aboutsummaryrefslogtreecommitdiffstats
path: root/src/drivers/net/efi/snpnet.c
Commit message (Collapse)AuthorAgeFilesLines
* [efi] Pad transmit buffer length to work around vendor driver bugssnppadMichael Brown2024-03-181-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The Mellanox/Nvidia UEFI driver is built from the same codebase as the iPXE driver, and appears to contain the bug that was fixed in commit c11734e ("[golan] Use ETH_HLEN for inline header size"). This results in identical failures when using the SNP or NII interface (via e.g. snponly.efi) to drive a Mellanox card while EAPoL is enabled. Work around the underlying UEFI driver bug by padding transmit I/O buffers to the minimum Ethernet frame length before passing them to the underlying driver's transmit function. This padding is not technically necessary, since almost all modern hardware will insert transmit padding as necessary (and where the hardware does not support doing so, the underlying UEFI driver is responsible for adding any necessary padding). However, it is guaranteed to be harmless (other than a miniscule performance impact): the Ethernet specification requires zero padding up to the minimum frame length for packets that are transmitted onto the wire, and so the receiver will see the same packet whether or not we manually insert this padding in software. The additional padding causes the underlying Mellanox driver to avoid its faulty code path, since it will never be asked to transmit a very short packet. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [snp] Allocate additional padding for receive buffersMichael Brown2024-03-161-1/+14
| | | | | | | | | | | | | | Some SNP implementations (observed with a wifi adapter in a Dell Latitude 3440 laptop) seem to require additional space in the allocated receive buffers, otherwise full-length packets will be silently dropped. The EDK2 MnpDxe driver happens to allocate an additional 8 bytes of padding (4 for a VLAN tag, 4 for the Ethernet frame checksum). Match this behaviour since drivers are very likely to have been tested against MnpDxe. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [netdevice] Remove netdev_priv() helper functionMichael Brown2023-09-131-3/+3
| | | | | | | | | | Some network device drivers use the trivial netdev_priv() helper function while others use the netdev->priv pointer directly. Standardise on direct use of netdev->priv, in order to free up the function name netdev_priv() for reuse. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Run ExitBootServices shutdown hook at TPL_NOTIFYshutdown_tpl_notifyMichael Brown2021-11-231-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On some systems (observed with the Thunderbolt ports on a ThinkPad X1 Extreme Gen3 and a ThinkPad P53), if the IOMMU is enabled then the system firmware will install an ExitBootServices notification event that disables bus mastering on the Thunderbolt xHCI controller and all PCI bridges, and destroys any extant IOMMU mappings. This leaves the xHCI controller unable to perform any DMA operations. As described in commit 236299b ("[xhci] Avoid DMA during shutdown if firmware has disabled bus mastering"), any subsequent DMA operation attempted by the xHCI controller will end up completing after the operating system kernel has reenabled bus mastering, resulting in a DMA operation to an area of memory that the hardware is no longer permitted to access and, on Windows with the Driver Verifier enabled, a STOP 0xE6 (DRIVER_VERIFIER_DMA_VIOLATION). That commit avoids triggering any DMA attempts during the shutdown of the xHCI controller itself. However, this is not a complete solution since any attached and opened USB device (e.g. a USB NIC) may asynchronously trigger DMA attempts that happen to occur after bus mastering has been disabled but before we reset the xHCI controller. Avoid this problem by installing our own ExitBootServices notification event at TPL_NOTIFY, thereby causing it to be invoked before the firmware's own ExitBootServices notification event that disables bus mastering. This unsurprisingly causes the shutdown hook itself to be invoked at TPL_NOTIFY, which causes a fatal error when later code attempts to raise the TPL to TPL_CALLBACK (which is a lower TPL). Work around this problem by redefining the "internal" iPXE TPL to be variable, and set this internal TPL to TPL_NOTIFY when the shutdown hook is invoked. Avoid calling into an underlying SNP protocol instance from within our shutdown hook at TPL_NOTIFY, since the underlying SNP driver may attempt to raise the TPL to TPL_CALLBACK (which would cause a fatal error). Failing to shut down the underlying SNP device is safe to do since the underlying device must, in any case, have installed its own ExitBootServices hook if any shutdown actions are required. Reported-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Tested-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [snp] Retry initialisation if link is reported as downMichael Brown2020-06-191-7/+49
| | | | | | | | | | | | | | | Some devices (observed with a Getac RX10 tablet and docking station containing an embedded AX88179 USB NIC) seem to be capable of detecting link state only during the call to Initialize(), and will occasionally erroneously report that the link is down for the first few such calls. Work around these devices by retrying the Initialize() call multiple times, terminating early if a link is detected. The eventual absence of a link is treated as a non-fatal error, since it is entirely possible that the link really is down. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [snp] Set EFI_SIMPLE_NETWORK_RECEIVE_MULTICAST bit as per UEFI specIgnat Korchagin2019-12-161-1/+2
| | | | | | | | | | According to UEFI specification 2.8 p 24.1 we must set the EFI_SIMPLE_NETWORK_RECEIVE_MULTICAST bit in the "Disable" mask, when "ResetMCastFilter" is TRUE. Signed-off-by: Ignat Korchagin <ignat@cloudflare.com> Split-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [snp] Try promiscuous multicast receive filter if the regular one failsIgnat Korchagin2019-12-161-0/+3
| | | | | | | | | | | | | | | Currently, if the SNP driver for whatever reason fails to enable receive filters for multicast frames, it falls back to enabling just unicast and broadcast filters. This breaks some IPv6 functionality as the network card does not respond to neighbour solicitation requests. Some cards refuse to enable EFI_SIMPLE_NETWORK_RECEIVE_MULTICAST, but do support enabling EFI_SIMPLE_NETWORK_RECEIVE_PROMISCUOUS_MULTICAST, so try it before falling back to just unicast+broadcast. Signed-off-by: Ignat Korchagin <ignat@cloudflare.com> Split-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Guard against GetStatus() failing to return a NULL TX bufferMichael Brown2016-05-111-0/+1
| | | | | | | | | | | | | | | The UEFI specification requires the EFI_SIMPLE_NETWORK_PROTOCOL GetStatus() method to set TxBuf to NULL if there are no transmit buffers to recycle. Some implementations (observed with Lan9118Dxe in EDK2) fill in TxBuf only when there is a transmit buffer to recycle, which leads to large numbers of "spurious TX completion" errors. Work around this problem by initialising TxBuf to NULL before calling the GetStatus() method. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Remove raw EFI_HANDLE values from debug messagesMichael Brown2015-08-271-13/+11
| | | | | | | | | The raw EFI_HANDLE value is almost never useful to know, and simply adds noise to the already verbose debug messages. Improve the legibility of debug messages by using only the name generated by efi_handle_name(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Generalise snpnet_dev_info() to efi_device_info()Michael Brown2014-10-161-60/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Free transmit ring entry before calling netdev_tx_complete()Michael Brown2014-10-161-1/+3
| | | | | | | | The snpnet driver uses netdev_tx_defer() and so must ensure that space in the (single-entry) transmit descriptor ring is freed up before calling netdev_tx_complete(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow for non-PCI snpnet devicesMichael Brown2014-09-041-7/+8
| | | | | | | | | | | | | We currently require information about the underlying PCI device to populate the snpnet device's name and description. If the underlying device is not a PCI device, this will fail and prevent the device from being registered. Fix by falling back to populating the device description with information based on the EFI handle, if no PCI device information is available. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Generalise snpnet_pci_info() to efi_locate_device()Michael Brown2014-08-061-34/+9
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Try various possible SNP receive filtersCurtis Larsen2014-08-051-11/+37
| | | | | | | | | | | | | | | | | | | | | | | | | The behavior observed in the Apple EFI (1.10) RecieveFilters() call is: - failure if any of the PROMISCUOUS or MULTICAST filters are included - success if only UNICAST is included, however the result is UNICAST|BROADCAST - success if only UNICAST and BROADCAST are included - if UNICAST, or UNICAST|BROADCAST are used, but the previous call tried (and failed) to set UNICAST|BROADCAST|MULTICAST, then the result is UNICAST|BROADCAST|MULTICAST Work around this apparently broken SNP implementation by trying RecieveFilterMask, then falling back to UNICAST|BROADCAST|MULTICAST, then UNICAST|BROADCAST, and finally UNICAST. Modified-by: Michael Brown <mcb30@ipxe.org> Tested-by: Curtis Larsen <larsen@dixie.edu> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Open device path protocol only at point of useMichael Brown2014-08-051-4/+27
| | | | | | | | | | | | Some EFI 1.10 systems (observed on an Apple iMac) do not allow us to open the device path protocol with an attribute of EFI_OPEN_PROTOCOL_BY_DRIVER and so we cannot maintain a safe, long-lived pointer to the device path. Work around this by instead opening the device path protocol with an attribute of EFI_OPEN_PROTOCOL_GET_PROTOCOL whenever we need to use it. Debugged-by: Curtis Larsen <larsen@dixie.edu> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide centralised definitions of commonly-used GUIDsMichael Brown2014-08-051-8/+0
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Reset multicast filter list when setting SNP receive filtersMichael Brown2014-08-051-1/+1
| | | | | | | | According to the UEFI specification, the MCastFilter parameter (which we currently pass as NULL, along with a zero MCastFilterCnt) is optional only if ResetMCastFilter is true. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add ability to dump SNP device mode informationMichael Brown2014-08-051-0/+64
| | | | | Originally-implemented-by: Curtis Larsen <larsen@dixie.edu> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Dump existing openers when we are unable to open a protocolMichael Brown2014-07-311-0/+2
| | | | | | | | Dump the existing openers of a protocol whenever we are unable to open a protocol using attributes of BY_DEVICE, EXCLUSIVE, or BY_CHILD_CONTROLLER. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Use efi_handle_name() instead of efi_devpath_text() where applicableMichael Brown2014-07-311-24/+23
| | | | | | | | | | Using efi_devpath_text() is marginally more efficient if we already have the device path protocol available, but the mild increase in efficiency is not worth compromising the clarity of the pattern: DBGC ( device, "THING %p %s ...", device, efi_handle_name ( device ) ); Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Rewrite SNP NIC driverMichael Brown2014-07-081-204/+392
| | | | | | | | | Rewrite the SNP NIC driver to use non-blocking and deferrable transmissions, to provide link status detection, to provide information about the underlying (PCI) hardware device, and to avoid unnecessary I/O buffer allocations during receive polling. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Perform meaningful error code conversionsMichael Brown2013-04-191-38/+45
| | | | | | | | Exploit the redefinition of iPXE error codes to include a "platform error code" to allow for meaningful conversion of EFI_STATUS values to iPXE errors and vice versa. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [snpnet] Give up entirely on the transmit queueJarrod Johnson2012-02-121-32/+13
| | | | | | | | Practically speaking, it seems the convention is to only have one packet pending and not rely upon any mechanism to associate returned txbuf with txqueue. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [netdevice] Call netdev_link_[up|down|err]() only while registeredMichael Brown2010-09-051-3/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add the "snpnet" driverGeoff Lywood2010-06-021-0/+362
Add a new network driver that consumes the EFI Simple Network Protocol. Also add a bus driver that can find the Simple Network Protocol that iPXE was loaded from; the resulting behavior is similar to the "undionly" driver for BIOS systems. Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit (git 2.34.1) at 2025-02-23 06:02:27 +0000