All of lore.kernel.org
 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 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.