Hi Bin, On 21 June 2018 at 05:19, Bin Meng <[email protected]> wrote: > Hi Simon, > > On Thu, Jun 21, 2018 at 1:51 AM, Simon Glass <[email protected]> wrote: >> Hi Bin, >> >> On 17 June 2018 at 06:57, Bin Meng <[email protected]> wrote: >>> The generic efi payload currently does not enumerate the PCI bus, >>> which means peripherals on the PCI bus are not discovered by their >>> drivers. This uses board_early_init_r() to do the PCI enumeration. >>> >>> Signed-off-by: Bin Meng <[email protected]> >>> --- >>> >>> board/efi/efi-x86_payload/Kconfig | 1 + >>> board/efi/efi-x86_payload/Makefile | 2 +- >>> board/efi/efi-x86_payload/payload.c | 18 ++++++++++++++++++ >>> 3 files changed, 20 insertions(+), 1 deletion(-) >>> create mode 100644 board/efi/efi-x86_payload/payload.c >> >> I would like to consider adding a mechanism to indicate that a uclass >> should be inited (and its devices probed) on startup. This would be >> used for things which provide essential peripherals, which otherwise >> would not be visible in the initial driver-model bind process. >> > > Good to know! > >> I am not sure whether this should be: >> >> - a flag in the uclass > > Only adding a flag to the uclass driver seems not working. On some > systems like x86 UCLASS_PCI may be init at boot up, but on other > systems this might not be the case. So we need find a place to tell DM > to init the uclass driver if the uclass driver has the flag, but > where?
Yes I figured. Let's drop this idea. > >> - a flag in the BOARD driver (assuming we have a BOARD uclass soon) > > The concept of BOARD driver sounds interesting. So does the BOARD > uclass driver intend to replace various config options like > CONFIG_BOARD_EARLY_INIT_F, CONFIG_BOARD_EARLY_INIT_R, > CONFIG_BOARD_LATE_INIT, etc? If we do that, how do we guarantee the > init order with other components in board_f.c and board_r.c? That's a separate issue, but we could certainly ensure that after all devices are bound, we probe things like PCI, which would bind its devices. > >> - a function call into DM > > Like uclass_first_device()? That's what we have today. I was more thinking of something that tells DM (at the start) which uclasses should be probed. E.g. uclass_set_auto_probe(UCLASS_PCI, true); > >> - something else >> >> But I think it is justified in the case of PCI, since some systems >> cannot find all their devices without scanning it. >> > > Yes, this makes sense for PCI on x86. Anyway the patch is fine, but if you want to try something like the above, please go ahead. Reviewed-by: Simon Glass <[email protected]> Regards, Simon _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
