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: <20251118-gs101-chipid-v2-0-e9f1e7460e35@linaro.org>
Date: Tue, 18 Nov 2025 13:56:07 +0000
From: Tudor Ambarus <tudor.ambarus@...aro.org>
To: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
 Conor Dooley <conor+dt@...nel.org>, Alim Akhtar <alim.akhtar@...sung.com>, 
 Peter Griffin <peter.griffin@...aro.org>, 
 André Draszik <andre.draszik@...aro.org>, 
 Srinivas Kandagatla <srini@...nel.org>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, semen.protsenko@...aro.org, 
 willmcvicker@...gle.com, kernel-team@...roid.com, 
 devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
 linux-samsung-soc@...r.kernel.org, linux-kernel@...r.kernel.org, 
 Tudor Ambarus <tudor.ambarus@...aro.org>, 
 Krzysztof Kozlowski <krzk@...nel.org>
Subject: [PATCH v2 0/7] soc: samsung: exynos-chipid: add gs101 support

Dependency
==========
Typical dependency of the DT patch depending on the bindings patch,
thus the bindings patch could go via the Samsung SoC tree with
Srinivas's ack.

Description
===========
GS101 is different (but also e850 and autov9 I assume) from the SoCs
that are currently handled by the exynos-chipid driver because the
chip ID info is part of the OTP registers. GS101 OTP has a clock, an
interrupt line, a register space (that contains product and chip ID,
TMU data, ASV, etc) and a 32Kbit memory space that can be
read/program/locked with specific commands. On GS101 the "ChipID block"
is just an abstraction, it's not a physical device. When the power-on
sequence progresses, the OTP chipid values are loaded to the OTP
registers.

Add the GS101 chip ID support. The support is intentionally added in the
exynos-chipid driver, and not in a dedicated Exynos OTP driver, because
we estimate that there will not be any OTP consumers in the kernel other
than the chip ID/SoC interface. The downstream GS101 drivers confirm
this supposition.

Testing
=======
root@...gle-gs:~# cat /sys/devices/soc0/family
Samsung Exynos
root@...gle-gs:~# cat /sys/devices/soc0/machine
Oriole
root@...gle-gs:~# cat /sys/devices/soc0/revision
11
root@...gle-gs:~# cat /sys/devices/soc0/soc_id
GS101

Signed-off-by: Tudor Ambarus <tudor.ambarus@...aro.org>
---
Changes in v2:
- complete rework, treat it as a new patch set please.
- bindings were reviewed at:
  - Link: https://lore.kernel.org/linux-samsung-soc/27a5521cd7ddbed0e870ac416dc829722f1b36a5.camel@linaro.org/T/#me139353334db535806ca6462ae1e86b01ff032a7
  - addressed Andre's s/if of/is of
- part of the cleaning patches are from this trivial series:
  - Link: https://lore.kernel.org/linux-samsung-soc/20251112-chipid-trivial-v1-0-ec2dea03bd83@linaro.org/
- Link to v1: https://lore.kernel.org/r/20251031-gs101-chipid-v1-0-d78d1076b210@linaro.org

---
Tudor Ambarus (7):
      dt-bindings: nvmem: add google,gs101-otp
      soc: samsung: exynos-chipid: add google,gs101-otp support
      soc: samsung: exynos-chipid: use devm action to unregister soc device
      soc: samsung: exynos-chipid: use dev_err_probe where appropiate
      soc: samsung: exynos-chipid: rename method
      soc: samsung: exynos-chipid: downgrade dev_info to dev_dbg for soc info
      arm64: dts: exynos: gs101: add OTP node

 .../bindings/nvmem/google,gs101-otp.yaml           |  56 ++++++++
 arch/arm64/boot/dts/exynos/google/gs101.dtsi       |   7 +
 drivers/soc/samsung/exynos-chipid.c                | 148 +++++++++++++++------
 3 files changed, 168 insertions(+), 43 deletions(-)
---
base-commit: 4b67e4c65c1e0740ac12bd0d790eb5a9d0091aaa
change-id: 20251031-gs101-chipid-fd84da8afa2f

Best regards,
-- 
Tudor Ambarus <tudor.ambarus@...aro.org>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