Re: [PATCH v2 10/19] irqdomain: Introduce irq_domain_alloc() and irq_domain_publish()

Herve!

On Thu, Jun 06 2024 at 17:52, Herve Codina wrote:

On Wed, 05 Jun 2024 15:02:46 +0200
Thomas Gleixner [off-list ref] wrote:

quoted

On Mon, May 27 2024 at 18:14, Herve Codina wrote:

quoted

To avoid a window where the domain is published but not yet ready to be  

I can see the point, but why is this suddenly a problem? There are tons
of interrupt chip drivers which have exactly that pattern.

I thing the issue was not triggered because these interrupt chip driver
are usually builtin compiled and the probe sequence is the linear one
done at boot time. Consumers/supplier are probe sequentially without any
parallel execution issues.

In the LAN966x PCI device driver use case, the drivers were built as
modules. Modules loading and drivers .probe() calls for the irqs supplier
and irqs consumers are done in parallel. This reveals the race condition.

So how is that supposed to work? There is clearly a requirement that the
interrupt controller is ready to use when the network driver is probed, no?

quoted

Also why is all of this burried in a series which aims to add a network
driver and touches the world and some more. If you had sent the two irq
domain patches seperately w/o spamming 100 people on CC then this would
have been solved long ago. That's documented clearly, no?

Yes, the main idea of the series, as mentioned in the cover letter, is to
give the big picture of the LAN966x PCI device use case in order to have
all the impacted subsystems and drivers maintainers be aware of the global
use case: DT overlay on top of PCI device.
Of course, the plan is to split this series into smaller ones once parts
get discussed in the DT overlay on top of PCI use case and reach some kind
of maturity at least on the way to implement a solution.

Fair enough.

Thomas, do you prefer to have all the IRQ related patches extracted right
now from this big picture series ?

I think the interrupt controller problem is completely orthogonal to the
PCI/DT issue.

So yes, please split them out as preparatory work which is probably also
not that interesting for the PCI/DT/net folks.

If the template approach holds, then the infrastructure change is
definitely worth it on its own and the actual driver just falls in place
and is off your backlog list.

Thanks,

        tglx