All of lore.kernel.org
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 2/3] efi_loader: enumerate disk devices every time
Date: Fri, 25 Jan 2019 17:27:26 +0900	[thread overview]
Message-ID: <20190125082724.GN20286@linaro.org> (raw)
In-Reply-To: <ef02b4ae-16ee-62b8-8b1e-234d33686e6f@suse.de>

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

> 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().)

?

Thanks,
-Takahiro Akashi
> 
> Alex
> 

  parent reply	other threads:[~2019-01-25  8:27 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-15  4:58 [U-Boot] [PATCH v2 0/3] efi_loader: add removable device support AKASHI Takahiro
2018-11-15  4:58 ` [U-Boot] [PATCH v2 1/3] efi_loader: export efi_locate_handle() function AKASHI Takahiro
2018-11-15  4:58 ` [U-Boot] [PATCH v2 2/3] efi_loader: enumerate disk devices every time AKASHI Takahiro
2018-12-11 19:55   ` Heinrich Schuchardt
2018-12-13  7:58     ` AKASHI Takahiro
2019-01-09  1:05       ` AKASHI Takahiro
2019-01-09  9:06       ` Alexander Graf
2019-01-10  2:13         ` AKASHI Takahiro
2019-01-10  6:21           ` Alexander Graf
2019-01-10  7:26             ` AKASHI Takahiro
2019-01-10  7:30               ` Alexander Graf
2019-01-10  8:02                 ` AKASHI Takahiro
2019-01-10  8:15                   ` Alexander Graf
2019-01-10  9:16                     ` AKASHI Takahiro
2019-01-10  9:22                       ` Alexander Graf
2019-01-10 19:22                         ` Heinrich Schuchardt
2019-01-11  5:08                           ` AKASHI Takahiro
2019-01-11  4:29                         ` AKASHI Takahiro
2019-01-11  7:57                           ` Alexander Graf
2019-01-12 21:32                             ` Simon Glass
2019-01-12 22:00                               ` Alexander Graf
2019-01-16 21:34                                 ` Simon Glass
2019-01-22  8:29                             ` AKASHI Takahiro
2019-01-22  9:08                               ` Alexander Graf
2019-01-22 19:39                                 ` Simon Glass
2019-01-22 21:04                                   ` Heinrich Schuchardt
2019-01-23  8:06                                     ` AKASHI Takahiro
2019-01-23 21:58                                     ` Simon Glass
2019-01-24  0:53                                       ` AKASHI Takahiro
2019-01-24 20:18                                         ` Simon Glass
2019-01-24 21:19                                           ` Heinrich Schuchardt
2019-01-25  2:27                                             ` AKASHI Takahiro
2019-01-23  9:51                                   ` Alexander Graf
2019-01-23 22:01                                     ` Simon Glass
2019-01-25  8:27                                     ` AKASHI Takahiro [this message]
2019-01-25  8:52                                       ` Alexander Graf
2019-01-25  9:18                                         ` AKASHI Takahiro
2019-01-25  9:31                                           ` Alexander Graf
2019-01-28  8:56                                             ` AKASHI Takahiro
2019-01-28  9:36                                               ` Alexander Graf
2019-01-29  0:46                                               ` Simon Glass
2019-01-29  1:22                                                 ` AKASHI Takahiro
2019-01-23  8:12                                 ` AKASHI Takahiro
2019-01-23  9:30                                   ` Alexander Graf
2019-01-10 12:57         ` Simon Glass
2019-01-11  4:51           ` AKASHI Takahiro
2019-01-11  8:00             ` Alexander Graf
2019-01-11 13:03               ` Mark Kettenis
2018-11-15  4:58 ` [U-Boot] [PATCH v2 3/3] efi_loader: remove block device details from efi file AKASHI Takahiro
2019-01-09  9:18   ` Alexander Graf
2019-01-10  0:37     ` AKASHI Takahiro
2019-01-10  6:22       ` Alexander Graf
2019-01-10  6:36         ` AKASHI Takahiro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190125082724.GN20286@linaro.org \
    --to=takahiro.akashi@linaro.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.