* [PATCH] bpf: Remove unused variable in nsim_bpf
From: Nathan Chancellor @ 2018-11-12 22:10 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: Quentin Monnet, Jakub Kicinski, netdev, linux-kernel,
Nathan Chancellor
Clang warns:
drivers/net/netdevsim/bpf.c:557:30: error: unused variable 'state'
[-Werror,-Wunused-variable]
struct nsim_bpf_bound_prog *state;
^
1 error generated.
The declaration should have been removed in commit b07ade27e933 ("bpf:
pass translate() as a callback and remove its ndo_bpf subcommand").
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/net/netdevsim/bpf.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/netdevsim/bpf.c b/drivers/net/netdevsim/bpf.c
index 6a5b7bd9a1f9..a1b29173ca1c 100644
--- a/drivers/net/netdevsim/bpf.c
+++ b/drivers/net/netdevsim/bpf.c
@@ -554,7 +554,6 @@ static void nsim_bpf_map_free(struct bpf_offloaded_map *offmap)
int nsim_bpf(struct net_device *dev, struct netdev_bpf *bpf)
{
struct netdevsim *ns = netdev_priv(dev);
- struct nsim_bpf_bound_prog *state;
int err;
ASSERT_RTNL();
--
2.19.1
^ permalink raw reply related
* [PATCH] geneve: Add missing braces in addr6 initializer
From: Nathan Chancellor @ 2018-11-12 22:12 UTC (permalink / raw)
To: David S. Miller
Cc: Stefano Brivio, Sabrina Dubroca, netdev, linux-kernel,
Nathan Chancellor
Clang warns:
drivers/net/geneve.c:428:29: error: suggest braces around initialization
of subobject [-Werror,-Wmissing-braces]
struct in6_addr addr6 = { 0 };
^
{}
Fixes: a07966447f39 ("geneve: ICMP error lookup handler")
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/net/geneve.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 7c53e06b31c3..224d8b0bb5de 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -425,7 +425,7 @@ static int geneve_udp_encap_err_lookup(struct sock *sk, struct sk_buff *skb)
#if IS_ENABLED(CONFIG_IPV6)
if (geneve_get_sk_family(gs) == AF_INET6) {
struct ipv6hdr *ip6h = ipv6_hdr(skb);
- struct in6_addr addr6 = { 0 };
+ struct in6_addr addr6 = { { 0 } };
if (!gs->collect_md) {
vni = geneve_hdr(skb)->vni;
--
2.19.1
^ permalink raw reply related
* Re: [PATCH] geneve: Add missing braces in addr6 initializer
From: Stefano Brivio @ 2018-11-12 22:19 UTC (permalink / raw)
To: Nathan Chancellor; +Cc: David S. Miller, Sabrina Dubroca, netdev, linux-kernel
In-Reply-To: <20181112221248.11477-1-natechancellor@gmail.com>
On Mon, 12 Nov 2018 15:12:48 -0700
Nathan Chancellor <natechancellor@gmail.com> wrote:
> Clang warns:
>
> drivers/net/geneve.c:428:29: error: suggest braces around initialization
> of subobject [-Werror,-Wmissing-braces]
> struct in6_addr addr6 = { 0 };
> ^
> {}
>
> Fixes: a07966447f39 ("geneve: ICMP error lookup handler")
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Thanks for spotting this. By the way, I guess you should indicate in
the subject when patches are meant for net-next.
Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
--
Stefano
^ permalink raw reply
* Re: [PATCH] geneve: Add missing braces in addr6 initializer
From: Nathan Chancellor @ 2018-11-12 22:20 UTC (permalink / raw)
To: Stefano Brivio; +Cc: David S. Miller, Sabrina Dubroca, netdev, linux-kernel
In-Reply-To: <20181112231917.4f2f07b5@redhat.com>
On Mon, Nov 12, 2018 at 11:19:17PM +0100, Stefano Brivio wrote:
> On Mon, 12 Nov 2018 15:12:48 -0700
> Nathan Chancellor <natechancellor@gmail.com> wrote:
>
> > Clang warns:
> >
> > drivers/net/geneve.c:428:29: error: suggest braces around initialization
> > of subobject [-Werror,-Wmissing-braces]
> > struct in6_addr addr6 = { 0 };
> > ^
> > {}
> >
> > Fixes: a07966447f39 ("geneve: ICMP error lookup handler")
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
>
> Thanks for spotting this. By the way, I guess you should indicate in
> the subject when patches are meant for net-next.
>
Sure, I'll be better about that in the future.
> Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
>
Thank you for the review!
Nathan
> --
> Stefano
^ permalink raw reply
* RE
From: ya vila @ 2018-11-12 12:27 UTC (permalink / raw)
Mr Bayford picked you for a $1,M donation Email For more details
^ permalink raw reply
* [RFC PATCH 0/6] Armada 38x comphy driver to support 2.5Gbps networking
From: Russell King - ARM Linux @ 2018-11-12 12:29 UTC (permalink / raw)
To: devicetree, linux-arm-kernel, netdev
Cc: Andrew Lunn, Gregory Clement, Jason Cooper,
Kishon Vijay Abraham I, Mark Rutland, Rob Herring,
Sebastian Hesselbarth, Thomas Petazzoni, Maxime Chevallier
Hi,
This series adds support for dynamically switching between 1Gbps
and 2.5Gbps networking for the Marvell Armada 38x SoCs, tested on
Armada 388 on the Clearfog platform.
This is necessary to be able to connect (eg) a Clearfog platform
with a Macchiatobin platform via the SFP sockets, as Clearfog
currently only supports 1Gbps networking via the SFP socket and
Macchiatobin defaults to 2.5Gbps when using Fiberchannel SFPs.
In order to allow dynamic switching, we need to implement a common
phy driver to switch the ethernet serdes lane speed - 2.5Gbps is
just 1Gbps up-clocked by 2.5x. We implement a simple comphy
driver to achieve this, which only supports networking.
With this, we are able to support both Fiberchannel SFPs operating
at 2.5Gbps or 1Gbps, and 1G ethernet SFPs plugged into the Clearfog
platform, dynamically selecting according to the SFPs abilities.
I'm aware of the proposed changes to the PHY layer, changing
phy_set_mode() to take the ethernet phy interface type, hence why
this is RFC - there's also the question about how this will be
merged. This series is currently based on 4.20-rc1, but will
likely need to be rebased when the PHY layer changes hit.
.../bindings/net/marvell-armada-370-neta.txt | 2 +-
.../bindings/phy/phy-armada38x-comphy.txt | 40 ++++
arch/arm/boot/dts/armada-388-clearfog.dtsi | 2 +
arch/arm/boot/dts/armada-38x.dtsi | 37 ++++
drivers/net/ethernet/marvell/mvneta.c | 58 ++++-
drivers/phy/marvell/Kconfig | 10 +
drivers/phy/marvell/Makefile | 1 +
drivers/phy/marvell/phy-armada38x-comphy.c | 236 +++++++++++++++++++++
8 files changed, 378 insertions(+), 8 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/phy-armada38x-comphy.txt
create mode 100644 drivers/phy/marvell/phy-armada38x-comphy.c
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* [RFC PATCH 1/6] dt-bindings: phy: Armada 38x common phy bindings
From: Russell King @ 2018-11-12 12:30 UTC (permalink / raw)
To: devicetree, linux-arm-kernel, netdev
Cc: Andrew Lunn, Gregory Clement, Jason Cooper,
Kishon Vijay Abraham I, Mark Rutland, Rob Herring,
Sebastian Hesselbarth, Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20181112122933.GD30658@n2100.armlinux.org.uk>
Add the Marvell Armada 38x common phy bindings.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
.../bindings/phy/phy-armada38x-comphy.txt | 40 ++++++++++++++++++++++
1 file changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/phy-armada38x-comphy.txt
diff --git a/Documentation/devicetree/bindings/phy/phy-armada38x-comphy.txt b/Documentation/devicetree/bindings/phy/phy-armada38x-comphy.txt
new file mode 100644
index 000000000000..ad49e5c01334
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-armada38x-comphy.txt
@@ -0,0 +1,40 @@
+mvebu armada 38x comphy driver
+------------------------------
+
+This comphy controller can be found on Marvell Armada 38x. It provides a
+number of shared PHYs used by various interfaces (network, sata, usb,
+PCIe...).
+
+Required properties:
+
+- compatible: should be "marvell,armada-380-comphy"
+- reg: should contain the comphy register location and length.
+- #address-cells: should be 1.
+- #size-cells: should be 0.
+
+A sub-node is required for each comphy lane provided by the comphy.
+
+Required properties (child nodes):
+
+- reg: comphy lane number.
+- #phy-cells : from the generic phy bindings, must be 1. Defines the
+ input port to use for a given comphy lane.
+
+Example:
+
+ comphy: phy@18300 {
+ compatible = "marvell,armada-380-comphy";
+ reg = <0x18300 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpm_comphy0: phy@0 {
+ reg = <0>;
+ #phy-cells = <1>;
+ };
+
+ cpm_comphy1: phy@1 {
+ reg = <1>;
+ #phy-cells = <1>;
+ };
+ };
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 2/6] phy: armada38x: add common phy support
From: Russell King @ 2018-11-12 12:30 UTC (permalink / raw)
To: devicetree, linux-arm-kernel, netdev
Cc: Andrew Lunn, Gregory Clement, Jason Cooper,
Kishon Vijay Abraham I, Mark Rutland, Rob Herring,
Sebastian Hesselbarth, Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20181112122933.GD30658@n2100.armlinux.org.uk>
Add support for the Armada 38x common phy to allow us to change the
speed of the Ethernet serdes lane. This driver only supports
manipulation of the speed, it does not support configuration of the
common phy.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/phy/marvell/Kconfig | 10 ++
drivers/phy/marvell/Makefile | 1 +
drivers/phy/marvell/phy-armada38x-comphy.c | 236 +++++++++++++++++++++++++++++
3 files changed, 247 insertions(+)
create mode 100644 drivers/phy/marvell/phy-armada38x-comphy.c
diff --git a/drivers/phy/marvell/Kconfig b/drivers/phy/marvell/Kconfig
index 6fb4b56e4c14..224ea4e6a46d 100644
--- a/drivers/phy/marvell/Kconfig
+++ b/drivers/phy/marvell/Kconfig
@@ -21,6 +21,16 @@ config PHY_BERLIN_USB
help
Enable this to support the USB PHY on Marvell Berlin SoCs.
+config PHY_MVEBU_A38X_COMPHY
+ tristate "Marvell Armada 38x comphy driver"
+ depends on ARCH_MVEBU || COMPILE_TEST
+ depends on OF
+ select GENERIC_PHY
+ help
+ This driver allows to control the comphy, an hardware block providing
+ shared serdes PHYs on Marvell Armada 38x. Its serdes lanes can be
+ used by various controllers (Ethernet, sata, usb, PCIe...).
+
config PHY_MVEBU_CP110_COMPHY
tristate "Marvell CP110 comphy driver"
depends on ARCH_MVEBU || COMPILE_TEST
diff --git a/drivers/phy/marvell/Makefile b/drivers/phy/marvell/Makefile
index 3975b144f8ec..59b6c03ef756 100644
--- a/drivers/phy/marvell/Makefile
+++ b/drivers/phy/marvell/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
obj-$(CONFIG_PHY_BERLIN_SATA) += phy-berlin-sata.o
obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o
+obj-$(CONFIG_PHY_MVEBU_A38X_COMPHY) += phy-armada38x-comphy.o
obj-$(CONFIG_PHY_MVEBU_CP110_COMPHY) += phy-mvebu-cp110-comphy.o
obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o
obj-$(CONFIG_PHY_PXA_28NM_HSIC) += phy-pxa-28nm-hsic.o
diff --git a/drivers/phy/marvell/phy-armada38x-comphy.c b/drivers/phy/marvell/phy-armada38x-comphy.c
new file mode 100644
index 000000000000..61d1965e1cf6
--- /dev/null
+++ b/drivers/phy/marvell/phy-armada38x-comphy.c
@@ -0,0 +1,236 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Russell King, Deep Blue Solutions Ltd.
+ *
+ * Partly derived from CP110 comphy driver by Antoine Tenart
+ * <antoine.tenart@bootlin.com>
+ */
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+
+#define MAX_A38X_COMPHY 6
+#define MAX_A38X_PORTS 3
+
+#define COMPHY_CFG1 0x00
+#define COMPHY_CFG1_GEN_TX(x) ((x) << 26)
+#define COMPHY_CFG1_GEN_TX_MSK COMPHY_CFG1_GEN_TX(15)
+#define COMPHY_CFG1_GEN_RX(x) ((x) << 22)
+#define COMPHY_CFG1_GEN_RX_MSK COMPHY_CFG1_GEN_RX(15)
+#define GEN_SGMII_1_25GBPS 6
+#define GEN_SGMII_3_125GBPS 8
+
+#define COMPHY_STAT1 0x18
+#define COMPHY_STAT1_PLL_RDY_TX BIT(3)
+#define COMPHY_STAT1_PLL_RDY_RX BIT(2)
+
+#define COMPHY_SELECTOR 0xfc
+
+struct a38x_comphy;
+
+struct a38x_comphy_lane {
+ void __iomem *base;
+ struct a38x_comphy *priv;
+ unsigned int n;
+
+ int port;
+};
+
+struct a38x_comphy {
+ void __iomem *base;
+ struct device *dev;
+ struct a38x_comphy_lane lane[MAX_A38X_COMPHY];
+};
+
+static const u8 gbe_mux[MAX_A38X_COMPHY][MAX_A38X_PORTS] = {
+ { 0, 0, 0 },
+ { 4, 5, 0 },
+ { 0, 4, 0 },
+ { 0, 0, 4 },
+ { 0, 3, 0 },
+ { 0, 0, 3 },
+};
+
+static void a38x_comphy_set_reg(struct a38x_comphy_lane *lane,
+ unsigned int offset, u32 mask, u32 value)
+{
+ u32 val;
+
+ val = readl_relaxed(lane->base + offset) & ~mask;
+ writel(val | value, lane->base + offset);
+}
+
+static void a38x_comphy_set_speed(struct a38x_comphy_lane *lane,
+ unsigned int gen_tx, unsigned int gen_rx)
+{
+ a38x_comphy_set_reg(lane, COMPHY_CFG1,
+ COMPHY_CFG1_GEN_TX_MSK | COMPHY_CFG1_GEN_RX_MSK,
+ COMPHY_CFG1_GEN_TX(gen_tx) |
+ COMPHY_CFG1_GEN_RX(gen_rx));
+}
+
+static int a38x_comphy_poll(struct a38x_comphy_lane *lane,
+ unsigned int offset, u32 mask, u32 value)
+{
+ unsigned int timeout = 10;
+ u32 val;
+
+ while (1) {
+ val = readl_relaxed(lane->base + offset);
+ if ((val & mask) == value)
+ return 0;
+ if (!timeout--)
+ break;
+ udelay(10);
+ }
+
+ dev_err(lane->priv->dev, "comphy%u: timed out waiting for status\n",
+ lane->n);
+
+ return -ETIMEDOUT;
+}
+
+/*
+ * We only support changing the speed for comphys configured for GBE.
+ * Since that is all we do, we only poll for PLL ready status.
+ */
+static int a38x_comphy_set_mode(struct phy *phy, enum phy_mode mode)
+{
+ struct a38x_comphy_lane *lane = phy_get_drvdata(phy);
+ unsigned int gen;
+ u32 val;
+
+ val = readl_relaxed(lane->priv->base + COMPHY_SELECTOR);
+ val = (val >> (4 * lane->n)) & 0xf;
+
+ if (!gbe_mux[lane->n][lane->port] ||
+ val != gbe_mux[lane->n][lane->port]) {
+ dev_warn(lane->priv->dev,
+ "comphy%u: not configured for GBE\n", lane->n);
+ return -EINVAL;
+ }
+
+ switch (mode) {
+ case PHY_MODE_SGMII:
+ gen = GEN_SGMII_1_25GBPS;
+ break;
+
+ case PHY_MODE_2500SGMII:
+ gen = GEN_SGMII_3_125GBPS;
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ a38x_comphy_set_speed(lane, gen, gen);
+
+ return a38x_comphy_poll(lane, COMPHY_STAT1,
+ COMPHY_STAT1_PLL_RDY_TX |
+ COMPHY_STAT1_PLL_RDY_RX,
+ COMPHY_STAT1_PLL_RDY_TX |
+ COMPHY_STAT1_PLL_RDY_RX);
+}
+
+static const struct phy_ops a38x_comphy_ops = {
+ .set_mode = a38x_comphy_set_mode,
+ .owner = THIS_MODULE,
+};
+
+static struct phy *a38x_comphy_xlate(struct device *dev,
+ struct of_phandle_args *args)
+{
+ struct a38x_comphy_lane *lane;
+ struct phy *phy;
+
+ if (WARN_ON(args->args[0] >= MAX_A38X_PORTS))
+ return ERR_PTR(-EINVAL);
+
+ phy = of_phy_simple_xlate(dev, args);
+ if (IS_ERR(phy))
+ return phy;
+
+ lane = phy_get_drvdata(phy);
+ if (lane->port >= 0)
+ return ERR_PTR(-EBUSY);
+
+ lane->port = args->args[0];
+
+ return phy;
+}
+
+static int a38x_comphy_probe(struct platform_device *pdev)
+{
+ struct a38x_comphy *priv;
+ struct phy_provider *provider;
+ struct device_node *child;
+ struct resource *res;
+ void __iomem *base;
+
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ priv->dev = &pdev->dev;
+ priv->base = base;
+
+ for_each_available_child_of_node(pdev->dev.of_node, child) {
+ struct phy *phy;
+ int ret;
+ u32 val;
+
+ ret = of_property_read_u32(child, "reg", &val);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "missing 'reg' property (%d)\n",
+ ret);
+ continue;
+ }
+
+ if (val >= MAX_A38X_COMPHY || priv->lane[val].base) {
+ dev_err(&pdev->dev, "invalid 'reg' property\n");
+ continue;
+ }
+
+ phy = devm_phy_create(&pdev->dev, child, &a38x_comphy_ops);
+ if (IS_ERR(phy))
+ return PTR_ERR(phy);
+
+ priv->lane[val].base = base + 0x28 * val;
+ priv->lane[val].priv = priv;
+ priv->lane[val].n = val;
+ priv->lane[val].port = -1;
+ phy_set_drvdata(phy, &priv->lane[val]);
+ }
+
+ dev_set_drvdata(&pdev->dev, priv);
+
+ provider = devm_of_phy_provider_register(&pdev->dev, a38x_comphy_xlate);
+
+ return PTR_ERR_OR_ZERO(provider);
+}
+
+static const struct of_device_id a38x_comphy_of_match_table[] = {
+ { .compatible = "marvell,armada-380-comphy" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, a38x_comphy_of_match_table);
+
+static struct platform_driver a38x_comphy_driver = {
+ .probe = a38x_comphy_probe,
+ .driver = {
+ .name = "armada-38x-comphy",
+ .of_match_table = a38x_comphy_of_match_table,
+ },
+};
+module_platform_driver(a38x_comphy_driver);
+
+MODULE_AUTHOR("Russell King <rmk+kernel@armlinux.org.uk>");
+MODULE_DESCRIPTION("Common PHY driver for Armada 38x SoCs");
+MODULE_LICENSE("GPL v2");
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 3/6] ARM: dts: add description for Armada 38x common phy
From: Russell King @ 2018-11-12 12:30 UTC (permalink / raw)
To: devicetree, linux-arm-kernel, netdev
Cc: Andrew Lunn, Gregory Clement, Jason Cooper,
Kishon Vijay Abraham I, Mark Rutland, Rob Herring,
Sebastian Hesselbarth, Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20181112122933.GD30658@n2100.armlinux.org.uk>
Add the DT description for the Armada 38x common phy.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/boot/dts/armada-38x.dtsi | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi
index 929459c42760..7b2e2bd6479b 100644
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -335,6 +335,43 @@
#clock-cells = <1>;
};
+ comphy: phy@18300 {
+ compatible = "marvell,armada-380-comphy";
+ reg = <0x18300 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ comphy0: phy@0 {
+ reg = <0>;
+ #phy-cells = <1>;
+ };
+
+ comphy1: phy@1 {
+ reg = <1>;
+ #phy-cells = <1>;
+ };
+
+ comphy2: phy@2 {
+ reg = <2>;
+ #phy-cells = <1>;
+ };
+
+ comphy3: phy@3 {
+ reg = <3>;
+ #phy-cells = <1>;
+ };
+
+ comphy4: phy@4 {
+ reg = <4>;
+ #phy-cells = <1>;
+ };
+
+ comphy5: phy@5 {
+ reg = <5>;
+ #phy-cells = <1>;
+ };
+ };
+
coreclk: mvebu-sar@18600 {
compatible = "marvell,armada-380-core-clock";
reg = <0x18600 0x04>;
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 4/6] dt-bindings: update mvneta binding document
From: Russell King @ 2018-11-12 12:31 UTC (permalink / raw)
To: devicetree, linux-arm-kernel, netdev
Cc: Andrew Lunn, Gregory Clement, Jason Cooper,
Kishon Vijay Abraham I, Mark Rutland, Rob Herring,
Sebastian Hesselbarth, Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20181112122933.GD30658@n2100.armlinux.org.uk>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
index bedcfd5a52cd..691f886cfc4a 100644
--- a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
+++ b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
@@ -19,7 +19,7 @@
"marvell,armada-370-neta" and 9800B for others.
- clock-names: List of names corresponding to clocks property; shall be
"core" for core clock and "bus" for the optional bus clock.
-
+- phys: comphy for the ethernet port, see ../phy/phy-bindings.txt
Optional properties (valid only for Armada XP/38x):
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 5/6] net: marvell: neta: add support for 2500base-X
From: Russell King @ 2018-11-12 12:31 UTC (permalink / raw)
To: devicetree, linux-arm-kernel, netdev
Cc: Andrew Lunn, Gregory Clement, Jason Cooper,
Kishon Vijay Abraham I, Mark Rutland, Rob Herring,
Sebastian Hesselbarth, Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20181112122933.GD30658@n2100.armlinux.org.uk>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/marvell/mvneta.c | 58 ++++++++++++++++++++++++++++++-----
1 file changed, 51 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 5bfd349bf41a..7305d4cc0630 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -27,6 +27,7 @@
#include <linux/of_irq.h>
#include <linux/of_mdio.h>
#include <linux/of_net.h>
+#include <linux/phy/phy.h>
#include <linux/phy.h>
#include <linux/phylink.h>
#include <linux/platform_device.h>
@@ -437,6 +438,7 @@ struct mvneta_port {
struct device_node *dn;
unsigned int tx_csum_limit;
struct phylink *phylink;
+ struct phy *comphy;
struct mvneta_bm *bm_priv;
struct mvneta_bm_pool *pool_long;
@@ -3150,6 +3152,8 @@ static void mvneta_start_dev(struct mvneta_port *pp)
{
int cpu;
+ WARN_ON(phy_power_on(pp->comphy));
+
mvneta_max_rx_size_set(pp, pp->pkt_size);
mvneta_txq_max_tx_size_set(pp, pp->pkt_size);
@@ -3212,6 +3216,8 @@ static void mvneta_stop_dev(struct mvneta_port *pp)
mvneta_tx_reset(pp);
mvneta_rx_reset(pp);
+
+ WARN_ON(phy_power_off(pp->comphy));
}
static void mvneta_percpu_enable(void *arg)
@@ -3337,6 +3343,7 @@ static int mvneta_set_mac_addr(struct net_device *dev, void *addr)
static void mvneta_validate(struct net_device *ndev, unsigned long *supported,
struct phylink_link_state *state)
{
+ struct mvneta_port *pp = netdev_priv(ndev);
__ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
/* We only support QSGMII, SGMII, 802.3z and RGMII modes */
@@ -3357,14 +3364,14 @@ static void mvneta_validate(struct net_device *ndev, unsigned long *supported,
/* Asymmetric pause is unsupported */
phylink_set(mask, Pause);
- /* We cannot use 1Gbps when using the 2.5G interface. */
- if (state->interface == PHY_INTERFACE_MODE_2500BASEX) {
- phylink_set(mask, 2500baseT_Full);
- phylink_set(mask, 2500baseX_Full);
- } else {
+ /* Half-duplex at speeds higher than 100Mbit is unsupported */
+ if (pp->comphy || state->interface != PHY_INTERFACE_MODE_2500BASEX) {
phylink_set(mask, 1000baseT_Full);
phylink_set(mask, 1000baseX_Full);
}
+ if (pp->comphy || state->interface == PHY_INTERFACE_MODE_2500BASEX) {
+ phylink_set(mask, 2500baseX_Full);
+ }
if (!phy_interface_mode_is_8023z(state->interface)) {
/* 10M and 100M are only supported in non-802.3z mode */
@@ -3378,6 +3385,11 @@ static void mvneta_validate(struct net_device *ndev, unsigned long *supported,
__ETHTOOL_LINK_MODE_MASK_NBITS);
bitmap_and(state->advertising, state->advertising, mask,
__ETHTOOL_LINK_MODE_MASK_NBITS);
+
+ /* We can only operate at 2500BaseX or 1000BaseX. If requested
+ * to advertise both, only report advertising at 2500BaseX.
+ */
+ phylink_helper_basex_speed(state);
}
static int mvneta_mac_link_state(struct net_device *ndev,
@@ -3389,7 +3401,9 @@ static int mvneta_mac_link_state(struct net_device *ndev,
gmac_stat = mvreg_read(pp, MVNETA_GMAC_STATUS);
if (gmac_stat & MVNETA_GMAC_SPEED_1000)
- state->speed = SPEED_1000;
+ state->speed =
+ state->interface == PHY_INTERFACE_MODE_2500BASEX ?
+ SPEED_2500 : SPEED_1000;
else if (gmac_stat & MVNETA_GMAC_SPEED_100)
state->speed = SPEED_100;
else
@@ -3504,12 +3518,32 @@ static void mvneta_mac_config(struct net_device *ndev, unsigned int mode,
MVNETA_GMAC_FORCE_LINK_DOWN);
}
+
/* When at 2.5G, the link partner can send frames with shortened
* preambles.
*/
if (state->speed == SPEED_2500)
new_ctrl4 |= MVNETA_GMAC4_SHORT_PREAMBLE_ENABLE;
+ if (pp->comphy) {
+ enum phy_mode mode = PHY_MODE_INVALID;
+
+ switch (state->interface) {
+ case PHY_INTERFACE_MODE_SGMII:
+ case PHY_INTERFACE_MODE_1000BASEX:
+ mode = PHY_MODE_SGMII;
+ break;
+ case PHY_INTERFACE_MODE_2500BASEX:
+ mode = PHY_MODE_2500SGMII;
+ break;
+ default:
+ break;
+ }
+
+ if (mode != PHY_MODE_INVALID)
+ WARN_ON(phy_set_mode(pp->comphy, mode));
+ }
+
if (new_ctrl0 != gmac_ctrl0)
mvreg_write(pp, MVNETA_GMAC_CTRL_0, new_ctrl0);
if (new_ctrl2 != gmac_ctrl2)
@@ -4411,7 +4445,7 @@ static int mvneta_port_power_up(struct mvneta_port *pp, int phy_mode)
if (phy_mode == PHY_INTERFACE_MODE_QSGMII)
mvreg_write(pp, MVNETA_SERDES_CFG, MVNETA_QSGMII_SERDES_PROTO);
else if (phy_mode == PHY_INTERFACE_MODE_SGMII ||
- phy_mode == PHY_INTERFACE_MODE_1000BASEX)
+ phy_interface_mode_is_8023z(phy_mode))
mvreg_write(pp, MVNETA_SERDES_CFG, MVNETA_SGMII_SERDES_PROTO);
else if (!phy_interface_mode_is_rgmii(phy_mode))
return -EINVAL;
@@ -4428,6 +4462,7 @@ static int mvneta_probe(struct platform_device *pdev)
struct mvneta_port *pp;
struct net_device *dev;
struct phylink *phylink;
+ struct phy *comphy;
const char *dt_mac_addr;
char hw_mac_addr[ETH_ALEN];
const char *mac_from;
@@ -4453,6 +4488,14 @@ static int mvneta_probe(struct platform_device *pdev)
goto err_free_irq;
}
+ comphy = devm_of_phy_get(&pdev->dev, dn, NULL);
+ if (comphy == ERR_PTR(-EPROBE_DEFER)) {
+ err = -EPROBE_DEFER;
+ goto err_free_irq;
+ } else if (IS_ERR(comphy)) {
+ comphy = NULL;
+ }
+
phylink = phylink_create(dev, pdev->dev.fwnode, phy_mode,
&mvneta_phylink_ops);
if (IS_ERR(phylink)) {
@@ -4469,6 +4512,7 @@ static int mvneta_probe(struct platform_device *pdev)
pp = netdev_priv(dev);
spin_lock_init(&pp->lock);
pp->phylink = phylink;
+ pp->comphy = comphy;
pp->phy_interface = phy_mode;
pp->dn = dn;
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 6/6] ARM: dts: clearfog: add comphy settings for Ethernet interfaces
From: Russell King @ 2018-11-12 12:31 UTC (permalink / raw)
To: devicetree, linux-arm-kernel, netdev
Cc: Andrew Lunn, Gregory Clement, Jason Cooper,
Kishon Vijay Abraham I, Mark Rutland, Rob Herring,
Sebastian Hesselbarth, Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20181112122933.GD30658@n2100.armlinux.org.uk>
Add the comphy settings for the Ethernet interfaces.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/boot/dts/armada-388-clearfog.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dtsi b/arch/arm/boot/dts/armada-388-clearfog.dtsi
index 1b0d0680c8b6..0d81600ca247 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dtsi
+++ b/arch/arm/boot/dts/armada-388-clearfog.dtsi
@@ -93,6 +93,7 @@
bm,pool-long = <2>;
bm,pool-short = <1>;
buffer-manager = <&bm>;
+ phys = <&comphy1 1>;
phy-mode = "sgmii";
status = "okay";
};
@@ -103,6 +104,7 @@
bm,pool-short = <1>;
buffer-manager = <&bm>;
managed = "in-band-status";
+ phys = <&comphy5 2>;
phy-mode = "sgmii";
sfp = <&sfp>;
status = "okay";
--
2.7.4
^ permalink raw reply related
* Which is officially supported by netdev for dynamic routing?
From: Akshat Kakkar @ 2018-11-12 12:32 UTC (permalink / raw)
To: netdev
I can see there are 3 projects for supporting dynamic routing like
ospf in linux namely,
Quagga
FRRouting
BIRD.
However, as a long term perspective, I am eager to know which out of
these is officially supported by netdev community.
^ permalink raw reply
* [PATCH net] rxrpc: Fix life check
From: David Howells @ 2018-11-12 22:33 UTC (permalink / raw)
To: netdev; +Cc: linux-afs, linux-kernel, dhowells
The life-checking function, which is used by kAFS to make sure that a call
is still live in the event of a pending signal, only samples the received
packet serial number counter; it doesn't actually provoke a change in the
counter, rather relying on the server to happen to give us a packet in the
time window.
Fix this by adding a function to force a ping to be transmitted.
kAFS then keeps track of whether there's been a stall, and if so, uses the
new function to ping the server, resetting the timeout to allow the reply
to come back.
If there's a stall, a ping and the call is *still* stalled in the same
place after another period, then the call will be aborted.
Fixes: bc5e3a546d55 ("rxrpc: Use MSG_WAITALL to tell sendmsg() to temporarily ignore signals")
Fixes: f4d15fb6f99a ("rxrpc: Provide functions for allowing cleaner handling of signals")
Signed-off-by: David Howells <dhowells@redhat.com>
---
Documentation/networking/rxrpc.txt | 17 +++++++++++------
fs/afs/rxrpc.c | 11 ++++++++++-
include/net/af_rxrpc.h | 3 ++-
include/trace/events/rxrpc.h | 2 ++
net/rxrpc/af_rxrpc.c | 27 +++++++++++++++++++++++----
5 files changed, 48 insertions(+), 12 deletions(-)
diff --git a/Documentation/networking/rxrpc.txt b/Documentation/networking/rxrpc.txt
index 605e00cdd6be..89f1302d593a 100644
--- a/Documentation/networking/rxrpc.txt
+++ b/Documentation/networking/rxrpc.txt
@@ -1056,18 +1056,23 @@ The kernel interface functions are as follows:
u32 rxrpc_kernel_check_life(struct socket *sock,
struct rxrpc_call *call);
+ void rxrpc_kernel_probe_life(struct socket *sock,
+ struct rxrpc_call *call);
- This returns a number that is updated when ACKs are received from the peer
- (notably including PING RESPONSE ACKs which we can elicit by sending PING
- ACKs to see if the call still exists on the server). The caller should
- compare the numbers of two calls to see if the call is still alive after
- waiting for a suitable interval.
+ The first function returns a number that is updated when ACKs are received
+ from the peer (notably including PING RESPONSE ACKs which we can elicit by
+ sending PING ACKs to see if the call still exists on the server). The
+ caller should compare the numbers of two calls to see if the call is still
+ alive after waiting for a suitable interval.
This allows the caller to work out if the server is still contactable and
if the call is still alive on the server whilst waiting for the server to
process a client operation.
- This function may transmit a PING ACK.
+ The second function causes a ping ACK to be transmitted to try to provoke
+ the peer into responding, which would then cause the value returned by the
+ first function to change. Note that this must be called in TASK_RUNNING
+ state.
(*) Get reply timestamp.
diff --git a/fs/afs/rxrpc.c b/fs/afs/rxrpc.c
index 59970886690f..a7b44863d502 100644
--- a/fs/afs/rxrpc.c
+++ b/fs/afs/rxrpc.c
@@ -576,6 +576,7 @@ static long afs_wait_for_call_to_complete(struct afs_call *call,
{
signed long rtt2, timeout;
long ret;
+ bool stalled = false;
u64 rtt;
u32 life, last_life;
@@ -609,12 +610,20 @@ static long afs_wait_for_call_to_complete(struct afs_call *call,
life = rxrpc_kernel_check_life(call->net->socket, call->rxcall);
if (timeout == 0 &&
- life == last_life && signal_pending(current))
+ life == last_life && signal_pending(current)) {
+ if (stalled)
break;
+ __set_current_state(TASK_RUNNING);
+ rxrpc_kernel_probe_life(call->net->socket, call->rxcall);
+ timeout = rtt2;
+ stalled = true;
+ continue;
+ }
if (life != last_life) {
timeout = rtt2;
last_life = life;
+ stalled = false;
}
timeout = schedule_timeout(timeout);
diff --git a/include/net/af_rxrpc.h b/include/net/af_rxrpc.h
index de587948042a..1adefe42c0a6 100644
--- a/include/net/af_rxrpc.h
+++ b/include/net/af_rxrpc.h
@@ -77,7 +77,8 @@ int rxrpc_kernel_retry_call(struct socket *, struct rxrpc_call *,
struct sockaddr_rxrpc *, struct key *);
int rxrpc_kernel_check_call(struct socket *, struct rxrpc_call *,
enum rxrpc_call_completion *, u32 *);
-u32 rxrpc_kernel_check_life(struct socket *, struct rxrpc_call *);
+u32 rxrpc_kernel_check_life(const struct socket *, const struct rxrpc_call *);
+void rxrpc_kernel_probe_life(struct socket *, struct rxrpc_call *);
u32 rxrpc_kernel_get_epoch(struct socket *, struct rxrpc_call *);
bool rxrpc_kernel_get_reply_time(struct socket *, struct rxrpc_call *,
ktime_t *);
diff --git a/include/trace/events/rxrpc.h b/include/trace/events/rxrpc.h
index 573d5b901fb1..5b50fe4906d2 100644
--- a/include/trace/events/rxrpc.h
+++ b/include/trace/events/rxrpc.h
@@ -181,6 +181,7 @@ enum rxrpc_timer_trace {
enum rxrpc_propose_ack_trace {
rxrpc_propose_ack_client_tx_end,
rxrpc_propose_ack_input_data,
+ rxrpc_propose_ack_ping_for_check_life,
rxrpc_propose_ack_ping_for_keepalive,
rxrpc_propose_ack_ping_for_lost_ack,
rxrpc_propose_ack_ping_for_lost_reply,
@@ -380,6 +381,7 @@ enum rxrpc_tx_point {
#define rxrpc_propose_ack_traces \
EM(rxrpc_propose_ack_client_tx_end, "ClTxEnd") \
EM(rxrpc_propose_ack_input_data, "DataIn ") \
+ EM(rxrpc_propose_ack_ping_for_check_life, "ChkLife") \
EM(rxrpc_propose_ack_ping_for_keepalive, "KeepAlv") \
EM(rxrpc_propose_ack_ping_for_lost_ack, "LostAck") \
EM(rxrpc_propose_ack_ping_for_lost_reply, "LostRpl") \
diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c
index 64362d078da8..a2522f9d71e2 100644
--- a/net/rxrpc/af_rxrpc.c
+++ b/net/rxrpc/af_rxrpc.c
@@ -375,16 +375,35 @@ EXPORT_SYMBOL(rxrpc_kernel_end_call);
* getting ACKs from the server. Returns a number representing the life state
* which can be compared to that returned by a previous call.
*
- * If this is a client call, ping ACKs will be sent to the server to find out
- * whether it's still responsive and whether the call is still alive on the
- * server.
+ * If the life state stalls, rxrpc_kernel_probe_life() should be called and
+ * then 2RTT waited.
*/
-u32 rxrpc_kernel_check_life(struct socket *sock, struct rxrpc_call *call)
+u32 rxrpc_kernel_check_life(const struct socket *sock,
+ const struct rxrpc_call *call)
{
return call->acks_latest;
}
EXPORT_SYMBOL(rxrpc_kernel_check_life);
+/**
+ * rxrpc_kernel_probe_life - Poke the peer to see if it's still alive
+ * @sock: The socket the call is on
+ * @call: The call to check
+ *
+ * In conjunction with rxrpc_kernel_check_life(), allow a kernel service to
+ * find out whether a call is still alive by pinging it. This should cause the
+ * life state to be bumped in about 2*RTT.
+ *
+ * The must be called in TASK_RUNNING state on pain of might_sleep() objecting.
+ */
+void rxrpc_kernel_probe_life(struct socket *sock, struct rxrpc_call *call)
+{
+ rxrpc_propose_ACK(call, RXRPC_ACK_PING, 0, 0, true, false,
+ rxrpc_propose_ack_ping_for_check_life);
+ rxrpc_send_ack_packet(call, true, NULL);
+}
+EXPORT_SYMBOL(rxrpc_kernel_probe_life);
+
/**
* rxrpc_kernel_get_epoch - Retrieve the epoch value from a call.
* @sock: The socket the call is on
^ permalink raw reply related
* Re: [PATCH] geneve: Add missing braces in addr6 initializer
From: Joe Perches @ 2018-11-12 22:36 UTC (permalink / raw)
To: Nathan Chancellor, David S. Miller
Cc: Stefano Brivio, Sabrina Dubroca, netdev, linux-kernel
In-Reply-To: <20181112221248.11477-1-natechancellor@gmail.com>
On Mon, 2018-11-12 at 15:12 -0700, Nathan Chancellor wrote:
> Clang warns:
>
> drivers/net/geneve.c:428:29: error: suggest braces around initialization
> of subobject [-Werror,-Wmissing-braces]
> struct in6_addr addr6 = { 0 };
> ^
> {}
Perhaps just remove the 0.
> diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
[]
> @@ -425,7 +425,7 @@ static int geneve_udp_encap_err_lookup(struct sock *sk, struct sk_buff *skb)
> #if IS_ENABLED(CONFIG_IPV6)
> if (geneve_get_sk_family(gs) == AF_INET6) {
> struct ipv6hdr *ip6h = ipv6_hdr(skb);
> - struct in6_addr addr6 = { 0 };
> + struct in6_addr addr6 = { { 0 } };
>
> if (!gs->collect_md) {
> vni = geneve_hdr(skb)->vni;
^ permalink raw reply
* Re: [PATCH net-next 0/6] net: sched: indirect tc block cb registration
From: Or Gerlitz @ 2018-11-12 13:30 UTC (permalink / raw)
To: Jakub Kicinski, David Miller
Cc: oss-drivers, Linux Netdev List, Jiri Pirko, Cong Wang,
Jamal Hadi Salim, Oz Shlomo, Vlad Buslov
In-Reply-To: <20181111201332.6821bfe1@cakuba.netronome.com>
On Mon, Nov 12, 2018 at 6:13 AM Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
> On Sun, 11 Nov 2018 09:55:35 -0800 (PST), David Miller wrote:
> > From: Jakub Kicinski <jakub.kicinski@netronome.com>
> > Date: Fri, 9 Nov 2018 21:21:25 -0800
> >
> > > John says:
> > >
> > > This patchset introduces an alternative to egdev offload by allowing a
> > > driver to register for block updates when an external device (e.g. tunnel
> > > netdev) is bound to a TC block. Drivers can track new netdevs or register
> > > to existing ones to receive information on such events. Based on this,
> > > they may register for block offload rules using already existing
> > > functions.
> > >
> > > The patchset also implements this new indirect block registration in the
> > > NFP driver to allow the offloading of tunnel rules. The use of egdev
> > > offload (which is currently only used for tunnel offload) is subsequently
> > > removed.
> >
> > Really nice. Series applied.
> >
> > Can the Mellanox folks use this too so that we can remove egdev altogether?
> > mlx5 is the only remaining user.
>
> I believe Or and Oz are working on mlx5 counterpart, hopefully to land
> in this cycle? :)
yeah, Oz is working on that, plumbing the code [..] as we speak, submission
is planned for this cycle.
Or.
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: nixge: Update device-tree bindings with v3.00
From: Alex Williams @ 2018-11-12 23:41 UTC (permalink / raw)
To: robh
Cc: netdev, devicetree, linux-kernel, davem, mark.rutland, mdf,
Kees Cook, Alex C. Williams
In-Reply-To: <5bea0e95.1c69fb81.88799.a282@mx.google.com>
On Mon, Nov 12, 2018 at 3:36 PM Rob Herring <robh@kernel.org> wrote:
>
> On Mon, Oct 29, 2018 at 04:14:47PM -0700, alex.williams@ettus.com wrote:
> > From: Alex Williams <alex.williams@ni.com>
> >
> > Now the DMA engine is free to float elsewhere in the system map.
> >
> > Signed-off-by: Alex Williams <alex.williams@ni.com>
> > ---
> > Documentation/devicetree/bindings/net/nixge.txt | 14 +++++++++++---
> > 1 file changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/net/nixge.txt b/Documentation/devicetree/bindings/net/nixge.txt
> > index e55af7f0881a..d0f9fb520578 100644
> > --- a/Documentation/devicetree/bindings/net/nixge.txt
> > +++ b/Documentation/devicetree/bindings/net/nixge.txt
> > @@ -1,8 +1,14 @@
> > * NI XGE Ethernet controller
> >
> > Required properties:
> > -- compatible: Should be "ni,xge-enet-2.00"
> > -- reg: Address and length of the register set for the device
> > +- compatible: Should be "ni,xge-enet-3.00", but can be "ni,xge-enet-2.00" for
> > + older device trees with DMA engines co-located in the address map,
> > + with the one reg entry to describe the whole device.
> > +- reg: Address and length of the register set for the device. It contains the
> > + information of registers in the same order as described by reg-names.
> > +- reg-names: Should contain the reg names
> > + "dma": DMA engine control and status region
> > + "ctrl": MDIO and PHY control and status region
> > - interrupts: Should contain tx and rx interrupt
> > - interrupt-names: Should be "rx" and "tx"
> > - phy-mode: See ethernet.txt file in the same directory.
> > @@ -13,7 +19,9 @@ Required properties:
> > Examples (10G generic PHY):
> > nixge0: ethernet@40000000 {
> > compatible = "ni,xge-enet-2.00";
>
> Shouldn't the compatible change here?
>
That's an oops... Will fix.
Should I leave the old example for the version 2.00 format and create
another for 3.00?
> > - reg = <0x40000000 0x6000>;
> > + reg = <0x40000000 0x4000
> > + 0x41002000 0x2000>;
> > + reg-names = "dma", "ctrl";
> >
> > nvmem-cells = <ð1_addr>;
> > nvmem-cell-names = "address";
> > --
> > 2.14.5
> >
>
^ permalink raw reply
* Inquiry 12/11/2018
From: Daniel Murray @ 2018-11-12 12:09 UTC (permalink / raw)
To: netdev
Hi,friend,
This is Daniel Murray and i am from Sinara Group Co.Ltd Group Co.,LTD in Russia.
We are glad to know about your company from the web and we are interested in your products.
Could you kindly send us your Latest catalog and price list for our trial order.
Best Regards,
Daniel Murray
Purchasing Manager
^ permalink raw reply
* [PATCH][net-next] net: phy: check if advertising is zero using linkmode_empty
From: Colin King @ 2018-11-12 23:45 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David S . Miller, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
A recent change modified variable advertising from a u32 to a link mode
array and left the u32 zero comparison, so essential we now have an array
being compared to null which is not the intention. Fix this by using the
call to linkmode_empty to check if advertising is all zero.
Detected by CoverityScan, CID#1475424 ("Array compared against 0")
Fixes: 3c1bcc8614db ("net: ethernet: Convert phydev advertize and supported from u32 to link mode")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/phy/phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index d73873334e47..101b83d08864 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -328,7 +328,7 @@ int phy_ethtool_ksettings_set(struct phy_device *phydev,
if (autoneg != AUTONEG_ENABLE && autoneg != AUTONEG_DISABLE)
return -EINVAL;
- if (autoneg == AUTONEG_ENABLE && advertising == 0)
+ if (autoneg == AUTONEG_ENABLE && linkmode_empty(advertising))
return -EINVAL;
if (autoneg == AUTONEG_DISABLE &&
--
2.19.1
^ permalink raw reply related
* Re: [PATCH net-next v6 23/23] net: WireGuard secure network tunnel
From: Jason A. Donenfeld @ 2018-11-12 23:53 UTC (permalink / raw)
To: labokml
Cc: Dave Taht, LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman
In-Reply-To: <e4b500e9-f24a-43c5-c2df-834dafc3aae5@labo.rs>
Hey Ivan,
Sorry for not getting back to you sooner.
On Mon, Nov 5, 2018 at 8:06 AM Ivan Labáth <labokml@labo.rs> wrote:
> Any news on this?
>
> To be clear, question is not about an insignificant documentation
> oversight. It is about copying bits from inner packets to outer packets
The short answer is RFC6040 with DSCP fixed to 0 so as not to leak
anything. I've added a description of this to
<wireguard.com/protocol/>.
Regards,
Jason
^ permalink raw reply
* [PATCH net-next 2/4] net: ethernet: ti: cpts: purge staled skbs from txq
From: Ivan Khoronzhuk @ 2018-11-12 14:00 UTC (permalink / raw)
To: grygorii.strashko, davem
Cc: linux-omap, netdev, linux-kernel, Ivan Khoronzhuk
In-Reply-To: <20181112140023.12407-1-ivan.khoronzhuk@linaro.org>
The overflow event is running with 1 jiffy in case if txq is not
empty, but it can be emptied completely only if next tx event
consumes skb or deletes staled skb from the txq. In case of staled
skb, that can happen for some unpredictable reason (the ts event was
lost or timed out), the overflow event can be generated quite long
time consuming CPU w/o reason before next tx event happens. To avoid
it, purge txq before increasing overflow event rate.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
drivers/net/ethernet/ti/cpts.c | 26 ++++++++++++++++++++++++--
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpts.c b/drivers/net/ethernet/ti/cpts.c
index dac4c528a1ff..63232b35024e 100644
--- a/drivers/net/ethernet/ti/cpts.c
+++ b/drivers/net/ethernet/ti/cpts.c
@@ -86,6 +86,25 @@ static int cpts_purge_events(struct cpts *cpts)
return removed ? 0 : -1;
}
+static void cpts_purge_txq(struct cpts *cpts)
+{
+ struct cpts_skb_cb_data *skb_cb;
+ struct sk_buff *skb, *tmp;
+ int removed = 0;
+
+ skb_queue_walk_safe(&cpts->txq, skb, tmp) {
+ skb_cb = (struct cpts_skb_cb_data *)skb->cb;
+ if (time_after(jiffies, skb_cb->tmo)) {
+ __skb_unlink(skb, &cpts->txq);
+ dev_consume_skb_any(skb);
+ ++removed;
+ }
+ }
+
+ if (removed)
+ dev_dbg(cpts->dev, "txq cleaned up %d\n", removed);
+}
+
static bool cpts_match_tx_ts(struct cpts *cpts, struct cpts_event *event)
{
struct sk_buff *skb, *tmp;
@@ -292,8 +311,11 @@ static long cpts_overflow_check(struct ptp_clock_info *ptp)
spin_lock_irqsave(&cpts->lock, flags);
ts = ns_to_timespec64(timecounter_read(&cpts->tc));
- if (!skb_queue_empty(&cpts->txq))
- delay = CPTS_SKB_TX_WORK_TIMEOUT;
+ if (!skb_queue_empty(&cpts->txq)) {
+ cpts_purge_txq(cpts);
+ if (!skb_queue_empty(&cpts->txq))
+ delay = CPTS_SKB_TX_WORK_TIMEOUT;
+ }
spin_unlock_irqrestore(&cpts->lock, flags);
pr_debug("cpts overflow check at %lld.%09ld\n",
--
2.17.1
^ permalink raw reply related
* BUG: Fatal in exception in interrupt, at nf_conncount_count [regression in 4.19(.1)]
From: Bruno Prémont @ 2018-11-12 14:04 UTC (permalink / raw)
To: Yi-Hung Wei, Florian Westphal, Pablo Neira Ayuso
Cc: David S. Miller, netfilter-devel, coreteam, netdev
Hi,
With linux-4.19.1 I'm seeing regular kernel panics since this night
with uptime of 5 to 30 minutes in between. System is not heavily loaded.
With the following trace (transcribed):
Call Trace:
<IRQ>
nf_conncount_count+0x48c/0x4f0
? nf_ct_ext_add+0x80/0x170
connlimit_mt+0xa1/0x1a0
? ipt_do_table+0x245/0x420
ipt_do_table+0x245/0x420
nf_hook_slow+0x3e/0xb0
ip_local_deliver+0x9a/0xd0
? ip_sublist_rcv_finish+0x60/0x60
ip_rcv+0x8f/0xb0
? ip_rcv_finish_core.isra.17+0x300/0x300
__netif_receive_skb_internal+0x4d/0x70
netif_receive_skb_internal+0x3e/0xd0
napi_gro_receive+0x6a/0x80
receive_buf+0x294/0xe40
? detach_buf+0x63/0x100
virtnet_poll+0xba/0x2f0
net_rx_action+0x137/0x330
__do_softirq+0xd6/0x238
irq_exit+0xc6/0xd0
do_IRQ+0x78/0xd0
common_interrupt+0xf/xf
</IRQ>
RIP: :native_safe_halt+0x2/0x10
Code: f3 c3 65 48 8b 04 25 40 4c 01 00 f0 80 48 02 20 48 8b 00 a8 08 74
8b eb c1 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 fb f4 <c3>
0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 f4 c3 90 90 90 90 90 90
RSP: 0018:ffffc90000073ec8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffdc
RAX: 0000000000000001 RBX: 0000000000000001 RCX: ffff88007db19200
RDX: ffffffff81c30638 RSI: ffff88007db19200 RDI: 0000000000000087
RBP: ffffffff81c670e8 R08: 000001b3fa8aad88 R09: ffff88007c417c00
R10: 000000010000ecef R11: 000000000000a000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
default_idle+0xc/0x20
do_idle+0x1f0/0x220
? do_idle+0x172/0x220
cpu_startup_entry+0x6a/0x70
secondary_startup_64+0xa4/0xb0
---[ end trace a4bf7eecae5cc0ae ]---
RIP: 0010rb_insert_color+0x17/0x190
Code: 4c 89 78 10 e9 72 ff ff ff 49 89 ef e9 27 ff ff ff 66 90 48 8b 17
48 85 d2 0f 84 4d 01 00 00 48 8b 02 a8 01 0f 85 6d 01 00 00 <48>
8b 48 08 49 89 c0 48 39 d1 74 53 48 85 c9 74 09 f6 01 01 0f 84
RSP: 0018:ffff88007db03a58 EFLAGS: 00010246
RAX: 930d659731af356e RBX: ffff88007db03b3c RCX: ffff88005f09c8c0
RDX: ffff8800631c4c00 RSI: ffff88007c4474b0 RDI: ffff88005f09c8a0
RBP: 0000000000000001 R08: ffff8800631c4c00 R09: ffff88005f09c8d0
R10: ffff88007db03bc8 R11: 0000000000000000 R12: ffff88007c4474b0
R13: 0000000000000002 R14: ffff88005f09c8a0 R15: ffff8800631c4c00
FS: 0000000000000000(0000) GS:ffff88007db00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f83d0291018 CR3: 000000007b036000 CR4: 00000000000406a0
Kernel panic - not syncing: Fatal exception in interrupt
That's all I can get from machine's display.
The following commits have touched nf_conncount/connlimit code:
- 33b78aaa4457ce5d531c6a06f461f8d402774cad netfilter: use PTR_ERR_OR_ZERO()
- 5c789e131cbb997a528451564ea4613e812fc718 netfilter: nf_conncount: Add list lock and gc worker, and RCU for init tree search
- 34848d5c896ea1ab4e3c441b9c4fed39928ccbaf netfilter: nf_conncount: Split insert and traversal
- 2ba39118c10ae3a7d3411c073485bba9576684cd netfilter: nf_conncount: Move locking into count_tree()
- 976afca1ceba53df6f4a543014e15d1c7a962571 netfilter: nf_conncount: Early exit in nf_conncount_lookup() and cleanup
- cb2b36f5a97df76f547fcc4ab444a02522fb6c96 netfilter: nf_conncount: Switch to plain list
- 2a406e8ac7c3e7e96b94d6c0765d5a4641970446 netfilter: nf_conncount: Early exit for garbage collection
- 5cd3da4ba2397ef07226ca2aa5094ed21ff8198f Merge ra.kernel.org:/pub/scm/linux/kernel/git/davem/net
It looks like those locking related changes may be the cause.
Bisecting it will be hard as I don't have exact packet stream
triggering the issue and as a production system it's not ideal
to run loops of testing.
(note, system is running under QEMU at a hosting provider)
Regards,
Bruno
^ permalink raw reply
* Re: BUG: Fatal in exception in interrupt, at nf_conncount_count [regression in 4.19(.1)]
From: Florian Westphal @ 2018-11-12 14:10 UTC (permalink / raw)
To: Bruno Prémont
Cc: Yi-Hung Wei, Florian Westphal, Pablo Neira Ayuso, David S. Miller,
netfilter-devel, coreteam, netdev
In-Reply-To: <20181112150406.1bbb7bee@pluto.restena.lu>
Bruno Prémont <bonbons@sysophe.eu> wrote:
> Hi,
>
> With linux-4.19.1 I'm seeing regular kernel panics since this night
> with uptime of 5 to 30 minutes in between. System is not heavily loaded.
[..]
> It looks like those locking related changes may be the cause.
Yes.
> Bisecting it will be hard as I don't have exact packet stream
No need. Can you give these three patches a try?
https://patchwork.ozlabs.org/project/netfilter-devel/list/?series=73972
^ permalink raw reply
* Re: [PATCH net-next v6 23/23] net: WireGuard secure network tunnel
From: Dave Taht @ 2018-11-13 0:10 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: labokml, linux-kernel, Linux Kernel Network Developers,
linux-crypto, David S. Miller, Greg Kroah-Hartman
In-Reply-To: <CAHmME9q8tp3Ch43o3D6zYTVujcjBWLVpNdzVw6RqYqHisd_suQ@mail.gmail.com>
On Mon, Nov 12, 2018 at 3:54 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> Hey Ivan,
>
> Sorry for not getting back to you sooner.
>
> On Mon, Nov 5, 2018 at 8:06 AM Ivan Labáth <labokml@labo.rs> wrote:
> > Any news on this?
> >
> > To be clear, question is not about an insignificant documentation
> > oversight. It is about copying bits from inner packets to outer packets
>
> The short answer is RFC6040 with DSCP fixed to 0 so as not to leak
> anything. I've added a description of this to
> <wireguard.com/protocol/>.
you have a speling error (ECM). :)
side note:
I have to say that wireguard works really well with ecn and non-ecn marked flows
against codel and fq_codel on the bottleneck router.
I'd still rather like it if wireguard focused a bit more on
interleaving multiple flows better
rather than on single stream benchmarks, one day.
In this case, codel is managing things not fq and we could possibly
shave a few ms of induced latency off of it in this particular test series:
http://tun.taht.net/~d/wireguard/rrul_-_comcast_v6.png
vs wireguard (doing it ivp6 over that ipv6)
http://tun.taht.net/~d/wireguard/rrul_-_wireguard.png
That said, I've been deploying wireguard widely in replacement of my
old tinc network particularly on machines that were formerly cpu
bottlenecked
and am insanely pleased with it. what's a few extra ms of latency
between friends?
>
> Regards,
> Jason
--
Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
^ permalink raw reply
* Re: [PATCH net-next v6 23/23] net: WireGuard secure network tunnel
From: Jason A. Donenfeld @ 2018-11-13 0:13 UTC (permalink / raw)
To: Dave Taht
Cc: labokml, LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman
In-Reply-To: <CAA93jw7e61mbbLMoDwshxpWWK+oGUz71pGrsUYVX8uWM-s5Krg@mail.gmail.com>
On Mon, Nov 12, 2018 at 7:10 PM Dave Taht <dave.taht@gmail.com> wrote:
> you have a speling error (ECM). :)
Thanks.
>
> side note:
>
> I have to say that wireguard works really well with ecn and non-ecn marked flows
> against codel and fq_codel on the bottleneck router.
Yup!
> I'd still rather like it if wireguard focused a bit more on
> interleaving multiple flows better
> rather than on single stream benchmarks, one day.
We're working on it, actually. Toke has been running some tests on
some beefy 100gbps hardware he recently acquired, and after v1 lands
we'll probably have a few interesting ideas for this.
Jason
^ 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