All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Alex Elder" <elder@riscstar.com>
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org, robh@kernel.org
Subject: Re: [PATCH 4/5] arm64: dts: qcom: monaco-evk-ifp-mezzanine: use dev for device nodes
Date: Tue, 01 Sep 2026 17:54:44 +0000	[thread overview]
Message-ID: <20260901175445.0142A1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260901172058.1512508-5-elder@riscstar.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Medium] Mismatch between the commit title and the patch implementation regarding the new node name.

Pre-existing issues:
- [High] Renaming the endpoint nodes from 'pcie@' to 'pci@' will not prevent them from being treated as PCI buses, because the `device_type = "pci"` property is retained.
--

commit c206fa07d8c746582b6a4894fa608acb472261eb
Author: Alex Elder <elder@riscstar.com>

> arm64: dts: qcom: monaco-evk-ifp-mezzanine: use dev for device nodes

[Severity: Medium]
Does the commit title match the implementation? The title explicitly mentions
using "dev for device nodes", but the patch renames the nodes to "pci@",
not "dev@".

This patch aims to fix an issue where embedded PCIe endpoints were
incorrectly treated as PCI buses after being renamed to pcie@. It
renames the nodes to pci@ to restore previous behavior and avoid
them being mistaken for bridge nodes.

> diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-ifp-mezzanine.dtso b/arch/arm64/boot/dts/qcom/monaco-evk-ifp-mezzanine.dtso
> index ca5bf0fe5ec6e..a6e57ec8a1e14 100644
> --- a/arch/arm64/boot/dts/qcom/monaco-evk-ifp-mezzanine.dtso
> +++ b/arch/arm64/boot/dts/qcom/monaco-evk-ifp-mezzanine.dtso
[ ... ]
> @@ -117,7 +117,7 @@ pcie@3,0 {
>  			ranges;
>  			bus-range = <0x5 0xff>;
>  
> -			pcie@0,0 {
> +			pci@0,0 {
>  				reg = <0x50000 0x0 0x0 0x0 0x0>;
>  				#address-cells = <3>;
>  				#size-cells = <2>;
>  				device_type = "pci";

[Severity: High]
This is a pre-existing issue, but does renaming the node to "pci@" actually
prevent it from being treated as a PCI bus?

The node pci@0,0 retains the device_type = "pci" property. When the devicetree
address parser matches buses, of_bus_pci_match() in drivers/of/address.c
evaluates the type before checking the node name:

drivers/of/address.c:of_bus_pci_match() {
        ...
        return of_node_is_type(np, "pci") || of_node_is_type(np, "pciex") ||
                of_node_is_type(np, "vci") || of_node_is_type(np, "ht") ||
                of_node_is_pcie(np);
}

Because device_type = "pci" remains present in the endpoint node,
of_node_is_type() will still evaluate to true. Will this cause the node to
always be matched as a PCI bus unconditionally, rendering the rename
ineffective at restoring the default-flags bus behavior?

This same question applies to the pci@0,1 node modified later in the file.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901172058.1512508-1-elder@riscstar.com?part=4

  reply	other threads:[~2026-09-01 17:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-01 17:20 [PATCH 0/5] arm64: dts: qcom: use pci for device nodes Alex Elder
2026-09-01 17:20 ` [PATCH 1/5] arm64: dts: qcom: qcs6490-rb3gen2: " Alex Elder
2026-09-01 17:39   ` sashiko-bot
2026-09-01 17:45     ` Alex Elder
2026-09-01 20:05   ` Rob Herring
2026-09-02 12:51     ` Alex Elder
2026-09-02 16:53       ` Rob Herring
2026-09-02 18:40         ` Alex Elder
2026-09-01 17:20 ` [PATCH 2/5] arm64: dts: qcom: qcs6490-rb3gen2-industrial-mezzanine: " Alex Elder
2026-09-01 17:34   ` sashiko-bot
2026-09-01 17:20 ` [PATCH 3/5] arm64: dts: qcom: lemans-evk-ifp-mezzanine: " Alex Elder
2026-09-01 17:49   ` sashiko-bot
2026-09-01 17:20 ` [PATCH 4/5] arm64: dts: qcom: monaco-evk-ifp-mezzanine: use dev " Alex Elder
2026-09-01 17:54   ` sashiko-bot [this message]
2026-09-01 18:18     ` Alex Elder
2026-09-01 17:20 ` [PATCH 5/5] arm64: dts: qcom: qcs6490-thundercomm-minipc-g1iot: " Alex Elder
2026-09-01 18:03   ` sashiko-bot

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=20260901175445.0142A1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=elder@riscstar.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.