linux-kernel - Re: [PATCH 1/5] dt-bindings: nvmem: add google,gs101-otp

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] [day] [month] [year] [list]

Message-ID: <336b06a7-8772-443e-8716-99e52ac4cc7e@linaro.org>
Date: Fri, 31 Oct 2025 18:06:27 +0200
From: Tudor Ambarus <tudor.ambarus@...aro.org>
To: Conor Dooley <conor@...nel.org>, Srinivas Kandagatla <srini@...nel.org>
Cc: Srinivas Kandagatla <srini@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Krzysztof Kozlowski <krzk@...nel.org>,
 Alim Akhtar <alim.akhtar@...sung.com>,
 Peter Griffin <peter.griffin@...aro.org>,
 André Draszik <andre.draszik@...aro.org>,
 semen.protsenko@...aro.org, willmcvicker@...gle.com,
 kernel-team@...roid.com, linux-kernel@...r.kernel.org,
 linux-samsung-soc@...r.kernel.org, devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 1/5] dt-bindings: nvmem: add google,gs101-otp



On 10/31/25 5:02 PM, Conor Dooley wrote:
> On Fri, Oct 31, 2025 at 12:45:09PM +0000, Tudor Ambarus wrote:
>> Add binding for the OTP controller found on Google GS101.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@...aro.org>
>> ---
>>  .../bindings/nvmem/google,gs101-otp.yaml           | 68 ++++++++++++++++++++++
>>  1 file changed, 68 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/nvmem/google,gs101-otp.yaml b/Documentation/devicetree/bindings/nvmem/google,gs101-otp.yaml
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..2144911297beb89337b0389b30fe6609db4156ea
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/nvmem/google,gs101-otp.yaml
>> @@ -0,0 +1,68 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/nvmem/google,gs101-otp.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Google GS101 OTP Controller
>> +
>> +maintainers:
>> +  - Tudor Ambarus <tudor.ambarus@...aro.org>
>> +
>> +description: |
>> +  OTP controller drives a NVMEM memory where system or user specific data
>> +  can be stored. The OTP controller register space if of interest as well
>> +  because it contains dedicated registers where it stores the Product ID
>> +  and the Chip ID (apart other things like TMU or ASV info).
>> +
>> +allOf:
>> +  - $ref: nvmem.yaml#
>> +  - $ref: nvmem-deprecated-cells.yaml
> 
> Why are the deprecated cells needed here?
> |  Before introducing NVMEM layouts all NVMEM (fixed) cells were defined
> |  as direct device subnodes. That syntax was replaced by "fixed-layout"
> |  and is deprecated now. No new bindings should use it.
>

This OTP controller has an OTP memory space that can be read/program/lock
using specific OTP commands /register pokes (I'm not adding support for
this in this patch set).

The OTP controller register space contains dedicated registers for the
Product ID and Chip ID, which I'd like to expose as nvmem cells so that
a client can parse them and register as a soc device (see [1]).

Right now I need to expose the OTP controller register space, but I
expect that the OTP memory space will need to be exposed as nvmem cells
in the future as well.

Thus I need to be able to expose both the OTP register space and the
OTP memory space as nvmem cells in DT. I thought of using the deprecated
(fixed) cells for the OTP register space and the fixed-layout syntax
for the OTP memory space.

What is the recommended way to expose the OTP register space? I guess
an alternative is to add empty nodes as direct device subnodes, and
define and add the cells to the nvmem device from the driver using
config->cells.

[1] https://lore.kernel.org/linux-samsung-soc/20251031-gs101-chipid-v1-0-d78d1076b210@linaro.org/T/>> +
>> +properties:
>> +  compatible:
>> +    items:
>> +      - const: google,gs101-otp
>> +
>> +  clocks:
>> +    maxItems: 1
>> +
>> +  clock-names:
>> +    const: pclk
> 
> Why bother with clock-names when you only have one clock? Are you
> anticipating a variant with more?
> 

Likely, but I'll drop the name. We can add it later on.>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  power-domains:
>> +    maxItems: 1
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - "#address-cells"
>> +  - "#size-cells"
>> +  - clock-names
>> +  - clocks
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/clock/google,gs101.h>
>> +
>> +    otp: efuse@...00000 {
>> +        compatible = "google,gs101-otp";
>> +        reg = <0x10000000 0xf084>;
>> +        #address-cells = <1>;
>> +        #size-cells = <1>;
>> +        clocks = <&cmu_misc CLK_GOUT_MISC_OTP_CON_TOP_PCLK>;
>> +        clock-names = "pclk";
>> +
>> +        product_id: product_id@0 {
> 
> Why does this node name have an underscore?

I forgot to update, will use product-id for the name> 
> Additionally, all nodes here should lose their labels.

and drop the labels from the examples.

Thanks!
ta