Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752563AbdHNNz7 (ORCPT ); Mon, 14 Aug 2017 09:55:59 -0400 Received: from mail-oi0-f53.google.com ([209.85.218.53]:33776 "EHLO mail-oi0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751141AbdHNNz4 (ORCPT ); Mon, 14 Aug 2017 09:55:56 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Linus Walleij Date: Mon, 14 Aug 2017 15:55:55 +0200 Message-ID: Subject: Re: [PATCH 3/8] gpio: zynq: Shift zynq_gpio_init() to subsys_initcall level To: Michal Simek Cc: "linux-kernel@vger.kernel.org" , "monstr@monstr.eu" , Nava kishore Manne , =?UTF-8?Q?S=C3=B6ren_Brinkmann?= , Steffen Trumtrar , Peter Crosthwaite , "linux-gpio@vger.kernel.org" , Rob Herring , Josh Cartwright , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1185 Lines: 29 On Mon, Aug 7, 2017 at 1:01 PM, Michal Simek wrote: > From: Nava kishore Manne > > 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 > Signed-off-by: Michal Simek 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()? Yours, Linus Walleij