summaryrefslogtreecommitdiffstats
path: root/src/drivers/net
Commit message (Collapse)AuthorAgeFilesLines
...
* [ipoib] Resimplify test for received broadcast packetsMichael Brown2016-03-081-2/+2
| | | | | | | | | | | | Commit e62e52b ("[ipoib] Simplify test for received broadcast packets") relies upon the multicast LID being present in the destination address vector as passed to ipoib_complete_recv(). Unfortunately, this information is not present in many Infiniband devices' completion queue entries. Fix by testing instead for the presence of a multicast GID. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Assign names to queue pairsMichael Brown2016-03-081-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Allow for the creation of multicast groupsMichael Brown2016-03-081-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipoib] Simplify test for received broadcast packetsMichael Brown2016-03-081-4/+2Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipoib] Avoid unnecessary path record lookup for broadcast addressMichael Brown2016-03-081-15/+27
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Parse MLID, rate, and SL from multicast membership recordMichael Brown2016-03-081-22/+38
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Record multicast GID attachment as part of group membershipMichael Brown2016-03-081-17/+5Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Remove concept of whole-device owner dataMichael Brown2016-03-071-11/+45
| | | | | | | Remove the implicit assumption that the IPoIB protocol owns the whole Infiniband device. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add INTEL_NO_PHY_RST for another I218-LM variantMika Tiainen2016-02-121-1/+1
| | | | | | Fixed booting on HP EliteBook 820 G2 laptop. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ath9k] Remove broken ath_rxbuf_alloc()Michael Brown2016-01-283-70/+5Star
| | | | | | | | | | | | ath_rx_init() demonstrates some serious confusion over how to use pointers, resulting in (uint32_t*)NULL being used as a temporary variable. This does not end well. The broken code in question is performing manual alignment of I/O buffers, which can now be achieved more simply using alloc_iob_raw(). Fix by removing ath_rxbuf_alloc() entirely. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add INTEL_NO_PHY_RST for I218-LMHummel Frank2016-01-271-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [smsc95xx] Reserve headroom in received packetsMichael Brown2016-01-191-2/+4
| | | | | | | | | | | | | | | | | | | | | | | Some protocols (such as ARP) may modify the received packet and re-use the same I/O buffer for transmission of a reply. The SMSC95XX transmit header is larger than the receive header: the re-used I/O buffer therefore does not have sufficient headroom for the transmit header, and the ARP reply will therefore fail to be transmitted. This is essentially the same problem as in commit 2e72d10 ("[ncm] Reserve headroom in received packets"). Fix by reserving sufficient space at the start of each received packet to allow for the difference between the lengths of the transmit and receive headers. This problem is not caught by the current driver development test suite (documented at http://ipxe.org/dev/driver), since even the large file transfer tests tend to completely sufficiently quickly that there is no need for the server to ever send an ARP request. The failure shows up only when using a very slow protocol such as RFC7440-enhanced TFTP (as used by Windows Deployment Services). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Allow USB endpoints to specify a reserved header length for refillsMichael Brown2016-01-196-12/+14
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [smsc95xx] Enable LEDsMichael Brown2016-01-182-0/+24
| | | | | | | | | | | The LED pins are configured by default as GPIO inputs. While it is conceivable that a board might actually use these pins as GPIOs, no such board is known to exist. The Linux smsc95xx driver configures these pins unconditionally as LED outputs. Assume that it is safe to do likewise. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [smsc95xx] Fetch MAC from SMBIOS OEM string for Honeywell VM3Michael Brown2016-01-042-0/+116
| | | | | | | The Honeywell VM3 has no attached EEPROM, and records the MAC address within an SMBIOS OEM string. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [smsc95xx] Allow for multiple methods for obtaining the MAC addressMichael Brown2015-12-231-11/+56
| | | | | | | The SMSC95xx devices tend to be used in embedded systems with a variety of ad-hoc mechanisms for storing the MAC address. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add INTEL_NO_PHY_RST for I217-LMTorgeir Wulfsberg2015-12-071-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acm] Add support for CDC-ACM (aka USB RNDIS) devicesMichael Brown2015-12-072-0/+598
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [smsc95xx] Add driver for SMSC/Microchip LAN95xx USB Ethernet NICsMichael Brown2015-12-012-0/+1381
| | | | | | | | | | | | | | | | | | | | | | | | Tested using QEMU and usbredir to expose the LAN9512 chip present on a Raspberry Pi. There is a known issue with the LAN9512: an extra two bytes are appended to every transmitted packet. These two bytes comprise: { 0x00, 0x08 } if packet length == 0 (mod 8) { CRC[0], 0x00 } if packet length == 7 (mod 8) { CRC[0], CRC[1] } otherwise The extra bytes are appended whether the Ethernet CRC is generated manually or added automatically by the hardware. The issue occurs with the Linux kernel driver as well as the iPXE driver. It appears to be an undocumented hardware errata. TCP/IP traffic is not affected, since the IP header length field causes the extraneous bytes to be discarded by the receiver. However, protocols that rely on the length of the Ethernet frame (such as FCoE or iPXE's "lotest" protocol) will be unusable on this hardware. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Add definitions for PCI Express function level reset (FLR)Michael Brown2015-11-301-1/+0Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Correct definition of receive overrun bitMichael Brown2015-11-221-1/+1
| | | | | | Reported-by: Robin Smidsrød <robin@smidsrod.no> Tested-by: Robin Smidsrød <robin@smidsrod.no> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Forcibly skip PHY reset on some modelsMichael Brown2015-11-222-8/+19
| | | | | | | | | | | | | | | | | | On some models (notably ICH), the PHY reset mechanism appears to be broken. In particular, the PHY_CTRL register will be correctly loaded from NVM but the values will not be propagated to the "OEM bits" PHY register. This typically has the effect of dropping the link speed to 10Mbps. Since the original version of this driver in commit 945e428 ("[intel] Replace driver for Intel Gigabit NICs"), we have always worked around this problem by skipping the PHY reset if the link is already up. Enhance this workaround by explicitly checking for known-broken PCI IDs. Reported-by: Robin Smidsrød <robin@smidsrod.no> Tested-by: Robin Smidsrød <robin@smidsrod.no> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add PCI IDs for i210/i211 flashless operationKyösti Mälkki2015-11-041-0/+2
| | | | | Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [vmxnet3] Avoid completely filling the TX descriptor ringCarl Henrik Lunde2015-09-162-4/+12
| | | | | Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ncm] Support setting MAC addressMichael Brown2015-09-142-0/+14
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Allow for wildcard USB class IDsMichael Brown2015-09-144-12/+4Star
| | | | | | | | Make the class ID a property of the USB driver (rather than a property of the USB device ID), and allow USB drivers to specify a wildcard ID for any of the three component IDs (class, subclass, or protocol). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Select preferred USB device configuration based on driver scoreMichael Brown2015-09-144-0/+4
| | | | | | | | | | | Generate a score for each possible USB device configuration based on the available driver support, and select the configuration with the highest score. This will allow us to prefer ECM over RNDIS (for devices which support both) and will allow us to meaningfully select a configuration even when we have drivers available for all functions (e.g. when exposing unused functions via EFI_USB_IO_PROTOCOL). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Remove raw EFI_HANDLE values from debug messagesMichael Brown2015-08-274-43/+41Star
| | | | | | | | | 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] Work around bugs in Emulex NII driverFabrice Bacchella2015-08-171-15/+71
| | | | | Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Improve NII driver loggingFabrice Bacchella2015-08-171-10/+21
| | | | | Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipoib] Fix a race when chain-loading undionly.kpxe in IPoIBWissam Shoukair2015-08-171-2/+5
| | | | | | | | | | | | | | | The Infiniband link status change callback ipoib_link_state_changed() may be called while the IPoIB device is closed, in which case there will not be an IPoIB queue pair to be joined to the IPv4 broadcast group. This leads to NULL pointer dereferences in ib_mcast_attach() and ib_mcast_detach(). Fix by not attempting to join (or leave) the broadcast group unless we actually have an IPoIB queue pair. Signed-off-by: Wissam Shoukair <wissams@mellanox.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tg3] Add support for BCM57766Bernd Wiebelt2015-07-063-0/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipoib] Transmit multicast packets as broadcastsMichael Brown2015-07-061-2/+4
| | | | | | | | | | | | | Multicast MAC addresses will never have REMAC cache entries, and the corresponding multicast IPoIB MAC address cannot be obtained simply by issuing an ARP request. For the trivial volume of multicast packets that we expect to send in any realistic scenario, the simplest solution is to send them as broadcasts instead. Reported-by: Wissam Shoukair <wissams@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipoib] Attempt to generate ARPs as needed to repopulate REMAC cacheMichael Brown2015-06-291-5/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The only way to map an eIPoIB MAC address (REMAC) to an IPoIB MAC address is to intercept an incoming ARP request or reply. If we do not have an REMAC cache entry for a particular destination MAC address, then we cannot transmit the packet. This can arise in at least two situations: - An external program (e.g. a PXE NBP using the UNDI API) may attempt to transmit to a destination MAC address that has been obtained by some method other than ARP. - Memory pressure may have caused REMAC cache entries to be discarded. This is fairly likely on a busy network, since REMAC cache entries are created for all received (broadcast) ARP requests. (We can't sensibly avoid creating these cache entries, since they are required in order to send an ARP reply, and when we are being used via the UNDI API we may have no knowledge of which IP addresses are "ours".) Attempt to ameliorate the situation by generating a semi-spurious ARP request whenever we find a missing REMAC cache entry. This will hopefully trigger an ARP reply, which would then provide us with the information required to populate the REMAC cache. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipoib] Mark REMAC cache as expensiveMichael Brown2015-06-291-1/+1
| | | | | | | | As with the neighbour cache, discarding an REMAC cache entry is potentially very disruptive. Originally-fixed-by: Wissam Shoukair <wissams@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipoib] Fix REMAC cache discarderMichael Brown2015-06-011-3/+11
| | | | | Originally-fixed-by: Wissam Shoukair <wissams@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Fix operation when physical function has jumbo frames enabledMichael Brown2015-05-194-2/+134
| | | | | | | | | When jumbo frames are enabled, the Linux ixgbe physical function driver will disable the virtual function's receive datapath by default, and will enable it only if the virtual function negotiates API version 1.1 (or higher) and explicitly selects an MTU. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add intelxvf_stats() to dump packet statistics registersMichael Brown2015-05-192-0/+46
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add intelxvf driver for Intel 10 GigE virtual function NICsMichael Brown2015-05-162-0/+454
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add support for mailbox used by virtual functionsMichael Brown2015-05-163-0/+413
| | | | | | | | Virtual functions use a mailbox to communicate with the physical function driver: this covers functionality such as obtaining the MAC address. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Allow for the use of advanced TX descriptorsMichael Brown2015-05-163-42/+126
| | | | | | | | | | | | | | | | Intel virtual function NICs almost work with the use of "legacy" transmit and receive descriptors (which are backwards compatible right back to the original Intel Gigabit NICs). Unfortunately the "TX switching" feature (which allows for VM<->VM traffic to be looped back within the NIC itself) does not work when a legacy TX descriptor is used: the packet is instead sent onto the wire. Fix by allowing for the use of an "advanced" TX descriptor (containing exactly the same information as is found in the "legacy" descriptor). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Expose intel_diag() for use by other Intel NIC driversMichael Brown2015-05-152-26/+19Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [base16] Add buffer size parameter to base16_encode() and base16_decode()Michael Brown2015-04-242-2/+2
| | | | | | | | | | | | | | The current API for Base16 (and Base64) encoding requires the caller to always provide sufficient buffer space. This prevents the use of the generic encoding/decoding functionality in some situations, such as in formatting the hex setting types. Implement a generic hex_encode() (based on the existing format_hex_setting()), implement base16_encode() and base16_decode() in terms of the more generic hex_encode() and hex_decode(), and update all callers to provide the additional buffer length parameter. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ath9k] Remove confusing logic inversion in an ANI variableChristian Hesse2015-04-244-24/+24
| | | | | | | | | | | | This changed in Linux kernel the same way in commit 7067e701 ("ath9k_hw: remove confusing logic inversion in an ANI variable") by Felix Fietkau. Additionally this fixes "error: logical not is only applied to the left hand side of comparison" with GCC 5.1.0. Signed-off-by: Christian Hesse <mail@eworm.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add PCI device IDs for Intel I218-LM and I218-VChristian Hesse2015-04-221-1/+6
| | | | | | | | I218-LM (rev 3) is found in Lenovo Thinkpad X250. The remaining device IDs are from linux/drivers/net/ethernet/intel/e1000e/hw.h Signed-off-by: Christian Hesse <mail@eworm.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [rtl818x] Obviate RTL_ROM() hackMichael Brown2015-04-224-35/+31Star
| | | | | Reported-by: Robin Smidsrød <robin@smidsrod.no> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [realtek] Do not attempt to access EEPROM on RTL8169 chipsMichael Brown2015-04-211-2/+3
| | | | | | | | | | | | | | | | | On some RTL8169 onboard NICs (observed with a Lenovo ThinkPad 11e), the EEPROM is not merely not present: any attempt to read from the non-existent EEPROM will crash and reboot the system. The equivalent code to read from the EEPROM was removed from the Linux r8169 driver in 2009 with a comment suggesting that it was similarly found to be unreliable on some systems. Fix by accessing the EEPROM only on RTL8139 NICs, and assuming that the MAC address will always be correctly preset on RTL8169 NICs. Reported-by: Evan Prohaska <eprohaska@edkey.org> Tested-by: Evan Prohaska <eprohaska@edkey.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Force RX polling on VMware emulated 82545emMichael Brown2015-04-212-1/+13
| | | | | | | | | | | | The emulated Intel 82545em in some versions of VMware (observed with ESXi v5.1) seems to sometimes fail to set the RXT0 bit in the interrupt cause register (ICR), causing iPXE to stop receiving packets. Work around this problem (for the 82545em only) by always polling the receive queue regardless of the state of the ICR. Reported-by: Slava Bendersky <volga629@networklab.ca> Tested-by: Slava Bendersky <volga629@networklab.ca> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Report any unexpected interrupt causesMichael Brown2015-04-212-0/+10
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Update PCI device IDs for Intel 82599 and X540 10G NICsEd Swierk2015-04-211-4/+9
| | | | | | | | | | | | Identifiers are based on defines in Linux ixgbe_type.h. Descriptive names are based on https://www-ssl.intel.com/content/www/us/en/ethernet-controllers/82599-10-gbe-controller-spec-update.html and https://www-ssl.intel.com/content/www/us/en/network-adapters/10-gigabit-network-adapters/ethernet-x540-spec-update.html Signed-off-by: Ed Swierk <eswierk@skyportsystems.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-02-27 17:55:14 +0100