* [PATCH v4 2/7] Documentation: devicetree: add PHY lane swap binding
From: Jon Mason @ 2016-11-01 20:04 UTC (permalink / raw)
To: David Miller, Rob Herring, Mark Rutland, Florian Fainelli
Cc: rafal, bcm-kernel-feedback-list, netdev, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1478030682-27012-1-git-send-email-jon.mason@broadcom.com>
Add the documentation for PHY lane swapping. This is a boolean entry to
notify the phy device drivers that the TX/RX lanes need to be swapped.
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
Documentation/devicetree/bindings/net/phy.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
index bc1c3c8..3dce607 100644
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -35,6 +35,9 @@ Optional Properties:
- broken-turn-around: If set, indicates the PHY device does not correctly
release the turn around line low at the end of a MDIO transaction.
+- enet-phy-lane-swap: If set, indicates the PHY device requires swapping the
+ TX/RX lanes to function properly.
+
Example:
ethernet-phy@0 {
--
2.7.4
^ permalink raw reply related
* [PATCH v4 3/7] net: phy: broadcom: Add BCM54810 PHY entry
From: Jon Mason @ 2016-11-01 20:04 UTC (permalink / raw)
To: David Miller, Rob Herring, Mark Rutland, Florian Fainelli
Cc: devicetree, netdev, linux-kernel, bcm-kernel-feedback-list, rafal,
linux-arm-kernel
In-Reply-To: <1478030682-27012-1-git-send-email-jon.mason@broadcom.com>
The BCM54810 PHY requires some semi-unique configuration, which results
in some additional configuration in addition to the standard config.
Also, some users of the BCM54810 require the PHY lanes to be swapped.
Since there is no way to detect this, add a device tree query to see if
it is applicable.
Inspired-by: Vikas Soni <vsoni@broadcom.com>
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
drivers/net/phy/Kconfig | 2 +-
drivers/net/phy/broadcom.c | 58 +++++++++++++++++++++++++++++++++++++++++++++-
include/linux/brcmphy.h | 9 +++++++
3 files changed, 67 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 45f68ea..31967ca 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -217,7 +217,7 @@ config BROADCOM_PHY
select BCM_NET_PHYLIB
---help---
Currently supports the BCM5411, BCM5421, BCM5461, BCM54616S, BCM5464,
- BCM5481 and BCM5482 PHYs.
+ BCM5481, BCM54810 and BCM5482 PHYs.
config CICADA_PHY
tristate "Cicada PHYs"
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 3a64b3d..b1e32e9 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -18,7 +18,7 @@
#include <linux/module.h>
#include <linux/phy.h>
#include <linux/brcmphy.h>
-
+#include <linux/of.h>
#define BRCM_PHY_MODEL(phydev) \
((phydev)->drv->phy_id & (phydev)->drv->phy_id_mask)
@@ -45,6 +45,34 @@ static int bcm54xx_auxctl_write(struct phy_device *phydev, u16 regnum, u16 val)
return phy_write(phydev, MII_BCM54XX_AUX_CTL, regnum | val);
}
+static int bcm54810_config(struct phy_device *phydev)
+{
+ int rc, val;
+
+ val = bcm_phy_read_exp(phydev, BCM54810_EXP_BROADREACH_LRE_MISC_CTL);
+ val &= ~BCM54810_EXP_BROADREACH_LRE_MISC_CTL_EN;
+ rc = bcm_phy_write_exp(phydev, BCM54810_EXP_BROADREACH_LRE_MISC_CTL,
+ val);
+ if (rc < 0)
+ return rc;
+
+ val = bcm54xx_auxctl_read(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC);
+ val &= ~MII_BCM54XX_AUXCTL_SHDWSEL_MISC_RGMII_SKEW_EN;
+ val |= MII_BCM54XX_AUXCTL_MISC_WREN;
+ rc = bcm54xx_auxctl_write(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC,
+ val);
+ if (rc < 0)
+ return rc;
+
+ val = bcm_phy_read_shadow(phydev, BCM54810_SHD_CLK_CTL);
+ val &= ~BCM54810_SHD_CLK_CTL_GTXCLK_EN;
+ rc = bcm_phy_write_shadow(phydev, BCM54810_SHD_CLK_CTL, val);
+ if (rc < 0)
+ return rc;
+
+ return 0;
+}
+
/* Needs SMDSP clock enabled via bcm54xx_phydsp_config() */
static int bcm50610_a0_workaround(struct phy_device *phydev)
{
@@ -217,6 +245,12 @@ static int bcm54xx_config_init(struct phy_device *phydev)
(phydev->dev_flags & PHY_BRCM_AUTO_PWRDWN_ENABLE))
bcm54xx_adjust_rxrefclk(phydev);
+ if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54810) {
+ err = bcm54810_config(phydev);
+ if (err)
+ return err;
+ }
+
bcm54xx_phydsp_config(phydev);
return 0;
@@ -314,6 +348,7 @@ static int bcm5482_read_status(struct phy_device *phydev)
static int bcm5481_config_aneg(struct phy_device *phydev)
{
+ struct device_node *np = phydev->mdio.dev.of_node;
int ret;
/* Aneg firsly. */
@@ -344,6 +379,14 @@ static int bcm5481_config_aneg(struct phy_device *phydev)
phy_write(phydev, 0x18, reg);
}
+ if (of_property_read_bool(np, "enet-phy-lane-swap")) {
+ /* Lane Swap - Undocumented register...magic! */
+ ret = bcm_phy_write_exp(phydev, MII_BCM54XX_EXP_SEL_ER + 0x9,
+ 0x11B);
+ if (ret < 0)
+ return ret;
+ }
+
return ret;
}
@@ -578,6 +621,18 @@ static struct phy_driver broadcom_drivers[] = {
.ack_interrupt = bcm_phy_ack_intr,
.config_intr = bcm_phy_config_intr,
}, {
+ .phy_id = PHY_ID_BCM54810,
+ .phy_id_mask = 0xfffffff0,
+ .name = "Broadcom BCM54810",
+ .features = PHY_GBIT_FEATURES |
+ SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+ .config_init = bcm54xx_config_init,
+ .config_aneg = bcm5481_config_aneg,
+ .read_status = genphy_read_status,
+ .ack_interrupt = bcm_phy_ack_intr,
+ .config_intr = bcm_phy_config_intr,
+}, {
.phy_id = PHY_ID_BCM5482,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM5482",
@@ -661,6 +716,7 @@ static struct mdio_device_id __maybe_unused broadcom_tbl[] = {
{ PHY_ID_BCM54616S, 0xfffffff0 },
{ PHY_ID_BCM5464, 0xfffffff0 },
{ PHY_ID_BCM5481, 0xfffffff0 },
+ { PHY_ID_BCM54810, 0xfffffff0 },
{ PHY_ID_BCM5482, 0xfffffff0 },
{ PHY_ID_BCM50610, 0xfffffff0 },
{ PHY_ID_BCM50610M, 0xfffffff0 },
diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
index 0ed6691..848dc50 100644
--- a/include/linux/brcmphy.h
+++ b/include/linux/brcmphy.h
@@ -13,6 +13,7 @@
#define PHY_ID_BCM5241 0x0143bc30
#define PHY_ID_BCMAC131 0x0143bc70
#define PHY_ID_BCM5481 0x0143bca0
+#define PHY_ID_BCM54810 0x03625d00
#define PHY_ID_BCM5482 0x0143bcb0
#define PHY_ID_BCM5411 0x00206070
#define PHY_ID_BCM5421 0x002060e0
@@ -56,6 +57,7 @@
#define PHY_BRCM_EXT_IBND_TX_ENABLE 0x00002000
#define PHY_BRCM_CLEAR_RGMII_MODE 0x00004000
#define PHY_BRCM_DIS_TXCRXC_NOENRGY 0x00008000
+
/* Broadcom BCM7xxx specific workarounds */
#define PHY_BRCM_7XXX_REV(x) (((x) >> 8) & 0xff)
#define PHY_BRCM_7XXX_PATCH(x) ((x) & 0xff)
@@ -111,6 +113,7 @@
#define MII_BCM54XX_AUXCTL_MISC_RDSEL_MISC 0x7000
#define MII_BCM54XX_AUXCTL_SHDWSEL_MISC 0x0007
#define MII_BCM54XX_AUXCTL_SHDWSEL_READ_SHIFT 12
+#define MII_BCM54XX_AUXCTL_SHDWSEL_MISC_RGMII_SKEW_EN (1 << 8)
#define MII_BCM54XX_AUXCTL_SHDWSEL_MASK 0x0007
@@ -192,6 +195,12 @@
#define BCM5482_SSD_SGMII_SLAVE_EN 0x0002 /* Slave mode enable */
#define BCM5482_SSD_SGMII_SLAVE_AD 0x0001 /* Slave auto-detection */
+/* BCM54810 Registers */
+#define BCM54810_EXP_BROADREACH_LRE_MISC_CTL (MII_BCM54XX_EXP_SEL_ER + 0x90)
+#define BCM54810_EXP_BROADREACH_LRE_MISC_CTL_EN (1 << 0)
+#define BCM54810_SHD_CLK_CTL 0x3
+#define BCM54810_SHD_CLK_CTL_GTXCLK_EN (1 << 9)
+
/*****************************************************************************/
/* Fast Ethernet Transceiver definitions. */
--
2.7.4
^ permalink raw reply related
* [PATCH v4 4/7] Documentation: devicetree: net: add NS2 bindings to amac
From: Jon Mason @ 2016-11-01 20:04 UTC (permalink / raw)
To: David Miller, Rob Herring, Mark Rutland, Florian Fainelli
Cc: rafal, bcm-kernel-feedback-list, netdev, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1478030682-27012-1-git-send-email-jon.mason@broadcom.com>
Clean-up the documentation to the bgmac-amac driver, per suggestion by
Rob Herring, and add details for NS2 support.
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
Documentation/devicetree/bindings/net/brcm,amac.txt | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/brcm,amac.txt b/Documentation/devicetree/bindings/net/brcm,amac.txt
index ba5ecc1..2fefa1a 100644
--- a/Documentation/devicetree/bindings/net/brcm,amac.txt
+++ b/Documentation/devicetree/bindings/net/brcm,amac.txt
@@ -2,11 +2,17 @@ Broadcom AMAC Ethernet Controller Device Tree Bindings
-------------------------------------------------------------
Required properties:
- - compatible: "brcm,amac" or "brcm,nsp-amac"
- - reg: Address and length of the GMAC registers,
- Address and length of the GMAC IDM registers
- - reg-names: Names of the registers. Must have both "amac_base" and
- "idm_base"
+ - compatible: "brcm,amac"
+ "brcm,nsp-amac"
+ "brcm,ns2-amac"
+ - reg: Address and length of the register set for the device. It
+ contains the information of registers in the same order as
+ described by reg-names
+ - reg-names: Names of the registers.
+ "amac_base": Address and length of the GMAC registers
+ "idm_base": Address and length of the GMAC IDM registers
+ "nicpm_base": Address and length of the NIC Port Manager
+ registers (required for Northstar2)
- interrupts: Interrupt number
Optional properties:
--
2.7.4
^ permalink raw reply related
* [PATCH v4 5/7] net: ethernet: bgmac: device tree phy enablement
From: Jon Mason @ 2016-11-01 20:04 UTC (permalink / raw)
To: David Miller, Rob Herring, Mark Rutland, Florian Fainelli
Cc: rafal-g1n6cQUeyibVItvQsEIGlw,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1478030682-27012-1-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Change the bgmac driver to allow for phy's defined by the device tree
Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
---
drivers/net/ethernet/broadcom/bgmac-bcma.c | 48 ++++++++++++++++++++++++
drivers/net/ethernet/broadcom/bgmac-platform.c | 48 +++++++++++++++++++++++-
drivers/net/ethernet/broadcom/bgmac.c | 52 ++------------------------
drivers/net/ethernet/broadcom/bgmac.h | 7 ++++
4 files changed, 105 insertions(+), 50 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac-bcma.c b/drivers/net/ethernet/broadcom/bgmac-bcma.c
index c16ec3a..3e3efde 100644
--- a/drivers/net/ethernet/broadcom/bgmac-bcma.c
+++ b/drivers/net/ethernet/broadcom/bgmac-bcma.c
@@ -80,6 +80,50 @@ static void bcma_bgmac_cmn_maskset32(struct bgmac *bgmac, u16 offset, u32 mask,
bcma_maskset32(bgmac->bcma.cmn, offset, mask, set);
}
+static int bcma_phy_connect(struct bgmac *bgmac)
+{
+ struct phy_device *phy_dev;
+ char bus_id[MII_BUS_ID_SIZE + 3];
+
+ /* Connect to the PHY */
+ snprintf(bus_id, sizeof(bus_id), PHY_ID_FMT, bgmac->mii_bus->id,
+ bgmac->phyaddr);
+ phy_dev = phy_connect(bgmac->net_dev, bus_id, bgmac_adjust_link,
+ PHY_INTERFACE_MODE_MII);
+ if (IS_ERR(phy_dev)) {
+ dev_err(bgmac->dev, "PHY connecton failed\n");
+ return PTR_ERR(phy_dev);
+ }
+
+ return 0;
+}
+
+static int bcma_phy_direct_connect(struct bgmac *bgmac)
+{
+ struct fixed_phy_status fphy_status = {
+ .link = 1,
+ .speed = SPEED_1000,
+ .duplex = DUPLEX_FULL,
+ };
+ struct phy_device *phy_dev;
+ int err;
+
+ phy_dev = fixed_phy_register(PHY_POLL, &fphy_status, -1, NULL);
+ if (!phy_dev || IS_ERR(phy_dev)) {
+ dev_err(bgmac->dev, "Failed to register fixed PHY device\n");
+ return -ENODEV;
+ }
+
+ err = phy_connect_direct(bgmac->net_dev, phy_dev, bgmac_adjust_link,
+ PHY_INTERFACE_MODE_MII);
+ if (err) {
+ dev_err(bgmac->dev, "Connecting PHY failed\n");
+ return err;
+ }
+
+ return err;
+}
+
static const struct bcma_device_id bgmac_bcma_tbl[] = {
BCMA_CORE(BCMA_MANUF_BCM, BCMA_CORE_4706_MAC_GBIT,
BCMA_ANY_REV, BCMA_ANY_CLASS),
@@ -275,6 +319,10 @@ static int bgmac_probe(struct bcma_device *core)
bgmac->cco_ctl_maskset = bcma_bgmac_cco_ctl_maskset;
bgmac->get_bus_clock = bcma_bgmac_get_bus_clock;
bgmac->cmn_maskset32 = bcma_bgmac_cmn_maskset32;
+ if (bgmac->mii_bus)
+ bgmac->phy_connect = bcma_phy_connect;
+ else
+ bgmac->phy_connect = bcma_phy_direct_connect;
err = bgmac_enet_probe(bgmac);
if (err)
diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c b/drivers/net/ethernet/broadcom/bgmac-platform.c
index be52f27..aed5dc5 100644
--- a/drivers/net/ethernet/broadcom/bgmac-platform.c
+++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
@@ -16,6 +16,7 @@
#include <linux/bcma/bcma.h>
#include <linux/etherdevice.h>
#include <linux/of_address.h>
+#include <linux/of_mdio.h>
#include <linux/of_net.h>
#include "bgmac.h"
@@ -86,6 +87,46 @@ static void platform_bgmac_cmn_maskset32(struct bgmac *bgmac, u16 offset,
WARN_ON(1);
}
+static int platform_phy_connect(struct bgmac *bgmac)
+{
+ struct phy_device *phy_dev;
+
+ phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
+ bgmac_adjust_link);
+ if (!phy_dev) {
+ dev_err(bgmac->dev, "Phy connect failed\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static int platform_phy_direct_connect(struct bgmac *bgmac)
+{
+ struct fixed_phy_status fphy_status = {
+ .link = 1,
+ .speed = SPEED_1000,
+ .duplex = DUPLEX_FULL,
+ };
+ struct phy_device *phy_dev;
+ int err;
+
+ phy_dev = fixed_phy_register(PHY_POLL, &fphy_status, -1, NULL);
+ if (!phy_dev || IS_ERR(phy_dev)) {
+ dev_err(bgmac->dev, "Failed to register fixed PHY device\n");
+ return -ENODEV;
+ }
+
+ err = phy_connect_direct(bgmac->net_dev, phy_dev, bgmac_adjust_link,
+ PHY_INTERFACE_MODE_MII);
+ if (err) {
+ dev_err(bgmac->dev, "Connecting PHY failed\n");
+ return err;
+ }
+
+ return err;
+}
+
static int bgmac_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
@@ -102,7 +143,6 @@ static int bgmac_probe(struct platform_device *pdev)
/* Set the features of the 4707 family */
bgmac->feature_flags |= BGMAC_FEAT_CLKCTLST;
bgmac->feature_flags |= BGMAC_FEAT_NO_RESET;
- bgmac->feature_flags |= BGMAC_FEAT_FORCE_SPEED_2500;
bgmac->feature_flags |= BGMAC_FEAT_CMDCFG_SR_REV4;
bgmac->feature_flags |= BGMAC_FEAT_TX_MASK_SETUP;
bgmac->feature_flags |= BGMAC_FEAT_RX_MASK_SETUP;
@@ -151,6 +191,12 @@ static int bgmac_probe(struct platform_device *pdev)
bgmac->cco_ctl_maskset = platform_bgmac_cco_ctl_maskset;
bgmac->get_bus_clock = platform_bgmac_get_bus_clock;
bgmac->cmn_maskset32 = platform_bgmac_cmn_maskset32;
+ if (of_parse_phandle(np, "phy-handle", 0)) {
+ bgmac->phy_connect = platform_phy_connect;
+ } else {
+ bgmac->phy_connect = platform_phy_direct_connect;
+ bgmac->feature_flags |= BGMAC_FEAT_FORCE_SPEED_2500;
+ }
return bgmac_enet_probe(bgmac);
}
diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
index 856379c..4584958 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -1388,7 +1388,7 @@ static const struct ethtool_ops bgmac_ethtool_ops = {
* MII
**************************************************/
-static void bgmac_adjust_link(struct net_device *net_dev)
+void bgmac_adjust_link(struct net_device *net_dev)
{
struct bgmac *bgmac = netdev_priv(net_dev);
struct phy_device *phy_dev = net_dev->phydev;
@@ -1411,50 +1411,7 @@ static void bgmac_adjust_link(struct net_device *net_dev)
phy_print_status(phy_dev);
}
}
-
-static int bgmac_phy_connect_direct(struct bgmac *bgmac)
-{
- struct fixed_phy_status fphy_status = {
- .link = 1,
- .speed = SPEED_1000,
- .duplex = DUPLEX_FULL,
- };
- struct phy_device *phy_dev;
- int err;
-
- phy_dev = fixed_phy_register(PHY_POLL, &fphy_status, -1, NULL);
- if (!phy_dev || IS_ERR(phy_dev)) {
- dev_err(bgmac->dev, "Failed to register fixed PHY device\n");
- return -ENODEV;
- }
-
- err = phy_connect_direct(bgmac->net_dev, phy_dev, bgmac_adjust_link,
- PHY_INTERFACE_MODE_MII);
- if (err) {
- dev_err(bgmac->dev, "Connecting PHY failed\n");
- return err;
- }
-
- return err;
-}
-
-static int bgmac_phy_connect(struct bgmac *bgmac)
-{
- struct phy_device *phy_dev;
- char bus_id[MII_BUS_ID_SIZE + 3];
-
- /* Connect to the PHY */
- snprintf(bus_id, sizeof(bus_id), PHY_ID_FMT, bgmac->mii_bus->id,
- bgmac->phyaddr);
- phy_dev = phy_connect(bgmac->net_dev, bus_id, &bgmac_adjust_link,
- PHY_INTERFACE_MODE_MII);
- if (IS_ERR(phy_dev)) {
- dev_err(bgmac->dev, "PHY connecton failed\n");
- return PTR_ERR(phy_dev);
- }
-
- return 0;
-}
+EXPORT_SYMBOL_GPL(bgmac_adjust_link);
int bgmac_enet_probe(struct bgmac *info)
{
@@ -1507,10 +1464,7 @@ int bgmac_enet_probe(struct bgmac *info)
netif_napi_add(net_dev, &bgmac->napi, bgmac_poll, BGMAC_WEIGHT);
- if (!bgmac->mii_bus)
- err = bgmac_phy_connect_direct(bgmac);
- else
- err = bgmac_phy_connect(bgmac);
+ err = bgmac_phy_connect(bgmac);
if (err) {
dev_err(bgmac->dev, "Cannot connect to phy\n");
goto err_dma_free;
diff --git a/drivers/net/ethernet/broadcom/bgmac.h b/drivers/net/ethernet/broadcom/bgmac.h
index 80836b4..ea52ac3 100644
--- a/drivers/net/ethernet/broadcom/bgmac.h
+++ b/drivers/net/ethernet/broadcom/bgmac.h
@@ -513,10 +513,12 @@ struct bgmac {
u32 (*get_bus_clock)(struct bgmac *bgmac);
void (*cmn_maskset32)(struct bgmac *bgmac, u16 offset, u32 mask,
u32 set);
+ int (*phy_connect)(struct bgmac *bgmac);
};
int bgmac_enet_probe(struct bgmac *info);
void bgmac_enet_remove(struct bgmac *bgmac);
+void bgmac_adjust_link(struct net_device *net_dev);
struct mii_bus *bcma_mdio_mii_register(struct bcma_device *core, u8 phyaddr);
void bcma_mdio_mii_unregister(struct mii_bus *mii_bus);
@@ -583,4 +585,9 @@ static inline void bgmac_set(struct bgmac *bgmac, u16 offset, u32 set)
{
bgmac_maskset(bgmac, offset, ~0, set);
}
+
+static inline int bgmac_phy_connect(struct bgmac *bgmac)
+{
+ return bgmac->phy_connect(bgmac);
+}
#endif /* _BGMAC_H */
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 6/7] net: ethernet: bgmac: add NS2 support
From: Jon Mason @ 2016-11-01 20:04 UTC (permalink / raw)
To: David Miller, Rob Herring, Mark Rutland, Florian Fainelli
Cc: rafal, bcm-kernel-feedback-list, netdev, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1478030682-27012-1-git-send-email-jon.mason@broadcom.com>
Add support for the variant of amac hardware present in the Broadcom
Northstar2 based SoCs. Northstar2 requires an additional register to be
configured with the port speed/duplexity (NICPM). This can be added to
the link callback to hide it from the instances that do not use this.
Also, clearing of the pending interrupts on init is required due to
observed issues on some platforms.
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
drivers/net/ethernet/broadcom/bgmac-platform.c | 56 +++++++++++++++++++++++++-
drivers/net/ethernet/broadcom/bgmac.c | 3 ++
drivers/net/ethernet/broadcom/bgmac.h | 1 +
3 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c b/drivers/net/ethernet/broadcom/bgmac-platform.c
index aed5dc5..f6d48c7 100644
--- a/drivers/net/ethernet/broadcom/bgmac-platform.c
+++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
@@ -14,12 +14,21 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/bcma/bcma.h>
+#include <linux/brcmphy.h>
#include <linux/etherdevice.h>
#include <linux/of_address.h>
#include <linux/of_mdio.h>
#include <linux/of_net.h>
#include "bgmac.h"
+#define NICPM_IOMUX_CTRL 0x00000008
+
+#define NICPM_IOMUX_CTRL_INIT_VAL 0x3196e000
+#define NICPM_IOMUX_CTRL_SPD_SHIFT 10
+#define NICPM_IOMUX_CTRL_SPD_10M 0
+#define NICPM_IOMUX_CTRL_SPD_100M 1
+#define NICPM_IOMUX_CTRL_SPD_1000M 2
+
static u32 platform_bgmac_read(struct bgmac *bgmac, u16 offset)
{
return readl(bgmac->plat.base + offset);
@@ -87,12 +96,46 @@ static void platform_bgmac_cmn_maskset32(struct bgmac *bgmac, u16 offset,
WARN_ON(1);
}
+static void bgmac_nicpm_speed_set(struct net_device *net_dev)
+{
+ struct bgmac *bgmac = netdev_priv(net_dev);
+ u32 val;
+
+ if (!bgmac->plat.nicpm_base)
+ return;
+
+ val = NICPM_IOMUX_CTRL_INIT_VAL;
+ switch (bgmac->net_dev->phydev->speed) {
+ default:
+ pr_err("Unsupported speed. Defaulting to 1000Mb\n");
+ case SPEED_1000:
+ val |= NICPM_IOMUX_CTRL_SPD_1000M << NICPM_IOMUX_CTRL_SPD_SHIFT;
+ break;
+ case SPEED_100:
+ val |= NICPM_IOMUX_CTRL_SPD_100M << NICPM_IOMUX_CTRL_SPD_SHIFT;
+ break;
+ case SPEED_10:
+ val |= NICPM_IOMUX_CTRL_SPD_10M << NICPM_IOMUX_CTRL_SPD_SHIFT;
+ break;
+ }
+
+ writel(val, bgmac->plat.nicpm_base + NICPM_IOMUX_CTRL);
+
+ bgmac_adjust_link(bgmac->net_dev);
+}
+
static int platform_phy_connect(struct bgmac *bgmac)
{
struct phy_device *phy_dev;
- phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
- bgmac_adjust_link);
+ if (bgmac->plat.nicpm_base)
+ phy_dev = of_phy_get_and_connect(bgmac->net_dev,
+ bgmac->dev->of_node,
+ bgmac_nicpm_speed_set);
+ else
+ phy_dev = of_phy_get_and_connect(bgmac->net_dev,
+ bgmac->dev->of_node,
+ bgmac_adjust_link);
if (!phy_dev) {
dev_err(bgmac->dev, "Phy connect failed\n");
return -ENODEV;
@@ -182,6 +225,14 @@ static int bgmac_probe(struct platform_device *pdev)
if (IS_ERR(bgmac->plat.idm_base))
return PTR_ERR(bgmac->plat.idm_base);
+ regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nicpm_base");
+ if (regs) {
+ bgmac->plat.nicpm_base = devm_ioremap_resource(&pdev->dev,
+ regs);
+ if (IS_ERR(bgmac->plat.nicpm_base))
+ return PTR_ERR(bgmac->plat.nicpm_base);
+ }
+
bgmac->read = platform_bgmac_read;
bgmac->write = platform_bgmac_write;
bgmac->idm_read = platform_bgmac_idm_read;
@@ -213,6 +264,7 @@ static int bgmac_remove(struct platform_device *pdev)
static const struct of_device_id bgmac_of_enet_match[] = {
{.compatible = "brcm,amac",},
{.compatible = "brcm,nsp-amac",},
+ {.compatible = "brcm,ns2-amac",},
{},
};
diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
index 4584958..a805cc8 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -1082,6 +1082,9 @@ static void bgmac_enable(struct bgmac *bgmac)
/* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipinit */
static void bgmac_chip_init(struct bgmac *bgmac)
{
+ /* Clear any erroneously pending interrupts */
+ bgmac_write(bgmac, BGMAC_INT_STATUS, ~0);
+
/* 1 interrupt per received frame */
bgmac_write(bgmac, BGMAC_INT_RECV_LAZY, 1 << BGMAC_IRL_FC_SHIFT);
diff --git a/drivers/net/ethernet/broadcom/bgmac.h b/drivers/net/ethernet/broadcom/bgmac.h
index ea52ac3..b1820ea 100644
--- a/drivers/net/ethernet/broadcom/bgmac.h
+++ b/drivers/net/ethernet/broadcom/bgmac.h
@@ -463,6 +463,7 @@ struct bgmac {
struct {
void *base;
void *idm_base;
+ void *nicpm_base;
} plat;
struct {
struct bcma_device *core;
--
2.7.4
^ permalink raw reply related
* [PATCH] net: ip, diag -- Adjust raw_abort to use unlocked __udp_disconnect
From: Cyrill Gorcunov @ 2016-11-01 20:05 UTC (permalink / raw)
To: netdev, eric.dumazet
Cc: David Miller, dsa, jhs, linux-kernel, kuznet, jmorris, yoshfuji,
kaber, avagin, stephen
While being preparing patches for killing raw sockets via
diag netlink interface I noticed that my runs are stuck:
| [root@pcs7 ~]# cat /proc/`pidof ss`/stack
| [<ffffffff816d1a76>] __lock_sock+0x80/0xc4
| [<ffffffff816d206a>] lock_sock_nested+0x47/0x95
| [<ffffffff8179ded6>] udp_disconnect+0x19/0x33
| [<ffffffff8179b517>] raw_abort+0x33/0x42
| [<ffffffff81702322>] sock_diag_destroy+0x4d/0x52
which has not been the case before. I narrowed it down to the commit
| commit 286c72deabaa240b7eebbd99496ed3324d69f3c0
| Author: Eric Dumazet <edumazet@google.com>
| Date: Thu Oct 20 09:39:40 2016 -0700
|
| udp: must lock the socket in udp_disconnect()
where we start locking the socket for different reason.
So the raw_abort escaped the renaming and we have to
fix this typo using __udp_disconnect instead.
CC: David S. Miller <davem@davemloft.net>
CC: Eric Dumazet <eric.dumazet@gmail.com>
CC: David Ahern <dsa@cumulusnetworks.com>
CC: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
CC: James Morris <jmorris@namei.org>
CC: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
CC: Patrick McHardy <kaber@trash.net>
CC: Andrey Vagin <avagin@openvz.org>
CC: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
---
On top of net-next tree 22ca904ad70afc831d8503e80be1b6558a978759
net/ipv4/raw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-ml.git/net/ipv4/raw.c
===================================================================
--- linux-ml.git.orig/net/ipv4/raw.c
+++ linux-ml.git/net/ipv4/raw.c
@@ -920,7 +920,7 @@ int raw_abort(struct sock *sk, int err)
sk->sk_err = err;
sk->sk_error_report(sk);
- udp_disconnect(sk, 0);
+ __udp_disconnect(sk, 0);
release_sock(sk);
^ permalink raw reply
* [PATCH v4 7/7] arm64: dts: NS2: add AMAC ethernet support
From: Jon Mason @ 2016-11-01 20:04 UTC (permalink / raw)
To: David Miller, Rob Herring, Mark Rutland, Florian Fainelli
Cc: rafal, bcm-kernel-feedback-list, netdev, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1478030682-27012-1-git-send-email-jon.mason@broadcom.com>
Add support for the AMAC ethernet to the Broadcom Northstar2 SoC device
tree
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
arch/arm64/boot/dts/broadcom/ns2-svk.dts | 5 +++++
arch/arm64/boot/dts/broadcom/ns2.dtsi | 12 ++++++++++++
2 files changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index 2d7872a..2e4d90d 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -56,6 +56,10 @@
};
};
+&enet {
+ status = "ok";
+};
+
&pci_phy0 {
status = "ok";
};
@@ -172,6 +176,7 @@
&mdio_mux_iproc {
mdio@10 {
gphy0: eth-phy@10 {
+ enet-phy-lane-swap;
reg = <0x10>;
};
};
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index d95dc40..773ed59 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -191,6 +191,18 @@
#include "ns2-clock.dtsi"
+ enet: ethernet@61000000 {
+ compatible = "brcm,ns2-amac";
+ reg = <0x61000000 0x1000>,
+ <0x61090000 0x1000>,
+ <0x61030000 0x100>;
+ reg-names = "amac_base", "idm_base", "nicpm_base";
+ interrupts = <GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH>;
+ phy-handle = <&gphy0>;
+ phy-mode = "rgmii";
+ status = "disabled";
+ };
+
dma0: dma@61360000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x61360000 0x1000>;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation
From: Hannes Frederic Sowa @ 2016-11-01 20:08 UTC (permalink / raw)
To: Thomas Graf
Cc: David S. Miller, Alexei Starovoitov, Daniel Borkmann, Tom Herbert,
roopa, netdev
In-Reply-To: <CACby=pmK9Pj00LYx9PQrgWe95xmy=qFhpjSYZT=QDnLQ55J=8w@mail.gmail.com>
On Tue, Nov 1, 2016, at 19:51, Thomas Graf wrote:
> On 1 November 2016 at 03:54, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
> > I do fear the complexity and debugability introduced by this patch set
> > quite a bit.
>
> What is the complexity concern? This is pretty straight forward. I
> agree on debugability. This is being worked on separately as Alexei
> mentioned, to address this for all BPF integrations.
We have a multi-layered policy engine which is actually hard to inspect
from user space already.
We first resolve the rules, with forwards us to the table_id, where we
do the fib lookup, which in the end returns the eBPF program to use.
> > I wonder if architecturally it would be more feasible to add a generic
> > (bfp-)hook into into dst_output(_sk) and allow arbitrary metadata to be
> > added into the dsts.
> >
> > BPF could then be able to access parts of the metadata in the attached
> > metadata dst entries and performing the matching this way?
>
> If I understand you correctly then a single BPF program would be
> loaded which then applies to all dst_output() calls? This has a huge
> drawback, instead of multiple small BPF programs which do exactly what
> is required per dst, a large BPF program is needed which matches on
> metadata. That's way slower and renders one of the biggest advantages
> of BPF invalid, the ability to generate a a small program tailored to
> a particular use. See Cilium.
I thought more of hooks in the actual output/input functions specific to
the protocol type (unfortunately again) protected by jump labels? Those
hook get part of the dst_entry mapped so they can act on them.
Another idea would be to put the eBPF hooks into the fib rules
infrastructure. But I fear this wouldn't get you the hooks you were
looking for? There they would only end up in the runtime path if
actually activated.
> > The reason why I would prefer an approach like this: irregardless of the
> > routing lookup we would process the skb with bpf or not. This gives a
> > single point to debug, where instead in your approach we first must
> > figure out the corresponding bpf program and then check for it specifically.
>
> Not sure I see what kind of advantage this actually provides. You can
> dump the routes and see which programs get invoked and which section.
Dumping and verifying which routes get used might actually already be
quite complex on its own. Thus my fear.
> If it's based on metadata then you need to know the program logic and
> associate it with the metadata in the dst. It actually doesn't get
> much easier than to debug one of the samples, they are completely
> static once compiled and it's very simple to verify if they do what
> they are supposed to do.
At the same time you can have lots of those programs and you e.g. would
also need to verify if they are acting on the same data structures or
have the identical code.
It all reminds me a bit on grepping in source code which makes heavy use
of function pointers with very generic and short names.
> If you like the single program approach, feel free to load the same
> program for every dst. Perfectly acceptable but I don't see why we
> should force everybody to use that model.
I am concerned having 100ths of BPF programs, all specialized on a
particular route, to debug. Looking at one code file and its associated
tables seems still easier to me.
E.g. imaging we have input routes and output routes with different BPF
programs. We somehow must make sure all nodes kind of behave accordingly
to "sane" network semantics. If you end up with an input route doing bpf
processing and the according output node, which e.g. might be needed to
reflect ICMP packets, doesn't behave accordingly you at least have two
programs to debug already instead of a switch- or if-condition in one
single code location. I would like to "force" this kind of symmetry to
developers using eBPF, thus I thought meta-data manipulation and
verification inside the kernel would be a better attack at this problem,
no?
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH net-next v2 3/5] bpf: BPF for lightweight tunnel encapsulation
From: David Ahern @ 2016-11-01 20:11 UTC (permalink / raw)
To: Thomas Graf, davem; +Cc: alexei.starovoitov, daniel, tom, roopa, netdev
In-Reply-To: <d8c7e07ac7d289a2846af8d659287f3512a4edec.1477959702.git.tgraf@suug.ch>
On 10/31/16 6:37 PM, Thomas Graf wrote:
> Register two new BPF prog types BPF_PROG_TYPE_LWT_IN and
> BPF_PROG_TYPE_LWT_OUT which are invoked if a route contains a
> LWT redirection of type LWTUNNEL_ENCAP_BPF.
>
> The separate program types are required because manipulation of
> packet data is only allowed on the output and transmit path as
> the subsequent dst_input() call path assumes an IP header
> validated by ip_rcv(). The BPF programs will be handed an skb
> with the L3 header attached and may return one of the following
> return codes:
>
> BPF_OK - Continue routing as per nexthop
> BPF_DROP - Drop skb and return EPERM
> BPF_REDIRECT - Redirect skb to device as per redirect() helper.
> (Only valid on lwtunnel_xmit() hook)
>
> The return codes are binary compatible with their TC_ACT_
> relatives to ease compatibility.
>
> A new helper bpf_skb_push() is added which allows to preprend an
> L2 header in front of the skb, extend the existing L3 header, or
> both. This allows to address a wide range of issues:
> - Optimize L2 header construction when L2 information is always
> static to avoid ARP/NDisc lookup.
> - Extend IP header to add additional IP options.
> - Perform simple encapsulation where offload is of no concern.
> (The existing funtionality to attach a tunnel key to the skb
> and redirect to a tunnel net_device to allow for offload
> continues to work obviously).
have you tested the adding of headers with large packets hitting gso and fragmentation? Wondering if mtu is used properly when headers are added and the lwt->headroom is not accounted. See 14972cbd34ff668c390cbd2e6497323484c9e812
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation
From: Tom Herbert @ 2016-11-01 20:33 UTC (permalink / raw)
To: Thomas Graf
Cc: David S. Miller, Alexei Starovoitov, Daniel Borkmann, roopa,
Linux Kernel Network Developers
In-Reply-To: <CACby=p=pjsSmu8EWWomm-MLE2E+H9BSs9Y2ZAiH2Jh67gScMsw@mail.gmail.com>
On Tue, Nov 1, 2016 at 12:59 PM, Thomas Graf <tgraf@suug.ch> wrote:
> On 1 November 2016 at 12:27, Tom Herbert <tom@herbertland.com> wrote:
>> On Tue, Nov 1, 2016 at 12:11 PM, Thomas Graf <tgraf@suug.ch> wrote:
>>> You can do the same with act_pedit or cls_bpf at dev_queue_xmit()
>>> before or after you go into the encapsulation device. This is a tool
>>> for root, if you install a drop all ssh rule then you won't be able to
>>> log into the box anymore. If you modify the packet and render it
>>> invalid, the packet will be dropped.
>>> If you attach a VLAN header while VLAN offload is already set up, then
>>> the hardware will add another VLAN header, this is what I would
>>> expect. I truly hope that we don't have code which crashes if we
>>> dev_queue_xmit() garbage into any device. That would be horrible.
>>>
>>> Do you have a specific example that could be a problem?
>>
>> I believe Alexander was dealing with problems where drivers were not
>> properly handling IP extension headers. We regularly get reports about
>
> There are many ways to cause IP extension headers to be inserted. How
> is this specific to BPF or this series?
>
>> driver checksum failures on edge conditions. Making a fully functional
>
> Not sure what an "edge condition" is? Untrusted networks? How is
> drivers crashing on receive related to this series?
>
>> and efficient transmit data path is nontrivial, there are many
>> assumptions being made some documented some not. When drivers crash we
>> either fix the driver or the protocol stack that is doing something
>> bad.
>
> Tom, we have a dozen ways to modify packet content already and we have
> multiple ways to take raw packet data from userspace and inject them
> at dev_queue_xmit() level and some even above. What is different for
> lwtunnel_xmit()?
>
> This is entirely optional and nobody is forced to use any of this. If
> you don't trust the BPF program then you better not run in. It's about
> the same as trusting a random tc filter or iptables ruleset. The
> important point is that integrity is maintained at all times.I would
> love to address any specific concern.
You need to show that is integrity is maintained with these patches.
Part of this can be done, but part of this needs to be established in
testing.
I've already given specifics for at least one potential source of
issues in routing issues. I would like to know what happens if someone
rewrites an IPv4 packet into IPv6 packet or vice versa. AFAICT we
would be send an IPv6 using an IPv4 route, or an IPv4 using an IPv6
route. What is supposed to happen in these circumstances? What
actually happens?
Similarly, someone overwrites the whole packet with 0xff. What happens
when we try to send that?
Tom
^ permalink raw reply
* Re: [PATCH v4 6/7] net: ethernet: bgmac: add NS2 support
From: Scott Branden @ 2016-11-01 20:34 UTC (permalink / raw)
To: Jon Mason, David Miller, Rob Herring, Mark Rutland,
Florian Fainelli
Cc: rafal, bcm-kernel-feedback-list, netdev, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1478030682-27012-7-git-send-email-jon.mason@broadcom.com>
One change in this patch
On 16-11-01 01:04 PM, Jon Mason wrote:
> Add support for the variant of amac hardware present in the Broadcom
> Northstar2 based SoCs. Northstar2 requires an additional register to be
> configured with the port speed/duplexity (NICPM). This can be added to
> the link callback to hide it from the instances that do not use this.
> Also, clearing of the pending interrupts on init is required due to
> observed issues on some platforms.
>
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> ---
> drivers/net/ethernet/broadcom/bgmac-platform.c | 56 +++++++++++++++++++++++++-
> drivers/net/ethernet/broadcom/bgmac.c | 3 ++
> drivers/net/ethernet/broadcom/bgmac.h | 1 +
> 3 files changed, 58 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c b/drivers/net/ethernet/broadcom/bgmac-platform.c
> index aed5dc5..f6d48c7 100644
> --- a/drivers/net/ethernet/broadcom/bgmac-platform.c
> +++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
> @@ -14,12 +14,21 @@
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> #include <linux/bcma/bcma.h>
> +#include <linux/brcmphy.h>
> #include <linux/etherdevice.h>
> #include <linux/of_address.h>
> #include <linux/of_mdio.h>
> #include <linux/of_net.h>
> #include "bgmac.h"
>
> +#define NICPM_IOMUX_CTRL 0x00000008
> +
> +#define NICPM_IOMUX_CTRL_INIT_VAL 0x3196e000
> +#define NICPM_IOMUX_CTRL_SPD_SHIFT 10
> +#define NICPM_IOMUX_CTRL_SPD_10M 0
> +#define NICPM_IOMUX_CTRL_SPD_100M 1
> +#define NICPM_IOMUX_CTRL_SPD_1000M 2
> +
> static u32 platform_bgmac_read(struct bgmac *bgmac, u16 offset)
> {
> return readl(bgmac->plat.base + offset);
> @@ -87,12 +96,46 @@ static void platform_bgmac_cmn_maskset32(struct bgmac *bgmac, u16 offset,
> WARN_ON(1);
> }
>
> +static void bgmac_nicpm_speed_set(struct net_device *net_dev)
> +{
> + struct bgmac *bgmac = netdev_priv(net_dev);
> + u32 val;
> +
> + if (!bgmac->plat.nicpm_base)
> + return;
> +
> + val = NICPM_IOMUX_CTRL_INIT_VAL;
> + switch (bgmac->net_dev->phydev->speed) {
> + default:
> + pr_err("Unsupported speed. Defaulting to 1000Mb\n");
This should be dev_err
> + case SPEED_1000:
> + val |= NICPM_IOMUX_CTRL_SPD_1000M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> + break;
> + case SPEED_100:
> + val |= NICPM_IOMUX_CTRL_SPD_100M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> + break;
> + case SPEED_10:
> + val |= NICPM_IOMUX_CTRL_SPD_10M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> + break;
> + }
> +
> + writel(val, bgmac->plat.nicpm_base + NICPM_IOMUX_CTRL);
> +
> + bgmac_adjust_link(bgmac->net_dev);
> +}
> +
> static int platform_phy_connect(struct bgmac *bgmac)
> {
> struct phy_device *phy_dev;
>
> - phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
> - bgmac_adjust_link);
> + if (bgmac->plat.nicpm_base)
> + phy_dev = of_phy_get_and_connect(bgmac->net_dev,
> + bgmac->dev->of_node,
> + bgmac_nicpm_speed_set);
> + else
> + phy_dev = of_phy_get_and_connect(bgmac->net_dev,
> + bgmac->dev->of_node,
> + bgmac_adjust_link);
> if (!phy_dev) {
> dev_err(bgmac->dev, "Phy connect failed\n");
> return -ENODEV;
> @@ -182,6 +225,14 @@ static int bgmac_probe(struct platform_device *pdev)
> if (IS_ERR(bgmac->plat.idm_base))
> return PTR_ERR(bgmac->plat.idm_base);
>
> + regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nicpm_base");
> + if (regs) {
> + bgmac->plat.nicpm_base = devm_ioremap_resource(&pdev->dev,
> + regs);
> + if (IS_ERR(bgmac->plat.nicpm_base))
> + return PTR_ERR(bgmac->plat.nicpm_base);
> + }
> +
> bgmac->read = platform_bgmac_read;
> bgmac->write = platform_bgmac_write;
> bgmac->idm_read = platform_bgmac_idm_read;
> @@ -213,6 +264,7 @@ static int bgmac_remove(struct platform_device *pdev)
> static const struct of_device_id bgmac_of_enet_match[] = {
> {.compatible = "brcm,amac",},
> {.compatible = "brcm,nsp-amac",},
> + {.compatible = "brcm,ns2-amac",},
> {},
> };
>
> diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
> index 4584958..a805cc8 100644
> --- a/drivers/net/ethernet/broadcom/bgmac.c
> +++ b/drivers/net/ethernet/broadcom/bgmac.c
> @@ -1082,6 +1082,9 @@ static void bgmac_enable(struct bgmac *bgmac)
> /* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipinit */
> static void bgmac_chip_init(struct bgmac *bgmac)
> {
> + /* Clear any erroneously pending interrupts */
> + bgmac_write(bgmac, BGMAC_INT_STATUS, ~0);
> +
> /* 1 interrupt per received frame */
> bgmac_write(bgmac, BGMAC_INT_RECV_LAZY, 1 << BGMAC_IRL_FC_SHIFT);
>
> diff --git a/drivers/net/ethernet/broadcom/bgmac.h b/drivers/net/ethernet/broadcom/bgmac.h
> index ea52ac3..b1820ea 100644
> --- a/drivers/net/ethernet/broadcom/bgmac.h
> +++ b/drivers/net/ethernet/broadcom/bgmac.h
> @@ -463,6 +463,7 @@ struct bgmac {
> struct {
> void *base;
> void *idm_base;
> + void *nicpm_base;
> } plat;
> struct {
> struct bcma_device *core;
>
^ permalink raw reply
* Re: [PATCH v4 2/7] Documentation: devicetree: add PHY lane swap binding
From: Andrew Lunn @ 2016-11-01 20:48 UTC (permalink / raw)
To: Jon Mason
Cc: David Miller, Rob Herring, Mark Rutland, Florian Fainelli,
devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
rafal-g1n6cQUeyibVItvQsEIGlw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1478030682-27012-3-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> +- enet-phy-lane-swap: If set, indicates the PHY device requires swapping the
> + TX/RX lanes to function properly.
Is 'requires' the right word here? The PHY performs the actual swap of
the Tx/Rx lanes.
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 0/3] tools lib bpf: Synchronize implementations
From: David Ahern @ 2016-11-01 20:51 UTC (permalink / raw)
To: Joe Stringer, netdev; +Cc: wangnan0, ast
In-Reply-To: <20161031183917.9938-1-joe@ovn.org>
On 10/31/16 12:39 PM, Joe Stringer wrote:
> Update tools/lib/bpf to provide more functionality and improve interoperation
> with other tools that generate and use eBPF code.
>
> The kernel uapi headers are a bit newer than the version in the tools/
> directory; synchronize those.
>
> samples/bpf/libbpf* has a bit more functionality than tools/lib/bpf, so extend
> tools/lib/bpf/bpf* with these functions to bring them into parity.
>
> tools/lib/bpf cannot read ELFs that tc can read, and vice versa. Update the
> map definition to be the same as in tc so the ELFs may be interchangeable
> (at least for now; I don't have a long-term plan in mind to ensure this always
> works).
can samples/bpf be converted to use tools/lib/bpf/libbpf.a?
^ permalink raw reply
* Re: [PATCH] net: ip, diag -- Adjust raw_abort to use unlocked __udp_disconnect
From: Eric Dumazet @ 2016-11-01 20:52 UTC (permalink / raw)
To: Cyrill Gorcunov
Cc: netdev, David Miller, dsa, jhs, linux-kernel, kuznet, jmorris,
yoshfuji, kaber, avagin, stephen
In-Reply-To: <20161101200500.GA1852@uranus.lan>
On Tue, 2016-11-01 at 23:05 +0300, Cyrill Gorcunov wrote:
> While being preparing patches for killing raw sockets via
> diag netlink interface I noticed that my runs are stuck:
>
> | [root@pcs7 ~]# cat /proc/`pidof ss`/stack
> | [<ffffffff816d1a76>] __lock_sock+0x80/0xc4
> | [<ffffffff816d206a>] lock_sock_nested+0x47/0x95
> | [<ffffffff8179ded6>] udp_disconnect+0x19/0x33
> | [<ffffffff8179b517>] raw_abort+0x33/0x42
> | [<ffffffff81702322>] sock_diag_destroy+0x4d/0x52
>
> which has not been the case before. I narrowed it down to the commit
>
> | commit 286c72deabaa240b7eebbd99496ed3324d69f3c0
> | Author: Eric Dumazet <edumazet@google.com>
> | Date: Thu Oct 20 09:39:40 2016 -0700
> |
> | udp: must lock the socket in udp_disconnect()
>
> where we start locking the socket for different reason.
>
> So the raw_abort escaped the renaming and we have to
> fix this typo using __udp_disconnect instead.
>
The preferred way to cite a bug origin is :
Fixes: 286c72deabaa ("udp: must lock the socket in udp_disconnect()")
> CC: David S. Miller <davem@davemloft.net>
> CC: Eric Dumazet <eric.dumazet@gmail.com>
> CC: David Ahern <dsa@cumulusnetworks.com>
> CC: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> CC: James Morris <jmorris@namei.org>
> CC: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
> CC: Patrick McHardy <kaber@trash.net>
> CC: Andrey Vagin <avagin@openvz.org>
> CC: Stephen Hemminger <stephen@networkplumber.org>
That is a lot of CC ...
> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Eric Dumazet <edumazet@google.com>
Thanks.
^ permalink raw reply
* Re: [PATCH] net: ip, diag -- Adjust raw_abort to use unlocked __udp_disconnect
From: Cyrill Gorcunov @ 2016-11-01 20:58 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, David Miller, dsa, jhs, linux-kernel, kuznet, jmorris,
yoshfuji, kaber, avagin, stephen
In-Reply-To: <1478033554.7065.356.camel@edumazet-glaptop3.roam.corp.google.com>
On Tue, Nov 01, 2016 at 01:52:34PM -0700, Eric Dumazet wrote:
>
> The preferred way to cite a bug origin is :
>
> Fixes: 286c72deabaa ("udp: must lock the socket in udp_disconnect()")
Aha. Thank you, will do this way next time.
> > CC: David S. Miller <davem@davemloft.net>
> > CC: Eric Dumazet <eric.dumazet@gmail.com>
> > CC: David Ahern <dsa@cumulusnetworks.com>
> > CC: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> > CC: James Morris <jmorris@namei.org>
> > CC: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
> > CC: Patrick McHardy <kaber@trash.net>
> > CC: Andrey Vagin <avagin@openvz.org>
> > CC: Stephen Hemminger <stephen@networkplumber.org>
>
> That is a lot of CC ...
Because I CC'ed all for raw diag first patch, so I thought I've
to notify them with this typo in code.
> > Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
>
> Acked-by: Eric Dumazet <edumazet@google.com>
>
> Thanks.
>
>
Cyrill
^ permalink raw reply
* Re: [PATCH v4 2/7] Documentation: devicetree: add PHY lane swap binding
From: Jon Mason @ 2016-11-01 20:59 UTC (permalink / raw)
To: Andrew Lunn
Cc: David Miller, Rob Herring, Mark Rutland, Florian Fainelli,
devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
rafal-g1n6cQUeyibVItvQsEIGlw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161101204826.GA21010-g2DYL2Zd6BY@public.gmane.org>
On Tue, Nov 01, 2016 at 09:48:26PM +0100, Andrew Lunn wrote:
> > +- enet-phy-lane-swap: If set, indicates the PHY device requires swapping the
> > + TX/RX lanes to function properly.
>
> Is 'requires' the right word here? The PHY performs the actual swap of
> the Tx/Rx lanes.
What I'm trying to say here is that without the lane swapping, the PHY
will not function properly. Thus, those PHYs require this parameter
to work. I am open to suggestions to reword the sentence to make it
clearer.
Thanks,
Jon
>
> Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation
From: Thomas Graf @ 2016-11-01 20:59 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: David S. Miller, Alexei Starovoitov, Daniel Borkmann, Tom Herbert,
roopa, netdev
In-Reply-To: <1478030932.3136562.774196097.1F1AD6FB@webmail.messagingengine.com>
On 1 November 2016 at 13:08, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On Tue, Nov 1, 2016, at 19:51, Thomas Graf wrote:
>> If I understand you correctly then a single BPF program would be
>> loaded which then applies to all dst_output() calls? This has a huge
>> drawback, instead of multiple small BPF programs which do exactly what
>> is required per dst, a large BPF program is needed which matches on
>> metadata. That's way slower and renders one of the biggest advantages
>> of BPF invalid, the ability to generate a a small program tailored to
>> a particular use. See Cilium.
>
> I thought more of hooks in the actual output/input functions specific to
> the protocol type (unfortunately again) protected by jump labels? Those
> hook get part of the dst_entry mapped so they can act on them.
This has no advantage over installing a BPF program at tc egress and
enabling to store/access metadata per dst. The whole point is to
execute bpf for a specific route.
> Another idea would be to put the eBPF hooks into the fib rules
> infrastructure. But I fear this wouldn't get you the hooks you were
> looking for? There they would only end up in the runtime path if
> actually activated.
Use of fib rules kills performance so it's not an option. I'm not even
sure that would be any simpler.
> Dumping and verifying which routes get used might actually already be
> quite complex on its own. Thus my fear.
We even have an API to query which route is used for a tuple. What
else would you like to see?
>> If it's based on metadata then you need to know the program logic and
>> associate it with the metadata in the dst. It actually doesn't get
>> much easier than to debug one of the samples, they are completely
>> static once compiled and it's very simple to verify if they do what
>> they are supposed to do.
>
> At the same time you can have lots of those programs and you e.g. would
> also need to verify if they are acting on the same data structures or
> have the identical code.
This will be addressed with signing AFAIK.
> It all reminds me a bit on grepping in source code which makes heavy use
> of function pointers with very generic and short names.
Is this statement related to routing? I don't get the reference to
function pointers and generic short names.
>> If you like the single program approach, feel free to load the same
>> program for every dst. Perfectly acceptable but I don't see why we
>> should force everybody to use that model.
>
> I am concerned having 100ths of BPF programs, all specialized on a
> particular route, to debug. Looking at one code file and its associated
> tables seems still easier to me.
100 programs != 100 source files. A lot more realistic is a single or
a handful of programs which get compiled for a particular route with
certain pieces enabled/disabled.
> E.g. imaging we have input routes and output routes with different BPF
> programs. We somehow must make sure all nodes kind of behave accordingly
> to "sane" network semantics. If you end up with an input route doing bpf
As soon as we have signing, you can verify your programs in testing,
sign the programs and then quickly verify on all your nodes whether
you are running the correct programs.
Would it help if we allow to store the original source used for
bytecode generation. What would make it clear which program was used.
> processing and the according output node, which e.g. might be needed to
> reflect ICMP packets, doesn't behave accordingly you at least have two
> programs to debug already instead of a switch- or if-condition in one
> single code location. I would like to "force" this kind of symmetry to
> developers using eBPF, thus I thought meta-data manipulation and
> verification inside the kernel would be a better attack at this problem,
> no?
Are you saying you want a single gigantic program for both input and output?
That's not possible. The BPF program has different limitations
depending on where it runs. On input, any write action on the packet
is not allowed, extending the header is only allowed on xmit, and so
on.
I also don't see how this could possibly scale if all packets must go
through a single BPF program. The overhead will be tremendous if you
only want to filter a couple of prefixes.
^ permalink raw reply
* Re: [PATCH v4 2/7] Documentation: devicetree: add PHY lane swap binding
From: Scott Branden @ 2016-11-01 21:01 UTC (permalink / raw)
To: Jon Mason, Andrew Lunn
Cc: David Miller, Rob Herring, Mark Rutland, Florian Fainelli,
devicetree, netdev, linux-kernel, bcm-kernel-feedback-list, rafal,
linux-arm-kernel
In-Reply-To: <20161101205913.GA27191@broadcom.com>
On 16-11-01 01:59 PM, Jon Mason wrote:
> On Tue, Nov 01, 2016 at 09:48:26PM +0100, Andrew Lunn wrote:
>>> +- enet-phy-lane-swap: If set, indicates the PHY device requires swapping the
>>> + TX/RX lanes to function properly.
>>
>> Is 'requires' the right word here? The PHY performs the actual swap of
>> the Tx/Rx lanes.
>
> What I'm trying to say here is that without the lane swapping, the PHY
> will not function properly. Thus, those PHYs require this parameter
> to work. I am open to suggestions to reword the sentence to make it
> clearer.
If set, indicates the PHY will swap the TX/RX lanes to compensate for
the board being designed with the lanes swapped.
>
> Thanks,
> Jon
>
>>
>> Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 3/5] bpf: BPF for lightweight tunnel encapsulation
From: Thomas Graf @ 2016-11-01 21:03 UTC (permalink / raw)
To: David Ahern
Cc: David S. Miller, Alexei Starovoitov, Daniel Borkmann, Tom Herbert,
roopa, netdev
In-Reply-To: <0bfff5e0-cd4a-4d69-d54c-7d6dbf237db7@cumulusnetworks.com>
On 1 November 2016 at 13:11, David Ahern <dsa@cumulusnetworks.com> wrote:
> On 10/31/16 6:37 PM, Thomas Graf wrote:
>> - Perform simple encapsulation where offload is of no concern.
>> (The existing funtionality to attach a tunnel key to the skb
>> and redirect to a tunnel net_device to allow for offload
>> continues to work obviously).
>
> have you tested the adding of headers with large packets hitting gso and fragmentation? Wondering if mtu is used properly when headers are added and the lwt->headroom is not accounted. See 14972cbd34ff668c390cbd2e6497323484c9e812
Thanks for the pointer David, I will look into this.
The packet size is currently limited to this when adding l2 headers:
skb->dev->mtu + skb->dev->hard_header_len
^ permalink raw reply
* Re: [PATCH v4 6/7] net: ethernet: bgmac: add NS2 support
From: Jon Mason @ 2016-11-01 21:05 UTC (permalink / raw)
To: Scott Branden
Cc: David Miller, Rob Herring, Mark Rutland, Florian Fainelli, rafal,
bcm-kernel-feedback-list, netdev, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <711f4964-e655-4007-9804-f45bd47fed73@broadcom.com>
On Tue, Nov 01, 2016 at 01:34:30PM -0700, Scott Branden wrote:
> One change in this patch
>
> On 16-11-01 01:04 PM, Jon Mason wrote:
> >Add support for the variant of amac hardware present in the Broadcom
> >Northstar2 based SoCs. Northstar2 requires an additional register to be
> >configured with the port speed/duplexity (NICPM). This can be added to
> >the link callback to hide it from the instances that do not use this.
> >Also, clearing of the pending interrupts on init is required due to
> >observed issues on some platforms.
> >
> >Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> >---
> > drivers/net/ethernet/broadcom/bgmac-platform.c | 56 +++++++++++++++++++++++++-
> > drivers/net/ethernet/broadcom/bgmac.c | 3 ++
> > drivers/net/ethernet/broadcom/bgmac.h | 1 +
> > 3 files changed, 58 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c b/drivers/net/ethernet/broadcom/bgmac-platform.c
> >index aed5dc5..f6d48c7 100644
> >--- a/drivers/net/ethernet/broadcom/bgmac-platform.c
> >+++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
> >@@ -14,12 +14,21 @@
> > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> >
> > #include <linux/bcma/bcma.h>
> >+#include <linux/brcmphy.h>
> > #include <linux/etherdevice.h>
> > #include <linux/of_address.h>
> > #include <linux/of_mdio.h>
> > #include <linux/of_net.h>
> > #include "bgmac.h"
> >
> >+#define NICPM_IOMUX_CTRL 0x00000008
> >+
> >+#define NICPM_IOMUX_CTRL_INIT_VAL 0x3196e000
> >+#define NICPM_IOMUX_CTRL_SPD_SHIFT 10
> >+#define NICPM_IOMUX_CTRL_SPD_10M 0
> >+#define NICPM_IOMUX_CTRL_SPD_100M 1
> >+#define NICPM_IOMUX_CTRL_SPD_1000M 2
> >+
> > static u32 platform_bgmac_read(struct bgmac *bgmac, u16 offset)
> > {
> > return readl(bgmac->plat.base + offset);
> >@@ -87,12 +96,46 @@ static void platform_bgmac_cmn_maskset32(struct bgmac *bgmac, u16 offset,
> > WARN_ON(1);
> > }
> >
> >+static void bgmac_nicpm_speed_set(struct net_device *net_dev)
> >+{
> >+ struct bgmac *bgmac = netdev_priv(net_dev);
> >+ u32 val;
> >+
> >+ if (!bgmac->plat.nicpm_base)
> >+ return;
> >+
> >+ val = NICPM_IOMUX_CTRL_INIT_VAL;
> >+ switch (bgmac->net_dev->phydev->speed) {
> >+ default:
> >+ pr_err("Unsupported speed. Defaulting to 1000Mb\n");
> This should be dev_err
It should probably be netdev_err (and there are a few instances below
that should probably be changed to netdev_err as well).
Thanks,
Jon
> >+ case SPEED_1000:
> >+ val |= NICPM_IOMUX_CTRL_SPD_1000M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> >+ break;
> >+ case SPEED_100:
> >+ val |= NICPM_IOMUX_CTRL_SPD_100M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> >+ break;
> >+ case SPEED_10:
> >+ val |= NICPM_IOMUX_CTRL_SPD_10M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> >+ break;
> >+ }
> >+
> >+ writel(val, bgmac->plat.nicpm_base + NICPM_IOMUX_CTRL);
> >+
> >+ bgmac_adjust_link(bgmac->net_dev);
> >+}
> >+
> > static int platform_phy_connect(struct bgmac *bgmac)
> > {
> > struct phy_device *phy_dev;
> >
> >- phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
> >- bgmac_adjust_link);
> >+ if (bgmac->plat.nicpm_base)
> >+ phy_dev = of_phy_get_and_connect(bgmac->net_dev,
> >+ bgmac->dev->of_node,
> >+ bgmac_nicpm_speed_set);
> >+ else
> >+ phy_dev = of_phy_get_and_connect(bgmac->net_dev,
> >+ bgmac->dev->of_node,
> >+ bgmac_adjust_link);
> > if (!phy_dev) {
> > dev_err(bgmac->dev, "Phy connect failed\n");
> > return -ENODEV;
> >@@ -182,6 +225,14 @@ static int bgmac_probe(struct platform_device *pdev)
> > if (IS_ERR(bgmac->plat.idm_base))
> > return PTR_ERR(bgmac->plat.idm_base);
> >
> >+ regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nicpm_base");
> >+ if (regs) {
> >+ bgmac->plat.nicpm_base = devm_ioremap_resource(&pdev->dev,
> >+ regs);
> >+ if (IS_ERR(bgmac->plat.nicpm_base))
> >+ return PTR_ERR(bgmac->plat.nicpm_base);
> >+ }
> >+
> > bgmac->read = platform_bgmac_read;
> > bgmac->write = platform_bgmac_write;
> > bgmac->idm_read = platform_bgmac_idm_read;
> >@@ -213,6 +264,7 @@ static int bgmac_remove(struct platform_device *pdev)
> > static const struct of_device_id bgmac_of_enet_match[] = {
> > {.compatible = "brcm,amac",},
> > {.compatible = "brcm,nsp-amac",},
> >+ {.compatible = "brcm,ns2-amac",},
> > {},
> > };
> >
> >diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
> >index 4584958..a805cc8 100644
> >--- a/drivers/net/ethernet/broadcom/bgmac.c
> >+++ b/drivers/net/ethernet/broadcom/bgmac.c
> >@@ -1082,6 +1082,9 @@ static void bgmac_enable(struct bgmac *bgmac)
> > /* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipinit */
> > static void bgmac_chip_init(struct bgmac *bgmac)
> > {
> >+ /* Clear any erroneously pending interrupts */
> >+ bgmac_write(bgmac, BGMAC_INT_STATUS, ~0);
> >+
> > /* 1 interrupt per received frame */
> > bgmac_write(bgmac, BGMAC_INT_RECV_LAZY, 1 << BGMAC_IRL_FC_SHIFT);
> >
> >diff --git a/drivers/net/ethernet/broadcom/bgmac.h b/drivers/net/ethernet/broadcom/bgmac.h
> >index ea52ac3..b1820ea 100644
> >--- a/drivers/net/ethernet/broadcom/bgmac.h
> >+++ b/drivers/net/ethernet/broadcom/bgmac.h
> >@@ -463,6 +463,7 @@ struct bgmac {
> > struct {
> > void *base;
> > void *idm_base;
> >+ void *nicpm_base;
> > } plat;
> > struct {
> > struct bcma_device *core;
> >
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation
From: Thomas Graf @ 2016-11-01 21:05 UTC (permalink / raw)
To: Tom Herbert
Cc: David S. Miller, Alexei Starovoitov, Daniel Borkmann, roopa,
Linux Kernel Network Developers
In-Reply-To: <CALx6S36o1ig4rhN3MTaD1OCJ3sQo_ghbkonde1JDf4S9X=YkZQ@mail.gmail.com>
On 1 November 2016 at 13:33, Tom Herbert <tom@herbertland.com> wrote:
> You need to show that is integrity is maintained with these patches.
> Part of this can be done, but part of this needs to be established in
> testing.
>
> I've already given specifics for at least one potential source of
> issues in routing issues. I would like to know what happens if someone
> rewrites an IPv4 packet into IPv6 packet or vice versa. AFAICT we
> would be send an IPv6 using an IPv4 route, or an IPv4 using an IPv6
> route. What is supposed to happen in these circumstances? What
> actually happens?
>
> Similarly, someone overwrites the whole packet with 0xff. What happens
> when we try to send that?
OK, I will add these tests to the selftest in the next iteration.
^ permalink raw reply
* Re: [PATCH net-next V2 3/3] net/mlx4_en: Add ethtool statistics for XDP cases
From: Brenden Blanco @ 2016-11-01 21:06 UTC (permalink / raw)
To: Tariq Toukan
Cc: David S. Miller, netdev, Eran Ben Elisha, Alexei Starovoitov,
Saeed Mahameed
In-Reply-To: <1478000186-5158-4-git-send-email-tariqt@mellanox.com>
On Tue, Nov 01, 2016 at 01:36:26PM +0200, Tariq Toukan wrote:
> XDP statistics are reported in ethtool as follows:
> - xdp_drop: the number of packets dropped by xdp.
> - xdp_tx: the number of packets forwarded by xdp.
> - xdp_tx_full: the number of times an xdp forward failed
> due to a full tx xdp ring.
>
> In addition, all packets that are dropped/forwarded by XDP
> are no longer accounted in rx_packets/rx_bytes of the ring,
> so that they count traffic that is passed to the stack.
This seems like a step backwards, in that I now no longer have any
statistic whatsoever that can count xdp packets per-ring. For instance,
how would I validate that my flow-hash rules are operating correctly? I
would suggest to restore the rxN_packet/bytes stat increment.
>
> Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 14 ++++++++++++++
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 4 ++++
> drivers/net/ethernet/mellanox/mlx4/en_port.c | 6 ++++++
> drivers/net/ethernet/mellanox/mlx4/en_rx.c | 12 +++++++-----
> drivers/net/ethernet/mellanox/mlx4/en_tx.c | 8 ++++----
> drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 7 ++++++-
> drivers/net/ethernet/mellanox/mlx4/mlx4_stats.h | 10 +++++++++-
> 7 files changed, 50 insertions(+), 11 deletions(-)
[...]
^ permalink raw reply
* Re: [PATCH v4 2/7] Documentation: devicetree: add PHY lane swap binding
From: Andrew Lunn @ 2016-11-01 21:09 UTC (permalink / raw)
To: Scott Branden
Cc: Mark Rutland, devicetree, Florian Fainelli, netdev, linux-kernel,
Jon Mason, Rob Herring, bcm-kernel-feedback-list, rafal,
David Miller, linux-arm-kernel
In-Reply-To: <f56145b6-adb6-186b-0b75-45a9f3a6c58e@broadcom.com>
> If set, indicates the PHY will swap the TX/RX lanes to compensate
> for the board being designed with the lanes swapped.
Thanks, much better.
Andrew
^ permalink raw reply
* Re: mlx5 bug in error path of mlx5e_open_channel()
From: Saeed Mahameed @ 2016-11-01 15:48 UTC (permalink / raw)
To: Jesper Dangaard Brouer, Tariq Toukan, Tariq Toukan,
Eran Ben Elisha
Cc: netdev@vger.kernel.org
In-Reply-To: <20161101154402.38eb730c@redhat.com>
On 11/01/2016 04:44 PM, Jesper Dangaard Brouer wrote:
>
> In driver mlx5 function mlx5e_open_channel() does not handle error
> path correctly. (Tested by letting mlx5e_create_rq fail with -ENOMEM,
> propagates to mlx5e_open_rq)
>
> This first seemed related to commit b5503b994ed5 ("net/mlx5e: XDP TX
> forwarding support"). As a failed call of mlx5e_open_rq() always
> calls mlx5e_close_sq(&c->xdp_sq) on "xdp_sq" even-though a XDP program
> is not attached.
>
Indeed, Nice catch.
> Fixing this like:
>
> @@ -1504,24 +1533,38 @@ static int mlx5e_open_channel(struct mlx5e_priv *priv, int ix,
>
> c->xdp = !!priv->xdp_prog;
> err = mlx5e_open_rq(c, &cparam->rq, &c->rq);
> - if (err)
> - goto err_close_xdp_sq;
> + if (err) {
> + if (c->xdp)
> + goto err_close_xdp_sq;
> + else
> + goto err_close_sqs;
> + }
>
> The fix does remove one problem, but the error path still cause the
> kernel to crash. This time it seems related to correct disabling of
> NAPI polling before disabling the queues.
>
Well a more proper fix will be to add a xdp check in close_xdp_sq error flow,
rather than complicating the error handling branching decision.
i.e:
Keep:
err = mlx5e_open_rq(c, &cparam->rq, &c->rq);
if (err)
goto err_close_xdp_sq;
[...]
err_close_xdp_sq:
- mlx5e_close_sq(&c->xdp_sq);
+ if (priv->xdp_prog)
+ mlx5e_close_sq(&c->xdp_sq);
One more thing, the error flow handling is missing mlx5e_close_cq(&c->xdp_sq.cq);
which might be related to the other bug you reported below.
> Now with another error:
>
> XXX: call mlx5e_close_sqs(c)
> BUG: unable to handle kernel NULL pointer dereference at (null)
> IP: [< (null)>] (null)
> PGD 401e00067
> PUD 40746e067 PMD 0
> Oops: 0010 [#1] PREEMPT SMP
> Modules linked in: mlx5_core coretemp kvm_intel kvm irqbypass intel_cstate mxm_wmi i2c_i801 i2c_smbus]
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-rc3-page_pool04+ #124
> Hardware name: To Be Filled By O.E.M./Z97 Extreme4, BIOS P2.10 05/12/2015
> task: ffffffff81c0c4c0 task.stack: ffffffff81c00000
> RIP: 0010:[<0000000000000000>] [< (null)>] (null)
> RSP: 0018:ffff88041fa03e70 EFLAGS: 00010286
> RAX: 0000000000000000 RBX: ffff880401ecc000 RCX: 0000000000000005
> RDX: 0000000000000000 RSI: ffff880401c38000 RDI: ffff880401ecc000
> RBP: ffff88041fa03e88 R08: 0000000000000001 R09: ffff8803ea6a7230
> R10: 0000000000000000 R11: 0000000000000040 R12: ffff880401c38000
> R13: ffff880401ecf148 R14: 0000000000000040 R15: ffff880401ecc000
> FS: 0000000000000000(0000) GS:ffff88041fa00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000000 CR3: 000000040c468000 CR4: 00000000001406f0
> Stack:
> ffffffffa02e62e0 0000000000000000 0000000000000001 ffff88041fa03ed0
> ffffffffa02e84c2 0000ffff00000000 ffffffff00000040 ffff880401ecf148
> 0000000000000040 0000000000000000 000000000000012c 0000000000000000
> Call Trace:
> <IRQ> [ 428.032595] [<ffffffffa02e62e0>] ? mlx5e_post_rx_wqes+0x80/0xc0 [mlx5_core]
> [<ffffffffa02e84c2>] mlx5e_napi_poll+0xf2/0x530 [mlx5_core]
> [<ffffffff8160e50c>] net_rx_action+0x1fc/0x350
> [<ffffffff8172aff8>] __do_softirq+0xc8/0x2c6
> [<ffffffff8106728e>] irq_exit+0xbe/0xd0
> [<ffffffff8172ad44>] do_IRQ+0x54/0xd0
> [<ffffffff8172937f>] common_interrupt+0x7f/0x7f
> <EOI> [ 428.075157] [<ffffffff817285d0>] ? _raw_spin_unlock_irq+0x10/0x20
> [<ffffffff81086db8>] ? finish_task_switch+0x78/0x200
> [<ffffffff81722dfa>] __schedule+0x17a/0x670
> [<ffffffff8172332d>] schedule+0x3d/0x90
> [<ffffffff817236a5>] schedule_preempt_disabled+0x15/0x20
> [<ffffffff810a560c>] cpu_startup_entry+0x12c/0x1c0
> [<ffffffff8171c274>] rest_init+0x84/0x90
> [<ffffffff81d95f14>] start_kernel+0x3fe/0x40b
> [<ffffffff81d9528f>] x86_64_start_reservations+0x2a/0x2c
> [<ffffffff81d953f9>] x86_64_start_kernel+0x168/0x176
> Code: Bad RIP value.
> RIP [< (null)>] (null)
> RSP <ffff88041fa03e70>
> CR2: 0000000000000000
> ---[ end trace a871278f0d0523ac ]---
>
> Could you please look at fixing your driver?
>
Will handle it ASAP, Thank you Jesper.
-Saeed.
^ permalink raw reply
* [PATCH 00/12] Netfilter updates for net-next
From: Pablo Neira Ayuso @ 2016-11-01 21:26 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
Hi David,
The following patchset contains Netfilter updates for your net-next
tree. This includes better integration with the routing subsystem for
nf_tables, explicit notrack support and smaller updates. More
specifically, they are:
1) Add fib lookup expression for nf_tables, from Florian Westphal. This
new expression provides a native replacement for iptables addrtype
and rp_filter matches. This is more flexible though, since we can
populate the kernel flowi representation to inquire fib to
accomodate new usecases, such as RTBH through skb mark.
2) Introduce rt expression for nf_tables, from Anders K. Pedersen. This
new expression allow you to access skbuff route metadata, more
specifically nexthop and classid fields.
3) Add notrack support for nf_tables, to skip conntracking, requested by
many users already.
4) Add boilerplate code to allow to use nf_log infrastructure from
nf_tables ingress.
5) Allow to mangle pkttype from nf_tables prerouting chain, to emulate
the xtables cluster match, from Liping Zhang.
6) Move socket lookup code into generic nf_socket_* infrastructure so
we can provide a native replacement for the xtables socket match.
7) Make sure nfnetlink_queue data that is updated on every packets is
placed in a different cache from read-only data, from Florian Westphal.
8) Handle NF_STOLEN from nf_tables core, also from Florian Westphal.
9) Start round robin number generation in nft_numgen from zero,
instead of n-1, for consistency with xtables statistics match,
patch from Liping Zhang.
10) Set GFP_NOWARN flag in skbuff netlink allocations in nfnetlink_log,
given we retry with a smaller allocation on failure, from Calvin Owens.
11) Cleanup xt_multiport to use switch(), from Gao feng.
12) Remove superfluous check in nft_immediate and nft_cmp, from
Liping Zhang.
You can pull these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git
Thanks!
----------------------------------------------------------------
The following changes since commit 432490f9d455fb842d70219f22d9d2c812371676:
net: ip, diag -- Add diag interface for raw sockets (2016-10-23 19:35:24 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git HEAD
for you to fetch changes up to 886bc50348fd69972baa4616ce95b7dc9ff8afe7:
netfilter: nf_queue: place volatile data in own cacheline (2016-11-01 20:50:33 +0100)
----------------------------------------------------------------
Anders K. Pedersen (1):
netfilter: nf_tables: introduce routing expression
Calvin Owens (1):
netfilter: nfnetlink_log: Use GFP_NOWARN for skb allocation
Florian Westphal (3):
netfilter: nf_tables: allow expressions to return STOLEN
netfilter: nf_tables: add fib expression
netfilter: nf_queue: place volatile data in own cacheline
Gao Feng (1):
netfilter: xt_multiport: Use switch case instead of multiple condition checks
Liping Zhang (3):
netfilter: nft_numgen: start round robin from zero
netfilter: nft_meta: permit pkttype mangling in ip/ip6 prerouting
netfilter: nf_tables: remove useless U8_MAX validation
Pablo Neira Ayuso (3):
netfilter: nft_ct: add notrack support
netfilter: nf_log: add packet logging for netdev family
netfilter: move socket lookup infrastructure to nf_socket_ipv{4,6}.c
include/net/netfilter/nf_log.h | 5 +
include/net/netfilter/nf_socket.h | 27 +++
include/net/netfilter/nft_fib.h | 31 ++++
include/uapi/linux/netfilter/nf_tables.h | 63 +++++++
net/bridge/netfilter/Kconfig | 1 +
net/bridge/netfilter/nf_log_bridge.c | 16 +-
net/ipv4/netfilter/Kconfig | 14 ++
net/ipv4/netfilter/Makefile | 3 +
net/ipv4/netfilter/nf_socket_ipv4.c | 163 +++++++++++++++++
net/ipv4/netfilter/nft_fib_ipv4.c | 238 ++++++++++++++++++++++++
net/ipv6/netfilter/Kconfig | 14 ++
net/ipv6/netfilter/Makefile | 3 +
net/ipv6/netfilter/nf_socket_ipv6.c | 151 +++++++++++++++
net/ipv6/netfilter/nft_fib_ipv6.c | 275 ++++++++++++++++++++++++++++
net/netfilter/Kconfig | 26 ++-
net/netfilter/Makefile | 6 +
net/netfilter/nf_log_common.c | 27 +++
net/netfilter/nf_log_netdev.c | 80 ++++++++
net/netfilter/nf_tables_core.c | 1 +
net/netfilter/nfnetlink_log.c | 2 +-
net/netfilter/nfnetlink_queue.c | 2 +-
net/netfilter/nft_cmp.c | 3 -
net/netfilter/nft_ct.c | 50 ++++-
net/netfilter/nft_fib.c | 159 ++++++++++++++++
net/netfilter/nft_fib_inet.c | 82 +++++++++
net/netfilter/nft_immediate.c | 3 -
net/netfilter/nft_meta.c | 5 +
net/netfilter/nft_numgen.c | 2 +-
net/netfilter/nft_rt.c | 153 ++++++++++++++++
net/netfilter/xt_multiport.c | 40 ++--
net/netfilter/xt_socket.c | 305 +------------------------------
31 files changed, 1610 insertions(+), 340 deletions(-)
create mode 100644 include/net/netfilter/nf_socket.h
create mode 100644 include/net/netfilter/nft_fib.h
create mode 100644 net/ipv4/netfilter/nf_socket_ipv4.c
create mode 100644 net/ipv4/netfilter/nft_fib_ipv4.c
create mode 100644 net/ipv6/netfilter/nf_socket_ipv6.c
create mode 100644 net/ipv6/netfilter/nft_fib_ipv6.c
create mode 100644 net/netfilter/nf_log_netdev.c
create mode 100644 net/netfilter/nft_fib.c
create mode 100644 net/netfilter/nft_fib_inet.c
create mode 100644 net/netfilter/nft_rt.c
^ 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