* Allow bpf_perf_event_output to access packet data
From: Lorenz Bauer @ 2018-09-07 14:56 UTC (permalink / raw)
To: netdev
Re-sent due to HTML e-mail mess up, apologies.
---------- Forwarded message ----------
From: Lorenz Bauer <lmb@cloudflare.com>
Date: 7 September 2018 at 15:53
Subject: Allow bpf_perf_event_output to access packet data
To: netdev@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>
Hello list,
I'm attempting to use bpf_perf_event_output to do packet sampling from XDP.
The code basically runs before our other XDP code, does a
perf_event_output with the full packet (for now) and then tail calls
into DDoS mitigation, etc.
I've just discovered that perf_event_output isn't allowed to access
packet data by the verifier. Is this something that could be allowed?
Best
Lorenz
--
Lorenz Bauer | Systems Engineer
25 Lavington St., London SE1 0NZ
www.cloudflare.com
^ permalink raw reply
* [PATCH 0/5] introduce setbits32/clrbits32/clrsetbits32/setbits64/clrbits64/clrsetbits64 functions
From: Corentin Labbe @ 2018-09-07 19:41 UTC (permalink / raw)
To: Gilles.Muller, Julia.Lawall, agust, alexandre.torgue, alistair,
benh, carlo, davem, galak, joabreu, khilman, maxime.ripard,
michal.lkml, mpe, mporter, nicolas.palix, oss, paulus,
peppe.cavallaro, tj, vitb, wens
Cc: cocci, linux-amlogic, linux-arm-kernel, linux-ide, linux-kernel,
linuxppc-dev, netdev, linux-sunxi, Corentin Labbe
Hello
This patchset adds a new set of functions which are open-coded in lot of
place.
Basicly the pattern is always the same, "read, modify a bit, write"
some driver already have thoses pattern them as functions. (like ahci_sunxi.c or dwmac-meson8b)
The first patch rename some powerpc funtions which already use the same name (xxxbits32)
but with only bigendian values.
The second patch adds the header.
The third patch is an ugly try to implement a coccinelle semantic patch to
find all place where xxxbits function could be used.
Probably this spatch could be better written and I didnt found an easy way to add the "linux/setbits" header.
The two last patch are example of convertion of two drivers.
Thoses patchs give an example of the reduction of code won by using xxxbits32.
This patchset is tested with the ahci_sunxi and dwmac-sun8i drivers.
Regards
Corentin Labbe (5):
powerpc: rename setbits32/clrbits32 to setbits32_be/clrbits32_be
include: add
setbits32/clrbits32/clrsetbits32/setbits64/clrbits64/clrsetbits64 in
linux/setbits.h
coccinelle: add xxxsetbitsXX converting spatch
net: ethernet: stmmac: use xxxsetbits32
ata: ahci_sunxi: use xxxsetbits32 functions
arch/powerpc/include/asm/fsl_lbc.h | 2 +-
arch/powerpc/include/asm/io.h | 5 +-
arch/powerpc/platforms/44x/canyonlands.c | 4 +-
arch/powerpc/platforms/4xx/gpio.c | 28 +-
arch/powerpc/platforms/512x/pdm360ng.c | 6 +-
arch/powerpc/platforms/52xx/mpc52xx_common.c | 6 +-
arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 10 +-
arch/powerpc/platforms/82xx/ep8248e.c | 2 +-
arch/powerpc/platforms/82xx/km82xx.c | 6 +-
arch/powerpc/platforms/82xx/mpc8272_ads.c | 10 +-
arch/powerpc/platforms/82xx/pq2.c | 2 +-
arch/powerpc/platforms/82xx/pq2ads-pci-pic.c | 4 +-
arch/powerpc/platforms/82xx/pq2fads.c | 10 +-
arch/powerpc/platforms/83xx/km83xx.c | 6 +-
arch/powerpc/platforms/83xx/mpc836x_mds.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c | 4 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 2 +-
arch/powerpc/platforms/85xx/p1022_ds.c | 4 +-
arch/powerpc/platforms/85xx/p1022_rdk.c | 4 +-
arch/powerpc/platforms/85xx/t1042rdb_diu.c | 4 +-
arch/powerpc/platforms/85xx/twr_p102x.c | 2 +-
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 4 +-
arch/powerpc/platforms/8xx/adder875.c | 2 +-
arch/powerpc/platforms/8xx/m8xx_setup.c | 4 +-
arch/powerpc/platforms/8xx/mpc86xads_setup.c | 4 +-
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 28 +-
arch/powerpc/platforms/embedded6xx/flipper-pic.c | 6 +-
arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 8 +-
arch/powerpc/platforms/embedded6xx/wii.c | 10 +-
arch/powerpc/sysdev/cpm1.c | 26 +-
arch/powerpc/sysdev/cpm2.c | 16 +-
arch/powerpc/sysdev/cpm_common.c | 4 +-
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 8 +-
arch/powerpc/sysdev/fsl_lbc.c | 2 +-
arch/powerpc/sysdev/fsl_pci.c | 8 +-
arch/powerpc/sysdev/fsl_pmc.c | 2 +-
arch/powerpc/sysdev/fsl_rcpm.c | 74 ++--
arch/powerpc/sysdev/fsl_rio.c | 4 +-
arch/powerpc/sysdev/fsl_rmu.c | 8 +-
arch/powerpc/sysdev/mpic_timer.c | 12 +-
drivers/ata/ahci_sunxi.c | 51 +--
.../net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 54 +--
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 55 +--
.../net/ethernet/stmicro/stmmac/dwmac1000_core.c | 21 +-
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 51 +--
drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c | 13 +-
drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c | 42 +-
drivers/net/ethernet/stmicro/stmmac/dwmac5.c | 11 +-
drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c | 17 +-
.../net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 30 +-
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 69 +---
.../net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 11 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 7 +-
include/linux/setbits.h | 55 +++
scripts/coccinelle/misc/setbits.cocci | 423 +++++++++++++++++++++
56 files changed, 776 insertions(+), 489 deletions(-)
create mode 100644 include/linux/setbits.h
create mode 100644 scripts/coccinelle/misc/setbits.cocci
--
2.16.4
^ permalink raw reply
* [PATCH 4/5] net: ethernet: stmmac: use xxxsetbits32
From: Corentin Labbe @ 2018-09-07 19:41 UTC (permalink / raw)
To: Gilles.Muller, Julia.Lawall, agust, alexandre.torgue, alistair,
benh, carlo, davem, galak, joabreu, khilman, maxime.ripard,
michal.lkml, mpe, mporter, nicolas.palix, oss, paulus,
peppe.cavallaro, tj, vitb, wens
Cc: cocci, linux-amlogic, linux-arm-kernel, linux-ide, linux-kernel,
linuxppc-dev, netdev, linux-sunxi, Corentin Labbe
In-Reply-To: <1536349307-20714-1-git-send-email-clabbe@baylibre.com>
This patch convert stmmac driver to use all xxxsetbits32 functions.
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 54 +++++++----------
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 55 ++++-------------
.../net/ethernet/stmicro/stmmac/dwmac1000_core.c | 21 +++----
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 51 ++++++----------
drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c | 13 ++--
drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c | 42 +++----------
drivers/net/ethernet/stmicro/stmmac/dwmac5.c | 11 +---
drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c | 17 ++----
.../net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 30 ++++------
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 69 +++++-----------------
.../net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 11 +---
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 7 +--
12 files changed, 108 insertions(+), 273 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index c5979569fd60..035a2ab7b479 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -22,6 +22,7 @@
#include <linux/of_net.h>
#include <linux/mfd/syscon.h>
#include <linux/platform_device.h>
+#include <linux/setbits.h>
#include <linux/stmmac.h>
#include "stmmac_platform.h"
@@ -75,18 +76,6 @@ struct meson8b_dwmac_clk_configs {
struct clk_gate rgmii_tx_en;
};
-static void meson8b_dwmac_mask_bits(struct meson8b_dwmac *dwmac, u32 reg,
- u32 mask, u32 value)
-{
- u32 data;
-
- data = readl(dwmac->regs + reg);
- data &= ~mask;
- data |= (value & mask);
-
- writel(data, dwmac->regs + reg);
-}
-
static struct clk *meson8b_dwmac_register_clk(struct meson8b_dwmac *dwmac,
const char *name_suffix,
const char **parent_names,
@@ -192,14 +181,12 @@ static int meson8b_set_phy_mode(struct meson8b_dwmac *dwmac)
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII_TXID:
/* enable RGMII mode */
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
- PRG_ETH0_RGMII_MODE,
- PRG_ETH0_RGMII_MODE);
+ clrsetbits32(dwmac->regs + PRG_ETH0, PRG_ETH0_RGMII_MODE,
+ PRG_ETH0_RGMII_MODE);
break;
case PHY_INTERFACE_MODE_RMII:
/* disable RGMII mode -> enables RMII mode */
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
- PRG_ETH0_RGMII_MODE, 0);
+ clrsetbits32(dwmac->regs + PRG_ETH0, PRG_ETH0_RGMII_MODE, 0);
break;
default:
dev_err(dwmac->dev, "fail to set phy-mode %s\n",
@@ -218,15 +205,15 @@ static int meson_axg_set_phy_mode(struct meson8b_dwmac *dwmac)
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII_TXID:
/* enable RGMII mode */
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
- PRG_ETH0_EXT_PHY_MODE_MASK,
- PRG_ETH0_EXT_RGMII_MODE);
+ clrsetbits32(dwmac->regs + PRG_ETH0,
+ PRG_ETH0_EXT_PHY_MODE_MASK,
+ PRG_ETH0_EXT_RGMII_MODE);
break;
case PHY_INTERFACE_MODE_RMII:
/* disable RGMII mode -> enables RMII mode */
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
- PRG_ETH0_EXT_PHY_MODE_MASK,
- PRG_ETH0_EXT_RMII_MODE);
+ clrsetbits32(dwmac->regs + PRG_ETH0,
+ PRG_ETH0_EXT_PHY_MODE_MASK,
+ PRG_ETH0_EXT_RMII_MODE);
break;
default:
dev_err(dwmac->dev, "fail to set phy-mode %s\n",
@@ -255,11 +242,11 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII_TXID:
/* only relevant for RMII mode -> disable in RGMII mode */
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
- PRG_ETH0_INVERTED_RMII_CLK, 0);
+ clrsetbits32(dwmac->regs + PRG_ETH0,
+ PRG_ETH0_INVERTED_RMII_CLK, 0);
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0, PRG_ETH0_TXDLY_MASK,
- tx_dly_val << PRG_ETH0_TXDLY_SHIFT);
+ clrsetbits32(dwmac->regs + PRG_ETH0, PRG_ETH0_TXDLY_MASK,
+ tx_dly_val << PRG_ETH0_TXDLY_SHIFT);
/* Configure the 125MHz RGMII TX clock, the IP block changes
* the output automatically (= without us having to configure
@@ -287,13 +274,12 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
case PHY_INTERFACE_MODE_RMII:
/* invert internal clk_rmii_i to generate 25/2.5 tx_rx_clk */
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
- PRG_ETH0_INVERTED_RMII_CLK,
- PRG_ETH0_INVERTED_RMII_CLK);
+ clrsetbits32(dwmac->regs + PRG_ETH0,
+ PRG_ETH0_INVERTED_RMII_CLK,
+ PRG_ETH0_INVERTED_RMII_CLK);
/* TX clock delay cannot be configured in RMII mode */
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0, PRG_ETH0_TXDLY_MASK,
- 0);
+ clrsetbits32(dwmac->regs + PRG_ETH0, PRG_ETH0_TXDLY_MASK, 0);
break;
@@ -304,8 +290,8 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
}
/* enable TX_CLK and PHY_REF_CLK generator */
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0, PRG_ETH0_TX_AND_PHY_REF_CLK,
- PRG_ETH0_TX_AND_PHY_REF_CLK);
+ clrsetbits32(dwmac->regs + PRG_ETH0, PRG_ETH0_TX_AND_PHY_REF_CLK,
+ PRG_ETH0_TX_AND_PHY_REF_CLK);
return 0;
}
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 0f660af01a4b..3c7f531feadf 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -27,6 +27,7 @@
#include <linux/platform_device.h>
#include <linux/regulator/consumer.h>
#include <linux/regmap.h>
+#include <linux/setbits.h>
#include <linux/stmmac.h>
#include "stmmac.h"
@@ -342,50 +343,27 @@ static void sun8i_dwmac_disable_dma_irq(void __iomem *ioaddr, u32 chan)
static void sun8i_dwmac_dma_start_tx(void __iomem *ioaddr, u32 chan)
{
- u32 v;
-
- v = readl(ioaddr + EMAC_TX_CTL1);
- v |= EMAC_TX_DMA_START;
- v |= EMAC_TX_DMA_EN;
- writel(v, ioaddr + EMAC_TX_CTL1);
+ setbits32(ioaddr + EMAC_TX_CTL1, EMAC_TX_DMA_START | EMAC_TX_DMA_EN);
}
static void sun8i_dwmac_enable_dma_transmission(void __iomem *ioaddr)
{
- u32 v;
-
- v = readl(ioaddr + EMAC_TX_CTL1);
- v |= EMAC_TX_DMA_START;
- v |= EMAC_TX_DMA_EN;
- writel(v, ioaddr + EMAC_TX_CTL1);
+ setbits32(ioaddr + EMAC_TX_CTL1, EMAC_TX_DMA_START | EMAC_TX_DMA_EN);
}
static void sun8i_dwmac_dma_stop_tx(void __iomem *ioaddr, u32 chan)
{
- u32 v;
-
- v = readl(ioaddr + EMAC_TX_CTL1);
- v &= ~EMAC_TX_DMA_EN;
- writel(v, ioaddr + EMAC_TX_CTL1);
+ clrbits32(ioaddr + EMAC_TX_CTL1, EMAC_TX_DMA_EN);
}
static void sun8i_dwmac_dma_start_rx(void __iomem *ioaddr, u32 chan)
{
- u32 v;
-
- v = readl(ioaddr + EMAC_RX_CTL1);
- v |= EMAC_RX_DMA_START;
- v |= EMAC_RX_DMA_EN;
- writel(v, ioaddr + EMAC_RX_CTL1);
+ setbits32(ioaddr + EMAC_RX_CTL1, EMAC_RX_DMA_START | EMAC_RX_DMA_EN);
}
static void sun8i_dwmac_dma_stop_rx(void __iomem *ioaddr, u32 chan)
{
- u32 v;
-
- v = readl(ioaddr + EMAC_RX_CTL1);
- v &= ~EMAC_RX_DMA_EN;
- writel(v, ioaddr + EMAC_RX_CTL1);
+ clrbits32(ioaddr + EMAC_RX_CTL1, EMAC_RX_DMA_EN);
}
static int sun8i_dwmac_dma_interrupt(void __iomem *ioaddr,
@@ -608,11 +586,8 @@ static void sun8i_dwmac_get_umac_addr(struct mac_device_info *hw,
static int sun8i_dwmac_rx_ipc_enable(struct mac_device_info *hw)
{
void __iomem *ioaddr = hw->pcsr;
- u32 v;
- v = readl(ioaddr + EMAC_RX_CTL0);
- v |= EMAC_RX_DO_CRC;
- writel(v, ioaddr + EMAC_RX_CTL0);
+ setbits32(ioaddr + EMAC_RX_CTL0, EMAC_RX_DO_CRC);
return 1;
}
@@ -662,21 +637,16 @@ static void sun8i_dwmac_flow_ctrl(struct mac_device_info *hw,
unsigned int pause_time, u32 tx_cnt)
{
void __iomem *ioaddr = hw->pcsr;
- u32 v;
- v = readl(ioaddr + EMAC_RX_CTL0);
if (fc == FLOW_AUTO)
- v |= EMAC_RX_FLOW_CTL_EN;
+ setbits32(ioaddr + EMAC_RX_CTL0, EMAC_RX_FLOW_CTL_EN);
else
- v &= ~EMAC_RX_FLOW_CTL_EN;
- writel(v, ioaddr + EMAC_RX_CTL0);
+ clrbits32(ioaddr + EMAC_RX_CTL0, EMAC_RX_FLOW_CTL_EN);
- v = readl(ioaddr + EMAC_TX_FLOW_CTL);
if (fc == FLOW_AUTO)
- v |= EMAC_TX_FLOW_CTL_EN;
+ setbits32(ioaddr + EMAC_TX_FLOW_CTL, EMAC_TX_FLOW_CTL_EN);
else
- v &= ~EMAC_TX_FLOW_CTL_EN;
- writel(v, ioaddr + EMAC_TX_FLOW_CTL);
+ clrbits32(ioaddr + EMAC_TX_FLOW_CTL, EMAC_TX_FLOW_CTL_EN);
}
static int sun8i_dwmac_reset(struct stmmac_priv *priv)
@@ -684,8 +654,7 @@ static int sun8i_dwmac_reset(struct stmmac_priv *priv)
u32 v;
int err;
- v = readl(priv->ioaddr + EMAC_BASIC_CTL1);
- writel(v | 0x01, priv->ioaddr + EMAC_BASIC_CTL1);
+ setbits32(priv->ioaddr + EMAC_BASIC_CTL1, 0x01);
/* The timeout was previoulsy set to 10ms, but some board (OrangePI0)
* need more if no cable plugged. 100ms seems OK
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index 0877bde6e860..ca864c3d7ff3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -25,6 +25,7 @@
#include <linux/crc32.h>
#include <linux/slab.h>
#include <linux/ethtool.h>
+#include <linux/setbits.h>
#include <net/dsa.h>
#include <asm/io.h>
#include "stmmac.h"
@@ -355,7 +356,6 @@ static void dwmac1000_set_eee_mode(struct mac_device_info *hw,
bool en_tx_lpi_clockgating)
{
void __iomem *ioaddr = hw->pcsr;
- u32 value;
/*TODO - en_tx_lpi_clockgating treatment */
@@ -363,19 +363,16 @@ static void dwmac1000_set_eee_mode(struct mac_device_info *hw,
* receive path and instruct the transmit to enter in LPI
* state.
*/
- value = readl(ioaddr + LPI_CTRL_STATUS);
- value |= LPI_CTRL_STATUS_LPIEN | LPI_CTRL_STATUS_LPITXA;
- writel(value, ioaddr + LPI_CTRL_STATUS);
+ setbits32(ioaddr + LPI_CTRL_STATUS,
+ LPI_CTRL_STATUS_LPIEN | LPI_CTRL_STATUS_LPITXA);
}
static void dwmac1000_reset_eee_mode(struct mac_device_info *hw)
{
void __iomem *ioaddr = hw->pcsr;
- u32 value;
- value = readl(ioaddr + LPI_CTRL_STATUS);
- value &= ~(LPI_CTRL_STATUS_LPIEN | LPI_CTRL_STATUS_LPITXA);
- writel(value, ioaddr + LPI_CTRL_STATUS);
+ clrbits32(ioaddr + LPI_CTRL_STATUS,
+ (LPI_CTRL_STATUS_LPIEN | LPI_CTRL_STATUS_LPITXA));
}
static void dwmac1000_set_eee_pls(struct mac_device_info *hw, int link)
@@ -383,14 +380,10 @@ static void dwmac1000_set_eee_pls(struct mac_device_info *hw, int link)
void __iomem *ioaddr = hw->pcsr;
u32 value;
- value = readl(ioaddr + LPI_CTRL_STATUS);
-
if (link)
- value |= LPI_CTRL_STATUS_PLS;
+ setbits32(ioaddr + LPI_CTRL_STATUS, LPI_CTRL_STATUS_PLS);
else
- value &= ~LPI_CTRL_STATUS_PLS;
-
- writel(value, ioaddr + LPI_CTRL_STATUS);
+ clrbits32(ioaddr + LPI_CTRL_STATUS, LPI_CTRL_STATUS_PLS);
}
static void dwmac1000_set_eee_timer(struct mac_device_info *hw, int ls, int tw)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 7e5d5db0d516..998695cbf3c2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -17,6 +17,8 @@
#include <linux/slab.h>
#include <linux/ethtool.h>
#include <linux/io.h>
+#include <linux/setbits.h>
+#include <linux/setbits.h>
#include <net/dsa.h>
#include "stmmac.h"
#include "stmmac_pcs.h"
@@ -85,16 +87,11 @@ static void dwmac4_rx_queue_priority(struct mac_device_info *hw,
{
void __iomem *ioaddr = hw->pcsr;
u32 base_register;
- u32 value;
base_register = (queue < 4) ? GMAC_RXQ_CTRL2 : GMAC_RXQ_CTRL3;
- value = readl(ioaddr + base_register);
-
- value &= ~GMAC_RXQCTRL_PSRQX_MASK(queue);
- value |= (prio << GMAC_RXQCTRL_PSRQX_SHIFT(queue)) &
- GMAC_RXQCTRL_PSRQX_MASK(queue);
- writel(value, ioaddr + base_register);
+ clrsetbits32(ioaddr + base_register, GMAC_RXQCTRL_PSRQX_MASK(queue),
+ (prio << GMAC_RXQCTRL_PSRQX_SHIFT(queue)) & GMAC_RXQCTRL_PSRQX_MASK(queue));
}
static void dwmac4_tx_queue_priority(struct mac_device_info *hw,
@@ -102,17 +99,11 @@ static void dwmac4_tx_queue_priority(struct mac_device_info *hw,
{
void __iomem *ioaddr = hw->pcsr;
u32 base_register;
- u32 value;
base_register = (queue < 4) ? GMAC_TXQ_PRTY_MAP0 : GMAC_TXQ_PRTY_MAP1;
- value = readl(ioaddr + base_register);
-
- value &= ~GMAC_TXQCTRL_PSTQX_MASK(queue);
- value |= (prio << GMAC_TXQCTRL_PSTQX_SHIFT(queue)) &
- GMAC_TXQCTRL_PSTQX_MASK(queue);
-
- writel(value, ioaddr + base_register);
+ clrsetbits32(ioaddr + base_register, GMAC_TXQCTRL_PSTQX_MASK(queue),
+ (prio << GMAC_TXQCTRL_PSTQX_SHIFT(queue)) & GMAC_TXQCTRL_PSTQX_MASK(queue));
}
static void dwmac4_rx_queue_routing(struct mac_device_info *hw,
@@ -198,11 +189,9 @@ static void dwmac4_set_mtl_tx_queue_weight(struct mac_device_info *hw,
u32 weight, u32 queue)
{
void __iomem *ioaddr = hw->pcsr;
- u32 value = readl(ioaddr + MTL_TXQX_WEIGHT_BASE_ADDR(queue));
-
- value &= ~MTL_TXQ_WEIGHT_ISCQW_MASK;
- value |= weight & MTL_TXQ_WEIGHT_ISCQW_MASK;
- writel(value, ioaddr + MTL_TXQX_WEIGHT_BASE_ADDR(queue));
+ clrsetbits32(ioaddr + MTL_TXQX_WEIGHT_BASE_ADDR(queue),
+ MTL_TXQ_WEIGHT_ISCQW_MASK,
+ weight & MTL_TXQ_WEIGHT_ISCQW_MASK);
}
static void dwmac4_map_mtl_dma(struct mac_device_info *hw, u32 queue, u32 chan)
@@ -243,10 +232,8 @@ static void dwmac4_config_cbs(struct mac_device_info *hw,
pr_debug("\tlow_credit: 0x%08x\n", low_credit);
/* enable AV algorithm */
- value = readl(ioaddr + MTL_ETSX_CTRL_BASE_ADDR(queue));
- value |= MTL_ETS_CTRL_AVALG;
- value |= MTL_ETS_CTRL_CC;
- writel(value, ioaddr + MTL_ETSX_CTRL_BASE_ADDR(queue));
+ setbits32(ioaddr + MTL_ETSX_CTRL_BASE_ADDR(queue),
+ MTL_ETS_CTRL_AVALG | MTL_ETS_CTRL_CC);
/* configure send slope */
value = readl(ioaddr + MTL_SEND_SLP_CREDX_BASE_ADDR(queue));
@@ -360,11 +347,9 @@ static void dwmac4_set_eee_mode(struct mac_device_info *hw,
static void dwmac4_reset_eee_mode(struct mac_device_info *hw)
{
void __iomem *ioaddr = hw->pcsr;
- u32 value;
- value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
- value &= ~(GMAC4_LPI_CTRL_STATUS_LPIEN | GMAC4_LPI_CTRL_STATUS_LPITXA);
- writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
+ clrbits32(ioaddr + GMAC4_LPI_CTRL_STATUS,
+ (GMAC4_LPI_CTRL_STATUS_LPIEN | GMAC4_LPI_CTRL_STATUS_LPITXA));
}
static void dwmac4_set_eee_pls(struct mac_device_info *hw, int link)
@@ -372,14 +357,12 @@ static void dwmac4_set_eee_pls(struct mac_device_info *hw, int link)
void __iomem *ioaddr = hw->pcsr;
u32 value;
- value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
-
if (link)
- value |= GMAC4_LPI_CTRL_STATUS_PLS;
+ setbits32(ioaddr + GMAC4_LPI_CTRL_STATUS,
+ GMAC4_LPI_CTRL_STATUS_PLS);
else
- value &= ~GMAC4_LPI_CTRL_STATUS_PLS;
-
- writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
+ clrbits32(ioaddr + GMAC4_LPI_CTRL_STATUS,
+ GMAC4_LPI_CTRL_STATUS_PLS);
}
static void dwmac4_set_eee_timer(struct mac_device_info *hw, int ls, int tw)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index edb6053bd980..63c582ff24a1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -14,6 +14,7 @@
*/
#include <linux/io.h>
+#include <linux/setbits.h>
#include "dwmac4.h"
#include "dwmac4_dma.h"
@@ -270,9 +271,7 @@ static void dwmac4_dma_rx_chan_op_mode(void __iomem *ioaddr, int mode,
writel(mtl_rx_op, ioaddr + MTL_CHAN_RX_OP_MODE(channel));
/* Enable MTL RX overflow */
- mtl_rx_int = readl(ioaddr + MTL_CHAN_INT_CTRL(channel));
- writel(mtl_rx_int | MTL_RX_OVERFLOW_INT_EN,
- ioaddr + MTL_CHAN_INT_CTRL(channel));
+ setbits32(ioaddr + MTL_CHAN_INT_CTRL(channel), MTL_RX_OVERFLOW_INT_EN);
}
static void dwmac4_dma_tx_chan_op_mode(void __iomem *ioaddr, int mode,
@@ -422,12 +421,8 @@ static void dwmac4_qmode(void __iomem *ioaddr, u32 channel, u8 qmode)
static void dwmac4_set_bfsize(void __iomem *ioaddr, int bfsize, u32 chan)
{
- u32 value = readl(ioaddr + DMA_CHAN_RX_CONTROL(chan));
-
- value &= ~DMA_RBSZ_MASK;
- value |= (bfsize << DMA_RBSZ_SHIFT) & DMA_RBSZ_MASK;
-
- writel(value, ioaddr + DMA_CHAN_RX_CONTROL(chan));
+ clrsetbits32(ioaddr + DMA_CHAN_RX_CONTROL(chan), DMA_RBSZ_MASK,
+ (bfsize << DMA_RBSZ_SHIFT) & DMA_RBSZ_MASK);
}
const struct stmmac_dma_ops dwmac4_dma_ops = {
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c
index 49f5687879df..5f699cf54e17 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c
@@ -10,6 +10,7 @@
#include <linux/io.h>
#include <linux/delay.h>
+#include <linux/setbits.h>
#include "common.h"
#include "dwmac4_dma.h"
#include "dwmac4.h"
@@ -47,51 +48,26 @@ void dwmac4_set_tx_tail_ptr(void __iomem *ioaddr, u32 tail_ptr, u32 chan)
void dwmac4_dma_start_tx(void __iomem *ioaddr, u32 chan)
{
- u32 value = readl(ioaddr + DMA_CHAN_TX_CONTROL(chan));
-
- value |= DMA_CONTROL_ST;
- writel(value, ioaddr + DMA_CHAN_TX_CONTROL(chan));
-
- value = readl(ioaddr + GMAC_CONFIG);
- value |= GMAC_CONFIG_TE;
- writel(value, ioaddr + GMAC_CONFIG);
+ setbits32(ioaddr + DMA_CHAN_TX_CONTROL(chan), DMA_CONTROL_ST);
+ setbits32(ioaddr + GMAC_CONFIG, GMAC_CONFIG_TE);
}
void dwmac4_dma_stop_tx(void __iomem *ioaddr, u32 chan)
{
- u32 value = readl(ioaddr + DMA_CHAN_TX_CONTROL(chan));
-
- value &= ~DMA_CONTROL_ST;
- writel(value, ioaddr + DMA_CHAN_TX_CONTROL(chan));
-
- value = readl(ioaddr + GMAC_CONFIG);
- value &= ~GMAC_CONFIG_TE;
- writel(value, ioaddr + GMAC_CONFIG);
+ clrbits32(ioaddr + DMA_CHAN_TX_CONTROL(chan), DMA_CONTROL_ST);
+ clrbits32(ioaddr + GMAC_CONFIG, GMAC_CONFIG_TE);
}
void dwmac4_dma_start_rx(void __iomem *ioaddr, u32 chan)
{
- u32 value = readl(ioaddr + DMA_CHAN_RX_CONTROL(chan));
-
- value |= DMA_CONTROL_SR;
-
- writel(value, ioaddr + DMA_CHAN_RX_CONTROL(chan));
-
- value = readl(ioaddr + GMAC_CONFIG);
- value |= GMAC_CONFIG_RE;
- writel(value, ioaddr + GMAC_CONFIG);
+ setbits32(ioaddr + DMA_CHAN_RX_CONTROL(chan), DMA_CONTROL_SR);
+ setbits32(ioaddr + GMAC_CONFIG, GMAC_CONFIG_RE);
}
void dwmac4_dma_stop_rx(void __iomem *ioaddr, u32 chan)
{
- u32 value = readl(ioaddr + DMA_CHAN_RX_CONTROL(chan));
-
- value &= ~DMA_CONTROL_SR;
- writel(value, ioaddr + DMA_CHAN_RX_CONTROL(chan));
-
- value = readl(ioaddr + GMAC_CONFIG);
- value &= ~GMAC_CONFIG_RE;
- writel(value, ioaddr + GMAC_CONFIG);
+ clrbits32(ioaddr + DMA_CHAN_RX_CONTROL(chan), DMA_CONTROL_SR);
+ clrbits32(ioaddr + GMAC_CONFIG, GMAC_CONFIG_RE);
}
void dwmac4_set_tx_ring_len(void __iomem *ioaddr, u32 len, u32 chan)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac5.c b/drivers/net/ethernet/stmicro/stmmac/dwmac5.c
index 3f4f3132e16b..aec2fb884477 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac5.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac5.c
@@ -4,6 +4,7 @@
#include <linux/bitops.h>
#include <linux/iopoll.h>
+#include <linux/setbits.h>
#include "common.h"
#include "dwmac4.h"
#include "dwmac5.h"
@@ -307,9 +308,7 @@ static int dwmac5_rxp_disable(void __iomem *ioaddr)
u32 val;
int ret;
- val = readl(ioaddr + MTL_OPERATION_MODE);
- val &= ~MTL_FRPE;
- writel(val, ioaddr + MTL_OPERATION_MODE);
+ clrbits32(ioaddr + MTL_OPERATION_MODE, MTL_FRPE);
ret = readl_poll_timeout(ioaddr + MTL_RXP_CONTROL_STATUS, val,
val & RXPI, 1, 10000);
@@ -320,11 +319,7 @@ static int dwmac5_rxp_disable(void __iomem *ioaddr)
static void dwmac5_rxp_enable(void __iomem *ioaddr)
{
- u32 val;
-
- val = readl(ioaddr + MTL_OPERATION_MODE);
- val |= MTL_FRPE;
- writel(val, ioaddr + MTL_OPERATION_MODE);
+ setbits32(ioaddr + MTL_OPERATION_MODE, MTL_FRPE);
}
static int dwmac5_rxp_update_single_entry(void __iomem *ioaddr,
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
index 7516ca210855..acecb9f0ee4b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
@@ -18,6 +18,7 @@
#include <linux/io.h>
#include <linux/iopoll.h>
+#include <linux/setbits.h>
#include "common.h"
#include "dwmac_dma.h"
@@ -59,30 +60,22 @@ void dwmac_disable_dma_irq(void __iomem *ioaddr, u32 chan)
void dwmac_dma_start_tx(void __iomem *ioaddr, u32 chan)
{
- u32 value = readl(ioaddr + DMA_CONTROL);
- value |= DMA_CONTROL_ST;
- writel(value, ioaddr + DMA_CONTROL);
+ setbits32(ioaddr + DMA_CONTROL, DMA_CONTROL_ST);
}
void dwmac_dma_stop_tx(void __iomem *ioaddr, u32 chan)
{
- u32 value = readl(ioaddr + DMA_CONTROL);
- value &= ~DMA_CONTROL_ST;
- writel(value, ioaddr + DMA_CONTROL);
+ clrbits32(ioaddr + DMA_CONTROL, DMA_CONTROL_ST);
}
void dwmac_dma_start_rx(void __iomem *ioaddr, u32 chan)
{
- u32 value = readl(ioaddr + DMA_CONTROL);
- value |= DMA_CONTROL_SR;
- writel(value, ioaddr + DMA_CONTROL);
+ setbits32(ioaddr + DMA_CONTROL, DMA_CONTROL_SR);
}
void dwmac_dma_stop_rx(void __iomem *ioaddr, u32 chan)
{
- u32 value = readl(ioaddr + DMA_CONTROL);
- value &= ~DMA_CONTROL_SR;
- writel(value, ioaddr + DMA_CONTROL);
+ clrbits32(ioaddr + DMA_CONTROL, DMA_CONTROL_SR);
}
#ifdef DWMAC_DMA_DEBUG
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
index 64b8cb88ea45..fc7df8de2ba7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
@@ -4,6 +4,7 @@
* stmmac XGMAC support.
*/
+#include <linux/setbits.h>
#include "stmmac.h"
#include "dwxgmac2.h"
@@ -75,12 +76,10 @@ static int dwxgmac2_rx_ipc(struct mac_device_info *hw)
void __iomem *ioaddr = hw->pcsr;
u32 value;
- value = readl(ioaddr + XGMAC_RX_CONFIG);
if (hw->rx_csum)
- value |= XGMAC_CONFIG_IPC;
+ setbits32(ioaddr + XGMAC_RX_CONFIG, XGMAC_CONFIG_IPC);
else
- value &= ~XGMAC_CONFIG_IPC;
- writel(value, ioaddr + XGMAC_RX_CONFIG);
+ clrbits32(ioaddr + XGMAC_RX_CONFIG, XGMAC_CONFIG_IPC);
return !!(readl(ioaddr + XGMAC_RX_CONFIG) & XGMAC_CONFIG_IPC);
}
@@ -107,11 +106,8 @@ static void dwxgmac2_rx_queue_prio(struct mac_device_info *hw, u32 prio,
reg = (queue < 4) ? XGMAC_RXQ_CTRL2 : XGMAC_RXQ_CTRL3;
- value = readl(ioaddr + reg);
- value &= ~XGMAC_PSRQ(queue);
- value |= (prio << XGMAC_PSRQ_SHIFT(queue)) & XGMAC_PSRQ(queue);
-
- writel(value, ioaddr + reg);
+ clrsetbits32(ioaddr + reg, XGMAC_PSRQ(queue),
+ (prio << XGMAC_PSRQ_SHIFT(queue)) & XGMAC_PSRQ(queue));
}
static void dwxgmac2_prog_mtl_rx_algorithms(struct mac_device_info *hw,
@@ -170,11 +166,8 @@ static void dwxgmac2_map_mtl_to_dma(struct mac_device_info *hw, u32 queue,
reg = (queue < 4) ? XGMAC_MTL_RXQ_DMA_MAP0 : XGMAC_MTL_RXQ_DMA_MAP1;
- value = readl(ioaddr + reg);
- value &= ~XGMAC_QxMDMACH(queue);
- value |= (chan << XGMAC_QxMDMACH_SHIFT(queue)) & XGMAC_QxMDMACH(queue);
-
- writel(value, ioaddr + reg);
+ clrsetbits32(ioaddr + reg, XGMAC_QxMDMACH(queue),
+ (chan << XGMAC_QxMDMACH_SHIFT(queue)) & XGMAC_QxMDMACH(queue));
}
static void dwxgmac2_config_cbs(struct mac_device_info *hw,
@@ -189,9 +182,8 @@ static void dwxgmac2_config_cbs(struct mac_device_info *hw,
writel(high_credit, ioaddr + XGMAC_MTL_TCx_HICREDIT(queue));
writel(low_credit, ioaddr + XGMAC_MTL_TCx_LOCREDIT(queue));
- value = readl(ioaddr + XGMAC_MTL_TCx_ETS_CONTROL(queue));
- value |= XGMAC_CC | XGMAC_CBS;
- writel(value, ioaddr + XGMAC_MTL_TCx_ETS_CONTROL(queue));
+ setbits32(ioaddr + XGMAC_MTL_TCx_ETS_CONTROL(queue),
+ XGMAC_CC | XGMAC_CBS);
}
static int dwxgmac2_host_irq_status(struct mac_device_info *hw,
@@ -263,9 +255,7 @@ static void dwxgmac2_pmt(struct mac_device_info *hw, unsigned long mode)
if (mode & WAKE_UCAST)
val |= XGMAC_PWRDWN | XGMAC_GLBLUCAST | XGMAC_RWKPKTEN;
if (val) {
- u32 cfg = readl(ioaddr + XGMAC_RX_CONFIG);
- cfg |= XGMAC_CONFIG_RE;
- writel(cfg, ioaddr + XGMAC_RX_CONFIG);
+ setbits32(ioaddr + XGMAC_RX_CONFIG, XGMAC_CONFIG_RE);
}
writel(val, ioaddr + XGMAC_PMT);
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
index 6c5092e7771c..7a7d584211e9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
@@ -5,6 +5,7 @@
*/
#include <linux/iopoll.h>
+#include <linux/setbits.h>
#include "stmmac.h"
#include "dwxgmac2.h"
@@ -47,12 +48,9 @@ static void dwxgmac2_dma_init_rx_chan(void __iomem *ioaddr,
u32 dma_rx_phy, u32 chan)
{
u32 rxpbl = dma_cfg->rxpbl ?: dma_cfg->pbl;
- u32 value;
- value = readl(ioaddr + XGMAC_DMA_CH_RX_CONTROL(chan));
- value &= ~XGMAC_RxPBL;
- value |= (rxpbl << XGMAC_RxPBL_SHIFT) & XGMAC_RxPBL;
- writel(value, ioaddr + XGMAC_DMA_CH_RX_CONTROL(chan));
+ clrsetbits32(ioaddr + XGMAC_DMA_CH_RX_CONTROL(chan), XGMAC_RxPBL,
+ (rxpbl << XGMAC_RxPBL_SHIFT) & XGMAC_RxPBL);
writel(dma_rx_phy, ioaddr + XGMAC_DMA_CH_RxDESC_LADDR(chan));
}
@@ -150,8 +148,7 @@ static void dwxgmac2_dma_rx_mode(void __iomem *ioaddr, int mode,
writel(value, ioaddr + XGMAC_MTL_RXQ_OPMODE(channel));
/* Enable MTL RX overflow */
- value = readl(ioaddr + XGMAC_MTL_QINTEN(channel));
- writel(value | XGMAC_RXOIE, ioaddr + XGMAC_MTL_QINTEN(channel));
+ setbits32(ioaddr + XGMAC_MTL_QINTEN(channel), XGMAC_RXOIE);
}
static void dwxgmac2_dma_tx_mode(void __iomem *ioaddr, int mode,
@@ -209,54 +206,26 @@ static void dwxgmac2_disable_dma_irq(void __iomem *ioaddr, u32 chan)
static void dwxgmac2_dma_start_tx(void __iomem *ioaddr, u32 chan)
{
- u32 value;
-
- value = readl(ioaddr + XGMAC_DMA_CH_TX_CONTROL(chan));
- value |= XGMAC_TXST;
- writel(value, ioaddr + XGMAC_DMA_CH_TX_CONTROL(chan));
-
- value = readl(ioaddr + XGMAC_TX_CONFIG);
- value |= XGMAC_CONFIG_TE;
- writel(value, ioaddr + XGMAC_TX_CONFIG);
+ setbits32(ioaddr + XGMAC_DMA_CH_TX_CONTROL(chan), XGMAC_TXST);
+ setbits32(ioaddr + XGMAC_TX_CONFIG, XGMAC_CONFIG_TE);
}
static void dwxgmac2_dma_stop_tx(void __iomem *ioaddr, u32 chan)
{
- u32 value;
-
- value = readl(ioaddr + XGMAC_DMA_CH_TX_CONTROL(chan));
- value &= ~XGMAC_TXST;
- writel(value, ioaddr + XGMAC_DMA_CH_TX_CONTROL(chan));
-
- value = readl(ioaddr + XGMAC_TX_CONFIG);
- value &= ~XGMAC_CONFIG_TE;
- writel(value, ioaddr + XGMAC_TX_CONFIG);
+ clrbits32(ioaddr + XGMAC_DMA_CH_TX_CONTROL(chan), XGMAC_TXST);
+ clrbits32(ioaddr + XGMAC_TX_CONFIG, XGMAC_CONFIG_TE);
}
static void dwxgmac2_dma_start_rx(void __iomem *ioaddr, u32 chan)
{
- u32 value;
-
- value = readl(ioaddr + XGMAC_DMA_CH_RX_CONTROL(chan));
- value |= XGMAC_RXST;
- writel(value, ioaddr + XGMAC_DMA_CH_RX_CONTROL(chan));
-
- value = readl(ioaddr + XGMAC_RX_CONFIG);
- value |= XGMAC_CONFIG_RE;
- writel(value, ioaddr + XGMAC_RX_CONFIG);
+ setbits32(ioaddr + XGMAC_DMA_CH_RX_CONTROL(chan), XGMAC_RXST);
+ setbits32(ioaddr + XGMAC_RX_CONFIG, XGMAC_CONFIG_RE);
}
static void dwxgmac2_dma_stop_rx(void __iomem *ioaddr, u32 chan)
{
- u32 value;
-
- value = readl(ioaddr + XGMAC_DMA_CH_RX_CONTROL(chan));
- value &= ~XGMAC_RXST;
- writel(value, ioaddr + XGMAC_DMA_CH_RX_CONTROL(chan));
-
- value = readl(ioaddr + XGMAC_RX_CONFIG);
- value &= ~XGMAC_CONFIG_RE;
- writel(value, ioaddr + XGMAC_RX_CONFIG);
+ clrbits32(ioaddr + XGMAC_DMA_CH_RX_CONTROL(chan), XGMAC_RXST);
+ clrbits32(ioaddr + XGMAC_RX_CONFIG, XGMAC_CONFIG_RE);
}
static int dwxgmac2_dma_interrupt(void __iomem *ioaddr,
@@ -367,14 +336,10 @@ static void dwxgmac2_set_tx_tail_ptr(void __iomem *ioaddr, u32 ptr, u32 chan)
static void dwxgmac2_enable_tso(void __iomem *ioaddr, bool en, u32 chan)
{
- u32 value = readl(ioaddr + XGMAC_DMA_CH_TX_CONTROL(chan));
-
if (en)
- value |= XGMAC_TSE;
+ setbits32(ioaddr + XGMAC_DMA_CH_TX_CONTROL(chan), XGMAC_TSE);
else
- value &= ~XGMAC_TSE;
-
- writel(value, ioaddr + XGMAC_DMA_CH_TX_CONTROL(chan));
+ clrbits32(ioaddr + XGMAC_DMA_CH_TX_CONTROL(chan), XGMAC_TSE);
}
static void dwxgmac2_qmode(void __iomem *ioaddr, u32 channel, u8 qmode)
@@ -394,11 +359,7 @@ static void dwxgmac2_qmode(void __iomem *ioaddr, u32 channel, u8 qmode)
static void dwxgmac2_set_bfsize(void __iomem *ioaddr, int bfsize, u32 chan)
{
- u32 value;
-
- value = readl(ioaddr + XGMAC_DMA_CH_RX_CONTROL(chan));
- value |= bfsize << 1;
- writel(value, ioaddr + XGMAC_DMA_CH_RX_CONTROL(chan));
+ setbits32(ioaddr + XGMAC_DMA_CH_RX_CONTROL(chan), bfsize << 1);
}
const struct stmmac_dma_ops dwxgmac210_dma_ops = {
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
index 8d9cc2157afd..8680fb4b1fa8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
@@ -21,6 +21,7 @@
#include <linux/io.h>
#include <linux/delay.h>
+#include <linux/setbits.h>
#include "common.h"
#include "stmmac_ptp.h"
@@ -64,14 +65,11 @@ static void config_sub_second_increment(void __iomem *ioaddr,
static int init_systime(void __iomem *ioaddr, u32 sec, u32 nsec)
{
int limit;
- u32 value;
writel(sec, ioaddr + PTP_STSUR);
writel(nsec, ioaddr + PTP_STNSUR);
/* issue command to initialize the system time value */
- value = readl(ioaddr + PTP_TCR);
- value |= PTP_TCR_TSINIT;
- writel(value, ioaddr + PTP_TCR);
+ setbits32(ioaddr + PTP_TCR, PTP_TCR_TSINIT);
/* wait for present system time initialize to complete */
limit = 10;
@@ -88,14 +86,11 @@ static int init_systime(void __iomem *ioaddr, u32 sec, u32 nsec)
static int config_addend(void __iomem *ioaddr, u32 addend)
{
- u32 value;
int limit;
writel(addend, ioaddr + PTP_TAR);
/* issue command to update the addend value */
- value = readl(ioaddr + PTP_TCR);
- value |= PTP_TCR_TSADDREG;
- writel(value, ioaddr + PTP_TCR);
+ setbits32(ioaddr + PTP_TCR, PTP_TCR_TSADDREG);
/* wait for present addend update to complete */
limit = 10;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index b72ef171477e..b9cdf951eda6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -27,6 +27,7 @@
#include <linux/of_gpio.h>
#include <linux/of_mdio.h>
#include <linux/phy.h>
+#include <linux/setbits.h>
#include <linux/slab.h>
#include "dwxgmac2.h"
@@ -64,10 +65,8 @@ static int stmmac_xgmac2_c22_format(struct stmmac_priv *priv, int phyaddr,
return -EBUSY;
/* Set port as Clause 22 */
- tmp = readl(priv->ioaddr + XGMAC_MDIO_C22P);
- tmp &= ~MII_XGMAC_C22P_MASK;
- tmp |= BIT(phyaddr);
- writel(tmp, priv->ioaddr + XGMAC_MDIO_C22P);
+ clrsetbits32(priv->ioaddr + XGMAC_MDIO_C22P, MII_XGMAC_C22P_MASK,
+ BIT(phyaddr));
*hw_addr = (phyaddr << 16) | (phyreg & 0x1f);
return 0;
--
2.16.4
^ permalink raw reply related
* for_each_netdev_feature() broken on big endian
From: Mehrtens, Hauke @ 2018-09-07 15:10 UTC (permalink / raw)
To: netdev@vger.kernel.org; +Cc: Doychev, Zahari, Langer, Thomas
Hi,
On a MIPS 32 Big endian system the netdev_sync_upper_features() function does not work correctly.
It does not disbale bit 15 (NETIF_F_LRO, 0x0000000000008000), but 47 (NETIF_F_HW_TC, 0x0000800000000000).
The for_each_netdev_feature() macro is used to go over all netdev feature flags and calls for_each_set_bit() with a u64.
This is the code:
#define for_each_netdev_feature(mask_addr, bit) \
for_each_set_bit(bit, (unsigned long *)mask_addr, NETDEV_FEATURE_COUNT)
https://elixir.bootlin.com/linux/v4.19-rc2/source/include/linux/netdev_features.h#L157
The for_each_set_bit() macro calls the find_first_bit() macro and works directly on the bits in the memory
organized in 32 bit values in the generic implementation, see here:
https://elixir.bootlin.com/linux/v4.19-rc2/source/lib/find_bit.c#L102
On big endian systems the u64 value is stored in a different order in memory compared to little endian systems.
When I execute this code:
netdev_features_t upper_disables = NETIF_F_UPPER_DISABLES;
printk("%s:%i: addr: 0x%llx, size: %i\n", __func__, __LINE__, upper_disables, NETDEV_FEATURE_COUNT);
ret = find_first_bit((unsigned long *)&upper_disables, NETDEV_FEATURE_COUNT);
printk("%s:%i: addr: 0x%llx, size: %i, ret: %li\n", __func__, __LINE__, upper_disables, NETDEV_FEATURE_COUNT, ret);
I get this result:
[ 35.227140] netdev_sync_upper_features:6912: addr: 0x8000, size: 48
[ 35.233337] netdev_sync_upper_features:6914: addr: 0x8000, size: 48, ret: 47
Expected would be a ret: 15.
As I understood the documentation for for_each_set_bit() this should find the first bit in memory and not in a integer,
so for_each_netdev_feature() should not use for_each_set_bit().
I do not really know what a good fix would be, I could convert the feature flags to little endian before calling for_each_netdev_feature(), would this be ok?
Hauke
^ permalink raw reply
* Re: [PATCH 2/5] include: add setbits32/clrbits32/clrsetbits32/setbits64/clrbits64/clrsetbits64 in linux/setbits.h
From: Scott Wood @ 2018-09-07 20:00 UTC (permalink / raw)
To: Corentin Labbe, Gilles.Muller, Julia.Lawall, agust,
alexandre.torgue, alistair, benh, carlo, davem, galak, joabreu,
khilman, maxime.ripard, michal.lkml, mpe, mporter, nicolas.palix,
paulus, peppe.cavallaro, tj, vitb, wens
Cc: cocci, linux-amlogic, linux-arm-kernel, linux-ide, linux-kernel,
linuxppc-dev, netdev, linux-sunxi
In-Reply-To: <1536349307-20714-3-git-send-email-clabbe@baylibre.com>
On Fri, 2018-09-07 at 19:41 +0000, Corentin Labbe wrote:
> This patch adds setbits32/clrbits32/clrsetbits32 and
> setbits64/clrbits64/clrsetbits64 in linux/setbits.h header.
>
> Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
> ---
> include/linux/setbits.h | 55
> +++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 55 insertions(+)
> create mode 100644 include/linux/setbits.h
>
> diff --git a/include/linux/setbits.h b/include/linux/setbits.h
> new file mode 100644
> index 000000000000..3e1e273551bb
> --- /dev/null
> +++ b/include/linux/setbits.h
> @@ -0,0 +1,55 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __LINUX_SETBITS_H
> +#define __LINUX_SETBITS_H
> +
> +#include <linux/io.h>
> +
> +#define __setbits(readfunction, writefunction, addr, set) \
> + writefunction((readfunction(addr) | (set)), addr)
> +#define __clrbits(readfunction, writefunction, addr, mask) \
> + writefunction((readfunction(addr) & ~(mask)), addr)
> +#define __clrsetbits(readfunction, writefunction, addr, mask, set) \
> + writefunction(((readfunction(addr) & ~(mask)) | (set)), addr)
> +#define __setclrbits(readfunction, writefunction, addr, mask, set) \
> + writefunction(((readfunction(addr) | (seti)) & ~(mask)), addr)
> +
> +#define setbits32(addr, set) __setbits(readl, writel, addr, set)
> +#define setbits32_relaxed(addr, set) __setbits(readl_relaxed,
> writel_relaxed, \
> + addr, set)
> +
> +#define clrbits32(addr, mask) __clrbits(readl, writel, addr, mask)
> +#define clrbits32_relaxed(addr, mask) __clrbits(readl_relaxed,
> writel_relaxed, \
> + addr, mask)
So now setbits32/clrbits32 is implicitly little-endian? Introducing new
implicit-endian accessors is probably a bad thing in general, but doing it
with a name that until this patchset was implicitly big-endian (at least on
powerpc) seems worse. Why not setbits32_le()?
> +
> +#define clrsetbits32(addr, mask, set) __clrsetbits(readl, writel, addr,
> mask, set)
> +#define clrsetbits32_relaxed(addr, mask, set) __clrsetbits(readl_relaxed, \
> + writel_relaxed,
> \
> + addr, mask, set)
> +
> +#define setclrbits32(addr, mask, set) __setclrbits(readl, writel, addr,
> mask, set)
> +#define setclrbits32_relaxed(addr, mask, set) __setclrbits(readl_relaxed, \
> + writel_relaxed,
> \
> + addr, mask, set)
What's the use case for setclrbits? I don't see it used anywhere in this
patchset (not even in the coccinelle patterns), it doesn't seem like it would
be a common pattern, and it could easily get confused with clrsetbits.
-Scott
^ permalink raw reply
* Re: for_each_netdev_feature() broken on big endian
From: David Miller @ 2018-09-07 15:25 UTC (permalink / raw)
To: hauke.mehrtens; +Cc: netdev, zahari.doychev, thomas.langer
In-Reply-To: <9231D502B07C5E4A8B32D5115C9F19991EE57330@IRSMSX101.ger.corp.intel.com>
From: "Mehrtens, Hauke" <hauke.mehrtens@intel.com>
Date: Fri, 7 Sep 2018 15:10:53 +0000
> On a MIPS 32 Big endian system the netdev_sync_upper_features() function does not work correctly.
> It does not disbale bit 15 (NETIF_F_LRO, 0x0000000000008000), but 47 (NETIF_F_HW_TC, 0x0000800000000000).
>
> The for_each_netdev_feature() macro is used to go over all netdev feature flags and calls for_each_set_bit() with a u64.
> This is the code:
> #define for_each_netdev_feature(mask_addr, bit) \
> for_each_set_bit(bit, (unsigned long *)mask_addr, NETDEV_FEATURE_COUNT)
> https://elixir.bootlin.com/linux/v4.19-rc2/source/include/linux/netdev_features.h#L157
Good catch, yes we cannot use the the generic bit handling macros on the netdev
feature flags because the feature flags are a u64 operated on as a unit whereas
"long" may be 32-bit or 64-bit depending upon the architecture.
^ permalink raw reply
* Re: [PATCH v4 3/3] IB/ipoib: Log sysfs 'dev_id' accesses from userspace
From: Jason Gunthorpe @ 2018-09-07 15:43 UTC (permalink / raw)
To: Arseny Maslennikov; +Cc: linux-rdma, Doug Ledford, netdev
In-Reply-To: <20180906145112.29245-4-ar@cs.msu.ru>
On Thu, Sep 06, 2018 at 05:51:12PM +0300, Arseny Maslennikov wrote:
> Some tools may currently be using only the deprecated attribute;
> let's print an elaborate and clear deprecation notice to kmsg.
>
> To do that, we have to replace the whole sysfs file, since we inherit
> the original one from netdev.
>
> Signed-off-by: Arseny Maslennikov <ar@cs.msu.ru>
> drivers/infiniband/ulp/ipoib/ipoib_main.c | 31 +++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
> index 30f840f874b3..74732726ec6f 100644
> +++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
> @@ -2386,6 +2386,35 @@ int ipoib_add_pkey_attr(struct net_device *dev)
> return device_create_file(&dev->dev, &dev_attr_pkey);
> }
>
> +/*
> + * We erroneously exposed the iface's port number in the dev_id
> + * sysfs field long after dev_port was introduced for that purpose[1],
> + * and we need to stop everyone from relying on that.
> + * Let's overload the shower routine for the dev_id file here
> + * to gently bring the issue up.
> + *
> + * [1] https://www.spinics.net/lists/netdev/msg272123.html
> + */
> +static ssize_t dev_id_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct net_device *ndev = to_net_dev(dev);
> +
> + if (ndev->dev_id == ndev->dev_port)
> + netdev_info_once(ndev,
> + "\"%s\" wants to know my dev_id. Should it look at dev_port instead? See Documentation/ABI/testing/sysfs-class-net for more info.\n",
> + current->comm);
> +
> + return sprintf(buf, "%#x\n", ndev->dev_id);
> +}
> +static DEVICE_ATTR_RO(dev_id);
> +
> +int ipoib_intercept_dev_id_attr(struct net_device *dev)
> +{
> + device_remove_file(&dev->dev, &dev_attr_dev_id);
> + return device_create_file(&dev->dev, &dev_attr_dev_id);
> +}
Isn't this racey with userspace? Ie what happens if udev is querying
the dev_id right here?
Do we know there is no userspace doing this?
> static struct net_device *ipoib_add_port(const char *format,
> struct ib_device *hca, u8 port)
> {
> @@ -2427,6 +2456,8 @@ static struct net_device *ipoib_add_port(const char *format,
> */
> ndev->priv_destructor = ipoib_intf_free;
>
> + if (ipoib_intercept_dev_id_attr(ndev))
> + goto sysfs_failed;
No device_remove_file needed?
Jason
^ permalink raw reply
* Re: [**EXTERNAL**] Re: VRF with enslaved L3 enabled bridge
From: David Ahern @ 2018-09-07 16:09 UTC (permalink / raw)
To: D'Souza, Nelson, netdev@vger.kernel.org; +Cc: Ido Schimmel
In-Reply-To: <BYAPR04MB3797F5219C2164F3C0B6DE57AD000@BYAPR04MB3797.namprd04.prod.outlook.com>
On 9/7/18 9:56 AM, D'Souza, Nelson wrote:
> ------------------------------------------------------------------------
> *From:* David Ahern <dsa@cumulusnetworks.com>
> *Sent:* Thursday, September 6, 2018 5:27 PM
> *To:* D'Souza, Nelson; netdev@vger.kernel.org
> *Subject:* Re: [**EXTERNAL**] Re: VRF with enslaved L3 enabled bridge
>
> On 9/5/18 12:00 PM, D'Souza, Nelson wrote:
>> Just following up.... would you be able to confirm that this is a
> Linux VRF issue?
>
> I can confirm that I can reproduce the problem. Need to find time to dig
> into it.
bridge's netfilter hook is dropping the packet.
bridge's netfilter code registers hook operations that are invoked when
nh_hook is called. It then sees all subsequent calls to nf_hook.
Packet wise, the bridge netfilter hook runs first. br_nf_pre_routing
allocates nf_bridge, sets in_prerouting to 1 and calls NF_HOOK for
NF_INET_PRE_ROUTING. It's finish function, br_nf_pre_routing_finish,
then resets in_prerouting flag to 0. Any subsequent calls to nf_hook
invoke ip_sabotage_in. That function sees in_prerouting is not
set and steals (drops) the packet.
The simplest change is to have ip_sabotage_in recognize that the bridge
can be enslaved to a VRF (L3 master device) and allow the packet to
continue.
Thanks to Ido for the hint on ip_sabotage_in.
This patch works for me:
diff --git a/net/bridge/br_netfilter_hooks.c
b/net/bridge/br_netfilter_hooks.c
index 6e0dc6bcd32a..37278dc280eb 100644
--- a/net/bridge/br_netfilter_hooks.c
+++ b/net/bridge/br_netfilter_hooks.c
@@ -835,7 +835,8 @@ static unsigned int ip_sabotage_in(void *priv,
struct sk_buff *skb,
const struct nf_hook_state *state)
{
- if (skb->nf_bridge && !skb->nf_bridge->in_prerouting) {
+ if (skb->nf_bridge && !skb->nf_bridge->in_prerouting &&
+ !netif_is_l3_master(skb->dev)) {
state->okfn(state->net, state->sk, skb);
return NF_STOLEN;
}
^ permalink raw reply related
* RE: [PATCH v3 1/2] net: ethernet: i40e: fix build error
From: Keller, Jacob E @ 2018-09-07 21:42 UTC (permalink / raw)
To: Wang, Dongsheng, Kirsher, Jeffrey T,
sergei.shtylyov@cogentembedded.com
Cc: davem@davemloft.net, intel-wired-lan@lists.osuosl.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Wyborny, Carolyn
In-Reply-To: <f2b0bdfcb53c461191e71603257874ac@HXTBJIDCEMVIW02.hxtcorp.net>
> -----Original Message-----
> From: Wang, Dongsheng [mailto:dongsheng.wang@hxt-semitech.com]
> Sent: Friday, September 07, 2018 5:41 AM
> To: Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>;
> sergei.shtylyov@cogentembedded.com
> Cc: Keller, Jacob E <jacob.e.keller@intel.com>; davem@davemloft.net; intel-
> wired-lan@lists.osuosl.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; Wyborny, Carolyn <carolyn.wyborny@intel.com>
> Subject: Re: [PATCH v3 1/2] net: ethernet: i40e: fix build error
>
> Hello all,
>
> The i40e_ethtool_stats.h is just included by i40e/i40e_ethtool.c. So the
> static doesn't make any affect. And Carolyn's team is working rebuild
> i40e and i40evf.
>
> Cheers,
> Dongsheng
Dave wanted a fix sent to netdev by end of day today. I think the best immediate solution is to just migrate that code back into the i40e_ethtool.c and i40evf_ethtool.c files, rather than only the single function.
I'm going to send that patch to netdev now, since Jeff Kirsher is on vacation.
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH] ethernet: hnae: add unlikely() to assert()
From: David Miller @ 2018-09-07 21:46 UTC (permalink / raw)
To: igor.stoppa
Cc: huangdaode, igor.stoppa, yisen.zhuang, salil.mehta, netdev,
linux-kernel
In-Reply-To: <20180907172650.29408-1-igor.stoppa@huawei.com>
From: Igor Stoppa <igor.stoppa@gmail.com>
Date: Fri, 7 Sep 2018 20:26:50 +0300
> The assert() condition is likely to be true.
Worse than that is that drivers should not be definiting their own
private "assert()" macro.
I'd rather have that fixed instead. We have tons of standard kernel
facilities that do what they are trying to do here, without overloading
the standard C namespace in this way.
^ permalink raw reply
* Re: [PATCH] PCI: Reprogram bridge prefetch registers on resume
From: Bjorn Helgaas @ 2018-09-07 21:48 UTC (permalink / raw)
To: Daniel Drake
Cc: bhelgaas, linux-pci, linux, nouveau, linux-pm, peter, kherbst,
andriy.shevchenko, rafael.j.wysocki, keith.busch, mika.westerberg,
jonathan.derrick, kugel, davem, hkallweit1, netdev, nic_swsd,
linux-kernel
In-Reply-To: <20180907053614.6540-1-drake@endlessm.com>
[+cc LKML]
On Fri, Sep 07, 2018 at 01:36:14PM +0800, Daniel Drake wrote:
> On 38+ Intel-based Asus products, the nvidia GPU becomes unusable
> after S3 suspend/resume. The affected products include multiple
> generations of nvidia GPUs and Intel SoCs. After resume, nouveau logs
> many errors such as:
>
> fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR] client 04 [HUB/FE] reason 4a [] on channel -1 [007fa91000 unknown]
> DRM: failed to idle channel 0 [DRM]
>
> Similarly, the nvidia proprietary driver also fails after resume
> (black screen, 100% CPU usage in Xorg process). We shipped a sample
> to Nvidia for diagnosis, and their response indicated that it's a
> problem with the parent PCI bridge (on the Intel SoC), not the GPU.
>
> Runtime suspend/resume works fine, only S3 suspend is affected.
>
> We found a workaround: on resume, rewrite the Intel PCI bridge
> 'Prefetchable Base Upper 32 Bits' register (PCI_PREF_BASE_UPPER32). In
> the cases that I checked, this register has value 0 and we just have to
> rewrite that value.
>
> It's very strange that rewriting the exact same register value
> makes a difference, but it definitely makes the issue go away.
> It's not just acting as some kind of memory barrier, because rewriting
> other bridge registers does not work around the issue. There's something
> magic in this particular register. We have confirmed this on all
> the affected models we have in-hands (X542UQ, UX533FD, X530UN, V272UN).
>
> Additionally, this workaround solves an issue where r8169 MSI-X
> interrupts were broken after S3 suspend/resume on Asus X441UAR. This
> issue was recently worked around in commit 7bb05b85bc2d ("r8169:
> don't use MSI-X on RTL8106e"). It also fixes the same issue on
> RTL6186evl/8111evl on an Aimfor-tech laptop that we had not yet
> patched. I suspect it will also fix the issue that was worked around in
> commit 7c53a722459c ("r8169: don't use MSI-X on RTL8168g").
This is crazy. I would think *lots* of devices, like anything that
uses prefetchable memory, would be affected by this.
> Thomas Martitz reports that this workaround also solves an issue where
> the AMD Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive
> after S3 suspend/resume.
>
> From our testing, the affected Intel PCI bridges are:
> Intel Skylake PCIe Controller (x16) [8086:1901] (rev 05)
> Intel Skylake PCIe Controller (x16) [8086:1901] (rev 07)
> Intel Device [8086:31d8] (rev f3)
> Intel Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port B #1 [8086:5ad6] (rev fb)
> Intel Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #1 [8086:5ad8] (rev fb)
> Intel Sunrise Point-LP PCI Express Root Port [8086:9d10] (rev f1)
> Intel Sunrise Point-LP PCI Express Root Port #5 [8086:9d14] (rev f1)
> Intel Device [8086:9dbc] (rev f0)
>
> On resume, reprogram the PCI bridge prefetch registers, including the
> magic register mentioned above.
>
> This matches Win10 behaviour, which also rewrites these registers
> during S3 resume (checked with qemu tracing).
>
> Link: https://marc.info/?i=CAD8Lp46Y2eOR7WE28xToUL8s-aYiqPa0nS=1GSD0AxkddXq6+A@mail.gmail.com
Can you use
https://lkml.kernel.org/r/CAD8Lp46Y2eOR7WE28xToUL8s-aYiqPa0nS=1GSD0AxkddXq6+A@mail.gmail.com
instead, so we don't depend on marc.info? lkml.kernel.org doesn't have
linux-pci archives, but it might someday, and it does redirect to other
archives already.
> Link: https://bugs.freedesktop.org/show_bug.cgi?id=105760
I would really like to have a bugzilla.kernel.org issue with the
excellent debugging you and Peter did attached. Then we don't also
have to depend on github.com, etc., sticking around.
The list of platforms below could also be attached there, since you
went to a lot of trouble to collect it, but it's probably more than is
necessary for the changelog.
> Signed-off-by: Daniel Drake <drake@endlessm.com>
> ---
>
> Notes:
> Replaces patch:
> PCI: add prefetch quirk to work around Asus/Nvidia suspend issues
>
> Below is the list of Asus products with Intel/Nvidia that we
> believe are affected by the GPU resume issue.
>
> I revised my counting method from my last patch to eliminate duplicate
> platforms that had multiple SKUs with the same DMI/GPU/bridge, that's why
> the product count reduced from 43 to 38.
>
> sys_vendor: ASUSTeK COMPUTER INC.
> board_name: FX502VD
> product_name: FX502VD
> 01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1c8d] (rev ff) (prog-if ff)
> !!! Unknown header type 7f
> 00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:1901] (rev 05) (prog-if 00 [Normal decode])
> ...
^ permalink raw reply
* Re: [PATCH] freescale: ethernet: remove unnecessary unlikely()
From: David Miller @ 2018-09-07 21:50 UTC (permalink / raw)
To: igor.stoppa; +Cc: madalin.bucur, igor.stoppa, netdev, linux-kernel
In-Reply-To: <20180907172318.29014-1-igor.stoppa@huawei.com>
From: Igor Stoppa <igor.stoppa@gmail.com>
Date: Fri, 7 Sep 2018 20:23:18 +0300
> Both WARN_ON() and WARN_ONCE() already contain an unlikely(), so it's not
> necessary to wrap it into another.
>
> Signed-off-by: Igor Stoppa <igor.stoppa@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: Expose tagging protocol to user-space
From: David Miller @ 2018-09-07 21:51 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, linux-kernel
In-Reply-To: <20180907180908.3223-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Fri, 7 Sep 2018 11:09:02 -0700
> There is no way for user-space to know what a given DSA network device's
> tagging protocol is. Expose this information through a dsa/tagging
> attribute which reflects the tagging protocol currently in use.
>
> This is helpful for configuration (e.g: none behaves dramatically
> different wrt. bridges) as well as for packet capture tools when there
> is not a proper Ethernet type available.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied, thanks Florian.
^ permalink raw reply
* Re: [PATCH] r8169: set TxConfig register after TX / RX is enabled, just like RxConfig
From: David Miller @ 2018-09-07 21:53 UTC (permalink / raw)
To: mail; +Cc: nic_swsd, netdev, linux-kernel, a3at.mail, hkallweit1
In-Reply-To: <fd32f0db-373a-2ee4-8a99-5fe6c5441606@maciej.szmigiero.name>
From: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
Date: Fri, 7 Sep 2018 20:15:22 +0200
> Commit 3559d81e76bf ("r8169: simplify rtl_hw_start_8169") changed order of
> two register writes:
> 1) Caused RxConfig to be written before TX / RX is enabled,
> 2) Caused TxConfig to be written before TX / RX is enabled.
>
> At least on XIDs 10000000 ("RTL8169sb/8110sb") and
> 18000000 ("RTL8169sc/8110sc") such writes are ignored by the chip, leaving
> values in these registers intact.
>
> Change 1) was reverted by
> commit 05212ba8132b42 ("r8169: set RxConfig after tx/rx is enabled for RTL8169sb/8110sb devices"),
> however change 2) wasn't.
>
> In practice, this caused TxConfig's "InterFrameGap time" and "Max DMA Burst
> Size per Tx DMA Burst" bits to be zero dramatically reducing TX performance
> (in my tests it dropped from around 500Mbps to around 50Mbps).
>
> This patch fixes the issue by moving TxConfig register write a bit later in
> the code so it happens after TX / RX is already enabled.
>
> Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
> Fixes: 05212ba8132b42 ("r8169: set RxConfig after tx/rx is enabled for RTL8169sb/8110sb devices")
> ---
> "Fixes" tag points to the RxConfig fix instead of the actual commit that
> introduced this regression to maintain patch ordering since the RxConfig fix
> partially affects the same code lines as this fix.
Applied, thanks.
Please, in the future, always put your Fixes: tag first in the set of tags.
Thank you.
^ permalink raw reply
* Re: [PATCH v3 3/3] IB/ipoib: Log sysfs 'dev_id' accesses from userspace
From: Doug Ledford @ 2018-09-07 17:14 UTC (permalink / raw)
To: Leon Romanovsky, Arseny Maslennikov; +Cc: linux-rdma, Jason Gunthorpe, netdev
In-Reply-To: <20180906130358.GJ3142@mtr-leonro.mtl.com>
[-- Attachment #1: Type: text/plain, Size: 3831 bytes --]
On Thu, 2018-09-06 at 16:03 +0300, Leon Romanovsky wrote:
> On Thu, Sep 06, 2018 at 10:04:33AM +0300, Arseny Maslennikov wrote:
> > On Wed, Sep 05, 2018 at 04:50:35PM +0300, Leon Romanovsky wrote:
> > > On Mon, Sep 03, 2018 at 07:13:16PM +0300, Arseny Maslennikov wrote:
> > > > Signed-off-by: Arseny Maslennikov <ar@cs.msu.ru>
> > > > ---
> > > > drivers/infiniband/ulp/ipoib/ipoib_main.c | 38 +++++++++++++++++++++++
> > > > 1 file changed, 38 insertions(+)
> > > >
> > > > diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
> > > > index 30f840f874b3..7386e5bde3d3 100644
> > > > --- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
> > > > +++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
> > > > @@ -2386,6 +2386,42 @@ int ipoib_add_pkey_attr(struct net_device *dev)
> > > > return device_create_file(&dev->dev, &dev_attr_pkey);
> > > > }
> > > >
> > > > +/*
> > > > + * We erroneously exposed the iface's port number in the dev_id
> > > > + * sysfs field long after dev_port was introduced for that purpose[1],
> > > > + * and we need to stop everyone from relying on that.
> > > > + * Let's overload the shower routine for the dev_id file here
> > > > + * to gently bring the issue up.
> > > > + *
> > > > + * [1] https://www.spinics.net/lists/netdev/msg272123.html
> > > > + */
> > > > +static ssize_t dev_id_show(struct device *dev,
> > > > + struct device_attribute *attr, char *buf)
> > > > +{
> > > > + struct net_device *ndev = to_net_dev(dev);
> > > > + ssize_t ret = -EINVAL;
> > > > +
> > > > + if (ndev->dev_id == ndev->dev_port) {
> > > > + netdev_info_once(ndev,
> > > > + "\"%s\" wants to know my dev_id. "
> > > > + "Should it look at dev_port instead?\n",
> > > > + current->comm);
> > > > + netdev_info_once(ndev,
> > > > + "See Documentation/ABI/testing/sysfs-class-net for more info.\n");
> > > > + }
> > > > +
> > > > + ret = sprintf(buf, "%#x\n", ndev->dev_id);
> > > > +
> > > > + return ret;
> > > > +}
> > > > +static DEVICE_ATTR_RO(dev_id);
> > > > +
> > >
> > > I don't see this field among exposed by IPoIB, why should we expose it now?
> > >
> >
> > To deviate from standard netdev behaviour, which only prints the
> > field out. Doug wanted this to also print a deprecation message, and
> > netdev (obviously) does not do that. See below.
> >
> > > > +int ipoib_intercept_dev_id_attr(struct net_device *dev)
> > > > +{
> > > > + device_remove_file(&dev->dev, &dev_attr_dev_id);
> > > > + return device_create_file(&dev->dev, &dev_attr_dev_id);
> > >
> > > Why isn't enough to rely on netdev code?
> > >
> >
> > Netdev code relies on macros around a *static* function 'netdev_show',
> > which is defined in net/core/net-sysfs.c; it is not listed in any header
> > files, and the macros aren't as well. This all leads me to believe it
> > was not really meant to be used from outside net/core/net-sysfs.
> >
> > The only way we could use any netdev code here is to set up our own
> > handler (again), printk() a message, then call netdev_show — but we have
> > no access to it.
> >
> > Of course, it also may be that I'm terribly missing a clue.
>
> Thanks,
>
> IMHO, the end result of adequate Doug's request is a little bit too much.
> I don't think that it justifies such remove->create construction.
>
> Personal opinion.
I agree with you that the end result is kinda bulky, *but*, we will need
to know if there are things using the old dev_id before we can remove
it. In particular, I'm concerned the IPoIB handling code of
NetworkManager uses it. It's worth the cost I think.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 3/3] IB/ipoib: Log sysfs 'dev_id' accesses from userspace
From: Doug Ledford @ 2018-09-07 17:14 UTC (permalink / raw)
To: Jason Gunthorpe, Arseny Maslennikov; +Cc: linux-rdma, netdev
In-Reply-To: <20180907154359.GA14627@ziepe.ca>
[-- Attachment #1: Type: text/plain, Size: 3054 bytes --]
On Fri, 2018-09-07 at 09:43 -0600, Jason Gunthorpe wrote:
> On Thu, Sep 06, 2018 at 05:51:12PM +0300, Arseny Maslennikov wrote:
> > Some tools may currently be using only the deprecated attribute;
> > let's print an elaborate and clear deprecation notice to kmsg.
> >
> > To do that, we have to replace the whole sysfs file, since we inherit
> > the original one from netdev.
> >
> > Signed-off-by: Arseny Maslennikov <ar@cs.msu.ru>
> > drivers/infiniband/ulp/ipoib/ipoib_main.c | 31 +++++++++++++++++++++++
> > 1 file changed, 31 insertions(+)
> >
> > diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
> > index 30f840f874b3..74732726ec6f 100644
> > +++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
> > @@ -2386,6 +2386,35 @@ int ipoib_add_pkey_attr(struct net_device *dev)
> > return device_create_file(&dev->dev, &dev_attr_pkey);
> > }
> >
> > +/*
> > + * We erroneously exposed the iface's port number in the dev_id
> > + * sysfs field long after dev_port was introduced for that purpose[1],
> > + * and we need to stop everyone from relying on that.
> > + * Let's overload the shower routine for the dev_id file here
> > + * to gently bring the issue up.
> > + *
> > + * [1] https://www.spinics.net/lists/netdev/msg272123.html
> > + */
> > +static ssize_t dev_id_show(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + struct net_device *ndev = to_net_dev(dev);
> > +
> > + if (ndev->dev_id == ndev->dev_port)
> > + netdev_info_once(ndev,
> > + "\"%s\" wants to know my dev_id. Should it look at dev_port instead? See Documentation/ABI/testing/sysfs-class-net for more info.\n",
> > + current->comm);
> > +
> > + return sprintf(buf, "%#x\n", ndev->dev_id);
> > +}
> > +static DEVICE_ATTR_RO(dev_id);
> > +
> > +int ipoib_intercept_dev_id_attr(struct net_device *dev)
> > +{
> > + device_remove_file(&dev->dev, &dev_attr_dev_id);
> > + return device_create_file(&dev->dev, &dev_attr_dev_id);
> > +}
>
> Isn't this racey with userspace? Ie what happens if udev is querying
> the dev_id right here?
>
> Do we know there is no userspace doing this?
I don't think that it can race (or reasonably can). The intercept
function is done as part of ipoib_add_port() so the port itself isn't
live yet. Things like udev shouldn't be scanning it until after we've
finished bringing it up and added it to the system, so any race here is
unimportant IMO.
> > static struct net_device *ipoib_add_port(const char *format,
> > struct ib_device *hca, u8 port)
> > {
> > @@ -2427,6 +2456,8 @@ static struct net_device *ipoib_add_port(const char *format,
> > */
> > ndev->priv_destructor = ipoib_intf_free;
> >
> > + if (ipoib_intercept_dev_id_attr(ndev))
> > + goto sysfs_failed;
>
> No device_remove_file needed?
>
> Jason
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 0/5] introduce setbits32/clrbits32/clrsetbits32/setbits64/clrbits64/clrsetbits64 functions
From: David Miller @ 2018-09-07 21:57 UTC (permalink / raw)
To: clabbe
Cc: Gilles.Muller, Julia.Lawall, agust, alexandre.torgue, alistair,
benh, carlo, galak, joabreu, khilman, maxime.ripard, michal.lkml,
mpe, mporter, nicolas.palix, oss, paulus, peppe.cavallaro, tj,
vitb, wens, cocci, linux-amlogic, linux-arm-kernel, linux-ide,
linux-kernel, linuxppc-dev, netdev, linux-sunxi
In-Reply-To: <1536349307-20714-1-git-send-email-clabbe@baylibre.com>
If you are going to do this, please add for_each_set_bit64() and similar.
For example, see:
https://marc.info/?l=linux-netdev&m=153633391214025&w=2
^ permalink raw reply
* RE: linux-next: build failure after merge of the net-next tree
From: Keller, Jacob E @ 2018-09-07 22:03 UTC (permalink / raw)
To: David Miller
Cc: sfr@canb.auug.org.au, netdev@vger.kernel.org,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Kirsher, Jeffrey T, Bowers, AndrewX
In-Reply-To: <20180907.103112.1943018536705670414.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Friday, September 07, 2018 10:31 AM
> To: Keller, Jacob E <jacob.e.keller@intel.com>
> Cc: sfr@canb.auug.org.au; netdev@vger.kernel.org; linux-next@vger.kernel.org;
> linux-kernel@vger.kernel.org; Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>;
> Bowers, AndrewX <andrewx.bowers@intel.com>
> Subject: Re: linux-next: build failure after merge of the net-next tree
>
> From: "Keller, Jacob E" <jacob.e.keller@intel.com>
> Date: Fri, 7 Sep 2018 15:30:42 +0000
>
> > There's some discussion about this going on in the intel-wired-lan
> > mailing list.
>
> I really want to see a pull request in my inbox fixing this by the end
> of today or I'll apply a fix directly at my discretion.
Jeff is out, so I just opted to email a fix to netdev. I hope this is acceptable.
I opted to essentially revert the patch that moved code to i40e_ethtool_stats.h, rather than anything fancier, since it was fast, and correct.
There was a suggestion to only move the one offending function, but I felt that it was better to move everything back into the .c files.
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH v4 3/3] IB/ipoib: Log sysfs 'dev_id' accesses from userspace
From: Jason Gunthorpe @ 2018-09-07 17:24 UTC (permalink / raw)
To: Doug Ledford; +Cc: Arseny Maslennikov, linux-rdma, netdev
In-Reply-To: <2615124df732cc4d8926a708eaf11a47cbac4b3a.camel@redhat.com>
On Fri, Sep 07, 2018 at 01:14:51PM -0400, Doug Ledford wrote:
> On Fri, 2018-09-07 at 09:43 -0600, Jason Gunthorpe wrote:
> > On Thu, Sep 06, 2018 at 05:51:12PM +0300, Arseny Maslennikov wrote:
> > > Some tools may currently be using only the deprecated attribute;
> > > let's print an elaborate and clear deprecation notice to kmsg.
> > >
> > > To do that, we have to replace the whole sysfs file, since we inherit
> > > the original one from netdev.
> > >
> > > Signed-off-by: Arseny Maslennikov <ar@cs.msu.ru>
> > > drivers/infiniband/ulp/ipoib/ipoib_main.c | 31 +++++++++++++++++++++++
> > > 1 file changed, 31 insertions(+)
> > >
> > > diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
> > > index 30f840f874b3..74732726ec6f 100644
> > > +++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
> > > @@ -2386,6 +2386,35 @@ int ipoib_add_pkey_attr(struct net_device *dev)
> > > return device_create_file(&dev->dev, &dev_attr_pkey);
> > > }
> > >
> > > +/*
> > > + * We erroneously exposed the iface's port number in the dev_id
> > > + * sysfs field long after dev_port was introduced for that purpose[1],
> > > + * and we need to stop everyone from relying on that.
> > > + * Let's overload the shower routine for the dev_id file here
> > > + * to gently bring the issue up.
> > > + *
> > > + * [1] https://www.spinics.net/lists/netdev/msg272123.html
> > > + */
> > > +static ssize_t dev_id_show(struct device *dev,
> > > + struct device_attribute *attr, char *buf)
> > > +{
> > > + struct net_device *ndev = to_net_dev(dev);
> > > +
> > > + if (ndev->dev_id == ndev->dev_port)
> > > + netdev_info_once(ndev,
> > > + "\"%s\" wants to know my dev_id. Should it look at dev_port instead? See Documentation/ABI/testing/sysfs-class-net for more info.\n",
> > > + current->comm);
> > > +
> > > + return sprintf(buf, "%#x\n", ndev->dev_id);
> > > +}
> > > +static DEVICE_ATTR_RO(dev_id);
> > > +
> > > +int ipoib_intercept_dev_id_attr(struct net_device *dev)
> > > +{
> > > + device_remove_file(&dev->dev, &dev_attr_dev_id);
> > > + return device_create_file(&dev->dev, &dev_attr_dev_id);
> > > +}
> >
> > Isn't this racey with userspace? Ie what happens if udev is querying
> > the dev_id right here?
> >
> > Do we know there is no userspace doing this?
>
> I don't think that it can race (or reasonably can). The intercept
> function is done as part of ipoib_add_port() so the port itself isn't
> live yet.
The above code is after register_netdev, so the port itself is
certainly live as far as userspace is concerned..
All the other sysfs stuff in add_port is already wrong/racy.. See
Parav's recent series fixing this for the main devices..
Jason
^ permalink raw reply
* Re: [PATCH v3 3/3] IB/ipoib: Log sysfs 'dev_id' accesses from userspace
From: Leon Romanovsky @ 2018-09-07 17:28 UTC (permalink / raw)
To: Doug Ledford; +Cc: Arseny Maslennikov, linux-rdma, Jason Gunthorpe, netdev
In-Reply-To: <adc47601cbf388f7909bc01dd3b122d6558cc74e.camel@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 4338 bytes --]
On Fri, Sep 07, 2018 at 01:14:37PM -0400, Doug Ledford wrote:
> On Thu, 2018-09-06 at 16:03 +0300, Leon Romanovsky wrote:
> > On Thu, Sep 06, 2018 at 10:04:33AM +0300, Arseny Maslennikov wrote:
> > > On Wed, Sep 05, 2018 at 04:50:35PM +0300, Leon Romanovsky wrote:
> > > > On Mon, Sep 03, 2018 at 07:13:16PM +0300, Arseny Maslennikov wrote:
> > > > > Signed-off-by: Arseny Maslennikov <ar@cs.msu.ru>
> > > > > ---
> > > > > drivers/infiniband/ulp/ipoib/ipoib_main.c | 38 +++++++++++++++++++++++
> > > > > 1 file changed, 38 insertions(+)
> > > > >
> > > > > diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
> > > > > index 30f840f874b3..7386e5bde3d3 100644
> > > > > --- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
> > > > > +++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
> > > > > @@ -2386,6 +2386,42 @@ int ipoib_add_pkey_attr(struct net_device *dev)
> > > > > return device_create_file(&dev->dev, &dev_attr_pkey);
> > > > > }
> > > > >
> > > > > +/*
> > > > > + * We erroneously exposed the iface's port number in the dev_id
> > > > > + * sysfs field long after dev_port was introduced for that purpose[1],
> > > > > + * and we need to stop everyone from relying on that.
> > > > > + * Let's overload the shower routine for the dev_id file here
> > > > > + * to gently bring the issue up.
> > > > > + *
> > > > > + * [1] https://www.spinics.net/lists/netdev/msg272123.html
> > > > > + */
> > > > > +static ssize_t dev_id_show(struct device *dev,
> > > > > + struct device_attribute *attr, char *buf)
> > > > > +{
> > > > > + struct net_device *ndev = to_net_dev(dev);
> > > > > + ssize_t ret = -EINVAL;
> > > > > +
> > > > > + if (ndev->dev_id == ndev->dev_port) {
> > > > > + netdev_info_once(ndev,
> > > > > + "\"%s\" wants to know my dev_id. "
> > > > > + "Should it look at dev_port instead?\n",
> > > > > + current->comm);
> > > > > + netdev_info_once(ndev,
> > > > > + "See Documentation/ABI/testing/sysfs-class-net for more info.\n");
> > > > > + }
> > > > > +
> > > > > + ret = sprintf(buf, "%#x\n", ndev->dev_id);
> > > > > +
> > > > > + return ret;
> > > > > +}
> > > > > +static DEVICE_ATTR_RO(dev_id);
> > > > > +
> > > >
> > > > I don't see this field among exposed by IPoIB, why should we expose it now?
> > > >
> > >
> > > To deviate from standard netdev behaviour, which only prints the
> > > field out. Doug wanted this to also print a deprecation message, and
> > > netdev (obviously) does not do that. See below.
> > >
> > > > > +int ipoib_intercept_dev_id_attr(struct net_device *dev)
> > > > > +{
> > > > > + device_remove_file(&dev->dev, &dev_attr_dev_id);
> > > > > + return device_create_file(&dev->dev, &dev_attr_dev_id);
> > > >
> > > > Why isn't enough to rely on netdev code?
> > > >
> > >
> > > Netdev code relies on macros around a *static* function 'netdev_show',
> > > which is defined in net/core/net-sysfs.c; it is not listed in any header
> > > files, and the macros aren't as well. This all leads me to believe it
> > > was not really meant to be used from outside net/core/net-sysfs.
> > >
> > > The only way we could use any netdev code here is to set up our own
> > > handler (again), printk() a message, then call netdev_show — but we have
> > > no access to it.
> > >
> > > Of course, it also may be that I'm terribly missing a clue.
> >
> > Thanks,
> >
> > IMHO, the end result of adequate Doug's request is a little bit too much.
> > I don't think that it justifies such remove->create construction.
> >
> > Personal opinion.
>
> I agree with you that the end result is kinda bulky, *but*, we will need
> to know if there are things using the old dev_id before we can remove
> it. In particular, I'm concerned the IPoIB handling code of
> NetworkManager uses it. It's worth the cost I think.
I did my checks now and saw that ibdev2netdev uses the value provided
from this dev_id, so every invocation of that script will generate the
warning.
See this line in Parav's repo
https://github.com/Mellanox/container_scripts/blob/master/ibdev2netdev#L112
Thanks
>
> --
> Doug Ledford <dledford@redhat.com>
> GPG KeyID: B826A3330E572FDD
> Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/2] net: ethernet: i40evf: fix underlying build error
From: Wang, Dongsheng @ 2018-09-07 17:29 UTC (permalink / raw)
To: Wyborny, Carolyn, Kirsher, Jeffrey T,
sergei.shtylyov@cogentembedded.com
Cc: Keller, Jacob E, davem@davemloft.net,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <9BBC4E0CF881AA4299206E2E1412B6267C604A79@ORSMSX102.amr.corp.intel.com>
On 9/7/2018 11:27 PM, Wyborny, Carolyn wrote:
>> -----Original Message-----
>> From: Wang, Dongsheng [mailto:dongsheng.wang@hxt-semitech.com]
>> Sent: Friday, September 07, 2018 5:34 AM
>> To: Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>;
>> sergei.shtylyov@cogentembedded.com
>> Cc: Keller, Jacob E <jacob.e.keller@intel.com>; davem@davemloft.net;
>> intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; linux-
>> kernel@vger.kernel.org; Wyborny, Carolyn <carolyn.wyborny@intel.com>
>> Subject: Re: [PATCH v3 2/2] net: ethernet: i40evf: fix underlying build error
>>
>> Hello Jacob,
>>
>> Since Carolyn' team is working this, I think we don't need this patch
>> anymore because this header file is only for ethtool.c.
>> [..]
> Hello Dongsheng,
>
> The commonization effort we're working on is prioritizing our newest drivers. The i40e work is still being scoped, so we should fix this problem as needed now and not wait.
After Sergei agree. ;)
Cheers,
Dongsheng
> I apologize for any miscommunication. Was trying to let people know that we aware of the issue and are trying to make progress in that direction.
>
> Thanks,
>
> Carolyn
>
^ permalink raw reply
* Re: [PATCH] PCI: Reprogram bridge prefetch registers on resume
From: Bjorn Helgaas @ 2018-09-07 22:26 UTC (permalink / raw)
To: Peter Wu
Cc: Daniel Drake, bhelgaas, linux-pci, linux, nouveau, linux-pm,
kherbst, andriy.shevchenko, rafael.j.wysocki, keith.busch,
mika.westerberg, jonathan.derrick, kugel, davem, hkallweit1,
netdev, nic_swsd, linux-kernel, Dave Jones, Luming Yu
In-Reply-To: <20180907150515.GA28739@al>
[+cc LKML, Dave, Luming]
On Fri, Sep 07, 2018 at 05:05:15PM +0200, Peter Wu wrote:
> On Fri, Sep 07, 2018 at 01:36:14PM +0800, Daniel Drake wrote:
> <..>
> > Thomas Martitz reports that this workaround also solves an issue where
> > the AMD Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive
> > after S3 suspend/resume.
>
> Where was this claimed? It is not stated in the linked bug:
> (https://bugs.freedesktop.org/show_bug.cgi?id=105760
>
> > On resume, reprogram the PCI bridge prefetch registers, including the
> > magic register mentioned above.
> >
> > This matches Win10 behaviour, which also rewrites these registers
> > during S3 resume (checked with qemu tracing).
>
> Windows 10 unconditionally rewrites these registers (BAR, I/O Base +
> Limit, Memory Base + Limit, etc. from top to bottom), see annotations:
> https://www.spinics.net/lists/linux-pci/msg75856.html
>
> Linux has a generic "restore" operation that works backwards from the
> end of the PCI config space to the beginning, see
> pci_restore_config_space. Do you have a dmesg where you see the
> "restoring config space at offset" messages?
>
> Would it be reasonable to unconditionally write these registers in
> pci_restore_config_dword, like Windows does?
That sounds reasonable to me.
We did write them unconditionally, prior to 04d9c1a1100b ("[PATCH]
PCI: Improve PCI config space writeback") [1]. That commit apparently
fixed suspend on some laptop.
But at that time, we restored the config space in order of dword 0, 1,
2, ... 15, which means we restored the command register before the
BARs and windows, and it's conceivable that the problem was the
ordering, not the rewriting of the same value.
Only a week later, we reversed the order with 8b8c8d280ab2 ("[PATCH]
PCI: reverse pci config space restore order") [2], which seems like a
good idea and even includes a spec reference. I found similar
language in the Intel ICH 10 datasheet, sec 14.1.3 [3].
So it seems reasonable to me to try writing them unconditionally in
reverse order (the same order we use today).
[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=04d9c1a1100b
[2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8b8c8d280ab2
[3] Intel ICH 10 IBL 373635
^ permalink raw reply
* Re: [PATCH net-next] veth: report NEWLINK event when moving the peer device in a new namespace
From: Thomas Haller @ 2018-09-07 18:52 UTC (permalink / raw)
To: David Ahern, Lorenzo Bianconi; +Cc: David S. Miller, Network Development
In-Reply-To: <76fe95ba-d80f-e420-1982-97019aa09d7c@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1454 bytes --]
Hi David,
On Mon, 2018-09-03 at 20:54 -0600, David Ahern wrote:
> From init_net:
> $ ip monitor all-nsid
I thought the concern of the patch is the overhead of sending one
additional RTM_NEWLINK message. This workaround has likely higher
overhead. More importantly, it's so cumbersome, that I doubt anybody
would implementing such a solution.
When the events of one namespace are not sufficient to get all relevant
information (local to the namespace itself), the solution is not
monitor all-nsid.
You might save complexity and performance overhead in kernel. But what
you save here is just moved to user-space, which faces higher
complexity (at multiple places/projects, where developers are not
experts in netlink) and higher overhead.
RTM_GETLINK/NLM_F_DUMP allows to fetch information. The same
information is usually also emitted on changes via RTM_NEWLINK
notifications.
Yes, the information may be avilable somehow, but how cumbersome:
a) receive RTM_DELLINK, recognize that the message belongs to a
veth that was moved to another netns, and recognize that the peer's
IFLA_LINK changed. This approach only works when the veth is moved
away from the current namespace.
b) or, enable monitor all-nsid, receive RTM_NEWLINK, recognize that
the event is for moving a veth between netns, find the peer in the
other netns and recognize that the peer's IFLA_LINK changed.
best,
THomas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2] net: sched: change tcf_del_walker() to take idrinfo->lock
From: Cong Wang @ 2018-09-07 19:12 UTC (permalink / raw)
To: Vlad Buslov
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
David Miller
In-Reply-To: <1536328317-8170-1-git-send-email-vladbu@mellanox.com>
On Fri, Sep 7, 2018 at 6:52 AM Vlad Buslov <vladbu@mellanox.com> wrote:
>
> Action API was changed to work with actions and action_idr in concurrency
> safe manner, however tcf_del_walker() still uses actions without taking a
> reference or idrinfo->lock first, and deletes them directly, disregarding
> possible concurrent delete.
>
> Add tc_action_wq workqueue to action API. Implement
> tcf_idr_release_unsafe() that assumes external synchronization by caller
> and delays blocking action cleanup part to tc_action_wq workqueue. Extend
> tcf_action_cleanup() with 'async' argument to indicate that function should
> free action asynchronously.
Where exactly is blocking in tcf_action_cleanup()?
>From your code, it looks like free_tcf(), but from my observation,
the only blocking function inside is tcf_action_goto_chain_fini()
which calls __tcf_chain_put(). But, __tcf_chain_put() is blocking
_ONLY_ when tc_chain_notify() is called, for tc action it is never
called.
So, what else is blocking?
^ permalink raw reply
* [PATCH 2/5] include: add setbits32/clrbits32/clrsetbits32/setbits64/clrbits64/clrsetbits64 in linux/setbits.h
From: Corentin Labbe @ 2018-09-07 19:41 UTC (permalink / raw)
To: Gilles.Muller, Julia.Lawall, agust, alexandre.torgue, alistair,
benh, carlo, davem, galak, joabreu, khilman, maxime.ripard,
michal.lkml, mpe, mporter, nicolas.palix, oss, paulus,
peppe.cavallaro, tj, vitb, wens
Cc: cocci, linux-amlogic, linux-arm-kernel, linux-ide, linux-kernel,
linuxppc-dev, netdev, linux-sunxi, Corentin Labbe
In-Reply-To: <1536349307-20714-1-git-send-email-clabbe@baylibre.com>
This patch adds setbits32/clrbits32/clrsetbits32 and
setbits64/clrbits64/clrsetbits64 in linux/setbits.h header.
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
include/linux/setbits.h | 55 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 55 insertions(+)
create mode 100644 include/linux/setbits.h
diff --git a/include/linux/setbits.h b/include/linux/setbits.h
new file mode 100644
index 000000000000..3e1e273551bb
--- /dev/null
+++ b/include/linux/setbits.h
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __LINUX_SETBITS_H
+#define __LINUX_SETBITS_H
+
+#include <linux/io.h>
+
+#define __setbits(readfunction, writefunction, addr, set) \
+ writefunction((readfunction(addr) | (set)), addr)
+#define __clrbits(readfunction, writefunction, addr, mask) \
+ writefunction((readfunction(addr) & ~(mask)), addr)
+#define __clrsetbits(readfunction, writefunction, addr, mask, set) \
+ writefunction(((readfunction(addr) & ~(mask)) | (set)), addr)
+#define __setclrbits(readfunction, writefunction, addr, mask, set) \
+ writefunction(((readfunction(addr) | (seti)) & ~(mask)), addr)
+
+#define setbits32(addr, set) __setbits(readl, writel, addr, set)
+#define setbits32_relaxed(addr, set) __setbits(readl_relaxed, writel_relaxed, \
+ addr, set)
+
+#define clrbits32(addr, mask) __clrbits(readl, writel, addr, mask)
+#define clrbits32_relaxed(addr, mask) __clrbits(readl_relaxed, writel_relaxed, \
+ addr, mask)
+
+#define clrsetbits32(addr, mask, set) __clrsetbits(readl, writel, addr, mask, set)
+#define clrsetbits32_relaxed(addr, mask, set) __clrsetbits(readl_relaxed, \
+ writel_relaxed, \
+ addr, mask, set)
+
+#define setclrbits32(addr, mask, set) __setclrbits(readl, writel, addr, mask, set)
+#define setclrbits32_relaxed(addr, mask, set) __setclrbits(readl_relaxed, \
+ writel_relaxed, \
+ addr, mask, set)
+
+/* We cannot use CONFIG_64BIT as some x86 drivers use writeq */
+#if defined(writeq) && defined(readq)
+#define setbits64(addr, set) __setbits(readq, writeq, addr, set)
+#define setbits64_relaxed(addr, set) __setbits(readq_relaxed, writeq_relaxed, \
+ addr, set)
+
+#define clrbits64(addr, mask) __clrbits(readq, writeq, addr, mask)
+#define clrbits64_relaxed(addr, mask) __clrbits(readq_relaxed, writeq_relaxed, \
+ addr, mask)
+
+#define clrsetbits64(addr, mask, set) __clrsetbits(readq, writeq, addr, mask, set)
+#define clrsetbits64_relaxed(addr, mask, set) __clrsetbits(readq_relaxed, \
+ writeq_relaxed, \
+ addr, mask, set)
+
+#define setclrbits64(addr, mask, set) __setclrbits(readq, writeq, addr, mask, set)
+#define setclrbits64_relaxed(addr, mask, set) __setclrbits(readq_relaxed, \
+ writeq_relaxed, \
+ addr, mask, set)
+#endif /* writeq/readq */
+
+#endif /* __LINUX_SETBITS_H */
--
2.16.4
^ permalink raw reply related
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