On Wed, 08 Nov 2023 09:53:14 +0000, Sunil V L <sunilvl@xxxxxxxxxxxxxxxx> wrote: > > That's partly correct. APLIC platform devices are created prior to PCI > host bridges added. But the actual APLIC driver which creates the > irqdomain will be probed as a regular platform driver for the APLIC > device. The platform driver probe will happen using DD framework and > devices don't have any dependency on APLIC which can cause device probe > prior to APLIC driver probe. > > DT supports fw_devlink framework which makes it easier for IRQ devices > to use regular platform drivers and produces-consumers are probed in the > order without requiring drivers to do deferred probe. But I don't see > that supported for ACPI framework. Also, the way PNP devices get added > there is an assumption that interrupt controller is already setup fully. > > With this new use case in RISC-V, here are the alternatives I am aware of. > > 1) Use core_initcall() in the APLIC drivers which makes APLIC driver to > be probed prior to PNP or PCI INTx devices. But this was ruled out in > the context of DT from Marc. > > 2) Like the approach tried in this series, add support for deferred > probe in drivers. This will be invasive change requiring many drivers to > change like you pointed. > > I don't know which is less evil or if there is any other alternative > which I am not aware of. > > Thomas/Marc, could you allow APLIC (and PLIC) irqchip drivers to use > core_initcall() for ACPI? I don't have a say about this anymore, so this is only a passing comment, which you are free to cast aside. My personal view is that if you need to rely on core_initcall() for a particular firmware interface, then your architecture will end-up being an unmaintainable ball of hacks, with conflicting requirements and increasingly diverging behaviours. Those who had the 'privilege' to deal with the 32bit ARM transition to DT will understand what I mean. Having to rely on initcalls can only mean two things: - you're missing crucial topology information that will eventually bite you where it hurts, and you're better off going back to the drawing board to fix it before any HW ships, - you're not making use of the kernel's dependency management infrastructure, which is pretty sad. Yes, it is DT specific for now, but nothing prevents you from improving it to make it grok another firmware interface. But as I said, I don't have much skin in that game anymore. M. -- Without deviation from the norm, progress is not possible.
