* [patch net-next 0/7] mlxsw: Add support for partial multicast route offload
From: Jiri Pirko @ 2017-09-28 17:34 UTC (permalink / raw)
To: netdev
Cc: davem, yotamg, idosch, mlxsw, nikolay, andrew, dsa, edumazet,
willemb, johannes.berg, dcaratti, pabeni, daniel, f.fainelli, fw,
gfree.wind
From: Jiri Pirko <jiri@mellanox.com>
Yotam says:
Previous patchset introduced support for offloading multicast MFC routes to
the Spectrum hardware. As described in that patchset, no partial offloading
is supported, i.e if a route has one output interface which is not a valid
offloadable device (e.g. pimreg device, dummy device, management NIC), the
route is trapped to the CPU and the forwarding is done in slow-path.
Add support for partial offloading of multicast routes, by letting the
hardware to forward the packet to all the in-hardware devices, while the
kernel ipmr module will continue forwarding to all other interfaces.
Similarly to the bridge, the kernel ipmr module will forward a marked
packet to an interface only if the interface has a different parent ID than
the packet's ingress interfaces.
The first patch introduces the offload_mr_fwd_mark skb field, which can be
used by offloading drivers to indicate that a packet had already gone
through multicast forwarding in hardware, similarly to the offload_fwd_mark
field that indicates that a packet had already gone through L2 forwarding
in hardware.
Patches 2 and 3 change the ipmr module to not forward packets that had
already been forwarded by the hardware, i.e. packets that are marked with
offload_mr_fwd_mark and the ingress VIF shares the same parent ID with the
egress VIF.
Patches 4, 5, 6 and 7 add the support in the mlxsw Spectrum driver for trap
and forward routes, while marking the trapped packets with the
offload_mr_fwd_mark.
Yotam Gigi (7):
skbuff: Add the offload_mr_fwd_mark field
ipv4: ipmr: Add the parent ID field to VIF struct
ipv4: ipmr: Don't forward packets already forwarded by hardware
mlxsw: acl: Introduce ACL trap and forward action
mlxsw: spectrum: Add trap for multicast trap-and-forward routes
mlxsw: spectrum: mr_tcam: Add trap-and-forward multicast route
mlxsw: spectrum: mr: Support trap-and-forward routes
.../mellanox/mlxsw/core_acl_flex_actions.c | 17 ++++++++
.../mellanox/mlxsw/core_acl_flex_actions.h | 2 +
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 13 ++++++
drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c | 17 ++++----
drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.h | 1 +
.../net/ethernet/mellanox/mlxsw/spectrum_mr_tcam.c | 8 ++++
drivers/net/ethernet/mellanox/mlxsw/trap.h | 2 +
include/linux/mroute.h | 2 +
include/linux/skbuff.h | 1 +
net/ipv4/ipmr.c | 46 +++++++++++++++++++---
10 files changed, 95 insertions(+), 14 deletions(-)
--
2.9.5
^ permalink raw reply
* [iproute PATCH] ip-route: Fix for listing routes with RTAX_LOCK attribute
From: Phil Sutter @ 2017-09-28 17:33 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Thomas Haller, Hangbin Liu
This fixes a corner-case for routes with a certain metric locked to
zero:
| ip route add 192.168.7.0/24 dev eth0 window 0
| ip route add 192.168.7.0/24 dev eth0 window lock 0
Since the kernel doesn't dump the attribute if it is zero, both routes
added above would appear as if they were equal although they are not.
Fix this by taking mxlock value for the given metric into account before
skipping it if it is not present.
Reported-by: Thomas Haller <thaller@redhat.com>
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
ip/iproute.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ip/iproute.c b/ip/iproute.c
index a8733f45bf881..e81bc05ec16cb 100644
--- a/ip/iproute.c
+++ b/ip/iproute.c
@@ -574,10 +574,10 @@ int print_route(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
for (i = 2; i <= RTAX_MAX; i++) {
__u32 val = 0U;
- if (mxrta[i] == NULL)
+ if (mxrta[i] == NULL && !(mxlock & (1 << i)))
continue;
- if (i != RTAX_CC_ALGO)
+ if (mxrta[i] != NULL && i != RTAX_CC_ALGO)
val = rta_getattr_u32(mxrta[i]);
if (i == RTAX_HOPLIMIT && (int)val == -1)
--
2.13.1
^ permalink raw reply related
* Re: [PATCH net-next] libbpf: use map_flags when creating maps
From: Craig Gallek @ 2017-09-28 17:33 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, David S . Miller, Chonggang Li, netdev
In-Reply-To: <59CC201C.6090502@iogearbox.net>
On Wed, Sep 27, 2017 at 6:03 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 09/27/2017 06:29 PM, Alexei Starovoitov wrote:
>>
>> On 9/27/17 7:04 AM, Craig Gallek wrote:
>>>
>>> From: Craig Gallek <kraig@google.com>
>>>
>>> This extends struct bpf_map_def to include a flags field. Note that
>>> this has the potential to break the validation logic in
>>> bpf_object__validate_maps and bpf_object__init_maps as they use
>>> sizeof(struct bpf_map_def) as a minimal allowable size of a map section.
>>> Any bpf program compiled with a smaller struct bpf_map_def will fail this
>>> check.
>>>
>>> I don't believe this will be an issue in practice as both compile-time
>>> definitions of struct bpf_map_def (in samples/bpf/bpf_load.h and
>>> tools/testing/selftests/bpf/bpf_helpers.h) have always been larger
>>> than this newly updated version in libbpf.h.
>>>
>>> Signed-off-by: Craig Gallek <kraig@google.com>
>>> ---
>>> tools/lib/bpf/libbpf.c | 2 +-
>>> tools/lib/bpf/libbpf.h | 1 +
>>> 2 files changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
>>> index 35f6dfcdc565..6bea85f260a3 100644
>>> --- a/tools/lib/bpf/libbpf.c
>>> +++ b/tools/lib/bpf/libbpf.c
>>> @@ -874,7 +874,7 @@ bpf_object__create_maps(struct bpf_object *obj)
>>> def->key_size,
>>> def->value_size,
>>> def->max_entries,
>>> - 0);
>>> + def->map_flags);
>>> if (*pfd < 0) {
>>> size_t j;
>>> int err = *pfd;
>>> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
>>> index 7959086eb9c9..6e20003109e0 100644
>>> --- a/tools/lib/bpf/libbpf.h
>>> +++ b/tools/lib/bpf/libbpf.h
>>> @@ -207,6 +207,7 @@ struct bpf_map_def {
>>> unsigned int key_size;
>>> unsigned int value_size;
>>> unsigned int max_entries;
>>> + unsigned int map_flags;
>>> };
>>
>>
>> yes it will break loading of pre-compiled .o
>> Instead of breaking, let's fix the loader to do it the way
>> samples/bpf/bpf_load.c does.
>> See commit 156450d9d964 ("samples/bpf: make bpf_load.c code compatible
>> with ELF maps section changes")
>
>
> +1, iproute2 loader also does map spec fixup
>
> For libbpf it would be good also such that it reduces the diff
> further between the libbpf and bpf_load so that it allows move
> to libbpf for samples in future.
Fair enough, I'll try to get this to work more dynamically. I did
noticed that the fields of struct bpf_map_def in
selftests/.../bpf_helpers.h and iproute2's struct bpf_elf_map have
diverged. The flags field is the only thing missing from libbpf right
now (and they are at the same offset for both), so it won't be an
issue for this change, but it is going to make unifying all of these
things under libbpf not trivial at some point...
^ permalink raw reply
* Re: [PATCH] arp: make arp_hdr_len() return unsigned int
From: David Miller @ 2017-09-28 17:29 UTC (permalink / raw)
To: adobriyan; +Cc: netdev
In-Reply-To: <20170926201228.GA31899@avx2>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Tue, 26 Sep 2017 23:12:28 +0300
> Negative ARP header length are not a thing.
>
> Constify arguments while I'm at it.
>
> Space savings:
>
> add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-3 (-3)
> function old new delta
> arpt_do_table 1163 1160 -3
>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net v2] net: dsa: mv88e6xxx: lock mutex when freeing IRQs
From: David Miller @ 2017-09-28 17:29 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, linux-kernel, kernel, f.fainelli, andrew
In-Reply-To: <20170926185721.12187-1-vivien.didelot@savoirfairelinux.com>
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date: Tue, 26 Sep 2017 14:57:21 -0400
> mv88e6xxx_g2_irq_free locks the registers mutex, but not
> mv88e6xxx_g1_irq_free, which results in a stack trace from
> assert_reg_lock when unloading the mv88e6xxx module. Fix this.
>
> Fixes: 3460a5770ce9 ("net: dsa: mv88e6xxx: Mask g1 interrupts and free interrupt")
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next] net-next/hinic: Fix a case of Tx Queue is Stopped forever
From: David Miller @ 2017-09-28 17:27 UTC (permalink / raw)
To: aviad.krawczyk; +Cc: linux-kernel, netdev
In-Reply-To: <1506449493-83395-1-git-send-email-aviad.krawczyk@huawei.com>
From: Aviad Krawczyk <aviad.krawczyk@huawei.com>
Date: Wed, 27 Sep 2017 02:11:33 +0800
> Fix the following scenario:
> 1. tx_free_poll is running on cpu X
> 2. xmit function is running on cpu Y and fails to get sq wqe
> 3. tx_free_poll frees wqes on cpu X and checks the queue is not stopped
> 4. xmit function stops the queue after failed to get sq wqe
> 5. The queue is stopped forever
>
> Signed-off-by: Aviad Krawczyk <aviad.krawczyk@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net-next/hinic: Set Rxq irq to specific cpu for NUMA
From: David Miller @ 2017-09-28 17:27 UTC (permalink / raw)
To: aviad.krawczyk; +Cc: linux-kernel, netdev
In-Reply-To: <1506448670-51213-1-git-send-email-aviad.krawczyk@huawei.com>
From: Aviad Krawczyk <aviad.krawczyk@huawei.com>
Date: Wed, 27 Sep 2017 01:57:50 +0800
> Set Rxq irq to specific cpu for allocating and receiving the skb from
> the same node.
>
> Signed-off-by: Aviad Krawczyk <aviad.krawczyk@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next RFC 5/9] net: dsa: forward hardware timestamping ioctls to switch driver
From: Florian Fainelli @ 2017-09-28 17:25 UTC (permalink / raw)
To: Brandon Streiff, netdev
Cc: linux-kernel, David S. Miller, Andrew Lunn, Vivien Didelot,
Richard Cochran, Erik Hons
In-Reply-To: <1506612341-18061-6-git-send-email-brandon.streiff@ni.com>
On 09/28/2017 08:25 AM, Brandon Streiff wrote:
> This patch adds support to the dsa slave network device so that
> switch drivers can implement the SIOC[GS]HWTSTAMP ioctls and the
> ethtool timestamp-info interface.
>
> Signed-off-by: Brandon Streiff <brandon.streiff@ni.com>
> ---
> struct dsa_switch_driver {
> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
> index bf8800d..2cf6a83 100644
> --- a/net/dsa/slave.c
> +++ b/net/dsa/slave.c
> @@ -264,10 +264,34 @@ dsa_slave_fdb_dump(struct sk_buff *skb, struct netlink_callback *cb,
>
> static int dsa_slave_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
> {
> + struct dsa_slave_priv *p = netdev_priv(dev);
> + struct dsa_switch *ds = p->dp->ds;
> + int port = p->dp->index;
> +
> if (!dev->phydev)
> return -ENODEV;
>
> - return phy_mii_ioctl(dev->phydev, ifr, cmd);
> + switch (cmd) {
> + case SIOCGMIIPHY:
> + case SIOCGMIIREG:
> + case SIOCSMIIREG:
> + if (dev->phydev)
> + return phy_mii_ioctl(dev->phydev, ifr, cmd);
> + else
> + return -EOPNOTSUPP;
> + case SIOCGHWTSTAMP:
> + if (ds->ops->port_hwtstamp_get)
> + return ds->ops->port_hwtstamp_get(ds, port, ifr);
> + else
> + return -EOPNOTSUPP;
> + case SIOCSHWTSTAMP:
> + if (ds->ops->port_hwtstamp_set)
> + return ds->ops->port_hwtstamp_set(ds, port, ifr);
> + else
> + return -EOPNOTSUPP;
> + default:
> + return -EOPNOTSUPP;
> + }
This echoes back to Andrew's comments in patch 2, but we may have to
prefer PHY timestamping over MAC timestamping if both are available?
Richard, is that usually how the preference should be made?
--
Florian
^ permalink raw reply
* Re: [PATCH net] packet: only test po->has_vnet_hdr once in packet_snd
From: David Miller @ 2017-09-28 17:25 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: netdev, willemb
In-Reply-To: <20170926162017.60750-1-willemdebruijn.kernel@gmail.com>
aFrom: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Tue, 26 Sep 2017 12:20:17 -0400
> From: Willem de Bruijn <willemb@google.com>
>
> Packet socket option po->has_vnet_hdr can be updated concurrently with
> other operations if no ring is attached.
>
> Do not test the option twice in packet_snd, as the value may change in
> between calls. A race on setsockopt disable may cause a packet > mtu
> to be sent without having GSO options set.
>
> Fixes: bfd5f4a3d605 ("packet: Add GSO/csum offload support.")
> Signed-off-by: Willem de Bruijn <willemb@google.com>
> Reviewed-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] packet: in packet_do_bind, test fanout with bind_lock held
From: David Miller @ 2017-09-28 17:25 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: netdev, willemb
In-Reply-To: <20170926161937.60597-1-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Tue, 26 Sep 2017 12:19:37 -0400
> From: Willem de Bruijn <willemb@google.com>
>
> Once a socket has po->fanout set, it remains a member of the group
> until it is destroyed. The prot_hook must be constant and identical
> across sockets in the group.
>
> If fanout_add races with packet_do_bind between the test of po->fanout
> and taking the lock, the bind call may make type or dev inconsistent
> with that of the fanout group.
>
> Hold po->bind_lock when testing po->fanout to avoid this race.
>
> I had to introduce artificial delay (local_bh_enable) to actually
> observe the race.
>
> Fixes: dc99f600698d ("packet: Add fanout support.")
> Signed-off-by: Willem de Bruijn <willemb@google.com>
> Reviewed-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/2] bpf/verifier: disassembly improvements
From: David Miller @ 2017-09-28 17:24 UTC (permalink / raw)
To: ecree; +Cc: netdev, daniel, alexei.starovoitov, ys114321
In-Reply-To: <52270348-67f1-4e7a-cd2f-9d611ae94064@solarflare.com>
From: Edward Cree <ecree@solarflare.com>
Date: Tue, 26 Sep 2017 16:32:15 +0100
> Fix the output of print_bpf_insn() for ALU ops that don't look like
> compound assignment (i.e. BPF_END and BPF_NEG).
>
> Sample output for a short test program:
> 0: (b4) (u32) r0 = (u32) 0
> 1: (dc) r0 = be32 r0
> 2: (84) r0 = (u32) -r0
> 3: (95) exit
> processed 4 insns, stack depth 0
Series applied.
^ permalink raw reply
* Re: [PATCH 2/4] ravb: Add optional PHY reset during system resume
From: Florian Fainelli @ 2017-09-28 17:22 UTC (permalink / raw)
To: Geert Uytterhoeven, David S . Miller, Simon Horman, Magnus Damm
Cc: Sergei Shtylyov, Andrew Lunn, Niklas Söderlund, netdev,
linux-renesas-soc, devicetree
In-Reply-To: <1506614014-4398-3-git-send-email-geert+renesas@glider.be>
On 09/28/2017 08:53 AM, Geert Uytterhoeven wrote:
> If the optional "reset-gpios" property is specified in DT, the generic
> MDIO bus code takes care of resetting the PHY during device probe.
> However, the PHY may still have to be reset explicitly after system
> resume.
>
> This allows to restore Ethernet operation after resume from s2ram on
> Salvator-XS, where the enable pin of the regulator providing PHY power
> is connected to PRESETn, and PSCI suspend powers down the SoC.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> drivers/net/ethernet/renesas/ravb_main.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
> index fdf30bfa403bf416..96d1d48e302f8c9a 100644
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
> @@ -19,6 +19,7 @@
> #include <linux/etherdevice.h>
> #include <linux/ethtool.h>
> #include <linux/if_vlan.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/kernel.h>
> #include <linux/list.h>
> #include <linux/module.h>
> @@ -2268,6 +2269,7 @@ static int __maybe_unused ravb_resume(struct device *dev)
> {
> struct net_device *ndev = dev_get_drvdata(dev);
> struct ravb_private *priv = netdev_priv(ndev);
> + struct mii_bus *bus = priv->mii_bus;
> int ret = 0;
>
> if (priv->wol_enabled) {
> @@ -2302,6 +2304,13 @@ static int __maybe_unused ravb_resume(struct device *dev)
> * reopen device if it was running before system suspended.
> */
>
> + /* PHY reset */
> + if (bus->reset_gpiod) {
> + gpiod_set_value_cansleep(bus->reset_gpiod, 1);
> + udelay(bus->reset_delay_us);
> + gpiod_set_value_cansleep(bus->reset_gpiod, 0);
> + }
This is a clever hack, but unfortunately this is also misusing the MDIO
bus reset line into a PHY reset line. As commented in patch 3, if this
reset line is tied to the PHY, then this should be a PHY property and
you cannot (ab)use the MDIO bus GPIO reset logic anymore...
Should not you also try to manage this reset line during ravb_open() to
achiever better power savings?
--
Florian
^ permalink raw reply
* Re: [PATCH][next] cxgb4: make function ch_flower_stats_cb, fixes warning
From: David Miller @ 2017-09-28 17:22 UTC (permalink / raw)
To: colin.king; +Cc: ganeshgr, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20170926151409.18244-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Tue, 26 Sep 2017 16:14:09 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> The function ch_flower_stats_cb is local to the source and does not need
> to be in global scope, so make it static.
>
> Cleans up sparse warnings:
> symbol 'ch_flower_stats_cb' was not declared. Should it be static?
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v4 0/4] rtnetlink: preparation patches for further rtnl lock pushdown/removal
From: David Miller @ 2017-09-28 17:21 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <20170926115843.12013-1-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Tue, 26 Sep 2017 13:58:39 +0200
> Patches split large rtnl_fill_ifinfo into smaller chunks
> to better see which parts
>
> 1. require rtnl
> 2. do not require it at all
> 3. rely on rtnl locking now but could be converted
>
> Changes since v3:
>
> I dropped the 'ifalias' patch, I have a change to decouple ifalias and
> rtnl mutex, I will send it once this series has been merged.
Series applied.
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: renesas: salvator-common: Add EthernetAVB PHY reset
From: Florian Fainelli @ 2017-09-28 17:20 UTC (permalink / raw)
To: Geert Uytterhoeven, David S . Miller, Simon Horman, Magnus Damm
Cc: Sergei Shtylyov, Andrew Lunn, Niklas Söderlund,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1506614014-4398-4-git-send-email-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
On 09/28/2017 08:53 AM, Geert Uytterhoeven wrote:
> Describe the GPIO used to reset the Ethernet PHY for EthernetAVB.
> This allows the driver to reset the PHY during probe and after system
> resume.
>
> This fixes Ethernet operation after resume from s2ram on Salvator-XS,
> where the enable pin of the regulator providing PHY power is connected
> to PRESETn, and PSCI powers down the SoC during system suspend.
>
> On Salvator-X, the enable pin is always pulled high, but the driver may
> still need to reset the PHY if this wasn't done by the bootloader
> before.
>
> Inspired by patches in the BSP for the individual Salvator-X/XS boards
> by Kazuya Mizuguchi.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
> ---
> For proper PHY reset operation during system resume, this depends on
> "ravb: Add missing PHY reset during system resume".
> However, this patch can be applied independently.
> ---
> arch/arm64/boot/dts/renesas/salvator-common.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> index ed4a8dfead3c2e58..db00e7c484f76eac 100644
> --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> @@ -296,6 +296,7 @@
> pinctrl-names = "default";
> renesas,no-ether-link;
> phy-handle = <&phy0>;
> + reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
> status = "okay";
>
> phy0: ethernet-phy@0 {
This should be a PHY node property, unless this GPIO pin really is
global to the MDIO bus itself.
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: stmmac: dwmac4: Re-enable MAC Rx before powering down
From: David Miller @ 2017-09-28 17:19 UTC (permalink / raw)
To: ed.blake; +Cc: peppe.cavallaro, alexandre.torgue, netdev
In-Reply-To: <1506422693-26144-1-git-send-email-ed.blake@sondrel.com>
From: Ed Blake <ed.blake@sondrel.com>
Date: Tue, 26 Sep 2017 11:44:53 +0100
> Re-enable the MAC receiver by setting CONFIG_RE before powering down,
> as instructed in section 6.3.5.1 of [1]. Without this the MAC fails
> to receive WoL packets and never wakes up.
>
> [1] DWC Ethernet QoS Databook 4.10a October 2014
>
> Signed-off-by: Ed Blake <ed.blake@sondrel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: stmmac: dwc-qos: Add suspend / resume support
From: David Miller @ 2017-09-28 17:19 UTC (permalink / raw)
To: ed.blake; +Cc: peppe.cavallaro, alexandre.torgue, netdev
In-Reply-To: <1506422626-26058-1-git-send-email-ed.blake@sondrel.com>
From: Ed Blake <ed.blake@sondrel.com>
Date: Tue, 26 Sep 2017 11:43:46 +0100
> Add hook to stmmac_pltfr_pm_ops for suspend / resume handling.
>
> Signed-off-by: Ed Blake <ed.blake@sondrel.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v4] selftests: rtnetlink.sh: add rudimentary vrf test
From: David Miller @ 2017-09-28 17:14 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <20170926054042.2750-1-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Tue, 26 Sep 2017 07:40:42 +0200
> Acked-by: David Ahern <dsahern@gmail.com>
> Signed-off-by: Florian Westphal <fw@strlen.de>
> ---
> Changes since v1: indent all lines with tabs, not spaces
>
> detaching this from the series, I want to avoid needless v5.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] net: dsa: Fix network device registration order
From: David Miller @ 2017-09-28 17:13 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, linux-kernel
In-Reply-To: <20170925225553.566-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 25 Sep 2017 15:55:53 -0700
> We cannot be registering the network device first, then setting its
> carrier off and finally connecting it to a PHY, doing that leaves a
> window during which the carrier is at best inconsistent, and at worse
> the device is not usable without a down/up sequence since the network
> device is visible to user space with possibly no PHY device attached.
>
> Re-order steps so that they make logical sense. This fixes some devices
> where the port was not usable after e.g: an unbind then bind of the
> driver.
>
> Fixes: 0071f56e46da ("dsa: Register netdev before phy")
> Fixes: 91da11f870f0 ("net: Distributed Switch Architecture protocol support")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next RFC 2/9] net: dsa: mv88e6xxx: expose switch time as a PTP hardware clock
From: Andrew Lunn @ 2017-09-28 17:03 UTC (permalink / raw)
To: Brandon Streiff
Cc: netdev, linux-kernel, David S. Miller, Florian Fainelli,
Vivien Didelot, Richard Cochran, Erik Hons
In-Reply-To: <1506612341-18061-3-git-send-email-brandon.streiff@ni.com>
> +/* The 32-bit timestamp counter overflows every ~34.3 seconds; this task
> + * forces periodic reads so that we don't miss any wraparounds.
> + */
> +#define MV88E6XXX_TAI_OVERFLOW_PERIOD (34 * HZ / 2)
> +static void mv88e6xxx_ptp_overflow_check(struct work_struct *work)
> +{
> + struct delayed_work *dw = to_delayed_work(work);
> + struct mv88e6xxx_chip *chip =
> + container_of(dw, struct mv88e6xxx_chip, overflow_work);
> + bool timeout = time_is_before_jiffies(chip->last_overflow_check +
> + MV88E6XXX_TAI_OVERFLOW_PERIOD);
> +
> + if (timeout) {
Why do you need this timeout? Do you think the kernel will call this
more often than required?
Also, if it did call this function early, you skip the read, and
reschedule. There is then a danger the next read is after the
wraparound.....
> + mutex_lock(&chip->reg_lock);
> + timecounter_read(&chip->tstamp_tc);
> + chip->last_overflow_check = jiffies;
> + mutex_unlock(&chip->reg_lock);
> + }
> +
> + schedule_delayed_work(&chip->overflow_work,
> + MV88E6XXX_TAI_OVERFLOW_PERIOD);
> +}
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH net-next RFC 2/9] net: dsa: mv88e6xxx: expose switch time as a PTP hardware clock
From: Andrew Lunn @ 2017-09-28 16:56 UTC (permalink / raw)
To: Brandon Streiff
Cc: netdev, linux-kernel, David S. Miller, Florian Fainelli,
Vivien Didelot, Richard Cochran, Erik Hons
In-Reply-To: <1506612341-18061-3-git-send-email-brandon.streiff@ni.com>
On Thu, Sep 28, 2017 at 10:25:34AM -0500, Brandon Streiff wrote:
> This patch adds basic support for exposing the 32-bit timestamp counter
> inside the mv88e6xxx switch code as a ptp_clock.
>
> Signed-off-by: Brandon Streiff <brandon.streiff@ni.com>
> ---
> drivers/net/dsa/mv88e6xxx/Kconfig | 10 +++
> drivers/net/dsa/mv88e6xxx/Makefile | 1 +
> drivers/net/dsa/mv88e6xxx/chip.c | 20 +++++
> drivers/net/dsa/mv88e6xxx/chip.h | 16 ++++
> drivers/net/dsa/mv88e6xxx/ptp.c | 180 +++++++++++++++++++++++++++++++++++++
> drivers/net/dsa/mv88e6xxx/ptp.h | 83 +++++++++++++++++
> 6 files changed, 310 insertions(+)
> create mode 100644 drivers/net/dsa/mv88e6xxx/ptp.c
> create mode 100644 drivers/net/dsa/mv88e6xxx/ptp.h
>
> diff --git a/drivers/net/dsa/mv88e6xxx/Kconfig b/drivers/net/dsa/mv88e6xxx/Kconfig
> index 1aaa7a9..ae9e7f7 100644
> --- a/drivers/net/dsa/mv88e6xxx/Kconfig
> +++ b/drivers/net/dsa/mv88e6xxx/Kconfig
> @@ -18,3 +18,13 @@ config NET_DSA_MV88E6XXX_GLOBAL2
>
> It is required on most chips. If the chip you compile the support for
> doesn't have such registers set, say N here. In doubt, say Y.
> +
> +config NET_DSA_MV88E6XXX_PTP
> + bool "PTP support for Marvell 88E6xxx"
> + default n
> + depends on NET_DSA_MV88E6XXX_GLOBAL2
> + imply NETWORK_PHY_TIMESTAMPING
Hi Brandon
Cool to see this code.
One probably dumb question so far..
It is the MAC which is doing the time stamping, not they PHY?
So why NETWORK_PHY_TIMESTAMPING?
Andrew
^ permalink raw reply
* Re: [patch net] net: dsa: mv88e6xxx: Allow dsa and cpu ports in multiple vlans
From: David Miller @ 2017-09-28 16:45 UTC (permalink / raw)
To: andrew; +Cc: vivien.didelot, netdev
In-Reply-To: <1506375140-2853-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Mon, 25 Sep 2017 23:32:20 +0200
> Ports with the same VLAN must all be in the same bridge. However the
> CPU and DSA ports need to be in multiple VLANs spread over multiple
> bridges. So exclude them when performing this test.
>
> Fixes: b2f81d304cee ("net: dsa: add CPU and DSA ports as VLAN members")
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [Patch net-next v2] net_sched: use idr to allocate u32 filter handles
From: David Miller @ 2017-09-28 16:44 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, chrism, jhs
In-Reply-To: <20170925171351.4956-3-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Mon, 25 Sep 2017 10:13:51 -0700
> Instead of calling u32_lookup_ht() in a loop to find
> a unused handle, just switch to idr API to allocate
> new handles. u32 filters are special as the handle
> could contain a hash table id and a key id, so we
> need two IDR to allocate each of them.
>
> Cc: Chris Mi <chrism@mellanox.com>
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied.
^ permalink raw reply
* Re: [Patch net-next v2] net_sched: use idr to allocate basic filter handles
From: David Miller @ 2017-09-28 16:44 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, chrism, jhs
In-Reply-To: <20170925171351.4956-2-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Mon, 25 Sep 2017 10:13:50 -0700
> Instead of calling basic_get() in a loop to find
> a unused handle, just switch to idr API to allocate
> new handles.
>
> Cc: Chris Mi <chrism@mellanox.com>
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied.
^ permalink raw reply
* Re: [Patch net-next v2] net_sched: use idr to allocate bpf filter handles
From: David Miller @ 2017-09-28 16:44 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, daniel, chrism, jhs
In-Reply-To: <20170925171351.4956-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Mon, 25 Sep 2017 10:13:49 -0700
> Instead of calling cls_bpf_get() in a loop to find
> a unused handle, just switch to idr API to allocate
> new handles.
>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Chris Mi <chrism@mellanox.com>
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
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