December 2024 - Linux-stable-mirror

[PATCH RFT 4/6] serial: sh-sci: Do not probe the serial port if its slot in sci_ports[] is in use

by Claudiu

From: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> In the sh-sci driver, sci_ports[0] is used by earlycon. If the earlycon is still active when sci_probe() is called and the new serial port is supposed to map to sci_ports[0], return -EBUSY to prevent breaking the earlycon. This situation should occurs in debug scenarios, and users should be aware of the potential conflict. Fixes: 0b0cced19ab1 ("serial: sh-sci: Add CONFIG_SERIAL_EARLYCON support") Cc: stable(a)vger.kernel.org Signed-off-by: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> --- drivers/tty/serial/sh-sci.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c index 373195995d3b..e12fbc71082a 100644 --- a/drivers/tty/serial/sh-sci.c +++ b/drivers/tty/serial/sh-sci.c @@ -158,6 +158,7 @@ struct sci_port { bool has_rtscts; bool autorts; bool tx_occurred; + bool earlycon; }; #define SCI_NPORTS CONFIG_SERIAL_SH_SCI_NR_UARTS @@ -3443,6 +3444,7 @@ static int sci_probe_single(struct platform_device *dev, static int sci_probe(struct platform_device *dev) { struct plat_sci_port *p; + struct resource *res; struct sci_port *sp; unsigned int dev_id; int ret; @@ -3472,6 +3474,26 @@ static int sci_probe(struct platform_device *dev) } sp = &sci_ports[dev_id]; + + /* + * In case: + * - the probed port alias is zero (as the one used by earlycon), and + * - the earlycon is still active (e.g., "earlycon keep_bootcon" in + * bootargs) + * + * defer the probe of this serial. This is a debug scenario and the user + * must be aware of it. + * + * Except when the probed port is the same as the earlycon port. + */ + + res = platform_get_resource(dev, IORESOURCE_MEM, 0); + if (!res) + return -ENODEV; + + if (sp->earlycon && res->start != sp->port.mapbase) + return dev_err_probe(&dev->dev, -EBUSY, "sci_port[0] is used by earlycon!\n"); + platform_set_drvdata(dev, sp); ret = sci_probe_single(dev, dev_id, p, sp); @@ -3568,6 +3590,7 @@ static int __init early_console_setup(struct earlycon_device *device, port_cfg.type = type; sci_ports[0].cfg = &port_cfg; sci_ports[0].params = sci_probe_regmap(&port_cfg); + sci_ports[0].earlycon = true; port_cfg.scscr = sci_serial_in(&sci_ports[0].port, SCSCR); sci_serial_out(&sci_ports[0].port, SCSCR, SCSCR_RE | SCSCR_TE | port_cfg.scscr); -- 2.39.2

12 months

2
1
0 0

[PATCH v10 05/15] mmc: sdhci-msm: fix crypto key eviction

by Eric Biggers

From: Eric Biggers <ebiggers(a)google.com> Commit c7eed31e235c ("mmc: sdhci-msm: Switch to the new ICE API") introduced an incorrect check of the algorithm ID into the key eviction path, and thus qcom_ice_evict_key() is no longer ever called. Fix it. Fixes: c7eed31e235c ("mmc: sdhci-msm: Switch to the new ICE API") Cc: stable(a)vger.kernel.org Cc: Abel Vesa <abel.vesa(a)linaro.org> Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- drivers/mmc/host/sdhci-msm.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c index e00208535bd1..319f0ebbe652 100644 --- a/drivers/mmc/host/sdhci-msm.c +++ b/drivers/mmc/host/sdhci-msm.c @@ -1865,24 +1865,24 @@ static int sdhci_msm_program_key(struct cqhci_host *cq_host, struct sdhci_host *host = mmc_priv(cq_host->mmc); struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host); struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host); union cqhci_crypto_cap_entry cap; + if (!(cfg->config_enable & CQHCI_CRYPTO_CONFIGURATION_ENABLE)) + return qcom_ice_evict_key(msm_host->ice, slot); + /* Only AES-256-XTS has been tested so far. */ cap = cq_host->crypto_cap_array[cfg->crypto_cap_idx]; if (cap.algorithm_id != CQHCI_CRYPTO_ALG_AES_XTS || cap.key_size != CQHCI_CRYPTO_KEY_SIZE_256) return -EINVAL; - if (cfg->config_enable & CQHCI_CRYPTO_CONFIGURATION_ENABLE) - return qcom_ice_program_key(msm_host->ice, - QCOM_ICE_CRYPTO_ALG_AES_XTS, - QCOM_ICE_CRYPTO_KEY_SIZE_256, - cfg->crypto_key, - cfg->data_unit_size, slot); - else - return qcom_ice_evict_key(msm_host->ice, slot); + return qcom_ice_program_key(msm_host->ice, + QCOM_ICE_CRYPTO_ALG_AES_XTS, + QCOM_ICE_CRYPTO_KEY_SIZE_256, + cfg->crypto_key, + cfg->data_unit_size, slot); } #else /* CONFIG_MMC_CRYPTO */ static inline int sdhci_msm_ice_init(struct sdhci_msm_host *msm_host, -- 2.47.1

12 months

2
1
0 0

[PATCH] RDMA/srp: Fix error handling in srp_add_port

by Ma Ke

The reference count of the device incremented in device_initialize() is not decremented when device_add() fails. Add a put_device() call before returning from the function to decrement reference count for cleanup. Or it could cause memory leak. As comment of device_add() says, if device_add() succeeds, you should call device_del() when you want to get rid of it. If device_add() has not succeeded, use only put_device() to drop the reference count. Found by code review. Cc: stable(a)vger.kernel.org Fixes: c8e4c2397655 ("RDMA/srp: Rework the srp_add_port() error path") Signed-off-by: Ma Ke <make_ruc2021(a)163.com> --- drivers/infiniband/ulp/srp/ib_srp.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c index 2916e77f589b..7289ae0b83ac 100644 --- a/drivers/infiniband/ulp/srp/ib_srp.c +++ b/drivers/infiniband/ulp/srp/ib_srp.c @@ -3978,7 +3978,6 @@ static struct srp_host *srp_add_port(struct srp_device *device, u32 port) return host; put_host: - device_del(&host->dev); put_device(&host->dev); return NULL; } -- 2.25.1

12 months

3
3
0 0

[PATCH 6.6 v1] KVM: arm64: Disable MPAM visibility by default and ignore VMM writes

by Joey Gouly

From: James Morse <james.morse(a)arm.com> commit 6685f5d572c22e1003e7c0d089afe1c64340ab1f upstream. commit 011e5f5bf529f ("arm64/cpufeature: Add remaining feature bits in ID_AA64PFR0 register") exposed the MPAM field of AA64PFR0_EL1 to guests, but didn't add trap handling. A previous patch supplied the missing trap handling. Existing VMs that have the MPAM field of ID_AA64PFR0_EL1 set need to be migratable, but there is little point enabling the MPAM CPU interface on new VMs until there is something a guest can do with it. Clear the MPAM field from the guest's ID_AA64PFR0_EL1 and on hardware that supports MPAM, politely ignore the VMMs attempts to set this bit. Guests exposed to this bug have the sanitised value of the MPAM field, so only the correct value needs to be ignored. This means the field can continue to be used to block migration to incompatible hardware (between MPAM=1 and MPAM=5), and the VMM can't rely on the field being ignored. Signed-off-by: James Morse <james.morse(a)arm.com> Co-developed-by: Joey Gouly <joey.gouly(a)arm.com> Signed-off-by: Joey Gouly <joey.gouly(a)arm.com> Reviewed-by: Gavin Shan <gshan(a)redhat.com> Tested-by: Shameer Kolothum <shameerali.kolothum.thodi(a)huawei.com> Reviewed-by: Marc Zyngier <maz(a)kernel.org> Link: https://lore.kernel.org/r/20241030160317.2528209-7-joey.gouly@arm.com Signed-off-by: Oliver Upton <oliver.upton(a)linux.dev> [ joey: fixed up merge conflict, no ID_FILTERED macro in 6.6 ] Signed-off-by: Joey Gouly <joey.gouly(a)arm.com> Cc: stable(a)vger.kernel.org # 6.6.x Cc: Vitaly Chikunov <vt(a)altlinux.org> Link: https://lore.kernel.org/linux-arm-kernel/20241202045830.e4yy3nkvxtzaybxk@al… --- This fixes an issue seen when using KVM with a 6.6 host kernel, and newer (6.13+) kernels in the guest. Tested with a stripped down version of set_id_regs from the original patch series. arch/arm64/kvm/sys_regs.c | 52 +++++++++++++++++++++++++++++++++++++-- 1 file changed, 50 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c index 370a1a7bd369..2031703424ea 100644 --- a/arch/arm64/kvm/sys_regs.c +++ b/arch/arm64/kvm/sys_regs.c @@ -1330,6 +1330,7 @@ static u64 __kvm_read_sanitised_id_reg(const struct kvm_vcpu *vcpu, val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_MTE); val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_SME); + val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_MPAM_frac); break; case SYS_ID_AA64ISAR1_EL1: if (!vcpu_has_ptrauth(vcpu)) @@ -1472,6 +1473,13 @@ static u64 read_sanitised_id_aa64pfr0_el1(struct kvm_vcpu *vcpu, val &= ~ID_AA64PFR0_EL1_AMU_MASK; + /* + * MPAM is disabled by default as KVM also needs a set of PARTID to + * program the MPAMVPMx_EL2 PARTID remapping registers with. But some + * older kernels let the guest see the ID bit. + */ + val &= ~ID_AA64PFR0_EL1_MPAM_MASK; + return val; } @@ -1560,6 +1568,42 @@ static int set_id_dfr0_el1(struct kvm_vcpu *vcpu, return set_id_reg(vcpu, rd, val); } +static int set_id_aa64pfr0_el1(struct kvm_vcpu *vcpu, + const struct sys_reg_desc *rd, u64 user_val) +{ + u64 hw_val = read_sanitised_ftr_reg(SYS_ID_AA64PFR0_EL1); + u64 mpam_mask = ID_AA64PFR0_EL1_MPAM_MASK; + + /* + * Commit 011e5f5bf529f ("arm64/cpufeature: Add remaining feature bits + * in ID_AA64PFR0 register") exposed the MPAM field of AA64PFR0_EL1 to + * guests, but didn't add trap handling. KVM doesn't support MPAM and + * always returns an UNDEF for these registers. The guest must see 0 + * for this field. + * + * But KVM must also accept values from user-space that were provided + * by KVM. On CPUs that support MPAM, permit user-space to write + * the sanitizied value to ID_AA64PFR0_EL1.MPAM, but ignore this field. + */ + if ((hw_val & mpam_mask) == (user_val & mpam_mask)) + user_val &= ~ID_AA64PFR0_EL1_MPAM_MASK; + + return set_id_reg(vcpu, rd, user_val); +} + +static int set_id_aa64pfr1_el1(struct kvm_vcpu *vcpu, + const struct sys_reg_desc *rd, u64 user_val) +{ + u64 hw_val = read_sanitised_ftr_reg(SYS_ID_AA64PFR1_EL1); + u64 mpam_mask = ID_AA64PFR1_EL1_MPAM_frac_MASK; + + /* See set_id_aa64pfr0_el1 for comment about MPAM */ + if ((hw_val & mpam_mask) == (user_val & mpam_mask)) + user_val &= ~ID_AA64PFR1_EL1_MPAM_frac_MASK; + + return set_id_reg(vcpu, rd, user_val); +} + /* * cpufeature ID register user accessors * @@ -2018,10 +2062,14 @@ static const struct sys_reg_desc sys_reg_descs[] = { { SYS_DESC(SYS_ID_AA64PFR0_EL1), .access = access_id_reg, .get_user = get_id_reg, - .set_user = set_id_reg, + .set_user = set_id_aa64pfr0_el1, .reset = read_sanitised_id_aa64pfr0_el1, .val = ID_AA64PFR0_EL1_CSV2_MASK | ID_AA64PFR0_EL1_CSV3_MASK, }, - ID_SANITISED(ID_AA64PFR1_EL1), + { SYS_DESC(SYS_ID_AA64PFR1_EL1), + .access = access_id_reg, + .get_user = get_id_reg, + .set_user = set_id_aa64pfr1_el1, + .reset = kvm_read_sanitised_id_reg, }, ID_UNALLOCATED(4,2), ID_UNALLOCATED(4,3), ID_SANITISED(ID_AA64ZFR0_EL1), -- 2.25.1

12 months

5
6
0 0

[PATCH] KVM: SVM: allow flipping the LFENCE_SERIALIZE bit

by Paolo Bonzini

Allow the guest to both clear and set the LFENCE_SERIALIZE bit as long as it is set in the host. It is absolutely okay for the guest to set it if LFENCE_RDTSC is supported but userspace left it cleared; and it is also acceptable that the guest clears the bit even if this will actually have no effect. This fixes booting Windows in some configuration where it tries to set the bit, and hangs if it does not succeed. Suggested-by: Sean Christopherson <seanjc(a)google.com> Fixes: 74a0e79df68a ("KVM: SVM: Disallow guest from changing userspace's MSR_AMD64_DE_CFG value") Cc: stable(a)vger.kernel.org Cc: Tom Lendacky <thomas.lendacky(a)amd.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> --- arch/x86/kvm/svm/svm.c | 9 --------- 1 file changed, 9 deletions(-) diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index dd15cc635655..21dacd312779 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -3201,15 +3201,6 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr) if (data & ~supported_de_cfg) return 1; - /* - * Don't let the guest change the host-programmed value. The - * MSR is very model specific, i.e. contains multiple bits that - * are completely unknown to KVM, and the one bit known to KVM - * is simply a reflection of hardware capabilities. - */ - if (!msr->host_initiated && data != svm->msr_decfg) - return 1; - svm->msr_decfg = data; break; } -- 2.43.5

12 months

1
0
0 0

[PATCH RFT 2/6] serial: sh-sci: Drop __initdata macro for port_cfg

by Claudiu

From: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> The port_cfg object is used by serial_console_write(), which serves as the write function for the earlycon device. Marking port_cfg as __initdata causes it to be freed after kernel initialization, resulting in earlycon becoming unavailable thereafter. Remove the __initdata macro from port_cfg to resolve this issue. Fixes: dd076cffb8cd ("serial: sh-sci: Fix init data attribute for struct 'port_cfg'") Cc: stable(a)vger.kernel.org Signed-off-by: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> --- drivers/tty/serial/sh-sci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c index 924b803af440..4f5da3254420 100644 --- a/drivers/tty/serial/sh-sci.c +++ b/drivers/tty/serial/sh-sci.c @@ -3562,7 +3562,7 @@ sh_early_platform_init_buffer("earlyprintk", &sci_driver, early_serial_buf, ARRAY_SIZE(early_serial_buf)); #endif #ifdef CONFIG_SERIAL_SH_SCI_EARLYCON -static struct plat_sci_port port_cfg __initdata; +static struct plat_sci_port port_cfg; static int __init early_console_setup(struct earlycon_device *device, int type) -- 2.39.2

12 months

2
1
0 0

[PATCH v4 00/15] media: stm32: introduction of CSI / DCMIPP for STM32MP25

by Alain Volmat

