- Linux-stable-mirror - lists.linaro.org

[PATCH 0/2] Backport request: mcp2221 needed to access eeprom data

by Romain Sioen

Hi maintainers, Please consider backporting the following patches to the stable trees. These patches fix a significant reading issue with mcp2221 on i2c eeprom. I have confirmed that the patches applie cleanly and build successfully against v6.6, v6.1, v5.15 and v5.10 stable branches. I will later come back to you with other patches that might need larger backport changes. Thanks, Romain Hamish Martin (2): HID: mcp2221: Don't set bus speed on every transfer HID: mcp2221: Handle reads greater than 60 bytes drivers/hid/hid-mcp2221.c | 71 +++++++++++++++++++++++++++------------ 1 file changed, 49 insertions(+), 22 deletions(-) -- 2.48.1

1 month, 4 weeks

1
2
0 0

5.10 backport request: ASoC: Intel: sof_rt5682: shrink platform_id names below 20 characters

by Michał Górny

Hello, I would like to request backporting the following patch to 5.10 series: 590cfb082837cc6c0c595adf1711330197c86a58 ASoC: Intel: sof_rt5682: shrink platform_id names below 20 characters The patch seems to be already present in 5.15 and newer branches, and its lack seems to be causing out-of-bounds read. I've hit it in the wild while trying to install 5.10.241 on i686: sh /var/tmp/portage/sys-kernel/gentoo-kernel-5.10.241/work/linux-5.10/scripts/depmod.sh depmod 5.10.241-gentoo-dist depmod: FATAL: Module index: bad character '�'=0x80 - only 7-bit ASCII is supported: platform:jsl_rt5682_max98360ax� TIA. -- Best regards, Michał Górny

1 month, 4 weeks

3
17
0 0

[PATCH v4 2/4] x86/cpu/topology: Always try cpu_parse_topology_ext() on AMD/Hygon

by K Prateek Nayak

Support for parsing the topology on AMD/Hygon processors using CPUID leaf 0xb was added in commit 3986a0a805e6 ("x86/CPU/AMD: Derive CPU topology from CPUID function 0xB when available"). In an effort to keep all the topology parsing bits in one place, this commit also introduced a pseudo dependency on the TOPOEXT feature to parse the CPUID leaf 0xb. TOPOEXT feature (CPUID 0x80000001 ECX[22]) advertises the support for Cache Properties leaf 0x8000001d and the CPUID leaf 0x8000001e EAX for "Extended APIC ID" however support for 0xb was introduced alongside the x2APIC support not only on AMD [1], but also historically on x86 [2]. Similar to 0xb, the support for extended CPU topology leaf 0x80000026 too does not depend on the TOPOEXT feature. The support for these leaves is expected to be confirmed by ensuring "leaf <= {extended_}cpuid_level" and then parsing the level 0 of the respective leaf to confirm EBX[15:0] (LogProcAtThisLevel) is non-zero as stated in the definition of "CPUID_Fn0000000B_EAX_x00 [Extended Topology Enumeration] (Core::X86::Cpuid::ExtTopEnumEax0)" in Processor Programming Reference (PPR) for AMD Family 19h Model 01h Rev B1 Vol1 [3] Sec. 2.1.15.1 "CPUID Instruction Functions". This has not been a problem on baremetal platforms since support for TOPOEXT (Fam 0x15 and later) predates the support for CPUID leaf 0xb (Fam 0x17[Zen2] and later), however, for AMD guests on QEMU, "x2apic" feature can be enabled independent of the "topoext" feature where QEMU expects topology and the initial APICID to be parsed using the CPUID leaf 0xb (especially when number of cores > 255) which is populated independent of the "topoext" feature flag. Unconditionally call cpu_parse_topology_ext() on AMD and Hygon processors to first parse the topology using the XTOPOLOGY leaves (0x80000026 / 0xb) before using the TOPOEXT leaf (0x8000001e). Cc: stable(a)vger.kernel.org # Only v6.9 and above Link: https://lore.kernel.org/lkml/1529686927-7665-1-git-send-email-suravee.suthi… [1] Link: https://lore.kernel.org/lkml/20080818181435.523309000@linux-os.sc.intel.com/ [2] Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 [3] Suggested-by: Naveen N Rao (AMD) <naveen(a)kernel.org> Fixes: 3986a0a805e6 ("x86/CPU/AMD: Derive CPU topology from CPUID function 0xB when available") Signed-off-by: K Prateek Nayak <kprateek.nayak(a)amd.com> --- Changelog v3..v4: o Quoted relevant section of the PPR justifying the changes. o Moved this patch up ahead. o Cc'd stable and made a note that backports should target v6.9 and above since this depends on the x86 topology rewrite. --- arch/x86/kernel/cpu/topology_amd.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/cpu/topology_amd.c b/arch/x86/kernel/cpu/topology_amd.c index 827dd0dbb6e9..4e3134a5550c 100644 --- a/arch/x86/kernel/cpu/topology_amd.c +++ b/arch/x86/kernel/cpu/topology_amd.c @@ -175,18 +175,14 @@ static void topoext_fixup(struct topo_scan *tscan) static void parse_topology_amd(struct topo_scan *tscan) { - bool has_topoext = false; - /* - * If the extended topology leaf 0x8000_001e is available - * try to get SMT, CORE, TILE, and DIE shifts from extended + * Try to get SMT, CORE, TILE, and DIE shifts from extended * CPUID leaf 0x8000_0026 on supported processors first. If * extended CPUID leaf 0x8000_0026 is not supported, try to * get SMT and CORE shift from leaf 0xb first, then try to * get the CORE shift from leaf 0x8000_0008. */ - if (cpu_feature_enabled(X86_FEATURE_TOPOEXT)) - has_topoext = cpu_parse_topology_ext(tscan); + bool has_topoext = cpu_parse_topology_ext(tscan); if (cpu_feature_enabled(X86_FEATURE_AMD_HTR_CORES)) tscan->c->topo.cpu_type = cpuid_ebx(0x80000026); -- 2.34.1

