Re: [PATCH 1/2] ath10k: Define an enum to enable cycle counter wraparound logic

2016-06-04 Thread Thiagarajan, Vasanthakumar
>> --- a/drivers/net/wireless/ath/ath10k/core.c
>> +++ b/drivers/net/wireless/ath/ath10k/core.c
>> @@ -55,7 +55,7 @@ static const struct ath10k_hw_params 
>> ath10k_hw_params_list[] = {
>>  .name = "qca988x hw2.0",
>>  .patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
>>  .uart_pin = 7,
>> -.has_shifted_cc_wraparound = true,
>> +.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
>>  .otp_exe_param = 0,
>>  .channel_counters_freq_hz = 88000,
>>  .max_probe_resp_desc_thres = 0,
>> @@ -224,7 +224,7 @@ static const struct ath10k_hw_params 
>> ath10k_hw_params_list[] = {
>>  .name = "qca4019 hw1.0",
>>  .patch_load_addr = QCA4019_HW_1_0_PATCH_LOAD_ADDR,
>>  .uart_pin = 7,
>> -.has_shifted_cc_wraparound = true,
>> +.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
>>  .otp_exe_param = 0x001,
>>  .continuous_frag_desc = true,
>>  .channel_counters_freq_hz = 125000,
>
> As the pending branch has the QCA9887 patch I added
> ATH10K_HW_CC_WRAP_SHIFTED_ALL also for QCA9887. Please review my changes
> in the pending branch:
>
> https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending=2fa32dbd9f26e8b2f323ca30ad116ea486840aba
>

Looks good, thanks.

Vasanth
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: pull-request: wireless-drivers 2016-06-04

2016-06-04 Thread David Miller
From: Kalle Valo 
Date: Sat, 04 Jun 2016 18:45:21 +0300

> few fixes for 4.7. Please let me know if you have any issues.

Pulled, thanks kalle.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 1/2] b43: Remove unused phy_a code

2016-06-04 Thread Larry Finger

On 06/04/2016 09:54 AM, Guenter Roeck wrote:

gcc-6 reports the following error with -Werror=unused-const-variable.

drivers/net/wireless/broadcom/b43/phy_a.c:576:40: error:
'b43_phyops_a' defined but not used

Per Michael Büsch: "All a-phy code is usused", so remove it all,
and move the remaining Type-G initialization code into phy_g.c.

Reported-by: Fengguang Wu  [0-day test robot]
Cc: Michael Büsch 
Signed-off-by: Guenter Roeck 
---
v3: Do not rename b43_phy_inita()
v2: Remove phy_a.c; move left-over code into phy_g.c
 Remove now unused data structure


These two patches have been tested on a BCM4318.

Larry

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: ath9k_htc firmware

2016-06-04 Thread Oleksij Rempel
Am 04.06.2016 um 21:44 schrieb bruce m beach:
>>> I'm looking for some kind of simple request in the ath9k_htc driver, through
>>> the usb ep0, like a memory read on the card, where a urb is sent with
>>> the resulting chain of events. The simpler the better. The simplest.
> 
>> For EP0 on drivers site:
>> static int ath9k_hif_usb_download_fw(struct hif_device_usb *hif_dev)
>> {
>> int transfer, err;
>> const void *data = hif_dev->fw_data;
>> size_t len = hif_dev->fw_size;
>> u32 addr = AR9271_FIRMWARE;
>> u8 *buf = kzalloc(4096, GFP_KERNEL);
>> u32 firm_offset;
>> ...
> 
>   What about the code for setting and resetting leds ???
> 
> Bruce

It is EP3/EP4 and it is not working without firmware.
Here is one example how you can add new command to firmware:
https://github.com/olerem/open-ath9k-htc-firmware/commit/c73c159303e30a28e2d3dc05ba0d2d15504e5fad


And for kernel driver:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8badb50cfab6d433622dbfd5a90b6adf27333107


PS: Grr... today i send message from wrong email. Sorry for the spam



-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature


ath9k_htc firmware

2016-06-04 Thread bruce m beach
>> I'm looking for some kind of simple request in the ath9k_htc driver, through
>> the usb ep0, like a memory read on the card, where a urb is sent with
>> the resulting chain of events. The simpler the better. The simplest.

> For EP0 on drivers site:
> static int ath9k_hif_usb_download_fw(struct hif_device_usb *hif_dev)
> {
> int transfer, err;
> const void *data = hif_dev->fw_data;
> size_t len = hif_dev->fw_size;
> u32 addr = AR9271_FIRMWARE;
> u8 *buf = kzalloc(4096, GFP_KERNEL);
> u32 firm_offset;
> ...

  What about the code for setting and resetting leds ???

Bruce
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Patch "ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards." has been added to the 4.6-stable tree

2016-06-04 Thread gregkh

This is a note to let you know that I've just added the patch titled

ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards.

to the 4.6-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 ath9k-fix-led-polarity-for-some-mini-pci-ar9220-mb92-cards.patch
and it can be found in the queue-4.6 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From 0f9edcdd88a993914fa1d1dc369b35dc503979db Mon Sep 17 00:00:00 2001
From: "Vittorio Gambaletta (VittGam)" 
Date: Mon, 11 Apr 2016 04:48:55 +0200
Subject: ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards.

From: Vittorio Gambaletta (VittGam) 

commit 0f9edcdd88a993914fa1d1dc369b35dc503979db upstream.

The Wistron DNMA-92 and Compex WLM200NX have inverted LED polarity
(active high instead of active low).

The same PCI Subsystem ID is used by both cards, which are based on
the same Atheros MB92 design.

Cc: 
Cc: 
Cc: 
Signed-off-by: Vittorio Gambaletta 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/ath/ath9k/pci.c |   10 ++
 1 file changed, 10 insertions(+)

--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -28,6 +28,16 @@ static const struct pci_device_id ath_pc
{ PCI_VDEVICE(ATHEROS, 0x0024) }, /* PCI-E */
{ PCI_VDEVICE(ATHEROS, 0x0027) }, /* PCI   */
{ PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI   */
+
+#ifdef CONFIG_ATH9K_PCOEM
+   /* Mini PCI AR9220 MB92 cards: Compex WLM200NX, Wistron DNMA-92 */
+   { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
+0x0029,
+PCI_VENDOR_ID_ATHEROS,
+0x2096),
+ .driver_data = ATH9K_PCI_LED_ACT_HI },
+#endif
+
{ PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */
 
 #ifdef CONFIG_ATH9K_PCOEM


Patches currently in stable-queue which might be from 
linux-wirel...@vittgam.net are

queue-4.6/ath9k-add-a-module-parameter-to-invert-led-polarity.patch
queue-4.6/ath9k-fix-led-polarity-for-some-mini-pci-ar9220-mb92-cards.patch
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Patch "ath9k: Add a module parameter to invert LED polarity." has been added to the 4.6-stable tree

2016-06-04 Thread gregkh

This is a note to let you know that I've just added the patch titled

ath9k: Add a module parameter to invert LED polarity.

to the 4.6-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 ath9k-add-a-module-parameter-to-invert-led-polarity.patch
and it can be found in the queue-4.6 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From cd84042ce9040ad038e958bc67a46fcfc015c736 Mon Sep 17 00:00:00 2001
From: "Vittorio Gambaletta (VittGam)" 
Date: Mon, 11 Apr 2016 04:48:54 +0200
Subject: ath9k: Add a module parameter to invert LED polarity.

From: Vittorio Gambaletta (VittGam) 

commit cd84042ce9040ad038e958bc67a46fcfc015c736 upstream.

The LED can be active high instead of active low on some hardware.

Add the led_active_high module parameter. It defaults to -1 to obey
platform data as before.

Setting the parameter to 1 or 0 will force the LED respectively
active high or active low.

Cc: 
Cc: 
Cc: 
Signed-off-by: Vittorio Gambaletta 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/ath/ath9k/init.c |7 +++
 1 file changed, 7 insertions(+)

--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -49,6 +49,10 @@ int ath9k_led_blink;
 module_param_named(blink, ath9k_led_blink, int, 0444);
 MODULE_PARM_DESC(blink, "Enable LED blink on activity");
 
+static int ath9k_led_active_high = -1;
+module_param_named(led_active_high, ath9k_led_active_high, int, 0444);
+MODULE_PARM_DESC(led_active_high, "Invert LED polarity");
+
 static int ath9k_btcoex_enable;
 module_param_named(btcoex_enable, ath9k_btcoex_enable, int, 0444);
 MODULE_PARM_DESC(btcoex_enable, "Enable wifi-BT coexistence");
@@ -600,6 +604,9 @@ static int ath9k_init_softc(u16 devid, s
if (ret)
return ret;
 
+   if (ath9k_led_active_high != -1)
+   ah->config.led_active_high = ath9k_led_active_high == 1;
+
/*
 * Enable WLAN/BT RX Antenna diversity only when:
 *


Patches currently in stable-queue which might be from 
linux-wirel...@vittgam.net are

queue-4.6/ath9k-add-a-module-parameter-to-invert-led-polarity.patch
queue-4.6/ath9k-fix-led-polarity-for-some-mini-pci-ar9220-mb92-cards.patch
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Patch "ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards." has been added to the 4.4-stable tree

2016-06-04 Thread gregkh

This is a note to let you know that I've just added the patch titled

ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards.

to the 4.4-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 ath9k-fix-led-polarity-for-some-mini-pci-ar9220-mb92-cards.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From 0f9edcdd88a993914fa1d1dc369b35dc503979db Mon Sep 17 00:00:00 2001
From: "Vittorio Gambaletta (VittGam)" 
Date: Mon, 11 Apr 2016 04:48:55 +0200
Subject: ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards.

From: Vittorio Gambaletta (VittGam) 

commit 0f9edcdd88a993914fa1d1dc369b35dc503979db upstream.

The Wistron DNMA-92 and Compex WLM200NX have inverted LED polarity
(active high instead of active low).

The same PCI Subsystem ID is used by both cards, which are based on
the same Atheros MB92 design.

Cc: 
Cc: 
Cc: 
Signed-off-by: Vittorio Gambaletta 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/ath/ath9k/pci.c |   10 ++
 1 file changed, 10 insertions(+)

--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -28,6 +28,16 @@ static const struct pci_device_id ath_pc
{ PCI_VDEVICE(ATHEROS, 0x0024) }, /* PCI-E */
{ PCI_VDEVICE(ATHEROS, 0x0027) }, /* PCI   */
{ PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI   */
+
+#ifdef CONFIG_ATH9K_PCOEM
+   /* Mini PCI AR9220 MB92 cards: Compex WLM200NX, Wistron DNMA-92 */
+   { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
+0x0029,
+PCI_VENDOR_ID_ATHEROS,
+0x2096),
+ .driver_data = ATH9K_PCI_LED_ACT_HI },
+#endif
+
{ PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */
 
 #ifdef CONFIG_ATH9K_PCOEM


Patches currently in stable-queue which might be from 
linux-wirel...@vittgam.net are

queue-4.4/ath9k-add-a-module-parameter-to-invert-led-polarity.patch
queue-4.4/ath9k-fix-led-polarity-for-some-mini-pci-ar9220-mb92-cards.patch
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Patch "ath9k: Add a module parameter to invert LED polarity." has been added to the 4.4-stable tree

2016-06-04 Thread gregkh

This is a note to let you know that I've just added the patch titled

ath9k: Add a module parameter to invert LED polarity.

to the 4.4-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 ath9k-add-a-module-parameter-to-invert-led-polarity.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From cd84042ce9040ad038e958bc67a46fcfc015c736 Mon Sep 17 00:00:00 2001
From: "Vittorio Gambaletta (VittGam)" 
Date: Mon, 11 Apr 2016 04:48:54 +0200
Subject: ath9k: Add a module parameter to invert LED polarity.

From: Vittorio Gambaletta (VittGam) 

commit cd84042ce9040ad038e958bc67a46fcfc015c736 upstream.

The LED can be active high instead of active low on some hardware.

Add the led_active_high module parameter. It defaults to -1 to obey
platform data as before.

Setting the parameter to 1 or 0 will force the LED respectively
active high or active low.

Cc: 
Cc: 
Cc: 
Signed-off-by: Vittorio Gambaletta 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/ath/ath9k/init.c |7 +++
 1 file changed, 7 insertions(+)

--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -49,6 +49,10 @@ int ath9k_led_blink;
 module_param_named(blink, ath9k_led_blink, int, 0444);
 MODULE_PARM_DESC(blink, "Enable LED blink on activity");
 
+static int ath9k_led_active_high = -1;
+module_param_named(led_active_high, ath9k_led_active_high, int, 0444);
+MODULE_PARM_DESC(led_active_high, "Invert LED polarity");
+
 static int ath9k_btcoex_enable;
 module_param_named(btcoex_enable, ath9k_btcoex_enable, int, 0444);
 MODULE_PARM_DESC(btcoex_enable, "Enable wifi-BT coexistence");
@@ -600,6 +604,9 @@ static int ath9k_init_softc(u16 devid, s
if (ret)
return ret;
 
+   if (ath9k_led_active_high != -1)
+   ah->config.led_active_high = ath9k_led_active_high == 1;
+
/*
 * Enable WLAN/BT RX Antenna diversity only when:
 *


Patches currently in stable-queue which might be from 
linux-wirel...@vittgam.net are

queue-4.4/ath9k-add-a-module-parameter-to-invert-led-polarity.patch
queue-4.4/ath9k-fix-led-polarity-for-some-mini-pci-ar9220-mb92-cards.patch
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Patch "ath9k: Add a module parameter to invert LED polarity." has been added to the 4.5-stable tree

2016-06-04 Thread gregkh

This is a note to let you know that I've just added the patch titled

ath9k: Add a module parameter to invert LED polarity.

to the 4.5-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 ath9k-add-a-module-parameter-to-invert-led-polarity.patch
and it can be found in the queue-4.5 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From cd84042ce9040ad038e958bc67a46fcfc015c736 Mon Sep 17 00:00:00 2001
From: "Vittorio Gambaletta (VittGam)" 
Date: Mon, 11 Apr 2016 04:48:54 +0200
Subject: ath9k: Add a module parameter to invert LED polarity.

From: Vittorio Gambaletta (VittGam) 

commit cd84042ce9040ad038e958bc67a46fcfc015c736 upstream.

The LED can be active high instead of active low on some hardware.

Add the led_active_high module parameter. It defaults to -1 to obey
platform data as before.

Setting the parameter to 1 or 0 will force the LED respectively
active high or active low.

Cc: 
Cc: 
Cc: 
Signed-off-by: Vittorio Gambaletta 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/ath/ath9k/init.c |7 +++
 1 file changed, 7 insertions(+)

--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -49,6 +49,10 @@ int ath9k_led_blink;
 module_param_named(blink, ath9k_led_blink, int, 0444);
 MODULE_PARM_DESC(blink, "Enable LED blink on activity");
 
+static int ath9k_led_active_high = -1;
+module_param_named(led_active_high, ath9k_led_active_high, int, 0444);
+MODULE_PARM_DESC(led_active_high, "Invert LED polarity");
+
 static int ath9k_btcoex_enable;
 module_param_named(btcoex_enable, ath9k_btcoex_enable, int, 0444);
 MODULE_PARM_DESC(btcoex_enable, "Enable wifi-BT coexistence");
@@ -600,6 +604,9 @@ static int ath9k_init_softc(u16 devid, s
if (ret)
return ret;
 
+   if (ath9k_led_active_high != -1)
+   ah->config.led_active_high = ath9k_led_active_high == 1;
+
/*
 * Enable WLAN/BT RX Antenna diversity only when:
 *


Patches currently in stable-queue which might be from 
linux-wirel...@vittgam.net are

queue-4.5/ath9k-add-a-module-parameter-to-invert-led-polarity.patch
queue-4.5/ath9k-fix-led-polarity-for-some-mini-pci-ar9220-mb92-cards.patch
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: rt2800usb firmware rt2870.bin 0.36 not scanning

2016-06-04 Thread Xose Vazquez Perez
Craig McQueen wrote:

> I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based (5392
> chipset). I'm trying to use it on a BeagleBone Black based system with
> 3.14.x kernel built with Yocto. We're using ConnMan 1.30 at the moment.

Try it with a _desktop x86_64 distribution_ , with a *recent kernel*
as Fedora: (WORK is gnome) https://alt.fedoraproject.org/pub/alt/live-respins/

> We've been finding some instabilities with it periodically disconnecting
> from some networks. So we tried upgrading the firmware file rt2870.bin
> from version 0.29 to 0.36. That seems to be more stable with the
> network. However, we're finding that it initially doesn't connect, until
> the Wi-Fi has been disabled and then re-enabled. '  scan wifi'
> and 'iwlist scan' don't return anything until Wi-Fi has been disabled
> and then re-enabled.

Don't use any wrapper(NM, ConnMan, wicd, ...), usually are buggy. You should
use raw commands "iw" and "wpa_supplicant". Hints:
https://wireless.wiki.kernel.org/en/users/documentation/iw and  wpa_supplicant
always running with "-Dnl80211"

> Have there been any Linux driver changes needed to support this 0.36
> firmware? Does anyone have any pointers on where to look to understand
> this behaviour between 0.29 and 0.36 firmware?

closed source, but old changelogs are available at:
http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2013-September/006391.html

Related to latest firmware releases, ralink/mediatek guys say:
"According to the engineers comment, the firmware didn't change much
these years, just some bbp register update and led stuff."
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] rtlwifi: Change long delays to sleeps

2016-06-04 Thread Kalle Valo
Jan Kiszka  writes:

> On 2016-02-15 23:12, Larry Finger wrote:
>> Routine rtl_addr_delay() uses delay statements in code that can
>> sleep. To improve system responsiveness, the various delay statements
>> are changed.
>> 
>> In addition, routines rtl_rfreg_delay() and rtl_bb_delay() are
>> rewritten to use the code in rtl_addr_delay() for most of their
>> input values.
>> 
>> Suggested-by: Byeoungwook Kim 
>> Signed-off-by: Larry Finger 

[...]

> This breaks spectacularly when turning on a little bit of correctness
> checking:
>
> BUG: scheduling while atomic: wpa_supplicant/1116/0x0002

This should fix it:

https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers.git/commit/?id=de26859dcf363d520cc44e59f6dcaf20ebe0aadf

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] rtlwifi: Change long delays to sleeps

2016-06-04 Thread Jan Kiszka
On 2016-02-15 23:12, Larry Finger wrote:
> Routine rtl_addr_delay() uses delay statements in code that can
> sleep. To improve system responsiveness, the various delay statements
> are changed.
> 
> In addition, routines rtl_rfreg_delay() and rtl_bb_delay() are
> rewritten to use the code in rtl_addr_delay() for most of their
> input values.
> 
> Suggested-by: Byeoungwook Kim 
> Signed-off-by: Larry Finger 
> ---
> 
> Kalle,
> 
> This patch will interfere with a set of 3 patches submitted by Byeoungwook Kim
>  on Feb. 3, 2016 that are currently in the deferred list
> at patchwork.
> 
> Larry
> 
>  drivers/net/wireless/realtek/rtlwifi/core.c | 44 
> -
>  1 file changed, 12 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c 
> b/drivers/net/wireless/realtek/rtlwifi/core.c
> index 02eba0e..16ad0d6 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/core.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/core.c
> @@ -54,59 +54,39 @@ EXPORT_SYMBOL(channel5g_80m);
>  void rtl_addr_delay(u32 addr)
>  {
>   if (addr == 0xfe)
> - mdelay(50);
> + msleep(50);
>   else if (addr == 0xfd)
> - mdelay(5);
> + msleep(5);
>   else if (addr == 0xfc)
> - mdelay(1);
> + msleep(1);
>   else if (addr == 0xfb)
> - udelay(50);
> + usleep_range(50, 100);
>   else if (addr == 0xfa)
> - udelay(5);
> + usleep_range(5, 10);
>   else if (addr == 0xf9)
> - udelay(1);
> + usleep_range(1, 2);
>  }
>  EXPORT_SYMBOL(rtl_addr_delay);
>  
>  void rtl_rfreg_delay(struct ieee80211_hw *hw, enum radio_path rfpath, u32 
> addr,
>u32 mask, u32 data)
>  {
> - if (addr == 0xfe) {
> - mdelay(50);
> - } else if (addr == 0xfd) {
> - mdelay(5);
> - } else if (addr == 0xfc) {
> - mdelay(1);
> - } else if (addr == 0xfb) {
> - udelay(50);
> - } else if (addr == 0xfa) {
> - udelay(5);
> - } else if (addr == 0xf9) {
> - udelay(1);
> + if (addr >= 0xf9 && addr <= 0xfe) {
> + rtl_addr_delay(addr);
>   } else {
>   rtl_set_rfreg(hw, rfpath, addr, mask, data);
> - udelay(1);
> + usleep_range(1, 2);
>   }
>  }
>  EXPORT_SYMBOL(rtl_rfreg_delay);
>  
>  void rtl_bb_delay(struct ieee80211_hw *hw, u32 addr, u32 data)
>  {
> - if (addr == 0xfe) {
> - mdelay(50);
> - } else if (addr == 0xfd) {
> - mdelay(5);
> - } else if (addr == 0xfc) {
> - mdelay(1);
> - } else if (addr == 0xfb) {
> - udelay(50);
> - } else if (addr == 0xfa) {
> - udelay(5);
> - } else if (addr == 0xf9) {
> - udelay(1);
> + if (addr >= 0xf9 && addr <= 0xfe) {
> + rtl_addr_delay(addr);
>   } else {
>   rtl_set_bbreg(hw, addr, MASKDWORD, data);
> - udelay(1);
> + usleep_range(1, 2);
>   }
>  }
>  EXPORT_SYMBOL(rtl_bb_delay);
> 

This breaks spectacularly when turning on a little bit of correctness
checking:

BUG: scheduling while atomic: wpa_supplicant/1116/0x0002
[...]
Call Trace:
 [] dump_trace+0x59/0x340
 [] show_stack_log_lvl+0xfc/0x190
 [] show_stack+0x21/0x40
 [] dump_stack+0x5c/0x7e
 [] __schedule_bug+0x4b/0x59
 [] thread_return+0x562/0x6b0
 [] schedule+0x3c/0x90
 [] schedule_hrtimeout_range_clock+0xab/0x130
 [] usleep_range+0x3b/0x40
 [] rtl92c_phy_config_rf_with_headerfile+0x104/0x2f0 
[rtl8192ce]
 [] rtl92ce_phy_rf6052_config+0x1b0/0x310 [rtl8192ce]
 [] rtl92ce_hw_init+0xa8b/0x17e0 [rtl8192ce]
 [] rtl_ps_enable_nic+0x3b/0xc0 [rtlwifi]
 [] rtl92c_phy_set_rf_power_state+0x509/0x760 [rtl8192ce]
 [] rtl_ps_set_rf_state+0xd4/0x200 [rtlwifi]
 [] _rtl_ps_inactive_ps+0x38/0xb0 [rtlwifi]
 [] rtl_ips_nic_on+0x78/0xb0 [rtlwifi]
 [] rtl_op_config+0x278/0x440 [rtlwifi]
 [] ieee80211_hw_config+0x56/0x3a0 [mac80211]
 [] ieee80211_add_chanctx+0x17a/0x1c0 [mac80211]
 [] ieee80211_new_chanctx+0x2d/0x80 [mac80211]
 [] ieee80211_vif_use_channel+0x1fb/0x250 [mac80211]
 [] ieee80211_prep_connection+0x188/0x8e0 [mac80211]
 [] ieee80211_mgd_auth+0x22a/0x330 [mac80211]
 [] cfg80211_mlme_auth+0x117/0x230 [cfg80211]
 [] nl80211_authenticate+0x2a7/0x300 [cfg80211]
 [] genl_family_rcv_msg+0x1b6/0x380
 [] genl_rcv_msg+0x79/0xb0
 [] netlink_rcv_skb+0x92/0xa0
 [] genl_rcv+0x24/0x40
 [] netlink_unicast+0x146/0x1f0
 [] netlink_sendmsg+0x323/0x3a0
 [] sock_sendmsg+0x30/0x40
 [] ___sys_sendmsg+0x279/0x290
 [] __sys_sendmsg+0x41/0x70
 [] do_syscall_64+0x59/0xb0
 [] entry_SYSCALL64_slow_path+0x25/0x25

So please revert this commit. I agree with the general goal, but this
approach does not work. I had to in order to make my wifi work again.

Then, when looking deeper, those local_irq_enable constructs in 

pull-request: wireless-drivers 2016-06-04

2016-06-04 Thread Kalle Valo
Hi Dave,

few fixes for 4.7. Please let me know if you have any issues.

Kalle

The following changes since commit b7e7ad611e24b95b0db2998428ce78370415c086:

  Merge branch 'qed-fixes' (2016-05-26 12:27:33 -0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git 
tags/wireless-drivers-for-davem-2016-06-04

for you to fetch changes up to 182fd9eecb287e696c82b30d06c6150d80a49c5b:

  MAINTAINERS: Add file patterns for wireless device tree bindings (2016-06-04 
17:24:02 +0300)


wireless-drivers fixes for 4.7

brcmfmac

* add fallback RSSI report for devices that do not report per-chain values
* fix a null pointer derefence regression on PCIe full dongle devices

rtlwifi

* fix scheduling while atomic regression from commit 49f86ec21c01

MAINTAINERS

* add file patterns for wireless device tree bindings


Franky Lin (1):
  brcmfmac: add eth_type_trans back for PCIe full dongle

Geert Uytterhoeven (1):
  MAINTAINERS: Add file patterns for wireless device tree bindings

Jaap Jan Meijer (1):
  brcmfmac: add fallback for devices that do not report per-chain values

Larry Finger (1):
  rtlwifi: Fix scheduling while atomic error from commit 49f86ec21c01

 MAINTAINERS|1 +
 .../broadcom/brcm80211/brcmfmac/cfg80211.c |   16 
 .../wireless/broadcom/brcm80211/brcmfmac/msgbuf.c  |2 ++
 drivers/net/wireless/realtek/rtlwifi/core.c|6 +++---
 4 files changed, 22 insertions(+), 3 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets

2016-06-04 Thread Kalle Valo
Jonas Gorski  writes:

> On 26 May 2016 at 20:52, Avinash Patil  wrote:
>
>> This email, including its contents and any attachment(s), may contain
>> confidential information of Quantenna Communications, Inc. and is
>> solely for the intended recipient(s). If you may have received this
>> in error, please contact the sender and permanently delete this
>> email, its contents and any attachment(s).
>
> You will need to remove this footer to be taken seriously, as
> confidential information would be not GPL compatible, and "may
> contain" means it is too risky to accept that.

Yeah, I'm not going to take (or even look) patches with such
disclaimers. So please resend so that we can start the review.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [7/7] mwifiex: fix typo

2016-06-04 Thread Kalle Valo
Julia Lawall  wrote:
> firmare -> firmware
> 
> Signed-off-by: Julia Lawall 

Thanks, 1 patch applied to wireless-drivers-next.git:

47ce90f9f08a mwifiex: fix typo

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9113281/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: b43: don't unconditionally fall back to CCK if the rate is 6MB OFDM.

2016-06-04 Thread Kalle Valo
Adrian Chadd  wrote:
> Check the current PHY operating mode (gmode) to see if we should
> fall back from 6MB OFDM to 11MB CCK.  For 5GHz operation this isn't
> allowed.
> 
> Note, the fallback lookup is only done for RTS rates; normal fallback
> rates are done via mac80211 and aren't affected by this change.
> 
> Signed-off-by: Adrian Chadd 

Thanks, 1 patch applied to wireless-drivers-next.git:

d0b03439f784 b43: don't unconditionally fall back to CCK if the rate is 6MB 
OFDM.

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9108351/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [v2,1/2] brcmfmac: Fix kernel oops in failed chip_attach

2016-06-04 Thread Kalle Valo
Christian Daudt  wrote:
> When chip attach fails, brcmf_sdiod_intr_unregister is being called
> but that is too early as sdiodev->settings has not been set yet
> nor has brcmf_sdiod_intr_register been called.
> Change to use oob_irq_requested + newly created sd_irq_requested
> to decide on what to unregister at intr_unregister time.
> 
> Steps to reproduce problem:
> - modprobe brcmfmac using buggy FW
> - rmmod brcmfmac
> - modprobe brcmfmac again.
> 
> If done with a buggy firmware, brcm_chip_attach will fail on the
> 2nd modprobe triggering the call to intr_unregister and the
> kernel oops when attempting to de-reference sdiodev->settings->bus.sdio
> which has not yet been set.
> 
> Signed-off-by: Christian Daudt 

Thanks, 2 patches applied to wireless-drivers-next.git:

b88a2e80396b brcmfmac: Fix kernel oops in failed chip_attach
b746740147dc brcmfmac: Fix 'did not remove int handler' warning

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9075231/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [v2] carl9170: Clarify kconfig text

2016-06-04 Thread Kalle Valo
Lauri Kasanen  wrote:
> The previous text was confusing, leading readers to think this
> driver was a duplicate, and so didn't need to be enabled.
> 
> After the removal of the older staging driver, this is the only
> driver in mainline for these devices.
> 
> Signed-off-by: Lauri Kasanen 
> Acked-by: Christian Lamparter 

Thanks, 1 patch applied to wireless-drivers-next.git:

83e41e77819b carl9170: Clarify kconfig text

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/8861621/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


wireless-drivers-next open for 4.8

2016-06-04 Thread Kalle Valo
Bob Copeland  writes:

> Since Linus released 4.7-rc1 today, I've resumed wireless-testing
> updates since its merge window hiatus, with tag wt-2016-05-29.
>
> Please test and let me know of any issues.

I also opened wireless-drivers-next tree for patches going to 4.8. And
wireless-drivers continues to be open for important fixes and
regressions to 4.7.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 1/2] b43: Remove unused phy_a code

2016-06-04 Thread Guenter Roeck
gcc-6 reports the following error with -Werror=unused-const-variable.

drivers/net/wireless/broadcom/b43/phy_a.c:576:40: error:
'b43_phyops_a' defined but not used

Per Michael Büsch: "All a-phy code is usused", so remove it all,
and move the remaining Type-G initialization code into phy_g.c.

Reported-by: Fengguang Wu  [0-day test robot]
Cc: Michael Büsch 
Signed-off-by: Guenter Roeck 
---
v3: Do not rename b43_phy_inita()
v2: Remove phy_a.c; move left-over code into phy_g.c
Remove now unused data structure

 drivers/net/wireless/broadcom/b43/Makefile |   2 +-
 drivers/net/wireless/broadcom/b43/phy_a.c  | 595 -
 drivers/net/wireless/broadcom/b43/phy_a.h  |  22 -
 drivers/net/wireless/broadcom/b43/phy_common.h |   3 -
 drivers/net/wireless/broadcom/b43/phy_g.c  |  25 +-
 5 files changed, 21 insertions(+), 626 deletions(-)
 delete mode 100644 drivers/net/wireless/broadcom/b43/phy_a.c

diff --git a/drivers/net/wireless/broadcom/b43/Makefile 
b/drivers/net/wireless/broadcom/b43/Makefile
index ddc4df46656f..27fab958e3d5 100644
--- a/drivers/net/wireless/broadcom/b43/Makefile
+++ b/drivers/net/wireless/broadcom/b43/Makefile
@@ -1,6 +1,6 @@
 b43-y  += main.o
 b43-y  += bus.o
-b43-$(CONFIG_B43_PHY_G)+= phy_a.o phy_g.o tables.o lo.o wa.o
+b43-$(CONFIG_B43_PHY_G)+= phy_g.o tables.o lo.o wa.o
 b43-$(CONFIG_B43_PHY_N)+= tables_nphy.o
 b43-$(CONFIG_B43_PHY_N)+= radio_2055.o
 b43-$(CONFIG_B43_PHY_N)+= radio_2056.o
diff --git a/drivers/net/wireless/broadcom/b43/phy_a.c 
b/drivers/net/wireless/broadcom/b43/phy_a.c
deleted file mode 100644
index 99c036f5ecb7..
--- a/drivers/net/wireless/broadcom/b43/phy_a.c
+++ /dev/null
@@ -1,595 +0,0 @@
-/*
-
-  Broadcom B43 wireless driver
-  IEEE 802.11a PHY driver
-
-  Copyright (c) 2005 Martin Langer ,
-  Copyright (c) 2005-2007 Stefano Brivio 
-  Copyright (c) 2005-2008 Michael Buesch 
-  Copyright (c) 2005, 2006 Danny van Dyk 
-  Copyright (c) 2005, 2006 Andreas Jaggi 
-
-  This program is free software; you can redistribute it and/or modify
-  it under the terms of the GNU General Public License as published by
-  the Free Software Foundation; either version 2 of the License, or
-  (at your option) any later version.
-
-  This program is distributed in the hope that it will be useful,
-  but WITHOUT ANY WARRANTY; without even the implied warranty of
-  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-  GNU General Public License for more details.
-
-  You should have received a copy of the GNU General Public License
-  along with this program; see the file COPYING.  If not, write to
-  the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor,
-  Boston, MA 02110-1301, USA.
-
-*/
-
-#include 
-
-#include "b43.h"
-#include "phy_a.h"
-#include "phy_common.h"
-#include "wa.h"
-#include "tables.h"
-#include "main.h"
-
-
-/* Get the freq, as it has to be written to the device. */
-static inline u16 channel2freq_a(u8 channel)
-{
-   B43_WARN_ON(channel > 200);
-
-   return (5000 + 5 * channel);
-}
-
-static inline u16 freq_r3A_value(u16 frequency)
-{
-   u16 value;
-
-   if (frequency < 5091)
-   value = 0x0040;
-   else if (frequency < 5321)
-   value = 0x;
-   else if (frequency < 5806)
-   value = 0x0080;
-   else
-   value = 0x0040;
-
-   return value;
-}
-
-#if 0
-/* This function converts a TSSI value to dBm in Q5.2 */
-static s8 b43_aphy_estimate_power_out(struct b43_wldev *dev, s8 tssi)
-{
-   struct b43_phy *phy = >phy;
-   struct b43_phy_a *aphy = phy->a;
-   s8 dbm = 0;
-   s32 tmp;
-
-   tmp = (aphy->tgt_idle_tssi - aphy->cur_idle_tssi + tssi);
-   tmp += 0x80;
-   tmp = clamp_val(tmp, 0x00, 0xFF);
-   dbm = aphy->tssi2dbm[tmp];
-   //TODO: There's a FIXME on the specs
-
-   return dbm;
-}
-#endif
-
-static void b43_radio_set_tx_iq(struct b43_wldev *dev)
-{
-   static const u8 data_high[5] = { 0x00, 0x40, 0x80, 0x90, 0xD0 };
-   static const u8 data_low[5] = { 0x00, 0x01, 0x05, 0x06, 0x0A };
-   u16 tmp = b43_radio_read16(dev, 0x001E);
-   int i, j;
-
-   for (i = 0; i < 5; i++) {
-   for (j = 0; j < 5; j++) {
-   if (tmp == (data_high[i] << 4 | data_low[j])) {
-   b43_phy_write(dev, 0x0069,
- (i - j) << 8 | 0x00C0);
-   return;
-   }
-   }
-   }
-}
-
-static void aphy_channel_switch(struct b43_wldev *dev, unsigned int channel)
-{
-   u16 freq, r8, tmp;
-
-   freq = 

[PATCH v3 2/2] b43: Completely remove support for phy_a

2016-06-04 Thread Guenter Roeck
Per Michael Büsch: "All a-phy code is usused", so remove it all.

Cc: Michael Büsch 
Signed-off-by: Guenter Roeck 
---
v3: no change
v2: added patch

 drivers/net/wireless/broadcom/b43/main.c |  31 +---
 drivers/net/wireless/broadcom/b43/wa.c   | 283 +++
 drivers/net/wireless/broadcom/b43/xmit.c |  17 +-
 3 files changed, 24 insertions(+), 307 deletions(-)

diff --git a/drivers/net/wireless/broadcom/b43/main.c 
b/drivers/net/wireless/broadcom/b43/main.c
index 4ee5c5853f9f..6e5d9095b195 100644
--- a/drivers/net/wireless/broadcom/b43/main.c
+++ b/drivers/net/wireless/broadcom/b43/main.c
@@ -3180,7 +3180,6 @@ static void b43_rate_memory_write(struct b43_wldev *dev, 
u16 rate, int is_ofdm)
 static void b43_rate_memory_init(struct b43_wldev *dev)
 {
switch (dev->phy.type) {
-   case B43_PHYTYPE_A:
case B43_PHYTYPE_G:
case B43_PHYTYPE_N:
case B43_PHYTYPE_LP:
@@ -3194,8 +3193,6 @@ static void b43_rate_memory_init(struct b43_wldev *dev)
b43_rate_memory_write(dev, B43_OFDM_RATE_36MB, 1);
b43_rate_memory_write(dev, B43_OFDM_RATE_48MB, 1);
b43_rate_memory_write(dev, B43_OFDM_RATE_54MB, 1);
-   if (dev->phy.type == B43_PHYTYPE_A)
-   break;
/* fallthrough */
case B43_PHYTYPE_B:
b43_rate_memory_write(dev, B43_CCK_RATE_1MB, 0);
@@ -4604,14 +4601,6 @@ static int b43_phy_versioning(struct b43_wldev *dev)
if (radio_manuf != 0x17F /* Broadcom */)
unsupported = 1;
switch (phy_type) {
-   case B43_PHYTYPE_A:
-   if (radio_id != 0x2060)
-   unsupported = 1;
-   if (radio_rev != 1)
-   unsupported = 1;
-   if (radio_manuf != 0x17F)
-   unsupported = 1;
-   break;
case B43_PHYTYPE_B:
if ((radio_id & 0xFFF0) != 0x2050)
unsupported = 1;
@@ -4766,10 +4755,7 @@ static void b43_set_synth_pu_delay(struct b43_wldev 
*dev, bool idle)
u16 pu_delay;
 
/* The time value is in microseconds. */
-   if (dev->phy.type == B43_PHYTYPE_A)
-   pu_delay = 3700;
-   else
-   pu_delay = 1050;
+   pu_delay = 1050;
if (b43_is_mode(dev->wl, NL80211_IFTYPE_ADHOC) || idle)
pu_delay = 500;
if ((dev->phy.radio_ver == 0x2050) && (dev->phy.radio_rev == 8))
@@ -4784,14 +4770,10 @@ static void b43_set_pretbtt(struct b43_wldev *dev)
u16 pretbtt;
 
/* The time value is in microseconds. */
-   if (b43_is_mode(dev->wl, NL80211_IFTYPE_ADHOC)) {
+   if (b43_is_mode(dev->wl, NL80211_IFTYPE_ADHOC))
pretbtt = 2;
-   } else {
-   if (dev->phy.type == B43_PHYTYPE_A)
-   pretbtt = 120;
-   else
-   pretbtt = 250;
-   }
+   else
+   pretbtt = 250;
b43_shm_write16(dev, B43_SHM_SHARED, B43_SHM_SH_PRETBTT, pretbtt);
b43_write16(dev, B43_MMIO_TSF_CFP_PRETBTT, pretbtt);
 }
@@ -5380,10 +5362,6 @@ static void b43_supported_bands(struct b43_wldev *dev, 
bool *have_2ghz_phy,
 
/* As a fallback, try to guess using PHY type */
switch (dev->phy.type) {
-   case B43_PHYTYPE_A:
-   *have_2ghz_phy = false;
-   *have_5ghz_phy = true;
-   return;
case B43_PHYTYPE_G:
case B43_PHYTYPE_N:
case B43_PHYTYPE_LP:
@@ -5455,7 +5433,6 @@ static int b43_wireless_core_attach(struct b43_wldev *dev)
/* We don't support 5 GHz on some PHYs yet */
if (have_5ghz_phy) {
switch (dev->phy.type) {
-   case B43_PHYTYPE_A:
case B43_PHYTYPE_G:
case B43_PHYTYPE_LP:
case B43_PHYTYPE_HT:
diff --git a/drivers/net/wireless/broadcom/b43/wa.c 
b/drivers/net/wireless/broadcom/b43/wa.c
index c218c08fb2f5..0e96c08d1e17 100644
--- a/drivers/net/wireless/broadcom/b43/wa.c
+++ b/drivers/net/wireless/broadcom/b43/wa.c
@@ -30,33 +30,6 @@
 #include "phy_common.h"
 #include "wa.h"
 
-static void b43_wa_papd(struct b43_wldev *dev)
-{
-   u16 backup;
-
-   backup = b43_ofdmtab_read16(dev, B43_OFDMTAB_PWRDYN2, 0);
-   b43_ofdmtab_write16(dev, B43_OFDMTAB_PWRDYN2, 0, 7);
-   b43_ofdmtab_write16(dev, B43_OFDMTAB_UNKNOWN_APHY, 0, 0);
-   b43_dummy_transmission(dev, true, true);
-   b43_ofdmtab_write16(dev, B43_OFDMTAB_PWRDYN2, 0, backup);
-}
-
-static void b43_wa_auxclipthr(struct b43_wldev *dev)
-{
-   b43_phy_write(dev, B43_PHY_OFDM(0x8E), 0x3800);
-}
-
-static void b43_wa_afcdac(struct b43_wldev *dev)
-{
-   b43_phy_write(dev, 0x0035, 0x03FF);
-   b43_phy_write(dev, 0x0036, 0x0400);
-}
-
-static void b43_wa_txdc_offset(struct b43_wldev *dev)
-{
-   b43_ofdmtab_write16(dev, B43_OFDMTAB_DC, 0, 0x0051);

Re: [PATCH 1/2] ath10k: Define an enum to enable cycle counter wraparound logic

2016-06-04 Thread Valo, Kalle
Vasanthakumar Thiagarajan  writes:

> QCA988X hw implements a different cycle counter wraparound
> behaviour when compared to QCA4019. To properly handle different
> wraparound logic for these chipsets replace already available
> bool hw_params member, has_shifted_cc_wraparound, with an
> enum which could be extended to handle different wraparound
> behaviour. This patch keeps the existing logic functionally
> same and a prepares cycle counter wraparound handling to
> extend for other chips.
>
> Signed-off-by: Vasanthakumar Thiagarajan 

[...]

> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -55,7 +55,7 @@ static const struct ath10k_hw_params 
> ath10k_hw_params_list[] = {
>   .name = "qca988x hw2.0",
>   .patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
>   .uart_pin = 7,
> - .has_shifted_cc_wraparound = true,
> + .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
>   .otp_exe_param = 0,
>   .channel_counters_freq_hz = 88000,
>   .max_probe_resp_desc_thres = 0,
> @@ -224,7 +224,7 @@ static const struct ath10k_hw_params 
> ath10k_hw_params_list[] = {
>   .name = "qca4019 hw1.0",
>   .patch_load_addr = QCA4019_HW_1_0_PATCH_LOAD_ADDR,
>   .uart_pin = 7,
> - .has_shifted_cc_wraparound = true,
> + .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
>   .otp_exe_param = 0x001,
>   .continuous_frag_desc = true,
>   .channel_counters_freq_hz = 125000,

As the pending branch has the QCA9887 patch I added
ATH10K_HW_CC_WRAP_SHIFTED_ALL also for QCA9887. Please review my changes
in the pending branch:

https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending=2fa32dbd9f26e8b2f323ca30ad116ea486840aba

-- 
Kalle Valo--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: ath9k gpio request

2016-06-04 Thread Kalle Valo
(Fixing top posting)

"Pan, Miaoqing"  writes:

>>> --- a/drivers/net/wireless/ath/ath9k/reg.h
>>> +++ b/drivers/net/wireless/ath/ath9k/reg.h
>>> @@ -1122,8 +1122,8 @@ enum {
>>>   #define AR9300_NUM_GPIO  16
>>>   #define AR9330_NUM_GPIO 16
>>>   #define AR9340_NUM_GPIO 23
>>> -#define AR9462_NUM_GPIO 10
>>> -#define AR9485_NUM_GPIO 12
>>> +#define AR9462_NUM_GPIO 14
>>> +#define AR9485_NUM_GPIO 11
>>>   #define AR9531_NUM_GPIO 18
>>>   #define AR9550_NUM_GPIO 24
>>>   #define AR9561_NUM_GPIO 23
>>> @@ -1139,8 +1139,8 @@ enum {
>>>   #define AR9300_GPIO_MASK0xF4FF
>>>   #define AR9330_GPIO_MASK0xF4FF
>>>   #define AR9340_GPIO_MASK0x000F
>>> -#define AR9462_GPIO_MASK0x03FF
>>> -#define AR9485_GPIO_MASK0x0FFF
>>> +#define AR9462_GPIO_MASK0x3FFF
>>> +#define AR9485_GPIO_MASK0x07FF
>>>   #define AR9531_GPIO_MASK0x000F
>>>   #define AR9550_GPIO_MASK0x000F
>>>   #define AR9561_GPIO_MASK0x000F
>>
>> solves the problem.
>>
>> Tested-by: Sudip Mukherjee 
>
> Done, https://patchwork.kernel.org/patch/9151847/

But the patch 9151847 is different from what Sudip tested above? Why?

And if you modify something _after_ the reporter has tested the patch
clearly document what you changed and why. I do not want find hidden
changes like this, even more so when the patch is going to a 4.7-rc
release.

Sudip, could you also test patch 9151847, please? You can download the
patch from the patchwork link above.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] net: wireless: marvell: libertas: Remove create_workqueue

2016-06-04 Thread Bhaktipriya Shridhar
On Sat, Jun 4, 2016 at 7:59 PM, Kalle Valo  wrote:
>
> $ git log --oneline --no-merges -10

Sure. Will keep that in mind.

Thanks,
Bhaktipriya
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC/RFT 2/5] ath9k: use mac80211 intermediate software queues

2016-06-04 Thread Toke Høiland-Jørgensen
Tim Shepard  writes:

>> Reworked to not require the global variable renaming in ath9k.
>> 
>> Signed-off-by: Toke Høiland-Jørgensen 
>
> Huh.  I wonder why you did that?  Is it really better to call the
> ieee80211_txq a swq and call the ath9k hardware queue a txq?  I
> thought doing the renaming made for more readable and much more
> maintainable code (where searching for text strings produced much
> cleaner results when trying to track down all references).

Well, the immediate reason was that at the time I just spent two weeks
figuring out how ath9k worked and what the different concepts were, and
suddenly they start to mean something different. The txq->hwq renaming
would probably make sense in itself, but suddenly the same variable
(txq) meant something different, which was quite confusing. So I found
it was easier to change your patch to not require the renaming.

A secondary reason was to keep the patch delta as small as possible. I'm
definitely not the right person to make that call, but I found the
global renaming somewhat intrusive.

As for the first point, I think it would be easier if you did not call
the mac80211 queues 'txq' but something else ('swq' like I did, perhaps;
I also considered 'imq' for intermediate queue). This will at least make
it clear at a glance that it is something different than 'txq' was
previously.

> I am grateful to learn that someone has read my patched version of
> ath9k at least enough to do this rework. Any comments on the actual
> work?

Well, it seems to work well enough (haven't noticed the pending_frames
issue, but on the other hand I haven't been looking very hard). However,
it does fell like somewhat of a temporary solution. Having another
intermediate queue in the driver (tid->i_q) and having a side-effect in
ath_tid_has_buffered() seems a bit iffy to me. Wouldn't the 'right' way
to do it be to have ath_tid_has_buffered() ask the mac layer if it has
any frames queued, and then have ath_tx_get_tid_subframe() basically
translate straight to a call to ieee80211_tx_dequeue() (taking into
account the retry queue)? Not sure if that covers all code paths, but
the current approach seems like it has one too many layers of queues?

Haven't given the above a lot of thought, but since you asked... :)

-Toke
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] net: wireless: marvell: libertas: Remove create_workqueue

2016-06-04 Thread Kalle Valo
Bhaktipriya Shridhar  writes:

> alloc_workqueue replaces deprecated create_workqueue().
>
> In if_sdio.c, the workqueue card->workqueue has workitem
> >packet_worker, which is mapped to if_sdio_host_to_card_worker.
> The workitem is involved in sending packets to firmware.
> Forward progress under memory pressure is a requirement here.
>
> In if_spi.c, the workqueue card->workqueue has workitem
> >packet_worker, which is mapped to if_spi_host_to_card_worker.
> The workitem is involved in sending command packets from the host.
> Forward progress under memory pressure is a requirement here.
>
> Dedicated workqueues have been used in both cases since the workitems
> on the workqueues are involved in normal device operation with
> WQ_MEM_RECLAIM set to gurantee forward progress under memory pressure.
> Since there are only a fixed number of work items, explicit concurrency
> limit is unnecessary.
>
> flush_workqueue is unnecessary since destroy_workqueue() itself calls
> drain_workqueue() which flushes repeatedly till the workqueue
> becomes empty. Hence the calls to flush_workqueue() before
> destroy_workqueue() have been dropped.
>
> Signed-off-by: Bhaktipriya Shridhar 

"libertas:" as a prefix is enough, no need to put the full path to the
title. I can fix that this time.

You can actually check yourself what prefix is commonly used in a
particular file or directory:

$ git log --oneline --no-merges -10 drivers/net/wireless/marvell/libertas/
57fbcce37be7 cfg80211: remove enum ieee80211_band
3691ac4a9c95 libertas: fix an error code in probe
143e49458424 libertas: add an cfg80211 interface for powersaving
0b8802dc5f59 libertas: fix ps-mode related removal problems
fada24a54770 libertas: go back to ps mode without commands pending
57954b94cad7 libertas: do not confirm sleep if commands are pending
fae4f9f78ab1 libertas: check whether bus can do more than polling
0a7701b4defc libertas: fix pointer bugs for PS_MODE commands
6d91ff7acc90 libertas: cleanup a variable name
0a38c8e1b592 libertas: check for NULL before use
$
-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [33/54] MAINTAINERS: Add file patterns for wireless device tree bindings

2016-06-04 Thread Kalle Valo
Geert Uytterhoeven  wrote:
> Submitters of device tree binding documentation may forget to CC
> the subsystem maintainer if this is missing.
> 
> Signed-off-by: Geert Uytterhoeven 
> Cc: Kalle Valo 
> Cc: linux-wireless@vger.kernel.org

Thanks, 1 patch applied to wireless-drivers.git:

182fd9eecb28 MAINTAINERS: Add file patterns for wireless device tree bindings

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9130849/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] net: wireless: marvell: libertas: Remove create_workqueue

2016-06-04 Thread Bhaktipriya Shridhar
alloc_workqueue replaces deprecated create_workqueue().

In if_sdio.c, the workqueue card->workqueue has workitem
>packet_worker, which is mapped to if_sdio_host_to_card_worker.
The workitem is involved in sending packets to firmware.
Forward progress under memory pressure is a requirement here.

In if_spi.c, the workqueue card->workqueue has workitem
>packet_worker, which is mapped to if_spi_host_to_card_worker.
The workitem is involved in sending command packets from the host.
Forward progress under memory pressure is a requirement here.

Dedicated workqueues have been used in both cases since the workitems
on the workqueues are involved in normal device operation with
WQ_MEM_RECLAIM set to gurantee forward progress under memory pressure.
Since there are only a fixed number of work items, explicit concurrency
limit is unnecessary.

flush_workqueue is unnecessary since destroy_workqueue() itself calls
drain_workqueue() which flushes repeatedly till the workqueue
becomes empty. Hence the calls to flush_workqueue() before
destroy_workqueue() have been dropped.

Signed-off-by: Bhaktipriya Shridhar 
---
 drivers/net/wireless/marvell/libertas/if_sdio.c | 3 +--
 drivers/net/wireless/marvell/libertas/if_spi.c  | 4 +---
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/marvell/libertas/if_sdio.c 
b/drivers/net/wireless/marvell/libertas/if_sdio.c
index 13eae9f..47f4a14 100644
--- a/drivers/net/wireless/marvell/libertas/if_sdio.c
+++ b/drivers/net/wireless/marvell/libertas/if_sdio.c
@@ -1228,7 +1228,7 @@ static int if_sdio_probe(struct sdio_func *func,
}

spin_lock_init(>lock);
-   card->workqueue = create_workqueue("libertas_sdio");
+   card->workqueue = alloc_workqueue("libertas_sdio", WQ_MEM_RECLAIM, 0);
INIT_WORK(>packet_worker, if_sdio_host_to_card_worker);
init_waitqueue_head(>pwron_waitq);

@@ -1326,7 +1326,6 @@ static void if_sdio_remove(struct sdio_func *func)
lbs_stop_card(card->priv);
lbs_remove_card(card->priv);

-   flush_workqueue(card->workqueue);
destroy_workqueue(card->workqueue);

while (card->packets) {
diff --git a/drivers/net/wireless/marvell/libertas/if_spi.c 
b/drivers/net/wireless/marvell/libertas/if_spi.c
index 82c0796..c3a53cd 100644
--- a/drivers/net/wireless/marvell/libertas/if_spi.c
+++ b/drivers/net/wireless/marvell/libertas/if_spi.c
@@ -1180,7 +1180,7 @@ static int if_spi_probe(struct spi_device *spi)
priv->fw_ready = 1;

/* Initialize interrupt handling stuff. */
-   card->workqueue = create_workqueue("libertas_spi");
+   card->workqueue = alloc_workqueue("libertas_spi", WQ_MEM_RECLAIM, 0);
INIT_WORK(>packet_work, if_spi_host_to_card_worker);
INIT_WORK(>resume_work, if_spi_resume_worker);

@@ -1208,7 +1208,6 @@ static int if_spi_probe(struct spi_device *spi)
 release_irq:
free_irq(spi->irq, card);
 terminate_workqueue:
-   flush_workqueue(card->workqueue);
destroy_workqueue(card->workqueue);
lbs_remove_card(priv); /* will call free_netdev */
 free_card:
@@ -1235,7 +1234,6 @@ static int libertas_spi_remove(struct spi_device *spi)
lbs_remove_card(priv); /* will call free_netdev */

free_irq(spi->irq, card);
-   flush_workqueue(card->workqueue);
destroy_workqueue(card->workqueue);
if (card->pdata->teardown)
card->pdata->teardown(spi);
--
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2] ath10k: Add board data download from target

2016-06-04 Thread Valo, Kalle
Sven Eckelmann  writes:

> The QCA9887 stores its calibration data (board.bin) inside the EEPROM of
> the target. This has to be downloaded manually to allow the device to
> initialize correctly.
>
> Signed-off-by: Sven Eckelmann 

[...]

> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "core.h"
>  #include "mac.h"
> @@ -550,6 +551,34 @@ out:
>   return ret;
>  }
>  
> +static int ath10k_download_cal_eeprom(struct ath10k *ar)
> +{
> + size_t data_len;
> + void *data = NULL;
> + int ret;
> +
> + ret = ath10k_hif_fetch_target_board_data(ar, , _len);
> + if (ret) {
> + ath10k_warn(ar, "failed to read calibration data from EEPROM: 
> %d\n",
> + ret);
> + goto out_free;
> + }

Looking at this again I noticed that we issue this warning even if
EEPROM is not supported, which I think is wrong. I fixed this in the
pending branch, the diff is below.

I also renamed target_board_data to cal_eeprom because, at least to my
understanding, the eeprom actually contains the real calibration data,
not the board data file.

Please review so that I didn't break anything.

https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending=4f79bdf2db7bcfa9c7c093fd423af801b9797c63

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 10a1b620a68b..1e88251ca6d0 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -580,10 +580,11 @@ static int ath10k_download_cal_eeprom(struct ath10k *ar)
void *data = NULL;
int ret;
 
-   ret = ath10k_hif_fetch_target_board_data(ar, , _len);
+   ret = ath10k_hif_fetch_cal_eeprom(ar, , _len);
if (ret) {
-   ath10k_warn(ar, "failed to read calibration data from EEPROM: 
%d\n",
-   ret);
+   if (ret != -EOPNOTSUPP)
+   ath10k_warn(ar, "failed to read calibration data from 
EEPROM: %d\n",
+   ret);
goto out_free;
}
 
diff --git a/drivers/net/wireless/ath/ath10k/hif.h 
b/drivers/net/wireless/ath/ath10k/hif.h
index c18b8c81bde4..b2566b06e1e1 100644
--- a/drivers/net/wireless/ath/ath10k/hif.h
+++ b/drivers/net/wireless/ath/ath10k/hif.h
@@ -88,9 +88,9 @@ struct ath10k_hif_ops {
int (*suspend)(struct ath10k *ar);
int (*resume)(struct ath10k *ar);
 
-   /* fetch board data from target eeprom */
-   int (*fetch_target_board_data)(struct ath10k *ar, void **data,
-  size_t *data_len);
+   /* fetch calibration data from target eeprom */
+   int (*fetch_cal_eeprom)(struct ath10k *ar, void **data,
+   size_t *data_len);
 };
 
 static inline int ath10k_hif_tx_sg(struct ath10k *ar, u8 pipe_id,
@@ -206,14 +206,14 @@ static inline void ath10k_hif_write32(struct ath10k *ar,
ar->hif.ops->write32(ar, address, data);
 }
 
-static inline int ath10k_hif_fetch_target_board_data(struct ath10k *ar,
-void **data,
-size_t *data_len)
+static inline int ath10k_hif_fetch_cal_eeprom(struct ath10k *ar,
+ void **data,
+ size_t *data_len)
 {
-   if (!ar->hif.ops->fetch_target_board_data)
+   if (!ar->hif.ops->fetch_cal_eeprom)
return -EOPNOTSUPP;
 
-   return ar->hif.ops->fetch_target_board_data(ar, data, data_len);
+   return ar->hif.ops->fetch_cal_eeprom(ar, data, data_len);
 }
 
 #endif /* _HIF_H_ */
diff --git a/drivers/net/wireless/ath/ath10k/pci.c 
b/drivers/net/wireless/ath/ath10k/pci.c
index fb53f8846efd..f06dd3941bac 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2678,8 +2678,8 @@ static int ath10k_pci_read_eeprom(struct ath10k *ar, u16 
addr, u8 *out)
return 0;
 }
 
-static int ath10k_pci_fetch_target_board_data(struct ath10k *ar, void **data,
- size_t *data_len)
+static int ath10k_pci_hif_fetch_cal_eeprom(struct ath10k *ar, void **data,
+  size_t *data_len)
 {
u8 *caldata = NULL;
size_t calsize, i;
@@ -2734,7 +2734,7 @@ static const struct ath10k_hif_ops ath10k_pci_hif_ops = {
.suspend= ath10k_pci_hif_suspend,
.resume = ath10k_pci_hif_resume,
 #endif
-   .fetch_target_board_data = ath10k_pci_fetch_target_board_data,
+   .fetch_cal_eeprom   = ath10k_pci_hif_fetch_cal_eeprom,
 };
 
 /*

-- 
Kalle Valo--
To unsubscribe from this list: send the line "unsubscribe 

Re: [PATCH 1/2] ath10k: add QCA9887 chipset support

2016-06-04 Thread Valo, Kalle
Sven Eckelmann  writes:

> Add the hardware name, revision, firmware names and update the pci_id
> table.
>
> QA9887 HW1.0 is supposed to be similar to QCA988X HW2.0 . Details about
> he firmware interface are currently unknown.
>
> Signed-off-by: Sven Eckelmann 

I added the warning we talked about, diff below. Full patch in the
pending branch:

https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending=ed730faad11df99f2aba3b8d78ac5587c3403e69

diff --git a/drivers/net/wireless/ath/ath10k/pci.c 
b/drivers/net/wireless/ath/ath10k/pci.c
index d34c32a075ac..3e8e7ed6faa1 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -3005,6 +3005,7 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
pci_hard_reset = ath10k_pci_qca988x_chip_reset;
break;
case QCA9887_1_0_DEVICE_ID:
+   dev_warn(>dev, "QCA9887 support is still experimental, 
there are likely bugs. You have been warned.\n");
hw_rev = ATH10K_HW_QCA9887;
pci_ps = false;
pci_soft_reset = ath10k_pci_warm_reset;


-- 
Kalle Valo--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] drivers: ssb: Change bare unsigned to unsigned int to suit coding style

2016-06-04 Thread Michael Büsch
On Sat,  4 Jun 2016 12:50:05 +0100
Hugh Sipière  wrote:

> These lines just have unsigned gpio rather than unsigned int gpio.
> I changed it to suit the coding style.
> 
> Signed-off-by: Hugh Sipière 

Acked-by: Michael Buesch 

Please send this to the MIPS tree, because this basically is MIPS-only
code:

MIPS
M:  Ralf Baechle 
L:  linux-m...@linux-mips.org


-- 
Michael


pgprMkyfNGSBd.pgp
Description: OpenPGP digital signature


[PATCH] drivers: ssb: Change bare unsigned to unsigned int to suit coding style

2016-06-04 Thread Hugh Sipière
These lines just have unsigned gpio rather than unsigned int gpio.
I changed it to suit the coding style.

Signed-off-by: Hugh Sipière 
---
 drivers/ssb/driver_gpio.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/ssb/driver_gpio.c b/drivers/ssb/driver_gpio.c
index 180e027..796e220 100644
--- a/drivers/ssb/driver_gpio.c
+++ b/drivers/ssb/driver_gpio.c
@@ -23,7 +23,7 @@
  **/
 
 #if IS_ENABLED(CONFIG_SSB_EMBEDDED)
-static int ssb_gpio_to_irq(struct gpio_chip *chip, unsigned gpio)
+static int ssb_gpio_to_irq(struct gpio_chip *chip, unsigned int gpio)
 {
struct ssb_bus *bus = gpiochip_get_data(chip);
 
@@ -38,14 +38,14 @@ static int ssb_gpio_to_irq(struct gpio_chip *chip, unsigned 
gpio)
  * ChipCommon
  **/
 
-static int ssb_gpio_chipco_get_value(struct gpio_chip *chip, unsigned gpio)
+static int ssb_gpio_chipco_get_value(struct gpio_chip *chip, unsigned int gpio)
 {
struct ssb_bus *bus = gpiochip_get_data(chip);
 
return !!ssb_chipco_gpio_in(>chipco, 1 << gpio);
 }
 
-static void ssb_gpio_chipco_set_value(struct gpio_chip *chip, unsigned gpio,
+static void ssb_gpio_chipco_set_value(struct gpio_chip *chip, unsigned int 
gpio,
  int value)
 {
struct ssb_bus *bus = gpiochip_get_data(chip);
@@ -54,7 +54,7 @@ static void ssb_gpio_chipco_set_value(struct gpio_chip *chip, 
unsigned gpio,
 }
 
 static int ssb_gpio_chipco_direction_input(struct gpio_chip *chip,
-  unsigned gpio)
+  unsigned int gpio)
 {
struct ssb_bus *bus = gpiochip_get_data(chip);
 
@@ -63,7 +63,7 @@ static int ssb_gpio_chipco_direction_input(struct gpio_chip 
*chip,
 }
 
 static int ssb_gpio_chipco_direction_output(struct gpio_chip *chip,
-   unsigned gpio, int value)
+   unsigned int gpio, int value)
 {
struct ssb_bus *bus = gpiochip_get_data(chip);
 
@@ -72,7 +72,7 @@ static int ssb_gpio_chipco_direction_output(struct gpio_chip 
*chip,
return 0;
 }
 
-static int ssb_gpio_chipco_request(struct gpio_chip *chip, unsigned gpio)
+static int ssb_gpio_chipco_request(struct gpio_chip *chip, unsigned int gpio)
 {
struct ssb_bus *bus = gpiochip_get_data(chip);
 
@@ -85,7 +85,7 @@ static int ssb_gpio_chipco_request(struct gpio_chip *chip, 
unsigned gpio)
return 0;
 }
 
-static void ssb_gpio_chipco_free(struct gpio_chip *chip, unsigned gpio)
+static void ssb_gpio_chipco_free(struct gpio_chip *chip, unsigned int gpio)
 {
struct ssb_bus *bus = gpiochip_get_data(chip);
 
@@ -256,14 +256,14 @@ static int ssb_gpio_chipco_init(struct ssb_bus *bus)
 
 #ifdef CONFIG_SSB_DRIVER_EXTIF
 
-static int ssb_gpio_extif_get_value(struct gpio_chip *chip, unsigned gpio)
+static int ssb_gpio_extif_get_value(struct gpio_chip *chip, unsigned int gpio)
 {
struct ssb_bus *bus = gpiochip_get_data(chip);
 
return !!ssb_extif_gpio_in(>extif, 1 << gpio);
 }
 
-static void ssb_gpio_extif_set_value(struct gpio_chip *chip, unsigned gpio,
+static void ssb_gpio_extif_set_value(struct gpio_chip *chip, unsigned int gpio,
 int value)
 {
struct ssb_bus *bus = gpiochip_get_data(chip);
@@ -272,7 +272,7 @@ static void ssb_gpio_extif_set_value(struct gpio_chip 
*chip, unsigned gpio,
 }
 
 static int ssb_gpio_extif_direction_input(struct gpio_chip *chip,
- unsigned gpio)
+ unsigned int gpio)
 {
struct ssb_bus *bus = gpiochip_get_data(chip);
 
@@ -281,7 +281,7 @@ static int ssb_gpio_extif_direction_input(struct gpio_chip 
*chip,
 }
 
 static int ssb_gpio_extif_direction_output(struct gpio_chip *chip,
-  unsigned gpio, int value)
+  unsigned int gpio, int value)
 {
struct ssb_bus *bus = gpiochip_get_data(chip);
 
-- 
2.5.5

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] drivers: ssb: Fix comments to suit coding style

2016-06-04 Thread Michael Büsch
On Sat,  4 Jun 2016 12:32:13 +0100
Hugh Sipière  wrote:

> I changed it so that these two comments do not end on a line with text.
> 
> Signed-off-by: Hugh Sipière 
> ---
>  drivers/ssb/driver_gpio.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/ssb/driver_gpio.c b/drivers/ssb/driver_gpio.c
> index 180e027..f2435f3 100644
> --- a/drivers/ssb/driver_gpio.c
> +++ b/drivers/ssb/driver_gpio.c
> @@ -231,7 +231,8 @@ static int ssb_gpio_chipco_init(struct ssb_bus *bus)
>   chip->ngpio = 16;
>   /* There is just one SoC in one device and its GPIO addresses should be
>* deterministic to address them more easily. The other buses could get
> -  * a random base number. */
> +  * a random base number.
> +  */
>   if (bus->bustype == SSB_BUSTYPE_SSB)
>   chip->base  = 0;
>   else
> @@ -424,7 +425,8 @@ static int ssb_gpio_extif_init(struct ssb_bus *bus)
>   chip->ngpio = 5;
>   /* There is just one SoC in one device and its GPIO addresses should be
>* deterministic to address them more easily. The other buses could get
> -  * a random base number. */
> +  * a random base number.
> +  */
>   if (bus->bustype == SSB_BUSTYPE_SSB)
>   chip->base  = 0;
>   else


What's the benefit from this change?
Will the next person submit a patch to remove wasted lines that just
contain a */?


-- 
Michael


pgpt0LkZKe3iZ.pgp
Description: OpenPGP digital signature


[PATCH] drivers: ssb: Fix comments to suit coding style

2016-06-04 Thread Hugh Sipière
I changed it so that these two comments do not end on a line with text.

Signed-off-by: Hugh Sipière 
---
 drivers/ssb/driver_gpio.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/ssb/driver_gpio.c b/drivers/ssb/driver_gpio.c
index 180e027..f2435f3 100644
--- a/drivers/ssb/driver_gpio.c
+++ b/drivers/ssb/driver_gpio.c
@@ -231,7 +231,8 @@ static int ssb_gpio_chipco_init(struct ssb_bus *bus)
chip->ngpio = 16;
/* There is just one SoC in one device and its GPIO addresses should be
 * deterministic to address them more easily. The other buses could get
-* a random base number. */
+* a random base number.
+*/
if (bus->bustype == SSB_BUSTYPE_SSB)
chip->base  = 0;
else
@@ -424,7 +425,8 @@ static int ssb_gpio_extif_init(struct ssb_bus *bus)
chip->ngpio = 5;
/* There is just one SoC in one device and its GPIO addresses should be
 * deterministic to address them more easily. The other buses could get
-* a random base number. */
+* a random base number.
+*/
if (bus->bustype == SSB_BUSTYPE_SSB)
chip->base  = 0;
else
-- 
2.5.5

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Drivers: ssb: Fix bare unsigned and changed to trailing comments

2016-06-04 Thread Julian Calaby
Hi Hugh,

On Sat, Jun 4, 2016 at 10:39 AM, Hugh Sipiere  wrote:
> I changed drivers/ssb/driver_gpio.c to better fit the coding style.
> I changed unsigned to unsigned int
> Two comments were changed to not end on a line with the text.
>
> Signed-off-by: Hugh Sipiere 

You should separate the changes into two patches, one to change
"unsigned" to "unsigned int" and one to fix the comments.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/2] b43: Remove unused phy_a code

2016-06-04 Thread Michael Büsch
On Fri,  3 Jun 2016 21:11:51 -0700
Guenter Roeck  wrote:

> +static void __b43_phy_initg(struct b43_wldev *dev)
> +{
> + struct b43_phy *phy = >phy;
> +
> + might_sleep();
> +
> + if (phy->rev >= 6) {
> + if (b43_phy_read(dev, B43_PHY_ENCORE) & B43_PHY_ENCORE_EN)
> + b43_phy_set(dev, B43_PHY_ENCORE, 0x0010);
> + else
> + b43_phy_mask(dev, B43_PHY_ENCORE, ~0x1010);
> + }
> +
> + b43_wa_all(dev);
> +
> + if (dev->dev->bus_sprom->boardflags_lo & B43_BFL_PACTRL)
> + b43_phy_maskset(dev, B43_PHY_OFDM(0x6E), 0xE000, 0x3CF);
> +}
> +
>  static void b43_phy_initg(struct b43_wldev *dev)
>  {
>   struct b43_phy *phy = >phy;
> @@ -1999,7 +2019,7 @@ static void b43_phy_initg(struct b43_wldev *dev)
>   b43_phy_initb6(dev);
>  
>   if (phy->rev >= 2 || phy->gmode)
> - b43_phy_inita(dev);
> + __b43_phy_initg(dev);

This actually is correctly called inita(), because there are A-phy parts
in the G-phy.
So I wasn't 100% correct saying that _all_ a-phy code is unused.
I'm Ok with moving that into the g-phy file though. But don't rename it.


-- 
Michael


pgp1mgBgFViAO.pgp
Description: OpenPGP digital signature