This series introduces the camera pipeline support for the STM32MP25 SOC. The STM32MP25 has 3 pipelines, fed from a single camera input which can be either parallel or csi. This series adds the basic support for the 1st pipe (dump) which, in term of features is same as the one featured on the STM32MP13 SOC. It focuses on introduction of the CSI input stage for the DCMIPP, and the CSI specific new control code for the DCMIPP. One of the subdev of the DCMIPP, dcmipp_parallel is now renamed as dcmipp_input since it allows to not only control the parallel but also the csi interface. Signed-off-by: Alain Volmat <alain.volmat(a)foss.st.com> --- Changes in v4: * stm32-dcmipp: correct patch 13/15 with clk error handling in dcmipp_runtime_resume function - Link to v3: https://lore.kernel.org/r/20241118-csi_dcmipp_mp25-v3-0-c1914afb0a0f@foss.s… Changes in v3: * stm32-csi: use clk_bulk api * stm32-csiL perform reset control within the probe - Link to v2: https://lore.kernel.org/r/20241105-csi_dcmipp_mp25-v2-0-b9fc8a7273c2@foss.s… --- Alain Volmat (15): media: stm32: dcmipp: correct dma_set_mask_and_coherent mask value dt-bindings: media: add description of stm32 csi media: stm32: csi: addition of the STM32 CSI driver media: stm32: dcmipp: use v4l2_subdev_is_streaming media: stm32: dcmipp: replace s_stream with enable/disable_streams media: stm32: dcmipp: rename dcmipp_parallel into dcmipp_input media: stm32: dcmipp: add support for csi input into dcmipp-input media: stm32: dcmipp: add bayer 10~14 bits formats media: stm32: dcmipp: add 1X16 RGB / YUV formats support media: stm32: dcmipp: avoid duplicated format on enum in bytecap media: stm32: dcmipp: fill media ctl hw_revision field dt-bindings: media: add the stm32mp25 compatible of DCMIPP media: stm32: dcmipp: add core support for the stm32mp25 arm64: dts: st: add csi & dcmipp node in stm32mp25 arm64: dts: st: enable imx335/csi/dcmipp pipeline on stm32mp257f-ev1 .../devicetree/bindings/media/st,stm32-dcmipp.yaml | 53 +- .../bindings/media/st,stm32mp25-csi.yaml | 125 +++ MAINTAINERS | 8 + arch/arm64/boot/dts/st/stm32mp251.dtsi | 23 + arch/arm64/boot/dts/st/stm32mp257f-ev1.dts | 85 ++ drivers/media/platform/st/stm32/Kconfig | 14 + drivers/media/platform/st/stm32/Makefile | 1 + drivers/media/platform/st/stm32/stm32-csi.c | 1137 ++++++++++++++++++++ .../media/platform/st/stm32/stm32-dcmipp/Makefile | 2 +- .../st/stm32/stm32-dcmipp/dcmipp-bytecap.c | 128 ++- .../st/stm32/stm32-dcmipp/dcmipp-byteproc.c | 119 +- .../platform/st/stm32/stm32-dcmipp/dcmipp-common.h | 4 +- .../platform/st/stm32/stm32-dcmipp/dcmipp-core.c | 122 ++- .../platform/st/stm32/stm32-dcmipp/dcmipp-input.c | 540 ++++++++++ .../st/stm32/stm32-dcmipp/dcmipp-parallel.c | 440 -------- 15 files changed, 2224 insertions(+), 577 deletions(-) --- base-commit: 40384c840ea1944d7c5a392e8975ed088ecf0b37 change-id: 20241007-csi_dcmipp_mp25-7779601f57da Best regards, -- Alain Volmat <alain.volmat(a)foss.st.com>

12 months

2
2
0 0

[PATCH v6 0/5] media: uvcvideo: Two +1 fixes for async controls

by Ricardo Ribalda

This patchset fixes two +1 bugs with the async controls for the uvc driver. They were found while implementing the granular PM, but I am sending them as a separate patches, so they can be reviewed sooner. They fix real issues in the driver that need to be taken care. Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org> --- Changes in v6: - Swap order of patches - Use uvc_ctrl_set_handle again - Move loaded=0 to uvc_ctrl_status_event() - Link to v5: https://lore.kernel.org/r/20241202-uvc-fix-async-v5-0-6658c1fe312b@chromium… Changes in v5: - Move set handle to the entity_commit - Replace uvc_ctrl_set_handle with get/put_handle. - Add a patch to flush the cache of async controls. - Link to v4: https://lore.kernel.org/r/20241129-uvc-fix-async-v4-0-f23784dba80f@chromium… Changes in v4: - Fix implementation of uvc_ctrl_set_handle. - Link to v3: https://lore.kernel.org/r/20241129-uvc-fix-async-v3-0-ab675ce66db7@chromium… Changes in v3: - change again! order of patches. - Introduce uvc_ctrl_set_handle. - Do not change ctrl->handle if it is not NULL. Changes in v2: - Annotate lockdep - ctrl->handle != handle - Change order of patches - Move documentation of mutex - Link to v1: https://lore.kernel.org/r/20241127-uvc-fix-async-v1-0-eb8722531b8c@chromium… --- Ricardo Ribalda (5): media: uvcvideo: Only save async fh if success media: uvcvideo: Remove redundant NULL assignment media: uvcvideo: Remove dangling pointers media: uvcvideo: Annotate lock requirements for uvc_ctrl_set media: uvcvideo: Flush the control cache when we get an event drivers/media/usb/uvc/uvc_ctrl.c | 83 ++++++++++++++++++++++++++++++++++------ drivers/media/usb/uvc/uvc_v4l2.c | 2 + drivers/media/usb/uvc/uvcvideo.h | 9 ++++- 3 files changed, 82 insertions(+), 12 deletions(-) --- base-commit: 291a8d98186f0a704cb954855d2ae3233971f07d change-id: 20241127-uvc-fix-async-2c9d40413ad8 Best regards, -- Ricardo Ribalda <ribalda(a)chromium.org>

12 months

3
8
0 0

[PATCH 5.4 00/24] 5.4.288-rc1 review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.4.288 release. There are 24 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu, 19 Dec 2024 17:05:03 +0000. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.288-rc… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 5.4.288-rc1 Dan Carpenter <dan.carpenter(a)linaro.org> ALSA: usb-audio: Fix a DMA to stack memory bug Juergen Gross <jgross(a)suse.com> xen/netfront: fix crash when removing device Nikolay Kuratov <kniv(a)yandex-team.ru> tracing/kprobes: Skip symbol counting logic for module symbols in create_local_trace_kprobe() Raghavendra Rao Ananta <rananta(a)google.com> KVM: arm64: Ignore PMCNTENSET_EL0 while checking for overflow status Nathan Chancellor <nathan(a)kernel.org> blk-iocost: Avoid using clamp() on inuse in __propagate_weights() Tejun Heo <tj(a)kernel.org> blk-iocost: fix weight updates of inner active iocgs Tejun Heo <tj(a)kernel.org> blk-iocost: clamp inuse and skip noops in __propagate_weights() Daniil Tatianin <d-tatianin(a)yandex-team.ru> ACPICA: events/evxfregn: don't release the ContextMutex that was never acquired Martin Ottens <martin.ottens(a)fau.de> net/sched: netem: account for backlog updates from child qdisc Stefan Wahren <wahrenst(a)gmx.net> qca_spi: Make driver probing reliable Stefan Wahren <wahrenst(a)gmx.net> qca_spi: Fix clock speed for multiple QCA7000 Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> ACPI: resource: Fix memory resource type union access Eric Dumazet <edumazet(a)google.com> net: lapb: increase LAPB_HEADER_LEN Eric Dumazet <edumazet(a)google.com> tipc: fix NULL deref in cleanup_bearer() Remi Pommarel <repk(a)triplefau.lt> batman-adv: Do not let TT changes list grows indefinitely Remi Pommarel <repk(a)triplefau.lt> batman-adv: Remove uninitialized data in full table TT response Remi Pommarel <repk(a)triplefau.lt> batman-adv: Do not send uninitialized TT changes Michal Luczaj <mhal(a)rbox.co> bpf, sockmap: Fix update element with same Darrick J. Wong <djwong(a)kernel.org> xfs: don't drop errno values when we fail to ficlone the entire range Lianqin Hu <hulianqin(a)vivo.com> usb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointer Vitalii Mordan <mordan(a)ispras.ru> usb: ehci-hcd: fix call balance of clocks handling routines Stefan Wahren <wahrenst(a)gmx.net> usb: dwc2: hcd: Fix GetPortStatus & SetPortFeature Joe Hattori <joe(a)pf.is.s.u-tokyo.ac.jp> ata: sata_highbank: fix OF node reference leak in highbank_initialize_phys() Mark Tomlinson <mark.tomlinson(a)alliedtelesis.co.nz> usb: host: max3421-hcd: Correctly abort a USB request. ------------- Diffstat: Makefile | 4 +-- block/blk-iocost.c | 24 ++++++++++++-- drivers/acpi/acpica/evxfregn.c | 2 -- drivers/acpi/resource.c | 6 ++-- drivers/ata/sata_highbank.c | 1 + drivers/net/ethernet/qualcomm/qca_spi.c | 26 +++++++-------- drivers/net/ethernet/qualcomm/qca_spi.h | 1 - drivers/net/xen-netfront.c | 5 ++- drivers/usb/dwc2/hcd.c | 16 ++++----- drivers/usb/gadget/function/u_serial.c | 9 +++-- drivers/usb/host/ehci-sh.c | 9 +++-- drivers/usb/host/max3421-hcd.c | 16 ++++++--- fs/xfs/xfs_file.c | 8 +++++ include/net/lapb.h | 2 +- kernel/trace/trace_kprobe.c | 2 +- net/batman-adv/translation-table.c | 58 +++++++++++++++++++++++---------- net/core/sock_map.c | 1 + net/sched/sch_netem.c | 22 +++++++++---- net/tipc/udp_media.c | 7 +++- sound/usb/quirks.c | 31 ++++++++++++------ virt/kvm/arm/pmu.c | 1 - 21 files changed, 167 insertions(+), 84 deletions(-)

