* Re: [PATCH] net: allow shifted address in smsc911x
From: Mathieu Poirier @ 2011-03-29 21:17 UTC (permalink / raw)
To: David Miller; +Cc: steve.glendinning, netdev, lee.jones, patches, linus.walleij
In-Reply-To: <20110325.143103.25112180.davem@davemloft.net>
My first email bounced on the list, hence sending again.
Please see my comments below.
Thanks,
Mathieu.
On 25 March 2011 15:31, David Miller <davem@davemloft.net> wrote:
> From: mathieu.poirier@linaro.org
> Date: Fri, 25 Mar 2011 15:27:17 -0600
>
>> From: Alessandro Rubini <rubini@gnudd.com>
>>
>> At least one device I'm using needs address shifting to access
>> registers in the LAN9221 device (smsc911x driver). This patch
>> adds a shift parameter in platform_data. The feature must be
>> enabled at configuration time, because shifting by a pdata
>> parameter makes access slower in those devices where no shift is
>> needed (I tested one, it was 20% slower).
>>
>> If the platform data requests shifted access but the feature is
>> unavailable, the probe method complains to the console. Board
>> config files should set the configuration option when needed.
>>
>> Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
>> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> Implement this at run time, keying off of a boolean or similar
> in the platform data.
>
> Implement a set of ops, one to do a PIO read one to do a PIO write,
> and choose the set of ops appropriate for the device depending upon
> the setting found in the platform device.
>
I'm find with this approach but confused on the way to implement it.
I could add the shifted read/write functions in smsc911x.c and choose,
based on a boolean found in the 'smsc911x_platform_config' struct,
which will be used (the original or the shifted methods). The
drawback with this approach is the new shifted read/write methods are
polluting smsc911x.c, something I'm not so fond of. It might be
acceptable for one set of OPS but what if there is many more ?
A better approach would be to pass the read/write methods to the
smsc911x core using the 'smsc911x_platform_config' structure. That
way smsc911x.c is kept clean but we'd have to move 'struct
smsc911x_data' to smsc911x.h to implement the methods from the board
files, something I'm not about do to without some sort of consensus.
'smsc911x_tx_writefifo' and 'smsc911x_rx_readfifo' are also of concern
to me. I understand the usage of writesl/readsl but it introduces
more challenges. If we don't want to replace their usage by a while
loop as it is the case when SMSC911X_SWAP_FIFO and SMSC911X_USE_16BIT
are set, we will need to introduce rx_readfifo and rx_writefifo in the
OPS.
Enlightenment is required on the above.
Best regards,
Mathieu.
^ permalink raw reply
* Re: [PATCH] net: Handle gso packets in dev_forward_skb
From: Eric W. Biederman @ 2011-03-29 21:02 UTC (permalink / raw)
To: Daniel Lezcano; +Cc: Eric Dumazet, David Miller, netdev, greearb, arnd, kaber
In-Reply-To: <4D91D693.1070202@free.fr>
Daniel Lezcano <daniel.lezcano@free.fr> writes:
> On 03/28/2011 09:20 PM, Eric Dumazet wrote:
>> Le dimanche 27 mars 2011 à 18:09 -0700, David Miller a écrit :
>>> From: ebiederm@xmission.com (Eric W. Biederman)
>>> Date: Mon, 21 Mar 2011 15:00:56 -0700
>>>
>>>> Eric Dumazet<eric.dumazet@gmail.com> writes:
>>>>
>>>>> Hmm, did you follow http://patchwork.ozlabs.org/patch/86815/
>>>>> discussion ?
>>>> No. It seems I missed it, but I do have the same problem, and
>>>> essentially the same fix.
>>> Can someone work on getting this straightened out and resubmit the
>>> final patch so I can apply something?
>>>
>> Apparently Daniel is busy.
>
> Yes, sorry for the delay.
> I would like to fix it but I am not sure to understand the different solutions
> proposed.
>
> On 03/28/2011 09:20 PM, Eric Dumazet wrote:
>> Le dimanche 27 mars 2011 à 18:09 -0700, David Miller a écrit :
>>> From: ebiederm@xmission.com (Eric W. Biederman)
>>> Date: Mon, 21 Mar 2011 15:00:56 -0700
>>>
>>>> Eric Dumazet<eric.dumazet@gmail.com> writes:
>>>>
>>>>> Hmm, did you follow http://patchwork.ozlabs.org/patch/86815/
>>>>> discussion ?
>>>> No. It seems I missed it, but I do have the same problem, and
>>>> essentially the same fix.
>>> Can someone work on getting this straightened out and resubmit the
>>> final patch so I can apply something?
>>>
>> Apparently Daniel is busy.
>
> Yes, sorry for the delay.
> I would like to fix it, but my knowledge in limited on offloading.
>
> I did the following patch, it fixes the problem. If it looks good I can resend
> it in patch format:
It looks fine to me. I would resubmit it so that if anyone else has
complaints they will be jolted into looking at the patch again.
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Eric
>
> Index: net-2.6/net/core/dev.c
> ===================================================================
> --- net-2.6.orig/net/core/dev.c 2011-03-29 14:50:00.047646000 +0200
> +++ net-2.6/net/core/dev.c 2011-03-29 14:50:35.587646000 +0200
> @@ -1454,6 +1454,27 @@ static inline void net_timestamp_check(s
> __net_timestamp(skb);
> }
>
> +static inline bool is_skb_forwardable(struct net_device *dev,
> + struct sk_buff *skb)
> +{
> + unsigned int len;
> +
> + if (!(dev->flags & IFF_UP))
> + return false;
> +
> + len = dev->mtu + dev->hard_header_len + VLAN_HLEN;
> + if (skb->len <= len)
> + return true;
> +
> + /* if TSO is enabled, we don't care about the length as the packet
> + * could be forwarded without being segmented before
> + */
> + if (skb_is_gso(skb))
> + return true;
> +
> + return false;
> +}
> +
> /**
> * dev_forward_skb - loopback an skb to another netif
> *
> @@ -1477,8 +1498,7 @@ int dev_forward_skb(struct net_device *d
> skb_orphan(skb);
> nf_reset(skb);
>
> - if (unlikely(!(dev->flags & IFF_UP) ||
> - (skb->len > (dev->mtu + dev->hard_header_len +
> VLAN_HLEN)))) {
> + if (unlikely(!is_skb_forwardable(dev, skb))) {
> atomic_long_inc(&dev->rx_dropped);
> kfree_skb(skb);
> return NET_RX_DROP;
^ permalink raw reply
* ethtool physical identify vs netlink locking?
From: Stephen Hemminger @ 2011-03-29 20:52 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Right now if an administrator uses the ethtool function to identify network
interface, the netlink lock can be held indefinitely. In other words, doing
"ethtool -p eth1" will stop all other netlink activity. This is bad, imagine
the case of an operator doing that to find a NIC in a rack, and because of
the netlink lockout all routing daemon activity stops.
There are several possible solutions but most involve fixing all the device
drivers (24). Options:
1. Have device driver drop and reacquire rtnl() while blinking
2. Have ethtool core drop rtnl before calling device driver
3. Add per-device ethtool rtnl lock
#1 is the least disruption
#2 means additional locking maybe required for each device driver
#3 seems like excessive overhead.
Comments?
^ permalink raw reply
* Re: [PATCH] net: gre: provide multicast mappings for ipv4 and ipv6
From: Doug Kehn @ 2011-03-29 20:26 UTC (permalink / raw)
To: netdev, Timo Teräs; +Cc: Timo Teräs
In-Reply-To: <1301388053-6083-1-git-send-email-timo.teras@iki.fi>
--- On Tue, 3/29/11, Timo Teräs <timo.teras@iki.fi> wrote:
> From: Timo Teräs <timo.teras@iki.fi>
> Subject: [PATCH] net: gre: provide multicast mappings for ipv4 and ipv6
> To: netdev@vger.kernel.org
> Cc: "Doug Kehn" <rdkehn@yahoo.com>, "Timo Teräs" <timo.teras@iki.fi>
> Date: Tuesday, March 29, 2011, 4:40 AM
> My commit 6d55cb91a0020ac0 (gre: fix
> hard header destination
> address checking) broke multicast.
>
> The reason is that ip_gre used to get ipgre_header() calls
> with
> zero destination if we have NOARP or multicast destination.
> Instead
> the actual target was decided at ipgre_tunnel_xmit() time
> based on
> per-protocol dissection.
>
> Instead of allowing the "abuse" of ->header() calls with
> invalid
> destination, this creates multicast mappings for ip_gre.
> This also
> fixes "ip neigh show nud noarp" to display the proper
> multicast
> mappings used by the gre device.
>
> Reported-by: Doug Kehn <rdkehn@yahoo.com>
> Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Acked-by: Doug Kehn <rdkehn@yahoo.com>
> ---
> Compile tested only. Doug tested IPv4 side with the earlier
> patch.
This patch set [still] works with IPv4.
>
> The IPv6 side needs a review. I'm not sure if mapped IPv4
> multicast
> addresses are intrepreted as multicast addresses by ndisc
> code or
> if we could map real IPv6 multicast addresses to IPv4
> multicast
> addresses.
>
> include/net/if_inet6.h | 16
> ++++++++++++++++
> include/net/ip.h |
> 8 ++++++++
> net/ipv4/arp.c
> | 3 +++
> net/ipv6/ndisc.c |
> 2 ++
> 4 files changed, 29 insertions(+), 0 deletions(-)
>
> diff --git a/include/net/if_inet6.h
> b/include/net/if_inet6.h
> index 04977ee..fccc218 100644
> --- a/include/net/if_inet6.h
> +++ b/include/net/if_inet6.h
> @@ -286,5 +286,21 @@ static inline void
> ipv6_ib_mc_map(const struct in6_addr *addr,
> buf[9] = broadcast[9];
> memcpy(buf + 10, addr->s6_addr + 6,
> 10);
> }
> +
> +static inline int ipv6_ipgre_mc_map(const struct in6_addr
> *addr,
> +
> const unsigned char
> *broadcast, char *buf)
> +{
> + if ((broadcast[0] | broadcast[1] |
> broadcast[2] | broadcast[3]) != 0) {
> + memcpy(buf,
> broadcast, 4);
> + } else {
> + /* v4mapped? */
> + if
> ((addr->s6_addr32[0] | addr->s6_addr32[1] |
> +
> (addr->s6_addr32[2] ^
> htonl(0x0000ffff))) != 0)
> +
> return -EINVAL;
> + memcpy(buf,
> &addr->s6_addr32[3], 4);
> + }
> + return 0;
> +}
> +
> #endif
> #endif
> diff --git a/include/net/ip.h b/include/net/ip.h
> index a4f6311..7c41658 100644
> --- a/include/net/ip.h
> +++ b/include/net/ip.h
> @@ -339,6 +339,14 @@ static inline void ip_ib_mc_map(__be32
> naddr, const unsigned char *broadcast, ch
> buf[16] = addr & 0x0f;
> }
>
> +static inline void ip_ipgre_mc_map(__be32 naddr, const
> unsigned char *broadcast, char *buf)
> +{
> + if ((broadcast[0] | broadcast[1] |
> broadcast[2] | broadcast[3]) != 0)
> + memcpy(buf,
> broadcast, 4);
> + else
> + memcpy(buf,
> &naddr, sizeof(naddr));
> +}
> +
> #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> #include <linux/ipv6.h>
> #endif
> diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
> index 090d273..1b74d3b 100644
> --- a/net/ipv4/arp.c
> +++ b/net/ipv4/arp.c
> @@ -215,6 +215,9 @@ int arp_mc_map(__be32 addr, u8 *haddr,
> struct net_device *dev, int dir)
> case ARPHRD_INFINIBAND:
> ip_ib_mc_map(addr,
> dev->broadcast, haddr);
> return 0;
> + case ARPHRD_IPGRE:
> +
> ip_ipgre_mc_map(addr, dev->broadcast, haddr);
> + return 0;
> default:
> if (dir) {
>
> memcpy(haddr, dev->broadcast, dev->addr_len);
> diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
> index 0e49c9d..92f952d 100644
> --- a/net/ipv6/ndisc.c
> +++ b/net/ipv6/ndisc.c
> @@ -341,6 +341,8 @@ int ndisc_mc_map(struct in6_addr *addr,
> char *buf, struct net_device *dev, int d
> case ARPHRD_INFINIBAND:
> ipv6_ib_mc_map(addr,
> dev->broadcast, buf);
> return 0;
> + case ARPHRD_IPGRE:
> + return
> ipv6_ipgre_mc_map(addr, dev->broadcast, buf);
> default:
> if (dir) {
>
> memcpy(buf, dev->broadcast, dev->addr_len);
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 0/9 net-next-2.6] qlcnic: Cleanup and fixes
From: Anirban Chakraborty @ 2011-03-29 20:05 UTC (permalink / raw)
To: Anirban Chakraborty
Cc: David Miller, netdev@vger.kernel.org, Dept_NX_Linux_NIC_Driver
In-Reply-To: <alpine.OSX.2.00.1103291121130.28263@macintosh-2.qlogic.org>
On Mar 29, 2011, at 11:45 AM, Anirban Chakraborty wrote:
> Please apply the series to net-next-2.6.
>
> Thanks,
> Anirban
Please disregard this patch series as some of the patches do not have my sign-offs. I am resending the patch series. Apology for the noise.
thanks,
Anirban
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
^ permalink raw reply
* Re: poll broken (for can)
From: Oliver Hartkopp @ 2011-03-29 20:03 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w, Wolfgang Grandegger
In-Reply-To: <4D90E262.1090201-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 28.03.2011 21:32, Marc Kleine-Budde wrote:
> On 03/28/2011 07:53 PM, Oliver Hartkopp wrote:
>> On 28.03.2011 18:13, Marc Kleine-Budde wrote:
>>> On 03/28/2011 05:55 PM, Wolfgang Grandegger wrote:
>>>>> BTW: I figured out why poll() wakes you up but the next write will fail
>>>>> with -ENOBUFS again.
>>>>
>>>> Ah, I'm curious? I also did realize that poll does burn CPU cycles
>>>> (instead of waiting).
>>>
>>> The poll callback checks if the used memory is less than the half of per
>>> socket snd buffer (IIRC ~60K). See:
>>>
>>> datagram_poll (http://lxr.linux.no/linux+v2.6.38/net/core/datagram.c#L737)
>>> sock_writeable (http://lxr.linux.no/linux+v2.6.38/include/net/sock.h#L1618)
>>>
>>> Because the size of a can frame (+the skb overhead) is much less then
>>> the ethernet frame (+overhead) the default value for the snd buffer is
>>> too big for can.
>>>
>>> We get the -ENOBUF from write() if the tx_queue_len (default 10) is
>>> exceeded.
>>>
>>> http://lxr.linux.no/linux+v2.6.38/drivers/net/can/dev.c#L435
>>> http://lxr.linux.no/linux+v2.6.38/net/can/af_can.c#L268
>>>
>>
>> What would be your suggestion? Decreasing the socket send buffer for CAN by
>> default?
>
> I haven't done any testing.....As far as I understand the code, we can
> a) increase the default tx_queue_len and/or
> b) decrease the default snd buffer size.
>
> Note: a) is a per device setting whereas b) is a per socket setting.
>
> With the current settings the -ENOBUF is triggered if we have X unsend
> can frames (per device) where X equals the tx_queue_len. This means
> using 5 applications, it about 2 queued (i.e. unsent) frames per app and
> device.
>
> If we increase the tx_queue_len to a high value (via ifconfig), so that
> the snd buffer is fully used, before the tx_queue_len is exceeded the
> write system call will block, (or return -EAGAIN of opened non
> blocking). At least the last time I've done this.
>
> I think solution b) would lead to a similar behavioural change.
>
> What do we really want to specify?
Hm - the problem could be that people expect their frames to be sent 'in
time', so if we increase the tx_queue_len, it's not transparent when the
frames are potentially leaving the system - and if the application data is
already out-dated when hitting the medium.
What about having up to three CAN frames in each CAN_RAW socket send buffer
and e.g.50 frames in the tx_queue_len of the netdevice as a starting point?
>
> Something like: queue up to X frames per socket and queue only Y frames
> per device. Where Y = X * n and n is "I don't know yet"?
>
> Y is simple, it's the tx_queue_len. But X is more complicated. The can
> frames have non constant length (i.e. dlc) and I'm not sure that the
> netdev people say if we misuse the sock_alloc_send_pskb() for our
> tx-flow-control :)
I would propose to count the CAN frames independently from the can_dlc. AFAIK
the tx_queue_len is dealing with skb's - and the skb->len for the socket send
buffer is also size of struct can_frame, right?
Regards,
Oliver
^ permalink raw reply
* Re: SAE J1939: update
From: Oliver Hartkopp @ 2011-03-29 19:41 UTC (permalink / raw)
To: Kurt Van Dijck; +Cc: socketcan-core, netdev
In-Reply-To: <20110329142907.GB335@kurt.e-circ.dyndns.org>
On 29.03.2011 16:29, Kurt Van Dijck wrote:
> Oliver,
>
> Some progress:
>
> I dropped the state-machine for the address claiming. This makes it less
> confusing I hope.
Thanks.
> I dropped SO_J1939_DEST_MASK. This could be done in userspace by
> accessing a procfs file, or additional rtnetlink ...
> Lookup up remote ecu's is not strictly necessary in kernel.
> I have no idea yet how such library would look like.
I'll check that with my colleague Urs, who knows very good, which concepts and
'mechanics' are commonly used for such kind of requirements.
> Can userspace tools be attached to the socketCAN subversion can-utils, or
> would a seperate dir be necessary?
I assume about 3-4 tools (like an AC-daemon, some dump or sniffer tool and a
library with some header file) to emerge in can-utils then, which should be
ok. There could also be some test-programms or src-samples that could be
placed in trunk/test .
> I'd say 'suggestions are welcome' but I know you'd suggest to remove
> address claiming..
I'm really very interested in having the address claiming - just somewhere in
userspace :-)
But of course it might become an ambitious target to support the address
claiming with an appropriate infrastructure to help users to fulfill their
needs without getting confused.
Thanks & best regards,
Oliver
^ permalink raw reply
* [PATCH] Bridge: Removed unwanted check and improper usage of bridge locks
From: Sasikanth V @ 2011-03-29 18:24 UTC (permalink / raw)
To: shemminger; +Cc: netdev, bridge, Sasikanth V
Signed-off-by: Sasikanth V <sasikanth.v19@gmail.com>
---
net/bridge/br_device.c | 5 ++++-
net/bridge/br_stp_if.c | 2 --
net/bridge/br_stp_timer.c | 3 ---
3 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index 21e5901..6cc612b 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -80,10 +80,13 @@ static int br_dev_open(struct net_device *dev)
netif_carrier_off(dev);
- br_features_recompute(br);
netif_start_queue(dev);
+
+ spin_lock_bh(&br->lock);
+ br_features_recompute(br);
br_stp_enable_bridge(br);
br_multicast_open(br);
+ spin_unlock_bh(&br->lock);
return 0;
}
diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c
index 5593f5a..472d8b2 100644
--- a/net/bridge/br_stp_if.c
+++ b/net/bridge/br_stp_if.c
@@ -44,7 +44,6 @@ void br_stp_enable_bridge(struct net_bridge *br)
{
struct net_bridge_port *p;
- spin_lock_bh(&br->lock);
mod_timer(&br->hello_timer, jiffies + br->hello_time);
mod_timer(&br->gc_timer, jiffies + HZ/10);
@@ -55,7 +54,6 @@ void br_stp_enable_bridge(struct net_bridge *br)
br_stp_enable_port(p);
}
- spin_unlock_bh(&br->lock);
}
/* NO locks held */
diff --git a/net/bridge/br_stp_timer.c b/net/bridge/br_stp_timer.c
index 3e96514..18244b2 100644
--- a/net/bridge/br_stp_timer.c
+++ b/net/bridge/br_stp_timer.c
@@ -65,8 +65,6 @@ static void br_message_age_timer_expired(unsigned long arg)
* check is redundant. I'm leaving it in for now, though.
*/
spin_lock(&br->lock);
- if (p->state == BR_STATE_DISABLED)
- goto unlock;
was_root = br_is_root_bridge(br);
br_become_designated_port(p);
@@ -74,7 +72,6 @@ static void br_message_age_timer_expired(unsigned long arg)
br_port_state_selection(br);
if (br_is_root_bridge(br) && !was_root)
br_become_root_bridge(br);
- unlock:
spin_unlock(&br->lock);
}
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] bridge: Fix compilation warning in function br_stp_recalculate_bridge_id()
From: Stephen Hemminger @ 2011-03-29 18:10 UTC (permalink / raw)
To: G.Balaji; +Cc: shemminger, bridge, netdev
In-Reply-To: <1301415604-3871-1-git-send-email-balajig81@gmail.com>
On Tue, 29 Mar 2011 21:50:04 +0530
"G.Balaji" <balajig81@gmail.com> wrote:
> net/bridge/br_stp_if.c: In function ‘br_stp_recalculate_bridge_id’:
> net/bridge/br_stp_if.c:216:3: warning: ‘return’ with no value, in function returning non-void
>
> Signed-off-by: G.Balaji <balajig81@gmail.com>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
(Forget to refresh quilt patch before sending).
^ permalink raw reply
* Re: [PATCH v2] ROSE: prevent heap corruption with bad facilities
From: Ralf Baechle @ 2011-03-29 16:26 UTC (permalink / raw)
To: Ben Hutchings; +Cc: drosenberg, netdev, security, David Miller
In-Reply-To: <1301361379.26693.742.camel@localhost>
On Tue, Mar 29, 2011 at 02:16:19AM +0100, Ben Hutchings wrote:
> On Sun, 2011-03-27 at 17:59 -0700, David Miller wrote:
> > From: Ben Hutchings <ben@decadent.org.uk>
> > Date: Sun, 20 Mar 2011 16:48:05 +0000
> >
> > > Subject: [PATCH] rose: Add length checks to CALL_REQUEST parsing
> > >
> > > Define some constant offsets for CALL_REQUEST based on the description
> > > at <http://www.techfest.com/networking/wan/x25plp.htm> and the
> > > definition of ROSE as using 10-digit (5-byte) addresses. Use them
> > > consistently. Validate all implicit and explicit facilities lengths.
> > > Validate the address length byte rather than either trusting or
> > > assuming its value.
> > >
> > > Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> >
> > Applied.
>
> Ralf, I would really appreciate it if you could test this soon...
Actual testing is a problem atm. But I've reviewed the patche and it appears
ok.
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Ralf
^ permalink raw reply
* [PATCH] bridge: Fix compilation warning in function br_stp_recalculate_bridge_id()
From: G.Balaji @ 2011-03-29 16:20 UTC (permalink / raw)
To: shemminger; +Cc: bridge, netdev, G.Balaji
net/bridge/br_stp_if.c: In function ‘br_stp_recalculate_bridge_id’:
net/bridge/br_stp_if.c:216:3: warning: ‘return’ with no value, in function returning non-void
Signed-off-by: G.Balaji <balajig81@gmail.com>
---
net/bridge/br_stp_if.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c
index 5593f5a..9b61d09 100644
--- a/net/bridge/br_stp_if.c
+++ b/net/bridge/br_stp_if.c
@@ -213,7 +213,7 @@ bool br_stp_recalculate_bridge_id(struct net_bridge *br)
/* user has chosen a value so keep it */
if (br->flags & BR_SET_MAC_ADDR)
- return;
+ return false;
list_for_each_entry(p, &br->port_list, list) {
if (addr == br_mac_zero ||
--
1.7.4
^ permalink raw reply related
* Re: [PATCH] Bridge allows the userspace to configure the bridge parameters with values not defined in the IEEE 802.1D std
From: Sasikanth V @ 2011-03-29 15:36 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, bridge
In-Reply-To: <AANLkTim=futKP0Opnedc10zH83r=WYEhaSUHCtf+qbw3@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1068 bytes --]
On Sun, Mar 27, 2011 at 12:01 AM, Sasikanth V <sasikanth.v19@gmail.com>wrote:
>
>
> On Sat, Mar 26, 2011 at 9:25 PM, Stephen Hemminger <
> shemminger@linux-foundation.org> wrote:
>
>> On Sat, 26 Mar 2011 20:19:57 +0530
>> Sasikanth V <sasikanth.v19@gmail.com> wrote:
>>
>> >
>> > Signed-off-by: Sasikanth V <sasikanth.v19@gmail.com>
>> > ---
>>
>> I will clean this up. There are things like introducing
>> global function names (set_forward_delay, etc) that need
>> to be fixed.
>>
>
> Thanks for looking at the patch. I made 5 set functions
> (set_forward_delay, set_max_age,
> set_hello_time, set_priority and set_ageing_time) in br_sysfs_br.c
> global to use in br_ioctl.c to
> avoid code duplication (but it looks it is not a good idea).
>
> Now i thought something like making those 5 functions static inline and
> moving it to br_private.h.
> If this is fine , I will resend the patch
>
>
>
> Since I am new to patch states and workflow. Can you guys please let me,
what I have to do when the
patch state is in Awaiting Stream.
Thanks
[-- Attachment #1.2: Type: text/html, Size: 1911 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Bridge mailing list
Bridge@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/bridge
^ permalink raw reply
* Re: ping when network down BUG: unable to handle kernel NULL pointer dereference at 000000000000001b
From: Eric Dumazet @ 2011-03-29 14:59 UTC (permalink / raw)
To: Jeff Chua; +Cc: lkml, Network Development
In-Reply-To: <AANLkTinthHDRYpfNrXSiOz9t_y5HyVMpjP-dLm_bn0es@mail.gmail.com>
Le mardi 29 mars 2011 à 22:54 +0800, Jeff Chua a écrit :
> I don't know when this started happening as my network was always up.
> Just down, I shutdown my network, and ping a known host and
> encountered this BUG.
>
> # ifconfig eth0 down
> # ping knowngoodhost
>
> Pid: 2144, comm: ping Not tainted 2.6.38 #34 LENOVO 5413FGA/5413FGA
> RIP: 0010:[<ffffffff81421047>] [<ffffffff81421047>] dst_release+0x11/0x57
> RSP: 0018:ffff880231975c28 EFLAGS: 00010286
> RAX: ffffffffffffff9b RBX: ffffffffffffff9b RCX: 00000000fffffffd
> RDX: 0000000000000000 RSI: 00000000000000fd RDI: ffffffffffffff9b
> RBP: 00000000ffffffff R08: ffff880231975bc8 R09: ffff88023bd8e1c8
> R10: 0000000000000001 R11: ffff880231975a08 R12: 0000000000000040
> R13: 00000000bcc8a19b R14: 00000000ffffff9b R15: 0000000000000000
> FS: 00007fa75ba60700(0000) GS:ffff88023bc00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000000000000001b CR3: 000000022f886000 CR4: 00000000000006f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process ping (pid: 2144, threadinfo ffff880231974000, task ffff8802330e2d00)
> Stack:
> ffff880231889b00 ffff880231889b00 ffff880231975ee8 ffffffff81464f97
> ffffffff0100007f 0000000000000202 ffffffff818385b0 0000000000000002
> 0000000000000000 0401000000000000 bcc8a19b00000000 0000000800000000
> Call Trace:
> [<ffffffff81464f97>] ? raw_sendmsg+0x66c/0x6c1
> [<ffffffff8140b0be>] ? sock_sendmsg+0xab/0xc3
> [<ffffffff8109cf03>] ? alloc_pages_vma+0x150/0x1fa
> [<ffffffff8104bde6>] ? up+0xe/0x36
> [<ffffffff81032cd8>] ? console_unlock+0x160/0x187
> [<ffffffff8104bde6>] ? up+0xe/0x36
> [<ffffffff810484b0>] ? remove_wait_queue+0x11/0x4a
> [<ffffffff8140b12d>] ? sockfd_lookup_light+0x1a/0x52
> [<ffffffff8140ab12>] ? move_addr_to_kernel+0x26/0x37
> [<ffffffff8140b7e7>] ? sys_sendto+0x114/0x148
> [<ffffffff8103d5e1>] ? do_sigaction+0x160/0x178
> [<ffffffff814b7d12>] ? system_call_fastpath+0x16/0x1b
> Code: 00 48 c7 c7 70 4c 72 81 e8 41 37 c2 ff 48 c7 c7 50 4c 72 81 5b
> e9 90 60 09 00 55 53 48 89 fb 48 83 ec 08 48 85 ff 74 45 83 cd ff <f0>
> 0f c1 af 80 00 00 00 ff cd 79 11 be 16 01 00 00 48 c7 c7 84
> RIP [<ffffffff81421047>] dst_release+0x11/0x57
> RSP <ffff880231975c28>
> CR2: 000000000000001b
> ---[ end trace 4b75e8b1559e0b81 ]---
> --
Hello Jeff.
Known problem, should be fixed by
http://git2.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=4910ac6c526d2868adcb5893e0c428473de862b5
Thanks
^ permalink raw reply
* ping when network down BUG: unable to handle kernel NULL pointer dereference at 000000000000001b
From: Jeff Chua @ 2011-03-29 14:54 UTC (permalink / raw)
To: lkml, Network Development
I don't know when this started happening as my network was always up.
Just down, I shutdown my network, and ping a known host and
encountered this BUG.
# ifconfig eth0 down
# ping knowngoodhost
Pid: 2144, comm: ping Not tainted 2.6.38 #34 LENOVO 5413FGA/5413FGA
RIP: 0010:[<ffffffff81421047>] [<ffffffff81421047>] dst_release+0x11/0x57
RSP: 0018:ffff880231975c28 EFLAGS: 00010286
RAX: ffffffffffffff9b RBX: ffffffffffffff9b RCX: 00000000fffffffd
RDX: 0000000000000000 RSI: 00000000000000fd RDI: ffffffffffffff9b
RBP: 00000000ffffffff R08: ffff880231975bc8 R09: ffff88023bd8e1c8
R10: 0000000000000001 R11: ffff880231975a08 R12: 0000000000000040
R13: 00000000bcc8a19b R14: 00000000ffffff9b R15: 0000000000000000
FS: 00007fa75ba60700(0000) GS:ffff88023bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000001b CR3: 000000022f886000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process ping (pid: 2144, threadinfo ffff880231974000, task ffff8802330e2d00)
Stack:
ffff880231889b00 ffff880231889b00 ffff880231975ee8 ffffffff81464f97
ffffffff0100007f 0000000000000202 ffffffff818385b0 0000000000000002
0000000000000000 0401000000000000 bcc8a19b00000000 0000000800000000
Call Trace:
[<ffffffff81464f97>] ? raw_sendmsg+0x66c/0x6c1
[<ffffffff8140b0be>] ? sock_sendmsg+0xab/0xc3
[<ffffffff8109cf03>] ? alloc_pages_vma+0x150/0x1fa
[<ffffffff8104bde6>] ? up+0xe/0x36
[<ffffffff81032cd8>] ? console_unlock+0x160/0x187
[<ffffffff8104bde6>] ? up+0xe/0x36
[<ffffffff810484b0>] ? remove_wait_queue+0x11/0x4a
[<ffffffff8140b12d>] ? sockfd_lookup_light+0x1a/0x52
[<ffffffff8140ab12>] ? move_addr_to_kernel+0x26/0x37
[<ffffffff8140b7e7>] ? sys_sendto+0x114/0x148
[<ffffffff8103d5e1>] ? do_sigaction+0x160/0x178
[<ffffffff814b7d12>] ? system_call_fastpath+0x16/0x1b
Code: 00 48 c7 c7 70 4c 72 81 e8 41 37 c2 ff 48 c7 c7 50 4c 72 81 5b
e9 90 60 09 00 55 53 48 89 fb 48 83 ec 08 48 85 ff 74 45 83 cd ff <f0>
0f c1 af 80 00 00 00 ff cd 79 11 be 16 01 00 00 48 c7 c7 84
RIP [<ffffffff81421047>] dst_release+0x11/0x57
RSP <ffff880231975c28>
CR2: 000000000000001b
---[ end trace 4b75e8b1559e0b81 ]---
^ permalink raw reply
* SAE J1939: update
From: Kurt Van Dijck @ 2011-03-29 14:29 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D8623BE.2080807-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
Oliver,
Some progress:
I dropped the state-machine for the address claiming. This makes it less
confusing I hope.
I dropped SO_J1939_DEST_MASK. This could be done in userspace by
accessing a procfs file, or additional rtnetlink ...
Lookup up remote ecu's is not strictly necessary in kernel.
I have no idea yet how such library would look like.
Can userspace tools be attached to the socketCAN subversion can-utils, or
would a seperate dir be necessary?
I'd say 'suggestions are welcome' but I know you'd suggest to remove
address claiming..
Kurt
^ permalink raw reply
* Re: zero copy for relay server
From: Eric Dumazet @ 2011-03-29 14:13 UTC (permalink / raw)
To: Changli Gao; +Cc: Viral Mehta, netdev@vger.kernel.org
In-Reply-To: <AANLkTi=GYxOP19HwdD0X33hX-Ku12oxwcX5=-okC9Let@mail.gmail.com>
Le mardi 29 mars 2011 à 19:28 +0800, Changli Gao a écrit :
> It is a waste of fd using pipe buffer with two fds. In fact, I had
> ever posted a patch, which extends pipe(2) to return a O_RDWR fd when
> NULL is passed in.
>
Oh well, one extra fd is less than 256 bytes.
Adding a syscall means you force users to have latest kernel.
All this is hypothetical, nobody gave performance numbers demonstrating
splice()/splice() is slow enough we have to optimize it and add kernel
bloat...
^ permalink raw reply
* Re: [PATCH net-next] net-ethtool: Allow ethtool to set interface in loopback mode.
From: Ben Hutchings @ 2011-03-29 13:54 UTC (permalink / raw)
To: Michał Mirosław
Cc: Mahesh Bandewar, David Miller, netdev, Tom Herbert
In-Reply-To: <20110329133941.GA15944@rere.qmqm.pl>
On Tue, 2011-03-29 at 15:39 +0200, Michał Mirosław wrote:
> On Tue, Mar 29, 2011 at 12:48:43AM +0100, Ben Hutchings wrote:
> > I'm sorry that things keep changing under your feet. Unfortunately I'm
> > going to have to ask for more changes; see below.
> >
> > I'm cc'ing Michał Mirosław so he can comment on how he thinks the
> > generic feature handling should be extended.
> >
> > On Mon, 2011-03-28 at 15:24 -0700, Mahesh Bandewar wrote:
> > > Add second word for feature (currently it's single word). Also use the first
> > > bit of the second word to set the loopback mode. By configuring the interface
> > > in loopback mode in conjunction with a policy route / rule, a user-land
> > > application can stress the egress / ingress path exposing the flows of the
> > > change in progress and potentially help developer(s) understand the impact of
> > > those changes without even sending a packet out on the network.
>
> For one, adding more feature words should be separate patch to the one
> introducing loopback mode.
>
> Unless I missed some patches, there's still one or two bits left in features
> you can use. This will be a lot less work for you.
[...]
I recommended Mahesh to use a second word for this flag because it is
not something the networking stack needs to be aware of.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
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
* Re: [PATCH net-next] net-ethtool: Allow ethtool to set interface in loopback mode.
From: Michał Mirosław @ 2011-03-29 13:39 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Mahesh Bandewar, David Miller, netdev, Tom Herbert
In-Reply-To: <1301356123.27727.41.camel@bwh-desktop>
On Tue, Mar 29, 2011 at 12:48:43AM +0100, Ben Hutchings wrote:
> I'm sorry that things keep changing under your feet. Unfortunately I'm
> going to have to ask for more changes; see below.
>
> I'm cc'ing Michał Mirosław so he can comment on how he thinks the
> generic feature handling should be extended.
>
> On Mon, 2011-03-28 at 15:24 -0700, Mahesh Bandewar wrote:
> > Add second word for feature (currently it's single word). Also use the first
> > bit of the second word to set the loopback mode. By configuring the interface
> > in loopback mode in conjunction with a policy route / rule, a user-land
> > application can stress the egress / ingress path exposing the flows of the
> > change in progress and potentially help developer(s) understand the impact of
> > those changes without even sending a packet out on the network.
For one, adding more feature words should be separate patch to the one
introducing loopback mode.
Unless I missed some patches, there's still one or two bits left in features
you can use. This will be a lot less work for you.
As Ben already commented on the visible parts of the patch, I'll only add
what's missing in it.
Extending feature words will need at least:
- adding new features word (making it an array will be a big patch unless
it's doable with preprocessor hackery)
- changing hw_features and wanted_features to arrays
- extending ndo_fix/set_features to handle arrays instead of one word
- updating bridge/vlan/bonding code to handle propagation of the extra words
(I'm waiting for merge window to close to resend patches touching this
for proper review)
- extending netdev_features_strings[] to 32x count of words (or functions
using it could be modified to handle missing entries at the end)
Best Regards,
Michał Mirosław
^ permalink raw reply
* [PATCH 3/3] igb: introduce igb_thermal_sensor_event for sensor checking
From: Stefan Assmann @ 2011-03-29 13:09 UTC (permalink / raw)
To: netdev; +Cc: e1000-devel, jeffrey.t.kirsher, alexander.h.duyck, sassmann
In-Reply-To: <1301404186-20872-1-git-send-email-sassmann@kpanic.de>
The code for thermal sensor checking should be wrapped into a function.
Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
---
drivers/net/igb/igb_main.c | 67 ++++++++++++++++++++++---------------------
1 files changed, 34 insertions(+), 33 deletions(-)
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index 3d850af..cea2f7f 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -3532,6 +3532,25 @@ bool igb_has_link(struct igb_adapter *adapter)
return link_active;
}
+static bool igb_thermal_sensor_event(struct e1000_hw *hw, u32 event)
+{
+ bool ret = false;
+ u32 ctrl_ext, thstat;
+
+ /* check for thermal sensor event on i350, copper only */
+ if (hw->mac.type == e1000_i350) {
+ thstat = rd32(E1000_THSTAT);
+ ctrl_ext = rd32(E1000_CTRL_EXT);
+
+ if ((hw->phy.media_type == e1000_media_type_copper) &&
+ !(ctrl_ext & E1000_CTRL_EXT_LINK_MODE_SGMII)) {
+ ret = !!(thstat & event);
+ }
+ }
+
+ return ret;
+}
+
/**
* igb_watchdog - Timer Call-back
* @data: pointer to adapter cast into an unsigned long
@@ -3550,7 +3569,7 @@ static void igb_watchdog_task(struct work_struct *work)
watchdog_task);
struct e1000_hw *hw = &adapter->hw;
struct net_device *netdev = adapter->netdev;
- u32 link, ctrl_ext, thstat;
+ u32 link;
int i;
link = igb_has_link(adapter);
@@ -3574,25 +3593,14 @@ static void igb_watchdog_task(struct work_struct *work)
((ctrl & E1000_CTRL_RFCE) ? "RX" :
((ctrl & E1000_CTRL_TFCE) ? "TX" : "None")));
- /* check for thermal sensor event on i350,
- * copper only */
- if (hw->mac.type == e1000_i350) {
- thstat = rd32(E1000_THSTAT);
- ctrl_ext = rd32(E1000_CTRL_EXT);
- if ((hw->phy.media_type ==
- e1000_media_type_copper) && !(ctrl_ext &
- E1000_CTRL_EXT_LINK_MODE_SGMII)) {
- if (thstat &
- E1000_THSTAT_LINK_THROTTLE) {
- printk(KERN_INFO "igb: %s The "
- "network adapter link "
- "speed was downshifted "
- "because it "
- "overheated.\n",
- netdev->name);
- }
- }
+ /* check for thermal sensor event */
+ if (igb_thermal_sensor_event(hw, E1000_THSTAT_LINK_THROTTLE)) {
+ printk(KERN_INFO "igb: %s The network adapter "
+ "link speed was downshifted "
+ "because it overheated.\n",
+ netdev->name);
}
+
/* adjust timeout factor according to speed/duplex */
adapter->tx_timeout_factor = 1;
switch (adapter->link_speed) {
@@ -3618,22 +3626,15 @@ static void igb_watchdog_task(struct work_struct *work)
if (netif_carrier_ok(netdev)) {
adapter->link_speed = 0;
adapter->link_duplex = 0;
- /* check for thermal sensor event on i350
- * copper only*/
- if (hw->mac.type == e1000_i350) {
- thstat = rd32(E1000_THSTAT);
- ctrl_ext = rd32(E1000_CTRL_EXT);
- if ((hw->phy.media_type ==
- e1000_media_type_copper) && !(ctrl_ext &
- E1000_CTRL_EXT_LINK_MODE_SGMII)) {
- if (thstat & E1000_THSTAT_PWR_DOWN) {
- printk(KERN_ERR "igb: %s The "
- "network adapter was stopped "
- "because it overheated.\n",
+
+ /* check for thermal sensor event */
+ if (igb_thermal_sensor_event(hw, E1000_THSTAT_PWR_DOWN)) {
+ printk(KERN_ERR "igb: %s The network adapter "
+ "was stopped because it "
+ "overheated.\n",
netdev->name);
- }
- }
}
+
/* Links status message must follow this format */
printk(KERN_INFO "igb: %s NIC Link is Down\n",
netdev->name);
--
1.7.4
^ permalink raw reply related
* [PATCH 2/3] igb: transform igb_{update,validate}_nvm_checksum into wrappers of their *_with_offset equivalents
From: Stefan Assmann @ 2011-03-29 13:09 UTC (permalink / raw)
To: netdev; +Cc: e1000-devel, jeffrey.t.kirsher, alexander.h.duyck, sassmann
In-Reply-To: <1301404186-20872-1-git-send-email-sassmann@kpanic.de>
igb_update_nvm_checksum_with_offset and igb_update_nvm_checksum are similar
except one additionally handles an offset.
Move igb_update_nvm_checksum_with_offset to e1000_nvm.c and transform
igb_update_nvm_checksum to a simple wrapper of
igb_update_nvm_checksum_with_offset.
Exactly the same is done for igb_validate_nvm_checksum.
Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
---
drivers/net/igb/e1000_82575.c | 76 +---------------------------------------
drivers/net/igb/e1000_nvm.c | 38 ++++++++++++++++----
drivers/net/igb/e1000_nvm.h | 2 +
3 files changed, 34 insertions(+), 82 deletions(-)
diff --git a/drivers/net/igb/e1000_82575.c b/drivers/net/igb/e1000_82575.c
index 0cd41c4..11f7519 100644
--- a/drivers/net/igb/e1000_82575.c
+++ b/drivers/net/igb/e1000_82575.c
@@ -66,12 +66,8 @@ static s32 igb_set_pcie_completion_timeout(struct e1000_hw *hw);
static s32 igb_reset_mdicnfg_82580(struct e1000_hw *hw);
static s32 igb_validate_nvm_checksum_82580(struct e1000_hw *hw);
static s32 igb_update_nvm_checksum_82580(struct e1000_hw *hw);
-static s32 igb_update_nvm_checksum_with_offset(struct e1000_hw *hw,
- u16 offset);
-static s32 igb_validate_nvm_checksum_with_offset(struct e1000_hw *hw,
- u16 offset);
-static s32 igb_validate_nvm_checksum_i350(struct e1000_hw *hw);
-static s32 igb_update_nvm_checksum_i350(struct e1000_hw *hw);
+static s32 igb_validate_nvm_checksum_i350(struct e1000_hw *hw);
+static s32 igb_update_nvm_checksum_i350(struct e1000_hw *hw);
static const u16 e1000_82580_rxpbs_table[] =
{ 36, 72, 144, 1, 2, 4, 8, 16,
35, 70, 140 };
@@ -1788,74 +1784,6 @@ u16 igb_rxpbs_adjust_82580(u32 data)
}
/**
- * igb_validate_nvm_checksum_with_offset - Validate EEPROM
- * checksum
- * @hw: pointer to the HW structure
- * @offset: offset in words of the checksum protected region
- *
- * Calculates the EEPROM checksum by reading/adding each word of the EEPROM
- * and then verifies that the sum of the EEPROM is equal to 0xBABA.
- **/
-s32 igb_validate_nvm_checksum_with_offset(struct e1000_hw *hw, u16 offset)
-{
- s32 ret_val = 0;
- u16 checksum = 0;
- u16 i, nvm_data;
-
- for (i = offset; i < ((NVM_CHECKSUM_REG + offset) + 1); i++) {
- ret_val = hw->nvm.ops.read(hw, i, 1, &nvm_data);
- if (ret_val) {
- hw_dbg("NVM Read Error\n");
- goto out;
- }
- checksum += nvm_data;
- }
-
- if (checksum != (u16) NVM_SUM) {
- hw_dbg("NVM Checksum Invalid\n");
- ret_val = -E1000_ERR_NVM;
- goto out;
- }
-
-out:
- return ret_val;
-}
-
-/**
- * igb_update_nvm_checksum_with_offset - Update EEPROM
- * checksum
- * @hw: pointer to the HW structure
- * @offset: offset in words of the checksum protected region
- *
- * Updates the EEPROM checksum by reading/adding each word of the EEPROM
- * up to the checksum. Then calculates the EEPROM checksum and writes the
- * value to the EEPROM.
- **/
-s32 igb_update_nvm_checksum_with_offset(struct e1000_hw *hw, u16 offset)
-{
- s32 ret_val;
- u16 checksum = 0;
- u16 i, nvm_data;
-
- for (i = offset; i < (NVM_CHECKSUM_REG + offset); i++) {
- ret_val = hw->nvm.ops.read(hw, i, 1, &nvm_data);
- if (ret_val) {
- hw_dbg("NVM Read Error while updating checksum.\n");
- goto out;
- }
- checksum += nvm_data;
- }
- checksum = (u16) NVM_SUM - checksum;
- ret_val = hw->nvm.ops.write(hw, (NVM_CHECKSUM_REG + offset), 1,
- &checksum);
- if (ret_val)
- hw_dbg("NVM Write Error while updating checksum.\n");
-
-out:
- return ret_val;
-}
-
-/**
* igb_validate_nvm_checksum_82580 - Validate EEPROM checksum
* @hw: pointer to the HW structure
*
diff --git a/drivers/net/igb/e1000_nvm.c b/drivers/net/igb/e1000_nvm.c
index 75bf36a..0f1ec3f 100644
--- a/drivers/net/igb/e1000_nvm.c
+++ b/drivers/net/igb/e1000_nvm.c
@@ -648,19 +648,21 @@ s32 igb_read_mac_addr(struct e1000_hw *hw)
}
/**
- * igb_validate_nvm_checksum - Validate EEPROM checksum
+ * igb_validate_nvm_checksum_with_offset - Validate EEPROM
+ * checksum
* @hw: pointer to the HW structure
+ * @offset: offset in words of the checksum protected region
*
* Calculates the EEPROM checksum by reading/adding each word of the EEPROM
* and then verifies that the sum of the EEPROM is equal to 0xBABA.
**/
-s32 igb_validate_nvm_checksum(struct e1000_hw *hw)
+s32 igb_validate_nvm_checksum_with_offset(struct e1000_hw *hw, u16 offset)
{
s32 ret_val = 0;
u16 checksum = 0;
u16 i, nvm_data;
- for (i = 0; i < (NVM_CHECKSUM_REG + 1); i++) {
+ for (i = offset; i < ((NVM_CHECKSUM_REG + offset) + 1); i++) {
ret_val = hw->nvm.ops.read(hw, i, 1, &nvm_data);
if (ret_val) {
hw_dbg("NVM Read Error\n");
@@ -680,20 +682,31 @@ out:
}
/**
- * igb_update_nvm_checksum - Update EEPROM checksum
+ * igb_validate_nvm_checksum - Validate EEPROM checksum
+ * @hw: pointer to the HW structure
+ **/
+s32 igb_validate_nvm_checksum(struct e1000_hw *hw)
+{
+ return igb_validate_nvm_checksum_with_offset(hw, 0);
+}
+
+/**
+ * igb_update_nvm_checksum_with_offset - Update EEPROM
+ * checksum
* @hw: pointer to the HW structure
+ * @offset: offset in words of the checksum protected region
*
* Updates the EEPROM checksum by reading/adding each word of the EEPROM
* up to the checksum. Then calculates the EEPROM checksum and writes the
* value to the EEPROM.
**/
-s32 igb_update_nvm_checksum(struct e1000_hw *hw)
+s32 igb_update_nvm_checksum_with_offset(struct e1000_hw *hw, u16 offset)
{
- s32 ret_val;
+ s32 ret_val;
u16 checksum = 0;
u16 i, nvm_data;
- for (i = 0; i < NVM_CHECKSUM_REG; i++) {
+ for (i = offset; i < (NVM_CHECKSUM_REG + offset); i++) {
ret_val = hw->nvm.ops.read(hw, i, 1, &nvm_data);
if (ret_val) {
hw_dbg("NVM Read Error while updating checksum.\n");
@@ -702,7 +715,8 @@ s32 igb_update_nvm_checksum(struct e1000_hw *hw)
checksum += nvm_data;
}
checksum = (u16) NVM_SUM - checksum;
- ret_val = hw->nvm.ops.write(hw, NVM_CHECKSUM_REG, 1, &checksum);
+ ret_val = hw->nvm.ops.write(hw, (NVM_CHECKSUM_REG + offset), 1,
+ &checksum);
if (ret_val)
hw_dbg("NVM Write Error while updating checksum.\n");
@@ -710,3 +724,11 @@ out:
return ret_val;
}
+/**
+ * igb_update_nvm_checksum - Update EEPROM checksum
+ * @hw: pointer to the HW structure
+ **/
+s32 igb_update_nvm_checksum(struct e1000_hw *hw)
+{
+ return igb_update_nvm_checksum_with_offset(hw, 0);
+}
diff --git a/drivers/net/igb/e1000_nvm.h b/drivers/net/igb/e1000_nvm.h
index 7f43564..b13b405 100644
--- a/drivers/net/igb/e1000_nvm.h
+++ b/drivers/net/igb/e1000_nvm.h
@@ -38,6 +38,8 @@ s32 igb_read_nvm_eerd(struct e1000_hw *hw, u16 offset, u16 words, u16 *data);
s32 igb_read_nvm_spi(struct e1000_hw *hw, u16 offset, u16 words, u16 *data);
s32 igb_write_nvm_spi(struct e1000_hw *hw, u16 offset, u16 words, u16 *data);
s32 igb_validate_nvm_checksum(struct e1000_hw *hw);
+s32 igb_validate_nvm_checksum_with_offset(struct e1000_hw *hw, u16 offset);
s32 igb_update_nvm_checksum(struct e1000_hw *hw);
+s32 igb_update_nvm_checksum_with_offset(struct e1000_hw *hw, u16 offset);
#endif
--
1.7.4
^ permalink raw reply related
* [PATCH 1/3] igb: fix typo in igb_validate_nvm_checksum_82580
From: Stefan Assmann @ 2011-03-29 13:09 UTC (permalink / raw)
To: netdev; +Cc: e1000-devel, jeffrey.t.kirsher, alexander.h.duyck, sassmann
In-Reply-To: <1301404186-20872-1-git-send-email-sassmann@kpanic.de>
Comment spelling fix.
Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
---
drivers/net/igb/e1000_82575.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/igb/e1000_82575.c b/drivers/net/igb/e1000_82575.c
index 6b256c2..0cd41c4 100644
--- a/drivers/net/igb/e1000_82575.c
+++ b/drivers/net/igb/e1000_82575.c
@@ -1877,7 +1877,7 @@ static s32 igb_validate_nvm_checksum_82580(struct e1000_hw *hw)
}
if (nvm_data & NVM_COMPATIBILITY_BIT_MASK) {
- /* if chekcsums compatibility bit is set validate checksums
+ /* if checksums compatibility bit is set validate checksums
* for all 4 ports. */
eeprom_regions_count = 4;
}
@@ -1988,6 +1988,7 @@ static s32 igb_update_nvm_checksum_i350(struct e1000_hw *hw)
out:
return ret_val;
}
+
/**
* igb_set_eee_i350 - Enable/disable EEE support
* @hw: pointer to the HW structure
--
1.7.4
^ permalink raw reply related
* [PATCH 0/3] igb: cleanup and code deduplication
From: Stefan Assmann @ 2011-03-29 13:09 UTC (permalink / raw)
To: netdev; +Cc: e1000-devel, jeffrey.t.kirsher, alexander.h.duyck, sassmann
Some cleanups for igb.
First patch is just a simple typo fix.
Second patch turns igb_update_nvm_checksum and igb_validate_nvm_checksum
into wrapper functions to deduplicate code.
Third patch puts the thermal sensor code into a function. This patch could use
some testing as I couldn't really test it due to lack of hardware.
Stefan
Stefan Assmann (3):
igb: fix typo in igb_validate_nvm_checksum_82580
igb: transform igb_{update,validate}_nvm_checksum into wrappers of
their *_with_offset equivalents
igb: introduce igb_thermal_sensor_event for sensor checking
drivers/net/igb/e1000_82575.c | 79 ++--------------------------------------
drivers/net/igb/e1000_nvm.c | 38 +++++++++++++++----
drivers/net/igb/e1000_nvm.h | 2 +
drivers/net/igb/igb_main.c | 67 +++++++++++++++++-----------------
4 files changed, 70 insertions(+), 116 deletions(-)
--
1.7.4
^ permalink raw reply
* Re: [PATCH] net: Handle gso packets in dev_forward_skb
From: Daniel Lezcano @ 2011-03-29 12:54 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, ebiederm, netdev, greearb, arnd, kaber
In-Reply-To: <1301340048.2506.13.camel@edumazet-laptop>
On 03/28/2011 09:20 PM, Eric Dumazet wrote:
> Le dimanche 27 mars 2011 à 18:09 -0700, David Miller a écrit :
>> From: ebiederm@xmission.com (Eric W. Biederman)
>> Date: Mon, 21 Mar 2011 15:00:56 -0700
>>
>>> Eric Dumazet<eric.dumazet@gmail.com> writes:
>>>
>>>> Hmm, did you follow http://patchwork.ozlabs.org/patch/86815/
>>>> discussion ?
>>> No. It seems I missed it, but I do have the same problem, and
>>> essentially the same fix.
>> Can someone work on getting this straightened out and resubmit the
>> final patch so I can apply something?
>>
> Apparently Daniel is busy.
Yes, sorry for the delay.
I would like to fix it but I am not sure to understand the different
solutions proposed.
On 03/28/2011 09:20 PM, Eric Dumazet wrote:
> Le dimanche 27 mars 2011 à 18:09 -0700, David Miller a écrit :
>> From: ebiederm@xmission.com (Eric W. Biederman)
>> Date: Mon, 21 Mar 2011 15:00:56 -0700
>>
>>> Eric Dumazet<eric.dumazet@gmail.com> writes:
>>>
>>>> Hmm, did you follow http://patchwork.ozlabs.org/patch/86815/
>>>> discussion ?
>>> No. It seems I missed it, but I do have the same problem, and
>>> essentially the same fix.
>> Can someone work on getting this straightened out and resubmit the
>> final patch so I can apply something?
>>
> Apparently Daniel is busy.
Yes, sorry for the delay.
I would like to fix it, but my knowledge in limited on offloading.
I did the following patch, it fixes the problem. If it looks good I can
resend it in patch format:
Index: net-2.6/net/core/dev.c
===================================================================
--- net-2.6.orig/net/core/dev.c 2011-03-29 14:50:00.047646000 +0200
+++ net-2.6/net/core/dev.c 2011-03-29 14:50:35.587646000 +0200
@@ -1454,6 +1454,27 @@ static inline void net_timestamp_check(s
__net_timestamp(skb);
}
+static inline bool is_skb_forwardable(struct net_device *dev,
+ struct sk_buff *skb)
+{
+ unsigned int len;
+
+ if (!(dev->flags & IFF_UP))
+ return false;
+
+ len = dev->mtu + dev->hard_header_len + VLAN_HLEN;
+ if (skb->len <= len)
+ return true;
+
+ /* if TSO is enabled, we don't care about the length as the packet
+ * could be forwarded without being segmented before
+ */
+ if (skb_is_gso(skb))
+ return true;
+
+ return false;
+}
+
/**
* dev_forward_skb - loopback an skb to another netif
*
@@ -1477,8 +1498,7 @@ int dev_forward_skb(struct net_device *d
skb_orphan(skb);
nf_reset(skb);
- if (unlikely(!(dev->flags & IFF_UP) ||
- (skb->len > (dev->mtu + dev->hard_header_len +
VLAN_HLEN)))) {
+ if (unlikely(!is_skb_forwardable(dev, skb))) {
atomic_long_inc(&dev->rx_dropped);
kfree_skb(skb);
return NET_RX_DROP;
^ permalink raw reply
* Re: zero copy for relay server
From: Changli Gao @ 2011-03-29 11:28 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Viral Mehta, netdev@vger.kernel.org
In-Reply-To: <1301372590.2506.57.camel@edumazet-laptop>
On Tue, Mar 29, 2011 at 12:23 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 29 mars 2011 à 10:00 +0800, Changli Gao a écrit :
>> On Tue, Mar 29, 2011 at 2:34 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> I think he concerns the overhead of system calls. In order to omit a
>> system call, I think you can implement sth. like this:
>>
>> splice2(infd, outfd, pipefd, ...)
>>
>
> Yes, but given no numbers are given, and no code yet written, I ask the
> question.
>
> Giving 4 file descriptors to a single syscall sounds convoluted.
>
It is a waste of fd using pipe buffer with two fds. In fact, I had
ever posted a patch, which extends pipe(2) to return a O_RDWR fd when
NULL is passed in.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH 2/2 v2] tg3: Don't use IRQF_SAMPLE_RANDOM
From: Javier Martinez Canillas @ 2011-03-29 11:26 UTC (permalink / raw)
To: David Miller; +Cc: bhutchings, eric.dumazet, error27, netdev, kernel-janitors
In-Reply-To: <20110328.165311.226778266.davem@davemloft.net>
On Tue, Mar 29, 2011 at 1:53 AM, David Miller <davem@davemloft.net> wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Mon, 28 Mar 2011 18:20:22 +0100
>
>> On Mon, 2011-03-28 at 17:46 +0200, Javier Martinez Canillas wrote:
>>> Yes this definitely is not janitor material :)
>>>
>>> I just sent the patch because I saw IRQF_SAMPLE_RANDOM in
>>> Documentation/feature-removal-schedule.txt. I can resend a patch
>>> removing the macro in the remaining network cards if the decision is
>>> to remove IRQF_SAMPLE_RANDOM.
>>
>> It's not my call, but I would support it.
>
> FWIW, I support it too.
>
Ok, I just sent a patch removing the IRQF_SAMPLE_RANDOM flag in all
the network drivers in the case everyone agrees.
Best regards,
-----------------------------------------
Javier Martínez Canillas
(+34) 682 39 81 69
PhD Student in High Performance Computing
Computer Architecture and Operating System Department (CAOS)
Universitat Autònoma de Barcelona
Barcelona, Spain
^ 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;
as well as URLs for NNTP newsgroup(s).