"status" property checks

[David Gibson]

On Fri, Jan 08, 2010 at 11:45:28AM -0800, Hollis Blanchard wrote:
> 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.

Sounds good to me to.  Only thing I'd add, is that I'd also suggest a
helper function to do an explicit check on the status property (or do
we have that already?).  This could be useful for drivers which are
bound primarily to one device tree node, but also need to (possibly
optionally) check/use some other node.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson