* Re: [PATCH net 2/2] sit: check if IPv6 enabled before call ip6_err_gen_icmpv6_unreach()
From: Stefano Brivio @ 2019-02-06 15:00 UTC (permalink / raw)
To: Hangbin Liu; +Cc: netdev, David Miller
In-Reply-To: <20190206125111.5286-3-liuhangbin@gmail.com>
On Wed, 6 Feb 2019 20:51:11 +0800
Hangbin Liu <liuhangbin@gmail.com> wrote:
> If we disabled IPv6 from kernel boot up cmd(ipv6.disable=1), we should not
> call ip6_err_gen_icmpv6_unreach().
>
> Reproducer:
> ip link add sit1 type sit local 10.10.0.1 remote 10.10.1.1 ttl 1
> ip link set sit1 up
> ip addr add 192.168.0.1/24 dev sit1
> ping 192.168.0.2
>
> Reported-by: Jianlin Shi <jishi@redhat.com>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
> ---
> net/ipv6/sit.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
> index 1e03305c0549..e43fbac0fd1a 100644
> --- a/net/ipv6/sit.c
> +++ b/net/ipv6/sit.c
> @@ -493,6 +493,7 @@ static int ipip6_err(struct sk_buff *skb, u32 info)
> const int type = icmp_hdr(skb)->type;
> const int code = icmp_hdr(skb)->code;
> unsigned int data_len = 0;
> + struct inet6_dev *idev;
> struct ip_tunnel *t;
> int sifindex;
> int err;
> @@ -546,8 +547,13 @@ static int ipip6_err(struct sk_buff *skb, u32 info)
> }
>
> err = 0;
> - if (!ip6_err_gen_icmpv6_unreach(skb, iph->ihl * 4, type, data_len))
> +
> + idev = in6_dev_get(skb->dev);
> + if (idev &&
> + !ip6_err_gen_icmpv6_unreach(skb, iph->ihl * 4, type, data_len)) {
> + in6_dev_put(idev);
> goto out;
> + }
You are leaking a reference if idev && ip6_err_gen_icmpv6_unreach(...).
You should call in6_dev_put(idev) whenever idev is not NULL instead.
--
Stefano
^ permalink raw reply
* Re: [PATCH net 1/2] geneve: should not call rt6_lookup() when ipv6 was disabled
From: Stefano Brivio @ 2019-02-06 14:58 UTC (permalink / raw)
To: Hangbin Liu; +Cc: netdev, David Miller
In-Reply-To: <20190206125111.5286-2-liuhangbin@gmail.com>
Hi Hangbin,
On Wed, 6 Feb 2019 20:51:10 +0800
Hangbin Liu <liuhangbin@gmail.com> wrote:
> When we add a new GENEVE device with IPv6 remote, checking only for
> IS_ENABLED(CONFIG_IPV6) is not enough as we may disable IPv6 in kernel
> cmd(ipv6.disable=1), which will cause a NULL pointer dereference.
>
> Reported-by: Jianlin Shi <jishi@redhat.com>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
> ---
> drivers/net/geneve.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
> index 58bbba8582b0..0658715581e3 100644
> --- a/drivers/net/geneve.c
> +++ b/drivers/net/geneve.c
> @@ -1512,6 +1512,10 @@ static void geneve_link_config(struct net_device *dev,
> }
> #if IS_ENABLED(CONFIG_IPV6)
> case AF_INET6: {
> + struct inet6_dev *idev = in6_dev_get(dev);
> + if (!idev)
> + break;
> +
> struct rt6_info *rt = rt6_lookup(geneve->net,
> &info->key.u.ipv6.dst, NULL, 0,
> NULL, 0);
You're mixing declarations and code here, ISO C90 forbids it. You
could rather declare:
struct inet6_dev *idev = in6_dev_get(dev);
struct rt6_info *rt;
then check idev, and then call rt6_lookup().
> @@ -1519,6 +1523,8 @@ static void geneve_link_config(struct net_device *dev,
> if (rt && rt->dst.dev)
> ldev_mtu = rt->dst.dev->mtu - GENEVE_IPV6_HLEN;
> ip6_rt_put(rt);
> +
> + in6_dev_put(idev);
I think it would be better to put this right after the check on idev,
mostly for readability, but also, marginally, to reduce the scope of
the reference count bump.
--
Stefano
^ permalink raw reply
* Re: [PATCH v2] bpf: test_maps: Avoid possible out of bound access
From: Daniel Borkmann @ 2019-02-06 14:52 UTC (permalink / raw)
To: Breno Leitao, netdev; +Cc: ast, davem
In-Reply-To: <1549386754-8549-1-git-send-email-leitao@debian.org>
On 02/05/2019 06:12 PM, Breno Leitao wrote:
> When compiling test_maps selftest with GCC-8, it warns that an array might
> be indexed with a negative value, which could cause a negative out of bound
> access, depending on parameters of the function. This is the GCC-8 warning:
>
> gcc -Wall -O2 -I../../../include/uapi -I../../../lib -I../../../lib/bpf -I../../../../include/generated -DHAVE_GENHDR -I../../../include test_maps.c /home/breno/Devel/linux/tools/testing/selftests/bpf/libbpf.a -lcap -lelf -lrt -lpthread -o /home/breno/Devel/linux/tools/testing/selftests/bpf/test_maps
> In file included from test_maps.c:16:
> test_maps.c: In function ‘run_all_tests’:
> test_maps.c:1079:10: warning: array subscript -1 is below array bounds of ‘pid_t[<Ube20> + 1]’ [-Warray-bounds]
> assert(waitpid(pid[i], &status, 0) == pid[i]);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> test_maps.c:1059:6: warning: array subscript -1 is below array bounds of ‘pid_t[<Ube20> + 1]’ [-Warray-bounds]
> pid[i] = fork();
> ~~~^~~
>
> This patch simply guarantees that the task(s) variables are unsigned, thus,
> they could never be a negative number, hence avoiding an out of bound access
> warning.
>
> Signed-off-by: Breno Leitao <leitao@debian.org>
Given this is a false positive anyway and we only want to reduce gcc noise, I've
applied it to bpf-next, thanks Breno!
^ permalink raw reply
* Re: [PATCH bpf-next] tools: bpftool: doc, fix incorrect text
From: Daniel Borkmann @ 2019-02-06 14:45 UTC (permalink / raw)
To: Prashant Bhole, Alexei Starovoitov; +Cc: netdev
In-Reply-To: <20190206014723.1424-1-bhole_prashant_q7@lab.ntt.co.jp>
On 02/06/2019 02:47 AM, Prashant Bhole wrote:
> Documentation about cgroup, feature, prog uses wrong header
> 'MAP COMMANDS' while listing commands. This patch corrects the header
> in respective doc files.
>
> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH bpf-next 0/5] net: xdp: allow offload to coexist with generic
From: Daniel Borkmann @ 2019-02-06 14:44 UTC (permalink / raw)
To: Jakub Kicinski, alexei.starovoitov; +Cc: netdev, oss-drivers
In-Reply-To: <20190206040324.22109-1-jakub.kicinski@netronome.com>
On 02/06/2019 05:03 AM, Jakub Kicinski wrote:
> Hi!
>
> Offloaded and native/driver XDP programs can already coexist.
> Allow offload and generic hook to coexist as well, there seem
> to be no reason why not to do so.
>
> Jakub Kicinski (5):
> selftests/bpf: fix the expected messages
> net: xdp: allow generic and driver XDP on one interface
> selftests/bpf: print traceback when test fails
> selftests/bpf: add test for mixing generic and offload XDP
> selftests/bpf: test reading the offloaded program
>
> net/core/dev.c | 10 +-
> tools/testing/selftests/bpf/test_offload.py | 135 ++++++++++++--------
> 2 files changed, 85 insertions(+), 60 deletions(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH net-next v3 00/12] net: Introduce ndo_get_port_parent_id()
From: Ido Schimmel @ 2019-02-06 14:24 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev@vger.kernel.org, David S. Miller, open list,
open list:MELLANOX MLX5 core VPI driver,
open list:NETRONOME ETHERNET DRIVERS, open list:STAGING SUBSYSTEM,
moderated list:ETHERNET BRIDGE
In-Reply-To: <20190206075136.GA2283@splinter>
On Wed, Feb 06, 2019 at 09:51:36AM +0200, Ido Schimmel wrote:
> On Tue, Feb 05, 2019 at 03:53:14PM -0800, Florian Fainelli wrote:
> > Hi all,
> >
> > Based on discussion with Ido and feedback from Jakub there are clearly
> > two classes of users that implement SWITCHDEV_ATTR_ID_PORT_PARENT_ID:
> >
> > - PF/VF drivers which typically only implement return the port's parent
> > ID, yet have to implement switchdev_port_attr_get() just for that
> >
> > - Ethernet switch drivers: mlxsw, ocelot, DSA, etc. which implement more
> > attributes which we want to be able to eventually veto in the context
> > of the caller, thus making them candidates for using a blocking notifier
> > chain
>
> Florian, patches look good to me. I'm going to build a kernel with these
> patches and run some tests. Will report later today.
Ran most of our tests and nothing exploded. Thanks!
^ permalink raw reply
* Re: [PATCH 0/8] nic: thunderx: fix communication races betwen VF & PF
From: Vadim Lomovtsev @ 2019-02-06 14:18 UTC (permalink / raw)
To: sgoutham@cavium.com, rric@kernel.org, davem@davemloft.net,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: dnelson@redhat.com
In-Reply-To: <20190206101351.16744-1-vlomovtsev@marvell.com>
self-NACK here, some emails get's corrupted for some reasons,
along with some typos found.
sorry for inconvenience.
Vadim
On Wed, Feb 06, 2019 at 10:13:54AM +0000, Vadim Lomovtsev wrote:
> The ThunderX CN88XX NIC Virtual Function driver uses mailbox interface
> to communicate to physical function driver. Each of VF has it's own pair
> of mailbox registers to read from and write to. The mailbox registers
> has no protection from possible races, so it has to be implemented
> at software side.
>
> After long term testing by loop of 'ip link set <ifname> up/down'
> command it was found that there are two possible scenarios when
> race condition appears:
> 1. VF receives link change message from PF and VF send RX mode
> configuration message to PF in the same time from separate thread.
> 2. PF receives RX mode configuration from VF and in the same time,
> in separate thread PF detects link status change and sends appropriate
> message to particular VF.
>
> Both cases leads to mailbox data to be rewritten, NIC VF messaging control
> data to be updated incorrectly and communication sequence gets broken.
>
> This patch series is to address race condition with VF & PF communication.
>
> Vadim Lomovtsev (8):
> net: thunderx: correct typo in macro name
> net: thunderx: replace global nicvf_rx_mode_wq work queue for all VFs
> to private for each of them.
> net: thunderx: make CFG_DONE message to run through generic send-ack
> sequence
> net: thunderx: add nicvf_send_msg_to_pf result check for
> set_rx_mode_task
> net: thunderx: rework xcast message structure to make it fit into 64
> bit
> net: thunderx: add mutex to protect mailbox from concurrent calls for
> same VF
> net: thunderx: implement helpers to read mailbox IRQ status
> net: thunderx: check status of mailbox IRQ before sending a message
>
> drivers/net/ethernet/cavium/thunder/nic.h | 12 +--
> .../net/ethernet/cavium/thunder/nic_main.c | 58 +++++++------
> .../net/ethernet/cavium/thunder/nicvf_main.c | 82 +++++++++++++------
> .../ethernet/cavium/thunder/nicvf_queues.c | 14 ++++
> .../ethernet/cavium/thunder/nicvf_queues.h | 1 +
> .../net/ethernet/cavium/thunder/thunder_bgx.c | 2 +-
> .../net/ethernet/cavium/thunder/thunder_bgx.h | 2 +-
> 7 files changed, 112 insertions(+), 59 deletions(-)
>
> --
> 2.17.2
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: net: add MDIO bus multiplexer driven by a regmap device
From: Andrew Lunn @ 2019-02-06 13:52 UTC (permalink / raw)
To: Pankaj Bansal; +Cc: Florian Fainelli, netdev@vger.kernel.org
In-Reply-To: <20190206114523.8954-2-pankaj.bansal@nxp.com>
On Wed, Feb 06, 2019 at 06:20:39AM +0000, Pankaj Bansal wrote:
> Add support for an MDIO bus multiplexer controlled by a regmap
> device, like an FPGA.
>
> Tested on a NXP LX2160AQDS board which uses the "QIXIS" FPGA
> attached to the i2c bus.
>
> Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
> ---
>
> Notes:
> V4:
> - No change
> V3:
> - No change
> V2:
> - New file describing the device tree bindings for regmap controlled devices'
> mdio mux
>
> .../bindings/net/mdio-mux-regmap.txt | 167 +++++++++++++++++
> 1 file changed, 167 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/mdio-mux-regmap.txt b/Documentation/devicetree/bindings/net/mdio-mux-regmap.txt
> new file mode 100644
> index 000000000000..8968f317965f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/mdio-mux-regmap.txt
> @@ -0,0 +1,167 @@
> +Properties for an MDIO bus multiplexer controlled by a regmap
> +
> +This is a special case of a MDIO bus multiplexer. A regmap device,
> +like an FPGA, is used to control which child bus is connected. The mdio-mux
> +node must be a child of the device that is controlled by a regmap.
> +The driver currently only supports devices with upto 32-bit registers.
> +
> +Required properties in addition to the generic multiplexer properties:
> +
> +- reg : integer, contains the offset of the register that controls the bus
> + multiplexer. it can be 32 bit number.
> +
> +- mux-mask : integer, contains an 32 bit mask that specifies which
> + bits in the register control the actual bus multiplexer. The
> + 'reg' property of each child mdio-mux node must be constrained by
> + this mask.
Hi Pankaj
Maybe you can address the comment about not having a compatible flag
by commenting that this is a device tree fragment, which is expected
to appear inside the binding of some other device. It is not a
standalone device.
Andrew
^ permalink raw reply
* Re: [PATCH net] virtio_net: Account for tx bytes and packets on sending xdp_frames
From: Jesper Dangaard Brouer @ 2019-02-06 13:48 UTC (permalink / raw)
To: Saeed Mahameed
Cc: dsahern@gmail.com, thoiland@redhat.com,
virtualization@lists.linux-foundation.org, borkmann@iogearbox.net,
Tariq Toukan, john.fastabend@gmail.com, mst@redhat.com,
jakub.kicinski@netronome.com, netdev@vger.kernel.org,
jasowang@redhat.com, davem@davemloft.net,
makita.toshiaki@lab.ntt.co.jp, brouer
In-Reply-To: <140ecbe1e25f54f90d859cc696c4119aa96bc6eb.camel@mellanox.com>
On Wed, 6 Feb 2019 00:06:33 +0000
Saeed Mahameed <saeedm@mellanox.com> wrote:
> 3) Unrelated, In non XDP case, if skb allocation fails or driver fails
> to pass the skb up to the stack for somereason, should the driver
> increase rx packets ? IMHO the answer should be yes if we want to have
> similar behavior between XDP and non XDP cases.
I don't think "skb allocation fails" should increase rx packets
counter. The difference is that these events are outside sysadm/users
control, and is an error detected inside the driver. The XDP program
takes a policy choice to XDP_DROP a packet, which can be accounted
inside the XDP prog (as the samples show) or as we also discuss via a
more generic XDP-action counters.
That said, I took at quick look at driver code, and it seems this
behavior differs per driver... ixgbe and mlx5 does not count "skb
allocation fails" as RX-ed packets, while mlx4 seems to count them.
> But this could result in netdev->stats.rx_packets +
> netdev->stats.rx_dropped to be more than the actual rx-ed packets, is
> this acceptable ?
This is one reasons I think this is wrong.
--Jesper
^ permalink raw reply
* Re: [PATCH net-next v3 12/12] net: Get rid of SWITCHDEV_ATTR_ID_PORT_PARENT_ID
From: Jiri Pirko @ 2019-02-06 13:34 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David S. Miller, Ido Schimmel, open list,
open list:MELLANOX MLX5 core VPI driver,
open list:NETRONOME ETHERNET DRIVERS, open list:STAGING SUBSYSTEM,
moderated list:ETHERNET BRIDGE
In-Reply-To: <20190205235326.14600-13-f.fainelli@gmail.com>
Wed, Feb 06, 2019 at 12:53:26AM CET, f.fainelli@gmail.com wrote:
>Now that we have a dedicated NDO for getting a port's parent ID, get rid
>of SWITCHDEV_ATTR_ID_PORT_PARENT_ID and convert all callers to use the
>NDO exclusively. This is a preliminary change to getting rid of
>switchdev_ops eventually.
>
>Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
[...]
>@@ -24,19 +23,12 @@ static int br_switchdev_mark_get(struct net_bridge *br, struct net_device *dev)
>
> int nbp_switchdev_mark_set(struct net_bridge_port *p)
> {
>- const struct net_device_ops *ops = p->dev->netdev_ops;
>- struct switchdev_attr attr = {
>- .orig_dev = p->dev,
>- .id = SWITCHDEV_ATTR_ID_PORT_PARENT_ID,
>- };
>- int err;
>+ struct netdev_phys_item_id ppid = { };
>+ int err = -EOPNOTSUPP;
Pointless init.
>
> ASSERT_RTNL();
>
>- if (ops->ndo_get_port_parent_id)
>- err = dev_get_port_parent_id(p->dev, &attr.u.ppid, true);
>- else
>- err = switchdev_port_attr_get(p->dev, &attr);
>+ err = dev_get_port_parent_id(p->dev, &ppid, true);
> if (err) {
> if (err == -EOPNOTSUPP)
> return 0;
[...]
>@@ -1146,26 +1145,17 @@ static int rtnl_phys_port_name_fill(struct sk_buff *skb, struct net_device *dev)
>
> static int rtnl_phys_switch_id_fill(struct sk_buff *skb, struct net_device *dev)
> {
>- const struct net_device_ops *ops = dev->netdev_ops;
>- int err;
>- struct switchdev_attr attr = {
>- .orig_dev = dev,
>- .id = SWITCHDEV_ATTR_ID_PORT_PARENT_ID,
>- .flags = SWITCHDEV_F_NO_RECURSE,
>- };
>+ struct netdev_phys_item_id ppid = { };
>+ int err = -EOPNOTSUPP;
Pointless init.
>
>- if (ops->ndo_get_port_parent_id)
>- err = dev_get_port_parent_id(dev, &attr.u.ppid, false);
>- else
>- err = switchdev_port_attr_get(dev, &attr);
>+ err = dev_get_port_parent_id(dev, &ppid, false);
> if (err) {
> if (err == -EOPNOTSUPP)
> return 0;
> return err;
> }
>
>- if (nla_put(skb, IFLA_PHYS_SWITCH_ID, attr.u.ppid.id_len,
>- attr.u.ppid.id))
>+ if (nla_put(skb, IFLA_PHYS_SWITCH_ID, ppid.id_len, ppid.id))
> return -EMSGSIZE;
>
> return 0;
[...]
>@@ -920,15 +917,10 @@ static int vif_add(struct net *net, struct mr_table *mrt,
> vifc->vifc_flags | (!mrtsock ? VIFF_STATIC : 0),
> (VIFF_TUNNEL | VIFF_REGISTER));
>
>- attr.orig_dev = dev;
> ops = dev->netdev_ops;
>- if (ops->ndo_get_port_parent_id &&
>- !dev_get_port_parent_id(dev, &attr.u.ppid, true)) {
>- memcpy(v->dev_parent_id.id, attr.u.ppid.id, attr.u.ppid.id_len);
>- v->dev_parent_id.id_len = attr.u.ppid.id_len;
>- } else if (!switchdev_port_attr_get(dev, &attr)) {
>- memcpy(v->dev_parent_id.id, attr.u.ppid.id, attr.u.ppid.id_len);
>- v->dev_parent_id.id_len = attr.u.ppid.id_len;
>+ if (!dev_get_port_parent_id(dev, &ppid, true)) {
Please split this to:
err = dev_get_port_parent_id(dev, &ppid, true);
if (err) {
>+ memcpy(v->dev_parent_id.id, ppid.id, ppid.id_len);
>+ v->dev_parent_id.id_len = ppid.id_len;
> } else {
> v->dev_parent_id.id_len = 0;
> }
[...]
^ permalink raw reply
* Re: Is advertising of 2500Mbps support must from phy device to set phy at 2500Mbps link speed
From: Andrew Lunn @ 2019-02-06 13:38 UTC (permalink / raw)
To: abhijit; +Cc: netdev
In-Reply-To: <ae092836-7ec1-a599-765f-6689310e97bb@gmail.com>
> Currently, we don't have any phy drivers. Generic driver doesn't seems to
> support 2500Mbps.
Correct. genphy only supports upto 1G. The c45 based genphy_c45 is
slowly gaining more features and might soon support 2.5G.
> If I have to write the driver, whether it is necessary for
> phy device to advertise speed of 2500Mbps?
The user could force it, using the ethool command you suggested. But
it is the PHY driver which configures this. If you add the driver code
to force it, you might as well add the driver code to allow it to be
negotiated.
> Phy is custom phy and is currently under test. If you know any phy device
> that supports 2500Mbps and whose data sheet is available freely please let
> me know.
There are none that i know of with open data sheets. However the IEEE
standards should be freely available and they describe the registers
the PHY is expected to have. There are also patches floating around
which add 2.5G and 5G support to the marvell10g driver. I expect these
patches to get merged soon, but maybe in a different form to make
genphy_c45 more generic.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v3 11/12] net: dsa: Implement ndo_get_port_parent_id()
From: Jiri Pirko @ 2019-02-06 13:27 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David S. Miller, Ido Schimmel, open list,
open list:MELLANOX MLX5 core VPI driver,
open list:NETRONOME ETHERNET DRIVERS, open list:STAGING SUBSYSTEM,
moderated list:ETHERNET BRIDGE
In-Reply-To: <20190205235326.14600-12-f.fainelli@gmail.com>
Wed, Feb 06, 2019 at 12:53:25AM CET, f.fainelli@gmail.com wrote:
>DSA implements SWITCHDEV_ATTR_ID_PORT_PARENT_ID and we want to get rid
>of switchdev_ops eventually, ease that migration by implementing a
>ndo_get_port_parent_id() function which returns what
>switchdev_port_attr_get() would do.
>
>Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next v3 09/12] netdevsim: Implement ndo_get_port_parent_id()
From: Jiri Pirko @ 2019-02-06 13:24 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David S. Miller, Ido Schimmel, open list,
open list:MELLANOX MLX5 core VPI driver,
open list:NETRONOME ETHERNET DRIVERS, open list:STAGING SUBSYSTEM,
moderated list:ETHERNET BRIDGE
In-Reply-To: <20190205235326.14600-10-f.fainelli@gmail.com>
Wed, Feb 06, 2019 at 12:53:23AM CET, f.fainelli@gmail.com wrote:
>netdevsim only supports SWITCHDEV_ATTR_ID_PORT_PARENT_ID, which makes it a
>great candidate to be converted to use the ndo_get_port_parent_id() NDO
>instead of implementing switchdev_port_attr_get().
>
>Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next v3 08/12] rocker: Implement ndo_get_port_parent_id()
From: Jiri Pirko @ 2019-02-06 13:23 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David S. Miller, Ido Schimmel, open list,
open list:MELLANOX MLX5 core VPI driver,
open list:NETRONOME ETHERNET DRIVERS, open list:STAGING SUBSYSTEM,
moderated list:ETHERNET BRIDGE
In-Reply-To: <20190205235326.14600-9-f.fainelli@gmail.com>
Wed, Feb 06, 2019 at 12:53:22AM CET, f.fainelli@gmail.com wrote:
>mlxsw implements SWITCHDEV_ATTR_ID_PORT_PARENT_ID and we want to get rid
>of switchdev_ops eventually, ease that migration by implementing a
>ndo_get_port_parent_id() function which returns what
>switchdev_port_attr_get() would do.
>
>Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next v3 07/12] nfp: Implement ndo_get_port_parent_id()
From: Jiri Pirko @ 2019-02-06 13:23 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David S. Miller, Ido Schimmel, open list,
open list:MELLANOX MLX5 core VPI driver,
open list:NETRONOME ETHERNET DRIVERS, open list:STAGING SUBSYSTEM,
moderated list:ETHERNET BRIDGE
In-Reply-To: <20190205235326.14600-8-f.fainelli@gmail.com>
Wed, Feb 06, 2019 at 12:53:21AM CET, f.fainelli@gmail.com wrote:
>NFP only supports SWITCHDEV_ATTR_ID_PORT_PARENT_ID, which makes it a
>great candidate to be converted to use the ndo_get_port_parent_id() NDO
>instead of implementing switchdev_port_attr_get().
>
>Since NFP uses switchdev_port_same_parent_id() convert it to use
>netdev_port_same_parent_id().
>
>Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
[...]
>@@ -31,34 +31,23 @@ struct nfp_port *nfp_port_from_netdev(struct net_device *netdev)
> return NULL;
> }
>
>-static int
>-nfp_port_attr_get(struct net_device *netdev, struct switchdev_attr *attr)
>+int nfp_port_get_port_parent_id(struct net_device *netdev,
>+ struct netdev_phys_item_id *ppid)
> {
> struct nfp_port *port;
>+ const u8 *serial;
>
> port = nfp_port_from_netdev(netdev);
> if (!port)
> return -EOPNOTSUPP;
>
>- switch (attr->id) {
>- case SWITCHDEV_ATTR_ID_PORT_PARENT_ID: {
>- const u8 *serial;
>- /* N.B: attr->u.ppid.id is binary data */
>- attr->u.ppid.id_len = nfp_cpp_serial(port->app->cpp, &serial);
>- memcpy(&attr->u.ppid.id, serial, attr->u.ppid.id_len);
>- break;
>- }
>- default:
>- return -EOPNOTSUPP;
>- }
>+ /* N.B: attr->u.ppid.id is binary data */
Comment is not updated. But I wonder if we really need it...
Otherwise this looks fine.
Acked-by: Jiri Pirko <jiri@mellanox.com>
>+ ppid->id_len = nfp_cpp_serial(port->app->cpp, &serial);
>+ memcpy(&ppid->id, serial, ppid->id_len);
>
> return 0;
> }
>
>-const struct switchdev_ops nfp_port_switchdev_ops = {
>- .switchdev_port_attr_get = nfp_port_attr_get,
>-};
>-
> int nfp_port_setup_tc(struct net_device *netdev, enum tc_setup_type type,
> void *type_data)
> {
[...]
^ permalink raw reply
* Re: [PATCH v3 1/2] r8169: Load MAC address from device tree if present
From: Andrew Lunn @ 2019-02-06 13:29 UTC (permalink / raw)
To: Thierry Reding
Cc: David S. Miller, Heiner Kallweit, Joe Perches, Eric Dumazet,
Paul Zimmerman, Michal Kubecek, Realtek linux nic maintainers,
netdev, linux-kernel
In-Reply-To: <20190206123018.24802-1-thierry.reding@gmail.com>
On Wed, Feb 06, 2019 at 01:30:17PM +0100, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> If the system was booted using a device tree and if the device tree
> contains a MAC address, use it instead of reading one from the EEPROM.
> This is useful in situations where the EEPROM isn't properly programmed
> or where the firmware wants to override the existing MAC address.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v3 2/2] r8169: Avoid pointer aliasing
From: Andrew Lunn @ 2019-02-06 13:28 UTC (permalink / raw)
To: Thierry Reding
Cc: David S. Miller, Heiner Kallweit, Joe Perches, Eric Dumazet,
Paul Zimmerman, Michal Kubecek, Realtek linux nic maintainers,
netdev, linux-kernel
In-Reply-To: <20190206123018.24802-2-thierry.reding@gmail.com>
On Wed, Feb 06, 2019 at 01:30:18PM +0100, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Read MAC address 32-bit at a time and manually extract the individual
> bytes. This avoids pointer aliasing and gives the compiler a better
> chance of optimizing the operation.
>
> Suggested-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> Applies to net-next.
>
> I tested this on a Jetson TX2 with an add-in Realtek ethernet card that
> has a properly programmed OTP to verify that I got the endianess right.
> Seems like everything works and the device behaves the same with or
> without this patch.
>
> Changes in v3:
> - align MAC address to u16 for is_valid_ether_addr()
Hi Thierry
The point of this patch was to try to avoid the pointer aliasing,
which is what leads to the alignment requirements. But if you are
forced to align it because of is_valid_ether_addr() i would just drop
this patch. Aliasing is going to happen whatever.
But if you want to keep it.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v3 06/12] mscc: ocelot: Implement ndo_get_port_parent_id()
From: Jiri Pirko @ 2019-02-06 13:16 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David S. Miller, Ido Schimmel, open list,
open list:MELLANOX MLX5 core VPI driver,
open list:NETRONOME ETHERNET DRIVERS, open list:STAGING SUBSYSTEM,
moderated list:ETHERNET BRIDGE
In-Reply-To: <20190205235326.14600-7-f.fainelli@gmail.com>
Wed, Feb 06, 2019 at 12:53:20AM CET, f.fainelli@gmail.com wrote:
>Ocelot only supports SWITCHDEV_ATTR_ID_PORT_PARENT_ID as a valid
>switchdev attribute getter, convert it to use ndo_get_port_parent_id()
>and get rid of the switchdev_ops::switchdev_port_attr_get altogether.
>
>Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next v3 05/12] mlxsw: Implement ndo_get_port_parent_id()
From: Jiri Pirko @ 2019-02-06 13:14 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David S. Miller, Ido Schimmel, open list,
open list:MELLANOX MLX5 core VPI driver,
open list:NETRONOME ETHERNET DRIVERS, open list:STAGING SUBSYSTEM,
moderated list:ETHERNET BRIDGE
In-Reply-To: <20190205235326.14600-6-f.fainelli@gmail.com>
Wed, Feb 06, 2019 at 12:53:19AM CET, f.fainelli@gmail.com wrote:
>mlxsw implements SWITCHDEV_ATTR_ID_PORT_PARENT_ID and we want to get rid
>of switchdev_ops eventually, ease that migration by implementing a
>ndo_get_port_parent_id() function which returns what
>switchdev_port_attr_get() would do.
>
>Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
[...]
>diff --git a/drivers/net/ethernet/mellanox/mlxsw/switchx2.c b/drivers/net/ethernet/mellanox/mlxsw/switchx2.c
>index 2d4f213e154d..3814ba8af517 100644
>--- a/drivers/net/ethernet/mellanox/mlxsw/switchx2.c
>+++ b/drivers/net/ethernet/mellanox/mlxsw/switchx2.c
Please remove net/switchdev.h inclusion from this file, you don't need
it any longer.
Otherwise, looks fine.
Acked-by: Jiri Pirko <jiri@mellanox.com>
[...]
^ permalink raw reply
* Re: Is advertising of 2500Mbps support must from phy device to set phy at 2500Mbps link speed
From: abhijit @ 2019-02-06 13:23 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20190205145601.GJ3397@lunn.ch>
Hi Andrew,
Thank you very much for reply.
Please see my reply in-line
On Tuesday 05 February 2019 08:26 PM, Andrew Lunn wrote:
> On Tue, Feb 05, 2019 at 11:39:34AM +0530, abhijit wrote:
>> Hi All,
>>
>> We are using Ethernet MAC which has integrated Phy. This phy supports speed
>> up to 10000Mbps. The phy has, 1000Base-X PCS(Physical Coding Sub-layer)
>> followed by SerDes interface to support 10Mbps to 10000Mbps. Currently we
>> are trying to get this phy at 2500Mbps. This device has 16 registers that
>> corresponds to Clause 37, which can be used to advertise speed till
>> 1000Mbps.
>> So my question is,
>> 1. Without phy advertising its capability of 2500Mbps, is there any way I
>> can set phy speed at 2500Mbps?
>> 2. I tried disabling auto-negotiation and setting speed at 2500Mbps with
>> ethtool (ethtool -s eth0 speed 2500 autoneg off), but the ethtool reported
>> this configuration as invalid?
>> 3. At the end we are targeting print of "link up (2500/Full)"
> Hi Abhijit
>
> It all depends on what the PHY driver can do.
> It sounds like the PHY
> driver does not support multi-gige speeds. So you probably need to
> work on the PHY driver and add support for them.
Currently, we don't have any phy drivers. Generic driver doesn't seems
to support 2500Mbps. If I have to write the driver, whether it is
necessary for phy device to advertise speed of 2500Mbps?
>
> What PHY is it?
Phy is custom phy and is currently under test. If you know any phy
device that supports 2500Mbps and whose data sheet is available freely
please let me know.
>
> Andrew
^ permalink raw reply
* [PATCH v2 04/28] thunderbolt: Add dummy read after port capability list walk on Light Ridge
From: Mika Westerberg @ 2019-02-06 13:17 UTC (permalink / raw)
To: linux-kernel
Cc: Michael Jamet, Yehezkel Bernat, Andreas Noever, Lukas Wunner,
David S . Miller, Mika Westerberg, Andy Shevchenko, netdev
In-Reply-To: <20190206131738.43696-1-mika.westerberg@linux.intel.com>
Light Ridge has an issue where reading the next capability pointer
location in port config space the read data is not cleared. It is fine
to read capabilities each after another so only thing we need to do is
to make sure we issue dummy read after tb_port_find_cap() is finished to
avoid the issue in next read.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
---
drivers/thunderbolt/cap.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/thunderbolt/cap.c b/drivers/thunderbolt/cap.c
index 0de548bda663..8aceb0d97a63 100644
--- a/drivers/thunderbolt/cap.c
+++ b/drivers/thunderbolt/cap.c
@@ -57,6 +57,21 @@ static int tb_port_enable_tmu(struct tb_port *port, bool enable)
return tb_sw_write(sw, &value, TB_CFG_SWITCH, offset, 1);
}
+static void tb_port_dummy_read(struct tb_port *port)
+{
+ /*
+ * When reading from next capability pointer location in port
+ * config space the read data is not cleared on LR. To avoid
+ * reading stale data on next read perform one dummy read after
+ * port capabilities are walked.
+ */
+ if (port->sw->config.device_id == PCI_DEVICE_ID_INTEL_LIGHT_RIDGE) {
+ u32 dummy;
+
+ tb_port_read(port, &dummy, TB_CFG_PORT, 0, 1);
+ }
+}
+
static int __tb_port_find_cap(struct tb_port *port, enum tb_port_cap cap)
{
u32 offset = 1;
@@ -97,6 +112,7 @@ int tb_port_find_cap(struct tb_port *port, enum tb_port_cap cap)
ret = __tb_port_find_cap(port, cap);
+ tb_port_dummy_read(port);
tb_port_enable_tmu(port, false);
return ret;
--
2.20.1
^ permalink raw reply related
* [PATCH v2 00/28] thunderbolt: Software connection manager improvements
From: Mika Westerberg @ 2019-02-06 13:17 UTC (permalink / raw)
To: linux-kernel
Cc: Michael Jamet, Yehezkel Bernat, Andreas Noever, Lukas Wunner,
David S . Miller, Mika Westerberg, Andy Shevchenko, netdev
Hi,
Software connection manager (drivers/thunderbolt/tb.c) is used on older
Apple hardware with Light Ridge, Cactus Ridge or Falcon Ridge controllers
to create PCIe tunnels when a Thunderbolt device is connected. Currently
only one PCIe tunnel is supported. On newer Alpine Ridge based Apple
systems the driver starts the firmware which then takes care creating
tunnels.
This series improves the software connection manager so that it will
support:
- Full PCIe daisy chains (up to 6 devices)
- Display Port tunneling
- P2P networking
We also add support for Titan Ridge based Apple systems where we can use
the same flows than with Alpine Ridge to start the firmware.
Note in order to prevent possible DMA attacks on these systems we should
make sure IOMMU is enabled. One option is to force dmar_platform_optin()
return true on Apple hardware. However, it is not part of this series. I'm
trusting people using Linux on such systems to take care of it. :-)
Previous version of the patch series can be viewed here:
https://lkml.org/lkml/2019/1/29/924
Changes from v1:
* Added ACK from David
* Add constant (TMU_ACCESS_EN) for BIT(20) when TMU access is enabled. We
keep it in cap.c close to the LR/ER workaround. Also we enable/disable
only during capability walk. If it turns we need to have it enabled
elsewhere we can move it to switch.c and enable just once during
switch enumeration.
* Use 0 to mean no cap_adap instead of negative value. This follows
cap_phy.
* Use correct PCI IDs (_BRIDGE) in the last patch where we start firmware
on Titan Ridge. It wrongly used NHI PCI IDs in v1.
Mika Westerberg (28):
net: thunderbolt: Unregister ThunderboltIP protocol handler when suspending
thunderbolt: Do not allocate switch if depth is greater than 6
thunderbolt: Enable TMU access when accessing port space on legacy devices
thunderbolt: Add dummy read after port capability list walk on Light Ridge
thunderbolt: Move LC specific functionality into a separate file
thunderbolt: Configure lanes when switch is initialized
thunderbolt: Set sleep bit when suspending switch
thunderbolt: Properly disable path
thunderbolt: Cache adapter specific capability offset into struct port
thunderbolt: Rename tunnel_pci to tunnel
thunderbolt: Generalize tunnel creation functionality
thunderbolt: Add functions for allocating and releasing hop IDs
thunderbolt: Add helper function to iterate from one port to another
thunderbolt: Extend tunnel creation to more than 2 adjacent switches
thunderbolt: Deactivate all paths before restarting them
thunderbolt: Discover preboot PCIe paths the boot firmware established
thunderbolt: Add support for full PCIe daisy chains
thunderbolt: Scan only valid NULL adapter ports in hotplug
thunderbolt: Generalize port finding routines to support all port types
thunderbolt: Rework NFC credits handling
thunderbolt: Add support for Display Port tunnels
thunderbolt: Run tb_xdp_handle_request() in system workqueue
thunderbolt: Add XDomain UUID exchange support
thunderbolt: Add support for DMA tunnels
thunderbolt: Make tb_switch_alloc() return ERR_PTR()
thunderbolt: Add support for XDomain connections
thunderbolt: Make rest of the logging to happen at debug level
thunderbolt: Start firmware on Titan Ridge Apple systems
drivers/net/thunderbolt.c | 3 +
drivers/thunderbolt/Makefile | 4 +-
drivers/thunderbolt/cap.c | 90 +++-
drivers/thunderbolt/ctl.c | 2 +-
drivers/thunderbolt/icm.c | 15 +-
drivers/thunderbolt/lc.c | 179 ++++++++
drivers/thunderbolt/path.c | 326 +++++++++++++--
drivers/thunderbolt/switch.c | 466 ++++++++++++++++++---
drivers/thunderbolt/tb.c | 529 ++++++++++++++++++------
drivers/thunderbolt/tb.h | 67 ++-
drivers/thunderbolt/tb_msgs.h | 11 +
drivers/thunderbolt/tb_regs.h | 50 ++-
drivers/thunderbolt/tunnel.c | 681 +++++++++++++++++++++++++++++++
drivers/thunderbolt/tunnel.h | 75 ++++
drivers/thunderbolt/tunnel_pci.c | 226 ----------
drivers/thunderbolt/tunnel_pci.h | 31 --
drivers/thunderbolt/xdomain.c | 142 ++++++-
include/linux/thunderbolt.h | 8 +
18 files changed, 2389 insertions(+), 516 deletions(-)
create mode 100644 drivers/thunderbolt/lc.c
create mode 100644 drivers/thunderbolt/tunnel.c
create mode 100644 drivers/thunderbolt/tunnel.h
delete mode 100644 drivers/thunderbolt/tunnel_pci.c
delete mode 100644 drivers/thunderbolt/tunnel_pci.h
--
2.20.1
^ permalink raw reply
* [PATCH v2 03/28] thunderbolt: Enable TMU access when accessing port space on legacy devices
From: Mika Westerberg @ 2019-02-06 13:17 UTC (permalink / raw)
To: linux-kernel
Cc: Michael Jamet, Yehezkel Bernat, Andreas Noever, Lukas Wunner,
David S . Miller, Mika Westerberg, Andy Shevchenko, netdev
In-Reply-To: <20190206131738.43696-1-mika.westerberg@linux.intel.com>
Light Ridge and Eagle Ridge both need to have TMU access enabled before
port space can be fully accessed so make sure it happens on those. This
allows us to get rid of the offset quirk in tb_port_find_cap().
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
---
drivers/thunderbolt/cap.c | 74 ++++++++++++++++++++++++++++++---------
1 file changed, 57 insertions(+), 17 deletions(-)
diff --git a/drivers/thunderbolt/cap.c b/drivers/thunderbolt/cap.c
index 9553305c63ea..0de548bda663 100644
--- a/drivers/thunderbolt/cap.c
+++ b/drivers/thunderbolt/cap.c
@@ -13,6 +13,7 @@
#define CAP_OFFSET_MAX 0xff
#define VSE_CAP_OFFSET_MAX 0xffff
+#define TMU_ACCESS_EN BIT(20)
struct tb_cap_any {
union {
@@ -22,28 +23,43 @@ struct tb_cap_any {
};
} __packed;
-/**
- * tb_port_find_cap() - Find port capability
- * @port: Port to find the capability for
- * @cap: Capability to look
- *
- * Returns offset to start of capability or %-ENOENT if no such
- * capability was found. Negative errno is returned if there was an
- * error.
- */
-int tb_port_find_cap(struct tb_port *port, enum tb_port_cap cap)
+static int tb_port_enable_tmu(struct tb_port *port, bool enable)
{
- u32 offset;
+ struct tb_switch *sw = port->sw;
+ u32 value, offset;
+ int ret;
/*
- * DP out adapters claim to implement TMU capability but in
- * reality they do not so we hard code the adapter specific
- * capability offset here.
+ * Legacy devices need to have TMU access enabled before port
+ * space can be fully accessed.
*/
- if (port->config.type == TB_TYPE_DP_HDMI_OUT)
- offset = 0x39;
+ switch (sw->config.device_id) {
+ case PCI_DEVICE_ID_INTEL_LIGHT_RIDGE:
+ offset = 0x26;
+ break;
+ case PCI_DEVICE_ID_INTEL_EAGLE_RIDGE:
+ offset = 0x2a;
+ break;
+
+ default:
+ return 0;
+ }
+
+ ret = tb_sw_read(sw, &value, TB_CFG_SWITCH, offset, 1);
+ if (ret)
+ return ret;
+
+ if (enable)
+ value |= TMU_ACCESS_EN;
else
- offset = 0x1;
+ value &= ~TMU_ACCESS_EN;
+
+ return tb_sw_write(sw, &value, TB_CFG_SWITCH, offset, 1);
+}
+
+static int __tb_port_find_cap(struct tb_port *port, enum tb_port_cap cap)
+{
+ u32 offset = 1;
do {
struct tb_cap_any header;
@@ -62,6 +78,30 @@ int tb_port_find_cap(struct tb_port *port, enum tb_port_cap cap)
return -ENOENT;
}
+/**
+ * tb_port_find_cap() - Find port capability
+ * @port: Port to find the capability for
+ * @cap: Capability to look
+ *
+ * Returns offset to start of capability or %-ENOENT if no such
+ * capability was found. Negative errno is returned if there was an
+ * error.
+ */
+int tb_port_find_cap(struct tb_port *port, enum tb_port_cap cap)
+{
+ int ret;
+
+ ret = tb_port_enable_tmu(port, true);
+ if (ret)
+ return ret;
+
+ ret = __tb_port_find_cap(port, cap);
+
+ tb_port_enable_tmu(port, false);
+
+ return ret;
+}
+
static int tb_switch_find_cap(struct tb_switch *sw, enum tb_switch_cap cap)
{
int offset = sw->config.first_cap_offset;
--
2.20.1
^ permalink raw reply related
* [PATCH v2 08/28] thunderbolt: Properly disable path
From: Mika Westerberg @ 2019-02-06 13:17 UTC (permalink / raw)
To: linux-kernel
Cc: Michael Jamet, Yehezkel Bernat, Andreas Noever, Lukas Wunner,
David S . Miller, Mika Westerberg, Andy Shevchenko, netdev
In-Reply-To: <20190206131738.43696-1-mika.westerberg@linux.intel.com>
We need to wait until all buffers have been drained before the path can
be considered disabled. Do this for every hop in a path. Also if the
switch is physically disconnected, do not bother disabling it anymore
(it is not present anyway).
This adds another bit field to struct tb_regs_hop even if we are trying
to get rid of them but we can clean them up another day.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
---
drivers/thunderbolt/path.c | 44 ++++++++++++++++++++++++++++++++---
drivers/thunderbolt/tb_regs.h | 3 ++-
2 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/drivers/thunderbolt/path.c b/drivers/thunderbolt/path.c
index a11956522bac..48cb15ff4446 100644
--- a/drivers/thunderbolt/path.c
+++ b/drivers/thunderbolt/path.c
@@ -7,6 +7,8 @@
#include <linux/slab.h>
#include <linux/errno.h>
+#include <linux/delay.h>
+#include <linux/ktime.h>
#include "tb.h"
@@ -74,13 +76,49 @@ static void __tb_path_deallocate_nfc(struct tb_path *path, int first_hop)
}
}
+static int __tb_path_deactivate_hop(struct tb_port *port, int hop_index)
+{
+ struct tb_regs_hop hop;
+ ktime_t timeout;
+ int ret;
+
+ if (port->sw->is_unplugged)
+ return 0;
+
+ /* Disable the path */
+ ret = tb_port_read(port, &hop, TB_CFG_HOPS, 2 * hop_index, 2);
+ if (ret)
+ return ret;
+
+ hop.enable = 0;
+
+ ret = tb_port_write(port, &hop, TB_CFG_HOPS, 2 * hop_index, 2);
+ if (ret)
+ return ret;
+
+ /* Wait until it is drained */
+ timeout = ktime_add_ms(ktime_get(), 500);
+ do {
+ ret = tb_port_read(port, &hop, TB_CFG_HOPS, 2 * hop_index, 2);
+ if (ret)
+ return ret;
+
+ if (!hop.pending)
+ return 0;
+
+ usleep_range(10, 20);
+ } while (ktime_before(ktime_get(), timeout));
+
+ return -ETIMEDOUT;
+}
+
static void __tb_path_deactivate_hops(struct tb_path *path, int first_hop)
{
int i, res;
- struct tb_regs_hop hop = { };
+
for (i = first_hop; i < path->path_length; i++) {
- res = tb_port_write(path->hops[i].in_port, &hop, TB_CFG_HOPS,
- 2 * path->hops[i].in_hop_index, 2);
+ res = __tb_path_deactivate_hop(path->hops[i].in_port,
+ path->hops[i].in_hop_index);
if (res)
tb_port_warn(path->hops[i].in_port,
"hop deactivation failed for hop %d, index %d\n",
diff --git a/drivers/thunderbolt/tb_regs.h b/drivers/thunderbolt/tb_regs.h
index 1ab6e0fb31c0..82ac4ec8757f 100644
--- a/drivers/thunderbolt/tb_regs.h
+++ b/drivers/thunderbolt/tb_regs.h
@@ -234,7 +234,8 @@ struct tb_regs_hop {
bool egress_fc:1;
bool ingress_shared_buffer:1;
bool egress_shared_buffer:1;
- u32 unknown3:4; /* set to zero */
+ bool pending:1;
+ u32 unknown3:3; /* set to zero */
} __packed;
/* Common link controller registers */
--
2.20.1
^ permalink raw reply related
* [PATCH v2 05/28] thunderbolt: Move LC specific functionality into a separate file
From: Mika Westerberg @ 2019-02-06 13:17 UTC (permalink / raw)
To: linux-kernel
Cc: Michael Jamet, Yehezkel Bernat, Andreas Noever, Lukas Wunner,
David S . Miller, Mika Westerberg, Andy Shevchenko, netdev
In-Reply-To: <20190206131738.43696-1-mika.westerberg@linux.intel.com>
We will be adding more link controller functionality in subsequent
patches and it does not make sense to keep all that in switch.c, so
separate LC functionality into its own file.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
---
drivers/thunderbolt/Makefile | 2 +-
drivers/thunderbolt/lc.c | 21 +++++++++++++++++++++
drivers/thunderbolt/switch.c | 12 +++++++-----
drivers/thunderbolt/tb.h | 3 +++
drivers/thunderbolt/tb_regs.h | 2 ++
5 files changed, 34 insertions(+), 6 deletions(-)
create mode 100644 drivers/thunderbolt/lc.c
diff --git a/drivers/thunderbolt/Makefile b/drivers/thunderbolt/Makefile
index f2f0de27252b..8531f15d3b3c 100644
--- a/drivers/thunderbolt/Makefile
+++ b/drivers/thunderbolt/Makefile
@@ -1,3 +1,3 @@
obj-${CONFIG_THUNDERBOLT} := thunderbolt.o
thunderbolt-objs := nhi.o ctl.o tb.o switch.o cap.o path.o tunnel_pci.o eeprom.o
-thunderbolt-objs += domain.o dma_port.o icm.o property.o xdomain.o
+thunderbolt-objs += domain.o dma_port.o icm.o property.o xdomain.o lc.o
diff --git a/drivers/thunderbolt/lc.c b/drivers/thunderbolt/lc.c
new file mode 100644
index 000000000000..2134a55ed837
--- /dev/null
+++ b/drivers/thunderbolt/lc.c
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Thunderbolt link controller support
+ *
+ * Copyright (C) 2019, Intel Corporation
+ * Author: Mika Westerberg <mika.westerberg@linux.intel.com>
+ */
+
+#include "tb.h"
+
+/**
+ * tb_lc_read_uuid() - Read switch UUID from link controller common register
+ * @sw: Switch whose UUID is read
+ * @uuid: UUID is placed here
+ */
+int tb_lc_read_uuid(struct tb_switch *sw, u32 *uuid)
+{
+ if (!sw->cap_lc)
+ return -EINVAL;
+ return tb_sw_read(sw, uuid, TB_CFG_SWITCH, sw->cap_lc + TB_LC_FUSE, 4);
+}
diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index a90d21abed88..bd96eebd8248 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -1207,6 +1207,10 @@ struct tb_switch *tb_switch_alloc(struct tb *tb, struct device *parent,
}
sw->cap_plug_events = cap;
+ cap = tb_switch_find_vse_cap(sw, TB_VSE_CAP_LINK_CONTROLLER);
+ if (cap > 0)
+ sw->cap_lc = cap;
+
/* Root switch is always authorized */
if (!route)
sw->authorized = true;
@@ -1303,7 +1307,7 @@ int tb_switch_configure(struct tb_switch *sw)
static void tb_switch_set_uuid(struct tb_switch *sw)
{
u32 uuid[4];
- int cap;
+ int ret;
if (sw->uuid)
return;
@@ -1312,10 +1316,8 @@ static void tb_switch_set_uuid(struct tb_switch *sw)
* The newer controllers include fused UUID as part of link
* controller specific registers
*/
- cap = tb_switch_find_vse_cap(sw, TB_VSE_CAP_LINK_CONTROLLER);
- if (cap > 0) {
- tb_sw_read(sw, uuid, TB_CFG_SWITCH, cap + 3, 4);
- } else {
+ ret = tb_lc_read_uuid(sw, uuid);
+ if (ret) {
/*
* ICM generates UUID based on UID and fills the upper
* two words with ones. This is not strictly following
diff --git a/drivers/thunderbolt/tb.h b/drivers/thunderbolt/tb.h
index 5faec5a8eb98..530464b25dcb 100644
--- a/drivers/thunderbolt/tb.h
+++ b/drivers/thunderbolt/tb.h
@@ -63,6 +63,7 @@ struct tb_switch_nvm {
* @device_name: Name of the device (or %NULL if not known)
* @generation: Switch Thunderbolt generation
* @cap_plug_events: Offset to the plug events capability (%0 if not found)
+ * @cap_lc: Offset to the link controller capability (%0 if not found)
* @is_unplugged: The switch is going away
* @drom: DROM of the switch (%NULL if not found)
* @nvm: Pointer to the NVM if the switch has one (%NULL otherwise)
@@ -98,6 +99,7 @@ struct tb_switch {
const char *device_name;
unsigned int generation;
int cap_plug_events;
+ int cap_lc;
bool is_unplugged;
u8 *drom;
struct tb_switch_nvm *nvm;
@@ -448,6 +450,7 @@ bool tb_path_is_invalid(struct tb_path *path);
int tb_drom_read(struct tb_switch *sw);
int tb_drom_read_uid_only(struct tb_switch *sw, u64 *uid);
+int tb_lc_read_uuid(struct tb_switch *sw, u32 *uuid);
static inline int tb_route_length(u64 route)
{
diff --git a/drivers/thunderbolt/tb_regs.h b/drivers/thunderbolt/tb_regs.h
index 6f1ff04ee195..4895ae9f0b40 100644
--- a/drivers/thunderbolt/tb_regs.h
+++ b/drivers/thunderbolt/tb_regs.h
@@ -237,5 +237,7 @@ struct tb_regs_hop {
u32 unknown3:4; /* set to zero */
} __packed;
+/* Common link controller registers */
+#define TB_LC_FUSE 0x03
#endif
--
2.20.1
^ permalink raw reply related
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