Re: [PATCH RFC 02/11] ACPI: Introduce irq_get() for static fwnodes

[Lorenzo Pieralisi <lpieralisi@kernel.org>]

On Mon, Oct 19, 2026 at 08:05:50PM +0200, Rafael J. Wysocki (Intel) wrote:
> On Mon, Oct 19, 2026 at 12:34 PM Lorenzo Pieralisi
> <lpieralisi@kernel.org> wrote:

[...]

> Basically, yes, the idea is to defer the creation of the platform
> device until the dependency is met.
> 
> > till the dependencies are cleared but then, without a _CRS, where will
> > the consumer driver find the platform device resources ?
> 
> Well, good question.
> 
> > There are multiple facets in this issue and possibly some of them have
> > been already solved but I need to pull them together.
> >
> > > Note that the dependencies can be added to acpi_dep_list after
> > > creating a struct acpi_device with acpi_add_single_object() and
> > > acpi_scan_add_dep() is not really suitable for that, but it should be
> > > doable if the dependencies can be found.
> > >
> > > > I need to have a deeper look into this next week but I wanted to ask first
> > > > whether there was something I missed - most likely.
> > >
> > > Well, it is not really straightforward.
> >
> > Yes it is getting messy. This RFC, with all its flaws, does not transparently
> > prevents enumeration but rather relies on -EPROBE_DEFER to sort out
> > dependencies - though it does so by adding more stuff into ACPI static fwnode
> > that to be honest I'd rather see gone.
> 
> I think what you need is a notification mechanism that will trigger
> when a specific device (enumerated via the ACPI Namespace) becomes
> operational.  It doesn't look like any of the existing ones (platform
> device probe deferral or ACPI device dependencies tracking) is really
> suitable for your use case.

Yes. It might just be a notification from ACPI core to say "the driver for
this ACPI device probed, go create platform devices that depends on it".

We can check and track the dependency in code that does create those
devices today.

I will think about this to see how bad this might look like.

> > > I'm still not sure why you can't represent all devices in the ACPI
> > > namespace in addition to describing some of them in static tables.  I
> > > guess that would work for everybody, wouldn't it?
> >
> > That's a fair point - though then code will have to work with firmware
> > that does NOT explicitly require those devices in the namespace (ie: firmware
> > as it is specified _now_); it can turn out to be a mess even less
> > manageable than this discussion ;-)
> 
> If it has to work under these conditions anyway, then adding stuff to
> the namespace is rather pointless.

Yes that's the problem, reworking the code to make it work with namespace
devices is doable the issue is existing firmware and that we can't change it
(and we can't create it in the kernel either).

Thanks,
Lorenzo