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.1On 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 >
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
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
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
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
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
On 27/03/2026 17:12:04+0530, Akhil R wrote: > 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 It works, thanks. The bitfield is fine then. > > Best Regards, > Akhil -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
On Fri, 27 Mar 2026 18:06:42 +0100, Alexandre Belloni wrote: > On 27/03/2026 17:12:04+0530, Akhil R wrote: >> 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 > > It works, thanks. The bitfield is fine then. Thanks for checking. I will update the link in the commit description and keep the rest of the patch as is. Hope that sounds good. Best Regards, Akhil
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
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
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
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
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
© 2016 - 2026 Red Hat, Inc.