Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH] textsearch: doc - fix spelling in lib/textsearch.c.
From: David Miller @ 2011-01-25  7:33 UTC (permalink / raw)
  To: hawk; +Cc: netdev, sander.contrib
In-Reply-To: <20110124124137.10202.47152.stgit@firesoul.comx.local>

From: Jesper Dangaard Brouer <hawk@comx.dk>
Date: Mon, 24 Jan 2011 13:41:37 +0100

> Found the following spelling errors while reading the textsearch code:
>   "facitilies"  -> "facilities"
>   "continously" -> "continuously"
>   "arbitary"    -> "arbitrary"
>   "patern"      -> "pattern"
>   "occurences"  -> "occurrences"
> 
> I'll try to push this patch through DaveM, given the only users
> of textsearch is in the net/ tree (nf_conntrack_amanda.c, xt_string.c
> and em_text.c)
> 
> Signed-off-by: Jesper Sander <sander.contrib@gmail.com>
> Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH] net: remove tests on 64bit platforms
From: David Miller @ 2011-01-25  7:30 UTC (permalink / raw)
  To: xiaosuo; +Cc: kuznet, pekkas, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <1295929298-13163-1-git-send-email-xiaosuo@gmail.com>

From: Changli Gao <xiaosuo@gmail.com>
Date: Tue, 25 Jan 2011 12:21:38 +0800

> On 64bit platforms, >31 bit shifting of a unsigned long variable is
> valid, so we can remove the related boundary tests, which may slow
> down the CPU if branch prediction fails.

The key word is "may", you don't actually know if this kind of
change actually matters for performance in practice.

I'm not applying this.

^ permalink raw reply

* RE: does intel X520-SR(ixgbe) support RSS on single VLAN?
From: Jon Zhou @ 2011-01-25  7:22 UTC (permalink / raw)
  To: Ben Hutchings, Rui
  Cc: Alexander Duyck, netdev@vger.kernel.org,
	e1000-devel@lists.sourceforge.net
In-Reply-To: <1295924734.2896.6.camel@localhost>



> -----Original Message-----
> From: Ben Hutchings [mailto:bhutchings@solarflare.com]
> Sent: Tuesday, January 25, 2011 11:06 AM
> To: Rui
> Cc: Alexander Duyck; netdev@vger.kernel.org; e1000-
> devel@lists.sourceforge.net
> Subject: Re: does intel X520-SR(ixgbe) support RSS on single VLAN?
> 
> On Tue, 2011-01-25 at 10:10 +0800, Rui wrote:
> > On Tue, Jan 25, 2011 at 1:09 AM, Alexander Duyck
> > <alexander.h.duyck@intel.com> wrote:
> > > On 1/24/2011 6:18 AM, Rui wrote:
> > >>
> > >> hi
> > >> does intel X520-SR support RSS on single VLAN?
> > >>
> > >> tested with 3 different vlan id and priority packets
> > >> What I saw is that all packets were always delivered to the same
> RxQ.
> > >> looks can not get a different RSS index for these packet?
> > >> any setting needed?
> > >> --
> > >> 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
> > >
> > > The X520 should have no problems hashing on a single VLAN tagged
> frame.
> > >  However the VLAN will not be a part of the RSS hash.  The  only
> components
> > > of the hash are the IPv4/IPv6 source and destination addresses, and
> if the
> > > flow is TCP then the port numbers.
> > >
> > hi alexander
> > I got these information from the intel community:
> >
> > 'I asked our software engineers about your question, and this is what
> I learned.
> > You cannot filter by just VLAN or VLAN priority.  The L4 type will
> > also play a role in the filter and as such you would only be able to
> > filter TCP, UDP, and SCTP packets that are bound for a VLAN.
> > The command itself to setup a filter is “ethtool –U ethX flow-type
> > tcp4 vlan 0x2000 vlan-mask 0xE000 action Y” where X is the correct
> > index for the interface and Y is the queue you want to route the
> > traffic to.  This would have to be repeated for udp4 and sctp4.
> > I hope this will help.
> > Mark H"
> 
> The mask specifies bits to be ignored, so if you want to filter on the
> basis of only the priority bits you should use vlan-mask 0xfff.  Unless
> this is another inconsistency I failed to notice...
> 
> > so my question is that the VLAN is PART of the RSS or not?
> 
> It's not part of any specified Toeplitz hash.  However, some hardware
> supports adding the hash (after indirection) to the queue number
> specified by a filter.  Currently the ethtool API doesn't have a way to
> request that.
> 
> > looks the
> > perfect filter support vlan id ?can the perfect filter support
> > wildchar,such as: flow-type ANY?
> 
> It is possible to specify this using flow-type ether, but the ixgbe
> driver does not yet support that (and I have no idea whether the
> hardware does).
> 


ethtool –U ethX flow-type tcp4 vlan 0x2000 vlan-mask 0xE000 action Y”

I got this msg:
Cannot add new RX n-tuple filter: Operation not supported
This command is only supported after 2.6.24?

Quoted:

"ethtool: Introduce n-tuple filter programming support

author Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>  
 Thu, 11 Feb 2010 04:03:05 +0000 (20:03 -0800) 
committer David S. Miller <davem@davemloft.net>  
 Thu, 11 Feb 2010 04:03:05 +0000 (20:03 -0800) 

This patchset enables the ethtool layer to program n-tuple
filters to an underlying device.  The idea is to allow capable
hardware to have static rules applied that can assist steering
flows into appropriate queues.

Hardware that is known to support these types of filters today
are ixgbe and niu.

Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
"


> Ben.
> 
> --
> Ben Hutchings, Senior Software Engineer, Solarflare Communications
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.


^ permalink raw reply

* Re: [PATCH] net: add sysfs entry for device group
From: David Miller @ 2011-01-25  7:23 UTC (permalink / raw)
  To: shemminger; +Cc: ddvlad, netdev
In-Reply-To: <20110125144106.1cbd12b0@s6510>

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 25 Jan 2011 14:41:06 +1000

> On Mon, 24 Jan 2011 15:37:29 +0200
> Vlad Dogaru <ddvlad@rosedu.org> wrote:
> 
>> The group of a network device can be queried or changed from userspace
>> using sysfs.
>> 
>> For example, considering sysfs mounted in /sys, one can change the group
>> that interface lo belongs to:
>> 	echo 1 > /sys/class/net/lo/group
>> 
>> Signed-off-by: Vlad Dogaru <ddvlad@rosedu.org>
> 
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>

Applied to net-next-2.6, thanks.

^ permalink raw reply

* Re: [PATCH] USB NET KL5KUSB101: Fix mem leak in error path of kaweth_download_firmware()
From: David Miller @ 2011-01-25  7:20 UTC (permalink / raw)
  To: jj; +Cc: linux-usb, linux-kernel, netdev, gregkh, zapman, rothwell
In-Reply-To: <alpine.LNX.2.00.1101232315230.30955@swampdragon.chaosbits.net>

From: Jesper Juhl <jj@chaosbits.net>
Date: Sun, 23 Jan 2011 23:19:55 +0100 (CET)

> We will leak the storage allocated by request_firmware() if the size of 
> the firmware is greater than KAWETH_FIRMWARE_BUF_SIZE.
> This removes the leak by calling release_firmware() before we return 
> -ENOSPC.
> 
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>

Applied, thanks Jesper.

^ permalink raw reply

* Re: [PATCH net-next-2.6] veth: remove unneeded ifname code from veth_newlink()
From: David Miller @ 2011-01-25  7:18 UTC (permalink / raw)
  To: jpirko; +Cc: netdev, xemul
In-Reply-To: <20110124154546.GA2689@psychotron.brq.redhat.com>

From: Jiri Pirko <jpirko@redhat.com>
Date: Mon, 24 Jan 2011 16:45:46 +0100

> The code is not needed because tb[IFLA_IFNAME] is already
> processed in rtnl_newlink(). Remove this redundancy.
> 
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>

Applied, thanks Jiri.

^ permalink raw reply

* Re: [PATCH net-2.6] bnx2: Always set ETH_FLAG_TXVLAN
From: David Miller @ 2011-01-25  7:16 UTC (permalink / raw)
  To: mchan; +Cc: eric.dumazet, jesse, netdev
In-Reply-To: <1295909942-758-1-git-send-email-mchan@broadcom.com>

From: "Michael Chan" <mchan@broadcom.com>
Date: Mon, 24 Jan 2011 14:59:02 -0800

> TSO does not work if the VLAN tag is in the packet (non-accelerated).
> We may be able to remove this restriction in future firmware.
> 
> Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>

Applied, thanks.

^ permalink raw reply

* [PATCH v2] smc91x: add devicetree support
From: Thomas Chou @ 2011-01-25  7:09 UTC (permalink / raw)
  To: Grant Likely, Nicolas Pitre
  Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	nios2-dev-1eJk0qcHJCcaeqlQEoCUNoJY59XmG8rH,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <AANLkTikgsqJqdW2qh7h4yATCmGFb5MkHCosma_DOBq-Y-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Signed-off-by: Thomas Chou <thomas-SDxUXYEhEBiCuPEqFHbRBg@public.gmane.org>
---
v2 specify part numbers in compat as Grant suggested.

 drivers/net/smc91x.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/net/smc91x.c b/drivers/net/smc91x.c
index 726df61..de48ebd 100644
--- a/drivers/net/smc91x.c
+++ b/drivers/net/smc91x.c
@@ -81,6 +81,7 @@ static const char version[] =
 #include <linux/ethtool.h>
 #include <linux/mii.h>
 #include <linux/workqueue.h>
+#include <linux/of.h>
 
 #include <linux/netdevice.h>
 #include <linux/etherdevice.h>
@@ -2394,6 +2395,13 @@ static int smc_drv_resume(struct device *dev)
 	return 0;
 }
 
+static const struct of_device_id smc91x_match[] = {
+	{ .compatible = "smsc,smc91c94", },
+	{ .compatible = "smsc,smc91c111", },
+	{},
+}
+MODULE_DEVICE_TABLE(of, smc91x_match);
+
 static struct dev_pm_ops smc_drv_pm_ops = {
 	.suspend	= smc_drv_suspend,
 	.resume		= smc_drv_resume,
@@ -2406,6 +2414,9 @@ static struct platform_driver smc_driver = {
 		.name	= CARDNAME,
 		.owner	= THIS_MODULE,
 		.pm	= &smc_drv_pm_ops,
+#ifdef CONFIG_OF
+		.of_match_table = smc91x_match,
+#endif
 	},
 };
 
-- 
1.7.3.5

^ permalink raw reply related

* Re: [PATCH] netfilter: ipvs: fix compiler warnings
From: Hans Schillstrom @ 2011-01-25  6:49 UTC (permalink / raw)
  To: Changli Gao
  Cc: Simon Horman, Wensong Zhang, Julian Anastasov, Patrick McHardy,
	David S. Miller, netdev, lvs-devel, netfilter-devel
In-Reply-To: <1295930418-14980-1-git-send-email-xiaosuo@gmail.com>

On Tuesday, January 25, 2011 05:40:18 Changli Gao wrote:
> Fix compiler warnings when IP_VS_DBG() isn't defined.
> 
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Acked-by: Hans Schillstrom <hans.schillstrom@ericsson.com>

> ---
>  net/netfilter/ipvs/ip_vs_core.c  |    4 +---
>  3 files changed, 9 insertions(+), 3 deletions(-)
> diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
> index f36a84f..d889f4f 100644
> --- a/net/netfilter/ipvs/ip_vs_core.c
> +++ b/net/netfilter/ipvs/ip_vs_core.c
> @@ -1894,9 +1894,7 @@ static int __net_init __ip_vs_init(struct net *net)
>  
>  static void __net_exit __ip_vs_cleanup(struct net *net)
>  {
> -	struct netns_ipvs *ipvs = net_ipvs(net);
> -
> -	IP_VS_DBG(10, "ipvs netns %d released\n", ipvs->gen);
> +	IP_VS_DBG(10, "ipvs netns %d released\n", net_ipvs(net)->gen);
>  }
>  
>  static struct pernet_operations ipvs_core_ops = {
> --
Thanks I forgot that one.

Regards
Hans Schillstrom

^ permalink raw reply

* Re: [PATCH] IPVS: Remove unused pr_fmt #define
From: Simon Horman @ 2011-01-25  6:24 UTC (permalink / raw)
  To: David Miller; +Cc: netfilter-devel, netdev, lvs-devel, joe
In-Reply-To: <20110124.212425.71124904.davem@davemloft.net>

On Mon, Jan 24, 2011 at 09:24:25PM -0800, David Miller wrote:
> From: Simon Horman <horms@verge.net.au>
> Date: Tue, 25 Jan 2011 15:15:53 +1000
> 
> > Cc: Joe Perches <joe@perches.com>
> > Signed-off-by: Simon Horman <horms@verge.net.au>
> 
> Isn't it used by IP_VS_DBG?

Ooops, yes. Please ignore this and v2.

^ permalink raw reply

* Re: [PATCH] smc91x: add devicetree support
From: Grant Likely @ 2011-01-25  6:24 UTC (permalink / raw)
  To: Thomas Chou
  Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	nios2-dev-1eJk0qcHJCcaeqlQEoCUNoJY59XmG8rH,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1295935170-19518-1-git-send-email-thomas-SDxUXYEhEBiCuPEqFHbRBg@public.gmane.org>

On Mon, Jan 24, 2011 at 10:59 PM, Thomas Chou <thomas-SDxUXYEhEBiCuPEqFHbRBg@public.gmane.org> wrote:
> Signed-off-by: Thomas Chou <thomas-SDxUXYEhEBiCuPEqFHbRBg@public.gmane.org>
> ---
>  drivers/net/smc91x.c |   10 ++++++++++
>  1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/smc91x.c b/drivers/net/smc91x.c
> index 726df61..d29e18d 100644
> --- a/drivers/net/smc91x.c
> +++ b/drivers/net/smc91x.c
> @@ -81,6 +81,7 @@ static const char version[] =
>  #include <linux/ethtool.h>
>  #include <linux/mii.h>
>  #include <linux/workqueue.h>
> +#include <linux/of.h>
>
>  #include <linux/netdevice.h>
>  #include <linux/etherdevice.h>
> @@ -2394,6 +2395,12 @@ static int smc_drv_resume(struct device *dev)
>        return 0;
>  }
>
> +static const struct of_device_id smc91x_match[] = {
> +       { .compatible = "smsc,smc91x", },

Be specific.  What *exact* smsc device are you adding support for?
Wildcards like smc91x tend to cause problems in the future.

> +       {},
> +}
> +MODULE_DEVICE_TABLE(of, smc91x_match);
> +
>  static struct dev_pm_ops smc_drv_pm_ops = {
>        .suspend        = smc_drv_suspend,
>        .resume         = smc_drv_resume,
> @@ -2406,6 +2413,9 @@ static struct platform_driver smc_driver = {
>                .name   = CARDNAME,
>                .owner  = THIS_MODULE,
>                .pm     = &smc_drv_pm_ops,
> +#ifdef CONFIG_OF
> +               .of_match_table = smc91x_match,
> +#endif
>        },
>  };
>
> --
> 1.7.3.5
>
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* [PATCH] [patch v2] IPVS: Remove unused pr_fmt #define
From: Simon Horman @ 2011-01-25  6:22 UTC (permalink / raw)
  To: netfilter-devel, netdev, lvs-devel; +Cc: Simon Horman, Joe Perches

