All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Simek <michal.simek@xilinx.com>
To: Linus Walleij <linus.walleij@linaro.org>,
	Michal Simek <michal.simek@xilinx.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"monstr@monstr.eu" <monstr@monstr.eu>,
	"Nava kishore Manne" <nava.manne@xilinx.com>,
	"Sören Brinkmann" <soren.brinkmann@xilinx.com>,
	"Steffen Trumtrar" <s.trumtrar@pengutronix.de>,
	"Peter Crosthwaite" <peter.crosthwaite@xilinx.com>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"Rob Herring" <robherring2@gmail.com>,
	"Josh Cartwright" <josh.cartwright@ni.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 3/8] gpio: zynq: Shift zynq_gpio_init() to subsys_initcall level
Date: Mon, 14 Aug 2017 16:15:01 +0200	[thread overview]
Message-ID: <68cd52a7-ce87-a507-f02d-ccb99634b465@xilinx.com> (raw)
In-Reply-To: <CACRpkdbUBe6z2C9U9THaaLq0JLuu=EsGAVQfaSY55tMUotKvvg@mail.gmail.com>

On 14.8.2017 15:55, Linus Walleij wrote:
> On Mon, Aug 7, 2017 at 1:01 PM, Michal Simek <michal.simek@xilinx.com> wrote:
> 
>> From: Nava kishore Manne <nava.manne@xilinx.com>
>>
>> In general situation on-SoC GPIO controller drivers should be probed
>> after pinctrl/pinmux controller driver, because on-SoC GPIOs utilize a
>> pin/pad as a resource provided and controlled by pinctrl subsystem.
>>
>>   GPIO must come after pinctrl as gpios may need to mux pins....etc
>>
>> Looking at Xilinx SoC series pinctrl drivers, zynq*_pinctrl_init()
>> functions are called at arch_initcall init levels,
>> so the change of initcall level for gpio-zynq driver from
>> postcore_initcall to subsys_initcall level is sufficient. Also note
>> that the most of GPIO controller drivers settled at subsys_initcall
>> level.
>>
>> If pinctrl subsystem manages pads with GPIO functions, the change is
>> needed to avoid unwanted driver probe deferrals during kernel boot.
>>
>> Signed-off-by: Nava kishore Manne <navam@xilinx.com>
>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> 
> Can't you just move it all the way to device_initcall and
> simply use the standard module init macros?
> builtin_platform_driver(), module_platform_driver()?

When I grep the kernel I see this

[linux](master)$ git grep "^core_initcall" drivers/gpio/ | wc -l
1
[linux](master)$ git grep "^postcore_initcall" drivers/gpio/ | wc -l
12
[linux](master)$ git grep "^arch_initcall" drivers/gpio/ | wc -l
2
[linux](master)$ git grep "^subsys_initcall" drivers/gpio/ | wc -l
33
[linux](master)$ git grep "^device_initcall" drivers/gpio/ | wc -l
4


[linux](master)$ git grep "^core_initcall" drivers/pinctrl/ | wc -l
6
[linux](master)$ git grep "^postcore_initcall" drivers/pinctrl/ | wc -l
7
[linux](master)$ git grep "^arch_initcall" drivers/pinctrl/ | wc -l
62
[linux](master)$ git grep "^subsys_initcall" drivers/pinctrl/ | wc -l
12
[linux](master)$ git grep "^device_initcall" drivers/pinctrl/ | wc -l
0

Majority of gpio drivers are in subsys_initcall and pinctrl in
arch_initcall. It doesn't mean that I have strong opinion about doing
this change. I have also read internal tracking system and it is not
fully clear if this is fixing any issue rather than removing on
deferring probe message.

Nava: Do you have any comment?

Thanks,
Michal


WARNING: multiple messages have this Message-ID (diff)
From: michal.simek@xilinx.com (Michal Simek)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/8] gpio: zynq: Shift zynq_gpio_init() to subsys_initcall level
Date: Mon, 14 Aug 2017 16:15:01 +0200	[thread overview]
Message-ID: <68cd52a7-ce87-a507-f02d-ccb99634b465@xilinx.com> (raw)
In-Reply-To: <CACRpkdbUBe6z2C9U9THaaLq0JLuu=EsGAVQfaSY55tMUotKvvg@mail.gmail.com>

On 14.8.2017 15:55, Linus Walleij wrote:
> On Mon, Aug 7, 2017 at 1:01 PM, Michal Simek <michal.simek@xilinx.com> wrote:
> 
>> From: Nava kishore Manne <nava.manne@xilinx.com>
>>
>> In general situation on-SoC GPIO controller drivers should be probed
>> after pinctrl/pinmux controller driver, because on-SoC GPIOs utilize a
>> pin/pad as a resource provided and controlled by pinctrl subsystem.
>>
>>   GPIO must come after pinctrl as gpios may need to mux pins....etc
>>
>> Looking at Xilinx SoC series pinctrl drivers, zynq*_pinctrl_init()
>> functions are called at arch_initcall init levels,
>> so the change of initcall level for gpio-zynq driver from
>> postcore_initcall to subsys_initcall level is sufficient. Also note
>> that the most of GPIO controller drivers settled at subsys_initcall
>> level.
>>
>> If pinctrl subsystem manages pads with GPIO functions, the change is
>> needed to avoid unwanted driver probe deferrals during kernel boot.
>>
>> Signed-off-by: Nava kishore Manne <navam@xilinx.com>
>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> 
> Can't you just move it all the way to device_initcall and
> simply use the standard module init macros?
> builtin_platform_driver(), module_platform_driver()?

When I grep the kernel I see this

