* [PATCH] ARM: dts: at91: VInCo: fix phy reset gpio flag
From: Nicolas Ferre @ 2016-04-26 10:24 UTC (permalink / raw)
To: sergei.shtylyov
Cc: linux-kernel, linux-arm-kernel, Gregory Clement,
Alexandre Belloni, netdev, Nicolas Ferre, Andrew Lunn,
David Miller
In-Reply-To: <570BF481.9070903@cogentembedded.com>
Fix gpio active flag for the phy reset-gpios property. The line is
active low instead of active high.
Actually, this flags was never used by the macb driver.
Reported-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
Hi,
Thanks for having reported this bug to me.
I hope that we will be able to move forward for changing the phy
reset code in the macb driver.
I plan to queue this patch through arm-soc for 4.7.
Thanks, best regards,
Nicolas
arch/arm/boot/dts/at91-vinco.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/at91-vinco.dts b/arch/arm/boot/dts/at91-vinco.dts
index 79aec55e1ebc..6a366ee952a8 100644
--- a/arch/arm/boot/dts/at91-vinco.dts
+++ b/arch/arm/boot/dts/at91-vinco.dts
@@ -118,7 +118,7 @@
ethernet-phy@1 {
reg = <0x1>;
- reset-gpios = <&pioE 8 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&pioE 8 GPIO_ACTIVE_LOW>;
interrupt-parent = <&pioB>;
interrupts = <15 IRQ_TYPE_EDGE_FALLING>;
};
@@ -162,7 +162,7 @@
reg = <0x1>;
interrupt-parent = <&pioB>;
interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
- reset-gpios = <&pioE 6 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&pioE 6 GPIO_ACTIVE_LOW>;
};
};
--
2.1.3
^ permalink raw reply related
* Re: [PATCH net-next 3/8] fs/quota: use nla_put_u64_64bit()
From: Jan Kara @ 2016-04-26 11:08 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: dev-yBygre7rU0TnMu66kgdUjQ, sd-y1jBWg8GRStKuXlAQpz2QA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, jhs-jkUAjuhPggJWk0Htik3J/w,
lars.ellenberg-63ez5xqkn6DQT0dZR+AlfA, jack-IBi9RG/b67k,
johannes-cdvu00un1VgdHxzADdlk8Q,
philipp.reisner-63ez5xqkn6DQT0dZR+AlfA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, kvalo-sgV2jX0FEOL9JmXXK+q4OQ,
drbd-dev-cunTk1MwBs8qoQakbn7OcQ
In-Reply-To: <1461657978-13360-4-git-send-email-nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
On Tue 26-04-16 10:06:13, Nicolas Dichtel wrote:
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
OK, so I somewhat miss a description of what will this do to the netlink
message so that I can judge whether the change is fine for the userspace
counterpart parsing these messages. AFAIU this changes the message format
by adding a QUOTA_NL_A_PAD field before each 64-bit field which needs an
alignment, am I guessing right? Thus when the userspace counterpart uses
genlmsg_parse() it should just silently ignore these attributes if I read
the documentation right. Did I understand this correctly?
Honza
> ---
> fs/quota/netlink.c | 12 +++++++-----
> include/uapi/linux/quota.h | 1 +
> 2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/fs/quota/netlink.c b/fs/quota/netlink.c
> index d07a2f91d858..8b252673d454 100644
> --- a/fs/quota/netlink.c
> +++ b/fs/quota/netlink.c
> @@ -47,7 +47,7 @@ void quota_send_warning(struct kqid qid, dev_t dev,
> void *msg_head;
> int ret;
> int msg_size = 4 * nla_total_size(sizeof(u32)) +
> - 2 * nla_total_size(sizeof(u64));
> + 2 * nla_total_size_64bit(sizeof(u64));
>
> /* We have to allocate using GFP_NOFS as we are called from a
> * filesystem performing write and thus further recursion into
> @@ -68,8 +68,9 @@ void quota_send_warning(struct kqid qid, dev_t dev,
> ret = nla_put_u32(skb, QUOTA_NL_A_QTYPE, qid.type);
> if (ret)
> goto attr_err_out;
> - ret = nla_put_u64(skb, QUOTA_NL_A_EXCESS_ID,
> - from_kqid_munged(&init_user_ns, qid));
> + ret = nla_put_u64_64bit(skb, QUOTA_NL_A_EXCESS_ID,
> + from_kqid_munged(&init_user_ns, qid),
> + QUOTA_NL_A_PAD);
> if (ret)
> goto attr_err_out;
> ret = nla_put_u32(skb, QUOTA_NL_A_WARNING, warntype);
> @@ -81,8 +82,9 @@ void quota_send_warning(struct kqid qid, dev_t dev,
> ret = nla_put_u32(skb, QUOTA_NL_A_DEV_MINOR, MINOR(dev));
> if (ret)
> goto attr_err_out;
> - ret = nla_put_u64(skb, QUOTA_NL_A_CAUSED_ID,
> - from_kuid_munged(&init_user_ns, current_uid()));
> + ret = nla_put_u64_64bit(skb, QUOTA_NL_A_CAUSED_ID,
> + from_kuid_munged(&init_user_ns, current_uid()),
> + QUOTA_NL_A_PAD);
> if (ret)
> goto attr_err_out;
> genlmsg_end(skb, msg_head);
> diff --git a/include/uapi/linux/quota.h b/include/uapi/linux/quota.h
> index 38baddb807f5..4d2489ef6f10 100644
> --- a/include/uapi/linux/quota.h
> +++ b/include/uapi/linux/quota.h
> @@ -191,6 +191,7 @@ enum {
> QUOTA_NL_A_DEV_MAJOR,
> QUOTA_NL_A_DEV_MINOR,
> QUOTA_NL_A_CAUSED_ID,
> + QUOTA_NL_A_PAD,
> __QUOTA_NL_A_MAX,
> };
> #define QUOTA_NL_A_MAX (__QUOTA_NL_A_MAX - 1)
> --
> 2.8.1
>
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* [net-next PATCH 0/4] samples/bpf: Improve user experience
From: Jesper Dangaard Brouer @ 2016-04-26 11:09 UTC (permalink / raw)
To: netdev
Cc: bblanco, borkmann, alexei.starovoitov, linux-kbuild,
Jesper Dangaard Brouer
It is a steep learning curve getting started with using the eBPF
examples in samples/bpf/. There are several dependencies, and
specific versions of these dependencies. Invoking make in the correct
manor is also slightly obscure.
This patchset cleanup, document and hopefully improves the first time
user experience with the eBPF samples directory by auto-detecting
certain scenarios.
---
Jesper Dangaard Brouer (4):
samples/bpf: add back functionality to redefine LLC command
samples/bpf: Makefile verify LLVM compiler avail and bpf target is supported
samples/bpf: add a README file to get users started
samples/bpf: allow make to be run from samples/bpf/ directory
samples/bpf/Makefile | 32 +++++++++++++++++++++-
samples/bpf/README.rst | 70 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 101 insertions(+), 1 deletion(-)
create mode 100644 samples/bpf/README.rst
^ permalink raw reply
* [net-next PATCH 1/4] samples/bpf: add back functionality to redefine LLC command
From: Jesper Dangaard Brouer @ 2016-04-26 11:09 UTC (permalink / raw)
To: netdev
Cc: bblanco, borkmann, alexei.starovoitov, linux-kbuild,
Jesper Dangaard Brouer
In-Reply-To: <20160426110828.20716.13392.stgit@firesoul>
It is practical to be-able-to redefine the location of the LLVM
command 'llc', because not all distros have a LLVM version with bpf
target support. Thus, it is sometimes required to compile LLVM from
source, and sometimes it is not desired to overwrite the distros
default LLVM version.
This feature was removed with 128d1514be35 ("samples/bpf: Use llc in
PATH, rather than a hardcoded value").
Add this features back. Note that it is possible to redefine the LLC
on the make command like:
make samples/bpf/ LLC=~/git/llvm/build/bin/llc
Fixes: 128d1514be35 ("samples/bpf: Use llc in PATH, rather than a hardcoded value")
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
samples/bpf/Makefile | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 744dd7a16144..5bae9536f100 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -81,10 +81,14 @@ HOSTLOADLIBES_spintest += -lelf
HOSTLOADLIBES_map_perf_test += -lelf -lrt
HOSTLOADLIBES_test_overhead += -lelf -lrt
+# Allows pointing LLC to a LLVM backend with bpf support, redefine on cmdline:
+# make samples/bpf/ LLC=~/git/llvm/build/bin/llc
+LLC ?= llc
+
# asm/sysreg.h - inline assembly used by it is incompatible with llvm.
# But, there is no easy way to fix it, so just exclude it since it is
# useless for BPF samples.
$(obj)/%.o: $(src)/%.c
clang $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) \
-D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused-value -Wno-pointer-sign \
- -O2 -emit-llvm -c $< -o -| llc -march=bpf -filetype=obj -o $@
+ -O2 -emit-llvm -c $< -o -| $(LLC) -march=bpf -filetype=obj -o $@
^ permalink raw reply related
* [net-next PATCH 2/4] samples/bpf: Makefile verify LLVM compiler avail and bpf target is supported
From: Jesper Dangaard Brouer @ 2016-04-26 11:09 UTC (permalink / raw)
To: netdev
Cc: bblanco, borkmann, alexei.starovoitov, linux-kbuild,
Jesper Dangaard Brouer
In-Reply-To: <20160426110828.20716.13392.stgit@firesoul>
Make compiling samples/bpf more user friendly, by detecting if LLVM
compiler tool 'llc' is available, and also detect if the 'bpf' target
is available in this version of LLVM.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
samples/bpf/Makefile | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 5bae9536f100..7ac66f5bbbf5 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -85,6 +85,24 @@ HOSTLOADLIBES_test_overhead += -lelf -lrt
# make samples/bpf/ LLC=~/git/llvm/build/bin/llc
LLC ?= llc
+# Verify LLVM compiler is available and bpf target is supported
+.PHONY: verify_cmd_llc verify_target_bpf
+
+verify_cmd_llc:
+ @if ! (which "${LLC}" > /dev/null 2>&1); then \
+ echo "*** ERROR: Cannot find LLVM tool 'llc' (${LLC})" ;\
+ exit 1; \
+ else true; fi
+
+verify_target_bpf: verify_cmd_llc
+ @if ! (${LLC} -march=bpf -mattr=help > /dev/null 2>&1); then \
+ echo "*** ERROR: LLVM (${LLC}) does not support 'bpf' target" ;\
+ echo " NOTICE: LLVM version >= 3.7.0 required" ;\
+ exit 2; \
+ else true; fi
+
+$(src)/*.c: verify_target_bpf
+
# asm/sysreg.h - inline assembly used by it is incompatible with llvm.
# But, there is no easy way to fix it, so just exclude it since it is
# useless for BPF samples.
^ permalink raw reply related
* [net-next PATCH 4/4] samples/bpf: allow make to be run from samples/bpf/ directory
From: Jesper Dangaard Brouer @ 2016-04-26 11:09 UTC (permalink / raw)
To: netdev
Cc: bblanco, borkmann, alexei.starovoitov, linux-kbuild,
Jesper Dangaard Brouer
In-Reply-To: <20160426110828.20716.13392.stgit@firesoul>
It is not intuitive that 'make' must be run from the top level
directory with argument "samples/bpf/" to compile these eBPF samples.
Introduce a kbuild make file trick that allow make to be run from the
"samples/bpf/" directory itself. It basically change to the top level
directory and call "make samples/bpf/" with the "/" slash after the
directory name.
Also add a clean target that only cleans this directory, by taking
advantage of the kbuild external module setting M=$PWD.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
samples/bpf/Makefile | 8 ++++++++
samples/bpf/README.rst | 3 +++
2 files changed, 11 insertions(+)
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 7ac66f5bbbf5..7370dfee482f 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -85,6 +85,14 @@ HOSTLOADLIBES_test_overhead += -lelf -lrt
# make samples/bpf/ LLC=~/git/llvm/build/bin/llc
LLC ?= llc
+# Trick to allow make to be run from this directory
+all:
+ $(MAKE) -C ../../ $$PWD/
+
+clean:
+ $(MAKE) -C ../../ M=$$PWD clean
+ @rm -f *~
+
# Verify LLVM compiler is available and bpf target is supported
.PHONY: verify_cmd_llc verify_target_bpf
diff --git a/samples/bpf/README.rst b/samples/bpf/README.rst
index 3e1ac05d8e7c..3a9e6c4099aa 100644
--- a/samples/bpf/README.rst
+++ b/samples/bpf/README.rst
@@ -47,6 +47,9 @@ For compiling goto kernel top level build directory and run make like::
Do notice the "/" slash after the directory name.
+It is also possible to call make from this directory. This will just
+hide the the invocation of make as above with the appended "/".
+
Manually compiling LLVM with 'bpf' support
------------------------------------------
^ permalink raw reply related
* [net-next PATCH 3/4] samples/bpf: add a README file to get users started
From: Jesper Dangaard Brouer @ 2016-04-26 11:09 UTC (permalink / raw)
To: netdev
Cc: bblanco, borkmann, alexei.starovoitov, linux-kbuild,
Jesper Dangaard Brouer
In-Reply-To: <20160426110828.20716.13392.stgit@firesoul>
Getting started with using examples in samples/bpf/ is not
straightforward. There are several dependencies, and specific
versions of these dependencies.
Just compiling the example tool is also slightly obscure, e.g. one
need to call make like:
make samples/bpf/
Do notice the "/" slash after the directory name.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
samples/bpf/README.rst | 67 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 67 insertions(+)
create mode 100644 samples/bpf/README.rst
diff --git a/samples/bpf/README.rst b/samples/bpf/README.rst
new file mode 100644
index 000000000000..3e1ac05d8e7c
--- /dev/null
+++ b/samples/bpf/README.rst
@@ -0,0 +1,67 @@
+eBPF sample programs
+====================
+
+This kernel samples/bpf directory contains a mini eBPF library, test
+stubs, verifier test-suite and examples for using eBPF.
+
+Build dependencies
+==================
+
+Compiling requires having installed:
+ * clang
+ * llvm >= version 3.7.0
+
+Note that LLVM's tool 'llc' must support target 'bpf', list with command::
+
+ $ llc --version
+ LLVM (http://llvm.org/):
+ LLVM version 3.x.y
+ [...]
+ Host CPU: xxx
+
+ Registered Targets:
+ [...]
+ bpf - BPF (host endian)
+ bpfeb - BPF (big endian)
+ bpfel - BPF (little endian)
+ [...]
+
+Kernel headers
+--------------
+
+There are usually dependencies to header files of the current kernel.
+To avoid installing devel kernel headers system wide, as a normal
+user, simply call::
+
+ make headers_install
+
+This will creates a local "usr/include" directory in the git/build top
+level directory, that the make system automatically pickup first.
+
+Compiling
+=========
+
+For compiling goto kernel top level build directory and run make like::
+
+ make samples/bpf/
+
+Do notice the "/" slash after the directory name.
+
+Manually compiling LLVM with 'bpf' support
+------------------------------------------
+
+In some LLVM versions the BPF target were marked experimental. To
+compile LLVM manually and enable BPF target run (build dependencies
+are cmake and gcc-c++)::
+
+ $ git clone http://llvm.org/git/llvm.git
+ $ cd llvm
+ $ mkdir build; cd build
+ $ cmake .. -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=BPF
+ $ make
+
+It is also possible to point make to the newly compile 'llc' command
+via redefining LLC on the make command line::
+
+ make samples/bpf/ LLC=~/git/llvm/build/bin/llc
+
^ permalink raw reply related
* Re: [net-next PATCH 1/4] samples/bpf: add back functionality to redefine LLC command
From: Daniel Borkmann @ 2016-04-26 11:36 UTC (permalink / raw)
To: Jesper Dangaard Brouer, netdev
Cc: bblanco, borkmann, alexei.starovoitov, linux-kbuild
In-Reply-To: <20160426110917.20716.43051.stgit@firesoul>
On 04/26/2016 01:09 PM, Jesper Dangaard Brouer wrote:
> It is practical to be-able-to redefine the location of the LLVM
> command 'llc', because not all distros have a LLVM version with bpf
> target support. Thus, it is sometimes required to compile LLVM from
> source, and sometimes it is not desired to overwrite the distros
> default LLVM version.
>
> This feature was removed with 128d1514be35 ("samples/bpf: Use llc in
> PATH, rather than a hardcoded value").
>
> Add this features back. Note that it is possible to redefine the LLC
> on the make command like:
>
> make samples/bpf/ LLC=~/git/llvm/build/bin/llc
>
> Fixes: 128d1514be35 ("samples/bpf: Use llc in PATH, rather than a hardcoded value")
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> ---
> samples/bpf/Makefile | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
> index 744dd7a16144..5bae9536f100 100644
> --- a/samples/bpf/Makefile
> +++ b/samples/bpf/Makefile
> @@ -81,10 +81,14 @@ HOSTLOADLIBES_spintest += -lelf
> HOSTLOADLIBES_map_perf_test += -lelf -lrt
> HOSTLOADLIBES_test_overhead += -lelf -lrt
>
> +# Allows pointing LLC to a LLVM backend with bpf support, redefine on cmdline:
> +# make samples/bpf/ LLC=~/git/llvm/build/bin/llc
> +LLC ?= llc
> +
> # asm/sysreg.h - inline assembly used by it is incompatible with llvm.
> # But, there is no easy way to fix it, so just exclude it since it is
> # useless for BPF samples.
> $(obj)/%.o: $(src)/%.c
> clang $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) \
> -D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused-value -Wno-pointer-sign \
> - -O2 -emit-llvm -c $< -o -| llc -march=bpf -filetype=obj -o $@
> + -O2 -emit-llvm -c $< -o -| $(LLC) -march=bpf -filetype=obj -o $@
Why not doing the same for clang? True that we're not using 'clang -target bpf'
here, but when someone builds llvm from git, it's very likely that clang is cloned
and built along with it.
^ permalink raw reply
* Re: [net-next PATCH 3/4] samples/bpf: add a README file to get users started
From: Daniel Borkmann @ 2016-04-26 11:44 UTC (permalink / raw)
To: Jesper Dangaard Brouer, netdev
Cc: bblanco, borkmann, alexei.starovoitov, linux-kbuild
In-Reply-To: <20160426110927.20716.89620.stgit@firesoul>
On 04/26/2016 01:09 PM, Jesper Dangaard Brouer wrote:
> Getting started with using examples in samples/bpf/ is not
> straightforward. There are several dependencies, and specific
> versions of these dependencies.
>
> Just compiling the example tool is also slightly obscure, e.g. one
> need to call make like:
>
> make samples/bpf/
>
> Do notice the "/" slash after the directory name.
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> ---
> samples/bpf/README.rst | 67 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 67 insertions(+)
> create mode 100644 samples/bpf/README.rst
>
> diff --git a/samples/bpf/README.rst b/samples/bpf/README.rst
> new file mode 100644
> index 000000000000..3e1ac05d8e7c
> --- /dev/null
> +++ b/samples/bpf/README.rst
> @@ -0,0 +1,67 @@
> +eBPF sample programs
> +====================
> +
> +This kernel samples/bpf directory contains a mini eBPF library, test
> +stubs, verifier test-suite and examples for using eBPF.
> +
> +Build dependencies
> +==================
> +
> +Compiling requires having installed:
> + * clang
> + * llvm >= version 3.7.0
> +
> +Note that LLVM's tool 'llc' must support target 'bpf', list with command::
> +
> + $ llc --version
> + LLVM (http://llvm.org/):
> + LLVM version 3.x.y
> + [...]
> + Host CPU: xxx
> +
> + Registered Targets:
> + [...]
> + bpf - BPF (host endian)
> + bpfeb - BPF (big endian)
> + bpfel - BPF (little endian)
> + [...]
> +
> +Kernel headers
> +--------------
> +
> +There are usually dependencies to header files of the current kernel.
> +To avoid installing devel kernel headers system wide, as a normal
> +user, simply call::
> +
> + make headers_install
> +
> +This will creates a local "usr/include" directory in the git/build top
> +level directory, that the make system automatically pickup first.
> +
> +Compiling
> +=========
> +
> +For compiling goto kernel top level build directory and run make like::
> +
> + make samples/bpf/
> +
> +Do notice the "/" slash after the directory name.
> +
> +Manually compiling LLVM with 'bpf' support
> +------------------------------------------
> +
> +In some LLVM versions the BPF target were marked experimental. To
> +compile LLVM manually and enable BPF target run (build dependencies
> +are cmake and gcc-c++)::
> +
> + $ git clone http://llvm.org/git/llvm.git
> + $ cd llvm
> + $ mkdir build; cd build
> + $ cmake .. -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=BPF
> + $ make
That's perhaps a bit misleading in the sense that when you clone the
tree from git, you'd nowadays invoke cmake normally with LLVM_TARGETS_TO_BUILD
instead of LLVM_EXPERIMENTAL_TARGETS_TO_BUILD for BPF, as BPF is not an
experimental target anymore. It's probably also recommended to clone
clang into tools/ dir as well under your llvm/ repo when you compile
from scratch anyways.
> +It is also possible to point make to the newly compile 'llc' command
> +via redefining LLC on the make command line::
> +
> + make samples/bpf/ LLC=~/git/llvm/build/bin/llc
> +
>
^ permalink raw reply
* Re: [PATCH net-next 0/8] netlink: align attributes when needed (patchset #3)
From: Lars Ellenberg @ 2016-04-26 11:54 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: dev-yBygre7rU0TnMu66kgdUjQ, sd-y1jBWg8GRStKuXlAQpz2QA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, jhs-jkUAjuhPggJWk0Htik3J/w,
pshelar-l0M0P4e3n4LQT0dZR+AlfA, jack-IBi9RG/b67k,
johannes-cdvu00un1VgdHxzADdlk8Q,
philipp.reisner-63ez5xqkn6DQT0dZR+AlfA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, kvalo-sgV2jX0FEOL9JmXXK+q4OQ,
drbd-dev-cunTk1MwBs8qoQakbn7OcQ
In-Reply-To: <1461657978-13360-1-git-send-email-nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
On Tue, Apr 26, 2016 at 10:06:10AM +0200, Nicolas Dichtel wrote:
>
> This is the continuation (series #3) of the work done to align netlink
> attributes when these attributes contain some 64-bit fields.
>
> It's the last patchset from what I've seen.
>
> The last user of nla_put_u64() is block/drbd. This module does not use
> standard netlink API (see all the stuff in include/linux/genl_magic_struct.h
> and include/linux/genl_magic_func.h). I didn't modify it because it's seems
> hard to do it whithout testing and fully understanding the context
Something like this should just work.
diff --git a/include/linux/genl_magic_struct.h b/include/linux/genl_magic_struct.h
index eecd19b..5715dac 100644
--- a/include/linux/genl_magic_struct.h
+++ b/include/linux/genl_magic_struct.h
@@ -80,7 +80,7 @@ extern void CONCAT_(GENL_MAGIC_FAMILY, _genl_unregister)(void);
nla_get_u32, nla_put_u32, true)
#define __u64_field(attr_nr, attr_flag, name) \
__field(attr_nr, attr_flag, name, NLA_U64, __u64, \
- nla_get_u64, nla_put_u64, false)
+ nla_get_u64, nla_put_u64_64bit_unspec, false)
#define __str_field(attr_nr, attr_flag, name, maxlen) \
__array(attr_nr, attr_flag, name, NLA_NUL_STRING, char, maxlen, \
nla_strlcpy, nla_put, false)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index e589cb3..38ba770 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -871,6 +871,18 @@ static inline int nla_put_u64_64bit(struct sk_buff *skb, int attrtype,
}
/**
+ * nla_put_u64_64bit_unspec - nla_put_u64_64bit() with padattr = 0
+ * @skb: socket buffer to add attribute to
+ * @attrtype: attribute type
+ * @value: numeric value
+ */
+static inline int nla_put_u64_64bit_unspec(struct sk_buff *skb, int attrtype,
+ u64 value)
+{
+ return nla_put_64bit(skb, attrtype, sizeof(u64), &value, NLA_UNSPEC);
+}
+
+/**
* nla_put_be64 - Add a __be64 netlink attribute to a socket buffer and align it
* @skb: socket buffer to add attribute to
* @attrtype: attribute type
> (for
> example, why include/linux/drbd_genl.h is not part of uapi?).
> Any thoughts?
probably should be.
Thanks,
Lars
^ permalink raw reply related
* Re: [net-next PATCH 3/4] samples/bpf: add a README file to get users started
From: Jesper Dangaard Brouer @ 2016-04-26 11:56 UTC (permalink / raw)
To: Daniel Borkmann
Cc: netdev, bblanco, borkmann, alexei.starovoitov, linux-kbuild,
brouer
In-Reply-To: <571F5486.7090902@iogearbox.net>
On Tue, 26 Apr 2016 13:44:06 +0200
Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 04/26/2016 01:09 PM, Jesper Dangaard Brouer wrote:
> > Getting started with using examples in samples/bpf/ is not
> > straightforward. There are several dependencies, and specific
> > versions of these dependencies.
> >
> > Just compiling the example tool is also slightly obscure, e.g. one
> > need to call make like:
> >
> > make samples/bpf/
> >
> > Do notice the "/" slash after the directory name.
> >
> > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> > ---
> > samples/bpf/README.rst | 67 ++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 67 insertions(+)
> > create mode 100644 samples/bpf/README.rst
> >
> > diff --git a/samples/bpf/README.rst b/samples/bpf/README.rst
> > new file mode 100644
> > index 000000000000..3e1ac05d8e7c
> > --- /dev/null
> > +++ b/samples/bpf/README.rst
> > @@ -0,0 +1,67 @@
> > +eBPF sample programs
> > +====================
> > +
> > +This kernel samples/bpf directory contains a mini eBPF library, test
> > +stubs, verifier test-suite and examples for using eBPF.
> > +
> > +Build dependencies
> > +==================
> > +
> > +Compiling requires having installed:
> > + * clang
> > + * llvm >= version 3.7.0
> > +
> > +Note that LLVM's tool 'llc' must support target 'bpf', list with command::
> > +
> > + $ llc --version
> > + LLVM (http://llvm.org/):
> > + LLVM version 3.x.y
> > + [...]
> > + Host CPU: xxx
> > +
> > + Registered Targets:
> > + [...]
> > + bpf - BPF (host endian)
> > + bpfeb - BPF (big endian)
> > + bpfel - BPF (little endian)
> > + [...]
> > +
> > +Kernel headers
> > +--------------
> > +
> > +There are usually dependencies to header files of the current kernel.
> > +To avoid installing devel kernel headers system wide, as a normal
> > +user, simply call::
> > +
> > + make headers_install
> > +
> > +This will creates a local "usr/include" directory in the git/build top
> > +level directory, that the make system automatically pickup first.
> > +
> > +Compiling
> > +=========
> > +
> > +For compiling goto kernel top level build directory and run make like::
> > +
> > + make samples/bpf/
> > +
> > +Do notice the "/" slash after the directory name.
> > +
> > +Manually compiling LLVM with 'bpf' support
> > +------------------------------------------
> > +
> > +In some LLVM versions the BPF target were marked experimental. To
> > +compile LLVM manually and enable BPF target run (build dependencies
> > +are cmake and gcc-c++)::
> > +
> > + $ git clone http://llvm.org/git/llvm.git
> > + $ cd llvm
> > + $ mkdir build; cd build
> > + $ cmake .. -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=BPF
> > + $ make
>
> That's perhaps a bit misleading in the sense that when you clone the
> tree from git, you'd nowadays invoke cmake normally with LLVM_TARGETS_TO_BUILD
> instead of LLVM_EXPERIMENTAL_TARGETS_TO_BUILD for BPF, as BPF is not an
> experimental target anymore. It's probably also recommended to clone
> clang into tools/ dir as well under your llvm/ repo when you compile
> from scratch anyways.
Can you come up with a formulation/desc I can use instead then?
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH 1/6] bus: Add shared MDIO bus framework
From: Andrew Lunn @ 2016-04-26 12:13 UTC (permalink / raw)
To: Pramod Kumar
Cc: Rob Herring, Catalin Marinas, Will Deacon, Masahiro Yamada,
Chen-Yu Tsai, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
Pawel Moll, Arnd Bergmann, Suzuki K Poulose,
netdev-u79uwXL29TY76Z2rM5mHXA, Punit Agrawal,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, BCM Kernel Feedback,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Anup Patel
In-Reply-To: <666dffb41a922b0c8638f2f002a2de08-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Apr 26, 2016 at 02:03:27PM +0530, Pramod Kumar wrote:
> Hi Andrew,
>
> Thanks for reviewing. I really appreciate your effort it.
>
> I am already aware of MDIO mux framework but did not see it fit for our
> use case due to below limitations:
>
> 1. Current MDIO mux framework is Ethernet centric and it is only meant to
> mux multiple MII buses using same MDIO controller. This means it is only
> meant for MII-compliant PHY devices (i.e. PHY devices having registers
> as-per MII specs).
Nope, this is wrong. You can have a mixture of PHYs and other MDIO
devices on the MII bus. The framework does not care. A PHY is a
special case of an MDIO device.
> 2. The MDIO mux framework registers each child bus as MII bus. The Linux
> Ethernet MDIO framework will scan for all attached PHY devices on given
> MII bus and try to read MII PHY_ID register which is not present in all
> Broadcom non-ethernet PHYs.
It only performs a scan if you don't list the devices in the device
tree. If you do list devices, and include the address on the bus, it
never scans.
A good example of this is Ethernet switches. They occupy multiple
addresses on the MDIO bus, and also do not implement the PHY_ID
register at each address. Yet the MDIO layer is happy with this.
> 3. Let's say we ignore point1 and point2 above and go ahead and use MDIO
> mux framework then we will still have to emulated MII PHY_ID read for
> non-ethernet PHYs.
Nope. Not at all. You have an MDIO device on the bus, not an Ethernet
PHY. Hence the device is not liked to the PHY state machine, etc.
The key concept to get here is that there are MDIO devices, and a
subset of MDIO devices are Ethernet PHYs.....
> 4. Apart from these, by using MDIO mux framework we are making our
> non-ethernet PHYs dependent on Linux network drivers which is not
> acceptable. What if some product line does not need network subsystem at
> all?
This is your only valid point. However, does Broadcom have a product
line which does not include networking? Is not Broadcom a network SoC
vendor?
>
> As you can see from above points, trying to re-use Linux Ethernet MDIO mux
> framework for non-Ethernet PHYs is not the right way.
And as i pointed out, all your arguments are wrong, bar one. And i
doubt that one argument is sufficient to duplicate a lot of code which
already exists and does 95% of what you need.
> I'll add PCIe PHYs driver based on Shared MDIO framework in next patch
> revision to get a feel of its need.
Great. Lets then see what is needed to turn it into an MDIO device.
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 0/8] netlink: align attributes when needed (patchset #3)
From: Lars Ellenberg @ 2016-04-26 12:18 UTC (permalink / raw)
To: Nicolas Dichtel, netdev-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, sd-y1jBWg8GRStKuXlAQpz2QA,
johannes-cdvu00un1VgdHxzADdlk8Q, kvalo-sgV2jX0FEOL9JmXXK+q4OQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, jack-IBi9RG/b67k,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
pshelar-l0M0P4e3n4LQT0dZR+AlfA, dev-yBygre7rU0TnMu66kgdUjQ,
jhs-jkUAjuhPggJWk0Htik3J/w,
philipp.reisner-63ez5xqkn6DQT0dZR+AlfA,
drbd-dev-cunTk1MwBs8qoQakbn7OcQ
In-Reply-To: <20160426115427.GB20950-w1SgEEioFePxa46PmUWvFg@public.gmane.org>
On Tue, Apr 26, 2016 at 01:54:27PM +0200, Lars Ellenberg wrote:
> On Tue, Apr 26, 2016 at 10:06:10AM +0200, Nicolas Dichtel wrote:
> >
> > This is the continuation (series #3) of the work done to align netlink
> > attributes when these attributes contain some 64-bit fields.
> >
> > It's the last patchset from what I've seen.
> >
> > The last user of nla_put_u64() is block/drbd. This module does not use
> > standard netlink API (see all the stuff in include/linux/genl_magic_struct.h
> > and include/linux/genl_magic_func.h). I didn't modify it because it's seems
> > hard to do it whithout testing and fully understanding the context
>
> Something like this should just work.
> + * @attrtype: attribute type
> + * @value: numeric value
> + */
> +static inline int nla_put_u64_64bit_unspec(struct sk_buff *skb, int attrtype,
> + u64 value)
> +{
> + return nla_put_64bit(skb, attrtype, sizeof(u64), &value, NLA_UNSPEC);
Ok, I confused attribute and policy type there for a sec.
Anyways, 0 works just fine,
all our nested attribute enums are != 0,
because nla_parse skips type 0.
Lars
^ permalink raw reply
* Re: [PATCH V3] net: stmmac: socfpga: Remove re-registration of reset controller
From: Joachim Eastwood @ 2016-04-26 12:26 UTC (permalink / raw)
To: Marek Vasut
Cc: netdev, peppe.cavallaro, alexandre.torgue, Matthew Gerlach,
Dinh Nguyen, David S . Miller
In-Reply-To: <571EA05F.3070200@denx.de>
On 26 April 2016 at 00:55, Marek Vasut <marex@denx.de> wrote:
> On 04/25/2016 08:11 PM, Joachim Eastwood wrote:
>> On 21 April 2016 at 14:11, Marek Vasut <marex@denx.de> wrote:
>>>
>>> Finally, plat_dat->exit and socfpga_dwmac_exit() is no longer necessary,
>>> since the functionality is already performed by the stmmac core.
>>
>> I am trying to rebase my changes on top of your two patches and
>> noticed a couple of things.
>>
>>> static int socfpga_dwmac_init(struct platform_device *pdev, void *priv)
>>> {
>>> - struct socfpga_dwmac *dwmac = priv;
>>> + struct socfpga_dwmac *dwmac = priv;
>>> struct net_device *ndev = platform_get_drvdata(pdev);
>>> struct stmmac_priv *stpriv = NULL;
>>> int ret = 0;
>>>
>>> - if (ndev)
>>> - stpriv = netdev_priv(ndev);
>>> + if (!ndev)
>>> + return -EINVAL;
>>
>> ndev can never be NULL here. socfpga_dwmac_init() is only called if
>> stmmac_dvr_probe() succeeds or we are running the resume callback. So
>> I don't see how this could ever be NULL.
>
> That's a good point, this check can indeed be removed. While you're at
> the patching, can you remove this one ?
Yes, my patch will refactor the init() function so this will go away.
>>> +
>>> + stpriv = netdev_priv(ndev);
>>
>> It's not really nice to access 'stmmac_priv' as it should be private
>> to the core driver, but I don't see any other good solution right now.
>
> I guess some stmmac_reset_assert() wrapper would be nicer, yes. What do
> you think ?
>
>>> + if (!stpriv)
>>> + return -EINVAL;
>>>
>>> /* Assert reset to the enet controller before changing the phy mode */
>>> - if (dwmac->stmmac_rst)
>>> - reset_control_assert(dwmac->stmmac_rst);
>>> + if (stpriv->stmmac_rst)
>>> + reset_control_assert(stpriv->stmmac_rst);
>>>
>>> /* Setup the phy mode in the system manager registers according to
>>> * devicetree configuration
>>> @@ -227,8 +210,8 @@ static int socfpga_dwmac_init(struct platform_device *pdev, void *priv)
>>> /* Deassert reset for the phy configuration to be sampled by
>>> * the enet controller, and operation to start in requested mode
>>> */
>>> - if (dwmac->stmmac_rst)
>>> - reset_control_deassert(dwmac->stmmac_rst);
>>> + if (stpriv->stmmac_rst)
>>> + reset_control_deassert(stpriv->stmmac_rst);
>>>
>>> /* Before the enet controller is suspended, the phy is suspended.
>>> * This causes the phy clock to be gated. The enet controller is
>>> @@ -245,7 +228,7 @@ static int socfpga_dwmac_init(struct platform_device *pdev, void *priv)
>>> * control register 0, and can be modified by the phy driver
>>> * framework.
>>> */
>>> - if (stpriv && stpriv->phydev)
>>> + if (stpriv->phydev)
>>> phy_resume(stpriv->phydev);
>>
>> Before this change phy_resume() was only called during driver resume
>> when , but your patches cause phy_resume() to called at probe time as
>> well. Is this okey?
>
> I _hope_ it's OK. The cryptic comment above is not very helpful in this
> aspect. Dinh ? :)
My patches will move phy_resume() to the resume callback so it
preserves the previous behavior. But if someone knows more about this
that would be useful.
> btw I wish you reviewed my patch a bit earlier to catch these bits.
Sorry, about that. I have been really busy with other things lately.
My patches based on next from Friday can be found here now:
https://github.com/manabian/linux-lpc/tree/net-socfpga-dwmac-on-next
I had to add your latest patch as well since the next version I used
didn't have it. I'll post the patches on netdev later today or
tomorrow.
regards,
Joachim Eastwood
^ permalink raw reply
* Re: [PATCH net-next 3/8] fs/quota: use nla_put_u64_64bit()
From: Nicolas Dichtel @ 2016-04-26 12:31 UTC (permalink / raw)
To: Jan Kara
Cc: dev-yBygre7rU0TnMu66kgdUjQ, sd-y1jBWg8GRStKuXlAQpz2QA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, jhs-jkUAjuhPggJWk0Htik3J/w,
lars.ellenberg-63ez5xqkn6DQT0dZR+AlfA, jack-IBi9RG/b67k,
johannes-cdvu00un1VgdHxzADdlk8Q,
philipp.reisner-63ez5xqkn6DQT0dZR+AlfA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, kvalo-sgV2jX0FEOL9JmXXK+q4OQ,
drbd-dev-cunTk1MwBs8qoQakbn7OcQ
In-Reply-To: <20160426110848.GD27612-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org>
Le 26/04/2016 13:08, Jan Kara a écrit :
> On Tue 26-04-16 10:06:13, Nicolas Dichtel wrote:
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>
> OK, so I somewhat miss a description of what will this do to the netlink
> message so that I can judge whether the change is fine for the userspace
> counterpart parsing these messages. AFAIU this changes the message format
> by adding a QUOTA_NL_A_PAD field before each 64-bit field which needs an
> alignment, am I guessing right? Thus when the userspace counterpart uses
> genlmsg_parse() it should just silently ignore these attributes if I read
> the documentation right. Did I understand this correctly?
Yes, that's it.
Regards,
Nicolas
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: codel: split into multiple files
From: Michal Kazior @ 2016-04-26 12:36 UTC (permalink / raw)
To: sedat.dilek; +Cc: David S. Miller, netdev@vger.kernel.org, Jens Axboe
In-Reply-To: <CA+icZUVinohrHUNpKti-QA52eeSztmRTH1sFHpK+YSm98yGrAA@mail.gmail.com>
On 26 April 2016 at 08:43, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> On 4/26/16, Michal Kazior <michal.kazior@tieto.com> wrote:
>> On 26 April 2016 at 08:09, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>>> Hi,
>>>
>>> I had a very quick view on net-next.git#master (up to commit
>>> fab7b629a82da1b59620470d13152aff975239f6).
>>>
>>> Commit in [1] aka "codel: split into multiple files" removed codel.h
>>> but [2] and [3] have relicts to it.
>>> Forgot to remove?
>>
>> codel.h was not removed. diffstat for codel.h is all red which I
>> presume is why you thought of it as removed, see:
>>
>> http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/include/net/codel.h?id=d068ca2ae2e614b9a418fb3b5f1fd4cf996ff032
>>
>
> [ CC Jens ]
>
> OK.
> So what are the plans in the future?
> Keep a "generic" codel.h (compatibility reasons?) for net or is it your split?
I'm interested in re-using codel in mac80211 for wireless. cfg80211
drivers may want to do that as well later. Even vendor drivers could
start to use it (I can dream :).
I plan to re-spin my patches soonish re-based on the new codel.h/fq.h
approach. There's quite a few spins already[1].
> AFAICS I have seen a codel-implementation in block.git#wb-buf-throttle.
> Does it make sense to have a more "super-generic" codel.h for re-use
> (not only for net and block)?
> Just a thought.
Oh, I'm not really familiar with block and problems around it but it
sounds reasonable and interesting. It doesn't look like it blatantly
copies codel though (I did that in my initial mac80211 patches with
some adjustments, you can check that in the link[1] which you can
lookup via my patchset's cover letter[2]; I've based off of codel5[3]
back then).
[1]: https://www.spinics.net/lists/linux-wireless/msg148714.html
[2]: https://www.spinics.net/lists/netdev/msg374308.html
[3]: https://github.com/dtaht/bcake/blob/master/codel5.h
Michał
^ permalink raw reply
* Re: [PATCH net-next 3/8] fs/quota: use nla_put_u64_64bit()
From: Jan Kara @ 2016-04-26 12:37 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: dev-yBygre7rU0TnMu66kgdUjQ, Jan Kara, sd-y1jBWg8GRStKuXlAQpz2QA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, jhs-jkUAjuhPggJWk0Htik3J/w,
lars.ellenberg-63ez5xqkn6DQT0dZR+AlfA, jack-IBi9RG/b67k,
johannes-cdvu00un1VgdHxzADdlk8Q,
philipp.reisner-63ez5xqkn6DQT0dZR+AlfA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, kvalo-sgV2jX0FEOL9JmXXK+q4OQ,
drbd-dev-cunTk1MwBs8qoQakbn7OcQ
In-Reply-To: <571F5FBE.8050900-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
On Tue 26-04-16 14:31:58, Nicolas Dichtel wrote:
> Le 26/04/2016 13:08, Jan Kara a écrit :
> > On Tue 26-04-16 10:06:13, Nicolas Dichtel wrote:
> >> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> >
> > OK, so I somewhat miss a description of what will this do to the netlink
> > message so that I can judge whether the change is fine for the userspace
> > counterpart parsing these messages. AFAIU this changes the message format
> > by adding a QUOTA_NL_A_PAD field before each 64-bit field which needs an
> > alignment, am I guessing right? Thus when the userspace counterpart uses
> > genlmsg_parse() it should just silently ignore these attributes if I read
> > the documentation right. Did I understand this correctly?
> Yes, that's it.
OK, then feel free to add:
Acked-by: Jan Kara <jack@suse.cz>
to the quota patch.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [net-next PATCH 3/4] samples/bpf: add a README file to get users started
From: Daniel Borkmann @ 2016-04-26 12:40 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev, bblanco, borkmann, alexei.starovoitov, linux-kbuild
In-Reply-To: <20160426135647.7faf9a87@redhat.com>
On 04/26/2016 01:56 PM, Jesper Dangaard Brouer wrote:
> On Tue, 26 Apr 2016 13:44:06 +0200
> Daniel Borkmann <daniel@iogearbox.net> wrote:
>
>> On 04/26/2016 01:09 PM, Jesper Dangaard Brouer wrote:
>>> Getting started with using examples in samples/bpf/ is not
>>> straightforward. There are several dependencies, and specific
>>> versions of these dependencies.
>>>
>>> Just compiling the example tool is also slightly obscure, e.g. one
>>> need to call make like:
>>>
>>> make samples/bpf/
>>>
>>> Do notice the "/" slash after the directory name.
>>>
>>> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
>>> ---
>>> samples/bpf/README.rst | 67 ++++++++++++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 67 insertions(+)
>>> create mode 100644 samples/bpf/README.rst
>>>
>>> diff --git a/samples/bpf/README.rst b/samples/bpf/README.rst
>>> new file mode 100644
>>> index 000000000000..3e1ac05d8e7c
>>> --- /dev/null
>>> +++ b/samples/bpf/README.rst
>>> @@ -0,0 +1,67 @@
>>> +eBPF sample programs
>>> +====================
>>> +
>>> +This kernel samples/bpf directory contains a mini eBPF library, test
>>> +stubs, verifier test-suite and examples for using eBPF.
>>> +
>>> +Build dependencies
>>> +==================
>>> +
>>> +Compiling requires having installed:
>>> + * clang
>>> + * llvm >= version 3.7.0
>>> +
>>> +Note that LLVM's tool 'llc' must support target 'bpf', list with command::
>>> +
>>> + $ llc --version
>>> + LLVM (http://llvm.org/):
>>> + LLVM version 3.x.y
>>> + [...]
>>> + Host CPU: xxx
>>> +
>>> + Registered Targets:
>>> + [...]
>>> + bpf - BPF (host endian)
>>> + bpfeb - BPF (big endian)
>>> + bpfel - BPF (little endian)
>>> + [...]
>>> +
>>> +Kernel headers
>>> +--------------
>>> +
>>> +There are usually dependencies to header files of the current kernel.
>>> +To avoid installing devel kernel headers system wide, as a normal
>>> +user, simply call::
>>> +
>>> + make headers_install
>>> +
>>> +This will creates a local "usr/include" directory in the git/build top
>>> +level directory, that the make system automatically pickup first.
>>> +
>>> +Compiling
>>> +=========
>>> +
>>> +For compiling goto kernel top level build directory and run make like::
>>> +
>>> + make samples/bpf/
>>> +
>>> +Do notice the "/" slash after the directory name.
>>> +
>>> +Manually compiling LLVM with 'bpf' support
>>> +------------------------------------------
>>> +
>>> +In some LLVM versions the BPF target were marked experimental. To
>>> +compile LLVM manually and enable BPF target run (build dependencies
>>> +are cmake and gcc-c++)::
>>> +
>>> + $ git clone http://llvm.org/git/llvm.git
>>> + $ cd llvm
>>> + $ mkdir build; cd build
>>> + $ cmake .. -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=BPF
>>> + $ make
>>
>> That's perhaps a bit misleading in the sense that when you clone the
>> tree from git, you'd nowadays invoke cmake normally with LLVM_TARGETS_TO_BUILD
>> instead of LLVM_EXPERIMENTAL_TARGETS_TO_BUILD for BPF, as BPF is not an
>> experimental target anymore. It's probably also recommended to clone
>> clang into tools/ dir as well under your llvm/ repo when you compile
>> from scratch anyways.
>
> Can you come up with a formulation/desc I can use instead then?
You mean how to build with clang? There are various docs/snippets out
there, for example, see the 'Build LLVM and Clang development libs'
part of [1], that you can tweak for your README with.
[1] https://gist.github.com/brendangregg/cfa482acb71aa577789c
^ permalink raw reply
* Re: [PATCH V3] net: stmmac: socfpga: Remove re-registration of reset controller
From: Marek Vasut @ 2016-04-26 12:47 UTC (permalink / raw)
To: Joachim Eastwood
Cc: netdev, peppe.cavallaro, alexandre.torgue, Matthew Gerlach,
Dinh Nguyen, David S . Miller
In-Reply-To: <CAGhQ9Vz568hdSk+HWGHXuSNn4DU7HZkUBfVbajQyRkq+rBYY7Q@mail.gmail.com>
On 04/26/2016 02:26 PM, Joachim Eastwood wrote:
> On 26 April 2016 at 00:55, Marek Vasut <marex@denx.de> wrote:
>> On 04/25/2016 08:11 PM, Joachim Eastwood wrote:
>>> On 21 April 2016 at 14:11, Marek Vasut <marex@denx.de> wrote:
>>>>
>>>> Finally, plat_dat->exit and socfpga_dwmac_exit() is no longer necessary,
>>>> since the functionality is already performed by the stmmac core.
>>>
>>> I am trying to rebase my changes on top of your two patches and
>>> noticed a couple of things.
>>>
>>>> static int socfpga_dwmac_init(struct platform_device *pdev, void *priv)
>>>> {
>>>> - struct socfpga_dwmac *dwmac = priv;
>>>> + struct socfpga_dwmac *dwmac = priv;
>>>> struct net_device *ndev = platform_get_drvdata(pdev);
>>>> struct stmmac_priv *stpriv = NULL;
>>>> int ret = 0;
>>>>
>>>> - if (ndev)
>>>> - stpriv = netdev_priv(ndev);
>>>> + if (!ndev)
>>>> + return -EINVAL;
>>>
>>> ndev can never be NULL here. socfpga_dwmac_init() is only called if
>>> stmmac_dvr_probe() succeeds or we are running the resume callback. So
>>> I don't see how this could ever be NULL.
>>
>> That's a good point, this check can indeed be removed. While you're at
>> the patching, can you remove this one ?
>
> Yes, my patch will refactor the init() function so this will go away.
Thanks!
>>>> +
>>>> + stpriv = netdev_priv(ndev);
>>>
>>> It's not really nice to access 'stmmac_priv' as it should be private
>>> to the core driver, but I don't see any other good solution right now.
>>
>> I guess some stmmac_reset_assert() wrapper would be nicer, yes. What do
>> you think ?
>>
>>>> + if (!stpriv)
>>>> + return -EINVAL;
>>>>
>>>> /* Assert reset to the enet controller before changing the phy mode */
>>>> - if (dwmac->stmmac_rst)
>>>> - reset_control_assert(dwmac->stmmac_rst);
>>>> + if (stpriv->stmmac_rst)
>>>> + reset_control_assert(stpriv->stmmac_rst);
>>>>
>>>> /* Setup the phy mode in the system manager registers according to
>>>> * devicetree configuration
>>>> @@ -227,8 +210,8 @@ static int socfpga_dwmac_init(struct platform_device *pdev, void *priv)
>>>> /* Deassert reset for the phy configuration to be sampled by
>>>> * the enet controller, and operation to start in requested mode
>>>> */
>>>> - if (dwmac->stmmac_rst)
>>>> - reset_control_deassert(dwmac->stmmac_rst);
>>>> + if (stpriv->stmmac_rst)
>>>> + reset_control_deassert(stpriv->stmmac_rst);
>>>>
>>>> /* Before the enet controller is suspended, the phy is suspended.
>>>> * This causes the phy clock to be gated. The enet controller is
>>>> @@ -245,7 +228,7 @@ static int socfpga_dwmac_init(struct platform_device *pdev, void *priv)
>>>> * control register 0, and can be modified by the phy driver
>>>> * framework.
>>>> */
>>>> - if (stpriv && stpriv->phydev)
>>>> + if (stpriv->phydev)
>>>> phy_resume(stpriv->phydev);
>>>
>>> Before this change phy_resume() was only called during driver resume
>>> when , but your patches cause phy_resume() to called at probe time as
>>> well. Is this okey?
>>
>> I _hope_ it's OK. The cryptic comment above is not very helpful in this
>> aspect. Dinh ? :)
>
> My patches will move phy_resume() to the resume callback so it
> preserves the previous behavior. But if someone knows more about this
> that would be useful.
>
>
>> btw I wish you reviewed my patch a bit earlier to catch these bits.
>
> Sorry, about that. I have been really busy with other things lately.
Oh I'm real happy someone is doing the refactoring :) I appreciate your
work, sorry if that was unclear.
> My patches based on next from Friday can be found here now:
> https://github.com/manabian/linux-lpc/tree/net-socfpga-dwmac-on-next
>
> I had to add your latest patch as well since the next version I used
> didn't have it. I'll post the patches on netdev later today or
> tomorrow.
Looks like next wasn't synced for a few days, yeah.
You can add my:
On SoCFPGA Cyclone V SoC (DENX MCVEVK):
Tested-by: Marek Vasut <marex@denx.de>
to those patches
> regards,
> Joachim Eastwood
>
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH v2 net-next 11/13] Documentation: Bindings: Update DT binding for separating dsaf dev support
From: Rob Herring @ 2016-04-26 12:48 UTC (permalink / raw)
To: Yisen Zhuang
Cc: devicetree, netdev, linux-arm-kernel, pawel.moll, mark.rutland,
ijc+devicetree, galak, davem, will.deacon, catalin.marinas,
yankejian, huangdaode, salil.mehta, lipeng321, liguozhu,
xieqianqian, xuwei5, linuxarm
In-Reply-To: <1461402317-136499-12-git-send-email-Yisen.Zhuang@huawei.com>
On Sat, Apr 23, 2016 at 05:05:15PM +0800, Yisen Zhuang wrote:
> Because debug dsaf port was separated from service dsaf port, this patch
> updates the related information of DT binding.
Separated when? New version of the h/w? If so, where's the new
compatible string? This is quite a big binding change.
> Signed-off-by: Yisen Zhuang <yisen.zhuang@huawei.com>
>
> ---
> .../devicetree/bindings/net/hisilicon-hns-dsaf.txt | 59 ++++++++++++++++++----
> 1 file changed, 49 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
> index ecacfa4..5ccd4f0 100644
> --- a/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
> +++ b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
> @@ -7,19 +7,47 @@ Required properties:
> - mode: dsa fabric mode string. only support one of dsaf modes like these:
> "2port-64vf",
> "6port-16rss",
> - "6port-16vf".
> + "6port-16vf",
> + "single-port".
> - interrupt-parent: the interrupt parent of this device.
> - interrupts: should contain the DSA Fabric and rcb interrupt.
> - reg: specifies base physical address(es) and size of the device registers.
> - The first region is external interface control register base and size.
> - The second region is SerDes base register and size.
> + The first region is external interface control register base and size(optional,
> + only be used when subctrl-syscon is not exists). It is recommended using
only used when subctrl-syscon does not exist
> + subctrl-syscon rather than this address.
> + The second region is SerDes base register and size(optional, only be used when
> + serdes-syscon in port node is not exists. It is recommended using
similar rewording needed here.
> + serdes-syscon rather than this address.
> The third region is the PPE register base and size.
> - The fourth region is dsa fabric base register and size.
> - The fifth region is cpld base register and size, it is not required if do not use cpld.
> -- phy-handle: phy handle of physicl port, 0 if not any phy device. see ethernet.txt [1].
> + The fourth region is dsa fabric base register and size. It is not required for
> + single-port mode.
> +- reg-names: may be ppe-base and(or) dsaf-base. It is used to find the
> + corresponding reg's index.
But you have up to 5 regions.
The variable nature of what regions you have tells me you need more
specific compatible strings for each chip.
> +
> +- phy-handle: phy handle of physicl port, 0 if not any phy device. It is optional
s/physicl/physical/
> + attribute. If port node is exists, phy-handle in each port node will be used.
> + see ethernet.txt [1].
> +- subctrl-syscon: is syscon handle for external interface control register.
> +- reset-field-offset: is offset of reset field. Its value depends on the hardware
> + user manual.
> - buf-size: rx buffer size, should be 16-1024.
> - desc-num: number of description in TX and RX queue, should be 512, 1024, 2048 or 4096.
>
> +- port: subnodes of dsaf. A dsaf node may contain several port nodes(Depending
> + on mode of dsaf). Port node contain some attributes listed below:
> +- port-id: is physical port index in one dsaf.
Indexes should generally be avoided. What does the number correspond
to in h/w (if anything)?
> +- phy-handle: phy handle of physicl port. It is not required if there isn't
> + phy device. see ethernet.txt [1].
> +- serdes-syscon: is syscon handle for SerDes register.
> +- cpld-syscon: is syscon handle for cpld register. It is not required if there
> + isn't cpld device.
> +- cpld-ctrl-reg: is cpld register offset. It is not required if there isn't
> + cpld-syscon.
This would usually be a cell in the cpld-syscon property.
> +- port-rst-offset: is offset of reset field for each port in dsaf. Its value
> + depends on the hardware user manual.
> +- port-mode-offset: is offset of port mode field for each port in dsaf. Its
> + value depends on the hardware user manual.
Again, sounds like you need more specific compatible strings that imply
this information.
> +
> [1] Documentation/devicetree/bindings/net/phy.txt
>
> Example:
> @@ -28,11 +56,11 @@ dsaf0: dsa@c7000000 {
> compatible = "hisilicon,hns-dsaf-v1";
> mode = "6port-16rss";
> interrupt-parent = <&mbigen_dsa>;
> - reg = <0x0 0xC0000000 0x0 0x420000
> - 0x0 0xC2000000 0x0 0x300000
> - 0x0 0xc5000000 0x0 0x890000
> + reg = <0x0 0xc5000000 0x0 0x890000
> 0x0 0xc7000000 0x0 0x60000>;
> - phy-handle = <0 0 0 0 &soc0_phy4 &soc0_phy5 0 0>;
> + reg-names = "ppe-base", "dsaf-base";
> + subctrl-syscon = <&subctrl>;
> + reset-field-offset = 0;
> interrupts = <131 4>,<132 4>, <133 4>,<134 4>,
> <135 4>,<136 4>, <137 4>,<138 4>,
> <139 4>,<140 4>, <141 4>,<142 4>,
> @@ -43,4 +71,15 @@ dsaf0: dsa@c7000000 {
> buf-size = <4096>;
> desc-num = <1024>;
> dma-coherent;
> +
> + prot@0 {
port?
> + port-id = 0;
> + phy-handle = <&phy0>;
> + serdes-syscon = <&serdes>;
> + };
> +
> + prot@1 {
> + port-id = 1;
> + serdes-syscon = <&serdes>;
> + };
> };
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH] can: m_can: fix bitrate setup on latest silicon
From: Florian Vallee @ 2016-04-26 13:46 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde
Cc: linux-can, netdev, linux-kernel, ebenard, Florian Vallee
According to the m_can user manual changelog the BTP register layout was
updated with core revision 3.1.0
This change is not backward-compatible and using the current driver along
with a recent IP results in an incorrect bitrate on the wire.
Tested with a SAMA5D2 SoC (CREL = 0x31040730)
Signed-off-by: Florian Vallee <fvallee@eukrea.fr>
---
drivers/net/can/m_can/m_can.c | 38 +++++++++++++++++++++++++++++++++++---
1 file changed, 35 insertions(+), 3 deletions(-)
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index ef65517..d12b8f2 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -105,6 +105,10 @@ enum m_can_mram_cfg {
MRAM_CFG_NUM,
};
+/* Core Release Register (CREL) */
+#define CRR_REL_MASK 0xfff
+#define CRR_REL_SHIFT 20
+
/* Fast Bit Timing & Prescaler Register (FBTP) */
#define FBTR_FBRP_MASK 0x1f
#define FBTR_FBRP_SHIFT 16
@@ -136,7 +140,7 @@ enum m_can_mram_cfg {
#define CCCR_INIT BIT(0)
#define CCCR_CANFD 0x10
-/* Bit Timing & Prescaler Register (BTP) */
+/* Bit Timing & Prescaler Register (BTP) (M_CAN IP < 3.1.0) */
#define BTR_BRP_MASK 0x3ff
#define BTR_BRP_SHIFT 16
#define BTR_TSEG1_SHIFT 8
@@ -146,6 +150,16 @@ enum m_can_mram_cfg {
#define BTR_SJW_SHIFT 0
#define BTR_SJW_MASK 0xf
+/* Nominal Bit Timing & Prescaler Register (NBTP) (M_CAN IP >= 3.1.0) */
+#define NBTR_SJW_SHIFT 25
+#define NBTR_SJW_MASK (0x7f << NBTR_SJW_SHIFT)
+#define NBTR_BRP_SHIFT 16
+#define NBTR_BRP_MASK (0x3ff << NBTR_BRP_SHIFT)
+#define NBTR_TSEG1_SHIFT 8
+#define NBTR_TSEG1_MASK (0xff << NBTR_TSEG1_SHIFT)
+#define NBTR_TSEG2_SHIFT 0
+#define NBTR_TSEG2_MASK (0x7f << NBTR_TSEG2_SHIFT)
+
/* Error Counter Register(ECR) */
#define ECR_RP BIT(15)
#define ECR_REC_SHIFT 8
@@ -200,6 +214,9 @@ enum m_can_mram_cfg {
IR_RF1L | IR_RF0L)
#define IR_ERR_ALL (IR_ERR_STATE | IR_ERR_BUS)
+/* Core Version */
+#define M_CAN_COREREL_3_1_0 0x310
+
/* Interrupt Line Select (ILS) */
#define ILS_ALL_INT0 0x0
#define ILS_ALL_INT1 0xFFFFFFFF
@@ -357,6 +374,13 @@ static inline void m_can_disable_all_interrupts(const struct m_can_priv *priv)
m_can_write(priv, M_CAN_ILE, 0x0);
}
+static inline int m_can_read_core_rev(const struct m_can_priv *priv)
+{
+ u32 reg = m_can_read(priv, M_CAN_CREL);
+
+ return ((reg >> CRR_REL_SHIFT) & CRR_REL_MASK);
+}
+
static void m_can_read_fifo(struct net_device *dev, u32 rxfs)
{
struct net_device_stats *stats = &dev->stats;
@@ -814,8 +838,16 @@ static int m_can_set_bittiming(struct net_device *dev)
sjw = bt->sjw - 1;
tseg1 = bt->prop_seg + bt->phase_seg1 - 1;
tseg2 = bt->phase_seg2 - 1;
- reg_btp = (brp << BTR_BRP_SHIFT) | (sjw << BTR_SJW_SHIFT) |
- (tseg1 << BTR_TSEG1_SHIFT) | (tseg2 << BTR_TSEG2_SHIFT);
+
+ if (m_can_read_core_rev(priv) < M_CAN_COREREL_3_1_0)
+ reg_btp = (brp << BTR_BRP_SHIFT) | (sjw << BTR_SJW_SHIFT) |
+ (tseg1 << BTR_TSEG1_SHIFT) |
+ (tseg2 << BTR_TSEG2_SHIFT);
+ else
+ reg_btp = (brp << NBTR_BRP_SHIFT) | (sjw << NBTR_SJW_SHIFT) |
+ (tseg1 << NBTR_TSEG1_SHIFT) |
+ (tseg2 << NBTR_TSEG2_SHIFT);
+
m_can_write(priv, M_CAN_BTP, reg_btp);
if (priv->can.ctrlmode & CAN_CTRLMODE_FD) {
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] net/mlx5e: avoid stack overflow in mlx5e_open_channels
From: Saeed Mahameed @ 2016-04-26 13:48 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Saeed Mahameed, Matan Barak, Leon Romanovsky, David S. Miller,
Achiad Shochat, Or Gerlitz, Amir Vadai, Tariq Toukan,
Linux Netdev List, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1461590139-1396745-1-git-send-email-arnd-r2nGTMty4D4@public.gmane.org>
On Mon, Apr 25, 2016 at 4:15 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> struct mlx5e_channel_param is a large structure that is allocated
> on the stack of mlx5e_open_channels, and with a recent change
> it has grown beyond the warning size for the maximum stack
> that a single function should use:
>
> mellanox/mlx5/core/en_main.c: In function 'mlx5e_open_channels':
> mellanox/mlx5/core/en_main.c:1325:1: error: the frame size of 1072 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
>
> The function is already using dynamic allocation and is not in
> a fast path, so the easiest workaround is to use another kzalloc
> for allocating the channel parameters.
>
> Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Fixes: d3c9bc2743dc ("net/mlx5e: Added ICO SQs")
> ---
> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 21 +++++++++++++++------
> 1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> index 22742e1fbcb9..2ec547a80886 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> @@ -1266,12 +1266,14 @@ static void mlx5e_build_icosq_param(struct mlx5e_priv *priv,
> param->icosq = true;
> }
>
> -static void mlx5e_build_channel_param(struct mlx5e_priv *priv,
> - struct mlx5e_channel_param *cparam)
> +static struct mlx5e_channel_param *mlx5e_build_channel_param(struct mlx5e_priv *priv)
I prefer to keep the function prototype as before and move the dynamic
allocation to mlx5e_open_channels,
to keep alloc/free symmetric in mlx5e_open_channels.
> {
> + struct mlx5e_channel_param *cparam;
> u8 icosq_log_wq_sz = MLX5E_PARAMS_MINIMUM_LOG_SQ_SIZE;
>
> - memset(cparam, 0, sizeof(*cparam));
> + cparam = kzalloc(sizeof(struct mlx5e_channel_param), GFP_KERNEL);
> + if (!cparam)
> + return NULL;
>
> mlx5e_build_rq_param(priv, &cparam->rq);
> mlx5e_build_sq_param(priv, &cparam->sq);
> @@ -1279,11 +1281,13 @@ static void mlx5e_build_channel_param(struct mlx5e_priv *priv,
> mlx5e_build_rx_cq_param(priv, &cparam->rx_cq);
> mlx5e_build_tx_cq_param(priv, &cparam->tx_cq);
> mlx5e_build_ico_cq_param(priv, &cparam->icosq_cq, icosq_log_wq_sz);
> +
> + return cparam;
> }
>
> static int mlx5e_open_channels(struct mlx5e_priv *priv)
> {
> - struct mlx5e_channel_param cparam;
> + struct mlx5e_channel_param *cparam;
> int nch = priv->params.num_channels;
> int err = -ENOMEM;
> int i;
> @@ -1298,9 +1302,12 @@ static int mlx5e_open_channels(struct mlx5e_priv *priv)
You can do the allocation here, then you can benefit from the next
allocation check to test the 3 allocations altogether.
i.e:
if (!cparam || !priv->channel || !priv->txq_to_sq_map)
goto err_free_txq_to_sq_map;
> if (!priv->channel || !priv->txq_to_sq_map)
> goto err_free_txq_to_sq_map;
>
> - mlx5e_build_channel_param(priv, &cparam);
> + cparam = mlx5e_build_channel_param(priv);
> + if (!cparam)
> + goto err_free_txq_to_sq_map;
> +
> for (i = 0; i < nch; i++) {
> - err = mlx5e_open_channel(priv, i, &cparam, &priv->channel[i]);
> + err = mlx5e_open_channel(priv, i, cparam, &priv->channel[i]);
> if (err)
> goto err_close_channels;
> }
> @@ -1311,11 +1318,13 @@ static int mlx5e_open_channels(struct mlx5e_priv *priv)
> goto err_close_channels;
> }
>
> + kfree(cparam);
> return 0;
>
> err_close_channels:
> for (i--; i >= 0; i--)
> mlx5e_close_channel(priv->channel[i]);
> + kfree(cparam);
>
> err_free_txq_to_sq_map:
> kfree(priv->txq_to_sq_map);
> --
> 2.7.0
>
Saeed.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net/mlx5e: avoid stack overflow in mlx5e_open_channels
From: Arnd Bergmann @ 2016-04-26 13:53 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Saeed Mahameed, Matan Barak, Leon Romanovsky, David S. Miller,
Achiad Shochat, Or Gerlitz, Amir Vadai, Tariq Toukan,
Linux Netdev List, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CALzJLG98swFRKAZUcoXMWMyzX3z_h-HhTNZD_unh43VHByZY0A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tuesday 26 April 2016 16:48:33 Saeed Mahameed wrote:
> > }
> >
> > -static void mlx5e_build_channel_param(struct mlx5e_priv *priv,
> > - struct mlx5e_channel_param *cparam)
> > +static struct mlx5e_channel_param *mlx5e_build_channel_param(struct mlx5e_priv *priv)
>
> I prefer to keep the function prototype as before and move the dynamic
> allocation to mlx5e_open_channels,
> to keep alloc/free symmetric in mlx5e_open_channels.
>
>
Sure, do you want to just edit this when you forward the patch, or
do you need me to do it?
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ip: add udp_csum, udp6_csum_tx, udp6_csum_rx control flags to ip l2tp add tunnel
From: Wang Shanker @ 2016-04-26 14:15 UTC (permalink / raw)
To: netdev
Hi, all
It’s my first time to contribute to such an important open source project. Things began when I upgraded my server, called "Server A", form ubuntu 14.04 to 16.04, which is shipped with new kernel version, 4.4. After upgrade, I soon found a l2tp tunnel between this server and another linux server, called "Server B", via ipv6 broke down. Here is the network topology:
+----------+ +----------+
| Server A | -- IPV6 Network -- | Server B |
+----------+ +----------+
The l2tp tunnel was encapsulated in udp datagrams. All the configuration was normal and could work after I reverted the kernel on Server A to original version.
Here is what i did to create the tunnel:
```
on Server A:
ip l2tp add tunnel tunnel_id 86 peer_tunnel_id 86 remote 2001:db8::aaaa local 2001:db8::bbbb udp_sport 1086 udp_dport 1086
ip l2tp add session name l2tpeth0 tunnel_id 86 session_id 86 peer_session_id 86
ip l s l2tpeth0 up
on Server B:
ip l2tp add tunnel tunnel_id 86 peer_tunnel_id 86 local 2001:db8::aaaa remote 2001:db8::bbbb udp_sport 1086 udp_dport 1086
ip l2tp add session name l2tpeth0 tunnel_id 86 session_id 86 peer_session_id 86
ip l s l2tpeth0 up
```
When I used tcpdump to diagnose the problem, I got such result:
```
on Server A:
arping -i l2tpeth0 -0 1.2.3.4
on Server B:
tcpdump -i eth0 -n port 1086 -v
21:35:57.818810 IP6 (flowlabel 0x8f028, hlim 64, next-header UDP (17) payload length: 62) 2001:db8::aaaa.1086 > 2001:db8::bbbb.1086: [bad udp cksum 0x0000 -> 0x1140!] UDP, length 54
21:35:58.820572 IP6 (flowlabel 0x8f028, hlim 64, next-header UDP (17) payload length: 62) 2001:db8::aaaa.1086 > 2001:db8::bbbb.1086: [bad udp cksum 0x0000 -> 0x1140!] UDP, length 54
21:35:59.822216 IP6 (flowlabel 0x8f028, hlim 64, next-header UDP (17) payload length: 62) 2001:db8::aaaa.1086 > 2001:db8::bbbb.1086: [bad udp cksum 0x0000 -> 0x1140!] UDP, length 54
```
After looking into kernel source, I found out that in this commit a new feature to set udp6 checksum to zero in commit 6b649fe, which added `L2TP_ATTR_UDP_ZERO_CSUM6_TX` and `L2TP_ATTR_UDP_ZERO_CSUM6_TX`.
As a result, I added `udp_csum`, `udp6_csum_tx`, `udp6_csum_rx` control flags to `ip l2tp add tunnel` to control those attributes about checksum.
Using this to create the tunnel instead on Server A:
```
ip l2tp add tunnel tunnel_id 86 peer_tunnel_id 86 remote 2001:db8::aaaa local 2001:db8::bbbb udp_sport 1086 udp_dport 1086 udp6_csum_tx on udp6_csum_rx on
```
I finally got:
```
on Server A:
arping -i l2tpeth0 -0 1.2.3.4
on Server B:
tcpdump -i eth0 -n port 1086 -v
22:07:03.844297 IP6 (flowlabel 0x8f028, hlim 64, next-header UDP (17) payload length: 62) 2001:db8::aaaa.1086 > 2001:db8::bbbb.1086: [udp sum ok] UDP, length 54
22:07:04.845717 IP6 (flowlabel 0x8f028, hlim 64, next-header UDP (17) payload length: 62) 2001:db8::aaaa.1086 > 2001:db8::bbbb.1086: [udp sum ok] UDP, length 54
22:07:05.847965 IP6 (flowlabel 0x8f028, hlim 64, next-header UDP (17) payload length: 62) 2001:db8::aaaa.1086 > 2001:db8::bbbb.1086: [udp sum ok] UDP, length 54
tcpdump -i l2tpeth0 -v
22:10:35.691326 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1.2.3.4 tell 0.0.0.0, length 28
22:10:36.693627 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1.2.3.4 tell 0.0.0.0, length 28
22:10:37.695010 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1.2.3.4 tell 0.0.0.0, length 28
22:10:38.697121 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1.2.3.4 tell 0.0.0.0, length 28
```
It seems to work. However, is it the real point that should be fixed and does my patch fix it well? I need your suggestion.
---
ip/ipl2tp.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/ip/ipl2tp.c b/ip/ipl2tp.c
index 3c8ee93..67a6482 100644
--- a/ip/ipl2tp.c
+++ b/ip/ipl2tp.c
@@ -56,6 +56,8 @@ struct l2tp_parm {
uint16_t pw_type;
uint16_t mtu;
+ int udp6_csum_tx:1;
+ int udp6_csum_rx:1;
int udp_csum:1;
int recv_seq:1;
int send_seq:1;
@@ -117,6 +119,9 @@ static int create_tunnel(struct l2tp_parm *p)
if (p->encap == L2TP_ENCAPTYPE_UDP) {
addattr16(&req.n, 1024, L2TP_ATTR_UDP_SPORT, p->local_udp_port);
addattr16(&req.n, 1024, L2TP_ATTR_UDP_DPORT, p->peer_udp_port);
+ addattr8 (&req.n, 1024, L2TP_ATTR_UDP_CSUM, p->udp_csum);
+ addattr8 (&req.n, 1024, L2TP_ATTR_UDP_ZERO_CSUM6_TX, p->udp6_csum_tx);
+ addattr8 (&req.n, 1024, L2TP_ATTR_UDP_ZERO_CSUM6_RX, p->udp6_csum_rx);
}
if (rtnl_talk(&genl_rth, &req.n, NULL, 0) < 0)
@@ -282,6 +287,14 @@ static int get_response(struct nlmsghdr *n, void *arg)
p->l2spec_len = rta_getattr_u8(attrs[L2TP_ATTR_L2SPEC_LEN]);
p->udp_csum = !!attrs[L2TP_ATTR_UDP_CSUM];
+ if (attrs[L2TP_ATTR_UDP_ZERO_CSUM6_TX])
+ p->udp6_csum_tx = rta_getattr_u8(attrs[L2TP_ATTR_UDP_ZERO_CSUM6_TX]);
+ else
+ p->udp6_csum_tx = 1;
+ if (attrs[L2TP_ATTR_UDP_ZERO_CSUM6_RX])
+ p->udp6_csum_rx = rta_getattr_u8(attrs[L2TP_ATTR_UDP_ZERO_CSUM6_RX]);
+ else
+ p->udp6_csum_rx = 1;
if (attrs[L2TP_ATTR_COOKIE])
memcpy(p->cookie, RTA_DATA(attrs[L2TP_ATTR_COOKIE]),
p->cookie_len = RTA_PAYLOAD(attrs[L2TP_ATTR_COOKIE]));
@@ -470,6 +483,9 @@ static void usage(void)
fprintf(stderr, " tunnel_id ID peer_tunnel_id ID\n");
fprintf(stderr, " [ encap { ip | udp } ]\n");
fprintf(stderr, " [ udp_sport PORT ] [ udp_dport PORT ]\n");
+ fprintf(stderr, " [ udp_csum { on | off } ]\n");
+ fprintf(stderr, " [ udp6_csum_tx { on | off } ]\n");
+ fprintf(stderr, " [ udp6_csum_rx { on | off } ]\n");
fprintf(stderr, "Usage: ip l2tp add session [ name NAME ]\n");
fprintf(stderr, " tunnel_id ID\n");
fprintf(stderr, " session_id ID peer_session_id ID\n");
@@ -500,6 +516,8 @@ static int parse_args(int argc, char **argv, int cmd, struct l2tp_parm *p)
/* Defaults */
p->l2spec_type = L2TP_L2SPECTYPE_DEFAULT;
p->l2spec_len = 4;
+ p->udp6_csum_rx = 1;
+ p->udp6_csum_tx = 1;
while (argc > 0) {
if (strcmp(*argv, "encap") == 0) {
@@ -569,6 +587,33 @@ static int parse_args(int argc, char **argv, int cmd, struct l2tp_parm *p)
if (get_u16(&uval, *argv, 0))
invarg("invalid port\n", *argv);
p->peer_udp_port = uval;
+ } else if (strcmp(*argv, "udp_csum") == 0) {
+ NEXT_ARG();
+ if (strcmp(*argv, "on") == 0) {
+ p->udp_csum = 1;
+ } else if (strcmp(*argv, "off") == 0) {
+ p->udp_csum = 0;
+ } else {
+ invarg("invalid option for udp_csum\n", *argv);
+ }
+ } else if (strcmp(*argv, "udp6_csum_rx") == 0) {
+ NEXT_ARG();
+ if (strcmp(*argv, "on") == 0) {
+ p->udp6_csum_rx = 1;
+ } else if (strcmp(*argv, "off") == 0) {
+ p->udp6_csum_rx = 0;
+ } else {
+ invarg("invalid option for udp6_csum_rx\n", *argv);
+ }
+ } else if (strcmp(*argv, "udp6_csum_tx") == 0) {
+ NEXT_ARG();
+ if (strcmp(*argv, "on") == 0) {
+ p->udp6_csum_tx = 1;
+ } else if (strcmp(*argv, "off") == 0) {
+ p->udp6_csum_tx = 0;
+ } else {
+ invarg("invalid option for udp6_csum_tx\n", *argv);
+ }
} else if (strcmp(*argv, "offset") == 0) {
__u8 uval;
--
2.5.2
^ permalink raw reply related
* Re: [PATCH v5 09/21] IB/hns: Add hca support
From: Leon Romanovsky @ 2016-04-26 14:18 UTC (permalink / raw)
To: oulijun
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
jiri-VPRAkNaXOzVWk0Htik3J/w, ogerlitz-VPRAkNaXOzVWk0Htik3J/w,
linuxarm-hv44wF8Li93QT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
gongyangming-hv44wF8Li93QT0dZR+AlfA,
xiaokun-hv44wF8Li93QT0dZR+AlfA,
tangchaofei-hv44wF8Li93QT0dZR+AlfA,
haifeng.wei-hv44wF8Li93QT0dZR+AlfA,
yisen.zhuang-hv44wF8Li93QT0dZR+AlfA,
yankejian-hv44wF8Li93QT0dZR+AlfA,
lisheng011-hv44wF8Li93QT0dZR+AlfA,
charles.chenxin-hv44wF8Li93QT0dZR+AlfA
In-Reply-To: <571F0C04.2010005-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4292 bytes --]
On Tue, Apr 26, 2016 at 02:34:44PM +0800, oulijun wrote:
> On 2016/4/24 15:54, Leon Romanovsky wrote:
> > On Sat, Apr 23, 2016 at 06:26:47PM +0800, Lijun Ou wrote:
> >> This patch mainly setup hca for RoCE. it will do a series of
> >> initial works as follows:
> >> 1. init uar table, allocate uar resource
> >> 2. init pd table
> >> 3. init cq table
> >> 4. init mr table
> >> 5. init qp table
> >>
> >> Signed-off-by: Lijun Ou <oulijun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> >> Signed-off-by: Wei Hu(Xavier) <xavier.huwei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> >> ---
> >> drivers/infiniband/hw/hns/hns_roce_alloc.c | 104 ++++++++++++++++
> >> drivers/infiniband/hw/hns/hns_roce_cq.c | 25 ++++
> >> drivers/infiniband/hw/hns/hns_roce_device.h | 69 ++++++++++
> >> drivers/infiniband/hw/hns/hns_roce_eq.c | 1 -
> >> drivers/infiniband/hw/hns/hns_roce_icm.c | 88 +++++++++++++
> >> drivers/infiniband/hw/hns/hns_roce_icm.h | 9 ++
> >> drivers/infiniband/hw/hns/hns_roce_main.c | 79 ++++++++++++
> >> drivers/infiniband/hw/hns/hns_roce_mr.c | 187 ++++++++++++++++++++++++++++
> >> drivers/infiniband/hw/hns/hns_roce_pd.c | 65 ++++++++++
> >> drivers/infiniband/hw/hns/hns_roce_qp.c | 30 +++++
> >> 10 files changed, 656 insertions(+), 1 deletion(-)
> >> create mode 100644 drivers/infiniband/hw/hns/hns_roce_alloc.c
> >> create mode 100644 drivers/infiniband/hw/hns/hns_roce_mr.c
> >> create mode 100644 drivers/infiniband/hw/hns/hns_roce_pd.c
> >>
> >> diff --git a/drivers/infiniband/hw/hns/hns_roce_alloc.c b/drivers/infiniband/hw/hns/hns_roce_alloc.c
> >> new file mode 100644
> >> index 0000000..0c76f1b
> >> --- /dev/null
> >> +++ b/drivers/infiniband/hw/hns/hns_roce_alloc.c
> >> @@ -0,0 +1,104 @@
> >> +/*
> >> + * Copyright (c) 2016 Hisilicon Limited.
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License as published by
> >> + * the Free Software Foundation; either version 2 of the License, or
> >> + * (at your option) any later version.
> >> + */
> >> +
> >> +#include <linux/bitmap.h>
> >> +#include <linux/dma-mapping.h>
> >> +#include <linux/errno.h>
> >> +#include <linux/mm.h>
> >> +#include <linux/slab.h>
> >> +#include <linux/vmalloc.h>
> >> +#include "hns_roce_device.h"
> >> +
> >> +int hns_roce_bitmap_alloc(struct hns_roce_bitmap *bitmap, u32 *obj)
> >> +{
> >> + int ret = 0;
> >> +
> >> + spin_lock(&bitmap->lock);
> >> + *obj = find_next_zero_bit(bitmap->table, bitmap->max, bitmap->last);
> >> + if (*obj >= bitmap->max) {
> >> + bitmap->top = (bitmap->top + bitmap->max + bitmap->reserved_top)
> >> + & bitmap->mask;
> >> + *obj = find_first_zero_bit(bitmap->table, bitmap->max);
> >
> > find_first_zero_bit function returns "unsigned long" which may or may
> > not be equal to u32 on some architectures.
> >
> Hi Leon,
> I appreciate your keen eye. this code is meant for ARM64bit therefore should run corretly for 64-bit AARCH64.
> I will consider changing it as part of good partice and better portability "
> I will give a primary plan to modified it.
> for example:
> *obj = (u32)find_next_zero_bit(bitmap->table, bitmap->max, bitmap->last);
> Beause the max size of bitmap->table is u32 in current version.
>
> int hns_roce_bitmap_init(struct hns_roce_bitmap *bitmap, u32 num, u32 mask,
> u32 reserved_bot, u32 reserved_top)
> {
> u32 i;
>
> if (num != roundup_pow_of_two(num))
> return -EINVAL;
>
> bitmap->last = 0;
> bitmap->top = 0;
> bitmap->max = num - reserved_top;
> bitmap->mask = mask;
> bitmap->reserved_top = reserved_top;
> spin_lock_init(&bitmap->lock);
> bitmap->table = kcalloc(BITS_TO_LONGS(bitmap->max), sizeof(long),
> GFP_KERNEL);
>
> Is this plan ok?
No,
You are submitting new driver, please do it properly (without casting)
from the beginning.
>
> Thanks
> Lijun Ou
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ 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