January 2025 - Linux-stable-mirror

Re: [PATCH 6.12 000/189] 6.12.10-rc1 review

by Ronald Warsow

Hi Greg no regressions here on x86_64 (RKL, Intel 11th Gen. CPU) Thanks Tested-by: Ronald Warsow <rwarsow(a)gmx.de>

8 months, 3 weeks

1
0
0 0

[PATCH v4] powerpc/pseries/eeh: Fix get PE state translation

by Narayana Murty N

The PE Reset State "0" returned by RTAS calls "ibm_read_slot_reset_[state|state2]" indicates that the reset is deactivated and the PE is in a state where MMIO and DMA are allowed. However, the current implementation of "pseries_eeh_get_state()" does not reflect this, causing drivers to incorrectly assume that MMIO and DMA operations cannot be resumed. The userspace drivers as a part of EEH recovery using VFIO ioctls fail to detect when the recovery process is complete. The VFIO_EEH_PE_GET_STATE ioctl does not report the expected EEH_PE_STATE_NORMAL state, preventing userspace drivers from functioning properly on pseries systems. The patch addresses this issue by updating 'pseries_eeh_get_state()' to include "EEH_STATE_MMIO_ENABLED" and "EEH_STATE_DMA_ENABLED" in the result mask for PE Reset State "0". This ensures correct state reporting to the callers, aligning the behavior with the PAPR specification and fixing the bug in EEH recovery for VFIO user workflows. Fixes: 00ba05a12b3c ("powerpc/pseries: Cleanup on pseries_eeh_get_state()") Cc: <stable(a)vger.kernel.org> Signed-off-by: Narayana Murty N <nnmlinux(a)linux.ibm.com> --- Changelog: V1:https://lore.kernel.org/all/20241107042027.338065-1-nnmlinux@linux.ibm.c… --added Fixes tag for "powerpc/pseries: Cleanup on pseries_eeh_get_state()". V2:https://lore.kernel.org/stable/20241212075044.10563-1-nnmlinux%40linux.i… --Updated the patch description to include it in the stable kernel tree. V3:https://lore.kernel.org/all/87v7vm8pwz.fsf@gmail.com/ --Updated commit description. --- arch/powerpc/platforms/pseries/eeh_pseries.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/pseries/eeh_pseries.c b/arch/powerpc/platforms/pseries/eeh_pseries.c index 1893f66371fa..b12ef382fec7 100644 --- a/arch/powerpc/platforms/pseries/eeh_pseries.c +++ b/arch/powerpc/platforms/pseries/eeh_pseries.c @@ -580,8 +580,10 @@ static int pseries_eeh_get_state(struct eeh_pe *pe, int *delay) switch(rets[0]) { case 0: - result = EEH_STATE_MMIO_ACTIVE | - EEH_STATE_DMA_ACTIVE; + result = EEH_STATE_MMIO_ACTIVE | + EEH_STATE_DMA_ACTIVE | + EEH_STATE_MMIO_ENABLED | + EEH_STATE_DMA_ENABLED; break; case 1: result = EEH_STATE_RESET_ACTIVE | -- 2.47.1

8 months, 3 weeks

1
0
0 0

Re: [PATCHv3 2/2] x86/mm: Make memremap(MEMREMAP_WB) map memory as encrypted by default

by Tom Lendacky

On 1/14/25 09:06, Tom Lendacky wrote: > On 1/14/25 08:44, Kirill A. Shutemov wrote: >> On Tue, Jan 14, 2025 at 08:33:39AM -0600, Tom Lendacky wrote: >>> On 1/14/25 01:27, Kirill A. Shutemov wrote: >>>> On Mon, Jan 13, 2025 at 02:47:56PM -0600, Tom Lendacky wrote: >>>>> On 1/13/25 07:14, Kirill A. Shutemov wrote: >>>>>> Currently memremap(MEMREMAP_WB) can produce decrypted/shared mapping: >>>>>> >>>>>> memremap(MEMREMAP_WB) >>>>>> arch_memremap_wb() >>>>>> ioremap_cache() >>>>>> __ioremap_caller(.encrytped = false) >>>>>> >>>>>> In such cases, the IORES_MAP_ENCRYPTED flag on the memory will determine >>>>>> if the resulting mapping is encrypted or decrypted. >>>>>> >>>>>> Creating a decrypted mapping without explicit request from the caller is >>>>>> risky: >>>>>> >>>>>> - It can inadvertently expose the guest's data and compromise the >>>>>> guest. >>>>>> >>>>>> - Accessing private memory via shared/decrypted mapping on TDX will >>>>>> either trigger implicit conversion to shared or #VE (depending on >>>>>> VMM implementation). >>>>>> >>>>>> Implicit conversion is destructive: subsequent access to the same >>>>>> memory via private mapping will trigger a hard-to-debug #VE crash. >>>>>> >>>>>> The kernel already provides a way to request decrypted mapping >>>>>> explicitly via the MEMREMAP_DEC flag. >>>>>> >>>>>> Modify memremap(MEMREMAP_WB) to produce encrypted/private mapping by >>>>>> default unless MEMREMAP_DEC is specified. >>>>>> >>>>>> Fix the crash due to #VE on kexec in TDX guests if CONFIG_EISA is enabled. >>>>> >>>>> This patch causes my bare-metal system to crash during boot when using >>>>> mem_encrypt=on: >>>>> >>>>> [ 2.392934] efi: memattr: Entry type should be RuntimeServiceCode/Data >>>>> [ 2.393731] efi: memattr: ! 0x214c42f01f1162a-0xee70ac7bd1a9c629 [type=2028324321|attr=0x6590648fa4209879] >>>> >>>> Could you try if this helps? >>>> >>>> diff --git a/drivers/firmware/efi/memattr.c b/drivers/firmware/efi/memattr.c >>>> index c38b1a335590..b5051dcb7c1d 100644 >>>> --- a/drivers/firmware/efi/memattr.c >>>> +++ b/drivers/firmware/efi/memattr.c >>>> @@ -160,7 +160,7 @@ int __init efi_memattr_apply_permissions(struct mm_struct *mm, >>>> if (WARN_ON(!efi_enabled(EFI_MEMMAP))) >>>> return 0; >>>> >>>> - tbl = memremap(efi_mem_attr_table, tbl_size, MEMREMAP_WB); >>>> + tbl = memremap(efi_mem_attr_table, tbl_size, MEMREMAP_WB | MEMREMAP_DEC); >>> >>> Well that would work for SME where EFI tables/data are not encrypted, >>> but will break for SEV where EFI tables/data are encrypted. >> >> Hm. Why would it break for SEV? It brings the situation back to what it >> was before the patch. > > Ah, true. I can try it and see how much further SME gets. Hopefully it > doesn't turn into a whack-a-mole thing. Unfortunately, it is turning into a whack-a-mole thing. But it looks the following works for SME: diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c index 3c36f3f5e688..ff3cd5fc8508 100644 --- a/arch/x86/mm/ioremap.c +++ b/arch/x86/mm/ioremap.c @@ -505,7 +505,7 @@ EXPORT_SYMBOL(iounmap); void *arch_memremap_wb(phys_addr_t phys_addr, size_t size, unsigned long flags) { - if (flags & MEMREMAP_DEC) + if (flags & MEMREMAP_DEC || cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT)) return (void __force *)ioremap_cache(phys_addr, size); return (void __force *)ioremap_encrypted(phys_addr, size); I haven't had a chance to test the series on SEV, yet. Thanks, Tom > > Thanks, > Tom > >> >> Note that that __ioremap_caller() would still check io_desc.flags before >> mapping it as decrypted. >>

8 months, 4 weeks

3
2
0 0

[tip: irq/urgent] irqchip: Plug a OF node reference leak in platform_irqchip_probe()

by tip-bot2 for Joe Hattori

The following commit has been merged into the irq/urgent branch of tip: Commit-ID: 9322d1915f9d976ee48c09d800fbd5169bc2ddcc Gitweb: https://git.kernel.org/tip/9322d1915f9d976ee48c09d800fbd5169bc2ddcc Author: Joe Hattori <joe(a)pf.is.s.u-tokyo.ac.jp> AuthorDate: Sun, 15 Dec 2024 12:39:45 +09:00 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Wed, 15 Jan 2025 10:38:43 +01:00 irqchip: Plug a OF node reference leak in platform_irqchip_probe() platform_irqchip_probe() leaks a OF node when irq_init_cb() fails. Fix it by declaring par_np with the __free(device_node) cleanup construct. This bug was found by an experimental static analysis tool that I am developing. Fixes: f8410e626569 ("irqchip: Add IRQCHIP_PLATFORM_DRIVER_BEGIN/END and IRQCHIP_MATCH helper macros") Signed-off-by: Joe Hattori <joe(a)pf.is.s.u-tokyo.ac.jp> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/20241215033945.3414223-1-joe@pf.is.s.u-tokyo.ac… --- drivers/irqchip/irqchip.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c index 1eeb0d0..0ee7b6b 100644 --- a/drivers/irqchip/irqchip.c +++ b/drivers/irqchip/irqchip.c @@ -35,11 +35,10 @@ void __init irqchip_init(void) int platform_irqchip_probe(struct platform_device *pdev) { struct device_node *np = pdev->dev.of_node; - struct device_node *par_np = of_irq_find_parent(np); + struct device_node *par_np __free(device_node) = of_irq_find_parent(np); of_irq_init_cb_t irq_init_cb = of_device_get_match_data(&pdev->dev); if (!irq_init_cb) { - of_node_put(par_np); return -EINVAL; } @@ -55,7 +54,6 @@ int platform_irqchip_probe(struct platform_device *pdev) * interrupt controller can check for specific domains as necessary. */ if (par_np && !irq_find_matching_host(par_np, DOMAIN_BUS_ANY)) { - of_node_put(par_np); return -EPROBE_DEFER; }

