On Thursday 24 January 2008 10:13:01 Johannes Berg wrote: > > > This also adds a longer delay for waiting for the microcode > > to initialize itself. It seems that the current timeout is sufficient > > on all available devices, but there's no real reason why we shouldn't > > wait for up to one second. Slow embedded devices might exist. > > Your decision, but I very much doubt you can make the MAC any slower > than on the old devices, in fact, on new chips it runs considerably > faster I think. Ok, well. But the host machine does get faster. In theory we only gave the microcode 500 microseconds of time to initialize. I think that is is a pretty tiny timeframe. In practice the time was higher, because we had a loop that checked MMIO and delayed for 10usec. Of course this all has overhead. But as machines get faster and faster I think we can't assume to have more than 500 microseconds of time. So, increasing the delay to one second doesn't hurt anyone. In all common cases it will continue after a few milliseconds. That's fine. Even if there is something going wrong (wrong firmware) you can interrupt the one second delay by hitting ^C. I think the specs originally sayed to use a much longer delay than we were using. But we did use a shorter delay, because in some old bcm43xx code this ran unter spinlock as far as I remember. So we didn't want to spin several milliseconds and lockup the system, if something goes wrong in firmware. These times are gone and now we can sleep in this part of the code. -- Greetings Michael. - 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
