* Re: [PATCH 6/9] netdev: bfin_mac: add support for wake-on-lan magic packets
From: David Miller @ 2010-05-18 0:21 UTC (permalink / raw)
To: vapier; +Cc: netdev, uclinux-dist-devel, michael.hennerich
In-Reply-To: <1273505954-32588-6-git-send-email-vapier@gentoo.org>
From: Mike Frysinger <vapier@gentoo.org>
Date: Mon, 10 May 2010 11:39:11 -0400
> From: Michael Hennerich <michael.hennerich@analog.com>
>
> Note that WOL works only in PM Suspend Standby Mode (Sleep Mode).
>
> Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Applied.
^ permalink raw reply
* Re: [PATCH 4/9 v2] netdev: bfin_mac: deduce Ethernet FCS from hardware IP payload checksum
From: David Miller @ 2010-05-18 0:21 UTC (permalink / raw)
To: vapier-aBrp7R+bbdUdnm+yROfE0A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, jon.kowal-obo422lQt0aqq+TXWfNVuQ,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b
In-Reply-To: <1273505954-32588-4-git-send-email-vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
From: Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
Date: Mon, 10 May 2010 11:39:09 -0400
> From: Sonic Zhang <sonic.zhang-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
>
> IP checksum is based on 16-bit one's complement algorithm, so to deduce a
> value from checksum is equal to add its complement.
>
> Unfortunately, the Blackfin on-chip MAC checksum logic only works when the
> IP packet has a header length of 20 bytes. This is true for most IPv4
> packets, but not for IPv6 packets or IPv4 packets which use header options.
> So only use the hardware checksum when appropriate.
>
> Signed-off-by: Sonic Zhang <sonic.zhang-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Jon Kowal <jon.kowal-obo422lQt0aqq+TXWfNVuQ@public.gmane.org>
> Signed-off-by: Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH 5/9] netdev: bfin_mac: clear RXCKS if hardware generated checksum is not enabled
From: David Miller @ 2010-05-18 0:21 UTC (permalink / raw)
To: vapier; +Cc: netdev, uclinux-dist-devel, sonic.zhang
In-Reply-To: <1273505954-32588-5-git-send-email-vapier@gentoo.org>
From: Mike Frysinger <vapier@gentoo.org>
Date: Mon, 10 May 2010 11:39:10 -0400
> From: Sonic Zhang <sonic.zhang@analog.com>
>
> Otherwise we might be get a setting mismatch from a previous module or
> bootloader and what the driver currently expects.
>
> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Applied.
^ permalink raw reply
* Re: [PATCH 3/9] netdev: bfin_mac: invalid data cache only once for each new rx skb buffer
From: David Miller @ 2010-05-18 0:21 UTC (permalink / raw)
To: vapier; +Cc: netdev, uclinux-dist-devel, sonic.zhang
In-Reply-To: <1273505954-32588-3-git-send-email-vapier@gentoo.org>
From: Mike Frysinger <vapier@gentoo.org>
Date: Mon, 10 May 2010 11:39:08 -0400
> From: Sonic Zhang <sonic.zhang@analog.com>
>
> The skb buffer isn't actually used until we finish transferring and pass
> it up to higher layers, so only invalidate the range once before we start
> receiving actual data. This also avoids the problem with data invalidating
> on Blackfin systems -- there is no invalidate-only, just invalidate+flush.
> So when running in writeback mode, there is the small (but not uncommon)
> possibility of the flush overwriting valid DMA-ed data from the cache.
>
> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Applied.
^ permalink raw reply
* Re: [PATCH 2/9] netdev: bfin_mac: handler RX status errors
From: David Miller @ 2010-05-18 0:21 UTC (permalink / raw)
To: vapier; +Cc: netdev, uclinux-dist-devel, pmeerw, graf.yang
In-Reply-To: <1273505954-32588-2-git-send-email-vapier@gentoo.org>
From: Mike Frysinger <vapier@gentoo.org>
Date: Mon, 10 May 2010 11:39:07 -0400
> From: Peter Meerwald <pmeerw@pmeerw.net>
>
> Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
> Signed-off-by: Graf Yang <graf.yang@analog.com>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Applied.
^ permalink raw reply
* Re: [PATCH 1/9] netdev: bfin_mac: add support for IEEE 1588 PTP
From: David Miller @ 2010-05-18 0:21 UTC (permalink / raw)
To: vapier; +Cc: netdev, uclinux-dist-devel, barry.song
In-Reply-To: <1273505954-32588-1-git-send-email-vapier@gentoo.org>
From: Mike Frysinger <vapier@gentoo.org>
Date: Mon, 10 May 2010 11:39:06 -0400
> Newer on-chip MAC peripherals support IEEE 1588 PTP in the hardware, so
> extend the driver to support this functionality.
>
> Signed-off-by: Barry Song <barry.song@analog.com>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Applied.
^ permalink raw reply
* Re: [PATCH] drivers/net/usb/asix.c Fix unaligned access
From: David Miller @ 2010-05-18 0:18 UTC (permalink / raw)
To: neiljay; +Cc: netdev
In-Reply-To: <AANLkTiliFhlbe7HAOyn9O3935MkmEuRumLKYY7Ew4DXQ@mail.gmail.com>
From: Neil Jones <neiljay@gmail.com>
Date: Mon, 10 May 2010 17:06:01 +0100
> Using this driver can cause unaligned accesses in the IP layer
> This has been fixed by aligning the skb data correctly using the
> spare room left over by the 4 byte header inserted between packets
> by the device.
>
> Signed-off-by: Neil Jones <NeilJay@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/1] ibmveth: Add suspend/resume support
From: David Miller @ 2010-05-18 0:09 UTC (permalink / raw)
To: brking; +Cc: netdev
In-Reply-To: <201005071156.o47BuCYM007062@d03av03.boulder.ibm.com>
From: Brian King <brking@linux.vnet.ibm.com>
Date: Fri, 07 May 2010 13:56:08 -0500
>
> Adds support for resuming from suspend for IBM virtual ethernet devices.
> We may have lost an interrupt over the suspend, so we just kick the
> interrupt handler to process anything that is outstanding.
>
> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH 1/1] ipv6 addrlabel: permit deletion of labels assigned to removed dev
From: David Miller @ 2010-05-18 0:08 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <1273267893-22485-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Fri, 7 May 2010 23:31:33 +0200
> as addrlabels with an interface index are left alone when the
> interface gets removed this results in addrlabels that can no
> longer be removed.
>
> Restrict validation of index to adding new addrlabels.
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Applied, thanks Florian.
^ permalink raw reply
* Re: [PATCH 0/6] netns support in the kobject layer
From: David Miller @ 2010-05-17 23:48 UTC (permalink / raw)
To: gregkh
Cc: ebiederm, greg, kay.sievers, linux-kernel, tj, cornelia.huck,
eric.dumazet, bcrl, serue, netdev
In-Reply-To: <20100517210318.GA6170@suse.de>
From: Greg KH <gregkh@suse.de>
Date: Mon, 17 May 2010 14:03:18 -0700
> On Mon, May 17, 2010 at 01:58:44PM -0700, Eric W. Biederman wrote:
>> Greg KH <greg@kroah.com> writes:
>>
>> If I must I will resend these, but these patches are already in
>> production use, and I had them to you weeks before the merge window
>> closed.
>
> Yes, but they were not reviewed by the network maintainer until after
> the merge window closed. I already have your sysfs-namespace patches
> queued up for .35, and that's a big enough change for me to feel
> comfortable with at the moment.
Greg, this is complete bullshit. I reviewed them last week, they are fine
and have been around forever.
Merge them in now, making them wait until 2.6.36 is completely rediculious.
^ permalink raw reply
* Re: [PATCH 0/6] netns support in the kobject layer
From: Greg KH @ 2010-05-17 22:54 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Greg KH, David Miller, kay.sievers, linux-kernel, tj,
cornelia.huck, eric.dumazet, bcrl, serue, netdev
In-Reply-To: <m1hbm6f93x.fsf@fess.ebiederm.org>
On Mon, May 17, 2010 at 03:37:22PM -0700, Eric W. Biederman wrote:
> Greg KH <gregkh@suse.de> writes:
>
> > On Mon, May 17, 2010 at 01:58:44PM -0700, Eric W. Biederman wrote:
> >> Greg KH <greg@kroah.com> writes:
> >>
> >> > On Sat, May 15, 2010 at 11:26:43PM -0700, David Miller wrote:
> >> >> From: Greg KH <greg@kroah.com>
> >> >> Date: Thu, 6 May 2010 13:04:04 -0700
> >> >>
> >> >> > On Tue, May 04, 2010 at 05:35:54PM -0700, Eric W. Biederman wrote:
> >> >> >>
> >> >> >> With the tagged sysfs support finally merged into Greg's tree,
> >> >> >> it is time for the last little bits of work to get the kobject
> >> >> >> layer and network namespaces to play together properly.
> >> >> >>
> >> >> >> These patches are roughly evenly divided between network layer work
> >> >> >> and sysfs layer work. Last time this conundrum came up I believe
> >> >> >> we decided that the easiest way to handle this was for Greg to carry
> >> >> >> all of the patches. David, Greg does that still make sense?
> >> >> >
> >> >> > That's fine, if I get David's ack on these.
> >> >>
> >> >> Looks good to me:
> >> >>
> >> >> Acked-by: David S. Miller <davem@davemloft.net>
> >> >
> >> > Ok. Eric, can you resend these to me when .35-rc1 is out so I can queue
> >> > them up then to get some testing in linux-next so that they can make it
> >> > into .36?
> >>
> >> Grumble. Grumble. Grumble.
> >>
> >> If I must I will resend these, but these patches are already in
> >> production use, and I had them to you weeks before the merge window
> >> closed.
> >
> > Yes, but they were not reviewed by the network maintainer until after
> > the merge window closed.
>
> Strictly speaking the day before but I get your point.
>
> > I already have your sysfs-namespace patches
> > queued up for .35, and that's a big enough change for me to feel
> > comfortable with at the moment.
> >
> >> Is there no way we can get these in for 2.6.35?
> >
> > No, sorry. One thing at a time please.
>
> Sure.
>
> If we are going to push this last bit off until the 2.6.36 time frame
> Dave, Greg mind if I flip around who I send these patches to?
>
> The big dependency is the sysfs-namespace patches which will be in
> 2.6.35, and if the patches get into net-next as well as linux-next
> there will be a larger number of potential testers.
Sure, that's fine with me.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] net: Introduce skb_tunnel_rx() helper
From: Eric Dumazet @ 2010-05-17 22:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev
skb rxhash should be cleared when a skb is handled by a tunnel before
being delivered again, so that correct packet steering can take place.
There are other cleanups and accounting that we can factorize in a new
helper, skb_tunnel_rx()
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/net/dst.h | 20 ++++++++++++++++++++
net/ipv4/ip_gre.c | 9 +--------
net/ipv4/ipip.c | 7 ++-----
net/ipv4/ipmr.c | 8 +++-----
net/ipv6/ip6_tunnel.c | 8 ++------
net/ipv6/ip6mr.c | 8 +++-----
net/ipv6/sit.c | 8 +++-----
7 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/include/net/dst.h b/include/net/dst.h
index aac5a5f..d708c22 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -184,6 +184,26 @@ static inline void skb_dst_drop(struct sk_buff *skb)
skb->_skb_dst = 0UL;
}
+
+/**
+ * skb_tunnel_rx - prepare skb for rx reinsert
+ * @skb: buffer
+ * @dev: tunnel device
+ *
+ * After decapsulation, packet is going to re-enter (netif_rx()) our stack,
+ * so make some cleanups, and perform accounting.
+ */
+static inline void skb_tunnel_rx(struct sk_buff *skb, struct net_device *dev)
+{
+ skb->dev = dev;
+ /* TODO : stats should be SMP safe */
+ dev->stats.rx_packets++;
+ dev->stats.rx_bytes += skb->len;
+ skb->rxhash = 0;
+ skb_dst_drop(skb);
+ nf_reset(skb);
+}
+
/* Children define the path of the packet through the
* Linux networking. Thus, destinations are stackable.
*/
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index fe381d1..498cf69 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -538,7 +538,6 @@ static int ipgre_rcv(struct sk_buff *skb)
struct ip_tunnel *tunnel;
int offset = 4;
__be16 gre_proto;
- unsigned int len;
if (!pskb_may_pull(skb, 16))
goto drop_nolock;
@@ -629,8 +628,6 @@ static int ipgre_rcv(struct sk_buff *skb)
tunnel->i_seqno = seqno + 1;
}
- len = skb->len;
-
/* Warning: All skb pointers will be invalidated! */
if (tunnel->dev->type == ARPHRD_ETHER) {
if (!pskb_may_pull(skb, ETH_HLEN)) {
@@ -644,11 +641,7 @@ static int ipgre_rcv(struct sk_buff *skb)
skb_postpull_rcsum(skb, eth_hdr(skb), ETH_HLEN);
}
- stats->rx_packets++;
- stats->rx_bytes += len;
- skb->dev = tunnel->dev;
- skb_dst_drop(skb);
- nf_reset(skb);
+ skb_tunnel_rx(skb, tunnel->dev);
skb_reset_network_header(skb);
ipgre_ecn_decapsulate(iph, skb);
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index 0b27b14..7fd6367 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -374,11 +374,8 @@ static int ipip_rcv(struct sk_buff *skb)
skb->protocol = htons(ETH_P_IP);
skb->pkt_type = PACKET_HOST;
- tunnel->dev->stats.rx_packets++;
- tunnel->dev->stats.rx_bytes += skb->len;
- skb->dev = tunnel->dev;
- skb_dst_drop(skb);
- nf_reset(skb);
+ skb_tunnel_rx(skb, tunnel->dev);
+
ipip_ecn_decapsulate(iph, skb);
netif_rx(skb);
rcu_read_unlock();
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 7a7ee1c..217ebe0 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1831,14 +1831,12 @@ static int __pim_rcv(struct mr_table *mrt, struct sk_buff *skb,
skb->mac_header = skb->network_header;
skb_pull(skb, (u8*)encap - skb->data);
skb_reset_network_header(skb);
- skb->dev = reg_dev;
skb->protocol = htons(ETH_P_IP);
skb->ip_summed = 0;
skb->pkt_type = PACKET_HOST;
- skb_dst_drop(skb);
- reg_dev->stats.rx_bytes += skb->len;
- reg_dev->stats.rx_packets++;
- nf_reset(skb);
+
+ skb_tunnel_rx(skb, reg_dev);
+
netif_rx(skb);
dev_put(reg_dev);
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 2599870..8f39893 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -723,14 +723,10 @@ static int ip6_tnl_rcv(struct sk_buff *skb, __u16 protocol,
skb->protocol = htons(protocol);
skb->pkt_type = PACKET_HOST;
memset(skb->cb, 0, sizeof(struct inet6_skb_parm));
- skb->dev = t->dev;
- skb_dst_drop(skb);
- nf_reset(skb);
- dscp_ecn_decapsulate(t, ipv6h, skb);
+ skb_tunnel_rx(skb, t->dev);
- t->dev->stats.rx_packets++;
- t->dev->stats.rx_bytes += skb->len;
+ dscp_ecn_decapsulate(t, ipv6h, skb);
netif_rx(skb);
rcu_read_unlock();
return 0;
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 163850e..bd9e7d3 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -658,14 +658,12 @@ static int pim6_rcv(struct sk_buff *skb)
skb->mac_header = skb->network_header;
skb_pull(skb, (u8 *)encap - skb->data);
skb_reset_network_header(skb);
- skb->dev = reg_dev;
skb->protocol = htons(ETH_P_IPV6);
skb->ip_summed = 0;
skb->pkt_type = PACKET_HOST;
- skb_dst_drop(skb);
- reg_dev->stats.rx_bytes += skb->len;
- reg_dev->stats.rx_packets++;
- nf_reset(skb);
+
+ skb_tunnel_rx(skb, reg_dev);
+
netif_rx(skb);
dev_put(reg_dev);
return 0;
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 5abae10..e51e650 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -566,11 +566,9 @@ static int ipip6_rcv(struct sk_buff *skb)
kfree_skb(skb);
return 0;
}
- tunnel->dev->stats.rx_packets++;
- tunnel->dev->stats.rx_bytes += skb->len;
- skb->dev = tunnel->dev;
- skb_dst_drop(skb);
- nf_reset(skb);
+
+ skb_tunnel_rx(skb, tunnel->dev);
+
ipip6_ecn_decapsulate(iph, skb);
netif_rx(skb);
rcu_read_unlock();
^ permalink raw reply related
* Re: [PATCH 0/6] netns support in the kobject layer
From: Eric W. Biederman @ 2010-05-17 22:37 UTC (permalink / raw)
To: Greg KH
Cc: Greg KH, David Miller, kay.sievers, linux-kernel, tj,
cornelia.huck, eric.dumazet, bcrl, serue, netdev
In-Reply-To: <20100517210318.GA6170@suse.de>
Greg KH <gregkh@suse.de> writes:
> On Mon, May 17, 2010 at 01:58:44PM -0700, Eric W. Biederman wrote:
>> Greg KH <greg@kroah.com> writes:
>>
>> > On Sat, May 15, 2010 at 11:26:43PM -0700, David Miller wrote:
>> >> From: Greg KH <greg@kroah.com>
>> >> Date: Thu, 6 May 2010 13:04:04 -0700
>> >>
>> >> > On Tue, May 04, 2010 at 05:35:54PM -0700, Eric W. Biederman wrote:
>> >> >>
>> >> >> With the tagged sysfs support finally merged into Greg's tree,
>> >> >> it is time for the last little bits of work to get the kobject
>> >> >> layer and network namespaces to play together properly.
>> >> >>
>> >> >> These patches are roughly evenly divided between network layer work
>> >> >> and sysfs layer work. Last time this conundrum came up I believe
>> >> >> we decided that the easiest way to handle this was for Greg to carry
>> >> >> all of the patches. David, Greg does that still make sense?
>> >> >
>> >> > That's fine, if I get David's ack on these.
>> >>
>> >> Looks good to me:
>> >>
>> >> Acked-by: David S. Miller <davem@davemloft.net>
>> >
>> > Ok. Eric, can you resend these to me when .35-rc1 is out so I can queue
>> > them up then to get some testing in linux-next so that they can make it
>> > into .36?
>>
>> Grumble. Grumble. Grumble.
>>
>> If I must I will resend these, but these patches are already in
>> production use, and I had them to you weeks before the merge window
>> closed.
>
> Yes, but they were not reviewed by the network maintainer until after
> the merge window closed.
Strictly speaking the day before but I get your point.
> I already have your sysfs-namespace patches
> queued up for .35, and that's a big enough change for me to feel
> comfortable with at the moment.
>
>> Is there no way we can get these in for 2.6.35?
>
> No, sorry. One thing at a time please.
Sure.
If we are going to push this last bit off until the 2.6.36 time frame
Dave, Greg mind if I flip around who I send these patches to?
The big dependency is the sysfs-namespace patches which will be in
2.6.35, and if the patches get into net-next as well as linux-next
there will be a larger number of potential testers.
Eric
^ permalink raw reply
* Re: [patch] pm_qos update fixing mmotm 2010-05-11 -dies in pm_qos_update_request()
From: Rafael J. Wysocki @ 2010-05-17 21:58 UTC (permalink / raw)
To: markgross
Cc: mgross, Valdis.Kletnieks, e1000-devel, netdev, linux-kernel,
linux-pm, akpm, davem
In-Reply-To: <20100517001241.GA2962@thegnar.org>
On Monday 17 May 2010, mgross wrote:
> On Mon, May 17, 2010 at 12:21:25AM +0200, Rafael J. Wysocki wrote:
> > On Saturday 15 May 2010, mgross wrote:
> > > On Sat, May 15, 2010 at 09:38:47PM +0200, Rafael J. Wysocki wrote:
> > > > On Saturday 15 May 2010, mgross wrote:
> > > > > I apologize for the goofy email address.
> > > > >
> > > > > The following is a fix for the crash reported by Valdis.
> > > > >
> > > > > The problem was that the original pm_qos silently fails when a request
> > > > > update is passed to a parameter that has not been added to the list
> > > > > yet. It seems that the e1000e is doing this. This update restores this
> > > > > behavior.
> > > > >
> > > > > I need to think about how to better handle such abuse, but for now this
> > > > > restores the original behavior.
> > > >
> > > > Can you please post a signed-off incremental patch against
> > > >
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6.git for-llinus
> > > >
> > > > that contains your original PM QOS update?
> > >
> > > No problem:
> > >
> > > Signed-off-by: markgross <markgross@thegnar.org>
> >
> > Thanks! Do you want to use this address for the sign-off or the Intel one?
>
> I guess so. Ever since switching groups within intel last summer my
> mgross@linux.intel.com address isn't checked as often as this one.
>
> The other option is to use my outlook email (mark.gross@intel.com), but
> I really hate posting from outlook. Besides, doing upstream kernel
> stuff isn't my day job any more so using markgross@thegnar.org makes
> sense to me.
Good. Patch applied to suspend-2.6/for-linus.
Thanks,
Rafael
------------------------------------------------------------------------------
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: iproute2 issue with adding rules.
From: Stephen Hemminger @ 2010-05-17 21:41 UTC (permalink / raw)
To: Ben Greear; +Cc: Chris Wright, NetDev
In-Reply-To: <4BF1A855.3090905@candelatech.com>
On Mon, 17 May 2010 13:34:29 -0700
Ben Greear <greearb@candelatech.com> wrote:
> On 05/17/2010 01:30 PM, Chris Wright wrote:
> > * Ben Greear (greearb@candelatech.com) wrote:
> >> On 05/17/2010 01:13 PM, Ben Greear wrote:
> >>> On 05/17/2010 12:03 PM, Ben Greear wrote:
> >>>> On older releases, you can do this with iproute:
> >>>>
> >>>> # ip ru add from 9.9.9.2/32 table 226 pref 400
> >>>> #
> >>>>
> >>>> But, in latest git, it returns an error:
> >>>> # ip ru add from 9.9.9.2/32 table 226 pref 400
> >>>> Error: an inet prefix is expected rather than "9.9.9.2/32".
> >>>>
> >>>> Is that on purpose?
> >>>
> >>> I was thinking maybe this was a library issue, since I compiled
> >>> on one machine and ran the 'ip' exe on another. So, I tried compiling
> >>> on the test system.
> >>
> >> I'm not thinking too well today, but this patch fixes the compile.
> >> No idea if it's actually correct code.
> >
> > Needs more changes than that patch.
>
> Ok, I'll try going back a few commits to find something that compiles
> w/out my hacks.
>
> Also, the rule addition does work..make install put ip in
> a different place than it's installed in fedora, so I wasn't
> actually running the latest code when I first tried to add
> the rule.
Distributions never seem to agree where it should be: /sbin or /usr/sbin
or even /bin
^ permalink raw reply
* [PATCH] [resend] fix non-mergeable buffers packet too large error handling
From: David L Stevens @ 2010-05-17 21:16 UTC (permalink / raw)
To: mst; +Cc: netdev, kvm, virtualization
This patch enforces single-buffer allocation when
mergeable rx buffers is not enabled.
Reported-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David L Stevens <dlstevens@us.ibm.com>
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 309c570..c346304 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -361,13 +361,21 @@ static void handle_rx(struct vhost_net *net)
break;
}
/* TODO: Should check and handle checksum. */
- if (vhost_has_feature(&net->dev, VIRTIO_NET_F_MRG_RXBUF) &&
- memcpy_toiovecend(vq->hdr, (unsigned char *)&headcount,
- offsetof(typeof(hdr), num_buffers),
- sizeof hdr.num_buffers)) {
- vq_err(vq, "Failed num_buffers write");
+ if (vhost_has_feature(&net->dev, VIRTIO_NET_F_MRG_RXBUF)) {
+ if (memcpy_toiovecend(vq->hdr,
+ (unsigned char *)&headcount,
+ offsetof(typeof(hdr),
+ num_buffers),
+ sizeof hdr.num_buffers)) {
+ vq_err(vq, "Failed num_buffers write");
+ vhost_discard_desc(vq, headcount);
+ break;
+ }
+ } else if (headcount > 1) {
+ vq_err(vq, "rx packet too large (%d) for guest",
+ sock_len);
vhost_discard_desc(vq, headcount);
- break;
+ continue;
}
vhost_add_used_and_signal_n(&net->dev, vq, vq->heads,
headcount);
^ permalink raw reply related
* [PATCH] tcp: tcp_synack_options() fix
From: Eric Dumazet @ 2010-05-17 21:04 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Bijay Singh, David Miller, <bhaskie@gmail.com>,
<bhutchings@solarflare.com>, netdev, Ilpo Järvinen
In-Reply-To: <20100517134240.1949f245@nehalam>
Le lundi 17 mai 2010 à 13:42 -0700, Stephen Hemminger a écrit :
> Since you are doing away with flag variable, why not this instead?
>
Sure, we can eliminate this doing_ts variable and save few bytes
Thanks
[PATCH] tcp: tcp_synack_options() fix
Commit 33ad798c924b4a (tcp: options clean up) introduced a problem
if MD5+SACK+timestamps were used in initial SYN message.
Some stacks (old linux for example) try to negotiate MD5+SACK+TSTAMP
sessions, but since 40 bytes of tcp options space are not enough to
store all the bits needed, we chose to disable timestamps in this case.
We send a SYN-ACK _without_ timestamp option, but socket has timestamps
enabled and all further outgoing messages contain a TS block, all with
the initial timestamp of the remote peer.
Fix is to really disable timestamps option for the whole session.
Reported-by: Bijay Singh <Bijay.Singh@guavus.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 0dda86e..44e98d9 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -667,7 +667,6 @@ static unsigned tcp_synack_options(struct sock *sk,
u8 cookie_plus = (xvp != NULL && !xvp->cookie_out_never) ?
xvp->cookie_plus :
0;
- bool doing_ts = ireq->tstamp_ok;
#ifdef CONFIG_TCP_MD5SIG
*md5 = tcp_rsk(req)->af_specific->md5_lookup(sk, req);
@@ -680,7 +679,7 @@ static unsigned tcp_synack_options(struct sock *sk,
* rather than TS in order to fit in better with old,
* buggy kernels, but that was deemed to be unnecessary.
*/
- doing_ts &= !ireq->sack_ok;
+ ireq->tstamp_ok &= !ireq->sack_ok;
}
#else
*md5 = NULL;
@@ -695,7 +694,7 @@ static unsigned tcp_synack_options(struct sock *sk,
opts->options |= OPTION_WSCALE;
remaining -= TCPOLEN_WSCALE_ALIGNED;
}
- if (likely(doing_ts)) {
+ if (likely(ireq->tstamp_ok)) {
opts->options |= OPTION_TS;
opts->tsval = TCP_SKB_CB(skb)->when;
opts->tsecr = req->ts_recent;
@@ -703,7 +702,7 @@ static unsigned tcp_synack_options(struct sock *sk,
}
if (likely(ireq->sack_ok)) {
opts->options |= OPTION_SACK_ADVERTISE;
- if (unlikely(!doing_ts))
+ if (unlikely(!ireq->tstamp_ok))
remaining -= TCPOLEN_SACKPERM_ALIGNED;
}
@@ -711,7 +710,7 @@ static unsigned tcp_synack_options(struct sock *sk,
* If the <SYN> options fit, the same options should fit now!
*/
if (*md5 == NULL &&
- doing_ts &&
+ ireq->tstamp_ok &&
cookie_plus > TCPOLEN_COOKIE_BASE) {
int need = cookie_plus; /* has TCPOLEN_COOKIE_BASE */
^ permalink raw reply related
* Re: [PATCH 0/6] netns support in the kobject layer
From: Greg KH @ 2010-05-17 21:03 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Greg KH, David Miller, kay.sievers, linux-kernel, tj,
cornelia.huck, eric.dumazet, bcrl, serue, netdev
In-Reply-To: <m1zkzyfdob.fsf@fess.ebiederm.org>
On Mon, May 17, 2010 at 01:58:44PM -0700, Eric W. Biederman wrote:
> Greg KH <greg@kroah.com> writes:
>
> > On Sat, May 15, 2010 at 11:26:43PM -0700, David Miller wrote:
> >> From: Greg KH <greg@kroah.com>
> >> Date: Thu, 6 May 2010 13:04:04 -0700
> >>
> >> > On Tue, May 04, 2010 at 05:35:54PM -0700, Eric W. Biederman wrote:
> >> >>
> >> >> With the tagged sysfs support finally merged into Greg's tree,
> >> >> it is time for the last little bits of work to get the kobject
> >> >> layer and network namespaces to play together properly.
> >> >>
> >> >> These patches are roughly evenly divided between network layer work
> >> >> and sysfs layer work. Last time this conundrum came up I believe
> >> >> we decided that the easiest way to handle this was for Greg to carry
> >> >> all of the patches. David, Greg does that still make sense?
> >> >
> >> > That's fine, if I get David's ack on these.
> >>
> >> Looks good to me:
> >>
> >> Acked-by: David S. Miller <davem@davemloft.net>
> >
> > Ok. Eric, can you resend these to me when .35-rc1 is out so I can queue
> > them up then to get some testing in linux-next so that they can make it
> > into .36?
>
> Grumble. Grumble. Grumble.
>
> If I must I will resend these, but these patches are already in
> production use, and I had them to you weeks before the merge window
> closed.
Yes, but they were not reviewed by the network maintainer until after
the merge window closed. I already have your sysfs-namespace patches
queued up for .35, and that's a big enough change for me to feel
comfortable with at the moment.
> Is there no way we can get these in for 2.6.35?
No, sorry. One thing at a time please.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 0/6] netns support in the kobject layer
From: Eric W. Biederman @ 2010-05-17 20:58 UTC (permalink / raw)
To: Greg KH
Cc: David Miller, gregkh, kay.sievers, linux-kernel, tj,
cornelia.huck, eric.dumazet, bcrl, serue, netdev
In-Reply-To: <20100517181133.GB18721@kroah.com>
Greg KH <greg@kroah.com> writes:
> On Sat, May 15, 2010 at 11:26:43PM -0700, David Miller wrote:
>> From: Greg KH <greg@kroah.com>
>> Date: Thu, 6 May 2010 13:04:04 -0700
>>
>> > On Tue, May 04, 2010 at 05:35:54PM -0700, Eric W. Biederman wrote:
>> >>
>> >> With the tagged sysfs support finally merged into Greg's tree,
>> >> it is time for the last little bits of work to get the kobject
>> >> layer and network namespaces to play together properly.
>> >>
>> >> These patches are roughly evenly divided between network layer work
>> >> and sysfs layer work. Last time this conundrum came up I believe
>> >> we decided that the easiest way to handle this was for Greg to carry
>> >> all of the patches. David, Greg does that still make sense?
>> >
>> > That's fine, if I get David's ack on these.
>>
>> Looks good to me:
>>
>> Acked-by: David S. Miller <davem@davemloft.net>
>
> Ok. Eric, can you resend these to me when .35-rc1 is out so I can queue
> them up then to get some testing in linux-next so that they can make it
> into .36?
Grumble. Grumble. Grumble.
If I must I will resend these, but these patches are already in
production use, and I had them to you weeks before the merge window
closed.
Is there no way we can get these in for 2.6.35?
Eric
^ permalink raw reply
* Re: TCP-MD5 checksum failure on x86_64 SMP
From: Stephen Hemminger @ 2010-05-17 20:42 UTC (permalink / raw)
To: Eric Dumazet
Cc: Bijay Singh, David Miller, <bhaskie@gmail.com>,
<bhutchings@solarflare.com>, netdev, Ilpo Järvinen
In-Reply-To: <1274072629.2299.58.camel@edumazet-laptop>
On Mon, 17 May 2010 07:03:49 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 17 mai 2010 à 03:49 +0000, Bijay Singh a écrit :
>
> > I am on quite an old kernel 2.6.27 and could not apply your patches.
> >
> > Then i moved on to the kernel 2.6.32.11 however since then I have not been able to bring up my card, this is something i need to fix before i can test you fix. Working on that.
> >
>
> Thanks again for the status report.
>
> I see bug is older than what I stated in my previous mail
>
> I could reproduce it in my lab and confirm following patch fixes it
>
> This is a stable candidate (2.6.27 kernels)
>
> Thanks
>
> [PATCH] tcp: tcp_synack_options() fix
>
> Commit 33ad798c924b4a (tcp: options clean up) introduced a problem
> if MD5+SACK+timestamps were used in initial SYN message.
>
> Some stacks (old linux for example) try to negotiate MD5+SACK+TSTAMP
> sessions, but since 20 bytes of tcp options space are not enough to
> store all the bits needed, we chose to disable timestamps in this case.
>
> We send a SYN-ACK _without_ timestamp option, but socket has timestamps
> enabled and all further outgoing messages contain a TS block, all with
> the initial timestamp of the remote peer.
>
> Fix is to really disable timestamps option for the whole session.
>
> Reported-by: Bijay Singh <Bijay.Singh@guavus.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> net/ipv4/tcp_output.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 0dda86e..b8bb226 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -667,7 +667,7 @@ static unsigned tcp_synack_options(struct sock *sk,
> u8 cookie_plus = (xvp != NULL && !xvp->cookie_out_never) ?
> xvp->cookie_plus :
> 0;
> - bool doing_ts = ireq->tstamp_ok;
> + bool doing_ts;
>
> #ifdef CONFIG_TCP_MD5SIG
> *md5 = tcp_rsk(req)->af_specific->md5_lookup(sk, req);
> @@ -680,11 +680,12 @@ static unsigned tcp_synack_options(struct sock *sk,
> * rather than TS in order to fit in better with old,
> * buggy kernels, but that was deemed to be unnecessary.
> */
> - doing_ts &= !ireq->sack_ok;
> + ireq->tstamp_ok &= !ireq->sack_ok;
> }
> #else
> *md5 = NULL;
> #endif
> + doing_ts = ireq->tstamp_ok;
>
> /* We always send an MSS option. */
> opts->mss = mss;
>
>
Since you are doing away with flag variable, why not this instead?
--- a/net/ipv4/tcp_output.c 2010-05-17 13:38:32.822025583 -0700
+++ b/net/ipv4/tcp_output.c 2010-05-17 13:41:47.321734775 -0700
@@ -668,7 +668,6 @@ static unsigned tcp_synack_options(struc
u8 cookie_plus = (xvp != NULL && !xvp->cookie_out_never) ?
xvp->cookie_plus :
0;
- bool doing_ts = ireq->tstamp_ok;
#ifdef CONFIG_TCP_MD5SIG
*md5 = tcp_rsk(req)->af_specific->md5_lookup(sk, req);
@@ -681,7 +680,7 @@ static unsigned tcp_synack_options(struc
* rather than TS in order to fit in better with old,
* buggy kernels, but that was deemed to be unnecessary.
*/
- doing_ts &= !ireq->sack_ok;
+ ireq->tstamp_ok &= !ireq->sack_ok;
}
#else
*md5 = NULL;
@@ -696,7 +695,7 @@ static unsigned tcp_synack_options(struc
opts->options |= OPTION_WSCALE;
remaining -= TCPOLEN_WSCALE_ALIGNED;
}
- if (likely(doing_ts)) {
+ if (likely(ireq->tstamp_ok)) {
opts->options |= OPTION_TS;
opts->tsval = TCP_SKB_CB(skb)->when;
opts->tsecr = req->ts_recent;
@@ -704,7 +703,7 @@ static unsigned tcp_synack_options(struc
}
if (likely(ireq->sack_ok)) {
opts->options |= OPTION_SACK_ADVERTISE;
- if (unlikely(!doing_ts))
+ if (unlikely(!ireq->tstamp_ok))
remaining -= TCPOLEN_SACKPERM_ALIGNED;
}
@@ -712,7 +711,7 @@ static unsigned tcp_synack_options(struc
* If the <SYN> options fit, the same options should fit now!
*/
if (*md5 == NULL &&
- doing_ts &&
+ ireq->tstamp_ok &&
cookie_plus > TCPOLEN_COOKIE_BASE) {
int need = cookie_plus; /* has TCPOLEN_COOKIE_BASE */
--
^ permalink raw reply
* Re: iproute2 issue with adding rules.
From: Ben Greear @ 2010-05-17 20:34 UTC (permalink / raw)
To: Chris Wright; +Cc: NetDev
In-Reply-To: <20100517203004.GD8301@sequoia.sous-sol.org>
On 05/17/2010 01:30 PM, Chris Wright wrote:
> * Ben Greear (greearb@candelatech.com) wrote:
>> On 05/17/2010 01:13 PM, Ben Greear wrote:
>>> On 05/17/2010 12:03 PM, Ben Greear wrote:
>>>> On older releases, you can do this with iproute:
>>>>
>>>> # ip ru add from 9.9.9.2/32 table 226 pref 400
>>>> #
>>>>
>>>> But, in latest git, it returns an error:
>>>> # ip ru add from 9.9.9.2/32 table 226 pref 400
>>>> Error: an inet prefix is expected rather than "9.9.9.2/32".
>>>>
>>>> Is that on purpose?
>>>
>>> I was thinking maybe this was a library issue, since I compiled
>>> on one machine and ran the 'ip' exe on another. So, I tried compiling
>>> on the test system.
>>
>> I'm not thinking too well today, but this patch fixes the compile.
>> No idea if it's actually correct code.
>
> Needs more changes than that patch.
Ok, I'll try going back a few commits to find something that compiles
w/out my hacks.
Also, the rule addition does work..make install put ip in
a different place than it's installed in fedora, so I wasn't
actually running the latest code when I first tried to add
the rule.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: iproute2 issue with adding rules.
From: Chris Wright @ 2010-05-17 20:30 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev
In-Reply-To: <4BF1A6D1.70507@candelatech.com>
* Ben Greear (greearb@candelatech.com) wrote:
> On 05/17/2010 01:13 PM, Ben Greear wrote:
> >On 05/17/2010 12:03 PM, Ben Greear wrote:
> >>On older releases, you can do this with iproute:
> >>
> >># ip ru add from 9.9.9.2/32 table 226 pref 400
> >>#
> >>
> >>But, in latest git, it returns an error:
> >># ip ru add from 9.9.9.2/32 table 226 pref 400
> >>Error: an inet prefix is expected rather than "9.9.9.2/32".
> >>
> >>Is that on purpose?
> >
> >I was thinking maybe this was a library issue, since I compiled
> >on one machine and ran the 'ip' exe on another. So, I tried compiling
> >on the test system.
>
> I'm not thinking too well today, but this patch fixes the compile.
> No idea if it's actually correct code.
Needs more changes than that patch.
thanks,
-chris
^ permalink raw reply
* Re: iproute2 issue with adding rules.
From: Ben Greear @ 2010-05-17 20:28 UTC (permalink / raw)
To: NetDev
In-Reply-To: <4BF1A352.5020500@candelatech.com>
On 05/17/2010 01:13 PM, Ben Greear wrote:
> On 05/17/2010 12:03 PM, Ben Greear wrote:
>> On older releases, you can do this with iproute:
>>
>> # ip ru add from 9.9.9.2/32 table 226 pref 400
>> #
>>
>> But, in latest git, it returns an error:
>> # ip ru add from 9.9.9.2/32 table 226 pref 400
>> Error: an inet prefix is expected rather than "9.9.9.2/32".
>>
>> Is that on purpose?
>
> I was thinking maybe this was a library issue, since I compiled
> on one machine and ran the 'ip' exe on another. So, I tried compiling
> on the test system.
I'm not thinking too well today, but this patch fixes the compile.
No idea if it's actually correct code.
Still can't add the rule like I was trying...but at least it's probably
not an issue with libraries:
[root@ct503-10G-09 iproute2]# git diff
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 48f7b1e..4d4481a 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -331,13 +331,13 @@ int print_linkinfo(const struct sockaddr_nl *who,
);
}
}
- if (do_link && tb[IFLA_VFINFO] && tb[IFLA_NUM_VF]) {
+ if (do_link && tb[IFLA_VFINFO_LIST] && tb[IFLA_NUM_VF]) {
SPRINT_BUF(b1);
- struct rtattr *rta = tb[IFLA_VFINFO];
+ struct rtattr *rta = tb[IFLA_VFINFO_LIST];
struct ifla_vf_info *ivi;
int i;
for (i = 0; i < *(int *)RTA_DATA(tb[IFLA_NUM_VF]); i++) {
- if (rta->rta_type != IFLA_VFINFO) {
+ if (rta->rta_type != IFLA_VFINFO_LIST) {
fprintf(stderr, "BUG: rta type is %d\n", rta->rta_type);
break;
}
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply related
* Re: iproute2 issue with adding rules.
From: Stephen Hemminger @ 2010-05-17 20:27 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev
In-Reply-To: <4BF1A352.5020500@candelatech.com>
On Mon, 17 May 2010 13:13:06 -0700
Ben Greear <greearb@candelatech.com> wrote:
> On 05/17/2010 12:03 PM, Ben Greear wrote:
> > On older releases, you can do this with iproute:
> >
> > # ip ru add from 9.9.9.2/32 table 226 pref 400
> > #
> >
> > But, in latest git, it returns an error:
> > # ip ru add from 9.9.9.2/32 table 226 pref 400
> > Error: an inet prefix is expected rather than "9.9.9.2/32".
> >
> > Is that on purpose?
>
> I was thinking maybe this was a library issue, since I compiled
> on one machine and ran the 'ip' exe on another. So, I tried compiling
> on the test system.
>
> But, iproute will not compile, apparently because it finds the
> /usr/include/linux header files before whatever is packaged with
> iproute:
>
> gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -I../include -DRESOLVE_HOSTNAMES -DLIBDIR=\"/usr/lib/\" -c -o ipaddress.o ipaddress.c
> ipaddress.c: In function ‘print_linkinfo’:
> ipaddress.c:334: error: ‘IFLA_VFINFO’ undeclared (first use in this function)
> ipaddress.c:334: error: (Each undeclared identifier is reported only once
> ipaddress.c:334: error: for each function it appears in.)
> make[1]: *** [ipaddress.o] Error 1
> make[1]: Leaving directory `/root/git/iproute2/ip'
> make: *** [all] Error 2
>
>
> I tried moving /usr/include/linux out of the way, but then it blows up
> even worse (can't find errno.h, etc)
>
> Are we supposed to be able to compile iproute2 on a system with moderately
> outdated kernel headers?
>
> If not, why bother with the iproute/include/linux directory at all?
The issue is the last minute VF changes in 2.6.34 are not supported
in iproute util yet. Please wait until it is fixed.
^ permalink raw reply
* [PATCH v2] Fix SJA1000 command register writes on SMP systems
From: Oliver Hartkopp @ 2010-05-17 20:17 UTC (permalink / raw)
To: David Miller
Cc: SocketCAN Core Mailing List, Linux Netdev List,
Wolfgang Grandegger
The SJA1000 command register is concurrently written in the rx-path to free
the receive buffer _and_ in the tx-path to start the transmission.
The SJA1000 data sheet, 6.4.4 COMMAND REGISTER (CMR) states:
"Between two commands at least one internal clock cycle is needed in
order to proceed. The internal clock is half of the external oscillator
frequency."
On SMP systems this leads to a write stall in the tx-path, which can be
solved by adding some locking for the command register in the SMP case.
In this special case we also read the status register to settle the command
register write.
Thanks to Klaus Hitschler for the original fix and detailed problem
description.
This patch applies on net-2.6 and (with some offsets) on net-next-2.6 .
Signed-off-by: Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
---
diff --git a/drivers/net/can/sja1000/sja1000.c b/drivers/net/can/sja1000/sja1000.c
index 145b1a7..2760085 100644
--- a/drivers/net/can/sja1000/sja1000.c
+++ b/drivers/net/can/sja1000/sja1000.c
@@ -84,6 +84,27 @@ static struct can_bittiming_const sja1000_bittiming_const = {
.brp_inc = 1,
};
+static void sja1000_write_cmdreg(struct sja1000_priv *priv, u8 val)
+{
+ /* the command register needs some locking on SMP systems */
+
+#ifdef CONFIG_SMP
+
+ unsigned long flags;
+
+ spin_lock_irqsave(&priv->cmdreg_lock, flags);
+ priv->write_reg(priv, REG_CMR, val);
+ priv->read_reg(priv, REG_SR);
+ spin_unlock_irqrestore(&priv->cmdreg_lock, flags);
+
+#else
+
+ /* write to the command register without locking */
+ priv->write_reg(priv, REG_CMR, val);
+
+#endif
+}
+
static int sja1000_probe_chip(struct net_device *dev)
{
struct sja1000_priv *priv = netdev_priv(dev);
@@ -297,7 +318,7 @@ static netdev_tx_t sja1000_start_xmit(struct sk_buff *skb,
can_put_echo_skb(skb, dev, 0);
- priv->write_reg(priv, REG_CMR, CMD_TR);
+ sja1000_write_cmdreg(priv, CMD_TR);
return NETDEV_TX_OK;
}
@@ -346,7 +367,7 @@ static void sja1000_rx(struct net_device *dev)
cf->can_id = id;
/* release receive buffer */
- priv->write_reg(priv, REG_CMR, CMD_RRB);
+ sja1000_write_cmdreg(priv, CMD_RRB);
netif_rx(skb);
@@ -374,7 +395,7 @@ static int sja1000_err(struct net_device *dev, uint8_t isrc, uint8_t status)
cf->data[1] = CAN_ERR_CRTL_RX_OVERFLOW;
stats->rx_over_errors++;
stats->rx_errors++;
- priv->write_reg(priv, REG_CMR, CMD_CDO); /* clear bit */
+ sja1000_write_cmdreg(priv, CMD_CDO); /* clear bit */
}
if (isrc & IRQ_EI) {
diff --git a/drivers/net/can/sja1000/sja1000.h b/drivers/net/can/sja1000/sja1000.h
index 97a622b..4527d95 100644
--- a/drivers/net/can/sja1000/sja1000.h
+++ b/drivers/net/can/sja1000/sja1000.h
@@ -168,6 +168,10 @@ struct sja1000_priv {
void __iomem *reg_base; /* ioremap'ed address to registers */
unsigned long irq_flags; /* for request_irq() */
+#ifdef CONFIG_SMP
+ spinlock_t cmdreg_lock; /* lock for concurrent cmd register writes */
+#endif
+
u16 flags; /* custom mode flags */
u8 ocr; /* output control register */
u8 cdr; /* clock divider register */
^ 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