On Tue, Nov 15, 2016 at 6:08 PM, Tony Lindgren [off-list ref] wrote:

* Tony Lindgren [off-list ref] [161115 07:42]:

quoted

* Linus Walleij [off-list ref] [161114 22:53]:

quoted

On Tue, Nov 15, 2016 at 1:47 AM, Tony Lindgren [off-list ref] wrote:

quoted

8< --------------------------------
From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Tue, 25 Oct 2016 08:33:35 -0700
Subject: [PATCH] pinctrl: core: Use delayed work for hogs

Having the pin control framework call pin controller functions
before it's probe has finished is not nice as the pin controller
device driver does not yet have struct pinctrl_dev handle.

Let's fix this issue by adding deferred work for late init. This is
needed to be able to add pinctrl generic helper functions that expect
to know struct pinctrl_dev handle. Note that we now need to call
create_pinctrl() directly as we don't want to add the pin controller
to the list of controllers until the hogs are claimed. We also need
to pass the pinctrl_dev to the device tree parser functions as they
otherwise won't find the right controller at this point.

Signed-off-by: Tony Lindgren <tony@atomide.com>

This looks a lot better!

So if I understand correctly, we can guarantee that the delayed
work will not execute until the device driver probe() has finished,
and it *will* execute immediately after that?

So:
- Device driver probes
- Delayed work is called
- Next initcall

I'm not 100% familiar with how delayed work works... :/

Yeah well the delayed work gets scheduled for next jiffy but may
be pre-empted as it runs in process context.

So in the worst case it could that we still may need to fix few
drivers to support -EPROBE_DEFER. I wonder if we should check for
hogs in probe already and only defer if hogs are defined?

Below is a version using delayed_work only if pinctrl_dt_has_hogs().

Not sure if testing only for pinctrl-0 is enough there though?

Sorry for the lack of attention to this patch set on my part. :(

Do you think you could resend these last 5 patches after the
release of v4.10-rc1 so we merge it early for the next cycle
and people get a chance to test and see if it works well for
everyone?

I'm worried about adding it to the tree this late in the kernel
cycle...

However I like the look of the series overall a lot.

Yours,
Linus Walleij