* [PATCH 3/3] macvlan: export macvlan mode through netlink
From: Arnd Bergmann @ 2009-11-17 22:39 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, David Miller, Stephen Hemminger, Herbert Xu,
Patrick McHardy, Patrick Mullaney, Eric W. Biederman,
Edge Virtual Bridging, Anna Fischer, bridge, virtualization,
Jens Osterkamp, Gerhard Stenzel, Arnd Bergmann
In-Reply-To: <1258497551-25959-1-git-send-email-arnd@arndb.de>
In order to support all three modes of macvlan at
runtime, extend the existing netlink protocol
to allow choosing the mode per macvlan slave
interface.
This depends on a matching patch to iproute2
in order to become accessible in user land.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/macvlan.c | 67 +++++++++++++++++++++++++++++++++++++++++-----
include/linux/if_link.h | 15 ++++++++++
2 files changed, 74 insertions(+), 8 deletions(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index fa8b568..731017e 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -33,12 +33,6 @@
#define MACVLAN_HASH_SIZE (1 << BITS_PER_BYTE)
-enum macvlan_type {
- MACVLAN_PRIVATE = 1,
- MACVLAN_VEPA = 2,
- MACVLAN_BRIDGE = 4,
-};
-
struct macvlan_port {
struct net_device *dev;
struct hlist_head vlan_hash[MACVLAN_HASH_SIZE];
@@ -51,7 +45,7 @@ struct macvlan_dev {
struct hlist_node hlist;
struct macvlan_port *port;
struct net_device *lowerdev;
- enum macvlan_mode mode;
+ enum ifla_macvlan_mode mode;
};
@@ -112,7 +106,7 @@ static int macvlan_addr_busy(const struct macvlan_port *port,
static void macvlan_broadcast(struct sk_buff *skb,
const struct macvlan_port *port,
struct net_device *src,
- enum macvlan_mode mode)
+ enum ifla_macvlan_mode mode)
{
const struct ethhdr *eth = eth_hdr(skb);
const struct macvlan_dev *vlan;
@@ -553,6 +547,18 @@ static int macvlan_validate(struct nlattr *tb[], struct nlattr *data[])
if (!is_valid_ether_addr(nla_data(tb[IFLA_ADDRESS])))
return -EADDRNOTAVAIL;
}
+
+ if (data && data[IFLA_MACVLAN_MODE]) {
+ u32 mode = nla_get_u32(data[IFLA_MACVLAN_MODE]);
+ switch (mode) {
+ case MACVLAN_MODE_PRIVATE:
+ case MACVLAN_MODE_VEPA:
+ case MACVLAN_MODE_BRIDGE:
+ break;
+ default:
+ return -EINVAL;
+ }
+ }
return 0;
}
@@ -617,6 +623,13 @@ static int macvlan_newlink(struct net_device *dev,
vlan->dev = dev;
vlan->port = port;
+ vlan->mode = MACVLAN_MODE_VEPA;
+ if (data && data[IFLA_MACVLAN_MODE]) {
+ u32 mode = nla_get_u32(data[IFLA_MACVLAN_MODE]);
+
+ vlan->mode = mode;
+ }
+
err = register_netdevice(dev);
if (err < 0)
return err;
@@ -638,6 +651,39 @@ static void macvlan_dellink(struct net_device *dev)
macvlan_port_destroy(port->dev);
}
+static int macvlan_changelink(struct net_device *dev,
+ struct nlattr *tb[], struct nlattr *data[])
+{
+ struct macvlan_dev *vlan = netdev_priv(dev);
+ if (data && data[IFLA_MACVLAN_MODE]) {
+ u32 mode = nla_get_u32(data[IFLA_MACVLAN_MODE]);
+ vlan->mode = mode;
+ }
+
+ return 0;
+}
+
+static size_t macvlan_get_size(const struct net_device *dev)
+{
+ return nla_total_size(4);
+}
+
+static int macvlan_fill_info(struct sk_buff *skb,
+ const struct net_device *dev)
+{
+ struct macvlan_dev *vlan = netdev_priv(dev);
+
+ NLA_PUT_U32(skb, IFLA_MACVLAN_MODE, vlan->mode);
+ return 0;
+
+nla_put_failure:
+ return -EMSGSIZE;
+}
+
+static const struct nla_policy macvlan_policy[IFLA_MACVLAN_MAX + 1] = {
+ [IFLA_MACVLAN_MODE] = { .type = NLA_U32 },
+};
+
static struct rtnl_link_ops macvlan_link_ops __read_mostly = {
.kind = "macvlan",
.priv_size = sizeof(struct macvlan_dev),
@@ -646,6 +692,11 @@ static struct rtnl_link_ops macvlan_link_ops __read_mostly = {
.validate = macvlan_validate,
.newlink = macvlan_newlink,
.dellink = macvlan_dellink,
+ .maxtype = IFLA_MACVLAN_MAX,
+ .policy = macvlan_policy,
+ .changelink = macvlan_changelink,
+ .get_size = macvlan_get_size,
+ .fill_info = macvlan_fill_info,
};
static int macvlan_device_event(struct notifier_block *unused,
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index 176c518..ef70ebc 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -190,4 +190,19 @@ struct ifla_vlan_qos_mapping
__u32 to;
};
+/* MACVLAN section */
+enum {
+ IFLA_MACVLAN_UNSPEC,
+ IFLA_MACVLAN_MODE,
+ __IFLA_MACVLAN_MAX,
+};
+
+#define IFLA_MACVLAN_MAX (__IFLA_MACVLAN_MAX - 1)
+
+enum ifla_macvlan_mode {
+ MACVLAN_MODE_PRIVATE = 1, /* don't talk to other macvlans */
+ MACVLAN_MODE_VEPA = 2, /* talk to other ports through ext bridge */
+ MACVLAN_MODE_BRIDGE = 4, /* talk to bridge ports directly */
+};
+
#endif /* _LINUX_IF_LINK_H */
--
1.6.3.3
^ permalink raw reply related
* [PATCH] iplink: add macvlan options for bridge mode
From: Arnd Bergmann @ 2009-11-17 22:39 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, David Miller, Stephen Hemminger, Herbert Xu,
Patrick McHardy, Patrick Mullaney, Eric W. Biederman,
Edge Virtual Bridging, Anna Fischer, bridge, virtualization,
Jens Osterkamp, Gerhard Stenzel, Arnd Bergmann
In-Reply-To: <1258497551-25959-1-git-send-email-arnd@arndb.de>
Macvlan can now optionally support forwarding between its
ports, if they are in "bridge" mode. This adds support
for this option to "ip link add", "ip link set" and "ip
-d link show".
The default mode in the kernel is now "vepa" mode, meaning
"virtual ethernet port aggregator". This mode is used
together with the "hairpin" mode of an ethernet bridge
that the parent of the macvlan device is connected to.
All frames still get sent out to the external interface,
but the adjacent bridge is able to send them back on
the same wire in hairpin mode, so the macvlan ports
are able to see each other, which the bridge can be
configured to monitor and control traffic between
all macvlan instances. Multicast traffic coming in
from the external interface is checked for the source
MAC address and only delivered to ports that have not
yet seen it.
In bridge mode, macvlan will send all multicast traffic
to other interfaces that are also in bridge mode but
not to those in vepa mode, which get them on the way
back from the hairpin.
The third supported mode is "private", which prevents
communication between macvlans even if the adjacent
bridge is in hairpin mode. This behavior is closer to
the original implementation of macvlan but stricly
maintains isolation.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/linux/if_link.h | 15 ++++++++
ip/Makefile | 3 +-
ip/iplink_macvlan.c | 93 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 110 insertions(+), 1 deletions(-)
create mode 100644 ip/iplink_macvlan.c
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index b0b9e8a..425c489 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -188,4 +188,19 @@ struct ifla_vlan_qos_mapping
__u32 to;
};
+/* MACVLAN section */
+enum {
+ IFLA_MACVLAN_UNSPEC,
+ IFLA_MACVLAN_MODE,
+ __IFLA_MACVLAN_MAX,
+};
+
+enum ifla_macvlan_mode {
+ MACVLAN_MODE_PRIVATE = 1, /* don't talk to other macvlans */
+ MACVLAN_MODE_VEPA = 2, /* talk to other ports through ext bridge */
+ MACVLAN_MODE_BRIDGE = 4, /* talk to bridge ports directly */
+};
+
+#define IFLA_MACVLAN_MAX (__IFLA_MACVLAN_MAX - 1)
+
#endif /* _LINUX_IF_LINK_H */
diff --git a/ip/Makefile b/ip/Makefile
index 51914e8..46a9836 100644
--- a/ip/Makefile
+++ b/ip/Makefile
@@ -2,7 +2,8 @@ IPOBJ=ip.o ipaddress.o ipaddrlabel.o iproute.o iprule.o \
rtm_map.o iptunnel.o ip6tunnel.o tunnel.o ipneigh.o ipntable.o iplink.o \
ipmaddr.o ipmonitor.o ipmroute.o ipprefix.o \
ipxfrm.o xfrm_state.o xfrm_policy.o xfrm_monitor.o \
- iplink_vlan.o link_veth.o link_gre.o iplink_can.o
+ iplink_vlan.o link_veth.o link_gre.o iplink_can.o \
+ iplink_macvlan.o
RTMONOBJ=rtmon.o
diff --git a/ip/iplink_macvlan.c b/ip/iplink_macvlan.c
new file mode 100644
index 0000000..307f559
--- /dev/null
+++ b/ip/iplink_macvlan.c
@@ -0,0 +1,93 @@
+/*
+ * iplink_vlan.c VLAN device support
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Authors: Patrick McHardy <kaber@trash.net>
+ * Arnd Bergmann <arnd@arndb.de>
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <sys/socket.h>
+#include <linux/if_link.h>
+
+#include "rt_names.h"
+#include "utils.h"
+#include "ip_common.h"
+
+static void explain(void)
+{
+ fprintf(stderr,
+ "Usage: ... macvlan mode { private | vepa | bridge }\n"
+ );
+}
+
+static int mode_arg(void)
+{
+ fprintf(stderr, "Error: argument of \"mode\" must be \"private\", "
+ "\"vepa\" or \"bridge\"\n");
+ return -1;
+}
+
+static int macvlan_parse_opt(struct link_util *lu, int argc, char **argv,
+ struct nlmsghdr *n)
+{
+ while (argc > 0) {
+ if (matches(*argv, "mode") == 0) {
+ __u32 mode = 0;
+ NEXT_ARG();
+
+ if (strcmp(*argv, "private") == 0)
+ mode = MACVLAN_MODE_PRIVATE;
+ else if (strcmp(*argv, "vepa") == 0)
+ mode = MACVLAN_MODE_VEPA;
+ else if (strcmp(*argv, "bridge") == 0)
+ mode = MACVLAN_MODE_BRIDGE;
+ else
+ return mode_arg();
+
+ addattr32(n, 1024, IFLA_MACVLAN_MODE, mode);
+ } else if (matches(*argv, "help") == 0) {
+ explain();
+ return -1;
+ } else {
+ fprintf(stderr, "macvlan: what is \"%s\"?\n", *argv);
+ explain();
+ return -1;
+ }
+ argc--, argv++;
+ }
+
+ return 0;
+}
+
+static void macvlan_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
+{
+ __u32 mode;
+
+ if (!tb)
+ return;
+
+ if (!tb[IFLA_MACVLAN_MODE] ||
+ RTA_PAYLOAD(tb[IFLA_MACVLAN_MODE]) < sizeof(__u32))
+ return;
+
+ mode = *(__u32 *)RTA_DATA(tb[IFLA_VLAN_ID]);
+ fprintf(f, " mode %s ",
+ mode == MACVLAN_MODE_PRIVATE ? "private"
+ : mode == MACVLAN_MODE_VEPA ? "vepa"
+ : mode == MACVLAN_MODE_BRIDGE ? "bridge"
+ : "unknown");
+}
+
+struct link_util macvlan_link_util = {
+ .id = "macvlan",
+ .maxattr = IFLA_MACVLAN_MAX,
+ .parse_opt = macvlan_parse_opt,
+ .print_opt = macvlan_print_opt,
+};
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/3] macvlan: implement VEPA and private mode
From: Arnd Bergmann @ 2009-11-17 22:39 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, David Miller, Stephen Hemminger, Herbert Xu,
Patrick McHardy, Patrick Mullaney, Eric W. Biederman,
Edge Virtual Bridging, Anna Fischer, bridge, virtualization,
Jens Osterkamp, Gerhard Stenzel, Arnd Bergmann
In-Reply-To: <1258497551-25959-1-git-send-email-arnd@arndb.de>
This allows each macvlan slave device to be in one
of three modes, depending on the use case:
MACVLAN_MODE_PRIVATE:
The device never communicates with any other device
on the same upper_dev. This even includes frames
coming back from a reflective relay, where supported
by the adjacent bridge.
MACVLAN_MODE_VEPA:
The new Virtual Ethernet Port Aggregator (VEPA) mode,
we assume that the adjacent bridge returns all frames
where both source and destination are local to the
macvlan port, i.e. the bridge is set up as a reflective
relay.
Broadcast frames coming in from the upper_dev get
flooded to all macvlan interfaces in VEPA mode.
We never deliver any frames locally.
MACVLAN_MODE_BRIDGE:
We provide the behavior of a simple bridge between
different macvlan interfaces on the same port. Frames
from one interface to another one get delivered directly
and are not sent out externally. Broadcast frames get
flooded to all other bridge ports and to the external
interface, but when they come back from a reflective
relay, we don't deliver them again.
Since we know all the MAC addresses, the macvlan bridge
mode does not require learning or STP like the bridge
module does.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/macvlan.c | 46 +++++++++++++++++++++++++++++++++++++---------
1 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 406b8b5..fa8b568 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -33,6 +33,12 @@
#define MACVLAN_HASH_SIZE (1 << BITS_PER_BYTE)
+enum macvlan_type {
+ MACVLAN_PRIVATE = 1,
+ MACVLAN_VEPA = 2,
+ MACVLAN_BRIDGE = 4,
+};
+
struct macvlan_port {
struct net_device *dev;
struct hlist_head vlan_hash[MACVLAN_HASH_SIZE];
@@ -45,6 +51,7 @@ struct macvlan_dev {
struct hlist_node hlist;
struct macvlan_port *port;
struct net_device *lowerdev;
+ enum macvlan_mode mode;
};
@@ -104,7 +111,8 @@ static int macvlan_addr_busy(const struct macvlan_port *port,
static void macvlan_broadcast(struct sk_buff *skb,
const struct macvlan_port *port,
- struct net_device *src)
+ struct net_device *src,
+ enum macvlan_mode mode)
{
const struct ethhdr *eth = eth_hdr(skb);
const struct macvlan_dev *vlan;
@@ -123,6 +131,9 @@ static void macvlan_broadcast(struct sk_buff *skb,
if (dev == src)
continue;
+ if (!(vlan->mode & mode))
+ continue;
+
nskb = skb_clone(skb, GFP_ATOMIC);
if (nskb == NULL) {
dev->stats.rx_errors++;
@@ -177,13 +188,27 @@ static struct sk_buff *macvlan_handle_frame(struct sk_buff *skb)
const struct ethhdr *eth = eth_hdr(skb);
const struct macvlan_port *port;
const struct macvlan_dev *vlan;
+ const struct macvlan_dev *src;
port = rcu_dereference(skb->dev->macvlan_port);
if (port == NULL)
return skb;
if (is_multicast_ether_addr(eth->h_dest)) {
- macvlan_broadcast(skb, port, NULL);
+ src = macvlan_hash_lookup(port, eth->h_source);
+ if (!src)
+ /* frame comes from an external address */
+ macvlan_broadcast(skb, port, NULL, MACVLAN_MODE_VEPA
+ | MACVLAN_MODE_VEPA | MACVLAN_MODE_BRIDGE);
+ else if (src->mode == MACVLAN_MODE_VEPA)
+ /* flood to everyone except source */
+ macvlan_broadcast(skb, port, src->dev,
+ MACVLAN_MODE_VEPA | MACVLAN_MODE_BRIDGE);
+ else if (src->mode == MACVLAN_MODE_BRIDGE)
+ /* flood only to VEPA ports, bridge ports
+ already saw the frame */
+ macvlan_broadcast(skb, port, src->dev,
+ MACVLAN_MODE_VEPA);
return skb;
}
@@ -218,14 +243,17 @@ static int macvlan_queue_xmit(struct sk_buff *skb, struct net_device *dev)
secpath_reset(skb);
nf_reset(skb);
- if (is_multicast_ether_addr(eth->h_dest)) {
- macvlan_broadcast(skb, port, dev);
- return macvlan_xmit_world(skb, dev);
- }
+ if (vlan->mode == MACVLAN_MODE_BRIDGE) {
+ /* send to other bridge ports directly */
+ if (is_multicast_ether_addr(eth->h_dest)) {
+ macvlan_broadcast(skb, port, dev, MACVLAN_MODE_BRIDGE);
+ return macvlan_xmit_world(skb, dev);
+ }
- dest = macvlan_hash_lookup(port, eth->h_dest);
- if (dest)
- return macvlan_unicast(skb, dest);
+ dest = macvlan_hash_lookup(port, eth->h_dest);
+ if (dest && dest->mode == MACVLAN_MODE_BRIDGE)
+ return macvlan_unicast(skb, dest);
+ }
return macvlan_xmit_world(skb, dev);
}
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/3] macvlan: Reflect macvlan packets meant for other macvlan devices
From: Arnd Bergmann @ 2009-11-17 22:39 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, David Miller, Stephen Hemminger, Herbert Xu,
Patrick McHardy, Patrick Mullaney, Eric W. Biederman,
Edge Virtual Bridging, Anna Fischer, bridge, virtualization,
Jens Osterkamp, Gerhard Stenzel, Arnd Bergmann
In-Reply-To: <1258497551-25959-1-git-send-email-arnd@arndb.de>
From: Eric Biederman <ebiederm@xmission.com>
Switch ports do not send packets back out the same port they came
in on. This causes problems when using a macvlan device inside
of a network namespace as it becomes impossible to talk to
other macvlan devices.
Signed-off-by: Eric Biederman <ebiederm@xmission.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/macvlan.c | 91 ++++++++++++++++++++++++++++++++++++-------------
1 files changed, 67 insertions(+), 24 deletions(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 3aabfd9..406b8b5 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -29,6 +29,7 @@
#include <linux/if_link.h>
#include <linux/if_macvlan.h>
#include <net/rtnetlink.h>
+#include <net/xfrm.h>
#define MACVLAN_HASH_SIZE (1 << BITS_PER_BYTE)
@@ -102,7 +103,8 @@ static int macvlan_addr_busy(const struct macvlan_port *port,
}
static void macvlan_broadcast(struct sk_buff *skb,
- const struct macvlan_port *port)
+ const struct macvlan_port *port,
+ struct net_device *src)
{
const struct ethhdr *eth = eth_hdr(skb);
const struct macvlan_dev *vlan;
@@ -118,6 +120,9 @@ static void macvlan_broadcast(struct sk_buff *skb,
hlist_for_each_entry_rcu(vlan, n, &port->vlan_hash[i], hlist) {
dev = vlan->dev;
+ if (dev == src)
+ continue;
+
nskb = skb_clone(skb, GFP_ATOMIC);
if (nskb == NULL) {
dev->stats.rx_errors++;
@@ -140,20 +145,45 @@ static void macvlan_broadcast(struct sk_buff *skb,
}
}
+static int macvlan_unicast(struct sk_buff *skb, const struct macvlan_dev *dest)
+{
+ struct net_device *dev = dest->dev;
+
+ if (unlikely(!dev->flags & IFF_UP)) {
+ kfree_skb(skb);
+ return NET_XMIT_DROP;
+ }
+
+ skb = skb_share_check(skb, GFP_ATOMIC);
+ if (!skb) {
+ dev->stats.rx_errors++;
+ dev->stats.rx_dropped++;
+ return NET_XMIT_DROP;
+ }
+
+ dev->stats.rx_bytes += skb->len + ETH_HLEN;
+ dev->stats.rx_packets++;
+
+ skb->dev = dev;
+ skb->pkt_type = PACKET_HOST;
+ netif_rx(skb);
+ return NET_XMIT_SUCCESS;
+}
+
+
/* called under rcu_read_lock() from netif_receive_skb */
static struct sk_buff *macvlan_handle_frame(struct sk_buff *skb)
{
const struct ethhdr *eth = eth_hdr(skb);
const struct macvlan_port *port;
const struct macvlan_dev *vlan;
- struct net_device *dev;
port = rcu_dereference(skb->dev->macvlan_port);
if (port == NULL)
return skb;
if (is_multicast_ether_addr(eth->h_dest)) {
- macvlan_broadcast(skb, port);
+ macvlan_broadcast(skb, port, NULL);
return skb;
}
@@ -161,27 +191,43 @@ static struct sk_buff *macvlan_handle_frame(struct sk_buff *skb)
if (vlan == NULL)
return skb;
- dev = vlan->dev;
- if (unlikely(!(dev->flags & IFF_UP))) {
- kfree_skb(skb);
- return NULL;
- }
+ macvlan_unicast(skb, vlan);
+ return NULL;
+}
- skb = skb_share_check(skb, GFP_ATOMIC);
- if (skb == NULL) {
- dev->stats.rx_errors++;
- dev->stats.rx_dropped++;
- return NULL;
- }
+static int macvlan_xmit_world(struct sk_buff *skb, struct net_device *dev)
+{
+ const struct macvlan_dev *vlan = netdev_priv(dev);
+ __skb_push(skb, skb->data - skb_mac_header(skb));
+ skb->dev = vlan->lowerdev;
+ return dev_queue_xmit(skb);
+}
- dev->stats.rx_bytes += skb->len + ETH_HLEN;
- dev->stats.rx_packets++;
+static int macvlan_queue_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+ const struct macvlan_dev *vlan = netdev_priv(dev);
+ const struct macvlan_port *port = vlan->port;
+ const struct macvlan_dev *dest;
+ const struct ethhdr *eth;
- skb->dev = dev;
- skb->pkt_type = PACKET_HOST;
+ skb->protocol = eth_type_trans(skb, dev);
+ eth = eth_hdr(skb);
- netif_rx(skb);
- return NULL;
+ skb_dst_drop(skb);
+ skb->mark = 0;
+ secpath_reset(skb);
+ nf_reset(skb);
+
+ if (is_multicast_ether_addr(eth->h_dest)) {
+ macvlan_broadcast(skb, port, dev);
+ return macvlan_xmit_world(skb, dev);
+ }
+
+ dest = macvlan_hash_lookup(port, eth->h_dest);
+ if (dest)
+ return macvlan_unicast(skb, dest);
+
+ return macvlan_xmit_world(skb, dev);
}
static netdev_tx_t macvlan_start_xmit(struct sk_buff *skb,
@@ -189,13 +235,10 @@ static netdev_tx_t macvlan_start_xmit(struct sk_buff *skb,
{
int i = skb_get_queue_mapping(skb);
struct netdev_queue *txq = netdev_get_tx_queue(dev, i);
- const struct macvlan_dev *vlan = netdev_priv(dev);
unsigned int len = skb->len;
int ret;
- skb->dev = vlan->lowerdev;
- ret = dev_queue_xmit(skb);
-
+ ret = macvlan_queue_xmit(skb, dev);
if (likely(ret == NET_XMIT_SUCCESS)) {
txq->tx_packets++;
txq->tx_bytes += len;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 0/3] macvlan: add vepa and bridge mode
From: Arnd Bergmann @ 2009-11-17 22:39 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, David Miller, Stephen Hemminger, Herbert Xu,
Patrick McHardy, Patrick Mullaney, Eric W. Biederman,
Edge Virtual Bridging, Anna Fischer, bridge, virtualization,
Jens Osterkamp, Gerhard Stenzel, Arnd Bergmann
This is based on an earlier patch from Eric Biederman adding
forwarding between macvlans. I extended his approach to
allow the administrator to choose the mode for each macvlan,
and to implement a functional VEPA between macvlan.
Still missing from this is support for communication between
the lower device that the macvlans are based on. This would
be extremely useful but as others have found out before me
requires significant changes not only to macvlan but also
to the common transmit path.
I've seen one panic during testing this that I still need
to track down, but it generally does what is advertised.
I've tested VEPA operation with the hairpin support
added to the bridge driver by Anna Fischer.
My current plan is to submit this for inclusion in 2.6.33
when people are happy with it and I tracked down any
remaining bugs, and possibly to do the communication with
the lower device one release later.
Arnd <><
---
Arnd Bergmann (3):
macvlan: implement VEPA and private mode
macvlan: export macvlan mode through netlink
iplink: add macvlan options for bridge mode
Eric Biederman (1):
macvlan: Reflect macvlan packets meant for other macvlan devices
linux/drivers/net/macvlan.c | 170 +++++++++++++++++++++++++++++++++-----
linux/include/linux/if_link.h | 15 +++
2 files changed, 161 insertions(+), 24 deletions(-)
iproute2/include/linux/if_link.h | 15 +++
iproute2/ip/Makefile | 3 +-
iproute2/ip/iplink_macvlan.c | 93 ++++++++++++++++++
3 files changed, 110 insertions(+), 1 deletions(-)
create mode 100644 ip/iplink_macvlan.c
^ permalink raw reply
* Re: [RFC v2] mac80211: disallow bridging managed/adhoc interfaces
From: Julian Calaby @ 2009-11-17 22:42 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, linux-wireless, Stephen Hemminger, Felix Fietkau
In-Reply-To: <1258490898.21197.42.camel-YfaajirXv2244ywRPIzf9A@public.gmane.org>
On Wed, Nov 18, 2009 at 07:48, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> --- wireless-testing.orig/net/mac80211/iface.c 2009-11-17 14:20:19.000000000 +0100
> +++ wireless-testing/net/mac80211/iface.c 2009-11-17 17:56:08.000000000 +0100
> @@ -745,6 +745,11 @@ int ieee80211_if_change_type(struct ieee
> if (type == sdata->vif.type)
> return 0;
>
> + /* if it's part of a bridge, reject changing type to station/ibss */
> + if (sdata->dev->br_port && (type == NL80211_IFTYPE_ADHOC ||
> + type == NL80211_IFTYPE_STATION))
> + return -EBUSY;
Busy doesn't seem like the right error here ... maybe use -EOPNOTSUPP
like the next test?
Thanks,
--
Julian Calaby
Email: julian.calaby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
.Plan: http://sites.google.com/site/juliancalaby/
--
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: [RFC v2] mac80211: disallow bridging managed/adhoc interfaces
From: Stephen Hemminger @ 2009-11-17 22:42 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, linux-wireless, Felix Fietkau
In-Reply-To: <1258490898.21197.42.camel@johannes.local>
On Tue, 17 Nov 2009 21:48:18 +0100
Johannes Berg <johannes@sipsolutions.net> wrote:
> A number of people have tried to add a wireless interface
> (in managed mode) to a bridge and then complained that it
> doesn't work. It cannot work, however, because in 802.11
> networks all packets need to be acknowledged and as such
> need to be sent to the right address. Promiscuous doesn't
> help here. The wireless address format used for these
> links has only space for three addresses, the
> * transmitter, which must be equal to the sender (origin)
> * receiver (on the wireless medium), which is the AP in
> the case of managed mode
> * the recipient (destination), which is on the APs local
> network segment
>
> In an IBSS, it is similar, but the receiver and recipient
> must match and the third address is used as the BSSID.
>
> To avoid such mistakes in the future, disallow adding a
> wireless interface to a bridge.
>
> Felix has recently added a four-address mode to the AP
> and client side that can be used (after negotiating that
> it is possible, which must happen out-of-band by setting
> up both sides) for bridging, so allow that case.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Looks good, maybe true four-address mode support will be available
more widely, and this will no longer be an issue.
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
^ permalink raw reply
* Re: [RFC v2] mac80211: disallow bridging managed/adhoc interfaces
From: Johannes Berg @ 2009-11-17 22:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, linux-wireless, Felix Fietkau
In-Reply-To: <20091117144239.47930866@nehalam>
[-- Attachment #1: Type: text/plain, Size: 659 bytes --]
On Tue, 2009-11-17 at 14:42 -0800, Stephen Hemminger wrote:
> > Felix has recently added a four-address mode to the AP
> > and client side that can be used (after negotiating that
> > it is possible, which must happen out-of-band by setting
> > up both sides) for bridging, so allow that case.
> Looks good, maybe true four-address mode support will be available
> more widely, and this will no longer be an issue.
Doubt it, it breaks the current 802.11 standard, and I think 802.1X too
if you use WPA/RSN. Anyway, thanks.
I'll take a look tomorrow if we can do this generically in cfg80211, and
then send a [PATCH] either way.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [RFC v2] mac80211: disallow bridging managed/adhoc interfaces
From: Johannes Berg @ 2009-11-17 22:46 UTC (permalink / raw)
To: Julian Calaby; +Cc: netdev, linux-wireless, Stephen Hemminger, Felix Fietkau
In-Reply-To: <646765f40911171442m467efbc8ped7abc9d529ed095@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]
On Wed, 2009-11-18 at 09:42 +1100, Julian Calaby wrote:
> On Wed, Nov 18, 2009 at 07:48, Johannes Berg <johannes@sipsolutions.net> wrote:
> > --- wireless-testing.orig/net/mac80211/iface.c 2009-11-17 14:20:19.000000000 +0100
> > +++ wireless-testing/net/mac80211/iface.c 2009-11-17 17:56:08.000000000 +0100
> > @@ -745,6 +745,11 @@ int ieee80211_if_change_type(struct ieee
> > if (type == sdata->vif.type)
> > return 0;
> >
> > + /* if it's part of a bridge, reject changing type to station/ibss */
> > + if (sdata->dev->br_port && (type == NL80211_IFTYPE_ADHOC ||
> > + type == NL80211_IFTYPE_STATION))
> > + return -EBUSY;
>
> Busy doesn't seem like the right error here ... maybe use -EOPNOTSUPP
> like the next test?
Not sure, it's a temporary error and you can fix it by removing it from
the bridge, so it's "busy" in the sense that it is fixed to the current
mode or any other bridging mode by being in the bridge ... it's not that
it doesn't support the mode.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [patch 1/1] drivers/atm/solos-pci.c: fix warning/bug, clean up code
From: akpm @ 2009-11-17 22:46 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, David.Woodhouse, chas, nathan
From: Andrew Morton <akpm@linux-foundation.org>
drivers/atm/solos-pci.c: In function 'flash_upgrade':
drivers/atm/solos-pci.c:528: warning: 'fw_name' may be used uninitialized in this function
Cc: Chas Williams <chas@cmf.nrl.navy.mil>
Cc: David Woodhouse <David.Woodhouse@intel.com>
Cc: Nathan Williams <nathan@traverse.com.au>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/atm/solos-pci.c | 29 ++++++++++++++++-------------
1 file changed, 16 insertions(+), 13 deletions(-)
diff -puN drivers/atm/solos-pci.c~drivers-atm-solos-pcic-fix-warning-bug-clean-up-code drivers/atm/solos-pci.c
--- a/drivers/atm/solos-pci.c~drivers-atm-solos-pcic-fix-warning-bug-clean-up-code
+++ a/drivers/atm/solos-pci.c
@@ -531,34 +531,37 @@ static int flash_upgrade(struct solos_ca
int numblocks = 0;
int offset;
- if (chip == 0) {
+ switch (chip) {
+ case 0:
fw_name = "solos-FPGA.bin";
blocksize = FPGA_BLOCK;
- }
-
- if (chip == 1) {
+ break;
+ case 1:
fw_name = "solos-Firmware.bin";
blocksize = SOLOS_BLOCK;
- }
-
- if (chip == 2){
+ break;
+ case 2:
if (card->fpga_version > LEGACY_BUFFERS){
fw_name = "solos-db-FPGA.bin";
blocksize = FPGA_BLOCK;
} else {
- dev_info(&card->dev->dev, "FPGA version doesn't support daughter board upgrades\n");
+ dev_info(&card->dev->dev, "FPGA version doesn't support"
+ " daughter board upgrades\n");
return -EPERM;
}
- }
-
- if (chip == 3){
+ break;
+ case 3:
if (card->fpga_version > LEGACY_BUFFERS){
fw_name = "solos-Firmware.bin";
blocksize = SOLOS_BLOCK;
} else {
- dev_info(&card->dev->dev, "FPGA version doesn't support daughter board upgrades\n");
- return -EPERM;
+ dev_info(&card->dev->dev, "FPGA version doesn't support"
+ " daughter board upgrades\n");
+ return -EPERM;
}
+ break;
+ default:
+ return -ENODEV;
}
if (request_firmware(&fw, fw_name, &card->dev->dev))
_
^ permalink raw reply
* [patch for 2.6.32? 1/2] hso: fix debug routines
From: akpm @ 2009-11-17 22:50 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, antti.kaijanmaki, greg, randy.dunlap
From: Antti Kaijanmäki <antti.kaijanmaki@nomovok.com>
Signed-off-by: Antti Kaijanmäki <antti.kaijanmaki@nomovok.com>
Cc: Greg KH <greg@kroah.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/usb/hso.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN drivers/net/usb/hso.c~hso-fix-debug-routines drivers/net/usb/hso.c
--- a/drivers/net/usb/hso.c~hso-fix-debug-routines
+++ a/drivers/net/usb/hso.c
@@ -378,7 +378,7 @@ static void dbg_dump(int line_count, con
}
#define DUMP(buf_, len_) \
- dbg_dump(__LINE__, __func__, buf_, len_)
+ dbg_dump(__LINE__, __func__, (unsigned char *)buf_, len_)
#define DUMP1(buf_, len_) \
do { \
@@ -1527,7 +1527,7 @@ static void tiocmget_intr_callback(struc
dev_warn(&usb->dev,
"hso received invalid serial state notification\n");
DUMP(serial_state_notification,
- sizeof(hso_serial_state_notifation))
+ sizeof(struct hso_serial_state_notification));
} else {
UART_state_bitmap = le16_to_cpu(serial_state_notification->
_
^ permalink raw reply
* Re: [RFC v2] mac80211: disallow bridging managed/adhoc interfaces
From: Julian Calaby @ 2009-11-17 22:50 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, linux-wireless, Stephen Hemminger, Felix Fietkau
In-Reply-To: <1258498005.30511.3.camel@johannes.local>
On Wed, Nov 18, 2009 at 09:46, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Wed, 2009-11-18 at 09:42 +1100, Julian Calaby wrote:
>> On Wed, Nov 18, 2009 at 07:48, Johannes Berg <johannes@sipsolutions.net> wrote:
>> > --- wireless-testing.orig/net/mac80211/iface.c 2009-11-17 14:20:19.000000000 +0100
>> > +++ wireless-testing/net/mac80211/iface.c 2009-11-17 17:56:08.000000000 +0100
>> > @@ -745,6 +745,11 @@ int ieee80211_if_change_type(struct ieee
>> > if (type == sdata->vif.type)
>> > return 0;
>> >
>> > + /* if it's part of a bridge, reject changing type to station/ibss */
>> > + if (sdata->dev->br_port && (type == NL80211_IFTYPE_ADHOC ||
>> > + type == NL80211_IFTYPE_STATION))
>> > + return -EBUSY;
>>
>> Busy doesn't seem like the right error here ... maybe use -EOPNOTSUPP
>> like the next test?
>
> Not sure, it's a temporary error and you can fix it by removing it from
> the bridge, so it's "busy" in the sense that it is fixed to the current
> mode or any other bridging mode by being in the bridge ... it's not that
> it doesn't support the mode.
Arguably the test following this (ensuring that we don't set ad-hoc
mode on a non-ad-hoc channel) is equally temporary - i.e. both actions
require the user to do something before they'll work again.
But then, the test after that - for whether the interface is running -
returns -EBUSY - and is just as easy to remedy, so........
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* [patch for 2.6.32? 2/2] hso: fix soft-lockup
From: akpm @ 2009-11-17 22:50 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, antti.kaijanmaki, greg, randy.dunlap, stable
From: Antti Kaijanmäki <antti.kaijanmaki@nomovok.com>
Fix soft-lockup in hso.c which is triggered on SMP machine when
modem is removed while file descriptor(s) under /dev are still open:
old version called kref_put() too early which resulted in destroying
hso_serial and hso_device objects which were still used later on.
Signed-off-by: Antti Kaijanmäki <antti.kaijanmaki@nomovok.com>
Cc: Greg KH <greg@kroah.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/usb/hso.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -puN drivers/net/usb/hso.c~hso-fix-soft-lockup drivers/net/usb/hso.c
--- a/drivers/net/usb/hso.c~hso-fix-soft-lockup
+++ a/drivers/net/usb/hso.c
@@ -1363,7 +1363,7 @@ static void hso_serial_close(struct tty_
/* reset the rts and dtr */
/* do the actual close */
serial->open_count--;
- kref_put(&serial->parent->ref, hso_serial_ref_free);
+
if (serial->open_count <= 0) {
serial->open_count = 0;
spin_lock_irq(&serial->serial_lock);
@@ -1383,6 +1383,8 @@ static void hso_serial_close(struct tty_
usb_autopm_put_interface(serial->parent->interface);
mutex_unlock(&serial->parent->mutex);
+
+ kref_put(&serial->parent->ref, hso_serial_ref_free);
}
/* close the requested serial port */
_
^ permalink raw reply
* Re: [patch 1/1] drivers/atm/solos-pci.c: fix warning/bug, clean up code
From: David Woodhouse @ 2009-11-17 22:55 UTC (permalink / raw)
To: akpm@linux-foundation.org
Cc: davem@davemloft.net, netdev@vger.kernel.org,
chas@cmf.nrl.navy.mil, nathan@traverse.com.au
In-Reply-To: <200911172246.nAHMkiK2004221@imap1.linux-foundation.org>
On Tue, 2009-11-17 at 14:46 -0800, akpm@linux-foundation.org wrote:
> From: Andrew Morton <akpm@linux-foundation.org>
>
> drivers/atm/solos-pci.c: In function 'flash_upgrade':
> drivers/atm/solos-pci.c:528: warning: 'fw_name' may be used uninitialized in this function
>
> Cc: Chas Williams <chas@cmf.nrl.navy.mil>
> Cc: Nathan Williams <nathan@traverse.com.au>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-By: David Woodhouse <David.Woodhouse@intel.com>
> ---
>
> drivers/atm/solos-pci.c | 29 ++++++++++++++++-------------
> 1 file changed, 16 insertions(+), 13 deletions(-)
>
> diff -puN drivers/atm/solos-pci.c~drivers-atm-solos-pcic-fix-warning-bug-clean-up-code drivers/atm/solos-pci.c
> --- a/drivers/atm/solos-pci.c~drivers-atm-solos-pcic-fix-warning-bug-clean-up-code
> +++ a/drivers/atm/solos-pci.c
> @@ -531,34 +531,37 @@ static int flash_upgrade(struct solos_ca
> int numblocks = 0;
> int offset;
>
> - if (chip == 0) {
> + switch (chip) {
> + case 0:
> fw_name = "solos-FPGA.bin";
> blocksize = FPGA_BLOCK;
> - }
> -
> - if (chip == 1) {
> + break;
> + case 1:
> fw_name = "solos-Firmware.bin";
> blocksize = SOLOS_BLOCK;
> - }
> -
> - if (chip == 2){
> + break;
> + case 2:
> if (card->fpga_version > LEGACY_BUFFERS){
> fw_name = "solos-db-FPGA.bin";
> blocksize = FPGA_BLOCK;
> } else {
> - dev_info(&card->dev->dev, "FPGA version doesn't support daughter board upgrades\n");
> + dev_info(&card->dev->dev, "FPGA version doesn't support"
> + " daughter board upgrades\n");
> return -EPERM;
> }
> - }
> -
> - if (chip == 3){
> + break;
> + case 3:
> if (card->fpga_version > LEGACY_BUFFERS){
> fw_name = "solos-Firmware.bin";
> blocksize = SOLOS_BLOCK;
> } else {
> - dev_info(&card->dev->dev, "FPGA version doesn't support daughter board upgrades\n");
> - return -EPERM;
> + dev_info(&card->dev->dev, "FPGA version doesn't support"
> + " daughter board upgrades\n");
> + return -EPERM;
> }
> + break;
> + default:
> + return -ENODEV;
> }
>
> if (request_firmware(&fw, fw_name, &card->dev->dev))
> _
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: [PATCH 0/3] macvlan: add vepa and bridge mode
From: Arnd Bergmann @ 2009-11-17 22:56 UTC (permalink / raw)
To: linux-kernel, Jens Osterkamp
Cc: netdev, David Miller, Stephen Hemminger, Herbert Xu,
Patrick McHardy, Patrick Mullaney, Eric W. Biederman,
Edge Virtual Bridging, Anna Fischer, bridge, Gerhard Stenzel,
virtualization
In-Reply-To: <1258497551-25959-1-git-send-email-arnd@arndb.de>
Sorry, I used the wrong address for the virtualization mailing list
at first. Please correct this to <virtualization@lists.linux-foundation.org>
when replying to the other mails.
For people only subscribed to virtualization, you can find the actual
patches at
http://patchwork.kernel.org/patch/60810/
http://patchwork.kernel.org/patch/60811/
http://patchwork.kernel.org/patch/60813/
http://patchwork.kernel.org/patch/60814/
Arnd <><
On Tuesday 17 November 2009, Arnd Bergmann wrote:
> This is based on an earlier patch from Eric Biederman adding
> forwarding between macvlans. I extended his approach to
> allow the administrator to choose the mode for each macvlan,
> and to implement a functional VEPA between macvlan.
>
> Still missing from this is support for communication between
> the lower device that the macvlans are based on. This would
> be extremely useful but as others have found out before me
> requires significant changes not only to macvlan but also
> to the common transmit path.
>
> I've seen one panic during testing this that I still need
> to track down, but it generally does what is advertised.
> I've tested VEPA operation with the hairpin support
> added to the bridge driver by Anna Fischer.
>
> My current plan is to submit this for inclusion in 2.6.33
> when people are happy with it and I tracked down any
> remaining bugs, and possibly to do the communication with
> the lower device one release later.
>
> Arnd <><
>
> ---
>
> Arnd Bergmann (3):
> macvlan: implement VEPA and private mode
> macvlan: export macvlan mode through netlink
> iplink: add macvlan options for bridge mode
>
> Eric Biederman (1):
> macvlan: Reflect macvlan packets meant for other macvlan devices
>
> linux/drivers/net/macvlan.c | 170 +++++++++++++++++++++++++++++++++-----
> linux/include/linux/if_link.h | 15 +++
> 2 files changed, 161 insertions(+), 24 deletions(-)
>
> iproute2/include/linux/if_link.h | 15 +++
> iproute2/ip/Makefile | 3 +-
> iproute2/ip/iplink_macvlan.c | 93 ++++++++++++++++++
> 3 files changed, 110 insertions(+), 1 deletions(-)
> create mode 100644 ip/iplink_macvlan.c
>
^ permalink raw reply
* [PATCH 2.6.32-rc6] drivers/net: ks8851_mll ethernet network driver
From: Choi, David @ 2009-11-17 23:02 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, shemminger, greg, Choi, David
Hello all,
This patch is for ks8851 16bit MLL Ethernet network device driver in order to fix bugs and to enhance functions.
>From : David J. Choi <david.choi@micrel.com>
Summary of Changes:
-Fix to receive multicast packets by setting the corresponding hardware bit during initialization.
-Fix to re-enable the interface [by interface up command(ifup)] while the interface is down.
-Fix to down the interface by passing the last parameter correctly to request_irq().
-Remove to read 4 extra bytes from the receiving queue after reading a packet, even though it does not cause
a predictable issue now.
-Remove occurrences of transmission done interrupt in order to tx throughput enhancement.
-Enable IP checksum for packet receiving by setting the corresponding hardware bit during initialization.
-Display a message of driver name/base address on the console after driver's initialization.
-Relocate ks_enable_int()/ks_disable_int() in order not to declare those functions at the beginning of the file.
-Rename ks_enable()/_disable() to ks_enable_qmu()/ks_disable_qmu() in order to give more meaningful names
and relocate them not declaire those functions at the beginning of the file.
Signed-off-by: David J. Choi <david.choi@micrel.com>
---
--- linux-2.6.32-rc6/drivers/net/ks8851_mll.c.orig 2009-11-12 09:57:33.000000000 -0800
+++ linux-2.6.32-rc6/drivers/net/ks8851_mll.c 2009-11-17 13:43:28.000000000 -0800
@@ -568,6 +568,16 @@ static inline void ks_outblk(struct ks_n
iowrite16(*wptr++, ks->hw_addr);
}
+static void ks_disable_int(struct ks_net *ks)
+{
+ ks_wrreg16(ks, KS_IER, 0x0000);
+} /* ks_disable_int */
+
+static void ks_enable_int(struct ks_net *ks)
+{
+ ks_wrreg16(ks, KS_IER, ks->rc_ier);
+} /* ks_enable_int */
+
/**
* ks_tx_fifo_space - return the available hardware buffer size.
* @ks: The chip information
@@ -681,6 +691,47 @@ static void ks_soft_reset(struct ks_net
}
+void ks_enable_qmu(struct ks_net *ks)
+{
+ u16 w;
+
+ w = ks_rdreg16(ks, KS_TXCR);
+ /* Enables QMU Transmit (TXCR). */
+ ks_wrreg16(ks, KS_TXCR, w | TXCR_TXE);
+
+ /*
+ * RX Frame Count Threshold Enable and Auto-Dequeue RXQ Frame
+ * Enable
+ */
+
+ w = ks_rdreg16(ks, KS_RXQCR);
+ ks_wrreg16(ks, KS_RXQCR, w | RXQCR_RXFCTE);
+
+ /* Enables QMU Receive (RXCR1). */
+ w = ks_rdreg16(ks, KS_RXCR1);
+ ks_wrreg16(ks, KS_RXCR1, w | RXCR1_RXE);
+ ks->enabled = true;
+} /* ks_enable_qmu */
+
+static void ks_disable_qmu(struct ks_net *ks)
+{
+ u16 w;
+
+ w = ks_rdreg16(ks, KS_TXCR);
+
+ /* Disables QMU Transmit (TXCR). */
+ w &= ~TXCR_TXE;
+ ks_wrreg16(ks, KS_TXCR, w);
+
+ /* Disables QMU Receive (RXCR1). */
+ w = ks_rdreg16(ks, KS_RXCR1);
+ w &= ~RXCR1_RXE ;
+ ks_wrreg16(ks, KS_RXCR1, w);
+
+ ks->enabled = false;
+
+} /* ks_disable_qmu */
+
/**
* ks_read_qmu - read 1 pkt data from the QMU.
* @ks: The chip information
@@ -752,7 +803,7 @@ static void ks_rcv(struct ks_net *ks, st
(frame_hdr->len < RX_BUF_SIZE) && frame_hdr->len)) {
skb_reserve(skb, 2);
/* read data block including CRC 4 bytes */
- ks_read_qmu(ks, (u16 *)skb->data, frame_hdr->len + 4);
+ ks_read_qmu(ks, (u16 *)skb->data, frame_hdr->len);
skb_put(skb, frame_hdr->len);
skb->dev = netdev;
skb->protocol = eth_type_trans(skb, netdev);
@@ -861,7 +912,7 @@ static int ks_net_open(struct net_device
ks_dbg(ks, "%s - entry\n", __func__);
/* reset the HW */
- err = request_irq(ks->irq, ks_irq, KS_INT_FLAGS, DRV_NAME, ks);
+ err = request_irq(ks->irq, ks_irq, KS_INT_FLAGS, DRV_NAME, netdev);
if (err) {
printk(KERN_ERR "Failed to request IRQ: %d: %d\n",
@@ -869,6 +920,15 @@ static int ks_net_open(struct net_device
return err;
}
+ /* wake up powermode to normal mode */
+ ks_set_powermode(ks, PMECR_PM_NORMAL);
+ mdelay(1); /* wait for normal mode to take effect */
+
+ ks_wrreg16(ks, KS_ISR, 0xffff);
+ ks_enable_int(ks);
+ ks_enable_qmu(ks);
+ netif_start_queue(ks->netdev);
+
if (netif_msg_ifup(ks))
ks_dbg(ks, "network device %s up\n", netdev->name);
@@ -892,19 +952,14 @@ static int ks_net_stop(struct net_device
netif_stop_queue(netdev);
- kfree(ks->frame_head_info);
-
mutex_lock(&ks->lock);
/* turn off the IRQs and ack any outstanding */
ks_wrreg16(ks, KS_IER, 0x0000);
ks_wrreg16(ks, KS_ISR, 0xffff);
- /* shutdown RX process */
- ks_wrreg16(ks, KS_RXCR1, 0x0000);
-
- /* shutdown TX process */
- ks_wrreg16(ks, KS_TXCR, 0x0000);
+ /* shutdown RX/TX QMU */
+ ks_disable_qmu(ks);
/* set powermode to soft power down to save power */
ks_set_powermode(ks, PMECR_PM_SOFTDOWN);
@@ -929,17 +984,8 @@ static int ks_net_stop(struct net_device
*/
static void ks_write_qmu(struct ks_net *ks, u8 *pdata, u16 len)
{
- unsigned fid = ks->fid;
-
- fid = ks->fid;
- ks->fid = (ks->fid + 1) & TXFR_TXFID_MASK;
-
- /* reduce the tx interrupt occurrances. */
- if (!fid)
- fid |= TXFR_TXIC; /* irq on completion */
-
/* start header at txb[0] to align txw entries */
- ks->txh.txw[0] = cpu_to_le16(fid);
+ ks->txh.txw[0] = 0;
ks->txh.txw[1] = cpu_to_le16(len);
/* 1. set sudo-DMA mode */
@@ -957,16 +1003,6 @@ static void ks_write_qmu(struct ks_net *
;
}
-static void ks_disable_int(struct ks_net *ks)
-{
- ks_wrreg16(ks, KS_IER, 0x0000);
-} /* ks_disable_int */
-
-static void ks_enable_int(struct ks_net *ks)
-{
- ks_wrreg16(ks, KS_IER, ks->rc_ier);
-} /* ks_enable_int */
-
/**
* ks_start_xmit - transmit packet
* @skb : The buffer to transmit
@@ -1410,25 +1446,6 @@ static int ks_read_selftest(struct ks_ne
return ret;
}
-static void ks_disable(struct ks_net *ks)
-{
- u16 w;
-
- w = ks_rdreg16(ks, KS_TXCR);
-
- /* Disables QMU Transmit (TXCR). */
- w &= ~TXCR_TXE;
- ks_wrreg16(ks, KS_TXCR, w);
-
- /* Disables QMU Receive (RXCR1). */
- w = ks_rdreg16(ks, KS_RXCR1);
- w &= ~RXCR1_RXE ;
- ks_wrreg16(ks, KS_RXCR1, w);
-
- ks->enabled = false;
-
-} /* ks_disable */
-
static void ks_setup(struct ks_net *ks)
{
u16 w;
@@ -1463,7 +1480,7 @@ static void ks_setup(struct ks_net *ks)
w = TXCR_TXFCE | TXCR_TXPE | TXCR_TXCRC | TXCR_TCGIP;
ks_wrreg16(ks, KS_TXCR, w);
- w = RXCR1_RXFCE | RXCR1_RXBE | RXCR1_RXUE;
+ w = RXCR1_RXFCE | RXCR1_RXBE | RXCR1_RXUE | RXCR1_RXME | RXCR1_RXIPFCC;
if (ks->promiscuous) /* bPromiscuous */
w |= (RXCR1_RXAE | RXCR1_RXINVF);
@@ -1486,28 +1503,6 @@ static void ks_setup_int(struct ks_net *
ks->rc_ier = (IRQ_LCI | IRQ_TXI | IRQ_RXI);
} /* ks_setup_int */
-void ks_enable(struct ks_net *ks)
-{
- u16 w;
-
- w = ks_rdreg16(ks, KS_TXCR);
- /* Enables QMU Transmit (TXCR). */
- ks_wrreg16(ks, KS_TXCR, w | TXCR_TXE);
-
- /*
- * RX Frame Count Threshold Enable and Auto-Dequeue RXQ Frame
- * Enable
- */
-
- w = ks_rdreg16(ks, KS_RXQCR);
- ks_wrreg16(ks, KS_RXQCR, w | RXQCR_RXFCTE);
-
- /* Enables QMU Receive (RXCR1). */
- w = ks_rdreg16(ks, KS_RXCR1);
- ks_wrreg16(ks, KS_RXCR1, w | RXCR1_RXE);
- ks->enabled = true;
-} /* ks_enable */
-
static int ks_hw_init(struct ks_net *ks)
{
#define MHEADER_SIZE (sizeof(struct type_frame_head) * MAX_RECV_FRAMES)
@@ -1568,6 +1563,10 @@ static int __devinit ks8851_probe(struct
goto err_get_irq;
}
+ printk(KERN_INFO DRV_NAME
+ " hw_addr at 0x%x, hw_addr_cmd at 0x%x, irq is %d\n",
+ (int)ks->hw_addr, (int) ks->hw_addr_cmd, ks->irq);
+
ks->pdev = pdev;
mutex_init(&ks->lock);
@@ -1612,11 +1611,9 @@ static int __devinit ks8851_probe(struct
ks_soft_reset(ks, GRR_GSR);
ks_hw_init(ks);
- ks_disable(ks);
+ ks_disable_qmu(ks);
ks_setup(ks);
ks_setup_int(ks);
- ks_enable_int(ks);
- ks_enable(ks);
memcpy(netdev->dev_addr, ks->mac_addr, 6);
data = ks_rdreg16(ks, KS_OBCR);
@@ -1658,6 +1655,7 @@ static int __devexit ks8851_remove(struc
struct ks_net *ks = netdev_priv(netdev);
struct resource *iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ kfree(ks->frame_head_info);
unregister_netdev(netdev);
iounmap(ks->hw_addr);
free_netdev(netdev);
--
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/2] ethtool: Add PHY type to ethtool get_drvinfo
From: Stephen Hemminger @ 2009-11-18 0:41 UTC (permalink / raw)
To: Waskiewicz Jr, Peter P
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com, Waskiewicz Jr, Peter P
In-Reply-To: <Pine.WNT.4.64.0911171156090.15476@ppwaskie-MOBL2.amr.corp.intel.com>
On Tue, 17 Nov 2009 11:56:57 -0800 (Pacific Standard Time)
"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel.com> wrote:
> On Tue, 17 Nov 2009, Stephen Hemminger wrote:
>
> > On Tue, 17 Nov 2009 08:13:24 -0800
> > Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> >
> > > From: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
> > >
> > > Allow the PHY type to be passed from a driver to ethtool when
> > > ethtool -i ethX is called. With newer network cards having SFP
> > > and SFP+ PHY cages, this information can be useful, especially
> > > if the NIC supports hot-swapping of the PHY modules.
> > >
> > > Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> > > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > > ---
> >
> > Maybe revive usage of connector port in ethtool rather than adding new API?
> > It is already there but values are out of date with current hardware.
>
> You're referring to the MODE_GSET port settings? If so, I like this
> approach, and will update my patches accordingly.
Yes. cmd->port is always PORT_TP or PORT_FIBRE now but could be extended
Likewise cmd->transceiver could be modified. I haven't seen an external transceiver
since the old fat yellow cable with vampire taps (and that was 20 yrs ago).
^ permalink raw reply
* Re: [net-next-2.6 PATCH] net: device name allocation cleanups
From: Stephen Hemminger @ 2009-11-18 0:42 UTC (permalink / raw)
To: Octavian Purdila; +Cc: netdev
In-Reply-To: <200911172233.53119.opurdila@ixiacom.com>
On Tue, 17 Nov 2009 22:33:53 +0200
Octavian Purdila <opurdila@ixiacom.com> wrote:
> +static int dev_get_valid_name(struct net *net, const char *name, char *buf,
> + int fmt)
you are using fmt as a boolean so declare it 'bool'?
--
^ permalink raw reply
* Re: [net-next-2.6 PATCH] net: device name allocation cleanups
From: Stephen Hemminger @ 2009-11-18 0:46 UTC (permalink / raw)
To: Octavian Purdila; +Cc: netdev
In-Reply-To: <200911172233.53119.opurdila@ixiacom.com>
On Tue, 17 Nov 2009 22:33:53 +0200
Octavian Purdila <opurdila@ixiacom.com> wrote:
> + if (fmt) {
> + if (strchr(name, '%'))
> + return __dev_alloc_name(net, name, buf);
> + }
> +
> + if (__dev_get_by_name(net, name))
Flatten this logic out.
if (fmt && strchr(name, '%'))
return __dev_alloc_name(net, name, buf);
else if (__dev_get_by_name(net, name))
return -EEXIST;
else if (buf != name)
strlcpy(buf, name, IFNAMSIZ);
return 0;
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/2] ethtool: Add PHY type to ethtool get_drvinfo
From: Waskiewicz Jr, Peter P @ 2009-11-18 0:47 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Waskiewicz Jr, Peter P, Kirsher, Jeffrey T, davem@davemloft.net,
netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <20091117164104.5da05b81@nehalam>
On Tue, 17 Nov 2009, Stephen Hemminger wrote:
> On Tue, 17 Nov 2009 11:56:57 -0800 (Pacific Standard Time)
> "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel.com> wrote:
>
> > On Tue, 17 Nov 2009, Stephen Hemminger wrote:
> >
> > > On Tue, 17 Nov 2009 08:13:24 -0800
> > > Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> > >
> > > > From: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
> > > >
> > > > Allow the PHY type to be passed from a driver to ethtool when
> > > > ethtool -i ethX is called. With newer network cards having SFP
> > > > and SFP+ PHY cages, this information can be useful, especially
> > > > if the NIC supports hot-swapping of the PHY modules.
> > > >
> > > > Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> > > > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > > > ---
> > >
> > > Maybe revive usage of connector port in ethtool rather than adding new API?
> > > It is already there but values are out of date with current hardware.
> >
> > You're referring to the MODE_GSET port settings? If so, I like this
> > approach, and will update my patches accordingly.
>
> Yes. cmd->port is always PORT_TP or PORT_FIBRE now but could be extended
> Likewise cmd->transceiver could be modified. I haven't seen an external transceiver
> since the old fat yellow cable with vampire taps (and that was 20 yrs ago).
I have patches that I sent to Jeff for internal testing that fixes up the
cmd->port field (per your and Ben's suggestion). I like it much better
too. :-)
-PJ
^ permalink raw reply
* [PATCH] ibm_newemac: Fix EMACx_TRTR[TRT] bit shifts
From: Dave Mitchell @ 2009-11-18 0:56 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, dmitchell
The TRT bit shifts were reversed for EMAC4 and non-EMAC4 during the
port from ibm_emac to ibm_newemac. This patch corrects that error.
Signed-off-by: Dave Mitchell <dmitchell@appliedmicro.com>
Acked-by: Feng Kan <fkan@appliedmicro.com>
Acked-by: Prodyut Hazarika <phazarika@appliedmicro.com>
---
For those curious, these bits control the TX threshold.
drivers/net/ibm_newemac/emac.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ibm_newemac/emac.h b/drivers/net/ibm_newemac/emac.h
index d34adf9..f2751cb 100644
--- a/drivers/net/ibm_newemac/emac.h
+++ b/drivers/net/ibm_newemac/emac.h
@@ -263,8 +263,8 @@ struct emac_regs {
/* EMACx_TRTR */
-#define EMAC_TRTR_SHIFT_EMAC4 27
-#define EMAC_TRTR_SHIFT 24
+#define EMAC_TRTR_SHIFT_EMAC4 24
+#define EMAC_TRTR_SHIFT 27
/* EMAC specific TX descriptor control fields (write access) */
#define EMAC_TX_CTRL_GFCS 0x0200
--
1.6.3.2
^ permalink raw reply related
* Re: [net-next-2.6 PATCH 1/2] ethtool: Add PHY type to ethtool get_drvinfo
From: Ben Hutchings @ 2009-11-18 1:23 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Waskiewicz Jr, Peter P, Kirsher, Jeffrey T, davem@davemloft.net,
netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <20091117164104.5da05b81@nehalam>
On Tue, 2009-11-17 at 16:41 -0800, Stephen Hemminger wrote:
> On Tue, 17 Nov 2009 11:56:57 -0800 (Pacific Standard Time)
> "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel.com> wrote:
>
> > On Tue, 17 Nov 2009, Stephen Hemminger wrote:
> >
> > > On Tue, 17 Nov 2009 08:13:24 -0800
> > > Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> > >
> > > > From: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
> > > >
> > > > Allow the PHY type to be passed from a driver to ethtool when
> > > > ethtool -i ethX is called. With newer network cards having SFP
> > > > and SFP+ PHY cages, this information can be useful, especially
> > > > if the NIC supports hot-swapping of the PHY modules.
> > > >
> > > > Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> > > > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > > > ---
> > >
> > > Maybe revive usage of connector port in ethtool rather than adding new API?
> > > It is already there but values are out of date with current hardware.
> >
> > You're referring to the MODE_GSET port settings? If so, I like this
> > approach, and will update my patches accordingly.
>
> Yes. cmd->port is always PORT_TP or PORT_FIBRE now but could be extended
> Likewise cmd->transceiver could be modified. I haven't seen an external transceiver
> since the old fat yellow cable with vampire taps (and that was 20 yrs ago).
It seems to me there should be a transceiver type code or codes for
connectors like SFP where the bulk of the transceiver is internal but
the optical part is an external module. SFP+ is a tricky case because
it also supports passive cables.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH] Documentation, clarify tuntap IPX example.
From: andrew hendry @ 2009-11-18 1:30 UTC (permalink / raw)
To: maxk, netdev; +Cc: linux-kernel
Can the TUNSETIFF ioctl change a tap's protocol to IPX as the
documentation suggests?
I think tun.c would need IFF_IPX_TAP added for it to work as described?
Otherwise tap can only be ptp or ethernet, and there is no way to
route or use AF_IPX.
Signed-off-by: Andrew Hendry <andrew.hendry@gmail.com>
--- a/Documentation/networking/tuntap.txt 2009-11-11
14:03:22.676167648 +1100
+++ b/Documentation/networking/tuntap.txt 2009-11-18
11:34:18.106647029 +1100
@@ -127,12 +127,14 @@ Ethernet device, which instead of receiv
media, receives them from user space program and instead of sending
packets via physical media sends them to the user space program.
-Let's say that you configured IPX on the tap0, then whenever
-the kernel sends an IPX packet to tap0, it is passed to the application
-(VTun for example). The application encrypts, compresses and sends it to
-the other side over TCP or UDP. The application on the other side decompresses
-and decrypts the data received and writes the packet to the TAP device,
-the kernel handles the packet like it came from real physical device.
+Let's say for the purpose of example, IPX support was added to tuntap.
+Then whenever the kernel routes an IPX packet to tap0, it is passed to the
+application reading the file descriptor from /dev/net/tun (VTun for example).
+The application encrypts, compresses and sends it to the other side over TCP
+or UDP. The application on the other side decompresses and decrypts the data
+received and writes the packet to the TAP device, the remote kernel handles
+the packet like it came from real physical device. The IPX applications are
+able to communicate as if there was a real IPX network.
4. What is the difference between TUN driver and TAP driver?
TUN works with IP frames. TAP works with Ethernet frames.
^ permalink raw reply
* Re: [PATCH] Documentation, clarify tuntap IPX example.
From: Max Krasnyansky @ 2009-11-18 1:40 UTC (permalink / raw)
To: andrew hendry; +Cc: netdev@vger.kernel.org, linux-kernel
In-Reply-To: <d45a3acc0911171730kc3a03d5iacec6d9ef4b1874c@mail.gmail.com>
On 11/17/2009 05:30 PM, andrew hendry wrote:
> Can the TUNSETIFF ioctl change a tap's protocol to IPX as the
> documentation suggests?
> I think tun.c would need IFF_IPX_TAP added for it to work as described?
> Otherwise tap can only be ptp or ethernet, and there is no way to
> route or use AF_IPX.
TAP is an Ethernet device. No special handling is required for IPX or
for that matter any other protocol. Example seems fine too.
Max
> Signed-off-by: Andrew Hendry<andrew.hendry@gmail.com>
>
> --- a/Documentation/networking/tuntap.txt 2009-11-11
> 14:03:22.676167648 +1100
> +++ b/Documentation/networking/tuntap.txt 2009-11-18
> 11:34:18.106647029 +1100
> @@ -127,12 +127,14 @@ Ethernet device, which instead of receiv
> media, receives them from user space program and instead of sending
> packets via physical media sends them to the user space program.
>
> -Let's say that you configured IPX on the tap0, then whenever
> -the kernel sends an IPX packet to tap0, it is passed to the application
> -(VTun for example). The application encrypts, compresses and sends it to
> -the other side over TCP or UDP. The application on the other side decompresses
> -and decrypts the data received and writes the packet to the TAP device,
> -the kernel handles the packet like it came from real physical device.
> +Let's say for the purpose of example, IPX support was added to tuntap.
> +Then whenever the kernel routes an IPX packet to tap0, it is passed to the
> +application reading the file descriptor from /dev/net/tun (VTun for example).
> +The application encrypts, compresses and sends it to the other side over TCP
> +or UDP. The application on the other side decompresses and decrypts the data
> +received and writes the packet to the TAP device, the remote kernel handles
> +the packet like it came from real physical device. The IPX applications are
> +able to communicate as if there was a real IPX network.
>
> 4. What is the difference between TUN driver and TAP driver?
> TUN works with IP frames. TAP works with Ethernet frames.
^ permalink raw reply
* Re: [RFC v2] mac80211: disallow bridging managed/adhoc interfaces
From: Stefan Monnier @ 2009-11-18 1:59 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA; +Cc: netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1258490898.21197.42.camel@johannes.local>
> A number of people have tried to add a wireless interface
> (in managed mode) to a bridge and then complained that it
> doesn't work. It cannot work, however, because in 802.11
[...]
> To avoid such mistakes in the future, disallow adding a
> wireless interface to a bridge.
As someone who's been bitten by this, I fully support this change.
Still, it makes me wonder: my broadcom-based home-router using the wl.o
driver can be set in "client bridge" mode. How does it work?
Stefan
--
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
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