8 months, 4 weeks

1
0
0 0

[PATCH v2] bus/fls-mc: Fix possible UAF error in driver_override_show()

by Qiu-ji Chen

Fixed a possible UAF problem in driver_override_show() in drivers/bus/fsl-mc/fsl-mc-bus.c This function driver_override_show() is part of DEVICE_ATTR_RW, which includes both driver_override_show() and driver_override_store(). These functions can be executed concurrently in sysfs. The driver_override_store() function uses driver_set_override() to update the driver_override value, and driver_set_override() internally locks the device (device_lock(dev)). If driver_override_show() reads cdx_dev->driver_override without locking, it could potentially access a freed pointer if driver_override_store() frees the string concurrently. This could lead to printing a kernel address, which is a security risk since DEVICE_ATTR can be read by all users. Additionally, a similar pattern is used in drivers/amba/bus.c, as well as many other bus drivers, where device_lock() is taken in the show function, and it has been working without issues. This potential bug was detected by our experimental static analysis tool, which analyzes locking APIs and paired functions to identify data races and atomicity violations. Fixes: 1f86a00c1159 ("bus/fsl-mc: add support for 'driver_override' in the mc-bus") Cc: stable(a)vger.kernel.org Signed-off-by: Qiu-ji Chen <chenqiuji666(a)gmail.com> --- V2: Revised the description to reduce the confusion it caused. --- drivers/bus/fsl-mc/fsl-mc-bus.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c index 930d8a3ba722..62a9da88b4c9 100644 --- a/drivers/bus/fsl-mc/fsl-mc-bus.c +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c @@ -201,8 +201,12 @@ static ssize_t driver_override_show(struct device *dev, struct device_attribute *attr, char *buf) { struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev); + ssize_t len; - return snprintf(buf, PAGE_SIZE, "%s\n", mc_dev->driver_override); + device_lock(dev); + len = snprintf(buf, PAGE_SIZE, "%s\n", mc_dev->driver_override); + device_unlock(dev); + return len; } static DEVICE_ATTR_RW(driver_override); -- 2.34.1

8 months, 4 weeks

1
0
0 0

[tip: x86/urgent] x86/fred: Fix the FRED RSP0 MSR out of sync with its per-CPU cache

by tip-bot2 for Xin Li (Intel)

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: de31b3cd706347044e1a57d68c3a683d58e8cca4 Gitweb: https://git.kernel.org/tip/de31b3cd706347044e1a57d68c3a683d58e8cca4 Author: Xin Li (Intel) <xin(a)zytor.com> AuthorDate: Fri, 10 Jan 2025 09:46:39 -08:00 Committer: Dave Hansen <dave.hansen(a)linux.intel.com> CommitterDate: Tue, 14 Jan 2025 14:16:36 -08:00 x86/fred: Fix the FRED RSP0 MSR out of sync with its per-CPU cache The FRED RSP0 MSR is only used for delivering events when running userspace. Linux leverages this property to reduce expensive MSR writes and optimize context switches. The kernel only writes the MSR when about to run userspace *and* when the MSR has actually changed since the last time userspace ran. This optimization is implemented by maintaining a per-CPU cache of FRED RSP0 and then checking that against the value for the top of current task stack before running userspace. However cpu_init_fred_exceptions() writes the MSR without updating the per-CPU cache. This means that the kernel might return to userspace with MSR_IA32_FRED_RSP0==0 when it needed to point to the top of current task stack. This would induce a double fault (#DF), which is bad. A context switch after cpu_init_fred_exceptions() can paper over the issue since it updates the cached value. That evidently happens most of the time explaining how this bug got through. Fix the bug through resynchronizing the FRED RSP0 MSR with its per-CPU cache in cpu_init_fred_exceptions(). Fixes: fe85ee391966 ("x86/entry: Set FRED RSP0 on return to userspace instead of context switch") Signed-off-by: Xin Li (Intel) <xin(a)zytor.com> Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Acked-by: Dave Hansen <dave.hansen(a)linux.intel.com> Cc:stable@vger.kernel.org Link: https://lore.kernel.org/all/20250110174639.1250829-1-xin%40zytor.com --- arch/x86/kernel/fred.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/fred.c b/arch/x86/kernel/fred.c index 8d32c3f..5e2cd10 100644 --- a/arch/x86/kernel/fred.c +++ b/arch/x86/kernel/fred.c @@ -50,7 +50,13 @@ void cpu_init_fred_exceptions(void) FRED_CONFIG_ENTRYPOINT(asm_fred_entrypoint_user)); wrmsrl(MSR_IA32_FRED_STKLVLS, 0); - wrmsrl(MSR_IA32_FRED_RSP0, 0); + + /* + * Ater a CPU offline/online cycle, the FRED RSP0 MSR should be + * resynchronized with its per-CPU cache. + */ + wrmsrl(MSR_IA32_FRED_RSP0, __this_cpu_read(fred_rsp0)); + wrmsrl(MSR_IA32_FRED_RSP1, 0); wrmsrl(MSR_IA32_FRED_RSP2, 0); wrmsrl(MSR_IA32_FRED_RSP3, 0);

8 months, 4 weeks

1
0
0 0

[tip: irq/urgent] irqchip/gic-v3: Handle CPU_PM_ENTER_FAILED correctly

by tip-bot2 for Yogesh Lal

The following commit has been merged into the irq/urgent branch of tip: Commit-ID: 0d62a49ab55c99e8deb4593b8d9f923de1ab5c18 Gitweb: https://git.kernel.org/tip/0d62a49ab55c99e8deb4593b8d9f923de1ab5c18 Author: Yogesh Lal <quic_ylal(a)quicinc.com> AuthorDate: Fri, 20 Dec 2024 15:09:07 +05:30 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Wed, 15 Jan 2025 09:42:44 +01:00 irqchip/gic-v3: Handle CPU_PM_ENTER_FAILED correctly When a CPU attempts to enter low power mode, it disables the redistributor and Group 1 interrupts and reinitializes the system registers upon wakeup. If the transition into low power mode fails, then the CPU_PM framework invokes the PM notifier callback with CPU_PM_ENTER_FAILED to allow the drivers to undo the state changes. The GIC V3 driver ignores CPU_PM_ENTER_FAILED, which leaves the GIC in disabled state. Handle CPU_PM_ENTER_FAILED in the same way as CPU_PM_EXIT to restore normal operation. [ tglx: Massage change log, add Fixes tag ] Fixes: 3708d52fc6bb ("irqchip: gic-v3: Implement CPU PM notifier") Signed-off-by: Yogesh Lal <quic_ylal(a)quicinc.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Acked-by: Marc Zyngier <maz(a)kernel.org> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/20241220093907.2747601-1-quic_ylal@quicinc.com --- drivers/irqchip/irq-gic-v3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c index 79d8cc8..76dce0a 100644 --- a/drivers/irqchip/irq-gic-v3.c +++ b/drivers/irqchip/irq-gic-v3.c @@ -1522,7 +1522,7 @@ static int gic_retrigger(struct irq_data *data) static int gic_cpu_pm_notifier(struct notifier_block *self, unsigned long cmd, void *v) { - if (cmd == CPU_PM_EXIT) { + if (cmd == CPU_PM_EXIT || cmd == CPU_PM_ENTER_FAILED) { if (gic_dist_security_disabled()) gic_enable_redist(true); gic_cpu_sys_reg_enable();

8 months, 4 weeks

1
0
0 0

[PATCH v2] irqchip/gic-v3-its: fix raw_local_irq_restore() called with IRQs enabled

by Tomas Krcka

