Re: [PATCH 1/3] ath9k: remove stray backslash in Makefile

[Jakub Kicinski]

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

[Ashish Kalra]

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

[Arend van Spriel]

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 Spriel 

Signed-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

[Steve deRosier]

On Sat, Nov 25, 2017 at 9:38 PM, Kenneth Lu  wrote:
> 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

[Peng Xu]

> 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

[Matthias Schiffer]

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

[Matthias Schiffer]

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

[Matthias Schiffer]

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

[Kalle Valo]

Arend van Spriel  writes:

> 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

[David Miller]

From: Johannes Berg 
Date: 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

[Peter Große]

On Mon, 27 Nov 2017 12:43:13 +0100
Johannes Berg  wrote:

> > 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

[Kalle Valo]

Geert Uytterhoeven  writes:

> 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

[Johannes Berg]

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

[Johannes Berg]

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?

[Johannes Berg]

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

[Arnd Bergmann]

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

[Arnd Bergmann]

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

[Johannes Berg]

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

[Johannes Berg]

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

[Geert Uytterhoeven]

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

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