summaryrefslogtreecommitdiffstats
path: root/src/drivers
Commit message (Collapse)AuthorAgeFilesLines
* [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>
* [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>
* [usb] Always clear recorded disconnections after performing hotplug actionsMichael Brown2015-05-131-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | The recorded disconnections (in port->disconnected) will currently be left uncleared if usb_attached() returns an error (e.g. because there are no drivers for a particular USB device). This is incorrect behaviour: the disconnection has been handled and the record should be cleared until the next physical disconnection is detected (via the CSC bit). The problem is masked for EHCI, UHCI, and USB hubs, since these will report a changed port (via usb_port_changed()) only when the underlying hardware reports a change. xHCI will call usb_port_changed() in response to any port status event, at which point the stale value of port->disconnected will be erroneously acted upon. This can lead to an endless loop of repeatedly enumerating the same device when a driverless device is attached to an xHCI root hub port. Fix by unconditionally clearing port->disconnected in usb_hotplugged(). Reported-by: Robin Smidsrød <robin@smidsrod.no> Tested-by: Robin Smidsrød <robin@smidsrod.no> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Do not call usb_hotplug() when registering a new hubMichael Brown2015-05-131-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | The action of registering a new hub can itself happen in only two ways: either a new USB hub has been created (in which case we are already inside a call to usb_hotplug()), or a new root hub has been created. In the former case, we do not need to issue a further call to usb_hotplug(), since the hub's ports will all be marked as changed and so will be handled after the return from register_usb_hub() anyway. Calling usb_hotplug() within register_usb_hub() leads to a confusing order of events, such as: - root hub port 1 detects a change - root hub port 2 detects a change - usb_hotplug() is called - root hub port 1 finds a USB hub - usb_hotplug() is called - this inner call to usb_hotplug() handles root hub port 2 Fix by calling usb_hotplug() only from usb_step() and from register_usb_bus(). This avoids recursive calls to usb_hotplug() and ensures that devices are enumerated in the order of detection. Tested-by: Robin Smidsrød <robin@smidsrod.no> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Add basic support for USB keyboardsMichael Brown2015-05-122-0/+663
| | | | | | | | | | | | When USB network card drivers are used, the BIOS' legacy USB capability is necessarily disabled since there is no way to share the host controller between the BIOS and iPXE. This currently results in USB keyboards becoming non-functional in USB-enabled builds of iPXE. Fix by adding basic support for USB keyboards, enabled by default in iPXE builds which include USB support. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Add generic USB human interface device (HID) frameworkMichael Brown2015-05-121-0/+151
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Add USB_INTERRUPT_OUT internal typeMichael Brown2015-05-113-3/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uhci] Use meaningful device names in debug messagesMichael Brown2015-05-102-15/+21
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ehci] Use meaningful device names in debug messagesMichael Brown2015-05-102-43/+52
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xhci] Use meaningful device names in debug messagesMichael Brown2015-05-102-119/+124
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Provide usb_endpoint_name() for use by host controller driversMichael Brown2015-05-101-33/+29Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uhci] Add support for UHCI host controllersMichael Brown2015-05-102-0/+1921
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ehci] Allow UHCI/OHCI controllers to locate the EHCI companion controllerMichael Brown2015-05-092-0/+28
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Add find_usb_bus_by_location() helper functionMichael Brown2015-05-091-0/+20
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ehci] Poll child companion controllers after disowning portMichael Brown2015-05-092-0/+59
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Maintain single lists of halted endpoints and changed portsMichael Brown2015-05-091-44/+55
| | | | | | | | | | When an EHCI hotplug action results in the controller disowning the port, it will result in a hotplug action on the corresponding UHCI or OHCI controller. Allow such hotplug actions to be carried out as part of the same call to usb_step() or usb_register_bus(), by maintaining a single central list of changed ports. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Maintain a list of all USB busesMichael Brown2015-05-091-0/+10
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Detect missed disconnectionsMichael Brown2015-05-084-51/+72
| | | | | | | | | | | | | | | | | | | | | The USB core will currently fail to detect disconnections if a new device has attached by the time the port is examined in usb_hotplug(). Fix by recording the fact that a disconnection has taken place whenever the "connection status changed" (CSC) bit is observed to be set. (Whether the change represents a disconnection or a reconnection, it indicates that the port has experienced some time of being disconnected.) Note that the time at which a disconnection can be detected varies by hub type. In particular: root hubs can observe the CSC bit when polling, and so will record the disconnection before calling usb_port_changed(), but USB hubs read the port status (and hence the CSC bit) only during the call to hub_speed(), long after the call to usb_port_changed(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Provide PCI_CLASS() to calculate a scalar PCI class valueMichael Brown2015-05-082-4/+4
| | | | | | | | Rename PCI_CLASS() (which constructs a struct pci_class_id) to PCI_CLASS_ID(), and provide PCI_CLASS() as a macro which constructs the 24-bit scalar value of a PCI class code. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Include setup packet within I/O buffer for message transfersMichael Brown2015-05-014-46/+40Star
| | | | | | | | | | | | | | The USB API currently assumes that host controllers will have immediate data buffer space available in which to store the setup packet. This is true for xHCI, partially true for EHCI (which happens to have 12 bytes of padding in each transfer descriptor due to alignment requirements), and not true at all for UHCI. Include the setup packet within the I/O buffer passed to the host controller's message() method, thereby eliminating the requirement for host controllers to provide immediate data buffers. 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>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-02-28 03:45:01 +0100