* Re: [PATCH RFC 2/2] ipv6: Add support for IPsec virtual tunnel interfaces
From: Steffen Klassert @ 2013-08-27 11:08 UTC (permalink / raw)
To: Dan Williams; +Cc: netdev
In-Reply-To: <1377535058.11709.21.camel@dcbw.foobar.com>
On Mon, Aug 26, 2013 at 11:37:38AM -0500, Dan Williams wrote:
> On Mon, 2013-08-19 at 08:27 +0200, Steffen Klassert wrote:
> > This patch adds IPv6 support for IPsec virtual tunnel interfaces
> > (vti). IPsec virtual tunnel interfaces provide a routable interface
> > for IPsec tunnel endpoints.
>
> Are new ioctls for this kind of thing kosher? Or should it be using
> netlink instead?
>
Well, I used the existing interface that all tunnels use. In particular
the vti tunnel for ipv4 uses it and the ipv6 side should be similar.
We could extend the netlink interface for tunnels of course, but that's
another issue.
^ permalink raw reply
* Re: [RFC PATCH] bridge: inherit slave devices needed_headroom
From: Florian Fainelli @ 2013-08-27 11:04 UTC (permalink / raw)
To: Amos Kong
Cc: netdev, Stephen Hemminger, Eric Dumazet, Vlad Yasevich,
David Miller
In-Reply-To: <CAFeW=pY2xT7DB-Wrpi7MSyri5UD1quR76PR5ziv+YkNmC2L5TQ@mail.gmail.com>
2013/8/23 Amos Kong <kongjianjun@gmail.com>:
> On Tue, Aug 20, 2013 at 5:21 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> Some slave devices may have set a dev->needed_headroom value which is
>> different than the default one, most likely in order to prepend a
>> hardware descriptor in front of the Ethernet frame to send. Whenever a
>> new slave is added to a bridge, ensure that we update the
>> needed_headroom value accordingly to account for the slave
>> needed_headroom value.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> net/bridge/br_if.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
>> index aa6c9a8..c41d5fb 100644
>> --- a/net/bridge/br_if.c
>> +++ b/net/bridge/br_if.c
>> @@ -383,6 +383,9 @@ int br_add_if(struct net_bridge *br, struct net_device *dev)
>>
>> netdev_update_features(br->dev);
>>
>> + if (br->dev->needed_headroom < dev->needed_headroom)
>> + br->dev->needed_headroom = dev->needed_headroom;
>> +
>
> do we need to update 'br->dev->needed_headroom' in br_del_if()?
>
> if (br->dev->needed_headroom == dev->needed_headroom)
> br->dev->needed_headroom = ....;
In theory yes, we should recompute the minimum headroom which is
common to all bridge members. This is something that I want to address
separately though with the NETDEV_CHANGEROOM notifier.
--
Florian
^ permalink raw reply
* [PATCH] bridge: inherit slave devices needed_headroom
From: Florian Fainelli @ 2013-08-27 11:03 UTC (permalink / raw)
To: netdev; +Cc: stephen, davem, vyasevic, eric.dumazet, Florian Fainelli
Some slave devices may have set a dev->needed_headroom value which is
different than the default one, most likely in order to prepend a
hardware descriptor in front of the Ethernet frame to send. Whenever a
new slave is added to a bridge, ensure that we update the
needed_headroom value accordingly to account for the slave
needed_headroom value.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
net/bridge/br_if.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index aa6c9a8..c41d5fb 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -383,6 +383,9 @@ int br_add_if(struct net_bridge *br, struct net_device *dev)
netdev_update_features(br->dev);
+ if (br->dev->needed_headroom < dev->needed_headroom)
+ br->dev->needed_headroom = dev->needed_headroom;
+
spin_lock_bh(&br->lock);
changed_addr = br_stp_recalculate_bridge_id(br);
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH net-next v1 1/9] net: add netdev_upper_get_next_dev(dev, iter)
From: Veaceslav Falico @ 2013-08-27 10:42 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, David S. Miller, Eric Dumazet, Alexander Duyck, Cong Wang
In-Reply-To: <20130826205748.GB3723@minipsycho.orion>
On Mon, Aug 26, 2013 at 10:57:48PM +0200, Jiri Pirko wrote:
>Mon, Aug 26, 2013 at 10:32:34PM CEST, vfalico@redhat.com wrote:
...snip...
>>+struct net_device *netdev_upper_get_next_dev(struct net_device *dev,
>>+ struct list_head **iter)
>
> This should be probably rather named
> "netdev_upper_get_next_dev_rcu" That way it is clear
> right away. Also if you introduce non-rcu variant in
> future, you won't introduce confusion :)
Agreed, it will be easier, will do in v2.
^ permalink raw reply
* Re: Is fallback vhost_net to qemu for live migrate available？
From: Wei Liu @ 2013-08-27 9:41 UTC (permalink / raw)
To: Qin Chuanyu
Cc: Michael S. Tsirkin, jasowang, kvm, netdev, qianhuibin, wangfuhai,
wei.liu2
In-Reply-To: <521C4F96.8000103@huawei.com>
First of all, good job, Chuanyu. :-)
On Tue, Aug 27, 2013 at 03:04:54PM +0800, Qin Chuanyu wrote:
[...]
> >.
> >
> Thanks for your reply.
>
> In fact，I am not sure that whether vhost_log could work on Xen live
> migrate or not. Yes，vhost_sync_dirty_bitmap work well on Kvm，but
> vhost_net havn't run on Xen before，although the method
> vhost_dev_sync_region -> memory_region_set_dirty ->
> xen_modified_memory call sequence exist.
>
For Xen-specific questions you might have better luck posting to
xen-devel@lists.xenproject.org.
And I think this project is interesting enough and of benificial to Xen
community as well. Could you CC Xen-devel@ for future updates?
Thanks
Wei.
> Have you considered the scene that vhost_migration_log code running
> on Xen？ If yes，it sames much easier then fallback datapath from
> vhost_net to qemu for live migrate.
>
>
> --
> 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-next] {ipv4,xfrm}: Introduce xfrm_tunnel_notifier for xfrm tunnel mode callback
From: Steffen Klassert @ 2013-08-27 9:28 UTC (permalink / raw)
To: Fan Du; +Cc: David Miller, saurabh.mohan, herbert, netdev
In-Reply-To: <521C0104.2070906@windriver.com>
On Tue, Aug 27, 2013 at 09:29:40AM +0800, Fan Du wrote:
> On 2013年08月27日 04:21, David Miller wrote:
> >
> >I don't understand why VTI doesn't need to propagate a PMTU update via
> >ipv4_update_pmtu(). Why is it different from a real xfrm_tunnel?
> ^^^^^^^^^^^^^^^^
>
> A IPsec protected packet is first handled by protocol handlers, e.g AH/ESP,
> to check packet authentication or encryption rightness. PMTU update is taken
> care of in this stage by protocol error handler.
>
> Then the packet is rearranged properly depending on whether it's transport
> mode or tunnel mode packed by mode "input" handler. The VTI handler code
> takes effects in this stage in tunnel mode only. So it neither need propagate
> PMTU, as it has already been done if necessary, nor the VTI handler is
> qualified as a xfrm_tunnel.
>
I think you are right here, please update your commit message with
the above informations. I'd take this into ipsec-next and update
the the ipv6 vti patch according to your changes if David does not
mind.
^ permalink raw reply
* Re: [PATCH 2/2] ipv6: set skb->protocol on tcp, raw and ip6_append_data genereated skbs
From: Steffen Klassert @ 2013-08-27 9:23 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev, eric.dumazet
In-Reply-To: <20130826103123.GA30508@order.stressinduktion.org>
On Mon, Aug 26, 2013 at 12:31:23PM +0200, Hannes Frederic Sowa wrote:
> Currently we don't initialize skb->protocol when transmitting data via
> tcp, raw(with and without inclhdr) or udp+ufo or appending data directly
> to the socket transmit queue (via ip6_append_data). This needs to be
> done so that we can get the correct mtu in the xfrm layer.
>
> Setting of skb->protocol happens only in functions where we also have
> a transmitting socket and a new skb, so we don't overwrite old values.
>
> Cc: Steffen Klassert <steffen.klassert@secunet.com>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Acked-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Also applied to ipsec, thanks a lot!
^ permalink raw reply
* Re: [PATCH ipsec 1/2] xfrm: revert ipv4 mtu determination to dst_mtu
From: Steffen Klassert @ 2013-08-27 9:22 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev
In-Reply-To: <20130826103119.GA30465@order.stressinduktion.org>
On Mon, Aug 26, 2013 at 12:31:19PM +0200, Hannes Frederic Sowa wrote:
> In commit 0ea9d5e3e0e03a63b11392f5613378977dae7eca ("xfrm: introduce
> helper for safe determination of mtu") I switched the determination of
> ipv4 mtus from dst_mtu to ip_skb_dst_mtu. This was an error because in
> case of IP_PMTUDISC_PROBE we fall back to the interface mtu, which is
> never correct for ipv4 ipsec.
>
> This patch partly reverts 0ea9d5e3e0e03a63b11392f5613378977dae7eca
> ("xfrm: introduce helper for safe determination of mtu").
>
> Cc: Steffen Klassert <steffen.klassert@secunet.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied to ipsec.
^ permalink raw reply
* RE: [PATCH 0/2] fs: supply inode uid/gid setting interface
From: David Laight @ 2013-08-27 9:20 UTC (permalink / raw)
To: Rui Xiang, Greg KH
Cc: linux-s390, linux-ia64, linux-rdma, netdev, linux-usb,
linux-kernel, linux-mm, viro, cgroups, linux-fsdevel,
v9fs-developer, linuxppc-dev
In-Reply-To: <5217100E.6080506@huawei.com>
> Subject: Re: [PATCH 0/2] fs: supply inode uid/gid setting interface
>
> On 2013/8/23 12:10, Greg KH wrote:
> > On Fri, Aug 23, 2013 at 10:48:36AM +0800, Rui Xiang wrote:
> >> This patchset implements an accessor functions to set uid/gid
> >> in inode struct. Just finish code clean up.
> >
> > Why?
> >
> It can introduce a new function to reduce some codes.
> Just clean up.
In what sense is it a 'cleanup' ?
To my mind it just means that anyone reading the code has
to go and look at another file in order to see what the
function does (it might be expected to be more complex).
It also adds run time cost, while probably not directly
measurable I suspect it more than doubles the execution
time of that code fragment - do that everywhere and the
system will run like a sick pig.
The only real use for accessor functions is when you
don't want the structure offset to be public.
In this case that is obviously not the case since
all the drivers are directly accessing other members
of the structure.
David
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 0/2] net/cadence/macb: add support for dt phy definition
From: Nicolas Ferre @ 2013-08-27 9:16 UTC (permalink / raw)
To: boris brezillon
Cc: Florian Fainelli, David Miller, Rob Herring, Pawel Moll,
Mark Rutland, Stephen Warren, Ian Campbell, Russell King, netdev,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
In-Reply-To: <521C6DD7.8030308@overkiz.com>
On 27/08/2013 11:13, boris brezillon :
> On 27/08/2013 11:07, Florian Fainelli wrote:
>> Hello Boris,
>>
>> 2013/8/27 boris brezillon <b.brezillon@overkiz.com>:
>>> Hello Dave,
>>>
>>>
>>> On 26/08/2013 22:04, David Miller wrote:
>>>> From: Boris BREZILLON <b.brezillon@overkiz.com>
>>>> Date: Thu, 22 Aug 2013 17:56:20 +0200
>>>>
>>>>> This patch series adds support for ethernet phy definition using device
>>>>> tree.
>>>>>
>>>>> This may help in moving some at91 boards to dt (some of them define an
>>>>> interrupt pin).
>>>>>
>>>>> Tested on samad31ek.
>>>> Series applied to net-next, thanks.
>>> Could you apply, the 3rd version of this series instead ?
>>>
>>> It fixes one bug when no phy is discovered and use the appropriate address
>>> for the phy dt node.
>>>
>>> Sorry for the inconvenience.
>> You will probably have to resubmit an incremental patch, I have never
>> seen David pick up another version of a patch once it has been pushed
>> out:
>>
>> http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=8c038e7e14b1c5f156745e3c4df0a3aa46173dd9
>> http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=148cbb53ace32f584d208764c7f7e6aa8edb970c
> Okay, I will submit patches (based on net-next branch) to fix those bugs.
You can add my Acked-by to your fixes...
Bye,
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH 0/2] net/cadence/macb: add support for dt phy definition
From: boris brezillon @ 2013-08-27 9:13 UTC (permalink / raw)
To: Florian Fainelli
Cc: David Miller, nicolas.ferre, Rob Herring, Pawel Moll,
Mark Rutland, Stephen Warren, Ian Campbell, Russell King, netdev,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
In-Reply-To: <CAGVrzcYBT5aCmdaiGTm34kVu1UQssxB_EHvvj+t0phT58hcsZQ@mail.gmail.com>
On 27/08/2013 11:07, Florian Fainelli wrote:
> Hello Boris,
>
> 2013/8/27 boris brezillon <b.brezillon@overkiz.com>:
>> Hello Dave,
>>
>>
>> On 26/08/2013 22:04, David Miller wrote:
>>> From: Boris BREZILLON <b.brezillon@overkiz.com>
>>> Date: Thu, 22 Aug 2013 17:56:20 +0200
>>>
>>>> This patch series adds support for ethernet phy definition using device
>>>> tree.
>>>>
>>>> This may help in moving some at91 boards to dt (some of them define an
>>>> interrupt pin).
>>>>
>>>> Tested on samad31ek.
>>> Series applied to net-next, thanks.
>> Could you apply, the 3rd version of this series instead ?
>>
>> It fixes one bug when no phy is discovered and use the appropriate address
>> for the phy dt node.
>>
>> Sorry for the inconvenience.
> You will probably have to resubmit an incremental patch, I have never
> seen David pick up another version of a patch once it has been pushed
> out:
>
> http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=8c038e7e14b1c5f156745e3c4df0a3aa46173dd9
> http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=148cbb53ace32f584d208764c7f7e6aa8edb970c
Okay, I will submit patches (based on net-next branch) to fix those bugs.
Thanks.
Best Regards,
Boris
^ permalink raw reply
* Re: [PATCH 0/2] net/cadence/macb: add support for dt phy definition
From: Florian Fainelli @ 2013-08-27 9:07 UTC (permalink / raw)
To: boris brezillon
Cc: David Miller, nicolas.ferre, Rob Herring, Pawel Moll,
Mark Rutland, Stephen Warren, Ian Campbell, Russell King, netdev,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
In-Reply-To: <521C586A.7080604@overkiz.com>
Hello Boris,
2013/8/27 boris brezillon <b.brezillon@overkiz.com>:
> Hello Dave,
>
>
> On 26/08/2013 22:04, David Miller wrote:
>>
>> From: Boris BREZILLON <b.brezillon@overkiz.com>
>> Date: Thu, 22 Aug 2013 17:56:20 +0200
>>
>>> This patch series adds support for ethernet phy definition using device
>>> tree.
>>>
>>> This may help in moving some at91 boards to dt (some of them define an
>>> interrupt pin).
>>>
>>> Tested on samad31ek.
>>
>> Series applied to net-next, thanks.
>
> Could you apply, the 3rd version of this series instead ?
>
> It fixes one bug when no phy is discovered and use the appropriate address
> for the phy dt node.
>
> Sorry for the inconvenience.
You will probably have to resubmit an incremental patch, I have never
seen David pick up another version of a patch once it has been pushed
out:
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=8c038e7e14b1c5f156745e3c4df0a3aa46173dd9
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=148cbb53ace32f584d208764c7f7e6aa8edb970c
--
Florian
^ permalink raw reply
* Re: [PATCH 0/5] netfilter: SYNPROXY target v3
From: Patrick McHardy @ 2013-08-27 9:05 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: pablo, netfilter-devel, netdev, mph, jesper.brouer, as
In-Reply-To: <Pine.LNX.4.64.1308270951520.25216@ask.diku.dk>
On Tue, Aug 27, 2013 at 10:35:56AM +0200, Jesper Dangaard Brouer wrote:
> On Tue, 27 Aug 2013, Patrick McHardy wrote:
>
> >Since the SYN proxy can't know the options the server supports, they have
> >to be specified as parameters to the SYNPROXY target. The assumption is that
> >these options are constant as long as you don't change settings on the
> >server.
>
> Future extention idea: Perhaps we could auto detect the options the
> server supports, after the first connection have been created?
> I know this is problematic/difficult for the iptables framework,
> because it would require the module to keep an internal dynamic
> state, which iptables module does not handle well (due to how the
> entires ruleset is reloaded on rule changes).
The main reason why I didn't add this is since it assumes you have a
single rule per destination. That assumption can't be made, so you'd
have to maintain a table of options per destination.
I'll add the synconf tool to generate rules based on what the server
actually supports to the iptables repository once this has been merged.
> Guess, the easiest thing to implement, would be to give a warning,
> if the options (the server supports) does not match the modules config.
Yes, that could be done.
^ permalink raw reply
* Re: [PATCH 0/5] netfilter: SYNPROXY target v3
From: Jesper Dangaard Brouer @ 2013-08-27 8:35 UTC (permalink / raw)
To: Patrick McHardy; +Cc: pablo, netfilter-devel, netdev, mph, jesper.brouer, as
In-Reply-To: <1377586216-7024-1-git-send-email-kaber@trash.net>
On Tue, 27 Aug 2013, Patrick McHardy wrote:
> The following patches contain the latest version of the SYNPROXY target.
>
> The SYNPROXY operates by marking the initial SYN from the client as UNTRACKED
> and directing it to the SYNPROXY target. The target responds with a SYN/ACK
> containing a cookie and encodes options such as window scaling factor, SACK
> perm etc. into the timestamp, if timestamps are used (similar to TCP). The
> window size is set to zero. The response is also sent as untracked packet.
>
> When the final ACK is received the cookie is validated, the original options
> extracted and a SYN to the original destination is generated. The SYN to the
> original destination uses the avertised window from the final ACK and the
> options from the initial SYN packet. The SYN is not sent as untracked, so
> from a connection tracking POV it will look like the original packet from
> the client and instantiate a new connection. When the server responds with
> a SYN/ACK a final ACK for the server is generated and a window update with
> the window size announced by the server is sent to the client. At this
> point the connection is handed of to conntrack and the only thing the
> target is still involved in is timestamp translation through the registerd
> hooks.
>
> Since the SYN proxy can't know the options the server supports, they have
> to be specified as parameters to the SYNPROXY target. The assumption is that
> these options are constant as long as you don't change settings on the
> server.
Future extention idea: Perhaps we could auto detect the options the server
supports, after the first connection have been created?
I know this is problematic/difficult for the iptables framework, because
it would require the module to keep an internal dynamic state, which
iptables module does not handle well (due to how the entires ruleset is
reloaded on rule changes).
Guess, the easiest thing to implement, would be to give a warning,
if the options (the server supports) does not match the modules config.
> Since the SYN proxy can't know the initial sequence number and
> timestamp values the server will use, both have to be translated in the
> direction server->client. Sequence number translation is done using the
> standard sequence number translation mechanisms originally only used for
> NAT, timestamps are translated in a hook registered by the SYNPROXY target.
>
> Usage is as follows:
>
> iptables -t raw -A PREROUTING -i eth0 -p tcp --dport 80 --syn -j NOTRACK
> iptables -A INPUT -i eth0 -p tcp --dport 80 -m state UNTRACKED,INVALID \
> -j SYNPROXY --sack-perm --timestamp --mss 1480 --wscale 7 --ecn
>
> echo 0 > /proc/sys/net/netfilter/nf_conntrack_tcp_loose
>
> The second rule catches untracked packets and directs them to the target.
> The purpose of disabling loose tracking is to have the final ACK from the
> client not be picked up by conntrack, so it won't create a new conntrack
> entry and will be marked INVALID and also get directed to the target.
>
> We did some extensive testing on Monday and it verified all retransmit
> bugs have been fixed. With 1.4Mpps SYNs the load on a 16 way Xeon L6530
> 2.13 Ghz machine was between 3% and 6%.
It was a Xeon L5630 ;-)
We tested both SYN and ACK flood-attacks, while running ab (Apache
Benchmark). The 1.4Mpps comes from limitations on the generator host
(which used trafgen). We also did some short tests with a modified
pktgen. And Martin wrote a test tool, that would delay conn
establishment, to test retransmits. And Patritck tested in (simulated)
drop situations.
> There's one single change since v2:
>
> Reopened TCP connections while the conntrack is in CLOSE state weren't
> handled properly. The sequence number and timestamp adjustments need
> to be reset in this case. Another counter has been introduced for this.
>
> From my POV, these patches are ready for merging now.
Yes, Martin and Patrick (and I) have done some good testing of the module.
And we have flushed out and solved several bugs in this process.
Cheers,
Jesper Brouer
--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------
^ permalink raw reply
* [PATCH] tcp: don't apply tsoffset if rcv_tsecr is zero
From: Andrey Vagin @ 2013-08-27 8:21 UTC (permalink / raw)
To: netdev
Cc: Cyrill Gorcunov, linux-kernel, Andrew Vagin, Pavel Emelyanov,
Eric Dumazet, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy
From: Andrew Vagin <avagin@openvz.org>
The zero value means that tsecr is not valid, so it's a special case.
tsoffset is used to customize tcp_time_stamp for one socket.
tsoffset is usually zero, it's used when a socket was moved from one
host to another host.
Currently this issue affects logic of tcp_rcv_rtt_measure_ts. Due to
incorrect value of rcv_tsecr, tcp_rcv_rtt_measure_ts sets rto to
TCP_RTO_MAX.
Cc: Pavel Emelyanov <xemul@parallels.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Patrick McHardy <kaber@trash.net>
Reported-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Andrey Vagin <avagin@openvz.org>
---
net/ipv4/tcp_input.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 28af45a..3ca2139 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3535,7 +3535,10 @@ static bool tcp_parse_aligned_timestamp(struct tcp_sock *tp, const struct tcphdr
++ptr;
tp->rx_opt.rcv_tsval = ntohl(*ptr);
++ptr;
- tp->rx_opt.rcv_tsecr = ntohl(*ptr) - tp->tsoffset;
+ if (*ptr)
+ tp->rx_opt.rcv_tsecr = ntohl(*ptr) - tp->tsoffset;
+ else
+ tp->rx_opt.rcv_tsecr = 0;
return true;
}
return false;
@@ -3560,7 +3563,7 @@ static bool tcp_fast_parse_options(const struct sk_buff *skb,
}
tcp_parse_options(skb, &tp->rx_opt, 1, NULL);
- if (tp->rx_opt.saw_tstamp)
+ if (tp->rx_opt.saw_tstamp && tp->rx_opt.rcv_tsecr)
tp->rx_opt.rcv_tsecr -= tp->tsoffset;
return true;
@@ -5316,7 +5319,7 @@ static int tcp_rcv_synsent_state_process(struct sock *sk, struct sk_buff *skb,
int saved_clamp = tp->rx_opt.mss_clamp;
tcp_parse_options(skb, &tp->rx_opt, 0, &foc);
- if (tp->rx_opt.saw_tstamp)
+ if (tp->rx_opt.saw_tstamp && tp->rx_opt.rcv_tsecr)
tp->rx_opt.rcv_tsecr -= tp->tsoffset;
if (th->ack) {
--
1.8.3.1
^ permalink raw reply related
* [PATCH] tcp: initialize rcv_tstamp for restored sockets
From: Andrey Vagin @ 2013-08-27 8:20 UTC (permalink / raw)
To: netdev
Cc: Cyrill Gorcunov, linux-kernel, Andrew Vagin, Pavel Emelyanov,
Eric Dumazet, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy
From: Andrew Vagin <avagin@openvz.org>
u32 rcv_tstamp; /* timestamp of last received ACK */
Its value used in tcp_retransmit_timer, which closes socket
if the last ack was received more then TCP_RTO_MAX ago.
Currently rcv_tstamp is initialized to zero and if tcp_retransmit_timer
is called before receiving a first ack, the connection is closed.
This patch initializes rcv_tstamp to a timestamp, when a socket was
restored.
Cc: Pavel Emelyanov <xemul@parallels.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Patrick McHardy <kaber@trash.net>
Reported-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Andrey Vagin <avagin@openvz.org>
---
net/ipv4/tcp_output.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 92fde8d..e297299 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2814,6 +2814,8 @@ void tcp_connect_init(struct sock *sk)
if (likely(!tp->repair))
tp->rcv_nxt = 0;
+ else
+ tp->rcv_tstamp = tcp_time_stamp;
tp->rcv_wup = tp->rcv_nxt;
tp->copied_seq = tp->rcv_nxt;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v3 2/2] ARM: at91/dt: define phy available on sama5d3 mother board
From: Nicolas Ferre @ 2013-08-27 8:00 UTC (permalink / raw)
To: Boris BREZILLON
Cc: Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, Russell King, devicetree, linux-arm-kernel,
linux-kernel, netdev
In-Reply-To: <1377589142-3758-1-git-send-email-b.brezillon@overkiz.com>
On 27/08/2013 09:39, Boris BREZILLON :
> This patch describe the phy used on atmel sama5d3 mother board:
> - phy address
> - phy interrupt pin
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> arch/arm/boot/dts/sama5d3xmb.dtsi | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sama5d3xmb.dtsi b/arch/arm/boot/dts/sama5d3xmb.dtsi
> index 8a9e05d..dba739b 100644
> --- a/arch/arm/boot/dts/sama5d3xmb.dtsi
> +++ b/arch/arm/boot/dts/sama5d3xmb.dtsi
> @@ -81,6 +81,14 @@
>
> macb1: ethernet@f802c000 {
> phy-mode = "rmii";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + phy0: ethernet-phy@1 {
> + interrupt-parent = <&pioE>;
> + interrupts = <30 IRQ_TYPE_EDGE_FALLING>;
> + reg = <1>;
> + };
> };
>
> pinctrl@fffff200 {
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH v3 1/2] net/cadence/macb: add support for dt phy definition
From: Nicolas Ferre @ 2013-08-27 7:58 UTC (permalink / raw)
To: Boris BREZILLON
Cc: Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, Russell King, devicetree, linux-arm-kernel,
linux-kernel, netdev
In-Reply-To: <1377589070-3722-1-git-send-email-b.brezillon@overkiz.com>
On 27/08/2013 09:37, Boris BREZILLON :
> The macb driver only handle PHY description through platform_data
> (macb_platform_data).
> Thus, when using dt you cannot define phy properties like phy address or
> phy irq pin.
>
> This patch makes use of the of_mdiobus_register to add support for
> phy device definition using dt.
> A fallback to the autoscan procedure is added in case there is no phy
> devices defined in dt.
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> drivers/net/ethernet/cadence/macb.c | 48 +++++++++++++++++++++++++++--------
> 1 file changed, 38 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
> index e866608..393afeb 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -27,6 +27,7 @@
> #include <linux/phy.h>
> #include <linux/of.h>
> #include <linux/of_device.h>
> +#include <linux/of_mdio.h>
> #include <linux/of_net.h>
> #include <linux/pinctrl/consumer.h>
>
> @@ -275,7 +276,7 @@ static int macb_mii_probe(struct net_device *dev)
> phydev = phy_find_first(bp->mii_bus);
> if (!phydev) {
> netdev_err(dev, "no PHY found\n");
> - return -1;
> + return -ENXIO;
> }
>
> pdata = dev_get_platdata(&bp->pdev->dev);
> @@ -314,6 +315,7 @@ static int macb_mii_probe(struct net_device *dev)
> int macb_mii_init(struct macb *bp)
> {
> struct macb_platform_data *pdata;
> + struct device_node *np;
> int err = -ENXIO, i;
>
> /* Enable management port */
> @@ -335,26 +337,52 @@ int macb_mii_init(struct macb *bp)
> bp->mii_bus->parent = &bp->dev->dev;
> pdata = bp->pdev->dev.platform_data;
>
> - if (pdata)
> - bp->mii_bus->phy_mask = pdata->phy_mask;
> -
> bp->mii_bus->irq = kmalloc(sizeof(int)*PHY_MAX_ADDR, GFP_KERNEL);
> if (!bp->mii_bus->irq) {
> err = -ENOMEM;
> goto err_out_free_mdiobus;
> }
>
> - for (i = 0; i < PHY_MAX_ADDR; i++)
> - bp->mii_bus->irq[i] = PHY_POLL;
> -
> dev_set_drvdata(&bp->dev->dev, bp->mii_bus);
>
> - if (mdiobus_register(bp->mii_bus))
> + np = bp->pdev->dev.of_node;
> + if (np) {
> + /* try dt phy registration */
> + err = of_mdiobus_register(bp->mii_bus, np);
> +
> + /* fallback to standard phy registration if no phy were
> + * found during dt phy registration
> + */
> + if (!err && !phy_find_first(bp->mii_bus)) {
> + for (i = 0; i < PHY_MAX_ADDR; i++) {
> + struct phy_device *phydev;
> +
> + phydev = mdiobus_scan(bp->mii_bus, i);
> + if (IS_ERR(phydev)) {
> + err = PTR_ERR(phydev);
> + break;
> + }
> + }
> +
> + if (err)
> + goto err_out_unregister_bus;
> + }
> + } else {
> + for (i = 0; i < PHY_MAX_ADDR; i++)
> + bp->mii_bus->irq[i] = PHY_POLL;
> +
> + if (pdata)
> + bp->mii_bus->phy_mask = pdata->phy_mask;
> +
> + err = mdiobus_register(bp->mii_bus);
> + }
> +
> + if (err)
> goto err_out_free_mdio_irq;
>
> - if (macb_mii_probe(bp->dev) != 0) {
> + err = macb_mii_probe(bp->dev);
> + if (err)
> goto err_out_unregister_bus;
> - }
>
> return 0;
>
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH v3 0/2] net/cadence/macb: add support for dt phy definition
From: boris brezillon @ 2013-08-27 7:48 UTC (permalink / raw)
To: David S. Miller
Cc: Boris BREZILLON, Rob Herring, Pawel Moll, Mark Rutland,
Stephen Warren, Ian Campbell, Russell King, Nicolas Ferre,
devicetree, linux-arm-kernel, linux-kernel, netdev
In-Reply-To: <1377589007-3684-1-git-send-email-b.brezillon@overkiz.com>
Hello David,
Sorry, I forgot to add your email in the cc list.
Do you want me to send you the whole series ?
Best Regards,
Boris
On 27/08/2013 09:36, Boris BREZILLON wrote:
> Hello,
>
> This patch series adds support for ethernet phy definition using device
> tree.
>
> This may help in moving some at91 boards to dt (some of them define an
> interrupt pin).
>
> Tested on samad31ek.
>
> Best Regards,
> Boris
>
> Changes since v2:
> - fix wrong address of phy0 dt node
>
> Changes since v1:
> - fix wrong macb_mii_init return code when no PHY device is discovered
>
> Boris BREZILLON (2):
> net/cadence/macb: add support for dt phy definition
> ARM: at91/dt: define phy available on sama5d3 mother board
>
> arch/arm/boot/dts/sama5d3xmb.dtsi | 8 ++++++
> drivers/net/ethernet/cadence/macb.c | 48 +++++++++++++++++++++++++++--------
> 2 files changed, 46 insertions(+), 10 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 0/2] net/cadence/macb: add support for dt phy definition
From: boris brezillon @ 2013-08-27 7:42 UTC (permalink / raw)
To: David Miller
Cc: nicolas.ferre, rob.herring, pawel.moll, mark.rutland, swarren,
ian.campbell, linux, f.fainelli, netdev, linux-kernel,
linux-arm-kernel, devicetree
In-Reply-To: <20130826.160450.2176892065062148718.davem@davemloft.net>
Hello Dave,
On 26/08/2013 22:04, David Miller wrote:
> From: Boris BREZILLON <b.brezillon@overkiz.com>
> Date: Thu, 22 Aug 2013 17:56:20 +0200
>
>> This patch series adds support for ethernet phy definition using device
>> tree.
>>
>> This may help in moving some at91 boards to dt (some of them define an
>> interrupt pin).
>>
>> Tested on samad31ek.
> Series applied to net-next, thanks.
Could you apply, the 3rd version of this series instead ?
It fixes one bug when no phy is discovered and use the appropriate address
for the phy dt node.
Sorry for the inconvenience.
Best Regards,
Boris
^ permalink raw reply
* RE: pcie_get_minimum_link returns 0 width
From: Yuval Mintz @ 2013-08-27 7:40 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: jacob.e.keller@intel.com, linux-pci@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <CAErSpo68LaevaBG8rJD0aj+oy-cp_f2ZsQVEhXL=oUyyRiYwZw@mail.gmail.com>
> On Mon, Aug 26, 2013 at 5:36 PM, Yuval Mintz <yuvalmin@broadcom.com>
> wrote:
> >> > Hi,
> >> >
> >> > I tried adding support for the newly added 'pcie_get_minimum_link' into
> >> the
> >> > bnx2x driver, but found out the some of my devices started showing
> width
> >> x0.
> >> >
> >> > By adding debug prints, I've found out there were devices up the chain
> that
> >> > Showed 0 when their PCI_EXP_LNKSTA was read by said function.
> >> > However, when I tried looking via lspci the output claimed the width was
> >> x4.
> Looking at its implementation, one obvious difference is that
> pcie_get_minimum_link() traverses up the hierarchy and keeps track of
> the minimum values it finds. lspci, on the other hand, just reads
> PCI_EXP_LNKSTA from a single device and decodes it.
>
> You said lspci reports x4 for every device from the Root Port all the
> way down to your NIC, so I would think the minimum from
> pcie_get_minimum_link() would be x4. But apparently it's not. Maybe
> there's a bug in it. Can you post the complete "lspci -vv" output
> along with your debug patch and output?
>
> Bjorn
Here's the patch:
---
drivers/pci/pci.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index c71e78c..72cb87b 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3601,13 +3601,19 @@ int pcie_get_minimum_link(struct pci_dev *dev, enum pci_bus_speed *speed,
enum pcie_link_width next_width;
ret = pcie_capability_read_word(dev, PCI_EXP_LNKSTA, &lnksta);
- if (ret)
+ if (ret) {
+ printk(KERN_ERR "Failed to Read LNKSTA\n");
return ret;
+ }
next_speed = pcie_link_speed[lnksta & PCI_EXP_LNKSTA_CLS];
next_width = (lnksta & PCI_EXP_LNKSTA_NLW) >>
PCI_EXP_LNKSTA_NLW_SHIFT;
+ printk(KERN_ERR "LnkSta %04x [%04x:%02x.%02x]\n",
+ lnksta, dev->bus->number, PCI_SLOT(dev->devfn),
+ PCI_FUNC(dev->devfn));
+
if (next_speed < *speed)
*speed = next_speed;
--
1.7.1
And here are the lscpi results for 09:00.0 and 0a:01.0
(The two devices for which the loop returns 0 width):
Sysfs do read [Pos 0, len 64]
09:00.0 Class 0604: Device 8086:3500 (rev 01)
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, Cache Line Size: 64 bytes
Bus: primary=09, secondary=0a, subordinate=11, sec-latency=0
Memory behind bridge: fb800000-fd7fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: Sysfs do read [Pos 68, len 4]
[44] Express (v1) Upstream Port, MSI 00
Sysfs do read [Pos 72, len 16]
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-SlotPowerLimit 0.000W
DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 256 bytes, MaxReadReq 4096 bytes
DevSta: CorrErr- UncorrErr- FatalErr+ UnsuppReq+ AuxPwr- TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x8, ASPM L0s, Latency L0 unlimited, L1 unlimited
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: Sysfs do read [Pos 112, len 4]
[70] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Sysfs do read [Pos 116, len 4]
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: Sysfs do read [Pos 128, len 4]
[80] Sysfs do read [Pos 132, len 4]
Subsystem: Device 0000:0000
Sysfs do read [Pos 256, len 4]
Capabilities: [100 v1] Advanced Error Reporting
Sysfs do read [Pos 260, len 24]
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
UESvrt: DLP+ SDES- TLP+ FCP+ CmpltTO+ CmpltAbrt+ UnxCmplt+ RxOF+ MalfTLP+ ECRC- UnsupReq+ ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr+ BadTLP+ BadDLLP+ Rollover+ Timeout+ NonFatalErr-
AERCap: First Error Pointer: 14, GenCap- CGenEn- ChkCap- ChkEn-
Kernel driver in use: pcieport
Kernel modules: shpchp
Sysfs do read [Pos 0, len 64]
0a:01.0 Class 0604: Device 8086:3514 (rev 01)
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, Cache Line Size: 64 bytes
Bus: primary=0a, secondary=0e, subordinate=10, sec-latency=0
Memory behind bridge: fb800000-fd7fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: Sysfs do read [Pos 68, len 4]
[44] Express (v1) Downstream Port (Slot-), MSI 00
Sysfs do read [Pos 72, len 16]
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 256 bytes, MaxReadReq 4096 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #2, Speed 2.5GT/s, Width x4, ASPM L0s, Latency L0 unlimited, L1 unlimited
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: Sysfs do read [Pos 96, len 4]
[60] MSI: Enable- Count=1/1 Maskable- 64bit+
Sysfs do read [Pos 100, len 10]
Address: 0000000000000000 Data: 0000
Capabilities: Sysfs do read [Pos 112, len 4]
[70] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Sysfs do read [Pos 116, len 4]
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: Sysfs do read [Pos 128, len 4]
[80] Sysfs do read [Pos 132, len 4]
Subsystem: Device 0000:0000
Sysfs do read [Pos 256, len 4]
Capabilities: [100 v1] Advanced Error Reporting
Sysfs do read [Pos 260, len 24]
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
UESvrt: DLP+ SDES- TLP+ FCP+ CmpltTO+ CmpltAbrt+ UnxCmplt+ RxOF+ MalfTLP+ ECRC- UnsupReq+ ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr+ BadTLP+ BadDLLP+ Rollover+ Timeout+ NonFatalErr-
AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
Kernel driver in use: pcieport
Kernel modules: shpchp
Thanks,
Yuval
^ permalink raw reply related
* [PATCH v3 2/2] ARM: at91/dt: define phy available on sama5d3 mother board
From: Boris BREZILLON @ 2013-08-27 7:39 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, Russell King, Nicolas Ferre
Cc: devicetree, linux-arm-kernel, linux-kernel, netdev,
Boris BREZILLON
In-Reply-To: <1377589007-3684-1-git-send-email-b.brezillon@overkiz.com>
This patch describe the phy used on atmel sama5d3 mother board:
- phy address
- phy interrupt pin
Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
---
arch/arm/boot/dts/sama5d3xmb.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sama5d3xmb.dtsi b/arch/arm/boot/dts/sama5d3xmb.dtsi
index 8a9e05d..dba739b 100644
--- a/arch/arm/boot/dts/sama5d3xmb.dtsi
+++ b/arch/arm/boot/dts/sama5d3xmb.dtsi
@@ -81,6 +81,14 @@
macb1: ethernet@f802c000 {
phy-mode = "rmii";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy0: ethernet-phy@1 {
+ interrupt-parent = <&pioE>;
+ interrupts = <30 IRQ_TYPE_EDGE_FALLING>;
+ reg = <1>;
+ };
};
pinctrl@fffff200 {
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 1/2] net/cadence/macb: add support for dt phy definition
From: Boris BREZILLON @ 2013-08-27 7:37 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, Russell King, Nicolas Ferre
Cc: devicetree, linux-arm-kernel, linux-kernel, netdev,
Boris BREZILLON
In-Reply-To: <1377589007-3684-1-git-send-email-b.brezillon@overkiz.com>
The macb driver only handle PHY description through platform_data
(macb_platform_data).
Thus, when using dt you cannot define phy properties like phy address or
phy irq pin.
This patch makes use of the of_mdiobus_register to add support for
phy device definition using dt.
A fallback to the autoscan procedure is added in case there is no phy
devices defined in dt.
Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
---
drivers/net/ethernet/cadence/macb.c | 48 +++++++++++++++++++++++++++--------
1 file changed, 38 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index e866608..393afeb 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -27,6 +27,7 @@
#include <linux/phy.h>
#include <linux/of.h>
#include <linux/of_device.h>
+#include <linux/of_mdio.h>
#include <linux/of_net.h>
#include <linux/pinctrl/consumer.h>
@@ -275,7 +276,7 @@ static int macb_mii_probe(struct net_device *dev)
phydev = phy_find_first(bp->mii_bus);
if (!phydev) {
netdev_err(dev, "no PHY found\n");
- return -1;
+ return -ENXIO;
}
pdata = dev_get_platdata(&bp->pdev->dev);
@@ -314,6 +315,7 @@ static int macb_mii_probe(struct net_device *dev)
int macb_mii_init(struct macb *bp)
{
struct macb_platform_data *pdata;
+ struct device_node *np;
int err = -ENXIO, i;
/* Enable management port */
@@ -335,26 +337,52 @@ int macb_mii_init(struct macb *bp)
bp->mii_bus->parent = &bp->dev->dev;
pdata = bp->pdev->dev.platform_data;
- if (pdata)
- bp->mii_bus->phy_mask = pdata->phy_mask;
-
bp->mii_bus->irq = kmalloc(sizeof(int)*PHY_MAX_ADDR, GFP_KERNEL);
if (!bp->mii_bus->irq) {
err = -ENOMEM;
goto err_out_free_mdiobus;
}
- for (i = 0; i < PHY_MAX_ADDR; i++)
- bp->mii_bus->irq[i] = PHY_POLL;
-
dev_set_drvdata(&bp->dev->dev, bp->mii_bus);
- if (mdiobus_register(bp->mii_bus))
+ np = bp->pdev->dev.of_node;
+ if (np) {
+ /* try dt phy registration */
+ err = of_mdiobus_register(bp->mii_bus, np);
+
+ /* fallback to standard phy registration if no phy were
+ * found during dt phy registration
+ */
+ if (!err && !phy_find_first(bp->mii_bus)) {
+ for (i = 0; i < PHY_MAX_ADDR; i++) {
+ struct phy_device *phydev;
+
+ phydev = mdiobus_scan(bp->mii_bus, i);
+ if (IS_ERR(phydev)) {
+ err = PTR_ERR(phydev);
+ break;
+ }
+ }
+
+ if (err)
+ goto err_out_unregister_bus;
+ }
+ } else {
+ for (i = 0; i < PHY_MAX_ADDR; i++)
+ bp->mii_bus->irq[i] = PHY_POLL;
+
+ if (pdata)
+ bp->mii_bus->phy_mask = pdata->phy_mask;
+
+ err = mdiobus_register(bp->mii_bus);
+ }
+
+ if (err)
goto err_out_free_mdio_irq;
- if (macb_mii_probe(bp->dev) != 0) {
+ err = macb_mii_probe(bp->dev);
+ if (err)
goto err_out_unregister_bus;
- }
return 0;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 0/2] net/cadence/macb: add support for dt phy definition
From: Boris BREZILLON @ 2013-08-27 7:36 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, Russell King, Nicolas Ferre
Cc: devicetree, linux-arm-kernel, linux-kernel, netdev,
Boris BREZILLON
Hello,
This patch series adds support for ethernet phy definition using device
tree.
This may help in moving some at91 boards to dt (some of them define an
interrupt pin).
Tested on samad31ek.
Best Regards,
Boris
Changes since v2:
- fix wrong address of phy0 dt node
Changes since v1:
- fix wrong macb_mii_init return code when no PHY device is discovered
Boris BREZILLON (2):
net/cadence/macb: add support for dt phy definition
ARM: at91/dt: define phy available on sama5d3 mother board
arch/arm/boot/dts/sama5d3xmb.dtsi | 8 ++++++
drivers/net/ethernet/cadence/macb.c | 48 +++++++++++++++++++++++++++--------
2 files changed, 46 insertions(+), 10 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH iproute2] ipnetns: fix ip batch mode when using 'netns exec'
From: Nicolas Dichtel @ 2013-08-27 7:25 UTC (permalink / raw)
To: shemminger; +Cc: netdev, Nicolas Dichtel
Since commit a05f6511f543, ip batch mode is broken when using 'netns exec' cmd.
When WIFEXITED() returns true, it means that the child exited normally, hence
we must not call exit() but just returns the status. If we call exit, the next
commands in the file file are not executed.
If WIFEXITED() returns false, we can call exit() because it means that the
child failed.
This patch partially reverts commit a05f6511f543.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
ip/ipnetns.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/ip/ipnetns.c b/ip/ipnetns.c
index c8a47920539c..11dd9b89e503 100644
--- a/ip/ipnetns.c
+++ b/ip/ipnetns.c
@@ -205,11 +205,15 @@ static int netns_exec(int argc, char **argv)
exit(1);
}
- /* If child failed, propagate status */
- if (WIFEXITED(status))
- exit(WEXITSTATUS(status));
+ if (WIFEXITED(status)) {
+ /* ip must returns the status of the child,
+ * but do_cmd() will add a minus to this,
+ * so let's add another one here to cancel it.
+ */
+ return -WEXITSTATUS(status);
+ }
- return 0;
+ exit(1);
}
}
--
1.8.2.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox