* Re: [PATCH v6] selftests: add headers_install to lib.mk
From: Shuah Khan @ 2018-09-05 14:13 UTC (permalink / raw)
To: Anders Roxell, yamada.masahiro, michal.lkml, bamv2005, brgl,
pbonzini, akpm, rppt, aarcange
Cc: linux-kbuild, linux-kernel, linux-kselftest, netdev, Shuah Khan
In-Reply-To: <20180904104721.27535-1-anders.roxell@linaro.org>
On 09/04/2018 04:47 AM, Anders Roxell wrote:
> If the kernel headers aren't installed we can't build all the tests.
> Add a new make target rule 'khdr' in the file lib.mk to generate the
> kernel headers and that gets include for every test-dir Makefile that
> includes lib.mk If the testdir in turn have its own sub-dirs the
> top_srcdir needs to be set to the linux-rootdir to be able to generate
> the kernel headers.
>
> Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
> Reviewed-by: Fathi Boudra <fathi.boudra@linaro.org>
> ---
>
> I sent this (v5) a month ago and wondered if it got lost. Resending
> unchanged.
>
> Cheers,
> Anders
>
> Makefile | 14 +-------------
> scripts/subarch.include | 13 +++++++++++++
> tools/testing/selftests/android/Makefile | 2 +-
> tools/testing/selftests/android/ion/Makefile | 2 ++
> tools/testing/selftests/futex/functional/Makefile | 1 +
> tools/testing/selftests/gpio/Makefile | 7 ++-----
> tools/testing/selftests/kvm/Makefile | 7 ++-----
> tools/testing/selftests/lib.mk | 12 ++++++++++++
> tools/testing/selftests/net/Makefile | 1 +
> .../selftests/networking/timestamping/Makefile | 1 +
> tools/testing/selftests/vm/Makefile | 4 ----
> 11 files changed, 36 insertions(+), 28 deletions(-)
> create mode 100644 scripts/subarch.include
>
> diff --git a/Makefile b/Makefile
> index 19948e556941..9c781e77fa24 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -299,19 +299,7 @@ KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)
> KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)
> export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION
>
> -# SUBARCH tells the usermode build what the underlying arch is. That is set
> -# first, and if a usermode build is happening, the "ARCH=um" on the command
> -# line overrides the setting of ARCH below. If a native build is happening,
> -# then ARCH is assigned, getting whatever value it gets normally, and
> -# SUBARCH is subsequently ignored.
> -
> -SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
> - -e s/sun4u/sparc64/ \
> - -e s/arm.*/arm/ -e s/sa110/arm/ \
> - -e s/s390x/s390/ -e s/parisc64/parisc/ \
> - -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
> - -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \
> - -e s/riscv.*/riscv/)
> +include scripts/subarch.include
>
> # Cross compiling and selecting different set of gcc/bin-utils
> # ---------------------------------------------------------------------------
> diff --git a/scripts/subarch.include b/scripts/subarch.include
> new file mode 100644
> index 000000000000..650682821126
> --- /dev/null
> +++ b/scripts/subarch.include
> @@ -0,0 +1,13 @@
> +# SUBARCH tells the usermode build what the underlying arch is. That is set
> +# first, and if a usermode build is happening, the "ARCH=um" on the command
> +# line overrides the setting of ARCH below. If a native build is happening,
> +# then ARCH is assigned, getting whatever value it gets normally, and
> +# SUBARCH is subsequently ignored.
> +
> +SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
> + -e s/sun4u/sparc64/ \
> + -e s/arm.*/arm/ -e s/sa110/arm/ \
> + -e s/s390x/s390/ -e s/parisc64/parisc/ \
> + -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
> + -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \
> + -e s/riscv.*/riscv/)
> diff --git a/tools/testing/selftests/android/Makefile b/tools/testing/selftests/android/Makefile
> index 72c25a3cb658..d9a725478375 100644
> --- a/tools/testing/selftests/android/Makefile
> +++ b/tools/testing/selftests/android/Makefile
> @@ -6,7 +6,7 @@ TEST_PROGS := run.sh
>
> include ../lib.mk
>
> -all:
> +all: khdr
> @for DIR in $(SUBDIRS); do \
> BUILD_TARGET=$(OUTPUT)/$$DIR; \
> mkdir $$BUILD_TARGET -p; \
> diff --git a/tools/testing/selftests/android/ion/Makefile b/tools/testing/selftests/android/ion/Makefile
> index e03695287f76..88cfe88e466f 100644
> --- a/tools/testing/selftests/android/ion/Makefile
> +++ b/tools/testing/selftests/android/ion/Makefile
> @@ -10,6 +10,8 @@ $(TEST_GEN_FILES): ipcsocket.c ionutils.c
>
> TEST_PROGS := ion_test.sh
>
> +KSFT_KHDR_INSTALL := 1
> +top_srcdir = ../../../../..
> include ../../lib.mk
>
> $(OUTPUT)/ionapp_export: ionapp_export.c ipcsocket.c ionutils.c
> diff --git a/tools/testing/selftests/futex/functional/Makefile b/tools/testing/selftests/futex/functional/Makefile
> index ff8feca49746..ad1eeb14fda7 100644
> --- a/tools/testing/selftests/futex/functional/Makefile
> +++ b/tools/testing/selftests/futex/functional/Makefile
> @@ -18,6 +18,7 @@ TEST_GEN_FILES := \
>
> TEST_PROGS := run.sh
>
> +top_srcdir = ../../../../..
> include ../../lib.mk
>
> $(TEST_GEN_FILES): $(HEADERS)
> diff --git a/tools/testing/selftests/gpio/Makefile b/tools/testing/selftests/gpio/Makefile
> index 1bbb47565c55..4665cdbf1a8d 100644
> --- a/tools/testing/selftests/gpio/Makefile
> +++ b/tools/testing/selftests/gpio/Makefile
> @@ -21,11 +21,8 @@ endef
> CFLAGS += -O2 -g -std=gnu99 -Wall -I../../../../usr/include/
> LDLIBS += -lmount -I/usr/include/libmount
>
> -$(BINARIES): ../../../gpio/gpio-utils.o ../../../../usr/include/linux/gpio.h
> +$(BINARIES):| khdr
> +$(BINARIES): ../../../gpio/gpio-utils.o
>
> ../../../gpio/gpio-utils.o:
> make ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C ../../../gpio
> -
> -../../../../usr/include/linux/gpio.h:
> - make -C ../../../.. headers_install INSTALL_HDR_PATH=$(shell pwd)/../../../../usr/
> -
> diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
> index 03b0f551bedf..87d1a8488af8 100644
> --- a/tools/testing/selftests/kvm/Makefile
> +++ b/tools/testing/selftests/kvm/Makefile
> @@ -37,9 +37,6 @@ $(LIBKVM_OBJ): $(OUTPUT)/%.o: %.c
> $(OUTPUT)/libkvm.a: $(LIBKVM_OBJ)
> $(AR) crs $@ $^
>
> -$(LINUX_HDR_PATH):
> - make -C $(top_srcdir) headers_install
> -
> -all: $(STATIC_LIBS) $(LINUX_HDR_PATH)
> +all: $(STATIC_LIBS)
> $(TEST_GEN_PROGS): $(STATIC_LIBS)
> -$(TEST_GEN_PROGS) $(LIBKVM_OBJ): | $(LINUX_HDR_PATH)
> +$(STATIC_LIBS):| khdr
> diff --git a/tools/testing/selftests/lib.mk b/tools/testing/selftests/lib.mk
> index 17ab36605a8e..0a8e75886224 100644
> --- a/tools/testing/selftests/lib.mk
> +++ b/tools/testing/selftests/lib.mk
> @@ -16,8 +16,20 @@ TEST_GEN_PROGS := $(patsubst %,$(OUTPUT)/%,$(TEST_GEN_PROGS))
> TEST_GEN_PROGS_EXTENDED := $(patsubst %,$(OUTPUT)/%,$(TEST_GEN_PROGS_EXTENDED))
> TEST_GEN_FILES := $(patsubst %,$(OUTPUT)/%,$(TEST_GEN_FILES))
>
> +top_srcdir ?= ../../../..
> +include $(top_srcdir)/scripts/subarch.include
> +ARCH ?= $(SUBARCH)
> +
> all: $(TEST_GEN_PROGS) $(TEST_GEN_PROGS_EXTENDED) $(TEST_GEN_FILES)
>
> +.PHONY: khdr
> +khdr:
> + make ARCH=$(ARCH) -C $(top_srcdir) headers_install
> +
> +ifdef KSFT_KHDR_INSTALL
> +$(TEST_GEN_PROGS) $(TEST_GEN_PROGS_EXTENDED) $(TEST_GEN_FILES):| khdr
> +endif
> +
> .ONESHELL:
> define RUN_TEST_PRINT_RESULT
> TEST_HDR_MSG="selftests: "`basename $$PWD`:" $$BASENAME_TEST"; \
> diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
> index cccdb2295567..256d82d5fa87 100644
> --- a/tools/testing/selftests/net/Makefile
> +++ b/tools/testing/selftests/net/Makefile
> @@ -15,6 +15,7 @@ TEST_GEN_FILES += udpgso udpgso_bench_tx udpgso_bench_rx ip_defrag
> TEST_GEN_PROGS = reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa
> TEST_GEN_PROGS += reuseport_dualstack reuseaddr_conflict tls
>
> +KSFT_KHDR_INSTALL := 1
> include ../lib.mk
>
> $(OUTPUT)/reuseport_bpf_numa: LDFLAGS += -lnuma
> diff --git a/tools/testing/selftests/networking/timestamping/Makefile b/tools/testing/selftests/networking/timestamping/Makefile
> index a728040edbe1..14cfcf006936 100644
> --- a/tools/testing/selftests/networking/timestamping/Makefile
> +++ b/tools/testing/selftests/networking/timestamping/Makefile
> @@ -5,6 +5,7 @@ TEST_PROGS := hwtstamp_config rxtimestamp timestamping txtimestamp
>
> all: $(TEST_PROGS)
>
> +top_srcdir = ../../../../..
> include ../../lib.mk
>
> clean:
> diff --git a/tools/testing/selftests/vm/Makefile b/tools/testing/selftests/vm/Makefile
> index 9881876d2aa0..e94b7b14bcb2 100644
> --- a/tools/testing/selftests/vm/Makefile
> +++ b/tools/testing/selftests/vm/Makefile
> @@ -26,10 +26,6 @@ TEST_PROGS := run_vmtests
>
> include ../lib.mk
>
> -$(OUTPUT)/userfaultfd: ../../../../usr/include/linux/kernel.h
> $(OUTPUT)/userfaultfd: LDLIBS += -lpthread
>
> $(OUTPUT)/mlock-random-test: LDLIBS += -lcap
> -
> -../../../../usr/include/linux/kernel.h:
> - make -C ../../../.. headers_install
>
I queued this up in linux-kselftest next to be included in my next
pull request.
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH 1/9] PCI: sysfs: Export available PCIe bandwidth
From: Alex G. @ 2018-09-05 13:52 UTC (permalink / raw)
To: Stephen Hemminger
Cc: linux-pci, bhelgaas, keith.busch, alex_gagniuc, austin_bolen,
shyam_iyer, Ariel Elior, everest-linux-l2, David S. Miller,
Michael Chan, Ganesh Goudar, Jeff Kirsher, Tariq Toukan,
Saeed Mahameed, Leon Romanovsky, Jakub Kicinski,
Dirk van der Merwe, netdev, linux-kernel, intel-wired-lan,
linux-rdma, oss-drivers
In-Reply-To: <20180905082605.69d9e5a0@shemminger-XPS-13-9360>
On 09/05/2018 02:26 AM, Stephen Hemminger wrote:
> On Mon, 3 Sep 2018 13:02:28 -0500
> Alexandru Gagniuc <mr.nuke.me@gmail.com> wrote:
>
>> For certain bandwidth-critical devices (e.g. multi-port network cards)
>> it is useful to know the available bandwidth to the root complex. This
>> information is only available via the system log, which doesn't
>> account for link degradation after probing.
>>
>> With a sysfs attribute, we can computes the bandwidth on-demand, and
>> will detect degraded links.
>>
>> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
>
> In other places (like /sys/class/net/eth0/speed) only the raw value is printed
> without suffix. The general convention in sysfs is that it should be one value
> per file and in more raw format. So why not just print it in bits/sec without
> suffix?
I wanted to be consistent with other PCIe exports that use units.For
example:
/sys/devices/pci0000:3a/0000:3a:00.0/0000:3b:00.0/0000:3c:05.0/max_link_speed:8
GT/s
/sys/devices/pci0000:3a/0000:3a:00.0/0000:3b:00.0/0000:3c:05.0/current_link_speed:2.5
GT/s
/sys/bus/pci/slots/182/cur_bus_speed:2.5 GT/s PCIe
/sys/bus/pci/slots/182/max_bus_speed:8.0 GT/s PCIe
^ permalink raw reply
* [PATCH V3] net: qca_spi: Fix race condition in spi transfers
From: Stefan Wahren @ 2018-09-05 13:23 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel, Stefan Wahren
With performance optimization the spi transfer and messages of basic
register operations like qcaspi_read_register moved into the private
driver structure. But they weren't protected against mutual access
(e.g. between driver kthread and ethtool). So dumping the QCA7000
registers via ethtool during network traffic could make spi_sync
hang forever, because the completion in spi_message is overwritten.
So revert the optimization completely.
Fixes: 291ab06ecf676 ("net: qualcomm: new Ethernet over SPI driver for QCA700")
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
drivers/net/ethernet/qualcomm/qca_7k.c | 76 ++++++++--------
drivers/net/ethernet/qualcomm/qca_spi.c | 110 ++++++++++++------------
drivers/net/ethernet/qualcomm/qca_spi.h | 5 --
3 files changed, 93 insertions(+), 98 deletions(-)
Changes in V3:
- add Fixes tag
- fix sparse warning reported by kbuild test robot
Changes in V2:
- explain race in commit log more in detail
diff --git a/drivers/net/ethernet/qualcomm/qca_7k.c b/drivers/net/ethernet/qualcomm/qca_7k.c
index ffe7a16bdfc8..6c8543fb90c0 100644
--- a/drivers/net/ethernet/qualcomm/qca_7k.c
+++ b/drivers/net/ethernet/qualcomm/qca_7k.c
@@ -45,34 +45,33 @@ qcaspi_read_register(struct qcaspi *qca, u16 reg, u16 *result)
{
__be16 rx_data;
__be16 tx_data;
- struct spi_transfer *transfer;
- struct spi_message *msg;
+ struct spi_transfer transfer[2];
+ struct spi_message msg;
int ret;
+ memset(transfer, 0, sizeof(transfer));
+
+ spi_message_init(&msg);
+
tx_data = cpu_to_be16(QCA7K_SPI_READ | QCA7K_SPI_INTERNAL | reg);
+ *result = 0;
+
+ transfer[0].tx_buf = &tx_data;
+ transfer[0].len = QCASPI_CMD_LEN;
+ transfer[1].rx_buf = &rx_data;
+ transfer[1].len = QCASPI_CMD_LEN;
+
+ spi_message_add_tail(&transfer[0], &msg);
if (qca->legacy_mode) {
- msg = &qca->spi_msg1;
- transfer = &qca->spi_xfer1;
- transfer->tx_buf = &tx_data;
- transfer->rx_buf = NULL;
- transfer->len = QCASPI_CMD_LEN;
- spi_sync(qca->spi_dev, msg);
- } else {
- msg = &qca->spi_msg2;
- transfer = &qca->spi_xfer2[0];
- transfer->tx_buf = &tx_data;
- transfer->rx_buf = NULL;
- transfer->len = QCASPI_CMD_LEN;
- transfer = &qca->spi_xfer2[1];
+ spi_sync(qca->spi_dev, &msg);
+ spi_message_init(&msg);
}
- transfer->tx_buf = NULL;
- transfer->rx_buf = &rx_data;
- transfer->len = QCASPI_CMD_LEN;
- ret = spi_sync(qca->spi_dev, msg);
+ spi_message_add_tail(&transfer[1], &msg);
+ ret = spi_sync(qca->spi_dev, &msg);
if (!ret)
- ret = msg->status;
+ ret = msg.status;
if (ret)
qcaspi_spi_error(qca);
@@ -86,35 +85,32 @@ int
qcaspi_write_register(struct qcaspi *qca, u16 reg, u16 value)
{
__be16 tx_data[2];
- struct spi_transfer *transfer;
- struct spi_message *msg;
+ struct spi_transfer transfer[2];
+ struct spi_message msg;
int ret;
+ memset(&transfer, 0, sizeof(transfer));
+
+ spi_message_init(&msg);
+
tx_data[0] = cpu_to_be16(QCA7K_SPI_WRITE | QCA7K_SPI_INTERNAL | reg);
tx_data[1] = cpu_to_be16(value);
+ transfer[0].tx_buf = &tx_data[0];
+ transfer[0].len = QCASPI_CMD_LEN;
+ transfer[1].tx_buf = &tx_data[1];
+ transfer[1].len = QCASPI_CMD_LEN;
+
+ spi_message_add_tail(&transfer[0], &msg);
if (qca->legacy_mode) {
- msg = &qca->spi_msg1;
- transfer = &qca->spi_xfer1;
- transfer->tx_buf = &tx_data[0];
- transfer->rx_buf = NULL;
- transfer->len = QCASPI_CMD_LEN;
- spi_sync(qca->spi_dev, msg);
- } else {
- msg = &qca->spi_msg2;
- transfer = &qca->spi_xfer2[0];
- transfer->tx_buf = &tx_data[0];
- transfer->rx_buf = NULL;
- transfer->len = QCASPI_CMD_LEN;
- transfer = &qca->spi_xfer2[1];
+ spi_sync(qca->spi_dev, &msg);
+ spi_message_init(&msg);
}
- transfer->tx_buf = &tx_data[1];
- transfer->rx_buf = NULL;
- transfer->len = QCASPI_CMD_LEN;
- ret = spi_sync(qca->spi_dev, msg);
+ spi_message_add_tail(&transfer[1], &msg);
+ ret = spi_sync(qca->spi_dev, &msg);
if (!ret)
- ret = msg->status;
+ ret = msg.status;
if (ret)
qcaspi_spi_error(qca);
diff --git a/drivers/net/ethernet/qualcomm/qca_spi.c b/drivers/net/ethernet/qualcomm/qca_spi.c
index 206f0266463e..66b775d462fd 100644
--- a/drivers/net/ethernet/qualcomm/qca_spi.c
+++ b/drivers/net/ethernet/qualcomm/qca_spi.c
@@ -99,22 +99,24 @@ static u32
qcaspi_write_burst(struct qcaspi *qca, u8 *src, u32 len)
{
__be16 cmd;
- struct spi_message *msg = &qca->spi_msg2;
- struct spi_transfer *transfer = &qca->spi_xfer2[0];
+ struct spi_message msg;
+ struct spi_transfer transfer[2];
int ret;
+ memset(&transfer, 0, sizeof(transfer));
+ spi_message_init(&msg);
+
cmd = cpu_to_be16(QCA7K_SPI_WRITE | QCA7K_SPI_EXTERNAL);
- transfer->tx_buf = &cmd;
- transfer->rx_buf = NULL;
- transfer->len = QCASPI_CMD_LEN;
- transfer = &qca->spi_xfer2[1];
- transfer->tx_buf = src;
- transfer->rx_buf = NULL;
- transfer->len = len;
+ transfer[0].tx_buf = &cmd;
+ transfer[0].len = QCASPI_CMD_LEN;
+ transfer[1].tx_buf = src;
+ transfer[1].len = len;
- ret = spi_sync(qca->spi_dev, msg);
+ spi_message_add_tail(&transfer[0], &msg);
+ spi_message_add_tail(&transfer[1], &msg);
+ ret = spi_sync(qca->spi_dev, &msg);
- if (ret || (msg->actual_length != QCASPI_CMD_LEN + len)) {
+ if (ret || (msg.actual_length != QCASPI_CMD_LEN + len)) {
qcaspi_spi_error(qca);
return 0;
}
@@ -125,17 +127,20 @@ qcaspi_write_burst(struct qcaspi *qca, u8 *src, u32 len)
static u32
qcaspi_write_legacy(struct qcaspi *qca, u8 *src, u32 len)
{
- struct spi_message *msg = &qca->spi_msg1;
- struct spi_transfer *transfer = &qca->spi_xfer1;
+ struct spi_message msg;
+ struct spi_transfer transfer;
int ret;
- transfer->tx_buf = src;
- transfer->rx_buf = NULL;
- transfer->len = len;
+ memset(&transfer, 0, sizeof(transfer));
+ spi_message_init(&msg);
+
+ transfer.tx_buf = src;
+ transfer.len = len;
- ret = spi_sync(qca->spi_dev, msg);
+ spi_message_add_tail(&transfer, &msg);
+ ret = spi_sync(qca->spi_dev, &msg);
- if (ret || (msg->actual_length != len)) {
+ if (ret || (msg.actual_length != len)) {
qcaspi_spi_error(qca);
return 0;
}
@@ -146,23 +151,25 @@ qcaspi_write_legacy(struct qcaspi *qca, u8 *src, u32 len)
static u32
qcaspi_read_burst(struct qcaspi *qca, u8 *dst, u32 len)
{
- struct spi_message *msg = &qca->spi_msg2;
+ struct spi_message msg;
__be16 cmd;
- struct spi_transfer *transfer = &qca->spi_xfer2[0];
+ struct spi_transfer transfer[2];
int ret;
+ memset(&transfer, 0, sizeof(transfer));
+ spi_message_init(&msg);
+
cmd = cpu_to_be16(QCA7K_SPI_READ | QCA7K_SPI_EXTERNAL);
- transfer->tx_buf = &cmd;
- transfer->rx_buf = NULL;
- transfer->len = QCASPI_CMD_LEN;
- transfer = &qca->spi_xfer2[1];
- transfer->tx_buf = NULL;
- transfer->rx_buf = dst;
- transfer->len = len;
+ transfer[0].tx_buf = &cmd;
+ transfer[0].len = QCASPI_CMD_LEN;
+ transfer[1].rx_buf = dst;
+ transfer[1].len = len;
- ret = spi_sync(qca->spi_dev, msg);
+ spi_message_add_tail(&transfer[0], &msg);
+ spi_message_add_tail(&transfer[1], &msg);
+ ret = spi_sync(qca->spi_dev, &msg);
- if (ret || (msg->actual_length != QCASPI_CMD_LEN + len)) {
+ if (ret || (msg.actual_length != QCASPI_CMD_LEN + len)) {
qcaspi_spi_error(qca);
return 0;
}
@@ -173,17 +180,20 @@ qcaspi_read_burst(struct qcaspi *qca, u8 *dst, u32 len)
static u32
qcaspi_read_legacy(struct qcaspi *qca, u8 *dst, u32 len)
{
- struct spi_message *msg = &qca->spi_msg1;
- struct spi_transfer *transfer = &qca->spi_xfer1;
+ struct spi_message msg;
+ struct spi_transfer transfer;
int ret;
- transfer->tx_buf = NULL;
- transfer->rx_buf = dst;
- transfer->len = len;
+ memset(&transfer, 0, sizeof(transfer));
+ spi_message_init(&msg);
- ret = spi_sync(qca->spi_dev, msg);
+ transfer.rx_buf = dst;
+ transfer.len = len;
- if (ret || (msg->actual_length != len)) {
+ spi_message_add_tail(&transfer, &msg);
+ ret = spi_sync(qca->spi_dev, &msg);
+
+ if (ret || (msg.actual_length != len)) {
qcaspi_spi_error(qca);
return 0;
}
@@ -195,19 +205,23 @@ static int
qcaspi_tx_cmd(struct qcaspi *qca, u16 cmd)
{
__be16 tx_data;
- struct spi_message *msg = &qca->spi_msg1;
- struct spi_transfer *transfer = &qca->spi_xfer1;
+ struct spi_message msg;
+ struct spi_transfer transfer;
int ret;
+ memset(&transfer, 0, sizeof(transfer));
+
+ spi_message_init(&msg);
+
tx_data = cpu_to_be16(cmd);
- transfer->len = sizeof(tx_data);
- transfer->tx_buf = &tx_data;
- transfer->rx_buf = NULL;
+ transfer.len = sizeof(cmd);
+ transfer.tx_buf = &tx_data;
+ spi_message_add_tail(&transfer, &msg);
- ret = spi_sync(qca->spi_dev, msg);
+ ret = spi_sync(qca->spi_dev, &msg);
if (!ret)
- ret = msg->status;
+ ret = msg.status;
if (ret)
qcaspi_spi_error(qca);
@@ -835,16 +849,6 @@ qcaspi_netdev_setup(struct net_device *dev)
qca = netdev_priv(dev);
memset(qca, 0, sizeof(struct qcaspi));
- memset(&qca->spi_xfer1, 0, sizeof(struct spi_transfer));
- memset(&qca->spi_xfer2, 0, sizeof(struct spi_transfer) * 2);
-
- spi_message_init(&qca->spi_msg1);
- spi_message_add_tail(&qca->spi_xfer1, &qca->spi_msg1);
-
- spi_message_init(&qca->spi_msg2);
- spi_message_add_tail(&qca->spi_xfer2[0], &qca->spi_msg2);
- spi_message_add_tail(&qca->spi_xfer2[1], &qca->spi_msg2);
-
memset(&qca->txr, 0, sizeof(qca->txr));
qca->txr.count = TX_RING_MAX_LEN;
}
diff --git a/drivers/net/ethernet/qualcomm/qca_spi.h b/drivers/net/ethernet/qualcomm/qca_spi.h
index fc4beb1b32d1..fc0e98726b36 100644
--- a/drivers/net/ethernet/qualcomm/qca_spi.h
+++ b/drivers/net/ethernet/qualcomm/qca_spi.h
@@ -83,11 +83,6 @@ struct qcaspi {
struct tx_ring txr;
struct qcaspi_stats stats;
- struct spi_message spi_msg1;
- struct spi_message spi_msg2;
- struct spi_transfer spi_xfer1;
- struct spi_transfer spi_xfer2[2];
-
u8 *rx_buffer;
u32 buffer_size;
u8 sync;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net] devlink: Fix devlink_param_driverinit_value_set() stub return code
From: Moshe Shemesh @ 2018-09-05 12:48 UTC (permalink / raw)
To: David Ahern, David S. Miller; +Cc: Jiri Pirko, netdev, linux-kernel
In-Reply-To: <2bf31ad0-c3f8-cdfd-8b96-1a8e3280064d@gmail.com>
On 9/4/2018 7:13 PM, David Ahern wrote:
> On 9/4/18 7:04 AM, Moshe Shemesh wrote:
>> The stub function returned -EOPNOTSUPP while CONFIG_NET_DEVLINK is off.
>> It caused false warning during driver load. Driver needs to update
>> devlink on a parameter value if devlink module is there, if not it
>> doesn't need any error code.
>>
>> Fixes: ec01aeb1803e ("devlink: Add support for get/set driverinit value")
>> Signed-off-by: Moshe Shemesh <moshe@mellanox.com>
>> Acked-by: Jiri Pirko <jiri@mellanox.com>
>> ---
>> include/net/devlink.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/net/devlink.h b/include/net/devlink.h
>> index b9b89d6..b467357 100644
>> --- a/include/net/devlink.h
>> +++ b/include/net/devlink.h
>> @@ -781,7 +781,7 @@ static inline bool devlink_dpipe_table_counter_enabled(struct devlink *devlink,
>> devlink_param_driverinit_value_set(struct devlink *devlink, u32 param_id,
>> union devlink_param_value init_val)
>> {
>> - return -EOPNOTSUPP;
>> + return 0;
>> }
>>
>> static inline void
>>
>
> This should be handled by the driver -- check for -EOPNOTSUPP and not
> log an error.
This is a stub inline function.
The return value would be ambiguous as the non-stub function can also
return -EOPNOTSUPP, in case the driver-init mode is not supported for a
parameter.
>
> devlink is generic infrastructure. If a call is made and the operation
> is not supported, then devlink should return an error.
In general the stub functions should take care that the driver won't
feel the missing code as much as possible. That's why
devlink_params_register() returns success and so should this function.
>
^ permalink raw reply
* Re: [PATCH net] be2net: Fix memory leak in be_cmd_get_profile_config()
From: Ivan Vecera @ 2018-09-05 12:45 UTC (permalink / raw)
To: Petr Oros, netdev
Cc: Sathya Perla, Ajit Khaparde, Sriharsha Basavapatna, Somnath Kotur,
David S. Miller, linux-kernel
In-Reply-To: <20180905123746.7399-1-poros@redhat.com>
On 5.9.2018 14:37, Petr Oros wrote:
> DMA allocated memory is lost in be_cmd_get_profile_config() when we
> call it with non-NULL port_res parameter.
>
> Signed-off-by: Petr Oros <poros@redhat.com>
> ---
> drivers/net/ethernet/emulex/benet/be_cmds.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c
> index ff92ab1daeb8..1e9d882c04ef 100644
> --- a/drivers/net/ethernet/emulex/benet/be_cmds.c
> +++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
> @@ -4500,7 +4500,7 @@ int be_cmd_get_profile_config(struct be_adapter *adapter,
> port_res->max_vfs += le16_to_cpu(pcie->num_vfs);
> }
> }
> - return status;
> + goto err;
> }
>
> pcie = be_get_pcie_desc(resp->func_param, desc_count,
>
Good catch, Petr.
Reviewed-by: Ivan Vecera <ivecera@redhat.com>
^ permalink raw reply
* [PATCH net] be2net: Fix memory leak in be_cmd_get_profile_config()
From: Petr Oros @ 2018-09-05 12:37 UTC (permalink / raw)
To: netdev
Cc: ivecera, Sathya Perla, Ajit Khaparde, Sriharsha Basavapatna,
Somnath Kotur, David S. Miller, linux-kernel
DMA allocated memory is lost in be_cmd_get_profile_config() when we
call it with non-NULL port_res parameter.
Signed-off-by: Petr Oros <poros@redhat.com>
---
drivers/net/ethernet/emulex/benet/be_cmds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c
index ff92ab1daeb8..1e9d882c04ef 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -4500,7 +4500,7 @@ int be_cmd_get_profile_config(struct be_adapter *adapter,
port_res->max_vfs += le16_to_cpu(pcie->num_vfs);
}
}
- return status;
+ goto err;
}
pcie = be_get_pcie_desc(resp->func_param, desc_count,
--
2.16.4
^ permalink raw reply related
* Re: [RFC/PATCH] net: nixge: Add PHYLINK support
From: Andrew Lunn @ 2018-09-05 12:31 UTC (permalink / raw)
To: Moritz Fischer
Cc: Florian Fainelli, netdev, David S. Miller, Alex Williams,
Linux Kernel Mailing List
In-Reply-To: <CAAtXAHdZxgvb7=DG0B2irB4wJ+taJaOYbxhGjNtjWvaAQP8_nA@mail.gmail.com>
> Let me check, it seems there is a register that indicates whether the MAC can
> do either 1G or 10G. I might be able to use that for some of the above, but
> there is not really much in terms of writable registers there.
Can the MAC do 10 or 100? At the moment, you don't have anything
stopping the PHY anto-neg'ing 10Half. If the MAC does not fully
implement standard Ethernet, you need to tell the PHY driver about
this. That is what the validate call is about. phylink and phylib
knows what the PHY supports. It passes that list to the validate
call. You need to then remove all the modes the MAC does not support.
> It's like a DMA engine with a bit of MDIO on the side. Let me see if
> I can make it look less weird with that. If not I'll go with a
> comment explaining that there isn't much to do for the MLO_AN_PHY
> case and the MLO_FIXED cases?
You again need to configure the MAC to the selected speed, duplex,
etc. If the link is down, you want to disable the MAC. You need this
for both MLO_AN_PHY and MLO_FIXED, because both specify speeds,
duplex, etc.
Andrew
^ permalink raw reply
* [PATCH net-next] net: lan743x_ptp: make function lan743x_ptp_set_sync_ts_insert() static
From: YueHaibing @ 2018-09-05 12:24 UTC (permalink / raw)
To: davem, bryan.whitehead, UNGLinuxDriver; +Cc: linux-kernel, netdev, YueHaibing
Fixes the following sparse warning:
drivers/net/ethernet/microchip/lan743x_ptp.c:980:6: warning:
symbol 'lan743x_ptp_set_sync_ts_insert' was not declared. Should it be static?
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/microchip/lan743x_ptp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/microchip/lan743x_ptp.c b/drivers/net/ethernet/microchip/lan743x_ptp.c
index ccdf912..b2109ec 100644
--- a/drivers/net/ethernet/microchip/lan743x_ptp.c
+++ b/drivers/net/ethernet/microchip/lan743x_ptp.c
@@ -977,8 +977,8 @@ void lan743x_ptp_close(struct lan743x_adapter *adapter)
lan743x_ptp_disable(adapter);
}
-void lan743x_ptp_set_sync_ts_insert(struct lan743x_adapter *adapter,
- bool ts_insert_enable)
+static void lan743x_ptp_set_sync_ts_insert(struct lan743x_adapter *adapter,
+ bool ts_insert_enable)
{
u32 ptp_tx_mod = lan743x_csr_read(adapter, PTP_TX_MOD);
--
2.7.0
^ permalink raw reply related
* Re: [PATCH V2 ipsec-next 0/2] xfrm: bug fixes when processing multiple transforms
From: Steffen Klassert @ 2018-09-05 7:40 UTC (permalink / raw)
To: Sowmini Varadhan; +Cc: netdev, davem
In-Reply-To: <cover.1535973419.git.sowmini.varadhan@oracle.com>
On Mon, Sep 03, 2018 at 04:36:51AM -0700, Sowmini Varadhan wrote:
> This series contains bug fixes that were encountered when I set
> up a libreswan tunnel using the config below, which will set up
> an IPsec policy involving 2 tmpls.
>
> type=transport
> compress=yes
> esp=aes_gcm_c-128-null # offloaded to Niantic
> auto=start
>
> The non-offload test case uses esp=aes_gcm_c-256-null.
>
> Each patch has a technical description of the contents of the fix.
>
> V2: added Fixes tag so that it can be backported to the stable trees.
>
> Sowmini Varadhan (2):
> xfrm: reset transport header back to network header after all input
> transforms ahave been applied
> xfrm: reset crypto_done when iterating over multiple input xfrms
All applied to the ipsec tree, thanks a lot Sowmini!
^ permalink raw reply
* QUICK LOAN
From: FIRST CAPITAL LOAN @ 2018-09-04 23:31 UTC (permalink / raw)
To: Recipients
Your search for business / personal loan ends here.
- Instant Loan approval
- No collateral
- Fair interest rates
Kindly get back to us via email: capitalfirstloan@foxmail.com
for further details on how to apply.
^ permalink raw reply
* Re: [PATCH] [RFC v2] Drop all 00-INDEX files from Documentation/
From: Paul Moore @ 2018-09-05 11:42 UTC (permalink / raw)
To: henrik
Cc: linux-doc, corbet, bhelgaas, paulmck, josh, rostedt,
mathieu.desnoyers, jiangshanlai, axboe, robh+dt, mark.rutland,
b.zolnierkie, linus.walleij, davem, isdn, yamada.masahiro,
michal.lkml, peterz, mingo, will.deacon, ralf, paul.burton,
jhogan, jejb, deller, rjw, len.brown, pavel, benh, paulus, mpe,
schwidefsky, heiko.carstens, gregkh, jslaby, broonie
In-Reply-To: <1536012923-16275-1-git-send-email-henrik@austad.us>
On Mon, Sep 3, 2018 at 6:15 PM Henrik Austad <henrik@austad.us> wrote:
> This is a respin with a wider audience (all that get_maintainer returned)
> and I know this spams a *lot* of people. Not sure what would be the correct
> way, so my apologies for ruining your inbox.
>
> The 00-INDEX files are supposed to give a summary of all files present
> in a directory, but these files are horribly out of date and their
> usefulness is brought into question. Often a simple "ls" would reveal
> the same information as the filenames are generally quite descriptive as
> a short introduction to what the file covers (it should not surprise
> anyone what Documentation/sched/sched-design-CFS.txt covers)
>
> A few years back it was mentioned that these files were no longer really
> needed, and they have since then grown further out of date, so perhaps
> it is time to just throw them out.
>
> A short status yields the following _outdated_ 00-INDEX files, first
> counter is files listed in 00-INDEX but missing in the directory, last
> is files present but not listed in 00-INDEX.
>
> List of outdated 00-INDEX:
> Documentation: (4/10)
> Documentation/sysctl: (0/1)
> Documentation/timers: (1/0)
> Documentation/blockdev: (3/1)
> Documentation/w1/slaves: (0/1)
> Documentation/locking: (0/1)
> Documentation/devicetree: (0/5)
> Documentation/power: (1/1)
> Documentation/powerpc: (0/5)
> Documentation/arm: (1/0)
> Documentation/x86: (0/9)
> Documentation/x86/x86_64: (1/1)
> Documentation/scsi: (4/4)
> Documentation/filesystems: (2/9)
> Documentation/filesystems/nfs: (0/2)
> Documentation/cgroup-v1: (0/2)
> Documentation/kbuild: (0/4)
> Documentation/spi: (1/0)
> Documentation/virtual/kvm: (1/0)
> Documentation/scheduler: (0/2)
> Documentation/fb: (0/1)
> Documentation/block: (0/1)
> Documentation/networking: (6/37)
> Documentation/vm: (1/3)
>
> Then there are 364 subdirectories in Documentation/ with several files that
> are missing 00-INDEX alltogether (and another 120 with a single file and no
> 00-INDEX).
>
> I don't really have an opinion to whether or not we /should/ have 00-INDEX,
> but the above 00-INDEX should either be removed or be kept up to date. If
> we should keep the files, I can try to keep them updated, but I rather not
> if we just want to delete them anyway.
>
> As a starting point, remove all index-files and references to 00-INDEX and
> see where the discussion is going.
>
> Again, sorry for the insanely wide distribution.
>
> Signed-off-by: Henrik Austad <henrik@austad.us>
...
> Signed-off-by: Henrik Austad <haustad@cisco.com>
> ---
> Documentation/00-INDEX | 428 --------------------------------
...
Looks reasonable to me, you can add my ACK for the NetLabel bits.
Acked-by: Paul Moore <paul@paul-moore.com>
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH net-next] net: sched: change tcf_del_walker() to use concurrent-safe delete
From: Vlad Buslov @ 2018-09-05 7:03 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
David Miller
In-Reply-To: <CAM_iQpXSC0aNpEWPdhcBmfvP8xjvNKoX3Fn-7=r0xf2ttUt2aQ@mail.gmail.com>
On Tue 04 Sep 2018 at 22:41, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Mon, Sep 3, 2018 at 1:33 PM Vlad Buslov <vladbu@mellanox.com> wrote:
>>
>>
>> On Mon 03 Sep 2018 at 18:50, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> > On Mon, Sep 3, 2018 at 12:06 AM Vlad Buslov <vladbu@mellanox.com> wrote:
>> >>
>> >> Action API was changed to work with actions and action_idr in concurrency
>> >> safe manner, however tcf_del_walker() still uses actions without taking
>> >> reference to them first and deletes them directly, disregarding possible
>> >> concurrent delete.
>> >>
>> >> Change tcf_del_walker() to use tcf_idr_delete_index() that doesn't require
>> >> caller to hold reference to action and accepts action id as argument,
>> >> instead of direct action pointer.
>> >
>> > Hmm, why doesn't tcf_del_walker() just take idrinfo->lock? At least
>> > tcf_dump_walker() already does.
>>
>> Because tcf_del_walker() calls __tcf_idr_release(), which take
>> idrinfo->lock itself (deadlock). It also calls sleeping functions like
>
> Deadlock can be easily resolved by moving the lock out.
>
>
>> tcf_action_goto_chain_fini(), so just implementing function that
>> releases action without taking idrinfo->lock is not enough.
>
> Sleeping can be resolved either by making it atomic or
> deferring it to a work queue.
>
> None of your arguments here is a blocker to locking
> idrinfo->lock. You really should focus on if it is really
> necessary to lock idrinfo->lock in tcf_del_walker(), rather
> than these details.
>
> For me, if you need idrinfo->lock for dump walker, you must
> need it for delete walker too, because deletion is a writer
> which should require stronger protection than the dumper,
> which merely a reader.
I don't get how it is necessary. Dump walker uses pointers to actions
directly, and in order to be concurrency-safe it must either hold the
lock or obtain reference to action. Note that del walker doesn't use the
action pointer, it only passed action id to tcf_idr_delete_index()
function, which does all the necessary locking and can deal with
potential concurrency issues (concurrent delete, etc.). This approach
also benefits from code reuse from other code paths that delete actions,
instead of implementing its own.
^ permalink raw reply
* Re: [PATCH net-next] bnxt_en: Properly get address type of encapsulation IP headers
From: YueHaibing @ 2018-09-05 11:29 UTC (permalink / raw)
To: Sathya Perla; +Cc: David Miller, Michael Chan, open list, Netdev
In-Reply-To: <CAKvpyk3RZB8ioSKLRxjD-DsJwsFOEsum9r2kH34WkktLkd9FNg@mail.gmail.com>
On 2018/9/4 14:01, Sathya Perla wrote:
> On Sat, Sep 1, 2018 at 2:56 PM YueHaibing <yuehaibing@huawei.com> wrote:
>>
>> gcc '-Wunused-but-set-variable' warning:
>>
>> drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c: In function 'bnxt_tc_parse_flow':
>> drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c:186:6: warning:
>> variable 'addr_type' set but not used [-Wunused-but-set-variable]
>>
>> As done elsewhere in TC/flower offload code, the address type of
>> the encapsulation IP headers should be realized accroding to the
>> addr_type field of the encapsulation control dissector key.
> ...
>> drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c | 10 ++++------
>> 1 file changed, 4 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
>> index 092c817..5c625e5 100644
>> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
>> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
>> @@ -242,7 +242,7 @@ static int bnxt_tc_parse_flow(struct bnxt *bp,
>> flow->l2_key.num_vlans = 1;
>> }
>>
>> - if (dissector_uses_key(dissector, FLOW_DISSECTOR_KEY_IPV4_ADDRS)) {
>
> __skb_flow_dissect() (in net/core/flow_dissector.c) uses the same
> construct. So, can you clarify what you are trying to fix here
> functionally. Thanks.
>
sorry, I misread the code.
However, the 'addr_type' can be removed. Will send a new cleanup patch.
> .
>
^ permalink raw reply
* Re: [PATCH v7 1/4] gpiolib: Pass bitmaps, not integer arrays, to get/set array
From: kbuild test robot @ 2018-09-05 6:46 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: kbuild-all, Linus Walleij, Jonathan Corbet, Miguel Ojeda Sandonis,
Peter Korsgaard, Peter Rosin, Ulf Hansson, Andrew Lunn,
Florian Fainelli, David S. Miller, Dominik Brodowski,
Greg Kroah-Hartman, Kishon Vijay Abraham I, Lars-Peter Clausen,
Michael Hennerich, Jonathan Cameron, Hartmut Knaack,
Peter Meerwald-Stadler, Jiri Slaby, Willy
In-Reply-To: <20180902120144.6855-2-jmkrzyszt@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6171 bytes --]
Hi Janusz,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on gpio/for-next]
[also build test ERROR on v4.19-rc2 next-20180905]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Janusz-Krzysztofik/gpiolib-Pass-bitmaps-not-integer-arrays-to-get-set-array/20180903-172834
base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git for-next
config: x86_64-randconfig-f2-201835 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/phy/motorola/phy-mapphone-mdm6600.c: In function 'phy_mdm6600_cmd':
>> drivers/phy/motorola/phy-mapphone-mdm6600.c:165:36: error: passing argument 3 of 'gpiod_set_array_value_cansleep' from incompatible pointer type [-Werror=incompatible-pointer-types]
ddata->cmd_gpios->desc, values);
^~~~~~
In file included from drivers/phy/motorola/phy-mapphone-mdm6600.c:16:0:
include/linux/gpio/consumer.h:400:20: note: expected 'int *' but argument is of type 'long unsigned int *'
static inline void gpiod_set_array_value_cansleep(unsigned int array_size,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/phy/motorola/phy-mapphone-mdm6600.c: In function 'phy_mdm6600_status':
>> drivers/phy/motorola/phy-mapphone-mdm6600.c:184:13: error: passing argument 3 of 'gpiod_get_array_value_cansleep' from incompatible pointer type [-Werror=incompatible-pointer-types]
values);
^~~~~~
In file included from drivers/phy/motorola/phy-mapphone-mdm6600.c:16:0:
include/linux/gpio/consumer.h:387:19: note: expected 'int *' but argument is of type 'long unsigned int *'
static inline int gpiod_get_array_value_cansleep(unsigned int array_size,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/gpiod_set_array_value_cansleep +165 drivers/phy/motorola/phy-mapphone-mdm6600.c
5d1ebbda0 Tony Lindgren 2018-03-08 151
5d1ebbda0 Tony Lindgren 2018-03-08 152 /**
5d1ebbda0 Tony Lindgren 2018-03-08 153 * phy_mdm6600_cmd() - send a command request to mdm6600
5d1ebbda0 Tony Lindgren 2018-03-08 154 * @ddata: device driver data
5d1ebbda0 Tony Lindgren 2018-03-08 155 *
5d1ebbda0 Tony Lindgren 2018-03-08 156 * Configures the three command request GPIOs to the specified value.
5d1ebbda0 Tony Lindgren 2018-03-08 157 */
5d1ebbda0 Tony Lindgren 2018-03-08 158 static void phy_mdm6600_cmd(struct phy_mdm6600 *ddata, int val)
5d1ebbda0 Tony Lindgren 2018-03-08 159 {
916010a73 Janusz Krzysztofik 2018-09-02 160 DECLARE_BITMAP(values, PHY_MDM6600_NR_CMD_LINES);
5d1ebbda0 Tony Lindgren 2018-03-08 161
916010a73 Janusz Krzysztofik 2018-09-02 162 *values = val;
5d1ebbda0 Tony Lindgren 2018-03-08 163
5d1ebbda0 Tony Lindgren 2018-03-08 164 gpiod_set_array_value_cansleep(PHY_MDM6600_NR_CMD_LINES,
5d1ebbda0 Tony Lindgren 2018-03-08 @165 ddata->cmd_gpios->desc, values);
5d1ebbda0 Tony Lindgren 2018-03-08 166 }
5d1ebbda0 Tony Lindgren 2018-03-08 167
5d1ebbda0 Tony Lindgren 2018-03-08 168 /**
5d1ebbda0 Tony Lindgren 2018-03-08 169 * phy_mdm6600_status() - read mdm6600 status lines
5d1ebbda0 Tony Lindgren 2018-03-08 170 * @ddata: device driver data
5d1ebbda0 Tony Lindgren 2018-03-08 171 */
5d1ebbda0 Tony Lindgren 2018-03-08 172 static void phy_mdm6600_status(struct work_struct *work)
5d1ebbda0 Tony Lindgren 2018-03-08 173 {
5d1ebbda0 Tony Lindgren 2018-03-08 174 struct phy_mdm6600 *ddata;
5d1ebbda0 Tony Lindgren 2018-03-08 175 struct device *dev;
916010a73 Janusz Krzysztofik 2018-09-02 176 DECLARE_BITMAP(values, PHY_MDM6600_NR_STATUS_LINES);
5d1ebbda0 Tony Lindgren 2018-03-08 177 int error, i, val = 0;
5d1ebbda0 Tony Lindgren 2018-03-08 178
5d1ebbda0 Tony Lindgren 2018-03-08 179 ddata = container_of(work, struct phy_mdm6600, status_work.work);
5d1ebbda0 Tony Lindgren 2018-03-08 180 dev = ddata->dev;
5d1ebbda0 Tony Lindgren 2018-03-08 181
ad5003300 Tony Lindgren 2018-05-31 182 error = gpiod_get_array_value_cansleep(PHY_MDM6600_NR_STATUS_LINES,
5d1ebbda0 Tony Lindgren 2018-03-08 183 ddata->status_gpios->desc,
5d1ebbda0 Tony Lindgren 2018-03-08 @184 values);
5d1ebbda0 Tony Lindgren 2018-03-08 185 if (error)
5d1ebbda0 Tony Lindgren 2018-03-08 186 return;
5d1ebbda0 Tony Lindgren 2018-03-08 187
ad5003300 Tony Lindgren 2018-05-31 188 for (i = 0; i < PHY_MDM6600_NR_STATUS_LINES; i++) {
916010a73 Janusz Krzysztofik 2018-09-02 189 val |= test_bit(i, values) << i;
5d1ebbda0 Tony Lindgren 2018-03-08 190 dev_dbg(ddata->dev, "XXX %s: i: %i values[i]: %i val: %i\n",
916010a73 Janusz Krzysztofik 2018-09-02 191 __func__, i, test_bit(i, values), val);
5d1ebbda0 Tony Lindgren 2018-03-08 192 }
5d1ebbda0 Tony Lindgren 2018-03-08 193 ddata->status = val;
5d1ebbda0 Tony Lindgren 2018-03-08 194
5d1ebbda0 Tony Lindgren 2018-03-08 195 dev_info(dev, "modem status: %i %s\n",
5d1ebbda0 Tony Lindgren 2018-03-08 196 ddata->status,
5d1ebbda0 Tony Lindgren 2018-03-08 197 phy_mdm6600_status_name[ddata->status & 7]);
5d1ebbda0 Tony Lindgren 2018-03-08 198 complete(&ddata->ack);
5d1ebbda0 Tony Lindgren 2018-03-08 199 }
5d1ebbda0 Tony Lindgren 2018-03-08 200
:::::: The code at line 165 was first introduced by commit
:::::: 5d1ebbda0318b1ba55eaa1fae3fd867af17b0774 phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4
:::::: TO: Tony Lindgren <tony@atomide.com>
:::::: CC: Kishon Vijay Abraham I <kishon@ti.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 30605 bytes --]
^ permalink raw reply
* BUG: unable to handle kernel paging request in fib6_node_lookup_1
From: Song Liu @ 2018-09-05 6:11 UTC (permalink / raw)
To: Networking; +Cc: weiwan@google.com, David Ahern, Eric Dumazet
We are debugging an issue with fib6_node_lookup_1().
We use a 4.16 based kernel, and we have back ported most upstream
patches in ip6_fib.{c.h}. The only major differences I can spot are
8b7f2731bd68d83940714ce92381d1a72596407c
c3506372277779fccbffee2475400fcd689d5738
I guess the issue is not related to these two fixes.
After staring at the call trace and disassembly code (attached below)
I guess this is a use-after-free issue in (or right after) the lookup
loop:
for (;;) {
struct fib6_node *next;
dir = addr_bit_set(args->addr, fn->fn_bit);
next = dir ? rcu_dereference(fn->right) :
rcu_dereference(fn->left);
if (next) {
fn = next;
continue;
}
break;
}
I guess this probably also happens to latest upstream. I haven't
tested this with upstream kernel (or net tree) yet, because we
can only trigger this about once a week on 100 servers.
Does this look familiar? Any comments and/or suggestions are highly
appreciated.
Thanks,
Song
Bug stack trace:
[354764.457916] BUG: unable to handle kernel
[354764.466125] paging request
[354764.471720] at 00000000f60fc318
[354764.478360] IP: fib6_node_lookup_1+0x29/0x130
[354764.487249] PGD 800000010f725067
[354764.494062] P4D 800000010f725067
[354764.500878] PUD 0
[354764.505087] Oops: 0000 [#1] SMP PTI
[354764.512245] Modules linked in:
[354764.518536] udp_diag
[354764.523266] act_gact
[354764.527997] cls_bpf
[354764.532557] tcp_diag
[354764.537291] inet_diag
[354764.542200] nfsv3
[354764.546409] nfs
[354764.550273] fscache
[354764.554834] ip6table_raw
[354764.560260] ip6table_filter
[354764.566208] xt_DSCP
[354764.570765] iptable_raw
[354764.576020] iptable_filter
[354764.581790] ip6table_mangle
[354764.587738] iptable_mangle
[354764.593505] sb_edac
[354764.598058] x86_pkg_temp_thermal
[354764.604872] intel_powerclamp
[354764.610992] coretemp
[354764.615723] kvm_intel
[354764.620628] kvm
[354764.624494] irqbypass
[354764.629399] iTCO_wdt
[354764.634132] iTCO_vendor_support
[354764.640772] i2c_i801
[354764.645507] lpc_ich
[354764.650064] efivars
[354764.654619] mfd_core
[354764.659353] ipmi_si
[354764.663911] ipmi_devintf
[354764.669341] ipmi_msghandler
[354764.675281] acpi_cpufreq
[354764.680711] button
[354764.685096] sch_fq_codel
[354764.690520] nfsd
[354764.694557] nfs_acl
[354764.699118] lockd
[354764.703330] auth_rpcgss
[354764.708588] oid_registry
[354764.714006] grace
[354764.718213] sunrpc
[354764.722590] fuse
[354764.726626] loop
[354764.730661] efivarfs
[354764.735395] autofs4
[354764.739957] CPU: 5 PID: 3460038 Comm: java Not tainted 4.16.0-14_fbk2_1455_g6bcb99c57db6 #14
[354764.756996] Hardware name: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM03 06/02/2016
[354764.773001] RIP: 0010:fib6_node_lookup_1+0x29/0x130
[354764.782929] RSP: 0018:ffffc9003f0bb730 EFLAGS: 00010206
[354764.793557] RAX: ffff883fc131a000 RBX: 00000000f60fc300 RCX: 00000000ffffffe4
[354764.807999] RDX: 0000000000000010 RSI: 0000000000000001 RDI: ffffc9003f0bb8f0
[354764.822436] RBP: ffffc9003f0bb750 R08: 0000000000000002 R09: 0000000000000004
[354764.836877] R10: ffffc9003f0bb7a8 R11: ffff883ff7795780 R12: ffffffff82305080
[354764.851317] R13: 0000000000000002 R14: 0000000000000000 R15: 0000000000000000
[354764.865765] FS: 00007f8defcfc700(0000) GS:ffff881fff940000(0000) knlGS:0000000000000000
[354764.882119] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[354764.893800] CR2: 00000000f60fc318 CR3: 0000000f68cae006 CR4: 00000000003606e0
[354764.908235] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[354764.922671] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[354764.937109] Call Trace:
[354764.942195] fib6_node_lookup+0x67/0x90
[354764.950042] ? fib6_table_lookup+0x43/0x2f0
[354764.958587] fib6_table_lookup+0x43/0x2f0
[354764.966794] ip6_pol_route+0x43/0x360
[354764.974294] ? ip6_pol_route_input+0x20/0x20
[354764.983016] fib6_rule_lookup+0x85/0x140
[354764.991050] ? ip6t_do_table+0x331/0x6b0
[354764.999089] ? ip6_route_output_flags+0xa3/0xc0
[354765.008342] ip6_route_me_harder+0xab/0x280
[354765.016889] ip6table_mangle_hook+0xd4/0x110 [ip6table_mangle]
[354765.028754] ? nf_hook_slow+0x43/0xc0
[354765.036269] nf_hook_slow+0x43/0xc0
[354765.043445] nf_hook+0x6e/0xc0
[354765.049731] ? ac6_proc_exit+0x20/0x20
[354765.057412] ip6_xmit+0x28a/0x500
[354765.064225] ? ac6_proc_exit+0x20/0x20
[354765.071902] ? inet6_csk_route_socket+0x10f/0x1c0
[354765.081495] ? update_group_capacity+0x23/0x1e0
[354765.090749] inet6_csk_xmit+0x82/0xd0
[354765.098277] tcp_transmit_skb+0x51d/0x9d0
[354765.106495] tcp_write_xmit+0x1bd/0xf40
[354765.114359] ? _copy_from_iter_full+0x9c/0x240
[354765.123444] tcp_sendmsg_locked+0x2c2/0xdd0
[354765.131991] tcp_sendmsg+0x27/0x40
[354765.138991] sock_sendmsg+0x36/0x40
[354765.146167] sock_write_iter+0x84/0xd0
Disassemble of the fib6_node_lookup_1:
Dump of assembler code for function fib6_node_lookup_1:
0xffffffff818b3c70 <+0>: callq 0xffffffff81a01610 <__fentry__>
0xffffffff818b3c75 <+5>: mov (%rsi),%eax
0xffffffff818b3c77 <+7>: test %eax,%eax
0xffffffff818b3c79 <+9>: je 0xffffffff818b3d94 <fib6_node_lookup_1+292>
0xffffffff818b3c7f <+15>: push %r12
0xffffffff818b3c81 <+17>: push %rbp
0xffffffff818b3c82 <+18>: mov %rsi,%rbp
0xffffffff818b3c85 <+21>: push %rbx
0xffffffff818b3c86 <+22>: mov %rdi,%rbx
0xffffffff818b3c89 <+25>: mov 0x8(%rsi),%rdi
0xffffffff818b3c8d <+29>: mov $0x1,%esi
0xffffffff818b3c92 <+34>: movzwl 0x28(%rbx),%ecx
0xffffffff818b3c96 <+38>: mov %esi,%edx
0xffffffff818b3c98 <+40>: mov %ecx,%eax
0xffffffff818b3c9a <+42>: xor $0xffffffe7,%ecx
0xffffffff818b3c9d <+45>: sar $0x5,%eax
0xffffffff818b3ca0 <+48>: shl %cl,%edx
0xffffffff818b3ca2 <+50>: cltq
0xffffffff818b3ca4 <+52>: test %edx,(%rdi,%rax,4)
0xffffffff818b3ca7 <+55>: je 0xffffffff818b3cb7 <fib6_node_lookup_1+71>
0xffffffff818b3ca9 <+57>: mov 0x10(%rbx),%rax
0xffffffff818b3cad <+61>: test %rax,%rax
0xffffffff818b3cb0 <+64>: je 0xffffffff818b3cc0 <fib6_node_lookup_1+80>
0xffffffff818b3cb2 <+66>: mov %rax,%rbx
0xffffffff818b3cb5 <+69>: jmp 0xffffffff818b3c92 <fib6_node_lookup_1+34>
0xffffffff818b3cb7 <+71>: mov 0x8(%rbx),%rax
0xffffffff818b3cbb <+75>: test %rax,%rax
0xffffffff818b3cbe <+78>: jne 0xffffffff818b3cb2 <fib6_node_lookup_1+66>
0xffffffff818b3cc0 <+80>: test %rbx,%rbx
0xffffffff818b3cc3 <+83>: je 0xffffffff818b3d17 <fib6_node_lookup_1+167>
0xffffffff818b3cc5 <+85>: mov $0xffffffffffffffff,%r12
0xffffffff818b3ccc <+92>: jmp 0xffffffff818b3d02 <fib6_node_lookup_1+146>
0xffffffff818b3cce <+94>: mov 0x20(%rbx),%rax
0xffffffff818b3cd2 <+98>: test %rax,%rax
0xffffffff818b3cd5 <+101>: je 0xffffffff818b3cf2 <fib6_node_lookup_1+130>
0xffffffff818b3cd7 <+103>: movslq 0x0(%rbp),%rdx
0xffffffff818b3cdb <+107>: mov 0x8(%rbp),%rsi
0xffffffff818b3cdf <+111>: add %rdx,%rax
0xffffffff818b3ce2 <+114>: mov 0x10(%rax),%edx
0xffffffff818b3ce5 <+117>: cmp $0x3f,%edx
0xffffffff818b3ce8 <+120>: jbe 0xffffffff818b3d1e <fib6_node_lookup_1+174>
0xffffffff818b3cea <+122>: mov (%rsi),%rcx
0xffffffff818b3ced <+125>: cmp %rcx,(%rax)
0xffffffff818b3cf0 <+128>: je 0xffffffff818b3d52 <fib6_node_lookup_1+226>
0xffffffff818b3cf2 <+130>: movzwl 0x2a(%rbx),%eax
0xffffffff818b3cf6 <+134>: test $0x2,%al
0xffffffff818b3cf8 <+136>: jne 0xffffffff818b3d17 <fib6_node_lookup_1+167>
0xffffffff818b3cfa <+138>: mov (%rbx),%rbx
^ permalink raw reply
* Re: [PATCH 01/25] tty: Change return type to void
From: Jiri Slaby @ 2018-09-05 5:57 UTC (permalink / raw)
To: Jaejoong Kim, sergei.shtylyov
Cc: devel, Greg KH, linux-um, greybus-dev, linuxppc-dev,
linux-bluetooth, LKML, linux-mmc, linux-s390, linux-serial,
USB list, netdev, sparclinux
In-Reply-To: <CAL6iAaKzDPe7CMGR8VOBZRsJqZuNB1=zek_YVvwcKnjimbox2g@mail.gmail.com>
On 09/05/2018, 03:08 AM, Jaejoong Kim wrote:
> > @@ -688,7 +688,7 @@ extern int tty_port_close_start(struct
> tty_port *port,
> > extern void tty_port_close_end(struct tty_port *port, struct
> tty_struct *tty);
> > extern void tty_port_close(struct tty_port *port,
> > struct tty_struct *tty, struct file
> *filp);
> > -extern int tty_port_install(struct tty_port *port, struct
> tty_driver *driver,
> > +extern void tty_port_install(struct tty_port *port, struct
> tty_driver *driver,
> > struct tty_struct *tty);
>
> You need to update all the callers in the same patch -- the
> kernel must
> remain buildable after each patch but you seem to have spread that
> update
> among a lot of patches..
>
>
> OK. I will make several patches as one patch.
You don't have to. Just reorder the patches as suggested by Sam. (First,
make everybody ignore the return value, then change these return types
to void.)
BTW you can mention in this commit log, that this change is possible
after a3123fd0a4a5. That commit made tty_standard_install to always
return 0.
thanks,
--
js
suse labs
^ permalink raw reply
* Re: [PATCH RFC net-next] net: Poptrie based routing table lookup
From: Jesper Dangaard Brouer @ 2018-09-05 5:54 UTC (permalink / raw)
To: Md. Islam
Cc: Netdev, David Miller, David Ahern, Alexey Kuznetsov,
alexei.starovoitov, Stephen Hemminger, makita.toshiaki, panda,
yasuhiro.ohara, Eric Dumazet, john fastabend, brouer
In-Reply-To: <CAFgPn1BKp5vGi9_V_ZU3bL4rKdVs6kvC8Cb8a57pNTHb6i7Gsg@mail.gmail.com>
On Tue, 4 Sep 2018 16:34:36 -0400
"Md. Islam" <mislam4@kent.edu> wrote:
> On Tue, Sep 4, 2018 at 12:14 PM, Md. Islam <mislam4@kent.edu> wrote:
> >
> > On Tue, Sep 4, 2018, 6:53 AM Jesper Dangaard Brouer <brouer@redhat.com>
> > wrote:
> >>
> >> Hi Md. Islam,
> >>
> >> People will start to ignore you, when you don't interact appropriately
> >> with the community, and you ignore their advice, especially when it is
> >> about how to interact with the community[1].
> >>
> >> You have not addressed any of my feedback on your patch in [1].
> >> [1]
> >> http://www.mail-archive.com/search?l=mid&q=20180827173334.16ff0673@redhat.com
> >
> >
> > Jesper,
> >
> > I actually addressed all the feedbacks in the previous patch except TOS,
> > FIB_matrics, and etc. This is because I don't think they are relevant in
> > this usecase. Please let me know if I wrong.
> >
> > Thanks
>
> Jesper
>
> Sorry, I missed your review in the first place. I will take a look and
> resubmit the patch.
Good that you actually noticed yourself, that you did not address any
of my feedback. I don't want to repeat myself, so you just need to
follow the above link, and the link below (coding style +checkpatch.pl).
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Jesper Dangaard Brouer
> >> MSc.CS, Principal Kernel Engineer at Red Hat
> >> LinkedIn: http://www.linkedin.com/in/brouer
> >>
> >> p.s. also top-posting is bad, but I suspect you will not read my
> >> response if I don't top-post.
> >>
> >>
> >> On Tue, 4 Sep 2018 01:02:30 -0400 "Md. Islam" <mislam4@kent.edu> wrote:
> >>
> >> > This patch implements Poptrie based routing table
> >> > lookup/insert/delete/flush. Currently many carrier routers use kernel
> >> > bypass frameworks such as DPDK and VPP to implement the data plane.
> >> > XDP along with this patch will enable Linux to work as such a router.
> >> > Currently it supports up to 255 ports. Many real word backbone routers
> >> > have up to 233 ports (to the best of my knowledge), so it seems to be
> >> > sufficient at this moment.
> >> >
> >> > I also have attached a draft paper to explain it works (poptrie.pdf).
> >> > Please set CONFIG_FIB_POPTRIE=y (default n) before testing the patch.
> >> > Note that, poptrie_lookup() is not being called from anywhere. It will
> >> > be used by XDP forwarding.
> >> >
> >> >
> >> > From 3dc9683298ed896dd3080733503c35d68f05370e Mon Sep 17 00:00:00 2001
> >> > From: tamimcse <tamim@csebuet.org>
> >> > Date: Mon, 3 Sep 2018 23:56:43 -0400
> >> > Subject: [PATCH] Poptrie based routing table lookup
> >> >
> >> > Signed-off-by: tamimcse <tamim@csebuet.org>
> >> > ---
> >> > include/net/ip_fib.h | 42 +++++
> >> > net/ipv4/Kconfig | 4 +
> >> > net/ipv4/Makefile | 1 +
> >> > net/ipv4/fib_poptrie.c | 483
> >> > +++++++++++++++++++++++++++++++++++++++++++++++++
> >> > net/ipv4/fib_trie.c | 12 ++
> >> > 5 files changed, 542 insertions(+)
> >> > create mode 100644 net/ipv4/fib_poptrie.c
> >>
> >> First of order of business: You need to conform to the kernels coding
> >> standards!
> >>
> >> https://www.kernel.org/doc/html/v4.18/process/coding-style.html
> >>
> >> There is a script avail to check this called: scripts/checkpatch.pl
> >> It summary says:
> >> total: 139 errors, 238 warnings, 6 checks, 372 lines checked
> >> (Not good, more error+warnings than lines...)
> >>
> >> Please fix up those... else people will not even read you code!
^ permalink raw reply
* Re: [Patch net v3] tipc: call start and done ops directly in __tipc_nl_compat_dumpit()
From: Cong Wang @ 2018-09-05 5:49 UTC (permalink / raw)
To: Ying Xue; +Cc: Linux Kernel Network Developers, tipc-discussion, Jon Maloy
In-Reply-To: <e1e17123-0b69-291b-db04-ccc8e1be1c97@windriver.com>
On Tue, Sep 4, 2018 at 8:25 PM Ying Xue <ying.xue@windriver.com> wrote:
>
> On 09/05/2018 05:54 AM, Cong Wang wrote:
> > __tipc_nl_compat_dumpit() uses a netlink_callback on stack,
> > so the only way to align it with other ->dumpit() call path
> > is calling tipc_dump_start() and tipc_dump_done() directly
> > inside it. Otherwise ->dumpit() would always get NULL from
> > cb->args[].
> >
> > But tipc_dump_start() uses sock_net(cb->skb->sk) to retrieve
> > net pointer, the cb->skb here doesn't set skb->sk, the net pointer
> > is saved in msg->net instead, so introduce a helper function
> > __tipc_dump_start() to pass in msg->net.
> >
> > Ying pointed out cb->args[0...3] are already used by other
> > callbacks on this call path, so we can't use cb->args[0] any
> > more, use cb->args[4] instead.
>
> It's a common mechanism to save rhashtable iterator pointer in cb->args
> after tipc_dump_start() and tipc_dump_done() are introduced. Someday
> probably we will involve new dumpit function. In order to lower the risk
> that rhashtable iterator pointer saved is overwritten, it's better to
> use the last slot, ie, cb->args[5].
I don't understand, currently only cb->args[0..3] are used at most,
therefore cb->args[4] is pretty safe in current code base, there is
no reason to be so defensive to use cb->args[5].
If you really worry about future, you probably want to extend cb->args
from 6 to whatever larger, rather than just skipping cb->args[4].
I don't see any reason to do so.
^ permalink raw reply
* [GIT] net merged into net-next
From: David Miller @ 2018-09-05 5:21 UTC (permalink / raw)
To: netdev
Just FYI...
^ permalink raw reply
* Re: [PATCH rdma-next v1 12/15] RDMA/mlx5: Add a new flow action verb - modify header
From: Leon Romanovsky @ 2018-09-05 5:20 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, RDMA mailing list, Ariel Levkovich, Mark Bloch,
Or Gerlitz, Saeed Mahameed, linux-netdev
In-Reply-To: <20180904215823.GA3792@ziepe.ca>
[-- Attachment #1: Type: text/plain, Size: 1527 bytes --]
On Tue, Sep 04, 2018 at 03:58:23PM -0600, Jason Gunthorpe wrote:
> On Tue, Aug 28, 2018 at 02:18:51PM +0300, Leon Romanovsky wrote:
>
> > +static int UVERBS_HANDLER(MLX5_IB_METHOD_FLOW_ACTION_CREATE_MODIFY_HEADER)(
> > + struct ib_uverbs_file *file,
> > + struct uverbs_attr_bundle *attrs)
> > +{
> > + struct ib_uobject *uobj = uverbs_attr_get_uobject(
> > + attrs, MLX5_IB_ATTR_CREATE_MODIFY_HEADER_HANDLE);
> > + struct mlx5_ib_dev *mdev = to_mdev(uobj->context->device);
> > + enum mlx5_ib_uapi_flow_table_type ft_type;
> > + struct ib_flow_action *action;
> > + size_t num_actions;
> > + void *in;
> > + int len;
> > + int ret;
> > +
> > + if (!mlx5_ib_modify_header_supported(mdev))
> > + return -EOPNOTSUPP;
> > +
> > + in = uverbs_attr_get_alloced_ptr(attrs,
> > + MLX5_IB_ATTR_CREATE_MODIFY_HEADER_ACTIONS_PRM);
> > + len = uverbs_attr_get_len(attrs,
> > + MLX5_IB_ATTR_CREATE_MODIFY_HEADER_ACTIONS_PRM);
> > +
> > + if (len % MLX5_UN_SZ_BYTES(set_action_in_add_action_in_auto))
> > + return -EINVAL;
> > +
> > + ret = uverbs_get_const(&ft_type, attrs,
> > + MLX5_IB_ATTR_CREATE_MODIFY_HEADER_FT_TYPE);
> > + if (ret)
> > + return -EINVAL;
>
> This should be
>
> if (ret)
> return ret;
>
> Every call to uverbs_get_const is wrong in this same way..
Right, from technical point of view uverbs_get_const can return EINVAL
only, and it is correct for now, but need to be changed to proper
"return ret".
>
> I can probably fix it if this is the only thing though..
>
Thanks, I appreciate it.
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH rdma-next v1 00/15] Flow actions to mutate packets
From: Leon Romanovsky @ 2018-09-05 5:14 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, RDMA mailing list, Ariel Levkovich, Mark Bloch,
Or Gerlitz, Saeed Mahameed, linux-netdev
In-Reply-To: <20180904221205.GB3895@ziepe.ca>
[-- Attachment #1: Type: text/plain, Size: 6666 bytes --]
On Tue, Sep 04, 2018 at 04:12:05PM -0600, Jason Gunthorpe wrote:
> On Tue, Aug 28, 2018 at 02:18:39PM +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@mellanox.com>
> >
> > >From Mark,
> >
> > This series exposes the ability to create flow actions which can
> > mutate packet headers. We do that by exposing two new verbs:
> > * modify header - can change existing packet headers. packet
> > * reformat - can encapsulate or decapsulate a packet.
> > Once created a flow action must be attached to a steering
> > rule for it to take effect.
> >
> > The first 10 patches refactor mlx5_core code, rename internal structures
> > to better reflect their operation and export needed functions so the
> > RDMA side can allocate the action.
> >
> > The last 5 patches expose via the IOCTL infrastructure mlx5_ib methods
> > which do the actual allocation of resources and return an handle to the
> > user. A user of this API is expected to know how to work with the
> > device's spec as the input to those function is HW depended.
> >
> > An example usage of the modify header action is routing, A user can
> > create an action which edits the L2 header and decrease the TTL.
> >
> > An example usage of the packet reformat action is VXLAN encap/decap
> > which is done by the HW.
> >
> > Changelog:
> > v0 -> v1:
> > * Patch 1: Addressed Saeed's comments and simplified the logic.
> > * Patch 2: Changed due to changes in patch 1.
> >
> > Split the 27 patch series into 3, this is the first one
> > which just lets the user create flow action.
> > Other than that styling fixes mainly in the RDMA patches
> > to make sure 80 chars limit isn't exceeded.
> >
> > RFC -> v0:
> > * Patch 1 a new patch which refactors the logic
> > when getting a flow namespace.
> > * Patch 2 was split into two.
> > * Patch 3: Fixed a typo in commit message
> > * Patch 5: Updated commit message
> > * Patch 7: Updated commit message
> > Renamed:
> > - MLX5_FLOW_CONTEXT_ACTION_PACKET_REFORMAT_ID to
> > MLX5_FLOW_CONTEXT_ACTION_PACKET_REFORMAT
> > - packet_reformat_id to reformat_id in struct mlx5_flow_act
> > - packet_reformat_id to encap_id in struct mlx5_esw_flow_attr
> > - packet_reformat_id to encap_id in struct mlx5e_encap_entry
> > - PACKET_REFORMAT to REFORMAT when printing trace points
> > * Patch 9: Updated commit message
> > Updated function declaration in mlx5_core.h, could of lead
> > to compile error on bisection.
> > * Patch 11: Disallow egress rules insertion when in switchdev mode
> > * Patch 12: A new patch to deal with passing enum values using
> > the IOCTL infrastructure.
> > * Patch 13: Use new enum value attribute when passing enum
> > mlx5_ib_uapi_flow_table_type
> > * Patch 15: Don't set encap flags on flow tables if in switchdev mode
> > * Patch 17: Use new enum value attribute when passing enum
> > mlx5_ib_uapi_flow_table_type and enum
> > mlx5_ib_uapi_flow_action_packet_reformat_type
> > * Patch 19: Allow creation of both
> > MLX5_IB_UAPI_FLOW_ACTION_PACKET_REFORMAT_TYPE_L2_TO_L3_TUNNEL
> > and MLX5_IB_UAPI_FLOW_ACTION_PACKET_REFORMAT_TYPE_L3_TUNNEL_TO_L2
> > packet
> > reformat actions.
> > * Patch 20: A new patch which allows attaching packet reformat
> > actions to flow tables on NIC RX.
> >
> > Thanks
> >
> > Mark Bloch (15):
> > net/mlx5: Cleanup flow namespace getter switch logic
> > net/mlx5: Add proper NIC TX steering flow tables support
> > net/mlx5: Export modify header alloc/dealloc functions
> > net/mlx5: Add support for more namespaces when allocating modify
> > header
> > net/mlx5: Break encap/decap into two separated flow table creation
> > flags
> > net/mlx5: Move header encap type to IFC header file
> > {net, RDMA}/mlx5: Rename encap to reformat packet
> > net/mlx5: Expose new packet reformat capabilities
> > net/mlx5: Pass a namespace for packet reformat ID allocation
> > net/mlx5: Export packet reformat alloc/dealloc functions
> > RDMA/uverbs: Add UVERBS_ATTR_CONST_IN to the specs language
> > RDMA/mlx5: Add a new flow action verb - modify header
> > RDMA/uverbs: Add generic function to fill in flow action object
> > RDMA/mlx5: Add new flow action verb - packet reformat
> > RDMA/mlx5: Extend packet reformat verbs
> >
> > drivers/infiniband/core/uverbs_ioctl.c | 23 ++
> > .../infiniband/core/uverbs_std_types_flow_action.c | 7 +-
> > drivers/infiniband/hw/mlx5/devx.c | 6 +-
> > drivers/infiniband/hw/mlx5/flow.c | 301 +++++++++++++++++++++
> > drivers/infiniband/hw/mlx5/main.c | 3 +
> > drivers/infiniband/hw/mlx5/mlx5_ib.h | 19 +-
> > drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 8 +-
> > .../mellanox/mlx5/core/diag/fs_tracepoint.h | 2 +-
> > drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 51 ++--
> > drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 2 +-
> > .../ethernet/mellanox/mlx5/core/eswitch_offloads.c | 9 +-
> > drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c | 87 +++---
> > drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 73 +++--
> > .../net/ethernet/mellanox/mlx5/core/mlx5_core.h | 12 +-
> > include/linux/mlx5/device.h | 6 +
> > include/linux/mlx5/fs.h | 20 +-
> > include/linux/mlx5/mlx5_ifc.h | 70 +++--
> > include/rdma/uverbs_ioctl.h | 40 +++
> > include/rdma/uverbs_std_types.h | 12 +
> > include/uapi/rdma/mlx5_user_ioctl_cmds.h | 18 ++
> > include/uapi/rdma/mlx5_user_ioctl_verbs.h | 12 +
> > 21 files changed, 638 insertions(+), 143 deletions(-)
>
> This looks OK to me, can you make the shared commit please?
Thanks, I pushed to mlx5-next
50acec06f392 net/mlx5: Export packet reformat alloc/dealloc functions
31ca3648f01b net/mlx5: Pass a namespace for packet reformat ID allocation
bea4e1f6c6c5 net/mlx5: Expose new packet reformat capabilities
60786f0987c0 {net, RDMA}/mlx5: Rename encap to reformat packet
e0e7a3861b6c net/mlx5: Move header encap type to IFC header file
61444b458b01 net/mlx5: Break encap/decap into two separated flow table creation flags
c3c062f80665 net/mlx5: Add support for more namespaces when allocating modify header
90c1d1b8da67 net/mlx5: Export modify header alloc/dealloc functions
8ce78257965e net/mlx5: Add proper NIC TX steering flow tables support
2226dcb424bf net/mlx5: Cleanup flow namespace getter switch logic
>
> Thanks,
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH mlx5-next v1 05/15] net/mlx5: Break encap/decap into two separated flow table creation flags
From: Leon Romanovsky @ 2018-09-05 5:10 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, RDMA mailing list, Ariel Levkovich, Mark Bloch,
Or Gerlitz, Saeed Mahameed, linux-netdev
In-Reply-To: <20180904220242.GA3895@ziepe.ca>
[-- Attachment #1: Type: text/plain, Size: 2721 bytes --]
On Tue, Sep 04, 2018 at 04:02:42PM -0600, Jason Gunthorpe wrote:
> On Tue, Aug 28, 2018 at 02:18:44PM +0300, Leon Romanovsky wrote:
> > From: Mark Bloch <markb@mellanox.com>
> >
> > Today we are able to attach encap and decap actions only to the FDB. In
> > preparation to enable those actions on the NIC flow tables, break the
> > single flag into two. Those flags control whatever a decap or encap
> > operations can be attached to the flow table created. For FDB, if
> > encapsulation is required, we set both of them.
> >
> > Signed-off-by: Mark Bloch <markb@mellanox.com>
> > Reviewed-by: Saeed Mahameed <saeedm@mellanox.com>
> > Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
> > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> > drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 3 ++-
> > drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c | 7 ++++---
> > include/linux/mlx5/fs.h | 3 ++-
> > 3 files changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> > index f72b5c9dcfe9..ff21807a0c4b 100644
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> > @@ -529,7 +529,8 @@ static int esw_create_offloads_fast_fdb_table(struct mlx5_eswitch *esw)
> > esw_size >>= 1;
> >
> > if (esw->offloads.encap != DEVLINK_ESWITCH_ENCAP_MODE_NONE)
> > - flags |= MLX5_FLOW_TABLE_TUNNEL_EN;
> > + flags |= (MLX5_FLOW_TABLE_TUNNEL_EN_ENCAP |
> > + MLX5_FLOW_TABLE_TUNNEL_EN_DECAP);
> >
> > fdb = mlx5_create_auto_grouped_flow_table(root_ns, FDB_FAST_PATH,
> > esw_size,
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c b/drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c
> > index 9ae777e56529..1698f325a21e 100644
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c
> > @@ -152,7 +152,8 @@ static int mlx5_cmd_create_flow_table(struct mlx5_core_dev *dev,
> > struct mlx5_flow_table *next_ft,
> > unsigned int *table_id, u32 flags)
> > {
> > - int en_encap_decap = !!(flags & MLX5_FLOW_TABLE_TUNNEL_EN);
> > + int en_encap = !!(flags & MLX5_FLOW_TABLE_TUNNEL_EN_ENCAP);
> > + int en_decap = !!(flags & MLX5_FLOW_TABLE_TUNNEL_EN_DECAP);
>
> Yuk, please don't use !!.
>
> bool en_decap = flags & MLX5_FLOW_TABLE_TUNNEL_EN_DECAP;
We need to provide en_encap and en_decap as an input to MLX5_SET(...)
which is passed to FW as 0 or 1. Boolean type is declared in C as int
and treated as zero for false and any other value for true, so we
can't pass "bool en_decap" without ensuring before that it is 1.
I'm applying this patch as is.
Thanks
>
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v2 00/11] mscc: ocelot: add support for SerDes muxing configuration
From: Alexandre Belloni @ 2018-09-05 9:07 UTC (permalink / raw)
To: Paul Burton
Cc: Quentin Schulz, David Miller, andrew, ralf, jhogan, robh+dt,
mark.rutland, kishon, f.fainelli, allan.nielsen, linux-mips,
devicetree, linux-kernel, netdev, thomas.petazzoni
In-Reply-To: <20180904230351.vwlq2s7joulvqw2i@pburton-laptop>
On 04/09/2018 16:03:51-0700, Paul Burton wrote:
> Well, it sounded like David is OK with this all going through the MIPS
> tree, though we'd need an ack for the PHY parts.
>
> Alternatively I'd be happy for the DT changes to go through the net-next
> tree, which may make more sense given that the .dts changes are pretty
> trivial in comparison with the driver changes. If David wants to do that
> then for patches 1 & 8:
>
> Acked-by: Paul Burton <paul.burton@mips.com>
>
> Either way there may be conflicts for ocelot.dtsi when it comes to
> merging to master, but they should be simple to resolve. It seems
> Wolfram already took your DT changes for I2C so there's probably going
> to be multiple trees updating that file this cycle already anyway.
>
Actually, I think Wolfram meant that he took the bindings so you can
take the DT patches for i2c.
> Ideally I'd say "don't break bisection" but that's sort of a separate
> issue here since even if you restructure your series to do that it would
> still need to go through one tree. For example you could adjust
> mscc_ocelot_probe() to handle either the reg property or the syscon,
> then adjust the DT to use the syscon, then remove the code dealing with
> the reg property, and I'd consider that a good idea anyway but it would
> still probably all need to go through one tree to make sure things get
> merged in the right order & avoid breaking bisection.
>
I don't really think bisection is important at this stage but if you
don't want to break it, then I guess it makes more sense to have the
whole series through net.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* pull-request: mac80211-next 2018-09-05
From: Johannes Berg @ 2018-09-05 9:05 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Hi Dave,
Here's a pull request for net-next. Thanks for including
net, that way I could include Stanislaw's patch to check
the regulatory WMM data.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 36302685f59345959de96d0d70a5ad20a3a3451b:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-09-04 21:33:03 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2018-09-05
for you to fetch changes up to 014f5a250fc49fa8c6cd50093e725e71f3ae52da:
cfg80211: validate wmm rule when setting (2018-09-05 10:16:59 +0200)
----------------------------------------------------------------
This time, we have some pretty impactful work. Among
the changes:
* changes to make PTK rekeying work better, or actually
better/safely if drivers get updated
* VHT extended NSS support - some APs had capabilities
that didn't fit into the VHT (11ac) spec, so the spec
was updated and we follow that now
* some TXQ and A-MSDU building work - will allow iwlwifi
to use this soon
* more HE work, including aligning to 802.11ax Draft 3.0
* L-SIG and 0-length-PSDU support in radiotap
----------------------------------------------------------------
Alexander Wetzel (2):
nl80211: Add CAN_REPLACE_PTK0 API
mac80211: Fix PTK rekey freezes and clear text leak
Gustavo A. R. Silva (1):
mac80211: remove unnecessary NULL check
Ido Yariv (1):
mac80211: Add he_capa debugfs entry
Johannes Berg (7):
mac80211: remove pointless 'params' NULL checks
mac80211: use le16_encode_bits() instead of open-coding
mac80211: add an optional TXQ for other PS-buffered frames
ieee80211: add new VHT capability fields/parsing
mac80211: introduce capability flags for VHT EXT NSS support
mac80211: add ability to parse CCFS2
mac80211: copy VHT EXT NSS BW Support/Capable data to station
Naftali Goldstein (1):
mac80211: fix saving a few HE values
Sara Sharon (4):
ieee80211: remove redundant leading zeroes
mac80211: add an option for station management TXQ
mac80211: allow AMSDU size limitation per-TID
mac80211: add an option for drivers to check if packets can be aggregated
Shaul Triebitz (5):
cfg80211: add he_capabilities (ext) IE to AP settings
mac80211: in AP mode, set bss_conf::he_supported
mac80211: support radiotap L-SIG data
mac80211: support reporting 0-length PSDU in radiotap
wireless: align to draft 11ax D3.0
Stanislaw Gruszka (1):
cfg80211: validate wmm rule when setting
Wen Gong (1):
mac80211: Store sk_pacing_shift in ieee80211_hw
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 51 ++-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 4 -
drivers/net/wireless/mac80211_hwsim.c | 18 +-
include/linux/ieee80211.h | 111 +++++--
include/net/cfg80211.h | 2 +
include/net/ieee80211_radiotap.h | 21 ++
include/net/mac80211.h | 80 ++++-
include/uapi/linux/nl80211.h | 6 +
net/mac80211/cfg.c | 9 +-
net/mac80211/debugfs.c | 4 +
net/mac80211/debugfs_sta.c | 364 ++++++++++++++++++++-
net/mac80211/driver-ops.h | 10 +
net/mac80211/ibss.c | 4 +-
net/mac80211/ieee80211_i.h | 7 +-
net/mac80211/key.c | 111 +++++--
net/mac80211/main.c | 65 ++++
net/mac80211/mesh.c | 5 +-
net/mac80211/mlme.c | 23 +-
net/mac80211/rx.c | 37 ++-
net/mac80211/spectmgmt.c | 5 +-
net/mac80211/sta_info.c | 21 +-
net/mac80211/tx.c | 64 +++-
net/mac80211/util.c | 48 ++-
net/mac80211/vht.c | 20 ++
net/wireless/nl80211.c | 3 +
net/wireless/reg.c | 64 ++--
net/wireless/util.c | 109 ++++++
27 files changed, 1088 insertions(+), 178 deletions(-)
^ permalink raw reply
* Re: [RFC/PATCH] net: nixge: Add PHYLINK support
From: Moritz Fischer @ 2018-09-05 4:05 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David S. Miller, Andrew Lunn, Alex Williams,
Linux Kernel Mailing List
In-Reply-To: <fa4fca9c-5950-8ec1-5746-91e51085cecf@gmail.com>
Hi Florian,
On Tue, Sep 4, 2018 at 5:27 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 09/04/2018 05:15 PM, Moritz Fischer wrote:
>> Add basic PHYLINK support to driver.
>>
>> Suggested-by: Andrew Lunn <andrew@lunn.ch>
>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
>> ---
>>
>> Hi all,
>>
>> as Andrew suggested in order to enable SFP as
>> well as fixed-link support add PHYLINK support.
>>
>> A couple of questions are still open (hence the RFC):
>>
>> 1) It seems odd to implement PHYLINK callbacks that
>> are all empty? If so, should we have generic empty
>> ones in drivers/net/phy/phylink.c like we have for
>> genphys?
>
> Yes it is odd, the validate callback most certainly should not be empty,
> neither should the mac_config and mac_link_{up,down}, but, with some
> luck, you can get things to just work, typically with MDIO PHYs, since a
> large amount of what they can do is discoverable.
>
> If you had an existing adjust_link callback from PHYLIB, it's really
> about breaking it down such that the MAC configuration of
> speed/duplex/pause happens in mac_config, and the link setting (if
> necessary), happens in mac_link_{up,down}, and that's pretty much it for
> MLO_AN_PHY cases.
Let me check, it seems there is a register that indicates whether the MAC can
do either 1G or 10G. I might be able to use that for some of the above, but
there is not really much in terms of writable registers there.
It's like a DMA engine with a bit of MDIO on the side. Let me see if I can make
it look less weird with that. If not I'll go with a comment explaining
that there
isn't much to do for the MLO_AN_PHY case and the MLO_FIXED cases?
Cheers and thanks for your feedback,
Moritz
^ 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