Add documentation for two new optional properties:
- limit-hs-gear
- limit-rate
These properties allow platforms to restrict the maximum high-speed
gear and rate used by the UFS controller. This is required for
certain automotive platforms with hardware constraints.
Signed-off-by: Ram Kumar Dwivedi <quic_rdwivedi@quicinc.com>
---
Documentation/devicetree/bindings/ufs/qcom,ufs.yaml | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
index 6c6043d9809e..9dedd09df9e0 100644
--- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
+++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
@@ -111,6 +111,16 @@ properties:
description:
GPIO connected to the RESET pin of the UFS memory device.
+ limit-hs-gear:
+ maxItems: 1
+ description:
+ Limit max phy hs gear
+
+ limit-rate:
+ maxItems: 1
+ description:
+ Limit max phy hs rate
+
required:
- compatible
- reg
--
2.50.1
On Tue, Jul 22, 2025 at 09:41:03PM +0530, Ram Kumar Dwivedi wrote: > Add documentation for two new optional properties: > - limit-hs-gear > - limit-rate > > These properties allow platforms to restrict the maximum high-speed > gear and rate used by the UFS controller. This is required for > certain automotive platforms with hardware constraints. Please reformat other way around: describe the actual problem (which platforms, which constraints, what breaks, etc). Then describe your solution. > > Signed-off-by: Ram Kumar Dwivedi <quic_rdwivedi@quicinc.com> > --- > Documentation/devicetree/bindings/ufs/qcom,ufs.yaml | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml > index 6c6043d9809e..9dedd09df9e0 100644 > --- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml > +++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml > @@ -111,6 +111,16 @@ properties: > description: > GPIO connected to the RESET pin of the UFS memory device. > > + limit-hs-gear: If the properties are generic, they should go to the ufs-common.yaml. If not (but why?), then they should be prefixed with 'qcom,' prefix, as usual. > + maxItems: 1 > + description: > + Limit max phy hs gear > + > + limit-rate: > + maxItems: 1 > + description: > + Limit max phy hs rate > + > required: > - compatible > - reg > -- > 2.50.1 > -- With best wishes Dmitry
On 23-Jul-25 12:32 AM, Dmitry Baryshkov wrote: > On Tue, Jul 22, 2025 at 09:41:03PM +0530, Ram Kumar Dwivedi wrote: >> Add documentation for two new optional properties: >> - limit-hs-gear >> - limit-rate >> >> These properties allow platforms to restrict the maximum high-speed >> gear and rate used by the UFS controller. This is required for >> certain automotive platforms with hardware constraints. > > Please reformat other way around: describe the actual problem (which > platforms, which constraints, what breaks, etc). Then describe your > solution. > Hi Dmitry, I have addressed this in latest patchset. Thanks, Ram. >> >> Signed-off-by: Ram Kumar Dwivedi <quic_rdwivedi@quicinc.com> >> --- >> Documentation/devicetree/bindings/ufs/qcom,ufs.yaml | 10 ++++++++++ >> 1 file changed, 10 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml >> index 6c6043d9809e..9dedd09df9e0 100644 >> --- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml >> +++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml >> @@ -111,6 +111,16 @@ properties: >> description: >> GPIO connected to the RESET pin of the UFS memory device. >> >> + limit-hs-gear: > > If the properties are generic, they should go to the ufs-common.yaml. If > not (but why?), then they should be prefixed with 'qcom,' prefix, as > usual. Hi Dmitry, I have added qcom prefix in latest patchset. Thanks, Ram. > >> + maxItems: 1 >> + description: >> + Limit max phy hs gear >> + >> + limit-rate: >> + maxItems: 1 >> + description: >> + Limit max phy hs rate >> + >> required: >> - compatible >> - reg >> -- >> 2.50.1 >> >
On 24/07/2025 09:36, Ram Kumar Dwivedi wrote: >>> GPIO connected to the RESET pin of the UFS memory device. >>> >>> + limit-hs-gear: >> >> If the properties are generic, they should go to the ufs-common.yaml. If >> not (but why?), then they should be prefixed with 'qcom,' prefix, as >> usual. > > Hi Dmitry, > > I have added qcom prefix in latest patchset. Unlike this patchset here, are you going to test before sending it? Best regards, Krzysztof
On Tue, 22 Jul 2025 21:41:03 +0530, Ram Kumar Dwivedi wrote: > Add documentation for two new optional properties: > - limit-hs-gear > - limit-rate > > These properties allow platforms to restrict the maximum high-speed > gear and rate used by the UFS controller. This is required for > certain automotive platforms with hardware constraints. > > Signed-off-by: Ram Kumar Dwivedi <quic_rdwivedi@quicinc.com> > --- > Documentation/devicetree/bindings/ufs/qcom,ufs.yaml | 10 ++++++++++ > 1 file changed, 10 insertions(+) > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml: limit-hs-gear: missing type definition /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml: limit-rate: missing type definition doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250722161103.3938-4-quic_rdwivedi@quicinc.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
© 2016 - 2025 Red Hat, Inc.