Cc: Joe Perches <joe@perches.com>
Signed-off-by: Simon Horman <horms@verge.net.au>

---

v2:
Also remove unused pr_fmt from other files in net/netfilter/ipvs/
Also remove KMSG_COMPONENT
---
 net/netfilter/ipvs/ip_vs_app.c          |    3 ---
 net/netfilter/ipvs/ip_vs_est.c          |    3 ---
 net/netfilter/ipvs/ip_vs_lc.c           |    3 ---
 net/netfilter/ipvs/ip_vs_nfct.c         |    3 ---
 net/netfilter/ipvs/ip_vs_nq.c           |    3 ---
 net/netfilter/ipvs/ip_vs_pe_sip.c       |    3 ---
 net/netfilter/ipvs/ip_vs_proto_ah_esp.c |    3 ---
 net/netfilter/ipvs/ip_vs_proto_tcp.c    |    3 ---
 net/netfilter/ipvs/ip_vs_rr.c           |    3 ---
 net/netfilter/ipvs/ip_vs_sed.c          |    3 ---
 net/netfilter/ipvs/ip_vs_wlc.c          |    3 ---
 net/netfilter/ipvs/ip_vs_xmit.c         |    3 ---
 12 files changed, 0 insertions(+), 36 deletions(-)

diff --git a/net/netfilter/ipvs/ip_vs_app.c b/net/netfilter/ipvs/ip_vs_app.c
index 5c48ffb..e216dda 100644
--- a/net/netfilter/ipvs/ip_vs_app.c
+++ b/net/netfilter/ipvs/ip_vs_app.c
@@ -18,9 +18,6 @@
  *
  */
 
-#define KMSG_COMPONENT "IPVS"
-#define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
-
 #include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/skbuff.h>
diff --git a/net/netfilter/ipvs/ip_vs_est.c b/net/netfilter/ipvs/ip_vs_est.c
index f560a05..10a100a 100644
--- a/net/netfilter/ipvs/ip_vs_est.c
+++ b/net/netfilter/ipvs/ip_vs_est.c
@@ -16,9 +16,6 @@
  *              get_stats()) do the per cpu summing.
  */
 
-#define KMSG_COMPONENT "IPVS"
-#define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
-
 #include <linux/kernel.h>
 #include <linux/jiffies.h>
 #include <linux/types.h>
diff --git a/net/netfilter/ipvs/ip_vs_lc.c b/net/netfilter/ipvs/ip_vs_lc.c
index 4f69db1..e906763 100644
--- a/net/netfilter/ipvs/ip_vs_lc.c
+++ b/net/netfilter/ipvs/ip_vs_lc.c
@@ -14,9 +14,6 @@
  *
  */
 
-#define KMSG_COMPONENT "IPVS"
-#define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
-
 #include <linux/module.h>
 #include <linux/kernel.h>
 
diff --git a/net/netfilter/ipvs/ip_vs_nfct.c b/net/netfilter/ipvs/ip_vs_nfct.c
index f454c80..05954db 100644
--- a/net/netfilter/ipvs/ip_vs_nfct.c
+++ b/net/netfilter/ipvs/ip_vs_nfct.c
@@ -47,9 +47,6 @@
  *
  */
 
-#define KMSG_COMPONENT "IPVS"
-#define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
-
 #include <linux/module.h>
 #include <linux/types.h>
 #include <linux/kernel.h>
diff --git a/net/netfilter/ipvs/ip_vs_nq.c b/net/netfilter/ipvs/ip_vs_nq.c
index c413e18..4fbaf1d 100644
--- a/net/netfilter/ipvs/ip_vs_nq.c
+++ b/net/netfilter/ipvs/ip_vs_nq.c
@@ -31,9 +31,6 @@
  *
  */
 
-#define KMSG_COMPONENT "IPVS"
-#define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
-
 #include <linux/module.h>
 #include <linux/kernel.h>
 
diff --git a/net/netfilter/ipvs/ip_vs_pe_sip.c b/net/netfilter/ipvs/ip_vs_pe_sip.c
index 0d83bc0..2a3da04 100644
--- a/net/netfilter/ipvs/ip_vs_pe_sip.c
+++ b/net/netfilter/ipvs/ip_vs_pe_sip.c
@@ -1,6 +1,3 @@
-#define KMSG_COMPONENT "IPVS"
-#define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
-
 #include <linux/module.h>
 #include <linux/kernel.h>
 
diff --git a/net/netfilter/ipvs/ip_vs_proto_ah_esp.c b/net/netfilter/ipvs/ip_vs_proto_ah_esp.c
index 5b8eb8b..0ae9710 100644
--- a/net/netfilter/ipvs/ip_vs_proto_ah_esp.c
+++ b/net/netfilter/ipvs/ip_vs_proto_ah_esp.c
@@ -10,9 +10,6 @@
  *
  */
 
-#define KMSG_COMPONENT "IPVS"
-#define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
-
 #include <linux/in.h>
 #include <linux/ip.h>
 #include <linux/module.h>
diff --git a/net/netfilter/ipvs/ip_vs_proto_tcp.c b/net/netfilter/ipvs/ip_vs_proto_tcp.c
index c0cc341..791e558 100644
--- a/net/netfilter/ipvs/ip_vs_proto_tcp.c
+++ b/net/netfilter/ipvs/ip_vs_proto_tcp.c
@@ -17,9 +17,6 @@
  *              protocol ip_vs_proto_data and is handled by netns
  */
 
-#define KMSG_COMPONENT "IPVS"
-#define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
-
 #include <linux/kernel.h>
 #include <linux/ip.h>
 #include <linux/tcp.h>                  /* for tcphdr */
diff --git a/net/netfilter/ipvs/ip_vs_rr.c b/net/netfilter/ipvs/ip_vs_rr.c
index e210f37..5857da9 100644
--- a/net/netfilter/ipvs/ip_vs_rr.c
+++ b/net/netfilter/ipvs/ip_vs_rr.c
@@ -19,9 +19,6 @@
  *
  */
 
-#define KMSG_COMPONENT "IPVS"
-#define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
-
 #include <linux/module.h>
 #include <linux/kernel.h>
 
diff --git a/net/netfilter/ipvs/ip_vs_sed.c b/net/netfilter/ipvs/ip_vs_sed.c
index 1ab75a9..2b9d2c0 100644
--- a/net/netfilter/ipvs/ip_vs_sed.c
+++ b/net/netfilter/ipvs/ip_vs_sed.c
@@ -35,9 +35,6 @@
  *
  */
 
-#define KMSG_COMPONENT "IPVS"
-#define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
-
 #include <linux/module.h>
 #include <linux/kernel.h>
 
diff --git a/net/netfilter/ipvs/ip_vs_wlc.c b/net/netfilter/ipvs/ip_vs_wlc.c
index bbddfdb..8e94256 100644
--- a/net/netfilter/ipvs/ip_vs_wlc.c
+++ b/net/netfilter/ipvs/ip_vs_wlc.c
@@ -19,9 +19,6 @@
  *
  */
 
-#define KMSG_COMPONENT "IPVS"
-#define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
-
 #include <linux/module.h>
 #include <linux/kernel.h>
 
diff --git a/net/netfilter/ipvs/ip_vs_xmit.c b/net/netfilter/ipvs/ip_vs_xmit.c
index 1f2a4e3..92734bb 100644
--- a/net/netfilter/ipvs/ip_vs_xmit.c
+++ b/net/netfilter/ipvs/ip_vs_xmit.c
@@ -23,9 +23,6 @@
  * - the only place where we can see skb->sk != NULL
  */
 
-#define KMSG_COMPONENT "IPVS"
-#define pr_fmt(fmt) KMSG_COMPONENT ": " fmt

^ permalink raw reply related

* [PATCH] smc91x: add devicetree support
From: Thomas Chou @ 2011-01-25  5:59 UTC (permalink / raw)
  To: Grant Likely, Nicolas Pitre
  Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	nios2-dev-1eJk0qcHJCcaeqlQEoCUNoJY59XmG8rH,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA

Signed-off-by: Thomas Chou <thomas-SDxUXYEhEBiCuPEqFHbRBg@public.gmane.org>
---
 drivers/net/smc91x.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/net/smc91x.c b/drivers/net/smc91x.c
index 726df61..d29e18d 100644
--- a/drivers/net/smc91x.c
+++ b/drivers/net/smc91x.c
@@ -81,6 +81,7 @@ static const char version[] =
 #include <linux/ethtool.h>
 #include <linux/mii.h>
 #include <linux/workqueue.h>
+#include <linux/of.h>
 
 #include <linux/netdevice.h>
 #include <linux/etherdevice.h>
@@ -2394,6 +2395,12 @@ static int smc_drv_resume(struct device *dev)
 	return 0;
 }
 
+static const struct of_device_id smc91x_match[] = {
+	{ .compatible = "smsc,smc91x", },
+	{},
+}
+MODULE_DEVICE_TABLE(of, smc91x_match);
+
 static struct dev_pm_ops smc_drv_pm_ops = {
 	.suspend	= smc_drv_suspend,
 	.resume		= smc_drv_resume,
@@ -2406,6 +2413,9 @@ static struct platform_driver smc_driver = {
 		.name	= CARDNAME,
 		.owner	= THIS_MODULE,
 		.pm	= &smc_drv_pm_ops,
+#ifdef CONFIG_OF
+		.of_match_table = smc91x_match,
+#endif
 	},
 };
 
-- 
1.7.3.5

^ permalink raw reply related

* Re: [PATCH] IPVS: Remove unused pr_fmt #define
From: David Miller @ 2011-01-25  5:24 UTC (permalink / raw)
  To: horms; +Cc: netfilter-devel, netdev, lvs-devel, joe
In-Reply-To: <1295932553-13854-1-git-send-email-horms@verge.net.au>

From: Simon Horman <horms@verge.net.au>
Date: Tue, 25 Jan 2011 15:15:53 +1000

> Cc: Joe Perches <joe@perches.com>
> Signed-off-by: Simon Horman <horms@verge.net.au>

Isn't it used by IP_VS_DBG?

^ permalink raw reply

* Re: [PATCH 18/79] IPVS: Remove useless { } block from ip_vs_process_message()
From: Simon Horman @ 2011-01-25  5:16 UTC (permalink / raw)
  To: Joe Perches; +Cc: kaber, davem, netfilter-devel, netdev
In-Reply-To: <20110125020959.GB7420@verge.net.au>

On Tue, Jan 25, 2011 at 12:10:00PM +1000, Simon Horman wrote:
> On Wed, Jan 19, 2011 at 11:40:52AM -0800, Joe Perches wrote:
> > On Wed, 2011-01-19 at 20:14 +0100, kaber@trash.net wrote:
> > > From: Simon Horman <horms@verge.net.au>
> > >  net/netfilter/ipvs/ip_vs_sync.c |   24 +++++++++++-------------
> > > diff --git a/net/netfilter/ipvs/ip_vs_sync.c b/net/netfilter/ipvs/ip_vs_sync.c
> > > @@ -381,20 +381,18 @@ static void ip_vs_process_message(const char *buffer, const size_t buflen)
> > >  			}
> > >  		}
> > >  
> > > -		{
> > > -			if (ip_vs_conn_fill_param_sync(AF_INET, s->protocol,
> > > -					      (union nf_inet_addr *)&s->caddr,
> > > -					      s->cport,
> > > -					      (union nf_inet_addr *)&s->vaddr,
> > > -					      s->vport, &param)) {
> > > -				pr_err("ip_vs_conn_fill_param_sync failed");
> > > -				return;
> > > -			}
> > > -			if (!(flags & IP_VS_CONN_F_TEMPLATE))
> > > -				cp = ip_vs_conn_in_get(&param);
> > > -			else
> > > -				cp = ip_vs_ct_in_get(&param);
> > > +		if (ip_vs_conn_fill_param_sync(AF_INET, s->protocol,
> > > +					       (union nf_inet_addr *)&s->caddr,
> > > +					       s->cport,
> > > +					       (union nf_inet_addr *)&s->vaddr,
> > > +					       s->vport, &param)) {
> > > +			pr_err("ip_vs_conn_fill_param_sync failed");
> > 
> > The original and this pr_err is missing a \n before close quote.
> 
> Thanks Joe, I'll get this fixed once nf-next-2.6 opens up again.

On closer inspection this line has subsequently been removed.
I also checked and the string passed to all calls to pr_erri()
in that file end in "\n".

^ permalink raw reply

* [PATCH] IPVS: Remove unused pr_fmt #define
From: Simon Horman @ 2011-01-25  5:15 UTC (permalink / raw)
  To: netfilter-devel, netdev, lvs-devel; +Cc: Simon Horman, Joe Perches

Cc: Joe Perches <joe@perches.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
 net/netfilter/ipvs/ip_vs_app.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/net/netfilter/ipvs/ip_vs_app.c b/net/netfilter/ipvs/ip_vs_app.c
index 5c48ffb..e2a19d0 100644
--- a/net/netfilter/ipvs/ip_vs_app.c
+++ b/net/netfilter/ipvs/ip_vs_app.c
@@ -19,7 +19,6 @@
  */
 
 #define KMSG_COMPONENT "IPVS"
-#define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
 
 #include <linux/module.h>
 #include <linux/kernel.h>
-- 
1.7.2.3


^ permalink raw reply related

* Re: [PATCH] netfilter: ipvs: fix compiler warnings
From: Simon Horman @ 2011-01-25  5:05 UTC (permalink / raw)
  To: Changli Gao
  Cc: Wensong Zhang, Julian Anastasov, Patrick McHardy, David S. Miller,
	netdev, lvs-devel, netfilter-devel
In-Reply-To: <1295930418-14980-1-git-send-email-xiaosuo@gmail.com>

On Tue, Jan 25, 2011 at 12:40:18PM +0800, Changli Gao wrote:
> Fix compiler warnings when IP_VS_DBG() isn't defined.
> 
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>

Thanks, I will queue this up for when nf-next-2.6 is open again.

^ permalink raw reply

* Re: [PATCH] net: add sysfs entry for device group
From: Stephen Hemminger @ 2011-01-25  4:41 UTC (permalink / raw)
  To: Vlad Dogaru; +Cc: netdev
In-Reply-To: <1295876249-15634-1-git-send-email-ddvlad@rosedu.org>

On Mon, 24 Jan 2011 15:37:29 +0200
Vlad Dogaru <ddvlad@rosedu.org> wrote:

> The group of a network device can be queried or changed from userspace
> using sysfs.
> 
> For example, considering sysfs mounted in /sys, one can change the group
> that interface lo belongs to:
> 	echo 1 > /sys/class/net/lo/group
> 
> Signed-off-by: Vlad Dogaru <ddvlad@rosedu.org>

Acked-by: Stephen Hemminger <shemminger@vyatta.com>

^ permalink raw reply

* [PATCH] netfilter: ipvs: fix compiler warnings
From: Changli Gao @ 2011-01-25  4:40 UTC (permalink / raw)
  To: Simon Horman
  Cc: Wensong Zhang, Julian Anastasov, Patrick McHardy, David S. Miller,
	netdev, lvs-devel, netfilter-devel, Changli Gao

Fix compiler warnings when IP_VS_DBG() isn't defined.

Signed-off-by: Changli Gao <xiaosuo@gmail.com>
---
 net/netfilter/ipvs/ip_vs_core.c  |    4 +---
 3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index f36a84f..d889f4f 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -1894,9 +1894,7 @@ static int __net_init __ip_vs_init(struct net *net)
 
 static void __net_exit __ip_vs_cleanup(struct net *net)
 {
-	struct netns_ipvs *ipvs = net_ipvs(net);

^ permalink raw reply related

* RE: [PATCH net-next-2.6 v5 1/1] can: c_can: Added support for Bosch C_CAN controller
From: Bhupesh SHARMA @ 2011-01-25  4:36 UTC (permalink / raw)
  To: Wolfgang Grandegger
  Cc: Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Marc Kleine-Budde,
	David Miller
In-Reply-To: <4D3B2F66.8090603-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>

Hi Wolfgang,

Thanks for your review.
Please see my comments inline:

> Hi Bhupesh,
> 
> at a closer look, I realized one more issue, apart from some minor
> ones...
> 
> On 01/20/2011 10:20 AM, Bhupesh Sharma wrote:
> > Bosch C_CAN controller is a full-CAN implementation which is
> compliant
> > to CAN protocol version 2.0 part A and B. Bosch C_CAN user manual can
> be
> > obtained from:
> > http://www.semiconductors.bosch.de/media/en/pdf/ipmodules_1/
> > c_can/users_manual_c_can.pdf
> >
> > This patch adds the support for this controller.
> > The following are the design choices made while writing the
> controller
> > driver:
> > 1. Interface Register set IF1 has be used only in the current design.
> > 2. Out of the 32 Message objects available, 16 are kept aside for RX
> >    purposes and the rest for TX purposes.
> > 3. NAPI implementation is such that both the TX and RX paths function
> >    in polling mode.
> >
> > Signed-off-by: Bhupesh Sharma <bhupesh.sharma-qxv4g6HH51o@public.gmane.org>
> > ---
> > Changes since V4:
> > 	1. Insured correct ISR implementation to allow shared IRQs.
> > 	2. To ensure better understanding of message object numbers
> > 	   and thierusage modified C_CAN_MSG_OBJ_RX_FIRST value from 0
> 
> Typo!

Ok :)

> > 	   to 1.
> > 	3. Corrected coding style globally.
> > 	4. Renamed Interface registers as *ifregs*.
> >
> >  drivers/net/can/Kconfig                |    2 +
> >  drivers/net/can/Makefile               |    1 +
> >  drivers/net/can/c_can/Kconfig          |   15 +
> >  drivers/net/can/c_can/Makefile         |    8 +
> >  drivers/net/can/c_can/c_can.c          |  958
> ++++++++++++++++++++++++++++++++
> >  drivers/net/can/c_can/c_can.h          |  229 ++++++++
> >  drivers/net/can/c_can/c_can_platform.c |  207 +++++++
> >  7 files changed, 1420 insertions(+), 0 deletions(-)
> >  create mode 100644 drivers/net/can/c_can/Kconfig
> >  create mode 100644 drivers/net/can/c_can/Makefile
> >  create mode 100644 drivers/net/can/c_can/c_can.c
> >  create mode 100644 drivers/net/can/c_can/c_can.h
> >  create mode 100644 drivers/net/can/c_can/c_can_platform.c
> >
> > diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
> > index 9d9e453..50549b5 100644
> > --- a/drivers/net/can/Kconfig
> > +++ b/drivers/net/can/Kconfig
> > @@ -86,6 +86,8 @@ source "drivers/net/can/mscan/Kconfig"
> >
> >  source "drivers/net/can/sja1000/Kconfig"
> >
> > +source "drivers/net/can/c_can/Kconfig"
> > +
> >  source "drivers/net/can/usb/Kconfig"
> >
> >  config CAN_DEBUG_DEVICES
> > diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile
> > index 0057537..c3efeb3 100644
> > --- a/drivers/net/can/Makefile
> > +++ b/drivers/net/can/Makefile
> > @@ -11,6 +11,7 @@ obj-y				+= usb/
> >
> >  obj-$(CONFIG_CAN_SJA1000)	+= sja1000/
> >  obj-$(CONFIG_CAN_MSCAN)		+= mscan/
> > +obj-$(CONFIG_CAN_C_CAN)		+= c_can/
> >  obj-$(CONFIG_CAN_AT91)		+= at91_can.o
> >  obj-$(CONFIG_CAN_TI_HECC)	+= ti_hecc.o
> >  obj-$(CONFIG_CAN_MCP251X)	+= mcp251x.o
> > diff --git a/drivers/net/can/c_can/Kconfig
> b/drivers/net/can/c_can/Kconfig
> > new file mode 100644
> > index 0000000..ffb9773
> > --- /dev/null
> > +++ b/drivers/net/can/c_can/Kconfig
> > @@ -0,0 +1,15 @@
> > +menuconfig CAN_C_CAN
> > +	tristate "Bosch C_CAN devices"
> > +	depends on CAN_DEV && HAS_IOMEM
> > +
> > +if CAN_C_CAN
> > +
> > +config CAN_C_CAN_PLATFORM
> > +	tristate "Generic Platform Bus based C_CAN driver"
> > +	---help---
> > +	  This driver adds support for the C_CAN chips connected to
> > +	  the "platform bus" (Linux abstraction for directly to the
> > +	  processor attached devices) which can be found on various
> > +	  boards from ST Microelectronics (http://www.st.com)
> > +	  like the SPEAr1310 and SPEAr320 evaluation boards.
> > +endif
> > diff --git a/drivers/net/can/c_can/Makefile
> b/drivers/net/can/c_can/Makefile
> > new file mode 100644
> > index 0000000..9273f6d
> > --- /dev/null
> > +++ b/drivers/net/can/c_can/Makefile
> > @@ -0,0 +1,8 @@
> > +#
> > +#  Makefile for the Bosch C_CAN controller drivers.
> > +#
> > +
> > +obj-$(CONFIG_CAN_C_CAN) += c_can.o
> > +obj-$(CONFIG_CAN_C_CAN_PLATFORM) += c_can_platform.o
> > +
> > +ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG
> > diff --git a/drivers/net/can/c_can/c_can.c
> b/drivers/net/can/c_can/c_can.c
> > new file mode 100644
> > index 0000000..66a400b
> > --- /dev/null
> > +++ b/drivers/net/can/c_can/c_can.c
> 
> ...
> 
> > +static void c_can_handle_lost_msg_obj(struct net_device *dev,
> > +					int iface, int objno)
> > +{
> > +	struct c_can_priv *priv = netdev_priv(dev);
> > +	struct net_device_stats *stats = &dev->stats;
> > +	struct sk_buff *skb;
> > +	struct can_frame *frame;
> > +
> > +	netdev_err(dev, "msg lost in buffer %d\n", objno);
> > +
> > +	c_can_object_get(dev, iface, objno, IF_COMM_ALL &
> > +						~IF_COMM_TXRQST);
> 
> Does fit on one line.

OK.

> ...
> 
> > +static void c_can_inval_msg_object(struct net_device *dev, int
> iface, int objno)
> > +{
> > +	struct c_can_priv *priv = netdev_priv(dev);
> > +
> > +	priv->write_reg(priv, &priv->regs->ifregs[iface].arb1, 0);
> > +	priv->write_reg(priv, &priv->regs->ifregs[iface].arb2, 0);
> > +	priv->write_reg(priv, &priv->regs->ifregs[iface].msg_cntrl, 0);
> > +
> > +	c_can_object_put(dev, iface, objno,
> > +				IF_COMM_ARB | IF_COMM_CONTROL);
> 
> Ditto

Ok.

> ...
> 
> > +static inline int c_can_has_and_handle_berr(struct c_can_priv *priv)
> > +{
> > +	return (priv->can.ctrlmode & CAN_CTRLMODE_BERR_REPORTING) &&
> > +		(priv->current_status & STATUS_LEC_MASK);
> > +}
> > +
> > +static int c_can_err(struct net_device *dev,
> > +				enum c_can_bus_error_types error_type,
> > +				enum c_can_lec_type lec_type)
> > +{
> > +	unsigned int reg_err_counter;
> > +	unsigned int rx_err_passive;
> > +	struct c_can_priv *priv = netdev_priv(dev);
> > +	struct net_device_stats *stats = &dev->stats;
> > +	struct can_frame *cf;
> > +	struct sk_buff *skb;
> > +	struct can_berr_counter bec;
> > +
> > +	/* propogate the error condition to the CAN stack */
> > +	skb = alloc_can_err_skb(dev, &cf);
> > +	if (unlikely(!skb))
> > +		return 0;
> > +
> > +	c_can_get_berr_counter(dev, &bec);
> > +	reg_err_counter = priv->read_reg(priv, &priv->regs->err_cnt);
> > +	rx_err_passive = (reg_err_counter & ERR_CNT_RP_MASK) >>
> > +				ERR_CNT_RP_SHIFT;
> > +
> > +	if (error_type & C_CAN_ERROR_WARNING) {
> > +		/* error warning state */
> > +		priv->can.can_stats.error_warning++;
> > +		priv->can.state = CAN_STATE_ERROR_WARNING;
> > +		cf->can_id |= CAN_ERR_CRTL;
> > +		if (bec.rxerr > 96)
> > +			cf->data[1] |= CAN_ERR_CRTL_RX_WARNING;
> > +		if (bec.txerr > 96)
> > +			cf->data[1] |= CAN_ERR_CRTL_TX_WARNING;
> > +	}
> > +	if (error_type & C_CAN_ERROR_PASSIVE) {
> > +		/* error passive state */
> > +		priv->can.can_stats.error_passive++;
> > +		priv->can.state = CAN_STATE_ERROR_PASSIVE;
> > +		cf->can_id |= CAN_ERR_CRTL;
> > +		if (rx_err_passive)
> > +			cf->data[1] |= CAN_ERR_CRTL_RX_PASSIVE;
> > +		if (bec.txerr > 127)
> > +			cf->data[1] |= CAN_ERR_CRTL_TX_PASSIVE;
> > +	}
> > +	if (error_type & C_CAN_BUS_OFF) {
> > +		/* bus-off state */
> > +		priv->can.state = CAN_STATE_BUS_OFF;
> > +		cf->can_id |= CAN_ERR_BUSOFF;
> > +		/*
> > +		 * disable all interrupts in bus-off mode to ensure that
> > +		 * the CPU is not hogged down
> > +		 */
> > +		c_can_enable_all_interrupts(priv, DISABLE_ALL_INTERRUPTS);
> > +		can_bus_off(dev);
> > +	}
> > +
> > +	/*
> > +	 * check for 'last error code' which tells us the
> > +	 * type of the last error to occur on the CAN bus
> > +	 */
> > +
> > +	/* common for all type of bus errors */
> > +	priv->can.can_stats.bus_error++;
> 
> Does a state change always come together with a bus error?
> 
> > +	stats->rx_errors++;
> > +	cf->can_id |= CAN_ERR_PROT | CAN_ERR_BUSERROR;
> > +	cf->data[2] |= CAN_ERR_PROT_UNSPEC;
> > +
> > +	switch (lec_type) {
> > +	case LEC_STUFF_ERROR:
> > +		netdev_dbg(dev, "stuff error\n");
> > +		cf->data[2] |= CAN_ERR_PROT_STUFF;
> > +		break;
> > +
> > +	case LEC_FORM_ERROR:
> > +		netdev_dbg(dev, "form error\n");
> > +		cf->data[2] |= CAN_ERR_PROT_FORM;
> > +		break;
> > +
> > +	case LEC_ACK_ERROR:
> > +		netdev_dbg(dev, "ack error\n");
> > +		cf->data[2] |= (CAN_ERR_PROT_LOC_ACK |
> > +				CAN_ERR_PROT_LOC_ACK_DEL);
> > +		break;
> > +
> > +	case LEC_BIT1_ERROR:
> > +		netdev_dbg(dev, "bit1 error\n");
> > +		cf->data[2] |= CAN_ERR_PROT_BIT1;
> > +		break;
> > +
> > +	case LEC_BIT0_ERROR:
> > +		netdev_dbg(dev, "bit0 error\n");
> > +		cf->data[2] |= CAN_ERR_PROT_BIT0;
> > +		break;
> > +
> > +	case LEC_CRC_ERROR:
> > +		netdev_dbg(dev, "CRC error\n");
> > +		cf->data[2] |= (CAN_ERR_PROT_LOC_CRC_SEQ |
> > +				CAN_ERR_PROT_LOC_CRC_DEL);
> > +		break;
> > +	}
> 
> From the C_CAN manual:
> 
> "The LEC field holds a code which indicates the type of the last error
> to occur on the CAN bus. This field will be cleared to '0' when a
> message has been transferred (reception or transmission) without error.
> The unused code '7' may be written by the CPU to check for updates."
> 
> Not sure if it's necessary to reset the lec at init and after an error
> to 0x7 and check it. More below...

Hmm.. The default value of Status Register is 0x0 at INIT so I am not
sure if LEC needs to be reset at init. However using the unused code
0x7 seems necessary to check for updates as per specs.
I will modify the same in V6.

> > +	netif_receive_skb(skb);
> > +	stats->rx_packets++;
> > +	stats->rx_bytes += cf->can_dlc;
> > +
> > +	return 1;
> > +}
> > +
> > +static int c_can_poll(struct napi_struct *napi, int quota)
> > +{
> > +	u16 irqstatus;
> > +	int lec_type = 0;
> > +	int work_done = 0;
> > +	struct net_device *dev = napi->dev;
> > +	struct c_can_priv *priv = netdev_priv(dev);
> > +	enum c_can_bus_error_types error_type = C_CAN_NO_ERROR;
> > +
> > +	irqstatus = priv->read_reg(priv, &priv->regs->interrupt);
> > +	if (!irqstatus)
> > +		goto end;
> > +
> > +	/* status events have the highest priority */
> > +	if (irqstatus == STATUS_INTERRUPT) {
> > +		priv->current_status = priv->read_reg(priv,
> > +					&priv->regs->status);
> > +
> > +		/* handle Tx/Rx events */
> > +		if (priv->current_status & STATUS_TXOK)
> > +			priv->write_reg(priv, &priv->regs->status,
> > +					priv->current_status & ~STATUS_TXOK);
> > +
> > +		if (priv->current_status & STATUS_RXOK)
> > +			priv->write_reg(priv, &priv->regs->status,
> > +					priv->current_status & ~STATUS_RXOK);
> > +
> > +		/* handle bus error events */
> > +		if (priv->current_status & STATUS_EWARN) {
> > +			netdev_dbg(dev,
> > +					"entered error warning state\n");
> 
> Does fit on one line.

OK.

> > +			error_type = C_CAN_ERROR_WARNING;
> > +		}
> > +		if ((priv->current_status & STATUS_EPASS) &&
> > +				(!(priv->last_status & STATUS_EPASS))) {
> > +			netdev_dbg(dev,
> > +					"entered error passive state\n");
> 
> Ditto.

OK.

> > +			error_type = C_CAN_ERROR_PASSIVE;
> > +		}
> > +		if ((priv->current_status & STATUS_BOFF) &&
> > +				(!(priv->last_status & STATUS_BOFF))) {
> > +			netdev_dbg(dev,
> > +					"entered bus off state\n");
> 
> Ditto.

OK.

> > +			error_type = C_CAN_BUS_OFF;
> > +		}
> > +
> > +		/* handle bus recovery events */
> > +		if ((!(priv->current_status & STATUS_EPASS)) &&
> > +				(priv->last_status & STATUS_EPASS)) {
> > +			netdev_dbg(dev,
> > +					"left error passive state\n");
> 
> Ditto.

OK.

> > +			priv->can.state = CAN_STATE_ERROR_ACTIVE;
> > +		}
> > +		if ((!(priv->current_status & STATUS_BOFF)) &&
> > +				(priv->last_status & STATUS_BOFF)) {
> > +			netdev_dbg(dev,
> > +					"left bus off state\n");
> > +			priv->can.state = CAN_STATE_ERROR_ACTIVE;
> > +		}
> > +
> > +		priv->last_status = priv->current_status;
> > +
> > +		/* handle error on the bus */
> > +		lec_type = c_can_has_and_handle_berr(priv);
> > +		if (lec_type && (error_type != C_CAN_NO_ERROR))
> > +			work_done += c_can_err(dev, error_type, lec_type);
> 
> State changes are only reported if berr_reporting is enabled and a bus
> error occured. This needs to be fixed.

As I mentioned earlier in a response to a review comment, the Bus Error
reporting for C_CAN seems different from sja1000 and flexcan approaches.
Do you think it will be useful to drop CAN_CTRLMODE_BERR_REPORTING from
priv->can.ctrlmode_supported as done by *pch* driver? Or do you have
a better idea..

> Feel free to send the output of "candump any,0:0,#FFFFFFFF" when
> sending
> messages without cable connected and with a bus error provocuted.

OK. I will try to cross-compile candump for my arm-v7 architecture
and will send the output.
 
> Apart form that the patch looks really good.

:)

> Wolfgang.

Regards,
Bhupesh

^ permalink raw reply

* Re: [PATCH] net: remove tests on 64bit platforms
From: Ben Hutchings @ 2011-01-25  4:28 UTC (permalink / raw)
  To: Changli Gao
  Cc: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
	James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev
In-Reply-To: <1295929298-13163-1-git-send-email-xiaosuo@gmail.com>

On Tue, 2011-01-25 at 12:21 +0800, Changli Gao wrote:
> On 64bit platforms, >31 bit shifting of a unsigned long variable is
> valid, so we can remove the related boundary tests, which may slow
> down the CPU if branch prediction fails.
[...]

It seems like it would be better to define generic shift functions that
correctly handle the case of a shift count >= word size.  There are many
places these would be useful.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


^ permalink raw reply

* [PATCH] net: remove tests on 64bit platforms
From: Changli Gao @ 2011-01-25  4:21 UTC (permalink / raw)
  To: David S. Miller
  Cc: Alexey Kuznetsov, Pekka Savola (ipv6), James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy, netdev, Changli Gao

On 64bit platforms, >31 bit shifting of a unsigned long variable is
valid, so we can remove the related boundary tests, which may slow
down the CPU if branch prediction fails.

The size of text becomes smaller:
before:
   text	   data	    bss	    dec	    hex	filename
  15721	     16	     16	  15753	   3d89	net/ipv4/fib_trie.o
after:
   text	   data	    bss	    dec	    hex	filename
  15656	     16	     16	  15688	   3d48	net/ipv4/fib_trie.o

Signed-off-by: Changli Gao <xiaosuo@gmail.com>
---
 net/ipv4/fib_trie.c |    8 ++++++++
 1 file changed, 8 insertions(+)
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index 0f28034..95c8bb3 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -219,15 +219,23 @@ static inline int tnode_child_length(const struct tnode *tn)
 
 static inline t_key mask_pfx(t_key k, unsigned short l)
 {
+#if BITS_PER_LONG > 32
+	return ((u64)k) >> (KEYLENGTH-l) << (KEYLENGTH-l);
+#else
 	return (l == 0) ? 0 : k >> (KEYLENGTH-l) << (KEYLENGTH-l);
+#endif
 }
 
 static inline t_key tkey_extract_bits(t_key a, int offset, int bits)
 {
+#if BITS_PER_LONG > 32
+	return (t_key)((u64)a << offset) >> (KEYLENGTH - bits);
+#else
 	if (offset < KEYLENGTH)
 		return ((t_key)(a << offset)) >> (KEYLENGTH - bits);
 	else
 		return 0;
+#endif
 }
 
 static inline int tkey_equals(t_key a, t_key b)

^ permalink raw reply related

* Re: does intel X520-SR(ixgbe) support RSS on single VLAN?
From: Ben Hutchings @ 2011-01-25  3:05 UTC (permalink / raw)
  To: Rui
  Cc: Alexander Duyck, netdev@vger.kernel.org,
	e1000-devel@lists.sourceforge.net
In-Reply-To: <AANLkTimFuUp+wbgJY4koZ96st1eBbFqVOxOPj4tU_-Ao@mail.gmail.com>

On Tue, 2011-01-25 at 10:10 +0800, Rui wrote:
> On Tue, Jan 25, 2011 at 1:09 AM, Alexander Duyck
> <alexander.h.duyck@intel.com> wrote:
> > On 1/24/2011 6:18 AM, Rui wrote:
> >>
> >> hi
> >> does intel X520-SR support RSS on single VLAN?
> >>
> >> tested with 3 different vlan id and priority packets
> >> What I saw is that all packets were always delivered to the same RxQ.
> >> looks can not get a different RSS index for these packet?
> >> any setting needed?
> >> --
> >> 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
> >
> > The X520 should have no problems hashing on a single VLAN tagged frame.
> >  However the VLAN will not be a part of the RSS hash.  The  only components
> > of the hash are the IPv4/IPv6 source and destination addresses, and if the
> > flow is TCP then the port numbers.
> >
> hi alexander
> I got these information from the intel community:
> 
> 'I asked our software engineers about your question, and this is what I learned.
> You cannot filter by just VLAN or VLAN priority.  The L4 type will
> also play a role in the filter and as such you would only be able to
> filter TCP, UDP, and SCTP packets that are bound for a VLAN.
> The command itself to setup a filter is “ethtool –U ethX flow-type
> tcp4 vlan 0x2000 vlan-mask 0xE000 action Y” where X is the correct
> index for the interface and Y is the queue you want to route the
> traffic to.  This would have to be repeated for udp4 and sctp4.
> I hope this will help.
> Mark H"

The mask specifies bits to be ignored, so if you want to filter on the
basis of only the priority bits you should use vlan-mask 0xfff.  Unless
this is another inconsistency I failed to notice...

> so my question is that the VLAN is PART of the RSS or not?

It's not part of any specified Toeplitz hash.  However, some hardware
supports adding the hash (after indirection) to the queue number
specified by a filter.  Currently the ethtool API doesn't have a way to
request that.

> looks the
> perfect filter support vlan id ?can the perfect filter support
> wildchar,such as: flow-type ANY?

It is possible to specify this using flow-type ether, but the ixgbe
driver does not yet support that (and I have no idea whether the
hardware does).

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


^ permalink raw reply

* Re: [PATCH v4] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Po-Yu Chuang @ 2011-01-25  2:46 UTC (permalink / raw)
  To: Michał Mirosław
  Cc: netdev, linux-kernel, bhutchings, eric.dumazet, joe, dilinger,
	Po-Yu Chuang
In-Reply-To: <AANLkTimWuBfeYPOsOFpTiAGS5uHysevAHiOg0svBQ4zW@mail.gmail.com>

Dear Michał,

2011/1/25 Michał Mirosław <mirqus@gmail.com>:
> W dniu 24 stycznia 2011 09:26 użytkownik Po-Yu Chuang
> <ratbert.chuang@gmail.com> napisał:
>> 2011/1/21 Michał Mirosław <mirqus@gmail.com>:
>>> Did you test this? This looks like it will result in double free after
>>> packet RX, as you are giving the same page (referenced once) to two
>>> distinct RX descriptors, that may be assigned different packets.
>>
>> Yes, this is tested.
>>
>>> Since your not implementing any RX offloads, you might just allocate
>>> fresh skb's with alloc_skb() and store skb pointer in rxdes3. Since
>>
>> rxdes3 does not store virtual address of an skb.
>> It stores the address of the buffer allocated while open() and freed
>> only when stop().
>> The data in that buffer will be memcpy()ed to an skb allocated in
>> ftmac100_rx_packet().
>> No double free happens.
>
> Ah, I blindly assumed that you're just appending the buffers to the
> skb (using skb_fill_page_desc() and friends). Since you have to mark
> descriptors for the device anyway, it might be faster to allocate new
> skbs and map those as rx buffers (changing the descriptor's buffer
> address after every RX) instead of keeping static buffer and copying
> every time. (For small packets it wastes lot of memory, though - so
> the right choice depends on the expected workload.)

The reason I chose to use memcpy rx buffer to skb is that I didn't know
how to deal with multi-segment packets if I preallocated skb for each
rx descriptor. This function seems to be what I need.
Let me rework this. Thanks.

best regards,
Po-Yu Chuang

^ permalink raw reply

* Re: [PATCH v5] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Po-Yu Chuang @ 2011-01-25  2:46 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: netdev, linux-kernel, bhutchings, joe, dilinger, mirqus,
	Po-Yu Chuang
In-Reply-To: <1295881662.2755.34.camel@edumazet-laptop>

Dear Eric,

On Mon, Jan 24, 2011 at 11:07 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 24 janvier 2011 à 20:39 +0800, Po-Yu Chuang a écrit :
>> From: Po-Yu Chuang <ratbert@faraday-tech.com>
>> +
>> +     priv->tx_pending++;
>> +     if (priv->tx_pending == TX_QUEUE_ENTRIES) {
>> +             if (net_ratelimit())
>> +                     netdev_info(netdev, "tx queue full\n");
>
> Hmm, I guess you didnt tested your driver with a pktgen flood ;)
>
> This 'netdev_info(netdev, "tx queue full\n");' is not necessary, since
> its a pretty normal condition for a driver (to fill its TX ring buffer)

Errr... No, I didn't test it with pktgen. I tested it with normal NFS usages.
I'll try it.

best regards,
Po-Yu Chuang

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox