On Tuesday 17 December 2019 12:52:11 CET Greg Kroah-Hartman wrote: > On Mon, Dec 16, 2019 at 05:03:33PM +0000, Jérôme Pouiller wrote: > > From: Jérôme Pouiller <jerome.pouil...@silabs.com> > > > > Device and driver maintain a cache of rate policies (aka. > > tx_retry_policy in hardware API). > > > > When hif_reset() is sent to hardware, device resets its cache of rate > > policies. In order to keep driver in sync, it is necessary to do the > > same on driver. > > > > Note, when driver tries to use a rate policy that has not been defined > > on device, data is sent at 1Mbps. So, this patch should fix abnormal > > throughput observed sometime after a reset of the interface. > > > > Signed-off-by: Jérôme Pouiller <jerome.pouil...@silabs.com> > > --- > > drivers/staging/wfx/data_tx.c | 3 +-- > > drivers/staging/wfx/data_tx.h | 1 + > > drivers/staging/wfx/sta.c | 6 +++++- > > 3 files changed, 7 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/staging/wfx/data_tx.c b/drivers/staging/wfx/data_tx.c > > index b722e9773232..02f001dab62b 100644 > > --- a/drivers/staging/wfx/data_tx.c > > +++ b/drivers/staging/wfx/data_tx.c > > @@ -249,7 +249,7 @@ static int wfx_tx_policy_upload(struct wfx_vif *wvif) > > return 0; > > } > > > > -static void wfx_tx_policy_upload_work(struct work_struct *work) > > +void wfx_tx_policy_upload_work(struct work_struct *work) > > { > > struct wfx_vif *wvif = > > container_of(work, struct wfx_vif, tx_policy_upload_work); > > @@ -270,7 +270,6 @@ void wfx_tx_policy_init(struct wfx_vif *wvif) > > spin_lock_init(&cache->lock); > > INIT_LIST_HEAD(&cache->used); > > INIT_LIST_HEAD(&cache->free); > > - INIT_WORK(&wvif->tx_policy_upload_work, wfx_tx_policy_upload_work); > > > > for (i = 0; i < HIF_MIB_NUM_TX_RATE_RETRY_POLICIES; ++i) > > list_add(&cache->cache[i].link, &cache->free); > > diff --git a/drivers/staging/wfx/data_tx.h b/drivers/staging/wfx/data_tx.h > > index 29faa5640516..a0f9ae69baf5 100644 > > --- a/drivers/staging/wfx/data_tx.h > > +++ b/drivers/staging/wfx/data_tx.h > > @@ -61,6 +61,7 @@ struct wfx_tx_priv { > > } __packed; > > > > void wfx_tx_policy_init(struct wfx_vif *wvif); > > +void wfx_tx_policy_upload_work(struct work_struct *work); > > > > void wfx_tx(struct ieee80211_hw *hw, struct ieee80211_tx_control *control, > > struct sk_buff *skb); > > diff --git a/drivers/staging/wfx/sta.c b/drivers/staging/wfx/sta.c > > index 29848a202ab4..471dd15b227f 100644 > > --- a/drivers/staging/wfx/sta.c > > +++ b/drivers/staging/wfx/sta.c > > @@ -592,6 +592,7 @@ static void wfx_do_unjoin(struct wfx_vif *wvif) > > wfx_tx_flush(wvif->wdev); > > hif_keep_alive_period(wvif, 0); > > hif_reset(wvif, false); > > + wfx_tx_policy_init(wvif); > > hif_set_output_power(wvif, wvif->wdev->output_power * 10); > > wvif->dtim_period = 0; > > hif_set_macaddr(wvif, wvif->vif->addr); > > @@ -880,8 +881,10 @@ static int wfx_update_beaconing(struct wfx_vif *wvif) > > if (wvif->state != WFX_STATE_AP || > > wvif->beacon_int != conf->beacon_int) { > > wfx_tx_lock_flush(wvif->wdev); > > - if (wvif->state != WFX_STATE_PASSIVE) > > + if (wvif->state != WFX_STATE_PASSIVE) { > > hif_reset(wvif, false); > > + wfx_tx_policy_init(wvif); > > + } > > wvif->state = WFX_STATE_PASSIVE; > > wfx_start_ap(wvif); > > wfx_tx_unlock(wvif->wdev); > > @@ -1567,6 +1570,7 @@ int wfx_add_interface(struct ieee80211_hw *hw, struct > > ieee80211_vif *vif) > > INIT_WORK(&wvif->set_cts_work, wfx_set_cts_work); > > INIT_WORK(&wvif->unjoin_work, wfx_unjoin_work); > > > > + INIT_WORK(&wvif->tx_policy_upload_work, wfx_tx_policy_upload_work); > > mutex_unlock(&wdev->conf_mutex); > > > > hif_set_macaddr(wvif, vif->addr); > > Meta-comment here. > > I've been having to hand-edit your patches to get them to be able to > apply so far, which is fine for 1-10 patches at a time, but when staring > down a 55-patch series, that's not ok for my end. > > The problem is that your email client is turning everything into base64 > text. On it's own, that's fine, but when doing so it turns the > line-ends from unix ones, into dos line-ends. So, when git decodes the > base64 text into "plain text" the patch obviously does not apply due to > the line-ends not matching up. > > Any chance you can fix your email client to not convert the line-ends?
Arg... I apologize for that. Yes, I will fix it and re-send the pull-request. For the record: In fact, the conversions to CR-LF and to base64 is done by the SMTP server that I use (Microsoft Exchange... useless to say that I do not administrate this server). I have already noticed that my SMTP server did weird things. So, I configured git to encode in base64 itself. However, the configuration line "sendemail.transferEncoding" is ignored in my version of git (2.20) (--transfer-encoding=base64 continue to work). Fortunately, the problem seems fixed with git 2.24. -- Jérôme Pouiller _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel