u-boot.git/drivers/net/Kconfig, branch v2025.01

Merge a patch series to improve dc2114x support

2024-10-27T23:04:02Z

This patch series by Hanyuan Zhao provides a number of improvements to the dc2114x driver. Link: https://lore.kernel.org/r/tencent_BD4B002FC63A5F77969D9BD1FFF125371C08@qq.com

Merge patch series "net: ksz9477: add support for KSZ GbE switches using SPI bus"

2024-10-27T23:03:40Z

Romain Naour says: We are using a custom board where an ethernet switch device KSZ9896 is available. This family of devices can use several types of serial bus as management interface: mdio, i2c or SPI. Due to board design constraints and because we initially planned to use this device only from Linux, the SPI bus was used. Luckily we are using a recent enough u-boot release where KSZ9477 driver is available... but only for the i2c interface. Indeed, unlike the kernel driver, the KSZ9477 driver doesn't use the regmap API to access the underlying bus since the regmap API is limited to direct memory access [1]. Until regmap API with bus support is available in U-boot, we introduced struct ksz_phy_ops to store low-level ksz bus operations (I2C or SPI). This series has been tested on the current master branch (after v2024.10 release). [1] https://source.denx.de/u-boot/u-boot/-/blob/v2024.10-rc5/drivers/core/Kconfig?ref_type=tags#L188 Link: https://lore.kernel.org/r/20241008075435.1572727-1-romain.naour@smile.fr

net: ksz9477: add support for KSZ GbE switches using SPI bus

2024-10-27T16:19:44Z

The Microchip KSZ Gigabit Ethernet Switches support SGMII/RGMII/MII/RMII with register access via SPI, I2C, or MDIO. Since this driver is now able to check the underlying bus type, handle the case when the SPI bus is used. The SPI bus is only used for 8/16/32 wide access of registers. Reword Kconfig option to include SPI bus support. Signed-off-by: Romain Naour

net: dc2114x: allow users to decide how to tx packets according to IP core

2024-10-27T16:15:29Z

Some IP cores of dc2114x or its variants do not comply so well with the behaviors described by the official document. Originally this driver uses only one tx descriptor and organizes it as a ring buffer, which would lead to a problem that one packet would be sent twice. This commit adds support to prevent this bug if you are using IP cores with this issue, by using multiple tx descriptors and organizing them as a real well-defined ring buffer. Signed-off-by: Hanyuan Zhao

net: dc2114x: allow users to decide whether to detect the tx No Carrier errors

2024-10-27T16:15:29Z

Some IP cores of dc2114x or its variants do not comply so well with the behaviors described by the official document. A packet could be sent successfully but reported with No Carrier error. Latest drivers of this IP core have not detect this error anymore. Signed-off-by: Hanyuan Zhao

net: dc2114x: add support for platforms that don't have pci controllers

2024-10-27T16:15:29Z

There're a few ethernet IP cores which have the same functions with dc2114x, and can be connected to CPU by AXI or other buses. This commit adds support for the platforms that do not have PCI controllers, using MMIO to communicate with the dc2114x IP core. Signed-off-by: Hanyuan Zhao

net: lwip: add DHCP support and dhcp commmand

2024-10-16T17:11:56Z

Add what it takes to enable NETDEVICES with NET_LWIP and enable DHCP as well as the dhcp command. CMD_TFTPBOOT is selected by BOOTMETH_EFI due to this code having an implicit dependency on do_tftpb(). Note that PXE is likely non-fonctional with NET_LWIP (or at least not 100% functional) because DHCP option 209 is not supported by the lwIP library. Therefore, BOOTP_PXE_DHCP_OPTION cannot be enabled. Signed-off-by: Jerome Forissier Tested-by: Ilias Apalodimas Acked-by: Ilias Apalodimas

net: introduce alternative implementation as net/lwip/

2024-10-16T17:11:56Z

Prepare the introduction of the lwIP (lightweight IP) TCP/IP stack by adding a new net/lwip/ directory and the NET_LWIP symbol. Network support is either NO_NET, NET (legacy stack) or NET_LWIP. Subsequent commits will introduce the lwIP code, re-work the NETDEVICE integration and port some of the NET commands and features to lwIP. SPL_NET cannot be enabled when NET_LWIP=y. SPL_NET pulls some symbols that are part of NET (such as arp_init(), arp_timeout_check(), arp_receive(), net_arp_wait_packet_ip()). lwIP support in SPL may be added later. Similarly, DFU_TFTP and FASTBOOT are not compatible with NET_LWIP because of dependencies on net_loop(), tftp_timeout_ms, tftp_timeout_count_max and other NET things. Let's add a dependency on !NET_LWIP for now. SANDBOX can select NET_LWIP but doing so will currently disable the eth dm tests as well as the wget tests which have strong dependencies on the NET code. Other adjustments to Kconfig files are made to fix "unmet direct dependencies detected" for USB_FUNCTION_SDP and CMD_FASTBOOT when the default networking stack is set to NET_LWIP ("default NET_LWIP" instead of "default NET" in Kconfig). The networking stack is now a choice between NO_NET, NET and NET_LWIP. Therefore '# CONFIG_NET is not set' should be 'CONFIG_NO_NET=y'. Adjust the defconfigs accordingly. Signed-off-by: Jerome Forissier Acked-by: Ilias Apalodimas

sandbox: add dummy driver ETH_SANDBOX_LWIP

2024-10-16T17:11:56Z

Introduce ETH_SANDBOX_LWIP which enables a mock driver similar to ETH_SANDOX but without the dependencies on the legacy network stack (NET) so that it may be enabled when the lwIP stack (NET_LWIP) is introduced. The driver does nothing at this stage but its presence will allow dm_test_iommu_noiommu [1] to pass. [1] ./u-boot -T -c "ut dm dm_test_iommu_noiommu" Signed-off-by: Jerome Forissier Acked-by: Ilias Apalodimas Reviewed-by: Simon Glass

Merge patch series "Tidy up use of 'SPL' and CONFIG_SPL_BUILD"

2024-10-11T18:23:25Z

Simon Glass says: When the SPL build-phase was first created it was designed to solve a particular problem (the need to init SDRAM so that U-Boot proper could be loaded). It has since expanded to become an important part of U-Boot, with three phases now present: TPL, VPL and SPL Due to this history, the term 'SPL' is used to mean both a particular phase (the one before U-Boot proper) and all the non-proper phases. This has become confusing. For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL' phases, not just SPL. So code which can only be compiled for actual SPL, for example, must use something like this: #if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD) In Makefiles we have similar issues. SPL_ has been used as a variable which expands to either SPL_ or nothing, to chose between options like CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was updated to support 'VPL_' as well. This series starts a change in terminology and usage to resolve the above issues: - The word 'xPL' is used instead of 'SPL' to mean a non-proper build - A new CONFIG_XPL_BUILD define indicates that the current build is an 'xPL' build - The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now defined for TPL and VPL phases - The existing SPL_ Makefile variable is renamed to SPL_ - The existing SPL_TPL Makefile variable is renamed to PHASE_ It should be noted that xpl_phase() can generally be used instead of the above CONFIGs without a code-space or run-time penalty. This series does not attempt to convert all of U-Boot to use this new terminology but it makes a start. In particular, renaming spl.h and common/spl seems like a bridge too far at this point. The series is fully bisectable. It has also been checked to ensure there are no code-size changes on any commit.