"status" property checks
Scott Wood
scottwood at freescale.com
Sat Jan 9 06:28:07 EST 2010
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
More information about the devicetree-discuss
mailing list