summaryrefslogtreecommitdiffstats
path: root/src/drivers/usb
Commit message (Collapse)AuthorAgeFilesLines
* [build] Mark known reviewed files as permitted for UEFI Secure BootMichael Brown2026-01-1410-0/+10
| | | | | | | | | Some past security reviews carried out for UEFI Secure Boot signing submissions have covered specific drivers or functional areas of iPXE. Mark all of the files comprising these areas as permitted for UEFI Secure Boot. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dwusb] Add driver for DesignWare USB3 host controllerMichael Brown2025-07-212-0/+154
| | | | | | | | | | | | | | | | | | | Add a basic driver for the DesignWare USB3 host controller as found in the Lichee Pi 4A. This driver covers only the DesignWare host controller hardware. On the Lichee Pi 4A, this is sufficient to get the single USB root hub port (exposed internally via the SODIMM connector) up and running. The driver does not yet handle the various GPIOs that control power and signal routing for the Lichee Pi 4A's onboard VL817 USB hub and the four physical USB-A ports. This therefore leaves the USB hub and the USB-A ports unpowered, and the USB2 root hub port routed to the physical USB-C port. Devices plugged in to the USB-A ports will not be powered up, and a device plugged in to the USB-C port will enumerate as a USB2 device. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xhci] Allow for non-PCI xHCI host controllersMichael Brown2025-07-212-1225/+89Star
| | | | | | | Allow for the existence of xHCI host controllers where the underlying hardware is not a PCI device. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xhci] Use root hub port number to determine slot typeMichael Brown2025-07-181-1/+2
| | | | | | | | | | | | | | | | | | | | We currently use the downstream hub's port number to determine the xHCI slot type for a newly connected USB device. The downstream hub port number is irrelevant to the xHCI controller's supported protocols table: the relevant value is the number of the root hub port through which the device is attached. Fix by using the root hub port number instead of the immediate parent hub's port number. This bug has not previously been detected since the slot type for the first N root hub ports will invariably be zero to indicate that these are USB ports. For any xHCI controller with a sufficiently large number of root hub ports, the code would therefore end up happening to calculate the correct slot type value despite using an incorrect port number. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Remove redundant copy_from_user() and copy_to_user()Michael Brown2025-04-301-0/+1
| | | | | | | Remove the now-redundant copy_from_user() and copy_to_user() wrapper functions. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [block] Remove userptr_t from block device abstractionMichael Brown2025-04-241-5/+5
| | | | | | | Simplify the block device code by assuming that all read/write buffers are directly accessible via pointer dereferences. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Remove trivial uses of userptr_tMichael Brown2025-04-241-2/+1Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Remove user_to_phys() and phys_to_user()Michael Brown2025-04-211-4/+3Star
| | | | | | | | Remove the intermediate concept of a user pointer from physical address conversions, leaving virt_to_phys() and phys_to_virt() as the directly implemented functions. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Remove redundant memcpy_user() and related string functionsMichael Brown2025-04-211-1/+1
| | | | | | | | | | The memcpy_user(), memmove_user(), memcmp_user(), memset_user(), and strlen_user() functions are now just straightforward wrappers around the corresponding standard library functions. Remove these redundant wrappers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow for custom methods for disconnecting existing driversMichael Brown2025-04-171-1/+21
| | | | | | | | Allow for greater control over the process used to disconnect existing drivers from a device handle, by converting the "exclude" field from a simple protocol GUID to a per-driver method. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Disconnect existing drivers on a per-protocol basisMichael Brown2025-03-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | UEFI does not provide a direct method to disconnect the existing driver of a specific protocol from a handle. We currently use DisconnectController() to remove all drivers from a handle that we want to drive ourselves, and then rely on recursion in the call to ConnectController() to reconnect any drivers that did not need to be disconnected in the first place. Experience shows that OEMs tend not to ever test the disconnection code paths in their UEFI drivers, and it is common to find drivers that refuse to disconnect, fail to close opened handles, fail to function correctly after reconnection, or lock up the entire system. Implement a more selective form of disconnection, in which we use OpenProtocolInformation() to identify the driver associated with a specific protocol, and then disconnect only that driver. Perform disconnections in reverse order of attachment priority, since this is the order likely to minimise the number of cascaded implicit disconnections. This allows our MNP driver to avoid performing any disconnections at all, since it does not require exclusive access to the MNP protocol. It also avoids performing unnecessary disconnections and reconnections of unrelated drivers such as the "UEFI WiFi Connection Manager" that attaches to wireless network interfaces in order to manage wireless network associations. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Define an attachment priority order for EFI driversMichael Brown2025-03-291-1/+1
| | | | | | | | Define an ordering for internal EFI drivers on the basis of how close the driver is to the hardware, and attempt to start drivers in this order. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow use of typed pointers for efi_open() et alMichael Brown2025-03-241-27/+7Star
| | | | | | | | | Provide wrapper macros to allow efi_open() and related functions to accept a pointer to any pointer type as the "interface" argument, in order to allow a substantial amount of type adjustment boilerplate to be removed. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Use efi_open() for all ephemeral protocol opensMichael Brown2025-03-241-53/+15Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Use efi_open_by_driver() for all by-driver protocol opensMichael Brown2025-03-241-23/+8Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Avoid overlap between special keys and Unicode charactersMichael Brown2023-07-041-2/+2
| | | | | | | | | | | | | | The special key range (from KEY_MIN upwards) currently overlaps with the valid range for Unicode characters, and therefore prohibits the use of Unicode key values outside the ASCII range. Create space for Unicode key values by moving the special keys to the range immediately above the maximum valid Unicode character. This allows the existing encoding of special keys as an efficiently packed representation of the equivalent ANSI escape sequence to be maintained almost as-is. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Support AltGr to access ASCII characters via remappingMichael Brown2022-02-151-0/+2
| | | | | | | | | | | | | Several keyboard layouts define ASCII characters as accessible only via the AltGr modifier. Add support for this modifier to ensure that all ASCII characters are accessible. Experiments suggest that the BIOS console is likely to fail to generate ASCII characters when the AltGr key is pressed. Work around this limitation by accepting LShift+RShift (which will definitely produce an ASCII character) as a synonym for AltGr. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Centralise handling of key modifiersMichael Brown2022-02-151-10/+11
| | | | | | | Handle Ctrl and CapsLock key modifiers within key_remap(), to provide consistent behaviour across different console types. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Handle remapping of scancode 86Michael Brown2022-02-102-1/+8
| | | | | | | | | | | | | | | | | The key with scancode 86 appears in the position between left shift and Z on a US keyboard, where it typically fails to exist entirely. Most US keyboard maps define this nonexistent key as generating "\|", with the notable exception of "loadkeys" which instead reports it as generating "<>". Both of these mapping choices duplicate keys that exist elsewhere in the map, which causes problems for our ASCII-based remapping mechanism. Work around these quirks by treating the key as generating "\|" with the high bit set, and making it subject to remapping. Where the BIOS generates "\|" as expected, this allows us to remap to the correct ASCII value. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Handle upper/lower case and Ctrl-<key> after applying remappingMichael Brown2022-02-101-6/+11
| | | | | | | | Some keyboard layouts (e.g. "fr") swap letter and punctuation keys. Apply the logic for upper and lower case and for Ctrl-<key> only after applying remapping, in order to handle these layouts correctly. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Support keyboard remapping via the native USB keyboard driverMichael Brown2022-02-101-0/+5
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xhci] Avoid DMA during shutdown if firmware has disabled bus masteringMichael Brown2021-11-121-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | On some systems (observed with the Thunderbolt ports on a ThinkPad X1 Extreme Gen3 and a ThinkPad P53), the system firmware will disable bus mastering on the xHCI controller and all PCI bridges at the point that ExitBootServices() is called if the IOMMU is enabled. This leaves the xHCI controller unable to shut down cleanly since all commands will fail with a timeout. Commit 85eb961 ("[xhci] Allow for permanent failure of the command mechanism") allows us to detect that this has happened and respond cleanly. However, some unidentified hardware component (either the xHCI controller or one of the PCI bridges) seems to manage to enqueue the attempted DMA operation and eventually complete it after the operating system kernel has reenabled bus mastering. This results in a DMA operation to an area of memory that the hardware is no longer permitted to access. On Windows with the Driver Verifier enabled, this will result in a STOP 0xE6 (DRIVER_VERIFIER_DMA_VIOLATION). Work around this problem by detecting when bus mastering has been disabled, and immediately failing the device to avoid initiating any further DMA attempts. Reported-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xhci] Allow for permanent failure of the command mechanismMichael Brown2021-10-292-2/+51
| | | | | | | | | | | | | | | | | | | | Some xHCI controllers (observed with the Thunderbolt ports on a ThinkPad X1 Extreme Gen3 and a ThinkPad P53) seem to suffer a catastrophic failure at the point that ExitBootServices() is called if the IOMMU is enabled. The symptoms appear to be consistent with another UEFI driver (e.g. the IOMMU driver, or the Thunderbolt driver) having torn down the DMA mappings, leaving the xHCI controller unable to write to host memory. The observable effect is that all commands fail with a timeout, and attempts to abort command execution similarly fail since the xHCI controller is unable to report the abort completion. Check for failure to abort a command, and respond by performing a full device reset (as recommended by the xHCI specification) and by marking the device as permanently failed. Reported-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xhci] Avoid false positive Coverity warningMichael Brown2021-01-041-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xhci] Show meaningful error messages after command failuresMichael Brown2021-01-031-7/+25
| | | | | | | Ensure that any command failure messages are followed up with an error message indicating what the failed command was attempting to perform. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xhci] Fail attempts to issue concurrent commandsMichael Brown2021-01-031-0/+8
| | | | | | | | The xHCI driver can handle only a single command TRB in progress at any one time. Immediately fail any attempts to issue concurrent commands (which should not occur in normal operation). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xhci] Update driver to use DMA APIMichael Brown2020-11-292-91/+175
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [malloc] Rename malloc_dma() to malloc_phys()Michael Brown2020-11-053-48/+49
| | | | | | | | | | | | The malloc_dma() function allocates memory with specified physical alignment, and is typically (though not exclusively) used to allocate memory for DMA. Rename to malloc_phys() to more closely match the functionality, and to create name space for functions that specifically allocate and map DMA-capable buffers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usbblk] Allow USB block device to be described using an EFI device pathMichael Brown2020-10-161-0/+15
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Split device path functions out to efi_path.cMichael Brown2020-10-161-2/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usbblk] Add support for USB mass storage devicesMichael Brown2020-10-132-0/+1018
| | | | | | | | | | | | | | | | | | | | | | | | Some UEFI BIOSes (observed with at least the Insyde UEFI BIOS on a Microsoft Surface Go) provide a very broken version of the UsbMassStorageDxe driver that is incapable of binding to the standard EFI_USB_IO_PROTOCOL instances and instead relies on an undocumented proprietary protocol (with GUID c965c76a-d71e-4e66-ab06-c6230d528425) installed by the platform's custom version of UsbCoreDxe. The upshot is that USB mass storage devices become inaccessible once iPXE's native USB host controller drivers are loaded. One possible workaround is to load a known working version of UsbMassStorageDxe (e.g. from the EDK2 tree): this driver will correctly bind to the standard EFI_USB_IO_PROTOCOL instances exposed by iPXE. This workaround is ugly in practice, since it involves embedding UsbMassStorageDxe.efi into the iPXE binary and including an embedded script to perform the required "chain UsbMassStorageDxe.efi". Provide a native USB mass storage driver for iPXE, allowing USB mass storage devices to be exposed as iPXE SAN devices. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Update drivers to use pci_ioremap()Michael Brown2020-09-252-2/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xhci] Increase link state settling delay to 100msMichael Brown2020-07-031-1/+1
| | | | | | | | | | Experimentation shows that the existing 20ms delay is insufficient, and often results in device detection being deferred until after iPXE has completed startup. Fix by increasing the delay to 100ms. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Avoid unnecessary calls to usb_hub_set_drvdata()Michael Brown2020-07-033-25/+8Star
| | | | | | | | The driver-private data for root hubs is already set immediately after allocating the USB bus. There seems to be no reason to set it again when opening the root hub. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xhci] Set link state to RxDetect after disabling USB3 root hub portMichael Brown2020-07-031-0/+13
| | | | | | | | | | | | | The "disabled" port states for USB2 and USB3 are not directly equivalent. In particular, a disabled USB3 port will not detect new device connections. The result is that a USB3 device disconnected from and reconnected to an xHCI root hub port will end up reconnecting as a USB2 device. Fix by setting the link state to RxDetect after disabling the port, as is already done during initialisation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Do not attempt to disable USB3 hub portsMichael Brown2020-07-021-2/+4
| | | | | | | | | The USB3 specification removes PORT_ENABLE from the list of features that may be cleared via a CLEAR_FEATURE request. Experimentation shows that omitting the attempt to clear PORT_ENABLE seems to result in the correct hotplug behaviour. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Add missing usb_recycle() for completed hub interrupt transfersMichael Brown2020-07-021-0/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Do not attempt EFI_USB_IO_PROTOCOL transfers during shutdownMichael Brown2019-09-151-0/+8
| | | | | | | | | | | | | | | On at least some platforms (observed with a Raspberry Pi), any attempt to perform USB transfers via EFI_USB_IO_PROTOCOL during EFI shutdown will lock up the system. This is quite probably due to the already documented failure of all EFI timers when ExitBootServices() is called: see e.g. commit 5cf5ffea2 "[efi] Work around temporal anomaly encountered during ExitBootServices()". Work around this problem by refusing to poll endpoints if shutdown is in progress, and by immediately failing any attempts to enqueue new transfers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Report failed control transfers as expected by the USB coreMichael Brown2019-09-151-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | The USB core reuses the I/O buffer space occupied by the USB setup packet to hold the completion status for message transfers, assuming that the message() method will always strip the setup packet before returning. This assumption is correct for all of the hardware controller drivers (XHCI, EHCI, and UHCI), since these drivers are able to enqueue the transfer as a separate action from waiting for the transfer to complete. The EFI_USB_IO_PROTOCOL does not allow us to separate actions in this way: there is only a single blocking method that both enqueues and waits for completion. Our usbio driver therefore currently defers stripping the setup packet until the control endpoint is polled. This causes a bug if a message transfer is enqueued but never polled and is subsequently cancelled, since the cancellation will be reported with the I/O buffer still containing the setup packet. This breaks the assumption that the setup packet has been stripped, and triggers an assertion failure in usb_control_complete(). Fix by always stripping the setup packet in usbio_endpoint_message(), and adjusting usbio_control_poll() to match. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [init] Show startup and shutdown function names in debug messagesMichael Brown2019-01-252-0/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xhci] Consume event TRB before reporting completion to USB coreMichael Brown2018-02-191-4/+4
| | | | | | | | | | | | | | | | Reporting a completion via usb_complete() will pass control outside the scope of xhci.c, and could potentially result in a further call to xhci_event_poll() before returning from usb_complete(). Since we currently update the event consumer counter only after calling usb_complete(), this can result in duplicate completions and consequent corruption of the submission TRB ring structures. Fix by updating the event ring consumer counter before passing control to usb_complete(). Reported-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Tested-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xhci] Assume an invalid PSI table if any invalid PSI value is observedMichael Brown2018-01-291-23/+30
| | | | | | | | | | | Invalid protocol speed ID tables appear to be increasingly common in the wild, to the point that it is infeasible to apply an explicit XHCI_BAD_PSIV flag for each offending PCI device ID. Fix by assuming an invalid PSI table as soon as any invalid value is reported by the hardware. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Allow for USB network devices with no interrupt endpointMichael Brown2017-06-141-13/+21
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xhci] Avoid accessing beyond end of endpoint context arrayMichael Brown2017-03-211-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ehci] Add extra debugging informationMichael Brown2016-02-051-2/+73
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Allow USB endpoints to specify a reserved header length for refillsMichael Brown2016-01-192-2/+2
| | | | 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>
* [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>
* [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] Record USB device speed separately from current port speedMichael Brown2015-12-073-5/+4Star
| | | | | | | | | | | | | 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>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-03-04 22:03:24 +0100