* [PATCH iproute2-next] ip: bond: add peer notification delay support
From: Vincent Bernat @ 2019-07-07 17:51 UTC (permalink / raw)
To: Stephen Hemminger, netdev; +Cc: Vincent Bernat
In-Reply-To: <20190707094141.1b98f3f4@hermes.lan>
Ability to tweak the delay between gratuitous ND/ARP packets has been
added in kernel commit 07a4ddec3ce9 ("bonding: add an option to
specify a delay between peer notifications"), through
IFLA_BOND_PEER_NOTIF_DELAY attribute. Add support to set and show this
value.
Example:
$ ip -d link set bond0 type bond peer_notify_delay 1000
$ ip -d link l dev bond0
2: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP mode DEFAULT group default qlen 1000
link/ether 50:54:33:00:00:01 brd ff:ff:ff:ff:ff:ff
bond mode active-backup active_slave eth0 miimon 100 updelay 0
downdelay 0 peer_notify_delay 1000 use_carrier 1 arp_interval 0
arp_validate none arp_all_targets any primary eth0
primary_reselect always fail_over_mac active xmit_hash_policy
layer2 resend_igmp 1 num_grat_arp 5 all_slaves_active 0 min_links
0 lp_interval 1 packets_per_slave 1 lacp_rate slow ad_select
stable tlb_dynamic_lb 1 addrgenmode eu
Signed-off-by: Vincent Bernat <vincent@bernat.ch>
---
include/uapi/linux/if_link.h | 1 +
ip/iplink_bond.c | 14 +++++++++++++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index b59554dd55cb..d36919fb4024 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -634,6 +634,7 @@ enum {
IFLA_BOND_AD_USER_PORT_KEY,
IFLA_BOND_AD_ACTOR_SYSTEM,
IFLA_BOND_TLB_DYNAMIC_LB,
+ IFLA_BOND_PEER_NOTIF_DELAY,
__IFLA_BOND_MAX,
};
diff --git a/ip/iplink_bond.c b/ip/iplink_bond.c
index c60f0e8ad0a0..585b6be14c81 100644
--- a/ip/iplink_bond.c
+++ b/ip/iplink_bond.c
@@ -120,6 +120,7 @@ static void print_explain(FILE *f)
"Usage: ... bond [ mode BONDMODE ] [ active_slave SLAVE_DEV ]\n"
" [ clear_active_slave ] [ miimon MIIMON ]\n"
" [ updelay UPDELAY ] [ downdelay DOWNDELAY ]\n"
+ " [ peer_notify_delay DELAY ]\n"
" [ use_carrier USE_CARRIER ]\n"
" [ arp_interval ARP_INTERVAL ]\n"
" [ arp_validate ARP_VALIDATE ]\n"
@@ -165,7 +166,7 @@ static int bond_parse_opt(struct link_util *lu, int argc, char **argv,
__u8 xmit_hash_policy, num_peer_notif, all_slaves_active;
__u8 lacp_rate, ad_select, tlb_dynamic_lb;
__u16 ad_user_port_key, ad_actor_sys_prio;
- __u32 miimon, updelay, downdelay, arp_interval, arp_validate;
+ __u32 miimon, updelay, downdelay, peer_notify_delay, arp_interval, arp_validate;
__u32 arp_all_targets, resend_igmp, min_links, lp_interval;
__u32 packets_per_slave;
unsigned int ifindex;
@@ -200,6 +201,11 @@ static int bond_parse_opt(struct link_util *lu, int argc, char **argv,
if (get_u32(&downdelay, *argv, 0))
invarg("invalid downdelay", *argv);
addattr32(n, 1024, IFLA_BOND_DOWNDELAY, downdelay);
+ } else if (matches(*argv, "peer_notify_delay") == 0) {
+ NEXT_ARG();
+ if (get_u32(&peer_notify_delay, *argv, 0))
+ invarg("invalid peer_notify_delay", *argv);
+ addattr32(n, 1024, IFLA_BOND_PEER_NOTIF_DELAY, peer_notify_delay);
} else if (matches(*argv, "use_carrier") == 0) {
NEXT_ARG();
if (get_u8(&use_carrier, *argv, 0))
@@ -410,6 +416,12 @@ static void bond_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
"downdelay %u ",
rta_getattr_u32(tb[IFLA_BOND_DOWNDELAY]));
+ if (tb[IFLA_BOND_PEER_NOTIF_DELAY])
+ print_uint(PRINT_ANY,
+ "peer_notify_delay",
+ "peer_notify_delay %u ",
+ rta_getattr_u32(tb[IFLA_BOND_PEER_NOTIF_DELAY]));
+
if (tb[IFLA_BOND_USE_CARRIER])
print_uint(PRINT_ANY,
"use_carrier",
--
2.20.1
^ permalink raw reply related
* Re: [PATCH iproute2-next] ip: bond: add peer notification delay support
From: Stephen Hemminger @ 2019-07-07 18:40 UTC (permalink / raw)
To: Vincent Bernat; +Cc: netdev
In-Reply-To: <20190707175115.3704-1-vincent@bernat.ch>
On Sun, 7 Jul 2019 19:51:15 +0200
Vincent Bernat <vincent@bernat.ch> wrote:
> Ability to tweak the delay between gratuitous ND/ARP packets has been
> added in kernel commit 07a4ddec3ce9 ("bonding: add an option to
> specify a delay between peer notifications"), through
> IFLA_BOND_PEER_NOTIF_DELAY attribute. Add support to set and show this
> value.
>
> Example:
>
> $ ip -d link set bond0 type bond peer_notify_delay 1000
> $ ip -d link l dev bond0
> 2: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
> state UP mode DEFAULT group default qlen 1000
> link/ether 50:54:33:00:00:01 brd ff:ff:ff:ff:ff:ff
> bond mode active-backup active_slave eth0 miimon 100 updelay 0
> downdelay 0 peer_notify_delay 1000 use_carrier 1 arp_interval 0
> arp_validate none arp_all_targets any primary eth0
> primary_reselect always fail_over_mac active xmit_hash_policy
> layer2 resend_igmp 1 num_grat_arp 5 all_slaves_active 0 min_links
> 0 lp_interval 1 packets_per_slave 1 lacp_rate slow ad_select
> stable tlb_dynamic_lb 1 addrgenmode eu
>
> Signed-off-by: Vincent Bernat <vincent@bernat.ch>
Looks good. I notice that all these flags don't show up in any man page.
Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
^ permalink raw reply
* Re: [PATCH net-next 00/11] Add drop monitor for offloaded data paths
From: David Miller @ 2019-07-07 19:45 UTC (permalink / raw)
To: idosch
Cc: netdev, jiri, mlxsw, dsahern, roopa, nikolay, andy, pablo,
jakub.kicinski, pieter.jansenvanvuuren, andrew, f.fainelli,
vivien.didelot, idosch
In-Reply-To: <20190707075828.3315-1-idosch@idosch.org>
From: Ido Schimmel <idosch@idosch.org>
Date: Sun, 7 Jul 2019 10:58:17 +0300
> Users have several ways to debug the kernel and understand why a packet
> was dropped. For example, using "drop monitor" and "perf". Both
> utilities trace kfree_skb(), which is the function called when a packet
> is freed as part of a failure. The information provided by these tools
> is invaluable when trying to understand the cause of a packet loss.
>
> In recent years, large portions of the kernel data path were offloaded
> to capable devices. Today, it is possible to perform L2 and L3
> forwarding in hardware, as well as tunneling (IP-in-IP and VXLAN).
> Different TC classifiers and actions are also offloaded to capable
> devices, at both ingress and egress.
>
> However, when the data path is offloaded it is not possible to achieve
> the same level of introspection as tools such "perf" and "drop monitor"
> become irrelevant.
>
> This patchset aims to solve this by allowing users to monitor packets
> that the underlying device decided to drop along with relevant metadata
> such as the drop reason and ingress port.
We are now going to have 5 or so ways to capture packets passing through
the system, this is nonsense.
AF_PACKET, kfree_skb drop monitor, perf, XDP perf events, and now this
devlink thing.
This is insanity, too many ways to do the same thing and therefore the
worst possible user experience.
Pick _ONE_ method to trap packets and forward normal kfree_skb events,
XDP perf events, and these taps there too.
I mean really, think about it from the average user's perspective. To
see all drops/pkts I have to attach a kfree_skb tracepoint, and not just
listen on devlink but configure a special tap thing beforehand and then
if someone is using XDP I gotta setup another perf event buffer capture
thing too.
Sorry, this isn't where we are going.
^ permalink raw reply
* Re: [PATCH net-next v4 1/4] devlink: Refactor physical port attributes
From: Jiri Pirko @ 2019-07-07 19:47 UTC (permalink / raw)
To: Parav Pandit; +Cc: netdev, jiri, saeedm, jakub.kicinski
In-Reply-To: <20190706182350.11929-2-parav@mellanox.com>
Sat, Jul 06, 2019 at 08:23:47PM CEST, parav@mellanox.com wrote:
>To support additional devlink port flavours and to support few common
>and few different port attributes, make following changes.
>
>1. Move physical port attributes to a different structure
>2. Return such attritubes in netlink response only for physical ports
>(PHYSICAL, CPU and DSA)
2 changes, 2 patches please.
^ permalink raw reply
* Re: [PATCH net-next v4 2/4] devlink: Introduce PCI PF port flavour and port attribute
From: Jiri Pirko @ 2019-07-07 19:50 UTC (permalink / raw)
To: Parav Pandit; +Cc: netdev, jiri, saeedm, jakub.kicinski
In-Reply-To: <20190706182350.11929-3-parav@mellanox.com>
Sat, Jul 06, 2019 at 08:23:48PM CEST, parav@mellanox.com wrote:
>In an eswitch, PCI PF may have port which is normally represented
>using a representor netdevice.
>To have better visibility of eswitch port, its association with
>PF and a representor netdevice, introduce a PCI PF port
>flavour and port attriute.
>
>When devlink port flavour is PCI PF, fill up PCI PF attributes of the
>port.
>
>Extend port name creation using PCI PF number on best effort basis.
>So that vendor drivers can skip defining their own scheme.
>
>$ devlink port show
>pci/0000:05:00.0/0: type eth netdev eth0 flavour pcipf pfnum 0
>
>Signed-off-by: Parav Pandit <parav@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next v4 3/4] devlink: Introduce PCI VF port flavour and port attribute
From: Jiri Pirko @ 2019-07-07 19:50 UTC (permalink / raw)
To: Parav Pandit; +Cc: netdev, jiri, saeedm, jakub.kicinski
In-Reply-To: <20190706182350.11929-4-parav@mellanox.com>
Sat, Jul 06, 2019 at 08:23:49PM CEST, parav@mellanox.com wrote:
>In an eswitch, PCI VF may have port which is normally represented using
>a representor netdevice.
>To have better visibility of eswitch port, its association with VF,
>and its representor netdevice, introduce a PCI VF port flavour.
>
>When devlink port flavour is PCI VF, fill up PCI VF attributes of
>the port.
>
>Extend port name creation using PCI PF and VF number scheme on best
>effort basis, so that vendor drivers can skip defining their own scheme.
>
>$ devlink port show
>pci/0000:05:00.0/0: type eth netdev eth0 flavour pcipf pfnum 0
>pci/0000:05:00.0/1: type eth netdev eth1 flavour pcivf pfnum 0 vfnum 0
>pci/0000:05:00.0/2: type eth netdev eth2 flavour pcivf pfnum 0 vfnum 1
>
>Signed-off-by: Parav Pandit <parav@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next v4 4/4] net/mlx5e: Register devlink ports for physical link, PCI PF, VFs
From: Jiri Pirko @ 2019-07-07 19:51 UTC (permalink / raw)
To: Parav Pandit; +Cc: netdev, jiri, saeedm, jakub.kicinski
In-Reply-To: <20190706182350.11929-5-parav@mellanox.com>
Sat, Jul 06, 2019 at 08:23:50PM CEST, parav@mellanox.com wrote:
>Register devlink port of physical port, PCI PF and PCI VF flavour
>for each PF, VF when a given devlink instance is in switchdev mode.
>
>Implement ndo_get_devlink_port callback API to make use of registered
>devlink ports.
>This eliminates ndo_get_phys_port_name() and ndo_get_port_parent_id()
>callbacks. Hence, remove them.
>
>An example output with 2 VFs, without a PF and single uplink port is
>below.
>
>$devlink port show
>pci/0000:06:00.0/65535: type eth netdev ens2f0 flavour physical
>pci/0000:05:00.0/1: type eth netdev eth1 flavour pcivf pfnum 0 vfnum 0
>pci/0000:05:00.0/2: type eth netdev eth2 flavour pcivf pfnum 0 vfnum 1
>
>Reviewed-by: Roi Dayan <roid@mellanox.com>
>Signed-off-by: Parav Pandit <parav@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH 1/2] proc: revalidate directories created with proc_net_mkdir()
From: David Miller @ 2019-07-07 19:51 UTC (permalink / raw)
To: adobriyan; +Cc: viro, netdev, Per.Hallsmark
In-Reply-To: <20190707080351.GA6236@avx2>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Sun, 7 Jul 2019 11:03:51 +0300
> On Sun, Jul 07, 2019 at 02:03:20AM +0100, Al Viro wrote:
>> On Sat, Jul 06, 2019 at 07:52:02PM +0300, Alexey Dobriyan wrote:
>> > +struct proc_dir_entry *_proc_mkdir(const char *name, umode_t mode,
>> > + struct proc_dir_entry **parent, void *data)
>>
>> Two underscores, please...
>
> Second underscore is more typing, I never understood it.
Canonicalness is not about understanding, it's about being consistent
with the rest of the tree.
Just do it please...
^ permalink raw reply
* Re: pull request: bluetooth-next 2019-07-07
From: David Miller @ 2019-07-07 19:55 UTC (permalink / raw)
To: johan.hedberg; +Cc: netdev, linux-bluetooth
In-Reply-To: <20190707080749.GA26799@lazarenk-mobl.amr.corp.intel.com>
From: Johan Hedberg <johan.hedberg@gmail.com>
Date: Sun, 7 Jul 2019 11:07:49 +0300
> Here's the main bluetooth-next pull request for 5.3:
>
> - Added support for new devices from Qualcomm, Realtek and Broadcom and
> MediaTek
> - Various fixes to 6LoWPAN
> - Fix L2CAP PSM namespace separation for LE & BR/EDR
> - Fix behavior with Microsoft Surface Precision Mouse
> - Added support for LE Ping feature
> - Fix L2CAP Disconnect response handling if received in wrong state
>
> Please let me know if there are any issues pulling. Thanks.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH net-next] r8169: sync few chip names with vendor driver
From: David Miller @ 2019-07-07 20:06 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <491cc371-bdaa-a41e-52eb-10ebb3aa4539@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sun, 7 Jul 2019 13:59:54 +0200
> This patch syncs the name of few chip versions with the latest vendor
> driver version.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH iproute2-next] ip: bond: add peer notification delay support
From: Vincent Bernat @ 2019-07-07 20:06 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20190707114041.4f068bee@xps13.lan>
❦ 7 juillet 2019 11:40 -07, Stephen Hemminger <stephen@networkplumber.org>:
> Looks good. I notice that all these flags don't show up in any man
> page.
Yes, "bond type" is not described at all in the manual page. I'll come
with a patch.
--
Your manuscript is both good and original, but the part that is good is not
original and the part that is original is not good.
-- Samuel Johnson
^ permalink raw reply
* Re: [PATCH net] nfc: fix potential illegal memory access
From: David Miller @ 2019-07-07 20:07 UTC (permalink / raw)
To: albin_yang; +Cc: netdev, linux-kernel, tglx
In-Reply-To: <1562506660-15853-1-git-send-email-albin_yang@163.com>
From: Yang Wei <albin_yang@163.com>
Date: Sun, 7 Jul 2019 21:37:40 +0800
> The frags_q is used before __skb_queue_head_init when conn_info is
> NULL. It may result in illegal memory access.
>
> Signed-off-by: Yang Wei <albin_yang@163.com>
> ---
> net/nfc/nci/data.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/nfc/nci/data.c b/net/nfc/nci/data.c
> index 0a0c265..b5f16cb 100644
> --- a/net/nfc/nci/data.c
> +++ b/net/nfc/nci/data.c
> @@ -104,14 +104,14 @@ static int nci_queue_tx_data_frags(struct nci_dev *ndev,
>
> pr_debug("conn_id 0x%x, total_len %d\n", conn_id, total_len);
>
> + __skb_queue_head_init(&frags_q);
> +
> conn_info = nci_get_conn_info_by_conn_id(ndev, conn_id);
> if (!conn_info) {
> rc = -EPROTO;
> goto free_exit;
> }
>
> - __skb_queue_head_init(&frags_q);
> -
Just change the goto into "goto exit;", much simpler one-line fix.
^ permalink raw reply
* Re: [PATCH net-next] tipc: use rcu dereference functions properly
From: David Miller @ 2019-07-07 20:19 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, jon.maloy, ying.xue, tipc-discussion
In-Reply-To: <20190706.151544.2015985674047795584.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sat, 06 Jul 2019 15:15:44 -0700 (PDT)
> From: Xin Long <lucien.xin@gmail.com>
> Date: Sat, 6 Jul 2019 14:48:48 +0800
>
>> Hi, David, I saw this patch in "Changes Requested".
>
> I just put it back to Under Review, thanks.
Applied to net-next, thank you.
^ permalink raw reply
* Re: [RFC PATCH net-next 2/6] taprio: Add support for hardware offloading
From: Vladimir Oltean @ 2019-07-07 20:23 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, Vivien Didelot, David S. Miller,
Vinicius Costa Gomes, vedang.patel, Richard Cochran, weifeng.voon,
jiri, m-karicheri2, Jose.Abreu, ilias.apalodimas, netdev
In-Reply-To: <20190707173951.GB21188@lunn.ch>
On Sun, 7 Jul 2019 at 20:39, Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Sun, Jul 07, 2019 at 08:29:17PM +0300, Vladimir Oltean wrote:
> > From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> >
> > This allows taprio to offload the schedule enforcement to capable
> > network cards, resulting in more precise windows and less CPU usage.
> >
> > The important detail here is the difference between the gate_mask in
> > taprio and gate_mask for the network driver. For the driver, each bit
> > in gate_mask references a transmission queue: bit 0 for queue 0, bit 1
> > for queue 1, and so on. This is done so the driver doesn't need to
> > know about traffic classes.
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> > Signed-off-by: Voon Weifeng <weifeng.voon@intel.com>
>
> Hi Vladimir
>
> Your SOB is also needed here.
>
> Andrew
Hi Andrew,
I thought I'd added it, but it looks like I edited the patch and then
overwrote it, instead of operating on the git history.
Next time!
-Vladimir
^ permalink raw reply
* Re: [RFC PATCH net-next 0/6] tc-taprio offload for SJA1105 DSA
From: Vladimir Oltean @ 2019-07-07 20:28 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, Vivien Didelot, David S. Miller,
Vinicius Costa Gomes, vedang.patel, Richard Cochran, weifeng.voon,
jiri, m-karicheri2, Jose.Abreu, ilias.apalodimas, netdev
In-Reply-To: <20190707174702.GC21188@lunn.ch>
On Sun, 7 Jul 2019 at 20:47, Andrew Lunn <andrew@lunn.ch> wrote:
>
> > - Configuring the switch over SPI cannot apparently be done from this
> > ndo_setup_tc callback because it runs in atomic context. I also have
> > some downstream patches to offload tc clsact matchall with mirred
> > action, but in that case it looks like the atomic context restriction
> > does not apply.
>
> There have been similar problems in the past. We can probably have the
> DSA layer turn it into a notifier. Look at the dsa_port_mdb_*
> functions for example.
>
> Andrew
Ok, thanks. I thought the dsa_port_notify functions are just to be
called from switchdev. I'm still not sure I fully understand, but I'll
try to switch to that in v2 and see what happens.
-Vladimir
^ permalink raw reply
* Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node
From: Vladimir Oltean @ 2019-07-07 21:00 UTC (permalink / raw)
To: Florian Fainelli
Cc: Andrew Lunn, Alexandre Belloni, Allan W. Nielsen, Claudiu Manoil,
David S . Miller, devicetree@vger.kernel.org,
netdev@vger.kernel.org, Alexandru Marginean,
linux-kernel@vger.kernel.org, UNGLinuxDriver@microchip.com,
Allan Nielsen, Rob Herring, linux-arm-kernel@lists.infradead.org
In-Reply-To: <c60df66a-b3c9-1445-36c6-cad7c6b75550@gmail.com>
On Fri, 5 Jul 2019 at 19:03, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>
>
> On 7/5/2019 2:08 AM, Vladimir Oltean wrote:
> > Hi Andrew,
> >
> > On Fri, 5 Jul 2019 at 07:49, Andrew Lunn <andrew@lunn.ch> wrote:
> >>
> >> Hi Vladimir
> >>
> >>> - DSA is typically used for discrete switches, switchdev is typically
> >>> used for embedded ones.
> >>
> >> Typically DSA is for discrete switches, but not exclusively. The
> >> b53/SF2 is embedded in a number of Broadcom SoCs. So this is no
> >> different to Ocelot, except ARM vs MIPS. Also, i would disagree that
> >> switchdev is used for embedded ones. Mellonex devices are discrete, on
> >> a PCIe bus. I believe Netronome devices are also discrete PCIe
> >> devices. In fact, i think ocelot is the only embedded switchdev
> >> switch.
> >>
> >> So embedded vs discrete plays no role here at all.
> >>
> >
> > drivers/staging/fsl-dpaa2/ethsw/ is another example of switchdev
> > driver for an embedded switch.
> > I would give it to you that the sample size is probably too small to
> > say 'typically', but my point was that in order to support cascaded
> > switches it makes more sense for those to be discrete.
> >
> >>> - The D in DSA is for cascaded switches. Apart from the absence of
> >>> such a "Ocelot SoC" driver (which maybe can be written, I don't know),
> >>> I think the switching core itself has some fundamental limitations
> >>> that make a DSA implementation questionable:
> >>
> >> There is no requirement to implement D in DSA. In fact, only Marvell
> >> does. None of the other switches do. And you will also find that most
> >> boards with a Marvell switch use a single device. D in DSA is totally
> >> optional. In fact, DSA is built from the ground up that nearly
> >> everything is optional. Take a look at mv88e6060, as an example. It
> >> implements nearly nothing. It cannot even offload a bridge to the
> >> switch.
> >>
> >
> > Let me see if I get your point.
> > The D is optional, and the S is optional. So what's left? :)
> > Also, there's a big difference between "the hardware can't do it" and
> > "the driver doesn't implement it". If I follow your argument, would
> > you write a DSA driver for a device that doesn't do L2 switching?
> > Along that same line, what benefit does the DSA model bring to a
> > switch that can't do cascading, compared to switchdev? I'm asking this
> > as a user, not as a developer.
>
> As an user, I don't think there are compelling arguments to either
> switchdev or DSA because the end result is the same: network devices
> that can offload "stuff". As a developer though, there is much less code
> to write with DSA than with switchdev to get your HW live.
>
> >
> >>> So my conclusion is that DSA for Felix/Ocelot doesn't make a lot of
> >>> sense if the whole purpose is to hide the CPU-facing netdev.
> >>
> >> You actually convinced me the exact opposite. You described the
> >> headers which are needed to implement DSA. The switch sounds like it
> >> can do what DSA requires. So DSA is the correct model.
> >>
> >> Andrew
> >
> > Somebody actually asked, with the intention of building a board, if
> > it's possible to cascade the LS1028A embedded switch (Felix) with
> > discrete SJA1105 devices - Felix being at the top of the switch tree.
> > Does the DSA model support heterogeneous setups (parsing stacked
> > headers)? I can't tell if that's how EDSA tags work. With switchdev
> > for Felix there wouldn't be any problem - it just wouldn't be part of
> > the DSA tree and its own driver would remove its tags before DSA would
> > look at the rest.
>
> DSA not does not make any particular assumptions about how the stacking
> is done actually because each slave network device is expected to
> provided standard Ethernet frames to the network stack. How you get to
> that point is entirely specific to what the hardware can do.
>
> You do what Andrew described about one of my setup (bcm_sf2 w/ tagging
> enabled and b53 w/o tagging, see more below why [1]]) and both being
> discrete switch trees, with the master netdev of the b53 being a slave
> netdev provided by bcm_sf2. If your tagging protocol supports it you can
> make them part of the same DSA switch tree and just have them have
> different switch identifiers, that is what Marvell switches do and it
> works just great. In your case, I suppose you could even use double VLAN
> tagging to get such cascading to work, that would limit you to a two
> level of cascading, unless you invent something custom.
>
> [1]: The original Broadcom tag format introduced with BCM5325/5365 did
> support cascading in the same way that Marvell did where a switch
> identifier can be added in addition to a port number within the tag. The
> newest Broadcom tag that was introduced with 5395 and newer dropped
> support for the switch identifier and the switch will "terminate" the
> first (from start of Ethernet frame) tag that it receives. This is the
> reason why we need to disable tagging on the outermost B53 device that
> we are connected to. This means those network devices are mainly
> configuration endpoints and not passing data (DSA_TAG_PROTO_NONE),
> though we could use DSA_TAG_PROTO_8021Q and resolve that now.
> --
> Florian
Thanks to both of you for sharing this trick, I don't think it's
written "in the books".
Given that you can choose the boundaries of a DSA tree at will
depending on what suits the setup best (and e.g. turn a DSA link pair
into a master and a CPU port pair which gains back introspection into
that port's ethtool counters etc), I guess DSA doesn't really offer
anything that raw switchdev drivers can't do (by reimplementing part
of it), just that it's is more idiomatic for Ethernet-connected
switches?
If so, it's a bit strange that switchdev and DSA are not in fact
unified, because as it is it creates false dichotomies. What about the
other way around? What are the features that raw switchdev drivers
(nfp, rocker, mlxsw) need that DSA can't offer them without breaking
the general model? (apart from access to the raw ndo_start_xmit and a
NAPI context for rcv)
As for DSA being easier on the driver writer, I totally get that, but
I think it isn't that much of an argument when the switchdev driver is
already said and done, as in this case :)
Regards,
-Vladimir
^ permalink raw reply
* Re: [PATCH net 0/2] net/tls: fix poll() wake up
From: David Miller @ 2019-07-07 21:13 UTC (permalink / raw)
To: jakub.kicinski; +Cc: netdev, oss-drivers, alexei.starovoitov
In-Reply-To: <20190704215037.6008-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Thu, 4 Jul 2019 14:50:35 -0700
> This small fix + selftest series is very similar to the previous
> commit 04b25a5411f9 ("net/tls: fix no wakeup on partial reads").
> This time instead of recvmsg we're fixing poll wake up.
Series applied and patch #1 queued up for -stable.
Thanks!
^ permalink raw reply
* Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node
From: Florian Fainelli @ 2019-07-07 21:15 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andrew Lunn, Alexandre Belloni, Allan W. Nielsen, Claudiu Manoil,
David S . Miller, devicetree@vger.kernel.org,
netdev@vger.kernel.org, Alexandru Marginean,
linux-kernel@vger.kernel.org, UNGLinuxDriver@microchip.com,
Allan Nielsen, Rob Herring, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CA+h21hqGEf4hoeBQ-cSGsiOWUD7bVX4=NWcJjwdYHOVonangAw@mail.gmail.com>
On 7/7/2019 2:00 PM, Vladimir Oltean wrote:
> On Fri, 5 Jul 2019 at 19:03, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>
>>
>>
>> On 7/5/2019 2:08 AM, Vladimir Oltean wrote:
>>> Hi Andrew,
>>>
>>> On Fri, 5 Jul 2019 at 07:49, Andrew Lunn <andrew@lunn.ch> wrote:
>>>>
>>>> Hi Vladimir
>>>>
>>>>> - DSA is typically used for discrete switches, switchdev is typically
>>>>> used for embedded ones.
>>>>
>>>> Typically DSA is for discrete switches, but not exclusively. The
>>>> b53/SF2 is embedded in a number of Broadcom SoCs. So this is no
>>>> different to Ocelot, except ARM vs MIPS. Also, i would disagree that
>>>> switchdev is used for embedded ones. Mellonex devices are discrete, on
>>>> a PCIe bus. I believe Netronome devices are also discrete PCIe
>>>> devices. In fact, i think ocelot is the only embedded switchdev
>>>> switch.
>>>>
>>>> So embedded vs discrete plays no role here at all.
>>>>
>>>
>>> drivers/staging/fsl-dpaa2/ethsw/ is another example of switchdev
>>> driver for an embedded switch.
>>> I would give it to you that the sample size is probably too small to
>>> say 'typically', but my point was that in order to support cascaded
>>> switches it makes more sense for those to be discrete.
>>>
>>>>> - The D in DSA is for cascaded switches. Apart from the absence of
>>>>> such a "Ocelot SoC" driver (which maybe can be written, I don't know),
>>>>> I think the switching core itself has some fundamental limitations
>>>>> that make a DSA implementation questionable:
>>>>
>>>> There is no requirement to implement D in DSA. In fact, only Marvell
>>>> does. None of the other switches do. And you will also find that most
>>>> boards with a Marvell switch use a single device. D in DSA is totally
>>>> optional. In fact, DSA is built from the ground up that nearly
>>>> everything is optional. Take a look at mv88e6060, as an example. It
>>>> implements nearly nothing. It cannot even offload a bridge to the
>>>> switch.
>>>>
>>>
>>> Let me see if I get your point.
>>> The D is optional, and the S is optional. So what's left? :)
>>> Also, there's a big difference between "the hardware can't do it" and
>>> "the driver doesn't implement it". If I follow your argument, would
>>> you write a DSA driver for a device that doesn't do L2 switching?
>>> Along that same line, what benefit does the DSA model bring to a
>>> switch that can't do cascading, compared to switchdev? I'm asking this
>>> as a user, not as a developer.
>>
>> As an user, I don't think there are compelling arguments to either
>> switchdev or DSA because the end result is the same: network devices
>> that can offload "stuff". As a developer though, there is much less code
>> to write with DSA than with switchdev to get your HW live.
>>
>>>
>>>>> So my conclusion is that DSA for Felix/Ocelot doesn't make a lot of
>>>>> sense if the whole purpose is to hide the CPU-facing netdev.
>>>>
>>>> You actually convinced me the exact opposite. You described the
>>>> headers which are needed to implement DSA. The switch sounds like it
>>>> can do what DSA requires. So DSA is the correct model.
>>>>
>>>> Andrew
>>>
>>> Somebody actually asked, with the intention of building a board, if
>>> it's possible to cascade the LS1028A embedded switch (Felix) with
>>> discrete SJA1105 devices - Felix being at the top of the switch tree.
>>> Does the DSA model support heterogeneous setups (parsing stacked
>>> headers)? I can't tell if that's how EDSA tags work. With switchdev
>>> for Felix there wouldn't be any problem - it just wouldn't be part of
>>> the DSA tree and its own driver would remove its tags before DSA would
>>> look at the rest.
>>
>> DSA not does not make any particular assumptions about how the stacking
>> is done actually because each slave network device is expected to
>> provided standard Ethernet frames to the network stack. How you get to
>> that point is entirely specific to what the hardware can do.
>>
>> You do what Andrew described about one of my setup (bcm_sf2 w/ tagging
>> enabled and b53 w/o tagging, see more below why [1]]) and both being
>> discrete switch trees, with the master netdev of the b53 being a slave
>> netdev provided by bcm_sf2. If your tagging protocol supports it you can
>> make them part of the same DSA switch tree and just have them have
>> different switch identifiers, that is what Marvell switches do and it
>> works just great. In your case, I suppose you could even use double VLAN
>> tagging to get such cascading to work, that would limit you to a two
>> level of cascading, unless you invent something custom.
>>
>> [1]: The original Broadcom tag format introduced with BCM5325/5365 did
>> support cascading in the same way that Marvell did where a switch
>> identifier can be added in addition to a port number within the tag. The
>> newest Broadcom tag that was introduced with 5395 and newer dropped
>> support for the switch identifier and the switch will "terminate" the
>> first (from start of Ethernet frame) tag that it receives. This is the
>> reason why we need to disable tagging on the outermost B53 device that
>> we are connected to. This means those network devices are mainly
>> configuration endpoints and not passing data (DSA_TAG_PROTO_NONE),
>> though we could use DSA_TAG_PROTO_8021Q and resolve that now.
>> --
>> Florian
>
> Thanks to both of you for sharing this trick, I don't think it's
> written "in the books".
> Given that you can choose the boundaries of a DSA tree at will
> depending on what suits the setup best (and e.g. turn a DSA link pair
> into a master and a CPU port pair which gains back introspection into
> that port's ethtool counters etc), I guess DSA doesn't really offer
> anything that raw switchdev drivers can't do (by reimplementing part
> of it), just that it's is more idiomatic for Ethernet-connected
> switches?
> If so, it's a bit strange that switchdev and DSA are not in fact
> unified, because as it is it creates false dichotomies. What about the
> other way around? What are the features that raw switchdev drivers
> (nfp, rocker, mlxsw) need that DSA can't offer them without breaking
> the general model? (apart from access to the raw ndo_start_xmit and a
> NAPI context for rcv)
I don't think they need anything that DSA could not offer them, other
than having the ability to complete bypass the net_device registration
and standard methods offered by DSA and provide their own.
> As for DSA being easier on the driver writer, I totally get that, but
> I think it isn't that much of an argument when the switchdev driver is
> already said and done, as in this case :)
DSA and switchdev don't try to solve the same problems, switchdev is
only about providing the mechanics by which the networking stack can
offload certain objects: FDB, MDB, VLANs, VXLANs, bridge attributes etc
towards capable devices. It is largely stateless and does not care so
much about what kind of device is on the other end of the notifications
it sends.
DSA is all about creating a device driver model for Ethernet switches
that follow the paradigm of having a seemingly standard Ethernet MAC
(doing DMA) connected to one or more Ethernet switch devices and between
those devices, a data path allows the identification of each Ethernet
frame as ingressing/egressing towards a particular switch port in the
fabric. With DSA you are supposed to be able to swap your Ethernet MAC
driver (e.g.: mv643xx_eth, e1000e, igb, bcmsysport, bcmgenet, etc.) with
any switch device (mv88e6xxx, b53, qca8k, etc.) and things would still
work largely the same (minus switch driver differences obviously).
In that regard, DSA also provides you with a number of things "for free"
to try to push the standard Linux device driver model further:
integration with PHYLIB/PHYLINK, HWMON, ethtool, etc. etc.
--
Florian
^ permalink raw reply
* Re: [PATCH v3 0/4] net: dsa: Add Vitesse VSC73xx parallel mode
From: David Miller @ 2019-07-07 21:16 UTC (permalink / raw)
To: paweldembicki
Cc: linus.walleij, andrew, vivien.didelot, f.fainelli, robh+dt,
mark.rutland, netdev, devicetree, linux-kernel
In-Reply-To: <20190704222907.2888-1-paweldembicki@gmail.com>
From: Pawel Dembicki <paweldembicki@gmail.com>
Date: Fri, 5 Jul 2019 00:29:03 +0200
> Main goal of this patch series is to add support for CPU attached parallel
> bus in Vitesse VSC73xx switches. Existing driver supports only SPI mode.
>
> Second change is needed for devices in unmanaged state.
>
> V3:
> - fix commit messages and descriptions about memory-mapped I/O mode
>
> V2:
> - drop changes in compatible strings
> - make changes less invasive
> - drop mutex in platform part and move mutex from core to spi part
> - fix indentation
> - fix devm_ioremap_resource result check
> - add cover letter
Series applied to net-next, thank you.
^ permalink raw reply
* [PATCH] phy: added a PHY_BUSY state into phy_state_machine
From: kwangdo.yi @ 2019-07-07 22:32 UTC (permalink / raw)
To: netdev; +Cc: kwangdo.yi
When mdio driver polling the phy state in the phy_state_machine,
sometimes it results in -ETIMEDOUT and link is down. But the phy
is still alive and just didn't meet the polling deadline.
Closing the phy link in this case seems too radical. Failing to
meet the deadline happens very rarely. When stress test runs for
tens of hours with multiple target boards (Xilinx Zynq7000 with
marvell 88E1512 PHY, Xilinx custom emac IP), it happens. This
patch gives another chance to the phy_state_machine when polling
timeout happens. Only two consecutive failing the deadline is
treated as the real phy halt and close the connection.
Signed-off-by: kwangdo.yi <kwangdo.yi@gmail.com>
---
drivers/net/phy/phy.c | 6 ++++++
include/linux/phy.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index e888542..9e8138b 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -919,7 +919,13 @@ void phy_state_machine(struct work_struct *work)
break;
case PHY_NOLINK:
case PHY_RUNNING:
+ case PHY_BUSY:
err = phy_check_link_status(phydev);
+ if (err == -ETIMEDOUT && old_state == PHY_RUNNING) {
+ phy->state = PHY_BUSY;
+ err = 0;
+
+ }
break;
case PHY_FORCING:
err = genphy_update_link(phydev);
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 6424586..4a49401 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -313,6 +313,7 @@ enum phy_state {
PHY_RUNNING,
PHY_NOLINK,
PHY_FORCING,
+ PHY_BUSY,
};
/**
--
2.7.4
^ permalink raw reply related
* [PATCH] tipc: ensure skb->lock is initialised
From: Chris Packham @ 2019-07-07 22:53 UTC (permalink / raw)
To: jon.maloy, ying.xue, davem
Cc: netdev, tipc-discussion, linux-kernel, Chris Packham
tipc_named_node_up() creates a skb list. It passes the list to
tipc_node_xmit() which has some code paths that can call
skb_queue_purge() which relies on the list->lock being initialised.
Ensure tipc_named_node_up() uses skb_queue_head_init() so that the lock
is explicitly initialised.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
I'm updating our products to use the latest kernel. One change that we have that
doesn't appear to have been upstreamed is related to the following soft lockup.
NMI watchdog: BUG: soft lockup - CPU#3 stuck for 23s! [swapper/3:0]
Modules linked in: tipc jitterentropy_rng echainiv drbg platform_driver(O) ipifwd(PO)
CPU: 3 PID: 0 Comm: swapper/3 Tainted: P O 4.4.6-at1 #1
task: a3054e00 ti: ac6b4000 task.ti: a307a000
NIP: 806891c4 LR: 804f5060 CTR: 804f50d0
REGS: ac6b59b0 TRAP: 0901 Tainted: P O (4.4.6-at1)
MSR: 00029002 <CE,EE,ME> CR: 84002088 XER: 20000000
GPR00: 804f50fc ac6b5a60 a3054e00 00029002 00000101 01001011 00000000 00000001
GPR08: 00021002 c1502d1c ac6b5ae4 00000000 804f50d0
NIP [806891c4] _raw_spin_lock_irqsave+0x44/0x80
LR [804f5060] skb_dequeue+0x20/0x90
Call Trace:
[ac6b5a80] [804f50fc] skb_queue_purge+0x2c/0x50
[ac6b5a90] [c1511058] tipc_node_xmit+0x138/0x170 [tipc]
[ac6b5ad0] [c1509e58] tipc_named_node_up+0x88/0xa0 [tipc]
[ac6b5b00] [c150fc1c] tipc_netlink_compat_stop+0x9bc/0xf50 [tipc]
[ac6b5b20] [c1511638] tipc_rcv+0x418/0x9b0 [tipc]
[ac6b5bc0] [c150218c] tipc_bcast_stop+0xfc/0x7b0 [tipc]
[ac6b5bd0] [80504e38] __netif_receive_skb_core+0x468/0xa10
[ac6b5c70] [805082fc] netif_receive_skb_internal+0x3c/0xe0
[ac6b5ca0] [80642a48] br_handle_frame_finish+0x1d8/0x4d0
[ac6b5d10] [80642f30] br_handle_frame+0x1f0/0x330
[ac6b5d60] [80504ec8] __netif_receive_skb_core+0x4f8/0xa10
[ac6b5e00] [805082fc] netif_receive_skb_internal+0x3c/0xe0
[ac6b5e30] [8044c868] _dpa_rx+0x148/0x5c0
[ac6b5ea0] [8044b0c8] priv_rx_default_dqrr+0x98/0x170
[ac6b5ed0] [804d1338] qman_p_poll_dqrr+0x1b8/0x240
[ac6b5f00] [8044b1c0] dpaa_eth_poll+0x20/0x60
[ac6b5f20] [805087cc] net_rx_action+0x15c/0x320
[ac6b5f80] [8002594c] __do_softirq+0x13c/0x250
[ac6b5fe0] [80025c34] irq_exit+0xb4/0xf0
[ac6b5ff0] [8000d81c] call_do_irq+0x24/0x3c
[a307be60] [80004acc] do_IRQ+0x8c/0x120
[a307be80] [8000f450] ret_from_except+0x0/0x18
--- interrupt: 501 at arch_cpu_idle+0x24/0x70
Eyeballing the code I think it can still happen since tipc_named_node_up
allocates struct sk_buff_head head on the stack so it could have arbitary
content.
net/tipc/name_distr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c
index 61219f0b9677..44abc8e9c990 100644
--- a/net/tipc/name_distr.c
+++ b/net/tipc/name_distr.c
@@ -190,7 +190,7 @@ void tipc_named_node_up(struct net *net, u32 dnode)
struct name_table *nt = tipc_name_table(net);
struct sk_buff_head head;
- __skb_queue_head_init(&head);
+ skb_queue_head_init(&head);
read_lock_bh(&nt->cluster_scope_lock);
named_distribute(net, &head, dnode, &nt->cluster_scope);
--
2.22.0
^ permalink raw reply related
* Re: More complex PBR rules
From: Markus Moeller @ 2019-07-07 23:20 UTC (permalink / raw)
To: netdev, David Ahern
In-Reply-To: <3fe925c0-e26f-492d-2552-b13a14451e3e@gmail.com>
Hi David,
I read up about multipath routing and ecmp. It seems to do what I am
looking for.
Thank you
Markus
-----Original Message-----
From: David Ahern
Sent: Sunday, July 7, 2019 2:24 PM
To: Markus Moeller ; netdev@vger.kernel.org
Subject: Re: More complex PBR rules
On 7/6/19 5:06 PM, Markus Moeller wrote:
> Hi Network developers
>
> I am new to this group and wonder if you can advise how I could
> implement more complex PBR rules to achieve for example load balancing.
> The requirement I have is to route based on e.g. a hash like:
>
> hash(src-ip+dst-ip) mod N routes via gwX 0<X<=N ( load balance
> over N gateways )
Have you tried multipath routing? Does that not work for you?
>
> This would help in situations where I can not use a MAC for identifying
> a gateway ( e.g. in cloud environments) .
>
> Could someone point me to the kernel source code where PBR is performed
> ?
>
net/core/fib_rules.c
^ permalink raw reply
* Re: [PATCH v8 net-next 0/5] net: ethernet: ti: cpsw: Add XDP support
From: David Miller @ 2019-07-08 1:31 UTC (permalink / raw)
To: ivan.khoronzhuk
Cc: grygorii.strashko, hawk, ast, linux-kernel, linux-omap,
xdp-newbies, ilias.apalodimas, netdev, daniel, jakub.kicinski,
john.fastabend
In-Reply-To: <20190705150502.6600-1-ivan.khoronzhuk@linaro.org>
From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Date: Fri, 5 Jul 2019 18:04:57 +0300
> This patchset adds XDP support for TI cpsw driver and base it on
> page_pool allocator. It was verified on af_xdp socket drop,
> af_xdp l2f, ebpf XDP_DROP, XDP_REDIRECT, XDP_PASS, XDP_TX.
>
> It was verified with following configs enabled:
...
I'm applying this to net-next, please deal with whatever follow-ups are
necessary.
Thanks!
^ permalink raw reply
* Re: [PATCH v8 net-next 0/5] net: ethernet: ti: cpsw: Add XDP support
From: David Miller @ 2019-07-08 1:35 UTC (permalink / raw)
To: ivan.khoronzhuk
Cc: grygorii.strashko, hawk, ast, linux-kernel, linux-omap,
xdp-newbies, ilias.apalodimas, netdev, daniel, jakub.kicinski,
john.fastabend
In-Reply-To: <20190707.183146.1123763637704790378.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sun, 07 Jul 2019 18:31:46 -0700 (PDT)
> From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
> Date: Fri, 5 Jul 2019 18:04:57 +0300
>
>> This patchset adds XDP support for TI cpsw driver and base it on
>> page_pool allocator. It was verified on af_xdp socket drop,
>> af_xdp l2f, ebpf XDP_DROP, XDP_REDIRECT, XDP_PASS, XDP_TX.
>>
>> It was verified with following configs enabled:
> ...
>
> I'm applying this to net-next, please deal with whatever follow-ups are
> necessary.
Nevermind, you really have to fix this:
drivers/net/ethernet/ti/davinci_cpdma.c: In function ‘cpdma_chan_submit_si’:
drivers/net/ethernet/ti/davinci_cpdma.c:1047:12: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
buffer = (u32)si->data;
^
drivers/net/ethernet/ti/davinci_cpdma.c: In function ‘cpdma_chan_idle_submit_mapped’:
drivers/net/ethernet/ti/davinci_cpdma.c:1114:12: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
si.data = (void *)(u32)data;
^
drivers/net/ethernet/ti/davinci_cpdma.c: In function ‘cpdma_chan_submit_mapped’:
drivers/net/ethernet/ti/davinci_cpdma.c:1164:12: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
si.data = (void *)(u32)data;
^
^ permalink raw reply
* Re: [PATCH net 0/6] gtp: fix several bugs
From: David Miller @ 2019-07-08 1:55 UTC (permalink / raw)
To: ap420073; +Cc: pablo, laforge, osmocom-net-gprs, netdev
In-Reply-To: <20190702152034.22412-1-ap420073@gmail.com>
From: Taehee Yoo <ap420073@gmail.com>
Date: Wed, 3 Jul 2019 00:20:34 +0900
> This patch series fixes several bugs in the gtp module.
I reviewed these carefully by hand and decided to apply these now.
Thanks Taehee.
^ 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