From: Marc Zyngier <maz@kernel.org>
To: Aksh Garg <a-garg7@ti.com>
Cc: <lukas@wunner.de>, <linux-pci@vger.kernel.org>,
<lpieralisi@kernel.org>, <kwilczynski@kernel.org>,
<mani@kernel.org>, <robh@kernel.org>, <bhelgaas@google.com>,
<cassel@kernel.org>, <linux-kernel@vger.kernel.org>,
<s-vadapalli@ti.com>, <danishanwar@ti.com>
Subject: Re: [PATCH] PCI: Add PCI_RID_MASK macro
Date: Tue, 17 Feb 2026 08:51:28 +0000 [thread overview]
Message-ID: <865x7vbvn3.wl-maz@kernel.org> (raw)
In-Reply-To: <d86a9cbf-900d-4561-836c-1c5a9fb2c4a3@ti.com>
On Tue, 17 Feb 2026 07:52:54 +0000,
Aksh Garg <a-garg7@ti.com> wrote:
>
> Marc, Lukas,
>
> On 16/02/26 18:56, Marc Zyngier wrote:
> > On Mon, 16 Feb 2026 12:06:00 +0000,
> > Aksh Garg <a-garg7@ti.com> wrote:
> >>
> >> Routing ID (RID) is a 16-bit value composed of bus number and devfn.
> >
> > No. RID here means "Requester ID". Please lookup the PCI spec.
> >
> >> Add a PCI_RID_MASK macro to eliminate the use of magic number 0xffff
> >> when masking for RIDs.
> >
> > I'm not convinced this is universally true. Some RIDs (or RID-like
> > identifiers, such as Stream IDs and Device IDs) are larger than 16
> > bit, depending on the integration.
> >
> > The fact that this particular integration uses a 16bit RID without any
> > extra qualifier in the upper bits doesn't make it universal.
> >
> >> This provides a standard way for drivers to extract RIDs without
> >> resorting to magic numbers.
> >>
> >> Signed-off-by: Aksh Garg <a-garg7@ti.com>
> >> ---
> >> drivers/pci/controller/pcie-apple.c | 2 +-
> >> include/linux/pci.h | 1 +
> >> 2 files changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c
> >> index 2d92fc79f6dd..6bf9fe102e2f 100644
> >> --- a/drivers/pci/controller/pcie-apple.c
> >> +++ b/drivers/pci/controller/pcie-apple.c
> >> @@ -802,7 +802,7 @@ static void apple_pcie_disable_device(struct pci_host_bridge *bridge, struct pci
> >> u32 val;
> >> val = readl_relaxed(port_rid2sid_addr(port, idx));
> >> - if ((val & 0xffff) == rid) {
> >> + if ((val & PCI_RID_MASK) == rid) {
> >> apple_pcie_rid2sid_write(port, idx, 0);
> >> bitmap_release_region(port->sid_map, idx, 0);
> >> dev_dbg(&pdev->dev, "Released %x (%d)\n", val, idx);
> >> diff --git a/include/linux/pci.h b/include/linux/pci.h
> >> index 864775651c6f..e3d9730121c8 100644
> >> --- a/include/linux/pci.h
> >> +++ b/include/linux/pci.h
> >> @@ -71,6 +71,7 @@
> >> #define PCI_DEVID(bus, devfn) ((((u16)(bus)) << 8) | (devfn))
> >> /* return bus from PCI devid = ((u16)bus_number) << 8) | devfn */
> >> #define PCI_BUS_NUM(x) (((x) >> 8) & 0xff)
> >> +#define PCI_RID_MASK 0xffff
> >
> > Even the naming of this macro clashes with the current nomenclature,
> > where we use PCI_DEVID()/pci_dev_id() to manipulate this information.
> >
>
> Is the below proposed macro acceptable at the same place:
> #define PCI_GET_DEVID(x) ((x) & 0xffff)
But what meaning does this have? What containing type are you
extracting the value from?
The code you're hacking extracts the value from a register. What if
the register had a completely different layout? Would you move the
mask to match the layout of that particular register?
If you really want to get rid of what you consider a magic number, add
a bunch of fields to the apple driver to describe the rid2sid
registers, and use that with FIELD_GET()/FIELD_PREP() to manipulate
the registers.
But what you are proposing here is not generic. It has no defined
semantics, and is actively misleading.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
prev parent reply other threads:[~2026-02-17 8:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-16 12:06 [PATCH] PCI: Add PCI_RID_MASK macro Aksh Garg
2026-02-16 12:14 ` Siddharth Vadapalli
2026-02-16 13:09 ` Lukas Wunner
2026-02-16 13:26 ` Marc Zyngier
2026-02-17 7:52 ` Aksh Garg
2026-02-17 8:51 ` Marc Zyngier [this message]
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=865x7vbvn3.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=a-garg7@ti.com \
--cc=bhelgaas@google.com \
--cc=cassel@kernel.org \
--cc=danishanwar@ti.com \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=lukas@wunner.de \
--cc=mani@kernel.org \
--cc=robh@kernel.org \
--cc=s-vadapalli@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox