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: <CAPDyKFrYkKFJ=+4t4ad=a4GJUCBVO7FuaRqdxSTUWtHOWgUA_w@mail.gmail.com>
Date: Fri, 15 Nov 2024 11:58:00 +0100
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Sarthak Garg <quic_sartgarg@...cinc.com>
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 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

> ---
>  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
>