From: Sergei Shtylyov <sshtylyov@ru•mvista.com>
To: Segher Boessenkool <segher@kernel•crashing.org>
Cc: ppcdev <linuxppc-dev@ozlabs•org>,
linux-mtd@lists•infradead.org, Milton Miller <miltonm@bga•com>
Subject: Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
Date: Sun, 03 Jun 2007 22:59:27 +0400 [thread overview]
Message-ID: <46630F8F.6080708@ru.mvista.com> (raw)
In-Reply-To: <c077dedaa90bf4fb3af1c5c8c4b39c85@kernel.crashing.org>
Segher Boessenkool wrote:
>>>>> I think "direct-mapped" as compatible is a bit too broad or vague.
>>>> It's actually not -- it means simple 1:1 address mapping (w/o
>>>> explicit
>>>> byte-swapping and such).
>>> Which has nothing to do with "compatible"; instead,
>>> it is implied by the parent node have a "ranges"
>> No! It doesn't have anything to do with "ranges" of parent (don't
>> even know why it would). :-O
> So learn about it please? "ranges" means exactly that:
> child nodes' address space is direct mapped.
Well, now we certainly need a parent node -- which would be static bus
controller? But those have multiple chips selects, so we should know which
range to use. Ugh...
>>> property. Or you can put some other property in
>>> the flash node for all I care, if that seems
>>> necessary for certain cases.
>> Erm... it's *certainly* necessary to mark this somewhere.
> Not if it's redundant information.
>>>> Note that we're matching by both "device_type" and "compatible".
>>> Which is wrong.
>> Why?
> Because that is a) not what you are supposed to do according
> to the standard (so it might very well not work with a
> "third-party" device tree that equally conforms to the standard);
> b) "device_type" describes some other information (namely, the
> OF programming model for the device node) that is completely
> unrelated to the process of driver matching; and c) it is wholly
> redundant to the information in "compatible" *ANYWAY*.
Hm, well. Than changing "compatible" prop would make sense.
>> And why then it's allowed to match by "device_type"?
> Anything is allowed, this is a free world. It is wrong though.
> Linux used to do this wrong, there are many remnants of that
> left. You also might *need* to do this for certain imperfect
> device trees. None of this is an argument to continue this
> "tradition".
>> And why you haven't complained at MPC5200 IDE driver
> Since no one paid me to review the code? Please don't try
Sigh, nobody pays me for that too. :-)
> that argument ever again, thank you very much. I think I
> do quite enough work here already, I don't need people
> demanding stuff from me.
I wasn't demanding anything. I just wanted to clear things out.
>> which does the same (well, maybe you have :-) or at PowerMac IDE
>> driver which matches wither by "name" or "device_type"? Well, quite a
>> lot of drivers are doing this...
> See before why that may be. Short answer is "history".
Well, at least that's cleared.
>>>> This would serve no purpose, as the driver that would catches
>>>> all these is signle one, drivers/mtd/maps/physmap_of.c...
>>> With the current kernel version, perhaps. Did you check
>>> out 2.6.28? Does it work with that?
>
>> For the simply mapped flashes, physmap_of will suffice, for more
>> complex cases, other driver will be needed.
> Ah, so you can predict the future of the Linux kernel!
If I could, I'd have taken measures. :-)
>> If you're hinting at the possibility that MTD subsys will be
>> substantially reworked -- I don't find that likely. If it will --
>> well, bad luck. :-)
> Which is not an acceptable outcome.
>> Anyway, reasonable suggestions on how to make MTD nodes more viable
>> are always welcome. I just haven't seen reasonable enough yet. ;-)
> I suggest you read, and try to understand, some of the base
> device tree specifications first.
Read them some months ago -- do you think I would have plunged into that
not reading anything first? :-/
> Segher
WBR, Sergei
next prev parent reply other threads:[~2007-06-03 18:57 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-02 4:30 [PATCH] powerpc: Create "rom" (MTD) device prpmc2800 Milton Miller
2007-06-02 7:39 ` Benjamin Herrenschmidt
2007-06-03 16:10 ` Sergei Shtylyov
2007-06-03 17:36 ` Segher Boessenkool
2007-06-03 18:03 ` Sergei Shtylyov
2007-06-03 18:25 ` Segher Boessenkool
2007-06-03 18:36 ` Sergei Shtylyov
2007-06-03 18:46 ` Segher Boessenkool
2007-06-03 19:16 ` Sergei Shtylyov
2007-06-03 21:04 ` Benjamin Herrenschmidt
2007-06-04 12:34 ` Sergei Shtylyov
2007-06-04 14:37 ` Segher Boessenkool
2007-06-04 14:49 ` Sergei Shtylyov
2007-06-07 14:53 ` David Woodhouse
2007-06-07 15:49 ` Segher Boessenkool
2007-06-07 14:47 ` David Woodhouse
2007-06-07 15:32 ` Segher Boessenkool
2007-06-02 8:53 ` Segher Boessenkool
2007-06-03 16:22 ` Sergei Shtylyov
2007-06-03 17:40 ` Segher Boessenkool
2007-06-03 18:31 ` Sergei Shtylyov
2007-06-03 18:44 ` Segher Boessenkool
2007-06-03 19:13 ` Sergei Shtylyov
2007-06-03 19:56 ` Segher Boessenkool
2007-06-03 20:26 ` Sergei Shtylyov
2007-06-04 8:07 ` Segher Boessenkool
2007-06-04 13:34 ` Sergei Shtylyov
2007-06-07 15:00 ` David Woodhouse
2007-06-07 15:55 ` Segher Boessenkool
2007-06-07 16:05 ` David Woodhouse
2007-06-07 16:46 ` Segher Boessenkool
2007-06-12 4:44 ` David Gibson
2007-06-12 10:53 ` Segher Boessenkool
2007-06-13 3:16 ` David Gibson
2007-06-13 5:05 ` Segher Boessenkool
2007-06-13 6:11 ` David Gibson
2007-06-13 9:10 ` Segher Boessenkool
2007-06-15 4:12 ` David Gibson
2007-06-15 11:22 ` Segher Boessenkool
2007-06-15 4:14 ` David Gibson
2007-06-15 8:42 ` Segher Boessenkool
2007-06-15 8:47 ` David Woodhouse
2007-06-15 8:59 ` Segher Boessenkool
2007-06-03 21:12 ` Benjamin Herrenschmidt
2007-06-04 8:11 ` Segher Boessenkool
2007-06-04 13:16 ` Sergei Shtylyov
2007-06-04 12:41 ` Sergei Shtylyov
2007-06-04 14:49 ` Segher Boessenkool
2007-06-04 15:54 ` Sergei Shtylyov
2007-06-03 17:29 ` Sergei Shtylyov
2007-06-03 17:45 ` Segher Boessenkool
2007-06-03 18:18 ` Sergei Shtylyov
2007-06-03 18:43 ` Segher Boessenkool
2007-06-03 18:59 ` Sergei Shtylyov [this message]
2007-06-03 19:48 ` Segher Boessenkool
2007-06-03 20:10 ` Sergei Shtylyov
2007-06-04 8:02 ` Segher Boessenkool
2007-06-04 19:40 ` Mark A. Greer
-- strict thread matches above, loose matches on Subject: below --
2007-06-01 23:20 Mark A. Greer
2007-06-02 8:46 ` Segher Boessenkool
2007-06-04 20:56 ` Mark A. Greer
2007-06-05 20:35 ` Sergei Shtylyov
2007-06-05 21:11 ` Mark A. Greer
2007-06-06 12:41 ` Sergei Shtylyov
2007-06-07 15:08 ` David Woodhouse
2007-06-06 2:39 ` David Gibson
2007-06-07 13:30 ` Segher Boessenkool
2007-06-12 4:42 ` David Gibson
2007-06-12 10:50 ` Segher Boessenkool
2007-06-13 6:12 ` David Gibson
2007-06-13 9:13 ` Segher Boessenkool
2007-06-13 9:19 ` David Gibson
2007-06-13 9:37 ` Segher Boessenkool
2007-06-14 4:29 ` David Gibson
2007-06-14 8:00 ` Segher Boessenkool
2007-06-14 12:39 ` Sergei Shtylyov
2007-06-14 13:20 ` Segher Boessenkool
2007-06-14 12:48 ` Sergei Shtylyov
2007-06-14 13:18 ` Segher Boessenkool
2007-06-14 12:50 ` Sergei Shtylyov
2007-06-14 13:43 ` Segher Boessenkool
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46630F8F.6080708@ru.mvista.com \
--to=sshtylyov@ru$(echo .)mvista.com \
--cc=linux-mtd@lists$(echo .)infradead.org \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=miltonm@bga$(echo .)com \
--cc=segher@kernel$(echo .)crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox