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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <8aa09712-5543-4bda-bf9e-a29c61656445@kernel.org>
Date: Tue, 20 May 2025 10:09:47 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Pavan Kondeti <pavan.kondeti@....qualcomm.com>,
 Nitin Rawat <quic_nitirawa@...cinc.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 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.

Best regards,
Krzysztof