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