summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-06-04Merge tag 'vfio-ccw-20190603' of ↵Heiko Carstens
https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw into features various vfio-ccw fixes (ccw translation, state machine)
2019-06-04s390/disassembler: update opcode tableMartin Schwidefsky
Sync with binutils and add a couple of missing instructions. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-04s390/mm: mmap base does not depend on ADDR_NO_RANDOMIZE personalityAlexandre Ghiti
randomize_stack_top() checks for current task flag PF_RANDOMIZE in order to use stack randomization and PF_RANDOMIZE is set when ADDR_NO_RANDOMIZE is unset, so no need to check for ADDR_NO_RANDOMIZE in stack_maxrandom_size. [heiko.carstens@de.ibm.com]: See also commit 01578e36163c ("x86/elf: Remove the unnecessary ADDR_NO_RANDOMIZE checks") Signed-off-by: Alexandre Ghiti <alex@ghiti.fr> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-04s390/Kconfig: pedantic cleanupsEnrico Weigelt, metux IT consult
Formatting of Kconfig files doesn't look so pretty, so just take damp cloth and clean it up. Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-04s390/purgatory: update .gitignoreMasahiro Yamada
Since commit 4c0f032d4963 ("s390/purgatory: Omit use of bin2c"), kexec-purgatory.c is not generated. purgatory and purgatory.lds are generated files, so should be ignored by git. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-04s390: drop meaningless 'targets' from tools MakefileMasahiro Yamada
'targets' should be specified to include .*.cmd files to evaluate if_changed or friends. Here, facility-defs.h and dis-defs.h are generated by filechk. Because filechk does not generate .*.cmd file, the 'targets' addition is meaningless. The filechk correctly updates the target when its content is changed. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-04s390: drop redundant directory creation from tools MakefileMasahiro Yamada
As you can see in scripts/Kbuild.include, the filechk creates the parent directory of the target as needed. This Makefile does not need to explicitly create the directory. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-04s390: drop unneeded -Wall addition from tools MakefileMasahiro Yamada
The top level Makefile adds -Wall globally for all host tools: KBUILD_HOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 \ I see two "-Wall" added for compiling these tools. Of course, it is allowed to pass the same option multiple times, but we do not need to do so. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-04s390: do not pass $(LINUXINCLUDE) to gen_opcode_table.cMasahiro Yamada
I guess HOSTCFLAGS_gen_opcode_table.o was blindly copied from HOSTCFLAGS_gen_facilities.o The reason of adding $(LINUXINCLUDE) to HOSTCFLAGS_gen_facilities.o is because gen_facilities.c references some CONFIG options. (Kbuild does not cater to this for host tools automatically.) On the other hand, gen_opcode_table.c does not reference CONFIG options at all. So, there is no good reason to pass $(LINUXINCLUDE). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-04s390/idal: use struct_size() in kmalloc()xiaolinkui
Use the new struct_size() helper to keep code simple. Signed-off-by: xiaolinkui <xiaolinkui@kylinos.cn> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-04s390/jump_label: replace stop_machine with smp_call_functionMartin Schwidefsky
The use of stop_machine to replace the mask bits of the jump label branch is a very heavy-weight operation. This is in fact not necessary, the mask of the branch can simply be updated, followed by a signal processor to all the other CPUs to force them to pick up the modified instruction. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> [heiko.carstens@de.ibm.com]: Change jump_label_make_nop() so we get brcl 0,offset instead of brcl 0,0. This makes sure that only the mask part of the instruction gets changed when updated. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-04arm64: mm: make CONFIG_ZONE_DMA32 configurableMiles Chen
This change makes CONFIG_ZONE_DMA32 defuly y and allows users to overwrite it only when CONFIG_EXPERT=y. For the SoCs that do not need CONFIG_ZONE_DMA32, this is the first step to manage all available memory by a single zone(normal zone) to reduce the overhead of multiple zones. The change also fixes a build error when CONFIG_NUMA=y and CONFIG_ZONE_DMA32=n. arch/arm64/mm/init.c:195:17: error: use of undeclared identifier 'ZONE_DMA32' max_zone_pfns[ZONE_DMA32] = PFN_DOWN(max_zone_dma_phys()); Change since v1: 1. only expose CONFIG_ZONE_DMA32 when CONFIG_EXPERT=y 2. remove redundant IS_ENABLED(CONFIG_ZONE_DMA32) Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Miles Chen <miles.chen@mediatek.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2019-06-04arm64/mm: Simplify protection flag creation for kernel huge mappingsAnshuman Khandual
Even though they have got the same value, PMD_TYPE_SECT and PUD_TYPE_SECT get used for kernel huge mappings. But before that first the table bit gets cleared using leaf level PTE_TABLE_BIT. Though functionally they are same, we should use page table level specific macros to be consistent as per the MMU specifications. Create page table level specific wrappers for kernel huge mapping entries and just drop mk_sect_prot() which does not have any other user. Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2019-06-04arm64: cacheinfo: Update cache_line_size detected from DT or PPTTShaokun Zhang
cache_line_size is derived from CTR_EL0.CWG field and is called mostly for I/O device drivers. For some platforms like the HiSilicon Kunpeng920 server SoC, cache line sizes are different between L1/2 cache and L3 cache while L1 cache line size is 64-byte and L3 is 128-byte, but CTR_EL0.CWG is misreporting using L1 cache line size. We shall correct the right value which is important for I/O performance. Let's update the cache line size if it is detected from DT or PPTT information. Cc: Will Deacon <will.deacon@arm.com> Cc: Jeremy Linton <jeremy.linton@arm.com> Cc: Zhenfa Qiu <qiuzhenfa@hisilicon.com> Reported-by: Zhenfa Qiu <qiuzhenfa@hisilicon.com> Suggested-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2019-06-04drivers: base: cacheinfo: Add variable to record max cache line sizeShaokun Zhang
Add coherency_max_size variable to record the maximum cache line size for different cache levels. If it is available, we will synchronize it as cache line size, otherwise we will use CTR_EL0.CWG reporting in cache_line_size() for arm64. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Jeremy Linton <jeremy.linton@arm.com> Cc: Will Deacon <will.deacon@arm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2019-06-04arm64/fpsimd: Don't disable softirq when touching FPSIMD/SVE stateJulien Grall
When the kernel is compiled with CONFIG_KERNEL_MODE_NEON, some part of the kernel may be able to use FPSIMD/SVE. This is for instance the case for crypto code. Any use of FPSIMD/SVE in the kernel are clearly marked by using the function kernel_neon_{begin, end}. Furthermore, this can only be used when may_use_simd() returns true. The current implementation of may_use_simd() allows softirq to use FPSIMD/SVE unless it is currently in use (i.e kernel_neon_busy is true). When in use, softirqs usually fall back to a software method. At the moment, as a softirq may use FPSIMD/SVE, softirqs are disabled when touching the FPSIMD/SVE context. This has the drawback to disable all softirqs even if they are not using FPSIMD/SVE. Since a softirq is supposed to check may_use_simd() anyway before attempting to use FPSIMD/SVE, there is limited reason to keep softirq disabled when touching the FPSIMD/SVE context. Instead, we can simply disable preemption and mark the FPSIMD/SVE context as in use by setting CPU's fpsimd_context_busy flag. Two new helpers {get, put}_cpu_fpsimd_context are introduced to mark the area using FPSIMD/SVE context and they are used to replace local_bh_{disable, enable}. The functions kernel_neon_{begin, end} are also re-implemented to use the new helpers. Additionally, double-underscored versions of the helpers are provided to called when preemption is already disabled. These are only relevant on paths where irqs are disabled anyway, so they are not needed for correctness in the current code. Let's use them anyway though: this marks critical sections clearly and will help to avoid mistakes during future maintenance. The change has been benchmarked on Linux 5.1-rc4 with defconfig. On Juno2: * hackbench 100 process 1000 (10 times) * .7% quicker On ThunderX 2: * hackbench 1000 process 1000 (20 times) * 3.4% quicker Reviewed-by: Dave Martin <dave.martin@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Julien Grall <julien.grall@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2019-06-04arm64/fpsimd: Introduce fpsimd_save_and_flush_cpu_state() and use itJulien Grall
The only external user of fpsimd_save() and fpsimd_flush_cpu_state() is the KVM FPSIMD code. A following patch will introduce a mechanism to acquire owernship of the FPSIMD/SVE context for performing context management operations. Rather than having to export the new helpers to get/put the context, we can just introduce a new function to combine fpsimd_save() and fpsimd_flush_cpu_state(). This has also the advantage to remove any external call of fpsimd_save() and fpsimd_flush_cpu_state(), so they can be turned static. Lastly, the new function can also be used in the PM notifier. Reviewed-by: Dave Martin <Dave.Martin@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Julien Grall <julien.grall@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2019-06-04arm64/fpsimd: Remove the prototype for sve_flush_cpu_state()Julien Grall
The function sve_flush_cpu_state() has been removed in commit 21cdd7fd76e3 ("KVM: arm64: Remove eager host SVE state saving"). So remove the associated prototype in asm/fpsimd.h. Reviewed-by: Dave Martin <Dave.Martin@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Julien Grall <julien.grall@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2019-06-04habanalabs: Read upper bits of trace buffer from RWPHITomer Tayar
The trace buffer address is 40 bits wide. The end of the buffer is set in the RWP register (lower 32 bits), and in the RWPHI register (upper 8 bits). Currently only the lower 32 bits are read, and this patch fixes it and concatenates the upper 8 bits to the output address. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2019-06-04arm64: arch_k3: Fix kconfig dependency warningYueHaibing
Fix Kbuild warning when SOC_TI is not set WARNING: unmet direct dependencies detected for TI_SCI_INTA_IRQCHIP Depends on [n]: TI_SCI_PROTOCOL [=y] && SOC_TI [=n] Selected by [y]: - ARCH_K3 [=y] Fixes: 009669e74813 ("arm64: arch_k3: Enable interrupt controller drivers") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com>
2019-06-04drm: don't block fb changes for async plane updatesHelen Koike
In the case of a normal sync update, the preparation of framebuffers (be it calling drm_atomic_helper_prepare_planes() or doing setups with drm_framebuffer_get()) are performed in the new_state and the respective cleanups are performed in the old_state. In the case of async updates, the preparation is also done in the new_state but the cleanups are done in the new_state (because updates are performed in place, i.e. in the current state). The current code blocks async udpates when the fb is changed, turning async updates into sync updates, slowing down cursor updates and introducing regressions in igt tests with errors of type: "CRITICAL: completed 97 cursor updated in a period of 30 flips, we expect to complete approximately 15360 updates, with the threshold set at 7680" Fb changes in async updates were prevented to avoid the following scenario: - Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1 - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2 - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2 (wrong) Where we have a single call to prepare fb2 but double cleanup call to fb2. To solve the above problems, instead of blocking async fb changes, we place the old framebuffer in the new_state object, so when the code performs cleanups in the new_state it will cleanup the old_fb and we will have the following scenario instead: - Async update, oldfb = NULL, newfb = fb1, prepare fb1, no cleanup - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb1 - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2 Where calls to prepare/cleanup are balanced. Cc: <stable@vger.kernel.org> # v4.14+ Fixes: 25dc194b34dd ("drm: Block fb changes for async plane updates") Suggested-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Helen Koike <helen.koike@collabora.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-6-helen.koike@collabora.com
2019-06-04drm/vc4: fix fb references in async updateHelen Koike
Async update callbacks are expected to set the old_fb in the new_state so prepare/cleanup framebuffers are balanced. Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new fb and put the old fb) is not required, as it's taken care by drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane(). Cc: <stable@vger.kernel.org> # v4.19+ Fixes: 539c320bfa97 ("drm/vc4: update cursors asynchronously through atomic") Suggested-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Helen Koike <helen.koike@collabora.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-5-helen.koike@collabora.com
2019-06-04drm/msm: fix fb references in async updateHelen Koike
Async update callbacks are expected to set the old_fb in the new_state so prepare/cleanup framebuffers are balanced. Cc: <stable@vger.kernel.org> # v4.14+ Fixes: 224a4c970987 ("drm/msm: update cursors asynchronously through atomic") Suggested-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Helen Koike <helen.koike@collabora.com> Acked-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-4-helen.koike@collabora.com
2019-06-04drm/amd: fix fb references in async updateHelen Koike
Async update callbacks are expected to set the old_fb in the new_state so prepare/cleanup framebuffers are balanced. Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new fb and put the old fb) is not required, as it's taken care by drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane(). Cc: <stable@vger.kernel.org> # v4.20+ Fixes: 674e78acae0d ("drm/amd/display: Add fast path for cursor plane updates") Suggested-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Helen Koike <helen.koike@collabora.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-3-helen.koike@collabora.com
2019-06-04drm/rockchip: fix fb references in async updateHelen Koike
In the case of async update, modifications are done in place, i.e. in the current plane state, so the new_state is prepared and the new_state is cleaned up (instead of the old_state, unlike what happens in a normal sync update). To cleanup the old_fb properly, it needs to be placed in the new_state in the end of async_update, so cleanup call will unreference the old_fb correctly. Also, the previous code had a: plane_state = plane->funcs->atomic_duplicate_state(plane); ... swap(plane_state, plane->state); if (plane->state->fb && plane->state->fb != new_state->fb) { ... } Which was wrong, as the fb were just assigned to be equal, so this if statement nevers evaluates to true. Another details is that the function drm_crtc_vblank_get() can only be called when vop->is_enabled is true, otherwise it has no effect and trows a WARN_ON(). Calling drm_atomic_set_fb_for_plane() (which get a referent of the new fb and pus the old fb) is not required, as it is taken care by drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane(). Fixes: 15609559a834 ("drm/rockchip: update cursors asynchronously through atomic.") Cc: <stable@vger.kernel.org> # v4.20+ Signed-off-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-2-helen.koike@collabora.com
2019-06-03xen-blkfront: switch kcalloc to kvcalloc for large array allocationRoger Pau Monne
There's no reason to request physically contiguous memory for those allocations. [boris: added CC to stable] Cc: stable@vger.kernel.org Reported-by: Ian Jackson <ian.jackson@citrix.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Juergen Gross <jgross@suse.com> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2019-06-04drm/mediatek: call mtk_dsi_stop() after mtk_drm_crtc_atomic_disable()Hsin-Yi Wang
mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(), which needs ovl irq for drm_crtc_wait_one_vblank(), since after mtk_dsi_stop() is called, ovl irq will be disabled. If drm_crtc_wait_one_vblank() is called after last irq, it will timeout with this message: "vblank wait timed out on crtc 0". This happens sometimes when turning off the screen. In drm_atomic_helper.c#disable_outputs(), the calling sequence when turning off the screen is: 1. mtk_dsi_encoder_disable() --> mtk_output_dsi_disable() --> mtk_dsi_stop(); /* sometimes make vblank timeout in atomic_disable */ --> mtk_dsi_poweroff(); 2. mtk_drm_crtc_atomic_disable() --> drm_crtc_wait_one_vblank(); ... --> mtk_dsi_ddp_stop() --> mtk_dsi_poweroff(); mtk_dsi_poweroff() has reference count design, change to make mtk_dsi_stop() called in mtk_dsi_poweroff() when refcount is 0. Fixes: 0707632b5bac ("drm/mediatek: update DSI sub driver flow for sending commands to panel") Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-06-04drm/mediatek: clear num_pipes when unbind driverHsin-Yi Wang
num_pipes is used for mutex created in mtk_drm_crtc_create(). If we don't clear num_pipes count, when rebinding driver, the count will be accumulated. From mtk_disp_mutex_get(), there can only be at most 10 mutex id. Clear this number so it starts from 0 in every rebind. Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-06-04drm/mediatek: call drm_atomic_helper_shutdown() when unbinding driverHsin-Yi Wang
shutdown all CRTC when unbinding drm driver. Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-06-04drm/mediatek: unbind components in mtk_drm_unbind()Hsin-Yi Wang
Unbinding components (i.e. mtk_dsi and mtk_disp_ovl/rdma/color) will trigger master(mtk_drm)'s .unbind(), and currently mtk_drm's unbind won't actually unbind components. During the next bind, mtk_drm_kms_init() is called, and the components are added back. .unbind() should call mtk_drm_kms_deinit() to unbind components. And since component_master_del() in .remove() will trigger .unbind(), which will also unregister device, it's fine to remove original functions called here. Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-06-04drm/mediatek: fix unbind functionsHsin-Yi Wang
detatch panel in mtk_dsi_destroy_conn_enc(), since .bind will try to attach it again. Fixes: 2e54c14e310f ("drm/mediatek: Add DSI sub driver") Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-06-03net: sfp: read eeprom in maximum 16 byte incrementsRussell King
Some SFP modules do not like reads longer than 16 bytes, so read the EEPROM in chunks of 16 bytes at a time. This behaviour is not specified in the SFP MSAs, which specifies: "The serial interface uses the 2-wire serial CMOS E2PROM protocol defined for the ATMEL AT24C01A/02/04 family of components." and "As long as the SFP+ receives an acknowledge, it shall serially clock out sequential data words. The sequence is terminated when the host responds with a NACK and a STOP instead of an acknowledge." We must avoid breaking a read across a 16-bit quantity in the diagnostic page, thankfully all 16-bit quantities in that page are naturally aligned. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-03selftests: set sysctl bc_forwarding properly in router_broadcast.shXin Long
sysctl setting bc_forwarding for $rp2 is needed when ping_test_from h2, otherwise the bc packets from $rp2 won't be forwarded. This patch is to add this setting for $rp2. Also, as ping_test_from does grep "$from" only, which could match some unexpected output, some test case doesn't really work, like: # ping_test_from $h2 198.51.200.255 198.51.200.2 PING 198.51.200.255 from 198.51.100.2 veth3: 56(84) bytes of data. 64 bytes from 198.51.100.1: icmp_seq=1 ttl=64 time=0.336 ms When doing grep $form (198.51.200.2), the output could still match. So change to grep "bytes from $from" instead. Fixes: 40f98b9af943 ("selftests: add a selftest for directed broadcast forwarding") Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-03net: ethernet: mediatek: Use NET_IP_ALIGN to judge if HW RX_2BYTE_OFFSET is ↵Sean Wang
enabled Should only enable HW RX_2BYTE_OFFSET function in the case NET_IP_ALIGN equals to 2. Signed-off-by: Mark Lee <mark-mc.lee@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-03net: ethernet: mediatek: Use hw_feature to judge if HWLRO is supportedSean Wang
Should hw_feature as hardware capability flags to check if hardware LRO got support. Signed-off-by: Mark Lee <mark-mc.lee@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-03Merge tag 'arc-5.2-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc Pull ARC fixes from Vineet Gupta: - Fix for userspace trying to access kernel vaddr space - HSDK platform DT updates - Cleanup some build warnings * tag 'arc-5.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc: ARC: [plat-hsdk] Get rid of inappropriate PHY settings ARC: [plat-hsdk]: Add support of Vivante GPU ARC: [plat-hsdk]: enable creg-gpio controller ARC: [plat-hsdk]: Add missing FIFO size entry in GMAC node ARC: [plat-hsdk]: Add missing multicast filter bins number to GMAC node ARC: mm: SIGSEGV userspace trying to access kernel virtual memory ARC: fix build warnings
2019-06-03net: ethernet: ti: cpsw_ethtool: fix ethtool ring param setIvan Khoronzhuk
Fix ability to set RX descriptor number, the reason - initially "tx_max_pending" was set incorrectly, but the issue appears after adding sanity check, so fix is for "sanity" patch. Fixes: 37e2d99b59c476 ("ethtool: Ensure new ring parameters are within bounds during SRINGPARAM") Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-03Merge branch 'reuseport-fixes'Alexei Starovoitov
Martin Lau says: ==================== s series has fixes when running reuseport's bpf_prog for udp lookup. If there is reuseport's bpf_prog, the common issue is the reuseport code path expects skb->data pointing to the transport header (udphdr here). A couple of commits broke this expectation. The issue is specific to running bpf_prog, so bpf tag is used for this series. Please refer to the individual commit message for details. ==================== Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-06-03bpf: udp: Avoid calling reuseport's bpf_prog from udp_groMartin KaFai Lau
When the commit a6024562ffd7 ("udp: Add GRO functions to UDP socket") added udp[46]_lib_lookup_skb to the udp_gro code path, it broke the reuseport_select_sock() assumption that skb->data is pointing to the transport header. This patch follows an earlier __udp6_lib_err() fix by passing a NULL skb to avoid calling the reuseport's bpf_prog. Fixes: a6024562ffd7 ("udp: Add GRO functions to UDP socket") Cc: Tom Herbert <tom@herbertland.com> Signed-off-by: Martin KaFai Lau <kafai@fb.com> Acked-by: Song Liu <songliubraving@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-06-03bpf: udp: ipv6: Avoid running reuseport's bpf_prog from __udp6_lib_errMartin KaFai Lau
__udp6_lib_err() may be called when handling icmpv6 message. For example, the icmpv6 toobig(type=2). __udp6_lib_lookup() is then called which may call reuseport_select_sock(). reuseport_select_sock() will call into a bpf_prog (if there is one). reuseport_select_sock() is expecting the skb->data pointing to the transport header (udphdr in this case). For example, run_bpf_filter() is pulling the transport header. However, in the __udp6_lib_err() path, the skb->data is pointing to the ipv6hdr instead of the udphdr. One option is to pull and push the ipv6hdr in __udp6_lib_err(). Instead of doing this, this patch follows how the original commit 538950a1b752 ("soreuseport: setsockopt SO_ATTACH_REUSEPORT_[CE]BPF") was done in IPv4, which has passed a NULL skb pointer to reuseport_select_sock(). Fixes: 538950a1b752 ("soreuseport: setsockopt SO_ATTACH_REUSEPORT_[CE]BPF") Cc: Craig Gallek <kraig@google.com> Signed-off-by: Martin KaFai Lau <kafai@fb.com> Acked-by: Song Liu <songliubraving@fb.com> Acked-by: Craig Gallek <kraig@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-06-03rcu: locking and unlocking need to always be at least barriersLinus Torvalds
Herbert Xu pointed out that commit bb73c52bad36 ("rcu: Don't disable preemption for Tiny and Tree RCU readers") was incorrect in making the preempt_disable/enable() be conditional on CONFIG_PREEMPT_COUNT. If CONFIG_PREEMPT_COUNT isn't enabled, the preemption enable/disable is a no-op, but still is a compiler barrier. And RCU locking still _needs_ that compiler barrier. It is simply fundamentally not true that RCU locking would be a complete no-op: we still need to guarantee (for example) that things that can trap and cause preemption cannot migrate into the RCU locked region. The way we do that is by making it a barrier. See for example commit 386afc91144b ("spinlocks and preemption points need to be at least compiler barriers") from back in 2013 that had similar issues with spinlocks that become no-ops on UP: they must still constrain the compiler from moving other operations into the critical region. Now, it is true that a lot of RCU operations already use READ_ONCE() and WRITE_ONCE() (which in practice likely would never be re-ordered wrt anything remotely interesting), but it is also true that that is not globally the case, and that it's not even necessarily always possible (ie bitfields etc). Reported-by: Herbert Xu <herbert@gondor.apana.org.au> Fixes: bb73c52bad36 ("rcu: Don't disable preemption for Tiny and Tree RCU readers") Cc: stable@kernel.org Cc: Boqun Feng <boqun.feng@gmail.com> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-06-03Merge tag 'nds32-for-linux-5.2-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/greentime/linux Pull nds32 fixes from Greentime Hu: - fix warning for math-emu - fix nds32 fpu exception handling - fix nds32 fpu emulation implementation * tag 'nds32-for-linux-5.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/greentime/linux: nds32: add new emulations for floating point instruction nds32: Avoid IEX status being incorrectly modified math-emu: Use statement expressions to fix Wshift-count-overflow warning
2019-06-03Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparcLinus Torvalds
Pull sparc fixes from David Miller: "Three bug fixes, and TLB flushing one is of particular brown paper bag quality..." * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc: sparc: perf: fix updated event period in response to PERF_EVENT_IOC_PERIOD mdesc: fix a missing-check bug in get_vdev_port_node_info() sparc64: Fix regression in non-hypervisor TLB flush xcall
2019-06-03Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhostLinus Torvalds
Pull virtio fixes from Michael Tsirkin: "Several fixes, some of them for CVEs" * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: vhost: scsi: add weight support vhost: vsock: add weight support vhost_net: fix possible infinite loop vhost: introduce vhost_exceeds_weight() virtio: Fix indentation of VIRTIO_MMIO virtio: add unlikely() to WARN_ON_ONCE()
2019-06-03ASoC: SOF: fix DSP oops definitions in FW ABIKai Vehmanen
The definitions for DSP oops structures were not aligned correctly to current FW ABI version 3.6.0, leading to invalid data being printed out to debug logs. Fix the structs and update related platform code accordingly. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-03ASoC: hda: fix unbalanced codec dev refcount for HDA_DEV_ASOCRanjani Sridharan
HDA_DEV_ASOC type codec device refcounts are managed differently from HDA_DEV_LEGACY devices. The refcount is released explicitly in snd_hdac_ext_bus_device_remove() for ASOC type devices. So, remove the put_device() call in snd_hda_codec_dev_free() for such devices to make the refcount balanced. This will prevent the NULL pointer exception when the codec driver is released after the card is freed. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-03ASoC: SOF: ipc: replace fw ready bitfield with explicit bit orderingSlawomir Blauciak
Previously the structure used bitfields, which do not guarantee bit ordering. This change makes sure the order is clearly defined. It also renames and repurposes the field for general use. Signed-off-by: Slawomir Blauciak <slawomir.blauciak@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-03ASoC: SOF: bump to ABI 3.6Pierre-Louis Bossart
We had a couple of misses with ABI changes, e.g. for Xtensa oops information and the integration of sound trigger, before we set-up a formal process to track evolutions. With this patch, the SOF kernel patches are officially aligned with the firmware 3.6 level. Changing this level has no impact on existing users and is fully backwards-compatible. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-03ASoC: SOF: soundwire: add initial soundwire supportPan Xiuli
Add soundwire dai type and update ABI version. Signed-off-by: Pan Xiuli <xiuli.pan@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-03ASoC: SOF: uapi: mirror firmware changesPierre-Louis Bossart
We missed these two definitions for GDB support and component notifications, they are defined for the SOF firmware. Since they are not used by the kernel so far, we can still add them without any ABI change. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-23 12:51:17 +0000