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.
Obtained from: NetBSD
s/device_ptr_t/device_t/g
No md5 changes in the .o's
# Note to the md5 tracking club: $FreeBSD$ changes md5 after every commit
# so you need to checkout -kk to get $FreeBSD$ instead of the actual value
# of the keyword.
EHCI spec for linking in new qTDs into an asynchronous QH. This
requires that there is a qTD marked as not active and not halted
at the start of the QH's list, and the hardware will know to re-fetch
the qTD on each pass rather than just looking at the overlay qTD:
"The host controller must be able to advance the queue from the
Fetch QH state in order to avoid all hardware/software race
conditions. This simple mechanism allows software to simply link
qTDs to the queue head and activate them, then the host controller
will always find them if/when they are reachable."
This is achieved by keeping an "inactivesqtd" entry on the QH list,
and re-using it each time as the start of the next transfer, and
allocating a new qTD to become the next inactivesqtd. Then a new
transfer can be activated by just setting its "active" flag, which
avoids all the previous messing with overlay qTD state in
ehci_set_qh_qtd().
ATI EHCI controllers exhibit simmilar stall issues and require
this dropped interrupts workaround. Be verbose about it.
ehci.c:
ehcivar.h:
Slight change in comments to note about issues surrounding both
VIA and ATI EHCI controllers.
Approved by: iedowse
an interrupt appears to occur before the transfer has been marked
as completed. This caused umass transfers to get stuck, especially
when writing large files. The workaround sets up a timer that
rechecks for missed completed transfers if some operations are still
pending. Other suggested workarounds, such as performing a PCI read
immediately after acknowledging the interrupts, do not appear to
help.
Obtained from: OpenBSD
---snip---
FYI this bit isn't needed for FreeBSD - I think it came from either
OpenBSD or NetBSD where arc4random() wasn't available during cold
boot.
---snip---
Explained by: iedowse
Synchronise with NetBSD upto rev 1.19:
- Allow 32 chars in the saved vendor string.
- Some NetBSD-only changes.
- Some missing parts (define, variable).
ehci_pci.c:
Add vendor ids for ATI and Philips.
Add identification strings for the following:
o ALi's M5239
o AMD 8111
o ATI SB200, SB400
o Intel 6300ESB, ICH4, ICH5, ICH7
o NVIDIA nForce 2, nForce 3, nForce 4
o Philips ISP156x
ehcireg.h:
We're at the same level as rev 1.18 from NetBSD.
usb_port.h:
NetBSD/OpenBSD specific things
Obtained from: NetBSD via DragonFly
No comment from: usb@
transfer, which lead to panics or page faults. For example if a
transfer timed out, another thread could come along and attempt to
abort the same transfer while the timeout task was sleeping in
the *_abort_xfer() function.
Add an "aborting" flag to the private transfer state in each host
controller driver and use this to ensure that the abort is only
executed once. Also prioritise normal abort requests over timeouts
so that the callback is always given a status of USB_CANCELLED even
if the timeout-initiated abort began first.
The crashes caused by this bug were mainly reported in connection
with lpd printing to a USB printer.
PR: usb/78208, usb/78986
to remove a transaction from the async schedule. The previous method didn't
work well and led to the hardware writing to free'd buffers etc, as
it didn't always know that the transaction had been aborted.
Written after consultation with David Brownell who wrote the Linux
EHCI driver.
As part of this give the sqh structure a "previous" pointer.
MFC after: 1 week
system BIOS to disable legacy device emulation as per the "EHCI
Extended Capability: Pre-OS to OS Handoff Synchronisation" section
of the EHCI spec. BIOSes that implement legacy emulation using SMIs
are supposed to disable the emulation when this procedure is performed.
to be particularly correct or optimal, but it seems to be enough
to allow the attachment of USB2 hubs and USB2 devices connected via
USB2 hubs. None of the split transaction support is implemented in
our USB stack, so USB1 peripherals will definitely not work when
connected via USB2 hubs.
