* Re: [patch net-next v2 05/19] net: bridge: Add support for notifying devices about FDB add/del
From: Ivan Vecera @ 2017-06-08 9:30 UTC (permalink / raw)
To: Jiri Pirko, netdev; +Cc: davem, idosch, arkadis, mlxsw, roopa, stephen, nikolay
In-Reply-To: <20170608064428.4785-6-jiri@resnulli.us>
On 8.6.2017 08:44, Jiri Pirko wrote:
> From: Arkadi Sharshevsky <arkadis@mellanox.com>
>
> Currently the bridge doesn't notify the underlying devices about new
> FDBs learned. The FDB sync is placed on the switchdev notifier chain
> because devices may potentially learn FDB that are not directly related
> to their ports, for example:
>
> 1. Mixed SW/HW bridge - FDBs that point to the ASICs external devices
> should be offloaded as CPU traps in order to
> perform forwarding in slow path.
> 2. EVPN - Externally learned FDBs for the vtep device.
>
> Notification is sent only about static FDB add/del. This is done due
> to fact that currently this is the only scenario supported by switch
> drivers.
>
> Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>
> Reviewed-by: Ido Schimmel <idosch@mellanox.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> ---
> .../ethernet/mellanox/mlxsw/spectrum_switchdev.c | 2 +-
> drivers/net/ethernet/rocker/rocker_ofdpa.c | 4 +--
> include/net/switchdev.h | 6 ++--
> net/bridge/br.c | 4 +--
> net/bridge/br_fdb.c | 2 ++
> net/bridge/br_private.h | 7 +++++
> net/bridge/br_switchdev.c | 33 ++++++++++++++++++++++
> 7 files changed, 51 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
> index edcc273..0111a77 100644
> --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
> +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
> @@ -1867,7 +1867,7 @@ static void mlxsw_sp_fdb_call_notifiers(bool learning_sync, bool adding,
> if (learning_sync) {
> info.addr = mac;
> info.vid = vid;
> - notifier_type = adding ? SWITCHDEV_FDB_ADD : SWITCHDEV_FDB_DEL;
> + notifier_type = adding ? SWITCHDEV_FDB_ADD_TO_BRIDGE : SWITCHDEV_FDB_DEL_TO_BRIDGE;
> call_switchdev_notifiers(notifier_type, dev, &info.info);
> }
> }
> diff --git a/drivers/net/ethernet/rocker/rocker_ofdpa.c b/drivers/net/ethernet/rocker/rocker_ofdpa.c
> index 2ae8524..f659dad 100644
> --- a/drivers/net/ethernet/rocker/rocker_ofdpa.c
> +++ b/drivers/net/ethernet/rocker/rocker_ofdpa.c
> @@ -1939,10 +1939,10 @@ static void ofdpa_port_fdb_learn_work(struct work_struct *work)
>
> rtnl_lock();
> if (learned && removing)
> - call_switchdev_notifiers(SWITCHDEV_FDB_DEL,
> + call_switchdev_notifiers(SWITCHDEV_FDB_DEL_TO_BRIDGE,
> lw->ofdpa_port->dev, &info.info);
> else if (learned && !removing)
> - call_switchdev_notifiers(SWITCHDEV_FDB_ADD,
> + call_switchdev_notifiers(SWITCHDEV_FDB_ADD_TO_BRIDGE,
> lw->ofdpa_port->dev, &info.info);
> rtnl_unlock();
>
> diff --git a/include/net/switchdev.h b/include/net/switchdev.h
> index 63a754d..8165ed9 100644
> --- a/include/net/switchdev.h
> +++ b/include/net/switchdev.h
> @@ -155,8 +155,10 @@ struct switchdev_ops {
> };
>
> enum switchdev_notifier_type {
> - SWITCHDEV_FDB_ADD = 1,
> - SWITCHDEV_FDB_DEL,
> + SWITCHDEV_FDB_ADD_TO_BRIDGE = 1,
> + SWITCHDEV_FDB_DEL_TO_BRIDGE,
> + SWITCHDEV_FDB_ADD_TO_DEVICE,
> + SWITCHDEV_FDB_DEL_TO_DEVICE,
> };
>
> struct switchdev_notifier_info {
> diff --git a/net/bridge/br.c b/net/bridge/br.c
> index e962fff..96d209c 100644
> --- a/net/bridge/br.c
> +++ b/net/bridge/br.c
> @@ -138,14 +138,14 @@ static int br_switchdev_event(struct notifier_block *unused,
> br = p->br;
>
> switch (event) {
> - case SWITCHDEV_FDB_ADD:
> + case SWITCHDEV_FDB_ADD_TO_BRIDGE:
> fdb_info = ptr;
> err = br_fdb_external_learn_add(br, p, fdb_info->addr,
> fdb_info->vid);
> if (err)
> err = notifier_from_errno(err);
> break;
> - case SWITCHDEV_FDB_DEL:
> + case SWITCHDEV_FDB_DEL_TO_BRIDGE:
> fdb_info = ptr;
> err = br_fdb_external_learn_del(br, p, fdb_info->addr,
> fdb_info->vid);
> diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
> index 5c780cd..26a1dae 100644
> --- a/net/bridge/br_fdb.c
> +++ b/net/bridge/br_fdb.c
> @@ -690,6 +690,8 @@ static void fdb_notify(struct net_bridge *br,
> struct sk_buff *skb;
> int err = -ENOBUFS;
>
> + br_switchdev_fdb_notify(fdb, type);
> +
> skb = nlmsg_new(fdb_nlmsg_size(), GFP_ATOMIC);
> if (skb == NULL)
> goto errout;
> diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> index a122684..98410ea 100644
> --- a/net/bridge/br_private.h
> +++ b/net/bridge/br_private.h
> @@ -1085,6 +1085,8 @@ bool nbp_switchdev_allowed_egress(const struct net_bridge_port *p,
> int br_switchdev_set_port_flag(struct net_bridge_port *p,
> unsigned long flags,
> unsigned long mask);
> +void br_switchdev_fdb_notify(const struct net_bridge_fdb_entry *fdb,
> + int type);
> #else
> static inline int nbp_switchdev_mark_set(struct net_bridge_port *p)
> {
> @@ -1108,6 +1110,11 @@ static inline int br_switchdev_set_port_flag(struct net_bridge_port *p,
> {
> return 0;
> }
> +
> +static inline void
> +br_switchdev_fdb_notify(const struct net_bridge_fdb_entry *fdb, int type)
> +{
> +}
> #endif /* CONFIG_NET_SWITCHDEV */
>
> #endif
> diff --git a/net/bridge/br_switchdev.c b/net/bridge/br_switchdev.c
> index b975959..181a44d 100644
> --- a/net/bridge/br_switchdev.c
> +++ b/net/bridge/br_switchdev.c
> @@ -98,3 +98,36 @@ int br_switchdev_set_port_flag(struct net_bridge_port *p,
>
> return 0;
> }
> +
> +static void
> +br_switchdev_fdb_call_notifiers(bool adding, const unsigned char *mac,
> + u16 vid, struct net_device *dev)
> +{
> + struct switchdev_notifier_fdb_info info;
> + unsigned long notifier_type;
> +
> + info.addr = mac;
> + info.vid = vid;
> + notifier_type = adding ? SWITCHDEV_FDB_ADD_TO_DEVICE : SWITCHDEV_FDB_DEL_TO_DEVICE;
> + call_switchdev_notifiers(notifier_type, dev, &info.info);
> +}
> +
> +void
> +br_switchdev_fdb_notify(const struct net_bridge_fdb_entry *fdb, int type)
> +{
> + if (!fdb->added_by_user)
> + return;
> +
> + switch (type) {
> + case RTM_DELNEIGH:
> + br_switchdev_fdb_call_notifiers(false, fdb->addr.addr,
> + fdb->vlan_id,
> + fdb->dst->dev);
> + break;
> + case RTM_NEWNEIGH:
> + br_switchdev_fdb_call_notifiers(true, fdb->addr.addr,
> + fdb->vlan_id,
> + fdb->dst->dev);
> + break;
> + }
> +}
>
Reviewed-by: Ivan Vecera <ivecera@redhat.com>
^ permalink raw reply
* Re: [PATCH RFC net-next 4/4] net/mlx5: Add CONFIG_MLX5_ESWITCH Kconfig
From: Or Gerlitz @ 2017-06-08 9:35 UTC (permalink / raw)
To: Saeed Mahameed; +Cc: Linux Netdev List, Jes Sorensen, Kernel Team, Or Gerlitz
In-Reply-To: <20170607234214.24723-5-saeedm@mellanox.com>
On Thu, Jun 8, 2017 at 2:42 AM, Saeed Mahameed <saeedm@mellanox.com> wrote:
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> @@ -2961,9 +2961,8 @@ static int mlx5e_modify_channels_vsd(struct mlx5e_channels *chs, bool vsd)
> return 0;
> }
>
> -static int mlx5e_setup_tc(struct net_device *netdev, u8 tc)
> +static int mlx5e_setup_tc(struct mlx5e_priv *priv, u8 tc)
> {
> - struct mlx5e_priv *priv = netdev_priv(netdev);
> struct mlx5e_channels new_channels = {};
> int err = 0;
>
> @@ -2995,6 +2994,7 @@ static int mlx5e_ndo_setup_tc(struct net_device *dev, u32 handle,
> {
> struct mlx5e_priv *priv = netdev_priv(dev);
>
> +#ifdef CONFIG_MLX5_ESWITCH
> if (TC_H_MAJ(handle) != TC_H_MAJ(TC_H_INGRESS))
> goto mqprio;
>
> @@ -3013,12 +3013,13 @@ static int mlx5e_ndo_setup_tc(struct net_device *dev, u32 handle,
> }
>
> mqprio:
> +#endif
> if (tc->type != TC_SETUP_MQPRIO)
> - return -EINVAL;
> + return -EOPNOTSUPP;
why change this corner in this patch? we're doing enough changes
>
> tc->mqprio->hw = TC_MQPRIO_HW_OFFLOAD_TCS;
>
> - return mlx5e_setup_tc(dev, tc->mqprio->num_tc);
> + return mlx5e_setup_tc(priv, tc->mqprio->num_tc);
> }
same comment
> --- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
> @@ -948,13 +946,11 @@ static int mlx5_init_once(struct mlx5_core_dev *dev, struct mlx5_priv *priv)
> goto err_rl_cleanup;
> }
>
> -#ifdef CONFIG_MLX5_CORE_EN
> err = mlx5_eswitch_init(dev);
> if (err) {
> dev_err(&pdev->dev, "Failed to init eswitch %d\n", err);
> goto err_mpfs_cleanup;
> }
> -#endif
why? before this patch we were doing it only if Ethernet
(MLX5_CORE_EN) was defined into the build,
and now we are returning blindly zero if another config isn't there
(CONFIG_MLX5_ESWITCH) - is that
fully equivalent? do we want to be fully equiv?
> @@ -965,10 +961,8 @@ static int mlx5_init_once(struct mlx5_core_dev *dev, struct mlx5_priv *priv)
> return 0;
>
> err_eswitch_cleanup:
> -#ifdef CONFIG_MLX5_CORE_EN
> mlx5_eswitch_cleanup(dev->priv.eswitch);
> err_mpfs_cleanup:
> -#endif
same comment/question
^ permalink raw reply
* [PATCH v2 1/8] net: mvmdio: reorder headers alphabetically
From: Antoine Tenart @ 2017-06-08 9:26 UTC (permalink / raw)
To: davem, jason, andrew, gregory.clement, sebastian.hesselbarth,
f.fainelli
Cc: Antoine Tenart, thomas.petazzoni, mw, linux, netdev,
linux-arm-kernel
In-Reply-To: <20170608092653.25221-1-antoine.tenart@free-electrons.com>
Cosmetic fix reordering headers alphabetically.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/marvell/mvmdio.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index 90a60b98c28e..109a2bff334d 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -17,16 +17,16 @@
* warranty of any kind, whether express or implied.
*/
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/mutex.h>
+#include <linux/of_mdio.h>
#include <linux/phy.h>
-#include <linux/interrupt.h>
#include <linux/platform_device.h>
-#include <linux/delay.h>
-#include <linux/io.h>
-#include <linux/clk.h>
-#include <linux/of_mdio.h>
#include <linux/sched.h>
#include <linux/wait.h>
--
2.9.4
^ permalink raw reply related
* [PATCH v2 2/8] net: mvmdio: use tabs for defines
From: Antoine Tenart @ 2017-06-08 9:26 UTC (permalink / raw)
To: davem, jason, andrew, gregory.clement, sebastian.hesselbarth,
f.fainelli
Cc: Antoine Tenart, thomas.petazzoni, mw, linux, netdev,
linux-arm-kernel
In-Reply-To: <20170608092653.25221-1-antoine.tenart@free-electrons.com>
Cosmetic patch replacing spaces by tabs for defined values.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/marvell/mvmdio.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index 109a2bff334d..17b518b13ae3 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -30,25 +30,25 @@
#include <linux/sched.h>
#include <linux/wait.h>
-#define MVMDIO_SMI_DATA_SHIFT 0
-#define MVMDIO_SMI_PHY_ADDR_SHIFT 16
-#define MVMDIO_SMI_PHY_REG_SHIFT 21
-#define MVMDIO_SMI_READ_OPERATION BIT(26)
-#define MVMDIO_SMI_WRITE_OPERATION 0
-#define MVMDIO_SMI_READ_VALID BIT(27)
-#define MVMDIO_SMI_BUSY BIT(28)
-#define MVMDIO_ERR_INT_CAUSE 0x007C
-#define MVMDIO_ERR_INT_SMI_DONE 0x00000010
-#define MVMDIO_ERR_INT_MASK 0x0080
+#define MVMDIO_SMI_DATA_SHIFT 0
+#define MVMDIO_SMI_PHY_ADDR_SHIFT 16
+#define MVMDIO_SMI_PHY_REG_SHIFT 21
+#define MVMDIO_SMI_READ_OPERATION BIT(26)
+#define MVMDIO_SMI_WRITE_OPERATION 0
+#define MVMDIO_SMI_READ_VALID BIT(27)
+#define MVMDIO_SMI_BUSY BIT(28)
+#define MVMDIO_ERR_INT_CAUSE 0x007C
+#define MVMDIO_ERR_INT_SMI_DONE 0x00000010
+#define MVMDIO_ERR_INT_MASK 0x0080
/*
* SMI Timeout measurements:
* - Kirkwood 88F6281 (Globalscale Dreamplug): 45us to 95us (Interrupt)
* - Armada 370 (Globalscale Mirabox): 41us to 43us (Polled)
*/
-#define MVMDIO_SMI_TIMEOUT 1000 /* 1000us = 1ms */
-#define MVMDIO_SMI_POLL_INTERVAL_MIN 45
-#define MVMDIO_SMI_POLL_INTERVAL_MAX 55
+#define MVMDIO_SMI_TIMEOUT 1000 /* 1000us = 1ms */
+#define MVMDIO_SMI_POLL_INTERVAL_MIN 45
+#define MVMDIO_SMI_POLL_INTERVAL_MAX 55
struct orion_mdio_dev {
struct mutex lock;
--
2.9.4
^ permalink raw reply related
* [PATCH v2 3/8] net: mvmdio: use GENMASK for masks
From: Antoine Tenart @ 2017-06-08 9:26 UTC (permalink / raw)
To: davem, jason, andrew, gregory.clement, sebastian.hesselbarth,
f.fainelli
Cc: Antoine Tenart, thomas.petazzoni, mw, linux, netdev,
linux-arm-kernel
In-Reply-To: <20170608092653.25221-1-antoine.tenart@free-electrons.com>
Cosmetic patch to use the GENMASK helper for masks.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/marvell/mvmdio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index 17b518b13ae3..96af8d57d9e5 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -138,7 +138,7 @@ static int orion_mdio_read(struct mii_bus *bus, int mii_id,
goto out;
}
- ret = val & 0xFFFF;
+ ret = val & GENMASK(15,0);
out:
mutex_unlock(&dev->lock);
return ret;
--
2.9.4
^ permalink raw reply related
* [PATCH v2 4/8] net: mvmdio: move the read valid check into its own function
From: Antoine Tenart @ 2017-06-08 9:26 UTC (permalink / raw)
To: davem, jason, andrew, gregory.clement, sebastian.hesselbarth,
f.fainelli
Cc: Antoine Tenart, thomas.petazzoni, mw, linux, netdev,
linux-arm-kernel
In-Reply-To: <20170608092653.25221-1-antoine.tenart@free-electrons.com>
Move the read valid check in its own function. This is needed as a
requirement to factorize the driver to add the xMDIO support in the
future.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
drivers/net/ethernet/marvell/mvmdio.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index 96af8d57d9e5..6cbdb221c1ab 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -69,6 +69,11 @@ static int orion_mdio_smi_is_done(struct orion_mdio_dev *dev)
return !(readl(dev->regs) & MVMDIO_SMI_BUSY);
}
+static int orion_mdio_smi_is_read_valid(struct orion_mdio_dev *dev)
+{
+ return readl(dev->regs) & MVMDIO_SMI_READ_VALID;
+}
+
/* Wait for the SMI unit to be ready for another operation
*/
static int orion_mdio_wait_ready(struct mii_bus *bus)
@@ -113,7 +118,6 @@ static int orion_mdio_read(struct mii_bus *bus, int mii_id,
int regnum)
{
struct orion_mdio_dev *dev = bus->priv;
- u32 val;
int ret;
mutex_lock(&dev->lock);
@@ -131,14 +135,13 @@ static int orion_mdio_read(struct mii_bus *bus, int mii_id,
if (ret < 0)
goto out;
- val = readl(dev->regs);
- if (!(val & MVMDIO_SMI_READ_VALID)) {
+ if (!orion_mdio_smi_is_read_valid(dev)) {
dev_err(bus->parent, "SMI bus read not valid\n");
ret = -ENODEV;
goto out;
}
- ret = val & GENMASK(15,0);
+ ret = readl(dev->regs) & GENMASK(15,0);
out:
mutex_unlock(&dev->lock);
return ret;
--
2.9.4
^ permalink raw reply related
* [PATCH v2 8/8] arm64: marvell: dts: add xmdio nodes for 7k/8k
From: Antoine Tenart @ 2017-06-08 9:26 UTC (permalink / raw)
To: davem, jason, andrew, gregory.clement, sebastian.hesselbarth,
f.fainelli
Cc: Antoine Tenart, thomas.petazzoni, mw, linux, netdev,
linux-arm-kernel
In-Reply-To: <20170608092653.25221-1-antoine.tenart@free-electrons.com>
Add the description of the xMDIO bus for the Marvell Armada 7k and
Marvell Armada 8k; for both CP110 slave and master. This bus is found
on Marvell Ethernet controllers and provides an interface with the
xMDIO bus.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
@Dave: patch 8 should go through the mvebu tree as asked by Gregory,
thanks!
arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 8 ++++++++
arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 8 ++++++++
2 files changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
index 037ed30d75a7..ab728aacdfae 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
@@ -98,6 +98,14 @@
clocks = <&cpm_syscon0 1 9>, <&cpm_syscon0 1 5>;
};
+ cpm_xmdio: mdio@12a600 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,orion-mdio";
+ reg = <0x12a600 0x10>;
+ status = "disabled";
+ };
+
cpm_icu: interrupt-controller@1e0000 {
compatible = "marvell,cp110-icu";
reg = <0x1e0000 0x10>;
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
index 2a99ff8fca2a..89af7a31e622 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
@@ -103,6 +103,14 @@
clocks = <&cps_syscon0 1 9>, <&cps_syscon0 1 5>;
};
+ cps_xmdio: mdio@12a600 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,orion-mdio";
+ reg = <0x12a600 0x10>;
+ status = "disabled";
+ };
+
cps_icu: interrupt-controller@1e0000 {
compatible = "marvell,cp110-icu";
reg = <0x1e0000 0x10>;
--
2.9.4
^ permalink raw reply related
* [PATCH v2 5/8] net: mvmdio: introduce an ops structure
From: Antoine Tenart @ 2017-06-08 9:26 UTC (permalink / raw)
To: davem, jason, andrew, gregory.clement, sebastian.hesselbarth,
f.fainelli
Cc: Antoine Tenart, thomas.petazzoni, mw, linux, netdev,
linux-arm-kernel
In-Reply-To: <20170608092653.25221-1-antoine.tenart@free-electrons.com>
Introduce an ops structure to add an indirection on functions accessing
the registers. This is needed to add the xMDIO support later.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
drivers/net/ethernet/marvell/mvmdio.c | 71 ++++++++++++++++++++++++++---------
1 file changed, 53 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index 6cbdb221c1ab..f66b474b382a 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -64,6 +64,14 @@ struct orion_mdio_dev {
wait_queue_head_t smi_busy_wait;
};
+struct orion_mdio_ops {
+ int (*is_done)(struct orion_mdio_dev *);
+ int (*is_read_valid)(struct orion_mdio_dev *);
+ void (*start_read)(struct orion_mdio_dev *, int, int);
+ u16 (*read)(struct orion_mdio_dev *);
+ void (*write)(struct orion_mdio_dev *, int, int, u16);
+};
+
static int orion_mdio_smi_is_done(struct orion_mdio_dev *dev)
{
return !(readl(dev->regs) & MVMDIO_SMI_BUSY);
@@ -74,9 +82,42 @@ static int orion_mdio_smi_is_read_valid(struct orion_mdio_dev *dev)
return readl(dev->regs) & MVMDIO_SMI_READ_VALID;
}
+static void orion_mdio_smi_start_read_op(struct orion_mdio_dev *dev, int mii_id,
+ int regnum)
+{
+ writel(((mii_id << MVMDIO_SMI_PHY_ADDR_SHIFT) |
+ (regnum << MVMDIO_SMI_PHY_REG_SHIFT) |
+ MVMDIO_SMI_READ_OPERATION),
+ dev->regs);
+}
+
+static u16 orion_mdio_smi_read_op(struct orion_mdio_dev *dev)
+{
+ return readl(dev->regs) & GENMASK(15,0);
+}
+
+static void orion_mdio_smi_write_op(struct orion_mdio_dev *dev, int mii_id,
+ int regnum, u16 value)
+{
+ writel(((mii_id << MVMDIO_SMI_PHY_ADDR_SHIFT) |
+ (regnum << MVMDIO_SMI_PHY_REG_SHIFT) |
+ MVMDIO_SMI_WRITE_OPERATION |
+ (value << MVMDIO_SMI_DATA_SHIFT)),
+ dev->regs);
+}
+
+static const struct orion_mdio_ops orion_mdio_smi_ops = {
+ .is_done = orion_mdio_smi_is_done,
+ .is_read_valid = orion_mdio_smi_is_read_valid,
+ .start_read = orion_mdio_smi_start_read_op,
+ .read = orion_mdio_smi_read_op,
+ .write = orion_mdio_smi_write_op,
+};
+
/* Wait for the SMI unit to be ready for another operation
*/
-static int orion_mdio_wait_ready(struct mii_bus *bus)
+static int orion_mdio_wait_ready(const struct orion_mdio_ops *ops,
+ struct mii_bus *bus)
{
struct orion_mdio_dev *dev = bus->priv;
unsigned long timeout = usecs_to_jiffies(MVMDIO_SMI_TIMEOUT);
@@ -84,7 +125,7 @@ static int orion_mdio_wait_ready(struct mii_bus *bus)
int timedout = 0;
while (1) {
- if (orion_mdio_smi_is_done(dev))
+ if (ops->is_done(dev))
return 0;
else if (timedout)
break;
@@ -103,8 +144,7 @@ static int orion_mdio_wait_ready(struct mii_bus *bus)
if (timeout < 2)
timeout = 2;
wait_event_timeout(dev->smi_busy_wait,
- orion_mdio_smi_is_done(dev),
- timeout);
+ ops->is_done(dev), timeout);
++timedout;
}
@@ -118,30 +158,28 @@ static int orion_mdio_read(struct mii_bus *bus, int mii_id,
int regnum)
{
struct orion_mdio_dev *dev = bus->priv;
+ const struct orion_mdio_ops *ops = &orion_mdio_smi_ops;
int ret;
mutex_lock(&dev->lock);
- ret = orion_mdio_wait_ready(bus);
+ ret = orion_mdio_wait_ready(ops, bus);
if (ret < 0)
goto out;
- writel(((mii_id << MVMDIO_SMI_PHY_ADDR_SHIFT) |
- (regnum << MVMDIO_SMI_PHY_REG_SHIFT) |
- MVMDIO_SMI_READ_OPERATION),
- dev->regs);
+ ops->start_read(dev, mii_id, regnum);
- ret = orion_mdio_wait_ready(bus);
+ ret = orion_mdio_wait_ready(ops, bus);
if (ret < 0)
goto out;
- if (!orion_mdio_smi_is_read_valid(dev)) {
+ if (!ops->is_read_valid(dev)) {
dev_err(bus->parent, "SMI bus read not valid\n");
ret = -ENODEV;
goto out;
}
- ret = readl(dev->regs) & GENMASK(15,0);
+ ret = ops->read(dev);
out:
mutex_unlock(&dev->lock);
return ret;
@@ -151,19 +189,16 @@ static int orion_mdio_write(struct mii_bus *bus, int mii_id,
int regnum, u16 value)
{
struct orion_mdio_dev *dev = bus->priv;
+ const struct orion_mdio_ops *ops = &orion_mdio_smi_ops;
int ret;
mutex_lock(&dev->lock);
- ret = orion_mdio_wait_ready(bus);
+ ret = orion_mdio_wait_ready(ops, bus);
if (ret < 0)
goto out;
- writel(((mii_id << MVMDIO_SMI_PHY_ADDR_SHIFT) |
- (regnum << MVMDIO_SMI_PHY_REG_SHIFT) |
- MVMDIO_SMI_WRITE_OPERATION |
- (value << MVMDIO_SMI_DATA_SHIFT)),
- dev->regs);
+ ops->write(dev, mii_id, regnum, value);
out:
mutex_unlock(&dev->lock);
--
2.9.4
^ permalink raw reply related
* [PATCH v2 6/8] net: mvmdio: put the poll intervals in the ops structure
From: Antoine Tenart @ 2017-06-08 9:26 UTC (permalink / raw)
To: davem, jason, andrew, gregory.clement, sebastian.hesselbarth,
f.fainelli
Cc: Antoine Tenart, thomas.petazzoni, mw, linux, netdev,
linux-arm-kernel
In-Reply-To: <20170608092653.25221-1-antoine.tenart@free-electrons.com>
Put the two poll intervals (min and max) in the driver's ops
structure. This is needed to add the xmdio support later.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
drivers/net/ethernet/marvell/mvmdio.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index f66b474b382a..07b18f60da2a 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -70,6 +70,9 @@ struct orion_mdio_ops {
void (*start_read)(struct orion_mdio_dev *, int, int);
u16 (*read)(struct orion_mdio_dev *);
void (*write)(struct orion_mdio_dev *, int, int, u16);
+
+ unsigned int poll_interval_min;
+ unsigned int poll_interval_max;
};
static int orion_mdio_smi_is_done(struct orion_mdio_dev *dev)
@@ -112,6 +115,9 @@ static const struct orion_mdio_ops orion_mdio_smi_ops = {
.start_read = orion_mdio_smi_start_read_op,
.read = orion_mdio_smi_read_op,
.write = orion_mdio_smi_write_op,
+
+ .poll_interval_min = MVMDIO_SMI_POLL_INTERVAL_MIN,
+ .poll_interval_max = MVMDIO_SMI_POLL_INTERVAL_MAX,
};
/* Wait for the SMI unit to be ready for another operation
@@ -131,8 +137,8 @@ static int orion_mdio_wait_ready(const struct orion_mdio_ops *ops,
break;
if (dev->err_interrupt <= 0) {
- usleep_range(MVMDIO_SMI_POLL_INTERVAL_MIN,
- MVMDIO_SMI_POLL_INTERVAL_MAX);
+ usleep_range(ops->poll_interval_min,
+ ops->poll_interval_max);
if (time_is_before_jiffies(end))
++timedout;
--
2.9.4
^ permalink raw reply related
* [PATCH v2 0/8] net: mvmdio: add xSMI support
From: Antoine Tenart @ 2017-06-08 9:26 UTC (permalink / raw)
To: davem, jason, andrew, gregory.clement, sebastian.hesselbarth,
f.fainelli
Cc: Antoine Tenart, thomas.petazzoni, mw, linux, netdev,
linux-arm-kernel
Hello,
This series aims to add the xSMI support (also called xMDIO) to the
mvmdio driver. The xSMI interface complies with the IEEE 802.3 clause 45
and is used by 10GbE devices. On 7k and 8k (as of now), such an
interface is found and is used by Ethernet controllers.
Patches 1-3 are cosmetic cleanups.
Patches 4-6 are prerequisites to the xSMI support.
Patches 7-8 add the xSMI support to the mvmdio driver, and a node is
added both in the cp110 slave and master device trees.
This was tested on an Armada 8040 mcbin, as well as on both the
Armada 7040 DB and the Armada 8040 DB to ensure the SMI interface
was still working.
@Dave: patch 8 should go through the mvebu tree as asked by Gregory,
thanks!
Thanks,
Antoine
Since v1:
- Instead of using the smi/xsmi helpers based on the compatible, now
check if the MII_ADDR_C45 bit is set.
- Removed the marvell,xmdio compatible addition.
- Fixed the is_read_valid logic.
- Updated to use static const variables for ops.
- Added 3 Reviewed-by tags from Florian (I dropped another one as the
patch changed in v2).
Antoine Tenart (8):
net: mvmdio: reorder headers alphabetically
net: mvmdio: use tabs for defines
net: mvmdio: use GENMASK for masks
net: mvmdio: move the read valid check into its own function
net: mvmdio: introduce an ops structure
net: mvmdio: put the poll intervals in the ops structure
net: mvmdio: add xmdio support
arm64: marvell: dts: add xmdio nodes for 7k/8k
.../devicetree/bindings/net/marvell-orion-mdio.txt | 6 +-
.../boot/dts/marvell/armada-cp110-master.dtsi | 8 +
.../arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 8 +
drivers/net/ethernet/marvell/Kconfig | 6 +-
drivers/net/ethernet/marvell/mvmdio.c | 196 ++++++++++++++++-----
5 files changed, 178 insertions(+), 46 deletions(-)
--
2.9.4
^ permalink raw reply
* [PATCH v2 7/8] net: mvmdio: add xmdio support
From: Antoine Tenart @ 2017-06-08 9:26 UTC (permalink / raw)
To: davem, jason, andrew, gregory.clement, sebastian.hesselbarth,
f.fainelli
Cc: Antoine Tenart, thomas.petazzoni, mw, linux, netdev,
linux-arm-kernel
In-Reply-To: <20170608092653.25221-1-antoine.tenart@free-electrons.com>
This patch adds the xMDIO interface support in the mvmdio driver. This
interface is used in Ethernet controllers on Marvell 370, 7k and 8k (as
of now). The xSMI interface supported by this driver complies with the
IEEE 802.3 clause 45 (while the SMI interface complies with the clause
22). The xSMI interface is used by 10GbE devices.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
.../devicetree/bindings/net/marvell-orion-mdio.txt | 6 +-
drivers/net/ethernet/marvell/Kconfig | 6 +-
drivers/net/ethernet/marvell/mvmdio.c | 76 +++++++++++++++++++++-
3 files changed, 80 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
index ccdabdcc8618..36be4ca5dab2 100644
--- a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
+++ b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
@@ -1,9 +1,9 @@
* Marvell MDIO Ethernet Controller interface
The Ethernet controllers of the Marvel Kirkwood, Dove, Orion5x,
-MV78xx0, Armada 370 and Armada XP have an identical unit that provides
-an interface with the MDIO bus. This driver handles this MDIO
-interface.
+MV78xx0, Armada 370, Armada XP, Armada 7k and Armada 8k have an
+identical unit that provides an interface with the MDIO bus or to
+the xMDIO bus. This driver handles these interfaces.
Required properties:
- compatible: "marvell,orion-mdio"
diff --git a/drivers/net/ethernet/marvell/Kconfig b/drivers/net/ethernet/marvell/Kconfig
index da6fb825afea..205bb7e683b7 100644
--- a/drivers/net/ethernet/marvell/Kconfig
+++ b/drivers/net/ethernet/marvell/Kconfig
@@ -35,9 +35,9 @@ config MVMDIO
depends on HAS_IOMEM
select PHYLIB
---help---
- This driver supports the MDIO interface found in the network
- interface units of the Marvell EBU SoCs (Kirkwood, Orion5x,
- Dove, Armada 370 and Armada XP).
+ This driver supports the MDIO and xMDIO interfaces found in
+ the network interface units of the Marvell EBU SoCs (Kirkwood,
+ Orion5x, Dove, Armada 370, Armada XP, Armada 7k and Armada 8k).
This driver is used by the MV643XX_ETH and MVNETA drivers.
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index 07b18f60da2a..7b650ef67347 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -41,6 +41,15 @@
#define MVMDIO_ERR_INT_SMI_DONE 0x00000010
#define MVMDIO_ERR_INT_MASK 0x0080
+#define MVMDIO_XSMI_MGNT_REG 0x0
+#define MVMDIO_XSMI_READ_VALID BIT(29)
+#define MVMDIO_XSMI_BUSY BIT(30)
+#define MVMDIO_XSMI_ADDR_REG 0x8
+#define MVMDIO_XSMI_PHYADDR_SHIFT 16
+#define MVMDIO_XSMI_DEVADDR_SHIFT 21
+#define MVMDIO_XSMI_READ_OPERATION (0x7 << 26)
+#define MVMDIO_XSMI_WRITE_OPERATION (0x5 << 27)
+
/*
* SMI Timeout measurements:
* - Kirkwood 88F6281 (Globalscale Dreamplug): 45us to 95us (Interrupt)
@@ -50,6 +59,9 @@
#define MVMDIO_SMI_POLL_INTERVAL_MIN 45
#define MVMDIO_SMI_POLL_INTERVAL_MAX 55
+#define MVMDIO_XSMI_POLL_INTERVAL_MIN 150
+#define MVMDIO_XSMI_POLL_INTERVAL_MAX 160
+
struct orion_mdio_dev {
struct mutex lock;
void __iomem *regs;
@@ -75,6 +87,7 @@ struct orion_mdio_ops {
unsigned int poll_interval_max;
};
+/* smi */
static int orion_mdio_smi_is_done(struct orion_mdio_dev *dev)
{
return !(readl(dev->regs) & MVMDIO_SMI_BUSY);
@@ -120,6 +133,65 @@ static const struct orion_mdio_ops orion_mdio_smi_ops = {
.poll_interval_max = MVMDIO_SMI_POLL_INTERVAL_MAX,
};
+/* xsmi */
+static int orion_mdio_xsmi_is_done(struct orion_mdio_dev *dev)
+{
+ return !(readl(dev->regs + MVMDIO_XSMI_MGNT_REG) & MVMDIO_XSMI_BUSY);
+}
+
+static int orion_mdio_xsmi_is_read_valid(struct orion_mdio_dev *dev)
+{
+ return readl(dev->regs + MVMDIO_XSMI_MGNT_REG) & MVMDIO_XSMI_READ_VALID;
+}
+
+static void orion_mdio_xsmi_start_read_op(struct orion_mdio_dev *dev,
+ int mii_id, int regnum)
+{
+ u16 dev_addr = regnum >> 16;
+
+ writel(regnum & GENMASK(15,0), dev->regs + MVMDIO_XSMI_ADDR_REG);
+ writel((mii_id << MVMDIO_XSMI_PHYADDR_SHIFT) |
+ (dev_addr << MVMDIO_XSMI_DEVADDR_SHIFT) |
+ MVMDIO_XSMI_READ_OPERATION,
+ dev->regs + MVMDIO_XSMI_MGNT_REG);
+}
+
+static u16 orion_mdio_xsmi_read_op(struct orion_mdio_dev *dev)
+{
+ return readl(dev->regs + MVMDIO_XSMI_MGNT_REG) & GENMASK(15,0);
+}
+
+static void orion_mdio_xsmi_write_op(struct orion_mdio_dev *dev, int mii_id,
+ int regnum, u16 value)
+{
+ u16 dev_addr = regnum >> 16;
+
+ writel(regnum & GENMASK(15,0), dev->regs + MVMDIO_XSMI_ADDR_REG);
+ writel((mii_id << MVMDIO_XSMI_PHYADDR_SHIFT) |
+ (dev_addr << MVMDIO_XSMI_DEVADDR_SHIFT) |
+ MVMDIO_XSMI_WRITE_OPERATION | value,
+ dev->regs + MVMDIO_XSMI_MGNT_REG);
+}
+
+static const struct orion_mdio_ops orion_mdio_xsmi_ops = {
+ .is_done = orion_mdio_xsmi_is_done,
+ .is_read_valid = orion_mdio_xsmi_is_read_valid,
+ .start_read = orion_mdio_xsmi_start_read_op,
+ .read = orion_mdio_xsmi_read_op,
+ .write = orion_mdio_xsmi_write_op,
+
+ .poll_interval_min = MVMDIO_XSMI_POLL_INTERVAL_MIN,
+ .poll_interval_max = MVMDIO_XSMI_POLL_INTERVAL_MAX,
+};
+
+static const struct orion_mdio_ops *orion_mdio_get_ops(int regnum)
+{
+ if (regnum & MII_ADDR_C45)
+ return &orion_mdio_xsmi_ops;
+
+ return &orion_mdio_smi_ops;
+}
+
/* Wait for the SMI unit to be ready for another operation
*/
static int orion_mdio_wait_ready(const struct orion_mdio_ops *ops,
@@ -164,7 +236,7 @@ static int orion_mdio_read(struct mii_bus *bus, int mii_id,
int regnum)
{
struct orion_mdio_dev *dev = bus->priv;
- const struct orion_mdio_ops *ops = &orion_mdio_smi_ops;
+ const struct orion_mdio_ops *ops = orion_mdio_get_ops(regnum);
int ret;
mutex_lock(&dev->lock);
@@ -195,7 +267,7 @@ static int orion_mdio_write(struct mii_bus *bus, int mii_id,
int regnum, u16 value)
{
struct orion_mdio_dev *dev = bus->priv;
- const struct orion_mdio_ops *ops = &orion_mdio_smi_ops;
+ const struct orion_mdio_ops *ops = orion_mdio_get_ops(regnum);
int ret;
mutex_lock(&dev->lock);
--
2.9.4
^ permalink raw reply related
* [PATCH] mwifiex: Replace semaphore async_sem with mutex
From: Binoy Jayan @ 2017-06-08 10:03 UTC (permalink / raw)
To: Binoy Jayan
Cc: linux-kernel, Arnd Bergmann, Rajendra, Mark Brown,
Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
Kalle Valo, linux-wireless, netdev
The semaphore 'async_sem' is used as a simple mutex, so
it should be written as one. Semaphores are going away in the future.
Signed-off-by: Binoy Jayan <binoy.jayan@linaro.org>
---
This patch is part of a bigger effort to eliminate unwanted
semaphores from the linux kernel.
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 2 +-
drivers/net/wireless/marvell/mwifiex/main.h | 2 +-
drivers/net/wireless/marvell/mwifiex/scan.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 7ec06bf..9e0d638 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -3059,7 +3059,7 @@ struct wireless_dev *mwifiex_add_virtual_intf(struct wiphy *wiphy,
INIT_DELAYED_WORK(&priv->dfs_chan_sw_work,
mwifiex_dfs_chan_sw_work_queue);
- sema_init(&priv->async_sem, 1);
+ mutex_init(&priv->async_mutex);
mwifiex_dbg(adapter, INFO,
"info: %s: Marvell 802.11 Adapter\n", dev->name);
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
index bb2a467..9c2cb33 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -628,7 +628,7 @@ struct mwifiex_private {
struct dentry *dfs_dev_dir;
#endif
u16 current_key_index;
- struct semaphore async_sem;
+ struct mutex async_mutex;
struct cfg80211_scan_request *scan_request;
u8 cfg_bssid[6];
struct wps wps;
diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c b/drivers/net/wireless/marvell/mwifiex/scan.c
index ce6936d..ae9630b 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -2809,7 +2809,7 @@ int mwifiex_request_scan(struct mwifiex_private *priv,
{
int ret;
- if (down_interruptible(&priv->async_sem)) {
+ if (mutex_lock_interruptible(&priv->async_mutex)) {
mwifiex_dbg(priv->adapter, ERROR,
"%s: acquire semaphore fail\n",
__func__);
@@ -2825,7 +2825,7 @@ int mwifiex_request_scan(struct mwifiex_private *priv,
/* Normal scan */
ret = mwifiex_scan_networks(priv, NULL);
- up(&priv->async_sem);
+ mutex_unlock(&priv->async_mutex);
return ret;
}
--
Binoy Jayan
^ permalink raw reply related
* Re: [PATCH RFC net-next 3/4] net/mlx5: Separate between eswitch and MPFS l2 table logic
From: Saeed Mahameed @ 2017-06-08 10:26 UTC (permalink / raw)
To: Or Gerlitz
Cc: Saeed Mahameed, Linux Netdev List, Jes Sorensen, Kernel Team,
Or Gerlitz
In-Reply-To: <CAJ3xEMi9+iaa3CCA-gdBC7Okz3KgpWbea-vvfYEJFpTQkboxUA@mail.gmail.com>
On Thu, Jun 8, 2017 at 12:13 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
> On Thu, Jun 8, 2017 at 2:42 AM, Saeed Mahameed <saeedm@mellanox.com> wrote:
> [...]
>> 9 files changed, 376 insertions(+), 223 deletions(-)
>
> a bit of heavy duty for this sort of sensitive change, should
> investigate if it can be broken a bit
>
yes, hence the RFC.
>> +int mlx5_mpfs_init(struct mlx5_core_dev *dev)
>> +{
>> + int l2table_size = 1 << MLX5_CAP_GEN(dev, log_max_l2_table);
>> + struct mlx5_mpfs *mpfs;
>> +
>> + if (!MLX5_VPORT_MANAGER(dev))
>> + return 0;
>
> In commit 955bc48081805c053 we added
>
> + static bool mlx5e_is_eswitch_vport_mngr(struct mlx5_core_dev *mdev)
> +{
> + return (MLX5_CAP_GEN(mdev, vport_group_manager) &&
> + MLX5_CAP_GEN(mdev, port_type) == MLX5_CAP_PORT_TYPE_ETH);
> +}
> +
>
> and now you add
>
> +#define MLX5_VPORT_MANAGER(mdev) \
> + (MLX5_CAP_GEN(mdev, vport_group_manager) && mlx5_core_is_pf(mdev))
> +
>
> would be good to align things across the place with a pre-patch and
> then use the whatever check
> we need to apply
>
Sure.
> BTW mlx5e_is_eswitch_vport_mngr() should return false in the down
> stream patch when eswitch is compiled out, right?
>
No, vport manager is a vport manager whether it wants to initialize
the eswitch or not.
it is up to the stub function to decide what to do when eswitch is compiled out.
>> +void mlx5_mpfs_cleanup(struct mlx5_core_dev *dev)
>> +{
>> + struct mlx5_mpfs *mpfs = dev->priv.mpfs;
>> +
>> + if (!MLX5_VPORT_MANAGER(dev))
>> + return;
>> +
>> + WARN_ON(!hlist_empty(mpfs->hash));
>
> I don't see any line with WARN_ON that was deleted by this patch, why add that?
>
Just to make sure we freed anything on cleanup, for now i will keep
this, i will consider removing this on
final submission.
>> + kfree(mpfs->bitmap);
>> + kfree(mpfs);
>> +}
>> +
>> +int mlx5_mpfs_add_mac(struct mlx5_core_dev *dev, u8 *mac)
>> +{
>
>> + if (!MLX5_VPORT_MANAGER(dev))
>> + return 0;
>> +
>> + if (is_multicast_ether_addr(mac))
>> + return 0;
>
> It would have been much better reviewed and maintained if we can code
> things in a manner under which we don't get here if not appropriate and
> not simulate successful return.
>
Sure, will consider that, i just wanted to avoid ugly indentations in
mlx5e set_rx_mode en_fs.c
>> +int mlx5_mpfs_del_mac(struct mlx5_core_dev *dev, u8 *mac)
>> +{
>
>> + if (!MLX5_VPORT_MANAGER(dev))
>> + return 0;
>> +
>> + if (is_multicast_ether_addr(mac))
>> + return 0;
>
> same comment as for the add_mac call
^ permalink raw reply
* Re: next-20170608 build: 1 failures 4 warnings (next-20170608)
From: Stephen Rothwell @ 2017-06-08 10:27 UTC (permalink / raw)
To: David Miller, Networking
Cc: Build bot for Mark Brown, linaro-kernel, linux-next
In-Reply-To: <E1dIuCM-0000cQ-QM@optimist>
Hi Dave,
On Thu, 08 Jun 2017 10:57:50 +0100 Build bot for Mark Brown <broonie@kernel.org> wrote:
>
> Tree/Branch: next-20170608
> Git describe: next-20170608
> Commit: e4689b9aad Add linux-next specific files for 20170608
>
> Build Time: 0 min 12 sec
>
> Passed: 6 / 7 ( 85.71 %)
> Failed: 1 / 7 ( 14.29 %)
>
> Errors: 1
> Warnings: 4
> Section Mismatches: 0
>
> Failed defconfigs:
> arm-allmodconfig
>
> Errors:
>
> arm-allmodconfig
> ../drivers/hsi/clients/ssi_protocol.c:1069:5: error: 'struct net_device' has no member named 'destructor'
Looks like Mark has found another one.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: next-20170608 build: 1 failures 4 warnings (next-20170608)
From: Mark Brown @ 2017-06-08 10:32 UTC (permalink / raw)
To: David S. Miller, Sebastian Reichel
Cc: kernel-build-reports, linaro-kernel, linux-next, netdev
In-Reply-To: <E1dIuCM-0000cQ-QM@optimist>
[-- Attachment #1: Type: text/plain, Size: 512 bytes --]
On Thu, Jun 08, 2017 at 10:57:50AM +0100, Build bot for Mark Brown wrote:
Today's -next fails to build an ARM allmodconfig due to:
> arm-allmodconfig
> ../drivers/hsi/clients/ssi_protocol.c:1069:5: error: 'struct net_device' has no member named 'destructor'
due to cf124db566e6 (net: Fix inconsistent teardown and release of
private netdev state.) which missed this instance, presumably due to a
combination of it not being in one of the normal networking driver
directories and only being buildable on ARM.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH RFC net-next 4/4] net/mlx5: Add CONFIG_MLX5_ESWITCH Kconfig
From: Saeed Mahameed @ 2017-06-08 10:32 UTC (permalink / raw)
To: Or Gerlitz
Cc: Saeed Mahameed, Linux Netdev List, Jes Sorensen, Kernel Team,
Or Gerlitz
In-Reply-To: <CAJ3xEMhPkf9DSs=zguYNzp13iMVDHJoLbFhi8MihuD6C5LHXeg@mail.gmail.com>
On Thu, Jun 8, 2017 at 12:35 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
> On Thu, Jun 8, 2017 at 2:42 AM, Saeed Mahameed <saeedm@mellanox.com> wrote:
>
>> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>> @@ -2961,9 +2961,8 @@ static int mlx5e_modify_channels_vsd(struct mlx5e_channels *chs, bool vsd)
>> return 0;
>> }
>>
>> -static int mlx5e_setup_tc(struct net_device *netdev, u8 tc)
>> +static int mlx5e_setup_tc(struct mlx5e_priv *priv, u8 tc)
>> {
>> - struct mlx5e_priv *priv = netdev_priv(netdev);
>> struct mlx5e_channels new_channels = {};
>> int err = 0;
>>
>> @@ -2995,6 +2994,7 @@ static int mlx5e_ndo_setup_tc(struct net_device *dev, u32 handle,
>> {
>> struct mlx5e_priv *priv = netdev_priv(dev);
>>
>> +#ifdef CONFIG_MLX5_ESWITCH
>> if (TC_H_MAJ(handle) != TC_H_MAJ(TC_H_INGRESS))
>> goto mqprio;
>>
>> @@ -3013,12 +3013,13 @@ static int mlx5e_ndo_setup_tc(struct net_device *dev, u32 handle,
>> }
>>
>> mqprio:
>> +#endif
>> if (tc->type != TC_SETUP_MQPRIO)
>> - return -EINVAL;
>> + return -EOPNOTSUPP;
>
> why change this corner in this patch? we're doing enough changes
>
>>
>> tc->mqprio->hw = TC_MQPRIO_HW_OFFLOAD_TCS;
>>
>> - return mlx5e_setup_tc(dev, tc->mqprio->num_tc);
>> + return mlx5e_setup_tc(priv, tc->mqprio->num_tc);
>> }
>
> same comment
>
Ok will change both.
>> --- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
>
>> @@ -948,13 +946,11 @@ static int mlx5_init_once(struct mlx5_core_dev *dev, struct mlx5_priv *priv)
>> goto err_rl_cleanup;
>> }
>>
>> -#ifdef CONFIG_MLX5_CORE_EN
>> err = mlx5_eswitch_init(dev);
>> if (err) {
>> dev_err(&pdev->dev, "Failed to init eswitch %d\n", err);
>> goto err_mpfs_cleanup;
>> }
>> -#endif
>
> why? before this patch we were doing it only if Ethernet
> (MLX5_CORE_EN) was defined into the build,
> and now we are returning blindly zero if another config isn't there
> (CONFIG_MLX5_ESWITCH) - is that
> fully equivalent? do we want to be fully equiv?
>
Fully equivalent and more correct behavior and design.
eswitch is now separate from MPFS and EN and fully independent and has
its own CONFIG_MLX5_ESWITCH,
you can choose to have it or not (CONFIG_MLX5_ESWITCH) it won't
affects other components.
>> @@ -965,10 +961,8 @@ static int mlx5_init_once(struct mlx5_core_dev *dev, struct mlx5_priv *priv)
>> return 0;
>>
>> err_eswitch_cleanup:
>> -#ifdef CONFIG_MLX5_CORE_EN
>> mlx5_eswitch_cleanup(dev->priv.eswitch);
>> err_mpfs_cleanup:
>> -#endif
>
> same comment/question
Same answer.
^ permalink raw reply
* Re: [PATCH v2 3/8] net: mvmdio: use GENMASK for masks
From: Sergei Shtylyov @ 2017-06-08 10:35 UTC (permalink / raw)
To: Antoine Tenart, davem, jason, andrew, gregory.clement,
sebastian.hesselbarth, f.fainelli
Cc: thomas.petazzoni, mw, linux, netdev, linux-arm-kernel
In-Reply-To: <20170608092653.25221-4-antoine.tenart@free-electrons.com>
Hello!
On 6/8/2017 12:26 PM, Antoine Tenart wrote:
> Cosmetic patch to use the GENMASK helper for masks.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/net/ethernet/marvell/mvmdio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
> index 17b518b13ae3..96af8d57d9e5 100644
> --- a/drivers/net/ethernet/marvell/mvmdio.c
> +++ b/drivers/net/ethernet/marvell/mvmdio.c
> @@ -138,7 +138,7 @@ static int orion_mdio_read(struct mii_bus *bus, int mii_id,
> goto out;
> }
>
> - ret = val & 0xFFFF;
> + ret = val & GENMASK(15,0);
Need a space after comma.
MBR, Sergei
^ permalink raw reply
* Re: [PATCH RFC net-next 3/4] net/mlx5: Separate between eswitch and MPFS l2 table logic
From: Or Gerlitz @ 2017-06-08 11:12 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Saeed Mahameed, Linux Netdev List, Jes Sorensen, Kernel Team,
Or Gerlitz
In-Reply-To: <CALzJLG-wha9D0Ybnu3mAPB8RaDYnfidj2dz81rmdiJzRjw7yCw@mail.gmail.com>
On Thu, Jun 8, 2017 at 1:26 PM, Saeed Mahameed
<saeedm@dev.mellanox.co.il> wrote:
> On Thu, Jun 8, 2017 at 12:13 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>>> +int mlx5_mpfs_add_mac(struct mlx5_core_dev *dev, u8 *mac)
>>> +{
>>
>>> + if (!MLX5_VPORT_MANAGER(dev))
>>> + return 0;
>>> +
>>> + if (is_multicast_ether_addr(mac))
>>> + return 0;
>> It would have been much better reviewed and maintained if we can code
>> things in a manner under which we don't get here if not appropriate and
>> not simulate successful return.
> Sure, will consider that, i just wanted to avoid ugly indentations in
> mlx5e set_rx_mode en_fs.c
I understand your concern re ugly indentations, but hopefully we can avoid them
^ permalink raw reply
* (unknown),
From: helga.brickl @ 2017-06-08 11:31 UTC (permalink / raw)
To: netdev
[-- Attachment #1: 529462.zip --]
[-- Type: application/zip, Size: 4813 bytes --]
^ permalink raw reply
* Re: next-20170608 build: 1 failures 4 warnings (next-20170608)
From: Sebastian Reichel @ 2017-06-08 11:33 UTC (permalink / raw)
To: Mark Brown
Cc: David S. Miller, kernel-build-reports, linaro-kernel, linux-next,
netdev
In-Reply-To: <20170608103231.gmqx6qluzcjwzrst@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 744 bytes --]
Hi,
On Thu, Jun 08, 2017 at 11:32:31AM +0100, Mark Brown wrote:
> On Thu, Jun 08, 2017 at 10:57:50AM +0100, Build bot for Mark Brown wrote:
>
> Today's -next fails to build an ARM allmodconfig due to:
>
> > arm-allmodconfig
> > ../drivers/hsi/clients/ssi_protocol.c:1069:5: error: 'struct net_device' has no member named 'destructor'
>
> due to cf124db566e6 (net: Fix inconsistent teardown and release of
> private netdev state.) which missed this instance, presumably due to a
> combination of it not being in one of the normal networking driver
> directories and only being buildable on ARM.
I assume, that this will be fixed via the net tree.
If you Cc me on updated/new patch I will provide Acked-by.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the wireless-drivers-next tree
From: Kalle Valo @ 2017-06-08 12:07 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Igor Mitsyanko, Wireless, David Miller, Networking,
Linux-Next Mailing List, Linux Kernel Mailing List, Dmitrii Lebed,
Sergei Maksimenko, Sergey Matyukevich, Bindu Therthala,
Huizhao Wang, Kamlesh Rath, Avinash Patil
In-Reply-To: <20170608125737.1e09c36d@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi Igor,
>
> On Wed, 7 Jun 2017 19:43:18 -0700 Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> wrote:
>>
>> thanks. As I understand, you've applied this patch during a merge and no
>> further actions are required, correct?
>
> Dave Miller will need to apply that patch (or something similar) when
> he merges the wireless-drivers-next tree into the net-next tree. I
> will keep applying the patch each day until then.
Thanks, I'll remind Dave about this when i submit the pull request (very
soon now).
--
Kalle Valo
^ permalink raw reply
* merge net into net-next?
From: Johannes Berg @ 2017-06-08 12:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Hi Dave,
Could you do me a favour and merge net into net-next? I want to merge
that back in order to apply a patch to mac80211-next that otherwise
conflicts fairly badly with a change in mac80211.
Thanks!
johannes
^ permalink raw reply
* Re: merge net into net-next?
From: Johannes Berg @ 2017-06-08 12:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1496923855.26119.0.camel@sipsolutions.net>
On Thu, 2017-06-08 at 14:10 +0200, Johannes Berg wrote:
> Hi Dave,
>
> Could you do me a favour and merge net into net-next? I want to merge
> that back in order to apply a patch to mac80211-next that otherwise
> conflicts fairly badly with a change in mac80211.
Wait, forget it. You already did, I just managed to somehow miss that -
sorry for the noise!
johannes
^ permalink raw reply
* Re: linux-next: build failure after merge of the wireless-drivers-next tree
From: Stephen Rothwell @ 2017-06-08 12:47 UTC (permalink / raw)
To: Kalle Valo
Cc: Igor Mitsyanko, Wireless, David Miller, Networking,
Linux-Next Mailing List, Linux Kernel Mailing List, Dmitrii Lebed,
Sergei Maksimenko, Sergey Matyukevich, Bindu Therthala,
Huizhao Wang, Kamlesh Rath, Avinash Patil
In-Reply-To: <87lgp24ra3.fsf@codeaurora.org>
Hi Kalle,
On Thu, 08 Jun 2017 15:07:00 +0300 Kalle Valo <kvalo@codeaurora.org> wrote:
>
> Stephen Rothwell <sfr@canb.auug.org.au> writes:
>
> > On Wed, 7 Jun 2017 19:43:18 -0700 Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> wrote:
> >>
> >> thanks. As I understand, you've applied this patch during a merge and no
> >> further actions are required, correct?
> >
> > Dave Miller will need to apply that patch (or something similar) when
> > he merges the wireless-drivers-next tree into the net-next tree. I
> > will keep applying the patch each day until then.
>
> Thanks, I'll remind Dave about this when i submit the pull request (very
> soon now).
It occurred to me just after I wrote the previous message that it would
only be true after he merges the current net tree into the net-next tree.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* RE: [PATCH v2 4/4] net: macb: Add hardware PTP support
From: Rafal Ozieblo @ 2017-06-08 12:48 UTC (permalink / raw)
To: Richard Cochran
Cc: David Miller, nicolas.ferre@atmel.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, harini.katakam@xilinx.com,
andrei.pistirica@microchip.com
In-Reply-To: <20170607132817.GA28329@localhost.localdomain>
> From: Richard Cochran [mailto:richardcochran@gmail.com]
> Sent: 7 czerwca 2017 15:28
> To: Rafal Ozieblo <rafalo@cadence.com>
> Cc: David Miller <davem@davemloft.net>; nicolas.ferre@atmel.com;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> harini.katakam@xilinx.com; andrei.pistirica@microchip.com
> Subject: Re: [PATCH v2 4/4] net: macb: Add hardware PTP support
>
> ********** EXTERNAL MAIL. PLEASE USE CAUTION WHEN CLICKING LINKS
> OR OPENING ATTACHMENTS **********
>
> On Wed, Jun 07, 2017 at 11:13:36AM +0000, Rafal Ozieblo wrote:
> > Please look at following call-stack:
> >
> > 1. macb_interrupt() // spin_lock(&bp->lock) is taken
> > 2. macb_tx_interrupt()
> > 3. macb_handle_txtstamp()
> > 4. skb_tstamp_tx()
> > 5. __skb_tstamp_tx()
> > 6. skb_may_tx_timestamp()
> > 7. read_lock_bh() // second lock is taken
>
> Well, you can always drop the lock, or postpone the call to
> skb_tstamp_tx() until after the spin lock is released...
Postponing is done using worker. Another pros is that skb_tstamp_tx() is called
outside interrupt routine.
>
> > I know that those are different locks and different types. But this could
> lead
> > to deadlocks. This is the reason of warning I could see.
>
> Can you please post the lockdep splat?
>
[ 1264.352242] =================================
[ 1264.356719] [ INFO: inconsistent lock state ]
[ 1264.361242] 4.4.0-42139-g418b7a0-dirty #16 Not tainted
[ 1264.366502] ---------------------------------
[ 1264.371004] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[ 1264.377204] ptp4l/105 [HC1[1]:SC0[4]:HE0:SE0] takes:
[ 1264.382286] (&(&list->lock)->rlock){?.-...}, at: [<d03250f8>] skb_queue_tail+0x18/0x34
[ 1264.390622] {HARDIRQ-ON-W} state was registered at:
[ 1264.395618] [<d0039d50>] lock_acquire+0x124/0x158
[ 1264.400730] [<d03e81f8>] _raw_spin_lock_bh+0x50/0x5c
[ 1264.406095] [<d0381745>] first_packet_length+0x35/0x1b4
[ 1264.411710] [<d0381f80>] udp_poll+0x30/0x3c
[ 1264.416267] [<d031743d>] sock_poll+0x141/0x148
[ 1264.421092] [<d00ea20d>] do_sys_poll+0x171/0x300
[ 1264.426111] [<d00ea41d>] SyS_poll+0x45/0x80
[ 1264.430676] [<d000481c>] system_call+0x40/0x50
[ 1264.435492] [<d00043d1>] common_exception_return+0x0/0x83
[ 1264.441274] irq event stamp: 23325
[ 1264.444802] hardirqs last enabled at (23324): [<d03e84da>] _raw_spin_unlock_irqrestore+0x4e/0x78
[ 1264.453929] hardirqs last disabled at (23325): [<d00065af>] do_interrupt+0x13/0x90
[ 1264.461732] softirqs last enabled at (23292): [<d0362cf8>] ip_finish_output2+0x80/0x43c
[ 1264.470073] softirqs last disabled at (23294): [<d0362da6>] ip_finish_output2+0x12e/0x43c
[ 1264.478480]
[ 1264.478480] other info that might help us debug this:
[ 1264.485211] Possible unsafe locking scenario:
[ 1264.485211]
[ 1264.491323] CPU0
[ 1264.493883] ----
[ 1264.496439] lock(&(&list->lock)->rlock);
[ 1264.500665] <Interrupt>
[ 1264.503392] lock(&(&list->lock)->rlock);
[ 1264.507793]
[ 1264.507793] *** DEADLOCK ***
[ 1264.507793]
[ 1264.514016] 4 locks held by ptp4l/105:
[ 1264.517886] #0: (rcu_read_lock_bh){......}, at: [<d0362da6>] ip_finish_output2+0x12e/0x43c
[ 1264.526675] #1: (rcu_read_lock_bh){......}, at: [<d03330f4>] __dev_queue_xmit+0x38/0x5f8
[ 1264.535287] #2: (_xmit_ETHER#2){+.-...}, at: [<d0348381>] sch_direct_xmit+0x51/0x138
[ 1264.543593] #3: (&(&bp->lock)->rlock){-.-...}, at: [<d02caeb2>] macb_interrupt+0x36/0x564
[ 1264.552316]
[ 1264.552316] stack backtrace:
[ 1264.556962] CPU: 0 PID: 105 Comm: ptp4l Not tainted 4.4.0-42139-g418b7a0-dirty #16
[ 1264.564654]
[ 1264.564654] Stack: d1786130 d75815e3 00001ffc d75815e0 9003811c d7581620 d7558c00 d1c0bd60
[ 1264.564654] 00000004 00000001 00000001 d7581600 900389fc d7581650 d7558c00 d7559160
[ 1264.564654] 00000004 00000000 00000000 d7559160 d04ecc34 d1bf2de0 00000179 d7581620
[ 1264.588339] Call Trace:
[ 1264.590894] [<d009a8af>] print_usage_bug.part.33+0x1c7/0x1cc
[ 1264.596883] [<d003811c>] mark_lock+0x2f4/0x44c
[ 1264.601639] [<d00389fc>] __lock_acquire+0x460/0x1228
[ 1264.606907] [<d0039d50>] lock_acquire+0x124/0x158
[ 1264.611907] [<d03e8335>] _raw_spin_lock_irqsave+0x45/0x54
[ 1264.617612] [<d03250f8>] skb_queue_tail+0x18/0x34
[ 1264.622594] [<d03251f0>] sock_queue_err_skb+0xdc/0x108
[ 1264.628017] [<d0326705>] __skb_complete_tx_timestamp+0x55/0x60
[ 1264.634146] [<d0326810>] __skb_tstamp_tx+0x94/0x98
[ 1264.639215] [<d032682c>] skb_tstamp_tx+0x18/0x1c
[ 1264.644110] [<d02cb065>] macb_interrupt+0x1e9/0x564
[ 1264.649302] [<d0041af5>] handle_irq_event_percpu+0xe9/0x2a4
[ 1264.655179] [<d0041ce6>] handle_irq_event+0x36/0x50
[ 1264.660343] [<d0043965>] handle_level_irq+0x99/0xb8
[ 1264.665525] [<d00415c5>] generic_handle_irq+0x19/0x24
[ 1264.670863] [<d000491d>] do_IRQ+0x35/0x38
[ 1264.675141] [<d000660c>] do_interrupt+0x70/0x90
[ 1264.679959] [<d00043d1>] common_exception_return+0x0/0x83
[ 1264.685635] [<d02c8eb4>] macb_start_xmit+0x414/0x418
[ 1264.690905] [<d0332eb1>] dev_hard_start_xmit+0x2ed/0x450
[ 1264.696521] [<d034839e>] sch_direct_xmit+0x6e/0x138
[ 1264.701720] [<d0333449>] __dev_queue_xmit+0x38d/0x5f8
[ 1264.707058] [<d03336c8>] dev_queue_xmit+0x14/0x18
[ 1264.712049] [<d033ab64>] neigh_resolve_output+0x180/0x190
[ 1264.717734] [<d0362ff2>] ip_finish_output2+0x37a/0x43c
[ 1264.723186] [<d0364168>] ip_finish_output+0x1b8/0x200
[ 1264.728532] [<d0364969>] ip_mc_output+0x179/0x1cc
[ 1264.733532] [<d03642e5>] ip_local_out+0x45/0x5c
[ 1264.738359] [<d03651ae>] ip_send_skb+0x16/0x64
[ 1264.743097] [<d03815f4>] udp_send_skb+0x160/0x1c8
[ 1264.748098] [<d0382741>] udp_sendmsg+0x45d/0x5a8
[ 1264.753009] [<d038a7f9>] inet_sendmsg+0x21/0x3c
[ 1264.757801] [<d0317de5>] sock_sendmsg+0x1d/0x44
[ 1264.762629] [<d03188e1>] SyS_sendto+0x89/0xa4
[ 1264.767288] [<d000481c>] system_call+0x40/0x50
[ 1264.772010] [<d00043d1>] common_exception_return+0x0/0x83
> Thanks,
> Richard
Regards,
Rafal
^ 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