linux-kernel - Re: [PATCH V2 1/3] scsi: ufs: dt-bindings: Document UFS Disable LPM property

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4734853b-87fc-4625-a9ee-54339b7a1512@kernel.org>
Date: Wed, 21 May 2025 08:51:01 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Nitin Rawat <quic_nitirawa@...cinc.com>,
 Pavan Kondeti <pavan.kondeti@....qualcomm.com>
Cc: alim.akhtar@...sung.com, avri.altman@....com, bvanassche@....org,
 krzk+dt@...nel.org, robh@...nel.org, mani@...nel.org, conor+dt@...nel.org,
 James.Bottomley@...senPartnership.com, martin.petersen@...cle.com,
 beanhuo@...ron.com, peter.wang@...iatek.com, linux-arm-msm@...r.kernel.org,
 linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org
Subject: Re: [PATCH V2 1/3] scsi: ufs: dt-bindings: Document UFS Disable LPM
 property

On 20/05/2025 20:49, Nitin Rawat wrote:
> 
> 
> On 5/20/2025 1:39 PM, Krzysztof Kozlowski wrote:
>> On 12/05/2025 09:41, Pavan Kondeti wrote:
>>> On Mon, May 12, 2025 at 09:45:49AM +0530, Nitin Rawat wrote:
>>>>
>>>>
>>>> On 5/7/2025 8:34 PM, Nitin Rawat wrote:
>>>>>
>>>>>
>>>>> On 5/6/2025 11:46 PM, Krzysztof Kozlowski wrote:
>>>>>> On 06/05/2025 18:37, Nitin Rawat wrote:
>>>>>>> Disable UFS low power mode on emulation FPGA platforms or other
>>>>>>> platforms
>>>>>>
>>>>>> Why wouldn't you like to test LPM also on FPGA designs? I do not see
>>>>>> here correlation.
>>>>>
>>>>> Hi Krzysztof,
>>>>>
>>>>> Since the FPGA platform doesn't support UFS Low Power Modes (such as the
>>>>> AutoHibern8 feature specified in the UFS specification), I have included
>>>>> this information in the hardware description (i.e dts).
>>>>
>>>>
>>>> Hi Krzysztof,
>>>>
>>>> Could you please share your thoughts on my above comment? If you still see
>>>> concerns, I may need to consider other options like modparam.
>>>>
>>>
>>> I understand why you are inclining towards the module param here. Before
>>> we take that route,
>>>
>>> Is it possible to use a different compatible (for ex: qcom,sm8650-emu-ufshc) for UFS controller
>>> on the emulation platform and apply the quirk in the driver based on the device_get_match_data()
>>> based detection?
>>
>> I do not get what are the benefits of upstreaming such patches. It feels
>> like you have some internal product, which will never be released, no
>> one will ever use it and eventually will be obsolete even internally. We
>> don't want patches for every broken feature or every broken hardware.
> 
> Hi Krzysztof,
> 
> Thank you for your review and opinions. I would like to clarify that 
> this is a platform requirement rather than a broken feature. 
> Additionally, there are few automotive targets, in addition to the FPGA 
> platform, where Low Power Mode (LPM) is not a requirement. For these 
> platforms, the LPM disable changes are currently maintained downstream.

And these platforms do not have their own SoC compatible? When you say
platforms, you mean SoC or boards? So many options... all this is so
unspecific, I need to dig every answer, every specific bit.

> 
> My apology for not including the automotive requirements in my previous 
> commit messages.
> 
> In my opinion, since these platforms do not support LPM, I requested 
> that this be reflected in the hardware description (i.e. DTS)). However, 
> I am open to suggestions and am willing to proceed with module 
> parameters if you have concerns regarding the device tree.

Module param will get other obstacles... We have lengthy discussion
because your commit msg explains nothing. Even now I still don't know
what do you mean by half of above statements. Use the wide upstream
terms, instead of ambiguous like "automotive platform".

Best regards,
Krzysztof