Add the chipid node.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
arch/arm64/boot/dts/exynos/google/gs101.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
index d06d1d05f36408137a8acd98e43d48ea7d4f4292..11622da2d46ff257b447a3dfdc98abdf29a45b9a 100644
--- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
+++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
@@ -467,6 +467,12 @@ opp-2802000000 {
};
};
+ chipid {
+ compatible = "google,gs101-chipid";
+ nvmem-cells = <&product_id>, <&chip_id>;
+ nvmem-cell-names = "product-id", "chip-id";
+ };
+
/* ect node is required to be present by bootloader */
ect {
};
--
2.51.1.930.gacf6e81ea2-googOn Fri, Oct 31, 2025 at 12:56:09PM +0000, Tudor Ambarus wrote:
> Add the chipid node.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> arch/arm64/boot/dts/exynos/google/gs101.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> index d06d1d05f36408137a8acd98e43d48ea7d4f4292..11622da2d46ff257b447a3dfdc98abdf29a45b9a 100644
> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> @@ -467,6 +467,12 @@ opp-2802000000 {
> };
> };
>
> + chipid {
> + compatible = "google,gs101-chipid";
That's not a real device, sorry.
I had some doubts when reading the bindings, then more when reading
driver - like chipid probe() was basically empty, no single device
access, except calling other kernel subsystem - and now here no single
actual hardware resource, except reference to other node.
Are you REALLY REALLY sure you have in your datasheet such device as
chipid?
It is damn basic question, which you should start with.
Best regards,
Krzysztof
On 11/3/25 12:18 PM, Krzysztof Kozlowski wrote:
> On Fri, Oct 31, 2025 at 12:56:09PM +0000, Tudor Ambarus wrote:
>> Add the chipid node.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>> ---
>> arch/arm64/boot/dts/exynos/google/gs101.dtsi | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>> index d06d1d05f36408137a8acd98e43d48ea7d4f4292..11622da2d46ff257b447a3dfdc98abdf29a45b9a 100644
>> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>> @@ -467,6 +467,12 @@ opp-2802000000 {
>> };
>> };
>>
>> + chipid {
>> + compatible = "google,gs101-chipid";
>
> That's not a real device, sorry.
>
> I had some doubts when reading the bindings, then more when reading
> driver - like chipid probe() was basically empty, no single device
> access, except calling other kernel subsystem - and now here no single
> actual hardware resource, except reference to other node.
>
> Are you REALLY REALLY sure you have in your datasheet such device as
> chipid?
>
> It is damn basic question, which you should start with.
Documentation says that GS101 "includes a CHIPID block for the software
that sends and receives APB interface signals to and from the bus system.
The first address of the SFR region (0x1000_0000) contains the product ID."
0x1000_0000 is the base address of the OTP controller (OTP_CON_TOP).
"CHIPID block" tells it's a device, no? But now I think it was just an
unfortunate datasheet description. Do you have an advice on how I shall
treat this next please? Maybe register to the soc interface directly from
the OTP controller driver?
Thanks!
ta
On 03/11/2025 11:50, Tudor Ambarus wrote:
>
>
> On 11/3/25 12:18 PM, Krzysztof Kozlowski wrote:
>> On Fri, Oct 31, 2025 at 12:56:09PM +0000, Tudor Ambarus wrote:
>>> Add the chipid node.
>>>
>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>>> ---
>>> arch/arm64/boot/dts/exynos/google/gs101.dtsi | 6 ++++++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>>> index d06d1d05f36408137a8acd98e43d48ea7d4f4292..11622da2d46ff257b447a3dfdc98abdf29a45b9a 100644
>>> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>>> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>>> @@ -467,6 +467,12 @@ opp-2802000000 {
>>> };
>>> };
>>>
>>> + chipid {
>>> + compatible = "google,gs101-chipid";
>>
>> That's not a real device, sorry.
>>
>> I had some doubts when reading the bindings, then more when reading
>> driver - like chipid probe() was basically empty, no single device
>> access, except calling other kernel subsystem - and now here no single
>> actual hardware resource, except reference to other node.
>>
>> Are you REALLY REALLY sure you have in your datasheet such device as
>> chipid?
>>
>> It is damn basic question, which you should start with.
>
> Documentation says that GS101 "includes a CHIPID block for the software
> that sends and receives APB interface signals to and from the bus system.
> The first address of the SFR region (0x1000_0000) contains the product ID."
So chipid@1000_0000
>
> 0x1000_0000 is the base address of the OTP controller (OTP_CON_TOP).
and efuse@1000_0000 from your other patchset and your sentence above.
Please add them to DTS and check for warnings.
>
> "CHIPID block" tells it's a device, no? But now I think it was just an
> unfortunate datasheet description. Do you have an advice on how I shall
> treat this next please? Maybe register to the soc interface directly from
> the OTP controller driver?
I think in the SoC it is impossible or at least never happening that you
create two devices for the same address, therefore either chipid is a
device or efuse is a device.
Best regards,
Krzysztof
On 11/4/25 9:14 AM, Krzysztof Kozlowski wrote:
> On 03/11/2025 11:50, Tudor Ambarus wrote:
>>
>>
>> On 11/3/25 12:18 PM, Krzysztof Kozlowski wrote:
>>> On Fri, Oct 31, 2025 at 12:56:09PM +0000, Tudor Ambarus wrote:
>>>> Add the chipid node.
>>>>
>>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>>>> ---
>>>> arch/arm64/boot/dts/exynos/google/gs101.dtsi | 6 ++++++
>>>> 1 file changed, 6 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>>>> index d06d1d05f36408137a8acd98e43d48ea7d4f4292..11622da2d46ff257b447a3dfdc98abdf29a45b9a 100644
>>>> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>>>> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>>>> @@ -467,6 +467,12 @@ opp-2802000000 {
>>>> };
>>>> };
>>>>
>>>> + chipid {
>>>> + compatible = "google,gs101-chipid";
>>>
>>> That's not a real device, sorry.
>>>
>>> I had some doubts when reading the bindings, then more when reading
>>> driver - like chipid probe() was basically empty, no single device
>>> access, except calling other kernel subsystem - and now here no single
>>> actual hardware resource, except reference to other node.
>>>
>>> Are you REALLY REALLY sure you have in your datasheet such device as
>>> chipid?
>>>
>>> It is damn basic question, which you should start with.
>>
>> Documentation says that GS101 "includes a CHIPID block for the software
>> that sends and receives APB interface signals to and from the bus system.
>> The first address of the SFR region (0x1000_0000) contains the product ID."
>
> So chipid@1000_0000
>
>>
>> 0x1000_0000 is the base address of the OTP controller (OTP_CON_TOP).
>
>
> and efuse@1000_0000 from your other patchset and your sentence above.
>
> Please add them to DTS and check for warnings.
One would get an unique_unit_address warning, yes.
>
>>
>> "CHIPID block" tells it's a device, no? But now I think it was just an
>> unfortunate datasheet description. Do you have an advice on how I shall
>> treat this next please? Maybe register to the soc interface directly from
>> the OTP controller driver?
> I think in the SoC it is impossible or at least never happening that you
> create two devices for the same address, therefore either chipid is a
> device or efuse is a device.
>
Right. The ChipID "block" does not have its own registers. It references
the OTP registers. I'll describe just the efuse device in the DT and
register to the soc interface directly from the efuse driver. Please let
me know if you think there's a better way to handle this.
Thanks,
ta
On 03/11/2025 11:50, Tudor Ambarus wrote:
>
>
> On 11/3/25 12:18 PM, Krzysztof Kozlowski wrote:
>> On Fri, Oct 31, 2025 at 12:56:09PM +0000, Tudor Ambarus wrote:
>>> Add the chipid node.
>>>
>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>>> ---
>>> arch/arm64/boot/dts/exynos/google/gs101.dtsi | 6 ++++++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>>> index d06d1d05f36408137a8acd98e43d48ea7d4f4292..11622da2d46ff257b447a3dfdc98abdf29a45b9a 100644
>>> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>>> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>>> @@ -467,6 +467,12 @@ opp-2802000000 {
>>> };
>>> };
>>>
>>> + chipid {
>>> + compatible = "google,gs101-chipid";
>>
>> That's not a real device, sorry.
>>
>> I had some doubts when reading the bindings, then more when reading
>> driver - like chipid probe() was basically empty, no single device
>> access, except calling other kernel subsystem - and now here no single
>> actual hardware resource, except reference to other node.
>>
>> Are you REALLY REALLY sure you have in your datasheet such device as
>> chipid?
>>
>> It is damn basic question, which you should start with.
>
> Documentation says that GS101 "includes a CHIPID block for the software
> that sends and receives APB interface signals to and from the bus system.
> The first address of the SFR region (0x1000_0000) contains the product ID."
>
> 0x1000_0000 is the base address of the OTP controller (OTP_CON_TOP).
>
> "CHIPID block" tells it's a device, no? But now I think it was just an
> unfortunate datasheet description. Do you have an advice on how I shall
> treat this next please? Maybe register to the soc interface directly from
> the OTP controller driver?
>
Huh, then I am confused, because:
1. That's the same message as in other Exynos and it has SFR region
2. Your binding said there is no SFR region.
3. Anyway, please post complete DTS, so if this has SFR region it must
have proper reg entry. You cannot skip it.
Of course next question would be what is the OTP controller...
Best regards,
Krzysztof
On 11/3/25 1:01 PM, Krzysztof Kozlowski wrote:
> On 03/11/2025 11:50, Tudor Ambarus wrote:
>>
>>
>> On 11/3/25 12:18 PM, Krzysztof Kozlowski wrote:
>>> On Fri, Oct 31, 2025 at 12:56:09PM +0000, Tudor Ambarus wrote:
>>>> Add the chipid node.
>>>>
>>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>>>> ---
>>>> arch/arm64/boot/dts/exynos/google/gs101.dtsi | 6 ++++++
>>>> 1 file changed, 6 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>>>> index d06d1d05f36408137a8acd98e43d48ea7d4f4292..11622da2d46ff257b447a3dfdc98abdf29a45b9a 100644
>>>> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>>>> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>>>> @@ -467,6 +467,12 @@ opp-2802000000 {
>>>> };
>>>> };
>>>>
>>>> + chipid {
>>>> + compatible = "google,gs101-chipid";
>>>
>>> That's not a real device, sorry.
>>>
>>> I had some doubts when reading the bindings, then more when reading
>>> driver - like chipid probe() was basically empty, no single device
>>> access, except calling other kernel subsystem - and now here no single
>>> actual hardware resource, except reference to other node.
>>>
>>> Are you REALLY REALLY sure you have in your datasheet such device as
>>> chipid?
>>>
>>> It is damn basic question, which you should start with.
>>
>> Documentation says that GS101 "includes a CHIPID block for the software
>> that sends and receives APB interface signals to and from the bus system.
>> The first address of the SFR region (0x1000_0000) contains the product ID."
>>
>> 0x1000_0000 is the base address of the OTP controller (OTP_CON_TOP).
>>
>> "CHIPID block" tells it's a device, no? But now I think it was just an
>> unfortunate datasheet description. Do you have an advice on how I shall
>> treat this next please? Maybe register to the soc interface directly from
>> the OTP controller driver?
>>
>
>
> Huh, then I am confused, because:
> 1. That's the same message as in other Exynos and it has SFR region
> 2. Your binding said there is no SFR region.
> 3. Anyway, please post complete DTS, so if this has SFR region it must
> have proper reg entry. You cannot skip it.
>
> Of course next question would be what is the OTP controller...
The CHIPID block, which has a dedicated chapter and all :), consists of two
registers:
Product ID
Address = Base Address (0x1000_0000) + 0x0000, Reset Value = 0xE383_0000
Chipid 3
Address = Base Address (0x1000_0000) + 0x0010, Reset Value = 0x0000_0000
While the Product ID is fixed (fused I assume), the CHIPID registers:
"depend on the OTP value. When the power-on sequence progresses, the OTP
values are loaded to the registers. These registers can read the loaded
current OTP values."
OTP values are from the OTP memory (32Kbit) from address 5'b00000, 160 bits
in total. Even if not explicitly stated, I think the OTP controller copies
the CHIP ID from the OTP memory to its registers, so that the "CHIPID block"
can access them. You notice that the reset value of the CHIPID OTP registers
is zero. They're then filled at power-on.
This is all. I lean towards thinking the CHIPID block is not really a device.
It's just a way software gets the product and chip IDs, which is by querying
the OTP registers. I think I lean towards registering to the soc interface
directly via the OTP device. Or maybe you think differently?
Thanks,
ta
© 2016 - 2026 Red Hat, Inc.