linux-kernel - Re: [PATCH v2 0/8] Add R-Car fuse support

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: <CAMuHMdXtAPebwHkEcp+PcAxP-BfP8wqmX4BYOc1TC7mCex7Fsw@mail.gmail.com>
Date: Sat, 29 Jun 2024 13:35:38 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Magnus Damm <magnus.damm@...il.com>, 
	Linus Walleij <linus.walleij@...aro.org>, 
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>, devicetree@...r.kernel.org, 
	linux-renesas-soc@...r.kernel.org, linux-gpio@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/8] Add R-Car fuse support

Hi Srinivas,

On Wed, May 29, 2024 at 11:29 AM Geert Uytterhoeven
<geert+renesas@...der.be> wrote:
> R-Car Gen3/Gen4 SoCs contain fuses indicating hardware support or
> hardware parameters.  Unfortunately the various SoCs require different
> mechanisms to read the state of the fuses:
>   - On R-Car Gen3, the fuse monitor registers are in the middle of the
>     Pin Function Controller (PFC) register block,
>   - On R-Car V3U and S4-8, the E-FUSE non-volatile memory is accessible
>     through a separate register block in the PFC,
>   - On R-Car V4H and V4M, the E-FUSE non-volatile memory is accessible
>     through the second register block of OTP_MEM.
>
> This patch series adds support for all 3 variants.  It provides an
> in-kernel API to read the fuses' states, as well as userspace access
> through the nvmem subsystem and sysfs:
>   - R-Car Gen3:    /sys/bus/platform/devices/rcar_fuse/fuse/nvmem
>   - R-Car V3U/S4:  /sys/bus/platform/devices/e6078800.fuse/fuse/nvmem
>   - R-Car V4H/V4M: /sys/bus/platform/devices/e61be000.otp/fuse/nvmem
>
> This has been tested on R-Car H3 ES2.0, M3-W and M3-W+, M3-N, V3M, V3H
> and V3H2, D3, E3, V3U, S4-8 ES1.0 and ES1.2, V4H, and V4M.
>
> For SoCs where E-FUSE is accessed through the PFC, it is not clear from
> the documentation if any PFC module clock needs to be enabled for fuse
> access.  According to experiments on R-Car S4-8, the module clock and
> reset only impact the GPIO functionality of the PFC, not the pinmux or
> fuse monitor functionalities.  So perhaps the clock/power-domains/resets
> properties should be dropped from the DT bindings and DTS, as well as
> the Runtime PM handling from the driver?
>
> Changes compared to v1[1]:
>   - Drop RFC state and broaden audience,
>   - Fix typo in one-line summary,
>   - Add Reviewed-by.
>
> Thanks for your comments!
>
> [1] https://lore.kernel.org/r/cover.1714642390.git.geert+renesas@glider.be
>
> Geert Uytterhoeven (8):
>   dt-bindings: fuse: Document R-Car E-FUSE / PFC
>   dt-bindings: fuse: Document R-Car E-FUSE / OTP_MEM
>   soc: renesas: Add R-Car fuse driver
>   pinctrl: renesas: Add R-Car Gen3 fuse support
>   arm64: dts: renesas: r8a779a0: Add E-FUSE node
>   arm64: dts: renesas: r8a779f0: Add E-FUSE node
>   arm64: dts: renesas: r8a779g0: Add OTP_MEM node
>   arm64: dts: renesas: r8a779h0: Add OTP_MEM node
>
>  .../bindings/fuse/renesas,rcar-efuse.yaml     |  55 +++++
>  .../bindings/fuse/renesas,rcar-otp.yaml       |  38 ++++
>  arch/arm64/boot/dts/renesas/r8a779a0.dtsi     |   8 +
>  arch/arm64/boot/dts/renesas/r8a779f0.dtsi     |   8 +
>  arch/arm64/boot/dts/renesas/r8a779g0.dtsi     |   5 +
>  arch/arm64/boot/dts/renesas/r8a779h0.dtsi     |   5 +
>  drivers/pinctrl/renesas/core.c                |  18 ++
>  drivers/pinctrl/renesas/pfc-r8a77951.c        |   2 +
>  drivers/pinctrl/renesas/pfc-r8a7796.c         |   4 +
>  drivers/pinctrl/renesas/pfc-r8a77965.c        |   2 +
>  drivers/pinctrl/renesas/pfc-r8a77970.c        |   2 +
>  drivers/pinctrl/renesas/pfc-r8a77980.c        |  14 +-
>  drivers/pinctrl/renesas/pfc-r8a77990.c        |   2 +
>  drivers/pinctrl/renesas/pfc-r8a77995.c        |   2 +
>  drivers/pinctrl/renesas/sh_pfc.h              |   4 +-
>  drivers/soc/renesas/Kconfig                   |   8 +
>  drivers/soc/renesas/Makefile                  |   1 +
>  drivers/soc/renesas/rcar-fuse.c               | 201 ++++++++++++++++++
>  include/linux/platform_data/rcar_fuse.h       |  11 +
>  include/linux/soc/renesas/rcar-fuse.h         |  41 ++++
>  20 files changed, 429 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/fuse/renesas,rcar-efuse.yaml
>  create mode 100644 Documentation/devicetree/bindings/fuse/renesas,rcar-otp.yaml
>  create mode 100644 drivers/soc/renesas/rcar-fuse.c
>  create mode 100644 include/linux/platform_data/rcar_fuse.h
>  create mode 100644 include/linux/soc/renesas/rcar-fuse.h

Arnd pointed out on IRC this should probably be an nvmem driver instead
of an soc driver.  I had mimicked this after the Tegra fuse driver,
which is also an soc driver.  The in-kernel user would be its main
user. The nvmem interface exists just because the tegra driver did
the same.

After some investigation, it looks like this should use
Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml
instead, and handle it like e.g.
Documentation/devicetree/bindings/nvmem/sprd-efuse.txt?

Thanks for your guidance!

Link to this series:
https://lore.kernel.org/all/cover.1716974502.git.geert+renesas@glider.be/

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds