* Tony Lindgren [off-list ref] [161114 12:54]:

* Tony Lindgren [off-list ref] [161111 12:27]:

quoted

* Linus Walleij [off-list ref] [161111 12:17]:

quoted

On Tue, Oct 25, 2016 at 11:02 PM, Tony Lindgren [off-list ref] wrote:

quoted

Signed-off-by: Tony Lindgren <redacted>

I don't see why this is necessary?

It's needed because the pin controller driver has not yet
finished it's probe at this point. We end up calling functions
in the device driver where no struct pinctrl_dev is yet known
to the driver. Asking a device driver to do something before
it's probe is done does not quite follow the Linux driver model :)

quoted

The hogging was placed inside pinctrl_register() so that any hogs
would be taken before it returns, so nothing else can take it
before the controller itself has the first chance. This semantic
needs to be preserved I think.

quoted

+       schedule_delayed_work(&pctldev->hog_work,
+                                     msecs_to_jiffies(100));

If we arbitrarily delay, something else can go in and take the
pins used by the hogs before the pinctrl core? That is what
we want to avoid.

Hm, 100ms seems arbitrarily chosen BTW. Can it be 1 ms?
1 ns?

Yeah well seems like it should not matter but the race we need
to remove somehow.

quoted

I'm pretty sure that whatever it is that needs to happen before
the hog work runs can race with this delayed work under
some circumstances (such as slow external expanders
on i2c). It should be impossible for that to happen
and I don't think it is?

Yes it's totally possible even with delay set to 0.

Maybe we could add some trigger on the first consumer request
and if that does not happen use the timer?

Below is what I came up with for removing the race for hogs. We
can do it by not registering the pctldev until in the deferred
work, does that seem OK to you?

Oops, that does not yet work, will have to look into it more.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html