* Re: [RFC PATCH mlx5-next 02/18] net/mlx5: Export modify header alloc/dealloc functions
From: Or Gerlitz @ 2018-07-16 21:27 UTC (permalink / raw)
To: Mark Bloch
Cc: Doug Ledford, Jason Gunthorpe, Leon Romanovsky, RDMA mailing list,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180716082305.11744-3-leon@kernel.org>
On Mon, Jul 16, 2018 at 11:22 AM, Leon Romanovsky <leon@kernel.org> wrote:
> From: Mark Bloch <markb@mellanox.com>
>
> Those function will be used by the RDMA side to create modify header
function --> functions
> actions to be attached to flow steering rules via verbs.
^ permalink raw reply
* Re: [PATCH next] bonding: pass link-local packets to bonding master also.
From: Jay Vosburgh @ 2018-07-16 21:24 UTC (permalink / raw)
To: Mahesh Bandewar
Cc: Andy Gospodarek, Veaceslav Falico, David Miller, Netdev,
Michal Soltys, Mahesh Bandewar
In-Reply-To: <20180716011246.225647-1-mahesh@bandewar.net>
Mahesh Bandewar <mahesh@bandewar.net> wrote:
>From: Mahesh Bandewar <maheshb@google.com>
>
>Commit b89f04c61efe ("bonding: deliver link-local packets with
>skb->dev set to link that packets arrived on") changed the behavior
>of how link-local-multicast packets are processed. The change in
>the behavior broke some legacy use cases where these packets are
>expected to arrive on bonding master device also.
>
>This patch passes the packet to the stack with the link it arrived
>on as well as passes to the bonding-master device to preserve the
>legacy use case.
Michal, can you test this? I'm travelling this week and won't
be able to run the patch.
Mahesh, will this confuse LLDP, et al, daemons that, e.g., bind
to every possible interface and now see the same LLDP PDU (identical
Chassis ID, Port ID, et al, TLVs) on multiple interfaces?
Thanks,
-J
>Reported-by: Michal Soltys <soltys@ziu.info>
>Signed-off-by: Mahesh Bandewar <maheshb@google.com>
>---
> drivers/net/bonding/bond_main.c | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index 9a2ea3c1f949..1d3b7d8448f2 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -1177,9 +1177,22 @@ static rx_handler_result_t bond_handle_frame(struct sk_buff **pskb)
> }
> }
>
>- /* don't change skb->dev for link-local packets */
>- if (is_link_local_ether_addr(eth_hdr(skb)->h_dest))
>+ /* Link-local multicast packets should be passed to the
>+ * stack on the link they arrive as well as pass them to the
>+ * bond-master device. These packets are mostly usable when
>+ * stack receives it with the link on which they arrive
>+ * (e.g. LLDP) but there may be some legacy behavior that
>+ * expects these packets to appear on bonding master too.
>+ */
>+ if (is_link_local_ether_addr(eth_hdr(skb)->h_dest)) {
>+ struct sk_buff *nskb = skb_clone(skb, GFP_ATOMIC);
>+
>+ if (nskb) {
>+ nskb->dev = bond->dev;
>+ netif_rx(nskb);
>+ }
> return RX_HANDLER_PASS;
>+ }
> if (bond_should_deliver_exact_match(skb, slave, bond))
> return RX_HANDLER_EXACT;
>
>--
>2.18.0.203.gfac676dfb9-goog
---
-Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* Re: [RFC PATCH rdma-next 13/18] RDMA/mlx5: Enable decap and packet reformat on flow tables
From: Or Gerlitz @ 2018-07-16 21:23 UTC (permalink / raw)
To: Mark Bloch
Cc: Doug Ledford, Jason Gunthorpe, Leon Romanovsky, RDMA mailing list,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180716082305.11744-14-leon@kernel.org>
On Mon, Jul 16, 2018 at 11:23 AM, Leon Romanovsky <leon@kernel.org> wrote:
> From: Mark Bloch <markb@mellanox.com>
>
> If NIC RX flow tables support decap opertion, enable it on creation.
opertion --> operation
> If NIC TX flow tables support reformat opertion, enable it on creation.
What is the trigger to use the decap flag on RX table or encap flag on
TX table?
Please note that we have a short blanket w.r.t mutual usage by
NIC vs e-Switch steering, did you consider to do that on demand?
^ permalink raw reply
* Re: [PATCH net V2 1/1] net/smc: take sock lock in smc_ioctl()
From: David Miller @ 2018-07-16 21:45 UTC (permalink / raw)
To: ubraun
Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl,
linux-kernel, eric.dumazet, lifeasageek, sbrivio
In-Reply-To: <20180716115652.72331-1-ubraun@linux.ibm.com>
From: Ursula Braun <ubraun@linux.ibm.com>
Date: Mon, 16 Jul 2018 13:56:52 +0200
> From: Ursula Braun <ursula.braun@linux.ibm.com>
>
> SMC ioctl processing requires the sock lock to work properly in
> all thinkable scenarios.
> Problem has been found with RaceFuzzer and fixes:
> KASAN: null-ptr-deref Read in smc_ioctl
>
> Reported-by: Byoungyoung Lee <lifeasageek@gmail.com>
> Reported-by: syzbot+35b2c5aa76fd398b9fd4@syzkaller.appspotmail.com
> Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [RFC PATCH mlx5-next 01/18] net/mlx5: Add proper NIC TX steering flow tables support
From: Or Gerlitz @ 2018-07-16 21:14 UTC (permalink / raw)
To: Mark Bloch
Cc: Doug Ledford, Jason Gunthorpe, Leon Romanovsky, RDMA mailing list,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180716082305.11744-2-leon@kernel.org>
On Mon, Jul 16, 2018 at 11:22 AM, Leon Romanovsky <leon@kernel.org> wrote:
> From: Mark Bloch <markb@mellanox.com>
>
> Expose the ability to add steering rules to NIC TX flow tables.
> For now, we are only adding TX bypass (egress) which is used by the RDMA
> side. While we are here clean the switch logic.
>
> We expose the same number of priorities as the RX bypass.
What is the use-case / model for priorities in TX steering?
Is/where this (tx prios) is used @ downstream patch?
Or.
^ permalink raw reply
* Re: [PATCH] net: lan78xx: Fix race in tx pending skb size calculation
From: David Miller @ 2018-07-16 21:13 UTC (permalink / raw)
To: stefan.wahren
Cc: woojung.huh, UNGLinuxDriver, gregkh, dave.stevenson, netdev,
linux-usb, stable, bos
In-Reply-To: <1531684400-15778-1-git-send-email-stefan.wahren@i2se.com>
From: Stefan Wahren <stefan.wahren@i2se.com>
Date: Sun, 15 Jul 2018 21:53:20 +0200
> The skb size calculation in lan78xx_tx_bh is in race with the start_xmit,
> which could lead to rare kernel oopses. So protect the whole skb walk with
> a spin lock. As a benefit we can unlink the skb directly.
>
> This patch was tested on Raspberry Pi 3B+
>
> Link: https://github.com/raspberrypi/linux/issues/2608
> Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet")
> Cc: stable <stable@vger.kernel.org>
> Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH v2 net] net/ipv6: Do not allow device only routes via the multipath API
From: David Miller @ 2018-07-16 21:09 UTC (permalink / raw)
To: dsahern; +Cc: netdev, eric.dumazet, dsahern
In-Reply-To: <20180715163519.12917-1-dsahern@kernel.org>
From: dsahern@kernel.org
Date: Sun, 15 Jul 2018 09:35:19 -0700
> From: David Ahern <dsahern@gmail.com>
>
> Eric reported that reverting the patch that fixed and simplified IPv6
> multipath routes means reverting back to invalid userspace notifications.
> eg.,
> $ ip -6 route add 2001:db8:1::/64 nexthop dev eth0 nexthop dev eth1
>
> only generates a single notification:
> 2001:db8:1::/64 dev eth0 metric 1024 pref medium
>
> While working on a fix for this problem I found another case that is just
> broken completely - a multipath route with a gateway followed by device
> followed by gateway:
> $ ip -6 ro add 2001:db8:103::/64
> nexthop via 2001:db8:1::64
> nexthop dev dummy2
> nexthop via 2001:db8:3::64
>
> In this case the device only route is dropped completely - no notification
> to userpsace but no addition to the FIB either:
>
> $ ip -6 ro ls
> 2001:db8:1::/64 dev dummy1 proto kernel metric 256 pref medium
> 2001:db8:2::/64 dev dummy2 proto kernel metric 256 pref medium
> 2001:db8:3::/64 dev dummy3 proto kernel metric 256 pref medium
> 2001:db8:103::/64 metric 1024
> nexthop via 2001:db8:1::64 dev dummy1 weight 1
> nexthop via 2001:db8:3::64 dev dummy3 weight 1 pref medium
> fe80::/64 dev dummy1 proto kernel metric 256 pref medium
> fe80::/64 dev dummy2 proto kernel metric 256 pref medium
> fe80::/64 dev dummy3 proto kernel metric 256 pref medium
>
> Really, IPv6 multipath is just FUBAR'ed beyond repair when it comes to
> device only routes, so do not allow it all.
>
> This change will break any scripts relying on the mpath api for insert,
> but I don't see any other way to handle the permutations. Besides, since
> the routes are added to the FIB as standalone (non-multipath) routes the
> kernel is not doing what the user requested, so it might as well tell the
> user that.
>
> Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Applied, thanks David.
Is this a -stable candidate?
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: Don't reuse RX page when XDP is set
From: David Miller @ 2018-07-16 21:08 UTC (permalink / raw)
To: tariqt; +Cc: netdev, eranbe, kafai, saeedm, edumazet
In-Reply-To: <1531652079-27380-1-git-send-email-tariqt@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Date: Sun, 15 Jul 2018 13:54:39 +0300
> From: Saeed Mahameed <saeedm@mellanox.com>
>
> When a new rx packet arrives, the rx path will decide whether to reuse
> the remainder of the page or not according to one of the below conditions:
> 1. frag_info->frag_stride == PAGE_SIZE / 2
> 2. frags->page_offset + frag_info->frag_size > PAGE_SIZE;
>
> The first condition is no met for when XDP is set.
> For XDP, page_offset is always set to priv->rx_headroom which is
> XDP_PACKET_HEADROOM and frag_info->frag_size is around mtu size + some
> padding, still the 2nd release condition will hold since
> XDP_PACKET_HEADROOM + 1536 < PAGE_SIZE, as a result the page will not
> be released and will be _wrongly_ reused for next free rx descriptor.
>
> In XDP there is an assumption to have a page per packet and reuse can
> break such assumption and might cause packet data corruptions.
>
> Fix this by adding an extra condition (!priv->rx_headroom) to the 2nd
> case to avoid page reuse when XDP is set, since rx_headroom is set to 0
> for non XDP setup and set to XDP_PACKET_HEADROOM for XDP setup.
>
> No additional cache line is required for the new condition.
>
> Fixes: 34db548bfb95 ("mlx4: add page recycling in receive path")
> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
> Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
> Suggested-by: Martin KaFai Lau <kafai@fb.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [RFC net-next v1 1/1] net/sched: Introduce the taprio scheduler
From: Jakub Kicinski @ 2018-07-16 21:06 UTC (permalink / raw)
To: Vinicius Costa Gomes
Cc: Jiri Pirko, netdev, jesus.sanchez-palencia, tglx, jan.altenberg,
henrik, richardcochran, levi.pearson, jhs, xiyou.wangcong
In-Reply-To: <87va9fgl3g.fsf@intel.com>
On Mon, 16 Jul 2018 10:13:23 -0700, Vinicius Costa Gomes wrote:
> Hi Jiri,
>
> Jiri Pirko <jiri@resnulli.us> writes:
>
> [...]
>
> >>
> >>gates.sched
> >
> > Any particular reason this has to be in file and not on the cmdline?
>
> The idea here was to keep longer schedules more manageable. And during
> testing I found it more ergonomic to have a file.
>
> It also has the advantage that the file can be reused by other tools,
> dump-classifier (awful name, I admit), included in that github gist, is
> one example, it uses the schedule (and some more information) to
> calculate which packets would fall outside their "windows" in a pcap
> dump.
>
> Anyway, if there are use cases that having the schedule in the command
> line helps, I would be happy to add it.
FWIW there is some precedent in cls_bpf/act_bpf for allowing specifying
potentially long sequences both in command line and as a file (cBPF
filters in that case - see man tc-bpf bytecode and bytecode-file).
^ permalink raw reply
* Re: [PATCH net-next] mlxsw: spectrum: Expose counters for various packet sizes
From: David Miller @ 2018-07-16 21:05 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, mlxsw
In-Reply-To: <20180715074542.11951-1-idosch@mellanox.com>
From: Ido Schimmel <idosch@mellanox.com>
Date: Sun, 15 Jul 2018 10:45:42 +0300
> From: Jiri Pirko <jiri@mellanox.com>
>
> Expose counters ASIC has in the group of RFC 2819 counters that count
> number of packets within specific size range.
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net/ethernet/freescale/fman: fix cross-build error
From: David Miller @ 2018-07-16 21:03 UTC (permalink / raw)
To: rdunlap; +Cc: netdev, madalin.bucur, linuxppc-dev
In-Reply-To: <3a063d78-73f8-b41f-9354-fe839fe80c11@infradead.org>
From: Randy Dunlap <rdunlap@infradead.org>
Date: Fri, 13 Jul 2018 21:25:19 -0700
> From: Randy Dunlap <rdunlap@infradead.org>
>
> CC [M] drivers/net/ethernet/freescale/fman/fman.o
> In file included from ../drivers/net/ethernet/freescale/fman/fman.c:35:
> ../include/linux/fsl/guts.h: In function 'guts_set_dmacr':
> ../include/linux/fsl/guts.h:165:2: error: implicit declaration of function 'clrsetbits_be32' [-Werror=implicit-function-declaration]
> clrsetbits_be32(&guts->dmacr, 3 << shift, device << shift);
> ^~~~~~~~~~~~~~~
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] liquidio: fix hang when re-binding VF host drv after running DPDK VF driver
From: David Miller @ 2018-07-16 21:02 UTC (permalink / raw)
To: felix.manlunas
Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla,
ricardo.farrington
In-Reply-To: <20180713195021.GA1178@felix-thinkpad.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Fri, 13 Jul 2018 12:50:21 -0700
> From: Rick Farrington <ricardo.farrington@cavium.com>
>
> When configuring SLI_PKTn_OUTPUT_CONTROL, VF driver was assuming that IPTR
> mode was disabled by reset, which was not true. Since DPDK driver had
> set IPTR mode previously, the VF driver (which uses buf-ptr-only mode) was
> not properly handling DROQ packets (i.e. it saw zero-length packets).
>
> This represented an invalid hardware configuration which the driver could
> not handle.
>
> Signed-off-by: Rick Farrington <ricardo.farrington@cavium.com>
> Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] hv/netvsc: fix handling of fallback to single queue mode
From: David Miller @ 2018-07-16 21:01 UTC (permalink / raw)
To: stephen; +Cc: haiyangz, netdev, sthemmin
In-Reply-To: <20180713173838.15980-1-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Fri, 13 Jul 2018 10:38:38 -0700
> The netvsc device may need to fallback to running in single queue
> mode if host side only wants to support single queue.
>
> Recent change for handling mtu broke this in setup logic.
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Fixes: 3ffe64f1a641 ("hv_netvsc: split sub-channel setup into async and sync")
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Applied.
^ permalink raw reply
* [PATCH net] af_unix: ensure POLLOUT on remote close() for connected dgram sockets
From: Jason Baron @ 2018-07-16 21:00 UTC (permalink / raw)
To: davem; +Cc: netdev, iant, Rainer Weikusat
Applications use ECONNREFUSED as returned from write() in order to
determine that a socket should be closed. When using connected dgram
unix sockets in a poll/write loop, this relies on POLLOUT being
signaled when the remote end closes. However, due to a race POLLOUT
can be missed when the remote closes:
thread 1 (client) thread 2 (server)
connect() to server
write() returns -EAGAIN
unix_dgram_poll()
-> unix_recvq_full() is true
close()
->unix_release_sock()
->wake_up_interruptible_all()
unix_dgram_poll() (due to the
wake_up_interruptible_all)
-> unix_recvq_full() still is true
->free all skbs
Now thread 1 is stuck and will not receive anymore wakeups. In this
case, when thread 1 gets the -EAGAIN, it has not queued any skbs
otherwise the 'free all skbs' step would in fact cause a wakeup and
a POLLOUT return. So the race here is probably fairly rare because
it means there are no skbs that thread 1 queued and that thread 1
runs before the 'free all skbs' step. Nevertheless, this has been
observed when the syslog daemon closes /dev/log. Tested against
a reproducer that re-creates the syslog hang.
The proposed fix is to move the wake_up_interruptible_all() call
after the 'free all skbs' step.
Reported-by: Ian Lance Taylor <iant@golang.org>
Cc: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>
---
net/unix/af_unix.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index e5473c0..de242cf 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -529,8 +529,6 @@ static void unix_release_sock(struct sock *sk, int embrion)
sk->sk_state = TCP_CLOSE;
unix_state_unlock(sk);
- wake_up_interruptible_all(&u->peer_wait);
-
skpair = unix_peer(sk);
if (skpair != NULL) {
@@ -560,6 +558,9 @@ static void unix_release_sock(struct sock *sk, int embrion)
kfree_skb(skb);
}
+ /* after freeing skbs to make sure POLLOUT triggers */
+ wake_up_interruptible_all(&u->peer_wait);
+
if (path.dentry)
path_put(&path);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net] ibmvnic: Revise RX/TX queue error messages
From: David Miller @ 2018-07-16 21:00 UTC (permalink / raw)
To: tlfalcon; +Cc: netdev, jallen, nfont
In-Reply-To: <1531501412-23579-1-git-send-email-tlfalcon@linux.vnet.ibm.com>
From: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Date: Fri, 13 Jul 2018 12:03:32 -0500
> During a device failover, there may be latency between the loss
> of the current backing device and a notification from firmware that
> a failover has occurred. This latency can result in a large amount of
> error printouts as firmware returns outgoing traffic with a generic
> error code. These are not necessarily errors in this case as the
> firmware is busy swapping in a new backing adapter and is not ready
> to send packets yet. This patch reclassifies those error codes as
> warnings with an explanation that a failover may be pending. All
> other return codes will be considered errors.
>
> Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] ipv6: make DAD fail with enhanced DAD when nonce length differs
From: David Miller @ 2018-07-16 20:45 UTC (permalink / raw)
To: sd; +Cc: netdev, nordmark, gilligan, hannes, sbrivio
In-Reply-To: <d477c52e54bcfc32f41df33ce48251543033d468.1531494812.git.sd@queasysnail.net>
From: Sabrina Dubroca <sd@queasysnail.net>
Date: Fri, 13 Jul 2018 17:21:42 +0200
> Commit adc176c54722 ("ipv6 addrconf: Implemented enhanced DAD (RFC7527)")
> added enhanced DAD with a nonce length of 6 bytes. However, RFC7527
> doesn't specify the length of the nonce, other than being 6 + 8*k bytes,
> with integer k >= 0 (RFC3971 5.3.2). The current implementation simply
> assumes that the nonce will always be 6 bytes, but others systems are
> free to choose different sizes.
>
> If another system sends a nonce of different length but with the same 6
> bytes prefix, it shouldn't be considered as the same nonce. Thus, check
> that the length of the received nonce is the same as the length we sent.
>
> Ugly scapy test script running on veth0:
>
> def loop():
> pkt=sniff(iface="veth0", filter="icmp6", count=1)
> pkt = pkt[0]
> b = bytearray(pkt[Raw].load)
> b[1] += 1
> b += b'\xde\xad\xbe\xef\xde\xad\xbe\xef'
> pkt[Raw].load = bytes(b)
> pkt[IPv6].plen += 8
> # fixup checksum after modifying the payload
> pkt[IPv6].payload.cksum -= 0x3b44
> if pkt[IPv6].payload.cksum < 0:
> pkt[IPv6].payload.cksum += 0xffff
> sendp(pkt, iface="veth0")
>
> This should result in DAD failure for any address added to veth0's peer,
> but is currently ignored.
>
> Fixes: adc176c54722 ("ipv6 addrconf: Implemented enhanced DAD (RFC7527)")
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
> Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
Applied and queued up for -stable, thank you!
^ permalink raw reply
* Re: [PATCH 2/4 v1] net: dsa: Add bindings for Realtek SMI DSAs
From: Rob Herring @ 2018-07-16 20:45 UTC (permalink / raw)
To: Linus Walleij
Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, netdev,
openwrt-devel, LEDE Development List, Antti Seppälä,
Roman Yeryomin, Colin Leitner, Gabor Juhos, devicetree
In-Reply-To: <20180714094556.30791-2-linus.walleij@linaro.org>
On Sat, Jul 14, 2018 at 11:45:54AM +0200, Linus Walleij wrote:
> The Realtek SMI family is a set of DSA chips that provide
> switching in routers. This binding just follows the pattern
> set by other switches but with the introduction of an embedded
> irqchip to demux and handle the interrupts fired by the single
> line from the chip.
>
> This interrupt construction is similar to how we handle
> interrupt controllers inside PCI bridges etc.
>
> Cc: Antti Seppälä <a.seppala@gmail.com>
> Cc: Roman Yeryomin <roman@advem.lv>
> Cc: Colin Leitner <colin.leitner@googlemail.com>
> Cc: Gabor Juhos <juhosg@openwrt.org>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog RFCv2->v1:
> - No changes, we agree on these bindings.
> ChangeLog RFCv1->RFCv2:
> - Switch to Andrew's suggestion to have a local MDIO bus
> definition inside of the DSA device node
> - Add realtek,disabled-leds
> - Correct WAN IRQ to 12 in the example
> ---
> .../bindings/net/dsa/realtek-smi.txt | 153 ++++++++++++++++++
> 1 file changed, 153 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt b/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
> new file mode 100644
> index 000000000000..b6ae8541bd55
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
> @@ -0,0 +1,153 @@
> +Realtek SMI-based Switches
> +==========================
> +
> +The SMI "Simple Management Interface" is a two-wire protocol using
At least for some other Realtek chips, the documentation I find says the
S stands for Serial. And Wikipedia says SMI is the same thing as MDIO.
Just want to make sure we don't define GPIOs directly when there should
be a layer of abstraction like mdio-gpio.
> +bit-banged GPIO that while it reuses the MDIO lines MCK and MDIO does
> +not use the MDIO protocol. This binding defines how to specify the
> +SMI-based Realtek devices.
> +
> +Required properties:
> +
> +- compatible: must be exactly one of:
> + "realtek,rtl8366"
> + "realtek,rtl8366rb" (4+1 ports)
> + "realtek,rtl8366s" (4+1 ports)
> + "realtek,rtl8367"
> + "realtek,rtl8367b"
> + "realtek,rtl8368s" (8 port)
> + "realtek,rtl8369"
> + "realtek,rtl8370" (8 port)
> +
> +Required properties:
> +- mdc-gpios: GPIO line for the MDC clock line.
> +- mdio-gpios: GPIO line for the MDIO data line.
> +- reset-gpios: GPIO line for the reset signal.
> +
> +Optional properties:
> +- realtek,disable-leds: if the LED drivers are not used in the
> + hardware design this will disable them so they are not turned on
> + and wasting power.
> +
> +Required subnodes:
> +
> +- interrupt-controller
> +
> + This defines an interrupt controller with an IRQ line (typically
> + a GPIO) that will demultiplex and handle the interrupt from the single
> + interrupt line coming out of one of the SMI-based chips. It most
> + importantly provides link up/down interrupts to the PHY blocks inside
> + the ASIC.
> +
> +Required properties of interrupt-controller:
> +
> +- interrupt: parent interrupt, see interrupt-controller/interrupts.txt
> +- interrupt-controller: see interrupt-controller/interrupts.txt
> +- #address-cells: should be <0>
> +- #interrupt-cells: should be <1>
> +
> +- mdio
> +
> + This defines the internal MDIO bus of the SMI device, mostly for the
> + purpose of being able to hook the interrupts to the right PHY and
> + the right PHY to the corresponding port.
> +
> +Required properties of mdio:
> +
> +- compatible: should be set to "realtek,smi-mdio" for all SMI devices
> +
> +See net/mdio.txt for additional MDIO bus properties.
> +
> +See net/dsa/dsa.txt for a list of additional required and optional properties
> +and subnodes of DSA switches.
> +
> +Examples:
> +
> +switch {
> + compatible = "realtek,rtl8366rb";
> + /* 22 = MDIO (has input reads), 21 = MDC (clock, output only) */
> + mdc-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>;
> + mdio-gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>;
> + reset-gpios = <&gpio0 14 GPIO_ACTIVE_LOW>;
> +
> + switch_intc: interrupt-controller {
> + /* GPIO 15 provides the interrupt */
> + interrupt-parent = <&gpio0>;
> + interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <1>;
> + };
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> + port@0 {
> + reg = <0>;
> + label = "lan0";
> + phy-handle = <&phy0>;
> + };
> + port@1 {
> + reg = <1>;
> + label = "lan1";
> + phy-handle = <&phy1>;
> + };
> + port@2 {
> + reg = <2>;
> + label = "lan2";
> + phy-handle = <&phy2>;
> + };
> + port@3 {
> + reg = <3>;
> + label = "lan3";
> + phy-handle = <&phy3>;
> + };
> + port@4 {
> + reg = <4>;
> + label = "wan";
> + phy-handle = <&phy4>;
> + };
> + port@5 {
> + reg = <5>;
> + label = "cpu";
> + ethernet = <&gmac0>;
> + phy-mode = "rgmii";
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> + };
> + };
> +
> + mdio {
> + compatible = "realtek,smi-mdio", "dsa-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + phy0: phy@0 {
> + reg = <0>;
> + interrupt-parent = <&switch_intc>;
> + interrupts = <0>;
> + };
> + phy1: phy@1 {
> + reg = <1>;
> + interrupt-parent = <&switch_intc>;
> + interrupts = <1>;
> + };
> + phy2: phy@2 {
> + reg = <2>;
> + interrupt-parent = <&switch_intc>;
> + interrupts = <2>;
> + };
> + phy3: phy@3 {
> + reg = <3>;
> + interrupt-parent = <&switch_intc>;
> + interrupts = <3>;
> + };
> + phy4: phy@4 {
> + reg = <4>;
> + interrupt-parent = <&switch_intc>;
> + interrupts = <12>;
> + };
> + };
> +};
> --
> 2.17.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" 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: cavium: Drop dependency of NET_VENDOR_CAVIUM on PCI
From: David Miller @ 2018-07-16 20:44 UTC (permalink / raw)
To: alexander.sverdlin
Cc: netdev, aleksey.makarov, sgoutham, raghu.vatsavayi, vijaya.guvva
In-Reply-To: <20180713150428.1638-1-alexander.sverdlin@nokia.com>
From: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Date: Fri, 13 Jul 2018 17:04:28 +0200
> Octeon Ethernet drivers work perfectly without PCI.
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: do not return DUPLEX_UNKNOWN when link is down
From: David Miller @ 2018-07-16 20:44 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, venkatesh, leedom
In-Reply-To: <1531484815-27685-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Fri, 13 Jul 2018 17:56:55 +0530
> We were returning DUPLEX_UNKNOWN in get_link_ksettings() when
> the link was down. Unfortunately, this causes a problem when
> "ethtool -s autoneg on" is issued for a link which is down because
> the ethtool code first reads the settings and then reapplies them
> with only the changes provided on the command line. Which results
> in us diving into set_link_ksettings() with DUPLEX_UNKNOWN which is
> not DUPLEX_FULL, so set_link_ksettings() throws an -EINVAL error.
> do not return DUPLEX_UNKNOWN to fix the issue.
>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH][net-next][v2] net: convert gro_count to bitmask
From: David Miller @ 2018-07-16 20:41 UTC (permalink / raw)
To: lirongqing; +Cc: netdev, edumazet, sbrivio
In-Reply-To: <1531464096-11319-1-git-send-email-lirongqing@baidu.com>
From: Li RongQing <lirongqing@baidu.com>
Date: Fri, 13 Jul 2018 14:41:36 +0800
> gro_hash size is 192 bytes, and uses 3 cache lines, if there is few
> flows, gro_hash may be not fully used, so it is unnecessary to iterate
> all gro_hash in napi_gro_flush(), to occupy unnecessary cacheline.
>
> convert gro_count to a bitmask, and rename it as gro_bitmask, each bit
> represents a element of gro_hash, only flush a gro_hash element if the
> related bit is set, to speed up napi_gro_flush().
>
> and update gro_bitmask only if it will be changed, to reduce cache
> update
>
> Suggested-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> Cc: Stefano Brivio <sbrivio@redhat.com>
> ---
> netperf shows no difference, maybe because my testing machine has large
> cache
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: ip6_gre: get ipv6hdr after skb_cow_head()
From: David Miller @ 2018-07-16 20:40 UTC (permalink / raw)
To: bhole_prashant_q7; +Cc: kuznet, yoshfuji, u9012063, netdev
In-Reply-To: <20180713054050.5656-1-bhole_prashant_q7@lab.ntt.co.jp>
From: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
Date: Fri, 13 Jul 2018 14:40:50 +0900
> A KASAN:use-after-free bug was found related to ip6-erspan
> while running selftests/net/ip6_gre_headroom.sh
>
> It happens because of following sequence:
> - ipv6hdr pointer is obtained from skb
> - skb_cow_head() is called, skb->head memory is reallocated
> - old data is accessed using ipv6hdr pointer
>
> skb_cow_head() call was added in e41c7c68ea77 ("ip6erspan: make sure
> enough headroom at xmit."), but looking at the history there was a
> chance of similar bug because gre_handle_offloads() and pskb_trim()
> can also reallocate skb->head memory. Fixes tag points to commit
> which introduced possibility of this bug.
>
> This patch moves ipv6hdr pointer assignment after skb_cow_head() call.
>
> Fixes: 5a963eb61b7c ("ip6_gre: Add ERSPAN native tunnel support")
> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
This bug goes back to 4.16, therefore applied to 'net' and queued up
for -stable.
Please do not submit bug fixes against 'net-next' in this situation
in the future.
Thanks.
^ permalink raw reply
* Re: [PATCH net,v2] tcp: Fix broken repair socket window probe patch
From: David Miller @ 2018-07-16 21:08 UTC (permalink / raw)
To: sbaranoff; +Cc: avagin, xemul, edumazet, kuznet, yoshfuji, netdev, linux-kernel
In-Reply-To: <1531668997-1439-1-git-send-email-sbaranoff@gmail.com>
From: Stefan Baranoff <sbaranoff@gmail.com>
Date: Sun, 15 Jul 2018 11:36:37 -0400
> Correct previous bad attempt at allowing sockets to come out of TCP
> repair without sending window probes. To avoid changing size of
> the repair variable in struct tcp_sock, this lets the decision for
> sending probes or not to be made when coming out of repair by
> introducing two ways to turn it off.
>
> v2:
> * Remove erroneous comment; defines now make behavior clear
>
> Fixes: 70b7ff130224 ("tcp: allow user to create repair socket without window probes")
> Signed-off-by: Stefan Baranoff <sbaranoff@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] tun: Fix use-after-free on XDP_TX
From: David Miller @ 2018-07-16 20:39 UTC (permalink / raw)
To: makita.toshiaki; +Cc: netdev, brouer
In-Reply-To: <1531455878-2552-1-git-send-email-makita.toshiaki@lab.ntt.co.jp>
From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Date: Fri, 13 Jul 2018 13:24:38 +0900
> On XDP_TX we need to free up the frame only when tun_xdp_tx() returns a
> negative value. A positive value indicates that the packet is
> successfully enqueued to the ptr_ring, so freeing the page causes
> use-after-free.
>
> Fixes: 735fc4054b3a ("xdp: change ndo_xdp_xmit API to support bulking")
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] liquidio: Use %pad printk format for dma_addr_t values
From: David Miller @ 2018-07-16 20:37 UTC (permalink / raw)
To: deller
Cc: derek.chickles, satananda.burla, felix.manlunas, raghu.vatsavayi,
netdev, linux-parisc
In-Reply-To: <20180712203629.GA32537@ls3530.fritz.box>
From: Helge Deller <deller@gmx.de>
Date: Thu, 12 Jul 2018 22:36:29 +0200
> Use the existing %pad printk format to print dma_addr_t values.
> This avoids the following warnings when compiling on the parisc platform:
>
> warning: format '%llx' expects argument of type 'long long unsigned int', but argument 2 has type 'dma_addr_t {aka unsigned int}' [-Wformat=]
>
> Signed-off-by: Helge Deller <deller@gmx.de>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: realtek: add missing entry for RTL8211C to mdio_device_id table
From: David Miller @ 2018-07-16 20:36 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <8308f8ec-364d-736d-72e5-b0678cf4d6e4@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Thu, 12 Jul 2018 21:45:08 +0200
> Add missing entry for RTL8211C to mdio_device_id table.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> Fixes: cf87915cb9f8 ("net: phy: realtek: add support for RTL8211C")
Applied.
^ 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