* [PATCH net 1/2] iavf: Fix error when changing ring parameters on ice PF
From: Tony Nguyen @ 2022-04-20 17:26 UTC (permalink / raw)
To: davem, kuba, pabeni
Cc: Michal Maloszewski, netdev, anthony.l.nguyen, sassmann,
Sylwester Dziedziuch, Konrad Jankowski
In-Reply-To: <20220420172624.931237-1-anthony.l.nguyen@intel.com>
From: Michal Maloszewski <michal.maloszewski@intel.com>
Reset is triggered when ring parameters are being changed through
ethtool and queues are reconfigured for VF's VSI. If ring is changed
again immediately, then the next reset could be executed before
queues could be properly reinitialized on VF's VSI. It caused ice PF
to mess up the VSI resource tree.
Add a check in iavf_set_ringparam for adapter and VF's queue
state. If VF is currently resetting or queues are disabled for the VF
return with EAGAIN error.
Fixes: d732a1844507 ("i40evf: fix crash when changing ring sizes")
Signed-off-by: Sylwester Dziedziuch <sylwesterx.dziedziuch@intel.com>
Signed-off-by: Michal Maloszewski <michal.maloszewski@intel.com>
Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
drivers/net/ethernet/intel/iavf/iavf_ethtool.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/intel/iavf/iavf_ethtool.c b/drivers/net/ethernet/intel/iavf/iavf_ethtool.c
index 3bb56714beb0..08efbc50fbe9 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_ethtool.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_ethtool.c
@@ -631,6 +631,11 @@ static int iavf_set_ringparam(struct net_device *netdev,
if ((ring->rx_mini_pending) || (ring->rx_jumbo_pending))
return -EINVAL;
+ if (adapter->state == __IAVF_RESETTING ||
+ (adapter->state == __IAVF_RUNNING &&
+ (adapter->flags & IAVF_FLAG_QUEUES_DISABLED)))
+ return -EAGAIN;
+
if (ring->tx_pending > IAVF_MAX_TXD ||
ring->tx_pending < IAVF_MIN_TXD ||
ring->rx_pending > IAVF_MAX_RXD ||
--
2.31.1
^ permalink raw reply related
* [PATCH net 0/2][pull request] Intel Wired LAN Driver Updates 2022-04-20
From: Tony Nguyen @ 2022-04-20 17:26 UTC (permalink / raw)
To: davem, kuba, pabeni; +Cc: Tony Nguyen, netdev, sassmann
This series contains updates to iavf and i40e drivers.
Michal adds a check for down states before changing ring parameters to
avoid possible corruption for iavf.
Xiaomeng Tong prevents possible use of incorrect 'ch' variable by
introducing an interim iterator variable for i40e.
The following are changes since commit 5e6242151d7f17b056a82ca7b860c4ec8eaa7589:
selftests: mlxsw: vxlan_flooding_ipv6: Prevent flooding of unwanted packets
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue 40GbE
Michal Maloszewski (1):
iavf: Fix error when changing ring parameters on ice PF
Xiaomeng Tong (1):
i40e: i40e_main: fix a missing check on list iterator
drivers/net/ethernet/intel/i40e/i40e_main.c | 27 ++++++++++---------
.../net/ethernet/intel/iavf/iavf_ethtool.c | 5 ++++
2 files changed, 19 insertions(+), 13 deletions(-)
--
2.31.1
^ permalink raw reply
* Re: [EXT] EEH Causes bnx2x to Hang in napi_disable
From: David Christensen @ 2022-04-20 17:23 UTC (permalink / raw)
To: Manish Chopra, Netdev, Ariel Elior, Sudarsana Reddy Kalluru
In-Reply-To: <BY3PR18MB4612CB2F82889E5B155BD03EABEE9@BY3PR18MB4612.namprd18.prod.outlook.com>
>> ----------------------------------------------------------------------
>> Experiencing an inaccessible system when bnx2x attempts to recover from an
>> injected EEH error. This is a POWER10 system running SLES 15 SP3
>> (5.3.18-150300.59.49-default) with a BCM57810 dual port NIC.
>>
> Thanks for reporting this issue, I tried to reproduce the same issue where in my case it leaded to system crash but it was not exactly the same
> symptom of hang/stuck in napi_disable(). But I believe they all have the same root cause for different issues as you stated about the incorrect
> sequence of NAPI API usage in this particular driver flow (unlike in regular unload flow (ndo_stop()) where it deletes NAPI after it disables the NAPI).
> So driver actually needs to disable NAPI first and delete the NAPI afterwards, I tried below change which fixed the crash which I was always seeing on
> my setup.
>
> Can you please try this below change to see if that helps for the issue you reported or not ?
Glad to report that it fixed our problem as well. Thanks for the help.
Dave
^ permalink raw reply
* Re: [PATCH bpf-next 00/11] bpf: random unpopular userspace fixes (32 bit et al.)
From: Andrii Nakryiko @ 2022-04-20 17:20 UTC (permalink / raw)
To: Alexander Lobakin
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Mark Rutland, Alexander Shishkin, Jiri Olsa, Namhyung Kim,
Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, David S. Miller, Jakub Kicinski, Jesper Dangaard Brouer,
Björn Töpel, Magnus Karlsson, Jonathan Lemon,
Nathan Chancellor, Nick Desaulniers, Dmitrii Dolgov,
Quentin Monnet, Tiezhu Yang, Kumar Kartikeya Dwivedi, Chenbo Feng,
Willem de Bruijn, Daniel Wagner, Thomas Graf, Ong Boon Leong,
linux-perf-use., open list, Networking, bpf, llvm
In-Reply-To: <20220414223704.341028-1-alobakin@pm.me>
On Thu, Apr 14, 2022 at 3:44 PM Alexander Lobakin <alobakin@pm.me> wrote:
>
> This mostly issues the cross build (1) errors for 32 bit (2)
> MIPS (3) with minimal configuration (4) on Musl (5). The majority
> of them aren't yesterday's, so it is a "who does need it outside
> of x86_64 or ARM64?" moment again.
> Trivial stuff in general, not counting the bpf_cookie build fix.
>
> Alexander Lobakin (11):
> bpf, perf: fix bpftool compilation with !CONFIG_PERF_EVENTS
> bpf: always emit struct bpf_perf_link BTF
> tools, bpf: fix bpftool build with !CONFIG_BPF_EVENTS
> samples: bpf: add 'asm/mach-generic' include path for every MIPS
> samples: bpf: use host bpftool to generate vmlinux.h, not target
> tools, bpf: fix fcntl.h include in bpftool
> samples: bpf: fix uin64_t format literals
> samples: bpf: fix shifting unsigned long by 32 positions
> samples: bpf: fix include order for non-Glibc environments
> samples: bpf: fix -Wsequence-point
> samples: bpf: xdpsock: fix -Wmaybe-uninitialized
>
For consistency with majority of other commits, can you please use
"samples/bpf: " prefix for samples/bpf changes and "bpftool: " for
bpftool's ones? Thanks!
> include/linux/perf_event.h | 2 ++
> kernel/bpf/syscall.c | 4 +++-
> samples/bpf/Makefile | 7 ++++---
> samples/bpf/cookie_uid_helper_example.c | 12 ++++++------
> samples/bpf/lathist_kern.c | 2 +-
> samples/bpf/lwt_len_hist_kern.c | 2 +-
> samples/bpf/lwt_len_hist_user.c | 4 ++--
> samples/bpf/task_fd_query_user.c | 2 +-
> samples/bpf/test_lru_dist.c | 3 ++-
> samples/bpf/tracex2_kern.c | 2 +-
> samples/bpf/xdpsock_user.c | 5 +++--
> tools/bpf/bpftool/tracelog.c | 2 +-
> 12 files changed, 27 insertions(+), 20 deletions(-)
>
> --
> 2.35.2
>
>
^ permalink raw reply
* Re: [PATCH bpf-next 08/11] samples: bpf: fix shifting unsigned long by 32 positions
From: Andrii Nakryiko @ 2022-04-20 17:18 UTC (permalink / raw)
To: Alexander Lobakin, Yonghong Song
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Mark Rutland, Alexander Shishkin, Jiri Olsa, Namhyung Kim,
Martin KaFai Lau, Song Liu, John Fastabend, KP Singh,
David S. Miller, Jakub Kicinski, Jesper Dangaard Brouer,
Björn Töpel, Magnus Karlsson, Jonathan Lemon,
Nathan Chancellor, Nick Desaulniers, Dmitrii Dolgov,
Quentin Monnet, Tiezhu Yang, Kumar Kartikeya Dwivedi, Chenbo Feng,
Willem de Bruijn, Daniel Wagner, Thomas Graf, Ong Boon Leong,
linux-perf-use., open list, Networking, bpf, llvm
In-Reply-To: <20220414223704.341028-9-alobakin@pm.me>
On Thu, Apr 14, 2022 at 3:46 PM Alexander Lobakin <alobakin@pm.me> wrote:
>
> On 32 bit systems, shifting an unsigned long by 32 positions
> yields the following warning:
>
> samples/bpf/tracex2_kern.c:60:23: warning: shift count >= width of type [-Wshift-count-overflow]
> unsigned int hi = v >> 32;
> ^ ~~
>
long is always 64-bit in BPF, but I suspect this is due to
samples/bpf/Makefile still using this clang + llc combo, where clang
is called with native target and llc for -target bpf. Not sure if we
are ready to ditch that complicated combination. Yonghong, do we still
need that or can we just use -target bpf in samples/bpf?
> The usual way to avoid this is to shift by 16 two times (see
> upper_32_bits() macro in the kernel). Use it across the BPF sample
> code as well.
>
> Fixes: d822a1926849 ("samples/bpf: Add counting example for kfree_skb() function calls and the write() syscall")
> Fixes: 0fb1170ee68a ("bpf: BPF based latency tracing")
> Fixes: f74599f7c530 ("bpf: Add tests and samples for LWT-BPF")
> Signed-off-by: Alexander Lobakin <alobakin@pm.me>
> ---
> samples/bpf/lathist_kern.c | 2 +-
> samples/bpf/lwt_len_hist_kern.c | 2 +-
> samples/bpf/tracex2_kern.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
[...]
^ permalink raw reply
* Re: [PATCH bpf-next 07/11] samples: bpf: fix uin64_t format literals
From: Andrii Nakryiko @ 2022-04-20 17:14 UTC (permalink / raw)
To: Alexander Lobakin
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Mark Rutland, Alexander Shishkin, Jiri Olsa, Namhyung Kim,
Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, David S. Miller, Jakub Kicinski, Jesper Dangaard Brouer,
Björn Töpel, Magnus Karlsson, Jonathan Lemon,
Nathan Chancellor, Nick Desaulniers, Dmitrii Dolgov,
Quentin Monnet, Tiezhu Yang, Kumar Kartikeya Dwivedi, Chenbo Feng,
Willem de Bruijn, Daniel Wagner, Thomas Graf, Ong Boon Leong,
linux-perf-use., open list, Networking, bpf, llvm
In-Reply-To: <20220414223704.341028-8-alobakin@pm.me>
On Thu, Apr 14, 2022 at 3:46 PM Alexander Lobakin <alobakin@pm.me> wrote:
>
> There's a couple places where uin64_t is being passed as an %ld
> format argument, which is incorrect (should be %lld). Fix them.
It depends on architecture, on some it will be %lu, on some it will be
%llu. But instead of PRIu64, just cast it to size_t and use %zu as
formatter
>
> Fixes: 51570a5ab2b7 ("A Sample of using socket cookie and uid for traffic monitoring")
> Fixes: 00f660eaf378 ("Sample program using SO_COOKIE")
> Signed-off-by: Alexander Lobakin <alobakin@pm.me>
> ---
> samples/bpf/cookie_uid_helper_example.c | 12 ++++++------
> samples/bpf/lwt_len_hist_user.c | 4 ++--
> 2 files changed, 8 insertions(+), 8 deletions(-)
>
[...]
^ permalink raw reply
* Re: [PATCH bpf-next 03/11] tools, bpf: fix bpftool build with !CONFIG_BPF_EVENTS
From: Andrii Nakryiko @ 2022-04-20 17:12 UTC (permalink / raw)
To: Alexander Lobakin
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Mark Rutland, Alexander Shishkin, Jiri Olsa, Namhyung Kim,
Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, David S. Miller, Jakub Kicinski, Jesper Dangaard Brouer,
Björn Töpel, Magnus Karlsson, Jonathan Lemon,
Nathan Chancellor, Nick Desaulniers, Dmitrii Dolgov,
Quentin Monnet, Tiezhu Yang, Kumar Kartikeya Dwivedi, Chenbo Feng,
Willem de Bruijn, Daniel Wagner, Thomas Graf, Ong Boon Leong,
linux-perf-use., open list, Networking, bpf, llvm
In-Reply-To: <20220414223704.341028-4-alobakin@pm.me>
On Thu, Apr 14, 2022 at 3:45 PM Alexander Lobakin <alobakin@pm.me> wrote:
>
> Fix the following error when building bpftool:
>
> CLANG profiler.bpf.o
> CLANG pid_iter.bpf.o
> skeleton/profiler.bpf.c:18:21: error: invalid application of 'sizeof' to an incomplete type 'struct bpf_perf_event_value'
> __uint(value_size, sizeof(struct bpf_perf_event_value));
> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> tools/bpf/bpftool/bootstrap/libbpf/include/bpf/bpf_helpers.h:13:39: note: expanded from macro '__uint'
> ^~~
> tools/bpf/bpftool/bootstrap/libbpf/include/bpf/bpf_helper_defs.h:7:8: note: forward declaration of 'struct bpf_perf_event_value'
> struct bpf_perf_event_value;
> ^
>
> struct bpf_perf_event_value is being used in the kernel only when
> CONFIG_BPF_EVENTS is enabled, so it misses a BTF entry then.
> Emit the type unconditionally to fix the problem.
>
> Fixes: 47c09d6a9f67 ("bpftool: Introduce "prog profile" command")
> Signed-off-by: Alexander Lobakin <alobakin@pm.me>
> ---
> kernel/bpf/syscall.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 34fdf27d14cf..dd8284a60a8e 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -4286,6 +4286,7 @@ static int link_create(union bpf_attr *attr, bpfptr_t uattr)
> goto out;
> case BPF_PROG_TYPE_PERF_EVENT:
> case BPF_PROG_TYPE_TRACEPOINT:
> + BTF_TYPE_EMIT(struct bpf_perf_event_value);
same as for previous two patches, if there are types that bpftool
expects and might not be in vmlinux.h due to different kernel
configurations, it's cleaner to just define their minimal local
definitions with __attribute__((preserve_access_index))
> if (attr->link_create.attach_type != BPF_PERF_EVENT) {
> ret = -EINVAL;
> goto out;
> --
> 2.35.2
>
>
^ permalink raw reply
* Re: [PATCH v2] bpf: Fix KASAN use-after-free Read in compute_effective_progs
From: Andrii Nakryiko @ 2022-04-20 17:07 UTC (permalink / raw)
To: Tadeusz Struk
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Networking, bpf, linux- stable, open list,
syzbot+f264bffdfbd5614f3bb2
In-Reply-To: <20220415141355.4329-1-tadeusz.struk@linaro.org>
On Fri, Apr 15, 2022 at 7:14 AM Tadeusz Struk <tadeusz.struk@linaro.org> wrote:
>
> Syzbot found a Use After Free bug in compute_effective_progs().
> The reproducer creates a number of BPF links, and causes a fault
> injected alloc to fail, while calling bpf_link_detach on them.
> Link detach triggers the link to be freed by bpf_link_free(),
> which calls __cgroup_bpf_detach() and update_effective_progs().
> If the memory allocation in this function fails, the function restores
> the pointer to the bpf_cgroup_link on the cgroup list, but the memory
> gets freed just after it returns. After this, every subsequent call to
> update_effective_progs() causes this already deallocated pointer to be
> dereferenced in prog_list_length(), and triggers KASAN UAF error.
>
> To fix this issue don't preserve the pointer to the prog or link in the
> list, but remove it and rearrange the effective table without
> shrinking it. The subsequent call to __cgroup_bpf_detach() or
> __cgroup_bpf_detach() will correct it.
>
> Cc: "Alexei Starovoitov" <ast@kernel.org>
> Cc: "Daniel Borkmann" <daniel@iogearbox.net>
> Cc: "Andrii Nakryiko" <andrii@kernel.org>
> Cc: "Martin KaFai Lau" <kafai@fb.com>
> Cc: "Song Liu" <songliubraving@fb.com>
> Cc: "Yonghong Song" <yhs@fb.com>
> Cc: "John Fastabend" <john.fastabend@gmail.com>
> Cc: "KP Singh" <kpsingh@kernel.org>
> Cc: <netdev@vger.kernel.org>
> Cc: <bpf@vger.kernel.org>
> Cc: <stable@vger.kernel.org>
> Cc: <linux-kernel@vger.kernel.org>
>
> Link: https://syzkaller.appspot.com/bug?id=8ebf179a95c2a2670f7cf1ba62429ec044369db4
> Fixes: af6eea57437a ("bpf: Implement bpf_link-based cgroup BPF program attachment")
> Reported-by: <syzbot+f264bffdfbd5614f3bb2@syzkaller.appspotmail.com>
> Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
> ---
> v2: Add a fall back path that removes a prog from the effective progs
> table in case detach fails to allocate memory in compute_effective_progs().
> ---
> kernel/bpf/cgroup.c | 55 +++++++++++++++++++++++++++++++++++++++------
> 1 file changed, 48 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
> index 128028efda64..5a64cece09f3 100644
> --- a/kernel/bpf/cgroup.c
> +++ b/kernel/bpf/cgroup.c
> @@ -723,10 +723,8 @@ static int __cgroup_bpf_detach(struct cgroup *cgrp, struct bpf_prog *prog,
> pl->link = NULL;
>
> err = update_effective_progs(cgrp, atype);
> - if (err)
> - goto cleanup;
>
> - /* now can actually delete it from this cgroup list */
> + /* now can delete it from this cgroup list */
> list_del(&pl->node);
> kfree(pl);
> if (list_empty(progs))
> @@ -735,12 +733,55 @@ static int __cgroup_bpf_detach(struct cgroup *cgrp, struct bpf_prog *prog,
> if (old_prog)
> bpf_prog_put(old_prog);
> static_branch_dec(&cgroup_bpf_enabled_key[atype]);
> - return 0;
> +
> + if (!err)
> + return 0;
>
> cleanup:
> - /* restore back prog or link */
> - pl->prog = old_prog;
> - pl->link = link;
> + /*
> + * If compute_effective_progs failed with -ENOMEM, i.e. alloc for
> + * cgrp->bpf.inactive table failed, we can recover by removing
> + * the detached prog from effective table and rearranging it.
> + */
> + if (err == -ENOMEM) {
> + struct bpf_prog_array_item *item;
> + struct bpf_prog *prog_tmp, *prog_detach, *prog_last;
> + struct bpf_prog_array *array;
> + int index = 0, index_detach = -1;
> +
> + array = cgrp->bpf.effective[atype];
> + item = &array->items[0];
> +
> + if (prog)
> + prog_detach = prog;
> + else
> + prog_detach = link->link.prog;
> +
> + if (!prog_detach)
> + return -EINVAL;
> +
> + while ((prog_tmp = READ_ONCE(item->prog))) {
> + if (prog_tmp == prog_detach)
> + index_detach = index;
> + item++;
> + index++;
> + prog_last = prog_tmp;
> + }
> +
> + /* Check if we found what's needed for removing the prog */
> + if (index_detach == -1 || index_detach == index-1)
> + return -EINVAL;
> +
> + /* Remove the last program in the array */
> + if (bpf_prog_array_delete_safe_at(array, index-1))
> + return -EINVAL;
> +
> + /* and update the detached with the last just removed */
> + if (bpf_prog_array_update_at(array, index_detach, prog_last))
> + return -EINVAL;
> +
> + err = 0;
> + }
There are a bunch of problems with this implementation.
1. We should do this fallback right after update_effective_progs()
returns error, before we get to list_del(&pl->node) and subsequent
code that does some additional things (like clearing flags and stuff).
This additional code needs to run even if update_effective_progs()
fails. So I suggest to extract the logic of removing program from
effective prog arrays into a helper function and doing
err = update_effective_progs(...);
if (err)
purge_effective_progs();
where purge_effective_progs() will be the logic you are adding. And it
will be void function because it can't fail.
2. We have to update not just cgrp->bpf.effective array, but all the
descendants' lists as well. See what update_effective_progs() is
doing, it has css_for_each_descendant_pre() iteration. You need to do
it here as well. But instead of doing compute_effective_progs() which
allocates a new copy of an array we'll need to update existing array
in place.
3. Not clear why you need to do both bpf_prog_array_delete_safe_at()
and bpf_prog_array_update_at(), isn't delete_safe_at() enought?
> return err;
> }
>
> --
> 2.35.1
>
^ permalink raw reply
* IPv6 multicast with VRF
From: Vladimir Oltean @ 2022-04-20 16:54 UTC (permalink / raw)
To: David Ahern; +Cc: netdev
Hi,
I don't have experience with either IPv6 multicast or VRF, yet I need to
send some IPv6 multicast packets from a device enslaved to a VRF, and I
don't really know what's wrong with the routing table setup.
The system is configured in the following way:
ip link set dev eth0 up
# The kernel kindly creates a ff00::/8 route for IPv6 multicast traffic
# in the local table, and I think this is what makes multicast route
# lookups find the egress device.
ip -6 route show table local
local ::1 dev lo proto kernel metric 0 pref medium
local fe80::204:9fff:fe05:f4ab dev eth0 proto kernel metric 0 pref medium
multicast ff00::/8 dev eth0 proto kernel metric 256 pref medium
ip -6 route get ff02::1
multicast ff02::1 dev eth0 table local proto kernel src fe80::204:9fff:fe05:f4ab metric 256 pref medium
ip link add dev vrf0 type vrf table 3 && ip link set dev vrf0 up
ip -4 route add table 3 unreachable default metric 4278198272
ip -6 route add table 3 unreachable default metric 4278198272
ip link set dev eth0 master vrf0
The problem seems to be that, although the "ff00::/8 dev eth0" route
migrates from table 255 to table 3, route lookups after this point fail
to find it and return -ENETUNREACH (ip6_null_entry).
ip -6 route show table local
local ::1 dev lo proto kernel metric 0 pref medium
ip -6 route show table main
::1 dev lo proto kernel metric 256 pref medium
ip -6 route show table 3
local fe80::204:9fff:fe05:f4ab dev eth0 proto kernel metric 0 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
multicast ff00::/8 dev eth0 proto kernel metric 256 pref medium
unreachable default dev lo metric 4278198272 pref medium
ip -6 route get ff02::1
RTNETLINK answers: Network is unreachable
ip -6 route get vrf vrf0 ff02::1
RTNETLINK answers: Network is unreachable
I'm not exactly sure what is missing?
^ permalink raw reply
* Re: [PATCH] wfx: use container_of() to get vif
From: Fabio M. De Francesco @ 2022-04-20 16:53 UTC (permalink / raw)
To: Jaehee Park, Kalle Valo
Cc: Jérôme Pouiller, David S. Miller, Jakub Kicinski,
Paolo Abeni, linux-wireless, netdev, linux-kernel, linux-staging,
outreachy, Stefano Brivio
In-Reply-To: <87y200nf0a.fsf@kernel.org>
On mercoledì 20 aprile 2022 13:57:57 CEST Kalle Valo wrote:
> Jaehee Park <jhpark1013@gmail.com> writes:
>
> > Currently, upon virtual interface creation, wfx_add_interface() stores
> > a reference to the corresponding struct ieee80211_vif in private data,
> > for later usage. This is not needed when using the container_of
> > construct. This construct already has all the info it needs to retrieve
> > the reference to the corresponding struct from the offset that is
> > already available, inherent in container_of(), between its type and
> > member inputs (struct ieee80211_vif and drv_priv, respectively).
> > Remove vif (which was previously storing the reference to the struct
> > ieee80211_vif) from the struct wfx_vif, define a function
> > wvif_to_vif(wvif) for container_of(), and replace all wvif->vif with
> > the newly defined container_of construct.
> >
> > Signed-off-by: Jaehee Park <jhpark1013@gmail.com>
>
> [...]
>
> > +static inline struct ieee80211_vif *wvif_to_vif(struct wfx_vif *wvif)
> > +{
> > + return container_of((void *)wvif, struct ieee80211_vif,
drv_priv);
> > +}
>
> Why the void pointer cast? Avoid casts as much possible.
In a previous email Jaehee wrote that she could compile her changes only by
using that "(void *)" cast.
I replied that probably this is a hint that something is broken, although
my argument is not necessarily a "proof". Might very well be that this cast
was needed in this particular situation but I cannot see why.
@Jaehee, please try to explain why this "(void *)" cast is actually
necessary and why your changes cannot avoid it.
Thanks,
Fabio M. De Francesco
^ permalink raw reply
* [PATCH bpf] lwt_bpf: fix crash when using bpf_skb_set_tunnel_key() from bpf_xmit lwt hook
From: Eyal Birger @ 2022-04-20 16:52 UTC (permalink / raw)
To: davem, kuba, pabeni, ast, daniel, andrii
Cc: kafai, songliubraving, yhs, john.fastabend, kpsingh, mkl, tgraf,
shmulik.ladkani, netdev, bpf, Eyal Birger, stable
xmit_check_hhlen() observes the dst for getting the device hard header
length to make sure a modified packet can fit. When a helper which changes
the dst - such as bpf_skb_set_tunnel_key() - is called as part of the xmit
program the accessed dst is no longer valid.
This leads to the following splat:
BUG: kernel NULL pointer dereference, address: 00000000000000de
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 0 PID: 798 Comm: ping Not tainted 5.18.0-rc2+ #103
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
RIP: 0010:bpf_xmit+0xfb/0x17f
Code: c6 c0 4d cd 8e 48 c7 c7 7d 33 f0 8e e8 42 09 fb ff 48 8b 45 58 48 8b 95 c8 00 00 00 48 2b 95 c0 00 00 00 48 83 e0 fe 48 8b 00 <0f> b7 80 de 00 00 00 39 c2 73 22 29 d0 b9 20 0a 00 00 31 d2 48 89
RSP: 0018:ffffb148c0bc7b98 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000240008 RCX: 0000000000000000
RDX: 0000000000000010 RSI: 00000000ffffffea RDI: 00000000ffffffff
RBP: ffff922a828a4e00 R08: ffffffff8f1350e8 R09: 00000000ffffdfff
R10: ffffffff8f055100 R11: ffffffff8f105100 R12: 0000000000000000
R13: ffff922a828a4e00 R14: 0000000000000040 R15: 0000000000000000
FS: 00007f414e8f0080(0000) GS:ffff922afdc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000de CR3: 0000000002d80006 CR4: 0000000000370ef0
Call Trace:
<TASK>
lwtunnel_xmit.cold+0x71/0xc8
ip_finish_output2+0x279/0x520
? __ip_finish_output.part.0+0x21/0x130
Fix by fetching the device hard header length before running the bpf code.
Cc: stable@vger.kernel.org
Fixes: commit 3a0af8fd61f9 ("bpf: BPF for lightweight tunnel infrastructure")
Signed-off-by: Eyal Birger <eyal.birger@gmail.com>
---
net/core/lwt_bpf.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/net/core/lwt_bpf.c b/net/core/lwt_bpf.c
index 349480ef68a5..8b6b5e72b217 100644
--- a/net/core/lwt_bpf.c
+++ b/net/core/lwt_bpf.c
@@ -159,10 +159,8 @@ static int bpf_output(struct net *net, struct sock *sk, struct sk_buff *skb)
return dst->lwtstate->orig_output(net, sk, skb);
}
-static int xmit_check_hhlen(struct sk_buff *skb)
+static int xmit_check_hhlen(struct sk_buff *skb, int hh_len)
{
- int hh_len = skb_dst(skb)->dev->hard_header_len;
-
if (skb_headroom(skb) < hh_len) {
int nhead = HH_DATA_ALIGN(hh_len - skb_headroom(skb));
@@ -274,6 +272,7 @@ static int bpf_xmit(struct sk_buff *skb)
bpf = bpf_lwt_lwtunnel(dst->lwtstate);
if (bpf->xmit.prog) {
+ int hh_len = dst->dev->hard_header_len;
__be16 proto = skb->protocol;
int ret;
@@ -291,7 +290,7 @@ static int bpf_xmit(struct sk_buff *skb)
/* If the header was expanded, headroom might be too
* small for L2 header to come, expand as needed.
*/
- ret = xmit_check_hhlen(skb);
+ ret = xmit_check_hhlen(skb, hh_len);
if (unlikely(ret))
return ret;
--
2.32.0
^ permalink raw reply related
* Re: [net-next v1] bpf: add bpf_ktime_get_real_ns helper
From: Toke Høiland-Jørgensen @ 2022-04-20 16:26 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Networking, bpf, Tonghao Zhang, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Jiri Olsa,
Dave Marchevsky, Kuniyuki Iwashima, Joanne Koong, Geliang Tang,
David S. Miller, Jakub Kicinski, Eric Dumazet
In-Reply-To: <CAEf4Bzafe3Am5uep7erd7r+-pgdGRc9hsJASYfFH47ty8x9mTA@mail.gmail.com>
Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
> On Wed, Apr 20, 2022 at 5:53 AM Toke Høiland-Jørgensen <toke@kernel.org> wrote:
>>
>> xiangxia.m.yue@gmail.com writes:
>>
>> > From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>> >
>> > This patch introduce a new bpf_ktime_get_real_ns helper, which may
>> > help us to measure the skb latency in the ingress/forwarding path:
>> >
>> > HW/SW[1] -> ip_rcv/tcp_rcv_established -> tcp_recvmsg_locked/tcp_update_recv_tstamps
>> >
>> > * Insert BPF kprobe into ip_rcv/tcp_rcv_established invoking this helper.
>> > Then we can inspect how long time elapsed since HW/SW.
>> > * If inserting BPF kprobe tcp_update_recv_tstamps invoked by tcp_recvmsg,
>> > we can measure how much latency skb in tcp receive queue. The reason for
>> > this can be application fetch the TCP messages too late.
>>
>> Why not just use one of the existing ktime helpers and also add a BPF
>> probe to set the initial timestamp instead of relying on skb->tstamp?
>>
>
> You don't even need a BPF probe for this. See [0] for how retsnoop is
> converting bpf_ktime_get_ns() into real time.
>
> [0] https://github.com/anakryiko/retsnoop/blob/master/src/retsnoop.c#L649-L668
Uh, neat! Thanks for the link :)
-Toke
^ permalink raw reply
* Re: [PATCH v8 08/13] dt-bindings: arm: Document i.MX8DXL EVK board binding
From: Rob Herring @ 2022-04-20 16:24 UTC (permalink / raw)
To: Abel Vesa
Cc: Ulf Hansson, Shawn Guo, netdev, NXP Linux Team,
Linux Kernel Mailing List, linux-mmc, Sascha Hauer,
Pengutronix Kernel Team, linux-arm-kernel, Krzysztof Kozlowski,
devicetree, Fabio Estevam
In-Reply-To: <20220419113516.1827863-9-abel.vesa@nxp.com>
On Tue, 19 Apr 2022 14:35:11 +0300, Abel Vesa wrote:
> Document devicetree binding of i.XM8DXL EVK board.
i.XM?
>
> Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
> ---
> Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [net-next v1] bpf: add bpf_ktime_get_real_ns helper
From: Andrii Nakryiko @ 2022-04-20 16:17 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Networking, bpf, Tonghao Zhang, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Jiri Olsa,
Dave Marchevsky, Kuniyuki Iwashima, Joanne Koong, Geliang Tang,
David S. Miller, Jakub Kicinski, Eric Dumazet
In-Reply-To: <878rrzj4r6.fsf@toke.dk>
On Wed, Apr 20, 2022 at 5:53 AM Toke Høiland-Jørgensen <toke@kernel.org> wrote:
>
> xiangxia.m.yue@gmail.com writes:
>
> > From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> >
> > This patch introduce a new bpf_ktime_get_real_ns helper, which may
> > help us to measure the skb latency in the ingress/forwarding path:
> >
> > HW/SW[1] -> ip_rcv/tcp_rcv_established -> tcp_recvmsg_locked/tcp_update_recv_tstamps
> >
> > * Insert BPF kprobe into ip_rcv/tcp_rcv_established invoking this helper.
> > Then we can inspect how long time elapsed since HW/SW.
> > * If inserting BPF kprobe tcp_update_recv_tstamps invoked by tcp_recvmsg,
> > we can measure how much latency skb in tcp receive queue. The reason for
> > this can be application fetch the TCP messages too late.
>
> Why not just use one of the existing ktime helpers and also add a BPF
> probe to set the initial timestamp instead of relying on skb->tstamp?
>
You don't even need a BPF probe for this. See [0] for how retsnoop is
converting bpf_ktime_get_ns() into real time.
[0] https://github.com/anakryiko/retsnoop/blob/master/src/retsnoop.c#L649-L668
> -Toke
^ permalink raw reply
* Re: [PATCH 0/1] add support for enum module parameters
From: Ben Greear @ 2022-04-20 15:35 UTC (permalink / raw)
To: Kalle Valo, Jani Nikula
Cc: Greg Kroah-Hartman, linux-kernel, intel-gfx, dri-devel,
Andrew Morton, Lucas De Marchi, linux-wireless, netdev
In-Reply-To: <87sfq8qqus.fsf@tynnyri.adurom.net>
On 4/19/22 10:13 PM, Kalle Valo wrote:
> + linux-wireless, netdev
>
> Jani Nikula <jani.nikula@intel.com> writes:
>
>> On Thu, 14 Apr 2022, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>>> On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
>>>> Hey, I've sent this before, ages ago, but haven't really followed
>>>> through with it. I still think it would be useful for many scenarios
>>>> where a plain number is a clumsy interface for a module param.
>>>>
>>>> Thoughts?
>>>
>>> We should not be adding new module parameters anyway (they operate on
>>> code, not data/devices), so what would this be used for?
>>
>> I think it's just easier to use names than random values, and this also
>> gives you range check on the input.
>>
>> I also keep telling people not to add new module parameters, but it's
>> not like they're going away anytime soon.
>>
>> If there's a solution to being able to pass device specific debug
>> parameters at probe time, I'm all ears. At least i915 has a bunch of
>> things which can't really be changed after probe, when debugfs for the
>> device is around. Module parameters aren't ideal, but debugfs doesn't
>> work for this.
>
> Wireless drivers would also desperately need to pass device specific
> parameters at (or before) probe time. And not only debug parameters but
> also configuration parameters, for example firmware memory allocations
> schemes (optimise for features vs number of clients etc) and whatnot.
>
> Any ideas how to implement that? Is there any prior work for anything
> like this? This is pretty hard limiting usability of upstream wireless
> drivers and I really want to find a proper solution.
I used a 'fwcfg' file that is loaded during ath10k initialization, from
same general location as the firmware. Name is with pci-id or other unique
identifier like board files sometimes are named, and you get per radio
configuration at device load time. I'm sure I posted a patch on this
some years ago, but I can point you to my current tree if you prefer.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v3 net-next] dt-bindings: net: mediatek,net: convert to the json-schema
From: Rob Herring @ 2022-04-20 15:31 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: devicetree, pabeni, netdev, lorenzo.bianconi, davem, kuba, john,
nbd
In-Reply-To: <6b417ab35163bd8a4bef4bd38cf46d777925bd26.1650463289.git.lorenzo@kernel.org>
On Wed, 20 Apr 2022 16:07:07 +0200, Lorenzo Bianconi wrote:
> This patch converts the existing mediatek-net.txt binding file
> in yaml format.
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> Changes since v2:
> - remove additionalItems for clock-names properties
> - move mediatek,sgmiisys definition out of the if block
>
> Changes since v1:
> - set resets maxItems to 3
> - fix cci-control-port usage in example
>
> This patch is based on commits [0] and [1] available in net-next tree but not
> in Linus's one yet.
>
> [0] 1dafd0d60703 ("dt-bindings: net: mediatek: add optional properties for the SoC ethernet core")
> [1] 4263f77a5144 ("net: ethernet: mtk_eth_soc: use standard property for cci-control-port")
> ---
> .../devicetree/bindings/net/mediatek,net.yaml | 297 ++++++++++++++++++
> .../devicetree/bindings/net/mediatek-net.txt | 108 -------
> 2 files changed, 297 insertions(+), 108 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/mediatek,net.yaml
> delete mode 100644 Documentation/devicetree/bindings/net/mediatek-net.txt
>
Assuming this passes 'make dt_binding_check' as I haven't run it:
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] net: ethernet: stmmac: fix write to sgmii_adapter_base
From: Dinh Nguyen @ 2022-04-20 15:23 UTC (permalink / raw)
To: davem; +Cc: dinguyen, netdev, linux-kernel, linux-stable
I made a mistake with the commit a6aaa0032424 ("net: ethernet: stmmac:
fix altr_tse_pcs function when using a fixed-link"). I should have
tested against both scenario of having a SGMII interface and one
without.
Without the SGMII PCS TSE adpater, the sgmii_adapter_base address is
NULL, thus a write to this address will fail.
Fixes: a6aaa0032424 ("net: ethernet: stmmac: fix altr_tse_pcs function when using a fixed-link")
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index ac9e6c7a33b5..6b447d8f0bd8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -65,8 +65,9 @@ static void socfpga_dwmac_fix_mac_speed(void *priv, unsigned int speed)
struct phy_device *phy_dev = ndev->phydev;
u32 val;
- writew(SGMII_ADAPTER_DISABLE,
- sgmii_adapter_base + SGMII_ADAPTER_CTRL_REG);
+ if (sgmii_adapter_base)
+ writew(SGMII_ADAPTER_DISABLE,
+ sgmii_adapter_base + SGMII_ADAPTER_CTRL_REG);
if (splitter_base) {
val = readl(splitter_base + EMAC_SPLITTER_CTRL_REG);
@@ -88,10 +89,11 @@ static void socfpga_dwmac_fix_mac_speed(void *priv, unsigned int speed)
writel(val, splitter_base + EMAC_SPLITTER_CTRL_REG);
}
- writew(SGMII_ADAPTER_ENABLE,
- sgmii_adapter_base + SGMII_ADAPTER_CTRL_REG);
- if (phy_dev)
+ if (phy_dev && sgmii_adapter_base) {
+ writew(SGMII_ADAPTER_ENABLE,
+ sgmii_adapter_base + SGMII_ADAPTER_CTRL_REG);
tse_pcs_fix_mac_speed(&dwmac->pcs, phy_dev, speed);
+ }
}
static int socfpga_dwmac_parse_data(struct socfpga_dwmac *dwmac, struct device *dev)
--
2.25.1
^ permalink raw reply related
* [Patch net-next v3 2/2] MAINTAINERS: Add maintainers for Microchip T1 Phy driver
From: Arun Ramadoss @ 2022-04-20 15:20 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: Paolo Abeni, Jakub Kicinski, David S. Miller, Russell King,
Heiner Kallweit, Andrew Lunn, UNGLinuxDriver, Arun Ramadoss
In-Reply-To: <20220420152016.9680-1-arun.ramadoss@microchip.com>
Signed-off-by: Arun Ramadoss <arun.ramadoss@microchip.com>
---
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 25d2a5d417bc..1adf2cac1865 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12920,6 +12920,13 @@ F: drivers/net/dsa/microchip/*
F: include/linux/platform_data/microchip-ksz.h
F: net/dsa/tag_ksz.c
+MICROCHIP LAN87xx/LAN937x T1 PHY DRIVER
+M: Arun Ramadoss <arun.ramadoss@microchip.com>
+R: UNGLinuxDriver@microchip.com
+L: netdev@vger.kernel.org
+S: Maintained
+F: drivers/net/phy/microchip_t1.c
+
MICROCHIP LAN743X ETHERNET DRIVER
M: Bryan Whitehead <bryan.whitehead@microchip.com>
M: UNGLinuxDriver@microchip.com
--
2.33.0
^ permalink raw reply related
* [Patch net-next v3 1/2] net: phy: LAN87xx: add ethtool SQI support
From: Arun Ramadoss @ 2022-04-20 15:20 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: Paolo Abeni, Jakub Kicinski, David S. Miller, Russell King,
Heiner Kallweit, Andrew Lunn, UNGLinuxDriver, Arun Ramadoss
In-Reply-To: <20220420152016.9680-1-arun.ramadoss@microchip.com>
This patch add the support for measuring Signal Quality Index for
LAN87xx and LAN937x T1 Phy. It uses the SQI Method 5 for obtaining the
values.
Signed-off-by: Arun Ramadoss <arun.ramadoss@microchip.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/phy/microchip_t1.c | 48 ++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/drivers/net/phy/microchip_t1.c b/drivers/net/phy/microchip_t1.c
index 3f79bbbe62d3..54f1fab9d8f8 100644
--- a/drivers/net/phy/microchip_t1.c
+++ b/drivers/net/phy/microchip_t1.c
@@ -68,7 +68,12 @@
#define T1_POST_LCK_MUFACT_CFG_REG 0x1C
#define T1_TX_RX_FIFO_CFG_REG 0x02
#define T1_TX_LPF_FIR_CFG_REG 0x55
+#define T1_COEF_CLK_PWR_DN_CFG 0x04
+#define T1_COEF_RW_CTL_CFG 0x0D
#define T1_SQI_CONFIG_REG 0x2E
+#define T1_SQI_CONFIG2_REG 0x4A
+#define T1_DCQ_SQI_REG 0xC3
+#define T1_DCQ_SQI_MSK GENMASK(3, 1)
#define T1_MDIO_CONTROL2_REG 0x10
#define T1_INTERRUPT_SOURCE_REG 0x18
#define T1_INTERRUPT2_SOURCE_REG 0x08
@@ -82,6 +87,9 @@
#define T1_MODE_STAT_REG 0x11
#define T1_LINK_UP_MSK BIT(0)
+/* SQI defines */
+#define LAN87XX_MAX_SQI 0x07
+
#define DRIVER_AUTHOR "Nisar Sayed <nisar.sayed@microchip.com>"
#define DRIVER_DESC "Microchip LAN87XX/LAN937x T1 PHY driver"
@@ -346,9 +354,20 @@ static int lan87xx_phy_init(struct phy_device *phydev)
T1_TX_LPF_FIR_CFG_REG, 0x1011, 0 },
{ PHYACC_ATTR_MODE_WRITE, PHYACC_ATTR_BANK_DSP,
T1_TX_LPF_FIR_CFG_REG, 0x1000, 0 },
+ /* Setup SQI measurement */
+ { PHYACC_ATTR_MODE_WRITE, PHYACC_ATTR_BANK_DSP,
+ T1_COEF_CLK_PWR_DN_CFG, 0x16d6, 0 },
/* SQI enable */
{ PHYACC_ATTR_MODE_WRITE, PHYACC_ATTR_BANK_DSP,
T1_SQI_CONFIG_REG, 0x9572, 0 },
+ /* SQI select mode 5 */
+ { PHYACC_ATTR_MODE_WRITE, PHYACC_ATTR_BANK_DSP,
+ T1_SQI_CONFIG2_REG, 0x0001, 0 },
+ /* Throws the first SQI reading */
+ { PHYACC_ATTR_MODE_WRITE, PHYACC_ATTR_BANK_DSP,
+ T1_COEF_RW_CTL_CFG, 0x0301, 0 },
+ { PHYACC_ATTR_MODE_READ, PHYACC_ATTR_BANK_DSP,
+ T1_DCQ_SQI_REG, 0, 0 },
/* Flag LPS and WUR as idle errors */
{ PHYACC_ATTR_MODE_WRITE, PHYACC_ATTR_BANK_SMI,
T1_MDIO_CONTROL2_REG, 0x0014, 0 },
@@ -724,6 +743,31 @@ static int lan87xx_config_aneg(struct phy_device *phydev)
return phy_modify_changed(phydev, MII_CTRL1000, CTL1000_AS_MASTER, ctl);
}
+static int lan87xx_get_sqi(struct phy_device *phydev)
+{
+ u8 sqi_value = 0;
+ int rc;
+
+ rc = access_ereg(phydev, PHYACC_ATTR_MODE_WRITE,
+ PHYACC_ATTR_BANK_DSP, T1_COEF_RW_CTL_CFG, 0x0301);
+ if (rc < 0)
+ return rc;
+
+ rc = access_ereg(phydev, PHYACC_ATTR_MODE_READ,
+ PHYACC_ATTR_BANK_DSP, T1_DCQ_SQI_REG, 0x0);
+ if (rc < 0)
+ return rc;
+
+ sqi_value = FIELD_GET(T1_DCQ_SQI_MSK, rc);
+
+ return sqi_value;
+}
+
+static int lan87xx_get_sqi_max(struct phy_device *phydev)
+{
+ return LAN87XX_MAX_SQI;
+}
+
static struct phy_driver microchip_t1_phy_driver[] = {
{
PHY_ID_MATCH_MODEL(PHY_ID_LAN87XX),
@@ -737,6 +781,8 @@ static struct phy_driver microchip_t1_phy_driver[] = {
.resume = genphy_resume,
.config_aneg = lan87xx_config_aneg,
.read_status = lan87xx_read_status,
+ .get_sqi = lan87xx_get_sqi,
+ .get_sqi_max = lan87xx_get_sqi_max,
.cable_test_start = lan87xx_cable_test_start,
.cable_test_get_status = lan87xx_cable_test_get_status,
},
@@ -749,6 +795,8 @@ static struct phy_driver microchip_t1_phy_driver[] = {
.resume = genphy_resume,
.config_aneg = lan87xx_config_aneg,
.read_status = lan87xx_read_status,
+ .get_sqi = lan87xx_get_sqi,
+ .get_sqi_max = lan87xx_get_sqi_max,
.cable_test_start = lan87xx_cable_test_start,
.cable_test_get_status = lan87xx_cable_test_get_status,
}
--
2.33.0
^ permalink raw reply related
* [Patch net-next v3 0/2] add ethtool SQI support for LAN87xx T1 Phy
From: Arun Ramadoss @ 2022-04-20 15:20 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: Paolo Abeni, Jakub Kicinski, David S. Miller, Russell King,
Heiner Kallweit, Andrew Lunn, UNGLinuxDriver, Arun Ramadoss
This patch series add the Signal Quality Index measurement for the LAN87xx and
LAN937x T1 phy. Updated the maintainers file for microchip_t1.c.
v2 - v3
------
Rebased to latest commit
v1 - v2
------
- Seperated the PHY_POLL_CABLE_TEST flag patch as a fix to net tree.
- Updated the individual people as Maintainer.
Arun Ramadoss (2):
net: phy: LAN87xx: add ethtool SQI support
MAINTAINERS: Add maintainers for Microchip T1 Phy driver
MAINTAINERS | 7 +++++
drivers/net/phy/microchip_t1.c | 48 ++++++++++++++++++++++++++++++++++
2 files changed, 55 insertions(+)
base-commit: 365014f5c39422fa7ccd75b36235155d9041f883
--
2.33.0
^ permalink raw reply
* [PATCH 00/18] xen: simplify frontend side ring setup
From: Juergen Gross @ 2022-04-20 15:09 UTC (permalink / raw)
To: xen-devel, linux-block, linux-kernel, netdev, linux-scsi,
linux-usb, dri-devel, linux-integrity, linux-pci
Cc: Juergen Gross, Boris Ostrovsky, Stefano Stabellini,
Roger Pau Monné, Jens Axboe, David S. Miller, Jakub Kicinski,
Paolo Abeni, James E.J. Bottomley, Martin K. Petersen,
Greg Kroah-Hartman, Oleksandr Andrushchenko, David Airlie,
Daniel Vetter, Jaroslav Kysela, Takashi Iwai, alsa-devel,
Peter Huewe, Jarkko Sakkinen, Jason Gunthorpe, Bjorn Helgaas
Many Xen PV frontends share similar code for setting up a ring page
(allocating and granting access for the backend) and for tearing it
down.
Create new service functions doing all needed steps in one go.
This requires all frontends to use a common value for an invalid
grant reference in order to make the functions idempotent.
Juergen Gross (18):
xen/blkfront: switch blkfront to use INVALID_GRANT_REF
xen/netfront: switch netfront to use INVALID_GRANT_REF
xen/scsifront: remove unused GRANT_INVALID_REF definition
xen/usb: switch xen-hcd to use INVALID_GRANT_REF
xen/drm: switch xen_drm_front to use INVALID_GRANT_REF
xen/sound: switch xen_snd_front to use INVALID_GRANT_REF
xen/dmabuf: switch gntdev-dmabuf to use INVALID_GRANT_REF
xen/shbuf: switch xen-front-pgdir-shbuf to use INVALID_GRANT_REF
xen/xenbus: add xenbus_setup_ring() service function
xen/blkfront: use xenbus_setup_ring() and xenbus_teardown_ring()
xen/netfront: use xenbus_setup_ring() and xenbus_teardown_ring()
xen/tpmfront: use xenbus_setup_ring() and xenbus_teardown_ring()
xen/drmfront: use xenbus_setup_ring() and xenbus_teardown_ring()
xen/pcifront: use xenbus_setup_ring() and xenbus_teardown_ring()
xen/scsifront: use xenbus_setup_ring() and xenbus_teardown_ring()
xen/usbfront: use xenbus_setup_ring() and xenbus_teardown_ring()
xen/sndfront: use xenbus_setup_ring() and xenbus_teardown_ring()
xen/xenbus: eliminate xenbus_grant_ring()
drivers/block/xen-blkfront.c | 54 ++++----------
drivers/char/tpm/xen-tpmfront.c | 18 +----
drivers/gpu/drm/xen/xen_drm_front.h | 9 ---
drivers/gpu/drm/xen/xen_drm_front_evtchnl.c | 40 +++-------
drivers/net/xen-netfront.c | 77 ++++++--------------
drivers/pci/xen-pcifront.c | 19 +----
drivers/scsi/xen-scsifront.c | 30 ++------
drivers/usb/host/xen-hcd.c | 59 ++++-----------
drivers/xen/gntdev-dmabuf.c | 13 +---
drivers/xen/xen-front-pgdir-shbuf.c | 17 +----
drivers/xen/xenbus/xenbus_client.c | 81 ++++++++++++++++-----
include/xen/xenbus.h | 4 +-
sound/xen/xen_snd_front_evtchnl.c | 41 +++--------
sound/xen/xen_snd_front_evtchnl.h | 9 ---
14 files changed, 156 insertions(+), 315 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH 02/18] xen/netfront: switch netfront to use INVALID_GRANT_REF
From: Juergen Gross @ 2022-04-20 15:09 UTC (permalink / raw)
To: xen-devel, netdev, linux-kernel
Cc: Juergen Gross, Boris Ostrovsky, Stefano Stabellini,
David S. Miller, Jakub Kicinski, Paolo Abeni
In-Reply-To: <20220420150942.31235-1-jgross@suse.com>
Instead of using a private macro for an invalid grant reference use
the common one.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
drivers/net/xen-netfront.c | 36 +++++++++++++++++-------------------
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index e2b4a1893a13..af3d3de7d9fa 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -78,8 +78,6 @@ struct netfront_cb {
#define RX_COPY_THRESHOLD 256
-#define GRANT_INVALID_REF 0
-
#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, XEN_PAGE_SIZE)
#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, XEN_PAGE_SIZE)
@@ -224,7 +222,7 @@ static grant_ref_t xennet_get_rx_ref(struct netfront_queue *queue,
{
int i = xennet_rxidx(ri);
grant_ref_t ref = queue->grant_rx_ref[i];
- queue->grant_rx_ref[i] = GRANT_INVALID_REF;
+ queue->grant_rx_ref[i] = INVALID_GRANT_REF;
return ref;
}
@@ -432,7 +430,7 @@ static bool xennet_tx_buf_gc(struct netfront_queue *queue)
}
gnttab_release_grant_reference(
&queue->gref_tx_head, queue->grant_tx_ref[id]);
- queue->grant_tx_ref[id] = GRANT_INVALID_REF;
+ queue->grant_tx_ref[id] = INVALID_GRANT_REF;
queue->grant_tx_page[id] = NULL;
add_id_to_list(&queue->tx_skb_freelist, queue->tx_link, id);
dev_kfree_skb_irq(skb);
@@ -1021,7 +1019,7 @@ static int xennet_get_responses(struct netfront_queue *queue,
* the backend driver. In future this should flag the bad
* situation to the system controller to reboot the backend.
*/
- if (ref == GRANT_INVALID_REF) {
+ if (ref == INVALID_GRANT_REF) {
if (net_ratelimit())
dev_warn(dev, "Bad rx response id %d.\n",
rx->id);
@@ -1390,7 +1388,7 @@ static void xennet_release_tx_bufs(struct netfront_queue *queue)
gnttab_end_foreign_access(queue->grant_tx_ref[i],
(unsigned long)page_address(queue->grant_tx_page[i]));
queue->grant_tx_page[i] = NULL;
- queue->grant_tx_ref[i] = GRANT_INVALID_REF;
+ queue->grant_tx_ref[i] = INVALID_GRANT_REF;
add_id_to_list(&queue->tx_skb_freelist, queue->tx_link, i);
dev_kfree_skb_irq(skb);
}
@@ -1411,7 +1409,7 @@ static void xennet_release_rx_bufs(struct netfront_queue *queue)
continue;
ref = queue->grant_rx_ref[id];
- if (ref == GRANT_INVALID_REF)
+ if (ref == INVALID_GRANT_REF)
continue;
page = skb_frag_page(&skb_shinfo(skb)->frags[0]);
@@ -1422,7 +1420,7 @@ static void xennet_release_rx_bufs(struct netfront_queue *queue)
get_page(page);
gnttab_end_foreign_access(ref,
(unsigned long)page_address(page));
- queue->grant_rx_ref[id] = GRANT_INVALID_REF;
+ queue->grant_rx_ref[id] = INVALID_GRANT_REF;
kfree_skb(skb);
}
@@ -1761,7 +1759,7 @@ static int netfront_probe(struct xenbus_device *dev,
static void xennet_end_access(int ref, void *page)
{
/* This frees the page as a side-effect */
- if (ref != GRANT_INVALID_REF)
+ if (ref != INVALID_GRANT_REF)
gnttab_end_foreign_access(ref, (unsigned long)page);
}
@@ -1798,8 +1796,8 @@ static void xennet_disconnect_backend(struct netfront_info *info)
xennet_end_access(queue->tx_ring_ref, queue->tx.sring);
xennet_end_access(queue->rx_ring_ref, queue->rx.sring);
- queue->tx_ring_ref = GRANT_INVALID_REF;
- queue->rx_ring_ref = GRANT_INVALID_REF;
+ queue->tx_ring_ref = INVALID_GRANT_REF;
+ queue->rx_ring_ref = INVALID_GRANT_REF;
queue->tx.sring = NULL;
queue->rx.sring = NULL;
@@ -1927,8 +1925,8 @@ static int setup_netfront(struct xenbus_device *dev,
grant_ref_t gref;
int err;
- queue->tx_ring_ref = GRANT_INVALID_REF;
- queue->rx_ring_ref = GRANT_INVALID_REF;
+ queue->tx_ring_ref = INVALID_GRANT_REF;
+ queue->rx_ring_ref = INVALID_GRANT_REF;
queue->rx.sring = NULL;
queue->tx.sring = NULL;
@@ -1978,17 +1976,17 @@ static int setup_netfront(struct xenbus_device *dev,
* granted pages because backend is not accessing it at this point.
*/
fail:
- if (queue->rx_ring_ref != GRANT_INVALID_REF) {
+ if (queue->rx_ring_ref != INVALID_GRANT_REF) {
gnttab_end_foreign_access(queue->rx_ring_ref,
(unsigned long)rxs);
- queue->rx_ring_ref = GRANT_INVALID_REF;
+ queue->rx_ring_ref = INVALID_GRANT_REF;
} else {
free_page((unsigned long)rxs);
}
- if (queue->tx_ring_ref != GRANT_INVALID_REF) {
+ if (queue->tx_ring_ref != INVALID_GRANT_REF) {
gnttab_end_foreign_access(queue->tx_ring_ref,
(unsigned long)txs);
- queue->tx_ring_ref = GRANT_INVALID_REF;
+ queue->tx_ring_ref = INVALID_GRANT_REF;
} else {
free_page((unsigned long)txs);
}
@@ -2020,7 +2018,7 @@ static int xennet_init_queue(struct netfront_queue *queue)
queue->tx_pend_queue = TX_LINK_NONE;
for (i = 0; i < NET_TX_RING_SIZE; i++) {
queue->tx_link[i] = i + 1;
- queue->grant_tx_ref[i] = GRANT_INVALID_REF;
+ queue->grant_tx_ref[i] = INVALID_GRANT_REF;
queue->grant_tx_page[i] = NULL;
}
queue->tx_link[NET_TX_RING_SIZE - 1] = TX_LINK_NONE;
@@ -2028,7 +2026,7 @@ static int xennet_init_queue(struct netfront_queue *queue)
/* Clear out rx_skbs */
for (i = 0; i < NET_RX_RING_SIZE; i++) {
queue->rx_skbs[i] = NULL;
- queue->grant_rx_ref[i] = GRANT_INVALID_REF;
+ queue->grant_rx_ref[i] = INVALID_GRANT_REF;
}
/* A grant for every tx ring slot */
--
2.34.1
^ permalink raw reply related
* [PATCH 11/18] xen/netfront: use xenbus_setup_ring() and xenbus_teardown_ring()
From: Juergen Gross @ 2022-04-20 15:09 UTC (permalink / raw)
To: xen-devel, netdev, linux-kernel
Cc: Juergen Gross, Boris Ostrovsky, Stefano Stabellini,
David S. Miller, Jakub Kicinski, Paolo Abeni
In-Reply-To: <20220420150942.31235-1-jgross@suse.com>
Simplify netfront's ring creation and removal via xenbus_setup_ring()
and xenbus_teardown_ring().
Signed-off-by: Juergen Gross <jgross@suse.com>
---
drivers/net/xen-netfront.c | 49 +++++++++-----------------------------
1 file changed, 11 insertions(+), 38 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index af3d3de7d9fa..880b10d435d9 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1921,8 +1921,7 @@ static int setup_netfront(struct xenbus_device *dev,
struct netfront_queue *queue, unsigned int feature_split_evtchn)
{
struct xen_netif_tx_sring *txs;
- struct xen_netif_rx_sring *rxs = NULL;
- grant_ref_t gref;
+ struct xen_netif_rx_sring *rxs;
int err;
queue->tx_ring_ref = INVALID_GRANT_REF;
@@ -1930,34 +1929,22 @@ static int setup_netfront(struct xenbus_device *dev,
queue->rx.sring = NULL;
queue->tx.sring = NULL;
- txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
- if (!txs) {
- err = -ENOMEM;
- xenbus_dev_fatal(dev, err, "allocating tx ring page");
+ err = xenbus_setup_ring(dev, GFP_NOIO | __GFP_HIGH, (void **)&txs,
+ 1, &queue->tx_ring_ref);
+ if (err)
goto fail;
- }
+
SHARED_RING_INIT(txs);
FRONT_RING_INIT(&queue->tx, txs, XEN_PAGE_SIZE);
- err = xenbus_grant_ring(dev, txs, 1, &gref);
- if (err < 0)
+ err = xenbus_setup_ring(dev, GFP_NOIO | __GFP_HIGH, (void **)&rxs,
+ 1, &queue->rx_ring_ref);
+ if (err)
goto fail;
- queue->tx_ring_ref = gref;
- rxs = (struct xen_netif_rx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
- if (!rxs) {
- err = -ENOMEM;
- xenbus_dev_fatal(dev, err, "allocating rx ring page");
- goto fail;
- }
SHARED_RING_INIT(rxs);
FRONT_RING_INIT(&queue->rx, rxs, XEN_PAGE_SIZE);
- err = xenbus_grant_ring(dev, rxs, 1, &gref);
- if (err < 0)
- goto fail;
- queue->rx_ring_ref = gref;
-
if (feature_split_evtchn)
err = setup_netfront_split(queue);
/* setup single event channel if
@@ -1972,24 +1959,10 @@ static int setup_netfront(struct xenbus_device *dev,
return 0;
- /* If we fail to setup netfront, it is safe to just revoke access to
- * granted pages because backend is not accessing it at this point.
- */
fail:
- if (queue->rx_ring_ref != INVALID_GRANT_REF) {
- gnttab_end_foreign_access(queue->rx_ring_ref,
- (unsigned long)rxs);
- queue->rx_ring_ref = INVALID_GRANT_REF;
- } else {
- free_page((unsigned long)rxs);
- }
- if (queue->tx_ring_ref != INVALID_GRANT_REF) {
- gnttab_end_foreign_access(queue->tx_ring_ref,
- (unsigned long)txs);
- queue->tx_ring_ref = INVALID_GRANT_REF;
- } else {
- free_page((unsigned long)txs);
- }
+ xenbus_teardown_ring((void **)&queue->rx.sring, 1, &queue->rx_ring_ref);
+ xenbus_teardown_ring((void **)&queue->tx.sring, 1, &queue->tx_ring_ref);
+
return err;
}
--
2.34.1
^ permalink raw reply related
* [PATCH net v2] ice: Fix race during aux device (un)plugging
From: Ivan Vecera @ 2022-04-20 15:02 UTC (permalink / raw)
To: netdev
Cc: poros, mschmidt, Leon Romanovsky, Jesse Brandeburg, Tony Nguyen,
David S. Miller, Jakub Kicinski, Paolo Abeni, Dave Ertman,
Shiraz Saleem, moderated list:INTEL ETHERNET DRIVERS, open list
Function ice_plug_aux_dev() assigns pf->adev field too early prior
aux device initialization and on other side ice_unplug_aux_dev()
starts aux device deinit and at the end assigns NULL to pf->adev.
This is wrong because pf->adev should always be non-NULL only when
aux device is fully initialized and ready. This wrong order causes
a crash when ice_send_event_to_aux() call occurs because that function
depends on non-NULL value of pf->adev and does not assume that
aux device is half-initialized or half-destroyed.
After order correction the race window is tiny but it is still there,
as Leon mentioned and manipulation with pf->adev needs to be protected
by mutex.
Fix (un-)plugging functions so pf->adev field is set after aux device
init and prior aux device destroy and protect pf->adev assignment by
new mutex. This mutex is also held during ice_send_event_to_aux()
call to ensure that aux device is valid during that call. Device
lock used ice_send_event_to_aux() to avoid its concurrent run can
be removed as this is secured by that mutex.
Reproducer:
cycle=1
while :;do
echo "#### Cycle: $cycle"
ip link set ens7f0 mtu 9000
ip link add bond0 type bond mode 1 miimon 100
ip link set bond0 up
ifenslave bond0 ens7f0
ip link set bond0 mtu 9000
ethtool -L ens7f0 combined 1
ip link del bond0
ip link set ens7f0 mtu 1500
sleep 1
let cycle++
done
In short when the device is added/removed to/from bond the aux device
is unplugged/plugged. When MTU of the device is changed an event is
sent to aux device asynchronously. This can race with (un)plugging
operation and because pf->adev is set too early (plug) or too late
(unplug) the function ice_send_event_to_aux() can touch uninitialized
or destroyed fields. In the case of crash below pf->adev->dev.mutex.
Crash:
[ 53.372066] bond0: (slave ens7f0): making interface the new active one
[ 53.378622] bond0: (slave ens7f0): Enslaving as an active interface with an u
p link
[ 53.386294] IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
[ 53.549104] bond0: (slave ens7f1): Enslaving as a backup interface with an up
link
[ 54.118906] ice 0000:ca:00.0 ens7f0: Number of in use tx queues changed inval
idating tc mappings. Priority traffic classification disabled!
[ 54.233374] ice 0000:ca:00.1 ens7f1: Number of in use tx queues changed inval
idating tc mappings. Priority traffic classification disabled!
[ 54.248204] bond0: (slave ens7f0): Releasing backup interface
[ 54.253955] bond0: (slave ens7f1): making interface the new active one
[ 54.274875] bond0: (slave ens7f1): Releasing backup interface
[ 54.289153] bond0 (unregistering): Released all slaves
[ 55.383179] MII link monitoring set to 100 ms
[ 55.398696] bond0: (slave ens7f0): making interface the new active one
[ 55.405241] BUG: kernel NULL pointer dereference, address: 0000000000000080
[ 55.405289] bond0: (slave ens7f0): Enslaving as an active interface with an u
p link
[ 55.412198] #PF: supervisor write access in kernel mode
[ 55.412200] #PF: error_code(0x0002) - not-present page
[ 55.412201] PGD 25d2ad067 P4D 0
[ 55.412204] Oops: 0002 [#1] PREEMPT SMP NOPTI
[ 55.412207] CPU: 0 PID: 403 Comm: kworker/0:2 Kdump: loaded Tainted: G S
5.17.0-13579-g57f2d6540f03 #1
[ 55.429094] bond0: (slave ens7f1): Enslaving as a backup interface with an up
link
[ 55.430224] Hardware name: Dell Inc. PowerEdge R750/06V45N, BIOS 1.4.4 10/07/
2021
[ 55.430226] Workqueue: ice ice_service_task [ice]
[ 55.468169] RIP: 0010:mutex_unlock+0x10/0x20
[ 55.472439] Code: 0f b1 13 74 96 eb e0 4c 89 ee eb d8 e8 79 54 ff ff 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 65 48 8b 04 25 40 ef 01 00 31 d2 <f0> 48 0f b1 17 75 01 c3 e9 e3 fe ff ff 0f 1f 00 0f 1f 44 00 00 48
[ 55.491186] RSP: 0018:ff4454230d7d7e28 EFLAGS: 00010246
[ 55.496413] RAX: ff1a79b208b08000 RBX: ff1a79b2182e8880 RCX: 0000000000000001
[ 55.503545] RDX: 0000000000000000 RSI: ff4454230d7d7db0 RDI: 0000000000000080
[ 55.510678] RBP: ff1a79d1c7e48b68 R08: ff4454230d7d7db0 R09: 0000000000000041
[ 55.517812] R10: 00000000000000a5 R11: 00000000000006e6 R12: ff1a79d1c7e48bc0
[ 55.524945] R13: 0000000000000000 R14: ff1a79d0ffc305c0 R15: 0000000000000000
[ 55.532076] FS: 0000000000000000(0000) GS:ff1a79d0ffc00000(0000) knlGS:0000000000000000
[ 55.540163] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 55.545908] CR2: 0000000000000080 CR3: 00000003487ae003 CR4: 0000000000771ef0
[ 55.553041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 55.560173] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 55.567305] PKRU: 55555554
[ 55.570018] Call Trace:
[ 55.572474] <TASK>
[ 55.574579] ice_service_task+0xaab/0xef0 [ice]
[ 55.579130] process_one_work+0x1c5/0x390
[ 55.583141] ? process_one_work+0x390/0x390
[ 55.587326] worker_thread+0x30/0x360
[ 55.590994] ? process_one_work+0x390/0x390
[ 55.595180] kthread+0xe6/0x110
[ 55.598325] ? kthread_complete_and_exit+0x20/0x20
[ 55.603116] ret_from_fork+0x1f/0x30
[ 55.606698] </TASK>
Fixes: f9f5301e7e2d ("ice: Register auxiliary device to provide RDMA")
Cc: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
drivers/net/ethernet/intel/ice/ice.h | 1 +
drivers/net/ethernet/intel/ice/ice_idc.c | 33 ++++++++++++++---------
drivers/net/ethernet/intel/ice/ice_main.c | 2 ++
3 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice.h b/drivers/net/ethernet/intel/ice/ice.h
index 8ed3c9ab7ff7..a895e3a8e988 100644
--- a/drivers/net/ethernet/intel/ice/ice.h
+++ b/drivers/net/ethernet/intel/ice/ice.h
@@ -540,6 +540,7 @@ struct ice_pf {
struct mutex avail_q_mutex; /* protects access to avail_[rx|tx]qs */
struct mutex sw_mutex; /* lock for protecting VSI alloc flow */
struct mutex tc_mutex; /* lock to protect TC changes */
+ struct mutex adev_mutex; /* lock to protect aux device access */
u32 msg_enable;
struct ice_ptp ptp;
struct tty_driver *ice_gnss_tty_driver;
diff --git a/drivers/net/ethernet/intel/ice/ice_idc.c b/drivers/net/ethernet/intel/ice/ice_idc.c
index 25a436d342c2..aef07accd63b 100644
--- a/drivers/net/ethernet/intel/ice/ice_idc.c
+++ b/drivers/net/ethernet/intel/ice/ice_idc.c
@@ -10,13 +10,15 @@
* ice_get_auxiliary_drv - retrieve iidc_auxiliary_drv struct
* @pf: pointer to PF struct
*
- * This function has to be called with a device_lock on the
- * pf->adev.dev to avoid race conditions.
+ * This function has to be called with pf->adev_mutex held
+ * to avoid race conditions.
*/
static struct iidc_auxiliary_drv *ice_get_auxiliary_drv(struct ice_pf *pf)
{
struct auxiliary_device *adev;
+ BUG_ON(!mutex_is_locked(&pf->adev_mutex));
+
adev = pf->adev;
if (!adev || !adev->dev.driver)
return NULL;
@@ -37,14 +39,13 @@ void ice_send_event_to_aux(struct ice_pf *pf, struct iidc_event *event)
if (WARN_ON_ONCE(!in_task()))
return;
- if (!pf->adev)
- return;
+ mutex_lock(&pf->adev_mutex);
- device_lock(&pf->adev->dev);
iadrv = ice_get_auxiliary_drv(pf);
if (iadrv && iadrv->event_handler)
iadrv->event_handler(pf, event);
- device_unlock(&pf->adev->dev);
+
+ mutex_unlock(&pf->adev_mutex);
}
/**
@@ -290,7 +291,6 @@ int ice_plug_aux_dev(struct ice_pf *pf)
return -ENOMEM;
adev = &iadev->adev;
- pf->adev = adev;
iadev->pf = pf;
adev->id = pf->aux_idx;
@@ -300,18 +300,20 @@ int ice_plug_aux_dev(struct ice_pf *pf)
ret = auxiliary_device_init(adev);
if (ret) {
- pf->adev = NULL;
kfree(iadev);
return ret;
}
ret = auxiliary_device_add(adev);
if (ret) {
- pf->adev = NULL;
auxiliary_device_uninit(adev);
return ret;
}
+ mutex_lock(&pf->adev_mutex);
+ pf->adev = adev;
+ mutex_unlock(&pf->adev_mutex);
+
return 0;
}
@@ -320,12 +322,17 @@ int ice_plug_aux_dev(struct ice_pf *pf)
*/
void ice_unplug_aux_dev(struct ice_pf *pf)
{
- if (!pf->adev)
- return;
+ struct auxiliary_device *adev;
- auxiliary_device_delete(pf->adev);
- auxiliary_device_uninit(pf->adev);
+ mutex_lock(&pf->adev_mutex);
+ adev = pf->adev;
pf->adev = NULL;
+ mutex_unlock(&pf->adev_mutex);
+
+ if (adev) {
+ auxiliary_device_delete(adev);
+ auxiliary_device_uninit(adev);
+ }
}
/**
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index 5b1198859da7..2cbbf7abefc4 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -3769,6 +3769,7 @@ u16 ice_get_avail_rxq_count(struct ice_pf *pf)
static void ice_deinit_pf(struct ice_pf *pf)
{
ice_service_task_stop(pf);
+ mutex_destroy(&pf->adev_mutex);
mutex_destroy(&pf->sw_mutex);
mutex_destroy(&pf->tc_mutex);
mutex_destroy(&pf->avail_q_mutex);
@@ -3847,6 +3848,7 @@ static int ice_init_pf(struct ice_pf *pf)
mutex_init(&pf->sw_mutex);
mutex_init(&pf->tc_mutex);
+ mutex_init(&pf->adev_mutex);
INIT_HLIST_HEAD(&pf->aq_wait_list);
spin_lock_init(&pf->aq_wait_lock);
--
2.35.1
^ permalink raw reply related
* Re: [PATCH 4/5] net: phy: marvell: Add LED accessors for Marvell 88E1510
From: Andrew Lunn @ 2022-04-20 15:03 UTC (permalink / raw)
To: Kai-Heng Feng
Cc: hkallweit1, linux, peppe.cavallaro, alexandre.torgue, joabreu,
davem, kuba, pabeni, netdev, linux-kernel
In-Reply-To: <20220420124053.853891-5-kai.heng.feng@canonical.com>
On Wed, Apr 20, 2022 at 08:40:51PM +0800, Kai-Heng Feng wrote:
> Implement get_led_config() and set_led_config() callbacks so phy core
> can use firmware LED as platform requested.
>
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> ---
> drivers/net/phy/marvell.c | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> index 2702faf7b0f60..c5f13e09b0692 100644
> --- a/drivers/net/phy/marvell.c
> +++ b/drivers/net/phy/marvell.c
> @@ -750,6 +750,30 @@ static int m88e1510_config_aneg(struct phy_device *phydev)
> return err;
> }
>
> +static int marvell_get_led_config(struct phy_device *phydev)
> +{
> + int led;
> +
> + led = phy_read_paged(phydev, MII_MARVELL_LED_PAGE, MII_PHY_LED_CTRL);
> + if (led < 0) {
> + phydev_warn(phydev, "Fail to get marvell phy LED.\n");
> + led = 0;
> + }
I've said this multiple times, there are three LED registers, The
Function Control register, the Priority Control register and the Timer
control register. It is the combination of all three that defines how
the LEDs work. You need to save all of them.
And you need to make your API generic enough that the PHY driver can
save anywhere from 1 bit to 42 bytes of configuration.
I don't know ACPI, but i'm pretty sure this is not the ACPI way of
doing this. I think you should be defining an ACPI method, which
phylib can call after initialising the hardware to allow the firmware
to configure the LED.
Andrew
^ 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