linux-kernel - Re: [PATCH v5 05/20] dt-bindings: memory: factorise LPDDR props into SDRAM props

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: <4055d2c4-64c7-498f-8cdb-8d749d32ec68@gmail.com>
Date: Thu, 14 Aug 2025 16:06:42 +0200
From: Clément Le Goffic <legoffic.clement@...il.com>
To: Julius Werner <jwerner@...omium.org>,
 Clément Le Goffic <clement.legoffic@...s.st.com>
Cc: Will Deacon <will@...nel.org>, Mark Rutland <mark.rutland@....com>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>,
 Maxime Coquelin <mcoquelin.stm32@...il.com>,
 Alexandre Torgue <alexandre.torgue@...s.st.com>,
 Philipp Zabel <p.zabel@...gutronix.de>, Jonathan Corbet <corbet@....net>,
 Gatien Chevallier <gatien.chevallier@...s.st.com>,
 Michael Turquette <mturquette@...libre.com>, Stephen Boyd
 <sboyd@...nel.org>, Gabriel Fernandez <gabriel.fernandez@...s.st.com>,
 Krzysztof Kozlowski <krzk@...nel.org>, linux-arm-kernel@...ts.infradead.org,
 linux-perf-users@...r.kernel.org, devicetree@...r.kernel.org,
 linux-stm32@...md-mailman.stormreply.com, linux-kernel@...r.kernel.org,
 linux-doc@...r.kernel.org, linux-clk@...r.kernel.org
Subject: Re: [PATCH v5 05/20] dt-bindings: memory: factorise LPDDR props into
 SDRAM props

Hi Julius,

On 30/07/2025 20:27, Julius Werner wrote:
>> +      Compatible strings can be either explicit vendor names and part numbers
>> +      (e.g. elpida,ECB240ABACN), or generated strings of the form
>> +      lpddrX,YY,ZZZZ or ddrX-YYYY,AAAA...,ZZZZ where X, Y, A and Z are in lower
> 
> If the revision ID is only one byte for DDR, there should be only two Zs.

Indeed, will fix it here and in the dedicated field documentation below.
Wouldn't it be better to add a regex pattern for the compatible ?

> 
>> +      case hexadecimal with leading zeroes.
> 
> AAAA is not hexadecimal, it's a verbatim ASCII string (at least that's
> how I would define it, for readability).

Yes you're right. I'll add the numbers of chars it corresponds to in the 
dedicated field below also.

> 
>> +      For LPDDR and DDR SDRAM, X is the SDRAM version (2, 3, 4, etc.).
>> +      For LPDDR SDRAM:
>> +        - YY is the manufacturer ID (from MR5), 1 byte
>> +        - ZZZZ is the revision ID (from MR6 and MR7), 2 bytes
>> +      For DDR4 SDRAM with SPD, according to JEDEC SPD4.1.2.L-6 :
>> +        - YYYY is the manufacturer ID, 2 bytes, from bytes 320 and 321
>> +        - AAAA... is the part number, 20 bytes, from bytes 329 to 348
> 
> This should clarify that it is excluding trailing spaces (so only the
> significant part of those 20 bytes, since they're supposed to be
> padded with spaces at the end).

I'll add a comment about that.

> 
>> +        - Z is the revision ID, 1 byte, from byte 349
>> +      The former form is useful when the SDRAM vendor and part number are
>> +      known, such as when the SDRAM is soldered on the board.
> 
> This inversion of the statement is a bit odd? I think it's more
> important to explain why we need the latter form (or just explain
> both).

I will document both forms so.

> 
>> +      SDRAM revision ID:
>> +        - LPDDR SDRAM, decoded from Mode Register 6 and 7, always 2 bytes.
>> +        - DDR4 SDRAM, decoded from the SPD from byte 349 according to
>> +          JEDEC SPD4.1.2.L-6.
> 
> nit: Add "always one byte" for clarity and consistency with the LPDDR
> equivalent.

Ack