RE: [EXT] Re: [PATCH] mwifiex: Random MAC address during scanning

[Ganapathi Bhat]

Hi Kalle,
>
> > --
> > On Fri, Sep 29, 2017 at 04:23:10PM +0530, Ganapathi Bhat wrote:
> > > From: Karthik Ananthapadmanabha 
> > >
> > > Driver will advertise RANDOM_MAC support only if the device supports
> > > this feature.
> > >
> > > Signed-off-by: Karthik Ananthapadmanabha 
> > > Signed-off-by: Ganapathi Bhat 
> >
> > I'd just like to point out that this is a very bad commit subject:
> >
> > "[PATCH] mwifiex: Random MAC address during scanning"
> >
> > It's borderline wrong, really. "Random MAC address during scanning" is
> > already supported. This patch is just adding a feature-flag check for
> > it, since some firmwares in the wild don't support it. A more accurate
> > description would be something like:
> >
> > "[PATCH] mwifiex: Add feature flag support for MAC randomization"
> >
> > The patch is already applied, so I'd only worry about it for future
> > submissions (no need to resend).
>
> I'm Really Sorry.  I will take care of this in future.
>
The firmware which advertises this capability flag is yet to be shared in 
upstream. The latest available firmware does not contain this flag.
So, is it possible to revert this change, so that we will resubmit this (with 
proper subject) once our firmware is uploaded.
> >
> > Brian

Regards,
Ganapathi

RE: [EXT] Re: [PATCH] mwifiex: Random MAC address during scanning

[Ganapathi Bhat]

Hi Brian,

> --
> On Fri, Sep 29, 2017 at 04:23:10PM +0530, Ganapathi Bhat wrote:
> > From: Karthik Ananthapadmanabha 
> >
> > Driver will advertise RANDOM_MAC support only if the device supports
> > this feature.
> >
> > Signed-off-by: Karthik Ananthapadmanabha 
> > Signed-off-by: Ganapathi Bhat 
>
> I'd just like to point out that this is a very bad commit subject:
>
> "[PATCH] mwifiex: Random MAC address during scanning"
>
> It's borderline wrong, really. "Random MAC address during scanning" is
> already supported. This patch is just adding a feature-flag check for it, 
> since
> some firmwares in the wild don't support it. A more accurate description
> would be something like:
>
> "[PATCH] mwifiex: Add feature flag support for MAC randomization"
>
> The patch is already applied, so I'd only worry about it for future 
> submissions
> (no need to resend).

I'm Really Sorry.  I will take care of this in future.

>
> Brian

Re: [PATCH] rtl8xxxu: mark expected switch fall-throughs

[Kalle Valo]

Jes Sorensen  writes:

> On 10/11/2017 04:41 AM, Kalle Valo wrote:
>> Jes Sorensen  writes:
>>
>>> On 10/10/2017 03:30 PM, Gustavo A. R. Silva wrote:
 In preparation to enabling -Wimplicit-fallthrough, mark switch cases
 where we are expecting to fall through.
>>>
>>> While this isn't harmful, to me this looks like pointless patch churn
>>> for zero gain and it's just ugly.
>>
>> In general I find it useful to mark fall through cases. And it's just a
>> comment with two words, so they cannot hurt your eyes that much.
>
> I don't see them being harmful in the code, but I don't see them of
> much use either. If it happened as part of natural code development,
> fine. My objection is to people running around doing this
> systematically causing patch churn for little to zero gain.

We do receive quite a lot these kind of cleanup patches found with
various analysers and tools. I guess one could classify those as churn
but I think the net result is still very much on the positive side. And
this patch in particular seems useful for me and I think we should take
it.

-- 
Kalle Valo

Re: [PATCH] ath10k: fix core PCI suspend when WoWLAN is supported but disabled

[Kalle Valo]

Brian Norris  writes:

> Ping? Any comments? I know there's more than one way to slice this
> problem, but it's most definitely a problem...

I'm lagging behind with patches but I'll try to catch up this week.
Sorry.

-- 
Kalle Valo

Re: [PATCH] ath10k: fix core PCI suspend when WoWLAN is supported but disabled

[Adrian Chadd]

fwiw - I did this on my in progress ath10k port to freebsd, and I've
tested it on Rome and Peregrine. It seems to be the right thing to do
during suspend to at least cleanly shut things down.


-adrian


On 11 October 2017 at 17:38, Brian Norris  wrote:
> Ping? Any comments? I know there's more than one way to slice this
> problem, but it's most definitely a problem...
>
> Brian
>
> On Tue, Sep 19, 2017 at 04:24:16PM -0700, Brian Norris wrote:
>> For devices where the FW supports WoWLAN but user-space has not
>> configured it, we don't do any PCI-specific suspend/resume operations,
>> because mac80211 doesn't call drv_suspend() when !wowlan. This has
>> particularly bad effects for some platforms, because we don't stop the
>> power-save timer, and if this timer goes off after the PCI controller
>> has suspended the link, Bad Things will happen.
>>
>> Commit 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops")
>> got some of this right, in that it understood there was a problem on
>> non-WoWLAN firmware. But it forgot the $subject case.
>>
>> Fix this by moving all the PCI driver suspend/resume logic exclusively
>> into the driver PM hooks. This shouldn't affect WoWLAN support much
>> (this just gets executed later on).
>>
>> I would just as well kill the entirety of ath10k_hif_suspend(), as it's
>> not even implemented on the USB or SDIO drivers. I expect that we don't
>> need the callback, except to return "supported" (i.e., 0) or "not
>> supported" (i.e., -EOPNOTSUPP).
>>
>> Fixes: 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops")
>> Fixes: 77258d409ce4 ("ath10k: enable pci soc powersaving")
>> Signed-off-by: Brian Norris 
>> Cc: Ryan Hsu 
>> Cc: Kalle Valo 
>> Cc: Michal Kazior 
>> ---
>>  drivers/net/wireless/ath/ath10k/pci.c | 24 ++--
>>  1 file changed, 14 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/pci.c 
>> b/drivers/net/wireless/ath/ath10k/pci.c
>> index bc1633945a56..4655c944e3fd 100644
>> --- a/drivers/net/wireless/ath/ath10k/pci.c
>> +++ b/drivers/net/wireless/ath/ath10k/pci.c
>> @@ -2580,6 +2580,12 @@ void ath10k_pci_hif_power_down(struct ath10k *ar)
>>  #ifdef CONFIG_PM
>>
>>  static int ath10k_pci_hif_suspend(struct ath10k *ar)
>> +{
>> + /* Nothing to do; the important stuff is in the driver suspend. */
>> + return 0;
>> +}
>> +
>> +static int ath10k_pci_suspend(struct ath10k *ar)
>>  {
>>   /* The grace timer can still be counting down and ar->ps_awake be true.
>>* It is known that the device may be asleep after resuming regardless
>> @@ -2592,6 +2598,12 @@ static int ath10k_pci_hif_suspend(struct ath10k *ar)
>>  }
>>
>>  static int ath10k_pci_hif_resume(struct ath10k *ar)
>> +{
>> + /* Nothing to do; the important stuff is in the driver resume. */
>> + return 0;
>> +}
>> +
>> +static int ath10k_pci_resume(struct ath10k *ar)
>>  {
>>   struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
>>   struct pci_dev *pdev = ar_pci->pdev;
>> @@ -3403,11 +3415,7 @@ static int ath10k_pci_pm_suspend(struct device *dev)
>>   struct ath10k *ar = dev_get_drvdata(dev);
>>   int ret;
>>
>> - if (test_bit(ATH10K_FW_FEATURE_WOWLAN_SUPPORT,
>> -  ar->running_fw->fw_file.fw_features))
>> - return 0;
>> -
>> - ret = ath10k_hif_suspend(ar);
>> + ret = ath10k_pci_suspend(ar);
>>   if (ret)
>>   ath10k_warn(ar, "failed to suspend hif: %d\n", ret);
>>
>> @@ -3419,11 +3427,7 @@ static int ath10k_pci_pm_resume(struct device *dev)
>>   struct ath10k *ar = dev_get_drvdata(dev);
>>   int ret;
>>
>> - if (test_bit(ATH10K_FW_FEATURE_WOWLAN_SUPPORT,
>> -  ar->running_fw->fw_file.fw_features))
>> - return 0;
>> -
>> - ret = ath10k_hif_resume(ar);
>> + ret = ath10k_pci_resume(ar);
>>   if (ret)
>>   ath10k_warn(ar, "failed to resume hif: %d\n", ret);
>>
>> --
>> 2.14.1.690.gbb1197296e-goog
>>

Re: [PATCH] ath10k: fix core PCI suspend when WoWLAN is supported but disabled

[Brian Norris]

Ping? Any comments? I know there's more than one way to slice this
problem, but it's most definitely a problem...

Brian

On Tue, Sep 19, 2017 at 04:24:16PM -0700, Brian Norris wrote:
> For devices where the FW supports WoWLAN but user-space has not
> configured it, we don't do any PCI-specific suspend/resume operations,
> because mac80211 doesn't call drv_suspend() when !wowlan. This has
> particularly bad effects for some platforms, because we don't stop the
> power-save timer, and if this timer goes off after the PCI controller
> has suspended the link, Bad Things will happen.
> 
> Commit 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops")
> got some of this right, in that it understood there was a problem on
> non-WoWLAN firmware. But it forgot the $subject case.
> 
> Fix this by moving all the PCI driver suspend/resume logic exclusively
> into the driver PM hooks. This shouldn't affect WoWLAN support much
> (this just gets executed later on).
> 
> I would just as well kill the entirety of ath10k_hif_suspend(), as it's
> not even implemented on the USB or SDIO drivers. I expect that we don't
> need the callback, except to return "supported" (i.e., 0) or "not
> supported" (i.e., -EOPNOTSUPP).
> 
> Fixes: 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops")
> Fixes: 77258d409ce4 ("ath10k: enable pci soc powersaving")
> Signed-off-by: Brian Norris 
> Cc: Ryan Hsu 
> Cc: Kalle Valo 
> Cc: Michal Kazior 
> ---
>  drivers/net/wireless/ath/ath10k/pci.c | 24 ++--
>  1 file changed, 14 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath10k/pci.c 
> b/drivers/net/wireless/ath/ath10k/pci.c
> index bc1633945a56..4655c944e3fd 100644
> --- a/drivers/net/wireless/ath/ath10k/pci.c
> +++ b/drivers/net/wireless/ath/ath10k/pci.c
> @@ -2580,6 +2580,12 @@ void ath10k_pci_hif_power_down(struct ath10k *ar)
>  #ifdef CONFIG_PM
>  
>  static int ath10k_pci_hif_suspend(struct ath10k *ar)
> +{
> + /* Nothing to do; the important stuff is in the driver suspend. */
> + return 0;
> +}
> +
> +static int ath10k_pci_suspend(struct ath10k *ar)
>  {
>   /* The grace timer can still be counting down and ar->ps_awake be true.
>* It is known that the device may be asleep after resuming regardless
> @@ -2592,6 +2598,12 @@ static int ath10k_pci_hif_suspend(struct ath10k *ar)
>  }
>  
>  static int ath10k_pci_hif_resume(struct ath10k *ar)
> +{
> + /* Nothing to do; the important stuff is in the driver resume. */
> + return 0;
> +}
> +
> +static int ath10k_pci_resume(struct ath10k *ar)
>  {
>   struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
>   struct pci_dev *pdev = ar_pci->pdev;
> @@ -3403,11 +3415,7 @@ static int ath10k_pci_pm_suspend(struct device *dev)
>   struct ath10k *ar = dev_get_drvdata(dev);
>   int ret;
>  
> - if (test_bit(ATH10K_FW_FEATURE_WOWLAN_SUPPORT,
> -  ar->running_fw->fw_file.fw_features))
> - return 0;
> -
> - ret = ath10k_hif_suspend(ar);
> + ret = ath10k_pci_suspend(ar);
>   if (ret)
>   ath10k_warn(ar, "failed to suspend hif: %d\n", ret);
>  
> @@ -3419,11 +3427,7 @@ static int ath10k_pci_pm_resume(struct device *dev)
>   struct ath10k *ar = dev_get_drvdata(dev);
>   int ret;
>  
> - if (test_bit(ATH10K_FW_FEATURE_WOWLAN_SUPPORT,
> -  ar->running_fw->fw_file.fw_features))
> - return 0;
> -
> - ret = ath10k_hif_resume(ar);
> + ret = ath10k_pci_resume(ar);
>   if (ret)
>   ath10k_warn(ar, "failed to resume hif: %d\n", ret);
>  
> -- 
> 2.14.1.690.gbb1197296e-goog
> 

Re: [PATCH 2/3] rsi: sdio: Add WOWLAN support for S4 hibernate state

[Brian Norris]

Hi Amitkumar,

On Wed, Oct 11, 2017 at 12:24:17PM +0300, Kalle Valo wrote:
> Amitkumar Karwar  writes:
> > On Tue, Sep 26, 2017 at 3:27 PM, Kalle Valo  wrote:
> >> And even if that would be the right approach it needs to be properly
> >> described in the commit log, a vague sentence in the end of a commit log
> >> is not enough.
> >
> > Understood. I will add detailed description and send updated version
> > if the patch is fine.
> 
> Not sure if this is fine or not. I think what you do here is ugly but I
> guess it's better than nothing?

I don't see why you can't try to reuse the existing mac80211 reset;
seems like you'd need to factor out some pieces of rsi_reset_card() and
call that from the ieee80211_ops::start() method. Then, you just call
ieee80211_restart_hw() from the appropriate place, instead of
implementing your own tear-down/reset.

Brian

[PATCH] rtlwifi: Remove unused cur_rfstate variables

[Christos Gkekas]

Clean up unused cur_rfstate variables in rtl8188ee, rtl8723ae, rtl8723be
and rtl8821ae.

Signed-off-by: Christos Gkekas 
---
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c | 4 +---
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 4 +---
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 4 +---
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 4 +---
 4 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
index 0ba26d2..4d843e6 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
@@ -2235,7 +2235,7 @@ bool rtl88ee_gpio_radio_on_off_checking(struct 
ieee80211_hw *hw, u8 *valid)
 {
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
-   enum rf_pwrstate e_rfpowerstate_toset, cur_rfstate;
+   enum rf_pwrstate e_rfpowerstate_toset;
u32 u4tmp;
bool b_actuallyset = false;
 
@@ -2254,8 +2254,6 @@ bool rtl88ee_gpio_radio_on_off_checking(struct 
ieee80211_hw *hw, u8 *valid)
spin_unlock(>locks.rf_ps_lock);
}
 
-   cur_rfstate = ppsc->rfpwr_state;
-
u4tmp = rtl_read_dword(rtlpriv, REG_GPIO_OUTPUT);
e_rfpowerstate_toset = (u4tmp & BIT(31)) ? ERFON : ERFOFF;
 
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
index 5ac7b81..4e1e1f8 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
@@ -2103,7 +2103,7 @@ bool rtl8723e_gpio_radio_on_off_checking(struct 
ieee80211_hw *hw, u8 *valid)
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
struct rtl_phy *rtlphy = &(rtlpriv->phy);
-   enum rf_pwrstate e_rfpowerstate_toset, cur_rfstate;
+   enum rf_pwrstate e_rfpowerstate_toset;
u8 u1tmp;
bool b_actuallyset = false;
 
@@ -2122,8 +2122,6 @@ bool rtl8723e_gpio_radio_on_off_checking(struct 
ieee80211_hw *hw, u8 *valid)
spin_unlock(>locks.rf_ps_lock);
}
 
-   cur_rfstate = ppsc->rfpwr_state;
-
rtl_write_byte(rtlpriv, REG_GPIO_IO_SEL_2,
   rtl_read_byte(rtlpriv, REG_GPIO_IO_SEL_2)&~(BIT(1)));
 
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
index 4d47b97..2ad1013 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
@@ -2486,7 +2486,7 @@ bool rtl8723be_gpio_radio_on_off_checking(struct 
ieee80211_hw *hw, u8 *valid)
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
struct rtl_phy *rtlphy = &(rtlpriv->phy);
-   enum rf_pwrstate e_rfpowerstate_toset, cur_rfstate;
+   enum rf_pwrstate e_rfpowerstate_toset;
u8 u1tmp;
bool b_actuallyset = false;
 
@@ -2505,8 +2505,6 @@ bool rtl8723be_gpio_radio_on_off_checking(struct 
ieee80211_hw *hw, u8 *valid)
spin_unlock(>locks.rf_ps_lock);
}
 
