[PATCH 2/2] PCI: brcmstb: Use "num-lanes" DT property if present

[Jim Quinlan]

On Tue, Jun 24, 2025 at 6:01 PM Bjorn Helgaas <helgaas at kernel.org> wrote:
>
> On Fri, May 30, 2025 at 06:40:33PM -0400, Jim Quinlan wrote:
> > By default, we use automatic HW negotiation to ascertain the number of
> > lanes of the PCIe connection.  If the "num-lanes" DT property is present,
> > assume that the chip's built-in capability information is incorrect or
> > undesired, and use the specified value instead.
> >
> > Signed-off-by: Jim Quinlan <james.quinlan at broadcom.com>
> > ---
> >  drivers/pci/controller/pcie-brcmstb.c | 26 +++++++++++++++++++++++++-
> >  1 file changed, 25 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
> > index e19628e13898..79fc6d00b7bc 100644
> > --- a/drivers/pci/controller/pcie-brcmstb.c
> > +++ b/drivers/pci/controller/pcie-brcmstb.c
> > @@ -46,6 +46,7 @@
> >  #define  PCIE_RC_CFG_PRIV1_ID_VAL3_CLASS_CODE_MASK   0xffffff
> >
> >  #define PCIE_RC_CFG_PRIV1_LINK_CAPABILITY                    0x04dc
> > +#define  PCIE_RC_CFG_PRIV1_LINK_CAPABILITY_MAX_LINK_WIDTH_MASK       0x1f0
> >  #define  PCIE_RC_CFG_PRIV1_LINK_CAPABILITY_ASPM_SUPPORT_MASK 0xc00
> >
> >  #define PCIE_RC_CFG_PRIV1_ROOT_CAP                   0x4f8
>    #define  PCIE_RC_CFG_PRIV1_ROOT_CAP_L1SS_MODE_MASK      0xf8
>
> If you squint, PCIE_RC_CFG_PRIV1_LINK_CAPABILITY looks a little like
> these standard PCIe things:
>
>   #define PCI_EXP_LNKCAP          0x0c    /* Link Capabilities */
>   #define  PCI_EXP_LNKCAP_MLW     0x000003f0 /* Maximum Link Width */
>   #define  PCI_EXP_LNKCAP_ASPMS   0x00000c00 /* ASPM Support */
>
>   #define PCI_EXP_DEVCTL2         0x28    /* Device Control 2 */
>
> So I was hoping we had an opportunity to use PCI_EXP_LNKCAP_MLW and
> PCI_EXP_LNKCAP_ASPMS instead of
> PCIE_RC_CFG_PRIV1_LINK_CAPABILITY_MAX_LINK_WIDTH_MASK and
> PCIE_RC_CFG_PRIV1_LINK_CAPABILITY_ASPM_SUPPORT_MASK.
>
> But I guess PCIE_RC_CFG_PRIV1_LINK_CAPABILITY is probably not actually
> PCI_EXP_LNKCAP, because PCI_EXP_LNKCAP being 0x0c into a PCIe
> Capability would mean the cap started at 0x04d0, and
> PCIE_RC_CFG_PRIV1_ROOT_CAP would be at offset 0x28
> (0x04d0 + 0x28 == 0x04f8).
>
> But offset 0x28 in a PCIe Capability would be PCI_EXP_DEVCTL2, not
> PCIE_RC_CFG_PRIV1_ROOT_CAP, and I can't squint hard enough to see
> anything related to L1SS anywhere in the PCIe Capability.
>
> So never mind ;)
Hi Bjorn,

Not only are the "priv" register offsets slightly different, the
values of the masks may be different as well.  For example,
PCI_EXP_LNKCAP_MLW  is 0x3f0 while our "priv" version is 0x1f0, as
something unrelated occupies the missing "priv" bit.

Cheers,
Jim Quinlan
Broadcom STB/CM


>
> Bjorn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4197 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20250625/cf20e0da/attachment.p7s>