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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aScwaxBG53dnZ4a4@lpieralisi>
Date: Wed, 26 Nov 2025 17:52:59 +0100
From: Lorenzo Pieralisi <lpieralisi@...nel.org>
To: Linus Walleij <linusw@...nel.org>
Cc: Lei Xue <lei.xue@...iatek.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.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

[+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@...iatek.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@...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.

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