linux-kernel - Re: [PATCH v2 2/2] pinctrl: add NXP S32 SoC family support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkdbyfp3FwUfS7aDCLmsyM-3Xc1GfyX7_jFcuF1dhf+knQA@mail.gmail.com>
Date:   Fri, 9 Dec 2022 12:27:28 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Chester Lin <clin@...e.com>, Saravana Kannan <saravanak@...gle.com>
Cc:     Fabio Estevam <festevam@...il.com>,
        Dong Aisheng <aisheng.dong@....com>,
        Shawn Guo <shawnguo@...nel.org>, Jacky Bai <ping.bai@....com>,
        Pengutronix Kernel Team <kernel@...gutronix.de>, s32@....com,
        linux-gpio@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        Larisa Grigore <larisa.grigore@....com>,
        Ghennadi Procopciuc <Ghennadi.Procopciuc@....com>,
        Andrei Stefanescu <andrei.stefanescu@....com>,
        Radu Pirea <radu-nicolae.pirea@....com>,
        Andreas Färber <afaerber@...e.de>,
        Matthias Brugger <mbrugger@...e.com>,
        Matthew Nunez <matthew.nunez@....com>,
        Phu Luu An <phu.luuan@....com>,
        Stefan-Gabriel Mirea <stefan-gabriel.mirea@....com>
Subject: Re: [PATCH v2 2/2] pinctrl: add NXP S32 SoC family support

On Fri, Dec 9, 2022 at 5:39 AM Chester Lin <clin@...e.com> 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@...il.com> 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