On Fri, Jun 22, 2018 at 3:45 AM, Simon Glass <[email protected]> wrote: > 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]> >
applied to u-boot-x86, thanks! _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
