"status" property checks
Hollis Blanchard
hollis_blanchard at mentor.com
Sat Jan 9 06:45:28 EST 2010
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
More information about the devicetree-discuss
mailing list