"status" property checks

[Scott Wood]

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).

-Scott