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: <6be65186-5af9-4a95-93db-41996310b715@quicinc.com>
Date: Wed, 21 May 2025 12:36:13 +0530
From: Sarthak Garg <quic_sartgarg@...cinc.com>
To: Ulf Hansson <ulf.hansson@...aro.org>
CC: Adrian Hunter <adrian.hunter@...el.com>, <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_sachgupt@...cinc.com>, <quic_bhaskarv@...cinc.com>,
        <quic_narepall@...cinc.com>, <kernel@...cinc.com>
Subject: Re: [PATCH V1] mmc: sdhci-msm: Enable MMC_CAP_AGGRESSIVE_PM for
 qualcomm controllers



On 11/15/2024 4:28 PM, Ulf Hansson wrote:
> On Mon, 4 Nov 2024 at 07:07, Sarthak Garg <quic_sartgarg@...cinc.com> wrote:
>>
>> Enable MMC_CAP_AGGRESSIVE_PM for qualcomm controllers.
>> This enables runtime PM for eMMC/SD card.
>>
>> Signed-off-by: Sarthak Garg <quic_sartgarg@...cinc.com>
> 
> In general I think using MMC_CAP_AGGRESSIVE_PM needs to be carefully
> selected. I am not saying it's a bad idea to use it, but the commit
> message above kind of indicates that this has only been enabled to
> make sure we avoid wasting energy at any cost. Maybe I am wrong?
> 
> Today the default autosuspend timeout is set to 3000 ms, which means
> that beyond this idle-period the card internally will no longer be
> able to manage "garbage collect". For a poorly behaving SD card, for
> example, that could hurt future read/writes. Or maybe that isn't such
> a big problem after all?
> 
> Also note that userspace via sysfs is able to change the autosuspend
> timeout and even disable runtime PM for the card, if that is needed.
> 
> Kind regards
> Uffe
>

Thanks for your valuable comment.
First of all sorry Ulf for the late reply as I was on break and came 
back now.
Yes you are right this has been enabled to make sure we avoid wasting 
power at any cost.
Moreover for a poorly behaving SD card we can't penalize the power 
consumption of all the SOC's so thats we won't to enable this flag.

>> ---
>>   drivers/mmc/host/sdhci-msm.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
>> index e00208535bd1..6657f7db1b8e 100644
>> --- a/drivers/mmc/host/sdhci-msm.c
>> +++ b/drivers/mmc/host/sdhci-msm.c
>> @@ -2626,6 +2626,7 @@ static int sdhci_msm_probe(struct platform_device *pdev)
>>                  goto clk_disable;
>>          }
>>
>> +       msm_host->mmc->caps |= MMC_CAP_AGGRESSIVE_PM;
>>          msm_host->mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY | MMC_CAP_NEED_RSP_BUSY;
>>
>>          /* Set the timeout value to max possible */
>> --
>> 2.17.1
>>