* RE: [PATCH 0/3] brcmfmac: sdio: Deal better w/ transmission errors waking from sleep
From: Avri Altman @ 2019-05-18 15:09 UTC (permalink / raw)
To: Douglas Anderson, Ulf Hansson, Kalle Valo, Adrian Hunter,
Arend van Spriel
Cc: linux-rockchip@lists.infradead.org, Double Lo,
briannorris@chromium.org, Madhan Mohan R, mka@chromium.org,
Wright Feng, Chi-Hsien Lin, linux-mmc@vger.kernel.org, Shawn Lin,
brcm80211-dev-list@cypress.com, YueHaibing, Hante Meuleman,
Martin Hicks, Ritesh Harjani, Michael Trimarchi, Wolfram Sang,
Franky Lin, Jiong Wu, brcm80211-dev-list.pdl@broadcom.com,
David S. Miller, netdev@vger.kernel.org,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
Naveen Gupta, Madhan Mohan R
In-Reply-To: <20190517225420.176893-1-dianders@chromium.org>
>
> This series attempts to deal better with the expected transmission
> errors that we get when waking up the SDIO-based WiFi on
> rk3288-veyron-minnie, rk3288-veyron-speedy, and rk3288-veyron-mickey.
>
> Some details about those errors can be found in
> <https://crbug.com/960222>, but to summarize it here: if we try to
> send the wakeup command to the WiFi card at the same time it has
> decided to wake up itself then it will behave badly on the SDIO bus.
> This can cause timeouts or CRC errors.
Wake-up itself: as part of a WoWlan, or d0i3?
Looks like this calls for a wifi driver fix, and not WA in the mmc driver.
Thanks,
Avri
^ permalink raw reply
* [PATCH 0/3] brcmfmac: sdio: Deal better w/ transmission errors waking from sleep
From: Douglas Anderson @ 2019-05-17 22:54 UTC (permalink / raw)
To: Ulf Hansson, Kalle Valo, Adrian Hunter, Arend van Spriel
Cc: linux-rockchip, Double Lo, briannorris, Madhan Mohan R, mka,
Wright Feng, Chi-Hsien Lin, Douglas Anderson, linux-mmc,
Shawn Lin, brcm80211-dev-list, YueHaibing, Hante Meuleman,
Martin Hicks, Ritesh Harjani, Michael Trimarchi, Wolfram Sang,
Franky Lin, Jiong Wu, brcm80211-dev-list.pdl, David S. Miller,
netdev, linux-wireless, linux-kernel, Naveen Gupta,
Madhan Mohan R, Avri Altman
This series attempts to deal better with the expected transmission
errors that we get when waking up the SDIO-based WiFi on
rk3288-veyron-minnie, rk3288-veyron-speedy, and rk3288-veyron-mickey.
Some details about those errors can be found in
<https://crbug.com/960222>, but to summarize it here: if we try to
send the wakeup command to the WiFi card at the same time it has
decided to wake up itself then it will behave badly on the SDIO bus.
This can cause timeouts or CRC errors.
When I tested on 4.19 and 4.20 these CRC errors can be seen to cause
re-tuning. Since I am currently developing on 4.19 this was the
original problem I attempted to solve.
On mainline it turns out that you don't see the retuning errors but
you see tons of spam about timeouts trying to wakeup from sleep. I
tracked down the commit that was causing that and have partially
reverted it here. I have no real knowledge about Broadcom WiFi, but
the commit that was causing problems sounds (from the descriptioin) to
be a hack commit penalizing all Broadcom WiFi users because of a bug
in a Cypress SD controller. I will let others comment if this is
truly the case and, if so, what the right solution should be.
Douglas Anderson (3):
brcmfmac: re-enable command decode in sdio_aos for BRCM 4354
mmc: core: API for temporarily disabling auto-retuning due to errors
brcmfmac: sdio: Disable auto-tuning around commands expected to fail
drivers/mmc/core/core.c | 27 +++++++++++++++++--
.../broadcom/brcm80211/brcmfmac/sdio.c | 6 +++--
include/linux/mmc/core.h | 2 ++
include/linux/mmc/host.h | 1 +
4 files changed, 32 insertions(+), 4 deletions(-)
--
2.21.0.1020.gf2820cf01a-goog
^ permalink raw reply
* [PATCH 1/3] brcmfmac: re-enable command decode in sdio_aos for BRCM 4354
From: Douglas Anderson @ 2019-05-17 22:54 UTC (permalink / raw)
To: Ulf Hansson, Kalle Valo, Adrian Hunter, Arend van Spriel
Cc: linux-rockchip, Double Lo, briannorris, Madhan Mohan R, mka,
Wright Feng, Chi-Hsien Lin, Douglas Anderson,
brcm80211-dev-list.pdl, Franky Lin, netdev, linux-wireless,
linux-kernel, Madhan Mohan R, Hante Meuleman, Naveen Gupta,
brcm80211-dev-list, YueHaibing, David S. Miller
In-Reply-To: <20190517225420.176893-1-dianders@chromium.org>
In commit 29f6589140a1 ("brcmfmac: disable command decode in
sdio_aos") we disabled something called "command decode in sdio_aos"
for a whole bunch of Broadcom SDIO WiFi parts.
After that patch landed I find that my kernel log on
rk3288-veyron-minnie and rk3288-veyron-speedy is filled with:
brcmfmac: brcmf_sdio_bus_sleep: error while changing bus sleep state -110
This seems to happen every time the Broadcom WiFi transitions out of
sleep mode. Reverting the part of the commit that affects the WiFi on
my boards fixes the problem for me, so that's what this patch does.
Note that, in general, the justification in the original commit seemed
a little weak. It looked like someone was testing on a SD card
controller that would sometimes die if there were CRC errors on the
bus. This used to happen back in early days of dw_mmc (the controller
on my boards), but we fixed it. Disabling a feature on all boards
just because one SD card controller is broken seems bad. ...so
instead of just this patch possibly the right thing to do is to fully
revert the original commit.
Fixes: 29f6589140a1 ("brcmfmac: disable command decode in sdio_aos")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 22b73da42822..3fd2d58a3c88 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -3378,8 +3378,7 @@ static bool brcmf_sdio_aos_no_decode(struct brcmf_sdio *bus)
if (bus->ci->chip == CY_CC_43012_CHIP_ID ||
bus->ci->chip == CY_CC_4373_CHIP_ID ||
bus->ci->chip == BRCM_CC_4339_CHIP_ID ||
- bus->ci->chip == BRCM_CC_4345_CHIP_ID ||
- bus->ci->chip == BRCM_CC_4354_CHIP_ID)
+ bus->ci->chip == BRCM_CC_4345_CHIP_ID)
return true;
else
return false;
--
2.21.0.1020.gf2820cf01a-goog
^ permalink raw reply related
* [PATCH 3/3] brcmfmac: sdio: Disable auto-tuning around commands expected to fail
From: Douglas Anderson @ 2019-05-17 22:54 UTC (permalink / raw)
To: Ulf Hansson, Kalle Valo, Adrian Hunter, Arend van Spriel
Cc: linux-rockchip, Double Lo, briannorris, Madhan Mohan R, mka,
Wright Feng, Chi-Hsien Lin, Douglas Anderson,
brcm80211-dev-list.pdl, David S. Miller, Franky Lin, netdev,
linux-wireless, linux-kernel, Hante Meuleman, Naveen Gupta,
brcm80211-dev-list, YueHaibing, Michael Trimarchi
In-Reply-To: <20190517225420.176893-1-dianders@chromium.org>
There are certain cases, notably when transitioning between sleep and
active state, when Broadcom SDIO WiFi cards will produce errors on the
SDIO bus. This is evident from the source code where you can see that
we try commands in a loop until we either get success or we've tried
too many times. The comment in the code reinforces this by saying
"just one write attempt may fail"
Unfortunately these failures sometimes end up causing an "-EILSEQ"
back to the core which triggers a retuning of the SDIO card and that
blocks all traffic to the card until it's done.
Let's disable retuning around the commands we expect might fail.
Fixes: bd11e8bd03ca ("mmc: core: Flag re-tuning is needed on CRC errors")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 3fd2d58a3c88..c09bb8965487 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -27,6 +27,7 @@
#include <linux/mmc/sdio_ids.h>
#include <linux/mmc/sdio_func.h>
#include <linux/mmc/card.h>
+#include <linux/mmc/core.h>
#include <linux/semaphore.h>
#include <linux/firmware.h>
#include <linux/module.h>
@@ -708,6 +709,7 @@ brcmf_sdio_kso_control(struct brcmf_sdio *bus, bool on)
bmask = SBSDIO_FUNC1_SLEEPCSR_KSO_MASK;
}
+ mmc_expect_errors_begin(bus->sdiodev->func1->card->host);
do {
/* reliable KSO bit set/clr:
* the sdiod sleep write access is synced to PMU 32khz clk
@@ -730,6 +732,7 @@ brcmf_sdio_kso_control(struct brcmf_sdio *bus, bool on)
&err);
} while (try_cnt++ < MAX_KSO_ATTEMPTS);
+ mmc_expect_errors_end(bus->sdiodev->func1->card->host);
if (try_cnt > 2)
brcmf_dbg(SDIO, "try_cnt=%d rd_val=0x%x err=%d\n", try_cnt,
--
2.21.0.1020.gf2820cf01a-goog
^ permalink raw reply related
* Re: [PATCH] mt76: mt7615: select wifi band according to eeprom
From: Lorenzo Bianconi @ 2019-05-17 21:35 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, Ryder Lee, royluo
In-Reply-To: <38aa977df45a92f60d78d9cb7e575289ccbaeef6.1558127930.git.lorenzo@kernel.org>
>
> Select supported band according to the value read from
> eeprom mtd/otp partition
>
I forgot to mention this patch is based on 'mt76: mt7615: add support
for mtd eeprom parsing'
https://patchwork.kernel.org/patch/10947385/
Regards,
Lorenzo
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> .../wireless/mediatek/mt76/mt7615/eeprom.c | 24 ++++++++++++++++---
> .../wireless/mediatek/mt76/mt7615/eeprom.h | 9 +++++++
> 2 files changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
> index 1712f66520a8..714590878d65 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
> @@ -90,6 +90,26 @@ static int mt7615_check_eeprom(struct mt76_dev *dev)
> }
> }
>
> +static void mt7615_eeprom_parse_hw_cap(struct mt7615_dev *dev)
> +{
> + u8 val, *eeprom = dev->mt76.eeprom.data;
> +
> + val = FIELD_GET(MT_EE_NIC_WIFI_CONF_BAND_SEL,
> + eeprom[MT_EE_WIFI_CONF]);
> + switch (val) {
> + case MT_EE_5GHZ:
> + dev->mt76.cap.has_5ghz = true;
> + break;
> + case MT_EE_2GHZ:
> + dev->mt76.cap.has_2ghz = true;
> + break;
> + default:
> + dev->mt76.cap.has_2ghz = true;
> + dev->mt76.cap.has_5ghz = true;
> + break;
> + }
> +}
> +
> int mt7615_eeprom_init(struct mt7615_dev *dev)
> {
> int ret;
> @@ -103,9 +123,7 @@ int mt7615_eeprom_init(struct mt7615_dev *dev)
> memcpy(dev->mt76.eeprom.data, dev->mt76.otp.data,
> MT7615_EEPROM_SIZE);
>
> - dev->mt76.cap.has_2ghz = true;
> - dev->mt76.cap.has_5ghz = true;
> -
> + mt7615_eeprom_parse_hw_cap(dev);
> memcpy(dev->mt76.macaddr, dev->mt76.eeprom.data + MT_EE_MAC_ADDR,
> ETH_ALEN);
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.h b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.h
> index a4cf16688171..b422e395d6ee 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.h
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.h
> @@ -11,8 +11,17 @@ enum mt7615_eeprom_field {
> MT_EE_VERSION = 0x002,
> MT_EE_MAC_ADDR = 0x004,
> MT_EE_NIC_CONF_0 = 0x034,
> + MT_EE_WIFI_CONF = 0x03e,
>
> __MT_EE_MAX = 0x3bf
> };
>
> +#define MT_EE_NIC_WIFI_CONF_BAND_SEL GENMASK(5, 4)
> +enum mt7615_eeprom_band {
> + MT_EE_DUAL_BAND,
> + MT_EE_5GHZ,
> + MT_EE_2GHZ,
> + MT_EE_DBDC,
> +};
> +
> #endif
> --
> 2.20.1
>
^ permalink raw reply
* [PATCH] mt76: mt7615: select wifi band according to eeprom
From: Lorenzo Bianconi @ 2019-05-17 21:32 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo
In-Reply-To: <cover.1558127930.git.lorenzo@kernel.org>
Select supported band according to the value read from
eeprom mtd/otp partition
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
.../wireless/mediatek/mt76/mt7615/eeprom.c | 24 ++++++++++++++++---
.../wireless/mediatek/mt76/mt7615/eeprom.h | 9 +++++++
2 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
index 1712f66520a8..714590878d65 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
@@ -90,6 +90,26 @@ static int mt7615_check_eeprom(struct mt76_dev *dev)
}
}
+static void mt7615_eeprom_parse_hw_cap(struct mt7615_dev *dev)
+{
+ u8 val, *eeprom = dev->mt76.eeprom.data;
+
+ val = FIELD_GET(MT_EE_NIC_WIFI_CONF_BAND_SEL,
+ eeprom[MT_EE_WIFI_CONF]);
+ switch (val) {
+ case MT_EE_5GHZ:
+ dev->mt76.cap.has_5ghz = true;
+ break;
+ case MT_EE_2GHZ:
+ dev->mt76.cap.has_2ghz = true;
+ break;
+ default:
+ dev->mt76.cap.has_2ghz = true;
+ dev->mt76.cap.has_5ghz = true;
+ break;
+ }
+}
+
int mt7615_eeprom_init(struct mt7615_dev *dev)
{
int ret;
@@ -103,9 +123,7 @@ int mt7615_eeprom_init(struct mt7615_dev *dev)
memcpy(dev->mt76.eeprom.data, dev->mt76.otp.data,
MT7615_EEPROM_SIZE);
- dev->mt76.cap.has_2ghz = true;
- dev->mt76.cap.has_5ghz = true;
-
+ mt7615_eeprom_parse_hw_cap(dev);
memcpy(dev->mt76.macaddr, dev->mt76.eeprom.data + MT_EE_MAC_ADDR,
ETH_ALEN);
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.h b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.h
index a4cf16688171..b422e395d6ee 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.h
@@ -11,8 +11,17 @@ enum mt7615_eeprom_field {
MT_EE_VERSION = 0x002,
MT_EE_MAC_ADDR = 0x004,
MT_EE_NIC_CONF_0 = 0x034,
+ MT_EE_WIFI_CONF = 0x03e,
__MT_EE_MAX = 0x3bf
};
+#define MT_EE_NIC_WIFI_CONF_BAND_SEL GENMASK(5, 4)
+enum mt7615_eeprom_band {
+ MT_EE_DUAL_BAND,
+ MT_EE_5GHZ,
+ MT_EE_2GHZ,
+ MT_EE_DBDC,
+};
+
#endif
--
2.20.1
^ permalink raw reply related
* Re: KASAN: use-after-free Read in p54u_load_firmware_cb
From: syzbot @ 2019-05-17 21:01 UTC (permalink / raw)
To: andreyknvl, chunkeey, chunkeey, davem, flamingice, kvalo,
linux-kernel, linux-usb, linux-wireless, netdev, oneukum, stern,
syzkaller-bugs
In-Reply-To: <Pine.LNX.4.44L0.1905171644110.1430-100000@iolanthe.rowland.org>
Hello,
syzbot tried to test the proposed patch but build/boot failed:
| ipr_init_dump_entry_hdr(&driver_dump->location_entry.hdr);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CC drivers/gpu/drm/nouveau/nvkm/engine/disp/ovlygk104.o
CC drivers/scsi/xen-scsifront.o
drivers/scsi/ipr.c: In function ‘ipr_build_ioadl’:
drivers/scsi/ipr.c:6017:11: warning: taking address of packed member of
‘struct ipr_ioarcb_add_data’ may result in an unaligned pointer value
[-Waddress-of-packed-member]
6017 | ioadl = ioarcb->u.add_data.u.ioadl;
| ^~~~~~
drivers/scsi/ipr.c: In function ‘ipr_check_term_power’:
drivers/scsi/ipr.c:7452:8: warning: taking address of packed member of
‘struct ipr_mode_page28’ may result in an unaligned pointer value
[-Waddress-of-packed-member]
7452 | bus = mode_page->bus;
| ^~~~~~~~~
drivers/scsi/ipr.c: In function ‘ipr_modify_ioafp_mode_page_28’:
drivers/scsi/ipr.c:7514:20: warning: taking address of packed member of
‘struct ipr_mode_page28’ may result in an unaligned pointer value
[-Waddress-of-packed-member]
7514 | for (i = 0, bus = mode_page->bus;
| ^~~~~~~~~
CC drivers/scsi/storvsc_drv.o
CC drivers/scsi/wd719x.o
CC drivers/gpu/drm/nouveau/nvkm/engine/disp/ovlygp102.o
CC drivers/scsi/st.o
CC drivers/gpu/drm/nouveau/nvkm/engine/disp/wimmgv100.o
CC drivers/scsi/osst.o
drivers/scsi/storvsc_drv.c: In function ‘storvsc_on_channel_callback’:
drivers/scsi/storvsc_drv.c:1173:24: warning: taking address of packed
member of ‘struct vmpacket_descriptor’ may result in an unaligned pointer
value [-Waddress-of-packed-member]
1173 | ((unsigned long)desc->trans_id);
| ~~~~^~~~~~~~~~
CC drivers/gpu/drm/nouveau/nvkm/engine/disp/wndwgv100.o
CC drivers/gpu/drm/nouveau/nvkm/engine/disp/piocnv50.o
CC drivers/scsi/sd.o
CC drivers/scsi/sd_dif.o
CC drivers/scsi/sd_zbc.o
CC drivers/gpu/drm/nouveau/nvkm/engine/disp/piocgf119.o
CC drivers/scsi/sr.o
CC drivers/gpu/drm/nouveau/nvkm/engine/disp/cursnv50.o
CC drivers/scsi/sr_ioctl.o
CC drivers/scsi/sr_vendor.o
CC drivers/scsi/sg.o
CC drivers/gpu/drm/nouveau/nvkm/engine/disp/cursgf119.o
CC drivers/gpu/drm/nouveau/nvkm/engine/disp/cursgp102.o
CC drivers/scsi/ch.o
CC drivers/scsi/ses.o
CC drivers/scsi/scsi_sysfs.o
CC drivers/gpu/drm/nouveau/nvkm/engine/disp/cursgv100.o
CC drivers/gpu/drm/nouveau/nvkm/engine/disp/oimmnv50.o
CC drivers/gpu/drm/nouveau/nvkm/engine/disp/oimmgf119.o
CC drivers/gpu/drm/nouveau/nvkm/engine/disp/oimmgp102.o
CC drivers/gpu/drm/nouveau/nvkm/engine/dma/nv04.o
CC drivers/gpu/drm/nouveau/nvkm/engine/dma/base.o
CC drivers/gpu/drm/nouveau/nvkm/engine/dma/nv50.o
CC drivers/gpu/drm/nouveau/nvkm/engine/dma/gf100.o
AR drivers/scsi/qla2xxx/built-in.a
CC drivers/gpu/drm/nouveau/nvkm/engine/dma/gf119.o
CC drivers/gpu/drm/nouveau/nvkm/engine/dma/gv100.o
CC drivers/gpu/drm/nouveau/nvkm/engine/dma/user.o
CC drivers/gpu/drm/nouveau/nvkm/engine/dma/usernv04.o
CC drivers/gpu/drm/nouveau/nvkm/engine/dma/usergf100.o
CC drivers/gpu/drm/nouveau/nvkm/engine/dma/usernv50.o
CC drivers/gpu/drm/nouveau/nvkm/engine/dma/usergf119.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv04.o
CC drivers/gpu/drm/nouveau/nvkm/engine/dma/usergv100.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/base.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv10.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv40.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv17.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv50.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/g84.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk110.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk208.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk20a.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gm107.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gm200.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gm20b.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gp100.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gp10b.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gv100.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/tu102.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/channv50.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/chang84.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv04.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv17.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv10.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv40.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv50.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmag84.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifonv50.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifog84.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogf100.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogk104.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogv100.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifotu102.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/usertu102.o
CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/usergv100.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/base.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv04.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv10.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv15.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv17.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv20.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv25.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv2a.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv30.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv34.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv35.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv44.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv40.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv50.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/g84.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gt200.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/mcp79.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gt215.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/mcp89.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gf104.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gf108.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gf110.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gf117.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gf119.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110b.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gk208.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gm107.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gm200.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gm20b.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gp100.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gp102.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gp104.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gp107.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gp10b.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gv100.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv40.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf104.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf108.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf110.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf119.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk20a.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm200.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgp100.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgp104.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm20b.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgp107.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgp102.o
CC drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv31.o
CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgv100.o
CC drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv40.o
CC drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv44.o
CC drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv50.o
CC drivers/gpu/drm/nouveau/nvkm/engine/mpeg/g84.o
CC drivers/gpu/drm/nouveau/nvkm/engine/mspdec/base.o
CC drivers/gpu/drm/nouveau/nvkm/engine/mspdec/g98.o
CC drivers/gpu/drm/nouveau/nvkm/engine/mspdec/gt215.o
CC drivers/gpu/drm/nouveau/nvkm/engine/mspdec/gf100.o
CC drivers/gpu/drm/nouveau/nvkm/engine/msppp/base.o
CC drivers/gpu/drm/nouveau/nvkm/engine/mspdec/gk104.o
CC drivers/gpu/drm/nouveau/nvkm/engine/msppp/g98.o
CC drivers/gpu/drm/nouveau/nvkm/engine/msppp/gt215.o
CC drivers/gpu/drm/nouveau/nvkm/engine/msvld/base.o
CC drivers/gpu/drm/nouveau/nvkm/engine/msppp/gf100.o
CC drivers/gpu/drm/nouveau/nvkm/engine/msvld/g98.o
CC drivers/gpu/drm/nouveau/nvkm/engine/msvld/gt215.o
CC drivers/gpu/drm/nouveau/nvkm/engine/msvld/mcp89.o
CC drivers/gpu/drm/nouveau/nvkm/engine/msvld/gf100.o
CC drivers/gpu/drm/nouveau/nvkm/engine/msvld/gk104.o
CC drivers/gpu/drm/nouveau/nvkm/engine/nvdec/base.o
CC drivers/gpu/drm/nouveau/nvkm/engine/nvdec/gp102.o
CC drivers/gpu/drm/nouveau/nvkm/engine/pm/base.o
CC drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.o
CC drivers/gpu/drm/nouveau/nvkm/engine/pm/nv50.o
CC drivers/gpu/drm/nouveau/nvkm/engine/pm/g84.o
CC drivers/gpu/drm/nouveau/nvkm/engine/pm/gt200.o
CC drivers/gpu/drm/nouveau/nvkm/engine/pm/gt215.o
CC drivers/gpu/drm/nouveau/nvkm/engine/pm/gf108.o
CC drivers/gpu/drm/nouveau/nvkm/engine/pm/gf117.o
CC drivers/gpu/drm/nouveau/nvkm/engine/pm/gf100.o
CC drivers/gpu/drm/nouveau/nvkm/engine/pm/gk104.o
CC drivers/gpu/drm/nouveau/nvkm/engine/sec/g98.o
CC drivers/gpu/drm/nouveau/nvkm/engine/sec2/base.o
CC drivers/gpu/drm/nouveau/nvkm/engine/sec2/gp102.o
CC drivers/gpu/drm/nouveau/nvkm/engine/sec2/tu102.o
CC drivers/gpu/drm/nouveau/nvkm/engine/sw/base.o
CC drivers/gpu/drm/nouveau/nvkm/engine/sw/nv04.o
CC drivers/gpu/drm/nouveau/nvkm/engine/sw/nv10.o
CC drivers/gpu/drm/nouveau/nvkm/engine/sw/nv50.o
CC drivers/gpu/drm/nouveau/nvkm/engine/sw/gf100.o
CC drivers/gpu/drm/nouveau/nvkm/engine/sw/chan.o
CC drivers/gpu/drm/nouveau/nvkm/engine/sw/nvsw.o
CC drivers/gpu/drm/nouveau/nvkm/engine/vp/g84.o
CC drivers/gpu/drm/nouveau/nouveau_acpi.o
CC drivers/gpu/drm/nouveau/nouveau_debugfs.o
CC drivers/gpu/drm/nouveau/nouveau_drm.o
CC drivers/gpu/drm/nouveau/nouveau_hwmon.o
CC drivers/gpu/drm/nouveau/nouveau_ioc32.o
CC drivers/gpu/drm/nouveau/nouveau_led.o
CC drivers/gpu/drm/nouveau/nouveau_nvif.o
CC drivers/gpu/drm/nouveau/nouveau_usif.o
CC drivers/gpu/drm/nouveau/nouveau_vga.o
CC drivers/gpu/drm/nouveau/nouveau_bo.o
CC drivers/gpu/drm/nouveau/nouveau_gem.o
CC drivers/gpu/drm/nouveau/nouveau_mem.o
CC drivers/gpu/drm/nouveau/nouveau_prime.o
CC drivers/gpu/drm/nouveau/nouveau_sgdma.o
CC drivers/gpu/drm/nouveau/nouveau_ttm.o
CC drivers/gpu/drm/nouveau/nouveau_vmm.o
CC drivers/gpu/drm/nouveau/nouveau_display.o
CC drivers/gpu/drm/nouveau/nouveau_backlight.o
CC drivers/gpu/drm/nouveau/nouveau_bios.o
CC drivers/gpu/drm/nouveau/nouveau_connector.o
CC drivers/gpu/drm/nouveau/nv04_fbcon.o
CC drivers/gpu/drm/nouveau/nv50_fbcon.o
CC drivers/gpu/drm/nouveau/nvc0_fbcon.o
CC drivers/gpu/drm/nouveau/nouveau_dp.o
CC drivers/gpu/drm/nouveau/nouveau_fbcon.o
CC drivers/gpu/drm/nouveau/dispnv04/arb.o
CC drivers/gpu/drm/nouveau/dispnv04/cursor.o
CC drivers/gpu/drm/nouveau/dispnv04/crtc.o
CC drivers/gpu/drm/nouveau/dispnv04/dfp.o
CC drivers/gpu/drm/nouveau/dispnv04/dac.o
CC drivers/gpu/drm/nouveau/dispnv04/hw.o
CC drivers/gpu/drm/nouveau/dispnv04/overlay.o
CC drivers/gpu/drm/nouveau/dispnv04/tvnv17.o
CC drivers/gpu/drm/nouveau/dispnv04/tvmodesnv17.o
CC drivers/gpu/drm/nouveau/dispnv04/tvnv04.o
CC drivers/gpu/drm/nouveau/dispnv50/core.o
CC drivers/gpu/drm/nouveau/dispnv50/lut.o
CC drivers/gpu/drm/nouveau/dispnv04/disp.o
CC drivers/gpu/drm/nouveau/dispnv50/disp.o
CC drivers/gpu/drm/nouveau/dispnv50/core507d.o
AR drivers/scsi/built-in.a
CC drivers/gpu/drm/nouveau/dispnv50/core827d.o
CC drivers/gpu/drm/nouveau/dispnv50/core907d.o
CC drivers/gpu/drm/nouveau/dispnv50/core917d.o
CC drivers/gpu/drm/nouveau/dispnv50/corec37d.o
CC drivers/gpu/drm/nouveau/dispnv50/corec57d.o
CC drivers/gpu/drm/nouveau/dispnv50/dac507d.o
CC drivers/gpu/drm/nouveau/dispnv50/dac907d.o
CC drivers/gpu/drm/nouveau/dispnv50/pior507d.o
CC drivers/gpu/drm/nouveau/dispnv50/sor507d.o
CC drivers/gpu/drm/nouveau/dispnv50/head507d.o
CC drivers/gpu/drm/nouveau/dispnv50/head.o
CC drivers/gpu/drm/nouveau/dispnv50/sorc37d.o
CC drivers/gpu/drm/nouveau/dispnv50/sor907d.o
CC drivers/gpu/drm/nouveau/dispnv50/head827d.o
CC drivers/gpu/drm/nouveau/dispnv50/head917d.o
CC drivers/gpu/drm/nouveau/dispnv50/head907d.o
CC drivers/gpu/drm/nouveau/dispnv50/headc37d.o
CC drivers/gpu/drm/nouveau/dispnv50/wimm.o
CC drivers/gpu/drm/nouveau/dispnv50/headc57d.o
CC drivers/gpu/drm/nouveau/dispnv50/wimmc37b.o
CC drivers/gpu/drm/nouveau/dispnv50/wndwc37e.o
CC drivers/gpu/drm/nouveau/dispnv50/wndw.o
CC drivers/gpu/drm/nouveau/dispnv50/base.o
CC drivers/gpu/drm/nouveau/dispnv50/wndwc57e.o
CC drivers/gpu/drm/nouveau/dispnv50/base507c.o
CC drivers/gpu/drm/nouveau/dispnv50/base827c.o
CC drivers/gpu/drm/nouveau/dispnv50/base907c.o
CC drivers/gpu/drm/nouveau/dispnv50/base917c.o
CC drivers/gpu/drm/nouveau/dispnv50/curs.o
CC drivers/gpu/drm/nouveau/dispnv50/curs507a.o
CC drivers/gpu/drm/nouveau/dispnv50/curs907a.o
CC drivers/gpu/drm/nouveau/dispnv50/cursc37a.o
CC drivers/gpu/drm/nouveau/dispnv50/oimm.o
CC drivers/gpu/drm/nouveau/dispnv50/oimm507b.o
CC drivers/gpu/drm/nouveau/dispnv50/ovly.o
CC drivers/gpu/drm/nouveau/dispnv50/ovly507e.o
CC drivers/gpu/drm/nouveau/dispnv50/ovly827e.o
CC drivers/gpu/drm/nouveau/dispnv50/ovly907e.o
CC drivers/gpu/drm/nouveau/dispnv50/ovly917e.o
CC drivers/gpu/drm/nouveau/nouveau_abi16.o
CC drivers/gpu/drm/nouveau/nouveau_dma.o
CC drivers/gpu/drm/nouveau/nouveau_chan.o
CC drivers/gpu/drm/nouveau/nouveau_fence.o
CC drivers/gpu/drm/nouveau/nv04_fence.o
CC drivers/gpu/drm/nouveau/nv10_fence.o
CC drivers/gpu/drm/nouveau/nv17_fence.o
CC drivers/gpu/drm/nouveau/nv50_fence.o
CC drivers/gpu/drm/nouveau/nv84_fence.o
CC drivers/gpu/drm/nouveau/nvc0_fence.o
AR drivers/gpu/drm/nouveau/built-in.a
AR drivers/gpu/drm/built-in.a
AR drivers/gpu/built-in.a
Makefile:1051: recipe for target 'drivers' failed
make: *** [drivers] Error 2
Error text is too large and was truncated, full error text is at:
https://syzkaller.appspot.com/x/error.txt?x=17a6b2f8a00000
Tested on:
commit: 43151d6c usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
patch: https://syzkaller.appspot.com/x/patch.diff?x=173a6c54a00000
^ permalink raw reply
* Re: KASAN: use-after-free Read in p54u_load_firmware_cb
From: Alan Stern @ 2019-05-17 20:46 UTC (permalink / raw)
To: Christian Lamparter
Cc: Oliver Neukum, syzbot, kvalo, davem, andreyknvl, syzkaller-bugs,
chunkeey, linux-kernel, linux-usb, linux-wireless, netdev,
Michael Wu
In-Reply-To: <5014675.0cgHOJIxtM@debian64>
On Fri, 17 May 2019, Christian Lamparter wrote:
> On Monday, May 13, 2019 3:28:30 PM CEST Oliver Neukum wrote:
> > On Mo, 2019-05-13 at 03:23 -0700, syzbot wrote:
> > > syzbot has found a reproducer for the following crash on:
> > >
> > > HEAD commit: 43151d6c usb-fuzzer: main usb gadget fuzzer driver
> > > git tree: https://github.com/google/kasan.git usb-fuzzer
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=16b64110a00000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=4183eeef650d1234
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=200d4bb11b23d929335f
> > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1634c900a00000
> > >
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+200d4bb11b23d929335f@syzkaller.appspotmail.com
> > >
> > > usb 1-1: config 0 descriptor??
> > > usb 1-1: reset high-speed USB device number 2 using dummy_hcd
> > > usb 1-1: device descriptor read/64, error -71
> > > usb 1-1: Using ep0 maxpacket: 8
> > > usb 1-1: Loading firmware file isl3887usb
> > > usb 1-1: Direct firmware load for isl3887usb failed with error -2
> > > usb 1-1: Firmware not found.
> > > ==================================================================
> > > BUG: KASAN: use-after-free in p54u_load_firmware_cb.cold+0x97/0x13a
> > > drivers/net/wireless/intersil/p54/p54usb.c:936
> > > Read of size 8 at addr ffff88809803f588 by task kworker/1:0/17
> >
> > Hi,
> >
> > it looks to me as if refcounting is broken.
> > You should have a usb_put_dev() in p54u_load_firmware_cb() or in
> > p54u_disconnect(), but not both.
>
> There's more to that refcounting that meets the eye. Do you see that
> request_firmware_nowait() in the driver? That's the async firmware
> request call that get's completed by the p54u_load_firmware_cb()
> So what's happening here is that the driver has to be protected
> against rmmod when the driver is waiting for request_firmware_nowait
> to "finally" callback, which depending on the system can be up to
> 60 seconds.
>
> Now, what seems to be odd is that it's at line 936
> > > BUG: KASAN: use-after-free in p54u_load_firmware_cb.cold+0x97/0x13a
> > > drivers/net/wireless/intersil/p54/p54usb.c:936
>
> because if you put it in context:
>
> |
> |static void p54u_load_firmware_cb(const struct firmware *firmware,
> | void *context)
> |{
> | struct p54u_priv *priv = context;
> | struct usb_device *udev = priv->udev;
> | int err;
> |
> | complete(&priv->fw_wait_load);
> | if (firmware) {
> | priv->fw = firmware;
> | err = p54u_start_ops(priv);
> | } else {
> | err = -ENOENT;
> | dev_err(&udev->dev, "Firmware not found.\n");
> | }
> |
> | if (err) {
> |>> >> struct device *parent = priv->udev->dev.parent; <<<<-- 936 is here
> |
> | dev_err(&udev->dev, "failed to initialize device (%d)\n", err);
> |
> | if (parent)
> | device_lock(parent);
> |
> | device_release_driver(&udev->dev);
> | /*
> | * At this point p54u_disconnect has already freed
> | * the "priv" context. Do not use it anymore!
> | */
> | priv = NULL;
> |
> | if (parent)
> | device_unlock(parent);
> | }
> |
> | usb_put_dev(udev);
> |}
>
> it seems very out of place, because at that line the device is still bound to
> the driver! Only with device_release_driver in line 942, I could see that
> something woulb be aray... !BUT! that's why we do have the extra
> usb_get_dev(udev) in p54u_load_firmware() so we can do the usb_put_dev(udev) in
> line 953 to ensure that nothing (like the rmmod I talked above) will interfere
> until everything is done.
>
> I've no idea what's wrong here, is gcc 9.0 aggressivly reording the put? Or is
> something else going on with the sanitizers? Because this report does look
> dogdy there!
>
> (Note: p54usb has !strategic! dev_err/infos in place right around the
> usb_get_dev/usb_put_dev so we can sort of tell the refvalue of the udev
> and it all seems to be correct from what I can gleam)
I agree; it doesn't seem to make sense. The nice thing about syzbot,
though, is you can ask it to run a debugging test for you. Let's start
by making sure that the faulty address really is &udev->dev.parent.
Alan
#syz test: https://github.com/google/kasan.git usb-fuzzer
drivers/net/wireless/intersil/p54/p54usb.c | 3 +++
1 file changed, 3 insertions(+)
Index: usb-devel/drivers/net/wireless/intersil/p54/p54usb.c
===================================================================
--- usb-devel.orig/drivers/net/wireless/intersil/p54/p54usb.c
+++ usb-devel/drivers/net/wireless/intersil/p54/p54usb.c
@@ -923,6 +923,7 @@ static void p54u_load_firmware_cb(const
struct usb_device *udev = priv->udev;
int err;
+ pr_info("%s: priv->udev = %px\n", __func__, udev);
complete(&priv->fw_wait_load);
if (firmware) {
priv->fw = firmware;
@@ -969,6 +970,8 @@ static int p54u_load_firmware(struct iee
if (i < 0)
return i;
+ dev_info(udev, "%s: udev @ %px, dev.parent @ %px\n",
+ __func__, udev, &udev->dev.parent);
dev_info(&priv->udev->dev, "Loading firmware file %s\n",
p54u_fwlist[i].fw);
^ permalink raw reply
* [PATCH 2/7] iw: fix endless loop inside handle_mgmt_dump
From: John Crispin @ 2019-05-17 19:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John Crispin
In-Reply-To: <20190517192956.18372-1-john@phrozen.org>
passing -1 will break the while loop further down in the code.
Signed-off-by: John Crispin <john@phrozen.org>
---
mgmt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mgmt.c b/mgmt.c
index 88fe3fd..338435d 100644
--- a/mgmt.c
+++ b/mgmt.c
@@ -109,6 +109,8 @@ static int handle_mgmt_dump(struct nl80211_state *state,
for (i = 3; i < argc; i += 3) {
if (strcmp(argv[i], "count") == 0) {
count = 1 + atoi(argv[i + 1]);
+ if (count < 1)
+ count = 1;
break;
}
--
2.20.1
^ permalink raw reply related
* [PATCH 3/7] iw: fix memory leak inside handle_cac
From: John Crispin @ 2019-05-17 19:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John Crispin
In-Reply-To: <20190517192956.18372-1-john@phrozen.org>
Signed-off-by: John Crispin <john@phrozen.org>
---
phy.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/phy.c b/phy.c
index 77df7a7..a4425ea 100644
--- a/phy.c
+++ b/phy.c
@@ -328,12 +328,15 @@ static int handle_cac(struct nl80211_state *state,
} else if (strcmp(argv[2], "freq") == 0) {
err = parse_freqchan(&chandef, false, argc - 3, argv + 3, NULL);
} else {
- return 1;
+ err = 1;
+ goto err_out;
}
cac_trigger_argv = calloc(argc + 1, sizeof(char*));
- if (!cac_trigger_argv)
- return -ENOMEM;
+ if (!cac_trigger_argv) {
+ err = -ENOMEM;
+ goto err_out;
+ }
cac_trigger_argv[0] = argv[0];
cac_trigger_argv[1] = "cac";
@@ -341,9 +344,8 @@ static int handle_cac(struct nl80211_state *state,
memcpy(&cac_trigger_argv[3], &argv[2], (argc - 2) * sizeof(char*));
err = handle_cmd(state, id, argc + 1, cac_trigger_argv);
- free(cac_trigger_argv);
if (err)
- return err;
+ goto err_out;
cac_event.ret = 1;
cac_event.freq = chandef.control_freq;
@@ -357,7 +359,13 @@ static int handle_cac(struct nl80211_state *state,
while (cac_event.ret > 0)
nl_recvmsgs(state->nl_sock, radar_cb);
- return 0;
+ err = 0;
+err_out:
+ if (radar_cb)
+ nl_cb_put(radar_cb);
+ if (cac_trigger_argv)
+ free(cac_trigger_argv);
+ return err;
}
TOPLEVEL(cac, "channel <channel> [NOHT|HT20|HT40+|HT40-|5MHz|10MHz|80MHz]\n"
"freq <freq> [NOHT|HT20|HT40+|HT40-|5MHz|10MHz|80MHz]\n"
--
2.20.1
^ permalink raw reply related
* [PATCH 5/7] iw: fix memory leak inside parse_sched_scan
From: John Crispin @ 2019-05-17 19:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John Crispin
In-Reply-To: <20190517192956.18372-1-john@phrozen.org>
Signed-off-by: John Crispin <john@phrozen.org>
---
scan.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scan.c b/scan.c
index b0b7828..980bfb4 100644
--- a/scan.c
+++ b/scan.c
@@ -355,11 +355,12 @@ int parse_sched_scan(struct nl_msg *msg, int *argc, char ***argv)
nla_put_failure:
if (match)
nla_nest_end(msg, match);
+out:
nlmsg_free(freqs);
nlmsg_free(matchset);
nlmsg_free(scan_plans);
+ nlmsg_free(ssids);
-out:
*argc = c;
*argv = v;
return err;
--
2.20.1
^ permalink raw reply related
* [PATCH 0/7] iw: various bug fixes
From: John Crispin @ 2019-05-17 19:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John Crispin
These fixes were extracted from the latest Intel/UGW. I am assuming they
ran static code analyses/Klocwork in the source.
John Crispin (7):
iw: fix memory leak inside register_mgmt_frame
iw: fix endless loop inside handle_mgmt_dump
iw: fix memory leak inside handle_cac
iw: fix fd leak inside handle_netns
iw: fix memory leak inside parse_sched_scan
iw: fix memory leaks inside handle_scan
iw: fix fp handling inside handle_vendor
mgmt.c | 4 ++++
phy.c | 25 ++++++++++++++++++-------
scan.c | 34 +++++++++++++++++-----------------
vendor.c | 5 ++++-
4 files changed, 43 insertions(+), 25 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH 1/7] iw: fix memory leak inside register_mgmt_frame
From: John Crispin @ 2019-05-17 19:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John Crispin
In-Reply-To: <20190517192956.18372-1-john@phrozen.org>
Signed-off-by: John Crispin <john@phrozen.org>
---
mgmt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mgmt.c b/mgmt.c
index 60f544b..88fe3fd 100644
--- a/mgmt.c
+++ b/mgmt.c
@@ -69,9 +69,11 @@ static int register_mgmt_frame(struct nl80211_state *state,
NLA_PUT_U16(msg, NL80211_ATTR_FRAME_TYPE, type);
NLA_PUT(msg, NL80211_ATTR_FRAME_MATCH, match_len, match);
+ free(match);
return 0;
nla_put_failure:
+ free(match);
return -ENOBUFS;
}
--
2.20.1
^ permalink raw reply related
* [PATCH 6/7] iw: fix memory leaks inside handle_scan
From: John Crispin @ 2019-05-17 19:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John Crispin
In-Reply-To: <20190517192956.18372-1-john@phrozen.org>
Signed-off-by: John Crispin <john@phrozen.org>
---
scan.c | 31 +++++++++++++++----------------
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/scan.c b/scan.c
index 980bfb4..6ad3ad4 100644
--- a/scan.c
+++ b/scan.c
@@ -389,7 +389,7 @@ static int handle_scan(struct nl80211_state *state,
bool passive = false, have_ssids = false, have_freqs = false;
bool duration_mandatory = false;
size_t ies_len = 0, meshid_len = 0;
- unsigned char *ies = NULL, *meshid = NULL, *tmpies;
+ unsigned char *ies = NULL, *meshid = NULL, *tmpies = NULL;
unsigned int flags = 0;
ssids = nlmsg_alloc();
@@ -450,7 +450,8 @@ static int handle_scan(struct nl80211_state *state,
case DONE:
nlmsg_free(ssids);
nlmsg_free(freqs);
- return 1;
+ err = 1;
+ goto nla_put_failure;
case FREQ:
freq = strtoul(argv[i], &eptr, 10);
if (eptr != argv[i] + strlen(argv[i])) {
@@ -462,6 +463,8 @@ static int handle_scan(struct nl80211_state *state,
NLA_PUT_U32(freqs, i, freq);
break;
case IES:
+ if (ies)
+ free(ies);
ies = parse_hex(argv[i], &ies_len);
if (!ies)
goto nla_put_failure;
@@ -490,24 +493,14 @@ static int handle_scan(struct nl80211_state *state,
if (ies || meshid) {
tmpies = (unsigned char *) malloc(ies_len + meshid_len);
- if (!tmpies) {
- free(ies);
- free(meshid);
+ if (!tmpies)
goto nla_put_failure;
- }
- if (ies) {
+ if (ies)
memcpy(tmpies, ies, ies_len);
- free(ies);
- }
- if (meshid) {
+ if (meshid)
memcpy(&tmpies[ies_len], meshid, meshid_len);
- free(meshid);
- }
- if (nla_put(msg, NL80211_ATTR_IE, ies_len + meshid_len, tmpies) < 0) {
- free(tmpies);
+ if (nla_put(msg, NL80211_ATTR_IE, ies_len + meshid_len, tmpies) < 0)
goto nla_put_failure;
- }
- free(tmpies);
}
if (!have_ssids)
@@ -535,6 +528,12 @@ static int handle_scan(struct nl80211_state *state,
nla_put_failure:
nlmsg_free(ssids);
nlmsg_free(freqs);
+ if (meshid)
+ free(meshid);
+ if (ies)
+ free(ies);
+ if (tmpies)
+ free(tmpies);
return err;
}
--
2.20.1
^ permalink raw reply related
* [PATCH 7/7] iw: fix fp handling inside handle_vendor
From: John Crispin @ 2019-05-17 19:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John Crispin
In-Reply-To: <20190517192956.18372-1-john@phrozen.org>
The fp can leak and should not be closed if we do i/o redirection.
Signed-off-by: John Crispin <john@phrozen.org>
---
vendor.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/vendor.c b/vendor.c
index 860cd48..d203d85 100644
--- a/vendor.c
+++ b/vendor.c
@@ -107,7 +107,8 @@ static int handle_vendor(struct nl80211_state *state,
if (file) {
count = read_file(file, buf, sizeof(buf));
- fclose(file);
+ if (file != stdin)
+ fclose(file);
} else
count = read_hex(argc - 2, &argv[2], buf, sizeof(buf));
@@ -120,6 +121,8 @@ static int handle_vendor(struct nl80211_state *state,
return 0;
nla_put_failure:
+ if (file && file != stdin)
+ fclose(file);
return -ENOBUFS;
}
--
2.20.1
^ permalink raw reply related
* [PATCH 4/7] iw: fix fd leak inside handle_netns
From: John Crispin @ 2019-05-17 19:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John Crispin
In-Reply-To: <20190517192956.18372-1-john@phrozen.org>
Signed-off-by: John Crispin <john@phrozen.org>
---
phy.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/phy.c b/phy.c
index a4425ea..ba89d46 100644
--- a/phy.c
+++ b/phy.c
@@ -1,6 +1,7 @@
#include <stdbool.h>
#include <errno.h>
#include <strings.h>
+#include <unistd.h>
#include <sys/param.h>
#include <sys/stat.h>
#include <fcntl.h>
@@ -531,7 +532,7 @@ static int handle_netns(struct nl80211_state *state,
enum id_input id)
{
char *end;
- int fd;
+ int fd = -1;
if (argc < 1 || !*argv[0])
return 1;
@@ -559,6 +560,8 @@ static int handle_netns(struct nl80211_state *state,
return 1;
nla_put_failure:
+ if (fd >= 0)
+ close(fd);
return -ENOBUFS;
}
COMMAND(set, netns, "{ <pid> | name <nsname> }",
--
2.20.1
^ permalink raw reply related
* Re: KASAN: use-after-free Read in p54u_load_firmware_cb
From: Christian Lamparter @ 2019-05-17 19:21 UTC (permalink / raw)
To: Oliver Neukum
Cc: syzbot, kvalo, davem, andreyknvl, syzkaller-bugs, chunkeey,
linux-kernel, linux-usb, linux-wireless, netdev, Michael Wu
In-Reply-To: <1557754110.2793.7.camel@suse.com>
On Monday, May 13, 2019 3:28:30 PM CEST Oliver Neukum wrote:
> On Mo, 2019-05-13 at 03:23 -0700, syzbot wrote:
> > syzbot has found a reproducer for the following crash on:
> >
> > HEAD commit: 43151d6c usb-fuzzer: main usb gadget fuzzer driver
> > git tree: https://github.com/google/kasan.git usb-fuzzer
> > console output: https://syzkaller.appspot.com/x/log.txt?x=16b64110a00000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=4183eeef650d1234
> > dashboard link: https://syzkaller.appspot.com/bug?extid=200d4bb11b23d929335f
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1634c900a00000
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+200d4bb11b23d929335f@syzkaller.appspotmail.com
> >
> > usb 1-1: config 0 descriptor??
> > usb 1-1: reset high-speed USB device number 2 using dummy_hcd
> > usb 1-1: device descriptor read/64, error -71
> > usb 1-1: Using ep0 maxpacket: 8
> > usb 1-1: Loading firmware file isl3887usb
> > usb 1-1: Direct firmware load for isl3887usb failed with error -2
> > usb 1-1: Firmware not found.
> > ==================================================================
> > BUG: KASAN: use-after-free in p54u_load_firmware_cb.cold+0x97/0x13a
> > drivers/net/wireless/intersil/p54/p54usb.c:936
> > Read of size 8 at addr ffff88809803f588 by task kworker/1:0/17
>
> Hi,
>
> it looks to me as if refcounting is broken.
> You should have a usb_put_dev() in p54u_load_firmware_cb() or in
> p54u_disconnect(), but not both.
There's more to that refcounting that meets the eye. Do you see that
request_firmware_nowait() in the driver? That's the async firmware
request call that get's completed by the p54u_load_firmware_cb()
So what's happening here is that the driver has to be protected
against rmmod when the driver is waiting for request_firmware_nowait
to "finally" callback, which depending on the system can be up to
60 seconds.
Now, what seems to be odd is that it's at line 936
> > BUG: KASAN: use-after-free in p54u_load_firmware_cb.cold+0x97/0x13a
> > drivers/net/wireless/intersil/p54/p54usb.c:936
because if you put it in context:
|
|static void p54u_load_firmware_cb(const struct firmware *firmware,
| void *context)
|{
| struct p54u_priv *priv = context;
| struct usb_device *udev = priv->udev;
| int err;
|
| complete(&priv->fw_wait_load);
| if (firmware) {
| priv->fw = firmware;
| err = p54u_start_ops(priv);
| } else {
| err = -ENOENT;
| dev_err(&udev->dev, "Firmware not found.\n");
| }
|
| if (err) {
|>> >> struct device *parent = priv->udev->dev.parent; <<<<-- 936 is here
|
| dev_err(&udev->dev, "failed to initialize device (%d)\n", err);
|
| if (parent)
| device_lock(parent);
|
| device_release_driver(&udev->dev);
| /*
| * At this point p54u_disconnect has already freed
| * the "priv" context. Do not use it anymore!
| */
| priv = NULL;
|
| if (parent)
| device_unlock(parent);
| }
|
| usb_put_dev(udev);
|}
it seems very out of place, because at that line the device is still bound to
the driver! Only with device_release_driver in line 942, I could see that
something woulb be aray... !BUT! that's why we do have the extra
usb_get_dev(udev) in p54u_load_firmware() so we can do the usb_put_dev(udev) in
line 953 to ensure that nothing (like the rmmod I talked above) will interfere
until everything is done.
I've no idea what's wrong here, is gcc 9.0 aggressivly reording the put? Or is
something else going on with the sanitizers? Because this report does look
dogdy there!
(Note: p54usb has !strategic! dev_err/infos in place right around the
usb_get_dev/usb_put_dev so we can sort of tell the refvalue of the udev
and it all seems to be correct from what I can gleam)
Regards,
Christian
^ permalink raw reply
* Re: [PATCH 3/7] brcmsmac: switch source files to using SPDX license identifier
From: Arend Van Spriel @ 2019-05-17 18:22 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Greg Kroah-Hartman, Kalle Valo, linux-wireless@vger.kernel.org,
Thomas Gleixner
In-Reply-To: <CACna6rxuSFWN8eib7FpJiVQqLwdD5GOTaAFr7msJa01rBSTLKA@mail.gmail.com>
On 5/17/2019 8:07 PM, Rafał Miłecki wrote:
> On Fri, 17 May 2019 at 01:25, Arend Van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 5/16/2019 10:01 PM, Greg Kroah-Hartman wrote:
>>> On Thu, May 16, 2019 at 09:45:19PM +0200, Arend Van Spriel wrote:
>>>> On 5/16/2019 7:31 PM, Greg Kroah-Hartman wrote:
>>>>> On Thu, May 16, 2019 at 02:04:07PM +0200, Arend van Spriel wrote:
>>>>>> With ISC license text in place under the LICENSES folder switch
>>>>>> to using the SPDX license identifier to refer to the ISC license.
>>>>>>
>>>>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>>>>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>>>> Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
>>>>>> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
>>>>>> Reviewed-by: Franky Lin <franky.lin@broadcom.com>
>>>>>> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>>>>>> ---
>>>>>> Hi Thomas, Greg,
>>>>>>
>>>>>> The file drivers/net/wireless/broadcom/brcm80211/brcmsmac/led.c
>>>>>> did not have license information nor copyright notice and as such
>>>>>> it got included in commit b24413180f56 ("License cleanup: add SPDX
>>>>>> GPL-2.0 license identifier to files with no license"). I added you
>>>>>> guys as I propose to align this source file with the rest of
>>>>>> the driver sources and change it to ISC license and add the missing
>>>>>> copyright notice while at it (not sure if that warrants a separate
>>>>>> patch).
>>>>>
>>>>> A separate patch would be good, to make it explicit that you are
>>>>> changing the license of the file.
>>>>
>>>> Ok.
>>>>
>>>>> And ISC, ick, why... :)
>>>>
>>>> Because the license text in the other driver source files is a 1:1 match
>>>> with the ISC license.
>>>
>>> Oh, I am not disagreeing with that, yes, that is obviously the license
>>> of the files. Just complaining about that choice for Linux kernel code :)
>>
>> I see.
>>
>>>> Another option could be MIT license which is in the preferred folder.
>>>> Will have to consult our legal department about it though.
>>>
>>> Hey, if your legal department is going to get asked this, why not just
>>> switch it to GPLv2? That would make everything much simpler.
>>
>> Hah. Because I already know the answer to that. ;-)
>
> It's not that obvious to me, sorry. Does your legal department require
> something more permissive than GPLv2? Is that worth asking them about
> dual-licensing? Something like
> GPL-2.0 OR MIT
> ? That assures driver is compatible with Linux, no matter what's the
> current lawyers interpretation of MIT vs. GPL 2.0. I believe Alan Cox
> once told/suggested that dual-licensing is safer for legal reasons.
Thanks, Rafał
Indeed we want a more permissive license. I decided to stick with ISC
for now. MIT is not off the table, but pending responses from copyright
holders. If you or anyone else for that matter has additional and/or
more accurate information about dual-licensing (and its legal safety)
please let me know.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 3/7] brcmsmac: switch source files to using SPDX license identifier
From: Rafał Miłecki @ 2019-05-17 18:07 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Greg Kroah-Hartman, Kalle Valo, linux-wireless@vger.kernel.org,
Thomas Gleixner
In-Reply-To: <eeebea29-4237-6e49-7578-8d3b1ad7df85@broadcom.com>
On Fri, 17 May 2019 at 01:25, Arend Van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 5/16/2019 10:01 PM, Greg Kroah-Hartman wrote:
> > On Thu, May 16, 2019 at 09:45:19PM +0200, Arend Van Spriel wrote:
> >> On 5/16/2019 7:31 PM, Greg Kroah-Hartman wrote:
> >>> On Thu, May 16, 2019 at 02:04:07PM +0200, Arend van Spriel wrote:
> >>>> With ISC license text in place under the LICENSES folder switch
> >>>> to using the SPDX license identifier to refer to the ISC license.
> >>>>
> >>>> Cc: Thomas Gleixner <tglx@linutronix.de>
> >>>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >>>> Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
> >>>> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
> >>>> Reviewed-by: Franky Lin <franky.lin@broadcom.com>
> >>>> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> >>>> ---
> >>>> Hi Thomas, Greg,
> >>>>
> >>>> The file drivers/net/wireless/broadcom/brcm80211/brcmsmac/led.c
> >>>> did not have license information nor copyright notice and as such
> >>>> it got included in commit b24413180f56 ("License cleanup: add SPDX
> >>>> GPL-2.0 license identifier to files with no license"). I added you
> >>>> guys as I propose to align this source file with the rest of
> >>>> the driver sources and change it to ISC license and add the missing
> >>>> copyright notice while at it (not sure if that warrants a separate
> >>>> patch).
> >>>
> >>> A separate patch would be good, to make it explicit that you are
> >>> changing the license of the file.
> >>
> >> Ok.
> >>
> >>> And ISC, ick, why... :)
> >>
> >> Because the license text in the other driver source files is a 1:1 match
> >> with the ISC license.
> >
> > Oh, I am not disagreeing with that, yes, that is obviously the license
> > of the files. Just complaining about that choice for Linux kernel code :)
>
> I see.
>
> >> Another option could be MIT license which is in the preferred folder.
> >> Will have to consult our legal department about it though.
> >
> > Hey, if your legal department is going to get asked this, why not just
> > switch it to GPLv2? That would make everything much simpler.
>
> Hah. Because I already know the answer to that. ;-)
It's not that obvious to me, sorry. Does your legal department require
something more permissive than GPLv2? Is that worth asking them about
dual-licensing? Something like
GPL-2.0 OR MIT
? That assures driver is compatible with Linux, no matter what's the
current lawyers interpretation of MIT vs. GPL 2.0. I believe Alan Cox
once told/suggested that dual-licensing is safer for legal reasons.
--
Rafał
^ permalink raw reply
* Re: [PATCH 1/7] brcm80211: switch common header files to using SPDX license identifier
From: Arend Van Spriel @ 2019-05-17 18:04 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <3dcbfbab-a1f0-bdc6-909a-d9ed225e060a@broadcom.com>
On 5/16/2019 10:57 PM, Arend Van Spriel wrote:
> On 5/16/2019 2:04 PM, Arend van Spriel wrote:
>> With ISC license text in place under the LICENSES folder switch
>> to using the SPDX license identifier to refer to the ISC license.
>
> Hi Kalle,
>
> Given the feedback on checkpatch (or spdxcheck) failures let me respin
> this series.
Actually let's *NOT* respin and leave this series as is and ignore the
warning for the header files as Thomas wrote in his response: " So we
can fixup the documentation and allow // style for headers as well.".
Regards,
Arend
^ permalink raw reply
* [PATCH 1/2] ath10k: move pktlog connect service before htc start
From: Abhishek Ambure @ 2019-05-17 10:05 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Abhishek Ambure
In-Reply-To: <1558087516-666-1-git-send-email-aambure@codeaurora.org>
WCN3990 supports HTC service for pktlog. PKTLOG service should be
connected before HTC start. Hence move connect pktlog service before
HTC start
Fixes: 713358c321f4 ("ath10k: enable pktlog for WCN3990 target")
Tested HW: WCN3990
Tested FW: WLAN.HL.3.1-00963-QCAHLSWMTPL-1
Signed-off-by: Abhishek Ambure <aambure@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/htc.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htc.c b/drivers/net/wireless/ath/ath10k/htc.c
index 805a7f8..e2980fe9 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -893,6 +893,14 @@ int ath10k_htc_start(struct ath10k_htc *htc)
int status = 0;
struct ath10k_htc_msg *msg;
+ if (ath10k_htc_pktlog_svc_supported(ar)) {
+ status = ath10k_htc_pktlog_connect(ar);
+ if (status) {
+ ath10k_err(ar, "failed to connect to pktlog: %d\n", status);
+ return status;
+ }
+ }
+
skb = ath10k_htc_build_tx_ctrl_skb(htc->ar);
if (!skb)
return -ENOMEM;
@@ -919,14 +927,6 @@ int ath10k_htc_start(struct ath10k_htc *htc)
return status;
}
- if (ath10k_htc_pktlog_svc_supported(ar)) {
- status = ath10k_htc_pktlog_connect(ar);
- if (status) {
- ath10k_err(ar, "failed to connect to pktlog: %d\n", status);
- return status;
- }
- }
-
return 0;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] ath10k: correct wmi_tlv command params to enable pktlog for WCN3990
From: Abhishek Ambure @ 2019-05-17 10:05 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Abhishek Ambure
In-Reply-To: <1558087516-666-1-git-send-email-aambure@codeaurora.org>
PKT log enable command expects pdev id in enable params which is missing
in current configuration. Fill pdev id in pkt log enable wmi command for
correct configuration.
Fixes: ca996ec56608 ("ath10k: implement wmi-tlv backend")
Tested HW: WCN3990
Tested FW: WLAN.HL.3.1-00963-QCAHLSWMTPL-1
Signed-off-by: Abhishek Ambure <aambure@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 2 ++
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index 582fb11..8a209f8 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -2981,6 +2981,8 @@ static void *ath10k_wmi_tlv_put_wmm(void *ptr,
tlv->len = __cpu_to_le16(sizeof(*cmd));
cmd = (void *)tlv->value;
cmd->filter = __cpu_to_le32(filter);
+ cmd->pdev_id = __cpu_to_le32(0);
+ cmd->reserved = __cpu_to_le32(0);
ptr += sizeof(*tlv);
ptr += sizeof(*cmd);
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.h b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
index 65e6aa5..5226283 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
@@ -1923,6 +1923,7 @@ struct wmi_tlv_vdev_stats {
} __packed;
struct wmi_tlv_pktlog_enable {
+ __le32 pdev_id;
__le32 reserved;
__le32 filter;
} __packed;
--
1.9.1
^ permalink raw reply related
* [PATCH 0/2] correction in pktlog service connect and pktlog enable command
From: Abhishek Ambure @ 2019-05-17 10:05 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Abhishek Ambure
WCN3990 firmware supports htc pktlog service through which host driver
gets pktlog information. Pktlog service should be connected before htc
start command, hence pktlog connect is moved before htc start.
WCN3990 firwmare expects pdev_id along with filter and reserved params to
enable pktlog htc service. So adding pdev_id in pktlog enable comamnd
params.
Tested HW: WCN3990
Tested FW: WLAN.HL.3.1-00963-QCAHLSWMTPL-1
Abhishek Ambure (2):
ath10k: move pktlog connect service before htc start
ath10k: correct wmi_tlv command params to enable pktlog for WCN3990
drivers/net/wireless/ath/ath10k/htc.c | 16 ++++++++--------
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 2 ++
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 1 +
3 files changed, 11 insertions(+), 8 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH v2] mt76: mt7615: add support for mtd eeprom parsing
From: Lorenzo Bianconi @ 2019-05-17 6:26 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo
In-Reply-To: <cover.1558074163.git.lorenzo@kernel.org>
Calibration data are often available on a specific mtd partition on
embedded devices. Take into account eeprom calibration data if
available.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
Changes since v1:
- remove TODO comment
- take into account mtd partition even if otp one is empty
---
.../wireless/mediatek/mt76/mt7615/eeprom.c | 29 +++++++++++++++----
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
index dd5ab46a4f66..1712f66520a8 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
@@ -42,13 +42,13 @@ static int mt7615_efuse_read(struct mt7615_dev *dev, u32 base,
static int mt7615_efuse_init(struct mt7615_dev *dev)
{
- u32 base = mt7615_reg_map(dev, MT_EFUSE_BASE);
- int len = MT7615_EEPROM_SIZE;
- int ret, i;
+ u32 val, base = mt7615_reg_map(dev, MT_EFUSE_BASE);
+ int i, len = MT7615_EEPROM_SIZE;
void *buf;
- if (mt76_rr(dev, base + MT_EFUSE_BASE_CTRL) & MT_EFUSE_BASE_CTRL_EMPTY)
- return -EINVAL;
+ val = mt76_rr(dev, base + MT_EFUSE_BASE_CTRL);
+ if (val & MT_EFUSE_BASE_CTRL_EMPTY)
+ return 0;
dev->mt76.otp.data = devm_kzalloc(dev->mt76.dev, len, GFP_KERNEL);
dev->mt76.otp.size = len;
@@ -57,6 +57,8 @@ static int mt7615_efuse_init(struct mt7615_dev *dev)
buf = dev->mt76.otp.data;
for (i = 0; i + 16 <= len; i += 16) {
+ int ret;
+
ret = mt7615_efuse_read(dev, base, i, buf + i);
if (ret)
return ret;
@@ -76,6 +78,18 @@ static int mt7615_eeprom_load(struct mt7615_dev *dev)
return mt7615_efuse_init(dev);
}
+static int mt7615_check_eeprom(struct mt76_dev *dev)
+{
+ u16 val = get_unaligned_le16(dev->eeprom.data);
+
+ switch (val) {
+ case 0x7615:
+ return 0;
+ default:
+ return -EINVAL;
+ }
+}
+
int mt7615_eeprom_init(struct mt7615_dev *dev)
{
int ret;
@@ -84,7 +98,10 @@ int mt7615_eeprom_init(struct mt7615_dev *dev)
if (ret < 0)
return ret;
- memcpy(dev->mt76.eeprom.data, dev->mt76.otp.data, MT7615_EEPROM_SIZE);
+ ret = mt7615_check_eeprom(&dev->mt76);
+ if (ret && dev->mt76.otp.data)
+ memcpy(dev->mt76.eeprom.data, dev->mt76.otp.data,
+ MT7615_EEPROM_SIZE);
dev->mt76.cap.has_2ghz = true;
dev->mt76.cap.has_5ghz = true;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 1/7] brcm80211: switch common header files to using SPDX license identifier
From: Arend Van Spriel @ 2019-05-16 20:57 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <1558008251-13692-2-git-send-email-arend.vanspriel@broadcom.com>
On 5/16/2019 2:04 PM, Arend van Spriel wrote:
> With ISC license text in place under the LICENSES folder switch
> to using the SPDX license identifier to refer to the ISC license.
Hi Kalle,
Given the feedback on checkpatch (or spdxcheck) failures let me respin
this series.
Gr. AvS
^ 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