[PATCH v2 01/39] RFC: efi: Drop code that doesn't work with driver model

[Jan Kiszka]

On 14.10.22 17:33, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 14 Oct 2022 at 07:13, Tom Rini <trini at konsulko.com> wrote:
>>
>> On Fri, Oct 14, 2022 at 01:51:54PM +0200, Jan Kiszka wrote:
>>> On 21.10.21 01:34, Heinrich Schuchardt wrote:
>>>> On 9/25/21 2:30 AM, Simon Glass wrote:
>>>>> This code should never have been added as it builds a new feature on top
>>>>> of legacy code. This has already been improved with the dependency on
>>>>> BLK.
>>>>>
>>>>> Add a dependency on DM_ETH also, to avoid needing to deal with this old
>>>>> code.
>>>>>
>>>>> Boards which want EFI_LOADER should migrate to driver model first.
>>>>>
>>>>> Note this patch is included to resolve the following build error:
>>>>>
>>>>> lib/efi_loader/efi_runtime.c:680:16: error: ‘CONFIG_SYS_TEXT_BASE’
>>>>>     undeclared (first use in this function); did you mean
>>>>>     ‘CONFIG_SYS_SRAM_BASE’?
>>>>>    680 |   ulong base = CONFIG_SYS_TEXT_BASE;
>>>>>        |                ^~~~~~~~~~~~~~~~~~~~
>>>>>        |                CONFIG_SYS_SRAM_BASE
>>>>>
>>>>> Signed-off-by: Simon Glass <sjg at chromium.org>
>>>>
>>>> Reviewed-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
>>>>
>>>
>>> How to deal with boards that need CONFIG_NET but do not actually
>>> implement any driver (yet)? This now broke UEFI for the IOT2050 which
>>> needs NET for network-related device tree setup (see also [1]) and
>>> enforces a local hack for us.
>>
>> Yes, looking at the patch, this should probably use NETDEVICES and not
>> NET as the test? Would that fix your problem, Jan?
> 
> But that selects DM_ETH. You can still enable DM_ETH when there are no
> devices, so I'm not sure what the problem is. Can you post an error?
> 
> Things should be migrated to DM_ETH by now (end of 2020).
> 

I am enable DM_ETH now at board-level, just to make EFI_LOADER happy,
but that feels wrong.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux