On Mon, Oct 04, 2021 at 09:07:35PM +0300, Ilias Apalodimas wrote:
On Mon, Oct 04, 2021 at 04:47:53PM +0200, Heinrich Schuchardt wrote:
[...]
My approach in this RFC:
Due to functional differences in semantics, it would be difficult to identify "udevice" structure as a handle in UEFI world. Instead, we will have to somehow maintain a relationship between a udevice and a handle.
1-1. add a dedicated uclass, UCLASS_PARTITION, for partitions Currently, the uclass for paritions is not a UCLASS_BLK. It can be possible to define partitions as UCLASS_BLK (with IF_TYPE_PARTION?), but I'm afraid that it may introduce some chaos since udevice(UCLASS_BLK) is tightly coupled with 'struct blk_desc' data which is still used as a "structure to a whole disk" in a lot of interfaces. (I hope that you understand what it means.)
I think it makes more sense the way it's currently defined. I don;t see a point in hiding partitions within UCLASS_BLK
Yeah. But even with my UCLASS_PARTITION, it provides block-level io's through blk_read/blk_write() APIs. So someone may wonder why two different type of udevices have the same interfaces :)
In DM tree, a UCLASS_PARTITON instance has a UCLASS_BLK parent: For instance, UCLASS_SCSI --- UCLASS_BLK --- UCLASS_PARTITION (IF_TYPE_SCSI) | +- struct blk_desc +- struct disk_part +- scsi_blk_ops +- blk_part_ops1-2. create partition udevices in the context of device_probe() part_init() is already called in blk_post_probe(). See the commit d0851c893706 ("blk: Call part_init() in the post_probe() method"). Why not enumelate partitions as well in there.
- add new block access interfaces, which takes "udevice" as a target device, in U-Boot and use those functions to implement efi_disk operations (i.e. EFI_BLOCK_IO_PROTOCOL).
3-1. maintain a bi-directional link by adding - a UEFI handle pointer in "struct udevice" - a udevice pointer in UEFI handle (in fact, in "struct efi_disk_obj")
An EFI application can create handles with any combination of protocols, e.g. a handle with both the block IO protocol and the simple network protocol. This means that a udevice cannot be assigned to a handle created by an EFI application.
When the EFI application calls ConnectController() for the handle, U-Boot can create child controllers. If U-Boot creates a udevice for such a child controller, it has to store the udevice pointer. lib/efi_driver/efi_block_device.c uses a private data section but you it could be preferable to use a field in struct efi_obj.
I agree with Heinrich here. Basically U-Boot has to be in charge of that. Once ConnectController has been called U-Boot should create an 1:1 mapping between udevice <-> handle and shouldn't be allowed to change that.
Again, are you sure you're talking about the implementation of efi_disk for U-Boot's block device (the path(1) in my previous reply to Heinrich)?
-Takahiro Akashi
3-2. use device model's post_probe/pre_remove hook to synchronize the lifetime of efi_disk objects in UEFI world with the device model.
- I have no answer to issue(4) and (5) yet.
- A udevice shall only exist for the child controller handle created by
U-Boot and not for the controller handle created by an EFI application.
- The stop() method of the driver binding protocol has to take care of
destroying the child controllers and the associated udevices.
Best regards
Heinrich
Thanks /Ilias