All of lore.kernel.org
 help / color / mirror / Atom feed
From: Herve Codina <herve.codina@bootlin.com>
To: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Cc: "robh+dt@kernel.org" <robh+dt@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Danilo Krummrich <dakr@kernel.org>,
	Saravana Kannan <saravanak@google.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Lizhi Hou <lizhi.hou@amd.com>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	linux-pci@vger.kernel.org,
	Allan Nielsen <allan.nielsen@microchip.com>,
	Horatiu Vultur <horatiu.vultur@microchip.com>,
	Steen Hegelund <steen.hegelund@microchip.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH v8 5/5] PCI: of: Create device-tree PCI host bridge node
Date: Tue, 17 Jun 2025 09:00:29 +0200	[thread overview]
Message-ID: <20250617090029.03283ea6@bootlin.com> (raw)
In-Reply-To: <3258d453-f262-4f1c-822b-5310a8346a2d@tuxon.dev>

Hi Claudiu,

On Fri, 13 Jun 2025 16:36:16 +0300
Claudiu Beznea <claudiu.beznea@tuxon.dev> wrote:

...

> I pointed to the wrong function. It's not of_pci_make_host_bridge_node()
> [1] but of_pci_make_dev_node() which creates a node with a similar naming
> and makes things not working on my side.
> 
> [1] https://elixir.bootlin.com/linux/v6.15/source/drivers/pci/of.c#L694

Ok, so your issue is not related patches applied from the "PCI: of: Create
device-tree PCI host bridge node" series.
  https://lore.kernel.org/all/20250224141356.36325-6-herve.codina@bootlin.com/

Indeed, this series add the node creation for the host bridge with
of_pci_make_host_bridge_node() but you pointed now of_pci_make_dev_node()
which is the creation for PCI device node and this function was not modify by the
series.

of_pci_make_host_bridge_node() should not create anything. Can you confirm on your
side that it doesn't create any nodes.

If so, maybe the problem comes from of_irq_parse_raw() or similar.

...

> 
> > 
> > On this system, I didn't observed any issues but of course, the PCIe drivers are
> > different.
> > Also, on my system, no node were created by of_pci_make_host_bridge_node().  
> 
> Sorry for the confusion, it is of_pci_make_dev_node() on my side which
> creates the node.
> 
> > 
> > To be honest, I didn't re-test recently to see if something has been broken.
> > I can do that on my side with my system.

I have re-tested and I confirm that I have no issue on my system.

> > 
> > On your side, maybe you can have look at the Armada PCIe driver and see if
> > something could explain your behavior. I am not sure that you need to add the
> > pci@0,0 node in your DT.  
> 
> I can't find a driver that uses the approach I'm trying in my patches. This
> approach was suggested in the review process [2] by Rob who mentioned that
> now we should be able drop legacy interrupt controller nodes. There are
> some Apple device trees that points the interrupt-map to the port node (the
> way I tried in my workaround) [3], but I can't find more than that.
> 
> The topology in my case is:
> 
> root@smarc-rzg3s:~# lspci -t
> -[0000:00]---00.0-[01]----00.0
> 
> root@smarc-rzg3s:~# lspci
> 00:00.0 PCI bridge: Renesas Technology Corp. Device 0033
> 01:00.0 Non-Volatile memory controller: Micron Technology Inc 2550 NVMe SSD
> (DRAM-less) (rev 01)
> 
> When not working pci@0,0 is exported as follows in rootfs:
> 
> root@smarc-rzg3s:~# ls /sys/firmware/devicetree/base/soc/pcie@11e40000 -l
> -r--r--r--    1 root     root             4 Jan 12 10:28 #address-cells
> -r--r--r--    1 root     root             4 Jan 12 10:28 #interrupt-cells
> -r--r--r--    1 root     root             4 Jan 12 10:28 #size-cells
> -r--r--r--    1 root     root             8 Jan 12 10:28 bus-range
> -r--r--r--    1 root     root            13 Jan 12 10:28 clock-names
> -r--r--r--    1 root     root            24 Jan 12 10:28 clocks
> -r--r--r--    1 root     root            26 Jan 12 10:28 compatible
> -r--r--r--    1 root     root             4 Jan 12 10:28 device-id
> -r--r--r--    1 root     root             4 Jan 12 10:28 device_type
> -r--r--r--    1 root     root            28 Jan 12 10:28 dma-ranges
> -r--r--r--    1 root     root             0 Jan 12 10:28 interrupt-controller
> -r--r--r--    1 root     root           144 Jan 12 10:28 interrupt-map
> -r--r--r--    1 root     root            16 Jan 12 10:28 interrupt-map-mask
> -r--r--r--    1 root     root           164 Jan 12 10:28 interrupt-names
> -r--r--r--    1 root     root             4 Jan 12 10:28 interrupt-parrent

Why parrent instead of parent in interrupt-parrent ?

> -r--r--r--    1 root     root           192 Jan 12 10:28 interrupts
> -r--r--r--    1 root     root             5 Jan 12 10:28 name
> -r--r--r--    1 root     root             4 Jan 12 10:28 num-lanes
> drwxr-xr-x    2 root     root             0 Jan 12 10:17 pci@0,0
> -r--r--r--    1 root     root             4 Jan 12 10:28 phandle
> -r--r--r--    1 root     root             4 Jan 12 10:28 pinctrl-0
> -r--r--r--    1 root     root             8 Jan 12 10:28 pinctrl-names
> -r--r--r--    1 root     root             4 Jan 12 10:28 power-domains
> -r--r--r--    1 root     root            28 Jan 12 10:28 ranges
> -r--r--r--    1 root     root            16 Jan 12 10:28 reg
> -r--r--r--    1 root     root             4 Jan 12 10:28 renesas,sysc
> -r--r--r--    1 root     root            63 Jan 12 10:28 reset-names
> -r--r--r--    1 root     root            56 Jan 12 10:28 resets
> -r--r--r--    1 root     root             5 Jan 12 10:28 status
> -r--r--r--    1 root     root             4 Jan 12 10:28 vendor-id
> root@smarc-rzg3s:~#
> root@smarc-rzg3s:~# ls
> /sys/firmware/devicetree/base/soc/pcie@11e40000/pci@0,0 -l
> -r--r--r--    1 root     root             4 Jan 12 10:17 #address-cells
> -r--r--r--    1 root     root             4 Jan 12 10:17 #interrupt-cells
> -r--r--r--    1 root     root             4 Jan 12 10:17 #size-cells
> -r--r--r--    1 root     root             8 Jan 12 10:17 bus-range
> -r--r--r--    1 root     root            41 Jan 12 10:17 compatible
> -r--r--r--    1 root     root             4 Jan 12 10:17 device_type
> -r--r--r--    1 root     root           144 Jan 12 10:17 interrupt-map
> -r--r--r--    1 root     root            16 Jan 12 10:17 interrupt-map-mask
> -r--r--r--    1 root     root            32 Jan 12 10:17 ranges
> -r--r--r--    1 root     root            20 Jan 12 10:17 reg
> root@smarc-rzg3s:~#
> root@smarc-rzg3s:~#
> root@smarc-rzg3s:~#
> root@smarc-rzg3s:~#
> root@smarc-rzg3s:~# cat
> /sys/firmware/devicetree/base/soc/pcie@11e40000/pci@0,0/compatible
> pci1912,33pciclass,060400pciclass,0604root@smarc-rzg3s:~#
> root@smarc-rzg3s:~#
> root@smarc-rzg3s:~#
> 
> In case I describe a port in device tree, it works because the pci@0,0 is
> not created anymore when device is enumerated and thus the interrupt
> parsing is working.
> 
> Herve: do you have some hints?

First interrupt-parrent in your /sys/firmware/devicetree/base/soc/pcie@11e40000
files.

If it is just a typo in this email, maybe the interrupt parsing itself.

Can you provide an extract for the DT with nodes created at runtime.
I mean can you run 'dtc -I dtb -O dts /proc/device-tree' and provide the output
related to PCI nodes including the PCIe controller ?

> 
> Rob: do you know some device trees where the interrupt-map points to the
> node itself as suggested in [2] so that I can check is something is missing
> on my side?
> 
> Thank you,
> Claudiu
> 
> [2] https://lore.kernel.org/all/20250509210800.GB4080349-robh@kernel.org/
> [3]
> https://elixir.bootlin.com/linux/v6.15/source/arch/arm64/boot/dts/apple/t8112.dtsi#L951
> 

Best regards,
Hervé

-- 
Hervé Codina, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

  reply	other threads:[~2025-06-17  7:23 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-24 14:13 [PATCH v8 0/5] Add support for the PCI host bridge device-tree node creation Herve Codina
2025-02-24 14:13 ` [PATCH v8 1/5] driver core: Introduce device_{add,remove}_of_node() Herve Codina
2025-02-24 14:13 ` [PATCH v8 2/5] PCI: of: Use device_{add,remove}_of_node() to attach of_node to existing device Herve Codina
2025-02-28 20:58   ` Bjorn Helgaas
2025-03-03  9:42     ` Herve Codina
2025-02-24 14:13 ` [PATCH v8 3/5] PCI: of_property: Add support for NULL pdev in of_pci_set_address() Herve Codina
2025-02-24 14:13 ` [PATCH v8 4/5] PCI: of_property: Constify parameter in of_pci_get_addr_flags() Herve Codina
2025-02-24 14:13 ` [PATCH v8 5/5] PCI: of: Create device-tree PCI host bridge node Herve Codina
2025-02-28 21:21   ` Bjorn Helgaas
2025-03-03  9:49     ` Herve Codina
2025-06-11  8:26   ` Claudiu Beznea
2025-06-11 14:56     ` Herve Codina
2025-06-13 13:36       ` Claudiu Beznea
2025-06-17  7:00         ` Herve Codina [this message]
2025-06-18 10:42           ` Claudiu Beznea
2025-02-27 17:36 ` [PATCH v8 0/5] Add support for the PCI host bridge device-tree node creation Bjorn Helgaas

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=20250617090029.03283ea6@bootlin.com \
    --to=herve.codina@bootlin.com \
    --cc=allan.nielsen@microchip.com \
    --cc=bhelgaas@google.com \
    --cc=claudiu.beznea@tuxon.dev \
    --cc=dakr@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=horatiu.vultur@microchip.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lizhi.hou@amd.com \
    --cc=rafael@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=saravanak@google.com \
    --cc=steen.hegelund@microchip.com \
    --cc=thomas.petazzoni@bootlin.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.