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. -- Hollis Blanchard Mentor Graphics, Embedded Systems Division > On Thu, 2010-01-07 at 15:07 -0800, Hollis Blanchard wrote: > > Right now, a number of drivers honor the "status" property on device > > nodes (via of_device_is_available() checks), but it's open-coded in each > > driver. I'm thinking of "hiding" arbitrary devices from the kernel, and > > setting this property seems like the best approach, but at the moment > > that would require modifying all OF drivers to check for it. > > > > Wouldn't the better approach be to have of_platform_device_probe() > > itself do the check, and not call the driver's probe() routine if the > > device isn't available? > > > > _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev