Re: [PATCH v6 3/4] ufs: host: Add ICE clock scaling during UFS clock changes

[Krzysztof Kozlowski]

On 26/02/2026 07:14, Abhinaba Rakshit wrote:
> On Wed, Feb 25, 2026 at 03:12:18PM +0100, Krzysztof Kozlowski wrote:
>> On 25/02/2026 13:58, Abhinaba Rakshit wrote:
>>> On Wed, Feb 25, 2026 at 10:00:12AM +0100, Krzysztof Kozlowski wrote:
>>>> On 19/02/2026 10:39, Abhinaba Rakshit wrote:
>>>>> Implement ICE (Inline Crypto Engine) clock scaling in sync with
>>>>> UFS controller clock scaling. This ensures that the ICE operates at
>>>>> an appropriate frequency when the UFS clocks are scaled up or down,
>>>>> improving performance and maintaining stability for crypto operations.
>>>>>
>>>>> Incase of OPP scaling is not supported by ICE, ensure to not prevent
>>>>> devfreq for UFS, as ICE OPP-table is optional.
>>>>>
>>>>> Acked-by: Manivannan Sadhasivam <mani@xxxxxxxxxx>
>>>>> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@xxxxxxxxxxxxxxxx>
>>>>> ---
>>>>>  drivers/ufs/host/ufs-qcom.c | 21 ++++++++++++++++++++-
>>>>
>>>>
>>>> SCSI/UFS is not respecting subsystem boundaries, thus you must not
>>>> combine multiple subsystem when targeting UFS.
>>>>
>>>> Please split your patches.
>>>
>>> Sorry, if I fail to understand the context here.
>>> This patch-series is already split into 4 patches based on the subsystem.
>>
>> s/patches/patchset/
>> Please split the patchset to not combine independent patches targeting
>> different subsystem into one patchset.
> 
> In this series, the UFS subsystem patch depends on the new ICE clock-scaling
> API introduced in the crypto/ICE patch. Without that ICE change, the UFS
> driver cannot call the scaling helper, so the UFS subsystem patch cannot
> be applied *independently*.

What? Where is this explained in the cover letter? Where is merging
dependencies/order mentioned?
> 
> Given this dependency, splitting the series into separate, standalone
> patchsets would break bisectability and lead to build/runtime failures
> if they are not merged together.
> 
> Please let me know what is the preferred approach in such instance.
> 
> Abhinaba Rakshit


Best regards,
Krzysztof