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

[Lorenzo Pieralisi]

On Mon, Oct 26, 2026 at 10:20:37AM +0530, Sunil V L wrote:
> On Thu, Oct 22, 2026 at 4:18 PM Rafael J. Wysocki (Intel)
> <rafael@xxxxxxxxxx> wrote:
> >
> > On Thu, Oct 22, 2026 at 8:43 AM Lorenzo Pieralisi <lpieralisi@xxxxxxxxxx> wrote:
> > >
> > > On Wed, Oct 21, 2026 at 12:18:39PM +0100, Robin Murphy wrote:
> > > > 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...
> > >
> > > I agree with you (but that's what we do for ACPI autodep and AFAICS OF
> > > devlinks - though there there might be opt-outs).
> > >
> > > To make -EPROBE_DEFER work I have to pursue the approach undertaken in this
> > > set and apply requested changes - I don't see any other way.
> > >
> > > Are we willing to accept the approach taken in this patchset (I can remove
> > > software nodes and make the whole thing ACPI static nodes self-contained) ?
> > >
> > > One way or another this ought to be sorted, please all let me know your
> > > take on this.
> >
> > Please make it as simple as reasonably possible. :-)
> >
> For this use case, where platform devices are created from static ACPI
> tables, I think adding fw_devlink support to ACPI is a much simpler
> approach. I proposed this in [1] as a generic solution, but we later
> realized that it doesn't work well for cases where dependencies need
> to be established very early (_DEP/autodep worked better for such use
> cases). That limitation should not apply to this particular use case,
> though. So I wonder if a combination of autodep and fw_devlink will be
> a better solution?
> 
> [1] - https://lists.infradead.org/pipermail/linux-riscv/2023-December/046146.html

Not sure and actually the point here is about opting in for using
-EPROBE_DEFER in consumer drivers (so that they have a choice on probe
deferral rather than being deferred behind their back).

I implemented devlink supports for these platform devices but I don't
think it is best way forward - given this discussion.

Thanks,
Lorenzo