[PATCH RFC] ath9k-htc: convert EP3 and EP4 back from bulk to int
Oleksij Rempel
linux at rempel-privat.de
Tue Aug 13 08:04:15 EDT 2013
Am 13.08.2013 10:09, schrieb Oleksij Rempel:
> If usb auto suspend is enabled or system run in to suspend/resume
> cycle ath9k-htc adapter will stop to response. It is reproducible on xhci HCs.
>
> Host part of problem:
> XHCI do timing calculation based on Transfer Type and bInterval,
> immediately after device was detected. Ath9k-htc try to overwrite
> this parameters on module probe and some changes in FW,
> since we do not initiate usb reset from the driver this changes
> are not took to account. So, before any kind of suspend or reset,
> host controller will operate with old parameters. Only after suspend/resume
> and if interface id stay unchanged, new parameters will by applied. Host
> will send bulk data with no intervals (?), which will cause
> overflow on FIFO of EP4.
>
> Firmware part of problem:
> By default, ath9k-htc adapters configured with EP3 and EP4
> as interrupt endpoints. Current firmware will try to overwrite
> ConfigDescriptor to make EP3 and EP4 bulk. FIFO for this endpoints
> stay not reconfigured, so under the hood it is still Int EP.
>
After some digging in the code, i see that converting EP3 and EP4 to
bulk was a bug. This endpoints can't handle more then 64bytes, and
normally if we would provide it as usb descriptor, we would got warned.
See this code:
drivers/usb/core/config.c
/*
* Some buggy high speed devices have bulk endpoints using
* maxpacket sizes other than 512. High speed HCDs may not
* be able to handle that particular bug, so let's warn...
*/
if (to_usb_device(ddev)->speed == USB_SPEED_HIGH
&& usb_endpoint_xfer_bulk(d)) {
unsigned maxp;
maxp = usb_endpoint_maxp(&endpoint->desc) & 0x07ff;
if (maxp != 512)
dev_warn(ddev, "config %d interface %d
altsetting %d "
"bulk endpoint 0x%X has invalid
maxpacket %d\n",
cfgno, inum, asnum, d->bEndpointAddress,
maxp);
}
--
Regards,
Oleksij
More information about the ath9k_htc_fw
mailing list