RE: [PATCH V5 0/4] Add DT-based gear and rate limiting support

Alim Akhtar posted 4 patches 1 month ago
Only 0 patches received!
RE: [PATCH V5 0/4] Add DT-based gear and rate limiting support
Posted by Alim Akhtar 1 month ago
Hi Ram

> -----Original Message-----
> From: Ram Kumar Dwivedi <quic_rdwivedi@quicinc.com>
> Sent: Tuesday, September 2, 2025 10:19 PM
> To: alim.akhtar@samsung.com; avri.altman@wdc.com;
> bvanassche@acm.org; robh@kernel.org; krzk+dt@kernel.org;
> conor+dt@kernel.org; mani@kernel.org;
> James.Bottomley@HansenPartnership.com; martin.petersen@oracle.com
> Cc: linux-scsi@vger.kernel.org; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-arm-msm@vger.kernel.org
> Subject: [PATCH V5 0/4] Add DT-based gear and rate limiting support
> 
> This patch series adds support for limiting the maximum high-speed gear
and
> rate used by the UFS controller via device tree properties.
> 
> Some platforms may have signal integrity, clock configuration, or layout
> issues that prevent reliable operation at higher gears or rates.
> This is especially critical in automotive and other platforms where
stability is
> prioritized over peak performance.
> 
> The series follows this logical progression:
> 1. Document the new DT properties in the common UFS binding 2. Clean up
> existing redundant code in the qcom driver 3. Add platform-level parsing
> support for the new properties 4. Integrate the platform support in the
qcom
> driver
> 
> This approach makes the functionality available to other UFS host drivers
and
> provides a cleaner, more maintainable implementation.
> 
> Changes from V1:
> - Restructured patch series for better logical flow and maintainability.
> - Moved DT bindings to ufs-common.yaml making it available for all UFS
>   controllers.
> - Added platform-level support in ufshcd-pltfrm.c for code reusability.
> - Separated the cleanup patch to remove redundant hs_rate assignment in
>   qcom driver.
> - Removed SA8155 DTS changes to keep the series focused on core
>   functionality.
> - Improved commit messages with better technical rationale.
> 
> Changes from V2:
> - Documented default values of limit-rate and limit-hs-gear in DT bindings
>   as per Krzysztof's suggestion.
> 
> Changes from V3:
> - Changed limit-rate property from numeric values 1 and 2 to string values
>   Rate-A and Rate-B for better readability and clarity as suggested by
>   Bart and Krzysztof.
> - Added Co-developed-by tag for Nitin Rawat in 3rd patch.
> 
> Changes from V4:
> - Added the missing argument to the error message while parsing
>   limit-rate property.
> - Updated the maximum supported value and default for limit-gear
>   property to gear 6, as per Krzysztof's and Bart's recommendation.
> - Renamed Rate-A and Rate-B to lowercase (rate-a, rate-b) as suggested
>   by Krzysztof.
> 
Please allow minimum 4 ~ 5 days for reviewers to complete the review before
posting next version.
That will also help to reduce the number of iteration a patch goes through.
Thanks
Re: [PATCH V5 0/4] Add DT-based gear and rate limiting support
Posted by Ram Kumar Dwivedi 2 weeks, 1 day ago

On 03-Sep-25 10:18 AM, Alim Akhtar wrote:
> Hi Ram
> 
>> -----Original Message-----
>> From: Ram Kumar Dwivedi <quic_rdwivedi@quicinc.com>
>> Sent: Tuesday, September 2, 2025 10:19 PM
>> To: alim.akhtar@samsung.com; avri.altman@wdc.com;
>> bvanassche@acm.org; robh@kernel.org; krzk+dt@kernel.org;
>> conor+dt@kernel.org; mani@kernel.org;
>> James.Bottomley@HansenPartnership.com; martin.petersen@oracle.com
>> Cc: linux-scsi@vger.kernel.org; devicetree@vger.kernel.org; linux-
>> kernel@vger.kernel.org; linux-arm-msm@vger.kernel.org
>> Subject: [PATCH V5 0/4] Add DT-based gear and rate limiting support
>>
>> This patch series adds support for limiting the maximum high-speed gear
> and
>> rate used by the UFS controller via device tree properties.
>>
>> Some platforms may have signal integrity, clock configuration, or layout
>> issues that prevent reliable operation at higher gears or rates.
>> This is especially critical in automotive and other platforms where
> stability is
>> prioritized over peak performance.
>>
>> The series follows this logical progression:
>> 1. Document the new DT properties in the common UFS binding 2. Clean up
>> existing redundant code in the qcom driver 3. Add platform-level parsing
>> support for the new properties 4. Integrate the platform support in the
> qcom
>> driver
>>
>> This approach makes the functionality available to other UFS host drivers
> and
>> provides a cleaner, more maintainable implementation.
>>
>> Changes from V1:
>> - Restructured patch series for better logical flow and maintainability.
>> - Moved DT bindings to ufs-common.yaml making it available for all UFS
>>   controllers.
>> - Added platform-level support in ufshcd-pltfrm.c for code reusability.
>> - Separated the cleanup patch to remove redundant hs_rate assignment in
>>   qcom driver.
>> - Removed SA8155 DTS changes to keep the series focused on core
>>   functionality.
>> - Improved commit messages with better technical rationale.
>>
>> Changes from V2:
>> - Documented default values of limit-rate and limit-hs-gear in DT bindings
>>   as per Krzysztof's suggestion.
>>
>> Changes from V3:
>> - Changed limit-rate property from numeric values 1 and 2 to string values
>>   Rate-A and Rate-B for better readability and clarity as suggested by
>>   Bart and Krzysztof.
>> - Added Co-developed-by tag for Nitin Rawat in 3rd patch.
>>
>> Changes from V4:
>> - Added the missing argument to the error message while parsing
>>   limit-rate property.
>> - Updated the maximum supported value and default for limit-gear
>>   property to gear 6, as per Krzysztof's and Bart's recommendation.
>> - Renamed Rate-A and Rate-B to lowercase (rate-a, rate-b) as suggested
>>   by Krzysztof.
>>
> Please allow minimum 4 ~ 5 days for reviewers to complete the review before
> posting next version.
> That will also help to reduce the number of iteration a patch goes through.
> Thanks

Hi Alim,

Thanks for input. I’ll make sure to allow at least 4–5 days for the 
reviewers to complete their review before posting the next version.

Thanks,
Ram.> 
> 
>