* [PATCH net-next 5/5] cxgb4: Support firmware rdma write completion work request.
From: Raju Rangoju @ 2018-03-17 7:22 UTC (permalink / raw)
To: netdev, davem
Cc: nirranjan, indranil, venkatesh, swise, bharat, Raju Rangoju,
Ganesh Goudar
In-Reply-To: <20180317072229.21211-1-rajur@chelsio.com>
From: Potnuri Bharat Teja <bharat@chelsio.com>
If FW supports RDMA WRITE_COMPLETION functionality, then advertise that
to the ULDs. This will be used by iw_cxgb4 to allow WRITE_COMPLETION
work requests.
Signed-off-by: Potnuri Bharat Teja <bharat@chelsio.com>
Signed-off-by: Raju Rangoju <rajur@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 6 ++++++
drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c | 1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h | 1 +
drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 2 ++
5 files changed, 11 insertions(+)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 507c9bc968c7..c7fe4d46c0d4 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -391,6 +391,7 @@ struct adapter_params {
*/
u8 mps_bg_map[MAX_NPORTS]; /* MPS Buffer Group Map */
bool write_w_imm_support; /* FW supports WRITE_WITH_IMMEDIATE */
+ bool write_cmpl_support; /* FW supports WRITE_CMPL */
};
/* State needed to monitor the forward progress of SGE Ingress DMA activities
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index fd4dc1bd27f8..efed7cc64e86 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -4294,6 +4294,12 @@ static int adap_init0(struct adapter *adap)
ret = t4_query_params(adap, adap->mbox, adap->pf, 0, 1, params,
val);
adap->params.write_w_imm_support = (ret == 0 && val[0] != 0);
+
+ /* Enable write_cmpl if FW supports it */
+ params[0] = FW_PARAM_DEV(RI_WRITE_CMPL_WR);
+ ret = t4_query_params(adap, adap->mbox, adap->pf, 0, 1, params,
+ val);
+ adap->params.write_cmpl_support = (ret == 0 && val[0] != 0);
adap->num_ofld_uld += 2;
}
if (caps_cmd.iscsicaps) {
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c
index eff12e9a4b46..5926edd8b4b2 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c
@@ -666,6 +666,7 @@ static void uld_init(struct adapter *adap, struct cxgb4_lld_info *lld)
lld->nodeid = dev_to_node(adap->pdev_dev);
lld->fr_nsmr_tpte_wr_support = adap->params.fr_nsmr_tpte_wr_support;
lld->write_w_imm_support = adap->params.write_w_imm_support;
+ lld->write_cmpl_support = adap->params.write_cmpl_support;
}
static void uld_attach(struct adapter *adap, unsigned int uld)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h
index dd3359374b20..1b4a1a1ec75a 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h
@@ -354,6 +354,7 @@ struct cxgb4_lld_info {
int nodeid; /* device numa node id */
bool fr_nsmr_tpte_wr_support; /* FW supports FR_NSMR_TPTE_WR */
bool write_w_imm_support; /* FW supports WRITE_WITH_IMMEDIATE */
+ bool write_cmpl_support; /* FW supports WRITE_CMPL WR */
};
struct cxgb4_uld_info {
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
index 174ae3e8b556..3876685904ba 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
@@ -101,6 +101,7 @@ enum fw_wr_opcodes {
FW_RI_BIND_MW_WR = 0x18,
FW_RI_FR_NSMR_WR = 0x19,
FW_RI_FR_NSMR_TPTE_WR = 0x20,
+ FW_RI_RDMA_WRITE_CMPL_WR = 0x21,
FW_RI_INV_LSTAG_WR = 0x1a,
FW_ISCSI_TX_DATA_WR = 0x45,
FW_PTP_TX_PKT_WR = 0x46,
@@ -1212,6 +1213,7 @@ enum fw_params_param_dev {
FW_PARAMS_PARAM_DEV_MPSBGMAP = 0x1E,
FW_PARAMS_PARAM_DEV_RDMA_WRITE_WITH_IMM = 0x21,
+ FW_PARAMS_PARAM_DEV_RI_WRITE_CMPL_WR = 0x24,
};
/*
--
2.13.0
^ permalink raw reply related
* Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()
From: Kees Cook @ 2018-03-17 7:27 UTC (permalink / raw)
To: Linus Torvalds
Cc: Al Viro, Florian Weimer, Andrew Morton, Josh Poimboeuf,
Rasmus Villemoes, Randy Dunlap, Miguel Ojeda, Ingo Molnar,
David Laight, Ian Abbott, linux-input, linux-btrfs,
Network Development, Linux Kernel Mailing List, Kernel Hardening
In-Reply-To: <CA+55aFzsrVF7W+YQye=EeF4Wk3yDOTbb_vSiM8s1zkKbE4JV4Q@mail.gmail.com>
On Fri, Mar 16, 2018 at 12:27 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> Kees - is there some online "gcc-4.4 checker" somewhere? This does
> seem to work with my gcc. I actually tested some of those files you
> pointed at now.
Unfortunately my 4.4 test fails quickly:
./include/linux/jiffies.h: In function ‘jiffies_delta_to_clock_t’:
./include/linux/jiffies.h:444: error: first argument to
‘__builtin_choose_expr’ not a constant
static inline clock_t jiffies_delta_to_clock_t(long delta)
{
return jiffies_to_clock_t(max(0L, delta));
}
I think this is the same problem of using __builtin_constant_p() in
4.4 that we hit earlier? :(
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?
From: Frantisek Rysanek @ 2018-03-17 7:39 UTC (permalink / raw)
To: Andrew Lunn, netdev
In-Reply-To: <20180316210240.GB8735@lunn.ch>
On 16 Mar 2018 at 22:02, Andrew Lunn wrote:
>
> Does ethtool -m show anything useful?
>
Not much. "unsupported".
Probably the ioctl() is not implemented or something, I haven't
investigated. Maybe I should.
Right now I've modded igb_init_i2c() to engage the bit-banging
i2c driver for the i210 too, if SGMII active and external MDIO off.
Which gets me a /dev/i2c-8 created (with modprobe i2c-dev),
and I'm trying an 8bit read transaction on slave addresses from 0 to
127, which yields no responses.
Maybe the 8bit transaction is not the right way to do it,
maybe I should use indirect access, I'm just a little scared of that,
I'd hate to reprogram the SFP inadvertently :-)
I know that I'd have to pipe this bit-banging stuff into the Ethtool
ioctl handling stuff, to get it to work via ethtool -m.
The way I have hacked the driver, I've noticed that if I enable the
BB mode in I2CPARAMS, the driver won't load completely,
because the HW-based I2C controller is defunct, and the driver gets
nothing at all when trying to read the PHY_ID.
But if I first leave I2CPARAMS configured for HW-driven I2C,
load the driver, and then switch I2CPARAMS to BB mode,
I get the bit-banged I2C device loaded and the bit-twiddling
callbacks in igb.ko do get called.
I'm currently using devmem2 to tweak I2CPARAMS:
devmem2 0xF750102C w 0x00007646
devmem2 0xF750102C w 0x00007746
I should probably decide which way to go, HW i2c or SW i2c :-)
and mod the driver accordingly.
I'm currently looking at the bb i2c callbacks in igb.ko with some
suspicion... they seem a little too coarse to me. I'd expect some
finer timing around "tri-state the pin, wait a few us and only then
read the input". E.g. when checking for an ACK from the slave.
I'm not sure if I should "take the i210 HW semaphore" while
bit-banging the i2c stuff. Currently the BB code doesn't do that.
Not sure if this prevents the bits from getting in and out
at the PCB traces. Will have to check on monday.
I've also noticed the drivers/net/phy/mdio-i2c.c .
Maybe I should engage this instead or on top of the generic I2C
bit-banging framework :-)
=> I haven't tried all my ideas yet and will have to stop tweaking
for now... I'm playing with this remotely at home via SSH,
so I don't see the 'scope (if anything happens on the bus in the BB
mode). And it's time for breakfast :-)
Frank
^ permalink raw reply
* [PATCH] vmxnet3: fix LRO feature check
From: Igor Pylypiv @ 2018-03-17 7:58 UTC (permalink / raw)
To: Shrikrishna Khare, VMware, Inc.; +Cc: netdev, ipylypiv
rxcsum and lro fields were deleted in commit a0d2730c9571 ("net: vmxnet3:
convert to hw_features"). With upgrading to newer version those fields were
resurrected and new code started using uninitialized lro field.
Removing rxcsum and lro fields.
Fixes: 45dac1d6ea04 ("vmxnet3: Changes for vmxnet3 adapter version 2 (fwd)")
Signed-off-by: Igor Pylypiv <ipylypiv@silver-peak.com>
---
drivers/net/vmxnet3/vmxnet3_drv.c | 4 +++-
drivers/net/vmxnet3/vmxnet3_int.h | 3 ---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 8b39c160743d..60776c86aaaf 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -1470,8 +1470,10 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
vmxnet3_rx_csum(adapter, skb,
(union Vmxnet3_GenericDesc *)rcd);
skb->protocol = eth_type_trans(skb, adapter->netdev);
- if (!rcd->tcp || !adapter->lro)
+ if (!rcd->tcp ||
+ !adapter->netdev->features & NETIF_F_LRO) {
goto not_lro;
+ }
if (segCnt != 0 && mss != 0) {
skb_shinfo(skb)->gso_type = rcd->v4 ?
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h b/drivers/net/vmxnet3/vmxnet3_int.h
index 5ba222920e80..3de4cecda35a 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -342,9 +342,6 @@ struct vmxnet3_adapter {
u8 __iomem *hw_addr1; /* for BAR 1 */
u8 version;
- bool rxcsum;
- bool lro;
-
#ifdef VMXNET3_RSS
struct UPT1_RSSConf *rss_conf;
bool rss;
--
2.16.2
^ permalink raw reply related
* [PATCH net-next 00/12] ARM: sun8i: r40: Add Ethernet support
From: Chen-Yu Tsai @ 2018-03-17 9:28 UTC (permalink / raw)
To: Maxime Ripard, Michael Turquette, Stephen Boyd,
Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
Cc: devicetree, netdev, Chen-Yu Tsai, Corentin Labbe, linux-clk,
linux-arm-kernel, Icenowy Zheng
Hi everyone,
This series adds support for the DWMAC based Ethernet controller found
on the Allwinner R40 SoC. The controller is either a DWMAC clone or
DWMAC core with its registers rearranged. This is already supported by
the dwmac-sun8i driver. The glue layer control registers, unlike other
sun8i family SoCs, is not in the system controller region, but in the
clock control unit, like with the older A20 and A31 SoCs.
Mark (Brown), could you take a look at the regmap bits in patches 2 and
7? While we reuse the bindings for dwmac-sun8i using a syscon phandle
reference, we need some custom plumbing for the clock driver to export
a regmap that only allows access to the GMAC register to the dwmac-sun8i
driver. An alternative would be to allow drivers to register custom
syscon devices with their own regmap and locking.
Patch 1 converts the CLK_OF_DECLARE style clock driver to a platform
one, so the regmap introduced later has a struct device to tie to.
Patch 2 adds a regmap that is exported by the clock driver for the
dwmac-sun8i driver to use.
Patch 3 and 4 clean up the dwmac-sun8i binding.
Patch 5 adds device tree binding for Allwinner R40's Ethernet
controller.
Patch 6 converts regmap access of the syscon region in the dwmac-sun8i
driver to regmap_field, in anticipation of different field widths on
the R40.
Patch 7 introduces custom plumbing in the dwmac-sun8i driver to fetch
a regmap from the clock module, by looking up a device via a phandle,
then getting the regmap associated with that device.
Patch 8 adds support for different or absent TX/RX delay chain ranges
to the dwmac-sun8i driver.
Patch 9 adds support for the R40's ethernet controller.
Patch 10 cleans up the Bananapi M2 Ultra device tree file.
Patch 11 adds a GMAC device node and RGMII mode pinmux setting for the
R40.
Patch 12 enables Ethernet on the Bananapi M2 Ultra.
Please have a look.
Regards
ChenYu
Chen-Yu Tsai (10):
dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
dt-bindings: net: dwmac-sun8i: Sort syscon compatibles by alphabetical
order
dt-bindings: net: dwmac-sun8i: Add binding for GMAC on Allwinner R40
SoC
net: stmmac: dwmac-sun8i: Use regmap_field for syscon register access
net: stmmac: dwmac-sun8i: Allow getting syscon regmap from CCU device
net: stmmac: dwmac-sun8i: Support different ranges for TX/RX delay
chains
net: stmmac: dwmac-sun8i: Add support for GMAC on Allwinner R40 SoC
ARM: dts: sun8i: r40: bananapi-m2-ultra: Sort device node dereferences
ARM: dts: sun8i: r40: Add device node and RGMII pinmux node for GMAC
ARM: dts: sun8i: r40: bananapi-m2-ultra: Enable GMAC ethernet
controller
Icenowy Zheng (2):
clk: sunxi-ng: r40: rewrite init code to a platform driver
clk: sunxi-ng: r40: export a regmap to access the GMAC register
.../devicetree/bindings/net/dwmac-sun8i.txt | 17 ++-
arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 99 ++++++++++------
arch/arm/boot/dts/sun8i-r40.dtsi | 34 ++++++
drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 70 +++++++++--
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 128 +++++++++++++++++----
5 files changed, 278 insertions(+), 70 deletions(-)
--
2.16.2
^ permalink raw reply
* [PATCH net-next 01/12] clk: sunxi-ng: r40: rewrite init code to a platform driver
From: Chen-Yu Tsai @ 2018-03-17 9:28 UTC (permalink / raw)
To: Maxime Ripard, Michael Turquette, Stephen Boyd,
Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
Cc: devicetree, netdev, Chen-Yu Tsai, Corentin Labbe, linux-clk,
linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20180317092857.4396-1-wens@csie.org>
From: Icenowy Zheng <icenowy@aosc.io>
As we need to register a regmap on the R40 CCU, there needs to be a
device structure bound to the CCU device node.
Rewrite the R40 CCU driver initial code to make it a proper platform
driver, thus we will have a platform device bound to it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 39 ++++++++++++++++++++++++++----------
1 file changed, 28 insertions(+), 11 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
index 933f2e68f42a..c3aa839a453d 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
@@ -12,7 +12,8 @@
*/
#include <linux/clk-provider.h>
-#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
#include "ccu_common.h"
#include "ccu_reset.h"
@@ -1250,17 +1251,17 @@ static struct ccu_mux_nb sun8i_r40_cpu_nb = {
.bypass_index = 1, /* index of 24 MHz oscillator */
};
-static void __init sun8i_r40_ccu_setup(struct device_node *node)
+static int sun8i_r40_ccu_probe(struct platform_device *pdev)
{
+ struct resource *res;
void __iomem *reg;
u32 val;
+ int ret;
- reg = of_io_request_and_map(node, 0, of_node_full_name(node));
- if (IS_ERR(reg)) {
- pr_err("%s: Could not map the clock registers\n",
- of_node_full_name(node));
- return;
- }
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ reg = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(reg))
+ return PTR_ERR(reg);
/* Force the PLL-Audio-1x divider to 4 */
val = readl(reg + SUN8I_R40_PLL_AUDIO_REG);
@@ -1277,7 +1278,9 @@ static void __init sun8i_r40_ccu_setup(struct device_node *node)
val &= ~GENMASK(25, 20);
writel(val, reg + SUN8I_R40_USB_CLK_REG);
- sunxi_ccu_probe(node, reg, &sun8i_r40_ccu_desc);
+ ret = sunxi_ccu_probe(pdev->dev.of_node, reg, &sun8i_r40_ccu_desc);
+ if (ret)
+ return ret;
/* Gate then ungate PLL CPU after any rate changes */
ccu_pll_notifier_register(&sun8i_r40_pll_cpu_nb);
@@ -1285,6 +1288,20 @@ static void __init sun8i_r40_ccu_setup(struct device_node *node)
/* Reparent CPU during PLL CPU rate changes */
ccu_mux_notifier_register(pll_cpu_clk.common.hw.clk,
&sun8i_r40_cpu_nb);
+
+ return 0;
}
-CLK_OF_DECLARE(sun8i_r40_ccu, "allwinner,sun8i-r40-ccu",
- sun8i_r40_ccu_setup);
+
+static const struct of_device_id sun8i_r40_ccu_ids[] = {
+ { .compatible = "allwinner,sun8i-r40-ccu" },
+ { }
+};
+
+static struct platform_driver sun8i_r40_ccu_driver = {
+ .probe = sun8i_r40_ccu_probe,
+ .driver = {
+ .name = "sun8i-r40-ccu",
+ .of_match_table = sun8i_r40_ccu_ids,
+ },
+};
+builtin_platform_driver(sun8i_r40_ccu_driver);
--
2.16.2
^ permalink raw reply related
* [PATCH net-next 02/12] clk: sunxi-ng: r40: export a regmap to access the GMAC register
From: Chen-Yu Tsai @ 2018-03-17 9:28 UTC (permalink / raw)
To: Maxime Ripard, Michael Turquette, Stephen Boyd,
Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
Cc: devicetree, netdev, Chen-Yu Tsai, Corentin Labbe, linux-clk,
linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20180317092857.4396-1-wens@csie.org>
From: Icenowy Zheng <icenowy@aosc.io>
There's a GMAC configuration register, which exists on A64/A83T/H3/H5 in
the syscon part, in the CCU of R40 SoC.
Export a regmap of the CCU.
Read access is not restricted to all registers, but only the GMAC
register is allowed to be written.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
index c3aa839a453d..54c7a6106206 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
@@ -1251,9 +1251,35 @@ static struct ccu_mux_nb sun8i_r40_cpu_nb = {
.bypass_index = 1, /* index of 24 MHz oscillator */
};
+/*
+ * Add a regmap for the GMAC driver (dwmac-sun8i) to access the
+ * GMAC configuration register.
+ * Only this register is allowed to be written, in order to
+ * prevent overriding critical clock configuration.
+ */
+
+#define SUN8I_R40_GMAC_CFG_REG 0x164
+static bool sun8i_r40_ccu_regmap_writeable_reg(struct device *dev,
+ unsigned int reg)
+{
+ if (reg == SUN8I_R40_GMAC_CFG_REG)
+ return true;
+ return false;
+}
+
+static struct regmap_config sun8i_r40_ccu_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = 0x320, /* PLL_LOCK_CTRL_REG */
+
+ .writeable_reg = sun8i_r40_ccu_regmap_writeable_reg,
+};
+
static int sun8i_r40_ccu_probe(struct platform_device *pdev)
{
struct resource *res;
+ struct regmap *regmap;
void __iomem *reg;
u32 val;
int ret;
@@ -1278,6 +1304,11 @@ static int sun8i_r40_ccu_probe(struct platform_device *pdev)
val &= ~GENMASK(25, 20);
writel(val, reg + SUN8I_R40_USB_CLK_REG);
+ regmap = devm_regmap_init_mmio(&pdev->dev, reg,
+ &sun8i_r40_ccu_regmap_config);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
ret = sunxi_ccu_probe(pdev->dev.of_node, reg, &sun8i_r40_ccu_desc);
if (ret)
return ret;
--
2.16.2
^ permalink raw reply related
* [PATCH net-next 03/12] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Chen-Yu Tsai @ 2018-03-17 9:28 UTC (permalink / raw)
To: Maxime Ripard, Michael Turquette, Stephen Boyd,
Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
Cc: devicetree, netdev, Chen-Yu Tsai, Corentin Labbe, linux-clk,
linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20180317092857.4396-1-wens@csie.org>
The clock delay chains found in the glue layer for dwmac-sun8i are only
used with RGMII PHYs. They are not intended for non-RGMII PHYs, such as
MII external PHYs or the internal PHY. Also, a recent SoC has a smaller
range of possible values for the delay chain.
This patch reformats the delay chain section of the device tree binding
to make it clear that the delay chains only apply to RGMII PHYs, and
make it easier to add the R40-specific bits later.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
index 3d6d5fa0c4d5..b8a3028d6c30 100644
--- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -28,10 +28,13 @@ Required properties:
- allwinner,sun8i-a83t-system-controller
Optional properties:
-- allwinner,tx-delay-ps: TX clock delay chain value in ps. Range value is 0-700. Default is 0)
-- allwinner,rx-delay-ps: RX clock delay chain value in ps. Range value is 0-3100. Default is 0)
-Both delay properties need to be a multiple of 100. They control the delay for
-external PHY.
+- allwinner,tx-delay-ps: TX clock delay chain value in ps.
+ Range is 0-700. Default is 0.
+- allwinner,rx-delay-ps: RX clock delay chain value in ps.
+ Range is 0-3100. Default is 0.
+Both delay properties need to be a multiple of 100. They control the
+clock delay for external RGMII PHY. They are do apply to the internal
+PHY or external non-RGMII PHYs.
Optional properties for the following compatibles:
- "allwinner,sun8i-h3-emac",
--
2.16.2
^ permalink raw reply related
* [PATCH net-next 04/12] dt-bindings: net: dwmac-sun8i: Sort syscon compatibles by alphabetical order
From: Chen-Yu Tsai @ 2018-03-17 9:28 UTC (permalink / raw)
To: Maxime Ripard, Michael Turquette, Stephen Boyd,
Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
Cc: devicetree, netdev, Chen-Yu Tsai, Corentin Labbe, linux-clk,
linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20180317092857.4396-1-wens@csie.org>
The A83T syscon compatible was appended to the syscon compatibles list,
instead of inserted in to preserve the ordering.
Move it to the proper place to keep the list sorted.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
index b8a3028d6c30..74b3ef79e57a 100644
--- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -22,10 +22,10 @@ Required properties:
- #size-cells: shall be 0
- syscon: A phandle to the syscon of the SoC with one of the following
compatible string:
+ - allwinner,sun8i-a83t-system-controller
- allwinner,sun8i-h3-system-controller
- allwinner,sun8i-v3s-system-controller
- allwinner,sun50i-a64-system-controller
- - allwinner,sun8i-a83t-system-controller
Optional properties:
- allwinner,tx-delay-ps: TX clock delay chain value in ps.
--
2.16.2
^ permalink raw reply related
* [PATCH net-next 05/12] dt-bindings: net: dwmac-sun8i: Add binding for GMAC on Allwinner R40 SoC
From: Chen-Yu Tsai @ 2018-03-17 9:28 UTC (permalink / raw)
To: Maxime Ripard, Michael Turquette, Stephen Boyd,
Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
Cc: devicetree, netdev, Chen-Yu Tsai, Corentin Labbe, linux-clk,
linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20180317092857.4396-1-wens@csie.org>
The Allwinner R40 SoC has the EMAC controller supported by dwmac-sun8i.
It is named "GMAC", while EMAC refers to the 10/100 Mbps Ethernet
controller supported by sun4i-emac. The controller is the same, but
the R40 has the glue layer controls in the clock control unit (CCU),
with a reduced RX delay chain, and no TX delay chain.
This patch adds the R40 specific bits to the dwmac-sun8i binding.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
index 74b3ef79e57a..fe4a48a1eb50 100644
--- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -7,6 +7,7 @@ Required properties:
- compatible: must be one of the following string:
"allwinner,sun8i-a83t-emac"
"allwinner,sun8i-h3-emac"
+ "allwinner,sun8i-r40-gmac"
"allwinner,sun8i-v3s-emac"
"allwinner,sun50i-a64-emac"
- reg: address and length of the register for the device.
@@ -24,14 +25,17 @@ Required properties:
compatible string:
- allwinner,sun8i-a83t-system-controller
- allwinner,sun8i-h3-system-controller
+ - allwinner,sun8i-r40-ccu
- allwinner,sun8i-v3s-system-controller
- allwinner,sun50i-a64-system-controller
Optional properties:
- allwinner,tx-delay-ps: TX clock delay chain value in ps.
Range is 0-700. Default is 0.
+ Unavailable for allwinner,sun8i-r40-gmac
- allwinner,rx-delay-ps: RX clock delay chain value in ps.
Range is 0-3100. Default is 0.
+ Range is 0-700 for allwinner,sun8i-r40-gmac
Both delay properties need to be a multiple of 100. They control the
clock delay for external RGMII PHY. They are do apply to the internal
PHY or external non-RGMII PHYs.
--
2.16.2
^ permalink raw reply related
* [PATCH net-next 06/12] net: stmmac: dwmac-sun8i: Use regmap_field for syscon register access
From: Chen-Yu Tsai @ 2018-03-17 9:28 UTC (permalink / raw)
To: Maxime Ripard, Michael Turquette, Stephen Boyd,
Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
Cc: devicetree, netdev, Chen-Yu Tsai, Corentin Labbe, linux-clk,
linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20180317092857.4396-1-wens@csie.org>
On the Allwinner R40, the "GMAC clock" register is located in the CCU
block, at a different register address than the other SoCs that have
it in the "system control" block.
This patch converts the use of regmap to regmap_field for mapping and
accessing the syscon register, so we can have the register address in
the variants data, and not in the actual register manipulation code.
This patch only converts regmap_read() and regmap_write() calls to
regmap_field_read() and regmap_field_write() calls. There are some
places where it might make sense to switch to regmap_field_update_bits(),
but this is not done here to keep the patch simple.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 42 +++++++++++++++++------
1 file changed, 31 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index a3fa65b1ca8e..de93f0faf58d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -42,6 +42,7 @@
* This value is used for disabling properly EMAC
* and used as a good starting value in case of the
* boot process(uboot) leave some stuff.
+ * @syscon_field reg_field for the syscon's gmac register
* @soc_has_internal_phy: Does the MAC embed an internal PHY
* @support_mii: Does the MAC handle MII
* @support_rmii: Does the MAC handle RMII
@@ -49,6 +50,7 @@
*/
struct emac_variant {
u32 default_syscon_value;
+ const struct reg_field *syscon_field;
bool soc_has_internal_phy;
bool support_mii;
bool support_rmii;
@@ -71,13 +73,21 @@ struct sunxi_priv_data {
struct regulator *regulator;
struct reset_control *rst_ephy;
const struct emac_variant *variant;
- struct regmap *regmap;
+ struct regmap_field *regmap_field;
bool internal_phy_powered;
void *mux_handle;
};
+/* EMAC clock register @ 0x30 in the "system control" address range */
+const struct reg_field sun8i_syscon_reg_field = {
+ .reg = 0x30,
+ .lsb = 0,
+ .msb = 31,
+};
+
static const struct emac_variant emac_variant_h3 = {
.default_syscon_value = 0x58000,
+ .syscon_field = &sun8i_syscon_reg_field,
.soc_has_internal_phy = true,
.support_mii = true,
.support_rmii = true,
@@ -86,12 +96,14 @@ static const struct emac_variant emac_variant_h3 = {
static const struct emac_variant emac_variant_v3s = {
.default_syscon_value = 0x38000,
+ .syscon_field = &sun8i_syscon_reg_field,
.soc_has_internal_phy = true,
.support_mii = true
};
static const struct emac_variant emac_variant_a83t = {
.default_syscon_value = 0,
+ .syscon_field = &sun8i_syscon_reg_field,
.soc_has_internal_phy = false,
.support_mii = true,
.support_rgmii = true
@@ -99,6 +111,7 @@ static const struct emac_variant emac_variant_a83t = {
static const struct emac_variant emac_variant_a64 = {
.default_syscon_value = 0,
+ .syscon_field = &sun8i_syscon_reg_field,
.soc_has_internal_phy = false,
.support_mii = true,
.support_rmii = true,
@@ -216,7 +229,6 @@ static const struct emac_variant emac_variant_a64 = {
#define SYSCON_ETCS_MII 0x0
#define SYSCON_ETCS_EXT_GMII 0x1
#define SYSCON_ETCS_INT_GMII 0x2
-#define SYSCON_EMAC_REG 0x30
/* sun8i_dwmac_dma_reset() - reset the EMAC
* Called from stmmac via stmmac_dma_ops->reset
@@ -745,7 +757,7 @@ static int mdio_mux_syscon_switch_fn(int current_child, int desired_child,
bool need_power_ephy = false;
if (current_child ^ desired_child) {
- regmap_read(gmac->regmap, SYSCON_EMAC_REG, ®);
+ regmap_field_read(gmac->regmap_field, ®);
switch (desired_child) {
case DWMAC_SUN8I_MDIO_MUX_INTERNAL_ID:
dev_info(priv->device, "Switch mux to internal PHY");
@@ -763,7 +775,7 @@ static int mdio_mux_syscon_switch_fn(int current_child, int desired_child,
desired_child);
return -EINVAL;
}
- regmap_write(gmac->regmap, SYSCON_EMAC_REG, val);
+ regmap_field_write(gmac->regmap_field, val);
if (need_power_ephy) {
ret = sun8i_dwmac_power_internal_phy(priv);
if (ret)
@@ -801,7 +813,7 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
int ret;
u32 reg, val;
- regmap_read(gmac->regmap, SYSCON_EMAC_REG, &val);
+ regmap_field_read(gmac->regmap_field, &val);
reg = gmac->variant->default_syscon_value;
if (reg != val)
dev_warn(priv->device,
@@ -883,7 +895,7 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
return -EINVAL;
}
- regmap_write(gmac->regmap, SYSCON_EMAC_REG, reg);
+ regmap_field_write(gmac->regmap_field, reg);
return 0;
}
@@ -892,7 +904,7 @@ static void sun8i_dwmac_unset_syscon(struct sunxi_priv_data *gmac)
{
u32 reg = gmac->variant->default_syscon_value;
- regmap_write(gmac->regmap, SYSCON_EMAC_REG, reg);
+ regmap_field_write(gmac->regmap_field, reg);
}
static void sun8i_dwmac_exit(struct platform_device *pdev, void *priv)
@@ -980,6 +992,7 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
int ret;
struct stmmac_priv *priv;
struct net_device *ndev;
+ struct regmap *regmap;
ret = stmmac_get_platform_resources(pdev, &stmmac_res);
if (ret)
@@ -1014,14 +1027,21 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
gmac->regulator = NULL;
}
- gmac->regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
- "syscon");
- if (IS_ERR(gmac->regmap)) {
- ret = PTR_ERR(gmac->regmap);
+ regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node, "syscon");
+ if (IS_ERR(regmap)) {
+ ret = PTR_ERR(regmap);
dev_err(&pdev->dev, "Unable to map syscon: %d\n", ret);
return ret;
}
+ gmac->regmap_field = devm_regmap_field_alloc(dev, regmap,
+ *gmac->variant->syscon_field);
+ if (IS_ERR(gmac->regmap_field)) {
+ ret = PTR_ERR(gmac->regmap_field);
+ dev_err(dev, "Unable to map syscon register: %d\n", ret);
+ return ret;
+ }
+
plat_dat->interface = of_get_phy_mode(dev->of_node);
/* platform data specifying hardware features and callbacks.
--
2.16.2
^ permalink raw reply related
* [PATCH net-next 07/12] net: stmmac: dwmac-sun8i: Allow getting syscon regmap from CCU device
From: Chen-Yu Tsai @ 2018-03-17 9:28 UTC (permalink / raw)
To: Maxime Ripard, Michael Turquette, Stephen Boyd,
Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
Cc: devicetree, netdev, Chen-Yu Tsai, Corentin Labbe, linux-clk,
linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20180317092857.4396-1-wens@csie.org>
On the Allwinner R40 SoC, the "GMAC clock" register is in the CCU
address space. Using a standard syscon to access it provides no
coordination with the CCU driver for register access. Neither does
it prevent this and other drivers from accessing other, maybe critical,
clock control registers.
Instead, for these types of setups, we let the CCU register a proper
device and a regmap tied to it. We can then get the device from the
phandle, and retrieve the regmap with dev_get_regmap().
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 38 ++++++++++++++++++++++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index de93f0faf58d..a51175bcfd11 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -43,6 +43,9 @@
* and used as a good starting value in case of the
* boot process(uboot) leave some stuff.
* @syscon_field reg_field for the syscon's gmac register
+ * @syscon_from_dev syscon regmap is in ccu address space and
+ * needs to be retrieved using dev_get_regmap()
+ * instead of syscon_regmap_lookup_by_phandle()
* @soc_has_internal_phy: Does the MAC embed an internal PHY
* @support_mii: Does the MAC handle MII
* @support_rmii: Does the MAC handle RMII
@@ -51,6 +54,7 @@
struct emac_variant {
u32 default_syscon_value;
const struct reg_field *syscon_field;
+ bool syscon_from_dev;
bool soc_has_internal_phy;
bool support_mii;
bool support_rmii;
@@ -983,6 +987,34 @@ static struct mac_device_info *sun8i_dwmac_setup(void *ppriv)
return mac;
}
+static struct regmap *sun8i_dwmac_get_syscon_from_dev(struct device_node *node)
+{
+ struct device_node *syscon_node;
+ struct platform_device *syscon_pdev;
+ struct regmap *regmap = NULL;
+
+ syscon_node = of_parse_phandle(node, "syscon", 0);
+ if (!syscon_node)
+ return ERR_PTR(-ENODEV);
+
+ syscon_pdev = of_find_device_by_node(syscon_node);
+ if (!syscon_pdev) {
+ /* platform device might not be probed yet */
+ regmap = ERR_PTR(-EPROBE_DEFER);
+ goto out_put_node;
+ }
+
+ /* If no regmap is found then the other device driver is at fault */
+ regmap = dev_get_regmap(&syscon_pdev->dev, NULL);
+ if (!regmap)
+ regmap = ERR_PTR(-EINVAL);
+
+ platform_device_put(syscon_pdev);
+out_put_node:
+ of_node_put(syscon_node);
+ return regmap;
+}
+
static int sun8i_dwmac_probe(struct platform_device *pdev)
{
struct plat_stmmacenet_data *plat_dat;
@@ -1027,7 +1059,11 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
gmac->regulator = NULL;
}
- regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node, "syscon");
+ if (gmac->variant->syscon_from_dev)
+ regmap = sun8i_dwmac_get_syscon_from_dev(pdev->dev.of_node);
+ else
+ regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
+ "syscon");
if (IS_ERR(regmap)) {
ret = PTR_ERR(regmap);
dev_err(&pdev->dev, "Unable to map syscon: %d\n", ret);
--
2.16.2
^ permalink raw reply related
* [PATCH net-next 08/12] net: stmmac: dwmac-sun8i: Support different ranges for TX/RX delay chains
From: Chen-Yu Tsai @ 2018-03-17 9:28 UTC (permalink / raw)
To: Maxime Ripard, Michael Turquette, Stephen Boyd,
Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
Cc: devicetree, netdev, Chen-Yu Tsai, Corentin Labbe, linux-clk,
linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20180317092857.4396-1-wens@csie.org>
On the R40 SoC, the RX delay chain only has a range of 0~7 (hundred
picoseconds), instead of 0~31. Also the TX delay chain is completely
absent.
This patch adds support for different ranges by adding per-compatible
maximum values in the variant data. A maximum of 0 indicates that the
delay chain is not supported or absent.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 32 ++++++++++++++++-------
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index a51175bcfd11..08d263567a52 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -50,6 +50,12 @@
* @support_mii: Does the MAC handle MII
* @support_rmii: Does the MAC handle RMII
* @support_rgmii: Does the MAC handle RGMII
+ *
+ * @rx_delay_max: Maximum raw value for RX delay chain
+ * @tx_delay_max: Maximum raw value for TX delay chain
+ * These two also indicate the bitmask for
+ * the RX and TX delay chain registers. A
+ * value of zero indicates this is not supported.
*/
struct emac_variant {
u32 default_syscon_value;
@@ -59,6 +65,8 @@ struct emac_variant {
bool support_mii;
bool support_rmii;
bool support_rgmii;
+ u8 rx_delay_max;
+ u8 tx_delay_max;
};
/* struct sunxi_priv_data - hold all sunxi private data
@@ -95,7 +103,9 @@ static const struct emac_variant emac_variant_h3 = {
.soc_has_internal_phy = true,
.support_mii = true,
.support_rmii = true,
- .support_rgmii = true
+ .support_rgmii = true,
+ .rx_delay_max = 31,
+ .tx_delay_max = 7,
};
static const struct emac_variant emac_variant_v3s = {
@@ -110,7 +120,9 @@ static const struct emac_variant emac_variant_a83t = {
.syscon_field = &sun8i_syscon_reg_field,
.soc_has_internal_phy = false,
.support_mii = true,
- .support_rgmii = true
+ .support_rgmii = true,
+ .rx_delay_max = 31,
+ .tx_delay_max = 7,
};
static const struct emac_variant emac_variant_a64 = {
@@ -119,7 +131,9 @@ static const struct emac_variant emac_variant_a64 = {
.soc_has_internal_phy = false,
.support_mii = true,
.support_rmii = true,
- .support_rgmii = true
+ .support_rgmii = true,
+ .rx_delay_max = 31,
+ .tx_delay_max = 7,
};
#define EMAC_BASIC_CTL0 0x00
@@ -223,9 +237,7 @@ static const struct emac_variant emac_variant_a64 = {
#define SYSCON_RMII_EN BIT(13) /* 1: enable RMII (overrides EPIT) */
/* Generic system control EMAC_CLK bits */
-#define SYSCON_ETXDC_MASK GENMASK(2, 0)
#define SYSCON_ETXDC_SHIFT 10
-#define SYSCON_ERXDC_MASK GENMASK(4, 0)
#define SYSCON_ERXDC_SHIFT 5
/* EMAC PHY Interface Type */
#define SYSCON_EPIT BIT(2) /* 1: RGMII, 0: MII */
@@ -851,8 +863,9 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
}
val /= 100;
dev_dbg(priv->device, "set tx-delay to %x\n", val);
- if (val <= SYSCON_ETXDC_MASK) {
- reg &= ~(SYSCON_ETXDC_MASK << SYSCON_ETXDC_SHIFT);
+ if (val <= gmac->variant->tx_delay_max) {
+ reg &= ~(gmac->variant->tx_delay_max <<
+ SYSCON_ETXDC_SHIFT);
reg |= (val << SYSCON_ETXDC_SHIFT);
} else {
dev_err(priv->device, "Invalid TX clock delay: %d\n",
@@ -868,8 +881,9 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
}
val /= 100;
dev_dbg(priv->device, "set rx-delay to %x\n", val);
- if (val <= SYSCON_ERXDC_MASK) {
- reg &= ~(SYSCON_ERXDC_MASK << SYSCON_ERXDC_SHIFT);
+ if (val <= gmac->variant->rx_delay_max) {
+ reg &= ~(gmac->variant->rx_delay_max <<
+ SYSCON_ERXDC_SHIFT);
reg |= (val << SYSCON_ERXDC_SHIFT);
} else {
dev_err(priv->device, "Invalid RX clock delay: %d\n",
--
2.16.2
^ permalink raw reply related
* [PATCH net-next 09/12] net: stmmac: dwmac-sun8i: Add support for GMAC on Allwinner R40 SoC
From: Chen-Yu Tsai @ 2018-03-17 9:28 UTC (permalink / raw)
To: Maxime Ripard, Michael Turquette, Stephen Boyd,
Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
Cc: devicetree, netdev, Chen-Yu Tsai, Corentin Labbe, linux-clk,
linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20180317092857.4396-1-wens@csie.org>
The Allwinner R40 SoC has the EMAC controller supported by dwmac-sun8i.
It is named "GMAC", while EMAC refers to the 10/100 Mbps Ethernet
controller supported by sun4i-emac. The controller is the same, but
the R40 has the glue layer controls in the clock control unit (CCU),
with a reduced RX delay chain, and no TX delay chain.
This patch adds support for it using the framework laid out by previous
patches to map the differences.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 08d263567a52..be6705e89e95 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -97,6 +97,13 @@ const struct reg_field sun8i_syscon_reg_field = {
.msb = 31,
};
+/* EMAC clock register @ 0x164 in the CCU address range */
+const struct reg_field sun8i_ccu_reg_field = {
+ .reg = 0x164,
+ .lsb = 0,
+ .msb = 31,
+};
+
static const struct emac_variant emac_variant_h3 = {
.default_syscon_value = 0x58000,
.syscon_field = &sun8i_syscon_reg_field,
@@ -125,6 +132,15 @@ static const struct emac_variant emac_variant_a83t = {
.tx_delay_max = 7,
};
+static const struct emac_variant emac_variant_r40 = {
+ .default_syscon_value = 0,
+ .syscon_field = &sun8i_ccu_reg_field,
+ .syscon_from_dev = true,
+ .support_mii = true,
+ .support_rgmii = true,
+ .rx_delay_max = 7,
+};
+
static const struct emac_variant emac_variant_a64 = {
.default_syscon_value = 0,
.syscon_field = &sun8i_syscon_reg_field,
@@ -1148,6 +1164,8 @@ static const struct of_device_id sun8i_dwmac_match[] = {
.data = &emac_variant_v3s },
{ .compatible = "allwinner,sun8i-a83t-emac",
.data = &emac_variant_a83t },
+ { .compatible = "allwinner,sun8i-r40-gmac",
+ .data = &emac_variant_r40 },
{ .compatible = "allwinner,sun50i-a64-emac",
.data = &emac_variant_a64 },
{ }
--
2.16.2
^ permalink raw reply related
* [PATCH net-next 10/12] ARM: dts: sun8i: r40: bananapi-m2-ultra: Sort device node dereferences
From: Chen-Yu Tsai @ 2018-03-17 9:28 UTC (permalink / raw)
To: Maxime Ripard, Michael Turquette, Stephen Boyd,
Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
Cc: devicetree, netdev, Chen-Yu Tsai, Corentin Labbe, linux-clk,
linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20180317092857.4396-1-wens@csie.org>
The device nodes dereference (&foo) usages should be sorted by the label
names, barring any parsing order issues such as the #include statement
for the PMIC's .dtsi file that must come after the PMIC.
Move the mmc and ohci blocks in front of the PMIC's regulator blocks.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 69 ++++++++++++-----------
1 file changed, 35 insertions(+), 34 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
index 27d9ccd0ef2f..c6da21e43572 100644
--- a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
+++ b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
@@ -114,6 +114,41 @@
#include "axp22x.dtsi"
+&mmc0 {
+ vmmc-supply = <®_dcdc1>;
+ bus-width = <4>;
+ cd-gpios = <&pio 7 13 GPIO_ACTIVE_HIGH>; /* PH13 */
+ cd-inverted;
+ status = "okay";
+};
+
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pg_pins>;
+ vmmc-supply = <®_dldo2>;
+ vqmmc-supply = <®_dldo1>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ bus-width = <4>;
+ non-removable;
+ status = "okay";
+};
+
+&mmc2 {
+ vmmc-supply = <®_dcdc1>;
+ vqmmc-supply = <®_dcdc1>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&ohci2 {
+ status = "okay";
+};
+
®_aldo3 {
regulator-always-on;
regulator-min-microvolt = <2700000>;
@@ -161,40 +196,6 @@
regulator-name = "vcc-wifi";
};
-&mmc0 {
- vmmc-supply = <®_dcdc1>;
- bus-width = <4>;
- cd-gpios = <&pio 7 13 GPIO_ACTIVE_LOW>; /* PH13 */
- status = "okay";
-};
-
-&mmc1 {
- pinctrl-names = "default";
- pinctrl-0 = <&mmc1_pg_pins>;
- vmmc-supply = <®_dldo2>;
- vqmmc-supply = <®_dldo1>;
- mmc-pwrseq = <&wifi_pwrseq>;
- bus-width = <4>;
- non-removable;
- status = "okay";
-};
-
-&mmc2 {
- vmmc-supply = <®_dcdc1>;
- vqmmc-supply = <®_dcdc1>;
- bus-width = <8>;
- non-removable;
- status = "okay";
-};
-
-&ohci1 {
- status = "okay";
-};
-
-&ohci2 {
- status = "okay";
-};
-
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.16.2
^ permalink raw reply related
* [PATCH net-next 11/12] ARM: dts: sun8i: r40: Add device node and RGMII pinmux node for GMAC
From: Chen-Yu Tsai @ 2018-03-17 9:28 UTC (permalink / raw)
To: Maxime Ripard, Michael Turquette, Stephen Boyd,
Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
Cc: devicetree, netdev, Chen-Yu Tsai, Corentin Labbe, linux-clk,
linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20180317092857.4396-1-wens@csie.org>
The R40 SoC has a GMAC (gigabit capable Ethernet controller). Add a
device node for it. The only publicly available board for this SoC
uses an RGMII PHY. Add a pinmux node for it as well.
Since this SoC also has an old 10/100 Mbps EMAC, which also has an
MDIO bus controller, the MDIO bus for the GMAC is labeled "gmac_mdio".
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun8i-r40.dtsi | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
index 173dcc1652d2..bd97ca3dc2fa 100644
--- a/arch/arm/boot/dts/sun8i-r40.dtsi
+++ b/arch/arm/boot/dts/sun8i-r40.dtsi
@@ -265,6 +265,19 @@
#interrupt-cells = <3>;
#gpio-cells = <3>;
+ gmac_rgmii_pins: gmac-rgmii-pins {
+ pins = "PA0", "PA1", "PA2", "PA3",
+ "PA4", "PA5", "PA6", "PA7",
+ "PA8", "PA10", "PA11", "PA12",
+ "PA13", "PA15", "PA16";
+ function = "gmac";
+ /*
+ * data lines in RGMII mode use DDR mode
+ * and need a higher signal drive strength
+ */
+ drive-strength = <40>;
+ };
+
i2c0_pins: i2c0-pins {
pins = "PB0", "PB1";
function = "i2c0";
@@ -451,6 +464,27 @@
#size-cells = <0>;
};
+ gmac: ethernet@1c50000 {
+ compatible = "allwinner,sun8i-r40-gmac";
+ syscon = <&ccu>;
+ reg = <0x01c50000 0x10000>;
+ interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ resets = <&ccu RST_BUS_GMAC>;
+ reset-names = "stmmaceth";
+ clocks = <&ccu CLK_BUS_GMAC>;
+ clock-names = "stmmaceth";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ gmac_mdio: mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
gic: interrupt-controller@1c81000 {
compatible = "arm,gic-400";
reg = <0x01c81000 0x1000>,
--
2.16.2
^ permalink raw reply related
* [PATCH net-next 12/12] ARM: dts: sun8i: r40: bananapi-m2-ultra: Enable GMAC ethernet controller
From: Chen-Yu Tsai @ 2018-03-17 9:28 UTC (permalink / raw)
To: Maxime Ripard, Michael Turquette, Stephen Boyd,
Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
Cc: devicetree, netdev, Chen-Yu Tsai, Corentin Labbe, linux-clk,
linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20180317092857.4396-1-wens@csie.org>
The Bananapi M2 Ultra has a Realtek RTL8211E RGMII PHY tied to the GMAC.
The PMIC's DC1SW output provides power for the PHY, while the ALDO2
output provides I/O voltages on both sides.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 30 +++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
index c6da21e43572..25fb048c7df2 100644
--- a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
+++ b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
@@ -51,6 +51,7 @@
compatible = "sinovoip,bpi-m2-ultra", "allwinner,sun8i-r40";
aliases {
+ ethernet0 = &gmac;
serial0 = &uart0;
};
@@ -101,6 +102,22 @@
status = "okay";
};
+&gmac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac_rgmii_pins>;
+ phy-handle = <&phy1>;
+ phy-mode = "rgmii";
+ phy-supply = <®_dc1sw>;
+ status = "okay";
+};
+
+&gmac_mdio {
+ phy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+};
+
&i2c0 {
status = "okay";
@@ -149,6 +166,13 @@
status = "okay";
};
+®_aldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ regulator-name = "vcc-pa";
+};
+
®_aldo3 {
regulator-always-on;
regulator-min-microvolt = <2700000>;
@@ -156,6 +180,12 @@
regulator-name = "avcc";
};
+®_dc1sw {
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "vcc-gmac-phy";
+};
+
®_dcdc1 {
regulator-always-on;
regulator-min-microvolt = <3000000>;
--
2.16.2
^ permalink raw reply related
* Ask for help about flow classifier tool
From: Wei Hu (Xavier) @ 2018-03-17 9:47 UTC (permalink / raw)
To: netdev, David Miller
Cc: linyunsheng, lipeng (Y), 00434615 >> shenjian 00434615,
liangfuyun (A), Chenxin (Charles),
shen >> 00434615 >> shenjian 00434615
Hi, David
The TC Flower Classifier allows control of packets based on flows
determined by matching of well-known packet fields and metadata.
Offload of the TC Flower classifier and related modules provides a
powerful mechanism to both increase throughput and reduce CPU
utilisation for users of such flow-based systems.
The command "ethtool -N" can provide similar function.
Now, hip08 SOC has flow classifier hardware offload capacity, which
tools we should support in HNS kernel driver?
Can you give some suggestion?
Regards
Wei Hu
^ permalink raw reply
* Re: [PATCH net-next 4/5] net: Make ip_ra_chain per struct net
From: Kirill Tkhai @ 2018-03-17 10:21 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, davem, yoshfuji, edumazet, yanhaishuang, nikolay,
yotamg, soheil, avagin, nicolas.dichtel, ebiederm, fw, roman.kapl,
netdev, xiyou.wangcong, dvyukov, andreyknvl
In-Reply-To: <201803170753.rO48WL2s%fengguang.wu@intel.com>
Hi,
On 17.03.2018 02:22, kbuild test robot wrote:
> Hi Kirill,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on v4.16-rc4]
> [also build test WARNING on next-20180316]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Kirill-Tkhai/Rework-ip_ra_chain-protection/20180317-032841
> reproduce:
> # apt-get install sparse
> make ARCH=x86_64 allmodconfig
> make C=1 CF=-D__CHECK_ENDIAN__
>
>
> sparse warnings: (new ones prefixed by >>)
>
>>> net/ipv4/ip_input.c:162:19: sparse: incompatible types in comparison expression (different address spaces)
thanks for reporting this! Forgot to add __rcu modifier to member type.
I'll send v2 version.
Kirill
> --
>>> net/ipv4/ip_sockglue.c:347:18: sparse: incorrect type in assignment (different address spaces) @@ expected struct ip_ra_chain [noderef] <asn:4>**rap @@ got n [noderef] <asn:4>**rap @@
> net/ipv4/ip_sockglue.c:347:18: expected struct ip_ra_chain [noderef] <asn:4>**rap
> net/ipv4/ip_sockglue.c:347:18: got struct ip_ra_chain **<noident>
>
> vim +162 net/ipv4/ip_input.c
>
> 150
> 151 /*
> 152 * Process Router Attention IP option (RFC 2113)
> 153 */
> 154 bool ip_call_ra_chain(struct sk_buff *skb)
> 155 {
> 156 struct ip_ra_chain *ra;
> 157 u8 protocol = ip_hdr(skb)->protocol;
> 158 struct sock *last = NULL;
> 159 struct net_device *dev = skb->dev;
> 160 struct net *net = dev_net(dev);
> 161
> > 162 for (ra = rcu_dereference(net->ipv4.ra_chain); ra; ra = rcu_dereference(ra->next)) {
> 163 struct sock *sk = ra->sk;
> 164
> 165 /* If socket is bound to an interface, only report
> 166 * the packet if it came from that interface.
> 167 */
> 168 if (sk && inet_sk(sk)->inet_num == protocol &&
> 169 (!sk->sk_bound_dev_if ||
> 170 sk->sk_bound_dev_if == dev->ifindex)) {
> 171 if (ip_is_fragment(ip_hdr(skb))) {
> 172 if (ip_defrag(net, skb, IP_DEFRAG_CALL_RA_CHAIN))
> 173 return true;
> 174 }
> 175 if (last) {
> 176 struct sk_buff *skb2 = skb_clone(skb, GFP_ATOMIC);
> 177 if (skb2)
> 178 raw_rcv(last, skb2);
> 179 }
> 180 last = sk;
> 181 }
> 182 }
> 183
> 184 if (last) {
> 185 raw_rcv(last, skb);
> 186 return true;
> 187 }
> 188 return false;
> 189 }
> 190
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
^ permalink raw reply
* Re: [PATCH v2] netns: send uevent messages
From: Christian Brauner @ 2018-03-17 10:29 UTC (permalink / raw)
To: David Miller
Cc: christian.brauner, ebiederm, gregkh, netdev, linux-kernel, serge,
avagin, ktkhai
In-Reply-To: <20180316.144145.1695554148709004295.davem@davemloft.net>
On Fri, Mar 16, 2018 at 02:41:45PM -0400, David Miller wrote:
> From: Christian Brauner <christian.brauner@ubuntu.com>
> Date: Fri, 16 Mar 2018 13:50:30 +0100
>
> > +static int uevent_net_broadcast(struct sock *usk, struct sk_buff *skb,
> > + struct netlink_ext_ack *extack)
> > +{
> > + int ret;
> > + /* u64 to chars: 2^64 - 1 = 21 chars */
> > + char buf[sizeof("SEQNUM=") + 21];
> > + struct sk_buff *skbc;
>
> I hate to be difficult, but please use reverse christmas tree ordering
> for local variables.
No problem David, coding style is important. I'm about to send out
another version with:
/* u64 to chars: 2^64 - 1 = 21 chars */
char buf[sizeof("SEQNUM=") + 21];
struct sk_buff *skbc;
int ret;
Thanks!
Christian
>
> > +static int uevent_net_rcv_skb(struct sk_buff *skb, struct nlmsghdr *nlh,
> > + struct netlink_ext_ack *extack)
> > +{
> > + int ret;
> > + struct net *net;
>
> Likewise.
>
> Thank you.
^ permalink raw reply
* Re: [PATCH v2] netns: send uevent messages
From: Christian Brauner @ 2018-03-17 10:31 UTC (permalink / raw)
To: Kirill Tkhai
Cc: Christian Brauner, ebiederm, gregkh, netdev, linux-kernel, serge,
avagin
In-Reply-To: <dd58d637-bb05-ff82-9471-b4163340d472@virtuozzo.com>
On Fri, Mar 16, 2018 at 11:14:31PM +0300, Kirill Tkhai wrote:
> On 16.03.2018 15:50, Christian Brauner wrote:
> > This patch adds a receive method to NETLINK_KOBJECT_UEVENT netlink sockets
> > to allow sending uevent messages into the network namespace the socket
> > belongs to.
> >
> > Currently non-initial network namespaces are already isolated and don't
> > receive uevents. There are a number of cases where it is beneficial for a
> > sufficiently privileged userspace process to send a uevent into a network
> > namespace.
> >
> > One such use case would be debugging and fuzzing of a piece of software
> > which listens and reacts to uevents. By running a copy of that software
> > inside a network namespace, specific uevents could then be presented to it.
> > More concretely, this would allow for easy testing of udevd/ueventd.
> >
> > This will also allow some piece of software to run components inside a
> > separate network namespace and then effectively filter what that software
> > can receive. Some examples of software that do directly listen to uevents
> > and that we have in the past attempted to run inside a network namespace
> > are rbd (CEPH client) or the X server.
> >
> > Implementation:
> > The implementation has been kept as simple as possible from the kernel's
> > perspective. Specifically, a simple input method uevent_net_rcv() is added
> > to NETLINK_KOBJECT_UEVENT sockets which completely reuses existing
> > af_netlink infrastructure and does neither add an additional netlink family
> > nor requires any user-visible changes.
> >
> > For example, by using netlink_rcv_skb() we can make use of existing netlink
> > infrastructure to report back informative error messages to userspace.
> >
> > Furthermore, this implementation does not introduce any overhead for
> > existing uevent generating codepaths. The struct netns gets a new uevent
> > socket member that records the uevent socket associated with that network
> > namespace including its position in the uevent socket list. Since we record
> > the uevent socket for each network namespace in struct net we don't have to
> > walk the whole uevent socket list. Instead we can directly retrieve the
> > relevant uevent socket and send the message. At exit time we can now also
> > trivially remove the uevent socket from the uevent socket list. This keeps
> > the codepath very performant without introducing needless overhead and even
> > makes older codepaths faster.
> >
> > Uevent sequence numbers are kept global. When a uevent message is sent to
> > another network namespace the implementation will simply increment the
> > global uevent sequence number and append it to the received uevent. This
> > has the advantage that the kernel will never need to parse the received
> > uevent message to replace any existing uevent sequence numbers. Instead it
> > is up to the userspace process to remove any existing uevent sequence
> > numbers in case the uevent message to be sent contains any.
> >
> > Security:
> > In order for a caller to send uevent messages to a target network namespace
> > the caller must have CAP_SYS_ADMIN in the owning user namespace of the
> > target network namespace. Additionally, any received uevent message is
> > verified to not exceed size UEVENT_BUFFER_SIZE. This includes the space
> > needed to append the uevent sequence number.
> >
> > Testing:
> > This patch has been tested and verified to work with the following udev
> > implementations:
> > 1. CentOS 6 with udevd version 147
> > 2. Debian Sid with systemd-udevd version 237
> > 3. Android 7.1.1 with ueventd
> >
> > Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
> > ---
> > Changelog v1->v2:
> > * Add the whole struct uevent_sock to struct net not just the socket
> > member. Since struct uevent_sock records the position of the uevent
> > socket in the uevent socket list we can trivially remove it from the
> > uevent socket list during cleanup. This speeds up the old removal
> > codepath. list_del() will hitl __list_del_entry_valid() in its call chain
> > which will validate that the element is a member of the list. If it isn't
> > it will take care that the list is not modified.
> > Changelog v0->v1:
> > * Hold mutex_lock() until uevent is sent to preserve uevent message
> > ordering. See udev and commit for reference:
> >
> > commit 7b60a18da393ed70db043a777fd9e6d5363077c4
> > Author: Andrew Vagin <avagin@openvz.org>
> > Date: Wed Mar 7 14:49:56 2012 +0400
> >
> > uevent: send events in correct order according to seqnum (v3)
> >
> > The queue handling in the udev daemon assumes that the events are
> > ordered.
> > ---
> > include/linux/kobject.h | 6 +++
> > include/net/net_namespace.h | 4 +-
> > lib/kobject_uevent.c | 98 ++++++++++++++++++++++++++++++++++++++-------
> > 3 files changed, 93 insertions(+), 15 deletions(-)
> >
> > diff --git a/include/linux/kobject.h b/include/linux/kobject.h
> > index 7f6f93c3df9c..c572c7abc609 100644
> > --- a/include/linux/kobject.h
> > +++ b/include/linux/kobject.h
> > @@ -39,6 +39,12 @@ extern char uevent_helper[];
> > /* counter to tag the uevent, read only except for the kobject core */
> > extern u64 uevent_seqnum;
> >
> > +/* uevent socket */
> > +struct uevent_sock {
> > + struct list_head list;
> > + struct sock *sk;
> > +};
>
> I missed, why we do this external?
Mostly because of transparency but I've kept it directly in
kobject_uevent.c in the new version for now.
>
> > +
> > /*
> > * The actions here must match the index to the string array
> > * in lib/kobject_uevent.c
> > diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
> > index f306b2aa15a4..abd7d91bffac 100644
> > --- a/include/net/net_namespace.h
> > +++ b/include/net/net_namespace.h
> > @@ -40,7 +40,7 @@ struct net_device;
> > struct sock;
> > struct ctl_table_header;
> > struct net_generic;
> > -struct sock;
> > +struct uevent_sock;
> > struct netns_ipvs;
> >
> >
> > @@ -79,6 +79,8 @@ struct net {
> > struct sock *rtnl; /* rtnetlink socket */
> > struct sock *genl_sock;
> >
> > + struct uevent_sock *uevent_sock; /* uevent socket */
>
> Since there will be one more version, could you please to move all preparation
> related to the above change to a separate patch? Then we have series of two patches
> with two logical changes.
Yes, I split adding struct uevent_sock to struct net and related
improvements in kobject_uevent.c into a separate patch in v3.
Thanks!
Christian
>
> > +
> > struct list_head dev_base_head;
> > struct hlist_head *dev_name_head;
> > struct hlist_head *dev_index_head;
> > diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
> > index 9fe6ec8fda28..53e9123474c0 100644
> > --- a/lib/kobject_uevent.c
> > +++ b/lib/kobject_uevent.c
> > @@ -25,6 +25,7 @@
> > #include <linux/uuid.h>
> > #include <linux/ctype.h>
> > #include <net/sock.h>
> > +#include <net/netlink.h>
> > #include <net/net_namespace.h>
> >
> >
> > @@ -33,10 +34,6 @@ u64 uevent_seqnum;
> > char uevent_helper[UEVENT_HELPER_PATH_LEN] = CONFIG_UEVENT_HELPER_PATH;
> > #endif
> > #ifdef CONFIG_NET
> > -struct uevent_sock {
> > - struct list_head list;
> > - struct sock *sk;
> > -};
> > static LIST_HEAD(uevent_sock_list);
> > #endif
> >
> > @@ -602,12 +599,88 @@ int add_uevent_var(struct kobj_uevent_env *env, const char *format, ...)
> > EXPORT_SYMBOL_GPL(add_uevent_var);
> >
> > #if defined(CONFIG_NET)
> > +static int uevent_net_broadcast(struct sock *usk, struct sk_buff *skb,
> > + struct netlink_ext_ack *extack)
> > +{
> > + int ret;
> > + /* u64 to chars: 2^64 - 1 = 21 chars */
> > + char buf[sizeof("SEQNUM=") + 21];
> > + struct sk_buff *skbc;
> > +
> > + /* bump and prepare sequence number */
> > + ret = snprintf(buf, sizeof(buf), "SEQNUM=%llu", ++uevent_seqnum);
> > + if (ret < 0 || (size_t)ret >= sizeof(buf))
> > + return -ENOMEM;
> > + ret++;
> > +
> > + /* verify message does not overflow */
> > + if ((skb->len + ret) > UEVENT_BUFFER_SIZE) {
> > + NL_SET_ERR_MSG(extack, "uevent message too big");
> > + return -EINVAL;
> > + }
> > +
> > + /* copy skb and extend to accommodate sequence number */
> > + skbc = skb_copy_expand(skb, 0, ret, GFP_KERNEL);
> > + if (!skbc)
> > + return -ENOMEM;
> > +
> > + /* append sequence number */
> > + skb_put_data(skbc, buf, ret);
> > +
> > + /* remove msg header */
> > + skb_pull(skbc, NLMSG_HDRLEN);
> > +
> > + /* set portid 0 to inform userspace message comes from kernel */
> > + NETLINK_CB(skbc).portid = 0;
> > + NETLINK_CB(skbc).dst_group = 1;
> > +
> > + ret = netlink_broadcast(usk, skbc, 0, 1, GFP_KERNEL);
> > + /* ENOBUFS should be handled in userspace */
> > + if (ret == -ENOBUFS || ret == -ESRCH)
> > + ret = 0;
> > +
> > + return ret;
> > +}
> > +
> > +static int uevent_net_rcv_skb(struct sk_buff *skb, struct nlmsghdr *nlh,
> > + struct netlink_ext_ack *extack)
> > +{
> > + int ret;
> > + struct net *net;
> > +
> > + if (!nlmsg_data(nlh))
> > + return -EINVAL;
> > +
> > + /*
> > + * Verify that we are allowed to send messages to the target
> > + * network namespace. The caller must have CAP_SYS_ADMIN in the
> > + * owning user namespace of the target network namespace.
> > + */
> > + net = sock_net(NETLINK_CB(skb).sk);
> > + if (!netlink_ns_capable(skb, net->user_ns, CAP_SYS_ADMIN)) {
> > + NL_SET_ERR_MSG(extack, "missing CAP_SYS_ADMIN capability");
> > + return -EPERM;
> > + }
> > +
> > + mutex_lock(&uevent_sock_mutex);
> > + ret = uevent_net_broadcast(net->uevent_sock->sk, skb, extack);
> > + mutex_unlock(&uevent_sock_mutex);
> > +
> > + return ret;
> > +}
> > +
> > +static void uevent_net_rcv(struct sk_buff *skb)
> > +{
> > + netlink_rcv_skb(skb, &uevent_net_rcv_skb);
> > +}
> > +
> > static int uevent_net_init(struct net *net)
> > {
> > struct uevent_sock *ue_sk;
> > struct netlink_kernel_cfg cfg = {
> > .groups = 1,
> > - .flags = NL_CFG_F_NONROOT_RECV,
> > + .input = uevent_net_rcv,
> > + .flags = NL_CFG_F_NONROOT_RECV
> > };
> >
> > ue_sk = kzalloc(sizeof(*ue_sk), GFP_KERNEL);
> > @@ -621,6 +694,9 @@ static int uevent_net_init(struct net *net)
> > kfree(ue_sk);
> > return -ENODEV;
> > }
> > +
> > + net->uevent_sock = ue_sk;
> > +
> > mutex_lock(&uevent_sock_mutex);
> > list_add_tail(&ue_sk->list, &uevent_sock_list);
> > mutex_unlock(&uevent_sock_mutex);
> > @@ -629,22 +705,16 @@ static int uevent_net_init(struct net *net)
> >
> > static void uevent_net_exit(struct net *net)
> > {
> > - struct uevent_sock *ue_sk;
> > + struct uevent_sock *ue_sk = net->uevent_sock;
> >
> > mutex_lock(&uevent_sock_mutex);
> > - list_for_each_entry(ue_sk, &uevent_sock_list, list) {
> > - if (sock_net(ue_sk->sk) == net)
> > - goto found;
> > - }
> > - mutex_unlock(&uevent_sock_mutex);
> > - return;
> > -
> > -found:
> > list_del(&ue_sk->list);
> > mutex_unlock(&uevent_sock_mutex);
> >
> > netlink_kernel_release(ue_sk->sk);
> > kfree(ue_sk);
> > +
> > + return;
> > }
> >
> > static struct pernet_operations uevent_net_ops = {
>
> Thanks,
> Kirill
^ permalink raw reply
* [PATCH 1/2 v3] net: add uevent socket member
From: Christian Brauner @ 2018-03-17 11:08 UTC (permalink / raw)
To: ebiederm, gregkh, netdev, linux-kernel
Cc: serge, avagin, ktkhai, Christian Brauner
This commit adds struct uevent_sock to struct net. Since struct uevent_sock
records the position of the uevent socket in the uevent socket list we can
trivially remove it from the uevent socket list during cleanup. This speeds
up the old removal codepath.
Note, list_del() will hit __list_del_entry_valid() in its call chain which
will validate that the element is a member of the list. If it isn't it will
take care that the list is not modified.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
---
Changelog v2->v3:
* patch added
This patch was split out of the follow up patch
Subject: [PATCH 2/2 v3] netns: send uevent messages
Changelog v1->v2:
* patch not present
Changelog v0->v1:
* patch not present
---
include/net/net_namespace.h | 4 +++-
lib/kobject_uevent.c | 19 +++++++++----------
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index f306b2aa15a4..abd7d91bffac 100644
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -40,7 +40,7 @@ struct net_device;
struct sock;
struct ctl_table_header;
struct net_generic;
-struct sock;
+struct uevent_sock;
struct netns_ipvs;
@@ -79,6 +79,8 @@ struct net {
struct sock *rtnl; /* rtnetlink socket */
struct sock *genl_sock;
+ struct uevent_sock *uevent_sock; /* uevent socket */
+
struct list_head dev_base_head;
struct hlist_head *dev_name_head;
struct hlist_head *dev_index_head;
diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
index 9fe6ec8fda28..cbdc60542cab 100644
--- a/lib/kobject_uevent.c
+++ b/lib/kobject_uevent.c
@@ -32,11 +32,13 @@ u64 uevent_seqnum;
#ifdef CONFIG_UEVENT_HELPER
char uevent_helper[UEVENT_HELPER_PATH_LEN] = CONFIG_UEVENT_HELPER_PATH;
#endif
-#ifdef CONFIG_NET
+
struct uevent_sock {
struct list_head list;
struct sock *sk;
};
+
+#ifdef CONFIG_NET
static LIST_HEAD(uevent_sock_list);
#endif
@@ -621,6 +623,9 @@ static int uevent_net_init(struct net *net)
kfree(ue_sk);
return -ENODEV;
}
+
+ net->uevent_sock = ue_sk;
+
mutex_lock(&uevent_sock_mutex);
list_add_tail(&ue_sk->list, &uevent_sock_list);
mutex_unlock(&uevent_sock_mutex);
@@ -629,22 +634,16 @@ static int uevent_net_init(struct net *net)
static void uevent_net_exit(struct net *net)
{
- struct uevent_sock *ue_sk;
+ struct uevent_sock *ue_sk = net->uevent_sock;
mutex_lock(&uevent_sock_mutex);
- list_for_each_entry(ue_sk, &uevent_sock_list, list) {
- if (sock_net(ue_sk->sk) == net)
- goto found;
- }
- mutex_unlock(&uevent_sock_mutex);
- return;
-
-found:
list_del(&ue_sk->list);
mutex_unlock(&uevent_sock_mutex);
netlink_kernel_release(ue_sk->sk);
kfree(ue_sk);
+
+ return;
}
static struct pernet_operations uevent_net_ops = {
--
2.15.1
^ permalink raw reply related
* [PATCH 2/2 v3] netns: send uevent messages
From: Christian Brauner @ 2018-03-17 11:08 UTC (permalink / raw)
To: ebiederm, gregkh, netdev, linux-kernel
Cc: serge, avagin, ktkhai, Christian Brauner
In-Reply-To: <20180317110826.1581-1-christian.brauner@ubuntu.com>
This patch adds a receive method to NETLINK_KOBJECT_UEVENT netlink sockets
to allow sending uevent messages into the network namespace the socket
belongs to.
Currently non-initial network namespaces are already isolated and don't
receive uevents. There are a number of cases where it is beneficial for a
sufficiently privileged userspace process to send a uevent into a network
namespace.
One such use case would be debugging and fuzzing of a piece of software
which listens and reacts to uevents. By running a copy of that software
inside a network namespace, specific uevents could then be presented to it.
More concretely, this would allow for easy testing of udevd/ueventd.
This will also allow some piece of software to run components inside a
separate network namespace and then effectively filter what that software
can receive. Some examples of software that do directly listen to uevents
and that we have in the past attempted to run inside a network namespace
are rbd (CEPH client) or the X server.
Implementation:
The implementation has been kept as simple as possible from the kernel's
perspective. Specifically, a simple input method uevent_net_rcv() is added
to NETLINK_KOBJECT_UEVENT sockets which completely reuses existing
af_netlink infrastructure and does neither add an additional netlink family
nor requires any user-visible changes.
For example, by using netlink_rcv_skb() we can make use of existing netlink
infrastructure to report back informative error messages to userspace.
Furthermore, this implementation does not introduce any overhead for
existing uevent generating codepaths. The struct netns got a new uevent
socket member that records the uevent socket associated with that network
namespace including its position in the uevent socket list. Since we record
the uevent socket for each network namespace in struct net we don't have to
walk the whole uevent socket list. Instead we can directly retrieve the
relevant uevent socket and send the message. At exit time we can now also
trivially remove the uevent socket from the uevent socket list. This keeps
the codepath very performant without introducing needless overhead and even
makes older codepaths faster.
Uevent sequence numbers are kept global. When a uevent message is sent to
another network namespace the implementation will simply increment the
global uevent sequence number and append it to the received uevent. This
has the advantage that the kernel will never need to parse the received
uevent message to replace any existing uevent sequence numbers. Instead it
is up to the userspace process to remove any existing uevent sequence
numbers in case the uevent message to be sent contains any.
Security:
In order for a caller to send uevent messages to a target network namespace
the caller must have CAP_SYS_ADMIN in the owning user namespace of the
target network namespace. Additionally, any received uevent message is
verified to not exceed size UEVENT_BUFFER_SIZE. This includes the space
needed to append the uevent sequence number.
Testing:
This patch has been tested and verified to work with the following udev
implementations:
1. CentOS 6 with udevd version 147
2. Debian Sid with systemd-udevd version 237
3. Android 7.1.1 with ueventd
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
---
Changelog v2->v3:
* Use reverse christmas tree ordering for local variables.
Changelog v1->v2:
* Add the whole struct uevent_sock to struct net not just the socket
member. Since struct uevent_sock records the position of the uevent
socket in the uevent socket list we can trivially remove it from the
uevent socket list during cleanup. This speeds up the old removal
codepath. list_del() will hitl __list_del_entry_valid() in its call chain
which will validate that the element is a member of the list. If it isn't
it will take care that the list is not modified.
Changelog v0->v1:
* Hold mutex_lock() until uevent is sent to preserve uevent message
ordering. See udev and commit for reference:
commit 7b60a18da393ed70db043a777fd9e6d5363077c4
Author: Andrew Vagin <avagin@openvz.org>
Date: Wed Mar 7 14:49:56 2012 +0400
uevent: send events in correct order according to seqnum (v3)
The queue handling in the udev daemon assumes that the events are
ordered.
---
lib/kobject_uevent.c | 79 +++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 78 insertions(+), 1 deletion(-)
diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
index cbdc60542cab..7631513f856e 100644
--- a/lib/kobject_uevent.c
+++ b/lib/kobject_uevent.c
@@ -25,6 +25,7 @@
#include <linux/uuid.h>
#include <linux/ctype.h>
#include <net/sock.h>
+#include <net/netlink.h>
#include <net/net_namespace.h>
@@ -604,12 +605,88 @@ int add_uevent_var(struct kobj_uevent_env *env, const char *format, ...)
EXPORT_SYMBOL_GPL(add_uevent_var);
#if defined(CONFIG_NET)
+static int uevent_net_broadcast(struct sock *usk, struct sk_buff *skb,
+ struct netlink_ext_ack *extack)
+{
+ /* u64 to chars: 2^64 - 1 = 21 chars */
+ char buf[sizeof("SEQNUM=") + 21];
+ struct sk_buff *skbc;
+ int ret;
+
+ /* bump and prepare sequence number */
+ ret = snprintf(buf, sizeof(buf), "SEQNUM=%llu", ++uevent_seqnum);
+ if (ret < 0 || (size_t)ret >= sizeof(buf))
+ return -ENOMEM;
+ ret++;
+
+ /* verify message does not overflow */
+ if ((skb->len + ret) > UEVENT_BUFFER_SIZE) {
+ NL_SET_ERR_MSG(extack, "uevent message too big");
+ return -EINVAL;
+ }
+
+ /* copy skb and extend to accommodate sequence number */
+ skbc = skb_copy_expand(skb, 0, ret, GFP_KERNEL);
+ if (!skbc)
+ return -ENOMEM;
+
+ /* append sequence number */
+ skb_put_data(skbc, buf, ret);
+
+ /* remove msg header */
+ skb_pull(skbc, NLMSG_HDRLEN);
+
+ /* set portid 0 to inform userspace message comes from kernel */
+ NETLINK_CB(skbc).portid = 0;
+ NETLINK_CB(skbc).dst_group = 1;
+
+ ret = netlink_broadcast(usk, skbc, 0, 1, GFP_KERNEL);
+ /* ENOBUFS should be handled in userspace */
+ if (ret == -ENOBUFS || ret == -ESRCH)
+ ret = 0;
+
+ return ret;
+}
+
+static int uevent_net_rcv_skb(struct sk_buff *skb, struct nlmsghdr *nlh,
+ struct netlink_ext_ack *extack)
+{
+ struct net *net;
+ int ret;
+
+ if (!nlmsg_data(nlh))
+ return -EINVAL;
+
+ /*
+ * Verify that we are allowed to send messages to the target
+ * network namespace. The caller must have CAP_SYS_ADMIN in the
+ * owning user namespace of the target network namespace.
+ */
+ net = sock_net(NETLINK_CB(skb).sk);
+ if (!netlink_ns_capable(skb, net->user_ns, CAP_SYS_ADMIN)) {
+ NL_SET_ERR_MSG(extack, "missing CAP_SYS_ADMIN capability");
+ return -EPERM;
+ }
+
+ mutex_lock(&uevent_sock_mutex);
+ ret = uevent_net_broadcast(net->uevent_sock->sk, skb, extack);
+ mutex_unlock(&uevent_sock_mutex);
+
+ return ret;
+}
+
+static void uevent_net_rcv(struct sk_buff *skb)
+{
+ netlink_rcv_skb(skb, &uevent_net_rcv_skb);
+}
+
static int uevent_net_init(struct net *net)
{
struct uevent_sock *ue_sk;
struct netlink_kernel_cfg cfg = {
.groups = 1,
- .flags = NL_CFG_F_NONROOT_RECV,
+ .input = uevent_net_rcv,
+ .flags = NL_CFG_F_NONROOT_RECV
};
ue_sk = kzalloc(sizeof(*ue_sk), GFP_KERNEL);
--
2.15.1
^ permalink raw reply related
* Re: Ask for help about flow classifier tool
From: Jiri Pirko @ 2018-03-17 12:47 UTC (permalink / raw)
To: Wei Hu (Xavier)
Cc: netdev, David Miller, linyunsheng, lipeng (Y),
00434615 >> shenjian 00434615, liangfuyun (A),
Chenxin (Charles)
In-Reply-To: <5AACE42B.3090607@huawei.com>
Sat, Mar 17, 2018 at 10:47:23AM CET, xavier.huwei@huawei.com wrote:
>Hi, David
>
> The TC Flower Classifier allows control of packets based on flows
>determined by matching of well-known packet fields and metadata.
> Offload of the TC Flower classifier and related modules provides a
>powerful mechanism to both increase throughput and reduce CPU
>utilisation for users of such flow-based systems.
>
> The command "ethtool -N" can provide similar function.
Afaik ethtool settings is very limited to rx queue steering.
If you want more actions, like vlan modification, tunnels, forward, etc,
you should use tc-flower
>
> Now, hip08 SOC has flow classifier hardware offload capacity, which
>tools we should support in HNS kernel driver?
> Can you give some suggestion?
>
> Regards
>Wei Hu
>
^ permalink raw reply
* RE: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs
From: Steve Wise @ 2018-03-17 13:23 UTC (permalink / raw)
To: 'Sinan Kaya', netdev, timur, sulrich
Cc: linux-arm-msm, linux-arm-kernel, 'Steve Wise',
'Doug Ledford', 'Jason Gunthorpe', linux-rdma,
linux-kernel, 'Michael Werner', 'Casey Leedom'
In-Reply-To: <1f5e3b14-05a1-08d0-c0cb-00805526448d@codeaurora.org>
>
> On 3/17/2018 12:03 AM, Sinan Kaya wrote:
> > On 3/16/2018 11:40 PM, Sinan Kaya wrote:
> >> I'll change writel_relaxed() with __raw_writel() in the series like you
> suggested
> >> and also look at your other comments.
> >
> > I spoke too soon.
> >
> > Now that I realized, code needs to follow one of the following patterns
> for correctness
> >
> > 1)
> > wmb()
> > writel()/writel_relaxed()
> >
> > or
> >
> > 2)
> > wmb()
> > __raw_wrltel()
> > mmiowb()
> >
> > but definitely not
> >
> > wmb()
> > __raw_wrltel()
> >
> > Since #1 == #2, I'll stick to my current implementation of writel_relaxed()
> >
> > Changing writel() to writel_relaxed() or __raw_writel() isn't enough.
> PowerPC needs mmiowb()
> > for correctness. ARM's mmiowb() implementation is empty.
> >
> > So, there is no one size fits all solution with the current state of affairs.
> >
> >
>
> I think I finally got what you mean.
>
> Code seems to have
>
> wmb()
> writel()/writeq()
> wmb()
>
> this can be safely replaced with
>
> wmb()
> __raw_writel()/__raw_writeq()
> wmb()
>
> This will work on all arches. Below is the new version. Let me know if this is
> OK.
>
> +++ b/drivers/infiniband/hw/cxgb4/t4.h
> @@ -457,7 +457,7 @@ static inline void pio_copy(u64 __iomem *dst, u64
> *src)
> int count = 8;
>
> while (count) {
> - writeq(*src, dst);
> + __raw_writeq(*src, dst);
> src++;
> dst++;
> count--;
> @@ -477,15 +477,16 @@ static inline void t4_ring_sq_db(struct t4_wq *wq,
> u16 inc, union t4_wr *wqe)
> (u64 *)wqe);
> } else {
> pr_debug("DB wq->sq.pidx = %d\n", wq->sq.pidx);
> - writel(PIDX_T5_V(inc) | QID_V(wq->sq.bar2_qid),
> - wq->sq.bar2_va + SGE_UDB_KDOORBELL);
> + __raw_writel(PIDX_T5_V(inc) | QID_V(wq->sq.bar2_qid),
> + wq->sq.bar2_va + SGE_UDB_KDOORBELL);
> }
>
> /* Flush user doorbell area writes. */
> wmb();
> return;
> }
> - writel(QID_V(wq->sq.qid) | PIDX_V(inc), wq->db);
> + __raw_writel(QID_V(wq->sq.qid) | PIDX_V(inc), wq->db);
> + mmiowmb()
> }
>
> static inline void t4_ring_rq_db(struct t4_wq *wq, u16 inc,
> @@ -502,15 +503,16 @@ static inline void t4_ring_rq_db(struct t4_wq *wq,
> u16 inc,
> (void *)wqe);
> } else {
> pr_debug("DB wq->rq.pidx = %d\n", wq->rq.pidx);
> - writel(PIDX_T5_V(inc) | QID_V(wq->rq.bar2_qid),
> - wq->rq.bar2_va + SGE_UDB_KDOORBELL);
> + __raw_writel(PIDX_T5_V(inc) | QID_V(wq->rq.bar2_qid),
> + wq->rq.bar2_va + SGE_UDB_KDOORBELL);
> }
>
> /* Flush user doorbell area writes. */
> wmb();
> return;
> }
> - writel(QID_V(wq->rq.qid) | PIDX_V(inc), wq->db);
> + __raw_writel(QID_V(wq->rq.qid) | PIDX_V(inc), wq->db);
> + mmiowmb();
> }
>
>
Yes, this is what chelsio recommended to me.
Reviewed-by: Steve Wise <swise@opengridcomputing.com>
^ 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