The following call-chain leads to misuse of spinlock_irq when spinlock_irqsave was hold. irq_set_vcpu_affinity -> irq_get_desc_lock (spinlock_irqsave) -> its_irq_set_vcpu_affinity -> guard(raw_spin_lock_irq) <--- this enables interrupts -> irq_put_desc_unlock // <--- WARN IRQs enabled Fix the issue by using guard(raw_spinlock), since the function is already called with irqsave and raw_spin_lock was used before the commit b97e8a2f7130 ("irqchip/gic-v3-its: Fix potential race condition in its_vlpi_prop_update()") introducing the guard as well. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 38 PID: 444 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x2c/0x38 Call trace: warn_bogus_irq_restore+0x2c/0x38 _raw_spin_unlock_irqrestore+0x68/0x88 __irq_put_desc_unlock+0x1c/0x48 irq_set_vcpu_affinity+0x74/0xc0 its_map_vlpi+0x44/0x88 kvm_vgic_v4_set_forwarding+0x148/0x230 kvm_arch_irq_bypass_add_producer+0x20/0x28 __connect+0x98/0xb8 irq_bypass_register_consumer+0x150/0x178 kvm_irqfd+0x6dc/0x744 kvm_vm_ioctl+0xe44/0x16b0 Fixes: b97e8a2f7130 ("irqchip/gic-v3-its: Fix potential race condition in its_vlpi_prop_update()") Signed-off-by: Tomas Krcka <krckatom(a)amazon.de> Reviewed-by: Marc Zyngier <maz(a)kernel.org> Cc: stable(a)vger.kernel.org --- drivers/irqchip/irq-gic-v3-its.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 92244cfa0464..8c3ec5734f1e 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -2045,7 +2045,7 @@ static int its_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu_info) if (!is_v4(its_dev->its)) return -EINVAL; - guard(raw_spinlock_irq)(&its_dev->event_map.vlpi_lock); + guard(raw_spinlock)(&its_dev->event_map.vlpi_lock); /* Unmap request? */ if (!info) -- 2.40.1 Amazon Web Services Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597

8 months, 4 weeks

3
2
0 0

[PATCH v2] cdx: Fix possible UAF error in driver_override_show()

by Qiu-ji Chen

There is a data race between the functions driver_override_show() and driver_override_store(). In the driver_override_store() function, the assignment to ret calls driver_set_override(), which frees the old value while writing the new value to dev. If a race occurs, it may cause a use-after-free (UAF) error in driver_override_show(). To fix this issue, we adopt a logic similar to the driver_override_show() function in vmbus_drv.c, protecting dev within a lock to ensure its value remains unchanged. This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. Fixes: 48a6c7bced2a ("cdx: add device attributes") Cc: stable(a)vger.kernel.org Signed-off-by: Qiu-ji Chen <chenqiuji666(a)gmail.com> --- V2: Modified the title and description. Removed the changes to cdx_bus_match(). --- drivers/cdx/cdx.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/cdx/cdx.c b/drivers/cdx/cdx.c index 07371cb653d3..4af1901c9d52 100644 --- a/drivers/cdx/cdx.c +++ b/drivers/cdx/cdx.c @@ -470,8 +470,12 @@ static ssize_t driver_override_show(struct device *dev, struct device_attribute *attr, char *buf) { struct cdx_device *cdx_dev = to_cdx_device(dev); + ssize_t len; - return sysfs_emit(buf, "%s\n", cdx_dev->driver_override); + device_lock(dev); + len = sysfs_emit(buf, "%s\n", cdx_dev->driver_override); + device_unlock(dev); + return len; } static DEVICE_ATTR_RW(driver_override); -- 2.34.1

8 months, 4 weeks

2
3
0 0

[PATCH v2 1/1] mtd: spi-nor: core: replace dummy buswidth from addr to data

by Cheng Ming Lin

From: Cheng Ming Lin <chengminglin(a)mxic.com.tw> The default dummy cycle for Macronix SPI NOR flash in Octal Output Read Mode(1-1-8) is 20. Currently, the dummy buswidth is set according to the address bus width. In the 1-1-8 mode, this means the dummy buswidth is 1. When converting dummy cycles to bytes, this results in 20 x 1 / 8 = 2 bytes, causing the host to read data 4 cycles too early. Since the protocol data buswidth is always greater than or equal to the address buswidth. Setting the dummy buswidth to match the data buswidth increases the likelihood that the dummy cycle-to-byte conversion will be divisible, preventing the host from reading data prematurely. Fixes: 0e30f47232ab5 ("mtd: spi-nor: add support for DTR protocol") Cc: stable(a)vger.kernel.org Reviewd-by: Pratyush Yadav <pratyush(a)kernel.org> Signed-off-by: Cheng Ming Lin <chengminglin(a)mxic.com.tw> --- drivers/mtd/spi-nor/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index f9c189ed7353..c7aceaa8a43f 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -89,7 +89,7 @@ void spi_nor_spimem_setup_op(const struct spi_nor *nor, op->addr.buswidth = spi_nor_get_protocol_addr_nbits(proto); if (op->dummy.nbytes) - op->dummy.buswidth = spi_nor_get_protocol_addr_nbits(proto); + op->dummy.buswidth = spi_nor_get_protocol_data_nbits(proto); if (op->data.nbytes) op->data.buswidth = spi_nor_get_protocol_data_nbits(proto); -- 2.25.1

8 months, 4 weeks

6
10
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2025