* [PATCH v3 2/2] mt76: mt7615: fix slow performance when enable encryption
From: Ryder Lee @ 2019-06-03 6:08 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi
Cc: Roy Luo, YF Luo, Yiwei Chung, Sean Wang, Chih-Min Chen,
linux-wireless, linux-mediatek, linux-kernel, Ryder Lee
In-Reply-To: <a1ff446dfc06e2443552e7ec2d754099aacce7df.1559541944.git.ryder.lee@mediatek.com>
Fix wrong WCID assignment and add RKV (RX Key of this entry is valid)
flag to check if peer uses the same configuration with previous
handshaking.
If the configuration is mismatch, WTBL indicates a “cipher mismatch”
to stop SEC decryption to prevent the packet from damage.
Suggested-by: YF Luo <yf.luo@mediatek.com>
Suggested-by: Yiwei Chung <yiwei.chung@mediatek.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
---
Changes since v3 - none
Changes since v2 - none
---
drivers/net/wireless/mediatek/mt76/mt7615/init.c | 16 ++++++++++------
drivers/net/wireless/mediatek/mt76/mt7615/main.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 1 +
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
index f860af6a42da..b3e08154ccbe 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
@@ -62,16 +62,11 @@ static void mt7615_mac_init(struct mt7615_dev *dev)
MT_AGG_ARCR_RATE_DOWN_RATIO_EN |
FIELD_PREP(MT_AGG_ARCR_RATE_DOWN_RATIO, 1) |
FIELD_PREP(MT_AGG_ARCR_RATE_UP_EXTRA_TH, 4)));
-
- dev->mt76.global_wcid.idx = MT7615_WTBL_RESERVED;
- dev->mt76.global_wcid.hw_key_idx = -1;
- rcu_assign_pointer(dev->mt76.wcid[MT7615_WTBL_RESERVED],
- &dev->mt76.global_wcid);
}
static int mt7615_init_hardware(struct mt7615_dev *dev)
{
- int ret;
+ int ret, idx;
mt76_wr(dev, MT_INT_SOURCE_CSR, ~0);
@@ -98,6 +93,15 @@ static int mt7615_init_hardware(struct mt7615_dev *dev)
mt7615_mcu_ctrl_pm_state(dev, 0);
mt7615_mcu_del_wtbl_all(dev);
+ /* Beacon and mgmt frames should occupy wcid 0 */
+ idx = mt76_wcid_alloc(dev->mt76.wcid_mask, MT7615_WTBL_STA - 1);
+ if (idx)
+ return -ENOSPC;
+
+ dev->mt76.global_wcid.idx = idx;
+ dev->mt76.global_wcid.hw_key_idx = -1;
+ rcu_assign_pointer(dev->mt76.wcid[idx], &dev->mt76.global_wcid);
+
return 0;
}
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
index 585e67fa2728..2cdd339453c8 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -95,7 +95,7 @@ static int mt7615_add_interface(struct ieee80211_hw *hw,
dev->vif_mask |= BIT(mvif->idx);
dev->omac_mask |= BIT(mvif->omac_idx);
- idx = MT7615_WTBL_RESERVED - 1 - mvif->idx;
+ idx = MT7615_WTBL_RESERVED - mvif->idx;
mvif->sta.wcid.idx = idx;
mvif->sta.wcid.hw_key_idx = -1;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index e82297048449..b3802f18b37b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -882,6 +882,7 @@ int mt7615_mcu_set_wtbl_key(struct mt7615_dev *dev, int wcid,
if (cipher == MT_CIPHER_NONE && key)
return -EOPNOTSUPP;
+ req.key.rkv = 1;
req.key.cipher_id = cipher;
req.key.key_id = key->keyidx;
req.key.key_len = key->keylen;
--
2.18.0
^ permalink raw reply related
* Re: [EXT] INFO: trying to register non-static key in del_timer_sync (2)
From: Dmitry Vyukov @ 2019-06-03 5:20 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: syzbot, amitkarwar@gmail.com, andreyknvl@google.com,
davem@davemloft.net, huxinming820@gmail.com, kvalo@codeaurora.org,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
nishants@marvell.com, syzkaller-bugs@googlegroups.com
In-Reply-To: <MN2PR18MB263783F52CAD4A335FD8BB34A01A0@MN2PR18MB2637.namprd18.prod.outlook.com>
On Sat, Jun 1, 2019 at 7:52 PM Ganapathi Bhat <gbhat@marvell.com> wrote:
>
> Hi syzbot,
>
> >
> > syzbot found the following crash on:
> >
> As per the link(https://syzkaller.appspot.com/bug?extid=dc4127f950da51639216), the issue is fixed; Is it OK? Let us know if we need to do something?
Hi Ganapathi,
The "fixed" status relates to the similar past bug that was reported
and fixed more than a year ago:
https://groups.google.com/forum/#!msg/syzkaller-bugs/3YnGX1chF2w/jeQjeihtBAAJ
https://syzkaller.appspot.com/bug?id=b4b5c74c57c4b69f4fff86131abb799106182749
This one is still well alive and kicking, with 1200+ crashes and the
last one happened less then 30min ago.
^ permalink raw reply
* Re: [PATCH v2 1/2] mt76: mt7615: enable support for mesh
From: Ryder Lee @ 2019-06-02 14:36 UTC (permalink / raw)
To: Felix Fietkau
Cc: Lorenzo Bianconi, Roy Luo, YF Luo, Yiwei Chung, Sean Wang,
Chih-Min Chen, linux-wireless, linux-mediatek, linux-kernel
In-Reply-To: <e459fbc79154da9e0e6e098d2c49a9b17e842f47.1559301203.git.ryder.lee@mediatek.com>
On Fri, 2019-05-31 at 22:09 +0800, Ryder Lee wrote:
> Enable NL80211_IFTYPE_MESH_POINT and update its path.
>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> ---
> Changes since v2 - remove unused definitions
> ---
> drivers/net/wireless/mediatek/mt76/mt7615/init.c | 6 ++++++
> drivers/net/wireless/mediatek/mt76/mt7615/main.c | 1 +
> drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 5 ++++-
> drivers/net/wireless/mediatek/mt76/mt7615/mcu.h | 6 ------
> 4 files changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
> index 59f604f3161f..f860af6a42da 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
> @@ -133,6 +133,9 @@ static const struct ieee80211_iface_limit if_limits[] = {
> {
> .max = MT7615_MAX_INTERFACES,
> .types = BIT(NL80211_IFTYPE_AP) |
> +#ifdef CONFIG_MAC80211_MESH
> + BIT(NL80211_IFTYPE_MESH_POINT) |
> +#endif
> BIT(NL80211_IFTYPE_STATION)
> }
> };
> @@ -195,6 +198,9 @@ int mt7615_register_device(struct mt7615_dev *dev)
> dev->mt76.antenna_mask = 0xf;
>
> wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
> +#ifdef CONFIG_MAC80211_MESH
> + BIT(NL80211_IFTYPE_MESH_POINT) |
> +#endif
> BIT(NL80211_IFTYPE_AP);
>
> ret = mt76_register_device(&dev->mt76, true, mt7615_rates,
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
> index b0bb7cc12385..585e67fa2728 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
> @@ -37,6 +37,7 @@ static int get_omac_idx(enum nl80211_iftype type, u32 mask)
>
> switch (type) {
> case NL80211_IFTYPE_AP:
> + case NL80211_IFTYPE_MESH_POINT:
> /* ap use hw bssid 0 and ext bssid */
> if (~mask & BIT(HW_BSSID_0))
> return HW_BSSID_0;
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> index 43f70195244c..8b8db526cb16 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> @@ -754,6 +754,7 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev,
>
> switch (vif->type) {
> case NL80211_IFTYPE_AP:
> + case NL80211_IFTYPE_MESH_POINT:
> tx_wlan_idx = mvif->sta.wcid.idx;
> conn_type = CONNECTION_INFRA_AP;
> break;
> @@ -968,7 +969,8 @@ int mt7615_mcu_add_wtbl(struct mt7615_dev *dev, struct ieee80211_vif *vif,
> .rx_wtbl = {
> .tag = cpu_to_le16(WTBL_RX),
> .len = cpu_to_le16(sizeof(struct wtbl_rx)),
> - .rca1 = vif->type != NL80211_IFTYPE_AP,
> + .rca1 = vif->type != (NL80211_IFTYPE_AP ||
> + NL80211_IFTYPE_MESH_POINT),
Oops, this expression is wrong. I will fix it in v3.
Sorry for the inconvenience.
Ryder
^ permalink raw reply
* Re: [RFC PATCH] ath9k: integrate AR92XX pci fixup code
From: Julian Calaby @ 2019-06-02 14:11 UTC (permalink / raw)
To: Christian Lamparter
Cc: QCA ath9k Development, linux-wireless, Hauke Mehrtens,
Martin Blumenstingl
In-Reply-To: <2349614.IEgcWBM518@debian64>
Hi Christian,
On Sun, Jun 2, 2019 at 11:14 PM Christian Lamparter <chunkeey@gmail.com> wrote:
>
> Hello Julian,
>
> On Sunday, June 2, 2019 1:43:52 PM CEST Julian Calaby wrote:
> > On Sun, Jun 2, 2019 at 8:24 PM Christian Lamparter <chunkeey@gmail.com> wrote:
> > >
> > > Some devices (like the Cisco Meraki Z1 Cloud Managed Teleworker Gateway)
> > > need to be able to initialize the PCIe wifi device. Normally, this is done
> > > during the early stages of booting linux, because the necessary init code
> > > is read from the memory mapped SPI and passed to pci_enable_ath9k_fixup.
> > > However, this isn't possible for devices which have the init code for the
> > > Atheros chip stored on NAND in an UBI volume. Hence, this module can be
> > > used to initialize the chip when the user-space is ready to extract the
> > > init code.
> > >
> > > Martin Blumenstingl prodived the following fixes:
> > > owl-loader: add support for OWL emulation PCI devices
> > > owl-loader: don't re-scan the bus when ath9k_pci_fixup failed
> > > owl-loader: use dev_* instead of pr_* logging functions
> > > owl-loader: auto-generate the eeprom filename as fallback
> > > owl-loader: add a debug message when swapping the eeprom data
> > > owl-loader: add missing newlines in log messages
> > >
> > > Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> > > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> >
> > Two questions:
> >
> > 1. This seems complicated enough that the functions introduced should
> > probably go into a separate .c file, maybe "noeeprom.c", with a header
> > file with all the ifdef / config magic in it.
>
> In openwrt we called it owl-loader.c and it's a separate module there.
> But I don't think that noeeprom.c is that great since ath9k also supports
> AHB and htc_usb, so from this perspective it would mean:
> pci_init_noeeprom.c ? (As AR5008, AR9160 and AR92XX seem to be affected).
Fair enough, I hadn't thought of the other buses.
> > 2. This smells almost like a completely separate PCI(e) driver for
> > cards in a "weird" state.
> It's in the Datasheet that the device initializes into this state. See
> AR9280 6.1.2 DEVICE_ID. "... if the EEPROM content is not valid, a
> value of 0XFF1C returns when read from the register". This would also
> mean that this routine can be used to resurrect aging AR9280 cards
> that have a failed eeprom or are from APPLE, see this thread:
>
> <https://www.mail-archive.com/ath9k-devel@lists.ath9k.org/msg03918.html>
>
> "does anyone know whether 168c:ff1c can be supported by the current ath9k
> driver? It isn't listed with the PCI IDs in the source. I bought it off
> eBay as "Apple" AR5008. It is a PCI Express card with 3 Antenna
> connectors and lots of Apple stampings on it. lspci says:"
I'm asking because (I think) Ath3k Bluetooth devices initialise with
one device ID when they don't have firmware, then initialise with a
different one once they do. These two states are handled using
different drivers. This seems like almost identical behaviour and
looks like it could be handled the same way. The code here looks like
it's just using the common boilerplate pci device initialisation code
from ath9k before doing it's own completely separate thing including
having PCI driver data in a different format to the rest of the ath9k
driver.
> > Is there anything you're using from ath9k
> > other than the eeprom file naming? and is that really useful? Won't
> > the eeprom files be device specific and therefore could always use the
> > device name fallback?
> Please take a look at the commit message. Unfortunately the Z1 stores
> its calibration data in a ubi volume, these can't be easily read
> without interfacing with either ubi or the vfs. In the future, simpler
> devices that have it on SPI-NOR in a mtd partition can setup a nvmem
> provider and the code can have a nvmem-consumer. (see attached patch).
Fair enough, I was reading the code as-is, not looking forward to
other possibilities.
> Note: There are also devices with mutliple ath9k pci(e) chips
> (usually one 2.4Ghz and one 5GHz), so a generic "ath9k" name is too
> short and the pciids of both are the same. That's why the pci-bus
> location is currently used for the eeprom name identifier.
I've finally worked out what was bothering me about the code: you look
at the platform data expecting it to be in the ath9k_platform_data
structure, however as far as I can tell, the platform data is only
ever set by reading the eeprom, which doesn't happen when there isn't
one, therefore the eeprom name retrieval will always fall back to
dev_name(). I'm assuming that dev_name() returns something
sufficiently unique to identify multiple different cards in a system.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: iwl_mvm_add_new_dqa_stream_wk BUG in lib/list_debug.c:56
From: Marc Haber @ 2019-06-02 13:48 UTC (permalink / raw)
To: linux-kernel, linux-wireless, netdev
In-Reply-To: <20190530081257.GA26133@torres.zugschlus.de>
On Thu, May 30, 2019 at 10:12:57AM +0200, Marc Haber wrote:
> on my primary notebook, a Lenovo X260, with an Intel Wireless 8260
> (8086:24f3), running Debian unstable, I have started to see network
> hangs since upgrading to kernel 5.1. In this situation, I cannot
> restart Network-Manager (the call just hangs), I can log out of X, but
> the system does not cleanly shut down and I need to Magic SysRq myself
> out of the running system. This happens about once every two days.
The issue is also present in 5.1.5 and 5.1.6.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply
* Re: [RFC PATCH] ath9k: integrate AR92XX pci fixup code
From: Christian Lamparter @ 2019-06-02 13:14 UTC (permalink / raw)
To: Julian Calaby
Cc: QCA ath9k Development, linux-wireless, Hauke Mehrtens,
Martin Blumenstingl
In-Reply-To: <CAGRGNgXqB=5oi1Nq4ZNSk3csOEr4A6WgN8QymKMriTcevnKUQw@mail.gmail.com>
Hello Julian,
On Sunday, June 2, 2019 1:43:52 PM CEST Julian Calaby wrote:
> On Sun, Jun 2, 2019 at 8:24 PM Christian Lamparter <chunkeey@gmail.com> wrote:
> >
> > Some devices (like the Cisco Meraki Z1 Cloud Managed Teleworker Gateway)
> > need to be able to initialize the PCIe wifi device. Normally, this is done
> > during the early stages of booting linux, because the necessary init code
> > is read from the memory mapped SPI and passed to pci_enable_ath9k_fixup.
> > However, this isn't possible for devices which have the init code for the
> > Atheros chip stored on NAND in an UBI volume. Hence, this module can be
> > used to initialize the chip when the user-space is ready to extract the
> > init code.
> >
> > Martin Blumenstingl prodived the following fixes:
> > owl-loader: add support for OWL emulation PCI devices
> > owl-loader: don't re-scan the bus when ath9k_pci_fixup failed
> > owl-loader: use dev_* instead of pr_* logging functions
> > owl-loader: auto-generate the eeprom filename as fallback
> > owl-loader: add a debug message when swapping the eeprom data
> > owl-loader: add missing newlines in log messages
> >
> > Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>
> Two questions:
>
> 1. This seems complicated enough that the functions introduced should
> probably go into a separate .c file, maybe "noeeprom.c", with a header
> file with all the ifdef / config magic in it.
In openwrt we called it owl-loader.c and it's a separate module there.
But I don't think that noeeprom.c is that great since ath9k also supports
AHB and htc_usb, so from this perspective it would mean:
pci_init_noeeprom.c ? (As AR5008, AR9160 and AR92XX seem to be affected).
> 2. This smells almost like a completely separate PCI(e) driver for
> cards in a "weird" state.
It's in the Datasheet that the device initializes into this state. See
AR9280 6.1.2 DEVICE_ID. "... if the EEPROM content is not valid, a
value of 0XFF1C returns when read from the register". This would also
mean that this routine can be used to resurrect aging AR9280 cards
that have a failed eeprom or are from APPLE, see this thread:
<https://www.mail-archive.com/ath9k-devel@lists.ath9k.org/msg03918.html>
"does anyone know whether 168c:ff1c can be supported by the current ath9k
driver? It isn't listed with the PCI IDs in the source. I bought it off
eBay as "Apple" AR5008. It is a PCI Express card with 3 Antenna
connectors and lots of Apple stampings on it. lspci says:"
> Is there anything you're using from ath9k
> other than the eeprom file naming? and is that really useful? Won't
> the eeprom files be device specific and therefore could always use the
> device name fallback?
Please take a look at the commit message. Unfortunately the Z1 stores
its calibration data in a ubi volume, these can't be easily read
without interfacing with either ubi or the vfs. In the future, simpler
devices that have it on SPI-NOR in a mtd partition can setup a nvmem
provider and the code can have a nvmem-consumer. (see attached patch).
Note: There are also devices with mutliple ath9k pci(e) chips
(usually one 2.4Ghz and one 5GHz), so a generic "ath9k" name is too
short and the pciids of both are the same. That's why the pci-bus
location is currently used for the eeprom name identifier.
Regards,
Christian
---
Note: nvmem dts is not finalized. See
commit 517f14d9cf3533d5ab4fded195ab6f80a92e378f
Author: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Date: Fri Nov 30 11:53:25 2018 +0000
nvmem: add new config option
for details why adding something like this unfinished patch
just does not makes sense (yet).
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -21,6 +21,7 @@
#include <linux/module.h>
#include <linux/firmware.h>
#include <linux/completion.h>
+#include <linux/nvmem-consumer.h>
#include <linux/ath9k_platform.h>
#include "ath9k.h"
#include "eeprom.h"
@@ -1053,6 +1054,7 @@ static int ath_pci_fixup_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
struct ath_pci_fixup_ctx *ctx;
+ struct nvmem_cell *cell;
const char *eeprom_name;
int err = 0;
@@ -1062,6 +1064,21 @@ static int ath_pci_fixup_probe(struct pci_dev *pdev,
pcim_pin_device(pdev);
+ cell = nvmem_cell_get(&pdev->dev, "caldata");
+ if (!IS_ERR(cell)) {
+ void *value;
+ size_t len;
+
+ value = nvmem_cell_read(cell, &len);
+ if (!IS_ERR(value)) {
+ err = ath_pci_fixup(pdev, value, len);
+ kfree(value);
+ } else
+ err = -EINVAL;
+ nvmem_cell_put(cell);
+ return err;
+ }
+
eeprom_name = ath_pci_fixup_get_eeprom_name(pdev);
if (!eeprom_name) {
dev_err(&pdev->dev, "no eeprom filename found.\n");
^ permalink raw reply
* Re: [RFC PATCH] ath9k: integrate AR92XX pci fixup code
From: Julian Calaby @ 2019-06-02 11:43 UTC (permalink / raw)
To: Christian Lamparter
Cc: QCA ath9k Development, linux-wireless, Hauke Mehrtens,
Martin Blumenstingl
In-Reply-To: <20190602102144.17360-1-chunkeey@gmail.com>
Hi Christian,
On Sun, Jun 2, 2019 at 8:24 PM Christian Lamparter <chunkeey@gmail.com> wrote:
>
> Some devices (like the Cisco Meraki Z1 Cloud Managed Teleworker Gateway)
> need to be able to initialize the PCIe wifi device. Normally, this is done
> during the early stages of booting linux, because the necessary init code
> is read from the memory mapped SPI and passed to pci_enable_ath9k_fixup.
> However, this isn't possible for devices which have the init code for the
> Atheros chip stored on NAND in an UBI volume. Hence, this module can be
> used to initialize the chip when the user-space is ready to extract the
> init code.
>
> Martin Blumenstingl prodived the following fixes:
> owl-loader: add support for OWL emulation PCI devices
> owl-loader: don't re-scan the bus when ath9k_pci_fixup failed
> owl-loader: use dev_* instead of pr_* logging functions
> owl-loader: auto-generate the eeprom filename as fallback
> owl-loader: add a debug message when swapping the eeprom data
> owl-loader: add missing newlines in log messages
>
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Two questions:
1. This seems complicated enough that the functions introduced should
probably go into a separate .c file, maybe "noeeprom.c", with a header
file with all the ifdef / config magic in it.
2. This smells almost like a completely separate PCI(e) driver for
cards in a "weird" state. Is there anything you're using from ath9k
other than the eeprom file naming? and is that really useful? Won't
the eeprom files be device specific and therefore could always use the
device name fallback?
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* [RFC PATCH] ath9k: integrate AR92XX pci fixup code
From: Christian Lamparter @ 2019-06-02 10:21 UTC (permalink / raw)
To: QCA ath9k Development, linux-wireless; +Cc: Hauke Mehrtens, Martin Blumenstingl
Some devices (like the Cisco Meraki Z1 Cloud Managed Teleworker Gateway)
need to be able to initialize the PCIe wifi device. Normally, this is done
during the early stages of booting linux, because the necessary init code
is read from the memory mapped SPI and passed to pci_enable_ath9k_fixup.
However, this isn't possible for devices which have the init code for the
Atheros chip stored on NAND in an UBI volume. Hence, this module can be
used to initialize the chip when the user-space is ready to extract the
init code.
Martin Blumenstingl prodived the following fixes:
owl-loader: add support for OWL emulation PCI devices
owl-loader: don't re-scan the bus when ath9k_pci_fixup failed
owl-loader: use dev_* instead of pr_* logging functions
owl-loader: auto-generate the eeprom filename as fallback
owl-loader: add a debug message when swapping the eeprom data
owl-loader: add missing newlines in log messages
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
drivers/net/wireless/ath/ath9k/Kconfig | 15 ++
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/pci.c | 252 ++++++++++++++++++++++++-
3 files changed, 266 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig
index a1ef8769983a..25b791389816 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -157,6 +157,21 @@ config ATH9K_PCOEM
depends on ATH9K
default y
+config ATH9K_PCI_NO_EEPROM
+ bool "Atheros ath9k support for EEPROM-less chips"
+ depends on ATH9K_PCI
+ default n
+ help
+ Say Y to support AR92XX-generation of ath9k PCI(e) WiFi chips, which
+ have their initialization data (which contains the PCI Device ID!)
+ stored together with the calibration data out of reach for the ath9k
+ chip.
+
+ These devices are usually various network appliances, routers or
+ access Points and such.
+
+ If unsure say N.
+
config ATH9K_HTC
tristate "Atheros HTC based wireless cards support"
depends on USB && MAC80211
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index a412b352182c..ec649446421b 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -959,6 +959,7 @@ void ath_ant_comb_scan(struct ath_softc *sc, struct ath_rx_status *rs);
#define ATH9K_PCI_NO_PLL_PWRSAVE 0x0200
#define ATH9K_PCI_KILLER 0x0400
#define ATH9K_PCI_LED_ACT_HI 0x0800
+#define ATH9K_PCI_NO_EEPROM 0x1000
/*
* Default cache line size, in bytes.
diff --git a/drivers/net/wireless/ath/ath9k/pci.c b/drivers/net/wireless/ath/ath9k/pci.c
index 92b2dd396436..53a16e961055 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -19,7 +19,11 @@
#include <linux/nl80211.h>
#include <linux/pci.h>
#include <linux/module.h>
+#include <linux/firmware.h>
+#include <linux/completion.h>
+#include <linux/ath9k_platform.h>
#include "ath9k.h"
+#include "eeprom.h"
extern int ath9k_use_msi;
@@ -774,6 +778,17 @@ static const struct pci_device_id ath_pci_id_table[] = {
.driver_data = ATH9K_PCI_BT_ANT_DIV },
#endif
+#ifdef CONFIG_ATH9K_PCI_NO_EEPROM
+ /* If a physical EEPROM or OTP is not used (such as for an integrated
+ * access point), the device responds to bus probing with default
+ * hardware deviceID and subvendorDeviceID information.
+ */
+ { PCI_VDEVICE(ATHEROS, 0xff1c),
+ .driver_data = ATH9K_PCI_NO_EEPROM }, /* PCIe */
+ { PCI_VDEVICE(ATHEROS, 0xff1d),
+ .driver_data = ATH9K_PCI_NO_EEPROM }, /* PCI */
+#endif /* CONFIG_ATH9K_PCI_NO_EEPROM */
+
{ 0 }
};
@@ -882,6 +897,228 @@ static const struct ath_bus_ops ath_pci_bus_ops = {
.aspm_init = ath_pci_aspm_init,
};
+#ifdef CONFIG_ATH9K_PCI_NO_EEPROM
+
+struct ath_pci_fixup_ctx {
+ struct completion eeprom_load;
+};
+
+#define EEPROM_FILENAME_LEN 100
+/* AR5416_EEPROM_MAGIC changes depending on target endian */
+#define ATH_PCI_FIXUP_MAGIC 0xa55a
+
+static int ath_pci_fixup(struct pci_dev *pdev, const u16 *cal_data,
+ size_t cal_len)
+{
+ void __iomem *mem;
+ const void *cal_end = (void *)cal_data + cal_len;
+ const struct {
+ u16 reg;
+ u16 low_val;
+ u16 high_val;
+ } __packed * data;
+ u16 cmd;
+ u32 bar0;
+ bool swap_needed = false;
+
+ if (*cal_data != ATH_PCI_FIXUP_MAGIC) {
+ if (*cal_data != swab16(ATH_PCI_FIXUP_MAGIC)) {
+ dev_err(&pdev->dev, "invalid calibration data\n");
+ return -EINVAL;
+ }
+
+ dev_dbg(&pdev->dev, "calibration data needs swapping\n");
+ swap_needed = true;
+ }
+
+ dev_info(&pdev->dev, "fixup device configuration\n");
+
+ mem = pcim_iomap(pdev, 0, 0);
+ if (!mem) {
+ dev_err(&pdev->dev, "ioremap error\n");
+ return -EINVAL;
+ }
+
+ pci_read_config_dword(pdev, PCI_BASE_ADDRESS_0, &bar0);
+ pci_write_config_dword(pdev, PCI_BASE_ADDRESS_0,
+ pci_resource_start(pdev, 0));
+ pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+ cmd |= PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY;
+ pci_write_config_word(pdev, PCI_COMMAND, cmd);
+
+ /* set pointer to first reg address */
+ for (data = (const void *)(cal_data + 3);
+ (const void *)data <= cal_end && data->reg != (u16)~0;
+ data++) {
+ u32 val;
+ u16 reg;
+
+ reg = data->reg;
+ val = data->low_val;
+ val |= ((u32)data->high_val) << 16;
+
+ if (swap_needed) {
+ reg = swab16(reg);
+ val = swahb32(val);
+ }
+
+ __raw_writel(val, mem + reg);
+ usleep_range(100, 120);
+ }
+
+ pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+ cmd &= ~(PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY);
+ pci_write_config_word(pdev, PCI_COMMAND, cmd);
+
+ pci_write_config_dword(pdev, PCI_BASE_ADDRESS_0, bar0);
+ pcim_iounmap(pdev, mem);
+
+ pci_disable_device(pdev);
+
+ return 0;
+}
+
+static void ath_pci_fixup_fw_cb(const struct firmware *fw, void *context)
+{
+ struct pci_dev *pdev = (struct pci_dev *)context;
+ struct ath_pci_fixup_ctx *ctx;
+ struct ath9k_platform_data *pdata = dev_get_platdata(&pdev->dev);
+ struct pci_bus *bus;
+
+ ctx = (struct ath_pci_fixup_ctx *)pci_get_drvdata(pdev);
+ complete(&ctx->eeprom_load);
+
+ if (!fw) {
+ dev_err(&pdev->dev, "no eeprom data received.\n");
+ goto release;
+ }
+
+ /* also note that we are doing *u16 operations on the file */
+ if (fw->size > sizeof(pdata->eeprom_data) || fw->size < 0x200 ||
+ (fw->size & 1) == 1) {
+ dev_err(&pdev->dev, "eeprom file has an invalid size.\n");
+ goto release;
+ }
+
+ if (pdata) {
+ memcpy(pdata->eeprom_data, fw->data, fw->size);
+
+ /* eeprom has been successfully loaded - pass the data to ath9k
+ * but remove the eeprom_name, so it doesn't try to load it too.
+ */
+ pdata->eeprom_name = NULL;
+ }
+
+ if (ath_pci_fixup(pdev, (const u16 *)fw->data, fw->size))
+ goto release;
+
+ pci_lock_rescan_remove();
+ bus = pdev->bus;
+ pci_stop_and_remove_bus_device(pdev);
+ /* the device should come back with the proper
+ * ProductId. But we have to initiate a rescan.
+ */
+ pci_rescan_bus(bus);
+ pci_unlock_rescan_remove();
+
+release:
+ release_firmware(fw);
+}
+
+static const char *ath_pci_fixup_get_eeprom_name(struct pci_dev *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct ath9k_platform_data *pdata;
+ char *eeprom_name;
+
+ /* try the existing platform data first */
+ pdata = dev_get_platdata(dev);
+ if (pdata && pdata->eeprom_name)
+ return pdata->eeprom_name;
+
+ dev_dbg(dev, "using auto-generated eeprom filename\n");
+
+ eeprom_name = devm_kzalloc(dev, EEPROM_FILENAME_LEN, GFP_KERNEL);
+ if (!eeprom_name)
+ return NULL;
+
+ /* this should match the pattern used in init.c */
+ scnprintf(eeprom_name, EEPROM_FILENAME_LEN, "ath9k-eeprom-pci-%s.bin",
+ dev_name(dev));
+
+ return eeprom_name;
+}
+
+static int ath_pci_fixup_probe(struct pci_dev *pdev,
+ const struct pci_device_id *id)
+{
+ struct ath_pci_fixup_ctx *ctx;
+ const char *eeprom_name;
+ int err = 0;
+
+ /* only handle devices that do not have a support EEPROM */
+ if (!(id->driver_data & ATH9K_PCI_NO_EEPROM))
+ return 0;
+
+ pcim_pin_device(pdev);
+
+ eeprom_name = ath_pci_fixup_get_eeprom_name(pdev);
+ if (!eeprom_name) {
+ dev_err(&pdev->dev, "no eeprom filename found.\n");
+ return -ENODEV;
+ }
+
+ ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
+
+ init_completion(&ctx->eeprom_load);
+
+ pci_set_drvdata(pdev, ctx);
+ err = request_firmware_nowait(THIS_MODULE, true, eeprom_name,
+ &pdev->dev, GFP_KERNEL, pdev,
+ ath_pci_fixup_fw_cb);
+ if (err)
+ dev_err(&pdev->dev, "failed to request caldata (%d).\n", err);
+
+ /* Use the return code "1" as a way to tell the ath_pci_probe()
+ * function that we will be taking an alternative code-path from
+ * now on. Once the device has the proper ProductIDs it will
+ * go through ath_pci_probe() again.
+ */
+ return err < 0 ? err : 1;
+}
+
+static bool ath_pci_fixup_remove(struct pci_dev *pdev)
+{
+ const struct pci_device_id *id;
+ struct ath_pci_fixup_ctx *ctx;
+
+ id = pci_match_id(ath_pci_id_table, pdev);
+ if (!id || !(id->driver_data & ATH9K_PCI_NO_EEPROM))
+ return false;
+
+ ctx = pci_get_drvdata(pdev);
+ if (ctx) {
+ wait_for_completion(&ctx->eeprom_load);
+ pci_set_drvdata(pdev, NULL);
+ }
+
+ return true;
+}
+#else
+static int ath_pci_fixup_probe(struct pci_dev __maybe_unused *pdev,
+ const struct pci_device_id __maybe_unused *id)
+{
+ return 0;
+}
+
+static bool ath_pci_fixup_remove(struct pci_dev __maybe_unused *pdev)
+{
+ return false;
+}
+#endif /* CONFIG_ATH9K_PCI_NO_EEPROM */
+
static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
struct ath_softc *sc;
@@ -895,6 +1132,12 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
if (pcim_enable_device(pdev))
return -EIO;
+ ret = ath_pci_fixup_probe(pdev, id);
+ if (ret < 0)
+ return ret;
+ if (ret == 1)
+ return 0; /* ath_pci_fixup_probe took over */
+
ret = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
if (ret) {
pr_err("32-bit DMA not available\n");
@@ -1007,9 +1250,14 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
static void ath_pci_remove(struct pci_dev *pdev)
{
- struct ieee80211_hw *hw = pci_get_drvdata(pdev);
- struct ath_softc *sc = hw->priv;
+ struct ieee80211_hw *hw;
+ struct ath_softc *sc;
+ if (ath_pci_fixup_remove(pdev))
+ return;
+
+ hw = pci_get_drvdata(pdev);
+ sc = hw->priv;
if (!is_ath9k_unloaded)
sc->sc_ah->ah_flags |= AH_UNPLUGGED;
ath9k_deinit_device(sc);
--
2.20.1
^ permalink raw reply related
* [PATCH] carl9170: Fix misuse of device driver API
From: Christian Lamparter @ 2019-06-02 9:06 UTC (permalink / raw)
To: linux-wireless; +Cc: Kalle Valo, Alan Stern, USB list
This patch follows Alan Stern's recent patch:
"p54: Fix race between disconnect and firmware loading"
that overhauled carl9170 buggy firmware loading and driver
unbinding procedures.
Since the carl9170 code was adapted from p54 it uses the
same functions and is likely to have the same problem, but
it's just that the syzbot hasn't reproduce them (yet).
a summary from the changes (copied from the p54 patch):
* Call usb_driver_release_interface() rather than
device_release_driver().
* Lock udev (the interface's parent) before unbinding the
driver instead of locking udev->parent.
* During the firmware loading process, take a reference
to the USB interface instead of the USB device.
* Don't take an unnecessary reference to the device during
probe (and then don't drop it during disconnect).
and
* Make sure to prevent use-after-free bugs by explicitly
setting the driver context to NULL after signaling the
completion.
Cc: <stable@vger.kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
drivers/net/wireless/ath/carl9170/usb.c | 26 ++++++++++++-------------
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/ath/carl9170/usb.c b/drivers/net/wireless/ath/carl9170/usb.c
index e7c3f3b8457d..297a7b877d31 100644
--- a/drivers/net/wireless/ath/carl9170/usb.c
+++ b/drivers/net/wireless/ath/carl9170/usb.c
@@ -128,6 +128,8 @@ static const struct usb_device_id carl9170_usb_ids[] = {
};
MODULE_DEVICE_TABLE(usb, carl9170_usb_ids);
+static struct usb_driver carl9170_driver;
+
static void carl9170_usb_submit_data_urb(struct ar9170 *ar)
{
struct urb *urb;
@@ -966,7 +968,7 @@ static int carl9170_usb_init_device(struct ar9170 *ar)
static void carl9170_usb_firmware_failed(struct ar9170 *ar)
{
- struct device *parent = ar->udev->dev.parent;
+ struct usb_interface *intf = ar->intf;
struct usb_device *udev;
/*
@@ -978,16 +980,15 @@ static void carl9170_usb_firmware_failed(struct ar9170 *ar)
udev = ar->udev;
complete(&ar->fw_load_wait);
+ /* at this point 'ar' could be already freed. Don't use it anymore */
+ ar = NULL;
/* unbind anything failed */
- if (parent)
- device_lock(parent);
-
- device_release_driver(&udev->dev);
- if (parent)
- device_unlock(parent);
+ usb_lock_device(udev);
+ usb_driver_release_interface(&carl9170_driver, intf);
+ usb_unlock_device(udev);
- usb_put_dev(udev);
+ usb_put_intf(intf);
}
static void carl9170_usb_firmware_finish(struct ar9170 *ar)
@@ -1009,7 +1010,7 @@ static void carl9170_usb_firmware_finish(struct ar9170 *ar)
goto err_unrx;
complete(&ar->fw_load_wait);
- usb_put_dev(ar->udev);
+ usb_put_intf(ar->intf);
return;
err_unrx:
@@ -1052,7 +1053,6 @@ static int carl9170_usb_probe(struct usb_interface *intf,
return PTR_ERR(ar);
udev = interface_to_usbdev(intf);
- usb_get_dev(udev);
ar->udev = udev;
ar->intf = intf;
ar->features = id->driver_info;
@@ -1094,15 +1094,14 @@ static int carl9170_usb_probe(struct usb_interface *intf,
atomic_set(&ar->rx_anch_urbs, 0);
atomic_set(&ar->rx_pool_urbs, 0);
- usb_get_dev(ar->udev);
+ usb_get_intf(intf);
carl9170_set_state(ar, CARL9170_STOPPED);
err = request_firmware_nowait(THIS_MODULE, 1, CARL9170FW_NAME,
&ar->udev->dev, GFP_KERNEL, ar, carl9170_usb_firmware_step2);
if (err) {
- usb_put_dev(udev);
- usb_put_dev(udev);
+ usb_put_intf(intf);
carl9170_free(ar);
}
return err;
@@ -1131,7 +1130,6 @@ static void carl9170_usb_disconnect(struct usb_interface *intf)
carl9170_release_firmware(ar);
carl9170_free(ar);
- usb_put_dev(udev);
}
#ifdef CONFIG_PM
--
2.20.1
^ permalink raw reply related
* RE: [EXT] Re: [PATCH] mwifiex: check for null return from skb_copy
From: Ganapathi Bhat @ 2019-06-02 1:56 UTC (permalink / raw)
To: Dan Carpenter
Cc: Colin King, Amitkumar Karwar, Nishant Sarmukadam, Xinming Hu,
Kalle Valo, David S . Miller, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, kernel-janitors@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190601210858.GG31203@kadam>
Hi Dan,
> > > > if (is_multicast_ether_addr(ra)) {
> > > > skb_uap = skb_copy(skb, GFP_ATOMIC);
> > > > + if (!skb_uap)
> > > > + return -ENOMEM;
> > >
> > > I think we would want to free dev_kfree_skb_any(skb) before returning.
> > I think if the pointer is NULL, no need to free it;
>
> You're misreading skb vs skb_uap. "skb_uap" is NULL but "skb" is non-NULL
> and I'm pretty sure we should free it.
Oh, right. I missed it; Yes you are correct.
Regards,
Ganapathi
^ permalink raw reply
* Re: [PATCH 11/11] rtw88: debug: dump tx power indexes in use
From: Joe Perches @ 2019-06-01 22:51 UTC (permalink / raw)
To: yhchuang, kvalo; +Cc: linux-wireless
In-Reply-To: <1559116487-5244-12-git-send-email-yhchuang@realtek.com>
On Wed, 2019-05-29 at 15:54 +0800, yhchuang@realtek.com wrote:
> From: Zong-Zhe Yang <kevin_yang@realtek.com>
>
> Add a read entry in debugfs to dump current tx power
> indexes in use for each path and each rate section.
> The corresponding power bases, power by rate, and
> power limit are also included.
>
> Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
> ---
> drivers/net/wireless/realtek/rtw88/debug.c | 112 +++++++++++++++++++++++++++++
> 1 file changed, 112 insertions(+)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/debug.c b/drivers/net/wireless/realtek/rtw88/debug.c
> index f0ae260..ee2937c2 100644
> --- a/drivers/net/wireless/realtek/rtw88/debug.c
> +++ b/drivers/net/wireless/realtek/rtw88/debug.c
> @@ -8,6 +8,7 @@
> #include "sec.h"
> #include "fw.h"
> #include "debug.h"
> +#include "phy.h"
>
> #ifdef CONFIG_RTW88_DEBUGFS
>
> @@ -460,6 +461,112 @@ static int rtw_debug_get_rf_dump(struct seq_file *m, void *v)
> return 0;
> }
>
> +static void rtw_print_cck_rate_txt(struct seq_file *m, u8 rate)
> +{
> + static const char * const
> + cck_rate[] = {"1M", "2M", "5.5M", "11M"};
> + u8 idx = rate - DESC_RATE1M;
> +
> + seq_printf(m, "%5s%-5s", "CCK_", cck_rate[idx]);
Why use %5s instead of just embedding the prefix directly?
Also why use %5s at all when the length is 4?
I think it'd be more sensible as:
seq_printf(m, " CCK_%-5s", cck_rate[idx]);
> +}
> +
> +static void rtw_print_ofdm_rate_txt(struct seq_file *m, u8 rate)
> +{
> + static const char * const
> + ofdm_rate[] = {"6M", "9M", "12M", "18M", "24M", "36M", "48M", "54M"};
> + u8 idx = rate - DESC_RATE6M;
> +
> + seq_printf(m, "%6s%-4s", "OFDM_", ofdm_rate[idx]);
here too
> +}
> +
> +static void rtw_print_ht_rate_txt(struct seq_file *m, u8 rate)
> +{
> + u8 mcs_n = rate - DESC_RATEMCS0;
> +
> + seq_printf(m, "%4s%-6u", "MCS", mcs_n);
and here, etc...
^ permalink raw reply
* Re: [EXT] Re: [PATCH] mwifiex: check for null return from skb_copy
From: Dan Carpenter @ 2019-06-01 21:08 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: Colin King, Amitkumar Karwar, Nishant Sarmukadam, Xinming Hu,
Kalle Valo, David S . Miller, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, kernel-janitors@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <MN2PR18MB2637DAA4852542EDA2BBC01DA01A0@MN2PR18MB2637.namprd18.prod.outlook.com>
On Sat, Jun 01, 2019 at 05:29:26PM +0000, Ganapathi Bhat wrote:
> Hi Dan,
>
> > > if (is_multicast_ether_addr(ra)) {
> > > skb_uap = skb_copy(skb, GFP_ATOMIC);
> > > + if (!skb_uap)
> > > + return -ENOMEM;
> >
> > I think we would want to free dev_kfree_skb_any(skb) before returning.
> I think if the pointer is NULL, no need to free it;
You're misreading skb vs skb_uap. "skb_uap" is NULL but "skb" is
non-NULL and I'm pretty sure we should free it.
regards,
dan carpenter
^ permalink raw reply
* RE: [EXT] INFO: trying to register non-static key in del_timer_sync (2)
From: Ganapathi Bhat @ 2019-06-01 17:52 UTC (permalink / raw)
To: syzbot, amitkarwar@gmail.com, andreyknvl@google.com,
davem@davemloft.net, huxinming820@gmail.com, kvalo@codeaurora.org,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
nishants@marvell.com, syzkaller-bugs@googlegroups.com
In-Reply-To: <000000000000927a7b0586561537@google.com>
Hi syzbot,
>
> syzbot found the following crash on:
>
As per the link(https://syzkaller.appspot.com/bug?extid=dc4127f950da51639216), the issue is fixed; Is it OK? Let us know if we need to do something?
Regards,
Ganapathi
^ permalink raw reply
* RE: [EXT] Re: [PATCH] mwifiex: check for null return from skb_copy
From: Ganapathi Bhat @ 2019-06-01 17:29 UTC (permalink / raw)
To: Dan Carpenter, Colin King
Cc: Amitkumar Karwar, Nishant Sarmukadam, Xinming Hu, Kalle Valo,
David S . Miller, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, kernel-janitors@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190413192729.GL6095@kadam>
Hi Dan,
> > if (is_multicast_ether_addr(ra)) {
> > skb_uap = skb_copy(skb, GFP_ATOMIC);
> > + if (!skb_uap)
> > + return -ENOMEM;
>
> I think we would want to free dev_kfree_skb_any(skb) before returning.
I think if the pointer is NULL, no need to free it;
Regards,
Ganapathi
^ permalink raw reply
* Re: [PATCH 4/7] iwlwifi: print fseq info upon fw assert
From: Luca Coelho @ 2019-06-01 11:13 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Shahar S Matityahu
In-Reply-To: <87pno12ukq.fsf@kamboji.qca.qualcomm.com>
On Wed, 2019-05-29 at 17:39 +0300, Kalle Valo wrote:
> Luca Coelho <luca@coelho.fi> writes:
>
> > From: Shahar S Matityahu <shahar.s.matityahu@intel.com>
> >
> > Read fseq info from FW registers and print it upon fw assert.
> > The print is needed since the fseq version coming from the TLV might
> > not be the actual version that is used.
> >
> > Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
> > Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
>
> [...]
>
> > +void iwl_fw_error_print_fseq_regs(struct iwl_fw_runtime *fwrt)
> > +{
> > + struct iwl_trans *trans = fwrt->trans;
> > + unsigned long flags;
> > + int i;
> > + struct {
> > + u32 addr;
> > + const char *str;
> > + } fseq_regs[] = {
> > + FSEQ_REG(FSEQ_ERROR_CODE),
> > + FSEQ_REG(FSEQ_TOP_INIT_VERSION),
> > + FSEQ_REG(FSEQ_CNVIO_INIT_VERSION),
> > + FSEQ_REG(FSEQ_OTP_VERSION),
> > + FSEQ_REG(FSEQ_TOP_CONTENT_VERSION),
> > + FSEQ_REG(FSEQ_ALIVE_TOKEN),
> > + FSEQ_REG(FSEQ_CNVI_ID),
> > + FSEQ_REG(FSEQ_CNVR_ID),
> > + FSEQ_REG(CNVI_AUX_MISC_CHIP),
> > + FSEQ_REG(CNVR_AUX_MISC_CHIP),
> > + FSEQ_REG(CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM),
> > + FSEQ_REG(CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR),
> > + };
>
> Can fseq_regs be static const?
Yes, they can. Can we send a fix for -next?
Shahar, can you make this change and send for internal review, please?
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] mwifiex: Fix heap overflow in mwifiex_uap_parse_tail_ies()
From: Kalle Valo @ 2019-06-01 5:06 UTC (permalink / raw)
To: Takashi Iwai
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
huangwen, Solar Designer, Marcus Meissner, linux-wireless
In-Reply-To: <20190531131841.7552-1-tiwai@suse.de>
Takashi Iwai <tiwai@suse.de> wrote:
> A few places in mwifiex_uap_parse_tail_ies() perform memcpy()
> unconditionally, which may lead to either buffer overflow or read over
> boundary.
>
> This patch addresses the issues by checking the read size and the
> destination size at each place more properly. Along with the fixes,
> the patch cleans up the code slightly by introducing a temporary
> variable for the token size, and unifies the error path with the
> standard goto statement.
>
> Reported-by: huangwen <huangwen@venustech.com.cn>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Patch applied to wireless-drivers.git, thanks.
69ae4f6aac15 mwifiex: Fix heap overflow in mwifiex_uap_parse_tail_ies()
--
https://patchwork.kernel.org/patch/10970141/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/7] iwlwifi: mvm: remove d3_sram debugfs file
From: Kalle Valo @ 2019-06-01 5:05 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, Johannes Berg, Luca Coelho
In-Reply-To: <20190529133955.31082-2-luca@coelho.fi>
Luca Coelho <luca@coelho.fi> wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> This debugfs file is really old, and cannot work properly since
> the unified image support. Rather than trying to make it work,
> which is difficult now due to multiple images (LMAC/UMAC etc.)
> just remove it - we no longer need it since we properly do a FW
> coredump even in D3 cases.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
7 patches applied to wireless-drivers.git, thanks.
23f57bfac7c2 iwlwifi: mvm: remove d3_sram debugfs file
b3500b472c88 iwlwifi: fix load in rfkill flow for unified firmware
44f61b5c832c iwlwifi: clear persistence bit according to device family
cc5470df4495 iwlwifi: print fseq info upon fw assert
b17dc0632a17 iwlwifi: fix AX201 killer sku loading firmware issue
a8627176b0de iwlwifi: Fix double-free problems in iwl_req_fw_callback()
5f4d55d5791a iwlwifi: mvm: change TLC config cmd sent by rs to be async
--
https://patchwork.kernel.org/patch/10967147/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rtlwifi: remove redundant assignment to variable k
From: Joe Perches @ 2019-05-31 19:41 UTC (permalink / raw)
To: Larry Finger, Colin King, Ping-Ke Shih, Kalle Valo,
David S . Miller, linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
In-Reply-To: <14372bed-6522-d81c-7d68-04adc0d71193@lwfinger.net>
On Fri, 2019-05-31 at 12:29 -0500, Larry Finger wrote:
> On 5/31/19 9:14 AM, Colin King wrote:
> > From: Colin Ian King <colin.king@canonical.com>
> >
> > The assignment of 0 to variable k is never read once we break out of
> > the loop, so the assignment is redundant and can be removed.
> >
> > Addresses-Coverity: ("Unused value")
> > Signed-off-by: Colin Ian King <colin.king@canonical.com>
> > ---
> > drivers/net/wireless/realtek/rtlwifi/efuse.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/wireless/realtek/rtlwifi/efuse.c b/drivers/net/wireless/realtek/rtlwifi/efuse.c
> > index e68340dfd980..83e5318ca04f 100644
> > --- a/drivers/net/wireless/realtek/rtlwifi/efuse.c
> > +++ b/drivers/net/wireless/realtek/rtlwifi/efuse.c
> > @@ -117,10 +117,8 @@ u8 efuse_read_1byte(struct ieee80211_hw *hw, u16 address)
> > rtlpriv->cfg->
> > maps[EFUSE_CTRL] + 3);
> > k++;
> > - if (k == 1000) {
> > - k = 0;
> > + if (k == 1000)
> > break;
> > - }
> > }
> > data = rtl_read_byte(rtlpriv, rtlpriv->cfg->maps[EFUSE_CTRL]);
> > return data;
>
> Colin,
>
> Your patch is not wrong, but it fails to address a basic deficiency of this code
> snippet - when an error is detected, there is no attempt to either fix the
> problem or report it upstream. As the data returned will be garbage if this
> condition happens, we might as well replace the "break" with "return 0xFF", as
> well as deleting the "k = 0" line. Most of the callers of efuse_read_1byte()
> ignore the returned result when bits 0 and 4 are set, thus returning all 8 bits
> is not a bad fixup.
>
> My suspicion is that this test is in the code merely to prevent an potential
> unterminated "while" loop, and that this condition is extremely unlikely to happen.
>
> Larry
The function is also overly verbose with many
unnecessary rtlpriv->cfg->maps dereferences.
I'd've written it more like:
---
drivers/net/wireless/realtek/rtlwifi/efuse.c | 57 +++++++++++-----------------
1 file changed, 22 insertions(+), 35 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/efuse.c b/drivers/net/wireless/realtek/rtlwifi/efuse.c
index e68340dfd980..db253f45e87d 100644
--- a/drivers/net/wireless/realtek/rtlwifi/efuse.c
+++ b/drivers/net/wireless/realtek/rtlwifi/efuse.c
@@ -87,46 +87,33 @@ void efuse_initialize(struct ieee80211_hw *hw)
u8 efuse_read_1byte(struct ieee80211_hw *hw, u16 address)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
- u8 data;
u8 bytetemp;
u8 temp;
- u32 k = 0;
- const u32 efuse_len =
- rtlpriv->cfg->maps[EFUSE_REAL_CONTENT_SIZE];
-
- if (address < efuse_len) {
- temp = address & 0xFF;
- rtl_write_byte(rtlpriv, rtlpriv->cfg->maps[EFUSE_CTRL] + 1,
- temp);
- bytetemp = rtl_read_byte(rtlpriv,
- rtlpriv->cfg->maps[EFUSE_CTRL] + 2);
- temp = ((address >> 8) & 0x03) | (bytetemp & 0xFC);
- rtl_write_byte(rtlpriv, rtlpriv->cfg->maps[EFUSE_CTRL] + 2,
- temp);
-
- bytetemp = rtl_read_byte(rtlpriv,
- rtlpriv->cfg->maps[EFUSE_CTRL] + 3);
- temp = bytetemp & 0x7F;
- rtl_write_byte(rtlpriv, rtlpriv->cfg->maps[EFUSE_CTRL] + 3,
- temp);
+ int k = 0;
+ u32 *maps = rtlpriv->cfg->maps;
+ const u32 efuse_len = maps[EFUSE_REAL_CONTENT_SIZE];
- bytetemp = rtl_read_byte(rtlpriv,
- rtlpriv->cfg->maps[EFUSE_CTRL] + 3);
- while (!(bytetemp & 0x80)) {
- bytetemp = rtl_read_byte(rtlpriv,
- rtlpriv->cfg->
- maps[EFUSE_CTRL] + 3);
- k++;
- if (k == 1000) {
- k = 0;
- break;
- }
- }
- data = rtl_read_byte(rtlpriv, rtlpriv->cfg->maps[EFUSE_CTRL]);
- return data;
- } else
+ if (address >= efuse_len)
return 0xFF;
+ temp = address & 0xFF;
+ rtl_write_byte(rtlpriv, maps[EFUSE_CTRL] + 1, temp);
+ bytetemp = rtl_read_byte(rtlpriv, maps[EFUSE_CTRL] + 2);
+ temp = ((address >> 8) & 0x03) | (bytetemp & 0xFC);
+ rtl_write_byte(rtlpriv, maps[EFUSE_CTRL] + 2, temp);
+
+ bytetemp = rtl_read_byte(rtlpriv, maps[EFUSE_CTRL] + 3);
+ temp = bytetemp & 0x7F;
+ rtl_write_byte(rtlpriv, maps[EFUSE_CTRL] + 3, temp);
+
+ bytetemp = rtl_read_byte(rtlpriv, maps[EFUSE_CTRL] + 3);
+ while (!(bytetemp & 0x80)) {
+ bytetemp = rtl_read_byte(rtlpriv, maps[EFUSE_CTRL] + 3);
+ if (++k >= 1000)
+ return 0xFF; /* Likely defect */
+ }
+
+ return rtl_read_byte(rtlpriv, maps[EFUSE_CTRL]);
}
EXPORT_SYMBOL(efuse_read_1byte);
^ permalink raw reply related
* Re: [PATCH] rtlwifi: remove redundant assignment to variable k
From: Larry Finger @ 2019-05-31 17:29 UTC (permalink / raw)
To: Colin King, Ping-Ke Shih, Kalle Valo, David S . Miller,
linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20190531141412.18632-1-colin.king@canonical.com>
On 5/31/19 9:14 AM, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The assignment of 0 to variable k is never read once we break out of
> the loop, so the assignment is redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/net/wireless/realtek/rtlwifi/efuse.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/efuse.c b/drivers/net/wireless/realtek/rtlwifi/efuse.c
> index e68340dfd980..83e5318ca04f 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/efuse.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/efuse.c
> @@ -117,10 +117,8 @@ u8 efuse_read_1byte(struct ieee80211_hw *hw, u16 address)
> rtlpriv->cfg->
> maps[EFUSE_CTRL] + 3);
> k++;
> - if (k == 1000) {
> - k = 0;
> + if (k == 1000)
> break;
> - }
> }
> data = rtl_read_byte(rtlpriv, rtlpriv->cfg->maps[EFUSE_CTRL]);
> return data;
Colin,
Your patch is not wrong, but it fails to address a basic deficiency of this code
snippet - when an error is detected, there is no attempt to either fix the
problem or report it upstream. As the data returned will be garbage if this
condition happens, we might as well replace the "break" with "return 0xFF", as
well as deleting the "k = 0" line. Most of the callers of efuse_read_1byte()
ignore the returned result when bits 0 and 4 are set, thus returning all 8 bits
is not a bad fixup.
My suspicion is that this test is in the code merely to prevent an potential
unterminated "while" loop, and that this condition is extremely unlikely to happen.
Larry
^ permalink raw reply
* Re: [PATCH 1/2] mwifiex: add support for host wakeup via PCIE wake#
From: Brian Norris @ 2019-05-31 16:47 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Zhiyuan Yang,
James Cao, Rakesh Parmar, Sharvari Harisangam
In-Reply-To: <MN2PR18MB26379DF16EADA38F72A87412A0180@MN2PR18MB2637.namprd18.prod.outlook.com>
(You really should re-send your patches, as they didn't make it to the
list. But while you're here:)
On Thu, May 30, 2019 at 3:01 AM Ganapathi Bhat <gbhat@marvell.com> wrote:
> > From: Sharvari Harisangam <sharvari@marvell.com>
> >
> > PCIE WAKE# is asserted by firmware, when WoWLAN conditions are
> > matched. Current driver does not enable PME bit needed for WAKE#
> > assertion, causing host to remain in sleep even after WoWLAN conditions are
> > matched. This commit fixes it by enabling wakeup (PME bit) in suspend
> > handler.
Are you sure said devices actually have their 'wakeup' attribute set
to 'enabled' (e.g., in sysfs)? I think the PCI core should probably be
taking care of this for you already. See below.
> > Signed-off-by: Sharvari Harisangam <sharvari@marvell.com>
> > Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
> > ---
> > drivers/net/wireless/marvell/mwifiex/pcie.c | 27 +++++++++++++++------------
> > 1 file changed, 15 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c
> > b/drivers/net/wireless/marvell/mwifiex/pcie.c
> > index 3fe81b2..0bd81d4 100644
> > --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> > +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
...
> > @@ -181,6 +180,10 @@ static int mwifiex_pcie_suspend(struct device *dev)
> > set_bit(MWIFIEX_IS_SUSPENDED, &adapter->work_flags);
> > clear_bit(MWIFIEX_IS_HS_ENABLING, &adapter->work_flags);
> >
> > + pci_enable_wake(pdev, pci_choose_state(pdev, state), 1);
> > + pci_save_state(pdev);
> > + pci_set_power_state(pdev, pci_choose_state(pdev, state));
From Documentation/power/pci.txt:
"""
3.1.2. suspend()
...
This callback is expected to quiesce the device and prepare it to be put into a
low-power state by the PCI subsystem. It is not required (in fact it even is
not recommended) that a PCI driver's suspend() callback save the standard
configuration registers of the device, prepare it for waking up the system, or
put it into a low-power state. All of these operations can very well be taken
care of by the PCI subsystem, without the driver's participation.
However, in some rare case it is convenient to carry out these operations in
a PCI driver. [...]
"""
I think you need to do a little more work to justify why you are one
of those rare cases.
On a related note: some of the existing "configure wakeup" stuff we do
here should probably be gated behind a call to device_may_wakeup().
That would help make it more obvious that such configuration is
futile, if the device was marked as wake-disabled.
Brian
> > +
> > return 0;
> > }
> >
^ permalink raw reply
* [PATCH] rtlwifi: remove redundant assignment to variable k
From: Colin King @ 2019-05-31 14:14 UTC (permalink / raw)
To: Ping-Ke Shih, Kalle Valo, David S . Miller, linux-wireless,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The assignment of 0 to variable k is never read once we break out of
the loop, so the assignment is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/realtek/rtlwifi/efuse.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/efuse.c b/drivers/net/wireless/realtek/rtlwifi/efuse.c
index e68340dfd980..83e5318ca04f 100644
--- a/drivers/net/wireless/realtek/rtlwifi/efuse.c
+++ b/drivers/net/wireless/realtek/rtlwifi/efuse.c
@@ -117,10 +117,8 @@ u8 efuse_read_1byte(struct ieee80211_hw *hw, u16 address)
rtlpriv->cfg->
maps[EFUSE_CTRL] + 3);
k++;
- if (k == 1000) {
- k = 0;
+ if (k == 1000)
break;
- }
}
data = rtl_read_byte(rtlpriv, rtlpriv->cfg->maps[EFUSE_CTRL]);
return data;
--
2.20.1
^ permalink raw reply related
* [PATCH v2 2/2] mt76: mt7615: fix slow performance when enable encryption
From: Ryder Lee @ 2019-05-31 14:09 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi
Cc: Roy Luo, YF Luo, Yiwei Chung, Sean Wang, Chih-Min Chen,
linux-wireless, linux-mediatek, linux-kernel, Ryder Lee
In-Reply-To: <e459fbc79154da9e0e6e098d2c49a9b17e842f47.1559301203.git.ryder.lee@mediatek.com>
Fix wrong WCID assignment and add RKV (RX Key of this entry is valid)
flag to check if peer uses the same configuration with previous
handshaking.
If the configuration is mismatch, WTBL indicates a “cipher mismatch”
to stop SEC decryption to prevent the packet from damage.
Suggested-by: YF Luo <yf.luo@mediatek.com>
Suggested-by: Yiwei Chung <yiwei.chung@mediatek.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
---
Changes since v2 - none
---
drivers/net/wireless/mediatek/mt76/mt7615/init.c | 15 +++++++++------
drivers/net/wireless/mediatek/mt76/mt7615/main.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 1 +
3 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
index f860af6a42da..b96c753b7532 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
@@ -62,16 +62,11 @@ static void mt7615_mac_init(struct mt7615_dev *dev)
MT_AGG_ARCR_RATE_DOWN_RATIO_EN |
FIELD_PREP(MT_AGG_ARCR_RATE_DOWN_RATIO, 1) |
FIELD_PREP(MT_AGG_ARCR_RATE_UP_EXTRA_TH, 4)));
-
- dev->mt76.global_wcid.idx = MT7615_WTBL_RESERVED;
- dev->mt76.global_wcid.hw_key_idx = -1;
- rcu_assign_pointer(dev->mt76.wcid[MT7615_WTBL_RESERVED],
- &dev->mt76.global_wcid);
}
static int mt7615_init_hardware(struct mt7615_dev *dev)
{
- int ret;
+ int ret, idx;
mt76_wr(dev, MT_INT_SOURCE_CSR, ~0);
@@ -98,6 +93,14 @@ static int mt7615_init_hardware(struct mt7615_dev *dev)
mt7615_mcu_ctrl_pm_state(dev, 0);
mt7615_mcu_del_wtbl_all(dev);
+ /* Beacon and mgmt frames should occupy wcid 0 */
+ idx = mt76_wcid_alloc(dev->mt76.wcid_mask, MT7615_WTBL_STA - 1);
+ if (idx)
+ return -ENOSPC;
+
+ dev->mt76.global_wcid.idx = idx;
+ dev->mt76.global_wcid.hw_key_idx = -1;
+ rcu_assign_pointer(dev->mt76.wcid[idx], &dev->mt76.global_wcid);
return 0;
}
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
index 585e67fa2728..2cdd339453c8 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -95,7 +95,7 @@ static int mt7615_add_interface(struct ieee80211_hw *hw,
dev->vif_mask |= BIT(mvif->idx);
dev->omac_mask |= BIT(mvif->omac_idx);
- idx = MT7615_WTBL_RESERVED - 1 - mvif->idx;
+ idx = MT7615_WTBL_RESERVED - mvif->idx;
mvif->sta.wcid.idx = idx;
mvif->sta.wcid.hw_key_idx = -1;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index 8b8db526cb16..5f38741e7366 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -882,6 +882,7 @@ int mt7615_mcu_set_wtbl_key(struct mt7615_dev *dev, int wcid,
if (cipher == MT_CIPHER_NONE && key)
return -EOPNOTSUPP;
+ req.key.rkv = 1;
req.key.cipher_id = cipher;
req.key.key_id = key->keyidx;
req.key.key_len = key->keylen;
--
2.18.0
^ permalink raw reply related
* [PATCH v2 1/2] mt76: mt7615: enable support for mesh
From: Ryder Lee @ 2019-05-31 14:09 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi
Cc: Roy Luo, YF Luo, Yiwei Chung, Sean Wang, Chih-Min Chen,
linux-wireless, linux-mediatek, linux-kernel, Ryder Lee
Enable NL80211_IFTYPE_MESH_POINT and update its path.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
---
Changes since v2 - remove unused definitions
---
drivers/net/wireless/mediatek/mt76/mt7615/init.c | 6 ++++++
drivers/net/wireless/mediatek/mt76/mt7615/main.c | 1 +
drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 5 ++++-
drivers/net/wireless/mediatek/mt76/mt7615/mcu.h | 6 ------
4 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
index 59f604f3161f..f860af6a42da 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
@@ -133,6 +133,9 @@ static const struct ieee80211_iface_limit if_limits[] = {
{
.max = MT7615_MAX_INTERFACES,
.types = BIT(NL80211_IFTYPE_AP) |
+#ifdef CONFIG_MAC80211_MESH
+ BIT(NL80211_IFTYPE_MESH_POINT) |
+#endif
BIT(NL80211_IFTYPE_STATION)
}
};
@@ -195,6 +198,9 @@ int mt7615_register_device(struct mt7615_dev *dev)
dev->mt76.antenna_mask = 0xf;
wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
+#ifdef CONFIG_MAC80211_MESH
+ BIT(NL80211_IFTYPE_MESH_POINT) |
+#endif
BIT(NL80211_IFTYPE_AP);
ret = mt76_register_device(&dev->mt76, true, mt7615_rates,
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
index b0bb7cc12385..585e67fa2728 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -37,6 +37,7 @@ static int get_omac_idx(enum nl80211_iftype type, u32 mask)
switch (type) {
case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_MESH_POINT:
/* ap use hw bssid 0 and ext bssid */
if (~mask & BIT(HW_BSSID_0))
return HW_BSSID_0;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index 43f70195244c..8b8db526cb16 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -754,6 +754,7 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev,
switch (vif->type) {
case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_MESH_POINT:
tx_wlan_idx = mvif->sta.wcid.idx;
conn_type = CONNECTION_INFRA_AP;
break;
@@ -968,7 +969,8 @@ int mt7615_mcu_add_wtbl(struct mt7615_dev *dev, struct ieee80211_vif *vif,
.rx_wtbl = {
.tag = cpu_to_le16(WTBL_RX),
.len = cpu_to_le16(sizeof(struct wtbl_rx)),
- .rca1 = vif->type != NL80211_IFTYPE_AP,
+ .rca1 = vif->type != (NL80211_IFTYPE_AP ||
+ NL80211_IFTYPE_MESH_POINT),
.rca2 = 1,
.rv = 1,
},
@@ -1042,6 +1044,7 @@ static void sta_rec_convert_vif_type(enum nl80211_iftype type, u32 *conn_type)
{
switch (type) {
case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_MESH_POINT:
if (conn_type)
*conn_type = CONNECTION_INFRA_STA;
break;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
index e96efb13fa4d..0915cb735699 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
@@ -105,25 +105,19 @@ enum {
#define STA_TYPE_STA BIT(0)
#define STA_TYPE_AP BIT(1)
#define STA_TYPE_ADHOC BIT(2)
-#define STA_TYPE_TDLS BIT(3)
#define STA_TYPE_WDS BIT(4)
#define STA_TYPE_BC BIT(5)
#define NETWORK_INFRA BIT(16)
#define NETWORK_P2P BIT(17)
#define NETWORK_IBSS BIT(18)
-#define NETWORK_MESH BIT(19)
-#define NETWORK_BOW BIT(20)
#define NETWORK_WDS BIT(21)
#define CONNECTION_INFRA_STA (STA_TYPE_STA | NETWORK_INFRA)
#define CONNECTION_INFRA_AP (STA_TYPE_AP | NETWORK_INFRA)
#define CONNECTION_P2P_GC (STA_TYPE_STA | NETWORK_P2P)
#define CONNECTION_P2P_GO (STA_TYPE_AP | NETWORK_P2P)
-#define CONNECTION_MESH_STA (STA_TYPE_STA | NETWORK_MESH)
-#define CONNECTION_MESH_AP (STA_TYPE_AP | NETWORK_MESH)
#define CONNECTION_IBSS_ADHOC (STA_TYPE_ADHOC | NETWORK_IBSS)
-#define CONNECTION_TDLS (STA_TYPE_STA | NETWORK_INFRA | STA_TYPE_TDLS)
#define CONNECTION_WDS (STA_TYPE_WDS | NETWORK_WDS)
#define CONNECTION_INFRA_BC (STA_TYPE_BC | NETWORK_INFRA)
--
2.18.0
^ permalink raw reply related
* [PATCH] mwifiex: Fix heap overflow in mwifiex_uap_parse_tail_ies()
From: Takashi Iwai @ 2019-05-31 13:18 UTC (permalink / raw)
To: Kalle Valo
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
huangwen, Solar Designer, Marcus Meissner, linux-wireless
A few places in mwifiex_uap_parse_tail_ies() perform memcpy()
unconditionally, which may lead to either buffer overflow or read over
boundary.
This patch addresses the issues by checking the read size and the
destination size at each place more properly. Along with the fixes,
the patch cleans up the code slightly by introducing a temporary
variable for the token size, and unifies the error path with the
standard goto statement.
Reported-by: huangwen <huangwen@venustech.com.cn>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
drivers/net/wireless/marvell/mwifiex/ie.c | 47 ++++++++++++++++++++-----------
1 file changed, 31 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/ie.c b/drivers/net/wireless/marvell/mwifiex/ie.c
index 6845eb57b39a..653d347a9a19 100644
--- a/drivers/net/wireless/marvell/mwifiex/ie.c
+++ b/drivers/net/wireless/marvell/mwifiex/ie.c
@@ -329,6 +329,8 @@ static int mwifiex_uap_parse_tail_ies(struct mwifiex_private *priv,
struct ieee80211_vendor_ie *vendorhdr;
u16 gen_idx = MWIFIEX_AUTO_IDX_MASK, ie_len = 0;
int left_len, parsed_len = 0;
+ unsigned int token_len;
+ int err = 0;
if (!info->tail || !info->tail_len)
return 0;
@@ -344,6 +346,12 @@ static int mwifiex_uap_parse_tail_ies(struct mwifiex_private *priv,
*/
while (left_len > sizeof(struct ieee_types_header)) {
hdr = (void *)(info->tail + parsed_len);
+ token_len = hdr->len + sizeof(struct ieee_types_header);
+ if (token_len > left_len) {
+ err = -EINVAL;
+ goto out;
+ }
+
switch (hdr->element_id) {
case WLAN_EID_SSID:
case WLAN_EID_SUPP_RATES:
@@ -361,17 +369,20 @@ static int mwifiex_uap_parse_tail_ies(struct mwifiex_private *priv,
if (cfg80211_find_vendor_ie(WLAN_OUI_MICROSOFT,
WLAN_OUI_TYPE_MICROSOFT_WMM,
(const u8 *)hdr,
- hdr->len + sizeof(struct ieee_types_header)))
+ token_len))
break;
/* fall through */
default:
- memcpy(gen_ie->ie_buffer + ie_len, hdr,
- hdr->len + sizeof(struct ieee_types_header));
- ie_len += hdr->len + sizeof(struct ieee_types_header);
+ if (ie_len + token_len > IEEE_MAX_IE_SIZE) {
+ err = -EINVAL;
+ goto out;
+ }
+ memcpy(gen_ie->ie_buffer + ie_len, hdr, token_len);
+ ie_len += token_len;
break;
}
- left_len -= hdr->len + sizeof(struct ieee_types_header);
- parsed_len += hdr->len + sizeof(struct ieee_types_header);
+ left_len -= token_len;
+ parsed_len += token_len;
}
/* parse only WPA vendor IE from tail, WMM IE is configured by
@@ -381,15 +392,17 @@ static int mwifiex_uap_parse_tail_ies(struct mwifiex_private *priv,
WLAN_OUI_TYPE_MICROSOFT_WPA,
info->tail, info->tail_len);
if (vendorhdr) {
- memcpy(gen_ie->ie_buffer + ie_len, vendorhdr,
- vendorhdr->len + sizeof(struct ieee_types_header));
- ie_len += vendorhdr->len + sizeof(struct ieee_types_header);
+ token_len = vendorhdr->len + sizeof(struct ieee_types_header);
+ if (ie_len + token_len > IEEE_MAX_IE_SIZE) {
+ err = -EINVAL;
+ goto out;
+ }
+ memcpy(gen_ie->ie_buffer + ie_len, vendorhdr, token_len);
+ ie_len += token_len;
}
- if (!ie_len) {
- kfree(gen_ie);
- return 0;
- }
+ if (!ie_len)
+ goto out;
gen_ie->ie_index = cpu_to_le16(gen_idx);
gen_ie->mgmt_subtype_mask = cpu_to_le16(MGMT_MASK_BEACON |
@@ -399,13 +412,15 @@ static int mwifiex_uap_parse_tail_ies(struct mwifiex_private *priv,
if (mwifiex_update_uap_custom_ie(priv, gen_ie, &gen_idx, NULL, NULL,
NULL, NULL)) {
- kfree(gen_ie);
- return -1;
+ err = -EINVAL;
+ goto out;
}
priv->gen_idx = gen_idx;
+
+ out:
kfree(gen_ie);
- return 0;
+ return err;
}
/* This function parses different IEs-head & tail IEs, beacon IEs,
--
2.16.4
^ permalink raw reply related
* Re: [PATCH 1/2] mt76: mt7615: enable support for mesh
From: Ryder Lee @ 2019-05-31 10:31 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Felix Fietkau, Lorenzo Bianconi, Roy Luo, YF Luo, Yiwei Chung,
Sean Wang, Chih-Min Chen, linux-wireless, linux-mediatek,
linux-kernel
In-Reply-To: <20190531100201.GA3527@localhost.localdomain>
On Fri, 2019-05-31 at 12:02 +0200, Lorenzo Bianconi wrote:
> > Enable NL80211_IFTYPE_MESH_POINT and add its path.
> >
> > Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> > ---
> > drivers/net/wireless/mediatek/mt76/mt7615/init.c | 6 ++++++
> > drivers/net/wireless/mediatek/mt76/mt7615/main.c | 1 +
> > drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 5 ++++-
> > 3 files changed, 11 insertions(+), 1 deletion(-)
> >
>
> [...]
>
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
> > index b0bb7cc12385..585e67fa2728 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
> > @@ -37,6 +37,7 @@ static int get_omac_idx(enum nl80211_iftype type, u32 mask)
> >
> > switch (type) {
> > case NL80211_IFTYPE_AP:
> > + case NL80211_IFTYPE_MESH_POINT:
> > /* ap use hw bssid 0 and ext bssid */
> > if (~mask & BIT(HW_BSSID_0))
> > return HW_BSSID_0;
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> > index 43f70195244c..8b8db526cb16 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> > @@ -754,6 +754,7 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev,
> >
> > switch (vif->type) {
> > case NL80211_IFTYPE_AP:
> > + case NL80211_IFTYPE_MESH_POINT:
> > tx_wlan_idx = mvif->sta.wcid.idx;
> > conn_type = CONNECTION_INFRA_AP;
>
> Just out of curiosity, why not using CONNECTION_MESH_{AP,STA} here?
> why not NETWORK_MESH?
Actually the CONNECTION_MESH_{AP,STA} are useless and I will send v2 to
remove them.
> > break;
> > @@ -968,7 +969,8 @@ int mt7615_mcu_add_wtbl(struct mt7615_dev *dev, struct ieee80211_vif *vif,
> > .rx_wtbl = {
> > .tag = cpu_to_le16(WTBL_RX),
> > .len = cpu_to_le16(sizeof(struct wtbl_rx)),
> > - .rca1 = vif->type != NL80211_IFTYPE_AP,
> > + .rca1 = vif->type != (NL80211_IFTYPE_AP ||
> > + NL80211_IFTYPE_MESH_POINT),
> > .rca2 = 1,
> > .rv = 1,
> > },
> > @@ -1042,6 +1044,7 @@ static void sta_rec_convert_vif_type(enum nl80211_iftype type, u32 *conn_type)
> > {
> > switch (type) {
> > case NL80211_IFTYPE_AP:
> > + case NL80211_IFTYPE_MESH_POINT:
> > if (conn_type)
> > *conn_type = CONNECTION_INFRA_STA;
> > break;
>
> same here.
>
> Regards,
> Lorenzo
>
> > --
> > 2.18.0
> >
^ 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