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

[Heinrich Schuchardt]

On 1/22/19 8: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
> - DM uclasses which support EFI would create a child EFI device (e.g.
> a UCLASS_EFI child of each UCLASS_BLK device)
> - EFI-uclass devices would thus be bound as needed
> - Probing an EFI device would causes its parents to be probed
> - We can use all the existing DM hooks (probe, remove, parent/child
> data, operations), to implement EFI things
> 
> I'm assuming that a small percentage of devices would have EFI
> children, so that this is more efficient than trying to merge the data
> structures. It also allows EFI to maintain some separate from the core
> DM code.

Dear Simon,

thanks to your suggestions.

I am not yet convinced that an UCLASS_EFI child device will be helpful.
It is not an EFI object.

A DM uclass is the equivalent to an EFI driver, i.e. a handle with the
EFI_DRIVER_BINDING_PROTOCOL installed on it [1]. So the natural thing
for a uclass supporting EFI would be to provide such a handle.

For the actual devices we also need handles.

In the EFI world partitions are devices. How does this fit into your
picture?

[1] https://lists.denx.de/pipermail/u-boot/2019-January/354359.html
[RFC] Device model for block devices - integration with EFI subsystem

Best regards

Heinrich

> 
>>
>>>
>>>> But we have this annoying interim state where we would lose a few boards
>>>> because they haven't been converted to DM. That's what keeps us from it.
>>>>
>>>> I think what this discussion boils down to is that someone needs to
>>>> start prototyping the DM/EFI integration. Start off with a simple
>>>> subsystem, like BLK.
>>>
>>> Even in the current implementation,
>>> * UEFI disk is implemented using UCLASS_BLK devices
>>>   (We can ignore !CONFIG_BLK case now as we have agreed.)
>>> * UEFI-specific block device can be seen as UCLASS_BLK/IF_TYPE_EFI
>>>
>>> So how essentially different is the *ultimate* goal from the current form
>>> regarding block devices?
>>
>> The ultimate goal is that efi_disk_register() and efi_obj_list disappear.
>>
>> Functionality wise we should be 100% identical to today, so all test
>> cases would still apply the same way as they do now. This is purely
>> internal rework, nothing visible to UEFI payloads.
> 
> Yes.
> 
>>
>>> In order to identify UEFI disks with u-boot devices transparently, we will
>>> have to have some sort of *hook* (or hotplug in Alex's language?), either
>>> in create_block_devices or bind/probe?  I don't know, but Simon seems
>>> to be in denial about this idea.
>>
>> Well, if a udevice *is* an efi device, we no longer need hooks. The
>> object list would simply change.
>>
>> We may still need to have event notifications at that stage, but that's
>> a different story.
> 
> Yes, it's something that I think will need to be added to DM. I
> haven't got to this as I have not run into an important use case yet.
> Maybe something like:
> 
> Controlled by CONFIG_EVENT
> 
> - int dev_ev_register(struct udevice *dev, enum event_t type,
> event_handler_func_t handler, void *userdata)
> 
> which calls handler(struct udevice *dev, void *userdata) when an event is fired
> 
> - int dev_ev_unregister() to unregister
> 
> - int dev_ev_send(struct udevice *dev, enum struct event_info *info)
> 
> which sends events to registered listeners.
> 
> struct event_info {
>   enum event_t type;
>   union {
>      struct ev_data_probed probed;
>      struct ev_data_removed removed;
>      ...
>  } d;
> };
> 
>>
>> As transitioning period, we could probably implement 2 efi object roots:
>> efi_obj_list as well as the udevice based one. Every piece of code that
>> iterates through devices then just iterates over both. That way we
>> should be able to slowly move devices from the old object model to the
>> new one.
> 
> Will the uclass I mentioned above you can iterate through UCLASS_EFI
> and thus you have a list of EFI devices.
> 
> [...]
> 
> Regards,
> Simon
>