On 1/22/19 8:39 PM, Simon Glass wrote: > Hi Alex, > > On Tue, 22 Jan 2019 at 22:08, Alexander Graf <ag...@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.
Dear Simon, thanks to your suggestions. I am not yet convinced that an UCLASS_EFI child device will be helpful. It is not an EFI object. A DM uclass is the equivalent to an EFI driver, i.e. a handle with the EFI_DRIVER_BINDING_PROTOCOL installed on it [1]. So the natural thing for a uclass supporting EFI would be to provide such a handle. For the actual devices we also need handles. In the EFI world partitions are devices. How does this fit into your picture? [1] https://lists.denx.de/pipermail/u-boot/2019-January/354359.html [RFC] Device model for block devices - integration with EFI subsystem Best regards Heinrich > >> >>> >>>> 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 > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
