linux-kernel - RE: [PATCH V2 1/4] gpio: mxc: Support module build

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: <DB3PR0402MB3916F080E4912B27B18BEADEF5720@DB3PR0402MB3916.eurprd04.prod.outlook.com>
Date:   Mon, 27 Jul 2020 08:18:56 +0000
From:   Anson Huang <anson.huang@....com>
To:     Arnd Bergmann <arnd@...db.de>
CC:     Russell King - ARM Linux <linux@...linux.org.uk>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Sascha Hauer <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Peter Chen <peter.chen@....com>,
        "oleksandr.suvorov@...adex.com" <oleksandr.suvorov@...adex.com>,
        Andreas Kemnade <andreas@...nade.info>,
        Peng Fan <peng.fan@....com>,
        Hans Verkuil <hverkuil-cisco@...all.nl>,
        Olof Johansson <olof@...om.net>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Alexandre Torgue <alexandre.torgue@...com>,
        Patrice Chotard <patrice.chotard@...com>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Joel Stanley <joel@....id.au>, Lubomir Rintel <lkundrak@...sk>,
        Christian Gmeiner <christian.gmeiner@...il.com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Leo Li <leoyang.li@....com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        "michael@...le.cc" <michael@...le.cc>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>
Subject: RE: [PATCH V2 1/4] gpio: mxc: Support module build

Hi, Arnd


> Subject: Re: [PATCH V2 1/4] gpio: mxc: Support module build
> 
> On Wed, Jul 22, 2020 at 3:50 AM Anson Huang <Anson.Huang@....com>
> wrote:
> >
> > Change config to tristate, add module device table, module author,
> > description and license to support module build for i.MX GPIO driver.
> >
> > As this is a SoC GPIO module, it provides common functions for most of
> > the peripheral devices, such as GPIO pins control, secondary interrupt
> > controller for GPIO pins IRQ etc., without GPIO driver, most of the
> > peripheral devices will NOT work properly, so GPIO module is similar
> > with clock, pinctrl driver that should be loaded ONCE and never
> > unloaded.
> >
> > Since MXC GPIO driver needs to have init function to register syscore
> > ops once, here still use subsys_initcall(), NOT module_platform_driver().
> 
> I'm not following this explanation.
> 
> Why is this driver using syscore_ops rather than
> SIMPLE_DEV_PM_OPS() or similar?

Below is the original patch of using syscore_ops, it has explanation:

commit 1a5287a3dbc34cd0c02c8f64c9131bd23cdfe2bb
Author: Anson Huang <anson.huang@....com>
Date:   Fri Nov 9 04:56:56 2018 +0000

    gpio: mxc: move gpio noirq suspend/resume to syscore phase

    During noirq suspend/resume phase, GPIO irq could arrive
    and its registers like IMR will be changed by irq handle
    process, to make the GPIO registers exactly when it is
    powered ON after resume, move the GPIO noirq suspend/resume
    callback to syscore suspend/resume phase, local irq is
    disabled at this phase so GPIO registers are atomic.

> 
> Why can the driver not unregister the syscore_ops the way it registers them
> when unloading the module?

As per previous discussion, for SoC level GPIO, since it acts as interrupt controller and
most of peripheral devices now depends on GPIO driver for proper function, so it makes
sense to keep SoC level GPIO once loaded and never unload.


> 
> Why do you need subsys_initcall() rather than a device_initcall()?

The subsys_initcal() is done by below commit, the commit log has detail explanation.


commit e188cbf7564fba80e8339b9406e8740f3e495c63
Author: Vladimir Zapolskiy <vladimir_zapolskiy@...tor.com>
Date:   Thu Sep 8 04:48:15 2016 +0300

    gpio: mxc: shift gpio_mxc_init() to subsys_initcall level


> 
> If the subsys_initcall() is indeed required here instead of device_initcall(), how
> can it work if the driver is a loadable module?

My understanding is: there are two scenarios, one for built-in case, the other is for loadable module,
the subsys_initcall() is for built-in case according to the upper commit, for loadable
module, the user needs to handle the sequence of modules loaded.

Thanks,
Anson