Re: [PATCH 2/2] powerpc/85xx: add Fman MDIO muxing support to the P4080DS
From: Scott Wood <hidden>
Date: 2012-08-14 23:06:39
Also in:
netdev
On 08/14/2012 04:58 PM, Timur Tabi wrote:
Scott Wood wrote:quoted
I think that was internally, and not on this specific comment wording. I don't think that code comment adequately explains things.I don't really have any more insight to add.
My point (at least, this part of it) was that more of the insight you've already provided should be moved from e-mail discussion to the code comment.
quoted
quoted
otherwise, the mdio-mux code would not prepare the mdio mus in time, and there would be initialization failures. Now maybe this goes away with -EPROBE_DEFER, or maybe it doesn't. But until we push the DPAA drivers upstream, we won't know.Do you know if it's theoretically supposed to be fixed and just can't test it, or are you unsure of whether it's even supposed to work?I'm not sure of anything. For one thing, we don't implement EPROBE_DEFER in the DPAA drivers, so we'd probably have to fix that before anything. And then, I'm just guessing that's the solution.
I feel confident saying it is the solution, at least until it is demonstrated otherwise.
quoted
I don't think we should be relying on the order of this list to determine probe order. For one thing, it won't work if the drivers register after you create the platform devices (e.g. they're modules).I agree we should not be relying on the order, but I don't know what to do. EPROBE_DEFER was designed to handle this situation, so my recommendation is to worry about it later. I can beef up the comment to talk about that, if you want.
If the DPAA driver doesn't implement it when it's submitted, it's a bug in the DPAA driver and we should insist it be fixed. I don't think we should at all entertain the notion that careful device id list ordering is even a potential solution. If anything, I'd make the ordering be "wrong" to force that code path to be tested -- though ideally there would be a more systematic approach to such testing, that doesn't require inefficiency during normal boot. -Scott