* [PATCH 05/11] ipv6: move route updating for redirect to ndisc layer
From: Duan Jiong @ 2013-09-12 10:47 UTC (permalink / raw)
To: davem; +Cc: netdev, hannes
In-Reply-To: <52319A6E.6090503@cn.fujitsu.com>
From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
---
net/ipv6/icmp.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
index eef8d94..4bde43c 100644
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -91,8 +91,6 @@ static void icmpv6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
if (type == ICMPV6_PKT_TOOBIG)
ip6_update_pmtu(skb, net, info, 0, 0);
- else if (type == NDISC_REDIRECT)
- ip6_redirect(skb, net, skb->dev->ifindex, 0);
if (!(type & ICMPV6_INFOMSG_MASK))
if (icmp6->icmp6_type == ICMPV6_ECHO_REQUEST)
--
1.8.3.1
^ permalink raw reply related
* [PATCH 04/11] ipv6: move route updating for redirect to ndisc layer
From: Duan Jiong @ 2013-09-12 10:46 UTC (permalink / raw)
To: davem; +Cc: netdev, hannes
In-Reply-To: <52319A6E.6090503@cn.fujitsu.com>
From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
So the esp6_err() only handle the ICMPV6_PKT_TOOBIG.
Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
---
net/ipv6/esp6.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index d3618a7..6aa64e1 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -436,9 +436,7 @@ static void esp6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
struct ip_esp_hdr *esph = (struct ip_esp_hdr *)(skb->data + offset);
struct xfrm_state *x;
- if (type != ICMPV6_DEST_UNREACH &&
- type != ICMPV6_PKT_TOOBIG &&
- type != NDISC_REDIRECT)
+ if (type != ICMPV6_PKT_TOOBIG)
return;
x = xfrm_state_lookup(net, skb->mark, (const xfrm_address_t *)&iph->daddr,
@@ -446,10 +444,7 @@ static void esp6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
if (!x)
return;
- if (type == NDISC_REDIRECT)
- ip6_redirect(skb, net, skb->dev->ifindex, 0);
- else
- ip6_update_pmtu(skb, net, info, 0, 0);
+ ip6_update_pmtu(skb, net, info, 0, 0);
xfrm_state_put(x);
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH 03/11] ipv6: move route updating for redirect to ndisc layer
From: Duan Jiong @ 2013-09-12 10:45 UTC (permalink / raw)
To: davem; +Cc: netdev, hannes
In-Reply-To: <52319A6E.6090503@cn.fujitsu.com>
From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
So the ah6_err() only handle the ICMPV6_PKT_TOOBIG.
Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
---
net/ipv6/ah6.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/net/ipv6/ah6.c b/net/ipv6/ah6.c
index 73784c3..79fb40f 100644
--- a/net/ipv6/ah6.c
+++ b/net/ipv6/ah6.c
@@ -618,19 +618,14 @@ static void ah6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
struct ip_auth_hdr *ah = (struct ip_auth_hdr*)(skb->data+offset);
struct xfrm_state *x;
- if (type != ICMPV6_DEST_UNREACH &&
- type != ICMPV6_PKT_TOOBIG &&
- type != NDISC_REDIRECT)
+ if (type != ICMPV6_PKT_TOOBIG)
return;
x = xfrm_state_lookup(net, skb->mark, (xfrm_address_t *)&iph->daddr, ah->spi, IPPROTO_AH, AF_INET6);
if (!x)
return;
- if (type == NDISC_REDIRECT)
- ip6_redirect(skb, net, skb->dev->ifindex, 0);
- else
- ip6_update_pmtu(skb, net, info, 0, 0);
+ ip6_update_pmtu(skb, net, info, 0, 0);
xfrm_state_put(x);
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH 02/11] dccp: move route updating for redirect to ndisc layer
From: Duan Jiong @ 2013-09-12 10:44 UTC (permalink / raw)
To: davem; +Cc: netdev, hannes
In-Reply-To: <52319A6E.6090503@cn.fujitsu.com>
From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
In additon, like net/ipv6/tcp_ipv6.c, when dealing with
redirect message, it should directly return;
Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
---
net/dccp/ipv6.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c
index 9c61f9c..300840c 100644
--- a/net/dccp/ipv6.c
+++ b/net/dccp/ipv6.c
@@ -98,6 +98,9 @@ static void dccp_v6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
return;
}
+ if (type == NDISC_REDIRECT)
+ return;
+
sk = inet6_lookup(net, &dccp_hashinfo,
&hdr->daddr, dh->dccph_dport,
&hdr->saddr, dh->dccph_sport, inet6_iif(skb));
@@ -130,13 +133,6 @@ static void dccp_v6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
np = inet6_sk(sk);
- if (type == NDISC_REDIRECT) {
- struct dst_entry *dst = __sk_dst_check(sk, np->dst_cookie);
-
- if (dst)
- dst->ops->redirect(dst, sk, skb);
- }
-
if (type == ICMPV6_PKT_TOOBIG) {
struct dst_entry *dst = NULL;
--
1.8.3.1
^ permalink raw reply related
* [PATCH 01/11] ipv6: Do route updating for redirect in ndisc layer
From: Duan Jiong @ 2013-09-12 10:43 UTC (permalink / raw)
To: davem; +Cc: netdev, hannes
In-Reply-To: <52319A6E.6090503@cn.fujitsu.com>
From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Do the whole verification and route updating in ndisc
lay and then just call into icmpv6_notify() to notify
the upper protocols if we have the data of the
redirected header option.
Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
---
include/net/ip6_route.h | 3 ---
net/ipv6/ndisc.c | 6 ++----
net/ipv6/route.c | 29 ++---------------------------
3 files changed, 4 insertions(+), 34 deletions(-)
diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
index f525e70..5db259e 100644
--- a/include/net/ip6_route.h
+++ b/include/net/ip6_route.h
@@ -133,9 +133,6 @@ extern void ip6_update_pmtu(struct sk_buff *skb, struct net *net, __be32 mtu,
extern void ip6_sk_update_pmtu(struct sk_buff *skb, struct sock *sk,
__be32 mtu);
extern void ip6_redirect(struct sk_buff *skb, struct net *net, int oif, u32 mark);
-extern void ip6_redirect_no_header(struct sk_buff *skb, struct net *net, int oif,
- u32 mark);
-extern void ip6_sk_redirect(struct sk_buff *skb, struct sock *sk);
struct netlink_callback;
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index f8a55ff..6bd1b41 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1368,11 +1368,9 @@ static void ndisc_redirect_rcv(struct sk_buff *skb)
if (!ndisc_parse_options(msg->opt, ndoptlen, &ndopts))
return;
- if (!ndopts.nd_opts_rh) {
- ip6_redirect_no_header(skb, dev_net(skb->dev),
- skb->dev->ifindex, 0);
+ ip6_redirect(skb, dev_net(skb->dev), skb->dev->ifindex, 0);
+ if (!ndopts.nd_opts_rh)
return;
- }
hdr = (u8 *)ndopts.nd_opts_rh;
hdr += 8;
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index c979dd9..151bd6c 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1227,27 +1227,7 @@ static struct dst_entry *ip6_route_redirect(struct net *net,
flags, __ip6_route_redirect);
}
-void ip6_redirect(struct sk_buff *skb, struct net *net, int oif, u32 mark)
-{
- const struct ipv6hdr *iph = (struct ipv6hdr *) skb->data;
- struct dst_entry *dst;
- struct flowi6 fl6;
-
- memset(&fl6, 0, sizeof(fl6));
- fl6.flowi6_oif = oif;
- fl6.flowi6_mark = mark;
- fl6.flowi6_flags = 0;
- fl6.daddr = iph->daddr;
- fl6.saddr = iph->saddr;
- fl6.flowlabel = ip6_flowinfo(iph);
-
- dst = ip6_route_redirect(net, &fl6, &ipv6_hdr(skb)->saddr);
- rt6_do_redirect(dst, NULL, skb);
- dst_release(dst);
-}
-EXPORT_SYMBOL_GPL(ip6_redirect);
-
-void ip6_redirect_no_header(struct sk_buff *skb, struct net *net, int oif,
+void ip6_redirect(struct sk_buff *skb, struct net *net, int oif,
u32 mark)
{
const struct ipv6hdr *iph = ipv6_hdr(skb);
@@ -1266,12 +1246,7 @@ void ip6_redirect_no_header(struct sk_buff *skb, struct net *net, int oif,
rt6_do_redirect(dst, NULL, skb);
dst_release(dst);
}
-
-void ip6_sk_redirect(struct sk_buff *skb, struct sock *sk)
-{
- ip6_redirect(skb, sock_net(sk), sk->sk_bound_dev_if, sk->sk_mark);
-}
-EXPORT_SYMBOL_GPL(ip6_sk_redirect);
+EXPORT_SYMBOL_GPL(ip6_redirect);
static unsigned int ip6_default_advmss(const struct dst_entry *dst)
{
--
1.8.3.1
^ permalink raw reply related
* [PATCH 00/11] ipv6: Do route updating for redirect in ndisc layer
From: Duan Jiong @ 2013-09-12 10:41 UTC (permalink / raw)
To: davem; +Cc: netdev, hannes
the ip6_redirect() could be replaced with
ip6_redirect_no_header(), we could always use ip6_redirect()
for route updating in ndisc layer and use the data of the
redirected header option just for finding the socket to be
notified and then notify user in protocols' err_handler.
---
include/net/ip6_route.h | 3 ---
net/dccp/ipv6.c | 10 +++-------
net/ipv6/ah6.c | 9 ++-------
net/ipv6/esp6.c | 9 ++-------
net/ipv6/icmp.c | 2 --
net/ipv6/ip6_tunnel.c | 5 -----
net/ipv6/ipcomp6.c | 9 ++-------
net/ipv6/ndisc.c | 6 ++----
net/ipv6/raw.c | 2 +-
net/ipv6/route.c | 29 ++---------------------------
net/ipv6/tcp_ipv6.c | 12 ++++--------
net/ipv6/udp.c | 4 ++--
net/sctp/input.c | 12 ------------
net/sctp/ipv6.c | 6 +++---
14 files changed, 23 insertions(+), 95 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: ip l2tp - suspected defect using IPv6 local/remote addresses
From: James Chapman @ 2013-09-12 10:20 UTC (permalink / raw)
To: Jeff Loughridge; +Cc: netdev
In-Reply-To: <CAG2uBVfwNOj_jKvaHV_66qrrBU5adDoqDWMvV7seNWfsG4RVAQ@mail.gmail.com>
On 11 September 2013 19:52, Jeff Loughridge <jeffl@alumni.duke.edu> wrote:
>
> Using IPv6 address as L2TPv3 endpoints doesn't seem to work in
> iproute2 3.11. I see a cosmetic defect in the output of 'ip l2tp show
> tunnel'. In addition, I can't get tunnels to function with UDP or IP
> encapsulation.
>
> root@debian:~# ip l2tp add tunnel tunnel_id 3000 peer_tunnel_id 4000
> encap udp local a::1 remote a::2 udp_sport 5000 udp_dport 6000
> root@debian:~# ip l2tp add session tunnel_id 3000 session_id 1000
> peer_session_id 2000
> root@debian:~# ip l2tp show tunnel
> Tunnel 3000, encap UDP
> From 127.0.0.1 to 127.0.0.1
> Peer tunnel 4000
> UDP source / dest ports: 5000/6000
> root@debian:~#
You'll need a 3.5 or later kernel for L2TP over IPv6. I see you are
using 3.2. Are you using a version of iproute2 which is not matched to
your kernel?
> See below for more details about my set-up. I have no problems using
> IPv4 endpoints.
>
> root@debian:~# ip addr show eth0
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UNKNOWN group default qlen 1000
> link/ether 00:0c:29:91:cb:3c brd ff:ff:ff:ff:ff:ff
> inet 5.1.0.100/24 scope global eth0
> inet6 a::1/64 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::20c:29ff:fe91:cb3c/64 scope link
> valid_lft forever preferred_lft forever
> root@debian:~#
> root@debian:~# ip -V
> ip utility, iproute2-ss130903
> root@debian:~# uname -a
> Linux debian 3.2.0-4-686-pae #1 SMP Debian 3.2.41-2 i686 GNU/Linux
> root@debian:~#
> root@debian:~# modprobe l2tp_eth
> root@debian:~# lsmod | grep l2tp
> l2tp_eth 12738 0
> l2tp_netlink 17263 1 l2tp_eth
> l2tp_core 17486 2 l2tp_netlink,l2tp_eth
>
> Jeff L.
^ permalink raw reply
* Re: XGMII support
From: Florian Fainelli @ 2013-09-12 9:09 UTC (permalink / raw)
To: Rayagond K; +Cc: netdev
In-Reply-To: <CAJ3bTp5kc-4eqQObCJ7xyCBTrBGp3yGLRGQZZMXdhTvsYahLFw@mail.gmail.com>
Hello,
2013/9/12 Rayagond K <rayagond@vayavyalabs.com>:
> Hi All,
>
> I was going through include/linux/phy.h file to check what all phy
> interface Linux supports. The enum "phy_interface_t" has entry for
> MII, GMII, TBI, SGMII, RMII etc but I didn't find entry for XGMII
> interface. So my questions are following,
>
> 1. How to support XGMII using phylib ?
phylib only needs to know about a phy_interface_t that is going to be
used by your Ethernet MAC adjust_link() callback to properly configure
the physical link between the MAC and the PHY. From a phylib
perspective there is no knowledge of how to configure based on the
*MII interface, this is the reponsibility of the Ethernet MAC driver
based on the "phydev->interface".
> 2. What are PHY_INTERFACE_MODE_RGMII_ID, PHY_INTERFACE_MODE_RGMII_RXID
> and PHY_INTERFACE_MODE_RGMII_TXID ?
They respectively stand for: "Reduced GMII with TX and RX internal
delay", "Reduced GMII with RX internal delay" and "Reduced GMII with
TX internal delay". In practice this is used when either the TX/RX or
both clocks and data lines needs to have a different phases (90
degrees in general).
--
Florian
^ permalink raw reply
* Re: [PATCH 20/52] net: fealnx: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-09-12 8:40 UTC (permalink / raw)
To: 'David Miller'; +Cc: sergei.shtylyov, netdev, 'Jingoo Han'
In-Reply-To: <20130912.041922.87675350693543309.davem@davemloft.net>
On Thursday, September 12, 2013 5:19 PM, David Miller wrote:
> On Thu, 12 Sep 2013 16:54:14 +0900, Jingoo Han wrote:
>
> > I have to split the patches into several chunks, and send them
> > over few weeks?
> > For example,
> > one day: 15 patches
> > 2 weeks later: 15 patches
> > 2 weeks later: 15 patches
> > 2 weeks later: 7 patches
>
> You can send the new chunk after I apply the previous one.
OK, I see.
I will do so as you guide. :-)
I will be more careful.
Thank you for your guidance.
Best regards,
Jingoo Han
^ permalink raw reply
* [PATCH] Inet-hashtable: Change the range of sk->hash lock to avoid the race condition.
From: Jun Chen @ 2013-09-12 16:32 UTC (permalink / raw)
To: edumazet; +Cc: davem, eric.dumazet, netdev, linux-kernel, Jun Chen
When try to add node to list in __inet_hash_nolisten function, first get the
list and then to lock for using, but in extremeness case, others can del this
node before locking it, then the node should be null.So this patch try to lock
firstly and then get the list for using to avoid this race condition.
Signed-off-by: Chen Jun <jun.d.chen@intel.com>
---
net/ipv4/inet_hashtables.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
index 7bd8983..76e846e 100644
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -407,12 +407,15 @@ int __inet_hash_nolisten(struct sock *sk, struct inet_timewait_sock *tw)
WARN_ON(!sk_unhashed(sk));
sk->sk_hash = inet_sk_ehashfn(sk);
- head = inet_ehash_bucket(hashinfo, sk->sk_hash);
- list = &head->chain;
lock = inet_ehash_lockp(hashinfo, sk->sk_hash);
spin_lock(lock);
- __sk_nulls_add_node_rcu(sk, list);
+ if (sk_hashed(sk)) {
+ head = inet_ehash_bucket(hashinfo, sk->sk_hash);
+ list = &head->chain;
+ __sk_nulls_add_node_rcu(sk, list);
+ }
+
if (tw) {
WARN_ON(sk->sk_hash != tw->tw_hash);
twrefcnt = inet_twsk_unhash(tw);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 20/52] net: fealnx: remove unnecessary pci_set_drvdata()
From: David Miller @ 2013-09-12 8:19 UTC (permalink / raw)
To: jg1.han; +Cc: sergei.shtylyov, netdev
In-Reply-To: <000001ceaf8d$46951cf0$d3bf56d0$%han@samsung.com>
From: Jingoo Han <jg1.han@samsung.com>
Date: Thu, 12 Sep 2013 16:54:14 +0900
> I have to split the patches into several chunks, and send them
> over few weeks?
> For example,
> one day: 15 patches
> 2 weeks later: 15 patches
> 2 weeks later: 15 patches
> 2 weeks later: 7 patches
You can send the new chunk after I apply the previous one.
^ permalink raw reply
* Re: [PATCH] bfin_mac: remove deprecated IRQF_DISABLED
From: Jingoo Han @ 2013-09-12 8:09 UTC (permalink / raw)
To: 'Michael Opdenacker', davem
Cc: richardcochran, jiri, mugunthanvnm, uclinux-dist-devel, netdev,
linux-kernel
In-Reply-To: <1378956943-3470-1-git-send-email-michael.opdenacker@free-electrons.com>
On Thursday, September 12, 2013 12:36 PM, Michael Opdenacker wrote:
>
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/adi/bfin_mac.c.
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Reviewed-by: Jingoo Han <jg1.han@samsung.com>
Best regards,
Jingoo Han
> ---
> drivers/net/ethernet/adi/bfin_mac.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH net 2/4] bridge: Handle priority-tagged frames properly
From: Toshiaki Makita @ 2013-09-12 8:08 UTC (permalink / raw)
To: vyasevic
Cc: David S. Miller, netdev, Fernando Luis Vazquez Cao,
Patrick McHardy
In-Reply-To: <52309B01.4060607@redhat.com>
On Wed, 2013-09-11 at 12:32 -0400, Vlad Yasevich wrote:
> On 09/11/2013 03:00 AM, Toshiaki Makita wrote:
> > On Tue, 2013-09-10 at 10:03 -0400, Vlad Yasevich wrote:
> >> On 09/10/2013 06:34 AM, Toshiaki Makita wrote:
> >>> IEEE 802.1Q says that when we receive priority-tagged (VID 0) frames
> >>> use the PVID for the port as its VID.
> >>> (See IEEE 802.1Q-2005 6.7.1 and Table 9-2)
> >>>
> >>> Apply the PVID to not only untagged frames but also priority-tagged frames.
> >>>
> >>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> >>> ---
> >>> net/bridge/br_vlan.c | 27 ++++++++++++++++++++-------
> >>> 1 file changed, 20 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
> >>> index 21b6d21..5a9c44a 100644
> >>> --- a/net/bridge/br_vlan.c
> >>> +++ b/net/bridge/br_vlan.c
> >>> @@ -189,6 +189,8 @@ out:
> >>> bool br_allowed_ingress(struct net_bridge *br, struct net_port_vlans *v,
> >>> struct sk_buff *skb, u16 *vid)
> >>> {
> >>> + int err;
> >>> +
> >>> /* If VLAN filtering is disabled on the bridge, all packets are
> >>> * permitted.
> >>> */
> >>> @@ -201,20 +203,31 @@ bool br_allowed_ingress(struct net_bridge *br, struct net_port_vlans *v,
> >>> if (!v)
> >>> return false;
> >>>
> >>> - if (br_vlan_get_tag(skb, vid)) {
> >>> + err = br_vlan_get_tag(skb, vid);
> >>> + if (!*vid) {
> >>> u16 pvid = br_get_pvid(v);
> >>>
> >>> - /* Frame did not have a tag. See if pvid is set
> >>> - * on this port. That tells us which vlan untagged
> >>> - * traffic belongs to.
> >>> + /* Frame had a tag with VID 0 or did not have a tag.
> >>> + * See if pvid is set on this port. That tells us which
> >>> + * vlan untagged or priority-tagged traffic belongs to.
> >>> */
> >>> if (pvid == VLAN_N_VID)
> >>> return false;
> >>>
> >>> - /* PVID is set on this port. Any untagged ingress
> >>> - * frame is considered to belong to this vlan.
> >>> + /* PVID is set on this port. Any untagged or priority-tagged
> >>> + * ingress frame is considered to belong to this vlan.
> >>> */
> >>> - __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), pvid);
> >>> + if (likely(err))
> >>> + /* Untagged Frame. */
> >>> + __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), pvid);
> >>> + else
> >>> + /* Priority-tagged Frame.
> >>> + * At this point, We know that skb->vlan_tci had
> >>> + * VLAN_TAG_PRESENT bit and its VID field was 0x000.
> >>> + * We update only VID field and preserve PCP field.
> >>> + */
> >>> + skb->vlan_tci |= pvid;
> >>> +
> >>
> >> In the case of a priority tagged frame, we should unroll the
> >> modification above and restore the VID field to 0. Otherwise, you
> >> may end up either stripping the vlan header completely or forwarding
> >> with pvid of the ingress port.
> >
> > Thank you for reviewing.
> >
> > It is my intended behavior that an incoming priority-tagged frame is
> > forwarded as a frame untagged or tagged with pvid.
> >
> > IEEE 802.1Q-2011:
> >
> > section 8.1.7 Conversion of frame formats
> >
> > NOTE - As all incoming frames, including priority-tagged frames, are
> > classified as belonging to a VLAN, the transmitting Port transmits
> > VLAN-tagged frames or untagged frames. Hence, a station sending a
> > priority-tagged frame via a Bridge will receive a response that is
> > either VLAN-tagged or untagged, as described in 8.5.
> >
> > 3. Definitions
> >
> > 3.132 Priority-tagged frame: A tagged frame whose tag header carries
> > priority information but carries no VLAN identification information.
> >
> > 3.203 VLAN-tagged frame: A VLAN-tagged frame is a tagged frame whose
> > tag header carries *both* VLAN identification and priority
> > information.
> >
> > Toshiaki Makita
> >
>
> Hmm.. The problem is that if a system attached to a port configures a
> vlan interface with vid 0 and some priority mappings, then that
> interface will not be able to properly receive traffic, as the bridge
> now will never transmit priority tagged frames.
>
> -vlad
I see. As you say, for example, if we configure vnet0.0 and attach
vnet0 to a bridge with vlan_filtering enabled, even though we are
sending priority-tagged frames from vnet0.0 and they are successfully
forwarded by the bridge to another port, we cannot receive any frame on
vnet0.0 because all incoming frames from a bridge port are not
priority-tagged and never passed to vnet0.0.
I think this might be a problem as an end station that cannot receive
incoming untagged frames and priority-tagged frames on the same
interface when vlan 0 interface is defined.
(We can receive both untagged and priority-tagged frames on the same
interface that is not configured vlan 0.)
If we assume it as a problem of vlan interface, I guess we should enable
vlan 0 interface to receive untagged frames (treat vnet0.0 as an alias
of vnet0), or add a setting of egress priority map to vnet0 so that vlan
0 interface can become unnecessary.
If it is preferable to deal with it by bridge, I don't think a
priority-tagged frame's VID field should be restored to 0 on the egress
port. If we do so, we may receive both untagged frames and
priority-tagged frames from a bridge port when another end station sends
both untagged and priority-tagged frames by mixture.
IMO, it will be resolved by adding a new per-port policy that enables us
to send priority-tagged frames instead of untagged frames, like the
"priority-tags" option of openvswitch.
This solution, however, makes the bridge not be conformed with IEEE
802.1Q, and the problem remains that we cannot receive any frames on a
vlan 0 interface such as eth0.0 when we connect eth0 to another 802.1Q
conformed switch.
I'd like to hear further comments or suggestions, everyone :)
Thanks,
Toshiaki Makita
>
> >>
> >> -vlad
> >>> return true;
> >>> }
> >>>
> >>>
> >
> >
^ permalink raw reply
* RE: [RFC PATCH] vsnprintf: Remove use of %n and convert existing uses
From: David Laight @ 2013-09-12 8:06 UTC (permalink / raw)
To: Al Viro, Joe Perches
Cc: Tetsuo Handa, linux-kernel, kosaki.motohiro, keescook, fweisbec,
dan.carpenter, devel, gregkh, tushar.behera, lidza.louina, davem,
kuznet, jmorris, yoshfuji, kaber, courmisch, vyasevich, nhorman,
netdev, linux-sctp
In-Reply-To: <20130912001911.GO13318@ZenIV.linux.org.uk>
> On Wed, Sep 11, 2013 at 05:04:17PM -0700, Joe Perches wrote:
> > On Thu, 2013-09-12 at 08:40 +0900, Tetsuo Handa wrote:
> > > Joe Perches wrote:
> > > > - seq_printf(m, "%s%d%n", con->name, con->index, &len);
> > > > + len = seq_printf(m, "%s%d", con->name, con->index);
> > >
> > > Isn't len always 0 or -1 ?
> >
> > Right. Well you're no fun...
> >
> > These uses would seem broken anyway because the
> > seq_printf isn't itself tested for correctness.
> >
> > Hmm.
> >
> > Also, there's a large amount of code that appears
> > to do calculations with pos or len like:
> >
> > pos += seq_printf(handle, fmt. ...)
>
> ... and most of that code proceeds to ignore pos completely.
> Note that ->show() is *NOT* supposed to return the number of
> characters it has/would like to have produced. Just return
> 0 and be done with that; overflows are dealt with just fine.
> The large amount, BTW, is below 100 lines, AFAICS, in rather
> few files.
>
> > There are very few that seem to use it correctly
> > like netfilter.
>
> > Suggestions?
Change the return type of seq_printf() to void and require that
code use access functions/macros to find the length and error
status. Possibly save the length of the last call separately.
David
^ permalink raw reply
* Re: [PATCH 20/52] net: fealnx: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-09-12 7:54 UTC (permalink / raw)
To: 'David Miller'; +Cc: sergei.shtylyov, netdev, 'Jingoo Han'
In-Reply-To: <20130912.033606.1689936899104585741.davem@davemloft.net>
On Thursday, September 12, 2013 4:36 PM, David Miller wrote:
> On Thu, 12 Sep 2013 14:49:56 +0900, Jingoo Han wrote:
> > On Thursday, September 12, 2013 2:25 PM, David Miller wrote:
> >> On Thu, 12 Sep 2013 09:11:01 +0900, Jingoo Han wrote:
> >> > Would you let know the reason not to add coding style fixes?
> >>
> >> They should be made seperately so that the individual changes
> >> can be reviewed more easily and without unnecessary unrelated
> >> changes mixed in.
> >
> > OK, I see. :-)
> > Thank you for your answer.
> > Then, I will send V2 patch soon.
>
> Please do not submit such a huge patch series in the future.
>
> Anything more than 16 patches at a time is not reasonable and
> overloads reviewer's capacity to look at your changes.
>
Then, in this case,
I have to split the patches into several chunks, and send them
over few weeks?
For example,
one day: 15 patches
2 weeks later: 15 patches
2 weeks later: 15 patches
2 weeks later: 7 patches
Best regards,
Jingoo Han
^ permalink raw reply
* Re: pull request: wireless 2013-09-10
From: David Miller @ 2013-09-12 7:53 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20130910193845.GD1960@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 10 Sep 2013 15:38:45 -0400
> This is a pull request for a few early fixes for the 3.12 stream.
Looks good, pulled, thanks John.
^ permalink raw reply
* Re: [PATCH 20/52] net: fealnx: remove unnecessary pci_set_drvdata()
From: David Miller @ 2013-09-12 7:36 UTC (permalink / raw)
To: jg1.han; +Cc: sergei.shtylyov, netdev
In-Reply-To: <000601ceaf7b$e8e7b2e0$bab718a0$%han@samsung.com>
From: Jingoo Han <jg1.han@samsung.com>
Date: Thu, 12 Sep 2013 14:49:56 +0900
> On Thursday, September 12, 2013 2:25 PM, David Miller wrote:
>> On Thu, 12 Sep 2013 09:11:01 +0900, Jingoo Han wrote:
>> > Would you let know the reason not to add coding style fixes?
>>
>> They should be made seperately so that the individual changes
>> can be reviewed more easily and without unnecessary unrelated
>> changes mixed in.
>
> OK, I see. :-)
> Thank you for your answer.
> Then, I will send V2 patch soon.
Please do not submit such a huge patch series in the future.
Anything more than 16 patches at a time is not reasonable and
overloads reviewer's capacity to look at your changes.
Thank you.
^ permalink raw reply
* Re: [Patch iproute2] vxlan: add ipv6 support
From: Cong Wang @ 2013-09-12 7:16 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Stephen Hemminger
In-Reply-To: <1378179210-1170-1-git-send-email-amwang@redhat.com>
On Tue, 2013-09-03 at 11:33 +0800, Cong Wang wrote:
> From: Cong Wang <amwang@redhat.com>
>
> The kernel already supports it, so add the support
> to iproute2 as well.
>
> Cc: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Cong Wang <amwang@redhat.com>
Stephen, could you take it if it looks good to you?
Thanks!
^ permalink raw reply
* bridge: Clamp forward_delay when enabling STP
From: Herbert Xu @ 2013-09-12 7:12 UTC (permalink / raw)
To: David S. Miller, Stephen Hemminger, netdev
At some point limits were added to forward_delay. However, the
limits are only enforced when STP is enabled. This created a
scenario where you could have a value outside the allowed range
while STP is disabled, which then stuck around even after STP
is enabled.
This patch fixes this by clamping the value when we enable STP.
I had to move the locking around a bit to ensure that there is
no window where someone could insert a value outside the range
while we're in the middle of enabling STP.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 598cb0b..cda8315 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -746,6 +746,7 @@ extern struct net_bridge_port *br_get_port(struct net_bridge *br,
extern void br_init_port(struct net_bridge_port *p);
extern void br_become_designated_port(struct net_bridge_port *p);
+extern void __br_set_forward_delay(struct net_bridge *br, unsigned long t);
extern int br_set_forward_delay(struct net_bridge *br, unsigned long x);
extern int br_set_hello_time(struct net_bridge *br, unsigned long x);
extern int br_set_max_age(struct net_bridge *br, unsigned long x);
diff --git a/net/bridge/br_stp.c b/net/bridge/br_stp.c
index 1c0a50f..e651211 100644
--- a/net/bridge/br_stp.c
+++ b/net/bridge/br_stp.c
@@ -544,18 +544,27 @@ int br_set_max_age(struct net_bridge *br, unsigned long val)
}
+void __br_set_forward_delay(struct net_bridge *br, unsigned long t)
+{
+ br->bridge_forward_delay = t;
+ if (br_is_root_bridge(br))
+ br->forward_delay = br->bridge_forward_delay;
+}
+
int br_set_forward_delay(struct net_bridge *br, unsigned long val)
{
unsigned long t = clock_t_to_jiffies(val);
+ int err = -ERANGE;
+ spin_lock_bh(&br->lock);
if (br->stp_enabled != BR_NO_STP &&
(t < BR_MIN_FORWARD_DELAY || t > BR_MAX_FORWARD_DELAY))
- return -ERANGE;
+ goto unlock;
- spin_lock_bh(&br->lock);
- br->bridge_forward_delay = t;
- if (br_is_root_bridge(br))
- br->forward_delay = br->bridge_forward_delay;
+ __br_set_forward_delay(br, t);
+ err = 0;
+
+unlock:
spin_unlock_bh(&br->lock);
- return 0;
+ return err;
}
diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c
index d45e760..108084a 100644
--- a/net/bridge/br_stp_if.c
+++ b/net/bridge/br_stp_if.c
@@ -129,6 +129,14 @@ static void br_stp_start(struct net_bridge *br)
char *envp[] = { NULL };
r = call_usermodehelper(BR_STP_PROG, argv, envp, UMH_WAIT_PROC);
+
+ spin_lock_bh(&br->lock);
+
+ if (br->bridge_forward_delay < BR_MIN_FORWARD_DELAY)
+ __br_set_forward_delay(br, BR_MIN_FORWARD_DELAY);
+ else if (br->bridge_forward_delay < BR_MAX_FORWARD_DELAY)
+ __br_set_forward_delay(br, BR_MAX_FORWARD_DELAY);
+
if (r == 0) {
br->stp_enabled = BR_USER_STP;
br_debug(br, "userspace STP started\n");
@@ -137,10 +145,10 @@ static void br_stp_start(struct net_bridge *br)
br_debug(br, "using kernel STP\n");
/* To start timers on any ports left in blocking */
- spin_lock_bh(&br->lock);
br_port_state_selection(br);
- spin_unlock_bh(&br->lock);
}
+
+ spin_unlock_bh(&br->lock);
}
static void br_stp_stop(struct net_bridge *br)
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* [PATCH 2/2] net: emaclite: Code cleanup
From: Michal Simek @ 2013-09-12 7:05 UTC (permalink / raw)
To: netdev
Cc: Michal Simek, David S. Miller, Jens Renner, Libo Chen,
Greg Kroah-Hartman, linux-kernel
In-Reply-To: <196d8368eee2d45eeeab40e96e2971f78ed8a79b.1378969499.git.michal.simek@xilinx.com>
[-- Attachment #1: Type: text/plain, Size: 3106 bytes --]
No function changes (s/\ \t/\t/g)
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/net/ethernet/xilinx/xilinx_emaclite.c | 28 +++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
index de39098..80dd404 100644
--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
@@ -31,7 +31,7 @@
#define DRIVER_NAME "xilinx_emaclite"
/* Register offsets for the EmacLite Core */
-#define XEL_TXBUFF_OFFSET 0x0 /* Transmit Buffer */
+#define XEL_TXBUFF_OFFSET 0x0 /* Transmit Buffer */
#define XEL_MDIOADDR_OFFSET 0x07E4 /* MDIO Address Register */
#define XEL_MDIOWR_OFFSET 0x07E8 /* MDIO Write Data Register */
#define XEL_MDIORD_OFFSET 0x07EC /* MDIO Read Data Register */
@@ -63,13 +63,13 @@
#define XEL_MDIOCTRL_MDIOEN_MASK 0x00000008 /* MDIO Enable */
/* Global Interrupt Enable Register (GIER) Bit Masks */
-#define XEL_GIER_GIE_MASK 0x80000000 /* Global Enable */
+#define XEL_GIER_GIE_MASK 0x80000000 /* Global Enable */
/* Transmit Status Register (TSR) Bit Masks */
-#define XEL_TSR_XMIT_BUSY_MASK 0x00000001 /* Tx complete */
-#define XEL_TSR_PROGRAM_MASK 0x00000002 /* Program the MAC address */
-#define XEL_TSR_XMIT_IE_MASK 0x00000008 /* Tx interrupt enable bit */
-#define XEL_TSR_XMIT_ACTIVE_MASK 0x80000000 /* Buffer is active, SW bit
+#define XEL_TSR_XMIT_BUSY_MASK 0x00000001 /* Tx complete */
+#define XEL_TSR_PROGRAM_MASK 0x00000002 /* Program the MAC address */
+#define XEL_TSR_XMIT_IE_MASK 0x00000008 /* Tx interrupt enable bit */
+#define XEL_TSR_XMIT_ACTIVE_MASK 0x80000000 /* Buffer is active, SW bit
* only. This is not documented
* in the HW spec */
@@ -77,21 +77,21 @@
#define XEL_TSR_PROG_MAC_ADDR (XEL_TSR_XMIT_BUSY_MASK | XEL_TSR_PROGRAM_MASK)
/* Receive Status Register (RSR) */
-#define XEL_RSR_RECV_DONE_MASK 0x00000001 /* Rx complete */
-#define XEL_RSR_RECV_IE_MASK 0x00000008 /* Rx interrupt enable bit */
+#define XEL_RSR_RECV_DONE_MASK 0x00000001 /* Rx complete */
+#define XEL_RSR_RECV_IE_MASK 0x00000008 /* Rx interrupt enable bit */
/* Transmit Packet Length Register (TPLR) */
-#define XEL_TPLR_LENGTH_MASK 0x0000FFFF /* Tx packet length */
+#define XEL_TPLR_LENGTH_MASK 0x0000FFFF /* Tx packet length */
/* Receive Packet Length Register (RPLR) */
-#define XEL_RPLR_LENGTH_MASK 0x0000FFFF /* Rx packet length */
+#define XEL_RPLR_LENGTH_MASK 0x0000FFFF /* Rx packet length */
-#define XEL_HEADER_OFFSET 12 /* Offset to length field */
-#define XEL_HEADER_SHIFT 16 /* Shift value for length */
+#define XEL_HEADER_OFFSET 12 /* Offset to length field */
+#define XEL_HEADER_SHIFT 16 /* Shift value for length */
/* General Ethernet Definitions */
-#define XEL_ARP_PACKET_SIZE 28 /* Max ARP packet size */
-#define XEL_HEADER_IP_LENGTH_OFFSET 16 /* IP Length Offset */
+#define XEL_ARP_PACKET_SIZE 28 /* Max ARP packet size */
+#define XEL_HEADER_IP_LENGTH_OFFSET 16 /* IP Length Offset */
--
1.8.2.3
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* [PATCH 1/2] net: emaclite: Not necessary to call devm_iounmap
From: Michal Simek @ 2013-09-12 7:05 UTC (permalink / raw)
To: netdev
Cc: Michal Simek, David S. Miller, Jens Renner, Libo Chen,
Greg Kroah-Hartman, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1393 bytes --]
devm_iounmap is called automatically.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/net/ethernet/xilinx/xilinx_emaclite.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
index 4c619ea..de39098 100644
--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
@@ -1075,14 +1075,9 @@ static int xemaclite_send(struct sk_buff *orig_skb, struct net_device *dev)
* This function un maps the IO region of the Emaclite device and frees the net
* device.
*/
-static void xemaclite_remove_ndev(struct net_device *ndev,
- struct platform_device *pdev)
+static void xemaclite_remove_ndev(struct net_device *ndev)
{
if (ndev) {
- struct net_local *lp = netdev_priv(ndev);
-
- if (lp->base_addr)
- devm_iounmap(&pdev->dev, lp->base_addr);
free_netdev(ndev);
}
}
@@ -1214,7 +1209,7 @@ static int xemaclite_of_probe(struct platform_device *ofdev)
return 0;
error:
- xemaclite_remove_ndev(ndev, ofdev);
+ xemaclite_remove_ndev(ndev);
return rc;
}
@@ -1248,7 +1243,7 @@ static int xemaclite_of_remove(struct platform_device *of_dev)
of_node_put(lp->phy_node);
lp->phy_node = NULL;
- xemaclite_remove_ndev(ndev, of_dev);
+ xemaclite_remove_ndev(ndev);
return 0;
}
--
1.8.2.3
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* Re: [PATCH net 1/1] r8169: enforce RX_MULTI_EN for the 8168f.
From: David Miller @ 2013-09-12 6:40 UTC (permalink / raw)
To: romieu; +Cc: dborkman, netdev, david, fredo, hayeswang
In-Reply-To: <20130911231543.GA29725@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu, 12 Sep 2013 01:15:43 +0200
> David Miller <davem@davemloft.net> :
> [...]
>> Francois, if you reply to this thread with your signoff, all will
>> be well and I will apply this.
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
>
> I slowly built an AMD IOMMU + 8168{e/f} problem report pattern but
> the picture got blurred:
> - Hayes has not heard of anything like this
> - the oracle suggests it could be an "AMD IOMMU + whatever" problem
> - "iommu=pt" seems quite effective (hardly surprizing :o/ )
>
> I still have a pile of iommu mailing-list messages to search through.
> Let aside the AMD-Vi error log message, I haven't done a thorough analysis.
>
> It's lame.
Understood. There were always IOMMU chips that sometimes prefetch one
cacheline too far (and thus potentially to the next page, which is
potentially unmapped) in certain circumstances. Maybe these settings
trigger that kind of thing.
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: sk_buff: memset(skb,0) after alloc in skb_clone
From: Govindarajulu Varadarajan @ 2013-09-12 6:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Govindarajulu Varadarajan, davem, netdev
In-Reply-To: <1378816832.26319.75.camel@edumazet-glaptop>
On Tue, 10 Sep 2013, Eric Dumazet wrote:
> On Tue, 2013-09-10 at 10:18 +0530, Govindarajulu Varadarajan wrote:
>> The following patch memset the skb to 0 after alloc. We do this in
>> __alloc_skb_head, __alloc_skb, build_skb. We are missing this in
>> skb_clone.
>>
>> The following call to __skb_clone in skb_clone does not copy all the
>> members of sk_buff. If we donot clear the skb to 0, we will have some
>> uninitialized members in new skb.
>
> Which ones exactly ?
>
> I would rather make sure all fields are properly copied.
>
> Your patch is incomplete, because it doesn't handle the fast clone case.
Sorry, my bad. Didnt check the __copy_skb_header completely.
thanks
//govind
^ permalink raw reply
* Re: [PATCH] net: tulip: remove deprecated IRQF_DISABLED
From: Grant Grundler @ 2013-09-12 6:05 UTC (permalink / raw)
To: Michael Opdenacker
Cc: Grant Grundler, open list:TULIP NETWORK DRI..., open list
In-Reply-To: <1378959624-4123-1-git-send-email-michael.opdenacker@free-electrons.com>
On Wed, Sep 11, 2013 at 9:20 PM, Michael Opdenacker
<michael.opdenacker@free-electrons.com> wrote:
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/dec/tulip/de4x5.c
>
> It's a NOOP since 2.6.35 and it will be removed one day.
yup - that was easy to confirm.
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Acked-by: Grant Grundler <grundler@parisc-linux.org>
thanks,
grant
> ---
> drivers/net/ethernet/dec/tulip/de4x5.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/dec/tulip/de4x5.c b/drivers/net/ethernet/dec/tulip/de4x5.c
> index 2db6c57..263b92c 100644
> --- a/drivers/net/ethernet/dec/tulip/de4x5.c
> +++ b/drivers/net/ethernet/dec/tulip/de4x5.c
> @@ -1321,7 +1321,7 @@ de4x5_open(struct net_device *dev)
> if (request_irq(dev->irq, de4x5_interrupt, IRQF_SHARED,
> lp->adapter_name, dev)) {
> printk("de4x5_open(): Requested IRQ%d is busy - attemping FAST/SHARE...", dev->irq);
> - if (request_irq(dev->irq, de4x5_interrupt, IRQF_DISABLED | IRQF_SHARED,
> + if (request_irq(dev->irq, de4x5_interrupt, IRQF_SHARED,
> lp->adapter_name, dev)) {
> printk("\n Cannot get IRQ- reconfigure your hardware.\n");
> disable_ast(dev);
> --
> 1.8.1.2
>
^ permalink raw reply
* [PATCH V2 20/52] net: fealnx: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-09-12 5:57 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Jingoo Han', 'Sergei Shtylyov'
In-Reply-To: <005e01ceaec2$23e32420$6ba96c60$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
Changes since v1:
- removed coding style fix.
drivers/net/ethernet/fealnx.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/fealnx.c b/drivers/net/ethernet/fealnx.c
index c706b7a..4b22a95 100644
--- a/drivers/net/ethernet/fealnx.c
+++ b/drivers/net/ethernet/fealnx.c
@@ -699,7 +699,6 @@ static void fealnx_remove_one(struct pci_dev *pdev)
pci_iounmap(pdev, np->mem);
free_netdev(dev);
pci_release_regions(pdev);
- pci_set_drvdata(pdev, NULL);
} else
printk(KERN_ERR "fealnx: remove for unknown device\n");
}
--
1.7.10.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox