public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Patrick Wildt <patrick@blueri.se>
Cc: Manivannan Sadhasivam <mani@kernel.org>,
	Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	Johan Hovold <johan+linaro@kernel.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Andy Gross <agross@kernel.org>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Mark Kettenis <kettenis@openbsd.org>
Subject: Re: [PATCH] arm64: dts: qcom: sc8280xp-pmics: add explicit rtc interrupt parent
Date: Thu, 29 Jun 2023 16:29:34 +0200	[thread overview]
Message-ID: <ZJ2VTjm-JaGfskl5@hovoldconsulting.com> (raw)
In-Reply-To: <ZJvv_bcum7nhrgrO@mone.fritz.box>

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

  parent reply	other threads:[~2023-06-29 14:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-27  8:53 [PATCH] arm64: dts: qcom: sc8280xp-pmics: add explicit rtc interrupt parent Johan Hovold
2023-06-27 10:43 ` Konrad Dybcio
2023-06-27 13:24 ` Manivannan Sadhasivam
2023-06-27 15:27   ` Johan Hovold
2023-06-28  5:25     ` Manivannan Sadhasivam
2023-06-28  6:47       ` Johan Hovold
2023-06-28  8:31         ` Patrick Wildt
2023-06-28 11:15           ` Konrad Dybcio
2023-06-29 14:29           ` Johan Hovold [this message]
2023-07-10  5:07 ` Bjorn Andersson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZJ2VTjm-JaGfskl5@hovoldconsulting.com \
    --to=johan@kernel.org \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=johan+linaro@kernel.org \
    --cc=kettenis@openbsd.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mani@kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=patrick@blueri.se \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox