Re: [PATCH v4 00/32] pinctrl: mediatek: Enable module build support for all drivers

[Linus Walleij]

Hi Justin,

thanks for your patches!

On Fri, Jun 26, 2026 at 6:01 AM Justin Yeh <justin.yeh@xxxxxxxxxxxx> wrote:

> Sorry for the quick v4 - v3 was sent with an incomplete cover letter
> (template placeholders) by mistake. This v4 also unifies MODULE_LICENSE
> to consistently use "GPL v2" across all patches.
>
> This series enables all MediaTek pinctrl drivers to be built as loadable
> kernel modules. This is required for Android GKI (Generic Kernel Image) +
> vendor_dlkm deployments where vendor-specific drivers must be kept separate
> from the GKI vmlinux.
>
> Each patch adds MODULE_LICENSE("GPL v2") and MODULE_DESCRIPTION() macros where
> missing, and changes the Kconfig option from bool to tristate. This allows
> these drivers to be properly packaged as vendor kernel modules while
> maintaining the existing built-in option.

Two things to fix:
1. Squash all these 32 patches into one, "one technical step". We don't wanna
  have to revery 32 patches, if this doesn't work on one driver it doesn't work
  on any driver.

2. Consider this Sashiko report on an unrelated patch by Luca:
  https://lore.kernel.org/linux-input/20260621083053.A3B641F000E9@xxxxxxxxxxxxxxx/

----8<----------8<--------8<----------8<--------
[Severity: High]
This is a pre-existing issue, but does mtk_pinctrl_driver in
drivers/pinctrl/mediatek/pinctrl-mt6397.c need a .remove callback or
suppress_bind_attrs set to true to prevent unbinding?

In drivers/pinctrl/mediatek/pinctrl-mtk-common.c:mtk_pctrl_init(), the driver
allocates the pctl and pctl->chip structures using devm_kzalloc() but
registers the GPIO chip using the unmanaged gpiochip_add_data() API:

mtk_pctrl_init() {
    ...
    pctl->chip = devm_kzalloc(&pdev->dev, sizeof(*pctl->chip), GFP_KERNEL);
    ...
    ret = gpiochip_add_data(pctl->chip, pctl);
    ...
}

If the driver is unbound via sysfs, the devm_ subsystem will free the memory
backing the GPIO chip while it remains registered with the core subsystem.
Could this lead to a use-after-free if the GPIOs are accessed after the
driver is unbound?
----8<----------8<--------8<----------8<--------

Well now we will unbind the driver by rmmod as well, so this needs fixing.

Please prepend a patch fixing this to the series.

Yours,
Linus Walleij