[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250605223603.GA3375348-robh@kernel.org>
Date: Thu, 5 Jun 2025 17:36:03 -0500
From: Rob Herring <robh@...nel.org>
To: Florian Fainelli <florian.fainelli@...adcom.com>
Cc: Jim Quinlan <james.quinlan@...adcom.com>, linux-pci@...r.kernel.org,
Nicolas Saenz Julienne <nsaenz@...nel.org>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
bcm-kernel-feedback-list@...adcom.com, jim2101024@...il.com,
Lorenzo Pieralisi <lpieralisi@...nel.org>,
Krzysztof Wilczyński <kw@...ux.com>,
Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
"moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE" <linux-arm-kernel@...ts.infradead.org>,
"moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" <linux-rpi-kernel@...ts.infradead.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] dt-bindings: PCI: brcm,stb-pcie: Add num-lanes
property
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@...adcom.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@...adcom.com>
> > > >
> > > > Reviewed-by: Florian Fainelli <florian.fainelli@...adcom.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
Powered by blists - more mailing lists