From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Cc: Simon Glass <sjg@chromium.org>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Masahisa Kojima <masahisa.kojima@linaro.org>,
u-boot@lists.denx.de
Subject: Re: [PATCH 0/2] efi_loader: provide media ID
Date: Fri, 16 Sep 2022 09:58:05 +0900 [thread overview]
Message-ID: <20220916005805.GA45676@laputa> (raw)
In-Reply-To: <20220915200242.18358-1-heinrich.schuchardt@canonical.com>
On Thu, Sep 15, 2022 at 10:02:40PM +0200, Heinrich Schuchardt wrote:
> The medium a device like 'mmc 0' or 'usb 0' points to may change over
> time. Hence device type and number are not sufficient to identify the
> inserted medium. The same is true for the device path generated for
> such a device.
Well, it depends on how a device path is generated in U-Boot's UEFI
implementation. I believe that a device path represents an "unique path"
to a given device however this device is enumerated.
In this sense, the current dp_fill()/efi_dp_from_part() is not a right
implementation as it relies on device numbers.
Furthermore, a generated device path here is different from one generated
by EDK2 (even if both software are run on the same board).
This is an issue that I used to tackle in
https://lists.denx.de/pipermail/u-boot/2021-November/468216.html
although I have since had no progress.
> This is why the EFI_BLOCK_IO_PROTOCOL provides a field
> MediaId.
>
> Whenever a removable medium is changed or a new block device with a
> previously used device path is created we should provide a different
> MediaID.
>
> This series adds a field media_id to the block device descriptor and fills
> it after probing. The value of the field is then copied to the
> EFI_BLOCK_IO_PROTOCOL.
I'm afraid that your patch doesn't always work as you expect.
When "scsi rescan" or "usb stop; usb start", for instance, is invoked,
all the existing devices and associated blk_desc structures are once freed
and even if nothing is changed, i.e. a device is neither removed nor added,
the exact same structures will be re-created.
With your patch applied, however, a new (and different) "media_id" will be
assigned to an existing device. UEFI User may be notified of "media change".
(To be honest, this is quite unlikely because the current UEFI implementation
doesn't use BLOCK_IO_PROTOCOL internally, say, for file system access.)
-Takahiro Akashi
> With future patches we can refine this in sub-systems like USB, MMC, SCSI
> to indicate media changes
>
> Heinrich Schuchardt (2):
> dm: blk: assign media ID to block devices
> efi_loader: fill media_id from block device descriptor
>
> drivers/block/blk-uclass.c | 16 +++++++++++++++-
> include/blk.h | 11 +++++++++++
> lib/efi_loader/efi_disk.c | 6 +-----
> 3 files changed, 27 insertions(+), 6 deletions(-)
>
> --
> 2.37.2
>
next prev parent reply other threads:[~2022-09-16 0:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-15 20:02 [PATCH 0/2] efi_loader: provide media ID Heinrich Schuchardt
2022-09-15 20:02 ` [PATCH 1/2] dm: blk: assign media ID to block devices Heinrich Schuchardt
2022-09-16 1:30 ` Simon Glass
2022-09-16 6:41 ` Heinrich Schuchardt
2022-09-16 20:29 ` Simon Glass
2022-09-15 20:02 ` [PATCH 2/2] efi_loader: fill media_id from block device descriptor Heinrich Schuchardt
2022-09-23 7:07 ` Ilias Apalodimas
2022-09-25 14:15 ` Simon Glass
2022-09-26 0:05 ` AKASHI Takahiro
2022-09-16 0:58 ` AKASHI Takahiro [this message]
2022-09-26 6:06 ` [PATCH 0/2] efi_loader: provide media ID Heinrich Schuchardt
2022-09-27 1:51 ` AKASHI Takahiro
2022-09-27 6:53 ` Heinrich Schuchardt
2022-09-28 1:54 ` Simon Glass
2022-09-28 6:57 ` Heinrich Schuchardt
2022-09-28 7:24 ` AKASHI Takahiro
2022-09-28 16:27 ` Simon Glass
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=20220916005805.GA45676@laputa \
--to=takahiro.akashi@linaro.org \
--cc=heinrich.schuchardt@canonical.com \
--cc=ilias.apalodimas@linaro.org \
--cc=masahisa.kojima@linaro.org \
--cc=sjg@chromium.org \
--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.