* [RFC 06/12] mt76x02u: add sta_ps
From: Stanislaw Gruszka @ 2019-02-28 8:03 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, Lorenzo Bianconi
In-Reply-To: <1551341013-24519-1-git-send-email-sgruszka@redhat.com>
Add sta_ps callback but dont set WCID drop sicne registers for USB
can not be accessed from tasklet context.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/mediatek/mt76/mt76x0/usb.c | 1 +
drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 3 ++-
drivers/net/wireless/mediatek/mt76/mt76x2/usb.c | 1 +
3 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c b/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
index 7f3113b91498..0348a1b38d2d 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
@@ -222,6 +222,7 @@ static int mt76x0u_probe(struct usb_interface *usb_intf,
.tx_complete_skb = mt76x02u_tx_complete_skb,
.tx_status_data = mt76x02_tx_status_data,
.rx_skb = mt76x02_queue_rx_skb,
+ .sta_ps = mt76x02_sta_ps,
.sta_add = mt76x02_sta_add,
.sta_remove = mt76x02_sta_remove,
};
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
index 83fc9d1add82..97a8aa30c333 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
@@ -625,7 +625,8 @@ void mt76x02_sta_ps(struct mt76_dev *mdev, struct ieee80211_sta *sta,
int idx = msta->wcid.idx;
mt76_stop_tx_queues(&dev->mt76, sta, true);
- mt76x02_mac_wcid_set_drop(dev, idx, ps);
+ if (mt76_is_mmio(dev))
+ mt76x02_mac_wcid_set_drop(dev, idx, ps);
}
EXPORT_SYMBOL_GPL(mt76x02_sta_ps);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c b/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c
index ddb6b2c48e01..03cd744bb89d 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c
@@ -41,6 +41,7 @@ static int mt76x2u_probe(struct usb_interface *intf,
.tx_complete_skb = mt76x02u_tx_complete_skb,
.tx_status_data = mt76x02_tx_status_data,
.rx_skb = mt76x02_queue_rx_skb,
+ .sta_ps = mt76x02_sta_ps,
.sta_add = mt76x02_sta_add,
.sta_remove = mt76x02_sta_remove,
};
--
2.20.1
^ permalink raw reply related
* [RFC 07/12] mt76x02: fix hdr pointer in write txwi for USB
From: Stanislaw Gruszka @ 2019-02-28 8:03 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, Lorenzo Bianconi
In-Reply-To: <1551341013-24519-1-git-send-email-sgruszka@redhat.com>
Since we add txwi at the begining of skb->data, it no longer point
to ieee80211_hdr. This breaks settings TS bit for probe response and
beacons.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c b/drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c
index fdd6a021914d..bcf3126efda9 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c
@@ -85,8 +85,9 @@ int mt76x02u_tx_prepare_skb(struct mt76_dev *mdev, void *data,
mt76x02_insert_hdr_pad(skb);
- txwi = skb_push(skb, sizeof(struct mt76x02_txwi));
+ txwi = (struct mt76x02_txwi *)(skb->data - sizeof(struct mt76x02_txwi));
mt76x02_mac_write_txwi(dev, txwi, skb, wcid, sta, len);
+ skb_push(skb, sizeof(struct mt76x02_txwi));
pid = mt76_tx_status_skb_add(mdev, wcid, skb);
txwi->pktid = pid;
--
2.20.1
^ permalink raw reply related
* [RFC 08/12] mt76x02: disable HW encryption for group frames
From: Stanislaw Gruszka @ 2019-02-28 8:03 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, Lorenzo Bianconi
In-Reply-To: <1551341013-24519-1-git-send-email-sgruszka@redhat.com>
This is required to sent multicast/broadcast frames in USB AP
mode just after beacon.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
index 97a8aa30c333..6e5ad900bf4e 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
@@ -418,6 +418,16 @@ int mt76x02_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
!(key->flags & IEEE80211_KEY_FLAG_PAIRWISE))
return -EOPNOTSUPP;
+ /*
+ * In USB AP mode, broadcast/multicast frames are setup in beacon
+ * data registers and sent via HW beacons engine, they require to
+ * be already encrypted.
+ */
+ if (mt76_is_usb(dev) &&
+ vif->type == NL80211_IFTYPE_AP &&
+ !(key->flags & IEEE80211_KEY_FLAG_PAIRWISE))
+ return -EOPNOTSUPP;
+
msta = sta ? (struct mt76x02_sta *) sta->drv_priv : NULL;
wcid = msta ? &msta->wcid : &mvif->group_wcid;
--
2.20.1
^ permalink raw reply related
* [RFC 09/12] mt76x02u: implement pre TBTT work for USB
From: Stanislaw Gruszka @ 2019-02-28 8:03 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, Lorenzo Bianconi
In-Reply-To: <1551341013-24519-1-git-send-email-sgruszka@redhat.com>
Program beacons data and PS buffered frames on TBTT work for USB.
We do not have MT_TXQ_PSD queue available via USB endpoints. The way
we can send PS broadcast frames in timely manner before PS stations go
sleep again is program them in beacon data area. Hardware do not modify
those frames since TXWI is properly configured. mt76x02_mac_set_beacon()
already handle this and free no longer used frames.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
.../wireless/mediatek/mt76/mt76x02_beacon.c | 2 ++
.../wireless/mediatek/mt76/mt76x02_usb_core.c | 36 +++++++++++++++++--
2 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_beacon.c b/drivers/net/wireless/mediatek/mt76/mt76x02_beacon.c
index 28102082772b..63e2926cdd0c 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_beacon.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_beacon.c
@@ -38,6 +38,7 @@ const u16 mt76x02_beacon_offsets[16] = {
0xc000,
0xc000,
};
+EXPORT_SYMBOL_GPL(mt76x02_beacon_offsets);
static void mt76x02_set_beacon_offsets(struct mt76x02_dev *dev)
{
@@ -134,6 +135,7 @@ int mt76x02_mac_set_beacon(struct mt76x02_dev *dev, u8 vif_idx,
bcn_idx - 1);
return 0;
}
+EXPORT_SYMBOL_GPL(mt76x02_mac_set_beacon);
static void
__mt76x02_mac_set_beacon_enable(struct mt76x02_dev *dev, u8 vif_idx,
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c b/drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c
index bcf3126efda9..2761a9300755 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c
@@ -165,9 +165,32 @@ static void mt76x02u_pre_tbtt_work(struct work_struct *work)
{
struct mt76x02_dev *dev =
container_of(work, struct mt76x02_dev, pre_tbtt_work);
+ int beacon_len = mt76x02_beacon_offsets[1] - mt76x02_beacon_offsets[0];
+ struct beacon_bc_data data = {};
+ struct sk_buff *skb;
+ int i, nbeacons;
if (!dev->beacon_mask)
return;
+
+ mt76x02_resync_beacon_timer(dev);
+
+ ieee80211_iterate_active_interfaces(mt76_hw(dev),
+ IEEE80211_IFACE_ITER_RESUME_ALL,
+ mt76x02_update_beacon_iter, dev);
+
+ nbeacons = hweight8(dev->beacon_mask);
+ mt76x02_enqueue_buffered_bc(dev, &data, 8 - nbeacons);
+
+ for (i = nbeacons; i < 8; i++) {
+ skb = __skb_dequeue(&data.q);
+ if (skb && skb->len >= beacon_len) {
+ dev_kfree_skb(skb);
+ skb = NULL;
+ }
+ mt76x02_mac_set_beacon(dev, i, skb);
+ }
+
mt76x02u_restart_pre_tbtt_timer(dev);
}
@@ -191,13 +214,20 @@ static void mt76x02u_pre_tbtt_enable(struct mt76x02_dev *dev, bool en)
static void mt76x02u_beacon_enable(struct mt76x02_dev *dev, bool en)
{
+ int i;
+
if (WARN_ON_ONCE(!dev->beacon_int))
return;
- if (en)
+ if (en) {
mt76x02u_start_pre_tbtt_timer(dev);
-
- /* Nothing to do on disable as timer is already stopped */
+ } else {
+ /* Timer is already stopped, only clean up
+ * PS buffered frames if any.
+ */
+ for (i = 0; i < 8; i++)
+ mt76x02_mac_set_beacon(dev, i, NULL);
+ }
}
void mt76x02u_init_beacon_config(struct mt76x02_dev *dev)
--
2.20.1
^ permalink raw reply related
* [RFC 10/12] mt76x02u: add mt76_release_buffered_frames
From: Stanislaw Gruszka @ 2019-02-28 8:03 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, Lorenzo Bianconi
In-Reply-To: <1551341013-24519-1-git-send-email-sgruszka@redhat.com>
Create software MT_TXQ_PSD queue for USB and map it to MT_TXQ_VO
since we do not have USB endpoint for PSD. This should make
mt76_release_buffered_frames() work by sending released frames
via MT_TXQ_VO.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/mediatek/mt76/mt76x0/usb.c | 1 +
.../net/wireless/mediatek/mt76/mt76x2/usb_main.c | 1 +
drivers/net/wireless/mediatek/mt76/usb.c | 13 ++++++++-----
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c b/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
index 0348a1b38d2d..b9b8a1dafbc9 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
@@ -152,6 +152,7 @@ static const struct ieee80211_ops mt76x0u_ops = {
.set_rts_threshold = mt76x02_set_rts_threshold,
.wake_tx_queue = mt76_wake_tx_queue,
.get_txpower = mt76_get_txpower,
+ .release_buffered_frames = mt76_release_buffered_frames,
};
static int mt76x0u_init_hardware(struct mt76x02_dev *dev)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c
index 2ac78e4dc41a..653b8df29ca3 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c
@@ -125,4 +125,5 @@ const struct ieee80211_ops mt76x2u_ops = {
.sw_scan_complete = mt76x02_sw_scan_complete,
.sta_rate_tbl_update = mt76x02_sta_rate_tbl_update,
.get_txpower = mt76_get_txpower,
+ .release_buffered_frames = mt76_release_buffered_frames,
};
diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
index ae6ada370597..f181200c05cb 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -632,7 +632,7 @@ static void mt76u_tx_tasklet(unsigned long data)
bool wake;
int i;
- for (i = 0; i < IEEE80211_NUM_ACS; i++) {
+ for (i = 0; i <= MT_TXQ_PSD; i++) {
q = &dev->q_tx[i];
spin_lock_bh(&q->lock);
@@ -785,11 +785,14 @@ static int mt76u_alloc_tx(struct mt76_dev *dev)
struct mt76_queue *q;
int i, j;
- for (i = 0; i < IEEE80211_NUM_ACS; i++) {
+ for (i = 0; i <= MT_TXQ_PSD; i++) {
q = &dev->q_tx[i];
spin_lock_init(&q->lock);
INIT_LIST_HEAD(&q->swq);
- q->hw_idx = mt76_ac_to_hwq(i);
+ if (i < IEEE80211_NUM_ACS)
+ q->hw_idx = mt76_ac_to_hwq(i);
+ else
+ q->hw_idx = 0;
q->entry = devm_kcalloc(dev->dev,
MT_NUM_TX_ENTRIES, sizeof(*q->entry),
@@ -825,7 +828,7 @@ static void mt76u_free_tx(struct mt76_dev *dev)
struct mt76_queue *q;
int i, j;
- for (i = 0; i < IEEE80211_NUM_ACS; i++) {
+ for (i = 0; i <= MT_TXQ_PSD; i++) {
q = &dev->q_tx[i];
for (j = 0; j < q->ndesc; j++)
usb_free_urb(q->entry[j].ubuf.urb);
@@ -837,7 +840,7 @@ static void mt76u_stop_tx(struct mt76_dev *dev)
struct mt76_queue *q;
int i, j;
- for (i = 0; i < IEEE80211_NUM_ACS; i++) {
+ for (i = 0; i <= MT_TXQ_PSD; i++) {
q = &dev->q_tx[i];
for (j = 0; j < q->ndesc; j++)
usb_kill_urb(q->entry[j].ubuf.urb);
--
2.20.1
^ permalink raw reply related
* [RFC 11/12] mt76x02: enable AP mode for USB
From: Stanislaw Gruszka @ 2019-02-28 8:03 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, Lorenzo Bianconi
In-Reply-To: <1551341013-24519-1-git-send-email-sgruszka@redhat.com>
Enable AP mode. For now without multi-vif support, this will require
more testing and investigation.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
index 6e5ad900bf4e..49da4e6ae0c7 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
@@ -142,6 +142,7 @@ void mt76x02_init_device(struct mt76x02_dev *dev)
wiphy->interface_modes =
BIT(NL80211_IFTYPE_STATION) |
+ BIT(NL80211_IFTYPE_AP) |
#ifdef CONFIG_MAC80211_MESH
BIT(NL80211_IFTYPE_MESH_POINT) |
#endif
@@ -158,7 +159,6 @@ void mt76x02_init_device(struct mt76x02_dev *dev)
wiphy->reg_notifier = mt76x02_regd_notifier;
wiphy->iface_combinations = mt76x02_if_comb;
wiphy->n_iface_combinations = ARRAY_SIZE(mt76x02_if_comb);
- wiphy->interface_modes |= BIT(NL80211_IFTYPE_AP);
wiphy->flags |= WIPHY_FLAG_HAS_CHANNEL_SWITCH;
/* init led callbacks */
--
2.20.1
^ permalink raw reply related
* [RFC 12/12] mt76x02: remove set_tim
From: Stanislaw Gruszka @ 2019-02-28 8:03 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, Lorenzo Bianconi
In-Reply-To: <1551341013-24519-1-git-send-email-sgruszka@redhat.com>
set_tim callback is not used by mac80211 if AP_LINK_PS hw flag is set.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/mediatek/mt76/mt76x0/pci.c | 8 --------
drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c | 7 -------
2 files changed, 15 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c b/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
index fafe57653ac0..68d44929dafa 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
@@ -74,13 +74,6 @@ mt76x0e_flush(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
{
}
-static int
-mt76x0e_set_tim(struct ieee80211_hw *hw, struct ieee80211_sta *sta,
- bool set)
-{
- return 0;
-}
-
static const struct ieee80211_ops mt76x0e_ops = {
.tx = mt76x02_tx,
.start = mt76x0e_start,
@@ -101,7 +94,6 @@ static const struct ieee80211_ops mt76x0e_ops = {
.get_survey = mt76_get_survey,
.get_txpower = mt76_get_txpower,
.flush = mt76x0e_flush,
- .set_tim = mt76x0e_set_tim,
.release_buffered_frames = mt76_release_buffered_frames,
.set_coverage_class = mt76x02_set_coverage_class,
.set_rts_threshold = mt76x02_set_rts_threshold,
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
index 878ce92405ed..f45847f48920 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
@@ -135,12 +135,6 @@ mt76x2_flush(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
{
}
-static int
-mt76x2_set_tim(struct ieee80211_hw *hw, struct ieee80211_sta *sta, bool set)
-{
- return 0;
-}
-
static int mt76x2_set_antenna(struct ieee80211_hw *hw, u32 tx_ant,
u32 rx_ant)
{
@@ -197,7 +191,6 @@ const struct ieee80211_ops mt76x2_ops = {
.release_buffered_frames = mt76_release_buffered_frames,
.set_coverage_class = mt76x02_set_coverage_class,
.get_survey = mt76_get_survey,
- .set_tim = mt76x2_set_tim,
.set_antenna = mt76x2_set_antenna,
.get_antenna = mt76x2_get_antenna,
.set_rts_threshold = mt76x02_set_rts_threshold,
--
2.20.1
^ permalink raw reply related
* Re: [PATCH wireless-drivers-next 1/2] brcmfmac: fix size of the struct msgbuf_ring_status
From: Kalle Valo @ 2019-02-28 8:28 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Arend van Spriel, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, Rafał Miłecki
In-Reply-To: <20190221103325.28228-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> This updates host struct to match the in-firmawre definition. It's a
> cosmetic change as it only applies to the reserved struct space.
>
> Fixes: c988b78244df ("brcmfmac: print firmware reported ring status errors")
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
2 patches applied to wireless-drivers-next.git, thanks.
0c7051610c57 brcmfmac: fix size of the struct msgbuf_ring_status
c91377495192 brcmfmac: print firmware reported general status errors
--
https://patchwork.kernel.org/patch/10823623/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH][next] rsi: fix missing null pointer check from a failed ieee80211_probereq_get call
From: Kalle Valo @ 2019-02-28 8:29 UTC (permalink / raw)
To: Colin King
Cc: Amitkumar Karwar, Siva Rebbagondla, David S . Miller,
linux-wireless, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20190221123549.7294-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The call to ieee80211_probereq_get can return NULL if a skb allocation
> fails, so add a null pointer check and free an earlier skb on the error
> exit return path.
>
> Fixes: 7fdcb8e12660 ("rsi: add support for hardware scan offload")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied to wireless-drivers-next.git, thanks.
74ee436f9581 rsi: fix missing null pointer check from a failed ieee80211_probereq_get call
--
https://patchwork.kernel.org/patch/10824023/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: long startup delay ath10k_pci known issue?
From: Kalle Valo @ 2019-02-28 8:37 UTC (permalink / raw)
To: Robert White; +Cc: linux-wireless
In-Reply-To: <53b7cbe9-f419-24c7-0f51-37f92e11df1d@pobox.com>
Robert White <rwhite@pobox.com> writes:
> I recently switched from an ath9k to an ath10k on my (gentoo based)
> home-build router, and there is about a two minute delay between the
> time of the modprobe of ath10k_pci and the time "iw list" can see the
> wireless endpoint. Then there's maybe another delay before the wlan0
> device appears in the kernel.
>
> This extreme delay is preventing a normal startup because it causes an
> error return in the OpenRC dependency/startup logic.
>
> That dependency tree is it's own problem, of course, but I don't
> understand why the delay is taking place. There are no errors shown in
> the startup and the system runs fine once manually kicked around to
> get it running (e.g. manually modprobing the various devices and then
> waiting and then re-triggering various parts of the startup).
>
> I have to reiterate that the system starts and runs fine as-configured
> if I put the ath9k device back in, so it's not a system-level
> configuration problem.
ath9k PCI device does not retrieve firmware images from user space so I
would not yet rule out a system level problem.
> Is this long delay after module and firmware load some expected effect
> that I need to code around or what?
Usually these 60 second (or it's multiply) delays are caused by kernel
requesting a firmware image from user space but the corresponding user
space component is not replying and kernel waits for the reply until it
timeouts and continues. IIRC there's a kernel config option you can use
to disable this feature, or you could also try to fix the user space.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/8] rtlwifi: Fix errors in spacing in wifi.h
From: Kalle Valo @ 2019-02-28 8:38 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, pkshih, Larry Finger
In-Reply-To: <20190221193115.30848-2-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> Checkpatch.pl report problems in wifi.h where spaces are missing, as well
> as extraneous spaces.
>
> There are no changes in the generated code.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
8 patches applied to wireless-drivers-next.git, thanks.
6e5d9041525a rtlwifi: Fix errors in spacing in wifi.h
d3da329c1d8c rtlwifi: Fix problems with block comments in wifi.h
1dc89bb93c42 rtlwifi: Fix alignment errors in wifi.h
93665097ea23 rtlwifi: Fix blank line errors in main header files
b16abaafea47 rtlwifi: Fix all blank line irregularities in main code files
2973af748d4d rtlwifi: rtl8192ce: Fix missing blank lines
6d255202a272 rtlwifi: rtl8192cu: Fix problems with blank lines
52f886571263 rtlwifi: rtl8192com: Fix blank line problems
--
https://patchwork.kernel.org/patch/10824687/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 3/5] mt76: fix a leaked reference by adding a missing of_node_put
From: Kalle Valo @ 2019-02-28 8:39 UTC (permalink / raw)
To: Wen Yang
Cc: linus.walleij, andrew, vivien.didelot, f.fainelli, davem, netdev,
linux-kernel, alexandre.belloni, UNGLinuxDriver, nbd,
lorenzo.bianconi83, matthias.bgg, linux-wireless,
linux-arm-kernel, linux-mediatek, anirudh, John.Linn,
michal.simek, wang.yi59, Wen Yang
In-Reply-To: <1550819742-32155-3-git-send-email-wen.yang99@zte.com.cn>
Wen Yang <wen.yang99@zte.com.cn> wrote:
> The call to of_find_node_by_phandle returns a node pointer with refcount
> incremented thus it must be explicitly decremented after the last
> usage.
>
> Detected by coccinelle with the following warnings:
> ./drivers/net/wireless/mediatek/mt76/eeprom.c:58:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
> ./drivers/net/wireless/mediatek/mt76/eeprom.c:61:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
> ./drivers/net/wireless/mediatek/mt76/eeprom.c:67:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
> ./drivers/net/wireless/mediatek/mt76/eeprom.c:70:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
> ./drivers/net/wireless/mediatek/mt76/eeprom.c:72:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
>
> Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
> Cc: Felix Fietkau <nbd@nbd.name>
> Cc: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-mediatek@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
Patch applied to wireless-drivers-next.git, thanks.
34e022d8b780 mt76: fix a leaked reference by adding a missing of_node_put
--
https://patchwork.kernel.org/patch/10825315/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rtlwifi: rtl8723be: Remove set but not used variable 'b_last_is_cur_rdlstate'
From: Kalle Valo @ 2019-02-28 8:39 UTC (permalink / raw)
To: YueHaibing
Cc: Ping-Ke Shih, Larry Finger, YueHaibing, linux-wireless, netdev,
kernel-janitors
In-Reply-To: <20190227022321.7623-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c: In function 'rtl8723be_dm_check_edca_turbo':
> drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c:998:7: warning:
> variable 'b_last_is_cur_rdlstate' set but not used [-Wunused-but-set-variable]
>
> It's never used and can be removed.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
f32150565601 rtlwifi: rtl8723be: Remove set but not used variable 'b_last_is_cur_rdlstate'
--
https://patchwork.kernel.org/patch/10830999/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rtlwifi: rtl8723ae: Remove set but not used variable 'bt_retry_cnt'
From: Kalle Valo @ 2019-02-28 8:40 UTC (permalink / raw)
To: YueHaibing
Cc: Ping-Ke Shih, Larry Finger, YueHaibing, linux-wireless, netdev,
kernel-janitors
In-Reply-To: <20190227022334.7750-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hal_btc.c: In function '_rtl8723e_dm_bt_coexist_2_ant':
> drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hal_btc.c:1408:5: warning:
> variable 'bt_retry_cnt' set but not used [-Wunused-but-set-variable]
>
> It's never used and can be removed.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
85c6ac33c87c rtlwifi: rtl8723ae: Remove set but not used variable 'bt_retry_cnt'
--
https://patchwork.kernel.org/patch/10831001/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rtlwifi: rtl8192se: Remove set but not used variable 'seg_ptr'
From: Kalle Valo @ 2019-02-28 8:40 UTC (permalink / raw)
To: YueHaibing
Cc: Ping-Ke Shih, Larry Finger, YueHaibing, linux-wireless, netdev,
kernel-janitors
In-Reply-To: <20190227022347.7927-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/realtek/rtlwifi/rtl8192se/fw.c: In function '_rtl92s_firmware_downloadcode':
> drivers/net/wireless/realtek/rtlwifi/rtl8192se/fw.c:139:17: warning:
> variable 'seg_ptr' set but not used [-Wunused-but-set-variable]
>
> It's not used after commit 59ae1d127ac0 ("networking: introduce and use
> skb_put_data()")
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
037e0c5df649 rtlwifi: rtl8192se: Remove set but not used variable 'seg_ptr'
--
https://patchwork.kernel.org/patch/10831003/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2 1/4] ath10k: Fix the incorrect updation of NSS data in tx stats
From: Kalle Valo @ 2019-02-28 8:46 UTC (permalink / raw)
To: Surabhi Vishnoi; +Cc: ath10k, linux-wireless, Surabhi Vishnoi
In-Reply-To: <1551173278-20926-2-git-send-email-svishnoi@codeaurora.org>
Surabhi Vishnoi <svishnoi@codeaurora.org> wrote:
> The NSS data is updated incorrectly in the tx stats as the array
> indexing starts from zero.
>
> Fix the incorrect updation of NSS data in tx_stats by taking into
> consideration the array index starting from zero.
>
> Tested HW: WCN3990
> Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1
>
> Fixes: a904417fc876 ("ath10k: add extended per sta tx statistics support")
> Signed-off-by: Surabhi Vishnoi <svishnoi@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
4 patches applied to ath-next branch of ath.git, thanks.
3a08ac3e79e8 ath10k: Fix the incorrect updation of NSS data in tx stats
ef9051c72ab7 ath10k: Fix the wrong updation of BW in tx_stats debugfs entry
8e55fdaa8ea7 ath10k: Fix the wrong updation of SGI in tx_stats debugfs
d23c2cdaa013 ath10k: Fix the wrong calculation ht_idx and idx of rate table for tx_stats
--
https://patchwork.kernel.org/patch/10829765/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] ath10k: Fill rx duration for each peer in fw_stats for WCN3990
From: Kalle Valo @ 2019-02-28 8:48 UTC (permalink / raw)
To: Surabhi Vishnoi; +Cc: ath10k, linux-wireless, Surabhi Vishnoi
In-Reply-To: <1551174796-25264-1-git-send-email-svishnoi@codeaurora.org>
Surabhi Vishnoi <svishnoi@codeaurora.org> wrote:
> Currently, rx_duration for each peer is not getting populated in
> fw_stats debugfs entry for WCN3990.
>
> WCN3990 firmware sends rx duration for each peer as part of
> peer_extd_stats in WMI_UPDATE_STATS_EVENT. To enable peer_extd_stats,
> firmware expects host to send fw_stats_req_mask with flag
> WMI_TLV_PEER_STATS_EXTD set in WMI_REQUEST_STATS_CMD.
>
> Send fw_stats_req_mask with flag WMI_TLV_PEER_STATS_EXTD set in
> WMI_REQUEST_STATS_CMD and parse the peer_extd_stats in
> WMI_UPDATE_STATS_EVENT to populate the rx_duration of each peer
> in fw_stats debugfs entry.
>
> Currently the driver handles 32-bit rx_duration, but the rx_duration
> for WCN3990 can be upto 63 bit. The firmware sends rx_duration split
> into two 32-bit fields, with the upper 32-bits being valid only if its
> MSB is set. This change handles the 63-bit rx_duration obtained from
> WCN3990 and maintain the backward compatibility.
>
> To get the rx_duration of each connected peer :
> cat /sys/kernel/debug/ieee80211/phyX/ath10k/fw_stats
>
> Tested HW: WCN3990
> Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1
>
> Signed-off-by: Surabhi Vishnoi <svishnoi@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
f40a307eb92c ath10k: Fill rx duration for each peer in fw_stats for WCN3990
--
https://patchwork.kernel.org/patch/10829811/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: MT76x2U crashes XHCI driver on AMD Ryzen system
From: Stanislaw Gruszka @ 2019-02-28 9:04 UTC (permalink / raw)
To: Joerg Roedel
Cc: Lorenzo Bianconi, Rosen Penev, linux-wireless, Samuel Sieb,
Alexander Duyck, iommu, linux-kernel
In-Reply-To: <20190226112407.GB2989@redhat.com>
On Tue, Feb 26, 2019 at 12:24:08PM +0100, Stanislaw Gruszka wrote:
> On Tue, Feb 26, 2019 at 11:44:13AM +0100, Joerg Roedel wrote:
> > On Tue, Feb 26, 2019 at 11:34:51AM +0100, Stanislaw Gruszka wrote:
> > > On Tue, Feb 26, 2019 at 11:05:36AM +0100, Joerg Roedel wrote:
> > > If sg->offset > PAGE_SIZE is fine then most likely we have problem with
> > > alignment.
> >
> > The map_sg implementation in the AMD IOMMU driver uses sg_phys() which
> > handles the sg->page + sg->offset calculation fine.
> >
> > > Note hat issue is with dma_map_sg(), switching to dma_map_single()
> > > by using urb->transfer_buffer instead of urb->sg make things work
> > > on AMD IOMMU.
> >
> > On the other hand this points to a bug in the driver, I'll look further
> > if I can spot something there.
>
> I think so too. And I have done some changes that avoid strange allocation
> scheme and use usb synchronous messages instead of allocating buffers
> with unaligned sizes. However things work ok on Intel IOMMU and
> there is no documentation what are dma_map_sg() requirement versus
> dma_map_single() which works. I think there are some unwritten
> requirements and things can work on some platforms and fails on others
> (different IOMMUs, no-IOMMU on some ARCHes)
For the record: we have another bug report with this issue:
https://bugzilla.kernel.org/show_bug.cgi?id=202673
I provided there patch that change alignment for page_frag_alloc() and
it did not fixed the problem. So this is not alignment issue.
Now I think it could be page->refcount issue ...
Stanislaw
^ permalink raw reply
* Re: [PATCH 00/21] wil6210 patches
From: Kalle Valo @ 2019-02-28 9:05 UTC (permalink / raw)
To: Maya Erez; +Cc: linux-wireless, wil6210
In-Reply-To: <1550845279-16103-1-git-send-email-merez@codeaurora.org>
Maya Erez <merez@codeaurora.org> writes:
> The following set of patches include:
> - support up to 20 stations in AP mode
> - add support for ucode tracing
> - various wil6210 fixes
21 patches is just too much to review. I'll review (and apply) these in
smaller sets. Ideally these should have been split into 3 smaller sets
and only one set at a time in review queue, that they would be applied a
lot faster.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH RFC] mac80211: Use IFF_ECHO to force delivery of tx_status frames
From: Julius Niedworok @ 2019-02-28 9:05 UTC (permalink / raw)
To: Johannes Berg
Cc: Oliver Hartkopp, linux-wireless, ga58taw, David Hildenbrand, nc,
David S. Miller, Edward Cree, Jiri Pirko, Ido Schimmel,
Petr Machata, Kirill Tkhai, Alexander Duyck, Amritha Nambiar,
Li RongQing, netdev, linux-kernel, Julius Niedworok
In-Reply-To: <550ff2ac45c891a3fcf3dd8a454f9732d8aa1b70.camel@sipsolutions.net>
> On 26.02.2019 14:33 Johannes Berg wrote
>
> You're proposing to add this to the *monitor* interfaces and you really
> should have made the flag conditional on that to make that clear.
>
> However, even on monitor interfaces, you typically *already* see the
> frames you transmitted there (as raw frames, which is the only thing you
> can do).
>
Thanks for your prompt reply and thoughts on our patch.
Let us briefly describe our test setup to ensure everyone on this mailing
list is one the same page.
Our general setup looks like this:
1 $ iw wlp1s0 info
Interface wlp1s0
ifindex 5
wdev 0x1
addr 4c:5e:0c:11:43:ac
type managed
wiphy 0
txpower 30.00 dBm
1 $ iw phy phy0 interface add mon0 type monitor
1 $ iw phy phy0 interface add mon1 type monitor
When we send (raw) packets on mon0 using packetspammer [1] and listen on
the _other_ monitor mode interface mon1, we receive frames that were sent
on the first one:
1 $ packetspammer mon0
2 $ tcpdump -i mon1 'wlan addr2 13:22:33:44:55:66'
This is due to the fact that frames sent on mon0 are echoed back as TX
status frames, because REQ_TX_STATUS is always set for frames sent from
monitor mode interfaces.
But when we replace mon0 with an interface in managed mode (wlp1s0), the
receipt of frames stops, because in managed mode REQ_TX_STATUS is cleared
in most frames:
1 $ ifup wlp1s0
1 $ ping -I wlp1s0 192.168.254.1 # this address is not assigned to any host
2 $ tcpdump -i mon1 ‚wlan addr2 4c:5e:0c:11:43:ac‘
> What you're proposing is to use IFF_ECHO to show frames transmitted
> through *other* interfaces on the monitor interface.
>
> I don’t think the IFF_ECHO semantics really match this.
>
What we propose is to use IFF_ECHO to force REQ_TX_STATUS being set for all
frames sent on the interface. But you are right: The goal is that frames
transmitted through the other interface show up on the monitor interface
(but only after passing the driver). However, this is exactly how we
understand the semantics of IFF_ECHO in the kernel documentation.
>
> Additionally, drivers are sort of free to ignore the REQ_TX_STATUS, or
> we could in the future add ways of using the _noskb to feed back TX
> status to the state machines where needed, so I'm not really sure I even
> _want_ this to be set in stone in such an API.
>
As far as we know, drivers must return a TX status frame, if REQ_TX_STATUS
is set, but can do whatever they want, if it is clear. This is no problem for our
functionality, because we force the delivery of TX status frames by
permanently setting REQ_TX_STATUS. As long as the semantics of
REQ_TX_STATUS remains like it is now, the functionality will always be
as expected from our API.
> Now, I can also see how this can be useful for debugging, but it feels
> to me like this should be a driver (debug) option?
>
We could also achieve the functionality by modifying the drivers but this
would mean that we had to add this functionality to every driver.
Moreover, the feature of TX status frames, how it is implemented currently
for monitor mode interfaces, is part of the mac80211 implementation. The
decision to force TX status frames for monitor mode interfaces is made in
the common mac80211 implementation.
> johannes
>
Once again, thanks for your comments. We appreciate your response.
Julius and Charlie
[1] https://warmcat.com/git/packetspammer
^ permalink raw reply
* Re: [PATCH 03/21] wil6210: support up to 20 stations in AP mode
From: Kalle Valo @ 2019-02-28 9:17 UTC (permalink / raw)
To: Maya Erez; +Cc: Ahmad Masri, linux-wireless, wil6210
In-Reply-To: <1550845279-16103-4-git-send-email-merez@codeaurora.org>
Maya Erez <merez@codeaurora.org> writes:
> From: Ahmad Masri <amasri@codeaurora.org>
>
> New FW added support for upto 20 clients in AP mode. Change the driver
> to support this as well. FW reports it's max supported associations in
> WMI_READY_EVENT. Some WMI commands/events use cidxtid field which is
> limited to 16 cids. Use new cid/tid fields instead.
>
> For Rx packets cid from rx descriptor is limited to 3 bits (0..7),
> to find the real cid, compare transmitter address with the stored
> stations mac address in the driver sta array.
>
> EDMA FW still supports 8 stations. Extending the support to 20
> stations will come later.
>
> Signed-off-by: Ahmad Masri <amasri@codeaurora.org>
> Signed-off-by: Maya Erez <merez@codeaurora.org>
[...]
> --- a/drivers/net/wireless/ath/wil6210/wmi.c
> +++ b/drivers/net/wireless/ath/wil6210/wmi.c
> @@ -24,8 +24,9 @@
> #include "wmi.h"
> #include "trace.h"
>
> -static uint max_assoc_sta = WIL6210_MAX_CID;
> -module_param(max_assoc_sta, uint, 0644);
> +/* set the default max assoc sta to max supported by driver */
> +uint max_assoc_sta = WIL6210_MAX_CID;
> +module_param(max_assoc_sta, uint, 0444);
> MODULE_PARM_DESC(max_assoc_sta, " Max number of stations associated to the AP");
>
> int agg_wsize; /* = 0; */
> @@ -770,6 +771,7 @@ static void wmi_evt_ready(struct wil6210_vif *vif, int id, void *d, int len)
> struct wil6210_priv *wil = vif_to_wil(vif);
> struct wiphy *wiphy = wil_to_wiphy(wil);
> struct wmi_ready_event *evt = d;
> + u8 fw_max_assoc_sta;
>
> wil_info(wil, "FW ver. %s(SW %d); MAC %pM; %d MID's\n",
> wil->fw_version, le32_to_cpu(evt->sw_version),
> @@ -787,6 +789,25 @@ static void wmi_evt_ready(struct wil6210_vif *vif, int id, void *d, int len)
> evt->rfc_read_calib_result);
> wil->fw_calib_result = evt->rfc_read_calib_result;
> }
> +
> + fw_max_assoc_sta = WIL6210_RX_DESC_MAX_CID;
> + if (len > offsetof(struct wmi_ready_event, max_assoc_sta) &&
> + evt->max_assoc_sta > 0) {
> + fw_max_assoc_sta = evt->max_assoc_sta;
> + wil_dbg_wmi(wil, "fw reported max assoc sta %d\n",
> + fw_max_assoc_sta);
> +
> + if (fw_max_assoc_sta > WIL6210_MAX_CID) {
> + wil_dbg_wmi(wil,
> + "fw max assoc sta %d exceeds max driver supported %d\n",
> + fw_max_assoc_sta, WIL6210_MAX_CID);
> + fw_max_assoc_sta = WIL6210_MAX_CID;
> + }
> + }
> +
> + max_assoc_sta = min_t(uint, max_assoc_sta, fw_max_assoc_sta);
You shouldn't modify max_assoc_sta like this. If you have two wil6210
devices on the same host they will share that variable and there's a
race condition. Sure, I guess currently they will use the same firmware
so the values will be the same, but still this is a bug. I think you
should have wil->max_assoc_sta to make this device specific value.
I'll apply this anyway as it breaks all other patches if I remove this
patch. But please fix this in a follow up patch.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 01/21] wil6210: remove rtap_include_phy_info module param
From: Kalle Valo @ 2019-02-28 9:25 UTC (permalink / raw)
To: Maya Erez; +Cc: Maya Erez, linux-wireless, wil6210
In-Reply-To: <1550845279-16103-2-git-send-email-merez@codeaurora.org>
Maya Erez <merez@codeaurora.org> wrote:
> Due to a HW issue in PHY info collection rtap_include_phy_info is not
> in use, hence can be removed.
>
> Signed-off-by: Maya Erez <merez@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
7 patches applied to ath-next branch of ath.git, thanks.
387f3794b8cf wil6210: remove rtap_include_phy_info module param
0439a5e035f7 wil6210: add option to drop Tx packets when Tx ring is full
bf0353a67491 wil6210: support up to 20 stations in AP mode
6d1ba32c8070 wil6210: accessing 802.3 addresses via utility functions
a380eb5736c0 wil6210: fix invalid sta statistics update
979c9d8d01c4 wil6210: ignore HALP ICR if already handled
de77a53c2d1e wil6210: check null pointer in _wil_cfg80211_merge_extra_ies
--
https://patchwork.kernel.org/patch/10826101/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [RFC 07/12] mt76x02: fix hdr pointer in write txwi for USB
From: Lorenzo Bianconi @ 2019-02-28 9:38 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Felix Fietkau, linux-wireless
In-Reply-To: <1551341013-24519-8-git-send-email-sgruszka@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1284 bytes --]
> Since we add txwi at the begining of skb->data, it no longer point
> to ieee80211_hdr. This breaks settings TS bit for probe response and
> beacons.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> ---
> drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c b/drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c
> index fdd6a021914d..bcf3126efda9 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c
> @@ -85,8 +85,9 @@ int mt76x02u_tx_prepare_skb(struct mt76_dev *mdev, void *data,
>
> mt76x02_insert_hdr_pad(skb);
>
> - txwi = skb_push(skb, sizeof(struct mt76x02_txwi));
> + txwi = (struct mt76x02_txwi *)(skb->data - sizeof(struct mt76x02_txwi));
> mt76x02_mac_write_txwi(dev, txwi, skb, wcid, sta, len);
> + skb_push(skb, sizeof(struct mt76x02_txwi));
>
> pid = mt76_tx_status_skb_add(mdev, wcid, skb);
> txwi->pktid = pid;
> --
> 2.20.1
>
Good catch :)
I think we should post it ontop of wireless-drivers since sw encryption is not
working now.
Acked-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PING] [PATCH v5 1/7] nfc: pn533: i2c: "pn532" as dt compatible string
From: Lars Poeschel @ 2019-02-28 10:48 UTC (permalink / raw)
To: devicetree, Samuel Ortiz, open list:NFC SUBSYSTEM, open list; +Cc: Johan Hovold
In-Reply-To: <20190111161812.26325-1-poeschel@lemonage.de>
A gentle ping on this whole patch series.
Regards,
Lars
On Fri, Jan 11, 2019 at 05:18:04PM +0100, Lars Poeschel wrote:
> It is favourable to have one unified compatible string for devices that
> have multiple interfaces. So this adds simply "pn532" as the devicetree
> binding compatible string and makes a note that the old ones are
> deprecated.
>
> Cc: Johan Hovold <johan@kernel.org>
> Signed-off-by: Lars Poeschel <poeschel@lemonage.de>
> ---
> Changes in v3:
> - This patch is new in v3
>
> drivers/nfc/pn533/i2c.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/nfc/pn533/i2c.c b/drivers/nfc/pn533/i2c.c
> index 4389eb4c8d0b..f4eae9dd5305 100644
> --- a/drivers/nfc/pn533/i2c.c
> +++ b/drivers/nfc/pn533/i2c.c
> @@ -258,6 +258,11 @@ static int pn533_i2c_remove(struct i2c_client *client)
> }
>
> static const struct of_device_id of_pn533_i2c_match[] = {
> + { .compatible = "nxp,pn532", },
> + /*
> + * NOTE: The use of the compatibles with the trailing "...-i2c" is
> + * deprecated and will be removed.
> + */
> { .compatible = "nxp,pn533-i2c", },
> { .compatible = "nxp,pn532-i2c", },
> {},
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCH 03/21] wil6210: support up to 20 stations in AP mode
From: merez @ 2019-02-28 10:36 UTC (permalink / raw)
To: Kalle Valo; +Cc: Ahmad Masri, linux-wireless, wil6210
In-Reply-To: <87va14z2zg.fsf@purkki.adurom.net>
On 2019-02-28 11:17, Kalle Valo wrote:
> Maya Erez <merez@codeaurora.org> writes:
>
>> From: Ahmad Masri <amasri@codeaurora.org>
>>
>> +
>> + max_assoc_sta = min_t(uint, max_assoc_sta, fw_max_assoc_sta);
>
> You shouldn't modify max_assoc_sta like this. If you have two wil6210
> devices on the same host they will share that variable and there's a
> race condition. Sure, I guess currently they will use the same firmware
> so the values will be the same, but still this is a bug. I think you
> should have wil->max_assoc_sta to make this device specific value.
>
> I'll apply this anyway as it breaks all other patches if I remove this
> patch. But please fix this in a follow up patch.
we'll fix that.
--
Maya Erez
Qualcomm Israel, Inc. on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
^ 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