[U-Boot] [PATCH 4/5] x86: efi-x86_payload: Enumerate PCI bus during early boot

[Simon Glass]

Hi Bin,

On 21 June 2018 at 05:19, Bin Meng <bmeng.cn at gmail.com> wrote:
> Hi Simon,
>
> On Thu, Jun 21, 2018 at 1:51 AM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Bin,
>>
>> On 17 June 2018 at 06:57, Bin Meng <bmeng.cn at 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 at 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?

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 <sjg at chromium.org>

Regards,
Simon