usb *hci: Always set ux_status before usbd_xfer_schedule_timeout.

Add an assert to usbd_xfer_schedule_timeout to enforce this.

Since access to ux_status is serialized by the bus lock, and nothing
releases the bus lock in the interim, this doesn't make a functional
change. But it does reduce confusion by readers, who no longer have
to worry if some callers got the order wrong. It could also now
potentially be factored out in a subsequent commit.

fix various typos in comments and log messages.

fix spelling mistakes, mainly in comments and log messages.

avoid different struct type problem.

Fix DMA sync flags in ehci_append_sqtd

update my email address.

ehci(4): Fix bug causing missed wakeups since ehci.c 1.308.

For reasons beyond me now, I used cv_signal on the same cv that is
used to wait for the doorbell to be available _and_ to wait for the
host controller to acknowledge the doorbell. Which means when the
host controller acknowledges the doorbell, we might wake some thread
waiting for the doorbell to be available -- and leave the thread
waiting for the doorbell acknowledgment hanging indefinitely.

PR port-i386/57662

XXX pullup-10

ehci(4): Fix cv_timedwait loop in ehci_sync_hc.

Stop when

now - starttime >= delta,

i.e., when at least delta ticks have elapsed since the start, not
when

endtime - now > delta,

i.e., more than delta ticks _remain_ to sleep, which is never going
to happen (except on arithmetic overflow).

As is, what will happen in the case that should time out is that we
wake up after delta ticks, and find now = getticks() is exactly
endtime, so we retry cv_timedwait with timo=(endtime - now)=0 which
means sleep indefinitely with no timeout as if with cv_wait.

PR port-i386/57662

XXX pullup-10

PR//57518: usb keyboard causes host controller to miss microframe

As per the USB 2.0 specification section 11.18.4; paragraph 3.b

For interrupt IN/OUT full-/low-speed transactions, the host must schedule a
complete-split transaction in each of the two microframes following the first
microframe in which the full-/low-speed transaction is budgeted. An additional
complete-split must also be scheduled in the third following microframe unless
the full-/low-speed transaction was budgeted to start in microframe Y6.

various debug updates for some usb drivers

- several new *_DEBUG_DEFAULT options that allow usb debug values to
be set to a default that is non-zero:
EHCI_DEBUG_DEFAULT, UGEN_DEBUG_DEFAULT, URTWN_DEBUG_DEFAULT,
UMS_DEBUG_DEFAULT, and USB_DEBUG_DEFAULT
- ugen debug uses fewer usbhist lines for the same info
- ums.c converted from printf() to usbhist

branches: 1.315.2;
fix grammar in comment

ehci_device_isoc_init() returns errno not usbd_error; remove blank line
in ehci_device_fs_isoc_init() to match ehci_device_isoc_init()

"periodic frame list", not "period frame list" in comments

Add missing whitespace in error message.

revert accidental last commit (except ukbd.c)

remove debug printf

ehci(4): Serialize access to portsc registers.

Both ehci_roothub_ctrl and ehci_suspend/resume do r/m/w on them, so
use a mutex to serialize access to avoid stomping on each other.

ehci(4): Fix doorbell synchronization.

ehci_sync_hc was previously subject to spurious wakeup, in which case
the CPU might proceed from aborting and recycle a DMA buffer before
the hardware was done writing to it. Now the code is not subject to
spurious wakeup -- it waits (up to the 1sec timeout) for the relevant
interrupt to be delivered, not for anything else.

ehci(4): Omit bus lock around ehci_suspend/resume.

This no longer serializes access to the portsc registers, also used
by ehci_roothub_ctrl, but it does pose a potential deadlock with
softints to wake usb_delay_ms. So the bus lock doesn't help here,
and may cause deadlock.

usb: Provisionally release bus lock around ubm_rhctrl.

This isn't quite correct, but it avoids a deadlock:

- *_roothub_ctrl holds bus lock, waits in usb_delay_ms for kpause
- softint waits for bus lock, holds up kpause wakeup

The deadlock is new since recent changes to hold the bus lock over
upm_start/upm_transfer. Making this change regresses to other
problems:

- *_suspend/resume and *_roothub_ctrl often touch the same portsc
registers

- roothub_ctrl_abort needs to wait for ubm_rhctrl to complete.

When the bus lock was held across both, a noop served here, but we
can't hold the bus lock across both, so that doesn't work.

However, these problems -- which we've had for a long time -- seem to
be less bad than the deadlock. So let's avoid the deadlock for now
and then work out another way to serialize suspend/resume/rhctrl and
aborts.

Candidate fix for PR kern/56739.

usb: Hold pipe lock across upm_transfer and upm_start.

This simplifies the code and fixes races with abort. Access to the
pipe's queue is now done exclusively while the pipe is locked.

usb: Factor usb_transfer_complete out of ubm_abortx method.

usb: Factor usb_insert_transfer out of upm_transfer and make private.

Almost every upm_transfer function starts with:

mutex_enter(&sc->sc_lock);
err = usb_insert_transfer(xfer);
mutex_exit(&sc->sc_lock);
if (err)
return err;

Some of them have debug messages sprinkled in here too, or assert
that err == USBD_NORMAL_COMPLETION (alternative is USBD_IN_PROGRESS,
only for pipes with up_running or up_serialise, presumably not
applicable for these types of pipes). Some of them also assert
xfer->ux_status == USBD_NOT_STARTED, which is guaranteed on entry and
preserved by usb_insert_transer.

Exceptions:

- arch/mips/adm5120/dev/ahci.c ahci_device_isoc_transfer just returns
USBD_NORMAL_COMPLETION, but I'm pretty sure this is and always has
been broken anyway, so won't make anything worse (if anything, might
make it better...)

- external/bsd/dwc2/dwc2.c dwc2_device_bulk_transfer and
dwc2_device_isoc_transfer _also_ issue dwc2_device_start(xfer)
under the lock. This is probably a better way to do it, but let's
do it uniformly across all HCIs at once.

- rump/dev/lib/libugenhc/ugenhc.c rumpusb_device_bulk_transfer
sometimes returns USBD_IN_PROGRESS _without_ queueing the transfer,
in the !rump_threads case. Not really sure how this is supposed to
work... If it actually breaks anything, we can figure it out.

initialize ntag with the old dmatag so we never end up with an invalid one
suggested by jmcneill@

shut up an unused variable warning
apparently clang gets confused by bus_dmatag_subregion() being EOPNOTSUPP
on powerpc

convert the ehci device owner ship change message to display the ehciN as well.

ehci(4): fix PR kern/56574: uaudio at ehci (not xhci) only outputs
rapid gunfire (patch from nick)

Use the correct dmatag for all control structures. Also, don't KASSERT that
we're using the low 4GB for them and simply error out.

kern/56570: ehci panic on boot

Three fixes

- pass the 64bit DMA tag if the HCCPARAMS says ehci supports it and the
64bit DMA tag is available/valid. This should help with the
"cannot create xfer" error on 64bit systems.

- restrict the control structure memory allocation to the low 4GB
(CTRLDSSEGMENT was always set to zero anyway)

- if ehci_init fails then tidyup before returning the error.

Whitespace

Remove an empty line

Wrap a long line

Change the usb_mem API to take a bus_dma_tag_t in usb_allocmem instead of
a struct usbd_bus *.

This allows an HCD to use more than one tag.

KASSERT(BUS_ADDR_HI32(baddr) == 0) in, and apply some consistent code
style to all of ehci_alloc_{sqh,sqtd,itd,sitd}.

While ehci can address memory >4GB for control structures
EHCI_CTRLDSSEGMENT is always set to zero so ehci assumes it's using the
low 4GB.

Fix two bugs

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.

Match variable names to register names. Same binary before and after.

More usb_status_t -> int

Code consistency. NFCI.

ehci: Replace bogus polling during suspend by taking bus lock.

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.

add missing newline and fix conditional for askroot/single user
hand over delay message. PR#56366.

More converstion from usbd_status to int for function error reporting.
This time it's the turn of usb_allocmem.

usb: Omit bogus assertions about struct usbd_pipe::up_intrxfer.

These assertions were only valid for pipes at UE_IN_DIR, UE_INTERRUPT
endpoints created with usbd_open_pipe_intr, which uses up_intrxfer to
pass the struct usbd_xfer object to usbd_close_pipe to free later.

In contrast, for pipes at UE_OUT_DIR, UE_INTERRUPT endpoints,
up_intrxfer is never initialized, so the assertion cannot be right.
In principle we might even have more than one outstanding interrupt
transfer at a time, rendering the point of the assertion moot anyway.

Found by interrupting a uhidev write to a u2f device.

ok nick

s/ we we / we /

branches: 1.282.2;
Talk Like a Pirate Day was yesterday.

Copyright maintenance

Use BUS_ADDR_{LO,HI}32. NFCI.

Update ux_length in usbd_setup_isoc_xfer and use this to usb_syncmem
in the HCDs

Switch USB to use non-coherent buffers for data transfers in the
same way as OpenBSD.

The use of coherent (uncacheable on ARM and other arches) mappings
for transfer buffers impacts performance, espcially where memcpys
are involved.

Audit the necessary usb_syncmem operations - a few were missing.

revert the 0x% -> %# change for fixed width formats pointed out by uwe.

PR/55068: sc.dying: Fix printf formats:
- no %s/%p for kernel log
- 0x% -> %#
- always %j for kernel log

Use howmany. NFC.

Fix a memory leak. Spotted by nat@

Fix mistakes in previous sloppy change with root intr xfers.

- Make sure ux_status is set to USBD_IN_PROGRESS when started.
Otherwise, if it is still in flight when we abort the pipe,
usbd_ar_pipe will skip calling upm_abort.

- Initialize ux_status under the lock; in principle a completion
interrupt (or a delay) could race with the initialization.

- KASSERT that the xfer is in progress when we're about to complete
it.

Candidate fix for PR kern/54963 for other HCI drivers than uhci.

ok nick
ok phone

(This is the change that nick evidently MEANT to ok when he ok'd the
previous one!)

Fix steady state of root intr xfers.

Why?

- Avoid completing a root intr xfer multiple times in races.
- Avoid potential use-after-free in poll_hub callouts (uhci, ahci).

How?

- Use sc->sc_intr_xfer or equivalent to store only a pending xfer
that has not yet completed -- whether successfully, by timeout, or
by synchronous abort. When any of those happens, set it to null
under the lock, so the xfer is completed only once.

- For hci drivers that use a callout to poll the root hub (uhci, ahci):

. Pass the softc pointer, not the xfer, to the callout, so the
callout is not even tempted to use xfer after free -- if the
callout fires, but the xfer is synchronously aborted before the
callout can do anything, the xfer might be freed by the time the
callout starts to examine it.

. Teach the callout to do nothing if it is callout_pending after it
has fired. This way:

1. completion or synchronous abort can just callout_stop
2. start can just callout_schedule

If the callout had already fired before (1), and doesn't acquire
the bus lock until after (2), it may be tempted to abort the new
root intr xfer just after submission, which would be wrong -- so
instead we just have the callout do nothing if it notices it has
been rescheduled, since it will fire again after the appropriate
time has elapsed.

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

Fix steady state of timeouts in ehci.

This is complicated because:

1. There are three ways that an xfer can be completed:
(a) hardware interrupt completes xfer
(b) software decision aborts xfer with USBD_CANCELLED
(c) timeout aborts xfer with USBD_TIMEOUT

2. The timeout abort can't be done in callout because ehci_sync_hc,
called unconditionally by ehci_abort_xfer to wait until the device
has finished using any references to the xfer, may sleep. So we
have to schedule a callout that, when run, will schedule a usb_task.

3. The hardware completion interrupt can't sleep waiting for a callout
or task to finish -- can't use callout_halt or usb_rem_task_wait.
So the callout and usb_task must be able to run _after_ the hardware
completion interrupt, and recognize that they're late to the party.

(Note, though, that usbd_free_xfer does wait for the callout and
task to complete, so there's no danger they may use themselves after
free.)

4. The xfer may resubmitted -- and the timeout may be rescheduled --
immediately after the hardware completion interrupt, _while_ the
callout and/or usb_task may still be scheduled. Specifically, we
may have the following sequence of events:
(a) hardware completion interrupt
(b) callout or usb_task fires
(c) driver resubmits xfer
(d) callout or usb_task acquires lock and looks around dazed and
bewildered at the firehose of events like reading the news in 2019

The mechanism for sorting this out is that we have two bits of state:

- xfer->ux_timeout_set informs the driver, when submitting an xfer and
setting up its timeout, whether either the callout or usb_task is
already scheduled or not.

- xfer->ux_timeout_reset informs the callout or usb_task whether it
should reschedule the callout, because the xfer got resubmitted, or
not.

don't call usb_syncmem() for zero-length packets.

branches: 1.268.2;
Remove a stray '

branches: 1.267.2;
Random style in ehci, also KM_SLEEP does not fail.

Fix assertion failures triggered by usbdi.c,v 1.182, when devices
are detached.

This is because xfers of USBD_NOT_STARTED can be removed from queue
in an invisible way to host controller drivers.

Discussed on tech-kern.

implement a gross hack to fix "boot -a" on systems with usb keyboards on
systems with ehci handover to uhci (and maybe ohci), and fix a similar
problem for "boot -s".

there is effort to ensure that all devices attached via USB are probed
before RB_ASKNAME or RB_SINGLE attempts to ask any questions on the console,
and largely this works, often by chance, today, for USB disks and root.
i've recently pushed this more into uhub and general USB device attachment
as well, and kept a config_pending reference across the first explore of
a bus. these fix many issues with directly attached hubs.

however, on systems where devices connected to ehci ports are handed over
to a companion uhci or ohci port, it may not be the first, or even second,
bus explore that finds the device finally before attachment, and at this
point all config_pending references are dropped.

there is no direct communication between drivers, the potentials are
looked up but their device_t is only used for generic things like the name,
so informing the correct companion to expect a device and deal with the
config_pending references is not possible without some fairly ugly layer
violations or multi-level callbacks (eg, we have "ehci0", and usually an
the relevant companion, eg, "uhci2", but it is the uhub that uhci2 has
attached that will deal with the device attachment.)

with the above fixes to generic USB code, the disown happens during the
first explore. the hack works by, at this point, checking if (a) root
is not mounted, (b) single user or ask name are set, and (c) if the hack
as not been triggered already. if all 3 conditions are true, then a
config_pending_incr() is called and a callback is triggered for (default)
5 seconds to call config_pending_decr(). ehci detach pauses waiting for
this callback if scheduled.

this allows enough time for the uhub and the ukbd/wskbd to attach before
the RK_ASKROOT prompts appear. testing shows it takes between 1.5 and
2 seconds for the keyboard to appear after the disown occurs.


Index: dev/usb/ehcivar.c
- new sc_compcallout, sc_compcallout, sc_complock, and a state for th
handover hack.

Index: dev/usb/ehci.c
ehci_init():
- use aprint_normal_dev() instead of manual device_xname().
- initialise sc_compcallout, sc_compcallout, sc_complock, and sc_comp_state.
ehci_detach():
- if there are companion controllers, tear own the above, including waiting
if there is a callback scheduled.
ehci_disown_callback():
- new callout to call config_pending_decr() in the the future.
schedule this ca
ehci_disown_sched_callback():
- if booting to single user or asking names, call config_pending_incr() and
schedule the callout above, default 5 second delay.
ehci_disown():
- if disowning a port call ehci_disown_sched_callback().

consolidate the handling of polling across HC drivers, and generic USB:
- don't take mutexes if polling
- normalise the code across all drivers
- add some not yet code to block discovery to/from polling
- minor CSE
- adjust comment for usbd_set_polling() to reality now i properly
understand what it is used for and why.

this, with a hack to make RB_ASKNAME to wait 5 seconds allows boot -a
work with USB keyboards. there are still multiple issues remaining:
- discovery and polling need to be mutually exclusive
- attachment of ukbd and wskbd is not handled by config_pending, and
the 5 second delay isn't going to always be enough.

interrupt has two 'r's

fix another typo while I'm here (flsah)

Rename min/max -> uimin/uimax for better honesty.

These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.

HOWEVER! Some subsystems have

#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))

even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.

To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.

I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:

cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))

It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.

Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)

fix DIAGNOSTIC build by not copying ub_usepolling to stack before use

pull across abort fixes from nick-nhusb. add more abort fixes, using
ideas from Taylor and Nick, and myself. special thanks to both who
inspired much of the code here, if not wrote it directly.

among other problems, this assert should no longer trigger:

panic: kernel diagnostic assertion "xfer->ux_state == XFER_ONQU" failed: file "/current/src/sys/dev/usb/usbdi.c", line 914

using usbhist i was able to track down my instance of it being related
to userland close() beginning, dropping the sc_lock, and then the usb
softintr completes the transfer normally, and when it is done, the
abort path attempts to re-complete the transfer, and the above assert
is tripped.


changes from nhusb were commited with these logs:
--
Move the struct usb_task to struct usbd_xfer for everyone to use.
--
Set device transfer status to USBD_IN_PROGRESS if start methods succeeds
--
Actually set the transfer status on transfers in ohci_abort_xfer and
the controller is dying
--
Don't supply the lock to callout_halt when polling as it won't be held
--
Improve transfer abort
--
Mark device transfers as USBD_IN_PROGRESS appropriately and improve
abort handling
--
#ifdef DIAGNOSTIC -> KASSERT and add another KASSERT
--
Mark device transfers as USBD_IN_PROGRESS appropriately and improve
abort handling
--

additional changes include:
- initialise the usb abort task in the HCI allocx routine, so that it
can be safely usb_rem_task()'d.
- rework the handling of softintr vs cancellation vs timeout abort based
upon a scheme from Taylor:
when completing a transfer normally:
- if the status is not in progress, it must be cancelled or timed out,
and we should not process this xfer.
- set the status as normal.
- unconditionallly callout_stop() and usb_rem_task(). they're safe and
either aren't running, or will run and do nothing.
- finally call usb_transfer_complete().
when aborting a transfer:
- status should be cancelled or timed out.
- if cancelling, callout_halt and usb_rem_task_wait() to make sure the
timer is either done or cancelled.
- at this point, the ux_status must not be cancelled or timed out, and
if it is not in progress we're done.
- set the status.
- if the controller is dying, just return.
- perform HCI-specific tasks to abort this xfer.
- finally call usb_transfer_complete().
for the timeout and timeout task:
- if the HCI is not dying, and the ux_status is in progress, then
trigger the usb abort task.
- remove UXFER_ABORTWAIT and UXFER_ABORTING.

