* linux-next: Signed-off-by missing for commit in the net-next tree
From: Stephen Rothwell @ 2019-09-10 14:41 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
The j1939 authors, Bastian Stender, Elenita Hinds, Kurt Van Dijck,
kbuild test robot, Maxime Jayat, Robin van der Gracht,
Oleksij Rempel, Marc Kleine-Budde
[-- Attachment #1: Type: text/plain, Size: 215 bytes --]
Hi all,
Commit
9d71dd0c7009 ("can: add support of SAE J1939 protocol")
is missing a Signed-off-by from its author.
[Not sure if I should complain about this one ...]
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH net-next 2/6] net: stmmac: Add VLAN HASH filtering support in GMAC4+
From: Jose Abreu @ 2019-09-10 14:41 UTC (permalink / raw)
To: netdev
Cc: Joao Pinto, Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue,
David S. Miller, Maxime Coquelin, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <cover.1568126224.git.joabreu@synopsys.com>
Adds the support for VLAN HASH Filtering in GMAC4/5 cores.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 11 ++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 31 +++++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c | 2 +-
3 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
index 03301ffc0391..4dfa69850040 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
@@ -16,6 +16,8 @@
#define GMAC_CONFIG 0x00000000
#define GMAC_PACKET_FILTER 0x00000008
#define GMAC_HASH_TAB(x) (0x10 + (x) * 4)
+#define GMAC_VLAN_TAG 0x00000050
+#define GMAC_VLAN_HASH_TABLE 0x00000058
#define GMAC_RX_FLOW_CTRL 0x00000090
#define GMAC_QX_TX_FLOW_CTRL(x) (0x70 + x * 4)
#define GMAC_TXQ_PRTY_MAP0 0x98
@@ -62,9 +64,18 @@
#define GMAC_PACKET_FILTER_PM BIT(4)
#define GMAC_PACKET_FILTER_PCF BIT(7)
#define GMAC_PACKET_FILTER_HPF BIT(10)
+#define GMAC_PACKET_FILTER_VTFE BIT(16)
#define GMAC_MAX_PERFECT_ADDRESSES 128
+/* MAC VLAN */
+#define GMAC_VLAN_EDVLP BIT(26)
+#define GMAC_VLAN_VTHM BIT(25)
+#define GMAC_VLAN_DOVLTC BIT(20)
+#define GMAC_VLAN_ESVL BIT(18)
+#define GMAC_VLAN_ETV BIT(16)
+#define GMAC_VLAN_VID GENMASK(15, 0)
+
/* MAC RX Queue Enable */
#define GMAC_RX_QUEUE_CLEAR(queue) ~(GENMASK(1, 0) << ((queue) * 2))
#define GMAC_RX_AV_QUEUE_ENABLE(queue) BIT((queue) * 2)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 596311a80d1c..5b43a8df1536 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -731,6 +731,34 @@ static void dwmac4_set_mac_loopback(void __iomem *ioaddr, bool enable)
writel(value, ioaddr + GMAC_CONFIG);
}
+static void dwmac4_update_vlan_hash(struct mac_device_info *hw, u32 hash,
+ bool is_double)
+{
+ void __iomem *ioaddr = hw->pcsr;
+
+ writel(hash, ioaddr + GMAC_VLAN_HASH_TABLE);
+
+ if (hash) {
+ u32 value = GMAC_VLAN_VTHM | GMAC_VLAN_ETV;
+ if (is_double) {
+ value |= GMAC_VLAN_EDVLP;
+ value |= GMAC_VLAN_ESVL;
+ value |= GMAC_VLAN_DOVLTC;
+ }
+
+ writel(value, ioaddr + GMAC_VLAN_TAG);
+ } else {
+ u32 value = readl(ioaddr + GMAC_VLAN_TAG);
+
+ value &= ~(GMAC_VLAN_VTHM | GMAC_VLAN_ETV);
+ value &= ~(GMAC_VLAN_EDVLP | GMAC_VLAN_ESVL);
+ value &= ~GMAC_VLAN_DOVLTC;
+ value &= ~GMAC_VLAN_VID;
+
+ writel(value, ioaddr + GMAC_VLAN_TAG);
+ }
+}
+
const struct stmmac_ops dwmac4_ops = {
.core_init = dwmac4_core_init,
.set_mac = stmmac_set_mac,
@@ -761,6 +789,7 @@ const struct stmmac_ops dwmac4_ops = {
.debug = dwmac4_debug,
.set_filter = dwmac4_set_filter,
.set_mac_loopback = dwmac4_set_mac_loopback,
+ .update_vlan_hash = dwmac4_update_vlan_hash,
};
const struct stmmac_ops dwmac410_ops = {
@@ -793,6 +822,7 @@ const struct stmmac_ops dwmac410_ops = {
.debug = dwmac4_debug,
.set_filter = dwmac4_set_filter,
.set_mac_loopback = dwmac4_set_mac_loopback,
+ .update_vlan_hash = dwmac4_update_vlan_hash,
};
const struct stmmac_ops dwmac510_ops = {
@@ -830,6 +860,7 @@ const struct stmmac_ops dwmac510_ops = {
.rxp_config = dwmac5_rxp_config,
.flex_pps_config = dwmac5_flex_pps_config,
.set_mac_loopback = dwmac4_set_mac_loopback,
+ .update_vlan_hash = dwmac4_update_vlan_hash,
};
int dwmac4_setup(struct stmmac_priv *priv)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index 3ed5508586ef..2456f421aac9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -333,7 +333,7 @@ static void dwmac4_get_hw_feature(void __iomem *ioaddr,
dma_cap->mbps_10_100 = (hw_cap & GMAC_HW_FEAT_MIISEL);
dma_cap->mbps_1000 = (hw_cap & GMAC_HW_FEAT_GMIISEL) >> 1;
dma_cap->half_duplex = (hw_cap & GMAC_HW_FEAT_HDSEL) >> 2;
- dma_cap->hash_filter = (hw_cap & GMAC_HW_FEAT_VLHASH) >> 4;
+ dma_cap->vlhash = (hw_cap & GMAC_HW_FEAT_VLHASH) >> 4;
dma_cap->multi_addr = (hw_cap & GMAC_HW_FEAT_ADDMAC) >> 18;
dma_cap->pcs = (hw_cap & GMAC_HW_FEAT_PCSSEL) >> 3;
dma_cap->sma_mdio = (hw_cap & GMAC_HW_FEAT_SMASEL) >> 5;
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 5/6] net: stmmac: Add support for VLAN Insertion Offload in GMAC4+
From: Jose Abreu @ 2019-09-10 14:41 UTC (permalink / raw)
To: netdev
Cc: Joao Pinto, Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue,
David S. Miller, Maxime Coquelin, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <cover.1568126224.git.joabreu@synopsys.com>
Adds support for TX VLAN Offload using descriptors based features
available in GMAC4/5.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 6 ++++
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 16 ++++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 35 ++++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.h | 8 +++++
drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c | 1 +
5 files changed, 66 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
index fad121cbfe0e..e88dac1dd765 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
@@ -19,6 +19,7 @@
#define GMAC_VLAN_TAG 0x00000050
#define GMAC_VLAN_HASH_TABLE 0x00000058
#define GMAC_RX_FLOW_CTRL 0x00000090
+#define GMAC_VLAN_INCL 0x00000060
#define GMAC_QX_TX_FLOW_CTRL(x) (0x70 + x * 4)
#define GMAC_TXQ_PRTY_MAP0 0x98
#define GMAC_TXQ_PRTY_MAP1 0x9C
@@ -75,6 +76,10 @@
#define GMAC_VLAN_ESVL BIT(18)
#define GMAC_VLAN_ETV BIT(16)
#define GMAC_VLAN_VID GENMASK(15, 0)
+#define GMAC_VLAN_VLTI BIT(20)
+#define GMAC_VLAN_CSVL BIT(19)
+#define GMAC_VLAN_VLC GENMASK(17, 16)
+#define GMAC_VLAN_VLC_SHIFT 16
/* MAC RX Queue Enable */
#define GMAC_RX_QUEUE_CLEAR(queue) ~(GENMASK(1, 0) << ((queue) * 2))
@@ -212,6 +217,7 @@ enum power_event {
#define GMAC_HW_FEAT_FRPES GENMASK(14, 13)
#define GMAC_HW_FEAT_FRPBS GENMASK(12, 11)
#define GMAC_HW_FEAT_FRPSEL BIT(10)
+#define GMAC_HW_FEAT_DVLAN BIT(5)
/* MAC HW ADDR regs */
#define GMAC_HI_DCS GENMASK(18, 16)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 73dbfd810fca..a99effe61325 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -769,6 +769,19 @@ static void dwmac4_sarc_configure(void __iomem *ioaddr, int val)
writel(value, ioaddr + GMAC_CONFIG);
}
+static void dwmac4_enable_vlan(struct mac_device_info *hw, u32 type)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 value;
+
+ value = readl(ioaddr + GMAC_VLAN_INCL);
+ value |= GMAC_VLAN_VLTI;
+ value |= GMAC_VLAN_CSVL; /* Only use SVLAN */
+ value &= ~GMAC_VLAN_VLC;
+ value |= (type << GMAC_VLAN_VLC_SHIFT) & GMAC_VLAN_VLC;
+ writel(value, ioaddr + GMAC_VLAN_INCL);
+}
+
const struct stmmac_ops dwmac4_ops = {
.core_init = dwmac4_core_init,
.set_mac = stmmac_set_mac,
@@ -801,6 +814,7 @@ const struct stmmac_ops dwmac4_ops = {
.set_mac_loopback = dwmac4_set_mac_loopback,
.update_vlan_hash = dwmac4_update_vlan_hash,
.sarc_configure = dwmac4_sarc_configure,
+ .enable_vlan = dwmac4_enable_vlan,
};
const struct stmmac_ops dwmac410_ops = {
@@ -835,6 +849,7 @@ const struct stmmac_ops dwmac410_ops = {
.set_mac_loopback = dwmac4_set_mac_loopback,
.update_vlan_hash = dwmac4_update_vlan_hash,
.sarc_configure = dwmac4_sarc_configure,
+ .enable_vlan = dwmac4_enable_vlan,
};
const struct stmmac_ops dwmac510_ops = {
@@ -874,6 +889,7 @@ const struct stmmac_ops dwmac510_ops = {
.set_mac_loopback = dwmac4_set_mac_loopback,
.update_vlan_hash = dwmac4_update_vlan_hash,
.sarc_configure = dwmac4_sarc_configure,
+ .enable_vlan = dwmac4_enable_vlan,
};
int dwmac4_setup(struct stmmac_priv *priv)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
index 8edc9f8787cc..15eb1abba91d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@ -459,6 +459,39 @@ static int set_16kib_bfsize(int mtu)
return ret;
}
+static void dwmac4_set_vlan_tag(struct dma_desc *p, u16 tag, u16 inner_tag,
+ u32 inner_type)
+{
+ p->des0 = 0;
+ p->des1 = 0;
+ p->des2 = 0;
+ p->des3 = 0;
+
+ /* Inner VLAN */
+ if (inner_type) {
+ u32 des = inner_tag << TDES2_IVT_SHIFT;
+
+ des &= TDES2_IVT_MASK;
+ p->des2 = cpu_to_le32(des);
+
+ des = inner_type << TDES3_IVTIR_SHIFT;
+ des &= TDES3_IVTIR_MASK;
+ p->des3 = cpu_to_le32(des | TDES3_IVLTV);
+ }
+
+ /* Outer VLAN */
+ p->des3 |= cpu_to_le32(tag & TDES3_VLAN_TAG);
+ p->des3 |= cpu_to_le32(TDES3_VLTV);
+
+ p->des3 |= cpu_to_le32(TDES3_CONTEXT_TYPE);
+}
+
+static void dwmac4_set_vlan(struct dma_desc *p, u32 type)
+{
+ type <<= TDES2_VLAN_TAG_SHIFT;
+ p->des2 |= cpu_to_le32(type & TDES2_VLAN_TAG_MASK);
+}
+
const struct stmmac_desc_ops dwmac4_desc_ops = {
.tx_status = dwmac4_wrback_get_tx_status,
.rx_status = dwmac4_wrback_get_rx_status,
@@ -484,6 +517,8 @@ const struct stmmac_desc_ops dwmac4_desc_ops = {
.set_addr = dwmac4_set_addr,
.clear = dwmac4_clear,
.set_sarc = dwmac4_set_sarc,
+ .set_vlan_tag = dwmac4_set_vlan_tag,
+ .set_vlan = dwmac4_set_vlan,
};
const struct stmmac_mode_ops dwmac4_ring_mode_ops = {
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.h
index 6089d76a00d3..0d7b3bbcd5a7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.h
@@ -18,13 +18,21 @@
/* TDES2 (read format) */
#define TDES2_BUFFER1_SIZE_MASK GENMASK(13, 0)
#define TDES2_VLAN_TAG_MASK GENMASK(15, 14)
+#define TDES2_VLAN_TAG_SHIFT 14
#define TDES2_BUFFER2_SIZE_MASK GENMASK(29, 16)
#define TDES2_BUFFER2_SIZE_MASK_SHIFT 16
+#define TDES3_IVTIR_MASK GENMASK(19, 18)
+#define TDES3_IVTIR_SHIFT 18
+#define TDES3_IVLTV BIT(17)
#define TDES2_TIMESTAMP_ENABLE BIT(30)
+#define TDES2_IVT_MASK GENMASK(31, 16)
+#define TDES2_IVT_SHIFT 16
#define TDES2_INTERRUPT_ON_COMPLETION BIT(31)
/* TDES3 (read format) */
#define TDES3_PACKET_SIZE_MASK GENMASK(14, 0)
+#define TDES3_VLAN_TAG GENMASK(15, 0)
+#define TDES3_VLTV BIT(16)
#define TDES3_CHECKSUM_INSERTION_MASK GENMASK(17, 16)
#define TDES3_CHECKSUM_INSERTION_SHIFT 16
#define TDES3_TCP_PKT_PAYLOAD_MASK GENMASK(17, 0)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index 82d9761b2df2..f3ca0236450d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -386,6 +386,7 @@ static void dwmac4_get_hw_feature(void __iomem *ioaddr,
dma_cap->frpes = (hw_cap & GMAC_HW_FEAT_FRPES) >> 13;
dma_cap->frpbs = (hw_cap & GMAC_HW_FEAT_FRPBS) >> 11;
dma_cap->frpsel = (hw_cap & GMAC_HW_FEAT_FRPSEL) >> 10;
+ dma_cap->dvlan = (hw_cap & GMAC_HW_FEAT_DVLAN) >> 5;
}
/* Enable/disable TSO feature and set MSS */
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 1/6] net: stmmac: Prevent divide-by-zero
From: Jose Abreu @ 2019-09-10 14:41 UTC (permalink / raw)
To: netdev
Cc: Joao Pinto, Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue,
David S. Miller, Maxime Coquelin, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <cover.1568126224.git.joabreu@synopsys.com>
When RX Coalesce settings are set to all zero (which is a valid setting)
we will currently get a divide-by-zero error. Fix it.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 686b82068142..6e44013b20cc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3418,7 +3418,9 @@ static inline void stmmac_rx_refill(struct stmmac_priv *priv, u32 queue)
stmmac_refill_desc3(priv, rx_q, p);
rx_q->rx_count_frames++;
- rx_q->rx_count_frames %= priv->rx_coal_frames;
+ rx_q->rx_count_frames += priv->rx_coal_frames;
+ if (rx_q->rx_count_frames > priv->rx_coal_frames)
+ rx_q->rx_count_frames = 0;
use_rx_wd = priv->use_riwt && rx_q->rx_count_frames;
dma_wmb();
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 6/6] net: stmmac: ARP Offload for GMAC4+ Cores
From: Jose Abreu @ 2019-09-10 14:41 UTC (permalink / raw)
To: netdev
Cc: Joao Pinto, Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue,
David S. Miller, Maxime Coquelin, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <cover.1568126224.git.joabreu@synopsys.com>
Implement the ARP Offload feature in GMAC4 and GMAC5 cores.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 3 +++
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 19 +++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c | 1 +
3 files changed, 23 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
index e88dac1dd765..89a3420eba42 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
@@ -40,6 +40,7 @@
#define GMAC_HW_FEATURE3 0x00000128
#define GMAC_MDIO_ADDR 0x00000200
#define GMAC_MDIO_DATA 0x00000204
+#define GMAC_ARP_ADDR 0x00000210
#define GMAC_ADDR_HIGH(reg) (0x300 + reg * 8)
#define GMAC_ADDR_LOW(reg) (0x304 + reg * 8)
@@ -165,6 +166,7 @@ enum power_event {
#define GMAC_DEBUG_RPESTS BIT(0)
/* MAC config */
+#define GMAC_CONFIG_ARPEN BIT(31)
#define GMAC_CONFIG_SARC GENMASK(30, 28)
#define GMAC_CONFIG_SARC_SHIFT 28
#define GMAC_CONFIG_IPC BIT(27)
@@ -188,6 +190,7 @@ enum power_event {
#define GMAC_HW_FEAT_TXCOSEL BIT(14)
#define GMAC_HW_FEAT_EEESEL BIT(13)
#define GMAC_HW_FEAT_TSSEL BIT(12)
+#define GMAC_HW_FEAT_ARPOFFSEL BIT(9)
#define GMAC_HW_FEAT_MMCSEL BIT(8)
#define GMAC_HW_FEAT_MGKSEL BIT(7)
#define GMAC_HW_FEAT_RWKSEL BIT(6)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index a99effe61325..9b4b5f69fc02 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -782,6 +782,22 @@ static void dwmac4_enable_vlan(struct mac_device_info *hw, u32 type)
writel(value, ioaddr + GMAC_VLAN_INCL);
}
+static void dwmac4_set_arp_offload(struct mac_device_info *hw, bool en,
+ u32 addr)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 value;
+
+ writel(addr, ioaddr + GMAC_ARP_ADDR);
+
+ value = readl(ioaddr + GMAC_CONFIG);
+ if (en)
+ value |= GMAC_CONFIG_ARPEN;
+ else
+ value &= ~GMAC_CONFIG_ARPEN;
+ writel(value, ioaddr + GMAC_CONFIG);
+}
+
const struct stmmac_ops dwmac4_ops = {
.core_init = dwmac4_core_init,
.set_mac = stmmac_set_mac,
@@ -815,6 +831,7 @@ const struct stmmac_ops dwmac4_ops = {
.update_vlan_hash = dwmac4_update_vlan_hash,
.sarc_configure = dwmac4_sarc_configure,
.enable_vlan = dwmac4_enable_vlan,
+ .set_arp_offload = dwmac4_set_arp_offload,
};
const struct stmmac_ops dwmac410_ops = {
@@ -850,6 +867,7 @@ const struct stmmac_ops dwmac410_ops = {
.update_vlan_hash = dwmac4_update_vlan_hash,
.sarc_configure = dwmac4_sarc_configure,
.enable_vlan = dwmac4_enable_vlan,
+ .set_arp_offload = dwmac4_set_arp_offload,
};
const struct stmmac_ops dwmac510_ops = {
@@ -890,6 +908,7 @@ const struct stmmac_ops dwmac510_ops = {
.update_vlan_hash = dwmac4_update_vlan_hash,
.sarc_configure = dwmac4_sarc_configure,
.enable_vlan = dwmac4_enable_vlan,
+ .set_arp_offload = dwmac4_set_arp_offload,
};
int dwmac4_setup(struct stmmac_priv *priv)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index f3ca0236450d..68c157979b94 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -349,6 +349,7 @@ static void dwmac4_get_hw_feature(void __iomem *ioaddr,
dma_cap->tx_coe = (hw_cap & GMAC_HW_FEAT_TXCOSEL) >> 14;
dma_cap->rx_coe = (hw_cap & GMAC_HW_FEAT_RXCOESEL) >> 16;
dma_cap->vlins = (hw_cap & GMAC_HW_FEAT_SAVLANINS) >> 27;
+ dma_cap->arpoffsel = (hw_cap & GMAC_HW_FEAT_ARPOFFSEL) >> 9;
/* MAC HW feature1 */
hw_cap = readl(ioaddr + GMAC_HW_FEATURE1);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 0/6] net: stmmac: Improvements for -next
From: Jose Abreu @ 2019-09-10 14:41 UTC (permalink / raw)
To: netdev
Cc: Joao Pinto, Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue,
David S. Miller, Maxime Coquelin, linux-stm32, linux-arm-kernel,
linux-kernel
Misc patches for -next. It includes:
- Two fixes for features in -next only
- New features support for GMAC cores (which includes GMAC4 and GMAC5)
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
Jose Abreu (6):
net: stmmac: Prevent divide-by-zero
net: stmmac: Add VLAN HASH filtering support in GMAC4+
net: stmmac: xgmac: Reinitialize correctly a variable
net: stmmac: Add support for SA Insertion/Replacement in GMAC4+
net: stmmac: Add support for VLAN Insertion Offload in GMAC4+
net: stmmac: ARP Offload for GMAC4+ Cores
drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 23 +++++++
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 79 ++++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 43 ++++++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.h | 9 +++
drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c | 5 +-
.../net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +-
7 files changed, 162 insertions(+), 3 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH net-next 3/6] net: stmmac: xgmac: Reinitialize correctly a variable
From: Jose Abreu @ 2019-09-10 14:41 UTC (permalink / raw)
To: netdev
Cc: Joao Pinto, Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue,
David S. Miller, Maxime Coquelin, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <cover.1568126224.git.joabreu@synopsys.com>
'value' was being or'ed with a value from another register. This is a
typo and could cause new written value to be wrong. Fix it.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
index 78ac659da279..d5173dd02a71 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
@@ -568,7 +568,7 @@ static void dwxgmac2_update_vlan_hash(struct mac_device_info *hw, u32 hash,
writel(value, ioaddr + XGMAC_PACKET_FILTER);
- value |= XGMAC_VLAN_VTHM | XGMAC_VLAN_ETV;
+ value = XGMAC_VLAN_VTHM | XGMAC_VLAN_ETV;
if (is_double) {
value |= XGMAC_VLAN_EDVLP;
value |= XGMAC_VLAN_ESVL;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next v2 1/3] net: dsa: microchip: add KSZ9477 I2C driver
From: George McCollister @ 2019-09-10 14:40 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, Woojung Huh, Florian Fainelli, Tristram Ha,
David S. Miller, Marek Vasut, open list
In-Reply-To: <20190910140304.GA4683@lunn.ch>
Andrew,
On Tue, Sep 10, 2019 at 9:03 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> Hi George
>
> > +KSZ_REGMAP_TABLE(ksz9477, not_used, 16, 0, 0);
> > +
> > @@ -294,6 +294,8 @@ static inline void ksz_pwrite32(struct ksz_device *dev, int port, int offset,
> > #define KSZ_SPI_OP_RD 3
> > #define KSZ_SPI_OP_WR 2
> >
> > +#define swabnot_used(x) 0
>
> > +
> > #define KSZ_SPI_OP_FLAG_MASK(opcode, swp, regbits, regpad) \
> > swab##swp((opcode) << ((regbits) + (regpad)))
>
> There seems to be quite a lot of macro magic here which is not
> obvious. Can this be simplified or made more obvious?
I thought about this for quite some time. To reduce the "macro magic"
the SPI specific parts will need to be removed from the common macro
and arguments for read_flag_mask and write_flag_mask would need to be
added to both KSZ_REGMAP_TABLE and KSZ_REGMAP_TABLE. That would leave
us with two macros that have 7 arguments. Not really an improvement
IMHO. Alternatively we could have different macros for SPI and I2C (or
not use the macros at all and define the i2c regmaps in ksz9477_i2c.c)
at the cost of ~20 lines of duplication. I prefer the "macro magic"
approach, however if you won't let the patch through the way it is
I'll respect your decision, just let me know which of the three
proposed approaches you want to go with.
>
> Andrew
Cheers,
George
^ permalink raw reply
* linux-next: Fixes tag needs some work in the net-next tree
From: Stephen Rothwell @ 2019-09-10 14:37 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Quentin Monnet, Alexei Starovoitov
[-- Attachment #1: Type: text/plain, Size: 377 bytes --]
Hi all,
In commit
ed4a3983cd3e ("tools: bpftool: fix argument for p_err() in BTF do_dump()")
Fixes tag
Fixes: c93cc69004dt ("bpftool: add ability to dump BTF types")
has these problem(s):
- missing space between the SHA1 and the subject
Presumably:
Fixes: c93cc69004df ("bpftool: add ability to dump BTF types")
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: VRF Issue Since kernel 5
From: Gowen @ 2019-09-10 14:22 UTC (permalink / raw)
To: Alexis Bauvin; +Cc: netdev@vger.kernel.org
In-Reply-To: <CWLP265MB1554989CAA2DB59B6862A6A2FDB70@CWLP265MB1554.GBRP265.PROD.OUTLOOK.COM>
Hi Alexis,
I enabled the target TRACE and found that the packet is passing through the security table - which I thought was for SELinux only. As far as I can tell the config is working, is being seen by iptables nut for some reason is not getting accepted by the local process - which isn't right surely. Debugs below from TRACE for the 91.0.0.0/8 subnet for the updates
Sep 10 13:50:37 NETM06 kernel: [442740.425992] TRACE: raw:PREROUTING:policy:2 IN=mgmt-vrf OUT= MAC=00:22:48:07:cc:ad:74:83:ef:a9:ca:c1:08:00 SRC=91.189.88.24 DST=10.24.12.10 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=0 DF PROTO=TCP SPT=80 DPT=40164 SEQ=2210516855 ACK=3954601288 WINDOW=28960 RES=0x00 ACK SYN URGP=0 OPT (0204058A0402080AD622157697AC236D01030307)
Sep 10 13:50:37 NETM06 kernel: [442740.426045] TRACE: filter:INPUT:rule:1 IN=mgmt-vrf OUT= MAC=00:22:48:07:cc:ad:74:83:ef:a9:ca:c1:08:00 SRC=91.189.88.24 DST=10.24.12.10 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=0 DF PROTO=TCP SPT=80 DPT=40164 SEQ=2210516855 ACK=3954601288 WINDOW=28960 RES=0x00 ACK SYN URGP=0 OPT (0204058A0402080AD622157697AC236D01030307)
Sep 10 13:50:37 NETM06 kernel: [442740.426060] TRACE: security:INPUT:rule:1 IN=mgmt-vrf OUT= MAC=00:22:48:07:cc:ad:74:83:ef:a9:ca:c1:08:00 SRC=91.189.88.24 DST=10.24.12.10 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=0 DF PROTO=TCP SPT=80 DPT=40164 SEQ=2210516855 ACK=3954601288 WINDOW=28960 RES=0x00 ACK SYN URGP=0 OPT (0204058A0402080AD622157697AC236D01030307)
Sep 10 13:50:37 NETM06 kernel: [442740.426108] TRACE: security:INPUT:policy:2 IN=mgmt-vrf OUT= MAC=00:22:48:07:cc:ad:74:83:ef:a9:ca:c1:08:00 SRC=91.189.88.24 DST=10.24.12.10 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=0 DF PROTO=TCP SPT=80 DPT=40164 SEQ=2210516855 ACK=3954601288 WINDOW=28960 RES=0x00 ACK SYN URGP=0 OPT (0204058A0402080AD622157697AC236D01030307)
Admin@NETM06:~$ sudo iptables -L PREROUTING -t raw -n -v
Chain PREROUTING (policy ACCEPT 56061 packets, 5260K bytes)
pkts bytes target prot opt in out source destination
296 16480 TRACE tcp -- mgmt-vrf * 91.0.0.0/8 0.0.0.0/0 ctstate RELATED,ESTABLISHED tcp spt:80
Chain INPUT (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 330 18260 ACCEPT tcp -- mgmt-vrf * 91.0.0.0/8 0.0.0.0/0 ctstate RELATED,ESTABLISHED tcp spt:80
Admin@NETM06:~$ sudo iptables -L -t security -n -v --line-numbers
Chain INPUT (policy ACCEPT 4190 packets, 371K bytes)
num pkts bytes target prot opt in out source destination
1 248 13980 LOG all -- * * 91.0.0.0/8 0.0.0.0/0 LOG flags 0 level 4 prefix "LOG-SECURITY"
From: Gowen
Sent: 09 September 2019 20:43
To: Alexis Bauvin <abauvin@online.net>
Cc: netdev@vger.kernel.org <netdev@vger.kernel.org>
Subject: RE: VRF Issue Since kernel 5
Hi alexis,
I did this earlier today and no change.
I’ll look at trying to see if the return traffic is hitting the INPUT table tomorrow with some conntrack rules and see if it hits any of those rules. If not then do you have any hints/techniques I can use to find the source of the issue?
Gareth
-----Original Message-----
From: Alexis Bauvin <abauvin@online.net>
Sent: 09 September 2019 13:02
To: Gowen <gowen@potatocomputing.co.uk>
Cc: netdev@vger.kernel.org
Subject: Re: VRF Issue Since kernel 5
Hi,
I guess all routing from the management VRF itself is working correctly (i.e. cURLing an IP from this VRF or digging any DNS), and it is your route leakage that’s at fault.
Could you try swapping the local and l3mdev rules?
`ip rule del pref 0; ip rule add from all lookup local pref 1001`
I faced security issues and behavioral weirdnesses from the default kernel rule ordering regarding the default vrf.
Alexis
> Le 9 sept. 2019 à 12:53, Gowen <gowen@potatocomputing.co.uk> a écrit :
>
> Hi Alexis,
>
> Admin@NETM06:~$ sysctl net.ipv4.tcp_l3mdev_accept
> net.ipv4.tcp_l3mdev_accept = 1
>
> Admin@NETM06:~$ sudo ip vrf exec mgmt-vrf curl kernel.org
> curl: (6) Could not resolve host: kernel.org
>
> the failure to resolve is the same with all DNS lookups from any
> process I've run
>
> The route is there from the guide I originally used, I can't remember
> the purpose but I know I don't need it - I've removed it now and no
> change
>
> Admin@NETM06:~$ ip rule show
> 0: from all lookup local
> 1000: from all lookup [l3mdev-table]
> 32766: from all lookup main
> 32767: from all lookup default
>
> I could switch the VRFs over, but this is a test-box and i have prod boxes on this as well so not so keen on that if I can avoid it.
>
> From what I can speculate, because the TCP return traffic is met with an RST, it looks like it may be something to do with iptables - but even if I set the policy to ACCEPT and flush all the rules, the behaviour remains the same.
>
> Is it possible that the TCP stack isn't aware of the session (as is mapped to wrong VRF internally or something to that effect) and is therefore sending the RST?
>
> Gareth
> From: Alexis Bauvin <abauvin@online.net>
> Sent: 09 September 2019 10:28
> To: Gowen <gowen@potatocomputing.co.uk>
> Cc: netdev@vger.kernel.org <netdev@vger.kernel.org>
> Subject: Re: VRF Issue Since kernel 5
>
> Hi,
>
> There has been some changes regarding VRF isolation in Linux 5 IIRC,
> namely proper isolation of the default VRF.
>
> Some things you may try:
>
> - looking at the l3mdev_accept sysctls (e.g.
> `net.ipv4.tcp_l3mdev_accept`)
> - querying stuff from the management vrf through `ip vrf exec vrf-mgmt <stuff>`
> e.g. `ip vrf exec vrf-mgmt curl kernel.org`
> `ip vrf exec vrf-mgmt dig @1.1.1.1 kernel.org`
> - reversing your logic: default VRF is your management one, the other one is for your
> other boxes
>
> Also, your `unreachable default metric 4278198272` route looks odd to me.
>
> What are your routing rules? (`ip rule`)
>
> Alexis
>
> > Le 9 sept. 2019 à 09:46, Gowen <gowen@potatocomputing.co.uk> a écrit :
> >
> > Hi there,
> >
> > Dave A said this was the mailer to send this to:
> >
> >
> > I’ve been using my management interface in a VRF for several months now and it’s worked perfectly – I’ve been able to update/upgrade the packages just fine and iptables works excellently with it – exactly as I needed.
> >
> >
> > Since Kernel 5 though I am no longer able to update – but the issue
> > is quite a curious one as some traffic appears to be fine (DNS
> > lookups use VRF correctly) but others don’t (updating/upgrading the
> > packages)
> >
> >
> > I have on this device 2 interfaces:
> > Eth0 for management – inbound SSH, DNS, updates/upgrades
> > Eth1 for managing other boxes (ansible using SSH)
> >
> >
> > Link and addr info shown below:
> >
> >
> > Admin@NETM06:~$ ip link show
> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
> > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master mgmt-vrf state UP mode DEFAULT group default qlen 1000
> > link/ether 00:22:48:07:cc:ad brd ff:ff:ff:ff:ff:ff
> > 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
> > link/ether 00:22:48:07:c9:6c brd ff:ff:ff:ff:ff:ff
> > 4: mgmt-vrf: <NOARP,MASTER,UP,LOWER_UP> mtu 65536 qdisc noqueue state UP mode DEFAULT group default qlen 1000
> > link/ether 8a:f6:26:65:02:5a brd ff:ff:ff:ff:ff:ff
> >
> >
> > Admin@NETM06:~$ ip addr
> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
> > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> > inet 127.0.0.1/8 scope host lo
> > valid_lft forever preferred_lft forever
> > inet6 ::1/128 scope host
> > valid_lft forever preferred_lft forever
> > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master mgmt-vrf state UP group default qlen 1000
> > link/ether 00:22:48:07:cc:ad brd ff:ff:ff:ff:ff:ff
> > inet 10.24.12.10/24 brd 10.24.12.255 scope global eth0
> > valid_lft forever preferred_lft forever
> > inet6 fe80::222:48ff:fe07:ccad/64 scope link
> > valid_lft forever preferred_lft forever
> > 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
> > link/ether 00:22:48:07:c9:6c brd ff:ff:ff:ff:ff:ff
> > inet 10.24.12.9/24 brd 10.24.12.255 scope global eth1
> > valid_lft forever preferred_lft forever
> > inet6 fe80::222:48ff:fe07:c96c/64 scope link
> > valid_lft forever preferred_lft forever
> > 4: mgmt-vrf: <NOARP,MASTER,UP,LOWER_UP> mtu 65536 qdisc noqueue state UP group default qlen 1000
> > link/ether 8a:f6:26:65:02:5a brd ff:ff:ff:ff:ff:ff
> >
> >
> >
> > the production traffic is all in the 10.0.0.0/8 network (eth1 global
> > VRF) except for a few subnets (DNS) which are routed out eth0
> > (mgmt-vrf)
> >
> >
> > Admin@NETM06:~$ ip route show
> > default via 10.24.12.1 dev eth0
> > 10.0.0.0/8 via 10.24.12.1 dev eth1
> > 10.24.12.0/24 dev eth1 proto kernel scope link src 10.24.12.9
> > 10.24.65.0/24 via 10.24.12.1 dev eth0
> > 10.25.65.0/24 via 10.24.12.1 dev eth0
> > 10.26.0.0/21 via 10.24.12.1 dev eth0
> > 10.26.64.0/21 via 10.24.12.1 dev eth0
> >
> >
> > Admin@NETM06:~$ ip route show vrf mgmt-vrf default via 10.24.12.1
> > dev eth0 unreachable default metric 4278198272
> > 10.24.12.0/24 dev eth0 proto kernel scope link src 10.24.12.10
> > 10.24.65.0/24 via 10.24.12.1 dev eth0
> > 10.25.65.0/24 via 10.24.12.1 dev eth0
> > 10.26.0.0/21 via 10.24.12.1 dev eth0
> > 10.26.64.0/21 via 10.24.12.1 dev eth0
> >
> >
> >
> > The strange activity occurs when I enter the command “sudo apt update” as I can resolve the DNS request (10.24.65.203 or 10.24.64.203, verified with tcpdump) out eth0 but for the actual update traffic there is no activity:
> >
> >
> > sudo tcpdump -i eth0 '(host 10.24.65.203 or host 10.25.65.203) and
> > port 53' -n <OUTPUT OMITTED FOR BREVITY>
> > 10:06:05.268735 IP 10.24.12.10.39963 > 10.24.65.203.53: 48798+ [1au]
> > A? security.ubuntu.com. (48) <OUTPUT OMITTED FOR BREVITY>
> > 10:06:05.284403 IP 10.24.65.203.53 > 10.24.12.10.39963: 48798 13/0/1
> > A 91.189.91.23, A 91.189.88.24, A 91.189.91.26, A 91.189.88.162, A
> > 91.189.88.149, A 91.189.91.24, A 91.189.88.173, A 91.189.88.177, A
> > 91.189.88.31, A 91.189.91.14, A 91.189.88.176, A 91.189.88.175, A
> > 91.189.88.174 (256)
> >
> >
> >
> > You can see that the update traffic is returned but is not accepted
> > by the stack and a RST is sent
> >
> >
> > Admin@NETM06:~$ sudo tcpdump -i eth0 '(not host 168.63.129.16 and
> > port 80)' -n
> > tcpdump: verbose output suppressed, use -v or -vv for full protocol
> > decode listening on eth0, link-type EN10MB (Ethernet), capture size
> > 262144 bytes
> > 10:17:12.690658 IP 10.24.12.10.40216 > 91.189.88.175.80: Flags [S],
> > seq 2279624826, win 64240, options [mss 1460,sackOK,TS val
> > 2029365856 ecr 0,nop,wscale 7], length 0
> > 10:17:12.691929 IP 10.24.12.10.52362 > 91.189.95.83.80: Flags [S], seq 1465797256, win 64240, options [mss 1460,sackOK,TS val 3833463674 ecr 0,nop,wscale 7], length 0
> > 10:17:12.696270 IP 91.189.88.175.80 > 10.24.12.10.40216: Flags [S.], seq 968450722, ack 2279624827, win 28960, options [mss 1418,sackOK,TS val 81957103 ecr 2029365856,nop,wscale 7], length 0
> > 10:17:12.696301 IP 10.24.12.10.40216 > 91.189.88.175.80: Flags [R], seq 2279624827, win 0, length 0
> > 10:17:12.697884 IP 91.189.95.83.80 > 10.24.12.10.52362: Flags [S.], seq 4148330738, ack 1465797257, win 28960, options [mss 1418,sackOK,TS val 2257624414 ecr 3833463674,nop,wscale 8], length 0
> > 10:17:12.697909 IP 10.24.12.10.52362 > 91.189.95.83.80: Flags [R],
> > seq 1465797257, win 0, length 0
> >
> >
> >
> >
> > I can emulate the DNS lookup using netcat in the vrf:
> >
> >
> > sudo ip vrf exec mgmt-vrf nc -u 10.24.65.203 53
> >
> >
> > then interactively enter the binary for a www.google.co.uk request:
> >
> >
> > 0035624be394010000010000000000010377777706676f6f676c6502636f02756b00
> > 000100010000290200000000000000
> >
> >
> > This returns as expected:
> >
> >
> > 00624be394010000010000000000010377777706676f6f676c6502636f02756b0000
> > 0100010000290200000000000000
> >
> >
> > I can run:
> >
> >
> > Admin@NETM06:~$ host www.google.co.uk
www.google.co.uk has address
> > 172.217.169.3 www.google.co.uk has IPv6 address
> > 2a00:1450:4009:80d::2003
> >
> >
> > but I get a timeout for:
> >
> >
> > sudo ip vrf exec mgmt-vrf host www.google.co.uk ;; connection timed
> > out; no servers could be reached
> >
> >
> >
> > However I can take a repo address and vrf exec to it on port 80:
> >
> >
> > Admin@NETM06:~$ sudo ip vrf exec mgmt-vrf nc 91.189.91.23 80 hello
> > HTTP/1.1 400 Bad Request
> > <OUTPUT OMITTED>
> >
> > My iptables rule:
> >
> >
> > sudo iptables -Z
> > Admin@NETM06:~$ sudo iptables -L -v
> > Chain INPUT (policy DROP 16 packets, 3592 bytes)
> > pkts bytes target prot opt in out source destination
> > 44 2360 ACCEPT tcp -- any any anywhere anywhere tcp spt:http ctstate RELATED,ESTABLISHED
> > 83 10243 ACCEPT udp -- any any anywhere anywhere udp spt:domain ctstate RELATED,ESTABLISHED
> >
> >
> >
> > I cannot find out why the update isn’t working. Any help greatly
> > appreciated
> >
> >
> > Kind Regards,
> >
> >
> > Gareth
^ permalink raw reply
* Re: [PATCH net-next v2 1/3] net: dsa: microchip: add KSZ9477 I2C driver
From: Andrew Lunn @ 2019-09-10 14:03 UTC (permalink / raw)
To: George McCollister
Cc: netdev, Woojung Huh, Florian Fainelli, Tristram Ha,
David S. Miller, Marek Vasut, linux-kernel
In-Reply-To: <20190910131836.114058-2-george.mccollister@gmail.com>
Hi George
> +KSZ_REGMAP_TABLE(ksz9477, not_used, 16, 0, 0);
> +
> @@ -294,6 +294,8 @@ static inline void ksz_pwrite32(struct ksz_device *dev, int port, int offset,
> #define KSZ_SPI_OP_RD 3
> #define KSZ_SPI_OP_WR 2
>
> +#define swabnot_used(x) 0
> +
> #define KSZ_SPI_OP_FLAG_MASK(opcode, swp, regbits, regpad) \
> swab##swp((opcode) << ((regbits) + (regpad)))
There seems to be quite a lot of macro magic here which is not
obvious. Can this be simplified or made more obvious?
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] net: stmmac: Only enable enhanced addressing mode when needed
From: Thierry Reding @ 2019-09-10 13:54 UTC (permalink / raw)
To: Jose Abreu
Cc: David S . Miller, Giuseppe Cavallaro, Alexandre Torgue,
Jon Hunter, Bitan Biswas, netdev@vger.kernel.org,
linux-tegra@vger.kernel.org
In-Reply-To: <BN8PR12MB3266850280A788D41C277B08D3B60@BN8PR12MB3266.namprd12.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]
On Tue, Sep 10, 2019 at 08:32:38AM +0000, Jose Abreu wrote:
> From: Thierry Reding <thierry.reding@gmail.com>
> Date: Sep/09/2019, 20:11:27 (UTC+00:00)
>
> > On Mon, Sep 09, 2019 at 04:07:04PM +0000, Jose Abreu wrote:
> > > From: Thierry Reding <thierry.reding@gmail.com>
> > > Date: Sep/09/2019, 16:25:45 (UTC+00:00)
> > >
> > > > @@ -92,6 +92,7 @@ struct stmmac_dma_cfg {
> > > > int fixed_burst;
> > > > int mixed_burst;
> > > > bool aal;
> > > > + bool eame;
> > >
> > > bools should not be used in struct's, please change to int.
> >
> > Huh? Since when? "aal" right above it is also bool. Can you provide a
> > specific rationale for why we shouldn't use bool in structs?
>
> Please see https://lkml.org/lkml/2017/11/21/384.
The context is slightly different here. stmmac_dma_cfg exists once for
each of these ethernet devices in the system, and I would assume that in
the vast majority of cases there's exactly one such device in the system
so the potential size increase is very small. On the other hand, there
are potentially very many struct sched_dl_entity, so the size impact is
multiplied.
Anyway, if you insist I'll rewrite this to use an unsigned int bitfield.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 3/4] virtio: introudce a mdev based transport
From: Michael S. Tsirkin @ 2019-09-10 13:52 UTC (permalink / raw)
To: Jason Wang
Cc: kvm, virtualization, netdev, linux-kernel, kwankhede,
alex.williamson, cohuck, tiwei.bie, maxime.coquelin,
cunming.liang, zhihong.wang, rob.miller, idos, xiao.w.wang,
haotian.wang
In-Reply-To: <572ffc34-3081-8503-d3cc-192edc9b5311@redhat.com>
On Tue, Sep 10, 2019 at 09:13:02PM +0800, Jason Wang wrote:
>
> On 2019/9/10 下午6:01, Michael S. Tsirkin wrote:
> > > +#ifndef _LINUX_VIRTIO_MDEV_H
> > > +#define _LINUX_VIRTIO_MDEV_H
> > > +
> > > +#include <linux/interrupt.h>
> > > +#include <linux/vringh.h>
> > > +#include <uapi/linux/virtio_net.h>
> > > +
> > > +/*
> > > + * Ioctls
> > > + */
> > Pls add a bit more content here. It's redundant to state these
> > are ioctls. Much better to document what does each one do.
>
>
> Ok.
>
>
> >
> > > +
> > > +struct virtio_mdev_callback {
> > > + irqreturn_t (*callback)(void *);
> > > + void *private;
> > > +};
> > > +
> > > +#define VIRTIO_MDEV 0xAF
> > > +#define VIRTIO_MDEV_SET_VQ_CALLBACK _IOW(VIRTIO_MDEV, 0x00, \
> > > + struct virtio_mdev_callback)
> > > +#define VIRTIO_MDEV_SET_CONFIG_CALLBACK _IOW(VIRTIO_MDEV, 0x01, \
> > > + struct virtio_mdev_callback)
> > Function pointer in an ioctl parameter? How does this ever make sense?
>
>
> I admit this is hacky (casting).
>
>
> > And can't we use a couple of registers for this, and avoid ioctls?
>
>
> Yes, how about something like interrupt numbers for each virtqueue and
> config?
Should we just reuse VIRTIO_PCI_COMMON_Q_XXX then?
>
> >
> > > +
> > > +#define VIRTIO_MDEV_DEVICE_API_STRING "virtio-mdev"
> > > +
> > > +/*
> > > + * Control registers
> > > + */
> > > +
> > > +/* Magic value ("virt" string) - Read Only */
> > > +#define VIRTIO_MDEV_MAGIC_VALUE 0x000
> > > +
> > > +/* Virtio device version - Read Only */
> > > +#define VIRTIO_MDEV_VERSION 0x004
> > > +
> > > +/* Virtio device ID - Read Only */
> > > +#define VIRTIO_MDEV_DEVICE_ID 0x008
> > > +
> > > +/* Virtio vendor ID - Read Only */
> > > +#define VIRTIO_MDEV_VENDOR_ID 0x00c
> > > +
> > > +/* Bitmask of the features supported by the device (host)
> > > + * (32 bits per set) - Read Only */
> > > +#define VIRTIO_MDEV_DEVICE_FEATURES 0x010
> > > +
> > > +/* Device (host) features set selector - Write Only */
> > > +#define VIRTIO_MDEV_DEVICE_FEATURES_SEL 0x014
> > > +
> > > +/* Bitmask of features activated by the driver (guest)
> > > + * (32 bits per set) - Write Only */
> > > +#define VIRTIO_MDEV_DRIVER_FEATURES 0x020
> > > +
> > > +/* Activated features set selector - Write Only */
> > > +#define VIRTIO_MDEV_DRIVER_FEATURES_SEL 0x024
> > > +
> > > +/* Queue selector - Write Only */
> > > +#define VIRTIO_MDEV_QUEUE_SEL 0x030
> > > +
> > > +/* Maximum size of the currently selected queue - Read Only */
> > > +#define VIRTIO_MDEV_QUEUE_NUM_MAX 0x034
> > > +
> > > +/* Queue size for the currently selected queue - Write Only */
> > > +#define VIRTIO_MDEV_QUEUE_NUM 0x038
> > > +
> > > +/* Ready bit for the currently selected queue - Read Write */
> > > +#define VIRTIO_MDEV_QUEUE_READY 0x044
> > Is this same as started?
>
>
> Do you mean "status"?
I really meant "enabled", didn't remember the correct name.
As in: VIRTIO_PCI_COMMON_Q_ENABLE
>
> >
> > > +
> > > +/* Alignment of virtqueue - Read Only */
> > > +#define VIRTIO_MDEV_QUEUE_ALIGN 0x048
> > > +
> > > +/* Queue notifier - Write Only */
> > > +#define VIRTIO_MDEV_QUEUE_NOTIFY 0x050
> > > +
> > > +/* Device status register - Read Write */
> > > +#define VIRTIO_MDEV_STATUS 0x060
> > > +
> > > +/* Selected queue's Descriptor Table address, 64 bits in two halves */
> > > +#define VIRTIO_MDEV_QUEUE_DESC_LOW 0x080
> > > +#define VIRTIO_MDEV_QUEUE_DESC_HIGH 0x084
> > > +
> > > +/* Selected queue's Available Ring address, 64 bits in two halves */
> > > +#define VIRTIO_MDEV_QUEUE_AVAIL_LOW 0x090
> > > +#define VIRTIO_MDEV_QUEUE_AVAIL_HIGH 0x094
> > > +
> > > +/* Selected queue's Used Ring address, 64 bits in two halves */
> > > +#define VIRTIO_MDEV_QUEUE_USED_LOW 0x0a0
> > > +#define VIRTIO_MDEV_QUEUE_USED_HIGH 0x0a4
> > > +
> > > +/* Configuration atomicity value */
> > > +#define VIRTIO_MDEV_CONFIG_GENERATION 0x0fc
> > > +
> > > +/* The config space is defined by each driver as
> > > + * the per-driver configuration space - Read Write */
> > > +#define VIRTIO_MDEV_CONFIG 0x100
> > Mixing device and generic config space is what virtio pci did,
> > caused lots of problems with extensions.
> > It would be better to reserve much more space.
>
>
> I see, will do this.
>
> Thanks
>
>
> >
> >
> > > +
> > > +#endif
> > > +
> > > +
> > > +/* Ready bit for the currently selected queue - Read Write */
> > > --
> > > 2.19.1
^ permalink raw reply
* Re: [PATCH] ath9k: release allocated buffer if timed out
From: Kalle Valo @ 2019-09-10 13:32 UTC (permalink / raw)
To: Navid Emamdoost
In-Reply-To: <20190906185931.19288-1-navid.emamdoost@gmail.com>
Navid Emamdoost <navid.emamdoost@gmail.com> wrote:
> In ath9k_wmi_cmd, the allocated network buffer needs to be released
> if timeout happens. Otherwise memory will be leaked.
>
> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
728c1e2a05e4 ath9k: release allocated buffer if timed out
--
https://patchwork.kernel.org/patch/11135843/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath9k_htc: release allocated buffer if timed out
From: Kalle Valo @ 2019-09-10 13:29 UTC (permalink / raw)
To: Navid Emamdoost
In-Reply-To: <20190906182604.9282-1-navid.emamdoost@gmail.com>
Navid Emamdoost <navid.emamdoost@gmail.com> wrote:
> In htc_config_pipe_credits, htc_setup_complete, and htc_connect_service
> if time out happens, the allocated buffer needs to be released.
> Otherwise there will be memory leak.
>
> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
853acf7caf10 ath9k_htc: release allocated buffer if timed out
--
https://patchwork.kernel.org/patch/11135781/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath9k: Remove unneeded variable to store return value
From: Kalle Valo @ 2019-09-10 13:26 UTC (permalink / raw)
To: zhong jiang; +Cc: davem, linux-wireless, zhongjiang, netdev, linux-kernel
In-Reply-To: <1567579428-16377-1-git-send-email-zhongjiang@huawei.com>
zhong jiang <zhongjiang@huawei.com> wrote:
> ath9k_reg_rmw_single do not need return value to cope with different
> cases. And change functon return type to void.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
45f09a1c5b85 ath9k: Remove unneeded variable to store return value
--
https://patchwork.kernel.org/patch/11129449/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [RFC PATCH 4/4] docs: Sample driver to demonstrate how to implement virtio-mdev framework
From: Jason Wang @ 2019-09-10 13:22 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kvm, virtualization, netdev, linux-kernel, kwankhede,
alex.williamson, cohuck, tiwei.bie, maxime.coquelin,
cunming.liang, zhihong.wang, rob.miller, idos, xiao.w.wang,
haotian.wang
In-Reply-To: <20190910060531-mutt-send-email-mst@kernel.org>
On 2019/9/10 下午6:15, Michael S. Tsirkin wrote:
> On Tue, Sep 10, 2019 at 04:19:35PM +0800, Jason Wang wrote:
>> This sample driver creates mdev device that simulate virtio net device
>> over virtio mdev transport. The device is implemented through vringh
>> and workqueue.
>>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>> ---
>> samples/Kconfig | 7 +
>> samples/vfio-mdev/Makefile | 1 +
>> samples/vfio-mdev/mvnet.c | 766 +++++++++++++++++++++++++++++++++++++
>> 3 files changed, 774 insertions(+)
>> create mode 100644 samples/vfio-mdev/mvnet.c
> So for a POC, this is a bit too rough to be able to judge
> whether the approach is workable.
> Can you get it a bit more into shape esp wrt UAPI?
Will do, actually I'm not 100% sure it need to go through UAPI.
Technically we can expose them for userspace but do we want something
simpler e.g vhost? Then we can make it as an internal API without caring
about UAPI stuffs like compatibility etc.
Except for UAPI, another other thing that can help you to judge this
approach? E.g we can make the device more reasonable rather than a
simple loopback device, e.g implementing a pair network device. But it
might be too complex for just a sample.
>
>> diff --git a/samples/Kconfig b/samples/Kconfig
>> index c8dacb4dda80..a1a1ca2c00b7 100644
>> --- a/samples/Kconfig
>> +++ b/samples/Kconfig
>> @@ -131,6 +131,13 @@ config SAMPLE_VFIO_MDEV_MDPY
>> mediated device. It is a simple framebuffer and supports
>> the region display interface (VFIO_GFX_PLANE_TYPE_REGION).
>>
>> +config SAMPLE_VIRTIO_MDEV_NET
>> + tristate "Build virtio mdev net example mediated device sample code -- loadable modules only"
>> + depends on VIRTIO_MDEV_DEVICE && VHOST_RING && m
>> + help
>> + Build a networking sample device for use as a virtio
>> + mediated device.
>> +
>> config SAMPLE_VFIO_MDEV_MDPY_FB
>> tristate "Build VFIO mdpy example guest fbdev driver -- loadable module only"
>> depends on FB && m
>> diff --git a/samples/vfio-mdev/Makefile b/samples/vfio-mdev/Makefile
>> index 10d179c4fdeb..f34af90ed0a0 100644
>> --- a/samples/vfio-mdev/Makefile
>> +++ b/samples/vfio-mdev/Makefile
>> @@ -3,3 +3,4 @@ obj-$(CONFIG_SAMPLE_VFIO_MDEV_MTTY) += mtty.o
>> obj-$(CONFIG_SAMPLE_VFIO_MDEV_MDPY) += mdpy.o
>> obj-$(CONFIG_SAMPLE_VFIO_MDEV_MDPY_FB) += mdpy-fb.o
>> obj-$(CONFIG_SAMPLE_VFIO_MDEV_MBOCHS) += mbochs.o
>> +obj-$(CONFIG_SAMPLE_VIRTIO_MDEV_NET) += mvnet.o
>> diff --git a/samples/vfio-mdev/mvnet.c b/samples/vfio-mdev/mvnet.c
>> new file mode 100644
>> index 000000000000..da295b41955e
>> --- /dev/null
>> +++ b/samples/vfio-mdev/mvnet.c
>> @@ -0,0 +1,766 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Mediated virtual virtio-net device driver.
>> + *
>> + * Copyright (c) 2019, Red Hat Inc. All rights reserved.
>> + * Author: Jason Wang <jasowang@redhat.com>
>> + *
>> + * Sample driver
>
> Documentation on how to use this?
Will add.
>
>
>> that creates mdev device that simulates ethernet
>> + * device virtio mdev transport.
>
> Well not exactly. What it seems to do is short-circuit
> RX and TX rings.
Yes, a loopback device.
>
>> + */
>> +
>> +#include <linux/init.h>
>> +#include <linux/module.h>
>> +#include <linux/device.h>
>> +#include <linux/kernel.h>
>> +#include <linux/fs.h>
>> +#include <linux/poll.h>
>> +#include <linux/slab.h>
>> +#include <linux/sched.h>
>> +#include <linux/wait.h>
>> +#include <linux/uuid.h>
>> +#include <linux/iommu.h>
>> +#include <linux/sysfs.h>
>> +#include <linux/file.h>
>> +#include <linux/etherdevice.h>
>> +#include <linux/mdev.h>
>> +#include <uapi/linux/virtio_mdev.h>
>> +
>> +#define VERSION_STRING "0.1"
>> +#define DRIVER_AUTHOR "NVIDIA Corporation"
>> +
>> +#define MVNET_CLASS_NAME "mvnet"
>> +
>> +#define MVNET_NAME "mvnet"
>> +
>> +/*
>> + * Global Structures
>> + */
>> +
>> +static struct mvnet_dev {
>> + struct class *vd_class;
>> + struct idr vd_idr;
>> + struct device dev;
>> +} mvnet_dev;
>> +
>> +struct mvnet_virtqueue {
>> + struct vringh vring;
>> + struct vringh_kiov iov;
>> + unsigned short head;
>> + bool ready;
>> + u32 desc_addr_lo;
>> + u32 desc_addr_hi;
>> + u32 device_addr_lo;
>> + u32 device_addr_hi;
>> + u32 driver_addr_lo;
>> + u32 driver_addr_hi;
>> + u64 desc_addr;
>> + u64 device_addr;
>> + u64 driver_addr;
>> + void *private;
>> + irqreturn_t (*cb)(void *);
>> +};
>> +
>> +#define MVNET_QUEUE_ALIGN PAGE_SIZE
>> +#define MVNET_QUEUE_MAX 256
>> +#define MVNET_MAGIC_VALUE ('v' | 'i' << 8 | 'r' << 16 | 't' << 24)
>> +#define MVNET_VERSION 0x1 /* Implies virtio 1.0 */
>> +#define MVNET_DEVICE_ID 0x1 /* network card */
>> +#define MVNET_VENDOR_ID 0 /* is this correct ? */
>> +#define MVNET_DEVICE_FEATURES VIRTIO_F_VERSION_1
>> +
>> +u64 mvnet_features = (1ULL << VIRTIO_F_ANY_LAYOUT) |
>> + (1ULL << VIRTIO_F_VERSION_1) |
>> + (1ULL << VIRTIO_F_IOMMU_PLATFORM) ;
>> +
>> +/* State of each mdev device */
>> +struct mvnet_state {
>> + struct mvnet_virtqueue vqs[2];
>> + struct work_struct work;
>> + spinlock_t lock;
>> + struct mdev_device *mdev;
>> + struct virtio_net_config config;
>> + struct virtio_mdev_callback *cbs;
>> + void *buffer;
>> + u32 queue_sel;
>> + u32 driver_features_sel;
>> + u32 driver_features[2];
>> + u32 device_features_sel;
>> + u32 status;
>> + u32 generation;
>> + u32 num;
>> + struct list_head next;
>> +};
>> +
>> +static struct mutex mdev_list_lock;
>> +static struct list_head mdev_devices_list;
>> +
>> +static void mvnet_queue_ready(struct mvnet_state *mvnet, unsigned idx)
>> +{
>> + struct mvnet_virtqueue *vq = &mvnet->vqs[idx];
>> + int ret;
>> +
>> + vq->desc_addr = (u64)vq->desc_addr_hi << 32 | vq->desc_addr_lo;
>> + vq->device_addr = (u64)vq->device_addr_hi << 32 | vq->device_addr_lo;
>> + vq->driver_addr = (u64)vq->driver_addr_hi << 32 | vq->driver_addr_lo;
>> +
>> + ret = vringh_init_kern(&vq->vring, mvnet_features, MVNET_QUEUE_MAX,
>> + false, (struct vring_desc *)vq->desc_addr,
>> + (struct vring_avail *)vq->driver_addr,
>> + (struct vring_used *)vq->device_addr);
>> +}
>> +
>> +static ssize_t mvnet_read_config(struct mdev_device *mdev,
>> + u32 *val, loff_t pos)
>> +{
>> + struct mvnet_state *mvnet;
>> + struct mvnet_virtqueue *vq;
>> + u32 queue_sel;
>> +
>> + if (!mdev || !val)
>> + return -EINVAL;
>> +
>> + mvnet = mdev_get_drvdata(mdev);
>> + if (!mvnet) {
>> + pr_err("%s mvnet not found\n", __func__);
>> + return -EINVAL;
>> + }
>> +
>> + queue_sel = mvnet->queue_sel;
>> + vq = &mvnet->vqs[queue_sel];
>> +
>> + switch (pos) {
>> + case VIRTIO_MDEV_MAGIC_VALUE:
>> + *val = MVNET_MAGIC_VALUE;
>> + break;
>> + case VIRTIO_MDEV_VERSION:
>> + *val = MVNET_VERSION;
>> + break;
>> + case VIRTIO_MDEV_DEVICE_ID:
>> + *val = MVNET_DEVICE_ID;
>> + break;
>> + case VIRTIO_MDEV_VENDOR_ID:
>> + *val = MVNET_VENDOR_ID;
>> + break;
>> + case VIRTIO_MDEV_DEVICE_FEATURES:
>> + if (mvnet->device_features_sel)
>> + *val = mvnet_features >> 32;
>> + else
>> + *val = mvnet_features;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_NUM_MAX:
>> + *val = MVNET_QUEUE_MAX;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_READY:
>> + *val = vq->ready;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_ALIGN:
>> + *val = MVNET_QUEUE_ALIGN;
>> + break;
>> + case VIRTIO_MDEV_STATUS:
>> + *val = mvnet->status;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_DESC_LOW:
>> + *val = vq->desc_addr_lo;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_DESC_HIGH:
>> + *val = vq->desc_addr_hi;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_AVAIL_LOW:
>> + *val = vq->driver_addr_lo;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_AVAIL_HIGH:
>> + *val = vq->driver_addr_hi;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_USED_LOW:
>> + *val = vq->device_addr_lo;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_USED_HIGH:
>> + *val = vq->device_addr_hi;
>> + break;
>> + case VIRTIO_MDEV_CONFIG_GENERATION:
>> + *val = 1;
>> + break;
>> + default:
>> + pr_err("Unsupported mdev read offset at 0x%x\n", pos);
>> + break;
>> + }
>> +
>> + return 4;
>> +}
>> +
>> +static ssize_t mvnet_read_net_config(struct mdev_device *mdev,
>> + char *buf, size_t count, loff_t pos)
>> +{
>> + struct mvnet_state *mvnet = mdev_get_drvdata(mdev);
>> +
>> + if (!mvnet) {
>> + pr_err("%s mvnet not found\n", __func__);
>> + return -EINVAL;
>> + }
>> +
>> + if (pos + count > sizeof(mvnet->config))
>> + return -EINVAL;
>> +
>> + memcpy(buf, &mvnet->config + (unsigned)pos, count);
>> +
>> + return count;
>> +}
>> +
>> +static void mvnet_vq_reset(struct mvnet_virtqueue *vq)
>> +{
>> + vq->ready = 0;
>> + vq->desc_addr_lo = vq->desc_addr_hi = 0;
>> + vq->device_addr_lo = vq->device_addr_hi = 0;
>> + vq->driver_addr_lo = vq->driver_addr_hi = 0;
>> + vq->desc_addr = 0;
>> + vq->driver_addr = 0;
>> + vq->device_addr = 0;
>> + vringh_init_kern(&vq->vring, mvnet_features, MVNET_QUEUE_MAX,
>> + false, 0, 0, 0);
>> +}
>> +
>> +static void mvnet_reset(struct mvnet_state *mvnet)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < 2; i++)
>> + mvnet_vq_reset(&mvnet->vqs[i]);
>> +
>> + mvnet->queue_sel = 0;
>> + mvnet->driver_features_sel = 0;
>> + mvnet->device_features_sel = 0;
>> + mvnet->status = 0;
>> + ++mvnet->generation;
>> +}
>> +
>> +static ssize_t mvnet_write_config(struct mdev_device *mdev,
>> + u32 *val, loff_t pos)
>> +{
>> + struct mvnet_state *mvnet;
>> + struct mvnet_virtqueue *vq;
>> + u32 queue_sel;
>> +
>> + if (!mdev || !val)
>> + return -EINVAL;
>> +
>> + mvnet = mdev_get_drvdata(mdev);
>> + if (!mvnet) {
>> + pr_err("%s mvnet not found\n", __func__);
>> + return -EINVAL;
>> + }
>> +
>> + queue_sel = mvnet->queue_sel;
>> + vq = &mvnet->vqs[queue_sel];
>> +
>> + switch (pos) {
>> + case VIRTIO_MDEV_DEVICE_FEATURES_SEL:
>> + mvnet->device_features_sel = *val;
>> + break;
>> + case VIRTIO_MDEV_DRIVER_FEATURES:
>> + mvnet->driver_features[mvnet->driver_features_sel] = *val;
>> + break;
>> + case VIRTIO_MDEV_DRIVER_FEATURES_SEL:
>> + mvnet->driver_features_sel = *val;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_SEL:
>> + mvnet->queue_sel = *val;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_NUM:
>> + mvnet->num = *val;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_READY:
>> + vq->ready = *val;
>> + if (vq->ready) {
>> + spin_lock(&mvnet->lock);
>> + mvnet_queue_ready(mvnet, queue_sel);
>> + spin_unlock(&mvnet->lock);
>> + }
>> + break;
>> + case VIRTIO_MDEV_QUEUE_NOTIFY:
>> + if (vq->ready)
>> + schedule_work(&mvnet->work);
>> + break;
>> + case VIRTIO_MDEV_STATUS:
>> + mvnet->status = *val;
>> + if (*val == 0) {
>> + spin_lock(&mvnet->lock);
>> + mvnet_reset(mvnet);
>> + spin_unlock(&mvnet->lock);
>> + }
>> + break;
>> + case VIRTIO_MDEV_QUEUE_DESC_LOW:
>> + vq->desc_addr_lo = *val;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_DESC_HIGH:
>> + vq->desc_addr_hi = *val;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_AVAIL_LOW:
>> + vq->driver_addr_lo = *val;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_AVAIL_HIGH:
>> + vq->driver_addr_hi = *val;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_USED_LOW:
>> + vq->device_addr_lo = *val;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_USED_HIGH:
>> + vq->device_addr_hi = *val;
>> + break;
>> + default:
>> + pr_err("Unsupported write offset! 0x%x\n", pos);
>> + break;
>> + }
>> + spin_unlock(&mvnet->lock);
>> +
>> + return 4;
>> +}
>> +
>> +static void mvnet_work(struct work_struct *work)
>> +{
>> + struct mvnet_state *mvnet = container_of(work, struct
>> + mvnet_state, work);
>> + struct mvnet_virtqueue *txq = &mvnet->vqs[1];
>> + struct mvnet_virtqueue *rxq = &mvnet->vqs[0];
>> + size_t read, write, total_write;
>> + unsigned long flags;
>> + int err;
>> + int pkts = 0;
>> +
>> + spin_lock(&mvnet->lock);
>> +
>> + if (!txq->ready || !rxq->ready)
>> + goto out;
>> +
>> + while (true) {
>> + total_write = 0;
>> + err = vringh_getdesc_kern(&txq->vring, &txq->iov, NULL,
>> + &txq->head, GFP_KERNEL);
>> + if (err <= 0)
>> + break;
>> +
>> + err = vringh_getdesc_kern(&rxq->vring, NULL, &rxq->iov,
>> + &rxq->head, GFP_KERNEL);
>
> GFP_KERNEL under a spin_lock will cause deadlocks.
Will fix.
>
>
>> + if (err <= 0) {
>> + vringh_complete_kern(&txq->vring, txq->head, 0);
>> + break;
>> + }
>> +
>> + while (true) {
>> + read = vringh_iov_pull_kern(&txq->iov, mvnet->buffer,
>> + PAGE_SIZE);
>> + if (read <= 0)
>> + break;
>> +
>> + write = vringh_iov_push_kern(&rxq->iov, mvnet->buffer,
>> + read);
>> + if (write <= 0)
>> + break;
>> +
>> + total_write += write;
>> + }
>> +
>> + /* Make sure data is wrote before advancing index */
>> + smp_wmb();
>> +
>> + vringh_complete_kern(&txq->vring, txq->head, 0);
>> + vringh_complete_kern(&rxq->vring, rxq->head, total_write);
>> +
>> + /* Make sure used is visible before rasing the
>> + interrupt */
>> + smp_wmb();
>> +
>> + local_bh_disable();
>> + if (txq->cb)
>> + txq->cb(txq->private);
>> + if (rxq->cb)
>> + rxq->cb(rxq->private);
>> + local_bh_enable();
>> +
>> + pkts ++;
> coding style problem
Will fix.
>
>> + if (pkts > 4) {
>> + schedule_work(&mvnet->work);
>> + goto out;
>> + }
>> + }
>> +
>> +out:
>> + spin_unlock(&mvnet->lock);
>> +}
>> +
>> +static dma_addr_t mvnet_map_page(struct device *dev, struct page *page,
>> + unsigned long offset, size_t size,
>> + enum dma_data_direction dir,
>> + unsigned long attrs)
>> +{
>> + /* Vringh can only use VA */
>> + return page_address(page) + offset;
>> +}
>> +
>> +static void mvnet_unmap_page(struct device *dev, dma_addr_t dma_addr,
>> + size_t size, enum dma_data_direction dir,
>> + unsigned long attrs)
>> +{
>> + return ;
>> +}
>> +
>> +static void *mvnet_alloc_coherent(struct device *dev, size_t size,
>> + dma_addr_t *dma_addr, gfp_t flag,
>> + unsigned long attrs)
>> +{
>> + void *ret = kmalloc(size, flag);
>> +
>> + if (ret == NULL)
> !ret is nicer
Yes.
>
>> + *dma_addr = DMA_MAPPING_ERROR;
>> + else
>> + *dma_addr = ret;
> Not sure how does this build ... don't we need a cast?
It builds but will fix for sure.
>
>> +
>> + return ret;
>> +}
>> +
>> +static void mvnet_free_coherent(struct device *dev, size_t size,
>> + void *vaddr, dma_addr_t dma_addr,
>> + unsigned long attrs)
>> +{
>> + kfree(dma_addr);
>> +}
>> +
>> +static const struct dma_map_ops mvnet_dma_ops = {
>> + .map_page = mvnet_map_page,
>> + .unmap_page = mvnet_unmap_page,
>> + .alloc = mvnet_alloc_coherent,
>> + .free = mvnet_free_coherent,
>> +};
>> +
>> +static int mvnet_create(struct kobject *kobj, struct mdev_device *mdev)
>> +{
>> + struct mvnet_state *mvnet;
>> + struct virtio_net_config *config;
>> +
>> + if (!mdev)
>> + return -EINVAL;
>> +
>> + mvnet = kzalloc(sizeof(struct mvnet_state), GFP_KERNEL);
>> + if (mvnet == NULL)
>> + return -ENOMEM;
>> +
>> + mvnet->buffer = kmalloc(PAGE_SIZE, GFP_KERNEL);
>> + if (!mvnet->buffer) {
>> + kfree(mvnet);
>> + return -ENOMEM;
>> + }
>> +
>> + config = &mvnet->config;
>> + config->mtu = 1500;
>> + config->status = VIRTIO_NET_S_LINK_UP;
>> + eth_random_addr(config->mac);
>> +
>> + INIT_WORK(&mvnet->work, mvnet_work);
>> +
>> + spin_lock_init(&mvnet->lock);
>> + mvnet->mdev = mdev;
>> + mdev_set_drvdata(mdev, mvnet);
>> +
>> + mutex_lock(&mdev_list_lock);
>> + list_add(&mvnet->next, &mdev_devices_list);
>> + mutex_unlock(&mdev_list_lock);
>> +
>> + mdev_set_dma_ops(mdev, &mvnet_dma_ops);
>> +
>> + return 0;
>> +}
>> +
>> +static int mvnet_remove(struct mdev_device *mdev)
>> +{
>> + struct mvnet_state *mds, *tmp_mds;
>> + struct mvnet_state *mvnet = mdev_get_drvdata(mdev);
>> + int ret = -EINVAL;
>> +
>> + mutex_lock(&mdev_list_lock);
>> + list_for_each_entry_safe(mds, tmp_mds, &mdev_devices_list, next) {
>> + if (mvnet == mds) {
>> + list_del(&mvnet->next);
>> + mdev_set_drvdata(mdev, NULL);
>> + kfree(mvnet->buffer);
>> + kfree(mvnet);
>> + ret = 0;
>> + break;
>> + }
>> + }
>> + mutex_unlock(&mdev_list_lock);
>> +
>> + return ret;
>> +}
>> +
>> +static ssize_t mvnet_read(struct mdev_device *mdev, char __user *buf,
>> + size_t count, loff_t *ppos)
>> +{
>> + ssize_t ret;
>> +
>> + if (*ppos < VIRTIO_MDEV_CONFIG) {
>> + if (count == 4)
>> + ret = mvnet_read_config(mdev, (u32 *)buf, *ppos);
>> + else
>> + ret = -EINVAL;
>> + *ppos += 4;
>> + } else if (*ppos < VIRTIO_MDEV_CONFIG + sizeof(struct virtio_net_config)) {
>> + ret = mvnet_read_net_config(mdev, buf, count,
>> + *ppos - VIRTIO_MDEV_CONFIG);
>> + *ppos += count;
>> + } else {
>> + ret = -EINVAL;
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +static ssize_t mvnet_write(struct mdev_device *mdev, const char __user *buf,
>> + size_t count, loff_t *ppos)
>> +{
>> + int ret;
>> +
>> + if (*ppos < VIRTIO_MDEV_CONFIG) {
>> + if (count == 4)
>> + ret = mvnet_write_config(mdev, (u32 *)buf, *ppos);
>> + else
>> + ret = -EINVAL;
>> + *ppos += 4;
>> + } else {
>> + /* No writable net config */
>> + ret = -EINVAL;
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +static long mvnet_ioctl(struct mdev_device *mdev, unsigned int cmd,
>> + unsigned long arg)
>> +{
>> + int ret = 0;
>> + struct mvnet_state *mvnet;
>> + struct virtio_mdev_callback *cb;
>> +
>> + if (!mdev)
>> + return -EINVAL;
>> +
>> + mvnet = mdev_get_drvdata(mdev);
>> + if (!mvnet)
>> + return -ENODEV;
>> +
>> + spin_lock(&mvnet->lock);
>> +
>> + switch (cmd) {
>> + case VIRTIO_MDEV_SET_VQ_CALLBACK:
>> + cb = (struct virtio_mdev_callback *)arg;
>> + mvnet->vqs[mvnet->queue_sel].cb = cb->callback;
>> + mvnet->vqs[mvnet->queue_sel].private = cb->private;
>> + break;
>> + case VIRTIO_MDEV_SET_CONFIG_CALLBACK:
>> + break;
> success, but nothing happens.
Because the device never raise any config interrupt.
>
>> + default:
>> + pr_err("Not supportted ioctl cmd 0x%x\n", cmd);
>> + ret = -ENOTTY;
>> + break;
>> + }
>> +
>> + spin_unlock(&mvnet->lock);
>> +
>> + return ret;
>> +}
>> +
>> +static int mvnet_open(struct mdev_device *mdev)
>> +{
>> + pr_info("%s\n", __func__);
>> + return 0;
>> +}
>> +
>> +static void mvnet_close(struct mdev_device *mdev)
>> +{
>> + pr_info("%s\n", __func__);
>> +}
>> +
>> +static ssize_t
>> +sample_mvnet_dev_show(struct device *dev, struct device_attribute *attr,
>> + char *buf)
>> +{
>> + return sprintf(buf, "This is phy device\n");
>
> what's this?
Will remove, copy&paste error from mtty.c.
>
>> +}
>> +
>> +static DEVICE_ATTR_RO(sample_mvnet_dev);
>> +
>> +static struct attribute *mvnet_dev_attrs[] = {
>> + &dev_attr_sample_mvnet_dev.attr,
>> + NULL,
>> +};
>> +
>> +static const struct attribute_group mvnet_dev_group = {
>> + .name = "mvnet_dev",
>> + .attrs = mvnet_dev_attrs,
>> +};
>> +
>> +static const struct attribute_group *mvnet_dev_groups[] = {
>> + &mvnet_dev_group,
>> + NULL,
>> +};
>> +
>> +static ssize_t
>> +sample_mdev_dev_show(struct device *dev, struct device_attribute *attr,
>> + char *buf)
>> +{
>> + if (mdev_from_dev(dev))
>> + return sprintf(buf, "This is MDEV %s\n", dev_name(dev));
>> +
>> + return sprintf(buf, "\n");
>> +}
>> +
>> +static DEVICE_ATTR_RO(sample_mdev_dev);
>> +
>> +static struct attribute *mdev_dev_attrs[] = {
>> + &dev_attr_sample_mdev_dev.attr,
>> + NULL,
>> +};
>> +
>> +static const struct attribute_group mdev_dev_group = {
>> + .name = "vendor",
>> + .attrs = mdev_dev_attrs,
>> +};
>> +
>> +static const struct attribute_group *mdev_dev_groups[] = {
>> + &mdev_dev_group,
>> + NULL,
>> +};
>> +
>> +#define MVNET_STRING_LEN 16
>> +
>> +static ssize_t
>> +name_show(struct kobject *kobj, struct device *dev, char *buf)
>> +{
>> + char name[MVNET_STRING_LEN];
>> + const char *name_str = "virtio-net";
>> +
>> + snprintf(name, MVNET_STRING_LEN, "%s", dev_driver_string(dev));
>> + if (!strcmp(kobj->name, name))
>> + return sprintf(buf, "%s\n", name_str);
>> +
>> + return -EINVAL;
>> +}
>> +
>> +static MDEV_TYPE_ATTR_RO(name);
>> +
>> +static ssize_t
>> +available_instances_show(struct kobject *kobj, struct device *dev, char *buf)
>> +{
>> + return sprintf(buf, "%d\n", INT_MAX);
>> +}
>> +
>> +static MDEV_TYPE_ATTR_RO(available_instances);
>
> ?
It used to demonstrate how many available instances that could be
created for this device. We don't have such limitation for software.
Thanks
>
>> +
>> +static ssize_t device_api_show(struct kobject *kobj, struct device *dev,
>> + char *buf)
>> +{
>> + return sprintf(buf, "%s\n", VIRTIO_MDEV_DEVICE_API_STRING);
>> +}
>> +
>> +static MDEV_TYPE_ATTR_RO(device_api);
>> +
>> +static struct attribute *mdev_types_attrs[] = {
>> + &mdev_type_attr_name.attr,
>> + &mdev_type_attr_device_api.attr,
>> + &mdev_type_attr_available_instances.attr,
>> + NULL,
>> +};
>> +
>> +static struct attribute_group mdev_type_group = {
>> + .name = "",
>> + .attrs = mdev_types_attrs,
>> +};
>> +
>> +static struct attribute_group *mdev_type_groups[] = {
>> + &mdev_type_group,
>> + NULL,
>> +};
>> +
>> +static const struct mdev_parent_ops mdev_fops = {
>> + .owner = THIS_MODULE,
>> + .dev_attr_groups = mvnet_dev_groups,
>> + .mdev_attr_groups = mdev_dev_groups,
>> + .supported_type_groups = mdev_type_groups,
>> + .create = mvnet_create,
>> + .remove = mvnet_remove,
>> + .open = mvnet_open,
>> + .release = mvnet_close,
>> + .read = mvnet_read,
>> + .write = mvnet_write,
>> + .ioctl = mvnet_ioctl,
>> +};
>> +
>> +static void mvnet_device_release(struct device *dev)
>> +{
>> + dev_dbg(dev, "mvnet: released\n");
>> +}
>> +
>> +static int __init mvnet_dev_init(void)
>> +{
>> + int ret = 0;
>> +
>> + pr_info("mvnet_dev: %s\n", __func__);
>> +
>> + memset(&mvnet_dev, 0, sizeof(mvnet_dev));
>> +
>> + idr_init(&mvnet_dev.vd_idr);
>> +
>> + mvnet_dev.vd_class = class_create(THIS_MODULE, MVNET_CLASS_NAME);
>> +
>> + if (IS_ERR(mvnet_dev.vd_class)) {
>> + pr_err("Error: failed to register mvnet_dev class\n");
>> + ret = PTR_ERR(mvnet_dev.vd_class);
>> + goto failed1;
>> + }
>> +
>> + mvnet_dev.dev.class = mvnet_dev.vd_class;
>> + mvnet_dev.dev.release = mvnet_device_release;
>> + dev_set_name(&mvnet_dev.dev, "%s", MVNET_NAME);
>> +
>> + ret = device_register(&mvnet_dev.dev);
>> + if (ret)
>> + goto failed2;
>> +
>> + ret = mdev_register_device(&mvnet_dev.dev, &mdev_fops);
>> + if (ret)
>> + goto failed3;
>> +
>> + mutex_init(&mdev_list_lock);
>> + INIT_LIST_HEAD(&mdev_devices_list);
>> +
>> + goto all_done;
>> +
>> +failed3:
>> +
>> + device_unregister(&mvnet_dev.dev);
>> +failed2:
>> + class_destroy(mvnet_dev.vd_class);
>> +
>> +failed1:
>> +all_done:
>> + return ret;
>> +}
>> +
>> +static void __exit mvnet_dev_exit(void)
>> +{
>> + mvnet_dev.dev.bus = NULL;
>> + mdev_unregister_device(&mvnet_dev.dev);
>> +
>> + device_unregister(&mvnet_dev.dev);
>> + idr_destroy(&mvnet_dev.vd_idr);
>> + class_destroy(mvnet_dev.vd_class);
>> + mvnet_dev.vd_class = NULL;
>> + pr_info("mvnet_dev: Unloaded!\n");
>> +}
>> +
>> +module_init(mvnet_dev_init)
>> +module_exit(mvnet_dev_exit)
>> +
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_INFO(supported, "Test driver that simulate serial port over PCI");
>> +MODULE_VERSION(VERSION_STRING);
>> +MODULE_AUTHOR(DRIVER_AUTHOR);
>> --
>> 2.19.1
^ permalink raw reply
* RE: [PATCH net-next 5/5] sctp: add spt_pathcpthld in struct sctp_paddrthlds
From: David Laight @ 2019-09-10 13:19 UTC (permalink / raw)
To: 'Xin Long', network dev, linux-sctp@vger.kernel.org
Cc: Marcelo Ricardo Leitner, Neil Horman, davem@davemloft.net
In-Reply-To: <604e6ac718c29aa5b1a8c4b164a126b82bc42a2f.1568015756.git.lucien.xin@gmail.com>
From: Xin Long
> Sent: 09 September 2019 08:57
> Section 7.2 of rfc7829: "Peer Address Thresholds (SCTP_PEER_ADDR_THLDS)
> Socket Option" extends 'struct sctp_paddrthlds' with 'spt_pathcpthld'
> added to allow a user to change ps_retrans per sock/asoc/transport, as
> other 2 paddrthlds: pf_retrans, pathmaxrxt.
>
> Note that ps_retrans is not allowed to be greater than pf_retrans.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> include/uapi/linux/sctp.h | 1 +
> net/sctp/socket.c | 10 ++++++++++
> 2 files changed, 11 insertions(+)
>
> diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
> index a15cc28..dfd81e1 100644
> --- a/include/uapi/linux/sctp.h
> +++ b/include/uapi/linux/sctp.h
> @@ -1069,6 +1069,7 @@ struct sctp_paddrthlds {
> struct sockaddr_storage spt_address;
> __u16 spt_pathmaxrxt;
> __u16 spt_pathpfthld;
> + __u16 spt_pathcpthld;
> };
>
> /*
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 5e2098b..5b9774d 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -3954,6 +3954,9 @@ static int sctp_setsockopt_paddr_thresholds(struct sock *sk,
This code does:
if (optlen < sizeof(struct sctp_paddrthlds))
return -EINVAL;
So adding an extra field breaks existing application binaries
that use this option.
I've not checked the other patches or similar fubar.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* [PATCH net-next v2 3/3] net: dsa: microchip: remove NET_DSA_TAG_KSZ_COMMON
From: George McCollister @ 2019-09-10 13:18 UTC (permalink / raw)
To: netdev
Cc: Woojung Huh, Andrew Lunn, Florian Fainelli, Tristram Ha,
David S. Miller, Marek Vasut, linux-kernel, George McCollister
In-Reply-To: <20190910131836.114058-1-george.mccollister@gmail.com>
Remove the superfluous NET_DSA_TAG_KSZ_COMMON and just use the existing
NET_DSA_TAG_KSZ. Update the description to mention the three switch
families it supports. No functional change.
Signed-off-by: George McCollister <george.mccollister@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
---
Changes since v1:
- Added Reviewed-by.
net/dsa/Kconfig | 9 ++-------
net/dsa/Makefile | 2 +-
2 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig
index 2f69d4b53d46..29e2bd5cc5af 100644
--- a/net/dsa/Kconfig
+++ b/net/dsa/Kconfig
@@ -73,16 +73,11 @@ config NET_DSA_TAG_MTK
Say Y or M if you want to enable support for tagging frames for
Mediatek switches.
-config NET_DSA_TAG_KSZ_COMMON
- tristate
- default n
-
config NET_DSA_TAG_KSZ
- tristate "Tag driver for Microchip 9893 family of switches"
- select NET_DSA_TAG_KSZ_COMMON
+ tristate "Tag driver for Microchip 8795/9477/9893 families of switches"
help
Say Y if you want to enable support for tagging frames for the
- Microchip 9893 family of switches.
+ Microchip 8795/9477/9893 families of switches.
config NET_DSA_TAG_QCA
tristate "Tag driver for Qualcomm Atheros QCA8K switches"
diff --git a/net/dsa/Makefile b/net/dsa/Makefile
index c342f54715ba..2c6d286f0511 100644
--- a/net/dsa/Makefile
+++ b/net/dsa/Makefile
@@ -9,7 +9,7 @@ obj-$(CONFIG_NET_DSA_TAG_BRCM_COMMON) += tag_brcm.o
obj-$(CONFIG_NET_DSA_TAG_DSA) += tag_dsa.o
obj-$(CONFIG_NET_DSA_TAG_EDSA) += tag_edsa.o
obj-$(CONFIG_NET_DSA_TAG_GSWIP) += tag_gswip.o
-obj-$(CONFIG_NET_DSA_TAG_KSZ_COMMON) += tag_ksz.o
+obj-$(CONFIG_NET_DSA_TAG_KSZ) += tag_ksz.o
obj-$(CONFIG_NET_DSA_TAG_LAN9303) += tag_lan9303.o
obj-$(CONFIG_NET_DSA_TAG_MTK) += tag_mtk.o
obj-$(CONFIG_NET_DSA_TAG_QCA) += tag_qca.o
--
2.11.0
^ permalink raw reply related
* [PATCH net-next v2 2/3] net: dsa: microchip: add ksz9567 to ksz9477 driver
From: George McCollister @ 2019-09-10 13:18 UTC (permalink / raw)
To: netdev
Cc: Woojung Huh, Andrew Lunn, Florian Fainelli, Tristram Ha,
David S. Miller, Marek Vasut, linux-kernel, George McCollister
In-Reply-To: <20190910131836.114058-1-george.mccollister@gmail.com>
Add support for the KSZ9567 7-Port Gigabit Ethernet Switch to the
ksz9477 driver. The KSZ9567 supports both SPI and I2C. Oddly the
ksz9567 is already in the device tree binding documentation.
Signed-off-by: George McCollister <george.mccollister@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
---
Changes since v1:
- Added Reviewed-by.
drivers/net/dsa/microchip/ksz9477.c | 9 +++++++++
drivers/net/dsa/microchip/ksz9477_i2c.c | 1 +
drivers/net/dsa/microchip/ksz9477_spi.c | 1 +
3 files changed, 11 insertions(+)
diff --git a/drivers/net/dsa/microchip/ksz9477.c b/drivers/net/dsa/microchip/ksz9477.c
index 187be42de5f1..50ffc63d6231 100644
--- a/drivers/net/dsa/microchip/ksz9477.c
+++ b/drivers/net/dsa/microchip/ksz9477.c
@@ -1529,6 +1529,15 @@ static const struct ksz_chip_data ksz9477_switch_chips[] = {
.cpu_ports = 0x07, /* can be configured as cpu port */
.port_cnt = 3, /* total port count */
},
+ {
+ .chip_id = 0x00956700,
+ .dev_name = "KSZ9567",
+ .num_vlans = 4096,
+ .num_alus = 4096,
+ .num_statics = 16,
+ .cpu_ports = 0x7F, /* can be configured as cpu port */
+ .port_cnt = 7, /* total physical port count */
+ },
};
static int ksz9477_switch_init(struct ksz_device *dev)
diff --git a/drivers/net/dsa/microchip/ksz9477_i2c.c b/drivers/net/dsa/microchip/ksz9477_i2c.c
index 79867cc2474b..0b1e01f0873d 100644
--- a/drivers/net/dsa/microchip/ksz9477_i2c.c
+++ b/drivers/net/dsa/microchip/ksz9477_i2c.c
@@ -77,6 +77,7 @@ MODULE_DEVICE_TABLE(i2c, ksz9477_i2c_id);
static const struct of_device_id ksz9477_dt_ids[] = {
{ .compatible = "microchip,ksz9477" },
{ .compatible = "microchip,ksz9897" },
+ { .compatible = "microchip,ksz9567" },
{},
};
MODULE_DEVICE_TABLE(of, ksz9477_dt_ids);
diff --git a/drivers/net/dsa/microchip/ksz9477_spi.c b/drivers/net/dsa/microchip/ksz9477_spi.c
index 2e402e4d866f..f4198d6f72be 100644
--- a/drivers/net/dsa/microchip/ksz9477_spi.c
+++ b/drivers/net/dsa/microchip/ksz9477_spi.c
@@ -81,6 +81,7 @@ static const struct of_device_id ksz9477_dt_ids[] = {
{ .compatible = "microchip,ksz9893" },
{ .compatible = "microchip,ksz9563" },
{ .compatible = "microchip,ksz8563" },
+ { .compatible = "microchip,ksz9567" },
{},
};
MODULE_DEVICE_TABLE(of, ksz9477_dt_ids);
--
2.11.0
^ permalink raw reply related
* [PATCH net-next v2 1/3] net: dsa: microchip: add KSZ9477 I2C driver
From: George McCollister @ 2019-09-10 13:18 UTC (permalink / raw)
To: netdev
Cc: Woojung Huh, Andrew Lunn, Florian Fainelli, Tristram Ha,
David S. Miller, Marek Vasut, linux-kernel, George McCollister
In-Reply-To: <20190910131836.114058-1-george.mccollister@gmail.com>
From: Tristram Ha <Tristram.Ha@microchip.com>
Add KSZ9477 I2C driver support. The code ksz9477.c and ksz_common.c are
used together to generate the I2C driver.
Signed-off-by: Tristram Ha <Tristram.Ha@microchip.com>
[george.mccollister@gmail.com: bring up to date, use ksz_common regmap macros]
Signed-off-by: George McCollister <george.mccollister@gmail.com>
---
Changes since v1:
- Adjust order of includes so they are in alphabetical order.
drivers/net/dsa/microchip/Kconfig | 7 +++
drivers/net/dsa/microchip/Makefile | 1 +
drivers/net/dsa/microchip/ksz9477_i2c.c | 100 ++++++++++++++++++++++++++++++++
drivers/net/dsa/microchip/ksz_common.h | 2 +
4 files changed, 110 insertions(+)
create mode 100644 drivers/net/dsa/microchip/ksz9477_i2c.c
diff --git a/drivers/net/dsa/microchip/Kconfig b/drivers/net/dsa/microchip/Kconfig
index e1c23d1e91e6..1d7870c6df3c 100644
--- a/drivers/net/dsa/microchip/Kconfig
+++ b/drivers/net/dsa/microchip/Kconfig
@@ -9,6 +9,13 @@ menuconfig NET_DSA_MICROCHIP_KSZ9477
help
This driver adds support for Microchip KSZ9477 switch chips.
+config NET_DSA_MICROCHIP_KSZ9477_I2C
+ tristate "KSZ9477 series I2C connected switch driver"
+ depends on NET_DSA_MICROCHIP_KSZ9477 && I2C
+ select REGMAP_I2C
+ help
+ Select to enable support for registering switches configured through I2C.
+
config NET_DSA_MICROCHIP_KSZ9477_SPI
tristate "KSZ9477 series SPI connected switch driver"
depends on NET_DSA_MICROCHIP_KSZ9477 && SPI
diff --git a/drivers/net/dsa/microchip/Makefile b/drivers/net/dsa/microchip/Makefile
index e3d799b95d7d..929caa81e782 100644
--- a/drivers/net/dsa/microchip/Makefile
+++ b/drivers/net/dsa/microchip/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_NET_DSA_MICROCHIP_KSZ_COMMON) += ksz_common.o
obj-$(CONFIG_NET_DSA_MICROCHIP_KSZ9477) += ksz9477.o
+obj-$(CONFIG_NET_DSA_MICROCHIP_KSZ9477_I2C) += ksz9477_i2c.o
obj-$(CONFIG_NET_DSA_MICROCHIP_KSZ9477_SPI) += ksz9477_spi.o
obj-$(CONFIG_NET_DSA_MICROCHIP_KSZ8795) += ksz8795.o
obj-$(CONFIG_NET_DSA_MICROCHIP_KSZ8795_SPI) += ksz8795_spi.o
diff --git a/drivers/net/dsa/microchip/ksz9477_i2c.c b/drivers/net/dsa/microchip/ksz9477_i2c.c
new file mode 100644
index 000000000000..79867cc2474b
--- /dev/null
+++ b/drivers/net/dsa/microchip/ksz9477_i2c.c
@@ -0,0 +1,100 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Microchip KSZ9477 series register access through I2C
+ *
+ * Copyright (C) 2018-2019 Microchip Technology Inc.
+ */
+
+#include <linux/i2c.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+
+#include "ksz_common.h"
+
+KSZ_REGMAP_TABLE(ksz9477, not_used, 16, 0, 0);
+
+static int ksz9477_i2c_probe(struct i2c_client *i2c,
+ const struct i2c_device_id *i2c_id)
+{
+ struct ksz_device *dev;
+ int i, ret;
+
+ dev = ksz_switch_alloc(&i2c->dev, i2c);
+ if (!dev)
+ return -ENOMEM;
+
+ for (i = 0; i < ARRAY_SIZE(ksz9477_regmap_config); i++) {
+ dev->regmap[i] = devm_regmap_init_i2c(i2c,
+ &ksz9477_regmap_config[i]);
+ if (IS_ERR(dev->regmap[i])) {
+ ret = PTR_ERR(dev->regmap[i]);
+ dev_err(&i2c->dev,
+ "Failed to initialize regmap%i: %d\n",
+ ksz9477_regmap_config[i].val_bits, ret);
+ return ret;
+ }
+ }
+
+ if (i2c->dev.platform_data)
+ dev->pdata = i2c->dev.platform_data;
+
+ ret = ksz9477_switch_register(dev);
+
+ /* Main DSA driver may not be started yet. */
+ if (ret)
+ return ret;
+
+ i2c_set_clientdata(i2c, dev);
+
+ return 0;
+}
+
+static int ksz9477_i2c_remove(struct i2c_client *i2c)
+{
+ struct ksz_device *dev = i2c_get_clientdata(i2c);
+
+ ksz_switch_remove(dev);
+
+ return 0;
+}
+
+static void ksz9477_i2c_shutdown(struct i2c_client *i2c)
+{
+ struct ksz_device *dev = i2c_get_clientdata(i2c);
+
+ if (dev && dev->dev_ops->shutdown)
+ dev->dev_ops->shutdown(dev);
+}
+
+static const struct i2c_device_id ksz9477_i2c_id[] = {
+ { "ksz9477-switch", 0 },
+ {},
+};
+
+MODULE_DEVICE_TABLE(i2c, ksz9477_i2c_id);
+
+static const struct of_device_id ksz9477_dt_ids[] = {
+ { .compatible = "microchip,ksz9477" },
+ { .compatible = "microchip,ksz9897" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ksz9477_dt_ids);
+
+static struct i2c_driver ksz9477_i2c_driver = {
+ .driver = {
+ .name = "ksz9477-switch",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(ksz9477_dt_ids),
+ },
+ .probe = ksz9477_i2c_probe,
+ .remove = ksz9477_i2c_remove,
+ .shutdown = ksz9477_i2c_shutdown,
+ .id_table = ksz9477_i2c_id,
+};
+
+module_i2c_driver(ksz9477_i2c_driver);
+
+MODULE_AUTHOR("Tristram Ha <Tristram.Ha@microchip.com>");
+MODULE_DESCRIPTION("Microchip KSZ9477 Series Switch I2C access Driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/net/dsa/microchip/ksz_common.h b/drivers/net/dsa/microchip/ksz_common.h
index 13d027baaa8b..a24d8e61fbe7 100644
--- a/drivers/net/dsa/microchip/ksz_common.h
+++ b/drivers/net/dsa/microchip/ksz_common.h
@@ -294,6 +294,8 @@ static inline void ksz_pwrite32(struct ksz_device *dev, int port, int offset,
#define KSZ_SPI_OP_RD 3
#define KSZ_SPI_OP_WR 2
+#define swabnot_used(x) 0
+
#define KSZ_SPI_OP_FLAG_MASK(opcode, swp, regbits, regpad) \
swab##swp((opcode) << ((regbits) + (regpad)))
--
2.11.0
^ permalink raw reply related
* [PATCH net-next v2 0/3] add ksz9567 with I2C support to ksz9477 driver
From: George McCollister @ 2019-09-10 13:18 UTC (permalink / raw)
To: netdev
Cc: Woojung Huh, Andrew Lunn, Florian Fainelli, Tristram Ha,
David S. Miller, Marek Vasut, linux-kernel, George McCollister
Resurrect KSZ9477 I2C driver support patch originally sent to the list
by Tristram Ha and resolve outstanding issues. It now works as similarly to
the ksz9477 SPI driver as possible, using the same regmap macros.
Add support for ksz9567 to the ksz9477 driver (tested on a board with
ksz9567 connected via I2C).
Remove NET_DSA_TAG_KSZ_COMMON since it's not needed.
Changes since v1:
Put ksz9477_i2c.c includes in alphabetical order.
Added Reviewed-Bys.
George McCollister (2):
net: dsa: microchip: add ksz9567 to ksz9477 driver
net: dsa: microchip: remove NET_DSA_TAG_KSZ_COMMON
Tristram Ha (1):
net: dsa: microchip: add KSZ9477 I2C driver
drivers/net/dsa/microchip/Kconfig | 7 +++
drivers/net/dsa/microchip/Makefile | 1 +
drivers/net/dsa/microchip/ksz9477.c | 9 +++
drivers/net/dsa/microchip/ksz9477_i2c.c | 101 ++++++++++++++++++++++++++++++++
drivers/net/dsa/microchip/ksz9477_spi.c | 1 +
drivers/net/dsa/microchip/ksz_common.h | 2 +
net/dsa/Kconfig | 9 +--
net/dsa/Makefile | 2 +-
8 files changed, 124 insertions(+), 8 deletions(-)
create mode 100644 drivers/net/dsa/microchip/ksz9477_i2c.c
--
2.11.0
^ permalink raw reply
* Re: [RFC PATCH 3/4] virtio: introudce a mdev based transport
From: Jason Wang @ 2019-09-10 13:13 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kvm, virtualization, netdev, linux-kernel, kwankhede,
alex.williamson, cohuck, tiwei.bie, maxime.coquelin,
cunming.liang, zhihong.wang, rob.miller, idos, xiao.w.wang,
haotian.wang
In-Reply-To: <20190910055744-mutt-send-email-mst@kernel.org>
On 2019/9/10 下午6:01, Michael S. Tsirkin wrote:
>> +#ifndef _LINUX_VIRTIO_MDEV_H
>> +#define _LINUX_VIRTIO_MDEV_H
>> +
>> +#include <linux/interrupt.h>
>> +#include <linux/vringh.h>
>> +#include <uapi/linux/virtio_net.h>
>> +
>> +/*
>> + * Ioctls
>> + */
> Pls add a bit more content here. It's redundant to state these
> are ioctls. Much better to document what does each one do.
Ok.
>
>> +
>> +struct virtio_mdev_callback {
>> + irqreturn_t (*callback)(void *);
>> + void *private;
>> +};
>> +
>> +#define VIRTIO_MDEV 0xAF
>> +#define VIRTIO_MDEV_SET_VQ_CALLBACK _IOW(VIRTIO_MDEV, 0x00, \
>> + struct virtio_mdev_callback)
>> +#define VIRTIO_MDEV_SET_CONFIG_CALLBACK _IOW(VIRTIO_MDEV, 0x01, \
>> + struct virtio_mdev_callback)
> Function pointer in an ioctl parameter? How does this ever make sense?
I admit this is hacky (casting).
> And can't we use a couple of registers for this, and avoid ioctls?
Yes, how about something like interrupt numbers for each virtqueue and
config?
>
>> +
>> +#define VIRTIO_MDEV_DEVICE_API_STRING "virtio-mdev"
>> +
>> +/*
>> + * Control registers
>> + */
>> +
>> +/* Magic value ("virt" string) - Read Only */
>> +#define VIRTIO_MDEV_MAGIC_VALUE 0x000
>> +
>> +/* Virtio device version - Read Only */
>> +#define VIRTIO_MDEV_VERSION 0x004
>> +
>> +/* Virtio device ID - Read Only */
>> +#define VIRTIO_MDEV_DEVICE_ID 0x008
>> +
>> +/* Virtio vendor ID - Read Only */
>> +#define VIRTIO_MDEV_VENDOR_ID 0x00c
>> +
>> +/* Bitmask of the features supported by the device (host)
>> + * (32 bits per set) - Read Only */
>> +#define VIRTIO_MDEV_DEVICE_FEATURES 0x010
>> +
>> +/* Device (host) features set selector - Write Only */
>> +#define VIRTIO_MDEV_DEVICE_FEATURES_SEL 0x014
>> +
>> +/* Bitmask of features activated by the driver (guest)
>> + * (32 bits per set) - Write Only */
>> +#define VIRTIO_MDEV_DRIVER_FEATURES 0x020
>> +
>> +/* Activated features set selector - Write Only */
>> +#define VIRTIO_MDEV_DRIVER_FEATURES_SEL 0x024
>> +
>> +/* Queue selector - Write Only */
>> +#define VIRTIO_MDEV_QUEUE_SEL 0x030
>> +
>> +/* Maximum size of the currently selected queue - Read Only */
>> +#define VIRTIO_MDEV_QUEUE_NUM_MAX 0x034
>> +
>> +/* Queue size for the currently selected queue - Write Only */
>> +#define VIRTIO_MDEV_QUEUE_NUM 0x038
>> +
>> +/* Ready bit for the currently selected queue - Read Write */
>> +#define VIRTIO_MDEV_QUEUE_READY 0x044
> Is this same as started?
Do you mean "status"?
>
>> +
>> +/* Alignment of virtqueue - Read Only */
>> +#define VIRTIO_MDEV_QUEUE_ALIGN 0x048
>> +
>> +/* Queue notifier - Write Only */
>> +#define VIRTIO_MDEV_QUEUE_NOTIFY 0x050
>> +
>> +/* Device status register - Read Write */
>> +#define VIRTIO_MDEV_STATUS 0x060
>> +
>> +/* Selected queue's Descriptor Table address, 64 bits in two halves */
>> +#define VIRTIO_MDEV_QUEUE_DESC_LOW 0x080
>> +#define VIRTIO_MDEV_QUEUE_DESC_HIGH 0x084
>> +
>> +/* Selected queue's Available Ring address, 64 bits in two halves */
>> +#define VIRTIO_MDEV_QUEUE_AVAIL_LOW 0x090
>> +#define VIRTIO_MDEV_QUEUE_AVAIL_HIGH 0x094
>> +
>> +/* Selected queue's Used Ring address, 64 bits in two halves */
>> +#define VIRTIO_MDEV_QUEUE_USED_LOW 0x0a0
>> +#define VIRTIO_MDEV_QUEUE_USED_HIGH 0x0a4
>> +
>> +/* Configuration atomicity value */
>> +#define VIRTIO_MDEV_CONFIG_GENERATION 0x0fc
>> +
>> +/* The config space is defined by each driver as
>> + * the per-driver configuration space - Read Write */
>> +#define VIRTIO_MDEV_CONFIG 0x100
> Mixing device and generic config space is what virtio pci did,
> caused lots of problems with extensions.
> It would be better to reserve much more space.
I see, will do this.
Thanks
>
>
>> +
>> +#endif
>> +
>> +
>> +/* Ready bit for the currently selected queue - Read Write */
>> --
>> 2.19.1
^ permalink raw reply
* Re: [PATCH net-next 11/11] net: aquantia: add support for PIN funcs
From: kbuild test robot @ 2019-09-10 13:03 UTC (permalink / raw)
To: Igor Russkikh
Cc: kbuild-all, netdev@vger.kernel.org, richardcochran@gmail.com,
davem@davemloft.net, Egor Pomozov, Sergey Samoilenko,
Dmitry Bezrukov, Igor Russkikh, Nikita Danilov
In-Reply-To: <b3eeb5dd7d38dab79ded5f4b7cca2a84505c8fac.1568034880.git.igor.russkikh@aquantia.com>
[-- Attachment #1: Type: text/plain, Size: 958 bytes --]
Hi Igor,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Igor-Russkikh/net-aquantia-PTP-support-for-AQC-devices/20190909-233041
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-11) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
ERROR: "__udivdi3" [drivers/net/ethernet/aquantia/atlantic/atlantic.ko] undefined!
>> ERROR: "__umoddi3" [drivers/net/ethernet/aquantia/atlantic/atlantic.ko] undefined!
ERROR: "__divdi3" [drivers/net/ethernet/aquantia/atlantic/atlantic.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 69589 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] ethtool: implement Energy Detect Powerdown support via phy-tunable
From: Ardelean, Alexandru @ 2019-09-10 12:07 UTC (permalink / raw)
To: mkubecek@suse.cz, netdev@vger.kernel.org
Cc: andrew@lunn.ch, davem@davemloft.net, hkallweit1@gmail.com,
devicetree@vger.kernel.org, mark.rutland@arm.com,
linux-kernel@vger.kernel.org, f.fainelli@gmail.com,
robh+dt@kernel.org
In-Reply-To: <20190910080014.GC24779@unicorn.suse.cz>
On Tue, 2019-09-10 at 10:00 +0200, Michal Kubecek wrote:
> [External]
>
> On Mon, Sep 09, 2019 at 04:12:50PM +0300, Alexandru Ardelean wrote:
> > The `phy_tunable_id` has been named `ETHTOOL_PHY_EDPD` since it looks like
> > this feature is common across other PHYs (like EEE), and defining
> > `ETHTOOL_PHY_ENERGY_DETECT_POWER_DOWN` seems too long.
> >
> > The way EDPD works, is that the RX block is put to a lower power mode,
> > except for link-pulse detection circuits. The TX block is also put to low
> > power mode, but the PHY wakes-up periodically to send link pulses, to avoid
> > lock-ups in case the other side is also in EDPD mode.
> >
> > Currently, there are 2 PHY drivers that look like they could use this new
> > PHY tunable feature: the `adin` && `micrel` PHYs.
> >
> > The ADIN's datasheet mentions that TX pulses are at intervals of 1 second
> > default each, and they can be disabled. For the Micrel KSZ9031 PHY, the
> > datasheet does not mention whether they can be disabled, but mentions that
> > they can modified.
> >
> > The way this change is structured, is similar to the PHY tunable downshift
> > control:
> > * a `ETHTOOL_PHY_EDPD_DFLT_TX_INTERVAL` value is exposed to cover a default
> > TX interval; some PHYs could specify a certain value that makes sense
> > * `ETHTOOL_PHY_EDPD_NO_TX` would disable TX when EDPD is enabled
> > * `ETHTOOL_PHY_EDPD_DISABLE` will disable EDPD
> >
> > This should allow PHYs to:
> > * enable EDPD and not enable TX pulses (interval would be 0)
> > * enable EDPD and configure TX pulse interval; note that TX interval units
> > would be PHY specific; we could consider `seconds` as units, but it could
> > happen that some PHYs would be prefer milliseconds as a unit;
> > a maximum of 65533 units should be sufficient
>
> Sorry for missing the discussion on previous version but I don't really
> like the idea of leaving the choice of units to PHY. Both for manual
> setting and system configuration, it would be IMHO much more convenient
> to have the interpretation universal for all NICs.
>
I was also a bit uncertain/undecided here about letting PHYs decide units.
And I also wasn't sure what to propose.
Not proposing a unit now, would have allowed us to decide later based on what PHYs implement (generally) in the future.
I know that may make me look a bit lazy [for not proposing units in ethtool], but tbh it's more of lack-of-experience
with ethtool (or these APIs) evolve over time.
> Seconds as units seem too coarse and maximum of ~18 hours way too big.
> Milliseconds would be more practical from granularity point of view,
> would maximum of ~65 seconds be sufficient?
I think 65 seconds is more than enough.
I feel that, if you plug-in an eth cable and don't have a link in a minute, then it's not great (no matter how much of a
power-saver you are).
Actually, voicing out these units makes it simpler for a decision to go in favor for milliseconds.
So: thank you :)
Alex
>
> Michal Kubecek
>
> > * disable EDPD
> >
> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.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