Scott Wood wrote:
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.
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 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.
--
Timur Tabi
Linux kernel developer at Freescale