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] [day] [month] [year] [list]

Message-ID: <CAPDyKFo9gUOB0VhQn=zD0RDM0=8wO08=VmA6XkHv0EN7M89bjg@mail.gmail.com>
Date: Tue, 27 May 2025 17:20:31 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>, 
	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_bhaskarv@...cinc.com, kernel@...cinc.com
Subject: Re: [PATCH V1] mmc: sdhci-msm: Enable MMC_CAP_AGGRESSIVE_PM for
 qualcomm controllers

On Wed, 21 May 2025 at 17:41, Dmitry Baryshkov
<dmitry.baryshkov@....qualcomm.com> wrote:
>
> On 21/05/2025 18:36, Sarthak Garg wrote:
> >
> >
> > 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.
>
> Isn't it a powered device? How much power is the save? Is it worth it?

Just wanted to share my view around this, in a slightly more generic
way. My answer to the above, would be, yes, for any battery driven
platform, it should be worth it.

Unfortunately, I don't have any fresh numbers to share for eMMC/SD,
but just searching for some vendor specific information about their
eMMC/SD cards, should tell us I think. In fact, this problem isn't
even limited to eMMC/SD, but rather applies to most flash based
storage (UFS/NVMe etc) that are used on these types of platforms.

How much there is to gain, obviously depends on the internal behaviour
of the storage device. Of course, the number of cards being attached
is important too.

That said, enabling this feature (MMC_CAP_AGGRESSIVE_PM) needs to be
done by taking into account that being *too* aggressive (too
frequently) with turning off the power to the card, may cause a
potential wear-out/brake of the card if we end up preventing it from
doing internal house-keeping for too long.

The current default autosuspend timeout
(pm_runtime_set_autosuspend_delay()) is set to 3s in mmc_blk_probe().
That seems way too aggressive in my opinion, so perhaps increasing
that value to ~180s could allow us to enable this, even if 180s is
just a guesstimate from my side.

Also note that, during system wide suspend we always turn off the
power to the card - and we really don't know if that is too frequent
too. It depends on how the platform is used, compare a laptop with a
smartphone, the frequency greatly differs.

Kind regards
Uffe