summaryrefslogtreecommitdiffstats
path: root/src/drivers
Commit message (Collapse)AuthorAgeFilesLines
* [ehci] Add extra debugging informationMichael Brown2016-02-051-2/+73
| | | | 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-199-16/+22
| | | | 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>
* [usb] Add support for numeric keypad on USB keyboardsMichael Brown2016-01-062-7/+100
| | | | 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>
* [xhci] Ensure that zero-length packets are not part of a TRB chainMichael Brown2015-12-071-0/+6
| | | | | | | | | | | | Some xHCI controllers (such as qemu's emulated xHCI controller) do not correctly handle zero-length packets that are part of a TRB chain. The zero-length TRB ends up being squashed and does not result in a zero-length packet as seen by the device. Work around this problem by marking the zero-length packet as belonging to a separate transfer descriptor. 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>
* [usb] Allow additional settling time for out-of-spec hubsMichael Brown2015-12-072-0/+19
| | | | | | | | | | | | | Some hubs (e.g. the Avocent Corp. Virtual Hub on a Lenovo x3550 Integrated Management Module) have been observed to require more than the standard 200ms for ports to stabilise, with the result that devices appear to disconnect and immediately reconnect during the initial bus enumeration. Work around this problem by allowing specific hubs an extra 500ms of settling time. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Allow USB device IDs to include arbitrary driver-specific dataMichael Brown2015-12-071-3/+5
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Record USB device speed separately from current port speedMichael Brown2015-12-074-14/+13Star
| | | | | | | | | | | | | Record the speed of a USB device based on the port's speed at the time that the device was enabled. This allows us to remember the device's speed even after the device has been disconnected (and so the port's current speed has changed). In particular, this allows us to correctly identify the transaction translator for a low-speed or full-speed device after the device has been disconnected. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Use port->disconnected to check for disconnected devicesMichael Brown2015-12-072-10/+12
| | | | | | | | | | | | | The usb_message() and usb_stream() functions currently check for port->speed==USB_SPEED_NONE to determine whether or not a device has been unplugged. This test will give a false negative result if a new device has been plugged in before the hotplug mechanism has finished handling the removal of the old device. Fix by checking instead the port->disconnected flag, which is now cleared only after completing the removal of the old device. 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-148-46/+27Star
| | | | | | | | 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-149-158/+270
| | | | | | | | | | | 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] Provide efi_devpath_len()Michael Brown2015-09-131-3/+2Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xhci] Support arbitrarily large transfersMichael Brown2015-09-131-11/+45
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ehci] Support arbitrarily large transfersMichael Brown2015-09-131-14/+49
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ehci] Do not treat zero-length NULL pointers as unreachableMichael Brown2015-09-131-0/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Generalise zero-length packet generation logicMichael Brown2015-09-135-17/+18
| | | | | | | | The decision on whether or not a zero-length packet needs to be transmitted is independent of the host controller and belongs in the USB core. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add a USB host controller driver based on EFI_USB_IO_PROTOCOLMichael Brown2015-09-072-0/+1875
| | | | | | | | | | | | | | | | | | | | | Allow iPXE to coexist with other USB device drivers, by attaching to the EFI_USB_IO_PROTOCOL instances provided by the UEFI platform firmware. The EFI_USB_IO_PROTOCOL is an unsurprisingly badly designed abstraction of a USB device. The poor design choices intrinsic in the UEFI specification prevent efficient operation as a network device, with the result that devices operated using the EFI_USB_IO_PROTOCOL operate approximately two orders of magnitude slower than devices operated using our native EHCI or xHCI host controller drivers. Since the performance is so abysmally slow, and since the underlying problems are due to fundamental architectural mistakes in the UEFI specification, support for the EFI_USB_IO_PROTOCOL host controller driver is left as disabled by default. Users are advised to use the native iPXE host controller drivers instead. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Add function to device's function list before attempting probeMichael Brown2015-09-061-6/+4Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Expose usb_find_driver()Michael Brown2015-09-061-43/+52
| | | | 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>
* [xhci] Ignore invalid protocol speed ID values on Intel Skylake platformsMichael Brown2015-06-182-3/+9
| | | | | | | | | | | | | | | Some Intel Skylake platforms (observed on a prototype Lenovo ThinkPad) report the list of available USB3 protocol speed ID values as {1,2,3} but then report a port's speed using ID value 4. The value 4 happens to be the default value for SuperSpeed (when no protocol speed ID value list is explicitly defined), and the hardware seems to function correctly if we simply ignore its protocol speed ID table and assume that it uses the default values. Fix by adding a "broken PSI values" quirk for this controller. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xhci] Record device-specific quirks in xHCI device structureMichael Brown2015-06-182-3/+6
| | | | 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>
* [xhci] Fix comparison of signed and unsigned integersMichael Brown2015-06-011-1/+1
| | | | | | | | gcc 4.8.2 fails to report this erroneous comparison unless assertions are enabled. Reported-by: Mary-Ann Johnson <MaryAnn.Johnson@displaylink.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xhci] Fix length of allocated slot arrayMichael Brown2015-06-011-2/+3
| | | | | | | | | The xHCI slot ID is one-based, not zero-based. Fix the length of the xhci->slot[] array to account for this, and add assertions to check that the hardware returns a valid slot ID in response to the Enable Slot command. 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>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-02-27 19:23:37 +0100