[PATCH v7 0/5] pinctrl: mediatek: Enable module build support
Linus Walleij
linusw at kernel.org
Sat Jul 25 06:02:24 PDT 2026
On Thu, Jul 23, 2026 at 5:58 AM Justin Yeh <justin.yeh at mediatek.com> wrote:
> This series lets the MediaTek pinctrl drivers be built as loadable
> kernel modules. This is required for Android GKI + vendor_dlkm
> deployments, where vendor-specific drivers must be kept separate from
> the GKI vmlinux and loaded as modules from the vendor partition.
>
> Enabling the individual SoC drivers as modules is a single logical step,
> but it has a few prerequisites, so the series is:
>
> 1. Fix a pre-existing GPIO chip lifecycle bug. The gpio_chip lives in
> device-managed memory but is registered with the non-managed
> gpiochip_add_data(). While the drivers were built-in only this was
> harmless, but once they can be unbound/rmmod'd, devm frees the
> backing memory while the chip is still registered (use-after-free).
> Switch to devm_gpiochip_add_data() in the shared probe/init paths.
>
> 2. Fix a pre-existing EINT resource leak on unbind. mtk_eint_do_init()
> creates an IRQ domain, an interrupt mapping per EINT line and a
> chained handler on the parent interrupt, none of which were ever
> released. Once the drivers can be unbound/rmmod'd this leaves a
> dangling IRQ domain, mappings whose chip data points at freed
> memory, and a chained handler still firing into that freed data.
> Tear them down with a device-managed action, matching the devm
> lifecycle used for the gpio_chip.
>
> 3. Make the shared common code modular. The SoC drivers link against
> pinctrl-mtk-common.c (v1), pinctrl-moore.c and pinctrl-mtmips.c,
> whose Kconfig symbols were bool and which exported nothing. Without
> this, selecting a SoC driver as =m forces the common symbol to =y
> and the module fails to link against the unexported entry points.
> Convert PINCTRL_MTK, PINCTRL_MTK_MOORE and PINCTRL_MTK_MTMIPS to
> tristate, export the entry points, and add MODULE_LICENSE()/
> MODULE_DESCRIPTION(). The already-modular v2 common code
> additionally needs mtk_rmw() exported, since it is called directly
> by SoC drivers such as mt7623. The shared symbols are exported in
> the "MTK_PINCTRL" symbol namespace (EXPORT_SYMBOL_NS_GPL()), and
> each SoC driver that uses them declares MODULE_IMPORT_NS().
>
> 4. Convert the MT7986 driver to a single initcall. It registers two
> platform drivers (mt7986a/mt7986b) and used to call arch_initcall()
> twice. A module has only one module_init(), so two arch_initcall()s
> break the module build with a redefinition of
> init_module()/__inittest(). Fold both drivers into one
> platform_register_drivers() call from a single initcall. No
> functional change when built-in.
>
> 5. Flip every SoC driver's Kconfig from bool to tristate and add the
> module metadata. This also adds the MODULE_DEVICE_TABLE(of, ...)
> entries that several drivers were missing, so the resulting modules
> carry the modalias information udev needs to autoload them on a
> matching device.
>
> The series builds cleanly under allmodconfig on arm64 (all SoC drivers
> as =m).
>
> Changes in v7:
> - patch 2/5 (free EINT resources on unbind): add synchronize_irq() in
> the teardown, after detaching the chained handler and before disposing
> of the domain/mappings, so any in-flight handler has finished before
> the data it references is freed, as suggested by AngeloGioacchino Del
> Regno. Also add the missing #include <linux/interrupt.h> that
> synchronize_irq() needs. Added his Reviewed-by.
> - patch 5/5 (enable module build support): add MODULE_DEVICE_TABLE(of,
> ...) to the SoC drivers that were missing it. AngeloGioacchino and
> Chen-Yu Tsai both pointed this out; without it the module still
> builds but is not autoloaded by udev on a matching device.
>
> Review status: patches 1/5 and 4/5 carry Chen-Yu Tsai's Reviewed-by;
> patch 2/5 carries AngeloGioacchino Del Regno's Reviewed-by; patch 5/5
> carries AngeloGioacchino Del Regno's Reviewed-by (from the per-driver
> patches reviewed in v4, preserved across the squash). Patch 3/5 has not
> been reviewed yet.
All patches applied, I had to rebase patch 5/5, please check the
result!
Yours,
Linus Walleij
More information about the Linux-mediatek
mailing list