Thread (1 message) 1 message, 1 author, 2012-07-03

Re: [PATCH] of: support an enumerated-bus compatible value

From: Stephen Warren <hidden>
Date: 2012-07-03 15:43:24

On 07/03/2012 08:00 AM, Segher Boessenkool wrote:
quoted
quoted
Why would you want to instantiate devices that you cannot address
at all anyway?  The only driver that can know what to do with the
device node is the driver for the device that has the phandle
reference to it; it can instantiate it.
It's not a single device referencing it, it's multiple devices
referencing it, and we can do useful things even with no external
references at all.  The node itself is a real thing that we can point at
and control (using GPIOs or something similar).
So you *can* address the device, you just don't want to show that
in the device tree (I don't blame you, it's quite impossible to
design a sane addressing scheme for this, all this stuff is so
ad-hoc).  I see.  You could make it the kid of a GPIO controller
node, but then what if it is controlled by two (or more!) GPIO
controllers?

There is still no reason for the fake bus node to have a "compatible"
property though.  What could it possibly mean?  "This bus does not
exist at all but you access it in bla bla bla way"?  That just doesn't
make sense.  It doesn't exist, you do not access it, it has no
programming model, it has no "compatible" property.
Without the "bus" (or "collection node") having a compatible property,
nothing would recurse into the child nodes and instantiate the devices.
It doesn't make sense for anything other than the parent node of the
regulator (or sound or rfkill or etc. node) to instantiate it; there may
be 0..n different other nodes using the services of the nodes we're
talking about here, so the only unitary common thing that makes sense to
instantiate it is the parent, not some other random node that might use
the node's services.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help