On Thu, 06 Jun 2024 20:11:23 +0200 Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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é
