* [PATCH 2/2] can: c_can: configurable amount of D_CAN RX objects
From: Andrejs Cainikovs @ 2019-02-08 13:17 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde, David S. Miller,
linux-can@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: Patrick Zysset
In-Reply-To: <20190208131738.27668-1-andrejs.cainikovs@netmodule.com>
Make number of D_CAN RX message objects configurable. This will allow
having bigger (or smaller) RX buffer instead of 50/50 split for RX/TX.
Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@netmodule.com>
---
drivers/net/can/c_can/Kconfig | 8 ++++++
drivers/net/can/c_can/c_can.c | 64 +++++++++++++++++++++++++++++--------------
drivers/net/can/c_can/c_can.h | 16 +++++------
3 files changed, 58 insertions(+), 30 deletions(-)
diff --git a/drivers/net/can/c_can/Kconfig b/drivers/net/can/c_can/Kconfig
index 6c1ada7291df..949d2d12d71e 100644
--- a/drivers/net/can/c_can/Kconfig
+++ b/drivers/net/can/c_can/Kconfig
@@ -32,4 +32,12 @@ config CAN_C_CAN_DCAN_64_MSG_OBJECTS
Enabling this option extends max D_CAN message objects up to
64.
+config CAN_C_CAN_DCAN_RX_MSG_OBJECTS
+ int "Specify amount of D_CAN RX message objects"
+ depends on CAN_C_CAN_DCAN_64_MSG_OBJECTS
+ default 32
+ ---help---
+ Use specific number of message objects for RX, instead of
+ 50/50 split between RX/TX.
+
endif
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 5d695b89b459..675bc223e222 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -208,6 +208,26 @@ static const struct can_bittiming_const c_can_bittiming_const = {
.brp_inc = 1,
};
+static inline u64 c_can_get_mask(int bits)
+{
+ return ((u64)1 << bits) - 1;
+}
+
+static inline int c_can_ffs64(u64 x)
+{
+ int b;
+
+ b = ffs(x);
+
+ if (!b) {
+ b = ffs(x >> 32);
+ if (b)
+ b += 32;
+ }
+
+ return b;
+}
+
static inline void c_can_pm_runtime_enable(const struct c_can_priv *priv)
{
if (priv->device)
@@ -695,24 +715,23 @@ static void c_can_do_tx(struct net_device *dev)
{
struct c_can_priv *priv = netdev_priv(dev);
struct net_device_stats *stats = &dev->stats;
- u32 idx, obj, pkts = 0, bytes = 0, pend, clr;
+ u32 idx, obj, pkts = 0, bytes = 0;
+ u64 pend, clr;
+ /* Mask interrupt pending bits */
+ pend = priv->read_reg32(priv, C_CAN_INTPND1_REG);
#ifdef CONFIG_CAN_C_CAN_DCAN_64_MSG_OBJECTS
if (priv->type == BOSCH_D_CAN) {
- pend = priv->read_reg32(priv, C_CAN_INTPND3_REG);
- } else {
-#endif
- pend = priv->read_reg(priv, C_CAN_INTPND2_REG);
-#ifdef CONFIG_CAN_C_CAN_DCAN_64_MSG_OBJECTS
+ pend |= (u64)priv->read_reg32(priv, C_CAN_INTPND3_REG) << 32;
}
#endif
- clr = pend;
+ pend &= ~c_can_get_mask(C_CAN_MSG_OBJ_RX_NUM);
+ clr = pend >> C_CAN_MSG_OBJ_RX_NUM;
- while ((idx = ffs(pend))) {
- idx--;
- pend &= ~(1 << idx);
- obj = idx + C_CAN_MSG_OBJ_TX_FIRST;
+ while ((obj = c_can_ffs64(pend))) {
+ pend &= ~((u64)1 << (obj - 1));
c_can_inval_tx_object(dev, IF_RX, obj);
+ idx = obj - C_CAN_MSG_OBJ_TX_FIRST;
can_get_echo_skb(dev, idx);
bytes += priv->dlc[idx];
pkts++;
@@ -736,19 +755,19 @@ static void c_can_do_tx(struct net_device *dev)
* raced with the hardware or failed to readout all upper
* objects in the last run due to quota limit.
*/
-static u32 c_can_adjust_pending(u32 pend)
+static u64 c_can_adjust_pending(u64 pend)
{
- u32 weight, lasts;
+ u64 weight, lasts;
- if (pend == RECEIVE_OBJECT_BITS)
+ if (pend == c_can_get_mask(C_CAN_MSG_OBJ_RX_NUM))
return pend;
/*
* If the last set bit is larger than the number of pending
* bits we have a gap.
*/
- weight = hweight32(pend);
- lasts = fls(pend);
+ weight = hweight64(pend);
+ lasts = fls64(pend);
/* If the bits are linear, nothing to do */
if (lasts == weight)
@@ -777,11 +796,11 @@ static inline void c_can_rx_finalize(struct net_device *dev,
}
static int c_can_read_objects(struct net_device *dev, struct c_can_priv *priv,
- u32 pend, int quota)
+ u64 pend, int quota)
{
u32 pkts = 0, ctrl, obj;
- while ((obj = ffs(pend)) && quota > 0) {
+ while ((obj = c_can_ffs64(pend)) && quota > 0) {
pend &= ~BIT(obj - 1);
c_can_rx_object_get(dev, priv, obj);
@@ -815,13 +834,15 @@ static int c_can_read_objects(struct net_device *dev, struct c_can_priv *priv,
return pkts;
}
-static inline u32 c_can_get_pending(struct c_can_priv *priv)
+static inline u64 c_can_get_pending(struct c_can_priv *priv)
{
- u32 pend;
+ u64 pend;
#ifdef CONFIG_CAN_C_CAN_DCAN_64_MSG_OBJECTS
if (priv->type == BOSCH_D_CAN) {
pend = priv->read_reg32(priv, C_CAN_NEWDAT1_REG);
+ pend |= (u64)priv->read_reg32(priv, C_CAN_NEWDAT3_REG) << 32;
+ pend &= c_can_get_mask(C_CAN_MSG_OBJ_RX_NUM);
} else {
#endif
pend = priv->read_reg(priv, C_CAN_NEWDAT1_REG);
@@ -847,7 +868,8 @@ static inline u32 c_can_get_pending(struct c_can_priv *priv)
static int c_can_do_rx_poll(struct net_device *dev, int quota)
{
struct c_can_priv *priv = netdev_priv(dev);
- u32 pkts = 0, pend = 0, toread, n;
+ u32 pkts = 0, n;
+ u64 pend = 0, toread;
while (quota > 0) {
if (!pend) {
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index e44b686a70a2..4a0759ee249d 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -26,12 +26,12 @@
#ifdef CONFIG_CAN_C_CAN_DCAN_64_MSG_OBJECTS
#define C_CAN_NO_OF_OBJECTS 64
+#define C_CAN_MSG_OBJ_RX_NUM CONFIG_CAN_C_CAN_DCAN_RX_MSG_OBJECTS
#else
#define C_CAN_NO_OF_OBJECTS 32
+#define C_CAN_MSG_OBJ_RX_NUM 16
#endif
-
-#define C_CAN_MSG_OBJ_TX_NUM (C_CAN_NO_OF_OBJECTS >> 1)
-#define C_CAN_MSG_OBJ_RX_NUM (C_CAN_NO_OF_OBJECTS - C_CAN_MSG_OBJ_TX_NUM)
+#define C_CAN_MSG_OBJ_TX_NUM (C_CAN_NO_OF_OBJECTS - C_CAN_MSG_OBJ_RX_NUM)
#define C_CAN_MSG_OBJ_RX_FIRST 1
#define C_CAN_MSG_OBJ_RX_LAST (C_CAN_MSG_OBJ_RX_FIRST + \
@@ -41,12 +41,6 @@
#define C_CAN_MSG_OBJ_TX_LAST (C_CAN_MSG_OBJ_TX_FIRST + \
C_CAN_MSG_OBJ_TX_NUM - 1)
-#ifdef CONFIG_CAN_C_CAN_DCAN_64_MSG_OBJECTS
-#define RECEIVE_OBJECT_BITS 0xffffffff
-#else
-#define RECEIVE_OBJECT_BITS 0x0000ffff
-#endif
-
enum reg {
C_CAN_CTRL_REG = 0,
C_CAN_CTRL_EX_REG,
@@ -82,6 +76,8 @@ enum reg {
C_CAN_TXRQST2_REG,
C_CAN_NEWDAT1_REG,
C_CAN_NEWDAT2_REG,
+ C_CAN_NEWDAT3_REG,
+ C_CAN_NEWDAT4_REG,
C_CAN_INTPND1_REG,
C_CAN_INTPND2_REG,
C_CAN_INTPND3_REG,
@@ -145,6 +141,8 @@ static const u16 reg_map_d_can[] = {
[C_CAN_TXRQST2_REG] = 0x8A,
[C_CAN_NEWDAT1_REG] = 0x9C,
[C_CAN_NEWDAT2_REG] = 0x9E,
+ [C_CAN_NEWDAT3_REG] = 0xA0,
+ [C_CAN_NEWDAT4_REG] = 0xA2,
[C_CAN_INTPND1_REG] = 0xB0,
[C_CAN_INTPND2_REG] = 0xB2,
[C_CAN_INTPND3_REG] = 0xB4,
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net-next] ipvlan: decouple l3s mode dependencies from other modes
From: Florian Westphal @ 2019-02-08 13:29 UTC (permalink / raw)
To: Daniel Borkmann
Cc: davem, netdev, Mahesh Bandewar, Florian Westphal,
Martynas Pumputis
In-Reply-To: <20190208125531.28970-1-daniel@iogearbox.net>
Daniel Borkmann <daniel@iogearbox.net> wrote:
> Right now ipvlan has a hard dependency on CONFIG_NETFILTER and
> otherwise it cannot be built. However, the only ipvlan operation
> mode that actually depends on netfilter is l3s, everything else
> is independent of it. Break this hard dependency such that users
> are able to use ipvlan l3 mode on systems where netfilter is not
> compiled in.
>
> Therefore, this adds a hidden CONFIG_IPVLAN_L3S bool which is
> defaulting to y when CONFIG_NETFILTER is set in order to retain
> existing behavior for l3s. All l3s related code is refactored
> into ipvlan_l3s.c that is compiled in when enabled.
IIRC L3S is only meaningful with netfilter anyway, so this
looks like a good thing to do.
Acked-by: Florian Westphal <fw@strlen.de>
^ permalink raw reply
* [PATCH 1/2] can: c_can: support 64 message objects for D_CAN
From: Andrejs Cainikovs @ 2019-02-08 13:31 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde, David S . Miller,
linux-can@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: Patrick Zysset
In-Reply-To: <20190208132954.28166-1-andrejs.cainikovs@netmodule.com>
D_CAN supports up to 128 message objects, comparing to 32 on C_CAN.
However, some CPUs with D_CAN controller have their own limits:
TI AM335x Sitara CPU, for example, supports max of 64 message objects.
This patch extends max D_CAN message objects up to 64.
Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@netmodule.com>
---
drivers/net/can/c_can/Kconfig | 12 ++++++++++++
drivers/net/can/c_can/c_can.c | 42 ++++++++++++++++++++++--------------------
drivers/net/can/c_can/c_can.h | 20 ++++++++++++++++----
3 files changed, 50 insertions(+), 24 deletions(-)
diff --git a/drivers/net/can/c_can/Kconfig b/drivers/net/can/c_can/Kconfig
index 61ffc12d8fd8..6c1ada7291df 100644
--- a/drivers/net/can/c_can/Kconfig
+++ b/drivers/net/can/c_can/Kconfig
@@ -20,4 +20,16 @@ config CAN_C_CAN_PCI
---help---
This driver adds support for the C_CAN/D_CAN chips connected
to the PCI bus.
+
+config CAN_C_CAN_DCAN_64_MSG_OBJECTS
+ bool "Use 64 message objects for D_CAN"
+ default n
+ ---help---
+ D_CAN supports up to 128 message objects, comparing to 32 on
+ C_CAN. However, some CPUs with D_CAN controller have their
+ own limits: TI AM335x Sitara CPU, for example, supports max
+ of 64 message objects.
+ Enabling this option extends max D_CAN message objects up to
+ 64.
+
endif
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 606b7d8ffe13..5d695b89b459 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -352,15 +352,6 @@ static void c_can_setup_tx_object(struct net_device *dev, int iface,
}
}
-static inline void c_can_activate_all_lower_rx_msg_obj(struct net_device *dev,
- int iface)
-{
- int i;
-
- for (i = C_CAN_MSG_OBJ_RX_FIRST; i <= C_CAN_MSG_RX_LOW_LAST; i++)
- c_can_object_get(dev, iface, i, IF_COMM_CLR_NEWDAT);
-}
-
static int c_can_handle_lost_msg_obj(struct net_device *dev,
int iface, int objno, u32 ctrl)
{
@@ -706,7 +697,16 @@ static void c_can_do_tx(struct net_device *dev)
struct net_device_stats *stats = &dev->stats;
u32 idx, obj, pkts = 0, bytes = 0, pend, clr;
- clr = pend = priv->read_reg(priv, C_CAN_INTPND2_REG);
+#ifdef CONFIG_CAN_C_CAN_DCAN_64_MSG_OBJECTS
+ if (priv->type == BOSCH_D_CAN) {
+ pend = priv->read_reg32(priv, C_CAN_INTPND3_REG);
+ } else {
+#endif
+ pend = priv->read_reg(priv, C_CAN_INTPND2_REG);
+#ifdef CONFIG_CAN_C_CAN_DCAN_64_MSG_OBJECTS
+ }
+#endif
+ clr = pend;
while ((idx = ffs(pend))) {
idx--;
@@ -817,7 +817,17 @@ static int c_can_read_objects(struct net_device *dev, struct c_can_priv *priv,
static inline u32 c_can_get_pending(struct c_can_priv *priv)
{
- u32 pend = priv->read_reg(priv, C_CAN_NEWDAT1_REG);
+ u32 pend;
+
+#ifdef CONFIG_CAN_C_CAN_DCAN_64_MSG_OBJECTS
+ if (priv->type == BOSCH_D_CAN) {
+ pend = priv->read_reg32(priv, C_CAN_NEWDAT1_REG);
+ } else {
+#endif
+ pend = priv->read_reg(priv, C_CAN_NEWDAT1_REG);
+#ifdef CONFIG_CAN_C_CAN_DCAN_64_MSG_OBJECTS
+ }
+#endif
return pend;
}
@@ -828,8 +838,7 @@ static inline u32 c_can_get_pending(struct c_can_priv *priv)
* c_can core saves a received CAN message into the first free message
* object it finds free (starting with the lowest). Bits NEWDAT and
* INTPND are set for this message object indicating that a new message
- * has arrived. To work-around this issue, we keep two groups of message
- * objects whose partitioning is defined by C_CAN_MSG_OBJ_RX_SPLIT.
+ * has arrived.
*
* We clear the newdat bit right away.
*
@@ -840,13 +849,6 @@ static int c_can_do_rx_poll(struct net_device *dev, int quota)
struct c_can_priv *priv = netdev_priv(dev);
u32 pkts = 0, pend = 0, toread, n;
- /*
- * It is faster to read only one 16bit register. This is only possible
- * for a maximum number of 16 objects.
- */
- BUILD_BUG_ON_MSG(C_CAN_MSG_OBJ_RX_LAST > 16,
- "Implementation does not support more message objects than 16");
-
while (quota > 0) {
if (!pend) {
pend = c_can_get_pending(priv);
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index 8acdc7fa4792..e44b686a70a2 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -23,9 +23,15 @@
#define C_CAN_H
/* message object split */
+
+#ifdef CONFIG_CAN_C_CAN_DCAN_64_MSG_OBJECTS
+#define C_CAN_NO_OF_OBJECTS 64
+#else
#define C_CAN_NO_OF_OBJECTS 32
-#define C_CAN_MSG_OBJ_RX_NUM 16
-#define C_CAN_MSG_OBJ_TX_NUM 16
+#endif
+
+#define C_CAN_MSG_OBJ_TX_NUM (C_CAN_NO_OF_OBJECTS >> 1)
+#define C_CAN_MSG_OBJ_RX_NUM (C_CAN_NO_OF_OBJECTS - C_CAN_MSG_OBJ_TX_NUM)
#define C_CAN_MSG_OBJ_RX_FIRST 1
#define C_CAN_MSG_OBJ_RX_LAST (C_CAN_MSG_OBJ_RX_FIRST + \
@@ -35,9 +41,11 @@
#define C_CAN_MSG_OBJ_TX_LAST (C_CAN_MSG_OBJ_TX_FIRST + \
C_CAN_MSG_OBJ_TX_NUM - 1)
-#define C_CAN_MSG_OBJ_RX_SPLIT 9
-#define C_CAN_MSG_RX_LOW_LAST (C_CAN_MSG_OBJ_RX_SPLIT - 1)
+#ifdef CONFIG_CAN_C_CAN_DCAN_64_MSG_OBJECTS
+#define RECEIVE_OBJECT_BITS 0xffffffff
+#else
#define RECEIVE_OBJECT_BITS 0x0000ffff
+#endif
enum reg {
C_CAN_CTRL_REG = 0,
@@ -76,6 +84,8 @@ enum reg {
C_CAN_NEWDAT2_REG,
C_CAN_INTPND1_REG,
C_CAN_INTPND2_REG,
+ C_CAN_INTPND3_REG,
+ C_CAN_INTPND4_REG,
C_CAN_MSGVAL1_REG,
C_CAN_MSGVAL2_REG,
C_CAN_FUNCTION_REG,
@@ -137,6 +147,8 @@ static const u16 reg_map_d_can[] = {
[C_CAN_NEWDAT2_REG] = 0x9E,
[C_CAN_INTPND1_REG] = 0xB0,
[C_CAN_INTPND2_REG] = 0xB2,
+ [C_CAN_INTPND3_REG] = 0xB4,
+ [C_CAN_INTPND4_REG] = 0xB6,
[C_CAN_MSGVAL1_REG] = 0xC4,
[C_CAN_MSGVAL2_REG] = 0xC6,
[C_CAN_IF1_COMREQ_REG] = 0x100,
--
2.11.0
^ permalink raw reply related
* [PATCH 2/2] can: c_can: configurable amount of D_CAN RX objects
From: Andrejs Cainikovs @ 2019-02-08 13:31 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde, David S . Miller,
linux-can@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: Patrick Zysset
In-Reply-To: <20190208132954.28166-1-andrejs.cainikovs@netmodule.com>
Make number of D_CAN RX message objects configurable. This will allow
having bigger (or smaller) RX buffer instead of 50/50 split for RX/TX.
Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@netmodule.com>
---
drivers/net/can/c_can/Kconfig | 8 ++++++
drivers/net/can/c_can/c_can.c | 64 +++++++++++++++++++++++++++++--------------
drivers/net/can/c_can/c_can.h | 16 +++++------
3 files changed, 58 insertions(+), 30 deletions(-)
diff --git a/drivers/net/can/c_can/Kconfig b/drivers/net/can/c_can/Kconfig
index 6c1ada7291df..949d2d12d71e 100644
--- a/drivers/net/can/c_can/Kconfig
+++ b/drivers/net/can/c_can/Kconfig
@@ -32,4 +32,12 @@ config CAN_C_CAN_DCAN_64_MSG_OBJECTS
Enabling this option extends max D_CAN message objects up to
64.
+config CAN_C_CAN_DCAN_RX_MSG_OBJECTS
+ int "Specify amount of D_CAN RX message objects"
+ depends on CAN_C_CAN_DCAN_64_MSG_OBJECTS
+ default 32
+ ---help---
+ Use specific number of message objects for RX, instead of
+ 50/50 split between RX/TX.
+
endif
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 5d695b89b459..675bc223e222 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -208,6 +208,26 @@ static const struct can_bittiming_const c_can_bittiming_const = {
.brp_inc = 1,
};
+static inline u64 c_can_get_mask(int bits)
+{
+ return ((u64)1 << bits) - 1;
+}
+
+static inline int c_can_ffs64(u64 x)
+{
+ int b;
+
+ b = ffs(x);
+
+ if (!b) {
+ b = ffs(x >> 32);
+ if (b)
+ b += 32;
+ }
+
+ return b;
+}
+
static inline void c_can_pm_runtime_enable(const struct c_can_priv *priv)
{
if (priv->device)
@@ -695,24 +715,23 @@ static void c_can_do_tx(struct net_device *dev)
{
struct c_can_priv *priv = netdev_priv(dev);
struct net_device_stats *stats = &dev->stats;
- u32 idx, obj, pkts = 0, bytes = 0, pend, clr;
+ u32 idx, obj, pkts = 0, bytes = 0;
+ u64 pend, clr;
+ /* Mask interrupt pending bits */
+ pend = priv->read_reg32(priv, C_CAN_INTPND1_REG);
#ifdef CONFIG_CAN_C_CAN_DCAN_64_MSG_OBJECTS
if (priv->type == BOSCH_D_CAN) {
- pend = priv->read_reg32(priv, C_CAN_INTPND3_REG);
- } else {
-#endif
- pend = priv->read_reg(priv, C_CAN_INTPND2_REG);
-#ifdef CONFIG_CAN_C_CAN_DCAN_64_MSG_OBJECTS
+ pend |= (u64)priv->read_reg32(priv, C_CAN_INTPND3_REG) << 32;
}
#endif
- clr = pend;
+ pend &= ~c_can_get_mask(C_CAN_MSG_OBJ_RX_NUM);
+ clr = pend >> C_CAN_MSG_OBJ_RX_NUM;
- while ((idx = ffs(pend))) {
- idx--;
- pend &= ~(1 << idx);
- obj = idx + C_CAN_MSG_OBJ_TX_FIRST;
+ while ((obj = c_can_ffs64(pend))) {
+ pend &= ~((u64)1 << (obj - 1));
c_can_inval_tx_object(dev, IF_RX, obj);
+ idx = obj - C_CAN_MSG_OBJ_TX_FIRST;
can_get_echo_skb(dev, idx);
bytes += priv->dlc[idx];
pkts++;
@@ -736,19 +755,19 @@ static void c_can_do_tx(struct net_device *dev)
* raced with the hardware or failed to readout all upper
* objects in the last run due to quota limit.
*/
-static u32 c_can_adjust_pending(u32 pend)
+static u64 c_can_adjust_pending(u64 pend)
{
- u32 weight, lasts;
+ u64 weight, lasts;
- if (pend == RECEIVE_OBJECT_BITS)
+ if (pend == c_can_get_mask(C_CAN_MSG_OBJ_RX_NUM))
return pend;
/*
* If the last set bit is larger than the number of pending
* bits we have a gap.
*/
- weight = hweight32(pend);
- lasts = fls(pend);
+ weight = hweight64(pend);
+ lasts = fls64(pend);
/* If the bits are linear, nothing to do */
if (lasts == weight)
@@ -777,11 +796,11 @@ static inline void c_can_rx_finalize(struct net_device *dev,
}
static int c_can_read_objects(struct net_device *dev, struct c_can_priv *priv,
- u32 pend, int quota)
+ u64 pend, int quota)
{
u32 pkts = 0, ctrl, obj;
- while ((obj = ffs(pend)) && quota > 0) {
+ while ((obj = c_can_ffs64(pend)) && quota > 0) {
pend &= ~BIT(obj - 1);
c_can_rx_object_get(dev, priv, obj);
@@ -815,13 +834,15 @@ static int c_can_read_objects(struct net_device *dev, struct c_can_priv *priv,
return pkts;
}
-static inline u32 c_can_get_pending(struct c_can_priv *priv)
+static inline u64 c_can_get_pending(struct c_can_priv *priv)
{
- u32 pend;
+ u64 pend;
#ifdef CONFIG_CAN_C_CAN_DCAN_64_MSG_OBJECTS
if (priv->type == BOSCH_D_CAN) {
pend = priv->read_reg32(priv, C_CAN_NEWDAT1_REG);
+ pend |= (u64)priv->read_reg32(priv, C_CAN_NEWDAT3_REG) << 32;
+ pend &= c_can_get_mask(C_CAN_MSG_OBJ_RX_NUM);
} else {
#endif
pend = priv->read_reg(priv, C_CAN_NEWDAT1_REG);
@@ -847,7 +868,8 @@ static inline u32 c_can_get_pending(struct c_can_priv *priv)
static int c_can_do_rx_poll(struct net_device *dev, int quota)
{
struct c_can_priv *priv = netdev_priv(dev);
- u32 pkts = 0, pend = 0, toread, n;
+ u32 pkts = 0, n;
+ u64 pend = 0, toread;
while (quota > 0) {
if (!pend) {
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index e44b686a70a2..4a0759ee249d 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -26,12 +26,12 @@
#ifdef CONFIG_CAN_C_CAN_DCAN_64_MSG_OBJECTS
#define C_CAN_NO_OF_OBJECTS 64
+#define C_CAN_MSG_OBJ_RX_NUM CONFIG_CAN_C_CAN_DCAN_RX_MSG_OBJECTS
#else
#define C_CAN_NO_OF_OBJECTS 32
+#define C_CAN_MSG_OBJ_RX_NUM 16
#endif
-
-#define C_CAN_MSG_OBJ_TX_NUM (C_CAN_NO_OF_OBJECTS >> 1)
-#define C_CAN_MSG_OBJ_RX_NUM (C_CAN_NO_OF_OBJECTS - C_CAN_MSG_OBJ_TX_NUM)
+#define C_CAN_MSG_OBJ_TX_NUM (C_CAN_NO_OF_OBJECTS - C_CAN_MSG_OBJ_RX_NUM)
#define C_CAN_MSG_OBJ_RX_FIRST 1
#define C_CAN_MSG_OBJ_RX_LAST (C_CAN_MSG_OBJ_RX_FIRST + \
@@ -41,12 +41,6 @@
#define C_CAN_MSG_OBJ_TX_LAST (C_CAN_MSG_OBJ_TX_FIRST + \
C_CAN_MSG_OBJ_TX_NUM - 1)
-#ifdef CONFIG_CAN_C_CAN_DCAN_64_MSG_OBJECTS
-#define RECEIVE_OBJECT_BITS 0xffffffff
-#else
-#define RECEIVE_OBJECT_BITS 0x0000ffff
-#endif
-
enum reg {
C_CAN_CTRL_REG = 0,
C_CAN_CTRL_EX_REG,
@@ -82,6 +76,8 @@ enum reg {
C_CAN_TXRQST2_REG,
C_CAN_NEWDAT1_REG,
C_CAN_NEWDAT2_REG,
+ C_CAN_NEWDAT3_REG,
+ C_CAN_NEWDAT4_REG,
C_CAN_INTPND1_REG,
C_CAN_INTPND2_REG,
C_CAN_INTPND3_REG,
@@ -145,6 +141,8 @@ static const u16 reg_map_d_can[] = {
[C_CAN_TXRQST2_REG] = 0x8A,
[C_CAN_NEWDAT1_REG] = 0x9C,
[C_CAN_NEWDAT2_REG] = 0x9E,
+ [C_CAN_NEWDAT3_REG] = 0xA0,
+ [C_CAN_NEWDAT4_REG] = 0xA2,
[C_CAN_INTPND1_REG] = 0xB0,
[C_CAN_INTPND2_REG] = 0xB2,
[C_CAN_INTPND3_REG] = 0xB4,
--
2.11.0
^ permalink raw reply related
* [PATCH 0/2] D_CAN RX buffer size improvements
From: Andrejs Cainikovs @ 2019-02-08 13:31 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde, David S . Miller,
linux-can@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: Patrick Zysset
Re-sending entire patchset due to missed cover letter, sorry.
This patchset introduces support for 64 D_CAN message objects with an option of
unequal split between RX/TX.
The rationale behind this is that there are lots of frame loss on higher bus
speeds. Below are test results from my custom Sitara AM3352 based board:
Sender: timeout 15m cangen can0 -g 0 -i x
Target: candump can0,0~0,#FFFFFFFF -td -c -d -e
* Without patches:
- 15 minute RX test, 500kbps
- 16 RX / 16 TX message objects
- 77 received frames lost out of 4649415
* With patches applied:
- 15 hours RX test, 500kbps
- 56 RX / 8 TX message objects
- 41 received frames lost out of 279303376
Please note, I do not have ability to test pure C_CAN, so it is left untested.
---
Andrejs Cainikovs (2):
can: c_can: support 64 message objects for D_CAN
can: c_can: configurable amount of D_CAN RX objects
drivers/net/can/c_can/Kconfig | 20 ++++++++++
drivers/net/can/c_can/c_can.c | 93 +++++++++++++++++++++++++++----------------
drivers/net/can/c_can/c_can.h | 20 +++++++---
3 files changed, 94 insertions(+), 39 deletions(-)
---
2.11.0
^ permalink raw reply
* Re: [PATCH net-next] ipvlan: decouple l3s mode dependencies from other modes
From: Daniel Borkmann @ 2019-02-08 13:39 UTC (permalink / raw)
To: Florian Westphal; +Cc: davem, netdev, Mahesh Bandewar, Martynas Pumputis
In-Reply-To: <20190208132941.bmbvuqckocuyhujr@breakpoint.cc>
On 02/08/2019 02:29 PM, Florian Westphal wrote:
> Daniel Borkmann <daniel@iogearbox.net> wrote:
>> Right now ipvlan has a hard dependency on CONFIG_NETFILTER and
>> otherwise it cannot be built. However, the only ipvlan operation
>> mode that actually depends on netfilter is l3s, everything else
>> is independent of it. Break this hard dependency such that users
>> are able to use ipvlan l3 mode on systems where netfilter is not
>> compiled in.
>>
>> Therefore, this adds a hidden CONFIG_IPVLAN_L3S bool which is
>> defaulting to y when CONFIG_NETFILTER is set in order to retain
>> existing behavior for l3s. All l3s related code is refactored
>> into ipvlan_l3s.c that is compiled in when enabled.
>
> IIRC L3S is only meaningful with netfilter anyway, so this
> looks like a good thing to do.
Yep, agree, it doesn't work without it since inside ipvlan's nfhook
there is the final switch to the target ipvlan slave device. :)
> Acked-by: Florian Westphal <fw@strlen.de>
Thanks!
^ permalink raw reply
* Re: [PATCH v2 3/6] ethtool: introduce new ioctl for per-queue settings
From: Willem de Bruijn @ 2019-02-08 13:56 UTC (permalink / raw)
To: Michal Kubecek
Cc: Network Development, Nunley, Nicholas D, Kirsher, Jeffrey T,
linville@tuxdriver.com, nhorman@redhat.com, sassmann@redhat.com
In-Reply-To: <20190208070200.GA7035@unicorn.suse.cz>
On Fri, Feb 8, 2019 at 2:04 AM Michal Kubecek <mkubecek@suse.cz> wrote:
>
> On Thu, Feb 07, 2019 at 11:37:19PM +0000, Nunley, Nicholas D wrote:
> > From: Michal Kubecek [mailto:mkubecek@suse.cz]
> > > On Tue, Feb 05, 2019 at 04:01:03PM -0800, Jeff Kirsher wrote:
> > > > Introduce a new ioctl for setting per-queue parameters.
> > > > Users can apply commands to specific queues by setting SUB_COMMAND
> > > and
> > > > queue_mask with the following ethtool command:
> > > >
> > > > ethtool --set-perqueue-command DEVNAME [queue_mask %x]
> > > SUB_COMMAND
> > >
> > > The "set" part is IMHO a bit confusing in combination with "show" type
> > > subcommands.
> >
> > I'm not a fan of the "set" either. This patch set had already gone
> > through some review before it was passed on to me, and the command
> > naming wasn't a previous point of contention and I didn't want to
> > disturb the parts that weren't "broken", but since you've brought it
> > up I agree that this may not be the best name. I think
> > "--perqueue-command" is more appropriate. Does this seem reasonable to
> > you?
>
> That sounds good, I would say either that or "--per-queue".
+1 --per-queue is short and easy to remember.
And perhaps reserve short-hand '-Q'? I expect this to become a popular
option. Especially if perhaps eventually it can dump per queue stats (-S).
^ permalink raw reply
* Re: [PATCH net-next] net: phy: disregard "Clause 22 registers present" bit in get_phy_c45_devs_in_pkg
From: Andrew Lunn @ 2019-02-08 14:02 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <47ec59c0-27c0-32e3-c75e-7bdfa99551c9@gmail.com>
On Fri, Feb 08, 2019 at 08:12:47AM +0100, Heiner Kallweit wrote:
> Bit 0 in register 1.5 doesn't represent a device but is a flag that
> Clause 22 registers are present. Therefore disregard this bit when
> populating the device list. If code needs this information it
> should read register 1.5 directly instead of accessing the device
> list. Because this bit doesn't represent a device I didn't add a
> MDIO_MMD_C22PRESENT constant or similar.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
> drivers/net/phy/phy_device.c | 3 ++-
> include/uapi/linux/mdio.h | 1 +
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 9369e1323..c2316a117 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -682,7 +682,8 @@ static int get_phy_c45_devs_in_pkg(struct mii_bus *bus, int addr, int dev_addr,
> phy_reg = mdiobus_read(bus, addr, reg_addr);
> if (phy_reg < 0)
> return -EIO;
> - *devices_in_package |= (phy_reg & 0xffff);
> + /* Bit 0 doesn't represent a device, it indicates c22 regs presence */
> + *devices_in_package |= (phy_reg & 0xfffe);
Hi Heiner
Just for readability, can we use BIT(0) in there somehow?
>
> return 0;
> }
> diff --git a/include/uapi/linux/mdio.h b/include/uapi/linux/mdio.h
> index 2e6e309f0..0e012b168 100644
> --- a/include/uapi/linux/mdio.h
> +++ b/include/uapi/linux/mdio.h
> @@ -115,6 +115,7 @@
>
> /* Device present registers. */
> #define MDIO_DEVS_PRESENT(devad) (1 << (devad))
> +#define MDIO_DEVS_C22PRESENT MDIO_DEVS_PRESENT(0)
Err. The commit message says you did not add this...
Andrew
^ permalink raw reply
* Re: [PATCH net-next] ipmr: ip6mr: Create new sockopt to clear mfc cache or vifs
From: Nicolas Dichtel @ 2019-02-08 14:18 UTC (permalink / raw)
To: Callum Sinclair, davem, kuznet, yoshfuji, nikolay, netdev,
linux-kernel
In-Reply-To: <20190208041103.31299-2-callum.sinclair@alliedtelesis.co.nz>
Le 08/02/2019 à 05:11, Callum Sinclair a écrit :
> Currently the only way to clear the mfc cache was to delete the entries
mfc stands for 'multicast forwarding cache', so 'mfc cache' is a bit strange.
> one by one using the MRT_DEL_MFC socket option or to destroy and
> recreate the socket.
Note that if entries were added with MRT_ADD_MFC_PROXY, they will survive to the
socket destruction. This is not the case with your new cmd. Is it intended?
Maybe a third option (something like MRT_FLUSH_MFC_PROXY) would be useful to
avoid confusion?
>
> Create a new socket option which will clear the multicast forwarding
> cache on the socket without destroying the socket. The new socket option
> MRT_FLUSH_ENTRIES will clear all multicast entries on the sockets table
> and the MRT_FLUSH_VIFS will delete all multicast vifs on the socket
> table.
>
> Signed-off-by: Callum Sinclair <callum.sinclair@alliedtelesis.co.nz>
> ---
> include/uapi/linux/mroute.h | 7 +++-
> include/uapi/linux/mroute6.h | 7 +++-
> net/ipv4/ipmr.c | 69 ++++++++++++++++++++-------------
> net/ipv6/ip6mr.c | 74 ++++++++++++++++++++++--------------
> 4 files changed, 100 insertions(+), 57 deletions(-)
>
> diff --git a/include/uapi/linux/mroute.h b/include/uapi/linux/mroute.h
> index 5d37a9ccce63..673495ca3495 100644
> --- a/include/uapi/linux/mroute.h
> +++ b/include/uapi/linux/mroute.h
> @@ -28,12 +28,17 @@
> #define MRT_TABLE (MRT_BASE+9) /* Specify mroute table ID */
> #define MRT_ADD_MFC_PROXY (MRT_BASE+10) /* Add a (*,*|G) mfc entry */
> #define MRT_DEL_MFC_PROXY (MRT_BASE+11) /* Del a (*,*|G) mfc entry */
> -#define MRT_MAX (MRT_BASE+11)
> +#define MRT_FLUSH (MRT_BASE+12) /* Flush all multicast entries and vifs */
nit: "Flush all mfc entries and/or vifs" ?
> +#define MRT_MAX (MRT_BASE+12)
>
> #define SIOCGETVIFCNT SIOCPROTOPRIVATE /* IP protocol privates */
> #define SIOCGETSGCNT (SIOCPROTOPRIVATE+1)
> #define SIOCGETRPF (SIOCPROTOPRIVATE+2)
>
> +/* MRT_FLUSH optional flags */
> +#define MRT_FLUSH_ENTRIES 1 /* For flushing all multicast entries */
Maybe MRT_FLUSH_MFC is more consistent with the previous naming (MRT_ADD_MFC, etc.)
Regards,
Nicolas
^ permalink raw reply
* Re: Clang warning in drivers/net/ethernet/intel/igc/igc_ethtool.c
From: Michal Kubecek @ 2019-02-08 14:34 UTC (permalink / raw)
To: netdev
Cc: Nathan Chancellor, Sasha Neftin, Jeff Kirsher, Aaron Brown,
intel-wired-lan, linux-kernel, Nick Desaulniers
In-Reply-To: <20190208050921.GA8758@archlinux-ryzen>
On Thu, Feb 07, 2019 at 10:09:21PM -0700, Nathan Chancellor wrote:
> Hi all,
>
> After commit 8c5ad0dae93c ("igc: Add ethtool support"), Clang warns:
>
> drivers/net/ethernet/intel/igc/igc_ethtool.c:9:19: warning: variable 'igc_priv_flags_strings' is not needed and will not be emitted [-Wunneeded-internal-declaration]
> static const char igc_priv_flags_strings[][ETH_GSTRING_LEN] = {
> ^
> 1 warning generated.
>
> igc_priv_flags_strings is only used in an ARRAY_SIZE macro, which is a
> compile time evaluation, so no reference to it is being emitted in the
> final assembly. Is it actually needed and was forgotten to be used
> somewhere or could it be eliminated so that Clang no longer warns?
That's because the driver provides get_priv_flags() and set_priv_flags()
callbacks in its ethtool_ops to allow querying and setting legacy-rx
private flag but it does not provide get_sset_count() and get_strings()
to provide list of private flags to userspace ethtool.
Michal Kubecek
^ permalink raw reply
* Re: [PATCH net-next] ipmr: ip6mr: Create new sockopt to clear mfc cache or vifs
From: Nikolay Aleksandrov @ 2019-02-08 14:43 UTC (permalink / raw)
To: nicolas.dichtel, Callum Sinclair, davem, kuznet, yoshfuji, netdev,
linux-kernel
In-Reply-To: <be9e655b-6911-c644-de63-9aabcd131763@6wind.com>
On 08/02/2019 16:18, Nicolas Dichtel wrote:
> Le 08/02/2019 à 05:11, Callum Sinclair a écrit :
>> Currently the only way to clear the mfc cache was to delete the entries
> mfc stands for 'multicast forwarding cache', so 'mfc cache' is a bit strange.
>
>> one by one using the MRT_DEL_MFC socket option or to destroy and
>> recreate the socket.
> Note that if entries were added with MRT_ADD_MFC_PROXY, they will survive to the
> socket destruction. This is not the case with your new cmd. Is it intended?
I think you're referring to MFC_STATIC entries (sk != mroute_sk). It
doesn't matter how you add an entry - they all get cleaned up if added
through the mroute socket.
> Maybe a third option (something like MRT_FLUSH_MFC_PROXY) would be useful to
> avoid confusion?
>
>>
>> Create a new socket option which will clear the multicast forwarding
>> cache on the socket without destroying the socket. The new socket option
>> MRT_FLUSH_ENTRIES will clear all multicast entries on the sockets table
>> and the MRT_FLUSH_VIFS will delete all multicast vifs on the socket
>> table.
>>
>> Signed-off-by: Callum Sinclair <callum.sinclair@alliedtelesis.co.nz>
>> ---
>> include/uapi/linux/mroute.h | 7 +++-
>> include/uapi/linux/mroute6.h | 7 +++-
>> net/ipv4/ipmr.c | 69 ++++++++++++++++++++-------------
>> net/ipv6/ip6mr.c | 74 ++++++++++++++++++++++--------------
>> 4 files changed, 100 insertions(+), 57 deletions(-)
>>
>> diff --git a/include/uapi/linux/mroute.h b/include/uapi/linux/mroute.h
>> index 5d37a9ccce63..673495ca3495 100644
>> --- a/include/uapi/linux/mroute.h
>> +++ b/include/uapi/linux/mroute.h
>> @@ -28,12 +28,17 @@
>> #define MRT_TABLE (MRT_BASE+9) /* Specify mroute table ID */
>> #define MRT_ADD_MFC_PROXY (MRT_BASE+10) /* Add a (*,*|G) mfc entry */
>> #define MRT_DEL_MFC_PROXY (MRT_BASE+11) /* Del a (*,*|G) mfc entry */
>> -#define MRT_MAX (MRT_BASE+11)
>> +#define MRT_FLUSH (MRT_BASE+12) /* Flush all multicast entries and vifs */
> nit: "Flush all mfc entries and/or vifs" ?
>
>> +#define MRT_MAX (MRT_BASE+12)
>>
>> #define SIOCGETVIFCNT SIOCPROTOPRIVATE /* IP protocol privates */
>> #define SIOCGETSGCNT (SIOCPROTOPRIVATE+1)
>> #define SIOCGETRPF (SIOCPROTOPRIVATE+2)
>>
>> +/* MRT_FLUSH optional flags */
>> +#define MRT_FLUSH_ENTRIES 1 /* For flushing all multicast entries */
> Maybe MRT_FLUSH_MFC is more consistent with the previous naming (MRT_ADD_MFC, etc.)
>
>
> Regards,
> Nicolas
>
^ permalink raw reply
* Re: [PATCH net-next] ipmr: ip6mr: Create new sockopt to clear mfc cache or vifs
From: Nicolas Dichtel @ 2019-02-08 15:08 UTC (permalink / raw)
To: Nikolay Aleksandrov, Callum Sinclair, davem, kuznet, yoshfuji,
netdev, linux-kernel
In-Reply-To: <5597e8bc-c23e-1f59-0442-260a7b4ca83d@cumulusnetworks.com>
Le 08/02/2019 à 15:43, Nikolay Aleksandrov a écrit :
> On 08/02/2019 16:18, Nicolas Dichtel wrote:
>> Le 08/02/2019 à 05:11, Callum Sinclair a écrit :
>>> Currently the only way to clear the mfc cache was to delete the entries
>> mfc stands for 'multicast forwarding cache', so 'mfc cache' is a bit strange.
>>
>>> one by one using the MRT_DEL_MFC socket option or to destroy and
>>> recreate the socket.
>> Note that if entries were added with MRT_ADD_MFC_PROXY, they will survive to the
>> socket destruction. This is not the case with your new cmd. Is it intended?
>
> I think you're referring to MFC_STATIC entries (sk != mroute_sk). It
> doesn't matter how you add an entry - they all get cleaned up if added
> through the mroute socket.
Yes, right.
MRT_FLUSH_MFC_STATIC ?
^ permalink raw reply
* Re: [PATCH] mwifiex: don't print error message on coex event
From: Kalle Valo @ 2019-02-08 15:28 UTC (permalink / raw)
To: Stefan Agner
Cc: amitkarwar, nishants, gbhat, huxinming820, davem, linux-wireless,
netdev, linux-kernel, Stefan Agner
In-Reply-To: <20190128154310.17322-1-stefan@agner.ch>
Stefan Agner <stefan@agner.ch> wrote:
> The BT coex event is not an error condition. Don't print an error
> message in this case. The same even in sta_event.c prints a
> message using the debug level already.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
Patch applied to wireless-drivers-next.git, thanks.
5208fea64e4f mwifiex: don't print error message on coex event
--
https://patchwork.kernel.org/patch/10783935/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH][RESEND] rtlwifi: remove set but not used variable 'cmd_seq'
From: Kalle Valo @ 2019-02-08 15:29 UTC (permalink / raw)
To: YueHaibing
Cc: davem, pkshih, linux-kernel, netdev, linux-wireless, YueHaibing
In-Reply-To: <20190130031526.20308-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/realtek/rtlwifi/base.c: In function 'rtl_c2h_content_parsing':
> drivers/net/wireless/realtek/rtlwifi/base.c:2313:13: warning:
> variable 'cmd_seq' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Patch applied to wireless-drivers-next.git, thanks.
78f2ef18e185 rtlwifi: remove set but not used variable 'cmd_seq'
--
https://patchwork.kernel.org/patch/10787619/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rsi: fix indentation issue with a code block
From: Kalle Valo @ 2019-02-08 15:31 UTC (permalink / raw)
To: Colin King
Cc: Amitkumar Karwar, Siva Rebbagondla, David S . Miller,
linux-wireless, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20190207121141.28336-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> There is a block of code that is indented at the wrong level. Fix this
> with extra tabbing.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied to wireless-drivers-next.git, thanks.
34025a1056a3 rsi: fix indentation issue with a code block
--
https://patchwork.kernel.org/patch/10801013/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: use struct_size() in devm_kzalloc()
From: Vivien Didelot @ 2019-02-08 15:32 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Andrew Lunn, Florian Fainelli, David S. Miller, netdev,
linux-kernel, Gustavo A. R. Silva
In-Reply-To: <20190208011603.GA927@embeddedor>
On Thu, 7 Feb 2019 19:16:03 -0600, "Gustavo A. R. Silva" <gustavo@embeddedor.com> wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> size = sizeof(struct foo) + count * sizeof(struct boo);
> instance = alloc(size, GFP_KERNEL)
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = alloc(struct_size(instance, entry, count), GFP_KERNEL)
>
> Notice that, in this case, variable size is not necessary, hence it is
> removed.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
^ permalink raw reply
* Re: Kernel 5.0-rc5 regression with NAT, bisected to: netfilter: nat: remove l4proto->manip_pkt
From: Sander Eikelenboom @ 2019-02-08 15:34 UTC (permalink / raw)
To: Florian Westphal; +Cc: Pablo Neira Ayuso, David S. Miller, netdev, linux-kernel
In-Reply-To: <20190208115447.ojyfhenf44kqs3w4@breakpoint.cc>
On 08/02/2019 12:54, Florian Westphal wrote:
> Florian Westphal <fw@strlen.de> wrote:
>> Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>> L.S.,
>>>
>>> While trying out a 5.0-RC5 kernel I seem to have stumbled over a regression with NAT.
>>> (using an nftables firewall with NAT and connection tracking).
>>>
>>> Unfortunately it isn't too obvious since no errors are logged, but on clients it
>>> causes symptoms like firefox intermittently not being able to load pages with:
>>> Network Protocol Error
>>> An error occurred during a connection to www.example.com
>>> The page you are trying to view cannot be shown because an error in the network protocol was detected.
>>> Please contact the website owners to inform them of this problem.
>>>
>>> But it's only intermittently, so i can still visit some webpages with clients,
>>> could be that packet size and or fragments are at play ?
>>>
>>> So I tried testing with git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git with
>>> e8c32c32b48c2e889704d8ca0872f92eb027838e as last commit, to be sure to have the latest netdev has to offer,
>>> but to no avail.
>>>
>>> After that I tried to git bisect and ended up with:
>>>
>>> faec18dbb0405c7d4dda025054511dc3a6696918 is the first bad commit
>>> commit faec18dbb0405c7d4dda025054511dc3a6696918
>>> Author: Florian Westphal <fw@strlen.de>
>>> Date: Thu Dec 13 16:01:33 2018 +0100
>>>
>>> netfilter: nat: remove l4proto->manip_pkt
>>
>> Thanks, this is immensely helpful.
>>
>> I think I see the bug, we can't use target->dst.protonum in
>> nf_nat_l4proto_manip_pkt(), it will be TCP in case we're dealing
>> with a related icmp packet.
>>
>> I will send a patch in a few hours when I get back.
>
> Sander, does this patch fix things for you?
Hi Florian,
You may stick on a reported/tested-by if you like.
Thanks for the swift fix !
--
Sander
>
> Thanks!
>
> diff --git a/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c b/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
> --- a/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
> +++ b/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
> @@ -215,6 +215,7 @@ int nf_nat_icmp_reply_translation(struct sk_buff *skb,
>
> /* Change outer to look like the reply to an incoming packet */
> nf_ct_invert_tuplepr(&target, &ct->tuplehash[!dir].tuple);
> + target.dst.protonum = IPPROTO_ICMP;
> if (!nf_nat_ipv4_manip_pkt(skb, 0, &target, manip))
> return 0;
>
> diff --git a/net/ipv6/netfilter/nf_nat_l3proto_ipv6.c b/net/ipv6/netfilter/nf_nat_l3proto_ipv6.c
> --- a/net/ipv6/netfilter/nf_nat_l3proto_ipv6.c
> +++ b/net/ipv6/netfilter/nf_nat_l3proto_ipv6.c
> @@ -226,6 +226,7 @@ int nf_nat_icmpv6_reply_translation(struct sk_buff *skb,
> }
>
> nf_ct_invert_tuplepr(&target, &ct->tuplehash[!dir].tuple);
> + target.dst.protonum = IPPROTO_ICMPV6;
> if (!nf_nat_ipv6_manip_pkt(skb, 0, &target, manip))
> return 0;
>
>
^ permalink raw reply
* [PATCH net-next 0/5] mvpp2 phylink fixes
From: Russell King - ARM Linux admin @ 2019-02-08 15:34 UTC (permalink / raw)
To: Antoine Tenart, Maxime Chevallier
Cc: Baruch Siach, David S. Miller, netdev, Sven Auhagen
Hi,
Having spent a while debugging issues with Sven Auhagen, it appears
that the mvpp2 network driver's phylink support isn't quite correct.
This series fixes that up, but, despite being tested locally, by
Sven, and by Antoine, I would prefer it to be applied to net-next
so that there is time for more people to test before it hits -rc or
stable backports.
The symptoms were that although PHYs would come up, the GMAC never
reported that the link was up, or in some cases it did report link
up but packets would not flow. Various approaches were tried to
work around that, such as switching to in-band negotiation from
PHY mode, but ultimately the problem was in the way mvpp2 was being
programmed.
This series addresses that by, essentially, making mvpp2 follow the
same implementation pattern as mvneta: we configure the GMAC in three
stages:
1) the PHY interface mode
2) the negotiation advert
3) the negotiation style
Another issue is that mvpp2 was always taking the link down each time
its mac_config method was called: this is disruptive when the link is
already up, and we're just updating settings such as flow control.
There are some circumstances where we make the call despite there
being no changes (eg, when phylink is polling a GPIO or using a custom
link state function.)
This series depends on two previous patches already sent for net-next:
net: marvell: mvpp2: fix lack of link interrupts
net: marvell: mvpp2: use phy_interface_mode_is_8023z() helper
There is one last patch which deals with link status interrupts, which
I'll send separately because I think there's other considerations, but
that should not hold up this series of patches.
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 4 +-
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 175 ++++++++++++++----------
2 files changed, 108 insertions(+), 71 deletions(-)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* [PATCH 1/5] net: marvell: mvpp2: phylink compliance updates
From: Russell King @ 2019-02-08 15:35 UTC (permalink / raw)
To: Antoine Tenart, Maxime Chevallier
Cc: Baruch Siach, Sven Auhagen, David S. Miller, netdev
In-Reply-To: <20190208153432.igh26ubphiljsswa@shell.armlinux.org.uk>
Sven Auhagen reported issues with negotiation on a couple of his
platforms using a mixture of SFP and PHYs in various different
modes. Debugging to root cause proved difficult, but essentially
the problem comes down to the mvpp2 phylink implementation being
slightly at odds with what is expected.
phylink operates in three modes: phy, fixed-link, and in-band mode.
In the first two modes, the expected behaviour from a MAC driver is
that phylink resolves the operating mode and passes the mode to the
MAC driver for it to program, including when the link should be
brought up or taken down. This is basically the same as the libphy
approach. This does not negate the requirement to advertise a correct
control word for interface modes that have control words where that
can be reasonably controlled.
The second mode is in-band mode, where the MAC is expected to use the
in-band control word to determine the operating mode.
The mvneta driver implements the correct pattern required to support
this: configure the port interface type separately from the in-band
mode(s). This is now specified in the phylink documentation patches.
mvpp2 was programming in-band mode for SGMII and the 802.3z modes no
what, and avoided forcing the link up in fixed/phy modes. This caused
a problem with some boards where the PHY is by default programmed to
enter AN bypass mode, the PHY would report that the link was up, but
the mvpp2 never completed the exchange of control word.
Another issue that mvpp2 has is it sets SGMII AN format control word
for both SGMII and 802.3z modes. The format of the control word is
defined by MVPP2_GMAC_INBAND_AN_MASK, which should be set for SGMII
and clear for 802.3z. Available Marvell documentation for earlier
GMAC implementations does not make this clear, but this has been
ascertained via extensive testing on earlier GMAC implementations,
and then confirmed with a Macchiatobin Single Shot connected to a
Clearfog: when MVPP2_GMAC_INBAND_AN_MASK is set, the clearfog does
not receive the advertised pause mode settings.
Lastly, there is no flow control in the in-band control word in Cisco
SGMII, setting the flow control autonegotiation bit even with a PHY
that has the Marvell extension to send this information does not result
in the flow control being enabled at the MAC. We need to do this
manually using the information provided via phylink.
Re-code mvpp2's mac_config() and mac_link_up() to follow this pattern.
This allows Sven Auhagen's board and Macchiatobin to reliably bring
the link up with the 88e1512 PHY with phylink operating in PHY mode
with COMPHY built as a module but the rest of the networking built-in,
and u-boot having brought up the interface. in-band mode requires an
additional patch to resolve another problem.
Tested-by: Sven Auhagen <sven.auhagen@voleatech.de>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 97 ++++++++++++++++---------
1 file changed, 61 insertions(+), 36 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index d8974c446f8e..c590dc7ba70a 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -4572,58 +4572,84 @@ static void mvpp2_gmac_config(struct mvpp2_port *port, unsigned int mode,
an &= ~(MVPP2_GMAC_CONFIG_MII_SPEED | MVPP2_GMAC_CONFIG_GMII_SPEED |
MVPP2_GMAC_AN_SPEED_EN | MVPP2_GMAC_FC_ADV_EN |
MVPP2_GMAC_FC_ADV_ASM_EN | MVPP2_GMAC_FLOW_CTRL_AUTONEG |
- MVPP2_GMAC_CONFIG_FULL_DUPLEX | MVPP2_GMAC_AN_DUPLEX_EN |
- MVPP2_GMAC_FORCE_LINK_DOWN);
+ MVPP2_GMAC_CONFIG_FULL_DUPLEX | MVPP2_GMAC_AN_DUPLEX_EN);
ctrl0 &= ~MVPP2_GMAC_PORT_TYPE_MASK;
- ctrl2 &= ~(MVPP2_GMAC_PORT_RESET_MASK | MVPP2_GMAC_PCS_ENABLE_MASK);
+ ctrl2 &= ~(MVPP2_GMAC_INBAND_AN_MASK | MVPP2_GMAC_PORT_RESET_MASK |
+ MVPP2_GMAC_PCS_ENABLE_MASK);
+ ctrl4 &= ~(MVPP22_CTRL4_RX_FC_EN | MVPP22_CTRL4_TX_FC_EN);
+ /* Configure port type */
if (phy_interface_mode_is_8023z(state->interface)) {
- /* 1000BaseX and 2500BaseX ports cannot negotiate speed nor can
- * they negotiate duplex: they are always operating with a fixed
- * speed of 1000/2500Mbps in full duplex, so force 1000/2500
- * speed and full duplex here.
- */
- ctrl0 |= MVPP2_GMAC_PORT_TYPE_MASK;
- an |= MVPP2_GMAC_CONFIG_GMII_SPEED |
- MVPP2_GMAC_CONFIG_FULL_DUPLEX;
- } else if (!phy_interface_mode_is_rgmii(state->interface)) {
- an |= MVPP2_GMAC_AN_SPEED_EN | MVPP2_GMAC_FLOW_CTRL_AUTONEG;
+ ctrl2 |= MVPP2_GMAC_PCS_ENABLE_MASK;
+ ctrl4 &= ~MVPP22_CTRL4_EXT_PIN_GMII_SEL;
+ ctrl4 |= MVPP22_CTRL4_SYNC_BYPASS_DIS |
+ MVPP22_CTRL4_DP_CLK_SEL |
+ MVPP22_CTRL4_QSGMII_BYPASS_ACTIVE;
+ } else if (state->interface == PHY_INTERFACE_MODE_SGMII) {
+ ctrl2 |= MVPP2_GMAC_PCS_ENABLE_MASK | MVPP2_GMAC_INBAND_AN_MASK;
+ ctrl4 &= ~MVPP22_CTRL4_EXT_PIN_GMII_SEL;
+ ctrl4 |= MVPP22_CTRL4_SYNC_BYPASS_DIS |
+ MVPP22_CTRL4_DP_CLK_SEL |
+ MVPP22_CTRL4_QSGMII_BYPASS_ACTIVE;
+ } else if (phy_interface_mode_is_rgmii(state->interface)) {
+ ctrl4 &= ~MVPP22_CTRL4_DP_CLK_SEL;
+ ctrl4 |= MVPP22_CTRL4_EXT_PIN_GMII_SEL |
+ MVPP22_CTRL4_SYNC_BYPASS_DIS |
+ MVPP22_CTRL4_QSGMII_BYPASS_ACTIVE;
}
- if (state->duplex)
- an |= MVPP2_GMAC_CONFIG_FULL_DUPLEX;
+ /* Configure advertisement bits */
if (phylink_test(state->advertising, Pause))
an |= MVPP2_GMAC_FC_ADV_EN;
if (phylink_test(state->advertising, Asym_Pause))
an |= MVPP2_GMAC_FC_ADV_ASM_EN;
- if (phy_interface_mode_is_8023z(state->interface) ||
- state->interface == PHY_INTERFACE_MODE_SGMII) {
- an |= MVPP2_GMAC_IN_BAND_AUTONEG;
- ctrl2 |= MVPP2_GMAC_INBAND_AN_MASK | MVPP2_GMAC_PCS_ENABLE_MASK;
+ /* Configure negotiation style */
+ if (!phylink_autoneg_inband(mode)) {
+ /* Phy or fixed speed - no in-band AN */
+ if (state->duplex)
+ an |= MVPP2_GMAC_CONFIG_FULL_DUPLEX;
- ctrl4 &= ~(MVPP22_CTRL4_EXT_PIN_GMII_SEL |
- MVPP22_CTRL4_RX_FC_EN | MVPP22_CTRL4_TX_FC_EN);
- ctrl4 |= MVPP22_CTRL4_SYNC_BYPASS_DIS |
- MVPP22_CTRL4_DP_CLK_SEL |
- MVPP22_CTRL4_QSGMII_BYPASS_ACTIVE;
+ if (state->speed == SPEED_1000 || state->speed == SPEED_2500)
+ an |= MVPP2_GMAC_CONFIG_GMII_SPEED;
+ else if (state->speed == SPEED_100)
+ an |= MVPP2_GMAC_CONFIG_MII_SPEED;
if (state->pause & MLO_PAUSE_TX)
ctrl4 |= MVPP22_CTRL4_TX_FC_EN;
if (state->pause & MLO_PAUSE_RX)
ctrl4 |= MVPP22_CTRL4_RX_FC_EN;
- } else if (phy_interface_mode_is_rgmii(state->interface)) {
- an |= MVPP2_GMAC_IN_BAND_AUTONEG_BYPASS;
+ } else if (state->interface == PHY_INTERFACE_MODE_SGMII) {
+ /* SGMII in-band mode receives the speed and duplex from
+ * the PHY. Flow control information is not received. */
+ an &= ~(MVPP2_GMAC_FORCE_LINK_DOWN | MVPP2_GMAC_FORCE_LINK_PASS);
+ an |= MVPP2_GMAC_IN_BAND_AUTONEG |
+ MVPP2_GMAC_AN_SPEED_EN |
+ MVPP2_GMAC_AN_DUPLEX_EN;
- if (state->speed == SPEED_1000)
- an |= MVPP2_GMAC_CONFIG_GMII_SPEED;
- else if (state->speed == SPEED_100)
- an |= MVPP2_GMAC_CONFIG_MII_SPEED;
+ if (state->pause & MLO_PAUSE_TX)
+ ctrl4 |= MVPP22_CTRL4_TX_FC_EN;
+ if (state->pause & MLO_PAUSE_RX)
+ ctrl4 |= MVPP22_CTRL4_RX_FC_EN;
+ } else if (phy_interface_mode_is_8023z(state->interface)) {
+ /* 1000BaseX and 2500BaseX ports cannot negotiate speed nor can
+ * they negotiate duplex: they are always operating with a fixed
+ * speed of 1000/2500Mbps in full duplex, so force 1000/2500
+ * speed and full duplex here.
+ */
+ ctrl0 |= MVPP2_GMAC_PORT_TYPE_MASK;
+ an &= ~(MVPP2_GMAC_FORCE_LINK_DOWN | MVPP2_GMAC_FORCE_LINK_PASS);
+ an |= MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_CONFIG_FULL_DUPLEX;
- ctrl4 &= ~MVPP22_CTRL4_DP_CLK_SEL;
- ctrl4 |= MVPP22_CTRL4_EXT_PIN_GMII_SEL |
- MVPP22_CTRL4_SYNC_BYPASS_DIS |
- MVPP22_CTRL4_QSGMII_BYPASS_ACTIVE;
+ if (state->pause & MLO_PAUSE_AN && state->an_enabled) {
+ an |= MVPP2_GMAC_FLOW_CTRL_AUTONEG;
+ } else {
+ if (state->pause & MLO_PAUSE_TX)
+ ctrl4 |= MVPP22_CTRL4_TX_FC_EN;
+ if (state->pause & MLO_PAUSE_RX)
+ ctrl4 |= MVPP22_CTRL4_RX_FC_EN;
+ }
}
writel(ctrl0, port->base + MVPP2_GMAC_CTRL_0_REG);
@@ -4685,8 +4711,7 @@ static void mvpp2_mac_link_up(struct net_device *dev, unsigned int mode,
interface != PHY_INTERFACE_MODE_10GKR) {
val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
val &= ~MVPP2_GMAC_FORCE_LINK_DOWN;
- if (phy_interface_mode_is_rgmii(interface))
- val |= MVPP2_GMAC_FORCE_LINK_PASS;
+ val |= MVPP2_GMAC_FORCE_LINK_PASS;
writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
}
--
2.7.4
^ permalink raw reply related
* [PATCH 2/5] net: marvell: mvpp2: fix stuck in-band SGMII negotiation
From: Russell King @ 2019-02-08 15:35 UTC (permalink / raw)
To: Antoine Tenart, Maxime Chevallier
Cc: Baruch Siach, Sven Auhagen, David S. Miller, netdev
In-Reply-To: <20190208153432.igh26ubphiljsswa@shell.armlinux.org.uk>
It appears that the mvpp22 can get stuck with SGMII negotiation. The
symptoms are that in-band negotiation never completes and the partner
(eg, PHY) never reports SGMII link up, or if it supports negotiation
bypass, goes into negotiation bypass mode (which will happen when the
PHY sees that the MAC is alive but gets no response.)
Triggering the PHY end of the link to re-negotiate results in the
bypass bit clearing on the PHY, and then re-setting - indicating that
the problem is at the mvpp22 GMAC end.
Asserting the GMAC reset and de-asserting it resolves the issue.
Arrange to assert the GMAC reset at probe time, and deassert it only
after we have configured the GMAC for the appropriate mode. This
resolves the issue.
Tested-by: Sven Auhagen <sven.auhagen@voleatech.de>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index c590dc7ba70a..1cb5023b2575 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -1392,13 +1392,9 @@ static void mvpp2_port_reset(struct mvpp2_port *port)
for (i = 0; i < ARRAY_SIZE(mvpp2_ethtool_regs); i++)
mvpp2_read_count(port, &mvpp2_ethtool_regs[i]);
- val = readl(port->base + MVPP2_GMAC_CTRL_2_REG) &
- ~MVPP2_GMAC_PORT_RESET_MASK;
+ val = readl(port->base + MVPP2_GMAC_CTRL_2_REG) |
+ MVPP2_GMAC_PORT_RESET_MASK;
writel(val, port->base + MVPP2_GMAC_CTRL_2_REG);
-
- while (readl(port->base + MVPP2_GMAC_CTRL_2_REG) &
- MVPP2_GMAC_PORT_RESET_MASK)
- continue;
}
/* Change maximum receive size of the port */
@@ -4554,12 +4550,15 @@ static void mvpp2_gmac_config(struct mvpp2_port *port, unsigned int mode,
const struct phylink_link_state *state)
{
u32 an, ctrl0, ctrl2, ctrl4;
+ u32 old_ctrl2;
an = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
ctrl0 = readl(port->base + MVPP2_GMAC_CTRL_0_REG);
ctrl2 = readl(port->base + MVPP2_GMAC_CTRL_2_REG);
ctrl4 = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
+ old_ctrl2 = ctrl2;
+
/* Force link down */
an &= ~MVPP2_GMAC_FORCE_LINK_PASS;
an |= MVPP2_GMAC_FORCE_LINK_DOWN;
@@ -4656,6 +4655,12 @@ static void mvpp2_gmac_config(struct mvpp2_port *port, unsigned int mode,
writel(ctrl2, port->base + MVPP2_GMAC_CTRL_2_REG);
writel(ctrl4, port->base + MVPP22_GMAC_CTRL_4_REG);
writel(an, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+
+ if (old_ctrl2 & MVPP2_GMAC_PORT_RESET_MASK) {
+ while (readl(port->base + MVPP2_GMAC_CTRL_2_REG) &
+ MVPP2_GMAC_PORT_RESET_MASK)
+ continue;
+ }
}
static void mvpp2_mac_config(struct net_device *dev, unsigned int mode,
--
2.7.4
^ permalink raw reply related
* [PATCH 3/5] net: marvell: mvpp2: only reprogram what is necessary on mac_config
From: Russell King @ 2019-02-08 15:35 UTC (permalink / raw)
To: Antoine Tenart, Maxime Chevallier
Cc: Baruch Siach, Sven Auhagen, David S. Miller, netdev
In-Reply-To: <20190208153432.igh26ubphiljsswa@shell.armlinux.org.uk>
mac_config() can be called at any point, and the expected behaviour
from MAC drivers is to only reprogram when necessary - and certainly
avoid taking the link down on every call.
Unfortunately, mvpp2 does exactly that - it takes the link down, and
reprograms everything, and then releases the forced-link down.
This is bad, it can cause the link to bounce:
- SFP detects signal, disables LOS indication.
- SFP code calls into phylink, calling phylink_sfp_link_up() which
triggers a resolve.
- phylink_resolve() calls phylink_get_mac_state() and finds the MAC
reporting link up.
- phylink wants to configure the pause mode on the MAC, so calls
phylink_mac_config()
- mvpp2 takes the link down temporarily, generating a MAC link down
event followed by another MAC link event.
- phylink calls mac_link_up() and then processes the MAC link down
event.
- phylink_resolve() gets called again, registers the link down, and
calls mach_link_down() before re-running itself.
- phylink_resolve() starts again at step 3 above. This sequence
repeats.
GMAC versions prior to mvpp2 do not require the link to be taken down
except when certain link properties (eg, switching between SGMII and
1000base-X mode, or enabling/disabling in-band negotiation) are
changed. Implement this for mvpp2.
Tested-by: Sven Auhagen <sven.auhagen@voleatech.de>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 58 +++++++++++++++----------
1 file changed, 35 insertions(+), 23 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 1cb5023b2575..624514bc1681 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -4549,29 +4549,21 @@ static void mvpp2_xlg_config(struct mvpp2_port *port, unsigned int mode,
static void mvpp2_gmac_config(struct mvpp2_port *port, unsigned int mode,
const struct phylink_link_state *state)
{
- u32 an, ctrl0, ctrl2, ctrl4;
- u32 old_ctrl2;
+ u32 old_an, an;
+ u32 old_ctrl0, ctrl0;
+ u32 old_ctrl2, ctrl2;
+ u32 old_ctrl4, ctrl4;
- an = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
- ctrl0 = readl(port->base + MVPP2_GMAC_CTRL_0_REG);
- ctrl2 = readl(port->base + MVPP2_GMAC_CTRL_2_REG);
- ctrl4 = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
-
- old_ctrl2 = ctrl2;
-
- /* Force link down */
- an &= ~MVPP2_GMAC_FORCE_LINK_PASS;
- an |= MVPP2_GMAC_FORCE_LINK_DOWN;
- writel(an, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
-
- /* Set the GMAC in a reset state */
- ctrl2 |= MVPP2_GMAC_PORT_RESET_MASK;
- writel(ctrl2, port->base + MVPP2_GMAC_CTRL_2_REG);
+ old_an = an = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+ old_ctrl0 = ctrl0 = readl(port->base + MVPP2_GMAC_CTRL_0_REG);
+ old_ctrl2 = ctrl2 = readl(port->base + MVPP2_GMAC_CTRL_2_REG);
+ old_ctrl4 = ctrl4 = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
an &= ~(MVPP2_GMAC_CONFIG_MII_SPEED | MVPP2_GMAC_CONFIG_GMII_SPEED |
MVPP2_GMAC_AN_SPEED_EN | MVPP2_GMAC_FC_ADV_EN |
MVPP2_GMAC_FC_ADV_ASM_EN | MVPP2_GMAC_FLOW_CTRL_AUTONEG |
- MVPP2_GMAC_CONFIG_FULL_DUPLEX | MVPP2_GMAC_AN_DUPLEX_EN);
+ MVPP2_GMAC_CONFIG_FULL_DUPLEX | MVPP2_GMAC_AN_DUPLEX_EN |
+ MVPP2_GMAC_IN_BAND_AUTONEG | MVPP2_GMAC_IN_BAND_AUTONEG_BYPASS);
ctrl0 &= ~MVPP2_GMAC_PORT_TYPE_MASK;
ctrl2 &= ~(MVPP2_GMAC_INBAND_AN_MASK | MVPP2_GMAC_PORT_RESET_MASK |
MVPP2_GMAC_PCS_ENABLE_MASK);
@@ -4638,7 +4630,8 @@ static void mvpp2_gmac_config(struct mvpp2_port *port, unsigned int mode,
*/
ctrl0 |= MVPP2_GMAC_PORT_TYPE_MASK;
an &= ~(MVPP2_GMAC_FORCE_LINK_DOWN | MVPP2_GMAC_FORCE_LINK_PASS);
- an |= MVPP2_GMAC_CONFIG_GMII_SPEED |
+ an |= MVPP2_GMAC_IN_BAND_AUTONEG |
+ MVPP2_GMAC_CONFIG_GMII_SPEED |
MVPP2_GMAC_CONFIG_FULL_DUPLEX;
if (state->pause & MLO_PAUSE_AN && state->an_enabled) {
@@ -4651,10 +4644,29 @@ static void mvpp2_gmac_config(struct mvpp2_port *port, unsigned int mode,
}
}
- writel(ctrl0, port->base + MVPP2_GMAC_CTRL_0_REG);
- writel(ctrl2, port->base + MVPP2_GMAC_CTRL_2_REG);
- writel(ctrl4, port->base + MVPP22_GMAC_CTRL_4_REG);
- writel(an, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+ if ((old_ctrl0 ^ ctrl0) & MVPP2_GMAC_PORT_TYPE_MASK ||
+ (old_ctrl2 ^ ctrl2) & MVPP2_GMAC_INBAND_AN_MASK ||
+ (old_an ^ an) & MVPP2_GMAC_IN_BAND_AUTONEG) {
+ /* Force link down */
+ old_an &= ~MVPP2_GMAC_FORCE_LINK_PASS;
+ old_an |= MVPP2_GMAC_FORCE_LINK_DOWN;
+ writel(old_an, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+
+ /* Set the GMAC in a reset state - do this in a way that
+ * ensures we clear it below.
+ */
+ old_ctrl2 |= MVPP2_GMAC_PORT_RESET_MASK;
+ writel(old_ctrl2, port->base + MVPP2_GMAC_CTRL_2_REG);
+ }
+
+ if (old_ctrl0 != ctrl0)
+ writel(ctrl0, port->base + MVPP2_GMAC_CTRL_0_REG);
+ if (old_ctrl2 != ctrl2)
+ writel(ctrl2, port->base + MVPP2_GMAC_CTRL_2_REG);
+ if (old_ctrl4 != ctrl4)
+ writel(ctrl4, port->base + MVPP22_GMAC_CTRL_4_REG);
+ if (old_an != an)
+ writel(an, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
if (old_ctrl2 & MVPP2_GMAC_PORT_RESET_MASK) {
while (readl(port->base + MVPP2_GMAC_CTRL_2_REG) &
--
2.7.4
^ permalink raw reply related
* [PATCH 4/5] net: marvell: mvpp2: read correct pause bits
From: Russell King @ 2019-02-08 15:35 UTC (permalink / raw)
To: Antoine Tenart, Maxime Chevallier
Cc: Baruch Siach, Sven Auhagen, David S. Miller, netdev
In-Reply-To: <20190208153432.igh26ubphiljsswa@shell.armlinux.org.uk>
When reading the pause bits in mac_link_state, mvpp2 was reporting
the state of the "active pause" bits, which are set when the MAC is
in pause mode. This is not what phylink wants - we want the
negotiated pause state. Fix the definition so we read the correct
bits.
Tested-by: Sven Auhagen <sven.auhagen@voleatech.de>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 398328f10743..96e3f0669032 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -402,8 +402,8 @@
#define MVPP2_GMAC_STATUS0_GMII_SPEED BIT(1)
#define MVPP2_GMAC_STATUS0_MII_SPEED BIT(2)
#define MVPP2_GMAC_STATUS0_FULL_DUPLEX BIT(3)
-#define MVPP2_GMAC_STATUS0_RX_PAUSE BIT(6)
-#define MVPP2_GMAC_STATUS0_TX_PAUSE BIT(7)
+#define MVPP2_GMAC_STATUS0_RX_PAUSE BIT(4)
+#define MVPP2_GMAC_STATUS0_TX_PAUSE BIT(5)
#define MVPP2_GMAC_STATUS0_AN_COMPLETE BIT(11)
#define MVPP2_GMAC_PORT_FIFO_CFG_1_REG 0x1c
#define MVPP2_GMAC_TX_FIFO_MIN_TH_OFFS 6
--
2.7.4
^ permalink raw reply related
* [PATCH 5/5] net: marvell: mvpp2: fix AN restart
From: Russell King @ 2019-02-08 15:35 UTC (permalink / raw)
To: Antoine Tenart, Maxime Chevallier
Cc: Baruch Siach, Sven Auhagen, David S. Miller, netdev
In-Reply-To: <20190208153432.igh26ubphiljsswa@shell.armlinux.org.uk>
phylink already limits which interface modes are able to call the
MACs AN restart function, but in any case, the commentry seems
incorrect: the AN restart bit does not automatically clear when
set. This has been found via manual setting using devmem2, and
we can observe that the AN does indeed restart and complete, yet
the AN restart bit remains set. Explicitly clear the AN restart
bit.
Tested-by: Sven Auhagen <sven.auhagen@voleatech.de>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 15 +++++----------
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 624514bc1681..93fed4080dbf 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -4512,17 +4512,12 @@ static int mvpp2_phylink_mac_link_state(struct net_device *dev,
static void mvpp2_mac_an_restart(struct net_device *dev)
{
struct mvpp2_port *port = netdev_priv(dev);
- u32 val;
-
- if (port->phy_interface != PHY_INTERFACE_MODE_SGMII)
- return;
+ u32 val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
- val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
- /* The RESTART_AN bit is cleared by the h/w after restarting the AN
- * process.
- */
- val |= MVPP2_GMAC_IN_BAND_RESTART_AN | MVPP2_GMAC_IN_BAND_AUTONEG;
- writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+ writel(val | MVPP2_GMAC_IN_BAND_RESTART_AN,
+ port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+ writel(val & ~MVPP2_GMAC_IN_BAND_RESTART_AN,
+ port->base + MVPP2_GMAC_AUTONEG_CONFIG);
}
static void mvpp2_xlg_config(struct mvpp2_port *port, unsigned int mode,
--
2.7.4
^ permalink raw reply related
* [PATCH RFC] net: marvell: mvpp2: phylink requires the link interrupt
From: Russell King @ 2019-02-08 15:39 UTC (permalink / raw)
To: Antoine Tenart, Maxime Chevallier
Cc: Baruch Siach, Sven Auhagen, David S. Miller, netdev
phylink requires the MAC to report when its link status changes when
operating in inband modes. Failure to report link status changes
means that phylink has no idea when the link events happen, which
results in either the network interface's carrier remaining up or
remaining permanently down.
For example, with a fiber module, if the interface is brought up and
link is initially established, taking the link down at the far end
will cut the optical power. The SFP module's LOS asserts, we
deactivate the link, and the network interface reports no carrier.
When the far end is brought back up, the SFP module's LOS deasserts,
but the MAC may be slower to establish link. If this happens (which
in my tests is a certainty) then phylink never hears that the MAC
has established link with the far end, and the network interface is
stuck reporting no carrier. This means the interface is
non-functional.
Avoiding the link interrupt when we have phylink is basically not
an option, so remove the !port->phylink from the test.
Tested-by: Sven Auhagen <sven.auhagen@voleatech.de>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
This is the final patch that I mentioned in the cover letter
"[PATCH net-next 0/5] mvpp2 phylink fixes"
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 93fed4080dbf..0b164b424dca 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -3412,7 +3412,7 @@ static int mvpp2_open(struct net_device *dev)
valid = true;
}
- if (priv->hw_version == MVPP22 && port->link_irq && !port->phylink) {
+ if (priv->hw_version == MVPP22 && port->link_irq) {
err = request_irq(port->link_irq, mvpp2_link_status_isr, 0,
dev->name, port);
if (err) {
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next] nfp: flower: cmsg: use struct_size() helper
From: Jakub Kicinski @ 2019-02-08 15:51 UTC (permalink / raw)
To: Gustavo A. R. Silva; +Cc: David S. Miller, oss-drivers, netdev, linux-kernel
In-Reply-To: <20190208034725.GA12043@embeddedor>
On Thu, 7 Feb 2019 21:47:25 -0600, Gustavo A. R. Silva wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> void *entry[];
> };
>
> size = sizeof(struct foo) + count * sizeof(void *);
> instance = alloc(size, GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = alloc(struct_size(instance, entry, count), GFP_KERNEL);
>
> Notice that, in this case, variable size is not necessary, hence
> it is removed.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.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