Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800

[Sergei Shtylyov <sshtylyov@ru.mvista.com>]

Segher Boessenkool wrote:

>>> Which Linux driver to use is not something that should
>>> be (directly) communicated in a device tree -- even if

>>    Bah... what's "name" and "compatible" properties are for then.

> They communicate to the kernel what exactly a certain device
> is.  Nothing more, nothing less.  The kernel is supposed to
> use this information to select what device driver to use for
> it.  Any extra information the kernel might need/want to drive
> the device is described in other properties (or, in some cases,
> in different device nodes, even).

    Yeah, the different node sounds more like this case.

>> Nobody's talking about the direct match but making the task of 
>> selecting a proper driver more complex by specifying the details that 
>> don't help (if not hinder) the correct selection is certainly not a 
>> way to go.

> Nonsense.  If the kernel doesn't care about certain details,
> it can just ignore them.

    That's OK, as long as it has the details it needs. Your suggestions on the 
"compatible" devoided it of such.

>>> -- the device tree on your board doesn't necessarily
>>> change when your kernel version does.

>>    Well, I'm not anticipating any changes either in this case...

> That's a problem then.

    At least not in the direction that you wanted us to change the MTD device 
node. :-)

>>>> the CFI/JEDEC interface then can be deduced by probing

>>> Most of the time, sure.  Not always.

>>    That's the way the cookie crumbles in Linux MTD for now. It's 
>> *always* detecting this by probing -- you only can say what [not] to 
>> probe.

> So go fix that :-)

    Wanna pay me for that? ;-)

>>> Who is talking about "probe-type"?  We are talking about "compatible".

>>    See my other mail where I've told why I don't consider your example 
>> of this prop valid...

> I haven't read that yet, but I can tell you now that I'm already
> very sceptical about the arguments.

> Segher

WBR, Sergei