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

[Simon Glass]

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.

>
> >
> >> 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