linux-kernel - Re: [PATCH v3 3/9] PCI: of_property: Restore the arguments of the next level 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: <zvyro2dl7hqproym4shawsckorhlcfkyucponfvw2qrbc44zb2@3kg2eaab42rj>
Date: Sat, 30 Aug 2025 09:40:22 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Claudiu Beznea <claudiu.beznea@...on.dev>
Cc: bhelgaas@...gle.com, lpieralisi@...nel.org, kwilczynski@...nel.org, 
	robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org, geert+renesas@...der.be, 
	magnus.damm@...il.com, catalin.marinas@....com, will@...nel.org, 
	mturquette@...libre.com, sboyd@...nel.org, p.zabel@...gutronix.de, lizhi.hou@....com, 
	linux-pci@...r.kernel.org, linux-renesas-soc@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, linux-clk@...r.kernel.org, 
	Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
Subject: Re: [PATCH v3 3/9] PCI: of_property: Restore the arguments of the
 next level parent

On Thu, Aug 21, 2025 at 10:40:40AM GMT, Claudiu Beznea wrote:
> Hi, Manivannan,
> 
> On 20.08.2025 20:47, Manivannan Sadhasivam wrote:
> > On Fri, Jul 04, 2025 at 07:14:03PM GMT, Claudiu wrote:
> >> From: Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
> >>
> >> of_pci_make_dev_node() creates a device tree node for the PCIe bridge it
> >> detects. The node name follows the format: pci_type@..._slot,pci_func. If
> >> such a node already exists in the current device tree, a new one is not
> >> created.
> >>
> >> When the node is created, its contents are populated with information from
> >> the parent node. In the case of root complex nodes described in the device
> >> tree, the created node duplicates the interrupt-map property. However, the
> >> duplicated interrupt-map property does not correctly point to the next
> >> interrupt controller.
> >>
> >> For example, in the case of the Renesas RZ/G3S SoC, the resulting device
> >> tree node is as follows (only relevant DT properties are shown):
> >>
> >> pcie@...40000 {
> >>
> >>     // ...
> >>
> >>     interrupt-map = <0x00 0x00 0x00 0x01 0x1f 0x00 0x00 0x00 0x00
> >>                      0x00 0x00 0x00 0x02 0x1f 0x00 0x00 0x00 0x01
> >>                      0x00 0x00 0x00 0x03 0x1f 0x00 0x00 0x00 0x02
> >>                      0x00 0x00 0x00 0x04 0x1f 0x00 0x00 0x00 0x03>;
> >>     interrupt-map-mask = <0x00 0x00 0x00 0x07>;
> >>     interrupt-controller;
> >>     #interrupt-cells = <0x01>;
> >>
> >>     #address-cells = <0x03>;
> >>     #size-cells = <0x02>;
> >>
> >>     phandle = <0x1f>;
> >>
> >>     // ...
> >>
> >>     pci@0,0 {
> >>         reg = <0x00 0x00 0x00 0x00 0x00>;
> >>         interrupt-map = <0x10000 0x00 0x00 0x01 0x1f 0x00 0x11e40000 0x00 0x00
> >>                          0x10000 0x00 0x00 0x02 0x1f 0x00 0x11e40000 0x00 0x01
> >>                          0x10000 0x00 0x00 0x03 0x1f 0x00 0x11e40000 0x00 0x02
> >>                          0x10000 0x00 0x00 0x04 0x1f 0x00 0x11e40000 0x00 0x03>;
> >>         interrupt-map-mask = <0xffff00 0x00 0x00 0x07>;
> >>         #interrupt-cells = <0x01>;
> >>
> >>         #address-cells = <0x03>;
> >>         #size-cells = <0x02>;
> >>
> >>         // ...
> >>     };
> >> };
> >>
> >> With this pci@0,0 node, the interrupt-map parsing code behaves as follows:
> >>
> >> When a PCIe endpoint is enumerated and it requests to map a legacy
> >> interrupt, of_irq_parse_raw() is called requesting the interrupt from
> >> pci@0,0. If INTA is requested, of_irq_parse_raw() first matches:
> >>
> >> interrupt-map = <0x10000 0x00 0x00 0x01 0x1f 0x00 0x11e40000 0x00 0x00>
> >>
> >> from the pci@0,0 node. It then follows the phandle 0x1f to the interrupt
> >> parent, looking for a mapping for interrupt ID 0x00
> >> (0x00 0x11e40000 0x00 0x00). However, the root complex node does not
> >> provide this mapping in its interrupt-map property, causing the interrupt
> >> request to fail.
> >>
> > 
> > Are you trying to say that the generated bridge node incorrectly uses Root
> > Complex node as the interrupt parent?
> 
> I'm trying to say that the generated bridge node is wrong because it copies
> the interrupt-map from the root complex mapping int 0x1 to 0x0 in the
> bridge node, while it should have map the int 0x1 to something valid for
> root complex mapping.
> 
> E.g. when some device requests INT with id 0x1 from bridge the bridge
> mapping returns 0x0 then the returned 0x0 is used to find a new mapping on
> the root complex based on what is provided for in with interrupt-map DT
> property.
> 

TBH, I don't know why it generates the 'interrupt-map' property for the bridge
node first place. It just creates two level lookup and in the absence, the IRQ
code will traverse up the node to find the interrupt parent anyway.

Maybe the intention was to avoid doing the traversal.

> 
> > 
> > I'm getting confused since your example above shows '0x1f' as the interrupt
> > parent phandle for both Root Complex and bridge nodes. But I don't know to which
> > node this phandle corresponds to.
> 
> Root complex node from this patch description has:
> 
> phandle = <0x1f>;
> 

Oops. I failed to spot it.

- Mani

-- 
மணிவண்ணன் சதாசிவம்