linux-kernel - Re: [PATCH V1] mmc: sdhci-msm: Enable MMC_CAP_AGGRESSIVE

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: <ca83b841-aea0-4233-93fe-02a7b5985af4@quicinc.com>
Date: Wed, 21 May 2025 21:06:06 +0530
From: Sarthak Garg <quic_sartgarg@...cinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
CC: Adrian Hunter <adrian.hunter@...el.com>,
        Ulf Hansson
	<ulf.hansson@...aro.org>, <linux-mmc@...r.kernel.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <quic_cang@...cinc.com>, <quic_nguyenb@...cinc.com>,
        <quic_rampraka@...cinc.com>, <quic_pragalla@...cinc.com>,
        <quic_sayalil@...cinc.com>, <quic_nitirawa@...cinc.com>,
        <quic_bhaskarv@...cinc.com>, <kernel@...cinc.com>
Subject: Re: [PATCH V1] mmc: sdhci-msm: Enable MMC_CAP_AGGRESSIVE_PM for
 qualcomm controllers



On 5/21/2025 8:19 PM, Dmitry Baryshkov wrote:
> On 21/05/2025 17:35, Sarthak Garg wrote:
>>
>>
>> On 5/21/2025 6:25 PM, Dmitry Baryshkov wrote:
>>> On Wed, May 21, 2025 at 12:46:49PM +0530, Sarthak Garg wrote:
>>>>
>>>>
>>>> On 11/15/2024 6:53 PM, Dmitry Baryshkov wrote:
>>>>> On Fri, 15 Nov 2024 at 12:23, Sarthak Garg 
>>>>> <quic_sartgarg@...cinc.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 11/4/2024 4:19 PM, Dmitry Baryshkov wrote:
>>>>>>> On Mon, Nov 04, 2024 at 11:37:22AM +0530, Sarthak Garg wrote:
>>>>>>>> Enable MMC_CAP_AGGRESSIVE_PM for qualcomm controllers.
>>>>>>>> This enables runtime PM for eMMC/SD card.
>>>>>>>
>>>>>>> Could you please mention, which platforms were tested with this 
>>>>>>> patch?
>>>>>>> Note, upstream kernel supports a lot of platforms, including 
>>>>>>> MSM8974, I
>>>>>>> think the oldest one, which uses SDHCI.
>>>>>>>
>>>>>>
>>>>>> This was tested with qdu1000 platform.
>>>>>
>>>>> Are you sure that it won't break other platforms?
>>>>>
>>>>
>>>> Thanks for your valuable comment.
>>>> I am not sure about the older platforms so to avoid issues on older
>>>> platforms we can enable this for all SDCC version 5.0 targets ?
>>>
>>> No, there are still a lot of platforms. Either explain why this is
>>> required for all v5 platforms (and won't break those) or find some other
>>> way, e.g. limit the change to QDU1000, explaining why it is _not_
>>> applicable to other platforms.
>>>
>>
>> Thanks for your comment.
> 
> No need to.
>  >> I agree with your concern but for me also its not possible to test on
>> all the platforms.
> 
> Sure.
> >> Lets say if I want to enable this caps for QDU1000 for which it has
>> been tested and on any other upcoming target after testing, then how 
>> can I proceed to enable?
> 
> Let's start from the beginning: why do you want to enable it on QDU1000?
> 

QDU1000 is one latest available target where we have enabled this and 
tested. This has been enabled to save power.

>>
>> One option I had thought of was to implement this using compatible 
>> string, then for all the upcoming platforms using this compatible 
>> string as a fallback.
>> But this doesn't look optimal to use compatible string for just one 
>> flag and also this capability is not platform specific and we will be 
>> needing for all the platforms. Please share your opinion on this.
>>
>> Another option that I could have thought of is using device tree based 
>> approach but seems that was not accepted earlier :
>> https://patchwork.kernel.org/project/linux-mmc/ 
>> patch/20230129023630.830764-1-chenhuiz@...s.com/
>>
>> So it would be helpful if you can suggest some approach?
> 
> Worst case, just tie it to the SoC-specific compat string that is 
> already a part of the bindings.
> 
> 

Sure will try to explore better solution before going for the worst case.