* 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 net-next v2 04/19] net: switchdev: Change notifier chain to be atomic
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-5-jiri@resnulli.us>
On 8.6.2017 08:44, Jiri Pirko wrote:
> From: Arkadi Sharshevsky <arkadis@mellanox.com>
>
> In order to use the switchdev notifier chain for FDB sync with the
> device it has to be changed to atomic. The is done because the bridge
> can learn new FDBs in atomic context.
>
> Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>
> Reviewed-by: Ido Schimmel <idosch@mellanox.com>
> Reviewed-by: Ivan Vecera <ivecera@redhat.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> ---
> net/switchdev/switchdev.c | 30 ++++++------------------------
> 1 file changed, 6 insertions(+), 24 deletions(-)
>
> diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
> index 8d40a7d..25dc67e 100644
> --- a/net/switchdev/switchdev.c
> +++ b/net/switchdev/switchdev.c
> @@ -571,24 +571,17 @@ int switchdev_port_obj_dump(struct net_device *dev, struct switchdev_obj *obj,
> }
> EXPORT_SYMBOL_GPL(switchdev_port_obj_dump);
>
> -static RAW_NOTIFIER_HEAD(switchdev_notif_chain);
> +static ATOMIC_NOTIFIER_HEAD(switchdev_notif_chain);
>
> /**
> * register_switchdev_notifier - Register notifier
> * @nb: notifier_block
> *
> - * Register switch device notifier. This should be used by code
> - * which needs to monitor events happening in particular device.
> - * Return values are same as for atomic_notifier_chain_register().
> + * Register switch device notifier.
> */
> int register_switchdev_notifier(struct notifier_block *nb)
> {
> - int err;
> -
> - rtnl_lock();
> - err = raw_notifier_chain_register(&switchdev_notif_chain, nb);
> - rtnl_unlock();
> - return err;
> + return atomic_notifier_chain_register(&switchdev_notif_chain, nb);
> }
> EXPORT_SYMBOL_GPL(register_switchdev_notifier);
>
> @@ -597,16 +590,10 @@ EXPORT_SYMBOL_GPL(register_switchdev_notifier);
> * @nb: notifier_block
> *
> * Unregister switch device notifier.
> - * Return values are same as for atomic_notifier_chain_unregister().
> */
> int unregister_switchdev_notifier(struct notifier_block *nb)
> {
> - int err;
> -
> - rtnl_lock();
> - err = raw_notifier_chain_unregister(&switchdev_notif_chain, nb);
> - rtnl_unlock();
> - return err;
> + return atomic_notifier_chain_unregister(&switchdev_notif_chain, nb);
> }
> EXPORT_SYMBOL_GPL(unregister_switchdev_notifier);
>
> @@ -616,18 +603,13 @@ EXPORT_SYMBOL_GPL(unregister_switchdev_notifier);
> * @dev: port device
> * @info: notifier information data
> *
> - * Call all network notifier blocks. This should be called by driver
> - * when it needs to propagate hardware event.
> - * Return values are same as for atomic_notifier_call_chain().
> - * rtnl_lock must be held.
> + * Call all network notifier blocks.
> */
> int call_switchdev_notifiers(unsigned long val, struct net_device *dev,
> struct switchdev_notifier_info *info)
> {
> - ASSERT_RTNL();
> -
> info->dev = dev;
> - return raw_notifier_call_chain(&switchdev_notif_chain, val, info);
> + return atomic_notifier_call_chain(&switchdev_notif_chain, val, info);
> }
> EXPORT_SYMBOL_GPL(call_switchdev_notifiers);
>
>
Reviewed-by: Ivan Vecera <ivecera@redhat.com>
^ permalink raw reply
* Re: [patch net-next v2 01/19] net: switchdev: Add support for querying supported bridge flags by hardware
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-2-jiri@resnulli.us>
On 8.6.2017 08:44, Jiri Pirko wrote:
> From: Arkadi Sharshevsky <arkadis@mellanox.com>
>
> This is done as a preparation stage before setting the bridge port flags
> from the bridge code. Currently the device can be queried for the bridge
> flags state, but the querier cannot distinguish if the flag is disabled
> or if it is not supported at all. Thus, add new attr and a bit-mask which
> include information regarding the support on a per-flag basis.
>
> Drivers that support bridge offload but not support bridge flags should
> return zeroed bitmask.
>
> Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>
> Reviewed-by: Ido Schimmel <idosch@mellanox.com>
> Reviewed-by: Ivan Vecera <ivecera@redhat.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> ---
> include/net/switchdev.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/net/switchdev.h b/include/net/switchdev.h
> index 929d6af..63a754d 100644
> --- a/include/net/switchdev.h
> +++ b/include/net/switchdev.h
> @@ -46,6 +46,7 @@ enum switchdev_attr_id {
> SWITCHDEV_ATTR_ID_PORT_PARENT_ID,
> SWITCHDEV_ATTR_ID_PORT_STP_STATE,
> SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS,
> + SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT,
> SWITCHDEV_ATTR_ID_PORT_MROUTER,
> SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME,
> SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING,
> @@ -62,6 +63,7 @@ struct switchdev_attr {
> struct netdev_phys_item_id ppid; /* PORT_PARENT_ID */
> u8 stp_state; /* PORT_STP_STATE */
> unsigned long brport_flags; /* PORT_BRIDGE_FLAGS */
> + unsigned long brport_flags_support; /* PORT_BRIDGE_FLAGS_SUPPORT */
> bool mrouter; /* PORT_MROUTER */
> clock_t ageing_time; /* BRIDGE_AGEING_TIME */
> bool vlan_filtering; /* BRIDGE_VLAN_FILTERING */
>
Reviewed-by: Ivan Vecera <ivecera@redhat.com>
^ permalink raw reply
* Re: [patch net-next v2 02/19] net: bridge: Add support for offloading port attributes
From: Ivan Vecera @ 2017-06-08 9:29 UTC (permalink / raw)
To: Jiri Pirko, netdev; +Cc: davem, idosch, arkadis, mlxsw, roopa, stephen, nikolay
In-Reply-To: <20170608064428.4785-3-jiri@resnulli.us>
On 8.6.2017 08:44, Jiri Pirko wrote:
> From: Arkadi Sharshevsky <arkadis@mellanox.com>
>
> Currently the flood, learning and learning_sync port attributes are
> offloaded by setting the SELF flag. Add support for offloading the
> flood and learning attribute through the bridge code. In case of
> setting an unsupported flag on a offloded port the operation will
> fail.
>
> The learning_sync attribute doesn't have any software representation
> and cannot be offloaded through the bridge code.
>
> Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>
> Reviewed-by: Ido Schimmel <idosch@mellanox.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> ---
> net/bridge/br_netlink.c | 87 +++++++++++++++++++++++++++++++++++------------
> net/bridge/br_private.h | 10 ++++++
> net/bridge/br_switchdev.c | 43 +++++++++++++++++++++++
> 3 files changed, 119 insertions(+), 21 deletions(-)
>
> diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
> index 3bcda55..63dca34 100644
> --- a/net/bridge/br_netlink.c
> +++ b/net/bridge/br_netlink.c
> @@ -662,16 +662,26 @@ static int br_set_port_state(struct net_bridge_port *p, u8 state)
> }
>
> /* Set/clear or port flags based on attribute */
> -static void br_set_port_flag(struct net_bridge_port *p, struct nlattr *tb[],
> - int attrtype, unsigned long mask)
> +static int br_set_port_flag(struct net_bridge_port *p, struct nlattr *tb[],
> + int attrtype, unsigned long mask)
> {
> - if (tb[attrtype]) {
> - u8 flag = nla_get_u8(tb[attrtype]);
> - if (flag)
> - p->flags |= mask;
> - else
> - p->flags &= ~mask;
> - }
> + unsigned long flags;
> + int err;
> +
> + if (!tb[attrtype])
> + return 0;
> +
> + if (nla_get_u8(tb[attrtype]))
> + flags = p->flags | mask;
> + else
> + flags = p->flags & ~mask;
> +
> + err = br_switchdev_set_port_flag(p, flags, mask);
> + if (err)
> + return err;
> +
> + p->flags = flags;
> + return 0;
> }
>
> /* Process bridge protocol info on port */
> @@ -681,20 +691,55 @@ static int br_setport(struct net_bridge_port *p, struct nlattr *tb[])
> bool br_vlan_tunnel_old = false;
> int err;
>
> - br_set_port_flag(p, tb, IFLA_BRPORT_MODE, BR_HAIRPIN_MODE);
> - br_set_port_flag(p, tb, IFLA_BRPORT_GUARD, BR_BPDU_GUARD);
> - br_set_port_flag(p, tb, IFLA_BRPORT_FAST_LEAVE, BR_MULTICAST_FAST_LEAVE);
> - br_set_port_flag(p, tb, IFLA_BRPORT_PROTECT, BR_ROOT_BLOCK);
> - br_set_port_flag(p, tb, IFLA_BRPORT_LEARNING, BR_LEARNING);
> - br_set_port_flag(p, tb, IFLA_BRPORT_UNICAST_FLOOD, BR_FLOOD);
> - br_set_port_flag(p, tb, IFLA_BRPORT_MCAST_FLOOD, BR_MCAST_FLOOD);
> - br_set_port_flag(p, tb, IFLA_BRPORT_MCAST_TO_UCAST, BR_MULTICAST_TO_UNICAST);
> - br_set_port_flag(p, tb, IFLA_BRPORT_BCAST_FLOOD, BR_BCAST_FLOOD);
> - br_set_port_flag(p, tb, IFLA_BRPORT_PROXYARP, BR_PROXYARP);
> - br_set_port_flag(p, tb, IFLA_BRPORT_PROXYARP_WIFI, BR_PROXYARP_WIFI);
> + err = br_set_port_flag(p, tb, IFLA_BRPORT_MODE, BR_HAIRPIN_MODE);
> + if (err)
> + return err;
> +
> + err = br_set_port_flag(p, tb, IFLA_BRPORT_GUARD, BR_BPDU_GUARD);
> + if (err)
> + return err;
> +
> + err = br_set_port_flag(p, tb, IFLA_BRPORT_FAST_LEAVE, BR_MULTICAST_FAST_LEAVE);
> + if (err)
> + return err;
> +
> + err = br_set_port_flag(p, tb, IFLA_BRPORT_PROTECT, BR_ROOT_BLOCK);
> + if (err)
> + return err;
> +
> + err = br_set_port_flag(p, tb, IFLA_BRPORT_LEARNING, BR_LEARNING);
> + if (err)
> + return err;
> +
> + err = br_set_port_flag(p, tb, IFLA_BRPORT_UNICAST_FLOOD, BR_FLOOD);
> + if (err)
> + return err;
> +
> + err = br_set_port_flag(p, tb, IFLA_BRPORT_MCAST_FLOOD, BR_MCAST_FLOOD);
> + if (err)
> + return err;
> +
> + err = br_set_port_flag(p, tb, IFLA_BRPORT_MCAST_TO_UCAST, BR_MULTICAST_TO_UNICAST);
> + if (err)
> + return err;
> +
> + err = br_set_port_flag(p, tb, IFLA_BRPORT_BCAST_FLOOD, BR_BCAST_FLOOD);
> + if (err)
> + return err;
> +
> + err = br_set_port_flag(p, tb, IFLA_BRPORT_PROXYARP, BR_PROXYARP);
> + if (err)
> + return err;
> +
> + err = br_set_port_flag(p, tb, IFLA_BRPORT_PROXYARP_WIFI, BR_PROXYARP_WIFI);
> + if (err)
> + return err;
>
> br_vlan_tunnel_old = (p->flags & BR_VLAN_TUNNEL) ? true : false;
> - br_set_port_flag(p, tb, IFLA_BRPORT_VLAN_TUNNEL, BR_VLAN_TUNNEL);
> + err = br_set_port_flag(p, tb, IFLA_BRPORT_VLAN_TUNNEL, BR_VLAN_TUNNEL);
> + if (err)
> + return err;
> +
> if (br_vlan_tunnel_old && !(p->flags & BR_VLAN_TUNNEL))
> nbp_vlan_tunnel_info_flush(p);
>
> diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> index 2062692..7f43992 100644
> --- a/net/bridge/br_private.h
> +++ b/net/bridge/br_private.h
> @@ -1076,6 +1076,9 @@ void nbp_switchdev_frame_mark(const struct net_bridge_port *p,
> struct sk_buff *skb);
> bool nbp_switchdev_allowed_egress(const struct net_bridge_port *p,
> const struct sk_buff *skb);
> +int br_switchdev_set_port_flag(struct net_bridge_port *p,
> + unsigned long flags,
> + unsigned long mask);
> #else
> static inline int nbp_switchdev_mark_set(struct net_bridge_port *p)
> {
> @@ -1092,6 +1095,13 @@ static inline bool nbp_switchdev_allowed_egress(const struct net_bridge_port *p,
> {
> return true;
> }
> +
> +static inline int br_switchdev_set_port_flag(struct net_bridge_port *p,
> + unsigned long flags,
> + unsigned long mask)
> +{
> + return 0;
> +}
> #endif /* CONFIG_NET_SWITCHDEV */
>
> #endif
> diff --git a/net/bridge/br_switchdev.c b/net/bridge/br_switchdev.c
> index f4097b9..b975959 100644
> --- a/net/bridge/br_switchdev.c
> +++ b/net/bridge/br_switchdev.c
> @@ -55,3 +55,46 @@ bool nbp_switchdev_allowed_egress(const struct net_bridge_port *p,
> return !skb->offload_fwd_mark ||
> BR_INPUT_SKB_CB(skb)->offload_fwd_mark != p->offload_fwd_mark;
> }
> +
> +/* Flags that can be offloaded to hardware */
> +#define BR_PORT_FLAGS_HW_OFFLOAD (BR_LEARNING | BR_FLOOD | \
> + BR_MCAST_FLOOD | BR_BCAST_FLOOD)
> +
> +int br_switchdev_set_port_flag(struct net_bridge_port *p,
> + unsigned long flags,
> + unsigned long mask)
> +{
> + struct switchdev_attr attr = {
> + .orig_dev = p->dev,
> + .id = SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT,
> + };
> + int err;
> +
> + if (mask & ~BR_PORT_FLAGS_HW_OFFLOAD)
> + return 0;
> +
> + err = switchdev_port_attr_get(p->dev, &attr);
> + if (err == -EOPNOTSUPP)
> + return 0;
> + if (err)
> + return err;
> +
> + /* Check if specific bridge flag attribute offload is supported */
> + if (!(attr.u.brport_flags_support & mask)) {
> + br_warn(p->br, "bridge flag offload is not supported %u(%s)\n",
> + (unsigned int)p->port_no, p->dev->name);
> + return -EOPNOTSUPP;
> + }
> +
> + attr.id = SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS;
> + attr.flags = SWITCHDEV_F_DEFER;
> + attr.u.brport_flags = flags;
> + err = switchdev_port_attr_set(p->dev, &attr);
> + if (err) {
> + br_warn(p->br, "error setting offload flag on port %u(%s)\n",
> + (unsigned int)p->port_no, p->dev->name);
> + return err;
> + }
> +
> + return 0;
> +}
>
Reviewed-by: Ivan Vecera <ivecera@redhat.com>
^ 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 9:26 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Linux Netdev List, Jes Sorensen, Kernel Team, Or Gerlitz,
Tzahi Oved
In-Reply-To: <20170607234214.24723-4-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_fs.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_fs.c
> @@ -363,17 +364,28 @@ static void mlx5e_del_vlan_rules(struct mlx5e_priv *priv)
> static void mlx5e_execute_l2_action(struct mlx5e_priv *priv,
> struct mlx5e_l2_hash_node *hn)
> {
> - switch (hn->action) {
> + u8 action = hn->action;
> + int l2_err = 0;
> +
> + switch (action) {
> case MLX5E_ACTION_ADD:
> mlx5e_add_l2_flow_rule(priv, &hn->ai, MLX5E_FULLMATCH);
> + /* mlx5_mpfs_add_mac will skip mc addresses */
> + l2_err = mlx5_mpfs_add_mac(priv->mdev, hn->ai.addr);
> hn->action = MLX5E_ACTION_NONE;
> break;
>
> case MLX5E_ACTION_DEL:
> + /* mlx5_mpfs_del_mac will skip mc addresses */
> + l2_err = mlx5_mpfs_del_mac(priv->mdev, hn->ai.addr);
> mlx5e_del_l2_flow_rule(priv, &hn->ai);
> mlx5e_del_l2_from_hash(hn);
> break;
> }
> --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> static int esw_add_uc_addr(struct mlx5_eswitch *esw, struct vport_addr *vaddr)
> {
> - struct hlist_head *hash = esw->l2_table.l2_hash;
> - struct esw_uc_addr *esw_uc;
> u8 *mac = vaddr->node.addr;
> u32 vport = vaddr->vport;
> int err;
>
> - esw_uc = l2addr_hash_find(hash, mac, struct esw_uc_addr);
> - if (esw_uc) {
> + /* Skip l2_table_add for PFs,
> + * it is already done by the PF netdev in mlx5e_execute_l2_action
> + */
> + if (!vport)
> + goto fdb_add;
> +
why !vport means we should go there?
> + err = mlx5_mpfs_add_mac(esw->dev, mac);
> + if (err) {
> esw_warn(esw->dev,
> - "Failed to set L2 mac(%pM) for vport(%d), mac is already in use by vport(%d)\n",
> - mac, vport, esw_uc->vport);
> - return -EEXIST;
> + "Failed to add L2 table mac(%pM) for vport(%d), err(%d)\n",
> + mac, vport, err);
> + return err;
> }
>
> - esw_uc = l2addr_hash_add(hash, mac, struct esw_uc_addr, GFP_KERNEL);
> - if (!esw_uc)
> - return -ENOMEM;
> - esw_uc->vport = vport;
> -
> - err = set_l2_table_entry(esw->dev, mac, 0, 0, &esw_uc->table_index);
> - if (err)
> - goto abort;
> -
> +fdb_add:
> /* SRIOV is enabled: Forward UC MAC to vport */
> if (esw->fdb_table.fdb && esw->mode == SRIOV_LEGACY)
> vaddr->flow_rule = esw_fdb_set_vport_rule(esw, mac, vport);
>
> - esw_debug(esw->dev, "\tADDED UC MAC: vport[%d] %pM index:%d fr(%p)\n",
> - vport, mac, esw_uc->table_index, vaddr->flow_rule);
> - return err;
> -abort:
> - l2addr_hash_del(esw_uc);
> + esw_debug(esw->dev, "\tADDED UC MAC: vport[%d] %pM fr(%p)\n",
> + vport, mac, vaddr->flow_rule);
> +
> return err;
> }
> static int esw_del_uc_addr(struct mlx5_eswitch *esw, struct vport_addr *vaddr)
> {
> - struct hlist_head *hash = esw->l2_table.l2_hash;
> - struct esw_uc_addr *esw_uc;
> u8 *mac = vaddr->node.addr;
> u32 vport = vaddr->vport;
> + int err = 0;
>
> - esw_uc = l2addr_hash_find(hash, mac, struct esw_uc_addr);
> - if (!esw_uc || esw_uc->vport != vport) {
> - esw_debug(esw->dev,
> - "MAC(%pM) doesn't belong to vport (%d)\n",
> - mac, vport);
> - return -EINVAL;
> - }
> - esw_debug(esw->dev, "\tDELETE UC MAC: vport[%d] %pM index:%d fr(%p)\n",
> - vport, mac, esw_uc->table_index, vaddr->flow_rule);
> + /* Skip l2_table_del for PFs,
> + * it is already done by the PF netdev in mlx5e_execute_l2_action
> + */
> + if (!vport)
> + goto fdb_del;
>
> - del_l2_table_entry(esw->dev, esw_uc->table_index);
> + err = mlx5_mpfs_del_mac(esw->dev, mac);
> + if (err)
> + esw_warn(esw->dev,
> + "Failed to del L2 table mac(%pM) for vport(%d), err(%d)\n",
> + mac, vport, err);
>
> +fdb_del:
> if (vaddr->flow_rule)
> mlx5_del_flow_rules(vaddr->flow_rule);
> vaddr->flow_rule = NULL;
>
> - l2addr_hash_del(esw_uc);
> return 0;
> }
>
can we somehow put these areas into a pre-patch?
^ permalink raw reply
* Re: [patch net-next v2 05/19] net: bridge: Add support for notifying devices about FDB add/del
From: Nikolay Aleksandrov @ 2017-06-08 9:25 UTC (permalink / raw)
To: Jiri Pirko, netdev; +Cc: davem, idosch, arkadis, mlxsw, roopa, stephen, ivecera
In-Reply-To: <20170608064428.4785-6-jiri@resnulli.us>
On 08/06/17 09: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(-)
>
Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
^ permalink raw reply
* Re: [patch net-next v2 02/19] net: bridge: Add support for offloading port attributes
From: Nikolay Aleksandrov @ 2017-06-08 9:24 UTC (permalink / raw)
To: Jiri Pirko, netdev; +Cc: davem, idosch, arkadis, mlxsw, roopa, stephen, ivecera
In-Reply-To: <20170608064428.4785-3-jiri@resnulli.us>
On 08/06/17 09:44, Jiri Pirko wrote:
> From: Arkadi Sharshevsky <arkadis@mellanox.com>
>
> Currently the flood, learning and learning_sync port attributes are
> offloaded by setting the SELF flag. Add support for offloading the
> flood and learning attribute through the bridge code. In case of
> setting an unsupported flag on a offloded port the operation will
> fail.
>
> The learning_sync attribute doesn't have any software representation
> and cannot be offloaded through the bridge code.
>
> Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>
> Reviewed-by: Ido Schimmel <idosch@mellanox.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> ---
> net/bridge/br_netlink.c | 87 +++++++++++++++++++++++++++++++++++------------
> net/bridge/br_private.h | 10 ++++++
> net/bridge/br_switchdev.c | 43 +++++++++++++++++++++++
> 3 files changed, 119 insertions(+), 21 deletions(-)
>
LGTM, thanks!
Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
^ permalink raw reply
* [PATCH net 2/3] bonding: fix 802.3ad support for 14G speed
From: Nicolas Dichtel @ 2017-06-08 9:18 UTC (permalink / raw)
To: davem
Cc: netdev, j.vosburgh, vfalico, andy, thibaut.collet, linville,
Nicolas Dichtel
In-Reply-To: <1496913493-23293-1-git-send-email-nicolas.dichtel@6wind.com>
This patch adds 14 Gbps enum definition, and fixes
aggregated bandwidth calculation based on above slave links.
Fixes: 0d7e2d2166f6 ("IB/ipoib: add get_link_ksettings in ethtool")
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
drivers/net/bonding/bond_3ad.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
index d1b09be63ba4..e5386ab706ec 100644
--- a/drivers/net/bonding/bond_3ad.c
+++ b/drivers/net/bonding/bond_3ad.c
@@ -92,6 +92,7 @@ enum ad_link_speed_type {
AD_LINK_SPEED_2500MBPS,
AD_LINK_SPEED_5000MBPS,
AD_LINK_SPEED_10000MBPS,
+ AD_LINK_SPEED_14000MBPS,
AD_LINK_SPEED_20000MBPS,
AD_LINK_SPEED_25000MBPS,
AD_LINK_SPEED_40000MBPS,
@@ -263,6 +264,7 @@ static inline int __check_agg_selection_timer(struct port *port)
* %AD_LINK_SPEED_2500MBPS,
* %AD_LINK_SPEED_5000MBPS,
* %AD_LINK_SPEED_10000MBPS
+ * %AD_LINK_SPEED_14000MBPS,
* %AD_LINK_SPEED_20000MBPS
* %AD_LINK_SPEED_25000MBPS
* %AD_LINK_SPEED_40000MBPS
@@ -308,6 +310,10 @@ static u16 __get_link_speed(struct port *port)
speed = AD_LINK_SPEED_10000MBPS;
break;
+ case SPEED_14000:
+ speed = AD_LINK_SPEED_14000MBPS;
+ break;
+
case SPEED_20000:
speed = AD_LINK_SPEED_20000MBPS;
break;
@@ -725,6 +731,9 @@ static u32 __get_agg_bandwidth(struct aggregator *aggregator)
case AD_LINK_SPEED_10000MBPS:
bandwidth = nports * 10000;
break;
+ case AD_LINK_SPEED_14000MBPS:
+ bandwidth = nports * 14000;
+ break;
case AD_LINK_SPEED_20000MBPS:
bandwidth = nports * 20000;
break;
--
2.8.1
^ permalink raw reply related
* [PATCH net 3/3] ethtool.h: remind to update 802.3ad when adding new speeds
From: Nicolas Dichtel @ 2017-06-08 9:18 UTC (permalink / raw)
To: davem
Cc: netdev, j.vosburgh, vfalico, andy, thibaut.collet, linville,
Nicolas Dichtel
In-Reply-To: <1496913493-23293-1-git-send-email-nicolas.dichtel@6wind.com>
Each time a new speed is added, the bonding 802.3ad isn't updated. Add a
comment to remind the developer to update this driver.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
include/uapi/linux/ethtool.h | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index d179d7767f51..7d4a594d5d58 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -1486,8 +1486,10 @@ enum ethtool_link_mode_bit_indices {
* it was forced up into this mode or autonegotiated.
*/
-/* The forced speed, in units of 1Mb. All values 0 to INT_MAX are legal. */
-/* Update drivers/net/phy/phy.c:phy_speed_to_str() when adding new values */
+/* The forced speed, in units of 1Mb. All values 0 to INT_MAX are legal.
+ * Update drivers/net/phy/phy.c:phy_speed_to_str() and
+ * drivers/net/bonding/bond_3ad.c:__get_link_speed() when adding new values.
+ */
#define SPEED_10 10
#define SPEED_100 100
#define SPEED_1000 1000
--
2.8.1
^ permalink raw reply related
* [PATCH net 1/3] bonding: fix 802.3ad support for 5G and 50G speeds
From: Nicolas Dichtel @ 2017-06-08 9:18 UTC (permalink / raw)
To: davem
Cc: netdev, j.vosburgh, vfalico, andy, thibaut.collet, linville,
Nicolas Dichtel
From: Thibaut Collet <thibaut.collet@6wind.com>
This patch adds [5|50] Gbps enum definition, and fixes
aggregated bandwidth calculation based on above slave links.
Fixes: c9a70d43461d ("net-next: ethtool: Added port speed macros.")
Signed-off-by: Thibaut Collet <thibaut.collet@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
drivers/net/bonding/bond_3ad.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
index b44a6aeb346d..d1b09be63ba4 100644
--- a/drivers/net/bonding/bond_3ad.c
+++ b/drivers/net/bonding/bond_3ad.c
@@ -90,10 +90,12 @@ enum ad_link_speed_type {
AD_LINK_SPEED_100MBPS,
AD_LINK_SPEED_1000MBPS,
AD_LINK_SPEED_2500MBPS,
+ AD_LINK_SPEED_5000MBPS,
AD_LINK_SPEED_10000MBPS,
AD_LINK_SPEED_20000MBPS,
AD_LINK_SPEED_25000MBPS,
AD_LINK_SPEED_40000MBPS,
+ AD_LINK_SPEED_50000MBPS,
AD_LINK_SPEED_56000MBPS,
AD_LINK_SPEED_100000MBPS,
};
@@ -259,10 +261,12 @@ static inline int __check_agg_selection_timer(struct port *port)
* %AD_LINK_SPEED_100MBPS,
* %AD_LINK_SPEED_1000MBPS,
* %AD_LINK_SPEED_2500MBPS,
+ * %AD_LINK_SPEED_5000MBPS,
* %AD_LINK_SPEED_10000MBPS
* %AD_LINK_SPEED_20000MBPS
* %AD_LINK_SPEED_25000MBPS
* %AD_LINK_SPEED_40000MBPS
+ * %AD_LINK_SPEED_50000MBPS
* %AD_LINK_SPEED_56000MBPS
* %AD_LINK_SPEED_100000MBPS
*/
@@ -296,6 +300,10 @@ static u16 __get_link_speed(struct port *port)
speed = AD_LINK_SPEED_2500MBPS;
break;
+ case SPEED_5000:
+ speed = AD_LINK_SPEED_5000MBPS;
+ break;
+
case SPEED_10000:
speed = AD_LINK_SPEED_10000MBPS;
break;
@@ -312,6 +320,10 @@ static u16 __get_link_speed(struct port *port)
speed = AD_LINK_SPEED_40000MBPS;
break;
+ case SPEED_50000:
+ speed = AD_LINK_SPEED_50000MBPS;
+ break;
+
case SPEED_56000:
speed = AD_LINK_SPEED_56000MBPS;
break;
@@ -707,6 +719,9 @@ static u32 __get_agg_bandwidth(struct aggregator *aggregator)
case AD_LINK_SPEED_2500MBPS:
bandwidth = nports * 2500;
break;
+ case AD_LINK_SPEED_5000MBPS:
+ bandwidth = nports * 5000;
+ break;
case AD_LINK_SPEED_10000MBPS:
bandwidth = nports * 10000;
break;
@@ -719,6 +734,9 @@ static u32 __get_agg_bandwidth(struct aggregator *aggregator)
case AD_LINK_SPEED_40000MBPS:
bandwidth = nports * 40000;
break;
+ case AD_LINK_SPEED_50000MBPS:
+ bandwidth = nports * 50000;
+ break;
case AD_LINK_SPEED_56000MBPS:
bandwidth = nports * 56000;
break;
--
2.8.1
^ permalink raw reply related
* [PATCH] af_unix: Add sockaddr length checks before accessing sa_family in bind and connect handlers
From: Mateusz Jurczyk @ 2017-06-08 9:13 UTC (permalink / raw)
To: David S. Miller, WANG Cong, Hannes Frederic Sowa, Al Viro,
Kees Cook, Miklos Szeredi, Isaac Boukris, Andrey Vagin
Cc: netdev, linux-kernel
Verify that the caller-provided sockaddr structure is large enough to
contain the sa_family field, before accessing it in bind() and connect()
handlers of the AF_UNIX socket. Since neither syscall enforces a minimum
size of the corresponding memory region, very short sockaddrs (zero or
one byte long) result in operating on uninitialized memory while
referencing .sa_family.
Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
---
net/unix/af_unix.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 6a7fe7660551..1a0c961f4ffe 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -999,7 +999,8 @@ static int unix_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
struct path path = { };
err = -EINVAL;
- if (sunaddr->sun_family != AF_UNIX)
+ if (addr_len < offsetofend(struct sockaddr_un, sun_family) ||
+ sunaddr->sun_family != AF_UNIX)
goto out;
if (addr_len == sizeof(short)) {
@@ -1110,6 +1111,10 @@ static int unix_dgram_connect(struct socket *sock, struct sockaddr *addr,
unsigned int hash;
int err;
+ err = -EINVAL;
+ if (alen < offsetofend(struct sockaddr, sa_family))
+ goto out;
+
if (addr->sa_family != AF_UNSPEC) {
err = unix_mkname(sunaddr, alen, &hash);
if (err < 0)
--
2.13.1.508.gb3defc5cc-goog
^ permalink raw reply related
* Re: [PATCH RFC net-next 3/4] net/mlx5: Separate between eswitch and MPFS l2 table logic
From: Or Gerlitz @ 2017-06-08 9:13 UTC (permalink / raw)
To: Saeed Mahameed; +Cc: Linux Netdev List, Jes Sorensen, Kernel Team, Or Gerlitz
In-Reply-To: <20170607234214.24723-4-saeedm@mellanox.com>
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
> +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
BTW mlx5e_is_eswitch_vport_mngr() should return false in the down
stream patch when eswitch is compiled out, right?
> +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?
> + 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.
> +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: kisskb: FAILED linux-next/s390-defconfig/s390x Thu Jun 08, 18:28
From: Stephen Rothwell @ 2017-06-08 9:11 UTC (permalink / raw)
To: David Miller, Networking; +Cc: Martin Schwidefsky, Heiko Carstens
In-Reply-To: <20170608082932.1.78356@6b879c743ee1>
Hi Dave,
On Thu, 08 Jun 2017 08:29:32 -0000 noreply@ellerman.id.au wrote:
>
> FAILED linux-next/s390-defconfig/s390x Thu Jun 08, 18:28
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/13055728/
>
> Commit: Add linux-next specific files for 20170608
> e4689b9aad2ded9ed83e3c5f61e84388762295c4
> Compiler: s390x-linux-gcc (GCC) 4.6.3
>
> Possible errors
> ---------------
>
> drivers/s390/net/netiucv.c:1975:5: error: 'struct net_device' has no member named 'destructor'
> make[3]: *** [drivers/s390/net/netiucv.o] Error 1
> make[2]: *** [drivers/s390/net] Error 2
> make[1]: *** [drivers/s390] Error 2
> make: *** [sub-make] Error 2
Another one for the net tree ...
I haven't actually even build tested this, but it seems obvious ...
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 8 Jun 2017 19:06:29 +1000
Subject: [PATCH] net: s390: fix up for "Fix inconsistent teardown and release
of private netdev state"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/s390/net/netiucv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/s390/net/netiucv.c b/drivers/s390/net/netiucv.c
index dba94b486f05..fa732bd86729 100644
--- a/drivers/s390/net/netiucv.c
+++ b/drivers/s390/net/netiucv.c
@@ -1954,7 +1954,6 @@ static void netiucv_free_netdevice(struct net_device *dev)
privptr->conn = NULL; privptr->fsm = NULL;
/* privptr gets freed by free_netdev() */
}
- free_netdev(dev);
}
/**
@@ -1972,7 +1971,8 @@ static void netiucv_setup_netdevice(struct net_device *dev)
dev->mtu = NETIUCV_MTU_DEFAULT;
dev->min_mtu = 576;
dev->max_mtu = NETIUCV_MTU_MAX;
- dev->destructor = netiucv_free_netdevice;
+ dev->needs_free_netdev = true;
+ dev->priv_destructor = netiucv_free_netdevice;
dev->hard_header_len = NETIUCV_HDRLEN;
dev->addr_len = 0;
dev->type = ARPHRD_SLIP;
--
2.11.0
--
Cheers,
Stephen Rothwell
^ permalink raw reply related
* Re: [PATCH 9/9] arm64: marvell: dts: add xmdio nodes for 7k/8k
From: Antoine Tenart @ 2017-06-08 9:03 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Antoine Tenart, davem, jason, andrew, sebastian.hesselbarth,
f.fainelli, thomas.petazzoni, mw, linux, netdev, linux-arm-kernel
In-Reply-To: <8737barh96.fsf@free-electrons.com>
[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]
Hi Gregory,
On Thu, Jun 08, 2017 at 10:55:01AM +0200, Gregory CLEMENT wrote:
> On jeu., juin 08 2017, Antoine Tenart <antoine.tenart@free-electrons.com> wrote:
> > On Wed, Jun 07, 2017 at 10:38:10AM +0200, Antoine Tenart wrote:
> >> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> >> index 2a99ff8fca2a..594356243ddb 100644
> >> --- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> >> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> >> @@ -103,6 +103,13 @@
> >> clocks = <&cps_syscon0 1 9>, <&cps_syscon0 1 5>;
> >> };
> >>
> >> + cps_xmdio: mdio@12a600 {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + compatible = "marvell,xmdio";
> >> + reg = <0x12a600 0x10>;
> >> + };
> >> +
> >
> > Russell pointed out on IRC the mdio/xmdio interfaces aren't wired to
> > anything on the mcbin. We could either disable these interfaces by
> > default, or add explicit disables in the mcbin device tree.
> >
> > What's your thoughts on this?
>
> I prefer that we disable it by default and only enable it on the boards
> using it.
OK. I'll add a disabled status property in this patch, and I'll make
another series to fix the existing mdio nodes.
Thanks!
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the net tree
From: Stephen Rothwell @ 2017-06-08 9:00 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: David Miller, Networking, Linux-Next Mailing List,
Linux Kernel Mailing List, Hans de Goede
In-Reply-To: <20170608072220.GA778@kroah.com>
Hi Greg,
On Thu, 8 Jun 2017 09:22:20 +0200 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> Looks good to me, thanks for this, I'll keep it around for when the
> merge window happens.
Actually, that patch needs to go into the net tree before Dave asks
Linus to merge it - the net tree is based post v4.12-rc1 and contains
fixes for the current merge window.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: [PATCH 9/9] arm64: marvell: dts: add xmdio nodes for 7k/8k
From: Gregory CLEMENT @ 2017-06-08 8:55 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, jason, andrew, sebastian.hesselbarth, f.fainelli,
thomas.petazzoni, mw, linux, netdev, linux-arm-kernel
In-Reply-To: <20170608084515.GA12385@kwain>
Hi Antoine,
On jeu., juin 08 2017, Antoine Tenart <antoine.tenart@free-electrons.com> wrote:
> Hi Gregory,
>
> On Wed, Jun 07, 2017 at 10:38:10AM +0200, Antoine Tenart wrote:
>> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
>> index 2a99ff8fca2a..594356243ddb 100644
>> --- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
>> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
>> @@ -103,6 +103,13 @@
>> clocks = <&cps_syscon0 1 9>, <&cps_syscon0 1 5>;
>> };
>>
>> + cps_xmdio: mdio@12a600 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "marvell,xmdio";
>> + reg = <0x12a600 0x10>;
>> + };
>> +
>
> Russell pointed out on IRC the mdio/xmdio interfaces aren't wired to
> anything on the mcbin. We could either disable these interfaces by
> default, or add explicit disables in the mcbin device tree.
>
> What's your thoughts on this?
I prefer that we disable it by default and only enable it on the boards
using it.
Thanks,
Gregory
>
> Thanks!
> Antoine
>
> --
> Antoine Ténart, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 9/9] arm64: marvell: dts: add xmdio nodes for 7k/8k
From: Antoine Tenart @ 2017-06-08 8:51 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: <20170608084515.GA12385@kwain>
[-- Attachment #1: Type: text/plain, Size: 975 bytes --]
On Thu, Jun 08, 2017 at 10:45:15AM +0200, Antoine Tenart wrote:
> On Wed, Jun 07, 2017 at 10:38:10AM +0200, Antoine Tenart wrote:
> > diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> > index 2a99ff8fca2a..594356243ddb 100644
> > --- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> > +++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> > @@ -103,6 +103,13 @@
> > clocks = <&cps_syscon0 1 9>, <&cps_syscon0 1 5>;
> > };
> >
> > + cps_xmdio: mdio@12a600 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + compatible = "marvell,xmdio";
> > + reg = <0x12a600 0x10>;
> > + };
> > +
>
> Russell pointed out on IRC the mdio/xmdio interfaces aren't wired to
> anything on the mcbin.
The ones found in the cp110 slave *
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 9/9] arm64: marvell: dts: add xmdio nodes for 7k/8k
From: Antoine Tenart @ 2017-06-08 8:45 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: <20170607083810.30922-10-antoine.tenart@free-electrons.com>
[-- Attachment #1: Type: text/plain, Size: 995 bytes --]
Hi Gregory,
On Wed, Jun 07, 2017 at 10:38:10AM +0200, Antoine Tenart wrote:
> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> index 2a99ff8fca2a..594356243ddb 100644
> --- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> @@ -103,6 +103,13 @@
> clocks = <&cps_syscon0 1 9>, <&cps_syscon0 1 5>;
> };
>
> + cps_xmdio: mdio@12a600 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "marvell,xmdio";
> + reg = <0x12a600 0x10>;
> + };
> +
Russell pointed out on IRC the mdio/xmdio interfaces aren't wired to
anything on the mcbin. We could either disable these interfaces by
default, or add explicit disables in the mcbin device tree.
What's your thoughts on this?
Thanks!
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH net] openvswitch: warn about missing first netlink attribute
From: Nicolas Dichtel @ 2017-06-08 8:37 UTC (permalink / raw)
To: davem; +Cc: netdev, pshelar, dev, Nicolas Dichtel
The first netlink attribute (value 0) must always be defined
as none/unspec.
Because we cannot change an existing UAPI, I add a comment to point the
mistake and avoid to propagate it in a new ovs API in the future.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
include/uapi/linux/openvswitch.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
index 61b7d36dfe34..156ee4cab82e 100644
--- a/include/uapi/linux/openvswitch.h
+++ b/include/uapi/linux/openvswitch.h
@@ -343,6 +343,7 @@ enum ovs_key_attr {
#define OVS_KEY_ATTR_MAX (__OVS_KEY_ATTR_MAX - 1)
enum ovs_tunnel_key_attr {
+ /* OVS_TUNNEL_KEY_ATTR_NONE, standard nl API requires this attribute! */
OVS_TUNNEL_KEY_ATTR_ID, /* be64 Tunnel ID */
OVS_TUNNEL_KEY_ATTR_IPV4_SRC, /* be32 src IP address. */
OVS_TUNNEL_KEY_ATTR_IPV4_DST, /* be32 dst IP address. */
--
2.8.1
^ permalink raw reply related
* Re: [PATCH net] netlink: don't send unknown nsid
From: Nicolas Dichtel @ 2017-06-08 8:31 UTC (permalink / raw)
To: Flavio Leitner; +Cc: davem, netdev
In-Reply-To: <20170607183746.GD2658@x240.lan>
Le 07/06/2017 à 21:14, Flavio Leitner a écrit :
> On Mon, Jun 05, 2017 at 10:40:24AM +0200, Nicolas Dichtel wrote:
>>> Let me ask this instead: How do you think userspace should behave when
>>> netnsid allocation fails?
>>>
>> There is two ways to assign a nsid:
>> - manually with netlink ('ip netns set'). In this case, the error is reported
>> to userspace via netlink.
>
> OK.
>
>> - automatically when a x-netns interface is created. The link-nsid is also
>> reported to userspace. If the allocation failed, NETNSA_NSID_NOT_ASSIGNED is
>> reported. And if you were able to create this x-netns interface, it means
>> that you have access to this peer netns, thus you can try to assign the nsid
>> manually.
>
> Does that prevent the interface to be created?
No.
>
>> So, in both cases, userland knows that something went wrong.
>> Do you have another scenario in mind?
>
> Let's say the app is restarted, or another monitoring app is executed
> with enough perms. How will it identify the error condition?
Your app wants to monitor a subset of netns. It means that you already have a
way to identify those netns, something like a file stored somewhere
(/var/run/netns/, /proc/<pid>/ns/net, ...). Thus, it's easy to check if those
netns have a nsid assigned in the netns where your app will open the socket.
This option was called NETLINK_F_LISTEN_ALL_NSID, because it only enables to
listen netns *with* a nsid assigned, nothing more. It's up to the user to ensure
that nsid are correctly assigned.
Regards,
Nicolas
^ permalink raw reply
* RE: [linuxwifi] [PATCH] net: wireless: intel: iwlwifi: dvm: fix tid mask
From: Grumbach, Emmanuel @ 2017-06-08 8:31 UTC (permalink / raw)
To: Seraphime Kirkovski
Cc: luca@coelho.fi, Berg, Johannes, Coelho, Luciano, linuxwifi,
Kalle Valo, open list:INTEL WIRELESS WIFI LINK (iwlwifi),
open list:NETWORKING DRIVERS, open list
In-Reply-To: <20170608074954.qihkavvqdtwn4zmp@macchiaveli>
>
> On Thu, Jun 08, 2017 at 06:31:01AM +0000, Grumbach, Emmanuel wrote:
> > Hi,
>
> Hi,
>
> > True, OTOH we need tid to be 8 sometimes. We *just* need to make sure
> > that we don't index tid_data with this. Hence I think the proper fix is:
> >
> > diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
> > b/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
> > index 06ac3f1..16a8646 100644
> > --- a/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
> > +++ b/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
> > @@ -1190,11 +1190,11 @@ void iwlagn_rx_reply_tx(struct iwl_priv *priv,
> struct iwl_rx_cmd_buffer *rxb)
> > next_reclaimed;
> > IWL_DEBUG_TX_REPLY(priv, "Next reclaimed packet:%d\n",
> > next_reclaimed);
> > + iwlagn_check_ratid_empty(priv, sta_id, tid);
> > }
> >
> > iwl_trans_reclaim(priv->trans, txq_id, ssn, &skbs);
> >
> > - iwlagn_check_ratid_empty(priv, sta_id, tid);
> > freed = 0;
> >
> > /* process frames */
>
> I can confirm it works. You can add my Tested-By.
Patch in review in our internal tree. It'll be upstreamed through the regular process.
Thanks for your report and debug work.
^ permalink raw reply
* Re: [PATCH RFC net-next 2/4] net/mlx5e: NIC netdev init flow cleanup
From: Or Gerlitz @ 2017-06-08 8:30 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Linux Netdev List, Jes Sorensen, Kernel Team, Or Gerlitz,
Tzahi Oved
In-Reply-To: <20170607234214.24723-3-saeedm@mellanox.com>
On Thu, Jun 8, 2017 at 2:42 AM, Saeed Mahameed <saeedm@mellanox.com> wrote:
> Remove redundant mlx5_eswitch_unregister_vport_rep in mlx5e_add error flow.
Maybe have point patch that makes it clear we fix commit 26e59d807 ?
> Hide mlx5e_rep_priv and eswitch internal structures from en_main.c in
> preparation for downstream patches which allows compiling the driver
> without en_rep and eswitch.
otherwise than the about comment and another one re how to do that,
patch seems fine
> static void *mlx5e_add(struct mlx5_core_dev *mdev)
> {
> - struct mlx5_eswitch *esw = mdev->priv.eswitch;
> - int total_vfs = MLX5_TOTAL_VPORTS(mdev);
> - struct mlx5e_rep_priv *rpriv = NULL;
> + struct net_device *netdev;
> + void *rpriv = NULL;
> void *priv;
> - int vport;
> int err;
> - struct net_device *netdev;
>
> err = mlx5e_check_required_hca_cap(mdev);
> if (err)
> return NULL;
>
> if (MLX5_CAP_GEN(mdev, vport_group_manager)) {
> - rpriv = kzalloc(sizeof(*rpriv), GFP_KERNEL);
> + rpriv = mlx5e_alloc_nic_rep_priv(mdev);
> if (!rpriv) {
> - mlx5_core_warn(mdev,
> - "Not creating net device, Failed to alloc rep priv data\n");
> + mlx5_core_warn(mdev, "Failed to alloc NIC rep priv data\n");
> return NULL;
> }
> - rpriv->rep = &esw->offloads.vport_reps[0];
> }
>
> netdev = mlx5e_create_netdev(mdev, &mlx5e_nic_profile, rpriv);
> if (!netdev) {
> mlx5_core_err(mdev, "mlx5e_create_netdev failed\n");
> - goto err_unregister_reps;
> + kfree(rpriv);
> + return NULL;
nit - would be better to just do goto err_something and avoid
repeating the kfree/return we already have there
> }
>
> priv = netdev_priv(netdev);
> @@ -4407,10 +4403,6 @@ static void *mlx5e_add(struct mlx5_core_dev *mdev)
> err_destroy_netdev:
> mlx5e_destroy_netdev(priv);
>
> -err_unregister_reps:
> - for (vport = 1; vport < total_vfs; vport++)
> - mlx5_eswitch_unregister_vport_rep(esw, vport);
> -
+err_something:
> kfree(rpriv);
> return NULL;
> }
^ permalink raw reply
* Re: ath9k_htc - Division by zero in kernel (as well as firmware panic)
From: Oleksij Rempel @ 2017-06-08 8:15 UTC (permalink / raw)
To: Tobias Diedrich, Nathan Royce, QCA ath9k Development, Kalle Valo,
linux-wireless, netdev, linux-kernel, ath9k_htc_fw
In-Reply-To: <20170607223913.GD20162@yumi.tdiedrich.de>
[-- Attachment #1.1: Type: text/plain, Size: 15218 bytes --]
Am 08.06.2017 um 00:39 schrieb Tobias Diedrich:
> Oleksij Rempel wrote:
>> Am 07.06.2017 um 02:12 schrieb Tobias Diedrich:
>>> Oleksij Rempel wrote:
>>>> Yes, this is "normal" problem. The firmware has no error handler for PCI
>>>> bus related exceptions. So if we filed to read PCI bus first time, we
>>>> have choice to Ooops and stall or Ooops and reboot ASAP. So we reboot
>>>> and provide an kernel "firmware panic!" message.
>>>> Every one who can or will to fix this, is welcome.
>>>>
>>>>> *****
>>>>> Jun 02 14:55:30 computer kernel: usb 1-1.1: ath: firmware panic!
>>>>> exccause: 0x0000000d; pc: 0x0090ae81; badvaddr: 0x10ff4038.
>>> [...]
>>>
>>>> memdmp 50ae78 50ae88
>>>
>>> 50ae78: 6c10 0412 6aa2 0c02 0088 20c0 2008 1940 l...j..........@
>>>
>>> [...copy to bin...]
>>> $ bin/objdump -b binary -m xtensa -D /tmp/memdump.bin
>>> [..]
>>> 0: 6c1004 entry a1, 32
>>> 3: 126aa2 l32r a2, 0xfffdaa8c
>>> 6: 0c0200 memw
>>> 9: 8820 l32i.n a8, a2, 0 <----------Exception cause PC still points at load
>>> b: c020 movi.n a2, 0
>>> d: 081940 extui a9, a8, 1, 1
>>>
>>> Judging from that it should be fairly simple to at least implement
>>> some sort of retry, possible after triggering a PCIe link retrain?
>>
>> I assume, yes.
>>
>>> There are some related PCIe root complex registers that may point to
>>> what exactly failed if they were dumped.
>>>
>>> The root complex registers live at 0x00040000 and I think match the
>>> registers described for the root complex in the AR9344 datasheet.
>>
>> Suddenly I don't have ar7010 docs to tell..
>>
>>> PCIE_INT_MASK would map to 0x40050 and has a bit for SYS_ERR:
>>> "A system error. The RC Core asserts CFG_SYS_ERR_RC if any device in
>>> the hierarchy reports any of the following errors and the associated
>>> enable bit is set in the Root Control register: ERR_COR, ERR_FATAL,
>>> ERR_NONFATAL."
>>>
>>> AFAICS link retrain can be done by setting bit3 (INIT_RST,
>>> "Application request to initiate a training reset") in
>>> PCIE_APP (0x40000).
>>>
>>> See sboot/magpie_1_1/sboot/cmnos/eeprom/src/cmnos_eeprom.c (which
>>> flips some bits in the RC to enable the PCIe bus for reading the
>>> EEPROM).
>>>
>>> The root complex pci configuration space is at 0x20000 which could
>>> have further error details:
>>>> memdmp 20000 20200
>>>
>>> 020000: a02a 168c 0010 0006 0000 0001 0001 0000 .*..............
>>> 020010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>>> 020020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>>> 020030: 0000 0000 0000 0040 0000 0000 0000 01ff .......@........
>>> 020040: 5bc3 5001 0000 0000 0000 0000 0000 0000 [.P.............
>>> 020050: 0080 7005 0000 0000 0000 0000 0000 0000 ..p.............
>>> 020060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>>> 020070: 0042 0010 0000 8701 0000 2010 0013 4411 .B............D.
>>> 020080: 3011 0000 0000 0000 00c0 03c0 0000 0000 0...............
>>> 020090: 0000 0000 0000 0010 0000 0000 0000 0000 ................
>>> 0200a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>>> 0200b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>>> 0200c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>>> 0200d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>>> 0200e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>>> 0200f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>>> 020100: 1401 0001 0000 0000 0000 0000 0006 2030 ...............0
>>> 020110: 0000 0000 0000 2000 0000 00a0 0000 0000 ................
>>> 020120: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>>> 020130: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>>> 020140: 0001 0002 0000 0000 0000 0000 0000 0000 ................
>>> 020150: 0000 0000 8000 00ff 0000 0000 0000 0000 ................
>>> 020160: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>>> 020170: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>>> 020180: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>>> 020190: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>>> 0201a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>>> 0201b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>>> 0201c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>>> 0201d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>>> 0201e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>>> 0201f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>>>
>>> Transformed into something suitable for feeding into lspci -F:
>>>
>>> 00:00.0 Description filled in by lspci
>>> 00: 8c 16 2a a0 06 00 10 00 01 00 00 00 00 00 01 00
>>> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> 30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 01 00 00
>>> 40: 01 50 c3 5b 00 00 00 00 00 00 00 00 00 00 00 00
>>> 50: 05 70 80 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> 70: 10 00 42 00 01 87 00 00 10 20 00 00 11 44 13 00
>>> 80: 00 00 11 30 00 00 00 00 c0 03 c0 00 00 00 00 00
>>> 90: 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00
>>> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>
>>> $ lspci -F /tmp/hexdump -vvv
>>> 00:00.0 Non-VGA unclassified device: Qualcomm Atheros Device a02a (rev 01)
>>> !!! Invalid class 0000 for header type 01
>>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>>> Latency: 0
>>> Interrupt: pin A routed to IRQ 255
>>> Bus: primary=00, secondary=00, subordinate=00, sec-latency=0
>>> I/O behind bridge: 00000000-00000fff
>>> Memory behind bridge: 00000000-000fffff
>>> Prefetchable memory behind bridge: 00000000-000fffff
>>> Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
>>> BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
>>> PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
>>> Capabilities: [40] Power Management version 3
>>> Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA PME(D0+,D1+,D2-,D3hot+,D3cold-)
>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
>>> Address: 0000000000000000 Data: 0000
>>> Capabilities: [70] Express (v2) Root Port (Slot-), MSI 00
>>> DevCap: MaxPayload 256 bytes, PhantFunc 0
>>> ExtTag- RBE+
>>> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>>> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
>>> MaxPayload 128 bytes, MaxReadReq 512 bytes
>>> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
>>> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s <1us, L1 <64us
>>> ClockPM- Surprise- LLActRep+ BwNot- ASPMOptComp-
>>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
>>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
>>> RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
>>> RootCap: CRSVisible-
>>> RootSta: PME ReqID 0000, PMEStatus- PMEPending-
>>> DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF Not Supported ARIFwd-
>>> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd-
>>> LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
>>> Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
>>> Compliance De-emphasis: -6dB
>>> LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
>>> EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
>>>
>>
>> Looks promising :)
>>
>
> POC seems to work, though this may additionally need to restore wifi
> state as well, no guarantees there.
This probably will be next topic. Can you address some comments in the
review and create a pull request in the github repo?
>
>> str 40018 3
> 00040018 : 00000003
>>
> Retry(1) failed PCIe access @0x10ff4038
> Before: int_mask=0 app=ffc1 reset=0
> After: int_mask=0 app=ffc1 reset=7
> wlan int status=0
>
>> str 40018 3
> 00040018 : 00000003
>>
> Retry(1) failed PCIe access @0x10ff4038
> Before: int_mask=0 app=ffc1 reset=0
> After: int_mask=0 app=ffc1 reset=7
> wlan int status=0
>>
>
>
> diff --git a/target_firmware/magpie_fw_dev/target/init/app_start.c b/target_firmware/magpie_fw_dev/target/init/app_start.c
> index 8fa9c8b..fea62c1 100644
> --- a/target_firmware/magpie_fw_dev/target/init/app_start.c
> +++ b/target_firmware/magpie_fw_dev/target/init/app_start.c
> @@ -137,6 +137,13 @@ void __section(boot) __noreturn __visible app_start(void)
>
> A_PRINTF(" A_WDT_INIT()\n\r");
>
> +#if defined(PROJECT_MAGPIE)
please, use /**/ style comments.
> + // For some reason needs to be called again here for the
> + // exception handlers to work properly, at least on the XBOX
> + // adapter.
> + fatal_exception_func();
> +#endif
> +
> #if defined(PROJECT_K2)
> save_cmnos_printf = fw_cmnos_printf;
> #endif
> diff --git a/target_firmware/magpie_fw_dev/target/init/init.c b/target_firmware/magpie_fw_dev/target/init/init.c
> index 7484c05..cad2519 100755
> --- a/target_firmware/magpie_fw_dev/target/init/init.c
> +++ b/target_firmware/magpie_fw_dev/target/init/init.c
> @@ -212,6 +212,78 @@ LOCAL void zfGenWrongEpidEvent(uint32_t epid)
> mUSB_EP3_XFER_DONE();
> }
>
> +static void
> +AR7010_pcie_reset(void)
> +{
> +#define PCIE_RC_ACCESS_DELAY 20
> +
> +#define PCI_RC_RESET_BIT BIT6
> +#define PCI_RC_PHY_RESET_BIT BIT7
> +#define PCI_RC_PLL_RESET_BIT BIT8
> +#define PCI_RC_PHY_SHIFT_RESET_BIT BIT10
> +
> +#define HAL_WORD_REG_WRITE(addr, val) do { *((uint32_t*)(addr)) = val; } while (0)
> +#define HAL_WORD_REG_READ(addr) (*((uint32_t*)(addr)))
we already have iowrite32* ioread32* functions, why do we need more?
> +#define CMD_PCI_RC_RESET_ON() HAL_WORD_REG_WRITE(MAGPIE_REG_RST_RESET_ADDR, \
> + (HAL_WORD_REG_READ(MAGPIE_REG_RST_RESET_ADDR)| \
> + (PCI_RC_PHY_SHIFT_RESET_BIT|PCI_RC_PLL_RESET_BIT|PCI_RC_PHY_RESET_BIT|PCI_RC_RESET_BIT)))
> +
> +#define CMD_PCI_RC_RESET_CLR() HAL_WORD_REG_WRITE(MAGPIE_REG_RST_RESET_ADDR, \
> + (HAL_WORD_REG_READ(MAGPIE_REG_RST_RESET_ADDR)& \
> + (~(PCI_RC_PHY_SHIFT_RESET_BIT|PCI_RC_PLL_RESET_BIT|PCI_RC_PHY_RESET_BIT|PCI_RC_RESET_BIT))))
> +
> + int i;
> +
> + CMD_PCI_RC_RESET_ON();
> + A_DELAY_USECS(PCIE_RC_ACCESS_DELAY);
> +
> + /* dereset the reset */
> + CMD_PCI_RC_RESET_CLR();
> + A_DELAY_USECS(500);
> +
> + /* 7. set bus master and memory space enable */
> + DEBUG_SYSTEM_STATE = (DEBUG_SYSTEM_STATE&(~0xff)) | 0x45;
> + HAL_WORD_REG_WRITE(0x00020004, (HAL_WORD_REG_READ(0x00020004)|(BIT1|BIT2)));
> + A_DELAY_USECS(PCIE_RC_ACCESS_DELAY);
> +
> + /* 7.5. asser pcie_ep reset */
> + HAL_WORD_REG_WRITE(0x00040018, (HAL_WORD_REG_READ(0x00040018) & ~(0x1 << 2)));
> + A_DELAY_USECS(PCIE_RC_ACCESS_DELAY);
> +
> + /* 7.5. de-asser pcie_ep reset */
> + HAL_WORD_REG_WRITE(0x00040018, (HAL_WORD_REG_READ(0x00040018)|(0x1 << 2)));
> + A_DELAY_USECS(PCIE_RC_ACCESS_DELAY);
> +
> + /* 8. set app_ltssm_enable */
> + DEBUG_SYSTEM_STATE = (DEBUG_SYSTEM_STATE&(~0xff)) | 0x46;
> + HAL_WORD_REG_WRITE(0x00040000, (HAL_WORD_REG_READ(0x00040000)|0xffc1));
> +
> + /*!
> + * Receive control (PCIE_RESET),
> + * 0x40018, BIT0: LINK_UP, PHY Link up -PHY Link up/down indicator
> + * in case the link up is not ready and we access the 0x14000000,
> + * vmc will hang here
> + */
> +
> + /* poll 0x40018/bit0 (1000 times) until it turns to 1 */
> + i = 10000;
> + while(i-->0)
> + {
> + uint32_t reg_value = HAL_WORD_REG_READ(0x00040018);
> + if( reg_value & BIT0 )
> + break;
> + A_DELAY_USECS(PCIE_RC_ACCESS_DELAY);
> + }
> +
> + HAL_WORD_REG_WRITE(0x14000004, (HAL_WORD_REG_READ(0x14000004)|0x116));
> + A_DELAY_USECS(PCIE_RC_ACCESS_DELAY);
> +
> + HAL_WORD_REG_WRITE(0x14000010, (HAL_WORD_REG_READ(0x14000010)|EEPROM_CTRL_BASE));
> +}
> +
> +static int exception_retries = 0;
> +
> void
> AR6002_fatal_exception_handler_patch(CPU_exception_frame_t *exc_frame)
> {
> @@ -226,6 +298,32 @@ AR6002_fatal_exception_handler_patch(CPU_exception_frame_t *exc_frame)
> dump.pc = exc_frame->xt_pc;
> dump.assline = 0;
i would prefer to put it in to separate function. may be, complete pci
code in a separate file?
> + if (dump.badvaddr >= 0x10000000 &&
> + dump.badvaddr < 0x18000000) {
if (!bla)
return;
> + // Exception while accessing PCIe memory space.
> + volatile uint32_t *pcie_app = (uint32_t*) 0x40000;
> + volatile uint32_t *pcie_reset = (uint32_t*) 0x40018;
> + volatile uint32_t *pcie_int_mask = (uint32_t*) 0x40050;
magic values should be replaced.
> + // Maybe retry.
> + if (++exception_retries < 2) {
if (!bla)
return;
> + A_PRINTF("\nRetry(%d) failed PCIe access @0x%x\n",
> + exception_retries, dump.badvaddr);
> + A_PRINTF("Before: int_mask=%x app=%x reset=%x\n", *pcie_int_mask, *pcie_app, *pcie_reset);
> +
> + AR7010_pcie_reset();
> +
> + A_PRINTF("After: int_mask=%x app=%x reset=%x\n", *pcie_int_mask, *pcie_app, *pcie_reset);
> +
> + // This should recurse if we failed to recover.
> + A_PRINTF("wlan int status=%x\n", HAL_WORD_REG_READ(0x10ff4038));
> +
> + // Reset retry counter.
> + exception_retries = 0;
> + return;
> + }
> + }
> +
> zfGenExceptionEvent(dump.exc_frame.xt_exccause, dump.pc, dump.badvaddr);
>
> #if SYSTEM_MODULE_PRINT
I'm exciting to see it mainline. Thank you for your work!
--
Regards,
Oleksij
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply
* [PATCH net-next] cxgb4: handle interrupt raised when FW crashes
From: Ganesh Goudar @ 2017-06-08 8:13 UTC (permalink / raw)
To: netdev, davem
Cc: nirranjan, indranil, venkatesh, Rahul Lakkireddy, Ganesh Goudar
From: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Handle TIMER0INT when FW crashes. Check for PCIE_FW[FW_EVAL]
and if it says "Device FW Crashed", then treat it as fatal.
Else, non-fatal.
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 19 ++++++++++++++++++-
drivers/net/ethernet/chelsio/cxgb4/t4_regs.h | 4 ++++
drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 4 ++++
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index da1322d..4fd5010 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -4040,6 +4040,7 @@ static void cim_intr_handler(struct adapter *adapter)
{ MBHOSTPARERR_F, "CIM mailbox host parity error", -1, 1 },
{ TIEQINPARERRINT_F, "CIM TIEQ outgoing parity error", -1, 1 },
{ TIEQOUTPARERRINT_F, "CIM TIEQ incoming parity error", -1, 1 },
+ { TIMER0INT_F, "CIM TIMER0 interrupt", -1, 1 },
{ 0 }
};
static const struct intr_info cim_upintr_info[] = {
@@ -4075,10 +4076,26 @@ static void cim_intr_handler(struct adapter *adapter)
};
int fat;
+ u32 val, fw_err;
- if (t4_read_reg(adapter, PCIE_FW_A) & PCIE_FW_ERR_F)
+ fw_err = t4_read_reg(adapter, PCIE_FW_A);
+ if (fw_err & PCIE_FW_ERR_F)
t4_report_fw_error(adapter);
+ /* When the Firmware detects an internal error which normally
+ * wouldn't raise a Host Interrupt, it forces a CIM Timer0 interrupt
+ * in order to make sure the Host sees the Firmware Crash. So
+ * if we have a Timer0 interrupt and don't see a Firmware Crash,
+ * ignore the Timer0 interrupt.
+ */
+
+ val = t4_read_reg(adapter, CIM_HOST_INT_CAUSE_A);
+ if (val & TIMER0INT_F)
+ if (!(fw_err & PCIE_FW_ERR_F) ||
+ (PCIE_FW_EVAL_G(fw_err) != PCIE_FW_EVAL_CRASH))
+ t4_write_reg(adapter, CIM_HOST_INT_CAUSE_A,
+ TIMER0INT_F);
+
fat = t4_handle_intr_status(adapter, CIM_HOST_INT_CAUSE_A,
cim_intr_info) +
t4_handle_intr_status(adapter, CIM_HOST_UPACC_INT_CAUSE_A,
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h b/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
index 3348d33..3884336 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
@@ -1077,6 +1077,10 @@
#define TIEQINPARERRINT_V(x) ((x) << TIEQINPARERRINT_S)
#define TIEQINPARERRINT_F TIEQINPARERRINT_V(1U)
+#define TIMER0INT_S 2
+#define TIMER0INT_V(x) ((x) << TIMER0INT_S)
+#define TIMER0INT_F TIMER0INT_V(1U)
+
#define PREFDROPINT_S 1
#define PREFDROPINT_V(x) ((x) << PREFDROPINT_S)
#define PREFDROPINT_F PREFDROPINT_V(1U)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
index c65c33c..f47461a 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
@@ -3088,6 +3088,10 @@ struct fw_debug_cmd {
#define FW_DEBUG_CMD_TYPE_G(x) \
(((x) >> FW_DEBUG_CMD_TYPE_S) & FW_DEBUG_CMD_TYPE_M)
+enum pcie_fw_eval {
+ PCIE_FW_EVAL_CRASH = 0,
+};
+
#define PCIE_FW_ERR_S 31
#define PCIE_FW_ERR_V(x) ((x) << PCIE_FW_ERR_S)
#define PCIE_FW_ERR_F PCIE_FW_ERR_V(1U)
--
2.1.0
^ permalink raw reply related
* (unknown),
From: Oliver Carter @ 2017-06-08 5:41 UTC (permalink / raw)
To: netdev
Hey Netdev
http://arc-protect.com/m7_gift_giver.php?isnt=pfcz272prn36hk
Oliver
^ 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