[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 at 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 at mediatek.com>
> > 
> > I'd ideally like Andy and the ARM64 ACPI maintainers look on
> > this. (Added to To:) and CC linux-acpi at 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