| Age | Commit message (Collapse) | Author |
|---|
|
Tested with "MAC/BBP RT5592 (rev 0x0222), RF RT5592 (MIMO 2T2R)" device.
|
|
|
|
|
|
Makes RT5592 devices work, except for an 11a scanning issue, according
to Brendan MacDonell who submitted this patch on tech@. Thanks!
ok claudio@
|
|
since this function is optional get rid of the no-op ones.
ok ratchov@
|
|
Apart from improving readability, this will help us reduce the number of
no-op functions now that some of them are optional.
ok ratchov@
|
|
is not part of the address. From Remco <remco at d-compu.dyndns.org>,
thanks!
ok mpi@
|
|
ok krw@ kettenis@ mpi@
|
|
ok krw@ kettenis@ mpi@
|
|
HW-specific data and CRC trailer as intended, the driver was telling the
net80211 layer frames were longer than they actually are. Math is hard.
ok krw@ kettenis@ mpi@
|
|
|
|
the boot process, USB devices must be attached or detached from the usb
task thread in order to avoid races with periodical explorations issued
by uhub(4) interrupts.
Respect this rule when detaching root hubs during a suspend/resume cycle
and avoid some hangs due to the aforementioned race.
Tested by Mattieu Baptiste, thanks!
|
|
the device has multiple interfaces and/or report IDs.
Make sure utpms(4) only matches the mouse interface of the HID device
embedded in Powerbooks and do not rely on the alphabetical order to
have a working ukbd(4) on such machines.
Problem reported by daniel@
|
|
DVACT_QUIESCE was not passed to usb(4) and a new uhub(4) device was
reattached at every resume.
Problem reported by mlarkin@
|
|
Committing over MAC/BBP RT5390 (rev 0x0502), RF RT5370 (MIMO 1T1R).
Tested by myself, matthieu@, juanfra@
Diff glanced over by kettenis@
|
|
|
|
|
|
|
|
|
|
the ring is halted.
Do not bother reporting USBD_STALLED to the stack like other HC drivers
do since the endpoint is automatically reseted. What is the point of
this error apart from making sure driver authors will forget to call
usbd_clear_endpoint_stall_async() correctly?
The Renesas uPD720202 xHCI, provided by Stefan Wollny, now works as
expected.
|
|
|
|
allows ramdisk kernels to build again
|
|
|
|
status changes because it might be freed when detaching the root uhub(4).
Also do not reschedule a timeout if the pipe is being aborted.
Finally do not add more code to retrieve the 'bInterval' value of the
root hub endpoint descriptor since this value is hardcoded in the uhci(4)
driver.
|
|
|
|
usbd_xfer pointer to the routines processing finished transfers to make
it crystal clear that the timeout and abort logic is the same everywhere.
|
|
host controller because autoconf(9) already does it.
|
|
Previous uchcom(4) driver targeted old one, and new one could not work
because of uchcom_set_line_control() broke the value of
UCHCOM_REG_LCR1(0x18).
To support new CH340, uchcom_set_line_control() and uchcom_reset_chip()
have been overhauled. Current uchcom(4) does not change the value of
UCHCOM_REG_LCR1 register, it means even/odd parity mode is no longer
supported with old CH340.
ok by mpi@
|
|
|
|
Diff from Lukasz Ratajski
ok sthen@
|
|
input device descriptors, notably if they include an Item with an
Usage array (Min-Max range) and others single Usage elements.
Tested by many, thanks! ok andre@
|
|
delicate. HC drivers do not always accept to be left alone.
I don't know if it is a love crisis, but apparently receiving a root
hub status change interrupt before having an uhub(4) attached breaks
resume.
So make sure the root hub is re-attached before interrupt get enabled.
It is safe to do it during DVACT_RESUME since attaching root hubs do
not require any USB transfer.
Based on a diff from yasuoka@, fix a regression introduced in last
commit an reported by Abel Abraham Camarillo Ojeda on tech@ and Nils
R on bugs@.
|
|
|
|
This leak is similar to the public xfer leak #1 that was affecting
device interrupt pipes except that root hubs are rarely detached.
Note that this xfer is never associated to any TD and is just used
to indicate that some of the HC ports has changed status, so there
is no need to flag it as "done" before completing it.
|
|
Now that aborting interrupt pipes does not prevent us from freeing
the associated xfer, make sure to flag this xfer as "done" even if
there's no need to abort it in hardware.
|
|
uhidev_open() at attach time. This plugs up to 3 xfer leaks and a buffer
one.
ok yuo@
|
|
|
|
ok jsg@
|
|
This has the side effect of simplifying and reducing the differences
between the various *hci_alloc_*_chain() functions since they are the
principal place where we want to known if the transfer is a read or a
write.
|
|
|
|
ok by dcoppa@
|
|
per-driver pool(9) instead.
|
|
Every call to usbd_abort_pipe() on an interrupt pipe would simply
reset the intrxfer pointer, which would prevent usbd_close_pipe()
to free it. Since we abort pipes in a lot of situations: when a
device is detached, when a USB-to-serial adapter is closed, when
an error occurs, when the machine is suspended, etc, this would
result in hundreds of leaked xfers in most of my machines.
xhci(4) is not affected, but you can't enable it right now since
the stack is not ready :)
While here put a KASSERT() to make sure drivers are only calling
the interrupt abort method for intrxfer, if that's not the case,
please let met know.
|
|
|
|
ok mpi
|
|
|
|
|
|
per-driver pool(9) instead.
With inputs from mikeb@
|
|
versus supported sensors table filtering.
discussed with and ok mpi@
|
|
Since pipe methods have an xfer argument, always use it to get acces to
various data structure (pipe, bus, device) instead of having a different
way to get a pointer to these descriptors in every function.
Also kill the {E,U}XFER() macro and use a consistent name accross all the
methods for {e,u}hci_xfer.
|
