<div dir="auto"><div>Hi Tony,<br><br><div class="gmail_quote"><div dir="ltr">Op ma 18 jun. 2018 11:54 schreef Tony Lindgren <<a href="mailto:tony@atomide.com">tony@atomide.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* H. Nikolaus Schaller <<a href="mailto:hns@goldelico.com" target="_blank" rel="noreferrer">hns@goldelico.com</a>> [180618 09:32]:<br>
> <br>
> > Am 18.06.2018 um 11:14 schrieb Tony Lindgren <<a href="mailto:tony@atomide.com" target="_blank" rel="noreferrer">tony@atomide.com</a>>:<br>
> > <br>
> > * Andy Shevchenko <<a href="mailto:andy.shevchenko@gmail.com" target="_blank" rel="noreferrer">andy.shevchenko@gmail.com</a>> [180618 08:25]:<br>
> >> On Sat, Jun 16, 2018 at 2:08 PM H. Nikolaus Schaller <<a href="mailto:hns@goldelico.com" target="_blank" rel="noreferrer">hns@goldelico.com</a>> wrote:<br>
> >>> But it looks as if we still have duplicate assignments by deferred probing, i.e. some cleanup is<br>
> >>> missing (or is this intended behaviour?).<br>
> >> <br>
> >>> But I think the fundamental problem is that the same driver assigns multiple slots if<br>
> >>> probing is deferred.<br>
> >> <br>
> >> Indeed.<br>
> >> <br>
> >> I think there is a simple way to clean up pinctrl stuff on failed probe. See<br>
> >> <a href="https://elixir.bootlin.com/linux/v4.18-rc1/source/drivers/base/dd.c#L416" rel="noreferrer noreferrer" target="_blank">https://elixir.bootlin.com/linux/v4.18-rc1/source/drivers/base/dd.c#L416</a><br>
> >> <br>
> >> We only bind pins, and do not perform any actions when failure happens later on.<br>
> > <br>
> > Yup seems like a good approach. I'll take a look if we can just<br>
> > check if the function or group name already exists and return<br>
> > the existing selector in that case.<br>
> <br>
> Ok, that would also solve the duplication issue.<br>
<br>
Below is an incremental patch to check for existing entries. Care<br>
to test again?<br>
<br>
If that works, I'll fold it into the patch series and repost the<br>
whole series.<br>
<br>
> On the other hand we still have a stale entry if the probing process<br>
> finally fails after several attempts.<br>
><br>
> This may happen if a driver with a valid DT entry is blacklisted in<br>
> /etc/modprobe.d/blacklist.conf. Then, the kernel will try to modprobe<br>
> it several times through udev until it gives up. The reason seems to<br>
> be that the deferred probing thread does not know why the driver did<br>
> not probe successfully.<br>
<br>
Hmm I think this might be fixed then too. Then on pinctrl module<br>
unbind/unload we should free the radix tree entries if that is<br>
not yet done. Seems we may only free them on -ENOMEM right now.<br>
<br>
Regards,<br>
<br>
Tony<br>
<br>
8< ------------------------<br>
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c<br>
--- a/drivers/pinctrl/core.c<br>
+++ b/drivers/pinctrl/core.c <br>
+               if (!strcmp(function, gname))</blockquote></div></div><div dir="auto"><br></div><div dir="auto">This could never fail? gname guaranteed to never == NULL?</div><div dir="auto"><br></div><div dir="auto">Christ van Willegen</div></div>