"status" property checks

"status" property checks

[Hollis Blanchard]

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?

--=20
Hollis Blanchard
Mentor Graphics, Embedded Systems Division

Re: "status" property checks

[Hunter Cobbs]

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?

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?
> 

Re: "status" property checks

[Hollis Blanchard]

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.

--=20
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 eac=
h
> > 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.
> >=20
> > 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?
> >=20
>=20
>=20

Re: "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

Re: "status" property checks

[Hollis Blanchard]

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?
> >=20
> > Practically speaking, all drivers doing the checks today just return
> > -ENODEV. They don't try to do anything to "handle" the situation.
> >=20
> > 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)."
> >=20
> > If a device is "not operational" in this sense, I don't think there's
> > anything for a device driver to do.
>=20
> I could see situations where there is some software action that could=20
> enable the device (e.g. multiple devices sharing pins, where only one=20
> can be active at a time) -- but it's likely to not be the driver itself=20
> that knows how to do that.
>=20
> If the need arises, there could be a mechanism where the enabling entity=20
> can tell the platform bus that it has enabled a previously-disabled=20
> device, overriding the status in the device tree (and likewise if it=20
> 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.

--=20
Hollis Blanchard
Mentor Graphics, Embedded Systems Division

Re: "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

Re: "status" property checks

[Hollis Blanchard]

On Sat, 2010-01-09 at 10:46 +1100, David Gibson wrote:
> 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 tes=
ting
> > > >> for this particular issue.  The only thing question I have is if i=
ts
> > > >> really better to have the upper level do the check.  Shouldn't the
> > > >> driver itself handle the hardware and device node status?
> > > >=20
> > > > Practically speaking, all drivers doing the checks today just retur=
n
> > > > -ENODEV. They don't try to do anything to "handle" the situation.
> > > >=20
> > > > The definition of the status property implies it's outside of softw=
are's
> > > > control, for example:
> > > >         "disabled"
> > > >         "Indicates that the device is not presently operational, bu=
t it
> > > >         might become operational in the future (for example, someth=
ing
> > > >         is not plugged in, or switched off)."
> > > >=20
> > > > If a device is "not operational" in this sense, I don't think there=
's
> > > > anything for a device driver to do.
> > >=20
> > > I could see situations where there is some software action that could=
=20
> > > enable the device (e.g. multiple devices sharing pins, where only one=
=20
> > > can be active at a time) -- but it's likely to not be the driver itse=
lf=20
> > > that knows how to do that.
> > >=20
> > > If the need arises, there could be a mechanism where the enabling ent=
ity=20
> > > can tell the platform bus that it has enabled a previously-disabled=20
> > > device, overriding the status in the device tree (and likewise if it=20
> > > wants take down a device that was previously enabled).
> >=20
> > 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.
>=20
> 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.

of_device_is_available() exists and is used already, so I think we're OK
there.

--=20
Hollis Blanchard
Mentor Graphics, Embedded Systems Division