* Re: [PATCH] iwlwifi: work around clang -Wuninitialized warning
From: Arnd Bergmann @ 2019-03-23 11:28 UTC (permalink / raw)
To: Luca Coelho
Cc: Johannes Berg, clang-built-linux, Nick Desaulniers,
Nathan Chancellor, Emmanuel Grumbach, Intel Linux Wireless,
Kalle Valo, David S. Miller, Sara Sharon, Avraham Stern,
linux-wireless, Networking, Linux Kernel Mailing List
In-Reply-To: <a92bc0994d5f3fa5da5da471d0ccd01f8cefeee5.camel@coelho.fi>
On Sat, Mar 23, 2019 at 7:11 AM Luca Coelho <luca@coelho.fi> wrote:
>
> On Fri, 2019-03-22 at 15:13 +0100, Arnd Bergmann wrote:
> > Clang incorrectly warns about an uninitialized variable:
> >
> >
> > This cannot happen because the if/else if/else if block always
> > has one code path that is entered. However, we can simply
> > rearrange the code to let clang see this as well.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
>
> Thanks for the patch, Arnd! But I have already queued up an equivalent
> patch for v5.2 (should probably reach linux-next by the end of next
> week or so):
>
> https://patchwork.kernel.org/patch/10844025/
Thanks, and sorry for the duplicate. I forgot to check for the
patches that Nathan had already done when I started sending
out my own series on the same issues.
Arnd
^ permalink raw reply
* [PATCH] iw: print 4ADDR attribute when dumping interface
From: Antonio Quartulli @ 2019-03-23 9:39 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Antonio Quartulli
Print the value of the 4ADDR attribute when dumping the interface
status.
Signed-off-by: Antonio Quartulli <a@unstable.cc>
---
This patch was sleeping in my local repo for a while .. maybe it is useful to
other people too.
Cheers,
interface.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/interface.c b/interface.c
index 712bbdc..678955d 100644
--- a/interface.c
+++ b/interface.c
@@ -447,6 +447,11 @@ static int print_iface_handler(struct nl_msg *msg, void *arg)
printf("%s\tmulticast TXQ:%s\n", indent, buf);
}
+ if (tb_msg[NL80211_ATTR_4ADDR]) {
+ uint8_t use_4addr = nla_get_u8(tb_msg[NL80211_ATTR_4ADDR]);
+ printf("%s\t4addr: %d\n", indent, use_4addr);
+ }
+
return NL_SKIP;
}
--
2.21.0
^ permalink raw reply related
* Re: [PATCH] ath10k: reset chip after supported check
From: Arend Van Spriel @ 2019-03-23 7:20 UTC (permalink / raw)
To: Christian Lamparter, Tomislav Požega
Cc: linux-wireless, openwrt-devel, Kalle Valo, Michał Kazior
In-Reply-To: <fe853ec8-0dca-d931-8632-fbe4df5cfaf8@broadcom.com>
* resending with corrected email address from Kalle
--------------------------------------------------------------------
+ Michał
On 3/22/2019 8:25 PM, Christian Lamparter wrote:
> On Friday, March 22, 2019 7:58:40 PM CET Tomislav Požega wrote:
>> When chip reset is done before the chip is checked if supported
>> there will be crash. Previous behaviour caused bootloops on
>> Archer C7 v1 units, this patch allows clean device boot without
>> excluding ath10k driver.
>>
> You need
>
> Fixes: 1a7fecb766c8 ("ath10k: reset chip before reading chip_id in
probe")
>
> too
Looking at the commit subject makes me suspicious whether this is a
proper fix.
>> Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com>
>> ---
>> drivers/net/wireless/ath/ath10k/pci.c | 12 ++++++------
>> 1 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
>> index e24403c..ec681da 100644
>> --- a/drivers/net/wireless/ath/ath10k/pci.c
>> +++ b/drivers/net/wireless/ath/ath10k/pci.c
>> @@ -3619,12 +3619,6 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
>> goto err_deinit_irq;
>> }
>>
>> - ret = ath10k_pci_chip_reset(ar);
>> - if (ret) {
>> - ath10k_err(ar, "failed to reset chip: %d\n", ret);
>> - goto err_free_irq;
>> - }
>> -
>> bus_params.dev_type = ATH10K_DEV_TYPE_LL;
>> bus_params.link_can_suspend = true;
>> bus_params.chip_id = ath10k_pci_soc_read32(ar, SOC_CHIP_ID_ADDRESS);
It seems to me the chip reset was done explicitly *before* reading the
chipid for a reason.
"""
ath10k: reset chip before reading chip_id in probe
There are some very rare cases with some hardware
configuration that the device doesn't init quickly
enough in which case reading chip_id yielded 0.
This caused driver to subsequently fail to setup
the device.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
"""
Might be the ath10k_pci_chip_reset() function needs to be modified to
work properly for Archer C7 v1 units.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] ath10k: reset chip after supported check
From: Arend Van Spriel @ 2019-03-23 7:16 UTC (permalink / raw)
To: Christian Lamparter, Tomislav Požega
Cc: linux-wireless, openwrt-devel, kalle, Michał Kazior
In-Reply-To: <3337086.qEUs9xMCTV@debian64>
+ Michał
On 3/22/2019 8:25 PM, Christian Lamparter wrote:
> On Friday, March 22, 2019 7:58:40 PM CET Tomislav Požega wrote:
>> When chip reset is done before the chip is checked if supported
>> there will be crash. Previous behaviour caused bootloops on
>> Archer C7 v1 units, this patch allows clean device boot without
>> excluding ath10k driver.
>>
> You need
>
> Fixes: 1a7fecb766c8 ("ath10k: reset chip before reading chip_id in probe")
>
> too
Looking at the commit subject makes me suspicious whether this is a
proper fix.
>> Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com>
>> ---
>> drivers/net/wireless/ath/ath10k/pci.c | 12 ++++++------
>> 1 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
>> index e24403c..ec681da 100644
>> --- a/drivers/net/wireless/ath/ath10k/pci.c
>> +++ b/drivers/net/wireless/ath/ath10k/pci.c
>> @@ -3619,12 +3619,6 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
>> goto err_deinit_irq;
>> }
>>
>> - ret = ath10k_pci_chip_reset(ar);
>> - if (ret) {
>> - ath10k_err(ar, "failed to reset chip: %d\n", ret);
>> - goto err_free_irq;
>> - }
>> -
>> bus_params.dev_type = ATH10K_DEV_TYPE_LL;
>> bus_params.link_can_suspend = true;
>> bus_params.chip_id = ath10k_pci_soc_read32(ar, SOC_CHIP_ID_ADDRESS);
It seems to me the chip reset was done explicitly *before* reading the
chipid for a reason.
"""
ath10k: reset chip before reading chip_id in probe
There are some very rare cases with some hardware
configuration that the device doesn't init quickly
enough in which case reading chip_id yielded 0.
This caused driver to subsequently fail to setup
the device.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
"""
Might be the ath10k_pci_chip_reset() function needs to be modified to
work properly for Archer C7 v1 units.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] net: rtlwifi: fix a potential NULL pointer dereference
From: Kalle Valo @ 2019-03-23 6:40 UTC (permalink / raw)
To: Kangjie Lu
Cc: pakki001, Ping-Ke Shih, David S. Miller, linux-wireless, netdev,
linux-kernel
In-Reply-To: <AFBB09F8-46AE-4B74-BF53-1045814476B0@umn.edu>
Kangjie Lu <kjlu@umn.edu> writes:
>> On Mar 12, 2019, at 2:56 AM, Kangjie Lu <kjlu@umn.edu> wrote:
>>
>> In case alloc_workqueue fails, the fix reports the error and
>> returns to avoid NULL pointer dereference.
>>
>> Signed-off-by: Kangjie Lu <kjlu@umn.edu>
>> ---
>> drivers/net/wireless/realtek/rtlwifi/base.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c
>> b/drivers/net/wireless/realtek/rtlwifi/base.c
>> index 217d2a7a43c7..ac746c322554 100644
>> --- a/drivers/net/wireless/realtek/rtlwifi/base.c
>> +++ b/drivers/net/wireless/realtek/rtlwifi/base.c
>> @@ -448,6 +448,11 @@ static void _rtl_init_deferred_work(struct ieee80211_hw *hw)
>> /* <2> work queue */
>> rtlpriv->works.hw = hw;
>> rtlpriv->works.rtl_wq = alloc_workqueue("%s", 0, 0, rtlpriv->cfg->name);
>> + if (unlikely(!rtlpriv->works.rtl_wq)) {
>> + pr_err("Failed to allocate work queue\n");
>> + return;
>> + }
>> +
>
> Can someone review the patch?
wireless-drivers-next is not yet open due to the wireless workshop. Also
you can check the patch status yourself:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#checking_state_of_patches_from_patchwork
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] iwlwifi: work around clang -Wuninitialized warning
From: Luca Coelho @ 2019-03-23 6:11 UTC (permalink / raw)
To: Arnd Bergmann, Johannes Berg
Cc: clang-built-linux, Nick Desaulniers, Nathan Chancellor,
Emmanuel Grumbach, Intel Linux Wireless, Kalle Valo,
David S. Miller, Sara Sharon, Avraham Stern, linux-wireless,
netdev, linux-kernel
In-Reply-To: <20190322141322.463149-1-arnd@arndb.de>
On Fri, 2019-03-22 at 15:13 +0100, Arnd Bergmann wrote:
> Clang incorrectly warns about an uninitialized variable:
>
> drivers/net/wireless/intel/iwlwifi/mvm/sta.c:2114:12: error: variable
> 'queue' is used uninitialized whenever 'if'
> condition is false [-Werror,-Wsometimes-uninitialized]
> else if (WARN(1, "Missing required TXQ for adding
> bcast STA\n"))
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~~~~~~~~~~
> include/asm-generic/bug.h:130:36: note: expanded from macro 'WARN'
> #define WARN(condition, format...)
> ({ \
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~~~~
> drivers/net/wireless/intel/iwlwifi/mvm/sta.c:2119:33: note:
> uninitialized use occurs here
> iwl_mvm_enable_txq(mvm, NULL, queue, 0, &cfg,
> wdg_timeout);
> ^~~~~
> drivers/net/wireless/intel/iwlwifi/mvm/sta.c:2114:8: note: remove the
> 'if' if its condition is always true
> else if (WARN(1, "Missing required TXQ for adding
> bcast STA\n"))
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~~~~~~~~~~~
> drivers/net/wireless/intel/iwlwifi/mvm/sta.c:2094:11: note:
> initialize the variable 'queue' to silence this warning
> int queue;
> ^
> = 0
> 1 error generated.
>
> This cannot happen because the if/else if/else if block always
> has one code path that is entered. However, we can simply
> rearrange the code to let clang see this as well.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Thanks for the patch, Arnd! But I have already queued up an equivalent
patch for v5.2 (should probably reach linux-next by the end of next
week or so):
https://patchwork.kernel.org/patch/10844025/
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] net: rtlwifi: fix a potential NULL pointer dereference
From: Kangjie Lu @ 2019-03-23 3:59 UTC (permalink / raw)
To: kjlu
Cc: pakki001, Ping-Ke Shih, Kalle Valo, David S. Miller,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20190312075633.573-1-kjlu@umn.edu>
> On Mar 12, 2019, at 2:56 AM, Kangjie Lu <kjlu@umn.edu> wrote:
>
> In case alloc_workqueue fails, the fix reports the error and
> returns to avoid NULL pointer dereference.
>
> Signed-off-by: Kangjie Lu <kjlu@umn.edu>
> ---
> drivers/net/wireless/realtek/rtlwifi/base.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c b/drivers/net/wireless/realtek/rtlwifi/base.c
> index 217d2a7a43c7..ac746c322554 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/base.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/base.c
> @@ -448,6 +448,11 @@ static void _rtl_init_deferred_work(struct ieee80211_hw *hw)
> /* <2> work queue */
> rtlpriv->works.hw = hw;
> rtlpriv->works.rtl_wq = alloc_workqueue("%s", 0, 0, rtlpriv->cfg->name);
> + if (unlikely(!rtlpriv->works.rtl_wq)) {
> + pr_err("Failed to allocate work queue\n");
> + return;
> + }
> +
Can someone review the patch?
Thanks.
> INIT_DELAYED_WORK(&rtlpriv->works.watchdog_wq,
> (void *)rtl_watchdog_wq_callback);
> INIT_DELAYED_WORK(&rtlpriv->works.ips_nic_off_wq,
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH] net: wireless: fix missing checks for ioremap
From: Kangjie Lu @ 2019-03-23 3:58 UTC (permalink / raw)
To: kjlu
Cc: pakki001, Kalle Valo, David S. Miller, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20190311075440.1513-1-kjlu@umn.edu>
Can someone review the patch?
Thanks.
> On Mar 11, 2019, at 2:54 AM, Kangjie Lu <kjlu@umn.edu> wrote:
>
> ioremap could fail and returns NULL. The fix actively checks
> its return value and handles potential failures.
>
> Signed-off-by: Kangjie Lu <kjlu@umn.edu>
> ---
> drivers/net/wireless/ray_cs.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/net/wireless/ray_cs.c b/drivers/net/wireless/ray_cs.c
> index 44a943d18b84..cecd18a2f2de 100644
> --- a/drivers/net/wireless/ray_cs.c
> +++ b/drivers/net/wireless/ray_cs.c
> @@ -394,6 +394,10 @@ static int ray_config(struct pcmcia_device *link)
> goto failed;
> local->sram = ioremap(link->resource[2]->start,
> resource_size(link->resource[2]));
> + if (!local->sram) {
> + ret = -ENOMEM;
> + goto failed;
> + }
>
> /*** Set up 16k window for shared memory (receive buffer) ***************/
> link->resource[3]->flags |=
> @@ -408,6 +412,10 @@ static int ray_config(struct pcmcia_device *link)
> goto failed;
> local->rmem = ioremap(link->resource[3]->start,
> resource_size(link->resource[3]));
> + if (!local->rmem) {
> + ret = -ENOMEM;
> + goto failed;
> + }
>
> /*** Set up window for attribute memory ***********************************/
> link->resource[4]->flags |=
> @@ -422,6 +430,10 @@ static int ray_config(struct pcmcia_device *link)
> goto failed;
> local->amem = ioremap(link->resource[4]->start,
> resource_size(link->resource[4]));
> + if (!local->amem) {
> + ret = -ENOMEM;
> + goto failed;
> + }
>
> dev_dbg(&link->dev, "ray_config sram=%p\n", local->sram);
> dev_dbg(&link->dev, "ray_config rmem=%p\n", local->rmem);
> --
> 2.17.1
>
^ permalink raw reply
* [PATCH v2] net: mwifiex: fix a NULL pointer dereference
From: Kangjie Lu @ 2019-03-23 3:57 UTC (permalink / raw)
To: kjlu
Cc: pakki001, Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat,
Xinming Hu, Kalle Valo, David S. Miller, linux-wireless, netdev,
linux-kernel
In-Reply-To: <87zhq04pl0.fsf@codeaurora.org>
In case dev_alloc_skb fails, the fix returns -ENOMEM to avoid
NULL pointer dereference.
Signed-off-by: Kangjie Lu <kjlu@umn.edu>
---
V2: minor change: simply remove whitespace
---
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index 60db2b969e20..8c35441fd9b7 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -341,6 +341,12 @@ static int mwifiex_dnld_sleep_confirm_cmd(struct mwifiex_adapter *adapter)
sleep_cfm_tmp =
dev_alloc_skb(sizeof(struct mwifiex_opt_sleep_confirm)
+ MWIFIEX_TYPE_LEN);
+ if (!sleep_cfm_tmp) {
+ mwifiex_dbg(adapter, ERROR,
+ "SLEEP_CFM: dev_alloc_skb failed\n");
+ return -ENOMEM;
+ }
+
skb_put(sleep_cfm_tmp, sizeof(struct mwifiex_opt_sleep_confirm)
+ MWIFIEX_TYPE_LEN);
put_unaligned_le32(MWIFIEX_USB_TYPE_CMD, sleep_cfm_tmp->data);
--
2.17.1
^ permalink raw reply related
* Re: preparing for 802.11ah channels
From: thomas @ 2019-03-22 22:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <eb3df21727c81ceed319b9106db895d735f4919d.camel@sipsolutions.net>
On Fri, Mar 22, 2019 at 1:50 PM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> On Fri, 2019-03-22 at 21:46 +0100, Johannes Berg wrote:
> >
> > In effect, an existing
> >
> > u32 freq;
> >
> > would become
> >
> > u32 freq, freq_fractional;
> >
> > and we'd just treat the two as a 32.32 fixed point integer.
>
> Maybe easier would be to say
>
> u32 freq;
> u16 freq_partial_khz;
>
> and basically say
>
> freq_khz = freq * 1000 + freq_partial_khz;
>
> Same reasoning and similar logic, but no need to do any sort of fixed
> point conversions.
I guess it's a tradeoff between leaving MHz-only drivers alone and
wrapping existing assignments and comparisons in maybe a macro to
extract the final KHz value. The current set of changes is about 150
lines in net/mac80211/ and net/wireless/ [1] with drivers/ being about
the same.
Adding the KHz part to center_freq, center_freq1, and rx_status->freq
may be fewer overall changes in mac80211 and cfg80211, and should be
none for existing drivers.
I'll give this a shot at some point when it comes time to rebase on
upstream wireless-testing.
[1] https://paste.debian.net/1074289/
^ permalink raw reply
* Re: preparing for 802.11ah channels
From: Johannes Berg @ 2019-03-22 20:50 UTC (permalink / raw)
To: thomas; +Cc: linux-wireless
In-Reply-To: <3ae333867edab6cc30e8154cce47ce3b4555fa43.camel@sipsolutions.net>
On Fri, 2019-03-22 at 21:46 +0100, Johannes Berg wrote:
>
> In effect, an existing
>
> u32 freq;
>
> would become
>
> u32 freq, freq_fractional;
>
> and we'd just treat the two as a 32.32 fixed point integer.
Maybe easier would be to say
u32 freq;
u16 freq_partial_khz;
and basically say
freq_khz = freq * 1000 + freq_partial_khz;
Same reasoning and similar logic, but no need to do any sort of fixed
point conversions.
johannes
^ permalink raw reply
* Re: preparing for 802.11ah channels
From: Johannes Berg @ 2019-03-22 20:46 UTC (permalink / raw)
To: thomas; +Cc: linux-wireless
In-Reply-To: <CABWD38kCrzns2RkShGDY6ip99fAFM3Ar_n6zDhk73KHxLTDbpQ@mail.gmail.com>
On Fri, 2019-03-22 at 13:40 -0700, thomas wrote:
>
> > OTOH, I guess if you change center_freq1 to center_freq1_khz or
> > something then you compile-fail everywhere ...
>
> Yeah it gets ugly quick to have additional freq_khz members,
> especially when doing comparisons etc.
>
> The kernel part was not too bad, there are only 3 structs or so to
> worry about. hostap on the other hand is incredibly hairy :)
We/I thought about this some more now at the wifi summit, and I think
the better choice would be to just add a "u32 fractional;" part where
needed.
In effect, an existing
u32 freq;
would become
u32 freq, freq_fractional;
and we'd just treat the two as a 32.32 fixed point integer. Maybe even
just do "u8 freq_fractional" since a 32.8 fixed point integer would be
sufficient (we do need >64k MHz for WiGig, so doing 16.16 or 16.8 won't
work).
That would have the advantage of not requiring any changes from drivers
that don't need to support it. It would also cover some of the 4.9 GHz
stuff Jouni looked up - it as fractional center frequencies too (at
least expressed in MHz).
For userspace API I'm not really sure, maybe we should just move to KHz?
Or maybe just do the same thing? On the one hand, moving to KHz would be
cleaner in a sense, but on the other hand it would require doing things
like checking that the KHz and MHz attributes agree if both are given,
etc., so similarly adding a "fractional MHz" attribute might be nicer
since we can also assume it to be 0 if not present (in fact, we could
*reject* it if it's 0, thereby ensuring that it'll only ever be nonzero)
johannes
^ permalink raw reply
* Re: preparing for 802.11ah channels
From: thomas @ 2019-03-22 20:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <83dad8c2478e141e382b02056389ba281bc72720.camel@sipsolutions.net>
On Fri, Mar 15, 2019 at 2:47 AM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> On Sat, 2019-02-16 at 15:45 -0800, thomas pedersen wrote:
> > Hello,
> >
> > I'm working on defining new channels for S1G PHYs in mac80211. These
> > are in the 900MHz range and center frequency for the 1MHz channels are
> > on a half MHz, while the existing channel definitions are in units of
> > MHz.
>
> Yay... :)
>
> > In order to support the new channels we could change the internal
> > center frequency units to KHz and extend the nl80211 API so
> > NL80211_FREQUENCY_ATTR_FREQ and NL80211_ATTR_WIPHY_FREQ get _KHZ
> > variants while renaming the original attributes to _MHZ to reflect the
> > units.
>
> The nl80211 API seems straightforward, yeah.
>
> > From looking at the code it looks like this should be fairly
> > straightforward, if involving a lot of changes since the driver
> > declarations would have to change too. Am I missing something
> > obviously wrong, or does this sound reasonable?
>
> I'm not sure I agree about all the driver changes being straightforward.
> In theory yes, but ... ;-)
>
> I guess you'd define a new band (NL80211_BAND_S1G or something?), so
> perhaps there's a way we can get away with doing it only on that band?
>
> OTOH, I guess if you change center_freq1 to center_freq1_khz or
> something then you compile-fail everywhere ...
Yeah it gets ugly quick to have additional freq_khz members,
especially when doing comparisons etc.
The kernel part was not too bad, there are only 3 structs or so to
worry about. hostap on the other hand is incredibly hairy :)
Thomas
^ permalink raw reply
* Re: [PATCH] ath10k: reset chip after supported check
From: Christian Lamparter @ 2019-03-22 19:25 UTC (permalink / raw)
To: Tomislav Požega; +Cc: linux-wireless, openwrt-devel, kalle
In-Reply-To: <1553281120-22139-1-git-send-email-pozega.tomislav@gmail.com>
On Friday, March 22, 2019 7:58:40 PM CET Tomislav Požega wrote:
> When chip reset is done before the chip is checked if supported
> there will be crash. Previous behaviour caused bootloops on
> Archer C7 v1 units, this patch allows clean device boot without
> excluding ath10k driver.
>
You need
Fixes: 1a7fecb766c8 ("ath10k: reset chip before reading chip_id in probe")
too
> Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com>
> ---
> drivers/net/wireless/ath/ath10k/pci.c | 12 ++++++------
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
> index e24403c..ec681da 100644
> --- a/drivers/net/wireless/ath/ath10k/pci.c
> +++ b/drivers/net/wireless/ath/ath10k/pci.c
> @@ -3619,12 +3619,6 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
> goto err_deinit_irq;
> }
>
> - ret = ath10k_pci_chip_reset(ar);
> - if (ret) {
> - ath10k_err(ar, "failed to reset chip: %d\n", ret);
> - goto err_free_irq;
> - }
> -
> bus_params.dev_type = ATH10K_DEV_TYPE_LL;
> bus_params.link_can_suspend = true;
> bus_params.chip_id = ath10k_pci_soc_read32(ar, SOC_CHIP_ID_ADDRESS);
> @@ -3639,6 +3633,12 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
> goto err_free_irq;
> }
>
> + ret = ath10k_pci_chip_reset(ar);
> + if (ret) {
> + ath10k_err(ar, "failed to reset chip: %d\n", ret);
> + goto err_free_irq;
> + }
> +
> ret = ath10k_core_register(ar, &bus_params);
> if (ret) {
> ath10k_err(ar, "failed to register driver core: %d\n", ret);
>
^ permalink raw reply
* [PATCH] ath10k: reset chip after supported check
From: Tomislav Požega @ 2019-03-22 18:58 UTC (permalink / raw)
To: linux-wireless; +Cc: openwrt-devel
When chip reset is done before the chip is checked if supported
there will be crash. Previous behaviour caused bootloops on
Archer C7 v1 units, this patch allows clean device boot without
excluding ath10k driver.
Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com>
---
drivers/net/wireless/ath/ath10k/pci.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index e24403c..ec681da 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -3619,12 +3619,6 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
goto err_deinit_irq;
}
- ret = ath10k_pci_chip_reset(ar);
- if (ret) {
- ath10k_err(ar, "failed to reset chip: %d\n", ret);
- goto err_free_irq;
- }
-
bus_params.dev_type = ATH10K_DEV_TYPE_LL;
bus_params.link_can_suspend = true;
bus_params.chip_id = ath10k_pci_soc_read32(ar, SOC_CHIP_ID_ADDRESS);
@@ -3639,6 +3633,12 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
goto err_free_irq;
}
+ ret = ath10k_pci_chip_reset(ar);
+ if (ret) {
+ ath10k_err(ar, "failed to reset chip: %d\n", ret);
+ goto err_free_irq;
+ }
+
ret = ath10k_core_register(ar, &bus_params);
if (ret) {
ath10k_err(ar, "failed to register driver core: %d\n", ret);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] b43: shut up clang -Wuninitialized variable warning
From: Nathan Chancellor @ 2019-03-22 16:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kalle Valo, David S. Miller, Larry Finger, Priit Laes,
clang-built-linux, Nick Desaulniers, linux-wireless, b43-dev,
netdev, linux-kernel
In-Reply-To: <20190322143725.1332353-1-arnd@arndb.de>
On Fri, Mar 22, 2019 at 03:37:02PM +0100, Arnd Bergmann wrote:
> Clang warns about what is clearly a case of passing an uninitalized
> variable into a static function:
>
> drivers/net/wireless/broadcom/b43/phy_lp.c:1852:23: error: variable 'gains' is uninitialized when used here
> [-Werror,-Wuninitialized]
> lpphy_papd_cal(dev, gains, 0, 1, 30);
> ^~~~~
> drivers/net/wireless/broadcom/b43/phy_lp.c:1838:2: note: variable 'gains' is declared here
> struct lpphy_tx_gains gains, oldgains;
> ^
> 1 error generated.
>
> However, this function is empty, and its arguments are never evaluated,
> so gcc in contrast does not warn here. Both compilers behave in a
> reasonable way as far as I can tell, so we should change the code
> to avoid the warning everywhere.
>
> We could just eliminate the lpphy_papd_cal() function entirely,
> given that it has had the TODO comment in it for 10 years now
> and is rather unlikely to ever get done. I'm doing a simpler
> change here, and just pass the 'oldgains' variable in that has
> been initialized, based on the guess that this is what was
> originally meant.
>
> Fixes: 2c0d6100da3e ("b43: LP-PHY: Begin implementing calibration & software RFKILL support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> drivers/net/wireless/broadcom/b43/phy_lp.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/b43/phy_lp.c b/drivers/net/wireless/broadcom/b43/phy_lp.c
> index 46408a560814..aedee026c5e2 100644
> --- a/drivers/net/wireless/broadcom/b43/phy_lp.c
> +++ b/drivers/net/wireless/broadcom/b43/phy_lp.c
> @@ -1835,7 +1835,7 @@ static void lpphy_papd_cal(struct b43_wldev *dev, struct lpphy_tx_gains gains,
> static void lpphy_papd_cal_txpwr(struct b43_wldev *dev)
> {
> struct b43_phy_lp *lpphy = dev->phy.lp;
> - struct lpphy_tx_gains gains, oldgains;
> + struct lpphy_tx_gains oldgains;
> int old_txpctl, old_afe_ovr, old_rf, old_bbmult;
>
> lpphy_read_tx_pctl_mode_from_hardware(dev);
> @@ -1849,9 +1849,9 @@ static void lpphy_papd_cal_txpwr(struct b43_wldev *dev)
> lpphy_set_tx_power_control(dev, B43_LPPHY_TXPCTL_OFF);
>
> if (dev->dev->chip_id == 0x4325 && dev->dev->chip_rev == 0)
> - lpphy_papd_cal(dev, gains, 0, 1, 30);
> + lpphy_papd_cal(dev, oldgains, 0, 1, 30);
> else
> - lpphy_papd_cal(dev, gains, 0, 1, 65);
> + lpphy_papd_cal(dev, oldgains, 0, 1, 65);
>
> if (old_afe_ovr)
> lpphy_set_tx_gains(dev, oldgains);
> --
> 2.20.0
>
^ permalink raw reply
* Re: [PATCH] b43: shut up clang -Wuninitialized variable warning
From: Larry Finger @ 2019-03-22 15:47 UTC (permalink / raw)
To: Arnd Bergmann, Kalle Valo, David S. Miller, Priit Laes
Cc: clang-built-linux, Nick Desaulniers, Nathan Chancellor,
linux-wireless, b43-dev, netdev, linux-kernel
In-Reply-To: <20190322143725.1332353-1-arnd@arndb.de>
On 3/22/19 9:37 AM, Arnd Bergmann wrote:
> Clang warns about what is clearly a case of passing an uninitalized
> variable into a static function:
>
> drivers/net/wireless/broadcom/b43/phy_lp.c:1852:23: error: variable 'gains' is uninitialized when used here
> [-Werror,-Wuninitialized]
> lpphy_papd_cal(dev, gains, 0, 1, 30);
> ^~~~~
> drivers/net/wireless/broadcom/b43/phy_lp.c:1838:2: note: variable 'gains' is declared here
> struct lpphy_tx_gains gains, oldgains;
> ^
> 1 error generated.
>
> However, this function is empty, and its arguments are never evaluated,
> so gcc in contrast does not warn here. Both compilers behave in a
> reasonable way as far as I can tell, so we should change the code
> to avoid the warning everywhere.
>
> We could just eliminate the lpphy_papd_cal() function entirely,
> given that it has had the TODO comment in it for 10 years now
> and is rather unlikely to ever get done. I'm doing a simpler
> change here, and just pass the 'oldgains' variable in that has
> been initialized, based on the guess that this is what was
> originally meant.
>
> Fixes: 2c0d6100da3e ("b43: LP-PHY: Begin implementing calibration & software RFKILL support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/net/wireless/broadcom/b43/phy_lp.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/b43/phy_lp.c b/drivers/net/wireless/broadcom/b43/phy_lp.c
> index 46408a560814..aedee026c5e2 100644
> --- a/drivers/net/wireless/broadcom/b43/phy_lp.c
> +++ b/drivers/net/wireless/broadcom/b43/phy_lp.c
> @@ -1835,7 +1835,7 @@ static void lpphy_papd_cal(struct b43_wldev *dev, struct lpphy_tx_gains gains,
> static void lpphy_papd_cal_txpwr(struct b43_wldev *dev)
> {
> struct b43_phy_lp *lpphy = dev->phy.lp;
> - struct lpphy_tx_gains gains, oldgains;
> + struct lpphy_tx_gains oldgains;
> int old_txpctl, old_afe_ovr, old_rf, old_bbmult;
>
> lpphy_read_tx_pctl_mode_from_hardware(dev);
> @@ -1849,9 +1849,9 @@ static void lpphy_papd_cal_txpwr(struct b43_wldev *dev)
> lpphy_set_tx_power_control(dev, B43_LPPHY_TXPCTL_OFF);
>
> if (dev->dev->chip_id == 0x4325 && dev->dev->chip_rev == 0)
> - lpphy_papd_cal(dev, gains, 0, 1, 30);
> + lpphy_papd_cal(dev, oldgains, 0, 1, 30);
> else
> - lpphy_papd_cal(dev, gains, 0, 1, 65);
> + lpphy_papd_cal(dev, oldgains, 0, 1, 65);
>
> if (old_afe_ovr)
> lpphy_set_tx_gains(dev, oldgains);
>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Thanks. I will submit a patch that removes lpphy_papd_cal(). You are correct
that it is unlikely ever to be implemented.
Larry
^ permalink raw reply
* Re: Ath10k on XPS 9380 regularly disconnects
From: Kai-Heng Feng @ 2019-03-22 15:43 UTC (permalink / raw)
To: Kalle Valo; +Cc: Anthony Wong, Stephan Fabel, linux-wireless, ath10k
In-Reply-To: <87pnqknonc.fsf@codeaurora.org>
at 01:05, Kalle Valo <kvalo@codeaurora.org> wrote:
> + ath10k list
> - netdev & linux-kernel
>
> Kai-Heng Feng <kai.heng.feng@canonical.com> writes:
>
>> There’s an issue that ath10k disconnects at regular basis [1], on
>> Linux kernel 4.18.
>>
>> Unfortunately I can’t reproduce the issue on XPS 9380 at my hand.
>>
>> Is there already a fix in upstream kernel?
>
> I'm not aware of any fixes related to this. Is this a regression? In
> other words, is there a known version of ath10k or firmware which didn't
> have this problem?
We know this issue happen on kernel v4.15 and v4.18, but kernels before
v4.15 were not tested.
The issue happens with Google Mesh, which has 802.11ac capability.
I haven’t been able to reproduce the issue with an 802.11n router (yet).
Kai-Heng
>
>> [1] https://bugs.launchpad.net/bugs/1818881
>
> Relevant information from dmesg:
>
> [ 19.346810] ath10k_pci 0000:02:00.0: qca6174 hw3.2 target 0x05030000
> chip_id 0x00340aff sub 1a56:143a
> [ 19.346812] ath10k_pci 0000:02:00.0: kconfig debug 0 debugfs 1 tracing
> 1 dfs 0 testmode 0
> [ 19.347136] ath10k_pci 0000:02:00.0: firmware ver
> WLAN.RM.4.4.1-00132-QCARMSWP-1 api 6 features wowlan,ignore-otp,mfp crc32
> 79f4db86
>
> [...]
>
> [77451.338339] WARNING: CPU: 4 PID: 0 at
> /build/linux-hwe-9KJ07q/linux-hwe-4.18.0/drivers/net/wireless/ath/ath10k/htt_rx.c:46
> ath10k_htt_rx_pop_paddr.isra.29+0xd9/0xf0 [ath10k_core]
>
> [...]
>
> [81254.857667] WARNING: CPU: 1 PID: 0 at
> /build/linux-hwe-9KJ07q/linux-hwe-4.18.0/drivers/net/wireless/ath/ath10k/htt_rx.c:46
> ath10k_htt_rx_pop_paddr.isra.29+0xd9/0xf0 [ath10k_core]
>
> [...]
>
> [81390.186167] WARNING: CPU: 2 PID: 0 at
> /build/linux-hwe-9KJ07q/linux-hwe-4.18.0/drivers/net/wireless/ath/ath10k/htt_rx.c:46
> ath10k_htt_rx_pop_paddr.isra.29+0xd9/0xf0 [ath10k_core]
>
> --
> Kalle Valo
^ permalink raw reply
* [PATCH] b43: shut up clang -Wuninitialized variable warning
From: Arnd Bergmann @ 2019-03-22 14:37 UTC (permalink / raw)
To: Kalle Valo, David S. Miller, Larry Finger, Arnd Bergmann,
Priit Laes
Cc: clang-built-linux, Nick Desaulniers, Nathan Chancellor,
linux-wireless, b43-dev, netdev, linux-kernel
Clang warns about what is clearly a case of passing an uninitalized
variable into a static function:
drivers/net/wireless/broadcom/b43/phy_lp.c:1852:23: error: variable 'gains' is uninitialized when used here
[-Werror,-Wuninitialized]
lpphy_papd_cal(dev, gains, 0, 1, 30);
^~~~~
drivers/net/wireless/broadcom/b43/phy_lp.c:1838:2: note: variable 'gains' is declared here
struct lpphy_tx_gains gains, oldgains;
^
1 error generated.
However, this function is empty, and its arguments are never evaluated,
so gcc in contrast does not warn here. Both compilers behave in a
reasonable way as far as I can tell, so we should change the code
to avoid the warning everywhere.
We could just eliminate the lpphy_papd_cal() function entirely,
given that it has had the TODO comment in it for 10 years now
and is rather unlikely to ever get done. I'm doing a simpler
change here, and just pass the 'oldgains' variable in that has
been initialized, based on the guess that this is what was
originally meant.
Fixes: 2c0d6100da3e ("b43: LP-PHY: Begin implementing calibration & software RFKILL support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/wireless/broadcom/b43/phy_lp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/broadcom/b43/phy_lp.c b/drivers/net/wireless/broadcom/b43/phy_lp.c
index 46408a560814..aedee026c5e2 100644
--- a/drivers/net/wireless/broadcom/b43/phy_lp.c
+++ b/drivers/net/wireless/broadcom/b43/phy_lp.c
@@ -1835,7 +1835,7 @@ static void lpphy_papd_cal(struct b43_wldev *dev, struct lpphy_tx_gains gains,
static void lpphy_papd_cal_txpwr(struct b43_wldev *dev)
{
struct b43_phy_lp *lpphy = dev->phy.lp;
- struct lpphy_tx_gains gains, oldgains;
+ struct lpphy_tx_gains oldgains;
int old_txpctl, old_afe_ovr, old_rf, old_bbmult;
lpphy_read_tx_pctl_mode_from_hardware(dev);
@@ -1849,9 +1849,9 @@ static void lpphy_papd_cal_txpwr(struct b43_wldev *dev)
lpphy_set_tx_power_control(dev, B43_LPPHY_TXPCTL_OFF);
if (dev->dev->chip_id == 0x4325 && dev->dev->chip_rev == 0)
- lpphy_papd_cal(dev, gains, 0, 1, 30);
+ lpphy_papd_cal(dev, oldgains, 0, 1, 30);
else
- lpphy_papd_cal(dev, gains, 0, 1, 65);
+ lpphy_papd_cal(dev, oldgains, 0, 1, 65);
if (old_afe_ovr)
lpphy_set_tx_gains(dev, oldgains);
--
2.20.0
^ permalink raw reply related
* Re: [PATCH v4 03/13] rtw88: hci files
From: Brian Norris @ 2019-03-22 14:36 UTC (permalink / raw)
To: Tony Chuang
Cc: Grant Grundler, Kalle Valo, Johannes Berg,
Larry.Finger@lwfinger.net, Pkshih, Andy Huang,
sgruszka@redhat.com, linux-wireless@vger.kernel.org
In-Reply-To: <F7CD281DE3E379468C6D07993EA72F84D17AA49B@RTITMBSVM04.realtek.com.tw>
[Following up a little late on this one]
Hi Grant and Tony,
On Wed, Feb 20, 2019 at 11:19:10AM +0000, Tony Chuang wrote:
> > -----Original Message-----
> > From: Grant Grundler [mailto:grundler@chromium.org]
> > This is another bug in the code actually: the code accessing tx
> > descriptor rings should be declared volatile since they are updated by
> > the device which is not visible to the compiler. Compiler won't
> > optimize (or reorder) volatile code (by "volatile code" I mean code
> > that is accessing data marked "volatile").
If I'm understanding the code correctly, the TX ISR assumes that
everything between the last entry we processed (ring->r.rp) and a
certain point (cur_rp) is complete. The former index was saved during
the previous interrupt and the latter is determined via a register read.
So assuming properly synchronized interrupts (such as with PCIe MSI) and
no device-/firmware-related ordering bugs, then I think we're OK -- the
only "volatile" piece is the register read, which already embeds
volatile in the IO accessors.
> This is fixed in PATCH v5. We reset and use rx tag to sync dma.
> So the polling can be removed and the bus timeout has not happened again.
Yes, I tested the later versions of this series, and I didn't see this
problem so far. I'll follow up there with my Review/Test information
eventually.
Thanks,
Brian
^ permalink raw reply
* Re: Wi-Fi drivers/chipsets supporting 802.11w / PMF / MFP
From: Raul Siles @ 2019-03-22 14:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: Rosen Penev, linux-wireless
In-Reply-To: <5e04d03f8f7cd65073215f395e40fdc2af0a7704.camel@sipsolutions.net>
Trying to sum up what has been shared (a few weeks ago) in both the
linux-wireless kernel mailing-list and the hostapd mailing-list, a way
to find Linux drivers with support for 802.11w / PMF / MFP (required
for WPA3), including both mac80211-based drivers and cfg80211-based,
aka fullmac, drivers, is:
https://elixir.bootlin.com/linux/latest/ident/MFP_CAPABLE
https://elixir.bootlin.com/linux/latest/ident/WLAN_CIPHER_SUITE_AES_CMAC
Cheers,
--
Raul Siles
On Thu, Jan 31, 2019 at 8:29 PM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> On Tue, 2019-01-29 at 18:31 +0100, Raul Siles wrote:
> > Hi Rosen,
> > Thanks for the reference! It is, indeed, a great and accurate way of
> > keeping track of Linux drivers that are MFP_CAPABLE (Wi-Fi PMF, MFP,
> > 802.11w).
>
> Note that this is only true for mac80211-based drivers.
>
> For the others, you'll want to check if their cipher list mentions
> WLAN_CIPHER_SUITE_AES_CMAC.
>
> johannes
>
^ permalink raw reply
* Re: [PATCH] cfg80211: Change an 'else if' into an 'else' in cfg80211_calculate_bitrate_he
From: Arnd Bergmann @ 2019-03-22 14:16 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Johannes Berg, linux-wireless, David S. Miller, Networking,
Linux Kernel Mailing List, clang-built-linux, Nick Desaulniers
In-Reply-To: <20190307235735.31487-1-natechancellor@gmail.com>
On Fri, Mar 8, 2019 at 12:57 AM Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> When building with -Wsometimes-uninitialized, Clang warns:
>
> net/wireless/util.c:1223:11: warning: variable 'result' is used
> uninitialized whenever 'if' condition is false
> [-Wsometimes-uninitialized]
>
> Clang can't evaluate at this point that WARN(1, ...) always returns true
> because __ret_warn_on is defined as !!(condition), which isn't
> immediately evaluated as 1. Change this branch to else so that it's
> clear to Clang that we intend to bail out here.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/382
> Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> net/wireless/util.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/wireless/util.c b/net/wireless/util.c
> index e4b8db5e81ec..75899b62bdc9 100644
> --- a/net/wireless/util.c
> +++ b/net/wireless/util.c
> @@ -1220,9 +1220,11 @@ static u32 cfg80211_calculate_bitrate_he(struct rate_info *rate)
> else if (rate->bw == RATE_INFO_BW_HE_RU &&
> rate->he_ru_alloc == NL80211_RATE_INFO_HE_RU_ALLOC_26)
> result = rates_26[rate->he_gi];
> - else if (WARN(1, "invalid HE MCS: bw:%d, ru:%d\n",
> - rate->bw, rate->he_ru_alloc))
> + else {
> + WARN(1, "invalid HE MCS: bw:%d, ru:%d\n",
> + rate->bw, rate->he_ru_alloc);
> return 0;
> + }
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
I independently came up with the same fix before I saw yours,
the only difference was that I avoided the extra curly braces
using
+ else
+ return !WARN(1, "invalid HE MCS: bw:%d, ru:%d\n",
+ rate->bw, rate->he_ru_alloc);
to avoid the mix of bare if() and if() {}
Arnd
^ permalink raw reply
* [PATCH] iwlwifi: work around clang -Wuninitialized warning
From: Arnd Bergmann @ 2019-03-22 14:13 UTC (permalink / raw)
To: Johannes Berg
Cc: clang-built-linux, Nick Desaulniers, Nathan Chancellor,
Arnd Bergmann, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, Kalle Valo, David S. Miller, Sara Sharon,
Avraham Stern, linux-wireless, netdev, linux-kernel
Clang incorrectly warns about an uninitialized variable:
drivers/net/wireless/intel/iwlwifi/mvm/sta.c:2114:12: error: variable 'queue' is used uninitialized whenever 'if'
condition is false [-Werror,-Wsometimes-uninitialized]
else if (WARN(1, "Missing required TXQ for adding bcast STA\n"))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/asm-generic/bug.h:130:36: note: expanded from macro 'WARN'
#define WARN(condition, format...) ({ \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/intel/iwlwifi/mvm/sta.c:2119:33: note: uninitialized use occurs here
iwl_mvm_enable_txq(mvm, NULL, queue, 0, &cfg, wdg_timeout);
^~~~~
drivers/net/wireless/intel/iwlwifi/mvm/sta.c:2114:8: note: remove the 'if' if its condition is always true
else if (WARN(1, "Missing required TXQ for adding bcast STA\n"))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/intel/iwlwifi/mvm/sta.c:2094:11: note: initialize the variable 'queue' to silence this warning
int queue;
^
= 0
1 error generated.
This cannot happen because the if/else if/else if block always
has one code path that is entered. However, we can simply
rearrange the code to let clang see this as well.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
index 498c315291cf..91ce56d2ebb8 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
@@ -2107,12 +2107,14 @@ int iwl_mvm_send_add_bcast_sta(struct iwl_mvm *mvm, struct ieee80211_vif *vif)
if (!iwl_mvm_has_new_tx_api(mvm)) {
if (vif->type == NL80211_IFTYPE_AP ||
- vif->type == NL80211_IFTYPE_ADHOC)
+ vif->type == NL80211_IFTYPE_ADHOC) {
queue = mvm->probe_queue;
- else if (vif->type == NL80211_IFTYPE_P2P_DEVICE)
+ } else if (vif->type == NL80211_IFTYPE_P2P_DEVICE) {
queue = mvm->p2p_dev_queue;
- else if (WARN(1, "Missing required TXQ for adding bcast STA\n"))
+ } else {
+ WARN(1, "Missing required TXQ for adding bcast STA\n");
return -EINVAL;
+ }
bsta->tfd_queue_msk |= BIT(queue);
--
2.20.0
^ permalink raw reply related
* [PATCH 18/24] iwlwifi: mvm: no need to check return value of debugfs_create functions
From: Luca Coelho @ 2019-03-22 13:58 UTC (permalink / raw)
To: kvalo
Cc: linux-wireless, Greg Kroah-Hartman, Johannes Berg,
Emmanuel Grumbach, Luca Coelho, Intel Linux Wireless
In-Reply-To: <20190322135903.10631-1-luca@coelho.fi>
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Cc: Luca Coelho <luciano.coelho@intel.com>
Cc: Intel Linux Wireless <linuxwifi@intel.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
.../wireless/intel/iwlwifi/mvm/debugfs-vif.c | 17 +---
.../net/wireless/intel/iwlwifi/mvm/debugfs.c | 89 +++++++------------
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 7 +-
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 12 +--
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 8 +-
5 files changed, 38 insertions(+), 95 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c
index 2453ceabf00d..9bf2407c9b4b 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c
@@ -743,9 +743,8 @@ static ssize_t iwl_dbgfs_quota_min_read(struct file *file,
#define MVM_DEBUGFS_READ_WRITE_FILE_OPS(name, bufsz) \
_MVM_DEBUGFS_READ_WRITE_FILE_OPS(name, bufsz, struct ieee80211_vif)
#define MVM_DEBUGFS_ADD_FILE_VIF(name, parent, mode) do { \
- if (!debugfs_create_file(#name, mode, parent, vif, \
- &iwl_dbgfs_##name##_ops)) \
- goto err; \
+ debugfs_create_file(#name, mode, parent, vif, \
+ &iwl_dbgfs_##name##_ops); \
} while (0)
MVM_DEBUGFS_READ_FILE_OPS(mac_params);
@@ -775,12 +774,6 @@ void iwl_mvm_vif_dbgfs_register(struct iwl_mvm *mvm, struct ieee80211_vif *vif)
mvmvif->dbgfs_dir = debugfs_create_dir("iwlmvm", dbgfs_dir);
- if (!mvmvif->dbgfs_dir) {
- IWL_ERR(mvm, "Failed to create debugfs directory under %pd\n",
- dbgfs_dir);
- return;
- }
-
if (iwlmvm_mod_params.power_scheme != IWL_POWER_SCHEME_CAM &&
((vif->type == NL80211_IFTYPE_STATION && !vif->p2p) ||
(vif->type == NL80211_IFTYPE_STATION && vif->p2p)))
@@ -812,12 +805,6 @@ void iwl_mvm_vif_dbgfs_register(struct iwl_mvm *mvm, struct ieee80211_vif *vif)
mvmvif->dbgfs_slink = debugfs_create_symlink(dbgfs_dir->d_name.name,
mvm->debugfs_dir, buf);
- if (!mvmvif->dbgfs_slink)
- IWL_ERR(mvm, "Can't create debugfs symbolic link under %pd\n",
- dbgfs_dir);
- return;
-err:
- IWL_ERR(mvm, "Can't create debugfs entity\n");
}
void iwl_mvm_vif_dbgfs_clean(struct iwl_mvm *mvm, struct ieee80211_vif *vif)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c
index 472d330661d3..d4ff6b44de2c 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c
@@ -1696,9 +1696,8 @@ static ssize_t iwl_dbgfs_d0i3_refs_write(struct iwl_mvm *mvm, char *buf,
#define MVM_DEBUGFS_READ_WRITE_FILE_OPS(name, bufsz) \
_MVM_DEBUGFS_READ_WRITE_FILE_OPS(name, bufsz, struct iwl_mvm)
#define MVM_DEBUGFS_ADD_FILE_ALIAS(alias, name, parent, mode) do { \
- if (!debugfs_create_file(alias, mode, parent, mvm, \
- &iwl_dbgfs_##name##_ops)) \
- goto err; \
+ debugfs_create_file(alias, mode, parent, mvm, \
+ &iwl_dbgfs_##name##_ops); \
} while (0)
#define MVM_DEBUGFS_ADD_FILE(name, parent, mode) \
MVM_DEBUGFS_ADD_FILE_ALIAS(#name, name, parent, mode)
@@ -1709,9 +1708,8 @@ static ssize_t iwl_dbgfs_d0i3_refs_write(struct iwl_mvm *mvm, char *buf,
_MVM_DEBUGFS_READ_WRITE_FILE_OPS(name, bufsz, struct ieee80211_sta)
#define MVM_DEBUGFS_ADD_STA_FILE_ALIAS(alias, name, parent, mode) do { \
- if (!debugfs_create_file(alias, mode, parent, sta, \
- &iwl_dbgfs_##name##_ops)) \
- goto err; \
+ debugfs_create_file(alias, mode, parent, sta, \
+ &iwl_dbgfs_##name##_ops); \
} while (0)
#define MVM_DEBUGFS_ADD_STA_FILE(name, parent, mode) \
MVM_DEBUGFS_ADD_STA_FILE_ALIAS(#name, name, parent, mode)
@@ -2092,13 +2090,9 @@ void iwl_mvm_sta_add_debugfs(struct ieee80211_hw *hw,
if (iwl_mvm_has_tlc_offload(mvm))
MVM_DEBUGFS_ADD_STA_FILE(rs_data, dir, 0400);
-
- return;
-err:
- IWL_ERR(mvm, "Can't create the mvm station debugfs entry\n");
}
-int iwl_mvm_dbgfs_register(struct iwl_mvm *mvm, struct dentry *dbgfs_dir)
+void iwl_mvm_dbgfs_register(struct iwl_mvm *mvm, struct dentry *dbgfs_dir)
{
struct dentry *bcast_dir __maybe_unused;
char buf[100];
@@ -2142,14 +2136,10 @@ int iwl_mvm_dbgfs_register(struct iwl_mvm *mvm, struct dentry *dbgfs_dir)
#endif
MVM_DEBUGFS_ADD_FILE(he_sniffer_params, mvm->debugfs_dir, 0600);
- if (!debugfs_create_bool("enable_scan_iteration_notif",
- 0600,
- mvm->debugfs_dir,
- &mvm->scan_iter_notif_enabled))
- goto err;
- if (!debugfs_create_bool("drop_bcn_ap_mode", 0600,
- mvm->debugfs_dir, &mvm->drop_bcn_ap_mode))
- goto err;
+ debugfs_create_bool("enable_scan_iteration_notif", 0600,
+ mvm->debugfs_dir, &mvm->scan_iter_notif_enabled);
+ debugfs_create_bool("drop_bcn_ap_mode", 0600, mvm->debugfs_dir,
+ &mvm->drop_bcn_ap_mode);
MVM_DEBUGFS_ADD_FILE(uapsd_noagg_bssids, mvm->debugfs_dir, S_IRUSR);
@@ -2157,13 +2147,9 @@ int iwl_mvm_dbgfs_register(struct iwl_mvm *mvm, struct dentry *dbgfs_dir)
if (mvm->fw->ucode_capa.flags & IWL_UCODE_TLV_FLAGS_BCAST_FILTERING) {
bcast_dir = debugfs_create_dir("bcast_filtering",
mvm->debugfs_dir);
- if (!bcast_dir)
- goto err;
- if (!debugfs_create_bool("override", 0600,
- bcast_dir,
- &mvm->dbgfs_bcast_filtering.override))
- goto err;
+ debugfs_create_bool("override", 0600, bcast_dir,
+ &mvm->dbgfs_bcast_filtering.override);
MVM_DEBUGFS_ADD_FILE_ALIAS("filters", bcast_filters,
bcast_dir, 0600);
@@ -2175,35 +2161,26 @@ int iwl_mvm_dbgfs_register(struct iwl_mvm *mvm, struct dentry *dbgfs_dir)
#ifdef CONFIG_PM_SLEEP
MVM_DEBUGFS_ADD_FILE(d3_sram, mvm->debugfs_dir, 0600);
MVM_DEBUGFS_ADD_FILE(d3_test, mvm->debugfs_dir, 0400);
- if (!debugfs_create_bool("d3_wake_sysassert", 0600,
- mvm->debugfs_dir, &mvm->d3_wake_sysassert))
- goto err;
- if (!debugfs_create_u32("last_netdetect_scans", 0400,
- mvm->debugfs_dir, &mvm->last_netdetect_scans))
- goto err;
+ debugfs_create_bool("d3_wake_sysassert", 0600, mvm->debugfs_dir,
+ &mvm->d3_wake_sysassert);
+ debugfs_create_u32("last_netdetect_scans", 0400, mvm->debugfs_dir,
+ &mvm->last_netdetect_scans);
#endif
- if (!debugfs_create_u8("ps_disabled", 0400,
- mvm->debugfs_dir, &mvm->ps_disabled))
- goto err;
- if (!debugfs_create_blob("nvm_hw", 0400,
- mvm->debugfs_dir, &mvm->nvm_hw_blob))
- goto err;
- if (!debugfs_create_blob("nvm_sw", 0400,
- mvm->debugfs_dir, &mvm->nvm_sw_blob))
- goto err;
- if (!debugfs_create_blob("nvm_calib", 0400,
- mvm->debugfs_dir, &mvm->nvm_calib_blob))
- goto err;
- if (!debugfs_create_blob("nvm_prod", 0400,
- mvm->debugfs_dir, &mvm->nvm_prod_blob))
- goto err;
- if (!debugfs_create_blob("nvm_phy_sku", 0400,
- mvm->debugfs_dir, &mvm->nvm_phy_sku_blob))
- goto err;
- if (!debugfs_create_blob("nvm_reg", S_IRUSR,
- mvm->debugfs_dir, &mvm->nvm_reg_blob))
- goto err;
+ debugfs_create_u8("ps_disabled", 0400, mvm->debugfs_dir,
+ &mvm->ps_disabled);
+ debugfs_create_blob("nvm_hw", 0400, mvm->debugfs_dir,
+ &mvm->nvm_hw_blob);
+ debugfs_create_blob("nvm_sw", 0400, mvm->debugfs_dir,
+ &mvm->nvm_sw_blob);
+ debugfs_create_blob("nvm_calib", 0400, mvm->debugfs_dir,
+ &mvm->nvm_calib_blob);
+ debugfs_create_blob("nvm_prod", 0400, mvm->debugfs_dir,
+ &mvm->nvm_prod_blob);
+ debugfs_create_blob("nvm_phy_sku", 0400, mvm->debugfs_dir,
+ &mvm->nvm_phy_sku_blob);
+ debugfs_create_blob("nvm_reg", S_IRUSR,
+ mvm->debugfs_dir, &mvm->nvm_reg_blob);
debugfs_create_file("mem", 0600, dbgfs_dir, mvm, &iwl_dbgfs_mem_ops);
@@ -2212,11 +2189,5 @@ int iwl_mvm_dbgfs_register(struct iwl_mvm *mvm, struct dentry *dbgfs_dir)
* exists (before the opmode exists which removes the target.)
*/
snprintf(buf, 100, "../../%pd2", dbgfs_dir->d_parent);
- if (!debugfs_create_symlink("iwlwifi", mvm->hw->wiphy->debugfsdir, buf))
- goto err;
-
- return 0;
-err:
- IWL_ERR(mvm, "Can't create the mvm debugfs directory\n");
- return -ENOMEM;
+ debugfs_create_symlink("iwlwifi", mvm->hw->wiphy->debugfsdir, buf);
}
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
index 61b6dbc83600..45d7a868e759 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
@@ -1786,14 +1786,13 @@ void iwl_mvm_rx_umac_scan_iter_complete_notif(struct iwl_mvm *mvm,
/* MVM debugfs */
#ifdef CONFIG_IWLWIFI_DEBUGFS
-int iwl_mvm_dbgfs_register(struct iwl_mvm *mvm, struct dentry *dbgfs_dir);
+void iwl_mvm_dbgfs_register(struct iwl_mvm *mvm, struct dentry *dbgfs_dir);
void iwl_mvm_vif_dbgfs_register(struct iwl_mvm *mvm, struct ieee80211_vif *vif);
void iwl_mvm_vif_dbgfs_clean(struct iwl_mvm *mvm, struct ieee80211_vif *vif);
#else
-static inline int iwl_mvm_dbgfs_register(struct iwl_mvm *mvm,
- struct dentry *dbgfs_dir)
+static inline void iwl_mvm_dbgfs_register(struct iwl_mvm *mvm,
+ struct dentry *dbgfs_dir)
{
- return 0;
}
static inline void
iwl_mvm_vif_dbgfs_register(struct iwl_mvm *mvm, struct ieee80211_vif *vif)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/ops.c b/drivers/net/wireless/intel/iwlwifi/mvm/ops.c
index 8e2e4fa7914e..55d399899d1c 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/ops.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/ops.c
@@ -862,9 +862,7 @@ iwl_op_mode_mvm_start(struct iwl_trans *trans, const struct iwl_cfg *cfg,
min_backoff = iwl_mvm_min_backoff(mvm);
iwl_mvm_thermal_initialize(mvm, min_backoff);
- err = iwl_mvm_dbgfs_register(mvm, dbgfs_dir);
- if (err)
- goto out_unregister;
+ iwl_mvm_dbgfs_register(mvm, dbgfs_dir);
if (!iwl_mvm_has_new_rx_stats_api(mvm))
memset(&mvm->rx_stats_v3, 0,
@@ -881,14 +879,6 @@ iwl_op_mode_mvm_start(struct iwl_trans *trans, const struct iwl_cfg *cfg,
return op_mode;
- out_unregister:
- if (iwlmvm_mod_params.init_dbg)
- return op_mode;
-
- ieee80211_unregister_hw(mvm->hw);
- mvm->hw_registered = false;
- iwl_mvm_leds_exit(mvm);
- iwl_mvm_thermal_exit(mvm);
out_free:
iwl_fw_flush_dump(&mvm->fwrt);
iwl_fw_runtime_free(&mvm->fwrt);
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
index e231a44d2423..c182821ab22b 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
@@ -4078,9 +4078,8 @@ static ssize_t iwl_dbgfs_ss_force_write(struct iwl_lq_sta *lq_sta, char *buf,
#define MVM_DEBUGFS_READ_WRITE_FILE_OPS(name, bufsz) \
_MVM_DEBUGFS_READ_WRITE_FILE_OPS(name, bufsz, struct iwl_lq_sta)
#define MVM_DEBUGFS_ADD_FILE_RS(name, parent, mode) do { \
- if (!debugfs_create_file(#name, mode, parent, lq_sta, \
- &iwl_dbgfs_##name##_ops)) \
- goto err; \
+ debugfs_create_file(#name, mode, parent, lq_sta, \
+ &iwl_dbgfs_##name##_ops); \
} while (0)
MVM_DEBUGFS_READ_WRITE_FILE_OPS(ss_force, 32);
@@ -4108,9 +4107,6 @@ static void rs_drv_add_sta_debugfs(void *mvm, void *priv_sta,
&lq_sta->pers.dbg_fixed_txp_reduction);
MVM_DEBUGFS_ADD_FILE_RS(ss_force, dir, 0600);
- return;
-err:
- IWL_ERR((struct iwl_mvm *)mvm, "Can't create debugfs entity\n");
}
void rs_remove_sta_debugfs(void *mvm, void *mvm_sta)
--
2.20.1
^ permalink raw reply related
* [PATCH 21/24] iwlwifi: mvm: use correct GP2 register address for 22000 family
From: Luca Coelho @ 2019-03-22 13:59 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Avraham Stern, Luca Coelho
In-Reply-To: <20190322135903.10631-1-luca@coelho.fi>
From: Avraham Stern <avraham.stern@intel.com>
The device time register address has changed for 22000 devices.
Add a util function for getting the GP2 time and use the correct
register address depending on the device family.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/cfg/22000.c | 6 ++++--
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 4 +---
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 4 ++--
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/tdls.c | 7 +++----
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 12 +++++++++++-
7 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/cfg/22000.c b/drivers/net/wireless/intel/iwlwifi/cfg/22000.c
index 33c95663914d..e0db1988b6a3 100644
--- a/drivers/net/wireless/intel/iwlwifi/cfg/22000.c
+++ b/drivers/net/wireless/intel/iwlwifi/cfg/22000.c
@@ -194,7 +194,8 @@ static const struct iwl_ht_params iwl_22000_ht_params = {
IWL_DEVICE_22000_COMMON, \
.device_family = IWL_DEVICE_FAMILY_22000, \
.base_params = &iwl_22000_base_params, \
- .csr = &iwl_csr_v1
+ .csr = &iwl_csr_v1, \
+ .gp2_reg_addr = 0xa02c68
#define IWL_DEVICE_22560 \
IWL_DEVICE_22000_COMMON, \
@@ -207,7 +208,8 @@ static const struct iwl_ht_params iwl_22000_ht_params = {
.device_family = IWL_DEVICE_FAMILY_AX210, \
.base_params = &iwl_22000_base_params, \
.csr = &iwl_csr_v1, \
- .min_txq_size = 128
+ .min_txq_size = 128, \
+ .gp2_reg_addr = 0xd02c68
const struct iwl_cfg iwl22000_2ac_cfg_hr = {
.name = "Intel(R) Dual Band Wireless AC 22000",
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-config.h b/drivers/net/wireless/intel/iwlwifi/iwl-config.h
index 76c1e44b7bdc..bc929d6639bd 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-config.h
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-config.h
@@ -456,6 +456,7 @@ struct iwl_cfg {
u32 fw_mon_smem_write_ptr_msk;
u32 fw_mon_smem_cycle_cnt_ptr_addr;
u32 fw_mon_smem_cycle_cnt_ptr_msk;
+ u32 gp2_reg_addr;
};
extern const struct iwl_csr_params iwl_csr_v1;
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
index 76bf7fbc0446..fcec25b7b679 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
@@ -1113,9 +1113,7 @@ static void iwl_mvm_mac_ctxt_cmd_fill_ap(struct iwl_mvm *mvm,
ieee80211_tu_to_usec(data.beacon_int * rand /
100);
} else {
- mvmvif->ap_beacon_time =
- iwl_read_prph(mvm->trans,
- DEVICE_SYSTEM_TIME_REG);
+ mvmvif->ap_beacon_time = iwl_mvm_get_systime(mvm);
}
}
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index ed866deddb5f..d55c7df813e3 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -3730,7 +3730,7 @@ static int iwl_mvm_send_aux_roc_cmd(struct iwl_mvm *mvm,
struct ieee80211_vif *vif,
int duration)
{
- int res, time_reg = DEVICE_SYSTEM_TIME_REG;
+ int res;
struct iwl_mvm_vif *mvmvif = iwl_mvm_vif_from_mac80211(vif);
struct iwl_mvm_time_event_data *te_data = &mvmvif->hs_time_event_data;
static const u16 time_event_response[] = { HOT_SPOT_CMD };
@@ -3756,7 +3756,7 @@ static int iwl_mvm_send_aux_roc_cmd(struct iwl_mvm *mvm,
0);
/* Set the time and duration */
- tail->apply_time = cpu_to_le32(iwl_read_prph(mvm->trans, time_reg));
+ tail->apply_time = cpu_to_le32(iwl_mvm_get_systime(mvm));
delay = AUX_ROC_MIN_DELAY;
req_dur = MSEC_TO_TU(duration);
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
index 45d7a868e759..cdac510fd22b 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
@@ -1539,6 +1539,7 @@ void iwl_mvm_dump_nic_error_log(struct iwl_mvm *mvm);
u8 first_antenna(u8 mask);
u8 iwl_mvm_next_antenna(struct iwl_mvm *mvm, u8 valid, u8 last_idx);
void iwl_mvm_get_sync_time(struct iwl_mvm *mvm, u32 *gp2, u64 *boottime);
+u32 iwl_mvm_get_systime(struct iwl_mvm *mvm);
/* Tx / Host Commands */
int __must_check iwl_mvm_send_cmd(struct iwl_mvm *mvm,
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tdls.c b/drivers/net/wireless/intel/iwlwifi/mvm/tdls.c
index 859aa5a4e6b5..9df21a8d1fc1 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tdls.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tdls.c
@@ -7,7 +7,7 @@
*
* Copyright(c) 2014 Intel Mobile Communications GmbH
* Copyright(c) 2017 Intel Deutschland GmbH
- * Copyright(C) 2018 Intel Corporation
+ * Copyright(C) 2018 - 2019 Intel Corporation
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of version 2 of the GNU General Public License as
@@ -29,7 +29,7 @@
*
* Copyright(c) 2014 Intel Mobile Communications GmbH
* Copyright(c) 2017 Intel Deutschland GmbH
- * Copyright(C) 2018 Intel Corporation
+ * Copyright(C) 2018 - 2019 Intel Corporation
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -252,8 +252,7 @@ static void iwl_mvm_tdls_update_cs_state(struct iwl_mvm *mvm,
/* we only send requests to our switching peer - update sent time */
if (state == IWL_MVM_TDLS_SW_REQ_SENT)
- mvm->tdls_cs.peer.sent_timestamp =
- iwl_read_prph(mvm->trans, DEVICE_SYSTEM_TIME_REG);
+ mvm->tdls_cs.peer.sent_timestamp = iwl_mvm_get_systime(mvm);
if (state == IWL_MVM_TDLS_SW_IDLE)
mvm->tdls_cs.cur_sta_id = IWL_MVM_INVALID_STA;
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/utils.c b/drivers/net/wireless/intel/iwlwifi/mvm/utils.c
index 4649327abb45..b9914efc55c4 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/utils.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/utils.c
@@ -1418,6 +1418,16 @@ void iwl_mvm_tcm_rm_vif(struct iwl_mvm *mvm, struct ieee80211_vif *vif)
cancel_delayed_work_sync(&mvmvif->uapsd_nonagg_detected_wk);
}
+u32 iwl_mvm_get_systime(struct iwl_mvm *mvm)
+{
+ u32 reg_addr = DEVICE_SYSTEM_TIME_REG;
+
+ if (mvm->trans->cfg->device_family >= IWL_DEVICE_FAMILY_22000 &&
+ mvm->trans->cfg->gp2_reg_addr)
+ reg_addr = mvm->trans->cfg->gp2_reg_addr;
+
+ return iwl_read_prph(mvm->trans, reg_addr);
+}
void iwl_mvm_get_sync_time(struct iwl_mvm *mvm, u32 *gp2, u64 *boottime)
{
@@ -1432,7 +1442,7 @@ void iwl_mvm_get_sync_time(struct iwl_mvm *mvm, u32 *gp2, u64 *boottime)
iwl_mvm_power_update_device(mvm);
}
- *gp2 = iwl_read_prph(mvm->trans, DEVICE_SYSTEM_TIME_REG);
+ *gp2 = iwl_mvm_get_systime(mvm);
*boottime = ktime_get_boot_ns();
if (!ps_disabled) {
--
2.20.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