* 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 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
* [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
* [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 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 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
* 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
* 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: [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: 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] 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
* [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 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 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] net: phy: Correctly handle MII ioctl which changes autonegotiation.
From: Florian Fainelli @ 2014-11-11 4:17 UTC (permalink / raw)
To: Brian Hill; +Cc: netdev
In-Reply-To: <54610F8B.2000600@houston-radar.com>
Hi Brian,
2014-11-10 11:18 GMT-08:00 Brian Hill <brian@houston-radar.com>:
>
> When advertised capabilities are changed with mii-tool,
> such as:
> mii-tool -A 10baseT
> the existing handler has two errors.
>
> - An actual PHY register value is provided by mii-tool, and this
> must be mapped to internal state with mii_adv_to_ethtool_adv_t().
> - The PHY state machine needs to be told that autonegotiation has
> again been performed. If not, the MAC will not be notified of
> the new link speed and duplex, resulting in a possible config
> mismatch.
Looks very good to me, just one minor thing I did not notice
initially. Once you fix that, feel free to resubmit with:
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
>
> Signed-off-by: Brian Hill <Brian@houston-radar.com>
> ---
> drivers/net/phy/phy.c | 36 ++++++++++++++++++++++++------------
> 1 file changed, 24 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index c94e2a2..ee9f0c9 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -352,6 +352,7 @@ int phy_mii_ioctl(struct phy_device *phydev, struct
> ifreq *ifr, int cmd)
> {
> struct mii_ioctl_data *mii_data = if_mii(ifr);
> u16 val = mii_data->val_in;
> + int change_autoneg = 0;
This should be a "bool autoneg = false;" here
>
> switch (cmd) {
> case SIOCGMIIPHY:
> @@ -367,22 +368,29 @@ int phy_mii_ioctl(struct phy_device *phydev, struct
> ifreq *ifr, int cmd)
> if (mii_data->phy_id == phydev->addr) {
> switch (mii_data->reg_num) {
> case MII_BMCR:
> - if ((val & (BMCR_RESET | BMCR_ANENABLE)) == 0)
> + if ((val & (BMCR_RESET | BMCR_ANENABLE)) == 0) {
> + if (phydev->autoneg == AUTONEG_ENABLE)
> + change_autoneg = 1;
> phydev->autoneg = AUTONEG_DISABLE;
> - else
> + if (val & BMCR_FULLDPLX)
> + phydev->duplex = DUPLEX_FULL;
> + else
> + phydev->duplex = DUPLEX_HALF;
> + if (val & BMCR_SPEED1000)
> + phydev->speed = SPEED_1000;
> + else if (val & BMCR_SPEED100)
> + phydev->speed = SPEED_100;
> + else phydev->speed = SPEED_10;
> + }
> + else {
> + if (phydev->autoneg == AUTONEG_DISABLE)
> + change_autoneg = 1;
> phydev->autoneg = AUTONEG_ENABLE;
> - if (!phydev->autoneg && (val & BMCR_FULLDPLX))
> - phydev->duplex = DUPLEX_FULL;
> - else
> - phydev->duplex = DUPLEX_HALF;
> - if (!phydev->autoneg && (val & BMCR_SPEED1000))
> - phydev->speed = SPEED_1000;
> - else if (!phydev->autoneg &&
> - (val & BMCR_SPEED100))
> - phydev->speed = SPEED_100;
> + }
> break;
> case MII_ADVERTISE:
> - phydev->advertising = val;
> + phydev->advertising = mii_adv_to_ethtool_adv_t(val);
> + change_autoneg = 1;
> break;
> default:
> /* do nothing */
> @@ -396,6 +404,10 @@ int phy_mii_ioctl(struct phy_device *phydev, struct
> ifreq *ifr, int cmd)
> if (mii_data->reg_num == MII_BMCR &&
> val & BMCR_RESET)
> return phy_init_hw(phydev);
> +
> + if (change_autoneg)
> + return phy_start_aneg(phydev);
> +
> return 0;
>
> case SIOCSHWTSTAMP:
> --
> 1.7.9.5
>
> --
> 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
--
Florian
^ permalink raw reply
* Re: [patch net-next] bridge: rename fdb_*_hw to fdb_*_hw_addr to avoid confusion
From: David Miller @ 2014-11-11 2:33 UTC (permalink / raw)
To: jiri
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: <1415551216-2239-1-git-send-email-jiri@resnulli.us>
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?
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: introduce SO_INCOMING_CPU
From: David Miller @ 2014-11-11 2:16 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ycai, willemb, ncardwell
In-Reply-To: <1415663481.9613.18.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 10 Nov 2014 15:51:21 -0800
> On Mon, 2014-11-10 at 15:08 -0500, David Miller wrote:
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Fri, 07 Nov 2014 12:51:12 -0800
>>
>> > @@ -1455,6 +1455,7 @@ process:
>> > goto discard_and_relse;
>> >
>> > sk_mark_napi_id(sk, skb);
>> > + sk_incoming_cpu_update(sk);
>>
>> Just make sk_mark_napi_id() call sk_incoming_cpu_update().
>>
>> You've matched up the calls precisely in this patch, and I can't think
>> of any situation where we'd add a sk_mark_napi_call() not not want to
>> do an sk_incoming_cpu_update().
>
> I believe this was a coincidence.
>
> In fact some sk_mark_napi_id() calls are not at the right place.
> It makes little sense to change sk->sk_napi_id for a listener socket.
>
> sk_mark_napi_id() should better be done [1] at the same time we call
> sock_rps_save_rxhash
>
> But we need to store cpu before prequeue or backlog (as I did in my
> patch)
Ok, so why don't you submit two patches. First, fix the locations
where we do sk_mark_napi_id(), then your SO_INCOMING_CPU patch
(unchanged)?
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] mlx4: restore conditional call to napi_complete_done()
From: David Miller @ 2014-11-11 2:13 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, amirv, ogerlitz, willemb
In-Reply-To: <1415657240.9613.11.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 10 Nov 2014 14:07:20 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> After commit 1a28817282 ("mlx4: use napi_complete_done()") we ended up
> calling napi_complete_done() in the case NAPI poll consumed all its
> budget.
>
> This added extra interrupt pressure, this patch restores proper
> behavior.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Fixes: 1a28817282 ("mlx4: use napi_complete_done()")
Applied, thanks Eric.
^ permalink raw reply
* [PATCH net 2/2] net: bcmgenet: apply MII configuration in bcmgenet_open()
From: Florian Fainelli @ 2014-11-11 2:06 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli
In-Reply-To: <1415671581-2835-1-git-send-email-f.fainelli@gmail.com>
In case an interface has been brought down before entering S3, and then
brought up out of S3, all the initialization done during
bcmgenet_probe() by bcmgenet_mii_init() calling bcmgenet_mii_config() is
just lost since register contents are restored to their reset values.
Re-apply this configuration anytime we call bcmgenet_open() to make sure
our port multiplexer is properly configured to match the PHY interface.
Since we are now calling bcmgenet_mii_config() everytime bcmgenet_open()
is called, make sure we only print the message during initialization
time not to pollute the console.
Fixes: b6e978e50444 ("net: bcmgenet: add suspend/resume callbacks")
Fixes: 1c1008c793fa4 ("net: bcmgenet: add main driver file")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 5 ++++-
drivers/net/ethernet/broadcom/genet/bcmgenet.h | 2 +-
drivers/net/ethernet/broadcom/genet/bcmmii.c | 7 ++++---
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index 34055fd59c74..da1a2500c91c 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -2140,6 +2140,9 @@ static int bcmgenet_open(struct net_device *dev)
goto err_irq0;
}
+ /* Re-configure the port multiplexer towards the PHY device */
+ bcmgenet_mii_config(priv->dev, false);
+
phy_connect_direct(dev, priv->phydev, bcmgenet_mii_setup,
priv->phy_interface);
@@ -2691,7 +2694,7 @@ static int bcmgenet_resume(struct device *d)
phy_init_hw(priv->phydev);
/* Speed settings must be restored */
- bcmgenet_mii_config(priv->dev);
+ bcmgenet_mii_config(priv->dev, false);
/* disable ethernet MAC while updating its registers */
umac_enable_set(priv, CMD_TX_EN | CMD_RX_EN, false);
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.h b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
index 44b55b8c220f..31b2da5f9b82 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.h
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
@@ -617,7 +617,7 @@ GENET_IO_MACRO(rbuf, GENET_RBUF_OFF);
/* MDIO routines */
int bcmgenet_mii_init(struct net_device *dev);
-int bcmgenet_mii_config(struct net_device *dev);
+int bcmgenet_mii_config(struct net_device *dev, bool init);
void bcmgenet_mii_exit(struct net_device *dev);
void bcmgenet_mii_reset(struct net_device *dev);
void bcmgenet_mii_setup(struct net_device *dev);
diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c b/drivers/net/ethernet/broadcom/genet/bcmmii.c
index 9c5fee782ccf..933cd7e7cd33 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
@@ -211,7 +211,7 @@ static void bcmgenet_moca_phy_setup(struct bcmgenet_priv *priv)
bcmgenet_sys_writel(priv, reg, SYS_PORT_CTRL);
}
-int bcmgenet_mii_config(struct net_device *dev)
+int bcmgenet_mii_config(struct net_device *dev, bool init)
{
struct bcmgenet_priv *priv = netdev_priv(dev);
struct phy_device *phydev = priv->phydev;
@@ -298,7 +298,8 @@ int bcmgenet_mii_config(struct net_device *dev)
return -EINVAL;
}
- dev_info(kdev, "configuring instance for %s\n", phy_name);
+ if (init)
+ dev_info(kdev, "configuring instance for %s\n", phy_name);
return 0;
}
@@ -350,7 +351,7 @@ static int bcmgenet_mii_probe(struct net_device *dev)
* PHY speed which is needed for bcmgenet_mii_config() to configure
* things appropriately.
*/
- ret = bcmgenet_mii_config(dev);
+ ret = bcmgenet_mii_config(dev, true);
if (ret) {
phy_disconnect(priv->phydev);
return ret;
--
1.9.1
^ permalink raw reply related
* [PATCH net 1/2] net: bcmgenet: connect and disconnect from the PHY state machine
From: Florian Fainelli @ 2014-11-11 2:06 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli
In-Reply-To: <1415671581-2835-1-git-send-email-f.fainelli@gmail.com>
phy_disconnect() is the only way to guarantee that we are not going to
schedule more work on the PHY state machine workqueue for that
particular PHY device.
This fixes an issue where a network interface was suspended prior to a
system suspend/resume cycle and would then be resumed as part of
mdio_bus_resume(), since the GENET interface clocks would have been
disabled, this basically resulted in bus errors to appear since we are
invoking the GENET driver adjust_link() callback.
Fixes: b6e978e50444 ("net: bcmgenet: add suspend/resume callbacks")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 6 ++++++
drivers/net/ethernet/broadcom/genet/bcmgenet.h | 1 +
drivers/net/ethernet/broadcom/genet/bcmmii.c | 2 +-
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index fdc9ec09e453..34055fd59c74 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -2140,6 +2140,9 @@ static int bcmgenet_open(struct net_device *dev)
goto err_irq0;
}
+ phy_connect_direct(dev, priv->phydev, bcmgenet_mii_setup,
+ priv->phy_interface);
+
bcmgenet_netif_start(dev);
return 0;
@@ -2184,6 +2187,9 @@ static int bcmgenet_close(struct net_device *dev)
bcmgenet_netif_stop(dev);
+ /* Really kill the PHY state machine and disconnect from it */
+ phy_disconnect(priv->phydev);
+
/* Disable MAC receive */
umac_enable_set(priv, CMD_RX_EN, false);
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.h b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
index dbf524ea3b19..44b55b8c220f 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.h
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
@@ -620,6 +620,7 @@ int bcmgenet_mii_init(struct net_device *dev);
int bcmgenet_mii_config(struct net_device *dev);
void bcmgenet_mii_exit(struct net_device *dev);
void bcmgenet_mii_reset(struct net_device *dev);
+void bcmgenet_mii_setup(struct net_device *dev);
/* Wake-on-LAN routines */
void bcmgenet_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol);
diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c b/drivers/net/ethernet/broadcom/genet/bcmmii.c
index 9ff799a9f801..9c5fee782ccf 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
@@ -77,7 +77,7 @@ static int bcmgenet_mii_write(struct mii_bus *bus, int phy_id,
/* setup netdev link state when PHY link status change and
* update UMAC and RGMII block when link up
*/
-static void bcmgenet_mii_setup(struct net_device *dev)
+void bcmgenet_mii_setup(struct net_device *dev)
{
struct bcmgenet_priv *priv = netdev_priv(dev);
struct phy_device *phydev = priv->phydev;
--
1.9.1
^ permalink raw reply related
* [PATCH net 0/2] net: bcmgenet: power management related fixes
From: Florian Fainelli @ 2014-11-11 2:06 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli
Hi David,
These two patches fixes issues seen while testing power management on
platforms using the GENET driver.
First patch fixes an issue with the PHY state machine queuing work after
resume since we are not properly detached from it.
Second patch fixes an issue with GENET interfaces that were not properly
restored to a working state after a S3 suspend/resume cycle.
Thanks!
Florian Fainelli (2):
net: bcmgenet: connect and disconnect from the PHY state machine
net: bcmgenet: apply MII configuration in bcmgenet_open()
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 11 ++++++++++-
drivers/net/ethernet/broadcom/genet/bcmgenet.h | 3 ++-
drivers/net/ethernet/broadcom/genet/bcmmii.c | 9 +++++----
3 files changed, 17 insertions(+), 6 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH 0/3 net-next] sunvnet: edge-case/race-conditions bug fixes
From: David Miller @ 2014-11-11 2:06 UTC (permalink / raw)
To: sowmini.varadhan; +Cc: netdev, david.stevens
In-Reply-To: <20141109014143.GB31217@oracle.com>
From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date: Sat, 8 Nov 2014 20:41:43 -0500
> This patch series contains fixes for race-conditions in sunvnet,
> that can encountered when there is a difference in latency between
> producer and consumer.
>
> Patch 1 addresses a case when the STOPPED LDC ack from a peer is
> processed before vnet_start_xmit can finish updating the dr->prod
> state.
>
> Patch 2 fixes the edge-case when outgoing data and incoming
> stopped-ack cross each other in flight.
>
> Patch 3 adds a missing rcu_read_unlock(), found by code-inspection.
Series applied, thanks.
^ permalink raw reply
* Re: [net-next PATCH 1/5] net: Add netdev Rx page allocation function
From: Alexander Duyck @ 2014-11-11 2:02 UTC (permalink / raw)
To: Cong Wang
Cc: netdev, linux-usb-u79uwXL29TY76Z2rM5mHXA,
leedom-ut6Up61K2wZBDgjK7y7TUQ, hariprasad-ut6Up61K2wZBDgjK7y7TUQ,
donald.c.skidmore-ral2JQCrhuEAvxtiuMwx3w,
oliver-GvhC2dPhHPQdnm+yROfE0A, balbi-l0cyMroinI0,
matthew.vick-ral2JQCrhuEAvxtiuMwx3w, mgorman-l3A5Bk7waGM,
David Miller, jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <CAHA+R7PigH6ZZBP0DzAPwLMwsK85aadj4hH3iahhOH2ehfYJvg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11/10/2014 04:26 PM, Cong Wang wrote:
> On Mon, Nov 10, 2014 at 11:51 AM, Alexander Duyck
> <alexander.h.duyck-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> This patch implements __netdev_alloc_pages and __netdev_alloc_page. These
>> are meant to replace the __skb_alloc_pages and __skb_alloc_page functions.
>> The reason for doing this is that it occurred to me that __skb_alloc_page is
>> supposed to be passed an sk_buff pointer, but it is NULL in all cases where
>> it is used. Worse is that in the case of ixgbe it is passed NULL via the
>> sk_buff pointer in the rx_buffer info structure which means the compiler is
>> not correctly stripping it out.
> These netdev_*() have nothing related with struct net_device, please
> find a better prefix. Also, they are in skbuff.h, you perhaps want to move them
> to netdevice.h.
The netdev_ prefix is really meant indicate where they are supposed to
be used, not so much the arguments being passed, and the fact that
historically this is what we had back in the kernel a couple years ago.
I suppose I could rename them to __dev_alloc_page(s) and
dev_alloc_page(s) since that seems to be the precedent for how this is
handled for skb's. I'll submit something tomorrow if there aren't any
other name requests.
I would prefer to keep them in skbuff.h since this is buffer allocation
that will later be handed off via either build_skb or skb_add_rx_frag to
an sk_buff.
Thanks,
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.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 1:57 UTC (permalink / raw)
To: Amir Vadai; +Cc: Wei Yang, Eric Dumazet, Eric Dumazet, David Miller, netdev
In-Reply-To: <54607095.6070302@mellanox.com>
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?
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
^ permalink raw reply
* [PATCH net] ipv6: fix IPV6_PKTINFO with v4 mapped
From: Eric Dumazet @ 2014-11-11 1:54 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Hannes Frederic Sowa
From: Eric Dumazet <edumazet@google.com>
Use IS_ENABLED(CONFIG_IPV6), to enable this code if IPv6 is
a module.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Fixes: c8e6ad0829a7 ("ipv6: honor IPV6_PKTINFO with v4 mapped addresses on sendmsg")
---
net/ipv4/ip_sockglue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 21894df662622bcb0f4bec01a2e612480276b92b..b7826575d2154dc67934d47adf90c7cd0fc40635 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -195,7 +195,7 @@ int ip_cmsg_send(struct net *net, struct msghdr *msg, struct ipcm_cookie *ipc,
for (cmsg = CMSG_FIRSTHDR(msg); cmsg; cmsg = CMSG_NXTHDR(msg, cmsg)) {
if (!CMSG_OK(msg, cmsg))
return -EINVAL;
-#if defined(CONFIG_IPV6)
+#if IS_ENABLED(CONFIG_IPV6)
if (allow_ipv6 &&
cmsg->cmsg_level == SOL_IPV6 &&
cmsg->cmsg_type == IPV6_PKTINFO) {
^ permalink raw reply related
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