12 months

7
30
0 0

[PATCH] spi: atmel-qspi: Memory barriers after memory-mapped I/O

by Bence Csókás

The QSPI peripheral control and status registers are accessible via the SoC's APB bus, whereas MMIO transactions' data travels on the AHB bus. Microchip documentation and even sample code from Atmel emphasises the need for a memory barrier before the first MMIO transaction to the AHB-connected QSPI, and before the last write to its registers via APB. This is achieved by the following lines in `atmel_qspi_transfer()`: /* Dummy read of QSPI_IFR to synchronize APB and AHB accesses */ (void)atmel_qspi_read(aq, QSPI_IFR); However, the current documentation makes no mention to synchronization requirements in the other direction, i.e. after the last data written via AHB, and before the first register access on APB. --- In our case, we were facing an issue where the QSPI peripheral would cease to send any new CSR (nCS Rise) interrupts, leading to a timeout in `atmel_qspi_wait_for_completion()` and ultimately this panic in higher levels: ubi0 error: ubi_io_write: error -110 while writing 63108 bytes to PEB 491:128, written 63104 bytes After months of extensive research of the codebase, fiddling around the debugger with kgdb, and back-and-forth with Microchip, we came to the conclusion that the issue is probably that the peripheral is still busy receiving on AHB when the LASTXFER bit is written to its Control Register on APB, therefore this write gets lost, and the peripheral still thinks there is more data to come in the MMIO transfer. This was first formulated when we noticed that doubling the write() of QSPI_CR_LASTXFER seemed to solve the problem. Ultimately, the solution is to introduce memory barriers after the AHB-mapped MMIO transfers, to ensure ordering. Fixes: d5433def3153 ("mtd: spi-nor: atmel-quadspi: Add spi-mem support to atmel-quadspi") Cc: Hari.PrasathGE(a)microchip.com Cc: Mahesh.Abotula(a)microchip.com Cc: Marco.Cardellini(a)microchip.com Cc: <stable(a)vger.kernel.org> # c0a0203cf579: ("spi: atmel-quadspi: Create `atmel_qspi_ops`"...) Cc: <stable(a)vger.kernel.org> # 6.x.y Signed-off-by: Bence Csókás <csokas.bence(a)prolan.hu> --- drivers/spi/atmel-quadspi.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c index 73cf0c3f1477..96fc1c56a221 100644 --- a/drivers/spi/atmel-quadspi.c +++ b/drivers/spi/atmel-quadspi.c @@ -625,13 +625,20 @@ static int atmel_qspi_transfer(struct spi_mem *mem, (void)atmel_qspi_read(aq, QSPI_IFR); /* Send/Receive data */ - if (op->data.dir == SPI_MEM_DATA_IN) + if (op->data.dir == SPI_MEM_DATA_IN) { memcpy_fromio(op->data.buf.in, aq->mem + offset, op->data.nbytes); - else + + /* Synchronize AHB and APB accesses again */ + rmb(); + } else { memcpy_toio(aq->mem + offset, op->data.buf.out, op->data.nbytes); + /* Synchronize AHB and APB accesses again */ + wmb(); + } + /* Release the chip-select */ atmel_qspi_write(QSPI_CR_LASTXFER, aq, QSPI_CR); -- 2.34.1

12 months

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2024