public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Heinrich Schuchardt <xypron.glpk@gmx.de>
To: Simon Glass <sjg@chromium.org>
Cc: Janne Grunau <j@jannau.net>,
	kettenis@openbsd.org, trini@konsulko.com,
	ilias.apalodimas@linaro.org, u-boot@lists.denx.de,
	Mark Kettenis <mark.kettenis@xs4all.nl>
Subject: Re: [PATCH 2/2] efi_loader: remove non vital devices first
Date: Wed, 13 Nov 2024 16:17:23 +0100	[thread overview]
Message-ID: <5FA71CBD-F9AF-442A-8564-4F663F44BF42@gmx.de> (raw)
In-Reply-To: <CAFLszTjDaQGaaL9qM_s+oxNrAkGhunGkbAjyR1giEDgnShUfzw@mail.gmail.com>

Am 13. November 2024 15:39:22 MEZ schrieb Simon Glass <sjg@chromium.org>:
>Hi,
>
>On Wed, 13 Nov 2024 at 05:52, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>
>> On 11/1/24 21:29, Mark Kettenis wrote:
>> >> From: Janne Grunau <j@jannau.net>
>> >> Date: Thu, 31 Oct 2024 23:48:02 +0100
>> >>
>> >> DM_FLAG_VITAL marks devices which are essential for the operation of
>> >> other devices. Removing these devices before their users can result in
>> >> hangs or crashes.
>> >> This potentially fixes EFI boot of Renesas rcar3 devices. Their clock
>> >> devices (and with this series the dart iommu) are the only devices
>> >> markes as vital.
>> >> The arm boot code already handles devioce removal in this way.
>> >
>> > There is a typo in that last sentence of the commit message (devioce).
>> > Otherwise:
>> >
>> >> Signed-off-by: Janne Grunau <j@jannau.net>
>> >
>> > Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
>> >
>> >> ---
>> >>   lib/efi_loader/efi_boottime.c | 1 +
>> >>   1 file changed, 1 insertion(+)
>> >>
>> >> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>> >> index 4f52284b4c653c252b0ed6c0c87da8901448d4b4..7db3c95782970f8c06a970a8ee86b1804cd848b6 100644
>> >> --- a/lib/efi_loader/efi_boottime.c
>> >> +++ b/lib/efi_loader/efi_boottime.c
>> >> @@ -2234,6 +2234,7 @@ static efi_status_t EFIAPI efi_exit_boot_services(efi_handle_t image_handle,
>> >>              if (IS_ENABLED(CONFIG_USB_DEVICE))
>> >>                      udc_disconnect();
>> >>              board_quiesce_devices();
>> >> +            dm_remove_devices_flags(DM_REMOVE_ACTIVE_ALL | DM_REMOVE_NON_VITAL);
>> >>              dm_remove_devices_flags(DM_REMOVE_ACTIVE_ALL);
>>
>> Simon's patch 6224dc9ba428 ("arm: Remove vital devices last") addressed
>> the same issue for bootm on arm. But what about about other architectures?
>>
>> This logic should be moved to drivers/core/root.c instead of replicating
>> code.
>
>We could have a common helper, but it should not be in driver/core as
>this ordering is more of a policy decision. Unless we can add a
>parameter telling dm exactly what to do...
>
>BTW, Heinrich, this behaviour is exactly what my bootflow_efi() test
>was supposed to check. But since it doesn't have the
>exit-boot-services piece at your request...
>
>Regards,
>Simon


Why can't we generally remove non-vital devices first if all are to be removed?

I cannot see anything device specific here.

Best regards

Heinrich


  reply	other threads:[~2024-11-13 15:17 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-31 22:48 [PATCH 0/2] Fix device removal order for Apple dart iommu Janne Grunau
2024-10-31 22:48 ` [PATCH 1/2] iommu: apple: Mark device with DM_FLAG_VITAL Janne Grunau
2024-11-01  7:12   ` Heinrich Schuchardt
2024-11-01  7:12   ` Heinrich Schuchardt
2024-11-01 20:28   ` Mark Kettenis
2024-10-31 22:48 ` [PATCH 2/2] efi_loader: remove non vital devices first Janne Grunau
2024-11-01 20:29   ` Mark Kettenis
2024-11-13 12:47     ` Heinrich Schuchardt
2024-11-13 14:39       ` Simon Glass
2024-11-13 15:17         ` Heinrich Schuchardt [this message]
2024-11-13 16:03           ` Simon Glass
2024-11-13 18:45             ` Heinrich Schuchardt
2024-11-14  3:53               ` Simon Glass
2024-11-14 14:26                 ` Tom Rini
2024-11-14 17:52                   ` Simon Glass
2024-11-13 15:57         ` Mark Kettenis
2024-11-01  6:22 ` [PATCH 0/2] Fix device removal order for Apple dart iommu Sughosh Ganu
2024-11-01  8:09   ` Janne Grunau
2024-11-21  7:39 ` Janne Grunau
2024-11-22  1:30   ` Tom Rini

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=5FA71CBD-F9AF-442A-8564-4F663F44BF42@gmx.de \
    --to=xypron.glpk@gmx.de \
    --cc=ilias.apalodimas@linaro.org \
    --cc=j@jannau.net \
    --cc=kettenis@openbsd.org \
    --cc=mark.kettenis@xs4all.nl \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox