| 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
| ||
|
Message-ID: <v6adntm5a3wxxxsmufd54t6pgmoj4njp63q362orkbeew6t3ef@7pfiz6ou7w77>
Date: Mon, 1 Dec 2025 15:18:48 +0100
From: Thierry Reding <thierry.reding@...il.com>
To: Rob Herring <robh@...nel.org>
Cc: Svyatoslav Ryhel <clamor95@...il.com>,
Krzysztof Kozlowski <krzk@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
Thierry Reding <treding@...dia.com>, Jonathan Hunter <jonathanh@...dia.com>,
Prashant Gaikwad <pgaikwad@...dia.com>, Mikko Perttunen <mperttunen@...dia.com>,
Michael Turquette <mturquette@...libre.com>, Stephen Boyd <sboyd@...nel.org>,
Dmitry Osipenko <digetx@...il.com>, MyungJoo Ham <myungjoo.ham@...sung.com>,
Kyungmin Park <kyungmin.park@...sung.com>, Chanwoo Choi <cw00.choi@...sung.com>,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org, linux-tegra@...r.kernel.org,
linux-clk@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH v3 03/11] dt-bindings: memory: Document Tegra114 Memory
Controller
On Wed, Sep 24, 2025 at 10:24:30AM -0500, Rob Herring wrote:
> On Mon, Sep 22, 2025 at 07:18:00PM +0300, Svyatoslav Ryhel wrote:
> > пн, 22 вер. 2025 р. о 19:00 Rob Herring <robh@...nel.org> пише:
> > >
> > > On Mon, Sep 15, 2025 at 11:01:49AM +0300, Svyatoslav Ryhel wrote:
> > > > Add Tegra114 support into existing Tegra124 MC schema with the most
> > > > notable difference in the amount of EMEM timings.
> > > >
> > > > Signed-off-by: Svyatoslav Ryhel <clamor95@...il.com>
> > > > ---
> > > > .../nvidia,tegra124-mc.yaml | 97 ++++++++++++++-----
> > > > 1 file changed, 74 insertions(+), 23 deletions(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml
> > > > index 7b18b4d11e0a..9cc9360d3bd0 100644
> > > > --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml
> > > > +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml
> > > > @@ -19,7 +19,9 @@ description: |
> > > >
> > > > properties:
> > > > compatible:
> > > > - const: nvidia,tegra124-mc
> > > > + enum:
> > > > + - nvidia,tegra114-mc
> > > > + - nvidia,tegra124-mc
> > > >
> > > > reg:
> > > > maxItems: 1
> > > > @@ -64,29 +66,10 @@ patternProperties:
> > > >
> > > > nvidia,emem-configuration:
> > > > $ref: /schemas/types.yaml#/definitions/uint32-array
> > > > - description: |
> > > > + description:
> > > > Values to be written to the EMEM register block. See section
> > > > - "15.6.1 MC Registers" in the TRM.
> > > > - items:
> > > > - - description: MC_EMEM_ARB_CFG
> > > > - - description: MC_EMEM_ARB_OUTSTANDING_REQ
> > > > - - description: MC_EMEM_ARB_TIMING_RCD
> > > > - - description: MC_EMEM_ARB_TIMING_RP
> > > > - - description: MC_EMEM_ARB_TIMING_RC
> > > > - - description: MC_EMEM_ARB_TIMING_RAS
> > > > - - description: MC_EMEM_ARB_TIMING_FAW
> > > > - - description: MC_EMEM_ARB_TIMING_RRD
> > > > - - description: MC_EMEM_ARB_TIMING_RAP2PRE
> > > > - - description: MC_EMEM_ARB_TIMING_WAP2PRE
> > > > - - description: MC_EMEM_ARB_TIMING_R2R
> > > > - - description: MC_EMEM_ARB_TIMING_W2W
> > > > - - description: MC_EMEM_ARB_TIMING_R2W
> > > > - - description: MC_EMEM_ARB_TIMING_W2R
> > > > - - description: MC_EMEM_ARB_DA_TURNS
> > > > - - description: MC_EMEM_ARB_DA_COVERS
> > > > - - description: MC_EMEM_ARB_MISC0
> > > > - - description: MC_EMEM_ARB_MISC1
> > > > - - description: MC_EMEM_ARB_RING1_THROTTLE
> > > > + "20.11.1 MC Registers" in the Tegea114 TRM or
> > > > + "15.6.1 MC Registers" in the Tegra124 TRM.
> > > >
> > > > required:
> > > > - clock-frequency
> > > > @@ -109,6 +92,74 @@ required:
> > > > - "#iommu-cells"
> > > > - "#interconnect-cells"
> > > >
> > > > +allOf:
> > > > + - if:
> > > > + properties:
> > > > + compatible:
> > > > + contains:
> > > > + enum:
> > > > + - nvidia,tegra114-mc
> > > > + then:
> > > > + patternProperties:
> > > > + "^emc-timings-[0-9]+$":
> > > > + patternProperties:
> > > > + "^timing-[0-9]+$":
> > > > + properties:
> > > > + nvidia,emem-configuration:
> > > > + items:
> > > > + - description: MC_EMEM_ARB_CFG
> > > > + - description: MC_EMEM_ARB_OUTSTANDING_REQ
> > > > + - description: MC_EMEM_ARB_TIMING_RCD
> > > > + - description: MC_EMEM_ARB_TIMING_RP
> > > > + - description: MC_EMEM_ARB_TIMING_RC
> > > > + - description: MC_EMEM_ARB_TIMING_RAS
> > > > + - description: MC_EMEM_ARB_TIMING_FAW
> > > > + - description: MC_EMEM_ARB_TIMING_RRD
> > > > + - description: MC_EMEM_ARB_TIMING_RAP2PRE
> > > > + - description: MC_EMEM_ARB_TIMING_WAP2PRE
> > > > + - description: MC_EMEM_ARB_TIMING_R2R
> > > > + - description: MC_EMEM_ARB_TIMING_W2W
> > > > + - description: MC_EMEM_ARB_TIMING_R2W
> > > > + - description: MC_EMEM_ARB_TIMING_W2R
> > > > + - description: MC_EMEM_ARB_DA_TURNS
> > > > + - description: MC_EMEM_ARB_DA_COVERS
> > > > + - description: MC_EMEM_ARB_MISC0
> > > > + - description: MC_EMEM_ARB_RING1_THROTTLE
> > >
> > > Like I said before, I don't think it is worth enumerating the list of
> > > registers for every variant. If you want to define the length
> > > (minItems/maxItems), then that is fine.
> > >
> >
> > It worth because position of value matters when reading and list above
> > provides a reference to the order in which register values should be
> > grouped.
>
> The schema does nothing to validate that. The only thing that gets
> validated is the length. It is just an opaque blob of data. I'm sure you
> have to define the order in the driver as well. One place is enough.
Hi Rob,
Sorry for being so late on this, but I just noticed that v4 had dropped
these items descriptions and then saw that you had suggested this. I
have always found the explicit mention useful because it allows DT
writers to know what to put into the properties without having to look
up a specific implementation.
If the DT bindings don't specify the order, then how do we guarantee
that all implementations agree on the order? While it's true that no
validation is done via the schema, the schema is the only specification
that we have for this. Without it there is no reason for an
implementation to pick one order over another.
Thierry
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists