Re: [PATCH] rt2800usb: Add Epson wireless adapter device-id

[Kalle Valo]

Tom Gaudasiński  writes:

> Make Epson WN7512BEP work by adding its device-id to rt2800usb. Device
> contains a Ralink RT3071L, registers as vendor Accton/Arcadyan.
>
> Signed-off-by: Tom Gaudasinski 

The prefix should be "rt2x00:".

> --- linux/drivers/net/wireless/ralink/rt2x00/rt2800usb.c.orig   
> 2017-05-17 19:49:44.893895819 +1000
> +++ linux/drivers/net/wireless/ralink/rt2x00/rt2800usb.c2017-05-17
> 19:49:32.90692 +1000
> @@ -1156,6 +1156,8 @@ static struct usb_device_id rt2800usb_de
>  { USB_DEVICE(0x2001, 0x3c17) },
>  /* Panasonic */
>  { USB_DEVICE(0x083a, 0xb511) },
> +/* Accton/Arcadyan/Epson */
> +{ USB_DEVICE(0x083a, 0xb512) },

The patch looks to be corrupted, didn't it test it though. Better use
'git send-email' to submit patches.

-- 
Kalle Valo

Re: [PATCH 1/2] wcn36xx: Pass used skb to ieee80211_tx_status()

[Bjorn Andersson]

On Wed 17 May 06:14 PDT 2017, Johannes Berg wrote:

> On Thu, 2017-05-04 at 13:13 +, Kalle Valo wrote:
> > 
> > > > This code intentionally checked if TX status was requested, and
> > > > if not then it doesn't go to the effort of building it.
> > > > 
> > > 
> > > What I'm finding puzzling is the fact that the only caller of
> > > ieee80211_led_tx() is ieee80211_tx_status() and it seems like
> > > drivers, such as ath10k, call this for each packet handled - but
> > > I'm likely missing something.
> 
> Yes, many drivers do call it for each packet, and as such, this
> deficiency was never noted.
> 
> > > > As it is with your patch, it'll go and report the TX status
> > > > without any
> > > > TX status information - which is handled in
> > > > wcn36xx_dxe_tx_ack_ind()
> > > > for those frames needing it.
> > > > 
> > > 
> > > Right, it doesn't sound desired. However, during normal operation
> > > I'm not seeing IEEE80211_TX_CTL_REQ_TX_STATUS being set and as such
> > > ieee80211_led_tx() is never called.
> > 
> > So what's the conclusion? How do we get leds working?
> 
> Well, frankly, I never thought the TX LED was a super good idea - but
> it had been supported by the original code IIRC, so never removed. Some
> people like frantic blinking I guess ;-)
> 

It seems very important to a lot of people...


But if ieee80211_free_txskb() is the counterpart of
ieee80211_tx_status() then we should be able to push the
ieee80211_led_tx() call down into ieee80211_report_used_skb() and handle
both cases.

The ieee80211_free_txskb() seems to be used in various cases where we
discard skbs, but perhaps this is not an issue in reality.

> But I think the problem also applies to the throughput trigger thing,
> so perhaps we need to stick some LED feedback calls into other places,
> like _noskb() or provide an extra way to do it?
> 

Looking around it seems that we either have a call to free_txskb() or
one of the tx_status(); where the _noskb() would need some special
handling. Are there others or would it be reasonable to add a call in
this one "special" case?

Regards,
Bjorn

Re: [net-realtek-btcoexist] question about identical code for different branches

[Larry Finger]

On 05/17/2017 04:52 PM, Gustavo A. R. Silva wrote:


Hello everybody,

While looking into Coverity ID 1362263 I ran into the following piece of code at 
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c:1000:


1000void exhalbtc_set_ant_num(struct rtl_priv *rtlpriv, u8 type, u8 ant_num)
1001{
1002if (BT_COEX_ANT_TYPE_PG == type) {
1003gl_bt_coexist.board_info.pg_ant_num = ant_num;
1004gl_bt_coexist.board_info.btdm_ant_num = ant_num;
1005/* The antenna position:
1006 * Main (default) or Aux for pgAntNum=2 && btdmAntNum =1.
1007 * The antenna position should be determined by
1008 * auto-detect mechanism.
1009 * The following is assumed to main,
1010 * and those must be modified
1011 * if y auto-detect mechanism is ready
1012 */
1013if ((gl_bt_coexist.board_info.pg_ant_num == 2) &&
1014(gl_bt_coexist.board_info.btdm_ant_num == 1))
1015gl_bt_coexist.board_info.btdm_ant_pos =
1016   
BTC_ANTENNA_AT_MAIN_PORT;

1017else
1018gl_bt_coexist.board_info.btdm_ant_pos =
1019   
BTC_ANTENNA_AT_MAIN_PORT;

1020} else if (BT_COEX_ANT_TYPE_ANTDIV == type) {
1021gl_bt_coexist.board_info.btdm_ant_num = ant_num;
1022gl_bt_coexist.board_info.btdm_ant_pos =
1023   
BTC_ANTENNA_AT_MAIN_PORT;

1024} else if (type == BT_COEX_ANT_TYPE_DETECTED) {
1025gl_bt_coexist.board_info.btdm_ant_num = ant_num;
1026if (rtlpriv->cfg->mod_params->ant_sel == 1)
1027gl_bt_coexist.board_info.btdm_ant_pos =
1028BTC_ANTENNA_AT_AUX_PORT;
1029else
1030gl_bt_coexist.board_info.btdm_ant_pos =
1031BTC_ANTENNA_AT_MAIN_PORT;
1032}
1033}

The issue is that lines of code 1015-1016 and 1018-1019 are identical for 
different branches.


My question here is if one of those assignments should be modified, or the 
entire _if_ statement replaced and the function refactored?


I'd really appreciate any comment on this.

Thank you!
--
Gustavo A. R. Silva


Gustavo,

Thanks for the notification. I will discuss with Realtek as to the proper fix.

Larry

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

[Bjorn Andersson]

On Wed 17 May 05:53 PDT 2017, Pali Roh?r wrote:

> On Wednesday 17 May 2017 14:06:06 Johannes Berg wrote:
> > On Tue, 2017-05-16 at 01:13 +0200, Luis R. Rodriguez wrote:
> > > > > Now for N900 case there is a similar scenario
> > > > > alhtough it has additional requirement to go to user-space due to
> > > > > need to use a proprietary library to obtain the NVS calibration
> > > > > data. My thought: Why should firmware_class care?
> > > 
> > > Agreed.
> > 
> > In fact, why should the *driver* care either? IOW - why should
> > "request_firmware_prefer_user()" even exist?
> 
> There are default/example NVS data, which are stored in /lib/firmware
> and installed by linux-firmware package. Those example calibration data
> should not be used for real usage, but Pavel told us that on N900 they
> are enough for working WIFI connection. They does not contain valid MAC
> address, so kernel should generate some (random?).
> 
> So kernel driver should get NVS calibration data from userspace (which
> know how where to get or how to prepare them) and in case userspace do
> not have it, then we can try fallback to those example data (as people
> reported us they can be useful instead of non-working WIFI).
> 

We're going to see a similar case with the Qualcomm DB410c WiFi soon,
where there is default calibration for the chip (wcn3620) but specific
calibration data for the particular board or product using this chip.

As with your case we expect to have a "generic" calibration file
integrated in linux-firmware, but providing means to supporting
device-specific calibration is probably going to be requested shortly.


We have however altered the reference design of picking the MAC address
from the calibration data and have the bootloader pass it via DT - so
our calibration data doesn't need to be specific to each unit.

Regards,
Bjorn

[net-realtek-btcoexist] question about identical code for different branches

[Gustavo A. R. Silva]

Hello everybody,

While looking into Coverity ID 1362263 I ran into the following piece  
of code at  
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c:1000:


1000void exhalbtc_set_ant_num(struct rtl_priv *rtlpriv, u8 type, u8 ant_num)
1001{
1002if (BT_COEX_ANT_TYPE_PG == type) {
1003gl_bt_coexist.board_info.pg_ant_num = ant_num;
1004gl_bt_coexist.board_info.btdm_ant_num = ant_num;
1005/* The antenna position:
1006 * Main (default) or Aux for pgAntNum=2 && btdmAntNum =1.
1007 * The antenna position should be determined by
1008 * auto-detect mechanism.
1009 * The following is assumed to main,
1010 * and those must be modified
1011 * if y auto-detect mechanism is ready
1012 */
1013if ((gl_bt_coexist.board_info.pg_ant_num == 2) &&
1014(gl_bt_coexist.board_info.btdm_ant_num == 1))
1015gl_bt_coexist.board_info.btdm_ant_pos =
1016
BTC_ANTENNA_AT_MAIN_PORT;

1017else
1018gl_bt_coexist.board_info.btdm_ant_pos =
1019
BTC_ANTENNA_AT_MAIN_PORT;

1020} else if (BT_COEX_ANT_TYPE_ANTDIV == type) {
1021gl_bt_coexist.board_info.btdm_ant_num = ant_num;
1022gl_bt_coexist.board_info.btdm_ant_pos =
1023
BTC_ANTENNA_AT_MAIN_PORT;

1024} else if (type == BT_COEX_ANT_TYPE_DETECTED) {
1025gl_bt_coexist.board_info.btdm_ant_num = ant_num;
1026if (rtlpriv->cfg->mod_params->ant_sel == 1)
1027gl_bt_coexist.board_info.btdm_ant_pos =
1028BTC_ANTENNA_AT_AUX_PORT;
1029else
1030gl_bt_coexist.board_info.btdm_ant_pos =
1031BTC_ANTENNA_AT_MAIN_PORT;
1032}
1033}

The issue is that lines of code 1015-1016 and 1018-1019 are identical  
for different branches.


My question here is if one of those assignments should be modified, or  
the entire _if_ statement replaced and the function refactored?


I'd really appreciate any comment on this.

Thank you!
--
Gustavo A. R. Silva

Re: [PATCH] ssb: Delete an error message for a failed memory allocation in ssb_devices_register()

[Michael Büsch]

On Wed, 17 May 2017 18:22:49 +0200
SF Markus Elfring  wrote:

> From: Markus Elfring 
> Date: Wed, 17 May 2017 18:12:16 +0200
> 
> Omit an extra message for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Link: 
> http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
> Signed-off-by: Markus Elfring 
> ---
>  drivers/ssb/main.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c
> index d1a750760cf3..65420a9f0e82 100644
> --- a/drivers/ssb/main.c
> +++ b/drivers/ssb/main.c
> @@ -480,7 +480,6 @@ static int ssb_devices_register(struct ssb_bus *bus)
>  
>   devwrap = kzalloc(sizeof(*devwrap), GFP_KERNEL);
>   if (!devwrap) {
> - ssb_err("Could not allocate device\n");
>   err = -ENOMEM;
>   goto error;
>   }


This looks good.

Acked-by: Michael Büsch 


-- 
Michael


pgpFfsUCp_TBq.pgp
Description: OpenPGP digital signature

[PATCH] staging: wilc1000: Delete an error message for a failed memory allocation in Handle_Key()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 17 May 2017 22:26:07 +0200

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Link: 
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring 
---
 drivers/staging/wilc1000/host_interface.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index c3a8af081880..17a31bbd3665 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1688,7 +1688,6 @@ static int Handle_Key(struct wilc_vif *vif,
} else if (pstrHostIFkeyAttr->action & ADDKEY) {
pu8keybuf = kmalloc(PTK_KEY_MSG_LEN, GFP_KERNEL);
if (!pu8keybuf) {
-   netdev_err(vif->ndev, "No buffer send PTK\n");
ret = -ENOMEM;
goto _WPAPtk_end_case_;
}
-- 
2.13.0

Re: 'iw events' stops receiving events after a while on 4.9 + hacks

[Bastian Bittorf]

* Johannes Berg  [17.05.2017 20:18]:
> On Wed, 2017-05-17 at 12:08 +0200, Bastian Bittorf wrote:
> > * Ben Greear  [17.05.2017 11:51]:

[...]

> > > kernels, but when testing on 4.9 overnight, I notice that 'iw
> > > events' is not showing any input.  'strace' shows
> > > that it is waiting on recvmsg.  If I start a second 'iw events'
> > > then it will get
> > > wifi events as expected.
> > 
> > me too, also seen on 4.4 - i'am happy for debug ideas.
> 
> I've never seen this.
> 
> Does it happen when it's very long-running? Or when there are lots of
> events?

only a couple of hours. hard to say which is the culprit. here
i run it like:

#!/bin/sh
iw event | while read -r LINE; do
 case "$LINE" in
  *': new station '*) ... ;;
  *': del station '*) ... ;;
 esac
done


The script marks new stations with "touch /tmp/$mac"
and removes this file during 'del station'.

What is interesting: i can recognize, that sometimes and
somehow i have stations in 'iw dev wlanX station dump' which
the script has not seen. When debugging this, the script
does not get any new events. A new started 'iw event' can
see further events without problems.

Hard to say where the error happens. I'am on busybox here.

bye, Bastian

[PATCH] ssb: Delete an error message for a failed memory allocation in ssb_devices_register()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 17 May 2017 18:12:16 +0200

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Link: 
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring 
---
 drivers/ssb/main.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c
index d1a750760cf3..65420a9f0e82 100644
--- a/drivers/ssb/main.c
+++ b/drivers/ssb/main.c
@@ -480,7 +480,6 @@ static int ssb_devices_register(struct ssb_bus *bus)
 
devwrap = kzalloc(sizeof(*devwrap), GFP_KERNEL);
if (!devwrap) {
-   ssb_err("Could not allocate device\n");
err = -ENOMEM;
goto error;
}
-- 
2.13.0

Re: 'iw events' stops receiving events after a while on 4.9 + hacks

[Ben Greear]

On 05/17/2017 06:30 AM, Johannes Berg wrote:

On Wed, 2017-05-17 at 12:08 +0200, Bastian Bittorf wrote:

* Ben Greear  [17.05.2017 11:51]:

I have been keeping an 'iw events' program running with a perl
script gathering its
output and post-processing it.  This has been working for several
years on 4.7 and earlier
kernels, but when testing on 4.9 overnight, I notice that 'iw
events' is not showing any input.  'strace' shows
that it is waiting on recvmsg.  If I start a second 'iw events'
then it will get
wifi events as expected.


me too, also seen on 4.4 - i'am happy for debug ideas.


I've never seen this.

Does it happen when it's very long-running? Or when there are lots of
events?

Perhaps something in the socket buffer accounting is going wrong, so
that it's slowly decreasing to 0?


I saw it exactly once so far, and it happened overnight,
but we have not been doing a lot of work with the 4.9 kernel until recently.

I don't think there were many messages on this system, and certainly
others have run much longer on systems that should be generating many more
events without trouble.

Is there any way to dump out the socket information if we reproduce
the problem?

Thanks,
Ben

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

[PATCH v2 03/10] rt2x00: convert rt2x00_rf_read return type

[Arnd Bergmann]

This is a semi-automated conversion to change rt2x00_rf_read()
to return the register contents instead of passing them by value,
resulting in much better object code. The majority of the patch
was done using:

sed -i 's:\(\(.*, .*\), &\(.*\));:\2 = \1);:' \
drivers/net/wireless/ralink/rt2x00/rt*

Signed-off-by: Arnd Bergmann 
---
 drivers/net/wireless/ralink/rt2x00/rt2400pci.c |  2 +-
 drivers/net/wireless/ralink/rt2x00/rt2500pci.c |  4 ++--
 drivers/net/wireless/ralink/rt2x00/rt2500usb.c |  4 ++--
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c |  2 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00.h| 11 ++-
 drivers/net/wireless/ralink/rt2x00/rt61pci.c   | 10 +-
 drivers/net/wireless/ralink/rt2x00/rt73usb.c   | 10 +-
 7 files changed, 18 insertions(+), 25 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c 
