[U-Boot] [PATCH v2 2/3] efi_loader: enumerate disk devices every time

[Alexander Graf]

On 25.01.19 09:27, AKASHI Takahiro wrote:
> Alex,
> 
> On Wed, Jan 23, 2019 at 10:51:29AM +0100, Alexander Graf wrote:
>> On 01/22/2019 08:39 PM, Simon Glass wrote:
>>> Hi Alex,
>>>
>>> On Tue, 22 Jan 2019 at 22:08, Alexander Graf <agraf at suse.de> wrote:
>>>>
>>>>
>>>> On 22.01.19 09:29, AKASHI Takahiro wrote:
>>>>> Alex, Simon,
>>>>>
>>>>> Apologies for my slow response on this matter,
>>>>>
>>>>> On Fri, Jan 11, 2019 at 08:57:05AM +0100, Alexander Graf wrote:
>>>>>>
>>>>>> On 11.01.19 05:29, AKASHI Takahiro wrote:
>>>>>>> Alex, Heinrich and Simon,
>>>>>>>
>>>>>>> Thank you for your comments, they are all valuable but also make me
>>>>>>> confused as different people have different requirements :)
>>>>>>> I'm not sure that all of us share the same *ultimate* goal here.
>>>>>> The shared ultimate goal is to "merge" (as Simon put it) dm and efi objects.
>>>>> I don't still understand what "merge" means very well.
>>>> It basically means that "struct efi_object" moves into "struct udevice".
>>>> Every udevice instance of type UCLASS_BLK would expose the block and
>>>> device_path protocols.
>>>>
>>>> This will be a slightly bigger rework, but eventually allows us to
>>>> basically get rid of efi_init_obj_list() I think.
>>> I envisaged something like:
>>>
>>> - EFI objects have their own UCLASS_EFI uclass
>>
>> ... and then we need to create our own sub object model around the
>> UCLASS_EFI devices again. I' not convinced that's a great idea yet :). I
>> really see little reason not to just expose every dm device as EFI handle.
>> Things would plug in quite naturally I think.
> 
> You said that the ultimate goal is to remove all efi_object data.
> Do you think that all the existing efi_object can be mapped to
> one of existing u-boot uclass devices?
> 
> If so, what would be an real entity of a UEFI handle?
> struct udevice *?
> 
> But Simon seems not to agree to adding any UEFI-specific members
> in struct udevice.

I think we'll have to experiment with both approaches. I personally
would like to have struct udevice * be the UEFI handle, yes.

> 
>> But either way, someone would need to sit down and prototype things to be
>> sure.
>>
> 
> The most simplest prototype would include
> * event mechanism (just registration and execution of hook/handler)
>     event: udevice creation (and deletion)
> * efi_disk hook for udevice(UCLASS_BLK) creation
> * modified block device's enumeration code, say, scsi_scan(),
>   to add an event hook at udevice creation
> * removing efi_disk_register() from efi_init_obj_list()
> * Optionally(?) UCLASS_PARTITION
>   (Partition udevices would be created in part_init().)

Almost.

The simplest prototype would be to add a struct efi_object into struct
udevice. Then whenever we're looping over efi_obj_list in the code, we
additionally loop over all udevices to find the handle.

Then, we could slowly give the uclasses explicit knowledge of uefi
protocols. So most of the logic of efi_disk_register() would move into
(or get called by) drivers/block/blk-uclass.c:blk_create_device().

Instead of creating diskobj and adding calling efi_add_handle(), we
could then just use existing data structure from the udevice (and its
platdata).


Does this make sense? Less events, more implicity :).

Alex