Hi Simon,
On Thu, Jun 21, 2018 at 1:51 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 17 June 2018 at 06:57, Bin Meng bmeng.cn@gmail.com 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 bmeng.cn@gmail.com
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?
- 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?
- a function call into DM
Like uclass_first_device()?
- 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.
What do you think?
Regards, Bin