aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2019-10-14net: dsa: sja1105: Move PTP data to its own private structureVladimir Oltean4-296/+335
This is a non-functional change with 2 goals (both for the case when CONFIG_NET_DSA_SJA1105_PTP is not enabled): - Reduce the size of the sja1105_private structure. - Make the PTP code more self-contained. Leaving priv->ptp_data.lock to be initialized in sja1105_main.c is not a leftover: it will be used in a future patch "net: dsa: sja1105: Restore PTP time after switch reset". Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-14net: dsa: sja1105: Make all public PTP functions take dsa_switch as argumentVladimir Oltean5-36/+37
The new rule (as already started for sja1105_tas.h) is for functions of optional driver components (ones which may be disabled via Kconfig - PTP and TAS) to take struct dsa_switch *ds instead of struct sja1105_private *priv as first argument. This is so that forward-declarations of struct sja1105_private can be avoided. So make sja1105_ptp.h the second user of this rule. Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-14net: dsa: sja1105: Get rid of global declaration of struct ptp_clock_infoVladimir Oltean1-15/+14
We need priv->ptp_caps to hold a structure and not just a pointer, because we use container_of in the various PTP callbacks. Therefore, the sja1105_ptp_caps structure declared in the global memory of the driver serves no further purpose after copying it into priv->ptp_caps. So just populate priv->ptp_caps with the needed operations and remove sja1105_ptp_caps. Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-14Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextDavid S. Miller85-1020/+1889
Alexei Starovoitov says: ==================== pull-request: bpf-next 2019-10-14 The following pull-request contains BPF updates for your *net-next* tree. 12 days of development and 85 files changed, 1889 insertions(+), 1020 deletions(-) The main changes are: 1) auto-generation of bpf_helper_defs.h, from Andrii. 2) split of bpf_helpers.h into bpf_{helpers, helper_defs, endian, tracing}.h and move into libbpf, from Andrii. 3) Track contents of read-only maps as scalars in the verifier, from Andrii. 4) small x86 JIT optimization, from Daniel. 5) cross compilation support, from Ivan. 6) bpf flow_dissector enhancements, from Jakub and Stanislav. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-13Merge tag 'mac80211-next-for-net-next-2019-10-11' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-nextDavid S. Miller30-130/+212
Johannes Berg says: ==================== A few more small things, nothing really stands out: * minstrel improvements from Felix * a TX aggregation simplification * some additional capabilities for hwsim * minor cleanups & docs updates ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-13genetlink: do not parse attributes for families with zero maxattrMichal Kubecek1-6/+4
Commit c10e6cf85e7d ("net: genetlink: push attrbuf allocation and parsing to a separate function") moved attribute buffer allocation and attribute parsing from genl_family_rcv_msg_doit() into a separate function genl_family_rcv_msg_attrs_parse() which, unlike the previous code, calls __nlmsg_parse() even if family->maxattr is 0 (i.e. the family does its own parsing). The parser error is ignored and does not propagate out of genl_family_rcv_msg_attrs_parse() but an error message ("Unknown attribute type") is set in extack and if further processing generates no error or warning, it stays there and is interpreted as a warning by userspace. Dumpit requests are not affected as genl_family_rcv_msg_dumpit() bypasses the call of genl_family_rcv_msg_attrs_parse() if family->maxattr is zero. Move this logic inside genl_family_rcv_msg_attrs_parse() so that we don't have to handle it in each caller. v3: put the check inside genl_family_rcv_msg_attrs_parse() v2: adjust also argument of genl_family_rcv_msg_attrs_free() Fixes: c10e6cf85e7d ("net: genetlink: push attrbuf allocation and parsing to a separate function") Signed-off-by: Michal Kubecek <mkubecek@suse.cz> Acked-by: Jiri Pirko <jiri@mellanox.com> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-13tcp: improve recv_skip_hint for tcp_zerocopy_receiveSoheil Hassas Yeganeh1-5/+5
tcp_zerocopy_receive() rounds down the zc->length a multiple of PAGE_SIZE. This results in two issues: - tcp_zerocopy_receive sets recv_skip_hint to the length of the receive queue if the zc->length input is smaller than the PAGE_SIZE, even though the data in receive queue could be zerocopied. - tcp_zerocopy_receive would set recv_skip_hint of 0, in cases where we have a little bit of data after the perfectly-sized packets. To fix these issues, do not store the rounded down value in zc->length. Round down the length passed to zap_page_range(), and return min(inq, zc->length) when the zap_range is 0. Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-12Merge branch 'selftests-bpf-Makefile-cleanup'Alexei Starovoitov1-49/+8
Andrii Nakryiko says: ==================== Patch #1 enforces libbpf build to have bpf_helper_defs.h ready before test BPF programs are built. Patch #2 drops obsolete BTF/pahole detection logic from Makefile. v1->v2: - drop CPU and PROBE (Martin). ==================== Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-10-12selftests/bpf: Remove obsolete pahole/BTF support detectionAndrii Nakryiko1-48/+6
Given lots of selftests won't work without recent enough Clang/LLVM that fully supports BTF, there is no point in maintaining outdated BTF support detection and fall-back to pahole logic. Just assume we have everything we need. Signed-off-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20191011220146.3798961-3-andriin@fb.com
2019-10-12selftests/bpf: Enforce libbpf build before BPF programs are builtAndrii Nakryiko1-1/+2
Given BPF programs rely on libbpf's bpf_helper_defs.h, which is auto-generated during libbpf build, libbpf build has to happen before we attempt progs/*.c build. Enforce it as order-only dependency. Fixes: 24f25763d6de ("libbpf: auto-generate list of BPF helper definitions") Signed-off-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20191011220146.3798961-2-andriin@fb.com
2019-10-12Merge branch 'samples-cross-compile'Alexei Starovoitov5-99/+218
Ivan Khoronzhuk says: ==================== This series contains mainly fixes/improvements for cross-compilation but not only, tested for arm, arm64, and intended for any arch. Also verified on native build (not cross compilation) for x86_64 and arm, arm64. Initial RFC link: https://lkml.org/lkml/2019/8/29/1665 Prev. version: https://lkml.org/lkml/2019/10/9/1045 Besides the patches given here, the RFC also contains couple patches related to llvm clang arm: include: asm: swab: mask rev16 instruction for clang arm: include: asm: unified: mask .syntax unified for clang They are necessarily to verify arm 32 build. Also, couple more fixes were added but are not merged in bpf-next yet, they can be needed for verification/configuration steps, if not in your tree the fixes can be taken here: https://www.spinics.net/lists/netdev/msg601716.html https://www.spinics.net/lists/netdev/msg601714.html https://www.spinics.net/lists/linux-kbuild/msg23468.html Now, to build samples, SAMPLE_BPF should be enabled in config. The change touches not only cross-compilation and can have impact on other archs and build environments, so might be good idea to verify it in order to add appropriate changes, some warn options could be tuned also. All is tested on x86-64 with clang installed (has to be built containing targets for arm, arm64..., see llc --version, usually it's present already) Instructions to test native on x86_64 ================================================= Native build on x86_64 is done in usual way and shouldn't have difference except HOSTCC is now printed as CC wile building the samples. Instructions to test cross compilation on arm64 ================================================= gcc version 8.3.0 (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) I've used sdk for TI am65x got here: http://downloads.ti.com/processor-sdk-linux/esd/AM65X/latest/exports/\ ti-processor-sdk-linux-am65xx-evm-06.00.00.07-Linux-x86-Install.bin make ARCH=arm64 -C tools/ clean make ARCH=arm64 -C samples/bpf clean make ARCH=arm64 clean make ARCH=arm64 defconfig make ARCH=arm64 headers_install make ARCH=arm64 INSTALL_HDR_PATH=/../sdk/\ ti-processor-sdk-linux-am65xx-evm-06.00.00.07/linux-devkit/sysroots/\ aarch64-linux/usr headers_install make samples/bpf/ ARCH=arm64 CROSS_COMPILE="aarch64-linux-gnu-"\ SYSROOT="/../sdk/ti-processor-sdk-linux-am65xx-evm-06.00.00.07/\ linux-devkit/sysroots/aarch64-linux" Instructions to test cross compilation on arm ================================================= arm-linux-gnueabihf-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011 or arm-linux-gnueabihf-gcc (GNU Toolchain for the A-profile Architecture 8.3-2019.03 \ (arm-rel-8.36)) 8.3.0 http://downloads.ti.com/processor-sdk-linux/esd/AM57X/05_03_00_07/exports/\ ti-processor-sdk-linux-am57xx-evm-05.03.00.07-Linux-x86-Install.bin make ARCH=arm -C tools/ clean make ARCH=arm -C samples/bpf clean make ARCH=arm clean make ARCH=arm omap2plus_defconfig make ARCH=arm headers_install make ARCH=arm INSTALL_HDR_PATH=/../sdk/\ ti-processor-sdk-linux-am57xx-evm-05.03.00.07/linux-devkit/sysroots/\ armv7ahf-neon-linux-gnueabi/usr headers_install make samples/bpf/ ARCH=arm CROSS_COMPILE="arm-linux-gnueabihf-"\ SYSROOT="/../sdk/ti-processor-sdk-linux-am57xx-evm-05.03\ .00.07/linux-devkit/sysroots/armv7ahf-neon-linux-gnueabi" Based on bpf-next/master v5..v4: - any changes, only missed SOBs are added v4..v3: - renamed CLANG_EXTRA_CFLAGS on BPF_EXTRA_CFLAGS - used filter for ARCH_ARM_SELECTOR - omit "-fomit-frame-pointer" and use same flags for native and "cross" - used sample/bpf prefixes - use C instead of C++ compiler for test_libbpf target v3..v2: - renamed makefile.progs to makeifle.target, as more appropriate - left only __LINUX_ARM_ARCH__ for D options for arm - for host build - left options from KBUILD_HOST for compatibility reasons - split patch adding c/cxx/ld flags to libbpf by modules - moved readme change to separate patch - added patch setting options for cross-compile - fixed issue with option error for syscall_nrs.S, avoiding overlap for ccflags-y. v2..v1: - restructured patches order - split "samples: bpf: Makefile: base progs build on Makefile.progs" to make change more readable. It added couple nice extra patches. - removed redundant patch: "samples: bpf: Makefile: remove target for native build" - added fix: "samples: bpf: makefile: fix cookie_uid_helper_example obj build" - limited -D option filter only for arm - improved comments - added couple instructions to verify cross compilation for arm and arm64 arches based on TI am57xx and am65xx sdks. - corrected include a little order ==================== Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-10-12samples/bpf: Add preparation steps and sysroot info to readmeIvan Khoronzhuk1-5/+36
Add couple preparation steps: clean and configuration. Also add newly added sysroot support info to cross-compile section. Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20191011002808.28206-16-ivan.khoronzhuk@linaro.org
2019-10-12samples/bpf: Add sysroot supportIvan Khoronzhuk1-0/+5
Basically it only enables that was added by previous couple fixes. Sysroot contains correct libs installed and its headers. Useful when working with NFC or virtual machine. Usage example: clean (on demand) make ARCH=arm -C samples/bpf clean make ARCH=arm -C tools clean make ARCH=arm clean configure and install headers: make ARCH=arm defconfig make ARCH=arm headers_install build samples/bpf: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- samples/bpf/ \ SYSROOT="path/to/sysroot" Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20191011002808.28206-15-ivan.khoronzhuk@linaro.org
2019-10-12samples/bpf: Provide C/LDFLAGS to libbpfIvan Khoronzhuk1-1/+2
In order to build lib using C/LD flags of target arch, provide them to libbpf make. Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20191011002808.28206-14-ivan.khoronzhuk@linaro.org
2019-10-12libbpf: Add C/LDFLAGS to libbpf.so and test_libpf targetsIvan Khoronzhuk1-3/+4
In case of C/LDFLAGS there is no way to pass them correctly to build command, for instance when --sysroot is used or external libraries are used, like -lelf, wich can be absent in toolchain. This can be used for samples/bpf cross-compiling allowing to get elf lib from sysroot. Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20191011002808.28206-13-ivan.khoronzhuk@linaro.org
2019-10-12libbpf: Don't use cxx to test_libpf targetIvan Khoronzhuk2-19/+13
No need to use C++ for test_libbpf target when libbpf is on C and it can be tested with C, after this change the CXXFLAGS in makefiles can be avoided, at least in bpf samples, when sysroot is used, passing same C/LDFLAGS as for lib. Add "return 0" in test_libbpf to avoid warn, but also remove spaces at start of the lines to keep same style and avoid warns while apply. Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20191011002808.28206-12-ivan.khoronzhuk@linaro.org
2019-10-12samples/bpf: Use target CC environment for HDR_PROBEIvan Khoronzhuk1-3/+2
No need in hacking HOSTCC to be cross-compiler any more, so drop this trick and use target CC for HDR_PROBE. Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20191011002808.28206-11-ivan.khoronzhuk@linaro.org
2019-10-12samples/bpf: Use own flags but not HOSTCFLAGSIvan Khoronzhuk1-2/+4
While compiling natively, the host's cflags and ldflags are equal to ones used from HOSTCFLAGS and HOSTLDFLAGS. When cross compiling it should have own, used for target arch. While verification, for arm, arm64 and x86_64 the following flags were used always: -Wall -O2 -fomit-frame-pointer -Wmissing-prototypes -Wstrict-prototypes So, add them as they were verified and used before adding Makefile.target and lets omit "-fomit-frame-pointer" as were proposed while review, as no sense in such optimization for samples. Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20191011002808.28206-10-ivan.khoronzhuk@linaro.org
2019-10-12samples/bpf: Base target programs rules on Makefile.targetIvan Khoronzhuk1-66/+69
The main reason for that - HOSTCC and CC have different aims. HOSTCC is used to build programs running on host, that can cross-comple target programs with CC. It was tested for arm and arm64 cross compilation, based on linaro toolchain, but should work for others. So, in order to split cross compilation (CC) with host build (HOSTCC), lets base samples on Makefile.target. It allows to cross-compile samples/bpf programs with CC while auxialry tools running on host built with HOSTCC. Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20191011002808.28206-9-ivan.khoronzhuk@linaro.org
2019-10-12samples/bpf: Add makefile.target for separate CC target buildIvan Khoronzhuk1-0/+75
The Makefile.target is added only and will be used in sample/bpf/Makefile later in order to switch cross-compiling to CC from HOSTCC environment. The HOSTCC is supposed to build binaries and tools running on the host afterwards, in order to simplify build or so, like "fixdep" or else. In case of cross compiling "fixdep" is executed on host when the rest samples should run on target arch. In order to build binaries for target arch with CC and tools running on host with HOSTCC, lets add Makefile.target for simplicity, having definition and routines similar to ones, used in script/Makefile.host. This allows later add cross-compilation to samples/bpf with minimum changes. The tprog stands for target programs built with CC. Makefile.target contains only stuff needed for samples/bpf, potentially can be reused later and now needed only for unblocking tricky samples/bpf cross compilation. Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20191011002808.28206-8-ivan.khoronzhuk@linaro.org
2019-10-12samples/bpf: Drop unnecessarily inclusion for bpf_loadIvan Khoronzhuk1-1/+1
Drop inclusion for bpf_load -I$(objtree)/usr/include as it is included for all objects anyway, with above line: KBUILD_HOSTCFLAGS += -I$(objtree)/usr/include Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20191011002808.28206-7-ivan.khoronzhuk@linaro.org
2019-10-12samples/bpf: Use __LINUX_ARM_ARCH__ selector for armIvan Khoronzhuk1-0/+8
For arm, -D__LINUX_ARM_ARCH__=X is min version used as instruction set selector and is absolutely required while parsing some parts of headers. It's present in KBUILD_CFLAGS but not in autoconf.h, so let's retrieve it from and add to programs cflags. In another case errors like "SMP is not supported" for armv7 and bunch of other errors are issued resulting to incorrect final object. Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20191011002808.28206-6-ivan.khoronzhuk@linaro.org
2019-10-12samples/bpf: Use own EXTRA_CFLAGS for clang commandsIvan Khoronzhuk1-4/+5
It can overlap with CFLAGS used for libraries built with gcc if not now then in next patches. Correct it here for simplicity. Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20191011002808.28206-5-ivan.khoronzhuk@linaro.org
2019-10-12samples/bpf: Use --target from cross-compileIvan Khoronzhuk1-1/+1
For cross compiling the target triple can be inherited from cross-compile prefix as it's done in CLANG_FLAGS from kernel makefile. So copy-paste this decision from kernel Makefile. Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20191011002808.28206-4-ivan.khoronzhuk@linaro.org
2019-10-12samples/bpf: Fix cookie_uid_helper_example obj buildIvan Khoronzhuk1-1/+0
Don't list userspace "cookie_uid_helper_example" object in list for bpf objects. 'always' target is used for listing bpf programs, but 'cookie_uid_helper_example.o' is a user space ELF file, and covered by rule `per_socket_stats_example`, so shouldn't be in 'always'. Let us remove `always += cookie_uid_helper_example.o`, which avoids breaking cross compilation due to mismatched includes. Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20191011002808.28206-3-ivan.khoronzhuk@linaro.org
2019-10-12samples/bpf: Fix HDR_PROBE "echo"Ivan Khoronzhuk1-1/+1
echo should be replaced with echo -e to handle '\n' correctly, but instead, replace it with printf as some systems can't handle echo -e. Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20191011002808.28206-2-ivan.khoronzhuk@linaro.org
2019-10-11Merge branch 'netdevsim-add-devlink-health-reporters-support'David S. Miller11-27/+521
Jiri Pirko says: ==================== netdevsim: add devlink health reporters support This patchset adds support for devlink health reporter interface testing. First 2 patches are small dependencies of the last 2. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-11selftests: add netdevsim devlink health testsJiri Pirko1-1/+126
Add basic tests to verify functionality of netdevsim reporters. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-11netdevsim: implement couple of testing devlink health reportersJiri Pirko4-3/+354
Implement "empty" and "dummy" reporters. The first one is really simple and does nothing. The other one has debugfs files to trigger breakage and it is able to do recovery. The ops also implement dummy fmsg content. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-11devlink: propagate extack down to health reporter opsJiri Pirko6-23/+38
During health reporter operations, driver might want to fill-up the extack message, so propagate extack down to the health reporter ops. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-11devlink: don't do reporter recovery if the state is healthyJiri Pirko1-0/+3
If reporter state is healthy, don't call into a driver for recover and don't increase recovery count. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-11net: usb: ax88179_178a: write mac to hardware in get_mac_addrPeter Fink1-0/+3
When the MAC address is supplied via device tree or a random MAC is generated it has to be written to the asix chip in order to receive any data. Previously in 9fb137aef34e ("net: usb: ax88179_178a: allow optionally getting mac address from device tree") this line was omitted because it seemed to work perfectly fine without it. But it was simply not detected because the chip keeps the mac stored even beyond a reset and it was tested on a hardware with an integrated UPS where the asix chip was permanently powered on even throughout power cycles. Fixes: 9fb137aef34e ("net: usb: ax88179_178a: allow optionally getting mac address from device tree") Signed-off-by: Peter Fink <pfink@christ-es.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-11sock_get_timeout: drop unnecessary return variableVito Caputo1-6/+3
Remove pointless use of size return variable by directly returning sizes. Signed-off-by: Vito Caputo <vcaputo@pengaru.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-11af_unix: __unix_find_socket_byname() cleanupVito Caputo1-4/+2
Remove pointless return variable dance. Appears vestigial from when the function did locking as seen in unix_find_socket_byinode(), but locking is handled in unix_find_socket_byname() for __unix_find_socket_byname(). Signed-off-by: Vito Caputo <vcaputo@pengaru.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-11Merge branch 'net-ftgmac100-Ungate-RCLK-for-RMII-on-ASPEED-MACs'David S. Miller2-10/+48
Andrew Jeffery says: ==================== net: ftgmac100: Ungate RCLK for RMII on ASPEED MACs This series slightly extends the devicetree binding and driver for the FTGMAC100 to describe an optional RMII RCLK gate in the clocks property. Currently it's necessary for the kernel to ungate RCLK on the AST2600 in NCSI configurations as u-boot does not yet support NCSI (which uses the R(educed)MII). v2: * Clear up Reduced vs Reversed MII in the cover letter * Mitigate anxiety in the commit message for 1/3 * Clarify that AST2500 is also affected in the clocks property description in 2/3 * Rework the error paths and update some comments in 3/3 v1 can be found here: https://lore.kernel.org/netdev/20191008115143.14149-1-andrew@aj.id.au/ ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-11net: ftgmac100: Ungate RCLK for RMII on ASPEED MACsAndrew Jeffery1-10/+40
The 50MHz RCLK has to be enabled before the RMII interface will function. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-11dt-bindings: net: ftgmac100: Describe clock propertiesAndrew Jeffery1-0/+7
Critically, the AST2600 requires ungating the RMII RCLK if e.g. NCSI is in use. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Acked-by: Joel Stanley <joel@jms.id.au> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-11dt-bindings: net: ftgmac100: Document AST2600 compatibleAndrew Jeffery1-0/+1
The AST2600 contains an FTGMAC100-compatible MAC, although the MDIO controller previously embedded in the MAC has been moved out to a dedicated MDIO block. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Acked-by: Joel Stanley <joel@jms.id.au> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-11libbpf: Handle invalid typedef emitted by old GCCAndrii Nakryiko1-0/+11
Old GCC versions are producing invalid typedef for __gnuc_va_list pointing to void. Special-case this and emit valid: typedef __builtin_va_list __gnuc_va_list; Reported-by: John Fastabend <john.fastabend@gmail.com> Signed-off-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <kafai@fb.com> Acked-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20191011032901.452042-1-andriin@fb.com
2019-10-11libbpf: Generate more efficient BPF_CORE_READ codeAndrii Nakryiko1-2/+2
Existing BPF_CORE_READ() macro generates slightly suboptimal code. If there are intermediate pointers to be read, initial source pointer is going to be assigned into a temporary variable and then temporary variable is going to be uniformly used as a "source" pointer for all intermediate pointer reads. Schematically (ignoring all the type casts), BPF_CORE_READ(s, a, b, c) is expanded into: ({ const void *__t = src; bpf_probe_read(&__t, sizeof(*__t), &__t->a); bpf_probe_read(&__t, sizeof(*__t), &__t->b); typeof(s->a->b->c) __r; bpf_probe_read(&__r, sizeof(*__r), &__t->c); }) This initial `__t = src` makes calls more uniform, but causes slightly less optimal register usage sometimes when compiled with Clang. This can cascase into, e.g., more register spills. This patch fixes this issue by generating more optimal sequence: ({ const void *__t; bpf_probe_read(&__t, sizeof(*__t), &src->a); /* <-- src here */ bpf_probe_read(&__t, sizeof(*__t), &__t->b); typeof(s->a->b->c) __r; bpf_probe_read(&__r, sizeof(*__r), &__t->c); }) Fixes: 7db3822ab991 ("libbpf: Add BPF_CORE_READ/BPF_CORE_READ_INTO helpers") Signed-off-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20191011023847.275936-1-andriin@fb.com
2019-10-11xdp: Trivial, fix spelling in function descriptionAnton Ivanov1-1/+1
Fix typo 'boolian' into 'boolean'. Signed-off-by: Anton Ivanov <anton.ivanov@cambridgegreys.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20191011084303.28418-1-anton.ivanov@cambridgegreys.com
2019-10-11bpf: Fix cast to pointer from integer of different size warningAndrii Nakryiko1-1/+1
Fix "warning: cast to pointer from integer of different size" when casting u64 addr to void *. Fixes: a23740ec43ba ("bpf: Track contents of read-only maps as scalars") Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/20191011172053.2980619-1-andriin@fb.com
2019-10-11selftests/bpf: Check that flow dissector can be re-attachedJakub Sitnicki1-0/+127
Make sure a new flow dissector program can be attached to replace the old one with a single syscall. Also check that attaching the same program twice is prohibited. Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Stanislav Fomichev <sdf@google.com> Acked-by: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/20191011082946.22695-3-jakub@cloudflare.com
2019-10-11flow_dissector: Allow updating the flow dissector program atomicallyJakub Sitnicki1-3/+7
It is currently not possible to detach the flow dissector program and attach a new one in an atomic fashion, that is with a single syscall. Attempts to do so will be met with EEXIST error. This makes updates to flow dissector program hard. Traffic steering that relies on BPF-powered flow dissection gets disrupted while old program has been already detached but the new one has not been attached yet. There is also a window of opportunity to attach a flow dissector to a non-root namespace while updating the root flow dissector, thus blocking the update. Lastly, the behavior is inconsistent with cgroup BPF programs, which can be replaced with a single bpf(BPF_PROG_ATTACH, ...) syscall without any restrictions. Allow attaching a new flow dissector program when another one is already present with a restriction that it can't be the same program. Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Stanislav Fomichev <sdf@google.com> Acked-by: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/20191011082946.22695-2-jakub@cloudflare.com
2019-10-11bpf: Align struct bpf_prog_statsEric Dumazet1-1/+1
Do not risk spanning these small structures on two cache lines. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20191011181140.2898-1-edumazet@google.com
2019-10-11mac80211_hwsim: add support for OCBRamon Fontes1-2/+4
OCB (Outside the Context of a BSS) interfaces are the implementation of 802.11p, support that. Signed-off-by: Ramon Fontes <ramonreisfontes@gmail.com> Link: https://lore.kernel.org/r/20191010181307.11821-2-ramonreisfontes@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-10-11mac80211_hwsim: add more 5GHz channels, 5/10 MHz supportRamon Fontes1-2/+26
These new 5GHz channels and 5/10 MHz support should be available for OCB usage (802.11p). Signed-off-by: Ramon Fontes <ramonreisfontes@gmail.com> Link: https://lore.kernel.org/r/20191010181307.11821-1-ramonreisfontes@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-10-11mac80211: minstrel_ht: rename prob_ewma to prob_avg, use it for the new averageFelix Fietkau6-68/+63
Reduces per-rate data structure size Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20191008171139.96476-3-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-10-11mac80211: minstrel_ht: replace rate stats ewma with a better moving averageFelix Fietkau3-8/+76
Rate success probability usually fluctuates a lot under normal conditions. With a simple EWMA, noise and fluctuation can be reduced by increasing the window length, but that comes at the cost of introducing lag on sudden changes. This change replaces the EWMA implementation with a moving average that's designed to significantly reduce lag while keeping a bigger window size by being better at filtering out noise. It is only slightly more expensive than the simple EWMA and still avoids divisions in its calculation. The algorithm is adapted from an implementation intended for a completely different field (stock market trading), where the tradeoff of lag vs noise filtering is equally important. It is based on the "smoothing filter" from http://www.stockspotter.com/files/PredictiveIndicators.pdf. I have adapted it to fixed-point math with some constants so that it uses only addition, bit shifts and multiplication To better make use of the filtering and bigger window size, the update interval time is cut in half. For testing, the algorithm can be reverted to the older one via debugfs Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20191008171139.96476-2-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-10-11mac80211: minstrel: remove divisions in tx status pathFelix Fietkau2-8/+5
Use a slightly different threshold for downgrading spatial streams to make it easier to calculate without divisions. Slightly reduces CPU overhead. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20191008171139.96476-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.