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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
