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

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] [day] [month] [year] [list]

Message-ID: <aSdBu-B9mwU2-1_S@smile.fi.intel.com>
Date: Wed, 26 Nov 2025 20:06:51 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Lorenzo Pieralisi <lpieralisi@...nel.org>
Cc: Linus Walleij <linusw@...nel.org>, Lei Xue <lei.xue@...iatek.com>,
	Hanjun Guo <guohanjun@...wei.com>,
	Sudeep Holla <sudeep.holla@....com>,
	Sean Wang <sean.wang@...nel.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Matthias Brugger <matthias.bgg@...il.com>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	linux-kernel@...r.kernel.org, linux-mediatek@...ts.infradead.org,
	linux-gpio@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	yong.mao@...iatek.com, qingliang.li@...iatek.com,
	Fred-WY.Chen@...iatek.com, ot_cathy.xu@...iatek.com,
	ot_shunxi.zhang@...iatek.com, ot_yaoy.wang@...iatek.com,
	ot_ye.wang@...iatek.com, linux-acpi@...r.kernel.org,
	robh@...nel.org
Subject: Re: [PATCH 2/3] pinctrl: mediatek: Add acpi support

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