On 27 Jun 07:14 AM, Thierry Reding wrote: > On Mon, Jun 23, 2014 at 12:29:09PM -0300, Ezequiel Garcia wrote: > > > > > > No. We don't need to change the link order. > > > > Could you clarify why? I guess you have some case in mind where changing > > the link order breaks things or makes something mis-behave. > > I said we don't need to change the link order because there is a better > mechanism in the kernel to handle this type of situation. Saying "we > need to change" makes it sound like there's a bug that needs to be fixed > by changing the link order. That's not so. If link order breaks some > drivers then its those drivers that are broken. > Ah, OK. I understand your point now. On a second read, my commit log isn't too clear explaining why I want to change the order. > > > What we need to do is make > > > sure that modules deal properly with situations where their resources > > > aren't available yet (i.e. EPROBE_DEFER). There are factors other than > > > link order that influence probe ordering. > > > > > > > While I understand defering is more robust, it would be systematically > > defering the probe when the DRM driver needs an I2C encoder. > > > > Just to name one example, the tilcdc, armada and others requiring TDA998x > > encoder will always defered the probe of the DRM, and then re-probe() once > > the encoder is ready. > > > > So, unless we have a good reason not to do this, it sounds a bit silly > > to me. > > The problem that I have with working around this issue by changing the > link order is that it hides bugs in drivers. It's not like probe > deferral is a very expensive operation, so I very much prefer this as a > way of forcing drivers to be fixed rather than optimizing for a few > microseconds of boot time. > That's true. However, in this particular case, I'm not worried about the extra microseconds wasted in the defered operation, but about the unneeded delay introduced in the DRM probe. I know that relying in some particular order is very fragile, but I don't agree with knowingly and even explicitly have a sub-optimal order of the drivers. Or maybe it's just that I dislike deferals a lot. Anyway, thanks for feedback. -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel