From: Herve Codina <herve.codina@bootlin.com>
To: Alex Elder <elder@riscstar.com>
Cc: bhelgaas@google.com, robh@kernel.org, saravanak@kernel.org,
daniel@riscstar.com, mohd.anwar@oss.qualcomm.com,
lorenzo.bianconi@oss.qualcomm.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 4/4] of: address: kill of_node_is_pcie()
Date: Tue, 1 Sep 2026 17:15:28 +0200 [thread overview]
Message-ID: <20260901171528.487ca48d@bootlin.com> (raw)
In-Reply-To: <6a5bec41-71ef-4d9c-a34f-77d166b15ca6@riscstar.com>
Hi Alex,
On Tue, 1 Sep 2026 09:58:10 -0500
Alex Elder <elder@riscstar.com> wrote:
> On 9/1/26 1:45 AM, Herve Codina wrote:
> > Hi Alex,
> >
> > On Mon, 31 Aug 2026 20:13:37 -0500
> > Alex Elder <elder@riscstar.com> wrote:
> >
> >> The of_bus->match function for the "PCI" bus type is fairly liberal
> >> in what it accepts as a PCI bus devicetree node. If a node has no
> >> device_type property, it even allows a node named "pcie@" to be
> >> accepted as represnting a devicetree bus, though it issues a warning
> >> in that case.
> >>
> >> A recent PCI commit introduced of_pci_verify_node(). When a PCI
> >> device is added, if it has a devicetree node, that function checks
> >> its device_type property. For PCI bridge devices, if there is no
> >> device_type property (value "pci"), a warning is issued.
> >>
> >> That warning duplicates the warning made by of_node_is_pcie(), and
> >> there's no point in that. Avoid the second (OF) warning by just
> >> checking the node name directly in of_bus_pci_match().
> >>
> >> That leaves of_node_is_pcie() unused, so get rid of it.
> >>
> >> Signed-off-by: Alex Elder <elder@riscstar.com>
> >> ---
> >> v3: - Added (new) in this version of the series
> >>
> >> drivers/of/address.c | 12 +-----------
> >> 1 file changed, 1 insertion(+), 11 deletions(-)
> >>
> >> diff --git a/drivers/of/address.c b/drivers/of/address.c
> >> index 499d37ceae210..ee2eb44884d85 100644
> >> --- a/drivers/of/address.c
> >> +++ b/drivers/of/address.c
> >> @@ -134,16 +134,6 @@ static unsigned int of_bus_pci_get_flags(const __be32 *addr)
> >> * PCI bus specific translator
> >> */
> >>
> >> -static bool of_node_is_pcie(const struct device_node *np)
> >> -{
> >> - bool is_pcie = of_node_name_eq(np, "pcie");
> >> -
> >> - if (is_pcie)
> >> - pr_warn_once("%pOF: Missing device_type\n", np);
> >> -
> >> - return is_pcie;
> >> -}
> >> -
> >> static int of_bus_pci_match(struct device_node *np)
> >> {
> >> /*
> >> @@ -156,7 +146,7 @@ static int of_bus_pci_match(struct device_node *np)
> >> */
> >> 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);
> >> + of_node_name_eq(np, "pcie");
> >> }
> >>
> >> static void of_bus_pci_count_cells(struct device_node *np,
> >
> > The warning here was printed based on the node name whereas of_node_is_pcie()
> > prints the message based on the 'device_type' property of a pci_dev node.
>
> You're right. Both warnings were getting reported for me, but for
> different reasons.
>
> I would be happy to just drop this patch and live with two warnings
> in some cases (we should rarely see either one of them anyway, right?).
>
> Is that OK with you? Does anyone feel this patch should be kept?
On my side, I have no problem to see two warnings and so, IHMO, this patch
can be dropped.
Best regards,
Hervé
next prev parent reply other threads:[~2026-09-01 15:15 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 1:13 [PATCH v3 0/4] PCI: of: warn on bogus device_type property Alex Elder
2026-09-01 1:13 ` [PATCH v3 1/4] PCI: of: drop the reg_num argument to of_pci_set_address() Alex Elder
2026-09-01 1:16 ` sashiko-bot
2026-09-01 1:13 ` [PATCH v3 2/4] PCI: of: don't zero flags in of_pci_get_addr_flags() Alex Elder
2026-09-01 1:20 ` sashiko-bot
2026-09-01 2:42 ` Alex Elder
2026-09-01 1:13 ` [PATCH v3 3/4] PCI: of: introduce of_pci_verify_node() Alex Elder
2026-09-01 1:21 ` sashiko-bot
2026-09-01 2:42 ` Alex Elder
2026-09-01 17:32 ` Rob Herring
2026-09-02 12:54 ` Alex Elder
2026-09-01 6:11 ` Herve Codina
2026-09-01 1:13 ` [PATCH v3 4/4] of: address: kill of_node_is_pcie() Alex Elder
2026-09-01 1:18 ` sashiko-bot
2026-09-01 2:03 ` Alex Elder
2026-09-01 6:45 ` Herve Codina
2026-09-01 14:58 ` Alex Elder
2026-09-01 15:15 ` Herve Codina [this message]
2026-09-01 15:25 ` Alex Elder
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=20260901171528.487ca48d@bootlin.com \
--to=herve.codina@bootlin.com \
--cc=bhelgaas@google.com \
--cc=daniel@riscstar.com \
--cc=devicetree@vger.kernel.org \
--cc=elder@riscstar.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.bianconi@oss.qualcomm.com \
--cc=mohd.anwar@oss.qualcomm.com \
--cc=robh@kernel.org \
--cc=saravanak@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox