BMC/Intel-BMC/linux.git/drivers/net/wireless/ralink, branch dev-5.4

rt2800: remove errornous duplicate condition

2020-01-26T09:01:06+00:00

[ Upstream commit a1f7c2cabf701a17b1a05d6526bbdadc3d05e05c ] On 2019-10-28 06:07, wbob wrote: > Hello Roman, > > while reading around drivers/net/wireless/ralink/rt2x00/rt2800lib.c > I stumbled on what I think is an edit of yours made in error in march > 2017: > > https://github.com/torvalds/linux/commit/41977e86#diff-dae5dc10da180f3b055809a48118e18aR5281 > > RT6352 in line 5281 should not have been introduced as the "else if" > below line 5291 can then not take effect for a RT6352 device. Another > possibility is for line 5291 to be not for RT6352, but this seems > very unlikely. Are you able to clarify still after this substantial time? > > 5277: static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev) > ... > 5279: } else if (rt2x00_rt(rt2x00dev, RT5390) || > 5280: rt2x00_rt(rt2x00dev, RT5392) || > 5281: rt2x00_rt(rt2x00dev, RT6352)) { > ... > 5291: } else if (rt2x00_rt(rt2x00dev, RT6352)) { > ... Hence remove errornous line 5281 to make the driver actually execute the correct initialization routine for MT7620 chips. As it was requested by Stanislaw Gruszka remove setting values of MIMO_PS_CFG and TX_PIN_CFG. MIMO_PS_CFG is responsible for MIMO power-safe mode (which is disabled), hence we can drop setting it. TX_PIN_CFG is set correctly in other functions, and as setting this value breaks some devices, rather don't set it here during init, but only modify it later on. Fixes: 41977e86c984 ("rt2x00: add support for MT7620") Reported-by: wbob Reported-by: Roman Yeryomin Signed-off-by: Daniel Golle Acked-by: Stanislaw Gruszka Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin

rt2x00: remove input-polldev.h header

2019-10-08T15:49:22+00:00

The driver does not use input subsystem so we do not need this header, and it is being removed, so stop pulling it in. Signed-off-by: Dmitry Torokhov Signed-off-by: Kalle Valo

rt2x00: initialize last_reset

2019-10-02T04:36:52+00:00

Initialize last_reset variable to INITIAL_JIFFIES, otherwise it is not possible to test H/W reset for first 5 minutes of system run. Fixes: e403fa31ed71 ("rt2x00: add restart hw") Reported-and-tested-by: Jonathan Liu Signed-off-by: Stanislaw Gruszka Signed-off-by: Kalle Valo

drivers: net: Fix Kconfig indentation

2019-09-26T06:56:17+00:00

Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski Acked-by: Kalle Valo Reviewed-by: Leon Romanovsky Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2019-09-15T12:17:27+00:00

Minor overlapping changes in the btusb and ixgbe drivers. Signed-off-by: David S. Miller

Revert "rt2800: enable TX_PIN_CFG_LNA_PE_ bits per band"

2019-09-03T13:52:22+00:00

This reverts commit 9ad3b55654455258a9463384edb40077439d879f. As reported by Sergey: "I got some problem after upgrade kernel to 5.2 version (debian testing linux-image-5.2.0-2-amd64). 5Ghz client stopped to see AP. Some tests with 1metre distance between client-AP: 2.4Ghz -22dBm, for 5Ghz - 53dBm !, for longer distance (8m + walls) 2.4 - 61dBm, 5Ghz not visible." It was identified that rx signal level degradation was caused by 9ad3b5565445 ("rt2800: enable TX_PIN_CFG_LNA_PE_ bits per band"). So revert this commit. Cc: # v5.1+ Reported-and-tested-by: Sergey Maranchuk Signed-off-by: Stanislaw Gruszka Signed-off-by: Kalle Valo

rt2x00: clear up IV's on key removal

2019-09-03T13:51:30+00:00

After looking at code I realized that my previous fix 95844124385e ("rt2x00: clear IV's on start to fix AP mode regression") was incomplete. We can still have wrong IV's after re-keyring. To fix that, clear up IV's also on key removal. Fixes: 710e6cc1595e ("rt2800: do not nullify initialization vector data") Signed-off-by: Stanislaw Gruszka tested-by: Emil Karlson Signed-off-by: Kalle Valo

rt2x00: do not set IEEE80211_TX_STAT_AMPDU_NO_BACK on tx status

2019-09-03T13:41:15+00:00

According to documentation IEEE80211_TX_STAT_AMPDU_NO_BACK is suppose to be used when we do not recive BA (BlockAck). However on rt2x00 we use it when remote station fail to decode one or more subframes within AMPDU (some bits are not set in BlockAck bitmap). Setting the flag result in sent of BAR (BlockAck Request) frame and this might result of abuse of BA session, since remote station can sent BA with incorrect sequence numbers after receiving BAR. This problem is visible especially when connecting two rt2800 devices. Previously I observed some performance benefits when using the flag when connecting with iwlwifi devices. But currently possibly due to reacent changes in rt2x00 removing the flag has no effect on those test cases. So remove the IEEE80211_TX_STAT_AMPDU_NO_BACK. Signed-off-by: Stanislaw Gruszka Signed-off-by: Kalle Valo

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2019-08-27T21:23:31+00:00

Minor conflict in r8169, bug fix had two versions in net and net-next, take the net-next hunks. Signed-off-by: David S. Miller

rt2x00: clear IV's on start to fix AP mode regression

2019-08-20T13:59:22+00:00

To do not brake HW restart we should keep initialization vectors data. I assumed that on start the data is already initialized to zeros, but that not true on some scenarios and we should clear it. So add additional flag to check if we are under HW restart and clear IV's data if we are not. Patch fixes AP mode regression. Reported-and-tested-by: Emil Karlson Fixes: 710e6cc1595e ("rt2800: do not nullify initialization vector data") Signed-off-by: Stanislaw Gruszka Signed-off-by: Kalle Valo