All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa+renesas@sang-engineering.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Avri Altman <Avri.Altman@sandisk.com>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
	"linux-renesas-soc@vger.kernel.org"
	<linux-renesas-soc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/5] mmc: core: Further avoid re-storing power to the eMMC before a shutdown
Date: Mon, 31 Mar 2025 12:46:22 +0200	[thread overview]
Message-ID: <Z-pyfv_7gJ72YWhz@shikoro> (raw)
In-Reply-To: <CAPDyKFr0MvQDxsi-Qd0F=1KuR4Gy6s5bhVdOXRt9K14Z9sO2Kw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2932 bytes --]

Hi Ulf,

> > > > +static bool mmc_may_poweroff_notify(const struct mmc_host *host,
> > > > +                               bool is_suspend)
> >
> > Maybe add some comments about the difference between
> > mmc_can_poweroff_notify() and mmc_may_poweroff_notify()? Like make it
> > super-obvious, so I will easily remember next year again :)
> 
> mmc_can_* functions are mostly about checking what the card is capable
> of. So mmc_can_poweroff_notify() should be consistent with the other
> similar functions.
> 
> For eMMC power-off notifications in particular, it has become more
> complicated as we need to check the power-off scenario along with the
> host's capabilities, to understand what we should do.
> 
> I am certainly open to another name than mmc_may_power_off_notify(),
> if that is what you are suggesting. Do you have a proposal? :-)

Initially, I didn't think of new names but some explanation in comments.
But since you are mentioning a rename now, how about:

mmc_card_can_poweroff_notify() and mmc_host_can_poweroff_notify()?

Similar to the commit 32f18e596141 ("mmc: improve API to make clear
hw_reset callback is for cards") where I renamed 'hw_reset' to
'card_hw_reset' for AFAICS similar reasons.

> > > >     if (mmc_can_poweroff_notify(host->card) &&
> > > > -           !(host->caps2 & MMC_CAP2_FULL_PWR_CYCLE))
> > > > +       !mmc_may_poweroff_notify(host, true))
> > > I guess this deserve some extra documentation because:
> > > If MMC_CAP2_FULL_PWR_CYCLE is not set but MMC_CAP2_FULL_PWR_CYCLE_IN_SUSPEND is set,
> > > !mmc_may_poweroff_notify(host, true) will evaluate to false while !(host->caps2 & MMC_CAP2_FULL_PWR_CYCLE) will evaluate to true.
> 
> Right. See more below.
> 
> >
> > I agree, I neither get this. Another way to express my confusion is: Why
> > do we set the 'is_suspend' flag to true in the shutdown function?
> >
> 
> I understand your concern and I agree that this is rather messy.
> Anyway, for shutdown, we set the is_suspend flag to false. The
> reasoning behind this is that during shutdown we know that the card
> will be fully powered-down (both vcc and vccq will be cut).
> 
> In suspend/runtime_suspend, we don't really know as it depends on what
> the platform/host is capable of. If we can't do a full power-off
> (maybe just vcc can be cut), then we prefer the sleep command instead.

I do understand that. I don't see why this needs a change in the
existing logic as Alan pointed out above.

> I was hoping that patch3 should make this more clear (using an enum

Sadly, it didn't. Using MMC_POWEROFF_SUSPEND first and then later
MMC_POWEROFF_SHUTDOWN in mmc_shutdown() is still confusing. Do you want
to return false in case none of the two PWR_CYCLE flags is set?

> type), but I can try to add some comment(s) in the code to further
> clarify the policy.

Please do.

All the best,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2025-03-31 10:46 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-20 14:00 [PATCH 0/5] mmc: core: Add support for graceful host removal for eMMC/SD Ulf Hansson
2025-03-20 14:00 ` [PATCH 1/5] mmc: core: Convert mmc_can_poweroff_notify() into a bool Ulf Hansson
2025-03-28 13:39   ` Avri Altman
2025-03-31  8:14   ` Wolfram Sang
2025-03-20 14:00 ` [PATCH 2/5] mmc: core: Further avoid re-storing power to the eMMC before a shutdown Ulf Hansson
2025-03-28 13:55   ` Avri Altman
2025-03-31  8:21     ` Wolfram Sang
2025-03-31  9:13       ` Ulf Hansson
2025-03-31 10:46         ` Wolfram Sang [this message]
2025-03-31 12:06           ` Ulf Hansson
2025-04-01  6:51             ` Wolfram Sang
2025-04-01 11:50               ` Ulf Hansson
2025-03-20 14:00 ` [PATCH 3/5] mmc: core: Convert into an enum for the poweroff-type for eMMC Ulf Hansson
2025-03-31  8:22   ` Wolfram Sang
2025-03-20 14:00 ` [PATCH 4/5] mmc: core: Add support for graceful host removal " Ulf Hansson
2025-03-28  8:13   ` Avri Altman
2025-03-28 10:21     ` Ulf Hansson
2025-03-31  8:27       ` Wolfram Sang
2025-03-31  8:23   ` Wolfram Sang
2025-03-20 14:00 ` [PATCH 5/5] mmc: core: Add support for graceful host removal for SD Ulf Hansson
2025-03-31  8:30   ` Wolfram Sang
2025-04-01  8:50     ` Wolfram Sang
2025-04-01  8:51       ` Wolfram Sang
2025-04-01 11:51         ` Ulf Hansson
2025-03-20 15:50 ` [PATCH 0/5] mmc: core: Add support for graceful host removal for eMMC/SD Wolfram Sang
2025-03-31  8:32   ` Wolfram Sang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z-pyfv_7gJ72YWhz@shikoro \
    --to=wsa+renesas@sang-engineering.com \
    --cc=Avri.Altman@sandisk.com \
    --cc=adrian.hunter@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=ulf.hansson@linaro.org \
    --cc=yoshihiro.shimoda.uh@renesas.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.