[U-Boot] [RFC 2/3] efi_loader: associate BLK/PARTITION device to efi_disk

[Simon Glass]

Hi AKASHI,

On Mon, 28 Jan 2019 at 19:59, AKASHI Takahiro
<takahiro.akashi at linaro.org> wrote:
>
> efi_disk_create() will initialize efi_disk attributes for each device,
> either UCLASS_BLK or UCLASS_PARTITION.
>
> Currently (temporarily), efi_disk_obj structure is embedded into
> blk_desc to hold efi-specific attributes.
>
> Signed-off-by: AKASHI Takahiro <takahiro.akashi at linaro.org>
> ---
>  drivers/block/blk-uclass.c |   9 ++
>  drivers/core/device.c      |   3 +
>  include/blk.h              |  24 +++++
>  include/dm/device.h        |   4 +
>  lib/efi_loader/efi_disk.c  | 192 ++++++++++++++++++++++++++-----------
>  5 files changed, 174 insertions(+), 58 deletions(-)
>

I think the objective should be to drop the EFI data structures.

So your approach of just including them in DM structures seems about
right to me, as a short-term migration measure. Given the large amount
of code that has built up I don't think it is possible to do it any
other way.

It is very unfortunate though.

So basically migration could be something like this:

1. Move each of the EFI structs into the DM structs one by one
2. Drop struct members that are not needed and can be calculated from DM members
3. Update DM to have 1:1 uclasses for each EFI protocol
4. Move all the protocol structs into the DM uclasses
5. Whittle these down until they are just shells used by the API, with
everything going through normal DM calls

Or would it be better to just start again and rewrite it with the
existing code as a base?

Looking at it, efi_object is not very useful in DM. It contains two members:

1. link - linked list link, which devices already have, although we
don't have a single list of all them. Instead they are linked into
separate lists for each uclass

2. protocols - list of protocols. But DM devices support only one
protocol. Multiple protocols are handled using child devices. E.g a
UCLASS_PMIC device that supports UCLASS_GPIO, UCLASS_REGULATOR and
UCLASS_AUDIO_CODEC would have three children, one for each uclass. So
perhaps with EFI we should create a separate child for each protocol
in a similar way?

Which comes back to the idea of creating an EFI child device for every
DM device. Perhaps instead we create one EFI child for each protocol
supported by the parent device?

Another point is that the operations supported by EFI should be in DM
operations structs. For example I think struct
efi_simple_text_output_protocol should have methods which call into
the corresponding uclass operations.

It is confusing that an EFI disk is in fact a partition. Or do I have
that wrong?

Anyway that's all the thoughts I have at present. Thanks for your
efforts on this.

Regards,
Simon