usbdi(9): Nix resurrected usbd_request_async.

We killed this back in 2013, but it came back from the dead on a
driver imported from OpenBSD.

usbdi(9): New usbd_suspend_pipe, usbd_resume_pipe.

- New usbd_suspend_pipe to persistently stop transfers on a pipe and
cancel pending ones or wait for their callbacks to finish.
Idempotent.

-

usbdi(9): New usbd_suspend_pipe, usbd_resume_pipe.

- New usbd_suspend_pipe to persistently stop transfers on a pipe and
cancel pending ones or wait for their callbacks to finish.
Idempotent.

- New usbd_resume_pipe to allow transfers again. Idempotent, but no
new xfers may be submitted before repeating this.

This way it is safe to usbd_abort_pipe in two threads concurrently,
e.g. if one thread is closing a device while another is revoking it
-- but the threads have to agree on when it is done being aborted
before starting to use it again.

- Existing usbd_abort_pipe now does suspend then resume. No change
in semantics so drivers that relied on being able to submit
transfers again won't be broken any worse than the already are
broken.

This allows drivers to avoid races such as:

/* read */
if (sc->sc_dying)
return ENXIO;
/* (*) */
err = usbd_bulk_transfer(...);

/* detach or or close */
sc->sc_dying = true;
usbd_abort_pipe(...);
wait_for_io_to_drain(...);

The detach or close logic might happen at the same time as (*), with
no way to stop the bulk transfer before it starts, leading to
deadlock when detach/close waits for I/O operations like read to
drain. Instead, the close routine can use usbd_suspend_pipe, and the
usbd_bulk_transfer is guaranteed to fail.

But some drivers such as ucom(4) don't close and reopen pipes after
aborting them -- they open on attach and close on detach, and just
abort when the /dev node is closed, expecting that xfers will
continue to work when next opened. These drivers can instead use
usbd_suspend_pipe on close and usbd_resume_pipe on open. Perhaps it
would be better to make them open pipes on open and close pipes on
close, but these functions make for a less intrusive transition.

show more ...

usb: usbd_close_pipe never fails. Make it return void.

Prune dead branches as a result of this change.

usb: usbd_abort_pipe never fails. Make it return void.

Prune dead branches as a result of this change.

usbdi(9): Fix missing includes in usbdi.h.

usb(4): Bus exploration is single-threaded -- assert it so.

New usb_in_event_thread(dev) returns true if dev is a USB device --
that is, a device with a usbN ancestor -- and the current thread is
th

usb(4): Bus exploration is single-threaded -- assert it so.

New usb_in_event_thread(dev) returns true if dev is a USB device --
that is, a device with a usbN ancestor -- and the current thread is
the USB event thread.

(Kinda kludgey to pass around the device_t instead of, say, struct
usbd_bus, but I don't see a good way to get to the usbN device_t or
struct usb_softc from there.)

show more ...

Move usb_desc_* into usbdi_util.c, no functional change.

Factor out HCI-independent xfer completion logic.

New API for HCI drivers to synchronize hardware completion
interrupts, synchronous aborts, and asynchronous timeouts:

- When submitting an xfer to

Factor out HCI-independent xfer completion logic.

New API for HCI drivers to synchronize hardware completion
interrupts, synchronous aborts, and asynchronous timeouts:

- When submitting an xfer to hardware, call
usbd_xfer_schedule_timeout(xfer).

- On HCI completion interrupt for xfer completion:

if (!usbd_xfer_trycomplete(xfer))
return; /* timed out or aborted, ignore it */

- In upm_abort methods, call usbd_xfer_abort(xfer).

For HCI drivers that use this API (not needed in drivers that don't,
or for xfers like root intr xfers that don't use it):

- New ubm_abortx method serves role of former *hci_abort_xfer, but
without any logic for wrangling timeouts/callouts/tasks -- caller
in usbd_xfer_abort has already handled them.

- New ubm_dying method, returns true if the device is in the process
of detaching, used by the timeout logic.

Converted and tested:
- ehci
- ohci

Converted and compile-tested:
- ahci (XXX did this ever work?)
- dwc2
- motg (XXX missing usbd_xfer_schedule_timeout in motg_*_start?)
- uhci
- xhci

Not changed:

- slhci (sys/dev/ic/sl811hs.c) -- doesn't use a separate per-xfer
callout for timeouts (XXX but maybe should?)

- ugenhc (sys/rump/dev/lib/libugenhc/ugenhc.c) -- doesn't manage its
own transfer timeouts

- vhci -- times transfers out only on detach; could be adapted easily
if we wanted to use the xfer->ux_callout

show more ...

New function usb_task_pending for diagnostic assertions.

Usable only for negative diagnostic assertions:

KASSERT(!usb_task_pending(dev, task))

If you can think of a better name for this than !usb

New function usb_task_pending for diagnostic assertions.

Usable only for negative diagnostic assertions:

KASSERT(!usb_task_pending(dev, task))

If you can think of a better name for this than !usb_task_pending,
I'm all ears.

show more ...

Teach usb_rem_task to return whether removed from queue or not.

Move uvideo's parsers into usbdi.c, to make them global. Rename
usb_desc_iter_peek_next -> usb_desc_iter_peek for consistency.

add new usbd_do_request_len() that can allocate a larger than
request size buffer. reimplement usbd_do_request_flags() in
terms of this. use this for fetching string descriptors.

fixes a very stra

add new usbd_do_request_len() that can allocate a larger than
request size buffer. reimplement usbd_do_request_flags() in
terms of this. use this for fetching string descriptors.

fixes a very strange problem where an axe(4) attaching (either
has ugen(4) or axe(4)) would ask for 2 bytes, usb_mem.c would
allocate a 2 byte fragment, perform the operation, and sometime
shortly afterwards (usually by the time the next allocation
is made for this fragment), would become corrupted (usually
two bytes were written with 0x0304.)

(initial request of 4 bytes also avoids the problem on this
device. it really seems like a HC problem -- host should not
allow the device to write more than req.wLength! nor should
it allow this write to happen after completion.)

avoid an (almost) always double-log in usbd_transfer().

show more ...

Merge the [pgoyette-compat] branch

Fix usb_rem_task_wait API.

- Return whether it removed task from queue or not.
. True if it was on the queue and we intercepted it before it ran.
. False if we could not intercept it: either it

Fix usb_rem_task_wait API.

- Return whether it removed task from queue or not.
. True if it was on the queue and we intercepted it before it ran.
. False if we could not intercept it: either it wasn't queued,
or it already ran. (Up to caller to distinguish these cases.)
- Pass an optional interlock like callout_halt.

While here, simplify.

ok mrg@

show more ...

Add a port of the umb(4) driver from OpenBSD

The umb(4) driver provides support for USB MBIM (Mobile Broadband
Interface Model) devices.

MBIM devices establish connections via cellular networks suc

Add a port of the umb(4) driver from OpenBSD

The umb(4) driver provides support for USB MBIM (Mobile Broadband
Interface Model) devices.

MBIM devices establish connections via cellular networks such as GPRS,
UMTS, and LTE. They appear as a regular point-to-point network interface, transporting raw IP frames.

Required configuration parameters like PIN and APN have to be set with
umbctl(8), a new tool specific to this driver. The IP address is configured
automatically; the default route and DNS server information have to be set
separately.

The driver is not fully functional yet, it is therefore still marked as
experimental and disabled by default. Any help welcome to complete it!

Tested on NetBSD/amd64, with a Sierra Wireless EM7345 LTE modem on a Lenovo
ThinkPad T440s. No functional change expected otherwise.

show more ...

New function usb_rem_task_wait(dev, task, queue).

If task is scheduled to run, removes it from the queue. If it may
have already begun to run, waits for it to complete. Caller must
guarantee it wi

New function usb_rem_task_wait(dev, task, queue).

If task is scheduled to run, removes it from the queue. If it may
have already begun to run, waits for it to complete. Caller must
guarantee it will not switch to another queue. If caller guarantees
it will not be scheduled again, then usb_rem_task_wait guarantees it
is not running on return.

This will enable us to fix a litany of bugs in detach where we
currently fail to wait for a pending task.

show more ...

Change the SOFTINT level from NET to SERIAL for the USB softint handler.
This gives the callback a chance of running when another softint handler
at SOFTINT_NET has blocked holding a lock, e.g. softn

Change the SOFTINT level from NET to SERIAL for the USB softint handler.
This gives the callback a chance of running when another softint handler
at SOFTINT_NET has blocked holding a lock, e.g. softnet_lock and most of
the network stack.

Should fix/help
kern/49065 - ifconfig tun0 ... sequence locks up system / lockup: softnet_lock held across usb xfr
kern/50491 - unkillable wait in usbd_transfer while using usmsc0 on raspberry pi 2
kern/51395 - USB Ethernet makes xhci hang

and probably others

show more ...

Merge nick-nhusb

- API / infrastructure changes to support memory management changes.
- Memory management improvements and bug fixes.
- HCDs should now be MP safe
- conversion to KERNHIST based debu

Merge nick-nhusb

- API / infrastructure changes to support memory management changes.
- Memory management improvements and bug fixes.
- HCDs should now be MP safe
- conversion to KERNHIST based debug
- FS/LS isoc support on ehci(4).
- conversion to kmem(9)
- Some USB 3 support - mostly from Takahiro HAYASHI (t-hash).
- interrupt transfers now get proper DMA operations
- general bug fixes
- kern/48308
- uhub status notification improvements
- umass(4) probe fix (applied to HEAD already)
- ohci(4) short transfer fix

show more ...

Fix usb task queue locking.

Remove usbd_do_request_async. It's callback was calling usbd_free_xfer
from softint context.

Adjust callers appropriately

- usbd_clear_endpoint_stall_async is already triggered via a
usb_task,

Remove usbd_do_request_async. It's callback was calling usbd_free_xfer
from softint context.

Adjust callers appropriately

- usbd_clear_endpoint_stall_async is already triggered via a
usb_task, so simply call usbd_do_request.

- uhidev_set_report_async had one caller in ukbd_set_leds.
Convert this usage to use usb_task as well.

Discussed with mrg@

show more ...

Some lock comments.

usbd_open_pipe and usbd_open_pipe_intr take different flags! Make sure
the value of USBD_MPSAFE doesn't conflict with flags for either of them, as
it can be passed to both.

make USBD_TASKQ_MPSAFE the same value as USBD_MPSAFE, just in case

- Add a USBD_MPSAFE flag to usbd_open_pipe. If not set, acquire KERNEL_LOCK
before invoking xfer callbacks on this pipe.
- Add an extra flags parameter to usb_init_task. If USBD_TASKQ_MPSAFE is not

- Add a USBD_MPSAFE flag to usbd_open_pipe. If not set, acquire KERNEL_LOCK
before invoking xfer callbacks on this pipe.
- Add an extra flags parameter to usb_init_task. If USBD_TASKQ_MPSAFE is not
present, acquire KERNEL_LOCK before invoking the task callback.

show more ...

commit my workaround for PR 46648 for now, as the more involved
fix is not ready yet:

move the clear endpoint stall async call into the task thread,
to avoid trying to call kmem_alloc() from a softi

commit my workaround for PR 46648 for now, as the more involved
fix is not ready yet:

move the clear endpoint stall async call into the task thread,
to avoid trying to call kmem_alloc() from a softint thread.

XXX ideally moving callbacks into the task thread (or perhaps
a different high priority task thread) would be better than this
workaround, once that method is working.

show more ...