* [PATCHv2 net-next] selftests/net: mv bpf/nat6to4.c to net folder
From: Hangbin Liu @ 2022-12-16 8:41 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Jakub Kicinski, Paolo Abeni, Shuah Khan,
David Ahern, Lina Wang, Coleman Dietsch, bpf, Maciej enczykowski,
Björn Töpel, Hangbin Liu
There are some issues with the bpf/nat6to4.c building.
1. It use TEST_CUSTOM_PROGS, which will add the nat6to4.o to
kselftest-list file and run by common run_tests.
2. When building the test via `make -C tools/testing/selftests/
TARGETS="net"`, the nat6to4.o will be build in selftests/net/bpf/
folder. But in test udpgro_frglist.sh it refers to ../bpf/nat6to4.o.
The correct path should be ./bpf/nat6to4.o.
3. If building the test via `make -C tools/testing/selftests/ TARGETS="net"
install`. The nat6to4.o will be installed to kselftest_install/net/
folder. Then the udpgro_frglist.sh should refer to ./nat6to4.o.
To fix the confusing test path, let's just move the nat6to4.c to net folder
and build it as TEST_GEN_FILES.
v2: Update the Makefile rules rely on commit 837a3d66d698 ("selftests:
net: Add cross-compilation support for BPF programs").
Fixes: edae34a3ed92 ("selftests net: add UDP GRO fraglist + bpf self-tests")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
I don't know if there is a way to just install a single TEST_GEN_FILES
to a separate folder. If there is, then we don't need to move the files.
---
tools/testing/selftests/net/Makefile | 50 +++++++++++++++++-
tools/testing/selftests/net/bpf/Makefile | 51 -------------------
.../testing/selftests/net/{bpf => }/nat6to4.c | 0
tools/testing/selftests/net/udpgro_frglist.sh | 8 +--
4 files changed, 52 insertions(+), 57 deletions(-)
delete mode 100644 tools/testing/selftests/net/bpf/Makefile
rename tools/testing/selftests/net/{bpf => }/nat6to4.c (100%)
diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
index 3007e98a6d64..ed9a315187c1 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -75,14 +75,60 @@ TEST_GEN_PROGS += so_incoming_cpu
TEST_PROGS += sctp_vrf.sh
TEST_GEN_FILES += sctp_hello
TEST_GEN_FILES += csum
+TEST_GEN_FILES += nat6to4.o
TEST_FILES := settings
include ../lib.mk
-include bpf/Makefile
-
$(OUTPUT)/reuseport_bpf_numa: LDLIBS += -lnuma
$(OUTPUT)/tcp_mmap: LDLIBS += -lpthread
$(OUTPUT)/tcp_inq: LDLIBS += -lpthread
$(OUTPUT)/bind_bhash: LDLIBS += -lpthread
+
+# Rules to generate bpf obj nat6to4.o
+CLANG ?= clang
+SCRATCH_DIR := $(OUTPUT)/tools
+BUILD_DIR := $(SCRATCH_DIR)/build
+BPFDIR := $(abspath ../../../lib/bpf)
+APIDIR := $(abspath ../../../include/uapi)
+
+CCINCLUDE += -I../bpf
+CCINCLUDE += -I../../../../usr/include/
+CCINCLUDE += -I$(SCRATCH_DIR)/include
+
+BPFOBJ := $(BUILD_DIR)/libbpf/libbpf.a
+
+MAKE_DIRS := $(BUILD_DIR)/libbpf $(OUTPUT)/bpf
+$(MAKE_DIRS):
+ mkdir -p $@
+
+# Get Clang's default includes on this system, as opposed to those seen by
+# '-target bpf'. This fixes "missing" files on some architectures/distros,
+# such as asm/byteorder.h, asm/socket.h, asm/sockios.h, sys/cdefs.h etc.
+#
+# Use '-idirafter': Don't interfere with include mechanics except where the
+# build would have failed anyways.
+define get_sys_includes
+$(shell $(1) $(2) -v -E - </dev/null 2>&1 \
+ | sed -n '/<...> search starts here:/,/End of search list./{ s| \(/.*\)|-idirafter \1|p }') \
+$(shell $(1) $(2) -dM -E - </dev/null | grep '__riscv_xlen ' | awk '{printf("-D__riscv_xlen=%d -D__BITS_PER_LONG=%d", $$3, $$3)}')
+endef
+
+ifneq ($(CROSS_COMPILE),)
+CLANG_TARGET_ARCH = --target=$(notdir $(CROSS_COMPILE:%-=%))
+endif
+
+CLANG_SYS_INCLUDES = $(call get_sys_includes,$(CLANG),$(CLANG_TARGET_ARCH))
+
+$(OUTPUT)/nat6to4.o: nat6to4.c $(BPFOBJ) | $(MAKE_DIRS)
+ $(CLANG) -O2 -target bpf -c $< $(CCINCLUDE) $(CLANG_SYS_INCLUDES) -o $@
+
+$(BPFOBJ): $(wildcard $(BPFDIR)/*.[ch] $(BPFDIR)/Makefile) \
+ $(APIDIR)/linux/bpf.h \
+ | $(BUILD_DIR)/libbpf
+ $(MAKE) $(submake_extras) -C $(BPFDIR) OUTPUT=$(BUILD_DIR)/libbpf/ \
+ EXTRA_CFLAGS='-g -O0' \
+ DESTDIR=$(SCRATCH_DIR) prefix= all install_headers
+
+EXTRA_CLEAN := $(SCRATCH_DIR)
diff --git a/tools/testing/selftests/net/bpf/Makefile b/tools/testing/selftests/net/bpf/Makefile
deleted file mode 100644
index 4abaf16d2077..000000000000
--- a/tools/testing/selftests/net/bpf/Makefile
+++ /dev/null
@@ -1,51 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-
-CLANG ?= clang
-SCRATCH_DIR := $(OUTPUT)/tools
-BUILD_DIR := $(SCRATCH_DIR)/build
-BPFDIR := $(abspath ../../../lib/bpf)
-APIDIR := $(abspath ../../../include/uapi)
-
-CCINCLUDE += -I../../bpf
-CCINCLUDE += -I../../../../../usr/include/
-CCINCLUDE += -I$(SCRATCH_DIR)/include
-
-BPFOBJ := $(BUILD_DIR)/libbpf/libbpf.a
-
-MAKE_DIRS := $(BUILD_DIR)/libbpf $(OUTPUT)/bpf
-$(MAKE_DIRS):
- mkdir -p $@
-
-TEST_CUSTOM_PROGS = $(OUTPUT)/bpf/nat6to4.o
-all: $(TEST_CUSTOM_PROGS)
-
-# Get Clang's default includes on this system, as opposed to those seen by
-# '-target bpf'. This fixes "missing" files on some architectures/distros,
-# such as asm/byteorder.h, asm/socket.h, asm/sockios.h, sys/cdefs.h etc.
-#
-# Use '-idirafter': Don't interfere with include mechanics except where the
-# build would have failed anyways.
-define get_sys_includes
-$(shell $(1) $(2) -v -E - </dev/null 2>&1 \
- | sed -n '/<...> search starts here:/,/End of search list./{ s| \(/.*\)|-idirafter \1|p }') \
-$(shell $(1) $(2) -dM -E - </dev/null | grep '__riscv_xlen ' | awk '{printf("-D__riscv_xlen=%d -D__BITS_PER_LONG=%d", $$3, $$3)}')
-endef
-
-ifneq ($(CROSS_COMPILE),)
-CLANG_TARGET_ARCH = --target=$(notdir $(CROSS_COMPILE:%-=%))
-endif
-
-CLANG_SYS_INCLUDES = $(call get_sys_includes,$(CLANG),$(CLANG_TARGET_ARCH))
-
-$(TEST_CUSTOM_PROGS): $(OUTPUT)/%.o: %.c $(BPFOBJ) | $(MAKE_DIRS)
- $(CLANG) -O2 -target bpf -c $< $(CCINCLUDE) $(CLANG_SYS_INCLUDES) -o $@
-
-$(BPFOBJ): $(wildcard $(BPFDIR)/*.[ch] $(BPFDIR)/Makefile) \
- $(APIDIR)/linux/bpf.h \
- | $(BUILD_DIR)/libbpf
- $(MAKE) $(submake_extras) -C $(BPFDIR) OUTPUT=$(BUILD_DIR)/libbpf/ \
- EXTRA_CFLAGS='-g -O0' \
- DESTDIR=$(SCRATCH_DIR) prefix= all install_headers
-
-EXTRA_CLEAN := $(TEST_CUSTOM_PROGS) $(SCRATCH_DIR)
-
diff --git a/tools/testing/selftests/net/bpf/nat6to4.c b/tools/testing/selftests/net/nat6to4.c
similarity index 100%
rename from tools/testing/selftests/net/bpf/nat6to4.c
rename to tools/testing/selftests/net/nat6to4.c
diff --git a/tools/testing/selftests/net/udpgro_frglist.sh b/tools/testing/selftests/net/udpgro_frglist.sh
index c9c4b9d65839..0a6359bed0b9 100755
--- a/tools/testing/selftests/net/udpgro_frglist.sh
+++ b/tools/testing/selftests/net/udpgro_frglist.sh
@@ -40,8 +40,8 @@ run_one() {
ip -n "${PEER_NS}" link set veth1 xdp object ${BPF_FILE} section xdp
tc -n "${PEER_NS}" qdisc add dev veth1 clsact
- tc -n "${PEER_NS}" filter add dev veth1 ingress prio 4 protocol ipv6 bpf object-file ../bpf/nat6to4.o section schedcls/ingress6/nat_6 direct-action
- tc -n "${PEER_NS}" filter add dev veth1 egress prio 4 protocol ip bpf object-file ../bpf/nat6to4.o section schedcls/egress4/snat4 direct-action
+ tc -n "${PEER_NS}" filter add dev veth1 ingress prio 4 protocol ipv6 bpf object-file nat6to4.o section schedcls/ingress6/nat_6 direct-action
+ tc -n "${PEER_NS}" filter add dev veth1 egress prio 4 protocol ip bpf object-file nat6to4.o section schedcls/egress4/snat4 direct-action
echo ${rx_args}
ip netns exec "${PEER_NS}" ./udpgso_bench_rx ${rx_args} -r &
@@ -88,8 +88,8 @@ if [ ! -f ${BPF_FILE} ]; then
exit -1
fi
-if [ ! -f bpf/nat6to4.o ]; then
- echo "Missing nat6to4 helper. Build bpfnat6to4.o selftest first"
+if [ ! -f nat6to4.o ]; then
+ echo "Missing nat6to4 helper. Build bpf nat6to4.o selftest first"
exit -1
fi
--
2.38.1
^ permalink raw reply related
* Re: [PATCH v2 6/9] net: phy: motorcomm: Add YT8531 phy support
From: Arun.Ramadoss @ 2022-12-16 8:41 UTC (permalink / raw)
To: netdev, linux-riscv, yanhong.wang, linux-kernel, devicetree
Cc: andrew, robh+dt, pgwipeout, kernel, kuba, pabeni, edumazet,
richardcochran, krzysztof.kozlowski+dt, davem, hkallweit1
In-Reply-To: <20221216070632.11444-7-yanhong.wang@starfivetech.com>
Hi Yanhong,
On Fri, 2022-12-16 at 15:06 +0800, Yanhong Wang wrote:
> This adds basic support for the Motorcomm YT8531
> Gigabit Ethernet PHY.
>
> Signed-off-by: Yanhong Wang <yanhong.wang@starfivetech.com>
> ---
> drivers/net/phy/Kconfig | 3 +-
> drivers/net/phy/motorcomm.c | 202
> ++++++++++++++++++++++++++++++++++++
> 2 files changed, 204 insertions(+), 1 deletion(-)
>
>
> +static int ytphy_read_ext(struct phy_device *phydev, u32 regnum)
> +{
> + int ret;
> + int val;
> +
> + ret = __phy_write(phydev, YT8511_PAGE_SELECT, regnum);
> + if (ret < 0)
> + return ret;
You are returning the error value as well as the read value in the
function. But in the config_init, you are not checking the error value,
just using the value directly. So instead of returning both the value
and error, you may consider return error and for value use call by
reference.
> +
> + val = __phy_read(phydev, YT8511_PAGE);
> +
> + return val;
> +}
> +
> +
> static int yt8511_config_init(struct phy_device *phydev)
> {
> int oldpage, ret = 0;
> @@ -111,6 +191,116 @@ static int yt8511_config_init(struct phy_device
> *phydev)
> return phy_restore_page(phydev, oldpage, ret);
> }
>
> +static int ytphy_config_init(struct phy_device *phydev)
> +{
> + struct device_node *of_node;
> + u32 val;
> + u32 mask;
> + u32 cfg;
> + int ret;
> + int i = 0;
i initialized here as well as in for loop.
> +
> + of_node = phydev->mdio.dev.of_node;
> + if (of_node) {
to reduce the ident level, you may consider returning here by checking
if(!of_node)
return -EINVAL;
> + ret = of_property_read_u32(of_node,
> ytphy_rxden_grp[0].name, &cfg);
> + if (!ret) {
> + mask = ytphy_rxden_grp[0].mask;
> + val = ytphy_read_ext(phydev,
> YTPHY_EXT_CHIP_CONFIG);
> +
> + /* check the cfg overflow or not */
> + cfg = cfg > mask >> (ffs(mask) - 1) ? mask :
> cfg;
> +
> + val &= ~mask;
> + val |= FIELD_PREP(mask, cfg);
> + ytphy_write_ext(phydev, YTPHY_EXT_CHIP_CONFIG,
> val);
> + }
> +
> + val = ytphy_read_ext(phydev, YTPHY_EXT_RGMII_CONFIG1);
> + for (i = 0; i < ARRAY_SIZE(ytphy_rxtxd_grp); i++) {
> + ret = of_property_read_u32(of_node,
> ytphy_rxtxd_grp[i].name, &cfg);
> + if (!ret) {
> + mask = ytphy_rxtxd_grp[i].mask;
> +
> + /* check the cfg overflow or not */
> + cfg = cfg > mask >> (ffs(mask) - 1) ?
> mask : cfg;
> +
> + val &= ~mask;
> + val |= cfg << (ffs(mask) - 1);
> + }
> + }
> + return ytphy_write_ext(phydev, YTPHY_EXT_RGMII_CONFIG1,
> val);
> + }
> +
> + phydev_err(phydev, "Get of node fail\n");
> +
> + return -EINVAL;
> +}
> +
> +static void ytphy_link_change_notify(struct phy_device *phydev)
> +{
> + u32 val;
> + struct ytphy_priv_t *ytphy_priv = phydev->priv;
reverse christmas tree
> +
> + if (phydev->speed < 0)
> + return;
> +
> +
> +static int yt8531_probe(struct phy_device *phydev)
> +{
> + struct ytphy_priv_t *priv;
> + const struct device_node *of_node;
Reverse christmas tree.
> + u32 val;
> + int ret;
> +
> + priv = devm_kzalloc(&phydev->mdio.dev, sizeof(*priv),
> GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + of_node = phydev->mdio.dev.of_node;
> + if (of_node) {
> + ret = of_property_read_u32(of_node,
> ytphy_txinver_grp[0].name, &val);
> + if (!ret)
> + priv->tx_inverted_1000 = val;
> +
> + ret = of_property_read_u32(of_node,
> ytphy_txinver_grp[1].name, &val);
> + if (!ret)
> + priv->tx_inverted_100 = val;
> +
> + ret = of_property_read_u32(of_node,
> ytphy_txinver_grp[2].name, &val);
> + if (!ret)
> + priv->tx_inverted_10 = val;
> + }
> + phydev->priv = priv;
> +
> + return 0;
> +}
> +
>
^ permalink raw reply
* Odroczenie zapłaty
From: Dominik Chrostek @ 2022-12-16 8:30 UTC (permalink / raw)
To: netdev
Dzień dobry,
czy chcieliby odroczyć płatność za towary u dostawców?
Możemy zapłacić za Państwa zamówienia, a po zapłacie wystawimy Państwu fakturę z odroczonym terminem płatności nawet do 90 dni.
Byliby Państwo zainteresowani taką możliwością?
Pozdrawiam
Dominik Chrostek
^ permalink raw reply
* Re: [RFC PATCH 1/6] vdpa: add bind_mm callback
From: Stefano Garzarella @ 2022-12-16 8:17 UTC (permalink / raw)
To: Jason Wang
Cc: virtualization, Andrey Zhadchenko, linux-kernel, kvm,
Michael S. Tsirkin, eperezma, stefanha, netdev
In-Reply-To: <CACGkMEtB6uQ_6fKU5F-D0vG+gQz9mMdYWUQwre-yp1sVpGvKPQ@mail.gmail.com>
On Fri, Dec 16, 2022 at 02:37:45PM +0800, Jason Wang wrote:
>On Thu, Dec 15, 2022 at 12:30 AM Stefano Garzarella <sgarzare@redhat.com> wrote:
>>
>> This new optional callback is used to bind the device to a specific
>> address space so the vDPA framework can use VA when this callback
>> is implemented.
>>
>> Suggested-by: Jason Wang <jasowang@redhat.com>
>> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
>> ---
>> include/linux/vdpa.h | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
>> index 6d0f5e4e82c2..34388e21ef3f 100644
>> --- a/include/linux/vdpa.h
>> +++ b/include/linux/vdpa.h
>> @@ -282,6 +282,12 @@ struct vdpa_map_file {
>> * @iova: iova to be unmapped
>> * @size: size of the area
>> * Returns integer: success (0) or error (< 0)
>> + * @bind_mm: Bind the device to a specific address space
>> + * so the vDPA framework can use VA when this
>> + * callback is implemented. (optional)
>> + * @vdev: vdpa device
>> + * @mm: address space to bind
>
>Do we need an unbind or did a NULL mm mean unbind?
Yep, your comment in patch 6 makes it necessary. I will add it!
>
>> + * @owner: process that owns the address space
>
>Any reason we need the task_struct here?
Mainly to attach to kthread to the process cgroups, but that part is
still in TODO since I need to understand it better.
Maybe we can remove the task_struct here and use `current` directly in
the callback.
Thanks,
Stefano
^ permalink raw reply
* Re: [RFC PATCH 6/6] vdpa_sim: add support for user VA
From: Stefano Garzarella @ 2022-12-16 8:13 UTC (permalink / raw)
To: Jason Wang
Cc: virtualization, Andrey Zhadchenko, linux-kernel, kvm,
Michael S. Tsirkin, eperezma, stefanha, netdev
In-Reply-To: <CACGkMEuk0xNwthy4NgR1xPfEVt-EgtmZmfiacJprGgyvi3hVAA@mail.gmail.com>
On Fri, Dec 16, 2022 at 03:26:46PM +0800, Jason Wang wrote:
>On Thu, Dec 15, 2022 at 12:31 AM Stefano Garzarella <sgarzare@redhat.com> wrote:
>>
>> The new "use_va" module parameter (default: false) is used in
>> vdpa_alloc_device() to inform the vDPA framework that the device
>> supports VA.
>>
>> vringh is initialized to use VA only when "use_va" is true and the
>> user's mm has been bound. So, only when the bus supports user VA
>> (e.g. vhost-vdpa).
>>
>> vdpasim_mm_work_fn work is used to attach the kthread to the user
>> address space when the .bind_mm callback is invoked, and to detach
>> it when the device is reset.
>
>One thing in my mind is that the current datapath is running under
>spinlock which prevents us from using iov_iter (which may have page
>faults).
>
>We need to get rid of the spinlock first.
Right! I already have a patch for that since I used for the vdpa-blk
software device in-kernel PoC where I had the same issue.
I'll add it to the series!
>
>>
>> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
>> ---
>> drivers/vdpa/vdpa_sim/vdpa_sim.h | 1 +
>> drivers/vdpa/vdpa_sim/vdpa_sim.c | 104 ++++++++++++++++++++++++++++++-
>> 2 files changed, 103 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.h b/drivers/vdpa/vdpa_sim/vdpa_sim.h
>> index 07ef53ea375e..1b010e5c0445 100644
>> --- a/drivers/vdpa/vdpa_sim/vdpa_sim.h
>> +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.h
>> @@ -55,6 +55,7 @@ struct vdpasim {
>> struct vdpasim_virtqueue *vqs;
>> struct kthread_worker *worker;
>> struct kthread_work work;
>> + struct mm_struct *mm_bound;
>> struct vdpasim_dev_attr dev_attr;
>> /* spinlock to synchronize virtqueue state */
>> spinlock_t lock;
>> diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
>> index 36a1d2e0a6ba..6e07cedef30c 100644
>> --- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
>> +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
>> @@ -36,10 +36,90 @@ module_param(max_iotlb_entries, int, 0444);
>> MODULE_PARM_DESC(max_iotlb_entries,
>> "Maximum number of iotlb entries for each address space. 0 means unlimited. (default: 2048)");
>>
>> +static bool use_va;
>> +module_param(use_va, bool, 0444);
>> +MODULE_PARM_DESC(use_va, "Enable the device's ability to use VA");
>> +
>> #define VDPASIM_QUEUE_ALIGN PAGE_SIZE
>> #define VDPASIM_QUEUE_MAX 256
>> #define VDPASIM_VENDOR_ID 0
>>
>> +struct vdpasim_mm_work {
>> + struct kthread_work work;
>> + struct task_struct *owner;
>> + struct mm_struct *mm;
>> + bool bind;
>> + int ret;
>> +};
>> +
>> +static void vdpasim_mm_work_fn(struct kthread_work *work)
>> +{
>> + struct vdpasim_mm_work *mm_work =
>> + container_of(work, struct vdpasim_mm_work, work);
>> +
>> + mm_work->ret = 0;
>> +
>> + if (mm_work->bind) {
>> + kthread_use_mm(mm_work->mm);
>> +#if 0
>> + if (mm_work->owner)
>> + mm_work->ret = cgroup_attach_task_all(mm_work->owner,
>> + current);
>> +#endif
>> + } else {
>> +#if 0
>> + //TODO: check it
>> + cgroup_release(current);
>> +#endif
>> + kthread_unuse_mm(mm_work->mm);
>> + }
>> +}
>> +
>> +static void vdpasim_worker_queue_mm(struct vdpasim *vdpasim,
>> + struct vdpasim_mm_work *mm_work)
>> +{
>> + struct kthread_work *work = &mm_work->work;
>> +
>> + kthread_init_work(work, vdpasim_mm_work_fn);
>> + kthread_queue_work(vdpasim->worker, work);
>> +
>> + spin_unlock(&vdpasim->lock);
>> + kthread_flush_work(work);
>> + spin_lock(&vdpasim->lock);
>> +}
>> +
>> +static int vdpasim_worker_bind_mm(struct vdpasim *vdpasim,
>> + struct mm_struct *new_mm,
>> + struct task_struct *owner)
>> +{
>> + struct vdpasim_mm_work mm_work;
>> +
>> + mm_work.owner = owner;
>> + mm_work.mm = new_mm;
>> + mm_work.bind = true;
>> +
>> + vdpasim_worker_queue_mm(vdpasim, &mm_work);
>> +
>
>Should we wait for the work to be finished?
Yep, I'm waiting inside vdpasim_worker_queue_mm() calling
kthread_flush_work().
If we will use mutex, I think we can avoid the lock release around that
call.
>
>> + if (!mm_work.ret)
>> + vdpasim->mm_bound = new_mm;
>> +
>> + return mm_work.ret;
>> +}
>> +
>> +static void vdpasim_worker_unbind_mm(struct vdpasim *vdpasim)
>> +{
>> + struct vdpasim_mm_work mm_work;
>> +
>> + if (!vdpasim->mm_bound)
>> + return;
>> +
>> + mm_work.mm = vdpasim->mm_bound;
>> + mm_work.bind = false;
>> +
>> + vdpasim_worker_queue_mm(vdpasim, &mm_work);
>> +
>> + vdpasim->mm_bound = NULL;
>> +}
>> static struct vdpasim *vdpa_to_sim(struct vdpa_device *vdpa)
>> {
>> return container_of(vdpa, struct vdpasim, vdpa);
>> @@ -66,8 +146,10 @@ static void vdpasim_vq_notify(struct vringh *vring)
>> static void vdpasim_queue_ready(struct vdpasim *vdpasim, unsigned int idx)
>> {
>> struct vdpasim_virtqueue *vq = &vdpasim->vqs[idx];
>> + bool va_enabled = use_va && vdpasim->mm_bound;
>>
>> - vringh_init_iotlb(&vq->vring, vdpasim->features, vq->num, false, false,
>> + vringh_init_iotlb(&vq->vring, vdpasim->features, vq->num, false,
>> + va_enabled,
>> (struct vring_desc *)(uintptr_t)vq->desc_addr,
>> (struct vring_avail *)
>> (uintptr_t)vq->driver_addr,
>> @@ -96,6 +178,9 @@ static void vdpasim_do_reset(struct vdpasim *vdpasim)
>> {
>> int i;
>>
>> + //TODO: should we cancel the works?
>> + vdpasim_worker_unbind_mm(vdpasim);
>
>We probably don't need this since it's the virtio level reset so we
>need to keep the mm bound in this case. Otherwise we may break the
>guest. It should be the responsibility of the driver to call
>config_ops->unbind if it needs to do that.
Got it, my biggest concern was when we go from a vhost-vdpa virtio-vdpa,
but as you said, in vhost-vdpa I can call unbind before releasing the
device.
Thanks,
Stefano
^ permalink raw reply
* Re: [RFC PATCH 6/6] vdpa_sim: add support for user VA
From: Jason Wang @ 2022-12-16 7:26 UTC (permalink / raw)
To: Stefano Garzarella
Cc: virtualization, Andrey Zhadchenko, linux-kernel, kvm,
Michael S. Tsirkin, eperezma, stefanha, netdev
In-Reply-To: <20221214163025.103075-7-sgarzare@redhat.com>
On Thu, Dec 15, 2022 at 12:31 AM Stefano Garzarella <sgarzare@redhat.com> wrote:
>
> The new "use_va" module parameter (default: false) is used in
> vdpa_alloc_device() to inform the vDPA framework that the device
> supports VA.
>
> vringh is initialized to use VA only when "use_va" is true and the
> user's mm has been bound. So, only when the bus supports user VA
> (e.g. vhost-vdpa).
>
> vdpasim_mm_work_fn work is used to attach the kthread to the user
> address space when the .bind_mm callback is invoked, and to detach
> it when the device is reset.
One thing in my mind is that the current datapath is running under
spinlock which prevents us from using iov_iter (which may have page
faults).
We need to get rid of the spinlock first.
>
> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
> ---
> drivers/vdpa/vdpa_sim/vdpa_sim.h | 1 +
> drivers/vdpa/vdpa_sim/vdpa_sim.c | 104 ++++++++++++++++++++++++++++++-
> 2 files changed, 103 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.h b/drivers/vdpa/vdpa_sim/vdpa_sim.h
> index 07ef53ea375e..1b010e5c0445 100644
> --- a/drivers/vdpa/vdpa_sim/vdpa_sim.h
> +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.h
> @@ -55,6 +55,7 @@ struct vdpasim {
> struct vdpasim_virtqueue *vqs;
> struct kthread_worker *worker;
> struct kthread_work work;
> + struct mm_struct *mm_bound;
> struct vdpasim_dev_attr dev_attr;
> /* spinlock to synchronize virtqueue state */
> spinlock_t lock;
> diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
> index 36a1d2e0a6ba..6e07cedef30c 100644
> --- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
> +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
> @@ -36,10 +36,90 @@ module_param(max_iotlb_entries, int, 0444);
> MODULE_PARM_DESC(max_iotlb_entries,
> "Maximum number of iotlb entries for each address space. 0 means unlimited. (default: 2048)");
>
> +static bool use_va;
> +module_param(use_va, bool, 0444);
> +MODULE_PARM_DESC(use_va, "Enable the device's ability to use VA");
> +
> #define VDPASIM_QUEUE_ALIGN PAGE_SIZE
> #define VDPASIM_QUEUE_MAX 256
> #define VDPASIM_VENDOR_ID 0
>
> +struct vdpasim_mm_work {
> + struct kthread_work work;
> + struct task_struct *owner;
> + struct mm_struct *mm;
> + bool bind;
> + int ret;
> +};
> +
> +static void vdpasim_mm_work_fn(struct kthread_work *work)
> +{
> + struct vdpasim_mm_work *mm_work =
> + container_of(work, struct vdpasim_mm_work, work);
> +
> + mm_work->ret = 0;
> +
> + if (mm_work->bind) {
> + kthread_use_mm(mm_work->mm);
> +#if 0
> + if (mm_work->owner)
> + mm_work->ret = cgroup_attach_task_all(mm_work->owner,
> + current);
> +#endif
> + } else {
> +#if 0
> + //TODO: check it
> + cgroup_release(current);
> +#endif
> + kthread_unuse_mm(mm_work->mm);
> + }
> +}
> +
> +static void vdpasim_worker_queue_mm(struct vdpasim *vdpasim,
> + struct vdpasim_mm_work *mm_work)
> +{
> + struct kthread_work *work = &mm_work->work;
> +
> + kthread_init_work(work, vdpasim_mm_work_fn);
> + kthread_queue_work(vdpasim->worker, work);
> +
> + spin_unlock(&vdpasim->lock);
> + kthread_flush_work(work);
> + spin_lock(&vdpasim->lock);
> +}
> +
> +static int vdpasim_worker_bind_mm(struct vdpasim *vdpasim,
> + struct mm_struct *new_mm,
> + struct task_struct *owner)
> +{
> + struct vdpasim_mm_work mm_work;
> +
> + mm_work.owner = owner;
> + mm_work.mm = new_mm;
> + mm_work.bind = true;
> +
> + vdpasim_worker_queue_mm(vdpasim, &mm_work);
> +
Should we wait for the work to be finished?
> + if (!mm_work.ret)
> + vdpasim->mm_bound = new_mm;
> +
> + return mm_work.ret;
> +}
> +
> +static void vdpasim_worker_unbind_mm(struct vdpasim *vdpasim)
> +{
> + struct vdpasim_mm_work mm_work;
> +
> + if (!vdpasim->mm_bound)
> + return;
> +
> + mm_work.mm = vdpasim->mm_bound;
> + mm_work.bind = false;
> +
> + vdpasim_worker_queue_mm(vdpasim, &mm_work);
> +
> + vdpasim->mm_bound = NULL;
> +}
> static struct vdpasim *vdpa_to_sim(struct vdpa_device *vdpa)
> {
> return container_of(vdpa, struct vdpasim, vdpa);
> @@ -66,8 +146,10 @@ static void vdpasim_vq_notify(struct vringh *vring)
> static void vdpasim_queue_ready(struct vdpasim *vdpasim, unsigned int idx)
> {
> struct vdpasim_virtqueue *vq = &vdpasim->vqs[idx];
> + bool va_enabled = use_va && vdpasim->mm_bound;
>
> - vringh_init_iotlb(&vq->vring, vdpasim->features, vq->num, false, false,
> + vringh_init_iotlb(&vq->vring, vdpasim->features, vq->num, false,
> + va_enabled,
> (struct vring_desc *)(uintptr_t)vq->desc_addr,
> (struct vring_avail *)
> (uintptr_t)vq->driver_addr,
> @@ -96,6 +178,9 @@ static void vdpasim_do_reset(struct vdpasim *vdpasim)
> {
> int i;
>
> + //TODO: should we cancel the works?
> + vdpasim_worker_unbind_mm(vdpasim);
We probably don't need this since it's the virtio level reset so we
need to keep the mm bound in this case. Otherwise we may break the
guest. It should be the responsibility of the driver to call
config_ops->unbind if it needs to do that.
Thanks
> +
> spin_lock(&vdpasim->iommu_lock);
>
> for (i = 0; i < vdpasim->dev_attr.nvqs; i++) {
> @@ -275,7 +360,7 @@ struct vdpasim *vdpasim_create(struct vdpasim_dev_attr *dev_attr,
>
> vdpasim = vdpa_alloc_device(struct vdpasim, vdpa, NULL, ops,
> dev_attr->ngroups, dev_attr->nas,
> - dev_attr->name, false);
> + dev_attr->name, use_va);
> if (IS_ERR(vdpasim)) {
> ret = PTR_ERR(vdpasim);
> goto err_alloc;
> @@ -657,6 +742,19 @@ static int vdpasim_set_map(struct vdpa_device *vdpa, unsigned int asid,
> return ret;
> }
>
> +static int vdpasim_bind_mm(struct vdpa_device *vdpa, struct mm_struct *mm,
> + struct task_struct *owner)
> +{
> + struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
> + int ret;
> +
> + spin_lock(&vdpasim->lock);
> + ret = vdpasim_worker_bind_mm(vdpasim, mm, owner);
> + spin_unlock(&vdpasim->lock);
> +
> + return ret;
> +}
> +
> static int vdpasim_dma_map(struct vdpa_device *vdpa, unsigned int asid,
> u64 iova, u64 size,
> u64 pa, u32 perm, void *opaque)
> @@ -744,6 +842,7 @@ static const struct vdpa_config_ops vdpasim_config_ops = {
> .set_group_asid = vdpasim_set_group_asid,
> .dma_map = vdpasim_dma_map,
> .dma_unmap = vdpasim_dma_unmap,
> + .bind_mm = vdpasim_bind_mm,
> .free = vdpasim_free,
> };
>
> @@ -776,6 +875,7 @@ static const struct vdpa_config_ops vdpasim_batch_config_ops = {
> .get_iova_range = vdpasim_get_iova_range,
> .set_group_asid = vdpasim_set_group_asid,
> .set_map = vdpasim_set_map,
> + .bind_mm = vdpasim_bind_mm,
> .free = vdpasim_free,
> };
>
> --
> 2.38.1
>
^ permalink raw reply
* [PATCH v2 9/9] riscv: dts: starfive: visionfive-v2: Add phy clock delay train configuration
From: Yanhong Wang @ 2022-12-16 7:06 UTC (permalink / raw)
To: linux-riscv, netdev, devicetree, linux-kernel
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Emil Renner Berthing,
Richard Cochran, Andrew Lunn, Heiner Kallweit, Peter Geis,
Yanhong Wang
In-Reply-To: <20221216070632.11444-1-yanhong.wang@starfivetech.com>
In view of the particularity of StarFive JH7110 SoC, the PHY clock delay
train configuration parameters must be adjusted for StarFive VisionFive
v2 board.
Signed-off-by: Yanhong Wang <yanhong.wang@starfivetech.com>
---
.../jh7110-starfive-visionfive-v2.dts | 28 +++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-v2.dts b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-v2.dts
index c8946cf3a268..81329d67ef0f 100644
--- a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-v2.dts
+++ b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-v2.dts
@@ -15,6 +15,8 @@
aliases {
serial0 = &uart0;
+ ethernet0 = &gmac0;
+ ethernet1 = &gmac1;
};
chosen {
@@ -114,3 +116,29 @@
pinctrl-0 = <&uart0_pins>;
status = "okay";
};
+
+&gmac0 {
+ status = "okay";
+};
+
+&phy0 {
+ rxc_dly_en = <1>;
+ tx_delay_sel_fe = <5>;
+ tx_delay_sel = <0xa>;
+ tx_inverted_10 = <0x1>;
+ tx_inverted_100 = <0x1>;
+ tx_inverted_1000 = <0x1>;
+};
+
+&gmac1 {
+ status = "okay";
+};
+
+&phy1 {
+ rxc_dly_en = <0>;
+ tx_delay_sel_fe = <5>;
+ tx_delay_sel = <0>;
+ tx_inverted_10 = <0x1>;
+ tx_inverted_100 = <0x1>;
+ tx_inverted_1000 = <0x0>;
+};
--
2.17.1
^ permalink raw reply related
* [PATCH v2 8/9] riscv: dts: starfive: jh7110: Add ethernet device node
From: Yanhong Wang @ 2022-12-16 7:06 UTC (permalink / raw)
To: linux-riscv, netdev, devicetree, linux-kernel
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Emil Renner Berthing,
Richard Cochran, Andrew Lunn, Heiner Kallweit, Peter Geis,
Yanhong Wang
In-Reply-To: <20221216070632.11444-1-yanhong.wang@starfivetech.com>
Add JH7110 ethernet device node to support gmac driver for the JH7110
RISC-V SoC.
Signed-off-by: Yanhong Wang <yanhong.wang@starfivetech.com>
---
arch/riscv/boot/dts/starfive/jh7110.dtsi | 93 ++++++++++++++++++++++++
1 file changed, 93 insertions(+)
diff --git a/arch/riscv/boot/dts/starfive/jh7110.dtsi b/arch/riscv/boot/dts/starfive/jh7110.dtsi
index c22e8f1d2640..c6de6e3b1a25 100644
--- a/arch/riscv/boot/dts/starfive/jh7110.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7110.dtsi
@@ -433,5 +433,98 @@
reg-shift = <2>;
status = "disabled";
};
+
+ stmmac_axi_setup: stmmac-axi-config {
+ snps,lpi_en;
+ snps,wr_osr_lmt = <4>;
+ snps,rd_osr_lmt = <4>;
+ snps,blen = <256 128 64 32 0 0 0>;
+ };
+
+ gmac0: ethernet@16030000 {
+ compatible = "starfive,jh7110-dwmac", "snps,dwmac-5.20";
+ reg = <0x0 0x16030000 0x0 0x10000>;
+ clocks = <&aoncrg JH7110_AONCLK_GMAC0_AXI>,
+ <&aoncrg JH7110_AONCLK_GMAC0_AHB>,
+ <&syscrg JH7110_SYSCLK_GMAC0_PTP>,
+ <&aoncrg JH7110_AONCLK_GMAC0_TX>,
+ <&syscrg JH7110_SYSCLK_GMAC0_GTXC>,
+ <&syscrg JH7110_SYSCLK_GMAC0_GTXCLK>;
+ clock-names = "stmmaceth", "pclk", "ptp_ref",
+ "tx", "gtxc", "gtx";
+ resets = <&aoncrg JH7110_AONRST_GMAC0_AXI>,
+ <&aoncrg JH7110_AONRST_GMAC0_AHB>;
+ reset-names = "stmmaceth", "ahb";
+ interrupts = <7>, <6>, <5>;
+ interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
+ phy-mode = "rgmii-id";
+ snps,multicast-filter-bins = <64>;
+ snps,perfect-filter-entries = <8>;
+ rx-fifo-depth = <2048>;
+ tx-fifo-depth = <2048>;
+ snps,fixed-burst;
+ snps,no-pbl-x8;
+ snps,force_thresh_dma_mode;
+ snps,axi-config = <&stmmac_axi_setup>;
+ snps,tso;
+ snps,en-tx-lpi-clockgating;
+ snps,txpbl = <16>;
+ snps,rxpbl = <16>;
+ status = "disabled";
+ phy-handle = <&phy0>;
+
+ mdio0: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+ };
+
+ gmac1: ethernet@16040000 {
+ compatible = "starfive,jh7110-dwmac", "snps,dwmac-5.20";
+ reg = <0x0 0x16040000 0x0 0x10000>;
+ clocks = <&syscrg JH7110_SYSCLK_GMAC1_AXI>,
+ <&syscrg JH7110_SYSCLK_GMAC1_AHB>,
+ <&syscrg JH7110_SYSCLK_GMAC1_PTP>,
+ <&syscrg JH7110_SYSCLK_GMAC1_TX>,
+ <&syscrg JH7110_SYSCLK_GMAC1_GTXC>,
+ <&syscrg JH7110_SYSCLK_GMAC1_GTXCLK>;
+ clock-names = "stmmaceth", "pclk", "ptp_ref",
+ "tx", "gtxc", "gtx";
+ resets = <&syscrg JH7110_SYSRST_GMAC1_AXI>,
+ <&syscrg JH7110_SYSRST_GMAC1_AHB>;
+ reset-names = "stmmaceth", "ahb";
+ interrupts = <78>, <77>, <76>;
+ interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
+ phy-mode = "rgmii-id";
+ snps,multicast-filter-bins = <64>;
+ snps,perfect-filter-entries = <8>;
+ rx-fifo-depth = <2048>;
+ tx-fifo-depth = <2048>;
+ snps,fixed-burst;
+ snps,no-pbl-x8;
+ snps,force_thresh_dma_mode;
+ snps,axi-config = <&stmmac_axi_setup>;
+ snps,tso;
+ snps,en-tx-lpi-clockgating;
+ snps,txpbl = <16>;
+ snps,rxpbl = <16>;
+ status = "disabled";
+ phy-handle = <&phy1>;
+
+ mdio1: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+ };
+ };
};
};
--
2.17.1
^ permalink raw reply related
* [PATCH v2 0/9] Add Ethernet driver for StarFive JH7110 SoC
From: Yanhong Wang @ 2022-12-16 7:06 UTC (permalink / raw)
To: linux-riscv, netdev, devicetree, linux-kernel
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Emil Renner Berthing,
Richard Cochran, Andrew Lunn, Heiner Kallweit, Peter Geis,
Yanhong Wang
This series adds ethernet support for the StarFive JH7110 RISC-V SoC.
The series includes PHY and MAC drivers. The PHY model is
YT8531 (from Motorcomm Inc), and the MAC version is dwmac-5.20
(from Synopsys DesignWare). For more information and support,
you can visit RVspace wiki[1].
This patchset should be applied after the patchset [2], [3], [4].
[1] https://wiki.rvspace.org/
[2] https://lore.kernel.org/all/20221118010627.70576-1-hal.feng@starfivetech.com/
[3] https://lore.kernel.org/all/20221118011108.70715-1-hal.feng@starfivetech.com/
[4] https://lore.kernel.org/all/20221118011714.70877-1-hal.feng@starfivetech.com/
Changes in v2:
- Recovered the author of the 1st and 3rd patches back to Emil Renner Berthing.
- Added a new patch to update maxitems number of resets property in 'snps,dwmac.yaml'.
- Fixed the check errors reported by "make dt_binding_check".
- Renamed the dt-binding 'starfive,dwmac-plat.yaml' to 'starfive,jh71x0-dwmac.yaml'.
- Updated the example context in the dt-binding 'starfive,jh71x0-dwmac.yaml'.
- Added new dt-binding 'motorcomm,yt8531.yaml' to describe details of phy clock
delay configuration parameters.
- Added more comments for PHY driver setting. For more details, see
'motorcomm,yt8531.yaml'.
- Moved mdio device tree node from 'jh7110-starfive-visionfive-v2.dts' to 'jh7110.dtsi'.
- Re-worded the commit message of several patches.
- Renamed all the functions with starfive_eth_plat prefix in 'dwmac-starfive-plat.c'.
- Added "starfive,jh7100-dwmac" compatible string and special init to support JH7100.
v1: https://patchwork.kernel.org/project/linux-riscv/patch/20221201090242.2381-8-yanhong.wang@starfivetech.com/
Emil Renner Berthing (2):
dt-bindings: net: snps,dwmac: Add dwmac-5.20 version
net: stmmac: platform: Add snps,dwmac-5.20 IP compatible string
Yanhong Wang (7):
dt-bindings: net: snps,dwmac: Update the maxitems number of resets and
reset-names
dt-bindings: net: Add bindings for StarFive dwmac
dt-bindings: net: motorcomm: add support for Motorcomm YT8531
net: phy: motorcomm: Add YT8531 phy support
net: stmmac: Add glue layer for StarFive JH71x0 SoCs
riscv: dts: starfive: jh7110: Add ethernet device node
riscv: dts: starfive: visionfive-v2: Add phy clock delay train
configuration
.../bindings/net/motorcomm,yt8531.yaml | 111 ++++++++++
.../devicetree/bindings/net/snps,dwmac.yaml | 20 +-
.../bindings/net/starfive,jh71x0-dwmac.yaml | 103 +++++++++
MAINTAINERS | 7 +
.../jh7110-starfive-visionfive-v2.dts | 28 +++
arch/riscv/boot/dts/starfive/jh7110.dtsi | 93 ++++++++
drivers/net/ethernet/stmicro/stmmac/Kconfig | 12 ++
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
.../stmicro/stmmac/dwmac-starfive-plat.c | 167 +++++++++++++++
.../ethernet/stmicro/stmmac/stmmac_platform.c | 3 +-
drivers/net/phy/Kconfig | 3 +-
drivers/net/phy/motorcomm.c | 202 ++++++++++++++++++
12 files changed, 744 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/motorcomm,yt8531.yaml
create mode 100644 Documentation/devicetree/bindings/net/starfive,jh71x0-dwmac.yaml
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-starfive-plat.c
base-commit: 094226ad94f471a9f19e8f8e7140a09c2625abaa
prerequisite-patch-id: 8ebfffa09b478904bf7c516f76e2d824ddb60140
prerequisite-patch-id: e8dd8258a4c4062eee2cf07c4607d52baea71f3a
prerequisite-patch-id: d050d884d7b091ff30508a70f5ce5164bb3b72e5
prerequisite-patch-id: 0e41f8cfd4861fcbf6f2e6a2559ce28f0450299e
prerequisite-patch-id: 6e1652501859b85f101ff3b15ced585d43c71c1b
prerequisite-patch-id: 587628a67adad5c655e5f998bf6c4a368ec07d3c
prerequisite-patch-id: 596490c0e397df6c0249c1306fbb1d5bf00b5b83
prerequisite-patch-id: dc873317826b50364344b25ac5cd74e811403f3d
prerequisite-patch-id: a50150f41d8e874553023187e22eb24dffae8d16
prerequisite-patch-id: 735e62255c75801bdc4c0b4107850bce821ff7f5
prerequisite-patch-id: 9d2e83a2dd43e193f534283fab73e90b4f435043
prerequisite-patch-id: 7a43e0849a9afa3c6f83547fd16d9271b07619e5
prerequisite-patch-id: e7aa6fb05314bad6d94c465f3f59969871bf3d2e
prerequisite-patch-id: 6276b2a23818c65ff2ad3d65b562615690cffee9
prerequisite-patch-id: d834ece14ffb525b8c3e661e78736692f33fca9b
prerequisite-patch-id: 4c17a3ce4dae9b788795d915bf775630f5c43c53
prerequisite-patch-id: dabb913fd478e97593e45c23fee4be9fd807f851
prerequisite-patch-id: ba61df106fbe2ada21e8f22c3d2cfaf7809c84b6
prerequisite-patch-id: 287572fb64f83f5d931034f7c75674907584a087
prerequisite-patch-id: 536114f0732646095ef5302a165672b3290d4c75
prerequisite-patch-id: 258ea5f9b8bf41b6981345dcc81795f25865d38f
prerequisite-patch-id: 8b6f2c9660c0ac0ee4e73e4c21aca8e6b75e81b9
prerequisite-patch-id: e09e995700a814a763aa304ad3881a7222acf556
prerequisite-patch-id: 841cd71b556b480d6a5a5e332eeca70d6a76ec3f
prerequisite-patch-id: d074c7ffa2917a9f754d5801e3f67bc980f9de4c
prerequisite-patch-id: 5f59bc7cbbf1230e5ff4761fa7c1116d4e6e5d71
prerequisite-patch-id: d5da3475c6a3588e11a1678feb565bdd459b548e
--
2.17.1
^ permalink raw reply
* [PATCH v2 7/9] net: stmmac: Add glue layer for StarFive JH71x0 SoCs
From: Yanhong Wang @ 2022-12-16 7:06 UTC (permalink / raw)
To: linux-riscv, netdev, devicetree, linux-kernel
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Emil Renner Berthing,
Richard Cochran, Andrew Lunn, Heiner Kallweit, Peter Geis,
Yanhong Wang
In-Reply-To: <20221216070632.11444-1-yanhong.wang@starfivetech.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="n", Size: 7343 bytes --]
This adds StarFive dwmac driver support on the StarFive JH71x0 SoCs.
Signed-off-by: Yanhong Wang <yanhong.wang@starfivetech.com>
Co-developed-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
---
MAINTAINERS | 1 +
drivers/net/ethernet/stmicro/stmmac/Kconfig | 12 ++
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
.../stmicro/stmmac/dwmac-starfive-plat.c | 167 ++++++++++++++++++
4 files changed, 181 insertions(+)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-starfive-plat.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 1ff68b8524d2..c7d3229330aa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19609,6 +19609,7 @@ F: include/dt-bindings/clock/starfive*
STARFIVE DWMAC GLUE LAYER
M: Yanhong Wang <yanhong.wang@starfivetech.com>
S: Maintained
+F: Documentation/devicetree/bindings/net/dwmac-starfive-plat.c
F: Documentation/devicetree/bindings/net/motorcomm,yt8531.yaml
F: Documentation/devicetree/bindings/net/starfive,jh71x0-dwmac.yaml
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 31ff35174034..ca3d4dd95a95 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -235,6 +235,18 @@ config DWMAC_INTEL_PLAT
the stmmac device driver. This driver is used for the Intel Keem Bay
SoC.
+config DWMAC_STARFIVE_PLAT
+ tristate "StarFive dwmac support"
+ depends on OF && COMMON_CLK
+ depends on STMMAC_ETH
+ default SOC_STARFIVE
+ help
+ Support for ethernet controllers on StarFive RISC-V SoCs
+
+ This selects the StarFive platform specific glue layer support for
+ the stmmac device driver. This driver is used for StarFive JH71x0
+ ethernet controller.
+
config DWMAC_VISCONTI
tristate "Toshiba Visconti DWMAC support"
default ARCH_VISCONTI
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index d4e12e9ace4f..a63ab0ab5071 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_DWMAC_DWC_QOS_ETH) += dwmac-dwc-qos-eth.o
obj-$(CONFIG_DWMAC_INTEL_PLAT) += dwmac-intel-plat.o
obj-$(CONFIG_DWMAC_GENERIC) += dwmac-generic.o
obj-$(CONFIG_DWMAC_IMX8) += dwmac-imx.o
+obj-$(CONFIG_DWMAC_STARFIVE_PLAT) += dwmac-starfive-plat.o
obj-$(CONFIG_DWMAC_VISCONTI) += dwmac-visconti.o
stmmac-platform-objs:= stmmac_platform.o
dwmac-altr-socfpga-objs := altr_tse_pcs.o dwmac-socfpga.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive-plat.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive-plat.c
new file mode 100644
index 000000000000..f8b68dd53c91
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive-plat.c
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * StarFive DWMAC platform driver
+ *
+ * Copyright(C) 2022 StarFive Technology Co., Ltd.
+ *
+ */
+
+#include <linux/mfd/syscon.h>
+#include <linux/of_device.h>
+#include <linux/regmap.h>
+#include "stmmac_platform.h"
+
+struct starfive_dwmac {
+ struct device *dev;
+ struct clk *clk_tx;
+ struct clk *clk_gtx;
+ struct clk *clk_gtxc;
+};
+
+#define JH7100_SYSMAIN_REGISTER28 0x70
+/* The value below is not a typo, just really bad naming by StarFive ¯\_(ツ)_/¯ */
+#define JH7100_SYSMAIN_REGISTER49 0xc8
+
+static int starfive_eth_plat_jh7100_syscon_init(struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ struct regmap *sysmain;
+ u32 gtxclk_dlychain;
+ int ret;
+
+ sysmain = syscon_regmap_lookup_by_phandle(np, "starfive,syscon");
+ if (IS_ERR(sysmain))
+ return dev_err_probe(dev, PTR_ERR(sysmain),
+ "error getting sysmain registers\n");
+
+ /* Choose RGMII interface to the phy.
+ * TODO: support other interfaces once we know the meaning of other
+ * values in the register
+ */
+ ret = regmap_update_bits(sysmain, JH7100_SYSMAIN_REGISTER28, 0x7, 1);
+ if (ret)
+ return dev_err_probe(dev, ret, "error selecting gmac interface\n");
+
+ if (!of_property_read_u32(np, "starfive,gtxclk-dlychain", >xclk_dlychain)) {
+ ret = regmap_write(sysmain, JH7100_SYSMAIN_REGISTER49, gtxclk_dlychain);
+ if (ret)
+ return dev_err_probe(dev, ret, "error selecting gtxclk delay chain\n");
+ }
+
+ return 0;
+}
+
+static void starfive_eth_plat_fix_mac_speed(void *priv, unsigned int speed)
+{
+ struct starfive_dwmac *dwmac = priv;
+ unsigned long rate;
+ int err;
+
+ switch (speed) {
+ case SPEED_1000:
+ rate = 125000000;
+ break;
+ case SPEED_100:
+ rate = 25000000;
+ break;
+ case SPEED_10:
+ rate = 2500000;
+ break;
+ default:
+ dev_err(dwmac->dev, "invalid speed %u\n", speed);
+ return;
+ }
+
+ err = clk_set_rate(dwmac->clk_gtx, rate);
+ if (err)
+ dev_err(dwmac->dev, "failed to set tx rate %lu\n", rate);
+}
+
+static int starfive_eth_plat_probe(struct platform_device *pdev)
+{
+ struct plat_stmmacenet_data *plat_dat;
+ struct stmmac_resources stmmac_res;
+ struct starfive_dwmac *dwmac;
+ int (*syscon_init)(struct device *dev);
+ int err;
+
+ err = stmmac_get_platform_resources(pdev, &stmmac_res);
+ if (err)
+ return err;
+
+ plat_dat = stmmac_probe_config_dt(pdev, stmmac_res.mac);
+ if (IS_ERR(plat_dat)) {
+ dev_err(&pdev->dev, "dt configuration failed\n");
+ return PTR_ERR(plat_dat);
+ }
+
+ dwmac = devm_kzalloc(&pdev->dev, sizeof(*dwmac), GFP_KERNEL);
+ if (!dwmac)
+ return -ENOMEM;
+
+ syscon_init = of_device_get_match_data(&pdev->dev);
+ if (syscon_init) {
+ err = syscon_init(&pdev->dev);
+ if (err)
+ return err;
+ }
+
+ dwmac->clk_tx = devm_clk_get_enabled(&pdev->dev, "tx");
+ if (IS_ERR(dwmac->clk_tx))
+ return dev_err_probe(&pdev->dev, PTR_ERR(dwmac->clk_tx),
+ "error getting tx clock\n");
+
+ dwmac->clk_gtx = devm_clk_get_enabled(&pdev->dev, "gtx");
+ if (IS_ERR(dwmac->clk_gtx))
+ return dev_err_probe(&pdev->dev, PTR_ERR(dwmac->clk_gtx),
+ "error getting gtx clock\n");
+
+ /* Only StarFive JH7110 SoC support gtxc clock */
+ if (of_device_is_compatible(pdev->dev.of_node, "starfive,jh7110-dwmac")) {
+ dwmac->clk_gtxc = devm_clk_get_enabled(&pdev->dev, "gtxc");
+ if (IS_ERR(dwmac->clk_gtxc))
+ return dev_err_probe(&pdev->dev, PTR_ERR(dwmac->clk_gtxc),
+ "error getting gtxc clock\n");
+ }
+
+ dwmac->dev = &pdev->dev;
+ plat_dat->fix_mac_speed = starfive_eth_plat_fix_mac_speed;
+ plat_dat->init = NULL;
+ plat_dat->bsp_priv = dwmac;
+ plat_dat->dma_cfg->dche = true;
+
+ err = stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
+ if (err) {
+ stmmac_remove_config_dt(pdev, plat_dat);
+ return err;
+ }
+
+ return 0;
+}
+
+static const struct of_device_id starfive_eth_plat_match[] = {
+ {
+ .compatible = "starfive,jh7110-dwmac"
+ },
+ {
+ .compatible = "starfive,jh7100-dwmac",
+ .data = starfive_eth_plat_jh7100_syscon_init,
+ },
+ { }
+};
+
+static struct platform_driver starfive_eth_plat_driver = {
+ .probe = starfive_eth_plat_probe,
+ .remove = stmmac_pltfr_remove,
+ .driver = {
+ .name = "starfive-eth-plat",
+ .pm = &stmmac_pltfr_pm_ops,
+ .of_match_table = starfive_eth_plat_match,
+ },
+};
+
+module_platform_driver(starfive_eth_plat_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("StarFive DWMAC platform driver");
+MODULE_AUTHOR("Yanhong Wang <yanhong.wang@starfivetech.com>");
--
2.17.1
^ permalink raw reply related
* [PATCH v2 3/9] net: stmmac: platform: Add snps,dwmac-5.20 IP compatible string
From: Yanhong Wang @ 2022-12-16 7:06 UTC (permalink / raw)
To: linux-riscv, netdev, devicetree, linux-kernel
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Emil Renner Berthing,
Richard Cochran, Andrew Lunn, Heiner Kallweit, Peter Geis,
Yanhong Wang
In-Reply-To: <20221216070632.11444-1-yanhong.wang@starfivetech.com>
From: Emil Renner Berthing <kernel@esmil.dk>
Add "snps,dwmac-5.20" compatible string for 5.20 version that can avoid
to define some platform data in the glue layer.
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Yanhong Wang <yanhong.wang@starfivetech.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 50f6b4a14be4..cc3b701af802 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -519,7 +519,8 @@ stmmac_probe_config_dt(struct platform_device *pdev, u8 *mac)
if (of_device_is_compatible(np, "snps,dwmac-4.00") ||
of_device_is_compatible(np, "snps,dwmac-4.10a") ||
of_device_is_compatible(np, "snps,dwmac-4.20a") ||
- of_device_is_compatible(np, "snps,dwmac-5.10a")) {
+ of_device_is_compatible(np, "snps,dwmac-5.10a") ||
+ of_device_is_compatible(np, "snps,dwmac-5.20")) {
plat->has_gmac4 = 1;
plat->has_gmac = 0;
plat->pmt = 1;
--
2.17.1
^ permalink raw reply related
* [PATCH v2 1/9] dt-bindings: net: snps,dwmac: Add dwmac-5.20 version
From: Yanhong Wang @ 2022-12-16 7:06 UTC (permalink / raw)
To: linux-riscv, netdev, devicetree, linux-kernel
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Emil Renner Berthing,
Richard Cochran, Andrew Lunn, Heiner Kallweit, Peter Geis,
Yanhong Wang
In-Reply-To: <20221216070632.11444-1-yanhong.wang@starfivetech.com>
From: Emil Renner Berthing <kernel@esmil.dk>
Add dwmac-5.20 IP version to snps.dwmac.yaml
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Yanhong Wang <yanhong.wang@starfivetech.com>
---
Documentation/devicetree/bindings/net/snps,dwmac.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 13b984076af5..e26c3e76ebb7 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -30,6 +30,7 @@ select:
- snps,dwmac-4.10a
- snps,dwmac-4.20a
- snps,dwmac-5.10a
+ - snps,dwmac-5.20
- snps,dwxgmac
- snps,dwxgmac-2.10
@@ -87,6 +88,7 @@ properties:
- snps,dwmac-4.10a
- snps,dwmac-4.20a
- snps,dwmac-5.10a
+ - snps,dwmac-5.20
- snps,dwxgmac
- snps,dwxgmac-2.10
@@ -393,6 +395,7 @@ allOf:
- snps,dwmac-3.50a
- snps,dwmac-4.10a
- snps,dwmac-4.20a
+ - snps,dwmac-5.20
- snps,dwxgmac
- snps,dwxgmac-2.10
- st,spear600-gmac
@@ -447,6 +450,7 @@ allOf:
- snps,dwmac-4.10a
- snps,dwmac-4.20a
- snps,dwmac-5.10a
+ - snps,dwmac-5.20
- snps,dwxgmac
- snps,dwxgmac-2.10
- st,spear600-gmac
--
2.17.1
^ permalink raw reply related
* [PATCH v2 6/9] net: phy: motorcomm: Add YT8531 phy support
From: Yanhong Wang @ 2022-12-16 7:06 UTC (permalink / raw)
To: linux-riscv, netdev, devicetree, linux-kernel
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Emil Renner Berthing,
Richard Cochran, Andrew Lunn, Heiner Kallweit, Peter Geis,
Yanhong Wang
In-Reply-To: <20221216070632.11444-1-yanhong.wang@starfivetech.com>
This adds basic support for the Motorcomm YT8531
Gigabit Ethernet PHY.
Signed-off-by: Yanhong Wang <yanhong.wang@starfivetech.com>
---
drivers/net/phy/Kconfig | 3 +-
drivers/net/phy/motorcomm.c | 202 ++++++++++++++++++++++++++++++++++++
2 files changed, 204 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index c57a0262fb64..86399254d9ff 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -258,9 +258,10 @@ config MICROSEMI_PHY
config MOTORCOMM_PHY
tristate "Motorcomm PHYs"
+ default SOC_STARFIVE
help
Enables support for Motorcomm network PHYs.
- Currently supports the YT8511 gigabit PHY.
+ Currently supports the YT8511 and YT8531 gigabit PHYs.
config NATIONAL_PHY
tristate "National Semiconductor PHYs"
diff --git a/drivers/net/phy/motorcomm.c b/drivers/net/phy/motorcomm.c
index 7e6ac2c5e27e..bca03185b338 100644
--- a/drivers/net/phy/motorcomm.c
+++ b/drivers/net/phy/motorcomm.c
@@ -3,13 +3,17 @@
* Driver for Motorcomm PHYs
*
* Author: Peter Geis <pgwipeout@gmail.com>
+ *
*/
+#include <linux/bitops.h>
#include <linux/kernel.h>
#include <linux/module.h>
+#include <linux/of.h>
#include <linux/phy.h>
#define PHY_ID_YT8511 0x0000010a
+#define PHY_ID_YT8531 0x4f51e91b
#define YT8511_PAGE_SELECT 0x1e
#define YT8511_PAGE 0x1f
@@ -17,6 +21,10 @@
#define YT8511_EXT_DELAY_DRIVE 0x0d
#define YT8511_EXT_SLEEP_CTRL 0x27
+#define YTPHY_EXT_SMI_SDS_PHY 0xa000
+#define YTPHY_EXT_CHIP_CONFIG 0xa001
+#define YTPHY_EXT_RGMII_CONFIG1 0xa003
+
/* 2b00 25m from pll
* 2b01 25m from xtl *default*
* 2b10 62.m from pll
@@ -38,6 +46,51 @@
#define YT8511_DELAY_FE_TX_EN (0xf << 12)
#define YT8511_DELAY_FE_TX_DIS (0x2 << 12)
+struct ytphy_reg_field {
+ char *name;
+ u32 mask;
+ u8 dflt; /* Default value */
+};
+
+struct ytphy_priv_t {
+ u32 tx_inverted_1000;
+ u32 tx_inverted_100;
+ u32 tx_inverted_10;
+};
+
+/* rx_delay_sel: RGMII rx clock delay train configuration, about 150ps per
+ * step. Delay = 150ps * N
+ *
+ * tx_delay_sel_fe: RGMII tx clock delay train configuration when speed is
+ * 100Mbps or 10Mbps, it's 150ps per step. Delay = 150ps * N
+ *
+ * tx_delay_sel: RGMII tx clock delay train configuration when speed is
+ * 1000Mbps, it's 150ps per step. Delay = 150ps * N
+ */
+static const struct ytphy_reg_field ytphy_rxtxd_grp[] = {
+ { "rx_delay_sel", GENMASK(13, 10), 0x0 },
+ { "tx_delay_sel_fe", GENMASK(7, 4), 0xf },
+ { "tx_delay_sel", GENMASK(3, 0), 0x1 }
+};
+
+/* tx_inverted_x: Use original or inverted RGMII TX_CLK to drive the RGMII
+ * TX_CLK delay train configuration when speed is
+ * xMbps(10/100/1000Mbps).
+ * 0: original, 1: inverted
+ */
+static const struct ytphy_reg_field ytphy_txinver_grp[] = {
+ { "tx_inverted_1000", BIT(14), 0x0 },
+ { "tx_inverted_100", BIT(14), 0x0 },
+ { "tx_inverted_10", BIT(14), 0x0 }
+};
+
+/* rxc_dly_en: RGMII clk 2ns delay control bit.
+ * 0: disable 1: enable
+ */
+static const struct ytphy_reg_field ytphy_rxden_grp[] = {
+ { "rxc_dly_en", BIT(8), 0x1 }
+};
+
static int yt8511_read_page(struct phy_device *phydev)
{
return __phy_read(phydev, YT8511_PAGE_SELECT);
@@ -48,6 +101,33 @@ static int yt8511_write_page(struct phy_device *phydev, int page)
return __phy_write(phydev, YT8511_PAGE_SELECT, page);
};
+static int ytphy_read_ext(struct phy_device *phydev, u32 regnum)
+{
+ int ret;
+ int val;
+
+ ret = __phy_write(phydev, YT8511_PAGE_SELECT, regnum);
+ if (ret < 0)
+ return ret;
+
+ val = __phy_read(phydev, YT8511_PAGE);
+
+ return val;
+}
+
+static int ytphy_write_ext(struct phy_device *phydev, u32 regnum, u16 val)
+{
+ int ret;
+
+ ret = __phy_write(phydev, YT8511_PAGE_SELECT, regnum);
+ if (ret < 0)
+ return ret;
+
+ ret = __phy_write(phydev, YT8511_PAGE, val);
+
+ return ret;
+}
+
static int yt8511_config_init(struct phy_device *phydev)
{
int oldpage, ret = 0;
@@ -111,6 +191,116 @@ static int yt8511_config_init(struct phy_device *phydev)
return phy_restore_page(phydev, oldpage, ret);
}
+static int ytphy_config_init(struct phy_device *phydev)
+{
+ struct device_node *of_node;
+ u32 val;
+ u32 mask;
+ u32 cfg;
+ int ret;
+ int i = 0;
+
+ of_node = phydev->mdio.dev.of_node;
+ if (of_node) {
+ ret = of_property_read_u32(of_node, ytphy_rxden_grp[0].name, &cfg);
+ if (!ret) {
+ mask = ytphy_rxden_grp[0].mask;
+ val = ytphy_read_ext(phydev, YTPHY_EXT_CHIP_CONFIG);
+
+ /* check the cfg overflow or not */
+ cfg = cfg > mask >> (ffs(mask) - 1) ? mask : cfg;
+
+ val &= ~mask;
+ val |= FIELD_PREP(mask, cfg);
+ ytphy_write_ext(phydev, YTPHY_EXT_CHIP_CONFIG, val);
+ }
+
+ val = ytphy_read_ext(phydev, YTPHY_EXT_RGMII_CONFIG1);
+ for (i = 0; i < ARRAY_SIZE(ytphy_rxtxd_grp); i++) {
+ ret = of_property_read_u32(of_node, ytphy_rxtxd_grp[i].name, &cfg);
+ if (!ret) {
+ mask = ytphy_rxtxd_grp[i].mask;
+
+ /* check the cfg overflow or not */
+ cfg = cfg > mask >> (ffs(mask) - 1) ? mask : cfg;
+
+ val &= ~mask;
+ val |= cfg << (ffs(mask) - 1);
+ }
+ }
+ return ytphy_write_ext(phydev, YTPHY_EXT_RGMII_CONFIG1, val);
+ }
+
+ phydev_err(phydev, "Get of node fail\n");
+
+ return -EINVAL;
+}
+
+static void ytphy_link_change_notify(struct phy_device *phydev)
+{
+ u32 val;
+ struct ytphy_priv_t *ytphy_priv = phydev->priv;
+
+ if (phydev->speed < 0)
+ return;
+
+ val = ytphy_read_ext(phydev, YTPHY_EXT_RGMII_CONFIG1);
+ switch (phydev->speed) {
+ case SPEED_1000:
+ val &= ~ytphy_txinver_grp[0].mask;
+ val |= FIELD_PREP(ytphy_txinver_grp[0].mask,
+ ytphy_priv->tx_inverted_1000);
+ break;
+
+ case SPEED_100:
+ val &= ~ytphy_txinver_grp[1].mask;
+ val |= FIELD_PREP(ytphy_txinver_grp[1].mask,
+ ytphy_priv->tx_inverted_100);
+ break;
+
+ case SPEED_10:
+ val &= ~ytphy_txinver_grp[2].mask;
+ val |= FIELD_PREP(ytphy_txinver_grp[2].mask,
+ ytphy_priv->tx_inverted_10);
+ break;
+
+ default:
+ break;
+ }
+
+ ytphy_write_ext(phydev, YTPHY_EXT_RGMII_CONFIG1, val);
+}
+
+static int yt8531_probe(struct phy_device *phydev)
+{
+ struct ytphy_priv_t *priv;
+ const struct device_node *of_node;
+ u32 val;
+ int ret;
+
+ priv = devm_kzalloc(&phydev->mdio.dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ of_node = phydev->mdio.dev.of_node;
+ if (of_node) {
+ ret = of_property_read_u32(of_node, ytphy_txinver_grp[0].name, &val);
+ if (!ret)
+ priv->tx_inverted_1000 = val;
+
+ ret = of_property_read_u32(of_node, ytphy_txinver_grp[1].name, &val);
+ if (!ret)
+ priv->tx_inverted_100 = val;
+
+ ret = of_property_read_u32(of_node, ytphy_txinver_grp[2].name, &val);
+ if (!ret)
+ priv->tx_inverted_10 = val;
+ }
+ phydev->priv = priv;
+
+ return 0;
+}
+
static struct phy_driver motorcomm_phy_drvs[] = {
{
PHY_ID_MATCH_EXACT(PHY_ID_YT8511),
@@ -120,6 +310,17 @@ static struct phy_driver motorcomm_phy_drvs[] = {
.resume = genphy_resume,
.read_page = yt8511_read_page,
.write_page = yt8511_write_page,
+ }, {
+ PHY_ID_MATCH_EXACT(PHY_ID_YT8531),
+ .name = "YT8531 Gigabit Ethernet",
+ .probe = yt8531_probe,
+ .config_init = ytphy_config_init,
+ .read_status = genphy_read_status,
+ .suspend = genphy_suspend,
+ .resume = genphy_resume,
+ .read_page = yt8511_read_page,
+ .write_page = yt8511_write_page,
+ .link_change_notify = ytphy_link_change_notify,
},
};
@@ -131,6 +332,7 @@ MODULE_LICENSE("GPL");
static const struct mdio_device_id __maybe_unused motorcomm_tbl[] = {
{ PHY_ID_MATCH_EXACT(PHY_ID_YT8511) },
+ { PHY_ID_MATCH_EXACT(PHY_ID_YT8531) },
{ /* sentinal */ }
};
--
2.17.1
^ permalink raw reply related
* [PATCH v2 5/9] dt-bindings: net: motorcomm: add support for Motorcomm YT8531
From: Yanhong Wang @ 2022-12-16 7:06 UTC (permalink / raw)
To: linux-riscv, netdev, devicetree, linux-kernel
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Emil Renner Berthing,
Richard Cochran, Andrew Lunn, Heiner Kallweit, Peter Geis,
Yanhong Wang
In-Reply-To: <20221216070632.11444-1-yanhong.wang@starfivetech.com>
Add support for Motorcomm Technology YT8531 10/100/1000 Ethernet PHY.
The document describe details of clock delay train configuration.
Signed-off-by: Yanhong Wang <yanhong.wang@starfivetech.com>
---
.../bindings/net/motorcomm,yt8531.yaml | 111 ++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 112 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/motorcomm,yt8531.yaml
diff --git a/Documentation/devicetree/bindings/net/motorcomm,yt8531.yaml b/Documentation/devicetree/bindings/net/motorcomm,yt8531.yaml
new file mode 100644
index 000000000000..c5b8a09a78bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/motorcomm,yt8531.yaml
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/motorcomm,yt8531.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Motorcomm YT8531 Gigabit Ethernet PHY
+
+maintainers:
+ - Yanhong Wang <yanhong.wang@starfivetech.com>
+
+select:
+ properties:
+ $nodename:
+ pattern: "^ethernet-phy(@[a-f0-9]+)?$"
+
+ required:
+ - $nodename
+
+properties:
+ $nodename:
+ pattern: "^ethernet-phy(@[a-f0-9]+)?$"
+
+ reg:
+ minimum: 0
+ maximum: 31
+ description:
+ The ID number for the PHY.
+
+ rxc_dly_en:
+ description: |
+ RGMII Receive PHY Clock Delay defined with fixed 2ns.This is used for
+ PHY that have configurable RX internal delays. If this property set
+ to 1, then automatically add 2ns delay pad for Receive PHY clock.
+ enum: [0, 1]
+ default: 0
+
+ rx_delay_sel:
+ description: |
+ This is supplement to rxc_dly_en property,and it can
+ be specified in 150ps(pico seconds) steps. The effective
+ delay is: 150ps * N.
+ minimum: 0
+ maximum: 15
+ default: 0
+
+ tx_delay_sel_fe:
+ description: |
+ RGMII Transmit PHY Clock Delay defined in pico seconds.This is used for
+ PHY's that have configurable TX internal delays when speed is 100Mbps
+ or 10Mbps. It can be specified in 150ps steps, the effective delay
+ is: 150ps * N.
+ minimum: 0
+ maximum: 15
+ default: 15
+
+ tx_delay_sel:
+ description: |
+ RGMII Transmit PHY Clock Delay defined in pico seconds.This is used for
+ PHY's that have configurable TX internal delays when speed is 1000Mbps.
+ It can be specified in 150ps steps, the effective delay is: 150ps * N.
+ minimum: 0
+ maximum: 15
+ default: 1
+
+ tx_inverted_10:
+ description: |
+ Use original or inverted RGMII Transmit PHY Clock to drive the RGMII
+ Transmit PHY Clock delay train configuration when speed is 10Mbps.
+ 0: original 1: inverted
+ enum: [0, 1]
+ default: 0
+
+ tx_inverted_100:
+ description: |
+ Use original or inverted RGMII Transmit PHY Clock to drive the RGMII
+ Transmit PHY Clock delay train configuration when speed is 100Mbps.
+ 0: original 1: inverted
+ enum: [0, 1]
+ default: 0
+
+ tx_inverted_1000:
+ description: |
+ Use original or inverted RGMII Transmit PHY Clock to drive the RGMII
+ Transmit PHY Clock delay train configuration when speed is 1000Mbps.
+ 0: original 1: inverted
+ enum: [0, 1]
+ default: 0
+
+required:
+ - reg
+
+additionalProperties: true
+
+examples:
+ - |
+ ethernet {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@0 {
+ reg = <0>;
+
+ rxc_dly_en = <1>;
+ tx_delay_sel_fe = <5>;
+ tx_delay_sel = <0xa>;
+ tx_inverted_10 = <0x1>;
+ tx_inverted_100 = <0x1>;
+ tx_inverted_1000 = <0x1>;
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 166b0009f63c..1ff68b8524d2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19609,6 +19609,7 @@ F: include/dt-bindings/clock/starfive*
STARFIVE DWMAC GLUE LAYER
M: Yanhong Wang <yanhong.wang@starfivetech.com>
S: Maintained
+F: Documentation/devicetree/bindings/net/motorcomm,yt8531.yaml
F: Documentation/devicetree/bindings/net/starfive,jh71x0-dwmac.yaml
STARFIVE PINCTRL DRIVER
--
2.17.1
^ permalink raw reply related
* [PATCH v2 4/9] dt-bindings: net: Add bindings for StarFive dwmac
From: Yanhong Wang @ 2022-12-16 7:06 UTC (permalink / raw)
To: linux-riscv, netdev, devicetree, linux-kernel
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Emil Renner Berthing,
Richard Cochran, Andrew Lunn, Heiner Kallweit, Peter Geis,
Yanhong Wang
In-Reply-To: <20221216070632.11444-1-yanhong.wang@starfivetech.com>
Add documentation to describe StarFive dwmac driver(GMAC).
Signed-off-by: Yanhong Wang <yanhong.wang@starfivetech.com>
---
.../devicetree/bindings/net/snps,dwmac.yaml | 1 +
.../bindings/net/starfive,jh71x0-dwmac.yaml | 103 ++++++++++++++++++
MAINTAINERS | 5 +
3 files changed, 109 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/starfive,jh71x0-dwmac.yaml
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 7870228b4cd3..cdb045d1c618 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -91,6 +91,7 @@ properties:
- snps,dwmac-5.20
- snps,dwxgmac
- snps,dwxgmac-2.10
+ - starfive,jh7110-dwmac
reg:
minItems: 1
diff --git a/Documentation/devicetree/bindings/net/starfive,jh71x0-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh71x0-dwmac.yaml
new file mode 100644
index 000000000000..5cb1272fe959
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/starfive,jh71x0-dwmac.yaml
@@ -0,0 +1,103 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022 StarFive Technology Co., Ltd.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/starfive,jh71x0-dwmac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH71x0 DWMAC glue layer
+
+maintainers:
+ - Yanhong Wang <yanhong.wang@starfivetech.com>
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - starfive,jh7110-dwmac
+ required:
+ - compatible
+
+allOf:
+ - $ref: snps,dwmac.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - starfive,jh7110-dwmac
+ - const: snps,dwmac-5.20
+
+ clocks:
+ items:
+ - description: GMAC main clock
+ - description: GMAC AHB clock
+ - description: PTP clock
+ - description: TX clock
+ - description: GTXC clock
+ - description: GTX clock
+
+ clock-names:
+ items:
+ - const: stmmaceth
+ - const: pclk
+ - const: ptp_ref
+ - const: tx
+ - const: gtxc
+ - const: gtx
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ stmmac_axi_setup: stmmac-axi-config {
+ snps,lpi_en;
+ snps,wr_osr_lmt = <4>;
+ snps,rd_osr_lmt = <4>;
+ snps,blen = <256 128 64 32 0 0 0>;
+ };
+
+ gmac0: ethernet@16030000 {
+ compatible = "starfive,jh7110-dwmac", "snps,dwmac-5.20";
+ reg = <0x16030000 0x10000>;
+ clocks = <&clk 3>, <&clk 2>, <&clk 109>,
+ <&clk 5>, <&clk 111>, <&clk 108>;
+ clock-names = "stmmaceth", "pclk", "ptp_ref",
+ "tx", "gtxc", "gtx";
+ resets = <&rst 1>, <&rst 2>;
+ reset-names = "stmmaceth", "ahb";
+ interrupts = <7>, <6>, <5>;
+ interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
+ phy-mode = "rgmii-id";
+ snps,multicast-filter-bins = <64>;
+ snps,perfect-filter-entries = <8>;
+ rx-fifo-depth = <2048>;
+ tx-fifo-depth = <2048>;
+ snps,fixed-burst;
+ snps,no-pbl-x8;
+ snps,tso;
+ snps,force_thresh_dma_mode;
+ snps,axi-config = <&stmmac_axi_setup>;
+ snps,en-tx-lpi-clockgating;
+ snps,txpbl = <16>;
+ snps,rxpbl = <16>;
+ phy-handle = <&phy0>;
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index a70c1d0f303e..166b0009f63c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19606,6 +19606,11 @@ F: Documentation/devicetree/bindings/clock/starfive*
F: drivers/clk/starfive/
F: include/dt-bindings/clock/starfive*
+STARFIVE DWMAC GLUE LAYER
+M: Yanhong Wang <yanhong.wang@starfivetech.com>
+S: Maintained
+F: Documentation/devicetree/bindings/net/starfive,jh71x0-dwmac.yaml
+
STARFIVE PINCTRL DRIVER
M: Emil Renner Berthing <kernel@esmil.dk>
M: Jianlong Huang <jianlong.huang@starfivetech.com>
--
2.17.1
^ permalink raw reply related
* [PATCH v2 2/9] dt-bindings: net: snps,dwmac: Update the maxitems number of resets and reset-names
From: Yanhong Wang @ 2022-12-16 7:06 UTC (permalink / raw)
To: linux-riscv, netdev, devicetree, linux-kernel
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Emil Renner Berthing,
Richard Cochran, Andrew Lunn, Heiner Kallweit, Peter Geis,
Yanhong Wang
In-Reply-To: <20221216070632.11444-1-yanhong.wang@starfivetech.com>
Some boards(such as StarFive VisionFive v2) require more than one value
which defined by resets property, so the original definition can not
meet the requirements. In order to adapt to different requirements,
adjust the maxitems number from 1 to 3..
Signed-off-by: Yanhong Wang <yanhong.wang@starfivetech.com>
---
.../devicetree/bindings/net/snps,dwmac.yaml | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index e26c3e76ebb7..7870228b4cd3 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -133,12 +133,19 @@ properties:
- ptp_ref
resets:
- maxItems: 1
- description:
- MAC Reset signal.
+ minItems: 1
+ maxItems: 3
+ additionalItems: true
+ items:
+ - description: MAC Reset signal
reset-names:
- const: stmmaceth
+ minItems: 1
+ maxItems: 3
+ additionalItems: true
+ contains:
+ enum:
+ - stmmaceth
power-domains:
maxItems: 1
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net 7/9] rxrpc: Fix I/O thread stop
From: David Howells @ 2022-12-16 6:46 UTC (permalink / raw)
To: Hillf Danton; +Cc: dhowells, netdev, Marc Dionne, linux-afs, linux-kernel
In-Reply-To: <20221216001958.1149-1-hdanton@sina.com>
Hillf Danton <hdanton@sina.com> wrote:
> > @@ -478,13 +479,14 @@ int rxrpc_io_thread(void *data)
> > }
> >
> > set_current_state(TASK_INTERRUPTIBLE);
> > + should_stop = kthread_should_stop();
> > if (!skb_queue_empty(&local->rx_queue) ||
> > !list_empty(&local->call_attend_q)) {
> > __set_current_state(TASK_RUNNING);
> > continue;
> > }
> >
> > - if (kthread_should_stop())
> > + if (should_stop)
> > break;
> > schedule();
> > }
>
> At the second glance still fail to see the difference this change can
> make.
There is a window here:
if (!skb_queue_empty(&local->rx_queue) ...)
continue;
--->
if (kthread_should_stop())
break;
in which an event can happen that should be attended to. For instance the
AF_RXRPC socket being closed, aborting all its calls and stopping the kthread
by doing the final unuse on its rxrpc_local struct - in that order. The
window can be expanded by an interrupt or softirq handler running.
So once we've observed that we've been asked to stop, we need to check if
there's more work to be done and, if so, do that work first.
So by doing:
should_stop = kthread_should_stop();
if (!skb_queue_empty(&local->rx_queue) ...)
continue;
if (should_stop)
break;
we do all outstanding cleanup work before exiting the loop to stop the thread.
David
^ permalink raw reply
* Re: [RFC PATCH 1/6] vdpa: add bind_mm callback
From: Jason Wang @ 2022-12-16 6:37 UTC (permalink / raw)
To: Stefano Garzarella
Cc: virtualization, Andrey Zhadchenko, linux-kernel, kvm,
Michael S. Tsirkin, eperezma, stefanha, netdev
In-Reply-To: <20221214163025.103075-2-sgarzare@redhat.com>
On Thu, Dec 15, 2022 at 12:30 AM Stefano Garzarella <sgarzare@redhat.com> wrote:
>
> This new optional callback is used to bind the device to a specific
> address space so the vDPA framework can use VA when this callback
> is implemented.
>
> Suggested-by: Jason Wang <jasowang@redhat.com>
> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
> ---
> include/linux/vdpa.h | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
> index 6d0f5e4e82c2..34388e21ef3f 100644
> --- a/include/linux/vdpa.h
> +++ b/include/linux/vdpa.h
> @@ -282,6 +282,12 @@ struct vdpa_map_file {
> * @iova: iova to be unmapped
> * @size: size of the area
> * Returns integer: success (0) or error (< 0)
> + * @bind_mm: Bind the device to a specific address space
> + * so the vDPA framework can use VA when this
> + * callback is implemented. (optional)
> + * @vdev: vdpa device
> + * @mm: address space to bind
Do we need an unbind or did a NULL mm mean unbind?
> + * @owner: process that owns the address space
Any reason we need the task_struct here?
Thanks
> * @free: Free resources that belongs to vDPA (optional)
> * @vdev: vdpa device
> */
> @@ -341,6 +347,8 @@ struct vdpa_config_ops {
> u64 iova, u64 size);
> int (*set_group_asid)(struct vdpa_device *vdev, unsigned int group,
> unsigned int asid);
> + int (*bind_mm)(struct vdpa_device *vdev, struct mm_struct *mm,
> + struct task_struct *owner);
>
> /* Free device resources */
> void (*free)(struct vdpa_device *vdev);
> --
> 2.38.1
>
^ permalink raw reply
* Re: [PATCH] wifi: mt76: mt7996: select CONFIG_RELAY
From: Kalle Valo @ 2022-12-16 6:22 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Arnd Bergmann,
Shayne Chen, Sean Wang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Matthias Brugger, linux-wireless,
netdev, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <20221215163133.4152299-1-arnd@kernel.org>
Arnd Bergmann <arnd@kernel.org> writes:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Without CONFIG_RELAY, the driver fails to link:
>
> ERROR: modpost: "relay_flush" [drivers/net/wireless/mediatek/mt76/mt7996/mt7996e.ko] undefined!
> ERROR: modpost: "relay_switch_subbuf" [drivers/net/wireless/mediatek/mt76/mt7996/mt7996e.ko] undefined!
> ERROR: modpost: "relay_open" [drivers/net/wireless/mediatek/mt76/mt7996/mt7996e.ko] undefined!
> ERROR: modpost: "relay_reset" [drivers/net/wireless/mediatek/mt76/mt7996/mt7996e.ko] undefined!
> ERROR: modpost: "relay_file_operations" [drivers/net/wireless/mediatek/mt76/mt7996/mt7996e.ko] undefined!
>
> The same change was done in mt7915 for the corresponding copy of the code.
>
> Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
> See-also: 988845c9361a ("mt76: mt7915: add support for passing chip/firmware debug data to user space")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Felix, should I take this to wireless tree?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH net] devlink: protect devlink dump by the instance lock
From: Jakub Kicinski @ 2022-12-16 4:44 UTC (permalink / raw)
To: davem; +Cc: netdev, edumazet, pabeni, jacob.e.keller, jiri, moshe
In-Reply-To: <20221216044122.1863550-1-kuba@kernel.org>
On Thu, 15 Dec 2022 20:41:22 -0800 Jakub Kicinski wrote:
> Take the instance lock around devlink_nl_fill() when dumping,
> doit takes it already.
>
> We are only dumping basic info so in the worst case we were risking
> data races around the reload statistics. Also note that the reloads
> themselves had not been under the instance lock until recently, so
> the selection of the Fixes tag is inherently questionable.
>
> Fixes: a254c264267e ("devlink: Add reload stats")
On second thought, the drivers can't call reload, so until we got rid
of the big bad mutex there could have been no race. I'll swap the tag
for:
Fixes: d3efc2a6a6d8 ("net: devlink: remove devlink_mutex")
when/if applying.
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
> CC: jiri@nvidia.com
> CC: moshe@mellanox.com
> ---
> net/core/devlink.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/core/devlink.c b/net/core/devlink.c
> index d2df30829083..032d6d0a5ce6 100644
> --- a/net/core/devlink.c
> +++ b/net/core/devlink.c
> @@ -1648,10 +1648,13 @@ static int devlink_nl_cmd_get_dumpit(struct sk_buff *msg,
> continue;
> }
>
> + devl_lock(devlink);
> err = devlink_nl_fill(msg, devlink, DEVLINK_CMD_NEW,
> NETLINK_CB(cb->skb).portid,
> cb->nlh->nlmsg_seq, NLM_F_MULTI);
> + devl_unlock(devlink);
> devlink_put(devlink);
> +
> if (err)
> goto out;
> idx++;
^ permalink raw reply
* [PATCH net] devlink: protect devlink dump by the instance lock
From: Jakub Kicinski @ 2022-12-16 4:41 UTC (permalink / raw)
To: davem; +Cc: netdev, edumazet, pabeni, jacob.e.keller, Jakub Kicinski, jiri,
moshe
Take the instance lock around devlink_nl_fill() when dumping,
doit takes it already.
We are only dumping basic info so in the worst case we were risking
data races around the reload statistics. Also note that the reloads
themselves had not been under the instance lock until recently, so
the selection of the Fixes tag is inherently questionable.
Fixes: a254c264267e ("devlink: Add reload stats")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
CC: jiri@nvidia.com
CC: moshe@mellanox.com
---
net/core/devlink.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/core/devlink.c b/net/core/devlink.c
index d2df30829083..032d6d0a5ce6 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -1648,10 +1648,13 @@ static int devlink_nl_cmd_get_dumpit(struct sk_buff *msg,
continue;
}
+ devl_lock(devlink);
err = devlink_nl_fill(msg, devlink, DEVLINK_CMD_NEW,
NETLINK_CB(cb->skb).portid,
cb->nlh->nlmsg_seq, NLM_F_MULTI);
+ devl_unlock(devlink);
devlink_put(devlink);
+
if (err)
goto out;
idx++;
--
2.38.1
^ permalink raw reply related
* Re: [PATCH 02/15] can: m_can: Wakeup net queue once tx was issued
From: Vincent MAILHOL @ 2022-12-16 4:40 UTC (permalink / raw)
To: Markus Schneider-Pargmann
Cc: Marc Kleine-Budde, Chandrasekar Ramakrishnan, Wolfgang Grandegger,
linux-can, netdev, linux-kernel
In-Reply-To: <20221215093140.fwpezasd6whhk7p7@blmsp>
On Thu. 15 Dec. 2022 at 18:44, Markus Schneider-Pargmann
<msp@baylibre.com> wrote:
> Hi,
>
> On Wed, Dec 14, 2022 at 11:35:43AM +0100, Markus Schneider-Pargmann wrote:
> > Hi Vincent,
> >
> > On Wed, Dec 14, 2022 at 07:15:25PM +0900, Vincent MAILHOL wrote:
> > > On Wed. 14 Dec. 2022 at 18:28, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> > > > On 14.12.2022 10:18:20, Marc Kleine-Budde wrote:
> > > > > On 14.12.2022 10:14:06, Markus Schneider-Pargmann wrote:
> > > > > > Hi Marc,
> > > > > >
> > > > > > On Wed, Nov 30, 2022 at 06:21:00PM +0100, Marc Kleine-Budde wrote:
> > > > > > > On 16.11.2022 21:52:55, Markus Schneider-Pargmann wrote:
> > > > > > > > Currently the driver waits to wakeup the queue until the interrupt for
> > > > > > > > the transmit event is received and acknowledged. If we want to use the
> > > > > > > > hardware FIFO, this is too late.
> > > > > > > >
> > > > > > > > Instead release the queue as soon as the transmit was transferred into
> > > > > > > > the hardware FIFO. We are then ready for the next transmit to be
> > > > > > > > transferred.
> > > > > > >
> > > > > > > If you want to really speed up the TX path, remove the worker and use
> > > > > > > the spi_async() API from the xmit callback, see mcp251xfd_start_xmit().
> > > > > > >
> > > > > > > Extra bonus if you implement xmit_more() and transfer more than 1 skb
> > > > > > > per SPI transfer.
> > > > > >
> > > > > > Just a quick question here, I mplemented a xmit_more() call and I am
> > > > > > testing it right now, but it always returns false even under high
> > > > > > pressure. The device has a txqueuelen set to 1000. Do I need to turn
> > > > > > some other knob for this to work?
> > >
> > > I was the first to use BQL in a CAN driver. It also took me time to
> > > first figure out the existence of xmit_more() and even more to
> > > understand how to make it so that it would return true.
> > >
> > > > > AFAIK you need BQL support: see 0084e298acfe ("can: mcp251xfd: add BQL support").
> > > > >
> > > > > The etas_es58x driver implements xmit_more(), I added the Author Vincent
> > > > > on Cc.
> > > >
> > > > Have a look at netdev_queue_set_dql_min_limit() in the etas driver.
> > >
> > > The functions you need are the netdev_send_queue() and the
> > > netdev_complete_queue():
> > >
> > > https://elixir.bootlin.com/linux/latest/source/include/linux/netdevice.h#L3424
> > >
> > > For CAN, you probably want to have a look to can_skb_get_frame_len().
> > >
> > > https://elixir.bootlin.com/linux/latest/source/include/linux/can/length.h#L166
> > >
> > > The netdev_queue_set_dql_min_limit() gives hints by setting a minimum
> > > value for BQL. It is optional (and as of today I am the only user of
> > > it).
> >
> > Thank you for this summary, great that you already invested the time to
> > make it work with a CAN driver. I will give it a try in the m_can
> > driver.
>
> Thanks again, it looks like it is working after adding netdev_sent_queue
> and netdev_complete_queue.
Happy to hear that :)
A quick advice just in case: make sure to test the different error
branches (failed TX, can_restart() after bus off…).
Yours sincerely,
Vincent Mailhol
^ permalink raw reply
* Re: [RESEND PATCH v5 net-next 2/2] net: phy: micrel: Fix warn: passing zero to PTR_ERR
From: Jakub Kicinski @ 2022-12-16 4:30 UTC (permalink / raw)
To: Divya Koppera
Cc: Alexander H Duyck, andrew, hkallweit1, linux, davem, edumazet,
pabeni, netdev, linux-kernel, richardcochran, UNGLinuxDriver
In-Reply-To: <c2040e16d69d251f1a0690f0805388817aba8ab7.camel@gmail.com>
On Thu, 15 Dec 2022 07:58:57 -0800 Alexander H Duyck wrote:
> Looks good to me. You may need to resubmit once net-next opens.
And please drop the Fixes tags when reposting. Both patches look
like placating static analysis tools but there's not real issue.
^ permalink raw reply
* Re: [PATCH net v3] net: dsa: mt7530: remove redundant assignment
From: patchwork-bot+netdevbpf @ 2022-12-16 4:30 UTC (permalink / raw)
To: Daniel Golle
Cc: netdev, linux-arm-kernel, linux-mediatek, linux-kernel, kuba,
sean.wang, Landen.Chao, dqfext, andrew, f.fainelli, olteanv,
davem, edumazet, pabeni, matthias.bgg
In-Reply-To: <Y5qY7x6la5TxZxzX@makrotopia.org>
Hello:
This patch was applied to netdev/net.git (master)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 15 Dec 2022 03:47:59 +0000 you wrote:
> Russell King correctly pointed out that the MAC_2500FD capability is
> already added for port 5 (if not in RGMII mode) and port 6 (which only
> supports SGMII) by mt7531_mac_port_get_caps. Remove the reduntant
> setting of this capability flag which was added by a previous commit.
>
> Fixes: e19de30d2080 ("net: dsa: mt7530: add support for in-band link status")
> Reported-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
>
> [...]
Here is the summary with links:
- [net,v3] net: dsa: mt7530: remove redundant assignment
https://git.kernel.org/netdev/net/c/32f1002ed485
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2 1/3] dsa: marvell: Provide per device information about max frame size
From: Jakub Kicinski @ 2022-12-16 4:20 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Andrew Lunn, Vladimir Oltean, Vivien Didelot, Florian Fainelli,
David S. Miller, Russell King, netdev, linux-kernel
In-Reply-To: <20221215144536.3810578-1-lukma@denx.de>
On Thu, 15 Dec 2022 15:45:34 +0100 Lukasz Majewski wrote:
> Different Marvell DSA switches support different size of max frame
> bytes to be sent.
>
> For example mv88e6185 supports max 1632 bytes, which is now in-driver
> standard value. On the other hand - mv88e6250 supports 2048 bytes.
>
> As this value is internal and may be different for each switch IC,
> new entry in struct mv88e6xxx_info has been added to store it.
# Form letter - net-next is closed
We have already submitted the networking pull request to Linus
for v6.2 and therefore net-next is closed for new drivers, features,
code refactoring and optimizations. We are currently accepting
bug fixes only.
Please repost when net-next reopens after Jan 2nd.
RFC patches sent for review only are obviously welcome at any time.
^ 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