All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: u-boot@lists.denx.de,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Simon Glass <sjg@chromium.org>
Subject: Re: [PATCH] efi: Call bootm_disable_interrupts earlier in efi_exit_boot_services
Date: Fri, 19 Nov 2021 17:09:51 -0500	[thread overview]
Message-ID: <20211119220951.GL24579@bill-the-cat> (raw)
In-Reply-To: <DCCCCDA4-6E52-48E5-A81A-38200006FAE3@gmx.de>

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

On Fri, Nov 19, 2021 at 10:52:27PM +0100, Heinrich Schuchardt wrote:
> 
> 
> Am 19. November 2021 22:33:04 MEZ schrieb Tom Rini <trini@konsulko.com>:
> >If we look at the path that bootm/booti take when preparing to boot the
> >OS, we see that as part of (or prior to calling do_bootm_states,
> >explicitly) the process, bootm_disable_interrupts() is called prior to
> >announce_and_cleanup() which is where udc_disconnect() /
> >board_quiesce_devices() / dm_remove_devices_flags() are called from.  In
> >the EFI path, these are called afterwards.  In efi_exit_boot_services()
> >however we have been calling bootm_disable_interrupts() after the above
> >functions, as part of ensuring that we disable interrupts as required
> >by the spec.  However, bootm_disable_interrupts() is also where we go
> >and call usb_stop().  While this has been fine before, on the TI J721E
> >platform this leads us to an exception.  This exception seems likely to
> >be the case that we're trying to stop devices that we have already
> >disabled clocks for.  The most direct way to handle this particular
> 
> This patch may hide an error on your board but obviously does not address the real problem.
> 
> If dependencies in the shut down sequence should exist, we need to consider them in the driver model.
> 
> What is your plan to analyze the problem?

I'm not sure there is a different problem to solve here.  It's unsafe to
call the "shut everything down" function, which is what usb_stop() is,
after having shut everything down.  We may be able to stop calling
usb_stop() as any sort of shutdown should already have happened via
driver model, which is what we see now.

-- 
Tom

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

  reply	other threads:[~2021-11-19 22:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-19 21:33 [PATCH] efi: Call bootm_disable_interrupts earlier in efi_exit_boot_services Tom Rini
2021-11-19 21:52 ` Heinrich Schuchardt
2021-11-19 22:09   ` Tom Rini [this message]
2021-11-20  8:20     ` Ilias Apalodimas
2021-11-20 11:11       ` Mark Kettenis

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=20211119220951.GL24579@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.de \
    /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.