Add optional "limit-hs-gear" and "limit-rate" properties to the
UFS controller common binding. These properties allow limiting
the maximum HS gear and rate.
This is useful in cases where the customer board may have signal
integrity, clock configuration or layout issues that prevent reliable
operation at higher gears. Such limitations are especially critical in
those platforms, where stability is prioritized over peak performance.
Signed-off-by: Ram Kumar Dwivedi <quic_rdwivedi@quicinc.com>
---
.../devicetree/bindings/ufs/ufs-common.yaml | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/ufs/ufs-common.yaml b/Documentation/devicetree/bindings/ufs/ufs-common.yaml
index 31fe7f30ff5b..1af658207901 100644
--- a/Documentation/devicetree/bindings/ufs/ufs-common.yaml
+++ b/Documentation/devicetree/bindings/ufs/ufs-common.yaml
@@ -89,6 +89,24 @@ properties:
msi-parent: true
+ limit-hs-gear:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 5
+ default: 5
+ description:
+ Restricts the maximum HS gear used in both TX and RX directions,
+ typically for hardware or power constraints in automotive use cases.
+
+ limit-rate:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2]
+ default: 2
+ description:
+ Restricts the UFS controller to Rate A (1) or Rate B (2) for both
+ TX and RX directions, often required in automotive environments due
+ to hardware limitations.
+
dependencies:
freq-table-hz: [ clocks ]
operating-points-v2: [ clocks, clock-names ]
--
2.50.1On 8/26/25 8:08 AM, Ram Kumar Dwivedi wrote: > + limit-hs-gear: > + $ref: /schemas/types.yaml#/definitions/uint32 > + minimum: 1 > + maximum: 5 > + default: 5 > + description: > + Restricts the maximum HS gear used in both TX and RX directions, > + typically for hardware or power constraints in automotive use cases. The UFSHCI 5.0 spec will add gear 6 soon. So why to restrict the maximum gear to 5? > + limit-rate: > + $ref: /schemas/types.yaml#/definitions/uint32 > + enum: [1, 2] > + default: 2 > + description: > + Restricts the UFS controller to Rate A (1) or Rate B (2) for both > + TX and RX directions, often required in automotive environments due > + to hardware limitations. As far as I know no numeric values are associated with these rates in the UFSHCI 4.1 standard nor in any of the previous versions of this standard. Does the .yaml syntax support something like "enum: [A, B]"? Thanks, Bart.
On 26/08/2025 17:35, Bart Van Assche wrote: > >> + limit-rate: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + enum: [1, 2] >> + default: 2 >> + description: >> + Restricts the UFS controller to Rate A (1) or Rate B (2) for both >> + TX and RX directions, often required in automotive environments due >> + to hardware limitations. > > As far as I know no numeric values are associated with these rates in > the UFSHCI 4.1 standard nor in any of the previous versions of this > standard. Does the .yaml syntax support something like "enum: [A, B]"? That's what I also requested and answer was "1" and "2" are coming from the spec. So now I am confused. Best regards, Krzysztof
On 8/28/25 10:40 AM, Krzysztof Kozlowski wrote: > On 26/08/2025 17:35, Bart Van Assche wrote: >> >>> + limit-rate: >>> + $ref: /schemas/types.yaml#/definitions/uint32 >>> + enum: [1, 2] >>> + default: 2 >>> + description: >>> + Restricts the UFS controller to Rate A (1) or Rate B (2) for both >>> + TX and RX directions, often required in automotive environments due >>> + to hardware limitations. >> >> As far as I know no numeric values are associated with these rates in >> the UFSHCI 4.1 standard nor in any of the previous versions of this >> standard. Does the .yaml syntax support something like "enum: [A, B]"? > > That's what I also requested and answer was "1" and "2" are coming from > the spec. So now I am confused. Ram quoted from the MIPI spec. That's another standard than what I referred to (UFSHCI). Bart.
On 26-Aug-25 9:05 PM, Bart Van Assche wrote: > On 8/26/25 8:08 AM, Ram Kumar Dwivedi wrote: >> + limit-hs-gear: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + minimum: 1 >> + maximum: 5 >> + default: 5 >> + description: >> + Restricts the maximum HS gear used in both TX and RX directions, >> + typically for hardware or power constraints in automotive use cases. > > The UFSHCI 5.0 spec will add gear 6 soon. So why to restrict the maximum > gear to 5? > >> + limit-rate: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + enum: [1, 2] >> + default: 2 >> + description: >> + Restricts the UFS controller to Rate A (1) or Rate B (2) for both >> + TX and RX directions, often required in automotive environments due >> + to hardware limitations. > > As far as I know no numeric values are associated with these rates in > the UFSHCI 4.1 standard nor in any of the previous versions of this > standard. Does the .yaml syntax support something like "enum: [A, B]"? Hi Bart, As per the MIPI UniPro spec: In Section 5.7.12.3.2, the hs_series is defined as: hs_series = Flags[3] + 1; In Section 5.7.7.1, Flags[3] is described as: Set to ‘0’ for Series A and ‘1’ for Series B (PA_HSSeries). While issuing the DME command from the UFS driver to set the rate, the values 1 and 2 are passed as arguments for Rate A and Rate B respectively. Additionally, the hs_rate variable is of type u32. Thanks, Ram > > Thanks, > > Bart.
On 28/08/2025 18:45, Ram Kumar Dwivedi wrote: > > > On 26-Aug-25 9:05 PM, Bart Van Assche wrote: >> On 8/26/25 8:08 AM, Ram Kumar Dwivedi wrote: >>> + limit-hs-gear: >>> + $ref: /schemas/types.yaml#/definitions/uint32 >>> + minimum: 1 >>> + maximum: 5 >>> + default: 5 >>> + description: >>> + Restricts the maximum HS gear used in both TX and RX directions, >>> + typically for hardware or power constraints in automotive use cases. >> >> The UFSHCI 5.0 spec will add gear 6 soon. So why to restrict the maximum >> gear to 5? >> >>> + limit-rate: >>> + $ref: /schemas/types.yaml#/definitions/uint32 >>> + enum: [1, 2] >>> + default: 2 >>> + description: >>> + Restricts the UFS controller to Rate A (1) or Rate B (2) for both >>> + TX and RX directions, often required in automotive environments due >>> + to hardware limitations. >> >> As far as I know no numeric values are associated with these rates in >> the UFSHCI 4.1 standard nor in any of the previous versions of this >> standard. Does the .yaml syntax support something like "enum: [A, B]"? > Hi Bart, > > As per the MIPI UniPro spec: > > In Section 5.7.12.3.2, the hs_series is defined as: > hs_series = Flags[3] + 1; > > In Section 5.7.7.1, Flags[3] is described as: > Set to ‘0’ for Series A and ‘1’ for Series B (PA_HSSeries). That's register value. Why are you using values as argument of actual meaning of rates? Best regards, Krzysztof
On 8/28/25 9:45 AM, Ram Kumar Dwivedi wrote: > On 26-Aug-25 9:05 PM, Bart Van Assche wrote: >> On 8/26/25 8:08 AM, Ram Kumar Dwivedi wrote: >>> + limit-rate: >>> + $ref: /schemas/types.yaml#/definitions/uint32 >>> + enum: [1, 2] >>> + default: 2 >>> + description: >>> + Restricts the UFS controller to Rate A (1) or Rate B (2) for both >>> + TX and RX directions, often required in automotive environments due >>> + to hardware limitations. >> >> As far as I know no numeric values are associated with these rates in >> the UFSHCI 4.1 standard nor in any of the previous versions of this >> standard. Does the .yaml syntax support something like "enum: [A, B]"? > Hi Bart, > > As per the MIPI UniPro spec: > > In Section 5.7.12.3.2, the hs_series is defined as: > hs_series = Flags[3] + 1; > > In Section 5.7.7.1, Flags[3] is described as: > Set to ‘0’ for Series A and ‘1’ for Series B (PA_HSSeries). > > While issuing the DME command from the UFS driver to set the rate, > the values 1 and 2 are passed as arguments for Rate A and Rate B > respectively. Additionally, the hs_rate variable is of type u32. Hi Ram, Thanks for having looked this up. Since it is much more common to refer to these rates as "Rate A" and "Rate B" rather than using numbers for these rates, please change the enumeration labels into something like "Rate_A" and "Rate_B". Thanks, Bart.
On Thu, Aug 28, 2025 at 10:22:28AM GMT, Bart Van Assche wrote: > On 8/28/25 9:45 AM, Ram Kumar Dwivedi wrote: > > On 26-Aug-25 9:05 PM, Bart Van Assche wrote: > > > On 8/26/25 8:08 AM, Ram Kumar Dwivedi wrote: > > > > + limit-rate: > > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > > + enum: [1, 2] > > > > + default: 2 > > > > + description: > > > > + Restricts the UFS controller to Rate A (1) or Rate B (2) for both > > > > + TX and RX directions, often required in automotive environments due > > > > + to hardware limitations. > > > > > > As far as I know no numeric values are associated with these rates in > > > the UFSHCI 4.1 standard nor in any of the previous versions of this > > > standard. Does the .yaml syntax support something like "enum: [A, B]"? > > Hi Bart, > > > > As per the MIPI UniPro spec: > > > > In Section 5.7.12.3.2, the hs_series is defined as: > > hs_series = Flags[3] + 1; > > > > In Section 5.7.7.1, Flags[3] is described as: > > Set to ‘0’ for Series A and ‘1’ for Series B (PA_HSSeries). > > > > While issuing the DME command from the UFS driver to set the rate, > > the values 1 and 2 are passed as arguments for Rate A and Rate B > > respectively. Additionally, the hs_rate variable is of type u32. > > Hi Ram, > > Thanks for having looked this up. > > Since it is much more common to refer to these rates as "Rate A" and > "Rate B" rather than using numbers for these rates, please change the > enumeration labels into something like "Rate_A" and "Rate_B". > +1. Since this binding describes the HCI, let's stick to the terminologies in UFSHCI spec. - Mani -- மணிவண்ணன் சதாசிவம்
On 01-Sep-25 9:37 AM, Manivannan Sadhasivam wrote: > On Thu, Aug 28, 2025 at 10:22:28AM GMT, Bart Van Assche wrote: >> On 8/28/25 9:45 AM, Ram Kumar Dwivedi wrote: >>> On 26-Aug-25 9:05 PM, Bart Van Assche wrote: >>>> On 8/26/25 8:08 AM, Ram Kumar Dwivedi wrote: >>>>> + limit-rate: >>>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>>> + enum: [1, 2] >>>>> + default: 2 >>>>> + description: >>>>> + Restricts the UFS controller to Rate A (1) or Rate B (2) for both >>>>> + TX and RX directions, often required in automotive environments due >>>>> + to hardware limitations. >>>> >>>> As far as I know no numeric values are associated with these rates in >>>> the UFSHCI 4.1 standard nor in any of the previous versions of this >>>> standard. Does the .yaml syntax support something like "enum: [A, B]"? >>> Hi Bart, >>> >>> As per the MIPI UniPro spec: >>> >>> In Section 5.7.12.3.2, the hs_series is defined as: >>> hs_series = Flags[3] + 1; >>> >>> In Section 5.7.7.1, Flags[3] is described as: >>> Set to ‘0’ for Series A and ‘1’ for Series B (PA_HSSeries). >>> >>> While issuing the DME command from the UFS driver to set the rate, >>> the values 1 and 2 are passed as arguments for Rate A and Rate B >>> respectively. Additionally, the hs_rate variable is of type u32. >> >> Hi Ram, >> >> Thanks for having looked this up. >> >> Since it is much more common to refer to these rates as "Rate A" and >> "Rate B" rather than using numbers for these rates, please change the >> enumeration labels into something like "Rate_A" and "Rate_B". >> > > +1. Since this binding describes the HCI, let's stick to the terminologies in > UFSHCI spec. I have taken care of this in the next patchset. Thanks, Ram > > - Mani >
On 26-Aug-25 9:05 PM, Bart Van Assche wrote: > On 8/26/25 8:08 AM, Ram Kumar Dwivedi wrote: >> + limit-hs-gear: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + minimum: 1 >> + maximum: 5 >> + default: 5 >> + description: >> + Restricts the maximum HS gear used in both TX and RX directions, >> + typically for hardware or power constraints in automotive use cases. > > The UFSHCI 5.0 spec will add gear 6 soon. So why to restrict the maximum > gear to 5? Hi Bart, Thanks for the suggestion. I limited it to Gear 5 based on current upstream support. But I am fine with updating it to Gear 6 if you prefer, to align with the upcoming spec and avoid future revisions. Thanks, Ram. > >> + limit-rate: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + enum: [1, 2] >> + default: 2 >> + description: >> + Restricts the UFS controller to Rate A (1) or Rate B (2) for both >> + TX and RX directions, often required in automotive environments due >> + to hardware limitations. > > As far as I know no numeric values are associated with these rates in > the UFSHCI 4.1 standard nor in any of the previous versions of this > standard. Does the .yaml syntax support something like "enum: [A, B]"? > > Thanks, > > Bart.
On 28/08/2025 18:25, Ram Kumar Dwivedi wrote: > > > On 26-Aug-25 9:05 PM, Bart Van Assche wrote: >> On 8/26/25 8:08 AM, Ram Kumar Dwivedi wrote: >>> + limit-hs-gear: >>> + $ref: /schemas/types.yaml#/definitions/uint32 >>> + minimum: 1 >>> + maximum: 5 >>> + default: 5 >>> + description: >>> + Restricts the maximum HS gear used in both TX and RX directions, >>> + typically for hardware or power constraints in automotive use cases. >> >> The UFSHCI 5.0 spec will add gear 6 soon. So why to restrict the maximum >> gear to 5? > > Hi Bart, > > Thanks for the suggestion. I limited it to Gear 5 based on current upstream support. Upstream of what? Bindings describe hardware. Best regards, Krzysztof
© 2016 - 2025 Red Hat, Inc.