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 <rmanoha...@atheros.com> 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-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html