* [PATCH] mt76: move mt76_insert_ccmp_hdr in mt76-module
From: Lorenzo Bianconi @ 2019-05-14 12:48 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo
In-Reply-To: <cover.1557838049.git.lorenzo@kernel.org>
Move mt7615_insert_ccmp_hdr in mac80211.c and rename it in
mt76_insert_ccmp_hdr since it is shared between mt7603 and mt7615
drivers
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mac80211.c | 23 ++++++++++++++++
drivers/net/wireless/mediatek/mt76/mt76.h | 1 +
.../net/wireless/mediatek/mt76/mt7603/mac.c | 26 +------------------
.../net/wireless/mediatek/mt76/mt7615/mac.c | 25 +-----------------
4 files changed, 26 insertions(+), 49 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
index 5b6a81ee457e..e70507a4b14d 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -820,3 +820,26 @@ mt76_set_tim(struct ieee80211_hw *hw, struct ieee80211_sta *sta, bool set)
return 0;
}
EXPORT_SYMBOL_GPL(mt76_set_tim);
+
+void mt76_insert_ccmp_hdr(struct sk_buff *skb, u8 key_id)
+{
+ struct mt76_rx_status *status = (struct mt76_rx_status *)skb->cb;
+ int hdr_len = ieee80211_get_hdrlen_from_skb(skb);
+ u8 *hdr, *pn = status->iv;
+
+ __skb_push(skb, 8);
+ memmove(skb->data, skb->data + 8, hdr_len);
+ hdr = skb->data + hdr_len;
+
+ hdr[0] = pn[5];
+ hdr[1] = pn[4];
+ hdr[2] = 0;
+ hdr[3] = 0x20 | (key_id << 6);
+ hdr[4] = pn[3];
+ hdr[5] = pn[2];
+ hdr[6] = pn[1];
+ hdr[7] = pn[0];
+
+ status->flag &= ~RX_FLAG_IV_STRIPPED;
+}
+EXPORT_SYMBOL_GPL(mt76_insert_ccmp_hdr);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index fc4169c83e76..8edf476f9f2f 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -750,6 +750,7 @@ void mt76_csa_check(struct mt76_dev *dev);
void mt76_csa_finish(struct mt76_dev *dev);
int mt76_set_tim(struct ieee80211_hw *hw, struct ieee80211_sta *sta, bool set);
+void mt76_insert_ccmp_hdr(struct sk_buff *skb, u8 key_id);
/* internal */
void mt76_tx_free(struct mt76_dev *dev);
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/mac.c b/drivers/net/wireless/mediatek/mt76/mt7603/mac.c
index 0ccba5926b68..5c09b2dbf3fd 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/mac.c
@@ -418,30 +418,6 @@ mt7603_rx_get_wcid(struct mt7603_dev *dev, u8 idx, bool unicast)
return &sta->vif->sta.wcid;
}
-static void
-mt7603_insert_ccmp_hdr(struct sk_buff *skb, u8 key_id)
-{
- struct mt76_rx_status *status = (struct mt76_rx_status *)skb->cb;
- int hdr_len = ieee80211_get_hdrlen_from_skb(skb);
- u8 *pn = status->iv;
- u8 *hdr;
-
- __skb_push(skb, 8);
- memmove(skb->data, skb->data + 8, hdr_len);
- hdr = skb->data + hdr_len;
-
- hdr[0] = pn[5];
- hdr[1] = pn[4];
- hdr[2] = 0;
- hdr[3] = 0x20 | (key_id << 6);
- hdr[4] = pn[3];
- hdr[5] = pn[2];
- hdr[6] = pn[1];
- hdr[7] = pn[0];
-
- status->flag &= ~RX_FLAG_IV_STRIPPED;
-}
-
int
mt7603_mac_fill_rx(struct mt7603_dev *dev, struct sk_buff *skb)
{
@@ -580,7 +556,7 @@ mt7603_mac_fill_rx(struct mt7603_dev *dev, struct sk_buff *skb)
if (insert_ccmp_hdr) {
u8 key_id = FIELD_GET(MT_RXD1_NORMAL_KEY_ID, rxd1);
- mt7603_insert_ccmp_hdr(skb, key_id);
+ mt76_insert_ccmp_hdr(skb, key_id);
}
hdr = (struct ieee80211_hdr *)skb->data;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
index b8f48d10f27a..1d6ebea17132 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
@@ -61,29 +61,6 @@ static int mt7615_get_rate(struct mt7615_dev *dev,
return 0;
}
-static void mt7615_insert_ccmp_hdr(struct sk_buff *skb, u8 key_id)
-{
- struct mt76_rx_status *status = (struct mt76_rx_status *)skb->cb;
- int hdr_len = ieee80211_get_hdrlen_from_skb(skb);
- u8 *pn = status->iv;
- u8 *hdr;
-
- __skb_push(skb, 8);
- memmove(skb->data, skb->data + 8, hdr_len);
- hdr = skb->data + hdr_len;
-
- hdr[0] = pn[5];
- hdr[1] = pn[4];
- hdr[2] = 0;
- hdr[3] = 0x20 | (key_id << 6);
- hdr[4] = pn[3];
- hdr[5] = pn[2];
- hdr[6] = pn[1];
- hdr[7] = pn[0];
-
- status->flag &= ~RX_FLAG_IV_STRIPPED;
-}
-
int mt7615_mac_fill_rx(struct mt7615_dev *dev, struct sk_buff *skb)
{
struct mt76_rx_status *status = (struct mt76_rx_status *)skb->cb;
@@ -225,7 +202,7 @@ int mt7615_mac_fill_rx(struct mt7615_dev *dev, struct sk_buff *skb)
if (insert_ccmp_hdr) {
u8 key_id = FIELD_GET(MT_RXD1_NORMAL_KEY_ID, rxd1);
- mt7615_insert_ccmp_hdr(skb, key_id);
+ mt76_insert_ccmp_hdr(skb, key_id);
}
hdr = (struct ieee80211_hdr *)skb->data;
--
2.20.1
^ permalink raw reply related
* [BUG] rtlwifi: Resource leaks in error handling code of rtl_pci_probe()
From: Jia-Ju Bai @ 2019-05-14 12:55 UTC (permalink / raw)
To: pkshih, kvalo, davem; +Cc: linux-wireless, netdev, Linux Kernel Mailing List
In rtl_pci_probe(), rtl_pci_init() allocates some resources, such as:
_rtl_pci_init_trx_ring
_rtl_pci_init_rx_ring
_rtl_pci_init_rx_ring
pci_zalloc_consistent() -- resource
_rtl_pci_init_one_rxdesc
dev_alloc_skb() -- resource
_rtl_pci_init_trx_ring
_rtl_pci_init_tx_ring
pci_zalloc_consistent() -- resource
When ieee80211_register_hw() or rtl_pci_intr_mode_decide() fails, these
resources are not released in error handling code.
A possible fix is to call rtl_pci_deinit() in error handling code, but I
am not sure whether this is correct.
Thus, I only report the bugs.
These bugs are found by a runtime fuzzing tool named FIZZER written by us.
Best wishes,
Jia-Ju Bai
^ permalink raw reply
* [BUG] rtlwifi: a crash in error handling code of rtl_pci_probe()
From: Jia-Ju Bai @ 2019-05-14 13:07 UTC (permalink / raw)
To: pkshih, Kalle Valo, David Miller
Cc: Linux Kernel Mailing List, linux-wireless@vger.kernel.org, netdev
In rtl_pci_probe(), when request_irq() in rtl_pci_intr_mode_legacy() in
rtl_pci_intr_mode_decide() fails, a crash occurs.
The crash information is as follows:
[ 108.271155] kasan: CONFIG_KASAN_INLINE enabled
[ 108.271163] kasan: GPF could be caused by NULL-ptr deref or user
memory access
......
[ 108.271193] RIP: 0010:cfg80211_get_drvinfo+0xce/0x3b0 [cfg80211]
......
[ 108.271235] Call Trace:
[ 108.271245] ethtool_get_drvinfo+0x110/0x640
[ 108.271255] ? cfg80211_get_chan_state+0x7e0/0x7e0 [cfg80211]
[ 108.271261] ? ethtool_get_settings+0x340/0x340
[ 108.271268] ? __read_once_size_nocheck.constprop.7+0x20/0x20
[ 108.271279] ? kasan_check_write+0x14/0x20
[ 108.271284] dev_ethtool+0x272d/0x4c20
[ 108.271290] ? unwind_get_return_address+0x66/0xb0
[ 108.271299] ? __save_stack_trace+0x92/0x100
[ 108.271307] ? ethtool_get_rxnfc+0x3f0/0x3f0
[ 108.271316] ? save_stack+0xa3/0xd0
[ 108.271323] ? save_stack+0x43/0xd0
[ 108.271331] ? ftrace_graph_ret_addr+0x2d/0x170
[ 108.271338] ? ftrace_graph_ret_addr+0x2d/0x170
[ 108.271346] ? ftrace_graph_ret_addr+0x2d/0x170
[ 108.271354] ? update_stack_state+0x3b2/0x670
[ 108.271361] ? update_stack_state+0x3b2/0x670
[ 108.271370] ? __read_once_size_nocheck.constprop.7+0x20/0x20
[ 108.271379] ? unwind_next_frame.part.5+0x19f/0xa60
[ 108.271388] ? bpf_prog_kallsyms_find+0x3e/0x270
[ 108.271396] ? is_bpf_text_address+0x1a/0x30
[ 108.271408] ? kernel_text_address+0x11d/0x130
[ 108.271416] ? __kernel_text_address+0x12/0x40
[ 108.271423] ? unwind_get_return_address+0x66/0xb0
[ 108.271431] ? __save_stack_trace+0x92/0x100
[ 108.271440] ? save_stack+0xa3/0xd0
[ 108.271448] ? udp_ioctl+0x35/0xe0
[ 108.271457] ? inet_ioctl+0x100/0x320
[ 108.271466] ? inet_stream_connect+0xb0/0xb0
[ 108.271475] ? alloc_file+0x60/0x480
[ 108.271483] ? alloc_file_pseudo+0x19d/0x270
[ 108.271495] ? sock_alloc_file+0x51/0x170
[ 108.271502] ? __sys_socket+0x12c/0x1f0
[ 108.271510] ? __x64_sys_socket+0x78/0xb0
[ 108.271520] ? do_syscall_64+0xb1/0x2e0
[ 108.271529] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 108.271538] ? kasan_check_read+0x11/0x20
[ 108.271548] ? mutex_lock+0x8f/0xe0
[ 108.271557] ? __mutex_lock_slowpath+0x20/0x20
[ 108.271568] dev_ioctl+0x1fb/0xae0
[ 108.271576] ? dev_ioctl+0x1fb/0xae0
[ 108.271586] ? _copy_from_user+0x71/0xd0
[ 108.271594] sock_do_ioctl+0x1e2/0x2f0
[ 108.271602] ? kmem_cache_alloc+0xf9/0x250
[ 108.271611] ? ___sys_recvmsg+0x5a0/0x5a0
[ 108.271621] ? apparmor_file_alloc_security+0x128/0x7e0
[ 108.271630] ? kasan_unpoison_shadow+0x35/0x50
[ 108.271638] ? kasan_kmalloc+0xad/0xe0
[ 108.271652] ? apparmor_file_alloc_security+0x128/0x7e0
[ 108.271662] ? apparmor_file_alloc_security+0x269/0x7e0
[ 108.271670] sock_ioctl+0x361/0x590
[ 108.271678] ? sock_ioctl+0x361/0x590
[ 108.271686] ? routing_ioctl+0x470/0x470
[ 108.271695] ? kasan_check_write+0x14/0x20
[ 108.271703] ? __mutex_init+0xba/0x130
[ 108.271713] ? percpu_counter_add_batch+0xc7/0x120
[ 108.271722] ? alloc_empty_file+0xae/0x150
[ 108.271729] ? routing_ioctl+0x470/0x470
[ 108.271738] do_vfs_ioctl+0x1ae/0xfe0
[ 108.271745] ? do_vfs_ioctl+0x1ae/0xfe0
[ 108.271754] ? alloc_file_pseudo+0x1ad/0x270
[ 108.271762] ? ioctl_preallocate+0x1e0/0x1e0
[ 108.271770] ? alloc_file+0x480/0x480
[ 108.271778] ? kasan_check_read+0x11/0x20
[ 108.271786] ? __fget+0x24d/0x320
[ 108.271794] ? iterate_fd+0x180/0x180
[ 108.271802] ? fd_install+0x52/0x60
[ 108.271812] ? security_file_ioctl+0x8c/0xb0
[ 108.271820] ksys_ioctl+0x99/0xb0
[ 108.271829] __x64_sys_ioctl+0x78/0xb0
[ 108.271839] do_syscall_64+0xb1/0x2e0
[ 108.271857] ? prepare_exit_to_usermode+0xc8/0x160
[ 108.271871] entry_SYSCALL_64_after_hwframe+0x44/0xa9
......
I checked the driver source code, but cannot find the reason, so I only
report the crash...
Can somebody give an explanation about this crash?
This crash is triggered by a runtime fuzzing tool named FIZZER written
by us.
Best wishes,
Jia-Ju Bai
^ permalink raw reply
* Re: [PATCH v2 00/12] NFC: nxp-nci: clean up and support new ID
From: Oleg Zhurakivskyy @ 2019-05-14 13:30 UTC (permalink / raw)
To: sedat.dilek
Cc: Andy Shevchenko, Clément Perrochaud, Charles Gorand,
linux-nfc, Samuel Ortiz, linux-wireless
In-Reply-To: <CA+icZUW6vttB8EvgBZYi3kT7uhcbQr+baYbif_V6D78ZNEDbHQ@mail.gmail.com>
OK, thanks!
On 5/14/19 3:03 PM, Sedat Dilek wrote:
> It's good to keep both informations - preferable put them into the
> Kconfig help text?
Sure, it's best to keep them both.
Regards,
Oleg
^ permalink raw reply
* Re: [PATCH v2 00/12] NFC: nxp-nci: clean up and support new ID
From: Sedat Dilek @ 2019-05-14 13:44 UTC (permalink / raw)
To: Oleg Zhurakivskyy
Cc: Andy Shevchenko, Clément Perrochaud, Charles Gorand,
linux-nfc, Samuel Ortiz, linux-wireless
In-Reply-To: <4f297fa0-257d-5036-8a1a-0f5434bb5d26@intel.com>
On Tue, May 14, 2019 at 3:30 PM Oleg Zhurakivskyy
<oleg.zhurakivskyy@intel.com> wrote:
>
>
> OK, thanks!
>
> On 5/14/19 3:03 PM, Sedat Dilek wrote:
>
> > It's good to keep both informations - preferable put them into the
> > Kconfig help text?
>
> Sure, it's best to keep them both.
>
While looking at the Kconfig help text; I wonder why...
config NFC_NXP_NCI_I2C
tristate "NXP-NCI I2C support"
depends on NFC_NXP_NCI && I2C
---help---
This module adds support for an I2C interface to the NXP NCI
chips.
Select this if your platform is using the I2C bus.
To compile this driver as a module, choose m here. The module will
be called nxp_nci_i2c.
Say Y if unsure.
Shouldn't that be "Say N if unsure"?
Or Say Yes If Sure :-).
- Sedat -
^ permalink raw reply
* Re: [PATCH v2 00/12] NFC: nxp-nci: clean up and support new ID
From: Oleg Zhurakivskyy @ 2019-05-14 13:56 UTC (permalink / raw)
To: sedat.dilek
Cc: Andy Shevchenko, Clément Perrochaud, Charles Gorand,
linux-nfc, Samuel Ortiz, linux-wireless
In-Reply-To: <CA+icZUWZH-JS=JHLieVd2ga=Zutac2BXd4tk0tSXs+izQ5txOQ@mail.gmail.com>
On 5/14/19 4:44 PM, Sedat Dilek wrote:
> Say Y if unsure.
>
> Shouldn't that be "Say N if unsure"?
> Or Say Yes If Sure :-).
:)
Must be a typo.
As to me, the last 5 lines in the description are extra, but this is just a matter of taste.
Regards,
Oleg
^ permalink raw reply
* Re: [PATCH v2 00/12] NFC: nxp-nci: clean up and support new ID
From: Sedat Dilek @ 2019-05-14 14:53 UTC (permalink / raw)
To: Oleg Zhurakivskyy
Cc: Andy Shevchenko, Clément Perrochaud, Charles Gorand,
linux-nfc, Samuel Ortiz, linux-wireless
In-Reply-To: <787aff34-b1b9-b9e2-faf3-409d7fc95a52@intel.com>
On Tue, May 14, 2019 at 3:57 PM Oleg Zhurakivskyy
<oleg.zhurakivskyy@intel.com> wrote:
>
>
> On 5/14/19 4:44 PM, Sedat Dilek wrote:
>
> > Say Y if unsure.
> >
> > Shouldn't that be "Say N if unsure"?
> > Or Say Yes If Sure :-).
>
> :)
>
> Must be a typo.
>
> As to me, the last 5 lines in the description are extra, but this is just a matter of taste.
>
What about this one?
diff --git a/drivers/nfc/nxp-nci/Kconfig b/drivers/nfc/nxp-nci/Kconfig
index a28c4265354d..b9e6486aa8fe 100644
--- a/drivers/nfc/nxp-nci/Kconfig
+++ b/drivers/nfc/nxp-nci/Kconfig
@@ -2,8 +2,8 @@ config NFC_NXP_NCI
tristate "NXP-NCI NFC driver"
depends on NFC_NCI
---help---
- Generic core driver for NXP NCI chips such as the NPC100
- or PN7150 families.
+ Generic core driver for NXP NCI chips such as the NPC100 (PN547),
+ NPC300 (PN548) or PN7150 families.
This is a driver based on the NCI NFC kernel layers and
will thus not work with NXP libnfc library.
@@ -19,6 +19,11 @@ config NFC_NXP_NCI_I2C
chips.
Select this if your platform is using the I2C bus.
+ Furthermore, the pin control and GPIO driver of the actual SoC or
+ PCH is needed.
+ For example set CONFIG_PINCTRL_SUNRISEPOINT=y to activate the
+ Intel Sunrisepoint (PCH of Intel Skylake) pinctrl and GPIO driver.
+
To compile this driver as a module, choose m here. The module will
be called nxp_nci_i2c.
- Say Y if unsure.
+ Say N if unsure.
- Sedat -
^ permalink raw reply related
* Re: NXP NFC version and ACPI
From: Sedat Dilek @ 2019-05-14 14:59 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Samuel Ortiz, linux-wireless, linux-nfc, oleg.zhurakivskyy,
clement.perrochaud, charles.gorand, Andy Shevchenko
In-Reply-To: <27f2ce02-8deb-384f-af10-7737b703770a@linaro.org>
On Tue, May 14, 2019 at 10:17 AM Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
[...]
Just for the records:
root@iniza:~# rfkill --output ID,TYPE
ID TYPE
0 bluetooth
1 nfc
2 wlan
3 bluetooth
root@iniza:~# rfkill list nfc
1: nfc0: NFC
Soft blocked: no
Hard blocked: no
- Sedat -
^ permalink raw reply
* Re: [PATCH] NFC: Orphan the subsystem
From: Samuel Ortiz @ 2019-05-14 15:15 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, netdev
In-Reply-To: <20190514090231.32414-1-johannes@sipsolutions.net>
Hi Johannes,
On Tue, May 14, 2019 at 11:02:31AM +0200, Johannes Berg wrote:
> Samuel clearly hasn't been working on this in many years and
> patches getting to the wireless list are just being ignored
> entirely now. Mark the subsystem as orphan to reflect the
> current state and revert back to the netdev list so at least
> some fixes can be picked up by Dave.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
I meant to do that for many months now but did not find time to push it
to the top of my TODO. Thanks.
Acked-by: Samuel Ortiz <sameo@linux.intel.com>
> ---
> MAINTAINERS | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index fb9f9d71f7a2..b2659312e9ed 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11028,10 +11028,8 @@ S: Supported
> F: drivers/net/ethernet/qlogic/netxen/
>
> NFC SUBSYSTEM
> -M: Samuel Ortiz <sameo@linux.intel.com>
> -L: linux-wireless@vger.kernel.org
> -L: linux-nfc@lists.01.org (subscribers-only)
> -S: Supported
> +L: netdev@vger.kernel.org
> +S: Orphan
> F: net/nfc/
> F: include/net/nfc/
> F: include/uapi/linux/nfc.h
> --
> 2.17.2
>
^ permalink raw reply
* Re: [PATCH v2] mac80211: remove warning message
From: Joe Perches @ 2019-05-14 15:44 UTC (permalink / raw)
To: Johannes Berg, Yibo Zhao; +Cc: linux-wireless, ath10k, Zhi Chen
In-Reply-To: <e2a6596b99085541a5886c0d0d6393c849ac2d57.camel@sipsolutions.net>
On Tue, 2019-05-14 at 11:12 +0200, Johannes Berg wrote:
> On Tue, 2019-05-14 at 17:10 +0800, Yibo Zhao wrote:
> > On 2019-05-14 17:05, Johannes Berg wrote:
> > > On Tue, 2019-05-14 at 17:01 +0800, Yibo Zhao wrote:
> > > > In multiple SSID cases, it takes time to prepare every AP interface
> > > > to be ready in initializing phase. If a sta already knows everything
> > > > it
> > > > needs to join one of the APs and sends authentication to the AP which
> > > > is not fully prepared at this point of time, AP's channel context
> > > > could be NULL. As a result, warning message occurs.
[]
> > I was planning to use WARN_ON_ONCE() in the first place to replace
> > WARN_ON() then after some discussion, we think removing it could be
> > better. So the first patch was based on my first version which is sent
> > incorrectly. Please check again.
[]
> I guess changing it to WARN_ON_ONCE() makes sense,
WARN_ON_RATELIMIT exists.
> but as per my earlier
> email I'm really not sure about removing it entirely, it doesn't seem
> like a valid scenario and we should take steps elsewhere to prevent it.
^ permalink raw reply
* Re: NXP NFC version and ACPI
From: Daniel Lezcano @ 2019-05-14 16:36 UTC (permalink / raw)
To: sedat.dilek
Cc: Samuel Ortiz, linux-wireless, linux-nfc, oleg.zhurakivskyy,
clement.perrochaud, charles.gorand, Andy Shevchenko
In-Reply-To: <CA+icZUVaBdswfmRfbRtdVJY8ymeDOwDSFEf7G6jneqEmpW84bg@mail.gmail.com>
On 14/05/2019 16:59, Sedat Dilek wrote:
> On Tue, May 14, 2019 at 10:17 AM Daniel Lezcano
> <daniel.lezcano@linaro.org> wrote:
> [...]
>
> Just for the records:
>
> root@iniza:~# rfkill --output ID,TYPE
> ID TYPE
> 0 bluetooth
> 1 nfc
> 2 wlan
> 3 bluetooth
>
> root@iniza:~# rfkill list nfc
> 1: nfc0: NFC
> Soft blocked: no
> Hard blocked: no
>
Thanks, I have checked and it is the same values.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH v2 00/12] NFC: nxp-nci: clean up and support new ID
From: Andy Shevchenko @ 2019-05-14 17:01 UTC (permalink / raw)
To: Sedat Dilek
Cc: Oleg Zhurakivskyy, Clément Perrochaud, Charles Gorand,
linux-nfc, Samuel Ortiz, linux-wireless
In-Reply-To: <CA+icZUV=TBfabHsbzj_JPnxXBjo114LWVJ==xSS7zVPkajmNgw@mail.gmail.com>
On Tue, May 14, 2019 at 04:53:10PM +0200, Sedat Dilek wrote:
> On Tue, May 14, 2019 at 3:57 PM Oleg Zhurakivskyy
> <oleg.zhurakivskyy@intel.com> wrote:
> What about this one?
>
> diff --git a/drivers/nfc/nxp-nci/Kconfig b/drivers/nfc/nxp-nci/Kconfig
> index a28c4265354d..b9e6486aa8fe 100644
> --- a/drivers/nfc/nxp-nci/Kconfig
> +++ b/drivers/nfc/nxp-nci/Kconfig
> @@ -2,8 +2,8 @@ config NFC_NXP_NCI
> tristate "NXP-NCI NFC driver"
> depends on NFC_NCI
> ---help---
> - Generic core driver for NXP NCI chips such as the NPC100
> - or PN7150 families.
> + Generic core driver for NXP NCI chips such as the NPC100 (PN547),
> + NPC300 (PN548) or PN7150 families.
> This is a driver based on the NCI NFC kernel layers and
> will thus not work with NXP libnfc library.
>
> @@ -19,6 +19,11 @@ config NFC_NXP_NCI_I2C
> chips.
> Select this if your platform is using the I2C bus.
>
> + Furthermore, the pin control and GPIO driver of the actual SoC or
> + PCH is needed.
> + For example set CONFIG_PINCTRL_SUNRISEPOINT=y to activate the
> + Intel Sunrisepoint (PCH of Intel Skylake) pinctrl and GPIO driver.
> +
Besides some indentation problems (the help lines should be prefixed with
'TAB + 2 spaces'), this is not needed — it's obvious and usually distros
provide all of pin control drivers anyway.
For debugging one may check deferred devices via DebugFS, or use
'initcall_debug', or other facilities.
> To compile this driver as a module, choose m here. The module will
> be called nxp_nci_i2c.
> - Say Y if unsure.
> + Say N if unsure.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] mt76: mt7615: add preliminary support for mtd eeprom parsing
From: Lorenzo Bianconi @ 2019-05-14 17:11 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo
In-Reply-To: <cover.1557853278.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. Calibration free data parsing is currently missing
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
.../wireless/mediatek/mt76/mt7615/eeprom.c | 32 +++++++++++++++----
1 file changed, 26 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..0313c604ea61 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,13 @@ 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);
+ if (dev->mt76.otp.data) {
+ ret = mt7615_check_eeprom(&dev->mt76);
+ if (ret < 0)
+ memcpy(dev->mt76.eeprom.data, dev->mt76.otp.data,
+ MT7615_EEPROM_SIZE);
+ /* TODO: take into account cal free data */
+ }
dev->mt76.cap.has_2ghz = true;
dev->mt76.cap.has_5ghz = true;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2] mac80211: remove warning message
From: Ben Greear @ 2019-05-14 17:55 UTC (permalink / raw)
To: Joe Perches, Johannes Berg, Yibo Zhao; +Cc: linux-wireless, ath10k, Zhi Chen
In-Reply-To: <34f72d5db336b9898618bf1c5c15ec41094d7d06.camel@perches.com>
On 5/14/19 8:44 AM, Joe Perches wrote:
> On Tue, 2019-05-14 at 11:12 +0200, Johannes Berg wrote:
>> On Tue, 2019-05-14 at 17:10 +0800, Yibo Zhao wrote:
>>> On 2019-05-14 17:05, Johannes Berg wrote:
>>>> On Tue, 2019-05-14 at 17:01 +0800, Yibo Zhao wrote:
>>>>> In multiple SSID cases, it takes time to prepare every AP interface
>>>>> to be ready in initializing phase. If a sta already knows everything
>>>>> it
>>>>> needs to join one of the APs and sends authentication to the AP which
>>>>> is not fully prepared at this point of time, AP's channel context
>>>>> could be NULL. As a result, warning message occurs.
> []
>>> I was planning to use WARN_ON_ONCE() in the first place to replace
>>> WARN_ON() then after some discussion, we think removing it could be
>>> better. So the first patch was based on my first version which is sent
>>> incorrectly. Please check again.
> []
>> I guess changing it to WARN_ON_ONCE() makes sense,
>
> WARN_ON_RATELIMIT exists.
We know the WARN hits, we have the backtrace, and it is easy enough (in my setup
at least) to reproduce this. So, the WARN logic has done its job.
Having more of these spam the kernel doesn't add much benefit I think.
Anyone have any suggestions on how to fix the underlying issue?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2] mac80211: remove warning message
From: Johannes Berg @ 2019-05-14 18:40 UTC (permalink / raw)
To: Ben Greear, Joe Perches, Yibo Zhao; +Cc: linux-wireless, ath10k, Zhi Chen
In-Reply-To: <4d013893-3302-14f0-c957-b3771f4b6b82@candelatech.com>
> We know the WARN hits, we have the backtrace, and it is easy enough (in my setup
> at least) to reproduce this. So, the WARN logic has done its job.
>
> Having more of these spam the kernel doesn't add much benefit I think.
Well, this doesn't necessarily just catch a *single* issue, so it should
remain for the future, I'd think.
> Anyone have any suggestions on how to fix the underlying issue?
I don't even have the backtrace and scenario that causes it.
johannes
^ permalink raw reply
* Re: [PATCH v2] mac80211: remove warning message
From: Ben Greear @ 2019-05-14 18:54 UTC (permalink / raw)
To: Johannes Berg, Yibo Zhao; +Cc: linux-wireless, ath10k, Zhi Chen
In-Reply-To: <8eacb8e107c854b64a0c6116fca9731ddd99dcac.camel@sipsolutions.net>
On 5/14/19 11:40 AM, Johannes Berg wrote:
>
>> We know the WARN hits, we have the backtrace, and it is easy enough (in my setup
>> at least) to reproduce this. So, the WARN logic has done its job.
>>
>> Having more of these spam the kernel doesn't add much benefit I think.
>
> Well, this doesn't necessarily just catch a *single* issue, so it should
> remain for the future, I'd think.
>
>> Anyone have any suggestions on how to fix the underlying issue?
>
> I don't even have the backtrace and scenario that causes it.
>
> johannes
>
Here is the info I have in my commit that changed this to WARN_ON_ONCE.
I never posted it because I had to hack ath10k to get to this state, so maybe
this is not a valid case to debug.
Maybe Yibo Zhao has a better example.
mac80211: don't spam kernel logs when chantx is null.
I set up ath10k to be chandef based again in order to test
WDS. My WDS stations are not very functional yet, and
when ethtool stats are queried, there is a WARN_ON splat
generated. Change this to WARN_ON_ONCE so that there is
less kernel spam.
[ 2401.445631] WARNING: CPU: 1 PID: 14070 at /home/greearb/git/linux-4.13.dev.y/net/mac80211/ieee80211_i.h:1452 sta_set_rate_info_tx+0x18c/0x1a0 [mac80211]
[ 2401.445727] Modules linked in: nf_conntrack_netlink nf_conntrack nfnetlink wanlink(O) ath10k_pci ath10k_core mac80211_hwsim ath5k ath9k ath9k_common
ath9k_hw ath mac80211 cfg80211 nf_defrag_ipv4 libcrc32c 8021q garp mrp stp llc fuse macvlan pktgen nfsv3 nfs fscache amd64_edac_mod edac_mce_amd kvm_amd kvm
irqbypass sp5100_tco fam15h_power k10temp i2c_piix4 ccp shpchp acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc sdhci_pci sdhci mmc_core
igb hwmon ptp pps_core i2c_algo_bit i2c_core dca ipv6 crc_ccitt [last unloaded: nfnetlink]
[ 2401.445911] CPU: 1 PID: 14070 Comm: btserver Tainted: G W O 4.13.11+ #18
[ 2401.445914] Hardware name: PC Engines apu2/apu2, BIOS 88a4f96 03/07/2016
[ 2401.445918] task: ffff880118c73b80 task.stack: ffffc90001400000
[ 2401.445973] RIP: 0010:sta_set_rate_info_tx+0x18c/0x1a0 [mac80211]
[ 2401.446003] RSP: 0018:ffffc90001403820 EFLAGS: 00010246
[ 2401.446007] RAX: 0000000000000000 RBX: ffff8800ca38e4a0 RCX: 000000000000000c
[ 2401.446010] RDX: 0000000000000000 RSI: ffff8800ca38e4a0 RDI: ffff8800ca38e000
[ 2401.446013] RBP: ffffc90001403850 R08: ffffffffa04437a0 R09: 0000000000002000
[ 2401.446016] R10: 000000001183be82 R11: 0000000000000000 R12: ffffc90001403970
[ 2401.446018] R13: 0000000000000000 R14: ffff8800c01d8900 R15: ffff8800ca180780
[ 2401.446023] FS: 00007f8123ed7740(0000) GS:ffff88011ec80000(0000) knlGS:0000000000000000
[ 2401.446026] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2401.446029] CR2: 00000000036e8018 CR3: 00000000c0b29000 CR4: 00000000000406e0
[ 2401.446034] Call Trace:
[ 2401.446140] sta_set_sinfo+0x629/0x8b0 [mac80211]
[ 2401.446192] ieee80211_get_stats+0x3f2/0x8c0 [mac80211]
[ 2401.446207] ? __nla_put+0x20/0x30
[ 2401.446221] ? __kmalloc_reserve.isra.35+0x2c/0x80
[ 2401.446229] ? netlink_deliver_tap+0x2d/0x1e0
[ 2401.446235] ? sock_def_readable+0x6d/0x70
[ 2401.446239] ? __netlink_sendskb+0x36/0x40
[ 2401.446245] ? netlink_unicast+0x1b0/0x1f0
[ 2401.446252] ? rtnl_getlink+0x135/0x1c0
[ 2401.446261] ? get_page_from_freelist+0x913/0xac0
[ 2401.446270] ? vmap_page_range_noflush+0x27d/0x370
[ 2401.446277] ? map_vm_area+0x31/0x40
[ 2401.446284] ? __vmalloc_node_range+0x21f/0x270
[ 2401.446319] dev_ethtool+0x11d1/0x1ce0
[ 2401.446325] ? __rtnl_unlock+0x25/0x50
[ 2401.446330] ? netdev_run_todo+0x4d/0x2e0
[ 2401.446338] ? dev_get_by_name_rcu+0x6f/0xa0
[ 2401.446344] dev_ioctl+0x330/0x550
[ 2401.446349] ? reuse_swap_page+0x30/0x100
[ 2401.446355] sock_do_ioctl+0x3d/0x50
[ 2401.446359] ? sock_do_ioctl+0x3d/0x50
[ 2401.446363] sock_ioctl+0x1e5/0x2a0
[ 2401.446370] do_vfs_ioctl+0x8b/0x5b0
[ 2401.446376] ? getnstimeofday64+0x9/0x20
[ 2401.446383] ? __audit_syscall_entry+0xba/0x110
[ 2401.446391] ? syscall_trace_enter+0x1b0/0x2b0
[ 2401.446395] SyS_ioctl+0x74/0x80
[ 2401.446400] ? __audit_syscall_exit+0x215/0x2b0
[ 2401.446405] do_syscall_64+0x5c/0x190
[ 2401.446412] entry_SYSCALL64_slow_path+0x25/0x25
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2] mac80211: remove warning message
From: Johannes Berg @ 2019-05-14 18:57 UTC (permalink / raw)
To: Ben Greear, Yibo Zhao; +Cc: linux-wireless, ath10k, Zhi Chen
In-Reply-To: <730d3664-488d-7d57-04d5-1a57e91fa070@candelatech.com>
On Tue, 2019-05-14 at 11:54 -0700, Ben Greear wrote:
>
> Here is the info I have in my commit that changed this to WARN_ON_ONCE.
> I never posted it because I had to hack ath10k to get to this state, so maybe
> this is not a valid case to debug.
>
>
> Maybe Yibo Zhao has a better example.
>
> mac80211: don't spam kernel logs when chantx is null.
>
> I set up ath10k to be chandef based again in order to test
> WDS. My WDS stations are not very functional yet, and
> when ethtool stats are queried, there is a WARN_ON splat
> generated. Change this to WARN_ON_ONCE so that there is
> less kernel spam.
I'm totally fine with WARN_ON_ONCE, FWIW.
Sounds like different bugs though. You're talking about WDS here, and
Yibo was talking about something with AP interfaces prematurely
accepting frames or so.
johannes
^ permalink raw reply
* Re: [PATCH][next] iwlwifi: d3: Use struct_size() helper
From: Gustavo A. R. Silva @ 2019-05-14 18:58 UTC (permalink / raw)
To: Luciano Coelho, Johannes Berg, Emmanuel Grumbach,
Intel Linux Wireless, Kalle Valo, David S. Miller
Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <c4a1fd36abf6acafa35bb70f87791d4ef802d87c.camel@intel.com>
On 5/14/19 12:16 AM, Luciano Coelho wrote:
>
> Thanks! Applied to our internal tree and it will reach the mainline
> following our normal upstreaming process.
>
Awesome. :)
Thanks, Luciano.
--
Gustavo
^ permalink raw reply
* [PATCH] libertas/libertas_tf: fix spelling mistake "Donwloading" -> "Downloading"
From: Colin King @ 2019-05-14 21:14 UTC (permalink / raw)
To: Kalle Valo, David S . Miller, libertas-dev, linux-wireless,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There is are two spelling mistakes in lbtf_deb_usb2 messages, fix these.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/marvell/libertas/if_usb.c | 2 +-
drivers/net/wireless/marvell/libertas_tf/if_usb.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/libertas/if_usb.c b/drivers/net/wireless/marvell/libertas/if_usb.c
index 220dcdee8d2b..1d06fa564e28 100644
--- a/drivers/net/wireless/marvell/libertas/if_usb.c
+++ b/drivers/net/wireless/marvell/libertas/if_usb.c
@@ -367,7 +367,7 @@ static int if_usb_send_fw_pkt(struct if_usb_card *cardp)
cardp->fwseqnum, cardp->totalbytes);
} else if (fwdata->hdr.dnldcmd == cpu_to_le32(FW_HAS_LAST_BLOCK)) {
lbs_deb_usb2(&cardp->udev->dev, "Host has finished FW downloading\n");
- lbs_deb_usb2(&cardp->udev->dev, "Donwloading FW JUMP BLOCK\n");
+ lbs_deb_usb2(&cardp->udev->dev, "Downloading FW JUMP BLOCK\n");
cardp->fwfinalblk = 1;
}
diff --git a/drivers/net/wireless/marvell/libertas_tf/if_usb.c b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
index a4b9ede70705..38f77b1a02ca 100644
--- a/drivers/net/wireless/marvell/libertas_tf/if_usb.c
+++ b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
@@ -319,7 +319,7 @@ static int if_usb_send_fw_pkt(struct if_usb_card *cardp)
} else if (fwdata->hdr.dnldcmd == cpu_to_le32(FW_HAS_LAST_BLOCK)) {
lbtf_deb_usb2(&cardp->udev->dev,
"Host has finished FW downloading\n");
- lbtf_deb_usb2(&cardp->udev->dev, "Donwloading FW JUMP BLOCK\n");
+ lbtf_deb_usb2(&cardp->udev->dev, "Downloading FW JUMP BLOCK\n");
/* Host has finished FW downloading
* Donwloading FW JUMP BLOCK
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] NFC: Orphan the subsystem
From: David Miller @ 2019-05-14 22:32 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, netdev, sameo
In-Reply-To: <20190514090231.32414-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Tue, 14 May 2019 11:02:31 +0200
> Samuel clearly hasn't been working on this in many years and
> patches getting to the wireless list are just being ignored
> entirely now. Mark the subsystem as orphan to reflect the
> current state and revert back to the netdev list so at least
> some fixes can be picked up by Dave.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Applied.
^ permalink raw reply
* Re: [BUG] rtlwifi: a crash in error handling code of rtl_pci_probe()
From: Larry Finger @ 2019-05-15 1:08 UTC (permalink / raw)
To: Jia-Ju Bai, pkshih, Kalle Valo, David Miller
Cc: Linux Kernel Mailing List, linux-wireless@vger.kernel.org, netdev
In-Reply-To: <4627da7a-c56c-5d88-62ae-ea2be9430f6f@gmail.com>
On 5/14/19 8:07 AM, Jia-Ju Bai wrote:
> In rtl_pci_probe(), when request_irq() in rtl_pci_intr_mode_legacy() in
> rtl_pci_intr_mode_decide() fails, a crash occurs.
> The crash information is as follows:
>
> [ 108.271155] kasan: CONFIG_KASAN_INLINE enabled
> [ 108.271163] kasan: GPF could be caused by NULL-ptr deref or user memory access
> ......
> [ 108.271193] RIP: 0010:cfg80211_get_drvinfo+0xce/0x3b0 [cfg80211]
> ......
> [ 108.271235] Call Trace:
> [ 108.271245] ethtool_get_drvinfo+0x110/0x640
> [ 108.271255] ? cfg80211_get_chan_state+0x7e0/0x7e0 [cfg80211]
> [ 108.271261] ? ethtool_get_settings+0x340/0x340
> [ 108.271268] ? __read_once_size_nocheck.constprop.7+0x20/0x20
> [ 108.271279] ? kasan_check_write+0x14/0x20
> [ 108.271284] dev_ethtool+0x272d/0x4c20
> [ 108.271290] ? unwind_get_return_address+0x66/0xb0
> [ 108.271299] ? __save_stack_trace+0x92/0x100
> [ 108.271307] ? ethtool_get_rxnfc+0x3f0/0x3f0
> [ 108.271316] ? save_stack+0xa3/0xd0
> [ 108.271323] ? save_stack+0x43/0xd0
> [ 108.271331] ? ftrace_graph_ret_addr+0x2d/0x170
> [ 108.271338] ? ftrace_graph_ret_addr+0x2d/0x170
> [ 108.271346] ? ftrace_graph_ret_addr+0x2d/0x170
> [ 108.271354] ? update_stack_state+0x3b2/0x670
> [ 108.271361] ? update_stack_state+0x3b2/0x670
> [ 108.271370] ? __read_once_size_nocheck.constprop.7+0x20/0x20
> [ 108.271379] ? unwind_next_frame.part.5+0x19f/0xa60
> [ 108.271388] ? bpf_prog_kallsyms_find+0x3e/0x270
> [ 108.271396] ? is_bpf_text_address+0x1a/0x30
> [ 108.271408] ? kernel_text_address+0x11d/0x130
> [ 108.271416] ? __kernel_text_address+0x12/0x40
> [ 108.271423] ? unwind_get_return_address+0x66/0xb0
> [ 108.271431] ? __save_stack_trace+0x92/0x100
> [ 108.271440] ? save_stack+0xa3/0xd0
> [ 108.271448] ? udp_ioctl+0x35/0xe0
> [ 108.271457] ? inet_ioctl+0x100/0x320
> [ 108.271466] ? inet_stream_connect+0xb0/0xb0
> [ 108.271475] ? alloc_file+0x60/0x480
> [ 108.271483] ? alloc_file_pseudo+0x19d/0x270
> [ 108.271495] ? sock_alloc_file+0x51/0x170
> [ 108.271502] ? __sys_socket+0x12c/0x1f0
> [ 108.271510] ? __x64_sys_socket+0x78/0xb0
> [ 108.271520] ? do_syscall_64+0xb1/0x2e0
> [ 108.271529] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 108.271538] ? kasan_check_read+0x11/0x20
> [ 108.271548] ? mutex_lock+0x8f/0xe0
> [ 108.271557] ? __mutex_lock_slowpath+0x20/0x20
> [ 108.271568] dev_ioctl+0x1fb/0xae0
> [ 108.271576] ? dev_ioctl+0x1fb/0xae0
> [ 108.271586] ? _copy_from_user+0x71/0xd0
> [ 108.271594] sock_do_ioctl+0x1e2/0x2f0
> [ 108.271602] ? kmem_cache_alloc+0xf9/0x250
> [ 108.271611] ? ___sys_recvmsg+0x5a0/0x5a0
> [ 108.271621] ? apparmor_file_alloc_security+0x128/0x7e0
> [ 108.271630] ? kasan_unpoison_shadow+0x35/0x50
> [ 108.271638] ? kasan_kmalloc+0xad/0xe0
> [ 108.271652] ? apparmor_file_alloc_security+0x128/0x7e0
> [ 108.271662] ? apparmor_file_alloc_security+0x269/0x7e0
> [ 108.271670] sock_ioctl+0x361/0x590
> [ 108.271678] ? sock_ioctl+0x361/0x590
> [ 108.271686] ? routing_ioctl+0x470/0x470
> [ 108.271695] ? kasan_check_write+0x14/0x20
> [ 108.271703] ? __mutex_init+0xba/0x130
> [ 108.271713] ? percpu_counter_add_batch+0xc7/0x120
> [ 108.271722] ? alloc_empty_file+0xae/0x150
> [ 108.271729] ? routing_ioctl+0x470/0x470
> [ 108.271738] do_vfs_ioctl+0x1ae/0xfe0
> [ 108.271745] ? do_vfs_ioctl+0x1ae/0xfe0
> [ 108.271754] ? alloc_file_pseudo+0x1ad/0x270
> [ 108.271762] ? ioctl_preallocate+0x1e0/0x1e0
> [ 108.271770] ? alloc_file+0x480/0x480
> [ 108.271778] ? kasan_check_read+0x11/0x20
> [ 108.271786] ? __fget+0x24d/0x320
> [ 108.271794] ? iterate_fd+0x180/0x180
> [ 108.271802] ? fd_install+0x52/0x60
> [ 108.271812] ? security_file_ioctl+0x8c/0xb0
> [ 108.271820] ksys_ioctl+0x99/0xb0
> [ 108.271829] __x64_sys_ioctl+0x78/0xb0
> [ 108.271839] do_syscall_64+0xb1/0x2e0
> [ 108.271857] ? prepare_exit_to_usermode+0xc8/0x160
> [ 108.271871] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> ......
>
> I checked the driver source code, but cannot find the reason, so I only report
> the crash...
> Can somebody give an explanation about this crash?
>
> This crash is triggered by a runtime fuzzing tool named FIZZER written by us.
Your backtrace does not include any references to rtlwifi routines, and I have
no idea what FIZZER does, thus it is not possible for me to debug this. If the
error situation that you state happens, the code should end up at label "fail3"
in routine rtl_pci_probe(). Insert printk statements after every line of the
following, and report the last good point before the error. It is certainly
possible that something is being torn down that was never erected. The
likelihood of failure of both MSI and legacy interrupts is not very likely, and
we probably have never hit those conditions.
fail3:
pci_set_drvdata(pdev, NULL);
rtl_deinit_core(hw);
fail2:
if (rtlpriv->io.pci_mem_start != 0)
pci_iounmap(pdev, (void __iomem *)rtlpriv->io.pci_mem_start);
pci_release_regions(pdev);
complete(&rtlpriv->firmware_loading_complete);
fail1:
if (hw)
ieee80211_free_hw(hw);
pci_disable_device(pdev);
return err;
Larry
^ permalink raw reply
* Re: [BUG] rtlwifi: a crash in error handling code of rtl_pci_probe()
From: Jia-Ju Bai @ 2019-05-15 1:20 UTC (permalink / raw)
To: Larry Finger, pkshih, Kalle Valo, David Miller
Cc: Linux Kernel Mailing List, linux-wireless@vger.kernel.org, netdev
In-Reply-To: <12810ae7-ff10-42be-7887-19b68331980c@lwfinger.net>
On 2019/5/15 9:08, Larry Finger wrote:
> On 5/14/19 8:07 AM, Jia-Ju Bai wrote:
>> In rtl_pci_probe(), when request_irq() in rtl_pci_intr_mode_legacy()
>> in rtl_pci_intr_mode_decide() fails, a crash occurs.
>> The crash information is as follows:
>>
>> [ 108.271155] kasan: CONFIG_KASAN_INLINE enabled
>> [ 108.271163] kasan: GPF could be caused by NULL-ptr deref or user
>> memory access
>> ......
>> [ 108.271193] RIP: 0010:cfg80211_get_drvinfo+0xce/0x3b0 [cfg80211]
>> ......
>> [ 108.271235] Call Trace:
>> [ 108.271245] ethtool_get_drvinfo+0x110/0x640
>> [ 108.271255] ? cfg80211_get_chan_state+0x7e0/0x7e0 [cfg80211]
>> [ 108.271261] ? ethtool_get_settings+0x340/0x340
>> [ 108.271268] ? __read_once_size_nocheck.constprop.7+0x20/0x20
>> [ 108.271279] ? kasan_check_write+0x14/0x20
>> [ 108.271284] dev_ethtool+0x272d/0x4c20
>> [ 108.271290] ? unwind_get_return_address+0x66/0xb0
>> [ 108.271299] ? __save_stack_trace+0x92/0x100
>> [ 108.271307] ? ethtool_get_rxnfc+0x3f0/0x3f0
>> [ 108.271316] ? save_stack+0xa3/0xd0
>> [ 108.271323] ? save_stack+0x43/0xd0
>> [ 108.271331] ? ftrace_graph_ret_addr+0x2d/0x170
>> [ 108.271338] ? ftrace_graph_ret_addr+0x2d/0x170
>> [ 108.271346] ? ftrace_graph_ret_addr+0x2d/0x170
>> [ 108.271354] ? update_stack_state+0x3b2/0x670
>> [ 108.271361] ? update_stack_state+0x3b2/0x670
>> [ 108.271370] ? __read_once_size_nocheck.constprop.7+0x20/0x20
>> [ 108.271379] ? unwind_next_frame.part.5+0x19f/0xa60
>> [ 108.271388] ? bpf_prog_kallsyms_find+0x3e/0x270
>> [ 108.271396] ? is_bpf_text_address+0x1a/0x30
>> [ 108.271408] ? kernel_text_address+0x11d/0x130
>> [ 108.271416] ? __kernel_text_address+0x12/0x40
>> [ 108.271423] ? unwind_get_return_address+0x66/0xb0
>> [ 108.271431] ? __save_stack_trace+0x92/0x100
>> [ 108.271440] ? save_stack+0xa3/0xd0
>> [ 108.271448] ? udp_ioctl+0x35/0xe0
>> [ 108.271457] ? inet_ioctl+0x100/0x320
>> [ 108.271466] ? inet_stream_connect+0xb0/0xb0
>> [ 108.271475] ? alloc_file+0x60/0x480
>> [ 108.271483] ? alloc_file_pseudo+0x19d/0x270
>> [ 108.271495] ? sock_alloc_file+0x51/0x170
>> [ 108.271502] ? __sys_socket+0x12c/0x1f0
>> [ 108.271510] ? __x64_sys_socket+0x78/0xb0
>> [ 108.271520] ? do_syscall_64+0xb1/0x2e0
>> [ 108.271529] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
>> [ 108.271538] ? kasan_check_read+0x11/0x20
>> [ 108.271548] ? mutex_lock+0x8f/0xe0
>> [ 108.271557] ? __mutex_lock_slowpath+0x20/0x20
>> [ 108.271568] dev_ioctl+0x1fb/0xae0
>> [ 108.271576] ? dev_ioctl+0x1fb/0xae0
>> [ 108.271586] ? _copy_from_user+0x71/0xd0
>> [ 108.271594] sock_do_ioctl+0x1e2/0x2f0
>> [ 108.271602] ? kmem_cache_alloc+0xf9/0x250
>> [ 108.271611] ? ___sys_recvmsg+0x5a0/0x5a0
>> [ 108.271621] ? apparmor_file_alloc_security+0x128/0x7e0
>> [ 108.271630] ? kasan_unpoison_shadow+0x35/0x50
>> [ 108.271638] ? kasan_kmalloc+0xad/0xe0
>> [ 108.271652] ? apparmor_file_alloc_security+0x128/0x7e0
>> [ 108.271662] ? apparmor_file_alloc_security+0x269/0x7e0
>> [ 108.271670] sock_ioctl+0x361/0x590
>> [ 108.271678] ? sock_ioctl+0x361/0x590
>> [ 108.271686] ? routing_ioctl+0x470/0x470
>> [ 108.271695] ? kasan_check_write+0x14/0x20
>> [ 108.271703] ? __mutex_init+0xba/0x130
>> [ 108.271713] ? percpu_counter_add_batch+0xc7/0x120
>> [ 108.271722] ? alloc_empty_file+0xae/0x150
>> [ 108.271729] ? routing_ioctl+0x470/0x470
>> [ 108.271738] do_vfs_ioctl+0x1ae/0xfe0
>> [ 108.271745] ? do_vfs_ioctl+0x1ae/0xfe0
>> [ 108.271754] ? alloc_file_pseudo+0x1ad/0x270
>> [ 108.271762] ? ioctl_preallocate+0x1e0/0x1e0
>> [ 108.271770] ? alloc_file+0x480/0x480
>> [ 108.271778] ? kasan_check_read+0x11/0x20
>> [ 108.271786] ? __fget+0x24d/0x320
>> [ 108.271794] ? iterate_fd+0x180/0x180
>> [ 108.271802] ? fd_install+0x52/0x60
>> [ 108.271812] ? security_file_ioctl+0x8c/0xb0
>> [ 108.271820] ksys_ioctl+0x99/0xb0
>> [ 108.271829] __x64_sys_ioctl+0x78/0xb0
>> [ 108.271839] do_syscall_64+0xb1/0x2e0
>> [ 108.271857] ? prepare_exit_to_usermode+0xc8/0x160
>> [ 108.271871] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>> ......
>>
>> I checked the driver source code, but cannot find the reason, so I
>> only report the crash...
>> Can somebody give an explanation about this crash?
>>
>> This crash is triggered by a runtime fuzzing tool named FIZZER
>> written by us.
>
> Your backtrace does not include any references to rtlwifi routines,
> and I have no idea what FIZZER does, thus it is not possible for me to
> debug this. If the error situation that you state happens, the code
> should end up at label "fail3" in routine rtl_pci_probe(). Insert
> printk statements after every line of the following, and report the
> last good point before the error. It is certainly possible that
> something is being torn down that was never erected. The likelihood of
> failure of both MSI and legacy interrupts is not very likely, and we
> probably have never hit those conditions.
>
> fail3:
> pci_set_drvdata(pdev, NULL);
> rtl_deinit_core(hw);
>
> fail2:
> if (rtlpriv->io.pci_mem_start != 0)
> pci_iounmap(pdev, (void __iomem
> *)rtlpriv->io.pci_mem_start);
>
> pci_release_regions(pdev);
> complete(&rtlpriv->firmware_loading_complete);
>
> fail1:
> if (hw)
> ieee80211_free_hw(hw);
> pci_disable_device(pdev);
>
> return err;
Thanks for the advice :)
I will insert some printk statements to debug this problem.
Best wishes,
Jia-Ju Bai
^ permalink raw reply
* Thank You For Contacting Us
From: Clarendon Fleet Livery Ltd via Clarendon Fleet Livery Ltd @ 2019-05-15 1:38 UTC (permalink / raw)
To: linux-wireless
Dear FrankGlaKy,
Thank you for contacting us. We have received your message and will respond
as soon as we can.
^ permalink raw reply
* Re: [PATCH v2] ath10k: add support for simulate crash on SDIO chip
From: Claire Chang @ 2019-05-15 2:52 UTC (permalink / raw)
To: Wen Gong; +Cc: ath10k, open list:NETWORKING DRIVERS (WIRELESS)
In-Reply-To: <1556524457-17469-1-git-send-email-wgong@codeaurora.org>
Tested-by: Claire Chang <tientzu@chromium.org>
If this patch adds support for detecting the real firmware assert,
maybe the title should be "add support for _crash recovery_ on SDIO
chip"
^ permalink raw reply
* [PATCH] ath10k: change firmware file name for UTF mode of SDIO/USB
From: Wen Gong @ 2019-05-15 3:30 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
Firmware name for UTF mode of SDIO has changed from utf-2.bin to
utf-sdio-2.bin, so it need to change in ath10k, otherwise it will
fail for UTF mode.
After change the name in ath10k, it will success for UTF mode of
SDIO/USB.
Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00007-QCARMSWP-1.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/hw.h | 2 ++
drivers/net/wireless/ath/ath10k/testmode.c | 17 ++++++++++++++++-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 7131499..d4fc13d 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -151,6 +151,8 @@ enum qca9377_chip_id_rev {
#define ATH10K_FW_UTF_FILE "utf.bin"
#define ATH10K_FW_UTF_API2_FILE "utf-2.bin"
+#define ATH10K_FW_UTF_FILE_BASE "utf"
+
/* includes also the null byte */
#define ATH10K_FIRMWARE_MAGIC "QCA-ATH10K"
#define ATH10K_BOARD_MAGIC "QCA-ATH10K-BOARD"
diff --git a/drivers/net/wireless/ath/ath10k/testmode.c b/drivers/net/wireless/ath/ath10k/testmode.c
index 6433ff1..da9c596 100644
--- a/drivers/net/wireless/ath/ath10k/testmode.c
+++ b/drivers/net/wireless/ath/ath10k/testmode.c
@@ -174,8 +174,23 @@ static int ath10k_tm_fetch_firmware(struct ath10k *ar)
{
struct ath10k_fw_components *utf_mode_fw;
int ret;
+ char fw_name[100];
+ int fw_api2 = 2;
+
+ switch (ar->hif.bus) {
+ case ATH10K_BUS_SDIO:
+ case ATH10K_BUS_USB:
+ scnprintf(fw_name, sizeof(fw_name), "%s-%s-%d.bin",
+ ATH10K_FW_UTF_FILE_BASE, ath10k_bus_str(ar->hif.bus),
+ fw_api2);
+ break;
+ default:
+ scnprintf(fw_name, sizeof(fw_name), "%s-%d.bin",
+ ATH10K_FW_UTF_FILE_BASE, fw_api2);
+ break;
+ }
- ret = ath10k_core_fetch_firmware_api_n(ar, ATH10K_FW_UTF_API2_FILE,
+ ret = ath10k_core_fetch_firmware_api_n(ar, fw_name,
&ar->testmode.utf_mode_fw.fw_file);
if (ret == 0) {
ath10k_dbg(ar, ATH10K_DBG_TESTMODE, "testmode using fw utf api 2");
--
1.9.1
^ permalink raw reply related
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