summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-05-17rtw89: pci: only mask out INT indicator register for disable interrupt v1Ping-Ke Shih
The design of INT indicator register (R_AX_PCIE_HIMR00_V1) is to reduce IO during frequent interrupts, because it can stop chip sending interrupt to host if we just set this indicator to 0, not all IMR(s). This indicator register looks like a root interrupt controller of wifi chip. However, we can't set all other IMR(s) to 0 during we are running on interrupt service routine, or the indicator register can't reflect the status of certain interrupt happened during this period, and then miss some interrupts especially SER interrupt events. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220516005215.5878-7-pkshih@realtek.com
2022-05-17rtw89: convert rtw89_band to nl80211_band preciselyZong-Zhe Yang
Before 6 GHz band was supported, i.e. only 2 GHz and 5 GHz, they were the same from the numerical point of view. However, after 6 GHz band support, we need to do this conversion logically. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220516005215.5878-6-pkshih@realtek.com
2022-05-17rtw89: 8852c: update txpwr tables to HALRF_027_00_052Zong-Zhe Yang
Update notes: update the following to HALRF_027_00_052 TX power by rate table TX power limit table TX power limit RU table TX shape table doesn't seem to be changed on HALRF_027_00_052 Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220516005215.5878-5-pkshih@realtek.com
2022-05-17rtw89: cfo: check mac_id to avoid out-of-boundsPing-Ke Shih
Somehow, hardware reports incorrect mac_id and pollute memory. Check index before we access the array. UBSAN: array-index-out-of-bounds in rtw89/phy.c:2517:23 index 188 is out of range for type 's32 [64]' CPU: 1 PID: 51550 Comm: irq/35-rtw89_pc Tainted: G OE Call Trace: <IRQ> show_stack+0x52/0x58 dump_stack_lvl+0x4c/0x63 dump_stack+0x10/0x12 ubsan_epilogue+0x9/0x45 __ubsan_handle_out_of_bounds.cold+0x44/0x49 ? __alloc_skb+0x92/0x1d0 rtw89_phy_cfo_parse+0x44/0x7f [rtw89_core] rtw89_core_rx+0x261/0x871 [rtw89_core] ? __alloc_skb+0xee/0x1d0 rtw89_pci_napi_poll+0x3fa/0x4ea [rtw89_pci] __napi_poll+0x33/0x1a0 net_rx_action+0x126/0x260 ? __queue_work+0x217/0x4c0 __do_softirq+0xd9/0x315 ? disable_irq_nosync+0x10/0x10 do_softirq.part.0+0x6d/0x90 </IRQ> <TASK> __local_bh_enable_ip+0x62/0x70 rtw89_pci_interrupt_threadfn+0x182/0x1a6 [rtw89_pci] irq_thread_fn+0x28/0x60 irq_thread+0xc8/0x190 ? irq_thread_fn+0x60/0x60 kthread+0x16b/0x190 ? irq_thread_check_affinity+0xe0/0xe0 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30 </TASK> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220516005215.5878-4-pkshih@realtek.com
2022-05-17rtw89: 8852c: set TX antenna pathPing-Ke Shih
To make user space can set TX antenna via iw command. Then, we can diagnose antenna is connected properly or not, and measure TX power in single path. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220516005215.5878-3-pkshih@realtek.com
2022-05-17rtw89: add ieee80211::sta_rc_update opsPing-Ke Shih
When peer's NSS, rate or bandwidth is changed, we update RA(rate adaptive) mask to ensure transmitting packets properly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220516005215.5878-2-pkshih@realtek.com
2022-05-17wireless: Fix Makefile to be in alphabetical orderSrinivasan R
Fix quantenna to be in the right order Signed-off-by: Srinivasan R <srinir@outlook.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/MA1PR01MB26992E104B006B340C3C3A84C1CA9@MA1PR01MB2699.INDPRD01.PROD.OUTLOOK.COM
2022-05-17arm64: mte: Ensure the cleared tags are visible before setting the PTECatalin Marinas
As an optimisation, only pages mapped with PROT_MTE in user space have the MTE tags zeroed. This is done lazily at the set_pte_at() time via mte_sync_tags(). However, this function is missing a barrier and another CPU may see the PTE updated before the zeroed tags are visible. Add an smp_wmb() barrier if the mapping is Normal Tagged. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Fixes: 34bfeea4a9e9 ("arm64: mte: Clear the tags when a page is mapped in user-space with PROT_MTE") Cc: <stable@vger.kernel.org> # 5.10.x Reported-by: Vladimir Murzin <vladimir.murzin@arm.com> Cc: Will Deacon <will@kernel.org> Reviewed-by: Steven Price <steven.price@arm.com> Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> Link: https://lore.kernel.org/r/20220517093532.127095-1-catalin.marinas@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2022-05-17arm64: kexec: load from kimage prior to clobberingMark Rutland
In arm64_relocate_new_kernel() we load some fields out of the kimage structure after relocation has occurred. As the kimage structure isn't allocated to be relocation-safe, it may be clobbered during relocation, and we may load junk values out of the structure. Due to this, kexec may fail when the kimage allocation happens to fall within a PA range that an object will be relocated to. This has been observed to occur for regular kexec on a QEMU TCG 'virt' machine with 2GiB of RAM, where the PA range of the new kernel image overlaps the kimage structure. Avoid this by ensuring we load all values from the kimage structure prior to relocation. I've tested this atop v5.16 and v5.18-rc6. Fixes: 878fdbd70486 ("arm64: kexec: pass kimage as the only argument to relocation function") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: James Morse <james.morse@arm.com> Cc: Pasha Tatashin <pasha.tatashin@soleen.com> Cc: Will Deacon <will@kernel.org> Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com> Link: https://lore.kernel.org/r/20220516160735.731404-1-mark.rutland@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2022-05-17arm64: paravirt: Use RCU read locks to guard stolen_timePrakruthi Deepak Heragu
During hotplug, the stolen time data structure is unmapped and memset. There is a possibility of the timer IRQ being triggered before memset and stolen time is getting updated as part of this timer IRQ handler. This causes the below crash in timer handler - [ 3457.473139][ C5] Unable to handle kernel paging request at virtual address ffffffc03df05148 ... [ 3458.154398][ C5] Call trace: [ 3458.157648][ C5] para_steal_clock+0x30/0x50 [ 3458.162319][ C5] irqtime_account_process_tick+0x30/0x194 [ 3458.168148][ C5] account_process_tick+0x3c/0x280 [ 3458.173274][ C5] update_process_times+0x5c/0xf4 [ 3458.178311][ C5] tick_sched_timer+0x180/0x384 [ 3458.183164][ C5] __run_hrtimer+0x160/0x57c [ 3458.187744][ C5] hrtimer_interrupt+0x258/0x684 [ 3458.192698][ C5] arch_timer_handler_virt+0x5c/0xa0 [ 3458.198002][ C5] handle_percpu_devid_irq+0xdc/0x414 [ 3458.203385][ C5] handle_domain_irq+0xa8/0x168 [ 3458.208241][ C5] gic_handle_irq.34493+0x54/0x244 [ 3458.213359][ C5] call_on_irq_stack+0x40/0x70 [ 3458.218125][ C5] do_interrupt_handler+0x60/0x9c [ 3458.223156][ C5] el1_interrupt+0x34/0x64 [ 3458.227560][ C5] el1h_64_irq_handler+0x1c/0x2c [ 3458.232503][ C5] el1h_64_irq+0x7c/0x80 [ 3458.236736][ C5] free_vmap_area_noflush+0x108/0x39c [ 3458.242126][ C5] remove_vm_area+0xbc/0x118 [ 3458.246714][ C5] vm_remove_mappings+0x48/0x2a4 [ 3458.251656][ C5] __vunmap+0x154/0x278 [ 3458.255796][ C5] stolen_time_cpu_down_prepare+0xc0/0xd8 [ 3458.261542][ C5] cpuhp_invoke_callback+0x248/0xc34 [ 3458.266842][ C5] cpuhp_thread_fun+0x1c4/0x248 [ 3458.271696][ C5] smpboot_thread_fn+0x1b0/0x400 [ 3458.276638][ C5] kthread+0x17c/0x1e0 [ 3458.280691][ C5] ret_from_fork+0x10/0x20 As a fix, introduce rcu lock to update stolen time structure. Fixes: 75df529bec91 ("arm64: paravirt: Initialize steal time when cpu is online") Cc: stable@vger.kernel.org Suggested-by: Will Deacon <will@kernel.org> Signed-off-by: Prakruthi Deepak Heragu <quic_pheragu@quicinc.com> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> Reviewed-by: Srivatsa S. Bhat (VMware) <srivatsa@csail.mit.edu> Link: https://lore.kernel.org/r/20220513174654.362169-1-quic_eberman@quicinc.com Signed-off-by: Will Deacon <will@kernel.org>
2022-05-17scripts/min-tool-version.sh: raise minimum clang version to 14.0.0 for s390Heiko Carstens
Before version 14.0.0 llvm's integrated assembler fails to handle some displacement variants: arch/s390/purgatory/head.S:108:10: error: invalid operand for instruction lg %r11,kernel_type-.base_crash(%r13) Instead of working around this and given that this is already fixed raise the minimum clang version from 13.0.0 to 14.0.0. Acked-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://reviews.llvm.org/D113341 Link: https://lore.kernel.org/r/20220511120532.2228616-9-hca@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2022-05-17s390/boot: do not emit debug info for assembly with llvm's IASHeiko Carstens
Commit ee6d777d3e93 ("s390/decompressor: support extra debug flags") added extra debug flags, in particular debug info is created, depending on config options. With llvm's IAS this causes this compile warning: arch/s390/boot/head.S:38:1: warning: DWARF2 only supports one section per compilation unit .section ".head.text","ax" ^ This is a known problem and was addressed with commit b8a9092330da ("Kbuild: do not emit debug info for assembly with LLVM_IAS=1"). Just do the same for s390 to get rid of this warning. Tested-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/r/20220511120532.2228616-8-hca@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2022-05-17s390/boot: workaround llvm IAS bugHeiko Carstens
For at least the mvc and clc instructions llvm's integrated assembler can generate incorrect code. In particular this happens with decompressor boot code. The reason seems to be that relocations for the second displacement of each instruction are at incorrect locations (-/+: gas vs llvm IAS): mvc __LC_IO_NEW_PSW(16),.Lnewpsw results in 4: d2 0f 01 f0 00 00 mvc 496(16,%r0),0 - 8: R_390_12 .head.text+0x10 + 6: R_390_12 .head.text+0x10 and clc 0(3,%r4),.L_hdr results in 258: d5 02 40 00 00 00 clc 0(3,%r4),0 - 25c: R_390_12 .head.text+0x324 + 25a: R_390_12 .head.text+0x324 Workaround this by writing the code in a different way. Tested-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://github.com/llvm/llvm-project/issues/55411 Link: https://lore.kernel.org/r/20220511120532.2228616-7-hca@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2022-05-17s390/purgatory: workaround llvm's IAS limitationsHeiko Carstens
llvm's integrated assembler cannot handle immediate values which are calculated with two local labels: arch/s390/purgatory/head.S:139:11: error: invalid operand for instruction aghi %r8,-(.base_crash-purgatory_start) Workaround this by partially rewriting the code. Link: https://lore.kernel.org/r/20220511120532.2228616-6-hca@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2022-05-17s390/entry: workaround llvm's IAS limitationsHeiko Carstens
llvm's integrated assembler cannot handle immediate values which are calculated with two local labels: <instantiation>:3:13: error: invalid operand for instruction clgfi %r14,.Lsie_done - .Lsie_gmap Workaround this by adding clang specific code which reads the specific value from memory. Since this code is within the hot paths of the kernel and adds an additional memory reference, keep the original code, and add ifdef'ed code. Acked-by: Alexander Gordeev <agordeev@linux.ibm.com> Link: https://lore.kernel.org/r/20220511120532.2228616-5-hca@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2022-05-17s390/alternatives: remove padding generation codeHeiko Carstens
clang fails to handle ".if" statements in inline assembly which are heavily used in the alternatives code. To work around this remove this code, and enforce that users of alternatives must specify original and alternative instruction sequences which have identical sizes. Add a compile time check with two ".org" statements similar to arm64. In result not only clang can handle this, but also quite a lot of code can be removed. Acked-by: Vasily Gorbik <gor@linux.ibm.com> Tested-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://github.com/ClangBuiltLinux/linux/issues/1356 Link: https://lore.kernel.org/r/20220511120532.2228616-3-hca@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2022-05-17s390/alternatives: provide identical sized orginal/alternative sequencesHeiko Carstens
Explicitly provide identical sized original/alternative instruction sequences. This way there is no need for the s390 specific alternatives infrastructure to generate padding sequences. The code which generates such sequences will be removed with a follow on patch. Acked-by: Vasily Gorbik <gor@linux.ibm.com> Tested-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/r/20220511120532.2228616-2-hca@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2022-05-17hwmon: (dell-smm) Add cooling device supportArmin Wolf
Until now, only the temperature sensors where exported thru the thermal subsystem. Export the fans as "dell-smm-fan[1-3]" too to make them available as cooling devices. Also update Documentation and fix a minor issue with the alphabetic ordering of the includes. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20220410163935.7840-1-W_Armin@gmx.de Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2022-05-17hwmon: (asus-ec-sensors) add ProArt X570 Creator WIFI boardEugene Shalygin
Basing on information and testing provided by users [1] add support for another board, ASUS ProArt X570 Creator WiFi. [1] https://github.com/zeule/asus-ec-sensors/issues/17 Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com> Link: https://lore.kernel.org/r/20220422111737.1352610-1-eugene.shalygin@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2022-05-17hwmon: (intel-m10-bmc-hwmon) use devm_hwmon_sanitize_name()Michael Walle
Instead of open-coding the bad characters replacement in the hwmon name, use the new devm_hwmon_sanitize_name(). Signed-off-by: Michael Walle <michael@walle.cc> Acked-by: Xu Yilun <yilun.xu@intel.com> Reviewed-by: Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20220405092452.4033674-3-michael@walle.cc Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2022-05-17hwmon: introduce hwmon_sanitize_name()Michael Walle
More and more drivers will check for bad characters in the hwmon name and all are using the same code snippet. Consolidate that code by adding a new hwmon_sanitize_name() function. Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20220405092452.4033674-2-michael@walle.cc Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2022-05-17hwmon: (aquacomputer_d5next) Add support for Aquacomputer OctoAleksa Savic
Extend aquacomputer_d5next driver to expose hardware temperature sensors and fans of the Aquacomputer Octo fan controller, which communicates through a proprietary USB HID protocol. Four temperature sensors and eight PWM controllable fans are available. Additionally, serial number, firmware version and power-on count are exposed through debugfs. This driver has been tested on x86_64. Signed-off-by: Aleksa Savic <savicaleksa83@gmail.com> Link: https://lore.kernel.org/r/20220404134212.9690-1-savicaleksa83@gmail.com [groeck: Add missing "select CRC16"] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2022-05-17hwmon: (peci) Use devm_delayed_work_autocancel() to simplify codeChristophe JAILLET
Use devm_delayed_work_autocancel() instead of hand writing it. This is less verbose and saves a few lines of code. devm_delayed_work_autocancel() uses devm_add_action() instead of devm_add_action_or_reset(). This is fine, because if the underlying memory allocation fails, no work has been scheduled yet. So there is nothing to undo. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Iwona Winiarska <iwona.winiarska@intel.com> Link: https://lore.kernel.org/r/fd277a708ede3882d7df6831f02d2e3c0cb813b8.1644781718.git.christophe.jaillet@wanadoo.fr Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2022-05-17hwmon: (asus-ec-sensors) Add T_Sensor for ASUS WS X570-ACEWei Shuyu
WS X570-ACE has a T_Sensor header on board according to manual[1]. I'm using a 10kΩ B=3435K thermsistor attached to the header of WS X570-ACE. EC byte at 0x3d matches readings from BIOS sensor page and environment temperature. [1]https://www.asus.com/Motherboards-Components/Motherboards/All-series/Pro-WS-X570-ACE/HelpDesk_Manual/ Signed-off-by: Wei Shuyu <wsy@dogben.com> Link: https://lore.kernel.org/r/E1nY43Q-000rAm-9a@dogben.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2022-05-17hwmon: (jc42) add HWMON_C_TZ_REGISTEREduardo Valentin
Add a thermal zone interface to the devices added under jc42 driver. This way, thermal zones described in device tree can make use of the of nodes of these devices. Cc: Guenter Roeck <linux@roeck-us.net> (maintainer:JC42.4 TEMPERATURE SENSOR DRIVER) Cc: Jean Delvare <jdelvare@suse.com> (maintainer:HARDWARE MONITORING) Cc: linux-hwmon@vger.kernel.org (open list:JC42.4 TEMPERATURE SENSOR DRIVER) Cc: linux-kernel@vger.kernel.org (open list) Signed-off-by: Eduardo Valentin <eduval@amazon.com> Signed-off-by: Eduardo Valentin <evalenti@kernel.org> Link: https://lore.kernel.org/r/20220318233011.13980-1-eduval@amazon.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2022-05-17blk-cgroup: Remove unnecessary rcu_read_lock/unlock()Fanjun Kong
spin_lock_irq/spin_unlock_irq contains preempt_disable/enable(). Which can serve as RCU read-side critical region, so remove rcu_read_lock/unlock(). Signed-off-by: Fanjun Kong <bh1scw@gmail.com> Reviewed-by: Muchun Song <songmuchun@bytedance.com> Acked-by: Tejun Heo <tj@kernel.org> Link: https://lore.kernel.org/r/20220516173930.159535-1-bh1scw@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-05-17blk-cgroup: always terminate io.stat linesWolfgang Bumiller
With the removal of seq_get_buf in blkcg_print_one_stat, we cannot make adding the newline conditional on there being relevant stats because the name was already written out unconditionally. Otherwise we may end up with multiple device names in one line which is confusing and doesn't follow the nested-keyed file format. Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com> Fixes: 252c651a4c85 ("blk-cgroup: stop using seq_get_buf") Acked-by: Tejun Heo <tj@kernel.org> Link: https://lore.kernel.org/r/20220111083159.42340-1-w.bumiller@proxmox.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-05-17net: phy: marvell: Add errata section 5.1 for Alaska PHYLeszek Polak
As per Errata Section 5.1, if EEE is intended to be used, some register writes must be done once after every hardware reset. This patch now adds the necessary register writes as listed in the Marvell errata. Without this fix we experience ethernet problems on some of our boards equipped with a new version of this ethernet PHY (different supplier). The fix applies to Marvell Alaska 88E1510/88E1518/88E1512/88E1514 Rev. A0. Signed-off-by: Leszek Polak <lpolak@arri.de> Signed-off-by: Stefan Roese <sr@denx.de> Cc: Marek Behún <kabel@kernel.org> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Heiner Kallweit <hkallweit1@gmail.com> Cc: Russell King <linux@armlinux.org.uk> Cc: David S. Miller <davem@davemloft.net> Reviewed-by: Marek Behún <kabel@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20220516070859.549170-1-sr@denx.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-05-17dma-buf: fix use of DMA_BUF_SET_NAME_{A,B} in userspaceJérôme Pouiller
The typedefs u32 and u64 are not available in userspace. Thus user get an error he try to use DMA_BUF_SET_NAME_A or DMA_BUF_SET_NAME_B: $ gcc -Wall -c -MMD -c -o ioctls_list.o ioctls_list.c In file included from /usr/include/x86_64-linux-gnu/asm/ioctl.h:1, from /usr/include/linux/ioctl.h:5, from /usr/include/asm-generic/ioctls.h:5, from ioctls_list.c:11: ioctls_list.c:463:29: error: ‘u32’ undeclared here (not in a function) 463 | { "DMA_BUF_SET_NAME_A", DMA_BUF_SET_NAME_A, -1, -1 }, // linux/dma-buf.h | ^~~~~~~~~~~~~~~~~~ ioctls_list.c:464:29: error: ‘u64’ undeclared here (not in a function) 464 | { "DMA_BUF_SET_NAME_B", DMA_BUF_SET_NAME_B, -1, -1 }, // linux/dma-buf.h | ^~~~~~~~~~~~~~~~~~ The issue was initially reported here[1]. [1]: https://github.com/jerome-pouiller/ioctl/pull/14 Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Reviewed-by: Christian König <christian.koenig@amd.com> Fixes: a5bff92eaac4 ("dma-buf: Fix SET_NAME ioctl uapi") CC: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20220517072708.245265-1-Jerome.Pouiller@silabs.com Signed-off-by: Christian König <christian.koenig@amd.com>
2022-05-17net: qede: Remove unnecessary synchronize_irq() before free_irq()Minghao Chi
Calling synchronize_irq() right before free_irq() is quite useless. On one hand the IRQ can easily fire again before free_irq() is entered, on the other hand free_irq() itself calls synchronize_irq() internally (in a race condition free way), before any state associated with the IRQ is freed. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Link: https://lore.kernel.org/r/20220516082251.1651350-1-chi.minghao@zte.com.cn Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-05-17mac80211: refactor freeing the next_beaconJohannes Berg
We have this code seven times, refactor it into a separate function. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-17net: vxge: Remove unnecessary synchronize_irq() before free_irq()Minghao Chi
Calling synchronize_irq() right before free_irq() is quite useless. On one hand the IRQ can easily fire again before free_irq() is entered, on the other hand free_irq() itself calls synchronize_irq() internally (in a race condition free way), before any state associated with the IRQ is freed. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Link: https://lore.kernel.org/r/20220516081914.1651281-1-chi.minghao@zte.com.cn Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-05-17qed: Remove unnecessary synchronize_irq() before free_irq()Minghao Chi
Calling synchronize_irq() right before free_irq() is quite useless. On one hand the IRQ can easily fire again before free_irq() is entered, on the other hand free_irq() itself calls synchronize_irq() internally (in a race condition free way), before any state associated with the IRQ is freed. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Link: https://lore.kernel.org/r/20220516072646.1651109-1-chi.minghao@zte.com.cn Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-05-17regulator: scmi: Fix refcount leak in scmi_regulator_probeMiaoqian Lin
of_find_node_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. Fixes: 0fbeae70ee7c ("regulator: add SCMI driver") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Link: https://lore.kernel.org/r/20220516074433.32433-1-linmq006@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-05-17x86/sev: Remove duplicated assignment to variable infoColin Ian King
Variable info is being assigned the same value twice, remove the redundant assignment. Also assign variable v in the declaration. Cleans up clang scan warning: warning: Value stored to 'info' during its initialization is never read [deadcode.DeadStores] No code changed: # arch/x86/kernel/sev.o: text data bss dec hex filename 19878 4487 4112 28477 6f3d sev.o.before 19878 4487 4112 28477 6f3d sev.o.after md5: bfbaa515af818615fd01fea91e7eba1b sev.o.before.asm bfbaa515af818615fd01fea91e7eba1b sev.o.after.asm [ bp: Running the before/after check on sev.c because sev-shared.c gets included into it. ] Fixes: 597cfe48212a ("x86/boot/compressed/64: Setup a GHCB-based VC Exception handler") Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/20220516184215.51841-1-colin.i.king@gmail.com
2022-05-17cfg80211: fix kernel-doc for cfg80211_beacon_dataJohannes Berg
The kernel-doc comment is formatted badly, resulting in a warning: include/net/cfg80211.h:1188: warning: bad line: [...] Fix that. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-17xtensa: improve call0 ABI probingMax Filippov
When call0 userspace ABI support by probing is enabled instructions that cause illegal instruction exception when PS.WOE is clear are retried with PS.WOE set before calling c-level exception handler. Record user pc at which PS.WOE was set in the fast exception handler and clear PS.WOE in the c-level exception handler if we get there from the same address. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2022-05-17xtensa: support artificial division by 0 exceptionMax Filippov
On xtensa cores wihout hardware division option division support functions from libgcc react to division by 0 attempt by executing illegal instruction followed by the characters 'DIV0'. Recognize this pattern in illegal instruction exception handler and convert it to division by 0. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2022-05-17ax25: merge repeat codes in ax25_dev_device_down()Lu Wei
Merge repeat codes to reduce the duplication. Signed-off-by: Lu Wei <luwei32@huawei.com> Link: https://lore.kernel.org/r/20220516062804.254742-1-luwei32@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-05-17net: vmxnet3: fix possible NULL pointer dereference in vmxnet3_rq_cleanup()Zixuan Fu
In vmxnet3_rq_create(), when dma_alloc_coherent() fails, vmxnet3_rq_destroy() is called. It sets rq->rx_ring[i].base to NULL. Then vmxnet3_rq_create() returns an error to its callers mxnet3_rq_create_all() -> vmxnet3_change_mtu(). Then vmxnet3_change_mtu() calls vmxnet3_force_close() -> dev_close() in error handling code. And the driver calls vmxnet3_close() -> vmxnet3_quiesce_dev() -> vmxnet3_rq_cleanup_all() -> vmxnet3_rq_cleanup(). In vmxnet3_rq_cleanup(), rq->rx_ring[ring_idx].base is accessed, but this variable is NULL, causing a NULL pointer dereference. To fix this possible bug, an if statement is added to check whether rq->rx_ring[0].base is NULL in vmxnet3_rq_cleanup() and exit early if so. The error log in our fault-injection testing is shown as follows: [ 65.220135] BUG: kernel NULL pointer dereference, address: 0000000000000008 ... [ 65.222633] RIP: 0010:vmxnet3_rq_cleanup_all+0x396/0x4e0 [vmxnet3] ... [ 65.227977] Call Trace: ... [ 65.228262] vmxnet3_quiesce_dev+0x80f/0x8a0 [vmxnet3] [ 65.228580] vmxnet3_close+0x2c4/0x3f0 [vmxnet3] [ 65.228866] __dev_close_many+0x288/0x350 [ 65.229607] dev_close_many+0xa4/0x480 [ 65.231124] dev_close+0x138/0x230 [ 65.231933] vmxnet3_force_close+0x1f0/0x240 [vmxnet3] [ 65.232248] vmxnet3_change_mtu+0x75d/0x920 [vmxnet3] ... Fixes: d1a890fa37f27 ("net: VMware virtual Ethernet NIC driver: vmxnet3") Reported-by: TOTE Robot <oslab@tsinghua.edu.cn> Signed-off-by: Zixuan Fu <r33s3n6@gmail.com> Link: https://lore.kernel.org/r/20220514050711.2636709-1-r33s3n6@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-05-17net: vmxnet3: fix possible use-after-free bugs in vmxnet3_rq_alloc_rx_buf()Zixuan Fu
In vmxnet3_rq_alloc_rx_buf(), when dma_map_single() fails, rbi->skb is freed immediately. Similarly, in another branch, when dma_map_page() fails, rbi->page is also freed. In the two cases, vmxnet3_rq_alloc_rx_buf() returns an error to its callers vmxnet3_rq_init() -> vmxnet3_rq_init_all() -> vmxnet3_activate_dev(). Then vmxnet3_activate_dev() calls vmxnet3_rq_cleanup_all() in error handling code, and rbi->skb or rbi->page are freed again in vmxnet3_rq_cleanup_all(), causing use-after-free bugs. To fix these possible bugs, rbi->skb and rbi->page should be cleared after they are freed. The error log in our fault-injection testing is shown as follows: [ 14.319016] BUG: KASAN: use-after-free in consume_skb+0x2f/0x150 ... [ 14.321586] Call Trace: ... [ 14.325357] consume_skb+0x2f/0x150 [ 14.325671] vmxnet3_rq_cleanup_all+0x33a/0x4e0 [vmxnet3] [ 14.326150] vmxnet3_activate_dev+0xb9d/0x2ca0 [vmxnet3] [ 14.326616] vmxnet3_open+0x387/0x470 [vmxnet3] ... [ 14.361675] Allocated by task 351: ... [ 14.362688] __netdev_alloc_skb+0x1b3/0x6f0 [ 14.362960] vmxnet3_rq_alloc_rx_buf+0x1b0/0x8d0 [vmxnet3] [ 14.363317] vmxnet3_activate_dev+0x3e3/0x2ca0 [vmxnet3] [ 14.363661] vmxnet3_open+0x387/0x470 [vmxnet3] ... [ 14.367309] [ 14.367412] Freed by task 351: ... [ 14.368932] __dev_kfree_skb_any+0xd2/0xe0 [ 14.369193] vmxnet3_rq_alloc_rx_buf+0x71e/0x8d0 [vmxnet3] [ 14.369544] vmxnet3_activate_dev+0x3e3/0x2ca0 [vmxnet3] [ 14.369883] vmxnet3_open+0x387/0x470 [vmxnet3] [ 14.370174] __dev_open+0x28a/0x420 [ 14.370399] __dev_change_flags+0x192/0x590 [ 14.370667] dev_change_flags+0x7a/0x180 [ 14.370919] do_setlink+0xb28/0x3570 [ 14.371150] rtnl_newlink+0x1160/0x1740 [ 14.371399] rtnetlink_rcv_msg+0x5bf/0xa50 [ 14.371661] netlink_rcv_skb+0x1cd/0x3e0 [ 14.371913] netlink_unicast+0x5dc/0x840 [ 14.372169] netlink_sendmsg+0x856/0xc40 [ 14.372420] ____sys_sendmsg+0x8a7/0x8d0 [ 14.372673] __sys_sendmsg+0x1c2/0x270 [ 14.372914] do_syscall_64+0x41/0x90 [ 14.373145] entry_SYSCALL_64_after_hwframe+0x44/0xae ... Fixes: 5738a09d58d5a ("vmxnet3: fix checks for dma mapping errors") Reported-by: TOTE Robot <oslab@tsinghua.edu.cn> Signed-off-by: Zixuan Fu <r33s3n6@gmail.com> Link: https://lore.kernel.org/r/20220514050656.2636588-1-r33s3n6@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-05-17Merge branch irq/gic-v3-nmi-fixes-5.19 into irq/irqchip-nextMarc Zyngier
* irq/gic-v3-nmi-fixes-5.19: : . : GICv3 pseudo-NMI fixes from Mark Rutland: : : "These patches fix a couple of issues with the way GICv3 pseudo-NMIs are : handled: : : * The first patch adds a barrier we missed from NMI handling due to an : oversight. : : * The second patch refactors some logic around reads from ICC_IAR1_EL1 : and adds commentary to explain what's going on. : : * The third patch descends into madness, reworking gic_handle_irq() to : consistently manage ICC_PMR_EL1 + DAIF and avoid cases where these can : be left in an inconsistent state while softirqs are processed." : . irqchip/gic-v3: Fix priority mask handling irqchip/gic-v3: Refactor ISB + EOIR at ack time irqchip/gic-v3: Ensure pseudo-NMIs have an ISB between ack and handling Signed-off-by: Marc Zyngier <maz@kernel.org>
2022-05-17Merge branch irq/misc-5.19 into irq/irqchip-nextMarc Zyngier
* irq/misc-5.19: : . : Misc fixes and minor improvements: : : - GIC: Improve warning when the firmware tables are inconsistent : : - csky: Use true/false as boolean litterals : : - imx-irqsteer: Add runtime PM support : : - armada-370-xp: Enable CPU affinity for MSIs, avoid messing with : PMU interrupts on some variants : : - aspeed: Fix handling of irq_of_parse_and_map() errors : : - sun6i: Fix sparse warnings : : - xtensa-mx: Fix initial IRQ affinity in non-SMP setup : : - exiu: Fix acknowledgment of edge-triggered interrupts : : - sunxi: Generalise configuration for further reuse : . irqchip: Add Kconfig symbols for sunxi drivers irqchip/armada-370-xp: Do not touch Performance Counter Overflow on A375, A38x, A39x irqchip/gic: Improved warning about incorrect type irqchip/csky: Return true/false (not 1/0) from bool functions irqchip/imx-irqsteer: Add runtime PM support irqchip/imx-irqsteer: Constify irq_chip struct irqchip/armada-370-xp: Enable MSI affinity configuration irqchip/aspeed-scu-ic: Fix irq_of_parse_and_map() return value irqchip/aspeed-i2c-ic: Fix irq_of_parse_and_map() return value irqchip/sun6i-r: Use NULL for chip_data irqchip/xtensa-mx: Fix initial IRQ affinity in non-SMP setup irqchip/exiu: Fix acknowledgment of edge triggered interrupts Signed-off-by: Marc Zyngier <maz@kernel.org>
2022-05-17PM / devfreq: passive: Keep cpufreq_policy for possible cpusChanwoo Choi
The passive governor requires the cpu data to get the next target frequency of devfreq device if depending on cpu. In order to reduce the unnecessary memory data, keep cpufreq_policy data for possible cpus instead of NR_CPU. Tested-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Johnson Wang <johnson.wang@mediatek.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2022-05-17PM / devfreq: passive: Reduce duplicate code when passive_devfreq caseChanwoo Choi
In order to keep the consistent coding style between passive_devfreq and passive_cpufreq, use common code for handling required opp property. Also remove the unneed conditional statement and unify the comment of both passive_devfreq and passive_cpufreq when getting the target frequency. Tested-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Johnson Wang <johnson.wang@mediatek.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2022-05-17PM / devfreq: Add cpu based scaling support to passive governorSaravana Kannan
Many CPU architectures have caches that can scale independent of the CPUs. Frequency scaling of the caches is necessary to make sure that the cache is not a performance bottleneck that leads to poor performance and power. The same idea applies for RAM/DDR. To achieve this, this patch adds support for cpu based scaling to the passive governor. This is accomplished by taking the current frequency of each CPU frequency domain and then adjust the frequency of the cache (or any devfreq device) based on the frequency of the CPUs. It listens to CPU frequency transition notifiers to keep itself up to date on the current CPU frequency. To decide the frequency of the device, the governor does one of the following: * Derives the optimal devfreq device opp from required-opps property of the parent cpu opp_table. * Scales the device frequency in proportion to the CPU frequency. So, if the CPUs are running at their max frequency, the device runs at its max frequency. If the CPUs are running at their min frequency, the device runs at its min frequency. It is interpolated for frequencies in between. Tested-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Johnson Wang <johnson.wang@mediatek.com> Signed-off-by: Saravana Kannan <skannan@codeaurora.org> [Sibi: Integrated cpu-freqmap governor into passive_governor] Signed-off-by: Sibi Sankar <sibis@codeaurora.org> [Chanwoo: Fix conflict with latest code and cleanup code] Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2022-05-17PM / devfreq: Export devfreq_get_freq_range symbol within devfreqChanwoo Choi
In order to get frequency range within devfreq governors, export devfreq_get_freq_range symbol within devfreq. Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Johnson Wang <johnson.wang@mediatek.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2022-05-17net/mlxbf_gige: use eth_zero_addr() to clear mac addressLu Wei
Use eth_zero_addr() to clear mac address instead of memset(). Signed-off-by: Lu Wei <luwei32@huawei.com> Link: https://lore.kernel.org/r/20220516033343.329178-1-luwei32@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-05-17ethernet/ti: delete if NULL check befort devm_kfreeBernard Zhao
devm_kfree check the pointer, there is no need to check before devm_kfree call. This change is to cleanup the code a bit. Signed-off-by: Bernard Zhao <bernard@vivo.com> Link: https://lore.kernel.org/r/20220516015208.6526-1-bernard@vivo.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-05-17irqchip: Add Kconfig symbols for sunxi driversSamuel Holland
Not all of these drivers are needed on every ARCH_SUNXI platform. In particular, the ARCH_SUNXI symbol will be reused for the Allwinner D1, a RISC-V SoC which contains none of these irqchips. Introduce Kconfig symbols so we can select only the drivers actually used by a particular set of platforms. This also lets us move the irqchip driver dependencies to a more appropriate location. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220509034941.30704-1-samuel@sholland.org
generated by cgit (git 2.34.1) at 2025-09-15 09:24:02 +0000