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. -- Hollis Blanchard Mentor Graphics, Embedded Systems Division _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
