linux-kernel - Re: Issues with OF_DYNAMIC PCI bridge node generation (kmemleak/interrupt-map IC reg property)

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAL_Jsq+tPM7+W9u1k6Gf9_vzB2na_0kBMxN4O3FtTxub7GK_xw@mail.gmail.com>
Date: Tue, 12 Aug 2025 12:04:49 -0500
From: Rob Herring <robh@...nel.org>
To: Lorenzo Pieralisi <lpieralisi@...nel.org>
Cc: Lizhi Hou <lizhi.hou@....com>, maz@...nel.org, devicetree@...r.kernel.org, 
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Issues with OF_DYNAMIC PCI bridge node generation
 (kmemleak/interrupt-map IC reg property)

On Tue, Aug 12, 2025 at 11:17 AM Lorenzo Pieralisi
<lpieralisi@...nel.org> wrote:
>
> On Tue, Aug 12, 2025 at 08:53:06AM -0700, Lizhi Hou wrote:
> >
> > On 8/12/25 00:42, Lorenzo Pieralisi wrote:
> > > On Mon, Aug 11, 2025 at 08:26:11PM -0700, Lizhi Hou wrote:
> > > > On 8/11/25 01:42, Lorenzo Pieralisi wrote:
> > > >
> > > > > Hi Lizhi, Rob,
> > > > >
> > > > > while debugging something unrelated I noticed two issues
> > > > > (related) caused by the automatic generation of device nodes
> > > > > for PCI bridges.
> > > > >
> > > > > GICv5 interrupt controller DT top level node [1] does not have a "reg"
> > > > > property, because it represents the top level node, children (IRSes and ITSs)
> > > > > are nested.
> > > > >
> > > > > It does provide #address-cells since it has child nodes, so it has to
> > > > > have a "ranges" property as well.
> > > > >
> > > > > You have added code to automatically generate properties for PCI bridges
> > > > > and in particular this code [2] creates an interrupt-map property for
> > > > > the PCI bridges (other than the host bridge if it has got an OF node
> > > > > already).
> > > > >
> > > > > That code fails on GICv5, because the interrupt controller node does not
> > > > > have a "reg" property (and AFAIU it does not have to - as a matter of
> > > > > fact, INTx mapping works on GICv5 with the interrupt-map in the
> > > > > host bridge node containing zeros in the parent unit interrupt
> > > > > specifier #address-cells).
> > > > Does GICv5 have 'interrupt-controller' but not 'interrupt-map'? I think
> > > > of_irq_parse_raw will not check its parent in this case.
> > > But that's not the problem. GICv5 does not have an interrupt-map,
> > > the issue here is that GICv5 _is_ the parent and does not have
> > > a "reg" property. Why does the code in [2] check the reg property
> > > for the parent node while building the interrupt-map property for
> > > the PCI bridge ?
> >
> > Based on the document, if #address-cells is not zero, it needs to get parent
> > unit address. Maybe there is way to get the parent unit address other than
> > read 'reg'?
>
> Reading the parent "reg" using the parent #address-cells as address size does
> not seem correct to me anyway.

Right, the parent #address-cells applies to reg/ranges(parent addr) in
the child node.

> > Or maybe zero should be used as parent unit address if 'reg' does not
> > exist?
>
> zeros are used for eg GICv3 interrupt-map properties, I suppose that's
> a wild card to say "any device in the interrupt-controller bus",
> whatever that means.
>
> Just my interpretation, I don't know the history behind this.

They should be zero simply because a device's address never has any
influence with a device's interrupt connection to a GIC (or any SoC
interrupt controller).

Rob