1 month, 4 weeks

2
3
0 0

[PATCH v2 0/4] nios2: Add architecture support for clone3

by Simon Schuster via B4 Relay

This series adds support for the clone3 system call to the nios2 architecture. This addresses the build-time warning "warning: clone3() entry point is missing, please fix" introduced in 505d66d1abfb9 ("clone3: drop __ARCH_WANT_SYS_CLONE3 macro"). The implementation passes the relevant clone3 tests of kselftest when applied on top of next-20250815: ./run_kselftest.sh TAP version 13 1..4 # selftests: clone3: clone3 ok 1 selftests: clone3: clone3 # selftests: clone3: clone3_clear_sighand ok 2 selftests: clone3: clone3_clear_sighand # selftests: clone3: clone3_set_tid ok 3 selftests: clone3: clone3_set_tid # selftests: clone3: clone3_cap_checkpoint_restore ok 4 selftests: clone3: clone3_cap_checkpoint_restore The series also includes a small patch to kernel/fork.c that ensures that clone_flags are passed correctly on architectures where unsigned long is insufficient to store the u64 clone_flags. It is marked as a fix for stable backporting. As requested, in v2, this series now further tries to correct this type error throughout the whole code base. Thus, it now touches a larger number of subsystems and all architectures. Therefore, another test was performed for ARCH=x86_64 (as a representative for 64-bit architectures). Here, the series builds cleanly without warnings on defconfig with CONFIG_SECURITY_APPARMOR=y and CONFIG_SECURITY_TOMOYO=y (to compile-check the LSM-related changes). The build further successfully passes testing/selftests/clone3 (with the patch from 20241105062948.1037011-1-zhouyuhang1010(a)163.com to prepare clone3_cap_checkpoint_restore for compatibility with the newer libcap version on my system). Is there any option to further preflight check this patch series via lkp/KernelCI/etc. for a broader test across architectures, or is this degree of testing sufficient to eventually get the series merged? N.B.: The series is not checkpatch clean right now: - include/linux/cred.h, include/linux/mnt_namespace.h: function definition arguments without identifier name - include/trace/events/task.h: space prohibited after that open parenthesis I did not fix these warnings to keep my changes minimal and reviewable, as the issues persist throughout the files and they were not introduced by me; I only followed the existing code style and just replaced the types. If desired, I'd be happy to make the changes in a potential v3, though. Signed-off-by: Simon Schuster <schuster.simon(a)siemens-energy.com> --- Changes in v2: - Introduce "Fixes:" and "Cc: stable(a)vger.kernel.org" where necessary - Factor out "Fixes:" when adapting the datatype of clone_flags for easier backports - Fix additional instances where `unsigned long` clone_flags is used - Reword commit message to make it clearer that any 32-bit arch is affected by this bug - Link to v1: https://lore.kernel.org/r/20250821-nios2-implement-clone3-v1-0-1bb24017376a… --- Simon Schuster (4): copy_sighand: Handle architectures where sizeof(unsigned long) < sizeof(u64) copy_process: pass clone_flags as u64 across calltree arch: copy_thread: pass clone_flags as u64 nios2: implement architecture-specific portion of sys_clone3 arch/alpha/kernel/process.c | 2 +- arch/arc/kernel/process.c | 2 +- arch/arm/kernel/process.c | 2 +- arch/arm64/kernel/process.c | 2 +- arch/csky/kernel/process.c | 2 +- arch/hexagon/kernel/process.c | 2 +- arch/loongarch/kernel/process.c | 2 +- arch/m68k/kernel/process.c | 2 +- arch/microblaze/kernel/process.c | 2 +- arch/mips/kernel/process.c | 2 +- arch/nios2/include/asm/syscalls.h | 1 + arch/nios2/include/asm/unistd.h | 2 -- arch/nios2/kernel/entry.S | 6 ++++++ arch/nios2/kernel/process.c | 2 +- arch/nios2/kernel/syscall_table.c | 1 + arch/openrisc/kernel/process.c | 2 +- arch/parisc/kernel/process.c | 2 +- arch/powerpc/kernel/process.c | 2 +- arch/riscv/kernel/process.c | 2 +- arch/s390/kernel/process.c | 2 +- arch/sh/kernel/process_32.c | 2 +- arch/sparc/kernel/process_32.c | 2 +- arch/sparc/kernel/process_64.c | 2 +- arch/um/kernel/process.c | 2 +- arch/x86/include/asm/fpu/sched.h | 2 +- arch/x86/include/asm/shstk.h | 4 ++-- arch/x86/kernel/fpu/core.c | 2 +- arch/x86/kernel/process.c | 2 +- arch/x86/kernel/shstk.c | 2 +- arch/xtensa/kernel/process.c | 2 +- block/blk-ioc.c | 2 +- fs/namespace.c | 2 +- include/linux/cgroup.h | 4 ++-- include/linux/cred.h | 2 +- include/linux/iocontext.h | 6 +++--- include/linux/ipc_namespace.h | 4 ++-- include/linux/lsm_hook_defs.h | 2 +- include/linux/mnt_namespace.h | 2 +- include/linux/nsproxy.h | 2 +- include/linux/pid_namespace.h | 4 ++-- include/linux/rseq.h | 4 ++-- include/linux/sched/task.h | 2 +- include/linux/security.h | 4 ++-- include/linux/sem.h | 4 ++-- include/linux/time_namespace.h | 4 ++-- include/linux/uprobes.h | 4 ++-- include/linux/user_events.h | 4 ++-- include/linux/utsname.h | 4 ++-- include/net/net_namespace.h | 4 ++-- include/trace/events/task.h | 6 +++--- ipc/namespace.c | 2 +- ipc/sem.c | 2 +- kernel/cgroup/namespace.c | 2 +- kernel/cred.c | 2 +- kernel/events/uprobes.c | 2 +- kernel/fork.c | 10 +++++----- kernel/nsproxy.c | 4 ++-- kernel/pid_namespace.c | 2 +- kernel/sched/core.c | 4 ++-- kernel/sched/fair.c | 2 +- kernel/sched/sched.h | 4 ++-- kernel/time/namespace.c | 2 +- kernel/utsname.c | 2 +- net/core/net_namespace.c | 2 +- security/apparmor/lsm.c | 2 +- security/security.c | 2 +- security/selinux/hooks.c | 2 +- security/tomoyo/tomoyo.c | 2 +- 68 files changed, 95 insertions(+), 89 deletions(-) --- base-commit: 1357b2649c026b51353c84ddd32bc963e8999603 change-id: 20250818-nios2-implement-clone3-7f252c20860b Best regards, -- Simon Schuster <schuster.simon(a)siemens-energy.com>

