.../bindings/nvmem/google,gs101-otp.yaml | 61 +++++++++++++++++ arch/arm64/boot/dts/exynos/google/gs101.dtsi | 8 +++ drivers/soc/samsung/exynos-chipid.c | 79 ++++++++++++++++++---- 3 files changed, 135 insertions(+), 13 deletions(-)
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@google-gs:~# cat /sys/devices/soc0/family
Samsung Exynos
root@google-gs:~# cat /sys/devices/soc0/machine
Oriole
root@google-gs:~# cat /sys/devices/soc0/revision
11
root@google-gs:~# cat /sys/devices/soc0/soc_id
GS101
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
Changes in v4:
- bindings were not sent in v3, human error. Add them back. Compared to
v2, add clock-names property as it's needed for
devm_regmap_init_mmio_clk()
- driver: use devm_regmap_init_mmio_clk() to deal with clock aquisition
and enable/disable as needed.
- dt: add clock-names prop
- Rebase and collect R-b tags
- Link to v3: https://lore.kernel.org/r/20251120-gs101-chipid-v3-0-1aeaa8b7fe35@linaro.org
Changes in v3:
- rebase so that cleanups come before the gs101 support. The inclusion
of linux/device/devres.h is now done in the devm action patch, as it's
first needed there.
- update error message: s/failed to read sub revision/failed to read revision
- Link to v2: https://lore.kernel.org/r/20251118-gs101-chipid-v2-0-e9f1e7460e35@linaro.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 (5):
dt-bindings: nvmem: add google,gs101-otp
soc: samsung: exynos-chipid: rename method
soc: samsung: exynos-chipid: downgrade dev_info to dev_dbg for soc info
soc: samsung: exynos-chipid: add google,gs101-otp support
arm64: dts: exynos: gs101: add OTP node
.../bindings/nvmem/google,gs101-otp.yaml | 61 +++++++++++++++++
arch/arm64/boot/dts/exynos/google/gs101.dtsi | 8 +++
drivers/soc/samsung/exynos-chipid.c | 79 ++++++++++++++++++----
3 files changed, 135 insertions(+), 13 deletions(-)
---
base-commit: 0825f376d02e58e8ee4179569e0a386e1cd0eb76
change-id: 20251031-gs101-chipid-fd84da8afa2f
Best regards,
--
Tudor Ambarus <tudor.ambarus@linaro.org>
On Mon, 22 Dec 2025 16:30:04 +0000, Tudor Ambarus wrote:
> 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.
>
> [...]
Applied, thanks!
[5/5] arm64: dts: exynos: gs101: add OTP node
https://git.kernel.org/krzk/linux/c/9afdf3e1a59e23180540ecb1fe3287c308cc8113
Best regards,
--
Krzysztof Kozlowski <krzk@kernel.org>
On Mon, 22 Dec 2025 16:30:04 +0000, Tudor Ambarus wrote:
> 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.
>
> [...]
Applied, thanks!
[1/5] dt-bindings: nvmem: add google,gs101-otp
https://git.kernel.org/krzk/linux/c/12da6f08a07ddaddd336af878350d30449d23a54
[2/5] soc: samsung: exynos-chipid: rename method
https://git.kernel.org/krzk/linux/c/9133ae2119cb3c948675dc566eebf11cc4bb1681
[3/5] soc: samsung: exynos-chipid: downgrade dev_info to dev_dbg for soc info
https://git.kernel.org/krzk/linux/c/c38cfc303db9ab4d5f482ae8e36e5a677db8eee6
[4/5] soc: samsung: exynos-chipid: add google,gs101-otp support
https://git.kernel.org/krzk/linux/c/732af51910960535382db3f6e0b33e2e2b0ff7b6
Best regards,
--
Krzysztof Kozlowski <krzk@kernel.org>
© 2016 - 2026 Red Hat, Inc.