* [patch net-next 5/7] mlxsw: spectrum: Add trap for multicast trap-and-forward routes
From: Jiri Pirko @ 2017-09-28 17:34 UTC (permalink / raw)
To: netdev
Cc: davem, yotamg, idosch, mlxsw, nikolay, andrew, dsa, edumazet,
willemb, johannes.berg, dcaratti, pabeni, daniel, f.fainelli, fw,
gfree.wind
In-Reply-To: <20170928173415.15551-1-jiri@resnulli.us>
From: Yotam Gigi <yotamg@mellanox.com>
When a multicast route is configured with trap-and-forward action, the
packets should be marked with skb->offload_mr_fwd_mark, in order to prevent
the packets from being forwarded again by the kernel ipmr module.
Due to this, it is not possible to use the already existing multicast trap
(MLXSW_TRAP_ID_ACL1) as the packet should be marked differently. Add the
MLXSW_TRAP_ID_ACL2 which is for trap-and-forward multicast routes, and set
the offload_mr_fwd_mark skb field in its handler.
Signed-off-by: Yotam Gigi <yotamg@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 13 +++++++++++++
drivers/net/ethernet/mellanox/mlxsw/trap.h | 2 ++
2 files changed, 15 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index e9b9443..3adf237 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -3312,6 +3312,14 @@ static void mlxsw_sp_rx_listener_mark_func(struct sk_buff *skb, u8 local_port,
return mlxsw_sp_rx_listener_no_mark_func(skb, local_port, priv);
}
+static void mlxsw_sp_rx_listener_mr_mark_func(struct sk_buff *skb,
+ u8 local_port, void *priv)
+{
+ skb->offload_mr_fwd_mark = 1;
+ skb->offload_fwd_mark = 1;
+ return mlxsw_sp_rx_listener_no_mark_func(skb, local_port, priv);
+}
+
static void mlxsw_sp_rx_listener_sample_func(struct sk_buff *skb, u8 local_port,
void *priv)
{
@@ -3355,6 +3363,10 @@ static void mlxsw_sp_rx_listener_sample_func(struct sk_buff *skb, u8 local_port,
MLXSW_RXL(mlxsw_sp_rx_listener_mark_func, _trap_id, _action, \
_is_ctrl, SP_##_trap_group, DISCARD)
+#define MLXSW_SP_RXL_MR_MARK(_trap_id, _action, _trap_group, _is_ctrl) \
+ MLXSW_RXL(mlxsw_sp_rx_listener_mr_mark_func, _trap_id, _action, \
+ _is_ctrl, SP_##_trap_group, DISCARD)
+
#define MLXSW_SP_EVENTL(_func, _trap_id) \
MLXSW_EVENTL(_func, _trap_id, SP_EVENT)
@@ -3425,6 +3437,7 @@ static const struct mlxsw_listener mlxsw_sp_listener[] = {
MLXSW_SP_RXL_MARK(IPV4_PIM, TRAP_TO_CPU, PIM, false),
MLXSW_SP_RXL_MARK(RPF, TRAP_TO_CPU, RPF, false),
MLXSW_SP_RXL_MARK(ACL1, TRAP_TO_CPU, MULTICAST, false),
+ MLXSW_SP_RXL_MR_MARK(ACL2, TRAP_TO_CPU, MULTICAST, false),
};
static int mlxsw_sp_cpu_policers_set(struct mlxsw_core *mlxsw_core)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/trap.h b/drivers/net/ethernet/mellanox/mlxsw/trap.h
index a981035..ec6cef8 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/trap.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/trap.h
@@ -93,6 +93,8 @@ enum {
MLXSW_TRAP_ID_ACL0 = 0x1C0,
/* Multicast trap used for routes with trap action */
MLXSW_TRAP_ID_ACL1 = 0x1C1,
+ /* Multicast trap used for routes with trap-and-forward action */
+ MLXSW_TRAP_ID_ACL2 = 0x1C2,
MLXSW_TRAP_ID_MAX = 0x1FF
};
--
2.9.5
^ permalink raw reply related
* [patch net-next 6/7] mlxsw: spectrum: mr_tcam: Add trap-and-forward multicast route
From: Jiri Pirko @ 2017-09-28 17:34 UTC (permalink / raw)
To: netdev
Cc: davem, yotamg, idosch, mlxsw, nikolay, andrew, dsa, edumazet,
willemb, johannes.berg, dcaratti, pabeni, daniel, f.fainelli, fw,
gfree.wind
In-Reply-To: <20170928173415.15551-1-jiri@resnulli.us>
From: Yotam Gigi <yotamg@mellanox.com>
In addition to the current multicast route actions, which include trap
route action and a forward route action, add the trap-and-forward multicast
route action, and implement it in the multicast routing hardware logic.
To implement that, add a trap-and-forward ACL action as the last action in
the route flexible action set. The used trap is the ACL2 trap, which marks
the packets with offload_mr_forward_mark, to prevent the packet from being
forwarded again by the kernel.
Note: At that stage the offloading logic does not support trap-and-forward
multicast routes. This patch adds the support only in the hardware logic.
Signed-off-by: Yotam Gigi <yotamg@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.h | 1 +
drivers/net/ethernet/mellanox/mlxsw/spectrum_mr_tcam.c | 8 ++++++++
2 files changed, 9 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.h b/drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.h
index c851b23..5d26a12 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.h
@@ -42,6 +42,7 @@
enum mlxsw_sp_mr_route_action {
MLXSW_SP_MR_ROUTE_ACTION_FORWARD,
MLXSW_SP_MR_ROUTE_ACTION_TRAP,
+ MLXSW_SP_MR_ROUTE_ACTION_TRAP_AND_FORWARD,
};
enum mlxsw_sp_mr_route_prio {
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_mr_tcam.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_mr_tcam.c
index cda9e9a..3ffb28d 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_mr_tcam.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_mr_tcam.c
@@ -253,6 +253,7 @@ mlxsw_sp_mr_tcam_afa_block_create(struct mlxsw_sp *mlxsw_sp,
if (err)
goto err;
break;
+ case MLXSW_SP_MR_ROUTE_ACTION_TRAP_AND_FORWARD:
case MLXSW_SP_MR_ROUTE_ACTION_FORWARD:
/* If we are about to append a multicast router action, commit
* the erif_list.
@@ -266,6 +267,13 @@ mlxsw_sp_mr_tcam_afa_block_create(struct mlxsw_sp *mlxsw_sp,
erif_list->kvdl_index);
if (err)
goto err;
+
+ if (route_action == MLXSW_SP_MR_ROUTE_ACTION_TRAP_AND_FORWARD) {
+ err = mlxsw_afa_block_append_trap_and_forward(afa_block,
+ MLXSW_TRAP_ID_ACL2);
+ if (err)
+ goto err;
+ }
break;
default:
err = -EINVAL;
--
2.9.5
^ permalink raw reply related
* [patch net-next 7/7] mlxsw: spectrum: mr: Support trap-and-forward routes
From: Jiri Pirko @ 2017-09-28 17:34 UTC (permalink / raw)
To: netdev
Cc: davem, yotamg, idosch, mlxsw, nikolay, andrew, dsa, edumazet,
willemb, johannes.berg, dcaratti, pabeni, daniel, f.fainelli, fw,
gfree.wind
In-Reply-To: <20170928173415.15551-1-jiri@resnulli.us>
From: Yotam Gigi <yotamg@mellanox.com>
Add the support of trap-and-forward route action in the multicast routing
offloading logic. A route will be set to trap-and-forward action if one (or
more) of its output interfaces is not offload-able, i.e. does not have a
valid Spectrum RIF.
This way, a route with mixed output VIFs list, which contains both
offload-able and un-offload-able devices can go through partial offloading
in hardware, and the rest will be done in the kernel ipmr module.
Signed-off-by: Yotam Gigi <yotamg@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c | 17 ++++++++---------
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c
index 0912025..4c0848e 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c
@@ -114,9 +114,9 @@ static bool mlxsw_sp_mr_vif_valid(const struct mlxsw_sp_mr_vif *vif)
return mlxsw_sp_mr_vif_regular(vif) && vif->dev && vif->rif;
}
-static bool mlxsw_sp_mr_vif_rif_invalid(const struct mlxsw_sp_mr_vif *vif)
+static bool mlxsw_sp_mr_vif_exists(const struct mlxsw_sp_mr_vif *vif)
{
- return mlxsw_sp_mr_vif_regular(vif) && vif->dev && !vif->rif;
+ return vif->dev;
}
static bool
@@ -182,14 +182,13 @@ mlxsw_sp_mr_route_action(const struct mlxsw_sp_mr_route *mr_route)
if (!mlxsw_sp_mr_route_valid_evifs_num(mr_route))
return MLXSW_SP_MR_ROUTE_ACTION_TRAP;
- /* If either one of the eVIFs is not regular (VIF of type pimreg or
- * tunnel) or one of the VIFs has no matching RIF, trap the packet.
+ /* If one of the eVIFs has no RIF, trap-and-forward the route as there
+ * is some more routing to do in software too.
*/
- list_for_each_entry(rve, &mr_route->evif_list, route_node) {
- if (!mlxsw_sp_mr_vif_regular(rve->mr_vif) ||
- mlxsw_sp_mr_vif_rif_invalid(rve->mr_vif))
- return MLXSW_SP_MR_ROUTE_ACTION_TRAP;
- }
+ list_for_each_entry(rve, &mr_route->evif_list, route_node)
+ if (mlxsw_sp_mr_vif_exists(rve->mr_vif) && !rve->mr_vif->rif)
+ return MLXSW_SP_MR_ROUTE_ACTION_TRAP_AND_FORWARD;
+
return MLXSW_SP_MR_ROUTE_ACTION_FORWARD;
}
--
2.9.5
^ permalink raw reply related
* Re: [PATCH net] net: Set sk_prot_creator when cloning sockets to the right proto
From: David Miller @ 2017-09-28 17:34 UTC (permalink / raw)
To: cpaasch; +Cc: netdev
In-Reply-To: <20170927003850.23731-1-cpaasch@apple.com>
From: Christoph Paasch <cpaasch@apple.com>
Date: Tue, 26 Sep 2017 17:38:50 -0700
> sk->sk_prot and sk->sk_prot_creator can differ when the app uses
> IPV6_ADDRFORM (transforming an IPv6-socket to an IPv4-one).
> Which is why sk_prot_creator is there to make sure that sk_prot_free()
> does the kmem_cache_free() on the right kmem_cache slab.
>
> Now, if such a socket gets transformed back to a listening socket (using
> connect() with AF_UNSPEC) we will allocate an IPv4 tcp_sock through
> sk_clone_lock() when a new connection comes in. But sk_prot_creator will
> still point to the IPv6 kmem_cache (as everything got copied in
> sk_clone_lock()). When freeing, we will thus put this
> memory back into the IPv6 kmem_cache although it was allocated in the
> IPv4 cache. I have seen memory corruption happening because of this.
>
> With slub-debugging and MEMCG_KMEM enabled this gives the warning
> "cache_from_obj: Wrong slab cache. TCPv6 but object is from TCP"
>
> A C-program to trigger this:
...
> As far as I can see, this bug has been there since the beginning of the
> git-days.
>
> Signed-off-by: Christoph Paasch <cpaasch@apple.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH v3 net-next 00/10] Add support for DCB feature in hns3 driver
From: David Miller @ 2017-09-28 17:35 UTC (permalink / raw)
To: linyunsheng
Cc: huangdaode, xuwei5, liguozhu, Yisen.Zhuang, gabriele.paoloni,
john.garry, linuxarm, salil.mehta, lipeng321, netdev,
linux-kernel
In-Reply-To: <1506476732-128130-1-git-send-email-linyunsheng@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
Date: Wed, 27 Sep 2017 09:45:22 +0800
> The patchset contains some enhancement related to DCB before
> adding support for DCB feature.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next RFC 0/9] net: dsa: PTP timestamping for mv88e6xxx
From: Andrew Lunn @ 2017-09-28 17:36 UTC (permalink / raw)
To: Brandon Streiff
Cc: netdev, linux-kernel, David S. Miller, Florian Fainelli,
Vivien Didelot, Richard Cochran, Erik Hons
In-Reply-To: <1506612341-18061-1-git-send-email-brandon.streiff@ni.com>
> - Patch #3: The GPIO config support is handled in a very simple manner.
> I suspect a longer term goal would be to use pinctrl here.
I assume ptp already has the core code to use pinctrl and Linux
standard GPIOs? What does the device tree binding look like? How do
you specify the GPIOs to use?
What we want to avoid is defining an ABI now, otherwise it is going to
be hard to swap to pinctrl later.
> - Patch #6: the dsa_switch pointer and port index is plumbed from
> dsa_device_ops::rcv so that we can call the correct port_rxtstamp
> method. This involved instrumenting all of the *_tag_rcv functions in
> a way that's kind of a kludge and that I'm not terribly happy with.
Yes, this is ugly. I will see if i can find a better way to do
this.
Andrew
^ permalink raw reply
* Re: [PATCH net-next RFC 6/9] net: dsa: forward timestamping callbacks to switch drivers
From: Florian Fainelli @ 2017-09-28 17:40 UTC (permalink / raw)
To: Brandon Streiff, netdev
Cc: linux-kernel, David S. Miller, Andrew Lunn, Vivien Didelot,
Richard Cochran, Erik Hons
In-Reply-To: <1506612341-18061-7-git-send-email-brandon.streiff@ni.com>
On 09/28/2017 08:25 AM, Brandon Streiff wrote:
> Forward the rx/tx timestamp machinery from the dsa infrastructure to the
> switch driver.
>
> On the rx side, defer delivery of skbs until we have an rx timestamp.
> This mimicks the behavior of skb_defer_rx_timestamp. The implementation
> does have to thread through the tagging protocol handlers because
> it is where that we know which switch and port the skb goes to.
>
> On the tx side, identify PTP packets, clone them, and pass them to the
> underlying switch driver before we transmit. This mimicks the behavior
> of skb_tx_timestamp.
>
> Signed-off-by: Brandon Streiff <brandon.streiff@ni.com>
> ---
> include/net/dsa.h | 13 +++++++++++--
> net/dsa/dsa.c | 39 ++++++++++++++++++++++++++++++++++++++-
> net/dsa/slave.c | 25 +++++++++++++++++++++++++
> net/dsa/tag_brcm.c | 6 +++++-
> net/dsa/tag_dsa.c | 6 +++++-
> net/dsa/tag_edsa.c | 6 +++++-
> net/dsa/tag_ksz.c | 6 +++++-
> net/dsa/tag_lan9303.c | 6 +++++-
> net/dsa/tag_mtk.c | 6 +++++-
> net/dsa/tag_qca.c | 6 +++++-
> net/dsa/tag_trailer.c | 6 +++++-
> 11 files changed, 114 insertions(+), 11 deletions(-)
>
> diff --git a/include/net/dsa.h b/include/net/dsa.h
> index 1163af1..4daf7f7 100644
> --- a/include/net/dsa.h
> +++ b/include/net/dsa.h
> @@ -101,11 +101,14 @@ struct dsa_platform_data {
> };
>
> struct packet_type;
> +struct dsa_switch;
>
> struct dsa_device_ops {
> struct sk_buff *(*xmit)(struct sk_buff *skb, struct net_device *dev);
> struct sk_buff *(*rcv)(struct sk_buff *skb, struct net_device *dev,
> - struct packet_type *pt);
> + struct packet_type *pt,
> + struct dsa_switch **src_dev,
> + int *src_port);
> int (*flow_dissect)(const struct sk_buff *skb, __be16 *proto,
> int *offset);
> };
> @@ -134,7 +137,9 @@ struct dsa_switch_tree {
> /* Copy of tag_ops->rcv for faster access in hot path */
> struct sk_buff * (*rcv)(struct sk_buff *skb,
> struct net_device *dev,
> - struct packet_type *pt);
> + struct packet_type *pt,
> + struct dsa_switch **src_dev,
> + int *src_port);
>
> /*
> * The switch port to which the CPU is attached.
> @@ -449,6 +454,10 @@ struct dsa_switch_ops {
> struct ifreq *ifr);
> int (*port_hwtstamp_set)(struct dsa_switch *ds, int port,
> struct ifreq *ifr);
> + void (*port_txtstamp)(struct dsa_switch *ds, int port,
> + struct sk_buff *clone, unsigned int type);
> + bool (*port_rxtstamp)(struct dsa_switch *ds, int port,
> + struct sk_buff *skb, unsigned int type);
> };
>
> struct dsa_switch_driver {
> diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
> index 81c852e..42e7286 100644
> --- a/net/dsa/dsa.c
> +++ b/net/dsa/dsa.c
> @@ -22,6 +22,7 @@
> #include <linux/netdevice.h>
> #include <linux/sysfs.h>
> #include <linux/phy_fixed.h>
> +#include <linux/ptp_classify.h>
> #include <linux/gpio/consumer.h>
> #include <linux/etherdevice.h>
>
> @@ -157,6 +158,37 @@ struct net_device *dsa_dev_to_net_device(struct device *dev)
> }
> EXPORT_SYMBOL_GPL(dsa_dev_to_net_device);
>
> +/* Determine if we should defer delivery of skb until we have a rx timestamp.
> + *
> + * Called from dsa_switch_rcv. For now, this will only work if tagging is
> + * enabled on the switch. Normally the MAC driver would retrieve the hardware
> + * timestamp when it reads the packet out of the hardware. However in a DSA
> + * switch, the DSA driver owning the interface to which the packet is
> + * delivered is never notified unless we do so here.
> + */
> +static bool dsa_skb_defer_rx_timestamp(struct dsa_switch *ds, int port,
> + struct sk_buff *skb)
You should not need the port information here because it's already
implied from skb->dev which points to the DSA slave network device, see
below.
> +{
> + unsigned int type;
> +
> + if (skb_headroom(skb) < ETH_HLEN)
> + return false;
Are you positive this is necessary? Because we called dst->rcv() we have
called eth_type_trans() which already made sure about that
> +
> + __skb_push(skb, ETH_HLEN);
> +
> + type = ptp_classify_raw(skb);
> +
> + __skb_pull(skb, ETH_HLEN);
> +
> + if (type == PTP_CLASS_NONE)
> + return false;
> +
> + if (likely(ds->ops->port_rxtstamp))
> + return ds->ops->port_rxtstamp(ds, port, skb, type);
> +
> + return false;
> +}
Can we also have a fast-path bypass in case time stamping is not
supported by the switch so we don't have to even try to classify this
packet only to realize we don't have a port_rxtsamp() operation later?
You can either gate this with a compile-time option, or use e.g: a
static key or something like an early test?
> +
> static int dsa_switch_rcv(struct sk_buff *skb, struct net_device *dev,
> struct packet_type *pt, struct net_device *unused)
> {
> @@ -164,6 +196,8 @@ static int dsa_switch_rcv(struct sk_buff *skb, struct net_device *dev,
> struct sk_buff *nskb = NULL;
> struct pcpu_sw_netstats *s;
> struct dsa_slave_priv *p;
> + struct dsa_switch *ds = NULL;
> + int source_port;
>
> if (unlikely(dst == NULL)) {
> kfree_skb(skb);
> @@ -174,7 +208,7 @@ static int dsa_switch_rcv(struct sk_buff *skb, struct net_device *dev,
> if (!skb)
> return 0;
>
> - nskb = dst->rcv(skb, dev, pt);
> + nskb = dst->rcv(skb, dev, pt, &ds, &source_port);
I don't think this is necessary, what dst->rcv() does is actually
properly assign skb->dev to the correct dsa slave network device, which
has the information about the port number already in its private context.
> if (!nskb) {
> kfree_skb(skb);
> return 0;
> @@ -192,6 +226,9 @@ static int dsa_switch_rcv(struct sk_buff *skb, struct net_device *dev,
> s->rx_bytes += skb->len;
> u64_stats_update_end(&s->syncp);
>
> + if (dsa_skb_defer_rx_timestamp(ds, source_port, skb))
> + return 0;
Can we just propagate an integer return value from
dsa_skb_defer_rx_timestamp()?
> +
> netif_receive_skb(skb);
>
> return 0;
> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
> index 2cf6a83..a278335 100644
> --- a/net/dsa/slave.c
> +++ b/net/dsa/slave.c
> @@ -22,6 +22,7 @@
> #include <net/tc_act/tc_mirred.h>
> #include <linux/if_bridge.h>
> #include <linux/netpoll.h>
> +#include <linux/ptp_classify.h>
>
> #include "dsa_priv.h"
>
> @@ -407,6 +408,25 @@ static inline netdev_tx_t dsa_slave_netpoll_send_skb(struct net_device *dev,
> return NETDEV_TX_OK;
> }
>
> +static void dsa_skb_tx_timestamp(struct dsa_slave_priv *p,
> + struct sk_buff *skb)
> +{
> + struct dsa_switch *ds = p->dp->ds;
> + struct sk_buff *clone;
> + unsigned int type;
> +
> + type = ptp_classify_raw(skb);
> + if (type == PTP_CLASS_NONE)
> + return;
If we don't have a port_txtstamp option, is there even value in
classifying this packet?
--
Florian
^ permalink raw reply
* Re: [PATCH net-next RFC 3/9] net: dsa: mv88e6xxx: add support for GPIO configuration
From: Florian Fainelli @ 2017-09-28 17:45 UTC (permalink / raw)
To: Brandon Streiff, netdev
Cc: linux-kernel, David S. Miller, Andrew Lunn, Vivien Didelot,
Richard Cochran, Erik Hons
In-Reply-To: <1506612341-18061-4-git-send-email-brandon.streiff@ni.com>
On 09/28/2017 08:25 AM, Brandon Streiff wrote:
> The Scratch/Misc register is a windowed interface that provides access
> to the GPIO configuration. Provide a new method for configuration of
> GPIO functions.
>
> Signed-off-by: Brandon Streiff <brandon.streiff@ni.com>
> ---
> +/* Offset 0x1A: Scratch and Misc. Register */
> +static int mv88e6xxx_g2_scratch_reg_read(struct mv88e6xxx_chip *chip,
> + int reg, u8 *data)
> +{
> + int err;
> + u16 value;
> +
> + err = mv88e6xxx_g2_write(chip, MV88E6XXX_G2_SCRATCH_MISC_MISC,
> + reg << 8);
> + if (err)
> + return err;
> +
> + err = mv88e6xxx_g2_read(chip, MV88E6XXX_G2_SCRATCH_MISC_MISC, &value);
> + if (err)
> + return err;
> +
> + *data = (value & MV88E6XXX_G2_SCRATCH_MISC_DATA_MASK);
> +
> + return 0;
> +}
With the write and read acquiring and then releasing the lock
immediately, is no there room for this sequence to be interrupted in the
middle and end-up returning inconsistent reads?
> +
> +static int mv88e6xxx_g2_scratch_reg_write(struct mv88e6xxx_chip *chip,
> + int reg, u8 data)
> +{
> + u16 value = (reg << 8) | data;
> +
> + return mv88e6xxx_g2_update(chip, MV88E6XXX_G2_SCRATCH_MISC_MISC, value);
> +}
> +
> +/* Configures the specified pin for the specified function. This function
> + * does not unset other pins configured for the same function. If multiple
> + * pins are configured for the same function, the lower-index pin gets
> + * that function and the higher-index pin goes back to being GPIO.
> + */
> +int mv88e6xxx_g2_set_gpio_config(struct mv88e6xxx_chip *chip, int pin,
> + int func, int dir)
> +{
> + int mode_reg = MV88E6XXX_G2_SCRATCH_GPIO_MODE(pin);
> + int dir_reg = MV88E6XXX_G2_SCRATCH_GPIO_DIR(pin);
> + int err;
> + u8 val;
> +
> + if (pin < 0 || pin >= mv88e6xxx_num_gpio(chip))
> + return -ERANGE;
> +
> + /* Set function first */
> + err = mv88e6xxx_g2_scratch_reg_read(chip, mode_reg, &val);
> + if (err)
> + return err;
> +
> + /* Zero bits in the field for this GPIO and OR in new config */
> + val &= ~MV88E6XXX_G2_SCRATCH_GPIO_MODE_MASK(pin);
> + val |= (func << MV88E6XXX_G2_SCRATCH_GPIO_MODE_OFFSET(pin));
> +
> + err = mv88e6xxx_g2_scratch_reg_write(chip, mode_reg, val);
> + if (err)
> + return err;
> +
> + /* Set direction */
> + err = mv88e6xxx_g2_scratch_reg_read(chip, dir_reg, &val);
> + if (err)
> + return err;
> +
> + /* Zero bits in the field for this GPIO and OR in new config */
> + val &= ~MV88E6XXX_G2_SCRATCH_GPIO_DIR_MASK(pin);
> + val |= (dir << MV88E6XXX_G2_SCRATCH_GPIO_DIR_OFFSET(pin));
> +
> + return mv88e6xxx_g2_scratch_reg_write(chip, dir_reg, val);
> +}
Would there be any value in implementing a proper gpiochip structure
here such that other pieces of SW can see this GPIO controller as a
provider and you can reference it from e.g: Device Tree using GPIO
descriptors?
--
Florian
^ permalink raw reply
* Re: [PATCH v5 1/4] ipv4: Namespaceify tcp_fastopen knob
From: David Miller @ 2017-09-28 17:47 UTC (permalink / raw)
To: yanhaishuang; +Cc: kuznet, edumazet, weiwan, lucab, netdev, linux-kernel
In-Reply-To: <1506483343-11544-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date: Wed, 27 Sep 2017 11:35:40 +0800
> Different namespace application might require enable TCP Fast Open
> feature independently of the host.
>
> This patch series continues making more of the TCP Fast Open related
> sysctl knobs be per net-namespace.
>
> Reported-by: Luca BRUNO <lucab@debian.org>
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Applied.
^ permalink raw reply
* Re: [PATCH v5 2/4] ipv4: Remove the 'publish' logic in tcp_fastopen_init_key_once
From: David Miller @ 2017-09-28 17:47 UTC (permalink / raw)
To: yanhaishuang; +Cc: kuznet, edumazet, weiwan, lucab, netdev, linux-kernel
In-Reply-To: <1506483343-11544-2-git-send-email-yanhaishuang@cmss.chinamobile.com>
From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date: Wed, 27 Sep 2017 11:35:41 +0800
> The 'publish' logic is not necessary after commit dfea2aa65424 ("tcp:
> Do not call tcp_fastopen_reset_cipher from interrupt context"), because
> in tcp_fastopen_cookie_gen，it wouldn't call tcp_fastopen_init_key_once.
>
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Applied.
^ permalink raw reply
* Re: [PATCH v5 3/4] ipv4: Namespaceify tcp_fastopen_key knob
From: David Miller @ 2017-09-28 17:47 UTC (permalink / raw)
To: yanhaishuang; +Cc: kuznet, edumazet, weiwan, lucab, netdev, linux-kernel
In-Reply-To: <1506483343-11544-3-git-send-email-yanhaishuang@cmss.chinamobile.com>
From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date: Wed, 27 Sep 2017 11:35:42 +0800
> Different namespace application might require different tcp_fastopen_key
> independently of the host.
>
> David Miller pointed out there is a leak without releasing the context
> of tcp_fastopen_key during netns teardown. So add the release action in
> exit_batch path.
>
> Tested:
> 1. Container namespace:
> # cat /proc/sys/net/ipv4/tcp_fastopen_key:
> 2817fff2-f803cf97-eadfd1f3-78c0992b
>
> cookie key in tcp syn packets:
> Fast Open Cookie
> Kind: TCP Fast Open Cookie (34)
> Length: 10
> Fast Open Cookie: 1e5dd82a8c492ca9
>
> 2. Host:
> # cat /proc/sys/net/ipv4/tcp_fastopen_key:
> 107d7c5f-68eb2ac7-02fb06e6-ed341702
>
> cookie key in tcp syn packets:
> Fast Open Cookie
> Kind: TCP Fast Open Cookie (34)
> Length: 10
> Fast Open Cookie: e213c02bf0afbc8a
>
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Applied.
^ permalink raw reply
* Re: [PATCH v5 4/4] ipv4: Namespaceify tcp_fastopen_blackhole_timeout knob
From: David Miller @ 2017-09-28 17:48 UTC (permalink / raw)
To: yanhaishuang; +Cc: kuznet, edumazet, weiwan, lucab, netdev, linux-kernel
In-Reply-To: <1506483343-11544-4-git-send-email-yanhaishuang@cmss.chinamobile.com>
From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date: Wed, 27 Sep 2017 11:35:43 +0800
> Different namespace application might require different time period in
> second to disable Fastopen on active TCP sockets.
>
> Tested:
> Simulate following similar situation that the server's data gets dropped
> after 3WHS.
> C ---- syn-data ---> S
> C <--- syn/ack ----- S
> C ---- ack --------> S
> S (accept & write)
> C? X <- data ------ S
> [retry and timeout]
>
> And then print netstat of TCPFastOpenBlackhole, the counter increased as
> expected when the firewall blackhole issue is detected and active TFO is
> disabled.
> # cat /proc/net/netstat | awk '{print $91}'
> TCPFastOpenBlackhole
> 1
>
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net-ipv6: remove unused IP6_ECN_clear() function
From: David Miller @ 2017-09-28 17:48 UTC (permalink / raw)
To: zenczykowski; +Cc: maze, netdev
In-Reply-To: <20170927033722.89146-1-zenczykowski@gmail.com>
From: Maciej Żenczykowski <zenczykowski@gmail.com>
Date: Tue, 26 Sep 2017 20:37:22 -0700
> From: Maciej Żenczykowski <maze@google.com>
>
> This function is unused, and furthermore it is buggy since it suffers
> from the same issue that requires IP6_ECN_set_ce() to take a pointer
> to the skb so that it may (in case of CHECKSUM_COMPLETE) update skb->csum
>
> Instead of fixing it, let's just outright remove it.
>
> Tested: builds, and 'git grep IP6_ECN_clear' comes up empty
>
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
Applied to net-next.
^ permalink raw reply
* Re: [patch net-next 1/7] skbuff: Add the offload_mr_fwd_mark field
From: Andrew Lunn @ 2017-09-28 17:49 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, yotamg, idosch, mlxsw, nikolay, dsa, edumazet,
willemb, johannes.berg, dcaratti, pabeni, daniel, f.fainelli, fw,
gfree.wind
In-Reply-To: <20170928173415.15551-2-jiri@resnulli.us>
On Thu, Sep 28, 2017 at 07:34:09PM +0200, Jiri Pirko wrote:
> From: Yotam Gigi <yotamg@mellanox.com>
>
> Similarly to the offload_fwd_mark field, the offload_mr_fwd_mark field is
> used to allow partial offloading of MFC multicast routes.
> The reason why the already existing "offload_fwd_mark" bit cannot be used
> is that a switchdev driver would want to make the distinction between a
> packet that has already gone through L2 forwarding but did not go through
> multicast forwarding, and a packet that has already gone through both L2
> and multicast forwarding.
Hi Jiri
So we are talking about l2 vs l3. So why not call this
offload_l3_fwd_mark?
Is there anything really specific to multicast here?
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH net-next RFC 0/9] net: dsa: PTP timestamping for mv88e6xxx
From: Florian Fainelli @ 2017-09-28 17:51 UTC (permalink / raw)
To: Andrew Lunn, Brandon Streiff
Cc: netdev, linux-kernel, David S. Miller, Vivien Didelot,
Richard Cochran, Erik Hons
In-Reply-To: <20170928173629.GD14940@lunn.ch>
On 09/28/2017 10:36 AM, Andrew Lunn wrote:
>> - Patch #3: The GPIO config support is handled in a very simple manner.
>> I suspect a longer term goal would be to use pinctrl here.
>
> I assume ptp already has the core code to use pinctrl and Linux
> standard GPIOs? What does the device tree binding look like? How do
> you specify the GPIOs to use?
>
> What we want to avoid is defining an ABI now, otherwise it is going to
> be hard to swap to pinctrl later.
>
>> - Patch #6: the dsa_switch pointer and port index is plumbed from
>> dsa_device_ops::rcv so that we can call the correct port_rxtstamp
>> method. This involved instrumenting all of the *_tag_rcv functions in
>> a way that's kind of a kludge and that I'm not terribly happy with.
>
> Yes, this is ugly. I will see if i can find a better way to do
> this.
See my reply in patch 6, I may be missing something, but once
dst->rdcv() has been called, skb->dev points to the slave network device
which already contains the switch port and switch information in
dsa_slave_priv, so that should lift the need for asking the individual
taggers' rcv() callback to tell us about it.
--
Florian
^ permalink raw reply
* Re: [patch net-next 3/7] ipv4: ipmr: Don't forward packets already forwarded by hardware
From: Florian Fainelli @ 2017-09-28 17:56 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, yotamg, idosch, mlxsw, nikolay, andrew, dsa, edumazet,
willemb, johannes.berg, dcaratti, pabeni, daniel, fw, gfree.wind
In-Reply-To: <20170928173415.15551-4-jiri@resnulli.us>
On 09/28/2017 10:34 AM, Jiri Pirko wrote:
> From: Yotam Gigi <yotamg@mellanox.com>
>
> Change the ipmr module to not forward packets if:
> - The packet is marked with the offload_mr_fwd_mark, and
> - Both input interface and output interface share the same parent ID.
>
> This way, a packet can go through partial multicast forwarding in the
> hardware, where it will be forwarded only to the devices that share the
> same parent ID (AKA, reside inside the same hardware). The kernel will
> forward the packet to all other interfaces.
>
> To do this, add the ipmr_offload_forward helper, which per skb, ingress VIF
> and egress VIF, returns whether the forwarding was offloaded to hardware.
> The ipmr_queue_xmit frees the skb and does not forward it if the result is
> a true value.
>
> All the forwarding path code compiles out when the CONFIG_NET_SWITCHDEV is
> not set.
>
> Signed-off-by: Yotam Gigi <yotamg@mellanox.com>
> Reviewed-by: Ido Schimmel <idosch@mellanox.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> ---
> net/ipv4/ipmr.c | 37 ++++++++++++++++++++++++++++++++-----
> 1 file changed, 32 insertions(+), 5 deletions(-)
>
> diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
> index 4566c54..deba569 100644
> --- a/net/ipv4/ipmr.c
> +++ b/net/ipv4/ipmr.c
> @@ -1857,10 +1857,33 @@ static inline int ipmr_forward_finish(struct net *net, struct sock *sk,
> return dst_output(net, sk, skb);
> }
>
> +#ifdef CONFIG_NET_SWITCHDEV
> +static bool ipmr_forward_offloaded(struct sk_buff *skb, struct mr_table *mrt,
> + int in_vifi, int out_vifi)
> +{
> + struct vif_device *out_vif = &mrt->vif_table[out_vifi];
> + struct vif_device *in_vif = &mrt->vif_table[in_vifi];
Nit: in_vifi and out_vifi may be better named as in_vif_idx and
out_vif_idx, oh well you are just replicating the existing naming
conventions used down below, never mind then.
--
Florian
^ permalink raw reply
* Re: [PATCH net-next RFC 3/9] net: dsa: mv88e6xxx: add support for GPIO configuration
From: Andrew Lunn @ 2017-09-28 18:01 UTC (permalink / raw)
To: Florian Fainelli
Cc: Brandon Streiff, netdev, linux-kernel, David S. Miller,
Vivien Didelot, Richard Cochran, Erik Hons
In-Reply-To: <659c4254-d0b7-52dc-dd9b-3921cd2f20c0@gmail.com>
On Thu, Sep 28, 2017 at 10:45:03AM -0700, Florian Fainelli wrote:
> On 09/28/2017 08:25 AM, Brandon Streiff wrote:
> > The Scratch/Misc register is a windowed interface that provides access
> > to the GPIO configuration. Provide a new method for configuration of
> > GPIO functions.
> >
> > Signed-off-by: Brandon Streiff <brandon.streiff@ni.com>
> > ---
>
> > +/* Offset 0x1A: Scratch and Misc. Register */
> > +static int mv88e6xxx_g2_scratch_reg_read(struct mv88e6xxx_chip *chip,
> > + int reg, u8 *data)
> > +{
> > + int err;
> > + u16 value;
> > +
> > + err = mv88e6xxx_g2_write(chip, MV88E6XXX_G2_SCRATCH_MISC_MISC,
> > + reg << 8);
> > + if (err)
> > + return err;
> > +
> > + err = mv88e6xxx_g2_read(chip, MV88E6XXX_G2_SCRATCH_MISC_MISC, &value);
> > + if (err)
> > + return err;
> > +
> > + *data = (value & MV88E6XXX_G2_SCRATCH_MISC_DATA_MASK);
> > +
> > + return 0;
> > +}
>
> With the write and read acquiring and then releasing the lock
> immediately, is no there room for this sequence to be interrupted in the
> middle and end-up returning inconsistent reads?
Hi Florian
The general pattern in this code is that the lock chip->reg_lock is
taken at a higher level. That protects against other threads. The
driver tends to do that at the highest levels, at the entry points
into the driver. I've not yet checked this code follows the pattern
yet. However, we have a check in the low level to ensure the lock has
been taken. So it seems likely the lock is held.
> Would there be any value in implementing a proper gpiochip structure
> here such that other pieces of SW can see this GPIO controller as a
> provider and you can reference it from e.g: Device Tree using GPIO
> descriptors?
That would be my preference as well, or maybe a pinctrl driver.
Andrew
^ permalink raw reply
* [PATCH v2] lib: fix multiple strlcpy definition
From: Baruch Siach @ 2017-09-28 18:02 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Phil Sutter, Baruch Siach
Some C libraries, like uClibc and musl, provide BSD compatible
strlcpy(). Add check_strlcpy() to configure, and avoid defining strlcpy
and strlcat when the C library provides them.
This fixes the following static link error with uClibc-ng:
.../sysroot/usr/lib/libc.a(strlcpy.os): In function `strlcpy':
strlcpy.c:(.text+0x0): multiple definition of `strlcpy'
../lib/libutil.a(utils.o):utils.c:(.text+0x1ddc): first defined here
collect2: error: ld returned 1 exit status
Acked-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
v2: Fix the order of strlcpy parameters
---
configure | 24 ++++++++++++++++++++++++
lib/Makefile | 4 ++++
lib/utils.c | 2 ++
3 files changed, 30 insertions(+)
diff --git a/configure b/configure
index 7be8fb113cc9..e0982f34a992 100755
--- a/configure
+++ b/configure
@@ -326,6 +326,27 @@ EOF
rm -f $TMPDIR/dbtest.c $TMPDIR/dbtest
}
+check_strlcpy()
+{
+ cat >$TMPDIR/strtest.c <<EOF
+#include <string.h>
+int main(int argc, char **argv) {
+ char dst[10];
+ strlcpy(dst, "test", sizeof(dst));
+ return 0;
+}
+EOF
+ $CC -I$INCLUDE -o $TMPDIR/strtest $TMPDIR/strtest.c >/dev/null 2>&1
+ if [ $? -eq 0 ]
+ then
+ echo "no"
+ else
+ echo "NEED_STRLCPY:=y" >>$CONFIG
+ echo "yes"
+ fi
+ rm -f $TMPDIR/strtest.c $TMPDIR/strtest
+}
+
quiet_config()
{
cat <<EOF
@@ -397,6 +418,9 @@ check_mnl
echo -n "Berkeley DB: "
check_berkeley_db
+echo -n "need for strlcpy: "
+check_strlcpy
+
echo
echo -n "docs:"
check_docs
diff --git a/lib/Makefile b/lib/Makefile
index 0fbdf4c31f50..132ad00c3335 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -1,5 +1,9 @@
include ../config.mk
+ifeq ($(NEED_STRLCPY),y)
+ CFLAGS += -DNEED_STRLCPY
+endif
+
CFLAGS += -fPIC
UTILOBJ = utils.o rt_names.o ll_types.o ll_proto.o ll_addr.o \
diff --git a/lib/utils.c b/lib/utils.c
index bbd3cbc46a0e..240e7426a810 100644
--- a/lib/utils.c
+++ b/lib/utils.c
@@ -1231,6 +1231,7 @@ int get_real_family(int rtm_type, int rtm_family)
return rtm_family;
}
+#ifdef NEED_STRLCPY
size_t strlcpy(char *dst, const char *src, size_t size)
{
size_t srclen = strlen(src);
@@ -1253,3 +1254,4 @@ size_t strlcat(char *dst, const char *src, size_t size)
return dlen + strlcpy(dst + dlen, src, size - dlen);
}
+#endif
--
2.14.2
^ permalink raw reply related
* Re: [PATCH] Add a driver for Renesas uPD60620 and uPD60620A PHYs
From: Bernd Edlinger @ 2017-09-28 18:12 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev@vger.kernel.org, Florian Fainelli
In-Reply-To: <20170922175918.GD3470@lunn.ch>
On 09/22/17 19:59, Andrew Lunn wrote:
> On Fri, Sep 22, 2017 at 05:08:45PM +0000, Bernd Edlinger wrote:
>>
>> +config RENESAS_PHY
>> + tristate "Driver for Renesas PHYs"
>> + ---help---
>> + Supports the uPD60620 and uPD60620A PHYs.
>> +
>
> Hi Bernd
>
> Please call this "Reneseas PHYs" and place in it alphabetical order.
>
Done.
>> +
>> +/* Extended Registers and values */
>> +/* PHY Special Control/Status */
>> +#define PHY_PHYSCR 0x1F /* PHY.31 */
>> +#define PHY_PHYSCR_10MB 0x0004 /* PHY speed = 10mb */
>> +#define PHY_PHYSCR_100MB 0x0008 /* PHY speed = 100mb */
>> +#define PHY_PHYSCR_DUPLEX 0x0010 /* PHY Duplex */
>> +#define PHY_PHYSCR_RSVD5 0x0020 /* Reserved Bit 5 */
>> +#define PHY_PHYSCR_MIIMOD 0x0040 /* Enable 4B5B MII mode */
>
> Are any of these comments actually useful. It seems like the defines
> are pretty obvious.
>
>> +#define PHY_PHYSCR_RSVD7 0x0080 /* Reserved Bit 7 */
>> +#define PHY_PHYSCR_RSVD8 0x0100 /* Reserved Bit 8 */
>> +#define PHY_PHYSCR_RSVD9 0x0200 /* Reserved Bit 9 */
>> +#define PHY_PHYSCR_RSVD10 0x0400 /* Reserved Bit 10 */
>> +#define PHY_PHYSCR_RSVD11 0x0800 /* Reserved Bit 11 */
>> +#define PHY_PHYSCR_ANDONE 0x1000 /* Auto negotiation done */
>> +#define PHY_PHYSCR_RSVD13 0x2000 /* Reserved Bit 13 */
>> +#define PHY_PHYSCR_RSVD14 0x4000 /* Reserved Bit 14 */
>> +#define PHY_PHYSCR_RSVD15 0x8000 /* Reserved Bit 15 */
>
> It looks like the only register you use is SCR and SPM. Maybe delete
> all the rest? Or do you plan to add more features making use of these
> registers?
>
No, I removed all unused defines for now.
>> + phydev->link = 0;
>> + phydev->lp_advertising = 0;
>> + phydev->pause = 0;
>> + phydev->asym_pause = 0;
>> +
>> + if (phy_state & BMSR_ANEGCOMPLETE) {
>
> It is worth comparing this against genphy_read_status() which is the
> reference implementation. You would normally check if auto negotiation
> is enabled, not if it has completed. If it is enabled you read the
> current negotiated state, even if it is not completed.
>
Do you suggest that there are cases where auto negotiation does not
reach completion, and still provides a usable link status?
I have tried to connect to link partners with fixed configuration
but even then the auto negotiation always competes normally.
>> + phy_state = phy_read(phydev, PHY_PHYSCR);
>> + if (phy_state < 0)
>> + return phy_state;
>> +
>> + if (phy_state & (PHY_PHYSCR_10MB | PHY_PHYSCR_100MB)) {
>> + phydev->link = 1;
>> + phydev->speed = SPEED_10;
>> + phydev->duplex = DUPLEX_HALF;
>> +
>> + if (phy_state & PHY_PHYSCR_100MB)
>> + phydev->speed = SPEED_100;
>> + if (phy_state & PHY_PHYSCR_DUPLEX)
>> + phydev->duplex = DUPLEX_FULL;
>> +
>> + phy_state = phy_read(phydev, MII_LPA);
>> + if (phy_state < 0)
>> + return phy_state;
>> +
>> + phydev->lp_advertising
>> + = mii_lpa_to_ethtool_lpa_t(phy_state);
>> +
>> + if (phydev->duplex == DUPLEX_FULL) {
>> + if (phy_state & LPA_PAUSE_CAP)
>> + phydev->pause = 1;
>> + if (phy_state & LPA_PAUSE_ASYM)
>> + phydev->asym_pause = 1;
>> + }
>> + }
>> + } else if (phy_state & BMSR_LSTATUS) {
>
> The else clause is then for a fixed configuration. Since all you are
> looking at is BMCR, you can probably just cut/paste from
> genphy_read_status().
>
I think I can fold the fixed speed case in the auto negotiation case:
The PHYSCR has always the correct values for fixed settings.
I was initially unsure if I should look at it while autonegotiation is
not complete, but as you pointed out, that is the generally accepted
practice.
Thanks
Bernd.
>From 2e101aed8466b314251972d1eaccfb43cf177078 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger <bernd.edlinger@hotmail.de>
Date: Thu, 21 Sep 2017 15:46:16 +0200
Subject: [PATCH 2/5] Add a driver for Renesas uPD60620 and uPD60620A PHYs.
Signed-off-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
---
drivers/net/phy/Kconfig | 5 +++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/uPD60620.c | 109 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 115 insertions(+)
create mode 100644 drivers/net/phy/uPD60620.c
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index a9d16a3..f67943b 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -366,6 +366,11 @@ config REALTEK_PHY
---help---
Supports the Realtek 821x PHY.
+config RENESAS_PHY
+ tristate "Driver for Renesas PHYs"
+ ---help---
+ Supports the Renesas PHYs uPD60620 and uPD60620A.
+
config ROCKCHIP_PHY
tristate "Driver for Rockchip Ethernet PHYs"
---help---
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 416df92..1404ad3 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_MICROSEMI_PHY) += mscc.o
obj-$(CONFIG_NATIONAL_PHY) += national.o
obj-$(CONFIG_QSEMI_PHY) += qsemi.o
obj-$(CONFIG_REALTEK_PHY) += realtek.o
+obj-$(CONFIG_RENESAS_PHY) += uPD60620.o
obj-$(CONFIG_ROCKCHIP_PHY) += rockchip.o
obj-$(CONFIG_SMSC_PHY) += smsc.o
obj-$(CONFIG_STE10XP) += ste10Xp.o
diff --git a/drivers/net/phy/uPD60620.c b/drivers/net/phy/uPD60620.c
new file mode 100644
index 0000000..96b3347
--- /dev/null
+++ b/drivers/net/phy/uPD60620.c
@@ -0,0 +1,109 @@
+/*
+ * Driver for the Renesas PHY uPD60620.
+ *
+ * Copyright (C) 2015 Softing Industrial Automation GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/phy.h>
+
+#define UPD60620_PHY_ID 0xb8242824
+
+/* Extended Registers and values */
+/* PHY Special Control/Status */
+#define PHY_PHYSCR 0x1F /* PHY.31 */
+#define PHY_PHYSCR_10MB 0x0004 /* PHY speed = 10mb */
+#define PHY_PHYSCR_100MB 0x0008 /* PHY speed = 100mb */
+#define PHY_PHYSCR_DUPLEX 0x0010 /* PHY Duplex */
+
+/* PHY Special Modes */
+#define PHY_SPM 0x12 /* PHY.18 */
+
+/* Init PHY */
+
+static int upd60620_config_init(struct phy_device *phydev)
+{
+ /* Enable support for passive HUBs (could be a strap option) */
+ /* PHYMODE: All speeds, HD in parallel detect */
+ return phy_write(phydev, PHY_SPM, 0x0180 | phydev->mdio.addr);
+}
+
+/* Get PHY status from common registers */
+
+static int upd60620_read_status(struct phy_device *phydev)
+{
+ int phy_state;
+
+ /* Read negotiated state */
+ phy_state = phy_read(phydev, MII_BMSR);
+ if (phy_state < 0)
+ return phy_state;
+
+ phydev->link = 0;
+ phydev->lp_advertising = 0;
+ phydev->pause = 0;
+ phydev->asym_pause = 0;
+
+ if (phy_state & (BMSR_ANEGCOMPLETE | BMSR_LSTATUS)) {
+ phy_state = phy_read(phydev, PHY_PHYSCR);
+ if (phy_state < 0)
+ return phy_state;
+
+ if (phy_state & (PHY_PHYSCR_10MB | PHY_PHYSCR_100MB)) {
+ phydev->link = 1;
+ phydev->speed = SPEED_10;
+ phydev->duplex = DUPLEX_HALF;
+
+ if (phy_state & PHY_PHYSCR_100MB)
+ phydev->speed = SPEED_100;
+ if (phy_state & PHY_PHYSCR_DUPLEX)
+ phydev->duplex = DUPLEX_FULL;
+
+ phy_state = phy_read(phydev, MII_LPA);
+ if (phy_state < 0)
+ return phy_state;
+
+ phydev->lp_advertising
+ = mii_lpa_to_ethtool_lpa_t(phy_state);
+
+ if (phydev->duplex == DUPLEX_FULL) {
+ if (phy_state & LPA_PAUSE_CAP)
+ phydev->pause = 1;
+ if (phy_state & LPA_PAUSE_ASYM)
+ phydev->asym_pause = 1;
+ }
+ }
+ }
+ return 0;
+}
+
+MODULE_DESCRIPTION("Renesas uPD60620 PHY driver");
+MODULE_AUTHOR("Bernd Edlinger <bernd.edlinger@hotmail.de>");
+MODULE_LICENSE("GPL");
+
+static struct phy_driver upd60620_driver[1] = { {
+ .phy_id = UPD60620_PHY_ID,
+ .phy_id_mask = 0xfffffffe,
+ .name = "Renesas uPD60620",
+ .features = PHY_BASIC_FEATURES,
+ .flags = 0,
+ .config_init = upd60620_config_init,
+ .config_aneg = genphy_config_aneg,
+ .read_status = upd60620_read_status,
+} };
+
+module_phy_driver(upd60620_driver);
+
+static struct mdio_device_id __maybe_unused upd60620_tbl[] = {
+ { UPD60620_PHY_ID, 0xfffffffe },
+ { }
+};
+
+MODULE_DEVICE_TABLE(mdio, upd60620_tbl);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next] Revert "net: dsa: bcm_sf2: Defer port enabling to calling port_enable"
From: Florian Fainelli @ 2017-09-28 18:19 UTC (permalink / raw)
To: netdev; +Cc: Florian Fainelli, Andrew Lunn, Vivien Didelot, open list
This reverts commit e85ec74ace29 ("net: dsa: bcm_sf2: Defer port
enabling to calling port_enable") because this now makes an unbind
followed by a bind to fail connecting to the ingrated PHY.
What this patch missed is that we need the PHY to be enabled with
bcm_sf2_gphy_enable_set() before probing it on the MDIO bus. This is
correctly done in the ops->setup() function, but by the time
ops->port_enable() runs, this is too late. Upon unbind we would power
down the PHY, and so when we would bind again, the PHY would be left
powered off.
Fixes: e85ec74ace29 ("net: dsa: bcm_sf2: Defer port enabling to calling port_enable")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/bcm_sf2.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 898d5642b516..7aecc98d0a18 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -754,11 +754,14 @@ static int bcm_sf2_sw_setup(struct dsa_switch *ds)
struct bcm_sf2_priv *priv = bcm_sf2_to_priv(ds);
unsigned int port;
- /* Disable unused ports and configure IMP port */
+ /* Enable all valid ports and disable those unused */
for (port = 0; port < priv->hw_params.num_ports; port++) {
- if (dsa_is_cpu_port(ds, port))
+ /* IMP port receives special treatment */
+ if ((1 << port) & ds->enabled_port_mask)
+ bcm_sf2_port_setup(ds, port, NULL);
+ else if (dsa_is_cpu_port(ds, port))
bcm_sf2_imp_setup(ds, port);
- else if (!((1 << port) & ds->enabled_port_mask))
+ else
bcm_sf2_port_disable(ds, port, NULL);
}
--
2.9.3
^ permalink raw reply related
* Re: [PATCH net-next v9] openvswitch: enable NSH support
From: Pravin Shelar @ 2017-09-28 18:28 UTC (permalink / raw)
To: Yang, Yi
Cc: Jiri Benc, netdev@vger.kernel.org, dev@openvswitch.org, e@erig.me,
davem@davemloft.net, Jan Scheurich
In-Reply-To: <20170927013908.GA33716@localhost.localdomain>
On Tue, Sep 26, 2017 at 6:39 PM, Yang, Yi <yi.y.yang@intel.com> wrote:
> On Tue, Sep 26, 2017 at 06:49:14PM +0800, Jiri Benc wrote:
>> On Tue, 26 Sep 2017 12:55:39 +0800, Yang, Yi wrote:
>> > After push_nsh, the packet won't be recirculated to flow pipeline, so
>> > key->eth.type must be set explicitly here, but for pop_nsh, the packet
>> > will be recirculated to flow pipeline, it will be reparsed, so
>> > key->eth.type will be set in packet parse function, we needn't handle it
>> > in pop_nsh.
>>
>> This seems to be a very different approach than what we currently have.
>> Looking at the code, the requirement after "destructive" actions such
>> as pushing or popping headers is to recirculate.
>
> This is optimization proposed by Jan Scheurich, recurculating after push_nsh
> will impact on performance, recurculating after pop_nsh is unavoidable, So
> also cc jan.scheurich@ericsson.com.
>
> Actucally all the keys before push_nsh are still there after push_nsh,
> push_nsh has updated all the nsh keys, so recirculating remains avoidable.
>
We should keep existing model for this patch. Later you can submit
optimization patch with specific use cases and performance
improvement. So that we can evaluate code complexity and benefits.
>>
>> Setting key->eth.type to satisfy conditions in the output path without
>> updating the rest of the key looks very hacky and fragile to me. There
>> might be other conditions and dependencies that are not obvious.
>> I don't think the code was written with such code path in mind.
>>
>> I'd like to hear what Pravin thinks about this.
>>
>> Jiri
^ permalink raw reply
* [PATCH V4] r8152: add Linksys USB3GIGV1 id
From: Grant Grundler @ 2017-09-28 18:35 UTC (permalink / raw)
To: Hayes Wang, Oliver Neukum
Cc: linux-usb, David S . Miller, LKML, netdev, Grant Grundler
This linksys dongle by default comes up in cdc_ether mode.
This patch allows r8152 to claim the device:
Bus 002 Device 002: ID 13b1:0041 Linksys
Signed-off-by: Grant Grundler <grundler@chromium.org>
---
drivers/net/usb/cdc_ether.c | 10 ++++++++++
drivers/net/usb/r8152.c | 2 ++
2 files changed, 12 insertions(+)
V4: use IS_ENABLED() to check CONFIG_USB_RTL8152 is m or y.
(verified by adding #error to the new code and trying to compile
Thanks Doug for the tip!)
Add LINKSYS vendor #define in same order for both drivers.
V3: for backwards compat, add #ifdef CONFIG_USB_RTL8152 around
the cdc_ether blacklist entry so the cdc_ether driver can
still claim the device if r8152 driver isn't configured.
V2: add LINKSYS_VENDOR_ID to cdc_ether blacklist
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 8ab281b478f2..677a85360db1 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -547,6 +547,7 @@ static const struct driver_info wwan_info = {
#define REALTEK_VENDOR_ID 0x0bda
#define SAMSUNG_VENDOR_ID 0x04e8
#define LENOVO_VENDOR_ID 0x17ef
+#define LINKSYS_VENDOR_ID 0x13b1
#define NVIDIA_VENDOR_ID 0x0955
#define HP_VENDOR_ID 0x03f0
#define MICROSOFT_VENDOR_ID 0x045e
@@ -737,6 +738,15 @@ static const struct usb_device_id products[] = {
.driver_info = 0,
},
+#if IS_ENABLED(CONFIG_USB_RTL8152)
+/* Linksys USB3GIGV1 Ethernet Adapter */
+{
+ USB_DEVICE_AND_INTERFACE_INFO(LINKSYS_VENDOR_ID, 0x0041, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+ .driver_info = 0,
+},
+#endif
+
/* ThinkPad USB-C Dock (based on Realtek RTL8153) */
{
USB_DEVICE_AND_INTERFACE_INFO(LENOVO_VENDOR_ID, 0x3062, USB_CLASS_COMM,
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ceb78e2ea4f0..941ece08ba78 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -613,6 +613,7 @@ enum rtl8152_flags {
#define VENDOR_ID_MICROSOFT 0x045e
#define VENDOR_ID_SAMSUNG 0x04e8
#define VENDOR_ID_LENOVO 0x17ef
+#define VENDOR_ID_LINKSYS 0x13b1
#define VENDOR_ID_NVIDIA 0x0955
#define MCU_TYPE_PLA 0x0100
@@ -5316,6 +5317,7 @@ static const struct usb_device_id rtl8152_table[] = {
{REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x7205)},
{REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x720c)},
{REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x7214)},
+ {REALTEK_USB_DEVICE(VENDOR_ID_LINKSYS, 0x0041)},
{REALTEK_USB_DEVICE(VENDOR_ID_NVIDIA, 0x09ff)},
{}
};
--
2.14.2.822.g60be5d43e6-goog
^ permalink raw reply related
* Re: [PATCH RFC 3/5] Add KSZ8795 switch driver
From: Pavel Machek @ 2017-09-28 18:40 UTC (permalink / raw)
To: Tristram.Ha
Cc: andrew, muvarov, nathan.leigh.conrad, vivien.didelot, f.fainelli,
netdev, linux-kernel, Woojung.Huh
In-Reply-To: <93AF473E2DA327428DE3D46B72B1E9FD41124D5A@CHN-SV-EXMX02.mchp-main.com>
[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]
Hi!
On Mon 2017-09-18 20:27:13, Tristram.Ha@microchip.com wrote:
> > > +/**
> > > + * Some counters do not need to be read too often because they are less
> > likely
> > > + * to increase much.
> > > + */
> >
> > What does comment mean? Are you caching statistics, and updating
> > different values at different rates?
> >
>
> There are 34 counters. In normal case using generic bus I/O or PCI to read them
> is very quick, but the switch is mostly accessed using SPI, or even I2C. As the SPI
> access is very slow and cannot run in interrupt context I keep worrying reading
> the MIB counters in a loop for 5 or more ports will prevent other critical hardware
> access from executing soon enough. These accesses can be getting 1588 PTP
> timestamps and opening/closing ports. (RSTP Conformance Test sends test traffic
> to port supposed to be closed/opened after receiving specific RSTP
> BPDU.)
Hmm. Ok, interesting.
I wonder how well this is going to work if userspace actively 'does
something' with the switch.
It seems to me that even if your statistics code is careful not to do
'a lot' of accesses at the same time, userspace can use other parts of
the driver to do the same, and thus cause same unwanted effects...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] ravb: Add optional PHY reset during system resume
From: Geert Uytterhoeven @ 2017-09-28 18:45 UTC (permalink / raw)
To: Florian Fainelli
Cc: Geert Uytterhoeven, David S . Miller, Simon Horman, Magnus Damm,
Sergei Shtylyov, Andrew Lunn, Niklas Söderlund,
netdev@vger.kernel.org, Linux-Renesas, devicetree@vger.kernel.org
In-Reply-To: <406f7aff-e386-31f3-39d3-17523443c265@gmail.com>
Hi Florian,
On Thu, Sep 28, 2017 at 7:22 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 09/28/2017 08:53 AM, Geert Uytterhoeven wrote:
>> If the optional "reset-gpios" property is specified in DT, the generic
>> MDIO bus code takes care of resetting the PHY during device probe.
>> However, the PHY may still have to be reset explicitly after system
>> resume.
>>
>> This allows to restore Ethernet operation after resume from s2ram on
>> Salvator-XS, where the enable pin of the regulator providing PHY power
>> is connected to PRESETn, and PSCI suspend powers down the SoC.
>>
>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> ---
>> drivers/net/ethernet/renesas/ravb_main.c | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
>> index fdf30bfa403bf416..96d1d48e302f8c9a 100644
>> --- a/drivers/net/ethernet/renesas/ravb_main.c
>> +++ b/drivers/net/ethernet/renesas/ravb_main.c
>> @@ -19,6 +19,7 @@
>> #include <linux/etherdevice.h>
>> #include <linux/ethtool.h>
>> #include <linux/if_vlan.h>
>> +#include <linux/gpio/consumer.h>
>> #include <linux/kernel.h>
>> #include <linux/list.h>
>> #include <linux/module.h>
>> @@ -2268,6 +2269,7 @@ static int __maybe_unused ravb_resume(struct device *dev)
>> {
>> struct net_device *ndev = dev_get_drvdata(dev);
>> struct ravb_private *priv = netdev_priv(ndev);
>> + struct mii_bus *bus = priv->mii_bus;
>> int ret = 0;
>>
>> if (priv->wol_enabled) {
>> @@ -2302,6 +2304,13 @@ static int __maybe_unused ravb_resume(struct device *dev)
>> * reopen device if it was running before system suspended.
>> */
>>
>> + /* PHY reset */
>> + if (bus->reset_gpiod) {
>> + gpiod_set_value_cansleep(bus->reset_gpiod, 1);
>> + udelay(bus->reset_delay_us);
>> + gpiod_set_value_cansleep(bus->reset_gpiod, 0);
>> + }
>
> This is a clever hack, but unfortunately this is also misusing the MDIO
> bus reset line into a PHY reset line. As commented in patch 3, if this
> reset line is tied to the PHY, then this should be a PHY property and
OK.
> you cannot (ab)use the MDIO bus GPIO reset logic anymore...
And then I should add reset-gpios support to drivers/net/phy/micrel.c?
Or is there already generic code to handle per-PHY reset? I couldn't find it.
> Should not you also try to manage this reset line during ravb_open() to
> achiever better power savings?
I don't know. The Micrel KSZ9031RNXVA datasheet doesn't mention if it's
safe or not to assert reset for a prolonged time.
Thanks!
Gr{oetje,eeting}s,
Geert
^ permalink raw reply
* Re: [PATCH RFC 3/5] Add KSZ8795 switch driver
From: Florian Fainelli @ 2017-09-28 18:45 UTC (permalink / raw)
To: Pavel Machek, Tristram.Ha
Cc: andrew, muvarov, nathan.leigh.conrad, vivien.didelot, netdev,
linux-kernel, Woojung.Huh
In-Reply-To: <20170928184059.GA2825@amd>
On 09/28/2017 11:40 AM, Pavel Machek wrote:
> Hi!
>
> On Mon 2017-09-18 20:27:13, Tristram.Ha@microchip.com wrote:
>>>> +/**
>>>> + * Some counters do not need to be read too often because they are less
>>> likely
>>>> + * to increase much.
>>>> + */
>>>
>>> What does comment mean? Are you caching statistics, and updating
>>> different values at different rates?
>>>
>>
>> There are 34 counters. In normal case using generic bus I/O or PCI to read them
>> is very quick, but the switch is mostly accessed using SPI, or even I2C. As the SPI
>> access is very slow and cannot run in interrupt context I keep worrying reading
>> the MIB counters in a loop for 5 or more ports will prevent other critical hardware
>> access from executing soon enough. These accesses can be getting 1588 PTP
>> timestamps and opening/closing ports. (RSTP Conformance Test sends test traffic
>> to port supposed to be closed/opened after receiving specific RSTP
>> BPDU.)
>
> Hmm. Ok, interesting.
>
> I wonder how well this is going to work if userspace actively 'does
> something' with the switch.
>
> It seems to me that even if your statistics code is careful not to do
> 'a lot' of accesses at the same time, userspace can use other parts of
> the driver to do the same, and thus cause same unwanted effects...
A few switches have a MIB snapshot feature that is implemented such that
accessing the snapshot does not hog the remainder of the switch
registers, is this something possible on KSZ switches?
Tangential: net-next is currently open, so now would be a good time to
send a revised version of your patch series to target possibly 4.15 with
an initial implementation. Please fix the cover-letter and patch
threading such that they look like the following:
[PATCH 0/X]
[PATCH 1/X]
[PATCH 2/X]
etc..
Right now this shows up as separate emails/patches and this is very
annoying to follow as a thread.
Thank you
--
Florian
^ 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