[PATCH 0/3] Add pinctrl and GPIO support for MediaTek MT8901

[PATCH 0/3] Add pinctrl and GPIO support for MediaTek MT8901

[Lei Xue]

Dear maintainers,

This patch series contains three patches aimed at improving the
Linux kernel support for MediaTek platforms, specifically for
the MT8901 SoC. The details are as follows:

Add GPIO range record in MediaTek pinctrl driver
 - This patch introduces GPIO range recording in the MediaTek
   pinctrl driver, providing a foundation for proper GPIO
   identification and management.

Add ACPI support in MediaTek pinctrl driver
 - This patch adds ACPI support to the MediaTek pinctrl driver,
   enabling the driver to function correctly in ACPI environments
   and enhancing platform compatibility.

Add pinctrl driver for MediaTek MT8901
 - This patch adds a new pinctrl driver for the MT8901 SoC,
   defining the GPIO functions, register mappings, and multiplexing
   relationships to improve pin control capabilities for MT8901.

These patches will help enhance the mainline kernel support for MediaTek MT8901.
Your review and feedback are highly appreciated.

Thank you!


Lei Xue (3):
  pinctrl: mediatek: Add gpio-range record in pinctrl driver
  pinctrl: mediatek: Add acpi support
  pinctrl: mediatek: mt8901: Add pinctrl driver for MT8901

 drivers/pinctrl/mediatek/Kconfig              |   12 +
 drivers/pinctrl/mediatek/Makefile             |    1 +
 drivers/pinctrl/mediatek/mtk-eint.c           |    4 +
 drivers/pinctrl/mediatek/mtk-eint.h           |    1 +
 drivers/pinctrl/mediatek/pinctrl-mt8901.c     | 1460 +++++++++++
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.c  |   24 +-
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.h  |    1 +
 drivers/pinctrl/mediatek/pinctrl-mtk-mt8901.h | 2130 +++++++++++++++++
 drivers/pinctrl/mediatek/pinctrl-paris.c      |   21 +-
 9 files changed, 3647 insertions(+), 7 deletions(-)
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt8901.c
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt8901.h

-- 
2.45.2

[PATCH 1/3] pinctrl: mediatek: Add gpio-range record in pinctrl driver

[Lei Xue]

Kernel GPIO subsystem mapping hardware pin number to a different
range of gpio number. Add gpio-range structure to hold
the mapped gpio range in pinctrl driver. That enables the kernel
to search a range of mapped gpio range against a pinctrl device.

Signed-off-by: Lei Xue <lei.xue@mediatek.com>
---
 drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h |  1 +
 drivers/pinctrl/mediatek/pinctrl-paris.c         | 15 ++++++++++++++-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
index fa7c0ed49346..df8dce14744f 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
@@ -302,6 +302,7 @@ struct mtk_pinctrl {
 	spinlock_t lock;
 	/* identify rsel setting by si unit or rsel define in dts node */
 	bool rsel_si_unit;
+	struct pinctrl_gpio_range	range;
 };
 
 void mtk_rmw(struct mtk_pinctrl *pctl, u8 i, u32 reg, u32 mask, u32 set);
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c b/drivers/pinctrl/mediatek/pinctrl-paris.c
index 6bf37d8085fa..2cf61cfe809e 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.c
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
@@ -3,7 +3,7 @@
  * MediaTek Pinctrl Paris Driver, which implement the vendor per-pin
  * bindings for MediaTek SoC.
  *
- * Copyright (C) 2018 MediaTek Inc.
+ * Copyright (C) 2018-2025 MediaTek Inc.
  * Author: Sean Wang <sean.wang@mediatek.com>
  *	   Zhiyong Tao <zhiyong.tao@mediatek.com>
  *	   Hongzhou.Yang <hongzhou.yang@mediatek.com>
@@ -936,6 +936,15 @@ static int mtk_gpio_set_config(struct gpio_chip *chip, unsigned int offset,
 	return mtk_eint_set_debounce(hw->eint, desc->eint.eint_n, debounce);
 }
 
+static void mtk_pinctrl_gpio_range_init(struct mtk_pinctrl *hw, struct gpio_chip *chip)
+{
+	hw->range.name = "mtk_pinctrl_gpio_range";
+	hw->range.id = 0;
+	hw->range.pin_base = 0;
+	hw->range.base = chip->base;
+	hw->range.npins = hw->soc->npins;
+}
+
 static int mtk_build_gpiochip(struct mtk_pinctrl *hw)
 {
 	struct gpio_chip *chip = &hw->chip;
@@ -959,6 +968,8 @@ static int mtk_build_gpiochip(struct mtk_pinctrl *hw)
 	if (ret < 0)
 		return ret;
 
+	mtk_pinctrl_gpio_range_init(hw, chip);
+
 	return 0;
 }
 
@@ -1077,6 +1088,8 @@ int mtk_paris_pinctrl_probe(struct platform_device *pdev)
 	if (err)
 		return dev_err_probe(dev, err, "Failed to add gpio_chip\n");
 
+	pinctrl_add_gpio_range(hw->pctrl, &hw->range);
+
 	platform_set_drvdata(pdev, hw);
 
 	return 0;
-- 
2.45.2

Re: [PATCH 1/3] pinctrl: mediatek: Add gpio-range record in pinctrl driver

[Andy Shevchenko]

On Tue, Nov 25, 2025 at 10:36:34AM +0800, Lei Xue wrote:
> Kernel GPIO subsystem mapping hardware pin number to a different
> range of gpio number. Add gpio-range structure to hold
> the mapped gpio range in pinctrl driver. That enables the kernel
> to search a range of mapped gpio range against a pinctrl device.

...

>  static int mtk_build_gpiochip(struct mtk_pinctrl *hw)
>  {
>  	struct gpio_chip *chip = &hw->chip;

>  	if (ret < 0)
>  		return ret;
>  
> +	mtk_pinctrl_gpio_range_init(hw, chip);
> +
>  	return 0;

We have a callback for that in struct gpio_chip. Any reason not to use it?

>  }

...

> +	pinctrl_add_gpio_range(hw->pctrl, &hw->range);

Not sure if this is needed.

-- 
With Best Regards,
Andy Shevchenko

[PATCH 2/3] pinctrl: mediatek: Add acpi support

[Lei Xue]

Add acpi support in the common part of pinctrl driver. Parsing
hardware base addresses and irq number to initialize eint
accroding to the acpi table data.

Signed-off-by: Lei Xue <lei.xue@mediatek.com>
---
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.c  | 24 +++++++++++++++----
 drivers/pinctrl/mediatek/pinctrl-paris.c      |  6 +++--
 2 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
index 4918d38abfc2..afa406afead2 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
@@ -369,18 +369,30 @@ int mtk_build_eint(struct mtk_pinctrl *hw, struct platform_device *pdev)
 {
 	struct device_node *np = pdev->dev.of_node;
 	int ret, i, j, count_reg_names;
+	struct fwnode_handle *fwnode = dev_fwnode(&pdev->dev);
+	struct resource *res;
 
 	if (!IS_ENABLED(CONFIG_EINT_MTK))
 		return 0;
 
-	if (!of_property_read_bool(np, "interrupt-controller"))
+	if (is_of_node(fwnode) && !of_property_read_bool(np, "interrupt-controller"))
 		return -ENODEV;
 
 	hw->eint = devm_kzalloc(hw->dev, sizeof(*hw->eint), GFP_KERNEL);
 	if (!hw->eint)
 		return -ENOMEM;
 
-	count_reg_names = of_property_count_strings(np, "reg-names");
+	if (is_of_node(fwnode)) {
+		count_reg_names = of_property_count_strings(np, "reg-names");
+	} else {
+		count_reg_names = 0;
+		for (i = 0; i < pdev->num_resources; i++) {
+			struct resource *r = &pdev->resource[i];
+
+			if (resource_type(r) == IORESOURCE_MEM)
+				count_reg_names++;
+		}
+	}
 	if (count_reg_names < 0)
 		return -EINVAL;
 
@@ -396,14 +408,18 @@ int mtk_build_eint(struct mtk_pinctrl *hw, struct platform_device *pdev)
 	}
 
 	for (i = hw->soc->nbase_names, j = 0; i < count_reg_names; i++, j++) {
-		hw->eint->base[j] = of_iomap(np, i);
+		res = platform_get_resource(pdev, IORESOURCE_MEM, i);
+		hw->eint->base[j] = is_of_node(fwnode) ? of_iomap(np, i) :
+					ioremap(res->start, resource_size(res));
 		if (IS_ERR(hw->eint->base[j])) {
 			ret = PTR_ERR(hw->eint->base[j]);
 			goto err_free_eint;
 		}
 	}
 