-   cur_rfstate = ppsc->rfpwr_state;
-
rtl_write_byte(rtlpriv, REG_GPIO_IO_SEL_2,
   rtl_read_byte(rtlpriv, REG_GPIO_IO_SEL_2) & ~(BIT(1)));
 
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
index 1d431d4..e756f94 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
@@ -3845,7 +3845,7 @@ bool rtl8821ae_gpio_radio_on_off_checking(struct 
ieee80211_hw *hw, u8 *valid)
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
struct rtl_phy *rtlphy = >phy;
-   enum rf_pwrstate e_rfpowerstate_toset, cur_rfstate;
+   enum rf_pwrstate e_rfpowerstate_toset;
u8 u1tmp = 0;
bool b_actuallyset = false;
 
@@ -3864,8 +3864,6 @@ bool rtl8821ae_gpio_radio_on_off_checking(struct 
ieee80211_hw *hw, u8 *valid)
spin_unlock(>locks.rf_ps_lock);
}
 
-   cur_rfstate = ppsc->rfpwr_state;
-
rtl_write_byte(rtlpriv, REG_GPIO_IO_SEL_2,
rtl_read_byte(rtlpriv,
REG_GPIO_IO_SEL_2) & ~(BIT(1)));
-- 
2.7.4

Re: [PATCH] [net-next]NFC: Convert timers to use timer_setup()

[Allen]

Switch to using the new timer_setup() and from_timer()
for net/nfc/*

Signed-off-by: Allen Pais 
---
---
  net/nfc/core.c  |  8 +++-
  net/nfc/hci/core.c  |  7 +++
  net/nfc/hci/llc_shdlc.c | 23 +--
  net/nfc/llcp_core.c | 14 ++
  4 files changed, 21 insertions(+), 31 deletions(-)



 My bad, I missed the Reviewed-by.

Reviewed-by: Kees Cook 

- Allen

Re: [PATCH] mwifiex: Random MAC address during scanning

[Brian Norris]

On Fri, Sep 29, 2017 at 04:23:10PM +0530, Ganapathi Bhat wrote:
> From: Karthik Ananthapadmanabha 
> 
> Driver will advertise RANDOM_MAC support only if the device
> supports this feature.
> 
> Signed-off-by: Karthik Ananthapadmanabha 
> Signed-off-by: Ganapathi Bhat 

I'd just like to point out that this is a very bad commit subject:

"[PATCH] mwifiex: Random MAC address during scanning"

It's borderline wrong, really. "Random MAC address during scanning" is
already supported. This patch is just adding a feature-flag check for
it, since some firmwares in the wild don't support it. A more accurate
description would be something like:

"[PATCH] mwifiex: Add feature flag support for MAC randomization"

The patch is already applied, so I'd only worry about it for future
submissions (no need to resend).

Brian

Atheros TL-721N adapter refuses to enumerate on the USB Bus (ath9k_htc)

[M D]

Hi,
My system details are as follows

Hardware:
CPU  :  ARM based platform, imx21
USB   : USB Host Controller 1.1 Full Speed Mode

Software:
Firmware  :  /lib/firmware/htc_9271.fw
(version 1.3 / version 1.4)
Device Driver   :  Backports (v3.12.8-1)
OS:  Linux Kernel 3.0.101, ARM
Freescale IMX21ADS

Problem Statement:

-The WiFi adapter is connected directly to the USB Port and is
configured in Full Speed mode
-After it is plugged in, it is enumerated on the Bus (that is,
executing the instruction lsusb shows the vendor and product
information)
-After repeated reboots, after one random reboot the issue
occurs. (usually 1 out of 5 times) the wlan0 node does not come up
-When the issue occurs the following details below describe
the issue at best


1)  The adapter is visible on the USB bus (adapter gets enumerated)
2)  The required modules are loaded
3)  However the wireless networking node, wlan0 does not come up
4)  One of the threads created during the init goes into a D state

root   1024  0.0  0.0  0 0 ?D11:06   0:00
[firmware/htc_92]

In the file drivers/net/wireless/ath/ath9k/hif_usb.c
[

hif_usb.c
...

ret = request_firmware_nowait(THIS_MODULE, true, hif_dev->fw_name,
  _dev->udev->dev, GFP_KERNEL,
  hif_dev, ath9k_hif_usb_firmware_cb);


compat_firmware_class.c
...
task = kthread_run(request_firmware_work_func, fw_work,
"firmware/%s", name);
]


5) This is recoverable only after manually unplugging out the Adapter.

ROOT CAUSE OF THE ISSUE:
6) The underlying cause is due to the wifi adapter being configured in
FULL SPEED mode. Due to this the endpoints 3 and 4 get configured as
BULK and not INT.


After some investigation, I made the following changes which helps to
recover the adapter when the issue occurs,

--- 
../original-backports/backports-3.12.8-1/drivers/net/wireless/ath/ath9k/hif_usb.c
  2017-10-11 10:50:05.043241000 -0700
+++ drivers/net/wireless/ath/ath9k/hif_usb.c2017-10-11
10:50:03.154255000 -0700
@@ -24,6 +24,8 @@
 MODULE_FIRMWARE(FIRMWARE_AR7010_1_1);
 MODULE_FIRMWARE(FIRMWARE_AR9271);

+static void ath9k_hif_usb_reboot(struct usb_device *udev);
+

@@ -1189,7 +1193,12 @@
 {
struct usb_device *udev = interface_to_usbdev(interface);
struct hif_device_usb *hif_dev;
-   int ret = 0;
+
+struct usb_host_interface *alt ;
+struct usb_endpoint_descriptor *endp;
+
+   int ret;
+   int idx, EP = 0;

if (id->driver_info == STORAGE_DEVICE)
return send_eject_command(interface);
@@ -1212,6 +1221,44 @@

init_completion(_dev->fw_done);

+   alt = _dev->interface->altsetting[0];
+
+
+   for (idx = 0; idx < alt->desc.bNumEndpoints; idx++) {
+endp = >endpoint[idx].desc;
+EP = idx + 1;
+printk (KERN_ALERT "EndPoint %d is conf as %d\n", EP,
(endp->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK));
+   /* First FIX EP3. EP3 should never show up as BULK.
+  If it does we have a serious problem.
+   */
+
+   if (endp->bEndpointAddress==0x83){
+  if ((endp->bmAttributes &
USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_BULK) {
+   endp->bmAttributes |= USB_ENDPOINT_XFER_INT;
+   endp->bInterval = 1;
+   ath9k_hif_usb_reboot(hif_dev->udev);
+   mdelay(1000);
+   ret = usb_reset_device(hif_dev->udev);
+   mdelay(1000);
+if (ret)
+   return ret;
+   }
+   }
+
+if (endp->bEndpointAddress==0x04){
+   if ((endp->bmAttributes &
USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_BULK) {
+endp->bmAttributes |= USB_ENDPOINT_XFER_INT;
+endp->bInterval = 1;
+   ath9k_hif_usb_reboot(hif_dev->udev);
+   mdelay(1000);
+   ret = usb_reset_device(hif_dev->udev);
+   mdelay(1000);
+   if (ret)
+   return ret;
+  }
+   }
+   }
+
/* Find out which firmware to load */

if (IS_AR7010_DEVICE(id->driver_info))



I see the following output in dmesg

EndPoint 1 is conf as 2
EndPoint 2 is conf as 2
EndPoint 3 is conf as 2
usb 1-2: reset full speed USB device number 2 using imx21-hcd
usb 1-2: device firmware changed
usb 1-2: USB disconnect, device number 2
usbcore: registered new interface driver ath9k_htc
usb 1-2: new full speed USB device number 3 using imx21-hcd
EndPoint 1 is conf as 2
EndPoint 2 is conf as 2
EndPoint 3 is conf as 3
EndPoint 4 is conf as 2
usb 1-2: reset full speed USB device 

Re: [PATCH] rtl8xxxu: mark expected switch fall-throughs

[Joe Perches]

On Wed, 2017-10-11 at 12:54 +, David Laight wrote:
> From: Joe Perches
> > Sent: 11 October 2017 11:21
> > On Tue, 2017-10-10 at 14:30 -0500, Gustavo A. R. Silva wrote:
> > > In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> > > where we are expecting to fall through.
> > 
> > perhaps use Arnaldo's idea:
> > 
> > https://lkml.org/lkml/2017/2/9/845
> > https://lkml.org/lkml/2017/2/10/485
> 
> gah, that is even uglier and requires a chase through
> headers to find out what it means.

Sure, if you think __fallthrough; isn't self-documenting.

case foo;
bar;
__fallthrough;
case baz;
etc...

Re: pull-request: mac80211-next 2017-10-11

[David Miller]

From: Johannes Berg 
Date: Wed, 11 Oct 2017 14:36:12 +0200

> Here's a -next pull request. The only bigger thing here is the
> addition of the regulatory database as firmware, which will
> allow us to - over time - get rid of CRDA, as well as having
> the option of adding more fields to the database where needed,
> this would've been extremely complex with CRDA because it had
> not been built with extensibility in mind.
> 
> Please pull and let me know if there's any problem.

Pulled, thanks!

Re: [PATCH] rtl8xxxu: mark expected switch fall-throughs

[Kees Cook]

On Wed, Oct 11, 2017 at 7:32 AM, Gustavo A. R. Silva
 wrote:
> Quoting Jes Sorensen :
>> On 10/11/2017 04:41 AM, Kalle Valo wrote:
>>> Jes Sorensen  writes:
 On 10/10/2017 03:30 PM, Gustavo A. R. Silva wrote:
>
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.

 While this isn't harmful, to me this looks like pointless patch churn
 for zero gain and it's just ugly.
>>>
>>> In general I find it useful to mark fall through cases. And it's just a
>>> comment with two words, so they cannot hurt your eyes that much.
>>
>> I don't see them being harmful in the code, but I don't see them of much
>> use either. If it happened as part of natural code development, fine. My
>> objection is to people running around doing this systematically causing
>> patch churn for little to zero gain.
>
> I understand that you think this is of zero gain for you, but as Florian
> Fainelli pointed out:
>
> "That is the canonical way to tell static analyzers and compilers that
> fall throughs are wanted and not accidental mistakes in the code. For
> people that deal with these kinds of errors, it's quite helpful, unless
> you suggest disabling that particular GCC warning specific for that
> file/directory?"
>
> this is very helpful for people working on fixing issues reported by static
> analyzers. It saves a huge amount of time when dealing with False Positives.
> Also, there are cases when an apparently intentional fall-through turns out
> to be an actual missing break or continue.
>
> So there is an ongoing effort to detect such cases and avoid them to show up
> in the future by at least warning people about a potential issue in their
> code. And this is helpful for everybody.

This is an unfortunate omission in the C language, and thankfully both
gcc and clang have stepped up to solve this the same way static
analyzers have solved it. It's not exactly pretty, but it does both
document the intention for humans and provide a way for analyzers to
report issues. Having the compiler help us not make mistakes is quite
handy, and with Gustavo grinding through all the Coverity warnings,
he's found actual bugs with missing "break"s, so I think this has a
demonstrable benefit to the code-base as a whole. It makes things
unambiguous to someone else reviewing the code.

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH] rtl8xxxu: mark expected switch fall-throughs

