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-next>] [day] [month] [year] [list]
Message-Id: <cover.1727963347.git.geert+renesas@glider.be>
Date: Thu,  3 Oct 2024 16:04:24 +0200
From: Geert Uytterhoeven <geert+renesas@...der.be>
To: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Magnus Damm <magnus.damm@...il.com>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
	Arnd Bergmann <arnd@...db.de>
Cc: devicetree@...r.kernel.org,
	linux-renesas-soc@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Geert Uytterhoeven <geert+renesas@...der.be>
Subject: [PATCH v3 resend 0/7] Add Renesas R-Car Gen4 E-FUSE support

	Hi all,

(another rc1, so time for a resend)

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.

As the first variant is quite different from the other two, and there is
currently no use case requiring support for it, this patch series adds
support for the last 2 variants only.

Note that the first two revisions of this series implemented only basic
nvmem support, and a custom in-kernel API, mimicked after the
fuse-tregra driver.  Then, Arnd told me on IRC that the R-Car E-FUSE
driver should use the nvmem framework fully.

The fuses' states can be read using the nvmem subsystem:
  - In kernelspace, through the nvmem_cell_*() API.
    A first known use case is reading tuning parameters for the
    Universal Flash Storage controller on R-Car S4-8 ES1.2.

  - In userspace, through sysfs. E.g. on R-Car S4-8 ES1.2:
    / # hd /sys/bus/nvmem/devices/rcar-fuse/nvmem
    00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    000000e0  00 00 00 00 fe 00 00 00  00 00 00 00 00 00 00 00  |....�...........|
    000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    00000140  00 00 00 00 23 51 23 51  52 98 52 98 00 00 00 00  |....#Q#QR�R�....|
    00000150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    00000200

Previous v3 submission[3]:
  - Some discussion about #nvmem-cell-cells = <0>, no changes.

Changes compared to v2[2]:
  - Dropped accepted dt-bindings,
  - Drop "pinctrl: renesas: Add R-Car Gen3 fuse support",
  - New patch "dt-bindings: fuse: Move renesas,rcar-{efuse,otp} to
    nvmem",
  - Drop superfluous semicolon,
  - Drop the custom rcar_fuse_read() kernel API, in favor of the
    standard nvmem_cell_*() API,
  - Drop support for explicitly-instantiated platform devices with
    accompanying platform data, which would be needed to support fuses
    tightly integrated with the Pin Function Controller on R-Car Gen3
    SoCs.  It can be added when a use case shows up.
  - Move from drivers/soc/renesas/ to drivers/nvmem/,
  - Register the full register block that contains the E-FUSE data
    registers with the nvmem subsystem, but use keepouts to ignore all
    registers before the first or after the last documented data
    register.  Undocumented registers in between are still accessible.
  - Replace offset/nregs in rcar_fuse_data by start/end,
  - Use __ioread32_copy() helper,
  - Initialize most fields of struct nvmem_config in its declaration,
  - Rename nvmem device from "fuse" to "rcar-fuse",
  - Use NVMEM_DEVID_NONE,
  - Add an entry to the MAINTAINERS file,
  - Fix reg size,
  - New patch "arm64: dts: renesas: r8a779f4: Add UFS tuning parameters
    in E-FUSE".

Changes compared to v1[3]:
  - Drop RFC state and broaden audience,
  - Fix typo in one-line summary,
  - Add Reviewed-by.

This has been tested on R-Car V3U, S4-8 ES1.0 and ES1.2, V4H, and V4M.

Thanks for your comments!

[1] https://lore.kernel.org/cover.1721999833.git.geert+renesas@glider.be
[2] https://lore.kernel.org/cover.1716974502.git.geert+renesas@glider.be
[3] https://lore.kernel.org/cover.1714642390.git.geert+renesas@glider.be

Geert Uytterhoeven (7):
  dt-bindings: fuse: Move renesas,rcar-{efuse,otp} to nvmem
  nvmem: Add R-Car E-FUSE driver
  arm64: dts: renesas: r8a779a0: Add E-FUSE node
  arm64: dts: renesas: r8a779f0: Add E-FUSE node
  arm64: dts: renesas: r8a779f4: Add UFS tuning parameters in E-FUSE
  arm64: dts: renesas: r8a779g0: Add OTP_MEM node
  arm64: dts: renesas: r8a779h0: Add OTP_MEM node

 .../{fuse => nvmem}/renesas,rcar-efuse.yaml   |  35 +++--
 .../{fuse => nvmem}/renesas,rcar-otp.yaml     |  17 ++-
 MAINTAINERS                                   |   2 +
 arch/arm64/boot/dts/renesas/r8a779a0.dtsi     |   8 +
 arch/arm64/boot/dts/renesas/r8a779f0.dtsi     |   8 +
 arch/arm64/boot/dts/renesas/r8a779f4.dtsi     |  12 ++
 arch/arm64/boot/dts/renesas/r8a779g0.dtsi     |   5 +
 arch/arm64/boot/dts/renesas/r8a779h0.dtsi     |   5 +
 drivers/nvmem/Kconfig                         |  11 ++
 drivers/nvmem/Makefile                        |   2 +
 drivers/nvmem/rcar-efuse.c                    | 142 ++++++++++++++++++
 11 files changed, 230 insertions(+), 17 deletions(-)
 rename Documentation/devicetree/bindings/{fuse => nvmem}/renesas,rcar-efuse.yaml (54%)
 rename Documentation/devicetree/bindings/{fuse => nvmem}/renesas,rcar-otp.yaml (60%)
 create mode 100644 drivers/nvmem/rcar-efuse.c

-- 
2.34.1

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