On 02/25/2013 11:19 AM, Yvan wrote:
Kalle Valo <kvalo@...> writes:
Larry Finger <Larry.Finger@...> writes:
On 02/21/2013 08:03 AM, Julien Massot wrote:
Hi,
I just find a quick and dirty patch to workaround this issue.
I just reset the device on initialization failure.
I hope this helps to understand the real issue.
[...]
I am certain that the real problem here is that ath6kl is requesting
firmware with a synchronous call using request_firmware() rather than
with the asynchronous request_firmware_nowait(). That used to work,
but updates to udev caused the firmware read operation to time out. It
works after a reset because the file reading routines are now running;
however, the correct fix is to rewrite the firmware reading section.
I haven't looked at all the details yet, but AFAIK this is about cold vs
warm booting the chip. When rebooting the host while maintaining the
power to ar6004 ("warm boot") ath6kl probe fails as the chip is in odd
state and needs to be reset. It's not about dowloading the firmware
image from user space, it's about starting the firmware inside the chip.
And besides, didn't udev finally fix that (after some "feedback" from
Linus) so that we don't need to change all the drivers?
Hi,
I'm having the exact same problem than Julien, (my kernel log are _exactly_ the
same than his).
A difference on the behavior: the problem is not on reboot, it's always present
(normal boot and reboot...).
But the "quick fix" witch consist in adding "reset_device" doesn't work, it just
goes into a loop (hardware_init fail->reset device->hardware_init fail->...)
Main difference is the linux system:
the architecture is ARM9 (armv4) with a buildroot system and kernel 3.6.7
note: hardware USB port is usb_v1.1 only.
I've tried ath6kl drivers from the kernel and the one from compat-
driver_next(2013-02-20)
=>same result.
The wireless USB dongle is working properly on my linux computer with the same
compat-driver and same firmware files, so it shouldn't have hardware problem
Another wireless dongle based on RALINK chipset is working properly on my ARM
system, so this shouldn't be an hardware problem from the board.
Does 'modprobe -rv ath6kl' followed by 'modprobe -r ath6kl' make it work? If so,
then my idea about firmware loading might be correct. If not, then the problem
is somewhere else.
Larry
--
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
