"status" property checks

[Hollis Blanchard]

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