On Tue, Nov 20, 2012 at 10:18 AM, Luciano Coelho <coelho@xxxxxx> wrote: > On Mon, 2012-11-19 at 18:39 +0200, Eliad Peller wrote: >> With the new connection flow, start_sta is called before >> the remote rates where updated. Use our own supported rates >> instead to make sure we don't disable any potential rate >> (the rate policies will be updated later, but there is >> currently no way to update the remote rates) >> >> Signed-off-by: Eliad Peller <eliad@xxxxxxxxxx> >> --- >> drivers/net/wireless/ti/wlcore/cmd.c | 7 ++++++- >> 1 files changed, 6 insertions(+), 1 deletions(-) >> >> diff --git a/drivers/net/wireless/ti/wlcore/cmd.c b/drivers/net/wireless/ti/wlcore/cmd.c >> index 4c2ed25..ec7e8b3 100644 >> --- a/drivers/net/wireless/ti/wlcore/cmd.c >> +++ b/drivers/net/wireless/ti/wlcore/cmd.c >> @@ -479,7 +479,12 @@ int wl12xx_cmd_role_start_sta(struct wl1271 *wl, struct wl12xx_vif *wlvif) >> } >> cmd->sta.hlid = wlvif->sta.hlid; >> cmd->sta.session = wl12xx_get_new_session_id(wl, wlvif); >> - cmd->sta.remote_rates = cpu_to_le32(wlvif->rate_set); >> + /* >> + * We don't have the correct remote rates in this stage, and there >> + * is no way to update them later, so use our supported rates instead. >> + * The fw will take the configured rate policies into account anyway. >> + */ >> + cmd->sta.remote_rates = cpu_to_le32(supported_rates); > > Why do we even have to pass this value, then? Any hidden reason that we > may be overlooking? > the fw uses an intersection our local_supported_rates, the remote_rates and the rate_policy in order to determine the rates. i'm not too familiar with its whole logic, though. Eliad. -- 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
