From mboxrd@z Thu Jan 1 00:00:00 1970 From: AKASHI Takahiro Date: Fri, 25 Jan 2019 17:27:26 +0900 Subject: [U-Boot] [PATCH v2 2/3] efi_loader: enumerate disk devices every time In-Reply-To: References: <20190110080216.GE20286@linaro.org> <20190110091608.GF20286@linaro.org> <35818CAD-AFCB-4A99-8BFD-276FA87BFBEE@suse.de> <20190111042926.GH20286@linaro.org> <5957d313-aa21-152d-18f2-d0a974b6b9da@suse.de> <20190122082957.GE20286@linaro.org> Message-ID: <20190125082724.GN20286@linaro.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.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 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 >