On Thursday 08 August 2013 22:19:32 Alan Stern wrote:
> On Thu, 8 Aug 2013, Christian Lamparter wrote:
>
> > Anyway, I do have a question about something else too.
> >
> > in ath9k_htc's hif_usb:
> >
> > > struct usb_host_interface *alt = &hif_dev->interface->altsetting[0];
> > > struct usb_endpoint_descriptor *endp;
> > > ...
> > > /* On downloading the firmware to the target, the USB descriptor of EP4
> > > * is 'patched' to change the type of the endpoint to Bulk. This will
> > > * bring down CPU usage during the scan period. */
> > >
> > > for (idx = 0; idx < alt->desc.bNumEndpoints; idx++) {
> > > endp = &alt->endpoint[idx].desc;
> > > if ((endp->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_INT) {
> > > endp->bmAttributes &= ~USB_ENDPOINT_XFERTYPE_MASK;
> > > endp->bmAttributes |= USB_ENDPOINT_XFER_BULK;
> > >// endp->bInterval = 0;
> > > }
> > > }
> >
> > Alan, can you please tell us, if it is really safe to
> > override the bmAttributes this way? After all (according to
> > the comment) the device has "morphed" (EP4 has changed).
>
> This does not look like a good idea. Why does the driver do it?
Probably because people use ath9k_htc devices with everything that
has some sort of usb port (devkits and embedded systems: Dockstar,
Rasberry Pi, ...) to get "wifi connectivity". ...
Yeah. I think we better ask "Rajkumar Manoharan"
(before I write more text out of thin air :-D )
commit 4a0e8ecca4eeed38d4b3b7a317a3aaab4dd3cacd
Author: Rajkumar Manoharan <rmanoharan@xxxxxxxxxxx>
Date: Tue Sep 14 14:35:55 2010 +0530
ath9k_htc: Fix CPU usage issue during scan period
Does anyone know his Qualcomm Atheros address?
> > Or, is it necessary for the driver call "usb_reset_device"
> > or (usb_reset_configuration) in this case?
>
> After loading firmware, a reset generally is necessary. Some devices
> will do it themselves; others require you to call usb_reset_device().
This makes things complicated. Because, as far as I remember,
usb_reset_device() will cause the current driver to be unbound
unless its called during .probe, right?
You see, ath9k_htc loads its firmware asynchronously in ".probe"
(ath9k_htc's .probe routine finishes before the firmware is
retrieved via the firmware loader helper... so part of the
firmware download is done in a firmware_complete callback
on a workqueue).
So, if we call usb_reset_device there and the driver is unbound
and later rebound. the next ath9k_htc .probe will start again and
again and again not knowing that it is already initialized
(and we have a loop).
This could be solved, if the devices changes the usb-id again
when a proper "wifi" ath9k_htc firmware was downloaded. So, the
driver would know that it doesn't have to download and reset
the device... But we need a "free" USB-ID for that.
Alan, Oleksij: What do you think?
Regards,
Chr
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
