- Nov 06, 2023
-
-
Naushir Patuck authored
This control is meant to be read-only, mark it as such. Signed-off-by:
Naushir Patuck <naush@raspberrypi.com>
-
Naushir Patuck authored
Add V4L2_CID_LINK_FREQ as a read-only control with a value of 450 Mhz. This will be used by the CFE driver to corretly setup the DPHY timing parameters in the CSI-2 block. Signed-off-by:
Naushir Patuck <naush@raspberrypi.com>
-
- Nov 03, 2023
-
-
Phil Elwell authored
Without the pinctrl-0 property in the overlays, the UARTs may not be mapped correctly. Signed-off-by:
Phil Elwell <phil@raspberrypi.com>
-
Dom Cobley authored
-
- Nov 02, 2023
-
-
Phil Elwell authored
spi6 won't be useful on Pi 5 because it can't be enabled on the 40-pin header, but include it for completeness. Also fix the #address-cells value for spi1, otherwise the kernel will reject attempts to apply the, say, spi1-2cs overlay at runtime. Signed-off-by:
Phil Elwell <phil@raspberrypi.com>
-
Phil Elwell authored
The kernel now treats multiple fragments targeting the same node as an error. For this reason, it is important that labels created just for compatibility with other systems (e.g. i2c0if and i2c0mux) are attached to unique nodes, not just tacked onto existing nodes. Signed-off-by:
Phil Elwell <phil@raspberrypi.com>
-
Naushir Patuck authored
Use the sensor provided link frequency to set the DPHY timing parameters on stream_on. This replaces the hard-coded 999 MHz value currently being used. As a fallback, revert to the original 999 Mhz link frequency. As a drive-by, fix a 80-character line formatting error. Signed-off-by:
Naushir Patuck <naush@raspberrypi.com>
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20231031165918.608547597@linuxfoundation.org Tested-by:
Pavel Machek (CIP) <pavel@denx.de> Tested-by:
Florian Fainelli <florian.fainelli@broadcom.com> Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Bagas Sanjaya <bagasdotme@gmail.com> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Ron Economos <re@w6rz.net> Tested-by:
Ricardo B. Marliere <ricardo@marliere.net> Tested-by:
Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Allen Pais <apais@linux.microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
John Sperbeck authored
When dbf46008 ("objtool/x86: Fixup frame-pointer vs rethunk") was backported to some stable branches, the check for dest->embedded_insn in is_special_call() was missed. The result is that the warning it was intended to suppress still appears. For example on 6.1 (on kernels before 6.1, the '-s' argument would instead be 'check'): $ tools/objtool/objtool -s arch/x86/lib/retpoline.o arch/x86/lib/retpoline.o: warning: objtool: srso_untrain_ret+0xd: call without frame pointer save/setup With this patch, the warning is correctly suppressed, and the kernel still passes the normal Google kernel developer tests. Signed-off-by:
John Sperbeck <jsperbeck@google.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Baokun Li authored
commit bedc5d34 upstream. Let's say we want to allocate 2 blocks starting from 4294966386, after predicting the file size, start is aligned to 4294965248, len is changed to 2048, then end = start + size = 0x100000000. Since end is of type ext4_lblk_t, i.e. uint, end is truncated to 0. This causes (pa->pa_lstart >= end) to always hold when checking if the current extent to be allocated crosses already preallocated blocks, so the resulting ac_g_ex may cross already preallocated blocks. Hence we convert the end type to loff_t and use pa_logical_end() to avoid overflow. Signed-off-by:
Baokun Li <libaokun1@huawei.com> Reviewed-by:
Ritesh Harjani (IBM) <ritesh.list@gmail.com> Link: https://lore.kernel.org/r/20230724121059.11834-4-libaokun1@huawei.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
Baokun Li <libaokun1@huawei.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Baokun Li authored
commit bc056e71 upstream. When we calculate the end position of ext4_free_extent, this position may be exactly where ext4_lblk_t (i.e. uint) overflows. For example, if ac_g_ex.fe_logical is 4294965248 and ac_orig_goal_len is 2048, then the computed end is 0x100000000, which is 0. If ac->ac_o_ex.fe_logical is not the first case of adjusting the best extent, that is, new_bex_end > 0, the following BUG_ON will be triggered: ========================================================= kernel BUG at fs/ext4/mballoc.c:5116! invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 3 PID: 673 Comm: xfs_io Tainted: G E 6.5.0-rc1+ #279 RIP: 0010:ext4_mb_new_inode_pa+0xc5/0x430 Call Trace: <TASK> ext4_mb_use_best_found+0x203/0x2f0 ext4_mb_try_best_found+0x163/0x240 ext4_mb_regular_allocator+0x158/0x1550 ext4_mb_new_blocks+0x86a/0xe10 ext4_ext_map_blocks+0xb0c/0x13a0 ext4_map_blocks+0x2cd/0x8f0 ext4_iomap_begin+0x27b/0x400 iomap_iter+0x222/0x3d0 __iomap_dio_rw+0x243/0xcb0 iomap_dio_rw+0x16/0x80 ========================================================= A simple reproducer demonstrating the problem: mkfs.ext4 -F /dev/sda -b 4096 100M mount /dev/sda /tmp/test fallocate -l1M /tmp/test/tmp fallocate -l10M /tmp/test/file fallocate -i -o 1M -l16777203M /tmp/test/file fsstress -d /tmp/test -l 0 -n 100000 -p 8 & sleep 10 && killall -9 fsstress rm -f /tmp/test/tmp xfs_io -c "open -ad /tmp/test/file" -c "pwrite -S 0xff 0 8192" We simply refactor the logic for adjusting the best extent by adding a temporary ext4_free_extent ex and use extent_logical_end() to avoid overflow, which also simplifies the code. Cc: stable@kernel.org # 6.4 Fixes: 93cdf49f ("ext4: Fix best extent lstart adjustment logic in ext4_mb_new_inode_pa()") Signed-off-by:
Baokun Li <libaokun1@huawei.com> Reviewed-by:
Ritesh Harjani (IBM) <ritesh.list@gmail.com> Link: https://lore.kernel.org/r/20230724121059.11834-3-libaokun1@huawei.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
Baokun Li <libaokun1@huawei.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Baokun Li authored
commit 43bbddc0 upstream. When we use lstart + len to calculate the end of free extent or prealloc space, it may exceed the maximum value of 4294967295(0xffffffff) supported by ext4_lblk_t and cause overflow, which may lead to various problems. Therefore, we add two helper functions, extent_logical_end() and pa_logical_end(), to limit the type of end to loff_t, and also convert lstart to loff_t for calculation to avoid overflow. Signed-off-by:
Baokun Li <libaokun1@huawei.com> Reviewed-by:
Ritesh Harjani (IBM) <ritesh.list@gmail.com> Link: https://lore.kernel.org/r/20230724121059.11834-2-libaokun1@huawei.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
Baokun Li <libaokun1@huawei.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
David Lazar authored
commit 3bde7ec1 upstream. When suspending to idle and resuming on some Lenovo laptops using the Mendocino APU, multiple NVME IOMMU page faults occur, showing up in dmesg as repeated errors: nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000b address=0xb6674000 flags=0x0000] The system is unstable afterwards. Applying the s2idle quirk introduced by commit 455cd867 ("platform/x86: thinkpad_acpi: Add a s2idle resume quirk for a number of laptops") allows these systems to work with the IOMMU enabled and s2idle resume to work. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218024 Suggested-by:
Mario Limonciello <mario.limonciello@amd.com> Suggested-by:
Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by:
David Lazar <dlazar@gmail.com> Reviewed-by:
Mario Limonciello <mario.limonciello@amd.com> Reviewed-by:
Mark Pearson <mpearson-lenovo@squebb.ca> Link: https://lore.kernel.org/r/ZTlsyOaFucF2pWrL@localhost Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alessandro Carminati authored
commit ceb87a36 upstream. In the possible_parent_show function, ensure proper handling of the return value from of_clk_get_parent_name to prevent potential issues arising from a NULL return. The current implementation invokes seq_puts directly on the result of of_clk_get_parent_name without verifying the return value, which can lead to kernel panic if the function returns NULL. This patch addresses the concern by introducing a check on the return value of of_clk_get_parent_name. If the return value is not NULL, the function proceeds to call seq_puts, providing the returned value as argument. However, if of_clk_get_parent_name returns NULL, the function provides a static string as argument, avoiding the panic. Fixes: 1ccc0ddf ("clk: Use seq_puts() in possible_parent_show()") Reported-by:
Philip Daly <pdaly@redhat.com> Signed-off-by:
Alessandro Carminati (Red Hat) <alessandro.carminati@gmail.com> Link: https://lore.kernel.org/r/20230921073217.572151-1-alessandro.carminati@gmail.com Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Al Viro authored
commit 1f36cd05 upstream. Fault handler used to make non-trivial calls, so it needed to set a stack frame up. Used to be save ... - grab a stack frame, old %o... become %i... .... ret - go back to address originally in %o7, currently %i7 restore - switch to previous stack frame, in delay slot Non-trivial calls had been gone since ab5e8b33 and that code should have become retl - go back to address in %o7 clr %o0 - have return value set to 0 What it had become instead was ret - go back to address in %i7 - return address of *caller* clr %o0 - have return value set to 0 which is not good, to put it mildly - we forcibly return 0 from csum_and_copy_{from,to}_iter() (which is what the call of that thing had been inlined into) and do that without dropping the stack frame of said csum_and_copy_..._iter(). Confuses the hell out of the caller of csum_and_copy_..._iter(), obviously... Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Fixes: ab5e8b33 "sparc32: propagate the calling conventions change down to __csum_partial_copy_sparc_generic()" Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Peter Zijlstra authored
commit a71ef314 upstream. Smatch is awesome. Fixes: 32671e37 ("perf: Disallow mis-matched inherited group reads") Reported-by:
Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tony Luck authored
commit b99d70c0 upstream. For "reasons" Intel has code-named this CPU with a "_H" suffix. [ dhansen: As usual, apply this and send it upstream quickly to make it easier for anyone who is doing work that consumes this. ] Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
Dave Hansen <dave.hansen@linux.intel.com> Link: https://lore.kernel.org/all/20231025202513.12358-1-tony.luck%40intel.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Thomas Gleixner authored
commit 128b0c97 upstream. David and a few others reported that on certain newer systems some legacy interrupts fail to work correctly. Debugging revealed that the BIOS of these systems leaves the legacy PIC in uninitialized state which makes the PIC detection fail and the kernel switches to a dummy implementation. Unfortunately this fallback causes quite some code to fail as it depends on checks for the number of legacy PIC interrupts or the availability of the real PIC. In theory there is no reason to use the PIC on any modern system when IO/APIC is available, but the dependencies on the related checks cannot be resolved trivially and on short notice. This needs lots of analysis and rework. The PIC detection has been added to avoid quirky checks and force selection of the dummy implementation all over the place, especially in VM guest scenarios. So it's not an option to revert the relevant commit as that would break a lot of other scenarios. One solution would be to try to initialize the PIC on detection fail and retry the detection, but that puts the burden on everything which does not have a PIC. Fortunately the ACPI/MADT table header has a flag field, which advertises in bit 0 that the system is PCAT compatible, which means it has a legacy 8259 PIC. Evaluate that bit and if set avoid the detection routine and keep the real PIC installed, which then gets initialized (for nothing) and makes the rest of the code with all the dependencies work again. Fixes: e179f691 ("x86, irq, pic: Probe for legacy PIC and set legacy_pic appropriately") Reported-by:
David Lazar <dlazar@gmail.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Tested-by:
David Lazar <dlazar@gmail.com> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Mario Limonciello <mario.limonciello@amd.com> Cc: stable@vger.kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218003 Link: https://lore.kernel.org/r/875y2u5s8g.ffs@tglx Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Peng Fan authored
commit 7d6e10f5 upstream. The nregs for i.MX6UL should be 144 per fuse map, correct it. Fixes: 4aa2b480 ("nvmem: octop: Add support for imx6ul") Cc: Stable@vger.kernel.org Signed-off-by:
Peng Fan <peng.fan@nxp.com> Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231013124904.175782-3-srinivas.kandagatla@linaro.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Peng Fan authored
commit 414a98ab upstream. The nregs for i.MX6SLL should be 80 per fuse map, correct it. Fixes: 6da27821 ("nvmem: imx-ocotp: add support for imx6sll") Cc: Stable@vger.kernel.org Signed-off-by:
Peng Fan <peng.fan@nxp.com> Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231013124904.175782-2-srinivas.kandagatla@linaro.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Peng Fan authored
commit 2382c1b0 upstream. The nregs for i.MX6ULL should be 80 per fuse map, correct it. Fixes: ffbc34bf ("nvmem: imx-ocotp: Implement i.MX6ULL/ULZ support") Cc: Stable@vger.kernel.org Signed-off-by:
Peng Fan <peng.fan@nxp.com> Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231013124904.175782-4-srinivas.kandagatla@linaro.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ekansh Gupta authored
commit 50914338 upstream. For unmapping any buffer from kernel, it should first be unmapped from DSP. In case unmap from DSP request fails, the map should not be removed from kernel as it might lead to SMMU faults and other memory issues. Fixes: 5c1b97c7 ("misc: fastrpc: add support for FASTRPC_IOCTL_MEM_MAP/UNMAP") Cc: stable <stable@kernel.org> Signed-off-by:
Ekansh Gupta <quic_ekangupt@quicinc.com> Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231013122007.174464-5-srinivas.kandagatla@linaro.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ekansh Gupta authored
commit 1c809359 upstream. With current design, buffers and dma handles are not freed in case of remote invocation failures returned from DSP. This could result in buffer leakings and dma handle pointing to wrong memory in the fastrpc kernel. Adding changes to clean buffers and dma handles even when remote invocation to DSP returns failures. Fixes: c68cfb71 ("misc: fastrpc: Add support for context Invoke method") Cc: stable <stable@kernel.org> Signed-off-by:
Ekansh Gupta <quic_ekangupt@quicinc.com> Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231013122007.174464-4-srinivas.kandagatla@linaro.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ekansh Gupta authored
commit 20648430 upstream. The FDs for DMA handles to be freed is updated in fdlist by DSP over a remote call. This holds true even for remote calls with no arguments. To handle this, get_args and put_args are needed to be called for remote calls with no arguments also as fdlist is allocated in get_args and FDs updated in fdlist is freed in put_args. Fixes: 8f6c1d8c ("misc: fastrpc: Add fdlist implementation") Cc: stable <stable@kernel.org> Signed-off-by:
Ekansh Gupta <quic_ekangupt@quicinc.com> Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231013122007.174464-3-srinivas.kandagatla@linaro.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ekansh Gupta authored
commit 1c29d801 upstream. Metadata buffer is allocated during get_args for any remote call. This buffer carries buffers, fdlists and other payload information for the call. If the buffer is not reset, put_args might find some garbage FDs in the fdlist which might have an existing mapping in the list. This could result in improper freeing of FD map when DSP might still be using the buffer. Added change to reset the metadata buffer after allocation. Fixes: 8f6c1d8c ("misc: fastrpc: Add fdlist implementation") Cc: stable <stable@kernel.org> Signed-off-by:
Ekansh Gupta <quic_ekangupt@quicinc.com> Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231013122007.174464-2-srinivas.kandagatla@linaro.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Yujie Liu authored
commit e0f83183 upstream. Fix the following kernel-doc warnings: kernel/trace/trace_kprobe.c:1029: warning: Excess function parameter 'args' description in '__kprobe_event_gen_cmd_start' kernel/trace/trace_kprobe.c:1097: warning: Excess function parameter 'args' description in '__kprobe_event_add_fields' Refer to the usage of variable length arguments elsewhere in the kernel code, "@..." is the proper way to express it in the description. Link: https://lore.kernel.org/all/20231027041315.2613166-1-yujie.liu@intel.com/ Fixes: 2a588dd1 ("tracing: Add kprobe event command generation functions") Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202310190437.paI6LYJF-lkp@intel.com/ Signed-off-by:
Yujie Liu <yujie.liu@intel.com> Reviewed-by:
Mukesh Ojha <quic_mojha@quicinc.com> Acked-by:
Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by:
Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jian Zhang authored
commit 54f1840d upstream. When the `CONFIG_I2C_SLAVE` option is enabled and the device operates as a slave, a situation arises where the master sends a START signal without the accompanying STOP signal. This action results in a persistent I2C bus timeout. The core issue stems from the fact that the i2c controller remains in a slave read state without a timeout mechanism. As a consequence, the bus perpetually experiences timeouts. In this case, the i2c bus will be reset, but the slave_state reset is missing. Fixes: fee46515 ("i2c: aspeed: Reset the i2c controller when timeout occurs") Signed-off-by:
Jian Zhang <zhangjian.3032@bytedance.com> Acked-by:
Andi Shyti <andi.shyti@kernel.org> Tested-by:
Andrew Jeffery <andrew@codeconstruct.com.au> Reviewed-by:
Andrew Jeffery <andrew@codeconstruct.com.au> Signed-off-by:
Wolfram Sang <wsa@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alain Volmat authored
commit c896ff2d upstream. In case of SMBUS byte read with PEC enabled, the whole transfer is split into two commands. A first write command, followed by a read command. The write command does not have any PEC byte and a PEC byte is appended at the end of the read command. (cf Read byte protocol with PEC in SMBUS specification) Within the STM32 I2C controller, handling (either sending or receiving) of the PEC byte is done via the PECBYTE bit in register CR2. Currently, the PECBYTE is set at the beginning of a transfer, which lead to sending a PEC byte at the end of the write command (hence losing the real last byte), and also does not check the PEC byte received during the read command. This patch corrects the function stm32f7_i2c_smbus_xfer_msg in order to only set the PECBYTE during the read command. Fixes: 9e48155f ("i2c: i2c-stm32f7: Add initial SMBus protocols support") Signed-off-by:
Alain Volmat <alain.volmat@foss.st.com> Reviewed-by:
Pierre-Yves MORDRET <pierre-yves.mordret@foss.st.com> Acked-by:
Andi Shyti <andi.shyti@kernel.org> Signed-off-by:
Wolfram Sang <wsa@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Herve Codina authored
commit 0fb118de upstream. i2c-demux-pinctrl uses the pair of_find_i2c_adapter_by_node() / i2c_put_adapter(). These pair alone is not correct to properly lock the I2C parent adapter. Indeed, i2c_put_adapter() decrements the module refcount while of_find_i2c_adapter_by_node() does not increment it. This leads to an underflow of the parent module refcount. Use the dedicated function, of_get_i2c_adapter_by_node(), to handle correctly the module refcount. Fixes: 50a5ba87 ("i2c: mux: demux-pinctrl: add driver") Signed-off-by:
Herve Codina <herve.codina@bootlin.com> Cc: stable@vger.kernel.org Acked-by:
Peter Rosin <peda@axentia.se> Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Wolfram Sang <wsa@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Herve Codina authored
commit 3dc0ec46 upstream. i2c-mux-gpmux uses the pair of_find_i2c_adapter_by_node() / i2c_put_adapter(). These pair alone is not correct to properly lock the I2C parent adapter. Indeed, i2c_put_adapter() decrements the module refcount while of_find_i2c_adapter_by_node() does not increment it. This leads to an underflow of the parent module refcount. Use the dedicated function, of_get_i2c_adapter_by_node(), to handle correctly the module refcount. Fixes: ac8498f0 ("i2c: i2c-mux-gpmux: new driver") Signed-off-by:
Herve Codina <herve.codina@bootlin.com> Cc: stable@vger.kernel.org Acked-by:
Peter Rosin <peda@axentia.se> Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Wolfram Sang <wsa@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Herve Codina authored
commit 3171d37b upstream. i2c-mux-pinctrl uses the pair of_find_i2c_adapter_by_node() / i2c_put_adapter(). These pair alone is not correct to properly lock the I2C parent adapter. Indeed, i2c_put_adapter() decrements the module refcount while of_find_i2c_adapter_by_node() does not increment it. This leads to an underflow of the parent module refcount. Use the dedicated function, of_get_i2c_adapter_by_node(), to handle correctly the module refcount. Fixes: c4aee3e1 ("i2c: mux: pinctrl: remove platform_data") Signed-off-by:
Herve Codina <herve.codina@bootlin.com> Cc: stable@vger.kernel.org Acked-by:
Peter Rosin <peda@axentia.se> Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Wolfram Sang <wsa@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Robert Hancock authored
commit e2bd8c28 upstream. The driver was previously using offset and scale values for the temperature sensor readings which were only valid for 7-series devices. Add per-device-type values for offset and scale and set them appropriately for each device type. Note that the values used for the UltraScale family are for UltraScale+ (i.e. the SYSMONE4 primitive) using the internal reference, as that seems to be the most common configuration and the device tree values Xilinx's device tree generator produces don't seem to give us anything to tell us which configuration is used. However, the differences within the UltraScale family seem fairly minor and it's closer than using the 7-series values instead in any case. Fixes: c2b7720a ("iio: xilinx-xadc: Add basic support for Ultrascale System Monitor") Signed-off-by:
Robert Hancock <robert.hancock@calian.com> Acked-by:
O'Griofa, Conall <conall.ogriofa@amd.com> Tested-by:
O'Griofa, Conall <conall.ogriofa@amd.com> Link: https://lore.kernel.org/r/20230915001019.2862964-3-robert.hancock@calian.com Cc: <Stable@vger.kernel.org> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Robert Hancock authored
commit 8d6b3ea4 upstream. In the probe function, the driver was reading out the thresholds already set in the core, which can be configured by the user in the Vivado tools when the FPGA image is built. However, it later clobbered those values with zero or maximum values. In particular, the overtemperature shutdown threshold register was overwritten with the max value, which effectively prevents the FPGA from shutting down when the desired threshold was eached, potentially risking hardware damage in that case. Remove this code to leave the preconfigured default threshold values intact. The code was also disabling all alarms regardless of what enable state they were left in by the FPGA image, including the overtemperature shutdown feature. Leave these bits in their original state so they are not unconditionally disabled. Fixes: bdc8cda1 ("iio:adc: Add Xilinx XADC driver") Signed-off-by:
Robert Hancock <robert.hancock@calian.com> Acked-by:
O'Griofa, Conall <conall.ogriofa@amd.com> Tested-by:
O'Griofa, Conall <conall.ogriofa@amd.com> Link: https://lore.kernel.org/r/20230915001019.2862964-2-robert.hancock@calian.com Cc: <Stable@vger.kernel.org> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Marek Szyprowski authored
commit 865b080e upstream. Second interrupt is needed only when touchscreen mode is used, so don't request it unconditionally. This removes the following annoying warning during boot: exynos-adc 14d10000.adc: error -ENXIO: IRQ index 1 not found Fixes: 2bb8ad9b ("iio: exynos-adc: add experimental touchscreen support") Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20231009101412.916922-1-m.szyprowski@samsung.com Cc: <Stable@vger.kernel.org> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Linus Walleij authored
commit bee44839 upstream. As noted by Jonathan Cameron: it is perfectly legal for a channel to have an offset but no scale in addition to the raw interface. The conversion will imply that scale is 1:1. Make rescale_configure_channel() accept just scale, or just offset to process a channel. When a user asks for IIO_CHAN_INFO_OFFSET in rescale_read_raw() we now have to deal with the fact that OFFSET could be present but SCALE missing. Add code to simply scale 1:1 in this case. Link: https://lore.kernel.org/linux-iio/CACRpkdZXBjHU4t-GVOCFxRO-AHGxKnxMeHD2s4Y4PuC29gBq6g@mail.gmail.com/ Fixes: 53ebee94 ("iio: afe: iio-rescale: Support processed channels") Fixes: 9decacd8 ("iio: afe: rescale: Fix boolean logic bug") Reported-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Peter Rosin <peda@axentia.se> Link: https://lore.kernel.org/r/20230902-iio-rescale-only-offset-v2-1-988b807754c8@linaro.org Cc: <Stable@vger.kernel.org> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jens Axboe authored
commit 7644b1a1 upstream. We could race with SQ thread exit, and if we do, we'll hit a NULL pointer dereference when the thread is cleared. Grab the SQPOLL data lock before attempting to get the task cpu and pid for fdinfo, this ensures we have a stable view of it. Cc: stable@vger.kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=218032 Reviewed-by:
Gabriel Krisman Bertazi <krisman@suse.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Haibo Li authored
commit babddbfb upstream. when the checked address is illegal,the corresponding shadow address from kasan_mem_to_shadow may have no mapping in mmu table. Access such shadow address causes kernel oops. Here is a sample about oops on arm64(VA 39bit) with KASAN_SW_TAGS and KASAN_OUTLINE on: [ffffffb80aaaaaaa] pgd=000000005d3ce003, p4d=000000005d3ce003, pud=000000005d3ce003, pmd=0000000000000000 Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP Modules linked in: CPU: 3 PID: 100 Comm: sh Not tainted 6.6.0-rc1-dirty #43 Hardware name: linux,dummy-virt (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __hwasan_load8_noabort+0x5c/0x90 lr : do_ib_ob+0xf4/0x110 ffffffb80aaaaaaa is the shadow address for efffff80aaaaaaaa. The problem is reading invalid shadow in kasan_check_range. The generic kasan also has similar oops. It only reports the shadow address which causes oops but not the original address. Commit 2f004eea("x86/kasan: Print original address on #GP") introduce to kasan_non_canonical_hook but limit it to KASAN_INLINE. This patch extends it to KASAN_OUTLINE mode. Link: https://lkml.kernel.org/r/20231009073748.159228-1-haibo.li@mediatek.com Fixes: 2f004eea ("x86/kasan: Print original address on #GP") Signed-off-by:
Haibo Li <haibo.li@mediatek.com> Reviewed-by:
Andrey Konovalov <andreyknvl@gmail.com> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Haibo Li <haibo.li@mediatek.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Kees Cook <keescook@chromium.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Khazhismel Kumykov authored
commit 2dd710d4 upstream. Inexact, we may reject some not-overflowing values incorrectly, but they'll be on the order of exabytes allowed anyways. This fixes divide error crash on x86 if bps_limit is not configured or is set too high in the rare case that jiffy_elapsed is greater than HZ. Fixes: e8368b57 ("blk-throttle: use calculate_io/bytes_allowed() for throtl_trim_slice()") Fixes: 8d6bbaad ("blk-throttle: prevent overflow while calculating wait time") Signed-off-by:
Khazhismel Kumykov <khazhy@google.com> Acked-by:
Tejun Heo <tj@kernel.org> Link: https://lore.kernel.org/r/20231020223617.2739774-1-khazhy@google.com Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Damien Le Moal authored
commit 24eca2dc upstream. Commit aa3998db ("ata: libata-scsi: Disable scsi device manage_system_start_stop") change setting the manage_system_start_stop flag to false for libata managed disks to enable libata internal management of disk suspend/resume. However, a side effect of this change is that on system shutdown, disks are no longer being stopped (set to standby mode with the heads unloaded). While this is not a critical issue, this unclean shutdown is not recommended and shows up with increased smart counters (e.g. the unexpected power loss counter "Unexpect_Power_Loss_Ct"). Instead of defining a shutdown driver method for all ATA adapter drivers (not all of them define that operation), this patch resolves this issue by further refining the sd driver start/stop control of disks using the new flag manage_shutdown. If this new flag is set to true by a low level driver, the function sd_shutdown() will issue a START STOP UNIT command with the start argument set to 0 when a disk needs to be powered off (suspended) on system power off, that is, when system_state is equal to SYSTEM_POWER_OFF. Similarly to the other manage_xxx flags, the new manage_shutdown flag is exposed through sysfs as a read-write device attribute. To avoid any confusion between manage_shutdown and manage_system_start_stop, the comments describing these flags in include/scsi/scsi.h are also improved. Fixes: aa3998db ("ata: libata-scsi: Disable scsi device manage_system_start_stop") Cc: stable@vger.kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218038 Link: https://lore.kernel.org/all/cd397c88-bf53-4768-9ab8-9d107df9e613@gmail.com/ Signed-off-by:
Damien Le Moal <dlemoal@kernel.org> Reviewed-by:
Niklas Cassel <niklas.cassel@wdc.com> Reviewed-by:
Hannes Reinecke <hare@suse.de> Reviewed-by:
James Bottomley <James.Bottomley@HansenPartnership.com> Acked-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Michal Schmidt authored
[ Upstream commit 53798666 ] In iavf_down, we're skipping the scheduling of certain operations if the driver is being removed. However, the IAVF_FLAG_AQ_DISABLE_QUEUES request must not be skipped in this case, because iavf_close waits for the transition to the __IAVF_DOWN state, which happens in iavf_virtchnl_completion after the queues are released. Without this fix, "rmmod iavf" takes half a second per interface that's up and prints the "Device resources not yet released" warning. Fixes: c8de44b5 ("iavf: do not process adminq tasks when __IAVF_IN_REMOVE_TASK is set") Signed-off-by:
Michal Schmidt <mschmidt@redhat.com> Reviewed-by:
Wojciech Drewek <wojciech.drewek@intel.com> Tested-by:
Rafal Romanowski <rafal.romanowski@intel.com> Tested-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Link: https://lore.kernel.org/r/20231025183213.874283-1-jacob.e.keller@intel.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-