tested on:
- multiple PC systems with several types of devices: ugen/UPS, ucom,
umass with disk, ssd and cdrom backends, kbd, ms, using uhci, ehci
and xhci.
- erlite3: sd@umass on dwc2.
- sunblade2000: kbd/ms and umass disk on ohci.

untested:
- motg, slhci and ahci. motg has some portion of the new scheme
applied, but slhci and ahci require more study.

future work includes pushing a lot of the common abort handling into
usbdi.c and leaving upm_abort() for HC specific tasks, but this change
is pullup-able to netbsd-7 and netbsd-8 as it does not change any
external API, as well as removing over 100 lines of code while adding
over 30 new asserts.

XXX: pullup-7, pullup-8.

branches: 1.259.2;
Remove duplicate ;

Stop potential misuse of vendor names and USB vendor IDs in root hub
device and string descriptors.

Firstly: Few vendors have identical PCI-SIG vendor IDs and USB-IF vendor
IDs. As such, using the PCI vendor ID as a USB vendor ID may trample
on whomever is allocated that USB vendor ID.

Secondly: The vendor of the host controller hardware implementation has
little to nothing to do with our usbroothub implementation. Thus we
should not potentially associate any problems therewith to such third
party.

This change will result in root hubs being identified by USB Vendor ID
0x0000. Root hub vendor string will now be "NetBSD" (or, specifically:
ostype). Product ID (0x0000) and product strings remain unchanged.

branches: 1.257.2;
s/PR_NOWAIT/PR_WAITOK/ in HCD allocx (allocate xfer) method

Update the kernhist(9) kernel history code to address issues identified
in PR kern/52639, as well as some general cleaning-up...

(As proposed on tech-kern@ with additional changes and enhancements.)

Details of changes:

* All history arguments are now stored as uintmax_t values[1], both in
the kernel and in the structures used for exporting the history data
to userland via sysctl(9). This avoids problems on some architectures
where passing a 64-bit (or larger) value to printf(3) can cause it to
process the value as multiple arguments. (This can be particularly
problematic when printf()'s format string is not a literal, since in
that case the compiler cannot know how large each argument should be.)

* Update the data structures used for exporting kernel history data to
include a version number as well as the length of history arguments.

* All [2] existing users of kernhist(9) have had their format strings
updated. Each format specifier now includes an explicit length
modifier 'j' to refer to numeric values of the size of uintmax_t.

* All [2] existing users of kernhist(9) have had their format strings
updated to replace uses of "%p" with "%#jx", and the pointer
arguments are now cast to (uintptr_t) before being subsequently cast
to (uintmax_t). This is needed to avoid compiler warnings about
casting "pointer to integer of a different size."

* All [2] existing users of kernhist(9) have had instances of "%s" or
"%c" format strings replaced with numeric formats; several instances
of mis-match between format string and argument list have been fixed.

* vmstat(1) has been modified to handle the new size of arguments in the
history data as exported by sysctl(9).

* vmstat(1) now provides a warning message if the history requested with
the -u option does not exist (previously, this condition was silently
ignored, with only a single blank line being printed).

* vmstat(1) now checks the version and argument length included in the
data exported via sysctl(9) and exits if they do not match the values
with which vmstat was built.

* The kernhist(9) man-page has been updated to note the additional
requirements imposed on the format strings, along with several other
minor changes and enhancements.

[1] It would have been possible to use an explicit length (for example,
uint64_t) for the history arguments. But that would require another
"rototill" of all the users in the future when we add support for an
architecture that supports a larger size. Also, the printf(3) format
specifiers for explicitly-sized values, such as "%"PRIu64, are much
more verbose (and less aesthetically appealing, IMHO) than simply
using "%ju".

[2] I've tried very hard to find "all [the] existing users of kernhist(9)"
but it is possible that I've missed some of them. I would be glad to
update any stragglers that anyone identifies.

Remove the requirement for ehci to attach after companion devices.

"go for it" - skrll@

branches: 1.254.8;
Improve diagnostic print seen in PR 51524.

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

branches: 1.252.2;
Only set QH CMASK for FS/LS interrupt transfers

Fix a KASSERT (ub_usepolling || mutex)

usb is attached with config_interrupts so we can G/C the code to support
transfers when this wasn't the case.

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

KNF

Don't need to nest #ifdef EHCI_DEBUG

eliminate USBHIST as a define/option. it was entangled with USB_DEBUG
and only referenced a handful of times. rename any usage in configs.

fixes recent build problems i introduced with the previous files.usb
change.

Fix up USBMODE registers in sc_vendor_init functions and not in the ehci
driver.

add some _KERNEL_OPT as the finishing touch

More IPL_SCHED -> IPL_USB

Use correct E[O]{READ,WRITE} function.

Somehow the ; disappeared from the previouis commit

From FreeBSD rev1.30 via OpenBSD:
- always initialise the pipe multiplier to a valid value
- do not unchain the the interrupt QHs immediately after initialisation

Prompted by msaitoh

Remove '\n' from panic message.

Fix previous for HEAD

Improve debug

Whitespace

Typo in USBHIST_LOG message

branches: 1.234.2;
Wrap a long line

Use lower case for USBHIST messages.

Whitespace.

Fix reversed argument to USBHIST_LOG

Fix build when USB_DEBUG is defined and EHCI_DEBUG isn't. The converse is
always true.

PR/49201 (broken build with options USB_DEBUG (latest current))

Improve USB debugging with USBHIST based on KERNHIST.

Convert some DPRINTFs to USBHIST_LOG and allow usbdebug, ehcidebug and
umassdebug to be changed via sysctl.

Remove the #define mess in usb.h.

This was started by mrg@ and updated by reinoud@

branches: 1.228.2; 1.228.6;
Remove #ifdef DIAGNOSTIC around sc from the root interrupt abort methods
now it's always used.

Simplify the freeing of the interrupt pipe transfer. Inspired by OpenBSD.

Fix duplicate assignment to NULL of sqtdstart in ehci_device_isoc_start
and initialise sqtdend is NULL instead.

From OpenBSD.

branches: 1.225.2;
Re-establish the default pipe after the initial reading of the device
descriptor.

This fixes usbd_new_device so that there is no really need to touch
QHs/EDs in [eo]hci_device_request.

KASSERT the address and maximum packet length now.

Backout the ED/QH change removal in [eo]hci_device_request.

Reports of the KASSERT firing mean this needs more thought/testing.

mark variable usage, fix non DIAGNOSTIC non DEBUG build

Now that usbd_new_device has been fixed there is no need to touch QHs/EDs
in [eo]hci_device_request.

KASSERT the address and maximum packet length just in case.

In ehci_check_qh_intr don't treat a short control transfer as done if the
status phase is still inflight. Let the hardware complete it.

PR/48358: Repeated low-speed USB control transfers returning short data
fail on EHCI

PR/46696: uhub disables port where USB keyboard attached

Adjust KASSERT in device_ctrl_done to polling case.

PR/48213: ehci assertion failure during boot

Improve DEBUG message.

Improve DEBUG output.

Simplify debug/DIAGNOSTIC code.

Whitespace in DIAGNOSTIC code.

mark a variable __diagused

Style.

Add an explicit initialization of .new_device = NULL

Remove unused variables

add KASSERT to make sure softints are not NULL

Typo.

Use UE_GET_XFERTYPE. No functional change.

swap positions of ehci_root_ctrl_done and ehci_root_intr_done so that they
are grouped with their respective transfer types

branches: 1.207.2;
Change "translater" to "translator" in comment.

Don't take the bus lock in usbd_transfer_complete when polling.

Sprinkle || polling in KASSERTsw

Call usb_syncmem() against descriptors more strictly.
(not sure if the previous ones were fatal though)

use a pool instead of a linked list to avoid synchronization problems.

- 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.

fix the fix of the fix of the format string.

Fix a debug printf format.

fix printf formats

don't use kprintf() directly, it does not lock so it just garbles the output.

Remove unused length member of ctrl xfer in struct ehci_pipe

Allow USB memory allocation by multiple segments in scatter/gather lists
rather than in a single contiguous block which causes problems with
large USB video frames.
Based on a patch by Jeremy Morse in the thread
http://mail-index.netbsd.org/current-users/2011/01/26/msg015532.html
Tested by developing http://code.opencv.org/issues/2360
OK jmcneill@

fix debug variables.
- include opt_usb.h in usb.h so that USB_DEBUG gets set properly in it.
- normalize and sort debugging variables

- need opt_usb.h if depending on USB_DEBUG
- remove trailing whitespace
- add missing KERNEL_RCSID

KNF a comment.

Fix ETTF PSPD definitions and enable the ETTF PORTSC detection.
Fix EHCI portion of PR/47156.

branches: 1.192.2;
fix locking for isoc transfers, as reported (and the fix tested) by prlw1.

Typos in comments.

merge the jmcneill-usbmp branch. many thanks to jared for the
initial work, and every one else who has tested things for me.
this is largely my fault at this point :-)

the main changes are something like:

- usbd_bus_methods{} gains a get_lock() to enable the
host controller to provide a lock for the USB code.
if the lock isn't provided, old-style protection is
(partially) applied.

- ehci/ohci/uhci have been converted to the new
interfaces, including mutex/cv/etc conversion.

- usbdivar.h contains a discussion about locking and
what locks are held for which method calls. more
to come for usbdi(9) here.

- audio drivers (uaudio, umidi, auvitek) have been
properly SMPified now that USB is ready.

- scsi drivers have been modified to take the kernel
lock explicitly before calling into scsi code.

- usb pipes are associated with a lock, that is the
same as the controller lock. (this could be split
up further in the future.)

- several usbfoo_locked() or usbfoo_unlocked()
functions have been added to the usbdi(9) to
enable functionality with or without the USB
lock (per controller) already being held.

the TODO.usbmp file has specific details on what is left to
do, including what device-specific changes should be done now
that the whole framework is ready.

Always check index against array bound; keep only the printf under
DIAGNOSTIC. Suggested by matthew green

Do not read array before detecting array overflow, found by gcc -O3

pull down from usbmp branch:
- remove usbd_bus{} intr_context member, and replace the checks against
it with cpu_intr_p() and cpu_softintr_p().

pull down from usbmp branch:

- rename usb_detach_{wake,waitup}() to usb_detach_{wake,waitup}old()
- use some c99 struct .initialisers

pull down from usbmp:

kill the !USE_USE_SOFTINTR code.

pull down from usbmp branch:

- remove SPLUSBCHECK. it has been broken and disabled for ages.

branches: 1.183.2; 1.183.6; 1.183.8;
Revert previous due to active usbmp branch(es).

Adjust-away inconsistent and trailing whitespace.

branches: 1.181.2; 1.181.6;
use an unsigned type for unsigned calcations. avoid GCC 4.5 warnings.

dependant -> dependent

ehci_set_qh_qtd: terminate alternate next qTD pointer with EHCI_NULL, not 0

Move EHCI_DEBUG, OHCI_DEBUG, UHCI_DEBUG, USB_DEBUG, UHUB_DEBUG to opt_usb.h
(ya dependencies).
Cleanup usb_mem.c a little more and add block tracking code. Help find
corruption problems.
Comment out the SPEED check for ETTF. XXX why doesn't that work right?

branches: 1.177.2;
Revert changes for PR kern/44907
http://mail-index.NetBSD.org/source-changes/2011/05/27/msg022584.html
for now. It might cause a panic in ehci_freex() on device detach
as reported by Paul Goyette on current-users@.

Apply patch in PR kern/44907 (crash due to race in ehci.c):
- make sure to remove abort_task in ehci_freex
- always initialize abort_task in ehci_allocx,
not in ehci_timeout just before adding the task
Also apply similar fixes to ohci and uhci.

XXX: should we also call abort_task handler before removing it from queue
if *hci_freex() is called for usbd_xfer_handle with queued abort_task?

remember the data toggle bit per (bulk) endpoint rather than per
pipe, as required by the spec
This helps in cases where pipes are opened/closed without reconfiguring
the device in between, eg with the ugen driver.
only for UHCI/EHCI, don't have an OHCI to test

in alloc_sqtd_chain(), deal with the case where a data packet ends
exactly at a page boundary, and the FORCE_SHORT_XFER was set by the
client (which causes that an empty descriptor is needed to terminate
the transfer), from Gordon McNutt per PR kern/44883
(fixed a bit differently than the proposed patch for aesthetical
reasons -- avoids the page pointer to come into unexpexted area earlier)

fix port reset for non-ETTF case broken by previous commit

Add preliminary support for Embedded Transaction Translator Function (as
found on the MPC8536 and AR9334) which allows low/full devices to be
connected to an EHCI root hub.

branches: 1.171.2;
Stop using the compatibility macros USB_ATTACH(), USB_DETACH(),
USB_MATCH(), et cetera. These files produce the same assembly
(according to objdump -d) before and after the change

Add vendor dependent functions.
sc_vendor_init()/sc_vendor_port_status().

For interrupt transfer, nak throttling must be disabled, but for the other
transfer type, nak throttling should be enabled from the veiwpoint that
avoids the memory thrashing. Fixes a problem that interrupt transfer stall
on some EHCI controllers (e.g. Geode LX). Fixed by Yamada Katsumi.

Improve EHCI isochronous code, fix scheduling.

- Create and use symbolic constants.

- Convert some switch statements to functionally-similar caculations.

- Correct scheduling interval of high-speed isochronous transactions.
Previous calculation produced half the intended rate.

Nvidia EHCI controllers do not ignore one or more of the "Port Number",
"Hub Address", "Split Completion Mask" fields in the Queue Head marked
"This field is ignored by the host controller unless the EPS field
indicates a full- or low-speed device.".

Therefore, only populate these fields for full- and low-speed devices.

Fixes PR#37884.

branches: 1.166.2;
A pointer typedef entails trading too much flexibility to declare const
and non-const types, and the kernel uses both const and non-const
PMF qualifiers and device suspensors, so change the pmf_qual_t and
device_suspensor_t typedefs from "pointers to const" to non-pointer,
non-const types.

branches: 1.165.2;
Expand PMF_FN_* macros.

Sprinkle static.

Simplify activation hook.

(sc_dying must die!)

EHCI_NULL is already little-endian. No htole32() needed. Pointed out by
Tsubai Masanari.

Fix some whitespaces.

Update referencial URLs.

Expand <dev/usb/usb_port.h> definitions, and lightly unifdef(1).

Wrap ehcidebug in EHCI_DEBUG, not USB_DEBUG.

Ansify function definitions w/o arguments. Generated with sed.

branches: 1.156.2;
replace bitmask_snprintf(9) with snprintb(3)

Fixed high-speed isoc USB transfers, 64 bit capable host controllers have a different transfer descriptor to non-capable controllers.

Added dma-sync of data buffer before scheduling transfers

branches: 1.154.2; 1.154.4;
ehci_dump_itd and _sitd are unused

kern/39727: race condition in ehci isoc abort xfer path

From Jeremy Morse:

* Serialize access to the ehci intrlist.
* Change the ehci intrlist to a tailq so xfers are not queued out of order.
* In ehci_check_itd_intr, don't treat a transfer error as an indication
that the xfer is no longer active.

Revert previous.

ehci_check_itd_intr: correct logic for checking for active itds

ehci_free_itd: use LIST_INSERT_HEAD rather than
LIST_INSERT_AFTER(LIST_FIRST(..), ..) when returning itds to the freelist
to prevent a crash when the freelist is empty. Reviewed by Jeremy Morse.

Fix issue where multi-transaction isoc endpoints were forced to single
transactions, from Jeremy Morse.

update TODO list: we have isoc support

Sign over copyright of Jeremy Morse's code to TNF, OK'd by Jeremy Morse
(still mention Jeremy as contributor)

Clarify the message printed by the kernel when a low or full speed
device with isochronous endpoints is attached to a hi-speed hub. Also
silence a printf in ehci_device_isoc_close

add a "break" so that the isoc setup code doesn't access uninitialized
data if the frames allocated by a client driver don't use up all the
microframes within a frame

use M_NOWAIT in an early allocation for consistency, from Kevin Lo

fix my last commit: add missing "break"s, from Marcus Glocker

fix an off-by-one in isochronous interval check, and streamline some
frame / microframe calculation, avoiding overestimation of frames needed,
reviewed by Jared D. McNeill

make i386 ALL kernel compile

Update copyright.

High speed isochronous support, from Jeremy Morse as part of Google
Summer of Code 2008.

