* 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] 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: [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: 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 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: [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 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: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
* [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
* [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
* [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
* [PATCH] rtlwifi: Fix null-pointer dereferences in error handling code of rtl_pci_probe()
From: Jia-Ju Bai @ 2019-05-14 12:34 UTC (permalink / raw)
To: pkshih, kvalo, davem; +Cc: linux-wireless, netdev, linux-kernel, Jia-Ju Bai
*BUG 1:
In rtl_pci_probe(), when rtlpriv->cfg->ops->init_sw_vars() fails,
rtl_deinit_core() in the error handling code is executed.
rtl_deinit_core() calls rtl_free_entries_from_scan_list(), which uses
rtlpriv->scan_list.list in list_for_each_entry_safe(), but it has been
initialized. Thus a null-pointer dereference occurs.
The reason is that rtlpriv->scan_list.list is initialized by
INIT_LIST_HEAD() in rtl_init_core(), which has not been called.
To fix this bug, rtl_deinit_core() should not be called when
rtlpriv->cfg->ops->init_sw_vars() fails.
*BUG 2:
In rtl_pci_probe(), rtl_init_core() can fail when rtl_regd_init() in
this function fails, and rtlpriv->scan_list.list has not been
initialized by INIT_LIST_HEAD(). Then, rtl_deinit_core() in the error
handling code of rtl_pci_probe() is executed. Finally, a null-pointer
dereference occurs due to the same reason of the above bug.
To fix this bug, the initialization of lists in rtl_init_core() are
performed before the call to rtl_regd_init().
These bugs are found by a runtime fuzzing tool named FIZZER written by
us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/net/wireless/realtek/rtlwifi/base.c | 15 ++++++++-------
drivers/net/wireless/realtek/rtlwifi/pci.c | 4 ++--
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c b/drivers/net/wireless/realtek/rtlwifi/base.c
index 217d2a7a43c7..b3f341ec3710 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -526,8 +526,14 @@ int rtl_init_core(struct ieee80211_hw *hw)
/* <2> rate control register */
hw->rate_control_algorithm = "rtl_rc";
+ /* <3> init list */
+ INIT_LIST_HEAD(&rtlpriv->entry_list);
+ INIT_LIST_HEAD(&rtlpriv->scan_list.list);
+ skb_queue_head_init(&rtlpriv->tx_report.queue);
+ skb_queue_head_init(&rtlpriv->c2hcmd_queue);
+
/*
- * <3> init CRDA must come after init
+ * <4> init CRDA must come after init
* mac80211 hw in _rtl_init_mac80211.
*/
if (rtl_regd_init(hw, rtl_reg_notifier)) {
@@ -535,7 +541,7 @@ int rtl_init_core(struct ieee80211_hw *hw)
return 1;
}
- /* <4> locks */
+ /* <5> locks */
mutex_init(&rtlpriv->locks.conf_mutex);
mutex_init(&rtlpriv->locks.ips_mutex);
mutex_init(&rtlpriv->locks.lps_mutex);
@@ -550,11 +556,6 @@ int rtl_init_core(struct ieee80211_hw *hw)
spin_lock_init(&rtlpriv->locks.cck_and_rw_pagea_lock);
spin_lock_init(&rtlpriv->locks.fw_ps_lock);
spin_lock_init(&rtlpriv->locks.iqk_lock);
- /* <5> init list */
- INIT_LIST_HEAD(&rtlpriv->entry_list);
- INIT_LIST_HEAD(&rtlpriv->scan_list.list);
- skb_queue_head_init(&rtlpriv->tx_report.queue);
- skb_queue_head_init(&rtlpriv->c2hcmd_queue);
rtlmac->link_state = MAC80211_NOLINK;
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 48ca52102cef..864cb76230c4 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -2267,7 +2267,7 @@ int rtl_pci_probe(struct pci_dev *pdev,
if (rtlpriv->cfg->ops->init_sw_vars(hw)) {
pr_err("Can't init_sw_vars\n");
err = -ENODEV;
- goto fail3;
+ goto fail2;
}
rtlpriv->cfg->ops->init_sw_leds(hw);
--
2.17.0
^ permalink raw reply related
* [PATCH] mt76: mt7615: stop mcu first in mt7615_unregister_device
From: Lorenzo Bianconi @ 2019-05-14 12:20 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo
In-Reply-To: <cover.1557836235.git.lorenzo@kernel.org>
Stop mcu engine and then dma one in mt7615_unregister_device
in order to avoid a mcu hang in mt7615_unregister_device
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
This patch ca be squashed with 'mt76: mt7615: rearrange cleanup operations in
mt7615_unregister_device' since it is not upstream yet
---
drivers/net/wireless/mediatek/mt76/mt7615/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
index 59f604f3161f..369b9a8e07be 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
@@ -213,8 +213,8 @@ void mt7615_unregister_device(struct mt7615_dev *dev)
int id;
mt76_unregister_device(&dev->mt76);
- mt7615_dma_cleanup(dev);
mt7615_mcu_exit(dev);
+ mt7615_dma_cleanup(dev);
spin_lock_bh(&dev->token_lock);
idr_for_each_entry(&dev->token, txwi, id) {
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 00/12] NFC: nxp-nci: clean up and support new ID
From: Sedat Dilek @ 2019-05-14 12:12 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Clément Perrochaud, Charles Gorand, linux-nfc, Samuel Ortiz,
linux-wireless, Oleg Zhurakivskyy
In-Reply-To: <20190514100328.GB9224@smile.fi.intel.com>
On Tue, May 14, 2019 at 12:03 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, May 13, 2019 at 09:48:15PM +0200, Sedat Dilek wrote:
> > On Mon, May 13, 2019 at 12:44 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
>
> > Is it possible to have an info in dmesg log when nxp-nci_i2c kernel
> > module is loaded?
>
> We have 'initcall_debug' for such purposes.
>
Thanks.
That's nice for retrieving helpful informations, especially the proble
line (see below).
Unload nxp_nci_i2c module...
[ 277.362813] NET: Unregistered protocol family 39
...and reload nxp_nci_i2c module...
[ 291.640491] calling nfc_init+0x0/0x8e [nfc] @ 2998
[ 291.640499] nfc: nfc_init: NFC Core ver 0.1
[ 291.640603] NET: Registered protocol family 39
[ 291.640651] initcall nfc_init+0x0/0x8e [nfc] returned 0 after 111 usecs
[ 291.653179] calling nxp_nci_i2c_driver_init+0x0/0x1000 [nxp_nci_i2c] @ 2998
[ 291.669584] probe of i2c-NXP1001:00 returned 1 after 16364 usecs
[ 291.669841] initcall nxp_nci_i2c_driver_init+0x0/0x1000
[nxp_nci_i2c] returned 0 after 16244 usecs
What I mean is (here: btrfs and vboxdrv built as modules)...
[ 21.285569] Btrfs loaded, crc32c=crc32c-intel
[ 28.823902] vboxdrv: Successfully loaded version 6.0.6_Debian
(interface 0x00290008)
- Sedat -
^ permalink raw reply
* Re: [PATCH v2 00/12] NFC: nxp-nci: clean up and support new ID
From: Sedat Dilek @ 2019-05-14 12:03 UTC (permalink / raw)
To: Oleg Zhurakivskyy
Cc: Andy Shevchenko, Clément Perrochaud, Charles Gorand,
linux-nfc, Samuel Ortiz, linux-wireless
In-Reply-To: <2d39b39b-27eb-abef-747f-400433daefee@intel.com>
On Tue, May 14, 2019 at 1:45 PM Oleg Zhurakivskyy
<oleg.zhurakivskyy@intel.com> wrote:
>
>
> On 5/14/19 11:34 AM, Sedat Dilek wrote:
>
> > Am I correct that "NPC100" is "PN547" and "NPC300" is "PN548"?
>
> Yes, NPC100 is PN547.
>
> Don’t know on NPC300, but a quick web search reveals it’s PN548.
>
> Might it make sense to drop NPC... and to keep just the chip names in Kconfig?
>
Thanks for the clarification.
I found NXP NPC300 windows driver from Lenovo's support website - not
on the support websites for ThinkPad T470 but for other ThinkPads like
T480.
It's the same driver and by accident I could update via Microsoft
device-manager to version 12.0.4.0.
So if you search in the Wild Wild Web for a Linux driver and have the
information "NXP NPC300", you will find it.
It's good to keep both informations - preferable put them into the
Kconfig help text?
- Sedat -
^ permalink raw reply
* Re: [PATCH v2 00/12] NFC: nxp-nci: clean up and support new ID
From: Oleg Zhurakivskyy @ 2019-05-14 11:44 UTC (permalink / raw)
To: sedat.dilek, Andy Shevchenko
Cc: Clément Perrochaud, Charles Gorand, linux-nfc, Samuel Ortiz,
linux-wireless
In-Reply-To: <CA+icZUUA8TfU--6b+RwXMf=ui7ww0DK=EurzdMeDUkGvwcJ_rg@mail.gmail.com>
On 5/14/19 11:34 AM, Sedat Dilek wrote:
> Am I correct that "NPC100" is "PN547" and "NPC300" is "PN548"?
Yes, NPC100 is PN547.
Don’t know on NPC300, but a quick web search reveals it’s PN548.
Might it make sense to drop NPC... and to keep just the chip names in Kconfig?
Regards,
Oleg
^ permalink raw reply
* Re: pull request: iwlwifi firmware updates 2019-05-03
From: Josh Boyer @ 2019-05-14 10:54 UTC (permalink / raw)
To: Luca Coelho
Cc: linux-firmware@kernel.org, linux-wireless@vger.kernel.org,
linuxwifi, kyle@infradead.org, ben@decadent.org.uk
In-Reply-To: <76e0ec375091a0b0f16d3cd9b15abc7b1840e89d.camel@coelho.fi>
On Fri, May 3, 2019 at 1:16 PM Luca Coelho <luca@coelho.fi> wrote:
>
> Hi,
>
> This contains some new versions of firmwares for the 9000 series of
> devices and the firmware for a new device, namely 22260.
>
> Please pull or let me know if there are any issues.
>
> --
> Cheers,
> Luca.
>
>
> The following changes since commit 92e17d0dd2437140fab044ae62baf69b35d7d1fa:
>
> amdgpu: update vega20 to the latest 19.10 firmware (2019-05-02 06:24:19 -0400)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git tags/iwlwifi-fw-2019-05-03
>
> for you to fetch changes up to 95a93535b723085ff74845eb8733d01c8ff5c052:
>
> iwlwifi: update -46 firmwares for 22260 and 9000 series (2019-05-03 19:33:53 +0300)
>
> ----------------------------------------------------------------
> updates for -46.ucode for 9260, 9000 and 22260
>
> ----------------------------------------------------------------
> Luca Coelho (3):
> iwlwifi: add -46.ucode firmwares for 9000 series
> iwlwifi: add firmware for 22260 and update 9000 series -46 firmwares
> iwlwifi: update -46 firmwares for 22260 and 9000 series
>
> WHENCE | 9 +++++++++
> iwlwifi-9000-pu-b0-jf-b0-46.ucode | Bin 0 -> 1448644 bytes
> iwlwifi-9260-th-b0-jf-b0-46.ucode | Bin 0 -> 1456088 bytes
> iwlwifi-cc-a0-46.ucode | Bin 0 -> 1044072 bytes
> 4 files changed, 9 insertions(+)
> create mode 100644 iwlwifi-9000-pu-b0-jf-b0-46.ucode
> create mode 100644 iwlwifi-9260-th-b0-jf-b0-46.ucode
> create mode 100644 iwlwifi-cc-a0-46.ucode
Pulled and pushed out.
josh
^ permalink raw reply
* Re: [PATCH] NFC: Orphan the subsystem
From: Johannes Berg @ 2019-05-14 10:03 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: linux-wireless, netdev, Samuel Ortiz
In-Reply-To: <20190514100210.GA9224@smile.fi.intel.com>
On Tue, 2019-05-14 at 13:02 +0300, Andy Shevchenko wrote:
> 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.
>
> Good to know.
>
> But Samuel was active like year ago and he is still at Intel, right?
Not AFAICT and yes. I guess you can reach out to him internally, you're
probably closer to him than I am, org-wise? :)
https://patchwork.kernel.org/project/linux-wireless/list/?delegate=sameo
johannes
^ permalink raw reply
* Re: [PATCH v2 00/12] NFC: nxp-nci: clean up and support new ID
From: Andy Shevchenko @ 2019-05-14 10:03 UTC (permalink / raw)
To: Sedat Dilek
Cc: Clément Perrochaud, Charles Gorand, linux-nfc, Samuel Ortiz,
linux-wireless, Oleg Zhurakivskyy
In-Reply-To: <CA+icZUVn9tHQ3Zug0u2scbvGFfrLag_WYdzs9FCBJsGJ4bhuzw@mail.gmail.com>
On Mon, May 13, 2019 at 09:48:15PM +0200, Sedat Dilek wrote:
> On Mon, May 13, 2019 at 12:44 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> Is it possible to have an info in dmesg log when nxp-nci_i2c kernel
> module is loaded?
We have 'initcall_debug' for such purposes.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] NFC: Orphan the subsystem
From: Andy Shevchenko @ 2019-05-14 10:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, netdev, Samuel Ortiz
In-Reply-To: <20190514090231.32414-1-johannes@sipsolutions.net>
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.
Good to know.
But Samuel was active like year ago and he is still at Intel, right?
Perhaps he can appear last time here to Ack this?
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> ---
> 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
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] mt76: mt7615: do not process rx packets if the device is not initialized
From: Lorenzo Bianconi @ 2019-05-14 9:18 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo
In-Reply-To: <cover.1557825294.git.lorenzo@kernel.org>
Fix following crash that occurs when the driver is processing rx packets
while the device is not initialized yet
$ rmmod mt7615e
[ 67.210261] mt7615e 0000:01:00.0: Message -239 (seq 2) timeout
$ modprobe mt7615e
[ 72.406937] bus=0x1, slot = 0x0, irq=0x16
[ 72.436590] CPU 0 Unable to handle kernel paging request at virtual address 00000004, epc == 8eec4240, ra == 8eec41e0
[ 72.450291] mt7615e 0000:01:00.0: Firmware is not ready for download
[ 72.457724] Oops[#1]:
[ 72.470494] mt7615e: probe of 0000:01:00.0 failed with error -5
[ 72.474829] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.114 #0
[ 72.498702] task: 805769e0 task.stack: 80564000
[ 72.507709] $ 0 : 00000000 00000001 00000000 00000001
[ 72.518106] $ 4 : 8f704dbc 00000000 00000000 8f7046c0
[ 72.528500] $ 8 : 00000024 8045e98c 81210008 11000000
[ 72.538895] $12 : 8fc09f60 00000008 00000019 00000033
[ 72.549289] $16 : 8f704d80 e00000ff 8f0c7800 3c182406
[ 72.559684] $20 : 00000006 8ee615a0 4e000108 00000000
[ 72.570078] $24 : 0000004c 8000cf94
[ 72.580474] $28 : 80564000 8fc09e38 00000001 8eec41e0
[ 72.590869] Hi : 00000001
[ 72.596582] Lo : 00000000
[ 72.602319] epc : 8eec4240 mt7615_mac_fill_rx+0xac/0x494 [mt7615e]
[ 72.614953] ra : 8eec41e0 mt7615_mac_fill_rx+0x4c/0x494 [mt7615e]
[ 72.627580] Status: 11008403 KERNEL EXL IE
[ 72.635899] Cause : 40800008 (ExcCode 02)
[ 72.643860] BadVA : 00000004
[ 72.649573] PrId : 0001992f (MIPS 1004Kc)
[ 72.657704] Modules linked in: mt7615e pppoe ppp_async pppox ppp_generic nf_conntrack_ipv6 mt76x2e mt76x2_common mt76x02_lib mt7603e mt76 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_mu]
[ 72.792717] Process swapper/0 (pid: 0, threadinfo=80564000, task=805769e0, tls=00000000)
[ 72.808799] Stack : 8f0c7800 00000800 8f0c7800 8032b874 00000000 40000000 8f704d80 8ee615a0
[ 72.825428] 8dc88010 00000001 8ee615e0 8eec09b0 8dc88010 8032b914 8f3aee80 80567d20
[ 72.842055] 00000000 8ee615e0 40000000 8f0c7800 00000108 8eec9944 00000000 00000000
[ 72.858682] 80508f10 80510000 00000001 80567d20 8ee615a0 00000000 00000000 8ee61c00
[ 72.875308] 8ee61c40 00000040 80610000 80580000 00000000 8ee615dc 8ee61a68 00000001
[ 72.891936] ...
[ 72.896793] Call Trace:
[ 72.901649] [<8eec4240>] mt7615_mac_fill_rx+0xac/0x494 [mt7615e]
[ 72.913602] [<8eec09b0>] mt7615_queue_rx_skb+0xe4/0x12c [mt7615e]
[ 72.925734] [<8eec9944>] mt76_dma_cleanup+0x390/0x42c [mt76]
[ 72.936988] Code: ae020018 8ea20004 24030001 <94420004> a602002a 8ea20004 90420000 14430003 a2020034
[ 72.956390]
[ 72.959676] ---[ end trace f176967739edb19f ]---
Fixes: 04b8e65922f6 ("mt76: add mac80211 driver for MT7615 PCIe-based chipsets")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt7615/mac.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
index 1d6ebea17132..1547bce561d3 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
@@ -73,6 +73,9 @@ int mt7615_mac_fill_rx(struct mt7615_dev *dev, struct sk_buff *skb)
bool unicast, remove_pad, insert_ccmp_hdr = false;
int i, idx;
+ if (!test_bit(MT76_STATE_RUNNING, &dev->mt76.state))
+ return -EINVAL;
+
memset(status, 0, sizeof(*status));
unicast = (rxd1 & MT_RXD1_NORMAL_ADDR_TYPE) == MT_RXD1_NORMAL_U2M;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2] mac80211: remove warning message
From: Johannes Berg @ 2019-05-14 9:12 UTC (permalink / raw)
To: Yibo Zhao; +Cc: linux-wireless, ath10k, Zhi Chen
In-Reply-To: <ccb48284f0d96e72f4c041e12c943f0a@codeaurora.org>
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.
> > >
> >
> > Err, what was the point in sending v2 without any changes?
> >
> > johannes
>
> Hi Johannes,
>
> 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.
Oops, I didn't pay attention to the - code.
I guess changing it to WARN_ON_ONCE() makes sense, 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.
johannes
^ permalink raw reply
* Re: [PATCH v2] mac80211: remove warning message
From: Yibo Zhao @ 2019-05-14 9:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, ath10k, Zhi Chen
In-Reply-To: <7c92f5cf51eaec1d5449698d90f5b6c5ca6c2bea.camel@sipsolutions.net>
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.
>>
> Err, what was the point in sending v2 without any changes?
>
> johannes
Hi Johannes,
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.
Sorry for the confusing.
--
Yibo
^ permalink raw reply
* Re: [PATCH v2] mac80211: remove warning message
From: Johannes Berg @ 2019-05-14 9:05 UTC (permalink / raw)
To: Yibo Zhao, linux-wireless; +Cc: ath10k, Zhi Chen
In-Reply-To: <1557824507-17668-1-git-send-email-yiboz@codeaurora.org>
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.
>
Err, what was the point in sending v2 without any changes?
johannes
^ permalink raw reply
* [PATCH] NFC: Orphan the subsystem
From: Johannes Berg @ 2019-05-14 9:02 UTC (permalink / raw)
To: linux-wireless, netdev; +Cc: Samuel Ortiz
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>
---
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 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