* Re: [PATCH v2] net: netcp: correct netcp_get_stats function signature
From: David Miller @ 2017-01-11 15:48 UTC (permalink / raw)
To: j-keerthy
Cc: w-kwok2, m-karicheri2, netdev, linux-kernel, stephen, m-scherban
In-Reply-To: <1484105609-8647-1-git-send-email-j-keerthy@ti.com>
From: Keerthy <j-keerthy@ti.com>
Date: Wed, 11 Jan 2017 09:03:29 +0530
> Commit: bc1f44709cf2 - net: make ndo_get_stats64 a void function
> and
> Commit: 6a8162e99ef3 - net: netcp: store network statistics in 64 bits.
>
> The commit 6a8162e99ef3 adds ndo_get_stats64 function as per old
> signature which causes compilation error:
>
> drivers/net/ethernet/ti/netcp_core.c:1951:28: error:
> initialization from incompatible pointer type
> .ndo_get_stats64 = netcp_get_stats,
>
> Hence correct netcp_get_stats function signature as per
> the latest definition.
>
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> Fixes: 6a8162e99ef344fc("net: netcp: store network statistics in 64 bits")
Applied, thanks.
^ permalink raw reply
* Re: [RFC PATCH] tcp: accept RST for rcv_nxt - 1 after receiving a FIN
From: Eric Dumazet @ 2017-01-11 15:48 UTC (permalink / raw)
To: Jason Baron; +Cc: netdev
In-Reply-To: <1483652008-20255-1-git-send-email-jbaron@akamai.com>
On Thu, 2017-01-05 at 16:33 -0500, Jason Baron wrote:
>
> +/* Accept RST for rcv_nxt - 1 after a FIN.
> + * When tcp connections are abruptly terminated from Mac OSX (via ^C), a
> + * FIN is sent followed by a RST packet. The RST is sent with the same
> + * sequence number as the FIN, and thus according to RFC 5961 a challenge
> + * ACK should be sent. However, Mac OSX does not reply to the challenge ACK
> + * with a RST on the closed socket, hence accept this class of RSTs.
> + */
> +static bool tcp_reset_check(struct sock *sk, struct sk_buff *skb)
const struct sock *sk, const struct sk_buff *skb
> +{
> + struct tcp_sock *tp = tcp_sk(sk);
> +
> + return unlikely((TCP_SKB_CB(skb)->seq == (tp->rcv_nxt - 1)) &&
> + (TCP_SKB_CB(skb)->end_seq == (tp->rcv_nxt - 1)) &&
Why is the test on end_seq needed ?
> + (sk->sk_state == TCP_CLOSE_WAIT ||
> + sk->sk_state == TCP_LAST_ACK ||
> + sk->sk_state == TCP_CLOSING));
> +}
Testing many states can be done more efficiently :
(1 << sk->sk_state) & (TCPF_CLOSE_WAIT | TCPF_LAST_ACK |
TCPF_CLOSING)
Thanks
^ permalink raw reply
* Re: [PATCH net-next 5/6] bnxt_en: Pass RoCE app priority to firmware.
From: David Miller @ 2017-01-11 15:46 UTC (permalink / raw)
To: michael.chan; +Cc: netdev
In-Reply-To: <1484097159-21575-6-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Tue, 10 Jan 2017 20:12:38 -0500
> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.h b/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.h
> index 35a0d28..f2630cc 100644
> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.h
> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.h
> @@ -36,6 +36,9 @@ struct bnxt_cos2bw_cfg {
>
> #define HWRM_STRUCT_DATA_SUBTYPE_HOST_OPERATIONAL 0x0300
>
> +#define ETH_P_ROCE 0x8915
There's also a similar define in the qedr infiniband driver, this doesn't
make much sense.
Please add this to if_ether.h, and reference it from there in the drivers.
Thanks.
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2017-01-11 15:22 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Fix rtlwifi crash, from Larry Finger.
2) Memory disclosure in appletalk ipddp routing code, from
Vlad Tsyrklevich.
3) r8152 can erroneously split an RX packet into multiple URBs if the
Rx FIFO is not empty when we suspend. Fix this by waiting for the
FIFO to empty before suspending. From Hayes Wang.
4) Two GRO fixes (enter slow path when not enough SKB tail room exists,
disable frag0 optimizations when there are IPV6 extension headers)
from Eric Dumazet and Herbert Xu.
5) A series of mlx5e bug fixes (do source udp port offloading for
tunnels properly, Ip fragment matching fixes, handling firmware
errors properly when installing TC rules, etc.) from Saeed
Mahameed, Or Gerlitz, Roi Dayan, Hadar Hen Zion, Gil Rockah, and
Daniel Jurgens.
6) Two VRF fixes from David Ahern (don't skip multipath selection for VRF
paths, disallow VRF to be configured with table ID 0).
Please pull, thanks a lot!
The following changes since commit c92f5bdc4b9ba509a93f9e386fbb1fa779d4b0d6:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-01-09 11:58:28 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to 24c63bbc18e25d5d8439422aa5fd2d66390b88eb:
net: vrf: do not allow table id 0 (2017-01-11 10:04:01 -0500)
----------------------------------------------------------------
Alexander Alemayhu (1):
ipv6: fix typos
Andrew Lutomirski (1):
orinoco: Use shash instead of ahash for MIC calculations
Anna, Suman (1):
net: add the AF_QIPCRTR entries to family name tables
Arnd Bergmann (1):
cgroup: move CONFIG_SOCK_CGROUP_DATA to init/Kconfig
Colin Ian King (1):
sctp: Fix spelling mistake: "Atempt" -> "Attempt"
Daniel Jurgens (1):
net/mlx5: Only cancel recovery work when cleaning up device
David Ahern (2):
net: ipv4: Fix multipath selection with vrf
net: vrf: do not allow table id 0
David S. Miller (3):
Merge tag 'wireless-drivers-for-davem-2017-01-10' of git://git.kernel.org/.../kvalo/wireless-drivers
Merge branch 'r8152-fix-autosuspend'
Merge branch 'mlx5-fixes'
Eric Dumazet (3):
tcp: do not export tcp_peer_is_proven()
net: skb_flow_get_be16() can be static
gro: use min_t() in skb_gro_reset_offset()
Florian Fainelli (1):
net: dsa: Ensure validity of dst->ds[0]
Gil Rockah (1):
net/mlx5e: Remove WARN_ONCE from adaptive moderation code
Hadar Hen Zion (1):
net/mlx5e: Fix kbuild warnings for uninitialized parameters
Herbert Xu (2):
gro: Enter slow-path if there is no tailroom
gro: Disable frag0 optimization on IPv6 ext headers
Jean Delvare (1):
net: phy: Add Meson GXL PHY hardware dependency
Julian Wiedmann (1):
net/af_iucv: don't use paged skbs for TX on HiperSockets
Larry Finger (1):
rtlwifi: rtl_usb: Fix missing entry in USB driver's private data
Martin KaFai Lau (1):
mlx4: Return EOPNOTSUPP instead of ENOTSUPP
Or Gerlitz (6):
net/mlx5e: Properly handle offloading of source udp port for IP tunnels
net/mlx5e: Warn when rejecting offload attempts of IP tunnels
net/mlx5e: TC ipv4 tunnel encap offload error flow fixes
net/mlx5e: Properly get address type of encapsulation IP headers
net/mlx5e: Set inline mode requirements for matching on IP fragments
net/mlx5e: Properly handle FW errors while adding TC rules
Pavel Tikhomirov (1):
ipv4: make tcp_notsent_lowat sysctl knob behave as true unsigned int
Russell King (1):
net: phy: marvell: fix Marvell 88E1512 used in SGMII mode
Saeed Mahameed (1):
net/mlx5e: Un-register uplink representor on nic_disable
Stephen Boyd (1):
net: qrtr: Mark 'buf' as little endian
Tobias Klauser (1):
net: socket: Make unnecessarily global sockfs_setattr() static
Vlad Tsyrklevich (1):
net/appletalk: Fix kernel memory disclosure
Zefir Kurtisi (1):
phy state machine: failsafe leave invalid RUNNING state
hayeswang (2):
r8152: split rtl8152_suspend function
r8152: fix rx issue for runtime suspend
drivers/net/appletalk/ipddp.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 13 +++++------
drivers/net/ethernet/mellanox/mlx5/core/en_rx_am.c | 7 +-----
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 93 +++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------
drivers/net/ethernet/mellanox/mlx5/core/main.c | 6 +++--
drivers/net/phy/Kconfig | 1 +
drivers/net/phy/marvell.c | 3 ++-
drivers/net/phy/phy.c | 9 ++++++++
drivers/net/usb/r8152.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++--------------
drivers/net/vrf.c | 4 ++++
drivers/net/wireless/intersil/orinoco/mic.c | 44 +++++++++++++++++++++---------------
drivers/net/wireless/intersil/orinoco/mic.h | 3 ++-
drivers/net/wireless/intersil/orinoco/orinoco.h | 4 ++--
drivers/net/wireless/realtek/rtlwifi/usb.c | 1 +
include/linux/netdevice.h | 9 ++++++--
init/Kconfig | 4 ++++
net/Kconfig | 4 ----
net/core/dev.c | 4 +++-
net/core/flow_dissector.c | 4 ++--
net/core/sock.c | 6 ++---
net/dsa/dsa2.c | 11 +++++----
net/ipv4/fib_semantics.c | 9 ++++++--
net/ipv4/sysctl_net_ipv4.c | 2 +-
net/ipv4/tcp_metrics.c | 1 -
net/ipv6/ip6_offload.c | 1 +
net/ipv6/route.c | 4 ++--
net/iucv/af_iucv.c | 25 ++++++++++++---------
net/qrtr/qrtr.c | 4 ++--
net/sctp/outqueue.c | 2 +-
net/socket.c | 2 +-
31 files changed, 243 insertions(+), 121 deletions(-)
^ permalink raw reply
* [PATCH v2] vxlan: Set ports in flow key when doing route lookups
From: Martynas Pumputis @ 2017-01-11 15:18 UTC (permalink / raw)
To: davem; +Cc: netdev, Martynas Pumputis
In-Reply-To: <20170110.211004.1712612611986550798.davem@davemloft.net>
Otherwise, a xfrm policy with sport/dport being set cannot be matched.
Signed-off-by: Martynas Pumputis <martynas@weave.works>
---
Changes in v2:
- Set the source port in the flow key.
drivers/net/vxlan.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index bb70dd5..ca7196c 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -1798,7 +1798,7 @@ static int vxlan_build_skb(struct sk_buff *skb, struct dst_entry *dst,
static struct rtable *vxlan_get_route(struct vxlan_dev *vxlan, struct net_device *dev,
struct vxlan_sock *sock4,
struct sk_buff *skb, int oif, u8 tos,
- __be32 daddr, __be32 *saddr,
+ __be32 daddr, __be32 *saddr, __be16 dport, __be16 sport,
struct dst_cache *dst_cache,
const struct ip_tunnel_info *info)
{
@@ -1824,6 +1824,8 @@ static struct rtable *vxlan_get_route(struct vxlan_dev *vxlan, struct net_device
fl4.flowi4_proto = IPPROTO_UDP;
fl4.daddr = daddr;
fl4.saddr = *saddr;
+ fl4.fl4_dport = dport;
+ fl4.fl4_sport = sport;
rt = ip_route_output_key(vxlan->net, &fl4);
if (likely(!IS_ERR(rt))) {
@@ -1851,6 +1853,7 @@ static struct dst_entry *vxlan6_get_route(struct vxlan_dev *vxlan,
__be32 label,
const struct in6_addr *daddr,
struct in6_addr *saddr,
+ __be16 dport, __be16 sport,
struct dst_cache *dst_cache,
const struct ip_tunnel_info *info)
{
@@ -1877,6 +1880,8 @@ static struct dst_entry *vxlan6_get_route(struct vxlan_dev *vxlan,
fl6.flowlabel = ip6_make_flowinfo(RT_TOS(tos), label);
fl6.flowi6_mark = skb->mark;
fl6.flowi6_proto = IPPROTO_UDP;
+ fl6.fl6_dport = dport;
+ fl6.fl6_sport = sport;
err = ipv6_stub->ipv6_dst_lookup(vxlan->net,
sock6->sock->sk,
@@ -2068,6 +2073,7 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct net_device *dev,
rdst ? rdst->remote_ifindex : 0, tos,
dst->sin.sin_addr.s_addr,
&src->sin.sin_addr.s_addr,
+ dst_port, src_port,
dst_cache, info);
if (IS_ERR(rt)) {
err = PTR_ERR(rt);
@@ -2104,6 +2110,7 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct net_device *dev,
rdst ? rdst->remote_ifindex : 0, tos,
label, &dst->sin6.sin6_addr,
&src->sin6.sin6_addr,
+ dst_port, src_port,
dst_cache, info);
if (IS_ERR(ndst)) {
err = PTR_ERR(ndst);
@@ -2430,7 +2437,7 @@ static int vxlan_fill_metadata_dst(struct net_device *dev, struct sk_buff *skb)
rt = vxlan_get_route(vxlan, dev, sock4, skb, 0, info->key.tos,
info->key.u.ipv4.dst,
- &info->key.u.ipv4.src, NULL, info);
+ &info->key.u.ipv4.src, dport, sport, NULL, info);
if (IS_ERR(rt))
return PTR_ERR(rt);
ip_rt_put(rt);
@@ -2441,7 +2448,7 @@ static int vxlan_fill_metadata_dst(struct net_device *dev, struct sk_buff *skb)
ndst = vxlan6_get_route(vxlan, dev, sock6, skb, 0, info->key.tos,
info->key.label, &info->key.u.ipv6.dst,
- &info->key.u.ipv6.src, NULL, info);
+ &info->key.u.ipv6.src, dport, sport, NULL, info);
if (IS_ERR(ndst))
return PTR_ERR(ndst);
dst_release(ndst);
--
2.10.2
^ permalink raw reply related
* Re: [PATCH v2 0/2] remove dwc_eth_qos and rename stmicro/stmmac
From: David Miller @ 2017-01-11 15:20 UTC (permalink / raw)
To: Joao.Pinto
Cc: alexandre.torgue, lars.persson, niklass, peppe.cavallaro, netdev
In-Reply-To: <329b0d8c-4cda-7238-c229-d69ac251f26b@synopsys.com>
From: Joao Pinto <Joao.Pinto@synopsys.com>
Date: Wed, 11 Jan 2017 15:06:55 +0000
> The goal of this work is to improve code organization and future merge of other
> Synopsys Ethernet IP driver that will be able to merge into this "synopsys
> driver bundle". That is why I volunteered to merge the dwc qos axis' driver into
> stmmac.
Then I want to see an ACK from Alexandre and Peppe for this renaming
patch set.
^ permalink raw reply
* Re: 4.9.2 panic, __skb_flow_dissect, gro?
From: Ian Kumlien @ 2017-01-11 15:19 UTC (permalink / raw)
To: David Miller; +Cc: Denys Fedoryshchenko, Linux Kernel Network Developers
In-Reply-To: <20170110.200804.303728442314129894.davem@davemloft.net>
On Wed, Jan 11, 2017 at 2:08 AM, David Miller <davem@davemloft.net> wrote:
> From: Denys Fedoryshchenko <nuclearcat@nuclearcat.com>
> Date: Wed, 11 Jan 2017 01:49:34 +0200
>
>> It seems this patch solve issue. I hope it will go to stable asap,
>> because without it loaded routers crashing almost instantly on 4.9.
>
> I will submit this soon.
Btw, any special reason why that code is written like it is? Stack depth?
^ permalink raw reply
* Re: [RFC PATCH] tcp: accept RST for rcv_nxt - 1 after receiving a FIN
From: Jason Baron @ 2017-01-11 15:14 UTC (permalink / raw)
To: Christoph Paasch; +Cc: netdev, Eric Dumazet
In-Reply-To: <20170111051708.GC23178@Chimay.local>
On 01/11/2017 12:17 AM, Christoph Paasch wrote:
> Hello Jason,
>
> (resending as Gmail sent out with HTML)
>
> On 05/01/17 - 16:33:28, Jason Baron wrote:
>> Using a Mac OSX box as a client connecting to a Linux server, we have found
>> that when certain applications (such as 'ab'), are abruptly terminated
>> (via ^C), a FIN is sent followed by a RST packet on tcp connections. The
>> FIN is accepted by the Linux stack but the RST is sent with the same
>> sequence number as the FIN, and Linux responds with a challenge ACK per
>> RFC 5961. The OSX client then does not reply with any RST as would be
>> expected on a closed socket.
>
> do you see this behavior consistently, even in a controlled environment?
>
> The problem seems rather to be that after the first RST, the NAT on the path
> has dropped its mapping and is thus dropping all other traffic. So, Linux's
> challenge-ack does not go through to the OSX-host to "re-synchronize" the
> state (which would allow OSX to send a RST with the updated sequence numbers).
>
> This is also documented in RFC5961:
>
> 9.3. Middleboxes That Drop the Challenge ACK
>
> It also needs to be noted that, some middleboxes (Firewalls/NATs)
> that don't have the fix recommended in the document, may drop the
> challenge ACK. This can happen because, the original RST segment
> that was in window had already cleared the flow state pertaining to
> the TCP connection in the middlebox. In such cases, the end hosts
> that have implemented the RST mitigation described in this document,
> will have the TCP connection left open. This is a corner case and
> can go away if the middlebox is conformant with the changes proposed
> in this document.
>
Yes, I've observed a couple of different ways that this can happen:
1) The case where Mac OSX does not send an RST in response to the
challenge ACK. I found that there is actually a rate limit to the number
of 'RSTs' that Mac OSX will send on a closed socket. Its
controlled by: 'net.inet.icmp.icmplim'. By default its set to 250, which
means it will send up to 250 'RSTs' on closed sockets per second. Thus,
I've confirmed that I can hit this limit by looking in the Mac OSX logs.
2) When I had the Mac OSX box connecting over a vpn to the linux server
I found that while the challenge ack sent by Linux did reach the Mac OSX
box, the RST that Mac OSX sent could get dropped somewhere in between.
That is I see it sent from the Mac OSX box but never see it received by
the Linux server. Thus, this is closer to the scenario you described above.
Also, as mentioned we've had this deployed in production where we've
seen this change make a real difference in capacity (due to freeing up
memory resources much more quickly). Since, I don't have dumps from the
client side I can't say exactly what the sequence of events is there.
Thanks,
-Jason
>
>
> Cheers,
> Christoph
>
>>
>> This results in sockets accumulating on the Linux server left mostly in
>> the CLOSE_WAIT state, although LAST_ACK and CLOSING are also possible.
>> This sequence of events can tie up a lot of resources on the Linux server
>> since there may be a lot of data in write buffers at the time of the RST.
>> Accepting a RST equal to rcv_nxt - 1, after we have already successfully
>> processed a FIN, has made a significant difference for us in practice, by
>> freeing up unneeded resources in a more expedient fashion.
>>
>> I also found a posting that the iOS client behaves in a similar manner here
>> (it will send a FIN followed by a RST for rcv_nxt - 1):
>> https://www.snellman.net/blog/archive/2016-02-01-tcp-rst/
>>
>> A packetdrill test demonstrating the behavior.
>>
>> // testing mac osx rst behavior
>>
>> // Establish a connection
>> 0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
>> 0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
>> 0.000 bind(3, ..., ...) = 0
>> 0.000 listen(3, 1) = 0
>>
>> 0.100 < S 0:0(0) win 32768 <mss 1460,nop,wscale 10>
>> 0.100 > S. 0:0(0) ack 1 <mss 1460,nop,wscale 5>
>> 0.200 < . 1:1(0) ack 1 win 32768
>> 0.200 accept(3, ..., ...) = 4
>>
>> // Client closes the connection
>> 0.300 < F. 1:1(0) ack 1 win 32768
>>
>> // now send rst with same sequence
>> 0.300 < R. 1:1(0) ack 1 win 32768
>>
>> // make sure we are in TCP_CLOSE
>> 0.400 %{
>> assert tcpi_state == 7
>> }%
>>
>> Signed-off-by: Jason Baron <jbaron@akamai.com>
>> ---
>> net/ipv4/tcp_input.c | 23 ++++++++++++++++++++++-
>> 1 file changed, 22 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
>> index ec6d84363024..373bea05c93b 100644
>> --- a/net/ipv4/tcp_input.c
>> +++ b/net/ipv4/tcp_input.c
>> @@ -5249,6 +5249,24 @@ static int tcp_copy_to_iovec(struct sock *sk, struct sk_buff *skb, int hlen)
>> return err;
>> }
>>
>> +/* Accept RST for rcv_nxt - 1 after a FIN.
>> + * When tcp connections are abruptly terminated from Mac OSX (via ^C), a
>> + * FIN is sent followed by a RST packet. The RST is sent with the same
>> + * sequence number as the FIN, and thus according to RFC 5961 a challenge
>> + * ACK should be sent. However, Mac OSX does not reply to the challenge ACK
>> + * with a RST on the closed socket, hence accept this class of RSTs.
>> + */
>> +static bool tcp_reset_check(struct sock *sk, struct sk_buff *skb)
>> +{
>> + struct tcp_sock *tp = tcp_sk(sk);
>> +
>> + return unlikely((TCP_SKB_CB(skb)->seq == (tp->rcv_nxt - 1)) &&
>> + (TCP_SKB_CB(skb)->end_seq == (tp->rcv_nxt - 1)) &&
>> + (sk->sk_state == TCP_CLOSE_WAIT ||
>> + sk->sk_state == TCP_LAST_ACK ||
>> + sk->sk_state == TCP_CLOSING));
>> +}
>> +
>> /* Does PAWS and seqno based validation of an incoming segment, flags will
>> * play significant role here.
>> */
>> @@ -5287,6 +5305,8 @@ static bool tcp_validate_incoming(struct sock *sk, struct sk_buff *skb,
>> LINUX_MIB_TCPACKSKIPPEDSEQ,
>> &tp->last_oow_ack_time))
>> tcp_send_dupack(sk, skb);
>> + } else if (tcp_reset_check(sk, skb)) {
>> + tcp_reset(sk);
>> }
>> goto discard;
>> }
>> @@ -5300,7 +5320,8 @@ static bool tcp_validate_incoming(struct sock *sk, struct sk_buff *skb,
>> * else
>> * Send a challenge ACK
>> */
>> - if (TCP_SKB_CB(skb)->seq == tp->rcv_nxt) {
>> + if (TCP_SKB_CB(skb)->seq == tp->rcv_nxt ||
>> + tcp_reset_check(sk, skb)) {
>> rst_seq_match = true;
>> } else if (tcp_is_sack(tp) && tp->rx_opt.num_sacks > 0) {
>> struct tcp_sack_block *sp = &tp->selective_acks[0];
>> --
>> 2.6.1
>>
^ permalink raw reply
* Re: net: ti: cpsw-phy-sel: RGMII is not working on AM335x
From: Andrew Lunn @ 2017-01-11 15:14 UTC (permalink / raw)
To: Teresa Remmet
Cc: Alexandru Gagniuc, David S. Miller, Mugunthan V N,
Grygorii Strashko, linux-omap, netdev
In-Reply-To: <1484122463.3777.1.camel@phytec.de>
> So I wonder what is correct now? As for me the patch makes RGMII unusable.
> Has anyone an explanation?
Hi Teresa
In your device tree, what phy-mode do you have?
And does your hardware require an RGMII delay in order that it works?
Andrew
^ permalink raw reply
* RE: [PATCH v2 8/8] crypto/testmgr: Allocate only the required output size for hash tests
From: David Laight @ 2017-01-11 15:13 UTC (permalink / raw)
To: 'Andy Lutomirski', Daniel Borkmann, Netdev, LKML,
Linux Crypto Mailing List
Cc: Jason A. Donenfeld, Hannes Frederic Sowa, Alexei Starovoitov,
Eric Dumazet, Eric Biggers, Tom Herbert, David S. Miller,
Ard Biesheuvel, Herbert Xu
In-Reply-To: <890f4bdb28a1cf72f6b802b220b35ebaf0f76bb9.1484090585.git.luto@kernel.org>
From: Andy Lutomirski
> Sent: 10 January 2017 23:25
> There are some hashes (e.g. sha224) that have some internal trickery
> to make sure that only the correct number of output bytes are
> generated. If something goes wrong, they could potentially overrun
> the output buffer.
>
> Make the test more robust by allocating only enough space for the
> correct output size so that memory debugging will catch the error if
> the output is overrun.
Might be better to test this by allocating an overlong buffer
and then explicitly checking that the output hasn't overrun
the allowed space.
If nothing else the error message will be clearer.
David
^ permalink raw reply
* Re: [PATCH net-next 1/2] phy: marvell: Add support for temperature sensor
From: Andrew Lunn @ 2017-01-11 15:09 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Vivien Didelot, Florian Fainelli
In-Reply-To: <1484096604-25033-2-git-send-email-andrew@lunn.ch>
> +static int marvell_hwmon_probe(struct phy_device *phydev,
> + const struct hwmon_chip_info *chip)
> +{
> + struct marvell_priv *priv = phydev->priv;
> + struct device *dev = &phydev->mdio.dev;
> + int err;
> +
> + err = marvell_hwmon_name(phydev);
> + if (err)
> + return err;
> +
> + priv->hwmon_dev = devm_hwmon_device_register_with_info(
> + dev, priv->hwmon_name, phydev, chip, NULL);
> +
> + if (IS_ERR(priv->hwmon_dev))
> + return PTR_ERR(priv->hwmon_dev);
> +
> + return 0;
> +}
0-day has pointed out this can be simplified to just
return PTR_ERR(priv->hwmon_dev);
I will submit a v2 in a couple of days, when others have had chance to
comment.
Andrew
^ permalink raw reply
* Re: [PATCH v2 0/2] remove dwc_eth_qos and rename stmicro/stmmac
From: Joao Pinto @ 2017-01-11 15:06 UTC (permalink / raw)
To: David Miller, alexandre.torgue
Cc: Joao.Pinto, lars.persson, niklass, peppe.cavallaro, netdev
In-Reply-To: <20170111.095256.1057845755758556047.davem@davemloft.net>
Hello David,
Às 2:52 PM de 1/11/2017, David Miller escreveu:
> From: Alexandre Torgue <alexandre.torgue@st.com>
> Date: Wed, 11 Jan 2017 12:39:09 +0100
>
>> Let's see what David think about that but if there no risk of backward
>> compatibility with DT, I agree with the series.
>
> I really am generally against driver renames. The only potentially
> make new users happy, but can only negatively impact existing users.
>
> The new name is not terribly appropriate either, it is using the name
> of the manufacturer rather than referring to a chipset or a class or
> chipsets.
stmmac is in fact a bundle of Synopsys Ethernet IPs. We can go with Jie'
suggestion a include all the Ips it supports like "Synopsys 10M/100M/1G/eQOS
Ethernet Drivers".
>
> I don't see what the big deal is in leaving the name as 'stmmac' and
> in a way leaving it alone shows respect for the people who have worked
> on and cared for the stmmac driver for all of these years.
I have a huge respect for STMicroelectronics and above all respect for the
developers that work hard to put things working properly and care for it, and
that's why before starting developing I had a discussion with stmmac maintainers
in order to align with them. From me you can only expect collaboration, help and
dedication, since Linux is for common good right, or at least I believe so.
Another thing to point is that I wish that Alexandre and Peppe remain
maintainers since they are doing an excelent job.
The goal of this work is to improve code organization and future merge of other
Synopsys Ethernet IP driver that will be able to merge into this "synopsys
driver bundle". That is why I volunteered to merge the dwc qos axis' driver into
stmmac.
Thanks.
Joao
>
> Thanks.
>
^ permalink raw reply
* Re: [PATCH] wext: handle NULL exta data in iwe_stream_add_point better
From: Johannes Berg @ 2017-01-11 15:06 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-wireless, David S. Miller, Networking, linux-kernel
In-Reply-To: <CAK8P3a2mOT=BG=9yxJ1e-q__5FYq6dfF3t3bT1vqcgFaQAUjog@mail.gmail.com>
On Wed, 2017-01-11 at 16:00 +0100, Arnd Bergmann wrote:
> On Wed, Jan 11, 2017 at 3:38 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > On Wed, 2017-01-11 at 15:35 +0100, Arnd Bergmann wrote:
> > > This works fine here because iwe->u.data.length is guaranteed to
> > > be
> > > NULL, and the memcpy doesn't actually have an effect.
> >
> > I think you mean 0, not NULL, but I can fix that when I apply it.
>
> Right, thanks!
Applied. Also fixed the typo in the subject :)
johannes
^ permalink raw reply
* Re: [PATCH] net: vrf: do not allow table id 0
From: David Miller @ 2017-01-11 15:04 UTC (permalink / raw)
To: dsa; +Cc: netdev, frank.kellermann
In-Reply-To: <1484090545-16407-1-git-send-email-dsa@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Tue, 10 Jan 2017 15:22:25 -0800
> Frank reported that vrf devices can be created with a table id of 0.
> This breaks many of the run time table id checks and should not be
> allowed. Detect this condition at create time and fail with EINVAL.
>
> Fixes: 193125dbd8eb ("net: Introduce VRF device driver")
> Reported-by: Frank Kellermann <frank.kellermann@atos.net>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Applied and queued up for -stable, thanks David.
^ permalink raw reply
* Re: [PATCH] net: phy: marvell: fix Marvell 88E1512 used in SGMII mode
From: David Miller @ 2017-01-11 15:03 UTC (permalink / raw)
To: f.fainelli
Cc: andrew, rmk+kernel, netdev, linux-arm-kernel,
charles-antoine.couret
In-Reply-To: <61950d83-cbe1-6e1b-4afc-bc471b386ff3@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 10 Jan 2017 15:24:11 -0800
> Fixes: 6cfb3bcc0641 ("Marvell phy: check link status in case of fiber
> link.")
Thanks, I added this to Russell's commit message.
^ permalink raw reply
* Re: [PATCH] net: phy: marvell: fix Marvell 88E1512 used in SGMII mode
From: David Miller @ 2017-01-11 15:03 UTC (permalink / raw)
To: rmk+kernel
Cc: f.fainelli, andrew, charles-antoine.couret, linux-arm-kernel,
netdev
In-Reply-To: <E1cR5bt-0000O8-1T@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Tue, 10 Jan 2017 23:13:45 +0000
> When an Marvell 88E1512 PHY is connected to a nic in SGMII mode, the
> fiber page is used for the SGMII host-side connection. The PHY driver
> notices that SUPPORTED_FIBRE is set, so it tries reading the fiber page
> for the link status, and ends up reading the MAC-side status instead of
> the outgoing (copper) link. This leads to incorrect results reported
> via ethtool.
>
> If the PHY is connected via SGMII to the host, ignore the fiber page.
> However, continue to allow the existing power management code to
> suspend and resume the fiber page.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Applied, thanks Russell.
^ permalink raw reply
* [PATCH] softingcs: ret is never non-zero, so remove non-zero check and -ENODEV return
From: Colin King @ 2017-01-11 15:02 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde, linux-can, netdev; +Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The error return ret is never zero in the error handling path in
softingcs_probe, so the check for non-zero and returning -ENODEV
is logically dead code and hence redundant. Remove it and just
return ret.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/can/softing/softing_cs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/softing/softing_cs.c b/drivers/net/can/softing/softing_cs.c
index cdc0c74..4d44928 100644
--- a/drivers/net/can/softing/softing_cs.c
+++ b/drivers/net/can/softing/softing_cs.c
@@ -310,7 +310,7 @@ static int softingcs_probe(struct pcmcia_device *pcmcia)
pcmcia_failed:
pcmcia_disable_device(pcmcia);
pcmcia->priv = NULL;
- return ret ?: -ENODEV;
+ return ret;
}
static const struct pcmcia_device_id softingcs_ids[] = {
--
2.10.2
^ permalink raw reply related
* Re: [PATCH] sctp: Fix spelling mistake: "Atempt" -> "Attempt"
From: David Miller @ 2017-01-11 15:01 UTC (permalink / raw)
To: colin.king; +Cc: vyasevich, nhorman, linux-sctp, netdev, linux-kernel
In-Reply-To: <20170110225306.14880-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Tue, 10 Jan 2017 22:53:06 +0000
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake in WARN_ONCE message
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] net: ipv4: Fix multipath selection with vrf
From: David Miller @ 2017-01-11 15:00 UTC (permalink / raw)
To: dsa; +Cc: netdev
In-Reply-To: <1484087855-4607-1-git-send-email-dsa@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Tue, 10 Jan 2017 14:37:35 -0800
> fib_select_path does not call fib_select_multipath if oif is set in the
> flow struct. For VRF use cases oif is always set, so multipath route
> selection is bypassed. Use the FLOWI_FLAG_SKIP_NH_OIF to skip the oif
> check similar to what is done in fib_table_lookup.
>
> Add saddr and proto to the flow struct for the fib lookup done by the
> VRF driver to better match hash computation for a flow.
>
> Fixes: 613d09b30f8b ("net: Use VRF device index for lookups on TX")
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
> ---
> IPv6 multipath selection works fine as is.
Applied and queued up for -stable, thanks David.
^ permalink raw reply
* Re: [PATCH] wext: handle NULL exta data in iwe_stream_add_point better
From: Arnd Bergmann @ 2017-01-11 15:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, David S. Miller, Networking, linux-kernel
In-Reply-To: <1484145522.29931.13.camel@sipsolutions.net>
On Wed, Jan 11, 2017 at 3:38 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2017-01-11 at 15:35 +0100, Arnd Bergmann wrote:
>> This works fine here because iwe->u.data.length is guaranteed to be
>> NULL, and the memcpy doesn't actually have an effect.
>
> I think you mean 0, not NULL, but I can fix that when I apply it.
Right, thanks!
Arnd
^ permalink raw reply
* Re: [PATCH net-next 0/4] net: switchdev: Avoid sleep in atomic with DSA
From: Andrew Lunn @ 2017-01-11 14:59 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Ido Schimmel, Jiri Pirko, netdev, davem, vivien.didelot
In-Reply-To: <03ce7d38-7775-3cd7-d863-682316d949bf@gmail.com>
> Vivien, Andrew, are you aware of an use case where we have the HW
> programmed with a superset of VLANs wrt. the SW bridge?
I cannot think of any case with a superset. Subset yes, but not
superset.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 0/2] net: dsa: Implement ndo_get_phys_port_name()
From: David Miller @ 2017-01-11 14:59 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, vivien.didelot, andrew, jiri
In-Reply-To: <20170110203237.23907-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 10 Jan 2017 12:32:35 -0800
> This patch series implements ndo_get_phys_port_name() so we can revert
> ndo_get_phys_id() which was (ab)used in the DSA layer.
Series applied, thanks Florian.
^ permalink raw reply
* Re: [PATCH v2 0/2] remove dwc_eth_qos and rename stmicro/stmmac
From: Joao Pinto @ 2017-01-11 14:54 UTC (permalink / raw)
To: Alexandre Torgue, Joao Pinto, davem
Cc: lars.persson, niklass, peppe.cavallaro, netdev
In-Reply-To: <8bdb613c-36d3-811f-6300-9c97110c855d@st.com>
Às 2:39 PM de 1/11/2017, Alexandre Torgue escreveu:
>
>
> On 01/11/2017 03:29 PM, Joao Pinto wrote:
>>
>> Alex,
>>
>> Às 2:25 PM de 1/11/2017, Alexandre Torgue escreveu:
>>> Jao,
>>>
>>> On 01/11/2017 12:54 PM, Joao Pinto wrote:
>>>>
>>>> Hi Alex,
>>>>
>>>> Às 11:39 AM de 1/11/2017, Alexandre Torgue escreveu:
>>>>> Hi Jao,
>>>>>
>>>>> On 01/10/2017 03:52 PM, Joao Pinto wrote:
>>>>>> This patch set removes the synopsys/dwc_eth_qos since it was merged recently
>>>>>> to stmmac (dwmac-dwc-qos-eth glue driver).
>>>>>>
>>>>>> It also renames stmicro/stmmac to synopsys/ since it is a standard ethernet
>>>>>> software package regarding synopsys ethernet controllers, supporting the
>>>>>> majority of Synopsys Ethernet IPs.
>>>>>
>>>>> I understand the reason to rename stmmac driver. The only risk I see is that
>>>>> usual user will be a little bit lost to find code. It seems there no risk of
>>>>> backward compatibility with current/old DT (I assume you already checked this
>>>>> point).
>>>>
>>>> I understand your concern, but for the Synopsys IPs users will be clearer what
>>>> drivers to use and what current stmmac has to offer.
>>>
>>> I agree.
>>>
>>>>
>>>> In terms of tests, I tested it and worked out of the box because the same
>>>> Kconfig IDs were used assuring the retro-compatibility that David suggested a
>>>> few weeks ago. For DT users no problems are expected as well.
>>>
>>> Ok, sounds good.
>>>
>>> I see that you rename also Documentation/devicetree/bindings/net/stmmac.txt. You
>>> have also to change some words inside as it talks about Stmicroelectronics.
>>
>> You are right. Going to change that and send a v3. Counting on your ack :)
>
> I continue to review ;)
> There is another point to talk. It will be strange to have the driver named
> "synopsys" but all file inside will continue to be called "stmmac" (and also
> function inside files). So either you plan to keep it as it is (and it is a
> little bit confusing) or you plan to change all file name + function name (+ few
> variable name) ?
The plan would be to change incrementally, but I have no problem in doing it all
now.
I am going to give you an example of something that must be done.
Syniopsys IP portfolium does not include a GMAC4 core, because it does not
exist. I understand why stmmac calls that way, but it is not accurate. Going to
explain why. Synopsys has the eQoS IP which version began at 4.x, and for
historical reasons drivers chose to call it gmac4 or dwmac4, when in fact it
should be named eqos or dwmac_eqos. This will have to be changed since when a
new version of eQoS is released, imagine 5.00, it will become completely
confusing. This is the reason why the files and functions named after gmac4 and
dwmac4 should be called eqos and dwmac-eqos.
We can make a total rename instead of renaming basic stuff, no problem. What do
you think?
Joao
>
> regards
> Alex
>
>
>
>
>> Thanks!
>>
>>>
>>> Regards
>>> Alex
>>>
>>>>
>>>> Thanks,
>>>> Joao
>>>>
>>>>> Let's see what David think about that but if there no risk of backward
>>>>> compatibility with DT, I agree with the series.
>>>>>
>>>>> Regards
>>>>> Alex
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> In the future we should make an effort to migrate to this new synopsys/
>>>>>> driver package all the Ethernet Synopsys IP drivers scattered in
>>>>>> net/ethernet.
>>>>>>
>>>>>> Joao Pinto (2):
>>>>>> synopsys: remove dwc_eth_qos driver
>>>>>> stmmac: rename it to synopsys
>>>>>>
>>>>>> .../bindings/net/{stmmac.txt => synopsys.txt} | 0
>>>>>> MAINTAINERS | 11 +-
>>>>>> arch/arm/configs/multi_v7_defconfig | 3 +-
>>>>>> drivers/net/ethernet/Kconfig | 3 +-
>>
^ permalink raw reply
* Re: [PATCH v2 0/2] remove dwc_eth_qos and rename stmicro/stmmac
From: David Miller @ 2017-01-11 14:52 UTC (permalink / raw)
To: alexandre.torgue
Cc: Joao.Pinto, lars.persson, niklass, peppe.cavallaro, netdev
In-Reply-To: <0dcdcb5f-200b-b130-9a67-774639353114@st.com>
From: Alexandre Torgue <alexandre.torgue@st.com>
Date: Wed, 11 Jan 2017 12:39:09 +0100
> Let's see what David think about that but if there no risk of backward
> compatibility with DT, I agree with the series.
I really am generally against driver renames. The only potentially
make new users happy, but can only negatively impact existing users.
The new name is not terribly appropriate either, it is using the name
of the manufacturer rather than referring to a chipset or a class or
chipsets.
I don't see what the big deal is in leaving the name as 'stmmac' and
in a way leaving it alone shows respect for the people who have worked
on and cared for the stmmac driver for all of these years.
Thanks.
^ permalink raw reply
* Re: [PATCH] cgroup: move CONFIG_SOCK_CGROUP_DATA to init/Kconfig
From: David Miller @ 2017-01-11 14:48 UTC (permalink / raw)
To: arnd; +Cc: netdev, ast, luto, augustocaringi, linux-kernel
In-Reply-To: <20170110120825.2984218-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 10 Jan 2017 13:08:06 +0100
> We now 'select SOCK_CGROUP_DATA' but Kconfig complains that this is
> not right when CONFIG_NET is disabled and there is no socket interface:
>
> warning: (CGROUP_BPF) selects SOCK_CGROUP_DATA which has unmet direct dependencies (NET)
>
> I don't know what the correct solution for this is, but simply removing
> the dependency on NET from SOCK_CGROUP_DATA by moving it out of the
> 'if NET' section avoids the warning and does not produce other build
> errors.
>
> Fixes: 483c4933ea09 ("cgroup: Fix CGROUP_BPF config")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> There was an earlier patch by Augusto Mecking Caringi, which added
> a dependency, see https://lkml.org/lkml/2017/1/2/296.
>
> I could not figure out whether CGROUP_BPF is meaningful without
> CONFIG_NET, my version of the patch assumes that it is.
> Applying either my version Augusto's to v4.10-rc will kill the
> warning.
CGROUP_BPF doesn't is not currently meaningful without CONFIG_NET,
and especially SOCK_CGROUP_DATA is not meaningful without CONFIG_NET.
Patch applied, thanks.
^ 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