branches: 1.138.2;
Add appropriate bus_dmamap_sync() calls to uhci(4), ohci(4) and ehci(4),
as proposed on tech-kern@.
While all DMA memory used in the USB framework is mapped BUS_DMAMAP_COHERENT
(including data memory, which is memcpy'd from/to USB-private buffers),
the CPU can reorder loads or stores from/to main memory, causing the
controller to have an incoherent view of the DMA descriptors lists for a
short time. bus_dmamap_sync() should contain memory barriers that prevents
the CPU from reordering load/store. Note that BUS_DMAMAP_COHERENT is
still required for the DMA descriptor lists - these can't work properly
with software cache coherency.
This fixes "host controller process error/host controller halted" errors
I'm occasionally seeing with a umodem device on uhci on x86.
Thanks to Michael Lorenz for testing it on his O2, and Izumi Tsutsui on
his Cobalt Qube 2700.

fix selective port resume signaling (not used in normal operation,
just for correctness)

branches: 1.136.2;
fix argument to usb_setup_reserve() (called from USB host adapter drivers)
to be device_t consistently, from Quentin Garnier

branches: 1.135.2;
Remove clause 3 and 4 from TNF licenses

branches: 1.134.2; 1.134.4;
split device/softc for USB host controllers and the usb (control)
device,
this is hairy stuff, and I've only tested with uhci/ehci at pci,
please test the rest and report problems

Use device_t and accessors. Setup power management in the PCI
front-end (XXX needs to look more alike the Cardbus front-end).
Establish the shutdown hook using PMF.

Add a method to detach child.

Cosmetic: use device_t and accessors. Use aprint_*_dev(). Use
PMF_FN_{ARGS,CALL,PROTO}.

branches: 1.131.2; 1.131.6;
share some code for USB root hub emulation which is common in the 3
host controller implementations, start with two little functions
which fake up string descriptors (which were inconststent, language
table fetching didn't interoperate with other code in the tree)

No need to operate in polling mode in ehci_resume.

Ensure that we don't clear the EHCI_PS_CLEAR bits by writing 1s to them
when modifying port state in ehci_suspend and ehci_resume.

Release port ownership on detach, so devices will be routed to companion
controllers. This allows 'drvctl -d ehci0' to disable USB 2.0 mode.

Merge jmcneill-pm branch.

branches: 1.126.2;
lockmgr -> mutex

branches: 1.125.2; 1.125.4;
machine/{bus,cpu,intr}.h -> sys/{bus,cpu,intr}.h

branches: 1.124.2; 1.124.6;
* splsoftusb, IPL_SOFTUSB, and IPL_HARDUSB defines in usbdi.h
-> the current names are confusing (didn't change other drivers)
* fix invalid memory access in usbd_transfer (kern/24636)
-> needed for this driver
* fix USB HC detach race condition (kern/32011)
-> main patch needed for this driver, sc_dying changes in other drivers
not necessary but seem right to me

Patch from Matthew Orgass.
http://mail-index.netbsd.org/tech-kern/2007/06/26/0001.html

branches: 1.123.4; 1.123.12; 1.123.14; 1.123.18;
-in root hub emulation, return a sane value as language code
-constify "methods" tables and (partly) descriptor templates

branches: 1.122.2;
The diagnostic code doesn't track busy_free correctly when a
device gets removed. However, when the diagnostic check fails,
it is much better to complete the free operation than to abort
it, because this just causes an infinite loop.

Merge newlock2 to head.

Kill the "bus powered" bit in the configuration descriptor. This doesn't
exist in newer spec revisions, and is recommended to be set to 1.
So call it _MBO and also use it in the fake root hub descriptors, just
for sanity, even if nothing ever looks at it.

Remove the code which disables port status change interrupts for 1s
when one occured -- this makes that events get lost (or delayed until
the next change), in particular in the handover process from the EHCI
to a companion controller, laeving the port dead under some circumstances.
This fixes the "can't reconnect" symptom for me.
I don't see why the interrupt should be disabled - it is acknowledged
in the interrupt handler and shouldn't be active again until the next
status change.

branches: 1.118.2;
in the interrupt endpoint descriptor of the simulated root hub, fix the
poll interval: since this is a highspeed device, it should be a "12"
(just for sanity; this stuff is not used by the kernel, only userland
usb exploration code might see it)

Remove the code which tried to guess the toggle bit after a short
transfer. It was wrong because it didn't consider block boundaries.
Instead, use the updated toggle from the transfer descriptor -- this
is supposedly cheaper than modulo arithmetics.
This fixes a problem similar to PR kern/34070 for me.

-fix interpretation of the poll interval in interrupt descriptors for
USB2/highspeed: This is an exponent now, not milliseconds.
(There are wrong example descriptors for hubs in the USB2 spec; tolerate
invalid values and assume 256ms which is good for hubs, just in case
someone blindly copied from the book.)
-being here, fix an obvious memory leak

__unused removal on arguments; approved by core.

Split the USB task queue into two parts, one for normal device tasks and
one for tasks of the host controllers. This is needed for drivers like
ural(4) that want to do synchronous USB transfers from the task handler.
Before the split timeouts could not be handled correctly as the task
thread was still blocked. From FreeBSD.

- sprinkle __unused on function decls.
- fix a couple of unused bugs
- no more -Wno-unused for i386

Add "name" parameter to powerhook_establish, to aid debugging. No objections
on tech-kern@

branches: 1.111.2; 1.111.4;
fix incomplete initializers

Clean up bogus whitespace

branches: 1.109.2;
Coverity CID 1131: Avoid NULL pointer dereference.

branches: 1.108.2; 1.108.4; 1.108.6; 1.108.8; 1.108.10;
From OpenBSD:

--
Add a workaround for VIA EHCI controllers which, under load, signal qTD
completion before they have performed writeback from the overlay qTD.

This condition would exhibit itself as a umass stall that never recovers.
--

This fixes the problem reported by Thomas Klausner on current-users@:
http://mail-index.netbsd.org/current-users/2006/01/17/0000.html

branches: 1.107.2;
Make the unused ehci_dump() function non-static.

Keep a flag for each port that keeps track of if the port has been reset
instead of having one flag for the controller.

Also, don't try to modify read-only power bits if the controller doesn't
support power cobntrol.

branches: 1.105.6;
Make sure we don't enable host controller interrupts until all
initialization is finished.

branches: 1.104.2;
- const poisoning
- eliminate variable shadowing

Make sure all physical addresses are filled in the qTD even when we have
a page offset.

From Dan Ellis (as was the previous fix).

Make sure to honor the USBD_FORCE_SHORT_XFER flag and generate an empty
transfer when necessary.

Fix typo.

Update TODO comment and copyright.

Only complain when opening full speed isoc devices, other types seem to
work reasonably (even if there is no proper scheduling of the TT yet).

Fix the error check on completion of an xfer. Just because the qTD status
field has error bits set doesn't mean there has been an error, unless the
HALTED bit is set as well. The old behaviour could result in a transfer
being considered failed by the software, but a success by the device.
This seems to have affected mostly mass storage devices.

Pointed out by Dan Ellis in kern/29731.

Timeout while polling is in ms not ticks.

From OpenBSD.

Fix a race condition in xfer abort. Derived from a FreeBSD patch.

An xfer could be aborted twice (which means that the second abort might
access deallocated memory). This happened when an xfer timed out and
the timeout started an abort. While that abort was taking place the
xfer could be cancelled (usually by closing the pipe), causing a second
abort to begin.
This is now handled by having flags indicating the abort state of an xfer.

Hopefully this will fix the occasional crashes when printing.

Get bit reversal table right this time.

Interrupt polling was spread very unevenly. Use the same bit reversal
trick as in ohci.c to correct this.

With the interrupt fix in the previous commit low and full speed devices
have a chance to work, so allow them (with a warning).
Make a small change to the transaction translator scheduling to make it
at least hobble along (again from Dan Ellis).

Don't null the qh_link point in the interrupt tree after it has been
initialized. From Dan Ellis in kern/30003.

branches: 1.91.2;
nuke trailing whitespace

branches: 1.90.2; 1.90.4;
Implement an USB memory reserve. Allocate some memory per host controller
in the wanted bus_dma space. If an allocation fails during operation
(i.e. when hotplugging an umass device), fall back to using the reserve.

The amount can be configured as USB_MEM_RESERVE. The default value is
256k.

Ideally, there would be a way to steal pages in the desired area from
UVM, but that's far more complicated, and this is not intrusive, plus
it works.

Don't error out if the number of companion controllers is wrong, just
omplain a go ahead.

Allow strings descriptor 0 to be fetched. It's the default language index.

Preserve some bits in the overlay qTD.

Add a comment.

Follow the spec more closely when updating the overlay qTD in the QH.

Only delay interrupt my 2 miucroframes instead of 8. This improves
Ethernet performance.

No need to generate an interrupt at the data part of a control transfer,
it's generated by the status transfer.

Make sure to update the data toggle on short transfers.
This makes my Ethernet adapter much happier.

Don't allow open of low/full speed pipes types that will not work yet.

Keep track of what high speed port (if any) a device belongs to so we can
set the transaction translator fields for the transfer.
Add a gross hack for split transaction completion in the ehci driver that
allows control transfers to be translated. Interrupt transfers do not work.
Warn when any low/full speed device is opened.

Turn the printf about needing toggle update into a DPRINTF. Things
seem to work even when this message appears.
Why is it there, Charles?

Add interrupt transfers. From OpenBSD.
Having interrupt transfers enables some more device types to be used,
most notably USB2 hubs. USB2 hubs still cannot handle anything but
USB2 devices, because there is node code to handle hub Transaction Translation
yet.
XXX This code doesn't do good bw scheduling, but it's certainly better than
nothing. :)

Insert from ifdefs for soft interrupt related stuff. From OpenBSD.

A little portability stuff.

Fix typo in comment: compolicated -> complicated.

Add suspend/resume support.
From OpenBSD.

Use do .. while wrappers for debug print.
From OpenBSD.

Match function names in debug messages with real name.
From OpenBSD.

ANSIfy.

make this compile with OHCI_DEBUG without EHCI_DEBUG.

hcpriv is not actually used here. Remove references to it.

Adjust some silliness that was causing us to do extra work for "frame list
rollover" interrupts, which we pretty much ignore.

Fix a byte order error.

Fix an endianness problem (EHCI_NULL was being double-swapped).

Make one message dependent on ohcidebug, so it doesn't interfere with polled
operation; e.g. when entering a root device or in DDB.

Further cleanup of toggle handling. Now that we use EHCI_QH_DTC, we don't
need to fiddle with the TOGGLE bit in the overlay descriptor, so minimize
how much we fuss with it.

Fix an error in a debug printf().

Adjust a couple of comments to make it clear WTF is going on.

Update comment.

Remove comment about the data toggle being borked.

As the ehci_idone() now uses the variable `epipe' unconditionally, always
declare it (in other words, make this file compile w/o EHCI_DEBUG).

Fix a stupid bug in ehci_check_intr() that caused use to try to complete a
transaction that was still running. Now ehci can handle multiple devices
being active at once.

Oops. Remove a couple of printf()s.

Failure to properly mask off UE_DIR_IN from the endpoint address was causing
OHCI_ED_FORMAT_ISO and EHCI_QH_HRECL to get set spuriously, causing rather
interesting lossage.

Suddenly I get MUCH better performance with ehci...

Set the data toggle correctly, and use EHCI_QTD_DTC. This fixes problems with
my ALi-based drive enclosure (it works now, rather than failing to attach).
Also seems to work with a GL811-based enclosure and an ASUS enclosure with a
CD-RW, on both Intel and NEC controllers.

Note: The ALi enclosure is currently very SLOW, due to some issue with taking
too long to notice that the QTD is complete. This requires more investigation.

branches: 1.54.2;
Michael van Elst reports his USB2 disk works stable after latest Chuck's
ehci.c changes, so remove the item from TODO.

in ehci_softintr() when looping over the active xfers, save the next pointer
before calling ehci_check_intr(), since that will free the xfer structure
if the xfer is complete.

add list of known issues, from Lennart Augustsson and Michael van Elst

Use the correct wValue to get hub desriptors.
Also, make wValue checks of root hub codes less strict.

Remove assigned-to but otherwise unused variables.
Remove unreachable break after return statements.

KNF the previous commit.

Fix problems with ehci on controllers that support 64-bit addressing. From
Cliff Wright, PR 23128. Thanks!

branches: 1.47.2;
Try to make message about missing companion controllers clearer.

Change debug message.

Use mstohz() in <sys/param.h> rather than homegrown MS_TO_TICKS().

Don't take xfers off the interrupt list if they are not on it yet.

change URL pointers of USB[1,2] specification

Fix a botched loop copied from the ohci driver (already fixed in ohci.c).
Pointed out by Daniel Ellis <dan@pod51.demon.co.uk>.

Use aprint_*().

Add a comment describing why ehci_dump() has been added back despite
not being referenced.
Suggested by Perry E. Metzger.

Ooops, put back ehci_dump() which I accidently removed in the last commit.
Thanks to enami tsugutomo for noticing this.

Move ehci_dump_exfer into #ifdef DIAGNOSTIC, it's not called w/o.
From FUKAUMI Naoki in PR 18988.

remove trailing \n in panic(). approved perry.

Set segment register if the device is 64 bit capable.

The revision of new document is 1.0.

Increase the timeout waiting for reset to finish.
Update documentation URL.

Get rid of trailing white space.

SIMPLEQ rototill:
- implement SIMPLEQ_REMOVE(head, elm, type, field). whilst it's O(n),
this mirrors the functionality of SLIST_REMOVE() (the other
singly-linked list type) and FreeBSD's STAILQ_REMOVE()
- remove the unnecessary elm arg from SIMPLEQ_REMOVE_HEAD().
this mirrors the functionality of SLIST_REMOVE_HEAD() (the other
singly-linked list type) and FreeBSD's STAILQ_REMOVE_HEAD()
- remove notes about SIMPLEQ not supporting arbitrary element removal
- use SIMPLEQ_FOREACH() instead of home-grown for loops
- use SIMPLEQ_EMPTY() appropriately
- use SIMPLEQ_*() instead of accessing sqh_first,sqh_last,sqe_next directly
- reorder manual page; be consistent about how the types are listed
- other minor cleanups

Change DMAADDR macro slightly.

branches: 1.30.2;
Update dma memory access API a little.

branches: 1.29.8;
Change abort slightly.
Change debug output.

More DIAGNOSTIC.

Fix null pointer dereference when EHCI_DEBUG is defined (and
debug is enabled).

Improve xfer abort sequence.
Fix another bug in qTD chain allocation.

Fix a bug in qTD chain allocation.
Fix a qTD leak.
Handle out of memory conditions better.

My USB 2.0 CD-RW now mounts nicely and I can access files.
Performance is still lacking (it's at about 2Mbyte/s).

Make it compile without debug.

Follow a safer protocol when updating the QH.
The EHCI driver isn't really working properly, but now the SCSI driver
correctly identifies my CD-RW drive! :-)

Implement (incorrect?) data toggle clear method.
Implement allocation of qTD chains.

Mask correct interrupt after error interrupt.

Mask the correct interrupt after a door bell interrupt.

Implement bulk transfers.

Add some interrupt processing.

Pay more attention to if the HC is being unplugged.

Add missing }

Set up control xfers.
Handle xfer timeouts.
Better debug messages.

Support port indicator light.

Use longer reset for root hubs (as told in the spec).

Don't wait for door bell interrupt when controller has been disconnected.

Use device speed in setup.
Simplify async list handling.

Start of pipe open routine.

Add more fields to hardware structs.
Add memory allocation for various data structures.

Implement port reset sequence correctly.

Add some more data structure defs.

Recognize port status changes.
Hand over low and full speed devices to companion controller.

Add root hub emulation.

add RCSIDs

Add some register defines.
Print companion controllers.

branches: 1.2.2; 1.2.4; 1.2.6; 1.2.10;
Even stubs need improvements.

Add some placeholders for the EHCI (USB 2) driver.

Don't get your hopes up. I've not even finished reading the
(100+) page spec, and I have no hardware.

fix various typos in comments and log messages.

fix spelling mistakes, mainly in comments and log messages.

avoid different struct type problem.

Fix DMA sync flags in ehci_append_sqtd

update my email address.

ehci(4): Fix bug causing missed wakeups since ehci.c 1.308.

For reasons beyond me now, I used cv_signal on the same cv that is
used to wait for the doorbell to be available _and_ to wait for the
host controller to acknowledge the doorbell. Which means when the
host controller acknowledges the doorbell, we might wake some thread
waiting for the doorbell to be available -- and leave the thread
waiting for the doorbell acknowledgment hanging indefinitely.

PR port-i386/57662

XXX pullup-10

ehci(4): Fix cv_timedwait loop in ehci_sync_hc.

Stop when

now - starttime >= delta,

i.e., when at least delta ticks have elapsed since the start, not
when

endtime - now > delta,

i.e., more than delta ticks _remain_ to sleep, which is never going
to happen (except on arithmetic overflow).

As is, what will happen in the case that should time out is that we
wake up after delta ticks, and find now = getticks() is exactly
endtime, so we retry cv_timedwait with timo=(endtime - now)=0 which
means sleep indefinitely with no timeout as if with cv_wait.

PR port-i386/57662

XXX pullup-10

PR//57518: usb keyboard causes host controller to miss microframe

As per the USB 2.0 specification section 11.18.4; paragraph 3.b

For interrupt IN/OUT full-/low-speed transactions, the host must schedule a
complete-split transaction in each of the two microframes following the first
microframe in which the full-/low-speed transaction is budgeted. An additional
complete-split must also be scheduled in the third following microframe unless
the full-/low-speed transaction was budgeted to start in microframe Y6.

various debug updates for some usb drivers

- several new *_DEBUG_DEFAULT options that allow usb debug values to
be set to a default that is non-zero:
EHCI_DEBUG_DEFAULT, UGEN_DEBUG_DEFAULT, URTWN_DEBUG_DEFAULT,
UMS_DEBUG_DEFAULT, and USB_DEBUG_DEFAULT
- ugen debug uses fewer usbhist lines for the same info
- ums.c converted from printf() to usbhist

branches: 1.315.2;
fix grammar in comment

ehci_device_isoc_init() returns errno not usbd_error; remove blank line
in ehci_device_fs_isoc_init() to match ehci_device_isoc_init()

"periodic frame list", not "period frame list" in comments

Add missing whitespace in error message.

revert accidental last commit (except ukbd.c)

remove debug printf

ehci(4): Serialize access to portsc registers.

Both ehci_roothub_ctrl and ehci_suspend/resume do r/m/w on them, so
use a mutex to serialize access to avoid stomping on each other.

ehci(4): Fix doorbell synchronization.

ehci_sync_hc was previously subject to spurious wakeup, in which case
the CPU might proceed from aborting and recycle a DMA buffer before
the hardware was done writing to it. Now the code is not subject to
spurious wakeup -- it waits (up to the 1sec timeout) for the relevant
interrupt to be delivered, not for anything else.

ehci(4): Omit bus lock around ehci_suspend/resume.

This no longer serializes access to the portsc registers, also used
by ehci_roothub_ctrl, but it does pose a potential deadlock with
softints to wake usb_delay_ms. So the bus lock doesn't help here,
and may cause deadlock.

usb: Provisionally release bus lock around ubm_rhctrl.

This isn't quite correct, but it avoids a deadlock:

- *_roothub_ctrl holds bus lock, waits in usb_delay_ms for kpause
- softint waits for bus lock, holds up kpause wakeup

The deadlock is new since recent changes to hold the bus lock over
upm_start/upm_transfer. Making this change regresses to other
problems:

- *_suspend/resume and *_roothub_ctrl often touch the same portsc
registers

- roothub_ctrl_abort needs to wait for ubm_rhctrl to complete.

When the bus lock was held across both, a noop served here, but we
can't hold the bus lock across both, so that doesn't work.

However, these problems -- which we've had for a long time -- seem to
be less bad than the deadlock. So let's avoid the deadlock for now
and then work out another way to serialize suspend/resume/rhctrl and
aborts.

Candidate fix for PR kern/56739.

usb: Hold pipe lock across upm_transfer and upm_start.

This simplifies the code and fixes races with abort. Access to the
pipe's queue is now done exclusively while the pipe is locked.

usb: Factor usb_transfer_complete out of ubm_abortx method.

usb: Factor usb_insert_transfer out of upm_transfer and make private.

Almost every upm_transfer function starts with:

mutex_enter(&sc->sc_lock);
err = usb_insert_transfer(xfer);
mutex_exit(&sc->sc_lock);
if (err)
return err;

Some of them have debug messages sprinkled in here too, or assert
that err == USBD_NORMAL_COMPLETION (alternative is USBD_IN_PROGRESS,
only for pipes with up_running or up_serialise, presumably not
applicable for these types of pipes). Some of them also assert
xfer->ux_status == USBD_NOT_STARTED, which is guaranteed on entry and
preserved by usb_insert_transer.

Exceptions:

- arch/mips/adm5120/dev/ahci.c ahci_device_isoc_transfer just returns
USBD_NORMAL_COMPLETION, but I'm pretty sure this is and always has
been broken anyway, so won't make anything worse (if anything, might
make it better...)

- external/bsd/dwc2/dwc2.c dwc2_device_bulk_transfer and
dwc2_device_isoc_transfer _also_ issue dwc2_device_start(xfer)
under the lock. This is probably a better way to do it, but let's
do it uniformly across all HCIs at once.

- rump/dev/lib/libugenhc/ugenhc.c rumpusb_device_bulk_transfer
sometimes returns USBD_IN_PROGRESS _without_ queueing the transfer,
in the !rump_threads case. Not really sure how this is supposed to
work... If it actually breaks anything, we can figure it out.

initialize ntag with the old dmatag so we never end up with an invalid one
suggested by jmcneill@

shut up an unused variable warning
apparently clang gets confused by bus_dmatag_subregion() being EOPNOTSUPP
on powerpc

convert the ehci device owner ship change message to display the ehciN as well.

ehci(4): fix PR kern/56574: uaudio at ehci (not xhci) only outputs
rapid gunfire (patch from nick)

Use the correct dmatag for all control structures. Also, don't KASSERT that
we're using the low 4GB for them and simply error out.

kern/56570: ehci panic on boot

Three fixes

- pass the 64bit DMA tag if the HCCPARAMS says ehci supports it and the
64bit DMA tag is available/valid. This should help with the
"cannot create xfer" error on 64bit systems.

- restrict the control structure memory allocation to the low 4GB
(CTRLDSSEGMENT was always set to zero anyway)

- if ehci_init fails then tidyup before returning the error.

Whitespace

Remove an empty line

Wrap a long line

Change the usb_mem API to take a bus_dma_tag_t in usb_allocmem instead of
a struct usbd_bus *.

This allows an HCD to use more than one tag.

KASSERT(BUS_ADDR_HI32(baddr) == 0) in, and apply some consistent code
style to all of ehci_alloc_{sqh,sqtd,itd,sitd}.

While ehci can address memory >4GB for control structures
EHCI_CTRLDSSEGMENT is always set to zero so ehci assumes it's using the
low 4GB.

Fix two bugs

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.

Match variable names to register names. Same binary before and after.

More usb_status_t -> int

Code consistency. NFCI.

ehci: Replace bogus polling during suspend by taking bus lock.

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.

add missing newline and fix conditional for askroot/single user
hand over delay message. PR#56366.

More converstion from usbd_status to int for function error reporting.
This time it's the turn of usb_allocmem.

usb: Omit bogus assertions about struct usbd_pipe::up_intrxfer.

These assertions were only valid for pipes at UE_IN_DIR, UE_INTERRUPT
endpoints created with usbd_open_pipe_intr, which uses up_intrxfer to
pass the struct usbd_xfer object to usbd_close_pipe to free later.

In contrast, for pipes at UE_OUT_DIR, UE_INTERRUPT endpoints,
up_intrxfer is never initialized, so the assertion cannot be right.
In principle we might even have more than one outstanding interrupt
transfer at a time, rendering the point of the assertion moot anyway.

Found by interrupting a uhidev write to a u2f device.

ok nick

s/ we we / we /

branches: 1.282.2;
Talk Like a Pirate Day was yesterday.

Copyright maintenance

Use BUS_ADDR_{LO,HI}32. NFCI.

Update ux_length in usbd_setup_isoc_xfer and use this to usb_syncmem
in the HCDs

Switch USB to use non-coherent buffers for data transfers in the
same way as OpenBSD.

The use of coherent (uncacheable on ARM and other arches) mappings
for transfer buffers impacts performance, espcially where memcpys
are involved.

Audit the necessary usb_syncmem operations - a few were missing.

revert the 0x% -> %# change for fixed width formats pointed out by uwe.

PR/55068: sc.dying: Fix printf formats:
- no %s/%p for kernel log
- 0x% -> %#
- always %j for kernel log

Use howmany. NFC.

Fix a memory leak. Spotted by nat@

Fix mistakes in previous sloppy change with root intr xfers.

- Make sure ux_status is set to USBD_IN_PROGRESS when started.
Otherwise, if it is still in flight when we abort the pipe,
usbd_ar_pipe will skip calling upm_abort.

- Initialize ux_status under the lock; in principle a completion
interrupt (or a delay) could race with the initialization.

- KASSERT that the xfer is in progress when we're about to complete
it.

Candidate fix for PR kern/54963 for other HCI drivers than uhci.

ok nick
ok phone

(This is the change that nick evidently MEANT to ok when he ok'd the
previous one!)

Fix steady state of root intr xfers.

Why?

- Avoid completing a root intr xfer multiple times in races.
- Avoid potential use-after-free in poll_hub callouts (uhci, ahci).

How?

- Use sc->sc_intr_xfer or equivalent to store only a pending xfer
that has not yet completed -- whether successfully, by timeout, or
by synchronous abort. When any of those happens, set it to null
under the lock, so the xfer is completed only once.

- For hci drivers that use a callout to poll the root hub (uhci, ahci):

. Pass the softc pointer, not the xfer, to the callout, so the
callout is not even tempted to use xfer after free -- if the
callout fires, but the xfer is synchronously aborted before the
callout can do anything, the xfer might be freed by the time the
callout starts to examine it.

. Teach the callout to do nothing if it is callout_pending after it
has fired. This way:

1. completion or synchronous abort can just callout_stop
2. start can just callout_schedule

If the callout had already fired before (1), and doesn't acquire
the bus lock until after (2), it may be tempted to abort the new
root intr xfer just after submission, which would be wrong -- so
instead we just have the callout do nothing if it notices it has
been rescheduled, since it will fire again after the appropriate
time has elapsed.

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

Fix steady state of timeouts in ehci.

This is complicated because:

1. There are three ways that an xfer can be completed:
(a) hardware interrupt completes xfer
(b) software decision aborts xfer with USBD_CANCELLED
(c) timeout aborts xfer with USBD_TIMEOUT

2. The timeout abort can't be done in callout because ehci_sync_hc,
called unconditionally by ehci_abort_xfer to wait until the device
has finished using any references to the xfer, may sleep. So we
have to schedule a callout that, when run, will schedule a usb_task.

3. The hardware completion interrupt can't sleep waiting for a callout
or task to finish -- can't use callout_halt or usb_rem_task_wait.
So the callout and usb_task must be able to run _after_ the hardware
completion interrupt, and recognize that they're late to the party.

(Note, though, that usbd_free_xfer does wait for the callout and
task to complete, so there's no danger they may use themselves after
free.)

4. The xfer may resubmitted -- and the timeout may be rescheduled --
immediately after the hardware completion interrupt, _while_ the
callout and/or usb_task may still be scheduled. Specifically, we
may have the following sequence of events:
(a) hardware completion interrupt
(b) callout or usb_task fires
(c) driver resubmits xfer
(d) callout or usb_task acquires lock and looks around dazed and
bewildered at the firehose of events like reading the news in 2019

The mechanism for sorting this out is that we have two bits of state:

- xfer->ux_timeout_set informs the driver, when submitting an xfer and
setting up its timeout, whether either the callout or usb_task is
already scheduled or not.

- xfer->ux_timeout_reset informs the callout or usb_task whether it
should reschedule the callout, because the xfer got resubmitted, or
not.

don't call usb_syncmem() for zero-length packets.

branches: 1.268.2;
Remove a stray '

branches: 1.267.2;
Random style in ehci, also KM_SLEEP does not fail.

Fix assertion failures triggered by usbdi.c,v 1.182, when devices
are detached.

This is because xfers of USBD_NOT_STARTED can be removed from queue
in an invisible way to host controller drivers.

Discussed on tech-kern.

implement a gross hack to fix "boot -a" on systems with usb keyboards on
systems with ehci handover to uhci (and maybe ohci), and fix a similar
problem for "boot -s".

there is effort to ensure that all devices attached via USB are probed
before RB_ASKNAME or RB_SINGLE attempts to ask any questions on the console,
and largely this works, often by chance, today, for USB disks and root.
i've recently pushed this more into uhub and general USB device attachment
as well, and kept a config_pending reference across the first explore of
a bus. these fix many issues with directly attached hubs.

however, on systems where devices connected to ehci ports are handed over
to a companion uhci or ohci port, it may not be the first, or even second,
bus explore that finds the device finally before attachment, and at this
point all config_pending references are dropped.

there is no direct communication between drivers, the potentials are
looked up but their device_t is only used for generic things like the name,
so informing the correct companion to expect a device and deal with the
config_pending references is not possible without some fairly ugly layer
violations or multi-level callbacks (eg, we have "ehci0", and usually an
the relevant companion, eg, "uhci2", but it is the uhub that uhci2 has
attached that will deal with the device attachment.)

with the above fixes to generic USB code, the disown happens during the
first explore. the hack works by, at this point, checking if (a) root
is not mounted, (b) single user or ask name are set, and (c) if the hack
as not been triggered already. if all 3 conditions are true, then a
config_pending_incr() is called and a callback is triggered for (default)
5 seconds to call config_pending_decr(). ehci detach pauses waiting for
this callback if scheduled.

this allows enough time for the uhub and the ukbd/wskbd to attach before
the RK_ASKROOT prompts appear. testing shows it takes between 1.5 and
2 seconds for the keyboard to appear after the disown occurs.


Index: dev/usb/ehcivar.c
- new sc_compcallout, sc_compcallout, sc_complock, and a state for th
handover hack.

Index: dev/usb/ehci.c
ehci_init():
- use aprint_normal_dev() instead of manual device_xname().
- initialise sc_compcallout, sc_compcallout, sc_complock, and sc_comp_state.
ehci_detach():
- if there are companion controllers, tear own the above, including waiting
if there is a callback scheduled.
ehci_disown_callback():
- new callout to call config_pending_decr() in the the future.
schedule this ca
ehci_disown_sched_callback():
- if booting to single user or asking names, call config_pending_incr() and
schedule the callout above, default 5 second delay.
ehci_disown():
- if disowning a port call ehci_disown_sched_callback().

consolidate the handling of polling across HC drivers, and generic USB:
- don't take mutexes if polling
- normalise the code across all drivers
- add some not yet code to block discovery to/from polling
- minor CSE
- adjust comment for usbd_set_polling() to reality now i properly
understand what it is used for and why.

this, with a hack to make RB_ASKNAME to wait 5 seconds allows boot -a
work with USB keyboards. there are still multiple issues remaining:
- discovery and polling need to be mutually exclusive
- attachment of ukbd and wskbd is not handled by config_pending, and
the 5 second delay isn't going to always be enough.

interrupt has two 'r's

fix another typo while I'm here (flsah)

Rename min/max -> uimin/uimax for better honesty.

These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.

HOWEVER! Some subsystems have

#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))

even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.

To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.

I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:

cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))

It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.

Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)

fix DIAGNOSTIC build by not copying ub_usepolling to stack before use

pull across abort fixes from nick-nhusb. add more abort fixes, using
ideas from Taylor and Nick, and myself. special thanks to both who
inspired much of the code here, if not wrote it directly.

among other problems, this assert should no longer trigger:

panic: kernel diagnostic assertion "xfer->ux_state == XFER_ONQU" failed: file "/current/src/sys/dev/usb/usbdi.c", line 914

using usbhist i was able to track down my instance of it being related
to userland close() beginning, dropping the sc_lock, and then the usb
softintr completes the transfer normally, and when it is done, the
abort path attempts to re-complete the transfer, and the above assert
is tripped.


changes from nhusb were commited with these logs:
--
Move the struct usb_task to struct usbd_xfer for everyone to use.
--
Set device transfer status to USBD_IN_PROGRESS if start methods succeeds
--
Actually set the transfer status on transfers in ohci_abort_xfer and
the controller is dying
--
Don't supply the lock to callout_halt when polling as it won't be held
--
Improve transfer abort
--
Mark device transfers as USBD_IN_PROGRESS appropriately and improve
abort handling
--
#ifdef DIAGNOSTIC -> KASSERT and add another KASSERT
--
Mark device transfers as USBD_IN_PROGRESS appropriately and improve
abort handling
--

additional changes include:
- initialise the usb abort task in the HCI allocx routine, so that it
can be safely usb_rem_task()'d.
- rework the handling of softintr vs cancellation vs timeout abort based
upon a scheme from Taylor:
when completing a transfer normally:
- if the status is not in progress, it must be cancelled or timed out,
and we should not process this xfer.
- set the status as normal.
- unconditionallly callout_stop() and usb_rem_task(). they're safe and
either aren't running, or will run and do nothing.
- finally call usb_transfer_complete().
when aborting a transfer:
- status should be cancelled or timed out.
- if cancelling, callout_halt and usb_rem_task_wait() to make sure the
timer is either done or cancelled.
- at this point, the ux_status must not be cancelled or timed out, and
if it is not in progress we're done.
- set the status.
- if the controller is dying, just return.
- perform HCI-specific tasks to abort this xfer.
- finally call usb_transfer_complete().
for the timeout and timeout task:
- if the HCI is not dying, and the ux_status is in progress, then
trigger the usb abort task.
- remove UXFER_ABORTWAIT and UXFER_ABORTING.

tested on:
- multiple PC systems with several types of devices: ugen/UPS, ucom,
umass with disk, ssd and cdrom backends, kbd, ms, using uhci, ehci
and xhci.
- erlite3: sd@umass on dwc2.
- sunblade2000: kbd/ms and umass disk on ohci.

untested:
- motg, slhci and ahci. motg has some portion of the new scheme
applied, but slhci and ahci require more study.

future work includes pushing a lot of the common abort handling into
usbdi.c and leaving upm_abort() for HC specific tasks, but this change
is pullup-able to netbsd-7 and netbsd-8 as it does not change any
external API, as well as removing over 100 lines of code while adding
over 30 new asserts.

XXX: pullup-7, pullup-8.

branches: 1.259.2;
Remove duplicate ;

Stop potential misuse of vendor names and USB vendor IDs in root hub
device and string descriptors.

Firstly: Few vendors have identical PCI-SIG vendor IDs and USB-IF vendor
IDs. As such, using the PCI vendor ID as a USB vendor ID may trample
on whomever is allocated that USB vendor ID.

Secondly: The vendor of the host controller hardware implementation has
little to nothing to do with our usbroothub implementation. Thus we
should not potentially associate any problems therewith to such third
party.

This change will result in root hubs being identified by USB Vendor ID
0x0000. Root hub vendor string will now be "NetBSD" (or, specifically:
ostype). Product ID (0x0000) and product strings remain unchanged.

branches: 1.257.2;
s/PR_NOWAIT/PR_WAITOK/ in HCD allocx (allocate xfer) method

Update the kernhist(9) kernel history code to address issues identified
in PR kern/52639, as well as some general cleaning-up...

(As proposed on tech-kern@ with additional changes and enhancements.)

Details of changes:

* All history arguments are now stored as uintmax_t values[1], both in
the kernel and in the structures used for exporting the history data
to userland via sysctl(9). This avoids problems on some architectures
where passing a 64-bit (or larger) value to printf(3) can cause it to
process the value as multiple arguments. (This can be particularly
problematic when printf()'s format string is not a literal, since in
that case the compiler cannot know how large each argument should be.)

* Update the data structures used for exporting kernel history data to
include a version number as well as the length of history arguments.

* All [2] existing users of kernhist(9) have had their format strings
updated. Each format specifier now includes an explicit length
modifier 'j' to refer to numeric values of the size of uintmax_t.

* All [2] existing users of kernhist(9) have had their format strings
updated to replace uses of "%p" with "%#jx", and the pointer
arguments are now cast to (uintptr_t) before being subsequently cast
to (uintmax_t). This is needed to avoid compiler warnings about
casting "pointer to integer of a different size."

* All [2] existing users of kernhist(9) have had instances of "%s" or
"%c" format strings replaced with numeric formats; several instances
of mis-match between format string and argument list have been fixed.

* vmstat(1) has been modified to handle the new size of arguments in the
history data as exported by sysctl(9).

* vmstat(1) now provides a warning message if the history requested with
the -u option does not exist (previously, this condition was silently
ignored, with only a single blank line being printed).

* vmstat(1) now checks the version and argument length included in the
data exported via sysctl(9) and exits if they do not match the values
with which vmstat was built.

* The kernhist(9) man-page has been updated to note the additional
requirements imposed on the format strings, along with several other
minor changes and enhancements.

[1] It would have been possible to use an explicit length (for example,
uint64_t) for the history arguments. But that would require another
"rototill" of all the users in the future when we add support for an
architecture that supports a larger size. Also, the printf(3) format
specifiers for explicitly-sized values, such as "%"PRIu64, are much
more verbose (and less aesthetically appealing, IMHO) than simply
using "%ju".

[2] I've tried very hard to find "all [the] existing users of kernhist(9)"
but it is possible that I've missed some of them. I would be glad to
update any stragglers that anyone identifies.