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

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Tue, Oct 20, 2026 at 05:30:00PM +0200, Lorenzo Pieralisi wrote:
> 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.

Don't we do something similar in drivers/acpi/x86/lpss.c?

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

-- 
With Best Regards,
Andy Shevchenko