Re: [PATCH 1/3] ath9k: remove stray backslash in Makefile
On Mon, 27 Nov 2017 18:56:21 +0100, Matthias Schiffer wrote: > Signed-off-by: Matthias Schiffer> --- > drivers/net/wireless/ath/ath9k/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/ath/ath9k/Makefile > b/drivers/net/wireless/ath/ath9k/Makefile > index 36a40ffdce15..90e4a341076c 100644 > --- a/drivers/net/wireless/ath/ath9k/Makefile > +++ b/drivers/net/wireless/ath/ath9k/Makefile > @@ -59,7 +59,7 @@ obj-$(CONFIG_ATH9K_HW) += ath9k_hw.o > obj-$(CONFIG_ATH9K_COMMON) += ath9k_common.o > ath9k_common-y:= common.o \ > common-init.o \ > - common-beacon.o \ > + common-beacon.o > It's not necessarily stray, there is nothing on the next line so it's OK, and if you add \ at the end of all lines, you don't have to touch the last line every time you add/remove something. Sort of like putting a , after last enum value. Just my $.02, not that I mind either way :) > ath9k_common-$(CONFIG_ATH9K_COMMON_DEBUG) += common-debug.o \ >common-spectral.o
[PATCH v2] drivers: bcma: driver_pcie2.c: Comment format correction & moving trailing */ to a separate line as per checkpatch
This patch fixes the checkpatch.pl warning: WARNING: Block comments use * on subsequent lines + /* TODO: + si_core_wrapperreg(pcie2, 3, 0x60, 0x8080, 0); */ WARNING: Block comments use a trailing */ on a separate line + si_core_wrapperreg(pcie2, 3, 0x60, 0x8080, 0); */ total: 0 errors, 2 warnings, 200 lines checked Signed-off-by: Ashish Kalra--- changes from v1 (https://lkml.org/lkml/2017/11/26/85) v2: Improved commit message as per review from Morgan Freeman drivers/bcma/driver_pcie2.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/bcma/driver_pcie2.c b/drivers/bcma/driver_pcie2.c index b1a6e327cb23..cf889fc62ac7 100644 --- a/drivers/bcma/driver_pcie2.c +++ b/drivers/bcma/driver_pcie2.c @@ -83,7 +83,8 @@ static void bcma_core_pcie2_hw_ltr_war(struct bcma_drv_pcie2 *pcie2) bcma_core_pcie2_set_ltr_vals(pcie2); /* TODO: - si_core_wrapperreg(pcie2, 3, 0x60, 0x8080, 0); */ +*si_core_wrapperreg(pcie2, 3, 0x60, 0x8080, 0); +*/ /* enable the LTR */ devstsctr2 |= PCIE2_CAP_DEVSTSCTRL2_LTRENAB; -- 2.14.1
Re: [PATCH v1] brcmfmac: Avoid build error with make W=1
On 23-11-17 16:57, Andy Shevchenko wrote: When I run make W=1 on gcc (Debian 7.2.0-16) 7.2.0 I got an error for the first run, all next ones are okay. CC [M] drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.o drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2078: error: Cannot parse struct or union! scripts/Makefile.build:310: recipe for target 'drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.o' failed Seems like something happened with W=1 and wrong kernel doc format. As a quick fix remove dubious /** in the code. Acked-by: Arend van SprielSigned-off-by: Andy Shevchenko --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: [PATCH] ath6kl: remove redundant variable ies_len
On Sat, Nov 25, 2017 at 9:38 PM, Kenneth Luwrote: > To get rid of W=1 warning: variable ‘ies_len’ set but not used. > Variable ies_len is being assigned but never read. > > Signed-off-by: Kenneth Lu > --- > drivers/net/wireless/ath/ath6kl/cfg80211.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c > b/drivers/net/wireless/ath/ath6kl/cfg80211.c > index b53eb2b..2ba8cf3 100644 > --- a/drivers/net/wireless/ath/ath6kl/cfg80211.c > +++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c > @@ -2766,7 +2766,6 @@ static int ath6kl_start_ap(struct wiphy *wiphy, struct > net_device *dev, > struct ieee80211_mgmt *mgmt; > bool hidden = false; > u8 *ies; > - int ies_len; > struct wmi_connect_cmd p; > int res; > int i, ret; > @@ -2804,7 +2803,6 @@ static int ath6kl_start_ap(struct wiphy *wiphy, struct > net_device *dev, > ies = mgmt->u.beacon.variable; > if (ies > info->beacon.head + info->beacon.head_len) > return -EINVAL; > - ies_len = info->beacon.head + info->beacon.head_len - ies; > > if (info->ssid == NULL) > return -EINVAL; Oddly, ies_len was never even used in the original patch that added it. Probably used in some debugging code that was stripped before submitting. Seems safe to kill it. Reviewed-by: Steve deRosier - Steve
RE: [RFC] cfg80211: Implement Multiple BSSID capability in scanning
> Is a new version of this patch hinging only on this? We'd love to have a > fixed- > up one :-) The new version covers the use cases mentioned by Jouni as the OUIs of the vendor commands has the format of OUI + type + subtype. For other format of vendor commands, they will be treated as different vendor commands and are added in the new IE as well. Jouni, could you chime in to explain your view on this? Thanks, Peng
[PATCH 1/3] ath9k: remove stray backslash in Makefile
Signed-off-by: Matthias Schiffer--- drivers/net/wireless/ath/ath9k/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath9k/Makefile b/drivers/net/wireless/ath/ath9k/Makefile index 36a40ffdce15..90e4a341076c 100644 --- a/drivers/net/wireless/ath/ath9k/Makefile +++ b/drivers/net/wireless/ath/ath9k/Makefile @@ -59,7 +59,7 @@ obj-$(CONFIG_ATH9K_HW) += ath9k_hw.o obj-$(CONFIG_ATH9K_COMMON) += ath9k_common.o ath9k_common-y:= common.o \ common-init.o \ - common-beacon.o \ + common-beacon.o ath9k_common-$(CONFIG_ATH9K_COMMON_DEBUG) += common-debug.o \ common-spectral.o -- 2.15.0
[PATCH 3/3] ath10k: move spectral scan support under a separate config symbol
At the moment, spectral scan support, and with it RELAY, is always enabled with ATH10K_DEBUGFS. Spectral scan support is currently the only user of RELAY in ath10k, and it unconditionally reserves a relay channel. Having debugfs support in ath10k is often useful even on very small embedded routers, where we'd rather like to avoid the code size and RAM usage of the relay support. While ath10k-based devices usually have more resources than ath9k-based ones, it makes sense to keep the configuration symmetric to ath9k, so the same base kernel without RELAY can be used for both ath9k and ath10k hardware. Signed-off-by: Matthias Schiffer--- checkpatch.pl wants me to write a more meaningful description for ATH10K_SPECTRAL, but I don't actually know enough about the spectral scan feature to do so... drivers/net/wireless/ath/ath10k/Kconfig| 9 - drivers/net/wireless/ath/ath10k/Makefile | 2 +- drivers/net/wireless/ath/ath10k/spectral.h | 4 ++-- 3 files changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/Kconfig b/drivers/net/wireless/ath/ath10k/Kconfig index 87f56d0e17a6..deb5ae21a559 100644 --- a/drivers/net/wireless/ath/ath10k/Kconfig +++ b/drivers/net/wireless/ath/ath10k/Kconfig @@ -47,12 +47,19 @@ config ATH10K_DEBUG config ATH10K_DEBUGFS bool "Atheros ath10k debugfs support" depends on ATH10K && DEBUG_FS - select RELAY ---help--- Enabled debugfs support If unsure, say Y to make it easier to debug problems. +config ATH10K_SPECTRAL + bool "Atheros ath10k spectral scan support" + depends on ATH10K_DEBUGFS + select RELAY + default n + ---help--- + Say Y to enable access to the FFT/spectral data via debugfs. + config ATH10K_TRACING bool "Atheros ath10k tracing support" depends on ATH10K diff --git a/drivers/net/wireless/ath/ath10k/Makefile b/drivers/net/wireless/ath/ath10k/Makefile index 899b9b79f4ce..af8f11970a08 100644 --- a/drivers/net/wireless/ath/ath10k/Makefile +++ b/drivers/net/wireless/ath/ath10k/Makefile @@ -14,7 +14,7 @@ ath10k_core-y += mac.o \ p2p.o \ swap.o -ath10k_core-$(CONFIG_ATH10K_DEBUGFS) += spectral.o +ath10k_core-$(CONFIG_ATH10K_SPECTRAL) += spectral.o ath10k_core-$(CONFIG_NL80211_TESTMODE) += testmode.o ath10k_core-$(CONFIG_ATH10K_TRACING) += trace.o ath10k_core-$(CONFIG_THERMAL) += thermal.o diff --git a/drivers/net/wireless/ath/ath10k/spectral.h b/drivers/net/wireless/ath/ath10k/spectral.h index 89b0ad769d4f..b2a2e8ae04b8 100644 --- a/drivers/net/wireless/ath/ath10k/spectral.h +++ b/drivers/net/wireless/ath/ath10k/spectral.h @@ -44,7 +44,7 @@ enum ath10k_spectral_mode { SPECTRAL_MANUAL, }; -#ifdef CONFIG_ATH10K_DEBUGFS +#ifdef CONFIG_ATH10K_SPECTRAL int ath10k_spectral_process_fft(struct ath10k *ar, struct wmi_phyerr_ev_arg *phyerr, @@ -85,6 +85,6 @@ static inline void ath10k_spectral_destroy(struct ath10k *ar) { } -#endif /* CONFIG_ATH10K_DEBUGFS */ +#endif /* CONFIG_ATH10K_SPECTRAL */ #endif /* SPECTRAL_H */ -- 2.15.0
[PATCH 2/3] ath9k: move spectral scan support under a separate config symbol
At the moment, spectral scan support, and with it RELAY, is always enabled with ATH9K[_HTC]_DEBUGFS. Spectral scan support is currently the only user of RELAY in ath9k, and it unconditionally reserves a relay channel. Having debugfs support in ath9k is often useful even on very small embedded routers, where we'd rather like to avoid the code size and RAM usage of the relay support. Signed-off-by: Matthias Schiffer--- drivers/net/wireless/ath/ath9k/Kconfig | 14 ++ drivers/net/wireless/ath/ath9k/Makefile | 4 ++-- drivers/net/wireless/ath/ath9k/common-spectral.h | 4 ++-- 3 files changed, 14 insertions(+), 8 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig index 783a38f1a626..1f3523019509 100644 --- a/drivers/net/wireless/ath/ath9k/Kconfig +++ b/drivers/net/wireless/ath/ath9k/Kconfig @@ -61,13 +61,12 @@ config ATH9K_DEBUGFS depends on ATH9K && DEBUG_FS select MAC80211_DEBUGFS select ATH9K_COMMON_DEBUG - select RELAY ---help--- Say Y, if you need access to ath9k's statistics for interrupts, rate control, etc. - Also required for changing debug message flags at run time. - As well as access to the FFT/spectral data and TX99. + Also required for changing debug message flags at run time and for + TX99. config ATH9K_STATION_STATISTICS bool "Detailed station statistics" @@ -177,7 +176,6 @@ config ATH9K_HTC_DEBUGFS bool "Atheros ath9k_htc debugging" depends on ATH9K_HTC && DEBUG_FS select ATH9K_COMMON_DEBUG - select RELAY ---help--- Say Y, if you need access to ath9k_htc's statistics. As well as access to the FFT/spectral data. @@ -192,3 +190,11 @@ config ATH9K_HWRNG Say Y, feeds the entropy directly from the WiFi driver to the input pool. + +config ATH9K_COMMON_SPECTRAL + bool "Atheros ath9k/ath9k_htc spectral scan support" + depends on ATH9K_DEBUGFS || ATH9K_HTC_DEBUGFS + select RELAY + default n + ---help--- + Say Y to enable access to the FFT/spectral data via debugfs. diff --git a/drivers/net/wireless/ath/ath9k/Makefile b/drivers/net/wireless/ath/ath9k/Makefile index 90e4a341076c..80197101eda7 100644 --- a/drivers/net/wireless/ath/ath9k/Makefile +++ b/drivers/net/wireless/ath/ath9k/Makefile @@ -61,8 +61,8 @@ ath9k_common-y:= common.o \ common-init.o \ common-beacon.o -ath9k_common-$(CONFIG_ATH9K_COMMON_DEBUG) += common-debug.o \ -common-spectral.o +ath9k_common-$(CONFIG_ATH9K_COMMON_DEBUG) += common-debug.o +ath9k_common-$(CONFIG_ATH9K_COMMON_SPECTRAL) += common-spectral.o ath9k_htc-y += htc_hst.o \ hif_usb.o \ diff --git a/drivers/net/wireless/ath/ath9k/common-spectral.h b/drivers/net/wireless/ath/ath9k/common-spectral.h index 5d1a51d83aa6..303ab470ce34 100644 --- a/drivers/net/wireless/ath/ath9k/common-spectral.h +++ b/drivers/net/wireless/ath/ath9k/common-spectral.h @@ -151,7 +151,7 @@ static inline u8 spectral_bitmap_weight(u8 *bins) return bins[0] & 0x3f; } -#ifdef CONFIG_ATH9K_COMMON_DEBUG +#ifdef CONFIG_ATH9K_COMMON_SPECTRAL void ath9k_cmn_spectral_init_debug(struct ath_spec_scan_priv *spec_priv, struct dentry *debugfs_phy); void ath9k_cmn_spectral_deinit_debug(struct ath_spec_scan_priv *spec_priv); @@ -183,6 +183,6 @@ static inline int ath_cmn_process_fft(struct ath_spec_scan_priv *spec_priv, { return 0; } -#endif /* CONFIG_ATH9K_COMMON_DEBUG */ +#endif /* CONFIG_ATH9K_COMMON_SPECTRAL */ #endif /* SPECTRAL_H */ -- 2.15.0
Re: [PATCH for-4.15] brcmfmac: change driver unbind order of the sdio function devices
Arend van Sprielwrites: > In the function brcmf_sdio_firmware_callback() the driver is > unbound from the sdio function devices in the error path. > However, the order in which it is done resulted in a use-after-free > issue (see brcmf_ops_sdio_remove() in bcmsdh.c). Hence change > the order and first unbind sdio function #2 device and then > unbind sdio function #1 device. > > Cc: sta...@vger.kernel.org # v4.12.x > Fixes: 7a51461fc2da ("brcmfmac: unbind all devices upon failure in firmware > callback") > Reported-by: Stefan Wahren > Reviewed-by: Hante Meuleman > Reviewed-by: Pieter-Paul Giesberts > Reviewed-by: Franky Lin > Signed-off-by: Arend van Spriel I'll queue this for v4.15. -- Kalle Valo
Re: pull-request: mac80211 2017-11-27
From: Johannes BergDate: Mon, 27 Nov 2017 11:32:56 +0100 > Here are a few more fixes, one of which fixes the crash Florian > reported which I think is the same that zero-day reported. > > Please pull and let me know if there's any problem. Pulled, thanks Johannes.
Re: Setting TX power on a monitoring interface
On Mon, 27 Nov 2017 12:43:13 +0100 Johannes Bergwrote: > > What would be the correct way of fixing it? Maybe I can provide a patch. > > That's a really good question :-) > > I think if the driver has WANT_MONITOR_VIF, then we can pass that > through and let the driver sort it out. > > But if not, we probably just have to reject the configuration? With passing through you mean calling bss_info_changed on the driver for the monitor interface? Are monitor interfaces allowed to exist when WANT_MONITOR_VIF is not set? I ask, whether I would have to check sdata->vif.type == NL80211_IFTYPE_MONITOR _and_ also ieee80211_hw_check(>hw, WANT_MONITOR_VIF) ? Regards Peter pgpjak_9TtR1A.pgp Description: OpenPGP digital signature
Re: Build regressions/improvements in v4.15-rc1
Geert Uytterhoevenwrites: > On Mon, Nov 27, 2017 at 11:01 AM, Geert Uytterhoeven > wrote: >> Below is the list of build error/warning regressions/improvements in >> v4.15-rc1[1] compared to v4.14[2]. >> >> Summarized: >> - build errors: +2/-5 > >> [1] >> http://kisskb.ellerman.id.au/kisskb/head/4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323/ >> (all 271 configs) >> [2] >> http://kisskb.ellerman.id.au/kisskb/head/bebc6082da0a9f5d47a1ea2edc099bf671058bd4/ >> (270 out of 271 configs) > >> 2 error regressions: >> + /home/kisskb/slave/src/drivers/gpu/drm/i915/intel_csr.c: error: 'si' may >> be used uninitialized in this function [-Werror=uninitialized]: => 204:3 > > x86_64-randconfig > >> + /home/kisskb/slave/src/include/linux/bcma/bcma_driver_pci.h: error: >> field 'pci_controller' has incomplete type: => 218:24 The last "real" change to that file was from 2015 so I guess something else changed to trigger this? But anyway, I guess the reason is missing struct pci_controller forward declaration? Or missing include
Re: [RFC] cfg80211: Implement Multiple BSSID capability in scanning
Hi, > As you pointed out the use cases for having vendor elements in MBSSID > subelements, what is > your suggestion to identify and process the vendor elements? Is a new version of this patch hinging only on this? We'd love to have a fixed-up one :-) johannes
Re: [RFC PATCH 2/2] nl80211: implement beacon change notifier
On Wed, 2017-11-15 at 18:35 +0300, Sergey Matyukevich wrote: > In our case, we are experimenting with applications running along with > hostapd and enabling band steering and client roaming functionality. > As I mentioned, various approaches are being examined, including > both pure nl80211-based approach as well as adding direct hooks > to hostapd. To be honest, I'm torn on this. On the one hand, I think it's fairly reasonable functionality, but on the other hand I'm not sure we should encourage such separate approaches - it seems to me that will lead to a lot of fragmentation and much harder debuggability for upstream where these things get used. It's also a bunch of code we have to maintain, for nothing that seems of use to the community - since it's the sort of flexibility explicitly designed for non-public code (otherwise it could just be part of hostapd; actually it could even if it were non-public, at least in theory, unless you're planning it as a value-add thing to go with an open source hostapd ...). So while I don't want to stop you entirely in your tracks with this, I'd really prefer you explore other options regarding where to put your client steering functionality, perhaps even working on hostapd. johannes
Re: What would it take to get WDS working with channel contexts?
On Fri, 2017-11-17 at 08:46 -0800, Ben Greear wrote: > It looks like my options are to hack the mac80211 stack to be minimally > functional with WDS and channel-contexts, or to hack ath10k driver to > disable chan-tx in order to try to fix the ath10k firmware WDS issues. > > I'd guess the former is of slightly more use to society. Do you have > any quick hacks to allow mac80211 to work with chantx and WDS, even > if you wouldn't want them upstream? No, I don't have anything like that, sorry. johannes
[PATCH] ath10k: use 64-bit crash dump timestamps
The dump format uses 64-bit timestamps already, but calling getnstimeofday() only returns a 32-bit number on 32-bit architectures, so that will overflow in y2038. This changes it to use ktime_get_real_ts64() instead. Signed-off-by: Arnd Bergmann--- drivers/net/wireless/ath/ath10k/core.h | 2 +- drivers/net/wireless/ath/ath10k/debug.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h index 643041ef3271..dd3c6c63aae1 100644 --- a/drivers/net/wireless/ath/ath10k/core.h +++ b/drivers/net/wireless/ath/ath10k/core.h @@ -463,7 +463,7 @@ struct ath10k_fw_crash_data { bool crashed_since_read; guid_t guid; - struct timespec timestamp; + struct timespec64 timestamp; __le32 registers[REG_DUMP_COUNT_QCA988X]; struct ath10k_ce_crash_data ce_crash_data[CE_COUNT_MAX]; }; diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c index df514507d3f1..66498e3c0f91 100644 --- a/drivers/net/wireless/ath/ath10k/debug.c +++ b/drivers/net/wireless/ath/ath10k/debug.c @@ -720,7 +720,7 @@ ath10k_debug_get_new_fw_crash_data(struct ath10k *ar) crash_data->crashed_since_read = true; guid_gen(_data->guid); - getnstimeofday(_data->timestamp); + ktime_get_real_ts64(_data->timestamp); return crash_data; } -- 2.9.0
[PATCH] wlcore: use boottime for fw time sync
Using getnstimeofday()/timespec_to_ns() causes an overflow on 32-bit architectures in 2038, and may suffer from time jumps due to settimeofday() or leap seconds. I don't see a reason why this needs to be UTC, so either monotonic or boot time would be better here. Assuming that the fw time keeps running during suspend, boottime is better than monotonic, and ktime_get_boot_ns() will also save the additional conversion to nanoseconds. Signed-off-by: Arnd Bergmann--- drivers/net/wireless/ti/wlcore/main.c | 4 +--- drivers/net/wireless/ti/wlcore/tx.c | 4 +--- 2 files changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c index d47921a84509..946a7124b09e 100644 --- a/drivers/net/wireless/ti/wlcore/main.c +++ b/drivers/net/wireless/ti/wlcore/main.c @@ -388,7 +388,6 @@ static void wl12xx_irq_update_links_status(struct wl1271 *wl, static int wlcore_fw_status(struct wl1271 *wl, struct wl_fw_status *status) { struct wl12xx_vif *wlvif; - struct timespec ts; u32 old_tx_blk_count = wl->tx_blocks_available; int avail, freed_blocks; int i; @@ -485,8 +484,7 @@ static int wlcore_fw_status(struct wl1271 *wl, struct wl_fw_status *status) } /* update the host-chipset time offset */ - getnstimeofday(); - wl->time_offset = (timespec_to_ns() >> 10) - + wl->time_offset = (ktime_get_boot_ns() >> 10) - (s64)(status->fw_localtime); wl->fw_fast_lnk_map = status->link_fast_bitmap; diff --git a/drivers/net/wireless/ti/wlcore/tx.c b/drivers/net/wireless/ti/wlcore/tx.c index a3f5e9ca492a..00e9b4624dcf 100644 --- a/drivers/net/wireless/ti/wlcore/tx.c +++ b/drivers/net/wireless/ti/wlcore/tx.c @@ -264,7 +264,6 @@ static void wl1271_tx_fill_hdr(struct wl1271 *wl, struct wl12xx_vif *wlvif, struct sk_buff *skb, u32 extra, struct ieee80211_tx_info *control, u8 hlid) { - struct timespec ts; struct wl1271_tx_hw_descr *desc; int ac, rate_idx; s64 hosttime; @@ -287,8 +286,7 @@ static void wl1271_tx_fill_hdr(struct wl1271 *wl, struct wl12xx_vif *wlvif, } /* configure packet life time */ - getnstimeofday(); - hosttime = (timespec_to_ns() >> 10); + hosttime = (ktime_get_boot_ns() >> 10); desc->start_time = cpu_to_le32(hosttime - wl->time_offset); is_dummy = wl12xx_is_dummy_packet(wl, skb); -- 2.9.0
Re: Setting TX power on a monitoring interface
On Mon, 2017-11-20 at 17:34 +0100, Peter Große wrote: > Hi everyone. > > The iw tool allows to set TX power settings on network interfaces. > > If I try to set the TX power level on a _monitor_ interface, I get > a kernel warning: > > [ cut here ] > WARNING: CPU: 0 PID: 2193 at net/mac80211/driver-ops.h:167 > ieee80211_bss_info_change_notify+0x111/0x190 Modules linked in: uvcvideo > videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core > rndis_host cdc_ether usbnet mii tp_smapi(O) thinkpad_ec(O) ohci_hcd vboxpci(O) > vboxnetadp(O) vboxnetflt(O) v boxdrv(O) x86_pkg_temp_thermal kvm_intel kvm > irqbypass iwldvm iwlwifi ehci_pci ehci_hcd tpm_tis tpm_tis_core tpm CPU: 0 > PID: 2193 Comm: iw Tainted: G O4.12.12-gentoo #2 task: > 880186fd5cc0 task.stack: c90001b54000 RIP: > 0010:ieee80211_bss_info_change_notify+0x111/0x190 RSP: 0018:c90001b57a10 > EFLAGS: 00010246 RAX: 0006 RBX: 8801052ce840 RCX: > 0064 RDX: fffc RSI: 0004 RDI: > 8801052ce840 RBP: c90001b57a38 R08: 0062 R09: > R10: 8802144b5000 R11: 880049dc4614 R12: > 0004 R13: 0064 R14: 8802105f0760 R15: > c90001b57b48 FS: 7f92644b4580() GS:88021e20() > knlGS: CS: 0010 DS: ES: CR0: 80050033 > CR2: 7f9263c109f0 CR3: 0001df85 CR4: 000406f0 > Call Trace: > ieee80211_recalc_txpower+0x33/0x40 > ieee80211_set_tx_power+0x40/0x180 > nl80211_set_wiphy+0x32e/0x950 > > Steps to reproduce: > > iw dev wlan0 interface add mon0 type monitor > ip link set dev mon0 up > iw dev mon0 set txpower fixed 100 > > Is that a bug to be fixed? Yeah, it's a bug. > What would be the correct way of fixing it? Maybe I can provide a patch. That's a really good question :-) I think if the driver has WANT_MONITOR_VIF, then we can pass that through and let the driver sort it out. But if not, we probably just have to reject the configuration? johannes
pull-request: mac80211 2017-11-27
Hi Dave, Here are a few more fixes, one of which fixes the crash Florian reported which I think is the same that zero-day reported. Please pull and let me know if there's any problem. Thanks, johannes The following changes since commit a13e8d418f3cb9d0b4efa6e744b8b23c0e3cdfe8: Merge tag 'mac80211-for-davem-2017-11-20' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 (2017-11-21 20:30:57 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2017-11-27 for you to fetch changes up to 72e2c3438ba3bd2ed640b6b5ea9e58993dd9ab7f: mac80211: tear down RX aggregations first (2017-11-27 11:24:59 +0100) Four fixes: * CRYPTO_SHA256 is needed for regdb validation * mac80211: mesh path metric was wrong in some frames * mac80211: use QoS null-data packets on QoS connections * mac80211: tear down RX aggregation sessions first to drop fewer packets in HW restart scenarios Chun-Yeow Yeoh (1): mac80211: fix the update of path metric for RANN frame Johannes Berg (2): cfg80211: select CRYPTO_SHA256 if needed mac80211: use QoS NDP for AP probing Sara Sharon (1): mac80211: tear down RX aggregations first drivers/net/wireless/ath/ath9k/channel.c | 2 +- drivers/net/wireless/st/cw1200/sta.c | 4 ++-- drivers/net/wireless/ti/wl1251/main.c| 2 +- drivers/net/wireless/ti/wlcore/cmd.c | 5 +++-- include/net/mac80211.h | 8 +++- net/mac80211/ht.c| 4 +++- net/mac80211/mesh_hwmp.c | 15 +-- net/mac80211/mlme.c | 2 +- net/mac80211/tx.c| 29 +++-- net/wireless/Kconfig | 7 +++ 10 files changed, 61 insertions(+), 17 deletions(-)
Re: Build regressions/improvements in v4.15-rc1
On Mon, Nov 27, 2017 at 11:01 AM, Geert Uytterhoevenwrote: > Below is the list of build error/warning regressions/improvements in > v4.15-rc1[1] compared to v4.14[2]. > > Summarized: > - build errors: +2/-5 > [1] > http://kisskb.ellerman.id.au/kisskb/head/4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323/ > (all 271 configs) > [2] > http://kisskb.ellerman.id.au/kisskb/head/bebc6082da0a9f5d47a1ea2edc099bf671058bd4/ > (270 out of 271 configs) > 2 error regressions: > + /home/kisskb/slave/src/drivers/gpu/drm/i915/intel_csr.c: error: 'si' may > be used uninitialized in this function [-Werror=uninitialized]: => 204:3 x86_64-randconfig > + /home/kisskb/slave/src/include/linux/bcma/bcma_driver_pci.h: error: field > 'pci_controller' has incomplete type: => 218:24 mips-allmodconfig Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds