* "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
[parent not found: <1262975655.31871.67.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>]
* 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
[parent not found: <4B478747.8070009-KZfg59tc24xl57MIdRCFDg@public.gmane.org>]
* 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.