On Thu, Mar 18, 2021 at 9:39 AM Ahmad Fatoum <a.fat...@pengutronix.de> wrote:
>
> When retrying a deferred probe, any old defer reason string should be
> discarded. Otherwise, if probe is deferred again at a different spot,
probe -> the probe
> but without setting a message, a now incorrect probe reason will remain.
a now incorrect -> now the incorrect
> 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.
Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com>
> Cc: sta...@kernel.org
> Fixes: d090b70ede02 ("driver core: add deferring probe reason to
> devices_deferred property")
> Signed-off-by: Ahmad Fatoum <a.fat...@pengutronix.de>
> ---
> 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
> --
> 2.29.2
>
--
With Best Regards,
Andy Shevchenko
