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

[Bin Meng]

On Fri, Jun 22, 2018 at 3:45 AM, Simon Glass <sjg at chromium.org> wrote:
> 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>
>

applied to u-boot-x86, thanks!