On Wed, Jun 28, 2023 at 10:31:57AM +0200, Patrick Wildt wrote: > On Wed, Jun 28, 2023 at 08:47:00AM +0200, Johan Hovold wrote: > > My point is that it's apparently not just Linux as most devicetrees work > > this way at least for the root domain. And then it may be time to update > > the spec in some way. > > I'm not sure about the point you're trying to make. In OpenBSD's > implementation, which I think complies with the spec, for non-extended > interrupts we check the node's (or all its parents') interrupt-parent > property. My point is that that is not compliant with the spec either which only says that in case 'interrupt-parent' is missing in a node for an interrupt-generating device, then the interrupt parent is assumed to be the devicetree parent (which must then also be an interrupt controller or nexus). There is no provision for any recursive lookup in the spec currently. > Technically the SPMI arbiter could define an interrupt-parent that > points to itself, because it's using interrupts-extended anyway to > point to the PDC. But that would feel a bit stupid and not really > correct. Alternatively each child node could have interrupt-parent. I agree that that would not really be correct (e.g. as 'interrupt' and 'interrupt-extended' are supposed to be mutually exclusive). > That said, I understand the point that it might make sense to amend > the spec so that if a parent node is an interrupt-controller, that's > most probably interrupt parent, This bit is already in the spec. > unless an interrupt-parent property > shows up before. But this seems to suggest that you really meant to say "ancestor" in the first clause? > I would like to add that OpenBSD supports a number of SoCs for quite > some years and this is the first time I've hit an issue with interrupts > that were not designed in a way for the current spec to work. That said > we obviously support quite fewer SoCs/boards in total compared to Linux. So OpenBSD apparently implements something similar to Linux (recursive lookup of 'interrupt-parent' properties), but not the part about stopping the recursion when hitting an interrupt controller. Neither part appears to be spec compliant, but you only care about updating DTs that do not comply to the latter bit. That seems reasonable and should importantly not require adding tens of thousands of 'interrupt-parent' properties to the DTs in mainline. Johan
