[PATCH v8] ath10k: add LED and GPIO controlling support for various chipsets

[s . gottschall]

From: Sebastian Gottschall 

Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based 
chipsets with on chipset connected led's
using WMI Firmware API.
The LED device will get available named as "ath10k-phyX" at sysfs and can be 
controlled with various triggers.
adds also debugfs interface for gpio control.

Signed-off-by: Sebastian Gottschall 

v2  add correct gpio count per chipset and remove IPQ4019 support since this 
chipset does not make use of specific gpios)
v5  fix compiling without LED_CLASS and GPIOLIB support, fix also error by 
kbuild test robot which does not occur in standard builds. curious
v6  correct return values and fix comment style
v7  fix ath10k_unregister_led for compiling without LED_CLASS
v8  fix various code design issues reported by reviewers
---
 drivers/net/wireless/ath/ath10k/core.c| 221 +-
 drivers/net/wireless/ath/ath10k/core.h|  39 +-
 drivers/net/wireless/ath/ath10k/debug.c   | 146 
 drivers/net/wireless/ath/ath10k/hw.h  |   2 +
 drivers/net/wireless/ath/ath10k/mac.c |   5 +
 drivers/net/wireless/ath/ath10k/wmi-ops.h |  36 -
 drivers/net/wireless/ath/ath10k/wmi-tlv.c |  65 +
 drivers/net/wireless/ath/ath10k/wmi.c |  46 +++
 drivers/net/wireless/ath/ath10k/wmi.h |  36 +
 9 files changed, 593 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index f3ec13b80b20..769a246ad0fd 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -21,6 +21,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+
 
 #include "core.h"
 #include "mac.h"
@@ -65,6 +69,8 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] 
= {
.id = QCA988X_HW_2_0_VERSION,
.dev_id = QCA988X_2_0_DEVICE_ID,
.name = "qca988x hw2.0",
+   .led_pin = 1,
+   .gpio_count = 24, 
.patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
@@ -94,6 +100,8 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] 
= {
.id = QCA988X_HW_2_0_VERSION,
.dev_id = QCA988X_2_0_DEVICE_ID_UBNT,
.name = "qca988x hw2.0 ubiquiti",
+   .led_pin = 1,
+   .gpio_count = 24, 
.patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
@@ -123,6 +131,8 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.id = QCA9887_HW_1_0_VERSION,
.dev_id = QCA9887_1_0_DEVICE_ID,
.name = "qca9887 hw1.0",
+   .led_pin = 1,
+   .gpio_count = 24, 
.patch_load_addr = QCA9887_HW_1_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
@@ -267,6 +277,8 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.id = QCA99X0_HW_2_0_DEV_VERSION,
.dev_id = QCA99X0_2_0_DEVICE_ID,
.name = "qca99x0 hw2.0",
+   .led_pin = 17,
+   .gpio_count = 35, 
.patch_load_addr = QCA99X0_HW_2_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.otp_exe_param = 0x0700,
@@ -301,6 +313,8 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.id = QCA9984_HW_1_0_DEV_VERSION,
.dev_id = QCA9984_1_0_DEVICE_ID,
.name = "qca9984/qca9994 hw1.0",
+   .led_pin = 17,
+   .gpio_count = 35, 
.patch_load_addr = QCA9984_HW_1_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_EACH,
@@ -340,6 +354,8 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.id = QCA9888_HW_2_0_DEV_VERSION,
.dev_id = QCA9888_2_0_DEVICE_ID,
.name = "qca9888 hw2.0",
+   .led_pin = 17,
+   .gpio_count = 35, 
.patch_load_addr = QCA9888_HW_2_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_EACH,
@@ -2132,6 +2148,199 @@ static int ath10k_core_reset_rx_filter(struct ath10k 
*ar)
return 0;
 }
 
+#if IS_ENABLED(CONFIG_GPIOLIB)
+
+static int ath10k_gpio_pin_cfg_input(struct gpio_chip *chip, unsigned offset)
+{
+   struct ath10k_gpiocontrol *gpio = container_of(chip, struct 
ath10k_gpiocontrol, gchip);
+   ath10k_wmi_gpio_config(gpio->ar, offset, 1, WMI_GPIO_PULL_NONE, 
WMI_GPIO_INTTYPE_DISABLE); /* configure to input */
+   

Re: testing tool for packet delay

[Toke Høiland-Jørgensen]

sdnlabs Janakaraj  writes:

> Hello Toke,
> Thanks for sharing this information.
>
> I took a look at Flent yesterday and planning to test it by the
> weekend due to something things I have to catch up with.

Awesome! Let me know if you run into any problems :)

-Toke

Re: testing tool for packet delay

[sdnlabs Janakaraj]

Hello Toke,
Thanks for sharing this information.

I took a look at Flent yesterday and planning to test it by the
weekend due to something things I have to catch up with.



On Tue, Feb 20, 2018 at 6:13 AM, Toke Høiland-Jørgensen  wrote:
> Steve deRosier  writes:
>
>> On Mon, Feb 19, 2018 at 9:19 AM, sdnlabs Janakaraj  
>> wrote:
>>>
>>> Hello All,
>>>
>>> I am working on delay analysis of packets in wireless stacks. I am
>>> able to see lots of papers talk about therotical analysis. But I am
>>> more interested in practical evaluation.
>>>
>>> I am reaching out to developers community to learn how they actually
>>> evaluate the performance of the stack. In particular, I am looking for
>>> ideas to evaluate the delay experienced by packets within the
>>> mac802.11 stack.
>>>
>>
>> Hi Prabhu,
>>
>> Sounds like an interesting project. More often my instrumentation
>> focuses on aggregate performance and iperf throughput numbers suffices
>> for most of that. Occasionally I utilize internal performance measures
>> and/or data provided me by ftrace and related tools.
>>
>> If you're unfamiliar with it, I suggest you look at the Bufferbloat
>> and Make-wifi-fast projects. I suspect that their data and techniques
>> and tools might be of interest to you:
>>
>> https://www.bufferbloat.net/projects/make-wifi-fast/
>
> Bufferbloat/make-wifi-fast community member checking in ;)
>
> Basically, what we've been doing to analyse (and reduce) the latency of
> the queueing system in the WiFi stack, is to put it under load and
> measure how it behaves. This is not so much through the use of tracing
> tools as it is an end-to-end black-box measurement approach.
>
> The go-to mechanism for this is to run a latency measurement (either a
> simple ICMP ping, or a UDP measurement flow using a tool such as
> irtt[1]), then load the connection with one or more TCP flows and see
> how it impacts latency. You can of course vary the number of flows,
> diffserv markings, etc. to get different insights.
>
> I'm the author of a test tool that automates a lot of this and which can
> also collect a lot of statistics from the stack while doing so. The tool
> is called Flent[2] and is open source. Feel free to try it out and ask
> any questions that come up :)
>
> -Toke
>
> [1] https://github.com/peteheist/irtt/
> [2] https://flent.org

Re: [RFC PATCH 0/2] net: rfkill: gpio: Fix and support SerDev

[Carlo Caione]

On Tue, Feb 20, 2018 at 9:18 PM, Jeremy Cline  wrote:

> Great, thanks for all the info! I'll definitely keep you CC'ed on my
> progress. I'm still very new to kernel development so I expect it'll
> take me quite a while, but I do have a fair bit of time to devote to
> this.

Welcome to this crazy world ;)
Keep me on CC also, I have quite a bit of hw I can test the patches
on. Fell free also to reach me in private.
I was actually going to work on this myself but now I guess there are
too many people.

Cheers,

-- 
Carlo Caione  |  +44.7384.69.16.04  |  Endless

Re: [RFC PATCH 0/2] net: rfkill: gpio: Fix and support SerDev

[Jeremy Cline]

Hi Martin,

On 02/20/2018 03:26 PM, Martin Blumenstingl wrote:
> Hello Jeremy, Hello Hans,
> 
> On Tue, Feb 20, 2018 at 5:15 PM, Hans de Goede  wrote:
>> Hi,
>>
>> On 02/20/2018 03:36 PM, Carlo Caione wrote:
>>>
>>> On Tue, Feb 20, 2018 at 2:01 PM, Hans de Goede 
>>> wrote:

 Hi Carlo,
>>>
>>>
>>> Hi Hans,
>>>
 Is this for devices with a RTL8723BS chip? If so then they
 still will not work after this since there also no longer is
 a /dev/ttyS4 created for the UART for the bluetooth, instead
 you probably want:


 https://github.com/jwrdegoede/linux-sunxi/commit/c383dac5ea00738ac01d704d820aa548494fcd41

 Which also puts the /dev/ttyS4 back in place.
>>>
>>>
>>> Yeah, this problem came up while working on the RTL8723BS chip but the
>>> driver is also broken for the other two GPS devices supported by this
>>> driver.
>>> Thank you for the patch BTW.
>>>
 Regards,

 Hans

 p.s.

 My college Jeremy Cline in the Cc is looking into getting proper
 bluetooth support in place for the rtl8723bs using serdev binding
 and having everything in the kernel, as we now already do for bcm
 uart bluetooth modules.
>>>
>>>
>>> Wasn't also Martin (+CC) working on this? See
>>> https://www.spinics.net/lists/linux-bluetooth/msg73594.html
> thank you for CC'ing me Carlo!
> 
>> Ah I did not know that, cool.  Jeremy, this is probably a good starting
>> point :)   And you should probably coordinate with Martin on this.
> the status on this is:
> - Marcel wrote a tool to parse the config blob: [0]
> - the first patch from my series called "serdev: implement parity
> configuration" is now obsolete because an improved version from Ulrich
> Hecht has been merged: [1] (this requires a trivial change to the
> "serdev_device_set_parity" call in patch #9 of my series)
> - I still have Realtek serdev support on my TODO-list but with low priority
> 
> there was a discussion what has to be done to drop the "RFC" prefix
> from my series: [3]
> the quick summary (from my point of view):
> - if possible we should get rid of the config blob (don't use it at
> all or generate it in-memory - I couldn't make either of these work so
> far but I've not spent much time on it either)
> - create a "library" for the H5 protocol (similar to the H4 protocol)
> so the Realtek code doesn't have to be part of hci_h5.c
> - add ACPI support (and not just device-tree support)
> - testing with existing Realtek USB devices is needed
> 
> I have successfully tested v2 of my series on two Amlogic boards I
> have which both come with a RTL8723BS SDIO wifi/UART Bluetooth combo
> chip.
> that said, I only looked at Bluetooth support (I didn't test wifi or
> btcoex support) and I don't have any "Realtek USB Bluetooth" dongles
> to check that I didn't break support for the existing devices
> 
> @Jeremy: I definitely won't be able to update my patches for the v4.17
> cycle (and I'm not sure how much time I can dedicate to this for the
> v4.18 cycle).
> it would be great if you could keep me CC'ed on your patches so I can
> learn and test them on the boards I have

Great, thanks for all the info! I'll definitely keep you CC'ed on my
progress. I'm still very new to kernel development so I expect it'll
take me quite a while, but I do have a fair bit of time to devote to
this.


Regards,
Jeremy

Re: [RFC PATCH 0/2] net: rfkill: gpio: Fix and support SerDev

[Martin Blumenstingl]

Hello Jeremy, Hello Hans,

On Tue, Feb 20, 2018 at 5:15 PM, Hans de Goede  wrote:
> Hi,
>
> On 02/20/2018 03:36 PM, Carlo Caione wrote:
>>
>> On Tue, Feb 20, 2018 at 2:01 PM, Hans de Goede 
>> wrote:
>>>
>>> Hi Carlo,
>>
>>
>> Hi Hans,
>>
>>> Is this for devices with a RTL8723BS chip? If so then they
>>> still will not work after this since there also no longer is
>>> a /dev/ttyS4 created for the UART for the bluetooth, instead
>>> you probably want:
>>>
>>>
>>> https://github.com/jwrdegoede/linux-sunxi/commit/c383dac5ea00738ac01d704d820aa548494fcd41
>>>
>>> Which also puts the /dev/ttyS4 back in place.
>>
>>
>> Yeah, this problem came up while working on the RTL8723BS chip but the
>> driver is also broken for the other two GPS devices supported by this
>> driver.
>> Thank you for the patch BTW.
>>
>>> Regards,
>>>
>>> Hans
>>>
>>> p.s.
>>>
>>> My college Jeremy Cline in the Cc is looking into getting proper
>>> bluetooth support in place for the rtl8723bs using serdev binding
>>> and having everything in the kernel, as we now already do for bcm
>>> uart bluetooth modules.
>>
>>
>> Wasn't also Martin (+CC) working on this? See
>> https://www.spinics.net/lists/linux-bluetooth/msg73594.html
thank you for CC'ing me Carlo!

> Ah I did not know that, cool.  Jeremy, this is probably a good starting
> point :)   And you should probably coordinate with Martin on this.
the status on this is:
- Marcel wrote a tool to parse the config blob: [0]
- the first patch from my series called "serdev: implement parity
configuration" is now obsolete because an improved version from Ulrich
Hecht has been merged: [1] (this requires a trivial change to the
"serdev_device_set_parity" call in patch #9 of my series)
- I still have Realtek serdev support on my TODO-list but with low priority

there was a discussion what has to be done to drop the "RFC" prefix
from my series: [3]
the quick summary (from my point of view):
- if possible we should get rid of the config blob (don't use it at
all or generate it in-memory - I couldn't make either of these work so
far but I've not spent much time on it either)
- create a "library" for the H5 protocol (similar to the H4 protocol)
so the Realtek code doesn't have to be part of hci_h5.c
- add ACPI support (and not just device-tree support)
- testing with existing Realtek USB devices is needed

I have successfully tested v2 of my series on two Amlogic boards I
have which both come with a RTL8723BS SDIO wifi/UART Bluetooth combo
chip.
that said, I only looked at Bluetooth support (I didn't test wifi or
btcoex support) and I don't have any "Realtek USB Bluetooth" dongles
to check that I didn't break support for the existing devices

@Jeremy: I definitely won't be able to update my patches for the v4.17
cycle (and I'm not sure how much time I can dedicate to this for the
v4.18 cycle).
it would be great if you could keep me CC'ed on your patches so I can
learn and test them on the boards I have


Regards
Martin


[0] 
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/tools/rtlfw.c?id=8b21a74f2e473b88cadc8ad871c635ace969ee02
[1] 
https://github.com/torvalds/linux/commit/3a19cfcce105e481b02b14265c5b40c6c10ef60a
[2] https://www.spinics.net/lists/linux-bluetooth/msg73602.html
[3] https://www.spinics.net/lists/linux-bluetooth/msg73602.html

Re: [PATCH v7] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

Agreed, I am also not a fan of bloat code. I wasn't suggesting you
move it to the .h, just saying that if it were not static, that's how
I'd suggest doing it.

In this case, keep it static, keep it in the .c.  And use the blocking
I suggested. You will get the optimizer friendly result you're looking
for, but make it more readable and more-inline with the dominant style
for these things.

thats what i did already in my sourcetree



true, but consider that required structures like gpio_chip (ar->gpio) and
led_classdev arent defined in the kernel if these CONFIG options arent
configured. so i may move it into a separate function ,but the guards will
remain.
thats not my fault. thats a fault of the kernel api.


Hm. I assumed the names were still valid, even if the functionality
that uses it wasn't.  Understood.

In that case, I suggest moving the code to a separate static function
that can be guarded. It keeps the mess out of the main startup
function, makes it easier to read as it collapses to a single
self-documented function name, and gets rid of the label and jump.

yes but we have 2 guards. GPIOLIB and LED_CLASS
so the mess remaines in the same way with no change. the same unreadable 
code just moved (personally i think its not that unreadable since its small)





The rest of this looks OK to me.

okay. i already changed some code, based on your requests but will wait for
reply of you and for other comments until i send out a new version

I appreciate the extra work you've put in. I hadn't expected my
comments would've generated so much extra work; sorry about that. It's
looking good.
i just want it upstream. i have alot of usefull patches in my backhand 
and its now getting hard to maintain the code with new ath10k patches.
and at the end its not that much work as it seems. just a question of 
some seconds todo that changes. i can live with it.


Sebastian


--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH v7] ath10k: add LED and GPIO controlling support for various chipsets

[Steve deRosier]

On Tue, Feb 20, 2018 at 10:06 AM, Sebastian Gottschall
 wrote:
> Am 20.02.2018 um 17:52 schrieb Steve deRosier:
>>
>>
>>> +static int ath10k_register_gpio_chip(struct ath10k *ar)
>>> +{
>>> +   struct ath10k_gpiocontrol *gpio;
>>> +   gpio = kzalloc(sizeof(struct ath10k_gpiocontrol), GFP_KERNEL);
>>> +   if (!gpio) {
>>> +   return -ENOMEM;
>>> +   }
>>> +
>>> +   snprintf(gpio->label, sizeof(gpio->label), "ath10k-%s",
>>> +wiphy_name(ar->hw->wiphy));
>>> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,5,0)
>>> +   gpio->gchip.parent = ar->dev;
>>> +#else
>>> +   gpio->gchip.dev = ar->dev;
>>> +#endif
>>> +   gpio->gchip.base = -1;  /* determine base automatically */
>>
>> I may be wrong, but I think that version guards are unwelcome here.
>> The patch is supposed to go and apply specifically to the upstream
>> version, which is clearly >= KERNEL_VERSION(4,5,0). I think you can
>> drop this, only use the 'gpio->gchip.parent = ar->dev;' and call it
>> good. This fixup should be picked up by Backports.  I understand that
>> you might need to keep it for your internal tree, but I don't think
>> the maintainers want to see this.
>
> the original patch comes from my sources which are supposed to work with
> compat-wireless für multiple kernels. but for sure i can change that :-)
>

I understand. I've got some code that looks similar. However, I don't
think the practice is to allow it upstream, the practice now is to
rely on Backports to know about these tranformations. Someone here
will correct me if I'm wrong.

Just prune it for going upstream. :-)


>>
>>
>>> +/* remove GPIO chip */
>>> +static void ath10k_unregister_gpio_chip(struct ath10k *ar)
>>> +{
>>> +#ifdef CONFIG_GPIOLIB
>>> +   struct ath10k_gpiocontrol *gpio = ar->gpio;
>>> +   if (gpio) {
>>> +   gpiochip_remove(>gchip);
>>> +   kfree(gpio);
>>> +   }
>>> +#endif
>>> +}
>>
>> Instead of entering/exiting the guards inside every function, I think
>> the usually accepted way to handle this is to place a block in the
>> that looks basically like:
>>
>> #ifdef CONFIG_GPIOLIB
>> static void ath10k_unregister_gpio_chip(struct ath10k *ar) {
>> struct ath10k_gpiocontrol *gpio = ar->gpio;
>> if (gpio) {
>> gpiochip_remove(>gchip);
>> kfree(gpio);
>> }
>>   }
>>
>> next function
>> next function...
>>
>> #else
>> static void ath10k_unregister_gpio_chip(struct ath10k *ar) {
>>   }
>> next function
>> next function...
>> #endif
>>
>> If they weren't static, you'd do it in the .h file, with the
>> declaration of the full function there and the definition in the .c.
>>
>> I may be nit-picking and your style is perfectly acceptable to the
>> other maintainers.
>
> i'm not a fan of bloat code. and making funktions static which are just
> called one will allow the compiler to optimize the code better
> than making it non static. that makes no sense here for sure. its just a
> question how you handle it.

Agreed, I am also not a fan of bloat code. I wasn't suggesting you
move it to the .h, just saying that if it were not static, that's how
I'd suggest doing it.

In this case, keep it static, keep it in the .c.  And use the blocking
I suggested. You will get the optimizer friendly result you're looking
for, but make it more readable and more-inline with the dominant style
for these things.


>>
>>
>>
>>> +
>>> +static void ath10k_unregister_led(struct ath10k *ar)
>>> +{
>>> +#if defined (CONFIG_GPIOLIB) && defined(CONFIG_LEDS_CLASS)
>>> +   if (ar->gpio)
>>> +   led_classdev_unregister(>gpio->cdev);
>>> +#endif
>>> +}
>>> +
>>> +
>>>   int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode
>>> mode,
>>>const struct ath10k_fw_components *fw)
>>>   {
>>>  int status;
>>>  u32 val;
>>> -
>>>  lockdep_assert_held(>conf_mutex);
>>>
>> Whitespace change for no apparent reason.
>
> count it as typo
>
>>
>>> @@ -2372,8 +2524,32 @@ int ath10k_core_start(struct ath10k *ar, enum
>>> ath10k_firmware_mode mode,
>>>  if (status)
>>>  goto err_hif_stop;
>>>
>>> -   return 0;
>>>
>>> +#ifdef CONFIG_GPIOLIB
>>> +   /* LED Code */
>>> +   if (ar->hw_params.led_pin) { /* only attach if non zero since
>>> some chipsets are unsupported yet */
>>> +   if (!ar->gpio_attached) {
>>> +   status = ath10k_register_gpio_chip(ar);
>>> +   if (status) {
>>> +   goto err_no_led;
>>> +   }
>>> +#ifdef CONFIG_LEDS_CLASS
>>> +   ar->gpio_attached = 1;
>>> +   ar->gpio->wifi_led.active_low = 1;
>>> +   ar->gpio->wifi_led.gpio = ar->hw_params.led_pin;
>>> +   ar->gpio->wifi_led.name = ar->gpio->label;
>>> +   

Re: [PATCH v7] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

Am 20.02.2018 um 17:52 schrieb Steve deRosier:



+static int ath10k_register_gpio_chip(struct ath10k *ar)
+{
+   struct ath10k_gpiocontrol *gpio;
+   gpio = kzalloc(sizeof(struct ath10k_gpiocontrol), GFP_KERNEL);
+   if (!gpio) {
+   return -ENOMEM;
+   }
+
+   snprintf(gpio->label, sizeof(gpio->label), "ath10k-%s",
+wiphy_name(ar->hw->wiphy));
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,5,0)
+   gpio->gchip.parent = ar->dev;
+#else
+   gpio->gchip.dev = ar->dev;
+#endif
+   gpio->gchip.base = -1;  /* determine base automatically */

I may be wrong, but I think that version guards are unwelcome here.
The patch is supposed to go and apply specifically to the upstream
version, which is clearly >= KERNEL_VERSION(4,5,0). I think you can
drop this, only use the 'gpio->gchip.parent = ar->dev;' and call it
good. This fixup should be picked up by Backports.  I understand that
you might need to keep it for your internal tree, but I don't think
the maintainers want to see this.
the original patch comes from my sources which are supposed to work with 
compat-wireless für multiple kernels. but for sure i can change that :-)




+/* remove GPIO chip */
+static void ath10k_unregister_gpio_chip(struct ath10k *ar)
+{
+#ifdef CONFIG_GPIOLIB
+   struct ath10k_gpiocontrol *gpio = ar->gpio;
+   if (gpio) {
+   gpiochip_remove(>gchip);
+   kfree(gpio);
+   }
+#endif
+}

Instead of entering/exiting the guards inside every function, I think
the usually accepted way to handle this is to place a block in the
that looks basically like:

#ifdef CONFIG_GPIOLIB
static void ath10k_unregister_gpio_chip(struct ath10k *ar) {
struct ath10k_gpiocontrol *gpio = ar->gpio;
if (gpio) {
gpiochip_remove(>gchip);
kfree(gpio);
}
  }

next function
next function...

#else
static void ath10k_unregister_gpio_chip(struct ath10k *ar) {
  }
next function
next function...
#endif

If they weren't static, you'd do it in the .h file, with the
declaration of the full function there and the definition in the .c.

I may be nit-picking and your style is perfectly acceptable to the
other maintainers.
i'm not a fan of bloat code. and making funktions static which are just 
called one will allow the compiler to optimize the code better
than making it non static. that makes no sense here for sure. its just a 
question how you handle it.




+
+static void ath10k_unregister_led(struct ath10k *ar)
+{
+#if defined (CONFIG_GPIOLIB) && defined(CONFIG_LEDS_CLASS)
+   if (ar->gpio)
+   led_classdev_unregister(>gpio->cdev);
+#endif
+}
+
+
  int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
   const struct ath10k_fw_components *fw)
  {
 int status;
 u32 val;
-
 lockdep_assert_held(>conf_mutex);


Whitespace change for no apparent reason.

count it as typo



@@ -2372,8 +2524,32 @@ int ath10k_core_start(struct ath10k *ar, enum 
ath10k_firmware_mode mode,
 if (status)
 goto err_hif_stop;

-   return 0;

+#ifdef CONFIG_GPIOLIB
+   /* LED Code */
+   if (ar->hw_params.led_pin) { /* only attach if non zero since some 
chipsets are unsupported yet */
+   if (!ar->gpio_attached) {
+   status = ath10k_register_gpio_chip(ar);
+   if (status) {
+   goto err_no_led;
+   }
+#ifdef CONFIG_LEDS_CLASS
+   ar->gpio_attached = 1;
+   ar->gpio->wifi_led.active_low = 1;
+   ar->gpio->wifi_led.gpio = ar->hw_params.led_pin;
+   ar->gpio->wifi_led.name = ar->gpio->label;
+   ar->gpio->wifi_led.default_state = 
LEDS_GPIO_DEFSTATE_KEEP;
+
+   ath10k_add_led(ar, >gpio->wifi_led);
+#endif
+   }
+   ath10k_wmi_gpio_config(ar, ar->hw_params.led_pin, 0, 
WMI_GPIO_PULL_NONE, WMI_GPIO_INTTYPE_DISABLE); /* configure to output */
+   ath10k_wmi_gpio_output(ar, ar->hw_params.led_pin, 1);
+   }
+err_no_led:;
+#endif
+
+   return 0;
  err_hif_stop:
 ath10k_hif_stop(ar);
  err_htt_rx_detach:

The guards make it harder to read. In this chunk, every component
should be defined acceptably even if the CONFIG flags aren't defined
because they're all under your control. Make sure they are, and then
you can drop the guards here. The only trick is to be sure that any
accessed struct members that are protected by guards are abstracted
and only accessed inside your guarded functions. Alternately, you
could encapsulate it into a function ath10k_core_gpios_start() and
just have the single call there. The additional benefit being that you
don't need the err_no_led: jump.
true, but consider that required structures like gpio_chip (ar->gpio) 
and led_classdev arent defined in the 

Re: [RFC v4 3/6] nl80211: Implement TX of control port frames

[Denis Kenzior]

Hi Johannes,

On 02/19/2018 06:44 AM, Johannes Berg wrote:

On Wed, 2018-01-31 at 19:04 -0600, Denis Kenzior wrote:


+   switch (wdev->iftype) {
+   case NL80211_IFTYPE_STATION:
+   if (wdev->current_bss)
+   break;
+   err = -ENOTCONN;
+   goto out;
+   default:
+   err = -EOPNOTSUPP;
+   goto out;
+   }


Why restrict this to client mode? At the very least, P2P_CLIENT really
should be listed there, but I'm not sure why not also support it in
IBSS, and AP/P2P_GO/AP_VLAN modes?

We could do this in a separate patch, but then we have to define
different flags for the modes which seems somewhat pointless.


I've no means of testing the other modes at this time.  So I'm not sure 
what to tell you.  I can respin with IFTYPE_P2P_CLIENT in the 
switch/case (or you can amend and do so).


Regards,
-Denis

Re: [PATCH v7] ath10k: add LED and GPIO controlling support for various chipsets

[Steve deRosier]

Hi Sebastian,

On Mon, Feb 19, 2018 at 11:32 PM,   wrote:
> From: Sebastian Gottschall 
>
> Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based 
> chipsets with on chipset connected led's
> using WMI Firmware API.
> The LED device will get available named as "ath10k-phyX" at sysfs and can be 
> controlled with various triggers.
> adds also debugfs interface for gpio control.
>
> Signed-off-by: Sebastian Gottschall 
>
> v2  add correct gpio count per chipset and remove IPQ4019 support since this 
> chipset does not make use of specific gpios)
> v5  fix compiling without LED_CLASS and GPIOLIB support, fix also error by 
> kbuild test robot which does not occur in standard builds. curious
> v6  correct return values and fix comment style
> v7  fix ath10k_unregister_led for compiling without LED_CLASS
> Wq
> ---
>  drivers/net/wireless/ath/ath10k/core.c| 183 
> +-
>  drivers/net/wireless/ath/ath10k/core.h|  20 +++-
>  drivers/net/wireless/ath/ath10k/debug.c   | 146 
>  drivers/net/wireless/ath/ath10k/hw.h  |   2 +
>  drivers/net/wireless/ath/ath10k/mac.c |   6 +
>  drivers/net/wireless/ath/ath10k/wmi-ops.h |  36 +-
>  drivers/net/wireless/ath/ath10k/wmi-tlv.c |  65 +++
>  drivers/net/wireless/ath/ath10k/wmi.c |  46 
>  drivers/net/wireless/ath/ath10k/wmi.h |  36 ++
>  9 files changed, 536 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c 
> b/drivers/net/wireless/ath/ath10k/core.c
> index f3ec13b80b20..e50977f97b18 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
...
> +static int ath10k_register_gpio_chip(struct ath10k *ar)
> +{
> +   struct ath10k_gpiocontrol *gpio;
> +   gpio = kzalloc(sizeof(struct ath10k_gpiocontrol), GFP_KERNEL);
> +   if (!gpio) {
> +   return -ENOMEM;
> +   }
> +
> +   snprintf(gpio->label, sizeof(gpio->label), "ath10k-%s",
> +wiphy_name(ar->hw->wiphy));
> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,5,0)
> +   gpio->gchip.parent = ar->dev;
> +#else
> +   gpio->gchip.dev = ar->dev;
> +#endif
> +   gpio->gchip.base = -1;  /* determine base automatically */

I may be wrong, but I think that version guards are unwelcome here.
The patch is supposed to go and apply specifically to the upstream
version, which is clearly >= KERNEL_VERSION(4,5,0). I think you can
drop this, only use the 'gpio->gchip.parent = ar->dev;' and call it
good. This fixup should be picked up by Backports.  I understand that
you might need to keep it for your internal tree, but I don't think
the maintainers want to see this.


> +/* remove GPIO chip */
> +static void ath10k_unregister_gpio_chip(struct ath10k *ar)
> +{
> +#ifdef CONFIG_GPIOLIB
> +   struct ath10k_gpiocontrol *gpio = ar->gpio;
> +   if (gpio) {
> +   gpiochip_remove(>gchip);
> +   kfree(gpio);
> +   }
> +#endif
> +}

Instead of entering/exiting the guards inside every function, I think
the usually accepted way to handle this is to place a block in the
that looks basically like:

#ifdef CONFIG_GPIOLIB
static void ath10k_unregister_gpio_chip(struct ath10k *ar) {
   struct ath10k_gpiocontrol *gpio = ar->gpio;
   if (gpio) {
   gpiochip_remove(>gchip);
   kfree(gpio);
   }
 }

next function
next function...

#else
static void ath10k_unregister_gpio_chip(struct ath10k *ar) {
 }
next function
next function...
#endif

If they weren't static, you'd do it in the .h file, with the
declaration of the full function there and the definition in the .c.

I may be nit-picking and your style is perfectly acceptable to the
other maintainers.


> +
> +static void ath10k_unregister_led(struct ath10k *ar)
> +{
> +#if defined (CONFIG_GPIOLIB) && defined(CONFIG_LEDS_CLASS)
> +   if (ar->gpio)
> +   led_classdev_unregister(>gpio->cdev);
> +#endif
> +}
> +
> +
>  int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
>   const struct ath10k_fw_components *fw)
>  {
> int status;
> u32 val;
> -
> lockdep_assert_held(>conf_mutex);
>

Whitespace change for no apparent reason.

> @@ -2372,8 +2524,32 @@ int ath10k_core_start(struct ath10k *ar, enum 
> ath10k_firmware_mode mode,
> if (status)
> goto err_hif_stop;
>
> -   return 0;
>
> +#ifdef CONFIG_GPIOLIB
> +   /* LED Code */
> +   if (ar->hw_params.led_pin) { /* only attach if non zero since some 
> chipsets are unsupported yet */
> +   if (!ar->gpio_attached) {
> +   status = ath10k_register_gpio_chip(ar);
> +   if (status) {
> +   goto err_no_led;
> +   }
> +#ifdef CONFIG_LEDS_CLASS
> +

Re: [RFC PATCH 0/2] net: rfkill: gpio: Fix and support SerDev

[Hans de Goede]

Hi,

On 02/20/2018 03:36 PM, Carlo Caione wrote:

On Tue, Feb 20, 2018 at 2:01 PM, Hans de Goede  wrote:

Hi Carlo,


Hi Hans,


Is this for devices with a RTL8723BS chip? If so then they
still will not work after this since there also no longer is
a /dev/ttyS4 created for the UART for the bluetooth, instead
you probably want:

https://github.com/jwrdegoede/linux-sunxi/commit/c383dac5ea00738ac01d704d820aa548494fcd41

Which also puts the /dev/ttyS4 back in place.


Yeah, this problem came up while working on the RTL8723BS chip but the
driver is also broken for the other two GPS devices supported by this
driver.
Thank you for the patch BTW.


Regards,

Hans

p.s.

My college Jeremy Cline in the Cc is looking into getting proper
bluetooth support in place for the rtl8723bs using serdev binding
and having everything in the kernel, as we now already do for bcm
uart bluetooth modules.


Wasn't also Martin (+CC) working on this? See
https://www.spinics.net/lists/linux-bluetooth/msg73594.html


Ah I did not know that, cool.  Jeremy, this is probably a good starting
point :)   And you should probably coordinate with Martin on this.

Regards,

Hans

Re: [RFC PATCH 0/2] net: rfkill: gpio: Fix and support SerDev

[Marcel Holtmann]

Hi Carlo,

>> Is this for devices with a RTL8723BS chip? If so then they
>> still will not work after this since there also no longer is
>> a /dev/ttyS4 created for the UART for the bluetooth, instead
>> you probably want:
>> 
>> https://github.com/jwrdegoede/linux-sunxi/commit/c383dac5ea00738ac01d704d820aa548494fcd41
>> 
>> Which also puts the /dev/ttyS4 back in place.
> 
> Yeah, this problem came up while working on the RTL8723BS chip but the
> driver is also broken for the other two GPS devices supported by this
> driver.
> Thank you for the patch BTW.
> 
>> Regards,
>> 
>> Hans
>> 
>> p.s.
>> 
>> My college Jeremy Cline in the Cc is looking into getting proper
>> bluetooth support in place for the rtl8723bs using serdev binding
>> and having everything in the kernel, as we now already do for bcm
>> uart bluetooth modules.
> 
> Wasn't also Martin (+CC) working on this? See
> https://www.spinics.net/lists/linux-bluetooth/msg73594.html

I remember that. I think we need a non-RFC version against latest 
bluetooth-next tree.

Regards

Marcel

[PATCH 06/12] staging: wilc1000: rename pstrSetBeaconParam to avoid camelCase

[Ajay Singh]

Fix "Avoid camelCase" issue found by checkpatch.pl script.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 51 +++
 1 file changed, 25 insertions(+), 26 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 57f0201..9eb808e 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1986,8 +1986,7 @@ static s32 handle_get_inactive_time(struct wilc_vif *vif,
return result;
 }
 
-static void handle_add_beacon(struct wilc_vif *vif,
- struct beacon_attr *pstrSetBeaconParam)
+static void handle_add_beacon(struct wilc_vif *vif, struct beacon_attr *param)
 {
s32 result = 0;
struct wid wid;
@@ -1995,38 +1994,38 @@ static void handle_add_beacon(struct wilc_vif *vif,
 
wid.id = (u16)WID_ADD_BEACON;
wid.type = WID_BIN;
-   wid.size = pstrSetBeaconParam->head_len + pstrSetBeaconParam->tail_len 
+ 16;
+   wid.size = param->head_len + param->tail_len + 16;
wid.val = kmalloc(wid.size, GFP_KERNEL);
if (!wid.val)
goto ERRORHANDLER;
 
cur_byte = wid.val;
-   *cur_byte++ = (pstrSetBeaconParam->interval & 0xFF);
-   *cur_byte++ = ((pstrSetBeaconParam->interval >> 8) & 0xFF);
-   *cur_byte++ = ((pstrSetBeaconParam->interval >> 16) & 0xFF);
-   *cur_byte++ = ((pstrSetBeaconParam->interval >> 24) & 0xFF);
+   *cur_byte++ = (param->interval & 0xFF);
+   *cur_byte++ = ((param->interval >> 8) & 0xFF);
+   *cur_byte++ = ((param->interval >> 16) & 0xFF);
+   *cur_byte++ = ((param->interval >> 24) & 0xFF);
 
-   *cur_byte++ = (pstrSetBeaconParam->dtim_period & 0xFF);
-   *cur_byte++ = ((pstrSetBeaconParam->dtim_period >> 8) & 0xFF);
-   *cur_byte++ = ((pstrSetBeaconParam->dtim_period >> 16) & 0xFF);
-   *cur_byte++ = ((pstrSetBeaconParam->dtim_period >> 24) & 0xFF);
+   *cur_byte++ = (param->dtim_period & 0xFF);
+   *cur_byte++ = ((param->dtim_period >> 8) & 0xFF);
+   *cur_byte++ = ((param->dtim_period >> 16) & 0xFF);
+   *cur_byte++ = ((param->dtim_period >> 24) & 0xFF);
 
-   *cur_byte++ = (pstrSetBeaconParam->head_len & 0xFF);
-   *cur_byte++ = ((pstrSetBeaconParam->head_len >> 8) & 0xFF);
-   *cur_byte++ = ((pstrSetBeaconParam->head_len >> 16) & 0xFF);
-   *cur_byte++ = ((pstrSetBeaconParam->head_len >> 24) & 0xFF);
+   *cur_byte++ = (param->head_len & 0xFF);
+   *cur_byte++ = ((param->head_len >> 8) & 0xFF);
+   *cur_byte++ = ((param->head_len >> 16) & 0xFF);
+   *cur_byte++ = ((param->head_len >> 24) & 0xFF);
 
-   memcpy(cur_byte, pstrSetBeaconParam->head, 
pstrSetBeaconParam->head_len);
-   cur_byte += pstrSetBeaconParam->head_len;
+   memcpy(cur_byte, param->head, param->head_len);
+   cur_byte += param->head_len;
 
-   *cur_byte++ = (pstrSetBeaconParam->tail_len & 0xFF);
-   *cur_byte++ = ((pstrSetBeaconParam->tail_len >> 8) & 0xFF);
-   *cur_byte++ = ((pstrSetBeaconParam->tail_len >> 16) & 0xFF);
-   *cur_byte++ = ((pstrSetBeaconParam->tail_len >> 24) & 0xFF);
+   *cur_byte++ = (param->tail_len & 0xFF);
+   *cur_byte++ = ((param->tail_len >> 8) & 0xFF);
+   *cur_byte++ = ((param->tail_len >> 16) & 0xFF);
+   *cur_byte++ = ((param->tail_len >> 24) & 0xFF);
 
-   if (pstrSetBeaconParam->tail)
-   memcpy(cur_byte, pstrSetBeaconParam->tail, 
pstrSetBeaconParam->tail_len);
-   cur_byte += pstrSetBeaconParam->tail_len;
+   if (param->tail)
+   memcpy(cur_byte, param->tail, param->tail_len);
+   cur_byte += param->tail_len;
 
result = wilc_send_config_pkt(vif, SET_CFG, , 1,
  wilc_get_vif_idx(vif));
@@ -2035,8 +2034,8 @@ static void handle_add_beacon(struct wilc_vif *vif,
 
 ERRORHANDLER:
kfree(wid.val);
-   kfree(pstrSetBeaconParam->head);
-   kfree(pstrSetBeaconParam->tail);
+   kfree(param->head);
+   kfree(param->tail);
 }
 
 static void handle_del_beacon(struct wilc_vif *vif)
-- 
2.7.4

[PATCH 04/12] staging: wilc1000: rename pu32InactiveTime to avoid camelCase

[Ajay Singh]

Fix "Avoid camelCase" issue found by checkpatch.pl script.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index f79618a..fd21765 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -3164,7 +3164,7 @@ int wilc_set_operation_mode(struct wilc_vif *vif, u32 
mode)
 }
 
 s32 wilc_get_inactive_time(struct wilc_vif *vif, const u8 *mac,
-  u32 *pu32InactiveTime)
+  u32 *out_val)
 {
s32 result = 0;
struct host_if_msg msg;
@@ -3187,7 +3187,7 @@ s32 wilc_get_inactive_time(struct wilc_vif *vif, const u8 
*mac,
else
wait_for_completion(_drv->comp_inactive_time);
 
-   *pu32InactiveTime = inactive_time;
+   *out_val = inactive_time;
 
return result;
 }
-- 
2.7.4

[PATCH 01/12] staging: wilc1000: rename pu8HdnNtwrksWidVal to avoid camelCase

[Ajay Singh]

Fix "Avoid camelCase" issue found by checkpatch.pl script.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 6f93966..f3a56e5 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -754,7 +754,7 @@ static s32 handle_scan(struct wilc_vif *vif, struct 
scan_attr *scan_info)
u32 i;
u8 *buffer;
u8 valuesize = 0;
-   u8 *pu8HdnNtwrksWidVal = NULL;
+   u8 *hdn_ntwk_wid_val = NULL;
struct host_if_drv *hif_drv = vif->hif_drv;
 
hif_drv->usr_scan_req.scan_result = scan_info->result;
@@ -780,8 +780,8 @@ static s32 handle_scan(struct wilc_vif *vif, struct 
scan_attr *scan_info)
 
for (i = 0; i < scan_info->hidden_network.n_ssids; i++)
valuesize += ((scan_info->hidden_network.net_info[i].ssid_len) 
+ 1);
-   pu8HdnNtwrksWidVal = kmalloc(valuesize + 1, GFP_KERNEL);
-   wid_list[index].val = pu8HdnNtwrksWidVal;
+   hdn_ntwk_wid_val = kmalloc(valuesize + 1, GFP_KERNEL);
+   wid_list[index].val = hdn_ntwk_wid_val;
if (wid_list[index].val) {
buffer = wid_list[index].val;
 
@@ -858,7 +858,7 @@ static s32 handle_scan(struct wilc_vif *vif, struct 
scan_attr *scan_info)
kfree(scan_info->hidden_network.net_info);
scan_info->hidden_network.net_info = NULL;
 
-   kfree(pu8HdnNtwrksWidVal);
+   kfree(hdn_ntwk_wid_val);
 
return result;
 }
-- 
2.7.4

[PATCH 00/12] staging: wilc1000: fixes to avoid use of camelCase in host interface

[Ajay Singh]

This patch series contains fixes for "Avoid camelCase" issues found by
checkpatch.pl script.

Ajay Singh (12):
  staging: wilc1000: rename pu8HdnNtwrksWidVal to avoid camelCase
  staging: wilc1000: rename ptstrJoinBssParam to avoid camelCase
  staging: wilc1000: rename variables using camelCase in
handle_rcvd_ntwrk_info()
  staging: wilc1000: rename pu32InactiveTime to avoid camelCase
  staging: wilc1000: rename Handle_SetMulticastFilter to avoid camelCase
  staging: wilc1000: rename pstrSetBeaconParam to avoid camelCase
  staging: wilc1000: rename pstrStatistics to avoid camelCase
  staging: wilc1000: rename strDisconnectNotifInfo to avoid camelCase
  staging: wilc1000: rename pstrDelStaParam to avoid camelCase
  staging: wilc1000: rename pstrStationParam to avoid camelCase
  staging: wilc1000: rename _WPAPtk_end_case_ label to avoid camelCase
  staging: wilc1000: rename _WPARxGtk_end_case_ label to avoid camelCase

 drivers/staging/wilc1000/host_interface.c | 299 +++---
 1 file changed, 147 insertions(+), 152 deletions(-)

-- 
2.7.4

[PATCH 02/12] staging: wilc1000: rename ptstrJoinBssParam to avoid camelCase

[Ajay Singh]

Fix "Avoid camelCase" issue found by checkpatch.pl script.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 78 +++
 1 file changed, 39 insertions(+), 39 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index f3a56e5..0f1eb17 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -909,7 +909,7 @@ static s32 handle_connect(struct wilc_vif *vif,
struct wid wid_list[8];
u32 wid_cnt = 0, dummyval = 0;
u8 *cur_byte = NULL;
-   struct join_bss_param *ptstrJoinBssParam;
+   struct join_bss_param *bss_param;
struct host_if_drv *hif_drv = vif->hif_drv;
 
if (memcmp(pstrHostIFconnectAttr->bssid, wilc_connected_ssid, ETH_ALEN) 
== 0) {
@@ -918,8 +918,8 @@ static s32 handle_connect(struct wilc_vif *vif,
return result;
}
 
-   ptstrJoinBssParam = pstrHostIFconnectAttr->params;
-   if (!ptstrJoinBssParam) {
+   bss_param = pstrHostIFconnectAttr->params;
+   if (!bss_param) {
netdev_err(vif->ndev, "Required BSSID not found\n");
result = -ENOENT;
goto ERRORHANDLER;
@@ -1031,8 +1031,8 @@ static s32 handle_connect(struct wilc_vif *vif,
netdev_err(vif->ndev, "Channel out of range\n");
*(cur_byte++) = 0xFF;
}
-   *(cur_byte++)  = (ptstrJoinBssParam->cap_info) & 0xFF;
-   *(cur_byte++)  = ((ptstrJoinBssParam->cap_info) >> 8) & 0xFF;
+   *(cur_byte++)  = (bss_param->cap_info) & 0xFF;
+   *(cur_byte++)  = ((bss_param->cap_info) >> 8) & 0xFF;
 
if (pstrHostIFconnectAttr->bssid)
memcpy(cur_byte, pstrHostIFconnectAttr->bssid, 6);
@@ -1042,57 +1042,57 @@ static s32 handle_connect(struct wilc_vif *vif,
memcpy(cur_byte, pstrHostIFconnectAttr->bssid, 6);
cur_byte += 6;
 
-   *(cur_byte++)  = (ptstrJoinBssParam->beacon_period) & 0xFF;
-   *(cur_byte++)  = ((ptstrJoinBssParam->beacon_period) >> 8) & 0xFF;
-   *(cur_byte++)  =  ptstrJoinBssParam->dtim_period;
+   *(cur_byte++)  = (bss_param->beacon_period) & 0xFF;
+   *(cur_byte++)  = ((bss_param->beacon_period) >> 8) & 0xFF;
+   *(cur_byte++)  =  bss_param->dtim_period;
 
-   memcpy(cur_byte, ptstrJoinBssParam->supp_rates, MAX_RATES_SUPPORTED + 
1);
+   memcpy(cur_byte, bss_param->supp_rates, MAX_RATES_SUPPORTED + 1);
cur_byte += (MAX_RATES_SUPPORTED + 1);
 
-   *(cur_byte++)  =  ptstrJoinBssParam->wmm_cap;
-   *(cur_byte++)  = ptstrJoinBssParam->uapsd_cap;
+   *(cur_byte++)  =  bss_param->wmm_cap;
+   *(cur_byte++)  = bss_param->uapsd_cap;
 
-   *(cur_byte++)  = ptstrJoinBssParam->ht_capable;
-   hif_drv->usr_conn_req.ht_capable = ptstrJoinBssParam->ht_capable;
+   *(cur_byte++)  = bss_param->ht_capable;
+   hif_drv->usr_conn_req.ht_capable = bss_param->ht_capable;
 
-   *(cur_byte++)  =  ptstrJoinBssParam->rsn_found;
-   *(cur_byte++)  =  ptstrJoinBssParam->rsn_grp_policy;
-   *(cur_byte++) =  ptstrJoinBssParam->mode_802_11i;
+   *(cur_byte++)  =  bss_param->rsn_found;
+   *(cur_byte++)  =  bss_param->rsn_grp_policy;
+   *(cur_byte++) =  bss_param->mode_802_11i;
 
-   memcpy(cur_byte, ptstrJoinBssParam->rsn_pcip_policy, 
sizeof(ptstrJoinBssParam->rsn_pcip_policy));
-   cur_byte += sizeof(ptstrJoinBssParam->rsn_pcip_policy);
+   memcpy(cur_byte, bss_param->rsn_pcip_policy, 
sizeof(bss_param->rsn_pcip_policy));
+   cur_byte += sizeof(bss_param->rsn_pcip_policy);
 
-   memcpy(cur_byte, ptstrJoinBssParam->rsn_auth_policy, 
sizeof(ptstrJoinBssParam->rsn_auth_policy));
-   cur_byte += sizeof(ptstrJoinBssParam->rsn_auth_policy);
+   memcpy(cur_byte, bss_param->rsn_auth_policy, 
sizeof(bss_param->rsn_auth_policy));
+   cur_byte += sizeof(bss_param->rsn_auth_policy);
 
-   memcpy(cur_byte, ptstrJoinBssParam->rsn_cap, 
sizeof(ptstrJoinBssParam->rsn_cap));
-   cur_byte += sizeof(ptstrJoinBssParam->rsn_cap);
+   memcpy(cur_byte, bss_param->rsn_cap, sizeof(bss_param->rsn_cap));
+   cur_byte += sizeof(bss_param->rsn_cap);
 
*(cur_byte++) = REAL_JOIN_REQ;
-   *(cur_byte++) = ptstrJoinBssParam->noa_enabled;
+   *(cur_byte++) = bss_param->noa_enabled;
 
-   if (ptstrJoinBssParam->noa_enabled) {
-   *(cur_byte++) = (ptstrJoinBssParam->tsf) & 0xFF;
-   *(cur_byte++) = ((ptstrJoinBssParam->tsf) >> 8) & 0xFF;
-   *(cur_byte++) = ((ptstrJoinBssParam->tsf) >> 16) & 0xFF;
-   *(cur_byte++) = ((ptstrJoinBssParam->tsf) >> 24) & 0xFF;
+   if (bss_param->noa_enabled) {
+   *(cur_byte++) = (bss_param->tsf) & 0xFF;
+   *(cur_byte++) = ((bss_param->tsf) >> 8) & 0xFF;
+   *(cur_byte++) = ((bss_param->tsf) >> 16) & 0xFF;
+   

[PATCH 10/12] staging: wilc1000: rename pstrStationParam to avoid camelCase

[Ajay Singh]

Fix "Avoid camelCase" issue found by checkpatch.pl script.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 46 +++
 1 file changed, 22 insertions(+), 24 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 8ec33b3..8528ff8 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -2061,40 +2061,38 @@ static void handle_del_beacon(struct wilc_vif *vif)
 }
 
 static u32 WILC_HostIf_PackStaParam(u8 *pu8Buffer,
-   struct add_sta_param *pstrStationParam)
+   struct add_sta_param *param)
 {
u8 *cur_byte;
 
cur_byte = pu8Buffer;
 
-   memcpy(cur_byte, pstrStationParam->bssid, ETH_ALEN);
+   memcpy(cur_byte, param->bssid, ETH_ALEN);
cur_byte +=  ETH_ALEN;
 
-   *cur_byte++ = pstrStationParam->aid & 0xFF;
-   *cur_byte++ = (pstrStationParam->aid >> 8) & 0xFF;
+   *cur_byte++ = param->aid & 0xFF;
+   *cur_byte++ = (param->aid >> 8) & 0xFF;
 
-   *cur_byte++ = pstrStationParam->rates_len;
-   if (pstrStationParam->rates_len > 0)
-   memcpy(cur_byte, pstrStationParam->rates,
-  pstrStationParam->rates_len);
-   cur_byte += pstrStationParam->rates_len;
+   *cur_byte++ = param->rates_len;
+   if (param->rates_len > 0)
+   memcpy(cur_byte, param->rates, param->rates_len);
+   cur_byte += param->rates_len;
 
-   *cur_byte++ = pstrStationParam->ht_supported;
-   memcpy(cur_byte, >ht_capa,
-  sizeof(struct ieee80211_ht_cap));
+   *cur_byte++ = param->ht_supported;
+   memcpy(cur_byte, >ht_capa, sizeof(struct ieee80211_ht_cap));
cur_byte += sizeof(struct ieee80211_ht_cap);
 
-   *cur_byte++ = pstrStationParam->flags_mask & 0xFF;
-   *cur_byte++ = (pstrStationParam->flags_mask >> 8) & 0xFF;
+   *cur_byte++ = param->flags_mask & 0xFF;
+   *cur_byte++ = (param->flags_mask >> 8) & 0xFF;
 
-   *cur_byte++ = pstrStationParam->flags_set & 0xFF;
-   *cur_byte++ = (pstrStationParam->flags_set >> 8) & 0xFF;
+   *cur_byte++ = param->flags_set & 0xFF;
+   *cur_byte++ = (param->flags_set >> 8) & 0xFF;
 
return cur_byte - pu8Buffer;
 }
 
 static void handle_add_station(struct wilc_vif *vif,
-  struct add_sta_param *pstrStationParam)
+  struct add_sta_param *param)
 {
s32 result = 0;
struct wid wid;
@@ -2102,14 +2100,14 @@ static void handle_add_station(struct wilc_vif *vif,
 
wid.id = (u16)WID_ADD_STA;
wid.type = WID_BIN;
-   wid.size = WILC_ADD_STA_LENGTH + pstrStationParam->rates_len;
+   wid.size = WILC_ADD_STA_LENGTH + param->rates_len;
 
wid.val = kmalloc(wid.size, GFP_KERNEL);
if (!wid.val)
goto ERRORHANDLER;
 
cur_byte = wid.val;
-   cur_byte += WILC_HostIf_PackStaParam(cur_byte, pstrStationParam);
+   cur_byte += WILC_HostIf_PackStaParam(cur_byte, param);
 
result = wilc_send_config_pkt(vif, SET_CFG, , 1,
  wilc_get_vif_idx(vif));
@@ -2117,7 +2115,7 @@ static void handle_add_station(struct wilc_vif *vif,
netdev_err(vif->ndev, "Failed to send add station\n");
 
 ERRORHANDLER:
-   kfree(pstrStationParam->rates);
+   kfree(param->rates);
kfree(wid.val);
 }
 
@@ -2190,7 +2188,7 @@ static void handle_del_station(struct wilc_vif *vif, 
struct del_sta *param)
 }
 
 static void handle_edit_station(struct wilc_vif *vif,
-   struct add_sta_param *pstrStationParam)
+   struct add_sta_param *param)
 {
s32 result = 0;
struct wid wid;
@@ -2198,14 +2196,14 @@ static void handle_edit_station(struct wilc_vif *vif,
 
wid.id = (u16)WID_EDIT_STA;
wid.type = WID_BIN;
-   wid.size = WILC_ADD_STA_LENGTH + pstrStationParam->rates_len;
+   wid.size = WILC_ADD_STA_LENGTH + param->rates_len;
 
wid.val = kmalloc(wid.size, GFP_KERNEL);
if (!wid.val)
goto ERRORHANDLER;
 
cur_byte = wid.val;
-   cur_byte += WILC_HostIf_PackStaParam(cur_byte, pstrStationParam);
+   cur_byte += WILC_HostIf_PackStaParam(cur_byte, param);
 
result = wilc_send_config_pkt(vif, SET_CFG, , 1,
  wilc_get_vif_idx(vif));
@@ -2213,7 +2211,7 @@ static void handle_edit_station(struct wilc_vif *vif,
netdev_err(vif->ndev, "Failed to send edit station\n");
 
 ERRORHANDLER:
-   kfree(pstrStationParam->rates);
+   kfree(param->rates);
kfree(wid.val);
 }
 
-- 
2.7.4

[PATCH 12/12] staging: wilc1000: rename _WPARxGtk_end_case_ label to avoid camelCase

[Ajay Singh]

Fix "Avoid camelCase" issue found by checkpatch.pl script.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 0cfb79d..253225c 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1620,7 +1620,7 @@ static int handle_key(struct wilc_vif *vif,
pu8keybuf = kzalloc(RX_MIC_KEY_MSG_LEN, GFP_KERNEL);
if (!pu8keybuf) {
ret = -ENOMEM;
-   goto _WPARxGtk_end_case_;
+   goto out_wpa_rx_gtk;
}
 
if (pstrHostIFkeyAttr->attr.wpa.seq)
@@ -1651,7 +1651,7 @@ static int handle_key(struct wilc_vif *vif,
pu8keybuf = kzalloc(RX_MIC_KEY_MSG_LEN, GFP_KERNEL);
if (!pu8keybuf) {
ret = -ENOMEM;
-   goto _WPARxGtk_end_case_;
+   goto out_wpa_rx_gtk;
}
 
if (hif_drv->hif_state == HOST_IF_CONNECTED)
@@ -1677,7 +1677,7 @@ static int handle_key(struct wilc_vif *vif,
kfree(pu8keybuf);
complete(_drv->comp_test_key_block);
}
-_WPARxGtk_end_case_:
+out_wpa_rx_gtk:
kfree(pstrHostIFkeyAttr->attr.wpa.key);
kfree(pstrHostIFkeyAttr->attr.wpa.seq);
if (ret)
-- 
2.7.4

[PATCH 11/12] staging: wilc1000: rename _WPAPtk_end_case_ label to avoid camelCase

[Ajay Singh]

Fix "Avoid camelCase" issue found by checkpatch.pl script.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 8528ff8..0cfb79d 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1690,7 +1690,7 @@ static int handle_key(struct wilc_vif *vif,
pu8keybuf = kmalloc(PTK_KEY_MSG_LEN + 1, GFP_KERNEL);
if (!pu8keybuf) {
ret = -ENOMEM;
-   goto _WPAPtk_end_case_;
+   goto out_wpa_ptk;
}
 
memcpy(pu8keybuf, pstrHostIFkeyAttr->attr.wpa.mac_addr, 
6);
@@ -1719,7 +1719,7 @@ static int handle_key(struct wilc_vif *vif,
if (!pu8keybuf) {
netdev_err(vif->ndev, "No buffer send PTK\n");
ret = -ENOMEM;
-   goto _WPAPtk_end_case_;
+   goto out_wpa_ptk;
}
 
memcpy(pu8keybuf, pstrHostIFkeyAttr->attr.wpa.mac_addr, 
6);
@@ -1739,7 +1739,7 @@ static int handle_key(struct wilc_vif *vif,
complete(_drv->comp_test_key_block);
}
 
-_WPAPtk_end_case_:
+out_wpa_ptk:
kfree(pstrHostIFkeyAttr->attr.wpa.key);
if (ret)
return ret;
-- 
2.7.4

[PATCH 09/12] staging: wilc1000: rename pstrDelStaParam to avoid camelCase

[Ajay Singh]

Fix "Avoid camelCase" issue found by checkpatch.pl script.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 64a2060..8ec33b3 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -2162,8 +2162,7 @@ static void handle_del_all_sta(struct wilc_vif *vif,
complete(_wait_response);
 }
 
-static void handle_del_station(struct wilc_vif *vif,
-  struct del_sta *pstrDelStaParam)
+static void handle_del_station(struct wilc_vif *vif, struct del_sta *param)
 {
s32 result = 0;
struct wid wid;
@@ -2179,7 +2178,7 @@ static void handle_del_station(struct wilc_vif *vif,
 
cur_byte = wid.val;
 
-   ether_addr_copy(cur_byte, pstrDelStaParam->mac_addr);
+   ether_addr_copy(cur_byte, param->mac_addr);
 
result = wilc_send_config_pkt(vif, SET_CFG, , 1,
  wilc_get_vif_idx(vif));
-- 
2.7.4

[PATCH 07/12] staging: wilc1000: rename pstrStatistics to avoid camelCase

[Ajay Singh]

Fix "Avoid caseCase" issue found by checkpatch.pl script.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 9eb808e..593f7f1 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1889,7 +1889,7 @@ static void handle_get_rssi(struct wilc_vif *vif)
 }
 
 static s32 handle_get_statistics(struct wilc_vif *vif,
-struct rf_info *pstrStatistics)
+struct rf_info *stats)
 {
struct wid wid_list[5];
u32 wid_cnt = 0, result = 0;
@@ -1897,31 +1897,31 @@ static s32 handle_get_statistics(struct wilc_vif *vif,
wid_list[wid_cnt].id = WID_LINKSPEED;
wid_list[wid_cnt].type = WID_CHAR;
wid_list[wid_cnt].size = sizeof(char);
-   wid_list[wid_cnt].val = (s8 *)>link_speed;
+   wid_list[wid_cnt].val = (s8 *)>link_speed;
wid_cnt++;
 
wid_list[wid_cnt].id = WID_RSSI;
wid_list[wid_cnt].type = WID_CHAR;
wid_list[wid_cnt].size = sizeof(char);
-   wid_list[wid_cnt].val = (s8 *)>rssi;
+   wid_list[wid_cnt].val = (s8 *)>rssi;
wid_cnt++;
 
wid_list[wid_cnt].id = WID_SUCCESS_FRAME_COUNT;
wid_list[wid_cnt].type = WID_INT;
wid_list[wid_cnt].size = sizeof(u32);
-   wid_list[wid_cnt].val = (s8 *)>tx_cnt;
+   wid_list[wid_cnt].val = (s8 *)>tx_cnt;
wid_cnt++;
 
wid_list[wid_cnt].id = WID_RECEIVED_FRAGMENT_COUNT;
wid_list[wid_cnt].type = WID_INT;
wid_list[wid_cnt].size = sizeof(u32);
-   wid_list[wid_cnt].val = (s8 *)>rx_cnt;
+   wid_list[wid_cnt].val = (s8 *)>rx_cnt;
wid_cnt++;
 
wid_list[wid_cnt].id = WID_FAILED_COUNT;
wid_list[wid_cnt].type = WID_INT;
wid_list[wid_cnt].size = sizeof(u32);
-   wid_list[wid_cnt].val = (s8 *)>tx_fail_cnt;
+   wid_list[wid_cnt].val = (s8 *)>tx_fail_cnt;
wid_cnt++;
 
result = wilc_send_config_pkt(vif, GET_CFG, wid_list,
@@ -1931,13 +1931,13 @@ static s32 handle_get_statistics(struct wilc_vif *vif,
if (result)
netdev_err(vif->ndev, "Failed to send scan parameters\n");
 
-   if (pstrStatistics->link_speed > TCP_ACK_FILTER_LINK_SPEED_THRESH &&
-   pstrStatistics->link_speed != DEFAULT_LINK_SPEED)
+   if (stats->link_speed > TCP_ACK_FILTER_LINK_SPEED_THRESH &&
+   stats->link_speed != DEFAULT_LINK_SPEED)
wilc_enable_tcp_ack_filter(true);
-   else if (pstrStatistics->link_speed != DEFAULT_LINK_SPEED)
+   else if (stats->link_speed != DEFAULT_LINK_SPEED)
wilc_enable_tcp_ack_filter(false);
 
-   if (pstrStatistics != >wilc->dummy_statistics)
+   if (stats != >wilc->dummy_statistics)
complete(_wait_response);
return 0;
 }
-- 
2.7.4

[PATCH 08/12] staging: wilc1000: rename strDisconnectNotifInfo to avoid camelCase

[Ajay Singh]

Fix "Avoid camelCase" issue found by checkpatch.pl script.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 593f7f1..64a2060 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1330,7 +1330,7 @@ static s32 handle_rcvd_gnrl_async_info(struct wilc_vif 
*vif,
u8 u8MacStatusReasonCode;
u8 u8MacStatusAdditionalInfo;
struct connect_info strConnectInfo;
-   struct disconnect_info strDisconnectNotifInfo;
+   struct disconnect_info disconn_info;
s32 s32Err = 0;
struct host_if_drv *hif_drv = vif->hif_drv;
 
@@ -1462,16 +1462,16 @@ static s32 handle_rcvd_gnrl_async_info(struct wilc_vif 
*vif,
hif_drv->usr_conn_req.ies = NULL;
} else if ((u8MacStatus == MAC_DISCONNECTED) &&
   (hif_drv->hif_state == HOST_IF_CONNECTED)) {
-   memset(, 0, sizeof(struct 
disconnect_info));
+   memset(_info, 0, sizeof(struct 
disconnect_info));
 
if (hif_drv->usr_scan_req.scan_result) {
del_timer(_drv->scan_timer);
handle_scan_done(vif, SCAN_EVENT_ABORTED);
}
 
-   strDisconnectNotifInfo.reason = 0;
-   strDisconnectNotifInfo.ie = NULL;
-   strDisconnectNotifInfo.ie_len = 0;
+   disconn_info.reason = 0;
+   disconn_info.ie = NULL;
+   disconn_info.ie_len = 0;
 
if (hif_drv->usr_conn_req.conn_result) {
wilc_optaining_ip = false;
@@ -1480,7 +1480,7 @@ static s32 handle_rcvd_gnrl_async_info(struct wilc_vif 
*vif,

hif_drv->usr_conn_req.conn_result(CONN_DISCONN_EVENT_DISCONN_NOTIF,
  NULL,
  0,
- 
,
+ _info,
  
hif_drv->usr_conn_req.arg);
} else {
netdev_err(vif->ndev, "Connect result NULL\n");
@@ -1800,13 +1800,13 @@ static void handle_disconnect(struct wilc_vif *vif)
if (result) {
netdev_err(vif->ndev, "Failed to send dissconect\n");
} else {
-   struct disconnect_info strDisconnectNotifInfo;
+   struct disconnect_info disconn_info;
 
-   memset(, 0, sizeof(struct 
disconnect_info));
+   memset(_info, 0, sizeof(struct disconnect_info));
 
-   strDisconnectNotifInfo.reason = 0;
-   strDisconnectNotifInfo.ie = NULL;
-   strDisconnectNotifInfo.ie_len = 0;
+   disconn_info.reason = 0;
+   disconn_info.ie = NULL;
+   disconn_info.ie_len = 0;
 
if (hif_drv->usr_scan_req.scan_result) {
del_timer(_drv->scan_timer);
@@ -1824,7 +1824,7 @@ static void handle_disconnect(struct wilc_vif *vif)

hif_drv->usr_conn_req.conn_result(CONN_DISCONN_EVENT_DISCONN_NOTIF,
  NULL,
  0,
- 
,
+ _info,
  
hif_drv->usr_conn_req.arg);
} else {
netdev_err(vif->ndev, "conn_result = NULL\n");
-- 
2.7.4

[PATCH 05/12] staging: wilc1000: rename Handle_SetMulticastFilter to avoid camelCase

[Ajay Singh]

Fix "Avoid camelCase" issue found by checkpatch.pl script.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index fd21765..57f0201 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -2404,8 +2404,8 @@ static void handle_power_management(struct wilc_vif *vif,
netdev_err(vif->ndev, "Failed to send power management\n");
 }
 
-static void Handle_SetMulticastFilter(struct wilc_vif *vif,
- struct set_multicast *hif_set_mc)
+static void handle_set_mcast_filter(struct wilc_vif *vif,
+   struct set_multicast *hif_set_mc)
 {
s32 result = 0;
struct wid wid;
@@ -2621,7 +2621,7 @@ static void host_if_work(struct work_struct *work)
break;
 
case HOST_IF_MSG_SET_MULTICAST_FILTER:
-   Handle_SetMulticastFilter(msg->vif, >body.multicast_info);
+   handle_set_mcast_filter(msg->vif, >body.multicast_info);
break;
 
case HOST_IF_MSG_DEL_ALL_STA:
-- 
2.7.4

[PATCH 03/12] staging: wilc1000: rename variables using camelCase in handle_rcvd_ntwrk_info()

[Ajay Singh]

Fix "Avoid camelCase" issue found by checkpatch.pl script.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 45 +++
 1 file changed, 22 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 0f1eb17..f79618a 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1248,18 +1248,17 @@ static s32 handle_rcvd_ntwrk_info(struct wilc_vif *vif,
  struct rcvd_net_info *rcvd_info)
 {
u32 i;
-   bool bNewNtwrkFound;
+   bool found;
s32 result = 0;
-   struct network_info *pstrNetworkInfo = NULL;
-   void *pJoinParams = NULL;
+   struct network_info *info = NULL;
+   void *params = NULL;
struct host_if_drv *hif_drv = vif->hif_drv;
 
-   bNewNtwrkFound = true;
+   found = true;
 
if (hif_drv->usr_scan_req.scan_result) {
-   wilc_parse_network_info(rcvd_info->buffer, );
-   if (!pstrNetworkInfo ||
-   !hif_drv->usr_scan_req.scan_result) {
+   wilc_parse_network_info(rcvd_info->buffer, );
+   if (!info || !hif_drv->usr_scan_req.scan_result) {
netdev_err(vif->ndev, "driver is null\n");
result = -EINVAL;
goto done;
@@ -1267,36 +1266,36 @@ static s32 handle_rcvd_ntwrk_info(struct wilc_vif *vif,
 
for (i = 0; i < hif_drv->usr_scan_req.rcvd_ch_cnt; i++) {
if (memcmp(hif_drv->usr_scan_req.net_info[i].bssid,
-  pstrNetworkInfo->bssid, 6) == 0) {
-   if (pstrNetworkInfo->rssi <= 
hif_drv->usr_scan_req.net_info[i].rssi) {
+  info->bssid, 6) == 0) {
+   if (info->rssi <= 
hif_drv->usr_scan_req.net_info[i].rssi) {
goto done;
} else {
-   hif_drv->usr_scan_req.net_info[i].rssi 
= pstrNetworkInfo->rssi;
-   bNewNtwrkFound = false;
+   hif_drv->usr_scan_req.net_info[i].rssi 
= info->rssi;
+   found = false;
break;
}
}
}
 
-   if (bNewNtwrkFound) {
+   if (found) {
if (hif_drv->usr_scan_req.rcvd_ch_cnt < 
MAX_NUM_SCANNED_NETWORKS) {
-   
hif_drv->usr_scan_req.net_info[hif_drv->usr_scan_req.rcvd_ch_cnt].rssi = 
pstrNetworkInfo->rssi;
+   
hif_drv->usr_scan_req.net_info[hif_drv->usr_scan_req.rcvd_ch_cnt].rssi = 
info->rssi;
 

memcpy(hif_drv->usr_scan_req.net_info[hif_drv->usr_scan_req.rcvd_ch_cnt].bssid,
-  pstrNetworkInfo->bssid, 6);
+  info->bssid, 6);
 
hif_drv->usr_scan_req.rcvd_ch_cnt++;
 
-   pstrNetworkInfo->new_network = true;
-   pJoinParams = 
host_int_parse_join_bss_param(pstrNetworkInfo);
+   info->new_network = true;
+   params = host_int_parse_join_bss_param(info);
 
-   
hif_drv->usr_scan_req.scan_result(SCAN_EVENT_NETWORK_FOUND, pstrNetworkInfo,
+   
hif_drv->usr_scan_req.scan_result(SCAN_EVENT_NETWORK_FOUND, info,
  
hif_drv->usr_scan_req.arg,
- pJoinParams);
+ params);
}
} else {
-   pstrNetworkInfo->new_network = false;
-   
hif_drv->usr_scan_req.scan_result(SCAN_EVENT_NETWORK_FOUND, pstrNetworkInfo,
+   info->new_network = false;
+   
hif_drv->usr_scan_req.scan_result(SCAN_EVENT_NETWORK_FOUND, info,
  
hif_drv->usr_scan_req.arg, NULL);
}
}
@@ -1305,9 +1304,9 @@ static s32 handle_rcvd_ntwrk_info(struct wilc_vif *vif,
kfree(rcvd_info->buffer);
rcvd_info->buffer = NULL;
 
-   if (pstrNetworkInfo) {
-   kfree(pstrNetworkInfo->ies);
-   kfree(pstrNetworkInfo);
+   if (info) {
+   kfree(info->ies);
+   kfree(info);
}
 
return result;
-- 
2.7.4

Re: [PATCH 2/2] ath9k: Fix ack SIFS time for quarter/half channels

[Kalle Valo]

+ linux-wireless

Wojciech Dubowik  writes:

> Yes in MHz.

Please always reply in public (Cc linux-wireless) so that it goes to the
mailing list and patchwork.

> Sorry, got distracted.

No problem.

-- 
Kalle Valo

Re: [PATCH 2/2] ath9k: Fix ack SIFS time for quarter/half channels

[Kalle Valo]

Wojciech Dubowik  writes:

> Ack timing generation has to be adapted for 5/10 MHz channels.
> Do it by properly initializing ack shift field in TXSIFS
> register. Ack shift assumes channel width of 2.5 Hhz so

Is this supposed to be MHz? I can fix that during commit, no need to
resend just because of this.

-- 
Kalle Valo

[PATCH 2/2] ath9k: Fix ack SIFS time for quarter/half channels

[Wojciech Dubowik]

Ack timing generation has to be adapted for 5/10 MHz channels.
Do it by properly initializing ack shift field in TXSIFS
register. Ack shift assumes channel width of 2.5 Hhz so
value zero means 2.5 MHz, 1 is 5 MHz and so on.

Signed-off-by: Wojciech Dubowik 
---
 drivers/net/wireless/ath/ath9k/hw.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/hw.c 
b/drivers/net/wireless/ath/ath9k/hw.c
index 3017078..6b37036 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1038,7 +1038,7 @@ void ath9k_hw_init_global_settings(struct ath_hw *ah)
int acktimeout, ctstimeout, ack_offset = 0;
int slottime;
int sifstime;
-   int rx_lat = 0, tx_lat = 0, eifs = 0;
+   int rx_lat = 0, tx_lat = 0, eifs = 0, ack_shift = 0;
u32 reg;
 
ath_dbg(ath9k_hw_common(ah), RESET, "ah->misc_mode 0x%x\n",
@@ -1070,6 +1070,7 @@ void ath9k_hw_init_global_settings(struct ath_hw *ah)
 
sifstime = 32;
ack_offset = 16;
+   ack_shift = 3;
slottime = 13;
} else if (IS_CHAN_QUARTER_RATE(chan)) {
eifs = 340;
@@ -1080,6 +1081,7 @@ void ath9k_hw_init_global_settings(struct ath_hw *ah)
 
sifstime = 64;
ack_offset = 32;
+   ack_shift = 1;
slottime = 21;
} else {
if (AR_SREV_9287(ah) && AR_SREV_9287_13_OR_LATER(ah)) {
@@ -1136,6 +1138,10 @@ void ath9k_hw_init_global_settings(struct ath_hw *ah)
SM(tx_lat, AR_USEC_TX_LAT),
AR_USEC_TX_LAT | AR_USEC_RX_LAT | AR_USEC_USEC);
 
+   if (IS_CHAN_HALF_RATE(chan) || IS_CHAN_QUARTER_RATE(chan))
+   REG_RMW(ah, AR_TXSIFS,
+   sifstime | SM(ack_shift, AR_TXSIFS_ACK_SHIFT),
+   (AR_TXSIFS_TIME | AR_TXSIFS_ACK_SHIFT));
 }
 EXPORT_SYMBOL(ath9k_hw_init_global_settings);
 
-- 
2.7.4

[PATCH 1/2] ath9k: Fix airtime calculation for quarter/half channels

[Wojciech Dubowik]

The bitrate value for airtime calculation is specified for
full rates. We need to divide it for 5 and 10MHz channels to
get correct result.

Signed-off-by: Wojciech Dubowik 
---
 drivers/net/wireless/ath/ath9k/hw.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/hw.c 
b/drivers/net/wireless/ath/ath9k/hw.c
index cd0f023..3017078 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -184,7 +184,8 @@ u16 ath9k_hw_computetxtime(struct ath_hw *ah,
break;
case WLAN_RC_PHY_OFDM:
if (ah->curchan && IS_CHAN_QUARTER_RATE(ah->curchan)) {
-   bitsPerSymbol = (kbps * OFDM_SYMBOL_TIME_QUARTER) / 
1000;
+   bitsPerSymbol =
+   ((kbps >> 2) * OFDM_SYMBOL_TIME_QUARTER) / 1000;
numBits = OFDM_PLCP_BITS + (frameLen << 3);
numSymbols = DIV_ROUND_UP(numBits, bitsPerSymbol);
txTime = OFDM_SIFS_TIME_QUARTER
@@ -192,7 +193,8 @@ u16 ath9k_hw_computetxtime(struct ath_hw *ah,
+ (numSymbols * OFDM_SYMBOL_TIME_QUARTER);
} else if (ah->curchan &&
   IS_CHAN_HALF_RATE(ah->curchan)) {
-   bitsPerSymbol = (kbps * OFDM_SYMBOL_TIME_HALF) / 1000;
+   bitsPerSymbol =
+   ((kbps >> 1) * OFDM_SYMBOL_TIME_HALF) / 1000;
numBits = OFDM_PLCP_BITS + (frameLen << 3);
numSymbols = DIV_ROUND_UP(numBits, bitsPerSymbol);
txTime = OFDM_SIFS_TIME_HALF +
-- 
2.7.4

Re: [PATCH v7] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

+struct ath10k_gpiocontrol {
+    struct ath10k *ar;
+    u32 gpio_set_num, gpio_num, gpio_input, gpio_pull_type, 
gpio_intr_mode, gpio_set; /* since we have no gpio read method, these 
are the state variables for debugfs.  */


I think the checkpatch.pl will complain above defintely.
Best regards,

because of the one liner?


Sebastian


--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [RFC PATCH 2/2] net: rfkill: gpio: Convert driver to SerDev

[Carlo Caione]

On Tue, Feb 20, 2018 at 2:04 PM, Marcel Holtmann  wrote:
> Hi Carlo,

Hi Marcel,

>> With commit e361d1f85855 ("ACPI / scan: Fix enumeration for special UART
>> devices") UART devices are now expected to be enumerated by
>> SerDev subsystem. This is breaking the enumeration of platform devices
>> connected to the UART without a proper SerDev support, like in the
>> rfkill-gpio case.
>>
>> Fix this moving the driver from a platform driver to a serdev device
>> driver.
>
> I do not like keeping this a RFKILL switch for the two GPS devices and that 
> is really all what is left for this driver.
>
> static const struct acpi_device_id rfkill_acpi_match[] = {
> { "BCM4752", RFKILL_TYPE_GPS },
> { "LNV4752", RFKILL_TYPE_GPS },
> { },
> };
>
> Frankly what this needs is a serdev GPS driver. Even if it also exposes the 
> data path via character device or a new TTY. Trying to hook this into RFKILL 
> for powering on the GPS chip is not what we should do anymore. What you 
> really want is that if the GPS daemon or application open the node for the 
> GPS device that it gets powered on and when closed powered back down. 
> Fiddling with RFKILL to do that is not what a RFKILL switch is for. If you 
> want to have an additional RFKILL switch for killing power, then this has to 
> be done the same as WiFi and Bluetooth do it.
>
> So this patch is just a bad hack and we better have a proper serdev GPS 
> driver.

Yeah, I know (that's also why I preferred to send this as RFC).
At least this patch could be useful to have things working until we
have something better in place, but I definitely agree that's a bad
hack.

Cheers,

-- 
Carlo Caione  |  +44.7384.69.16.04  |  Endless

Re: [RFC PATCH 0/2] net: rfkill: gpio: Fix and support SerDev

[Carlo Caione]

On Tue, Feb 20, 2018 at 2:01 PM, Hans de Goede  wrote:
> Hi Carlo,

Hi Hans,

> Is this for devices with a RTL8723BS chip? If so then they
> still will not work after this since there also no longer is
> a /dev/ttyS4 created for the UART for the bluetooth, instead
> you probably want:
>
> https://github.com/jwrdegoede/linux-sunxi/commit/c383dac5ea00738ac01d704d820aa548494fcd41
>
> Which also puts the /dev/ttyS4 back in place.

Yeah, this problem came up while working on the RTL8723BS chip but the
driver is also broken for the other two GPS devices supported by this
driver.
Thank you for the patch BTW.

> Regards,
>
> Hans
>
> p.s.
>
> My college Jeremy Cline in the Cc is looking into getting proper
> bluetooth support in place for the rtl8723bs using serdev binding
> and having everything in the kernel, as we now already do for bcm
> uart bluetooth modules.

Wasn't also Martin (+CC) working on this? See
https://www.spinics.net/lists/linux-bluetooth/msg73594.html

Cheers,

-- 
Carlo Caione  |  +44.7384.69.16.04  |  Endless

Re: [RFC PATCH 0/2] net: rfkill: gpio: Fix and support SerDev

[Marcel Holtmann]

Hi Hans,

> Is this for devices with a RTL8723BS chip? If so then they
> still will not work after this since there also no longer is
> a /dev/ttyS4 created for the UART for the bluetooth, instead
> you probably want:
> 

it is not for that hardware, it is for some GPS devices.

static const struct acpi_device_id rfkill_acpi_match[] = {
{ "BCM4752", RFKILL_TYPE_GPS },
{ "LNV4752", RFKILL_TYPE_GPS },
{ },
};

> https://github.com/jwrdegoede/linux-sunxi/commit/c383dac5ea00738ac01d704d820aa548494fcd41
> 
> Which also puts the /dev/ttyS4 back in place.
> 
> Regards,
> 
> Hans
> 
> p.s.
> 
> My college Jeremy Cline in the Cc is looking into getting proper
> bluetooth support in place for the rtl8723bs using serdev binding
> and having everything in the kernel, as we now already do for bcm
> uart bluetooth modules.

Actually this should be done quickly since the Realtek hciattach / btattach 
hacks are not even upstream either since that is unmergable code. Even a basic 
hci_rtl.c driver would be better than nothing.

Regards

Marcel

Re: [RFC PATCH 2/2] net: rfkill: gpio: Convert driver to SerDev

[Marcel Holtmann]

Hi Carlo,

> With commit e361d1f85855 ("ACPI / scan: Fix enumeration for special UART
> devices") UART devices are now expected to be enumerated by
> SerDev subsystem. This is breaking the enumeration of platform devices
> connected to the UART without a proper SerDev support, like in the
> rfkill-gpio case.
> 
> Fix this moving the driver from a platform driver to a serdev device
> driver.

I do not like keeping this a RFKILL switch for the two GPS devices and that is 
really all what is left for this driver.

static const struct acpi_device_id rfkill_acpi_match[] = {
{ "BCM4752", RFKILL_TYPE_GPS },
{ "LNV4752", RFKILL_TYPE_GPS },
{ },
};

Frankly what this needs is a serdev GPS driver. Even if it also exposes the 
data path via character device or a new TTY. Trying to hook this into RFKILL 
for powering on the GPS chip is not what we should do anymore. What you really 
want is that if the GPS daemon or application open the node for the GPS device 
that it gets powered on and when closed powered back down. Fiddling with RFKILL 
to do that is not what a RFKILL switch is for. If you want to have an 
additional RFKILL switch for killing power, then this has to be done the same 
as WiFi and Bluetooth do it.

So this patch is just a bad hack and we better have a proper serdev GPS driver.

Regards

Marcel

Re: [RFC PATCH 0/2] net: rfkill: gpio: Fix and support SerDev

[Hans de Goede]

Hi Carlo,

Is this for devices with a RTL8723BS chip? If so then they
still will not work after this since there also no longer is
a /dev/ttyS4 created for the UART for the bluetooth, instead
you probably want:

https://github.com/jwrdegoede/linux-sunxi/commit/c383dac5ea00738ac01d704d820aa548494fcd41

Which also puts the /dev/ttyS4 back in place.

Regards,

Hans

p.s.

My college Jeremy Cline in the Cc is looking into getting proper
bluetooth support in place for the rtl8723bs using serdev binding
and having everything in the kernel, as we now already do for bcm
uart bluetooth modules.

On 20-02-18 14:46, Carlo Caione wrote:

From: Carlo Caione 

Hi,
this patch came after investigating why the rfkill-gpio driver was failing on
the latest kernel on a machine I have. Sending this out as RFC because I'm
still not sure if this is the right way to approach this problem. I was
honestly expecting not to see the platform devices failing as consequences of
the latest work on SerDev.

Carlo Caione (2):
   net: rfkill: gpio: Fix NULL pointer deference
   net: rfkill: gpio: Convert driver to SerDev

  net/rfkill/Kconfig   |  1 +
  net/rfkill/rfkill-gpio.c | 48 +---
  2 files changed, 26 insertions(+), 23 deletions(-)

[RFC PATCH 2/2] net: rfkill: gpio: Convert driver to SerDev

[Carlo Caione]

From: Carlo Caione 

With commit e361d1f85855 ("ACPI / scan: Fix enumeration for special UART
devices") UART devices are now expected to be enumerated by
SerDev subsystem. This is breaking the enumeration of platform devices
connected to the UART without a proper SerDev support, like in the
rfkill-gpio case.

Fix this moving the driver from a platform driver to a serdev device
driver.

Signed-off-by: Carlo Caione 
---
 net/rfkill/Kconfig   |  1 +
 net/rfkill/rfkill-gpio.c | 46 --
 2 files changed, 25 insertions(+), 22 deletions(-)

diff --git a/net/rfkill/Kconfig b/net/rfkill/Kconfig
index 060600b03fad..14ee289328d7 100644
--- a/net/rfkill/Kconfig
+++ b/net/rfkill/Kconfig
@@ -27,6 +27,7 @@ config RFKILL_GPIO
tristate "GPIO RFKILL driver"
depends on RFKILL
depends on GPIOLIB || COMPILE_TEST
+   depends on SERIAL_DEV_CTRL_TTYPORT
default n
help
  If you say yes here you get support of a generic gpio RFKILL
diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c
index 659d2edae972..d7553f3c3ae7 100644
--- a/net/rfkill/rfkill-gpio.c
+++ b/net/rfkill/rfkill-gpio.c
@@ -23,11 +23,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
 struct rfkill_gpio_data {
+   struct device   *dev;
const char  *name;
enum rfkill_typetype;
struct gpio_desc*reset_gpio;
@@ -84,40 +86,42 @@ static int rfkill_gpio_acpi_probe(struct device *dev,
return devm_acpi_dev_add_driver_gpios(dev, acpi_rfkill_default_gpios);
 }
 
-static int rfkill_gpio_probe(struct platform_device *pdev)
+static int rfkill_gpio_serdev_probe(struct serdev_device *serdev)
 {
struct rfkill_gpio_data *rfkill;
struct gpio_desc *gpio;
const char *type_name = NULL;
int ret;
 
-   rfkill = devm_kzalloc(>dev, sizeof(*rfkill), GFP_KERNEL);
+   rfkill = devm_kzalloc(>dev, sizeof(*rfkill), GFP_KERNEL);
if (!rfkill)
return -ENOMEM;
 
-   device_property_read_string(>dev, "name", >name);
-   device_property_read_string(>dev, "type", _name);
+   rfkill->dev = >dev;
+
+   device_property_read_string(rfkill->dev, "name", >name);
+   device_property_read_string(rfkill->dev, "type", _name);
 
if (!rfkill->name)
-   rfkill->name = dev_name(>dev);
+   rfkill->name = dev_name(rfkill->dev);
 
rfkill->type = rfkill_find_type(type_name);
 
-   if (ACPI_HANDLE(>dev)) {
-   ret = rfkill_gpio_acpi_probe(>dev, rfkill);
+   if (ACPI_HANDLE(rfkill->dev)) {
+   ret = rfkill_gpio_acpi_probe(rfkill->dev, rfkill);
if (ret)
return ret;
}
 
-   rfkill->clk = devm_clk_get(>dev, NULL);
+   rfkill->clk = devm_clk_get(rfkill->dev, NULL);
 
-   gpio = devm_gpiod_get_optional(>dev, "reset", GPIOD_OUT_LOW);
+   gpio = devm_gpiod_get_optional(rfkill->dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(gpio))
return PTR_ERR(gpio);
 
rfkill->reset_gpio = gpio;
 
-   gpio = devm_gpiod_get_optional(>dev, "shutdown", GPIOD_OUT_LOW);
+   gpio = devm_gpiod_get_optional(rfkill->dev, "shutdown", GPIOD_OUT_LOW);
if (IS_ERR(gpio))
return PTR_ERR(gpio);
 
@@ -125,11 +129,11 @@ static int rfkill_gpio_probe(struct platform_device *pdev)
 
/* Make sure at-least one GPIO is defined for this instance */
if (!rfkill->reset_gpio && !rfkill->shutdown_gpio) {
-   dev_err(>dev, "invalid platform data\n");
+   dev_err(rfkill->dev, "invalid platform data\n");
return -EINVAL;
}
 
-   rfkill->rfkill_dev = rfkill_alloc(rfkill->name, >dev,
+   rfkill->rfkill_dev = rfkill_alloc(rfkill->name, rfkill->dev,
  rfkill->type, _gpio_ops,
  rfkill);
if (!rfkill->rfkill_dev)
@@ -139,21 +143,19 @@ static int rfkill_gpio_probe(struct platform_device *pdev)
if (ret < 0)
return ret;
 
-   platform_set_drvdata(pdev, rfkill);
+   serdev_device_set_drvdata(serdev, rfkill);
 
-   dev_info(>dev, "%s device registered.\n", rfkill->name);
+   dev_info(rfkill->dev, "%s device registered.\n", rfkill->name);
 
return 0;
 }
 
-static int rfkill_gpio_remove(struct platform_device *pdev)
+static void rfkill_gpio_serdev_remove(struct serdev_device *serdev)
 {
-   struct rfkill_gpio_data *rfkill = platform_get_drvdata(pdev);
+   struct rfkill_gpio_data *rfkill = serdev_device_get_drvdata(serdev);
 
rfkill_unregister(rfkill->rfkill_dev);
rfkill_destroy(rfkill->rfkill_dev);
-
-   return 0;
 }
 
 #ifdef CONFIG_ACPI
@@ -165,16 +167,16 @@ static const struct acpi_device_id rfkill_acpi_match[] = {
 

Re: [v7 3/8] rsi: add header file rsi_91x

[Kalle Valo]

Hi Dave and Johannes,

a question to both of you below:

Amitkumar Karwar  writes:

> From: Prameela Rani Garnepudi 
>
> The common parameters used by wlan and bt modules are add
> to a new header file "rsi_91x.h" defined in 'include/net'
>
> Signed-off-by: Prameela Rani Garnepudi 
> Signed-off-by: Siva Rebbagondla 
> Signed-off-by: Amitkumar Karwar 
> ---
> v7: Same as v6
> v6: Renamed rsi_header.h to rsi_91x.h and moved to include/net
> from include/linux(Kalle)
> v5: Same as earlier versions

[...]

> --- /dev/null
> +++ b/include/net/rsi_91x.h
> @@ -0,0 +1,34 @@
> +/**
> + * Copyright (c) 2017 Redpine Signals Inc.
> + *
> + * Permission to use, copy, modify, and/or distribute this software for any
> + * purpose with or without fee is hereby granted, provided that the above
> + * copyright notice and this permission notice appear in all copies.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> + */
> +
> +#ifndef __RSI_HEADER_H__
> +#define __RSI_HEADER_H__
> +
> +/* HAL queue information */
> +#define RSI_COEX_Q   0x0
> +#define RSI_BT_Q 0x2
> +#define RSI_WLAN_Q  0x3
> +#define RSI_WIFI_MGMT_Q 0x4
> +#define RSI_WIFI_DATA_Q 0x5
> +#define RSI_BT_MGMT_Q0x6
> +#define RSI_BT_DATA_Q0x7
> +
> +enum rsi_host_intf {
> + RSI_HOST_INTF_SDIO = 0,
> + RSI_HOST_INTF_USB
> +};
> +
> +#endif

Are you guys ok to have this header file shared by rsi wireless and
bluetooth driver in include/net?

-- 
Kalle Valo

Re: [PATCH v7] ath10k: add LED and GPIO controlling support for various chipsets

[Bo YU]

Hi,
On Tue, Feb 20, 2018 at 08:32:59AM +0100, s.gottsch...@dd-wrt.com wrote:

From: Sebastian Gottschall 

Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based 
chipsets with on chipset connected led's
using WMI Firmware API.
The LED device will get available named as "ath10k-phyX" at sysfs and can be 
controlled with various triggers.
adds also debugfs interface for gpio control.

Signed-off-by: Sebastian Gottschall 

v2  add correct gpio count per chipset and remove IPQ4019 support since this 
chipset does not make use of specific gpios)
v5  fix compiling without LED_CLASS and GPIOLIB support, fix also error by 
kbuild test robot which does not occur in standard builds. curious
v6  correct return values and fix comment style
v7  fix ath10k_unregister_led for compiling without LED_CLASS
Wq
---
drivers/net/wireless/ath/ath10k/core.c| 183 +-
drivers/net/wireless/ath/ath10k/core.h|  20 +++-
drivers/net/wireless/ath/ath10k/debug.c   | 146 
drivers/net/wireless/ath/ath10k/hw.h  |   2 +
drivers/net/wireless/ath/ath10k/mac.c |   6 +
drivers/net/wireless/ath/ath10k/wmi-ops.h |  36 +-
drivers/net/wireless/ath/ath10k/wmi-tlv.c |  65 +++
drivers/net/wireless/ath/ath10k/wmi.c |  46 
drivers/net/wireless/ath/ath10k/wmi.h |  36 ++
9 files changed, 536 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index f3ec13b80b20..e50977f97b18 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -21,6 +21,10 @@
#include 
#include 
#include 
+#include 
+#include 
+#include 
+

#include "core.h"
#include "mac.h"
@@ -65,6 +69,8 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] 
= {
.id = QCA988X_HW_2_0_VERSION,
.dev_id = QCA988X_2_0_DEVICE_ID,
.name = "qca988x hw2.0",
+   .led_pin = 1,
+   .gpio_count = 24,
.patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
@@ -94,6 +100,8 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] 
= {
.id = QCA988X_HW_2_0_VERSION,
.dev_id = QCA988X_2_0_DEVICE_ID_UBNT,
.name = "qca988x hw2.0 ubiquiti",
+   .led_pin = 1,
+   .gpio_count = 24,
.patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
@@ -123,6 +131,8 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.id = QCA9887_HW_1_0_VERSION,
.dev_id = QCA9887_1_0_DEVICE_ID,
.name = "qca9887 hw1.0",
+   .led_pin = 1,
+   .gpio_count = 24,
.patch_load_addr = QCA9887_HW_1_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
@@ -267,6 +277,8 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.id = QCA99X0_HW_2_0_DEV_VERSION,
.dev_id = QCA99X0_2_0_DEVICE_ID,
.name = "qca99x0 hw2.0",
+   .led_pin = 17,
+   .gpio_count = 35,
.patch_load_addr = QCA99X0_HW_2_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.otp_exe_param = 0x0700,
@@ -301,6 +313,8 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.id = QCA9984_HW_1_0_DEV_VERSION,
.dev_id = QCA9984_1_0_DEVICE_ID,
.name = "qca9984/qca9994 hw1.0",
+   .led_pin = 17,
+   .gpio_count = 35,
.patch_load_addr = QCA9984_HW_1_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_EACH,
@@ -340,6 +354,8 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.id = QCA9888_HW_2_0_DEV_VERSION,
.dev_id = QCA9888_2_0_DEVICE_ID,
.name = "qca9888 hw2.0",
+   .led_pin = 17,
+   .gpio_count = 35,
.patch_load_addr = QCA9888_HW_2_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_EACH,
@@ -2132,12 +2148,148 @@ static int ath10k_core_reset_rx_filter(struct ath10k 
*ar)
return 0;
}

+#ifdef CONFIG_GPIOLIB
+
+static int ath10k_gpio_pin_cfg_input(struct gpio_chip *chip, unsigned offset)
+{
+   struct ath10k_gpiocontrol *gpio = container_of(chip, struct 
ath10k_gpiocontrol, gchip);
+   ath10k_wmi_gpio_config(gpio->ar, offset, 1, WMI_GPIO_PULL_NONE, 
WMI_GPIO_INTTYPE_DISABLE); /* configure to input */
+   

[4.4-stable 17/22] cw1200: fix bogus maybe-uninitialized warning

[Arnd Bergmann]

commit 7fc1503c906f0fac62d3506a6e993e49fb996248 upstream.

On x86, the cw1200 driver produces a rather silly warning about the
possible use of the 'ret' variable without an initialization
presumably after being confused by the architecture specific definition
of WARN_ON:

drivers/net/wireless/st/cw1200/wsm.c: In function ‘wsm_handle_rx’:
drivers/net/wireless/st/cw1200/wsm.c:1457:9: error: ‘ret’ may be used 
uninitialized in this function [-Werror=maybe-uninitialized]

We have already checked that 'count' is larger than 0 here, so
we know that 'ret' is initialized. Changing the 'for' loop
into do/while also makes this clear to the compiler.

Suggested-by: David Laight 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Kalle Valo 
[arnd: rebased to 4.4]
Signed-off-by: Arnd Bergmann 
---
 drivers/net/wireless/cw1200/wsm.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/cw1200/wsm.c 
b/drivers/net/wireless/cw1200/wsm.c
index 9e0ca3048657..3dd46c78c1cc 100644
--- a/drivers/net/wireless/cw1200/wsm.c
+++ b/drivers/net/wireless/cw1200/wsm.c
@@ -379,7 +379,6 @@ static int wsm_multi_tx_confirm(struct cw1200_common *priv,
 {
int ret;
int count;
-   int i;
 
count = WSM_GET32(buf);
if (WARN_ON(count <= 0))
@@ -395,11 +394,10 @@ static int wsm_multi_tx_confirm(struct cw1200_common 
*priv,
}
 
cw1200_debug_txed_multi(priv, count);
-   for (i = 0; i < count; ++i) {
+   do {
ret = wsm_tx_confirm(priv, buf, link_id);
-   if (ret)
-   return ret;
-   }
+   } while (!ret && --count);
+
return ret;
 
 underflow:
-- 
2.9.0

Re: testing tool for packet delay

[Toke Høiland-Jørgensen]

Steve deRosier  writes:

> On Mon, Feb 19, 2018 at 9:19 AM, sdnlabs Janakaraj  
> wrote:
>>
>> Hello All,
>>
>> I am working on delay analysis of packets in wireless stacks. I am
>> able to see lots of papers talk about therotical analysis. But I am
>> more interested in practical evaluation.
>>
>> I am reaching out to developers community to learn how they actually
>> evaluate the performance of the stack. In particular, I am looking for
>> ideas to evaluate the delay experienced by packets within the
>> mac802.11 stack.
>>
>
> Hi Prabhu,
>
> Sounds like an interesting project. More often my instrumentation
> focuses on aggregate performance and iperf throughput numbers suffices
> for most of that. Occasionally I utilize internal performance measures
> and/or data provided me by ftrace and related tools.
>
> If you're unfamiliar with it, I suggest you look at the Bufferbloat
> and Make-wifi-fast projects. I suspect that their data and techniques
> and tools might be of interest to you:
>
> https://www.bufferbloat.net/projects/make-wifi-fast/

Bufferbloat/make-wifi-fast community member checking in ;)

Basically, what we've been doing to analyse (and reduce) the latency of
the queueing system in the WiFi stack, is to put it under load and
measure how it behaves. This is not so much through the use of tracing
tools as it is an end-to-end black-box measurement approach.

The go-to mechanism for this is to run a latency measurement (either a
simple ICMP ping, or a UDP measurement flow using a tool such as
irtt[1]), then load the connection with one or more TCP flows and see
how it impacts latency. You can of course vary the number of flows,
diffserv markings, etc. to get different insights.

I'm the author of a test tool that automates a lot of this and which can
also collect a lot of statistics from the stack while doing so. The tool
is called Flent[2] and is open source. Feel free to try it out and ask
any questions that come up :)

-Toke

[1] https://github.com/peteheist/irtt/
[2] https://flent.org