| Age | Commit message (Collapse) | Author |
|
i) EHCI_HCSPARAMS should be read with EREAD4 (and not EOREAD4). Spotted by
jmcneill
ii) Apply brackets so that ?: vs | operator precedence doesn't give the
wrong result.
|
|
|
|
|
|
|
|
another copyright claim line. again. (i did this in 2008 and then
did not update all of my personal templates.)
|
|
|
|
|
|
|
|
The system is not at high IPL or limited to a single CPU at this
point; it is running essentially normally, just with some devices
suspended. Other threads might be trying to touch EHCI registers,
which might have bad outcomes while we're suspending stuff. Enabling
polling only makes sense if there is a single thread and single CPU
running, such as when we enter ddb on crash.
|
|
|
|
|
|
functions.
Also be more verbose about errors.
|
|
|
|
|
|
|
|
Access the 64-bit registers in their entirety at all times, independent
of the AC64 parameter of the hardware implementation.
Makes xhci(4) work on SolidRun MACCHIATObin (Marvell 8040 SoC)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
syzbot says that the change exposes UB in usb_free_device and I can't
see how, so revert until I have a better understanding of what's going on.
Reported-by: syzbot+c445f7149cce07d4c252@syzkaller.appspotmail.com
Reported-by: syzbot+a2ae42f37de765a54b20@syzkaller.appspotmail.com
|
|
|
|
which says it should be max 10 milliseconds.
From FreeBSD: https://github.com/freebsd/freebsd-src/commit/70ffaaa69c830d26b59136d0b0447ab2f8683db8
|
|
|
|
|
|
Instead of holding up boot by 400ms for each attached ukbd to blink the
keyboard LEDs, turn them on and set a callout to turn them off later.
|
|
In uhub_explore instead of waiting 300ms after powering up each
connected port, power up all of the connected ports and then wait for
300ms total.
|
|
The delay at the start of usb_event_thread is meant to slow down EHCI
companion controllers. Skip the 500ms delay if the bus that owns this
thread is USB >= 2.0 since those are never companions.
|
|
Instead of waiting for USB_PORT_ROOT_RESET_DELAY (250ms) before checking
the port reset status, poll the PORTSC register and return early if the
reset has completed.
|
|
|
|
if (uha->uiaa->uiaa_vendor == USB_VENDOR_..., remove entries now covered
by UQ_ALWAYS_ON
|
|
|
|
|
|
|
|
- Remove sc_wr_sel completely; nothing actually uses it.
|
|
|
|
define a flag FILTEROP_ISFD that has the meaning of the prior f_isfd.
Field and flag name aligned with OpenBSD.
This does not constitute a functional or ABI change, as the field location
and size, and the value placed in that field, are the same as the previous
code, but we're bumping __NetBSD_Version__ so 3rd-party module source code
can adapt, as needed.
NetBSD 9.99.89
|
|
|
|
|
|
|
|
|
|
NFC intended.
|
|
|
|
This fixes a bug in the API contract of usbd_abort_pipe: with the
change, the caller is guaranteed the xfer completion callbacks have
returned; without the change, completion callbacks could still be
running on the queued xfers while the caller of usbd_abort_pipe
proceeds to concurrently issue usbd_destroy_xfer.
This also fixes the following problem for interrupt pipes, whose
xfers stay on the queue until the pipe is aborted:
Thread 1: Hardware completion interrupt calls usb_transfer_complete.
Thread 1: pipe->up_repeat is 1, so usb_transfer_complete keeps xfer
queued.
Thread 2: Calls usbd_abort_pipe (e.g., in detach).
Thread 2: usbd_abort_pipe waits for bus lock.
Thread 1: usb_transfer_complete releases bus lock to invoke callback.
Thread 2: Sets pipe->up_repeat := 0 (too late for thread 1 to see).
Thread 1: usb_transfer_complete waits to reacquire bus lock before
resetting xfer status to USBD_NOT_STARTED.
Thread 2: Repeatdly calls upm_abort on the same xfer, which does
nothing because upm_abort just does usbd_abort_xfer which does
nothing because the xfer status is (e.g.) USBD_IOERROR and not
USBD_IN_PROGRESS.
Thread 2 is now spinning forever with the bus lock held (and possibly
the kernel lock) waiting for queue or xfer status to change, which
will never happen as long as it holds the bus lock.
The resolution is for thread 2 to notice that thread 1 is busy
invoking a callback, and to wait until thread 1 has finished invoking
the callback and updated the xfer status to reset it to
USBD_NOT_STARTED at which point thread 1 can make progress again.
XXX pullup-9
|
|
This avoids silent leaks in DIAGNOSTIC kernels.
|