Linux MultiMedia Card development
 help / color / mirror / Atom feed
From: Andrew Davis <afd@ti.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
	Yangtao Li <frank.li@vivo.com>, <linux-mmc@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mmc: pwrseq: Use proper reboot notifier path
Date: Thu, 1 Feb 2024 10:20:44 -0600	[thread overview]
Message-ID: <d81a060f-3d8f-44b2-8140-eb8e7ce35d93@ti.com> (raw)
In-Reply-To: <CAPDyKFpc38-CFrzhnhutS7c78tZTLM6Bg6XsTKENP8oVT6SQXg@mail.gmail.com>

On 1/30/24 6:04 AM, Ulf Hansson wrote:
> On Fri, 26 Jan 2024 at 20:01, Andrew Davis <afd@ti.com> wrote:
>>
>> This driver registers itself as a reboot handler, which means it claims
>> it can reboot the system. It does this so it is called during the system
>> reboot sequence. The correct way to be notified during the reboot
>> sequence is to register a notifier with register_reboot_notifier().
>> Do this here.
>>
>> Note this will be called during normal reboots but not emergency reboots.
>> This is the expected behavior, emergency reboot means emergency, not go
>> do some cleanup with emmc pins.. The reboot notifiers are intentionally
>> not called in the emergency path for a reason and working around that by
>> pretending to be a reboot handler is a hack.
> 
> I understand the reason for the $subject patch, but it will not work,
> unfortunately.
> 
> For eMMC we need to manage emergency reboots too. The fiddling with
> GPIOs isn't a "cleanup", but tries to move the eMMC into a clean reset
> state. 

That is by definition a "cleanup", even if the cleanup is really important.

> This is needed on some platforms with broken bootloaders (ROM
> code), that is expecting the eMMC to always start in a clean reset
> state.
> 

I understand the reason, I don't agree with the method used to get
the result.

> So, we need both parts, as was discussed here [1] too.
> 

In this thread I see a lot of discussion about the priority of the
handler. You want this to run before any real reboot handlers
are run. Luckily for you, all reboot "notifiers" are run before
any "handlers" are run. So if you register as a "notifier" as
this patch does, you will be run first, no super high priority
settings needed.

The real issue is you want to be called even in the
emergency_restart() path, which is fine. But from the
docs for that function this type of restart is done:

> Without shutting down any hardware 

So we have two options:

1. Add a new notifier list that *does* get called in the
    emergency_restart() path. Then register this driver with
    with that.

2. Remove emergency_restart() from the kernel. It only has a
    couple of callers, and most of those callers look like they
    should instead be using hw_protection_reboot() or panic().
    That way all reboot paths activate the reboot notifiers.
    Kinda wondering why you think you need to handle the
    emergency_restart() case at all, will even be a thing on
    your hardware, i.e. is this a real problem at all?

Having this driver claim to be a real reboot handler to sneak
around doing one of the above is preventing some cleanup I am
working on. So if either of the above two options work for you
just let me know, I'll help out in implementing them for you.

Thanks,
Andrew

> Kind regards
> Uffe
> 
> [1]
> https://lore.kernel.org/all/1445440540-21525-1-git-send-email-javier@osg.samsung.com/
> 
>>
>> Signed-off-by: Andrew Davis <afd@ti.com>
>> ---
>>   drivers/mmc/core/pwrseq_emmc.c | 8 +-------
>>   1 file changed, 1 insertion(+), 7 deletions(-)
>>
>> diff --git a/drivers/mmc/core/pwrseq_emmc.c b/drivers/mmc/core/pwrseq_emmc.c
>> index 3b6d69cefb4eb..d5045fd1a02c1 100644
>> --- a/drivers/mmc/core/pwrseq_emmc.c
>> +++ b/drivers/mmc/core/pwrseq_emmc.c
>> @@ -70,14 +70,8 @@ static int mmc_pwrseq_emmc_probe(struct platform_device *pdev)
>>                  return PTR_ERR(pwrseq->reset_gpio);
>>
>>          if (!gpiod_cansleep(pwrseq->reset_gpio)) {
>> -               /*
>> -                * register reset handler to ensure emmc reset also from
>> -                * emergency_reboot(), priority 255 is the highest priority
>> -                * so it will be executed before any system reboot handler.
>> -                */
>>                  pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb;
>> -               pwrseq->reset_nb.priority = 255;
>> -               register_restart_handler(&pwrseq->reset_nb);
>> +               register_reboot_notifier(&pwrseq->reset_nb);
>>          } else {
>>                  dev_notice(dev, "EMMC reset pin tied to a sleepy GPIO driver; reset on emergency-reboot disabled\n");
>>          }
>> --
>> 2.39.2
>>

  reply	other threads:[~2024-02-01 16:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20240126190119eucas1p28714f09cd2afe41087dcaceba9862a64@eucas1p2.samsung.com>
2024-01-26 19:01 ` [PATCH] mmc: pwrseq: Use proper reboot notifier path Andrew Davis
2024-01-30 12:04   ` Ulf Hansson
2024-02-01 16:20     ` Andrew Davis [this message]
2024-02-01 22:56       ` Ulf Hansson
2024-01-31  8:27   ` Marek Szyprowski

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=d81a060f-3d8f-44b2-8140-eb8e7ce35d93@ti.com \
    --to=afd@ti.com \
    --cc=frank.li@vivo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=ulf.hansson@linaro.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox