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

[Robin Murphy]

On 2026-10-21 10:06 am, Lorenzo Pieralisi wrote:
> On Wed, Oct 21, 2026 at 09:58:33AM +0300, Andy Shevchenko wrote:
> > 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@xxxxxxxxxx> 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 suppose I can add a notifier that checks whether the device whose
> companion represents the ACPI device a given platform device IRQ depends
> on was bound to its driver and then map the IRQ and add the platform device
> _then_ - after all that's what acpi_dev_clear_dependencies() does (similar
> at least).
>
> There is still the question - where the GSI number, flags should be
> stashed so that the notifier can grab them in a uniform way. We
> could simply attach platform data storing those values to a pdev, either on
> a per static table basis or generalize the data so that a single notifier
> would be able to deal with it.
>
> That or I can just piggyback on acpi_dev_clear_dependencies() and add
> a separate dep mechanism to acpi_dep_data that instead of being acpi_handle
> based the consumer is fwnode based (something Rafael mentioned before).
>
> I will have a stab at this and see what's the least bad solution I can
> come up with.
>
> I suppose we are scrapping the -EPROBE_DEFER solution (ie this set),
> what we are talking about above won't need to defer anything other
> than the time when platform devices are added.

I dunno, that seems pretty drastic for some use-cases - the fact that a 
GSI is described in a table doesn't necessarily mean it is critical to 
device operation. If we don't even create the device until all possible 
resources are available, then its driver never has any chance to decide 
whether it's happy to ignore the deferral and just use MSIs or polling 
instead...

Thanks,
Robin.