* [PATCH 15/21] rt2x00: rt2800lib: hardcode txmixer gain values to zero for RT3883
From: Stanislaw Gruszka @ 2019-04-09 11:37 UTC (permalink / raw)
To: linux-wireless
Cc: Tomislav Požega, Daniel Golle, Felix Fietkau, Mathias Kresin,
Gabor Juhos, Stanislaw Gruszka
In-Reply-To: <1554809828-13500-1-git-send-email-sgruszka@redhat.com>
From: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 0687bef990e1..4ea94c62d439 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -9128,7 +9128,8 @@ static u8 rt2800_get_txmixer_gain_24g(struct rt2x00_dev *rt2x00dev)
{
u16 word;
- if (rt2x00_rt(rt2x00dev, RT3593))
+ if (rt2x00_rt(rt2x00dev, RT3593) ||
+ rt2x00_rt(rt2x00dev, RT3883))
return 0;
word = rt2800_eeprom_read(rt2x00dev, EEPROM_TXMIXER_GAIN_BG);
@@ -9142,7 +9143,8 @@ static u8 rt2800_get_txmixer_gain_5g(struct rt2x00_dev *rt2x00dev)
{
u16 word;
- if (rt2x00_rt(rt2x00dev, RT3593))
+ if (rt2x00_rt(rt2x00dev, RT3593) ||
+ rt2x00_rt(rt2x00dev, RT3883))
return 0;
word = rt2800_eeprom_read(rt2x00dev, EEPROM_TXMIXER_GAIN_A);
--
2.7.5
^ permalink raw reply related
* [PATCH 16/21] rt2x00: rt2800lib: use correct [RT]XWI size for RT3883
From: Stanislaw Gruszka @ 2019-04-09 11:37 UTC (permalink / raw)
To: linux-wireless
Cc: Tomislav Požega, Daniel Golle, Felix Fietkau, Mathias Kresin,
Gabor Juhos, Stanislaw Gruszka
In-Reply-To: <1554809828-13500-1-git-send-email-sgruszka@redhat.com>
From: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 4ea94c62d439..024befd07903 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -591,6 +591,7 @@ void rt2800_get_txwi_rxwi_size(struct rt2x00_dev *rt2x00dev,
{
switch (rt2x00dev->chip.rt) {
case RT3593:
+ case RT3883:
*txwi_size = TXWI_DESC_SIZE_4WORDS;
*rxwi_size = RXWI_DESC_SIZE_5WORDS;
break;
--
2.7.5
^ permalink raw reply related
* [PATCH 17/21] rt2x00: rt2800lib: fix antenna configuration for RT3883
From: Stanislaw Gruszka @ 2019-04-09 11:37 UTC (permalink / raw)
To: linux-wireless
Cc: Tomislav Požega, Daniel Golle, Felix Fietkau, Mathias Kresin,
Gabor Juhos, Stanislaw Gruszka
In-Reply-To: <1554809828-13500-1-git-send-email-sgruszka@redhat.com>
From: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 024befd07903..8fca5e26f36e 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -2174,7 +2174,8 @@ void rt2800_config_ant(struct rt2x00_dev *rt2x00dev, struct antenna_setup *ant)
rt2800_bbp_write(rt2x00dev, 3, r3);
rt2800_bbp_write(rt2x00dev, 1, r1);
- if (rt2x00_rt(rt2x00dev, RT3593)) {
+ if (rt2x00_rt(rt2x00dev, RT3593) ||
+ rt2x00_rt(rt2x00dev, RT3883)) {
if (ant->rx_chain_num == 1)
rt2800_bbp_write(rt2x00dev, 86, 0x00);
else
--
2.7.5
^ permalink raw reply related
* [PATCH 18/21] rt2x00: rt2800lib: fix LNA gain configuration for RT3883
From: Stanislaw Gruszka @ 2019-04-09 11:37 UTC (permalink / raw)
To: linux-wireless
Cc: Tomislav Požega, Daniel Golle, Felix Fietkau, Mathias Kresin,
Gabor Juhos, Stanislaw Gruszka
In-Reply-To: <1554809828-13500-1-git-send-email-sgruszka@redhat.com>
From: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 8fca5e26f36e..a3b5b51d7779 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -2197,7 +2197,8 @@ static void rt2800_config_lna_gain(struct rt2x00_dev *rt2x00dev,
eeprom = rt2800_eeprom_read(rt2x00dev, EEPROM_LNA);
lna_gain = rt2x00_get_field16(eeprom, EEPROM_LNA_A0);
} else if (libconf->rf.channel <= 128) {
- if (rt2x00_rt(rt2x00dev, RT3593)) {
+ if (rt2x00_rt(rt2x00dev, RT3593) ||
+ rt2x00_rt(rt2x00dev, RT3883)) {
eeprom = rt2800_eeprom_read(rt2x00dev, EEPROM_EXT_LNA2);
lna_gain = rt2x00_get_field16(eeprom,
EEPROM_EXT_LNA2_A1);
@@ -2207,7 +2208,8 @@ static void rt2800_config_lna_gain(struct rt2x00_dev *rt2x00dev,
EEPROM_RSSI_BG2_LNA_A1);
}
} else {
- if (rt2x00_rt(rt2x00dev, RT3593)) {
+ if (rt2x00_rt(rt2x00dev, RT3593) ||
+ rt2x00_rt(rt2x00dev, RT3883)) {
eeprom = rt2800_eeprom_read(rt2x00dev, EEPROM_EXT_LNA2);
lna_gain = rt2x00_get_field16(eeprom,
EEPROM_EXT_LNA2_A2);
--
2.7.5
^ permalink raw reply related
* [PATCH 19/21] rt2x00: rt2800lib: fix VGC setup for RT3883
From: Stanislaw Gruszka @ 2019-04-09 11:37 UTC (permalink / raw)
To: linux-wireless
Cc: Tomislav Požega, Daniel Golle, Felix Fietkau, Mathias Kresin,
Gabor Juhos, Stanislaw Gruszka
In-Reply-To: <1554809828-13500-1-git-send-email-sgruszka@redhat.com>
From: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index a3b5b51d7779..b0701aba50de 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -5526,7 +5526,8 @@ static u8 rt2800_get_default_vgc(struct rt2x00_dev *rt2x00dev)
else
vgc = 0x2e + rt2x00dev->lna_gain;
} else { /* 5GHZ band */
- if (rt2x00_rt(rt2x00dev, RT3593))
+ if (rt2x00_rt(rt2x00dev, RT3593) ||
+ rt2x00_rt(rt2x00dev, RT3883))
vgc = 0x20 + (rt2x00dev->lna_gain * 5) / 3;
else if (rt2x00_rt(rt2x00dev, RT5592))
vgc = 0x24 + (2 * rt2x00dev->lna_gain);
@@ -5546,7 +5547,8 @@ static inline void rt2800_set_vgc(struct rt2x00_dev *rt2x00dev,
{
if (qual->vgc_level != vgc_level) {
if (rt2x00_rt(rt2x00dev, RT3572) ||
- rt2x00_rt(rt2x00dev, RT3593)) {
+ rt2x00_rt(rt2x00dev, RT3593) ||
+ rt2x00_rt(rt2x00dev, RT3883)) {
rt2800_bbp_write_with_rx_chain(rt2x00dev, 66,
vgc_level);
} else if (rt2x00_rt(rt2x00dev, RT5592)) {
@@ -5593,6 +5595,11 @@ void rt2800_link_tuner(struct rt2x00_dev *rt2x00dev, struct link_qual *qual,
}
break;
+ case RT3883:
+ if (qual->rssi > -65)
+ vgc += 0x10;
+ break;
+
case RT5592:
if (qual->rssi > -65)
vgc += 0x20;
--
2.7.5
^ permalink raw reply related
* [PATCH 20/21] rt2x00: rt2800lib: fix EEPROM LNA validation for RT3883
From: Stanislaw Gruszka @ 2019-04-09 11:37 UTC (permalink / raw)
To: linux-wireless
Cc: Tomislav Požega, Daniel Golle, Felix Fietkau, Mathias Kresin,
Gabor Juhos, Stanislaw Gruszka
In-Reply-To: <1554809828-13500-1-git-send-email-sgruszka@redhat.com>
From: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index b0701aba50de..a401fd60f9a6 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -9261,7 +9261,8 @@ static int rt2800_validate_eeprom(struct rt2x00_dev *rt2x00dev)
word = rt2800_eeprom_read(rt2x00dev, EEPROM_RSSI_BG2);
if (abs(rt2x00_get_field16(word, EEPROM_RSSI_BG2_OFFSET2)) > 10)
rt2x00_set_field16(&word, EEPROM_RSSI_BG2_OFFSET2, 0);
- if (!rt2x00_rt(rt2x00dev, RT3593)) {
+ if (!rt2x00_rt(rt2x00dev, RT3593) &&
+ !rt2x00_rt(rt2x00dev, RT3883)) {
if (rt2x00_get_field16(word, EEPROM_RSSI_BG2_LNA_A1) == 0x00 ||
rt2x00_get_field16(word, EEPROM_RSSI_BG2_LNA_A1) == 0xff)
rt2x00_set_field16(&word, EEPROM_RSSI_BG2_LNA_A1,
@@ -9281,7 +9282,8 @@ static int rt2800_validate_eeprom(struct rt2x00_dev *rt2x00dev)
word = rt2800_eeprom_read(rt2x00dev, EEPROM_RSSI_A2);
if (abs(rt2x00_get_field16(word, EEPROM_RSSI_A2_OFFSET2)) > 10)
rt2x00_set_field16(&word, EEPROM_RSSI_A2_OFFSET2, 0);
- if (!rt2x00_rt(rt2x00dev, RT3593)) {
+ if (!rt2x00_rt(rt2x00dev, RT3593) &&
+ !rt2x00_rt(rt2x00dev, RT3883)) {
if (rt2x00_get_field16(word, EEPROM_RSSI_A2_LNA_A2) == 0x00 ||
rt2x00_get_field16(word, EEPROM_RSSI_A2_LNA_A2) == 0xff)
rt2x00_set_field16(&word, EEPROM_RSSI_A2_LNA_A2,
@@ -9289,7 +9291,8 @@ static int rt2800_validate_eeprom(struct rt2x00_dev *rt2x00dev)
}
rt2800_eeprom_write(rt2x00dev, EEPROM_RSSI_A2, word);
- if (rt2x00_rt(rt2x00dev, RT3593)) {
+ if (rt2x00_rt(rt2x00dev, RT3593) ||
+ rt2x00_rt(rt2x00dev, RT3883)) {
word = rt2800_eeprom_read(rt2x00dev, EEPROM_EXT_LNA2);
if (rt2x00_get_field16(word, EEPROM_EXT_LNA2_A1) == 0x00 ||
rt2x00_get_field16(word, EEPROM_EXT_LNA2_A1) == 0xff)
--
2.7.5
^ permalink raw reply related
* [PATCH 21/21] rt2x00: rt2800lib: fix txpower compensation for RT3883
From: Stanislaw Gruszka @ 2019-04-09 11:37 UTC (permalink / raw)
To: linux-wireless
Cc: Tomislav Požega, Daniel Golle, Felix Fietkau, Mathias Kresin,
Gabor Juhos, Stanislaw Gruszka
In-Reply-To: <1554809828-13500-1-git-send-email-sgruszka@redhat.com>
From: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index a401fd60f9a6..0e8e96075554 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -4516,6 +4516,9 @@ static u8 rt2800_compensate_txpower(struct rt2x00_dev *rt2x00dev, int is_rate_b,
if (rt2x00_rt(rt2x00dev, RT3593))
return min_t(u8, txpower, 0xc);
+ if (rt2x00_rt(rt2x00dev, RT3883))
+ return min_t(u8, txpower, 0xf);
+
if (rt2x00_has_cap_power_limit(rt2x00dev)) {
/*
* Check if eirp txpower exceed txpower_limit.
--
2.7.5
^ permalink raw reply related
* Re: [PATCH] brcmfmac: fix leak of mypkt on error return path
From: Arend Van Spriel @ 2019-04-09 11:40 UTC (permalink / raw)
To: Colin King, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, David S . Miller, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, netdev
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20190409112011.19546-1-colin.king@canonical.com>
On 4/9/2019 1:20 PM, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Currently if the call to brcmf_sdiod_set_backplane_window fails then
> then error return path leaks mypkt. Fix this by returning by a new
> error path labelled 'out' that calls brcmu_pkt_buf_free_skb to free
> mypkt.
>
> Addresses-Coverity: ("Resource Leak")
> Fixes: a7c3aa1509e2 ("brcmfmac: Remove brcmf_sdiod_addrprep()")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> index ec129864cc9c..f3d11e024e71 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> @@ -628,7 +628,7 @@ int brcmf_sdiod_send_buf(struct brcmf_sdio_dev *sdiodev, u8 *buf, uint nbytes)
>
> err = brcmf_sdiod_set_backplane_window(sdiodev, addr);
> if (err)
> - return err;
> + goto out;
Actually seems you can just get rid of the if statement entirely as
below it skips brcmf_sdiod_skbuff_write() when an error occurred so no
label is necessary.
Regards,
Arend
> addr &= SBSDIO_SB_OFT_ADDR_MASK;
> addr |= SBSDIO_SB_ACCESS_2_4B_FLAG;
> @@ -636,7 +636,7 @@ int brcmf_sdiod_send_buf(struct brcmf_sdio_dev *sdiodev, u8 *buf, uint nbytes)
> if (!err)
> err = brcmf_sdiod_skbuff_write(sdiodev, sdiodev->func2, addr,
> mypkt);
> -
> +out:
> brcmu_pkt_buf_free_skb(mypkt);
>
> return err;
>
^ permalink raw reply
* [PATCH][V2] brcmfmac: fix leak of mypkt on error return path
From: Colin King @ 2019-04-09 11:43 UTC (permalink / raw)
To: Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, David S . Miller, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Currently if the call to brcmf_sdiod_set_backplane_window fails then
then error return path leaks mypkt. Fix this by returning by a new
error path labelled 'out' that calls brcmu_pkt_buf_free_skb to free
mypkt. Also remove redundant check on err before calling
brcmf_sdiod_skbuff_write.
Addresses-Coverity: ("Resource Leak")
Fixes: a7c3aa1509e2 ("brcmfmac: Remove brcmf_sdiod_addrprep()")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
V2: Remove redundant check on err before calling
brcmf_sdiod_skbuff_write, kudos to Dan Carpenter and Arend Van Spriel
for spotting this.
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index ec129864cc9c..60aede5abb4d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -628,15 +628,13 @@ int brcmf_sdiod_send_buf(struct brcmf_sdio_dev *sdiodev, u8 *buf, uint nbytes)
err = brcmf_sdiod_set_backplane_window(sdiodev, addr);
if (err)
- return err;
+ goto out;
addr &= SBSDIO_SB_OFT_ADDR_MASK;
addr |= SBSDIO_SB_ACCESS_2_4B_FLAG;
- if (!err)
- err = brcmf_sdiod_skbuff_write(sdiodev, sdiodev->func2, addr,
- mypkt);
-
+ err = brcmf_sdiod_skbuff_write(sdiodev, sdiodev->func2, addr, mypkt);
+out:
brcmu_pkt_buf_free_skb(mypkt);
return err;
--
2.20.1
^ permalink raw reply related
* pull-request: mac80211 2019-04-09
From: Johannes Berg @ 2019-04-09 11:45 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
Here's a set of fixes for the current cycle. Mostly all over,
but some focus from Felix on the mac80211 internal TXQs.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 9a5a90d167b0e5fe3d47af16b68fd09ce64085cd:
net: core: netif_receive_skb_list: unlist skb before passing to pt->func (2019-03-28 17:28:05 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2019-04-09
for you to fetch changes up to 78ad2341521d5ea96cb936244ed4c4c4ef9ec13b:
mac80211: Honor SW_CRYPTO_CONTROL for unicast keys in AP VLAN mode (2019-04-09 13:40:32 +0200)
----------------------------------------------------------------
Various fixes:
* iTXQ fixes from Felix
* tracing fix - increase message length
* fix SW_CRYPTO_CONTROL enforcement
* WMM rule handling for regdomain intersection
* max_interfaces in hwsim - reported by syzbot
* clear private data in some more commands
* a clang compiler warning fix
I added a patch with two new (unused) macros for
rate-limited printing to simplify getting the users
into the tree.
----------------------------------------------------------------
Alexander Wetzel (1):
mac80211: Honor SW_CRYPTO_CONTROL for unicast keys in AP VLAN mode
Andrei Otcheretianski (1):
mac80211: Increase MAX_MSG_LEN
Felix Fietkau (6):
mac80211: un-schedule TXQs on powersave start
mac80211: fix unaligned access in mesh table hash function
mac80211: fix memory accounting with A-MSDU aggregation
mac80211: do not call driver wake_tx_queue op during reconfig
mac80211: rework locking for txq scheduling / airtime fairness
mac80211: make ieee80211_schedule_txq schedule empty TXQs
Ilan Peer (1):
cfg80211: Handle WMM rules in regulatory domain intersection
Johannes Berg (1):
mac80211_hwsim: calculate if_combination.max_interfaces
Nathan Chancellor (1):
cfg80211: Change an 'else if' into an 'else' in cfg80211_calculate_bitrate_he
Stanislaw Gruszka (1):
cfg80211: add ratelimited variants of err and warn
Sunil Dutt (1):
nl80211: Add NL80211_FLAG_CLEAR_SKB flag for other NL commands
YueHaibing (1):
cfg80211: Use kmemdup in cfg80211_gen_new_ie()
drivers/net/wireless/ath/ath10k/htt_rx.c | 2 +-
drivers/net/wireless/ath/ath10k/mac.c | 4 +-
drivers/net/wireless/ath/ath9k/xmit.c | 5 ++-
drivers/net/wireless/mac80211_hwsim.c | 19 ++++++++--
include/net/cfg80211.h | 5 +++
include/net/mac80211.h | 63 +++++++++++++++++---------------
net/mac80211/driver-ops.h | 3 ++
net/mac80211/key.c | 9 ++---
net/mac80211/mesh_pathtbl.c | 2 +-
net/mac80211/rx.c | 10 ++++-
net/mac80211/trace_msg.h | 7 +++-
net/mac80211/tx.c | 53 ++++++++++++---------------
net/wireless/nl80211.c | 18 ++++++---
net/wireless/reg.c | 39 ++++++++++++++++++++
net/wireless/scan.c | 3 +-
net/wireless/util.c | 6 ++-
16 files changed, 163 insertions(+), 85 deletions(-)
^ permalink raw reply
* Re: [linux-sunxi] [PATCH v2 02/13] arm64: dts: allwinner: h6: Add Orange Pi 3 DTS
From: Maxime Ripard @ 2019-04-09 11:47 UTC (permalink / raw)
To: Jagan Teki, linux-sunxi, Chen-Yu Tsai, Rob Herring, Linus Walleij,
David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, Naveen Gupta, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190409113157.e4vrzesbgmyslomb@core.my.home>
[-- Attachment #1: Type: text/plain, Size: 3449 bytes --]
On Tue, Apr 09, 2019 at 01:31:57PM +0200, Ondřej Jirman wrote:
> Hi Jagan,
>
> On Tue, Apr 09, 2019 at 02:08:18PM +0530, Jagan Teki wrote:
> > Based on the conversation about using common dtsi from this thread[1],
> > I'm commenting here to make show the diff directly on the nodes,
> > giving comments on each node so-that we can see the diff globally.
>
> Thanks for the suggestions below. It mostly repeats the differences and
> commonalities I already stated in the previous discussion.
>
> I don't have much to add to what I already said previously, though, because you
> didn't address my concerns there. But I can restate and expand on those
> concerns.
>
> Previously I already agreed it's possible to base orangepi-3.dts on
> orangepi.dtsi, and proposed a maintainable way forward, and why to follow it (to
> quote myself):
>
> Schematics allow for high amount of variability in the power tree (see all the
> NC (not connected) / 0R resistors) in the schematic around AXP805. Every board
> based on this Xunlong design can be subtly different.
>
> I already suggested a maintainable solution, below. Where base dtsi has empty
> config for regulators and every board based on that just defines it completely
> for itself.
>
> A few regulators (for CPU/GPU) will most probably have the same meaning on
> every derived board, so these can probably be kept in dtsi without causing too
> much annoyance.
>
> It's unpleasant to have wrong regulator setup defined in an underlying dtsi,
> and then trying to override it by removing/adding random properties in the
> board dts for the new boards based on that, so that it fits.
>
> The rest of the current HW descriptions in the sun50i-h6-orangepi.dtsi can be
> shared (as of now).
>
> My suggestion was this:
>
> So to base Orange Pi 3 dts on top of existing sun50i-h6-orangepi.dtsi I'd have
> to first move some things out of the base dtsi to the OrangePi Lite2 and One
> Plus board dts files, in order to have sun50i-h6-orangepi.dtsi only describe
> HW that is *really* shared by these 2 boards and Orange Pi 3.
>
> If I do that, I'd undefine all the axp805 regulator nodes and move the
> configurations to each of the 3 board files. That will probably end up being
> the least confusing and most maintainable. See axp81x.dtsi lines 86-144 for
> what I mean.
>
> You seem to be suggesting a solution where every time we add an OrangePi H6
> based board, the person adding it will have to go through the base dtsi and all
> the other boards based on it, status disable or otherwise change regulators in
> the base dtsi, patch all the other boards to re-enable it.
>
> It would be already unpleasant just adding a third board based on this approach.
> And when the fourth board is added, with another small differences in the
> regulator use/meanings, the person will be looking at patching 4 dts files
> + adding one for his own board. For what benefit, to save some bytes right now?
>
> I think maintainability, ease of adding new boards is more important, than
> having a dtsi that tries to maximally cover all the commonalities between the
> existing boards right now, without regards for the future. That's why
> I suggested an approach like in axp81x.dtsi lines 86-144.
I agree.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH][V2] brcmfmac: fix leak of mypkt on error return path
From: Arend Van Spriel @ 2019-04-09 11:50 UTC (permalink / raw)
To: Colin King, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, David S . Miller, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, netdev
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20190409114333.24342-1-colin.king@canonical.com>
On 4/9/2019 1:43 PM, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Currently if the call to brcmf_sdiod_set_backplane_window fails then
> then error return path leaks mypkt. Fix this by returning by a new
> error path labelled 'out' that calls brcmu_pkt_buf_free_skb to free
> mypkt. Also remove redundant check on err before calling
> brcmf_sdiod_skbuff_write.
>
> Addresses-Coverity: ("Resource Leak")
> Fixes: a7c3aa1509e2 ("brcmfmac: Remove brcmf_sdiod_addrprep()")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
>
> V2: Remove redundant check on err before calling
> brcmf_sdiod_skbuff_write, kudos to Dan Carpenter and Arend Van Spriel
> for spotting this.
>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> index ec129864cc9c..60aede5abb4d 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> @@ -628,15 +628,13 @@ int brcmf_sdiod_send_buf(struct brcmf_sdio_dev *sdiodev, u8 *buf, uint nbytes)
>
> err = brcmf_sdiod_set_backplane_window(sdiodev, addr);
> if (err)
> - return err;
> + goto out;
>
> addr &= SBSDIO_SB_OFT_ADDR_MASK;
> addr |= SBSDIO_SB_ACCESS_2_4B_FLAG;
>
> - if (!err)
> - err = brcmf_sdiod_skbuff_write(sdiodev, sdiodev->func2, addr,
> - mypkt);
> -
> + err = brcmf_sdiod_skbuff_write(sdiodev, sdiodev->func2, addr, mypkt);
> +out:
I am fine with it, but my suggestion was a bit different:
err = brcmf_sdiod_set_backplane_window(sdiodev, addr);
if (!err) {
addr &= SBSDIO_SB_OFT_ADDR_MASK;
addr |= SBSDIO_SB_ACCESS_2_4B_FLAG;
err = brcmf_sdiod_skbuff_write(sdiodev, sdiodev->func2,
addr, mypkt);
}
> brcmu_pkt_buf_free_skb(mypkt);
>
> return err;
>
^ permalink raw reply
* Re: [PATCH][V2] brcmfmac: fix leak of mypkt on error return path
From: Dan Carpenter @ 2019-04-09 11:55 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Colin King, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, David S . Miller, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, netdev,
kernel-janitors, linux-kernel
In-Reply-To: <e0d984a7-6a6d-b902-6f75-26ee6f530efe@broadcom.com>
On Tue, Apr 09, 2019 at 01:50:38PM +0200, Arend Van Spriel wrote:
> On 4/9/2019 1:43 PM, Colin King wrote:
> > From: Colin Ian King <colin.king@canonical.com>
> >
> > Currently if the call to brcmf_sdiod_set_backplane_window fails then
> > then error return path leaks mypkt. Fix this by returning by a new
> > error path labelled 'out' that calls brcmu_pkt_buf_free_skb to free
> > mypkt. Also remove redundant check on err before calling
> > brcmf_sdiod_skbuff_write.
> >
> > Addresses-Coverity: ("Resource Leak")
> > Fixes: a7c3aa1509e2 ("brcmfmac: Remove brcmf_sdiod_addrprep()")
> > Signed-off-by: Colin Ian King <colin.king@canonical.com>
> > ---
> >
> > V2: Remove redundant check on err before calling
> > brcmf_sdiod_skbuff_write, kudos to Dan Carpenter and Arend Van Spriel
> > for spotting this.
> >
> > ---
> > drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 8 +++-----
> > 1 file changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> > index ec129864cc9c..60aede5abb4d 100644
> > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> > @@ -628,15 +628,13 @@ int brcmf_sdiod_send_buf(struct brcmf_sdio_dev *sdiodev, u8 *buf, uint nbytes)
> > err = brcmf_sdiod_set_backplane_window(sdiodev, addr);
> > if (err)
> > - return err;
> > + goto out;
> > addr &= SBSDIO_SB_OFT_ADDR_MASK;
> > addr |= SBSDIO_SB_ACCESS_2_4B_FLAG;
> > - if (!err)
> > - err = brcmf_sdiod_skbuff_write(sdiodev, sdiodev->func2, addr,
> > - mypkt);
> > -
> > + err = brcmf_sdiod_skbuff_write(sdiodev, sdiodev->func2, addr, mypkt);
> > +out:
>
> I am fine with it, but my suggestion was a bit different:
>
> err = brcmf_sdiod_set_backplane_window(sdiodev, addr);
> if (!err) {
> addr &= SBSDIO_SB_OFT_ADDR_MASK;
> addr |= SBSDIO_SB_ACCESS_2_4B_FLAG;
> err = brcmf_sdiod_skbuff_write(sdiodev, sdiodev->func2,
> addr, mypkt);
> }
Success handling always leads to extra indenting like this... It's
less confusing to do failure handling keep the normal/success path at
indent level 1.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v2 02/13] arm64: dts: allwinner: h6: Add Orange Pi 3 DTS
From: Maxime Ripard @ 2019-04-09 11:59 UTC (permalink / raw)
To: linux-sunxi, Chen-Yu Tsai, Rob Herring, Linus Walleij,
David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, Naveen Gupta, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190409093304.sutpobe5azncyl5r@core.my.home>
[-- Attachment #1: Type: text/plain, Size: 928 bytes --]
On Tue, Apr 09, 2019 at 11:33:04AM +0200, Ondřej Jirman wrote:
> On Tue, Apr 09, 2019 at 10:12:30AM +0200, Maxime Ripard wrote:
> > Hi,
> >
> > On Tue, Apr 09, 2019 at 02:24:41AM +0200, megous@megous.com wrote:
> > > +&mmc0 {
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&mmc0_pins>;
> >
> > Since 5 minutes ago, that's now the default.
>
> Ah. :)
>
> > > +&usb2otg {
> > > + /*
> > > + * Beware that this board will not automatically disconnect
> > > + * VBUS from DCIN, when self-powered and used as a peripheral.
> > > + */
> > > + dr_mode = "otg";
> > > + status = "okay";
> > > +};
> >
> > As we were discussing, I guess leaving it as host is the safest
> > option.
> >
> > I can fix both issues while applying if that's ok for you.
>
> It's ok with me. Thank you.
Done, thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/3] wireless: Add support to probe unexercised mesh link
From: Johannes Berg @ 2019-04-09 12:02 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: linux-wireless
In-Reply-To: <1554318884-22450-1-git-send-email-rmanohar@codeaurora.org>
On Wed, 2019-04-03 at 12:14 -0700, Rajkumar Manoharan wrote:
> Consider below mesh topology.
>
> MP1
> / \
> / \
> MP2 --- MP3
>
> Assume that even though MP1 & MP3 have direct mesh links, the path was
> established via MP2. (MP1 <-> MP2 <-> MP3). The 1-hop mesh link MP1 <-> MP3
> never be excercised till the current path is terminated. As of now, there
> is no option to send data frame to pick other than primary path. So mesh
> link metric between MP1 & MP3 never be updated. This series allows user
> to send data to 1-hop mesh peers through unexercised mesh path.
>
> -Rajkumar
>
> v3: Rebased the changes on TOT
Hmm. Please rebase again, and retest, because I just applied this and it
doesn't even compile ...
johannes
^ permalink raw reply
* [PATCH] mac80211: fix RX STBC override byte order
From: Johannes Berg @ 2019-04-09 12:08 UTC (permalink / raw)
To: linux-wireless; +Cc: Sergey Matyukevich, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
The original patch neglected to take byte order conversions
into account, fix that.
Fixes: d9bb410888ce ("mac80211: allow overriding HT STBC capabilities")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/ht.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/ht.c b/net/mac80211/ht.c
index e03c46ac8e4d..f0735413bff3 100644
--- a/net/mac80211/ht.c
+++ b/net/mac80211/ht.c
@@ -112,8 +112,9 @@ void ieee80211_apply_htcap_overrides(struct ieee80211_sub_if_data *sdata,
IEEE80211_HT_CAP_TX_STBC);
/* Allow user to configure RX STBC bits */
- if (ht_capa_mask->cap_info & IEEE80211_HT_CAP_RX_STBC)
- ht_cap->cap |= ht_capa->cap_info & IEEE80211_HT_CAP_RX_STBC;
+ if (ht_capa_mask->cap_info & cpu_to_le16(IEEE80211_HT_CAP_RX_STBC))
+ ht_cap->cap |= ht_capa->cap_info &
+ cpu_to_le16(IEEE80211_HT_CAP_RX_STBC);
/* Allow user to decrease AMPDU factor */
if (ht_capa_mask->ampdu_params_info &
--
2.17.2
^ permalink raw reply related
* [PATCH v2] mac80211: fix RX STBC override byte order
From: Johannes Berg @ 2019-04-09 12:11 UTC (permalink / raw)
To: linux-wireless; +Cc: Sergey Matyukevich, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
The original patch neglected to take byte order conversions
into account, fix that.
Fixes: d9bb410888ce ("mac80211: allow overriding HT STBC capabilities")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/ht.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/ht.c b/net/mac80211/ht.c
index e03c46ac8e4d..c62101857b9b 100644
--- a/net/mac80211/ht.c
+++ b/net/mac80211/ht.c
@@ -112,8 +112,9 @@ void ieee80211_apply_htcap_overrides(struct ieee80211_sub_if_data *sdata,
IEEE80211_HT_CAP_TX_STBC);
/* Allow user to configure RX STBC bits */
- if (ht_capa_mask->cap_info & IEEE80211_HT_CAP_RX_STBC)
- ht_cap->cap |= ht_capa->cap_info & IEEE80211_HT_CAP_RX_STBC;
+ if (ht_capa_mask->cap_info & cpu_to_le16(IEEE80211_HT_CAP_RX_STBC))
+ ht_cap->cap |= le16_to_cpu(ht_capa->cap_info) &
+ IEEE80211_HT_CAP_RX_STBC;
/* Allow user to decrease AMPDU factor */
if (ht_capa_mask->ampdu_params_info &
--
2.17.2
^ permalink raw reply related
* Re: [RFC/RFT] mac80211: Switch to a virtual time-based airtime scheduler
From: Yibo Zhao @ 2019-04-09 13:25 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: make-wifi-fast, linux-wireless, Felix Fietkau, Rajkumar Manoharan,
Kan Yan, linux-wireless-owner
In-Reply-To: <87ftqy41ea.fsf@toke.dk>
On 2019-04-04 16:31, Toke Høiland-Jørgensen wrote:
> Yibo Zhao <yiboz@codeaurora.org> writes:
>
>> On 2019-02-16 01:05, Toke Høiland-Jørgensen wrote:
>>> This switches the airtime scheduler in mac80211 to use a virtual
>>> time-based
>>> scheduler instead of the round-robin scheduler used before. This has
>>> a
>>> couple of advantages:
>>>
>>> - No need to sync up the round-robin scheduler in firmware/hardware
>>> with
>>> the round-robin airtime scheduler.
>>>
>>> - If several stations are eligible for transmission we can schedule
>>> both of
>>> them; no need to hard-block the scheduling rotation until the head
>>> of
>>> the
>>> queue has used up its quantum.
>>>
>>> - The check of whether a station is eligible for transmission becomes
>>> simpler (in ieee80211_txq_may_transmit()).
>>>
>>> The drawback is that scheduling becomes slightly more expensive, as
>>> we
>>> need
>>> to maintain an rbtree of TXQs sorted by virtual time. This means that
>>> ieee80211_register_airtime() becomes O(logN) in the number of
>>> currently
>>> scheduled TXQs. However, hopefully this number rarely grows too big
>>> (it's
>>> only TXQs currently backlogged, not all associated stations), so it
>>> shouldn't be too big of an issue.
>>>
>>> @@ -1831,18 +1830,32 @@ void ieee80211_sta_register_airtime(struct
>>> ieee80211_sta *pubsta, u8 tid,
>>> {
>>> struct sta_info *sta = container_of(pubsta, struct sta_info, sta);
>>> struct ieee80211_local *local = sta->sdata->local;
>>> + struct ieee80211_txq *txq = sta->sta.txq[tid];
>>> u8 ac = ieee80211_ac_from_tid(tid);
>>> - u32 airtime = 0;
>>> + u64 airtime = 0, weight_sum;
>>> +
>>> + if (!txq)
>>> + return;
>>>
>>> if (sta->local->airtime_flags & AIRTIME_USE_TX)
>>> airtime += tx_airtime;
>>> if (sta->local->airtime_flags & AIRTIME_USE_RX)
>>> airtime += rx_airtime;
>>>
>>> + /* Weights scale so the unit weight is 256 */
>>> + airtime <<= 8;
>>> +
>>> spin_lock_bh(&local->active_txq_lock[ac]);
>>> +
>>> sta->airtime[ac].tx_airtime += tx_airtime;
>>> sta->airtime[ac].rx_airtime += rx_airtime;
>>> - sta->airtime[ac].deficit -= airtime;
>>> +
>>> + weight_sum = local->airtime_weight_sum[ac] ?: sta->airtime_weight;
>>> +
>>> + local->airtime_v_t[ac] += airtime / weight_sum;
>> Hi Toke,
>>
>> Please ignore the previous two broken emails regarding this new
>> proposal
>> from me.
>>
>> It looks like local->airtime_v_t acts like a Tx criteria. Only the
>> stations with less airtime than that are valid for Tx. That means
>> there
>> are situations, like 50 clients, that some of the stations can be used
>> to Tx when putting next_txq in the loop. Am I right?
>
> I'm not sure what you mean here. Are you referring to the case where
> new
> stations appear with a very low (zero) airtime_v_t? That is handled
> when
> the station is enqueued.
Hi Toke,
Sorry for the confusion. I am not referring to the case that you
mentioned though it can be solved by your subtle design, max(local vt,
sta vt). :-)
Actually, my concern is situation about putting next_txq in the loop.
Let me explain a little more and see below.
> @@ -3640,126 +3638,191 @@ EXPORT_SYMBOL(ieee80211_tx_dequeue);
> struct ieee80211_txq *ieee80211_next_txq(struct ieee80211_hw *hw, u8
> ac)
> {
> struct ieee80211_local *local = hw_to_local(hw);
> + struct rb_node *node = local->schedule_pos[ac];
> struct txq_info *txqi = NULL;
> + bool first = false;
>
> lockdep_assert_held(&local->active_txq_lock[ac]);
>
> - begin:
> - txqi = list_first_entry_or_null(&local->active_txqs[ac],
> - struct txq_info,
> - schedule_order);
> - if (!txqi)
> + if (!node) {
> + node = rb_first_cached(&local->active_txqs[ac]);
> + first = true;
> + } else
> + node = rb_next(node);
Consider below piece of code from ath10k_mac_schedule_txq:
ieee80211_txq_schedule_start(hw, ac);
while ((txq = ieee80211_next_txq(hw, ac))) {
while (ath10k_mac_tx_can_push(hw, txq)) {
ret = ath10k_mac_tx_push_txq(hw, txq);
if (ret < 0)
break;
}
ieee80211_return_txq(hw, txq);
ath10k_htt_tx_txq_update(hw, txq);
if (ret == -EBUSY)
break;
}
ieee80211_txq_schedule_end(hw, ac);
If my understanding is right, local->schedule_pos is used to record the
last scheduled node and used for traversal rbtree for valid txq. There
is chance that an empty txq is feeded to return_txq and got removed from
rbtree. The empty txq will always be the rb_first node. Then in the
following next_txq, local->schedule_pos becomes meaningless since its
rb_next will return NULL and the loop break. Only rb_first get dequeued
during this loop.
if (!node || RB_EMPTY_NODE(node)) {
node = rb_first_cached(&local->active_txqs[ac]);
first = true;
} else
node = rb_next(node);
How about this? The nodes on the rbtree will be dequeued and removed
from rbtree one by one until HW is busy. Please note local vt and sta vt
will not be updated since txq lock is held during this time.
>
>>> + sta->airtime[ac].v_t += airtime / sta->airtime_weight;
>> Another question. Any plan for taking v_t overflow situation into
>> consideration? u64 might be enough for low throughput products but not
>> sure for high end products. Something like below for reference:
>
> The unit for the variable is time, not bytes, so it is unaffected by
> throughput. 2**64 microseconds is 584554 *years* according to my
> 'units' binary, so don't think we have to worry too much about this
> overflowing ;)
Cool, Great! Then no problem with that now.
>
> -Toke
--
Yibo
^ permalink raw reply
* Re: [linux-sunxi] [PATCH v2 02/13] arm64: dts: allwinner: h6: Add Orange Pi 3 DTS
From: Jagan Teki @ 2019-04-09 13:27 UTC (permalink / raw)
To: Jagan Teki, linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Linus Walleij, David Airlie, Daniel Vetter, Mark Rutland,
Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
Maxime Coquelin, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, Kalle Valo, Naveen Gupta, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190409113157.e4vrzesbgmyslomb@core.my.home>
Hi Ondřej Jirman,
On Tue, Apr 9, 2019 at 5:01 PM Ondřej Jirman <megous@megous.com> wrote:
>
> Hi Jagan,
>
> On Tue, Apr 09, 2019 at 02:08:18PM +0530, Jagan Teki wrote:
> > Based on the conversation about using common dtsi from this thread[1],
> > I'm commenting here to make show the diff directly on the nodes,
> > giving comments on each node so-that we can see the diff globally.
>
> Thanks for the suggestions below. It mostly repeats the differences and
> commonalities I already stated in the previous discussion.
>
> I don't have much to add to what I already said previously, though, because you
> didn't address my concerns there. But I can restate and expand on those
> concerns.
>
> Previously I already agreed it's possible to base orangepi-3.dts on
> orangepi.dtsi, and proposed a maintainable way forward, and why to follow it (to
> quote myself):
>
> Schematics allow for high amount of variability in the power tree (see all the
> NC (not connected) / 0R resistors) in the schematic around AXP805. Every board
> based on this Xunlong design can be subtly different.
Well, how about defining them in required dts file and group it common
regulators in dtsi? The idea of all these 3 H6 OPI boards are
evaluated in the same design consideration by adding new IP's in new
boards design by keeping the core things common like lite2 has wifi,
one plus has emac and 3 has PCIe etc. This is what I got from
Steven(OrangePI).
>
> I already suggested a maintainable solution, below. Where base dtsi has empty
> config for regulators and every board based on that just defines it completely
> for itself.
>
> A few regulators (for CPU/GPU) will most probably have the same meaning on
> every derived board, so these can probably be kept in dtsi without causing too
> much annoyance.
>
> It's unpleasant to have wrong regulator setup defined in an underlying dtsi,
> and then trying to override it by removing/adding random properties in the
> board dts for the new boards based on that, so that it fits.
If we manage them properly by moving common things in dtsi and rest in
dts, we may avoid these underlying issues.
>
> The rest of the current HW descriptions in the sun50i-h6-orangepi.dtsi can be
> shared (as of now).
>
> My suggestion was this:
>
> So to base Orange Pi 3 dts on top of existing sun50i-h6-orangepi.dtsi I'd have
> to first move some things out of the base dtsi to the OrangePi Lite2 and One
> Plus board dts files, in order to have sun50i-h6-orangepi.dtsi only describe
> HW that is *really* shared by these 2 boards and Orange Pi 3.
>
> If I do that, I'd undefine all the axp805 regulator nodes and move the
> configurations to each of the 3 board files. That will probably end up being
> the least confusing and most maintainable. See axp81x.dtsi lines 86-144 for
> what I mean.
>
> You seem to be suggesting a solution where every time we add an OrangePi H6
> based board, the person adding it will have to go through the base dtsi and all
> the other boards based on it, status disable or otherwise change regulators in
> the base dtsi, patch all the other boards to re-enable it.
>
> It would be already unpleasant just adding a third board based on this approach.
> And when the fourth board is added, with another small differences in the
> regulator use/meanings, the person will be looking at patching 4 dts files
> + adding one for his own board. For what benefit, to save some bytes right now?
>
> I think maintainability, ease of adding new boards is more important, than
> having a dtsi that tries to maximally cover all the commonalities between the
> existing boards right now, without regards for the future. That's why
> I suggested an approach like in axp81x.dtsi lines 86-144.
True, if the boards indeed are different but we can maintain easily if
the boards are from same family of design based my experience and few
boards do share common things in dtsi already.
Anyway, thanks for inputs. Seems like patch is applied already may be
we can move into dtsi if require in future.
Thanks,
Jagan.
^ permalink raw reply
* gsmtap design/extensions?
From: Johannes Berg @ 2019-04-09 13:50 UTC (permalink / raw)
To: laforge, openbsc
Cc: radiotap, linux-wireless, Subash Abhinov Kasiviswanathan,
Dan Williams, Bjørn Mork, netdev, Sean Tranchetti,
Aleksander Morgado
Hi,
As I'm looking into adding a generic cell modem framework to the linux
kernel (to create session netdevs etc.), I started looking for a
metadata encapsulation, a la Radiotap (I'm a wifi guy :-) ).
So obviously, I found gsmtap, but for my use case it doesn't really
address most of the interesting data, and it got me wondering. So a few
questions, if I may:
1) Why the design with encapsulating it in UDP? Radiotap is just a raw
header without IP etc. in front, and you use it with tcpdump,
wireshark or similar tools on the local system. What's the value in
having something "network transparent"?
2) The format of gsmtap doesn't seem very extensible, but I guess a new
version could be made that has a TLV-based format or so. I'd have
argued that a new version isn't even needed, but the length field is
only 8 bits right now which seems too short.
(speaking of versions - the docs say "version, set to 0x01 currently"
but "#define GSMTAP_VERSION 0x02")
3) Does the packet data follow the gsmtap header? It's not really clear
to me based on reading the wireshark code.
In particular, the data I'm thinking of is higher-level things, like the
session ID for a frame when it's going through the kernel, or perhaps a
flow label on RX, etc.
Also, vendor-specific data would be useful, e.g. to encapsulate the
device-specific headers like QMI, where such metadata is encapsulated in
a vendor- or device-specific way, which you'd want to see for debugging
certain things, but for other things the generic "session ID" type
information - encoded in a vendor-agnostic way - would be better to show
in wireshark.
Since it doesn't seem possible to use gsmtap in the current version,
would it make sense to define a new gsmtap that (say) has version 3 or
something, followed by an overall length and TLVs? I do note that this
wouldn't be compatible with the current wireshark code as it doesn't
check the version, just shows it...
Or would it make more sense to define a new ARPHDR_WWANTAP like
ARPHDR_IEEE80211_RADIOTAP and just use that instead of encapsulating in
IP/UDP, and then have a completely new (extensible) protocol inside of
that? I'm not really sure I see the point of UDP encapsulation anyway.
Thanks,
johannes
^ permalink raw reply
* Re: [PATCH v2] mac80211: fix RX STBC override byte order
From: Sergey Matyukevich @ 2019-04-09 14:55 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org, Johannes Berg
In-Reply-To: <20190409121120.7962-1-johannes@sipsolutions.net>
> The original patch neglected to take byte order conversions
> into account, fix that.
>
> Fixes: d9bb410888ce ("mac80211: allow overriding HT STBC capabilities")
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> net/mac80211/ht.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/net/mac80211/ht.c b/net/mac80211/ht.c
> index e03c46ac8e4d..c62101857b9b 100644
> --- a/net/mac80211/ht.c
> +++ b/net/mac80211/ht.c
> @@ -112,8 +112,9 @@ void ieee80211_apply_htcap_overrides(struct ieee80211_sub_if_data *sdata,
> IEEE80211_HT_CAP_TX_STBC);
>
> /* Allow user to configure RX STBC bits */
> - if (ht_capa_mask->cap_info & IEEE80211_HT_CAP_RX_STBC)
> - ht_cap->cap |= ht_capa->cap_info & IEEE80211_HT_CAP_RX_STBC;
> + if (ht_capa_mask->cap_info & cpu_to_le16(IEEE80211_HT_CAP_RX_STBC))
> + ht_cap->cap |= le16_to_cpu(ht_capa->cap_info) &
> + IEEE80211_HT_CAP_RX_STBC;
>
> /* Allow user to decrease AMPDU factor */
> if (ht_capa_mask->ampdu_params_info &
Thanks for fixing this!
Reviewed-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Regards,
Sergey
^ permalink raw reply
* Re: [PATCH 15/21] rt2x00: rt2800lib: hardcode txmixer gain values to zero for RT3883
From: Tom Psyborg @ 2019-04-09 15:26 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: linux-wireless, Daniel Golle, Felix Fietkau, Mathias Kresin,
Gabor Juhos
In-Reply-To: <1554809828-13500-16-git-send-email-sgruszka@redhat.com>
On 09/04/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> From: Gabor Juhos <juhosg@openwrt.org>
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> ---
> drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> index 0687bef990e1..4ea94c62d439 100644
> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> @@ -9128,7 +9128,8 @@ static u8 rt2800_get_txmixer_gain_24g(struct
> rt2x00_dev *rt2x00dev)
> {
> u16 word;
>
> - if (rt2x00_rt(rt2x00dev, RT3593))
> + if (rt2x00_rt(rt2x00dev, RT3593) ||
> + rt2x00_rt(rt2x00dev, RT3883))
> return 0;
>
> word = rt2800_eeprom_read(rt2x00dev, EEPROM_TXMIXER_GAIN_BG);
> @@ -9142,7 +9143,8 @@ static u8 rt2800_get_txmixer_gain_5g(struct rt2x00_dev
> *rt2x00dev)
> {
> u16 word;
>
> - if (rt2x00_rt(rt2x00dev, RT3593))
> + if (rt2x00_rt(rt2x00dev, RT3593) ||
> + rt2x00_rt(rt2x00dev, RT3883))
> return 0;
>
> word = rt2800_eeprom_read(rt2x00dev, EEPROM_TXMIXER_GAIN_A);
> --
> 2.7.5
>
>
Did someone actually verified this is correct?
^ permalink raw reply
* Re: [PATCH] NFC: pn533: mark expected switch fall-throughs
From: Kees Cook @ 2019-04-09 16:29 UTC (permalink / raw)
To: Gustavo A. R. Silva; +Cc: Samuel Ortiz, linux-wireless, LKML
In-Reply-To: <20190213185741.GA5047@embeddedor>
On Wed, Feb 13, 2019 at 10:57 AM Gustavo A. R. Silva
<gustavo@embeddedor.com> wrote:
>
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> This patch fixes the following warnings:
>
> drivers/nfc/pn533/pn533.c: In function ‘pn533_transceive’:
> drivers/nfc/pn533/pn533.c:2142:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
> if (dev->tgt_active_prot == NFC_PROTO_FELICA) {
> ^
> drivers/nfc/pn533/pn533.c:2150:2: note: here
> default:
> ^~~~~~~
> drivers/nfc/pn533/pn533.c: In function ‘pn533_wq_mi_recv’:
> drivers/nfc/pn533/pn533.c:2267:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
> if (dev->tgt_active_prot == NFC_PROTO_FELICA) {
> ^
> drivers/nfc/pn533/pn533.c:2276:2: note: here
> default:
> ^~~~~~~
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> This patch is part of the ongoing efforts to enable
> -Wimplicit-fallthrough.
>
> Addresses-Coverity-ID: 1230487 ("Missing break in switch")
> Addresses-Coverity-ID: 1230488 ("Missing break in switch")
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
--
Kees Cook
^ permalink raw reply
* Re: [PATCH] NFC: st21nfca: Fix a couple of fall-through warnings
From: Kees Cook @ 2019-04-09 16:30 UTC (permalink / raw)
To: Gustavo A. R. Silva; +Cc: Samuel Ortiz, linux-wireless, LKML
In-Reply-To: <20190212173902.GA6829@embeddedor>
On Tue, Feb 12, 2019 at 9:39 AM Gustavo A. R. Silva
<gustavo@embeddedor.com> wrote:
>
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> This patch fixes the following warnings by adding a missing break
> and a fall-through annotation:
>
> drivers/nfc/st21nfca/dep.c: In function ‘st21nfca_tm_event_send_data’:
> drivers/nfc/st21nfca/dep.c:391:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
> switch (cmd1) {
> ^~~~~~
> drivers/nfc/st21nfca/dep.c:404:2: note: here
> default:
> ^~~~~~~
> In file included from ./include/linux/kernel.h:15,
> from ./include/linux/skbuff.h:17,
> from ./include/net/nfc/hci.h:21,
> from drivers/nfc/st21nfca/dep.c:17:
> drivers/nfc/st21nfca/dep.c: In function ‘st21nfca_im_recv_dep_res_cb’:
> ./include/linux/printk.h:303:2: warning: this statement may fall through [-Wimplicit-fallthrough=]
> printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/nfc/st21nfca/dep.c:622:4: note: in expansion of macro ‘pr_err’
> pr_err("Received a ACK/NACK PDU\n");
> ^~~~~~
> drivers/nfc/st21nfca/dep.c:623:3: note: here
> case ST21NFCA_NFC_DEP_PFB_I_PDU:
> ^~~~
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> This patch is part of the ongoing efforts to enable
> -Wimplicit-fallthrough.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
--
Kees Cook
^ permalink raw reply
* [PATCHv3 0/2] cfg80211/mac80211: Add support to configure and monitor station's rssi threshold
From: Tamizh chelvam @ 2019-04-09 17:38 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Tamizh chelvam
This patchsets introduced new NL command and api to support
configuring rssi for the connected stations and api to notify
userspace application upon crossing the configured threshold.
This will be useful for the application which requires
station's current signal strength change information.
Monitoring station's signal strength through station dump command
will unnecessarily increase the system overhead. This event based
mechanism will reduce the system overhead and helps application to
take a decision for the station for which event received.
Tamizh chelvam (2):
cfg80211: Add support to configure station specific RSSI threshold
for AP mode
mac80211: Implement API to configure station specific rssi threshold
v3:
* Addressed Johannes comments
v2:
* Combined patchset 2 and 3 as single patch and addressed Johannes comments.
include/net/cfg80211.h | 39 +++++++++
include/net/mac80211.h | 7 ++
include/uapi/linux/nl80211.h | 21 +++++
net/mac80211/cfg.c | 108 +++++++++++++++++++++++++
net/mac80211/rx.c | 56 ++++++++++++-
net/mac80211/sta_info.c | 1 +
net/mac80211/sta_info.h | 31 ++++++++
net/wireless/nl80211.c | 179 ++++++++++++++++++++++++++++++++++++------
net/wireless/rdev-ops.h | 13 +++
net/wireless/trace.h | 21 +++++
10 files changed, 449 insertions(+), 27 deletions(-)
--
1.7.9.5
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox