
Heinrich,
On Tue, Jan 29, 2019 at 11:48:37PM +0100, Heinrich Schuchardt wrote:
On 1/29/19 5:20 PM, Alexander Graf wrote:
On 01/29/2019 03:59 AM, AKASHI Takahiro wrote:
This patch set came from the past discussion[1] on my "removable device support" patch and is intended to be an attempt to integrate efi_disk (more precisely, EFI_BLOCK_IO_PROTOCOL-capable efi object) into u-boot's Driver Model as much seamlessly as possible
[1] https://lists.denx.de/pipermail/u-boot/2019-January/354010.html
Basic idea is
- create UCLASS_PARTITION
- enumerate all the partitions when a block device is probed
- hook up a creation of UCLASS_BLK or UCLASS_PARTITION device
to efi handler for efi_disk attributes to be properly set up
Since this patch is a prototype (or POC, proof-of-concept), the aim here is to discuss further about how in a better shape we will be able to merge the two worlds.
I like the approach. It seems pretty clean and gives us a smooth transition from the split world to a unified all-dm world. Eventually the efi object list will just naturally disappear and we can drop all calls to add efi object handles.
Alex
Thanks Takahiro, it is good to have a reference to work on to bring the worlds together.
I still have some issues:
The implementation lacks the driver binding protocol to handle block devices that are not discovered by U-Boot but supplied by an EFI driver or application. I would prefer if the block uclass would provide this protocol.
I don't yet have deep understandings of DM, but I believe that any UCLASS_BLK instance should have a backing block device, blk_desc, which is pointed to by uclass_platdata. But your efi block device, UCLASS_BLK/IF_TYPE_EFI, does never initialize this structure, in particular "ops," and so it won't work as a block device on u-boot side.
I guess that it is one of reasons that EFI block driver doesn't work with my patch.
If you agree with me, it would be much easier for you to modify EFI block driver :)
In EFI a handle can always be deleted by first stopping all controllers and then removing all protocols.
What do you mean by "delete?" Some efi object will directly use efi_add_handle(). Efi object is solely responsible for maintaining a handle.
The current implementation of partitions tries to use a struct efi_obj instead of a handle. This is incompatible to the rest of the EFI subsystem.
How incompatible? A handle is always a pointer to opaque data outside the implementation. struct efi_obj in blk_desc is explicitly handled only in efi_disk.c. What's wrong with that?
-Takahiro Akashi
Best regards
Heinrich