| Message ID | 1344358266-5450-1-git-send-email-timur@freescale.com |
|---|---|
| State | Changes Requested, archived |
| Delegated to: | David Miller |
| Headers | show |
On 08/07/2012 09:51 AM, Timur Tabi wrote: > The mdio-mux driver scans all child mdio nodes, without regard to whether > the node is actually used. Some device trees include all possible > mdio-mux nodes and rely on the boot loader to disable those that are not > present, based on some run-time configuration. Those nodes need to be > skipped. > > Signed-off-by: Timur Tabi<timur@freescale.com> > --- > drivers/net/phy/mdio-mux.c | 9 +++++++++ > 1 files changed, 9 insertions(+), 0 deletions(-) > > diff --git a/drivers/net/phy/mdio-mux.c b/drivers/net/phy/mdio-mux.c > index 5c12018..d0c231e 100644 > --- a/drivers/net/phy/mdio-mux.c > +++ b/drivers/net/phy/mdio-mux.c > @@ -135,6 +135,15 @@ int mdio_mux_init(struct device *dev, > for_each_child_of_node(dev->of_node, child_bus_node) { > u32 v; > > + /* > + * Some device trees include all possible mdio-mux nodes and > + * rely on the boot loader to disable those that are not > + * present, based on some run-time configuration. Those nodes > + * need to be skipped. > + */ > + if (!of_device_is_available(child_bus_node)) > + continue; Although this will get the job done, I don't think it is the cleanest approach. Would it be better to create a new iterator (for_each_available_child_of_node perhaps) that skips the unavailable nodes? This seems like a general problem that is not restricted to mdio multiplexers. David Daney -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
David Daney wrote: > Although this will get the job done, I don't think it is the cleanest > approach. > > Would it be better to create a new iterator > (for_each_available_child_of_node perhaps) that skips the unavailable > nodes? This seems like a general problem that is not restricted to mdio > multiplexers. You're probably right, but this is how it's normally done. If you're going to scan child nodes manually, you have to skip disabled nodes. If someone else wants to implement for_each_available_child_of_node(), I'm all for it, but such a patch would not be merged until 3.7. I was hoping to have my patch applied to 3.6, since it fixes a real bug.
On Tue, Aug 7, 2012 at 11:51 AM, Timur Tabi <timur@freescale.com> wrote: > The mdio-mux driver scans all child mdio nodes, without regard to whether > the node is actually used. Some device trees include all possible > mdio-mux nodes and rely on the boot loader to disable those that are not > present, based on some run-time configuration. Those nodes need to be > skipped. > > Signed-off-by: Timur Tabi <timur@freescale.com> > --- Mr. Miller, Any chance this patch can get into 3.6? I don't know if it qualifies as a fix or not, but getting it into 3.6 would make it easier for me to apply other patches to the powerpc tree.
From: Tabi Timur-B04825 <B04825@freescale.com> Date: Tue, 14 Aug 2012 19:19:58 +0000 > On Tue, Aug 7, 2012 at 11:51 AM, Timur Tabi <timur@freescale.com> wrote: >> The mdio-mux driver scans all child mdio nodes, without regard to whether >> the node is actually used. Some device trees include all possible >> mdio-mux nodes and rely on the boot loader to disable those that are not >> present, based on some run-time configuration. Those nodes need to be >> skipped. >> >> Signed-off-by: Timur Tabi <timur@freescale.com> >> --- > > Any chance this patch can get into 3.6? I don't know if it qualifies > as a fix or not, but getting it into 3.6 would make it easier for me > to apply other patches to the powerpc tree. > I want you to implement it the way David Daney said to do so. And you never need to ask me questions like this, I clearly mark the state of your patch: http://patchwork.ozlabs.org/patch/175750/ So that you can just monitor it instead of wasting my time asking what is happening to your patch. Time of mine you consume forcing me to reply to you in situations like this, which you could handle on your own, is time that I can't spend reviewing patches from oher people that really are ready to go into the tree. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller wrote: >> Any chance this patch can get into 3.6? I don't know if it qualifies >> as a fix or not, but getting it into 3.6 would make it easier for me >> to apply other patches to the powerpc tree. >> > > I want you to implement it the way David Daney said to do so. So you're saying that you don't want this fixed for 3.6? Because David Daney's suggestion would require me to introduce a new device tree function, and that won't be accepted until 3.7 at the earliest. > And you never need to ask me questions like this, I clearly mark the > state of your patch: > > http://patchwork.ozlabs.org/patch/175750/ > > So that you can just monitor it instead of wasting my time asking what > is happening to your patch. Sorry. > Time of mine you consume forcing me to reply to you in situations like > this, which you could handle on your own, is time that I can't spend > reviewing patches from oher people that really are ready to go into > the tree. >
From: Timur Tabi <timur@freescale.com> Date: Tue, 14 Aug 2012 16:12:10 -0500 > David Miller wrote: > >>> Any chance this patch can get into 3.6? I don't know if it qualifies >>> as a fix or not, but getting it into 3.6 would make it easier for me >>> to apply other patches to the powerpc tree. >>> >> >> I want you to implement it the way David Daney said to do so. > > So you're saying that you don't want this fixed for 3.6? Because David > Daney's suggestion would require me to introduce a new device tree > function, and that won't be accepted until 3.7 at the earliest. If it is infrastrucure needed to fix a bug, it would be accepted. Stop talking nonsense. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/phy/mdio-mux.c b/drivers/net/phy/mdio-mux.c index 5c12018..d0c231e 100644 --- a/drivers/net/phy/mdio-mux.c +++ b/drivers/net/phy/mdio-mux.c @@ -135,6 +135,15 @@ int mdio_mux_init(struct device *dev, for_each_child_of_node(dev->of_node, child_bus_node) { u32 v; + /* + * Some device trees include all possible mdio-mux nodes and + * rely on the boot loader to disable those that are not + * present, based on some run-time configuration. Those nodes + * need to be skipped. + */ + if (!of_device_is_available(child_bus_node)) + continue; + r = of_property_read_u32(child_bus_node, "reg", &v); if (r) continue;
The mdio-mux driver scans all child mdio nodes, without regard to whether the node is actually used. Some device trees include all possible mdio-mux nodes and rely on the boot loader to disable those that are not present, based on some run-time configuration. Those nodes need to be skipped. Signed-off-by: Timur Tabi <timur@freescale.com> --- drivers/net/phy/mdio-mux.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)