Hi Johannes,
The point is that the whole thing about disassociation is already the
wrong assumption. As I've outlined, it only works in STA mode, and thus
the function is generally not very useful.
I agree that resume/suspend shell be handled properly in the mac80211
regardless of this issue.
And it will handle the "firmware crashed" case perfectly too.
You may have a case, anyhow, please show us some RFC before you remove
of mac notify.
I don't have any, but given the current deficiencies, I don't think the
notify callback is worth keeping especially in light of the locking
nightmare it's creating. What does it fix anyway? No user ever
complained about slow re-association at resume time that I've heard, and
no driver but iwlwifi tries to speed it up.
until we see hard numbers here, I am fine with treating every driver the
same and just not do any kind of speed up at all. With all my testing
during resume and re-association, the timing has always been good enough
so that no real impact for the user happened.
The question here is what are the real benefits and for that we need a
more detailed measurement that is realistic. In the desktop case for
example we have enough time since the users still has to still enter
their password to unlock the screensaver. For the embedded type devices
like phones etc., the impact is also not present. At least I've never
seen it. There are other bottlenecks like updating the DHCP lease etc.
Regards
Marcel
--
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
