summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-08-04riscv/kexec: load initrd high in available memoryTorsten Duwe
When initrd is loaded low, the secondary kernel fails like this: INITRD: 0xdc581000+0x00eef000 overlaps in-use memory region This initrd load address corresponds to the _end symbol, but the reservation is aligned on PMD_SIZE, as explained by a comment in setup_bootmem(). It is technically possible to align the initrd load address accordingly, leaving a hole between the end of kernel and the initrd, but it is much simpler to allocate the initrd top-down. Fixes: 838b3e28488f ("RISC-V: Load purgatory in kexec_file") Signed-off-by: Torsten Duwe <duwe@suse.de> Signed-off-by: Petr Tesarik <petr.tesarik.ext@huawei.com> Cc: stable@vger.kernel.org Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/all/67c8eb9eea25717c2c8208d9bfbfaa39e6e2a1c6.1690365011.git.petr.tesarik.ext@huawei.com/ Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-04riscv/kexec: handle R_RISCV_CALL_PLT relocation typeTorsten Duwe
R_RISCV_CALL has been deprecated and replaced by R_RISCV_CALL_PLT. See Enum 18-19 in Table 3. Relocation types here: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc It was deprecated in ("Deprecated R_RISCV_CALL, prefer R_RISCV_CALL_PLT"): https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/a0dced85018d7a0ec17023c9389cbd70b1dbc1b0 Recent tools (at least GNU binutils-2.40) already use R_RISCV_CALL_PLT. Kernels built with such binutils fail kexec_load_file(2) with: kexec_image: Unknown rela relocation: 19 kexec_image: Error loading purgatory ret=-8 The binary code at the call site remains the same, so tell arch_kexec_apply_relocations_add() to handle _PLT alike. Fixes: 838b3e28488f ("RISC-V: Load purgatory in kexec_file") Signed-off-by: Torsten Duwe <duwe@suse.de> Signed-off-by: Petr Tesarik <petr.tesarik.ext@huawei.com> Cc: Li Zhengyu <lizhengyu3@huawei.com> Cc: stable@vger.kernel.org Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/all/b046b164af8efd33bbdb7d4003273bdf9196a5b0.1690365011.git.petr.tesarik.ext@huawei.com/ Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-04arm64/fpsimd: Sync and zero pad FPSIMD state for streaming SVEMark Brown
We have a function sve_sync_from_fpsimd_zeropad() which is used by the ptrace code to update the SVE state when the user writes to the the FPSIMD register set. Currently this checks that the task has SVE enabled but this will miss updates for tasks which have streaming SVE enabled if SVE has not been enabled for the thread, also do the conversion if the task has streaming SVE enabled. Fixes: e12310a0d30f ("arm64/sme: Implement ptrace support for streaming mode SVE registers") Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230803-arm64-fix-ptrace-ssve-no-sve-v1-3-49df214bfb3e@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2023-08-04arm64/fpsimd: Sync FPSIMD state with SVE for SME only systemsMark Brown
Currently we guard FPSIMD/SVE state conversions with a check for the system supporting SVE but SME only systems may need to sync streaming mode SVE state so add a check for SME support too. These functions are only used by the ptrace code. Fixes: e12310a0d30f ("arm64/sme: Implement ptrace support for streaming mode SVE registers") Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230803-arm64-fix-ptrace-ssve-no-sve-v1-2-49df214bfb3e@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2023-08-04arm64/ptrace: Don't enable SVE when setting streaming SVEMark Brown
Systems which implement SME without also implementing SVE are architecturally valid but were not initially supported by the kernel, unfortunately we missed one issue in the ptrace code. The SVE register setting code is shared between SVE and streaming mode SVE. When we set full SVE register state we currently enable TIF_SVE unconditionally, in the case where streaming SVE is being configured on a system that supports vanilla SVE this is not an issue since we always initialise enough state for both vector lengths but on a system which only support SME it will result in us attempting to restore the SVE vector length after having set streaming SVE registers. Fix this by making the enabling of SVE conditional on setting SVE vector state. If we set streaming SVE state and SVE was not already enabled this will result in a SVE access trap on next use of normal SVE, this will cause us to flush our register state but this is fine since the only way to trigger a SVE access trap would be to exit streaming mode which will cause the in register state to be flushed anyway. Fixes: e12310a0d30f ("arm64/sme: Implement ptrace support for streaming mode SVE registers") Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230803-arm64-fix-ptrace-ssve-no-sve-v1-1-49df214bfb3e@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2023-08-04rust: fix bindgen build error with UBSAN_BOUNDS_STRICTAndrea Righi
With commit 2d47c6956ab3 ("ubsan: Tighten UBSAN_BOUNDS on GCC") if CONFIG_UBSAN is enabled and gcc supports -fsanitize=bounds-strict, we can trigger the following build error due to bindgen lacking support for this additional build option: BINDGEN rust/bindings/bindings_generated.rs error: unsupported argument 'bounds-strict' to option '-fsanitize=' Fix by adding -fsanitize=bounds-strict to the list of skipped gcc flags for bindgen. Fixes: 2d47c6956ab3 ("ubsan: Tighten UBSAN_BOUNDS on GCC") Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Kees Cook <keescook@chromium.org> Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Link: https://lore.kernel.org/r/20230711071914.133946-1-andrea.righi@canonical.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2023-08-04rust: delete `ForeignOwnable::borrow_mut`Alice Ryhl
We discovered that the current design of `borrow_mut` is problematic. This patch removes it until a better solution can be found. Specifically, the current design gives you access to a `&mut T`, which lets you change where the `ForeignOwnable` points (e.g., with `core::mem::swap`). No upcoming user of this API intended to make that possible, making all of them unsound. Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Fixes: 0fc4424d24a2 ("rust: types: introduce `ForeignOwnable`") Link: https://lore.kernel.org/r/20230706094615.3080784-1-aliceryhl@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2023-08-04rust: allocator: Prevent mis-aligned allocationBoqun Feng
Currently the rust allocator simply passes the size of the type Layout to krealloc(), and in theory the alignment requirement from the type Layout may be larger than the guarantee provided by SLAB, which means the allocated object is mis-aligned. Fix this by adjusting the allocation size to the nearest power of two, which SLAB always guarantees a size-aligned allocation. And because Rust guarantees that the original size must be a multiple of alignment and the alignment must be a power of two, then the alignment requirement is satisfied. Suggested-by: Vlastimil Babka <vbabka@suse.cz> Co-developed-by: "Andreas Hindborg (Samsung)" <nmi@metaspace.dk> Signed-off-by: "Andreas Hindborg (Samsung)" <nmi@metaspace.dk> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Cc: stable@vger.kernel.org # v6.1+ Acked-by: Vlastimil Babka <vbabka@suse.cz> Fixes: 247b365dc8dc ("rust: add `kernel` crate") Link: https://github.com/Rust-for-Linux/linux/issues/974 Link: https://lore.kernel.org/r/20230730012905.643822-2-boqun.feng@gmail.com [ Applied rewording of comment as discussed in the mailing list. ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2023-08-04firmware: stratix10-rsu: query spt addressesRadu Bacrau
Extend Intel Remote System Update (RSU) driver to get SPT (Sub-Partition Table) addresses. The query SPT address can be used to determine if the RSU QSPI layout is 32kB or 64kB aligned. The alignment can be determined by minus the upper with the lower of the SPT addresses. This patch depends on patch: firmware: stratix10-svc: Generic Mailbox Command Signed-off-by: Radu Bacrau <radu.bacrau@intel.com> Signed-off-by: Kah Jing Lee <kah.jing.lee@intel.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org> Link: https://lore.kernel.org/r/20230727192907.982070-2-dinguyen@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04firmware: stratix10-svc: Generic Mailbox CommandTeh Wen Ping
Add generic mailbox command that can support SDM command. User can use this command to send SDM mailbox command. User have to specified an input file which contain the command data and an output file for SDM response to be copied over. Signed-off-by: Teh Wen Ping <wen.ping.teh@intel.com> Signed-off-by: Kah Jing Lee <kah.jing.lee@intel.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org> Link: https://lore.kernel.org/r/20230727192907.982070-1-dinguyen@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04firmware: coreboot: framebuffer: Allow building with simpledrmAlper Nebi Yasak
The coreboot framebuffer driver registers a "simple-framebuffer" device based on the information from the firmware, after checking that it's compatible with the formats listed in simplefb.h. It was added before simpledrm, and its Kconfig marked as dependent on the simplefb driver. The simpledrm driver can also handle "simple-framebuffer" devices and the coreboot framebuffer works fine with it on a 'Lick' Chromebook. Allow building the coreboot framebuffer driver with simpledrm as well. Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Link: https://lore.kernel.org/r/20230725174334.887485-1-alpernebiyasak@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04peci: Constify struct peci_controller_opsZev Weiss
As with most ops structs, we never modify it at runtime, and keeping function pointers in read-only memory is generally a good thing security-wise. Signed-off-by: Zev Weiss <zev@bewilderbeest.net> Link: https://lore.kernel.org/r/20230327224315.11135-1-zev@bewilderbeest.net Reviewed-by: Iwona Winiarska <iwona.winiarska@intel.com> Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com> Link: https://lore.kernel.org/r/20230623142805.577612-1-iwona.winiarska@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04cdx: Explicitly include correct DT includesRob Herring
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Nipun Gupta <nipun.gupta@amd.com> Link: https://lore.kernel.org/r/20230717150355.1749845-1-robh@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04uio: pruss: fix to check return value of platform_get_irq() in pruss_probe()Zhang Shurong
The platform_get_irq might be failed and return a negative result. So there should have an error handling code. Fixed this by adding an error handling code. Signed-off-by: Zhang Shurong <zhang_shurong@foxmail.com> Link: https://lore.kernel.org/r/tencent_8E383752B54E5BF860711E500AD8A8971208@qq.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04dma-buf/sync_file: Fix docs syntaxRob Clark
Fixes the warning: include/uapi/linux/sync_file.h:77: warning: Function parameter or member 'num_fences' not described in 'sync_file_info' Fixes: 2d75c88fefb2 ("staging/android: refactor SYNC IOCTLs") Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20230724145000.125880-1-robdclark@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04misc: tps6594-esm: Disable ESM for rev 1 PMICEsteban Blanc
Due to a silicon bug, ESM on TPS6594 PMIC revision 1 is not working properly. This patch keeps SOC ESM disabled for such PMIC. Fixes: 875fdd0787e4 ("misc: tps6594-esm: Add driver for TI TPS6594 ESM") Co-developed-by: Julien Panis <jpanis@baylibre.com> Signed-off-by: Julien Panis <jpanis@baylibre.com> Signed-off-by: Esteban Blanc <eblanc@baylibre.com> Link: https://lore.kernel.org/r/20230726-tps6594_fix_esm_for_v1-v1-1-2adfdcad31c2@baylibre.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04misc: rtsx: judge ASPM Mode to set PETXCFG RegRicky WU
ASPM Mode is ASPM_MODE_CFG need to judge the value of clkreq_0 to set HIGH or LOW, if the ASPM Mode is ASPM_MODE_REG always set to HIGH during the initialization. Cc: stable@vger.kernel.org Signed-off-by: Ricky Wu <ricky_wu@realtek.com> Link: https://lore.kernel.org/r/52906c6836374c8cb068225954c5543a@realtek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04misc: bcm_vk: Fix potential deadlock on &vk->ctx_lockChengfeng Ye
As &vk->ctx_lock is acquired by timer bcm_vk_hb_poll() under softirq context, other process context code should disable irq or bottom-half before acquire the same lock, otherwise deadlock could happen if the timer preempt the execution while the lock is held in process context on the same CPU. Possible deadlock scenario bcm_vk_open() -> bcm_vk_get_ctx() -> spin_lock(&vk->ctx_lock) <timer iterrupt> -> bcm_vk_hb_poll() -> bcm_vk_blk_drv_access() -> spin_lock_irqsave(&vk->ctx_lock, flags) (deadlock here) This flaw was found using an experimental static analysis tool we are developing for irq-related deadlock, which reported the following warning when analyzing the linux kernel 6.4-rc7 release. [Deadlock]: &vk->ctx_lock [Interrupt]: bcm_vk_hb_poll -->/root/linux/drivers/misc/bcm-vk/bcm_vk_msg.c:176 -->/root/linux/drivers/misc/bcm-vk/bcm_vk_dev.c:512 [Locking Unit]: bcm_vk_ioctl -->/root/linux/drivers/misc/bcm-vk/bcm_vk_dev.c:1181 -->/root/linux/drivers/misc/bcm-vk/bcm_vk_dev.c:512 [Deadlock]: &vk->ctx_lock [Interrupt]: bcm_vk_hb_poll -->/root/linux/drivers/misc/bcm-vk/bcm_vk_msg.c:176 -->/root/linux/drivers/misc/bcm-vk/bcm_vk_dev.c:512 [Locking Unit]: bcm_vk_ioctl -->/root/linux/drivers/misc/bcm-vk/bcm_vk_dev.c:1169 [Deadlock]: &vk->ctx_lock [Interrupt]: bcm_vk_hb_poll -->/root/linux/drivers/misc/bcm-vk/bcm_vk_msg.c:176 -->/root/linux/drivers/misc/bcm-vk/bcm_vk_dev.c:512 [Locking Unit]: bcm_vk_open -->/root/linux/drivers/misc/bcm-vk/bcm_vk_msg.c:216 [Deadlock]: &vk->ctx_lock [Interrupt]: bcm_vk_hb_poll -->/root/linux/drivers/misc/bcm-vk/bcm_vk_msg.c:176 -->/root/linux/drivers/misc/bcm-vk/bcm_vk_dev.c:512 [Locking Unit]: bcm_vk_release -->/root/linux/drivers/misc/bcm-vk/bcm_vk_msg.c:306 As suggested by Arnd, the tentative patch fix the potential deadlocks by replacing the timer with delay workqueue. x86_64 allyesconfig using GCC shows no new warning. Note that no runtime testing was performed due to no device on hand. Signed-off-by: Chengfeng Ye <dg573847474@gmail.com> Acked-by: Scott Branden <scott.branden@broadcom.com> Tested-by: Desmond Yan <desmond.branden@broadcom.com> Tested-by: Desmond Yan <desmond.yan@broadcom.com> Link: https://lore.kernel.org/r/20230629182941.13045-1-dg573847474@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04pcmcia : make PCMCIA depend on HAS_IOMEMBaoquan He
On s390 systems (aka mainframes), it has classic channel devices for networking and permanent storage that are currently even more common than PCI devices. Hence it could have a fully functional s390 kernel with CONFIG_PCI=n, then the relevant iomem mapping functions [including ioremap(), devm_ioremap(), etc.] are not available. Here let depend PCMCIA on HAS_IOMEM so that it won't be built to cause below compiling error if PCI is unset. ------ ld: drivers/pcmcia/cistpl.o: in function `set_cis_map': cistpl.c:(.text+0x1202): undefined reference to `ioremap' ld: cistpl.c:(.text+0x13b0): undefined reference to `iounmap' ld: cistpl.c:(.text+0x14a6): undefined reference to `iounmap' ld: cistpl.c:(.text+0x1544): undefined reference to `ioremap' ld: drivers/pcmcia/cistpl.o: in function `release_cis_mem': cistpl.c:(.text+0x3f14): undefined reference to `iounmap' ------ Besides, many other Kconfig option, e.g IPWIRELESS, PCMCIA_PCNET, PCMCIA_FMVJ18X, PCMCIA_SMC91C92 which depends on PCMCIA also will cause compiling error if enabled. ------ ERROR: modpost: "iounmap" [drivers/tty/ipwireless/ipwireless.ko] undefined! ERROR: modpost: "ioremap" [drivers/tty/ipwireless/ipwireless.ko] undefined! ERROR: modpost: "iounmap" [drivers/net/ethernet/8390/pcnet_cs.ko] undefined! ERROR: modpost: "ioremap" [drivers/net/ethernet/8390/pcnet_cs.ko] undefined! ERROR: modpost: "iounmap" [drivers/net/ethernet/fujitsu/fmvj18x_cs.ko] undefined! ERROR: modpost: "ioremap" [drivers/net/ethernet/fujitsu/fmvj18x_cs.ko] undefined! ERROR: modpost: "iounmap" [drivers/net/ethernet/smsc/smc91c92_cs.ko] undefined! ERROR: modpost: "ioremap" [drivers/net/ethernet/smsc/smc91c92_cs.ko] undefined! ERROR: modpost: "iounmap" [drivers/net/ethernet/xircom/xirc2ps_cs.ko] undefined! ERROR: modpost: "ioremap" [drivers/net/ethernet/xircom/xirc2ps_cs.ko] undefined! ERROR: modpost: "devm_ioremap" [drivers/net/ethernet/altera/altera_tse.ko] undefined! ERROR: modpost: "iounmap" [drivers/net/arcnet/com90xx.ko] undefined! ------ Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202306211329.ticOJCSv-lkp@intel.com/ Signed-off-by: Baoquan He <bhe@redhat.com> Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Link: https://lore.kernel.org/r/20230707135852.24292-5-bhe@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04misc: open-dice: make OPEN_DICE depend on HAS_IOMEMBaoquan He
On s390 systems (aka mainframes), it has classic channel devices for networking and permanent storage that are currently even more common than PCI devices. Hence it could have a fully functional s390 kernel with CONFIG_PCI=n, then the relevant iomem mapping functions [including ioremap(), devm_ioremap(), etc.] are not available. Here let OPEN_DICE depend on HAS_IOMEM so that it won't be built to cause below compiling error if PCI is unset: ------ ERROR: modpost: "devm_memremap" [drivers/misc/open-dice.ko] undefined! ERROR: modpost: "devm_memunmap" [drivers/misc/open-dice.ko] undefined! ------ Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202306211329.ticOJCSv-lkp@intel.com/ Signed-off-by: Baoquan He <bhe@redhat.com> Cc: Derek Kiernan <derek.kiernan@amd.com> Cc: Dragan Cvetic <dragan.cvetic@amd.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20230707135852.24292-4-bhe@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04char: xillybus: make XILLYBUS_OF depend on HAS_IOMEMBaoquan He
On s390 systems (aka mainframes), it has classic channel devices for networking and permanent storage that are currently even more common than PCI devices. Hence it could have a fully functional s390 kernel with CONFIG_PCI=n, then the relevant iomem mapping functions [including ioremap(), devm_ioremap(), etc.] are not available. Here let XILLYBUS_OF depend on HAS_IOMEM so that it won't be built to cause below compiling error if PCI is unset: ------ ERROR: modpost: "devm_platform_ioremap_resource" [drivers/char/xillybus/xillybus_of.ko] undefined! ------ Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202306211329.ticOJCSv-lkp@intel.com/ Signed-off-by: Baoquan He <bhe@redhat.com> Acked-by: Eli Billauer <eli.billauer@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20230707135852.24292-3-bhe@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04misc: hi6421-spmi-pmic: Remove redundant dev_err()Ruan Jinjie
There is no need to call the dev_err() function directly to print a custom message when handling an error from the platform_get_irq() function as it is going to display an appropriate error message in case of a failure. Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com> Link: https://lore.kernel.org/r/20230726180707.2486808-1-ruanjinjie@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04misc: Explicitly include correct DT includesRob Herring
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Acked-by: Andrew Donnellan <ajd@linux.ibm.com> # cxl Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230718143102.1065481-1-robh@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04misc: tps6594-esm: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). There are two calls that can go wrong in tps6594_esm_remove(); for both there is already an error message. Not returning the error code has the only side effect of suppressing (another) error message by the core about the error being ignored. So tps6594_esm_remove() can be converted to return void without any loss. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230710082311.3474785-1-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04misc: tps6594-pfsm: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230707073343.3396477-1-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04misc: xilinx_tmr_manager: Use devm_platform_get_and_ioremap_resource()Yangtao Li
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by: Yangtao Li <frank.li@vivo.com> Reviewed-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/20230707024224.78907-3-frank.li@vivo.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04misc/xilinx_sdfec: Convert to devm_platform_ioremap_resource()Yangtao Li
Use devm_platform_ioremap_resource() to simplify code. Signed-off-by: Yangtao Li <frank.li@vivo.com> Reviewed-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/20230707024224.78907-2-frank.li@vivo.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04misc: atmel-ssc: Use devm_platform_get_and_ioremap_resource()Yangtao Li
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by: Yangtao Li <frank.li@vivo.com> Link: https://lore.kernel.org/r/20230707024224.78907-1-frank.li@vivo.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04misc: microchip: pci1xxxx: Add support to read and write into PCI1XXXX ↵Kumaravel Thiagarajan
EEPROM via NVMEM sysfs Microchip's pci1xxxx is an unmanaged PCIe3.1a switch for consumer, industrial, and automotive applications. This switch integrates OTP and EEPROM to enable customization of the part in the field. This patch adds support to read and write into PCI1XXXX EEPROM via NVMEM sysfs. Signed-off-by: Kumaravel Thiagarajan <kumaravel.thiagarajan@microchip.com> Co-developed-by: Tharun Kumar P <tharunkumar.pasumarthi@microchip.com> Signed-off-by: Tharun Kumar P <tharunkumar.pasumarthi@microchip.com> Co-developed-by: Vaibhaav Ram T.L <vaibhaavram.tl@microchip.com> Signed-off-by: Vaibhaav Ram T.L <vaibhaavram.tl@microchip.com> Link: https://lore.kernel.org/r/20230620143520.858-3-vaibhaavram.tl@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04misc: microchip: pci1xxxx: Add support to read and write into PCI1XXXX OTP ↵Kumaravel Thiagarajan
via NVMEM sysfs Microchip's pci1xxxx is an unmanaged PCIe3.1a switch for consumer, industrial, and automotive applications. This switch integrates OTP and EEPROM to enable customization of the part in the field. This patch adds support to read and write into PCI1XXXX OTP via NVMEM sysfs. Signed-off-by: Kumaravel Thiagarajan <kumaravel.thiagarajan@microchip.com> Co-developed-by: Tharun Kumar P <tharunkumar.pasumarthi@microchip.com> Signed-off-by: Tharun Kumar P <tharunkumar.pasumarthi@microchip.com> Co-developed-by: Vaibhaav Ram T.L <vaibhaavram.tl@microchip.com> Signed-off-by: Vaibhaav Ram T.L <vaibhaavram.tl@microchip.com> Link: https://lore.kernel.org/r/20230620143520.858-2-vaibhaavram.tl@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04dyndbg: add source filename to prefixThomas Weißschuh
Printing the line number without the file is of limited usefulness. Knowing the filename also makes it also easier to relate the logged information to the controlfile. Example: # modprobe test_dynamic_debug # echo 'file test_dynamic_debug.c =pfsl' > /proc/dynamic_debug/control # echo 1 > /sys/module/test_dynamic_debug/parameters/do_prints # dmesg | tail -2 [ 71.802212] do_cats:lib/test_dynamic_debug.c:103: test_dd: doing categories [ 71.802227] do_levels:lib/test_dynamic_debug.c:123: test_dd: doing levels Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Jim Cromie <jim.cromie@gmail.com> Acked-by: Jason Baron <jbaron@akamai.com> Reviewed-by: Luis Chamberlain <mcgrof@kernel.org> Link: https://lore.kernel.org/r/20230709-dyndbg-filename-v2-3-fd83beef0925@weissschuh.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04dyndbg: increase PREFIX_SIZE to 128Thomas Weißschuh
A follow-up patch will add the possibility to print the filename as part of the prefix. Increase the maximum prefix size to accommodate this. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Luis Chamberlain <mcgrof@kernel.org> Link: https://lore.kernel.org/r/20230709-dyndbg-filename-v2-2-fd83beef0925@weissschuh.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04dyndbg: constify opt_arrayThomas Weißschuh
It is never modified, so mark it const. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Luis Chamberlain <mcgrof@kernel.org> Link: https://lore.kernel.org/r/20230709-dyndbg-filename-v2-1-fd83beef0925@weissschuh.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04binderfs: Drop unused #include <linux/radix-tree.h>Uwe Kleine-König
binderfs.c doens't use any of the symbols provided by linux/radix-tree.h and compiles just fine without this include. So drop the #include. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Christian Brauner <brauner@kernel.org> Link: https://lore.kernel.org/r/20230728070931.589823-1-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04android: Remove error checking for debugfs_create_dir()Wang Ming
It is expected that most callers should _ignore_ the errors return by debugfs_create_dir() in binder_init(). Signed-off-by: Wang Ming <machel@vivo.com> Link: https://lore.kernel.org/r/20230713080649.1893-1-machel@vivo.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04binder: fix memory leak in binder_init()Qi Zheng
In binder_init(), the destruction of binder_alloc_shrinker_init() is not performed in the wrong path, which will cause memory leaks. So this commit introduces binder_alloc_shrinker_exit() and calls it in the wrong path to fix that. Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com> Acked-by: Carlos Llamas <cmllamas@google.com> Fixes: f2517eb76f1f ("android: binder: Add global lru shrinker to binder") Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/20230625154937.64316-1-qi.zheng@linux.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04Merge tag 'iio-fixes-for-6.5a' of ↵Greg Kroah-Hartman
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-linus Jonathan writes: 1st set of IIO fixes for 6.5 Usual mixed bag of fixes for recently introduced issues and ones from way back that have recently been noticed. * core - Avoid a device with no parent issues seen on the dummy example device. * adi,ad71145 - Drop ref now that dt-schema supports -nanoamp. * adi,ad7192 - Fix wrong bit set for enabling AC excitation and exposure of control on devices without the feature. * adi,admv1013 - Don't ignore errors from regulator_get_voltage(). * amlogic,meson-adc - Make sure clocks enabled early enough. * google,cros_ec - Fix undersized cros_ec_command allocation that resulted in a buffer overrun. * rohm,bu27008 - Fix truncation issue with scale format that prevents smallest value being set - Report intensity as unsigned. Previously large values would be interpretted as negative intensities (and odd concept). * rohm,bu27034 - Fix truncation issue with scale format that prevents smallest value being set. * st,lsm6dsx - Return an error code, not false (which is 0 and hence success) to indicate ACPI mount matrix retrieval failed due to no ACPI support. * ti,ina2xx - Avoid a NULL pointer dereference if fall back compatible is used. * tag 'iio-fixes-for-6.5a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: iio: cros_ec: Fix the allocation size for cros_ec_command iio: imu: lsm6dsx: Fix mount matrix retrieval iio: adc: meson: fix core clock enable/disable moment iio: core: Prevent invalid memory access when there is no parent iio: frequency: admv1013: propagate errors from regulator_get_voltage() dt-bindings: iio: adi,ad74115: remove ref from -nanoamp iio: adc: ina2xx: avoid NULL pointer dereference on OF device match iio: light: bu27008: Fix intensity data type iio: light: bu27008: Fix scale format iio: light: bu27034: Fix scale format iio: adc: ad7192: Fix ac excitation feature
2023-08-04Merge tag 'counter-fixes-for-6.5b' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/wbg/counter into char-misc-linus William writes: Second set of Counter fixes for 6.5 The I8254 Kconfig entry is repositioned to resolve a misplacement causing the "Counter support" submenu items to disappear in menuconfig. The tools/counter/Makefile clean recipe is adjusted to replace rmdir with an equivalent set of rm to prevent failure if someone tries to clean the counter directory without building it first. * tag 'counter-fixes-for-6.5b' of git://git.kernel.org/pub/scm/linux/kernel/git/wbg/counter: tools/counter: Makefile: Replace rmdir by rm to avoid make,clean failure counter: Fix menuconfig "Counter support" submenu entries disappearance
2023-08-04thunderbolt: Fix memory leak in tb_handle_dp_bandwidth_request()Mika Westerberg
The memory allocated in tb_queue_dp_bandwidth_request() needs to be released once the request is handled to avoid leaking it. Fixes: 6ce3563520be ("thunderbolt: Add support for DisplayPort bandwidth allocation mode") Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-08-04coresight: dummy: simplify the code with module_platform_driverYang Yingliang
The init/exit() of driver only calls platform_driver_register/unregister, it can be simpilfied with module_platform_driver. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20230804092709.1359264-1-yangyingliang@huawei.com
2023-08-04Merge tag 'counter-fixes-for-6.5a' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/wbg/counter into char-misc-linus William writes: First set of Counter fixes for 6.5 In commit d428487471ba ("counter: i8254: Introduce the Intel 8254 interface library module"), the misplacement of the I8254 Kconfig entry results in the "Counter support" submenu items disappearing in menuconfig. A fix is provided to reposition the I8254 Kconfig entry to restore the intended submenu behavior. * tag 'counter-fixes-for-6.5a' of git://git.kernel.org/pub/scm/linux/kernel/git/wbg/counter: counter: Fix menuconfig "Counter support" submenu entries disappearance
2023-08-04usb: dwc3: Properly handle processing of pending eventsElson Roy Serrao
If dwc3 is runtime suspended we defer processing the event buffer until resume, by setting the pending_events flag. Set this flag before triggering resume to avoid race with the runtime resume callback. While handling the pending events, in addition to checking the event buffer we also need to process it. Handle this by explicitly calling dwc3_thread_interrupt(). Also balance the runtime pm get() operation that triggered this processing. Cc: stable@vger.kernel.org Fixes: fc8bb91bc83e ("usb: dwc3: implement runtime PM") Signed-off-by: Elson Roy Serrao <quic_eserrao@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Roger Quadros <rogerq@kernel.org> Link: https://lore.kernel.org/r/20230801192658.19275-1-quic_eserrao@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04usb-storage: alauda: Fix uninit-value in alauda_check_media()Alan Stern
Syzbot got KMSAN to complain about access to an uninitialized value in the alauda subdriver of usb-storage: BUG: KMSAN: uninit-value in alauda_transport+0x462/0x57f0 drivers/usb/storage/alauda.c:1137 CPU: 0 PID: 12279 Comm: usb-storage Not tainted 5.3.0-rc7+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x191/0x1f0 lib/dump_stack.c:113 kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108 __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250 alauda_check_media+0x344/0x3310 drivers/usb/storage/alauda.c:460 The problem is that alauda_check_media() doesn't verify that its USB transfer succeeded before trying to use the received data. What should happen if the transfer fails isn't entirely clear, but a reasonably conservative approach is to pretend that no media is present. A similar problem exists in a usb_stor_dbg() call in alauda_get_media_status(). In this case, when an error occurs the call is redundant, because usb_stor_ctrl_transfer() already will print a debugging message. Finally, unrelated to the uninitialized memory access, is the fact that alauda_check_media() performs DMA to a buffer on the stack. Fortunately usb-storage provides a general purpose DMA-able buffer for uses like this. We'll use it instead. Reported-and-tested-by: syzbot+e7d46eb426883fb97efd@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/0000000000007d25ff059457342d@google.com/T/ Suggested-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Fixes: e80b0fade09e ("[PATCH] USB Storage: add alauda support") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/693d5d5e-f09b-42d0-8ed9-1f96cd30bcce@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04usb: common: usb-conn-gpio: Prevent bailing out if initial role is nonePrashanth K
Currently if we bootup a device without cable connected, then usb-conn-gpio won't call set_role() because last_role is same as current role. This happens since last_role gets initialised to zero during the probe. To avoid this, add a new flag initial_detection into struct usb_conn_info, which prevents bailing out during initial detection. Cc: <stable@vger.kernel.org> # 5.4 Fixes: 4602f3bff266 ("usb: common: add USB GPIO based connection detection driver") Signed-off-by: Prashanth K <quic_prashk@quicinc.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/1690880632-12588-1-git-send-email-quic_prashk@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04USB: Gadget: core: Help prevent panic during UVC unconfigureAlan Stern
Avichal Rakesh reported a kernel panic that occurred when the UVC gadget driver was removed from a gadget's configuration. The panic involves a somewhat complicated interaction between the kernel driver and a userspace component (as described in the Link tag below), but the analysis did make one thing clear: The Gadget core should accomodate gadget drivers calling usb_gadget_deactivate() as part of their unbind procedure. Currently this doesn't work. gadget_unbind_driver() calls driver->unbind() while holding the udc->connect_lock mutex, and usb_gadget_deactivate() attempts to acquire that mutex, which will result in a deadlock. The simple fix is for gadget_unbind_driver() to release the mutex when invoking the ->unbind() callback. There is no particular reason for it to be holding the mutex at that time, and the mutex isn't held while the ->bind() callback is invoked. So we'll drop the mutex before performing the unbind callback and reacquire it afterward. We'll also add a couple of comments to usb_gadget_activate() and usb_gadget_deactivate(). Because they run in process context they must not be called from a gadget driver's ->disconnect() callback, which (according to the kerneldoc for struct usb_gadget_driver in include/linux/usb/gadget.h) may run in interrupt context. This may help prevent similar bugs from arising in the future. Reported-and-tested-by: Avichal Rakesh <arakesh@google.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Fixes: 286d9975a838 ("usb: gadget: udc: core: Prevent soft_connect_store() race") Link: https://lore.kernel.org/linux-usb/4d7aa3f4-22d9-9f5a-3d70-1bd7148ff4ba@google.com/ Cc: Badhri Jagan Sridharan <badhri@google.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/48b2f1f1-0639-46bf-bbfc-98cb05a24914@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04usb: typec: mux: intel: Add dependency on USB_COMMONHeikki Krogerus
This fixes an undefined reference to `usb_debug_root' issue when USB_COMMON is not enabled. Fixes: 0a453dc9f260 ("usb: typec: intel_pmc_mux: Expose IOM port status to debugfs") Reported-by: Randy Dunlap <rdunlap@infradead.org> Closes: https://lore.kernel.org/lkml/c3bb8781-676d-2448-cfbb-62e29f1f570b@infradead.org/ Cc: Rajat Khandelwal <rajat.khandelwal@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20230731131210.43158-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04usb: typec: nb7vpq904m: Add an error handling path in nb7vpq904m_probe()Christophe JAILLET
In case of error in the nb7vpq904m_probe() probe function, some resources need to be freed, as already done in the remove function. Add the missing error handling path and adjust code accordingly. Fixes: 88d8f3ac9c67 ("usb: typec: add support for the nb7vpq904m Type-C Linear Redriver") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/9118954765821ea9f1179883602b4eca63e91749.1689716381.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04usb: typec: altmodes/displayport: Signal hpd when configuring pin assignmentRD Babiera
When connecting to some DisplayPort partners, the initial status update after entering DisplayPort Alt Mode notifies that the DFP_D/UFP_D is not in the connected state. This leads to sending a configure message that keeps the device in USB mode. The port partner then sets DFP_D/UFP_D to the connected state and HPD to high in the same Attention message. Currently, the HPD signal is dropped in order to handle configuration. This patch saves changes to the HPD signal when the device chooses to configure during dp_altmode_status_update, and invokes sysfs_notify if necessary for HPD after configuring. Fixes: 0e3bb7d6894d ("usb: typec: Add driver for DisplayPort alternate mode") Cc: stable@vger.kernel.org Signed-off-by: RD Babiera <rdbabiera@google.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20230726020903.1409072-1-rdbabiera@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04usb: typec: tcpm: Fix response to vsafe0V eventBadhri Jagan Sridharan
Do not transition to SNK_UNATTACHED state when receiving vsafe0v event while in SNK_HARD_RESET_WAIT_VBUS. Ignore VBUS off events as well as in some platforms VBUS off can be signalled more than once. [143515.364753] Requesting mux state 1, usb-role 2, orientation 2 [143515.365520] pending state change SNK_HARD_RESET_SINK_OFF -> SNK_HARD_RESET_SINK_ON @ 650 ms [rev3 HARD_RESET] [143515.632281] CC1: 0 -> 0, CC2: 3 -> 0 [state SNK_HARD_RESET_SINK_OFF, polarity 1, disconnected] [143515.637214] VBUS on [143515.664985] VBUS off [143515.664992] state change SNK_HARD_RESET_SINK_OFF -> SNK_HARD_RESET_WAIT_VBUS [rev3 HARD_RESET] [143515.665564] VBUS VSAFE0V [143515.665566] state change SNK_HARD_RESET_WAIT_VBUS -> SNK_UNATTACHED [rev3 HARD_RESET] Fixes: 28b43d3d746b ("usb: typec: tcpm: Introduce vsafe0v for vbus") Cc: <stable@vger.kernel.org> Signed-off-by: Badhri Jagan Sridharan <badhri@google.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20230712085722.1414743-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04interconnect: qcom: qcm2290: Enable sync stateKonrad Dybcio
Enable the generic .sync_state callback to ensure there are no outstanding votes that would waste power. Generally one would need a bunch of interface clocks to access the QoS registers when trying to go over all possible nodes during sync_state, but QCM2290 surprisingly does not seem to require any such handling. Fixes: 1a14b1ac3935 ("interconnect: qcom: Add QCM2290 driver support") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230720-topic-qcm2290_icc-v2-2-a2ceb9d3e713@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-29 22:29:45 +0000