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

[Herve Codina]

On Thu, 06 Jun 2024 20:11:23 +0200
Thomas Gleixner <tglx at linutronix.de> wrote:

> Herve!
> 
> On Thu, Jun 06 2024 at 17:52, Herve Codina wrote:
> > On Wed, 05 Jun 2024 15:02:46 +0200
> > Thomas Gleixner <tglx at linutronix.de> wrote:  
> >> On Mon, May 27 2024 at 18:14, Herve Codina wrote:  
> >> > 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?

Yes, EPROBE_DEFER mecanism.
The race condition window leads to an other error code instead of the
expected EPROBE_DEFER.

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

Will do that.

Best regards,
Hervé