[PATCH] mwifiex: set different mac address for interfaces with same bss type

[Xinming Hu]

Multiple interfaces with same bss type could affect each other if
they are sharing the same mac address. In this patch, different
mac address is assigned to new interface which have same bss type
with exist interfaces.

Signed-off-by: Xinming Hu 
---
 drivers/net/wireless/marvell/mwifiex/main.c | 24 +++-
 drivers/net/wireless/marvell/mwifiex/main.h | 13 +
 2 files changed, 32 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index 3dd8584..20737f5 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -960,13 +960,26 @@ int mwifiex_set_mac_address(struct mwifiex_private *priv,
struct net_device *dev)
 {
int ret;
-   u64 mac_addr;
+   u64 mac_addr, old_mac_addr;
 
-   if (priv->bss_type != MWIFIEX_BSS_TYPE_P2P)
-   goto done;
+   if (priv->bss_type == MWIFIEX_BSS_TYPE_ANY)
+   return -ENOTSUPP;
 
mac_addr = ether_addr_to_u64(priv->curr_addr);
-   mac_addr |= BIT_ULL(MWIFIEX_MAC_LOCAL_ADMIN_BIT);
+   old_mac_addr = mac_addr;
+
+   if (priv->bss_type == MWIFIEX_BSS_TYPE_P2P)
+   mac_addr |= BIT_ULL(MWIFIEX_MAC_LOCAL_ADMIN_BIT);
+
+   if (mwifiex_get_intf_num(priv->adapter, priv->bss_type) > 1) {
+   /* Set mac address based on bss_type/bss_num */
+   mac_addr ^= BIT_ULL(priv->bss_type + 8);
+   mac_addr += priv->bss_num;
+   }
+
+   if (mac_addr == old_mac_addr)
+   goto done;
+
u64_to_ether_addr(mac_addr, priv->curr_addr);
 
/* Send request to firmware */
@@ -974,13 +987,14 @@ int mwifiex_set_mac_address(struct mwifiex_private *priv,
   HostCmd_ACT_GEN_SET, 0, NULL, true);
 
if (ret) {
+   u64_to_ether_addr(old_mac_addr, priv->curr_addr);
mwifiex_dbg(priv->adapter, ERROR,
"set mac address failed: ret=%d\n", ret);
return ret;
}
 
 done:
-   memcpy(dev->dev_addr, priv->curr_addr, ETH_ALEN);
+   ether_addr_copy(dev->dev_addr, priv->curr_addr);
return 0;
 }
 
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
b/drivers/net/wireless/marvell/mwifiex/main.h
index c4c6918..f607d0b 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -1276,6 +1276,19 @@ int mwifiex_cmd_802_11_bg_scan_config(struct 
mwifiex_private *priv,
return pos;
 }
 
+/* This function return interface number with the same bss_type.
+ */
+static inline u8
+mwifiex_get_intf_num(struct mwifiex_adapter *adapter, u8 bss_type)
+{
+   u8 i, num = 0;
+
+   for (i = 0; i < adapter->priv_num; i++)
+   if (adapter->priv[i] && adapter->priv[i]->bss_type == bss_type)
+   num++;
+   return num;
+}
+
 /*
  * This function returns the correct private structure pointer based
  * upon the BSS type and BSS number.
-- 
1.9.1

Presentation at ELC on debugging wifi modules

[Steve deRosier]

Hi Linux Wireless driver maintainers,

I'm giving a talk at ELC NA next month in Portland and I'd like a
little help from our other driver maintainers. The talk is titled:
"Reliable Linux Wireless - Techniques for Debugging Wireless Module
Integrations". While I'm familiar with a fairly wide variety of WiFi
chips and adapters and drivers, I don't know them all. I will speak
from my experience and I'm sure I won't have time to get into the
detailed ins-and-outs of every driver, but I'd love to include value
for everyone no matter which wifi chip vendor the audience member is
using.

So, if you have any specific tips or tricks you'd like to share with
me so I can include them in the materials for my talk I would
appreciate it.  I'm looking for those harder to find things: the
little known debugfs knobs, module parameters, device tree bindings,
and so on. Or, those things that are are common tripping up points.
Anything you find useful or think others might.

Also, part of my talk will be about how to reach out to those of us on
the list for help. We all know the calls for help come to us in
varying quality and I'd like to explain all the stuff to do first and
all the information to gather and send to us as they reach out. So
please send me any thoughts on what you'd like to see in the emails
when people ask for help.

You're welcome to do it on-list if you desire to elicit discussion,
but in order to keep the noise down feel free to reply to me directly
off-list.

For those that are not of the maintainer types that happen to be on
this list, if you're looking for help or tips and tricks, please
attend my talk at ELC or otherwise come and find me. All are welcome.

Thanks,
- Steve

[PATCHv2 3/3] ath: change in cfg80211_probe_status API

[Venkateswara Naralasetty]

This patch changes cfg80211_probe_status API.

Signed-off-by: Venkateswara Naralasetty 
---
 drivers/net/wireless/ath/wil6210/cfg80211.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c 
b/drivers/net/wireless/ath/wil6210/cfg80211.c
index 768f63f38..b799a53 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -1599,7 +1599,8 @@ static void wil_probe_client_handle(struct wil6210_priv 
*wil,
 */
bool alive = (sta->status == wil_sta_connected);
 
-   cfg80211_probe_status(ndev, sta->addr, req->cookie, alive, GFP_KERNEL);
+   cfg80211_probe_status(ndev, sta->addr, req->cookie, alive,
+ 0, false, GFP_KERNEL);
 }
 
 static struct list_head *next_probe_client(struct wil6210_priv *wil)
-- 
2.7.4

[PATCHv2 2/3] mac80211: Add tx ack signal support in sta info

[Venkateswara Naralasetty]

This allows users to get ack signal strength of
last transmitted frame.

Signed-off-by: Venkateswara Naralasetty 
---
V2:
 * added one bool variable to validate ack_signal is valid or not.

 include/net/mac80211.h  |  1 +
 net/mac80211/sta_info.c |  6 ++
 net/mac80211/sta_info.h |  2 ++
 net/mac80211/status.c   | 11 ++-
 4 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 906e902..854037b 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -934,6 +934,7 @@ struct ieee80211_tx_info {
u8 ampdu_len;
u8 antenna;
u16 tx_time;
+   bool is_valid_ack_signal;
void *status_driver_data[19 / sizeof(void *)];
} status;
struct {
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 0c5627f..0bc40c7 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -2287,6 +2287,12 @@ void sta_set_sinfo(struct sta_info *sta, struct 
station_info *sinfo)
sinfo->filled |= BIT(NL80211_STA_INFO_EXPECTED_THROUGHPUT);
sinfo->expected_throughput = thr;
}
+
+   if (!(sinfo->filled & BIT_ULL(NL80211_STA_INFO_ACK_SIGNAL)) &&
+   sta->status_stats.ack_signal_filled) {
+   sinfo->ack_signal = sta->status_stats.last_ack_signal;
+   sinfo->filled |= BIT_ULL(NL80211_STA_INFO_ACK_SIGNAL);
+   }
 }
 
 u32 sta_get_expected_throughput(struct sta_info *sta)
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index cd53619..f64eb86 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -548,6 +548,8 @@ struct sta_info {
u64 msdu_retries[IEEE80211_NUM_TIDS + 1];
u64 msdu_failed[IEEE80211_NUM_TIDS + 1];
unsigned long last_ack;
+   s8 last_ack_signal;
+   bool ack_signal_filled;
} status_stats;
 
/* Updated from TX path only, no locking requirements */
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index da7427a..743e89c 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -187,9 +187,16 @@ static void ieee80211_frame_acked(struct sta_info *sta, 
struct sk_buff *skb)
struct ieee80211_mgmt *mgmt = (void *) skb->data;
struct ieee80211_local *local = sta->local;
struct ieee80211_sub_if_data *sdata = sta->sdata;
+   struct ieee80211_tx_info *txinfo = IEEE80211_SKB_CB(skb);
 
-   if (ieee80211_hw_check(>hw, REPORTS_TX_ACK_STATUS))
+   if (ieee80211_hw_check(>hw, REPORTS_TX_ACK_STATUS)) {
sta->status_stats.last_ack = jiffies;
+   if (txinfo->status.is_valid_ack_signal) {
+   sta->status_stats.last_ack_signal =
+(s8)txinfo->status.ack_signal;
+   sta->status_stats.ack_signal_filled = true;
+   }
+   }
 
if (ieee80211_is_data_qos(mgmt->frame_control)) {
struct ieee80211_hdr *hdr = (void *) skb->data;
@@ -487,6 +494,8 @@ static void ieee80211_report_ack_skb(struct ieee80211_local 
*local,
ieee80211_is_qos_nullfunc(hdr->frame_control))
cfg80211_probe_status(sdata->dev, hdr->addr1,
  cookie, acked,
+ info->status.ack_signal,
+ 
info->status.is_valid_ack_signal,
  GFP_ATOMIC);
else
cfg80211_mgmt_tx_status(>wdev, cookie,
-- 
2.7.4

[PATCHv2 1/3] cfg80211: send ack_signal to user in probe client response

[Venkateswara Naralasetty]

This patch provides support to get ack signal in probe client response
and in station info from user.

Signed-off-by: Venkateswara Naralasetty 
---
v2:
* addressed Johannes comments

 include/net/cfg80211.h   | 7 ++-
 include/uapi/linux/nl80211.h | 3 +++
 net/wireless/nl80211.c   | 8 ++--
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 7d49cd0..56e905c 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1147,6 +1147,7 @@ struct cfg80211_tid_stats {
  * @rx_duration: aggregate PPDU duration(usecs) for all the frames from a peer
  * @pertid: per-TID statistics, see  cfg80211_tid_stats, using the last
  * (IEEE80211_NUM_TIDS) index for MSDUs not encapsulated in QoS-MPDUs.
+ * @ack_signal: signal strength (in dBm) of the last ACK frame.
  */
 struct station_info {
u64 filled;
@@ -1191,6 +1192,7 @@ struct station_info {
u64 rx_duration;
u8 rx_beacon_signal_avg;
struct cfg80211_tid_stats pertid[IEEE80211_NUM_TIDS + 1];
+   s8 ack_signal;
 };
 
 #if IS_ENABLED(CONFIG_CFG80211)
@@ -5838,10 +5840,13 @@ bool cfg80211_rx_unexpected_4addr_frame(struct 
net_device *dev,
  * @addr: the address of the peer
  * @cookie: the cookie filled in @probe_client previously
  * @acked: indicates whether probe was acked or not
+ * @ack_signal: signal strength (in dBm) of the ACK frame.
+ * @is_valid_ack_signal: indicates the ack_signal is valid or not.
  * @gfp: allocation flags
  */
 void cfg80211_probe_status(struct net_device *dev, const u8 *addr,
-  u64 cookie, bool acked, gfp_t gfp);
+  u64 cookie, bool acked, s32 ack_signal,
+  bool is_valid_ack_signal, gfp_t gfp);
 
 /**
  * cfg80211_report_obss_beacon - report beacon from other APs
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index ca3d5a6..c13c843 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2626,6 +2626,7 @@ enum nl80211_attrs {
NL80211_ATTR_EXTERNAL_AUTH_SUPPORT,
 
NL80211_ATTR_NSS,
+   NL80211_ATTR_ACK_SIGNAL,
 
/* add attributes here, update the policy in nl80211.c */
 
@@ -2947,6 +2948,7 @@ enum nl80211_sta_bss_param {
  * @NL80211_STA_INFO_RX_DURATION: aggregate PPDU duration for all frames
  * received from the station (u64, usec)
  * @NL80211_STA_INFO_PAD: attribute used for padding for 64-bit alignment
+ * @NL80211_STA_INFO_ACK_SIGNAL: signal strength of the last ACK frame(u8, dBm)
  * @__NL80211_STA_INFO_AFTER_LAST: internal
  * @NL80211_STA_INFO_MAX: highest possible station info attribute
  */
@@ -2985,6 +2987,7 @@ enum nl80211_sta_info {
NL80211_STA_INFO_TID_STATS,
NL80211_STA_INFO_RX_DURATION,
NL80211_STA_INFO_PAD,
+   NL80211_STA_INFO_ACK_SIGNAL,
 
/* keep last */
__NL80211_STA_INFO_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index cc6ec5b..707f4a2 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -4486,6 +4486,7 @@ static int nl80211_send_station(struct sk_buff *msg, u32 
cmd, u32 portid,
PUT_SINFO_U64(RX_DROP_MISC, rx_dropped_misc);
PUT_SINFO_U64(BEACON_RX, rx_beacon);
PUT_SINFO(BEACON_SIGNAL_AVG, rx_beacon_signal_avg, u8);
+   PUT_SINFO(ACK_SIGNAL, ack_signal, u8);
 
 #undef PUT_SINFO
 #undef PUT_SINFO_U64
@@ -15006,7 +15007,8 @@ void cfg80211_sta_opmode_change_notify(struct 
net_device *dev, const u8 *mac,
 EXPORT_SYMBOL(cfg80211_sta_opmode_change_notify);
 
 void cfg80211_probe_status(struct net_device *dev, const u8 *addr,
-  u64 cookie, bool acked, gfp_t gfp)
+  u64 cookie, bool acked, s32 ack_signal,
+  bool is_valid_ack_signal, gfp_t gfp)
 {
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct cfg80211_registered_device *rdev = wiphy_to_rdev(wdev->wiphy);
@@ -15031,7 +15033,9 @@ void cfg80211_probe_status(struct net_device *dev, 
const u8 *addr,
nla_put(msg, NL80211_ATTR_MAC, ETH_ALEN, addr) ||
nla_put_u64_64bit(msg, NL80211_ATTR_COOKIE, cookie,
  NL80211_ATTR_PAD) ||
-   (acked && nla_put_flag(msg, NL80211_ATTR_ACK)))
+   (acked && nla_put_flag(msg, NL80211_ATTR_ACK)) ||
+   (is_valid_ack_signal && nla_put_s32(msg, NL80211_ATTR_ACK_SIGNAL,
+   ack_signal)))
goto nla_put_failure;
 
genlmsg_end(msg, hdr);
-- 
2.7.4

Re: [PATCH] headers: untangle kmemleak.h from mm.h

[Randy Dunlap]

On 02/12/2018 04:28 AM, Michael Ellerman wrote:
> Randy Dunlap  writes:
> 
>> From: Randy Dunlap 
>>
>> Currently  #includes  for no obvious
>> reason. It looks like it's only a convenience, so remove kmemleak.h
>> from slab.h and add  to any users of kmemleak_*
>> that don't already #include it.
>> Also remove  from source files that do not use it.
>>
>> This is tested on i386 allmodconfig and x86_64 allmodconfig. It
>> would be good to run it through the 0day bot for other $ARCHes.
>> I have neither the horsepower nor the storage space for the other
>> $ARCHes.
>>
>> [slab.h is the second most used header file after module.h; kernel.h
>> is right there with slab.h. There could be some minor error in the
>> counting due to some #includes having comments after them and I
>> didn't combine all of those.]
>>
>> This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
>> header files).
>>
>> Signed-off-by: Randy Dunlap 
> 
> I threw it at a random selection of configs and so far the only failures
> I'm seeing are:
> 
>   lib/test_firmware.c:134:2: error: implicit declaration of function 'vfree' 
> [-Werror=implicit-function-declaration]   
>
>   lib/test_firmware.c:620:25: error: implicit declaration of function 
> 'vzalloc' [-Werror=implicit-function-declaration]
>   lib/test_firmware.c:620:2: error: implicit declaration of function 
> 'vzalloc' [-Werror=implicit-function-declaration]
>   security/integrity/digsig.c:146:2: error: implicit declaration of function 
> 'vfree' [-Werror=implicit-function-declaration]
> 
> Full results trickling in here, not all the failures there are caused by
> this patch, ie. some configs are broken in mainline:
> 
>   http://kisskb.ellerman.id.au/kisskb/head/13396/

That's very useful, thanks.

I'll send a few patches for those.

-- 
~Randy

Re: Centrino Advanced-N 6235 - Microcode SW error detected

[Luca Coelho]

On Mon, 2018-02-12 at 19:52 +0100, Pali Rohár wrote:
> On Monday 12 February 2018 20:48:47 Luca Coelho wrote:
> > On Tue, 2018-01-30 at 20:49 +0100, Pali Rohár wrote:
> > > Hello,
> > 
> > Hi Pali,
> > 
> > 
> > > for almost 3 years I have a problem with Intel wifi card Centrino
> > > Advanced-N 6235. Its firmware periodically crash and in dmesg I'm
> > > seeing
> > > a message "Microcode SW error detected".
> > > 
> > > Problem happens independently of kernel versions (I tried 3.8,
> > > 3.13,
> > > 3.18, 4.0, 4.9). Currently I'm using Debian Stretch and its 4.9
> > > version.
> > > 
> > > This wifi card is identified as:
> > > 
> > > $ lspci -s 03:00.0 -vv
> > > 03:00.0 Network controller: Intel Corporation Centrino Advanced-N 
> > > 6235 (rev 24)
> > > Subsystem: Intel Corporation Centrino Advanced-N 6235 AGN
> > 
> > [...]
> > 
> > > And here is example of dmesg error flood:
> > > 
> > > [26624.998823] iwlwifi :03:00.0: Microcode SW error
> > > detected.  Restarting 0x200.
> > 
> > [...]
> > 
> > > [26624.999013] iwlwifi :03:00.0: Loaded firmware version:
> > > 18.168.6.1
> > > [26624.999117] iwlwifi :03:00.0: Start IWL Error Log Dump:
> > > [26624.999118] iwlwifi :03:00.0: Status: 0x02CC, count: 6
> > > [26624.999120] iwlwifi :03:00.0: 0x28AA |
> > > ADVANCED_SYSASSERT  
> > > [27464.823779] iwlwifi :03:00.0: Loaded firmware version:
> > > 18.168.6.1
> > > [27464.823903] iwlwifi :03:00.0: Start IWL Error Log Dump:
> > > [27464.823904] iwlwifi :03:00.0: Status: 0x02CC, count: 6
> > > [27464.823906] iwlwifi :03:00.0: 0x28AA |
> > > ADVANCED_SYSASSERT  
> > 
> > [...]
> > 
> > > This really looks like firmware problem. What can I do with these
> > > microcode errors? Can you help me?
> > 
> > Yes, this is a firmware problem.  But unfortunately this is a
> > really
> > old hardware (6 years old) and we don't support the firmware
> > anymore. 
> 
> Hi! That is pity :-(
> 
> > I'm sorry, but there is really nothing we can do.
> 
> So can I debug this problem myself? Is there any documentation or
> resources for this?

Nothing prevents you from trying to debug.  Maybe find the exact
situation when this happens and try to make a workaround in the driver.
 But unfortunately we don't have any public documentation for this
firmware, so you'll have to try to solve it in the driver entirely.

Sadly, I wouldn't have much hope in succeeding, since this is most
likely a purely firmware side bug which may be impossible to work
around in the driver. :(

Good luck!

--
Cheers,
Luca.

Re: [PATCH] headers: untangle kmemleak.h from mm.h

[Randy Dunlap]

On 02/12/2018 04:28 AM, Michael Ellerman wrote:
> Randy Dunlap  writes:
> 
>> From: Randy Dunlap 
>>
>> Currently  #includes  for no obvious
>> reason. It looks like it's only a convenience, so remove kmemleak.h
>> from slab.h and add  to any users of kmemleak_*
>> that don't already #include it.
>> Also remove  from source files that do not use it.
>>
>> This is tested on i386 allmodconfig and x86_64 allmodconfig. It
>> would be good to run it through the 0day bot for other $ARCHes.
>> I have neither the horsepower nor the storage space for the other
>> $ARCHes.
>>
>> [slab.h is the second most used header file after module.h; kernel.h
>> is right there with slab.h. There could be some minor error in the
>> counting due to some #includes having comments after them and I
>> didn't combine all of those.]
>>
>> This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
>> header files).
>>
>> Signed-off-by: Randy Dunlap 
> 
> I threw it at a random selection of configs and so far the only failures
> I'm seeing are:
> 
>   lib/test_firmware.c:134:2: error: implicit declaration of function 'vfree' 
> [-Werror=implicit-function-declaration]   
>
>   lib/test_firmware.c:620:25: error: implicit declaration of function 
> 'vzalloc' [-Werror=implicit-function-declaration]
>   lib/test_firmware.c:620:2: error: implicit declaration of function 
> 'vzalloc' [-Werror=implicit-function-declaration]
>   security/integrity/digsig.c:146:2: error: implicit declaration of function 
> 'vfree' [-Werror=implicit-function-declaration]
> 

Both of those source files need to #include .

> Full results trickling in here, not all the failures there are caused by
> this patch, ie. some configs are broken in mainline:
> 
>   http://kisskb.ellerman.id.au/kisskb/head/13396/
> 
> cheers

:)

-- 
~Randy

Re: 802.11ac devices that use Minstrel_HT

[Rosen Penev]

On Mon, Feb 12, 2018 at 11:05 AM, Ali Abedi  wrote:
> Hello,
>
> It seems that Minstrel_ht rate adaptation algorithm supports 802.11ac VHT
> rates.
> Can you refer me to some 802.11ac devices that use this rate adaptation
> algorithm?
> I need to modify the rate adaptation algorithm however all 802.11ac devices
> that I know have moved this functionality to (closed) firmware.
>
Devices with support for the mt76 do not do rate adaptation in
firmware as far as I can tell. This may also be the case with the
mt7601u driver.
> Best,
> Ali

Re: [PATCH v2] net: make getname() functions return length rather than use int* parameter

[David Miller]

From: Denys Vlasenko 
Date: Mon, 12 Feb 2018 20:00:20 +0100

> Changes since v1:
> Added changes in these files:
> drivers/infiniband/hw/usnic/usnic_transport.c
> drivers/staging/lustre/lnet/lnet/lib-socket.c
> drivers/target/iscsi/iscsi_target_login.c
> drivers/vhost/net.c
> fs/dlm/lowcomms.c
> fs/ocfs2/cluster/tcp.c
> security/tomoyo/network.c
> 
> 
> Before:
> All these functions either return a negative error indicator,
> or store length of sockaddr into "int *socklen" parameter
> and return zero on success.
> 
> "int *socklen" parameter is awkward. For example, if caller does not
> care, it still needs to provide on-stack storage for the value
> it does not need.
> 
> None of the many FOO_getname() functions of various protocols
> ever used old value of *socklen. They always just overwrite it.
> 
> This change drops this parameter, and makes all these functions, on success,
> return length of sockaddr. It's always >= 0 and can be differentiated
> from an error.
> 
> Tests in callers are changed from "if (err)" to "if (err < 0)", where needed.
> 
> rpc_sockname() lost "int buflen" parameter, since its only use was
> to be passed to kernel_getsockname() as  and subsequently
> not used in any way.
> 
> Userspace API is not changed.
> 
> textdata bss  dec hex filename
> 30108430 2633624  873672 33615726 200ef6e vmlinux.before.o
> 30108109 2633612  873672 33615393 200ee21 vmlinux.o
> 
> Signed-off-by: Denys Vlasenko 

Applied to net-next, thanks Denys.

802.11ac devices that use Minstrel_HT

[Ali Abedi]

Hello,

It seems that Minstrel_ht rate adaptation algorithm supports 802.11ac 
VHT rates.
Can you refer me to some 802.11ac devices that use this rate adaptation 
algorithm?
I need to modify the rate adaptation algorithm however all 802.11ac 
devices that I know have moved this functionality to (closed) firmware.


Best,
Ali

[PATCH v2] net: make getname() functions return length rather than use int* parameter

[Denys Vlasenko]

Changes since v1:
Added changes in these files:
drivers/infiniband/hw/usnic/usnic_transport.c
drivers/staging/lustre/lnet/lnet/lib-socket.c
drivers/target/iscsi/iscsi_target_login.c
drivers/vhost/net.c
fs/dlm/lowcomms.c
fs/ocfs2/cluster/tcp.c
security/tomoyo/network.c


Before:
All these functions either return a negative error indicator,
or store length of sockaddr into "int *socklen" parameter
and return zero on success.

"int *socklen" parameter is awkward. For example, if caller does not
care, it still needs to provide on-stack storage for the value
it does not need.

None of the many FOO_getname() functions of various protocols
ever used old value of *socklen. They always just overwrite it.

This change drops this parameter, and makes all these functions, on success,
return length of sockaddr. It's always >= 0 and can be differentiated
from an error.

Tests in callers are changed from "if (err)" to "if (err < 0)", where needed.

rpc_sockname() lost "int buflen" parameter, since its only use was
to be passed to kernel_getsockname() as  and subsequently
not used in any way.

Userspace API is not changed.

textdata bss  dec hex filename
30108430 2633624  873672 33615726 200ef6e vmlinux.before.o
30108109 2633612  873672 33615393 200ee21 vmlinux.o

Signed-off-by: Denys Vlasenko 
CC: David S. Miller 
CC: linux-ker...@vger.kernel.org
CC: net...@vger.kernel.org
CC: linux-blueto...@vger.kernel.org
CC: linux-decnet-u...@lists.sourceforge.net
CC: linux-wireless@vger.kernel.org
CC: linux-r...@vger.kernel.org
CC: linux-s...@vger.kernel.org
CC: linux-...@vger.kernel.org
CC: linux-...@vger.kernel.org
---
 drivers/infiniband/hw/usnic/usnic_transport.c |  5 ++--
 drivers/isdn/mISDN/socket.c   |  5 ++--
 drivers/net/ppp/pppoe.c   |  6 ++---
 drivers/net/ppp/pptp.c|  6 ++---
 drivers/scsi/iscsi_tcp.c  | 14 +--
 drivers/soc/qcom/qmi_interface.c  |  3 +--
 drivers/staging/ipx/af_ipx.c  |  6 ++---
 drivers/staging/irda/net/af_irda.c|  8 +++---
 drivers/staging/lustre/lnet/lnet/lib-socket.c |  7 +++---
 drivers/target/iscsi/iscsi_target_login.c | 18 +++---
 drivers/vhost/net.c   |  7 +++---
 fs/dlm/lowcomms.c |  7 +++---
 fs/ocfs2/cluster/tcp.c|  6 ++---
 include/linux/net.h   |  8 +++---
 include/net/inet_common.h |  2 +-
 include/net/ipv6.h|  2 +-
 include/net/sock.h|  2 +-
 net/appletalk/ddp.c   |  5 ++--
 net/atm/pvc.c |  5 ++--
 net/atm/svc.c |  5 ++--
 net/ax25/af_ax25.c|  4 +--
 net/bluetooth/hci_sock.c  |  4 +--
 net/bluetooth/l2cap_sock.c|  5 ++--
 net/bluetooth/rfcomm/sock.c   |  5 ++--
 net/bluetooth/sco.c   |  5 ++--
 net/can/raw.c |  6 ++---
 net/core/sock.c   |  5 ++--
 net/decnet/af_decnet.c|  6 ++---
 net/ipv4/af_inet.c|  5 ++--
 net/ipv6/af_inet6.c   |  5 ++--
 net/iucv/af_iucv.c|  5 ++--
 net/l2tp/l2tp_ip.c|  5 ++--
 net/l2tp/l2tp_ip6.c   |  5 ++--
 net/l2tp/l2tp_ppp.c   |  5 ++--
 net/llc/af_llc.c  |  5 ++--
 net/netlink/af_netlink.c  |  5 ++--
 net/netrom/af_netrom.c|  9 ---
 net/nfc/llcp_sock.c   |  5 ++--
 net/packet/af_packet.c| 10 +++-
 net/phonet/socket.c   |  5 ++--
 net/qrtr/qrtr.c   |  5 ++--
 net/rds/af_rds.c  |  5 ++--
 net/rds/tcp.c |  7 ++
 net/rose/af_rose.c|  5 ++--
 net/sctp/ipv6.c   |  8 +++---
 net/smc/af_smc.c  | 11 -
 net/socket.c  | 35 +--
 net/sunrpc/clnt.c |  6 ++---
 net/sunrpc/svcsock.c  | 13 ++
 net/sunrpc/xprtsock.c |  3 +--
 net/tipc/socket.c |  5 ++--
 net/unix/af_unix.c| 10 
 net/vmw_vsock/af_vsock.c  |  4 +--
 net/x25/af_x25.c  |  4 +--
 security/tomoyo/network.c |  5 ++--
 55 files changed, 159 insertions(+), 203 deletions(-)

diff --git 

Re: Centrino Advanced-N 6235 - Microcode SW error detected

[Pali Rohár]

On Monday 12 February 2018 20:48:47 Luca Coelho wrote:
> On Tue, 2018-01-30 at 20:49 +0100, Pali Rohár wrote:
> > Hello,
> 
> Hi Pali,
> 
> 
> > for almost 3 years I have a problem with Intel wifi card Centrino
> > Advanced-N 6235. Its firmware periodically crash and in dmesg I'm
> > seeing
> > a message "Microcode SW error detected".
> > 
> > Problem happens independently of kernel versions (I tried 3.8, 3.13,
> > 3.18, 4.0, 4.9). Currently I'm using Debian Stretch and its 4.9
> > version.
> > 
> > This wifi card is identified as:
> > 
> > $ lspci -s 03:00.0 -vv
> > 03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6235 (rev 
> > 24)
> > Subsystem: Intel Corporation Centrino Advanced-N 6235 AGN
> 
> [...]
> 
> > And here is example of dmesg error flood:
> > 
> > [26624.998823] iwlwifi :03:00.0: Microcode SW error detected.  
> > Restarting 0x200.
> 
> [...]
> 
> > [26624.999013] iwlwifi :03:00.0: Loaded firmware version: 18.168.6.1
> > [26624.999117] iwlwifi :03:00.0: Start IWL Error Log Dump:
> > [26624.999118] iwlwifi :03:00.0: Status: 0x02CC, count: 6
> > [26624.999120] iwlwifi :03:00.0: 0x28AA | ADVANCED_SYSASSERT
> >   
> > [27464.823779] iwlwifi :03:00.0: Loaded firmware version: 18.168.6.1
> > [27464.823903] iwlwifi :03:00.0: Start IWL Error Log Dump:
> > [27464.823904] iwlwifi :03:00.0: Status: 0x02CC, count: 6
> > [27464.823906] iwlwifi :03:00.0: 0x28AA | ADVANCED_SYSASSERT
> >   
> 
> [...]
> 
> > This really looks like firmware problem. What can I do with these
> > microcode errors? Can you help me?
> 
> Yes, this is a firmware problem.  But unfortunately this is a really
> old hardware (6 years old) and we don't support the firmware anymore. 

Hi! That is pity :-(

> I'm sorry, but there is really nothing we can do.

So can I debug this problem myself? Is there any documentation or
resources for this?

> I hope the driver manages to recover properly and WiFi continues to
> work on your machine without much disturbance when this happens.
> 
> --
> Cheers,
> Luca.

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


signature.asc
Description: PGP signature

Re: Centrino Advanced-N 6235 - Microcode SW error detected

[Luca Coelho]

On Tue, 2018-01-30 at 20:49 +0100, Pali Rohár wrote:
> Hello,

Hi Pali,


> for almost 3 years I have a problem with Intel wifi card Centrino
> Advanced-N 6235. Its firmware periodically crash and in dmesg I'm
> seeing
> a message "Microcode SW error detected".
> 
> Problem happens independently of kernel versions (I tried 3.8, 3.13,
> 3.18, 4.0, 4.9). Currently I'm using Debian Stretch and its 4.9
> version.
> 
> This wifi card is identified as:
> 
> $ lspci -s 03:00.0 -vv
> 03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6235 (rev 
> 24)
> Subsystem: Intel Corporation Centrino Advanced-N 6235 AGN

[...]

> And here is example of dmesg error flood:
> 
> [26624.998823] iwlwifi :03:00.0: Microcode SW error detected.  Restarting 
> 0x200.

[...]

> [26624.999013] iwlwifi :03:00.0: Loaded firmware version: 18.168.6.1
> [26624.999117] iwlwifi :03:00.0: Start IWL Error Log Dump:
> [26624.999118] iwlwifi :03:00.0: Status: 0x02CC, count: 6
> [26624.999120] iwlwifi :03:00.0: 0x28AA | ADVANCED_SYSASSERT  
> [27464.823779] iwlwifi :03:00.0: Loaded firmware version: 18.168.6.1
> [27464.823903] iwlwifi :03:00.0: Start IWL Error Log Dump:
> [27464.823904] iwlwifi :03:00.0: Status: 0x02CC, count: 6
> [27464.823906] iwlwifi :03:00.0: 0x28AA | ADVANCED_SYSASSERT  

[...]

> This really looks like firmware problem. What can I do with these
> microcode errors? Can you help me?

Yes, this is a firmware problem.  But unfortunately this is a really
old hardware (6 years old) and we don't support the firmware anymore. 
I'm sorry, but there is really nothing we can do.

I hope the driver manages to recover properly and WiFi continues to
work on your machine without much disturbance when this happens.

--
Cheers,
Luca.

Re: [PATCH] ath9k: fix DFS detector synchronization

[Felix Fietkau]

On 2018-02-08 12:46, Timothy Redaelli wrote:
> The code currently syncronize the DFS region only if curchan != 0, but hostapd
> launch DFS before the channel is set and so set_dfs_domain is never executed.
> 
> CC: Felix Fietkau 
> Signed-off-by: Timothy Redaelli 
Acked-by: Felix Fietkau 

Re: [PATCH] net: make getname() functions return length rather than use int* parameter

[Denys Vlasenko]

On 02/12/2018 06:47 PM, David Miller wrote:

From: Denys Vlasenko 
Date: Mon, 12 Feb 2018 15:15:18 +0100


Before:
All these functions either return a negative error indicator,
or store length of sockaddr into "int *socklen" parameter
and return zero on success.

"int *socklen" parameter is awkward. For example, if caller does not
care, it still needs to provide on-stack storage for the value
it does not need.

None of the many FOO_getname() functions of various protocols
ever used old value of *socklen. They always just overwrite it.

This change drops this parameter, and makes all these functions, on success,
return length of sockaddr. It's always >= 0 and can be differentiated
from an error.

Tests in callers are changed from "if (err)" to "if (err < 0)", where needed.

rpc_sockname() lost "int buflen" parameter, since its only use was
to be passed to kernel_getsockname() as  and subsequently
not used in any way.

Userspace API is not changed.

 textdata bss  dec hex filename
30108430 2633624  873672 33615726 200ef6e vmlinux.before.o
30108109 2633612  873672 33615393 200ee21 vmlinux.o

Signed-off-by: Denys Vlasenko 


Please do an allmodconfig build, there are still some conversions you
missed:

security/tomoyo/network.c: In function ‘tomoyo_socket_listen_permission’:
security/tomoyo/network.c:658:19: warning: passing argument 3 of 
‘sock->ops->getname’ makes integer from pointer without a cast 
[-Wint-conversion]
 , _len, 0);
^
security/tomoyo/network.c:658:19: note: expected ‘int’ but argument is of type 
‘int *’
security/tomoyo/network.c:657:21: error: too many arguments to function 
‘sock->ops->getname’
const int error = sock->ops->getname(sock, (struct sockaddr *)
  ^~~~
fs/dlm/lowcomms.c: In function ‘lowcomms_error_report’:
fs/dlm/lowcomms.c:495:6: error: too many arguments to function 
‘kernel_getpeername’
   kernel_getpeername(con->sock, (struct sockaddr *), )) {
   ^~
fs/dlm/lowcomms.c: In function ‘tcp_accept_from_sock’:
fs/dlm/lowcomms.c:761:7: warning: passing argument 3 of ‘newsock->ops->getname’ 
makes integer from pointer without a cast [-Wint-conversion]
, 2)) {
^
fs/dlm/lowcomms.c:761:7: note: expected ‘int’ but argument is of type ‘int *’
fs/dlm/lowcomms.c:760:6: error: too many arguments to function 
‘newsock->ops->getname’
   if (newsock->ops->getname(newsock, (struct sockaddr *),
   ^~~


Sorry. Will send updated patch.
 

Re: [PATCH] net: make getname() functions return length rather than use int* parameter

[David Miller]

From: Denys Vlasenko 
Date: Mon, 12 Feb 2018 15:15:18 +0100

> Before:
> All these functions either return a negative error indicator,
> or store length of sockaddr into "int *socklen" parameter
> and return zero on success.
> 
> "int *socklen" parameter is awkward. For example, if caller does not
> care, it still needs to provide on-stack storage for the value
> it does not need.
> 
> None of the many FOO_getname() functions of various protocols
> ever used old value of *socklen. They always just overwrite it.
> 
> This change drops this parameter, and makes all these functions, on success,
> return length of sockaddr. It's always >= 0 and can be differentiated
> from an error.
> 
> Tests in callers are changed from "if (err)" to "if (err < 0)", where needed.
> 
> rpc_sockname() lost "int buflen" parameter, since its only use was
> to be passed to kernel_getsockname() as  and subsequently
> not used in any way.
> 
> Userspace API is not changed.
> 
> textdata bss  dec hex filename
> 30108430 2633624  873672 33615726 200ef6e vmlinux.before.o
> 30108109 2633612  873672 33615393 200ee21 vmlinux.o
> 
> Signed-off-by: Denys Vlasenko 

Please do an allmodconfig build, there are still some conversions you
missed:

security/tomoyo/network.c: In function ‘tomoyo_socket_listen_permission’:
security/tomoyo/network.c:658:19: warning: passing argument 3 of 
‘sock->ops->getname’ makes integer from pointer without a cast 
[-Wint-conversion]
, _len, 0);
   ^
security/tomoyo/network.c:658:19: note: expected ‘int’ but argument is of type 
‘int *’
security/tomoyo/network.c:657:21: error: too many arguments to function 
‘sock->ops->getname’
   const int error = sock->ops->getname(sock, (struct sockaddr *)
 ^~~~
fs/dlm/lowcomms.c: In function ‘lowcomms_error_report’:
fs/dlm/lowcomms.c:495:6: error: too many arguments to function 
‘kernel_getpeername’
  kernel_getpeername(con->sock, (struct sockaddr *), )) {
  ^~
fs/dlm/lowcomms.c: In function ‘tcp_accept_from_sock’:
fs/dlm/lowcomms.c:761:7: warning: passing argument 3 of ‘newsock->ops->getname’ 
makes integer from pointer without a cast [-Wint-conversion]
   , 2)) {
   ^
fs/dlm/lowcomms.c:761:7: note: expected ‘int’ but argument is of type ‘int *’
fs/dlm/lowcomms.c:760:6: error: too many arguments to function 
‘newsock->ops->getname’
  if (newsock->ops->getname(newsock, (struct sockaddr *),
  ^~~

Re: B43 driver no longer works in Linux 4.15 (bisected)

[James Hogan]

On Mon, Feb 12, 2018 at 05:08:10PM +0200, Kalle Valo wrote:
> James Hogan  writes:
> > On Mon, Feb 05, 2018 at 01:23:31PM -0500, Adric Blake wrote:
> >> I bisected to this "first bad commit:"
> >> 
> >> commit 58eae1416b804d900014d84feadda7195007cc30
> >> Author: James Hogan 
> >> Date:   Mon Jan 15 21:17:14 2018 +
> >> 
> >> ssb: Disable PCI host for PCI_DRIVERS_GENERIC
> >
> > Yes, really sorry about that and thanks for going to the effort of
> > bisecting. There is a patch here:
> > https://patchwork.kernel.org/patch/10185397/
> >
> > which is applied to linux-next as commit
> > a9e6d44ddeccd3522670e641f1ed9b068e746ff7, and is tagged for stable,
> > though I've just noticed the stable email address is incorrect... I'll
> > make sure it gets applied to the 4.15 stable branch though as soon as
> > I notice its merged.
> 
> The commit is now in v4.16-rc1.

Yes, thanks,

Greg: Please can commit a9e6d44ddeccd3522670e641f1ed9b068e746ff7 ("ssb:
Do not disable PCI host on non-Mips") be applied to 4.15 stable (the
wrong stable email address was Cc'd in the commit message).

Thanks
James


signature.asc
Description: Digital signature

Re: [PATCH] ath9k: fix DFS detector synchronization

[Zefir Kurtisi]

On 02/12/2018 01:44 PM, Kalle Valo wrote:
> Timothy Redaelli  writes:
> 
>> On Fri, 09 Feb 2018 10:01:09 +0200
>> Kalle Valo  wrote:
>>
>>> Timothy Redaelli  writes:
>>>
 The code currently syncronize the DFS region only if curchan != 0,
 but hostapd launch DFS before the channel is set and so
 set_dfs_domain is never executed.

 CC: Felix Fietkau 
 Signed-off-by: Timothy Redaelli   
>>>
>>> What kind of bug does this fix? Please describe the symptoms from
>>> user's point of view.
>>
>> With the current code radar detection (CAC) doesn't work on ath9k
>> since "dpd_set_domain" is only called once with NL80211_DFS_UNSET (0) as
>> region and so "dpd_add_pulse" always returns true (radar detected)
>> without doing a real scan.
>>
>> You can test it easily with a kernel built with
>> CONFIG_ATH9K_DFS_CERTIFIED and by using a simple hostapd configuration:
>>
>> interface=wlp1s0
>> hw_mode=a
>> channel=acs_survey
>> chanlist=100 104 108 112 116 120 124 128 132 136 140
>> ieee80211d=1
>> ieee80211h=1
>> country_code=US
>> ieee80211n=1
>> wmm_enabled=1
>> ssid=testwifi
> 
> Any ideas what broke this? Or has it never worked with FCC (US)?
> 
> Anyway, please add this info to the commit log and submit v2.
> 

Hi,

the idea / reasoning behind setting the DFS detector's initial regulatory domain
to UNSET is a fail-safe mechanism to ensure a proper countrycode is set before 
the
CAC is initiated.

It used to work for a long time, but might broke when the regdb was moved into 
the
kernel and with that the initialization order between channel and regulatory
domain changed.


Not tested, but patch looks sane.

Re: B43 driver no longer works in Linux 4.15 (bisected)

[Kalle Valo]

James Hogan  writes:

> Hi Adric,
>
> On Mon, Feb 05, 2018 at 01:23:31PM -0500, Adric Blake wrote:
>> In the time between Linux 4.15-rc8 and -rc9, my wireless driver, b43,
>> would no longer load automatically. When I modprobe the b43 (and ssb)
>> modules, the device still didn't appear in NetworkManager. Comparing
>> the kernel logs between working (4.14.16-lts) and nonworking (4.15)
>> kernels reveals that there is zero output from the ssb module, and no
>> devices recognized by the b43 driver:
>
> ...
>
>> I had my suspicions at this point, but I had a lull and decided to
>> bisect it anyways.
>> I bisected to this "first bad commit:"
>> 
>> commit 58eae1416b804d900014d84feadda7195007cc30
>> Author: James Hogan 
>> Date:   Mon Jan 15 21:17:14 2018 +
>> 
>> ssb: Disable PCI host for PCI_DRIVERS_GENERIC
>
> Yes, really sorry about that and thanks for going to the effort of
> bisecting. There is a patch here:
> https://patchwork.kernel.org/patch/10185397/
>
> which is applied to linux-next as commit
> a9e6d44ddeccd3522670e641f1ed9b068e746ff7, and is tagged for stable,
> though I've just noticed the stable email address is incorrect... I'll
> make sure it gets applied to the 4.15 stable branch though as soon as
> I notice its merged.

The commit is now in v4.16-rc1.

-- 
Kalle Valo

[PATCH] net: make getname() functions return length rather than use int* parameter

[Denys Vlasenko]

Before:
All these functions either return a negative error indicator,
or store length of sockaddr into "int *socklen" parameter
and return zero on success.

"int *socklen" parameter is awkward. For example, if caller does not
care, it still needs to provide on-stack storage for the value
it does not need.

None of the many FOO_getname() functions of various protocols
ever used old value of *socklen. They always just overwrite it.

This change drops this parameter, and makes all these functions, on success,
return length of sockaddr. It's always >= 0 and can be differentiated
from an error.

Tests in callers are changed from "if (err)" to "if (err < 0)", where needed.

rpc_sockname() lost "int buflen" parameter, since its only use was
to be passed to kernel_getsockname() as  and subsequently
not used in any way.

Userspace API is not changed.

textdata bss  dec hex filename
30108430 2633624  873672 33615726 200ef6e vmlinux.before.o
30108109 2633612  873672 33615393 200ee21 vmlinux.o

Signed-off-by: Denys Vlasenko 
CC: David S. Miller 
CC: linux-ker...@vger.kernel.org
CC: net...@vger.kernel.org
CC: linux-blueto...@vger.kernel.org
CC: linux-decnet-u...@lists.sourceforge.net
CC: linux-wireless@vger.kernel.org
CC: linux-r...@vger.kernel.org
CC: linux-s...@vger.kernel.org
CC: linux-...@vger.kernel.org
CC: linux-...@vger.kernel.org
---
 drivers/isdn/mISDN/socket.c|  5 ++---
 drivers/net/ppp/pppoe.c|  6 ++
 drivers/net/ppp/pptp.c |  6 ++
 drivers/scsi/iscsi_tcp.c   | 14 +++---
 drivers/soc/qcom/qmi_interface.c   |  3 +--
 drivers/staging/ipx/af_ipx.c   |  6 ++
 drivers/staging/irda/net/af_irda.c |  8 +++-
 include/linux/net.h|  8 +++-
 include/net/inet_common.h  |  2 +-
 include/net/ipv6.h |  2 +-
 include/net/sock.h |  2 +-
 net/appletalk/ddp.c|  5 ++---
 net/atm/pvc.c  |  5 ++---
 net/atm/svc.c  |  5 ++---
 net/ax25/af_ax25.c |  4 ++--
 net/bluetooth/hci_sock.c   |  4 ++--
 net/bluetooth/l2cap_sock.c |  5 ++---
 net/bluetooth/rfcomm/sock.c|  5 ++---
 net/bluetooth/sco.c|  5 ++---
 net/can/raw.c  |  6 ++
 net/core/sock.c|  5 +++--
 net/decnet/af_decnet.c |  6 ++
 net/ipv4/af_inet.c |  5 ++---
 net/ipv6/af_inet6.c|  5 ++---
 net/iucv/af_iucv.c |  5 ++---
 net/l2tp/l2tp_ip.c |  5 ++---
 net/l2tp/l2tp_ip6.c|  5 ++---
 net/l2tp/l2tp_ppp.c|  5 ++---
 net/llc/af_llc.c   |  5 ++---
 net/netlink/af_netlink.c   |  5 ++---
 net/netrom/af_netrom.c |  9 +
 net/nfc/llcp_sock.c|  5 ++---
 net/packet/af_packet.c | 10 --
 net/phonet/socket.c|  5 ++---
 net/qrtr/qrtr.c|  5 ++---
 net/rds/af_rds.c   |  5 ++---
 net/rds/tcp.c  |  7 ++-
 net/rose/af_rose.c |  5 ++---
 net/sctp/ipv6.c|  8 
 net/smc/af_smc.c   |  7 +++
 net/socket.c   | 35 +--
 net/sunrpc/clnt.c  |  6 +++---
 net/sunrpc/svcsock.c   | 13 -
 net/sunrpc/xprtsock.c  |  3 +--
 net/tipc/socket.c  |  5 ++---
 net/unix/af_unix.c | 10 +-
 net/vmw_vsock/af_vsock.c   |  4 ++--
 net/x25/af_x25.c   |  4 ++--
 48 files changed, 132 insertions(+), 171 deletions(-)

diff --git a/drivers/isdn/mISDN/socket.c b/drivers/isdn/mISDN/socket.c
index c5603d1a07d6..1f8f489b4167 100644
--- a/drivers/isdn/mISDN/socket.c
+++ b/drivers/isdn/mISDN/socket.c
@@ -560,7 +560,7 @@ data_sock_bind(struct socket *sock, struct sockaddr *addr, 
int addr_len)
 
 static int
 data_sock_getname(struct socket *sock, struct sockaddr *addr,
- int *addr_len, int peer)
+ int peer)
 {
struct sockaddr_mISDN   *maddr = (struct sockaddr_mISDN *) addr;
struct sock *sk = sock->sk;
@@ -570,14 +570,13 @@ data_sock_getname(struct socket *sock, struct sockaddr 
*addr,
 
lock_sock(sk);
 
-   *addr_len = sizeof(*maddr);
maddr->family = AF_ISDN;
maddr->dev = _pms(sk)->dev->id;
maddr->channel = _pms(sk)->ch.nr;
maddr->sapi = _pms(sk)->ch.addr & 0xff;
maddr->tei = (_pms(sk)->ch.addr >> 8) & 0xff;
release_sock(sk);
-   return 0;
+   return sizeof(*maddr);
 }
 
 static const struct proto_ops data_sock_ops = {
diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
index 5aa59f41bf8c..bd89d1c559ce 100644
--- a/drivers/net/ppp/pppoe.c
+++ b/drivers/net/ppp/pppoe.c
@@ 

Make brcmfmac repeat authentication requests

[Daniel Drake]

Hi,

We are working with the Weibu F3C MiniPC which includes BCM43455 SDIO
wifi chip 0x004345(17221) rev 0x06

Testing Linux 4.15, this wifi adapter is unable to authenticate with
the MF928 MiFi Access Point which is common in Africa. The STA sends
the authentication request, which is ACKed by the AP, but then the
conversation ends there (a timeout later bubbles up to userspace).
Windows 10 with broadcom driver version 1.605.1.0 is also unable to
connect.

My laptop with ath10k can authenticate and connect fine. There the
conversation is:

1. STA sends authentication request
2. AP sends ACK
3. After 0.1s timeout, STA sends another auth request
4. AP sends ACK
5. AP sends authentication response
6. etc.

Also confirmed the same pattern on a couple of smartphones, where the
delay seems to be 0.3s before repeating the authentication request.

Clearly this AP is not behaving correctly; the authentication request
should not have to be repeated. However of all the devices to hand,
unfortunately only this broadcom device is unable to connect.

Is there a way to adjust the driver/firmware to repeat the
authentication requests when they are not responded to? This would
match the behaviour of other devices and work around this issue.

Thanks
Daniel

Re: [PATCH v2 00/10] rtlwifi: add more materials for 8822be

[Kalle Valo]

Pkshih  writes:

> On Mon, 2018-01-29 at 11:26 +0800, pks...@realtek.com wrote:
>> From: Ping-Ke Shih 
>> 
>> I continue to submit more materials needed by 8822be. A special patch is
>> "PATCH 10/10" that add new files to support 8822be btcoex in case wifi
>> only. In my plan, 8822be btcoex for combo card will be sumitted in next
>> patchset.
>> 
>> v2: Add 'Acked-by: Larry Finger' if the commits are acked
>> Use 'switch...case' to replace verbose 'if...else if...else if...else'
>> Use extern declaration to quiet sparse warnings
>> 
>> Ping-Ke Shih (10):
>>   rtlwifi: enable mac80211 fast-tx support
>>   rtlwifi: Add Support VHT to spec_ver
>>   rtlwifi: Use 6 bits as sequence number of TX report
>>   rtlwifi: Extend tx_power_by_rate_offset size for newer IC
>>   rtlwifi: Add rate section and its related definition and comment
>>   rtlwifi: Fix VHT NSS in RC
>>   rtlwifi: add definition radio_mask for RF and maximum bandwidth
>>   rtlwifi: add efuse ops for other components
>>   rtlwifi: btcoex: add routine to set default port id
>>   rtlwifi: btcoex: Add 8822be btcoex supported files for wifi only

[...]

> Do you have any comment with this patchset that is pending for 2 weeks?

Normally I don't review or apply patches during when the merge window is
open, only exception being important fixes going to wireless-drivers
tree.

Also read this: 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#checking_state_of_patches_from_patchwork

-- 
Kalle Valo

Re: [PATCH] ath9k: fix DFS detector synchronization

[Kalle Valo]

Timothy Redaelli  writes:

> On Fri, 09 Feb 2018 10:01:09 +0200
> Kalle Valo  wrote:
>
>> Timothy Redaelli  writes:
>> 
>> > The code currently syncronize the DFS region only if curchan != 0,
>> > but hostapd launch DFS before the channel is set and so
>> > set_dfs_domain is never executed.
>> >
>> > CC: Felix Fietkau 
>> > Signed-off-by: Timothy Redaelli   
>> 
>> What kind of bug does this fix? Please describe the symptoms from
>> user's point of view.
>
> With the current code radar detection (CAC) doesn't work on ath9k
> since "dpd_set_domain" is only called once with NL80211_DFS_UNSET (0) as
> region and so "dpd_add_pulse" always returns true (radar detected)
> without doing a real scan.
>
> You can test it easily with a kernel built with
> CONFIG_ATH9K_DFS_CERTIFIED and by using a simple hostapd configuration:
>
> interface=wlp1s0
> hw_mode=a
> channel=acs_survey
> chanlist=100 104 108 112 116 120 124 128 132 136 140
> ieee80211d=1
> ieee80211h=1
> country_code=US
> ieee80211n=1
> wmm_enabled=1
> ssid=testwifi

Any ideas what broke this? Or has it never worked with FCC (US)?

Anyway, please add this info to the commit log and submit v2.

-- 
Kalle Valo

Re: [PATCH] headers: untangle kmemleak.h from mm.h

[Michael Ellerman]

Randy Dunlap  writes:

> From: Randy Dunlap 
>
> Currently  #includes  for no obvious
> reason. It looks like it's only a convenience, so remove kmemleak.h
> from slab.h and add  to any users of kmemleak_*
> that don't already #include it.
> Also remove  from source files that do not use it.
>
> This is tested on i386 allmodconfig and x86_64 allmodconfig. It
> would be good to run it through the 0day bot for other $ARCHes.
> I have neither the horsepower nor the storage space for the other
> $ARCHes.
>
> [slab.h is the second most used header file after module.h; kernel.h
> is right there with slab.h. There could be some minor error in the
> counting due to some #includes having comments after them and I
> didn't combine all of those.]
>
> This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
> header files).
>
> Signed-off-by: Randy Dunlap 

I threw it at a random selection of configs and so far the only failures
I'm seeing are:

  lib/test_firmware.c:134:2: error: implicit declaration of function 'vfree' 
[-Werror=implicit-function-declaration] 
 
  lib/test_firmware.c:620:25: error: implicit declaration of function 'vzalloc' 
[-Werror=implicit-function-declaration]
  lib/test_firmware.c:620:2: error: implicit declaration of function 'vzalloc' 
[-Werror=implicit-function-declaration]
  security/integrity/digsig.c:146:2: error: implicit declaration of function 
'vfree' [-Werror=implicit-function-declaration]

Full results trickling in here, not all the failures there are caused by
this patch, ie. some configs are broken in mainline:

  http://kisskb.ellerman.id.au/kisskb/head/13396/

cheers