aboutsummaryrefslogtreecommitdiffstats
path: root/src/drivers/bus
Commit message (Collapse)AuthorAgeFilesLines
* [pci] Drag in PCI settings mechanism only when PCI support is presentMichael Brown2024-10-251-0/+6
| | | | | | | Allow for the existence of platforms with no PCI bus by including the PCI settings mechanism only if PCI bus support is included. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Expose USB device descriptor and strings via settingsMichael Brown2024-10-182-5/+179
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow scripts to read basic information from USB device descriptors via the settings mechanism. For example: echo USB vendor ID: ${usb/${busloc}.8.2} echo USB device ID: ${usb/${busloc}.10.2} echo USB manufacturer name: ${usb/${busloc}.14.0} The general syntax is usb/<bus:dev>.<offset>.<length> where bus:dev is the USB bus:device address (as obtained via the "usbscan" command, or from e.g. ${net0/busloc} for a USB network device), and <offset> and <length> select the required portion of the USB device descriptor. Following the usage of SMBIOS settings tags, a <length> of zero may be used to indicate that the byte at <offset> contains a USB string descriptor index, and an <offset> of zero may be used to indicate that the <length> contains a literal USB string descriptor index. Since the byte at offset zero can never contain a string index, and a literal string index can never be zero, the combination of both <length> and <offset> being zero may be used to indicate that the entire device descriptor is to be read as a raw hex dump. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Add "usbscan" command for iterating over USB devicesMichael Brown2024-10-171-2/+73
| | | | | | | | Implement a "usbscan" command as a direct analogy of the existing "pciscan" command, allowing scripts to iterate over all detected USB devices. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Separate permission to probe buses from bus:dev.fn range discoveryMichael Brown2024-08-152-0/+5
| | | | | | | | | | | | | | | | | The UEFI device model requires us to not probe the PCI bus directly, but instead to wait to be offered the opportunity to drive devices via our driver service binding handle. We currently inhibit PCI bus probing by having pci_discover() return an empty range when using the EFI PCI I/O API. This has the unwanted side effect that scanning the bus manually using the "pciscan" command will also fail to discover any devices. Separate out the concept of being allowed to probe PCI buses from the mechanism for discovering PCI bus:dev.fn address ranges, so that this limitation may be removed. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Check that ECAM configuration space is within reachable memoryMichael Brown2023-11-021-0/+9
| | | | | | | | | | | | | | | | | Some machines (observed with an AWS EC2 m7a.large instance) will place the ECAM configuration space window above 4GB, thereby making it unreachable from non-paged 32-bit code. This problem is currently ignored by iPXE, since the address is silently truncated in the call to ioremap(). (Note that other uses of ioremap() are not affected since the PCI core will already have checked for unreachable 64-bit BARs when retrieving the physical address to be mapped.) Fix by adding an explicit check that the region to be mapped starts within the reachable memory address space. (Assume that no machines will be sufficiently peverse to provide a region that straddles the 4GB boundary.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Cache ECAM mapping errorsMichael Brown2023-11-021-2/+4
| | | | | | | | | When an error occurs during ECAM configuration space mapping, preserve the error within the existing cached mapping (instead of invalidating the cached mapping) in order to avoid flooding the debug log with repeated identical mapping errors. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Handle non-zero starting bus in ECAM allocationsMichael Brown2023-11-021-0/+1
| | | | | | | | | | | | | The base address provided in the PCI ECAM allocation within the ACPI MCFG table is the base address for the segment as a whole, not for the starting bus within that allocation. On machines that provide ECAM allocations with a non-zero starting bus number (observed with an AWS EC2 m7a.large instance), this will result in iPXE accessing the wrong memory addresses within the ECAM region. Fix by adding the appropriate starting bus offset to the base address. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Force completion of ECAM configuration space writesMichael Brown2023-11-011-1/+10
| | | | | | | | | | | | | | | | | | | | | The PCIe specification requires that "processor and host bridge implementations must ensure that a method exists for the software to determine when the write using the ECAM is completed by the completer" but does not specify any particular method to be used. Some platforms might treat writes to the ECAM region as non-posted, others might require reading back from a dedicated (and implementation-specific) completion register to determine when the configuration space write has completed. Since PCI configuration space writes will never be used for any performance-critical datapath operations (on any sane hardware), a simple and platform-independent solution is to always read back from the written register in order to guarantee that the write must have completed. This is safe to do, since the PCIe specification defines a limited set of configuration register types, none of which have read side effects. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [virtio] Fix implementation of vpm_ioread32()Alexander Eichner2023-08-221-2/+2
| | | | | | | | | | | The current implementation of vpm_ioread32() erroneously reads only 16 bits of data, which fails when used with the (stricter) virtio device emulation in VirtualBox. Fix by using the correct readl()/inl() I/O wrappers. Reworded-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [eisa] Check for system board presence before probing for slotseisaMichael Brown2023-02-101-0/+8
| | | | | | | | | | | | | | | EISA expansion slot I/O port addresses overlap space that may be assigned to PCI devices, which can lead to register reads and writes with unwanted side effects during EISA probing. Reduce the chances of performing EISA probing on PCI devices by probing EISA slot vendor and product ID registers only if the EISA system board vendor ID register indicates that the motherboard supports EISA. Debugged-by: Václav Ovsík <vaclav.ovsik@gmail.com> Tested-by: Václav Ovsík <vaclav.ovsik@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Do not attempt to drive PCI bridge devicesefibridgeMichael Brown2023-02-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | The "bridge" driver introduced in 3aa6b79 ("[pci] Add minimal PCI bridge driver") is required only for BIOS builds using the ENA driver, where experimentation shows that we cannot rely on the BIOS to fully assign MMIO addresses. Since the driver is a valid PCI driver, it will end up binding to all PCI bridge devices even on a UEFI platform, where the firmware is likely to have completed MMIO address assignment correctly. This has no impact on most systems since there is generally no UEFI driver for PCI bridges: the enumeration of the whole PCI bus is handled by the PciBusDxe driver bound to the root bridge. Experimentation shows that at least one laptop will freeze at the point that iPXE attempts to bind to the bridge device. No deeper investigation has been carried out to find the root cause. Fix by causing efipci_supported() to return an error unless the configuration space header type indicates a non-bridge device. Reported-by: Marcel Petersen <mp@sbe.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Backup and restore standard config space across PCIe FLRMichael Brown2022-11-131-2/+7
| | | | | | | | | | | | | | The behaviour of PCI devices across a function-level reset seems to be inconsistent in practice: some devices will preserve PCI BARs, some will not. Fix the behaviour of FLR on devices that do not preserve PCI BARs by backing up and restoring PCI configuration space across the reset. Preserve only the standard portion of the configuration space, since there may be registers with unexpected side effects in the remaining non-standardised space. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Allow PCI config space backup to be limited by maximum offsetMichael Brown2022-11-131-4/+6
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Add minimal PCI bridge driverMichael Brown2022-09-191-0/+132
| | | | | | | Add a minimal driver for PCI bridges that can be used to locate the bridge to which a PCI device is attached. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Select PCI I/O API at runtime for cloud imagesMichael Brown2022-09-181-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pretty much all physical machines and off-the-shelf virtual machines will provide a functional PCI BIOS. We therefore default to using only the PCI BIOS, with no fallback to an alternative mechanism if the PCI BIOS fails. AWS EC2 provides the opportunity to experience some exceptions to this rule. For example, the t3a.nano instances in eu-west-1 have no functional PCI BIOS at all. As of commit 83516ba ("[cloud] Use PCIAPI_DIRECT for cloud images") we therefore use direct Type 1 configuration space accesses in the images built and published for use in the cloud. Recent experience has discovered yet more variation in AWS EC2 instances. For example, some of the metal instance types have multiple PCI host bridges and the direct Type 1 accesses therefore see only a subset of the PCI devices. Attempt to accommodate future such variations by making the PCI I/O API selectable at runtime and choosing ECAM (if available), falling back to the PCI BIOS (if available), then finally falling back to direct Type 1 accesses. This is implemented as a dedicated PCIAPI_CLOUD API, rather than by having the PCI core select a suitable API at runtime (as was done for timers in commit 302f1ee ("[time] Allow timer to be selected at runtime"). The common case will remain that only the PCI BIOS API is required, and we would prefer to retain the optimisations that come from inlining the configuration space accesses in this common case. Cloud images are (at present) disk images rather than ROM images, and so the increased code size required for this design approach in the PCIAPI_CLOUD case is acceptable. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Add support for the Enhanced Configuration Access Mechanism (ECAM)Michael Brown2022-09-161-0/+265
| | | | | | | | | | | | | The ACPI MCFG table describes a direct mapping of PCI configuration space into MMIO space. This mapping allows access to extended configuration space (up to 4096 bytes) and also provides for the existence of multiple host bridges. Add support for the ECAM mechanism described by the ACPI MCFG table, as a selectable PCI I/O API alongside the existing PCI BIOS and Type 1 mechanisms. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Generalise pci_num_bus() to pci_discover()Michael Brown2022-09-151-13/+21
| | | | | | | | | | Allow pci_find_next() to discover devices beyond the first PCI segment, by generalising pci_num_bus() (which implicitly assumes that there is only a single PCI segment) with pci_discover() (which has the ability to return an arbitrary contiguous chunk of PCI bus:dev.fn address space). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Check for wraparound in callers of pci_find_next()Michael Brown2022-09-151-3/+3
| | | | | | | | | | | | | | | | The semantics of the bus:dev.fn parameter passed to pci_find_next() are "find the first existent PCI device at this address or higher", with the caller expected to increment the address between finding devices. This does not allow the parameter to distinguish between the two cases "start from address zero" and "wrapped after incrementing maximal possible address", which could therefore lead to an infinite loop in the degenerate case that a device with address ffff:ff:1f.7 really exists. Fix by checking for wraparound in the caller (which is already responsible for performing the increment). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Allow pci_find_next() to return non-zero PCI segmentsMichael Brown2022-09-151-8/+8
| | | | | | | | Separate the return status code from the returned PCI bus:dev.fn address, in order to allow pci_find_next() to be used to find devices with a non-zero PCI segment number. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Generalise function-level reset mechanismMichael Brown2022-08-081-0/+22
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Ensure that pci_read_config() initialises all fieldsMichael Brown2022-02-161-0/+5
| | | | | | | | | | | | | | | | | | As per the general pattern for initialisation functions in iPXE, pci_init() saves code size by assuming that the caller has already zeroed the underlying storage (e.g. as part of zeroing a larger containing structure). There are several places within the code where pci_init() is deliberately used to initialise a transient struct pci_device without zeroing the entire structure, because the calling code knows that only the PCI bus:dev.fn address is required to be initialised (e.g. when reading from PCI configuration space). Ensure that using pci_init() followed by pci_read_config() will fully initialise the struct pci_device even if the caller did not previously zero the underlying storage, since Coverity reports that there are several places in the code that rely upon this. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [virtio] Update driver to use DMA APIAaron Young2021-10-282-17/+32
| | | | Signed-off-by: Aaron Young <aaron.young@oracle.com>
* [pci] Avoid scanning nonexistent buses when using PCIAPI_DIRECTMichael Brown2021-04-101-2/+25
| | | | | | | | | | | | | | There is no method for obtaining the number of PCI buses when using PCIAPI_DIRECT, and we therefore currently scan all possible bus numbers. This can cause a several-second startup delay in some virtualised environments, since PCI configuration space access will necessarily require the involvement of the hypervisor. Ameliorate this situation by defaulting to scanning only a single bus, and expanding the number of PCI buses to accommodate any subordinate buses that are detected during enumeration. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Inhibit spurious array bounds warning on some versions of gccMichael Brown2021-01-151-1/+1
| | | | | | | | | | | | Some versions of gcc (observed with gcc 9.3.0 on NixOS Linux) produce a spurious warning about an out-of-bounds array access for the isa_extra_probe_addrs[] array. Work around this compiler bug by redefining the array index as a signed long, which seems to somehow avoid this spurious warning. Debugged-by: Manuel Mendez <mmendez534@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [isa] Add missing #include <config/isa.h>Manuel Mendez2021-01-131-0/+1
| | | | | | Signed-off-by: Manuel Mendez <mmendez534@gmail.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Avoid dragging in USB subsystem via efi_usb_path()Michael Brown2020-10-301-17/+0
| | | | | | | | | | | | Commit 87e39a9c9 ("[efi] Split efi_usb_path() out to a separate function") unintentionally introduced an undefined symbol reference from efi_path.o to usb_depth(), causing the USB subsystem to become a dependency of all EFI builds. Fix by converting usb_depth() to a static inline function. Reported-by: Pico Mitchell <pico@randomapplications.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Allow endpoints to be refilled to a specified upper limitMichael Brown2020-10-121-3/+16
| | | | | | | | | | | | For USB mass storage devices, we do not want to submit more bulk IN packets than are required for the inbound data, since this will waste memory. Allow an upper limit to be specified on each refill attempt. The endpoint will be refilled to the lower of this limit or the limit specified by usb_refill_init(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Allow device halt to be cleared independently of host controllerMichael Brown2020-10-121-14/+31
| | | | | | | | | | | | | | | | | | Closing and reopening a USB endpoint will clear any halt status recorded by the host controller, but may leave the endpoint halted at the device. This will cause the first packet submitted to the reopened endpoint to be lost, before the automatic stall recovery mechanism detects the halt and resets the endpoint. This is relatively harmless for USB network or HID devices, since the wire protocols will recover gracefully from dropped packets. Some protocols (e.g. for USB mass storage devices) assume zero packet loss and so would be adversely affected. Fix by allowing any device endpoint halt status to be cleared on a freshly opened endpoint. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Avoid integer underflow on malformed string descriptorsMichael Brown2020-10-011-1/+8
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Show debug message on device removalMichael Brown2020-09-291-0/+5
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Reset control endpoints immediately after failureMichael Brown2020-09-291-0/+1
| | | | | | | | | | | | | | | The current error handling mechanism defers the endpoint reset until the next use of the endpoint, on the basis that errors are detected during completions and completion handling should not recursively call usb_poll(). In the case of usb_control(), we are already at the level that calls usb_poll() and can therefore safely perform the endpoint reset immediately. This has no impact on functionality, but does make debugging traces easier to read since the reset will appear immediately after the causative error. 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>
* [usb] Leave port enabled after a failed device registrationMichael Brown2020-07-041-1/+3
| | | | | | | | | | | | A failure in device registration (e.g. due to a device with malformed descriptors) will currently result in the port being disabled as part of the error path. This in turn causes the hardware to detect the device as newly connected, leading to an endless loop of failed device registrations. Fix by leaving the port enabled in the case of a registration failure. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Clear device endpoint halt before resetting host endpointMichael Brown2020-07-021-7/+7
| | | | | | | | | | | | | | | | | | Resetting the host endpoint may immediately restart any pending transfers for that endpoint. If the device endpoint halt has not yet been cleared, then this will probably result in a second failed transfer. This second failure may be detected within usb_endpoint_reset() while waiting for usb_clear_feature() to complete. The endpoint will subsequently be removed from the list of halted endpoints, causing the second failure to be effectively ignored and leaving the host endpoint in a permanently halted state. Fix by deferring the host endpoint reset until after the device endpoint is ready to accept new transfers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Add support for PCI MSI-X interruptsMichael Brown2019-04-241-0/+251
| | | | | | | | | | | | | | | | | The Intel 40 Gigabit Ethernet virtual functions support only MSI-X interrupts, and will write back completed interrupt descriptors only when the device attempts to raise an interrupt (or when a complete cacheline of receive descriptors has been completed). We cannot actually use MSI-X interrupts within iPXE, since we never have ownership of the APIC. However, an MSI-X interrupt is fundamentally just a DMA write of a single dword to an arbitrary address. We can therefore configure the device to "raise" an interrupt by writing a meaningless value to an otherwise unused memory location: this is sufficient to trigger the receive descriptor writeback logic. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Use non-zero language ID to retrieve stringsMichael Brown2017-07-031-1/+36
| | | | | | | | | | | | We currently use a zero language ID to retrieve strings such as the ECM/NCM MAC address. This works on most hardware devices, but is known to fail on some software emulated CDC-NCM devices. Fix by using the first supported language ID, falling back to English (0x0409) if any error occurs when fetching the list of supported languages. This matches the behaviour of the Linux kernel. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Use correct length for memcpy()Michael Brown2017-03-221-2/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Use correct length for memcpy()Michael Brown2017-03-211-1/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [virtio] Remove queue size limit in legacy virtioLadi Prosek2017-01-221-9/+39
| | | | | | | | | | | | | | | | Virtio 0.9 implementation was limited to the maximum virtqueue size of MAX_QUEUE_NUM and the virtio-net driver would fail to initialize on hosts exceeding this limit. This commit lifts the restriction by allocating the queue memory based on the actual queue size instead of using a fixed maximum. Note that virtio 1.0 still uses the MAX_QUEUE_NUM constant to cap the size (unfortunately this functionality is not available in virtio 0.9). Signed-off-by: Ladi Prosek <lprosek@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [virtio] Simplify virtqueue shutdownLadi Prosek2017-01-221-8/+1
| | | | | | | | | | | | This commit introduces virtnet_free_virtqueues called on all virtqueue error and shutdown paths. vpm_find_vqs no longer cleans up after itself and instead expects virtnet_free_virtqueues to be always called to undo its effect. Signed-off-by: Ladi Prosek <lprosek@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [virtio] Cap queue size to MAX_QUEUE_NUMLadi Prosek2017-01-221-1/+7
| | | | | | | | | | | | | | | vpm_find_vqs incorrectly accepted the host provided queue size with no regard to iPXE's internal limitations. Virtio 1.0 makes it possible for the driver to override the queue size to reduce memory requirements and iPXE is a great use case for this feature. Also removing the extra vq->vring.num assignment which is already handled in vring_init. Signed-off-by: Ladi Prosek <lprosek@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [virtio] Fix virtio-pci loggingLadi Prosek2016-06-201-7/+7
| | | | | | | | | iPXE debug logging doesn't support %u. This commit replaces it with %d in virtio-pci debug format strings. Signed-off-by: Ladi Prosek <lprosek@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Support systems with multiple PCI root bridgesMichael Brown2016-06-092-5/+5
| | | | | | | | | Extend the 16-bit PCI bus:dev.fn address to a 32-bit seg:bus:dev.fn address, assuming a segment value of zero in contexts where multiple segments are unsupported by the underlying data structures (e.g. in the iBFT or BOFM tables). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Add support for PCI Enhanced AllocationMichael Brown2016-05-201-0/+149
| | | | | | | Some embedded devices have immovable BARs, which are described via a PCI Enhanced Allocation capability. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [virtio] Add virtio 1.0 PCI supportLadi Prosek2016-04-152-9/+361
| | | | | | | | | | | | This commit adds support for driving virtio 1.0 PCI devices. In addition to various helpers, a number of vpm_ functions are introduced to be used instead of their legacy vp_ counterparts when accessing virtio 1.0 (aka modern) devices. Signed-off-by: Ladi Prosek <lprosek@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Add pci_find_next_capability()Ladi Prosek2016-04-151-13/+41
| | | | | | | | | | | | | | | | | PCI devices may support more capabilities of the same type (for example PCI_CAP_ID_VNDR) and there was no way to discover all of them. This commit adds a new API pci_find_next_capability which provides this functionality. It would typically be used like so: for (pos = pci_find_capability(pci, PCI_CAP_ID_VNDR); pos > 0; pos = pci_find_next_capability(pci, pos, PCI_CAP_ID_VNDR)) { ... } Signed-off-by: Ladi Prosek <lprosek@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Allow USB endpoints to specify a reserved header length for refillsMichael Brown2016-01-191-2/+6
| | | | 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-071-9/+9
| | | | | | | | | | | | | 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-071-9/+10
| | | | | | | | | | | | | 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>
generated by cgit (git 2.34.1) at 2025-02-23 14:23:47 +0000