Messages in this thread | | | From | Andy Shevchenko <> | Date | Mon, 8 Jun 2020 15:11:07 +0300 | Subject | Re: [PATCH v3] driver core: Break infinite loop when deferred probe can't be satisfied |
| |
On Mon, Jun 8, 2020 at 2:59 PM Marco Felsch <m.felsch@pengutronix.de> wrote: > On 20-06-08 14:13, Andy Shevchenko wrote: > > On Mon, Jun 8, 2020 at 12:20 PM Marco Felsch <m.felsch@pengutronix.de> wrote: > > > On 20-03-26 18:31, Andy Shevchenko wrote:
> > > sorry for picking this up again but I stumbled above the same issue > > > within the driver imx/drm driver which is using the component framework. > > > I end up in a infinity boot loop if I enabled the HDMI (which is the > > > DesignWare bridge device) and the LVDS support and the LVDS bind return > > > with EPROBE_DEFER. There are no words within the component framework docs > > > which says that this is forbidden. Of course we can work-around the > > > driver-core framework but IMHO this shouldn't be the way to go. I do not > > > say that we should revert the commit introducing the regression but we > > > should address this not only by extending the docs since the most > > > drm-drivers are using the component framework and can end up in the same > > > situation. > > > > > > > > It can be solved by refactoring the driver probe routine. If a resource is > > > > > required to be present, then check that it is available early; before > > > > > registering child devices. > > > > > > > > We fix one and leave others. > > > > > > E.g. the imx-drm and the sunxi driver... > > > > Just out of curiosity, does my patch fix an issue for you? > > I didn't applied your patch yet. I can test it if you want.
If you can, thanks!
> > > > > The proposed solution to modify driver core is fragile and susceptible to > > > > > side effects from other probe paths. I don't think it is the right approach.
-- With Best Regards, Andy Shevchenko
| |