* Re: [PATCH net-next] sockopt: Change getsockopt() of SO_BINDTODEVICE to return an interface name
From: Eric Dumazet @ 2012-11-02 10:23 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: Brian Haley, David Miller, netdev@vger.kernel.org
In-Reply-To: <5093940B.6020207@parallels.com>
On Fri, 2012-11-02 at 13:36 +0400, Pavel Emelyanov wrote:
> This still races with the device name change, potentially providing
> a name which never existed in the system, doesn't it?
It does.
Maybe add a seqlock_t, to avoid taking rtnl here.
(as it could bring interesting lockdep/deadlock issues)
Here is the write side. Read side is trivial.
diff --git a/net/core/dev.c b/net/core/dev.c
index b4978e2..0184ec9 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -201,6 +201,8 @@ static struct list_head ptype_all __read_mostly; /* Taps */
DEFINE_RWLOCK(dev_base_lock);
EXPORT_SYMBOL(dev_base_lock);
+DEFINE_SEQLOCK(devnet_rename_seq);
+
static inline void dev_base_seq_inc(struct net *net)
{
while (++net->dev_base_seq == 0);
@@ -1018,17 +1020,22 @@ int dev_change_name(struct net_device *dev, const char *newname)
memcpy(oldname, dev->name, IFNAMSIZ);
+ write_seqlock(&devnet_rename_seq);
err = dev_get_valid_name(net, dev, newname);
- if (err < 0)
+ if (err < 0) {
+ write_sequnlock(&devnet_rename_seq);
return err;
-
+ }
rollback:
ret = device_rename(&dev->dev, dev->name);
if (ret) {
memcpy(dev->name, oldname, IFNAMSIZ);
+ write_sequnlock(&devnet_rename_seq);
return ret;
}
+ write_sequnlock(&devnet_rename_seq);
+
write_lock_bh(&dev_base_lock);
hlist_del_rcu(&dev->name_hlist);
write_unlock_bh(&dev_base_lock);
@@ -1046,6 +1053,7 @@ rollback:
/* err >= 0 after dev_alloc_name() or stores the first errno */
if (err >= 0) {
err = ret;
+ write_seqlock(&devnet_rename_seq);
memcpy(dev->name, oldname, IFNAMSIZ);
goto rollback;
} else {
^ permalink raw reply related
* [PATCH net-next] ptp: fixup Kconfig for two PHC drivers.
From: Richard Cochran @ 2012-11-02 9:57 UTC (permalink / raw)
To: netdev; +Cc: David Miller
Ben Hutchings recently came up with a better way to handle the kconfig
dependencies for the PTP hardware clocks. This patch converts one new and
one older driver to the new scheme.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
---
drivers/net/ethernet/adi/Kconfig | 2 +-
drivers/net/ethernet/ti/Kconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/adi/Kconfig b/drivers/net/ethernet/adi/Kconfig
index 175c38c..e49c0ef 100644
--- a/drivers/net/ethernet/adi/Kconfig
+++ b/drivers/net/ethernet/adi/Kconfig
@@ -61,7 +61,7 @@ config BFIN_RX_DESC_NUM
config BFIN_MAC_USE_HWSTAMP
bool "Use IEEE 1588 hwstamp"
- depends on BFIN_MAC && BF518 && PTP_1588_CLOCK && !(BFIN_MAC=y && PTP_1588_CLOCK=m)
+ select PTP_1588_CLOCK
default y
---help---
To support the IEEE 1588 Precision Time Protocol (PTP), select y here
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index cbc3905..14297ff 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -62,7 +62,7 @@ config TI_CPSW
config TI_CPTS
boolean "TI Common Platform Time Sync (CPTS) Support"
- depends on TI_CPSW && PTP_1588_CLOCK && !(TI_CPSW=y && PTP_1588_CLOCK=m)
+ select PTP_1588_CLOCK
---help---
This driver supports the Common Platform Time Sync unit of
the CPSW Ethernet Switch. The unit can time stamp PTP UDP/IPv4
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH v2 2/3] pppoatm: fix race condition with destroying of vcc
From: Krzysztof Mazur @ 2012-11-02 9:40 UTC (permalink / raw)
To: chas williams - CONTRACTOR; +Cc: davem, dwmw2, netdev, linux-kernel
In-Reply-To: <20121101102628.6e3d3cae@thirdoffive.cmf.nrl.navy.mil>
On Thu, Nov 01, 2012 at 10:26:28AM -0400, chas williams - CONTRACTOR wrote:
> On Wed, 31 Oct 2012 23:04:35 +0100
> Krzysztof Mazur <krzysiek@podlesie.net> wrote:
>
> > There are also some minor potential issues in pppoatm driver:
> >
> > - locking issues, but now only between pppoatm_send() and
> > vcc_sendmsg() and maybe some other functions,
>
> these have been around for a while. i agree that something should be
> done about it. just not sure what should be synchronizing this mess.
I think the ATM socket lock should be used. I'm sending the latest
patch that adds this locking after David Woodhouse's comments. The vcc->flags
check is now probably unnecessary.
>
> > - missing check for SS_CONNECTED in pppoatm_ioctl,
>
> in practice you will never run into this because a pvc is immediately
> put into SS_CONNECTED mode (right before the userspace open()
> returns). however, should it check? yes. i dont see anything
> preventing you from running ppp on svc's.
I can confirm that the problem really exists, without connect() in pppoatm
plugin in pppd, I have seen an Oops and panic. I will send appropriate
patch.
Thanks.
Krzysiek
-- >8 --
diff --git a/net/atm/pppoatm.c b/net/atm/pppoatm.c
index f27a07a..ef19436 100644
--- a/net/atm/pppoatm.c
+++ b/net/atm/pppoatm.c
@@ -269,10 +269,23 @@ static inline int pppoatm_may_send(struct pppoatm_vcc *pvcc, int size)
static int pppoatm_send(struct ppp_channel *chan, struct sk_buff *skb)
{
struct pppoatm_vcc *pvcc = chan_to_pvcc(chan);
+ struct atm_vcc *vcc;
+ int ret;
+
ATM_SKB(skb)->vcc = pvcc->atmvcc;
pr_debug("(skb=0x%p, vcc=0x%p)\n", skb, pvcc->atmvcc);
if (skb->data[0] == '\0' && (pvcc->flags & SC_COMP_PROT))
(void) skb_pull(skb, 1);
+
+ vcc = ATM_SKB(skb)->vcc;
+ bh_lock_sock(sk_atm(vcc));
+ if (sock_owned_by_user(sk_atm(vcc)))
+ goto nospace;
+ if (test_bit(ATM_VF_RELEASED, &vcc->flags)
+ || test_bit(ATM_VF_CLOSE, &vcc->flags)
+ || !test_bit(ATM_VF_READY, &vcc->flags))
+ goto nospace;
+
switch (pvcc->encaps) { /* LLC encapsulation needed */
case e_llc:
if (skb_headroom(skb) < LLC_LEN) {
@@ -285,8 +298,10 @@ static int pppoatm_send(struct ppp_channel *chan, struct sk_buff *skb)
}
consume_skb(skb);
skb = n;
- if (skb == NULL)
+ if (skb == NULL) {
+ bh_unlock_sock(sk_atm(vcc));
return DROP_PACKET;
+ }
} else if (!pppoatm_may_send(pvcc, skb->truesize))
goto nospace;
memcpy(skb_push(skb, LLC_LEN), pppllc, LLC_LEN);
@@ -296,6 +311,7 @@ static int pppoatm_send(struct ppp_channel *chan, struct sk_buff *skb)
goto nospace;
break;
case e_autodetect:
+ bh_unlock_sock(sk_atm(vcc));
pr_debug("Trying to send without setting encaps!\n");
kfree_skb(skb);
return 1;
@@ -305,9 +321,12 @@ static int pppoatm_send(struct ppp_channel *chan, struct sk_buff *skb)
ATM_SKB(skb)->atm_options = ATM_SKB(skb)->vcc->atm_options;
pr_debug("atm_skb(%p)->vcc(%p)->dev(%p)\n",
skb, ATM_SKB(skb)->vcc, ATM_SKB(skb)->vcc->dev);
- return ATM_SKB(skb)->vcc->send(ATM_SKB(skb)->vcc, skb)
+ ret = ATM_SKB(skb)->vcc->send(ATM_SKB(skb)->vcc, skb)
? DROP_PACKET : 1;
+ bh_unlock_sock(sk_atm(vcc));
+ return ret;
nospace:
+ bh_unlock_sock(sk_atm(vcc));
/*
* We don't have space to send this SKB now, but we might have
* already applied SC_COMP_PROT compression, so may need to undo
^ permalink raw reply related
* Re: [PATCH net-next] sockopt: Change getsockopt() of SO_BINDTODEVICE to return an interface name
From: Pavel Emelyanov @ 2012-11-02 9:36 UTC (permalink / raw)
To: Brian Haley; +Cc: David Miller, Eric Dumazet, netdev@vger.kernel.org
In-Reply-To: <509184D9.8030103@hp.com>
> +static int sock_getbindtodevice(struct sock *sk, char __user *optval,
> + int __user *optlen, int len)
> +{
> + int ret = -ENOPROTOOPT;
> +#ifdef CONFIG_NETDEVICES
> + struct net *net = sock_net(sk);
> + struct net_device *dev;
> + char devname[IFNAMSIZ];
> +
> + if (sk->sk_bound_dev_if == 0) {
> + len = 0;
> + goto zero;
> + }
> +
> + ret = -EINVAL;
> + if (len < IFNAMSIZ)
> + goto out;
> +
> + rcu_read_lock();
> + dev = dev_get_by_index_rcu(net, sk->sk_bound_dev_if);
> + if (dev)
> + strcpy(devname, dev->name);
This still races with the device name change, potentially providing
a name which never existed in the system, doesn't it?
> + rcu_read_unlock();
> + ret = -ENODEV;
> + if (!dev)
> + goto out;
> +
> + len = strlen(devname) + 1;
> +
> + ret = -EFAULT;
> + if (copy_to_user(optval, devname, len))
> + goto out;
> +
> +zero:
> + ret = -EFAULT;
> + if (put_user(len, optlen))
> + goto out;
> +
> + ret = 0;
> +
> +out:
> +#endif
> +
> + return ret;
> +}
Thanks,
Pavel
^ permalink raw reply
* [PATCH] net-ipv6: change %8s to %s for rt->dst.dev->name in seq_printf of rt6_info_route
From: Chen Gang @ 2012-11-02 9:28 UTC (permalink / raw)
To: Eric Dumazet, netdev
In-Reply-To: <50938A65.6040507@asianux.com>
Hello Eric Dumazet:
1) This time (the first time):
A) I have done according to what you have suggested.
i) git clone git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
ii) format with `git format-patch -s --summary --stat`
iii) cc to netdev@vger.kernel.org (not to linux-kernle@vger.kernel.org)
B) please check the 'Main Contents' (below of this mail).
C) thank you for your original information again, they are truly useful for me.
2) Next time (if also for net/ipv6):
A) I will send mail according to MAINTAINERS (which also you suggested)
M: "David S. Miller" <davem@davemloft.net>
M: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
M: James Morris <jmorris@namei.org>
M: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
M: Patrick McHardy <kaber@trash.net>
L: netdev@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
B) Only have 'Main Content' in next time.
Main Contents:
-----------------------------------------------------------------------------------
From: Chen Gang <gang.chen@asianux.com>
Date: Fri, 2 Nov 2012 16:02:11 +0800
Subject: [PATCH] net-ipv6: change %8s to %s for rt->dst.dev->name in seq_printf of rt6_info_route
the length of rt->dst.dev->name is 16 (IFNAMSIZ)
in seq_printf, it is not suitable to use %8s for rt->dst.dev->name.
so change it to %s, since each line has not been solid any more.
additional information:
%8s limit the width, not for the original string output length
if name length is more than 8, it still can be fully displayed.
if name length is less than 8, the ' ' will be filled before name.
%.8s truly limit the original string output length (precision)
Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
net/ipv6/route.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index c42650c..b60bc52 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2835,7 +2835,7 @@ static int rt6_info_route(struct rt6_info *rt, void *p_arg)
} else {
seq_puts(m, "00000000000000000000000000000000");
}
- seq_printf(m, " %08x %08x %08x %08x %8s\n",
+ seq_printf(m, " %08x %08x %08x %08x %s\n",
rt->rt6i_metric, atomic_read(&rt->dst.__refcnt),
rt->dst.__use, rt->rt6i_flags,
rt->dst.dev ? rt->dst.dev->name : "");
--
1.7.9.5
--
Chen Gang
Asianux Corporation
^ permalink raw reply related
* Re: [PATCH 4/4] FEC: Add time stamping code and a PTP hardware clock
From: Richard Cochran @ 2012-11-02 9:19 UTC (permalink / raw)
To: Frank Li; +Cc: lznua, shawn.guo, linux-arm-kernel, netdev, davem
In-Reply-To: <1351657531-25989-1-git-send-email-Frank.Li@freescale.com>
On Wed, Oct 31, 2012 at 12:25:31PM +0800, Frank Li wrote:
> diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
> index feff516..ff3be53 100644
> --- a/drivers/net/ethernet/freescale/Kconfig
> +++ b/drivers/net/ethernet/freescale/Kconfig
> @@ -92,4 +92,13 @@ config GIANFAR
> This driver supports the Gigabit TSEC on the MPC83xx, MPC85xx,
> and MPC86xx family of chips, and the FEC on the 8540.
>
> +config FEC_PTP
> + bool "PTP Hardware Clock (PHC)"
> + depends on FEC
> + select PPS
> + select PTP_1588_CLOCK
> + --help---
> + Say Y here if you want to use PTP Hardware Clock (PHC) in the
> + driver. Only the basic clock operations have been implemented.
> +
Does the PTP function work with every FEC on ColdFire and i.MX?
Or do you need to limit this option in some way?
> endif # NET_VENDOR_FREESCALE
...
> diff --git a/drivers/net/ethernet/freescale/fec_ptp.c b/drivers/net/ethernet/freescale/fec_ptp.c
> new file mode 100644
> index 0000000..9b91da9
> --- /dev/null
> +++ b/drivers/net/ethernet/freescale/fec_ptp.c
...
> +/**
> + * fec_ptp_adjfreq - adjust ptp cycle frequency
> + * @ptp: the ptp clock structure
> + * @ppb: parts per billion adjustment from base
> + *
> + * Adjust the frequency of the ptp cycle counter by the
> + * indicated ppb from the base frequency.
> + *
> + * Because ENET hardware frequency adjust is complex,
> + * using software method to do that.
> + */
> +static int fec_ptp_adjfreq(struct ptp_clock_info *ptp, s32 ppb)
> +{
> + u64 diff;
> + unsigned long flags;
> + int neg_adj = 0;
> +
> + struct fec_enet_private *fep =
> + container_of(ptp, struct fec_enet_private, ptp_caps);
> +
> + if (ppb < 0) {
> + ppb = -ppb;
> + neg_adj = 1;
> + }
> +
> + spin_lock_irqsave(&fep->tmreg_lock, flags);
> + /*
> + * dummy read to set cycle_last in tc to now.
> + * So use adjusted mult to calculate when next call
> + * timercounter_read.
> + */
> + timecounter_read(&fep->tc);
You can reduce the time that the spin lock is held by moving the next
four lines before the locked region:
> + fep->cc.mult = FEC_CC_MULT;
> + diff = fep->cc.mult;
> + diff *= ppb;
> + diff = div_u64(diff, 1000000000ULL);
> +
> + if (neg_adj)
> + fep->cc.mult -= diff;
> + else
> + fep->cc.mult += diff;
> +
> + spin_unlock_irqrestore(&fep->tmreg_lock, flags);
> +
> + return 0;
> +}
Thanks,
Richard
^ permalink raw reply
* Re: [net-next:master 122/152] drivers/ptp/ptp_chardev.c:36 ptp_ioctl() warn: 'sysoff' puts 832 bytes on stack
From: Richard Cochran @ 2012-11-02 8:59 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: changlongx.xie, fengguang.wu, netdev
In-Reply-To: <20121102020631.GI16883@yliu-dev.sh.intel.com>
On Fri, Nov 02, 2012 at 10:06:31AM +0800, Yuanhan Liu wrote:
>
> Hi Richard,
>
> _just_ FYI and let you aware of it, there are new smatch warnings show up in
>
> tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
> head: b77bc2069d1e437d5a1a71bb5cfcf4556ee40015
> commit: 215b13dd288c2e1e4461c1530a801f5f83e8cd90 [122/152] ptp: add an ioctl to compare PHC time with system time
>
> + drivers/ptp/ptp_chardev.c:36 ptp_ioctl() warn: 'sysoff' puts 832 bytes on stack
> drivers/ptp/ptp_chardev.c:144 ptp_read() warn: 'event' puts 960 bytes on stack
I am aware that these methods use large stack buffers, but I thought
it was okay seeing as they are both under the 1k limit.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
From: Richard Cochran @ 2012-11-02 8:56 UTC (permalink / raw)
To: N, Mugunthan V
Cc: Cousson, Benoit, Hiremath, Vaibhav, netdev@vger.kernel.org,
paul@pwsan.com, linux-arm-kernel@lists.infradead.org,
linux-omap@vger.kernel.org
In-Reply-To: <EB1619762EAF8B4E97A227FB77B7E0293EA08F53@DBDE01.ent.ti.com>
On Fri, Nov 02, 2012 at 08:46:46AM +0000, N, Mugunthan V wrote:
> >
> > Do you expect to have several instance of the same IP with different
> > parameters here?
>
> Though CPSW is a single IP in AM335X, CPSW has sub modules like CPDMA, ALE,
> SLIVER, CPTS and SLAVES where is IP integrator can locate it at different
> offsets. For example comparing the CPSW ip in TI814X and AM335X all the
> above offsets are changed. So I have kept all these offsets in DT as driver
> should not hold any SoC related informations
Did you see the two messages on this point from yesterday?
Thanks,
Richard
^ permalink raw reply
* [PATCH] net-ipv6: change %8s to %s for rt->dst.dev->name in seq_printf of rt6_info_route
From: Chen Gang @ 2012-11-02 8:55 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
Hello Eric Dumazet:
1) This time (the first time):
A) I have done according to what you have suggested.
i) git clone git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
ii) format with `git format-patch -s --summary --stat`
iii) cc to netdev@vger.kernel.org (not to linux-kernle@vger.kernel.org)
B) please check the 'Main Contents' (below of this mail).
C) thank you for your original information again, they are truly useful for me.
2) Next time (if also for net/ipv6):
A) I will send mail according to MAINTAINERS (which also you suggested)
M: "David S. Miller" <davem@davemloft.net>
M: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
M: James Morris <jmorris@namei.org>
M: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
M: Patrick McHardy <kaber@trash.net>
L: netdev@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
B) Only have 'Main Content' in next time.
Main Contents:
-----------------------------------------------------------------------------------
From: Chen Gang <gang.chen@asianux.com>
Date: Fri, 2 Nov 2012 16:02:11 +0800
Subject: [PATCH] net-ipv6: change %8s to %s for rt->dst.dev->name in seq_printf of rt6_info_route
the length of rt->dst.dev->name is 16 (IFNAMSIZ)
in seq_printf, it is not suitable to use %8s for rt->dst.dev->name.
so change it to %s, since each line has not been solid any more.
additional information:
%8s limit the width, not for the original string output length
if name length is more than 8, it still can be fully displayed.
if name length is less than 8, the ' ' will be filled before name.
%.8s truly limit the original string output length (precision)
Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
net/ipv6/route.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index c42650c..b60bc52 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2835,7 +2835,7 @@ static int rt6_info_route(struct rt6_info *rt, void *p_arg)
} else {
seq_puts(m, "00000000000000000000000000000000");
}
- seq_printf(m, " %08x %08x %08x %08x %8s\n",
+ seq_printf(m, " %08x %08x %08x %08x %s\n",
rt->rt6i_metric, atomic_read(&rt->dst.__refcnt),
rt->dst.__use, rt->rt6i_flags,
rt->dst.dev ? rt->dst.dev->name : "");
--
1.7.9.5
--
Chen Gang
Asianux Corporation
^ permalink raw reply related
* [RESEND PATCH net-next] ipv6/multipath: remove flag NLM_F_EXCL after the first nexthop
From: Nicolas Dichtel @ 2012-11-02 8:58 UTC (permalink / raw)
To: davem
Cc: shemminger, netdev, joe, bernat, eric.dumazet, yoshfuji,
Nicolas Dichtel
In-Reply-To: <50896D47.7030500@6wind.com>
fib6_add_rt2node() will reject the nexthop if this flag is set, so
we perform the check only for the first nexthop.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv6/route.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index c42650c..9c7b5d8 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2449,6 +2449,12 @@ beginning:
goto beginning;
}
}
+ /* Because each route is added like a single route we remove
+ * this flag after the first nexthop (if there is a collision,
+ * we have already fail to add the first nexthop:
+ * fib6_add_rt2node() has reject it).
+ */
+ cfg->fc_nlinfo.nlh->nlmsg_flags &= ~NLM_F_EXCL;
rtnh = rtnh_next(rtnh, &remaining);
}
--
1.7.12
^ permalink raw reply related
* RE: [PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
From: N, Mugunthan V @ 2012-11-02 8:46 UTC (permalink / raw)
To: Cousson, Benoit, Hiremath, Vaibhav
Cc: netdev@vger.kernel.org, paul@pwsan.com,
linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
Richard Cochran
In-Reply-To: <50914107.2090909@ti.com>
> -----Original Message-----
> From: Cousson, Benoit
> Sent: Wednesday, October 31, 2012 8:47 PM
> To: Hiremath, Vaibhav
> Cc: netdev@vger.kernel.org; paul@pwsan.com; linux-arm-
> kernel@lists.infradead.org; linux-omap@vger.kernel.org; N, Mugunthan V;
> Richard Cochran
> Subject: Re: [PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module
> nodes for AM33XX
> > + compatible = "ti,cpsw";
> > + ti,hwmods = "cpgmac0";
> > + cpdma_channels = <8>;
> > + host_port_no = <0>;
> > + cpdma_reg_ofs = <0x800>;
> > + cpdma_sram_ofs = <0xa00>;
> > + ale_reg_ofs = <0xd00>;
> > + ale_entries = <1024>;
> > + host_port_reg_ofs = <0x108>;
> > + hw_stats_reg_ofs = <0x900>;
> > + bd_ram_ofs = <0x2000>;
> > + bd_ram_size = <0x2000>;
> > + no_bd_ram = <0>;
> > + rx_descs = <64>;
> > + mac_control = <0x20>;
>
> Do you have to store all these data in the DTS? Cannot it be in the
> driver?
>
> Do you expect to have several instance of the same IP with different
> parameters here?
Though CPSW is a single IP in AM335X, CPSW has sub modules like CPDMA, ALE,
SLIVER, CPTS and SLAVES where is IP integrator can locate it at different
offsets. For example comparing the CPSW ip in TI814X and AM335X all the
above offsets are changed. So I have kept all these offsets in DT as driver
should not hold any SoC related informations
> > + cpsw_emac0: slave@0 {
>
> Mmm, you are using some address later and here some relative number,
> that does not looks very consistent.
>
> > + slave_reg_ofs = <0x208>;
>
> Is it an offset from 4a100000? Cannot you use the address for the slave
> name?
>
> Something like that: cpsw_emac0: slave@4a100208
>
I have followed the naming convention as per the TRM which is mentioned as
Slave 0 and Slave 1 and its offset is from 0x4a100000. I have taken the
reference from arch/arm/boot/dts/picoxcell-pc3x2.dtsi+167 and followed
the same naming convention from TRM. There is one more method to implement
in reference from arch/arm/boot/dts/imx6q.dtsi+408 as below
+ cpsw_emac0: slave@208 {
+ slave_reg_ofs = <0x208>;
+ sliver_reg_ofs = <0xd80>;
+ /* Filled in by U-Boot */
+ mac-address = [ 00 00 00 00 00 00 ];
+ };
Regards
Mugunthan V N
^ permalink raw reply
* Re: [PATCH 0/4] Support the MX6 FEC as a PTP hardware clock
From: Richard Cochran @ 2012-11-02 8:43 UTC (permalink / raw)
To: Frank Li; +Cc: David Miller, Frank.Li, shawn.guo, linux-arm-kernel, netdev
In-Reply-To: <CAHrpEqRuy=kewK-592RphVfJnNoma2CPZytoTqLc45HeT53hRQ@mail.gmail.com>
On Fri, Nov 02, 2012 at 10:36:09AM +0800, Frank Li wrote:
> >
> > All applied to net-next.
> >
> > Please make sure your changes are in sync with Ben's PTP/PPS
> > Kconfig changes of today, and send me any changes if necessary.
> >
>
> Thank you very much.
> I checked Ben's patch, which not affect FEC.
Maybe just remove the Kconfig line "select PPS".
Thanks,
Richard
^ permalink raw reply
* Re: [3.5/6.x][e1000e] - Regression - Unable to receive packets if MTU == 1500
From: Jeff Kirsher @ 2012-11-02 8:40 UTC (permalink / raw)
To: Shawn Starr; +Cc: netdev, e1000-devel
In-Reply-To: <1570009.hYb0226lHg@segfault.sh0n.net>
[-- Attachment #1: Type: text/plain, Size: 3542 bytes --]
On 11/01/2012 10:58 AM, Shawn Starr wrote:
> Hello network driver folks,
>
> I recently decided to reinstall my Lenovo W500 laptop and found I wasn't able
> to get DHCP leases, I wasn't able to install over PXE (when getting the IP a
> second time within the OS)
>
> Fedora is currently using kernel-3.6.2-2.fc18.x86_64 (Pre-beta)
>
> The only difference I noticed was in my old install of Fedora, I had added
> MTU=9000 to the interface config while using a 3.5 kernel, not knowing 3.6.x
> seems to break things.
>
> My Cisco DPC3825 Switch/Cable modem has an MTU setting but this is from Cable
> provider <-> WAN interface only. I tried changing to 1500 but by default it
> uses this anyway.
>
> I had noticed tx unit hang errors sometimes, but not when MTU is above 1500.
>
> PCI info:
>
> 00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network
> Connection (rev 03)
> Subsystem: Lenovo Device 20ee
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR+ FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin A routed to IRQ 46
> Region 0: Memory at fc000000 (32-bit, non-prefetchable) [size=128K]
> Region 1: Memory at fc025000 (32-bit, non-prefetchable) [size=4K]
> Region 2: I/O ports at 1840 [size=32]
> Capabilities: [c8] Power Management version 2
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
> PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Address: 00000000fee0100c Data: 41a2
> Capabilities: [e0] PCI Advanced Features
> AFCap: TP+ FLR+
> AFCtrl: FLR-
> AFStatus: TP-
> Kernel driver in use: e1000e
>
> e1000e conversation log:
>
> [ 12.653816] e1000e: Intel(R) PRO/1000 Network Driver - 2.0.0-k
> [ 12.653819] e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
> [ 12.653855] e1000e 0000:00:19.0: setting latency timer to 64
> [ 12.653938] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set
> to dynamic conservative mode
> [ 12.653980] e1000e 0000:00:19.0: irq 46 for MSI/MSI-X
> [ 12.844121] e1000e 0000:00:19.0: eth0: (PCI Express:2.5GT/s:Width x1)
> 00:22:68:0c:96:e3
> [ 12.844124] e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
> [ 12.844150] e1000e 0000:00:19.0: eth0: MAC: 7, PHY: 8, PBA No: 1008FF-0FF
> [ 17.459570] e1000e 0000:00:19.0: eth0: changing MTU from 1500 to 9000
> [ 17.459577] e1000e 0000:00:19.0: Interrupt Throttle Rate turned off
> [ 17.948121] e1000e 0000:00:19.0: irq 46 for MSI/MSI-X
> [ 18.049164] e1000e 0000:00:19.0: irq 46 for MSI/MSI-X
> [ 20.442936] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow
> Control: Rx/Tx
>
> When I set MTU = 1500 (2000 works), it will stop receiving packets, it also
> disables Interrupt Throttling when MTU is set higher.
>
> After testing reasons why it wasn't get a DHCP lease, I decided to bump the
> MTU to 9000 for Jumbo Frames and as soon as I did this, I was able to get a
> lease and the network functioned resumes receiving packets.
>
> Can anyone else report regressions or might know whats going on?
>
> Thanks,
> Shawn.
Adding e1000-devel mailing list
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]
^ permalink raw reply
* Re: [v6 PATCH 0/8] csiostor: Chelsio FCoE offload driver submission
From: Naresh Kumar Inna @ 2012-11-02 7:23 UTC (permalink / raw)
To: JBottomley@parallels.com
Cc: Naresh Kumar Inna, linux-scsi@vger.kernel.org,
Dimitrios Michailidis, Casey Leedom, netdev@vger.kernel.org,
Chethan Seshadri
In-Reply-To: <1351158621-32222-1-git-send-email-naresh@chelsio.com>
Hi James,
Could you please let me know where we are with the review of this driver?
Thanks,
Naresh.
On 10/25/2012 3:20 PM, Naresh Kumar Inna wrote:
> This is the initial submission of the Chelsio FCoE offload driver (csiostor)
> to the upstream kernel. This driver currently supports FCoE offload
> functionality over Chelsio T4-based 10Gb Converged Network Adapters.
>
> The following patches contain the driver sources for csiostor driver and
> updates to firmware/hardware header files shared between csiostor,
> cxgb4 (Chelsio T4-based NIC driver) and cxgb4vf (Chelsio T4-based Virtual
> Function NIC driver). The csiostor driver is dependent on these
> header updates. These patches have been generated against scsi 'misc' branch.
>
> csiostor is a low level SCSI driver that interfaces with PCI, SCSI midlayer and
> FC transport subsystems. This driver claims the FCoE PCIe function on
> Chelsio Converged Network Adapters. It relies on firmware events for slow path
> operations like discovery, thereby offloading session management. The driver
> programs firmware via Work Request interfaces for fast path I/O offload
> features.
>
> v6 has changes to make csiostor work with cxgb4 header files post 3.6 merge, as
> well as a few bug fixes in csiostor.
>
> Here is the brief description of patches:
> [v6 PATCH 1/8]: Updates to header files shared between cxgb4, cxgb4vf and
> csiostor.
> [v6 PATCH 2/8]: Header files part 1.
> [v6 PATCH 3/8]: Header files part 2.
> [v6 PATCH 4/8]: Driver initialization and Work Request services.
> [v6 PATCH 5/8]: FC transport interfaces and mailbox services.
> [v6 PATCH 6/8]: Local and remote port state tracking functionality.
> [v6 PATCH 7/8]: Interrupt handling and fast path I/O functionality.
> [v6 PATCH 8/8]: Hardware interface, Makefile and Kconfig changes.
>
> Naresh Kumar Inna (8):
> cxgb4/cxgb4vf: Chelsio FCoE offload driver submission (common header
> updates).
> csiostor: Chelsio FCoE offload driver submission (headers part 1).
> csiostor: Chelsio FCoE offload driver submission (headers part 2).
> csiostor: Chelsio FCoE offload driver submission (sources part 1).
> csiostor: Chelsio FCoE offload driver submission (sources part 2).
> csiostor: Chelsio FCoE offload driver submission (sources part 3).
> csiostor: Chelsio FCoE offload driver submission (sources part 4).
> csiostor: Chelsio FCoE offload driver submission (sources part 5).
>
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 8 +-
> drivers/net/ethernet/chelsio/cxgb4/sge.c | 6 +-
> drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 20 +-
> drivers/net/ethernet/chelsio/cxgb4/t4_msg.h | 1 +
> drivers/net/ethernet/chelsio/cxgb4/t4_regs.h | 36 +-
> drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 41 +-
> drivers/net/ethernet/chelsio/cxgb4vf/sge.c | 8 +-
> drivers/scsi/Kconfig | 1 +
> drivers/scsi/Makefile | 1 +
> drivers/scsi/csiostor/Kconfig | 19 +
> drivers/scsi/csiostor/Makefile | 11 +
> drivers/scsi/csiostor/csio_attr.c | 796 ++++
> drivers/scsi/csiostor/csio_defs.h | 121 +
> drivers/scsi/csiostor/csio_hw.c | 4395 +++++++++++++++++++++++
> drivers/scsi/csiostor/csio_hw.h | 667 ++++
> drivers/scsi/csiostor/csio_init.c | 1274 +++++++
> drivers/scsi/csiostor/csio_init.h | 158 +
> drivers/scsi/csiostor/csio_isr.c | 624 ++++
> drivers/scsi/csiostor/csio_lnode.c | 2133 +++++++++++
> drivers/scsi/csiostor/csio_lnode.h | 255 ++
> drivers/scsi/csiostor/csio_mb.c | 1770 +++++++++
> drivers/scsi/csiostor/csio_mb.h | 278 ++
> drivers/scsi/csiostor/csio_rnode.c | 912 +++++
> drivers/scsi/csiostor/csio_rnode.h | 141 +
> drivers/scsi/csiostor/csio_scsi.c | 2555 +++++++++++++
> drivers/scsi/csiostor/csio_scsi.h | 342 ++
> drivers/scsi/csiostor/csio_wr.c | 1632 +++++++++
> drivers/scsi/csiostor/csio_wr.h | 512 +++
> drivers/scsi/csiostor/t4fw_api_stor.h | 578 +++
> 29 files changed, 19267 insertions(+), 28 deletions(-)
> create mode 100644 drivers/scsi/csiostor/Kconfig
> create mode 100644 drivers/scsi/csiostor/Makefile
> create mode 100644 drivers/scsi/csiostor/csio_attr.c
> create mode 100644 drivers/scsi/csiostor/csio_defs.h
> create mode 100644 drivers/scsi/csiostor/csio_hw.c
> create mode 100644 drivers/scsi/csiostor/csio_hw.h
> create mode 100644 drivers/scsi/csiostor/csio_init.c
> create mode 100644 drivers/scsi/csiostor/csio_init.h
> create mode 100644 drivers/scsi/csiostor/csio_isr.c
> create mode 100644 drivers/scsi/csiostor/csio_lnode.c
> create mode 100644 drivers/scsi/csiostor/csio_lnode.h
> create mode 100644 drivers/scsi/csiostor/csio_mb.c
> create mode 100644 drivers/scsi/csiostor/csio_mb.h
> create mode 100644 drivers/scsi/csiostor/csio_rnode.c
> create mode 100644 drivers/scsi/csiostor/csio_rnode.h
> create mode 100644 drivers/scsi/csiostor/csio_scsi.c
> create mode 100644 drivers/scsi/csiostor/csio_scsi.h
> create mode 100644 drivers/scsi/csiostor/csio_wr.c
> create mode 100644 drivers/scsi/csiostor/csio_wr.h
> create mode 100644 drivers/scsi/csiostor/t4fw_api_stor.h
>
^ permalink raw reply
* Re: switching network namespace midway
From: Eric W. Biederman @ 2012-11-02 6:18 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: rsa, netdev
In-Reply-To: <20121102022542.GD18091@kvack.org>
Benjamin LaHaise <bcrl@kvack.org> writes:
> On Thu, Oct 25, 2012 at 09:15:34AM -0700, Eric W. Biederman wrote:
>> > I've read IPv4 gre code, and it appears to do the right thing on rx, but it
>> > does *not* appear to handle namespaces correctly on transmit. In general,
>> > I would expect pretty much all code to get namespace handling correct for
>> > the rx case. I'll have a closer look at fixing this tomorrow if nobody else
>> > beats me to it.
>>
>> It will be interesting to see what you come up with.
>
> Well, I finally had some time to work on the ip_gre module a bit today,
> and here's what I came up with. The basic idea is to store the network
> namespace in the ip_tunnel structure at creation time for use in sending
> and receiving packets, allowing the gre network device to be safely moved
> into another network namespace. This works for me in moving a gre tunnel
> into an lxc container, and survives module unload and namespace
> destruction. I'll try to spend a bit more time adding similar support to
> the other ip_tunnel devices over the next few days. Comments/thoughts?
>
> -ben
You need a per network namespace exit function to delete the tunnel when
the xmit direction goes away. Otherwise we have a very nasty race if
the original network namespace exits.
NETNS_LOCAL may make sense on the reference device that is used to
support ioctls for creating devices.
ipgre_open ? It looks like it needs to be handled. Probably that
ip_route_output_gre needs to be moved.
ipv6?
Eric
> --
> "Thought is the essence of where you are now."
>
>
> diff --git a/include/net/ipip.h b/include/net/ipip.h
> index ddc077c..9cfba92 100644
> --- a/include/net/ipip.h
> +++ b/include/net/ipip.h
> @@ -19,6 +19,7 @@ struct ip_tunnel_6rd_parm {
> struct ip_tunnel {
> struct ip_tunnel __rcu *next;
> struct net_device *dev;
> + struct net *net; /* Namespace for packet i/o */
>
> int err_count; /* Number of arrived ICMP errors */
> unsigned long err_time; /* Time when the last ICMP error arrived */
> diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> index 7240f8e..705dc66 100644
> --- a/net/ipv4/ip_gre.c
> +++ b/net/ipv4/ip_gre.c
> @@ -461,6 +461,7 @@ static struct ip_tunnel *ipgre_tunnel_locate(struct net *net,
> dev_net_set(dev, net);
>
> nt = netdev_priv(dev);
> + nt->net = net;
> nt->parms = *parms;
> dev->rtnl_link_ops = &ipgre_link_ops;
>
> @@ -484,8 +485,10 @@ failed_free:
>
> static void ipgre_tunnel_uninit(struct net_device *dev)
> {
> - struct net *net = dev_net(dev);
> - struct ipgre_net *ign = net_generic(net, ipgre_net_id);
> + struct ip_tunnel *tunnel = netdev_priv(dev);
> + struct ipgre_net *ign;
> +
> + ign = net_generic(tunnel->net, ipgre_net_id);
>
> ipgre_tunnel_unlink(ign, netdev_priv(dev));
> dev_put(dev);
> @@ -837,7 +840,7 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
> tos = ipv6_get_dsfield((const struct ipv6hdr *)old_iph);
> }
>
> - rt = ip_route_output_gre(dev_net(dev), &fl4, dst, tiph->saddr,
> + rt = ip_route_output_gre(tunnel->net, &fl4, dst, tiph->saddr,
> tunnel->parms.o_key, RT_TOS(tos),
> tunnel->parms.link);
> if (IS_ERR(rt)) {
> @@ -1010,7 +1013,7 @@ static int ipgre_tunnel_bind_dev(struct net_device *dev)
> struct flowi4 fl4;
> struct rtable *rt;
>
> - rt = ip_route_output_gre(dev_net(dev), &fl4,
> + rt = ip_route_output_gre(tunnel->net, &fl4,
> iph->daddr, iph->saddr,
> tunnel->parms.o_key,
> RT_TOS(iph->tos),
> @@ -1341,7 +1344,6 @@ static void ipgre_tunnel_setup(struct net_device *dev)
> dev->flags = IFF_NOARP;
> dev->iflink = 0;
> dev->addr_len = 4;
> - dev->features |= NETIF_F_NETNS_LOCAL;
> dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
>
> dev->features |= GRE_FEATURES;
> @@ -1432,6 +1434,7 @@ static void ipgre_destroy_tunnels(struct ipgre_net *ign, struct list_head *head)
> static int __net_init ipgre_init_net(struct net *net)
> {
> struct ipgre_net *ign = net_generic(net, ipgre_net_id);
> + struct ip_tunnel *tunnel;
> int err;
>
> ign->fb_tunnel_dev = alloc_netdev(sizeof(struct ip_tunnel), "gre0",
> @@ -1445,6 +1448,9 @@ static int __net_init ipgre_init_net(struct net *net)
> ipgre_fb_tunnel_init(ign->fb_tunnel_dev);
> ign->fb_tunnel_dev->rtnl_link_ops = &ipgre_link_ops;
>
> + tunnel = netdev_priv(ign->fb_tunnel_dev);
> + tunnel->net = net;
> +
> if ((err = register_netdev(ign->fb_tunnel_dev)))
> goto err_reg_dev;
>
^ permalink raw reply
* linux-next: manual merge of the drop-experimental tree with the net-next tree
From: Stephen Rothwell @ 2012-11-02 4:55 UTC (permalink / raw)
To: Kees Cook; +Cc: linux-next, linux-kernel, Ben Hutchings, David Miller, netdev
[-- Attachment #1: Type: text/plain, Size: 584 bytes --]
Hi Kees,
Today's linux-next merge of the drop-experimental tree got a conflict in
drivers/net/ethernet/intel/Kconfig between commit a24006ed1261 ("ptp:
Enable clock drivers along with associated net/PHY drivers") from the
net-next tree and commit 70c5056f413d ("drivers/net/ethernet/intel:
remove depends on CONFIG_EXPERIMENTAL") from the drop-experimental tree.
The former removed some code that was changed by the latter, so I did
that and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Vital Information
From: Google Registered Office @ 2012-11-01 5:51 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 119 bytes --]
Dear Google User,
See attached document for details on Google winning Reward.
Heiko Thaemlitz
Google Representative
[-- Attachment #2: Google Reward..doc --]
[-- Type: application/msword, Size: 94720 bytes --]
^ permalink raw reply
* Re: [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
From: Sasha Levin @ 2012-11-02 4:23 UTC (permalink / raw)
To: Linus Torvalds
Cc: snitzer-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, agk-H+wXaHxf7aLQT0dZR+AlfA,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, mingo-X9Un+BFzKDI,
dev-yBygre7rU0TnMu66kgdUjQ, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
josh-iaAMLnmF4UmaiuxdJuQwMA, Steven Rostedt,
lw-BthXqXjhjHXQFUHtdCDX3A,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w,
axboe-tSWWG44O7X1aa/9Udqfwiw, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ejt-H+wXaHxf7aLQT0dZR+AlfA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, Tejun Heo,
teigland-H+wXaHxf7aLQT0dZR+AlfA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <CA+55aFxK+xr0Gc+ZLgi3Ch8YgoV78vvr+Q-7cP=kC7asFB5k5w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Oct 30, 2012 at 10:23 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
> On Tue, Oct 30, 2012 at 6:36 PM, Sasha Levin <levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>> I can either rebase that on top of mainline, or we can ask maintainers
>> to take it to their own trees if you take only 01/16 into mainline.
>> What would you prefer?
>
> I don't really care deeply. The only reason to merge it now would be
> to avoid any pain with it during the next merge window. Just taking
> 01/16 might be the sanest way to do that, then the rest can trickle in
> independently at their own leisure.
Okay, I'll keep working on converting everything else as soon as 01/16
makes it in your tree.
Thanks,
Sasha
^ permalink raw reply
* This Message is From the Administrator Desk
From: Brittnee E Johnson @ 2012-11-02 3:16 UTC (permalink / raw)
This Message is From the Administrator Desk
Due to our latest IP Security upgrades we have reason to believe that your webmail account was accessed by a third party. Protecting the security of your webmail account is our primary concern, we have limited access to sensitive webmail account features.Failure to revalidate, your e-mail will be blocked in 24 hours. To complete this verification kindly copy the link and paste on your web address.
http://securityupgrad.ucoz.com/Microsoft_Outloo.htm<http://ipexchangeowa.ucoz.com/Microsoft_outlook-Upgrade_microsoft_outlook-1-.htm>
Thank you for your cooperation.
System Administrator.
^ permalink raw reply
* [PATCH v2 net-next] r8169: enable internal ASPM and clock request settings
From: Hayes Wang @ 2012-11-02 2:46 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, agnescheng, Hayes Wang
In-Reply-To: <1351780651-1271-1-git-send-email-hayeswang@realtek.com>
The following chips need to enable internal settings to let ASPM
and clock request work.
RTL8111E-VL, RTL8111F, RTL8411, RTL8111G
RTL8105, RTL8402, RTL8106
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 30 +++++++++++++++++++++---------
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 123c6a5..91c8387 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -456,6 +456,7 @@ enum rtl8168_registers {
#define PWM_EN (1 << 22)
#define RXDV_GATED_EN (1 << 19)
#define EARLY_TALLY_EN (1 << 16)
+#define FORCE_CLK (1 << 15) /* force clock request */
};
enum rtl_register_content {
@@ -519,6 +520,7 @@ enum rtl_register_content {
PMEnable = (1 << 0), /* Power Management Enable */
/* Config2 register p. 25 */
+ ClkReqEn = (1 << 7), /* Clock Request Enable */
MSIEnable = (1 << 5), /* 8169 only. Reserved in the 8168. */
PCI_Clock_66MHz = 0x01,
PCI_Clock_33MHz = 0x00,
@@ -539,6 +541,7 @@ enum rtl_register_content {
Spi_en = (1 << 3),
LanWake = (1 << 1), /* LanWake enable/disable */
PMEStatus = (1 << 0), /* PME status can be reset by PCI RST# */
+ ASPM_en = (1 << 0), /* ASPM enable */
/* TBICSR p.28 */
TBIReset = 0x80000000,
@@ -5046,8 +5049,6 @@ static void rtl_hw_start_8168e_2(struct rtl8169_private *tp)
RTL_W8(MaxTxPacketSize, EarlySize);
- rtl_disable_clock_request(pdev);
-
RTL_W32(TxConfig, RTL_R32(TxConfig) | TXCFG_AUTO_FIFO);
RTL_W8(MCU, RTL_R8(MCU) & ~NOW_IS_OOB);
@@ -5056,7 +5057,8 @@ static void rtl_hw_start_8168e_2(struct rtl8169_private *tp)
RTL_W8(DLLPR, RTL_R8(DLLPR) | PFM_EN);
RTL_W32(MISC, RTL_R32(MISC) | PWM_EN);
- RTL_W8(Config5, RTL_R8(Config5) & ~Spi_en);
+ RTL_W8(Config5, (RTL_R8(Config5) & ~Spi_en) | ASPM_en);
+ RTL_W8(Config2, RTL_R8(Config2) | ClkReqEn);
}
static void rtl_hw_start_8168f(struct rtl8169_private *tp)
@@ -5081,13 +5083,12 @@ static void rtl_hw_start_8168f(struct rtl8169_private *tp)
RTL_W8(MaxTxPacketSize, EarlySize);
- rtl_disable_clock_request(pdev);
-
RTL_W32(TxConfig, RTL_R32(TxConfig) | TXCFG_AUTO_FIFO);
RTL_W8(MCU, RTL_R8(MCU) & ~NOW_IS_OOB);
RTL_W8(DLLPR, RTL_R8(DLLPR) | PFM_EN);
- RTL_W32(MISC, RTL_R32(MISC) | PWM_EN);
- RTL_W8(Config5, RTL_R8(Config5) & ~Spi_en);
+ RTL_W32(MISC, RTL_R32(MISC) | PWM_EN | FORCE_CLK);
+ RTL_W8(Config5, (RTL_R8(Config5) & ~Spi_en) | ASPM_en);
+ RTL_W8(Config2, RTL_R8(Config2) | ClkReqEn);
}
static void rtl_hw_start_8168f_1(struct rtl8169_private *tp)
@@ -5144,8 +5145,10 @@ static void rtl_hw_start_8168g_1(struct rtl8169_private *tp)
rtl_w1w0_eri(tp, 0xdc, ERIAR_MASK_0001, 0x01, 0x00, ERIAR_EXGMAC);
RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
- RTL_W32(MISC, RTL_R32(MISC) & ~RXDV_GATED_EN);
+ RTL_W32(MISC, (RTL_R32(MISC) | FORCE_CLK) & ~RXDV_GATED_EN);
RTL_W8(MaxTxPacketSize, EarlySize);
+ RTL_W8(Config5, RTL_R8(Config5) | ASPM_en);
+ RTL_W8(Config2, RTL_R8(Config2) | ClkReqEn);
rtl_eri_write(tp, 0xc0, ERIAR_MASK_0011, 0x0000, ERIAR_EXGMAC);
rtl_eri_write(tp, 0xb8, ERIAR_MASK_0011, 0x0000, ERIAR_EXGMAC);
@@ -5361,6 +5364,9 @@ static void rtl_hw_start_8105e_1(struct rtl8169_private *tp)
RTL_W8(MCU, RTL_R8(MCU) | EN_NDP | EN_OOB_RESET);
RTL_W8(DLLPR, RTL_R8(DLLPR) | PFM_EN);
+ RTL_W8(Config5, RTL_R8(Config5) | ASPM_en);
+ RTL_W8(Config2, RTL_R8(Config2) | ClkReqEn);
+ RTL_W32(MISC, RTL_R32(MISC) | FORCE_CLK);
rtl_ephy_init(tp, e_info_8105e_1, ARRAY_SIZE(e_info_8105e_1));
}
@@ -5386,6 +5392,9 @@ static void rtl_hw_start_8402(struct rtl8169_private *tp)
RTL_W32(TxConfig, RTL_R32(TxConfig) | TXCFG_AUTO_FIFO);
RTL_W8(MCU, RTL_R8(MCU) & ~NOW_IS_OOB);
+ RTL_W8(Config5, RTL_R8(Config5) | ASPM_en);
+ RTL_W8(Config2, RTL_R8(Config2) | ClkReqEn);
+ RTL_W32(MISC, RTL_R32(MISC) | FORCE_CLK);
rtl_ephy_init(tp, e_info_8402, ARRAY_SIZE(e_info_8402));
@@ -5407,7 +5416,10 @@ static void rtl_hw_start_8106(struct rtl8169_private *tp)
/* Force LAN exit from ASPM if Rx/Tx are not idle */
RTL_W32(FuncEvent, RTL_R32(FuncEvent) | 0x002800);
- RTL_W32(MISC, (RTL_R32(MISC) | DISABLE_LAN_EN) & ~EARLY_TALLY_EN);
+ RTL_W32(MISC,
+ (RTL_R32(MISC) | DISABLE_LAN_EN | FORCE_CLK) & ~EARLY_TALLY_EN);
+ RTL_W8(Config5, RTL_R8(Config5) | ASPM_en);
+ RTL_W8(Config2, RTL_R8(Config2) | ClkReqEn);
RTL_W8(MCU, RTL_R8(MCU) | EN_NDP | EN_OOB_RESET);
RTL_W8(DLLPR, RTL_R8(DLLPR) & ~PFM_EN);
}
--
1.7.11.4
^ permalink raw reply related
* [net PATCH] rtnetlink: Use nlmsg type RTM_NEWNEIGH from dflt fdb dump
From: John Fastabend @ 2012-11-02 2:23 UTC (permalink / raw)
To: davem; +Cc: netdev
Change the dflt fdb dump handler to use RTM_NEWNEIGH to
be compatible with bridge dump routines.
The dump reply from the network driver handlers should
match the reply from bridge handler. The fact they were
not in the ixgbe case was effectively a bug. This patch
resolves it.
Applications that were not checking the nlmsg type will
continue to work. And now applications that do check
the type will work as expected.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---
net/core/rtnetlink.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 76d4c2c..fad649a 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2192,7 +2192,8 @@ static int nlmsg_populate_fdb(struct sk_buff *skb,
goto skip;
err = nlmsg_populate_fdb_fill(skb, dev, ha->addr,
- portid, seq, 0, NTF_SELF);
+ portid, seq,
+ RTM_NEWNEIGH, NTF_SELF);
if (err < 0)
return err;
skip:
^ permalink raw reply related
* Re: [PATCH 0/4] Support the MX6 FEC as a PTP hardware clock
From: Frank Li @ 2012-11-02 2:36 UTC (permalink / raw)
To: David Miller
Cc: Frank.Li, lznuaa, richardcochran, shawn.guo, linux-arm-kernel,
netdev
In-Reply-To: <20121101.123027.1332984905040252720.davem@davemloft.net>
>
> All applied to net-next.
>
> Please make sure your changes are in sync with Ben's PTP/PPS
> Kconfig changes of today, and send me any changes if necessary.
>
Thank you very much.
I checked Ben's patch, which not affect FEC.
best regards
Frank Li
^ permalink raw reply
* RE: [PATCH v4 0/21] qlcnic: patches for new adapter - Qlogic 83XX CNA
From: Sony Chacko @ 2012-11-02 2:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Dept-NX Linux NIC Driver
In-Reply-To: <20121101.120346.2191225134084388160.davem@davemloft.net>
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Thursday, November 01, 2012 9:04 AM
> To: Sony Chacko
> Cc: netdev; Dept-NX Linux NIC Driver
> Subject: Re: [PATCH v4 0/21] qlcnic: patches for new adapter - Qlogic 83XX
> CNA
>
>
> Patch #17 did not make it to the list, you have to make it smaller so that it fits.
David,
I re-submitted the patch series after splitting patch #17.
Updated patch series V5 has 22 patches and by mistake patch #21 do not have the patch number.
I have re-submitted patch #21 with the proper version and correct patch number.
Please let me know if I need to resubmit the complete patch set again.
Thanks,
Sony
^ permalink raw reply
* Re: switching network namespace midway
From: Benjamin LaHaise @ 2012-11-02 2:25 UTC (permalink / raw)
To: Eric W. Biederman, rsa; +Cc: netdev
In-Reply-To: <87a9var0ih.fsf@xmission.com>
On Thu, Oct 25, 2012 at 09:15:34AM -0700, Eric W. Biederman wrote:
> > I've read IPv4 gre code, and it appears to do the right thing on rx, but it
> > does *not* appear to handle namespaces correctly on transmit. In general,
> > I would expect pretty much all code to get namespace handling correct for
> > the rx case. I'll have a closer look at fixing this tomorrow if nobody else
> > beats me to it.
>
> It will be interesting to see what you come up with.
Well, I finally had some time to work on the ip_gre module a bit today,
and here's what I came up with. The basic idea is to store the network
namespace in the ip_tunnel structure at creation time for use in sending
and receiving packets, allowing the gre network device to be safely moved
into another network namespace. This works for me in moving a gre tunnel
into an lxc container, and survives module unload and namespace
destruction. I'll try to spend a bit more time adding similar support to
the other ip_tunnel devices over the next few days. Comments/thoughts?
-ben
--
"Thought is the essence of where you are now."
diff --git a/include/net/ipip.h b/include/net/ipip.h
index ddc077c..9cfba92 100644
--- a/include/net/ipip.h
+++ b/include/net/ipip.h
@@ -19,6 +19,7 @@ struct ip_tunnel_6rd_parm {
struct ip_tunnel {
struct ip_tunnel __rcu *next;
struct net_device *dev;
+ struct net *net; /* Namespace for packet i/o */
int err_count; /* Number of arrived ICMP errors */
unsigned long err_time; /* Time when the last ICMP error arrived */
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 7240f8e..705dc66 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -461,6 +461,7 @@ static struct ip_tunnel *ipgre_tunnel_locate(struct net *net,
dev_net_set(dev, net);
nt = netdev_priv(dev);
+ nt->net = net;
nt->parms = *parms;
dev->rtnl_link_ops = &ipgre_link_ops;
@@ -484,8 +485,10 @@ failed_free:
static void ipgre_tunnel_uninit(struct net_device *dev)
{
- struct net *net = dev_net(dev);
- struct ipgre_net *ign = net_generic(net, ipgre_net_id);
+ struct ip_tunnel *tunnel = netdev_priv(dev);
+ struct ipgre_net *ign;
+
+ ign = net_generic(tunnel->net, ipgre_net_id);
ipgre_tunnel_unlink(ign, netdev_priv(dev));
dev_put(dev);
@@ -837,7 +840,7 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
tos = ipv6_get_dsfield((const struct ipv6hdr *)old_iph);
}
- rt = ip_route_output_gre(dev_net(dev), &fl4, dst, tiph->saddr,
+ rt = ip_route_output_gre(tunnel->net, &fl4, dst, tiph->saddr,
tunnel->parms.o_key, RT_TOS(tos),
tunnel->parms.link);
if (IS_ERR(rt)) {
@@ -1010,7 +1013,7 @@ static int ipgre_tunnel_bind_dev(struct net_device *dev)
struct flowi4 fl4;
struct rtable *rt;
- rt = ip_route_output_gre(dev_net(dev), &fl4,
+ rt = ip_route_output_gre(tunnel->net, &fl4,
iph->daddr, iph->saddr,
tunnel->parms.o_key,
RT_TOS(iph->tos),
@@ -1341,7 +1344,6 @@ static void ipgre_tunnel_setup(struct net_device *dev)
dev->flags = IFF_NOARP;
dev->iflink = 0;
dev->addr_len = 4;
- dev->features |= NETIF_F_NETNS_LOCAL;
dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
dev->features |= GRE_FEATURES;
@@ -1432,6 +1434,7 @@ static void ipgre_destroy_tunnels(struct ipgre_net *ign, struct list_head *head)
static int __net_init ipgre_init_net(struct net *net)
{
struct ipgre_net *ign = net_generic(net, ipgre_net_id);
+ struct ip_tunnel *tunnel;
int err;
ign->fb_tunnel_dev = alloc_netdev(sizeof(struct ip_tunnel), "gre0",
@@ -1445,6 +1448,9 @@ static int __net_init ipgre_init_net(struct net *net)
ipgre_fb_tunnel_init(ign->fb_tunnel_dev);
ign->fb_tunnel_dev->rtnl_link_ops = &ipgre_link_ops;
+ tunnel = netdev_priv(ign->fb_tunnel_dev);
+ tunnel->net = net;
+
if ((err = register_netdev(ign->fb_tunnel_dev)))
goto err_reg_dev;
^ permalink raw reply related
* Re: [net-next v5 0/7] Multiqueue support in tuntap
From: Max Krasnyansky @ 2012-11-02 2:18 UTC (permalink / raw)
To: Jason Wang
Cc: davem, mst, netdev, linux-kernel, edumazet, krkumar2,
ernesto.martin, haixiao
In-Reply-To: <1351748762-3455-1-git-send-email-jasowang@redhat.com>
On 10/31/2012 10:45 PM, Jason Wang wrote:
> Hello All:
>
> This is an update of multiqueue support in tuntap from V3. Please consider to
> merge.
>
> The main idea for this series is to let tun/tap device to be benefited from
> multiqueue network cards and multi-core host. We used to have a single queue for
> tuntap which could be a bottleneck in a multiqueue/core environment. So this
> series let the device could be attched with multiple sockets and expose them
> through fd to the userspace as multiqueues. The sereis were orignally designed
> to serve as backend for multiqueue virtio-net in KVM, but the design is generic
> for other application to be used.
>
> Some quick overview of the design:
>
> - Moving socket from tun_device to tun_file.
> - Allowing multiple sockets to be attached to a tun/tap devices.
> - Using RCU to synchronize the data path and system call.
> - Two new ioctls were added for the usespace to attach and detach socket to the
> device.
> - API compatibility were maintained without userspace notable changes, so legacy
> userspace that only use one queue won't need any changes.
> - A flow(rxhash) to queue table were maintained by tuntap which choose the txq
> based on the last rxq where it comes.
I'm still trying to wrap my head around the new locking/RCU stuff but it looks like
Paul and others already looked at it.
Otherwise looks good to me.
btw In the description above you really meant allowing for attaching multiple file
descriptors not sockets.
Thanks
Max
^ 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