On Tue, 2006-09-26 at 03:54 +0800, Peter Memishian wrote: > webrev: http://cr.grommit.com/~meem/wifi-0926 > cscope: /net/azariah.prc/builds/meem/wifi-0926/usr/src > /net/azariah.prc/builds/meem/wifi-0926/usr/src/uts > > Please provide feedback to this list. The review timer is set for two > weeks (10/10/2006).
I haven't reviewed this in detail, but have a quick comment on ath_detach() while I'm thinking of it: Why does ath_detach() not check to see if there is an established connection for the device, and fail the detach operation if there is one? I keep hearing, "you have to plumb an IP interface before connecting the WiFi link in order to keep the driver from unloading". This seems like an arbitrary administrative restriction, especially since the driver has enough information at hand to do the right thing and not unload while there are established connections. It's possible there is a technical reason why the driver needs to allow a detach in this situation, and if so, please educate me. :-) On a slightly related note, the ath_detach() function seems to do quite a bit of disabling and freeing things prior to calling mac_unregister(). If mac_unregister() fails, this will leave the device in a strange state, as things like interrupts have been disabled some things have been freed. It might make more sense to first call mac_unregister(), and then if that succeeds, to destroy the rest of the device state. -Seb _______________________________________________ networking-discuss mailing list [email protected]