-	hw->eint->irq = irq_of_parse_and_map(np, 0);
+	hw->eint->irq = is_of_node(fwnode)
+			? irq_of_parse_and_map(np, 0)
+			: platform_get_irq(pdev, 0);
 	if (!hw->eint->irq) {
 		ret = -EINVAL;
 		goto err_free_eint;
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c b/drivers/pinctrl/mediatek/pinctrl-paris.c
index 2cf61cfe809e..9c2751b9b065 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.c
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
@@ -1008,6 +1008,7 @@ int mtk_paris_pinctrl_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct pinctrl_pin_desc *pins;
 	struct mtk_pinctrl *hw;
+	struct fwnode_handle *fwnode = dev_fwnode(&pdev->dev);
 	int err, i;
 
 	hw = devm_kzalloc(&pdev->dev, sizeof(*hw), GFP_KERNEL);
@@ -1032,8 +1033,9 @@ int mtk_paris_pinctrl_probe(struct platform_device *pdev)
 		return -ENOMEM;
 
 	for (i = 0; i < hw->soc->nbase_names; i++) {
-		hw->base[i] = devm_platform_ioremap_resource_byname(pdev,
-					hw->soc->base_names[i]);
+		hw->base[i] = is_of_node(fwnode)
+			? devm_platform_ioremap_resource_byname(pdev, hw->soc->base_names[i])
+			: devm_platform_get_and_ioremap_resource(pdev, i, NULL);
 		if (IS_ERR(hw->base[i]))
 			return PTR_ERR(hw->base[i]);
 	}
-- 
2.45.2

Re: [PATCH 2/3] pinctrl: mediatek: Add acpi support

[Linus Walleij]

On Tue, Nov 25, 2025 at 3:36 AM Lei Xue <lei.xue@mediatek.com> wrote:

> Add acpi support in the common part of pinctrl driver. Parsing
> hardware base addresses and irq number to initialize eint
> accroding to the acpi table data.
>
> Signed-off-by: Lei Xue <lei.xue@mediatek.com>

I'd ideally like Andy and the ARM64 ACPI maintainers look on
this. (Added to To:) and CC linux-acpi@vger.kernel.org.

I'm not aware of the best way to deal with ACPI in combined drivers
but things like this:

> -               hw->base[i] = devm_platform_ioremap_resource_byname(pdev,
> -                                       hw->soc->base_names[i]);
> +               hw->base[i] = is_of_node(fwnode)
> +                       ? devm_platform_ioremap_resource_byname(pdev, hw->soc->base_names[i])
> +                       : devm_platform_get_and_ioremap_resource(pdev, i, NULL);

Just look really quirky, I think there are better ways to go about
this and sometimes the ACPI maintainers give some good
pushback about the firmware as well.

Yours,
Linus Walleij

Re: [PATCH 2/3] pinctrl: mediatek: Add acpi support

[Lorenzo Pieralisi]

[+cc: RobH for his information]

On Wed, Nov 26, 2025 at 10:10:15AM +0100, Linus Walleij wrote:
> On Tue, Nov 25, 2025 at 3:36 AM Lei Xue <lei.xue@mediatek.com> wrote:
> 
> > Add acpi support in the common part of pinctrl driver. Parsing
> > hardware base addresses and irq number to initialize eint
> > accroding to the acpi table data.
> >
> > Signed-off-by: Lei Xue <lei.xue@mediatek.com>
> 
> I'd ideally like Andy and the ARM64 ACPI maintainers look on
> this. (Added to To:) and CC linux-acpi@vger.kernel.org.
> 
> I'm not aware of the best way to deal with ACPI in combined drivers
> but things like this:
> 
> > -               hw->base[i] = devm_platform_ioremap_resource_byname(pdev,
> > -                                       hw->soc->base_names[i]);
> > +               hw->base[i] = is_of_node(fwnode)
> > +                       ? devm_platform_ioremap_resource_byname(pdev, hw->soc->base_names[i])
> > +                       : devm_platform_get_and_ioremap_resource(pdev, i, NULL);
> 
> Just look really quirky, I think there are better ways to go about
> this and sometimes the ACPI maintainers give some good
> pushback about the firmware as well.

How are pdev->resource initialized ? For OF I suppose the names come from
"reg-names" (that don't exist in ACPI, yet), for ACPI I assume they come
from a _CRS (and you can't tag them by name for the reason above) ?

I assume that in ACPI the _CRS resource order is foolproof against the
variaty of SOCs this code has to deal with.

I also assume/hope that we don't want to add a "reg-names" _DSD property either
in ACPI to deal with this seamlessly in DT/ACPI (that was done for
"interrupt-names"):

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/firmware-guide/acpi/enumeration.rst?h=v6.18-rc7#n188

I am sorry I have got more questions than answers here - it would be good
to understand where the line is drawn when it comes to OF/ACPI and fwnode
heuristics compatibility.

Thanks,
Lorenzo

Re: [PATCH 2/3] pinctrl: mediatek: Add acpi support

[Andy Shevchenko]

On Wed, Nov 26, 2025 at 05:52:59PM +0100, Lorenzo Pieralisi wrote:
> On Wed, Nov 26, 2025 at 10:10:15AM +0100, Linus Walleij wrote:
> > On Tue, Nov 25, 2025 at 3:36 AM Lei Xue <lei.xue@mediatek.com> wrote:
> > 
> > > Add acpi support in the common part of pinctrl driver. Parsing

ACPI

> > > hardware base addresses and irq number to initialize eint

IRQ

> > > accroding to the acpi table data.

ACPI

> > > Signed-off-by: Lei Xue <lei.xue@mediatek.com>
> > 
> > I'd ideally like Andy and the ARM64 ACPI maintainers look on
> > this. (Added to To:) and CC linux-acpi@vger.kernel.org.
> > 
> > I'm not aware of the best way to deal with ACPI in combined drivers
> > but things like this:
> > 
> > > -               hw->base[i] = devm_platform_ioremap_resource_byname(pdev,
> > > -                                       hw->soc->base_names[i]);
> > > +               hw->base[i] = is_of_node(fwnode)
> > > +                       ? devm_platform_ioremap_resource_byname(pdev, hw->soc->base_names[i])
> > > +                       : devm_platform_get_and_ioremap_resource(pdev, i, NULL);
> > 
> > Just look really quirky, I think there are better ways to go about
> > this and sometimes the ACPI maintainers give some good
> > pushback about the firmware as well.

Agree. It looks fragile.
I believe the best approach is to have fwnode_iomap_byname() and if required
add a quirk to have a software node with names.

> How are pdev->resource initialized ? For OF I suppose the names come from
> "reg-names" (that don't exist in ACPI, yet), for ACPI I assume they come
> from a _CRS (and you can't tag them by name for the reason above) ?

We always can hardcode the names if required in quirks via software nodes.
GPIO has even special data types for that (struct acpi_gpio_mapping).

> I assume that in ACPI the _CRS resource order is foolproof against the
> variaty of SOCs this code has to deal with.

Yeah, that's what we have with GPIOs in a few drivers, the hardcoded quirks.

> I also assume/hope that we don't want to add a "reg-names" _DSD property either
> in ACPI to deal with this seamlessly in DT/ACPI (that was done for
> "interrupt-names"):
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/firmware-guide/acpi/enumeration.rst?h=v6.18-rc7#n188

Hmm... Why not?

> I am sorry I have got more questions than answers here - it would be good
> to understand where the line is drawn when it comes to OF/ACPI and fwnode
> heuristics compatibility.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 2/3] pinctrl: mediatek: Add acpi support

[Lorenzo Pieralisi]

On Wed, Nov 26, 2025 at 08:06:51PM +0200, Andy Shevchenko wrote:

[...]

> > I also assume/hope that we don't want to add a "reg-names" _DSD property either
> > in ACPI to deal with this seamlessly in DT/ACPI (that was done for
> > "interrupt-names"):
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/firmware-guide/acpi/enumeration.rst?h=v6.18-rc7#n188
> 
> Hmm... Why not?

What's the policy there ? Half of the ACPI bindings for an interrupt
descriptor are defined in the ACPI specs (ie _CRS) and the other half
(ie "interrupt-names") is documented in the Linux kernel (or are we
documenting this elsewhere ?) ?

Or we are saying that "interrupt-names" properties are added by kernel
code _only_ (through software nodes, to make parsing seamless between DT
and ACPI) based on hardcoded name values in drivers ?

I don't think I can grok any example of the latter in the mainline.

I am asking because I'd need to add something similar shortly to make parsing
of platform devices created out of ACPI static tables easier (I guess we
can postpone discussion till I post the code but I thought I'd ask).

Are we going to do the same for "reg-names" ?

Most importantly, what is DT maintainers stance on the matter ?

Thanks,
Lorenzo

> > I am sorry I have got more questions than answers here - it would be good
> > to understand where the line is drawn when it comes to OF/ACPI and fwnode
> > heuristics compatibility.
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 

Re: [PATCH 2/3] pinctrl: mediatek: Add acpi support

[Andy Shevchenko]

On Thu, Nov 27, 2025 at 11:06:29AM +0100, Lorenzo Pieralisi wrote:
> On Wed, Nov 26, 2025 at 08:06:51PM +0200, Andy Shevchenko wrote:

[...]

> > > I also assume/hope that we don't want to add a "reg-names" _DSD property either
> > > in ACPI to deal with this seamlessly in DT/ACPI (that was done for
> > > "interrupt-names"):
> > > 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/firmware-guide/acpi/enumeration.rst?h=v6.18-rc7#n188
> > 
> > Hmm... Why not?
> 
> What's the policy there ?

> Half of the ACPI bindings for an interrupt
> descriptor are defined in the ACPI specs (ie _CRS) and the other half
> (ie "interrupt-names") is documented in the Linux kernel (or are we
> documenting this elsewhere ?) ?

Yeah, nobody pursued ACPI specification updates / addendum to make it fully
official. _De facto_ we have established practice for GPIOs enumeration
(as most used resources in the OSes), Linux official for PWM, I²C muxes,
multi-functional HW (such as Diolan DLN-2, LJCA), Microsoft defined for
so called "USB hardwired" devices, Linux defined for LEDs and GPIO keys,
sensor mount matrix as per "most used" cases + DT analogue works just
because we have agnostic APIs in IIO to retrieve that. There are maybe
more, but don't remember

So, I think the practical "policies" are that:
- if it's defined in ACPI spec, we use the spec
- if there is Microsoft addendum, we rely on what Windows does
- WMI, EFI, and other "windoze"-like vendor defined cases
- if it makes sense, we establish practice from Linux perspective
- the rest, every vendor does what it does

That said, for the first two we expect OEMs to follow, for the third one
depends, but there are established WMI calls and other more or less "standard"
interfaces, so like the first two.

For the fourth one (Linux) we do, but living in the expectation that some or
more vendors fall to the fifth category and we might need to support that if
we want their HW work in Linux.

> Or we are saying that "interrupt-names" properties are added by kernel
> code _only_ (through software nodes, to make parsing seamless between DT
> and ACPI) based on hardcoded name values in drivers ?

No, the idea behind software nodes is to "fix" the FW nodes in case the FW
description can not be modified (and that might well happen to even DT in some
cases AFAIH). So, if some driver hard codes "interrupt-names" we expect that
new versions of the FW that support the HW that needs the property will be
amended accordingly.

"interrupt-names" has been established for ACPI to support a separate SMB alert
interrupt. However, I haven't heard any development of that IRL (for real
devices in ACPI environment).

> I don't think I can grok any example of the latter in the mainline.
> 
> I am asking because I'd need to add something similar shortly to make parsing
> of platform devices created out of ACPI static tables easier (I guess we
> can postpone discussion till I post the code but I thought I'd ask).

Oh, I can go ahead and tell you, try to avoid that. Why?! Whatever,
indeed, please Cc me to that, I will be glad to study the case and
try to be helpful.

(Have you considered DT overlays instead? There is a big pending support for
 that for _ACPI_ platforms.)

> Are we going to do the same for "reg-names" ?

If it makes sense and we expect some vendor to follow that _in ACPI_,
why not?

> Most importantly, what is DT maintainers stance on the matter ?

AFAIK They don't care as long as there is a schema provided, accepted and
used in DT, if it's ACPI-only thing, then it most likely should be done
in ACPI-like way (see above the first two / three items: spec, MS, WMI/EFI).

> > > I am sorry I have got more questions than answers here - it would be good
> > > to understand where the line is drawn when it comes to OF/ACPI and fwnode
> > > heuristics compatibility.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 2/3] pinctrl: mediatek: Add acpi support

[Lorenzo Pieralisi]

On Thu, Nov 27, 2025 at 04:29:54PM +0200, Andy Shevchenko wrote:
> On Thu, Nov 27, 2025 at 11:06:29AM +0100, Lorenzo Pieralisi wrote:
> > On Wed, Nov 26, 2025 at 08:06:51PM +0200, Andy Shevchenko wrote:
> 
> [...]
> 
> > > > I also assume/hope that we don't want to add a "reg-names" _DSD property either
> > > > in ACPI to deal with this seamlessly in DT/ACPI (that was done for
> > > > "interrupt-names"):
> > > > 
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/firmware-guide/acpi/enumeration.rst?h=v6.18-rc7#n188
> > > 
> > > Hmm... Why not?
> > 
> > What's the policy there ?
> 
> > Half of the ACPI bindings for an interrupt
> > descriptor are defined in the ACPI specs (ie _CRS) and the other half
> > (ie "interrupt-names") is documented in the Linux kernel (or are we
> > documenting this elsewhere ?) ?
> 
> Yeah, nobody pursued ACPI specification updates / addendum to make it fully
> official. _De facto_ we have established practice for GPIOs enumeration
> (as most used resources in the OSes), Linux official for PWM, I²C muxes,
> multi-functional HW (such as Diolan DLN-2, LJCA), Microsoft defined for
> so called "USB hardwired" devices, Linux defined for LEDs and GPIO keys,
> sensor mount matrix as per "most used" cases + DT analogue works just
> because we have agnostic APIs in IIO to retrieve that. There are maybe
> more, but don't remember
> 
> So, I think the practical "policies" are that:
> - if it's defined in ACPI spec, we use the spec
> - if there is Microsoft addendum, we rely on what Windows does
> - WMI, EFI, and other "windoze"-like vendor defined cases
> - if it makes sense, we establish practice from Linux perspective
> - the rest, every vendor does what it does
> 
> That said, for the first two we expect OEMs to follow, for the third one
> depends, but there are established WMI calls and other more or less "standard"
> interfaces, so like the first two.
> 
> For the fourth one (Linux) we do, but living in the expectation that some or
> more vendors fall to the fifth category and we might need to support that if
> we want their HW work in Linux.
> 
> > Or we are saying that "interrupt-names" properties are added by kernel
> > code _only_ (through software nodes, to make parsing seamless between DT
> > and ACPI) based on hardcoded name values in drivers ?
> 
> No, the idea behind software nodes is to "fix" the FW nodes in case the FW
> description can not be modified (and that might well happen to even DT in some
> cases AFAIH). So, if some driver hard codes "interrupt-names" we expect that
> new versions of the FW that support the HW that needs the property will be
> amended accordingly.
> 
> "interrupt-names" has been established for ACPI to support a separate SMB alert
> interrupt. However, I haven't heard any development of that IRL (for real
> devices in ACPI environment).
> 
> > I don't think I can grok any example of the latter in the mainline.
> > 
> > I am asking because I'd need to add something similar shortly to make parsing
> > of platform devices created out of ACPI static tables easier (I guess we
> > can postpone discussion till I post the code but I thought I'd ask).
> 
> Oh, I can go ahead and tell you, try to avoid that. Why?! Whatever,
> indeed, please Cc me to that, I will be glad to study the case and
> try to be helpful.
> 
> (Have you considered DT overlays instead? There is a big pending support for
>  that for _ACPI_ platforms.)

Long story short: we do need to create platform devices out of static
table (eg ARM64 IORT) entries. Current code parses the table entries and
try to map the devices IRQs (ie acpi_register_gsi()) when the platform
device is created. Now, the interrupt controller that device IRQ's is
routed to might not have probed yet. We have to defer probing and later,
when the platform driver probes, map the IRQ.

Issue is: for OF nodes and ACPI devices, behind the platform device
firmware node there is a standard firmware object, so implementing
fwnode_irq_get() is trivial. For the devices I am talking about,
the data providing GSI info (hwirq, trigger/polarity) is static
table specific, so the idea was to stash that data and embed it in
fwnode_static along with a irq_get() fwnode_operations function
specific to that piece of data so that device drivers can actually do:

fwnode_irq_get()

on the fwnode _seamlessly_ (if you still do wonder: those platform
devices created out of static table entries in ACPI in OF are
of_node(s)).

There is a less convoluted solution (that is what some platform
drivers in ACPI do today), that is, we pass the static table
data in pdev->dev.platform_data and each platform_driver parses it differently.

That works but that also means the in the respective device drivers
OF and ACPI IRQ (and MMIO) parsing differ (which is not necessarily
a problem I just have to rewrite them all).

Now - when it comes to "interrupt-names". Some of the device drivers
I mention do:

eg platform_get_irq_byname_optional()

that expects the IRQ to be mapped and stored in a named platform device resource.

That's easy in DT - for two reasons:

(1) "interrupt-names"
(2) standard properties behind the of_node

how to do that for fwnodes that aren't backed by either OF nodes or ACPI
devices (that do use "interrupt-names" _DSD property) is a question.

Mind, the "interrupt-names" thing is a detail in the whole mechanism.

DT overlays to represent in ACPI those static table entries ?

I vividly remember the days ACPI for ARM64 was being merged - that's what
our crystal ball predicted :)

This delayed IRQ mapping notwithstanding, I read what you wrote and took
note. The worry is, this fwnode_*() (on ACPI nodes) interface trickling
into subsystems where it should not (ie PCI, clocks, regulators) - hopefully
the respective maintainers are keeping an eye on it.

Thanks,
Lorenzo

> > Are we going to do the same for "reg-names" ?
> 
> If it makes sense and we expect some vendor to follow that _in ACPI_,
> why not?
> 
> > Most importantly, what is DT maintainers stance on the matter ?
> 
> AFAIK They don't care as long as there is a schema provided, accepted and
> used in DT, if it's ACPI-only thing, then it most likely should be done
> in ACPI-like way (see above the first two / three items: spec, MS, WMI/EFI).
> 
> > > > I am sorry I have got more questions than answers here - it would be good
> > > > to understand where the line is drawn when it comes to OF/ACPI and fwnode
> > > > heuristics compatibility.
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 

Re: [PATCH 3/3] pinctrl: mediatek: mt8901: Add pinctrl driver for MT8901

[AngeloGioacchino Del Regno]

Il 25/11/25 03:36, Lei Xue ha scritto:
> Add mt8901 pinctrl, gpio and eint driver implementation.
> 
> Signed-off-by: Lei Xue <lei.xue@mediatek.com>
> ---
>   drivers/pinctrl/mediatek/Kconfig              |   12 +
>   drivers/pinctrl/mediatek/Makefile             |    1 +
>   drivers/pinctrl/mediatek/mtk-eint.c           |    4 +
>   drivers/pinctrl/mediatek/mtk-eint.h           |    1 +
>   drivers/pinctrl/mediatek/pinctrl-mt8901.c     | 1460 +++++++++++
>   drivers/pinctrl/mediatek/pinctrl-mtk-mt8901.h | 2130 +++++++++++++++++
>   6 files changed, 3608 insertions(+)
>   create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt8901.c
>   create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt8901.h
> 
> diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
> index 4819617d9368..4820ae5197a0 100644
> --- a/drivers/pinctrl/mediatek/Kconfig
> +++ b/drivers/pinctrl/mediatek/Kconfig
> @@ -321,6 +321,18 @@ config PINCTRL_MT8516
>   	default ARM64 && ARCH_MEDIATEK
>   	select PINCTRL_MTK
>   
> +config PINCTRL_MT8901
> +	bool "MediaTek MT8901 pin control"
> +	depends on ACPI
> +	depends on ARM64 || COMPILE_TEST
> +	default ARM64 && ARCH_MEDIATEK
> +	select PINCTRL_MTK_PARIS
> +	help
> +	  Say yes here to support pin controller and gpio driver
> +	  on MediaTek MT8901 SoC.
> +	  In MTK platform, we support virtual gpio and use it to
> +	  map specific eint which doesn't have real gpio pin.
> +
>   # For PMIC
>   config PINCTRL_MT6397
>   	bool "MediaTek MT6397 pin control"
> diff --git a/drivers/pinctrl/mediatek/Makefile b/drivers/pinctrl/mediatek/Makefile
> index ae765bd99965..57c69b1e5c2d 100644
> --- a/drivers/pinctrl/mediatek/Makefile
> +++ b/drivers/pinctrl/mediatek/Makefile
> @@ -43,3 +43,4 @@ obj-$(CONFIG_PINCTRL_MT8196)		+= pinctrl-mt8196.o
>   obj-$(CONFIG_PINCTRL_MT8365)		+= pinctrl-mt8365.o
>   obj-$(CONFIG_PINCTRL_MT8516)		+= pinctrl-mt8516.o
>   obj-$(CONFIG_PINCTRL_MT6397)		+= pinctrl-mt6397.o
> +obj-$(CONFIG_PINCTRL_MT8901)		+= pinctrl-mt8901.o
> diff --git a/drivers/pinctrl/mediatek/mtk-eint.c b/drivers/pinctrl/mediatek/mtk-eint.c
> index c8c5097c11c4..b5a5beebf9cd 100644
> --- a/drivers/pinctrl/mediatek/mtk-eint.c
> +++ b/drivers/pinctrl/mediatek/mtk-eint.c
> @@ -71,6 +71,10 @@ const unsigned int debounce_time_mt6878[] = {
>   };
>   EXPORT_SYMBOL_GPL(debounce_time_mt6878);
>   
> +const unsigned int debounce_time_mt8901[] = {
> +	156, 313, 625, 1250, 20000, 40000, 80000, 160000, 320000, 640000, 0};
> +EXPORT_SYMBOL_GPL(debounce_time_mt8901);
> +
>   static void __iomem *mtk_eint_get_offset(struct mtk_eint *eint,
>   					 unsigned int eint_num,
>   					 unsigned int offset)
> diff --git a/drivers/pinctrl/mediatek/mtk-eint.h b/drivers/pinctrl/mediatek/mtk-eint.h
> index 3cdd6f6310cd..1b185f660aff 100644
> --- a/drivers/pinctrl/mediatek/mtk-eint.h
> +++ b/drivers/pinctrl/mediatek/mtk-eint.h
> @@ -53,6 +53,7 @@ extern const unsigned int debounce_time_mt2701[];
>   extern const unsigned int debounce_time_mt6765[];
>   extern const unsigned int debounce_time_mt6795[];
>   extern const unsigned int debounce_time_mt6878[];
> +extern const unsigned int debounce_time_mt8901[];
>   
>   struct mtk_eint;
>   
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8901.c b/drivers/pinctrl/mediatek/pinctrl-mt8901.c
> new file mode 100644
> index 000000000000..77dec85fe29b
> --- /dev/null
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt8901.c
> @@ -0,0 +1,1460 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2025 MediaTek Inc.
> + *
> + */
> +
> +#include <linux/acpi.h>
> +#include <linux/module.h>
> +#include "pinctrl-mtk-mt8901.h"
> +#include "pinctrl-paris.h"
> +

..snip..

> +static const char * const mt8901_pinctrl_register_base_name[] = {
> +	"iocfg0", "iocfg_lt2", "iocfg_lt3", "iocfg_rt1", "iocfg_rt2", "iocfg_rt3",
> +	"iocfg_tr", "iocfg_rt0", "iocfg_lt1", "iocfg_lb", "iocfg_rb",
> +};
> +
> +static const struct mtk_eint_hw mt8901_eint_hw = {
> +	.port_mask = 0xf,
> +	.ports     = 7,
> +	.ap_num    = 209,
> +	.db_cnt    = 32,
> +	.db_time   = debounce_time_mt8901,
> +};
> +
> +static const struct mtk_pin_soc mt8901_data = {
> +	.reg_cal = mt8901_reg_cals,
> +	.pins = mtk_pins_mt8901,
> +	.npins = ARRAY_SIZE(mtk_pins_mt8901),
> +	.ngrps = ARRAY_SIZE(mtk_pins_mt8901),
> +	.eint_hw = &mt8901_eint_hw,
> +	.eint_pin = eint_pins_mt8901,
> +	.nfuncs = 8,
> +	.gpio_m = 0,
> +	.base_names = mt8901_pinctrl_register_base_name,
> +	.nbase_names = ARRAY_SIZE(mt8901_pinctrl_register_base_name),
> +	.pull_type = mt8901_pull_type,
> +	.pin_rsel = mt8901_pin_rsel_val_range,
> +	.npin_rsel = ARRAY_SIZE(mt8901_pin_rsel_val_range), /*numsel*/
> +	.bias_set_combo = mtk_pinconf_bias_set_combo,
> +	.bias_get_combo = mtk_pinconf_bias_get_combo,
> +	.drive_set = mtk_pinconf_drive_set_rev1,
> +	.drive_get = mtk_pinconf_drive_get_rev1,
> +	.adv_drive_set = mtk_pinconf_adv_drive_set_raw,
> +	.adv_drive_get = mtk_pinconf_adv_drive_get_raw,
> +};
> +
> +static const struct acpi_device_id mt8901_pinctrl_acpi_match[] = {
> +	{"NVDA9221", (kernel_ulong_t)&mt8901_data },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(acpi, mt8901_pinctrl_acpi_match);
> +
> +static struct platform_driver mt8901_pinctrl_driver = {
> +	.driver = {
> +		.name = "mt8901-pinctrl",
> +		.acpi_match_table = ACPI_PTR(mt8901_pinctrl_acpi_match),

Please also add support for devicetree - I have a hunch (and I'm sure that I am
not the only one) that ACPI may give some issues at the end of the day, on ARM64.

Of course, I'd hope that ACPI is all good on this platform, but still.... :-)

static const struct of_device_id mt8901_pinctrl_of_match[] = {
	{ .compatible = "mediatek,mt8901-pinctrl", .data = &mt8901_data },
	{ /* sentinel */ }
};

	.of_match_table = mt8901_pinctrl_of_match,

> +		.pm = pm_sleep_ptr(&mtk_paris_pinctrl_pm_ops)
> +	},
> +	.probe = mtk_paris_pinctrl_probe,
> +};

Cheers,
Angelo

> +
> +static int __init mt8901_pinctrl_init(void)
> +{
> +	return platform_driver_register(&mt8901_pinctrl_driver);
> +}
> +
> +arch_initcall(mt8901_pinctrl_init);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("MediaTek MT8901 Pinctrl Driver");