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.kis...@siemens.com> wrote: >>> >>> On 14.10.22 17:33, Simon Glass wrote: >>>> Hi Tom, >>>> >>>> On Fri, 14 Oct 2022 at 07:13, Tom Rini <tr...@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 <s...@chromium.org> >>>>>>> >>>>>>> Reviewed-by: Heinrich Schuchardt <xypron.g...@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. Jan -- Siemens AG, Technology Competence Center Embedded Linux
