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

[Johan Hovold]

On Wed, Jun 28, 2023 at 10:55:57AM +0530, Manivannan Sadhasivam wrote:
> On Tue, Jun 27, 2023 at 05:27:32PM +0200, Johan Hovold wrote:
> > On Tue, Jun 27, 2023 at 06:54:06PM +0530, Manivannan Sadhasivam wrote:
> > > On Tue, Jun 27, 2023 at 10:53:06AM +0200, Johan Hovold wrote:
> > > > Unless explicitly specified the interrupt-parent property is inherited
> > > > from the parent node on Linux even though this may not be in full
> > > > compliance with the devicetree specification.
> > > > 
> > > > Following commit 2d5cab9232ba ("arm64: dts: qcom: sc8280xp-pmics:
> > > > Specify interrupt parent explicitly"), add an explicit interrupt parent
> > > > also for the PMIC RTC node for the benefit of other operating systems
> > > > which may be confused by this omission.
> > > > 
> > > > Note that any such OS must still implement a fallback to the root
> > > > interrupt domain as most devicetrees are written under the assumption
> > > > that the interrupt parent is inherited.
> > > > 
> > > > Reported-by: Patrick Wildt <patrick@xxxxxxxxx>
> > > > Signed-off-by: Johan Hovold <johan+linaro@xxxxxxxxxx>
> > > 
> > > It is good to encode this in the binding and fix other such instances.
> > 
> > Not sure about that. Perhaps the spec should be updated to match reality
> > instead... We have many more instances like this, even for this very
> > SoC, but apparently OpenBSD or whatever OS needs this falls back to the
> > root domain then.
> > 
> 
> Just because linux is doing it in a different way doesn't warrant an amendment
> to the spec IMO.

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.
 
> > Changing this for the rtc node for consistency after you changed the
> > others is a no-brainer, but not sure about trying to do this tree-wide.
> > We already have too many of these one-line DT cleanups...
> > 
> 
> I agree that this is going to be a one-line cleanup but someone has to do it.
> (not asking you to do since I also skipped it during 2d5cab9232ba). We can put
> it in the back burner.

So that may actually amount to a ten-thousand line diff or so... And
then it's probably better to just update the spec.

Johan