Hi Ahmad, W dniu 19.03.2021 o 12:04, Ahmad Fatoum pisze: > When retrying a deferred probe, any old defer reason string should be > discarded. Otherwise, if the probe is deferred again at a different spot, > but without setting a message, the now incorrect probe reason will remain. > > This was observed with the i.MX I2C driver, which ultimately failed > to probe due to lack of the GPIO driver. The probe defer for GPIO > doesn't record a message, but a previous probe defer to clock_get did. > This had the effect that /sys/kernel/debug/devices_deferred listed > a misleading probe deferral reason. > > Cc: sta...@kernel.org > Fixes: d090b70ede02 ("driver core: add deferring probe reason to > devices_deferred property") > Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com> > Signed-off-by: Ahmad Fatoum <a.fat...@pengutronix.de>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com> Regards Andrzej > --- > v1 -> v2: > - reworded commit message (Andy) > - collected Andy's Reviewed-by > --- > drivers/base/dd.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/base/dd.c b/drivers/base/dd.c > index 9179825ff646..e2cf3b29123e 100644 > --- a/drivers/base/dd.c > +++ b/drivers/base/dd.c > @@ -97,6 +97,9 @@ static void deferred_probe_work_func(struct work_struct > *work) > > get_device(dev); > > + kfree(dev->p->deferred_probe_reason); > + dev->p->deferred_probe_reason = NULL; > + > /* > * Drop the mutex while probing each device; the probe path may > * manipulate the deferred list