RE: [PATCH] ath10k: support PCIe enter L1 state
> -Original Message- > From: ath10k On Behalf Of Brian > Norris > Sent: Thursday, November 15, 2018 8:29 AM > To: Wen Gong > Cc: linux-wireless@vger.kernel.org; ath...@lists.infradead.org > Subject: [EXTERNAL] Re: [PATCH] ath10k: support PCIe enter L1 state > > Hi Wen, > > > > > Signed-off-by: Wen Gong > > Is there some reason L1 was disabled in the first place? Wa s it known to be > unreliable? > Hi Brian, It is a BUG for power, and it is not considered this BUG before. So this change will fix the bug. > Brian > > ___ > ath10k mailing list > ath...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH v4 2/3] dts: arm64/sdm845: Add WCN3990 WLAN module device node
Hi Govind,
On Mon, Nov 05, 2018 at 06:38:37PM +0530, Govind Singh wrote:
> Add device node for the ath10k SNOC platform driver probe
> and add resources required for WCN3990 on SDM845 soc.
>
> Signed-off-by: Govind Singh
> Reviewed-by: Brian Norris
> Tested-by: Brian Norris
> ---
> arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 8
> arch/arm64/boot/dts/qcom/sdm845.dtsi| 26 ++
> 2 files changed, 34 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> index eedfaf8..c062c5c 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> @@ -440,3 +440,11 @@
> bias-pull-up;
> };
> };
> +
> +&wifi {
> + status = "okay";
> + vdd-0.8-cx-mx-supply = <&vreg_l5a_0p8>;
> + vdd-1.8-xo-supply = <&vreg_l7a_1p8>;
> + vdd-1.3-rfa-supply = <&vreg_l17a_1p3>;
> + vdd-3.3-ch0-supply = <&vreg_l25a_3p3>;
> +};
This node should be above the PINCTRL section.
Brian
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index b72bdb0..324be5b 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -87,6 +87,11 @@
> reg = <0 0x8620 0 0x2d0>;
> no-map;
> };
> +
> + wlan_msa_mem: memory@9670 {
> + reg = <0 0x9670 0 0x10>;
> + no-map;
> + };
> };
>
> cpus {
> @@ -1403,5 +1408,26 @@
> status = "disabled";
> };
> };
> +
> + wifi: wifi@1880 {
> + compatible = "qcom,wcn3990-wifi";
> + status = "disabled";
> + reg = <0x1880 0x80>;
> + reg-names = "membase";
> + memory-region = <&wlan_msa_mem>;
> + interrupts =
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ;
> + };
> };
> };
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
Re: atk10k Unknown eventid and WARN() on resume with kernel 4.19
Am Mi., 14. Nov. 2018 um 23:16 Uhr schrieb Gabriel C : > > > Hello, > > > > > > starting with kernel 4.19 we noticed 'Unknown eventid: ' warnings > > > on our Laptops. > > > > > > ... > > > > > > crazy@devnull:~$ dmesg | grep Unknow > > > [7.144998] ath10k_pci :03:00.0: Unknown eventid: 118809 > > > [7.147758] ath10k_pci :03:00.0: Unknown eventid: 90118 > > > [9.441654] ath10k_pci :03:00.0: Unknown eventid: 118809 > > > [9.46] ath10k_pci :03:00.0: Unknown eventid: 90118 > > > [ 11.770997] ath10k_pci :03:00.0: Unknown eventid: 118809 > > > [ 11.773787] ath10k_pci :03:00.0: Unknown eventid: 90118 > > > [320339.374108] ath10k_pci :03:00.0: Unknown eventid: 118809 > > > [320339.377020] ath10k_pci :03:00.0: Unknown eventid: 90118 > > > [320342.128664] ath10k_pci :03:00.0: Unknown eventid: 118809 > > > [320342.131447] ath10k_pci :03:00.0: Unknown eventid: 90118 > > > [320344.452864] ath10k_pci :03:00.0: Unknown eventid: 118809 > > > [320344.455696] ath10k_pci :03:00.0: Unknown eventid: 90118 > > > > > > > > > > > > Both boxes also hits the following WARN*() on resume from S3: > > > > > Uh sorry .. Gmail doesn't like long lines it seems. > > There the WARN() message: > > > > http://ftp.frugalware.org/pub/other/people/crazy/warn.txt > > > > > > > > Please let me know if you need an dmesg or any other informations. > > > Added pm list maybe someone there got some idea ? > > Also same issue reported there : > https://bugzilla.kernel.org/show_bug.cgi?id=201499 > The WARN_ON() on resume seems to be triggered after commit cd93b83ad927b. BR, Gabriel C
Re: [PATCH] ath10k: support PCIe enter L1 state
Hi Wen, On Wed, Nov 14, 2018 at 10:50:48AM +0800, Wen Gong wrote: > QCA6174A/QCA9377 PCIe chips support PCIe L1 and L1SS, and indicate the > L1/L1SS capabilities in PCI configuration space. Currently ath10k driver > write target PCIe config flags to disallow HW enter into L1, this leads > some HW modules are still powered up even when both system PCIe RC and > QCA6174A/QCA9377 endpoint decides to enter into L1 or L1SS. > > This cause ~12 mA power drain of bottom power consumption for all scenarios. > Fix this issue by removing the drive code to write PCIe config flags. > > Tested with QCA6174 PCI with firmware > WLAN.RM.4.4.1-00109-QCARMSWPZ-1, but this will also affect QCA9377 PCI. > It's not a regression with new firmware releases. > > Signed-off-by: Wen Gong Is there some reason L1 was disabled in the first place? Was it known to be unreliable? Brian
[PATCH] iw: add FEATURE support for scan randomization
Signed-off-by: Brian Norris
---
info.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/info.c b/info.c
index d0577e32552e..f1a25daa63da 100644
--- a/info.c
+++ b/info.c
@@ -609,6 +609,12 @@ broken_combination:
printf("\tDevice supports configuring vdev MAC-addr on
create.\n");
if (features & NL80211_FEATURE_TDLS_CHANNEL_SWITCH)
printf("\tDevice supports TDLS channel switching\n");
+ if (features & NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR)
+ printf("\tDevice supports randomizing MAC-addr in
scans.\n");
+ if (features & NL80211_FEATURE_SCHED_SCAN_RANDOM_MAC_ADDR)
+ printf("\tDevice supports randomizing MAC-addr in sched
scans.\n");
+ if (features & NL80211_FEATURE_ND_RANDOM_MAC_ADDR)
+ printf("\tDevice supports randomizing MAC-addr in
net-detect scans.\n");
}
if (tb_msg[NL80211_ATTR_TDLS_SUPPORT])
--
2.19.1.930.g4563a0d9d0-goog
Re: [PATCH v3] ath10k: support NET_DETECT WoWLAN feature
Hi Wen,
You've introduced a regression in 4.20-rc1:
On Thu, Aug 16, 2018 at 02:48:33PM +0800, Wen Gong wrote:
> For WoWLAN support, it expect to support wake up based on discovery of
> one or more known SSIDs. This is the WIPHY_WOWLAN_NET_DETECT feature,
> which shows up as an NL80211 feature flag.
>
> With an upgrade iw, this shows up in 'iw phy' as:
> WoWLAN support:
> * wake up on network detection, up to 16 match sets
> And it can use command:
> "iw phy0 wowlan enable net-detect interval 5000 delay 30 freqs 2412
> matches ssid foo" to configure the parameters of net detect.
>
> Firmware will do scan by the configured parameters after suspend and
> wakeup if it found matched SSIDs. Tested with QCA6174 hw3.0 with
> firmware WLAN.RM.4.4.1-00110-QCARMSWPZ-1.
>
> Signed-off-by: Wen Gong
> ---
> V3:
> -fix the waring of alloc with no test
> drivers/net/wireless/ath/ath10k/core.h| 1 +
> drivers/net/wireless/ath/ath10k/mac.c | 12 ++
> drivers/net/wireless/ath/ath10k/wmi-ops.h | 21 +++
> drivers/net/wireless/ath/ath10k/wmi-tlv.c | 180 +++-
> drivers/net/wireless/ath/ath10k/wmi-tlv.h | 226
> ++
> drivers/net/wireless/ath/ath10k/wmi.h | 57
> drivers/net/wireless/ath/ath10k/wow.c | 174 +++
> 7 files changed, 670 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.h
> b/drivers/net/wireless/ath/ath10k/core.h
> index 427ee57..7885462 100644
> --- a/drivers/net/wireless/ath/ath10k/core.h
> +++ b/drivers/net/wireless/ath/ath10k/core.h
> @@ -904,6 +904,7 @@ struct ath10k {
> u32 high_5ghz_chan;
> bool ani_enabled;
>
> + bool nlo_enabled;
> bool p2p;
>
> struct {
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
> b/drivers/net/wireless/ath/ath10k/mac.c
> index 95243b4..ba9b9af 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -8361,6 +8361,18 @@ int ath10k_mac_register(struct ath10k *ar)
> ar->hw->wiphy->max_scan_ssids = WLAN_SCAN_PARAMS_MAX_SSID;
> ar->hw->wiphy->max_scan_ie_len = WLAN_SCAN_PARAMS_MAX_IE_LEN;
>
> + if (test_bit(WMI_SERVICE_NLO, ar->wmi.svc_map)) {
> + ar->hw->wiphy->max_sched_scan_reqs = 1;
> + ar->hw->wiphy->max_sched_scan_ssids = WMI_PNO_MAX_SUPP_NETWORKS;
> + ar->hw->wiphy->max_match_sets = WMI_PNO_MAX_SUPP_NETWORKS;
> + ar->hw->wiphy->max_sched_scan_ie_len = WMI_PNO_MAX_IE_LENGTH;
> + ar->hw->wiphy->max_sched_scan_plans =
> WMI_PNO_MAX_SCHED_SCAN_PLANS;
> + ar->hw->wiphy->max_sched_scan_plan_interval =
> + WMI_PNO_MAX_SCHED_SCAN_PLAN_INT;
> + ar->hw->wiphy->max_sched_scan_plan_iterations =
> + WMI_PNO_MAX_SCHED_SCAN_PLAN_ITRNS;
It seems like youre enabling SCHED_SCAN support? But you're not adding
the NL80211_FEATURE_SCHED_SCAN_RANDOM_MAC_ADDR feature flag. So it puts
us in a tough place on using randomization -- we either can't trust the
FEATURE flags, or else we can't use both SCHED_SCAN and scan
randomization.
I haven't played with this much at all yet (except to notice that my
tests no longer pass), but maybe you just need to add the FEATURE flag.
Brian
> + }
> +
> ar->hw->vif_data_size = sizeof(struct ath10k_vif);
> ar->hw->sta_data_size = sizeof(struct ath10k_sta);
> ar->hw->txq_data_size = sizeof(struct ath10k_txq);
...
Re: atk10k Unknown eventid and WARN() on resume with kernel 4.19
Am Sa., 3. Nov. 2018 um 21:11 Uhr schrieb Gabriel C : > > Am Sa., 3. Nov. 2018 um 21:01 Uhr schrieb Gabriel C : > > > > Hello, > > > > starting with kernel 4.19 we noticed 'Unknown eventid: ' warnings > > on our Laptops. > > > > ... > > > > crazy@devnull:~$ dmesg | grep Unknow > > [7.144998] ath10k_pci :03:00.0: Unknown eventid: 118809 > > [7.147758] ath10k_pci :03:00.0: Unknown eventid: 90118 > > [9.441654] ath10k_pci :03:00.0: Unknown eventid: 118809 > > [9.46] ath10k_pci :03:00.0: Unknown eventid: 90118 > > [ 11.770997] ath10k_pci :03:00.0: Unknown eventid: 118809 > > [ 11.773787] ath10k_pci :03:00.0: Unknown eventid: 90118 > > [320339.374108] ath10k_pci :03:00.0: Unknown eventid: 118809 > > [320339.377020] ath10k_pci :03:00.0: Unknown eventid: 90118 > > [320342.128664] ath10k_pci :03:00.0: Unknown eventid: 118809 > > [320342.131447] ath10k_pci :03:00.0: Unknown eventid: 90118 > > [320344.452864] ath10k_pci :03:00.0: Unknown eventid: 118809 > > [320344.455696] ath10k_pci :03:00.0: Unknown eventid: 90118 > > > > > > > > Both boxes also hits the following WARN*() on resume from S3: > > > Uh sorry .. Gmail doesn't like long lines it seems. > There the WARN() message: > > http://ftp.frugalware.org/pub/other/people/crazy/warn.txt > > > > > Please let me know if you need an dmesg or any other informations. Added pm list maybe someone there got some idea ? Also same issue reported there : https://bugzilla.kernel.org/show_bug.cgi?id=201499 BR, Gabriel C
Re: [PATCH v3 3/3] b43: Use cordic algorithm from kernel library
On Wed, 14 Nov 2018 20:27:52 +0200 Priit Laes wrote: > Kernel library has a common cordic algorithm which is identical > to internally implementatd one, so use it and drop the duplicate > implementation. In v2 of the series it has been said that: Arend van Spriel wrote: > I recall doing a comparison between the algorithms and thought I put > that in the original commit message. However, it is not there. It is not > exactly the same as in b43 so there are difference for certain angles, > most results are the same however. This implementation is slightly more > accurate on the full scale. That's not my definition of "identical". Please do not apply this patch without doing a thorough regression test on actual b43 LP hardware. -- Michael pgplbk4jvgDhd.pgp Description: OpenPGP digital signature
[PATCH v3 2/3] brcmsmac: Use cordic-related macros from common cordic library
Current driver includes macro that is available from general cordic
library. Use that and drop unused duplicate and unneeded internal
definitions.
Signed-off-by: Priit Laes
---
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_int.h | 7 +---
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c | 4 ++--
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c | 4 ++--
3 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_int.h
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_int.h
index 4960f7d..e9e8337 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_int.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_int.h
@@ -220,13 +220,6 @@ enum phy_cal_mode {
#define BB_MULT_MASK 0x
#define BB_MULT_VALID_MASK 0x8000
-#define CORDIC_AG 39797
-#defineCORDIC_NI 18
-#defineFIXED(X)((s32)((X) << 16))
-
-#defineFLOAT(X) \
- (((X) >= 0) ? X) >> 15) + 1) >> 1) : --(X)) >> 15) + 1) >> 1))
-
#define PHY_CHAIN_TX_DISABLE_TEMP 115
#define PHY_HYSTERESIS_DELTATEMP 5
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c
index 9fb0d9f..e78a93a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c
@@ -3447,8 +3447,8 @@ wlc_lcnphy_start_tx_tone(struct brcms_phy *pi, s32 f_kHz,
u16 max_val,
theta += rot;
- i_samp = (u16) (FLOAT(tone_samp.i * max_val) & 0x3ff);
- q_samp = (u16) (FLOAT(tone_samp.q * max_val) & 0x3ff);
+ i_samp = (u16)(CORDIC_FLOAT(tone_samp.i * max_val) & 0x3ff);
+ q_samp = (u16)(CORDIC_FLOAT(tone_samp.q * max_val) & 0x3ff);
data_buf[t] = (i_samp << 10) | q_samp;
}
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
index a57f271..f4f5e90 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -23089,8 +23089,8 @@ wlc_phy_gen_load_samples_nphy(struct brcms_phy *pi, u32
f_kHz, u16 max_val,
theta += rot;
- tone_buf[t].q = (s32) FLOAT(tone_buf[t].q * max_val);
- tone_buf[t].i = (s32) FLOAT(tone_buf[t].i * max_val);
+ tone_buf[t].q = (s32)CORDIC_FLOAT(tone_buf[t].q * max_val);
+ tone_buf[t].i = (s32)CORDIC_FLOAT(tone_buf[t].i * max_val);
}
wlc_phy_loadsampletable_nphy(pi, tone_buf, num_samps);
--
git-series 0.9.1
[PATCH v3 3/3] b43: Use cordic algorithm from kernel library
Kernel library has a common cordic algorithm which is identical
to internally implementatd one, so use it and drop the duplicate
implementation.
Signed-off-by: Priit Laes
---
drivers/net/wireless/broadcom/b43/Kconfig | 1 +-
drivers/net/wireless/broadcom/b43/phy_common.c | 47 +---
drivers/net/wireless/broadcom/b43/phy_common.h | 9 +
drivers/net/wireless/broadcom/b43/phy_lp.c | 13 ++---
drivers/net/wireless/broadcom/b43/phy_n.c | 13 ++---
5 files changed, 15 insertions(+), 68 deletions(-)
diff --git a/drivers/net/wireless/broadcom/b43/Kconfig
b/drivers/net/wireless/broadcom/b43/Kconfig
index fba8560..3e41457 100644
--- a/drivers/net/wireless/broadcom/b43/Kconfig
+++ b/drivers/net/wireless/broadcom/b43/Kconfig
@@ -4,6 +4,7 @@ config B43
select BCMA if B43_BCMA
select SSB if B43_SSB
select FW_LOADER
+ select CORDIC
---help---
b43 is a driver for the Broadcom 43xx series wireless devices.
diff --git a/drivers/net/wireless/broadcom/b43/phy_common.c
b/drivers/net/wireless/broadcom/b43/phy_common.c
index 85f2ca9..98c4fa5 100644
--- a/drivers/net/wireless/broadcom/b43/phy_common.c
+++ b/drivers/net/wireless/broadcom/b43/phy_common.c
@@ -604,50 +604,3 @@ void b43_phy_force_clock(struct b43_wldev *dev, bool force)
#endif
}
}
-
-/* http://bcm-v4.sipsolutions.net/802.11/PHY/Cordic */
-struct b43_c32 b43_cordic(int theta)
-{
- static const u32 arctg[] = {
- 2949120, 1740967, 919879, 466945, 234379, 117304,
- 58666, 29335, 14668, 7334, 3667, 1833,
- 917, 458,229,115, 57, 29,
- };
- u8 i;
- s32 tmp;
- s8 signx = 1;
- u32 angle = 0;
- struct b43_c32 ret = { .i = 39797, .q = 0, };
-
- while (theta > (180 << 16))
- theta -= (360 << 16);
- while (theta < -(180 << 16))
- theta += (360 << 16);
-
- if (theta > (90 << 16)) {
- theta -= (180 << 16);
- signx = -1;
- } else if (theta < -(90 << 16)) {
- theta += (180 << 16);
- signx = -1;
- }
-
- for (i = 0; i <= 17; i++) {
- if (theta > angle) {
- tmp = ret.i - (ret.q >> i);
- ret.q += ret.i >> i;
- ret.i = tmp;
- angle += arctg[i];
- } else {
- tmp = ret.i + (ret.q >> i);
- ret.q -= ret.i >> i;
- ret.i = tmp;
- angle -= arctg[i];
- }
- }
-
- ret.i *= signx;
- ret.q *= signx;
-
- return ret;
-}
diff --git a/drivers/net/wireless/broadcom/b43/phy_common.h
b/drivers/net/wireless/broadcom/b43/phy_common.h
index 57a1ad8..4213cac 100644
--- a/drivers/net/wireless/broadcom/b43/phy_common.h
+++ b/drivers/net/wireless/broadcom/b43/phy_common.h
@@ -7,13 +7,6 @@
struct b43_wldev;
-/* Complex number using 2 32-bit signed integers */
-struct b43_c32 { s32 i, q; };
-
-#define CORDIC_CONVERT(value) (((value) >= 0) ? \
-value) >> 15) + 1) >> 1) : \
---(value)) >> 15) + 1) >> 1))
-
/* PHY register routing bits */
#define B43_PHYROUTE 0x0C00 /* PHY register routing bits
mask */
#define B43_PHYROUTE_BASE 0x /* Base registers */
@@ -450,6 +443,4 @@ bool b43_is_40mhz(struct b43_wldev *dev);
void b43_phy_force_clock(struct b43_wldev *dev, bool force);
-struct b43_c32 b43_cordic(int theta);
-
#endif /* LINUX_B43_PHY_COMMON_H_ */
diff --git a/drivers/net/wireless/broadcom/b43/phy_lp.c
b/drivers/net/wireless/broadcom/b43/phy_lp.c
index 6922cbb..1718e3b 100644
--- a/drivers/net/wireless/broadcom/b43/phy_lp.c
+++ b/drivers/net/wireless/broadcom/b43/phy_lp.c
@@ -23,6 +23,7 @@
*/
+#include
#include
#include "b43.h"
@@ -1780,9 +1781,9 @@ static void lpphy_start_tx_tone(struct b43_wldev *dev,
s32 freq, u16 max)
{
struct b43_phy_lp *lpphy = dev->phy.lp;
u16 buf[64];
- int i, samples = 0, angle = 0;
+ int i, samples = 0, theta = 0;
int rotation = (((36 * freq) / 20) << 16) / 100;
- struct b43_c32 sample;
+ struct cordic_iq sample;
lpphy->tx_tone_freq = freq;
@@ -1798,10 +1799,10 @@ static void lpphy_start_tx_tone(struct b43_wldev *dev,
s32 freq, u16 max)
}
for (i = 0; i < samples; i++) {
- sample = b43_cordic(angle);
- angle += rotation;
- buf[i] = CORDIC_CONVERT((sample.i * max) & 0xFF) << 8;
- buf[i] |= CORDIC_CONVERT((sample.q * max) & 0xFF);
+ sample = cordic_calc_iq(theta);
+ theta += rotation;
+ buf[i] = CORDIC_FLOAT((sample.i * max) & 0xFF) << 8;
+ buf[i] |= CORDIC_FLOAT((sample.q * max) & 0xFF);
}
[PATCH v3 0/3] wireless: Use common cordic algorithm for b43 driver
b43 wireless driver includes an internal implementation of cordic algorithm, although there's a common cordic library which was split out from brcmsmac driver. Use that and drop internal implementation. During the process, cordic-algorithm related macros in brcmfmac driver were also removed and use general macros. Please note that this series is only compile-tested, as I do not have access to the hardware. Changes since v2: - Improvements to commit messages. No functional changes. - Collect reviewed-by bits. Changes since v1: - Merged brcmsmac driver patches into single patch - Merged b43 driver patches into single patch Priit Laes (3): lib: cordic: Move cordic macros and defines to header file brcmsmac: Use cordic-related macros from common cordic library b43: Use cordic algorithm from kernel library drivers/net/wireless/broadcom/b43/Kconfig | 1 +- drivers/net/wireless/broadcom/b43/phy_common.c | 47 +--- drivers/net/wireless/broadcom/b43/phy_common.h | 9 +- drivers/net/wireless/broadcom/b43/phy_lp.c | 13 +- drivers/net/wireless/broadcom/b43/phy_n.c | 13 +- drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_int.h | 7 +- drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c | 4 +- drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c | 4 +- include/linux/cordic.h | 9 +- lib/cordic.c | 23 +--- 10 files changed, 35 insertions(+), 95 deletions(-) base-commit: ccda4af0f4b92f7b4c308d3acc262f4a7e3affad -- git-series 0.9.1
[PATCH v3 1/3] lib: cordic: Move cordic macros and defines to header file
Now that these macros are in header file, we can eventually
clean up the duplicate macros present in the drivers that
utilize the same cordic algorithm implementation.
Also add CORDIC_ prefix to nonprefixed macros.
Reviewed-by: Arend van Spriel
Signed-off-by: Priit Laes
---
include/linux/cordic.h | 9 +
lib/cordic.c | 23 +++
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/include/linux/cordic.h b/include/linux/cordic.h
index cf68ca4..3d656f5 100644
--- a/include/linux/cordic.h
+++ b/include/linux/cordic.h
@@ -18,6 +18,15 @@
#include
+#define CORDIC_ANGLE_GEN 39797
+#define CORDIC_PRECISION_SHIFT 16
+#define CORDIC_NUM_ITER(CORDIC_PRECISION_SHIFT + 2)
+
+#define CORDIC_FIXED(X)((s32)((X) << CORDIC_PRECISION_SHIFT))
+#define CORDIC_FLOAT(X)(((X) >= 0) \
+ ? X) >> (CORDIC_PRECISION_SHIFT - 1)) + 1) >> 1) \
+ : --(X)) >> (CORDIC_PRECISION_SHIFT - 1)) + 1) >> 1))
+
/**
* struct cordic_iq - i/q coordinate.
*
diff --git a/lib/cordic.c b/lib/cordic.c
index 6cf4778..8ef27c1 100644
--- a/lib/cordic.c
+++ b/lib/cordic.c
@@ -16,15 +16,6 @@
#include
#include
-#define CORDIC_ANGLE_GEN 39797
-#define CORDIC_PRECISION_SHIFT 16
-#defineCORDIC_NUM_ITER (CORDIC_PRECISION_SHIFT + 2)
-
-#defineFIXED(X)((s32)((X) << CORDIC_PRECISION_SHIFT))
-#defineFLOAT(X)(((X) >= 0) \
- ? X) >> (CORDIC_PRECISION_SHIFT - 1)) + 1) >> 1) \
- : --(X)) >> (CORDIC_PRECISION_SHIFT - 1)) + 1) >> 1))
-
static const s32 arctan_table[] = {
2949120,
1740967,
@@ -64,16 +55,16 @@ struct cordic_iq cordic_calc_iq(s32 theta)
coord.q = 0;
angle = 0;
- theta = FIXED(theta);
+ theta = CORDIC_FIXED(theta);
signtheta = (theta < 0) ? -1 : 1;
- theta = ((theta + FIXED(180) * signtheta) % FIXED(360)) -
- FIXED(180) * signtheta;
+ theta = ((theta + CORDIC_FIXED(180) * signtheta) % CORDIC_FIXED(360)) -
+ CORDIC_FIXED(180) * signtheta;
- if (FLOAT(theta) > 90) {
- theta -= FIXED(180);
+ if (CORDIC_FLOAT(theta) > 90) {
+ theta -= CORDIC_FIXED(180);
signx = -1;
- } else if (FLOAT(theta) < -90) {
- theta += FIXED(180);
+ } else if (CORDIC_FLOAT(theta) < -90) {
+ theta += CORDIC_FIXED(180);
signx = -1;
}
--
git-series 0.9.1
Re: [PATCH v3 3/6] mac80211: Add airtime accounting and scheduling to TXQs
Felix Fietkau writes:
> On 2018-11-12 23:51, Rajkumar Manoharan wrote:
>> From: Toke Høiland-Jørgensen
>>
>> This adds airtime accounting and scheduling to the mac80211 TXQ
>> scheduler. A new callback, ieee80211_sta_register_airtime(), is added
>> that drivers can call to report airtime usage for stations.
>>
>> When airtime information is present, mac80211 will schedule TXQs
>> (through ieee80211_next_txq()) in a way that enforces airtime fairness
>> between active stations. This scheduling works the same way as the ath9k
>> in-driver airtime fairness scheduling. If no airtime usage is reported
>> by the driver, the scheduler will default to round-robin scheduling.
>>
>> For drivers that don't control TXQ scheduling in software, a new API
>> function, ieee80211_txq_may_transmit(), is added which the driver can use
>> to check if the TXQ is eligible for transmission, or should be throttled to
>> enforce fairness. Calls to this function must also be enclosed in
>> ieee80211_txq_schedule_{start,end}() calls to ensure proper locking.
>>
>> The API ieee80211_txq_may_transmit() also ensures that TXQ list will be
>> aligned aginst driver's own round-robin scheduler list. i.e it rotates
>> the TXQ list till it makes the requested node becomes the first entry
>> in TXQ list. Thus both the TXQ list and driver's list are in sync.
>>
>> Co-Developed-by: Rajkumar Manoharan
>> Signed-off-by: Toke Høiland-Jørgensen
>> Signed-off-by: Rajkumar Manoharan
>> ---
>> include/net/mac80211.h | 59 ++
>> net/mac80211/cfg.c | 3 ++
>> net/mac80211/debugfs.c | 3 ++
>> net/mac80211/debugfs_sta.c | 50 --
>> net/mac80211/ieee80211_i.h | 2 ++
>> net/mac80211/main.c| 4 +++
>> net/mac80211/sta_info.c| 44 +--
>> net/mac80211/sta_info.h| 13 +++
>> net/mac80211/status.c | 6
>> net/mac80211/tx.c | 90
>> +++---
>> 10 files changed, 264 insertions(+), 10 deletions(-)
>>
>> diff --git a/net/mac80211/status.c b/net/mac80211/status.c
>> index aa4afbf0abaf..a1f1256448f5 100644
>> --- a/net/mac80211/status.c
>> +++ b/net/mac80211/status.c
>> @@ -818,6 +818,12 @@ static void __ieee80211_tx_status(struct ieee80211_hw
>> *hw,
>> ieee80211_sta_tx_notify(sta->sdata, (void *) skb->data,
>> acked, info->status.tx_time);
>>
>> +if (info->status.tx_time &&
>> +wiphy_ext_feature_isset(local->hw.wiphy,
>> +
>> NL80211_EXT_FEATURE_AIRTIME_FAIRNESS))
>> +ieee80211_sta_register_airtime(&sta->sta, tid,
>> + info->status.tx_time, 0);
>> +
>> if (ieee80211_hw_check(&local->hw, REPORTS_TX_ACK_STATUS)) {
>> if (info->flags & IEEE80211_TX_STAT_ACK) {
>> if (sta->status_stats.lost_packets)
> I think the same is needed in ieee80211_tx_status_ext.
Right, good point.
>> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
>> index 305965283506..3f417e80e041 100644
>> --- a/net/mac80211/tx.c
>> +++ b/net/mac80211/tx.c
>> @@ -3660,12 +3680,74 @@ void ieee80211_return_txq(struct ieee80211_hw *hw,
>> lockdep_assert_held(&local->active_txq_lock[txq->ac]);
>>
>> if (list_empty(&txqi->schedule_order) &&
>> -(!skb_queue_empty(&txqi->frags) || txqi->tin.backlog_packets))
>> -list_add_tail(&txqi->schedule_order,
>> - &local->active_txqs[txq->ac]);
>> +(!skb_queue_empty(&txqi->frags) || txqi->tin.backlog_packets)) {
>> +/* If airtime accounting is active, always enqueue STAs at the
>> + * head of the list to ensure that they only get moved to the
>> + * back by the airtime DRR scheduler once they have a negative
>> + * deficit. A station that already has a negative deficit will
>> + * get immediately moved to the back of the list on the next
>> + * call to ieee80211_next_txq().
>> + */
>> +if (txqi->txq.sta &&
>> +wiphy_ext_feature_isset(local->hw.wiphy,
>> +
>> NL80211_EXT_FEATURE_AIRTIME_FAIRNESS))
>> +list_add(&txqi->schedule_order,
>> + &local->active_txqs[txq->ac]);
>> +else
>> +list_add_tail(&txqi->schedule_order,
>> + &local->active_txqs[txq->ac]);
>> +}
>> }
> This part doesn't really make much sense to me, but maybe I'm
> misunderstanding how the code works.
> Let's assume we have a driver like ath9k or mt76, which tries to keep a
> number of aggregates in the hardware queue, and the hardware queue is
> currently empty.
> If the current txq entry is kept at the head of the schedule list,
Re: [PATCH v4 4/6] nfc: pn533: add UART phy driver
On Thu, Nov 01, 2018 at 11:02:12AM +0100, Lars Poeschel wrote:
> This adds the UART phy interface for the pn533 driver.
> The pn533 driver can be used through UART interface this way.
> It is implemented as a serdev device.
>
> Signed-off-by: Lars Poeschel
Please make sure to include reviewers on CC.
> ---
> Changes in v4:
> - SPDX-License-Identifier: GPL-2.0+
> - Source code comments above refering items
> - Error check for serdev_device_write's
> - Change if (xxx == NULL) to if (!xxx)
> - Remove device name from a dev_err
> - move pn533_register in _probe a bit towards the end of _probe
> - make use of newly added dev_up / dev_down phy_ops
> - control send_wakeup variable from dev_up / dev_down
>
> Changes in v3:
> - depend on SERIAL_DEV_BUS in Kconfig
>
> Changes in v2:
> - switched from tty line discipline to serdev, resulting in many
> simplifications
> - SPDX License Identifier
>
> drivers/nfc/pn533/Kconfig | 11 ++
> drivers/nfc/pn533/Makefile | 2 +
> drivers/nfc/pn533/pn533.h | 8 +
> drivers/nfc/pn533/uart.c | 311 +
> 4 files changed, 332 insertions(+)
> create mode 100644 drivers/nfc/pn533/uart.c
>
> +static void pn532_dev_up(struct pn533 *dev)
> +{
> + struct pn532_uart_phy *pn532 = dev->phy;
> +
> + serdev_device_open(pn532->serdev);
> + pn532->send_wakeup = PN532_SEND_LAST_WAKEUP;
> +}
> +
> +static void pn532_dev_down(struct pn533 *dev)
> +{
> + struct pn532_uart_phy *pn532 = dev->phy;
> +
> + serdev_device_close(pn532->serdev);
> + pn532->send_wakeup = PN532_SEND_WAKEUP;
> +}
> +
> +static struct pn533_phy_ops uart_phy_ops = {
> + .send_frame = pn532_uart_send_frame,
> + .send_ack = pn532_uart_send_ack,
> + .abort_cmd = pn532_uart_abort_cmd,
> + .dev_up = pn532_dev_up,
> + .dev_down = pn532_dev_down,
> +};
> +static int pn532_uart_probe(struct serdev_device *serdev)
> +{
> + struct pn532_uart_phy *pn532;
> + struct pn533 *priv;
> + int err;
> +
> + err = -ENOMEM;
> + pn532 = kzalloc(sizeof(*pn532), GFP_KERNEL);
> + if (!pn532)
> + goto err_exit;
> +
> + pn532->recv_skb = alloc_skb(PN532_UART_SKB_BUFF_LEN, GFP_KERNEL);
> + if (!pn532->recv_skb)
> + goto err_free;
> +
> + pn532->serdev = serdev;
> + serdev_device_set_drvdata(serdev, pn532);
> + serdev_device_set_client_ops(serdev, &pn532_serdev_ops);
> + err = serdev_device_open(serdev);
> + if (err) {
> + dev_err(&serdev->dev, "Unable to open device\n");
> + goto err_skb;
> + }
> +
> + err = serdev_device_set_baudrate(serdev, 115200);
> + if (err != 115200) {
> + err = -EINVAL;
> + goto err_serdev;
> + }
> +
> + serdev_device_set_flow_control(serdev, false);
> + pn532->send_wakeup = PN532_SEND_WAKEUP;
> + timer_setup(&pn532->cmd_timeout, pn532_cmd_timeout, 0);
> + priv = pn533_register_device(PN533_DEVICE_PN532,
> + PN533_NO_TYPE_B_PROTOCOLS,
> + PN533_PROTO_REQ_ACK_RESP,
> + pn532, &uart_phy_ops, NULL,
> + &pn532->serdev->dev,
> + &serdev->dev);
> + if (IS_ERR(priv)) {
> + err = PTR_ERR(priv);
> + goto err_serdev;
> + }
> +
> + pn532->priv = priv;
> + err = pn533_finalize_setup(pn532->priv);
> + if (err)
> + goto err_unregister;
> +
> + serdev_device_close(serdev);
This looks broken; what if the NFC interface is brought up before this
point? You'd get a double open, which is likely to crash things, but
even if you survive that, the port would not be closed despite the
interface being up.
Can't you finalise your setup before registering the interface?
> + return 0;
> +
> +err_unregister:
> + pn533_unregister_device(pn532->priv);
> +err_serdev:
> + serdev_device_close(serdev);
> +err_skb:
> + kfree_skb(pn532->recv_skb);
> +err_free:
> + kfree(pn532);
> +err_exit:
> + return err;
> +}
> +
> +static void pn532_uart_remove(struct serdev_device *serdev)
> +{
> + struct pn532_uart_phy *pn532 = serdev_device_get_drvdata(serdev);
> +
> + pn533_unregister_device(pn532->priv);
> + serdev_device_close(serdev);
This is also broken; the port should have been closed when the interface
was deregistered.
> + kfree_skb(pn532->recv_skb);
> + kfree(pn532);
> +}
Johan
iw dev twpoxer limit in mBm or not
hi. On ubuntu 18.10 using kernel 4.18.0-10-generic and iw-4.14 on a Broadcom Corp. BCM43142 wifi interface using wl driver, i run sudo iw dev wlp2s0 set txpower limit 21 and iw dev reports back a txpower of 21 dBm But the doc at https://wireless.wiki.kernel.org/en/users/documentation/iw#setting_tx_power and the output of `iw dev help` states that the txpower is to be expressed in mDm not dBm. So I am confused. Can I use suod iw dev wlp2s0 set txpower limit 2100 wihtout frying my card ? Moreover, how is that even possible given that I have set the regdom to FR and that max output power is supposed to be 20dBm in Europe ? Thanks
Re: AP6335 with mainline kernel
+ Cameron On 3/26/2018 3:34 PM, Vanessa Maegima wrote: On Seg, 2018-03-26 at 09:24 -0300, Vanessa Maegima wrote: Hi Arend, Here's the hexdump: http://code.bulix.org/trv3o7-306254 The link above provides the hexdump from the html nvram, which makes wifi work on pico-imx7d. I also got the hexdump of the nvram file provided by TechNexion for comparison, which returns the error "brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100): clkctl 0x50": http://code.bulix.org/mw4x62-3 09 095 Fixing second URL: http://code.bulix.org/mw4x62-309095 Hi Vanessa, It has been a while, but recently I was contacted by Cameron who was facing same/similar issue. After some email exchanges with him he uncovered that the problem with the TechNexion nvram file is with the boardflags3 entry. On my suggestion he change the value from 0x08101188 to 0x101188. The dropped bit forces the clock hierarchy in the chip to select external LPO. I found some schematics showing a 32kHz signal hooked up to the LPO input coming from GPIO1_IO03. Could it be that it is not properly setup? Devicetree maybe? Regards, Arend
Re: [PATCH] brcmfmac: Use standard SKB list accessors in brcmf_sdiod_sglist_rw.
On 11/14/2018 11:57 AM, Arend van Spriel wrote: On 11/14/2018 11:54 AM, Andy Duan wrote: From: Arend van Spriel [mailto:arend.vanspr...@broadcom.com] Sent: 2018年11月14日 16:40 To: Andy Duan ; David Miller ; net...@vger.kernel.org Cc: linux-wireless@vger.kernel.org Subject: Re: [PATCH] brcmfmac: Use standard SKB list accessors in brcmf_sdiod_sglist_rw. On 11/14/2018 4:28 AM, Andy Duan wrote: From: David Miller Sent: 2018年11月11日 8:34 [ As I am trying to remove direct SKB list pointer accesses I am committing this to net-next. If this causes a lot of grief I can and will revert, just let me know. ] [...] I just have bcm4339 in hands, test the patch on i.MX7D sdb board with bcm4339, it works fine with iperf testing. Tested-by: Fugang Duan Thanks, Andy Can you do one more check? Please insert brcmfmac with module parameter debug=2 and let me know if the following log message is seen: brcmfmac: brcmf_sdiod_sgtable_alloc: nents=X If not seen, the driver does not go through the patched code. My kernel don't enable debug and DEBUG and CONFIG_BRCM_TRACING, I add the debug info in the brcmf_sdiod_sgtable_alloc(), and the log show the driver go through the sg path: Log: brcmf_sdiod_sgtable_alloc: max_segs:128, sg_support:1, nents=35 Thanks, Andy Works for me ;-) I should better read the patch email. I tried to apply the patch to wireless-testing, but it failed simply because the patch is already in place through net-next as Dave mentioned. Anyway, it is good that it has been tested to some extent. Regards, Arend
Re: [PATCH v3 3/6] mac80211: Add airtime accounting and scheduling to TXQs
On 2018-11-12 23:51, Rajkumar Manoharan wrote:
> From: Toke Høiland-Jørgensen
>
> This adds airtime accounting and scheduling to the mac80211 TXQ
> scheduler. A new callback, ieee80211_sta_register_airtime(), is added
> that drivers can call to report airtime usage for stations.
>
> When airtime information is present, mac80211 will schedule TXQs
> (through ieee80211_next_txq()) in a way that enforces airtime fairness
> between active stations. This scheduling works the same way as the ath9k
> in-driver airtime fairness scheduling. If no airtime usage is reported
> by the driver, the scheduler will default to round-robin scheduling.
>
> For drivers that don't control TXQ scheduling in software, a new API
> function, ieee80211_txq_may_transmit(), is added which the driver can use
> to check if the TXQ is eligible for transmission, or should be throttled to
> enforce fairness. Calls to this function must also be enclosed in
> ieee80211_txq_schedule_{start,end}() calls to ensure proper locking.
>
> The API ieee80211_txq_may_transmit() also ensures that TXQ list will be
> aligned aginst driver's own round-robin scheduler list. i.e it rotates
> the TXQ list till it makes the requested node becomes the first entry
> in TXQ list. Thus both the TXQ list and driver's list are in sync.
>
> Co-Developed-by: Rajkumar Manoharan
> Signed-off-by: Toke Høiland-Jørgensen
> Signed-off-by: Rajkumar Manoharan
> ---
> include/net/mac80211.h | 59 ++
> net/mac80211/cfg.c | 3 ++
> net/mac80211/debugfs.c | 3 ++
> net/mac80211/debugfs_sta.c | 50 --
> net/mac80211/ieee80211_i.h | 2 ++
> net/mac80211/main.c| 4 +++
> net/mac80211/sta_info.c| 44 +--
> net/mac80211/sta_info.h| 13 +++
> net/mac80211/status.c | 6
> net/mac80211/tx.c | 90
> +++---
> 10 files changed, 264 insertions(+), 10 deletions(-)
>
> diff --git a/net/mac80211/status.c b/net/mac80211/status.c
> index aa4afbf0abaf..a1f1256448f5 100644
> --- a/net/mac80211/status.c
> +++ b/net/mac80211/status.c
> @@ -818,6 +818,12 @@ static void __ieee80211_tx_status(struct ieee80211_hw
> *hw,
> ieee80211_sta_tx_notify(sta->sdata, (void *) skb->data,
> acked, info->status.tx_time);
>
> + if (info->status.tx_time &&
> + wiphy_ext_feature_isset(local->hw.wiphy,
> +
> NL80211_EXT_FEATURE_AIRTIME_FAIRNESS))
> + ieee80211_sta_register_airtime(&sta->sta, tid,
> +info->status.tx_time, 0);
> +
> if (ieee80211_hw_check(&local->hw, REPORTS_TX_ACK_STATUS)) {
> if (info->flags & IEEE80211_TX_STAT_ACK) {
> if (sta->status_stats.lost_packets)
I think the same is needed in ieee80211_tx_status_ext.
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index 305965283506..3f417e80e041 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -3660,12 +3680,74 @@ void ieee80211_return_txq(struct ieee80211_hw *hw,
> lockdep_assert_held(&local->active_txq_lock[txq->ac]);
>
> if (list_empty(&txqi->schedule_order) &&
> - (!skb_queue_empty(&txqi->frags) || txqi->tin.backlog_packets))
> - list_add_tail(&txqi->schedule_order,
> - &local->active_txqs[txq->ac]);
> + (!skb_queue_empty(&txqi->frags) || txqi->tin.backlog_packets)) {
> + /* If airtime accounting is active, always enqueue STAs at the
> + * head of the list to ensure that they only get moved to the
> + * back by the airtime DRR scheduler once they have a negative
> + * deficit. A station that already has a negative deficit will
> + * get immediately moved to the back of the list on the next
> + * call to ieee80211_next_txq().
> + */
> + if (txqi->txq.sta &&
> + wiphy_ext_feature_isset(local->hw.wiphy,
> +
> NL80211_EXT_FEATURE_AIRTIME_FAIRNESS))
> + list_add(&txqi->schedule_order,
> + &local->active_txqs[txq->ac]);
> + else
> + list_add_tail(&txqi->schedule_order,
> + &local->active_txqs[txq->ac]);
> + }
> }
This part doesn't really make much sense to me, but maybe I'm
misunderstanding how the code works.
Let's assume we have a driver like ath9k or mt76, which tries to keep a
number of aggregates in the hardware queue, and the hardware queue is
currently empty.
If the current txq entry is kept at the head of the schedule list,
wouldn't the code just pull from that one over and over again, until
enough packets are transmitted by the hardware a
Re: [PATCH] brcmfmac: Use standard SKB list accessors in brcmf_sdiod_sglist_rw.
On 11/14/2018 11:54 AM, Andy Duan wrote: From: Arend van Spriel [mailto:arend.vanspr...@broadcom.com] Sent: 2018年11月14日 16:40 To: Andy Duan ; David Miller ; net...@vger.kernel.org Cc: linux-wireless@vger.kernel.org Subject: Re: [PATCH] brcmfmac: Use standard SKB list accessors in brcmf_sdiod_sglist_rw. On 11/14/2018 4:28 AM, Andy Duan wrote: From: David Miller Sent: 2018年11月11日 8:34 [ As I am trying to remove direct SKB list pointer accesses I am committing this to net-next. If this causes a lot of grief I can and will revert, just let me know. ] [...] I just have bcm4339 in hands, test the patch on i.MX7D sdb board with bcm4339, it works fine with iperf testing. Tested-by: Fugang Duan Thanks, Andy Can you do one more check? Please insert brcmfmac with module parameter debug=2 and let me know if the following log message is seen: brcmfmac: brcmf_sdiod_sgtable_alloc: nents=X If not seen, the driver does not go through the patched code. My kernel don't enable debug and DEBUG and CONFIG_BRCM_TRACING, I add the debug info in the brcmf_sdiod_sgtable_alloc(), and the log show the driver go through the sg path: Log: brcmf_sdiod_sgtable_alloc: max_segs:128, sg_support:1, nents=35 Thanks, Andy Works for me ;-) Regards, Arend
RE: [PATCH] brcmfmac: Use standard SKB list accessors in brcmf_sdiod_sglist_rw.
From: Arend van Spriel [mailto:arend.vanspr...@broadcom.com] Sent: 2018年11月14日 16:40 > To: Andy Duan ; David Miller > ; net...@vger.kernel.org > Cc: linux-wireless@vger.kernel.org > Subject: Re: [PATCH] brcmfmac: Use standard SKB list accessors in > brcmf_sdiod_sglist_rw. > > On 11/14/2018 4:28 AM, Andy Duan wrote: > > From: David Miller Sent: 2018年11月11日 8:34 > >> [ As I am trying to remove direct SKB list pointer accesses I am > >> committing this to net-next. If this causes a lot of grief I > >> can and will revert, just let me know. ] > > [...] > > > > > I just have bcm4339 in hands, test the patch on i.MX7D sdb board with > bcm4339, it works fine with iperf testing. > > > > Tested-by: Fugang Duan > > Thanks, Andy > > Can you do one more check? Please insert brcmfmac with module parameter > debug=2 and let me know if the following log message is seen: > > brcmfmac: brcmf_sdiod_sgtable_alloc: nents=X > > If not seen, the driver does not go through the patched code. My kernel don't enable debug and DEBUG and CONFIG_BRCM_TRACING, I add the debug info in the brcmf_sdiod_sgtable_alloc(), and the log show the driver go through the sg path: Log: brcmf_sdiod_sgtable_alloc: max_segs:128, sg_support:1, nents=35
intel 9000 wifi cards positive signed signal reading
Hi, I got some Intel 8000 and 9000 wifi cards here to test their roaming capabilities. I'm using debian testing (buster) with firmware-iwlwifi (20180825+dfsg-1), which includes iwlwifi-9000-pu-b0-jf-b0-38.ucode The 8000 series cards are working good, but all 9000 series cards give signal readings with a positive sign (like +58dBm). If I cover the antenna with my hand, it goes to +63dBm. So it seems as if it's just wrongly signed. From -58 to -63 would be perfectly plausible... I cannot use those 9000 cards, as they would never roam with signal always being 100%. Is this a known issue? Thanks, Lukas
Re: [PATCH] brcmfmac: Use standard SKB list accessors in brcmf_sdiod_sglist_rw.
On 11/14/2018 4:28 AM, Andy Duan wrote: From: David Miller Sent: 2018年11月11日 8:34 [ As I am trying to remove direct SKB list pointer accesses I am committing this to net-next. If this causes a lot of grief I can and will revert, just let me know. ] [...] I just have bcm4339 in hands, test the patch on i.MX7D sdb board with bcm4339, it works fine with iperf testing. Tested-by: Fugang Duan Thanks, Andy Can you do one more check? Please insert brcmfmac with module parameter debug=2 and let me know if the following log message is seen: brcmfmac: brcmf_sdiod_sgtable_alloc: nents=X If not seen, the driver does not go through the patched code. Regards, Arend
