linux-kernel - Re: [PATCH] arm64: dts: qcom: sc8280xp-pmics: add explicit rtc interrupt parent

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZJ2VTjm-JaGfskl5@hovoldconsulting.com>
Date:   Thu, 29 Jun 2023 16:29:34 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Patrick Wildt <patrick@...eri.se>
Cc:     Manivannan Sadhasivam <mani@...nel.org>,
        Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        Johan Hovold <johan+linaro@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Andy Gross <agross@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, Mark Kettenis <kettenis@...nbsd.org>
Subject: Re: [PATCH] arm64: dts: qcom: sc8280xp-pmics: add explicit rtc
 interrupt parent

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