* [PATCH 3/3] net: ethernet: add support for high speed mac and usxgmii pcs
From: Parshuram Thombare @ 2019-02-22 20:13 UTC (permalink / raw)
To: nicolas.ferre, davem, netdev, andrew, f.fainelli, hkallweit1,
linux-kernel, rafalc, piotrs, jank, pthombar
This patch add support for (10G) high speed mac, usxgmii pcs
and usxgmii interface in Cadence ethernet controller driver.
Signed-off-by: Parshuram Thombare <pthombar@cadence.com>
---
drivers/net/ethernet/cadence/macb.h | 33 +++++++++
drivers/net/ethernet/cadence/macb_main.c | 110 ++++++++++++++++++++++++++++--
include/linux/phy.h | 3 +
3 files changed, 140 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index 59c23e0..34df014 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -84,6 +84,7 @@
#define GEM_USRIO 0x000c /* User IO */
#define GEM_DMACFG 0x0010 /* DMA Configuration */
#define GEM_JML 0x0048 /* Jumbo Max Length */
+#define GEM_HS_MAC_CONFIG 0x0050 /* GEM high speed config */
#define GEM_HRB 0x0080 /* Hash Bottom */
#define GEM_HRT 0x0084 /* Hash Top */
#define GEM_SA1B 0x0088 /* Specific1 Bottom */
@@ -168,6 +169,9 @@
#define GEM_DCFG7 0x0298 /* Design Config 7 */
#define GEM_DCFG8 0x029C /* Design Config 8 */
#define GEM_DCFG10 0x02A4 /* Design Config 10 */
+#define GEM_DCFG12 0x02AC /* Design Config 12 */
+#define GEM_USX_CONTROL 0x0A80 /* USXGMII control register */
+#define GEM_USX_STATUS 0x0A88 /* USXGMII status register */
#define GEM_TXBDCTRL 0x04cc /* TX Buffer Descriptor control register */
#define GEM_RXBDCTRL 0x04d0 /* RX Buffer Descriptor control register */
@@ -275,6 +279,8 @@
#define MACB_IRXFCS_SIZE 1
/* GEM specific NCR bitfields. */
+#define GEM_ENABLE_HS_MAC_OFFSET 31
+#define GEM_ENABLE_HS_MAC_SIZE 1
#define GEM_TWO_PT_FIVE_GIG_OFFSET 29
#define GEM_TWO_PT_FIVE_GIG_SIZE 1
@@ -463,6 +469,10 @@
#define MACB_REV_OFFSET 0
#define MACB_REV_SIZE 16
+/* Bitfield in HS_MAC_CONFIG */
+#define GEM_HS_MAC_SPEED_OFFSET 0
+#define GEM_HS_MAC_SPEED_SIZE 3
+
/* Bitfields in DCFG1. */
#define GEM_IRQCOR_OFFSET 23
#define GEM_IRQCOR_SIZE 1
@@ -504,6 +514,28 @@
#define GEM_RXBD_RDBUFF_OFFSET 8
#define GEM_RXBD_RDBUFF_SIZE 4
+/* Bitfields in DCFG12. */
+#define GEM_HIGH_SPEED_OFFSET 26
+#define GEM_HIGH_SPEED_SIZE 1
+
+/* Bitfields in USX_CONTROL. */
+#define GEM_USX_CTRL_SPEED_OFFSET 14
+#define GEM_USX_CTRL_SPEED_SIZE 3
+#define GEM_SERDES_RATE_OFFSET 12
+#define GEM_SERDES_RATE_SIZE 2
+#define GEM_TX_EN_OFFSET 1
+#define GEM_TX_EN_SIZE 1
+#define GEM_SIGNAL_OK_OFFSET 0
+#define GEM_SIGNAL_OK_SIZE 1
+
+/* Bitfields in USX_STATUS. */
+#define GEM_USX_TX_FAULT_OFFSET 28
+#define GEM_USX_TX_FAULT_SIZE 1
+#define GEM_USX_RX_FAULT_OFFSET 27
+#define GEM_USX_RX_FAULT_SIZE 1
+#define GEM_USX_BLOCK_LOCK_OFFSET 0
+#define GEM_USX_BLOCK_LOCK_SIZE 1
+
/* Bitfields in TISUBN */
#define GEM_SUBNSINCR_OFFSET 0
#define GEM_SUBNSINCR_SIZE 16
@@ -664,6 +696,7 @@
#define MACB_CAPS_MACB_IS_GEM 0x80000000
#define MACB_CAPS_PCS 0x01000000
#define MACB_CAPS_TWO_PT_FIVE_GIG_SPEED 0x02000000
+#define MACB_CAPS_HIGH_SPEED 0x04000000
#define MACB_GEM7010_IDNUM 0x009
#define MACB_GEM7014_IDNUM 0x107
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 2494abf..0e0acf9 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -79,6 +79,21 @@
*/
#define MACB_HALT_TIMEOUT 1230
+enum {
+ HS_MAC_SPEED_100M,
+ HS_MAC_SPEED_1000M,
+ HS_MAC_SPEED_2500M,
+ HS_MAC_SPEED_5000M,
+ HS_MAC_SPEED_10000M,
+ HS_MAC_SPEED_25000M,
+};
+
+enum {
+ MACB_SERDES_RATE_5_PT_15625Gbps,
+ MACB_SERDES_RATE_10_PT_3125Gbps,
+ MACB_SERDES_RATE_25_PT_78125Gbps,
+};
+
/* DMA buffer descriptor might be different size
* depends on hardware configuration:
*
@@ -443,6 +458,20 @@ static void macb_set_tx_clk(struct clk *clk, int speed,
default:
return;
}
+ } else if (interface == PHY_INTERFACE_MODE_USXGMII) {
+ struct macb *bp = netdev_priv(dev);
+ u32 serdes_rate = GEM_BFEXT(SERDES_RATE,
+ gem_readl(bp, USX_CONTROL));
+ switch (serdes_rate) {
+ case MACB_SERDES_RATE_5_PT_15625Gbps:
+ rate = 78125000;
+ break;
+ case MACB_SERDES_RATE_10_PT_3125Gbps:
+ rate = 156250000;
+ break;
+ default:
+ return;
+ }
} else {
return;
}
@@ -475,7 +504,7 @@ static void macb_handle_link_change(struct net_device *dev)
if (phydev->link && (bp->speed != phydev->speed ||
bp->duplex != phydev->duplex)) {
- u32 reg;
+ u32 reg, speed;
reg = macb_readl(bp, NCFGR);
reg &= ~(MACB_BIT(SPD) | MACB_BIT(FD));
@@ -485,7 +514,53 @@ static void macb_handle_link_change(struct net_device *dev)
reg |= MACB_BIT(FD);
macb_or_gem_writel(bp, NCFGR, reg);
- if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII &&
+ if ((bp->phy_interface == PHY_INTERFACE_MODE_USXGMII ||
+ bp->phy_interface == PHY_INTERFACE_MODE_XGMII) &&
+ phydev->speed >= SPEED_100) {
+ gem_writel(bp, NCR, gem_readl(bp, NCR) |
+ GEM_BIT(ENABLE_HS_MAC));
+ if (bp->phy_interface == PHY_INTERFACE_MODE_USXGMII) {
+ /* Setup USXGMII PCS */
+ reg = gem_readl(bp, USX_CONTROL);
+ reg = GEM_BFINS(SERDES_RATE,
+ MACB_SERDES_RATE_5_PT_15625Gbps,
+ reg);
+ gem_writel(bp, USX_CONTROL, reg |
+ GEM_BIT(TX_EN) |
+ GEM_BIT(SIGNAL_OK));
+ while (!GEM_BFEXT(USX_BLOCK_LOCK,
+ gem_readl(bp, USX_STATUS)))
+ cpu_relax();
+ }
+ switch (phydev->speed) {
+ case SPEED_10000:
+ speed = HS_MAC_SPEED_10000M;
+ break;
+
+ case SPEED_5000:
+ speed = HS_MAC_SPEED_5000M;
+ break;
+
+ case SPEED_2500:
+ speed = HS_MAC_SPEED_2500M;
+ break;
+
+ case SPEED_1000:
+ speed = HS_MAC_SPEED_1000M;
+ break;
+
+ default:
+ case SPEED_100:
+ speed = HS_MAC_SPEED_100M;
+ break;
+ }
+ gem_writel(bp, HS_MAC_CONFIG,
+ GEM_BFINS(HS_MAC_SPEED, speed,
+ gem_readl(bp, HS_MAC_CONFIG)));
+ gem_writel(bp, USX_CONTROL,
+ GEM_BFINS(USX_CTRL_SPEED, speed,
+ gem_readl(bp, USX_CONTROL)));
+ } else if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII &&
(phydev->speed == SPEED_1000 ||
phydev->speed == SPEED_2500)) {
if (bp->caps & MACB_CAPS_TWO_PT_FIVE_GIG_SPEED) {
@@ -627,10 +702,15 @@ static int macb_mii_probe(struct net_device *dev)
/* mask with MAC supported features */
if (macb_is_gem(bp)) {
- linkmode_copy(phydev->supported, PHY_GBIT_FEATURES);
- if (bp->caps & MACB_CAPS_TWO_PT_FIVE_GIG_SPEED)
- linkmode_set_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
- phydev->supported);
+ if (bp->caps & MACB_CAPS_HIGH_SPEED) {
+ linkmode_copy(phydev->supported, PHY_10GBIT_FEATURES);
+ } else {
+ u32 bitmask = ETHTOOL_LINK_MODE_2500baseT_Full_BIT;
+
+ linkmode_copy(phydev->supported, PHY_GBIT_FEATURES);
+ if (bp->caps & MACB_CAPS_TWO_PT_FIVE_GIG_SPEED)
+ linkmode_set_bit(bitmask, phydev->supported);
+ }
} else {
linkmode_copy(phydev->supported, PHY_BASIC_FEATURES);
}
@@ -3344,6 +3424,9 @@ static void macb_configure_caps(struct macb *bp,
bp->caps |= MACB_CAPS_ISR_CLEAR_ON_WRITE;
if (GEM_BFEXT(NO_PCS, dcfg) == 0)
bp->caps |= MACB_CAPS_PCS;
+ dcfg = gem_readl(bp, DCFG12);
+ if (GEM_BFEXT(HIGH_SPEED, dcfg) == 1)
+ bp->caps |= MACB_CAPS_HIGH_SPEED;
switch (MACB_BFEXT(IDNUM, macb_readl(bp, MID))) {
case MACB_GEM7016_IDNUM:
case MACB_GEM7017_IDNUM:
@@ -4215,6 +4298,21 @@ static int macb_probe(struct platform_device *pdev)
bp->phy_interface = PHY_INTERFACE_MODE_MII;
} else {
switch (err) {
+ case PHY_INTERFACE_MODE_USXGMII:
+ if ((bp->caps & MACB_CAPS_HIGH_SPEED) &&
+ (bp->caps & MACB_CAPS_PCS)) {
+ bp->phy_interface = PHY_INTERFACE_MODE_USXGMII;
+ break;
+ }
+ /* Fallthrough */
+
+ case PHY_INTERFACE_MODE_XGMII:
+ if (bp->caps & MACB_CAPS_HIGH_SPEED) {
+ bp->phy_interface = PHY_INTERFACE_MODE_XGMII;
+ break;
+ }
+ /* Fallthrough */
+
case PHY_INTERFACE_MODE_SGMII:
if (bp->caps & MACB_CAPS_PCS) {
bp->phy_interface = PHY_INTERFACE_MODE_SGMII;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 8e9fc57..b627e30 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -94,6 +94,7 @@
PHY_INTERFACE_MODE_RTBI,
PHY_INTERFACE_MODE_SMII,
PHY_INTERFACE_MODE_XGMII,
+ PHY_INTERFACE_MODE_USXGMII,
PHY_INTERFACE_MODE_MOCA,
PHY_INTERFACE_MODE_QSGMII,
PHY_INTERFACE_MODE_TRGMII,
@@ -162,6 +163,8 @@ unsigned int phy_supported_speeds(struct phy_device *phy,
return "smii";
case PHY_INTERFACE_MODE_XGMII:
return "xgmii";
+ case PHY_INTERFACE_MODE_USXGMII:
+ return "usxgmii";
case PHY_INTERFACE_MODE_MOCA:
return "moca";
case PHY_INTERFACE_MODE_QSGMII:
--
1.7.1
^ permalink raw reply related
* RE: [RFC v1 01/19] net/i40e: Add peer register/unregister to struct i40e_netdev_priv
From: Ertman, David M @ 2019-02-22 20:13 UTC (permalink / raw)
To: Jason Gunthorpe, Saleem, Shiraz
Cc: dledford@redhat.com, davem@davemloft.net,
linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
Ismail, Mustafa, Kirsher, Jeffrey T, Patil, Kiran
In-Reply-To: <20190221193523.GO17500@ziepe.ca>
> -----Original Message-----
> From: Jason Gunthorpe [mailto:jgg@ziepe.ca]
> Sent: Thursday, February 21, 2019 11:35 AM
> To: Saleem, Shiraz <shiraz.saleem@intel.com>
> Cc: dledford@redhat.com; davem@davemloft.net; linux-
> rdma@vger.kernel.org; netdev@vger.kernel.org; Ismail, Mustafa
> <mustafa.ismail@intel.com>; Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>;
> Patil, Kiran <kiran.patil@intel.com>; Ertman, David M
> <david.m.ertman@intel.com>
> Subject: Re: [RFC v1 01/19] net/i40e: Add peer register/unregister to struct
> i40e_netdev_priv
>
> On Thu, Feb 21, 2019 at 02:19:33AM +0000, Saleem, Shiraz wrote:
> > >Subject: Re: [RFC v1 01/19] net/i40e: Add peer register/unregister to
> > >struct i40e_netdev_priv
> > >
> > >On Fri, Feb 15, 2019 at 11:10:48AM -0600, Shiraz Saleem wrote:
> > >> Expose the register/unregister function pointers in the struct
> > >> i40e_netdev_priv which is accesible via the netdev_priv() interface
> > >> in the RDMA driver. On a netdev notification in the RDMA driver,
> > >> the appropriate LAN driver register/unregister functions are
> > >> invoked from the struct i40e_netdev_priv structure,
> > >
> > >Why? In later patches we get an entire device_add() based thing. Why
> > >do you need two things?
> > >
> > >The RDMA driver should bind to the thing that device_add created and
> > >from there reliably get the netdev. It should not listen to netdev notifiers for
> attachment.
> >
> > In the new IDC mechanism between ice<->irdma, the LAN driver setups up
> > the device for us and attaches it to a software bus via device_add() based
> mechanism.
> > However, RDMA driver binds to the device only when the LAN 'register'
> > function is called in irdma.
>
> That doesn't make sense. The PCI driver should always create the required
> struct device attachment point when attachment is becomes possible.
>
> > There is no ordering guarantee in which irdma, i40e and ice modules load.
> > The netdev notifier is for the case where the irdma loads before i40e
> > or ice.
>
> You are supposed to use the driver core to handle this ordering.
>
> The pci driver creates the attachment points in the correct order, when they
> are ready for use, and the driver core will automatically attach registered
> device drivers to the attachement points, no matter the module load loader.
>
> You will have a netdev and a rdma attachment point, sounds like the RDMA one
> is created once the netdev is happy.
>
> Maybe what you are missing is a struct device_driver?
>
> Jason
I am assuming that the term PCI driver is being used to mean the PCI
subsystem in the kernel. If this assumption is wrong, please disregard the next
paragraph, but the following points will still apply.
The bus that the irdma driver is registering with is a software (pseudo) bus
and not a hardware bus, and since this software bus is being defined by the LAN
driver, the bus does not exist until a LAN driver is loaded, up, and ready to receive
registration from the irdma peer. The PCI driver does not have anything to with this
bus, and has no ability to perform the described functions. The irdma driver cannot
register with the software bus unless it registers with the LAN driver that controls the
bus. The LAN driver's register function will call "driver_register(&drv->driver)" for the
registering irdma driver.
Since the irdma driver is a consolidated driver (supports both ice and i40e LAN
drivers), we cannot guarantee that a given LAN driver will load before the irdma
driver. Even if we use module dependencies to make irdma depend on (ice ||
i40e), we have to consider the situation where a machine will have both an ice
supported LAN device and an i40e supported LAN device in it. In this case, the
load order could be (e.g.) i40e -> irdma -> ice. The irdma driver can check all
present netdevs when it loads to find the one that has the correct function
pointers in it, but it will have no way of knowing that a new software bus was
created by the second LAN driver to load.
This is why irdma is listening for netdev notifiers, so that whenever a new netdev
appears from a LAN driver loading after irdma, the irdma driver can evaluate
whether the new netdev was created by a LAN driver supported by irdma driver.
If I have misunderstood your concerns, I apologize and look forward to clarification.
Thanks,
-Dave Ertman
^ permalink raw reply
* [PATCH] MIPS: lantiq: Remove separate GPHY Firmware loader
From: Hauke Mehrtens @ 2019-02-22 20:13 UTC (permalink / raw)
To: paul.burton
Cc: linux-mips, devicetree, john, martin.blumenstingl, netdev,
Hauke Mehrtens
The separate GPHY Firmware loader driver is not used any more, the GPHY
firmware is now loaded by the GSWIP switch driver which also makes use
of the GPHY.
Remove the old unused GPHY firmware loader driver.
The GPHY firmware is useless without an Ethernet and switch driver, it
should not harm if loading this does not work for system using an old
device tree.
I am not aware of any vendor separating the device tree from the kernel
binary, it should be ok to remove this.
The code and the functionality form this separate GPHY firmware loader
was added to the gswip driver in commit 14fceff4771e ("net: dsa: Add
Lantiq / Intel DSA driver for vrx200")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
This should go through the MIPS tree, but any other tree should also be
fine, I am not expecting any merge conflicts.
.../bindings/mips/lantiq/rcu-gphy.txt | 36 ---
.../devicetree/bindings/mips/lantiq/rcu.txt | 18 --
arch/mips/configs/xway_defconfig | 1 -
arch/mips/lantiq/Kconfig | 4 -
drivers/soc/lantiq/Makefile | 1 -
drivers/soc/lantiq/gphy.c | 224 ------------------
6 files changed, 284 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mips/lantiq/rcu-gphy.txt
delete mode 100644 drivers/soc/lantiq/gphy.c
diff --git a/Documentation/devicetree/bindings/mips/lantiq/rcu-gphy.txt b/Documentation/devicetree/bindings/mips/lantiq/rcu-gphy.txt
deleted file mode 100644
index a0c19bd1ce66..000000000000
--- a/Documentation/devicetree/bindings/mips/lantiq/rcu-gphy.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Lantiq XWAY SoC GPHY binding
-============================
-
-This binding describes a software-defined ethernet PHY, provided by the RCU
-module on newer Lantiq XWAY SoCs (xRX200 and newer).
-
--------------------------------------------------------------------------------
-Required properties:
-- compatible : Should be one of
- "lantiq,xrx200a1x-gphy"
- "lantiq,xrx200a2x-gphy"
- "lantiq,xrx300-gphy"
- "lantiq,xrx330-gphy"
-- reg : Addrress of the GPHY FW load address register
-- resets : Must reference the RCU GPHY reset bit
-- reset-names : One entry, value must be "gphy" or optional "gphy2"
-- clocks : A reference to the (PMU) GPHY clock gate
-
-Optional properties:
-- lantiq,gphy-mode : GPHY_MODE_GE (default) or GPHY_MODE_FE as defined in
- <dt-bindings/mips/lantiq_xway_gphy.h>
-
-
--------------------------------------------------------------------------------
-Example for the GPHys on the xRX200 SoCs:
-
-#include <dt-bindings/mips/lantiq_rcu_gphy.h>
- gphy0: gphy@20 {
- compatible = "lantiq,xrx200a2x-gphy";
- reg = <0x20 0x4>;
-
- resets = <&reset0 31 30>, <&reset1 7 7>;
- reset-names = "gphy", "gphy2";
- clocks = <&pmu0 XRX200_PMU_GATE_GPHY>;
- lantiq,gphy-mode = <GPHY_MODE_GE>;
- };
diff --git a/Documentation/devicetree/bindings/mips/lantiq/rcu.txt b/Documentation/devicetree/bindings/mips/lantiq/rcu.txt
index 7f0822b4beae..58d51f480c9e 100644
--- a/Documentation/devicetree/bindings/mips/lantiq/rcu.txt
+++ b/Documentation/devicetree/bindings/mips/lantiq/rcu.txt
@@ -26,24 +26,6 @@ Example of the RCU bindings on a xRX200 SoC:
ranges = <0x0 0x203000 0x100>;
big-endian;
- gphy0: gphy@20 {
- compatible = "lantiq,xrx200a2x-gphy";
- reg = <0x20 0x4>;
-
- resets = <&reset0 31 30>, <&reset1 7 7>;
- reset-names = "gphy", "gphy2";
- lantiq,gphy-mode = <GPHY_MODE_GE>;
- };
-
- gphy1: gphy@68 {
- compatible = "lantiq,xrx200a2x-gphy";
- reg = <0x68 0x4>;
-
- resets = <&reset0 29 28>, <&reset1 6 6>;
- reset-names = "gphy", "gphy2";
- lantiq,gphy-mode = <GPHY_MODE_GE>;
- };
-
reset0: reset-controller@10 {
compatible = "lantiq,xrx200-reset";
reg = <0x10 4>, <0x14 4>;
diff --git a/arch/mips/configs/xway_defconfig b/arch/mips/configs/xway_defconfig
index c3cac29e8414..2bb02ea9fb4e 100644
--- a/arch/mips/configs/xway_defconfig
+++ b/arch/mips/configs/xway_defconfig
@@ -13,7 +13,6 @@ CONFIG_EMBEDDED=y
# CONFIG_COMPAT_BRK is not set
CONFIG_LANTIQ=y
CONFIG_PCI_LANTIQ=y
-CONFIG_XRX200_PHY_FW=y
CONFIG_CPU_MIPS32_R2=y
CONFIG_MIPS_VPE_LOADER=y
CONFIG_NR_CPUS=2
diff --git a/arch/mips/lantiq/Kconfig b/arch/mips/lantiq/Kconfig
index 188de95d6dbd..6c6802e482c9 100644
--- a/arch/mips/lantiq/Kconfig
+++ b/arch/mips/lantiq/Kconfig
@@ -52,8 +52,4 @@ config PCI_LANTIQ
bool "PCI Support"
depends on SOC_XWAY && PCI
-config XRX200_PHY_FW
- bool "XRX200 PHY firmware loader"
- depends on SOC_XWAY
-
endif
diff --git a/drivers/soc/lantiq/Makefile b/drivers/soc/lantiq/Makefile
index be9e866d53e5..35aa86bd1023 100644
--- a/drivers/soc/lantiq/Makefile
+++ b/drivers/soc/lantiq/Makefile
@@ -1,2 +1 @@
obj-y += fpi-bus.o
-obj-$(CONFIG_XRX200_PHY_FW) += gphy.o
diff --git a/drivers/soc/lantiq/gphy.c b/drivers/soc/lantiq/gphy.c
deleted file mode 100644
index feeb17cebc25..000000000000
--- a/drivers/soc/lantiq/gphy.c
+++ /dev/null
@@ -1,224 +0,0 @@
-/*
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published
- * by the Free Software Foundation.
- *
- * Copyright (C) 2012 John Crispin <blogic@phrozen.org>
- * Copyright (C) 2016 Martin Blumenstingl <martin.blumenstingl@googlemail.com>
- * Copyright (C) 2017 Hauke Mehrtens <hauke@hauke-m.de>
- */
-
-#include <linux/clk.h>
-#include <linux/delay.h>
-#include <linux/dma-mapping.h>
-#include <linux/firmware.h>
-#include <linux/mfd/syscon.h>
-#include <linux/module.h>
-#include <linux/reboot.h>
-#include <linux/regmap.h>
-#include <linux/reset.h>
-#include <linux/of_device.h>
-#include <linux/of_platform.h>
-#include <linux/property.h>
-#include <dt-bindings/mips/lantiq_rcu_gphy.h>
-
-#include <lantiq_soc.h>
-
-#define XRX200_GPHY_FW_ALIGN (16 * 1024)
-
-struct xway_gphy_priv {
- struct clk *gphy_clk_gate;
- struct reset_control *gphy_reset;
- struct reset_control *gphy_reset2;
- void __iomem *membase;
- char *fw_name;
-};
-
-struct xway_gphy_match_data {
- char *fe_firmware_name;
- char *ge_firmware_name;
-};
-
-static const struct xway_gphy_match_data xrx200a1x_gphy_data = {
- .fe_firmware_name = "lantiq/xrx200_phy22f_a14.bin",
- .ge_firmware_name = "lantiq/xrx200_phy11g_a14.bin",
-};
-
-static const struct xway_gphy_match_data xrx200a2x_gphy_data = {
- .fe_firmware_name = "lantiq/xrx200_phy22f_a22.bin",
- .ge_firmware_name = "lantiq/xrx200_phy11g_a22.bin",
-};
-
-static const struct xway_gphy_match_data xrx300_gphy_data = {
- .fe_firmware_name = "lantiq/xrx300_phy22f_a21.bin",
- .ge_firmware_name = "lantiq/xrx300_phy11g_a21.bin",
-};
-
-static const struct of_device_id xway_gphy_match[] = {
- { .compatible = "lantiq,xrx200a1x-gphy", .data = &xrx200a1x_gphy_data },
- { .compatible = "lantiq,xrx200a2x-gphy", .data = &xrx200a2x_gphy_data },
- { .compatible = "lantiq,xrx300-gphy", .data = &xrx300_gphy_data },
- { .compatible = "lantiq,xrx330-gphy", .data = &xrx300_gphy_data },
- {},
-};
-MODULE_DEVICE_TABLE(of, xway_gphy_match);
-
-static int xway_gphy_load(struct device *dev, struct xway_gphy_priv *priv,
- dma_addr_t *dev_addr)
-{
- const struct firmware *fw;
- void *fw_addr;
- dma_addr_t dma_addr;
- size_t size;
- int ret;
-
- ret = request_firmware(&fw, priv->fw_name, dev);
- if (ret) {
- dev_err(dev, "failed to load firmware: %s, error: %i\n",
- priv->fw_name, ret);
- return ret;
- }
-
- /*
- * GPHY cores need the firmware code in a persistent and contiguous
- * memory area with a 16 kB boundary aligned start address.
- */
- size = fw->size + XRX200_GPHY_FW_ALIGN;
-
- fw_addr = dmam_alloc_coherent(dev, size, &dma_addr, GFP_KERNEL);
- if (fw_addr) {
- fw_addr = PTR_ALIGN(fw_addr, XRX200_GPHY_FW_ALIGN);
- *dev_addr = ALIGN(dma_addr, XRX200_GPHY_FW_ALIGN);
- memcpy(fw_addr, fw->data, fw->size);
- } else {
- dev_err(dev, "failed to alloc firmware memory\n");
- ret = -ENOMEM;
- }
-
- release_firmware(fw);
-
- return ret;
-}
-
-static int xway_gphy_of_probe(struct platform_device *pdev,
- struct xway_gphy_priv *priv)
-{
- struct device *dev = &pdev->dev;
- const struct xway_gphy_match_data *gphy_fw_name_cfg;
- u32 gphy_mode;
- int ret;
- struct resource *res_gphy;
-
- gphy_fw_name_cfg = of_device_get_match_data(dev);
-
- priv->gphy_clk_gate = devm_clk_get(dev, NULL);
- if (IS_ERR(priv->gphy_clk_gate)) {
- dev_err(dev, "Failed to lookup gate clock\n");
- return PTR_ERR(priv->gphy_clk_gate);
- }
-
- res_gphy = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- priv->membase = devm_ioremap_resource(dev, res_gphy);
- if (IS_ERR(priv->membase))
- return PTR_ERR(priv->membase);
-
- priv->gphy_reset = devm_reset_control_get(dev, "gphy");
- if (IS_ERR(priv->gphy_reset)) {
- if (PTR_ERR(priv->gphy_reset) != -EPROBE_DEFER)
- dev_err(dev, "Failed to lookup gphy reset\n");
- return PTR_ERR(priv->gphy_reset);
- }
-
- priv->gphy_reset2 = devm_reset_control_get_optional(dev, "gphy2");
- if (IS_ERR(priv->gphy_reset2))
- return PTR_ERR(priv->gphy_reset2);
-
- ret = device_property_read_u32(dev, "lantiq,gphy-mode", &gphy_mode);
- /* Default to GE mode */
- if (ret)
- gphy_mode = GPHY_MODE_GE;
-
- switch (gphy_mode) {
- case GPHY_MODE_FE:
- priv->fw_name = gphy_fw_name_cfg->fe_firmware_name;
- break;
- case GPHY_MODE_GE:
- priv->fw_name = gphy_fw_name_cfg->ge_firmware_name;
- break;
- default:
- dev_err(dev, "Unknown GPHY mode %d\n", gphy_mode);
- return -EINVAL;
- }
-
- return 0;
-}
-
-static int xway_gphy_probe(struct platform_device *pdev)
-{
- struct device *dev = &pdev->dev;
- struct xway_gphy_priv *priv;
- dma_addr_t fw_addr = 0;
- int ret;
-
- priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
- if (!priv)
- return -ENOMEM;
-
- ret = xway_gphy_of_probe(pdev, priv);
- if (ret)
- return ret;
-
- ret = clk_prepare_enable(priv->gphy_clk_gate);
- if (ret)
- return ret;
-
- ret = xway_gphy_load(dev, priv, &fw_addr);
- if (ret) {
- clk_disable_unprepare(priv->gphy_clk_gate);
- return ret;
- }
-
- reset_control_assert(priv->gphy_reset);
- reset_control_assert(priv->gphy_reset2);
-
- iowrite32be(fw_addr, priv->membase);
-
- reset_control_deassert(priv->gphy_reset);
- reset_control_deassert(priv->gphy_reset2);
-
- platform_set_drvdata(pdev, priv);
-
- return ret;
-}
-
-static int xway_gphy_remove(struct platform_device *pdev)
-{
- struct xway_gphy_priv *priv = platform_get_drvdata(pdev);
-
- iowrite32be(0, priv->membase);
-
- clk_disable_unprepare(priv->gphy_clk_gate);
-
- return 0;
-}
-
-static struct platform_driver xway_gphy_driver = {
- .probe = xway_gphy_probe,
- .remove = xway_gphy_remove,
- .driver = {
- .name = "xway-rcu-gphy",
- .of_match_table = xway_gphy_match,
- },
-};
-
-module_platform_driver(xway_gphy_driver);
-
-MODULE_FIRMWARE("lantiq/xrx300_phy11g_a21.bin");
-MODULE_FIRMWARE("lantiq/xrx300_phy22f_a21.bin");
-MODULE_FIRMWARE("lantiq/xrx200_phy11g_a14.bin");
-MODULE_FIRMWARE("lantiq/xrx200_phy11g_a22.bin");
-MODULE_FIRMWARE("lantiq/xrx200_phy22f_a14.bin");
-MODULE_FIRMWARE("lantiq/xrx200_phy22f_a22.bin");
-MODULE_AUTHOR("Martin Blumenstingl <martin.blumenstingl@googlemail.com>");
-MODULE_DESCRIPTION("Lantiq XWAY GPHY Firmware Loader");
-MODULE_LICENSE("GPL");
--
2.20.1
^ permalink raw reply related
* Re: INFO: task hung in rtnetlink_rcv_msg
From: Joe Perches @ 2019-02-22 20:14 UTC (permalink / raw)
To: Jakub Kicinski
Cc: syzbot, ast, christian, daniel, davem, dsahern, hawk, idosch,
john.fastabend, kafai, ktkhai, linux-kernel, netdev, petrm, roopa,
songliubraving, syzkaller-bugs, xdp-newbies, yhs
In-Reply-To: <20190222120129.1f2f1c17@cakuba.netronome.com>
On Fri, 2019-02-22 at 12:01 -0800, Jakub Kicinski wrote:
> Hi!
>
> Seems like something funny is going on with get_maintainer.pl since XDP
> entry got added. We seem to have been CCed on:
I suggest removing the MAINTAINERS line with
K: xdp
as xdp is a pretty generic file/patch content
regex match for the K: type
$ git grep --name-only xdp | wc -l
236
Rather more files than desired.
The N: match is dubious too.
It's generally better to have specific lists of
maintained file patterns rather than using the
K: and N: pattern matches.
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index d7ad97b235ec..aa703e2cb882 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16970,7 +16970,6 @@ F: include/net/xdp.h
F: kernel/bpf/devmap.c
F: kernel/bpf/cpumap.c
F: include/trace/events/xdp.h
-K: xdp
N: xdp
XDP SOCKETS (AF_XDP)
^ permalink raw reply related
* Re: [RFC v1 01/19] net/i40e: Add peer register/unregister to struct i40e_netdev_priv
From: Jason Gunthorpe @ 2019-02-22 20:23 UTC (permalink / raw)
To: Ertman, David M
Cc: Saleem, Shiraz, dledford@redhat.com, davem@davemloft.net,
linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
Ismail, Mustafa, Kirsher, Jeffrey T, Patil, Kiran
In-Reply-To: <2B0E3F215D1AB84DA946C8BEE234CCC97B11DF23@ORSMSX101.amr.corp.intel.com>
On Fri, Feb 22, 2019 at 08:13:58PM +0000, Ertman, David M wrote:
> > From: Jason Gunthorpe [mailto:jgg@ziepe.ca]
> > Sent: Thursday, February 21, 2019 11:35 AM
> > To: Saleem, Shiraz <shiraz.saleem@intel.com>
> > Cc: dledford@redhat.com; davem@davemloft.net; linux-
> > rdma@vger.kernel.org; netdev@vger.kernel.org; Ismail, Mustafa
> > <mustafa.ismail@intel.com>; Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>;
> > Patil, Kiran <kiran.patil@intel.com>; Ertman, David M
> > <david.m.ertman@intel.com>
> > Subject: Re: [RFC v1 01/19] net/i40e: Add peer register/unregister to struct
> > i40e_netdev_priv
> >
> > On Thu, Feb 21, 2019 at 02:19:33AM +0000, Saleem, Shiraz wrote:
> > > >Subject: Re: [RFC v1 01/19] net/i40e: Add peer register/unregister to
> > > >struct i40e_netdev_priv
> > > >
> > > >On Fri, Feb 15, 2019 at 11:10:48AM -0600, Shiraz Saleem wrote:
> > > >> Expose the register/unregister function pointers in the struct
> > > >> i40e_netdev_priv which is accesible via the netdev_priv() interface
> > > >> in the RDMA driver. On a netdev notification in the RDMA driver,
> > > >> the appropriate LAN driver register/unregister functions are
> > > >> invoked from the struct i40e_netdev_priv structure,
> > > >
> > > >Why? In later patches we get an entire device_add() based thing. Why
> > > >do you need two things?
> > > >
> > > >The RDMA driver should bind to the thing that device_add created and
> > > >from there reliably get the netdev. It should not listen to netdev notifiers for
> > attachment.
> > >
> > > In the new IDC mechanism between ice<->irdma, the LAN driver setups up
> > > the device for us and attaches it to a software bus via device_add() based
> > mechanism.
> > > However, RDMA driver binds to the device only when the LAN 'register'
> > > function is called in irdma.
> >
> > That doesn't make sense. The PCI driver should always create the required
> > struct device attachment point when attachment is becomes possible.
> >
> > > There is no ordering guarantee in which irdma, i40e and ice modules load.
> > > The netdev notifier is for the case where the irdma loads before i40e
> > > or ice.
> >
> > You are supposed to use the driver core to handle this ordering.
> >
> > The pci driver creates the attachment points in the correct order, when they
> > are ready for use, and the driver core will automatically attach registered
> > device drivers to the attachement points, no matter the module load loader.
> >
> > You will have a netdev and a rdma attachment point, sounds like the RDMA one
> > is created once the netdev is happy.
> >
> > Maybe what you are missing is a struct device_driver?
> >
> > Jason
>
> I am assuming that the term PCI driver is being used to mean the PCI
> subsystem in the kernel. If this assumption is wrong, please disregard the next
> paragraph, but the following points will still apply.
No, I mean the driver that has the struct pci_driver for the PCI
function. Maybe that is the LAN driver for this case.
> bus, and has no ability to perform the described functions. The
> irdma driver cannot register with the software bus unless it
> registers with the LAN driver that controls the bus. The LAN
> driver's register function will call "driver_register(&drv->driver)"
> for the registering irdma driver.
That isn't how to use the driver core.
> Since the irdma driver is a consolidated driver (supports both ice and i40e LAN
> drivers), we cannot guarantee that a given LAN driver will load before the irdma
> driver. Even if we use module dependencies to make irdma depend on (ice ||
> i40e), we have to consider the situation where a machine will have both an ice
> supported LAN device and an i40e supported LAN device in it. In this case, the
> load order could be (e.g.) i40e -> irdma -> ice. The irdma driver can check all
> present netdevs when it loads to find the one that has the correct function
> pointers in it, but it will have no way of knowing that a new software bus was
> created by the second LAN driver to load.
This is why you use the driver core to manage driver binding.
> This is why irdma is listening for netdev notifiers, so that whenever a new netdev
> appears from a LAN driver loading after irdma, the irdma driver can evaluate
> whether the new netdev was created by a LAN driver supported by irdma driver.
Register a device driver to the driver core and wait for the driver
core to call that driver's probe method.
Jason
^ permalink raw reply
* Re: [PATCH v2] kcm: remove any offset before parsing messages
From: Dominique Martinet @ 2019-02-22 20:27 UTC (permalink / raw)
To: Tom Herbert
Cc: Tom Herbert, David Miller, Doron Roberts-Kedes, Dave Watson,
Linux Kernel Network Developers, LKML
In-Reply-To: <CALx6S36o3JVHh3UtOsfXNrosXK0NCZo703gfzfJPgJvZK9brOA@mail.gmail.com>
Tom Herbert wrote on Fri, Feb 22, 2019:
> > > So basically it sounds like you're interested in supporting TCP
> > > connections that are half closed. I believe that the error in half
> > > closed is EPIPE, so if the TCP socket returns that it can be ignored
> > > and the socket can continue being attached and used to send data.
> >
> > Did you mean 'can continue being attached and used to receive data'?
>
> No, I meant shutdown on receive side when FIN is receved. TX is still
> allowed to drain an queued bytes. To support shutdown on the TX side
> would require additional logic since we need to effectively detach the
> transmit path but retain the receive path. I'm not sure this is a
> compelling use case to support.
Hm, it must be a matter of how we see thing but from what I understand
it's exactly the other way around. The remote closed the connection, so
trying to send anything would just yield a RST, so TX doesn't make
sense.
On the other hand, anything that had been sent by the remote before the
FIN and is on the local side's memory should still be receivable.
When you think about it as a TCP stream it's really weird: data coming,
data coming, data coming, FIN received.
But in the networking stack that received FIN short-circuits all the
data that was left around and immediately raises an EPIPE error.
I don't see what makes this FIN packet so great that it should be
processed before the data; we should only see that EPIPE when we're
done reading the data before it or trying to send something.
I'll check tomorrow/next week but I'm pretty sure the packets before
that have been ack'd at a tcp level as well, so losing them in the
application level is really unexpected.
> > I can confirm getsockopt with SO_ERROR gets me EPIPE, but I don't see
> > how to efficiently ignore EPIPE until POLLIN gets unset -- polling on
> > both the csock and kcm socket will do many needless wakeups on only the
> > csock from what I can see, so I'd need some holdoff timer or something.
> > I guess it's possible though.
>
> We might need to clear the error somehow. May a read of zero bytes?
Can try.
> > After a bit more debugging, this part works (__strp_recv() is called
> > again); but the next packet that is treated properly is rejected because
> > by the time __strp_recv() was called again a new skb was read and the
> > length isn't large enough to go all the way into the new packet, so this
> > test fails:
> > } else if (len <= (ssize_t)head->len -
> > skb->len - stm->strp.offset) {
> > /* Length must be into new skb (and also
> > * greater than zero)
> > */
> > STRP_STATS_INCR(strp->stats.bad_hdr_len);
> > strp_parser_err(strp, -EPROTO, desc);
> >
> > So I need to figure a way to say "call this function again without
> > reading more data" somehow, or make this check more lax e.g. accept any
> > len > 0 after a retry maybe...
> > Removing that branch altogether seems to work at least but I'm not sure
> > we'd want to?
>
> I like the check since it's conservative and covers the normal case.
> Maybe just need some more logic?
I can add a "retrying" state and not fail here if we ewre retrying for
whatever reason perhaps...
But I'm starting to wonder how this would work if my client didn't keep
on sending data, I'll try to fail on the last client's packet and see
how __strp_recv is called again through the timer, with the same skb
perhaps?
--
Dominique
^ permalink raw reply
* [PATCH net-next 0/2] net: switchdev.h inclusion removal
From: Florian Fainelli @ 2019-02-22 20:31 UTC (permalink / raw)
To: netdev; +Cc: Florian Fainelli
Hi David,
This targets a few drivers that no longer to have net/switchdev.h
included.
Florian Fainelli (2):
nfp: Remove switchdev.h inclusion
net: Remove switchdev.h inclusion from team/bond/vlan
drivers/net/bonding/bond_main.c | 1 -
drivers/net/ethernet/netronome/nfp/nfp_port.c | 1 -
drivers/net/team/team.c | 1 -
net/8021q/vlan_dev.c | 1 -
4 files changed, 4 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH net-next 1/2] nfp: Remove switchdev.h inclusion
From: Florian Fainelli @ 2019-02-22 20:31 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, Jakub Kicinski, David S. Miller,
Dirk van der Merwe, Jiri Pirko,
open list:NETRONOME ETHERNET DRIVERS, open list
In-Reply-To: <20190222203134.19508-1-f.fainelli@gmail.com>
This is no longer necessary after a5084bb71fa4 ("nfp: Implement
ndo_get_port_parent_id()")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/netronome/nfp/nfp_port.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_port.c b/drivers/net/ethernet/netronome/nfp/nfp_port.c
index 7e90880fa46b..93c5bfc0510b 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_port.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_port.c
@@ -3,7 +3,6 @@
#include <linux/lockdep.h>
#include <linux/netdevice.h>
-#include <net/switchdev.h>
#include "nfpcore/nfp_cpp.h"
#include "nfpcore/nfp_nsp.h"
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 2/2] net: Remove switchdev.h inclusion from team/bond/vlan
From: Florian Fainelli @ 2019-02-22 20:31 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, Jay Vosburgh, Veaceslav Falico, Andy Gospodarek,
David S. Miller, Jiri Pirko, Hangbin Liu, Richard Cochran,
Davide Caratti, Debabrata Banerjee, Sun Lianwen, open list
In-Reply-To: <20190222203134.19508-1-f.fainelli@gmail.com>
This is no longer necessary after eca59f691566 ("net: Remove support for bridge bypass ndos from stacked devices")
Suggested-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/bonding/bond_main.c | 1 -
drivers/net/team/team.c | 1 -
net/8021q/vlan_dev.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 485462d3087f..a044a8032a0f 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -77,7 +77,6 @@
#include <net/pkt_sched.h>
#include <linux/rculist.h>
#include <net/flow_dissector.h>
-#include <net/switchdev.h>
#include <net/bonding.h>
#include <net/bond_3ad.h>
#include <net/bond_alb.h>
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index 958f1cf67282..3ff23a993668 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -28,7 +28,6 @@
#include <net/genetlink.h>
#include <net/netlink.h>
#include <net/sch_generic.h>
-#include <net/switchdev.h>
#include <generated/utsrelease.h>
#include <linux/if_team.h>
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index b2d9c8f27cd7..15293c2a5dd8 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -31,7 +31,6 @@
#include <linux/ethtool.h>
#include <linux/phy.h>
#include <net/arp.h>
-#include <net/switchdev.h>
#include "vlan.h"
#include "vlanproc.h"
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next 1/7] net: phy: marvell10g: Use get_features to get the PHY abilities
From: Maxime Chevallier @ 2019-02-22 20:45 UTC (permalink / raw)
To: Heiner Kallweit
Cc: davem, netdev, linux-kernel, Andrew Lunn, Florian Fainelli,
Russell King, linux-arm-kernel, Antoine Tenart, thomas.petazzoni,
gregory.clement, miquel.raynal, nadavh, stefanc, mw
In-Reply-To: <a69da540-fe5c-e9a7-d848-2f2c61011f21@gmail.com>
On Fri, 22 Feb 2019 19:42:29 +0100
Heiner Kallweit <hkallweit1@gmail.com> wrote:
>After my just submitted patch to include the aneg capability checking in
>genphy_c45_pma_read_abilities() function mv3310_get_features() isn't
>needed any longer and can be replaced with the generic one.
I'll still need it to handle the 2.5G/5G abilities that aren't
correctly reported on 3310. I'll be able to use the generic
function for the 2110 though, which is nice.
>But we can make this change afterwards, then you don't have to
>rework your series.
>
>Also I'm not sure whether there will be a 5.0-rc8 or whether beginning
>of next week we'll see 5.0. In the latter case we're a little bit in a
>hurry because the merge window will start very soon.
OK, I'll re-spin the series quickly with the small cleanup needed if
everything's OK to you regarding the rest of it.
Thanks,
Maxime
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: Remove switchdev.h inclusion from team/bond/vlan
From: Andy Gospodarek @ 2019-02-22 20:47 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, Jay Vosburgh, Veaceslav Falico, David S. Miller,
Jiri Pirko, Hangbin Liu, Richard Cochran, Davide Caratti,
Debabrata Banerjee, Sun Lianwen, open list
In-Reply-To: <20190222203134.19508-3-f.fainelli@gmail.com>
On Fri, Feb 22, 2019 at 12:31:34PM -0800, Florian Fainelli wrote:
> This is no longer necessary after eca59f691566 ("net: Remove support for bridge bypass ndos from stacked devices")
>
> Suggested-by: Ido Schimmel <idosch@mellanox.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Andy Gospodarek <andy@greyhouse.net>
> ---
> drivers/net/bonding/bond_main.c | 1 -
> drivers/net/team/team.c | 1 -
> net/8021q/vlan_dev.c | 1 -
> 3 files changed, 3 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 485462d3087f..a044a8032a0f 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -77,7 +77,6 @@
> #include <net/pkt_sched.h>
> #include <linux/rculist.h>
> #include <net/flow_dissector.h>
> -#include <net/switchdev.h>
> #include <net/bonding.h>
> #include <net/bond_3ad.h>
> #include <net/bond_alb.h>
> diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
> index 958f1cf67282..3ff23a993668 100644
> --- a/drivers/net/team/team.c
> +++ b/drivers/net/team/team.c
> @@ -28,7 +28,6 @@
> #include <net/genetlink.h>
> #include <net/netlink.h>
> #include <net/sch_generic.h>
> -#include <net/switchdev.h>
> #include <generated/utsrelease.h>
> #include <linux/if_team.h>
>
> diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
> index b2d9c8f27cd7..15293c2a5dd8 100644
> --- a/net/8021q/vlan_dev.c
> +++ b/net/8021q/vlan_dev.c
> @@ -31,7 +31,6 @@
> #include <linux/ethtool.h>
> #include <linux/phy.h>
> #include <net/arp.h>
> -#include <net/switchdev.h>
>
> #include "vlan.h"
> #include "vlanproc.h"
> --
> 2.17.1
>
^ permalink raw reply
* Re: pull-request: mac80211 2019-02-22
From: David Miller @ 2019-02-22 20:51 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20190222131052.28249-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 22 Feb 2019 14:10:51 +0100
> So ... I thought there weren't going to be any more patches
> when I asked you to apply that mac80211 one, but now a few
> days later I still ended up with three that are current and
> possibly even stable material.
>
> Please pull and let me know if there's any problem.
Pulled, thanks Johannes.
^ permalink raw reply
* Re: pull-request: mac80211-next 2019-02-22
From: David Miller @ 2019-02-22 20:52 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20190222132513.29834-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 22 Feb 2019 14:25:12 +0100
> Here's the promised update with the big multi-BSSID changes,
> which are related to HE (802.11ax) for which we also have some
> updates.
>
> Note that I took the liberty of including Herbert's rhashtable
> API removal, I merged net-next for that and verified that the
> API he removed is also not used in anything new, but if you
> apply/applied any patches after I pulled you should probably
> double check that again.
>
> Please pull and let me know if there's any problem.
Pulled, looks good on this end.
Will push back out after build testing.
Thanks!
^ permalink raw reply
* Re: [PATCH net-next v2 0/7] AF_PACKET transport_offset fix
From: David Miller @ 2019-02-22 20:55 UTC (permalink / raw)
To: willemdebruijn.kernel
Cc: maximmi, saeedm, willemb, jasowang, edumazet, netdev, eranbe,
tariqt
In-Reply-To: <CAF=yD-J4SLEYxvvjKkvofF+_YE0EDG_MmpQGQ9r6HT0RvFzdyQ@mail.gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Fri, 22 Feb 2019 09:20:01 -0500
> On Thu, Feb 21, 2019 at 7:40 AM Maxim Mikityanskiy <maximmi@mellanox.com> wrote:
>>
>> This patch series contains the implementation of the RFC that was posted
>> on this mailing list previously:
>> https://www.spinics.net/lists/netdev/msg541709.html
>>
>> It fixes having incorrect skb->transport_header values in cases when
>> dissect fails. Having correct values set by the kernel fixes mlx5
>> operation and allows to remove some unnecessary code flows in mlx5.
>>
>> v2 changes:
>>
>> - Rebase against the fresh net-next.
>> - Don't return bool from skb_probe_transport_header (and don't rename
>> the function).
>> - WARN_ON_ONCE and error path in case of GSO without the L4 header.
>>
>> Maxim Mikityanskiy (7):
>> net: Don't set transport offset to invalid value
>> net: Introduce parse_protocol header_ops callback
>> net/ethernet: Add parse_protocol header_ops support
>> net/packet: Ask driver for protocol if not provided by user
>> net/packet: Remove redundant skb->protocol set
>> net/mlx5e: Remove the wrong assumption about transport offset
>> net/mlx5e: Trust kernel regarding transport offset
>
> For the series: Acked-by: Willem de Bruijn <willemb@google.com>
Series applied, thanks.
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2019-02-22
From: David Miller @ 2019-02-22 20:56 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87sgwfn9zk.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Fri, 22 Feb 2019 17:01:03 +0200
> here's a pull request to net-next tree for 5.1, more info below. Do note
> that the diffstat again was wrong due to the wireless-drivers merge so I
> had to recreate it manually.
>
> Please let me know if there are any problems.
Pulled, thanks a lot Kalle.
^ permalink raw reply
* Re: [PATCH v2] kcm: remove any offset before parsing messages
From: Tom Herbert @ 2019-02-22 21:01 UTC (permalink / raw)
To: Dominique Martinet
Cc: Tom Herbert, David Miller, Doron Roberts-Kedes, Dave Watson,
Linux Kernel Network Developers, LKML
In-Reply-To: <20190222202754.GA20806@nautica>
On Fri, Feb 22, 2019 at 12:28 PM Dominique Martinet
<asmadeus@codewreck.org> wrote:
>
> Tom Herbert wrote on Fri, Feb 22, 2019:
> > > > So basically it sounds like you're interested in supporting TCP
> > > > connections that are half closed. I believe that the error in half
> > > > closed is EPIPE, so if the TCP socket returns that it can be ignored
> > > > and the socket can continue being attached and used to send data.
> > >
> > > Did you mean 'can continue being attached and used to receive data'?
> >
> > No, I meant shutdown on receive side when FIN is receved. TX is still
> > allowed to drain an queued bytes. To support shutdown on the TX side
> > would require additional logic since we need to effectively detach the
> > transmit path but retain the receive path. I'm not sure this is a
> > compelling use case to support.
>
Dominque,
> Hm, it must be a matter of how we see thing but from what I understand
> it's exactly the other way around. The remote closed the connection, so
> trying to send anything would just yield a RST, so TX doesn't make
> sense.
> On the other hand, anything that had been sent by the remote before the
> FIN and is on the local side's memory should still be receivable.
That's right, any data sent before the FIN can be received. After the
FIN, there is not more data to received. But, the FIN doesn't say
anything about the reverse path. For instance, if the peer did
shutdown(SHUT_WR), then it sent the FIN so it no longer transmits on
the connection, but still can receive data.
>
> When you think about it as a TCP stream it's really weird: data coming,
> data coming, data coming, FIN received.
> But in the networking stack that received FIN short-circuits all the
> data that was left around and immediately raises an EPIPE error.
>
Right, it doesn't help that most people automatically assume a
received FIN means the connection is closed! (although in practice
that assumption works pretty well for most applications).
> I don't see what makes this FIN packet so great that it should be
> processed before the data; we should only see that EPIPE when we're
> done reading the data before it or trying to send something.
It's not supposed to be. If your seeing a problem, it might because
state_change is processed before the received data is drained. If
plain recvmsg were being used, zero bytes is on returned after all
outstanding received data on the socket has been read. We might need
some additional logic in KCM to handle this.
>
> I'll check tomorrow/next week but I'm pretty sure the packets before
> that have been ack'd at a tcp level as well, so losing them in the
> application level is really unexpected.
>
> > > I can confirm getsockopt with SO_ERROR gets me EPIPE, but I don't see
> > > how to efficiently ignore EPIPE until POLLIN gets unset -- polling on
> > > both the csock and kcm socket will do many needless wakeups on only the
> > > csock from what I can see, so I'd need some holdoff timer or something.
> > > I guess it's possible though.
> >
> > We might need to clear the error somehow. May a read of zero bytes?
>
> Can try.
>
> > > After a bit more debugging, this part works (__strp_recv() is called
> > > again); but the next packet that is treated properly is rejected because
> > > by the time __strp_recv() was called again a new skb was read and the
> > > length isn't large enough to go all the way into the new packet, so this
> > > test fails:
> > > } else if (len <= (ssize_t)head->len -
> > > skb->len - stm->strp.offset) {
> > > /* Length must be into new skb (and also
> > > * greater than zero)
> > > */
> > > STRP_STATS_INCR(strp->stats.bad_hdr_len);
> > > strp_parser_err(strp, -EPROTO, desc);
> > >
> > > So I need to figure a way to say "call this function again without
> > > reading more data" somehow, or make this check more lax e.g. accept any
> > > len > 0 after a retry maybe...
> > > Removing that branch altogether seems to work at least but I'm not sure
> > > we'd want to?
> >
> > I like the check since it's conservative and covers the normal case.
> > Maybe just need some more logic?
>
> I can add a "retrying" state and not fail here if we ewre retrying for
> whatever reason perhaps...
> But I'm starting to wonder how this would work if my client didn't keep
> on sending data, I'll try to fail on the last client's packet and see
> how __strp_recv is called again through the timer, with the same skb
> perhaps?
Right, a timer or some sort of aynchronous callbask is needed. Like I
said, I don't think dealing with memory failure like this is unique to
KCM.
Thanks again for looking into this, I think this is good progress!
Tom
>
> --
> Dominique
^ permalink raw reply
* Re: [PATCH] net: dsa: mv88e6xxx: Add lockdep classes to fix false positive splat
From: David Miller @ 2019-02-22 21:02 UTC (permalink / raw)
To: andrew; +Cc: linux, netdev, vivien.didelot
In-Reply-To: <20190222175916.GM5894@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Fri, 22 Feb 2019 18:59:16 +0100
>> Hi Andrew,
>>
>> Do we have a way forward for this issue?
>
> Hi Russell
>
> Yes. I tested releasing the mutex around the request for the
> interrupt. That works. So i will submit a patchset adding both the
> lockdep class, and the unlock/lock pair.
So I'll drop this patch from patchwork.
^ permalink raw reply
* Re: [PATCH net-next v2 2/5] ethtool: hold a reference to the netdevice around devlink compat
From: Jakub Kicinski @ 2019-02-22 21:20 UTC (permalink / raw)
To: Florian Fainelli; +Cc: davem, jiri, mkubecek, andrew, netdev, oss-drivers
In-Reply-To: <97be3163-b167-edf4-fd16-be35dc68fa25@gmail.com>
On Fri, 22 Feb 2019 12:09:32 -0800, Florian Fainelli wrote:
> On 2/22/19 11:54 AM, Jakub Kicinski wrote:
> > When calling into devlink compat code make sure we have a reference
> > on the netdevice on which the operation was invoked.
> >
> > Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> > ---
> > net/core/ethtool.c | 11 ++++++++---
> > 1 file changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> > index 1320e8dce559..6832476dfcaf 100644
> > --- a/net/core/ethtool.c
> > +++ b/net/core/ethtool.c
> > @@ -805,11 +805,14 @@ static noinline_for_stack int ethtool_get_drvinfo(struct net_device *dev,
> > if (ops->get_eeprom_len)
> > info.eedump_len = ops->get_eeprom_len(dev);
> >
> > - rtnl_unlock();
> > - if (!info.fw_version[0])
> > + if (!info.fw_version[0]) {
> > + dev_hold(dev);
> > + rtnl_unlock();
> > devlink_compat_running_version(dev, info.fw_version,
> > sizeof(info.fw_version));
> > - rtnl_lock();
> > + rtnl_lock();
> > + dev_put(dev);
> > + }
>
> Would it make sense to make the locking and reference holding implicit
> within the compat versions of devlink_* because they use a net_device ->
> devlink object manipulation as opposed to doing in the caller. We are
> more or less guaranteed that the compatibility layer is used from within
> ethtool.
I guess we can, in general it feels wrong to call some devlink_
function with rtnl_lock held, but I guess devlink_compat_ can be
special in this regard. v3 coming up.
^ permalink raw reply
* Re: [PATCH net-next 1/2] nfp: Remove switchdev.h inclusion
From: Jakub Kicinski @ 2019-02-22 21:20 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David S. Miller, Dirk van der Merwe, Jiri Pirko,
open list:NETRONOME ETHERNET DRIVERS, open list
In-Reply-To: <20190222203134.19508-2-f.fainelli@gmail.com>
On Fri, 22 Feb 2019 12:31:33 -0800, Florian Fainelli wrote:
> This is no longer necessary after a5084bb71fa4 ("nfp: Implement
> ndo_get_port_parent_id()")
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
^ permalink raw reply
* Re: [PATCH 1/2 v2] kprobe: Do not use uaccess functions to access kernel memory that can fault
From: Linus Torvalds @ 2019-02-22 21:20 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Masami Hiramatsu, Steven Rostedt, Andy Lutomirski,
Linux List Kernel Mailing, Ingo Molnar, Andrew Morton, stable,
Changbin Du, Jann Horn, Kees Cook, Andy Lutomirski,
Daniel Borkmann, Netdev, bpf
In-Reply-To: <20190222192703.epvgxghwybte7gxs@ast-mbp.dhcp.thefacebook.com>
On Fri, Feb 22, 2019 at 11:27 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On bpf side the bpf_probe_read() helper just calls probe_kernel_read()
> and users pass both user and kernel addresses into it and expect
> that the helper will actually try to read from that address.
As mentioned earlier in the thread, that's actually fundamentally broken.
There are architectures that have physically separate address spaces,
with the same pointer value in both kernel and user space.
They are rare, but they exist. At least sparc32 and the old 4G:4G split x86.
So a pointer really should always unambiguously always be explicitly
_either_ a kernel pointer, or a user pointer. You can't have "this is
a pointer", and then try to figure it out by looking at the value.
That may happen to work on x86-64, but it's literally a "happen to
work on the most common architectures", not a design thing.
Linus
^ permalink raw reply
* Re: [PATCH net-next 2/2] xdp: Add devmap_idx map type for looking up devices by ifindex
From: Jakub Kicinski @ 2019-02-22 21:30 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: David Miller, netdev, Jesper Dangaard Brouer, Daniel Borkmann,
Alexei Starovoitov
In-Reply-To: <87y368gnoh.fsf@toke.dk>
On Fri, 22 Feb 2019 10:47:10 +0100, Toke Høiland-Jørgensen wrote:
> Jakub Kicinski <jakub.kicinski@netronome.com> writes:
>
> > On Fri, 22 Feb 2019 00:02:23 +0100, Toke Høiland-Jørgensen wrote:
> >> Jakub Kicinski <jakub.kicinski@netronome.com> writes:
> >>
> >> > On Thu, 21 Feb 2019 12:56:54 +0100, Toke Høiland-Jørgensen wrote:
> >> >> A common pattern when using xdp_redirect_map() is to create a device map
> >> >> where the lookup key is simply ifindex. Because device maps are arrays,
> >> >> this leaves holes in the map, and the map has to be sized to fit the
> >> >> largest ifindex, regardless of how many devices actually are actually
> >> >> needed in the map.
> >> >>
> >> >> This patch adds a second type of device map where the key is interpreted as
> >> >> an ifindex and looked up using a hashmap, instead of being used as an array
> >> >> index. This leads to maps being densely packed, so they can be smaller.
> >> >>
> >> >> The default maps used by xdp_redirect() are changed to use the new map
> >> >> type, which means that xdp_redirect() is no longer limited to ifindex < 64,
> >> >> but instead to 64 total simultaneous interfaces per network namespace. This
> >> >> also provides an easy way to compare the performance of devmap and
> >> >> devmap_idx:
> >> >>
> >> >> xdp_redirect_map (devmap): 8394560 pkt/s
> >> >> xdp_redirect (devmap_idx): 8179480 pkt/s
> >> >>
> >> >> Difference: 215080 pkt/s or 3.1 nanoseconds per packet.
> >> >
> >> > Could you share what the ifindex mix was here, to arrive at these
> >> > numbers? How does it compare to using an array but not keying with
> >> > ifindex?
> >>
> >> Just the standard set on my test machine; ifindex 1 through 9, except 8
> >> in this case. So certainly no more than 1 ifindex in each hash bucket
> >> for those numbers.
> >
> > Oh, I clearly misread your numbers, it's still slower than array, you
> > just don't need the size limit.
>
> Yeah, this is not about speeding up devmap, it's about lifting the size
> restriction.
>
> >> >> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
> >> >
> >> >> +static int dev_map_idx_update_elem(struct bpf_map *map, void *key, void *value,
> >> >> + u64 map_flags)
> >> >> +{
> >> >> + struct bpf_dtab *dtab = container_of(map, struct bpf_dtab, map);
> >> >> + struct bpf_dtab_netdev *dev, *old_dev;
> >> >> + u32 idx = *(u32 *)key;
> >> >> + u32 val = *(u32 *)value;
> >> >> + u32 bit;
> >> >> +
> >> >> + if (unlikely(map_flags > BPF_EXIST))
> >> >> + return -EINVAL;
> >> >> + if (unlikely(map_flags == BPF_NOEXIST))
> >> >> + return -EEXIST;
> >> >> +
> >> >> + old_dev = __dev_map_idx_lookup_elem(map, idx);
> >> >> + if (!val) {
> >> >> + if (!old_dev)
> >> >> + return 0;
> >> >
> >> > IMHO this is a fairly strange mix of array and hashmap semantics. I
> >> > think you should stick to hashmap behaviour AFA flags and
> >> > update/delete goes.
> >>
> >> Yeah, the double book-keeping is a bit strange, but it allows the actual
> >> forwarding and flush code to be reused between both types of maps. I
> >> think this is worth the slight semantic confusion :)
> >
> > I'm not sure I was clear, let me try again :) Your get_next_key only
> > reports existing indexes if I read the code right, so that's not an
> > array - in an array indexes always exist. What follows inserting 0
> > should not be equivalent to delete and BPF_NOEXIST should be handled
> > appropriately.
>
> Ah, I see what you mean. Yeah, sure, I guess I can restrict deletion to
> only working through explicit delete.
>
> I could also add a fail on NOEXIST, but since each index is tied to a
> particular value, you can't actually change the contents of each index,
> only insert and remove. So why would you ever set that flag?
The reason user would have for setting the flag is not clear :) But
if you want to reject it because it's unsupported/makes no sense, you
should do EINVAL, not EEXIST ;)
> > Different maps behave differently, I think it's worth trying to limit
> > the divergence in how things behave to the basic array and a hashmap
> > models when possible.
>
> So I don't actually think of this as a hashmap in the general sense;
> after all, you can only store ifindexes in it, and key and value are
> tied to one another. So it's an ifindex'ed devmap (which is also why I
> named it devmap_idx and not devmap_hash); the fact that it's implemented
> as a hashmap is just incidental.
>
> So I guess it's a choice between being consistent with the other devmap
> type, or with a general hashmap. I'm not actually sure that the latter
> is less surprising? :)
The distinction is that if entry is not in the map get_next won't
return its key. As you say the construct is not really a hash map
(probably a set is the closest) but it most definitely is not an
array, so no hard EEXIST on NOEXIST flag :)
^ permalink raw reply
* Re: [PATCH net-next 1/2] xdp: Always use a devmap for XDP_REDIRECT to a device
From: Jakub Kicinski @ 2019-02-22 21:37 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: David Miller, netdev, Jesper Dangaard Brouer, Daniel Borkmann,
Alexei Starovoitov
In-Reply-To: <87va1cgmg1.fsf@toke.dk>
On Fri, 22 Feb 2019 11:13:50 +0100, Toke Høiland-Jørgensen wrote:
> Jakub Kicinski <jakub.kicinski@netronome.com> writes:
> > On Thu, 21 Feb 2019 12:56:54 +0100, Toke Høiland-Jørgensen wrote:
> >> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> >> index b63bc77af2d1..629661db36ee 100644
> >> --- a/kernel/bpf/verifier.c
> >> +++ b/kernel/bpf/verifier.c
> >> @@ -7527,6 +7527,12 @@ static int fixup_bpf_calls(struct bpf_verifier_env *env)
> >> prog->dst_needed = 1;
> >> if (insn->imm == BPF_FUNC_get_prandom_u32)
> >> bpf_user_rnd_init_once();
> >> + if (insn->imm == BPF_FUNC_redirect) {
> >> + int err = dev_map_alloc_default_map();
> >> +
> >> + if (err)
> >> + return err;
> >> + }
> >> if (insn->imm == BPF_FUNC_override_return)
> >> prog->kprobe_override = 1;
> >> if (insn->imm == BPF_FUNC_tail_call) {
> >
> >> +int dev_map_alloc_default_map(void)
> >> +{
> >> + struct net *net = current->nsproxy->net_ns;
> >> + struct bpf_dtab *dtab, *old_dtab;
> >> + struct net_device *netdev;
> >> + union bpf_attr attr = {};
> >> + u32 idx;
> >> + int err;
> >
> > BPF programs don't obey by netns boundaries. The fact the program is
> > verified in one ns doesn't mean this is the only ns it will be used in :(
> > Meaning if any program is using the redirect map you may need a secret
> > map in every ns.. no?
>
> Ah, yes, good point. Totally didn't think about the fact that load and
> attach are decoupled. Hmm, guess I'll just have to move the call to
> alloc_default_map() to the point where the program is attached to an
> interface, then...
Possibly.. and you also need to handle the case where interface with a
program attached is moved, no?
> I trust it's safe to skip the allocation in case the program is
> offloaded to hardware, right? I.e., an offloaded program will never need
> to fall back to the kernel helper?
We will cross that bridge when we get there ;) I'd definitely want the
ability to do a redirect to a non-offloaded netdev (e.g. redirect to a
veth) via some fallback, but the plan is to try to only add support for
the map version of redirect on offload, anyway.
^ permalink raw reply
* Re: [PATCH 1/2 v2] kprobe: Do not use uaccess functions to access kernel memory that can fault
From: David Miller @ 2019-02-22 21:38 UTC (permalink / raw)
To: torvalds
Cc: alexei.starovoitov, mhiramat, rostedt, luto, linux-kernel, mingo,
akpm, stable, changbin.du, jannh, keescook, luto, daniel, netdev,
bpf
In-Reply-To: <CAHk-=wib9VSbwbS+N82ZPNtvt4vrvYyHyQduhFimX8nyjCyZyA@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri, 22 Feb 2019 13:20:58 -0800
> On Fri, Feb 22, 2019 at 11:27 AM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
>>
>> On bpf side the bpf_probe_read() helper just calls probe_kernel_read()
>> and users pass both user and kernel addresses into it and expect
>> that the helper will actually try to read from that address.
>
> As mentioned earlier in the thread, that's actually fundamentally broken.
>
> There are architectures that have physically separate address spaces,
> with the same pointer value in both kernel and user space.
>
> They are rare, but they exist. At least sparc32 and the old 4G:4G split x86.
And sparc64.
> So a pointer really should always unambiguously always be explicitly
> _either_ a kernel pointer, or a user pointer. You can't have "this is
> a pointer", and then try to figure it out by looking at the value.
> That may happen to work on x86-64, but it's literally a "happen to
> work on the most common architectures", not a design thing.
Don't be surprised if we see more separation like this in the future too.
So it's not a smart thing to code against even if you can discount all of
the examples Linus gives above.
^ permalink raw reply
* Re: [PATCH 1/3] net: ethernet: add support for PCS and 2.5G speed
From: Andrew Lunn @ 2019-02-22 21:39 UTC (permalink / raw)
To: Parshuram Thombare
Cc: nicolas.ferre, davem, netdev, f.fainelli, hkallweit1,
linux-kernel, rafalc, piotrs, jank
In-Reply-To: <20190222201225.GA15633@lvlogina.cadence.com>
> /* mask with MAC supported features */
> - if (macb_is_gem(bp) && bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE)
> - phy_set_max_speed(phydev, SPEED_1000);
> - else
> - phy_set_max_speed(phydev, SPEED_100);
> + if (macb_is_gem(bp)) {
> + linkmode_copy(phydev->supported, PHY_GBIT_FEATURES);
> + if (bp->caps & MACB_CAPS_TWO_PT_FIVE_GIG_SPEED)
> + linkmode_set_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
> + phydev->supported);
> + } else {
> + linkmode_copy(phydev->supported, PHY_BASIC_FEATURES);
> + }
> +
> + linkmode_copy(phydev->advertising, phydev->supported);
This is not correct. Just because the MAC can do 2.5G does not mean
the PHY can. So you should not be adding links modes. Also, somebody
might be using a PHY that can do 2.5G with a MAC which can only do 1G.
The correct thing to do is call phy_set_max_speed() with the maximum
speed the MAC can do.
Andrew
^ permalink raw reply
* Re: [PATCH 2/3] net: ethernet: add c45 PHY support in MDIO read/write functions.
From: Andrew Lunn @ 2019-02-22 21:41 UTC (permalink / raw)
To: Parshuram Thombare
Cc: nicolas.ferre, davem, netdev, f.fainelli, hkallweit1,
linux-kernel, rafalc, piotrs, jank
In-Reply-To: <20190222201242.GA20889@lvlogina.cadence.com>
On Fri, Feb 22, 2019 at 08:12:42PM +0000, Parshuram Thombare wrote:
> This patch modify MDIO read/write functions to support
> communication with C45 PHY in Cadence ethernet controller driver.
Hi Parshuram
Are all versions of the MDIO controller capable of doing C45?
Andrew
^ 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