Luis R. Rodriguez wrote: > On Fri, Feb 4, 2011 at 11:42 AM, Mark Mentovai <mark@xxxxxxxxxxxx> wrote: >> If you can come up with a good way to compute the hardware maximum per >> channel (overcoming ath9k_init_txpower_limits’s current faults), then >> I think this can be accommodated with another field, but I don’t think >> orig_mpwr should be overloaded. Maybe renamed to better reflect its >> purpose, though. > > I do wonder if the patch above introduced a regression I overlooked.. (Re babcbc295fee766ca710235e431686fef744d9a6) I don’t think it introduced any regressions, because max_power and orig_mpwr are always updated with regulatory-based values. I think that the patch was effectively a no-op. It tried to set better initial values, but the regulatory values that superseded them didn’t change. >> I don’t think that a good way for a driver to reflect the transmit >> power it has actually put into effect (after taking the effects of CTL >> limits) back to user space currently exists. > > What do you mean here, sorry I could not follow. The user space interface for txpower winds up getting piped through cfg80211_ops’ set_tx_power and get_tx_power fields. For mac80211, net/mac80211/cfg.c sends set_tx_power requests through to the driver (ieee80211_set_tx_power calls ieee80211_hw_config which calls through to an ieee80211_ops config field), but get_tx_power requests are satisfied without ever checking the driver. mac80211 get_tx_power just pulls a cached value out of an ieee80211_local. A driver couldn’t even push a better value back into mac80211, because its ieee80211_local is private. Felix Fietkau wrote: > Right, for testing the tx power, we need to override the > twiceMaxRegulatoryPower parameter that we pass to the set_txpower op. That would work for ath9k. I still think it’d be prudent to examine a handful of rates. I also seem to remember that some other values that were being used within ath9k_init_txpower_limits were invalid. I think ntxchains was invalid during that early phase of initialization, for example. That might not have any ultimate effect on the result, but it’s not right to hit that ath_debug claiming "Invalid chainmask configuration" once for every supported channel every time the driver initializes. -- 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
