On 08/14/2012 04:58 PM, Timur Tabi wrote: > 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.
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. >>> 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. >> 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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