[Gustavo A. R. Silva]

Hi Jes,

Quoting Jes Sorensen :


On 10/11/2017 04:41 AM, Kalle Valo wrote:

Jes Sorensen  writes:


On 10/10/2017 03:30 PM, Gustavo A. R. Silva wrote:

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.


While this isn't harmful, to me this looks like pointless patch churn
for zero gain and it's just ugly.


In general I find it useful to mark fall through cases. And it's just a
comment with two words, so they cannot hurt your eyes that much.


I don't see them being harmful in the code, but I don't see them of  
much use either. If it happened as part of natural code development,  
fine. My objection is to people running around doing this  
systematically causing patch churn for little to zero gain.


Jes



I understand that you think this is of zero gain for you, but as  
Florian Fainelli pointed out:


"That is the canonical way to tell static analyzers and compilers that
fall throughs are wanted and not accidental mistakes in the code. For
people that deal with these kinds of errors, it's quite helpful, unless
you suggest disabling that particular GCC warning specific for that
file/directory?"

this is very helpful for people working on fixing issues reported by  
static analyzers. It saves a huge amount of time when dealing with  
False Positives. Also, there are cases when an apparently intentional  
fall-through turns out to be an actual missing break or continue.


So there is an ongoing effort to detect such cases and avoid them to  
show up in the future by at least warning people about a potential  
issue in their code. And this is helpful for everybody.


Thanks
--
Gustavo A. R. Silva

Re: Setting single rate in ath10k broken by "reject/clear user rate mask if not usable"

[Ben Greear]

On 10/11/2017 01:02 AM, Johannes Berg wrote:

Hi,


#iw dev vap206 set bitrates legacy-5 ht-mcs-5 0 vht-mcs-5
command failed: Invalid argument (-22)

But, it actually *does* successfully set the rate in the driver
first, which is confusing at best.


Huh?


The call to set the rate in the driver comes before the error
check.

if (ieee80211_hw_check(>hw, HAS_RATE_CONTROL)) {
ret = drv_set_bitrate_mask(local, sdata, mask);
if (ret) {
pr_err("%s: drv-set-bitrate-mask had error return: 
%d\n",
   sdata->dev->name, ret);
return ret;
}
}

/*
 * If active validate the setting and reject it if it doesn't leave
 * at least one basic rate usable, since we really have to be able
 * to send something, and if we're an AP we have to be able to do
 * so at a basic rate so that all clients can receive it.
 */
if (rcu_access_pointer(sdata->vif.chanctx_conf) &&
sdata->vif.bss_conf.chandef.chan) {
u32 basic_rates = sdata->vif.bss_conf.basic_rates;
enum nl80211_band band = sdata->vif.bss_conf.chandef.chan->band;

if (!(mask->control[band].legacy & basic_rates)) {
 I changed this code so I could set a single 
rate... --Ben
pr_err("%s:  WARNING: no legacy rates for band[%d] in 
set-bitrate-mask.\n",
   sdata->dev->name, band);
}
}




So, I think we should relax this check, at least for ath10k.


Well, yes and no. I don't think we should make ath10k special here, and
this fixes a real problem - namely that you can set up the system so
that you have no usable rates at all, and then you just get a WARN_ON
and start using the lowest possible rate...


Well, there are a million ways to set up a broken system, and setting a single
rate has a useful purpose, especially with ath10k since it has such limited
rate-setting capabilities.

There is basically never going to be a case where setting a single tx-rate on an
AP is a good idea in a general production environment, so maybe a possible 
WARN-ON is fine?

If you *do* set up an AP with a limited rateset, then it should simply fail to
allow a station to connect if it does not have any matching rates.  This might 
go
back to a previous idea I had (and patches I posted and carry in my tree) to 
allow setting a different
advertise rateset vs usable tx-rateset.

For existing stations that might not match the new fixed rate, we could 
purposefully kick
them off I guess, but seems like a lot of work for a case that seems pretty 
irrelevant.




commit e8e4f5280ddd0a7b43a795f90a0758e3c99df6a6
Author: Johannes Berg 
Date:   Wed Mar 8 11:12:10 2017 +0100

 mac80211: reject/clear user rate mask if not usable

 If the user rate mask results in no (basic) rates being usable,
 clear it. Also, if we're already operating when it's set, reject
 it instead.

 Technically, selecting basic rates as the criterion is a bit too
 restrictive, but calculating the usable rates over all stations
 (e.g. in AP mode) is harder, and all stations must support the
 basic rates. Similarly, in client mode, the basic rates will be
 used anyway for control frames.


I guess you could implement this part? I.e. iterating the clients and
checking that they all support the rate that is set. However, then you
also need to implement that this gets reset when a new client that
doesn't support this rate connects.

Overall, this isn't very well defined for AP mode...

Perhaps it'd be better - as you pointed out in the other thread - to
have API to force a rate per station? We already have that for iwlwifi
in debugfs, so perhaps that'd be something to consider for this too,
I'm not sure there would be a real need to have it in nl80211?


I looked closely at the ath10k firmware yesterday, and it has no way to set a 
specific
single rate per peer.  Sure, I could hack something into my CT firmware, but 
that
still leaves all the stock driver/firmware people out of luck, and my patches
won't make it upstream in the main kernel...

Thanks,
Ben


--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

Re: [RFC 1/3] mac80211: Add TXQ scheduling API

[Johannes Berg]

On Wed, 2017-10-11 at 16:29 +0200, Toke Høiland-Jørgensen wrote:
> Johannes Berg  writes:
> 
> > On Wed, 2017-10-11 at 16:06 +0200, Toke Høiland-Jørgensen wrote:
> > 
> > > > Hmm, not sure. We really want this to be scheduled pretty much
> > > > immediately because the other side will be waiting for the
> > > > frames,
> > > > and
> > > > if we don't get an answer out quickly it'll have to assume
> > > > we're
> > > > broken. I don't know what the limit here is for our firmware,
> > > > but
> > > > we
> > > > should really get this out as soon as possible in this case.
> > > 
> > > OK. But presumably it can't preempt packets already pushed to the
> > > hardware, right? 
> > 
> > True. If there are still packets scheduled then it needs even more
> > driver tricks to drop those back to tx_pending first ...
> 
> Only for packets to the same station, right?

Yes, but they need to be somehow taken off the queue to avoid
reordering. Usually the firmware will filter them, but synchronisation
is difficult, since what might happen is that some frames are already
filtered, others aren't, and then the later ones actually need to go
out while the earlier ones don't ... if that's not done, you get
reordering and the state machines get out of sync.

> What part of the standard do I have to read to learn how this is
> supposed to work, BTW? Or even better, is there a resource that
> describes how PS works that is more accessible than the standard
> itself?

Hmm. I don't think the standard will actually help you much here, it
just describes the over-the-air behaviour.

Most of the complexity here comes from having to deal with driver
buffering, mac80211 buffering, addressing the reordering problem
(described above) from queuing frames for multiple stations on the same
hw queue.

johannes

Re: [RFC 1/3] mac80211: Add TXQ scheduling API

[Toke Høiland-Jørgensen]

Johannes Berg  writes:

> On Wed, 2017-10-11 at 16:06 +0200, Toke Høiland-Jørgensen wrote:
>
>> > Hmm, not sure. We really want this to be scheduled pretty much
>> > immediately because the other side will be waiting for the frames,
>> > and
>> > if we don't get an answer out quickly it'll have to assume we're
>> > broken. I don't know what the limit here is for our firmware, but
>> > we
>> > should really get this out as soon as possible in this case.
>> 
>> OK. But presumably it can't preempt packets already pushed to the
>> hardware, right? 
>
> True. If there are still packets scheduled then it needs even more
> driver tricks to drop those back to tx_pending first ...

Only for packets to the same station, right?

>> So telling the driver to immediately schedule a packet,
>> and making sure that the txq it gets from next_txq() is the right one
>> should do the trick? But I guess it's a bit of a roundabout way,
>> which may not be worth it to avoid an extra callback...
>
> Yeah, might work, but remember that we need to mangle the packet, and
> for that we need to know how many packets will go out. E.g. with U-
> APSD, if we tell the driver 8 packets are OK, and it only wants 6, then
> that's acceptable, but we have to tag the last of those with EOSP ...
>
> So one way or another I think we need a separate callback here, and
> perhaps just have the driver do the EOSP tagging, or have a separate
> function to pull the frames so mac80211 can do the tagging, dunno.

Yeah, sounds like it'll need a separate callback, or at least a flag.

What part of the standard do I have to read to learn how this is
supposed to work, BTW? Or even better, is there a resource that
describes how PS works that is more accessible than the standard itself?

> Note that this is only for _some_ drivers, others will implement much
> of this in firmware.

Right, of course. Fun times! :)

-Toke

Re: Two rtlwifi drivers?

[Larry Finger]

On 10/11/2017 08:13 AM, Greg Kroah-Hartman wrote:

On Wed, Oct 11, 2017 at 12:06:00PM +0300, Kalle Valo wrote:

(Sorry for taking so long with the reply, I wanted first to check what
the rtlwifi in staging contains.)

Larry Finger  writes:


On 08/24/2017 07:14 AM, Kalle Valo wrote:

Dan Carpenter  writes:


Smatch is distrustful of the "capab" value and marks it as user
controlled.  I think it actually comes from the firmware?  Anyway, I
looked at other drivers and they added a bounds check and it seems like
a harmless thing to have so I have added it here as well.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/rtlwifi/base.c b/drivers/staging/rtlwifi/base.c
index f7f207cbaee3..a30b928d5ee1 100644
--- a/drivers/staging/rtlwifi/base.c
+++ b/drivers/staging/rtlwifi/base.c


I'm getting slightly annoyed that we now apparently have two duplicate
rtlwifi drivers (with the same name!) and I'm being spammed by staging
patches. Was this really a smart thing to do? And what will be the
future of these two drivers?

(Of course this is not directed to Dan, he is just fixing bugs found by
smatch, but more like a general question.)


That was the decision that you and Greg made. The version in
wireless-drivers needs many patches to handle the new device. The
progress in applying these to wireless-drivers was very slow for many
reasons. Keeping a single version of that code would have required
coordination between you and Greg, which was discouraged.


I don't recall deciding anything, all I did was asking for more info
about the new code. I was against the idea since I first saw your mail
but I tried to be diplomatic and not shot it down immeadiately. Shows
that diplomacy is not really my thing...

We always take extra measures to avoid forking code, why is it now all
of sudden ok? Also this gives the wrong message to Realtek, and other
vendors, that they can just fork the driver and push all sort of crap to
staging.

So just to make clear to everyone: I think forking drivers like this is
a HORRIBLE idea and I do not want to have anything to do with that. If
schedule goes over quality then a much better approach is to move to the
whole driver to staging than to have duplicated drivers like we have
now.


I think it's horrid too.  But, if no one is able to do the real work
here, we hurt users who just need to use their hardware to get things
done.

And it seems like the company isn't willing to do the real work, so
dumping this in staging is the best we can do at the moment.

However, if this causes you problems, that's not good at all either.
Getting "real" support for this hardware is key, and hopefully can
happen somehow.  But fixing up the staging driver is almost never the
way to do it, as you know :)

So what to do?  Any ideas?  What makes your life easier?  You can just
ignore the staging tree, as it should not affect your portion of the
kernel at all, right?


Greg and Kalle,

We can all agree that this situation is bad; however, several of the points made 
in your E-mails need to be addressed.


First of all, I am not an employee of Realtek, and I have no knowledge of the 
internals of any of their chips. I have never signed a non-disclosure agreement, 
and the only thing that I have received from them are sample chips for testing. 
My main interest is in helping the user experience. As there are a number of 
users with the new RTL8822BE device, that meant getting an in-kernel driver to 
them as soon as possible. As stated earlier, adding this particular device to 
the rtlwifi family involved roughly 120K lines of new code. Given our recent 
experience in getting code accepted into the wireless tree meant that this 
additional code would not have been accepted for many months. For that reason, 
we chose the staging route. It is important that we get this right as Realtek 
tells me that there will be two additional new drivers in the coming 6 months.


As to the convergence of the rtlwifi code between staging and wireless, I 
applied the 40 or 50 patches in my queue to the wireless version to create the 
version that went into staging. If any of the current patches to wireless do not 
seem to be in the staging version, sometimes temporary changes are necessary so 
that the intermediate drivers will build and work. Yes, it is code churn, but 
necessary to keep patches small. In keeping with Kalle's requests, only a 
fraction of those patches have been submitted to him.


My intent is to have the RTL8822BE driver moved from staging to mainline no 
later than 4.17. The affected drivers rtl_pci, rtlwifi and becoex will be moved 
in that order. Of course, the required changes will need to be in wireless 
before staging is changed, which will slow the process. As I see it, the switch 
can only occur with a new version.


My opinion is that the company has gone a long ways toward meeting the 
requirements of the Linux 

Re: [RFC 1/3] mac80211: Add TXQ scheduling API

[Johannes Berg]

On Wed, 2017-10-11 at 16:06 +0200, Toke Høiland-Jørgensen wrote:

> > Hmm, not sure. We really want this to be scheduled pretty much
> > immediately because the other side will be waiting for the frames,
> > and
> > if we don't get an answer out quickly it'll have to assume we're
> > broken. I don't know what the limit here is for our firmware, but
> > we
> > should really get this out as soon as possible in this case.
> 
> OK. But presumably it can't preempt packets already pushed to the
> hardware, right? 

True. If there are still packets scheduled then it needs even more
driver tricks to drop those back to tx_pending first ...

> So telling the driver to immediately schedule a packet,
> and making sure that the txq it gets from next_txq() is the right one
> should do the trick? But I guess it's a bit of a roundabout way,
> which may not be worth it to avoid an extra callback...

Yeah, might work, but remember that we need to mangle the packet, and
for that we need to know how many packets will go out. E.g. with U-
APSD, if we tell the driver 8 packets are OK, and it only wants 6, then
that's acceptable, but we have to tag the last of those with EOSP ...

So one way or another I think we need a separate callback here, and
perhaps just have the driver do the EOSP tagging, or have a separate
function to pull the frames so mac80211 can do the tagging, dunno.

Note that this is only for _some_ drivers, others will implement much
of this in firmware.

johannes

Re: [PATCH v3] mac80211: aead api to reduce redundancy

[Xiang Gao]

Great ! Thanks !
Xiang Gao


2017-10-11 3:48 GMT-04:00 Johannes Berg :
> On Tue, 2017-10-10 at 22:31 -0400, Xiang Gao wrote:
>> Currently, the aes_ccm.c and aes_gcm.c are almost line by line copy
>> of
>> each other. This patch reduce code redundancy by moving the code in
>> these
>> two files to crypto/aead_api.c to make it a higher level aead api.
>> The
>> file aes_ccm.c and aes_gcm.c are removed and all the functions there
>> are
>> now implemented in their headers using the newly added aead api.
>
> Applied. FWIW, the sta_dynamic_down_up test that the robot complained
> about, and the PSK tests that heavily use CCMP all pass.
>
> johannes

Re: [RFC 1/3] mac80211: Add TXQ scheduling API

[Toke Høiland-Jørgensen]

Johannes Berg  writes:

>> Well I was trying to do The Right Thing(tm), obviously ;)
>
> :-)
>
>> The driver_buffered field comes from the previous behaviour of ath9k:
>> It would basically set the station_buffered flag if there was
>> something in the retry queue at the time it goes to sleep. And on
>> wakeup, it will reschedule the txq if it has anything in the retry
>> queue. And, well, it just seemed odd that there was this duplicated
>> logic in the driver and mac80211, if the driver could just signal to
>> mac80211 to reschedule for it...
>
> Ok. I'm not sure what ath9k does, but mac80211 makes a distinction
> between "do I have something buffered" and "does the driver have
> something buffered".
>
> When the station wakes up it's pretty easy, we tell the driver and it
> just has to send its own frames first.
>
> But when we get a PS-Poll/U-APSD it's more complicated, and we have to
> tell the driver "please release N frames you have buffered" or we may
> have to tell it "please allow me to send N frames that I have buffered"
> which is why we need the distinction of whether or not the driver has
> something buffered.
>
> Ultimately, with TXQs, I hope this distinction can go away because the
> driver wouldn't buffer all by itself.

Yes, that would be good. Okay, I'll keep PS buffering the way it works
now.

>> But I guess I was really just getting ahead of myself there; so the
>> right thing to do for now is to keep the old behaviour, and then fix
>> it properly afterwards?
>
> I guess that'd be easier.
>
>> Yes, this makes sense. Each sleep period is pretty short, right? 
>
> Not necessarily.
>
>> I.e., we don't need to deal with interactions between CoDel and the
>> queue being stopped for a long period of time?
>
> I don't know enough about the possible interactions to answer that.
> Sleep periods may be long, though typically if there's traffic for
> stations then they want to retrieve that and will wake up relatively
> soon, but "relatively soon" may still be on the order of hundreds of
> milliseconds (or even seconds) because sometimes clients will only
> listen to DTIM beacons (DTIM period * beacon interval), and e.g. with
> WNM sleep mode it becomes even longer.

Ah. Right. Well, guess we'll have to cross that bridge once we get
there. Not sure what the right thing to do from the point of view of an
AQM in this instance. But at least making sure it doesn't drop the
packet at the head of every queue at wakeup would probably be good.

>> I was envisioning that next_txq() could also make those kinds of
>> decisions (i.e., preempt the normal scheduling algorithm when a
>> "special" TXQ needs to be scheduled immediately). But not sure if
>> that is enough for this case?
>
> Hmm, not sure. We really want this to be scheduled pretty much
> immediately because the other side will be waiting for the frames, and
> if we don't get an answer out quickly it'll have to assume we're
> broken. I don't know what the limit here is for our firmware, but we
> should really get this out as soon as possible in this case.

OK. But presumably it can't preempt packets already pushed to the
hardware, right? So telling the driver to immediately schedule a packet,
and making sure that the txq it gets from next_txq() is the right one
should do the trick? But I guess it's a bit of a roundabout way, which
may not be worth it to avoid an extra callback...

-Toke

Re: Two rtlwifi drivers?

[Dan Carpenter]

On Wed, Oct 11, 2017 at 03:13:10PM +0200, Greg Kroah-Hartman wrote:
> And it seems like the company isn't willing to do the real work, so
> dumping this in staging is the best we can do at the moment.

I'm more optimistic.  There are a lot of @realtek.com addresses in the
CC list and that's a new thing.

regards,
dan carpenter

Re: [RFC 1/3] mac80211: Add TXQ scheduling API

[Toke Høiland-Jørgensen]

Johannes Berg  writes:

> On Tue, 2017-10-10 at 19:51 +0200, Toke Høiland-Jørgensen wrote:
>
>> > > +struct list_head active_txqs;
>> > > +spinlock_t active_txq_lock;
>> > 
>> > Is there much point in having a separate lock? We probably need the
>> > fq lock in most places related to this anyway?
>> 
>> Well, once the scheduler gets a bit smarter it may be necessary to
>> much with the order of TXQs on there without touching any of the
>> queues (e.g., when calculating airtime usage on TX and RX
>> completion). Not sure if that is enough to warrant a separate lock,
>> though; I hadn't thought about just grabbing fq->lock...
>
> Ok, dunno. It seemed sort of related but perhaps it's not really.

Yeah. I'll keep this in mind when I implement the airtime fairness
accounting.

>> > Also maybe you should only do that if the TXQ isn't *empty*, so the
>> > driver could call this unconditionally?
>> 
>> There can be cases where the driver wants the queue to be scheduled
>> even though it looks empty from mac80211's point of view. For ath9k,
>> the driver keeps its retry queue in the drv_priv part of the txq
>> structure, so it will check if that is empty before deciding to call
>> the schedule function.
>> 
>> This is also related to the PS behaviour, so guess this could be
>> changed once that is all TXQ-based...
>
> Interesting. I guess scheduling an empty queue doesn't really matter
> for mac80211 anyway though - just some extra work if we try to get
> frames from it.

Yes, and I figure giving the driver that option might be a good way to
have some flexibility.

-Toke

Re: [RFC] mac80211: Add airtime fairness accounting

[Toke Høiland-Jørgensen]

Johannes Berg  writes:

>> Yeah, ath9k certainly gets that as part of the RX information from
>> the chip.
>
> Yeah, though there are more complex cases, e.g. with hardware A-MSDU
> deaggregation like in ath10k.

Here be dragons; noted :)

>> Well, some of the tests I did while porting ath9k to the iTXQs
>> indicated that for voice-like traffic we can get very close to the
>> same actual end-to-end latency for BE-marked traffic that we do with
>> VO-marked traffic. This is in part because the FQ sparse flow
>> prioritisation makes sure that such flows get queueing priority.
>
> That really depends on medium saturation - if that's low, then yeah,
> the difference is in the EDCA parameters and the minimum backoff,
> which isn't a huge difference if you measure end-to-end.
>
> Given saturation/congestion though, and I think we have to take this
> into account since not everyone will be using this code, there are
> measurable advantages to using VO - like in the test I mentioned where
> you can block out BE "forever".

Yup, when the medium is saturated the tradeoff might be different. My
hope is that it is possible to dynamically detect when it might be
beneficial and change behaviour based on this. I know this is maybe a
bit hand-wavy for now, but otherwise it wouldn't be research... ;)
>
>> Now obviously, there are going to be tradeoffs, and scenarios where
>> latency will suffer. But I would at least like to be able to explore
>> this, and I think with the API we are currently discussing that will
>> be possible. 
>
> I'm not sure how you envision this working with the API, since you
> still have to pull from multiple TXQs, but I have no objection to the
> API as is - I'm just not convinced that actually demoting traffic is a
> good idea :)

Sure, I realise I have some convincing to do on this point...

>> Another thing I want to explore is doing soft admission
>> control; i.e., if someone sends bulk traffic marked as VO, it will be
>> automatically demoted to BE traffic rather than locking everyone else
>> out. We've tested that with some success in the Cake scheduler, and
>> it may be applicable to WiFi as well.
>
> It seems pretty strange to do that at this level - we control what TID
> (and AC) is selected for the traffic? So why not just change at that
> level for this type of thing?
>
> You can probably even already do that with TC by re-marking the traffic
> depending on type or throughput or whatever else TC can classify on.

Mostly because I am expecting that the current queue state is an
important input variable. It's quite straight forward to (e.g.) remark
VO packets if they exceed a fixed rate. But what I want to do is demote
packets if they exceed what the network can currently handle. It may be
that visibility into the queueing is enough, though. I have yet to
actually experiment with this...

-Toke

[PATCH] mac80211: use crypto_aead_authsize()

[Johannes Berg]

From: Johannes Berg 

Evidently this API is intended to be used to isolate against
API changes, so use it instead of accessing ->authsize.

Signed-off-by: Johannes Berg 
---
 net/mac80211/aead_api.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/aead_api.c b/net/mac80211/aead_api.c
