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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2a3903f5-4494-4053-b821-435a75b1ad7b@quicinc.com>
Date: Wed, 17 Sep 2025 19:49:38 +0530
From: Ram Kumar Dwivedi <quic_rdwivedi@...cinc.com>
To: Alim Akhtar <alim.akhtar@...sung.com>, <avri.altman@....com>,
        <bvanassche@....org>, <robh@...nel.org>, <krzk+dt@...nel.org>,
        <conor+dt@...nel.org>, <mani@...nel.org>,
        <James.Bottomley@...senPartnership.com>, <martin.petersen@...cle.com>
CC: <linux-scsi@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH V5 0/4] Add DT-based gear and rate limiting support



On 03-Sep-25 10:18 AM, Alim Akhtar wrote:
> Hi Ram
> 
>> -----Original Message-----
>> From: Ram Kumar Dwivedi <quic_rdwivedi@...cinc.com>
>> Sent: Tuesday, September 2, 2025 10:19 PM
>> To: alim.akhtar@...sung.com; avri.altman@....com;
>> bvanassche@....org; robh@...nel.org; krzk+dt@...nel.org;
>> conor+dt@...nel.org; mani@...nel.org;
>> James.Bottomley@...senPartnership.com; martin.petersen@...cle.com
>> Cc: linux-scsi@...r.kernel.org; devicetree@...r.kernel.org; linux-
>> kernel@...r.kernel.org; linux-arm-msm@...r.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.> 
> 
>