On Sat, 2010-01-09 at 10:46 +1100, David Gibson wrote: > On Fri, Jan 08, 2010 at 11:45:28AM -0800, Hollis Blanchard wrote: > > On Fri, 2010-01-08 at 13:28 -0600, Scott Wood wrote: > > > Hollis Blanchard wrote: > > > > On Thu, 2010-01-07 at 20:35 -0600, Hunter Cobbs wrote: > > > >> I think that is definitely a solution. It does centralize the testing > > > >> for this particular issue. The only thing question I have is if its > > > >> really better to have the upper level do the check. Shouldn't the > > > >> driver itself handle the hardware and device node status? > > > > > > > > Practically speaking, all drivers doing the checks today just return > > > > -ENODEV. They don't try to do anything to "handle" the situation. > > > > > > > > The definition of the status property implies it's outside of software's > > > > control, for example: > > > > "disabled" > > > > "Indicates that the device is not presently operational, but it > > > > might become operational in the future (for example, something > > > > is not plugged in, or switched off)." > > > > > > > > If a device is "not operational" in this sense, I don't think there's > > > > anything for a device driver to do. > > > > > > I could see situations where there is some software action that could > > > enable the device (e.g. multiple devices sharing pins, where only one > > > can be active at a time) -- but it's likely to not be the driver itself > > > that knows how to do that. > > > > > > If the need arises, there could be a mechanism where the enabling entity > > > can tell the platform bus that it has enabled a previously-disabled > > > device, overriding the status in the device tree (and likewise if it > > > wants take down a device that was previously enabled). > > > > OK, that makes sense to me. I'll put together a patch for the original > > idea, and the enable/disable part can come later as needed. > > Sounds good to me to. Only thing I'd add, is that I'd also suggest a > helper function to do an explicit check on the status property (or do > we have that already?). This could be useful for drivers which are > bound primarily to one device tree node, but also need to (possibly > optionally) check/use some other node.
of_device_is_available() exists and is used already, so I think we're OK there. -- Hollis Blanchard Mentor Graphics, Embedded Systems Division _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