[linux](master)$ git grep "^core_initcall" drivers/gpio/ | wc -l
1
[linux](master)$ git grep "^postcore_initcall" drivers/gpio/ | wc -l
12
[linux](master)$ git grep "^arch_initcall" drivers/gpio/ | wc -l
2
[linux](master)$ git grep "^subsys_initcall" drivers/gpio/ | wc -l
33
[linux](master)$ git grep "^device_initcall" drivers/gpio/ | wc -l
4


[linux](master)$ git grep "^core_initcall" drivers/pinctrl/ | wc -l
6
[linux](master)$ git grep "^postcore_initcall" drivers/pinctrl/ | wc -l
7
[linux](master)$ git grep "^arch_initcall" drivers/pinctrl/ | wc -l
62
[linux](master)$ git grep "^subsys_initcall" drivers/pinctrl/ | wc -l
12
[linux](master)$ git grep "^device_initcall" drivers/pinctrl/ | wc -l
0

Majority of gpio drivers are in subsys_initcall and pinctrl in
arch_initcall. It doesn't mean that I have strong opinion about doing
this change. I have also read internal tracking system and it is not
fully clear if this is fixing any issue rather than removing on
deferring probe message.

Nava: Do you have any comment?

Thanks,
Michal

  reply	other threads:[~2017-08-14 14:15 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-07 11:01 [PATCH 0/8] Zynq GPIO driver changes Michal Simek
2017-08-07 11:01 ` Michal Simek
2017-08-07 11:01 ` [PATCH 1/8] gpio: zynq: Add support for suspend resume Michal Simek
2017-08-07 11:01   ` Michal Simek
2017-08-07 11:01   ` Michal Simek
2017-08-14 13:44   ` Linus Walleij
2017-08-14 13:44     ` Linus Walleij
2017-08-07 11:01 ` [PATCH 2/8] gpio: zynq: Wakeup gpio controller when it is used as IRQ controller Michal Simek
2017-08-07 11:01   ` Michal Simek
2017-08-14 13:53   ` Linus Walleij
2017-08-14 13:53     ` Linus Walleij
2017-08-14 14:33     ` Michal Simek
2017-08-14 14:33       ` Michal Simek
2017-08-22 12:57       ` Linus Walleij
2017-08-22 12:57         ` Linus Walleij
2019-01-07 15:42       ` Thomas Petazzoni
2019-01-07 15:42         ` Thomas Petazzoni
2019-01-08 13:21         ` Michal Simek
2019-01-08 13:21           ` Michal Simek
2019-01-11  9:54         ` Linus Walleij
2019-01-11  9:54           ` Linus Walleij
2019-01-11 12:54           ` Thomas Petazzoni
2019-01-11 12:54             ` Thomas Petazzoni
2019-01-11 14:37             ` Linus Walleij
2019-01-11 14:37               ` Linus Walleij
2019-01-11 14:37               ` Linus Walleij
2019-01-21  6:11               ` Shubhrajyoti Datta
2019-01-21  6:11                 ` Shubhrajyoti Datta
2019-01-21  6:11                 ` Shubhrajyoti Datta
2017-08-07 11:01 ` [PATCH 3/8] gpio: zynq: Shift zynq_gpio_init() to subsys_initcall level Michal Simek
2017-08-07 11:01   ` Michal Simek
2017-08-14 13:55   ` Linus Walleij
2017-08-14 13:55     ` Linus Walleij
2017-08-14 14:15     ` Michal Simek [this message]
2017-08-14 14:15       ` Michal Simek
2017-08-22 13:02       ` Linus Walleij
2017-08-22 13:02         ` Linus Walleij
2017-08-07 11:01 ` [PATCH 4/8] gpio: zynq: Provided workaround for GPIO Michal Simek
2017-08-07 11:01   ` Michal Simek
2017-08-14 13:57   ` Linus Walleij
2017-08-14 13:57     ` Linus Walleij
2017-08-14 14:01     ` Michal Simek
2017-08-14 14:01       ` Michal Simek
2017-08-07 11:01 ` [PATCH 5/8] gpio: zynq: Fix kernel doc warnings Michal Simek
2017-08-07 11:01   ` Michal Simek
2017-08-14 13:58   ` Linus Walleij
2017-08-14 13:58     ` Linus Walleij
2017-08-07 11:01 ` [PATCH 6/8] gpio: zynq: Fix empty lines in driver Michal Simek
2017-08-07 11:01   ` Michal Simek
2017-08-14 13:59   ` Linus Walleij
2017-08-14 13:59     ` Linus Walleij
2017-08-07 11:02 ` [PATCH 7/8] gpio: zynq: Fix warnings in the driver Michal Simek
2017-08-07 11:02   ` Michal Simek
2017-08-14 14:00   ` Linus Walleij
2017-08-14 14:00     ` Linus Walleij
2017-08-07 11:02 ` [PATCH 8/8] gpio: zynq: Fix driver function parameters alignment Michal Simek
2017-08-07 11:02   ` Michal Simek
2017-08-14 14:01   ` Linus Walleij
2017-08-14 14:01     ` Linus Walleij
2017-08-14 14:03     ` Michal Simek
2017-08-14 14:03       ` Michal Simek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=68cd52a7-ce87-a507-f02d-ccb99634b465@xilinx.com \
    --to=michal.simek@xilinx.com \
    --cc=josh.cartwright@ni.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=monstr@monstr.eu \
    --cc=nava.manne@xilinx.com \
    --cc=peter.crosthwaite@xilinx.com \
    --cc=robherring2@gmail.com \
    --cc=s.trumtrar@pengutronix.de \
    --cc=soren.brinkmann@xilinx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.