1 month, 4 weeks

4
5
0 0

[PATCH v2] mtd: nand: raw: atmel: Respect tAR, tCLR in read setup timing

by A. Sverdlin

From: Alexander Sverdlin <alexander.sverdlin(a)siemens.com> Having setup time 0 violates tAR, tCLR of some chips, for instance TOSHIBA TC58NVG2S3ETAI0 cannot be detected successfully (first ID byte being read duplicated, i.e. 98 98 dc 90 15 76 14 03 instead of 98 dc 90 15 76 ...). Atmel Application Notes postulated 1 cycle NRD_SETUP without explanation [1], but it looks more appropriate to just calculate setup time properly. [1] Link: https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/Applicatio… Cc: stable(a)vger.kernel.org Fixes: f9ce2eddf176 ("mtd: nand: atmel: Add ->setup_data_interface() hooks") Signed-off-by: Alexander Sverdlin <alexander.sverdlin(a)siemens.com> --- v2: - Cc'ed stable - reformatted atmel_smc_cs_conf_set_setup() call - rebased onto mtd/fixes drivers/mtd/nand/raw/atmel/nand-controller.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c b/drivers/mtd/nand/raw/atmel/nand-controller.c index dedcca87defc7..ad0eff385e123 100644 --- a/drivers/mtd/nand/raw/atmel/nand-controller.c +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c @@ -1377,14 +1377,24 @@ static int atmel_smc_nand_prepare_smcconf(struct atmel_nand *nand, if (ret) return ret; + /* + * Read setup timing depends on the operation done on the NAND: + * + * NRD_SETUP = max(tAR, tCLR) + */ + timeps = max(conf->timings.sdr.tAR_min, conf->timings.sdr.tCLR_min); + ncycles = DIV_ROUND_UP(timeps, mckperiodps); + totalcycles += ncycles; + ret = atmel_smc_cs_conf_set_setup(smcconf, ATMEL_SMC_NRD_SHIFT, ncycles); + if (ret) + return ret; + /* * The read cycle timing is directly matching tRC, but is also * dependent on the setup and hold timings we calculated earlier, * which gives: * - * NRD_CYCLE = max(tRC, NRD_PULSE + NRD_HOLD) - * - * NRD_SETUP is always 0. + * NRD_CYCLE = max(tRC, NRD_SETUP + NRD_PULSE + NRD_HOLD) */ ncycles = DIV_ROUND_UP(conf->timings.sdr.tRC_min, mckperiodps); ncycles = max(totalcycles, ncycles); -- 2.50.1

