From: Bjorn Helgaas <helgaas@kernel.org>
To: Anand Moon <linux.amoon@gmail.com>
Cc: "Shawn Lin" <shawn.lin@rock-chips.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Heiko Stuebner" <heiko@sntech.de>,
"open list:PCIE DRIVER FOR ROCKCHIP" <linux-pci@vger.kernel.org>,
"open list:PCIE DRIVER FOR ROCKCHIP"
<linux-rockchip@lists.infradead.org>,
"moderated list:ARM/Rockchip SoC support"
<linux-arm-kernel@lists.infradead.org>,
"open list" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC v1 2/5] PCI: rockchip: Fix Device Control register offset for Max payload size
Date: Mon, 17 Nov 2025 18:50:56 -0600 [thread overview]
Message-ID: <20251118005056.GA2541796@bhelgaas> (raw)
In-Reply-To: <20251117181023.482138-3-linux.amoon@gmail.com>
On Mon, Nov 17, 2025 at 11:40:10PM +0530, Anand Moon wrote:
> As per 17.6.6.1.29 PCI Express Device Capabilities Register
> (PCIE_RC_CONFIG_DC) reside at offset 0xc8 within the Root Complex (RC)
> configuration space, not at the offset of the PCI Express Capability
> List (0xc0). Following changes corrects the register offset to use
> PCIE_RC_CONFIG_DC (0xc8) to configure Max Payload Size.
>
> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> ---
> drivers/pci/controller/pcie-rockchip-host.c | 4 ++--
> drivers/pci/controller/pcie-rockchip.h | 1 +
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-rockchip-host.c b/drivers/pci/controller/pcie-rockchip-host.c
> index f0de5b2590c4..d51780f4a254 100644
> --- a/drivers/pci/controller/pcie-rockchip-host.c
> +++ b/drivers/pci/controller/pcie-rockchip-host.c
> @@ -382,10 +382,10 @@ static int rockchip_pcie_host_init_port(struct rockchip_pcie *rockchip)
> rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_CR + PCI_EXP_LNKCAP);
> }
>
> - status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_CR + PCI_EXP_DEVCTL);
> + status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_DC + PCI_EXP_DEVCTL);
> status &= ~PCI_EXP_DEVCTL_PAYLOAD;
> status |= PCI_EXP_DEVCTL_PAYLOAD_256B;
> - rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_CR + PCI_EXP_DEVCTL);
> + rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_DC + PCI_EXP_DEVCTL);
>
> return 0;
> err_power_off_phy:
> diff --git a/drivers/pci/controller/pcie-rockchip.h b/drivers/pci/controller/pcie-rockchip.h
> index 5d8a3ae38599..c0ec6c32ea16 100644
> --- a/drivers/pci/controller/pcie-rockchip.h
> +++ b/drivers/pci/controller/pcie-rockchip.h
> @@ -157,6 +157,7 @@
> #define PCIE_EP_CONFIG_LCS (PCIE_EP_CONFIG_BASE + 0xd0)
> #define PCIE_RC_CONFIG_RID_CCR (PCIE_RC_CONFIG_BASE + 0x08)
> #define PCIE_RC_CONFIG_CR (PCIE_RC_CONFIG_BASE + 0xc0)
> +#define PCIE_RC_CONFIG_DC (PCIE_RC_CONFIG_BASE + 0xc8)
Per the RK3399 TRM:
DEVCAP 0xc4
DEVCTL and DEVSTA 0xc8
LNKCAP 0xcc
LNKCTL and LNKSTA 0xd0
SLTCAP 0xd4
SLTCTL and SLTSTA 0xd8
That all makes good sense and matches the relative offsets in the PCIe
Capability.
I have no idea how we got from that to the mind-bendingly obtuse
#defines here:
PCIE_RC_CONFIG_CR == PCIE_RC_CONFIG_BASE + 0xc0
== 0xa00000 + 0xc0
== 0xa000c0
PCIE_RC_CONFIG_DC == PCIE_RC_CONFIG_BASE + 0xc8
== 0xa00000 + 0xc8
== 0xa000c8
PCIE_RC_CONFIG_LC == PCIE_RC_CONFIG_BASE + 0xd0
== 0xa00000 + 0xd0
== 0xa000d0
PCIE_RC_CONFIG_SR == PCIE_RC_CONFIG_BASE + 0xd4
== 0xa00000 + 0xd4
== 0xa000d4
And they're used like this:
PCIE_RC_CONFIG_CR + PCI_EXP_LNKCAP == 0xa000c0 + 0x0c
== 0xa000cc
PCIE_RC_CONFIG_CR + PCI_EXP_LNKCTL == 0xa000c0 + 0x10
== 0xa000d0
PCIE_RC_CONFIG_DC + PCI_EXP_DEVCTL == 0xa000c8 + 0x08
== 0xa000d0 <-- same as LNKCTL?
PCIE_RC_CONFIG_SR + PCI_EXP_DEVCAP == 0xa000d4 + 0x04
== 0xa000d8 <--
PCIE_RC_CONFIG_LC + PCI_EXP_LNKCTL == 0xa000d0 + 0x10
== 0xa000e0 <-- but LNKCTL was at 0xa000d0 above?
And the mappings don't make any sense to me:
CR -> LNKCAP & LNKCTL
DC -> DEVCTL (ok, this one makes a *little* sense)
SR -> DEVCAP
LC -> LNKCTL (would make some sense except that we have CR above)
This is all just really hard to read. It looks like if we defined a
single base address for the PCIe Capability, we shouldn't need all the
_CR, _DC, _LC, _SR, etc #defines. E.g., we could have
#define ROCKCHIP_RP_PCIE_CAP ...
rockchip_pcie_read(rockchip, ROCKCHIP_RP_PCIE_CAP + PCI_EXP_DEVCAP)
rockchip_pcie_read(rockchip, ROCKCHIP_RP_PCIE_CAP + PCI_EXP_LNKCTL)
...
with maybe some minor adjustment for 16-bit registers since Rockchip
only seems to support 32-bit accesses (?)
None of these registers are *Root Complex* registers; they're all part
of a PCIe Capability, which applies to a Root *Port*.
> #define PCIE_RC_CONFIG_LC (PCIE_RC_CONFIG_BASE + 0xd0)
> #define PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2 (PCIE_RC_CONFIG_BASE + 0x90c)
> #define PCIE_RC_CONFIG_THP_CAP (PCIE_RC_CONFIG_BASE + 0x274)
> --
> 2.50.1
>
next prev parent reply other threads:[~2025-11-18 0:51 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-17 18:10 [RFC v1 0/5] Fix some register offset as per RK3399 TRM part 2 Anand Moon
2025-11-17 18:10 ` [RFC v1 1/5] PCI: rockchip: Fix Link Control register offset and enable ASPM/CLKREQ Anand Moon
2025-11-18 17:50 ` Bjorn Helgaas
2025-11-19 14:19 ` Anand Moon
2025-11-20 3:44 ` Bjorn Helgaas
2025-11-20 13:58 ` Anand Moon
2025-11-26 10:33 ` Anand Moon
2025-11-26 14:39 ` Bjorn Helgaas
2025-11-27 7:34 ` Anand Moon
2025-11-17 18:10 ` [RFC v1 2/5] PCI: rockchip: Fix Device Control register offset for Max payload size Anand Moon
2025-11-18 0:50 ` Bjorn Helgaas [this message]
2025-11-18 11:16 ` Anand Moon
2025-11-17 18:10 ` [RFC v1 3/5] PCI: rockchip: Fix Slot Capability Register offset for slot power limit Anand Moon
2025-11-17 18:10 ` [RFC v1 4/5] PCI: rockchip: Fix Link Control and Status Register 2 for target link speed Anand Moon
2025-11-17 18:10 ` [RFC v1 5/5] PCI: rockchip: Fix Linkwidth Control Register offset for Retrain Link Anand Moon
2025-11-18 0:54 ` [RFC v1 0/5] Fix some register offset as per RK3399 TRM part 2 Shawn Lin
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=20251118005056.GA2541796@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=heiko@sntech.de \
--cc=kwilczynski@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux.amoon@gmail.com \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=robh@kernel.org \
--cc=shawn.lin@rock-chips.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