Linux wireless drivers development
 help / color / mirror / Atom feed
* Re: [PATCH][next] qtnfmac: replace qtnf_cmd_acl_data_size() with struct_size()
From: Sergey Matyukevich @ 2019-04-04 13:32 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Igor Mitsyanko, Avinash Patil, Sergey Matyukevich, Kalle Valo,
	David S. Miller, linux-wireless@vger.kernel.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20190403170236.GA31637@embeddedor>

> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
> 
> struct foo {
>     int stuff;
>     struct boo entry[];
> };
> 
> size = sizeof(struct foo) + count * sizeof(struct boo);
> instance = kzalloc(size, GFP_KERNEL)
> 
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
> 
> size = struct_size(instance, entry, count);
> 
> or
> 
> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL)
> 
> Based on the above, replace qtnf_cmd_acl_data_size() with the
> new struct_size() helper.
> 
> This code was detected with the help of Coccinelle.
> 
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> ---
>  drivers/net/wireless/quantenna/qtnfmac/commands.c | 15 ++++-----------
>  1 file changed, 4 insertions(+), 11 deletions(-)

Hi Gustavo,

Thanks for the patch! By the way, it does not apply cleanly, so it needs
to be rebased on top of the up-to-date wireless-drivers-next tree. Let
me know if you would prefer me to care about rebase. Then I will
add this patch to the upcoming series of qtnfmac fixes.

Reviewed-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>

Regards,
Sergey

^ permalink raw reply

* Re: FW: [PATCH v2] ath10k: Report low ack rssi based on the reason code
From: Rakesh Pillai @ 2019-04-04 12:11 UTC (permalink / raw)
  To: peter.oh; +Cc: ath10k, linux-wireless
In-Reply-To: <8c3110f20aec4c4a90bb679c4551b1fc@aphydexm01b.ap.qualcomm.com>

>> diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
>> b/drivers/net/wireless/ath/ath10k/wmi.h
>> index e1c40bb..3ccd79e 100644
>> --- a/drivers/net/wireless/ath/ath10k/wmi.h
>> +++ b/drivers/net/wireless/ath/ath10k/wmi.h
>> @@ -6797,6 +6797,8 @@ struct wmi_vdev_start_ev_arg {
>> 
>>   struct wmi_peer_kick_ev_arg {
>>   	const u8 *mac_addr;
>> +	u32 reason;
>> +	bool reason_code_valid;
>>   };
>> 
> Adding extra members to this structure breaks structure consistency
> between FW and host driver since FW doesn't have such members.
> 
> Peter
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k

struct wmi_peer_sta_kickout_event is used for parsing event from non-tlv 
firmwares and
struct wmi_tlv_peer_sta_kickout_event  is used for parsing event from 
tlv firmwares.
Both of the above structures maintain consistency with the respective 
FW.

struct wmi_peer_kick_ev_arg is used only for internal ath10k operations 
only.

Thanks,
Rakesh Pillai.

^ permalink raw reply

* Re: [PATCH] rtlwifi: move spin_lock_bh to spin_lock in tasklet
From: Kalle Valo @ 2019-04-04 10:27 UTC (permalink / raw)
  To: Jeff Xie
  Cc: pkshih, davem, linux-wireless, netdev, linux-kernel, chongguiguzi
In-Reply-To: <1553005870-28018-1-git-send-email-chongguiguzi@gmail.com>

Jeff Xie <chongguiguzi@gmail.com> wrote:

> It is unnecessary to call spin_lock_bh in a tasklet.
> 
> Signed-off-by: Jeff Xie <chongguiguzi@gmail.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>

Patch applied to wireless-drivers-next.git, thanks.

38bb0baea310 rtlwifi: move spin_lock_bh to spin_lock in tasklet

-- 
https://patchwork.kernel.org/patch/10859681/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply

* Re: [PATCH] rtlwifi: fix potential NULL pointer dereference
From: Kalle Valo @ 2019-04-04 10:25 UTC (permalink / raw)
  To: pkshih; +Cc: linux-wireless, Larry.Finger, kjlu
In-Reply-To: <20190312090648.30750-1-pkshih@realtek.com>

<pkshih@realtek.com> wrote:

> From: Ping-Ke Shih <pkshih@realtek.com>
> 
> In case dev_alloc_skb fails, the fix safely returns to avoid
> potential NULL pointer dereference.
> 
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

Patch applied to wireless-drivers-next.git, thanks.

60209d482b97 rtlwifi: fix potential NULL pointer dereference

-- 
https://patchwork.kernel.org/patch/10848803/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply

* Re: [PATCH] rtlwifi: fix a potential NULL pointer dereference
From: Kalle Valo @ 2019-04-04 10:25 UTC (permalink / raw)
  To: Kangjie Lu
  Cc: kjlu, pakki001, Ping-Ke Shih, David S. Miller, linux-wireless,
	netdev, linux-kernel
In-Reply-To: <20190312075633.573-1-kjlu@umn.edu>

Kangjie Lu <kjlu@umn.edu> wrote:

> In case alloc_workqueue fails, the fix reports the error and
> returns to avoid NULL pointer dereference.
> 
> Signed-off-by: Kangjie Lu <kjlu@umn.edu>

Patch applied to wireless-drivers-next.git, thanks.

765976285a8c rtlwifi: fix a potential NULL pointer dereference

-- 
https://patchwork.kernel.org/patch/10848697/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply

* Re: [PATCH 1/2] rtlwifi: Fix duplicate tests of one of the RX descriptors
From: Kalle Valo @ 2019-04-04 10:24 UTC (permalink / raw)
  To: Larry Finger; +Cc: linux-wireless, pkshih, Larry Finger
In-Reply-To: <20190304215940.2608-2-Larry.Finger@lwfinger.net>

Larry Finger <Larry.Finger@lwfinger.net> wrote:

> In drivers rtl8188ee, rtl8821ae, rtl8723be, and rtl8192ee, the reason
> for a wake-up is returned in the fourth RX descriptor in bits 29-31. Due
> to typographical errors, all but rtl8821ae test bit 31 twice and fail to
> test bit 29.
> 
> This error causes no problems as the tests are only used to set bits in
> a quantity output in an optional debugging statement.
> 
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>

Failed to apply:

fatal: sha1 information is lacking or useless (drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c).
error: could not build fake ancestor
Applying: rtlwifi: Convert the wake_match variable to local
Patch failed at 0001 rtlwifi: Convert the wake_match variable to local
The copy of the patch that failed is found in: .git/rebase-apply/patch

2 patches set to Changes Requested.

10838677 [1/2] rtlwifi: Fix duplicate tests of one of the RX descriptors
10838679 [2/2] rtlwifi: Convert the wake_match variable to local

-- 
https://patchwork.kernel.org/patch/10838677/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply

* Re: [PATCH 3/4] mwifiex: Flag wake-up interrupt as IRQ_NOAUTOEN rather than disabling it too late
From: Kalle Valo @ 2019-04-04 10:22 UTC (permalink / raw)
  To: Marc Zyngier
  Cc: Amitkumar Karwar, Enric Balletbo i Serra, Ganapathi Bhat,
	Heiko Stuebner, Nishant Sarmukadam, Rob Herring, Xinming Hu,
	David S. Miller, devicetree, linux-arm-kernel, linux-kernel,
	linux-rockchip, linux-wireless, netdev
In-Reply-To: <20190224140426.3267-4-marc.zyngier@arm.com>

Marc Zyngier <marc.zyngier@arm.com> wrote:

> The mwifiex driver makes unsafe assumptions about the state of the
> wake-up interrupt. It requests it and only then disable it. Of
> course, the interrupt may be screaming for whatever reason at that
> time, and the handler will then be called without the interrupt
> having been registered with the PM/wakeup subsystem. Oops.
> 
> The right way to handle this kind of situation is to flag the
> interrupt with IRQ_NOAUTOEN before requesting it. It will then
> stay disabled until someone (the wake-up subsystem) enables it.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> Reviewed-by: Brian Norris <briannorris@chromium.org>

Failed to apply:

fatal: sha1 information is lacking or useless (drivers/net/wireless/marvell/mwifiex/main.c).
error: could not build fake ancestor
Applying: mwifiex: Flag wake-up interrupt as IRQ_NOAUTOEN rather than disabling it too late
Patch failed at 0001 mwifiex: Flag wake-up interrupt as IRQ_NOAUTOEN rather than disabling it too late
The copy of the patch that failed is found in: .git/rebase-apply/patch

Patch set to Changes Requested.

-- 
https://patchwork.kernel.org/patch/10827971/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply

* Re: [PATCH] mwifiex: add a bounds check in mwifiex_process_sta_rx_packet()
From: Kalle Valo @ 2019-04-04 10:21 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
	linux-wireless, kernel-janitors
In-Reply-To: <20190402070338.GB15171@kadam>

Dan Carpenter <dan.carpenter@oracle.com> wrote:

> Smatch complains that "local_rx_pd->priority" can't be trusted because
> it comes from skb->data and it can go up to 255 instead of being capped
> in the 0-7 range.  A few lines earlier, on the other side of the if
> statement, we cap priority so it seems harmless to add a bounds check
> here as well.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> Reviewed-by: Brian Norris <briannorris@chromium.org>

Patch applied to wireless-drivers-next.git, thanks.

2cd2b42439ea mwifiex: add a bounds check in mwifiex_process_sta_rx_packet()

-- 
https://patchwork.kernel.org/patch/10881135/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply

* Re: [PATCH] mwifiex: Fix potential NULL pointer dereference
From: Kalle Valo @ 2019-04-04 10:20 UTC (permalink / raw)
  To: Aditya Pakki
  Cc: pakki001, kjlu, Amitkumar Karwar, Nishant Sarmukadam,
	Ganapathi Bhat, Xinming Hu, David S. Miller, linux-wireless,
	netdev, linux-kernel
In-Reply-To: <20190313184229.24780-1-pakki001@umn.edu>

Aditya Pakki <pakki001@umn.edu> wrote:

> dev_alloc_skb can fail and return a NULL pointer. The patch avoids
> a potential NULL pointer dereference and returns -ENOMEM.
> 
> Signed-off-by: Aditya Pakki <pakki001@umn.edu>

A similar patch was already submitted:

https://patchwork.kernel.org/patch/10848599/

Patch set to Superseded.

-- 
https://patchwork.kernel.org/patch/10851669/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply

* Re: [PATCH] mwifiex: Fix mem leak in mwifiex_tm_cmd
From: Kalle Valo @ 2019-04-04 10:19 UTC (permalink / raw)
  To: Yue Haibing
  Cc: amitkarwar, nishants, gbhat, huxinming820, davem, linux-kernel,
	netdev, linux-wireless, YueHaibing
In-Reply-To: <20190312070358.12700-1-yuehaibing@huawei.com>

Yue Haibing <yuehaibing@huawei.com> wrote:

> From: YueHaibing <yuehaibing@huawei.com>
> 
> 'hostcmd' is alloced by kzalloc, should be freed before
> leaving from the error handling cases, otherwise it will
> cause mem leak.
> 
> Fixes: 3935ccc14d2c ("mwifiex: add cfg80211 testmode support")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>

Patch applied to wireless-drivers-next.git, thanks.

003b686ace82 mwifiex: Fix mem leak in mwifiex_tm_cmd

-- 
https://patchwork.kernel.org/patch/10848633/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply

* Re: [PATCH v2] net: mwifiex: fix a NULL pointer dereference
From: Kalle Valo @ 2019-04-04 10:18 UTC (permalink / raw)
  To: Kangjie Lu
  Cc: kjlu, pakki001, Amitkumar Karwar, Nishant Sarmukadam,
	Ganapathi Bhat, Xinming Hu, David S. Miller, linux-wireless,
	netdev, linux-kernel
In-Reply-To: <20190312053107.5790-1-kjlu@umn.edu>

Kangjie Lu <kjlu@umn.edu> wrote:

> In case dev_alloc_skb fails, the fix returns -ENOMEM to avoid
> NULL pointer dereference.
> 
> Signed-off-by: Kangjie Lu <kjlu@umn.edu>

Patch applied to wireless-drivers-next.git, thanks.

e5b9b206f3f6 net: mwifiex: fix a NULL pointer dereference

-- 
https://patchwork.kernel.org/patch/10848599/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply

* Re: [PATCH] iwlegacy: remove redundant assignment to *res
From: Kalle Valo @ 2019-04-04 10:15 UTC (permalink / raw)
  To: Colin King
  Cc: Stanislaw Gruszka, David S . Miller, linux-wireless, netdev,
	kernel-janitors, linux-kernel
In-Reply-To: <20190330201422.8024-1-colin.king@canonical.com>

Colin King <colin.king@canonical.com> wrote:

> From: Colin Ian King <colin.king@canonical.com>
> 
> Currently 1 is being assigned to *res and then it is immediately
> updated with the computed result.  The first assignment is
> redundant and can be removed.
> 
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>

Patch applied to wireless-drivers-next.git, thanks.

6603c5844a44 iwlegacy: remove redundant assignment to *res

-- 
https://patchwork.kernel.org/patch/10878565/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply

* Re: [PATCH] b43: shut up clang -Wuninitialized variable warning
From: Kalle Valo @ 2019-04-04 10:14 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: David S. Miller, Larry Finger, Arnd Bergmann, Priit Laes,
	clang-built-linux, Nick Desaulniers, Nathan Chancellor,
	linux-wireless, b43-dev, netdev, linux-kernel
In-Reply-To: <20190322143725.1332353-1-arnd@arndb.de>

Arnd Bergmann <arnd@arndb.de> wrote:

> Clang warns about what is clearly a case of passing an uninitalized
> variable into a static function:
> 
> drivers/net/wireless/broadcom/b43/phy_lp.c:1852:23: error: variable 'gains' is uninitialized when used here
>       [-Werror,-Wuninitialized]
>                 lpphy_papd_cal(dev, gains, 0, 1, 30);
>                                     ^~~~~
> drivers/net/wireless/broadcom/b43/phy_lp.c:1838:2: note: variable 'gains' is declared here
>         struct lpphy_tx_gains gains, oldgains;
>         ^
> 1 error generated.
> 
> However, this function is empty, and its arguments are never evaluated,
> so gcc in contrast does not warn here. Both compilers behave in a
> reasonable way as far as I can tell, so we should change the code
> to avoid the warning everywhere.
> 
> We could just eliminate the lpphy_papd_cal() function entirely,
> given that it has had the TODO comment in it for 10 years now
> and is rather unlikely to ever get done. I'm doing a simpler
> change here, and just pass the 'oldgains' variable in that has
> been initialized, based on the guess that this is what was
> originally meant.
> 
> Fixes: 2c0d6100da3e ("b43: LP-PHY: Begin implementing calibration & software RFKILL support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>

Patch applied to wireless-drivers-next.git, thanks.

d825db346270 b43: shut up clang -Wuninitialized variable warning

-- 
https://patchwork.kernel.org/patch/10865933/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply

* Re: [PATCH v3] brcmfmac: fix missing checks for kmemdup
From: Kalle Valo @ 2019-04-04 10:13 UTC (permalink / raw)
  To: Kangjie Lu
  Cc: kjlu, pakki001, Arend van Spriel, Franky Lin, Hante Meuleman,
	Chi-Hsien Lin, Wright Feng, David S. Miller,
	Rafał Miłecki, Stefan Wahren, Chung-Hsien Hsu,
	linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
	netdev, linux-kernel
In-Reply-To: <20190315170433.3845-1-kjlu@umn.edu>

Kangjie Lu <kjlu@umn.edu> wrote:

> In case kmemdup fails, the fix sets conn_info->req_ie_len and
> conn_info->resp_ie_len to zero to avoid buffer overflows.
> 
> Signed-off-by: Kangjie Lu <kjlu@umn.edu>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>

Patch applied to wireless-drivers-next.git, thanks.

46953f97224d brcmfmac: fix missing checks for kmemdup

-- 
https://patchwork.kernel.org/patch/10855341/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply

* Re: [PATCH] brcmfmac: convert dev_init_lock mutex to completion
From: Kalle Valo @ 2019-04-04 10:13 UTC (permalink / raw)
  To: Piotr Figiel
  Cc: linux-wireless@vger.kernel.org, arend.vanspriel@broadcom.com,
	franky.lin@broadcom.com, hante.meuleman@broadcom.com,
	chi-hsien.lin@cypress.com, wright.feng@cypress.com,
	brcm80211-dev-list@cypress.com, Krzysztof Drobiński,
	Pawel Lenkow, Lech Perczak, Piotr Figiel
In-Reply-To: <1552470749-3625-1-git-send-email-p.figiel@camlintechnologies.com>

Piotr Figiel <p.figiel@camlintechnologies.com> wrote:

> Leaving dev_init_lock mutex locked in probe causes BUG and a WARNING when
> kernel is compiled with CONFIG_PROVE_LOCKING. Convert mutex to completion
> which silences those warnings and improves code readability.
> 
> Fix below errors when connecting the USB WiFi dongle:
> 
> brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43143 for chip BCM43143/2
> BUG: workqueue leaked lock or atomic: kworker/0:2/0x00000000/434
>      last function: hub_event
> 1 lock held by kworker/0:2/434:
>  #0: 18d5dcdf (&devinfo->dev_init_lock){+.+.}, at: brcmf_usb_probe+0x78/0x550 [brcmfmac]
> CPU: 0 PID: 434 Comm: kworker/0:2 Not tainted 4.19.23-00084-g454a789-dirty #123
> Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> Workqueue: usb_hub_wq hub_event
> [<8011237c>] (unwind_backtrace) from [<8010d74c>] (show_stack+0x10/0x14)
> [<8010d74c>] (show_stack) from [<809c4324>] (dump_stack+0xa8/0xd4)
> [<809c4324>] (dump_stack) from [<8014195c>] (process_one_work+0x710/0x808)
> [<8014195c>] (process_one_work) from [<80141a80>] (worker_thread+0x2c/0x564)
> [<80141a80>] (worker_thread) from [<80147bcc>] (kthread+0x13c/0x16c)
> [<80147bcc>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20)
> Exception stack(0xed1d9fb0 to 0xed1d9ff8)
> 9fa0:                                     00000000 00000000 00000000 00000000
> 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> 
> ======================================================
> WARNING: possible circular locking dependency detected
> 4.19.23-00084-g454a789-dirty #123 Not tainted
> ------------------------------------------------------
> kworker/0:2/434 is trying to acquire lock:
> e29cf799 ((wq_completion)"events"){+.+.}, at: process_one_work+0x174/0x808
> 
> but task is already holding lock:
> 18d5dcdf (&devinfo->dev_init_lock){+.+.}, at: brcmf_usb_probe+0x78/0x550 [brcmfmac]
> 
> which lock already depends on the new lock.
> 
> the existing dependency chain (in reverse order) is:
> 
> -> #2 (&devinfo->dev_init_lock){+.+.}:
>        mutex_lock_nested+0x1c/0x24
>        brcmf_usb_probe+0x78/0x550 [brcmfmac]
>        usb_probe_interface+0xc0/0x1bc
>        really_probe+0x228/0x2c0
>        __driver_attach+0xe4/0xe8
>        bus_for_each_dev+0x68/0xb4
>        bus_add_driver+0x19c/0x214
>        driver_register+0x78/0x110
>        usb_register_driver+0x84/0x148
>        process_one_work+0x228/0x808
>        worker_thread+0x2c/0x564
>        kthread+0x13c/0x16c
>        ret_from_fork+0x14/0x20
>          (null)
> 
> -> #1 (brcmf_driver_work){+.+.}:
>        worker_thread+0x2c/0x564
>        kthread+0x13c/0x16c
>        ret_from_fork+0x14/0x20
>          (null)
> 
> -> #0 ((wq_completion)"events"){+.+.}:
>        process_one_work+0x1b8/0x808
>        worker_thread+0x2c/0x564
>        kthread+0x13c/0x16c
>        ret_from_fork+0x14/0x20
>          (null)
> 
> other info that might help us debug this:
> 
> Chain exists of:
>   (wq_completion)"events" --> brcmf_driver_work --> &devinfo->dev_init_lock
> 
>  Possible unsafe locking scenario:
> 
>        CPU0                    CPU1
>        ----                    ----
>   lock(&devinfo->dev_init_lock);
>                                lock(brcmf_driver_work);
>                                lock(&devinfo->dev_init_lock);
>   lock((wq_completion)"events");
> 
>  *** DEADLOCK ***
> 
> 1 lock held by kworker/0:2/434:
>  #0: 18d5dcdf (&devinfo->dev_init_lock){+.+.}, at: brcmf_usb_probe+0x78/0x550 [brcmfmac]
> 
> stack backtrace:
> CPU: 0 PID: 434 Comm: kworker/0:2 Not tainted 4.19.23-00084-g454a789-dirty #123
> Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> Workqueue: events request_firmware_work_func
> [<8011237c>] (unwind_backtrace) from [<8010d74c>] (show_stack+0x10/0x14)
> [<8010d74c>] (show_stack) from [<809c4324>] (dump_stack+0xa8/0xd4)
> [<809c4324>] (dump_stack) from [<80172838>] (print_circular_bug+0x210/0x330)
> [<80172838>] (print_circular_bug) from [<80175940>] (__lock_acquire+0x160c/0x1a30)
> [<80175940>] (__lock_acquire) from [<8017671c>] (lock_acquire+0xe0/0x268)
> [<8017671c>] (lock_acquire) from [<80141404>] (process_one_work+0x1b8/0x808)
> [<80141404>] (process_one_work) from [<80141a80>] (worker_thread+0x2c/0x564)
> [<80141a80>] (worker_thread) from [<80147bcc>] (kthread+0x13c/0x16c)
> [<80147bcc>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20)
> Exception stack(0xed1d9fb0 to 0xed1d9ff8)
> 9fa0:                                     00000000 00000000 00000000 00000000
> 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> 
> Signed-off-by: Piotr Figiel <p.figiel@camlintechnologies.com>

Patch applied to wireless-drivers-next.git, thanks.

a9fd0953fa4a brcmfmac: convert dev_init_lock mutex to completion

-- 
https://patchwork.kernel.org/patch/10850843/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply

* Re: [PATCH] brcmfmac: fix Oops when bringing up interface during USB disconnect
From: Kalle Valo @ 2019-04-04 10:11 UTC (permalink / raw)
  To: Piotr Figiel
  Cc: linux-wireless@vger.kernel.org, arend.vanspriel@broadcom.com,
	franky.lin@broadcom.com, hante.meuleman@broadcom.com,
	chi-hsien.lin@cypress.com, wright.feng@cypress.com,
	brcm80211-dev-list@cypress.com, Krzysztof Drobiński,
	Pawel Lenkow, Lech Perczak, Piotr Figiel
In-Reply-To: <1552470712-3496-1-git-send-email-p.figiel@camlintechnologies.com>

Piotr Figiel <p.figiel@camlintechnologies.com> wrote:

> Fix a race which leads to an Oops with NULL pointer dereference.  The
> dereference is in brcmf_config_dongle() when cfg_to_ndev() attempts to get
> net_device structure of interface with index 0 via if2bss mapping. This
> shouldn't fail because of check for bus being ready in brcmf_netdev_open(),
> but it's not synchronised with USB disconnect and there is a race: after
> the check the bus can be marked down and the mapping for interface 0 may be
> gone.
> 
> Solve this by modifying disconnect handling so that the removal of mapping
> of ifidx to brcmf_if structure happens after netdev removal (which is
> synchronous with brcmf_netdev_open() thanks to rtln being locked in
> devinet_ioctl()). This assures brcmf_netdev_open() returns before the
> mapping is removed during disconnect.
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00000008
> pgd = bcae2612
> [00000008] *pgd=8be73831
> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> Modules linked in: brcmfmac brcmutil nf_log_ipv4 nf_log_common xt_LOG xt_limit
> iptable_mangle xt_connmark xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6
> nf_defrag_ipv4 iptable_filter ip_tables x_tables usb_f_mass_storage usb_f_rndis
> u_ether usb_serial_simple usbserial cdc_acm smsc95xx usbnet ci_hdrc_imx ci_hdrc
> usbmisc_imx ulpi 8250_exar 8250_pci 8250 8250_base libcomposite configfs
> udc_core [last unloaded: brcmutil]
> CPU: 2 PID: 24478 Comm: ifconfig Not tainted 4.19.23-00078-ga62866d-dirty #115
> Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> PC is at brcmf_cfg80211_up+0x94/0x29c [brcmfmac]
> LR is at brcmf_cfg80211_up+0x8c/0x29c [brcmfmac]
> pc : [<7f26a91c>]    lr : [<7f26a914>]    psr: a0070013
> sp : eca99d28  ip : 00000000  fp : ee9c6c00
> r10: 00000036  r9 : 00000000  r8 : ece4002c
> r7 : edb5b800  r6 : 00000000  r5 : 80f08448  r4 : edb5b968
> r3 : ffffffff  r2 : 00000000  r1 : 00000002  r0 : 00000000
> Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
> Control: 10c5387d  Table: 7ca0c04a  DAC: 00000051
> Process ifconfig (pid: 24478, stack limit = 0xd9e85a0e)
> Stack: (0xeca99d28 to 0xeca9a000)
> 9d20:                   00000000 80f873b0 0000000d 80f08448 eca99d68 50d45f32
> 9d40: 7f27de94 ece40000 80f08448 80f08448 7f27de94 ece4002c 00000000 00000036
> 9d60: ee9c6c00 7f27262c 00001002 50d45f32 ece40000 00000000 80f08448 80772008
> 9d80: 00000001 00001043 00001002 ece40000 00000000 50d45f32 ece40000 00000001
> 9da0: 80f08448 00001043 00001002 807723d0 00000000 50d45f32 80f08448 eca99e58
> 9dc0: 80f87113 50d45f32 80f08448 ece40000 ece40138 00001002 80f08448 00000000
> 9de0: 00000000 80772434 edbd5380 eca99e58 edbd5380 80f08448 ee9c6c0c 80805f70
> 9e00: 00000000 ede08e00 00008914 ece40000 00000014 ee9c6c0c 600c0013 00001043
> 9e20: 0208a8c0 ffffffff 00000000 50d45f32 eca98000 80f08448 7ee9fc38 00008914
> 9e40: 80f68e40 00000051 eca98000 00000036 00000003 80808b9c 6e616c77 00000030
> 9e60: 00000000 00000000 00001043 0208a8c0 ffffffff 00000000 80f08448 00000000
> 9e80: 00000000 816d8b20 600c0013 00000001 ede09320 801763d4 00000000 50d45f32
> 9ea0: eca98000 80f08448 7ee9fc38 50d45f32 00008914 80f08448 7ee9fc38 80f68e40
> 9ec0: ed531540 8074721c 00000800 00000001 00000000 6e616c77 00000030 00000000
> 9ee0: 00000000 00001002 0208a8c0 ffffffff 00000000 50d45f32 80f08448 7ee9fc38
> 9f00: ed531560 ec8fc900 80285a6c 80285138 edb910c0 00000000 ecd91008 ede08e00
> 9f20: 80f08448 00000000 00000000 816d8b20 600c0013 00000001 ede09320 801763d4
> 9f40: 00000000 50d45f32 00021000 edb91118 edb910c0 80f08448 01b29000 edb91118
> 9f60: eca99f7c 50d45f32 00021000 ec8fc900 00000003 ec8fc900 00008914 7ee9fc38
> 9f80: eca98000 00000036 00000003 80285a6c 00086364 7ee9fe1c 000000c3 00000036
> 9fa0: 801011c4 80101000 00086364 7ee9fe1c 00000003 00008914 7ee9fc38 00086364
> 9fc0: 00086364 7ee9fe1c 000000c3 00000036 0008630c 7ee9fe1c 7ee9fc38 00000003
> 9fe0: 000a42b8 7ee9fbd4 00019914 76e09acc 600c0010 00000003 00000000 00000000
> [<7f26a91c>] (brcmf_cfg80211_up [brcmfmac]) from [<7f27262c>] (brcmf_netdev_open+0x74/0xe8 [brcmfmac])
> [<7f27262c>] (brcmf_netdev_open [brcmfmac]) from [<80772008>] (__dev_open+0xcc/0x150)
> [<80772008>] (__dev_open) from [<807723d0>] (__dev_change_flags+0x168/0x1b4)
> [<807723d0>] (__dev_change_flags) from [<80772434>] (dev_change_flags+0x18/0x48)
> [<80772434>] (dev_change_flags) from [<80805f70>] (devinet_ioctl+0x67c/0x79c)
> [<80805f70>] (devinet_ioctl) from [<80808b9c>] (inet_ioctl+0x210/0x3d4)
> [<80808b9c>] (inet_ioctl) from [<8074721c>] (sock_ioctl+0x350/0x524)
> [<8074721c>] (sock_ioctl) from [<80285138>] (do_vfs_ioctl+0xb0/0x9b0)
> [<80285138>] (do_vfs_ioctl) from [<80285a6c>] (ksys_ioctl+0x34/0x5c)
> [<80285a6c>] (ksys_ioctl) from [<80101000>] (ret_fast_syscall+0x0/0x28)
> Exception stack(0xeca99fa8 to 0xeca99ff0)
> 9fa0:                   00086364 7ee9fe1c 00000003 00008914 7ee9fc38 00086364
> 9fc0: 00086364 7ee9fe1c 000000c3 00000036 0008630c 7ee9fe1c 7ee9fc38 00000003
> 9fe0: 000a42b8 7ee9fbd4 00019914 76e09acc
> Code: e5970328 eb002021 e1a02006 e3a01002 (e5909008)
> ---[ end trace 5cbac2333f3ac5df ]---
> 
> Signed-off-by: Piotr Figiel <p.figiel@camlintechnologies.com>

Patch applied to wireless-drivers-next.git, thanks.

24d413a31afa brcmfmac: fix Oops when bringing up interface during USB disconnect

-- 
https://patchwork.kernel.org/patch/10850845/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply

* Re: [PATCH 1/3] brcmfmac: fix race during disconnect when USB completion is in progress
From: Kalle Valo @ 2019-04-04 10:11 UTC (permalink / raw)
  To: Piotr Figiel
  Cc: linux-wireless@vger.kernel.org, arend.vanspriel@broadcom.com,
	franky.lin@broadcom.com, hante.meuleman@broadcom.com,
	chi-hsien.lin@cypress.com, wright.feng@cypress.com,
	brcm80211-dev-list@cypress.com, Pawel Lenkow, Lech Perczak,
	Krzysztof Drobiński, Piotr Figiel
In-Reply-To: <1552058658-23250-2-git-send-email-p.figiel@camlintechnologies.com>

Piotr Figiel <p.figiel@camlintechnologies.com> wrote:

> It was observed that rarely during USB disconnect happening shortly after
> connect (before full initialization completes) usb_hub_wq would wait
> forever for the dev_init_lock to be unlocked. dev_init_lock would remain
> locked though because of infinite wait during usb_kill_urb:
> 
> [ 2730.656472] kworker/0:2     D    0   260      2 0x00000000
> [ 2730.660700] Workqueue: events request_firmware_work_func
> [ 2730.664807] [<809dca20>] (__schedule) from [<809dd164>] (schedule+0x4c/0xac)
> [ 2730.670587] [<809dd164>] (schedule) from [<8069af44>] (usb_kill_urb+0xdc/0x114)
> [ 2730.676815] [<8069af44>] (usb_kill_urb) from [<7f258b50>] (brcmf_usb_free_q+0x34/0xa8 [brcmfmac])
> [ 2730.684833] [<7f258b50>] (brcmf_usb_free_q [brcmfmac]) from [<7f2517d4>] (brcmf_detach+0xa0/0xb8 [brcmfmac])
> [ 2730.693557] [<7f2517d4>] (brcmf_detach [brcmfmac]) from [<7f251a34>] (brcmf_attach+0xac/0x3d8 [brcmfmac])
> [ 2730.702094] [<7f251a34>] (brcmf_attach [brcmfmac]) from [<7f2587ac>] (brcmf_usb_probe_phase2+0x468/0x4a0 [brcmfmac])
> [ 2730.711601] [<7f2587ac>] (brcmf_usb_probe_phase2 [brcmfmac]) from [<7f252888>] (brcmf_fw_request_done+0x194/0x220 [brcmfmac])
> [ 2730.721795] [<7f252888>] (brcmf_fw_request_done [brcmfmac]) from [<805748e4>] (request_firmware_work_func+0x4c/0x88)
> [ 2730.731125] [<805748e4>] (request_firmware_work_func) from [<80141474>] (process_one_work+0x228/0x808)
> [ 2730.739223] [<80141474>] (process_one_work) from [<80141a80>] (worker_thread+0x2c/0x564)
> [ 2730.746105] [<80141a80>] (worker_thread) from [<80147bcc>] (kthread+0x13c/0x16c)
> [ 2730.752227] [<80147bcc>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20)
> 
> [ 2733.099695] kworker/0:3     D    0  1065      2 0x00000000
> [ 2733.103926] Workqueue: usb_hub_wq hub_event
> [ 2733.106914] [<809dca20>] (__schedule) from [<809dd164>] (schedule+0x4c/0xac)
> [ 2733.112693] [<809dd164>] (schedule) from [<809e2a8c>] (schedule_timeout+0x214/0x3e4)
> [ 2733.119621] [<809e2a8c>] (schedule_timeout) from [<809dde2c>] (wait_for_common+0xc4/0x1c0)
> [ 2733.126810] [<809dde2c>] (wait_for_common) from [<7f258d00>] (brcmf_usb_disconnect+0x1c/0x4c [brcmfmac])
> [ 2733.135206] [<7f258d00>] (brcmf_usb_disconnect [brcmfmac]) from [<8069e0c8>] (usb_unbind_interface+0x5c/0x1e4)
> [ 2733.143943] [<8069e0c8>] (usb_unbind_interface) from [<8056d3e8>] (device_release_driver_internal+0x164/0x1fc)
> [ 2733.152769] [<8056d3e8>] (device_release_driver_internal) from [<8056c078>] (bus_remove_device+0xd0/0xfc)
> [ 2733.161138] [<8056c078>] (bus_remove_device) from [<8056977c>] (device_del+0x11c/0x310)
> [ 2733.167939] [<8056977c>] (device_del) from [<8069cba8>] (usb_disable_device+0xa0/0x1cc)
> [ 2733.174743] [<8069cba8>] (usb_disable_device) from [<8069507c>] (usb_disconnect+0x74/0x1dc)
> [ 2733.181823] [<8069507c>] (usb_disconnect) from [<80695e88>] (hub_event+0x478/0xf88)
> [ 2733.188278] [<80695e88>] (hub_event) from [<80141474>] (process_one_work+0x228/0x808)
> [ 2733.194905] [<80141474>] (process_one_work) from [<80141a80>] (worker_thread+0x2c/0x564)
> [ 2733.201724] [<80141a80>] (worker_thread) from [<80147bcc>] (kthread+0x13c/0x16c)
> [ 2733.207913] [<80147bcc>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20)
> 
> It was traced down to a case where usb_kill_urb would be called on an URB
> structure containing more or less random data, including large number in
> its use_count. During the debugging it appeared that in brcmf_usb_free_q()
> the traversal over URBs' lists is not synchronized with operations on those
> lists in brcmf_usb_rx_complete() leading to handling
> brcmf_usbdev_info structure (holding lists' head) as lists' element and in
> result causing above problem.
> 
> Fix it by walking through all URBs during brcmf_cancel_all_urbs using the
> arrays of requests instead of linked lists.
> 
> Signed-off-by: Piotr Figiel <p.figiel@camlintechnologies.com>

3 patches applied to wireless-drivers-next.git, thanks.

db3b9e2e1d58 brcmfmac: fix race during disconnect when USB completion is in progress
2b78e5f52236 brcmfmac: remove pending parameter from brcmf_usb_free_q
504f06725d01 brcmfmac: remove unused variable i from brcmf_usb_free_q

-- 
https://patchwork.kernel.org/patch/10845051/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply

* Re: [PATCH 1/2] brcmfmac: fix WARNING during USB disconnect in case of unempty psq
From: Kalle Valo @ 2019-04-04 10:10 UTC (permalink / raw)
  To: Piotr Figiel
  Cc: linux-wireless@vger.kernel.org, arend.vanspriel@broadcom.com,
	franky.lin@broadcom.com, hante.meuleman@broadcom.com,
	chi-hsien.lin@cypress.com, wright.feng@cypress.com,
	brcm80211-dev-list@cypress.com, Piotr Figiel
In-Reply-To: <1551714128-27412-2-git-send-email-p.figiel@camlintechnologies.com>

Piotr Figiel <p.figiel@camlintechnologies.com> wrote:

> brcmu_pkt_buf_free_skb emits WARNING when attempting to free a sk_buff
> which is part of any queue. After USB disconnect this may have happened
> when brcmf_fws_hanger_cleanup() is called as per-interface psq was never
> cleaned when removing the interface.
> Change brcmf_fws_macdesc_cleanup() in a way that it removes the
> corresponding packets from hanger table (to avoid double-free when
> brcmf_fws_hanger_cleanup() is called) and add a call to clean-up the
> interface specific packet queue.
> 
> Below is a WARNING during USB disconnect with Raspberry Pi WiFi dongle
> running in AP mode. This was reproducible when the interface was
> transmitting during the disconnect and is fixed with this commit.
> 
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1171 at drivers/net/wireless/broadcom/brcm80211/brcmutil/utils.c:49 brcmu_pkt_buf_free_skb+0x3c/0x40
> Modules linked in: nf_log_ipv4 nf_log_common xt_LOG xt_limit iptable_mangle xt_connmark xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter ip_tables x_tables usb_f_mass_storage usb_f_rndis u_ether cdc_acm smsc95xx usbnet ci_hdrc_imx ci_hdrc ulpi usbmisc_imx 8250_exar 8250_pci 8250 8250_base libcomposite configfs udc_core
> CPU: 0 PID: 1171 Comm: kworker/0:0 Not tainted 4.19.23-00075-gde33ed8 #99
> Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> Workqueue: usb_hub_wq hub_event
> [<8010ff84>] (unwind_backtrace) from [<8010bb64>] (show_stack+0x10/0x14)
> [<8010bb64>] (show_stack) from [<80840278>] (dump_stack+0x88/0x9c)
> [<80840278>] (dump_stack) from [<8011f5ec>] (__warn+0xfc/0x114)
> [<8011f5ec>] (__warn) from [<8011f71c>] (warn_slowpath_null+0x40/0x48)
> [<8011f71c>] (warn_slowpath_null) from [<805a476c>] (brcmu_pkt_buf_free_skb+0x3c/0x40)
> [<805a476c>] (brcmu_pkt_buf_free_skb) from [<805bb6c4>] (brcmf_fws_cleanup+0x1e4/0x22c)
> [<805bb6c4>] (brcmf_fws_cleanup) from [<805bc854>] (brcmf_fws_del_interface+0x58/0x68)
> [<805bc854>] (brcmf_fws_del_interface) from [<805b66ac>] (brcmf_remove_interface+0x40/0x150)
> [<805b66ac>] (brcmf_remove_interface) from [<805b6870>] (brcmf_detach+0x6c/0xb0)
> [<805b6870>] (brcmf_detach) from [<805bdbb8>] (brcmf_usb_disconnect+0x30/0x4c)
> [<805bdbb8>] (brcmf_usb_disconnect) from [<805e5d64>] (usb_unbind_interface+0x5c/0x1e0)
> [<805e5d64>] (usb_unbind_interface) from [<804aab10>] (device_release_driver_internal+0x154/0x1ec)
> [<804aab10>] (device_release_driver_internal) from [<804a97f4>] (bus_remove_device+0xcc/0xf8)
> [<804a97f4>] (bus_remove_device) from [<804a6fc0>] (device_del+0x118/0x308)
> [<804a6fc0>] (device_del) from [<805e488c>] (usb_disable_device+0xa0/0x1c8)
> [<805e488c>] (usb_disable_device) from [<805dcf98>] (usb_disconnect+0x70/0x1d8)
> [<805dcf98>] (usb_disconnect) from [<805ddd84>] (hub_event+0x464/0xf50)
> [<805ddd84>] (hub_event) from [<80135a70>] (process_one_work+0x138/0x3f8)
> [<80135a70>] (process_one_work) from [<80135d5c>] (worker_thread+0x2c/0x554)
> [<80135d5c>] (worker_thread) from [<8013b1a0>] (kthread+0x124/0x154)
> [<8013b1a0>] (kthread) from [<801010e8>] (ret_from_fork+0x14/0x2c)
> Exception stack(0xecf8dfb0 to 0xecf8dff8)
> dfa0:                                     00000000 00000000 00000000 00000000
> dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
> ---[ end trace 38d234018e9e2a90 ]---
> ------------[ cut here ]------------
> 
> Signed-off-by: Piotr Figiel <p.figiel@camlintechnologies.com>

2 patches applied to wireless-drivers-next.git, thanks.

c80d26e81ef1 brcmfmac: fix WARNING during USB disconnect in case of unempty psq
5cdb0ef6144f brcmfmac: fix NULL pointer derefence during USB disconnect

-- 
https://patchwork.kernel.org/patch/10837981/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply

* Re: [PATCH 1/4] brcmfmac: support repeated brcmf_fw_alloc_request() calls
From: Kalle Valo @ 2019-04-04 10:00 UTC (permalink / raw)
  To: Rafał Miłecki
  Cc: Arend van Spriel, linux-wireless, brcm80211-dev-list.pdl,
	brcm80211-dev-list, Rafał Miłecki
In-Reply-To: <20190226131119.7907-2-zajec5@gmail.com>

Rafał Miłecki wrote:

> From: Rafał Miłecki <rafal@milecki.pl>
> 
> During a normal brcmfmac lifetime brcmf_fw_alloc_request() is called
> once only during the probe. It's safe to assume provided array is clear.
> 
> Further brcmfmac improvements may require calling it multiple times
> though. This patch allows it by fixing invalid firmware paths like:
> brcm/brcmfmac4366c-pcie.binbrcm/brcmfmac4366c-pcie.bin
> 
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>

3 patches applied to wireless-drivers-next.git, thanks.

c9692820710f brcmfmac: support repeated brcmf_fw_alloc_request() calls
a2ec87ddbf16 brcmfmac: add a function designated for handling firmware fails
4684997d9eea brcmfmac: reset PCIe bus on a firmware crash

-- 
https://patchwork.kernel.org/patch/10830169/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply

* Re: [PATCH 01/14] qtnfmac: make regulatory notifier work on per-phy basis
From: Kalle Valo @ 2019-04-04  9:58 UTC (permalink / raw)
  To: Sergey Matyukevich
  Cc: linux-wireless@vger.kernel.org, Igor Mitsyanko,
	Sergey Matyukevich
In-Reply-To: <20190320100340.14168-2-sergey.matyukevich.os@quantenna.com>

Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> wrote:

> From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
> 
> Wireless core calls regulatory notifier for each wiphy and it only
> guarantees that bands info is updated for this particular wiphy prior
> to calling a notifier. Hence updating all wiphy which belong to driver
> in a single notifier callback is redundant and incorrect.
> 
> Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>

13 patches applied to wireless-drivers-next.git, thanks.

d123172175db qtnfmac: make regulatory notifier work on per-phy basis
642f15a5cee7 qtnfmac: simplify error reporting in regulatory notifier
a2fbaaf757e3 qtnfmac: include full channels info to regulatory notifier
2c31129f8f40 qtnfmac: pass complete channel info in regulatory notifier
48cefdfbcb57 qtnfmac: flexible regulatory domain registration logic
c698bce01562 qtnfmac: allow each MAC to specify its own regulatory rules
438fb43bcab1 qtnfmac: pass DFS region to firmware on region update
93eeab26791d qtnfmac: update bands information on CHANGE_INTF command
ae1946be26bc qtnfmac: fix core attach error path in pcie backend
83b00f6eb863 qtnfmac: simplify firmware state tracking
72b3270e01ab qtnfmac: allow changing the netns
bc70732f9bd9 qtnfmac: send EAPOL frames via control path
b63967cae6b1 qtnfmac: use scan duration param for different scan types

-- 
https://patchwork.kernel.org/patch/10861235/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply

* [PATCH v2 06/13] iwlwifi: dbg_ini: add debug prints to the ini flows
From: Luca Coelho @ 2019-04-04  8:58 UTC (permalink / raw)
  To: kvalo; +Cc: linux-wireless, Shahar S Matityahu, Luca Coelho
In-Reply-To: <20190403092224.815-7-luca@coelho.fi>

From: Shahar S Matityahu <shahar.s.matityahu@intel.com>

Add debug prints to the ini flow and rewrite existing prints to provide
more information

Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
 drivers/net/wireless/intel/iwlwifi/fw/dbg.c   | 102 ++++++++++++++----
 .../net/wireless/intel/iwlwifi/iwl-dbg-tlv.c  |   2 +-
 .../net/wireless/intel/iwlwifi/pcie/trans.c   |   2 +
 3 files changed, 82 insertions(+), 24 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
index ad8a5411212e..2762b8853e72 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
+++ b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
@@ -1685,6 +1685,9 @@ iwl_dump_ini_mem(struct iwl_fw_runtime *fwrt,
 		    !ops->fill_mem_hdr || !ops->fill_range))
 		return;
 
+	IWL_DEBUG_FW(fwrt, "WRT: collecting region: id=%d, type=%d\n",
+		     le32_to_cpu(reg->region_id), type);
+
 	num_of_ranges = ops->get_num_of_ranges(fwrt, reg);
 
 	(*data)->type = cpu_to_le32(type | INI_DUMP_BIT);
@@ -1698,7 +1701,8 @@ iwl_dump_ini_mem(struct iwl_fw_runtime *fwrt,
 
 	range = ops->fill_mem_hdr(fwrt, reg, header);
 	if (!range) {
-		IWL_ERR(fwrt, "Failed to fill region header: id=%d, type=%d\n",
+		IWL_ERR(fwrt,
+			"WRT: failed to fill region header: id=%d, type=%d\n",
 			le32_to_cpu(reg->region_id), type);
 		return;
 	}
@@ -1707,7 +1711,8 @@ iwl_dump_ini_mem(struct iwl_fw_runtime *fwrt,
 		int range_size = ops->fill_range(fwrt, reg, range, i);
 
 		if (range_size < 0) {
-			IWL_ERR(fwrt, "Failed to dump region: id=%d, type=%d\n",
+			IWL_ERR(fwrt,
+				"WRT: failed to dump region: id=%d, type=%d\n",
 				le32_to_cpu(reg->region_id), type);
 			return;
 		}
@@ -1732,8 +1737,12 @@ static int iwl_fw_ini_get_trigger_len(struct iwl_fw_runtime *fwrt,
 			continue;
 
 		reg = fwrt->dump.active_regs[reg_id];
-		if (WARN(!reg, "Unassigned region %d\n", reg_id))
+		if (!reg) {
+			IWL_WARN(fwrt,
+				 "WRT: unassigned region id %d, skipping\n",
+				 reg_id);
 			continue;
+		}
 
 		switch (le32_to_cpu(reg->region_type)) {
 		case IWL_FW_INI_REGION_DEVICE_MEMORY:
@@ -2110,6 +2119,12 @@ int _iwl_fw_dbg_ini_collect(struct iwl_fw_runtime *fwrt,
 	if (test_and_set_bit(IWL_FWRT_STATUS_DUMPING, &fwrt->status))
 		return -EBUSY;
 
+	if (!iwl_fw_ini_trigger_on(fwrt, id)) {
+		IWL_WARN(fwrt, "WRT: Trigger %d is not active, aborting dump\n",
+			 id);
+		return -EINVAL;
+	}
+
 	active = &fwrt->dump.active_trigs[id];
 	delay = le32_to_cpu(active->trig->dump_delay);
 	occur = le32_to_cpu(active->trig->occurrences);
@@ -2119,14 +2134,14 @@ int _iwl_fw_dbg_ini_collect(struct iwl_fw_runtime *fwrt,
 	active->trig->occurrences = cpu_to_le32(--occur);
 
 	if (le32_to_cpu(active->trig->force_restart)) {
-		IWL_WARN(fwrt, "Force restart: trigger %d fired.\n", id);
+		IWL_WARN(fwrt, "WRT: force restart: trigger %d fired.\n", id);
 		iwl_force_nmi(fwrt->trans);
 		return 0;
 	}
 
 	fwrt->dump.ini_trig_id = id;
 
-	IWL_WARN(fwrt, "Collecting data: ini trigger %d fired.\n", id);
+	IWL_WARN(fwrt, "WRT: collecting data: ini trigger %d fired.\n", id);
 
 	schedule_delayed_work(&fwrt->dump.wk, usecs_to_jiffies(delay));
 
@@ -2264,12 +2279,12 @@ void iwl_fw_dbg_collect_sync(struct iwl_fw_runtime *fwrt)
 
 	iwl_fw_dbg_stop_recording(fwrt, &params);
 
-	IWL_DEBUG_INFO(fwrt, "WRT dump start\n");
+	IWL_DEBUG_FW_INFO(fwrt, "WRT: data collection start\n");
 	if (fwrt->trans->ini_valid)
 		iwl_fw_error_ini_dump(fwrt);
 	else
 		iwl_fw_error_dump(fwrt);
-	IWL_DEBUG_INFO(fwrt, "WRT dump done\n");
+	IWL_DEBUG_FW_INFO(fwrt, "WRT: data collection done\n");
 
 	/* start recording again if the firmware is not crashed */
 	if (!test_bit(STATUS_FW_ERROR, &fwrt->trans->status) &&
@@ -2339,12 +2354,14 @@ iwl_fw_dbg_buffer_allocation(struct iwl_fw_runtime *fwrt, u32 size)
 	if (!virtual_addr)
 		IWL_ERR(fwrt, "Failed to allocate debug memory\n");
 
+	IWL_DEBUG_FW(trans,
+		     "Allocated DRAM buffer[%d], size=0x%x\n",
+		     trans->num_blocks, size);
+
 	trans->fw_mon[trans->num_blocks].block = virtual_addr;
 	trans->fw_mon[trans->num_blocks].physical = phys_addr;
 	trans->fw_mon[trans->num_blocks].size = size;
 	trans->num_blocks++;
-
-	IWL_DEBUG_FW(trans, "Allocated debug block of size %d\n", size);
 }
 
 static void iwl_fw_dbg_buffer_apply(struct iwl_fw_runtime *fwrt,
@@ -2367,11 +2384,15 @@ static void iwl_fw_dbg_buffer_apply(struct iwl_fw_runtime *fwrt,
 
 	if (buf_location == IWL_FW_INI_LOCATION_SRAM_PATH) {
 		if (!WARN(pnt != IWL_FW_INI_APPLY_EARLY,
-			  "Invalid apply point %d for SMEM buffer allocation",
-			  pnt))
+			  "WRT: Invalid apply point %d for SMEM buffer allocation, aborting\n",
+			  pnt)) {
+			IWL_DEBUG_FW(trans,
+				     "WRT: applying SMEM buffer destination\n");
+
 			/* set sram monitor by enabling bit 7 */
 			iwl_set_bit(fwrt->trans, CSR_HW_IF_CONFIG_REG,
 				    CSR_HW_IF_CONFIG_REG_BIT_MONITOR_SRAM);
+		}
 		return;
 	}
 
@@ -2390,6 +2411,9 @@ static void iwl_fw_dbg_buffer_apply(struct iwl_fw_runtime *fwrt,
 	if (trans->num_blocks == 1)
 		return;
 
+	IWL_DEBUG_FW(trans,
+		     "WRT: applying DRAM buffer[%d] destination\n", block_idx);
+
 	cmd->num_frags = cpu_to_le32(1);
 	cmd->fragments[0].address =
 		cpu_to_le64(trans->fw_mon[block_idx].physical);
@@ -2401,7 +2425,8 @@ static void iwl_fw_dbg_buffer_apply(struct iwl_fw_runtime *fwrt,
 }
 
 static void iwl_fw_dbg_send_hcmd(struct iwl_fw_runtime *fwrt,
-				 struct iwl_ucode_tlv *tlv)
+				 struct iwl_ucode_tlv *tlv,
+				 bool ext)
 {
 	struct iwl_fw_ini_hcmd_tlv *hcmd_tlv = (void *)&tlv->data[0];
 	struct iwl_fw_ini_hcmd *data = &hcmd_tlv->hcmd;
@@ -2417,6 +2442,10 @@ static void iwl_fw_dbg_send_hcmd(struct iwl_fw_runtime *fwrt,
 	if (le32_to_cpu(hcmd_tlv->domain) != IWL_FW_INI_DBG_DOMAIN_ALWAYS_ON)
 		return;
 
+	IWL_DEBUG_FW(fwrt,
+		     "WRT: ext=%d. Sending host command id=0x%x, group=0x%x\n",
+		     ext, data->id, data->group);
+
 	iwl_trans_send_cmd(fwrt->trans, &hcmd);
 }
 
@@ -2433,17 +2462,20 @@ static void iwl_fw_dbg_update_regions(struct iwl_fw_runtime *fwrt,
 		u32 type = le32_to_cpu(reg->region_type);
 
 		if (WARN(id >= ARRAY_SIZE(fwrt->dump.active_regs),
-			 "Invalid region id %d for apply point %d\n", id, pnt))
+			 "WRT: ext=%d. Invalid region id %d for apply point %d\n",
+			 ext, id, pnt))
 			break;
 
 		active = &fwrt->dump.active_regs[id];
 
 		if (*active)
-			IWL_WARN(fwrt->trans, "region TLV %d override\n", id);
+			IWL_WARN(fwrt->trans,
+				 "WRT: ext=%d. Region id %d override\n",
+				 ext, id);
 
 		IWL_DEBUG_FW(fwrt,
-			     "%s: apply point %d, activating region ID %d\n",
-			     __func__, pnt, id);
+			     "WRT: ext=%d. Activating region id %d\n",
+			     ext, id);
 
 		*active = reg;
 
@@ -2476,7 +2508,8 @@ static int iwl_fw_dbg_trig_realloc(struct iwl_fw_runtime *fwrt,
 
 	ptr = krealloc(active->trig, size, GFP_KERNEL);
 	if (!ptr) {
-		IWL_ERR(fwrt, "Failed to allocate memory for trigger %d\n", id);
+		IWL_ERR(fwrt, "WRT: Failed to allocate memory for trigger %d\n",
+			id);
 		return -ENOMEM;
 	}
 	active->trig = ptr;
@@ -2500,7 +2533,9 @@ static void iwl_fw_dbg_update_triggers(struct iwl_fw_runtime *fwrt,
 		u32 trig_regs_size = le32_to_cpu(trig->num_regions) *
 			sizeof(__le32);
 
-		if (WARN_ON(id >= ARRAY_SIZE(fwrt->dump.active_trigs)))
+		if (WARN(id >= ARRAY_SIZE(fwrt->dump.active_trigs),
+			 "WRT: ext=%d. Invalid trigger id %d for apply point %d\n",
+			 ext, id, apply_point))
 			break;
 
 		active = &fwrt->dump.active_trigs[id];
@@ -2508,6 +2543,10 @@ static void iwl_fw_dbg_update_triggers(struct iwl_fw_runtime *fwrt,
 		if (!active->active) {
 			size_t trig_size = sizeof(*trig) + trig_regs_size;
 
+			IWL_DEBUG_FW(fwrt,
+				     "WRT: ext=%d. Activating trigger %d\n",
+				     ext, id);
+
 			if (iwl_fw_dbg_trig_realloc(fwrt, active, id,
 						    trig_size))
 				goto next;
@@ -2526,8 +2565,16 @@ static void iwl_fw_dbg_update_triggers(struct iwl_fw_runtime *fwrt,
 			int mem_to_add = trig_regs_size;
 
 			if (region_override) {
+				IWL_DEBUG_FW(fwrt,
+					     "WRT: ext=%d. Trigger %d regions override\n",
+					     ext, id);
+
 				mem_to_add -= active_regs * sizeof(__le32);
 			} else {
+				IWL_DEBUG_FW(fwrt,
+					     "WRT: ext=%d. Trigger %d regions appending\n",
+					     ext, id);
+
 				offset += active_regs;
 				new_regs += active_regs;
 			}
@@ -2536,8 +2583,13 @@ static void iwl_fw_dbg_update_triggers(struct iwl_fw_runtime *fwrt,
 						    active->size + mem_to_add))
 				goto next;
 
-			if (conf_override)
+			if (conf_override) {
+				IWL_DEBUG_FW(fwrt,
+					     "WRT: ext=%d. Trigger %d configuration override\n",
+					     ext, id);
+
 				memcpy(active->trig, trig, sizeof(*trig));
+			}
 
 			memcpy(active->trig->data + offset, trig->data,
 			       trig_regs_size);
@@ -2578,11 +2630,11 @@ static void _iwl_fw_dbg_apply_point(struct iwl_fw_runtime *fwrt,
 		case IWL_UCODE_TLV_TYPE_HCMD:
 			if (pnt < IWL_FW_INI_APPLY_AFTER_ALIVE) {
 				IWL_ERR(fwrt,
-					"Invalid apply point %x for host command\n",
-					pnt);
+					"WRT: ext=%d. Invalid apply point %d for host command\n",
+					ext, pnt);
 				goto next;
 			}
-			iwl_fw_dbg_send_hcmd(fwrt, tlv);
+			iwl_fw_dbg_send_hcmd(fwrt, tlv, ext);
 			break;
 		case IWL_UCODE_TLV_TYPE_REGIONS:
 			iwl_fw_dbg_update_regions(fwrt, ini_tlv, ext, pnt);
@@ -2593,7 +2645,9 @@ static void _iwl_fw_dbg_apply_point(struct iwl_fw_runtime *fwrt,
 		case IWL_UCODE_TLV_TYPE_DEBUG_FLOW:
 			break;
 		default:
-			WARN_ONCE(1, "Invalid TLV %x for apply point\n", type);
+			WARN_ONCE(1,
+				  "WRT: ext=%d. Invalid TLV 0x%x for apply point\n",
+				  ext, type);
 			break;
 		}
 next:
@@ -2607,6 +2661,8 @@ void iwl_fw_dbg_apply_point(struct iwl_fw_runtime *fwrt,
 	void *data = &fwrt->trans->apply_points[apply_point];
 	int i;
 
+	IWL_DEBUG_FW(fwrt, "WRT: enabling apply point %d\n", apply_point);
+
 	if (apply_point == IWL_FW_INI_APPLY_EARLY) {
 		for (i = 0; i < IWL_FW_INI_MAX_REGION_ID; i++)
 			fwrt->dump.active_regs[i] = NULL;
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c b/drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c
index 9107302cc444..08e40a8f9f6b 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c
@@ -138,7 +138,7 @@ void iwl_alloc_dbg_tlv(struct iwl_trans *trans, size_t len, const u8 *data,
 		if (le32_to_cpu(hdr->tlv_version) != 1)
 			continue;
 
-		IWL_DEBUG_FW(trans, "Read TLV %x, apply point %d\n",
+		IWL_DEBUG_FW(trans, "WRT: read TLV 0x%x, apply point %d\n",
 			     le32_to_cpu(tlv->type), apply);
 
 		if (WARN_ON(apply >= IWL_FW_INI_APPLY_NUM))
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index cfaad360c823..ce71ac662ad0 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -896,6 +896,8 @@ void iwl_pcie_apply_destination(struct iwl_trans *trans)
 		if (!trans->num_blocks)
 			return;
 
+		IWL_DEBUG_FW(trans,
+			     "WRT: applying DRAM buffer[0] destination\n");
 		iwl_write_umac_prph(trans, MON_BUFF_BASE_ADDR_VER2,
 				    trans->fw_mon[0].physical >>
 				    MON_BUFF_SHIFT_VER2);
-- 
2.20.1


^ permalink raw reply related

* [PATCH 4.19 049/187] mt76: fix a leaked reference by adding a missing of_node_put
From: Greg Kroah-Hartman @ 2019-04-04  8:46 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Wen Yang, Felix Fietkau,
	Lorenzo Bianconi, Kalle Valo, David S. Miller, Matthias Brugger,
	linux-wireless, netdev, linux-arm-kernel, linux-mediatek,
	Sasha Levin
In-Reply-To: <20190404084603.119654039@linuxfoundation.org>

4.19-stable review patch.  If anyone has any objections, please let me know.

------------------

[ Upstream commit 34e022d8b780a03902d82fb3997ba7c7b1f40c81 ]

The call to of_find_node_by_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.

Detected by coccinelle with the following warnings:
./drivers/net/wireless/mediatek/mt76/eeprom.c:58:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
./drivers/net/wireless/mediatek/mt76/eeprom.c:61:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
./drivers/net/wireless/mediatek/mt76/eeprom.c:67:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
./drivers/net/wireless/mediatek/mt76/eeprom.c:70:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
./drivers/net/wireless/mediatek/mt76/eeprom.c:72:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.

Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Cc: Felix Fietkau <nbd@nbd.name>
Cc: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/net/wireless/mediatek/mt76/eeprom.c | 24 ++++++++++++++-------
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/eeprom.c b/drivers/net/wireless/mediatek/mt76/eeprom.c
index 530e5593765c..a1529920d877 100644
--- a/drivers/net/wireless/mediatek/mt76/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/eeprom.c
@@ -54,22 +54,30 @@ mt76_get_of_eeprom(struct mt76_dev *dev, int len)
 		part = np->name;
 
 	mtd = get_mtd_device_nm(part);
-	if (IS_ERR(mtd))
-		return PTR_ERR(mtd);
+	if (IS_ERR(mtd)) {
+		ret =  PTR_ERR(mtd);
+		goto out_put_node;
+	}
 
-	if (size <= sizeof(*list))
-		return -EINVAL;
+	if (size <= sizeof(*list)) {
+		ret = -EINVAL;
+		goto out_put_node;
+	}
 
 	offset = be32_to_cpup(list);
 	ret = mtd_read(mtd, offset, len, &retlen, dev->eeprom.data);
 	put_mtd_device(mtd);
 	if (ret)
-		return ret;
+		goto out_put_node;
 
-	if (retlen < len)
-		return -EINVAL;
+	if (retlen < len) {
+		ret = -EINVAL;
+		goto out_put_node;
+	}
 
-	return 0;
+out_put_node:
+	of_node_put(np);
+	return ret;
 #else
 	return -ENOENT;
 #endif
-- 
2.19.1




^ permalink raw reply related

* [PATCH 5.0 060/246] mt76: fix a leaked reference by adding a missing of_node_put
From: Greg Kroah-Hartman @ 2019-04-04  8:46 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Wen Yang, Felix Fietkau,
	Lorenzo Bianconi, Kalle Valo, David S. Miller, Matthias Brugger,
	linux-wireless, netdev, linux-arm-kernel, linux-mediatek,
	Sasha Levin
In-Reply-To: <20190404084619.236418459@linuxfoundation.org>

5.0-stable review patch.  If anyone has any objections, please let me know.

------------------

[ Upstream commit 34e022d8b780a03902d82fb3997ba7c7b1f40c81 ]

The call to of_find_node_by_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.

Detected by coccinelle with the following warnings:
./drivers/net/wireless/mediatek/mt76/eeprom.c:58:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
./drivers/net/wireless/mediatek/mt76/eeprom.c:61:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
./drivers/net/wireless/mediatek/mt76/eeprom.c:67:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
./drivers/net/wireless/mediatek/mt76/eeprom.c:70:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
./drivers/net/wireless/mediatek/mt76/eeprom.c:72:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.

Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Cc: Felix Fietkau <nbd@nbd.name>
Cc: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/net/wireless/mediatek/mt76/eeprom.c | 24 ++++++++++++++-------
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/eeprom.c b/drivers/net/wireless/mediatek/mt76/eeprom.c
index 530e5593765c..a1529920d877 100644
--- a/drivers/net/wireless/mediatek/mt76/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/eeprom.c
@@ -54,22 +54,30 @@ mt76_get_of_eeprom(struct mt76_dev *dev, int len)
 		part = np->name;
 
 	mtd = get_mtd_device_nm(part);
-	if (IS_ERR(mtd))
-		return PTR_ERR(mtd);
+	if (IS_ERR(mtd)) {
+		ret =  PTR_ERR(mtd);
+		goto out_put_node;
+	}
 
-	if (size <= sizeof(*list))
-		return -EINVAL;
+	if (size <= sizeof(*list)) {
+		ret = -EINVAL;
+		goto out_put_node;
+	}
 
 	offset = be32_to_cpup(list);
 	ret = mtd_read(mtd, offset, len, &retlen, dev->eeprom.data);
 	put_mtd_device(mtd);
 	if (ret)
-		return ret;
+		goto out_put_node;
 
-	if (retlen < len)
-		return -EINVAL;
+	if (retlen < len) {
+		ret = -EINVAL;
+		goto out_put_node;
+	}
 
-	return 0;
+out_put_node:
+	of_node_put(np);
+	return ret;
 #else
 	return -ENOENT;
 #endif
-- 
2.19.1




^ permalink raw reply related

* Re: [PATCH v2] net: mwifiex: fix a NULL pointer dereference
From: Kalle Valo @ 2019-04-04  9:28 UTC (permalink / raw)
  To: Kangjie Lu
  Cc: kjlu, pakki001, Amitkumar Karwar, Nishant Sarmukadam,
	Ganapathi Bhat, Xinming Hu, David S. Miller, linux-wireless,
	netdev, linux-kernel
In-Reply-To: <20190323035711.23882-1-kjlu@umn.edu>

Kangjie Lu <kjlu@umn.edu> wrote:

> In case dev_alloc_skb fails, the fix returns -ENOMEM to avoid
> NULL pointer dereference.
> 
> Signed-off-by: Kangjie Lu <kjlu@umn.edu>

There is a similar patch submitted:

https://patchwork.kernel.org/patch/10851669/

Patch set to Superseded.

-- 
https://patchwork.kernel.org/patch/10866749/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply

* [PATCH] ath6kl: add some bounds checking
From: Dan Carpenter @ 2019-04-04  8:56 UTC (permalink / raw)
  To: Kalle Valo; +Cc: linux-wireless, kernel-janitors

The "ev->traffic_class" and "reply->ac" variables come from the network
and they're used as an offset into the wmi->stream_exist_for_ac[] array.
Those variables are u8 so they can be 0-255 but the stream_exist_for_ac[]
array only has WMM_NUM_AC (4) elements.  We need to add a couple bounds
checks to prevent array overflows.

I also modified one existing check from "if (traffic_class > 3) {" to
"if (traffic_class >= WMM_NUM_AC) {" just to make them all consistent.

Fixes: bdcd81707973 (" Add ath6kl cleaned up driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
 drivers/net/wireless/ath/ath6kl/wmi.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath6kl/wmi.c b/drivers/net/wireless/ath/ath6kl/wmi.c
index 68854c45d0a4..9ab6aa9ded5c 100644
--- a/drivers/net/wireless/ath/ath6kl/wmi.c
+++ b/drivers/net/wireless/ath/ath6kl/wmi.c
@@ -1176,6 +1176,10 @@ static int ath6kl_wmi_pstream_timeout_event_rx(struct wmi *wmi, u8 *datap,
 		return -EINVAL;
 
 	ev = (struct wmi_pstream_timeout_event *) datap;
+	if (ev->traffic_class >= WMM_NUM_AC) {
+		ath6kl_err("invalid traffic class: %d\n", ev->traffic_class);
+		return -EINVAL;
+	}
 
 	/*
 	 * When the pstream (fat pipe == AC) timesout, it means there were
@@ -1517,6 +1521,10 @@ static int ath6kl_wmi_cac_event_rx(struct wmi *wmi, u8 *datap, int len,
 		return -EINVAL;
 
 	reply = (struct wmi_cac_event *) datap;
+	if (reply->ac >= WMM_NUM_AC) {
+		ath6kl_err("invalid AC: %d\n", reply->ac);
+		return -EINVAL;
+	}
 
 	if ((reply->cac_indication == CAC_INDICATION_ADMISSION_RESP) &&
 	    (reply->status_code != IEEE80211_TSPEC_STATUS_ADMISS_ACCEPTED)) {
@@ -2633,7 +2641,7 @@ int ath6kl_wmi_delete_pstream_cmd(struct wmi *wmi, u8 if_idx, u8 traffic_class,
 	u16 active_tsids = 0;
 	int ret;
 
-	if (traffic_class > 3) {
+	if (traffic_class >= WMM_NUM_AC) {
 		ath6kl_err("invalid traffic class: %d\n", traffic_class);
 		return -EINVAL;
 	}
-- 
2.17.1


^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox