* Re: [PATCH] net: Add support for handling queueing in hardware
From: David Miller @ 2013-03-22 15:17 UTC (permalink / raw)
To: benmcollins13; +Cc: afleming, linux-kernel, netdev
In-Reply-To: <FE78128C-01DB-4831-ACBE-BA3E3A428BFC@gmail.com>
From: Ben Collins <benmcollins13@gmail.com>
Date: Fri, 22 Mar 2013 10:43:44 -0400
> "For us" is a loose term, when it's more that we are attempting to
> upstream code so our system is supported by a mainline kernel
> instead of having one-off kernels.
If this other person doesn't want their code upstreams, it is absolutely
inappropriate for you to try and force the matter and "do it for them."
^ permalink raw reply
* Re: [PATCH iproute2] libnetlink: check flag NLM_F_DUMP_INTR during dumps
From: Eric Dumazet @ 2013-03-22 15:14 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: shemminger, netdev
In-Reply-To: <514C72B7.8070804@6wind.com>
On Fri, 2013-03-22 at 16:03 +0100, Nicolas Dichtel wrote:
> Le 22/03/2013 15:59, Eric Dumazet a écrit :
> > On Fri, 2013-03-22 at 15:45 +0100, Nicolas Dichtel wrote:
> >> When this flag is set, it means that dump was interrupted and result may be
> >> wrong. Ask user to restart.
> >>
> >> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> >
> >
> > Do we have a guarantee this will complete eventually, on some hosts
> > constantly adding removing entries ?
> >
>
> No. You mean it will be better to just print a warning and continue the dump?
> --
I would not break the dump, return the indication, so that caller can
chose to restart the loop one or two times.
^ permalink raw reply
* Re: [PATCH] ath9k : Fix ieee80211 work while going to suspend
From: Luis R. Rodriguez @ 2013-03-22 15:08 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: John W. Linville, Parag Warudkar, Jouni Malinen,
Vasanthakumar Thiagarajan, linux-wireless, ath9k-devel, netdev,
LKML, senthilb
In-Reply-To: <20130322091342.GB1496@redhat.com>
On Fri, Mar 22, 2013 at 10:13:42AM +0100, Stanislaw Gruszka wrote:
> On Thu, Mar 21, 2013 at 12:33:31PM -0700, Luis R. Rodriguez wrote:
> > OK how about this for stable for now:
> >
> > diff --git a/drivers/net/wireless/ath/ath9k/link.c b/drivers/net/wireless/ath/ath9k/link.c
> > index 39c84ec..7fdac6c 100644
> > --- a/drivers/net/wireless/ath/ath9k/link.c
> > +++ b/drivers/net/wireless/ath/ath9k/link.c
> > @@ -170,7 +170,8 @@ void ath_rx_poll(unsigned long data)
> > {
> > struct ath_softc *sc = (struct ath_softc *)data;
> >
> > - ieee80211_queue_work(sc->hw, &sc->hw_check_work);
> > + if (!test_bit(SC_OP_INVALID, &sc->sc_flags))
> > + ieee80211_queue_work(sc->hw, &sc->hw_check_work);
> > }
>
> That looks ok for me as -stable fix
>
> Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
Parag, can you test the above to ensure it fixes your issue ?
Luis
^ permalink raw reply
* Re: [PATCH iproute2] libnetlink: check flag NLM_F_DUMP_INTR during dumps
From: Nicolas Dichtel @ 2013-03-22 15:03 UTC (permalink / raw)
To: Eric Dumazet; +Cc: shemminger, netdev
In-Reply-To: <1363964393.4431.66.camel@edumazet-glaptop>
Le 22/03/2013 15:59, Eric Dumazet a écrit :
> On Fri, 2013-03-22 at 15:45 +0100, Nicolas Dichtel wrote:
>> When this flag is set, it means that dump was interrupted and result may be
>> wrong. Ask user to restart.
>>
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>
>
> Do we have a guarantee this will complete eventually, on some hosts
> constantly adding removing entries ?
>
No. You mean it will be better to just print a warning and continue the dump?
^ permalink raw reply
* Re: [PATCH] net: Add support for handling queueing in hardware
From: Eric Dumazet @ 2013-03-22 15:01 UTC (permalink / raw)
To: Ben Collins; +Cc: linux-kernel, netdev
In-Reply-To: <63463136-FE5B-462D-9259-53DD5AC61BDB@gmail.com>
On Fri, 2013-03-22 at 10:50 -0400, Ben Collins wrote:
>
> NETIF_F_LLTX_BIT, /* LockLess TX - deprecated. Please */
> /* do not use LLTX in new drivers */
Yes, but this is the current way to do that.
Unless you design a complete new layer to replace it.
^ permalink raw reply
* Re: [PATCH iproute2] libnetlink: check flag NLM_F_DUMP_INTR during dumps
From: Eric Dumazet @ 2013-03-22 14:59 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: shemminger, netdev
In-Reply-To: <1363963557-3888-1-git-send-email-nicolas.dichtel@6wind.com>
On Fri, 2013-03-22 at 15:45 +0100, Nicolas Dichtel wrote:
> When this flag is set, it means that dump was interrupted and result may be
> wrong. Ask user to restart.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Do we have a guarantee this will complete eventually, on some hosts
constantly adding removing entries ?
^ permalink raw reply
* Re: [PATCH] tcp: preserve ACK clocking in TSO
From: Eric Dumazet @ 2013-03-22 14:52 UTC (permalink / raw)
To: David Miller; +Cc: netdev, ycheng, ncardwell, nanditad, vanj
In-Reply-To: <20130322.103435.879689479406836333.davem@davemloft.net>
On Fri, 2013-03-22 at 10:34 -0400, David Miller wrote:
> I always wondered about this, good catch.
>
> Applied and queued up for -stable, thanks!
It took me a while to see the light.
I was trying to reduce the time limit (2 ticks -> 1 tick), or remove
tso_deferred field to use lsndtime instead.
Then, before cooking the patch for net-next, I finally understood the
problem.
Thanks
^ permalink raw reply
* Re: [PATCH] net: Add support for handling queueing in hardware
From: Ben Collins @ 2013-03-22 14:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, netdev
In-Reply-To: <1363962193.4431.59.camel@edumazet-glaptop>
On Mar 22, 2013, at 10:23 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2011-07-13 at 08:52 -0500, Andy Fleming wrote:
>> The QDisc code does a bunch of locking which is unnecessary if
>> you have hardware which handles all of the queueing. Add
>> support for this, and skip over all of the queueing code if
>> the feature is enabled on a given device, which breaks QDisc
>> support on dpaa_eth, and also coopts the FCOE feature bit.
>>
>> Signed-off-by: Andy Fleming <afleming@freescale.com>
>> Signed-off-by: Ben Collins <ben.c@servergy.com>
>> Cc: netdev@vger.kernel.org
>> ---
>> include/linux/netdev_features.h | 2 ++
>> net/core/dev.c | 6 ++++++
>> 2 files changed, 8 insertions(+)
>>
>> diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
>> index 3dd3934..ffb4587 100644
>> --- a/include/linux/netdev_features.h
>> +++ b/include/linux/netdev_features.h
>> @@ -56,6 +56,7 @@ enum {
>> NETIF_F_LOOPBACK_BIT, /* Enable loopback */
>> NETIF_F_RXFCS_BIT, /* Append FCS to skb pkt data */
>> NETIF_F_RXALL_BIT, /* Receive errored frames too */
>> + NETIF_F_HW_QDISC_BIT, /* Supports hardware Qdisc */
>>
>> /*
>> * Add your fresh new feature above and remember to update
>> @@ -80,6 +81,7 @@ enum {
>> #define NETIF_F_GSO_ROBUST __NETIF_F(GSO_ROBUST)
>> #define NETIF_F_HIGHDMA __NETIF_F(HIGHDMA)
>> #define NETIF_F_HW_CSUM __NETIF_F(HW_CSUM)
>> +#define NETIF_F_HW_QDISC __NETIF_F(HW_QDISC)
>> #define NETIF_F_HW_VLAN_FILTER __NETIF_F(HW_VLAN_FILTER)
>> #define NETIF_F_HW_VLAN_RX __NETIF_F(HW_VLAN_RX)
>> #define NETIF_F_HW_VLAN_TX __NETIF_F(HW_VLAN_TX)
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index dffbef7..6818b18 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -2743,6 +2743,12 @@ int dev_queue_xmit(struct sk_buff *skb)
>>
>> skb_update_prio(skb);
>>
>> + if (dev->features & NETIF_F_HW_QDISC) {
>> + txq = netdev_pick_tx(dev, skb);
>> + rc = dev_hard_start_xmit(skb, dev, txq);
>> + goto out;
>> + }
>> +
>> txq = netdev_pick_tx(dev, skb);
>> q = rcu_dereference_bh(txq->qdisc);
>>
>
> Nobody forces you to use a qdisc.
>
> And if your device really is lockless, it can use NETIF_F_LLTX feature.
NETIF_F_LLTX_BIT, /* LockLess TX - deprecated. Please */
/* do not use LLTX in new drivers */
--
Servergy : http://www.servergy.com/
SwissDisk : http://www.swissdisk.com/
Ubuntu : http://www.ubuntu.com/
My Blog : http://ben-collins.blogspot.com/
^ permalink raw reply
* Re: [PATCH] net: Fix tentative IPv6 address due to DAD looping back
From: Eric Dumazet @ 2013-03-22 14:47 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Meng, Jilin, davem@davemloft.net, kuznet@ms2.inr.ac.ru,
jmorris@namei.org, yoshfuji@linux-ipv6.org, kaber@trash.net,
Sun, Yinglin, Prithviraj, Lakshmanan, netdev@vger.kernel.org
In-Reply-To: <514C6CAA.2090902@cogentembedded.com>
On Fri, 2013-03-22 at 18:37 +0400, Sergei Shtylyov wrote:
> Don't we have memcmp() in Linux?
>
Dont use slow memcmp() in this context but fast
ether_addr_equal_64bits()
^ permalink raw reply
* [PATCH iproute2] libnetlink: check flag NLM_F_DUMP_INTR during dumps
From: Nicolas Dichtel @ 2013-03-22 14:45 UTC (permalink / raw)
To: shemminger; +Cc: netdev, Nicolas Dichtel
When this flag is set, it means that dump was interrupted and result may be
wrong. Ask user to restart.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
lib/libnetlink.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/lib/libnetlink.c b/lib/libnetlink.c
index f262959..91991cf 100644
--- a/lib/libnetlink.c
+++ b/lib/libnetlink.c
@@ -230,6 +230,12 @@ int rtnl_dump_filter_l(struct rtnl_handle *rth,
h->nlmsg_seq != rth->dump)
goto skip_it;
+ if (h->nlmsg_flags & NLM_F_DUMP_INTR) {
+ fprintf(stderr,
+ "Dump was interrupted, please restart.\n");
+ return -1;
+ }
+
if (h->nlmsg_type == NLMSG_DONE) {
found_done = 1;
break; /* process next filter */
--
1.8.0.1
^ permalink raw reply related
* Re: [net-next.git 0/9] stmmac: update to March_2013 (adding PTP & RGMII/SGMII)
From: Giuseppe CAVALLARO @ 2013-03-22 14:27 UTC (permalink / raw)
To: netdev; +Cc: David Miller, bh74.an, rayagond, Richard Cochran
In-Reply-To: <513D839A.8000009@st.com>
On 3/11/2013 8:11 AM, Giuseppe CAVALLARO wrote:
[snip]
> At any case, I'll arrange to change the code removing the Koption and
> continuing (as done in the past) to setup at probe time the right
> configuration. This will be in the next version of the patches.
I've finally completed this task and I've reworked all the code to
completely remove the Koption (also for chain/ring mode).
Now all is done at probe time as discussed in this email thread.
On top of this, the PTP will be ported with Richard's advice
Pls let me know if there are other suggestions about the patches, I have
sent, so I can review and update them before resending the new versions.
peppe
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* Re: [PATCH] net: Add support for handling queueing in hardware
From: Ben Collins @ 2013-03-22 14:43 UTC (permalink / raw)
To: David Miller; +Cc: afleming, linux-kernel, netdev
In-Reply-To: <20130322.103302.1277256650283142022.davem@davemloft.net>
On Mar 22, 2013, at 10:33 AM, David Miller <davem@davemloft.net> wrote:
> From: Fleming Andy-AFLEMING <afleming@freescale.com>
> Date: Fri, 22 Mar 2013 14:31:50 +0000
>
>> It would appear one of our customers is attempting to upstream our
>> code for us. We are aware that this current solution is unacceptable
>> (which is why we have not submitted it), and we are currently trying
>> to develop a less hacky solution that integrates with qdisc.
>
> Ben, can can you coordinate with people instead of doing crap like
> this?
"For us" is a loose term, when it's more that we are attempting to upstream code so our system is supported by a mainline kernel instead of having one-off kernels.
And we have been talking with Freescale about this for quite some time (couple years?). They have a roadmap that doesn't include getting this driver supported in mainline any time soon, so I'm taking time to get this done for our own system. I'm not meaning to step on any toes.
Believe me, I've attempted to make this as painless as possible. Only having 5 patches (and each just a few lines) is significantly less than how this driver started out. I can toss out the QDisc patch and work on a better way. I'm not totally familiar with the queueing, so any pointers to a better way to handle this would be appreciated.
--
Servergy : http://www.servergy.com/
SwissDisk : http://www.swissdisk.com/
Ubuntu : http://www.ubuntu.com/
My Blog : http://ben-collins.blogspot.com/
^ permalink raw reply
* [PATCH net-next 2/2] ipv6: provide addr and netconf dump consistency info
From: Nicolas Dichtel @ 2013-03-22 14:42 UTC (permalink / raw)
To: netdev; +Cc: davem, junwei.zhang, hongjun.li, Nicolas Dichtel
In-Reply-To: <1363963360-3603-1-git-send-email-nicolas.dichtel@6wind.com>
This patch adds a dev_addr_genid for IPv6. The goal is to use it, combined with
dev_base_seq to check if a change occurs during a netlink dump.
If a change is detected, the flag NLM_F_DUMP_INTR is set in the first message
after the dump was interrupted.
Note that only dump of unicast addresses is checked (multicast and anycast are
not checked).
Reported-by: Junwei Zhang <junwei.zhang@6wind.com>
Reported-by: Hongjun Li <hongjun.li@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
include/net/netns/ipv6.h | 1 +
net/ipv6/addrconf.c | 8 ++++++++
2 files changed, 9 insertions(+)
diff --git a/include/net/netns/ipv6.h b/include/net/netns/ipv6.h
index 1242f37..005e2c2 100644
--- a/include/net/netns/ipv6.h
+++ b/include/net/netns/ipv6.h
@@ -71,6 +71,7 @@ struct netns_ipv6 {
struct fib_rules_ops *mr6_rules_ops;
#endif
#endif
+ atomic_t dev_addr_genid;
};
#if IS_ENABLED(CONFIG_NF_DEFRAG_IPV6)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index fa36a67..d0e40d4 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -622,6 +622,8 @@ static int inet6_netconf_dump_devconf(struct sk_buff *skb,
idx = 0;
head = &net->dev_index_head[h];
rcu_read_lock();
+ cb->seq = atomic_read(&net->ipv6.dev_addr_genid) ^
+ net->dev_base_seq;
hlist_for_each_entry_rcu(dev, head, index_hlist) {
if (idx < s_idx)
goto cont;
@@ -639,6 +641,7 @@ static int inet6_netconf_dump_devconf(struct sk_buff *skb,
rcu_read_unlock();
goto done;
}
+ nl_dump_check_consistent(cb, nlmsg_hdr(skb));
cont:
idx++;
}
@@ -3875,6 +3878,7 @@ static int in6_dump_addrs(struct inet6_dev *idev, struct sk_buff *skb,
NLM_F_MULTI);
if (err <= 0)
break;
+ nl_dump_check_consistent(cb, nlmsg_hdr(skb));
}
break;
}
@@ -3932,6 +3936,7 @@ static int inet6_dump_addr(struct sk_buff *skb, struct netlink_callback *cb,
s_ip_idx = ip_idx = cb->args[2];
rcu_read_lock();
+ cb->seq = atomic_read(&net->ipv6.dev_addr_genid) ^ net->dev_base_seq;
for (h = s_h; h < NETDEV_HASHENTRIES; h++, s_idx = 0) {
idx = 0;
head = &net->dev_index_head[h];
@@ -4409,6 +4414,8 @@ errout:
static void __ipv6_ifa_notify(int event, struct inet6_ifaddr *ifp)
{
+ struct net *net = dev_net(ifp->idev->dev);
+
inet6_ifa_notify(event ? : RTM_NEWADDR, ifp);
switch (event) {
@@ -4434,6 +4441,7 @@ static void __ipv6_ifa_notify(int event, struct inet6_ifaddr *ifp)
dst_free(&ifp->rt->dst);
break;
}
+ atomic_inc(&net->ipv6.dev_addr_genid);
}
static void ipv6_ifa_notify(int event, struct inet6_ifaddr *ifp)
--
1.8.0.1
^ permalink raw reply related
* [PATCH net-next 1/2] ipv4: provide addr and netconf dump consistency info
From: Nicolas Dichtel @ 2013-03-22 14:42 UTC (permalink / raw)
To: netdev; +Cc: davem, junwei.zhang, hongjun.li, Nicolas Dichtel
This patch takes benefit of dev_addr_genid and dev_base_seq to check if a change
occurs during a netlink dump. If a change is detected, the flag NLM_F_DUMP_INTR
is set in the first message after the dump was interrupted.
Reported-by: Junwei Zhang <junwei.zhang@6wind.com>
Reported-by: Hongjun Li <hongjun.li@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv4/devinet.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index af57bba..158ca5e 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1499,6 +1499,8 @@ static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
idx = 0;
head = &net->dev_index_head[h];
rcu_read_lock();
+ cb->seq = atomic_read(&net->ipv4.dev_addr_genid) ^
+ net->dev_base_seq;
hlist_for_each_entry_rcu(dev, head, index_hlist) {
if (idx < s_idx)
goto cont;
@@ -1519,6 +1521,7 @@ static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
rcu_read_unlock();
goto done;
}
+ nl_dump_check_consistent(cb, nlmsg_hdr(skb));
}
cont:
idx++;
@@ -1808,6 +1811,8 @@ static int inet_netconf_dump_devconf(struct sk_buff *skb,
idx = 0;
head = &net->dev_index_head[h];
rcu_read_lock();
+ cb->seq = atomic_read(&net->ipv4.dev_addr_genid) ^
+ net->dev_base_seq;
hlist_for_each_entry_rcu(dev, head, index_hlist) {
if (idx < s_idx)
goto cont;
@@ -1825,6 +1830,7 @@ static int inet_netconf_dump_devconf(struct sk_buff *skb,
rcu_read_unlock();
goto done;
}
+ nl_dump_check_consistent(cb, nlmsg_hdr(skb));
cont:
idx++;
}
--
1.8.0.1
^ permalink raw reply related
* Re: [PATCH] net: Fix tentative IPv6 address due to DAD looping back
From: Sergei Shtylyov @ 2013-03-22 14:37 UTC (permalink / raw)
To: Meng, Jilin
Cc: davem@davemloft.net, kuznet@ms2.inr.ac.ru, jmorris@namei.org,
yoshfuji@linux-ipv6.org, kaber@trash.net, Sun, Yinglin,
Prithviraj, Lakshmanan, netdev@vger.kernel.org
In-Reply-To: <D6EA916C7149064CB4D5C686612478A3183E2D27D1@MX34A.corp.emc.com>
Hello.
On 22-03-2013 7:20, Meng, Jilin wrote:
> we should ignore the looped-back IPv6 DAD packet to avoid configuration failure.
> This occurs when a bonding interface with roundrobin mode is being configured an IPv6 address
> while the switch side isn't configured bonding/channel yet.
> Signed-off-by: Jilin Meng <jilin.meng@emc.com>
> Signed-off-by: Yinglin Sun <yinglin.sun@emc.com>
> Signed-off-by: Lakshmanan Prithviraj <lakshmanan.prithviraj@emc.com>
> ---
> --- linux/net/ipv6/ndisc.c.orig 2013-03-12 17:16:18.000000000 +0800
> +++ linux/net/ipv6/ndisc.c 2013-03-21 10:37:06.000000000 +0800
> @@ -757,6 +757,24 @@ static void ndisc_recv_ns(struct sk_buff
>
> if (ifp->flags & (IFA_F_TENTATIVE|IFA_F_OPTIMISTIC)) {
> if (dad) {
> + if (dev->type == ARPHRD_ETHER) {
> + const unsigned char *sadr;
Empty line after declaration wouldn't hurt.
> + sadr = skb_mac_header(skb);
> + if (sadr[6] == dev->dev_addr[0] &&
> + sadr[7] == dev->dev_addr[1] &&
> + sadr[8] == dev->dev_addr[2] &&
> + sadr[9] == dev->dev_addr[3] &&
> + sadr[10] == dev->dev_addr[4] &&
> + sadr[11] == dev->dev_addr[5]) {
Don't we have memcmp() in Linux?
WBR, Sergei
^ permalink raw reply
* Re: [git pull] firewire net: resource management improvements
From: David Miller @ 2013-03-22 14:35 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev, stefanr, linux1394-devel
In-Reply-To: <1363923263.16608.14.camel@cirrhata>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Fri, 22 Mar 2013 12:34:23 +0900
> would you consider pulling this one to net-next, please?
> I can prepare rebased tree, if you want.
So the firewire maintainers are OK with these changes?
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
^ permalink raw reply
* Re: [PATCH] tcp: preserve ACK clocking in TSO
From: David Miller @ 2013-03-22 14:34 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ycheng, ncardwell, nanditad, vanj
In-Reply-To: <1363923369.4431.53.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 21 Mar 2013 20:36:09 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> A long standing problem with TSO is the fact that tcp_tso_should_defer()
> rearms the deferred timer, while it should not.
...
> Signed-off-by: Eric Dumazet <edumazet@google.com>
I always wondered about this, good catch.
Applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH] phy: Add XGMII phy interface type
From: Ben Collins @ 2013-03-22 14:33 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, netdev
In-Reply-To: <20130322.102738.100763719710671227.davem@davemloft.net>
On Mar 22, 2013, at 10:27 AM, David Miller <davem@davemloft.net> wrote:
> From: Ben Collins <benmcollins13@gmail.com>
> Date: Fri, 22 Mar 2013 10:22:05 -0400
>
>> It's code that I've manually stripped down as a subset of a larger
>> code base for Freescale's DPAA driver. I've only tested it on our
>> (Servergy's) platform, so until it gets more broad testing (and some
>> code review), I want to at least get it into staging so our hardware
>> is supported.
>
> Then why don't you submit the PHY type addition with the staging
> driver, which will be the only user, and you can add my:
>
> Acked-by: David S. Miller <davem@davemloft.net>
That I can do. Greg had asked I get all the rest of this signed off before he could take the driver into staging.
--
Servergy : http://www.servergy.com/
SwissDisk : http://www.swissdisk.com/
Ubuntu : http://www.ubuntu.com/
My Blog : http://ben-collins.blogspot.com/
^ permalink raw reply
* Re: [PATCH] net: Add support for handling queueing in hardware
From: David Miller @ 2013-03-22 14:33 UTC (permalink / raw)
To: afleming; +Cc: linux-kernel, netdev, ben.c
In-Reply-To: <A5ACC15C-361D-48E6-BFFF-9AA3966C2A68@freescale.com>
From: Fleming Andy-AFLEMING <afleming@freescale.com>
Date: Fri, 22 Mar 2013 14:31:50 +0000
> It would appear one of our customers is attempting to upstream our
> code for us. We are aware that this current solution is unacceptable
> (which is why we have not submitted it), and we are currently trying
> to develop a less hacky solution that integrates with qdisc.
Ben, can can you coordinate with people instead of doing crap like
this?
^ permalink raw reply
* Re: [PATCH net-next 1/2] decnet: Parse netlink attributes on our own
From: Steven Whitehouse @ 2013-03-22 14:29 UTC (permalink / raw)
To: Thomas Graf; +Cc: davem, netdev, linux-decnet-user
In-Reply-To: <20130322142735.GA11368@casper.infradead.org>
Hi,
On Fri, 2013-03-22 at 14:27 +0000, Thomas Graf wrote:
> On 03/21/13 at 06:04pm, Steven Whitehouse wrote:
> > You shouldn't need any special hardware to test this. A copy of iproute2
> > should be enough as you should be able to use that to create an
> > interface or two and a route between them, etc. Although DECnet routing
> > works in a different way to ip routing, the Linux implementation tries
> > to stick fairly closely to the ip way of doing things whenever it can in
> > order to share infrastructure. Now that ip has diverged a fair bit over
> > time that isn't quite as true as it was, but there shouldn't be anything
> > too surprising in there.
>
> Alright, I did some basic testing with iproute2. I do not claim
> to understand what I did but I ran the following:
>
> $ ip -f dnet route add 1.661 dev em1
> $ ip -f dnet route list
> 1.661 dev em1 scope link
>
> $ ip -f dnet neigh add 6.662 dev em1
> $ ip -f dnet neigh list
> 6.662 dev em1 lladdr aa:00:04:00:96:1a PERMANENT
>
> $ ip -f dnet addr add 1.111 dev em1
> $ ip -f dnet addr list
> 2: em1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
> dnet 1.111/16 scope global em1
That looks sane to me. The only thing I could think of to add to that
list would be to use ip route get to do a lookup, but otherwise, that
seems to cover everything pretty much,
Steve.
^ permalink raw reply
* Re: [PATCH] net: Add support for handling queueing in hardware
From: Fleming Andy-AFLEMING @ 2013-03-22 14:31 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20130322.101139.1942128058226201237.davem@davemloft.net>
On Mar 22, 2013, at 9:11, "David Miller" <davem@davemloft.net> wrote:
> From: Andy Fleming <afleming@freescale.com>
> Date: Wed, 13 Jul 2011 08:52:04 -0500
>
>> The QDisc code does a bunch of locking which is unnecessary if
>> you have hardware which handles all of the queueing. Add
>> support for this, and skip over all of the queueing code if
>> the feature is enabled on a given device, which breaks QDisc
>> support on dpaa_eth, and also coopts the FCOE feature bit.
>>
>> Signed-off-by: Andy Fleming <afleming@freescale.com>
>> Signed-off-by: Ben Collins <ben.c@servergy.com>
>
> Sorry, no.
>
> If we are going to support something like this then there needs to
> be full coordination, configuration wise, so that if we enable
> a qdisc that the hardware supports we submit it directly, but if
> we enable a qdisc the HW does not support, we still use the software
> qdisc.
>
> This also means that we need to have a way to determine if the qdisc
> configuration exceeds that parametorial limits of the device's HW
> capabilities, and fallback to software qdisc in those cases too.
It would appear one of our customers is attempting to upstream our code for us. We are aware that this current solution is unacceptable (which is why we have not submitted it), and we are currently trying to develop a less hacky solution that integrates with qdisc.
Andy
^ permalink raw reply
* Re: [PATCH net-next 1/2] decnet: Parse netlink attributes on our own
From: David Miller @ 2013-03-22 14:31 UTC (permalink / raw)
To: tgraf; +Cc: swhiteho, netdev, linux-decnet-user
In-Reply-To: <20130322142735.GA11368@casper.infradead.org>
From: Thomas Graf <tgraf@suug.ch>
Date: Fri, 22 Mar 2013 14:27:35 +0000
> On 03/21/13 at 06:04pm, Steven Whitehouse wrote:
>> You shouldn't need any special hardware to test this. A copy of iproute2
>> should be enough as you should be able to use that to create an
>> interface or two and a route between them, etc. Although DECnet routing
>> works in a different way to ip routing, the Linux implementation tries
>> to stick fairly closely to the ip way of doing things whenever it can in
>> order to share infrastructure. Now that ip has diverged a fair bit over
>> time that isn't quite as true as it was, but there shouldn't be anything
>> too surprising in there.
>
> Alright, I did some basic testing with iproute2. I do not claim
> to understand what I did but I ran the following:
>
> $ ip -f dnet route add 1.661 dev em1
> $ ip -f dnet route list
> 1.661 dev em1 scope link
>
> $ ip -f dnet neigh add 6.662 dev em1
> $ ip -f dnet neigh list
> 6.662 dev em1 lladdr aa:00:04:00:96:1a PERMANENT
>
> $ ip -f dnet addr add 1.111 dev em1
> $ ip -f dnet addr list
> 2: em1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
> dnet 1.111/16 scope global em1
That's good enough for me, both patches applied, thanks Thomas!
^ permalink raw reply
* Re: [PATCH 0/4 v3] mv643xx_eth: use mvmdio MDIO bus driver
From: Florian Fainelli @ 2013-03-22 14:31 UTC (permalink / raw)
To: Jason Cooper
Cc: davem, Grant Likely, Rob Herring, Rob Landley, Andrew Lunn,
Russell King, Benjamin Herrenschmidt, Paul Mackerras,
Lennert Buytenhek, Thomas Petazzoni, Greg Kroah-Hartman,
devicetree-discuss, linux-doc, linux-kernel, linux-arm-kernel,
linuxppc-dev, netdev
In-Reply-To: <20130322142924.GK13280@titan.lakedaemon.net>
Le 03/22/13 15:29, Jason Cooper a écrit :
>> Ok, thanks! Does that mean that you want these changes to go via
>> your tree? David initially applied my v2 of this patchset, and since
>> it thouches mostly ethernet driver stuff, I would rather make it go
>> via his tree if both of you agree.
>
> Yeah, I thought I should have reworded that after I hit send :) I
> simply meant it applied cleanly against v3.9-rc3, booted, and worked. I
> Acked it so David could take the whole series through his tree. Sorry
> for the confusion.
>
> Now that I can build mv643xx_eth DT on top of this, I'll structure it so
> those changes go on top of yours (in David's tree) and try to avoid the
> external dependency for the DT bits going though arm-soc.
Sounds good! FYI, I am finishing up DSA Device Tree bindings so that we
can finally get rid of board-specific Kirkwood files.
--
Florian
^ permalink raw reply
* Re: [PATCH 0/4 v3] mv643xx_eth: use mvmdio MDIO bus driver
From: Jason Cooper @ 2013-03-22 14:29 UTC (permalink / raw)
To: Florian Fainelli
Cc: davem, Grant Likely, Rob Herring, Rob Landley, Andrew Lunn,
Russell King, Benjamin Herrenschmidt, Paul Mackerras,
Lennert Buytenhek, Thomas Petazzoni, Greg Kroah-Hartman,
devicetree-discuss, linux-doc, linux-kernel, linux-arm-kernel,
linuxppc-dev, netdev
In-Reply-To: <514C69B7.8090106@openwrt.org>
On Fri, Mar 22, 2013 at 03:24:55PM +0100, Florian Fainelli wrote:
> Le 03/22/13 15:14, Jason Cooper a écrit :
> >On Fri, Mar 22, 2013 at 02:39:24PM +0100, Florian Fainelli wrote:
> >>Hi all,
> >>
> >>This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver
> >>instead of rolling its own implementation. As a result, all users of this
> >>mv643xx_eth driver are converted to register an "orion-mdio" platform_device.
> >>The mvmdio driver is also updated to support an interrupt line which reports
> >>SMI error/completion, and to allow traditionnal platform device registration
> >>instead of just device tree.
> >>
> >>David, I think it makes sense for you to merge all of this, since we do
> >>not want the architecture files to be desynchronized from the mv643xx_eth to
> >>avoid runtime breakage. The potential for merge conflicts should be very small.
> >>
> >>Florian Fainelli (4):
> >> net: mvmdio: allow platform device style registration
> >> net: mvmdio: rename base register cookie from smireg to regs
> >> net: mvmdio: enhance driver to support SMI error/done interrupts
> >> mv643xx_eth: convert to use the Marvell Orion MDIO driver
> >>
> >> .../devicetree/bindings/net/marvell-orion-mdio.txt | 3 +
> >> arch/arm/plat-orion/common.c | 54 +++---
> >> arch/powerpc/platforms/chrp/pegasos_eth.c | 20 ++
> >> arch/powerpc/sysdev/mv64x60_dev.c | 16 +-
> >> drivers/net/ethernet/marvell/Kconfig | 5 +-
> >> drivers/net/ethernet/marvell/Makefile | 2 +-
> >> drivers/net/ethernet/marvell/mv643xx_eth.c | 195 ++------------------
> >> drivers/net/ethernet/marvell/mvmdio.c | 130 ++++++++++---
> >> include/linux/mv643xx_eth.h | 1 -
> >> 9 files changed, 187 insertions(+), 239 deletions(-)
> >
> >Whole series applied on top of v3.9-rc3 and tested on dreamplug
> >(kirkwood DT boot with legacy mv643xx_eth init)
>
> Ok, thanks! Does that mean that you want these changes to go via
> your tree? David initially applied my v2 of this patchset, and since
> it thouches mostly ethernet driver stuff, I would rather make it go
> via his tree if both of you agree.
Yeah, I thought I should have reworded that after I hit send :) I
simply meant it applied cleanly against v3.9-rc3, booted, and worked. I
Acked it so David could take the whole series through his tree. Sorry
for the confusion.
Now that I can build mv643xx_eth DT on top of this, I'll structure it so
those changes go on top of yours (in David's tree) and try to avoid the
external dependency for the DT bits going though arm-soc.
thx,
Jason.
^ permalink raw reply
* RE: [PATCH -next] caif_virtio: fix error return code in cfv_create_genpool()
From: Sjur BRENDELAND @ 2013-03-22 14:27 UTC (permalink / raw)
To: David Miller, weiyj.lk@gmail.com
Cc: rusty@rustcorp.com.au, yongjun_wei@trendmicro.com.cn,
netdev@vger.kernel.org
In-Reply-To: <20130322.102425.1728735565421860819.davem@davemloft.net>
> From: David Miller [mailto:davem@davemloft.net]
> > From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> >
> > Fix to return a negative error code from the error handling
> > case instead of 0, as returned elsewhere in this function.
> >
> > Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> > ---
> > drivers/net/caif/caif_virtio.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
>
> I can't apply this as this file doesn't exist in my tree.
caif_virtio.c lives in Rusty's "virtio-next" tree.
I guess this patch should have been tagged "virtio-next" instead.
Thanks,
Sjur
^ 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