* [PATCH net-next 6/6] ppc: bpf: Add SKF_AD_CPU for ppc32
From: Denis Kirjanov @ 2015-02-14 13:06 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, Denis Kirjanov
In-Reply-To: <1423919182-28618-1-git-send-email-kda@linux-powerpc.org>
Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
---
arch/powerpc/net/bpf_jit.h | 17 +++++++++++++++++
arch/powerpc/net/bpf_jit_comp.c | 14 +-------------
2 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
index 2d5e715..889fd19 100644
--- a/arch/powerpc/net/bpf_jit.h
+++ b/arch/powerpc/net/bpf_jit.h
@@ -154,6 +154,23 @@ DECLARE_LOAD_FUNC(sk_load_byte_msh);
#define PPC_LL_OFFS(r, base, i) do { PPC_LWZ_OFFS(r, base, i); } while(0)
#endif
+#ifdef CONFIG_SMP
+#ifdef CONFIG_PPC64
+#define PPC_BPF_LOAD_CPU(r) \
+ do { BUILD_BUG_ON(FIELD_SIZEOF(struct paca_struct, paca_index) != 2); \
+ PPC_LHZ_OFFS(r, 13, offsetof(struct paca_struct, paca_index)); \
+ } while (0)
+#else
+#define PPC_BPF_LOAD_CPU(r) \
+ do { BUILD_BUG_ON(FIELD_SIZEOF(struct thread_info, cpu) != 4); \
+ PPC_LHZ_OFFS(r, (1 & ~(THREAD_SIZE - 1)), \
+ offsetof(struct thread_info, cpu)); \
+ } while(0)
+#endif
+#else
+#define PPC_BPF_LOAD_CPU(r) do { PPC_LI(r, 0); } while(0)
+#endif
+
#define PPC_CMPWI(a, i) EMIT(PPC_INST_CMPWI | ___PPC_RA(a) | IMM_L(i))
#define PPC_CMPDI(a, i) EMIT(PPC_INST_CMPDI | ___PPC_RA(a) | IMM_L(i))
#define PPC_CMPLWI(a, i) EMIT(PPC_INST_CMPLWI | ___PPC_RA(a) | IMM_L(i))
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index 8b29268..17cea18 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -411,20 +411,8 @@ static int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
PPC_SRWI(r_A, r_A, 5);
break;
case BPF_ANC | SKF_AD_CPU:
-#ifdef CONFIG_SMP
- /*
- * PACA ptr is r13:
- * raw_smp_processor_id() = local_paca->paca_index
- */
- BUILD_BUG_ON(FIELD_SIZEOF(struct paca_struct,
- paca_index) != 2);
- PPC_LHZ_OFFS(r_A, 13,
- offsetof(struct paca_struct, paca_index));
-#else
- PPC_LI(r_A, 0);
-#endif
+ PPC_BPF_LOAD_CPU(r_A);
break;
-
/*** Absolute loads from packet header/data ***/
case BPF_LD | BPF_W | BPF_ABS:
func = CHOOSE_LOAD_FUNC(K, sk_load_word);
--
2.1.3
^ permalink raw reply related
* [PATCH] net/core: Fix warning while make xmldocs caused by dev.c
From: Masanari Iida @ 2015-02-14 13:26 UTC (permalink / raw)
To: monis, davem, linux-kernel, netdev; +Cc: Masanari Iida
This patch fix following warning wile make xmldocs.
Warning(.//net/core/dev.c:5345): No description found
for parameter 'bonding_info'
Warning(.//net/core/dev.c:5345): Excess function parameter
'netdev_bonding_info' description in 'netdev_bonding_info_change'
This warning starts to appear after following patch was added
into Linus's tree during merger period.
commit 61bd3857ff2c7daf756d49b41e6277bbdaa8f789
net/core: Add event for a change in slave state
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index d030575..2e8fcb0 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5335,7 +5335,7 @@ EXPORT_SYMBOL(netdev_upper_dev_unlink);
/**
* netdev_bonding_info_change - Dispatch event about slave change
* @dev: device
- * @netdev_bonding_info: info to dispatch
+ * @bonding_info: info to dispatch
*
* Send NETDEV_BONDING_INFO to netdev notifiers with info.
* The caller must hold the RTNL lock.
--
2.3.0
^ permalink raw reply related
* Re: Question on Bonding driver
From: Jay Vosburgh @ 2015-02-14 16:25 UTC (permalink / raw)
To: Murali Karicheri; +Cc: netdev, WingMan Kwok
In-Reply-To: <54DE3056.6020606@ti.com>
Murali Karicheri <m-karicheri2@ti.com> wrote:
>Hi,
>
>I am working to enable bonding driver on my hardware and trying to
>understand this.
>
>I am using the alb mode. I create a bond interface with 2 ethernet
>interfaces. First one is the basic question about net driver itself and
>second is about bonding.
>
>1. Each ethernet interface has a MAC address. The hardware has MAC filter
>and the driver fills the net_device's dev_addr with its MAC address before
>calling register_netdev() API. When the net core calls ndo_start(), is the
>low level driver responsible for setting up its MAC address in the MAC
>filter of the hardware or low level driver will be told to do so by upper
>layer. Or is it required to set it up as part of ndo_set_rx_mode() or
>ndo_set_mac_address()?
>
>2. In the case of bonding, the bond interface MAC address is copied from
>the active slave's MAC address. Also it updates the dev_addr in the netdev
>struct of each of the slave with its own MAC address. So I assume, the
>device/NIC now needs to accept packets to its original MAC address as well
>the bond's MAC address. This is especially more important for the slave's
>that are not active slave as it can be target of packets from Peers as
>part of rlb. So for the slave that is not active slave, MAC filter needs
>to include its original hw address as well unless the slave is put to
>promiscuous mode. So I am trying to figure out how this is expected to
>work? All slaves put to promiscuous mode or MAC filter updated by slave
>driver to include MAC addresses it is expected to filter on (bond MAC
>address and its own MAC address)
I'm travelling at the moment, but the short answer for #2 is
that the way the alb mode works is basically that the non-active slaves
only receive for their own individual MAC. Peers within the L2 network
are "assigned" to those slaves via tailored ARPs sent to the specific
peers. The slaves do not generally go into promisc mode (there are
exceptions during failover type events), nor are they programmed with
multiple unicast MAC addreeses.
I'd suggest you look at rlb_update_client in bond_alb.c and the
functions that call it to understand the logic.
-J
---
-Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* Re: [PATCH] net: ipv6: Make address flushing on ifdown optional - v3
From: Nicolas Dichtel @ 2015-02-14 16:49 UTC (permalink / raw)
To: David Ahern, netdev; +Cc: Hannes Frederic Sowa, Stephen Hemminger
In-Reply-To: <54DD73EE.8040807@gmail.com>
Le 13/02/2015 04:47, David Ahern a écrit :
> On 2/12/15 9:57 AM, Nicolas Dichtel wrote:
>> Le 12/02/2015 05:27, David Ahern a écrit :
>>> Currently, all ipv6 addresses are flushed when the interface is
>>> configured
>>> down, even static address:
>>>
>> [snip]
>>>
>>> [root@f20 ~]# echo 0 > /proc/sys/net/ipv6/conf/eth1/flush_addr_on_down
>>> [root@f20 ~]# ip -6 addr add dev eth1 2000:11:1:1::1/64
>>> [root@f20 ~]# ip addr show dev eth1
>>> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN
>>> group default qlen 1000
>>> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
>>> inet6 2000:11:1:1::1/64 scope global tentative
>>> valid_lft forever preferred_lft forever
>>> [root@f20 ~]# ip link set dev eth1 up
>>> [root@f20 ~]# ip link set dev eth1 down
>>> [root@f20 ~]# ip addr show dev eth1
>>> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN
>>> group default qlen 1000
>>> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
>>> inet6 2000:11:1:1::1/64 scope global
>>> valid_lft forever preferred_lft forever
>>> inet6 fe80::4:11ff:fe22:3301/64 scope link
>>> valid_lft forever preferred_lft forever
>> Can you show an output of 'ip -6 route list table local' and 'ip -6
>> route' ?
>
> hmmmm.... interesting. once again ipv6 behavior is radically different from ipv4.
>
> This is *after* a configure, up, down cycle:
>
> [root@f21 ~]# ip -6 route list table local
> local ::1 dev lo proto none metric 0
> local 2000:11:1:1::1 dev lo proto none metric 0
> local fe80::11:22ff:fe33:4402 dev lo proto none metric 0
> ff00::/8 dev eth0 metric 256
We also need to check netlink notifications. When you set an interface down, the
kernel doesn't send rtnl notifications for IPv6 routes. Daemons have to take
care of the ifdow notification.
If your patch is going to keep some routes after an ifdown, we need to have a
way in userland to know this.
Advertising the new sysctl (flush_addr_on_down) entry via netconf may be a
solution (Stephen already talks about this feature).
>
> [root@f21 ~]# ip -6 route ls
> unreachable ::/96 dev lo metric 1024 error -101
> unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 error -101
> unreachable 2002:a00::/24 dev lo metric 1024 error -101
> unreachable 2002:7f00::/24 dev lo metric 1024 error -101
> unreachable 2002:a9fe::/32 dev lo metric 1024 error -101
> unreachable 2002:ac10::/28 dev lo metric 1024 error -101
> unreachable 2002:c0a8::/32 dev lo metric 1024 error -101
> unreachable 2002:e000::/19 dev lo metric 1024 error -101
> unreachable 3ffe:ffff::/32 dev lo metric 1024 error -101
> fe80::/64 dev eth0 proto kernel metric 256
>
> (the ipv6 addresses on lo show up on stock 3.18.3-201.fc21.x86_64; no idea why)
>
> But on a subsequent ifconfig up the route is not inserted:
>
> [root@f21 ~]# ifconfig eth1 up
>
> [root@f21 ~]# ip -6 route ls
> unreachable ::/96 dev lo metric 1024 error -101
> unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 error -101
> unreachable 2002:a00::/24 dev lo metric 1024 error -101
> unreachable 2002:7f00::/24 dev lo metric 1024 error -101
> unreachable 2002:a9fe::/32 dev lo metric 1024 error -101
> unreachable 2002:ac10::/28 dev lo metric 1024 error -101
> unreachable 2002:c0a8::/32 dev lo metric 1024 error -101
> unreachable 2002:e000::/19 dev lo metric 1024 error -101
> unreachable 3ffe:ffff::/32 dev lo metric 1024 error -101
> fe80::/64 dev eth0 proto kernel metric 256
> fe80::/64 dev eth1 proto kernel metric 256
>
> So I need to look into why.
Yes. The patch will probably have to play with this connected route.
Regards,
Nicolas
^ permalink raw reply
* [PATCH iproute2] ip xfrm: Allow to specify "all" option for monitor
From: Vadim Kochan @ 2015-02-14 17:45 UTC (permalink / raw)
To: netdev; +Cc: Vadim Kochan
From: Vadim Kochan <vadim4j@gmail.com>
Just to be aligned with the usage output.
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
---
ip/xfrm_monitor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ip/xfrm_monitor.c b/ip/xfrm_monitor.c
index 79453e4..8aa6f49 100644
--- a/ip/xfrm_monitor.c
+++ b/ip/xfrm_monitor.c
@@ -374,7 +374,7 @@ int do_xfrm_monitor(int argc, char **argv)
groups = 0;
} else if (matches(*argv, "help") == 0) {
usage();
- } else {
+ } else if (strcmp(*argv, "all")) {
fprintf(stderr, "Argument \"%s\" is unknown, try \"ip xfrm monitor help\".\n", *argv);
exit(-1);
}
--
2.2.2
^ permalink raw reply related
* Re: vnet problem (bug? feature?)
From: Bill Fink @ 2015-02-14 18:17 UTC (permalink / raw)
To: Toerless Eckert; +Cc: Cong Wang, netdev
In-Reply-To: <20150214101547.GA9335@faui40p.informatik.uni-erlangen.de>
On Sat, 14 Feb 2015, Toerless Eckert wrote:
> Thanks for replying, Cong.
>
> On Fri, Feb 13, 2015 at 03:48:14PM -0800, Cong Wang wrote:
> > > - Created vnet pair
> > > - NOT putting them into different namespaces.
> > > - Unicast across them works fine.
> > > - When sending IP multicsast into one end, i can not receive it on the other side
> > > (with normal socket API applications).
> >
> > Hmm, what does your routing table look like?
> >
> > They are in the same namespace, so in the same stack, so their IP addresses
> > belong to the same stack.
>
> Sure, but it must be possible to send/receive multicast packets to/from a specific
> interface. For example link-local-scope multicast. Which works.
>
> Just repeated with a mint 17, 3.13 kernel, same result:
>
> ip link add name veth1 type veth peer name veth2
> ip addr add 10.0.0.1/24 dev veth1
> ip addr add 10.0.0.2/24 dev veth2
> ip link set dev veth1 up
> ip link set dev veth2 up
Did you try disabling reverse path filtering:
echo 0 > /proc/sys/net/ipv4/conf/veth1/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/veth2/rp_filter
Both veth1 and veth2 are in the same subnet, but only one
(presumably veth1) is the expected source for packets coming
from net 10, so when the muticast packets from a net 10
source arrive on veth2, they are rejected for arriving
on the wrong interface.
You could check this with "nstat -z | grep -i filter".
The above is an educated guess on my part, and could
be something completely different.
-Bill
> Receiver socket, eg: on veth2:
> socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)
> setsockopt(SO_REUSEADDR, 1)
> bind(0.0.0.0/<port>)
> setsockopt(IP_ADD_MEMBERSHIP, 224.0.0.33/10.0.0.2)
>
> check wih "netstat -gn" that there is IGMP membership on veth2:
> veth2 1 224.0.0.33
>
> Sender socket, eg: on veth1:
> socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)
> setsockopt(SO_REUSEADDR, 1)
> bind(10.0.0.1/7000)
> connect(224.0.0.33/<port>)
>
> Sending packet, check how they're transmitted:
> - TX countes on veth1 go up (ifconfig output)
> - RX counters on veth2 go up (ifconfig output)
> - tcpdump -i veth2 -P in shows packets being received
> - tcpdump -i veth1 -P out shows packets being sent
>
> Played around with lots of parameters:
> - same behavior for non-link-local-scope multicast, TTL > 1 doesn't elp.
> - same behavior if setting "multicast, "allmulticast", "promiscuous" on the veth
> - same behavior when setting IP_MULTICAST_LOOP on sender.
>
> Routing table:
> netstat -r -n
> Kernel IP routing table
> Destination Gateway Genmask Flags MSS Window irtt Iface
> 0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth1
> 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 veth1
> 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 veth2
> 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
>
> And of course it works if one side is put into a separate namespace,
> but that doesn't help me.
>
> But: it really seems to be a problem with the kernel/sockets, not with veth.
> Just replaced the veth pair with a pair of ethernets with a loopback cable and
> pretty much exactly the same result (except that receiver side does not see
> packets in RX unless it's promiscuous or has a real receiver socket, but that's
> perfect). But not being a veth problem but other kernel network stack "feature"
> doesn't make it right IMHO. I can't see by which "logic" the receiver socket
> seemingly does not care about these packets even though it's explicitly bound
> to the interface and the multicast group. "Gimme the darn packets, socket,
> they are received on the interface"! ;-))
>
> I can play around with the receiver side socket API call details, but i really
> don't see why those should be different if the packets happen to be looped
> than if they're not.
>
> Cheers
> Toerless
^ permalink raw reply
* [PATCH iproute2] ip xfrm mon: Add objects list to the usage output
From: Vadim Kochan @ 2015-02-14 18:07 UTC (permalink / raw)
To: netdev; +Cc: Vadim Kochan
From: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
---
ip/xfrm_monitor.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ip/xfrm_monitor.c b/ip/xfrm_monitor.c
index 79453e4..0b58d24 100644
--- a/ip/xfrm_monitor.c
+++ b/ip/xfrm_monitor.c
@@ -36,7 +36,8 @@ static void usage(void) __attribute__((noreturn));
static void usage(void)
{
- fprintf(stderr, "Usage: ip xfrm monitor [ all | LISTofXFRM-OBJECTS ]\n");
+ fprintf(stderr, "Usage: ip xfrm monitor [ all | OBJECTS | help ]\n");
+ fprintf(stderr, "OBJECTS := { acquire | expire | SA | aevent | policy | report }\n");
exit(-1);
}
--
2.2.2
^ permalink raw reply related
* [PATCH 1/2] net: dsa: mv88e6352: Refactor shareable code
From: Andrew Lunn @ 2015-02-14 18:17 UTC (permalink / raw)
To: davem, linux; +Cc: netdev, Andrew Lunn
In-Reply-To: <1423937871-9180-1-git-send-email-andrew@lunn.ch>
The mv88e6352 allows access to the port phys via an internal mdio bus
which is accessed using registers in the GLOBAL 2 range. The mv88e6171
and probably other devices use the same mechanism. Move this code into
the shared mv88e6xxx.c library.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/mv88e6352.c | 77 +++++++--------------------------------------
drivers/net/dsa/mv88e6xxx.c | 53 +++++++++++++++++++++++++++++++
drivers/net/dsa/mv88e6xxx.h | 6 ++++
3 files changed, 71 insertions(+), 65 deletions(-)
diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
index e13adc7b3dda..1ebd8f96072a 100644
--- a/drivers/net/dsa/mv88e6352.c
+++ b/drivers/net/dsa/mv88e6352.c
@@ -22,59 +22,6 @@
#include <net/dsa.h>
#include "mv88e6xxx.h"
-static int mv88e6352_wait(struct dsa_switch *ds, int reg, int offset, u16 mask)
-{
- unsigned long timeout = jiffies + HZ / 10;
-
- while (time_before(jiffies, timeout)) {
- int ret;
-
- ret = REG_READ(reg, offset);
- if (!(ret & mask))
- return 0;
-
- usleep_range(1000, 2000);
- }
- return -ETIMEDOUT;
-}
-
-static inline int mv88e6352_phy_wait(struct dsa_switch *ds)
-{
- return mv88e6352_wait(ds, REG_GLOBAL2, 0x18, 0x8000);
-}
-
-static inline int mv88e6352_eeprom_load_wait(struct dsa_switch *ds)
-{
- return mv88e6352_wait(ds, REG_GLOBAL2, 0x14, 0x0800);
-}
-
-static inline int mv88e6352_eeprom_busy_wait(struct dsa_switch *ds)
-{
- return mv88e6352_wait(ds, REG_GLOBAL2, 0x14, 0x8000);
-}
-
-static int __mv88e6352_phy_read(struct dsa_switch *ds, int addr, int regnum)
-{
- int ret;
-
- REG_WRITE(REG_GLOBAL2, 0x18, 0x9800 | (addr << 5) | regnum);
-
- ret = mv88e6352_phy_wait(ds);
- if (ret < 0)
- return ret;
-
- return REG_READ(REG_GLOBAL2, 0x19);
-}
-
-static int __mv88e6352_phy_write(struct dsa_switch *ds, int addr, int regnum,
- u16 val)
-{
- REG_WRITE(REG_GLOBAL2, 0x19, val);
- REG_WRITE(REG_GLOBAL2, 0x18, 0x9400 | (addr << 5) | regnum);
-
- return mv88e6352_phy_wait(ds);
-}
-
static char *mv88e6352_probe(struct device *host_dev, int sw_addr)
{
struct mii_bus *bus = dsa_host_dev_to_mii_bus(host_dev);
@@ -346,12 +293,12 @@ static int mv88e6352_phy_page_read(struct dsa_switch *ds,
int ret;
mutex_lock(&ps->phy_mutex);
- ret = __mv88e6352_phy_write(ds, port, 0x16, page);
+ ret = mv88e6xxx_phy_write_indirect(ds, port, 0x16, page);
if (ret < 0)
goto error;
- ret = __mv88e6352_phy_read(ds, port, reg);
+ ret = mv88e6xxx_phy_read_indirect(ds, port, reg);
error:
- __mv88e6352_phy_write(ds, port, 0x16, 0x0);
+ mv88e6xxx_phy_write_indirect(ds, port, 0x16, 0x0);
mutex_unlock(&ps->phy_mutex);
return ret;
}
@@ -363,13 +310,13 @@ static int mv88e6352_phy_page_write(struct dsa_switch *ds,
int ret;
mutex_lock(&ps->phy_mutex);
- ret = __mv88e6352_phy_write(ds, port, 0x16, page);
+ ret = mv88e6xxx_phy_write_indirect(ds, port, 0x16, page);
if (ret < 0)
goto error;
- ret = __mv88e6352_phy_write(ds, port, reg, val);
+ ret = mv88e6xxx_phy_write_indirect(ds, port, reg, val);
error:
- __mv88e6352_phy_write(ds, port, 0x16, 0x0);
+ mv88e6xxx_phy_write_indirect(ds, port, 0x16, 0x0);
mutex_unlock(&ps->phy_mutex);
return ret;
}
@@ -482,7 +429,7 @@ mv88e6352_phy_read(struct dsa_switch *ds, int port, int regnum)
return addr;
mutex_lock(&ps->phy_mutex);
- ret = __mv88e6352_phy_read(ds, addr, regnum);
+ ret = mv88e6xxx_phy_read_indirect(ds, addr, regnum);
mutex_unlock(&ps->phy_mutex);
return ret;
@@ -499,7 +446,7 @@ mv88e6352_phy_write(struct dsa_switch *ds, int port, int regnum, u16 val)
return addr;
mutex_lock(&ps->phy_mutex);
- ret = __mv88e6352_phy_write(ds, addr, regnum, val);
+ ret = mv88e6xxx_phy_write_indirect(ds, addr, regnum, val);
mutex_unlock(&ps->phy_mutex);
return ret;
@@ -553,7 +500,7 @@ static int mv88e6352_read_eeprom_word(struct dsa_switch *ds, int addr)
if (ret < 0)
goto error;
- ret = mv88e6352_eeprom_busy_wait(ds);
+ ret = mv88e6xxx_eeprom_busy_wait(ds);
if (ret < 0)
goto error;
@@ -576,7 +523,7 @@ static int mv88e6352_get_eeprom(struct dsa_switch *ds,
eeprom->magic = 0xc3ec4951;
- ret = mv88e6352_eeprom_load_wait(ds);
+ ret = mv88e6xxx_eeprom_load_wait(ds);
if (ret < 0)
return ret;
@@ -657,7 +604,7 @@ static int mv88e6352_write_eeprom_word(struct dsa_switch *ds, int addr,
if (ret < 0)
goto error;
- ret = mv88e6352_eeprom_busy_wait(ds);
+ ret = mv88e6xxx_eeprom_busy_wait(ds);
error:
mutex_unlock(&ps->eeprom_mutex);
return ret;
@@ -681,7 +628,7 @@ static int mv88e6352_set_eeprom(struct dsa_switch *ds,
len = eeprom->len;
eeprom->len = 0;
- ret = mv88e6352_eeprom_load_wait(ds);
+ ret = mv88e6xxx_eeprom_load_wait(ds);
if (ret < 0)
return ret;
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 3e7e31a6abb7..a83ace0803e7 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -596,6 +596,59 @@ error:
}
#endif /* CONFIG_NET_DSA_HWMON */
+static int mv88e6xxx_wait(struct dsa_switch *ds, int reg, int offset, u16 mask)
+{
+ unsigned long timeout = jiffies + HZ / 10;
+
+ while (time_before(jiffies, timeout)) {
+ int ret;
+
+ ret = REG_READ(reg, offset);
+ if (!(ret & mask))
+ return 0;
+
+ usleep_range(1000, 2000);
+ }
+ return -ETIMEDOUT;
+}
+
+int mv88e6xxx_phy_wait(struct dsa_switch *ds)
+{
+ return mv88e6xxx_wait(ds, REG_GLOBAL2, 0x18, 0x8000);
+}
+
+int mv88e6xxx_eeprom_load_wait(struct dsa_switch *ds)
+{
+ return mv88e6xxx_wait(ds, REG_GLOBAL2, 0x14, 0x0800);
+}
+
+int mv88e6xxx_eeprom_busy_wait(struct dsa_switch *ds)
+{
+ return mv88e6xxx_wait(ds, REG_GLOBAL2, 0x14, 0x8000);
+}
+
+int mv88e6xxx_phy_read_indirect(struct dsa_switch *ds, int addr, int regnum)
+{
+ int ret;
+
+ REG_WRITE(REG_GLOBAL2, 0x18, 0x9800 | (addr << 5) | regnum);
+
+ ret = mv88e6xxx_phy_wait(ds);
+ if (ret < 0)
+ return ret;
+
+ return REG_READ(REG_GLOBAL2, 0x19);
+}
+
+int mv88e6xxx_phy_write_indirect(struct dsa_switch *ds, int addr, int regnum,
+ u16 val)
+{
+ REG_WRITE(REG_GLOBAL2, 0x19, val);
+ REG_WRITE(REG_GLOBAL2, 0x18, 0x9400 | (addr << 5) | regnum);
+
+ return mv88e6xxx_phy_wait(ds);
+}
+
static int __init mv88e6xxx_init(void)
{
#if IS_ENABLED(CONFIG_NET_DSA_MV88E6131)
diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
index 03e397efde36..72942271bb67 100644
--- a/drivers/net/dsa/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx.h
@@ -82,6 +82,12 @@ int mv88e6xxx_get_regs_len(struct dsa_switch *ds, int port);
void mv88e6xxx_get_regs(struct dsa_switch *ds, int port,
struct ethtool_regs *regs, void *_p);
int mv88e6xxx_get_temp(struct dsa_switch *ds, int *temp);
+int mv88e6xxx_phy_wait(struct dsa_switch *ds);
+int mv88e6xxx_eeprom_load_wait(struct dsa_switch *ds);
+int mv88e6xxx_eeprom_busy_wait(struct dsa_switch *ds);
+int mv88e6xxx_phy_read_indirect(struct dsa_switch *ds, int addr, int regnum);
+int mv88e6xxx_phy_write_indirect(struct dsa_switch *ds, int addr, int regnum,
+ u16 val);
extern struct dsa_switch_driver mv88e6131_switch_driver;
extern struct dsa_switch_driver mv88e6123_61_65_switch_driver;
--
2.1.4
^ permalink raw reply related
* [PATCH 2/2] net: dsa: mv88e6171: Enable access to phys via internal mdio bus
From: Andrew Lunn @ 2015-02-14 18:17 UTC (permalink / raw)
To: davem, linux; +Cc: netdev, Andrew Lunn
In-Reply-To: <1423937871-9180-1-git-send-email-andrew@lunn.ch>
When the device is configured to use single chip addressing mode, the
phy devices of the port are not accessible on the host MDIO
bus. Instead the switch internal MDIO bus must be used. For this to
work, the phy polling unit must be enabled.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/mv88e6171.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/net/dsa/mv88e6171.c b/drivers/net/dsa/mv88e6171.c
index aa33d16f2e22..9808c860a797 100644
--- a/drivers/net/dsa/mv88e6171.c
+++ b/drivers/net/dsa/mv88e6171.c
@@ -51,8 +51,11 @@ static int mv88e6171_switch_reset(struct dsa_switch *ds)
/* Wait for transmit queues to drain. */
usleep_range(2000, 4000);
- /* Reset the switch. */
- REG_WRITE(REG_GLOBAL, 0x04, 0xc400);
+ /* Reset the switch. Keep PPU active. The PPU needs to be
+ * active to support indirect phy register accesses through
+ * global registers 0x18 and 0x19.
+ */
+ REG_WRITE(REG_GLOBAL, 0x04, 0xc000);
/* Wait up to one second for reset to complete. */
timeout = jiffies + 1 * HZ;
@@ -83,11 +86,10 @@ static int mv88e6171_setup_global(struct dsa_switch *ds)
int ret;
int i;
- /* Disable the PHY polling unit (since there won't be any
- * external PHYs to poll), don't discard packets with
- * excessive collisions, and mask all interrupt sources.
+ /* Discard packets with excessive collisions, mask all
+ * interrupt sources, enable PPU.
*/
- REG_WRITE(REG_GLOBAL, 0x04, 0x0000);
+ REG_WRITE(REG_GLOBAL, 0x04, 0x6000);
/* Set the default address aging time to 5 minutes, and
* enable address learn messages to be sent to all message
@@ -336,7 +338,7 @@ mv88e6171_phy_read(struct dsa_switch *ds, int port, int regnum)
int ret;
mutex_lock(&ps->phy_mutex);
- ret = mv88e6xxx_phy_read(ds, addr, regnum);
+ ret = mv88e6xxx_phy_read_indirect(ds, addr, regnum);
mutex_unlock(&ps->phy_mutex);
return ret;
}
@@ -350,7 +352,7 @@ mv88e6171_phy_write(struct dsa_switch *ds,
int ret;
mutex_lock(&ps->phy_mutex);
- ret = mv88e6xxx_phy_write(ds, addr, regnum, val);
+ ret = mv88e6xxx_phy_write_indirect(ds, addr, regnum, val);
mutex_unlock(&ps->phy_mutex);
return ret;
}
--
2.1.4
^ permalink raw reply related
* [PATCH 0/2] Indirect phy access for mv88e6171
From: Andrew Lunn @ 2015-02-14 18:17 UTC (permalink / raw)
To: davem, linux; +Cc: netdev, Andrew Lunn
These two patches allow the mv88e6171 driver to access the port phys
using indirect addressing. Depending on pin strapping, the switch
either uses a single address on the host MDIO bus, requiring the port
phys are accessed indirectly, or the switch uses a number of addresses
on the host bus and the phys can be directly accessed.
The 370RD, the first supported platform to use the 6171 uses multiple
addresses, so this indirect mode was not required. However the
WRT1900AC has the switch configured to use a single address, and so
indirect access is needed.
The mv88e6352 already has all the needed code. Refactor it into the
shared mv88e6xxx and then use it in the mv88e6171 driver.
Tested on the 370RD and WRT1900AC.
It would be good if Guenter Roeck could test on his platform to ensure
i've not broken anything for the mv88e6352.
Andrew Lunn (2):
net: dsa: mv88e6352: Refactor shareable code
net: dsa: mv88e6171: Enable access to phys via internal mdio bus
drivers/net/dsa/mv88e6171.c | 18 ++++++-----
drivers/net/dsa/mv88e6352.c | 77 +++++++--------------------------------------
drivers/net/dsa/mv88e6xxx.c | 53 +++++++++++++++++++++++++++++++
drivers/net/dsa/mv88e6xxx.h | 6 ++++
4 files changed, 81 insertions(+), 73 deletions(-)
--
2.1.4
^ permalink raw reply
* Re: [PATCH next v3 2/6] bonding: implement bond_poll_controller()
From: Mahesh Bandewar @ 2015-02-14 18:36 UTC (permalink / raw)
To: Jay Vosburgh
Cc: Andy Gospodarek, Veaceslav Falico, Nikolay Aleksandrov,
David Miller, Maciej Zenczykowski, netdev, Eric Dumazet
In-Reply-To: <23063.1423777544@famine>
On Thu, Feb 12, 2015 at 1:45 PM, Jay Vosburgh
<jay.vosburgh@canonical.com> wrote:
>
> Mahesh Bandewar <maheshb@google.com> wrote:
>
> >This patches implements the poll_controller support for all
> >bonding driver. If the slaves have poll_controller net_op defined,
> >this implementation calls them. This is mode agnostic implementation
> >and iterates through all slaves (based on mode) and calls respective
> >handler.
> >
> >Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> >---
> >v1:
> > Initial version
> >v2:
> > Eliminate bool variable.
> >v3:
> > Rebase
> >
> > drivers/net/bonding/bond_3ad.c | 24 ++++++++++++++++++++++++
> > drivers/net/bonding/bond_main.c | 33 +++++++++++++++++++++++++++++++++
> > include/net/bond_3ad.h | 1 +
> > 3 files changed, 58 insertions(+)
> >
> >diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
> >index 9b436696b95e..14f2ebe786c5 100644
> >--- a/drivers/net/bonding/bond_3ad.c
> >+++ b/drivers/net/bonding/bond_3ad.c
> >@@ -2477,6 +2477,30 @@ int bond_3ad_get_active_agg_info(struct bonding *bond, struct ad_info *ad_info)
> > return ret;
> > }
> >
> >+#define BOND_3AD_PORT_OPERATIONAL \
> >+ (AD_STATE_DISTRIBUTING | AD_STATE_COLLECTING | \
> >+ AD_STATE_SYNCHRONIZATION | AD_STATE_AGGREGATION)
> >+
> >+static int bond_3ad_port_operational(struct slave *slave)
> >+{
> >+ port_t *port = &SLAVE_AD_INFO(slave)->port;
> >+
> >+ return bond_slave_can_tx(slave) &&
> >+ (port->actor_oper_port_state & port->partner_oper.port_state &
> >+ BOND_3AD_PORT_OPERATIONAL) == BOND_3AD_PORT_OPERATIONAL;
> >+}
> >+
> >+/* bond_3ad_port_is_active - check if a slave port is active or not. A port
> >+ * is active when it can forward traffic.
> >+ *
> >+ * @slave: slave port to check state for.
> >+ * Returns: 0 if not active else is active.
> >+ */
> >+int bond_3ad_port_is_active(struct slave *slave)
> >+{
> >+ return bond_3ad_port_operational(slave);
> >+}
> >+
>
> Why the nesting here? I don't see other users of
> bond_3ad_port_operational, so why not move that logic to
> bond_3ad_port_is_active and eliminate the extra level of function call?
>
> Also, the test in bond_3ad_port_operational will exclude the
> case that the active agg port is Individual (e.g., link partner is not
> LACP-capable) as that case won't run the state machine to coll-dist
> state, but the agg is still available for TX/RX.
>
I missed this comment in the earlier reply. I wasn't sure if the
situation you described even works and hence I completely ignored that
case. Are you suggesting that this check can be eliminated and
replaced with just slave_can_tx() check? If not then what should be
the correct check?
Thanks,
--mahesh..
> -J
>
>
> > int bond_3ad_lacpdu_recv(const struct sk_buff *skb, struct bonding *bond,
> > struct slave *slave)
> > {
> >diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> >index b979c265fc51..8433fe464f95 100644
> >--- a/drivers/net/bonding/bond_main.c
> >+++ b/drivers/net/bonding/bond_main.c
> >@@ -928,6 +928,39 @@ static inline void slave_disable_netpoll(struct slave *slave)
> >
> > static void bond_poll_controller(struct net_device *bond_dev)
> > {
> >+ struct bonding *bond = netdev_priv(bond_dev);
> >+ struct slave *slave = NULL;
> >+ struct list_head *iter;
> >+ struct ad_info ad_info;
> >+ struct netpoll_info *ni;
> >+ const struct net_device_ops *ops;
> >+
> >+ if (BOND_MODE(bond) == BOND_MODE_8023AD)
> >+ if (bond_3ad_get_active_agg_info(bond, &ad_info))
> >+ return;
> >+
> >+ bond_for_each_slave(bond, slave, iter) {
> >+ ops = slave->dev->netdev_ops;
> >+ if (!bond_slave_is_up(slave) || !ops->ndo_poll_controller)
> >+ continue;
> >+
> >+ if (BOND_MODE(bond) == BOND_MODE_8023AD) {
> >+ struct aggregator *agg =
> >+ SLAVE_AD_INFO(slave)->port.aggregator;
> >+
> >+ if (agg && agg->aggregator_identifier !=
> >+ ad_info.aggregator_id)
> >+ continue;
> >+ if (!bond_3ad_port_is_active(slave) || ad_info.ports != 1)
> >+ continue;
>
> The above will exclude slaves that are in an aggregator with
> more than one member, which is likely to be the usual case. Is that
> intentional?
>
> Also, if this will only accept slaves from the active
> aggregator, and we're limiting it to case that the active agg has
> exactly one slave, why do we need to loop through all slaves of the
> bond? Could we do something (inside an "if (mode == 8023AD)" block)
> like:
>
> first_slave = bond_first_slave_rcu(bond);
> [...]
> agg = __get_active_agg(&(SLAVE_AD_INFO(first_slave)->aggregator));
> if (agg->num_of_ports != 1)
> return;
> slave = agg->lag_ports->slave;
> if (!bond_3ad_port_is_active(slave)
> return;
> [...]
> ops->ndo_poll_controller(slave->dev);
>
> That would need some checks, but, basically, go from the active
> aggregator directly to its list of slaves.
>
> -J
>
> >+ }
> >+
> >+ ni = rcu_dereference_bh(slave->dev->npinfo);
> >+ if (down_trylock(&ni->dev_lock))
> >+ continue;
> >+ ops->ndo_poll_controller(slave->dev);
> >+ up(&ni->dev_lock);
> >+ }
> > }
> >
> > static void bond_netpoll_cleanup(struct net_device *bond_dev)
> >diff --git a/include/net/bond_3ad.h b/include/net/bond_3ad.h
> >index f04cdbb7848e..6c455c646d61 100644
> >--- a/include/net/bond_3ad.h
> >+++ b/include/net/bond_3ad.h
> >@@ -278,5 +278,6 @@ int bond_3ad_lacpdu_recv(const struct sk_buff *skb, struct bonding *bond,
> > struct slave *slave);
> > int bond_3ad_set_carrier(struct bonding *bond);
> > void bond_3ad_update_lacp_rate(struct bonding *bond);
> >+int bond_3ad_port_is_active(struct slave *slave);
> > #endif /* _NET_BOND_3AD_H */
> >
> >--
> >2.2.0.rc0.207.ga3a616c
>
> ---
> -Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* Re: Fw: [Bug 93011] New: boilerplate IPVLAN Kconfig
From: Mahesh Bandewar @ 2015-02-14 18:40 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: linux-netdev
In-Reply-To: <20150209224913.24e48ffa@uryu.home.lan>
sure I'll send a patch correcting that soon.
On Mon, Feb 9, 2015 at 10:49 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
>
> Begin forwarded message:
>
> Date: Mon, 9 Feb 2015 22:06:03 +0000
> From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
> To: "shemminger@linux-foundation.org" <shemminger@linux-foundation.org>
> Subject: [Bug 93011] New: boilerplate IPVLAN Kconfig
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=93011
>
> Bug ID: 93011
> Summary: boilerplate IPVLAN Kconfig
> Product: Networking
> Version: 2.5
> Kernel Version: 3.19
> Hardware: All
> OS: Linux
> Tree: Mainline
> Status: NEW
> Severity: low
> Priority: P1
> Component: Other
> Assignee: shemminger@linux-foundation.org
> Reporter: bugzilla.kernel.bpeb@manchmal.in-ulm.de
> Regression: No
>
> Hi there,
>
> 3.19 introduced a new option IPVLAN, however the text in
> drivers/net/Kconfig still contains a template:
>
> | Ipvlan devices can be added using the "ip" command from the
> | iproute2 package starting with the iproute2-X.Y.ZZ release:
>
> Please update to the appropriate version number.
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.
> --
> 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 net-next] net: spelling fixes
From: Stephen Hemminger @ 2015-02-14 18:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Spelling errors caught by codespell.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
--- a/net/core/filter.c 2015-02-14 13:43:49.650827618 -0500
+++ b/net/core/filter.c 2015-02-14 13:43:49.646827774 -0500
@@ -531,7 +531,7 @@ do_pass:
*insn = BPF_LDX_MEM(BPF_W, BPF_REG_A, BPF_REG_CTX, fp->k);
break;
- /* Unkown instruction. */
+ /* Unknown instruction. */
default:
goto err;
}
--- a/net/core/pktgen.c 2015-02-14 13:43:49.650827618 -0500
+++ b/net/core/pktgen.c 2015-02-14 13:43:49.650827618 -0500
@@ -97,7 +97,7 @@
* New xmit() return, do_div and misc clean up by Stephen Hemminger
* <shemminger@osdl.org> 040923
*
- * Randy Dunlap fixed u64 printk compiler waring
+ * Randy Dunlap fixed u64 printk compiler warning
*
* Remove FCS from BW calculation. Lennert Buytenhek <buytenh@wantstofly.org>
* New time handling. Lennert Buytenhek <buytenh@wantstofly.org> 041213
--- a/net/ipv4/devinet.c 2015-02-14 13:43:49.650827618 -0500
+++ b/net/ipv4/devinet.c 2015-02-14 13:43:49.650827618 -0500
@@ -1186,7 +1186,7 @@ __be32 inet_select_addr(const struct net
no_in_dev:
/* Not loopback addresses on loopback should be preferred
- in this case. It is importnat that lo is the first interface
+ in this case. It is important that lo is the first interface
in dev_base list.
*/
for_each_netdev_rcu(net, dev) {
^ permalink raw reply
* [PATCH] nl80211: Fix possible leak in nl80211_new_interface on MONITOR_FLAG_ACTIVE
From: Christian Engelmayer @ 2015-02-14 19:52 UTC (permalink / raw)
To: johannes-cdvu00un1VgdHxzADdlk8Q
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Christian Engelmayer
In case of NL80211_IFTYPE_MONITOR and flag MONITOR_FLAG_ACTIVE, the already
allocated sk_buff 'msg' is not freed, when the function exits in case the
feature is not supported. Detected by Coverity CID 1269116.
Signed-off-by: Christian Engelmayer <cengelma-RbZlAiThDcE@public.gmane.org>
---
Compile tested only. Applies against linux-next.
---
net/wireless/nl80211.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index d78fd8b54515..38a7477dda81 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2663,8 +2663,10 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
&flags);
if (!err && (flags & MONITOR_FLAG_ACTIVE) &&
- !(rdev->wiphy.features & NL80211_FEATURE_ACTIVE_MONITOR))
+ !(rdev->wiphy.features & NL80211_FEATURE_ACTIVE_MONITOR)) {
+ nlmsg_free(msg);
return -EOPNOTSUPP;
+ }
wdev = rdev_add_virtual_intf(rdev,
nla_data(info->attrs[NL80211_ATTR_IFNAME]),
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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 related
* Re: [RFC net-next 3/4] openvswitch: Add conntrack action.
From: Thomas Graf @ 2015-02-14 19:56 UTC (permalink / raw)
To: Joe Stringer; +Cc: netdev, Justin Pettit, Pablo Neira Ayuso, dev
In-Reply-To: <1423901633-53789-4-git-send-email-joestringer@nicira.com>
On 02/14/15 at 12:13am, Joe Stringer wrote:
[..]
> +static bool skb_has_valid_nfct(const struct net *net, u16 zone,
> + const struct sk_buff *skb)
> +{
> + enum ip_conntrack_info ctinfo;
> + struct nf_conn *ct = nf_ct_get(skb, &ctinfo);
> +
> + if (!ct)
> + return false;
> + if (!net_eq(net, ct->ct_net))
> + return false;
I'm surprised that this is needed. Shouldn't we call skb_scrub_packet()
between namespaces and invalidate the ct associated with the skb.
^ permalink raw reply
* Re: [PATCH 3/5] virtio: Don't expose legacy net features when VIRTIO_NET_NO_LEGACY defined.
From: Michael S. Tsirkin @ 2015-02-14 20:43 UTC (permalink / raw)
To: Rusty Russell; +Cc: lkml, netdev@vger.kernel.org
In-Reply-To: <20150208105908.GI3185@redhat.com>
On Sun, Feb 08, 2015 at 11:59:08AM +0100, Michael S. Tsirkin wrote:
> On Fri, Feb 06, 2015 at 03:36:54PM +1030, Rusty Russell wrote:
> > In particular, the virtio header always has the u16 num_buffers field.
> > We define a new 'struct virtio_net_modern_hdr' for this (rather than
> > simply calling it 'struct virtio_net_hdr', to avoid nasty type errors
> > if some parts of a project define VIRTIO_NET_NO_LEGACY and some don't.
> >
> > Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
> > ---
> > include/uapi/linux/virtio_net.h | 30 ++++++++++++++++++++++++++++--
> > 1 file changed, 28 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
> > index b5f1677b291c..32754f3000e8 100644
> > --- a/include/uapi/linux/virtio_net.h
> > +++ b/include/uapi/linux/virtio_net.h
> > @@ -35,7 +35,6 @@
> > #define VIRTIO_NET_F_CSUM 0 /* Host handles pkts w/ partial csum */
> > #define VIRTIO_NET_F_GUEST_CSUM 1 /* Guest handles pkts w/ partial csum */
> > #define VIRTIO_NET_F_MAC 5 /* Host has given MAC address. */
> > -#define VIRTIO_NET_F_GSO 6 /* Host handles pkts w/ any GSO type */
> > #define VIRTIO_NET_F_GUEST_TSO4 7 /* Guest can handle TSOv4 in. */
> > #define VIRTIO_NET_F_GUEST_TSO6 8 /* Guest can handle TSOv6 in. */
> > #define VIRTIO_NET_F_GUEST_ECN 9 /* Guest can handle TSO[6] w/ ECN in. */
> > @@ -56,6 +55,10 @@
> > * Steering */
> > #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
> >
> > +#ifndef VIRTIO_NET_NO_LEGACY
> > +#define VIRTIO_NET_F_GSO 6 /* Host handles pkts w/ any GSO type */
> > +#endif /* VIRTIO_NET_NO_LEGACY */
> > +
> > #define VIRTIO_NET_S_LINK_UP 1 /* Link is up */
> > #define VIRTIO_NET_S_ANNOUNCE 2 /* Announcement is needed */
> >
> > @@ -71,8 +74,9 @@ struct virtio_net_config {
> > __u16 max_virtqueue_pairs;
> > } __attribute__((packed));
> >
> > +#ifndef VIRTIO_NET_NO_LEGACY
> > /* This header comes first in the scatter-gather list.
> > - * If VIRTIO_F_ANY_LAYOUT is not negotiated, it must
> > + * For legacy virtio, if VIRTIO_F_ANY_LAYOUT is not negotiated, it must
> > * be the first element of the scatter-gather list. If you don't
> > * specify GSO or CSUM features, you can simply ignore the header. */
> > struct virtio_net_hdr {
> > @@ -97,6 +101,28 @@ struct virtio_net_hdr_mrg_rxbuf {
> > struct virtio_net_hdr hdr;
> > __virtio16 num_buffers; /* Number of merged rx buffers */
> > };
> > +#else /* ... VIRTIO_NET_NO_LEGACY */
> > +/*
> > + * This header comes first in the scatter-gather list. If you don't
> > + * specify GSO or CSUM features, you can simply ignore the header.
> > + */
> > +struct virtio_net_modern_hdr {
> > +#define VIRTIO_NET_HDR_F_NEEDS_CSUM 1 /* Use csum_start, csum_offset */
> > +#define VIRTIO_NET_HDR_F_DATA_VALID 2 /* Csum is valid */
> > + __u8 flags;
> > +#define VIRTIO_NET_HDR_GSO_NONE 0 /* Not a GSO frame */
> > +#define VIRTIO_NET_HDR_GSO_TCPV4 1 /* GSO frame, IPv4 TCP (TSO) */
> > +#define VIRTIO_NET_HDR_GSO_UDP 3 /* GSO frame, IPv4 UDP (UFO) */
> > +#define VIRTIO_NET_HDR_GSO_TCPV6 4 /* GSO frame, IPv6 TCP */
> > +#define VIRTIO_NET_HDR_GSO_ECN 0x80 /* TCP has ECN set */
> > + __u8 gso_type;
> > + __virtio16 hdr_len; /* Ethernet + IP + tcp/udp hdrs */
> > + __virtio16 gso_size; /* Bytes to append to hdr_len per frame */
> > + __virtio16 csum_start; /* Position to start checksumming from */
> > + __virtio16 csum_offset; /* Offset after that to place checksum */
> > + __virtio16 num_buffers; /* Number of merged rx buffers */
> > +};
> > +#endif /* ...VIRTIO_NET_NO_LEGACY */
>
> This kind of masks the fact that it's the same as
> virtio_net_hdr_mrg_rxbuf. So it's forcing people to duplicate
> code for transitional devices.
>
> How about
> struct virtio_net_modern_hdr {
> struct virtio_net_hdr_mrg_rxbuf hdr;
> }
>
>
> This will also make it look nicer when we start
> adding stuff in the header, the main header
> is separated in a struct by its own, so it's
> easy to apply operations such as sizeof.
Ping.
Would you like a patch on top that does this?
>
> > /*
> > * Control virtqueue data structures
> > --
> > 2.1.0
^ permalink raw reply
* Re: [PATCH net-next] tcp: do not pace pure ack packets
From: Or Gerlitz @ 2015-02-14 20:45 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, Kenneth Klette Jonassen, john fastabend
In-Reply-To: <1423017113.907.76.camel@edumazet-glaptop2.roam.corp.google.com>
On Wed, Feb 4, 2015 at 4:31 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> When we added pacing to TCP, we decided to let sch_fq take care
> of actual pacing.
>
> All TCP had to do was to compute sk->pacing_rate using simple formula:
>
> sk->pacing_rate = 2 * cwnd * mss / rtt
>
> It works well for senders (bulk flows), but not very well for receivers
> or even RPC :
>
> cwnd on the receiver can be less than 10, rtt can be around 100ms, so we
> can end up pacing ACK packets, slowing down the sender.
> Really, only the sender should pace, according to its own logic.
[...]
> This patch is a combination of two patches we used for about one year at Google.
Wow, so what is the black box impact on systems running without the
fix, pacing works but also un-needed slow downs
are introduced, right?
Sounds to me as something we really want to push into -stable, isn't that?
Do you think we need to let the patch rot for a while in 3.20-rc or we
can do it right away?
Or
^ permalink raw reply
* Re: [PATCH] at86rf230: assign wait_for_completion_timeout to appropriately typed var
From: Alexander Aring @ 2015-02-14 21:34 UTC (permalink / raw)
To: Nicholas Mc Guire; +Cc: linux-wpan, netdev, linux-kernel, marcel
In-Reply-To: <20150208093428.GA10594@omega>
On Sun, Feb 08, 2015 at 10:34:34AM +0100, Alexander Aring wrote:
> On Sun, Feb 08, 2015 at 03:55:00AM -0500, Nicholas Mc Guire wrote:
> > return type of wait_for_completion_timeout is unsigned long not int.
> > As rc is used here only for wait_for_completion_timeout the type is simply
> > changed to unsigned long.
> >
> > Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
>
> Acked-by: Alexander Aring <alex.aring@gmail.com>
>
> Marcel, can you please queue this for bluetooth-next. Should be able to
> apply against bluetooth-next. Thanks.
>
Marcel, ping.
- Alex
^ permalink raw reply
* Re: [PATCH] at86rf230: assign wait_for_completion_timeout to appropriately typed var
From: Marcel Holtmann @ 2015-02-14 21:48 UTC (permalink / raw)
To: Alexander Aring; +Cc: Nicholas Mc Guire, linux-wpan, netdev, linux-kernel
In-Reply-To: <20150214213422.GB4035@omega>
Hi Alex,
>>> return type of wait_for_completion_timeout is unsigned long not int.
>>> As rc is used here only for wait_for_completion_timeout the type is simply
>>> changed to unsigned long.
>>>
>>> Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
>>
>> Acked-by: Alexander Aring <alex.aring@gmail.com>
>>
>> Marcel, can you please queue this for bluetooth-next. Should be able to
>> apply against bluetooth-next. Thanks.
>>
>
> Marcel, ping.
my apologizes, but this one never made it to my archive. Please resend and I apply it.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls
From: Alexei Starovoitov @ 2015-02-14 22:48 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Steven Rostedt, Ingo Molnar, Namhyung Kim,
Arnaldo Carvalho de Melo, Jiri Olsa, Masami Hiramatsu, Linux API,
Network Development, LKML, Linus Torvalds, Eric W. Biederman
On Wed, Feb 11, 2015 at 5:28 AM, Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
>
> We're compiling the BPF stuff against the 'current' kernel headers
> right?
the tracex1 example is pulling kernel headers to demonstrate
how bpf_fetch*() helpers can be used to walk kernel structures
without debug info.
The other examples don't need any internal headers.
> So would enforcing module versioning not be sufficient?
I'm going to redo the ex1 to use kprobe and some form of
version check. Indeed module-like versioning should
be enough.
^ permalink raw reply
* Re: [PATCH v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls
From: Alexei Starovoitov @ 2015-02-14 22:54 UTC (permalink / raw)
To: Steven Rostedt
Cc: Ingo Molnar, Namhyung Kim, Arnaldo Carvalho de Melo, Jiri Olsa,
Masami Hiramatsu, Linux API, Network Development, LKML,
Linus Torvalds, Peter Zijlstra, Eric W. Biederman
On Wed, Feb 11, 2015 at 7:51 AM, Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org> wrote:
> On Tue, 10 Feb 2015 22:33:05 -0800
> Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org> wrote:
>
>
>> fair enough.
>> Something like TRACE_MARKER(arg1, arg2) that prints
>> it was hit without accessing the args would be enough.
>> Without any args it is indeed a 'fast kprobe' only.
>> Debug info would still be needed to access
>> function arguments.
>> On x64 function entry point and x64 abi make it easy
>> to access args, but i386 or kprobe in the middle
>> lose visibility when debug info is not available.
>> TRACE_MARKER (with few key args that function
>> is operating on) is enough to achieve roughly the same
>> as kprobe without debug info.
>
> Actually, what about a TRACE_EVENT_DEBUG(), that has a few args and
> possibly a full trace event layout.
>
> The difference would be that the trace events do not show up unless you
> have "trace_debug" on the command line. This should prevent
> applications from depending on them.
>
> I could even do the nasty dmesg output like I do with trace_printk()s,
> that would definitely keep a production kernel from adding it by
> default.
>
> When trace_debug is not there, the trace points could still be accessed
> but perhaps only via bpf, or act like a simple trace marker.
I think that is a great idea!
Makes it clear that all prints are for debugging and
no abi guarantees.
> Note, if you need ids, I rather have them in another directory than
> tracefs. Make a eventfs perhaps that holds these. I rather keep tracefs
> simple.
indeed. makes sense. no reason to burn fs memory just
to get an id from name. may be perf_event api can be
extended to lookup id from name. I think perf will benefit as well.
^ permalink raw reply
* Re: [PATCH v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls
From: Alexei Starovoitov @ 2015-02-14 23:02 UTC (permalink / raw)
To: Hekuang
Cc: Steven Rostedt, Ingo Molnar, Namhyung Kim,
Arnaldo Carvalho de Melo, Jiri Olsa, Masami Hiramatsu, Linux API,
Network Development, LKML, Linus Torvalds, Peter Zijlstra,
Eric W. Biederman, wangnan0-hv44wF8Li93QT0dZR+AlfA
On Wed, Feb 11, 2015 at 11:58 PM, Hekuang <hekuang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote:
>
>>> eBPF is very flexible, which means it is bound to have someone use it
>>> in a way you never dreamed of, and that will be what bites you in the
>>> end (pun intended).
>>
>> understood :)
>> let's start slow then with bpf+syscall and bpf+kprobe only.
>
>
> I think BPF + system calls/kprobes can meet our use case
> (https://lkml.org/lkml/2015/2/6/44), but there're some issues to be
> improved.
>
> I suggest that you can improve bpf+kprobes when attached to function
> headers(or TRACE_MARKERS), make it converts pt-regs to bpf_ctx->arg1,
> arg2.., then top models and architectures can be separated by bpf.
>
> BPF bytecode is cross-platform, but what we can get by using bpf+kprobes
> is a 'regs->rdx' kind of information, such information is both
> architecture and kernel version related.
for kprobes in the middle of the function, kernel cannot
convert pt_regs into argN. Placement was decided by compiler
and can only be found in debug info.
I think bpf+kprobe will be using it when it is available.
When there is no debug info, kprobes will be limited
to function entry and mapping of regs/stack into
argN can be done by user space depending on architecture.
So user tracing scripts in some higher level language
can be kernel/arch independent when 'perf probe+bpf'
is loading them on the fly on the given machine.
> We hope to establish some models for describing kernel procedures such
> as IO and network, which requires that it does not rely on architecture
> and does not rely to a specific kernel version as much as possible.
That's obviously a goal, but it requires a new approach to tracepoints.
I think a lot of great ideas were discussed in this thread, so I'm
hopeful that we'll come up with solution that will satisfy even
strictest Peter's requirements :)
^ permalink raw reply
* Re: [PATCH v3] brcmfmac: avoid duplicated suspend/resume operation
From: Fu, Zhonghui @ 2015-02-15 2:40 UTC (permalink / raw)
To: Kalle Valo, brudley-dY08KVG/lbpWk0Htik3J/w, Arend van Spriel,
Franky Lin, meuleman-dY08KVG/lbpWk0Htik3J/w,
linville-2XuSBdqkA4R54TAoqtyWWQ, pieterpg-dY08KVG/lbpWk0Htik3J/w,
hdegoede-H+wXaHxf7aLQT0dZR+AlfA, wens-jdAy2FN1RRM,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
brcm80211-dev-list-dY08KVG/lbpWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <54DC1D7D.5050407-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Any comments to this patch? Can it be accepted?
Thanks,
Zhonghui
On 2015/2/12 11:26, Fu, Zhonghui wrote:
> From a05d35ab334c20970c236fb971dae88810078c88 Mon Sep 17 00:00:00 2001
> From: Fu Zhonghui <zhonghui.fu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Date: Thu, 12 Feb 2015 10:49:35 +0800
> Subject: [PATCH v3] brcmfmac: avoid duplicated suspend/resume operation
>
> WiFi chip has 2 SDIO functions, and PM core will trigger
> twice suspend/resume operations for one WiFi chip to do
> the same things. This patch avoid this case.
>
> Acked-by: Arend van Spriel <arend-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Fu Zhonghui <zhonghui.fu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> ---
> Changes in v3:
> - Rebase to wireless-drivers-next/master branch
>
> drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
> index 7944224..b8832a7 100644
> --- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
> +++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
> @@ -1117,9 +1117,13 @@ static int brcmf_ops_sdio_suspend(struct device *dev)
> struct brcmf_bus *bus_if;
> struct brcmf_sdio_dev *sdiodev;
> mmc_pm_flag_t sdio_flags;
> + struct sdio_func *func = dev_to_sdio_func(dev);
>
> brcmf_dbg(SDIO, "Enter\n");
>
> + if (func->num == 2)
> + return 0;
> +
> bus_if = dev_get_drvdata(dev);
> sdiodev = bus_if->bus_priv.sdio;
>
> @@ -1148,9 +1152,16 @@ static int brcmf_ops_sdio_suspend(struct device *dev)
> static int brcmf_ops_sdio_resume(struct device *dev)
> {
> struct brcmf_bus *bus_if = dev_get_drvdata(dev);
> - struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
> + struct brcmf_sdio_dev *sdiodev;
> + struct sdio_func *func = dev_to_sdio_func(dev);
>
> brcmf_dbg(SDIO, "Enter\n");
> +
> + if (func->num == 2)
> + return 0;
> +
> + sdiodev = bus_if->bus_priv.sdio;
> +
> if (sdiodev->pdata && sdiodev->pdata->oob_irq_supported)
> disable_irq_wake(sdiodev->pdata->oob_irq_nr);
> brcmf_sdio_wd_timer(sdiodev->bus, BRCMF_WD_POLL_MS);
> -- 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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: [PATCH v3] brcmfmac: avoid duplicated suspend/resume operation
From: Pat Erley @ 2015-02-15 3:27 UTC (permalink / raw)
To: Fu, Zhonghui, Kalle Valo, brudley, Arend van Spriel, Franky Lin,
meuleman, linville, pieterpg, hdegoede, wens, linux-wireless,
brcm80211-dev-list, netdev, linux-kernel@vger.kernel.org
In-Reply-To: <54E0072D.3020802@linux.intel.com>
On 02/14/2015 08:40 PM, Fu, Zhonghui wrote:
>
> Any comments to this patch? Can it be accepted?
>
> Thanks,
> Zhonghui
>
> On 2015/2/12 11:26, Fu, Zhonghui wrote:
>> From a05d35ab334c20970c236fb971dae88810078c88 Mon Sep 17 00:00:00 2001
>> From: Fu Zhonghui <zhonghui.fu@linux.intel.com>
>> Date: Thu, 12 Feb 2015 10:49:35 +0800
>> Subject: [PATCH v3] brcmfmac: avoid duplicated suspend/resume operation
>>
>> WiFi chip has 2 SDIO functions, and PM core will trigger
>> twice suspend/resume operations for one WiFi chip to do
>> the same things. This patch avoid this case.
>>
>> Acked-by: Arend van Spriel <arend@broadcom.com>
>> Signed-off-by: Fu Zhonghui <zhonghui.fu@linux.intel.com>
>> ---
>> Changes in v3:
>> - Rebase to wireless-drivers-next/master branch
>>
>> drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 13 ++++++++++++-
>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>> index 7944224..b8832a7 100644
>> --- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>> +++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>> @@ -1117,9 +1117,13 @@ static int brcmf_ops_sdio_suspend(struct device *dev)
>> struct brcmf_bus *bus_if;
>> struct brcmf_sdio_dev *sdiodev;
>> mmc_pm_flag_t sdio_flags;
>> + struct sdio_func *func = dev_to_sdio_func(dev);
>>
>> brcmf_dbg(SDIO, "Enter\n");
>>
>> + if (func->num == 2)
>> + return 0;
>> +
Should it be >= 2 instead of == 2 so that if, in the future, a 3+
SDIO function chip comes out, it's already handled? Not that that
should hold up the patch or anything, just a curiosity.
>> bus_if = dev_get_drvdata(dev);
>> sdiodev = bus_if->bus_priv.sdio;
>>
>> @@ -1148,9 +1152,16 @@ static int brcmf_ops_sdio_suspend(struct device *dev)
>> static int brcmf_ops_sdio_resume(struct device *dev)
>> {
>> struct brcmf_bus *bus_if = dev_get_drvdata(dev);
>> - struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
>> + struct brcmf_sdio_dev *sdiodev;
>> + struct sdio_func *func = dev_to_sdio_func(dev);
>>
>> brcmf_dbg(SDIO, "Enter\n");
>> +
>> + if (func->num == 2)
>> + return 0;
>> +
>> + sdiodev = bus_if->bus_priv.sdio;
>> +
>> if (sdiodev->pdata && sdiodev->pdata->oob_irq_supported)
>> disable_irq_wake(sdiodev->pdata->oob_irq_nr);
>> brcmf_sdio_wd_timer(sdiodev->bus, BRCMF_WD_POLL_MS);
>> -- 1.9.1
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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] openvswitch: Fix key serialization.
From: David Miller @ 2015-02-15 4:21 UTC (permalink / raw)
To: pshelar; +Cc: netdev, joestringer
In-Reply-To: <1423763928-1554-1-git-send-email-pshelar@nicira.com>
From: Pravin B Shelar <pshelar@nicira.com>
Date: Thu, 12 Feb 2015 09:58:48 -0800
> Fix typo where mask is used rather than key.
>
> Fixes: 74ed7ab9264("openvswitch: Add support for unique flow IDs.")
> Reported-by: Joe Stringer <joestringer@nicira.com>
> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Applied.
^ 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