[PATCH 1/2] dt-bindings: PCI: brcm,stb-pcie: Add num-lanes property

[PATCH 1/2] dt-bindings: PCI: brcm,stb-pcie: Add num-lanes property

[Jim Quinlan]

Add optional num-lanes property Broadcom STB PCIe host controllers.

Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
---
 Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
index 29f0e1eb5096..f31d654ac3a0 100644
--- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
@@ -107,6 +107,8 @@ properties:
       - const: bridge
       - const: swinit
 
+  num-lanes: true
+
 required:
   - compatible
   - reg
-- 
2.43.0

Re: [PATCH 1/2] dt-bindings: PCI: brcm,stb-pcie: Add num-lanes property

[Florian Fainelli]

On 5/10/2025 12:28 AM, Jim Quinlan wrote:
> Add optional num-lanes property Broadcom STB PCIe host controllers.
> 
> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>

Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
-- 
Florian

Re: [PATCH 1/2] dt-bindings: PCI: brcm,stb-pcie: Add num-lanes property

[Rob Herring]

On Fri, May 9, 2025 at 5:28 PM Jim Quinlan <james.quinlan@broadcom.com> wrote:
>
> Add optional num-lanes property Broadcom STB PCIe host controllers.
>
> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> ---
>  Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> index 29f0e1eb5096..f31d654ac3a0 100644
> --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> @@ -107,6 +107,8 @@ properties:
>        - const: bridge
>        - const: swinit
>
> +  num-lanes: true

Why do you need this? It is already allowed by the referenced schemas.
Though maybe you don't support 16 lanes and need to limit this to
something less? I would also set 'default' if you do that.

Rob

Re: [PATCH 1/2] dt-bindings: PCI: brcm,stb-pcie: Add num-lanes property

[Jim Quinlan]

[-- Attachment #1: Type: text/plain, Size: 1391 bytes --]

On Mon, May 12, 2025 at 11:01 AM Rob Herring <robh@kernel.org> wrote:
>
> On Fri, May 9, 2025 at 5:28 PM Jim Quinlan <james.quinlan@broadcom.com> wrote:
> >
> > Add optional num-lanes property Broadcom STB PCIe host controllers.
> >
> > Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> > ---
> >  Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > index 29f0e1eb5096..f31d654ac3a0 100644
> > --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > @@ -107,6 +107,8 @@ properties:
> >        - const: bridge
> >        - const: swinit
> >
> > +  num-lanes: true
>
> Why do you need this? It is already allowed by the referenced schemas.
> Though maybe you don't support 16 lanes and need to limit this to
> something less? I would also set 'default' if you do that.


I just thought that if our driver actually did something with
"num-lanes" -- most drivers do not --  then it should be mentioned  in
the YAML, even if "num-lanes" is pre-defined.

At any rate we cannot handle 16 lanes so I will add a "default" and "maximum".

Regards,
Jim Quinlan
Broadcom STB
>
>
> Rob

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4197 bytes --]

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

[Jim Quinlan]

v2:
  -- DT bindings: Add default, maximum values for 'num-lanes' (Rob)
  -- Add 'if' clause to clamp maximum requested num-lanes


v1: original

Jim Quinlan (2):
  dt-bindings: PCI: brcm,stb-pcie: Add num-lanes property
  PCI: brcmstb: Use "num-lanes" DT property if present

 .../bindings/pci/brcm,stb-pcie.yaml           |  4 +++
 drivers/pci/controller/pcie-brcmstb.c         | 26 ++++++++++++++++++-
 2 files changed, 29 insertions(+), 1 deletion(-)


base-commit: 01f95500a162fca88cefab9ed64ceded5afabc12
-- 
2.43.0

[PATCH 1/2] dt-bindings: PCI: brcm,stb-pcie: Add num-lanes property

[Jim Quinlan]

Add optional num-lanes property Broadcom STB PCIe host controllers.

Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
---
 Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
index 29f0e1eb5096..cba227b19a5f 100644
--- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
@@ -107,6 +107,10 @@ properties:
       - const: bridge
       - const: swinit
 
+  num-lanes:
+    default: 1
+    maximum: 4
+
 required:
   - compatible
   - reg
-- 
2.43.0

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

[Jim Quinlan]

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@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
@@ -55,6 +56,9 @@
 #define PCIE_RC_DL_MDIO_WR_DATA				0x1104
 #define PCIE_RC_DL_MDIO_RD_DATA				0x1108
 
+#define PCIE_RC_PL_REG_PHY_CTL_1			0x1804
+#define  PCIE_RC_PL_REG_PHY_CTL_1_REG_P2_POWERDOWN_ENA_NOSYNC_MASK	0x8
+
 #define PCIE_RC_PL_PHY_CTL_15				0x184c
 #define  PCIE_RC_PL_PHY_CTL_15_DIS_PLL_PD_MASK		0x400000
 #define  PCIE_RC_PL_PHY_CTL_15_PM_CLK_PERIOD_MASK	0xff
@@ -1072,7 +1076,7 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
 	void __iomem *base = pcie->base;
 	struct pci_host_bridge *bridge;
 	struct resource_entry *entry;
-	u32 tmp, burst, aspm_support;
+	u32 tmp, burst, aspm_support, num_lanes, num_lanes_cap;
 	u8 num_out_wins = 0;
 	int num_inbound_wins = 0;
 	int memc, ret;
@@ -1180,6 +1184,26 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
 		PCIE_RC_CFG_PRIV1_LINK_CAPABILITY_ASPM_SUPPORT_MASK);
 	writel(tmp, base + PCIE_RC_CFG_PRIV1_LINK_CAPABILITY);
 
+	/* 'tmp' still holds the contents of PRIV1_LINK_CAPABILITY */
+	num_lanes_cap = u32_get_bits(tmp, PCIE_RC_CFG_PRIV1_LINK_CAPABILITY_MAX_LINK_WIDTH_MASK);
+	num_lanes = 0;
+	/*
+	 * Use automatic num-lanes HW negotiation by default.  If the
+	 * "num-lanes" DT property is present, assume that the chip's
+	 * built-in link width capability information is
+	 * incorrect/undesired and use the specified value instead.
+	 */
+	if (!of_property_read_u32(pcie->np, "num-lanes", &num_lanes) &&
+	    num_lanes && num_lanes <= 4 && num_lanes_cap != num_lanes) {
+		u32p_replace_bits(&tmp, num_lanes,
+			PCIE_RC_CFG_PRIV1_LINK_CAPABILITY_MAX_LINK_WIDTH_MASK);
+		writel(tmp, base + PCIE_RC_CFG_PRIV1_LINK_CAPABILITY);
+		tmp = readl(base + PCIE_RC_PL_REG_PHY_CTL_1);
+		u32p_replace_bits(&tmp, 1,
+			PCIE_RC_PL_REG_PHY_CTL_1_REG_P2_POWERDOWN_ENA_NOSYNC_MASK);
+		writel(tmp, base + PCIE_RC_PL_REG_PHY_CTL_1);
+	}
+
 	/*
 	 * For config space accesses on the RC, show the right class for
 	 * a PCIe-PCIe bridge (the default setting is to be EP mode).
-- 
2.43.0

Re: [PATCH 1/2] dt-bindings: PCI: brcm,stb-pcie: Add num-lanes property

[Florian Fainelli]

On 5/30/25 15:40, Jim Quinlan wrote:
> Add optional num-lanes property Broadcom STB PCIe host controllers.
> 
> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>

Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
-- 
Florian

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

[Florian Fainelli]

On 5/30/25 15:40, 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@broadcom.com>

Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
-- 
Florian

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

[Florian Fainelli]

On 5/30/25 15:40, Jim Quinlan wrote:
> v2:
>    -- DT bindings: Add default, maximum values for 'num-lanes' (Rob)
>    -- Add 'if' clause to clamp maximum requested num-lanes

Subjects should have been "PATCH v2", FWIW.
-- 
Florian

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

[Manivannan Sadhasivam]

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@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
> @@ -55,6 +56,9 @@
>  #define PCIE_RC_DL_MDIO_WR_DATA				0x1104
>  #define PCIE_RC_DL_MDIO_RD_DATA				0x1108
>  
> +#define PCIE_RC_PL_REG_PHY_CTL_1			0x1804
> +#define  PCIE_RC_PL_REG_PHY_CTL_1_REG_P2_POWERDOWN_ENA_NOSYNC_MASK	0x8
> +
>  #define PCIE_RC_PL_PHY_CTL_15				0x184c
>  #define  PCIE_RC_PL_PHY_CTL_15_DIS_PLL_PD_MASK		0x400000
>  #define  PCIE_RC_PL_PHY_CTL_15_PM_CLK_PERIOD_MASK	0xff
> @@ -1072,7 +1076,7 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
>  	void __iomem *base = pcie->base;
>  	struct pci_host_bridge *bridge;
>  	struct resource_entry *entry;
> -	u32 tmp, burst, aspm_support;
> +	u32 tmp, burst, aspm_support, num_lanes, num_lanes_cap;
>  	u8 num_out_wins = 0;
>  	int num_inbound_wins = 0;
>  	int memc, ret;
> @@ -1180,6 +1184,26 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
>  		PCIE_RC_CFG_PRIV1_LINK_CAPABILITY_ASPM_SUPPORT_MASK);
>  	writel(tmp, base + PCIE_RC_CFG_PRIV1_LINK_CAPABILITY);
>  
> +	/* 'tmp' still holds the contents of PRIV1_LINK_CAPABILITY */
> +	num_lanes_cap = u32_get_bits(tmp, PCIE_RC_CFG_PRIV1_LINK_CAPABILITY_MAX_LINK_WIDTH_MASK);
> +	num_lanes = 0;
> +	/*
> +	 * Use automatic num-lanes HW negotiation by default.  If the

"Use hardware negotiated Max Link Width value by default."

> +	 * "num-lanes" DT property is present, assume that the chip's
> +	 * built-in link width capability information is
> +	 * incorrect/undesired and use the specified value instead.
> +	 */
> +	if (!of_property_read_u32(pcie->np, "num-lanes", &num_lanes) &&
> +	    num_lanes && num_lanes <= 4 && num_lanes_cap != num_lanes) {

I think you should drop the 'num_lanes && num_lanes <= 4' check since the DT
binding should take care of that. Otherwise, once link width gets increased, you
need to update both binding and the driver, which is redundant.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

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

[Jim Quinlan]

[-- Attachment #1: Type: text/plain, Size: 3890 bytes --]

On Sat, May 31, 2025 at 2:34 AM Manivannan Sadhasivam
<manivannan.sadhasivam@linaro.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@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
> > @@ -55,6 +56,9 @@
> >  #define PCIE_RC_DL_MDIO_WR_DATA                              0x1104
> >  #define PCIE_RC_DL_MDIO_RD_DATA                              0x1108
> >
> > +#define PCIE_RC_PL_REG_PHY_CTL_1                     0x1804
> > +#define  PCIE_RC_PL_REG_PHY_CTL_1_REG_P2_POWERDOWN_ENA_NOSYNC_MASK   0x8
> > +
> >  #define PCIE_RC_PL_PHY_CTL_15                                0x184c
> >  #define  PCIE_RC_PL_PHY_CTL_15_DIS_PLL_PD_MASK               0x400000
> >  #define  PCIE_RC_PL_PHY_CTL_15_PM_CLK_PERIOD_MASK    0xff
> > @@ -1072,7 +1076,7 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
> >       void __iomem *base = pcie->base;
> >       struct pci_host_bridge *bridge;
> >       struct resource_entry *entry;
> > -     u32 tmp, burst, aspm_support;
> > +     u32 tmp, burst, aspm_support, num_lanes, num_lanes_cap;
> >       u8 num_out_wins = 0;
> >       int num_inbound_wins = 0;
> >       int memc, ret;
> > @@ -1180,6 +1184,26 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
> >               PCIE_RC_CFG_PRIV1_LINK_CAPABILITY_ASPM_SUPPORT_MASK);
> >       writel(tmp, base + PCIE_RC_CFG_PRIV1_LINK_CAPABILITY);
> >
> > +     /* 'tmp' still holds the contents of PRIV1_LINK_CAPABILITY */
> > +     num_lanes_cap = u32_get_bits(tmp, PCIE_RC_CFG_PRIV1_LINK_CAPABILITY_MAX_LINK_WIDTH_MASK);
> > +     num_lanes = 0;
> > +     /*
> > +      * Use automatic num-lanes HW negotiation by default.  If the
>
> "Use hardware negotiated Max Link Width value by default."
>
> > +      * "num-lanes" DT property is present, assume that the chip's
> > +      * built-in link width capability information is
> > +      * incorrect/undesired and use the specified value instead.
> > +      */
> > +     if (!of_property_read_u32(pcie->np, "num-lanes", &num_lanes) &&
> > +         num_lanes && num_lanes <= 4 && num_lanes_cap != num_lanes) {
>
> I think you should drop the 'num_lanes && num_lanes <= 4' check since the DT
> binding should take care of that. Otherwise, once link width gets increased, you
> need to update both binding and the driver, which is redundant.
Not all Linux release configuration systems run a comprehensive DT
validator  before execution.  Our bootloader modifies the DT blob on
the fly and also permits -- with restrictions -- customers to modify
the DT at the bootloader command line.  Yes, we can do partial a
priori DT validation, but there is still value to checking the params
in the driver code, at least for us.

>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4197 bytes --]

Re: [PATCH 1/2] dt-bindings: PCI: brcm,stb-pcie: Add num-lanes property

[Florian Fainelli]

On 5/30/25 16:32, Florian Fainelli wrote:
> On 5/30/25 15:40, Jim Quinlan wrote:
>> Add optional num-lanes property Broadcom STB PCIe host controllers.
>>
>> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> 
> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>

Sorry I take that back, I think this should be:

num-lanes:
   enum: [ 1, 2, 4 ]

We are basically documenting the allowed values, not specifying that we 
can repeat the num-lames property between 1 and 4 times.
-- 
Florian

Re: [PATCH 1/2] dt-bindings: PCI: brcm,stb-pcie: Add num-lanes property

[Jim Quinlan]

[-- Attachment #1: Type: text/plain, Size: 719 bytes --]

On Tue, Jun 3, 2025 at 12:24 PM Florian Fainelli
<florian.fainelli@broadcom.com> wrote:
>
> On 5/30/25 16:32, Florian Fainelli wrote:
> > On 5/30/25 15:40, Jim Quinlan wrote:
> >> Add optional num-lanes property Broadcom STB PCIe host controllers.
> >>
> >> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> >
> > Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
>
> Sorry I take that back, I think this should be:
>
> num-lanes:
>    enum: [ 1, 2, 4 ]
>
> We are basically documenting the allowed values, not specifying that we
> can repeat the num-lames property between 1 and 4 times.

num-lanes is already defined as

    enum: [ 1, 2, 4, 8, 16, 32 ]

> --
> Florian

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4197 bytes --]

Re: [PATCH 1/2] dt-bindings: PCI: brcm,stb-pcie: Add num-lanes property

[Florian Fainelli]

On 6/3/25 10:16, Jim Quinlan wrote:
> On Tue, Jun 3, 2025 at 12:24 PM Florian Fainelli
> <florian.fainelli@broadcom.com> wrote:
>>
>> On 5/30/25 16:32, Florian Fainelli wrote:
>>> On 5/30/25 15:40, Jim Quinlan wrote:
>>>> Add optional num-lanes property Broadcom STB PCIe host controllers.
>>>>
>>>> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
>>>
>>> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
>>
>> Sorry I take that back, I think this should be:
>>
>> num-lanes:
>>     enum: [ 1, 2, 4 ]
>>
>> We are basically documenting the allowed values, not specifying that we
>> can repeat the num-lames property between 1 and 4 times.
> 
> num-lanes is already defined as
> 
>      enum: [ 1, 2, 4, 8, 16, 32 ]

Right, but then we need to re-define it with our own specific 
constraints, still, don't we?
-- 
Florian

Re: [PATCH 1/2] dt-bindings: PCI: brcm,stb-pcie: Add num-lanes property

[Jim Quinlan]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]

On Tue, Jun 3, 2025 at 1:17 PM Florian Fainelli
<florian.fainelli@broadcom.com> wrote:
>
> On 6/3/25 10:16, Jim Quinlan wrote:
> > On Tue, Jun 3, 2025 at 12:24 PM Florian Fainelli
> > <florian.fainelli@broadcom.com> wrote:
> >>
> >> On 5/30/25 16:32, Florian Fainelli wrote:
> >>> On 5/30/25 15:40, Jim Quinlan wrote:
> >>>> Add optional num-lanes property Broadcom STB PCIe host controllers.
> >>>>
> >>>> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> >>>
> >>> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
> >>
> >> Sorry I take that back, I think this should be:
> >>
> >> num-lanes:
> >>     enum: [ 1, 2, 4 ]
> >>
> >> We are basically documenting the allowed values, not specifying that we
> >> can repeat the num-lames property between 1 and 4 times.
> >
> > num-lanes is already defined as
> >
> >      enum: [ 1, 2, 4, 8, 16, 32 ]
>
> Right, but then we need to re-define it with our own specific
> constraints, still, don't we?
We do; there is the provided enum and we provide the maximum and minimum.
The AND-ing of all constraints yields [1, 2, 4].
Also, I'm not sure one can redefine an existing property or would want to.

> --
> Florian

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4197 bytes --]

Re: [PATCH 1/2] dt-bindings: PCI: brcm,stb-pcie: Add num-lanes property

[Rob Herring]

On Tue, Jun 03, 2025 at 10:17:26AM -0700, Florian Fainelli wrote:
> On 6/3/25 10:16, Jim Quinlan wrote:
> > On Tue, Jun 3, 2025 at 12:24 PM Florian Fainelli
> > <florian.fainelli@broadcom.com> wrote:
> > > 
> > > On 5/30/25 16:32, Florian Fainelli wrote:
> > > > On 5/30/25 15:40, Jim Quinlan wrote:
> > > > > Add optional num-lanes property Broadcom STB PCIe host controllers.
> > > > > 
> > > > > Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> > > > 
> > > > Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
> > > 
> > > Sorry I take that back, I think this should be:
> > > 
> > > num-lanes:
> > >     enum: [ 1, 2, 4 ]
> > > 
> > > We are basically documenting the allowed values, not specifying that we
> > > can repeat the num-lames property between 1 and 4 times.

Are you confused with maxItems?

> > 
> > num-lanes is already defined as
> > 
> >      enum: [ 1, 2, 4, 8, 16, 32 ]
> 
> Right, but then we need to re-define it with our own specific constraints,
> still, don't we?

It is correct as-is.

Rob

Re: [PATCH 1/2] dt-bindings: PCI: brcm,stb-pcie: Add num-lanes property

[Rob Herring (Arm)]

On Fri, 30 May 2025 18:40:32 -0400, Jim Quinlan wrote:
> Add optional num-lanes property Broadcom STB PCIe host controllers.
> 
> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> ---
>  Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml | 4 ++++
>  1 file changed, 4 insertions(+)
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

Re: [PATCH 1/2] dt-bindings: PCI: brcm,stb-pcie: Add num-lanes property

[Florian Fainelli]

On 6/5/25 15:36, Rob Herring wrote:
> On Tue, Jun 03, 2025 at 10:17:26AM -0700, Florian Fainelli wrote:
>> On 6/3/25 10:16, Jim Quinlan wrote:
>>> On Tue, Jun 3, 2025 at 12:24 PM Florian Fainelli
>>> <florian.fainelli@broadcom.com> wrote:
>>>>
>>>> On 5/30/25 16:32, Florian Fainelli wrote:
>>>>> On 5/30/25 15:40, Jim Quinlan wrote:
>>>>>> Add optional num-lanes property Broadcom STB PCIe host controllers.
>>>>>>
>>>>>> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
>>>>>
>>>>> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
>>>>
>>>> Sorry I take that back, I think this should be:
>>>>
>>>> num-lanes:
>>>>      enum: [ 1, 2, 4 ]
>>>>
>>>> We are basically documenting the allowed values, not specifying that we
>>>> can repeat the num-lames property between 1 and 4 times.
> 
> Are you confused with maxItems?

Yes I am.

> 
>>>
>>> num-lanes is already defined as
>>>
>>>       enum: [ 1, 2, 4, 8, 16, 32 ]
>>
>> Right, but then we need to re-define it with our own specific constraints,
>> still, don't we?
> 
> It is correct as-is.

Thanks!
-- 
Florian

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

[Manivannan Sadhasivam]

On Fri, 30 May 2025 18:40:31 -0400, Jim Quinlan wrote:
> v2:
>   -- DT bindings: Add default, maximum values for 'num-lanes' (Rob)
>   -- Add 'if' clause to clamp maximum requested num-lanes
> 
> 
> v1: original
> 
> [...]

Applied, thanks!

[1/2] dt-bindings: PCI: brcm,stb-pcie: Add num-lanes property
      commit: dbb1258daf75f2b98e465ba5a0e26073eda6e539
[2/2] PCI: brcmstb: Use "num-lanes" DT property if present
      commit: a364d10ffe361fb34c3838d33604da493045de1e

Best regards,
-- 
Manivannan Sadhasivam <mani@kernel.org>

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

[Bjorn Helgaas]

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@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 ;)

Bjorn

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

[Jim Quinlan]

[-- Attachment #1: Type: text/plain, Size: 2780 bytes --]

On Tue, Jun 24, 2025 at 6:01 PM Bjorn Helgaas <helgaas@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@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

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4197 bytes --]