On Fri, Dec 9, 2022 at 5:39 AM Chester Lin <clin@xxxxxxxx> wrote: > > Hi Linus and Fabio, > > Thanks for your time to review this patch! > > On Thu, Dec 08, 2022 at 10:37:36PM +0100, Linus Walleij wrote: > > On Thu, Dec 8, 2022 at 12:04 AM Fabio Estevam <festevam@xxxxxxxxx> wrote: > > > > > In other imx8m pinctrl drivers we pass: > > (...) > > > > +module_platform_driver(s32g_pinctrl_driver); > > > > > > And we also register it in arch_initcall() level. > > > > Do you really need that though? This driver certainly does not. > > > > I was under the impression that recent changes to the probe-order > > logic has made most explicit arch_ etc initcall orderings surplus. > > > > Could bool/tristate options in the Kconfig be the key point? > > Based on current design I prefer to build the s32g2 pinctrl driver as built-in > rather than a loadable module. IIUC, when the driver is not built as module > then the initcall ordering should still matter. It is true that if you compile something into a module then all initicalls are the same: they are called when the module is loaded. But the remaining initcalls used to be assigned to core, arch, subsystem etc in order for resources (such as clocks, regulators or pins) to be available before the drivers that need them get probed. However there was first deferred probe to partially solve the problem and recently a large and refined series that use the dependencies in the device tree to resolve probe order. Saravana Kannan has been working tirelessly at this, issueing git log --oneline --author="Saravana Kannan" you will see the scope of this work. Yours, Linus Walleij