index 347f13953b2c..160f9df30402 100644
--- a/net/mac80211/aead_api.c
+++ b/net/mac80211/aead_api.c
@@ -21,7 +21,7 @@
 int aead_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad, size_t aad_len,
 u8 *data, size_t data_len, u8 *mic)
 {
-   size_t mic_len = tfm->authsize;
+   size_t mic_len = crypto_aead_authsize(tfm);
struct scatterlist sg[3];
struct aead_request *aead_req;
int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(tfm);
@@ -52,7 +52,7 @@ int aead_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad, 
size_t aad_len,
 int aead_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad, size_t aad_len,
 u8 *data, size_t data_len, u8 *mic)
 {
-   size_t mic_len = tfm->authsize;
+   size_t mic_len = crypto_aead_authsize(tfm);
struct scatterlist sg[3];
struct aead_request *aead_req;
int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(tfm);
-- 
2.14.2

Re: [PATCH] rtl8xxxu: mark expected switch fall-throughs

[Jes Sorensen]

On 10/11/2017 04:41 AM, Kalle Valo wrote:

Jes Sorensen  writes:


On 10/10/2017 03:30 PM, Gustavo A. R. Silva wrote:

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.


While this isn't harmful, to me this looks like pointless patch churn
for zero gain and it's just ugly.


In general I find it useful to mark fall through cases. And it's just a
comment with two words, so they cannot hurt your eyes that much.


I don't see them being harmful in the code, but I don't see them of much 
use either. If it happened as part of natural code development, fine. My 
objection is to people running around doing this systematically causing 
patch churn for little to zero gain.


Jes

Re: Two rtlwifi drivers?

[Greg Kroah-Hartman]

On Wed, Oct 11, 2017 at 12:06:00PM +0300, Kalle Valo wrote:
> (Sorry for taking so long with the reply, I wanted first to check what
> the rtlwifi in staging contains.)
> 
> Larry Finger  writes:
> 
> > On 08/24/2017 07:14 AM, Kalle Valo wrote:
> >> Dan Carpenter  writes:
> >>
> >>> Smatch is distrustful of the "capab" value and marks it as user
> >>> controlled.  I think it actually comes from the firmware?  Anyway, I
> >>> looked at other drivers and they added a bounds check and it seems like
> >>> a harmless thing to have so I have added it here as well.
> >>>
> >>> Signed-off-by: Dan Carpenter 
> >>>
> >>> diff --git a/drivers/staging/rtlwifi/base.c 
> >>> b/drivers/staging/rtlwifi/base.c
> >>> index f7f207cbaee3..a30b928d5ee1 100644
> >>> --- a/drivers/staging/rtlwifi/base.c
> >>> +++ b/drivers/staging/rtlwifi/base.c
> >>
> >> I'm getting slightly annoyed that we now apparently have two duplicate
> >> rtlwifi drivers (with the same name!) and I'm being spammed by staging
> >> patches. Was this really a smart thing to do? And what will be the
> >> future of these two drivers?
> >>
> >> (Of course this is not directed to Dan, he is just fixing bugs found by
> >> smatch, but more like a general question.)
> >
> > That was the decision that you and Greg made. The version in
> > wireless-drivers needs many patches to handle the new device. The
> > progress in applying these to wireless-drivers was very slow for many
> > reasons. Keeping a single version of that code would have required
> > coordination between you and Greg, which was discouraged.
> 
> I don't recall deciding anything, all I did was asking for more info
> about the new code. I was against the idea since I first saw your mail
> but I tried to be diplomatic and not shot it down immeadiately. Shows
> that diplomacy is not really my thing...
> 
> We always take extra measures to avoid forking code, why is it now all
> of sudden ok? Also this gives the wrong message to Realtek, and other
> vendors, that they can just fork the driver and push all sort of crap to
> staging.
> 
> So just to make clear to everyone: I think forking drivers like this is
> a HORRIBLE idea and I do not want to have anything to do with that. If
> schedule goes over quality then a much better approach is to move to the
> whole driver to staging than to have duplicated drivers like we have
> now.

I think it's horrid too.  But, if no one is able to do the real work
here, we hurt users who just need to use their hardware to get things
done.

And it seems like the company isn't willing to do the real work, so
dumping this in staging is the best we can do at the moment.

However, if this causes you problems, that's not good at all either.
Getting "real" support for this hardware is key, and hopefully can
happen somehow.  But fixing up the staging driver is almost never the
way to do it, as you know :)

So what to do?  Any ideas?  What makes your life easier?  You can just
ignore the staging tree, as it should not affect your portion of the
kernel at all, right?

thanks,

greg k-h

RE: [PATCH] rtl8xxxu: mark expected switch fall-throughs

[David Laight]

From: Joe Perches
> Sent: 11 October 2017 11:21
> On Tue, 2017-10-10 at 14:30 -0500, Gustavo A. R. Silva wrote:
> > In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> > where we are expecting to fall through.
> 
> perhaps use Arnaldo's idea:
> 
> https://lkml.org/lkml/2017/2/9/845
> https://lkml.org/lkml/2017/2/10/485

gah, that is even uglier and requires a chase through
headers to find out what it means.

David

pull-request: mac80211-next 2017-10-11

[Johannes Berg]

Hi Dave,

Here's a -next pull request. The only bigger thing here is the
addition of the regulatory database as firmware, which will
allow us to - over time - get rid of CRDA, as well as having
the option of adding more fields to the database where needed,
this would've been extremely complex with CRDA because it had
not been built with extensibility in mind.

Please pull and let me know if there's any problem.

Thanks,
johannes



The following changes since commit cc71b7b071192ac1c288e272fdc3f3877eb96663:

  net/ipv6: remove unused err variable on icmpv6_push_pending_frames 
(2017-10-05 21:56:26 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git 
tags/mac80211-next-for-davem-2017-10-11

for you to fetch changes up to 90a53e4432b12288316efaa5f308adafb8d304b0:

  cfg80211: implement regdb signature checking (2017-10-11 14:24:24 +0200)


Work continues in various areas:
 * port authorized event for 4-way-HS offload (Avi)
 * enable MFP optional for such devices (Emmanuel)
 * Kees's timer setup patch for mac80211 mesh
   (the part that isn't trivially scripted)
 * improve VLAN vs. TXQ handling (myself)
 * load regulatory database as firmware file (myself)
 * with various other small improvements and cleanups

I merged net-next once in the meantime to allow Kees's
timer setup patch to go in.


Avraham Stern (2):
  ieee80211: Add WFA TPC report element OUI type
  cfg80211/nl80211: add a port authorized event

Emmanuel Grumbach (1):
  nl80211: add an option to allow MFP without requiring it

Gregory Greenman (1):
  mac80211: recalculate some sta parameters after insertion

Ilan peer (1):
  mac80211: Simplify locking in ieee80211_sta_tear_down_BA_sessions()

Johannes Berg (12):
  mac80211: avoid allocating TXQs that won't be used
  mac80211: simplify and clarify IE splitting
  mac80211: use offsetofend()
  cfg80211: remove unused function ieee80211_data_from_8023()
  Merge remote-tracking branch 'net-next/master' into mac80211-next
  MAINTAINERS: update Johannes Berg's entries
  fq: support filtering a given tin
  mac80211: only remove AP VLAN frames from TXQ
  cfg80211: support loading regulatory database as firmware file
  cfg80211: support reloading regulatory database
  cfg80211: reg: remove support for built-in regdb
  cfg80211: implement regdb signature checking

Kees Cook (1):
  net/mac80211/mesh_plink: Convert timers to use timer_setup()

Liad Kaufman (1):
  mac80211: extend ieee80211_ie_split to support EXTENSION

Lubomir Rintel (1):
  mac80211_hwsim: use dyndbg for debug messages

Luca Coelho (1):
  mac80211: add documentation to ieee80211_rx_ba_offl()

Manikanta Pubbisetty (1):
  mac80211: fix bandwidth computation for TDLS peers

Richard Schütz (1):
  wireless: set correct mandatory rate flags

Roee Zamir (2):
  nl80211: add OCE scan and capability flags
  mac80211: oce: enable receiving of bcast probe resp

Stanislaw Gruszka (1):
  mac80211: fix STA_SLOW_THRESHOLD htmldocs failure

Tova Mussai (1):
  nl80211: return error for invalid center_freq in 40 MHz

Xiang Gao (1):
  mac80211: aead api to reduce redundancy

 Documentation/driver-api/80211/cfg80211.rst |   3 -
 Documentation/networking/regulatory.txt |  30 +-
 MAINTAINERS |  13 +-
 drivers/net/wireless/mac80211_hwsim.c   | 192 ++--
 include/linux/ieee80211.h   |   1 +
 include/net/cfg80211.h  |  40 +--
 include/net/fq.h|   7 +
 include/net/fq_impl.h   |  72 -
 include/net/mac80211.h  |   8 +-
 include/uapi/linux/nl80211.h|  82 +++--
 net/mac80211/Makefile   |   3 +-
 net/mac80211/{aes_ccm.c => aead_api.c}  |  40 +--
 net/mac80211/aead_api.h |  27 ++
 net/mac80211/aes_ccm.h  |  42 ++-
 net/mac80211/aes_gcm.c  | 109 ---
 net/mac80211/aes_gcm.h  |  38 ++-
 net/mac80211/agg-rx.c   |   4 +-
 net/mac80211/ht.c   |  12 +-
 net/mac80211/ieee80211_i.h  |   2 +
 net/mac80211/iface.c|  29 +-
 net/mac80211/mesh.c |   3 +-
 net/mac80211/mesh.h |   1 +
 net/mac80211/mesh_hwmp.c|   8 +-
 net/mac80211/mesh_plink.c   |  13 +-
 net/mac80211/mlme.c |  19 +-
 net/mac80211/scan.c |  37 ++-
 net/mac80211/sta_info.c |  61 ++--
 net/mac80211/sta_info.h |   4 +-
 net/mac80211/tx.c   |  34 +++
 net/mac80211/util.c

Re: [PATCH V5 1/5] mac80211: Enable TDLS peer buffer STA feature

[Johannes Berg]

> +++ b/include/net/cfg80211.h
> @@ -3249,6 +3249,8 @@ struct cfg80211_ops {
>   *   beaconing mode (AP, IBSS, Mesh, ...).
>   * @WIPHY_FLAG_HAS_STATIC_WEP: The device supports static WEP key
> installation
>   *   before connection.
> + * @WIPHY_FLAG_SUPPORT_TDLS_BUFFER_ST: Device support buffer STA
> when TDLS is
> + *   established.

There's a typo (missing A) here.

However, I don't see a reason for this to be a WIPHY flag rather than a
mac80211 hw flag (enum ieee80211_hw_flags) since you only use it in
mac80211.

In reality, adding WIPHY flags should be really rare - only if
*cfg80211* needs to know something, but *userspace* doesn't...

If cfg80211 doesn't care, add to mac80211. If userspace cares, add to
extended nl80211 flags instead :)

johannes

[PATCH] [net-next]NFC: Convert timers to use timer_setup()

[Allen Pais]

Switch to using the new timer_setup() and from_timer()
for net/nfc/*

Signed-off-by: Allen Pais 
---
---
 net/nfc/core.c  |  8 +++-
 net/nfc/hci/core.c  |  7 +++
 net/nfc/hci/llc_shdlc.c | 23 +--
 net/nfc/llcp_core.c | 14 ++
 4 files changed, 21 insertions(+), 31 deletions(-)

diff --git a/net/nfc/core.c b/net/nfc/core.c
index e5e23c2..56e5467 100644
--- a/net/nfc/core.c
+++ b/net/nfc/core.c
@@ -1015,9 +1015,9 @@ static void nfc_check_pres_work(struct work_struct *work)
device_unlock(>dev);
 }
 
-static void nfc_check_pres_timeout(unsigned long data)
+static void nfc_check_pres_timeout(struct timer_list *t)
 {
-   struct nfc_dev *dev = (struct nfc_dev *)data;
+   struct nfc_dev *dev = from_timer(dev, t, check_pres_timer);
 
schedule_work(>check_pres_work);
 }
@@ -1094,9 +1094,7 @@ struct nfc_dev *nfc_allocate_device(struct nfc_ops *ops,
dev->targets_generation = 1;
 
if (ops->check_presence) {
-   setup_timer(>check_pres_timer, nfc_check_pres_timeout,
-   (unsigned long)dev);
-
+   timer_setup(>check_pres_timer, nfc_check_pres_timeout, 0);
INIT_WORK(>check_pres_work, nfc_check_pres_work);
}
 
diff --git a/net/nfc/hci/core.c b/net/nfc/hci/core.c
index a8a6e78..ac8030c4 100644
--- a/net/nfc/hci/core.c
+++ b/net/nfc/hci/core.c
@@ -428,9 +428,9 @@ void nfc_hci_event_received(struct nfc_hci_dev *hdev, u8 
pipe, u8 event,
nfc_hci_driver_failure(hdev, r);
 }
 
-static void nfc_hci_cmd_timeout(unsigned long data)
+static void nfc_hci_cmd_timeout(struct timer_list *t)
 {
-   struct nfc_hci_dev *hdev = (struct nfc_hci_dev *)data;
+   struct nfc_hci_dev *hdev = from_timer(hdev, t, cmd_timer);
 
schedule_work(>msg_tx_work);
 }
@@ -1004,8 +1004,7 @@ int nfc_hci_register_device(struct nfc_hci_dev *hdev)
 
INIT_WORK(>msg_tx_work, nfc_hci_msg_tx_work);
 
-   setup_timer(>cmd_timer, nfc_hci_cmd_timeout,
-   (unsigned long)hdev);
+   timer_setup(>cmd_timer, nfc_hci_cmd_timeout, 0);
 
skb_queue_head_init(>rx_hcp_frags);
 
diff --git a/net/nfc/hci/llc_shdlc.c b/net/nfc/hci/llc_shdlc.c
index 58df37e..fe98893 100644
--- a/net/nfc/hci/llc_shdlc.c
+++ b/net/nfc/hci/llc_shdlc.c
@@ -580,27 +580,27 @@ static void llc_shdlc_handle_send_queue(struct llc_shdlc 
*shdlc)
}
 }
 
-static void llc_shdlc_connect_timeout(unsigned long data)
+static void llc_shdlc_connect_timeout(struct timer_list *t)
 {
-   struct llc_shdlc *shdlc = (struct llc_shdlc *)data;
+   struct llc_shdlc *shdlc = from_timer(shdlc, t, connect_timer);
 
pr_debug("\n");
 
schedule_work(>sm_work);
 }
 
-static void llc_shdlc_t1_timeout(unsigned long data)
+static void llc_shdlc_t1_timeout(struct timer_list *t)
 {
-   struct llc_shdlc *shdlc = (struct llc_shdlc *)data;
+   struct llc_shdlc *shdlc = from_timer(shdlc, t, t1_timer);
 
pr_debug("SoftIRQ: need to send ack\n");
 
schedule_work(>sm_work);
 }
 
-static void llc_shdlc_t2_timeout(unsigned long data)
+static void llc_shdlc_t2_timeout(struct timer_list *t)
 {
-   struct llc_shdlc *shdlc = (struct llc_shdlc *)data;
+   struct llc_shdlc *shdlc = from_timer(shdlc, t, t2_timer);
 
pr_debug("SoftIRQ: need to retransmit\n");
 
@@ -763,14 +763,9 @@ static void *llc_shdlc_init(struct nfc_hci_dev *hdev, 
xmit_to_drv_t xmit_to_drv,
mutex_init(>state_mutex);
shdlc->state = SHDLC_DISCONNECTED;
 
-   setup_timer(>connect_timer, llc_shdlc_connect_timeout,
-   (unsigned long)shdlc);
-
-   setup_timer(>t1_timer, llc_shdlc_t1_timeout,
-   (unsigned long)shdlc);
-
-   setup_timer(>t2_timer, llc_shdlc_t2_timeout,
-   (unsigned long)shdlc);
+   timer_setup(>connect_timer, llc_shdlc_connect_timeout, 0);
+   timer_setup(>t1_timer, llc_shdlc_t1_timeout, 0);
+   timer_setup(>t2_timer, llc_shdlc_t2_timeout, 0);
 
shdlc->w = SHDLC_MAX_WINDOW;
shdlc->srej_support = SHDLC_SREJ_SUPPORT;
diff --git a/net/nfc/llcp_core.c b/net/nfc/llcp_core.c
index 7988185..ef4026a 100644
--- a/net/nfc/llcp_core.c
+++ b/net/nfc/llcp_core.c
@@ -242,9 +242,9 @@ static void nfc_llcp_timeout_work(struct work_struct *work)
nfc_dep_link_down(local->dev);
 }
 
-static void nfc_llcp_symm_timer(unsigned long data)
+static void nfc_llcp_symm_timer(struct timer_list *t)
 {
-   struct nfc_llcp_local *local = (struct nfc_llcp_local *) data;
+   struct nfc_llcp_local *local = from_timer(local, t, link_timer);
 
pr_err("SYMM timeout\n");
 
@@ -285,9 +285,9 @@ static void nfc_llcp_sdreq_timeout_work(struct work_struct 
*work)
nfc_genl_llc_send_sdres(local->dev, _sdres_list);
 }
 
-static void nfc_llcp_sdreq_timer(unsigned long data)
+static void nfc_llcp_sdreq_timer(struct timer_list *t)
 {
-   struct 

Re: [PATCH 12/13] kthread: Convert callback to use from_timer()

[Petr Mladek]

On Wed 2017-10-04 16:27:06, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer
> to all timer callbacks, switch kthread to use from_timer() and pass the
> timer pointer explicitly.
> 
> Cc: Andrew Morton 
> Cc: Petr Mladek 
> Cc: Tejun Heo 
> Cc: Thomas Gleixner 
> Cc: Oleg Nesterov 
> Signed-off-by: Kees Cook 

Reviewed-by: Petr Mladek 

Best Regards,
Petr

Re: [PATCH] rtl8xxxu: mark expected switch fall-throughs

[Joe Perches]

On Tue, 2017-10-10 at 14:30 -0500, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.

perhaps use Arnaldo's idea:

https://lkml.org/lkml/2017/2/9/845
https://lkml.org/lkml/2017/2/10/485

[PATCH v2] ath9k: add MSI support

[Russell Hu]

On new Intel platforms like ApolloLake, legacy interrupt mechanism
(INTx) is not supported, so WLAN modules are not working because
interrupts are missing, therefore this patch is to add MSI support to
ath9k.  With module paremeter "use_msi=1", ath9k driver would try to
use MSI instead of INTx.

Signed-off-by: Russell Hu 
---
 drivers/net/wireless/ath/ath9k/hw.c   | 33 ++--
 drivers/net/wireless/ath/ath9k/hw.h   |  3 +++
 drivers/net/wireless/ath/ath9k/init.c |  4 +++
 drivers/net/wireless/ath/ath9k/mac.c  | 47 +++
 drivers/net/wireless/ath/ath9k/pci.c  | 21 +++-
 drivers/net/wireless/ath/ath9k/reg.h  | 15 +++
 6 files changed, 115 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/hw.c 
b/drivers/net/wireless/ath/ath9k/hw.c
index 8c5c2dd8fa7f..cd0f023ccf77 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -922,6 +922,7 @@ static void ath9k_hw_init_interrupt_masks(struct ath_hw *ah,
AR_IMR_RXERR |
AR_IMR_RXORN |
AR_IMR_BCNMISC;
+   u32 msi_cfg = 0;
 
if (AR_SREV_9340(ah) || AR_SREV_9550(ah) || AR_SREV_9531(ah) ||
AR_SREV_9561(ah))
@@ -929,22 +930,30 @@ static void ath9k_hw_init_interrupt_masks(struct ath_hw 
*ah,
 
if (AR_SREV_9300_20_OR_LATER(ah)) {
imr_reg |= AR_IMR_RXOK_HP;
-   if (ah->config.rx_intr_mitigation)
+   if (ah->config.rx_intr_mitigation) {
imr_reg |= AR_IMR_RXINTM | AR_IMR_RXMINTR;
-   else
+   msi_cfg |= AR_INTCFG_MSI_RXINTM | AR_INTCFG_MSI_RXMINTR;
+   } else {
imr_reg |= AR_IMR_RXOK_LP;
-
+   msi_cfg |= AR_INTCFG_MSI_RXOK;
+   }
} else {
-   if (ah->config.rx_intr_mitigation)
+   if (ah->config.rx_intr_mitigation) {
imr_reg |= AR_IMR_RXINTM | AR_IMR_RXMINTR;
-   else
+   msi_cfg |= AR_INTCFG_MSI_RXINTM | AR_INTCFG_MSI_RXMINTR;
+   } else {
imr_reg |= AR_IMR_RXOK;
+   msi_cfg |= AR_INTCFG_MSI_RXOK;
+   }
}
 
-   if (ah->config.tx_intr_mitigation)
+   if (ah->config.tx_intr_mitigation) {
imr_reg |= AR_IMR_TXINTM | AR_IMR_TXMINTR;
-   else
+   msi_cfg |= AR_INTCFG_MSI_TXINTM | AR_INTCFG_MSI_TXMINTR;
+   } else {
imr_reg |= AR_IMR_TXOK;
+   msi_cfg |= AR_INTCFG_MSI_TXOK;
+   }
 
ENABLE_REGWRITE_BUFFER(ah);
 
@@ -952,6 +961,16 @@ static void ath9k_hw_init_interrupt_masks(struct ath_hw 
*ah,
ah->imrs2_reg |= AR_IMR_S2_GTT;
REG_WRITE(ah, AR_IMR_S2, ah->imrs2_reg);
 
+   if (ah->msi_enabled) {
+   ah->msi_reg = REG_READ(ah, AR_PCIE_MSI);
+   ah->msi_reg |= AR_PCIE_MSI_HW_DBI_WR_EN;
+   ah->msi_reg &= AR_PCIE_MSI_HW_INT_PENDING_ADDR_MSI_64;
+   REG_WRITE(ah, AR_INTCFG, msi_cfg);
+   ath_dbg(ath9k_hw_common(ah), ANY,
+   "value of AR_INTCFG=0x%X, msi_cfg=0x%X\n",
+   REG_READ(ah, AR_INTCFG), msi_cfg);
+   }
+
if (!AR_SREV_9100(ah)) {
REG_WRITE(ah, AR_INTR_SYNC_CAUSE, 0x);
REG_WRITE(ah, AR_INTR_SYNC_ENABLE, sync_default);
diff --git a/drivers/net/wireless/ath/ath9k/hw.h 
b/drivers/net/wireless/ath/ath9k/hw.h
index 4ac70827d142..0d6c07c77372 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -977,6 +977,9 @@ struct ath_hw {
bool tpc_enabled;
u8 tx_power[Ar5416RateSize];
u8 tx_power_stbc[Ar5416RateSize];
+   bool msi_enabled;
+   u32 msi_mask;
+   u32 msi_reg;
 };
 
 struct ath_bus_ops {
diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c
index bb7936090b91..b6b7a353fea4 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -75,6 +75,10 @@ MODULE_PARM_DESC(use_chanctx, "Enable channel context for 
concurrency");
 
 #endif /* CONFIG_ATH9K_CHANNEL_CONTEXT */
 
+int ath9k_use_msi;
+module_param_named(use_msi, ath9k_use_msi, int, 0444);
+MODULE_PARM_DESC(use_msi, "Use MSI instead of INTx if possible");
+
 bool is_ath9k_unloaded;
 
 #ifdef CONFIG_MAC80211_LEDS
diff --git a/drivers/net/wireless/ath/ath9k/mac.c 
b/drivers/net/wireless/ath/ath9k/mac.c
index 77c94f9e7b61..58d02c19b6d0 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -832,6 +832,43 @@ static void __ath9k_hw_enable_interrupts(struct ath_hw *ah)
}
ath_dbg(common, INTERRUPT, "AR_IMR 0x%x IER 0x%x\n",
REG_READ(ah, AR_IMR), REG_READ(ah, AR_IER));
+
+   if (ah->msi_enabled) {
+   u32 

Re: [PATCH 11/13] timer: Remove expires argument from __TIMER_INITIALIZER()

[Petr Mladek]

On Wed 2017-10-04 16:27:05, Kees Cook wrote:
> The expires field is normally initialized during the first mod_timer()
> call. It was unused by all callers, so remove it from the macro.
> 
> Signed-off-by: Kees Cook 
> ---
>  include/linux/kthread.h   | 2 +-
>  include/linux/timer.h | 5 ++---
>  include/linux/workqueue.h | 2 +-
>  3 files changed, 4 insertions(+), 5 deletions(-)

I was primary interested into the change in kthread.h. But the entire
patch is simple and looks fine:

Reviewed-by: Petr Mladek 

Best Regards,
Petr

Re: [PATCH 4/8] rsi: handle peer connection and disconnection in p2p mode

[Kalle Valo]

Amitkumar Karwar  writes:

> From: Prameela Rani Garnepudi 
>
> Parameter 'vif' is passed to inform_bss_status function to
> check the type of vif and to get vap_id.
>
> Signed-off-by: Prameela Rani Garnepudi 
> Signed-off-by: Amitkumar Karwar 

Kbuild bot reported that this added a new warning, I suspect this is from 
sparse:

>> drivers/net//wireless/rsi/rsi_91x_hal.c:136:3: note: in expansion of
>> macro 'cpu_to_le16'
  cpu_to_le16((tx_params->vap_id << RSI_DESC_VAP_ID_OFST) &

Please fix.

-- 
Kalle Valo

Re: Two rtlwifi drivers?

[Kalle Valo]

(Sorry for taking so long with the reply, I wanted first to check what
the rtlwifi in staging contains.)

Larry Finger  writes:

> On 08/24/2017 07:14 AM, Kalle Valo wrote:
>> Dan Carpenter  writes:
>>
>>> Smatch is distrustful of the "capab" value and marks it as user
>>> controlled.  I think it actually comes from the firmware?  Anyway, I
>>> looked at other drivers and they added a bounds check and it seems like
>>> a harmless thing to have so I have added it here as well.
>>>
>>> Signed-off-by: Dan Carpenter 
>>>
>>> diff --git a/drivers/staging/rtlwifi/base.c b/drivers/staging/rtlwifi/base.c
>>> index f7f207cbaee3..a30b928d5ee1 100644
>>> --- a/drivers/staging/rtlwifi/base.c
>>> +++ b/drivers/staging/rtlwifi/base.c
>>
>> I'm getting slightly annoyed that we now apparently have two duplicate
>> rtlwifi drivers (with the same name!) and I'm being spammed by staging
>> patches. Was this really a smart thing to do? And what will be the
>> future of these two drivers?
>>
>> (Of course this is not directed to Dan, he is just fixing bugs found by
>> smatch, but more like a general question.)
>
> That was the decision that you and Greg made. The version in
> wireless-drivers needs many patches to handle the new device. The
> progress in applying these to wireless-drivers was very slow for many
> reasons. Keeping a single version of that code would have required
> coordination between you and Greg, which was discouraged.

I don't recall deciding anything, all I did was asking for more info
about the new code. I was against the idea since I first saw your mail
but I tried to be diplomatic and not shot it down immeadiately. Shows
that diplomacy is not really my thing...

We always take extra measures to avoid forking code, why is it now all
of sudden ok? Also this gives the wrong message to Realtek, and other
vendors, that they can just fork the driver and push all sort of crap to
staging.

So just to make clear to everyone: I think forking drivers like this is
a HORRIBLE idea and I do not want to have anything to do with that. If
schedule goes over quality then a much better approach is to move to the
whole driver to staging than to have duplicated drivers like we have
now.

> The future, as stated in the TODO in staging, is to merge all the
> changes in the support drivers into wireless-drivers, and then move
> the new RTL8822BE driver out of staging.

And how many years will that take? (If that will ever happen) Also I see
that multiple patches are applied to staging version of rtlwifi which is
not in net version of rtlwifi. That all should be synced somehow, the
bigger the delta becomes the more difficult everything is.

> I'm sorry about the fallout affecting you, and I probably should have
> changed the directory names. In any case, ignore any patches that
> belong in staging. If I see any that do not include GregKH in the "To"
> list, I will NACK them and request proper routing.

Thanks, but that doesn't really help as I apply patches from patchwork
and it doesn't show the To field. I'll try to be extra careful and not
apply patches the staging version of rtlwifi patches, but mistakes
always happen.

-- 
Kalle Valo

Re: [RFC] mac80211: Add airtime fairness accounting

[Johannes Berg]

On Mon, 2017-10-09 at 22:25 +0200, Toke Høiland-Jørgensen wrote:

> > Well, the case that we did find is that sometimes U-APSD kills
> > aggregation, so then you'd have a lot of single frames and
> > significantly under-estimate air-time usage in this case. Thus,
> > this
> > station would get far more than its fair share of air time, because
> > of
> > a bug that makes it not use aggregation... That doesn't sound very
> > good to me.
> > 
> > Perhaps at least taking aggregation into account would be doable -
> > we _should_ know this, at least partially.
> 
> Yeah, ath9k certainly gets that as part of the RX information from
> the chip.

Yeah, though there are more complex cases, e.g. with hardware A-MSDU
deaggregation like in ath10k.

> Well, some of the tests I did while porting ath9k to the iTXQs
> indicated that for voice-like traffic we can get very close to the
> same actual end-to-end latency for BE-marked traffic that we do with
> VO-marked traffic. This is in part because the FQ sparse flow
> prioritisation makes sure that such flows get queueing priority.

That really depends on medium saturation - if that's low, then yeah,
the difference is in the EDCA parameters and the minimum backoff, which
isn't a huge difference if you measure end-to-end.

Given saturation/congestion though, and I think we have to take this
into account since not everyone will be using this code, there are
measurable advantages to using VO - like in the test I mentioned where
you can block out BE "forever".

> Now obviously, there are going to be tradeoffs, and scenarios where
> latency will suffer. But I would at least like to be able to explore
> this, and I think with the API we are currently discussing that will
> be possible. 

I'm not sure how you envision this working with the API, since you
still have to pull from multiple TXQs, but I have no objection to the
API as is - I'm just not convinced that actually demoting traffic is a
good idea :)

> Another thing I want to explore is doing soft admission
> control; i.e., if someone sends bulk traffic marked as VO, it will be
> automatically demoted to BE traffic rather than locking everyone else
> out. We've tested that with some success in the Cake scheduler, and
> it may be applicable to WiFi as well.

It seems pretty strange to do that at this level - we control what TID
(and AC) is selected for the traffic? So why not just change at that
level for this type of thing?

You can probably even already do that with TC by re-marking the traffic
depending on type or throughput or whatever else TC can classify on.

johannes

Re: [RFC 1/3] mac80211: Add TXQ scheduling API

[Johannes Berg]

On Tue, 2017-10-10 at 19:51 +0200, Toke Høiland-Jørgensen wrote:

> > > + struct list_head active_txqs;
> > > + spinlock_t active_txq_lock;
> > 
> > Is there much point in having a separate lock? We probably need the
> > fq lock in most places related to this anyway?
> 
> Well, once the scheduler gets a bit smarter it may be necessary to
> much with the order of TXQs on there without touching any of the
> queues (e.g., when calculating airtime usage on TX and RX
> completion). Not sure if that is enough to warrant a separate lock,
> though; I hadn't thought about just grabbing fq->lock...

Ok, dunno. It seemed sort of related but perhaps it's not really.


> > Also maybe you should only do that if the TXQ isn't *empty*, so the
> > driver could call this unconditionally?
> 
> There can be cases where the driver wants the queue to be scheduled
> even though it looks empty from mac80211's point of view. For ath9k,
> the driver keeps its retry queue in the drv_priv part of the txq
> structure, so it will check if that is empty before deciding to call
> the schedule function.
> 
> This is also related to the PS behaviour, so guess this could be
> changed once that is all TXQ-based...

Interesting. I guess scheduling an empty queue doesn't really matter
for mac80211 anyway though - just some extra work if we try to get
frames from it.

johannes

Re: [RFC 1/3] mac80211: Add TXQ scheduling API

[Johannes Berg]

> Well I was trying to do The Right Thing(tm), obviously ;)

:-)

> The driver_buffered field comes from the previous behaviour of ath9k:
> It would basically set the station_buffered flag if there was
> something in the retry queue at the time it goes to sleep. And on
> wakeup, it will reschedule the txq if it has anything in the retry
> queue. And, well, it just seemed odd that there was this duplicated
> logic in the driver and mac80211, if the driver could just signal to
> mac80211 to reschedule for it...

Ok. I'm not sure what ath9k does, but mac80211 makes a distinction
between "do I have something buffered" and "does the driver have
something buffered".

When the station wakes up it's pretty easy, we tell the driver and it
just has to send its own frames first.

But when we get a PS-Poll/U-APSD it's more complicated, and we have to
tell the driver "please release N frames you have buffered" or we may
have to tell it "please allow me to send N frames that I have buffered"
which is why we need the distinction of whether or not the driver has
something buffered.

Ultimately, with TXQs, I hope this distinction can go away because the
driver wouldn't buffer all by itself.

> But I guess I was really just getting ahead of myself there; so the
> right thing to do for now is to keep the old behaviour, and then fix
> it properly afterwards?

I guess that'd be easier.

> Yes, this makes sense. Each sleep period is pretty short, right? 

Not necessarily.

> I.e., we don't need to deal with interactions between CoDel and the
> queue being stopped for a long period of time?

I don't know enough about the possible interactions to answer that.
Sleep periods may be long, though typically if there's traffic for
stations then they want to retrieve that and will wake up relatively
soon, but "relatively soon" may still be on the order of hundreds of
milliseconds (or even seconds) because sometimes clients will only
listen to DTIM beacons (DTIM period * beacon interval), and e.g. with
WNM sleep mode it becomes even longer.

> > For the deliver-while-sleeping (PS-Poll/U-APSD) scenario, I think
> > the
> > driver should still pull frames, after calling something like
> > drv_release_buffered_frames(). We want this to be scheduled pretty
> > much
> > immediately, so we shouldn't just put the TXQ into the normal
> > rotation,
> > but otherwise it should work similarly - except limited to a
> > certain
> > number of frames [**].
> > In this case the driver probably needs to pull the frames using a
> > different function so that we can
> >  a) tag the packets properly (more-data, EOSP)
> >  b) generate nulldata as EOSP container where needed
> > Thus, it seems likely that we'll want a separate function, "pull
> > for PS
> > delivery" rather than the normal ieee80211_tx_dequeue().
> 
> I was envisioning that next_txq() could also make those kinds of
> decisions (i.e., preempt the normal scheduling algorithm when a
> "special" TXQ needs to be scheduled immediately). But not sure if
> that is enough for this case?

Hmm, not sure. We really want this to be scheduled pretty much
immediately because the other side will be waiting for the frames, and
if we don't get an answer out quickly it'll have to assume we're
broken. I don't know what the limit here is for our firmware, but we
should really get this out as soon as possible in this case.

johannes

Re: [PATCH] rtl8xxxu: mark expected switch fall-throughs

[Kalle Valo]

Jes Sorensen  writes:

> On 10/10/2017 03:30 PM, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>> where we are expecting to fall through.
>
> While this isn't harmful, to me this looks like pointless patch churn
> for zero gain and it's just ugly.

In general I find it useful to mark fall through cases. And it's just a
comment with two words, so they cannot hurt your eyes that much.

-- 
Kalle Valo

Re: pull-request: iwlwifi-next 2017-10-06-2

[Kalle Valo]

Luca Coelho  writes:

> Here's the second version of my first pull-request intended for
> v4.15.  It contains the last two patch sets I sent out with v2 of the
> pci dump patch.
>
> In v2 we have fixed a potential kernel oops when our driver is used
> with qemu, for instance.  In that case, the root port is NULL and we
> were trying to access it without checing.
>
> I have sent this out before and kbuildbot reported success.
>
> Please let me know if there are any issues.
>
> Cheers,
> Luca.
>
>
> The following changes since commit a7c9acc452b21b56c99dd7dfe0ab542f7baa6563:
>
>   brcmfmac: Delete redundant length check (2017-10-02 17:07:00 +0300)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git 
> tags/iwlwifi-next-for-kalle-2017-10-06-2
>
> for you to fetch changes up to f2abcfa6c86e503b352846ace9d6ab9b02ade0ab:
>
>   iwlwifi: remove dflt_pwr_limit from the transport (2017-10-06 15:22:34 
> +0300)
>
> 
> First batch of iwlwifi patches for 4.15 (v2)
>
> * Cleanups: - remove an unused value that we read from the NVM;
> - remove link quality measurement code that was never used;
> * One FW command API update;
> * A fix and an addition for PCI devices for the A000 family;
> * Tiny refactor of ref/unref code used by runtime-PM;
> * Some debugging improvements;
> * Implementation of a more flexible way to define command queue sizes;
> * ACPI code refactoring;
> * Some coding-style fixes;
> * Avoid redundant command to the firmware;
> * Add a struct with the format of one FW command;
> * Change an error log to a warning when the FW API is not aligned with
>   the driver (important during development);
> * Change a WARN_ON to WARN_ONCE to make it more descriptive and less
>   noisy (i.e. no repeated warnings on a firmware triggered error);
> * Dump PCI registers when an error occurs, to make it easier to debug;
>
> 

Pulled, thanks.

-- 
Kalle Valo

[PATCH v4.9] nl80211: Define policy for packet pattern attributes

[Johannes Berg]

From: Peng Xu 

Upstream commit ad670233c9e1d5feb365d870e30083ef1b889177.

Define a policy for packet pattern attributes in order to fix a
potential read over the end of the buffer during nla_get_u32()
of the NL80211_PKTPAT_OFFSET attribute.

Note that the data there can always be read due to SKB allocation
(with alignment and struct skb_shared_info at the end), but the
data might be uninitialized. This could be used to leak some data
from uninitialized vmalloc() memory, but most drivers don't allow
an offset (so you'd just get -EINVAL if the data is non-zero) or
just allow it with a fixed value - 100 or 128 bytes, so anything
above that would get -EINVAL. With brcmfmac the limit is 1500 so
(at least) one byte could be obtained.

Cc: sta...@kernel.org
Signed-off-by: Peng Xu 
Signed-off-by: Jouni Malinen 
[rewrite description based on SKB allocation knowledge]
Signed-off-by: Johannes Berg 
---
 net/wireless/nl80211.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ece0fbc08607..c626f679e1c8 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -541,6 +541,14 @@ nl80211_nan_srf_policy[NL80211_NAN_SRF_ATTR_MAX + 1] = {
[NL80211_NAN_SRF_MAC_ADDRS] = { .type = NLA_NESTED },
 };
 
+/* policy for packet pattern attributes */
+static const struct nla_policy
+nl80211_packet_pattern_policy[MAX_NL80211_PKTPAT + 1] = {
+   [NL80211_PKTPAT_MASK] = { .type = NLA_BINARY, },
+   [NL80211_PKTPAT_PATTERN] = { .type = NLA_BINARY, },
+   [NL80211_PKTPAT_OFFSET] = { .type = NLA_U32 },
+};
+
 static int nl80211_prepare_wdev_dump(struct sk_buff *skb,
 struct netlink_callback *cb,
 struct cfg80211_registered_device **rdev,
@@ -10009,7 +10017,7 @@ static int nl80211_set_wowlan(struct sk_buff *skb, 
struct genl_info *info)
u8 *mask_pat;
 
nla_parse(pat_tb, MAX_NL80211_PKTPAT, nla_data(pat),
- nla_len(pat), NULL);
+ nla_len(pat), nl80211_packet_pattern_policy);
err = -EINVAL;
if (!pat_tb[NL80211_PKTPAT_MASK] ||
!pat_tb[NL80211_PKTPAT_PATTERN])
@@ -10259,7 +10267,7 @@ static int nl80211_parse_coalesce_rule(struct 
cfg80211_registered_device *rdev,
u8 *mask_pat;
 
nla_parse(pat_tb, MAX_NL80211_PKTPAT, nla_data(pat),
- nla_len(pat), NULL);
+ nla_len(pat), nl80211_packet_pattern_policy);
if (!pat_tb[NL80211_PKTPAT_MASK] ||
!pat_tb[NL80211_PKTPAT_PATTERN])
return -EINVAL;
-- 
2.14.2

Re: [PATCH] wcn36xx: Remove unnecessary rcu_read_unlock in wcn36xx_bss_info_changed

[Kalle Valo]

Bjorn Andersson  writes:

> On Sun 08 Oct 06:06 PDT 2017, Jia-Ju Bai wrote:
>
>> No rcu_read_lock is called, but rcu_read_unlock is still called.
>> Thus rcu_read_unlock should be removed.
>> 
>
> Thanks, not sure how I could miss that one. Kalle can you please include
> this in a v4.14-rc pull request?
>
>
> :
>
> Fixes: 39efc7cc7ccf ("wcn36xx: Introduce mutual exclusion of fw 
> configuration")
>
>> Signed-off-by: Jia-Ju Bai 
>
> Acked-by: Bjorn Andersson 

Ok, I'll queue this to 4.14.

-- 
Kalle Valo

[PATCH v4.4] nl80211: Define policy for packet pattern attributes

[Johannes Berg]

From: Peng Xu 

Upstream commit ad670233c9e1d5feb365d870e30083ef1b889177.

Define a policy for packet pattern attributes in order to fix a
potential read over the end of the buffer during nla_get_u32()
of the NL80211_PKTPAT_OFFSET attribute.

Note that the data there can always be read due to SKB allocation
(with alignment and struct skb_shared_info at the end), but the
data might be uninitialized. This could be used to leak some data
from uninitialized vmalloc() memory, but most drivers don't allow
an offset (so you'd just get -EINVAL if the data is non-zero) or
just allow it with a fixed value - 100 or 128 bytes, so anything
above that would get -EINVAL. With brcmfmac the limit is 1500 so
(at least) one byte could be obtained.

Cc: sta...@kernel.org
Signed-off-by: Peng Xu 
Signed-off-by: Jouni Malinen 
[rewrite description based on SKB allocation knowledge]
Signed-off-by: Johannes Berg 
---
 net/wireless/nl80211.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 8ece212aa3d2..7950506395a8 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -485,6 +485,14 @@ nl80211_plan_policy[NL80211_SCHED_SCAN_PLAN_MAX + 1] = {
[NL80211_SCHED_SCAN_PLAN_ITERATIONS] = { .type = NLA_U32 },
 };
 
+/* policy for packet pattern attributes */
+static const struct nla_policy
+nl80211_packet_pattern_policy[MAX_NL80211_PKTPAT + 1] = {
+   [NL80211_PKTPAT_MASK] = { .type = NLA_BINARY, },
+   [NL80211_PKTPAT_PATTERN] = { .type = NLA_BINARY, },
+   [NL80211_PKTPAT_OFFSET] = { .type = NLA_U32 },
+};
+
 static int nl80211_prepare_wdev_dump(struct sk_buff *skb,
 struct netlink_callback *cb,
 struct cfg80211_registered_device **rdev,
@@ -9410,7 +9418,7 @@ static int nl80211_set_wowlan(struct sk_buff *skb, struct 
genl_info *info)
u8 *mask_pat;
 
nla_parse(pat_tb, MAX_NL80211_PKTPAT, nla_data(pat),
- nla_len(pat), NULL);
+ nla_len(pat), nl80211_packet_pattern_policy);
err = -EINVAL;
if (!pat_tb[NL80211_PKTPAT_MASK] ||
!pat_tb[NL80211_PKTPAT_PATTERN])
@@ -9660,7 +9668,7 @@ static int nl80211_parse_coalesce_rule(struct 
cfg80211_registered_device *rdev,
u8 *mask_pat;
 
nla_parse(pat_tb, MAX_NL80211_PKTPAT, nla_data(pat),
- nla_len(pat), NULL);
+ nla_len(pat), nl80211_packet_pattern_policy);
if (!pat_tb[NL80211_PKTPAT_MASK] ||
!pat_tb[NL80211_PKTPAT_PATTERN])
return -EINVAL;
-- 
2.14.2

Re: iwlwifi: ToF usage

[Luca Coelho]

On Wed, 2017-10-04 at 07:52 +0300, Luciano Coelho wrote:
> Hi Joel,
> 
> Unfortunately we don't have full support for ToF on the mainline
> kernel
> yet.  But you can try to use one of our Core releases (which is a
> backports-based tree) that you can find here:
> 
> You could try the release/Core30 branch, for example.


Johannes has also created a patch on top of the latest iw tool, adding
the commands for ToF.  Please see my comment in this bugzilla entry if
you want to try that:

https://bugzilla.kernel.org/show_bug.cgi?id=197187#c1

Also, if you have any problems, please add it to bugzilla so we can
track this all in a single place.

--
Cheers,
Luca.

Re: Setting single rate in ath10k broken by "reject/clear user rate mask if not usable"

[Johannes Berg]

On Wed, 2017-10-11 at 10:02 +0200, Johannes Berg wrote:

> Overall, this isn't very well defined for AP mode...

No, that's not really correct. It *is* well defined (set the rate for
all clients to the same fixed rate), but that definition isn't very
good because if that rate isn't a basic rate, clients can connect that
don't support this rate...

johannes

Re: Setting single rate in ath10k broken by "reject/clear user rate mask if not usable"

[Johannes Berg]

Hi,

> #iw dev vap206 set bitrates legacy-5 ht-mcs-5 0 vht-mcs-5
> command failed: Invalid argument (-22)
> 
> But, it actually *does* successfully set the rate in the driver
> first, which is confusing at best.

Huh?

> So, I think we should relax this check, at least for ath10k.

Well, yes and no. I don't think we should make ath10k special here, and
this fixes a real problem - namely that you can set up the system so
that you have no usable rates at all, and then you just get a WARN_ON
and start using the lowest possible rate...

> commit e8e4f5280ddd0a7b43a795f90a0758e3c99df6a6
> Author: Johannes Berg 
> Date:   Wed Mar 8 11:12:10 2017 +0100
> 
>  mac80211: reject/clear user rate mask if not usable
> 
>  If the user rate mask results in no (basic) rates being usable,
>  clear it. Also, if we're already operating when it's set, reject
>  it instead.
> 
>  Technically, selecting basic rates as the criterion is a bit too
>  restrictive, but calculating the usable rates over all stations
>  (e.g. in AP mode) is harder, and all stations must support the
>  basic rates. Similarly, in client mode, the basic rates will be
>  used anyway for control frames.

I guess you could implement this part? I.e. iterating the clients and
checking that they all support the rate that is set. However, then you
also need to implement that this gets reset when a new client that
doesn't support this rate connects.

Overall, this isn't very well defined for AP mode...

Perhaps it'd be better - as you pointed out in the other thread - to
have API to force a rate per station? We already have that for iwlwifi
in debugfs, so perhaps that'd be something to consider for this too,
I'm not sure there would be a real need to have it in nl80211?

johannes

Re: 4.14.0-rc3 iwlwifi: Hardware became unavailable during restart

[Luca Coelho]

On Tue, 2017-10-10 at 09:44 +0200, Seraphime Kirkovski wrote:
> Hello,

Hi Seraphime,


> I've got this splat after a couple of suspend-resume cycles on my
> HP-laptop. I haven't had the time to bisect or test other rcs for now.
> Pasting some logs before the actual WARN_ON, as they may be relevant.
> Just after the splat the connection is successfully reestablished.
> 
> [14293.758404] iwlwifi :24:00.0: Error sending REPLY_SCAN_ABORT_CMD: 
> time out after 2000ms.
> [14293.758429] iwlwifi :24:00.0: Current CMD queue read_ptr 67 write_ptr 
> 68
> [14293.758518] iwlwifi :24:00.0: Loaded firmware version: 18.168.6.1

This seems to be a DVM device (iwldvm).  What is the exact device
model? And you have never noticed this problem before?

Unfortunately this is a very old device and we don't support it
actively anymore.  Hopefully this will turn out to be a trivial fix in
the driver side, so we can get it solved for you.

The best way to track this is to report it in
https://bugzilla.kernel.org.

--
Cheers,
Luca.

Re: [PATCH v3] mac80211: aead api to reduce redundancy

[Johannes Berg]

On Tue, 2017-10-10 at 22:31 -0400, Xiang Gao wrote:
> Currently, the aes_ccm.c and aes_gcm.c are almost line by line copy
> of
> each other. This patch reduce code redundancy by moving the code in
> these
> two files to crypto/aead_api.c to make it a higher level aead api.
> The
> file aes_ccm.c and aes_gcm.c are removed and all the functions there
> are
> now implemented in their headers using the newly added aead api.

Applied. FWIW, the sta_dynamic_down_up test that the robot complained
about, and the PSK tests that heavily use CCMP all pass.

johannes

Re: [PATCH] wcn36xx: Remove unnecessary rcu_read_unlock in wcn36xx_bss_info_changed

[Bjorn Andersson]

On Sun 08 Oct 06:06 PDT 2017, Jia-Ju Bai wrote:

> No rcu_read_lock is called, but rcu_read_unlock is still called.
> Thus rcu_read_unlock should be removed.
> 

Thanks, not sure how I could miss that one. Kalle can you please include
this in a v4.14-rc pull request?


:

Fixes: 39efc7cc7ccf ("wcn36xx: Introduce mutual exclusion of fw configuration")

> Signed-off-by: Jia-Ju Bai 

Acked-by: Bjorn Andersson 

Regards,
Bjorn

> ---
>  drivers/net/wireless/ath/wcn36xx/main.c |1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/ath/wcn36xx/main.c 
> b/drivers/net/wireless/ath/wcn36xx/main.c
> index 35bd50b..b83f01d 100644
> --- a/drivers/net/wireless/ath/wcn36xx/main.c
> +++ b/drivers/net/wireless/ath/wcn36xx/main.c
> @@ -812,7 +812,6 @@ static void wcn36xx_bss_info_changed(struct ieee80211_hw 
> *hw,
>   if (!sta) {
>   wcn36xx_err("sta %pM is not found\n",
> bss_conf->bssid);
> - rcu_read_unlock();
>   goto out;
>   }
>   sta_priv = wcn36xx_sta_to_priv(sta);
> -- 
> 1.7.9.5
> 
> 
> 
> ___
> wcn36xx mailing list
> wcn3...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/wcn36xx