On 9/16/22 02:58, AKASHI Takahiro wrote:
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.)
This behavior matches what EDK II does if you remove a device and create
a new device.
If a device is removed and recreated anything could have happened in
between like complete repartitioning. We cannot assume that any cached
state is valid anymore even if GUIDs are the same.
So it is correct to change the media ID in this case.
Commands like scsi rescan are needed because we don't monitor media
changes in the DM drivers yet. Simon's suggestion to use provide an
event for media changes looks like the right approach to me.
Best regards
Heinrich
-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
