* [PATCH 1/1] linux-wireless: Added psk in struct cfg80211_connect_params needed for offloading 4way handshake to driver
From: Gautam (Gautam Kumar) Shukla @ 2014-11-11 5:56 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jithu Jance,
Sreenath S
For offloading 4 way handshake to driver, currently we don't have any member of struct cfg80211_connect_params to pass PSK from supplicant to driver. I have added psk for the same and added rest of the code needed in nl80211.h and nl80211.c to parse and make it available to driver.
From supplicant, we already have psk member field in assoc_params to use .
Tested on x86 linux.
Signed-off-by: Gautam kumar shukla <gautams-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
---
include/net/cfg80211.h | 2 ++
include/uapi/linux/nl80211.h | 8 +++++++-
net/wireless/nl80211.c | 4 ++++
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index a2ddcf2..6f744e0 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1758,6 +1758,7 @@ struct cfg80211_ibss_params {
* allowed to ignore this @bssid_hint if it has knowledge of a better BSS
* to use.
* @ssid: SSID
+ * @psk:preshared key for WPA2-PSK connection or %NULL if not specified
* @ssid_len: Length of ssid in octets
* @auth_type: Authentication type (algorithm)
* @ie: IEs for association request
@@ -1783,6 +1784,7 @@ struct cfg80211_connect_params {
const u8 *bssid;
const u8 *bssid_hint;
const u8 *ssid;
+ const u8 *psk;
size_t ssid_len;
enum nl80211_auth_type auth_type;
const u8 *ie;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h index 4b28dc0..b01d5dd 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -421,7 +421,7 @@
* %NL80211_ATTR_MAC, %NL80211_ATTR_WIPHY_FREQ, %NL80211_ATTR_CONTROL_PORT,
* %NL80211_ATTR_CONTROL_PORT_ETHERTYPE,
* %NL80211_ATTR_CONTROL_PORT_NO_ENCRYPT, %NL80211_ATTR_MAC_HINT, and
- * %NL80211_ATTR_WIPHY_FREQ_HINT.
+ * %NL80211_ATTR_WIPHY_FREQ_HINT, and %NL80211_ATTR_PSK.
* If included, %NL80211_ATTR_MAC and %NL80211_ATTR_WIPHY_FREQ are
* restrictions on BSS selection, i.e., they effectively prevent roaming
* within the ESS. %NL80211_ATTR_MAC_HINT and %NL80211_ATTR_WIPHY_FREQ_HINT @@ -1638,6 +1638,10 @@ enum nl80211_commands {
* @NL80211_ATTR_SMPS_MODE: SMPS mode to use (ap mode). see
* &enum nl80211_smps_mode.
*
+ * @NL80211_ATTR_PSK: a PSK value (u8 attribute).This is 32-octet
+ (256-bit)
+ * PSK.
+ *
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -1990,6 +1994,8 @@ enum nl80211_attrs {
NL80211_ATTR_SMPS_MODE,
+ NL80211_ATTR_PSK,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index 5839c85..91c24b1 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -395,6 +395,7 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
[NL80211_ATTR_USER_PRIO] = { .type = NLA_U8 },
[NL80211_ATTR_ADMITTED_TIME] = { .type = NLA_U16 },
[NL80211_ATTR_SMPS_MODE] = { .type = NLA_U8 },
+ [NL80211_ATTR_PSK] = { .type = NLA_BINARY, .len = 32 },
};
/* policy for the key attributes */
@@ -7310,6 +7311,9 @@ static int nl80211_connect(struct sk_buff *skb, struct genl_info *info)
connect.flags |= ASSOC_REQ_USE_RRM;
}
+ if (info->attrs[NL80211_ATTR_PSK])
+ connect.psk = nla_data(info->attrs[NL80211_ATTR_PSK]);
+
wdev_lock(dev->ieee80211_ptr);
err = cfg80211_connect(rdev, dev, &connect, connkeys, NULL);
wdev_unlock(dev->ieee80211_ptr);
--
1.9.1
^ permalink raw reply
* Re: [PATCH v4 10/25] virtio: add API to enable VQs early
From: Michael S. Tsirkin @ 2014-11-11 6:15 UTC (permalink / raw)
To: Andy Grover
Cc: linux-s390, kvm, linux-scsi, Christian Borntraeger, netdev,
linux-kernel, virtualization, Paolo Bonzini, Amit Shah,
v9fs-developer, David S. Miller
In-Reply-To: <54615C15.6060400@redhat.com>
On Mon, Nov 10, 2014 at 04:45:09PM -0800, Andy Grover wrote:
> On 10/13/2014 12:50 AM, Michael S. Tsirkin wrote:
> >virtio spec 0.9.X requires DRIVER_OK to be set before
> >VQs are used, but some drivers use VQs before probe
> >function returns.
> >Since DRIVER_OK is set after probe, this violates the spec.
> >
> >Even though under virtio 1.0 transitional devices support this
> >behaviour, we want to make it possible for those early callers to become
> >spec compliant and eventually support non-transitional devices.
> >
> >Add API for drivers to call before using VQs.
> >
> >Sets DRIVER_OK internally.
> >
> >Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> >Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
> >---
> > include/linux/virtio_config.h | 17 +++++++++++++++++
> > 1 file changed, 17 insertions(+)
> >
> >diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h
> >index e8f8f71..e36403b 100644
> >--- a/include/linux/virtio_config.h
> >+++ b/include/linux/virtio_config.h
> >@@ -109,6 +109,23 @@ struct virtqueue *virtio_find_single_vq(struct virtio_device *vdev,
> > return vq;
> > }
> >
> >+/**
> >+ * virtio_device_ready - enable vq use in probe function
> >+ * @vdev: the device
> >+ *
> >+ * Driver must call this to use vqs in the probe function.
> >+ *
> >+ * Note: vqs are enabled automatically after probe returns.
> >+ */
> >+static inline
> >+void virtio_device_ready(struct virtio_device *dev)
> >+{
> >+ unsigned status = dev->config->get_status(dev);
> >+
> >+ BUG_ON(status & VIRTIO_CONFIG_S_DRIVER_OK);
> >+ dev->config->set_status(dev, status | VIRTIO_CONFIG_S_DRIVER_OK);
> >+}
>
> Getting a BUG when booting via KVM, host Fedora 20, guest Fedora 20.
>
> my config is at:
>
> https://fedorapeople.org/~grover/config-20141110
>
The fix is here:
http://article.gmane.org/gmane.linux.kernel.virtualization/23324/raw
I'm surprised it's not merged yet.
Rusty, could you pick it up please?
>
> [ 0.828494] ------------[ cut here ]------------
> [ 0.829039] kernel BUG at
> /home/agrover/git/kernel/include/linux/virtio_config.h:125!
> [ 0.831266] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
> [ 0.831266] Modules linked in:
> [ 0.831266] CPU: 1 PID: 30 Comm: kworker/1:1 Not tainted 3.18.0-rc4 #120
> [ 0.831266] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [ 0.831266] Workqueue: events control_work_handler
> [ 0.831266] task: ffff88003cd98000 ti: ffff88003cd94000 task.ti:
> ffff88003cd94000
> [ 0.831266] RIP: 0010:[<ffffffff81445004>] [<ffffffff81445004>]
> add_port+0x264/0x410
> [ 0.831266] RSP: 0000:ffff88003cd97c78 EFLAGS: 00010202
> [ 0.831266] RAX: 0000000000000007 RBX: ffff88003c58c400 RCX:
> 0000000000000001
> [ 0.831266] RDX: 000000000000c132 RSI: ffffffff81a955e9 RDI:
> 000000000001c132
> [ 0.831266] RBP: ffff88003cd97cc8 R08: 0000000000000000 R09:
> 0000000000000000
> [ 0.831266] R10: 0000000000000001 R11: 0000000000000000 R12:
> ffff88003c58be00
> [ 0.831266] R13: 0000000000000001 R14: ffff8800395ca800 R15:
> ffff88003c58c420
> [ 0.831266] FS: 0000000000000000(0000) GS:ffff88003fa00000(0000)
> knlGS:0000000000000000
> [ 0.831266] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 0.831266] CR2: 0000000000000000 CR3: 0000000001c11000 CR4:
> 00000000000006e0
> [ 0.831266] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [ 0.831266] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
> 0000000000000400
> [ 0.831266] Stack:
> [ 0.831266] ffff880000000001 0000000000000292 0000000000000000
> 0000000000000001
> [ 0.831266] ffff88003cd97cc8 ffff88003dfa8a20 ffff88003c58beb8
> ffff88003c58be10
> [ 0.831266] ffff8800395a2000 0000000000000000 ffff88003cd97d38
> ffffffff8144531a
> [ 0.831266] Call Trace:
> [ 0.831266] [<ffffffff8144531a>] control_work_handler+0x16a/0x3c0
> [ 0.831266] [<ffffffff8108b0c8>] ? process_one_work+0x208/0x500
> [ 0.831266] [<ffffffff8108b16c>] process_one_work+0x2ac/0x500
> [ 0.831266] [<ffffffff8108b0c8>] ? process_one_work+0x208/0x500
> [ 0.831266] [<ffffffff8108b68e>] worker_thread+0x2ce/0x4e0
> [ 0.831266] [<ffffffff8108b3c0>] ? process_one_work+0x500/0x500
> [ 0.831266] [<ffffffff81090b28>] kthread+0xf8/0x100
> [ 0.831266] [<ffffffff810bad7d>] ? trace_hardirqs_on+0xd/0x10
> [ 0.831266] [<ffffffff81090a30>] ? kthread_stop+0x140/0x140
> [ 0.831266] [<ffffffff816ea92c>] ret_from_fork+0x7c/0xb0
> [ 0.831266] [<ffffffff81090a30>] ? kthread_stop+0x140/0x140
> [ 0.831266] Code: c7 c2 48 31 01 83 48 c7 c6 e9 55 a9 81 e8 55 b4 c6 ff
> 4d 8b b4 24 58 01 00 00 49 8b 86 e8 04 00 00 4c 89 f7 ff 50 10 a8 04 74 0c
> <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 49 8b 96 e8 04 00 00 83 c8
> [ 0.831266] RIP [<ffffffff81445004>] add_port+0x264/0x410
> [ 0.831266] RSP <ffff88003cd97c78>
> [ 0.878202] ---[ end trace f98fbb172cc7bbf4 ]---
>
> Thanks -- Andy
^ permalink raw reply
* [PATCH 2/2] linux-wireless:Added wiphy capability flag for offloading 4way handshake to driver
From: Gautam (Gautam Kumar) Shukla @ 2014-11-11 6:27 UTC (permalink / raw)
To: linville@tuxdriver.com
Cc: linux-wireless@vger.kernel.org, johannes@sipsolutions.net,
davem@davemloft.net, linux-api@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Jithu Jance,
Sreenath S
For offloading 4 way handshake to driver , currently we don't have WIPHY capability flag to communicate same to supplicant.
I have added the flag NL80211_ATTR_4WAY_KEY_HANDSHAKE and rest of the code for the same.
Tested on x86 linux machine
Signed-off-by: Gautam kumar shukla <gautams@broadcom.com>
---
include/net/cfg80211.h | 4 ++++
include/uapi/linux/nl80211.h | 5 ++++-
net/wireless/nl80211.c | 4 ++++
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 6f744e0..b37de0a 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2629,7 +2629,10 @@ struct cfg80211_ops {
* TSPEC sessions (TID aka TSID 0-7) with the NL80211_CMD_ADD_TX_TS
* command. Standard IEEE 802.11 TSPEC setup is not yet supported, it
* needs to be able to handle Block-Ack agreements and other things.
+ * @WIPHY_FLAG_SUPPORTS_4WAY_HANDHSHAKE:the device supports 4way handshake
+ * in the driver/firmware.
*/
+
enum wiphy_flags {
WIPHY_FLAG_SUPPORTS_WMM_ADMISSION = BIT(0),
/* use hole at 1 */
@@ -2654,6 +2657,7 @@ enum wiphy_flags {
WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL = BIT(21),
WIPHY_FLAG_SUPPORTS_5_10_MHZ = BIT(22),
WIPHY_FLAG_HAS_CHANNEL_SWITCH = BIT(23),
+ WIPHY_FLAG_SUPPORTS_4WAY_HANDSHAKE = BIT(24),
};
/**
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index b01d5dd..2c474a3 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1640,9 +1640,11 @@ enum nl80211_commands {
*
* @NL80211_ATTR_PSK: a PSK value (u8 attribute).This is 32-octet (256-bit)
* PSK.
+ * @NL80211_ATTR_4WAY_KEY_HANDSHAKE: Indicates whether the driver is capable
+ * of 4way key handshake
*
*
- * @NL80211_ATTR_MAX: highest attribute number currently defined
+ * * @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
enum nl80211_attrs {
@@ -1995,6 +1997,7 @@ enum nl80211_attrs {
NL80211_ATTR_SMPS_MODE,
NL80211_ATTR_PSK,
+ NL80211_ATTR_4WAY_KEY_HANDSHAKE,
/* add attributes here, update the policy in nl80211.c */
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 91c24b1..5f85c41 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -396,6 +396,7 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
[NL80211_ATTR_ADMITTED_TIME] = { .type = NLA_U16 },
[NL80211_ATTR_SMPS_MODE] = { .type = NLA_U8 },
[NL80211_ATTR_PSK] = { .type = NLA_BINARY, .len = 32 },
+ [NL80211_ATTR_4WAY_KEY_HANDSHAKE] = { .type = NLA_FLAG },
};
/* policy for the key attributes */
@@ -1303,6 +1304,9 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
if ((rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_FW_ROAM) &&
nla_put_flag(msg, NL80211_ATTR_ROAM_SUPPORT))
goto nla_put_failure;
+ if ((rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_4WAY_HANDSHAKE) &&
+ nla_put_flag(msg,NL80211_ATTR_4WAY_KEY_HANDSHAKE))
+ goto nla_put_failure;
if ((rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_TDLS) &&
nla_put_flag(msg, NL80211_ATTR_TDLS_SUPPORT))
goto nla_put_failure;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] usbnet: smsc95xx: dereferencing NULL pointer
From: Sudip Mukherjee @ 2014-11-11 6:30 UTC (permalink / raw)
To: David Miller; +Cc: steve.glendinning, netdev, linux-usb, linux-kernel
In-Reply-To: <20141110.142223.816257623301941276.davem@davemloft.net>
On Mon, Nov 10, 2014 at 02:22:23PM -0500, David Miller wrote:
> From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
> Date: Fri, 7 Nov 2014 18:52:40 +0530
>
> > we were dereferencing dev to initialize pdata. but just after that we
> > have a BUG_ON(!dev). so we were basically dereferencing the pointer
> > first and then tesing it for NULL.
> >
> > Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
>
> You didn't even compile test this.
>
> Do not even bother fixing theoretical issues if you're going to be
> introducing a _REAL_ serious regression into the code with your "fix":
>
> drivers/net/usb/smsc95xx.c: In function ‘smsc95xx_resume’:
> drivers/net/usb/smsc95xx.c:1674:5: warning: ‘pdata’ is used uninitialized in this function [-Wuninitialized]
> u8 suspend_flags = pdata->suspend_flags;
> ^
>
> So, instead of a theoretical issue, we now have a real guaranteed
> crash.
>
> You did not compile test this change, and you definitely did not
> functionally test this change either.
>
> Please do not do this ever again, thanks.
extremely sorry for this.
i have compile tested but don't know how i missed the new warning message.
for any of my patch,if for some reason i am not able to compile test it, i mention that in the comments.
sorry again.
thanks
sudip
^ permalink raw reply
* Re: Face some error after applying commit 7dfa4b414d4(net/mlx4_en: Code cleanups in tx path)
From: Or Gerlitz @ 2014-11-11 6:49 UTC (permalink / raw)
To: Wei Yang
Cc: Amir Vadai, Eric Dumazet, Eric Dumazet, David Miller,
Linux Netdev List
In-Reply-To: <20141111015705.GA8470@richard>
On Tue, Nov 11, 2014 at 3:57 AM, Wei Yang <weiyang@linux.vnet.ibm.com> wrote:
>>Please send me the module parameters you used when loading mlx4_core, a
>>full dmesg with both mlx4_core and mlx4_en loading.
>
> The command line I use is:
> modprobe mlx4_core num_vfs=1 probe_vf=1 port_type_array=2,2
>
> The log I sent in the first mail is the full log, including the CQE error, one
> warning in watchdog, and then print the CQE error periodicly. What else
> message you would like me to capture?
>
> And this error is reported from VF always. After the error, the other network
> interface seems can't function.
Guys, do we have here something which isn't bisectable (i.e the code
doesn't work if you force it to an arbitrary commit within in the
chain) - something which doesn't work as a whole? in case the former,
we will work to do better next times.. in case the latter, Wei, as
Amir asked, please send us full logs when you load/run the driver with
debug level set, for mlx4_core it would be loading with debug_level=1
for mlx4_en you should be able to raise the debug level using ethtool
Or.
^ permalink raw reply
* Re: [patch net-next] bridge: rename fdb_*_hw to fdb_*_hw_addr to avoid confusion
From: Jiri Pirko @ 2014-11-11 7:20 UTC (permalink / raw)
To: David Miller
Cc: netdev, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl
In-Reply-To: <20141110.213306.1167288435677960869.davem@davemloft.net>
Tue, Nov 11, 2014 at 03:33:06AM CET, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.us>
>Date: Sun, 9 Nov 2014 17:40:16 +0100
>
>> The current name might seem that this actually offloads the fdb entry to
>> hw. So rename it to clearly present that this for hardware address
>> addition/removal.
>>
>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>
>This must have been relative to your rocket patch series because it
>doesn't apply cleanly.
>
>I already am assuming that the rocket patch set is getting one more
>spin, so why don't you add this to that series?
Will do.
>
>Thanks.
^ permalink raw reply
* Re: Face some error after applying commit 7dfa4b414d4(net/mlx4_en: Code cleanups in tx path)
From: Amir Vadai @ 2014-11-11 7:28 UTC (permalink / raw)
To: Wei Yang; +Cc: Amir Vadai, Eric Dumazet, Eric Dumazet, David Miller, netdev
In-Reply-To: <20141111015705.GA8470@richard>
On Tue, Nov 11, 2014 at 3:57 AM, Wei Yang <weiyang@linux.vnet.ibm.com> wrote:
> On Mon, Nov 10, 2014 at 10:00:21AM +0200, Amir Vadai wrote:
>>On 11/10/2014 7:40 AM, Wei Yang wrote:
>>> On Sun, Nov 09, 2014 at 06:46:14PM -0800, Eric Dumazet wrote:
>>>> On Mon, 2014-11-10 at 09:59 +0800, Wei Yang wrote:
>>>>> On Fri, Nov 07, 2014 at 07:38:15PM -0800, Eric Dumazet wrote:
>>>>>> On Fri, Nov 7, 2014 at 6:57 PM, Wei Yang <weiyang@linux.vnet.ibm.com> wrote:
>>>>>>> Eric and Amir
>>>>>>>
>>
>>[...]
>>
>>>>>
>>>>
>>>> Okay, your message was not clear : I thought you had a compilation error
>>>> on current tree.
>>>>
>>>> The true story of these patches is that Mellanox split an initial big
>>>> chunk [1] I gave into multiple patches.
>>>>
>>>> Maybe they missed that one patch did not actually compile.
>>>>
>>>> [1] https://patchwork.ozlabs.org/patch/394256/
>>>>
>>>> Now, it is done, there is nothing we can do.
>>>>
>>>> I'll let Mellanox comment, but it looks like your hardware does not like
>>>> something.
>>>>
>>>> Have you tried to disable Blue Frame ?
>>>>
>>>
>>> Yep, looks the PF works fine. But the current FW I can't just enable the PF.
>>>
>>> How to disable Blue Frame? I am not clear about this.
>>>
>>Hi,
>>
>>Lets see that we're on the same page here:
>>1. There was a compilation problem that you fixed (Yes, it was my fault
>>- I just discovered it a minute after the code was applied).
>>2. When you're using SR-IOV, during initialization, you get a CQE error
>>with syndrome 0x2 on one of the probed VF's.
>
> From the log, seems yes.
>
>>3. Regarding the BlueFlame - I don't see how it is related to the issue
>>that you see. But it is a very easy experiment. Issue: "ethtool
>>--set-priv-flags eth1 blueflame off"
>
> I tried to use this after mlx4_en is loaded, still see the CQE error.
>
>>
>>Please send me the module parameters you used when loading mlx4_core, a
>>full dmesg with both mlx4_core and mlx4_en loading.
>
> The command line I use is:
> modprobe mlx4_core num_vfs=1 probe_vf=1 port_type_array=2,2
>
> The log I sent in the first mail is the full log, including the CQE error, one
> warning in watchdog, and then print the CQE error periodicly. What else
> message you would like me to capture?
The log in the first mail has only mlx4_en logs. I would like to see
the full log, that has mlx4_core messages too. And as Or suggested,
debug_level=1 could be useful here too.
>
> And this error is reported from VF always. After the error, the other network
> interface seems can't function.
>
>>
>>Amir.
>
> --
> Richard Yang
> Help you, Help me
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Face some error after applying commit 7dfa4b414d4(net/mlx4_en: Code cleanups in tx path)
From: Wei Yang @ 2014-11-11 7:42 UTC (permalink / raw)
To: Amir Vadai
Cc: Wei Yang, Eric Dumazet, Eric Dumazet, David Miller, netdev,
gerlitz.or
In-Reply-To: <CAPcc5Ph-guxyUj96VQa1FqTsnwU3J8em4wv0E+ddYho71o0v4w@mail.gmail.com>
On Tue, Nov 11, 2014 at 09:28:34AM +0200, Amir Vadai wrote:
>On Tue, Nov 11, 2014 at 3:57 AM, Wei Yang <weiyang@linux.vnet.ibm.com> wrote:
>> On Mon, Nov 10, 2014 at 10:00:21AM +0200, Amir Vadai wrote:
>>>On 11/10/2014 7:40 AM, Wei Yang wrote:
>>>> On Sun, Nov 09, 2014 at 06:46:14PM -0800, Eric Dumazet wrote:
>>>>> On Mon, 2014-11-10 at 09:59 +0800, Wei Yang wrote:
>>>>>> On Fri, Nov 07, 2014 at 07:38:15PM -0800, Eric Dumazet wrote:
>>>>>>> On Fri, Nov 7, 2014 at 6:57 PM, Wei Yang <weiyang@linux.vnet.ibm.com> wrote:
>>>>>>>> Eric and Amir
>>>>>>>>
>>>
>>>[...]
>>>
>>>>>>
>>>>>
>>>>> Okay, your message was not clear : I thought you had a compilation error
>>>>> on current tree.
>>>>>
>>>>> The true story of these patches is that Mellanox split an initial big
>>>>> chunk [1] I gave into multiple patches.
>>>>>
>>>>> Maybe they missed that one patch did not actually compile.
>>>>>
>>>>> [1] https://patchwork.ozlabs.org/patch/394256/
>>>>>
>>>>> Now, it is done, there is nothing we can do.
>>>>>
>>>>> I'll let Mellanox comment, but it looks like your hardware does not like
>>>>> something.
>>>>>
>>>>> Have you tried to disable Blue Frame ?
>>>>>
>>>>
>>>> Yep, looks the PF works fine. But the current FW I can't just enable the PF.
>>>>
>>>> How to disable Blue Frame? I am not clear about this.
>>>>
>>>Hi,
>>>
>>>Lets see that we're on the same page here:
>>>1. There was a compilation problem that you fixed (Yes, it was my fault
>>>- I just discovered it a minute after the code was applied).
>>>2. When you're using SR-IOV, during initialization, you get a CQE error
>>>with syndrome 0x2 on one of the probed VF's.
>>
>> From the log, seems yes.
>>
>>>3. Regarding the BlueFlame - I don't see how it is related to the issue
>>>that you see. But it is a very easy experiment. Issue: "ethtool
>>>--set-priv-flags eth1 blueflame off"
>>
>> I tried to use this after mlx4_en is loaded, still see the CQE error.
>>
>>>
>>>Please send me the module parameters you used when loading mlx4_core, a
>>>full dmesg with both mlx4_core and mlx4_en loading.
>>
>> The command line I use is:
>> modprobe mlx4_core num_vfs=1 probe_vf=1 port_type_array=2,2
>>
>> The log I sent in the first mail is the full log, including the CQE error, one
>> warning in watchdog, and then print the CQE error periodicly. What else
>> message you would like me to capture?
>
>The log in the first mail has only mlx4_en logs. I would like to see
>the full log, that has mlx4_core messages too. And as Or suggested,
>debug_level=1 could be useful here too.
>
Ah, you need the log from mlx4_core too. Ok, I will do it again.
BTW, how to add the debug_level=1 in the command line? Like this?
modprobe mlx4_core num_vfs=1 probe_vf=1 port_type_array=2,2 debug_level=1
But for mlx4_en, I am not sure I could raise the debug level with ethtool,
since the ethernet driver may not work properly. Actually I am not sure how to
raise the level with ethtool. Could you give me an example?
>>
>> And this error is reported from VF always. After the error, the other network
>> interface seems can't function.
>>
>>>
>>>Amir.
>>
>> --
>> Richard Yang
>> Help you, Help me
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Richard Yang
Help you, Help me
^ permalink raw reply
* [PATCH net-next 0/3] dev_disable_lro() improvements for stacked devices
From: Michal Kubecek @ 2014-11-11 8:21 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-kernel, Jay Vosburgh, Veaceslav Falico,
Andy Gospodarek, Jiri Pirko
Large receive offloading is known to cause problems if received packets
are passed to other host. Therefore the kernel disables it by calling
dev_disable_lro() whenever a network device is enslaved in a bridge or
forwarding is enabled for it (or globally). For virtual devices we need
to disable LRO on the underlying physical device (which is actually
receiving the packets).
Current dev_disable_lro() code handles this propagation for a vlan
(including 802.1ad nested vlan), macvlan or a vlan on top of a macvlan.
This patch adds LRO disabling propagation for
- macvlan on top of a vlan or any stacked combination of those
- bonding
- teaming
In the bonding and teaming case, it is necessary to disable LRO not only
on slaves when dev_disable_lro() is called but also on any slave (port)
added later.
Michal Kubecek (3):
net: handle more general stacking in dev_disable_lro()
team: add helper to check if device is a team master
net: propagate LRO disabling to bond and team slaves
drivers/net/bonding/bond_main.c | 3 +++
drivers/net/team/team.c | 6 +++++-
include/linux/netdevice.h | 7 +++++++
net/core/dev.c | 31 ++++++++++++++++++++++---------
4 files changed, 37 insertions(+), 10 deletions(-)
--
1.8.4.5
^ permalink raw reply
* [PATCH net-next 1/3] net: handle more general stacking in dev_disable_lro()
From: Michal Kubecek @ 2014-11-11 8:21 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-kernel, Jay Vosburgh, Veaceslav Falico,
Andy Gospodarek, Jiri Pirko
In-Reply-To: <cover.1415692212.git.mkubecek@suse.cz>
Current dev_disable_lro() code passing LRO disabling to lower device
handles vlan on top of a macvlan but not the opposite. Repeat the test
until the device is neither vlan nor macvlan.
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
---
net/core/dev.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index bb09b03..ebcd308 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1437,16 +1437,21 @@ EXPORT_SYMBOL(dev_close);
*/
void dev_disable_lro(struct net_device *dev)
{
- /*
- * If we're trying to disable lro on a vlan device
- * use the underlying physical device instead
- */
- if (is_vlan_dev(dev))
- dev = vlan_dev_real_dev(dev);
+ struct net_device *prev_dev;
+
+ do {
+ prev_dev = dev;
+
+ /* If we're trying to disable lro on a vlan device
+ * use the underlying physical device instead
+ */
+ if (is_vlan_dev(dev))
+ dev = vlan_dev_real_dev(dev);
- /* the same for macvlan devices */
- if (netif_is_macvlan(dev))
- dev = macvlan_dev_real_dev(dev);
+ /* the same for macvlan devices */
+ if (netif_is_macvlan(dev))
+ dev = macvlan_dev_real_dev(dev);
+ } while (dev != prev_dev);
dev->wanted_features &= ~NETIF_F_LRO;
netdev_update_features(dev);
--
1.8.4.5
^ permalink raw reply related
* [PATCH net-next 2/3] team: add helper to check if device is a team master
From: Michal Kubecek @ 2014-11-11 8:21 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-kernel, Jay Vosburgh, Veaceslav Falico,
Andy Gospodarek, Jiri Pirko
In-Reply-To: <cover.1415692212.git.mkubecek@suse.cz>
Add flag IFF_TEAM_MASTER to recognize a team master and helper
netif_is_team_master() to check it.
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
---
drivers/net/team/team.c | 3 ++-
include/linux/netdevice.h | 7 +++++++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index 2368395..e1e2b85 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -2043,7 +2043,8 @@ static void team_setup(struct net_device *dev)
* bring us to promisc mode in case a unicast addr is added.
* Let this up to underlay drivers.
*/
- dev->priv_flags |= IFF_UNICAST_FLT | IFF_LIVE_ADDR_CHANGE;
+ dev->priv_flags |= IFF_UNICAST_FLT | IFF_LIVE_ADDR_CHANGE |
+ IFF_TEAM_MASTER;
dev->features |= NETIF_F_LLTX;
dev->features |= NETIF_F_GRO;
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 888d551..1236feb 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1203,6 +1203,7 @@ struct net_device_ops {
* @IFF_LIVE_ADDR_CHANGE: device supports hardware address
* change when it's running
* @IFF_MACVLAN: Macvlan device
+ * @IFF_TEAM_MASTER: device is a team master
*/
enum netdev_priv_flags {
IFF_802_1Q_VLAN = 1<<0,
@@ -1228,6 +1229,7 @@ enum netdev_priv_flags {
IFF_LIVE_ADDR_CHANGE = 1<<20,
IFF_MACVLAN = 1<<21,
IFF_XMIT_DST_RELEASE_PERM = 1<<22,
+ IFF_TEAM_MASTER = 1<<23,
};
#define IFF_802_1Q_VLAN IFF_802_1Q_VLAN
@@ -3638,6 +3640,11 @@ static inline bool netif_is_bond_slave(struct net_device *dev)
return dev->flags & IFF_SLAVE && dev->priv_flags & IFF_BONDING;
}
+static inline bool netif_is_team_master(struct net_device *dev)
+{
+ return dev->priv_flags & IFF_TEAM_MASTER;
+}
+
static inline bool netif_supports_nofcs(struct net_device *dev)
{
return dev->priv_flags & IFF_SUPP_NOFCS;
--
1.8.4.5
^ permalink raw reply related
* [PATCH net-next 3/3] net: propagate LRO disabling to bond and team slaves
From: Michal Kubecek @ 2014-11-11 8:22 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-kernel, Jay Vosburgh, Veaceslav Falico,
Andy Gospodarek, Jiri Pirko
In-Reply-To: <cover.1415692212.git.mkubecek@suse.cz>
As LRO doesn't work correctly if incoming packets are passed to other
hosts, it needs to be disabled if a device is enslaved into a bridge or
forwarding is enabled for it.
For a bond/team master, LRO needs to be disabled for all its slaves as
they are actually receiving the packets. Once LRO is disabled for
a bond/team master, we also need to make sure to disable it for newly
added slaves.
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
---
drivers/net/bonding/bond_main.c | 3 +++
drivers/net/team/team.c | 3 +++
net/core/dev.c | 8 ++++++++
3 files changed, 14 insertions(+)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index b9b3456..8575fee 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1526,6 +1526,9 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
}
#endif
+ if (!(bond_dev->features & NETIF_F_LRO))
+ dev_disable_lro(slave_dev);
+
res = netdev_rx_handler_register(slave_dev, bond_handle_frame,
new_slave);
if (res) {
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index e1e2b85..217b973 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -1179,6 +1179,9 @@ static int team_port_add(struct team *team, struct net_device *port_dev)
goto err_enable_netpoll;
}
+ if (!(dev->features & NETIF_F_LRO))
+ dev_disable_lro(port_dev);
+
err = netdev_rx_handler_register(port_dev, team_handle_frame,
port);
if (err) {
diff --git a/net/core/dev.c b/net/core/dev.c
index ebcd308..b132f44 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1438,6 +1438,8 @@ EXPORT_SYMBOL(dev_close);
void dev_disable_lro(struct net_device *dev)
{
struct net_device *prev_dev;
+ struct net_device *lower_dev;
+ struct list_head *iter;
do {
prev_dev = dev;
@@ -1458,6 +1460,12 @@ void dev_disable_lro(struct net_device *dev)
if (unlikely(dev->features & NETIF_F_LRO))
netdev_WARN(dev, "failed to disable LRO!\n");
+
+ /* if dev is a bond/team master, disable LRO for all its slaves */
+ if (netif_is_bond_master(dev) || netif_is_team_master(dev)) {
+ netdev_for_each_lower_dev(dev, lower_dev, iter)
+ dev_disable_lro(lower_dev);
+ }
}
EXPORT_SYMBOL(dev_disable_lro);
--
1.8.4.5
^ permalink raw reply related
* Re: [PATCH V1 net-next] net/fm10k: Avoid double setting of NETIF_F_SG for the HW encapsulation feature mask
From: Jeff Kirsher @ 2014-11-11 8:25 UTC (permalink / raw)
To: Or Gerlitz; +Cc: netdev
In-Reply-To: <1415520822-11922-1-git-send-email-ogerlitz@mellanox.com>
[-- Attachment #1: Type: text/plain, Size: 457 bytes --]
On Sun, 2014-11-09 at 10:13 +0200, Or Gerlitz wrote:
> The networking core does it for the driver during registration time.
>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
> ---
>
> changes from v0:
> - set alignment to be per the request of Matthew Vick
>
>
> drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 13 ++++++-------
> 1 files changed, 6 insertions(+), 7 deletions(-)
Thanks Or, I have added your patch to my queue.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [net-next PATCH] ixgbe: Remove IXGBE_FLAG_IN_NETPOLL since it doesn't do anything
From: Jeff Kirsher @ 2014-11-11 8:26 UTC (permalink / raw)
To: Alexander Duyck; +Cc: netdev, donald.c.skidmore, davem
In-Reply-To: <20141110224922.7245.35078.stgit@ahduyck-vm-fedora20>
[-- Attachment #1: Type: text/plain, Size: 759 bytes --]
On Mon, 2014-11-10 at 14:50 -0800, Alexander Duyck wrote:
> This patch removes some dead code from the cleanup path for ixgbe.
>
> Setting and clearing the flag doesn't do anything since all we are
> doing is
> setting the flag, scheduling napi, clearing the flag and then letting
> netpoll do the polling cleanup. As such it doesn't make much sense to
> have
> it there.
>
> This patch also removes one minor white-space error.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 -
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 16 ++++------------
> 2 files changed, 4 insertions(+), 13 deletions(-)
Thanks Alex, I have added your patch to my queue.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] net: s6gmac: remove driver
From: Paul Bolle @ 2014-11-11 8:32 UTC (permalink / raw)
To: David Miller; +Cc: Valentin Rothberg, jcmvbkbc, dg, netdev, linux-kernel
In-Reply-To: <20141019.132801.424495087167944921.davem@davemloft.net>
On Sun, 2014-10-19 at 13:28 -0400, David Miller wrote:
> From: Max Filippov <jcmvbkbc@gmail.com>
> Date: Sun, 19 Oct 2014 21:26:05 +0400
>
> > On Sun, Oct 19, 2014 at 8:45 PM, David Miller <davem@davemloft.net> wrote:
> >> From: Daniel Glöckner <dg@emlix.com>
> >> Date: Sun, 19 Oct 2014 00:49:05 +0200
> >>
> >>> The s6000 Xtensa support is removed from the kernel. There are no
> >>> other chips using this driver.
> >>
> >> That's not what I see in Linus's current tree:
> >
> > David, s6000 removal is queued for 3.18.
>
> Then there is zero reason for me to apply this to my networking
> tree.
Commit 4006e565e150 ("xtensa: remove s6000 variant and s6105 platform")
is included in linux-next as of next-20141111. So now we see:
$ git grep XTENSA_VARIANT_S6000 next-20141111
next-20141111:drivers/net/ethernet/Kconfig: depends on XTENSA_VARIANT_S6000
Should Daniel resubmit, for net-next, perhaps with a commit explanation
that references this commit?
Paul Bolle
^ permalink raw reply
* Re: [net-next PATCH 4/5] fm10k/igb/ixgbe: Replace __skb_alloc_page with netdev_alloc_page
From: Jeff Kirsher @ 2014-11-11 8:32 UTC (permalink / raw)
To: Alexander Duyck
Cc: netdev, linux-usb, leedom, hariprasad, donald.c.skidmore, oliver,
balbi, matthew.vick, mgorman, davem
In-Reply-To: <20141110195221.16182.16080.stgit@ahduyck-vm-fedora20>
[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]
On Mon, 2014-11-10 at 11:52 -0800, Alexander Duyck wrote:
> The Intel drivers were pretty much just using the plain vanilla GFP
> flags
> in their calls to __skb_alloc_page so this change makes it so that
> they use
> netdev_alloc_page which just uses GFP_ATOMIC for the gfp_flags value.
>
> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Cc: Matthew Vick <matthew.vick@intel.com>
> Cc: Don Skidmore <donald.c.skidmore@intel.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
> ---
> drivers/net/ethernet/intel/fm10k/fm10k_main.c | 2 +-
> drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 +--
> 3 files changed, 3 insertions(+), 4 deletions(-)
I know that this patch is dependent upon the changes in patch 01 of the
series, so I do not want to necessarily break up the series by having
Dave wait for us to test and ACK this patch internally. But I will add
your patch to my queue so that I can get what testing I can on these
changes.
FWIW...
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: Face some error after applying commit 7dfa4b414d4(net/mlx4_en: Code cleanups in tx path)
From: Amir Vadai @ 2014-11-11 8:40 UTC (permalink / raw)
To: Wei Yang
Cc: Amir Vadai, Eric Dumazet, Eric Dumazet, David Miller, netdev,
gerlitz.or
In-Reply-To: <20141111074243.GA25321@richard>
On Tue, Nov 11, 2014 at 9:42 AM, Wei Yang <weiyang@linux.vnet.ibm.com> wrote:
> On Tue, Nov 11, 2014 at 09:28:34AM +0200, Amir Vadai wrote:
>>On Tue, Nov 11, 2014 at 3:57 AM, Wei Yang <weiyang@linux.vnet.ibm.com> wrote:
>>> On Mon, Nov 10, 2014 at 10:00:21AM +0200, Amir Vadai wrote:
>>>>On 11/10/2014 7:40 AM, Wei Yang wrote:
>>>>> On Sun, Nov 09, 2014 at 06:46:14PM -0800, Eric Dumazet wrote:
>>>>>> On Mon, 2014-11-10 at 09:59 +0800, Wei Yang wrote:
>>>>>>> On Fri, Nov 07, 2014 at 07:38:15PM -0800, Eric Dumazet wrote:
>>>>>>>> On Fri, Nov 7, 2014 at 6:57 PM, Wei Yang <weiyang@linux.vnet.ibm.com> wrote:
>>>>>>>>> Eric and Amir
>>>>>>>>>
>>>>
>>>>[...]
>>>>
>>>>>>>
>>>>>>
>>>>>> Okay, your message was not clear : I thought you had a compilation error
>>>>>> on current tree.
>>>>>>
>>>>>> The true story of these patches is that Mellanox split an initial big
>>>>>> chunk [1] I gave into multiple patches.
>>>>>>
>>>>>> Maybe they missed that one patch did not actually compile.
>>>>>>
>>>>>> [1] https://patchwork.ozlabs.org/patch/394256/
>>>>>>
>>>>>> Now, it is done, there is nothing we can do.
>>>>>>
>>>>>> I'll let Mellanox comment, but it looks like your hardware does not like
>>>>>> something.
>>>>>>
>>>>>> Have you tried to disable Blue Frame ?
>>>>>>
>>>>>
>>>>> Yep, looks the PF works fine. But the current FW I can't just enable the PF.
>>>>>
>>>>> How to disable Blue Frame? I am not clear about this.
>>>>>
>>>>Hi,
>>>>
>>>>Lets see that we're on the same page here:
>>>>1. There was a compilation problem that you fixed (Yes, it was my fault
>>>>- I just discovered it a minute after the code was applied).
>>>>2. When you're using SR-IOV, during initialization, you get a CQE error
>>>>with syndrome 0x2 on one of the probed VF's.
>>>
>>> From the log, seems yes.
>>>
>>>>3. Regarding the BlueFlame - I don't see how it is related to the issue
>>>>that you see. But it is a very easy experiment. Issue: "ethtool
>>>>--set-priv-flags eth1 blueflame off"
>>>
>>> I tried to use this after mlx4_en is loaded, still see the CQE error.
>>>
>>>>
>>>>Please send me the module parameters you used when loading mlx4_core, a
>>>>full dmesg with both mlx4_core and mlx4_en loading.
>>>
>>> The command line I use is:
>>> modprobe mlx4_core num_vfs=1 probe_vf=1 port_type_array=2,2
>>>
>>> The log I sent in the first mail is the full log, including the CQE error, one
>>> warning in watchdog, and then print the CQE error periodicly. What else
>>> message you would like me to capture?
>>
>>The log in the first mail has only mlx4_en logs. I would like to see
>>the full log, that has mlx4_core messages too. And as Or suggested,
>>debug_level=1 could be useful here too.
>>
>
> Ah, you need the log from mlx4_core too. Ok, I will do it again.
>
> BTW, how to add the debug_level=1 in the command line? Like this?
>
> modprobe mlx4_core num_vfs=1 probe_vf=1 port_type_array=2,2 debug_level=1
yes
>
> But for mlx4_en, I am not sure I could raise the debug level with ethtool,
> since the ethernet driver may not work properly. Actually I am not sure how to
> raise the level with ethtool. Could you give me an example?
# ethtool -s ens5f1d1 msglvl 0xffff
>
>>>
>>> And this error is reported from VF always. After the error, the other network
>>> interface seems can't function.
>>>
>>>>
>>>>Amir.
>>>
>>> --
>>> Richard Yang
>>> Help you, Help me
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> Richard Yang
> Help you, Help me
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] usbnet: smsc95xx: dereferencing NULL pointer
From: Sudip Mukherjee @ 2014-11-11 8:40 UTC (permalink / raw)
To: Steve Glendinning; +Cc: Sudip Mukherjee, netdev, linux-usb, linux-kernel
we were dereferencing dev to initialize pdata. but just after that we
have a BUG_ON(!dev). so we were basically dereferencing the pointer
first and then tesing it for NULL.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
change in v2: suspend_flags is initialised after pdata is initialised.
v1 had a very silly but serious mistake of making pdata NULL, and trying
to dereference it.
sorry again for that.
drivers/net/usb/smsc95xx.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index d07bf4c..26423ad 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -1670,12 +1670,14 @@ done:
static int smsc95xx_resume(struct usb_interface *intf)
{
struct usbnet *dev = usb_get_intfdata(intf);
- struct smsc95xx_priv *pdata = (struct smsc95xx_priv *)(dev->data[0]);
- u8 suspend_flags = pdata->suspend_flags;
+ struct smsc95xx_priv *pdata;
+ u8 suspend_flags;
int ret;
u32 val;
BUG_ON(!dev);
+ pdata = (struct smsc95xx_priv *)(dev->data[0]);
+ suspend_flags = pdata->suspend_flags;
netdev_dbg(dev->net, "resume suspend_flags=0x%02x\n", suspend_flags);
--
1.8.1.2
^ permalink raw reply related
* Re: [patch net-next v2 00/10] introduce rocker switch driver with hardware accelerated datapath api - phase 1: bridge fdb offload
From: Simon Horman @ 2014-11-11 8:51 UTC (permalink / raw)
To: John Fastabend
Cc: Jamal Hadi Salim, Jiri Pirko, netdev, davem, nhorman, andy, tgraf,
dborkman, ogerlitz, jesse, pshelar, azhou, ben, stephen,
jeffrey.t.kirsher, vyasevic, xiyou.wangcong, john.r.fastabend,
edumazet, sfeldma, f.fainelli, roopa, linville, jasowang,
ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh, aviadr, nbd,
alexei.starovoitov, Neil.Jerram, ronye, alexander.h.duyck,
john.ronciak, mleitner, shrijeet, gospo
In-Reply-To: <54613AD3.7030600@gmail.com>
On Mon, Nov 10, 2014 at 02:23:15PM -0800, John Fastabend wrote:
> On 11/09/2014 08:58 PM, Simon Horman wrote:
> >On Sun, Nov 09, 2014 at 11:03:40PM -0500, Jamal Hadi Salim wrote:
> >>Hi Simon,
> >>
> >>On 11/09/14 22:46, Simon Horman wrote:
> >>>Hi Jamal, Hi Jiri,
> >>>
> >>>On a somewhat related note I am also wondering what if any progress has
> >>>been made regarding discussions of (and code for) the following:
> >>>
> >>>1. Exposing flow tables to user-space
> >>> - I realise that this is Open vSwitch specific to some extent
> >>> but I am in no way implying that it should be done instead of
> >>> non-Open vSwitch specific work.
> >>> - Jiri, IIRC this was part ~v2 of your earlier offload patchset
> >>>
> >>
> >>I dont know what Rocker crowd is doing; however, I know
> >>John F. has been doing some work which i have stared at
> >>and I was hoping to join in with Ben's effort and show tc flow
> >>offload on the realtek chip in my infinite spare time unles.
> >>(for both Linux bridge and ports).
> >>The priority is to merge the obvious bits first.
> >
> >Merging the obvious bits first is quite fine my me.
> >
>
> +1
>
> >>>2. Describing Switch Hardware
> >>> - I see John Fastabend moving forwards on this in his git repository
> >>> https://github.com/jrfastab/flow-net-next
> >>>
> >>>The way that I see things is that both of the above could be exposed via
> >>>netlink. And that the first at least could be backed by NDOs. As such I
> >>>see this work as complementary and perhaps applying on top of this
> >>>patchset. If I am mistaken in this regards it would be good to know :)
> >>>
> >>
> >>You are correct - I will let John speak on his work, but
> >>that is the intent.
> >>The challenge is there are many schools of thoughts and i am hoping
> >>it is not an arms race.
> >
> >That is also my hope.
>
> My intent is to submit the Flow API bits once the base rocker switch
> gets committed. I've implemented the Flow API against ixgbe and a
> sadly a proprietary SDK. I'll implement it against the rocker switch
> as well.
Understood, that seems like a good approach to me.
> >>>I am of course also interested to know if the above are moving forwards.
> >>>To be clear I am very interested in being able to use these APIs to
> >>>perform Open vSwitch offloads and I am very happy to help.
> >>>(Jamal: I'm also interested in non-Open vSwitch offloads :)
> >>>
> >>
>
> I think they are moving forward. I have some code cleanup to do on
> the flow API, but its mostly in place. Then I want to implement
> an example on Rocker switch so we could experiment with something
> why we wait for a real hardware driver. From my side assuming I at
> least got it close to correct should be doable in the next few week.
>
> After that I want to work with Jesse/Jamal and look at integrating
> with OVS and other stacks. I thought a bit about the OVS integration
> path but I'll hold that discussion for the moment.
I am looking forward to that discussion.
> Simon, if your feeling adventurous any feedback on the repo link
> would be great. I still need to smash the commit log into something
> coherent though at the moment you can see all the errors and rewrites,
> etc as I made them.
Sure, will do. I took a look over your code about two weeks ago but I
believe you have made some updates since then.
> >>Hey, OVS should be able to use these APIs; i am just interested in making
> >>sure they are not just for OVS or OF. Then we are all happy;->
> >
> >I think we are all happy :)
>
> I'm happy :) Also my intent is the flow API is more general then
> just OVS. My view is OVS should be one user of the API.
I agree entirely.
^ permalink raw reply
* Re: [PATCH net-next 0/3] dev_disable_lro() improvements for stacked devices
From: Veaceslav Falico @ 2014-11-11 9:05 UTC (permalink / raw)
To: Michal Kubecek
Cc: David S. Miller, netdev, linux-kernel, Jay Vosburgh,
Andy Gospodarek, Jiri Pirko
In-Reply-To: <cover.1415692212.git.mkubecek@suse.cz>
On Tue, Nov 11, 2014 at 09:21:30AM +0100, Michal Kubecek wrote:
>Large receive offloading is known to cause problems if received packets
>are passed to other host. Therefore the kernel disables it by calling
>dev_disable_lro() whenever a network device is enslaved in a bridge or
>forwarding is enabled for it (or globally). For virtual devices we need
>to disable LRO on the underlying physical device (which is actually
>receiving the packets).
>
>Current dev_disable_lro() code handles this propagation for a vlan
>(including 802.1ad nested vlan), macvlan or a vlan on top of a macvlan.
>This patch adds LRO disabling propagation for
>
> - macvlan on top of a vlan or any stacked combination of those
> - bonding
> - teaming
All of these drivers use the netdev_upper and friends, so why not make it
generic with netdev_for_each_all_lower() in dev_disable_lro()?
>
>In the bonding and teaming case, it is necessary to disable LRO not only
>on slaves when dev_disable_lro() is called but also on any slave (port)
>added later.
>
>Michal Kubecek (3):
> net: handle more general stacking in dev_disable_lro()
> team: add helper to check if device is a team master
> net: propagate LRO disabling to bond and team slaves
>
> drivers/net/bonding/bond_main.c | 3 +++
> drivers/net/team/team.c | 6 +++++-
> include/linux/netdevice.h | 7 +++++++
> net/core/dev.c | 31 ++++++++++++++++++++++---------
> 4 files changed, 37 insertions(+), 10 deletions(-)
>
>--
>1.8.4.5
>
^ permalink raw reply
* Re: Face some error after applying commit 7dfa4b414d4(net/mlx4_en: Code cleanups in tx path)
From: Wei Yang @ 2014-11-11 9:12 UTC (permalink / raw)
To: Amir Vadai
Cc: Wei Yang, Eric Dumazet, Eric Dumazet, David Miller, netdev,
gerlitz.or
In-Reply-To: <CAPcc5PgFqzSVZ9rj8yj7LyuCjQXafP5J4bohcL4h7SFMc-rAJg@mail.gmail.com>
On Tue, Nov 11, 2014 at 10:40:24AM +0200, Amir Vadai wrote:
>On Tue, Nov 11, 2014 at 9:42 AM, Wei Yang <weiyang@linux.vnet.ibm.com> wrote:
>>>>>Hi,
>>>>>
>>>>>Lets see that we're on the same page here:
>>>>>1. There was a compilation problem that you fixed (Yes, it was my fault
>>>>>- I just discovered it a minute after the code was applied).
>>>>>2. When you're using SR-IOV, during initialization, you get a CQE error
>>>>>with syndrome 0x2 on one of the probed VF's.
>>>>
>>>> From the log, seems yes.
>>>>
>>>>>3. Regarding the BlueFlame - I don't see how it is related to the issue
>>>>>that you see. But it is a very easy experiment. Issue: "ethtool
>>>>>--set-priv-flags eth1 blueflame off"
>>>>
>>>> I tried to use this after mlx4_en is loaded, still see the CQE error.
>>>>
>>>>>
>>>>>Please send me the module parameters you used when loading mlx4_core, a
>>>>>full dmesg with both mlx4_core and mlx4_en loading.
>>>>
>>>> The command line I use is:
>>>> modprobe mlx4_core num_vfs=1 probe_vf=1 port_type_array=2,2
>>>>
>>>> The log I sent in the first mail is the full log, including the CQE error, one
>>>> warning in watchdog, and then print the CQE error periodicly. What else
>>>> message you would like me to capture?
>>>
>>>The log in the first mail has only mlx4_en logs. I would like to see
>>>the full log, that has mlx4_core messages too. And as Or suggested,
>>>debug_level=1 could be useful here too.
>>>
>>
>> Ah, you need the log from mlx4_core too. Ok, I will do it again.
>>
>> BTW, how to add the debug_level=1 in the command line? Like this?
>>
>> modprobe mlx4_core num_vfs=1 probe_vf=1 port_type_array=2,2 debug_level=1
>yes
>
I past the full log here, but I don't see the log level affact.
[ 5723.612882] mlx4_core: Mellanox ConnectX core driver v2.2-1 (Feb, 2014)
[ 5723.612979] mlx4_core: Initializing 0003:05:00.0
[ 5723.613023] pci 0003:05: 0.1: [PE# 222] VF 0003:05:00.1 associated with PE#222
[ 5723.613299] pci 0003:05: 0.1: [PE# 222] Setting up 32-bit TCE table at 0..80000000
[ 5723.684140] pci 0003:05: 0.1: [PE# 222] Enabling 64-bit DMA bypass
[ 5723.684215] pci 0003:05: 0.2: [PE# 223] VF 0003:05:00.2 associated with PE#223
[ 5723.684409] pci 0003:05: 0.2: [PE# 223] Setting up 32-bit TCE table at 0..80000000
[ 5723.754871] pci 0003:05: 0.2: [PE# 223] Enabling 64-bit DMA bypass
[ 5723.754944] pci 0003:05: 0.3: [PE# 224] VF 0003:05:00.3 associated with PE#224
[ 5723.755150] pci 0003:05: 0.3: [PE# 224] Setting up 32-bit TCE table at 0..80000000
[ 5723.825646] pci 0003:05: 0.3: [PE# 224] Enabling 64-bit DMA bypass
[ 5723.825718] pci 0003:05: 0.4: [PE# 225] VF 0003:05:00.4 associated with PE#225
[ 5723.825911] pci 0003:05: 0.4: [PE# 225] Setting up 32-bit TCE table at 0..80000000
[ 5723.896342] pci 0003:05: 0.4: [PE# 225] Enabling 64-bit DMA bypass
[ 5723.896416] pci 0003:05: 0.5: [PE# 226] VF 0003:05:00.5 associated with PE#226
[ 5723.896610] pci 0003:05: 0.5: [PE# 226] Setting up 32-bit TCE table at 0..80000000
[ 5723.967052] pci 0003:05: 0.5: [PE# 226] Enabling 64-bit DMA bypass
[ 5723.967135] pci 0003:05: 0.6: [PE# 227] VF 0003:05:00.6 associated with PE#227
[ 5723.967328] pci 0003:05: 0.6: [PE# 227] Setting up 32-bit TCE table at 0..80000000
[ 5724.037755] pci 0003:05: 0.6: [PE# 227] Enabling 64-bit DMA bypass
[ 5724.037829] pci 0003:05: 0.7: [PE# 228] VF 0003:05:00.7 associated with PE#228
[ 5724.038022] pci 0003:05: 0.7: [PE# 228] Setting up 32-bit TCE table at 0..80000000
[ 5724.108452] pci 0003:05: 0.7: [PE# 228] Enabling 64-bit DMA bypass
[ 5724.108525] pci 0003:05: 1.0: [PE# 229] VF 0003:05:01.0 associated with PE#229
[ 5724.108718] pci 0003:05: 1.0: [PE# 229] Setting up 32-bit TCE table at 0..80000000
[ 5724.179209] pci 0003:05: 1.0: [PE# 229] Enabling 64-bit DMA bypass
[ 5724.179293] pci 0003:05: 1.1: [PE# 230] VF 0003:05:01.1 associated with PE#230
[ 5724.179486] pci 0003:05: 1.1: [PE# 230] Setting up 32-bit TCE table at 0..80000000
[ 5724.249946] pci 0003:05: 1.1: [PE# 230] Enabling 64-bit DMA bypass
[ 5724.250020] pci 0003:05: 1.2: [PE# 231] VF 0003:05:01.2 associated with PE#231
[ 5724.250214] pci 0003:05: 1.2: [PE# 231] Setting up 32-bit TCE table at 0..80000000
[ 5724.320703] pci 0003:05: 1.2: [PE# 231] Enabling 64-bit DMA bypass
[ 5724.320787] pci 0003:05: 1.3: [PE# 232] VF 0003:05:01.3 associated with PE#232
[ 5724.320982] pci 0003:05: 1.3: [PE# 232] Setting up 32-bit TCE table at 0..80000000
[ 5724.391424] pci 0003:05: 1.3: [PE# 232] Enabling 64-bit DMA bypass
[ 5724.391497] pci 0003:05: 1.4: [PE# 233] VF 0003:05:01.4 associated with PE#233
[ 5724.391690] pci 0003:05: 1.4: [PE# 233] Setting up 32-bit TCE table at 0..80000000
[ 5724.462129] pci 0003:05: 1.4: [PE# 233] Enabling 64-bit DMA bypass
[ 5724.462215] pci 0003:05: 1.5: [PE# 234] VF 0003:05:01.5 associated with PE#234
[ 5724.462408] pci 0003:05: 1.5: [PE# 234] Setting up 32-bit TCE table at 0..80000000
[ 5724.532834] pci 0003:05: 1.5: [PE# 234] Enabling 64-bit DMA bypass
[ 5724.532907] pci 0003:05: 1.6: [PE# 235] VF 0003:05:01.6 associated with PE#235
[ 5724.533100] pci 0003:05: 1.6: [PE# 235] Setting up 32-bit TCE table at 0..80000000
[ 5724.603556] pci 0003:05: 1.6: [PE# 235] Enabling 64-bit DMA bypass
[ 5724.603628] pci 0003:05: 1.7: [PE# 236] VF 0003:05:01.7 associated with PE#236
[ 5724.603822] pci 0003:05: 1.7: [PE# 236] Setting up 32-bit TCE table at 0..80000000
[ 5724.674261] pci 0003:05: 1.7: [PE# 236] Enabling 64-bit DMA bypass
[ 5724.674334] pci 0003:05: 2.0: [PE# 237] VF 0003:05:02.0 associated with PE#237
[ 5724.674528] pci 0003:05: 2.0: [PE# 237] Setting up 32-bit TCE table at 0..80000000
[ 5724.745012] pci 0003:05: 2.0: [PE# 237] Enabling 64-bit DMA bypass
[ 5724.745088] pci 0003:05: 2.1: [PE# 238] VF 0003:05:02.1 associated with PE#238
[ 5724.745281] pci 0003:05: 2.1: [PE# 238] Setting up 32-bit TCE table at 0..80000000
[ 5724.815714] pci 0003:05: 2.1: [PE# 238] Enabling 64-bit DMA bypass
[ 5724.815786] pci 0003:05: 2.2: [PE# 239] VF 0003:05:02.2 associated with PE#239
[ 5724.815979] pci 0003:05: 2.2: [PE# 239] Setting up 32-bit TCE table at 0..80000000
[ 5724.886413] pci 0003:05: 2.2: [PE# 239] Enabling 64-bit DMA bypass
[ 5724.886487] pci 0003:05: 2.3: [PE# 240] VF 0003:05:02.3 associated with PE#240
[ 5724.886680] pci 0003:05: 2.3: [PE# 240] Setting up 32-bit TCE table at 0..80000000
[ 5724.957126] pci 0003:05: 2.3: [PE# 240] Enabling 64-bit DMA bypass
[ 5724.957210] pci 0003:05: 2.4: [PE# 241] VF 0003:05:02.4 associated with PE#241
[ 5724.957403] pci 0003:05: 2.4: [PE# 241] Setting up 32-bit TCE table at 0..80000000
[ 5725.027842] pci 0003:05: 2.4: [PE# 241] Enabling 64-bit DMA bypass
[ 5725.027917] pci 0003:05: 2.5: [PE# 242] VF 0003:05:02.5 associated with PE#242
[ 5725.028109] pci 0003:05: 2.5: [PE# 242] Setting up 32-bit TCE table at 0..80000000
[ 5725.098551] pci 0003:05: 2.5: [PE# 242] Enabling 64-bit DMA bypass
[ 5725.098624] pci 0003:05: 2.6: [PE# 243] VF 0003:05:02.6 associated with PE#243
[ 5725.098818] pci 0003:05: 2.6: [PE# 243] Setting up 32-bit TCE table at 0..80000000
[ 5725.169255] pci 0003:05: 2.6: [PE# 243] Enabling 64-bit DMA bypass
[ 5725.169338] pci 0003:05: 2.7: [PE# 244] VF 0003:05:02.7 associated with PE#244
[ 5725.169532] pci 0003:05: 2.7: [PE# 244] Setting up 32-bit TCE table at 0..80000000
[ 5725.239962] pci 0003:05: 2.7: [PE# 244] Enabling 64-bit DMA bypass
[ 5725.240036] pci 0003:05: 3.0: [PE# 245] VF 0003:05:03.0 associated with PE#245
[ 5725.240229] pci 0003:05: 3.0: [PE# 245] Setting up 32-bit TCE table at 0..80000000
[ 5725.310678] pci 0003:05: 3.0: [PE# 245] Enabling 64-bit DMA bypass
[ 5725.310751] pci 0003:05: 3.1: [PE# 246] VF 0003:05:03.1 associated with PE#246
[ 5725.310944] pci 0003:05: 3.1: [PE# 246] Setting up 32-bit TCE table at 0..80000000
[ 5725.381375] pci 0003:05: 3.1: [PE# 246] Enabling 64-bit DMA bypass
[ 5725.381459] pci 0003:05: 3.2: [PE# 247] VF 0003:05:03.2 associated with PE#247
[ 5725.381653] pci 0003:05: 3.2: [PE# 247] Setting up 32-bit TCE table at 0..80000000
[ 5725.452087] pci 0003:05: 3.2: [PE# 247] Enabling 64-bit DMA bypass
[ 5725.452171] pci 0003:05: 3.3: [PE# 248] VF 0003:05:03.3 associated with PE#248
[ 5725.452365] pci 0003:05: 3.3: [PE# 248] Setting up 32-bit TCE table at 0..80000000
[ 5725.522815] pci 0003:05: 3.3: [PE# 248] Enabling 64-bit DMA bypass
[ 5725.522889] pci 0003:05: 3.4: [PE# 249] VF 0003:05:03.4 associated with PE#249
[ 5725.523082] pci 0003:05: 3.4: [PE# 249] Setting up 32-bit TCE table at 0..80000000
[ 5725.593516] pci 0003:05: 3.4: [PE# 249] Enabling 64-bit DMA bypass
[ 5725.593590] pci 0003:05: 3.5: [PE# 250] VF 0003:05:03.5 associated with PE#250
[ 5725.593783] pci 0003:05: 3.5: [PE# 250] Setting up 32-bit TCE table at 0..80000000
[ 5725.664330] pci 0003:05: 3.5: [PE# 250] Enabling 64-bit DMA bypass
[ 5725.664403] pci 0003:05: 3.6: [PE# 251] VF 0003:05:03.6 associated with PE#251
[ 5725.664597] pci 0003:05: 3.6: [PE# 251] Setting up 32-bit TCE table at 0..80000000
[ 5725.735081] pci 0003:05: 3.6: [PE# 251] Enabling 64-bit DMA bypass
[ 5725.735154] pci 0003:05: 3.7: [PE# 252] VF 0003:05:03.7 associated with PE#252
[ 5725.735348] pci 0003:05: 3.7: [PE# 252] Setting up 32-bit TCE table at 0..80000000
[ 5725.805792] pci 0003:05: 3.7: [PE# 252] Enabling 64-bit DMA bypass
[ 5725.805865] pci 0003:05: 4.0: [PE# 253] VF 0003:05:04.0 associated with PE#253
[ 5725.806058] pci 0003:05: 4.0: [PE# 253] Setting up 32-bit TCE table at 0..80000000
[ 5725.876496] pci 0003:05: 4.0: [PE# 253] Enabling 64-bit DMA bypass
[ 5725.876570] pci 0003:05: 4.1: [PE# 254] VF 0003:05:04.1 associated with PE#254
[ 5725.876763] pci 0003:05: 4.1: [PE# 254] Setting up 32-bit TCE table at 0..80000000
[ 5725.945133] pci 0003:05: 4.1: [PE# 254] Enabling 64-bit DMA bypass
[ 5725.945212] pci 0003:05: 4.2: [PE# 255] VF 0003:05:04.2 associated with PE#255
[ 5725.945316] pci 0003:05: 4.2: [PE# 255] Setting up 32-bit TCE table at 0..80000000
[ 5726.006975] pci 0003:05: 4.2: [PE# 255] Enabling 64-bit DMA bypass
[ 5726.007163] mlx4_core 0003:05:00.0: Using 64-bit DMA iommu bypass
[ 5726.007227] mlx4_core 0003:05:00.0: Enabling SR-IOV with 1 VFs
[ 5726.116742] mlx4_core: Initializing 0003:05:00.1
[ 5726.116825] mlx4_core 0003:05:00.1: enabling device (0000 -> 0002)
[ 5726.116914] mlx4_core 0003:05:00.1: Using 64-bit DMA iommu bypass
[ 5726.116976] mlx4_core 0003:05:00.1: Detected virtual function - running in slave mode
[ 5726.117191] mlx4_core 0003:05:00.1: PF is not ready - Deferring probe
[ 5726.117276] pci 0003:05:00.1: Driver mlx4_core requests probe deferral
[ 5726.117363] mlx4_core 0003:05:00.0: Running in master mode
[ 5731.123148] mlx4_core 0003:05:00.0: PCIe link speed is 8.0GT/s, device supports 8.0GT/s
[ 5731.123227] mlx4_core 0003:05:00.0: PCIe link width is x8, device supports x8
[ 5731.151307] mlx4_core: Initializing 0003:05:00.1
[ 5731.151389] mlx4_core 0003:05:00.1: enabling device (0000 -> 0002)
[ 5731.151501] mlx4_core 0003:05:00.1: Using 64-bit DMA iommu bypass
[ 5731.151559] mlx4_core 0003:05:00.1: Detected virtual function - running in slave mode
[ 5731.151636] mlx4_core 0003:05:00.1: Sending reset
[ 5731.151770] mlx4_core 0003:05:00.0: Received reset from slave:1
[ 5731.152189] mlx4_core 0003:05:00.1: Sending vhcr0
[ 5731.152991] mlx4_core 0003:05:00.1: HCA minimum page size:512
[ 5731.153444] mlx4_core 0003:05:00.1: Timestamping is not supported in slave mode
[root@tian-lp1 ywywyang]# [ 5731.229958] mlx4_en: Mellanox ConnectX HCA Ethernet driver v2.2-1 (Feb 2014)
[ 5731.230572] mlx4_en 0003:05:00.0: registered PHC clock
[ 5731.230817] mlx4_en 0003:05:00.0: Activating port:1
[ 5731.262377] mlx4_en: eth12: Using 256 TX rings
[ 5731.262494] mlx4_en: eth12: Using 4 RX rings
[ 5731.262546] mlx4_en: eth12: frag:0 - size:1518 prefix:0 align:0 stride:1536
[ 5731.262761] mlx4_en: eth12: Initializing port
[ 5731.263357] mlx4_en 0003:05:00.1: Activating port:1
[ 5731.263467] mlx4_en: 0003:05:00.1: Port 1: Assigned random MAC address d6:0f:0b:57:36:24
[ 5731.442926] mlx4_en: eth13: Using 256 TX rings
[ 5731.443010] mlx4_en: eth13: Using 4 RX rings
[ 5731.443018] mlx4_en: eth13: frag:0 - size:1518 prefix:0 align:0 stride:1536
[ 5731.443304] mlx4_en: eth13: Initializing port
[ 5732.096548] mlx4_en: eth13: frag:0 - size:1518 prefix:0 align:0 stride:1536
[ 5732.452283] IPv6: ADDRCONF(NETDEV_UP): eth13: link is not ready
[ 5732.951420] mlx4_en: eth12: Link Up
[ 5732.951477] mlx4_en: eth13: Link Up
[ 5732.951627] IPv6: ADDRCONF(NETDEV_CHANGE): eth13: link becomes ready
[ 5733.171020] mlx4_en: eth13: CQE error - vendor syndrome: 0x6f syndrome: 0x2
[ 5733.315756] mlx4_en: eth13: CQE error - vendor syndrome: 0x6f syndrome: 0x2
[ 5734.165387] mlx4_en: eth13: CQE error - vendor syndrome: 0x6f syndrome: 0x2
[ 5748.045084] NETDEV WATCHDOG: eth13 (mlx4_core): transmit queue 1 timed out
[ 5748.045245] ------------[ cut here ]------------
[ 5748.045301] WARNING: at net/sched/sch_generic.c:303
[ 5748.045355] Modules linked in: mlx4_en(O) mlx4_core nf_conntrack_ipv6 nf_defrag_ipv6 bnep nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack bluetooth rfkill ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_security iptable_raw be2net tg3 ptp pps_core nfsd nfs_acl ses enclosure kvm_hv kvm_pr kvm lockd grace binfmt_misc shpchp sunrpc uinput lpfc ipr scsi_transport_fc [last unloaded: mlx4_core]
[ 5748.046069] CPU: 1 PID: 0 Comm: swapper/1 Tainted: P O 3.18.0-rc2yw+ #161
[ 5748.046142] task: c0000027ef4f92d0 ti: c0000027ef574000 task.ti: c0000027ef574000
[ 5748.046215] NIP: c00000000079a9d4 LR: c00000000079a9d0 CTR: 0000000030044878
[ 5748.046286] REGS: c0000027ef5772d0 TRAP: 0700 Tainted: P O (3.18.0-rc2yw+)
[ 5748.046357] MSR: 9000000000029032 <SF,HV,EE,ME,IR,DR,RI> CR: 28004024 XER: 00000000
[ 5748.046524] CFAR: c0000000008be150 SOFTE: 1
GPR00: c00000000079a9d0 c0000027ef577550 c00000000147acf0 000000000000003e
GPR04: c000002004145888 c000002004156240 9000000000009032 0000000000000029
GPR08: c000000000d1acf0 0000000000000000 0000002003430000 0000000030044954
GPR12: 0000000028004022 c00000000fdc0900 0000000000000001 c0000000008f10a8
GPR16: c0000027ef795438 c0000027ef795838 c0000027ef795c38 0000000000000000
GPR20: c0000027ef795038 c0000000014b2200 0000000000000000 0000000000000000
GPR24: 0000000000000000 ffffffffffffffff 0000000000000000 0000000000000001
GPR28: 0000000000000004 c0000000014b2200 c000002781340000 0000000000000001
[ 5748.047435] NIP [c00000000079a9d4] .dev_watchdog+0x354/0x370
[ 5748.047496] LR [c00000000079a9d0] .dev_watchdog+0x350/0x370
[ 5748.047544] Call Trace:
[ 5748.047570] [c0000027ef577550] [c00000000079a9d0] .dev_watchdog+0x350/0x370 (unreliable)
[ 5748.047655] [c0000027ef577600] [c0000000001275a4] .call_timer_fn+0x64/0x190
[ 5748.047727] [c0000027ef5776b0] [c00000000012814c] .run_timer_softirq+0x2bc/0x3d0
[ 5748.047812] [c0000027ef5777b0] [c0000000000ad738] .__do_softirq+0x168/0x390
[ 5748.047885] [c0000027ef5778b0] [c0000000000adcc8] .irq_exit+0xc8/0x110
[ 5748.047958] [c0000027ef577930] [c00000000001d15c] .timer_interrupt+0x9c/0xd0
[ 5748.048030] [c0000027ef5779b0] [c000000000002658] decrementer_common+0x158/0x180
[ 5748.048116] --- interrupt: 901 at .arch_local_irq_restore+0x74/0x90
[ 5748.048116] LR = .arch_local_irq_restore+0x74/0x90
[ 5748.048224] [c0000027ef577ca0] [c0000027ef577d30] 0xc0000027ef577d30 (unreliable)
[ 5748.048309] [c0000027ef577d10] [c00000000070887c] .cpuidle_enter_state+0xac/0x260
[ 5748.048393] [c0000027ef577dd0] [c0000000000f6c90] .cpu_startup_entry+0x410/0x460
[ 5748.048478] [c0000027ef577ed0] [c000000000040b40] .start_secondary+0x310/0x340
[ 5748.048562] [c0000027ef577f90] [c000000000008b6c] start_secondary_prolog+0x10/0x14
[ 5748.048643] Instruction dump:
[ 5748.048680] 994d02d4 4bffff10 7fc3f378 4bfd5ff1 60000000 7fc4f378 7fe6fb78 7c651b78
[ 5748.048799] 3c62ff75 3863afb8 48123721 60000000 <0fe00000> 39200001 3d02fff0 99282b88
[ 5748.048920] ---[ end trace a04deb5eef8eba41 ]---
[ 5748.385369] mlx4_en: eth13: frag:0 - size:1518 prefix:0 align:0 stride:1536
[ 5760.841519] mlx4_en: eth13: CQE error - vendor syndrome: 0x6f syndrome: 0x2
[ 5781.165457] mlx4_en: eth13: CQE error - vendor syndrome: 0x6f syndrome: 0x2
[ 5781.315631] mlx4_en: eth13: CQE error - vendor syndrome: 0x6f syndrome: 0x2
[ 5782.165413] mlx4_en: eth13: CQE error - vendor syndrome: 0x6f syndrome: 0x2
>>
>> But for mlx4_en, I am not sure I could raise the debug level with ethtool,
>> since the ethernet driver may not work properly. Actually I am not sure how to
>> raise the level with ethtool. Could you give me an example?
>
># ethtool -s ens5f1d1 msglvl 0xffff
>
>>
>>>>
>>>> And this error is reported from VF always. After the error, the other network
>>>> interface seems can't function.
>>>>
>>>>>
>>>>>Amir.
>>>>
>>>> --
>>>> Richard Yang
>>>> Help you, Help me
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> --
>> Richard Yang
>> Help you, Help me
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Richard Yang
Help you, Help me
^ permalink raw reply
* Re: [PATCH 1/1] linux-wireless: Added psk in struct cfg80211_connect_params needed for offloading 4way handshake to driver
From: Johannes Berg @ 2014-11-11 9:29 UTC (permalink / raw)
To: Gautam (Gautam Kumar) Shukla
Cc: linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jithu Jance,
Sreenath S
In-Reply-To: <DF163EE1A432BF4BBE6B2088220663A67437BD-HXj2mutaA2pmqaqore1TH5r/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
On Tue, 2014-11-11 at 05:56 +0000, Gautam (Gautam Kumar) Shukla wrote:
> For offloading 4 way handshake to driver, currently we don't have any
> member of struct cfg80211_connect_params to pass PSK from supplicant
> to driver. I have added psk for the same and added rest of the code
> needed in nl80211.h and nl80211.c to parse and make it available to
> driver.
> From supplicant, we already have psk member field in assoc_params to
> use .
>
> Tested on x86 linux.
Your commit message needs serious work.
Also, there's a competing approach from QCA that's far more suited.
In either case though, I'm going to ask which driver is going to use
this and when it's going to land in mainline.
johannes
^ permalink raw reply
* Re: [PATCH net-next 0/3] dev_disable_lro() improvements for stacked devices
From: Michal Kubecek @ 2014-11-11 9:34 UTC (permalink / raw)
To: Veaceslav Falico
Cc: David S. Miller, netdev, linux-kernel, Jay Vosburgh,
Andy Gospodarek, Jiri Pirko
In-Reply-To: <20141111090522.GB20586@raspberrypi>
On Tue, Nov 11, 2014 at 10:05:22AM +0100, Veaceslav Falico wrote:
> On Tue, Nov 11, 2014 at 09:21:30AM +0100, Michal Kubecek wrote:
> >Large receive offloading is known to cause problems if received packets
> >are passed to other host. Therefore the kernel disables it by calling
> >dev_disable_lro() whenever a network device is enslaved in a bridge or
> >forwarding is enabled for it (or globally). For virtual devices we need
> >to disable LRO on the underlying physical device (which is actually
> >receiving the packets).
> >
> >Current dev_disable_lro() code handles this propagation for a vlan
> >(including 802.1ad nested vlan), macvlan or a vlan on top of a macvlan.
> >This patch adds LRO disabling propagation for
> >
> > - macvlan on top of a vlan or any stacked combination of those
> > - bonding
> > - teaming
>
> All of these drivers use the netdev_upper and friends, so why not make it
> generic with netdev_for_each_all_lower() in dev_disable_lro()?
I wanted to preserve current approach where for vlan and macvlan, LRO is
disabled on the real device instead of the original one (rather than in
addition to it) as LRO is always disabled on them.
Handling all four uniformly would make the code nicer but would bring
unnecessary overhead of traversing the list and dev_disable_lro()
recursion. On the other hand, this operation is not time critical so it
might be acceptable after all.
Michal Kubecek
^ permalink raw reply
* Re: [PATCH 1/1] linux-wireless: Added psk in struct cfg80211_connect_params needed for offloading 4way handshake to driver
From: Arend van Spriel @ 2014-11-11 9:44 UTC (permalink / raw)
To: Gautam (Gautam Kumar) Shukla,
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jithu Jance,
Sreenath S
In-Reply-To: <DF163EE1A432BF4BBE6B2088220663A67437BD-HXj2mutaA2pmqaqore1TH5r/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
On 11-11-14 06:56, Gautam (Gautam Kumar) Shukla wrote:
>
Hi Gautam,
Good to see more upstream contributions, but it might be useful to have
a driver implementation as well in this series. Maybe we can take a shot
with brcmfmac for obvious reasons. Would you happen to have
wpa_supplicant changes as well?
I added some inline comments below.
Regards,
Arend
> For offloading 4 way handshake to driver, currently we don't have any member of struct cfg80211_connect_params to pass PSK from supplicant to driver. I have added psk for the same and added rest of the code needed in nl80211.h and nl80211.c to parse and make it available to driver.
> From supplicant, we already have psk member field in assoc_params to use .
In the commit message you should not describe what you did, but what
problem you are trying to solve and/or what functional change the patch
provides.
> Tested on x86 linux.
>
> Signed-off-by: Gautam kumar shukla <gautams-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
> include/net/cfg80211.h | 2 ++
> include/uapi/linux/nl80211.h | 8 +++++++-
> net/wireless/nl80211.c | 4 ++++
> 3 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index a2ddcf2..6f744e0 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -1758,6 +1758,7 @@ struct cfg80211_ibss_params {
> * allowed to ignore this @bssid_hint if it has knowledge of a better BSS
> * to use.
> * @ssid: SSID
> + * @psk:preshared key for WPA2-PSK connection or %NULL if not specified
add space after the colon sign.
> * @ssid_len: Length of ssid in octets
> * @auth_type: Authentication type (algorithm)
> * @ie: IEs for association request
> @@ -1783,6 +1784,7 @@ struct cfg80211_connect_params {
> const u8 *bssid;
> const u8 *bssid_hint;
> const u8 *ssid;
> + const u8 *psk;
> size_t ssid_len;
> enum nl80211_auth_type auth_type;
> const u8 *ie;
> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h index 4b28dc0..b01d5dd 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -421,7 +421,7 @@
> * %NL80211_ATTR_MAC, %NL80211_ATTR_WIPHY_FREQ, %NL80211_ATTR_CONTROL_PORT,
> * %NL80211_ATTR_CONTROL_PORT_ETHERTYPE,
> * %NL80211_ATTR_CONTROL_PORT_NO_ENCRYPT, %NL80211_ATTR_MAC_HINT, and
> - * %NL80211_ATTR_WIPHY_FREQ_HINT.
> + * %NL80211_ATTR_WIPHY_FREQ_HINT, and %NL80211_ATTR_PSK.
> * If included, %NL80211_ATTR_MAC and %NL80211_ATTR_WIPHY_FREQ are
> * restrictions on BSS selection, i.e., they effectively prevent roaming
> * within the ESS. %NL80211_ATTR_MAC_HINT and %NL80211_ATTR_WIPHY_FREQ_HINT @@ -1638,6 +1638,10 @@ enum nl80211_commands {
> * @NL80211_ATTR_SMPS_MODE: SMPS mode to use (ap mode). see
> * &enum nl80211_smps_mode.
> *
> + * @NL80211_ATTR_PSK: a PSK value (u8 attribute).This is 32-octet
> + (256-bit)
> + * PSK.
> + *
Some indentation gone haywire here. I would remove '(u8 attribute)'. The
mention of 32-octet seems sufficient to me.
> * @NL80211_ATTR_MAX: highest attribute number currently defined
> * @__NL80211_ATTR_AFTER_LAST: internal use
> */
> @@ -1990,6 +1994,8 @@ enum nl80211_attrs {
>
> NL80211_ATTR_SMPS_MODE,
>
> + NL80211_ATTR_PSK,
> +
> /* add attributes here, update the policy in nl80211.c */
>
> __NL80211_ATTR_AFTER_LAST,
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index 5839c85..91c24b1 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -395,6 +395,7 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
> [NL80211_ATTR_USER_PRIO] = { .type = NLA_U8 },
> [NL80211_ATTR_ADMITTED_TIME] = { .type = NLA_U16 },
> [NL80211_ATTR_SMPS_MODE] = { .type = NLA_U8 },
> + [NL80211_ATTR_PSK] = { .type = NLA_BINARY, .len = 32 },
> };
>
> /* policy for the key attributes */
> @@ -7310,6 +7311,9 @@ static int nl80211_connect(struct sk_buff *skb, struct genl_info *info)
> connect.flags |= ASSOC_REQ_USE_RRM;
> }
>
> + if (info->attrs[NL80211_ATTR_PSK])
> + connect.psk = nla_data(info->attrs[NL80211_ATTR_PSK]);
> +
> wdev_lock(dev->ieee80211_ptr);
> err = cfg80211_connect(rdev, dev, &connect, connkeys, NULL);
> wdev_unlock(dev->ieee80211_ptr);
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [PATCH 2/2] linux-wireless:Added wiphy capability flag for offloading 4way handshake to driver
From: Arend van Spriel @ 2014-11-11 9:49 UTC (permalink / raw)
To: Gautam (Gautam Kumar) Shukla,
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jithu Jance,
Sreenath S
In-Reply-To: <DF163EE1A432BF4BBE6B2088220663A6743890-HXj2mutaA2pmqaqore1TH5r/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
On 11-11-14 07:27, Gautam (Gautam Kumar) Shukla wrote:
>
> For offloading 4 way handshake to driver , currently we don't have WIPHY capability flag to communicate same to supplicant.
> I have added the flag NL80211_ATTR_4WAY_KEY_HANDSHAKE and rest of the code for the same.
>
> Tested on x86 linux machine
>
> Signed-off-by: Gautam kumar shukla <gautams-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
> include/net/cfg80211.h | 4 ++++
> include/uapi/linux/nl80211.h | 5 ++++-
> net/wireless/nl80211.c | 4 ++++
> 3 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index 6f744e0..b37de0a 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -2629,7 +2629,10 @@ struct cfg80211_ops {
> * TSPEC sessions (TID aka TSID 0-7) with the NL80211_CMD_ADD_TX_TS
> * command. Standard IEEE 802.11 TSPEC setup is not yet supported, it
> * needs to be able to handle Block-Ack agreements and other things.
> + * @WIPHY_FLAG_SUPPORTS_4WAY_HANDHSHAKE:the device supports 4way handshake
Indentation seems wrong here. Also add space after the colon sign.
> + * in the driver/firmware.
> */
> +
> enum wiphy_flags {
> WIPHY_FLAG_SUPPORTS_WMM_ADMISSION = BIT(0),
> /* use hole at 1 */
> @@ -2654,6 +2657,7 @@ enum wiphy_flags {
> WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL = BIT(21),
> WIPHY_FLAG_SUPPORTS_5_10_MHZ = BIT(22),
> WIPHY_FLAG_HAS_CHANNEL_SWITCH = BIT(23),
> + WIPHY_FLAG_SUPPORTS_4WAY_HANDSHAKE = BIT(24),
> };
>
> /**
> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
> index b01d5dd..2c474a3 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -1640,9 +1640,11 @@ enum nl80211_commands {
> *
> * @NL80211_ATTR_PSK: a PSK value (u8 attribute).This is 32-octet (256-bit)
> * PSK.
> + * @NL80211_ATTR_4WAY_KEY_HANDSHAKE: Indicates whether the driver is capable
> + * of 4way key handshake
convention is to have a tab in the continuing line.
> *
> *
> - * @NL80211_ATTR_MAX: highest attribute number currently defined
> + * * @NL80211_ATTR_MAX: highest attribute number currently defined
huh?
> * @__NL80211_ATTR_AFTER_LAST: internal use
> */
> enum nl80211_attrs {
> @@ -1995,6 +1997,7 @@ enum nl80211_attrs {
> NL80211_ATTR_SMPS_MODE,
>
> NL80211_ATTR_PSK,
> + NL80211_ATTR_4WAY_KEY_HANDSHAKE,
>
> /* add attributes here, update the policy in nl80211.c */
>
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index 91c24b1..5f85c41 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -396,6 +396,7 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
> [NL80211_ATTR_ADMITTED_TIME] = { .type = NLA_U16 },
> [NL80211_ATTR_SMPS_MODE] = { .type = NLA_U8 },
> [NL80211_ATTR_PSK] = { .type = NLA_BINARY, .len = 32 },
> + [NL80211_ATTR_4WAY_KEY_HANDSHAKE] = { .type = NLA_FLAG },
> };
>
> /* policy for the key attributes */
> @@ -1303,6 +1304,9 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
> if ((rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_FW_ROAM) &&
> nla_put_flag(msg, NL80211_ATTR_ROAM_SUPPORT))
> goto nla_put_failure;
> + if ((rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_4WAY_HANDSHAKE) &&
> + nla_put_flag(msg,NL80211_ATTR_4WAY_KEY_HANDSHAKE))
> + goto nla_put_failure;
> if ((rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_TDLS) &&
> nla_put_flag(msg, NL80211_ATTR_TDLS_SUPPORT))
> goto nla_put_failure;
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox