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

[Lorenzo Pieralisi <lpieralisi@kernel.org>]

On Fri, Apr 17, 2026 at 09:26:31AM +0300, Andy Shevchenko wrote:
> On Thu, Nov 27, 2025 at 04:53:55PM +0100, Lorenzo Pieralisi wrote:
> > 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).
> 
> Hmm... The parsing inside drivers is quite a custom case. I would avoid doing
> it if it's not device specific (I mean if it's not related to the very unique
> device or family of the devices which most likely won't appear again in the
> future). In other words, I prefer agnostic solutions over custom ones.
> 
> > 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 :)
> 
> So, the idea is to translate ACPI static table entries (which comes from IORT)
> to the IRQ fwnodes at initialisation (parsing) time?

They don't come from IORT only but that does not matter much. The point is,
we have got to have a standard way for device drivers to retrieve a HW
IRQ number for devices created out of static tables (and only code that
knows what a static table represents can initialize such fwnodes because
the interrupt fields are different in different static tables).

Lorenzo

> > 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.
> > 
> > > > 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
> 
>