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

[Tom Rini]

On Fri, Oct 14, 2022 at 05:47:55PM +0200, Jan Kiszka wrote:
> On 14.10.22 17:39, Tom Rini wrote:
> > On Fri, Oct 14, 2022 at 09:36:46AM -0600, Simon Glass wrote:
> >> Hi Jan,
> >>
> >> On Fri, 14 Oct 2022 at 09:35, Jan Kiszka <jan.kiszka at siemens.com> wrote:
> >>>
> >>> 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.
> >>
> >> I agree, but I wonder if this might need some code refactoring.
> >> Perhaps EFI_LOADER_NET needs to be created, net functionality can be
> >> disabled?
> > 
> > I think we should be able to leverage existing flags already for this
> > and not need a new one. The issue is that CONFIG_NET does not mean "we
> > have network devices" but CONFIG_NETDEVICES does.
> 
> So, you mean fixing up the efi-loader code to use CONFIG_NETDEVICES,
> rather than CONFIG_NET? Then we could drop that Kconfig check.

Yes.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20221014/de8cbf29/attachment.sig>