"Luis R. Rodriguez" <mcgrof@xxxxxxxxx> writes: > On Wed, Mar 25, 2009 at 8:48 AM, Johannes Berg > <johannes@xxxxxxxxxxxxxxxx> wrote: >> On Wed, 2009-03-25 at 11:31 -0400, Dan Williams wrote: >> >>> Yeah, sounds OK. Just to be clear, problems with this code will appear >>> on a *per-AP* basis, not a per-card basis, right? ie there are some >>> stupid APs that won't work with it, but it won't be the case that a >>> chipset will be broken for all APs, right? >> >> Right. If a particular chipset doesn't properly supported PS then we >> shouldn't actually support it at all -- but we cannot know if the AP is >> broken. > > How about leaving it to the supplicant to guess if the AP is borked or not. Very difficult and not worth the trouble IMHO. > Kalle, what would happen with these broken APs? Usually there's packet loss and for the user it shows as data connections not working reliably. > If we can determine this through some heuristics then we can label > such BSSes as borked in the supplicant and then the user won't have to > worry about this. This would only be dealt with each BSS once at most > as we would have saved the AP's power save borkedness after our first > determination of this. > > If one wants to do manual debugging you can simple add the flag > through the supplicant for the bss. Just don't see the need to confuse > a user with an option if we can get away with figuring it out if > possible. If the ui option to disable power is disliked, just hide it somewhere. For example, a gconf flag which can be enabled with a command line tool. -- Kalle Valo -- 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
