* Re: [PATCH net-next] net: dsa: mv88e6xxx: fix shift of FID bits in mv88e6250_g1_vtu_loadpurge()
From: David Miller @ 2019-06-19 14:26 UTC (permalink / raw)
To: rasmus.villemoes
Cc: andrew, vivien.didelot, f.fainelli, Rasmus.Villemoes, netdev,
linux-kernel
In-Reply-To: <20190619100224.11848-1-rasmus.villemoes@prevas.dk>
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Date: Wed, 19 Jun 2019 10:02:38 +0000
> The comment is correct, but the code ends up moving the bits four
> places too far, into the VTUOp field.
>
> Fixes: bec8e5725281 (net: dsa: mv88e6xxx: implement vtu_getnext and vtu_loadpurge for mv88e6250)
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Also applied, thank you.
^ permalink raw reply
* Re: [PATCH net] net: dsa: mv88e6xxx: fix shift of FID bits in mv88e6185_g1_vtu_loadpurge()
From: David Miller @ 2019-06-19 14:24 UTC (permalink / raw)
To: rasmus.villemoes
Cc: andrew, vivien.didelot, f.fainelli, Rasmus.Villemoes, netdev,
linux-kernel
In-Reply-To: <20190619100203.11749-1-rasmus.villemoes@prevas.dk>
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Date: Wed, 19 Jun 2019 10:02:13 +0000
> The comment is correct, but the code ends up moving the bits four
> places too far, into the VTUOp field.
>
> Fixes: 11ea809f1a74 (net: dsa: mv88e6xxx: support 256 databases)
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH v3 07/16] dt-bindings: net: sun4i-mdio: Convert the binding to a schemas
From: Rob Herring @ 2019-06-19 14:19 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, Frank Rowand, David S . Miller, Chen-Yu Tsai,
Maxime Coquelin, Alexandre Torgue, netdev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
devicetree, linux-stm32, Maxime Chevallier, Antoine Ténart,
Andrew Lunn, Florian Fainelli, Heiner Kallweit
In-Reply-To: <36bc43471d12502b3b49169ca16cf1f5de415f95.1560937626.git-series.maxime.ripard@bootlin.com>
On Wed, Jun 19, 2019 at 3:48 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> Switch our Allwinner A10 MDIO controller binding to a YAML schema to enable
> the DT validation.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
>
> ---
>
> Changes from v2:
> - Add the generic MDIO YAML schema
>
> Changes from v1:
> - Add a select statement with the deprecated compatible, and remove it
> from the valid compatibles
> ---
> Documentation/devicetree/bindings/net/allwinner,sun4i-a10-mdio.yaml | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt | 27 ---------------------------
> 2 files changed, 70 insertions(+), 27 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/allwinner,sun4i-a10-mdio.yaml
> delete mode 100644 Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 03/16] dt-bindings: net: Add a YAML schemas for the generic MDIO options
From: Rob Herring @ 2019-06-19 14:17 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, Frank Rowand, David S . Miller, Chen-Yu Tsai,
Maxime Coquelin, Alexandre Torgue, netdev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
devicetree, linux-stm32, Maxime Chevallier, Antoine Ténart,
Andrew Lunn, Florian Fainelli, Heiner Kallweit
In-Reply-To: <89b834af795fa6ad5ba1f04a5a61c54204bf4f96.1560937626.git-series.maxime.ripard@bootlin.com>
On Wed, Jun 19, 2019 at 3:47 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> The MDIO buses have a number of available device tree properties that can
> be used in their device tree node. Add a YAML schemas for those.
>
> Suggested-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
>
> ---
>
> Changes from v2:
> - New patch
> ---
> Documentation/devicetree/bindings/net/mdio.txt | 38 +-------------
> Documentation/devicetree/bindings/net/mdio.yaml | 51 ++++++++++++++++++-
> 2 files changed, 52 insertions(+), 37 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/mdio.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/mdio.txt b/Documentation/devicetree/bindings/net/mdio.txt
> index e3e1603f256c..cf8a0105488e 100644
> --- a/Documentation/devicetree/bindings/net/mdio.txt
> +++ b/Documentation/devicetree/bindings/net/mdio.txt
> @@ -1,37 +1 @@
> -Common MDIO bus properties.
> -
> -These are generic properties that can apply to any MDIO bus.
> -
> -Optional properties:
> -- reset-gpios: One GPIO that control the RESET lines of all PHYs on that MDIO
> - bus.
> -- reset-delay-us: RESET pulse width in microseconds.
> -
> -A list of child nodes, one per device on the bus is expected. These
> -should follow the generic phy.txt, or a device specific binding document.
> -
> -The 'reset-delay-us' indicates the RESET signal pulse width in microseconds and
> -applies to all PHY devices. It must therefore be appropriately determined based
> -on all PHY requirements (maximum value of all per-PHY RESET pulse widths).
> -
> -Example :
> -This example shows these optional properties, plus other properties
> -required for the TI Davinci MDIO driver.
> -
> - davinci_mdio: ethernet@5c030000 {
> - compatible = "ti,davinci_mdio";
> - reg = <0x5c030000 0x1000>;
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
> - reset-delay-us = <2>;
> -
> - ethphy0: ethernet-phy@1 {
> - reg = <1>;
> - };
> -
> - ethphy1: ethernet-phy@3 {
> - reg = <3>;
> - };
> - };
> +This file has moved to mdio.yaml.
> diff --git a/Documentation/devicetree/bindings/net/mdio.yaml b/Documentation/devicetree/bindings/net/mdio.yaml
> new file mode 100644
> index 000000000000..8f4f9d0a2882
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/mdio.yaml
> @@ -0,0 +1,51 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/mdio.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MDIO Bus Generic Binding
> +
> +maintainers:
> + - Andrew Lunn <andrew@lunn.ch>
> + - Florian Fainelli <f.fainelli@gmail.com>
> + - Heiner Kallweit <hkallweit1@gmail.com>
> +
> +description:
> + These are generic properties that can apply to any MDIO bus. Any
> + MDIO bus must have a list of child nodes, one per device on the
> + bus. These should follow the generic ethernet-phy.yaml document, or
> + a device specific binding document.
> +
> +properties:
> + reset-gpios:
> + maxItems: 1
> + description:
> + The phandle and specifier for the GPIO that controls the RESET
> + lines of all PHYs on that MDIO bus.
> +
> + reset-delay-us:
> + description:
> + RESET pulse width in microseconds. It applies to all PHY devices
> + and must therefore be appropriately determined based on all PHY
> + requirements (maximum value of all per-PHY RESET pulse widths).
> +
> +examples:
> + - |
> + davinci_mdio: ethernet@5c030000 {
Shouldn't this be mdio@... ?
> + compatible = "ti,davinci_mdio";
> + reg = <0x5c030000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reset-gpios = <&gpio2 5 1>;
> + reset-delay-us = <2>;
> +
> + ethphy0: ethernet-phy@1 {
Would be good to have some unit-address checks. Could be a follow-up though.
> + reg = <1>;
> + };
> +
> + ethphy1: ethernet-phy@3 {
> + reg = <3>;
> + };
> + };
> --
> git-series 0.9.1
^ permalink raw reply
* [PATCH iproute2 v2 2/2] uapi: update if_link.h
From: Denis Kirjanov @ 2019-06-19 14:14 UTC (permalink / raw)
To: stephen; +Cc: netdev, linux-rdma, dledford, mkubecek, Denis Kirjanov
In-Reply-To: <20190619141414.4242-1-dkirjanov@suse.com>
update if_link.h to commit 75345f888f700c4ab2448287e35d48c760b202e6
("ipoib: show VF broadcast address")
Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
---
include/uapi/linux/if_link.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index bfe7f9e6..5f271d84 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -692,6 +692,7 @@ enum {
IFLA_VF_IB_NODE_GUID, /* VF Infiniband node GUID */
IFLA_VF_IB_PORT_GUID, /* VF Infiniband port GUID */
IFLA_VF_VLAN_LIST, /* nested list of vlans, option for QinQ */
+ IFLA_VF_BROADCAST, /* VF broadcast */
__IFLA_VF_MAX,
};
@@ -702,6 +703,10 @@ struct ifla_vf_mac {
__u8 mac[32]; /* MAX_ADDR_LEN */
};
+struct ifla_vf_broadcast {
+ __u8 broadcast[32];
+};
+
struct ifla_vf_vlan {
__u32 vf;
__u32 vlan; /* 0 - 4095, 0 disables VLAN filter */
--
2.12.3
^ permalink raw reply related
* [PATCH iproute2 v2 1/2] ipaddress: correctly print a VF hw address in the IPoIB case
From: Denis Kirjanov @ 2019-06-19 14:14 UTC (permalink / raw)
To: stephen; +Cc: netdev, linux-rdma, dledford, mkubecek, Denis Kirjanov
Current code assumes that we print Etheret mac and
that doesn't work in IPoIB case with SRIOV-enabled hardware
Before:
11: ib1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast
state UP mode DEFAULT group default qlen 256
link/infiniband
80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd
00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
vf 0 MAC 14:80:00:00:66:fe, spoof checking off, link-state disable,
trust off, query_rss off
...
After:
11: ib1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast
state UP mode DEFAULT group default qlen 256
link/infiniband
80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd
00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
vf 0 link/infiniband
80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd
00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff, spoof
checking off, link-state disable, trust off, query_rss off
v1->v2: updated kernel headers to uapi commit
Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
---
ip/ipaddress.c | 42 +++++++++++++++++++++++++++++++++++++-----
1 file changed, 37 insertions(+), 5 deletions(-)
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index b504200b..13ad76dd 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -26,6 +26,7 @@
#include <linux/netdevice.h>
#include <linux/if_arp.h>
+#include <linux/if_infiniband.h>
#include <linux/sockios.h>
#include <linux/net_namespace.h>
@@ -349,9 +350,10 @@ static void print_af_spec(FILE *fp, struct rtattr *af_spec_attr)
static void print_vf_stats64(FILE *fp, struct rtattr *vfstats);
-static void print_vfinfo(FILE *fp, struct rtattr *vfinfo)
+static void print_vfinfo(struct ifinfomsg *ifi, FILE *fp, struct rtattr *vfinfo)
{
struct ifla_vf_mac *vf_mac;
+ struct ifla_vf_broadcast *vf_broadcast;
struct ifla_vf_tx_rate *vf_tx_rate;
struct rtattr *vf[IFLA_VF_MAX + 1] = {};
@@ -365,13 +367,43 @@ static void print_vfinfo(FILE *fp, struct rtattr *vfinfo)
parse_rtattr_nested(vf, IFLA_VF_MAX, vfinfo);
vf_mac = RTA_DATA(vf[IFLA_VF_MAC]);
+ vf_broadcast = RTA_DATA(vf[IFLA_VF_BROADCAST]);
vf_tx_rate = RTA_DATA(vf[IFLA_VF_TX_RATE]);
print_string(PRINT_FP, NULL, "%s ", _SL_);
print_int(PRINT_ANY, "vf", "vf %d ", vf_mac->vf);
- print_string(PRINT_ANY, "mac", "MAC %s",
- ll_addr_n2a((unsigned char *) &vf_mac->mac,
- ETH_ALEN, 0, b1, sizeof(b1)));
+
+ print_string(PRINT_ANY,
+ "link_type",
+ " link/%s ",
+ ll_type_n2a(ifi->ifi_type, b1, sizeof(b1)));
+
+ print_color_string(PRINT_ANY,
+ COLOR_MAC,
+ "address",
+ "%s",
+ ll_addr_n2a((unsigned char *) &vf_mac->mac,
+ ifi->ifi_type == ARPHRD_ETHER ? ETH_ALEN : INFINIBAND_ALEN,
+ ifi->ifi_type,
+ b1, sizeof(b1)));
+
+ if (vf[IFLA_VF_BROADCAST]) {
+ if (ifi->ifi_flags&IFF_POINTOPOINT) {
+ print_string(PRINT_FP, NULL, " peer ", NULL);
+ print_bool(PRINT_JSON,
+ "link_pointtopoint", NULL, true);
+ } else {
+ print_string(PRINT_FP, NULL, " brd ", NULL);
+ }
+ print_color_string(PRINT_ANY,
+ COLOR_MAC,
+ "broadcast",
+ "%s",
+ ll_addr_n2a((unsigned char *) &vf_broadcast->broadcast,
+ ifi->ifi_type == ARPHRD_ETHER ? ETH_ALEN : INFINIBAND_ALEN,
+ ifi->ifi_type,
+ b1, sizeof(b1)));
+ }
if (vf[IFLA_VF_VLAN_LIST]) {
struct rtattr *i, *vfvlanlist = vf[IFLA_VF_VLAN_LIST];
@@ -1102,7 +1134,7 @@ int print_linkinfo(struct nlmsghdr *n, void *arg)
open_json_array(PRINT_JSON, "vfinfo_list");
for (i = RTA_DATA(vflist); RTA_OK(i, rem); i = RTA_NEXT(i, rem)) {
open_json_object(NULL);
- print_vfinfo(fp, i);
+ print_vfinfo(ifi, fp, i);
close_json_object();
}
close_json_array(PRINT_JSON, NULL);
--
2.12.3
^ permalink raw reply related
* Re: linux-next: build failure after merge of the net-next tree
From: David Miller @ 2019-06-19 14:13 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, ldir, yamada.masahiro
In-Reply-To: <20190619132326.1846345b@canb.auug.org.au>
I've fixed this as follows, thanks:
====================
From 23cdf8752b26d4edbd60a6293bca492d83192d4d Mon Sep 17 00:00:00 2001
From: "David S. Miller" <davem@davemloft.net>
Date: Wed, 19 Jun 2019 10:12:58 -0400
Subject: [PATCH] act_ctinfo: Don't use BIT() in UAPI headers.
Use _BITUL() instead.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/uapi/linux/tc_act/tc_ctinfo.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/tc_act/tc_ctinfo.h b/include/uapi/linux/tc_act/tc_ctinfo.h
index da803e05a89b..32337304fbe5 100644
--- a/include/uapi/linux/tc_act/tc_ctinfo.h
+++ b/include/uapi/linux/tc_act/tc_ctinfo.h
@@ -27,8 +27,8 @@ enum {
#define TCA_CTINFO_MAX (__TCA_CTINFO_MAX - 1)
enum {
- CTINFO_MODE_DSCP = BIT(0),
- CTINFO_MODE_CPMARK = BIT(1)
+ CTINFO_MODE_DSCP = _BITUL(0),
+ CTINFO_MODE_CPMARK = _BITUL(1)
};
#endif
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v3 08/16] dt-bindings: net: stmmac: Convert the binding to a schemas
From: Rob Herring @ 2019-06-19 14:12 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, Frank Rowand, David S . Miller, Chen-Yu Tsai,
Maxime Coquelin, Alexandre Torgue, netdev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
devicetree, linux-stm32, Maxime Chevallier, Antoine Ténart,
Andrew Lunn, Florian Fainelli, Heiner Kallweit
In-Reply-To: <60569c4326437aeb1c13b3da4d00bcf6202e9e6b.1560937626.git-series.maxime.ripard@bootlin.com>
On Wed, Jun 19, 2019 at 3:48 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> Switch the STMMAC / Synopsys DesignWare MAC controller binding to a YAML
> schema to enable the DT validation.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
>
> ---
>
> Changes from v2:
> - Switch to phy-connection-type instead of phy-mode
> - Fix the snps,*pbl properties type
>
> Changes from v1:
> - Restrict snps,tso to only a couple of compatibles
> - Use an enum for the compatibles
> - Add a custom select statement with the compatibles of all the generic
> compatibles, including the deprecated ones. Remove the deprecated ones
> from the valid compatible values to issue a warning when used.
> ---
> Documentation/devicetree/bindings/net/snps,dwmac.yaml | 389 +++++++++++-
> Documentation/devicetree/bindings/net/stmmac.txt | 179 +-----
> 2 files changed, 390 insertions(+), 178 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/snps,dwmac.yaml
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 14/16] ARM: dts: sunxi: Switch from phy-mode to phy-connection-type
From: Andrew Lunn @ 2019-06-19 14:11 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, Rob Herring, Frank Rowand, David S . Miller,
Chen-Yu Tsai, Maxime Coquelin, Alexandre Torgue, netdev,
linux-arm-kernel, devicetree, linux-stm32, Maxime Chevallier,
Antoine Ténart, Florian Fainelli, Heiner Kallweit
In-Reply-To: <50f869f466acb110c5924d7e8a67087fd97106fd.1560937626.git-series.maxime.ripard@bootlin.com>
On Wed, Jun 19, 2019 at 11:47:23AM +0200, Maxime Ripard wrote:
> The phy-mode device tree property has been deprecated in favor of
> phy-connection-type, let's replace it.
Hi Maxime
net/ethernet/stmicro/stmmac/dwmac-mediatek.c: dev_err(plat->dev, "not find phy-mode\n");
net/ethernet/stmicro/stmmac/dwmac-anarion.c: dev_err(&pdev->dev, "Unsupported phy-mode (%d)\n",
net/ethernet/stmicro/stmmac/dwmac-meson8b.c: dev_err(dwmac->dev, "fail to set phy-mode %s\n",
net/ethernet/stmicro/stmmac/dwmac-meson8b.c: dev_err(dwmac->dev, "fail to set phy-mode %s\n",
net/ethernet/stmicro/stmmac/dwmac-meson8b.c: dev_err(dwmac->dev, "unsupported phy-mode %s\n",
net/ethernet/stmicro/stmmac/dwmac-meson8b.c: dev_err(&pdev->dev, "missing phy-mode property\n");
As a follow up patch, you might want to change these error messages.
Andrew
^ permalink raw reply
* Re: [PATCH v3 10/16] dt-bindings: net: sun8i-emac: Convert the binding to a schemas
From: Rob Herring @ 2019-06-19 14:10 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, Frank Rowand, David S . Miller, Chen-Yu Tsai,
Maxime Coquelin, Alexandre Torgue, netdev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
devicetree, linux-stm32, Maxime Chevallier, Antoine Ténart,
Andrew Lunn, Florian Fainelli, Heiner Kallweit
In-Reply-To: <a9c556114ab21793d100f31361da01a579bae84e.1560937626.git-series.maxime.ripard@bootlin.com>
On Wed, Jun 19, 2019 at 3:48 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> Switch our Allwinner H3 EMAC controller binding to a YAML schema to enable
> the DT validation. Since that controller is based on a Synopsys IP, let's
> add the validation to that schemas with a bunch of conditionals.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
>
> ---
>
> Changes from v2:
> - Switch to phy-connection-type instead of phy-mode
> - Change the delay enum to using multipleOf
>
> Changes from v1:
> - Add specific binding document
> ---
> Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml | 321 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 201 +---------------------------------------------
> Documentation/devicetree/bindings/net/snps,dwmac.yaml | 15 +++-
> 3 files changed, 336 insertions(+), 201 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
> delete mode 100644 Documentation/devicetree/bindings/net/dwmac-sun8i.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next 0/8] mlxsw: Implement flower ingress device matching offload
From: David Miller @ 2019-06-19 14:09 UTC (permalink / raw)
To: idosch
Cc: netdev, jiri, jhs, xiyou.wangcong, pablo, ecree, jakub.kicinski,
idosch
In-Reply-To: <20190619064109.849-1-idosch@idosch.org>
From: Ido Schimmel <idosch@idosch.org>
Date: Wed, 19 Jun 2019 09:41:01 +0300
> From: Ido Schimmel <idosch@mellanox.com>
>
> Jiri says:
>
> In case of using shared block, user might find it handy to be able to insert
> filters to match on particular ingress device. This patchset exposes the
> ingress ifindex through flow_dissector and flow_offload so mlxsw can use it to
> push down to HW. See the selftests for examples of usage.
Looks good, series applied.
^ permalink raw reply
* · quick question…
From: Laura @ 2019-06-19 10:59 UTC (permalink / raw)
To: netdev
Hi,
Can you direct me to the owner/decision maker? We’d like to send you
more clients to help you grow your business.
We can deliver to you real time, exclusive and consistent leads of people
looking for your business.
Who would be the right person to call, and what is the best number to reach
them on?
Thank you!
Laura Gevins
^ permalink raw reply
* Re: [PATCH v3 01/16] dt-bindings: net: Add YAML schemas for the generic Ethernet options
From: Andrew Lunn @ 2019-06-19 14:03 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, Rob Herring, Frank Rowand, David S . Miller,
Chen-Yu Tsai, Maxime Coquelin, Alexandre Torgue, netdev,
linux-arm-kernel, devicetree, linux-stm32, Maxime Chevallier,
Antoine Ténart, Florian Fainelli, Heiner Kallweit,
Rob Herring
In-Reply-To: <27aeb33cf5b896900d5d11bd6957eda268014f0c.1560937626.git-series.maxime.ripard@bootlin.com>
Hi Maxime
> + phy-connection-type:
> + description:
> + Operation mode of the PHY interface
> + enum:
> + # There is not a standard bus between the MAC and the PHY,
> + # something proprietary is being used to embed the PHY in the
> + # MAC.
...
> +
> + phy-mode:
> + $ref: "#/properties/phy-connection-type"
> + deprecated: true
I don't think phy-mode is actually deprecated. ethernet.txt actually says:
"This is now a de-facto standard property;" and no mentions that is
should not be used. Looking at actual device trees, phy-mode is by far
more popular than phy-connection-type.
fwnode_get_phy_mode() first looks for phy-mode and only falls back to
phy-connection-type if it is not present. The same is true for
of_get_phy_mode().
> + fixed-link:
> + allOf:
> + - if:
> + type: array
> + then:
> + minItems: 1
> + maxItems: 1
> + items:
> + items:
> + - minimum: 0
> + maximum: 31
> + description:
> + Emulated PHY ID, choose any but unique to the all
> + specified fixed-links
> +
> + - enum: [0, 1]
> + description:
> + Duplex configuration. 0 for half duplex or 1 for
> + full duplex
> +
> + - enum: [10, 100, 1000]
> + description:
> + Link speed in Mbits/sec.
> +
> + - enum: [0, 1]
> + description:
> + Pause configuration. 0 for no pause, 1 for pause
> +
> + - enum: [0, 1]
> + description:
> + Asymmetric pause configuration. 0 for no asymmetric
> + pause, 1 for asymmetric pause
> +
This array of 5 values format should be marked as deprecated.
> +
> + - if:
> + type: object
> + then:
> + properties:
> + speed:
> + allOf:
> + - $ref: /schemas/types.yaml#definitions/uint32
> + - enum: [10, 100, 1000]
This recently changed, depending on context. If PHYLINK is being used,
any speed is allowed. If phylib is used, then only these speeds are
allowed. And we are starting to see some speeds other than listed
here.
Andrew
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: David Miller @ 2019-06-19 13:46 UTC (permalink / raw)
To: yamada.masahiro; +Cc: sfr, netdev, linux-next, linux-kernel, ldir
In-Reply-To: <CAK7LNARVfXySZK_Wzmww=UeFwpWu+vjbctK33zX9KW8w_adexw@mail.gmail.com>
From: Masahiro Yamada <yamada.masahiro@socionext.com>
Date: Wed, 19 Jun 2019 13:14:06 +0900
> What a hell.
I know, some serious bush league coding going on in the networking
right?
^ permalink raw reply
* Re: [PATCH] mlxsw: spectrum_ptp: fix 32-bit build
From: Ido Schimmel @ 2019-06-19 13:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jiri Pirko, Ido Schimmel, David S. Miller, Shalom Toledo,
Petr Machata, netdev, linux-kernel
In-Reply-To: <20190619133128.2259960-1-arnd@arndb.de>
On Wed, Jun 19, 2019 at 03:31:20PM +0200, Arnd Bergmann wrote:
> On 32-bit architectures, we cannot easily device 64-bit numbers:
>
> ERROR: "__aeabi_uldivmod" [drivers/net/ethernet/mellanox/mlxsw/mlxsw_spectrum.ko] undefined!
>
> Use do_div() to annotate the fact that we know this is an
> expensive operation.
>
> Fixes: 992aa864dca0 ("mlxsw: spectrum_ptp: Add implementation for physical hardware clock operations")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Arnd, thanks for the patch. We already patched this issue yesterday:
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=cd4bb2a3344cb53d9234cca232edfb2dce0f0a35
^ permalink raw reply
* [PATCH] ppp: mppe: Add softdep to arc4
From: Takashi Iwai @ 2019-06-19 13:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: David S . Miller, linux-ppp, netdev
The arc4 crypto is mandatory at ppp_mppe probe time, so let's put a
softdep line, so that the corresponding module gets prepared
gracefully. Without this, a simple inclusion to initrd via dracut
failed due to the missing dependency, for example.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
drivers/net/ppp/ppp_mppe.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ppp/ppp_mppe.c b/drivers/net/ppp/ppp_mppe.c
index ff61dd8748de..66c8e65f6872 100644
--- a/drivers/net/ppp/ppp_mppe.c
+++ b/drivers/net/ppp/ppp_mppe.c
@@ -63,6 +63,7 @@ MODULE_AUTHOR("Frank Cusack <fcusack@fcusack.com>");
MODULE_DESCRIPTION("Point-to-Point Protocol Microsoft Point-to-Point Encryption support");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_ALIAS("ppp-compress-" __stringify(CI_MPPE));
+MODULE_SOFTDEP("pre: arc4");
MODULE_VERSION("1.0.2");
static unsigned int
--
2.16.4
^ permalink raw reply related
* [PATCH] mlxsw: spectrum_ptp: fix 32-bit build
From: Arnd Bergmann @ 2019-06-19 13:31 UTC (permalink / raw)
To: Jiri Pirko, Ido Schimmel, David S. Miller
Cc: Arnd Bergmann, Shalom Toledo, Petr Machata, netdev, linux-kernel
On 32-bit architectures, we cannot easily device 64-bit numbers:
ERROR: "__aeabi_uldivmod" [drivers/net/ethernet/mellanox/mlxsw/mlxsw_spectrum.ko] undefined!
Use do_div() to annotate the fact that we know this is an
expensive operation.
Fixes: 992aa864dca0 ("mlxsw: spectrum_ptp: Add implementation for physical hardware clock operations")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c
index 2a9bbc90225e..618e329e1490 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c
@@ -87,7 +87,7 @@ mlxsw_sp1_ptp_phc_settime(struct mlxsw_sp_ptp_clock *clock, u64 nsec)
u32 next_sec;
int err;
- next_sec = nsec / NSEC_PER_SEC + 1;
+ next_sec = div_u64(nsec, NSEC_PER_SEC) + 1;
next_sec_in_nsec = next_sec * NSEC_PER_SEC;
spin_lock(&clock->lock);
--
2.20.0
^ permalink raw reply related
* [PATCH] netfilter: synproxy: fix building syncookie calls
From: Arnd Bergmann @ 2019-06-19 12:54 UTC (permalink / raw)
To: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI
Cc: Arnd Bergmann, Fernando Fernandez Mancera, wenxu, netfilter-devel,
coreteam, linux-kernel, netdev
When either CONFIG_IPV6 or CONFIG_SYN_COOKIES are disabled, the kernel
fails to build:
include/linux/netfilter_ipv6.h:180:9: error: implicit declaration of function '__cookie_v6_init_sequence'
[-Werror,-Wimplicit-function-declaration]
return __cookie_v6_init_sequence(iph, th, mssp);
include/linux/netfilter_ipv6.h:194:9: error: implicit declaration of function '__cookie_v6_check'
[-Werror,-Wimplicit-function-declaration]
return __cookie_v6_check(iph, th, cookie);
net/ipv6/netfilter.c:237:26: error: use of undeclared identifier '__cookie_v6_init_sequence'; did you mean 'cookie_init_sequence'?
net/ipv6/netfilter.c:238:21: error: use of undeclared identifier '__cookie_v6_check'; did you mean '__cookie_v4_check'?
Fix the IS_ENABLED() checks to match the function declaration
and definitions for these.
Fixes: 3006a5224f15 ("netfilter: synproxy: remove module dependency on IPv6 SYNPROXY")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/linux/netfilter_ipv6.h | 14 ++++++++------
net/ipv6/netfilter.c | 2 ++
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/include/linux/netfilter_ipv6.h b/include/linux/netfilter_ipv6.h
index 1aa3a23744df..7beb681e1ce5 100644
--- a/include/linux/netfilter_ipv6.h
+++ b/include/linux/netfilter_ipv6.h
@@ -171,31 +171,33 @@ static inline u32 nf_ipv6_cookie_init_sequence(const struct ipv6hdr *iph,
const struct tcphdr *th,
u16 *mssp)
{
+#if IS_ENABLED(CONFIG_SYN_COOKIES)
#if IS_MODULE(CONFIG_IPV6)
const struct nf_ipv6_ops *v6_ops = nf_get_ipv6_ops();
if (v6_ops)
return v6_ops->cookie_init_sequence(iph, th, mssp);
-
- return 0;
-#else
+#elif IS_BUILTIN(CONFIG_IPV6)
return __cookie_v6_init_sequence(iph, th, mssp);
#endif
+#endif
+ return 0;
}
static inline int nf_cookie_v6_check(const struct ipv6hdr *iph,
const struct tcphdr *th, __u32 cookie)
{
+#if IS_ENABLED(CONFIG_SYN_COOKIES)
#if IS_MODULE(CONFIG_IPV6)
const struct nf_ipv6_ops *v6_ops = nf_get_ipv6_ops();
if (v6_ops)
return v6_ops->cookie_v6_check(iph, th, cookie);
-
- return 0;
-#else
+#elif IS_BUILTIN(CONFIG_IPV6)
return __cookie_v6_check(iph, th, cookie);
#endif
+#endif
+ return 0;
}
__sum16 nf_ip6_checksum(struct sk_buff *skb, unsigned int hook,
diff --git a/net/ipv6/netfilter.c b/net/ipv6/netfilter.c
index dffb10fdc3e8..61819ed858b1 100644
--- a/net/ipv6/netfilter.c
+++ b/net/ipv6/netfilter.c
@@ -234,8 +234,10 @@ static const struct nf_ipv6_ops ipv6ops = {
.route_me_harder = ip6_route_me_harder,
.dev_get_saddr = ipv6_dev_get_saddr,
.route = __nf_ip6_route,
+#if IS_ENABLED(CONFIG_SYN_COOKIES)
.cookie_init_sequence = __cookie_v6_init_sequence,
.cookie_v6_check = __cookie_v6_check,
+#endif
#endif
.route_input = ip6_route_input,
.fragment = ip6_fragment,
--
2.20.0
^ permalink raw reply related
* [PATCH] netfilter: synproxy: fix nf_synproxy_ipv{4,6}_init() return code
From: Arnd Bergmann @ 2019-06-19 12:53 UTC (permalink / raw)
To: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
David S. Miller
Cc: Arnd Bergmann, Fernando Fernandez Mancera, netfilter-devel,
coreteam, netdev, linux-kernel
We return an uninitialized variable on success:
net/netfilter/nf_synproxy_core.c:793:6: error: variable 'err' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
if (snet->hook_ref4 == 0) {
^~~~~~~~~~~~~~~~~~~~
Initialize the return code to zero first.
Fixes: d7f9b2f18eae ("netfilter: synproxy: extract SYNPROXY infrastructure from {ipt, ip6t}_SYNPROXY")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
net/netfilter/nf_synproxy_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/nf_synproxy_core.c b/net/netfilter/nf_synproxy_core.c
index 50677285f82e..283686e972a0 100644
--- a/net/netfilter/nf_synproxy_core.c
+++ b/net/netfilter/nf_synproxy_core.c
@@ -788,7 +788,7 @@ static const struct nf_hook_ops ipv4_synproxy_ops[] = {
int nf_synproxy_ipv4_init(struct synproxy_net *snet, struct net *net)
{
- int err;
+ int err = 0;
if (snet->hook_ref4 == 0) {
err = nf_register_net_hooks(net, ipv4_synproxy_ops,
@@ -1213,7 +1213,7 @@ static const struct nf_hook_ops ipv6_synproxy_ops[] = {
int
nf_synproxy_ipv6_init(struct synproxy_net *snet, struct net *net)
{
- int err;
+ int err = 0;
if (snet->hook_ref6 == 0) {
err = nf_register_net_hooks(net, ipv6_synproxy_ops,
--
2.20.0
^ permalink raw reply related
* Re: [PATCH mlx5-next 05/15] net/mlx5: E-Switch, Tag packet with vport number in VF vports and uplink ingress ACLs
From: Jianbo Liu @ 2019-06-19 12:52 UTC (permalink / raw)
To: Parav Pandit
Cc: Saeed Mahameed, Leon Romanovsky, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, Eli Britstein, Roi Dayan, Mark Bloch
In-Reply-To: <AM0PR05MB48664868E0B89E582807830BD1EA0@AM0PR05MB4866.eurprd05.prod.outlook.com>
The 06/18/2019 18:31, Parav Pandit wrote:
>
>
> > -----Original Message-----
> > From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On
> > Behalf Of Saeed Mahameed
> > Sent: Tuesday, June 18, 2019 12:53 AM
> > To: Saeed Mahameed <saeedm@mellanox.com>; Leon Romanovsky
> > <leonro@mellanox.com>
> > Cc: netdev@vger.kernel.org; linux-rdma@vger.kernel.org; Jianbo Liu
> > <jianbol@mellanox.com>; Eli Britstein <elibr@mellanox.com>; Roi Dayan
> > <roid@mellanox.com>; Mark Bloch <markb@mellanox.com>
> > Subject: [PATCH mlx5-next 05/15] net/mlx5: E-Switch, Tag packet with vport
> > number in VF vports and uplink ingress ACLs
> >
> > From: Jianbo Liu <jianbol@mellanox.com>
> >
> > When a dual-port VHCA sends a RoCE packet on its non-native port, and the
> > packet arrives to its affiliated vport FDB, a mismatch might occur on the rules
> > that match the packet source vport as it is not represented by single VHCA only
> > in this case. So we change to match on metadata instead of source vport.
> > To do that, a rule is created in all vports and uplink ingress ACLs, to save the
> > source vport number and vhca id in the packet's metadata in order to match on
> > it later.
> > The metadata register used is the first of the 32-bit type C registers. It can be
> > used for matching and header modify operations. The higher 16 bits of this
> > register are for vhca id, and the lower 16 ones is for vport number.
> > This change is not for dual-port RoCE only. If HW and FW allow, the vport
> > metadata matching is enabled by default.
> >
> > Signed-off-by: Jianbo Liu <jianbol@mellanox.com>
> > Reviewed-by: Eli Britstein <elibr@mellanox.com>
> > Reviewed-by: Roi Dayan <roid@mellanox.com>
> > Reviewed-by: Mark Bloch <markb@mellanox.com>
> > Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
> > ---
> > .../net/ethernet/mellanox/mlx5/core/eswitch.c | 2 +
> > .../net/ethernet/mellanox/mlx5/core/eswitch.h | 9 +
> > .../mellanox/mlx5/core/eswitch_offloads.c | 183 ++++++++++++++----
> > include/linux/mlx5/eswitch.h | 3 +
> > 4 files changed, 161 insertions(+), 36 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> > b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> > index a42a23e505df..1235fd84ae3a 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
...
> > + err = esw_vport_egress_prio_tag_config(esw, vport);
> > + if (err)
> > + goto err_egress;
> > + }
> > }
> >
> > + if (mlx5_eswitch_vport_match_metadata_enabled(esw))
> > + esw_info(esw->dev, "Use metadata reg_c as source vport to
> > match\n");
> > +
> > return 0;
> >
> > err_egress:
> > esw_vport_disable_ingress_acl(esw, vport);
> > err_ingress:
> > - mlx5_esw_for_each_vf_vport_reverse(esw, j, vport, i - 1) {
> > + for (j = MLX5_VPORT_PF; j < i; j++) {
> Keep the reverse order as before.
The vports are independent from each other. It doesn't matter disabling
them in or out of order. I don't understand what's the benifit.
>
> > + vport = &esw->vports[j];
> > esw_vport_disable_egress_acl(esw, vport);
> > esw_vport_disable_ingress_acl(esw, vport);
> > }
> > @@ -1704,15 +1800,17 @@ static int esw_prio_tag_acls_config(struct
> > mlx5_eswitch *esw, int nvports)
> > return err;
> > }
> >
> > -static void esw_prio_tag_acls_cleanup(struct mlx5_eswitch *esw)
> > +static void esw_destroy_offloads_acl_tables(struct mlx5_eswitch *esw)
> > {
> > struct mlx5_vport *vport;
> > int i;
> >
> > - mlx5_esw_for_each_vf_vport(esw, i, vport, esw->nvports) {
> > + mlx5_esw_for_all_vports(esw, i, vport) {
> If you are changing this, please do in reverse order to keep it exact mirror of create/enable sequence.
Same...
>
> > esw_vport_disable_egress_acl(esw, vport);
> > esw_vport_disable_ingress_acl(esw, vport);
> > }
> > +
> > + esw->flags &= ~MLX5_ESWITCH_VPORT_MATCH_METADATA;
> > }
> >
> > static int esw_offloads_steering_init(struct mlx5_eswitch *esw, int nvports)
^ permalink raw reply
* Re: [RFC net-next 1/5] net: stmmac: introduce IEEE 802.1Qbv configuration functionalities
From: Andrew Lunn @ 2019-06-19 12:44 UTC (permalink / raw)
To: Voon, Weifeng
Cc: David S. Miller, Maxime Coquelin, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Jose Abreu, Giuseppe Cavallaro,
Florian Fainelli, Alexandre Torgue, Gomes, Vinicius,
Ong, Boon Leong
In-Reply-To: <D6759987A7968C4889FDA6FA91D5CBC81472623A@PGSMSX103.gar.corp.intel.com>
> > It looks like most o the TSN_WARN should actually be netdev_dbg().
> >
> > Andrew
>
> Hi Andrew,
> This file is targeted for dual licensing which is GPL-2.0 OR BSD-3-Clause.
> This is the reason why we are using wrappers around the functions so that
> all the function call is generic.
I don't see why dual licenses should require wrappers. Please explain.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH v2 net] be2net: fix link failure after ethtool offline test
From: Ivan Vecera @ 2019-06-19 12:33 UTC (permalink / raw)
To: Petr Oros
Cc: netdev, sathya.perla, ajit.khaparde, sriharsha.basavapatna,
somnath.kotur, davem, linux-kernel
In-Reply-To: <20190619122942.15497-1-poros@redhat.com>
On Wed, 19 Jun 2019 14:29:42 +0200
Petr Oros <poros@redhat.com> wrote:
> Certain cards in conjunction with certain switches need a little more
> time for link setup that results in ethtool link test failure after
> offline test. Patch adds a loop that waits for a link setup finish.
>
> Changes in v2:
> - added fixes header
>
> Fixes: 4276e47e2d1c ("be2net: Add link test to list of ethtool self
> tests.") Signed-off-by: Petr Oros <poros@redhat.com>
> ---
> .../net/ethernet/emulex/benet/be_ethtool.c | 28
> +++++++++++++++---- 1 file changed, 22 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/emulex/benet/be_ethtool.c
> b/drivers/net/ethernet/emulex/benet/be_ethtool.c index
> 8a6785173228f3..492f8769ac12c2 100644 ---
> a/drivers/net/ethernet/emulex/benet/be_ethtool.c +++
> b/drivers/net/ethernet/emulex/benet/be_ethtool.c @@ -891,7 +891,7 @@
> static void be_self_test(struct net_device *netdev, struct
> ethtool_test *test, u64 *data) {
> struct be_adapter *adapter = netdev_priv(netdev);
> - int status;
> + int status, cnt;
> u8 link_status = 0;
>
> if (adapter->function_caps & BE_FUNCTION_CAPS_SUPER_NIC) {
> @@ -902,6 +902,9 @@ static void be_self_test(struct net_device
> *netdev, struct ethtool_test *test,
> memset(data, 0, sizeof(u64) * ETHTOOL_TESTS_NUM);
>
> + /* check link status before offline tests */
> + link_status = netif_carrier_ok(netdev);
> +
> if (test->flags & ETH_TEST_FL_OFFLINE) {
> if (be_loopback_test(adapter, BE_MAC_LOOPBACK,
> &data[0]) != 0) test->flags |= ETH_TEST_FL_FAILED;
> @@ -922,13 +925,26 @@ static void be_self_test(struct net_device
> *netdev, struct ethtool_test *test, test->flags |= ETH_TEST_FL_FAILED;
> }
>
> - status = be_cmd_link_status_query(adapter, NULL,
> &link_status, 0);
> - if (status) {
> - test->flags |= ETH_TEST_FL_FAILED;
> - data[4] = -1;
> - } else if (!link_status) {
> + /* link status was down prior to test */
> + if (!link_status) {
> test->flags |= ETH_TEST_FL_FAILED;
> data[4] = 1;
> + return;
> + }
> +
> + for (cnt = 10; cnt; cnt--) {
> + status = be_cmd_link_status_query(adapter, NULL,
> &link_status,
> + 0);
> + if (status) {
> + test->flags |= ETH_TEST_FL_FAILED;
> + data[4] = -1;
> + break;
> + }
> +
> + if (link_status)
> + break;
> +
> + msleep_interruptible(500);
> }
> }
>
LGTM
Reviewed-by: Ivan Vecera <ivecera@redhat.com>
^ permalink raw reply
* Re: [PATCH v2 2/5] net: macb: add support for sgmii MAC-PHY interface
From: Russell King - ARM Linux admin @ 2019-06-19 12:32 UTC (permalink / raw)
To: Parshuram Raju Thombare
Cc: andrew@lunn.ch, nicolas.ferre@microchip.com, davem@davemloft.net,
f.fainelli@gmail.com, netdev@vger.kernel.org,
hkallweit1@gmail.com, linux-kernel@vger.kernel.org,
Rafal Ciepiela, Anil Joy Varughese, Piotr Sroka
In-Reply-To: <CO2PR07MB24695C706292A16D71322DB5C1E50@CO2PR07MB2469.namprd07.prod.outlook.com>
On Wed, Jun 19, 2019 at 11:23:01AM +0000, Parshuram Raju Thombare wrote:
> >From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> >
> >On Wed, Jun 19, 2019 at 09:40:46AM +0100, Parshuram Thombare wrote:
> >
> >> This patch add support for SGMII interface) and
> >
> >> 2.5Gbps MAC in Cadence ethernet controller driver.
>
> >> switch (state->interface) {
> >
> >> + case PHY_INTERFACE_MODE_SGMII:
> >
> >> + if (bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE)
> >
> >> + phylink_set(mask, 2500baseT_Full);
> >
> >
> >
> >This doesn't look correct to me. SGMII as defined by Cisco only
> >supports 1G, 100M and 10M speeds, not 2.5G.
>
> Cadence MAC support 2.5G SGMII by using higher clock frequency.
Ok, so why not set 2.5GBASE-X too? Does the MAC handle auto-detecting
the SGMII/BASE-X speed itself or does it need to be programmed? If it
needs to be programmed, you need additional handling in the validate
callback to deal with that.
> >> + case PHY_INTERFACE_MODE_2500BASEX:
> >
> >> + if (bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE)
> >
> >> + phylink_set(mask, 2500baseX_Full);
> >
> >> + /* fallthrough */
> >
> >> + case PHY_INTERFACE_MODE_1000BASEX:
> >
> >> + if (bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE)
> >
> >> + phylink_set(mask, 1000baseX_Full);
> >
> >> + break;
> >
> >
> >
> >Please see how other drivers which use phylink deal with the validate()
> >format, and please read the phylink documentation:
> >
> > * Note that the PHY may be able to transform from one connection
> > * technology to another, so, eg, don't clear 1000BaseX just
> > * because the MAC is unable to BaseX mode. This is more about
> > * clearing unsupported speeds and duplex settings.
> >
>
> There are some configs used in this driver which limits MAC speed.
> Above checks just to make sure this use case does not break.
That's not what I'm saying.
By way of example, you're offering 1000BASE-T just because the MAC
connection supports it. However, the MAC doesn't _actually_ support
1000BASE-T, it supports a connection to a PHY that _happens_ to
convert the MAC connection to 1000BASE-T. It could equally well
convert the MAC connection to 1000BASE-X.
So, only setting 1000BASE-X when you have a PHY connection using
1000BASE-X is fundamentally incorrect.
For example, you could have a MAC <-> PHY link using standard 1.25Gbps
SGMII, and the PHY offers 1000BASE-T _and_ 1000BASE-X connections on
a first-link-up basis. An example of a PHY that does this are the
Marvell 1G PHYs (eg, 88E151x).
This point is detailed in the PHYLINK documentation, which I quoted
above.
> >> @@ -506,18 +563,26 @@ static void gem_mac_config(struct phylink_config
> >*pl_config, unsigned int mode,
> >> switch (state->speed) {
> >> + case SPEED_2500:
> >> + gem_writel(bp, NCFGR, GEM_BIT(GBE) |
> >> + gem_readl(bp, NCFGR));
> >> }
> >> - macb_or_gem_writel(bp, NCFGR, reg);
> >>
> >> bp->speed = state->speed;
> >> bp->duplex = state->duplex;
> >
> >
> >
> >This is not going to work for 802.3z nor SGMII properly when in-band
> >negotiation is used. We don't know ahead of time what the speed and
> >duplex will be. Please see existing drivers for examples showing
> >how mac_config() should be implemented (there's good reason why its
> >laid out as it is in those drivers.)
> >
> Ok, Here I will configure MAC only for FIXED and PHY mode.
As you are not the only one who has made this error, I'm considering
splitting mac_config() into mac_config_fixed() and mac_config_inband()
so that it's clearer what is required. Maybe even taking separate
structures so that it's impossible to access members that should not
be used.
--
RMK's Patch system: https://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
* [PATCH v2 net] be2net: fix link failure after ethtool offline test
From: Petr Oros @ 2019-06-19 12:29 UTC (permalink / raw)
To: netdev
Cc: sathya.perla, ajit.khaparde, sriharsha.basavapatna, somnath.kotur,
davem, linux-kernel, ivecera
Certain cards in conjunction with certain switches need a little more
time for link setup that results in ethtool link test failure after
offline test. Patch adds a loop that waits for a link setup finish.
Changes in v2:
- added fixes header
Fixes: 4276e47e2d1c ("be2net: Add link test to list of ethtool self tests.")
Signed-off-by: Petr Oros <poros@redhat.com>
---
.../net/ethernet/emulex/benet/be_ethtool.c | 28 +++++++++++++++----
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_ethtool.c b/drivers/net/ethernet/emulex/benet/be_ethtool.c
index 8a6785173228f3..492f8769ac12c2 100644
--- a/drivers/net/ethernet/emulex/benet/be_ethtool.c
+++ b/drivers/net/ethernet/emulex/benet/be_ethtool.c
@@ -891,7 +891,7 @@ static void be_self_test(struct net_device *netdev, struct ethtool_test *test,
u64 *data)
{
struct be_adapter *adapter = netdev_priv(netdev);
- int status;
+ int status, cnt;
u8 link_status = 0;
if (adapter->function_caps & BE_FUNCTION_CAPS_SUPER_NIC) {
@@ -902,6 +902,9 @@ static void be_self_test(struct net_device *netdev, struct ethtool_test *test,
memset(data, 0, sizeof(u64) * ETHTOOL_TESTS_NUM);
+ /* check link status before offline tests */
+ link_status = netif_carrier_ok(netdev);
+
if (test->flags & ETH_TEST_FL_OFFLINE) {
if (be_loopback_test(adapter, BE_MAC_LOOPBACK, &data[0]) != 0)
test->flags |= ETH_TEST_FL_FAILED;
@@ -922,13 +925,26 @@ static void be_self_test(struct net_device *netdev, struct ethtool_test *test,
test->flags |= ETH_TEST_FL_FAILED;
}
- status = be_cmd_link_status_query(adapter, NULL, &link_status, 0);
- if (status) {
- test->flags |= ETH_TEST_FL_FAILED;
- data[4] = -1;
- } else if (!link_status) {
+ /* link status was down prior to test */
+ if (!link_status) {
test->flags |= ETH_TEST_FL_FAILED;
data[4] = 1;
+ return;
+ }
+
+ for (cnt = 10; cnt; cnt--) {
+ status = be_cmd_link_status_query(adapter, NULL, &link_status,
+ 0);
+ if (status) {
+ test->flags |= ETH_TEST_FL_FAILED;
+ data[4] = -1;
+ break;
+ }
+
+ if (link_status)
+ break;
+
+ msleep_interruptible(500);
}
}
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver
From: Arnd Bergmann @ 2019-06-19 12:23 UTC (permalink / raw)
To: Subash Abhinov Kasiviswanathan
Cc: Johannes Berg, Alex Elder, abhishek.esse, Ben Chan,
Bjorn Andersson, cpratapa, David Miller, Dan Williams, DTML,
Eric Caruso, evgreen, Ilias Apalodimas, Linux ARM, linux-arm-msm,
Linux Kernel Mailing List, linux-soc, Networking, syadagir
In-Reply-To: <6c70950d0c78bc02a3d016918ec3929e@codeaurora.org>
On Tue, Jun 18, 2019 at 11:15 PM Subash Abhinov Kasiviswanathan
<subashab@codeaurora.org> wrote:
>
> On 2019-06-18 14:55, Arnd Bergmann wrote:
> > On Tue, Jun 18, 2019 at 10:36 PM Johannes Berg
> > <johannes@sipsolutions.net> wrote:
> >>
> >> On Tue, 2019-06-18 at 21:59 +0200, Arnd Bergmann wrote:
> >> >
> >> > From my understanding, the ioctl interface would create the lower
> >> > netdev after talking to the firmware, and then user space would use
> >> > the rmnet interface to create a matching upper-level device for that.
> >> > This is an artifact of the strong separation of ipa and rmnet in the
> >> > code.
> >>
> >> Huh. But if rmnet has muxing, and IPA supports that, why would you
> >> ever
> >> need multiple lower netdevs?
> >
> > From my reading of the code, there is always exactly a 1:1 relationship
> > between an rmnet netdev an an ipa netdev. rmnet does the encapsulation/
> > decapsulation of the qmap data and forwards it to the ipa netdev,
> > which then just passes data through between a hardware queue and
> > its netdevice.
> >
>
> There is a n:1 relationship between rmnet and IPA.
> rmnet does the de-muxing to multiple netdevs based on the mux id
> in the MAP header for RX packets and vice versa.
Oh, so you mean that even though IPA supports multiple channels
and multiple netdev instances for a physical device, all the
rmnet devices end up being thrown into a single channel in IPA?
What are the other channels for in IPA? I understand that there
is one channel for commands that is separate, while the others
are for network devices, but that seems to make no sense if
we only use a single channel for rmnet data.
> >> Yeah, but if you actually have a hardware queue per upper netdev then
> >> you don't really need this - you just stop the netdev queue when the
> >> hardware queue is full, and you have flow control automatically.
> >>
> >> So I really don't see any reason to have these messages going back and
> >> forth unless you plan to have multiple sessions muxed on a single
> >> hardware queue.
> >
>
> Hardware may flow control specific PDNs (rmnet interfaces) based on QoS
> -
> not necessarily only in case of hardware queue full.
Right, I guess that makes sense if everything ends up in a
single queue in IPA.
Arnd
^ 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