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

[Simon Glass]

Hi Alex,

On Wed, 23 Jan 2019 at 22:51, Alexander Graf <agraf at suse.de> 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.

I would like to keep some separation between EFI and DM data
structures. We can maintain a list of pointers or whatever is needed
for the protocol stuff.

I'm not convinced either way also, and agree that:

>
> But either way, someone would need to sit down and prototype things to
> be sure.

I think a reasonable starting point would be to create a PARTITION
uclass and rework things to deal with that.

>
>
> Alex
>

Regards,
Simon