On Thu, Mar 26, 2009 at 1:19 AM, Kalle Valo <kalle.valo@xxxxxx> wrote: > "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. Oh I don't care for it, I just don't think its a good idea to be adding more knobs and agree with the general sentiment to always focus on saving power. Luis -- 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
