[PATCH 00/12] i3c: Support ACPI and SETAASA device discovery

[PATCH 00/12] i3c: Support ACPI and SETAASA device discovery

[Akhil R]

This patch series adds SETAASA device discovery to the I3C subsystem,
enabling support for SPD5118 temperature sensors found on DDR5 memory
modules. The changes also add ACPI support for all existing DAA
methods like SETDASA, SETNEWDA as well as I2C devices on I3C bus.

SPD5118 and similar devices on DDR5 memory modules differ from typical
I3C devices in their initialization. They use SETAASA broadcast CCC
instead of ENTDAA for address assignment, and per JEDEC specification,
are not required to have a Provisioned ID or implement standard device
information CCC commands (GETPID, GETDCR, GETBCR).

The series enables to describe all I3C and I2C devices on both Device
Tree and the ACPI table, using unified device property APIs throughout
the I3C core and the Synopsys DesignWare I3C master driver.

Please note that the series modifies drivers across multiple subsystems,
like Device Tree bindings, ACPI, I3C and HWMON.

Akhil R (12):
  dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA
  ACPICA: Read LVR from the I2C resource descriptor
  i3c: master: Use unified device property interface
  i3c: master: Support ACPI enumeration
  i3c: master: Add support for devices using SETAASA
  i3c: master: Add support for devices without PID
  i3c: master: match I3C device through DT and ACPI
  i3c: dw-i3c-master: Add SETAASA as supported CCC
  i3c: dw-i3c-master: Add a quirk to skip clock and reset
  i3c: dw-i3c-master: Add ACPI ID for Tegra410
  hwmon: spd5118: Add I3C support
  arm64: defconfig: Enable I3C and SPD5118 hwmon

 .../devicetree/bindings/i3c/i3c.yaml          |  30 +-
 arch/arm64/configs/defconfig                  |   3 +
 drivers/acpi/acpica/rsserial.c                |   6 +-
 drivers/hwmon/Kconfig                         |   7 +-
 drivers/hwmon/spd5118.c                       |  66 +++-
 drivers/i3c/master.c                          | 327 +++++++++++++++---
 drivers/i3c/master/dw-i3c-master.c            |  66 ++--
 include/acpi/acrestyp.h                       |   1 +
 include/linux/i3c/ccc.h                       |   1 +
 include/linux/i3c/master.h                    |  22 +-
 10 files changed, 439 insertions(+), 90 deletions(-)

-- 
2.50.1

[PATCH 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA

[Akhil R]

Add the 'mipi-i3c-static-method' property mentioned in the MIPI I3C
Discovery and Configuration Specification [1] to specify which discovery
method an I3C device supports during bus initialization. The property is
a bitmap, where a bit value of 1 indicates support for that method, and 0
indicates lack of support.
Bit 0: SETDASA CCC (Direct)
Bit 1: SETAASA CCC (Broadcast)
Bit 2: Other CCC (vendor / standards extension)
All other bits are reserved.

It is specifically needed when an I3C device requires SETAASA for the
address assignment. SETDASA will be supported by default if this property
is absent - which means for now the property just serves as a flag to
enable SETAASA, but keep the property as a bitmap to align with the
specifications.

[1] https://www.mipi.org/specifications/disco

Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
 .../devicetree/bindings/i3c/i3c.yaml          | 30 ++++++++++++++++---
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
index e25fa72fd785..1705d90d4d79 100644
--- a/Documentation/devicetree/bindings/i3c/i3c.yaml
+++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
@@ -31,10 +31,12 @@ properties:
       described in the device tree, which in turn means we have to describe
       I3C devices.
 
-      Another use case for describing an I3C device in the device tree is when
-      this I3C device has a static I2C address and we want to assign it a
-      specific I3C dynamic address before the DAA takes place (so that other
-      devices on the bus can't take this dynamic address).
+      Other use-cases for describing an I3C device in the device tree are:
+      - When the I3C device has a static I2C address and we want to assign
+        it a specific I3C dynamic address before the DAA takes place (so
+        that other devices on the bus can't take this dynamic address).
+      - When the I3C device requires SETAASA for its discovery and uses a
+        pre-defined static address.
 
   "#size-cells":
     const: 0
@@ -147,6 +149,26 @@ patternProperties:
           through SETDASA. If static address is not present, this address is assigned
           through SETNEWDA after assigning a temporary address via ENTDAA.
 
+      mipi-i3c-static-method:
+        $ref: /schemas/types.yaml#/definitions/uint32
+        minimum: 0x1
+        maximum: 0xff
+        default: 1
+        description: |
+          Bitmap describing which methods of Dynamic Address Assignment from a
+          static address are supported by this I3C Target. A bit value of 1
+          indicates support for that method, and 0 indicates lack of support.
+          Bit 0: SETDASA CCC (Direct)
+          Bit 1: SETAASA CCC (Broadcast)
+          Bit 2: Other CCC (vendor / standards extension)
+          All other bits are reserved.
+
+          This property follows the MIPI I3C specification. The primary use
+          of this property is to indicate support for SETAASA, i.e Bit 1, but
+          will allow all values so that it is aligned with the specifications.
+          SETDASA will remain as the default method even if this property is
+          not present.
+
     required:
       - reg
 
-- 
2.50.1

Re: [PATCH 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 3676 bytes --]

On Wed, Mar 18, 2026 at 10:57:14PM +0530, Akhil R wrote:
> Add the 'mipi-i3c-static-method' property mentioned in the MIPI I3C
> Discovery and Configuration Specification [1] to specify which discovery
> method an I3C device supports during bus initialization. The property is
> a bitmap, where a bit value of 1 indicates support for that method, and 0
> indicates lack of support.
> Bit 0: SETDASA CCC (Direct)
> Bit 1: SETAASA CCC (Broadcast)
> Bit 2: Other CCC (vendor / standards extension)
> All other bits are reserved.
> 
> It is specifically needed when an I3C device requires SETAASA for the
> address assignment. SETDASA will be supported by default if this property
> is absent - which means for now the property just serves as a flag to
> enable SETAASA, but keep the property as a bitmap to align with the
> specifications.
> 
> [1] https://www.mipi.org/specifications/disco
> 
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> ---
>  .../devicetree/bindings/i3c/i3c.yaml          | 30 ++++++++++++++++---
>  1 file changed, 26 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
> index e25fa72fd785..1705d90d4d79 100644
> --- a/Documentation/devicetree/bindings/i3c/i3c.yaml
> +++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
> @@ -31,10 +31,12 @@ properties:
>        described in the device tree, which in turn means we have to describe
>        I3C devices.
>  
> -      Another use case for describing an I3C device in the device tree is when
> -      this I3C device has a static I2C address and we want to assign it a
> -      specific I3C dynamic address before the DAA takes place (so that other
> -      devices on the bus can't take this dynamic address).
> +      Other use-cases for describing an I3C device in the device tree are:
> +      - When the I3C device has a static I2C address and we want to assign
> +        it a specific I3C dynamic address before the DAA takes place (so
> +        that other devices on the bus can't take this dynamic address).
> +      - When the I3C device requires SETAASA for its discovery and uses a
> +        pre-defined static address.
>  
>    "#size-cells":
>      const: 0
> @@ -147,6 +149,26 @@ patternProperties:
>            through SETDASA. If static address is not present, this address is assigned
>            through SETNEWDA after assigning a temporary address via ENTDAA.
>  
> +      mipi-i3c-static-method:
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        minimum: 0x1
> +        maximum: 0xff
> +        default: 1
> +        description: |
> +          Bitmap describing which methods of Dynamic Address Assignment from a
> +          static address are supported by this I3C Target. A bit value of 1
> +          indicates support for that method, and 0 indicates lack of support.

I really am not keen on properties that are bitmaps, why can't we just
use the strings "setdasa", "setaasa" etc?

> +          Bit 0: SETDASA CCC (Direct)
> +          Bit 1: SETAASA CCC (Broadcast)
> +          Bit 2: Other CCC (vendor / standards extension)
> +          All other bits are reserved.
> +
> +          This property follows the MIPI I3C specification. The primary use
> +          of this property is to indicate support for SETAASA, i.e Bit 1, but
> +          will allow all values so that it is aligned with the specifications.
> +          SETDASA will remain as the default method even if this property is
> +          not present.
> +
>      required:
>        - reg
>  
> -- 
> 2.50.1
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA

[Akhil R]

On Wed, 18 Mar 2026 17:31:50 +0000, Conor Dooley wrote:
> On Wed, Mar 18, 2026 at 10:57:14PM +0530, Akhil R wrote:
>> Add the 'mipi-i3c-static-method' property mentioned in the MIPI I3C
>> Discovery and Configuration Specification [1] to specify which discovery
>> method an I3C device supports during bus initialization. The property is
>> a bitmap, where a bit value of 1 indicates support for that method, and 0
>> indicates lack of support.
>> Bit 0: SETDASA CCC (Direct)
>> Bit 1: SETAASA CCC (Broadcast)
>> Bit 2: Other CCC (vendor / standards extension)
>> All other bits are reserved.
>> 
>> It is specifically needed when an I3C device requires SETAASA for the
>> address assignment. SETDASA will be supported by default if this property
>> is absent - which means for now the property just serves as a flag to
>> enable SETAASA, but keep the property as a bitmap to align with the
>> specifications.
>> 
>> [1] https://www.mipi.org/specifications/disco
>> 
>> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
>> ---
>>  .../devicetree/bindings/i3c/i3c.yaml          | 30 ++++++++++++++++---
>>  1 file changed, 26 insertions(+), 4 deletions(-)
>> 
>> diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
>> index e25fa72fd785..1705d90d4d79 100644
>> --- a/Documentation/devicetree/bindings/i3c/i3c.yaml
>> +++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
>> @@ -31,10 +31,12 @@ properties:
>>        described in the device tree, which in turn means we have to describe
>>        I3C devices.
>>  
>> -      Another use case for describing an I3C device in the device tree is when
>> -      this I3C device has a static I2C address and we want to assign it a
>> -      specific I3C dynamic address before the DAA takes place (so that other
>> -      devices on the bus can't take this dynamic address).
>> +      Other use-cases for describing an I3C device in the device tree are:
>> +      - When the I3C device has a static I2C address and we want to assign
>> +        it a specific I3C dynamic address before the DAA takes place (so
>> +        that other devices on the bus can't take this dynamic address).
>> +      - When the I3C device requires SETAASA for its discovery and uses a
>> +        pre-defined static address.
>>  
>>    "#size-cells":
>>      const: 0
>> @@ -147,6 +149,26 @@ patternProperties:
>>            through SETDASA. If static address is not present, this address is assigned
>>            through SETNEWDA after assigning a temporary address via ENTDAA.
>>  
>> +      mipi-i3c-static-method:
>> +        $ref: /schemas/types.yaml#/definitions/uint32
>> +        minimum: 0x1
>> +        maximum: 0xff
>> +        default: 1
>> +        description: |
>> +          Bitmap describing which methods of Dynamic Address Assignment from a
>> +          static address are supported by this I3C Target. A bit value of 1
>> +          indicates support for that method, and 0 indicates lack of support.
> 
> I really am not keen on properties that are bitmaps, why can't we just
> use the strings "setdasa", "setaasa" etc?

The intention was to mirror the property described in the specification. Using
strings would not allow to use a combination of methods when a device supports
more than one method. It also cannot represent the vendor extensions (Bit 2)
cleanly. Would this be better if we use macros instead of raw numbers?
Please let me know your thoughts.

> 
>> +          Bit 0: SETDASA CCC (Direct)
>> +          Bit 1: SETAASA CCC (Broadcast)
>> +          Bit 2: Other CCC (vendor / standards extension)
>> +          All other bits are reserved.
>> +
>> +          This property follows the MIPI I3C specification. The primary use
>> +          of this property is to indicate support for SETAASA, i.e Bit 1, but
>> +          will allow all values so that it is aligned with the specifications.
>> +          SETDASA will remain as the default method even if this property is
>> +          not present.
>> +
>>      required:
>>        - reg

Best Regards,
Akhil

Re: [PATCH 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA

[Krzysztof Kozlowski]

On Thu, Mar 19, 2026 at 02:16:41PM +0530, Akhil R wrote:
> On Wed, 18 Mar 2026 17:31:50 +0000, Conor Dooley wrote:
> > On Wed, Mar 18, 2026 at 10:57:14PM +0530, Akhil R wrote:
> >> Add the 'mipi-i3c-static-method' property mentioned in the MIPI I3C
> >> Discovery and Configuration Specification [1] to specify which discovery
> >> method an I3C device supports during bus initialization. The property is
> >> a bitmap, where a bit value of 1 indicates support for that method, and 0
> >> indicates lack of support.
> >> Bit 0: SETDASA CCC (Direct)
> >> Bit 1: SETAASA CCC (Broadcast)
> >> Bit 2: Other CCC (vendor / standards extension)
> >> All other bits are reserved.
> >> 
> >> It is specifically needed when an I3C device requires SETAASA for the
> >> address assignment. SETDASA will be supported by default if this property
> >> is absent - which means for now the property just serves as a flag to
> >> enable SETAASA, but keep the property as a bitmap to align with the
> >> specifications.
> >> 
> >> [1] https://www.mipi.org/specifications/disco
> >> 
> >> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> >> ---
> >>  .../devicetree/bindings/i3c/i3c.yaml          | 30 ++++++++++++++++---
> >>  1 file changed, 26 insertions(+), 4 deletions(-)
> >> 
> >> diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
> >> index e25fa72fd785..1705d90d4d79 100644
> >> --- a/Documentation/devicetree/bindings/i3c/i3c.yaml
> >> +++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
> >> @@ -31,10 +31,12 @@ properties:
> >>        described in the device tree, which in turn means we have to describe
> >>        I3C devices.
> >>  
> >> -      Another use case for describing an I3C device in the device tree is when
> >> -      this I3C device has a static I2C address and we want to assign it a
> >> -      specific I3C dynamic address before the DAA takes place (so that other
> >> -      devices on the bus can't take this dynamic address).
> >> +      Other use-cases for describing an I3C device in the device tree are:
> >> +      - When the I3C device has a static I2C address and we want to assign
> >> +        it a specific I3C dynamic address before the DAA takes place (so
> >> +        that other devices on the bus can't take this dynamic address).
> >> +      - When the I3C device requires SETAASA for its discovery and uses a
> >> +        pre-defined static address.
> >>  
> >>    "#size-cells":
> >>      const: 0
> >> @@ -147,6 +149,26 @@ patternProperties:
> >>            through SETDASA. If static address is not present, this address is assigned
> >>            through SETNEWDA after assigning a temporary address via ENTDAA.
> >>  
> >> +      mipi-i3c-static-method:
> >> +        $ref: /schemas/types.yaml#/definitions/uint32
> >> +        minimum: 0x1
> >> +        maximum: 0xff
> >> +        default: 1
> >> +        description: |
> >> +          Bitmap describing which methods of Dynamic Address Assignment from a
> >> +          static address are supported by this I3C Target. A bit value of 1
> >> +          indicates support for that method, and 0 indicates lack of support.
> > 
> > I really am not keen on properties that are bitmaps, why can't we just
> > use the strings "setdasa", "setaasa" etc?
> 
> The intention was to mirror the property described in the specification. Using
> strings would not allow to use a combination of methods when a device supports

Why combination would not be allowed? Look:
mipi-i3c-static-methods = "setdasa", "setaasa";
Both are allowed.

> more than one method. It also cannot represent the vendor extensions (Bit 2)
> cleanly. Would this be better if we use macros instead of raw numbers?

Hoes does setting bit 2 differ from a string "vendor"?

> Please let me know your thoughts.
> 

Best regards,
Krzysztof

Re: [PATCH 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA

[Akhil R]

On Thu, 19 Mar 2026 10:39:32 +0100, Krzysztof Kozlowski wrote:
> On Thu, Mar 19, 2026 at 02:16:41PM +0530, Akhil R wrote:
>> On Wed, 18 Mar 2026 17:31:50 +0000, Conor Dooley wrote:
>> > On Wed, Mar 18, 2026 at 10:57:14PM +0530, Akhil R wrote:
>> >> Add the 'mipi-i3c-static-method' property mentioned in the MIPI I3C
>> >> Discovery and Configuration Specification [1] to specify which discovery
>> >> method an I3C device supports during bus initialization. The property is
>> >> a bitmap, where a bit value of 1 indicates support for that method, and 0
>> >> indicates lack of support.
>> >> Bit 0: SETDASA CCC (Direct)
>> >> Bit 1: SETAASA CCC (Broadcast)
>> >> Bit 2: Other CCC (vendor / standards extension)
>> >> All other bits are reserved.
>> >> 
>> >> It is specifically needed when an I3C device requires SETAASA for the
>> >> address assignment. SETDASA will be supported by default if this property
>> >> is absent - which means for now the property just serves as a flag to
>> >> enable SETAASA, but keep the property as a bitmap to align with the
>> >> specifications.
>> >> 
>> >> [1] https://www.mipi.org/specifications/disco
>> >> 
>> >> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
>> >> ---
>> >>  .../devicetree/bindings/i3c/i3c.yaml          | 30 ++++++++++++++++---
>> >>  1 file changed, 26 insertions(+), 4 deletions(-)
>> >> 
>> >> diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
>> >> index e25fa72fd785..1705d90d4d79 100644
>> >> --- a/Documentation/devicetree/bindings/i3c/i3c.yaml
>> >> +++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
>> >> @@ -31,10 +31,12 @@ properties:
>> >>        described in the device tree, which in turn means we have to describe
>> >>        I3C devices.
>> >>  
>> >> -      Another use case for describing an I3C device in the device tree is when
>> >> -      this I3C device has a static I2C address and we want to assign it a
>> >> -      specific I3C dynamic address before the DAA takes place (so that other
>> >> -      devices on the bus can't take this dynamic address).
>> >> +      Other use-cases for describing an I3C device in the device tree are:
>> >> +      - When the I3C device has a static I2C address and we want to assign
>> >> +        it a specific I3C dynamic address before the DAA takes place (so
>> >> +        that other devices on the bus can't take this dynamic address).
>> >> +      - When the I3C device requires SETAASA for its discovery and uses a
>> >> +        pre-defined static address.
>> >>  
>> >>    "#size-cells":
>> >>      const: 0
>> >> @@ -147,6 +149,26 @@ patternProperties:
>> >>            through SETDASA. If static address is not present, this address is assigned
>> >>            through SETNEWDA after assigning a temporary address via ENTDAA.
>> >>  
>> >> +      mipi-i3c-static-method:
>> >> +        $ref: /schemas/types.yaml#/definitions/uint32
>> >> +        minimum: 0x1
>> >> +        maximum: 0xff
>> >> +        default: 1
>> >> +        description: |
>> >> +          Bitmap describing which methods of Dynamic Address Assignment from a
>> >> +          static address are supported by this I3C Target. A bit value of 1
>> >> +          indicates support for that method, and 0 indicates lack of support.
>> > 
>> > I really am not keen on properties that are bitmaps, why can't we just
>> > use the strings "setdasa", "setaasa" etc?
>> 
>> The intention was to mirror the property described in the specification. Using
>> strings would not allow to use a combination of methods when a device supports
> 
> Why combination would not be allowed? Look:
> mipi-i3c-static-methods = "setdasa", "setaasa";
> Both are allowed.
> 
>> more than one method. It also cannot represent the vendor extensions (Bit 2)
>> cleanly. Would this be better if we use macros instead of raw numbers?
> 
> Hoes does setting bit 2 differ from a string "vendor"?

Okay, a string array would handle those cases.

I am concerned if this can be a string array for the ACPI because the MIPI
specification defines the property differently. Would it be fine to deviate
from that specification in the ACPI? Or do you suggest to keep it as bitmap
for the ACPI and use strings in DT?

Best Regards,
Akhil

Re: [PATCH 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA

[Krzysztof Kozlowski]

On 19/03/2026 18:01, Akhil R wrote:
>>
>>> more than one method. It also cannot represent the vendor extensions (Bit 2)
>>> cleanly. Would this be better if we use macros instead of raw numbers?
>>
>> Hoes does setting bit 2 differ from a string "vendor"?
> 
> Okay, a string array would handle those cases.
> 
> I am concerned if this can be a string array for the ACPI because the MIPI
> specification defines the property differently. Would it be fine to deviate
> from that specification in the ACPI? Or do you suggest to keep it as bitmap
> for the ACPI and use strings in DT?

We are not defining here a property for the ACPI. I don't suggest
anything for ACPI.

Best regards,
Krzysztof

Re: [PATCH 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA

[Akhil R]

On Thu, 19 Mar 2026 18:14:41 +0100, Krzysztof Kozlowski wrote:
> On 19/03/2026 18:01, Akhil R wrote:
>>>
>>>> more than one method. It also cannot represent the vendor extensions (Bit 2)
>>>> cleanly. Would this be better if we use macros instead of raw numbers?
>>>
>>> Hoes does setting bit 2 differ from a string "vendor"?
>> 
>> Okay, a string array would handle those cases.
>> 
>> I am concerned if this can be a string array for the ACPI because the MIPI
>> specification defines the property differently. Would it be fine to deviate
>> from that specification in the ACPI? Or do you suggest to keep it as bitmap
>> for the ACPI and use strings in DT?
> 
> We are not defining here a property for the ACPI. I don't suggest
> anything for ACPI.

Understood. I will wait for responses in the driver changes to determine what
works best. This property is primarily intended for the ACPI and if it does
not align with DT, I would prefer to drop this from the binding in the next
revision - if you agree.

Best Regards,
Akhil

Re: [PATCH 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA

[Rob Herring]

On Wed, Mar 18, 2026 at 05:31:50PM +0000, Conor Dooley wrote:
> On Wed, Mar 18, 2026 at 10:57:14PM +0530, Akhil R wrote:
> > Add the 'mipi-i3c-static-method' property mentioned in the MIPI I3C
> > Discovery and Configuration Specification [1] to specify which discovery
> > method an I3C device supports during bus initialization. The property is
> > a bitmap, where a bit value of 1 indicates support for that method, and 0
> > indicates lack of support.
> > Bit 0: SETDASA CCC (Direct)
> > Bit 1: SETAASA CCC (Broadcast)
> > Bit 2: Other CCC (vendor / standards extension)
> > All other bits are reserved.
> > 
> > It is specifically needed when an I3C device requires SETAASA for the
> > address assignment. SETDASA will be supported by default if this property
> > is absent - which means for now the property just serves as a flag to
> > enable SETAASA, but keep the property as a bitmap to align with the
> > specifications.
> > 
> > [1] https://www.mipi.org/specifications/disco
> > 
> > Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> > ---
> >  .../devicetree/bindings/i3c/i3c.yaml          | 30 ++++++++++++++++---
> >  1 file changed, 26 insertions(+), 4 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
> > index e25fa72fd785..1705d90d4d79 100644
> > --- a/Documentation/devicetree/bindings/i3c/i3c.yaml
> > +++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
> > @@ -31,10 +31,12 @@ properties:
> >        described in the device tree, which in turn means we have to describe
> >        I3C devices.
> >  
> > -      Another use case for describing an I3C device in the device tree is when
> > -      this I3C device has a static I2C address and we want to assign it a
> > -      specific I3C dynamic address before the DAA takes place (so that other
> > -      devices on the bus can't take this dynamic address).
> > +      Other use-cases for describing an I3C device in the device tree are:
> > +      - When the I3C device has a static I2C address and we want to assign
> > +        it a specific I3C dynamic address before the DAA takes place (so
> > +        that other devices on the bus can't take this dynamic address).
> > +      - When the I3C device requires SETAASA for its discovery and uses a
> > +        pre-defined static address.
> >  
> >    "#size-cells":
> >      const: 0
> > @@ -147,6 +149,26 @@ patternProperties:
> >            through SETDASA. If static address is not present, this address is assigned
> >            through SETNEWDA after assigning a temporary address via ENTDAA.
> >  
> > +      mipi-i3c-static-method:
> > +        $ref: /schemas/types.yaml#/definitions/uint32
> > +        minimum: 0x1
> > +        maximum: 0xff
> > +        default: 1
> > +        description: |
> > +          Bitmap describing which methods of Dynamic Address Assignment from a
> > +          static address are supported by this I3C Target. A bit value of 1
> > +          indicates support for that method, and 0 indicates lack of support.
> 
> I really am not keen on properties that are bitmaps, why can't we just
> use the strings "setdasa", "setaasa" etc?

If this comes from a specification, then I'd tend to just copy it rather 
than invent our own thing. Obviously if is something structured 
fundamentally different from how DT is designed, then we wouldn't. But 
this is just a simple property.

Rob

Re: [PATCH 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA

[Alexandre Belloni]

On 26/03/2026 10:05:03-0500, Rob Herring wrote:
> On Wed, Mar 18, 2026 at 05:31:50PM +0000, Conor Dooley wrote:
> > On Wed, Mar 18, 2026 at 10:57:14PM +0530, Akhil R wrote:
> > > Add the 'mipi-i3c-static-method' property mentioned in the MIPI I3C
> > > Discovery and Configuration Specification [1] to specify which discovery
> > > method an I3C device supports during bus initialization. The property is
> > > a bitmap, where a bit value of 1 indicates support for that method, and 0
> > > indicates lack of support.
> > > Bit 0: SETDASA CCC (Direct)
> > > Bit 1: SETAASA CCC (Broadcast)
> > > Bit 2: Other CCC (vendor / standards extension)
> > > All other bits are reserved.
> > > 
> > > It is specifically needed when an I3C device requires SETAASA for the
> > > address assignment. SETDASA will be supported by default if this property
> > > is absent - which means for now the property just serves as a flag to
> > > enable SETAASA, but keep the property as a bitmap to align with the
> > > specifications.
> > > 
> > > [1] https://www.mipi.org/specifications/disco
> > > 
> > > Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> > > ---
> > >  .../devicetree/bindings/i3c/i3c.yaml          | 30 ++++++++++++++++---
> > >  1 file changed, 26 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
> > > index e25fa72fd785..1705d90d4d79 100644
> > > --- a/Documentation/devicetree/bindings/i3c/i3c.yaml
> > > +++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
> > > @@ -31,10 +31,12 @@ properties:
> > >        described in the device tree, which in turn means we have to describe
> > >        I3C devices.
> > >  
> > > -      Another use case for describing an I3C device in the device tree is when
> > > -      this I3C device has a static I2C address and we want to assign it a
> > > -      specific I3C dynamic address before the DAA takes place (so that other
> > > -      devices on the bus can't take this dynamic address).
> > > +      Other use-cases for describing an I3C device in the device tree are:
> > > +      - When the I3C device has a static I2C address and we want to assign
> > > +        it a specific I3C dynamic address before the DAA takes place (so
> > > +        that other devices on the bus can't take this dynamic address).
> > > +      - When the I3C device requires SETAASA for its discovery and uses a
> > > +        pre-defined static address.
> > >  
> > >    "#size-cells":
> > >      const: 0
> > > @@ -147,6 +149,26 @@ patternProperties:
> > >            through SETDASA. If static address is not present, this address is assigned
> > >            through SETNEWDA after assigning a temporary address via ENTDAA.
> > >  
> > > +      mipi-i3c-static-method:
> > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > +        minimum: 0x1
> > > +        maximum: 0xff
> > > +        default: 1
> > > +        description: |
> > > +          Bitmap describing which methods of Dynamic Address Assignment from a
> > > +          static address are supported by this I3C Target. A bit value of 1
> > > +          indicates support for that method, and 0 indicates lack of support.
> > 
> > I really am not keen on properties that are bitmaps, why can't we just
> > use the strings "setdasa", "setaasa" etc?
> 
> If this comes from a specification, then I'd tend to just copy it rather 
> than invent our own thing. Obviously if is something structured 
> fundamentally different from how DT is designed, then we wouldn't. But 
> this is just a simple property.
> 

The issue being that the specification is not public so it is difficult
to take any decision.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA

[Akhil R]

On Thu, 26 Mar 2026 16:44:31 +0100, Alexandre Belloni wrote:
> On 26/03/2026 10:05:03-0500, Rob Herring wrote:
>> On Wed, Mar 18, 2026 at 05:31:50PM +0000, Conor Dooley wrote:
>> > On Wed, Mar 18, 2026 at 10:57:14PM +0530, Akhil R wrote:
>> > > Add the 'mipi-i3c-static-method' property mentioned in the MIPI I3C
>> > > Discovery and Configuration Specification [1] to specify which discovery
>> > > method an I3C device supports during bus initialization. The property is
>> > > a bitmap, where a bit value of 1 indicates support for that method, and 0
>> > > indicates lack of support.
>> > > Bit 0: SETDASA CCC (Direct)
>> > > Bit 1: SETAASA CCC (Broadcast)
>> > > Bit 2: Other CCC (vendor / standards extension)
>> > > All other bits are reserved.
>> > > 
>> > > It is specifically needed when an I3C device requires SETAASA for the
>> > > address assignment. SETDASA will be supported by default if this property
>> > > is absent - which means for now the property just serves as a flag to
>> > > enable SETAASA, but keep the property as a bitmap to align with the
>> > > specifications.
>> > > 
>> > > [1] https://www.mipi.org/specifications/disco
>> > > 
>> > > Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
>> > > ---
>> > >  .../devicetree/bindings/i3c/i3c.yaml          | 30 ++++++++++++++++---
>> > >  1 file changed, 26 insertions(+), 4 deletions(-)
>> > > 
>> > > diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
>> > > index e25fa72fd785..1705d90d4d79 100644
>> > > --- a/Documentation/devicetree/bindings/i3c/i3c.yaml
>> > > +++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
>> > > @@ -31,10 +31,12 @@ properties:
>> > >        described in the device tree, which in turn means we have to describe
>> > >        I3C devices.
>> > >  
>> > > -      Another use case for describing an I3C device in the device tree is when
>> > > -      this I3C device has a static I2C address and we want to assign it a
>> > > -      specific I3C dynamic address before the DAA takes place (so that other
>> > > -      devices on the bus can't take this dynamic address).
>> > > +      Other use-cases for describing an I3C device in the device tree are:
>> > > +      - When the I3C device has a static I2C address and we want to assign
>> > > +        it a specific I3C dynamic address before the DAA takes place (so
>> > > +        that other devices on the bus can't take this dynamic address).
>> > > +      - When the I3C device requires SETAASA for its discovery and uses a
>> > > +        pre-defined static address.
>> > >  
>> > >    "#size-cells":
>> > >      const: 0
>> > > @@ -147,6 +149,26 @@ patternProperties:
>> > >            through SETDASA. If static address is not present, this address is assigned
>> > >            through SETNEWDA after assigning a temporary address via ENTDAA.
>> > >  
>> > > +      mipi-i3c-static-method:
>> > > +        $ref: /schemas/types.yaml#/definitions/uint32
>> > > +        minimum: 0x1
>> > > +        maximum: 0xff
>> > > +        default: 1
>> > > +        description: |
>> > > +          Bitmap describing which methods of Dynamic Address Assignment from a
>> > > +          static address are supported by this I3C Target. A bit value of 1
>> > > +          indicates support for that method, and 0 indicates lack of support.
>> > 
>> > I really am not keen on properties that are bitmaps, why can't we just
>> > use the strings "setdasa", "setaasa" etc?
>> 
>> If this comes from a specification, then I'd tend to just copy it rather 
>> than invent our own thing. Obviously if is something structured 
>> fundamentally different from how DT is designed, then we wouldn't. But 
>> this is just a simple property.
>> 
> 
> The issue being that the specification is not public so it is difficult
> to take any decision.

There is a public version available in the same link, but you would still
have to provide them a name and an email ID. The document will be sent to
the mail ID.

Regards,
Akhil

Re: [PATCH 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA

[Alexandre Belloni]

On 27/03/2026 13:48:58+0530, Akhil R wrote:
> On Thu, 26 Mar 2026 16:44:31 +0100, Alexandre Belloni wrote:
> > On 26/03/2026 10:05:03-0500, Rob Herring wrote:
> >> On Wed, Mar 18, 2026 at 05:31:50PM +0000, Conor Dooley wrote:
> >> > On Wed, Mar 18, 2026 at 10:57:14PM +0530, Akhil R wrote:
> >> > > Add the 'mipi-i3c-static-method' property mentioned in the MIPI I3C
> >> > > Discovery and Configuration Specification [1] to specify which discovery
> >> > > method an I3C device supports during bus initialization. The property is
> >> > > a bitmap, where a bit value of 1 indicates support for that method, and 0
> >> > > indicates lack of support.
> >> > > Bit 0: SETDASA CCC (Direct)
> >> > > Bit 1: SETAASA CCC (Broadcast)
> >> > > Bit 2: Other CCC (vendor / standards extension)
> >> > > All other bits are reserved.
> >> > > 
> >> > > It is specifically needed when an I3C device requires SETAASA for the
> >> > > address assignment. SETDASA will be supported by default if this property
> >> > > is absent - which means for now the property just serves as a flag to
> >> > > enable SETAASA, but keep the property as a bitmap to align with the
> >> > > specifications.
> >> > > 
> >> > > [1] https://www.mipi.org/specifications/disco
> >> > > 
> >> > > Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> >> > > ---
> >> > >  .../devicetree/bindings/i3c/i3c.yaml          | 30 ++++++++++++++++---
> >> > >  1 file changed, 26 insertions(+), 4 deletions(-)
> >> > > 
> >> > > diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
> >> > > index e25fa72fd785..1705d90d4d79 100644
> >> > > --- a/Documentation/devicetree/bindings/i3c/i3c.yaml
> >> > > +++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
> >> > > @@ -31,10 +31,12 @@ properties:
> >> > >        described in the device tree, which in turn means we have to describe
> >> > >        I3C devices.
> >> > >  
> >> > > -      Another use case for describing an I3C device in the device tree is when
> >> > > -      this I3C device has a static I2C address and we want to assign it a
> >> > > -      specific I3C dynamic address before the DAA takes place (so that other
> >> > > -      devices on the bus can't take this dynamic address).
> >> > > +      Other use-cases for describing an I3C device in the device tree are:
> >> > > +      - When the I3C device has a static I2C address and we want to assign
> >> > > +        it a specific I3C dynamic address before the DAA takes place (so
> >> > > +        that other devices on the bus can't take this dynamic address).
> >> > > +      - When the I3C device requires SETAASA for its discovery and uses a
> >> > > +        pre-defined static address.
> >> > >  
> >> > >    "#size-cells":
> >> > >      const: 0
> >> > > @@ -147,6 +149,26 @@ patternProperties:
> >> > >            through SETDASA. If static address is not present, this address is assigned
> >> > >            through SETNEWDA after assigning a temporary address via ENTDAA.
> >> > >  
> >> > > +      mipi-i3c-static-method:
> >> > > +        $ref: /schemas/types.yaml#/definitions/uint32
> >> > > +        minimum: 0x1
> >> > > +        maximum: 0xff
> >> > > +        default: 1
> >> > > +        description: |
> >> > > +          Bitmap describing which methods of Dynamic Address Assignment from a
> >> > > +          static address are supported by this I3C Target. A bit value of 1
> >> > > +          indicates support for that method, and 0 indicates lack of support.
> >> > 
> >> > I really am not keen on properties that are bitmaps, why can't we just
> >> > use the strings "setdasa", "setaasa" etc?
> >> 
> >> If this comes from a specification, then I'd tend to just copy it rather 
> >> than invent our own thing. Obviously if is something structured 
> >> fundamentally different from how DT is designed, then we wouldn't. But 
> >> this is just a simple property.
> >> 
> > 
> > The issue being that the specification is not public so it is difficult
> > to take any decision.
> 
> There is a public version available in the same link, but you would still
> have to provide them a name and an email ID. The document will be sent to
> the mail ID.
> 

The public version only contains one property:
mipi-disco-interface-revision


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA

[Akhil R]

On Fri, 27 Mar 2026 09:27:21 +0100, Alexandre Belloni wrote:
> On 27/03/2026 13:48:58+0530, Akhil R wrote:
>> On Thu, 26 Mar 2026 16:44:31 +0100, Alexandre Belloni wrote:
>> > On 26/03/2026 10:05:03-0500, Rob Herring wrote:
>> >> On Wed, Mar 18, 2026 at 05:31:50PM +0000, Conor Dooley wrote:
>> >> > On Wed, Mar 18, 2026 at 10:57:14PM +0530, Akhil R wrote:
>> >> > > Add the 'mipi-i3c-static-method' property mentioned in the MIPI I3C
>> >> > > Discovery and Configuration Specification [1] to specify which discovery
>> >> > > method an I3C device supports during bus initialization. The property is
>> >> > > a bitmap, where a bit value of 1 indicates support for that method, and 0
>> >> > > indicates lack of support.
>> >> > > Bit 0: SETDASA CCC (Direct)
>> >> > > Bit 1: SETAASA CCC (Broadcast)
>> >> > > Bit 2: Other CCC (vendor / standards extension)
>> >> > > All other bits are reserved.
>> >> > > 
>> >> > > It is specifically needed when an I3C device requires SETAASA for the
>> >> > > address assignment. SETDASA will be supported by default if this property
>> >> > > is absent - which means for now the property just serves as a flag to
>> >> > > enable SETAASA, but keep the property as a bitmap to align with the
>> >> > > specifications.
>> >> > > 
>> >> > > [1] https://www.mipi.org/specifications/disco
>> >> > > 
>> >> > > Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
>> >> > > ---
>> >> > >  .../devicetree/bindings/i3c/i3c.yaml          | 30 ++++++++++++++++---
>> >> > >  1 file changed, 26 insertions(+), 4 deletions(-)
>> >> > > 
>> >> > > diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
>> >> > > index e25fa72fd785..1705d90d4d79 100644
>> >> > > --- a/Documentation/devicetree/bindings/i3c/i3c.yaml
>> >> > > +++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
>> >> > > @@ -31,10 +31,12 @@ properties:
>> >> > >        described in the device tree, which in turn means we have to describe
>> >> > >        I3C devices.
>> >> > >  
>> >> > > -      Another use case for describing an I3C device in the device tree is when
>> >> > > -      this I3C device has a static I2C address and we want to assign it a
>> >> > > -      specific I3C dynamic address before the DAA takes place (so that other
>> >> > > -      devices on the bus can't take this dynamic address).
>> >> > > +      Other use-cases for describing an I3C device in the device tree are:
>> >> > > +      - When the I3C device has a static I2C address and we want to assign
>> >> > > +        it a specific I3C dynamic address before the DAA takes place (so
>> >> > > +        that other devices on the bus can't take this dynamic address).
>> >> > > +      - When the I3C device requires SETAASA for its discovery and uses a
>> >> > > +        pre-defined static address.
>> >> > >  
>> >> > >    "#size-cells":
>> >> > >      const: 0
>> >> > > @@ -147,6 +149,26 @@ patternProperties:
>> >> > >            through SETDASA. If static address is not present, this address is assigned
>> >> > >            through SETNEWDA after assigning a temporary address via ENTDAA.
>> >> > >  
>> >> > > +      mipi-i3c-static-method:
>> >> > > +        $ref: /schemas/types.yaml#/definitions/uint32
>> >> > > +        minimum: 0x1
>> >> > > +        maximum: 0xff
>> >> > > +        default: 1
>> >> > > +        description: |
>> >> > > +          Bitmap describing which methods of Dynamic Address Assignment from a
>> >> > > +          static address are supported by this I3C Target. A bit value of 1
>> >> > > +          indicates support for that method, and 0 indicates lack of support.
>> >> > 
>> >> > I really am not keen on properties that are bitmaps, why can't we just
>> >> > use the strings "setdasa", "setaasa" etc?
>> >> 
>> >> If this comes from a specification, then I'd tend to just copy it rather 
>> >> than invent our own thing. Obviously if is something structured 
>> >> fundamentally different from how DT is designed, then we wouldn't. But 
>> >> this is just a simple property.
>> >> 
>> > 
>> > The issue being that the specification is not public so it is difficult
>> > to take any decision.
>> 
>> There is a public version available in the same link, but you would still
>> have to provide them a name and an email ID. The document will be sent to
>> the mail ID.
>> 
> 
> The public version only contains one property:
> mipi-disco-interface-revision

Could you check once if the below link works?
https://www.mipi.org/mipi-disco-for-i3c-download

Best Regards,
Akhil

[PATCH 02/12] ACPICA: Read LVR from the I2C resource descriptor

[Akhil R]

ACPI 6.3 specifies byte 8 of I2C Serial Bus Connection descriptor to be
used for Legacy Virtual Register (LVR) data as specified in the MIPI
I3C Specification for an I2C device connected to an I3C Host Controller.
LVR will be read by I3C host controller drivers and it provides details
about the specific speed and 50ns spike filter capabilities of I2C
devices.

Update the rsconvert_info to include this field. For I2C devices on an
I2C bus, this field is Reserved and unused.

This commit is the result of squashing the following:
ACPICA commit 70082dc8fc847673ac7f4bbb1541776730f0b63e
ACPICA commit e62e74baf7e08cf059ec82049aeccd565b24d661
ACPICA commit c404118235108012cad396c834b5aabe2dd1b51a
ACPICA commit 7650d4a889ea7907060bfce89f4f780ce83e7b28
ACPICA commit 014fa9f2dbcc6b1bd42a4a4a6f6705d9cf7d460b

Link: https://github.com/acpica/acpica/commit/70082dc8
Link: https://github.com/acpica/acpica/commit/b3c38dc9
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
 drivers/acpi/acpica/rsserial.c | 6 +++++-
 include/acpi/acrestyp.h        | 1 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/acpica/rsserial.c b/drivers/acpi/acpica/rsserial.c
index 279bfa27da94..c06e918ab889 100644
--- a/drivers/acpi/acpica/rsserial.c
+++ b/drivers/acpi/acpica/rsserial.c
@@ -315,7 +315,7 @@ struct acpi_rsconvert_info acpi_rs_convert_csi2_serial_bus[14] = {
  *
  ******************************************************************************/
 
-struct acpi_rsconvert_info acpi_rs_convert_i2c_serial_bus[17] = {
+struct acpi_rsconvert_info acpi_rs_convert_i2c_serial_bus[18] = {
 	{ACPI_RSC_INITGET, ACPI_RESOURCE_TYPE_SERIAL_BUS,
 	 ACPI_RS_SIZE(struct acpi_resource_i2c_serialbus),
 	 ACPI_RSC_TABLE_SIZE(acpi_rs_convert_i2c_serial_bus)},
@@ -391,6 +391,10 @@ struct acpi_rsconvert_info acpi_rs_convert_i2c_serial_bus[17] = {
 	 AML_OFFSET(i2c_serial_bus.type_specific_flags),
 	 0},
 
+	{ACPI_RSC_MOVE8, ACPI_RS_OFFSET(data.i2c_serial_bus.lvr),
+	 AML_OFFSET(i2c_serial_bus.type_specific_flags) + 1,
+	 1},
+
 	{ACPI_RSC_MOVE32, ACPI_RS_OFFSET(data.i2c_serial_bus.connection_speed),
 	 AML_OFFSET(i2c_serial_bus.connection_speed),
 	 1},
diff --git a/include/acpi/acrestyp.h b/include/acpi/acrestyp.h
index 842f932e2c2b..38a19b1d19ac 100644
--- a/include/acpi/acrestyp.h
+++ b/include/acpi/acrestyp.h
@@ -423,6 +423,7 @@ struct acpi_resource_i2c_serialbus {
 	ACPI_RESOURCE_SERIAL_COMMON u8 access_mode;
 	u16 slave_address;
 	u32 connection_speed;
+	u8 lvr;
 };
 
 /* Values for access_mode field above */
-- 
2.50.1

[PATCH 03/12] i3c: master: Use unified device property interface

[Akhil R]

Replace all OF-specific functions with unified device property functions
as a prerequisite to support both ACPI and device tree.

Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
 drivers/i3c/master.c       | 91 ++++++++++++++++++++++----------------
 include/linux/i3c/master.h |  5 ++-
 2 files changed, 55 insertions(+), 41 deletions(-)

diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index c32847bc4d0d..2c479fecbfdf 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -5,16 +5,19 @@
  * Author: Boris Brezillon <boris.brezillon@bootlin.com>
  */
 
+#include <linux/acpi.h>
 #include <linux/atomic.h>
 #include <linux/bug.h>
 #include <linux/device.h>
 #include <linux/dma-mapping.h>
 #include <linux/err.h>
 #include <linux/export.h>
+#include <linux/i2c.h>
 #include <linux/kernel.h>
 #include <linux/list.h>
 #include <linux/of.h>
 #include <linux/pm_runtime.h>
+#include <linux/property.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
 #include <linux/workqueue.h>
@@ -497,7 +500,7 @@ static void i3c_bus_cleanup(struct i3c_bus *i3cbus)
 	mutex_unlock(&i3c_core_lock);
 }
 
-static int i3c_bus_init(struct i3c_bus *i3cbus, struct device_node *np)
+static int i3c_bus_init(struct i3c_bus *i3cbus, struct fwnode_handle *fwnode)
 {
 	int ret, start, end, id = -1;
 
@@ -507,8 +510,8 @@ static int i3c_bus_init(struct i3c_bus *i3cbus, struct device_node *np)
 	i3c_bus_init_addrslots(i3cbus);
 	i3cbus->mode = I3C_BUS_MODE_PURE;
 
-	if (np)
-		id = of_alias_get_id(np, "i3c");
+	if (fwnode && is_of_node(fwnode))
+		id = of_alias_get_id(to_of_node(fwnode), "i3c");
 
 	mutex_lock(&i3c_core_lock);
 	if (id >= 0) {
@@ -811,7 +814,7 @@ static void i3c_masterdev_release(struct device *dev)
 	WARN_ON(!list_empty(&bus->devs.i2c) || !list_empty(&bus->devs.i3c));
 	i3c_bus_cleanup(bus);
 
-	of_node_put(dev->of_node);
+	fwnode_handle_put(dev->fwnode);
 }
 
 static const struct device_type i3c_masterdev_type = {
@@ -995,7 +998,7 @@ static void i3c_device_release(struct device *dev)
 
 	WARN_ON(i3cdev->desc);
 
-	of_node_put(i3cdev->dev.of_node);
+	fwnode_handle_put(dev->fwnode);
 	kfree(i3cdev);
 }
 
@@ -1783,7 +1786,7 @@ i3c_master_register_new_i3c_devs(struct i3c_master_controller *master)
 			     desc->info.pid);
 
 		if (desc->boardinfo)
-			desc->dev->dev.of_node = desc->boardinfo->of_node;
+			device_set_node(&desc->dev->dev, desc->boardinfo->fwnode);
 
 		ret = device_register(&desc->dev->dev);
 		if (ret) {
@@ -2402,8 +2405,8 @@ EXPORT_SYMBOL_GPL(i3c_master_add_i3c_dev_locked);
 #define OF_I3C_REG1_IS_I2C_DEV			BIT(31)
 
 static int
-of_i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
-				struct device_node *node, u32 *reg)
+i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
+			     struct fwnode_handle *fwnode, u32 *reg)
 {
 	struct i2c_dev_boardinfo *boardinfo;
 	struct device *dev = &master->dev;
@@ -2413,9 +2416,13 @@ of_i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
 	if (!boardinfo)
 		return -ENOMEM;
 
-	ret = of_i2c_get_board_info(dev, node, &boardinfo->base);
-	if (ret)
-		return ret;
+	if (is_of_node(fwnode)) {
+		ret = of_i2c_get_board_info(dev, to_of_node(fwnode), &boardinfo->base);
+		if (ret)
+			return ret;
+	} else {
+		return -EINVAL;
+	}
 
 	/*
 	 * The I3C Specification does not clearly say I2C devices with 10-bit
@@ -2431,14 +2438,14 @@ of_i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
 	boardinfo->lvr = reg[2];
 
 	list_add_tail(&boardinfo->node, &master->boardinfo.i2c);
-	of_node_get(node);
+	fwnode_handle_get(fwnode);
 
 	return 0;
 }
 
 static int
-of_i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
-				struct device_node *node, u32 *reg)
+i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
+			     struct fwnode_handle *fwnode, u32 *reg)
 {
 	struct i3c_dev_boardinfo *boardinfo;
 	struct device *dev = &master->dev;
@@ -2461,7 +2468,7 @@ of_i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
 
 	boardinfo->static_addr = reg[0];
 
-	if (!of_property_read_u32(node, "assigned-address", &init_dyn_addr)) {
+	if (!fwnode_property_read_u32(fwnode, "assigned-address", &init_dyn_addr)) {
 		if (init_dyn_addr > I3C_MAX_ADDR)
 			return -EINVAL;
 
@@ -2478,14 +2485,14 @@ of_i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
 		return -EINVAL;
 
 	boardinfo->init_dyn_addr = init_dyn_addr;
-	boardinfo->of_node = of_node_get(node);
+	boardinfo->fwnode = fwnode_handle_get(fwnode);
 	list_add_tail(&boardinfo->node, &master->boardinfo.i3c);
 
 	return 0;
 }
 
-static int of_i3c_master_add_dev(struct i3c_master_controller *master,
-				 struct device_node *node)
+static int i3c_master_add_dev(struct i3c_master_controller *master,
+			      struct fwnode_handle *fwnode)
 {
 	u32 reg[3];
 	int ret;
@@ -2493,7 +2500,7 @@ static int of_i3c_master_add_dev(struct i3c_master_controller *master,
 	if (!master)
 		return -EINVAL;
 
-	ret = of_property_read_u32_array(node, "reg", reg, ARRAY_SIZE(reg));
+	ret = fwnode_property_read_u32_array(fwnode, "reg", reg, ARRAY_SIZE(reg));
 	if (ret)
 		return ret;
 
@@ -2502,25 +2509,25 @@ static int of_i3c_master_add_dev(struct i3c_master_controller *master,
 	 * dealing with an I2C device.
 	 */
 	if (!reg[1])
-		ret = of_i3c_master_add_i2c_boardinfo(master, node, reg);
+		ret = i3c_master_add_i2c_boardinfo(master, fwnode, reg);
 	else
-		ret = of_i3c_master_add_i3c_boardinfo(master, node, reg);
+		ret = i3c_master_add_i3c_boardinfo(master, fwnode, reg);
 
 	return ret;
 }
 
-static int of_populate_i3c_bus(struct i3c_master_controller *master)
+static int fwnode_populate_i3c_bus(struct i3c_master_controller *master)
 {
 	struct device *dev = &master->dev;
-	struct device_node *i3cbus_np = dev->of_node;
+	struct fwnode_handle *fwnode = dev_fwnode(dev);
 	int ret;
 	u32 val;
 
-	if (!i3cbus_np)
+	if (!fwnode)
 		return 0;
 
-	for_each_available_child_of_node_scoped(i3cbus_np, node) {
-		ret = of_i3c_master_add_dev(master, node);
+	fwnode_for_each_available_child_node_scoped(fwnode, child) {
+		ret = i3c_master_add_dev(master, child);
 		if (ret)
 			return ret;
 	}
@@ -2530,10 +2537,10 @@ static int of_populate_i3c_bus(struct i3c_master_controller *master)
 	 * on the bus are not supporting typical rates, or if the bus topology
 	 * prevents it from using max possible rate.
 	 */
-	if (!of_property_read_u32(i3cbus_np, "i2c-scl-hz", &val))
+	if (!device_property_read_u32(dev, "i2c-scl-hz", &val))
 		master->bus.scl_rate.i2c = val;
 
-	if (!of_property_read_u32(i3cbus_np, "i3c-scl-hz", &val))
+	if (!device_property_read_u32(dev, "i3c-scl-hz", &val))
 		master->bus.scl_rate.i3c = val;
 
 	return 0;
@@ -2588,7 +2595,7 @@ static u8 i3c_master_i2c_get_lvr(struct i2c_client *client)
 	u8 lvr = I3C_LVR_I2C_INDEX(2) | I3C_LVR_I2C_FM_MODE;
 	u32 reg[3];
 
-	if (!of_property_read_u32_array(client->dev.of_node, "reg", reg, ARRAY_SIZE(reg)))
+	if (!fwnode_property_read_u32_array(client->dev.fwnode, "reg", reg, ARRAY_SIZE(reg)))
 		lvr = reg[2];
 
 	return lvr;
@@ -2707,7 +2714,8 @@ static int i3c_master_i2c_adapter_init(struct i3c_master_controller *master)
 	struct i2c_adapter *adap = i3c_master_to_i2c_adapter(master);
 	struct i2c_dev_desc *i2cdev;
 	struct i2c_dev_boardinfo *i2cboardinfo;
-	int ret, id;
+	struct fwnode_handle *fwnode = dev_fwnode(&master->dev);
+	int ret, id = -1;
 
 	adap->dev.parent = master->dev.parent;
 	adap->owner = master->dev.parent->driver->owner;
@@ -2716,7 +2724,9 @@ static int i3c_master_i2c_adapter_init(struct i3c_master_controller *master)
 	adap->timeout = HZ;
 	adap->retries = 3;
 
-	id = of_alias_get_id(master->dev.of_node, "i2c");
+	if (fwnode && is_of_node(fwnode))
+		id = of_alias_get_id(to_of_node(fwnode), "i2c");
+
 	if (id >= 0) {
 		adap->nr = id;
 		ret = i2c_add_numbered_adapter(adap);
@@ -3017,7 +3027,7 @@ int i3c_master_register(struct i3c_master_controller *master,
 		return ret;
 
 	master->dev.parent = parent;
-	master->dev.of_node = of_node_get(parent->of_node);
+	device_set_node(&master->dev, fwnode_handle_get(dev_fwnode(parent)));
 	master->dev.bus = &i3c_bus_type;
 	master->dev.type = &i3c_masterdev_type;
 	master->dev.release = i3c_masterdev_release;
@@ -3036,13 +3046,13 @@ int i3c_master_register(struct i3c_master_controller *master,
 	master->dev.coherent_dma_mask = parent->coherent_dma_mask;
 	master->dev.dma_parms = parent->dma_parms;
 
-	ret = i3c_bus_init(i3cbus, master->dev.of_node);
+	ret = i3c_bus_init(i3cbus, dev_fwnode(&master->dev));
 	if (ret)
 		goto err_put_dev;
 
 	dev_set_name(&master->dev, "i3c-%d", i3cbus->id);
 
-	ret = of_populate_i3c_bus(master);
+	ret = fwnode_populate_i3c_bus(master);
 	if (ret)
 		goto err_put_dev;
 
@@ -3300,11 +3310,14 @@ static int __init i3c_init(void)
 {
 	int res;
 
-	res = of_alias_get_highest_id("i3c");
-	if (res >= 0) {
-		mutex_lock(&i3c_core_lock);
-		__i3c_first_dynamic_bus_num = res + 1;
-		mutex_unlock(&i3c_core_lock);
+	/* of_alias_get_highest_id is DT-specific, only call for DT systems */
+	if (IS_ENABLED(CONFIG_OF)) {
+		res = of_alias_get_highest_id("i3c");
+		if (res >= 0) {
+			mutex_lock(&i3c_core_lock);
+			__i3c_first_dynamic_bus_num = res + 1;
+			mutex_unlock(&i3c_core_lock);
+		}
 	}
 
 	res = bus_register_notifier(&i2c_bus_type, &i2cdev_notifier);
diff --git a/include/linux/i3c/master.h b/include/linux/i3c/master.h
index 592b646f6134..6b03a3ce574c 100644
--- a/include/linux/i3c/master.h
+++ b/include/linux/i3c/master.h
@@ -177,7 +177,8 @@ struct i3c_device_ibi_info {
  * @pid: I3C Provisioned ID exposed by the device. This is a unique identifier
  *	 that may be used to attach boardinfo to i3c_dev_desc when the device
  *	 does not have a static address
- * @of_node: optional DT node in case the device has been described in the DT
+ * @fwnode: Firmware node (DT or ACPI) in case the device has been
+ *	    described in firmware
  *
  * This structure is used to attach board-level information to an I3C device.
  * Not all I3C devices connected on the bus will have a boardinfo. It's only
@@ -189,7 +190,7 @@ struct i3c_dev_boardinfo {
 	u8 init_dyn_addr;
 	u8 static_addr;
 	u64 pid;
-	struct device_node *of_node;
+	struct fwnode_handle *fwnode;
 };
 
 /**
-- 
2.50.1

Re: [PATCH 03/12] i3c: master: Use unified device property interface

[Frank Li]

On Wed, Mar 18, 2026 at 10:57:16PM +0530, Akhil R wrote:
> Replace all OF-specific functions with unified device property functions
> as a prerequisite to support both ACPI and device tree.
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>

Reviewed-by: Frank Li <Frank.Li@nxp.com>

> ---
>  drivers/i3c/master.c       | 91 ++++++++++++++++++++++----------------
>  include/linux/i3c/master.h |  5 ++-
>  2 files changed, 55 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index c32847bc4d0d..2c479fecbfdf 100644
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c
> @@ -5,16 +5,19 @@
>   * Author: Boris Brezillon <boris.brezillon@bootlin.com>
>   */
>
> +#include <linux/acpi.h>
>  #include <linux/atomic.h>
>  #include <linux/bug.h>
>  #include <linux/device.h>
>  #include <linux/dma-mapping.h>
>  #include <linux/err.h>
>  #include <linux/export.h>
> +#include <linux/i2c.h>
>  #include <linux/kernel.h>
>  #include <linux/list.h>
>  #include <linux/of.h>
>  #include <linux/pm_runtime.h>
> +#include <linux/property.h>
>  #include <linux/slab.h>
>  #include <linux/spinlock.h>
>  #include <linux/workqueue.h>
> @@ -497,7 +500,7 @@ static void i3c_bus_cleanup(struct i3c_bus *i3cbus)
>  	mutex_unlock(&i3c_core_lock);
>  }
>
> -static int i3c_bus_init(struct i3c_bus *i3cbus, struct device_node *np)
> +static int i3c_bus_init(struct i3c_bus *i3cbus, struct fwnode_handle *fwnode)
>  {
>  	int ret, start, end, id = -1;
>
> @@ -507,8 +510,8 @@ static int i3c_bus_init(struct i3c_bus *i3cbus, struct device_node *np)
>  	i3c_bus_init_addrslots(i3cbus);
>  	i3cbus->mode = I3C_BUS_MODE_PURE;
>
> -	if (np)
> -		id = of_alias_get_id(np, "i3c");
> +	if (fwnode && is_of_node(fwnode))
> +		id = of_alias_get_id(to_of_node(fwnode), "i3c");
>
>  	mutex_lock(&i3c_core_lock);
>  	if (id >= 0) {
> @@ -811,7 +814,7 @@ static void i3c_masterdev_release(struct device *dev)
>  	WARN_ON(!list_empty(&bus->devs.i2c) || !list_empty(&bus->devs.i3c));
>  	i3c_bus_cleanup(bus);
>
> -	of_node_put(dev->of_node);
> +	fwnode_handle_put(dev->fwnode);
>  }
>
>  static const struct device_type i3c_masterdev_type = {
> @@ -995,7 +998,7 @@ static void i3c_device_release(struct device *dev)
>
>  	WARN_ON(i3cdev->desc);
>
> -	of_node_put(i3cdev->dev.of_node);
> +	fwnode_handle_put(dev->fwnode);
>  	kfree(i3cdev);
>  }
>
> @@ -1783,7 +1786,7 @@ i3c_master_register_new_i3c_devs(struct i3c_master_controller *master)
>  			     desc->info.pid);
>
>  		if (desc->boardinfo)
> -			desc->dev->dev.of_node = desc->boardinfo->of_node;
> +			device_set_node(&desc->dev->dev, desc->boardinfo->fwnode);
>
>  		ret = device_register(&desc->dev->dev);
>  		if (ret) {
> @@ -2402,8 +2405,8 @@ EXPORT_SYMBOL_GPL(i3c_master_add_i3c_dev_locked);
>  #define OF_I3C_REG1_IS_I2C_DEV			BIT(31)
>
>  static int
> -of_i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
> -				struct device_node *node, u32 *reg)
> +i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
> +			     struct fwnode_handle *fwnode, u32 *reg)
>  {
>  	struct i2c_dev_boardinfo *boardinfo;
>  	struct device *dev = &master->dev;
> @@ -2413,9 +2416,13 @@ of_i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
>  	if (!boardinfo)
>  		return -ENOMEM;
>
> -	ret = of_i2c_get_board_info(dev, node, &boardinfo->base);
> -	if (ret)
> -		return ret;
> +	if (is_of_node(fwnode)) {
> +		ret = of_i2c_get_board_info(dev, to_of_node(fwnode), &boardinfo->base);
> +		if (ret)
> +			return ret;
> +	} else {
> +		return -EINVAL;
> +	}
>
>  	/*
>  	 * The I3C Specification does not clearly say I2C devices with 10-bit
> @@ -2431,14 +2438,14 @@ of_i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
>  	boardinfo->lvr = reg[2];
>
>  	list_add_tail(&boardinfo->node, &master->boardinfo.i2c);
> -	of_node_get(node);
> +	fwnode_handle_get(fwnode);
>
>  	return 0;
>  }
>
>  static int
> -of_i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
> -				struct device_node *node, u32 *reg)
> +i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
> +			     struct fwnode_handle *fwnode, u32 *reg)
>  {
>  	struct i3c_dev_boardinfo *boardinfo;
>  	struct device *dev = &master->dev;
> @@ -2461,7 +2468,7 @@ of_i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
>
>  	boardinfo->static_addr = reg[0];
>
> -	if (!of_property_read_u32(node, "assigned-address", &init_dyn_addr)) {
> +	if (!fwnode_property_read_u32(fwnode, "assigned-address", &init_dyn_addr)) {
>  		if (init_dyn_addr > I3C_MAX_ADDR)
>  			return -EINVAL;
>
> @@ -2478,14 +2485,14 @@ of_i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
>  		return -EINVAL;
>
>  	boardinfo->init_dyn_addr = init_dyn_addr;
> -	boardinfo->of_node = of_node_get(node);
> +	boardinfo->fwnode = fwnode_handle_get(fwnode);
>  	list_add_tail(&boardinfo->node, &master->boardinfo.i3c);
>
>  	return 0;
>  }
>
> -static int of_i3c_master_add_dev(struct i3c_master_controller *master,
> -				 struct device_node *node)
> +static int i3c_master_add_dev(struct i3c_master_controller *master,
> +			      struct fwnode_handle *fwnode)
>  {
>  	u32 reg[3];
>  	int ret;
> @@ -2493,7 +2500,7 @@ static int of_i3c_master_add_dev(struct i3c_master_controller *master,
>  	if (!master)
>  		return -EINVAL;
>
> -	ret = of_property_read_u32_array(node, "reg", reg, ARRAY_SIZE(reg));
> +	ret = fwnode_property_read_u32_array(fwnode, "reg", reg, ARRAY_SIZE(reg));
>  	if (ret)
>  		return ret;
>
> @@ -2502,25 +2509,25 @@ static int of_i3c_master_add_dev(struct i3c_master_controller *master,
>  	 * dealing with an I2C device.
>  	 */
>  	if (!reg[1])
> -		ret = of_i3c_master_add_i2c_boardinfo(master, node, reg);
> +		ret = i3c_master_add_i2c_boardinfo(master, fwnode, reg);
>  	else
> -		ret = of_i3c_master_add_i3c_boardinfo(master, node, reg);
> +		ret = i3c_master_add_i3c_boardinfo(master, fwnode, reg);
>
>  	return ret;
>  }
>
> -static int of_populate_i3c_bus(struct i3c_master_controller *master)
> +static int fwnode_populate_i3c_bus(struct i3c_master_controller *master)
>  {
>  	struct device *dev = &master->dev;
> -	struct device_node *i3cbus_np = dev->of_node;
> +	struct fwnode_handle *fwnode = dev_fwnode(dev);
>  	int ret;
>  	u32 val;
>
> -	if (!i3cbus_np)
> +	if (!fwnode)
>  		return 0;
>
> -	for_each_available_child_of_node_scoped(i3cbus_np, node) {
> -		ret = of_i3c_master_add_dev(master, node);
> +	fwnode_for_each_available_child_node_scoped(fwnode, child) {
> +		ret = i3c_master_add_dev(master, child);
>  		if (ret)
>  			return ret;
>  	}
> @@ -2530,10 +2537,10 @@ static int of_populate_i3c_bus(struct i3c_master_controller *master)
>  	 * on the bus are not supporting typical rates, or if the bus topology
>  	 * prevents it from using max possible rate.
>  	 */
> -	if (!of_property_read_u32(i3cbus_np, "i2c-scl-hz", &val))
> +	if (!device_property_read_u32(dev, "i2c-scl-hz", &val))
>  		master->bus.scl_rate.i2c = val;
>
> -	if (!of_property_read_u32(i3cbus_np, "i3c-scl-hz", &val))
> +	if (!device_property_read_u32(dev, "i3c-scl-hz", &val))
>  		master->bus.scl_rate.i3c = val;
>
>  	return 0;
> @@ -2588,7 +2595,7 @@ static u8 i3c_master_i2c_get_lvr(struct i2c_client *client)
>  	u8 lvr = I3C_LVR_I2C_INDEX(2) | I3C_LVR_I2C_FM_MODE;
>  	u32 reg[3];
>
> -	if (!of_property_read_u32_array(client->dev.of_node, "reg", reg, ARRAY_SIZE(reg)))
> +	if (!fwnode_property_read_u32_array(client->dev.fwnode, "reg", reg, ARRAY_SIZE(reg)))
>  		lvr = reg[2];
>
>  	return lvr;
> @@ -2707,7 +2714,8 @@ static int i3c_master_i2c_adapter_init(struct i3c_master_controller *master)
>  	struct i2c_adapter *adap = i3c_master_to_i2c_adapter(master);
>  	struct i2c_dev_desc *i2cdev;
>  	struct i2c_dev_boardinfo *i2cboardinfo;
> -	int ret, id;
> +	struct fwnode_handle *fwnode = dev_fwnode(&master->dev);
> +	int ret, id = -1;
>
>  	adap->dev.parent = master->dev.parent;
>  	adap->owner = master->dev.parent->driver->owner;
> @@ -2716,7 +2724,9 @@ static int i3c_master_i2c_adapter_init(struct i3c_master_controller *master)
>  	adap->timeout = HZ;
>  	adap->retries = 3;
>
> -	id = of_alias_get_id(master->dev.of_node, "i2c");
> +	if (fwnode && is_of_node(fwnode))
> +		id = of_alias_get_id(to_of_node(fwnode), "i2c");
> +
>  	if (id >= 0) {
>  		adap->nr = id;
>  		ret = i2c_add_numbered_adapter(adap);
> @@ -3017,7 +3027,7 @@ int i3c_master_register(struct i3c_master_controller *master,
>  		return ret;
>
>  	master->dev.parent = parent;
> -	master->dev.of_node = of_node_get(parent->of_node);
> +	device_set_node(&master->dev, fwnode_handle_get(dev_fwnode(parent)));
>  	master->dev.bus = &i3c_bus_type;
>  	master->dev.type = &i3c_masterdev_type;
>  	master->dev.release = i3c_masterdev_release;
> @@ -3036,13 +3046,13 @@ int i3c_master_register(struct i3c_master_controller *master,
>  	master->dev.coherent_dma_mask = parent->coherent_dma_mask;
>  	master->dev.dma_parms = parent->dma_parms;
>
> -	ret = i3c_bus_init(i3cbus, master->dev.of_node);
> +	ret = i3c_bus_init(i3cbus, dev_fwnode(&master->dev));
>  	if (ret)
>  		goto err_put_dev;
>
>  	dev_set_name(&master->dev, "i3c-%d", i3cbus->id);
>
> -	ret = of_populate_i3c_bus(master);
> +	ret = fwnode_populate_i3c_bus(master);
>  	if (ret)
>  		goto err_put_dev;
>
> @@ -3300,11 +3310,14 @@ static int __init i3c_init(void)
>  {
>  	int res;
>
> -	res = of_alias_get_highest_id("i3c");
> -	if (res >= 0) {
> -		mutex_lock(&i3c_core_lock);
> -		__i3c_first_dynamic_bus_num = res + 1;
> -		mutex_unlock(&i3c_core_lock);
> +	/* of_alias_get_highest_id is DT-specific, only call for DT systems */
> +	if (IS_ENABLED(CONFIG_OF)) {
> +		res = of_alias_get_highest_id("i3c");
> +		if (res >= 0) {
> +			mutex_lock(&i3c_core_lock);
> +			__i3c_first_dynamic_bus_num = res + 1;
> +			mutex_unlock(&i3c_core_lock);
> +		}
>  	}
>
>  	res = bus_register_notifier(&i2c_bus_type, &i2cdev_notifier);
> diff --git a/include/linux/i3c/master.h b/include/linux/i3c/master.h
> index 592b646f6134..6b03a3ce574c 100644
> --- a/include/linux/i3c/master.h
> +++ b/include/linux/i3c/master.h
> @@ -177,7 +177,8 @@ struct i3c_device_ibi_info {
>   * @pid: I3C Provisioned ID exposed by the device. This is a unique identifier
>   *	 that may be used to attach boardinfo to i3c_dev_desc when the device
>   *	 does not have a static address
> - * @of_node: optional DT node in case the device has been described in the DT
> + * @fwnode: Firmware node (DT or ACPI) in case the device has been
> + *	    described in firmware
>   *
>   * This structure is used to attach board-level information to an I3C device.
>   * Not all I3C devices connected on the bus will have a boardinfo. It's only
> @@ -189,7 +190,7 @@ struct i3c_dev_boardinfo {
>  	u8 init_dyn_addr;
>  	u8 static_addr;
>  	u64 pid;
> -	struct device_node *of_node;
> +	struct fwnode_handle *fwnode;
>  };
>
>  /**
> --
> 2.50.1
>

Re: [PATCH 03/12] i3c: master: Use unified device property interface

[Rob Herring]

On Wed, Mar 18, 2026 at 10:57:16PM +0530, Akhil R wrote:
> Replace all OF-specific functions with unified device property functions
> as a prerequisite to support both ACPI and device tree.
> 
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> ---
>  drivers/i3c/master.c       | 91 ++++++++++++++++++++++----------------
>  include/linux/i3c/master.h |  5 ++-
>  2 files changed, 55 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index c32847bc4d0d..2c479fecbfdf 100644
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c

[...]

> @@ -3300,11 +3310,14 @@ static int __init i3c_init(void)
>  {
>  	int res;
>  
> -	res = of_alias_get_highest_id("i3c");
> -	if (res >= 0) {
> -		mutex_lock(&i3c_core_lock);
> -		__i3c_first_dynamic_bus_num = res + 1;
> -		mutex_unlock(&i3c_core_lock);
> +	/* of_alias_get_highest_id is DT-specific, only call for DT systems */
> +	if (IS_ENABLED(CONFIG_OF)) {

BTW, CONFIG_OF is *always* enabled on arm64.

> +		res = of_alias_get_highest_id("i3c");

This will just return an error if not booting with DT or if CONFIG_OF is 
disabled.

> +		if (res >= 0) {
> +			mutex_lock(&i3c_core_lock);
> +			__i3c_first_dynamic_bus_num = res + 1;
> +			mutex_unlock(&i3c_core_lock);
> +		}
>  	}
>  
>  	res = bus_register_notifier(&i2c_bus_type, &i2cdev_notifier);

[PATCH 04/12] i3c: master: Support ACPI enumeration

[Akhil R]

Support ACPI enumeration for I2C and I3C devices on an I3C bus.
Read _ADR and LVR from the ACPI resources and extract the data
as per the ACPI specification for an I3C bus. Also read
mipi-i3c-static-address as per the MIPI DISCO specifications [1]
to get the static address to be used.

Although the existing subsystem allows host controllers to register
through the ACPI table, it was not possible to describe I3C or I2C
devices there. This change enables describing the I3C or I2C devices
in the ACPI table, which is required if the device is using a static
address or if it needs some specific properties to be attached to it.

[1] https://www.mipi.org/specifications/disco

Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
 drivers/i3c/master.c | 101 +++++++++++++++++++++++++++++++++++++++----
 1 file changed, 93 insertions(+), 8 deletions(-)

diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index 2c479fecbfdf..15a356a2b3c8 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -2404,12 +2404,31 @@ EXPORT_SYMBOL_GPL(i3c_master_add_i3c_dev_locked);
 
 #define OF_I3C_REG1_IS_I2C_DEV			BIT(31)
 
+static int i3c_acpi_get_i2c_resource(struct acpi_resource *ares, void *data)
+{
+	struct i2c_dev_boardinfo *boardinfo = data;
+	struct acpi_resource_i2c_serialbus *sb;
+
+	if (!i2c_acpi_get_i2c_resource(ares, &sb))
+		return 1;
+
+	boardinfo->base.addr = sb->slave_address;
+	if (sb->access_mode == ACPI_I2C_10BIT_MODE)
+		boardinfo->base.flags |= I2C_CLIENT_TEN;
+
+	boardinfo->lvr = sb->lvr;
+
+	return 0;
+}
+
 static int
 i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
 			     struct fwnode_handle *fwnode, u32 *reg)
 {
 	struct i2c_dev_boardinfo *boardinfo;
 	struct device *dev = &master->dev;
+	struct acpi_device *adev;
+	LIST_HEAD(resources);
 	int ret;
 
 	boardinfo = devm_kzalloc(dev, sizeof(*boardinfo), GFP_KERNEL);
@@ -2420,6 +2439,23 @@ i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
 		ret = of_i2c_get_board_info(dev, to_of_node(fwnode), &boardinfo->base);
 		if (ret)
 			return ret;
+
+		/* LVR is encoded in reg[2] for Device Tree. */
+		boardinfo->lvr = reg[2];
+	} else if (is_acpi_device_node(fwnode)) {
+		adev = to_acpi_device_node(fwnode);
+		boardinfo->base.fwnode = acpi_fwnode_handle(adev);
+
+		ret = acpi_dev_get_resources(adev, &resources,
+					     i3c_acpi_get_i2c_resource, boardinfo);
+
+		if (ret < 0)
+			return ret;
+
+		acpi_dev_free_resource_list(&resources);
+
+		if (!boardinfo->base.addr)
+			return -ENODEV;
 	} else {
 		return -EINVAL;
 	}
@@ -2434,9 +2470,6 @@ i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
 		return -EOPNOTSUPP;
 	}
 
-	/* LVR is encoded in reg[2]. */
-	boardinfo->lvr = reg[2];
-
 	list_add_tail(&boardinfo->node, &master->boardinfo.i2c);
 	fwnode_handle_get(fwnode);
 
@@ -2491,8 +2524,8 @@ i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
 	return 0;
 }
 
-static int i3c_master_add_dev(struct i3c_master_controller *master,
-			      struct fwnode_handle *fwnode)
+static int i3c_master_add_of_dev(struct i3c_master_controller *master,
+				 struct fwnode_handle *fwnode)
 {
 	u32 reg[3];
 	int ret;
@@ -2516,6 +2549,31 @@ static int i3c_master_add_dev(struct i3c_master_controller *master,
 	return ret;
 }
 
+static int i3c_master_add_acpi_dev(struct i3c_master_controller *master,
+				   struct fwnode_handle *fwnode)
+{
+	struct acpi_device *adev = to_acpi_device_node(fwnode);
+	acpi_bus_address adr;
+	u32 reg[3] = { 0 };
+
+	/*
+	 * If the ACPI table entry does not have _ADR method, it's an I2C device
+	 * If the ACPI table entry has _ADR method, it's an I3C device
+	 */
+	if (!acpi_has_method(adev->handle, "_ADR"))
+		return i3c_master_add_i2c_boardinfo(master, fwnode, reg);
+
+	adr = acpi_device_adr(adev);
+
+	/* For I3C devices, _ADR will have the 48 bit PID of the device  */
+	reg[1] = upper_32_bits(adr);
+	reg[2] = lower_32_bits(adr);
+
+	fwnode_property_read_u32(fwnode, "mipi-i3c-static-address", &reg[0]);
+
+	return i3c_master_add_i3c_boardinfo(master, fwnode, reg);
+}
+
 static int fwnode_populate_i3c_bus(struct i3c_master_controller *master)
 {
 	struct device *dev = &master->dev;
@@ -2527,7 +2585,13 @@ static int fwnode_populate_i3c_bus(struct i3c_master_controller *master)
 		return 0;
 
 	fwnode_for_each_available_child_node_scoped(fwnode, child) {
-		ret = i3c_master_add_dev(master, child);
+		if (is_of_node(child))
+			ret = i3c_master_add_of_dev(master, child);
+		else if (is_acpi_device_node(child))
+			ret = i3c_master_add_acpi_dev(master, child);
+		else
+			continue;
+
 		if (ret)
 			return ret;
 	}
@@ -2593,10 +2657,31 @@ static u8 i3c_master_i2c_get_lvr(struct i2c_client *client)
 {
 	/* Fall back to no spike filters and FM bus mode. */
 	u8 lvr = I3C_LVR_I2C_INDEX(2) | I3C_LVR_I2C_FM_MODE;
+	struct i2c_dev_boardinfo boardinfo;
+	struct acpi_device *adev;
+	LIST_HEAD(resources);
 	u32 reg[3];
+	int ret;
+
+	if (is_of_node(client->dev.fwnode)) {
+		if (!fwnode_property_read_u32_array(client->dev.fwnode, "reg",
+						    reg, ARRAY_SIZE(reg)))
+			lvr = reg[2];
+	} else if (is_acpi_device_node(client->dev.fwnode)) {
+		adev = to_acpi_device_node(client->dev.fwnode);
+		memset(&boardinfo, 0, sizeof(boardinfo));
+
+		ret = acpi_dev_get_resources(adev, &resources,
+					     i3c_acpi_get_i2c_resource, &boardinfo);
 
-	if (!fwnode_property_read_u32_array(client->dev.fwnode, "reg", reg, ARRAY_SIZE(reg)))
-		lvr = reg[2];
+		if (ret < 0)
+			return lvr;
+
+		if (boardinfo.base.addr)
+			lvr = boardinfo.lvr;
+
+		acpi_dev_free_resource_list(&resources);
+	}
 
 	return lvr;
 }
-- 
2.50.1

Re: [PATCH 04/12] i3c: master: Support ACPI enumeration

[Frank Li]

On Wed, Mar 18, 2026 at 10:57:17PM +0530, Akhil R wrote:
> Support ACPI enumeration for I2C and I3C devices on an I3C bus.
> Read _ADR and LVR from the ACPI resources and extract the data

ADR have _, but not _ before LVR, I am not familary with ACPI.

> as per the ACPI specification for an I3C bus. Also read
> mipi-i3c-static-address as per the MIPI DISCO specifications [1]
> to get the static address to be used.
>
> Although the existing subsystem allows host controllers to register
> through the ACPI table, it was not possible to describe I3C or I2C
> devices there.

why?

> This change enables describing the I3C or I2C devices

Don't use "This commit/change/" just Enable ...

Frank
> in the ACPI table, which is required if the device is using a static
> address or if it needs some specific properties to be attached to it.
>
> [1] https://www.mipi.org/specifications/disco
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> ---
>  drivers/i3c/master.c | 101 +++++++++++++++++++++++++++++++++++++++----
>  1 file changed, 93 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index 2c479fecbfdf..15a356a2b3c8 100644
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c
> @@ -2404,12 +2404,31 @@ EXPORT_SYMBOL_GPL(i3c_master_add_i3c_dev_locked);
>
>  #define OF_I3C_REG1_IS_I2C_DEV			BIT(31)
>
> +static int i3c_acpi_get_i2c_resource(struct acpi_resource *ares, void *data)
> +{
> +	struct i2c_dev_boardinfo *boardinfo = data;
> +	struct acpi_resource_i2c_serialbus *sb;
> +
> +	if (!i2c_acpi_get_i2c_resource(ares, &sb))
> +		return 1;
> +
> +	boardinfo->base.addr = sb->slave_address;
> +	if (sb->access_mode == ACPI_I2C_10BIT_MODE)
> +		boardinfo->base.flags |= I2C_CLIENT_TEN;
> +
> +	boardinfo->lvr = sb->lvr;
> +
> +	return 0;
> +}
> +
>  static int
>  i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
>  			     struct fwnode_handle *fwnode, u32 *reg)
>  {
>  	struct i2c_dev_boardinfo *boardinfo;
>  	struct device *dev = &master->dev;
> +	struct acpi_device *adev;
> +	LIST_HEAD(resources);
>  	int ret;
>
>  	boardinfo = devm_kzalloc(dev, sizeof(*boardinfo), GFP_KERNEL);
> @@ -2420,6 +2439,23 @@ i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
>  		ret = of_i2c_get_board_info(dev, to_of_node(fwnode), &boardinfo->base);
>  		if (ret)
>  			return ret;
> +
> +		/* LVR is encoded in reg[2] for Device Tree. */
> +		boardinfo->lvr = reg[2];
> +	} else if (is_acpi_device_node(fwnode)) {
> +		adev = to_acpi_device_node(fwnode);
> +		boardinfo->base.fwnode = acpi_fwnode_handle(adev);
> +
> +		ret = acpi_dev_get_resources(adev, &resources,
> +					     i3c_acpi_get_i2c_resource, boardinfo);
> +
> +		if (ret < 0)
> +			return ret;
> +
> +		acpi_dev_free_resource_list(&resources);
> +
> +		if (!boardinfo->base.addr)
> +			return -ENODEV;
>  	} else {
>  		return -EINVAL;
>  	}
> @@ -2434,9 +2470,6 @@ i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
>  		return -EOPNOTSUPP;
>  	}
>
> -	/* LVR is encoded in reg[2]. */
> -	boardinfo->lvr = reg[2];
> -
>  	list_add_tail(&boardinfo->node, &master->boardinfo.i2c);
>  	fwnode_handle_get(fwnode);
>
> @@ -2491,8 +2524,8 @@ i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
>  	return 0;
>  }
>
> -static int i3c_master_add_dev(struct i3c_master_controller *master,
> -			      struct fwnode_handle *fwnode)
> +static int i3c_master_add_of_dev(struct i3c_master_controller *master,
> +				 struct fwnode_handle *fwnode)
>  {
>  	u32 reg[3];
>  	int ret;
> @@ -2516,6 +2549,31 @@ static int i3c_master_add_dev(struct i3c_master_controller *master,
>  	return ret;
>  }
>
> +static int i3c_master_add_acpi_dev(struct i3c_master_controller *master,
> +				   struct fwnode_handle *fwnode)
> +{
> +	struct acpi_device *adev = to_acpi_device_node(fwnode);
> +	acpi_bus_address adr;
> +	u32 reg[3] = { 0 };
> +
> +	/*
> +	 * If the ACPI table entry does not have _ADR method, it's an I2C device
> +	 * If the ACPI table entry has _ADR method, it's an I3C device
> +	 */
> +	if (!acpi_has_method(adev->handle, "_ADR"))
> +		return i3c_master_add_i2c_boardinfo(master, fwnode, reg);
> +
> +	adr = acpi_device_adr(adev);
> +
> +	/* For I3C devices, _ADR will have the 48 bit PID of the device  */
> +	reg[1] = upper_32_bits(adr);
> +	reg[2] = lower_32_bits(adr);
> +
> +	fwnode_property_read_u32(fwnode, "mipi-i3c-static-address", &reg[0]);
> +
> +	return i3c_master_add_i3c_boardinfo(master, fwnode, reg);
> +}
> +
>  static int fwnode_populate_i3c_bus(struct i3c_master_controller *master)
>  {
>  	struct device *dev = &master->dev;
> @@ -2527,7 +2585,13 @@ static int fwnode_populate_i3c_bus(struct i3c_master_controller *master)
>  		return 0;
>
>  	fwnode_for_each_available_child_node_scoped(fwnode, child) {
> -		ret = i3c_master_add_dev(master, child);
> +		if (is_of_node(child))
> +			ret = i3c_master_add_of_dev(master, child);
> +		else if (is_acpi_device_node(child))
> +			ret = i3c_master_add_acpi_dev(master, child);
> +		else
> +			continue;
> +
>  		if (ret)
>  			return ret;
>  	}
> @@ -2593,10 +2657,31 @@ static u8 i3c_master_i2c_get_lvr(struct i2c_client *client)
>  {
>  	/* Fall back to no spike filters and FM bus mode. */
>  	u8 lvr = I3C_LVR_I2C_INDEX(2) | I3C_LVR_I2C_FM_MODE;
> +	struct i2c_dev_boardinfo boardinfo;
> +	struct acpi_device *adev;
> +	LIST_HEAD(resources);
>  	u32 reg[3];
> +	int ret;
> +
> +	if (is_of_node(client->dev.fwnode)) {
> +		if (!fwnode_property_read_u32_array(client->dev.fwnode, "reg",
> +						    reg, ARRAY_SIZE(reg)))
> +			lvr = reg[2];
> +	} else if (is_acpi_device_node(client->dev.fwnode)) {
> +		adev = to_acpi_device_node(client->dev.fwnode);
> +		memset(&boardinfo, 0, sizeof(boardinfo));
> +
> +		ret = acpi_dev_get_resources(adev, &resources,
> +					     i3c_acpi_get_i2c_resource, &boardinfo);
>
> -	if (!fwnode_property_read_u32_array(client->dev.fwnode, "reg", reg, ARRAY_SIZE(reg)))
> -		lvr = reg[2];
> +		if (ret < 0)
> +			return lvr;
> +
> +		if (boardinfo.base.addr)
> +			lvr = boardinfo.lvr;
> +
> +		acpi_dev_free_resource_list(&resources);
> +	}
>
>  	return lvr;
>  }
> --
> 2.50.1
>

Re: [PATCH 04/12] i3c: master: Support ACPI enumeration

[Akhil R]

On Thu, 19 Mar 2026 10:29:38 -0400, Frank Li wrote:
> On Wed, Mar 18, 2026 at 10:57:17PM +0530, Akhil R wrote:
>> Support ACPI enumeration for I2C and I3C devices on an I3C bus.
>> Read _ADR and LVR from the ACPI resources and extract the data
> 
> ADR have _, but not _ before LVR, I am not familary with ACPI.

'_ADR' is a static ACPI object (or method), but LVR is not.
LVR (Legacy Virtual Register) has to be read by parsing the
ACPI I2C serial resource.

> 
>> as per the ACPI specification for an I3C bus. Also read
>> mipi-i3c-static-address as per the MIPI DISCO specifications [1]
>> to get the static address to be used.
>>
>> Although the existing subsystem allows host controllers to register
>> through the ACPI table, it was not possible to describe I3C or I2C
>> devices there.
> 
> why?

The existing code relied on the 'reg' property to get PID, static address etc.
ACPI table entries do not use reg property, instead use _ADR or other resource
objects. Also for ACPI, MIPI recommends a different format which encodes the
details in the _ADR object. The specification also includes a few additional
properties like mipi-i3c-static-address, mipi-i3c-static-method etc. which
the new code follows.

> 
>> This change enables describing the I3C or I2C devices
> 
> Don't use "This commit/change/" just Enable ...

Ack. Will update.

Best Regards,
Akhil

Re: [PATCH 04/12] i3c: master: Support ACPI enumeration

[kernel test robot]

Hi Akhil,

kernel test robot noticed the following build errors:

[auto build test ERROR on next-20260320]
[also build test ERROR on linus/master v7.0-rc4]
[cannot apply to i3c/i3c/next rafael-pm/linux-next rafael-pm/bleeding-edge groeck-staging/hwmon-next v7.0-rc4 v7.0-rc3 v7.0-rc2]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Akhil-R/dt-bindings-i3c-Add-mipi-i3c-static-method-to-support-SETAASA/20260322-174037
base:   next-20260320
patch link:    https://lore.kernel.org/r/20260318172820.13771-5-akhilrajeev%40nvidia.com
patch subject: [PATCH 04/12] i3c: master: Support ACPI enumeration
config: sparc-randconfig-002-20260322 (https://download.01.org/0day-ci/archive/20260323/202603230007.WOMwklQ6-lkp@intel.com/config)
compiler: sparc-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260323/202603230007.WOMwklQ6-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603230007.WOMwklQ6-lkp@intel.com/

All errors (new ones prefixed by >>):

   drivers/i3c/master.c: In function 'i3c_master_add_i2c_boardinfo':
>> drivers/i3c/master.c:2449:23: error: implicit declaration of function 'acpi_dev_get_resources'; did you mean 'acpi_get_event_resources'? [-Wimplicit-function-declaration]
    2449 |                 ret = acpi_dev_get_resources(adev, &resources,
         |                       ^~~~~~~~~~~~~~~~~~~~~~
         |                       acpi_get_event_resources
>> drivers/i3c/master.c:2455:17: error: implicit declaration of function 'acpi_dev_free_resource_list' [-Wimplicit-function-declaration]
    2455 |                 acpi_dev_free_resource_list(&resources);
         |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/i3c/master.c: In function 'i3c_master_add_acpi_dev':
>> drivers/i3c/master.c:2556:9: error: unknown type name 'acpi_bus_address'; did you mean 'acpi_io_address'?
    2556 |         acpi_bus_address adr;
         |         ^~~~~~~~~~~~~~~~
         |         acpi_io_address
>> drivers/i3c/master.c:2563:14: error: implicit declaration of function 'acpi_has_method'; did you mean 'acpi_has_watchdog'? [-Wimplicit-function-declaration]
    2563 |         if (!acpi_has_method(adev->handle, "_ADR"))
         |              ^~~~~~~~~~~~~~~
         |              acpi_has_watchdog
>> drivers/i3c/master.c:2563:34: error: invalid use of undefined type 'struct acpi_device'
    2563 |         if (!acpi_has_method(adev->handle, "_ADR"))
         |                                  ^~
>> drivers/i3c/master.c:2566:15: error: implicit declaration of function 'acpi_device_adr'; did you mean 'acpi_device_handle'? [-Wimplicit-function-declaration]
    2566 |         adr = acpi_device_adr(adev);
         |               ^~~~~~~~~~~~~~~
         |               acpi_device_handle


vim +2449 drivers/i3c/master.c

  2423	
  2424	static int
  2425	i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
  2426				     struct fwnode_handle *fwnode, u32 *reg)
  2427	{
  2428		struct i2c_dev_boardinfo *boardinfo;
  2429		struct device *dev = &master->dev;
  2430		struct acpi_device *adev;
  2431		LIST_HEAD(resources);
  2432		int ret;
  2433	
  2434		boardinfo = devm_kzalloc(dev, sizeof(*boardinfo), GFP_KERNEL);
  2435		if (!boardinfo)
  2436			return -ENOMEM;
  2437	
  2438		if (is_of_node(fwnode)) {
  2439			ret = of_i2c_get_board_info(dev, to_of_node(fwnode), &boardinfo->base);
  2440			if (ret)
  2441				return ret;
  2442	
  2443			/* LVR is encoded in reg[2] for Device Tree. */
  2444			boardinfo->lvr = reg[2];
  2445		} else if (is_acpi_device_node(fwnode)) {
  2446			adev = to_acpi_device_node(fwnode);
  2447			boardinfo->base.fwnode = acpi_fwnode_handle(adev);
  2448	
> 2449			ret = acpi_dev_get_resources(adev, &resources,
  2450						     i3c_acpi_get_i2c_resource, boardinfo);
  2451	
  2452			if (ret < 0)
  2453				return ret;
  2454	
> 2455			acpi_dev_free_resource_list(&resources);
  2456	
  2457			if (!boardinfo->base.addr)
  2458				return -ENODEV;
  2459		} else {
  2460			return -EINVAL;
  2461		}
  2462	
  2463		/*
  2464		 * The I3C Specification does not clearly say I2C devices with 10-bit
  2465		 * address are supported. These devices can't be passed properly through
  2466		 * DEFSLVS command.
  2467		 */
  2468		if (boardinfo->base.flags & I2C_CLIENT_TEN) {
  2469			dev_err(dev, "I2C device with 10 bit address not supported.");
  2470			return -EOPNOTSUPP;
  2471		}
  2472	
  2473		list_add_tail(&boardinfo->node, &master->boardinfo.i2c);
  2474		fwnode_handle_get(fwnode);
  2475	
  2476		return 0;
  2477	}
  2478	
  2479	static int
  2480	i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
  2481				     struct fwnode_handle *fwnode, u32 *reg)
  2482	{
  2483		struct i3c_dev_boardinfo *boardinfo;
  2484		struct device *dev = &master->dev;
  2485		enum i3c_addr_slot_status addrstatus;
  2486		u32 init_dyn_addr = 0;
  2487	
  2488		boardinfo = devm_kzalloc(dev, sizeof(*boardinfo), GFP_KERNEL);
  2489		if (!boardinfo)
  2490			return -ENOMEM;
  2491	
  2492		if (reg[0]) {
  2493			if (reg[0] > I3C_MAX_ADDR)
  2494				return -EINVAL;
  2495	
  2496			addrstatus = i3c_bus_get_addr_slot_status(&master->bus,
  2497								  reg[0]);
  2498			if (addrstatus != I3C_ADDR_SLOT_FREE)
  2499				return -EINVAL;
  2500		}
  2501	
  2502		boardinfo->static_addr = reg[0];
  2503	
  2504		if (!fwnode_property_read_u32(fwnode, "assigned-address", &init_dyn_addr)) {
  2505			if (init_dyn_addr > I3C_MAX_ADDR)
  2506				return -EINVAL;
  2507	
  2508			addrstatus = i3c_bus_get_addr_slot_status(&master->bus,
  2509								  init_dyn_addr);
  2510			if (addrstatus != I3C_ADDR_SLOT_FREE)
  2511				return -EINVAL;
  2512		}
  2513	
  2514		boardinfo->pid = ((u64)reg[1] << 32) | reg[2];
  2515	
  2516		if ((boardinfo->pid & GENMASK_ULL(63, 48)) ||
  2517		    I3C_PID_RND_LOWER_32BITS(boardinfo->pid))
  2518			return -EINVAL;
  2519	
  2520		boardinfo->init_dyn_addr = init_dyn_addr;
  2521		boardinfo->fwnode = fwnode_handle_get(fwnode);
  2522		list_add_tail(&boardinfo->node, &master->boardinfo.i3c);
  2523	
  2524		return 0;
  2525	}
  2526	
  2527	static int i3c_master_add_of_dev(struct i3c_master_controller *master,
  2528					 struct fwnode_handle *fwnode)
  2529	{
  2530		u32 reg[3];
  2531		int ret;
  2532	
  2533		if (!master)
  2534			return -EINVAL;
  2535	
  2536		ret = fwnode_property_read_u32_array(fwnode, "reg", reg, ARRAY_SIZE(reg));
  2537		if (ret)
  2538			return ret;
  2539	
  2540		/*
  2541		 * The manufacturer ID can't be 0. If reg[1] == 0 that means we're
  2542		 * dealing with an I2C device.
  2543		 */
  2544		if (!reg[1])
  2545			ret = i3c_master_add_i2c_boardinfo(master, fwnode, reg);
  2546		else
  2547			ret = i3c_master_add_i3c_boardinfo(master, fwnode, reg);
  2548	
  2549		return ret;
  2550	}
  2551	
  2552	static int i3c_master_add_acpi_dev(struct i3c_master_controller *master,
  2553					   struct fwnode_handle *fwnode)
  2554	{
  2555		struct acpi_device *adev = to_acpi_device_node(fwnode);
> 2556		acpi_bus_address adr;
  2557		u32 reg[3] = { 0 };
  2558	
  2559		/*
  2560		 * If the ACPI table entry does not have _ADR method, it's an I2C device
  2561		 * If the ACPI table entry has _ADR method, it's an I3C device
  2562		 */
> 2563		if (!acpi_has_method(adev->handle, "_ADR"))
  2564			return i3c_master_add_i2c_boardinfo(master, fwnode, reg);
  2565	
> 2566		adr = acpi_device_adr(adev);
  2567	
  2568		/* For I3C devices, _ADR will have the 48 bit PID of the device  */
  2569		reg[1] = upper_32_bits(adr);
  2570		reg[2] = lower_32_bits(adr);
  2571	
  2572		fwnode_property_read_u32(fwnode, "mipi-i3c-static-address", &reg[0]);
  2573	
  2574		return i3c_master_add_i3c_boardinfo(master, fwnode, reg);
  2575	}
  2576	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH 04/12] i3c: master: Support ACPI enumeration

[kernel test robot]

Hi Akhil,

kernel test robot noticed the following build errors:

[auto build test ERROR on next-20260320]
[also build test ERROR on linus/master v7.0-rc4]
[cannot apply to i3c/i3c/next rafael-pm/linux-next rafael-pm/bleeding-edge groeck-staging/hwmon-next v7.0-rc4 v7.0-rc3 v7.0-rc2]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Akhil-R/dt-bindings-i3c-Add-mipi-i3c-static-method-to-support-SETAASA/20260322-174037
base:   next-20260320
patch link:    https://lore.kernel.org/r/20260318172820.13771-5-akhilrajeev%40nvidia.com
patch subject: [PATCH 04/12] i3c: master: Support ACPI enumeration
config: hexagon-randconfig-002-20260322 (https://download.01.org/0day-ci/archive/20260323/202603230124.VFt6CPBe-lkp@intel.com/config)
compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project 4abb927bacf37f18f6359a41639a6d1b3bffffb5)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260323/202603230124.VFt6CPBe-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603230124.VFt6CPBe-lkp@intel.com/

All errors (new ones prefixed by >>):

>> drivers/i3c/master.c:2449:9: error: call to undeclared function 'acpi_dev_get_resources'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    2449 |                 ret = acpi_dev_get_resources(adev, &resources,
         |                       ^
   drivers/i3c/master.c:2449:9: note: did you mean 'acpi_get_event_resources'?
   include/acpi/acpixf.h:816:9: note: 'acpi_get_event_resources' declared here
     816 |                              acpi_get_event_resources(acpi_handle device_handle,
         |                              ^
   include/acpi/platform/aclinux.h:93:21: note: expanded from macro 'ACPI_EXTERNAL_RETURN_STATUS'
      93 |         static ACPI_INLINE prototype {return(AE_NOT_CONFIGURED);}
         |                            ^
>> drivers/i3c/master.c:2455:3: error: call to undeclared function 'acpi_dev_free_resource_list'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    2455 |                 acpi_dev_free_resource_list(&resources);
         |                 ^
   drivers/i3c/master.c:2556:2: error: unknown type name 'acpi_bus_address'; did you mean 'acpi_io_address'?
    2556 |         acpi_bus_address adr;
         |         ^~~~~~~~~~~~~~~~
         |         acpi_io_address
   include/acpi/actypes.h:187:13: note: 'acpi_io_address' declared here
     187 | typedef u64 acpi_io_address;
         |             ^
>> drivers/i3c/master.c:2563:7: error: call to undeclared function 'acpi_has_method'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    2563 |         if (!acpi_has_method(adev->handle, "_ADR"))
         |              ^
   drivers/i3c/master.c:2563:7: note: did you mean 'acpi_has_watchdog'?
   include/linux/acpi.h:1504:20: note: 'acpi_has_watchdog' declared here
    1504 | static inline bool acpi_has_watchdog(void) { return false; }
         |                    ^
>> drivers/i3c/master.c:2563:27: error: incomplete definition of type 'struct acpi_device'
    2563 |         if (!acpi_has_method(adev->handle, "_ADR"))
         |                              ~~~~^
   include/linux/device/bus.h:224:8: note: forward declaration of 'struct acpi_device'
     224 | struct acpi_device;
         |        ^
>> drivers/i3c/master.c:2566:8: error: call to undeclared function 'acpi_device_adr'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    2566 |         adr = acpi_device_adr(adev);
         |               ^
   drivers/i3c/master.c:2566:8: note: did you mean 'acpi_device_handle'?
   include/linux/acpi.h:883:27: note: 'acpi_device_handle' declared here
     883 | static inline acpi_handle acpi_device_handle(struct acpi_device *adev)
         |                           ^
   drivers/i3c/master.c:2674:9: error: call to undeclared function 'acpi_dev_get_resources'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    2674 |                 ret = acpi_dev_get_resources(adev, &resources,
         |                       ^
   drivers/i3c/master.c:2683:3: error: call to undeclared function 'acpi_dev_free_resource_list'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    2683 |                 acpi_dev_free_resource_list(&resources);
         |                 ^
   8 errors generated.


vim +/acpi_dev_get_resources +2449 drivers/i3c/master.c

  2423	
  2424	static int
  2425	i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
  2426				     struct fwnode_handle *fwnode, u32 *reg)
  2427	{
  2428		struct i2c_dev_boardinfo *boardinfo;
  2429		struct device *dev = &master->dev;
  2430		struct acpi_device *adev;
  2431		LIST_HEAD(resources);
  2432		int ret;
  2433	
  2434		boardinfo = devm_kzalloc(dev, sizeof(*boardinfo), GFP_KERNEL);
  2435		if (!boardinfo)
  2436			return -ENOMEM;
  2437	
  2438		if (is_of_node(fwnode)) {
  2439			ret = of_i2c_get_board_info(dev, to_of_node(fwnode), &boardinfo->base);
  2440			if (ret)
  2441				return ret;
  2442	
  2443			/* LVR is encoded in reg[2] for Device Tree. */
  2444			boardinfo->lvr = reg[2];
  2445		} else if (is_acpi_device_node(fwnode)) {
  2446			adev = to_acpi_device_node(fwnode);
  2447			boardinfo->base.fwnode = acpi_fwnode_handle(adev);
  2448	
> 2449			ret = acpi_dev_get_resources(adev, &resources,
  2450						     i3c_acpi_get_i2c_resource, boardinfo);
  2451	
  2452			if (ret < 0)
  2453				return ret;
  2454	
> 2455			acpi_dev_free_resource_list(&resources);
  2456	
  2457			if (!boardinfo->base.addr)
  2458				return -ENODEV;
  2459		} else {
  2460			return -EINVAL;
  2461		}
  2462	
  2463		/*
  2464		 * The I3C Specification does not clearly say I2C devices with 10-bit
  2465		 * address are supported. These devices can't be passed properly through
  2466		 * DEFSLVS command.
  2467		 */
  2468		if (boardinfo->base.flags & I2C_CLIENT_TEN) {
  2469			dev_err(dev, "I2C device with 10 bit address not supported.");
  2470			return -EOPNOTSUPP;
  2471		}
  2472	
  2473		list_add_tail(&boardinfo->node, &master->boardinfo.i2c);
  2474		fwnode_handle_get(fwnode);
  2475	
  2476		return 0;
  2477	}
  2478	
  2479	static int
  2480	i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
  2481				     struct fwnode_handle *fwnode, u32 *reg)
  2482	{
  2483		struct i3c_dev_boardinfo *boardinfo;
  2484		struct device *dev = &master->dev;
  2485		enum i3c_addr_slot_status addrstatus;
  2486		u32 init_dyn_addr = 0;
  2487	
  2488		boardinfo = devm_kzalloc(dev, sizeof(*boardinfo), GFP_KERNEL);
  2489		if (!boardinfo)
  2490			return -ENOMEM;
  2491	
  2492		if (reg[0]) {
  2493			if (reg[0] > I3C_MAX_ADDR)
  2494				return -EINVAL;
  2495	
  2496			addrstatus = i3c_bus_get_addr_slot_status(&master->bus,
  2497								  reg[0]);
  2498			if (addrstatus != I3C_ADDR_SLOT_FREE)
  2499				return -EINVAL;
  2500		}
  2501	
  2502		boardinfo->static_addr = reg[0];
  2503	
  2504		if (!fwnode_property_read_u32(fwnode, "assigned-address", &init_dyn_addr)) {
  2505			if (init_dyn_addr > I3C_MAX_ADDR)
  2506				return -EINVAL;
  2507	
  2508			addrstatus = i3c_bus_get_addr_slot_status(&master->bus,
  2509								  init_dyn_addr);
  2510			if (addrstatus != I3C_ADDR_SLOT_FREE)
  2511				return -EINVAL;
  2512		}
  2513	
  2514		boardinfo->pid = ((u64)reg[1] << 32) | reg[2];
  2515	
  2516		if ((boardinfo->pid & GENMASK_ULL(63, 48)) ||
  2517		    I3C_PID_RND_LOWER_32BITS(boardinfo->pid))
  2518			return -EINVAL;
  2519	
  2520		boardinfo->init_dyn_addr = init_dyn_addr;
  2521		boardinfo->fwnode = fwnode_handle_get(fwnode);
  2522		list_add_tail(&boardinfo->node, &master->boardinfo.i3c);
  2523	
  2524		return 0;
  2525	}
  2526	
  2527	static int i3c_master_add_of_dev(struct i3c_master_controller *master,
  2528					 struct fwnode_handle *fwnode)
  2529	{
  2530		u32 reg[3];
  2531		int ret;
  2532	
  2533		if (!master)
  2534			return -EINVAL;
  2535	
  2536		ret = fwnode_property_read_u32_array(fwnode, "reg", reg, ARRAY_SIZE(reg));
  2537		if (ret)
  2538			return ret;
  2539	
  2540		/*
  2541		 * The manufacturer ID can't be 0. If reg[1] == 0 that means we're
  2542		 * dealing with an I2C device.
  2543		 */
  2544		if (!reg[1])
  2545			ret = i3c_master_add_i2c_boardinfo(master, fwnode, reg);
  2546		else
  2547			ret = i3c_master_add_i3c_boardinfo(master, fwnode, reg);
  2548	
  2549		return ret;
  2550	}
  2551	
  2552	static int i3c_master_add_acpi_dev(struct i3c_master_controller *master,
  2553					   struct fwnode_handle *fwnode)
  2554	{
  2555		struct acpi_device *adev = to_acpi_device_node(fwnode);
> 2556		acpi_bus_address adr;
  2557		u32 reg[3] = { 0 };
  2558	
  2559		/*
  2560		 * If the ACPI table entry does not have _ADR method, it's an I2C device
  2561		 * If the ACPI table entry has _ADR method, it's an I3C device
  2562		 */
> 2563		if (!acpi_has_method(adev->handle, "_ADR"))
  2564			return i3c_master_add_i2c_boardinfo(master, fwnode, reg);
  2565	
> 2566		adr = acpi_device_adr(adev);
  2567	
  2568		/* For I3C devices, _ADR will have the 48 bit PID of the device  */
  2569		reg[1] = upper_32_bits(adr);
  2570		reg[2] = lower_32_bits(adr);
  2571	
  2572		fwnode_property_read_u32(fwnode, "mipi-i3c-static-address", &reg[0]);
  2573	
  2574		return i3c_master_add_i3c_boardinfo(master, fwnode, reg);
  2575	}
  2576	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH 04/12] i3c: master: Support ACPI enumeration

[Akhil R]

On Mon, 23 Mar 2026 01:47:20 +0800, kernel test robot wrote:
> kernel test robot noticed the following build errors:
> 
> [auto build test ERROR on next-20260320]
> [also build test ERROR on linus/master v7.0-rc4]
> [cannot apply to i3c/i3c/next rafael-pm/linux-next rafael-pm/bleeding-edge groeck-staging/hwmon-next v7.0-rc4 v7.0-rc3 v7.0-rc2]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
> 
> url:    https://github.com/intel-lab-lkp/linux/commits/Akhil-R/dt-bindings-i3c-Add-mipi-i3c-static-method-to-support-SETAASA/20260322-174037
> base:   next-20260320
> patch link:    https://lore.kernel.org/r/20260318172820.13771-5-akhilrajeev%40nvidia.com
> patch subject: [PATCH 04/12] i3c: master: Support ACPI enumeration
> config: sparc-randconfig-002-20260322 (https://download.01.org/0day-ci/archive/20260323/202603230007.WOMwklQ6-lkp@intel.com/config)
> compiler: sparc-linux-gcc (GCC) 15.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260323/202603230007.WOMwklQ6-lkp@intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202603230007.WOMwklQ6-lkp@intel.com/
> 
> All errors (new ones prefixed by >>):
> 
>    drivers/i3c/master.c: In function 'i3c_master_add_i2c_boardinfo':
>>> drivers/i3c/master.c:2449:23: error: implicit declaration of function 'acpi_dev_get_resources'; did you mean 'acpi_get_event_resources'? [-Wimplicit-function-declaration]
>     2449 |                 ret = acpi_dev_get_resources(adev, &resources,
>          |                       ^~~~~~~~~~~~~~~~~~~~~~
>          |                       acpi_get_event_resources
>>> drivers/i3c/master.c:2455:17: error: implicit declaration of function 'acpi_dev_free_resource_list' [-Wimplicit-function-declaration]
>     2455 |                 acpi_dev_free_resource_list(&resources);
>          |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>    drivers/i3c/master.c: In function 'i3c_master_add_acpi_dev':
>>> drivers/i3c/master.c:2556:9: error: unknown type name 'acpi_bus_address'; did you mean 'acpi_io_address'?
>     2556 |         acpi_bus_address adr;
>          |         ^~~~~~~~~~~~~~~~
>          |         acpi_io_address
>>> drivers/i3c/master.c:2563:14: error: implicit declaration of function 'acpi_has_method'; did you mean 'acpi_has_watchdog'? [-Wimplicit-function-declaration]
>     2563 |         if (!acpi_has_method(adev->handle, "_ADR"))
>          |              ^~~~~~~~~~~~~~~
>          |              acpi_has_watchdog
>>> drivers/i3c/master.c:2563:34: error: invalid use of undefined type 'struct acpi_device'
>     2563 |         if (!acpi_has_method(adev->handle, "_ADR"))
>          |                                  ^~
>>> drivers/i3c/master.c:2566:15: error: implicit declaration of function 'acpi_device_adr'; did you mean 'acpi_device_handle'? [-Wimplicit-function-declaration]
>     2566 |         adr = acpi_device_adr(adev);
>          |               ^~~~~~~~~~~~~~~
>          |               acpi_device_handle

#include <linux/acpi.h> is added in PATCH 03/12. The functions' prototypes
are present in acpi.h. I think the bot checked this patch individually,
or did I miss something?

Best Regards,
Akhil

Re: [PATCH 04/12] i3c: master: Support ACPI enumeration

[Guenter Roeck]

On 3/23/26 11:42, Akhil R wrote:
> On Mon, 23 Mar 2026 01:47:20 +0800, kernel test robot wrote:
>> kernel test robot noticed the following build errors:
>>
>> [auto build test ERROR on next-20260320]
>> [also build test ERROR on linus/master v7.0-rc4]
>> [cannot apply to i3c/i3c/next rafael-pm/linux-next rafael-pm/bleeding-edge groeck-staging/hwmon-next v7.0-rc4 v7.0-rc3 v7.0-rc2]
>> [If your patch is applied to the wrong git tree, kindly drop us a note.
>> And when submitting patch, we suggest to use '--base' as documented in
>> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>>
>> url:    https://github.com/intel-lab-lkp/linux/commits/Akhil-R/dt-bindings-i3c-Add-mipi-i3c-static-method-to-support-SETAASA/20260322-174037
>> base:   next-20260320
>> patch link:    https://lore.kernel.org/r/20260318172820.13771-5-akhilrajeev%40nvidia.com
>> patch subject: [PATCH 04/12] i3c: master: Support ACPI enumeration
>> config: sparc-randconfig-002-20260322 (https://download.01.org/0day-ci/archive/20260323/202603230007.WOMwklQ6-lkp@intel.com/config)
>> compiler: sparc-linux-gcc (GCC) 15.2.0
>> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260323/202603230007.WOMwklQ6-lkp@intel.com/reproduce)
>>
>> If you fix the issue in a separate patch/commit (i.e. not just a new version of
>> the same patch/commit), kindly add following tags
>> | Reported-by: kernel test robot <lkp@intel.com>
>> | Closes: https://lore.kernel.org/oe-kbuild-all/202603230007.WOMwklQ6-lkp@intel.com/
>>
>> All errors (new ones prefixed by >>):
>>
>>     drivers/i3c/master.c: In function 'i3c_master_add_i2c_boardinfo':
>>>> drivers/i3c/master.c:2449:23: error: implicit declaration of function 'acpi_dev_get_resources'; did you mean 'acpi_get_event_resources'? [-Wimplicit-function-declaration]
>>      2449 |                 ret = acpi_dev_get_resources(adev, &resources,
>>           |                       ^~~~~~~~~~~~~~~~~~~~~~
>>           |                       acpi_get_event_resources
>>>> drivers/i3c/master.c:2455:17: error: implicit declaration of function 'acpi_dev_free_resource_list' [-Wimplicit-function-declaration]
>>      2455 |                 acpi_dev_free_resource_list(&resources);
>>           |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>>     drivers/i3c/master.c: In function 'i3c_master_add_acpi_dev':
>>>> drivers/i3c/master.c:2556:9: error: unknown type name 'acpi_bus_address'; did you mean 'acpi_io_address'?
>>      2556 |         acpi_bus_address adr;
>>           |         ^~~~~~~~~~~~~~~~
>>           |         acpi_io_address
>>>> drivers/i3c/master.c:2563:14: error: implicit declaration of function 'acpi_has_method'; did you mean 'acpi_has_watchdog'? [-Wimplicit-function-declaration]
>>      2563 |         if (!acpi_has_method(adev->handle, "_ADR"))
>>           |              ^~~~~~~~~~~~~~~
>>           |              acpi_has_watchdog
>>>> drivers/i3c/master.c:2563:34: error: invalid use of undefined type 'struct acpi_device'
>>      2563 |         if (!acpi_has_method(adev->handle, "_ADR"))
>>           |                                  ^~
>>>> drivers/i3c/master.c:2566:15: error: implicit declaration of function 'acpi_device_adr'; did you mean 'acpi_device_handle'? [-Wimplicit-function-declaration]
>>      2566 |         adr = acpi_device_adr(adev);
>>           |               ^~~~~~~~~~~~~~~
>>           |               acpi_device_handle
> 
> #include <linux/acpi.h> is added in PATCH 03/12. The functions' prototypes
> are present in acpi.h. I think the bot checked this patch individually,
> or did I miss something?
> 

Did you try to build this code with a sparc cross-compiler ?
Because, as far as I can see, the functions are not declared or available
if ACPI is not enabled (or available, as with sparc).

Guenter

Re: [PATCH 04/12] i3c: master: Support ACPI enumeration

[Alexandre Belloni]

On 24/03/2026 00:12:07+0530, Akhil R wrote:
> On Mon, 23 Mar 2026 01:47:20 +0800, kernel test robot wrote:
> > kernel test robot noticed the following build errors:
> > 
> > [auto build test ERROR on next-20260320]
> > [also build test ERROR on linus/master v7.0-rc4]
> > [cannot apply to i3c/i3c/next rafael-pm/linux-next rafael-pm/bleeding-edge groeck-staging/hwmon-next v7.0-rc4 v7.0-rc3 v7.0-rc2]
> > [If your patch is applied to the wrong git tree, kindly drop us a note.
> > And when submitting patch, we suggest to use '--base' as documented in
> > https://git-scm.com/docs/git-format-patch#_base_tree_information]
> > 
> > url:    https://github.com/intel-lab-lkp/linux/commits/Akhil-R/dt-bindings-i3c-Add-mipi-i3c-static-method-to-support-SETAASA/20260322-174037
> > base:   next-20260320
> > patch link:    https://lore.kernel.org/r/20260318172820.13771-5-akhilrajeev%40nvidia.com
> > patch subject: [PATCH 04/12] i3c: master: Support ACPI enumeration
> > config: sparc-randconfig-002-20260322 (https://download.01.org/0day-ci/archive/20260323/202603230007.WOMwklQ6-lkp@intel.com/config)
> > compiler: sparc-linux-gcc (GCC) 15.2.0
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260323/202603230007.WOMwklQ6-lkp@intel.com/reproduce)
> > 
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <lkp@intel.com>
> > | Closes: https://lore.kernel.org/oe-kbuild-all/202603230007.WOMwklQ6-lkp@intel.com/
> > 
> > All errors (new ones prefixed by >>):
> > 
> >    drivers/i3c/master.c: In function 'i3c_master_add_i2c_boardinfo':
> >>> drivers/i3c/master.c:2449:23: error: implicit declaration of function 'acpi_dev_get_resources'; did you mean 'acpi_get_event_resources'? [-Wimplicit-function-declaration]
> >     2449 |                 ret = acpi_dev_get_resources(adev, &resources,
> >          |                       ^~~~~~~~~~~~~~~~~~~~~~
> >          |                       acpi_get_event_resources
> >>> drivers/i3c/master.c:2455:17: error: implicit declaration of function 'acpi_dev_free_resource_list' [-Wimplicit-function-declaration]
> >     2455 |                 acpi_dev_free_resource_list(&resources);
> >          |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> >    drivers/i3c/master.c: In function 'i3c_master_add_acpi_dev':
> >>> drivers/i3c/master.c:2556:9: error: unknown type name 'acpi_bus_address'; did you mean 'acpi_io_address'?
> >     2556 |         acpi_bus_address adr;
> >          |         ^~~~~~~~~~~~~~~~
> >          |         acpi_io_address
> >>> drivers/i3c/master.c:2563:14: error: implicit declaration of function 'acpi_has_method'; did you mean 'acpi_has_watchdog'? [-Wimplicit-function-declaration]
> >     2563 |         if (!acpi_has_method(adev->handle, "_ADR"))
> >          |              ^~~~~~~~~~~~~~~
> >          |              acpi_has_watchdog
> >>> drivers/i3c/master.c:2563:34: error: invalid use of undefined type 'struct acpi_device'
> >     2563 |         if (!acpi_has_method(adev->handle, "_ADR"))
> >          |                                  ^~
> >>> drivers/i3c/master.c:2566:15: error: implicit declaration of function 'acpi_device_adr'; did you mean 'acpi_device_handle'? [-Wimplicit-function-declaration]
> >     2566 |         adr = acpi_device_adr(adev);
> >          |               ^~~~~~~~~~~~~~~
> >          |               acpi_device_handle
> 
> #include <linux/acpi.h> is added in PATCH 03/12. The functions' prototypes
> are present in acpi.h. I think the bot checked this patch individually,
> or did I miss something?
> 


#include <acpi/acpi_bus.h> is behind an #ifdef in acpi.h and your code
is not.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH 04/12] i3c: master: Support ACPI enumeration

[Akhil R]

On Tue, 24 Mar 2026 09:43:27 +0100, Alexandre Belloni wrote:

...

>> #include <linux/acpi.h> is added in PATCH 03/12. The functions' prototypes
>> are present in acpi.h. I think the bot checked this patch individually,
>> or did I miss something?
>> 
> 
> #include <acpi/acpi_bus.h> is behind an #ifdef in acpi.h and your code
> is not.

Thanks for pointing Alexandre and Guenter. I also noticed that we do not
have stub functions for a few of the acpi_* functions in #else.

Looks like I will have to guard calls to these functions under
#ifdef CONFIG_ACPI.

Best Regards,
Akhil

Re: [PATCH 04/12] i3c: master: Support ACPI enumeration

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

On Tue, Mar 24, 2026 at 10:52:15PM +0530, Akhil R wrote:
> On Tue, 24 Mar 2026 09:43:27 +0100, Alexandre Belloni wrote:
> 
> ...
> 
> >> #include <linux/acpi.h> is added in PATCH 03/12. The functions' prototypes
> >> are present in acpi.h. I think the bot checked this patch individually,
> >> or did I miss something?
> >> 
> > 
> > #include <acpi/acpi_bus.h> is behind an #ifdef in acpi.h and your code
> > is not.
> 
> Thanks for pointing Alexandre and Guenter. I also noticed that we do not
> have stub functions for a few of the acpi_* functions in #else.
> 
> Looks like I will have to guard calls to these functions under
> #ifdef CONFIG_ACPI.

Alternatively it might make sense to add the stubs in a separate patch.
I don't know if they were purposefully left out or nobody's ever run
into the lack of these before.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH 05/12] i3c: master: Add support for devices using SETAASA

[Akhil R]

Add support for devices using SETAASA, such as SPD5118 and SPD5108
attached to DDR5 memory modules that do not support ENTDAA. Follow the
guidelines proposed by the MIPI Discovery and Configuration
Specification[1] for discovering such devices.

SETAASA (Set All Addresses to Static Address) differs from standard I3C
address assignment that uses ENTDAA or SETDASA to assign dynamic
addresses. Devices using SETAASA assign their pre-defined static
addresses as their dynamic addresses during DAA, and it is not mandatory
for these devices to implement standard CCC commands like GETPID, GETDCR,
or GETBCR. For such devices, it is generally recommended to issue SETHID
(specified by JEDEC JESD300) as a prerequisite for SETAASA to stop HID
bit flipping.

[1] https://www.mipi.org/specifications/disco

Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
 drivers/i3c/master.c       | 72 +++++++++++++++++++++++++++++++++++++-
 include/linux/i3c/ccc.h    |  1 +
 include/linux/i3c/master.h | 17 +++++++++
 3 files changed, 89 insertions(+), 1 deletion(-)

diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index 15a356a2b3c8..40a3bb734234 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -1049,6 +1049,47 @@ static int i3c_master_rstdaa_locked(struct i3c_master_controller *master,
 	return ret;
 }
 
+/**
+ * i3c_master_setaasa_locked() - start a SETAASA procedure (Set All Addresses to Static Address)
+ * @master: I3C master object
+ *
+ * Send a SETAASA CCC command to set all attached I3C devices' dynamic addresses to
+ * their static address.
+ *
+ * This function must be called with the bus lock held in write mode.
+ *
+ * First, the SETHID CCC command is sent, followed by the SETAASA CCC.
+ *
+ * Return: 0 in case of success, a positive I3C error code if the error is
+ * one of the official Mx error codes, and a negative error code otherwise.
+ */
+static int i3c_master_setaasa_locked(struct i3c_master_controller *master)
+{
+	struct i3c_ccc_cmd_dest dest;
+	struct i3c_ccc_cmd cmd;
+	int ret;
+
+	/*
+	 * Send SETHID CCC command. Though it is a standard CCC command specified
+	 * in JESD300-5, we are not defining a separate macro to be explicit that
+	 * the value falls under the vendor specific range.
+	 */
+	i3c_ccc_cmd_dest_init(&dest, I3C_BROADCAST_ADDR, 0);
+	i3c_ccc_cmd_init(&cmd, false, I3C_CCC_VENDOR(0, true), &dest, 1);
+	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+	i3c_ccc_cmd_dest_cleanup(&dest);
+	if (ret)
+		return ret;
+
+	/* Send SETAASA CCC command */
+	i3c_ccc_cmd_dest_init(&dest, I3C_BROADCAST_ADDR, 0);
+	i3c_ccc_cmd_init(&cmd, false, I3C_CCC_SETAASA, &dest, 1);
+	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+	i3c_ccc_cmd_dest_cleanup(&dest);
+
+	return ret;
+}
+
 /**
  * i3c_master_entdaa_locked() - start a DAA (Dynamic Address Assignment)
  *				procedure
@@ -1733,6 +1774,18 @@ static int i3c_master_early_i3c_dev_add(struct i3c_master_controller *master,
 	if (ret)
 		goto err_free_dev;
 
+	/*
+	 * For devices using SETAASA instead of ENTDAA, the address is statically
+	 * assigned. Update the dynamic address to the provided static address.
+	 * Reattaching the I3C device is not useful. It is also not mandatory
+	 * for such devices to implement CCC commands like GETPID, GETDCR etc.
+	 * Hence, we can return here.
+	 */
+	if (i3cdev->boardinfo->static_addr_method & I3C_ADDR_METHOD_SETAASA) {
+		i3cdev->info.dyn_addr = i3cdev->boardinfo->static_addr;
+		return 0;
+	}
+
 	ret = i3c_master_setdasa_locked(master, i3cdev->info.static_addr,
 					i3cdev->boardinfo->init_dyn_addr);
 	if (ret)
@@ -2132,6 +2185,12 @@ static int i3c_master_bus_init(struct i3c_master_controller *master)
 			goto err_bus_cleanup;
 	}
 
+	if (master->addr_method & I3C_ADDR_METHOD_SETAASA) {
+		ret = i3c_master_setaasa_locked(master);
+		if (ret)
+			goto err_bus_cleanup;
+	}
+
 	/* Disable all slave events before starting DAA. */
 	ret = i3c_master_disec_locked(master, I3C_BROADCAST_ADDR,
 				      I3C_CCC_EVENT_SIR | I3C_CCC_EVENT_MR |
@@ -2483,7 +2542,7 @@ i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
 	struct i3c_dev_boardinfo *boardinfo;
 	struct device *dev = &master->dev;
 	enum i3c_addr_slot_status addrstatus;
-	u32 init_dyn_addr = 0;
+	u32 init_dyn_addr = 0, static_addr_method = 0;
 
 	boardinfo = devm_kzalloc(dev, sizeof(*boardinfo), GFP_KERNEL);
 	if (!boardinfo)
@@ -2511,6 +2570,16 @@ i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
 			return -EINVAL;
 	}
 
+	if (!fwnode_property_read_u32(fwnode, "mipi-i3c-static-method", &static_addr_method)) {
+		if (static_addr_method & ~(I3C_ADDR_METHOD_SETDASA | I3C_ADDR_METHOD_SETAASA))
+			dev_warn(dev, "Invalid bits set in mipi-i3c-static-method, ignoring.\n");
+		else
+			boardinfo->static_addr_method = static_addr_method;
+	}
+
+	/* Update the address methods required for device discovery */
+	master->addr_method |= boardinfo->static_addr_method;
+
 	boardinfo->pid = ((u64)reg[1] << 32) | reg[2];
 
 	if ((boardinfo->pid & GENMASK_ULL(63, 48)) ||
@@ -3118,6 +3187,7 @@ int i3c_master_register(struct i3c_master_controller *master,
 	master->dev.release = i3c_masterdev_release;
 	master->ops = ops;
 	master->secondary = secondary;
+	master->addr_method = I3C_ADDR_METHOD_SETDASA;
 	INIT_LIST_HEAD(&master->boardinfo.i2c);
 	INIT_LIST_HEAD(&master->boardinfo.i3c);
 
diff --git a/include/linux/i3c/ccc.h b/include/linux/i3c/ccc.h
index ad59a4ae60d1..a145d766ab6f 100644
--- a/include/linux/i3c/ccc.h
+++ b/include/linux/i3c/ccc.h
@@ -32,6 +32,7 @@
 #define I3C_CCC_DEFSLVS			I3C_CCC_ID(0x8, true)
 #define I3C_CCC_ENTTM			I3C_CCC_ID(0xb, true)
 #define I3C_CCC_ENTHDR(x)		I3C_CCC_ID(0x20 + (x), true)
+#define I3C_CCC_SETAASA			I3C_CCC_ID(0x29, true)
 
 /* Unicast-only commands */
 #define I3C_CCC_SETDASA			I3C_CCC_ID(0x7, false)
diff --git a/include/linux/i3c/master.h b/include/linux/i3c/master.h
index 6b03a3ce574c..71802d9b5943 100644
--- a/include/linux/i3c/master.h
+++ b/include/linux/i3c/master.h
@@ -174,6 +174,14 @@ struct i3c_device_ibi_info {
  *		 assigned a dynamic address by the master. Will be used during
  *		 bus initialization to assign it a specific dynamic address
  *		 before starting DAA (Dynamic Address Assignment)
+ * @static_addr_method: Bitmap describing which methods of Dynamic Address
+ *		 Assignment from a Static Address are supported by this I3C Target.
+ *		 A value of 1 in a bit position indicates that the Bus Controller
+ *		 supports that method, and a value of 0 indicates that the Bus
+ *		 Controller does not support that method.
+ *		 Bit 0: SETDASA
+ *		 Bit 1: SETAASA
+ *		 All other bits are reserved.
  * @pid: I3C Provisioned ID exposed by the device. This is a unique identifier
  *	 that may be used to attach boardinfo to i3c_dev_desc when the device
  *	 does not have a static address
@@ -189,6 +197,7 @@ struct i3c_dev_boardinfo {
 	struct list_head node;
 	u8 init_dyn_addr;
 	u8 static_addr;
+	u8 static_addr_method;
 	u64 pid;
 	struct fwnode_handle *fwnode;
 };
@@ -498,6 +507,8 @@ struct i3c_master_controller_ops {
 				  unsigned long dev_nack_retry_cnt);
 };
 
+#define I3C_ADDR_METHOD_SETDASA BIT(0)
+#define I3C_ADDR_METHOD_SETAASA BIT(1)
 /**
  * struct i3c_master_controller - I3C master controller object
  * @dev: device to be registered to the device-model
@@ -516,6 +527,11 @@ struct i3c_master_controller_ops {
  * @boardinfo.i2c: list of I2C boardinfo objects
  * @boardinfo: board-level information attached to devices connected on the bus
  * @bus: I3C bus exposed by this master
+ * @addr_method: Bitmap describing which methods of Address Assignment required
+ *		 to be run for discovering all the devices on the bus.
+ *		 Bit 0: SETDASA
+ *		 Bit 1: SETAASA
+ *		 All other bits are reserved.
  * @wq: workqueue which can be used by master
  *	drivers if they need to postpone operations that need to take place
  *	in a thread context. Typical examples are Hot Join processing which
@@ -543,6 +559,7 @@ struct i3c_master_controller {
 		struct list_head i2c;
 	} boardinfo;
 	struct i3c_bus bus;
+	u8 addr_method;
 	struct workqueue_struct *wq;
 	unsigned int dev_nack_retry_count;
 };
-- 
2.50.1

[PATCH 06/12] i3c: master: Add support for devices without PID

[Akhil R]

Devices using SETAASA for address assignment are not required to have
a 48-bit PID according to the I3C specification. Allow such devices to
register and use the static address where PID was required.

Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
 drivers/i3c/master.c | 51 ++++++++++++++++++++++++++++++++++----------
 1 file changed, 40 insertions(+), 11 deletions(-)

diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index 40a3bb734234..0cce75bb05b0 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -1835,8 +1835,17 @@ i3c_master_register_new_i3c_devs(struct i3c_master_controller *master)
 		desc->dev->dev.type = &i3c_device_type;
 		desc->dev->dev.bus = &i3c_bus_type;
 		desc->dev->dev.release = i3c_device_release;
-		dev_set_name(&desc->dev->dev, "%d-%llx", master->bus.id,
-			     desc->info.pid);
+
+		/*
+		 * For devices without PID (e.g., SETAASA devices), use
+		 * static address for naming instead.
+		 */
+		if (desc->info.pid)
+			dev_set_name(&desc->dev->dev, "%d-%llx", master->bus.id,
+				     desc->info.pid);
+		else
+			dev_set_name(&desc->dev->dev, "%d-static_addr-%02x", master->bus.id,
+				     desc->info.static_addr);
 
 		if (desc->boardinfo)
 			device_set_node(&desc->dev->dev, desc->boardinfo->fwnode);
@@ -2281,8 +2290,18 @@ static void i3c_master_attach_boardinfo(struct i3c_dev_desc *i3cdev)
 	struct i3c_dev_boardinfo *i3cboardinfo;
 
 	list_for_each_entry(i3cboardinfo, &master->boardinfo.i3c, node) {
-		if (i3cdev->info.pid != i3cboardinfo->pid)
-			continue;
+		/*
+		 * For devices without PID (e.g., SETAASA devices), match by
+		 * static address. For devices with PID, match by PID.
+		 */
+		if (i3cboardinfo->pid) {
+			if (i3cdev->info.pid != i3cboardinfo->pid)
+				continue;
+		} else {
+			if (!i3cboardinfo->static_addr ||
+			    i3cdev->info.static_addr != i3cboardinfo->static_addr)
+				continue;
+		}
 
 		i3cdev->boardinfo = i3cboardinfo;
 		i3cdev->info.static_addr = i3cboardinfo->static_addr;
@@ -2296,8 +2315,12 @@ i3c_master_search_i3c_dev_duplicate(struct i3c_dev_desc *refdev)
 	struct i3c_master_controller *master = i3c_dev_get_master(refdev);
 	struct i3c_dev_desc *i3cdev;
 
+	if (!refdev->info.pid)
+		return NULL;
+
 	i3c_bus_for_each_i3cdev(&master->bus, i3cdev) {
-		if (i3cdev != refdev && i3cdev->info.pid == refdev->info.pid)
+		if (i3cdev != refdev && i3cdev->info.pid &&
+		    i3cdev->info.pid == refdev->info.pid)
 			return i3cdev;
 	}
 
@@ -2582,9 +2605,15 @@ i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
 
 	boardinfo->pid = ((u64)reg[1] << 32) | reg[2];
 
-	if ((boardinfo->pid & GENMASK_ULL(63, 48)) ||
-	    I3C_PID_RND_LOWER_32BITS(boardinfo->pid))
-		return -EINVAL;
+	/* For SETAASA devices, validate the static address instead of PID */
+	if (boardinfo->static_addr_method & I3C_ADDR_METHOD_SETAASA) {
+		if (!boardinfo->static_addr)
+			return -EINVAL;
+	} else {
+		if ((boardinfo->pid & GENMASK_ULL(63, 48)) ||
+		    I3C_PID_RND_LOWER_32BITS(boardinfo->pid))
+			return -EINVAL;
+	}
 
 	boardinfo->init_dyn_addr = init_dyn_addr;
 	boardinfo->fwnode = fwnode_handle_get(fwnode);
@@ -2607,10 +2636,10 @@ static int i3c_master_add_of_dev(struct i3c_master_controller *master,
 		return ret;
 
 	/*
-	 * The manufacturer ID can't be 0. If reg[1] == 0 that means we're
-	 * dealing with an I2C device.
+	 * I3C device should have either the manufacturer ID specified or the
+	 * address discovery method specified. Else treat it as an I2C device.
 	 */
-	if (!reg[1])
+	if (!reg[1] && !fwnode_property_present(fwnode, "mipi-i3c-static-method"))
 		ret = i3c_master_add_i2c_boardinfo(master, fwnode, reg);
 	else
 		ret = i3c_master_add_i3c_boardinfo(master, fwnode, reg);
-- 
2.50.1

[PATCH 07/12] i3c: master: match I3C device through DT and ACPI

[Akhil R]

SETAASA-based devices cannot always be identified by PID or DCR; the
standard I3C id_table matching may not be applicable. Allow such devices
to be matched through Device Tree or ACPI

Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
 drivers/i3c/master.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index 0cce75bb05b0..ef96518558fb 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -16,6 +16,7 @@
 #include <linux/kernel.h>
 #include <linux/list.h>
 #include <linux/of.h>
+#include <linux/of_device.h>
 #include <linux/pm_runtime.h>
 #include <linux/property.h>
 #include <linux/slab.h>
@@ -342,15 +343,32 @@ static int i3c_device_match(struct device *dev, const struct device_driver *drv)
 {
 	struct i3c_device *i3cdev;
 	const struct i3c_driver *i3cdrv;
+	u8 static_addr_method = 0;
 
 	if (dev->type != &i3c_device_type)
 		return 0;
 
 	i3cdev = dev_to_i3cdev(dev);
 	i3cdrv = drv_to_i3cdrv(drv);
-	if (i3c_device_match_id(i3cdev, i3cdrv->id_table))
+
+	if (i3cdev->desc && i3cdev->desc->boardinfo)
+		static_addr_method = i3cdev->desc->boardinfo->static_addr_method;
+
+	/*
+	 * SETAASA based device need not always have a matching ID since
+	 * it is not mandatory for such devices to implement deviceinfo
+	 * CCC commands. Allow them to register through DT or ACPI.
+	 */
+	if (i3cdrv->id_table && i3c_device_match_id(i3cdev, i3cdrv->id_table))
 		return 1;
 
+	if (static_addr_method & I3C_ADDR_METHOD_SETAASA) {
+		if (of_driver_match_device(dev, drv))
+			return 1;
+		if (acpi_driver_match_device(dev, drv))
+			return 1;
+	}
+
 	return 0;
 }
 
-- 
2.50.1

[PATCH 08/12] i3c: dw-i3c-master: Add SETAASA as supported CCC

[Akhil R]

Add SETAASA and SETHID to the supported list of CCC commands for
DesignWare I3C host controller.

SETAASA is a broadcast command that assigns predefined static
addresses to all I3C devices on the bus. SETHID stops HID bit
flipping by the SPD Hub on which the SPD devices are connected.
It is a prerequisite command to be sent before SETAASA as recommended
by JESD300-5 and JESD403 sideband bus specifications.

Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
 drivers/i3c/master/dw-i3c-master.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/i3c/master/dw-i3c-master.c b/drivers/i3c/master/dw-i3c-master.c
index d6bdb32397fb..05ccdf177b6d 100644
--- a/drivers/i3c/master/dw-i3c-master.c
+++ b/drivers/i3c/master/dw-i3c-master.c
@@ -308,6 +308,8 @@ static bool dw_i3c_master_supports_ccc_cmd(struct i3c_master_controller *m,
 	case I3C_CCC_GETSTATUS:
 	case I3C_CCC_GETMXDS:
 	case I3C_CCC_GETHDRCAP:
+	case I3C_CCC_SETAASA:
+	case I3C_CCC_VENDOR(0, true): /* SETHID */
 		return true;
 	default:
 		return false;
-- 
2.50.1

[PATCH 09/12] i3c: dw-i3c-master: Add a quirk to skip clock and reset

[Akhil R]

Some ACPI-enumerated devices like Tegra410 do not have clock and reset
resources exposed via the clk/reset frameworks. Add a match data for
such devices to skip acquiring clock and reset controls during probe.

Move match data parsing before clock/reset acquisition so the quirk is
available early enough.  When the quirk is set, fall back to reading
the clock rate from the "clock-frequency" device property instead.

Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
 drivers/i3c/master/dw-i3c-master.c | 57 +++++++++++++++++++-----------
 1 file changed, 36 insertions(+), 21 deletions(-)

diff --git a/drivers/i3c/master/dw-i3c-master.c b/drivers/i3c/master/dw-i3c-master.c
index 05ccdf177b6d..2dae63983303 100644
--- a/drivers/i3c/master/dw-i3c-master.c
+++ b/drivers/i3c/master/dw-i3c-master.c
@@ -241,6 +241,7 @@
 /* List of quirks */
 #define AMD_I3C_OD_PP_TIMING		BIT(1)
 #define DW_I3C_DISABLE_RUNTIME_PM_QUIRK	BIT(2)
+#define DW_I3C_ACPI_SKIP_CLK_RST		BIT(3)
 
 struct dw_i3c_cmd {
 	u32 cmd_lo;
@@ -560,13 +561,26 @@ static void dw_i3c_master_set_intr_regs(struct dw_i3c_master *master)
 	writel(IBI_REQ_REJECT_ALL, master->regs + IBI_MR_REQ_REJECT);
 }
 
+static unsigned long dw_i3c_master_get_core_rate(struct dw_i3c_master *master)
+{
+	unsigned int core_rate_prop;
+
+	if (!(master->quirks & DW_I3C_ACPI_SKIP_CLK_RST))
+		return clk_get_rate(master->core_clk);
+
+	if (device_property_read_u32(master->dev, "clock-frequency", &core_rate_prop))
+		return 0;
+
+	return core_rate_prop;
+}
+
 static int dw_i3c_clk_cfg(struct dw_i3c_master *master)
 {
 	unsigned long core_rate, core_period;
 	u32 scl_timing;
 	u8 hcnt, lcnt;
 
-	core_rate = clk_get_rate(master->core_clk);
+	core_rate = dw_i3c_master_get_core_rate(master);
 	if (!core_rate)
 		return -EINVAL;
 
@@ -619,7 +633,7 @@ static int dw_i2c_clk_cfg(struct dw_i3c_master *master)
 	u16 hcnt, lcnt;
 	u32 scl_timing;
 
-	core_rate = clk_get_rate(master->core_clk);
+	core_rate = dw_i3c_master_get_core_rate(master);
 	if (!core_rate)
 		return -EINVAL;
 
@@ -1600,21 +1614,31 @@ int dw_i3c_common_probe(struct dw_i3c_master *master,
 	if (IS_ERR(master->regs))
 		return PTR_ERR(master->regs);
 
-	master->core_clk = devm_clk_get_enabled(&pdev->dev, NULL);
-	if (IS_ERR(master->core_clk))
-		return PTR_ERR(master->core_clk);
+	if (has_acpi_companion(&pdev->dev)) {
+		quirks = (unsigned long)device_get_match_data(&pdev->dev);
+	} else if (pdev->dev.of_node) {
+		drvdata = device_get_match_data(&pdev->dev);
+		if (drvdata)
+			quirks = drvdata->flags;
+	}
+	master->quirks = quirks;
+
+	if (!(master->quirks & DW_I3C_ACPI_SKIP_CLK_RST)) {
+		master->core_clk = devm_clk_get_enabled(&pdev->dev, NULL);
+		if (IS_ERR(master->core_clk))
+			return PTR_ERR(master->core_clk);
+
+		master->core_rst = devm_reset_control_get_optional_exclusive(&pdev->dev,
+									     "core_rst");
+		if (IS_ERR(master->core_rst))
+			return PTR_ERR(master->core_rst);
+		reset_control_deassert(master->core_rst);
+	}
 
 	master->pclk = devm_clk_get_optional_enabled(&pdev->dev, "pclk");
 	if (IS_ERR(master->pclk))
 		return PTR_ERR(master->pclk);
 
-	master->core_rst = devm_reset_control_get_optional_exclusive(&pdev->dev,
-								    "core_rst");
-	if (IS_ERR(master->core_rst))
-		return PTR_ERR(master->core_rst);
-
-	reset_control_deassert(master->core_rst);
-
 	spin_lock_init(&master->xferqueue.lock);
 	INIT_LIST_HEAD(&master->xferqueue.list);
 
@@ -1647,15 +1671,6 @@ int dw_i3c_common_probe(struct dw_i3c_master *master,
 	master->maxdevs = ret >> 16;
 	master->free_pos = GENMASK(master->maxdevs - 1, 0);
 
-	if (has_acpi_companion(&pdev->dev)) {
-		quirks = (unsigned long)device_get_match_data(&pdev->dev);
-	} else if (pdev->dev.of_node) {
-		drvdata = device_get_match_data(&pdev->dev);
-		if (drvdata)
-			quirks = drvdata->flags;
-	}
-	master->quirks = quirks;
-
 	/* Keep controller enabled by preventing runtime suspend */
 	if (master->quirks & DW_I3C_DISABLE_RUNTIME_PM_QUIRK)
 		pm_runtime_get_noresume(&pdev->dev);
-- 
2.50.1

[PATCH 10/12] i3c: dw-i3c-master: Add ACPI ID for Tegra410

[Akhil R]

Update variable names to generic names and add Tegra410 ACPI ID to
support the I3C controller in Tegra410 which is a DesignWare I3C host
controller.

Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
 drivers/i3c/master/dw-i3c-master.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/i3c/master/dw-i3c-master.c b/drivers/i3c/master/dw-i3c-master.c
index 2dae63983303..684499ad2047 100644
--- a/drivers/i3c/master/dw-i3c-master.c
+++ b/drivers/i3c/master/dw-i3c-master.c
@@ -1866,11 +1866,12 @@ static const struct of_device_id dw_i3c_master_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, dw_i3c_master_of_match);
 
-static const struct acpi_device_id amd_i3c_device_match[] = {
+static const struct acpi_device_id dw_i3c_master_acpi_match[] = {
 	{ "AMDI0015", AMD_I3C_OD_PP_TIMING },
+	{ "NVDA2018", DW_I3C_ACPI_SKIP_CLK_RST },
 	{ }
 };
-MODULE_DEVICE_TABLE(acpi, amd_i3c_device_match);
+MODULE_DEVICE_TABLE(acpi, dw_i3c_master_acpi_match);
 
 static struct platform_driver dw_i3c_driver = {
 	.probe = dw_i3c_probe,
@@ -1879,7 +1880,7 @@ static struct platform_driver dw_i3c_driver = {
 	.driver = {
 		.name = "dw-i3c-master",
 		.of_match_table = dw_i3c_master_of_match,
-		.acpi_match_table = amd_i3c_device_match,
+		.acpi_match_table = dw_i3c_master_acpi_match,
 		.pm = &dw_i3c_pm_ops,
 	},
 };
-- 
2.50.1

[PATCH 11/12] hwmon: spd5118: Add I3C support

[Akhil R]

Add a regmap config and a probe function to support for I3C based
communication to SPD5118 devices.

On an I3C bus, SPD5118 are enumerated via SETAASA and always require an
ACPI or device tree entry. The device matching is hence through the OF
match tables only and do not need an I3C class match table. The device
identity is verified in the type registers before proceeding to the
common probe function.

Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
 drivers/hwmon/Kconfig   |  7 +++--
 drivers/hwmon/spd5118.c | 66 ++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 70 insertions(+), 3 deletions(-)

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 8af80e17d25e..23604c05ad22 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -2300,10 +2300,13 @@ config SENSORS_SPD5118
 	tristate "SPD5118 Compliant Temperature Sensors"
 	depends on I2C
 	select REGMAP_I2C
+	select REGMAP_I3C if I3C
 	help
 	  If you say yes here you get support for SPD5118 (JEDEC JESD300)
-	  compliant temperature sensors. Such sensors are found on DDR5 memory
-	  modules.
+	  compliant temperature sensors using I2C or I3C bus interface.
+	  Such sensors are found on DDR5 memory modules.
+
+	  This driver supports both I2C and I3C interfaces.
 
 	  This driver can also be built as a module. If so, the module
 	  will be called spd5118.
diff --git a/drivers/hwmon/spd5118.c b/drivers/hwmon/spd5118.c
index 5da44571b6a0..d70123e10616 100644
--- a/drivers/hwmon/spd5118.c
+++ b/drivers/hwmon/spd5118.c
@@ -18,6 +18,7 @@
 #include <linux/bits.h>
 #include <linux/err.h>
 #include <linux/i2c.h>
+#include <linux/i3c/device.h>
 #include <linux/hwmon.h>
 #include <linux/module.h>
 #include <linux/mutex.h>
@@ -482,6 +483,25 @@ static const struct regmap_config spd5118_regmap16_config = {
 	.cache_type = REGCACHE_MAPLE,
 };
 
+/*
+ * I3C uses 2-byte register addressing -
+ *   Byte 1: MemReg | BlkAddr[0] | Address[5:0]
+ *   Byte 2: 0000   | BlkAddr[4:1]
+ *
+ * The low byte carries the register/NVM address and the high byte carries the
+ * upper block address bits, so little-endian format is required. No range
+ * config is needed since I3C does not use MR11 page switching.
+ */
+static const struct regmap_config spd5118_regmap_i3c_config = {
+	.reg_bits = 16,
+	.val_bits = 8,
+	.max_register = 0x7ff,
+	.reg_format_endian = REGMAP_ENDIAN_LITTLE,
+	.writeable_reg = spd5118_writeable_reg,
+	.volatile_reg = spd5118_volatile_reg,
+	.cache_type = REGCACHE_MAPLE,
+};
+
 static int spd5118_suspend(struct device *dev)
 {
 	struct spd5118_data *data = dev_get_drvdata(dev);
@@ -770,7 +790,51 @@ static struct i2c_driver spd5118_i2c_driver = {
 	.address_list	= IS_ENABLED(CONFIG_SENSORS_SPD5118_DETECT) ? normal_i2c : NULL,
 };
 
-module_i2c_driver(spd5118_i2c_driver);
+/* I3C */
+
+static int spd5118_i3c_probe(struct i3c_device *i3cdev)
+{
+	struct device *dev = i3cdev_to_dev(i3cdev);
+	struct regmap *regmap;
+	unsigned int regval;
+	int err;
+
+	regmap = devm_regmap_init_i3c(i3cdev, &spd5118_regmap_i3c_config);
+	if (IS_ERR(regmap))
+		return dev_err_probe(dev, PTR_ERR(regmap), "regmap init failed\n");
+
+	/* Verify this is a SPD5118 device */
+	err = regmap_read(regmap, SPD5118_REG_TYPE, &regval);
+	if (err)
+		return err;
+
+	if (regval != 0x51) {
+		dev_err(dev, "unexpected device type 0x%02x, expected 0x51\n", regval);
+		return -ENODEV;
+	}
+
+	err = regmap_read(regmap, SPD5118_REG_TYPE + 1, &regval);
+	if (err)
+		return err;
+
+	if (regval != 0x18) {
+		dev_err(dev, "unexpected device type 0x%02x, expected 0x18\n", regval);
+		return -ENODEV;
+	}
+
+	return spd5118_common_probe(dev, regmap, false);
+}
+
+static struct i3c_driver spd5118_i3c_driver = {
+	.driver = {
+		.name	= "spd5118_i3c",
+		.of_match_table = spd5118_of_ids,
+		.pm = pm_sleep_ptr(&spd5118_pm_ops),
+	},
+	.probe		= spd5118_i3c_probe,
+};
+
+module_i3c_i2c_driver(spd5118_i3c_driver, &spd5118_i2c_driver);
 
 MODULE_AUTHOR("René Rebe <rene@exactcode.de>");
 MODULE_AUTHOR("Guenter Roeck <linux@roeck-us.net>");
-- 
2.50.1

Re: [PATCH 11/12] hwmon: spd5118: Add I3C support

[Alexandre Belloni]

On 18/03/2026 22:57:24+0530, Akhil R wrote:
> Add a regmap config and a probe function to support for I3C based
> communication to SPD5118 devices.
> 
> On an I3C bus, SPD5118 are enumerated via SETAASA and always require an
> ACPI or device tree entry. The device matching is hence through the OF
> match tables only and do not need an I3C class match table. The device
> identity is verified in the type registers before proceeding to the
> common probe function.
> 
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> ---
>  drivers/hwmon/Kconfig   |  7 +++--
>  drivers/hwmon/spd5118.c | 66 ++++++++++++++++++++++++++++++++++++++++-
>  2 files changed, 70 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 8af80e17d25e..23604c05ad22 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -2300,10 +2300,13 @@ config SENSORS_SPD5118
>  	tristate "SPD5118 Compliant Temperature Sensors"
>  	depends on I2C

Please use I3C_OR_I2C here

>  	select REGMAP_I2C
> +	select REGMAP_I3C if I3C
>  	help
>  	  If you say yes here you get support for SPD5118 (JEDEC JESD300)
> -	  compliant temperature sensors. Such sensors are found on DDR5 memory
> -	  modules.
> +	  compliant temperature sensors using I2C or I3C bus interface.
> +	  Such sensors are found on DDR5 memory modules.
> +
> +	  This driver supports both I2C and I3C interfaces.
>  
>  	  This driver can also be built as a module. If so, the module
>  	  will be called spd5118.
> diff --git a/drivers/hwmon/spd5118.c b/drivers/hwmon/spd5118.c
> index 5da44571b6a0..d70123e10616 100644
> --- a/drivers/hwmon/spd5118.c
> +++ b/drivers/hwmon/spd5118.c
> @@ -18,6 +18,7 @@
>  #include <linux/bits.h>
>  #include <linux/err.h>
>  #include <linux/i2c.h>
> +#include <linux/i3c/device.h>
>  #include <linux/hwmon.h>
>  #include <linux/module.h>
>  #include <linux/mutex.h>
> @@ -482,6 +483,25 @@ static const struct regmap_config spd5118_regmap16_config = {
>  	.cache_type = REGCACHE_MAPLE,
>  };
>  
> +/*
> + * I3C uses 2-byte register addressing -
> + *   Byte 1: MemReg | BlkAddr[0] | Address[5:0]
> + *   Byte 2: 0000   | BlkAddr[4:1]
> + *
> + * The low byte carries the register/NVM address and the high byte carries the
> + * upper block address bits, so little-endian format is required. No range
> + * config is needed since I3C does not use MR11 page switching.
> + */
> +static const struct regmap_config spd5118_regmap_i3c_config = {
> +	.reg_bits = 16,
> +	.val_bits = 8,
> +	.max_register = 0x7ff,
> +	.reg_format_endian = REGMAP_ENDIAN_LITTLE,
> +	.writeable_reg = spd5118_writeable_reg,
> +	.volatile_reg = spd5118_volatile_reg,
> +	.cache_type = REGCACHE_MAPLE,
> +};
> +
>  static int spd5118_suspend(struct device *dev)
>  {
>  	struct spd5118_data *data = dev_get_drvdata(dev);
> @@ -770,7 +790,51 @@ static struct i2c_driver spd5118_i2c_driver = {
>  	.address_list	= IS_ENABLED(CONFIG_SENSORS_SPD5118_DETECT) ? normal_i2c : NULL,
>  };
>  
> -module_i2c_driver(spd5118_i2c_driver);
> +/* I3C */
> +
> +static int spd5118_i3c_probe(struct i3c_device *i3cdev)
> +{
> +	struct device *dev = i3cdev_to_dev(i3cdev);
> +	struct regmap *regmap;
> +	unsigned int regval;
> +	int err;
> +
> +	regmap = devm_regmap_init_i3c(i3cdev, &spd5118_regmap_i3c_config);
> +	if (IS_ERR(regmap))
> +		return dev_err_probe(dev, PTR_ERR(regmap), "regmap init failed\n");
> +
> +	/* Verify this is a SPD5118 device */
> +	err = regmap_read(regmap, SPD5118_REG_TYPE, &regval);
> +	if (err)
> +		return err;
> +
> +	if (regval != 0x51) {
> +		dev_err(dev, "unexpected device type 0x%02x, expected 0x51\n", regval);
> +		return -ENODEV;
> +	}
> +
> +	err = regmap_read(regmap, SPD5118_REG_TYPE + 1, &regval);
> +	if (err)
> +		return err;
> +
> +	if (regval != 0x18) {
> +		dev_err(dev, "unexpected device type 0x%02x, expected 0x18\n", regval);
> +		return -ENODEV;
> +	}
> +
> +	return spd5118_common_probe(dev, regmap, false);
> +}
> +
> +static struct i3c_driver spd5118_i3c_driver = {
> +	.driver = {
> +		.name	= "spd5118_i3c",
> +		.of_match_table = spd5118_of_ids,
> +		.pm = pm_sleep_ptr(&spd5118_pm_ops),
> +	},
> +	.probe		= spd5118_i3c_probe,
> +};
> +
> +module_i3c_i2c_driver(spd5118_i3c_driver, &spd5118_i2c_driver);
>  
>  MODULE_AUTHOR("René Rebe <rene@exactcode.de>");
>  MODULE_AUTHOR("Guenter Roeck <linux@roeck-us.net>");
> -- 
> 2.50.1
> 

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH 11/12] hwmon: spd5118: Add I3C support

[Guenter Roeck]

On 3/18/26 10:27, Akhil R wrote:
> Add a regmap config and a probe function to support for I3C based
> communication to SPD5118 devices.
> 
> On an I3C bus, SPD5118 are enumerated via SETAASA and always require an
> ACPI or device tree entry. The device matching is hence through the OF
> match tables only and do not need an I3C class match table. The device
> identity is verified in the type registers before proceeding to the
> common probe function.
> 
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> ---
>   drivers/hwmon/Kconfig   |  7 +++--
>   drivers/hwmon/spd5118.c | 66 ++++++++++++++++++++++++++++++++++++++++-
>   2 files changed, 70 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 8af80e17d25e..23604c05ad22 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -2300,10 +2300,13 @@ config SENSORS_SPD5118
>   	tristate "SPD5118 Compliant Temperature Sensors"
>   	depends on I2C
>   	select REGMAP_I2C

I also had
	depends on I3C || I3C=n
in my version at

https://patchwork.kernel.org/project/linux-hwmon/patch/20250419161356.2528986-6-linux@roeck-us.net/

which I guess matches the more recent "depends on I3C_OR_I2C".

> +	select REGMAP_I3C if I3C
>   	help
>   	  If you say yes here you get support for SPD5118 (JEDEC JESD300)
> -	  compliant temperature sensors. Such sensors are found on DDR5 memory
> -	  modules.
> +	  compliant temperature sensors using I2C or I3C bus interface.
> +	  Such sensors are found on DDR5 memory modules.
> +
> +	  This driver supports both I2C and I3C interfaces.
>   
>   	  This driver can also be built as a module. If so, the module
>   	  will be called spd5118.
> diff --git a/drivers/hwmon/spd5118.c b/drivers/hwmon/spd5118.c
> index 5da44571b6a0..d70123e10616 100644
> --- a/drivers/hwmon/spd5118.c
> +++ b/drivers/hwmon/spd5118.c
> @@ -18,6 +18,7 @@
>   #include <linux/bits.h>
>   #include <linux/err.h>
>   #include <linux/i2c.h>
> +#include <linux/i3c/device.h>
>   #include <linux/hwmon.h>
>   #include <linux/module.h>
>   #include <linux/mutex.h>
> @@ -482,6 +483,25 @@ static const struct regmap_config spd5118_regmap16_config = {
>   	.cache_type = REGCACHE_MAPLE,
>   };
>   
> +/*
> + * I3C uses 2-byte register addressing -
> + *   Byte 1: MemReg | BlkAddr[0] | Address[5:0]
> + *   Byte 2: 0000   | BlkAddr[4:1]
> + *
> + * The low byte carries the register/NVM address and the high byte carries the
> + * upper block address bits, so little-endian format is required. No range
> + * config is needed since I3C does not use MR11 page switching.
> + */
> +static const struct regmap_config spd5118_regmap_i3c_config = {
> +	.reg_bits = 16,
> +	.val_bits = 8,
> +	.max_register = 0x7ff,
> +	.reg_format_endian = REGMAP_ENDIAN_LITTLE,

Should this be added to spd5118_regmap16_config instead, or is there reason
to assume that I2C 16-bit addressing differs from I3C addressing ?

> +	.writeable_reg = spd5118_writeable_reg,
> +	.volatile_reg = spd5118_volatile_reg,
> +	.cache_type = REGCACHE_MAPLE,
> +};
> +
>   static int spd5118_suspend(struct device *dev)
>   {
>   	struct spd5118_data *data = dev_get_drvdata(dev);
> @@ -770,7 +790,51 @@ static struct i2c_driver spd5118_i2c_driver = {
>   	.address_list	= IS_ENABLED(CONFIG_SENSORS_SPD5118_DETECT) ? normal_i2c : NULL,
>   };
>   
> -module_i2c_driver(spd5118_i2c_driver);
> +/* I3C */
> +
> +static int spd5118_i3c_probe(struct i3c_device *i3cdev)
> +{
> +	struct device *dev = i3cdev_to_dev(i3cdev);
> +	struct regmap *regmap;
> +	unsigned int regval;
> +	int err;
> +
> +	regmap = devm_regmap_init_i3c(i3cdev, &spd5118_regmap_i3c_config);
> +	if (IS_ERR(regmap))
> +		return dev_err_probe(dev, PTR_ERR(regmap), "regmap init failed\n");
> +
> +	/* Verify this is a SPD5118 device */
> +	err = regmap_read(regmap, SPD5118_REG_TYPE, &regval);
> +	if (err)
> +		return err;
> +
> +	if (regval != 0x51) {
> +		dev_err(dev, "unexpected device type 0x%02x, expected 0x51\n", regval);
> +		return -ENODEV;
> +	}
> +
> +	err = regmap_read(regmap, SPD5118_REG_TYPE + 1, &regval);
> +	if (err)
> +		return err;
> +
> +	if (regval != 0x18) {
> +		dev_err(dev, "unexpected device type 0x%02x, expected 0x18\n", regval);
> +		return -ENODEV;
> +	}
> +

I don't think this should dump error messages. Also, it might be desirable
to use a single regmap operation to read both values.

> +	return spd5118_common_probe(dev, regmap, false);

Why is_16bit=false ?

Thanks,
Guenter

> +}
> +
> +static struct i3c_driver spd5118_i3c_driver = {
> +	.driver = {
> +		.name	= "spd5118_i3c",
> +		.of_match_table = spd5118_of_ids,
> +		.pm = pm_sleep_ptr(&spd5118_pm_ops),
> +	},
> +	.probe		= spd5118_i3c_probe,
> +};
> +
> +module_i3c_i2c_driver(spd5118_i3c_driver, &spd5118_i2c_driver);
>   
>   MODULE_AUTHOR("René Rebe <rene@exactcode.de>");
>   MODULE_AUTHOR("Guenter Roeck <linux@roeck-us.net>");

Re: [PATCH 11/12] hwmon: spd5118: Add I3C support

[Akhil R]

On Wed, 18 Mar 2026 11:53:49 -0700, Guenter Roeck wrote:
> On 3/18/26 10:27, Akhil R wrote:
>> Add a regmap config and a probe function to support for I3C based
>> communication to SPD5118 devices.
>> 
>> On an I3C bus, SPD5118 are enumerated via SETAASA and always require an
>> ACPI or device tree entry. The device matching is hence through the OF
>> match tables only and do not need an I3C class match table. The device
>> identity is verified in the type registers before proceeding to the
>> common probe function.
>> 
>> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
>> ---
>>   drivers/hwmon/Kconfig   |  7 +++--
>>   drivers/hwmon/spd5118.c | 66 ++++++++++++++++++++++++++++++++++++++++-
>>   2 files changed, 70 insertions(+), 3 deletions(-)
>> 
>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
>> index 8af80e17d25e..23604c05ad22 100644
>> --- a/drivers/hwmon/Kconfig
>> +++ b/drivers/hwmon/Kconfig
>> @@ -2300,10 +2300,13 @@ config SENSORS_SPD5118
>>   	tristate "SPD5118 Compliant Temperature Sensors"
>>   	depends on I2C
>>   	select REGMAP_I2C
> 
> I also had
> 	depends on I3C || I3C=n
> in my version at
> 
> https://patchwork.kernel.org/project/linux-hwmon/patch/20250419161356.2528986-6-linux@roeck-us.net/
> 
> which I guess matches the more recent "depends on I3C_OR_I2C".

Ack. Will update.

> 
>> +	select REGMAP_I3C if I3C
>>   	help
>>   	  If you say yes here you get support for SPD5118 (JEDEC JESD300)
>> -	  compliant temperature sensors. Such sensors are found on DDR5 memory
>> -	  modules.
>> +	  compliant temperature sensors using I2C or I3C bus interface.
>> +	  Such sensors are found on DDR5 memory modules.
>> +
>> +	  This driver supports both I2C and I3C interfaces.
>>   
>>   	  This driver can also be built as a module. If so, the module
>>   	  will be called spd5118.
>> diff --git a/drivers/hwmon/spd5118.c b/drivers/hwmon/spd5118.c
>> index 5da44571b6a0..d70123e10616 100644
>> --- a/drivers/hwmon/spd5118.c
>> +++ b/drivers/hwmon/spd5118.c
>> @@ -18,6 +18,7 @@
>>   #include <linux/bits.h>
>>   #include <linux/err.h>
>>   #include <linux/i2c.h>
>> +#include <linux/i3c/device.h>
>>   #include <linux/hwmon.h>
>>   #include <linux/module.h>
>>   #include <linux/mutex.h>
>> @@ -482,6 +483,25 @@ static const struct regmap_config spd5118_regmap16_config = {
>>   	.cache_type = REGCACHE_MAPLE,
>>   };
>>   
>> +/*
>> + * I3C uses 2-byte register addressing -
>> + *   Byte 1: MemReg | BlkAddr[0] | Address[5:0]
>> + *   Byte 2: 0000   | BlkAddr[4:1]
>> + *
>> + * The low byte carries the register/NVM address and the high byte carries the
>> + * upper block address bits, so little-endian format is required. No range
>> + * config is needed since I3C does not use MR11 page switching.
>> + */
>> +static const struct regmap_config spd5118_regmap_i3c_config = {
>> +	.reg_bits = 16,
>> +	.val_bits = 8,
>> +	.max_register = 0x7ff,
>> +	.reg_format_endian = REGMAP_ENDIAN_LITTLE,
> 
> Should this be added to spd5118_regmap16_config instead, or is there reason
> to assume that I2C 16-bit addressing differs from I3C addressing ?

I did not see any difference for I2C in the specification, but I assumed the
existing format would have been working and I thought not to change them.
Changing the I2C format would also require a change in the is_16bit nvmem_read
formula.

> 
>> +	.writeable_reg = spd5118_writeable_reg,
>> +	.volatile_reg = spd5118_volatile_reg,
>> +	.cache_type = REGCACHE_MAPLE,
>> +};
>> +
>>   static int spd5118_suspend(struct device *dev)
>>   {
>>   	struct spd5118_data *data = dev_get_drvdata(dev);
>> @@ -770,7 +790,51 @@ static struct i2c_driver spd5118_i2c_driver = {
>>   	.address_list	= IS_ENABLED(CONFIG_SENSORS_SPD5118_DETECT) ? normal_i2c : NULL,
>>   };
>>   
>> -module_i2c_driver(spd5118_i2c_driver);
>> +/* I3C */
>> +
>> +static int spd5118_i3c_probe(struct i3c_device *i3cdev)
>> +{
>> +	struct device *dev = i3cdev_to_dev(i3cdev);
>> +	struct regmap *regmap;
>> +	unsigned int regval;
>> +	int err;
>> +
>> +	regmap = devm_regmap_init_i3c(i3cdev, &spd5118_regmap_i3c_config);
>> +	if (IS_ERR(regmap))
>> +		return dev_err_probe(dev, PTR_ERR(regmap), "regmap init failed\n");
>> +
>> +	/* Verify this is a SPD5118 device */
>> +	err = regmap_read(regmap, SPD5118_REG_TYPE, &regval);
>> +	if (err)
>> +		return err;
>> +
>> +	if (regval != 0x51) {
>> +		dev_err(dev, "unexpected device type 0x%02x, expected 0x51\n", regval);
>> +		return -ENODEV;
>> +	}
>> +
>> +	err = regmap_read(regmap, SPD5118_REG_TYPE + 1, &regval);
>> +	if (err)
>> +		return err;
>> +
>> +	if (regval != 0x18) {
>> +		dev_err(dev, "unexpected device type 0x%02x, expected 0x18\n", regval);
>> +		return -ENODEV;
>> +	}
>> +
> 
> I don't think this should dump error messages. Also, it might be desirable
> to use a single regmap operation to read both values.

Ack. Will use regmap_bulk_read() and will remove the error dump.

> 
>> +	return spd5118_common_probe(dev, regmap, false);
> 
> Why is_16bit=false ?

We don't need the encoding formula for the nvmem address with I3C. Since it
uses little-endian, (page * 0x100 + SPD5118_EEPROM_BASE) translates to the
correct address. Or did I overlook something?

> 
>> +}
>> +
>> +static struct i3c_driver spd5118_i3c_driver = {
>> +	.driver = {
>> +		.name	= "spd5118_i3c",
>> +		.of_match_table = spd5118_of_ids,
>> +		.pm = pm_sleep_ptr(&spd5118_pm_ops),
>> +	},
>> +	.probe		= spd5118_i3c_probe,
>> +};
>> +
>> +module_i3c_i2c_driver(spd5118_i3c_driver, &spd5118_i2c_driver);
>>   
>>   MODULE_AUTHOR("René Rebe <rene@exactcode.de>");
>>   MODULE_AUTHOR("Guenter Roeck <linux@roeck-us.net>");

Best Regards,
Akhil

Re: [PATCH 11/12] hwmon: spd5118: Add I3C support

[Guenter Roeck]

On 3/18/26 21:35, Akhil R wrote:
> On Wed, 18 Mar 2026 11:53:49 -0700, Guenter Roeck wrote:
>> On 3/18/26 10:27, Akhil R wrote:
>>> Add a regmap config and a probe function to support for I3C based
>>> communication to SPD5118 devices.
>>>
>>> On an I3C bus, SPD5118 are enumerated via SETAASA and always require an
>>> ACPI or device tree entry. The device matching is hence through the OF
>>> match tables only and do not need an I3C class match table. The device
>>> identity is verified in the type registers before proceeding to the
>>> common probe function.
>>>
>>> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
>>> ---
>>>    drivers/hwmon/Kconfig   |  7 +++--
>>>    drivers/hwmon/spd5118.c | 66 ++++++++++++++++++++++++++++++++++++++++-
>>>    2 files changed, 70 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
>>> index 8af80e17d25e..23604c05ad22 100644
>>> --- a/drivers/hwmon/Kconfig
>>> +++ b/drivers/hwmon/Kconfig
>>> @@ -2300,10 +2300,13 @@ config SENSORS_SPD5118
>>>    	tristate "SPD5118 Compliant Temperature Sensors"
>>>    	depends on I2C
>>>    	select REGMAP_I2C
>>
>> I also had
>> 	depends on I3C || I3C=n
>> in my version at
>>
>> https://patchwork.kernel.org/project/linux-hwmon/patch/20250419161356.2528986-6-linux@roeck-us.net/
>>
>> which I guess matches the more recent "depends on I3C_OR_I2C".
> 
> Ack. Will update.
> 
>>
>>> +	select REGMAP_I3C if I3C
>>>    	help
>>>    	  If you say yes here you get support for SPD5118 (JEDEC JESD300)
>>> -	  compliant temperature sensors. Such sensors are found on DDR5 memory
>>> -	  modules.
>>> +	  compliant temperature sensors using I2C or I3C bus interface.
>>> +	  Such sensors are found on DDR5 memory modules.
>>> +
>>> +	  This driver supports both I2C and I3C interfaces.
>>>    
>>>    	  This driver can also be built as a module. If so, the module
>>>    	  will be called spd5118.
>>> diff --git a/drivers/hwmon/spd5118.c b/drivers/hwmon/spd5118.c
>>> index 5da44571b6a0..d70123e10616 100644
>>> --- a/drivers/hwmon/spd5118.c
>>> +++ b/drivers/hwmon/spd5118.c
>>> @@ -18,6 +18,7 @@
>>>    #include <linux/bits.h>
>>>    #include <linux/err.h>
>>>    #include <linux/i2c.h>
>>> +#include <linux/i3c/device.h>
>>>    #include <linux/hwmon.h>
>>>    #include <linux/module.h>
>>>    #include <linux/mutex.h>
>>> @@ -482,6 +483,25 @@ static const struct regmap_config spd5118_regmap16_config = {
>>>    	.cache_type = REGCACHE_MAPLE,
>>>    };
>>>    
>>> +/*
>>> + * I3C uses 2-byte register addressing -
>>> + *   Byte 1: MemReg | BlkAddr[0] | Address[5:0]
>>> + *   Byte 2: 0000   | BlkAddr[4:1]
>>> + *
>>> + * The low byte carries the register/NVM address and the high byte carries the
>>> + * upper block address bits, so little-endian format is required. No range
>>> + * config is needed since I3C does not use MR11 page switching.
>>> + */
>>> +static const struct regmap_config spd5118_regmap_i3c_config = {
>>> +	.reg_bits = 16,
>>> +	.val_bits = 8,
>>> +	.max_register = 0x7ff,
>>> +	.reg_format_endian = REGMAP_ENDIAN_LITTLE,
>>
>> Should this be added to spd5118_regmap16_config instead, or is there reason
>> to assume that I2C 16-bit addressing differs from I3C addressing ?
> 
> I did not see any difference for I2C in the specification, but I assumed the
> existing format would have been working and I thought not to change them.
> Changing the I2C format would also require a change in the is_16bit nvmem_read
> formula.
> 
>>
>>> +	.writeable_reg = spd5118_writeable_reg,
>>> +	.volatile_reg = spd5118_volatile_reg,
>>> +	.cache_type = REGCACHE_MAPLE,
>>> +};
>>> +
>>>    static int spd5118_suspend(struct device *dev)
>>>    {
>>>    	struct spd5118_data *data = dev_get_drvdata(dev);
>>> @@ -770,7 +790,51 @@ static struct i2c_driver spd5118_i2c_driver = {
>>>    	.address_list	= IS_ENABLED(CONFIG_SENSORS_SPD5118_DETECT) ? normal_i2c : NULL,
>>>    };
>>>    
>>> -module_i2c_driver(spd5118_i2c_driver);
>>> +/* I3C */
>>> +
>>> +static int spd5118_i3c_probe(struct i3c_device *i3cdev)
>>> +{
>>> +	struct device *dev = i3cdev_to_dev(i3cdev);
>>> +	struct regmap *regmap;
>>> +	unsigned int regval;
>>> +	int err;
>>> +
>>> +	regmap = devm_regmap_init_i3c(i3cdev, &spd5118_regmap_i3c_config);
>>> +	if (IS_ERR(regmap))
>>> +		return dev_err_probe(dev, PTR_ERR(regmap), "regmap init failed\n");
>>> +
>>> +	/* Verify this is a SPD5118 device */
>>> +	err = regmap_read(regmap, SPD5118_REG_TYPE, &regval);
>>> +	if (err)
>>> +		return err;
>>> +
>>> +	if (regval != 0x51) {
>>> +		dev_err(dev, "unexpected device type 0x%02x, expected 0x51\n", regval);
>>> +		return -ENODEV;
>>> +	}
>>> +
>>> +	err = regmap_read(regmap, SPD5118_REG_TYPE + 1, &regval);
>>> +	if (err)
>>> +		return err;
>>> +
>>> +	if (regval != 0x18) {
>>> +		dev_err(dev, "unexpected device type 0x%02x, expected 0x18\n", regval);
>>> +		return -ENODEV;
>>> +	}
>>> +
>>
>> I don't think this should dump error messages. Also, it might be desirable
>> to use a single regmap operation to read both values.
> 
> Ack. Will use regmap_bulk_read() and will remove the error dump.
> 
>>
>>> +	return spd5118_common_probe(dev, regmap, false);
>>
>> Why is_16bit=false ?
> 
> We don't need the encoding formula for the nvmem address with I3C. Since it
> uses little-endian, (page * 0x100 + SPD5118_EEPROM_BASE) translates to the
> correct address. Or did I overlook something?
> 

Testing of the 16-bit code was limited: I had to set the SPD on a system
manually to 16-bit mode to get it working, and that only worked until the system
was reset. Its whole point was to prepare for I3C mode. If that fails, the entire
16-bit code in the driver is potentially wrong and should be pulled out before
adding I3C code. It can be added back later if/when a system actually utilizing
it is found.

Thanks,
Guenter

>>
>>> +}
>>> +
>>> +static struct i3c_driver spd5118_i3c_driver = {
>>> +	.driver = {
>>> +		.name	= "spd5118_i3c",
>>> +		.of_match_table = spd5118_of_ids,
>>> +		.pm = pm_sleep_ptr(&spd5118_pm_ops),
>>> +	},
>>> +	.probe		= spd5118_i3c_probe,
>>> +};
>>> +
>>> +module_i3c_i2c_driver(spd5118_i3c_driver, &spd5118_i2c_driver);
>>>    
>>>    MODULE_AUTHOR("René Rebe <rene@exactcode.de>");
>>>    MODULE_AUTHOR("Guenter Roeck <linux@roeck-us.net>");
> 
> Best Regards,
> Akhil

Re: [PATCH 11/12] hwmon: spd5118: Add I3C support

[Akhil R]

On Thu, 19 Mar 2026 07:34:18 -0700, Guenter Roeck wrote:
> On 3/18/26 21:35, Akhil R wrote:
>> On Wed, 18 Mar 2026 11:53:49 -0700, Guenter Roeck wrote:
>>> On 3/18/26 10:27, Akhil R wrote:
>>>> Add a regmap config and a probe function to support for I3C based
>>>> communication to SPD5118 devices.
>>>>
>>>> On an I3C bus, SPD5118 are enumerated via SETAASA and always require an
>>>> ACPI or device tree entry. The device matching is hence through the OF
>>>> match tables only and do not need an I3C class match table. The device
>>>> identity is verified in the type registers before proceeding to the
>>>> common probe function.
>>>>
>>>> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
>>>> ---
>>>>    drivers/hwmon/Kconfig   |  7 +++--
>>>>    drivers/hwmon/spd5118.c | 66 ++++++++++++++++++++++++++++++++++++++++-
>>>>    2 files changed, 70 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
>>>> index 8af80e17d25e..23604c05ad22 100644
>>>> --- a/drivers/hwmon/Kconfig
>>>> +++ b/drivers/hwmon/Kconfig
>>>> @@ -2300,10 +2300,13 @@ config SENSORS_SPD5118
>>>>    	tristate "SPD5118 Compliant Temperature Sensors"
>>>>    	depends on I2C
>>>>    	select REGMAP_I2C
>>>
>>> I also had
>>> 	depends on I3C || I3C=n
>>> in my version at
>>>
>>> https://patchwork.kernel.org/project/linux-hwmon/patch/20250419161356.2528986-6-linux@roeck-us.net/
>>>
>>> which I guess matches the more recent "depends on I3C_OR_I2C".
>> 
>> Ack. Will update.
>> 
>>>
>>>> +	select REGMAP_I3C if I3C
>>>>    	help
>>>>    	  If you say yes here you get support for SPD5118 (JEDEC JESD300)
>>>> -	  compliant temperature sensors. Such sensors are found on DDR5 memory
>>>> -	  modules.
>>>> +	  compliant temperature sensors using I2C or I3C bus interface.
>>>> +	  Such sensors are found on DDR5 memory modules.
>>>> +
>>>> +	  This driver supports both I2C and I3C interfaces.
>>>>    
>>>>    	  This driver can also be built as a module. If so, the module
>>>>    	  will be called spd5118.
>>>> diff --git a/drivers/hwmon/spd5118.c b/drivers/hwmon/spd5118.c
>>>> index 5da44571b6a0..d70123e10616 100644
>>>> --- a/drivers/hwmon/spd5118.c
>>>> +++ b/drivers/hwmon/spd5118.c
>>>> @@ -18,6 +18,7 @@
>>>>    #include <linux/bits.h>
>>>>    #include <linux/err.h>
>>>>    #include <linux/i2c.h>
>>>> +#include <linux/i3c/device.h>
>>>>    #include <linux/hwmon.h>
>>>>    #include <linux/module.h>
>>>>    #include <linux/mutex.h>
>>>> @@ -482,6 +483,25 @@ static const struct regmap_config spd5118_regmap16_config = {
>>>>    	.cache_type = REGCACHE_MAPLE,
>>>>    };
>>>>    
>>>> +/*
>>>> + * I3C uses 2-byte register addressing -
>>>> + *   Byte 1: MemReg | BlkAddr[0] | Address[5:0]
>>>> + *   Byte 2: 0000   | BlkAddr[4:1]
>>>> + *
>>>> + * The low byte carries the register/NVM address and the high byte carries the
>>>> + * upper block address bits, so little-endian format is required. No range
>>>> + * config is needed since I3C does not use MR11 page switching.
>>>> + */
>>>> +static const struct regmap_config spd5118_regmap_i3c_config = {
>>>> +	.reg_bits = 16,
>>>> +	.val_bits = 8,
>>>> +	.max_register = 0x7ff,
>>>> +	.reg_format_endian = REGMAP_ENDIAN_LITTLE,
>>>
>>> Should this be added to spd5118_regmap16_config instead, or is there reason
>>> to assume that I2C 16-bit addressing differs from I3C addressing ?
>> 
>> I did not see any difference for I2C in the specification, but I assumed the
>> existing format would have been working and I thought not to change them.
>> Changing the I2C format would also require a change in the is_16bit nvmem_read
>> formula.
>> 
>>>
>>>> +	.writeable_reg = spd5118_writeable_reg,
>>>> +	.volatile_reg = spd5118_volatile_reg,
>>>> +	.cache_type = REGCACHE_MAPLE,
>>>> +};
>>>> +
>>>>    static int spd5118_suspend(struct device *dev)
>>>>    {
>>>>    	struct spd5118_data *data = dev_get_drvdata(dev);
>>>> @@ -770,7 +790,51 @@ static struct i2c_driver spd5118_i2c_driver = {
>>>>    	.address_list	= IS_ENABLED(CONFIG_SENSORS_SPD5118_DETECT) ? normal_i2c : NULL,
>>>>    };
>>>>    
>>>> -module_i2c_driver(spd5118_i2c_driver);
>>>> +/* I3C */
>>>> +
>>>> +static int spd5118_i3c_probe(struct i3c_device *i3cdev)
>>>> +{
>>>> +	struct device *dev = i3cdev_to_dev(i3cdev);
>>>> +	struct regmap *regmap;
>>>> +	unsigned int regval;
>>>> +	int err;
>>>> +
>>>> +	regmap = devm_regmap_init_i3c(i3cdev, &spd5118_regmap_i3c_config);
>>>> +	if (IS_ERR(regmap))
>>>> +		return dev_err_probe(dev, PTR_ERR(regmap), "regmap init failed\n");
>>>> +
>>>> +	/* Verify this is a SPD5118 device */
>>>> +	err = regmap_read(regmap, SPD5118_REG_TYPE, &regval);
>>>> +	if (err)
>>>> +		return err;
>>>> +
>>>> +	if (regval != 0x51) {
>>>> +		dev_err(dev, "unexpected device type 0x%02x, expected 0x51\n", regval);
>>>> +		return -ENODEV;
>>>> +	}
>>>> +
>>>> +	err = regmap_read(regmap, SPD5118_REG_TYPE + 1, &regval);
>>>> +	if (err)
>>>> +		return err;
>>>> +
>>>> +	if (regval != 0x18) {
>>>> +		dev_err(dev, "unexpected device type 0x%02x, expected 0x18\n", regval);
>>>> +		return -ENODEV;
>>>> +	}
>>>> +
>>>
>>> I don't think this should dump error messages. Also, it might be desirable
>>> to use a single regmap operation to read both values.
>> 
>> Ack. Will use regmap_bulk_read() and will remove the error dump.
>> 
>>>
>>>> +	return spd5118_common_probe(dev, regmap, false);
>>>
>>> Why is_16bit=false ?
>> 
>> We don't need the encoding formula for the nvmem address with I3C. Since it
>> uses little-endian, (page * 0x100 + SPD5118_EEPROM_BASE) translates to the
>> correct address. Or did I overlook something?
>> 
> 
> Testing of the 16-bit code was limited: I had to set the SPD on a system
> manually to 16-bit mode to get it working, and that only worked until the system
> was reset. Its whole point was to prepare for I3C mode. If that fails, the entire
> 16-bit code in the driver is potentially wrong and should be pulled out before
> adding I3C code. It can be added back later if/when a system actually utilizing
> it is found.

Thanks for letting me know. I will add a patch to remove the I2C 16-bit sections in
the next revision as a prerequistie to this patch. Hope that sounds good.

Best Regards,
Akhil

Re: [PATCH 11/12] hwmon: spd5118: Add I3C support

[Guenter Roeck]

On 3/19/26 10:55, Akhil R wrote:
> On Thu, 19 Mar 2026 07:34:18 -0700, Guenter Roeck wrote:
>> On 3/18/26 21:35, Akhil R wrote:
>>> On Wed, 18 Mar 2026 11:53:49 -0700, Guenter Roeck wrote:
>>>> On 3/18/26 10:27, Akhil R wrote:
>>>>> Add a regmap config and a probe function to support for I3C based
>>>>> communication to SPD5118 devices.
>>>>>
>>>>> On an I3C bus, SPD5118 are enumerated via SETAASA and always require an
>>>>> ACPI or device tree entry. The device matching is hence through the OF
>>>>> match tables only and do not need an I3C class match table. The device
>>>>> identity is verified in the type registers before proceeding to the
>>>>> common probe function.
>>>>>
>>>>> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
>>>>> ---
>>>>>     drivers/hwmon/Kconfig   |  7 +++--
>>>>>     drivers/hwmon/spd5118.c | 66 ++++++++++++++++++++++++++++++++++++++++-
>>>>>     2 files changed, 70 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
>>>>> index 8af80e17d25e..23604c05ad22 100644
>>>>> --- a/drivers/hwmon/Kconfig
>>>>> +++ b/drivers/hwmon/Kconfig
>>>>> @@ -2300,10 +2300,13 @@ config SENSORS_SPD5118
>>>>>     	tristate "SPD5118 Compliant Temperature Sensors"
>>>>>     	depends on I2C
>>>>>     	select REGMAP_I2C
>>>>
>>>> I also had
>>>> 	depends on I3C || I3C=n
>>>> in my version at
>>>>
>>>> https://patchwork.kernel.org/project/linux-hwmon/patch/20250419161356.2528986-6-linux@roeck-us.net/
>>>>
>>>> which I guess matches the more recent "depends on I3C_OR_I2C".
>>>
>>> Ack. Will update.
>>>
>>>>
>>>>> +	select REGMAP_I3C if I3C
>>>>>     	help
>>>>>     	  If you say yes here you get support for SPD5118 (JEDEC JESD300)
>>>>> -	  compliant temperature sensors. Such sensors are found on DDR5 memory
>>>>> -	  modules.
>>>>> +	  compliant temperature sensors using I2C or I3C bus interface.
>>>>> +	  Such sensors are found on DDR5 memory modules.
>>>>> +
>>>>> +	  This driver supports both I2C and I3C interfaces.
>>>>>     
>>>>>     	  This driver can also be built as a module. If so, the module
>>>>>     	  will be called spd5118.
>>>>> diff --git a/drivers/hwmon/spd5118.c b/drivers/hwmon/spd5118.c
>>>>> index 5da44571b6a0..d70123e10616 100644
>>>>> --- a/drivers/hwmon/spd5118.c
>>>>> +++ b/drivers/hwmon/spd5118.c
>>>>> @@ -18,6 +18,7 @@
>>>>>     #include <linux/bits.h>
>>>>>     #include <linux/err.h>
>>>>>     #include <linux/i2c.h>
>>>>> +#include <linux/i3c/device.h>
>>>>>     #include <linux/hwmon.h>
>>>>>     #include <linux/module.h>
>>>>>     #include <linux/mutex.h>
>>>>> @@ -482,6 +483,25 @@ static const struct regmap_config spd5118_regmap16_config = {
>>>>>     	.cache_type = REGCACHE_MAPLE,
>>>>>     };
>>>>>     
>>>>> +/*
>>>>> + * I3C uses 2-byte register addressing -
>>>>> + *   Byte 1: MemReg | BlkAddr[0] | Address[5:0]
>>>>> + *   Byte 2: 0000   | BlkAddr[4:1]
>>>>> + *
>>>>> + * The low byte carries the register/NVM address and the high byte carries the
>>>>> + * upper block address bits, so little-endian format is required. No range
>>>>> + * config is needed since I3C does not use MR11 page switching.
>>>>> + */
>>>>> +static const struct regmap_config spd5118_regmap_i3c_config = {
>>>>> +	.reg_bits = 16,
>>>>> +	.val_bits = 8,
>>>>> +	.max_register = 0x7ff,
>>>>> +	.reg_format_endian = REGMAP_ENDIAN_LITTLE,
>>>>
>>>> Should this be added to spd5118_regmap16_config instead, or is there reason
>>>> to assume that I2C 16-bit addressing differs from I3C addressing ?
>>>
>>> I did not see any difference for I2C in the specification, but I assumed the
>>> existing format would have been working and I thought not to change them.
>>> Changing the I2C format would also require a change in the is_16bit nvmem_read
>>> formula.
>>>
>>>>
>>>>> +	.writeable_reg = spd5118_writeable_reg,
>>>>> +	.volatile_reg = spd5118_volatile_reg,
>>>>> +	.cache_type = REGCACHE_MAPLE,
>>>>> +};
>>>>> +
>>>>>     static int spd5118_suspend(struct device *dev)
>>>>>     {
>>>>>     	struct spd5118_data *data = dev_get_drvdata(dev);
>>>>> @@ -770,7 +790,51 @@ static struct i2c_driver spd5118_i2c_driver = {
>>>>>     	.address_list	= IS_ENABLED(CONFIG_SENSORS_SPD5118_DETECT) ? normal_i2c : NULL,
>>>>>     };
>>>>>     
>>>>> -module_i2c_driver(spd5118_i2c_driver);
>>>>> +/* I3C */
>>>>> +
>>>>> +static int spd5118_i3c_probe(struct i3c_device *i3cdev)
>>>>> +{
>>>>> +	struct device *dev = i3cdev_to_dev(i3cdev);
>>>>> +	struct regmap *regmap;
>>>>> +	unsigned int regval;
>>>>> +	int err;
>>>>> +
>>>>> +	regmap = devm_regmap_init_i3c(i3cdev, &spd5118_regmap_i3c_config);
>>>>> +	if (IS_ERR(regmap))
>>>>> +		return dev_err_probe(dev, PTR_ERR(regmap), "regmap init failed\n");
>>>>> +
>>>>> +	/* Verify this is a SPD5118 device */
>>>>> +	err = regmap_read(regmap, SPD5118_REG_TYPE, &regval);
>>>>> +	if (err)
>>>>> +		return err;
>>>>> +
>>>>> +	if (regval != 0x51) {
>>>>> +		dev_err(dev, "unexpected device type 0x%02x, expected 0x51\n", regval);
>>>>> +		return -ENODEV;
>>>>> +	}
>>>>> +
>>>>> +	err = regmap_read(regmap, SPD5118_REG_TYPE + 1, &regval);
>>>>> +	if (err)
>>>>> +		return err;
>>>>> +
>>>>> +	if (regval != 0x18) {
>>>>> +		dev_err(dev, "unexpected device type 0x%02x, expected 0x18\n", regval);
>>>>> +		return -ENODEV;
>>>>> +	}
>>>>> +
>>>>
>>>> I don't think this should dump error messages. Also, it might be desirable
>>>> to use a single regmap operation to read both values.
>>>
>>> Ack. Will use regmap_bulk_read() and will remove the error dump.
>>>
>>>>
>>>>> +	return spd5118_common_probe(dev, regmap, false);
>>>>
>>>> Why is_16bit=false ?
>>>
>>> We don't need the encoding formula for the nvmem address with I3C. Since it
>>> uses little-endian, (page * 0x100 + SPD5118_EEPROM_BASE) translates to the
>>> correct address. Or did I overlook something?
>>>
>>
>> Testing of the 16-bit code was limited: I had to set the SPD on a system
>> manually to 16-bit mode to get it working, and that only worked until the system
>> was reset. Its whole point was to prepare for I3C mode. If that fails, the entire
>> 16-bit code in the driver is potentially wrong and should be pulled out before
>> adding I3C code. It can be added back later if/when a system actually utilizing
>> it is found.
> 
> Thanks for letting me know. I will add a patch to remove the I2C 16-bit sections in
> the next revision as a prerequistie to this patch. Hope that sounds good.
> 

Please do.

Thanks,
Guenter


> Best Regards,
> Akhil

[PATCH 12/12] arm64: defconfig: Enable I3C and SPD5118 hwmon

[Akhil R]

Add I3C subsystem support, DesignWare I3C master controller, and
SPD5118 hwmon sensor as modules to the defconfig.

Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
 arch/arm64/configs/defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 18881bd239f9..5dde063822cb 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -582,6 +582,8 @@ CONFIG_I2C_UNIPHIER_F=y
 CONFIG_I2C_XILINX=m
 CONFIG_I2C_RCAR=y
 CONFIG_I2C_CROS_EC_TUNNEL=y
+CONFIG_I3C=m
+CONFIG_DW_I3C_MASTER=m
 CONFIG_SPI=y
 CONFIG_SPI_APPLE=m
 CONFIG_SPI_ARMADA_3700=y
@@ -761,6 +763,7 @@ CONFIG_SENSORS_SL28CPLD=m
 CONFIG_SENSORS_AMC6821=m
 CONFIG_SENSORS_INA2XX=m
 CONFIG_SENSORS_INA3221=m
+CONFIG_SENSORS_SPD5118=m
 CONFIG_SENSORS_TMP102=m
 CONFIG_MISC_RP1=m
 CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y
-- 
2.50.1

Re: [PATCH 12/12] arm64: defconfig: Enable I3C and SPD5118 hwmon

[Krzysztof Kozlowski]

On Wed, Mar 18, 2026 at 10:57:25PM +0530, Akhil R wrote:
> Add I3C subsystem support, DesignWare I3C master controller, and
> SPD5118 hwmon sensor as modules to the defconfig.

Why? If there is no user of that, why would we want it? Your commit msg
should explain that.

Best regards,
Krzysztof

Re: [PATCH 12/12] arm64: defconfig: Enable I3C and SPD5118 hwmon

[Akhil R]

On Thu, 19 Mar 2026 10:40:34 +0100, Krzysztof Kozlowski wrote:
> On Wed, Mar 18, 2026 at 10:57:25PM +0530, Akhil R wrote:
>> Add I3C subsystem support, DesignWare I3C master controller, and
>> SPD5118 hwmon sensor as modules to the defconfig.
> 
> Why? If there is no user of that, why would we want it? Your commit msg
> should explain that.

Ack. This is for Tegra410 which has a DesignWare I3C host controller.
I will add this in the commit message.

Best Regards,
Akhil

Re: [PATCH 12/12] arm64: defconfig: Enable I3C and SPD5118 hwmon

[Krzysztof Kozlowski]

On 19/03/2026 18:09, Akhil R wrote:
> On Thu, 19 Mar 2026 10:40:34 +0100, Krzysztof Kozlowski wrote:
>> On Wed, Mar 18, 2026 at 10:57:25PM +0530, Akhil R wrote:
>>> Add I3C subsystem support, DesignWare I3C master controller, and
>>> SPD5118 hwmon sensor as modules to the defconfig.
>>
>> Why? If there is no user of that, why would we want it? Your commit msg
>> should explain that.
> 
> Ack. This is for Tegra410 which has a DesignWare I3C host controller.
> I will add this in the commit message.

Board or products. Not SoCs.

Best regards,
Krzysztof

Re: [PATCH 12/12] arm64: defconfig: Enable I3C and SPD5118 hwmon

[Akhil R]

On Thu, 19 Mar 2026 18:15:14 +0100 Krzysztof Kozlowski wrote:
> On 19/03/2026 18:09, Akhil R wrote:
>> On Thu, 19 Mar 2026 10:40:34 +0100, Krzysztof Kozlowski wrote:
>>> On Wed, Mar 18, 2026 at 10:57:25PM +0530, Akhil R wrote:
>>>> Add I3C subsystem support, DesignWare I3C master controller, and
>>>> SPD5118 hwmon sensor as modules to the defconfig.
>>>
>>> Why? If there is no user of that, why would we want it? Your commit msg
>>> should explain that.
>> 
>> Ack. This is for Tegra410 which has a DesignWare I3C host controller.
>> I will add this in the commit message.
> 
> Board or products. Not SoCs.

Makes sense. I will have to get that information. Will update.

Regards,
Akhil

Re: [PATCH 12/12] arm64: defconfig: Enable I3C and SPD5118 hwmon

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]

On Thu, Mar 19, 2026 at 06:15:14PM +0100, Krzysztof Kozlowski wrote:
> On 19/03/2026 18:09, Akhil R wrote:
> > On Thu, 19 Mar 2026 10:40:34 +0100, Krzysztof Kozlowski wrote:
> >> On Wed, Mar 18, 2026 at 10:57:25PM +0530, Akhil R wrote:
> >>> Add I3C subsystem support, DesignWare I3C master controller, and
> >>> SPD5118 hwmon sensor as modules to the defconfig.
> >>
> >> Why? If there is no user of that, why would we want it? Your commit msg
> >> should explain that.
> > 
> > Ack. This is for Tegra410 which has a DesignWare I3C host controller.
> > I will add this in the commit message.
> 
> Board or products. Not SoCs.

Is this a new requirement? I see a bit of both in defconfig changes.
Some mention specific products, other mention SoCs. Does this
requirement apply to DT platforms or also ACPI platforms?

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 12/12] arm64: defconfig: Enable I3C and SPD5118 hwmon

[Krzysztof Kozlowski]

On 25/03/2026 11:31, Thierry Reding wrote:
> On Thu, Mar 19, 2026 at 06:15:14PM +0100, Krzysztof Kozlowski wrote:
>> On 19/03/2026 18:09, Akhil R wrote:
>>> On Thu, 19 Mar 2026 10:40:34 +0100, Krzysztof Kozlowski wrote:
>>>> On Wed, Mar 18, 2026 at 10:57:25PM +0530, Akhil R wrote:
>>>>> Add I3C subsystem support, DesignWare I3C master controller, and
>>>>> SPD5118 hwmon sensor as modules to the defconfig.
>>>>
>>>> Why? If there is no user of that, why would we want it? Your commit msg
>>>> should explain that.
>>>
>>> Ack. This is for Tegra410 which has a DesignWare I3C host controller.
>>> I will add this in the commit message.
>>
>> Board or products. Not SoCs.
> 
> Is this a new requirement? I see a bit of both in defconfig changes.

Almost every review from me has it for 2-3 years... And it is a known
thing since always in a bit different wording: we do not care about
downstream things and downstream products. defconfig does not serve
downstream at all, makes no sense outside of our (upstream) work.

> Some mention specific products, other mention SoCs. Does this
> requirement apply to DT platforms or also ACPI platforms?

Just like kernel, applies to all platforms, regardless of firmware
interface.

Best regards,
Krzysztof

Re: [PATCH 12/12] arm64: defconfig: Enable I3C and SPD5118 hwmon

[Krzysztof Kozlowski]

On 25/03/2026 11:59, Krzysztof Kozlowski wrote:
> On 25/03/2026 11:31, Thierry Reding wrote:
>> On Thu, Mar 19, 2026 at 06:15:14PM +0100, Krzysztof Kozlowski wrote:
>>> On 19/03/2026 18:09, Akhil R wrote:
>>>> On Thu, 19 Mar 2026 10:40:34 +0100, Krzysztof Kozlowski wrote:
>>>>> On Wed, Mar 18, 2026 at 10:57:25PM +0530, Akhil R wrote:
>>>>>> Add I3C subsystem support, DesignWare I3C master controller, and
>>>>>> SPD5118 hwmon sensor as modules to the defconfig.
>>>>>
>>>>> Why? If there is no user of that, why would we want it? Your commit msg
>>>>> should explain that.
>>>>
>>>> Ack. This is for Tegra410 which has a DesignWare I3C host controller.
>>>> I will add this in the commit message.
>>>
>>> Board or products. Not SoCs.
>>
>> Is this a new requirement? I see a bit of both in defconfig changes.
> 
> Almost every review from me has it for 2-3 years... And it is a known

And I already explained this to *you* 3 years ago:

https://lore.kernel.org/all/ac8f30a7-fc72-9a44-74b3-a69001bfdaaf@linaro.org/

So how this could be a new requirement *now* if three years ago we had
exactly same discussion.

I understand question for the first time, but why this being brought up
as "why is this a new thing" again?

Best regards,
Krzysztof

Re: [PATCH 12/12] arm64: defconfig: Enable I3C and SPD5118 hwmon

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2910 bytes --]

On Wed, Mar 25, 2026 at 12:03:37PM +0100, Krzysztof Kozlowski wrote:
> On 25/03/2026 11:59, Krzysztof Kozlowski wrote:
> > On 25/03/2026 11:31, Thierry Reding wrote:
> >> On Thu, Mar 19, 2026 at 06:15:14PM +0100, Krzysztof Kozlowski wrote:
> >>> On 19/03/2026 18:09, Akhil R wrote:
> >>>> On Thu, 19 Mar 2026 10:40:34 +0100, Krzysztof Kozlowski wrote:
> >>>>> On Wed, Mar 18, 2026 at 10:57:25PM +0530, Akhil R wrote:
> >>>>>> Add I3C subsystem support, DesignWare I3C master controller, and
> >>>>>> SPD5118 hwmon sensor as modules to the defconfig.
> >>>>>
> >>>>> Why? If there is no user of that, why would we want it? Your commit msg
> >>>>> should explain that.
> >>>>
> >>>> Ack. This is for Tegra410 which has a DesignWare I3C host controller.
> >>>> I will add this in the commit message.
> >>>
> >>> Board or products. Not SoCs.
> >>
> >> Is this a new requirement? I see a bit of both in defconfig changes.
> > 
> > Almost every review from me has it for 2-3 years... And it is a known
> 
> And I already explained this to *you* 3 years ago:
> 
> https://lore.kernel.org/all/ac8f30a7-fc72-9a44-74b3-a69001bfdaaf@linaro.org/
> 
> So how this could be a new requirement *now* if three years ago we had
> exactly same discussion.
> 
> I understand question for the first time, but why this being brought up
> as "why is this a new thing" again?

I have to admit I did not remember what we discussed, so I had to go
read that exchange again. It sounds to me like we were not discussing
the specific issue of a missing description as to which particular
product needed this, but you were instead rejecting the idea of
enabling drivers that were not strictly necessary like those for PCI
devices because they were making your life more difficult by building
drivers by default that you were not interested in.

Here you're arguing that you want proof that this is going to be used
by some upstream-supported device, which are two different things,
because they might very well be drivers that you're not interested in
but end up building if documented properly.

So I find it a little hard to keep track of what is acceptable to you
and what isn't. Are you objecting to this on the grounds of it bloating
the kernel build or because you want documentation for what platforms a
driver is being used on?

Our action items will be different depending on what your answer is: if
you want documentation about what device this will be used for, we'll
get you that information. If your concern is that it bloats the build we
drop the patch and will have to ask users to build their own
configurations.

Maybe to avoid these kinds of discussions in the past you can write down
your rules about what should go into defconfig and what should not. And
maybe we can eventually find consensus and find something that people
can use as a reference.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 12/12] arm64: defconfig: Enable I3C and SPD5118 hwmon

[Krzysztof Kozlowski]

On 25/03/2026 13:58, Thierry Reding wrote:
> On Wed, Mar 25, 2026 at 12:03:37PM +0100, Krzysztof Kozlowski wrote:
>> On 25/03/2026 11:59, Krzysztof Kozlowski wrote:
>>> On 25/03/2026 11:31, Thierry Reding wrote:
>>>> On Thu, Mar 19, 2026 at 06:15:14PM +0100, Krzysztof Kozlowski wrote:
>>>>> On 19/03/2026 18:09, Akhil R wrote:
>>>>>> On Thu, 19 Mar 2026 10:40:34 +0100, Krzysztof Kozlowski wrote:
>>>>>>> On Wed, Mar 18, 2026 at 10:57:25PM +0530, Akhil R wrote:
>>>>>>>> Add I3C subsystem support, DesignWare I3C master controller, and
>>>>>>>> SPD5118 hwmon sensor as modules to the defconfig.
>>>>>>>
>>>>>>> Why? If there is no user of that, why would we want it? Your commit msg
>>>>>>> should explain that.
>>>>>>
>>>>>> Ack. This is for Tegra410 which has a DesignWare I3C host controller.
>>>>>> I will add this in the commit message.
>>>>>
>>>>> Board or products. Not SoCs.
>>>>
>>>> Is this a new requirement? I see a bit of both in defconfig changes.
>>>
>>> Almost every review from me has it for 2-3 years... And it is a known
>>
>> And I already explained this to *you* 3 years ago:
>>
>> https://lore.kernel.org/all/ac8f30a7-fc72-9a44-74b3-a69001bfdaaf@linaro.org/
>>
>> So how this could be a new requirement *now* if three years ago we had
>> exactly same discussion.
>>
>> I understand question for the first time, but why this being brought up
>> as "why is this a new thing" again?
> 
> I have to admit I did not remember what we discussed, so I had to go
> read that exchange again. It sounds to me like we were not discussing
> the specific issue of a missing description as to which particular
> product needed this, but you were instead rejecting the idea of
> enabling drivers that were not strictly necessary like those for PCI
> devices because they were making your life more difficult by building
> drivers by default that you were not interested in.
> 
> Here you're arguing that you want proof that this is going to be used
> by some upstream-supported device, which are two different things,
> because they might very well be drivers that you're not interested in
> but end up building if documented properly.
> 
> So I find it a little hard to keep track of what is acceptable to you
> and what isn't. Are you objecting to this on the grounds of it bloating
> the kernel build or because you want documentation for what platforms a
> driver is being used on?
> 
> Our action items will be different depending on what your answer is: if
> you want documentation about what device this will be used for, we'll
> get you that information. If your concern is that it bloats the build we
> drop the patch and will have to ask users to build their own
> configurations.
> 
> Maybe to avoid these kinds of discussions in the past you can write down
> your rules about what should go into defconfig and what should not. And
> maybe we can eventually find consensus and find something that people
> can use as a reference.

I think answer is pretty simple and comes from the reason WHAT is the
purpose of defconfig. It's purpose is only for us.

Therefore defconfig can have anything anyone will find useful, when
building and running vanilla upstream kernel on their devices, with
exception of explicit needs for pluggable devices because then it bloats
the kernel to impossible stage (otherwise look for me sending all USB,
PCI, MEDIA, whatever devices for defconfig...).

For example:
1. Something used only by a DT board not enabled upstream: no, because
you cannot run upstream kernel on it,
2. Something used only by a ACPI platform, which require some out of
tree patches to build: no, because you cannot run upstream kernel on it
3. Something not being part of the device but pluggable: depends,
explain why upstream contributors would want it.

Look at the commit here:

"Add I3C subsystem support, DesignWare I3C master controller, and
SPD5118 hwmon sensor as modules to the defconfig."

Does it say why doing it? No.

Nowhere in this posting I was objecting to actual change. At least not
yet. I only ask WHY you are doing it.

Why is it so hard for a contributor to know and express why they are
doing something? If one does not know WHY they are doing it, then why
the heck they are doing it?

Best regards,
Krzysztof

Re: [PATCH 12/12] arm64: defconfig: Enable I3C and SPD5118 hwmon

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1995 bytes --]

On Wed, Mar 25, 2026 at 11:59:36AM +0100, Krzysztof Kozlowski wrote:
> On 25/03/2026 11:31, Thierry Reding wrote:
> > On Thu, Mar 19, 2026 at 06:15:14PM +0100, Krzysztof Kozlowski wrote:
> >> On 19/03/2026 18:09, Akhil R wrote:
> >>> On Thu, 19 Mar 2026 10:40:34 +0100, Krzysztof Kozlowski wrote:
> >>>> On Wed, Mar 18, 2026 at 10:57:25PM +0530, Akhil R wrote:
> >>>>> Add I3C subsystem support, DesignWare I3C master controller, and
> >>>>> SPD5118 hwmon sensor as modules to the defconfig.
> >>>>
> >>>> Why? If there is no user of that, why would we want it? Your commit msg
> >>>> should explain that.
> >>>
> >>> Ack. This is for Tegra410 which has a DesignWare I3C host controller.
> >>> I will add this in the commit message.
> >>
> >> Board or products. Not SoCs.
> > 
> > Is this a new requirement? I see a bit of both in defconfig changes.
> 
> Almost every review from me has it for 2-3 years... And it is a known
> thing since always in a bit different wording: we do not care about
> downstream things and downstream products. defconfig does not serve
> downstream at all, makes no sense outside of our (upstream) work.

I don't understand why you're turning this into a downstream vs.
upstream discussion. This is all code that is being submitted upstream,
because we want these new platforms with I3C support enabled upstream.
It's as simple as that.

> > Some mention specific products, other mention SoCs. Does this
> > requirement apply to DT platforms or also ACPI platforms?
> 
> Just like kernel, applies to all platforms, regardless of firmware
> interface.

Hm... again, I don't think there's every been a rule to the effect of
needing to specify a particular platform or product when adding a new
defconfig change. There's plenty of things that we're enabling in the
defconfigs because we think they are generally useful.

But alright, we'll either add more details to the commit message, or
drop this patch entirely.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 12/12] arm64: defconfig: Enable I3C and SPD5118 hwmon

[Krzysztof Kozlowski]

On 25/03/2026 13:41, Thierry Reding wrote:
> On Wed, Mar 25, 2026 at 11:59:36AM +0100, Krzysztof Kozlowski wrote:
>> On 25/03/2026 11:31, Thierry Reding wrote:
>>> On Thu, Mar 19, 2026 at 06:15:14PM +0100, Krzysztof Kozlowski wrote:
>>>> On 19/03/2026 18:09, Akhil R wrote:
>>>>> On Thu, 19 Mar 2026 10:40:34 +0100, Krzysztof Kozlowski wrote:
>>>>>> On Wed, Mar 18, 2026 at 10:57:25PM +0530, Akhil R wrote:
>>>>>>> Add I3C subsystem support, DesignWare I3C master controller, and
>>>>>>> SPD5118 hwmon sensor as modules to the defconfig.
>>>>>>
>>>>>> Why? If there is no user of that, why would we want it? Your commit msg
>>>>>> should explain that.
>>>>>
>>>>> Ack. This is for Tegra410 which has a DesignWare I3C host controller.
>>>>> I will add this in the commit message.
>>>>
>>>> Board or products. Not SoCs.
>>>
>>> Is this a new requirement? I see a bit of both in defconfig changes.
>>
>> Almost every review from me has it for 2-3 years... And it is a known
>> thing since always in a bit different wording: we do not care about
>> downstream things and downstream products. defconfig does not serve
>> downstream at all, makes no sense outside of our (upstream) work.
> 
> I don't understand why you're turning this into a downstream vs.
> upstream discussion. This is all code that is being submitted upstream,
> because we want these new platforms with I3C support enabled upstream.
> It's as simple as that.
> 
>>> Some mention specific products, other mention SoCs. Does this
>>> requirement apply to DT platforms or also ACPI platforms?
>>
>> Just like kernel, applies to all platforms, regardless of firmware
>> interface.
> 
> Hm... again, I don't think there's every been a rule to the effect of
> needing to specify a particular platform or product when adding a new
> defconfig change. There's plenty of things that we're enabling in the
> defconfigs because we think they are generally useful.

And the commit msg MUST always explain WHY we are doing it, in this case
- why do you think it is generally useful.

If you add new driver, it is usually obvious why it is generally useful.

If you add defconfig change for dead stuff, it is not obvious. That's
why commit msg must provide arguments WHY do we want it, WHY do you
think it is useful for us.

If you add defconfig change for device which no one (in terms of
upstream) can use, then automatically it is not useful. Whether this
change is like that - I do not know. That's why you have commit msg to
provide argument WHY maintainer should take it. And it is as simple as
one sentence explaining the upstream kernel user/use case of this
defconfig change...

Best regards,
Krzysztof

Re: [PATCH 12/12] arm64: defconfig: Enable I3C and SPD5118 hwmon

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3469 bytes --]

On Wed, Mar 25, 2026 at 01:47:44PM +0100, Krzysztof Kozlowski wrote:
> On 25/03/2026 13:41, Thierry Reding wrote:
> > On Wed, Mar 25, 2026 at 11:59:36AM +0100, Krzysztof Kozlowski wrote:
> >> On 25/03/2026 11:31, Thierry Reding wrote:
> >>> On Thu, Mar 19, 2026 at 06:15:14PM +0100, Krzysztof Kozlowski wrote:
> >>>> On 19/03/2026 18:09, Akhil R wrote:
> >>>>> On Thu, 19 Mar 2026 10:40:34 +0100, Krzysztof Kozlowski wrote:
> >>>>>> On Wed, Mar 18, 2026 at 10:57:25PM +0530, Akhil R wrote:
> >>>>>>> Add I3C subsystem support, DesignWare I3C master controller, and
> >>>>>>> SPD5118 hwmon sensor as modules to the defconfig.
> >>>>>>
> >>>>>> Why? If there is no user of that, why would we want it? Your commit msg
> >>>>>> should explain that.
> >>>>>
> >>>>> Ack. This is for Tegra410 which has a DesignWare I3C host controller.
> >>>>> I will add this in the commit message.
> >>>>
> >>>> Board or products. Not SoCs.
> >>>
> >>> Is this a new requirement? I see a bit of both in defconfig changes.
> >>
> >> Almost every review from me has it for 2-3 years... And it is a known
> >> thing since always in a bit different wording: we do not care about
> >> downstream things and downstream products. defconfig does not serve
> >> downstream at all, makes no sense outside of our (upstream) work.
> > 
> > I don't understand why you're turning this into a downstream vs.
> > upstream discussion. This is all code that is being submitted upstream,
> > because we want these new platforms with I3C support enabled upstream.
> > It's as simple as that.
> > 
> >>> Some mention specific products, other mention SoCs. Does this
> >>> requirement apply to DT platforms or also ACPI platforms?
> >>
> >> Just like kernel, applies to all platforms, regardless of firmware
> >> interface.
> > 
> > Hm... again, I don't think there's every been a rule to the effect of
> > needing to specify a particular platform or product when adding a new
> > defconfig change. There's plenty of things that we're enabling in the
> > defconfigs because we think they are generally useful.
> 
> And the commit msg MUST always explain WHY we are doing it, in this case
> - why do you think it is generally useful.
> 
> If you add new driver, it is usually obvious why it is generally useful.
> 
> If you add defconfig change for dead stuff, it is not obvious. That's
> why commit msg must provide arguments WHY do we want it, WHY do you
> think it is useful for us.

You're making too many assumptions. What's your basis for calling this
dead stuff? Do you really think we'd be spending any time on this if it
wasn't going to get used?

> If you add defconfig change for device which no one (in terms of
> upstream) can use, then automatically it is not useful. Whether this
> change is like that - I do not know. That's why you have commit msg to
> provide argument WHY maintainer should take it. And it is as simple as
> one sentence explaining the upstream kernel user/use case of this
> defconfig change...

Again, why are you making this about upstream vs. downstream? The goal
of these submissions is to make upstream capable of running on real
devices that real people want to run (preferably upstream) Linux on.

Anyway, I think this clarifies some of the questions I posed in my other
mail, so we'll go and add more information to this commit message to let
you know what products this will be used in.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 12/12] arm64: defconfig: Enable I3C and SPD5118 hwmon

[Krzysztof Kozlowski]

On 25/03/2026 14:05, Thierry Reding wrote:
> On Wed, Mar 25, 2026 at 01:47:44PM +0100, Krzysztof Kozlowski wrote:
>> On 25/03/2026 13:41, Thierry Reding wrote:
>>> On Wed, Mar 25, 2026 at 11:59:36AM +0100, Krzysztof Kozlowski wrote:
>>>> On 25/03/2026 11:31, Thierry Reding wrote:
>>>>> On Thu, Mar 19, 2026 at 06:15:14PM +0100, Krzysztof Kozlowski wrote:
>>>>>> On 19/03/2026 18:09, Akhil R wrote:
>>>>>>> On Thu, 19 Mar 2026 10:40:34 +0100, Krzysztof Kozlowski wrote:
>>>>>>>> On Wed, Mar 18, 2026 at 10:57:25PM +0530, Akhil R wrote:
>>>>>>>>> Add I3C subsystem support, DesignWare I3C master controller, and
>>>>>>>>> SPD5118 hwmon sensor as modules to the defconfig.
>>>>>>>>
>>>>>>>> Why? If there is no user of that, why would we want it? Your commit msg
>>>>>>>> should explain that.
>>>>>>>
>>>>>>> Ack. This is for Tegra410 which has a DesignWare I3C host controller.
>>>>>>> I will add this in the commit message.
>>>>>>
>>>>>> Board or products. Not SoCs.
>>>>>
>>>>> Is this a new requirement? I see a bit of both in defconfig changes.
>>>>
>>>> Almost every review from me has it for 2-3 years... And it is a known
>>>> thing since always in a bit different wording: we do not care about
>>>> downstream things and downstream products. defconfig does not serve
>>>> downstream at all, makes no sense outside of our (upstream) work.
>>>
>>> I don't understand why you're turning this into a downstream vs.
>>> upstream discussion. This is all code that is being submitted upstream,
>>> because we want these new platforms with I3C support enabled upstream.
>>> It's as simple as that.
>>>
>>>>> Some mention specific products, other mention SoCs. Does this
>>>>> requirement apply to DT platforms or also ACPI platforms?
>>>>
>>>> Just like kernel, applies to all platforms, regardless of firmware
>>>> interface.
>>>
>>> Hm... again, I don't think there's every been a rule to the effect of
>>> needing to specify a particular platform or product when adding a new
>>> defconfig change. There's plenty of things that we're enabling in the
>>> defconfigs because we think they are generally useful.
>>
>> And the commit msg MUST always explain WHY we are doing it, in this case
>> - why do you think it is generally useful.
>>
>> If you add new driver, it is usually obvious why it is generally useful.
>>
>> If you add defconfig change for dead stuff, it is not obvious. That's
>> why commit msg must provide arguments WHY do we want it, WHY do you
>> think it is useful for us.
> 
> You're making too many assumptions. What's your basis for calling this
> dead stuff? Do you really think we'd be spending any time on this if it
> wasn't going to get used?

I don't know. That's why the commit msg explains that it is not dead
stuff because we use it here and there.

Let's read the commit msg:

"Add I3C subsystem support, DesignWare I3C master controller, and
SPD5118 hwmon sensor as modules to the defconfig."

Helps nothing.

> 
>> If you add defconfig change for device which no one (in terms of
>> upstream) can use, then automatically it is not useful. Whether this
>> change is like that - I do not know. That's why you have commit msg to
>> provide argument WHY maintainer should take it. And it is as simple as
>> one sentence explaining the upstream kernel user/use case of this
>> defconfig change...
> 
> Again, why are you making this about upstream vs. downstream? The goal
> of these submissions is to make upstream capable of running on real

Up to here:
I do not make it upstream vs downstream. I expressed the same goal as
you here.

> devices that real people want to run (preferably upstream) Linux on.

But here not true. defconfig is ONLY upstream. The purpose of defconfig
is not to give some libraries of configs for downstream trees, because
it is useless for them. All downstreams or distros have their own
defconfigs, thus defconfig role is *only* upstream. I do not make it
"upstream vs downstream", but I make strong requirement of talking here
only about upstream.

Best regards,
Krzysztof