Tianocore/edk2-platforms.git/Silicon/Broadcom/Drivers/Net, branch CodeCleanup

Silicon/Broadcom/BcmGenetDxe: Suppress some bogus compiler warnings

2024-03-11T14:15:27+00:00

Some recent GCC revisions will throw warnings about values being used before being initialized. But in the case where the lack of initialization is the result of the called function returning error status the EFI_ERROR() macro/error seems to confuse the compiler about the fact that the value is then never used. So, while the code appears to be fine, lets just zero the variables anyway to make the compiler happy. Signed-off-by: Jeremy Linton Reviewed-by: Ard Biesheuvel

Silicon/Broadcom/BcmGenetDxe: Delay for linkup in transmit

2021-08-16T07:21:14+00:00

Under normal circumstances GenetSimpleNetworkTransmit won't be called unless the rest of the network stack detects the link is up. So, during normal operation when the adapter is initialized the link naturally transitions to link up, and then is ready for activity later in the boot sequence. If that hasn't happened by the time PXE runs then it will itself wait for the link. OTOH, the normal distro PXE sequence involves PXE loading shim which in turn loads grub, which tries to read machine specific configs, modules, and grub.cfg in order to prepare the boot menu. Then, once a grub selection is picked, it might try to load the kernel+initrd. In this sequence the network stack is shutdown and restarted multiple times. Grub though, starts up, notices its been network booted, reads saved network parameters and immediately tries to transmit data assuming the link is still up. When that happens grub will print "couldn't send network packet" and if that lasts long enough it fails to load grub.cfg and the user gets dropped to the grub prompt because no one in the path bothers to assure the link state has transitioned back up. For reference: https://github.com/pftf/RPi4/issues/113 This patch fixes that by polling the link state via GenericPhyUpdateConfig() for ten seconds in the transmit path when the link is down. If the link recovers within this timeout the state machine is transitioned and we continue data transmission. If the 10 seconds expires without the link resuming we will fail as before. While full link negotiation can be fast, it frequently can take a second or two, or longer depending on the remote peer on the other end of the Ethernet cable. It seems auto MDX can slow this down, and certain vendors products seem to be slower than the norm. Ten seconds may not cover some of these possibilities, but the user should validate cabling and the switch/peer's port configuration if resuming the link is taking > 10 seconds. Picking a longer timeout is a tradeoff between the machine appearing to hang for extended periods of time (due to grub retries) if the link is actually down vs generally providing enough time for most endpoints to complete the negotiation. Signed-off-by: Jeremy Linton Reviewed-by: Jared McNeill Reviewed-by: Andrei Warkentin

Platforms/RaspberryPi: Fix BcmGenetDxe ComponentName2 error checking

2020-08-17T13:52:32+00:00

Fix input param error checking for the BcmGenetDxe ComponentName2 protocol. This fixes https://github.com/pftf/RPi4/issues/85 Signed-off-by: Samer El-Haj-Mahmoud Reviewed-by: Pete Batard

Silicon/BcmGenetDxe: don't consume RX buffer until it's actually copied

2020-07-14T14:46:05+00:00

This was originally a bit sloppy, and could hypothetically under heavy load result in a buffer being overwritten by hardware before the received buffer is copied. Signed-off-by: Andrei Warkentin Reviewed-by: Pete Batard Reviewed-by: Leif Lindholm

Silicon/Broadcom/BcmGenetDxe: implement media state adapter info protocol

2020-06-18T10:32:06+00:00

NetLibDetectMedia () in DxeNetLib is used as a fallback on implementations of the SNP protocol that do not also carry an implementation of the adapter info protocol to provide media state information, and it does all kinds of terrible things to the network interface (stopping and restarting multiple times, reprogramming the multicast filters etc etc) to workaround some alleged UNDI shortcoming. Although our GENET code should be bullet proof and therefore able to take this kind of abuse, it is better to avoid it, and provide an implementation of the adapter info protocol that returns the media state directly, without the need to mistreat the SNP layer. Signed-off-by: Ard Biesheuvel Reviewed-by: Samer El-Haj-Mahmoud Tested-by: Samer El-Haj-Mahmoud

Silicon/Broadcom/BcmGenetDxe: program MAC also when not connected

2020-06-05T08:07:45+00:00

In preparation of removing the EfiBootManagerConnectAll() from the ordinary boot path, ensure that the MAC programming of the GENET occurs even if the SNP driver for it is never invoked by the BDS. Signed-off-by: Ard Biesheuvel Reviewed-by: Pete Batard Tested-by: Pete Batard Acked-by: Leif Lindholm

Silicon/Broadcom/BcmGenetDxe: Fix reliability issues

2020-05-12T22:01:11+00:00

TFTP and HTTP downloads were failing. The problem was that the incorrect PROD index was being written TX ring. The PROD index should be the TxProdIndex (in the range [0-0xffff]), not the descriptor index (in the range [0-num descs)). Also, mod 0xffff is not the same as & 0xffff, so fix that as well. Signed-off-by: Andrei Warkentin Tested-by: Samer El-Haj-Mahmoud

Platform/RaspberryPi4: Clean up PCDs out of the GENET driver

2020-05-12T17:19:35+00:00

Move PCDs from GENET driver to Raspberry Pi and Bcm27xx packages. The Genet driver follows the UEFI driver model, so it should not have PCDs defined that describe MMIO and MAC addresses of a single instance. Also, move related definitions around, and update references accordingly. Signed-off-by: Ard Biesheuvel Reviewed-by: Leif Lindholm

Silicon/Broadcom/BcmGenetDxe: Add GENET driver

2020-05-12T17:19:35+00:00

Add support for the Broadcom GENET v5 ethernet controller for the Raspberry Pi 4 (BCM2711) Co-authored-by: Jared McNeill Co-authored-by: Andrei Warkentin Co-authored-by: Samer El-Haj-Mahmoud Co-authored-by: Ard Biesheuvel Signed-off-by: Ard Biesheuvel Reviewed-by: Leif Lindholm

Silicon/Broadcom: Add BcmGenetPlatformDevice protocol

2020-05-12T15:27:16+00:00

Add BcmGenetPlatformDevice definition for GENET. This protocol will be used to register GENET platform device that is on a non-discoverable bus. Signed-off-by: Ard Biesheuvel Reviewed-by: Leif Lindholm