b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
index 3ba9a1674e1d..d41832292db2 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
@@ -199,7 +199,7 @@ static const struct rt2x00debug rt2400pci_rt2x00debug = {
.word_count = BBP_SIZE / sizeof(u8),
},
.rf = {
-   .read   = _rt2x00_rf_read,
+   .read   = rt2x00_rf_read,
.write  = rt2400pci_rf_write,
.word_base  = RF_BASE,
.word_size  = sizeof(u32),
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2500pci.c 
b/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
index d9b061b73e83..232feba0773f 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
@@ -199,7 +199,7 @@ static const struct rt2x00debug rt2500pci_rt2x00debug = {
.word_count = BBP_SIZE / sizeof(u8),
},
.rf = {
-   .read   = _rt2x00_rf_read,
+   .read   = rt2x00_rf_read,
.write  = rt2500pci_rf_write,
.word_base  = RF_BASE,
.word_size  = sizeof(u32),
@@ -556,7 +556,7 @@ static void rt2500pci_config_txpower(struct rt2x00_dev 
*rt2x00dev,
 {
u32 rf3;
 
-   rt2x00_rf_read(rt2x00dev, 3, );
+   rf3 = rt2x00_rf_read(rt2x00dev, 3);
rt2x00_set_field32(, RF3_TXPOWER, TXPOWER_TO_DEV(txpower));
rt2500pci_rf_write(rt2x00dev, 3, rf3);
 }
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2500usb.c 
b/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
index 5bd160f732de..9cff9ddafb72 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
@@ -268,7 +268,7 @@ static const struct rt2x00debug rt2500usb_rt2x00debug = {
.word_count = BBP_SIZE / sizeof(u8),
},
.rf = {
-   .read   = _rt2x00_rf_read,
+   .read   = rt2x00_rf_read,
.write  = rt2500usb_rf_write,
.word_base  = RF_BASE,
.word_size  = sizeof(u32),
@@ -639,7 +639,7 @@ static void rt2500usb_config_txpower(struct rt2x00_dev 
*rt2x00dev,
 {
u32 rf3;
 
-   rt2x00_rf_read(rt2x00dev, 3, );
+   rf3 = rt2x00_rf_read(rt2x00dev, 3);
rt2x00_set_field32(, RF3_TXPOWER, TXPOWER_TO_DEV(txpower));
rt2500usb_rf_write(rt2x00dev, 3, rf3);
 }
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c 
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 9b8c19dcdb2c..fef53d6a888a 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -1265,7 +1265,7 @@ const struct rt2x00debug rt2800_rt2x00debug = {
.word_count = BBP_SIZE / sizeof(u8),
},
.rf = {
-   .read   = _rt2x00_rf_read,
+   .read   = rt2x00_rf_read,
.write  = rt2800_rf_write,
.word_base  = RF_BASE,
.word_size  = sizeof(u32),
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00.h 
b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
index f2ae33bf2ef2..36791f7ae2ce 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
@@ -1049,15 +1049,8 @@ struct rt2x00_bar_list_entry {
  * Generic RF access.
  * The RF is being accessed by word index.
  */
-static inline void rt2x00_rf_read(struct rt2x00_dev *rt2x00dev,
- const unsigned int word, u32 *data)
-{
-   BUG_ON(word < 1 || word > rt2x00dev->ops->rf_size / sizeof(u32));
-   *data = rt2x00dev->rf[word - 1];
-}
-
-static inline u32 _rt2x00_rf_read(struct rt2x00_dev *rt2x00dev,
- const unsigned int word)
+static inline u32 rt2x00_rf_read(struct rt2x00_dev *rt2x00dev,
+const unsigned int 

[PATCH v2 02/10] rt2x00: convert rt2800_rfcsr_read return type

[Arnd Bergmann]

With CONFIG_KASAN enabled and gcc-7, we get a warning about rather high
stack usage (with a private patch set I have to turn on this warning,
which I intend to get into the next kernel release):

wireless/ralink/rt2x00/rt2800lib.c: In function 'rt2800_bw_filter_calibration':
wireless/ralink/rt2x00/rt2800lib.c:7990:1: error: the frame size of 2144 bytes 
is larger than 1536 bytes [-Werror=frame-larger-than=]

The problem is that KASAN inserts a redzone around each local variable
that gets passed by reference, and the newly added function has a lot
of them.

This is a semi-automated conversion to change rt2800_rfcsr_read to return
the register contents instead of passing them by value, resulting in
much better object code. The majority of the patch was done using:

sed -i 's:\(rt2800_rfcsr_read(.*, .*\), &\(.*\));:\2 = \1);:' \
-i 's:\(rt2800_rfcsr_read_bank(.*, .*\), &\(.*\));:\2 = \1);:' \
drivers/net/wireless/ralink/rt2x00/rt2800lib.c

Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
Signed-off-by: Arnd Bergmann 
---
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 322 -
 1 file changed, 158 insertions(+), 164 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c 
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 87cfc135e564..9b8c19dcdb2c 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -203,10 +203,11 @@ static void rt2800_rfcsr_write_dccal(struct rt2x00_dev 
*rt2x00dev,
rt2800_rfcsr_write_bank(rt2x00dev, 7, reg, value);
 }
 
-static void rt2800_rfcsr_read(struct rt2x00_dev *rt2x00dev,
- const unsigned int word, u8 *value)
+static u8 rt2800_rfcsr_read(struct rt2x00_dev *rt2x00dev,
+   const unsigned int word)
 {
u32 reg;
+   u8 value;
 
mutex_lock(>csr_mutex);
 
@@ -232,7 +233,7 @@ static void rt2800_rfcsr_read(struct rt2x00_dev *rt2x00dev,
WAIT_FOR_RFCSR_MT7620(rt2x00dev, );
}
 
-   *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620);
+   value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620);
break;
 
default:
@@ -247,17 +248,19 @@ static void rt2800_rfcsr_read(struct rt2x00_dev 
*rt2x00dev,
WAIT_FOR_RFCSR(rt2x00dev, );
}
 
-   *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
+   value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
break;
}
 
mutex_unlock(>csr_mutex);
+
+   return value;
 }
 
-static void rt2800_rfcsr_read_bank(struct rt2x00_dev *rt2x00dev, const u8 bank,
-  const unsigned int reg, u8 *value)
+static u8 rt2800_rfcsr_read_bank(struct rt2x00_dev *rt2x00dev, const u8 bank,
+const unsigned int reg)
 {
-   rt2800_rfcsr_read(rt2x00dev, (reg | (bank << 6)), value);
+   return rt2800_rfcsr_read(rt2x00dev, (reg | (bank << 6)));
 }
 
 static void rt2800_rf_write(struct rt2x00_dev *rt2x00dev,
@@ -1234,15 +1237,6 @@ static u8 _rt2800_bbp_read(struct rt2x00_dev *rt2x00dev, 
const unsigned int word
return value;
 }
 
-static u8 _rt2800_rfcsr_read(struct rt2x00_dev *rt2x00dev, const unsigned int 
word)
-{
-   u8 value;
-
-   rt2800_rfcsr_read(rt2x00dev, word, );
-
-   return value;
-}
-
 const struct rt2x00debug rt2800_rt2x00debug = {
.owner  = THIS_MODULE,
.csr= {
@@ -1278,7 +1272,7 @@ const struct rt2x00debug rt2800_rt2x00debug = {
.word_count = RF_SIZE / sizeof(u32),
},
.rfcsr  = {
-   .read   = _rt2800_rfcsr_read,
+   .read   = rt2800_rfcsr_read,
.write  = rt2800_rfcsr_write,
.word_base  = RFCSR_BASE,
.word_size  = sizeof(u8),
@@ -2090,7 +2084,7 @@ static void rt2800_freq_cal_mode1(struct rt2x00_dev 
*rt2x00dev)
freq_offset = rt2x00_get_field8(rt2x00dev->freq_offset, RFCSR17_CODE);
freq_offset = min_t(u8, freq_offset, FREQ_OFFSET_BOUND);
 
-   rt2800_rfcsr_read(rt2x00dev, 17, );
+   rfcsr = rt2800_rfcsr_read(rt2x00dev, 17);
prev_rfcsr = rfcsr;
 
rt2x00_set_field8(, RFCSR17_CODE, freq_offset);
@@ -2192,23 +2186,23 @@ static void rt2800_config_channel_rf3xxx(struct 
rt2x00_dev *rt2x00dev,
 
rt2800_rfcsr_write(rt2x00dev, 2, rf->rf1);
 
-   rt2800_rfcsr_read(rt2x00dev, 3, );
+   rfcsr = rt2800_rfcsr_read(rt2x00dev, 3);
rt2x00_set_field8(, RFCSR3_K, rf->rf3);
rt2800_rfcsr_write(rt2x00dev, 3, rfcsr);
 
-   rt2800_rfcsr_read(rt2x00dev, 6, );
+   rfcsr = rt2800_rfcsr_read(rt2x00dev, 6);
rt2x00_set_field8(, RFCSR6_R1, rf->rf2);
rt2800_rfcsr_write(rt2x00dev, 6, rfcsr);
 
-   rt2800_rfcsr_read(rt2x00dev, 12, );
+   rfcsr = 

[PATCH v2 10/10] rt2x00: convert rt2x00_desc_read return type

[Arnd Bergmann]

This is a semi-automated conversion to change rt2x00_desc_read to return
the register contents instead of passing them by value, resulting in
much better object code. The majority of the patch was done using:

sed -i 's:\(\(.*, .*\), &\(.*\));:\2 = \1);:' \
-i 's:\(\<_rt2x00_desc_read\>(.*, .*\), &\(.*\));:\2 = \1);:' \
drivers/net/wireless/ralink/rt2x00/rt*

Signed-off-by: Arnd Bergmann 
---
 drivers/net/wireless/ralink/rt2x00/rt2400pci.c   | 32 +++---
 drivers/net/wireless/ralink/rt2x00/rt2500pci.c   | 26 +-
 drivers/net/wireless/ralink/rt2x00/rt2500usb.c   | 14 +-
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c   | 12 -
 drivers/net/wireless/ralink/rt2x00/rt2800mmio.c  | 14 +-
 drivers/net/wireless/ralink/rt2x00/rt2800usb.c   |  8 +++---
 drivers/net/wireless/ralink/rt2x00/rt2x00queue.h | 12 +++--
 drivers/net/wireless/ralink/rt2x00/rt61pci.c | 34 
 drivers/net/wireless/ralink/rt2x00/rt73usb.c | 18 ++---
 9 files changed, 83 insertions(+), 87 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c 
b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
index 73b919838a61..0bc8b0249c57 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
@@ -728,11 +728,11 @@ static bool rt2400pci_get_entry_state(struct queue_entry 
*entry)
u32 word;
 
if (entry->queue->qid == QID_RX) {
-   rt2x00_desc_read(entry_priv->desc, 0, );
+   word = rt2x00_desc_read(entry_priv->desc, 0);
 
return rt2x00_get_field32(word, RXD_W0_OWNER_NIC);
} else {
-   rt2x00_desc_read(entry_priv->desc, 0, );
+   word = rt2x00_desc_read(entry_priv->desc, 0);
 
return (rt2x00_get_field32(word, TXD_W0_OWNER_NIC) ||
rt2x00_get_field32(word, TXD_W0_VALID));
@@ -746,19 +746,19 @@ static void rt2400pci_clear_entry(struct queue_entry 
*entry)
u32 word;
 
if (entry->queue->qid == QID_RX) {
-   rt2x00_desc_read(entry_priv->desc, 2, );
+   word = rt2x00_desc_read(entry_priv->desc, 2);
rt2x00_set_field32(, RXD_W2_BUFFER_LENGTH, 
entry->skb->len);
rt2x00_desc_write(entry_priv->desc, 2, word);
 
-   rt2x00_desc_read(entry_priv->desc, 1, );
+   word = rt2x00_desc_read(entry_priv->desc, 1);
rt2x00_set_field32(, RXD_W1_BUFFER_ADDRESS, 
skbdesc->skb_dma);
rt2x00_desc_write(entry_priv->desc, 1, word);
 
-   rt2x00_desc_read(entry_priv->desc, 0, );
+   word = rt2x00_desc_read(entry_priv->desc, 0);
rt2x00_set_field32(, RXD_W0_OWNER_NIC, 1);
rt2x00_desc_write(entry_priv->desc, 0, word);
} else {
-   rt2x00_desc_read(entry_priv->desc, 0, );
+   word = rt2x00_desc_read(entry_priv->desc, 0);
rt2x00_set_field32(, TXD_W0_VALID, 0);
rt2x00_set_field32(, TXD_W0_OWNER_NIC, 0);
rt2x00_desc_write(entry_priv->desc, 0, word);
@@ -1113,16 +1113,16 @@ static void rt2400pci_write_tx_desc(struct queue_entry 
*entry,
/*
 * Start writing the descriptor words.
 */
-   rt2x00_desc_read(txd, 1, );
+   word = rt2x00_desc_read(txd, 1);
rt2x00_set_field32(, TXD_W1_BUFFER_ADDRESS, skbdesc->skb_dma);
rt2x00_desc_write(txd, 1, word);
 
-   rt2x00_desc_read(txd, 2, );
+   word = rt2x00_desc_read(txd, 2);
rt2x00_set_field32(, TXD_W2_BUFFER_LENGTH, txdesc->length);
rt2x00_set_field32(, TXD_W2_DATABYTE_COUNT, txdesc->length);
rt2x00_desc_write(txd, 2, word);
 
-   rt2x00_desc_read(txd, 3, );
+   word = rt2x00_desc_read(txd, 3);
rt2x00_set_field32(, TXD_W3_PLCP_SIGNAL, txdesc->u.plcp.signal);
rt2x00_set_field32(, TXD_W3_PLCP_SIGNAL_REGNUM, 5);
rt2x00_set_field32(, TXD_W3_PLCP_SIGNAL_BUSY, 1);
@@ -1131,7 +1131,7 @@ static void rt2400pci_write_tx_desc(struct queue_entry 
*entry,
rt2x00_set_field32(, TXD_W3_PLCP_SERVICE_BUSY, 1);
rt2x00_desc_write(txd, 3, word);
 
-   rt2x00_desc_read(txd, 4, );
+   word = rt2x00_desc_read(txd, 4);
rt2x00_set_field32(, TXD_W4_PLCP_LENGTH_LOW,
   txdesc->u.plcp.length_low);
rt2x00_set_field32(, TXD_W3_PLCP_LENGTH_LOW_REGNUM, 8);
@@ -1147,7 +1147,7 @@ static void rt2400pci_write_tx_desc(struct queue_entry 
*entry,
 * the device, whereby the device may take hold of the TXD before we
 * finished updating it.
 */
-   rt2x00_desc_read(txd, 0, );
+   word = rt2x00_desc_read(txd, 0);
rt2x00_set_field32(, TXD_W0_OWNER_NIC, 1);
rt2x00_set_field32(, TXD_W0_VALID, 1);
rt2x00_set_field32(, TXD_W0_MORE_FRAG,
@@ -1228,10 +1228,10 @@ static void 

[PATCH v2 05/10] rt2x00: convert rt2x00usb_register_read return type

[Arnd Bergmann]

This is a semi-automated conversion to change rt2x00usb_register_read
to return the register contents instead of passing them by value,
resulting in much better object code. The majority of the patch
was done using:

sed -i 's:\(\(.*, .*\), &\(.*\));:\2 = \1);:' \
-i 's:\(\(.*, .*\), &\(.*\));:\2 = \1);:' \
-i 's:\(\(.*, .*\), &\(.*\));:\2 = \1);:' \
 drivers/net/wireless/ralink/rt2x00/*

Signed-off-by: Arnd Bergmann 
---
 drivers/net/wireless/ralink/rt2x00/rt2500usb.c | 104 +++---
 drivers/net/wireless/ralink/rt2x00/rt2800usb.c |  14 +--
 drivers/net/wireless/ralink/rt2x00/rt2x00usb.c |   2 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00usb.h |  32 +--
 drivers/net/wireless/ralink/rt2x00/rt73usb.c   | 114 -
 5 files changed, 118 insertions(+), 148 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2500usb.c 
b/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
index 9cff9ddafb72..70204cecc985 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
@@ -55,26 +55,24 @@ MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
  * If the csr_mutex is already held then the _lock variants must
  * be used instead.
  */
-static void rt2500usb_register_read(struct rt2x00_dev *rt2x00dev,
-  const unsigned int offset,
-  u16 *value)
+static u16 rt2500usb_register_read(struct rt2x00_dev *rt2x00dev,
+  const unsigned int offset)
 {
__le16 reg;
rt2x00usb_vendor_request_buff(rt2x00dev, USB_MULTI_READ,
  USB_VENDOR_REQUEST_IN, offset,
  , sizeof(reg));
-   *value = le16_to_cpu(reg);
+   return le16_to_cpu(reg);
 }
 
-static void rt2500usb_register_read_lock(struct rt2x00_dev *rt2x00dev,
-   const unsigned int offset,
-   u16 *value)
+static u16 rt2500usb_register_read_lock(struct rt2x00_dev *rt2x00dev,
+   const unsigned int offset)
 {
__le16 reg;
rt2x00usb_vendor_req_buff_lock(rt2x00dev, USB_MULTI_READ,
   USB_VENDOR_REQUEST_IN, offset,
   , sizeof(reg), REGISTER_TIMEOUT);
-   *value = le16_to_cpu(reg);
+   return le16_to_cpu(reg);
 }
 
 static void rt2500usb_register_write(struct rt2x00_dev *rt2x00dev,
@@ -114,7 +112,7 @@ static int rt2500usb_regbusy_read(struct rt2x00_dev 
*rt2x00dev,
unsigned int i;
 
for (i = 0; i < REGISTER_USB_BUSY_COUNT; i++) {
-   rt2500usb_register_read_lock(rt2x00dev, offset, reg);
+   *reg = rt2500usb_register_read_lock(rt2x00dev, offset);
if (!rt2x00_get_field16(*reg, field))
return 1;
udelay(REGISTER_BUSY_DELAY);
@@ -178,7 +176,7 @@ static void rt2500usb_bbp_read(struct rt2x00_dev *rt2x00dev,
rt2500usb_register_write_lock(rt2x00dev, PHY_CSR7, reg);
 
if (WAIT_FOR_BBP(rt2x00dev, ))
-   rt2500usb_register_read_lock(rt2x00dev, PHY_CSR7, );
+   reg = rt2500usb_register_read_lock(rt2x00dev, PHY_CSR7);
}
 
*value = rt2x00_get_field16(reg, PHY_CSR7_DATA);
@@ -219,11 +217,7 @@ static void rt2500usb_rf_write(struct rt2x00_dev 
*rt2x00dev,
 static u32 _rt2500usb_register_read(struct rt2x00_dev *rt2x00dev,
 const unsigned int offset)
 {
-   u16 tmp;
-
-   rt2500usb_register_read(rt2x00dev, offset, );
-
-   return tmp;
+   return rt2500usb_register_read(rt2x00dev, offset);
 }
 
 static void _rt2500usb_register_write(struct rt2x00_dev *rt2x00dev,
@@ -281,7 +275,7 @@ static int rt2500usb_rfkill_poll(struct rt2x00_dev 
*rt2x00dev)
 {
u16 reg;
 
-   rt2500usb_register_read(rt2x00dev, MAC_CSR19, );
+   reg = rt2500usb_register_read(rt2x00dev, MAC_CSR19);
return rt2x00_get_field16(reg, MAC_CSR19_VAL7);
 }
 
@@ -294,7 +288,7 @@ static void rt2500usb_brightness_set(struct led_classdev 
*led_cdev,
unsigned int enabled = brightness != LED_OFF;
u16 reg;
 
-   rt2500usb_register_read(led->rt2x00dev, MAC_CSR20, );
+   reg = rt2500usb_register_read(led->rt2x00dev, MAC_CSR20);
 
if (led->type == LED_TYPE_RADIO || led->type == LED_TYPE_ASSOC)
rt2x00_set_field16(, MAC_CSR20_LINK, enabled);
@@ -312,7 +306,7 @@ static int rt2500usb_blink_set(struct led_classdev 
*led_cdev,
container_of(led_cdev, struct rt2x00_led, led_dev);
u16 reg;
 
-   rt2500usb_register_read(led->rt2x00dev, MAC_CSR21, );
+   reg = rt2500usb_register_read(led->rt2x00dev, 

[PATCH v2 08/10] rt2x00: convert rt2x00_eeprom_read return type

[Arnd Bergmann]

This is a semi-automated conversion to change rt2x00_eeprom_read()
to return the register contents instead of passing them by value,
resulting in much better object code. The majority of the patch
was done using:

sed -i 's:\(\(.*, .*\), &\(.*\));:\2 = \1);:' \
   -i 's:= _\(rt2x00_eeprom_read\):= \1:' drivers/net/wireless/ralink/rt2x00/*

Signed-off-by: Arnd Bergmann 
---
 drivers/net/wireless/ralink/rt2x00/rt2400pci.c |  8 +++---
 drivers/net/wireless/ralink/rt2x00/rt2500pci.c | 16 ++--
 drivers/net/wireless/ralink/rt2x00/rt2500usb.c | 34 +-
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c |  6 ++---
 drivers/net/wireless/ralink/rt2x00/rt2x00.h| 10 ++--
 drivers/net/wireless/ralink/rt2x00/rt61pci.c   | 28 ++---
 drivers/net/wireless/ralink/rt2x00/rt73usb.c   | 28 ++---
 7 files changed, 62 insertions(+), 68 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c 
b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
index 0ab3d571aba4..73b919838a61 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
@@ -178,7 +178,7 @@ static const struct rt2x00debug rt2400pci_rt2x00debug = {
.word_count = CSR_REG_SIZE / sizeof(u32),
},
.eeprom = {
-   .read   = _rt2x00_eeprom_read,
+   .read   = rt2x00_eeprom_read,
.write  = rt2x00_eeprom_write,
.word_base  = EEPROM_BASE,
.word_size  = sizeof(u16),
@@ -950,7 +950,7 @@ static int rt2400pci_init_bbp(struct rt2x00_dev *rt2x00dev)
rt2400pci_bbp_write(rt2x00dev, 31, 0x00);
 
for (i = 0; i < EEPROM_BBP_SIZE; i++) {
-   rt2x00_eeprom_read(rt2x00dev, EEPROM_BBP_START + i, );
+   eeprom = rt2x00_eeprom_read(rt2x00dev, EEPROM_BBP_START + i);
 
if (eeprom != 0x && eeprom != 0x) {
reg_id = rt2x00_get_field16(eeprom, EEPROM_BBP_REG_ID);
@@ -1464,7 +1464,7 @@ static int rt2400pci_validate_eeprom(struct rt2x00_dev 
*rt2x00dev)
mac = rt2x00_eeprom_addr(rt2x00dev, EEPROM_MAC_ADDR_0);
rt2x00lib_set_mac_address(rt2x00dev, mac);
 
-   rt2x00_eeprom_read(rt2x00dev, EEPROM_ANTENNA, );
+   word = rt2x00_eeprom_read(rt2x00dev, EEPROM_ANTENNA);
if (word == 0x) {
rt2x00_err(rt2x00dev, "Invalid EEPROM data detected\n");
return -EINVAL;
@@ -1482,7 +1482,7 @@ static int rt2400pci_init_eeprom(struct rt2x00_dev 
*rt2x00dev)
/*
 * Read EEPROM word for configuration.
 */
-   rt2x00_eeprom_read(rt2x00dev, EEPROM_ANTENNA, );
+   eeprom = rt2x00_eeprom_read(rt2x00dev, EEPROM_ANTENNA);
 
/*
 * Identify RF chipset.
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2500pci.c 
b/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
index a4e2f7b8adf1..5fcee4855720 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
@@ -178,7 +178,7 @@ static const struct rt2x00debug rt2500pci_rt2x00debug = {
.word_count = CSR_REG_SIZE / sizeof(u32),
},
.eeprom = {
-   .read   = _rt2x00_eeprom_read,
+   .read   = rt2x00_eeprom_read,
.write  = rt2x00_eeprom_write,
.word_base  = EEPROM_BASE,
.word_size  = sizeof(u16),
@@ -1104,7 +1104,7 @@ static int rt2500pci_init_bbp(struct rt2x00_dev 
*rt2x00dev)
rt2500pci_bbp_write(rt2x00dev, 62, 0x10);
 
for (i = 0; i < EEPROM_BBP_SIZE; i++) {
-   rt2x00_eeprom_read(rt2x00dev, EEPROM_BBP_START + i, );
+   eeprom = rt2x00_eeprom_read(rt2x00dev, EEPROM_BBP_START + i);
 
if (eeprom != 0x && eeprom != 0x) {
reg_id = rt2x00_get_field16(eeprom, EEPROM_BBP_REG_ID);
@@ -1590,7 +1590,7 @@ static int rt2500pci_validate_eeprom(struct rt2x00_dev 
*rt2x00dev)
mac = rt2x00_eeprom_addr(rt2x00dev, EEPROM_MAC_ADDR_0);
rt2x00lib_set_mac_address(rt2x00dev, mac);
 
-   rt2x00_eeprom_read(rt2x00dev, EEPROM_ANTENNA, );
+   word = rt2x00_eeprom_read(rt2x00dev, EEPROM_ANTENNA);
if (word == 0x) {
rt2x00_set_field16(, EEPROM_ANTENNA_NUM, 2);
rt2x00_set_field16(, EEPROM_ANTENNA_TX_DEFAULT,
@@ -1606,7 +1606,7 @@ static int rt2500pci_validate_eeprom(struct rt2x00_dev 
*rt2x00dev)
rt2x00_eeprom_dbg(rt2x00dev, "Antenna: 0x%04x\n", word);
}
 
-   rt2x00_eeprom_read(rt2x00dev, EEPROM_NIC, );
+   word = rt2x00_eeprom_read(rt2x00dev, EEPROM_NIC);
if (word == 0x) {
rt2x00_set_field16(, EEPROM_NIC_CARDBUS_ACCEL, 0);
rt2x00_set_field16(, EEPROM_NIC_DYN_BBP_TUNE, 0);
@@ -1615,7 +1615,7 @@ static 

[PATCH v2 01/10] rt2x00: change function pointers for register accessors

[Arnd Bergmann]

This prepares the driver for changing all the 'read' register accessors
to return the value instead of passing it by reference. Since a lot
of them are used in callbacks, this takes care of the callbacks first,
adding a couple of helpers that will be removed again one at a time.

Signed-off-by: Arnd Bergmann 
---
 drivers/net/wireless/ralink/rt2x00/rt2400pci.c   | 18 +++
 drivers/net/wireless/ralink/rt2x00/rt2500pci.c   | 18 +++
 drivers/net/wireless/ralink/rt2x00/rt2500usb.c   | 24 ++--
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c   | 28 +++-
 drivers/net/wireless/ralink/rt2x00/rt2800lib.h   | 20 -
 drivers/net/wireless/ralink/rt2x00/rt2800pci.c   |  4 ++--
 drivers/net/wireless/ralink/rt2x00/rt2800soc.c   |  4 ++--
 drivers/net/wireless/ralink/rt2x00/rt2800usb.c   |  4 ++--
 drivers/net/wireless/ralink/rt2x00/rt2x00.h  | 13 +++
 drivers/net/wireless/ralink/rt2x00/rt2x00debug.c |  2 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00debug.h |  4 ++--
 drivers/net/wireless/ralink/rt2x00/rt2x00mmio.h  |  6 +
 drivers/net/wireless/ralink/rt2x00/rt2x00usb.h   | 22 ++-
 drivers/net/wireless/ralink/rt2x00/rt61pci.c | 17 ++
 drivers/net/wireless/ralink/rt2x00/rt73usb.c | 17 ++
 15 files changed, 157 insertions(+), 44 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c 
b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
index 19874439ac40..3ba9a1674e1d 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
@@ -164,10 +164,20 @@ static void rt2400pci_eepromregister_write(struct 
eeprom_93cx6 *eeprom)
 }
 
 #ifdef CONFIG_RT2X00_LIB_DEBUGFS
+static u8 _rt2400pci_bbp_read(struct rt2x00_dev *rt2x00dev,
+ const unsigned int word)
+{
+   u8 value;
+
+   rt2400pci_bbp_read(rt2x00dev, word, );
+
+   return value;
+}
+
 static const struct rt2x00debug rt2400pci_rt2x00debug = {
.owner  = THIS_MODULE,
.csr= {
-   .read   = rt2x00mmio_register_read,
+   .read   = _rt2x00mmio_register_read,
.write  = rt2x00mmio_register_write,
.flags  = RT2X00DEBUGFS_OFFSET,
.word_base  = CSR_REG_BASE,
@@ -175,21 +185,21 @@ static const struct rt2x00debug rt2400pci_rt2x00debug = {
.word_count = CSR_REG_SIZE / sizeof(u32),
},
.eeprom = {
-   .read   = rt2x00_eeprom_read,
+   .read   = _rt2x00_eeprom_read,
.write  = rt2x00_eeprom_write,
.word_base  = EEPROM_BASE,
.word_size  = sizeof(u16),
.word_count = EEPROM_SIZE / sizeof(u16),
},
.bbp= {
-   .read   = rt2400pci_bbp_read,
+   .read   = _rt2400pci_bbp_read,
.write  = rt2400pci_bbp_write,
.word_base  = BBP_BASE,
.word_size  = sizeof(u8),
.word_count = BBP_SIZE / sizeof(u8),
},
.rf = {
-   .read   = rt2x00_rf_read,
+   .read   = _rt2x00_rf_read,
.write  = rt2400pci_rf_write,
.word_base  = RF_BASE,
.word_size  = sizeof(u32),
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2500pci.c 
b/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
index 791434de8052..d9b061b73e83 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
@@ -164,10 +164,20 @@ static void rt2500pci_eepromregister_write(struct 
eeprom_93cx6 *eeprom)
 }
 
 #ifdef CONFIG_RT2X00_LIB_DEBUGFS
+static u8 _rt2500pci_bbp_read(struct rt2x00_dev *rt2x00dev,
+ const unsigned int word)
+{
+   u8 value;
+
+   rt2500pci_bbp_read(rt2x00dev, word, );
+
+   return value;
+}
+
 static const struct rt2x00debug rt2500pci_rt2x00debug = {
.owner  = THIS_MODULE,
.csr= {
-   .read   = rt2x00mmio_register_read,
+   .read   = _rt2x00mmio_register_read,
.write  = rt2x00mmio_register_write,
.flags  = RT2X00DEBUGFS_OFFSET,
.word_base  = CSR_REG_BASE,
@@ -175,21 +185,21 @@ static const struct rt2x00debug rt2500pci_rt2x00debug = {
.word_count = CSR_REG_SIZE / sizeof(u32),
},
.eeprom = {
-   .read   = rt2x00_eeprom_read,
+   .read   = _rt2x00_eeprom_read,
.write  = rt2x00_eeprom_write,
.word_base  = EEPROM_BASE,
.word_size  = sizeof(u16),
.word_count = EEPROM_SIZE / 

[PATCH v2 04/10] rt2x00: convert rt2x00mmio_register_read return type

[Arnd Bergmann]

This is a semi-automated conversion to change rt2x00mmio_register_read
to return the register contents instead of passing them by value,
resulting in much better object code. The majority of the patch
was done using:

sed -i 's:\(rt2x00mmio_register_read(.*, .*\), &\(.*\));:\2 = \1);:' \
-i 's:_rt2x00mmio_register_read:rt2x00mmio_register_read:' \
drivers/net/wireless/ralink/rt2x00/*.c

The function itself was modified manually along with the one remaining
caller that was not covered automatically.

Signed-off-by: Arnd Bergmann 
---
 drivers/net/wireless/ralink/rt2x00/rt2400pci.c  | 128 
 drivers/net/wireless/ralink/rt2x00/rt2500pci.c  | 140 +-
 drivers/net/wireless/ralink/rt2x00/rt2800mmio.c |  30 ++--
 drivers/net/wireless/ralink/rt2x00/rt2800pci.c  |  10 +-
 drivers/net/wireless/ralink/rt2x00/rt2800soc.c  |   4 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00mmio.c |   2 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00mmio.h |   9 +-
 drivers/net/wireless/ralink/rt2x00/rt61pci.c| 188 
 8 files changed, 252 insertions(+), 259 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c 
b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
index d41832292db2..3607261df199 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
@@ -138,7 +138,7 @@ static void rt2400pci_eepromregister_read(struct 
eeprom_93cx6 *eeprom)
struct rt2x00_dev *rt2x00dev = eeprom->data;
u32 reg;
 
-   rt2x00mmio_register_read(rt2x00dev, CSR21, );
+   reg = rt2x00mmio_register_read(rt2x00dev, CSR21);
 
eeprom->reg_data_in = !!rt2x00_get_field32(reg, CSR21_EEPROM_DATA_IN);
eeprom->reg_data_out = !!rt2x00_get_field32(reg, CSR21_EEPROM_DATA_OUT);
@@ -177,7 +177,7 @@ static u8 _rt2400pci_bbp_read(struct rt2x00_dev *rt2x00dev,
 static const struct rt2x00debug rt2400pci_rt2x00debug = {
.owner  = THIS_MODULE,
.csr= {
-   .read   = _rt2x00mmio_register_read,
+   .read   = rt2x00mmio_register_read,
.write  = rt2x00mmio_register_write,
.flags  = RT2X00DEBUGFS_OFFSET,
.word_base  = CSR_REG_BASE,
@@ -212,7 +212,7 @@ static int rt2400pci_rfkill_poll(struct rt2x00_dev 
*rt2x00dev)
 {
u32 reg;
 
-   rt2x00mmio_register_read(rt2x00dev, GPIOCSR, );
+   reg = rt2x00mmio_register_read(rt2x00dev, GPIOCSR);
return rt2x00_get_field32(reg, GPIOCSR_VAL0);
 }
 
@@ -225,7 +225,7 @@ static void rt2400pci_brightness_set(struct led_classdev 
*led_cdev,
unsigned int enabled = brightness != LED_OFF;
u32 reg;
 
-   rt2x00mmio_register_read(led->rt2x00dev, LEDCSR, );
+   reg = rt2x00mmio_register_read(led->rt2x00dev, LEDCSR);
 
if (led->type == LED_TYPE_RADIO || led->type == LED_TYPE_ASSOC)
rt2x00_set_field32(, LEDCSR_LINK, enabled);
@@ -243,7 +243,7 @@ static int rt2400pci_blink_set(struct led_classdev 
*led_cdev,
container_of(led_cdev, struct rt2x00_led, led_dev);
u32 reg;
 
-   rt2x00mmio_register_read(led->rt2x00dev, LEDCSR, );
+   reg = rt2x00mmio_register_read(led->rt2x00dev, LEDCSR);
rt2x00_set_field32(, LEDCSR_ON_PERIOD, *delay_on);
rt2x00_set_field32(, LEDCSR_OFF_PERIOD, *delay_off);
rt2x00mmio_register_write(led->rt2x00dev, LEDCSR, reg);
@@ -276,7 +276,7 @@ static void rt2400pci_config_filter(struct rt2x00_dev 
*rt2x00dev,
 * Note that the version error will always be dropped
 * since there is no filter for it at this time.
 */
-   rt2x00mmio_register_read(rt2x00dev, RXCSR0, );
+   reg = rt2x00mmio_register_read(rt2x00dev, RXCSR0);
rt2x00_set_field32(, RXCSR0_DROP_CRC,
   !(filter_flags & FIF_FCSFAIL));
rt2x00_set_field32(, RXCSR0_DROP_PHYSICAL,
@@ -305,14 +305,14 @@ static void rt2400pci_config_intf(struct rt2x00_dev 
*rt2x00dev,
 * Enable beacon config
 */
bcn_preload = PREAMBLE + GET_DURATION(IEEE80211_HEADER, 20);
-   rt2x00mmio_register_read(rt2x00dev, BCNCSR1, );
+   reg = rt2x00mmio_register_read(rt2x00dev, BCNCSR1);
rt2x00_set_field32(, BCNCSR1_PRELOAD, bcn_preload);
rt2x00mmio_register_write(rt2x00dev, BCNCSR1, reg);
 
/*
 * Enable synchronisation.
 */
-   rt2x00mmio_register_read(rt2x00dev, CSR14, );
+   reg = rt2x00mmio_register_read(rt2x00dev, CSR14);
rt2x00_set_field32(, CSR14_TSF_SYNC, conf->sync);
rt2x00mmio_register_write(rt2x00dev, CSR14, reg);
}
@@ -340,35 +340,35 @@ static void rt2400pci_config_erp(struct rt2x00_dev 
*rt2x00dev,
if (changed & BSS_CHANGED_ERP_PREAMBLE) {
preamble_mask = 

[PATCH v2 00/10] rt2x00: rt2x00: improve calling conventions for register accessors

[Arnd Bergmann]

I've managed to split up my long patch into a series of reasonble
steps now.

The first two are required to fix a regression from commit 41977e86c984
("rt2x00: add support for MT7620"), the rest are just cleanups to
have a consistent state across all the register access functions.

 Arnd

[PATCH v2 06/10] rt2x00: convert rt2800_register_read return type

[Arnd Bergmann]

This is a semi-automated conversion to change rt2800_register_read
to return the register contents instead of passing them by value,
resulting in much better object code. The majority of the patch
was done using:

sed -i 's:\(rt2800_register_read(.*, .*\), &\(.*\));:\2 = \1);:' \
   's:\(rt2800_register_read_lock(.*, .*\), &\(.*\));:\2 = \1);:' \
drivers/net/wireless/ralink/rt2x00/rt2800lib.c

The function itself was modified manually along with the one remaining
multi-line caller that was not covered automatically and the indirect
reference.

Signed-off-by: Arnd Bergmann 
---
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 291 -
 drivers/net/wireless/ralink/rt2x00/rt2800lib.h |  22 +-
 2 files changed, 151 insertions(+), 162 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c 
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index fef53d6a888a..541e2692766a 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -442,7 +442,7 @@ static int rt2800_enable_wlan_rt3290(struct rt2x00_dev 
*rt2x00dev)
u32 reg;
int i, count;
 
-   rt2800_register_read(rt2x00dev, WLAN_FUN_CTRL, );
+   reg = rt2800_register_read(rt2x00dev, WLAN_FUN_CTRL);
rt2x00_set_field32(, WLAN_GPIO_OUT_OE_BIT_ALL, 0xff);
rt2x00_set_field32(, FRC_WL_ANT_SET, 1);
rt2x00_set_field32(, WLAN_CLK_EN, 0);
@@ -457,7 +457,7 @@ static int rt2800_enable_wlan_rt3290(struct rt2x00_dev 
*rt2x00dev)
 * Check PLL_LD & XTAL_RDY.
 */
for (i = 0; i < REGISTER_BUSY_COUNT; i++) {
-   rt2800_register_read(rt2x00dev, CMB_CTRL, );
+   reg = rt2800_register_read(rt2x00dev, CMB_CTRL);
if (rt2x00_get_field32(reg, PLL_LD) &&
rt2x00_get_field32(reg, XTAL_RDY))
break;
@@ -480,7 +480,7 @@ static int rt2800_enable_wlan_rt3290(struct rt2x00_dev 
*rt2x00dev)
count = 0;
}
 
-   rt2800_register_read(rt2x00dev, WLAN_FUN_CTRL, );
+   reg = rt2800_register_read(rt2x00dev, WLAN_FUN_CTRL);
rt2x00_set_field32(, PCIE_APP0_CLK_REQ, 0);
rt2x00_set_field32(, WLAN_CLK_EN, 1);
rt2x00_set_field32(, WLAN_RESET, 1);
@@ -535,7 +535,7 @@ int rt2800_wait_csr_ready(struct rt2x00_dev *rt2x00dev)
u32 reg;
 
for (i = 0; i < REGISTER_BUSY_COUNT; i++) {
-   rt2800_register_read(rt2x00dev, MAC_CSR0, );
+   reg = rt2800_register_read(rt2x00dev, MAC_CSR0);
if (reg && reg != ~0)
return 0;
msleep(1);
@@ -556,7 +556,7 @@ int rt2800_wait_wpdma_ready(struct rt2x00_dev *rt2x00dev)
 * before timing out.
 */
for (i = 0; i < REGISTER_BUSY_COUNT; i++) {
-   rt2800_register_read(rt2x00dev, WPDMA_GLO_CFG, );
+   reg = rt2800_register_read(rt2x00dev, WPDMA_GLO_CFG);
if (!rt2x00_get_field32(reg, WPDMA_GLO_CFG_TX_DMA_BUSY) &&
!rt2x00_get_field32(reg, WPDMA_GLO_CFG_RX_DMA_BUSY))
return 0;
@@ -573,7 +573,7 @@ void rt2800_disable_wpdma(struct rt2x00_dev *rt2x00dev)
 {
u32 reg;
 
-   rt2800_register_read(rt2x00dev, WPDMA_GLO_CFG, );
+   reg = rt2800_register_read(rt2x00dev, WPDMA_GLO_CFG);
rt2x00_set_field32(, WPDMA_GLO_CFG_ENABLE_TX_DMA, 0);
rt2x00_set_field32(, WPDMA_GLO_CFG_TX_DMA_BUSY, 0);
rt2x00_set_field32(, WPDMA_GLO_CFG_ENABLE_RX_DMA, 0);
@@ -723,7 +723,7 @@ int rt2800_load_firmware(struct rt2x00_dev *rt2x00dev,
rt2x00_rt(rt2x00dev, RT3572) ||
rt2x00_rt(rt2x00dev, RT5390) ||
rt2x00_rt(rt2x00dev, RT5392)) {
-   rt2800_register_read(rt2x00dev, AUX_CTRL, );
+   reg = rt2800_register_read(rt2x00dev, AUX_CTRL);
rt2x00_set_field32(, AUX_CTRL_FORCE_PCIE_CLK, 1);
rt2x00_set_field32(, AUX_CTRL_WAKE_PCIE_EN, 1);
rt2800_register_write(rt2x00dev, AUX_CTRL, reg);
@@ -742,7 +742,7 @@ int rt2800_load_firmware(struct rt2x00_dev *rt2x00dev,
 * Wait for device to stabilize.
 */
for (i = 0; i < REGISTER_BUSY_COUNT; i++) {
-   rt2800_register_read(rt2x00dev, PBF_SYS_CTRL, );
+   reg = rt2800_register_read(rt2x00dev, PBF_SYS_CTRL);
if (rt2x00_get_field32(reg, PBF_SYS_CTRL_READY))
break;
msleep(1);
@@ -1096,7 +1096,7 @@ static void rt2800_update_beacons_setup(struct rt2x00_dev 
*rt2x00dev)
/*
 * H/W sends up to MAC_BSSID_DW1_BSS_BCN_NUM + 1 consecutive beacons.
 */
-   rt2800_register_read(rt2x00dev, MAC_BSSID_DW1, _dw1);
+   bssid_dw1 = 

[PATCH v2 09/10] rt2x00: convert rt2800_eeprom_read return type

[Arnd Bergmann]

This is a semi-automated conversion to change rt2800_eeprom_read to return
the register contents instead of passing them by value, resulting in
much better object code. The majority of the patch was done using:

sed -i 's:\(\(.*, .*\), &\(.*\));:\3 = 
\1);:'
drivers/net/wireless/ralink/rt2x00/rt2800lib.c

Some manual tweaking was required here to work around the line wraps.

Signed-off-by: Arnd Bergmann 
---
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 194 -
 1 file changed, 97 insertions(+), 97 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c 
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 7998cc196ee4..5063169b7794 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -410,13 +410,13 @@ static void *rt2800_eeprom_addr(struct rt2x00_dev 
*rt2x00dev,
return rt2x00_eeprom_addr(rt2x00dev, index);
 }
 
-static void rt2800_eeprom_read(struct rt2x00_dev *rt2x00dev,
-  const enum rt2800_eeprom_word word, u16 *data)
+static u16 rt2800_eeprom_read(struct rt2x00_dev *rt2x00dev,
+ const enum rt2800_eeprom_word word)
 {
unsigned int index;
 
index = rt2800_eeprom_word_index(rt2x00dev, word);
-   *data = rt2x00_eeprom_read(rt2x00dev, index);
+   return rt2x00_eeprom_read(rt2x00dev, index);
 }
 
 static void rt2800_eeprom_write(struct rt2x00_dev *rt2x00dev,
@@ -428,15 +428,14 @@ static void rt2800_eeprom_write(struct rt2x00_dev 
*rt2x00dev,
rt2x00_eeprom_write(rt2x00dev, index, data);
 }
 
-static void rt2800_eeprom_read_from_array(struct rt2x00_dev *rt2x00dev,
- const enum rt2800_eeprom_word array,
- unsigned int offset,
- u16 *data)
+static u16 rt2800_eeprom_read_from_array(struct rt2x00_dev *rt2x00dev,
+const enum rt2800_eeprom_word array,
+unsigned int offset)
 {
unsigned int index;
 
index = rt2800_eeprom_word_index(rt2x00dev, array);
-   *data = rt2x00_eeprom_read(rt2x00dev, index + offset);
+   return rt2x00_eeprom_read(rt2x00dev, index + offset);
 }
 
 static int rt2800_enable_wlan_rt3290(struct rt2x00_dev *rt2x00dev)
@@ -848,16 +847,16 @@ static int rt2800_agc_to_rssi(struct rt2x00_dev 
*rt2x00dev, u32 rxwi_w2)
u8 offset2;
 
if (rt2x00dev->curr_band == NL80211_BAND_2GHZ) {
-   rt2800_eeprom_read(rt2x00dev, EEPROM_RSSI_BG, );
+   eeprom = rt2800_eeprom_read(rt2x00dev, EEPROM_RSSI_BG);
offset0 = rt2x00_get_field16(eeprom, EEPROM_RSSI_BG_OFFSET0);
offset1 = rt2x00_get_field16(eeprom, EEPROM_RSSI_BG_OFFSET1);
-   rt2800_eeprom_read(rt2x00dev, EEPROM_RSSI_BG2, );
+   eeprom = rt2800_eeprom_read(rt2x00dev, EEPROM_RSSI_BG2);
offset2 = rt2x00_get_field16(eeprom, EEPROM_RSSI_BG2_OFFSET2);
} else {
-   rt2800_eeprom_read(rt2x00dev, EEPROM_RSSI_A, );
+   eeprom = rt2800_eeprom_read(rt2x00dev, EEPROM_RSSI_A);
offset0 = rt2x00_get_field16(eeprom, EEPROM_RSSI_A_OFFSET0);
offset1 = rt2x00_get_field16(eeprom, EEPROM_RSSI_A_OFFSET1);
-   rt2800_eeprom_read(rt2x00dev, EEPROM_RSSI_A2, );
+   eeprom = rt2800_eeprom_read(rt2x00dev, EEPROM_RSSI_A2);
offset2 = rt2x00_get_field16(eeprom, EEPROM_RSSI_A2_OFFSET2);
}
 
@@ -1913,7 +1912,7 @@ static void rt2800_config_3572bt_ant(struct rt2x00_dev 
*rt2x00dev)
led_r_mode = rt2x00_get_field32(reg, LED_CFG_LED_POLAR) ? 0 : 3;
if (led_g_mode != rt2x00_get_field32(reg, LED_CFG_G_LED_MODE) ||
led_r_mode != rt2x00_get_field32(reg, LED_CFG_R_LED_MODE)) {
-   rt2800_eeprom_read(rt2x00dev, EEPROM_FREQ, );
+   eeprom = rt2800_eeprom_read(rt2x00dev, EEPROM_FREQ);
led_ctrl = rt2x00_get_field16(eeprom, EEPROM_FREQ_LED_MODE);
if (led_ctrl == 0 || led_ctrl > 0x40) {
rt2x00_set_field32(, LED_CFG_G_LED_MODE, 
led_g_mode);
@@ -1988,8 +1987,8 @@ void rt2800_config_ant(struct rt2x00_dev *rt2x00dev, 
struct antenna_setup *ant)
rt2x00_rt(rt2x00dev, RT3090) ||
rt2x00_rt(rt2x00dev, RT3352) ||
rt2x00_rt(rt2x00dev, RT3390)) {
-   rt2800_eeprom_read(rt2x00dev,
-  EEPROM_NIC_CONF1, );
+   eeprom = rt2800_eeprom_read(rt2x00dev,
+   EEPROM_NIC_CONF1);
if (rt2x00_get_field16(eeprom,
EEPROM_NIC_CONF1_ANT_DIVERSITY))
 

Re: [PATCH] rt2x00: improve calling conventions for register accessors

[Arnd Bergmann]

On Wed, May 17, 2017 at 2:17 PM, Tom Psyborg  wrote:
>
>
> On 16 May 2017 at 16:31, Jes Sorensen  wrote:
>>
>>
>> True - if the automatic conversion works without automatic intervention, I
>> am less worried about it. Personally I would still focus on converting one
>> function at a time to reduce the impact of each patch.
>>
> give me a single patch with all changes to try

I've sent a series of 10 patches now that does it all one (or two in some cases)
function at a time. The combined patch is a little too large to send
on the mailing
list.

 Arnd

[PATCH v2 07/10] rt2x00: convert rt2*_bbp_read return type

[Arnd Bergmann]

This is a semi-automated conversion to change *_bbp_read()
to return the register contents instead of passing them by value,
resulting in much better object code. The majority of the patch
was done using:

sed -i 's:\(\(.*, .*\), &\(.*\));:\2 = \1);:' \
-i 's:\(\(.*, .*\), &\(.*\));:\2 = \1);:' \
-i 's:= _\(rt.*_bbp_read\):\1:' drivers/net/wireless/ralink/rt2x00/*

Signed-off-by: Arnd Bergmann 
---
 drivers/net/wireless/ralink/rt2x00/rt2400pci.c |  29 +++
 drivers/net/wireless/ralink/rt2x00/rt2500pci.c |  27 +++---
 drivers/net/wireless/ralink/rt2x00/rt2500usb.c |  29 +++
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 116 -
 drivers/net/wireless/ralink/rt2x00/rt61pci.c   |  42 -
 drivers/net/wireless/ralink/rt2x00/rt73usb.c   |  36 
 6 files changed, 119 insertions(+), 160 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c 
b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
index 3607261df199..0ab3d571aba4 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
@@ -77,10 +77,11 @@ static void rt2400pci_bbp_write(struct rt2x00_dev 
*rt2x00dev,
mutex_unlock(>csr_mutex);
 }
 
-static void rt2400pci_bbp_read(struct rt2x00_dev *rt2x00dev,
-  const unsigned int word, u8 *value)
+static u8 rt2400pci_bbp_read(struct rt2x00_dev *rt2x00dev,
+const unsigned int word)
 {
u32 reg;
+   u8 value;
 
mutex_lock(>csr_mutex);
 
@@ -103,9 +104,11 @@ static void rt2400pci_bbp_read(struct rt2x00_dev 
*rt2x00dev,
WAIT_FOR_BBP(rt2x00dev, );
}
 
-   *value = rt2x00_get_field32(reg, BBPCSR_VALUE);
+   value = rt2x00_get_field32(reg, BBPCSR_VALUE);
 
mutex_unlock(>csr_mutex);
+
+   return value;
 }
 
 static void rt2400pci_rf_write(struct rt2x00_dev *rt2x00dev,
@@ -164,16 +167,6 @@ static void rt2400pci_eepromregister_write(struct 
eeprom_93cx6 *eeprom)
 }
 
 #ifdef CONFIG_RT2X00_LIB_DEBUGFS
-static u8 _rt2400pci_bbp_read(struct rt2x00_dev *rt2x00dev,
- const unsigned int word)
-{
-   u8 value;
-
-   rt2400pci_bbp_read(rt2x00dev, word, );
-
-   return value;
-}
-
 static const struct rt2x00debug rt2400pci_rt2x00debug = {
.owner  = THIS_MODULE,
.csr= {
@@ -192,7 +185,7 @@ static const struct rt2x00debug rt2400pci_rt2x00debug = {
.word_count = EEPROM_SIZE / sizeof(u16),
},
.bbp= {
-   .read   = _rt2400pci_bbp_read,
+   .read   = rt2400pci_bbp_read,
.write  = rt2400pci_bbp_write,
.word_base  = BBP_BASE,
.word_size  = sizeof(u8),
@@ -418,8 +411,8 @@ static void rt2400pci_config_ant(struct rt2x00_dev 
*rt2x00dev,
BUG_ON(ant->rx == ANTENNA_SW_DIVERSITY ||
   ant->tx == ANTENNA_SW_DIVERSITY);
 
-   rt2400pci_bbp_read(rt2x00dev, 4, );
-   rt2400pci_bbp_read(rt2x00dev, 1, );
+   r4 = rt2400pci_bbp_read(rt2x00dev, 4);
+   r1 = rt2400pci_bbp_read(rt2x00dev, 1);
 
/*
 * Configure the TX antenna.
@@ -600,7 +593,7 @@ static void rt2400pci_link_stats(struct rt2x00_dev 
*rt2x00dev,
/*
 * Update False CCA count from register.
 */
-   rt2400pci_bbp_read(rt2x00dev, 39, );
+   bbp = rt2400pci_bbp_read(rt2x00dev, 39);
qual->false_cca = bbp;
 }
 
@@ -921,7 +914,7 @@ static int rt2400pci_wait_bbp_ready(struct rt2x00_dev 
*rt2x00dev)
u8 value;
 
for (i = 0; i < REGISTER_BUSY_COUNT; i++) {
-   rt2400pci_bbp_read(rt2x00dev, 0, );
+   value = rt2400pci_bbp_read(rt2x00dev, 0);
if ((value != 0xff) && (value != 0x00))
return 0;
udelay(REGISTER_BUSY_DELAY);
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2500pci.c 
b/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
index dc622d60f79d..a4e2f7b8adf1 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
@@ -77,10 +77,11 @@ static void rt2500pci_bbp_write(struct rt2x00_dev 
*rt2x00dev,
mutex_unlock(>csr_mutex);
 }
 
-static void rt2500pci_bbp_read(struct rt2x00_dev *rt2x00dev,
-  const unsigned int word, u8 *value)
+static u8 rt2500pci_bbp_read(struct rt2x00_dev *rt2x00dev,
+const unsigned int word)
 {
u32 reg;
+   u8 value;
 
mutex_lock(>csr_mutex);
 
@@ -103,9 +104,11 @@ static void rt2500pci_bbp_read(struct rt2x00_dev 
*rt2x00dev,
WAIT_FOR_BBP(rt2x00dev, );
}
 
-   *value = rt2x00_get_field32(reg, BBPCSR_VALUE);
+   value = rt2x00_get_field32(reg, BBPCSR_VALUE);
 
mutex_unlock(>csr_mutex);
+
+   return value;
 }
 
 static void 

Re: [PATCH V2 0/9] nl80211: add support for PTK/GTK handshake offload

[Johannes Berg]

Hi,

I think this looks really good. One thing though:

> Another change is the
> addition of the flag ATTR_WANT_1X_4WAY_HS that user-space has to pass
> in CONNECT request. Some drivers may need to be aware before the PMK
> is programmed through SET_PMK request.

I wonder how we really should do this, and if this is good enough.

There might be drivers that simply don't support the non-offloaded
case, so they assume you always have the newer wpa_s. That would seem
to be a legitimate decision, since the compatibility with that might
not make much sense for a completely new driver, and it might be a lot
of work to support TK operations.

We should therefore probably set the expectation that wpa_s - if it's
new enough - always uses the offloaded functionality and always sets
the WANT_1X. Then this is even better with such drivers, since they can
immediately reject the connect() command if want_1x isn't set.

Thoughts?

johannes

Re: [PATCH v3] mac80211: Dynamically set CoDel parameters per station

[Johannes Berg]

On Thu, 2017-04-06 at 11:38 +0200, Toke Høiland-Jørgensen wrote:
> CoDel can be too aggressive if a station sends at a very low rate,
> leading reduced throughput. This gets worse the more stations are
> present, as each station gets more bursty the longer the round-robin
> scheduling between stations takes.
> 
[...]

I've applied this now (with some minor fixups) - the whole discussion
didn't really conclude in anything, and we can just try it.

johannes

Re: [PATCH v2] mac80211: mesh - always do every discovery retry

[Johannes Berg]

On Wed, 2017-03-29 at 18:33 +0800, Chun-Yeow Yeoh wrote:
> I would suggest the following modification of commit messages and
> code. Let me know whether this is fine.
> 
> -
> I would suggest the following edition to the commit message:
> 
> Instead of stopping path discovery when a path is established,
> continue the
> attempts to find alternative paths until we hit the
> dot11MeshHWMPmaxPREQretries
> limit. However, this is not a standard behavior and may easily
> increase the number of
> broadcast PREQ frame in your network. So this feature is turned off
> by default.
> 
> and the remaining are removed due to misleading explanation.
> 
> Then, in the mesh_path_timer, I think that only the following is
> needed:
> 
> - if (mpath->flags & MESH_PATH_RESOLVED ||
> - (!(mpath->flags & MESH_PATH_RESOLVING))) {
> + if (!multiple_discoveries &&
> +(mpath->flags & MESH_PATH_RESOLVED ||
> + (!(mpath->flags & MESH_PATH_RESOLVING {

Alexis?

johannes

Re: nl80211 vendor commands on upstream drivers

[Johannes Berg]

On Fri, 2017-05-12 at 16:51 +0300, Kalle Valo wrote:
> 
> But this does not mean that the gates are open for all possible hacks
> via vendor commands, we still want to have generic nl80211 interface
> for all normal functionality. Just to give some examples of something
> which is NOT acceptable:

[snip scanning]

> * power save settings
> * btcoex settings

I'm starting to think that these might really be a vendor API for
anything but the most basic features - there's so much variation here
now.

OTOH, much of these shouldn't really be something the user needs to
twiddle with anyway.

> Comments? Am I forgetting something from the discussion?

I think that's a good summary.

johannes

Re: iw reg get since iw-4.x

[Johannes Berg]

On Fri, 2017-05-12 at 17:11 +0300, Sergey Naumov wrote:
> Hi All.
> 
> I see that since iw-4.x "iw reg get" reports multiple region
> information - per-phy and global. Moreover, per-phy information could
> be marked as "self-managed".

That's also dependent on the kernel.

> Could somebody clarify when a driver uses phy-specific region and
> when
> - the global one?

It's just a driver decision, and how the firmware works.

> Looking at a list of channels from "iw phy phyX info" I can conclude
> that if "self-managed" is true, then phy-specific region is used,
> otherwise - the global one. Is it a correct assumption? If yes, then
> why phy-specific regions are reported at all for non-self-managed
> devices, and why the global region is reported for self-managed ones?

Good question, I'm not sure right now. You probably need to look at the
kernel's code (net/wireless/reg.c) to figure out the answer.

> I think it would be natural to use new "iw phy phyX reg get" command
> to report region information that is actually used, but unfortunately
> this command returns exactly the same as "iw reg get":

It's a pure alias right now, but that could be fixed by filtering in iw
I guess.

johannes

Re: 'iw events' stops receiving events after a while on 4.9 + hacks

[Johannes Berg]

On Wed, 2017-05-17 at 12:08 +0200, Bastian Bittorf wrote:
> * Ben Greear  [17.05.2017 11:51]:
> > I have been keeping an 'iw events' program running with a perl
> > script gathering its
> > output and post-processing it.  This has been working for several
> > years on 4.7 and earlier
> > kernels, but when testing on 4.9 overnight, I notice that 'iw
> > events' is not showing any input.  'strace' shows
> > that it is waiting on recvmsg.  If I start a second 'iw events'
> > then it will get
> > wifi events as expected.
> 
> me too, also seen on 4.4 - i'am happy for debug ideas.

I've never seen this.

Does it happen when it's very long-running? Or when there are lots of
events?

Perhaps something in the socket buffer accounting is going wrong, so
that it's slowly decreasing to 0?

johannes

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

[Johannes Berg]

On Wed, 2017-05-17 at 15:21 +0200, Pali Rohár wrote:
> On Wednesday 17 May 2017 15:04:50 Johannes Berg wrote:
> > On Wed, 2017-05-17 at 14:53 +0200, Pali Rohár wrote:
> > 
> > > > In fact, why should the *driver* care either? IOW - why should
> > > > "request_firmware_prefer_user()" even exist?
> > > 
> > > There are default/example NVS data, which are stored in
> > > /lib/firmware
> > > and installed by linux-firmware package.
> > 
> > [...]
> > 
> > Oh, so you're saying you want this to invert the order ... Ok, that
> > makes some sense.
> 
> Yes! I thought that this fact can be understood from commit message.
> If not, I can change it, but provide how to improve it.

It probably can, I was only Cc'ed later :)

Sorry for the noise.

johannes

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

[Pali Rohár]

On Wednesday 17 May 2017 15:04:50 Johannes Berg wrote:
> On Wed, 2017-05-17 at 14:53 +0200, Pali Rohár wrote:
> 
> > > In fact, why should the *driver* care either? IOW - why should
> > > "request_firmware_prefer_user()" even exist?
> > 
> > There are default/example NVS data, which are stored in /lib/firmware
> > and installed by linux-firmware package.
> [...]
> 
> Oh, so you're saying you want this to invert the order ... Ok, that
> makes some sense.

Yes! I thought that this fact can be understood from commit message. If
not, I can change it, but provide how to improve it.

-- 
Pali Rohár
pali.ro...@gmail.com

Re: when to use wdev_lock()

[Johannes Berg]

Hi Arend,

Sorry for the long delay.

> I bumped into use of wdev_lock() again with 802.1X 4-way-hs offload 
> stuff. So for .set_pmk() and .del_pmk() it takes wdev_lock(). Is
> there a  rule of thumb when this lock is needed. What is it
> protecting in general  and in the case of pmk configuration.

No, unfortunately it's not very well defined.

One thing that drove this is that mac80211 (and perhaps some full-mac
drivers) uses the same lock to prevent races between their own and
cfg80211's state. So some of the locking is driven by that as well.

I think it may have been done here just for consistency with other
calls.

johannes

Re: [PATCH v6] qtnfmac: introduce new FullMAC driver for Quantenna chipsets

[Johannes Berg]

Good job :)

Let's merge this - the tiny fixes for things I found can come later.

Some (mostly trivial) comments:

 * I'm surprised you don't support WEP - nice :)
 * I don't think returning -EFAULT from qtnf_add_virtual_intf is a good
   idea - perhaps better propagate the error or use -EIO?
 * the forward declaration of struct bus in pearl/pcie_bus_priv.h seems 
unnecessary
 * you might want to use a whitelist in qtnf_set_wiphy_params(), but
   it's not really important as we should add capability bits for
   everything that we add
 * qtnf_mgmt_frame_register()/cfg80211_rx_mgmt() aren't used correctly
   - since there's filtering further than the frame type/subtype, you
   need to check the return value of cfg80211_rx_mgmt(). If, for
   example, userspace only registers for a certain action frame
   category, you need to still reject the remaining ones yourself. We
   could extend the API here to give you the whole filter data as well,
   if that helps. Otherwise you need to handle the return value from
   cfg80211_rx_mgmt().
 * The ENOENT handling in qtnf_dump_station() surprises me, especially
   since there's no checking that this doesn't result in duplicate
   cfg80211_del_sta() calls due to races - if
   qtnf_event_handle_sta_deauth() wins to remove it with
   qtnf_sta_list_del() but qtnf_dump_station() already had it looked
   up? Seems like the whole handling in that function either needs to
   be the same as in the event, or just be removed and return -ENOENT
 * There seems to be little point in dynamically allocating the
   iface_comb in qtnf_wiphy_register() vs. just embedding it in struct
   qtnf_wmac or so?
 * qtnf_rx_frame() is declared but not used?
 * -D__CHECK_ENDIAN was always wrong, it should be -D__CHECK_ENDIAN__,
   but it's now also enabled by default so can be removed
 * I'm not sure there's much point in printing the failure code address
   (which should be static) in pr_err("skb DMA mapping error: %pad\n",
   _paddr);
 * I like the real use of NAPI :)
 * However, is there any specific reason you're not using
   napi_gro_receive() rather than netif_receive_skb()? It seems using
   GRO would help TCP streams, in particular by reducing the number of
   ACKs
 * with just a single (PCI-E) transport, I'm not sure I see much point
   in splitting it into a separate module, which necessitates the
   EXPORT_SYMBOL_GPL, which do take up a bit of space. But there are
   only 4, so it doesn't really matter :) One thing we did in iwlwifi
   was to not export if both are built-in, since nobody else should
   ever have any reason to access them.

Thanks all!

johannes

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

[Johannes Berg]

On Wed, 2017-05-17 at 14:53 +0200, Pali Rohár wrote:

> > In fact, why should the *driver* care either? IOW - why should
> > "request_firmware_prefer_user()" even exist?
> 
> There are default/example NVS data, which are stored in /lib/firmware
> and installed by linux-firmware package.
[...]

Oh, so you're saying you want this to invert the order ... Ok, that
makes some sense.

I still hope that all other requests will eventually fall back to user
loading though, I think that's important to system integration in
general.

johannes

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

[Pali Rohár]

On Wednesday 17 May 2017 14:06:06 Johannes Berg wrote:
> On Tue, 2017-05-16 at 01:13 +0200, Luis R. Rodriguez wrote:
> > > > Now for N900 case there is a similar scenario
> > > > alhtough it has additional requirement to go to user-space due to
> > > > need to use a proprietary library to obtain the NVS calibration
> > > > data. My thought: Why should firmware_class care?
> > 
> > Agreed.
> 
> In fact, why should the *driver* care either? IOW - why should
> "request_firmware_prefer_user()" even exist?

There are default/example NVS data, which are stored in /lib/firmware
and installed by linux-firmware package. Those example calibration data
should not be used for real usage, but Pavel told us that on N900 they
are enough for working WIFI connection. They does not contain valid MAC
address, so kernel should generate some (random?).

So kernel driver should get NVS calibration data from userspace (which
know how where to get or how to prepare them) and in case userspace do
not have it, then we can try fallback to those example data (as people
reported us they can be useful instead of non-working WIFI).

And that fallback is working by direct firmware loading from kernel.

-- 
Pali Rohár
pali.ro...@gmail.com

Re: [PATCH v2] mac80211: strictly check mesh address extension mode

[Johannes Berg]

On Sun, 2017-05-14 at 21:41 -0700, Rajkumar Manoharan wrote:
> Mesh forwarding path checks for address extension mode to fetch
> appropriate proxied address and MPP address. Existing condition
> that looks for 6 address format is not strict enough so that
> frames with improper values are processed and invalid entries
> are added into MPP table. Fix that by adding a stricter check before
> processing the packet.
> 
> Per IEEE Std 802.11s-2011 spec. Table 7-6g1 lists address extension
> mode 0x3 as reserved one. And also Table Table 9-13 does not specify
> 0x3 as valid address field.

Yeah ...

applied, thanks.

johannes

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

[Johannes Berg]

On Tue, 2017-05-16 at 01:13 +0200, Luis R. Rodriguez wrote:
> > > Now for N900 case there is a similar scenario
> > > alhtough it has additional requirement to go to user-space due to
> > > need to use a proprietary library to obtain the NVS calibration
> > > data. My thought: Why should firmware_class care?
> 
> Agreed.

In fact, why should the *driver* care either? IOW - why should
"request_firmware_prefer_user()" even exist?

> > > So the idea is that firmware_class provides
> > > a registry for modules that can produce a certain firmware
> > > "file". Those
> > > modules can do whatever is needed. If they need to use umh so be
> > > it.
> > > They would only register themselves with firmware_class on
> > > platforms
> > > that need them. It would basically be replacing the fallback
> > > mechanism
> > > and only be effective on certain platforms.
> 
> Sure, so it sounds like the work that Daniel Wagner and Tom Gundersen
> worked [0] on which provides a firmwared with two modes: best-effort, 
> and final-mode, would address what you are looking for but without
> requiring any upstream changes, *and* it also helps solve the rootfs
> race remote-proc folks had concerns over.

Right.

> The other added gain over this solution is if folks need their own
> proprietary concoction they can just fork firmwared

Or just reimplement it to the same kernel API, no need to even use the
same code base.

> Lastly, if we did not want to deal with timeouts for the way the
> driver data API implements it I think we might be able to do away
> with them for for async requests if we assume there will be a daemon
> that spawns in final-mode eventually, and since it *knows* when the
> rootfs is ready it should be able to do a final lookup, if it returns
> -ENOENT; then indeed we know we can give up. Now, perhaps how and if
> we want to deal with timeouts when using the driver data API for the
> fallback mechanism is worth considering given it does not have a
> fallback mechanism support yet. If we *add* them it would seem this
> would also put an implicit race against userspace finishing
> initialization and running firmwared in final-mode.
> 
> Johannes, do you recall the corner cases we spoke about regarding
> timeouts? Does this match what we spoke about?

I think we have to protect against userspace code crashing, not
existing, etc. - so I think we do need a timeout anyway.

However, I don't recall any (other) corner cases we might have spoken
about.

> Note that firmware signing will require an additional file, the
> detached signature.

Is anything like that happening finally? :)

johannes
> 

[PATCH] rt2800usb: Add Epson wireless adapter device-id

[Tom Gaudasiński]

Make Epson WN7512BEP work by adding its device-id to rt2800usb. Device
contains a Ralink RT3071L, registers as vendor Accton/Arcadyan.

Signed-off-by: Tom Gaudasinski 

--- linux/drivers/net/wireless/ralink/rt2x00/rt2800usb.c.orig   
2017-05-17 19:49:44.893895819 +1000
+++ linux/drivers/net/wireless/ralink/rt2x00/rt2800usb.c2017-05-17
19:49:32.90692 +1000
@@ -1156,6 +1156,8 @@ static struct usb_device_id rt2800usb_de
 { USB_DEVICE(0x2001, 0x3c17) },
 /* Panasonic */
 { USB_DEVICE(0x083a, 0xb511) },
+/* Accton/Arcadyan/Epson */
+{ USB_DEVICE(0x083a, 0xb512) },
 /* Philips */
 { USB_DEVICE(0x0471, 0x20dd) },
 /* Ralink */

Re: 'iw events' stops receiving events after a while on 4.9 + hacks

[Bastian Bittorf]

* Ben Greear  [17.05.2017 11:51]:
> I have been keeping an 'iw events' program running with a perl script 
> gathering its
> output and post-processing it.  This has been working for several years on 
> 4.7 and earlier
> kernels, but when testing on 4.9 overnight, I notice that 'iw events' is not 
> showing any input.  'strace' shows
> that it is waiting on recvmsg.  If I start a second 'iw events' then it will 
> get
> wifi events as expected.

me too, also seen on 4.4 - i'am happy for debug ideas.

bye, bastian

Re: [PATCH] [ath10k] go back to using dma_alloc_coherent() for firmware scratch memory.

[Sven Eckelmann]

On Montag, 1. Mai 2017 14:43:27 CEST Adrian Chadd wrote:
> This reverts b057886524be060021e3cfad0ba8458c850330cd in 2015
> which converted this allocation from dma_map_coherent() to
> kzalloc() / dma_map_single().
> 
> The current problem manifests when using later model NICs with larger
> (>700KiB) scratch spaces in memory.  Although the kzalloc call
> succeeds, the software IOMMU TLB code (via dma_map_single()) panics
> because it can't find 700KiB of linear physmem bounce buffers for DMA.
> Now, this is a bit of a silly failure mode for the dma map API,
> but it's what we currently have to play with.
[]
> 
> Signed-off-by: Adrian Chadd 
> ---
>  drivers/net/wireless/ath/ath10k/wmi.c | 35 
> ++-
>  1 file changed, 10 insertions(+), 25 deletions(-)

Thanks for investigating this. This partial revert fixes following crash for
me with QCA99X0 on amd64 with SWIOMMU:

[9.167281] DMA: Out of SW-IOMMU space for 689816 bytes at device 
:02:00.0
[9.174719] Kernel panic - not syncing: DMA: Random memory could be DMA 
read
[9.174719] 
[9.183560] CPU: 0 PID: 133 Comm: kworker/u32:6 Tainted: P   OE  
 4.9.0-0.bpo.2-amd64 #1 Debian 4.9.13-1~bpo8+1
[9.194666] Hardware name: Intel Corporation SandyBridge 
Platform/ETXe-SC T2 i3-2310E, BIOS CHR2R110 05/12/2011
[9.205033] Workqueue: ath10k_aux_wq ath10k_wmi_event_service_ready_work 
[ath10k_core]
[9.213151]   bd329cd5 0200 
a7b5c1247cb8
[9.220827]  bd17bc24 0008 a7b5c1247cc8 
a7b5c1247c60
[9.228523]  6036bf02 00020018 91fde700dfc8 

[9.236177] Call Trace:
[9.238692]  [] ? dump_stack+0x5c/0x77
[9.244165]  [] ? panic+0xe8/0x236
[9.251161]  [] ? swiotlb_map_page+0x16c/0x190
[9.259219]  [] ? 
ath10k_wmi_event_service_ready_work+0x4d5/0x680 [ath10k_core]
[9.272150]  [] ? process_one_work+0x14b/0x410
[9.280190]  [] ? worker_thread+0x65/0x4a0
[9.287869]  [] ? rescuer_thread+0x340/0x340
[9.295689]  [] ? kthread+0xe0/0x100
[9.302742]  [] ? __switch_to+0x2bb/0x700
[9.310213]  [] ? kthread_park+0x60/0x60
[9.317556]  [] ? ret_from_fork+0x25/0x30
[9.324992] Kernel Offset: 0x3c00 from 0x8100 
(relocation range: 0x8000-0xbfff)
[9.339429] ---[ end Kernel panic - not syncing: DMA: Random memory 
could be DMA read
[9.339429] 
[9.353900] [ cut here ]
[9.360274] WARNING: CPU: 0 PID: 133 at 
/home/zumbi/linux-4.9.13/arch/x86/kernel/smp.c:127 
update_process_times+0x40/0x50
[9.374724] Modules linked in: tpm_infineon iTCO_wdt iTCO_vendor_support 
ppdev wl(POE) evdev intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp 
kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
cryptd intel_cstate intel_uncore ath10k_pci ath10k_core intel_rapl_perf ath 
mac80211 i2c_kempld btusb btrtl btbcm btintel pcspkr bluetooth cfg80211 
serio_raw rfkill snd_hda_codec_realtek snd_hda_codec_generic battery 
snd_hda_intel parport_pc parport snd_hda_codec i915 snd_hda_core snd_hwdep 
shpchp video drm_kms_helper snd_pcm snd_timer snd drm soundcore mei_me button 
mei i2c_i801 i2c_smbus lpc_ich tpm_tis tpm_tis_core ac tpm autofs4 ext4 crc16 
jbd2 fscrypto mbcache sg sd_mod ata_generic ahci pata_jmicron libahci 
kempld_core mfd_core libata ehci_pci ehci_hcd scsi_mod crc32c_intel usbcore 
psmouse e1000e usb_common igb i2c_algo_bit dca ptp pps_core fan thermal fjes
[9.476736] CPU: 0 PID: 133 Comm: kworker/u32:6 Tainted: P   OE  
 4.9.0-0.bpo.2-amd64 #1 Debian 4.9.13-1~bpo8+1
[9.491320] Hardware name: Intel Corporation SandyBridge 
Platform/ETXe-SC T2 i3-2310E, BIOS CHR2R110 05/12/2011
[9.505260] Workqueue: ath10k_aux_wq ath10k_wmi_event_service_ready_work 
[ath10k_core]
[9.517103]   bd329cd5  

[9.528682]  bd0778a4 91fde101a140  
a7b5c1247b98
[9.540304]  bd0f7270 0003 91fde7012580 
bd0e7dc0
[9.551962] Call Trace:
[9.556381]   [9.558370]  [] ? 
dump_stack+0x5c/0x77
[9.567776]  [] ? __warn+0xc4/0xe0
[9.574863]  [] ? tick_sched_do_timer+0x30/0x30
[9.583059]  [] ? update_process_times+0x40/0x50
[9.591302]  [] ? tick_sched_handle.isra.13+0x20/0x50
[9.600021]  [] ? tick_sched_timer+0x38/0x70
[9.607872]  [] ? __hrtimer_run_queues+0xdc/0x250
[9.616158]  [] ? hrtimer_interrupt+0x99/0x190
[9.624100]  [] ? smp_apic_timer_interrupt+0x39/0x50
[9.632618]  [] ? apic_timer_interrupt+0x82/0x90
[9.640700]   [9.642681]  [] ? 
panic+0x1f2/0x236
[9.649615]  [] ? swiotlb_map_page+0x16c/0x190

git repo with Redpine changes

[Alexey Brodkin]

Hello Amitkumar, Prameela,

I was lucky enough to get hold of RS9113 Evaluation Kit and now I'm trying
to get it working with my board via USB and SDIO interfaces but seeing issues 
here and there:
 1) In case of SDIO I see this on interface up with vanilla 4.11.1 kernel:
--->8
# ifconfig wlan0 up
rsi_91x: Sending RX filter frame
rsi_91x: rsi_core_qos_processor: Queue number = 4
rsi_91x: rsi_sdio_host_intf_write_pkt: Successfully written onto card
rsi_91x: rsi_set_vap_capabilities: Sending VAP capabilities frame
rsi_91x: rsi_mac80211_conf_tx: Conf queue 0, aifs: 2, cwmin: 15 cwmax: 1023, 
txop: 0
rsi_91x: rsi_mac80211_conf_tx: Conf queue 1, aifs: 2, cwmin: 15 cwmax: 1023, 
txop: 0
rsi_91x: rsi_mac80211_conf_tx: Conf queue 2, aifs: 2, cwmin: 15 cwmax: 1023, 
txop: 0
# rsi_91x: rsi_mac80211_conf_tx: Conf queue 3, aifs: 2, cwmin: 15 cwmax: 1023, 
txop: 0
rsi_91x: rsi_channel_change: Set channel: 2412 MHz type: 416 channel_no 1
rsi_91x: rsi_set_channel: Sending scan req frame
rsi_91x: rsi_mac80211_config: Configuring Power
rsi_91x: rsi_config_power: Set tx power: 20 dBM
rsi_91x: rsi_send_radio_params_update: Sending Radio Params update frame
rsi_91x: rsi_core_qos_processor: Queue number = 4
rsi_91x: rsi_interrupt_handler: Intr_status = 8 8 4
rsi_91x: Pkt pending interrupt
rsi_91x: rsi_mgmt_pkt_recv: Msg Len: 0, Msg Type:1
rsi_91x: rsi_handle_ta_confirm_type: Invalid TA confirm pkt received
rsi_91x: rsi_sdio_host_intf_write_pkt: Successfully written onto card
rsi_91x: rsi_core_qos_processor: Queue number = 4
rsi_91x: rsi_sdio_host_intf_write_pkt: Successfully written onto card
rsi_91x: rsi_core_qos_processor: Queue number = 4
rsi_91x: rsi_interrupt_handler: Intr_status = 8 8 4
rsi_91x: Pkt pending interrupt
rsi_91x: rsi_mgmt_pkt_recv: Msg Len: 0, Msg Type:1
rsi_91x: rsi_handle_ta_confirm_type: Invalid TA confirm pkt received
rsi_91x: rsi_interrupt_handler: Intr_status = 8 8 4
rsi_91x: Pkt pending interrupt
rsi_91x: rsi_mgmt_pkt_recv: Msg Len: 321, Msg Type:2
rsi_91x: rsi_sdio_host_intf_write_pkt: Successfully written onto card
rsi_91x: rsi_core_qos_processor: Queue number = 255
rsi_91x: rsi_core_qos_processor: No More Pkt
rsi_91x: rsi_interrupt_handler: Intr_status = c 8 4
rsi_91x: Pkt pending interrupt
rsi_91x: rsi_mgmt_pkt_recv: Msg Len: 299, Msg Type:2
rsi_91x: rsi_interrupt_handler: ==> FIRMWARE Assert <==
rsi_91x: rsi_interrupt_handler: Firmware Status is 0x65
rsi_91x: rsi_core_qos_processor: Queue number = 255
rsi_91x: rsi_core_qos_processor: No More Pkt
--->8

and you recent patch series for nwe firmware loading I see something a bit
different:
--->8
mmc_host mmc0: Bus speed (slot 0) = 5000Hz (slot req 2500Hz, actual 
2500HZ div = 1)
mmc0: new SDIO card at address fffd
rsi_91x: rsi_probe: Init function called
rsi_91x: rsi_init_sdio_interface: Enabled the interface
mmc_host mmc0: Bus speed (slot 0) = 5000Hz (slot req 5000Hz, actual 
5000HZ div = 0)
rsi_91x: rsi_setblocklength: Setting the block length
rsi_91x: rsi_setblocklength: Operational blk length is 256
rsi_91x: rsi_init_sdio_interface: Setup card succesfully
rsi_91x: rsi_init_sdio_slave_regs: Initialzing SDIO read start level
rsi_91x: rsi_init_sdio_slave_regs: Initialzing FIFO ctrl registers
rsi_91x: rsi_sdio_master_access_msword: MASTER_ACCESS_MSBYTE:0x5
rsi_91x: rsi_sdio_master_access_msword:MASTER_ACCESS_LSBYTE:0x41
rsi_91x: rsi_sdio_read_register_multiple: Synch Cmd53 read failed
rsi_91x: rsi_sdio_master_reg_read: AHB register read failed
rsi_91x: rsi_load_firmware: REGOUT read failed
rsi_91x: rsi_hal_device_init: Failed to load TA instructions
rsi_91x: rsi_probe: Failed in device init
rsi_91x: rsi_91x_deinit: Performing deinit os ops
rsi_91x: rsi_core_qos_processor: Queue number = 255
rsi_91x: rsi_core_qos_processor: No More Pkt
rsi_91x: rsi_probe: Failed in probe...Exiting
RSI-SDIO WLAN: probe of mmc0:fffd:1 failed with error 1
--->8

 2) In case of USB I just see:
--->8
usb 1-1: new high-speed USB device number 6 using ehci-platform
usb 1-1: config 1 interface 0 altsetting 0 endpoint 0x83 has an invalid 
bInterval 255, changing to 11
usb 1-1: New USB device found, idVendor=1618, idProduct=9113
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1: Product: Wireless USB-CDC Network Module
usb 1-1: Manufacturer: Redpine Signals, Inc.
cdc_acm 1-1:1.0: ttyACM0: USB ACM device
--->8

I noticed that there're quite some patches floating on linux-wireless mailing 
list which
were not yet merged in upstream kernel (even in linux-next or wireless-testing).

So at this point I'm not really sure what could be a safe baseline for my 
experiments:
 - if existing vanilla say 4.11 kernel is good enough and things that doesn't 
work are caused
   by other 

VERIFICA

[ZIMBRA]

L'aggiornamento dell'account è in corso, fa parte di esso oggi per un perfetto 
funzionamento dei conti. CLICCA SULLA LINK SEGUENTE E AGGIORNARE IL TUO CONTO 
IMMEDIATAMENTE.

http://bibankie.tripod.com

ZIMBRA WEBMASTER