* "status" property checks
@ 2010-01-07 23:07 ` Hollis Blanchard
0 siblings, 0 replies; 12+ messages in thread
From: Hollis Blanchard @ 2010-01-07 23:07 UTC (permalink / raw)
To: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ
Cc: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
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?
--
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
^ permalink raw reply [flat|nested] 12+ messages in thread
* "status" property checks
@ 2010-01-07 23:07 ` Hollis Blanchard
0 siblings, 0 replies; 12+ messages in thread
From: Hollis Blanchard @ 2010-01-07 23:07 UTC (permalink / raw)
To: devicetree-discuss; +Cc: linuxppc-dev
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: "status" property checks
2010-01-07 23:07 ` Hollis Blanchard
(?)
@ 2010-01-08 2:35 ` Hunter Cobbs
2010-01-08 18:34 ` Hollis Blanchard
-1 siblings, 1 reply; 12+ messages in thread
From: Hunter Cobbs @ 2010-01-08 2:35 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: devicetree-discuss, linuxppc-dev
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?
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: "status" property checks
2010-01-08 2:35 ` Hunter Cobbs
@ 2010-01-08 18:34 ` Hollis Blanchard
0 siblings, 0 replies; 12+ messages in thread
From: Hollis Blanchard @ 2010-01-08 18:34 UTC (permalink / raw)
To: Hunter Cobbs
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
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?
> >
>
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: "status" property checks
@ 2010-01-08 18:34 ` Hollis Blanchard
0 siblings, 0 replies; 12+ messages in thread
From: Hollis Blanchard @ 2010-01-08 18:34 UTC (permalink / raw)
To: Hunter Cobbs; +Cc: devicetree-discuss, linuxppc-dev
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: "status" property checks
2010-01-08 18:34 ` Hollis Blanchard
@ 2010-01-08 19:28 ` Scott Wood
-1 siblings, 0 replies; 12+ messages in thread
From: Scott Wood @ 2010-01-08 19:28 UTC (permalink / raw)
To: Hollis Blanchard
Cc: Hunter Cobbs, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: "status" property checks
@ 2010-01-08 19:28 ` Scott Wood
0 siblings, 0 replies; 12+ messages in thread
From: Scott Wood @ 2010-01-08 19:28 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: Hunter Cobbs, devicetree-discuss, linuxppc-dev
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: "status" property checks
2010-01-08 19:28 ` Scott Wood
@ 2010-01-08 19:45 ` Hollis Blanchard
-1 siblings, 0 replies; 12+ messages in thread
From: Hollis Blanchard @ 2010-01-08 19:45 UTC (permalink / raw)
To: Scott Wood
Cc: Hunter Cobbs, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
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.
--
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: "status" property checks
@ 2010-01-08 19:45 ` Hollis Blanchard
0 siblings, 0 replies; 12+ messages in thread
From: Hollis Blanchard @ 2010-01-08 19:45 UTC (permalink / raw)
To: Scott Wood; +Cc: Hunter Cobbs, devicetree-discuss, linuxppc-dev
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: "status" property checks
2010-01-08 19:45 ` Hollis Blanchard
(?)
@ 2010-01-08 23:46 ` David Gibson
2010-01-08 23:58 ` Hollis Blanchard
-1 siblings, 1 reply; 12+ messages in thread
From: David Gibson @ 2010-01-08 23:46 UTC (permalink / raw)
To: Hollis Blanchard
Cc: Scott Wood, Hunter Cobbs, devicetree-discuss, linuxppc-dev
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: "status" property checks
2010-01-08 23:46 ` David Gibson
@ 2010-01-08 23:58 ` Hollis Blanchard
0 siblings, 0 replies; 12+ messages in thread
From: Hollis Blanchard @ 2010-01-08 23:58 UTC (permalink / raw)
To: David Gibson
Cc: Scott Wood, Hunter Cobbs,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
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 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.
of_device_is_available() exists and is used already, so I think we're OK
there.
--
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: "status" property checks
@ 2010-01-08 23:58 ` Hollis Blanchard
0 siblings, 0 replies; 12+ messages in thread
From: Hollis Blanchard @ 2010-01-08 23:58 UTC (permalink / raw)
To: David Gibson; +Cc: Scott Wood, Hunter Cobbs, devicetree-discuss, linuxppc-dev
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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2010-01-08 23:58 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-01-07 23:07 "status" property checks Hollis Blanchard
2010-01-07 23:07 ` Hollis Blanchard
2010-01-08 2:35 ` Hunter Cobbs
2010-01-08 18:34 ` Hollis Blanchard
2010-01-08 18:34 ` Hollis Blanchard
[not found] ` <1262975655.31871.67.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2010-01-08 19:28 ` Scott Wood
2010-01-08 19:28 ` Scott Wood
[not found] ` <4B478747.8070009-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2010-01-08 19:45 ` Hollis Blanchard
2010-01-08 19:45 ` Hollis Blanchard
2010-01-08 23:46 ` David Gibson
2010-01-08 23:58 ` Hollis Blanchard
2010-01-08 23:58 ` Hollis Blanchard
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.