diff options
| author | Tudor Ambarus <tudor.ambarus@linaro.org> | 2025-12-22 16:30:08 +0000 |
|---|---|---|
| committer | Krzysztof Kozlowski <krzk@kernel.org> | 2025-12-28 12:31:38 +0100 |
| commit | 732af51910960535382db3f6e0b33e2e2b0ff7b6 (patch) | |
| tree | a20edf49f0d1dc1bdb49c317154e18f3b9766302 /include/linux/platform_data | |
| parent | c38cfc303db9ab4d5f482ae8e36e5a677db8eee6 (diff) | |
soc: samsung: exynos-chipid: add google,gs101-otp support
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.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Reviewed-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20251222-gs101-chipid-v4-4-aa8e20ce7bb3@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Diffstat (limited to 'include/linux/platform_data')
0 files changed, 0 insertions, 0 deletions