1 month, 4 weeks

4
6
0 0

[PATCH] mtd: rawnand: stm32_fmc2: fix ECC overwrite

by Christophe Kerello

In case OOB write is requested during a data write, ECC is currently lost. Avoid this issue by only writing in the free spare area. This issue has been seen with a YAFFS2 file system. Signed-off-by: Christophe Kerello <christophe.kerello(a)foss.st.com> Cc: stable(a)vger.kernel.org Fixes: 2cd457f328c1 ("mtd: rawnand: stm32_fmc2: add STM32 FMC2 NAND flash controller driver") --- drivers/mtd/nand/raw/stm32_fmc2_nand.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/stm32_fmc2_nand.c b/drivers/mtd/nand/raw/stm32_fmc2_nand.c index a960403081f11091837b73b8610231fe421d0c05..f84f23392fa441327bec90ba12a2a57d825d9330 100644 --- a/drivers/mtd/nand/raw/stm32_fmc2_nand.c +++ b/drivers/mtd/nand/raw/stm32_fmc2_nand.c @@ -996,9 +996,21 @@ static int stm32_fmc2_nfc_seq_write(struct nand_chip *chip, const u8 *buf, /* Write oob */ if (oob_required) { - ret = nand_change_write_column_op(chip, mtd->writesize, - chip->oob_poi, mtd->oobsize, - false); + unsigned int offset_in_page = mtd->writesize; + const void *buf = chip->oob_poi; + unsigned int len = mtd->oobsize; + + if (!raw) { + struct mtd_oob_region oob_free; + + mtd_ooblayout_free(mtd, 0, &oob_free); + offset_in_page += oob_free.offset; + buf += oob_free.offset; + len = oob_free.length; + } + + ret = nand_change_write_column_op(chip, offset_in_page, + buf, len, false); if (ret) return ret; } --- base-commit: fb2fae70e7e985c4acb1ad96110d8b98bb64a87c change-id: 20250811-fix-ecc-overwrite-9962b7797746 Best regards, -- Christophe Kerello <christophe.kerello(a)foss.st.com>

1 month, 4 weeks

2
1
0 0

[PATCH] mtd: rawnand: stm32_fmc2: avoid overlapping mappings on ECC buffer

by Christophe Kerello

Avoid below overlapping mappings by using a contiguous non-cacheable buffer. [ 4.077708] DMA-API: stm32_fmc2_nfc 48810000.nand-controller: cacheline tracking EEXIST, overlapping mappings aren't supported [ 4.089103] WARNING: CPU: 1 PID: 44 at kernel/dma/debug.c:568 add_dma_entry+0x23c/0x300 [ 4.097071] Modules linked in: [ 4.100101] CPU: 1 PID: 44 Comm: kworker/u4:2 Not tainted 6.1.82 #1 [ 4.106346] Hardware name: STMicroelectronics STM32MP257F VALID1 SNOR / MB1704 (LPDDR4 Power discrete) + MB1703 + MB1708 (SNOR MB1730) (DT) [ 4.118824] Workqueue: events_unbound deferred_probe_work_func [ 4.124674] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.131624] pc : add_dma_entry+0x23c/0x300 [ 4.135658] lr : add_dma_entry+0x23c/0x300 [ 4.139792] sp : ffff800009dbb490 [ 4.143016] x29: ffff800009dbb4a0 x28: 0000000004008022 x27: ffff8000098a6000 [ 4.150174] x26: 0000000000000000 x25: ffff8000099e7000 x24: ffff8000099e7de8 [ 4.157231] x23: 00000000ffffffff x22: 0000000000000000 x21: ffff8000098a6a20 [ 4.164388] x20: ffff000080964180 x19: ffff800009819ba0 x18: 0000000000000006 [ 4.171545] x17: 6361727420656e69 x16: 6c6568636163203a x15: 72656c6c6f72746e [ 4.178602] x14: 6f632d646e616e2e x13: ffff800009832f58 x12: 00000000000004ec [ 4.185759] x11: 00000000000001a4 x10: ffff80000988af58 x9 : ffff800009832f58 [ 4.192916] x8 : 00000000ffffefff x7 : ffff80000988af58 x6 : 80000000fffff000 [ 4.199972] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000 [ 4.207128] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000812d2c40 [ 4.214185] Call trace: [ 4.216605] add_dma_entry+0x23c/0x300 [ 4.220338] debug_dma_map_sg+0x198/0x350 [ 4.224373] __dma_map_sg_attrs+0xa0/0x110 [ 4.228411] dma_map_sg_attrs+0x10/0x2c [ 4.232247] stm32_fmc2_nfc_xfer.isra.0+0x1c8/0x3fc [ 4.237088] stm32_fmc2_nfc_seq_read_page+0xc8/0x174 [ 4.242127] nand_read_oob+0x1d4/0x8e0 [ 4.245861] mtd_read_oob_std+0x58/0x84 [ 4.249596] mtd_read_oob+0x90/0x150 [ 4.253231] mtd_read+0x68/0xac Signed-off-by: Christophe Kerello <christophe.kerello(a)foss.st.com> Cc: stable(a)vger.kernel.org Fixes: 2cd457f328c1 ("mtd: rawnand: stm32_fmc2: add STM32 FMC2 NAND flash controller driver") --- drivers/mtd/nand/raw/stm32_fmc2_nand.c | 28 +++++++++------------------- 1 file changed, 9 insertions(+), 19 deletions(-) diff --git a/drivers/mtd/nand/raw/stm32_fmc2_nand.c b/drivers/mtd/nand/raw/stm32_fmc2_nand.c index a960403081f11091837b73b8610231fe421d0c05..222c3c3b684841879a55835e802dcf9983860c28 100644 --- a/drivers/mtd/nand/raw/stm32_fmc2_nand.c +++ b/drivers/mtd/nand/raw/stm32_fmc2_nand.c @@ -272,6 +272,7 @@ struct stm32_fmc2_nfc { struct sg_table dma_data_sg; struct sg_table dma_ecc_sg; u8 *ecc_buf; + dma_addr_t dma_ecc_addr; int dma_ecc_len; u32 tx_dma_max_burst; u32 rx_dma_max_burst; @@ -902,17 +903,10 @@ static int stm32_fmc2_nfc_xfer(struct nand_chip *chip, const u8 *buf, if (!write_data && !raw) { /* Configure DMA ECC status */ - p = nfc->ecc_buf; for_each_sg(nfc->dma_ecc_sg.sgl, sg, eccsteps, s) { - sg_set_buf(sg, p, nfc->dma_ecc_len); - p += nfc->dma_ecc_len; - } - - ret = dma_map_sg(nfc->dev, nfc->dma_ecc_sg.sgl, - eccsteps, dma_data_dir); - if (!ret) { - ret = -EIO; - goto err_unmap_data; + sg_dma_address(sg) = nfc->dma_ecc_addr + + s * nfc->dma_ecc_len; + sg_dma_len(sg) = nfc->dma_ecc_len; } desc_ecc = dmaengine_prep_slave_sg(nfc->dma_ecc_ch, @@ -921,7 +915,7 @@ static int stm32_fmc2_nfc_xfer(struct nand_chip *chip, const u8 *buf, DMA_PREP_INTERRUPT); if (!desc_ecc) { ret = -ENOMEM; - goto err_unmap_ecc; + goto err_unmap_data; } reinit_completion(&nfc->dma_ecc_complete); @@ -929,7 +923,7 @@ static int stm32_fmc2_nfc_xfer(struct nand_chip *chip, const u8 *buf, desc_ecc->callback_param = &nfc->dma_ecc_complete; ret = dma_submit_error(dmaengine_submit(desc_ecc)); if (ret) - goto err_unmap_ecc; + goto err_unmap_data; dma_async_issue_pending(nfc->dma_ecc_ch); } @@ -949,7 +943,7 @@ static int stm32_fmc2_nfc_xfer(struct nand_chip *chip, const u8 *buf, if (!write_data && !raw) dmaengine_terminate_all(nfc->dma_ecc_ch); ret = -ETIMEDOUT; - goto err_unmap_ecc; + goto err_unmap_data; } /* Wait DMA data transfer completion */ @@ -969,11 +963,6 @@ static int stm32_fmc2_nfc_xfer(struct nand_chip *chip, const u8 *buf, } } -err_unmap_ecc: - if (!write_data && !raw) - dma_unmap_sg(nfc->dev, nfc->dma_ecc_sg.sgl, - eccsteps, dma_data_dir); - err_unmap_data: dma_unmap_sg(nfc->dev, nfc->dma_data_sg.sgl, eccsteps, dma_data_dir); @@ -1610,7 +1599,8 @@ static int stm32_fmc2_nfc_dma_setup(struct stm32_fmc2_nfc *nfc) return ret; /* Allocate a buffer to store ECC status registers */ - nfc->ecc_buf = devm_kzalloc(nfc->dev, FMC2_MAX_ECC_BUF_LEN, GFP_KERNEL); + nfc->ecc_buf = dmam_alloc_coherent(nfc->dev, FMC2_MAX_ECC_BUF_LEN, + &nfc->dma_ecc_addr, GFP_KERNEL); if (!nfc->ecc_buf) return -ENOMEM; --- base-commit: fb2fae70e7e985c4acb1ad96110d8b98bb64a87c change-id: 20250811-fix-dma-overlapping-1c8fba7fd519 Best regards, -- Christophe Kerello <christophe.kerello(a)foss.st.com>

1 month, 4 weeks

2
1
0 0

UDF failures in 5.15

by Jan Kara

Hello, Henrik notified me that UDF in 5.15 kernel is failing for him, likely because commit 1ea1cd11c72d ("udf: Fix directory iteration for longer tail extents") is missing 5.15 stable tree. Basically wherever d16076d9b684b got backported, 1ea1cd11c72d needs to be backported as well (I'm sorry for forgetting to add proper Fixes tag back then). Honza -- Jan Kara <jack(a)suse.com> SUSE Labs, CR

1 month, 4 weeks

2
1
0 0

[PATCH] accel/ivpu: Prevent recovery work from being queued during device removal

by Jacek Lawrynowicz

From: Karol Wachowski <karol.wachowski(a)intel.com> Use disable_work_sync() instead of cancel_work_sync() in ivpu_dev_fini() to ensure that no new recovery work items can be queued after device removal has started. Previously, recovery work could be scheduled even after canceling existing work, potentially leading to use-after-free bugs if recovery accessed freed resources. Rename ivpu_pm_cancel_recovery() to ivpu_pm_disable_recovery() to better reflect its new behavior. Fixes: 58cde80f45a2 ("accel/ivpu: Use dedicated work for job timeout detection") Cc: <stable(a)vger.kernel.org> # v6.8+ Signed-off-by: Karol Wachowski <karol.wachowski(a)intel.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz(a)linux.intel.com> --- drivers/accel/ivpu/ivpu_drv.c | 2 +- drivers/accel/ivpu/ivpu_pm.c | 4 ++-- drivers/accel/ivpu/ivpu_pm.h | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c index 3d6d52492536a..3289751b47573 100644 --- a/drivers/accel/ivpu/ivpu_drv.c +++ b/drivers/accel/ivpu/ivpu_drv.c @@ -677,7 +677,7 @@ static void ivpu_bo_unbind_all_user_contexts(struct ivpu_device *vdev) static void ivpu_dev_fini(struct ivpu_device *vdev) { ivpu_jobs_abort_all(vdev); - ivpu_pm_cancel_recovery(vdev); + ivpu_pm_disable_recovery(vdev); ivpu_pm_disable(vdev); ivpu_prepare_for_reset(vdev); ivpu_shutdown(vdev); diff --git a/drivers/accel/ivpu/ivpu_pm.c b/drivers/accel/ivpu/ivpu_pm.c index eacda1dbe8405..475ddc94f1cfe 100644 --- a/drivers/accel/ivpu/ivpu_pm.c +++ b/drivers/accel/ivpu/ivpu_pm.c @@ -417,10 +417,10 @@ void ivpu_pm_init(struct ivpu_device *vdev) ivpu_dbg(vdev, PM, "Autosuspend delay = %d\n", delay); } -void ivpu_pm_cancel_recovery(struct ivpu_device *vdev) +void ivpu_pm_disable_recovery(struct ivpu_device *vdev) { drm_WARN_ON(&vdev->drm, delayed_work_pending(&vdev->pm->job_timeout_work)); - cancel_work_sync(&vdev->pm->recovery_work); + disable_work_sync(&vdev->pm->recovery_work); } void ivpu_pm_enable(struct ivpu_device *vdev) diff --git a/drivers/accel/ivpu/ivpu_pm.h b/drivers/accel/ivpu/ivpu_pm.h index 89b264cc0e3e7..a2aa7a27f32ef 100644 --- a/drivers/accel/ivpu/ivpu_pm.h +++ b/drivers/accel/ivpu/ivpu_pm.h @@ -25,7 +25,7 @@ struct ivpu_pm_info { void ivpu_pm_init(struct ivpu_device *vdev); void ivpu_pm_enable(struct ivpu_device *vdev); void ivpu_pm_disable(struct ivpu_device *vdev); -void ivpu_pm_cancel_recovery(struct ivpu_device *vdev); +void ivpu_pm_disable_recovery(struct ivpu_device *vdev); int ivpu_pm_suspend_cb(struct device *dev); int ivpu_pm_resume_cb(struct device *dev); -- 2.45.1

1 month, 4 weeks

2
2
0 0

[PATCH v2] drm/rcar-du: dsi: Fix 1/2/3 lane support

by Marek Vasut

Remove fixed PPI lane count setup. The R-Car DSI host is capable of operating in 1..4 DSI lane mode. Remove the hard-coded 4-lane configuration from PPI register settings and instead configure the PPI lane count according to lane count information already obtained by this driver instance. Configure TXSETR register to match PPI lane count. The R-Car V4H Reference Manual R19UH0186EJ0121 Rev.1.21 section 67.2.2.3 Tx Set Register (TXSETR), field LANECNT description indicates that the TXSETR register LANECNT bitfield lane count must be configured such, that it matches lane count configuration in PPISETR register DLEN bitfield. Make sure the LANECNT and DLEN bitfields are configured to match. Fixes: 155358310f01 ("drm: rcar-du: Add R-Car DSI driver") Cc: <stable(a)vger.kernel.org> Signed-off-by: Marek Vasut <marek.vasut+renesas(a)mailbox.org> --- Cc: David Airlie <airlied(a)gmail.com> Cc: Geert Uytterhoeven <geert+renesas(a)glider.be> Cc: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com> Cc: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Magnus Damm <magnus.damm(a)gmail.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Simona Vetter <simona(a)ffwll.ch> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Tomi Valkeinen <tomi.valkeinen+renesas(a)ideasonboard.com> Cc: dri-devel(a)lists.freedesktop.org Cc: linux-renesas-soc(a)vger.kernel.org --- V2: - Split this out of a series, update commit message, combine from drm/rcar-du: dsi: Remove fixed PPI lane count setup drm/rcar-du: dsi: Configure TXSETR register to match PPI lane count - add Fixes tag, CC stable --- drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c | 5 ++++- drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi_regs.h | 8 ++++---- 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c index 1af4c73f7a88..952c3efb74da 100644 --- a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c @@ -576,7 +576,10 @@ static int rcar_mipi_dsi_startup(struct rcar_mipi_dsi *dsi, udelay(10); rcar_mipi_dsi_clr(dsi, CLOCKSET1, CLOCKSET1_UPDATEPLL); - ppisetr = PPISETR_DLEN_3 | PPISETR_CLEN; + rcar_mipi_dsi_clr(dsi, TXSETR, TXSETR_LANECNT_MASK); + rcar_mipi_dsi_set(dsi, TXSETR, dsi->lanes - 1); + + ppisetr = ((BIT(dsi->lanes) - 1) & PPISETR_DLEN_MASK) | PPISETR_CLEN; rcar_mipi_dsi_write(dsi, PPISETR, ppisetr); rcar_mipi_dsi_set(dsi, PHYSETUP, PHYSETUP_SHUTDOWNZ); diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi_regs.h b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi_regs.h index a6b276f1d6ee..a54c7eb4113b 100644 --- a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi_regs.h +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi_regs.h @@ -12,6 +12,9 @@ #define LINKSR_LPBUSY (1 << 1) #define LINKSR_HSBUSY (1 << 0) +#define TXSETR 0x100 +#define TXSETR_LANECNT_MASK (0x3 << 0) + /* * Video Mode Register */ @@ -80,10 +83,7 @@ * PHY-Protocol Interface (PPI) Registers */ #define PPISETR 0x700 -#define PPISETR_DLEN_0 (0x1 << 0) -#define PPISETR_DLEN_1 (0x3 << 0) -#define PPISETR_DLEN_2 (0x7 << 0) -#define PPISETR_DLEN_3 (0xf << 0) +#define PPISETR_DLEN_MASK (0xf << 0) #define PPISETR_CLEN (1 << 8) #define PPICLCR 0x710 -- 2.47.2

1 month, 4 weeks

3
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror