linux-kernel - Re: [PATCH v4 12/17] dt-bindings: PCI: dwc: Add Baikal-T1 PCIe Root Port bindings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL_JsqJGvZnaV+kRazsb953+RtXadFxhEkw_uSjwR9PUXQeAAw@mail.gmail.com>
Date:   Tue, 9 Aug 2022 14:06:16 -0600
From:   Rob Herring <robh@...nel.org>
To:     Serge Semin <fancer.lancer@...il.com>
Cc:     Serge Semin <Sergey.Semin@...kalelectronics.ru>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Jingoo Han <jingoohan1@...il.com>,
        Gustavo Pimentel <gustavo.pimentel@...opsys.com>,
        Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
        Pavel Parkhomenko <Pavel.Parkhomenko@...kalelectronics.ru>,
        Krzysztof Wilczyński <kw@...ux.com>,
        Frank Li <Frank.Li@....com>,
        Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        PCI <linux-pci@...r.kernel.org>, devicetree@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 12/17] dt-bindings: PCI: dwc: Add Baikal-T1 PCIe Root
 Port bindings

On Tue, Aug 9, 2022 at 1:28 PM Serge Semin <fancer.lancer@...il.com> wrote:
>
> On Tue, Aug 09, 2022 at 09:12:31AM -0600, Rob Herring wrote:
> > On Mon, Aug 8, 2022 at 10:01 AM Serge Semin <fancer.lancer@...il.com> wrote:
> > >
> > > On Mon, Aug 01, 2022 at 12:13:11PM -0600, Rob Herring wrote:
> > > > On Thu, Jul 28, 2022 at 05:34:22PM +0300, Serge Semin wrote:
> > > > > Baikal-T1 SoC is equipped with DWC PCIe v4.60a Root Port controller, which
> > > > > link can be trained to work on up to Gen.3 speed over up to x4 lanes. The
> > > > > controller is supposed to be fed up with four clock sources: DBI
> > > > > peripheral clock, AXI application Tx/Rx clocks and external PHY/core
> > > > > reference clock generating the 100MHz signal. In addition to that the
> > > > > platform provide a way to reset each part of the controller:
> > > > > sticky/non-sticky bits, host controller core, PIPE interface, PCS/PHY and
> > > > > Hot/Power reset signal. The Root Port controller is equipped with multiple
> > > > > IRQ lines like MSI, system AER, PME, HP, Bandwidth change, Link
> > > > > equalization request and eDMA ones. The registers space is accessed over
> > > > > the DBI interface. There can be no more than four inbound or outbound iATU
> > > > > windows configured.
> > > > >
> > > > > Signed-off-by: Serge Semin <Sergey.Semin@...kalelectronics.ru>
> > > > >

[...]

> > > > > +  reg-names:
> > > > > +    minItems: 3
> > > > > +    maxItems: 3
> > > > > +    items:
> > > > > +      enum: [ dbi, dbi2, config ]
> > > >
> > >
> > > > Define the order. Here, and the rest.
> > >
> > > Ok. I will, but please answer to my question, I asked you in the
> > > previous email thread:
> > >
> > > Serge Semin wrote:
> > > > Rob Herring wrote:
> > > > > ...
> > > > > Tell me why you need random order.
> > > >
> > > > Because I don't see a need in constraining the order. If we get to set
> > > > the order requirement, then why do we need to have the "*-names"
> > > > property at all?
> >
> > Originally, it was for cases where you have a variable number of
> > entries and can't determine what each entry is. IOW, when you have
> > optional entries in the middle of required entries. But then everyone
> > *loves* -names even when not needed or useful such as 'phy-names =
> > "pcie"' (the phy subsys requiring names was part of the problem there,
> > but that's been fixed).
> >

> > > > IMO having "reg" with max/minItems restriction plus generic
> > > > description and "reg-names" with possible values enumerated seems very
> > > > suitable pattern in this case. Don't you think?
> >
> > No, I think this is just as concise and defines the order too:
> >
> > reg-names:
> >   items:
> >     - const: dbi
> >     - const: dbi2
> >     - const: config
> >
> > >
> > > In addition to that what about optional names? How would you suggest
> > > to handle such case without the non-ordered pattern?
> >
>
> > Sorry, I don't follow.
>
> I meant exactly the case you've described as the main goal of the
> named properties. My worry was that by using the pattern:
>
> reg-names:
>   items:
>     - const: name
>     - const: another_name
>     - const: one_more_name
>
> you get to fix the names order, which they were invented to get rid
> from. If you get to use that pattern the only optional names could be
> the names at the tail of the array, which isn't always applicable. In
> that case you'd have no choice but to use the pattern suggested by
> me.

For this binding, we use reg-names because the order and what's
present varies by platform. But for a given platform the order is
fixed.

Rob