March 2024 - Linux-stable-mirror

[PATCH 00/17] ASoC: SOF: ipc4/Intel: Fix delay reporting (for 6.9 / 6.8)

by Peter Ujfalusi

Hi, The current version of delay reporting code can report incorrect values when paired with a firmware which enables this feature. Unfortunately there are several smaller issues that needed to be addressed to correct the behavior: Wrong information was used for the host side of counter For MTL/LNL used incorrect (in a sense that it was verified only on MTL) link side counter function. The link side counter needs compensation logic if pause/resume is used. The offset values were not refreshed from firmware. Finally, not strictly connected, but the ALSA buffer size needs to be constrained to avoid constant xrun from media players (like mpv) The series applies cleanly for 6.9 and 6.8.y stable, but older stable would need manual backport, but it is questionable if it is needed as MTL/LNL is missing features. Mark, can you pick these patches for the 6.9 cycle as fixes? Regards, Peter --- Peter Ujfalusi (17): ASoC: SOF: Add dsp_max_burst_size_in_ms member to snd_sof_pcm_stream ASoC: SOF: ipc4-topology: Save the DMA maximum burst size for PCMs ASoC: SOF: Intel: hda-pcm: Use dsp_max_burst_size_in_ms to place constraint ASoC: SOF: Intel: hda: Implement get_stream_position (Linear Link Position) ASoC: SOF: Intel: mtl/lnl: Use the generic get_stream_position callback ASoC: SOF: Introduce a new callback pair to be used for PCM delay reporting ASoC: SOF: Intel: Set the dai/host get frame/byte counter callbacks ASoC: SOF: ipc4-pcm: Use the snd_sof_pcm_get_dai_frame_counter() for pcm_delay ASoC: SOF: Intel: hda-common-ops: Do not set the get_stream_position callback ASoC: SOF: Remove the get_stream_position callback ASoC: SOF: ipc4-pcm: Move struct sof_ipc4_timestamp_info definition locally ASoC: SOF: ipc4-pcm: Combine the SOF_IPC4_PIPE_PAUSED cases in pcm_trigger ASoC: SOF: ipc4-pcm: Invalidate the stream_start_offset in PAUSED state ASoC: SOF: sof-pcm: Add pointer callback to sof_ipc_pcm_ops ASoC: SOF: ipc4-pcm: Correct the delay calculation ALSA: hda: Add pplcllpl/u members to hdac_ext_stream ASoC: SOF: Intel: hda: Compensate LLP in case it is not reset include/sound/hdaudio_ext.h | 3 + sound/soc/sof/intel/hda-common-ops.c | 3 + sound/soc/sof/intel/hda-dai-ops.c | 11 ++ sound/soc/sof/intel/hda-pcm.c | 29 ++++ sound/soc/sof/intel/hda-stream.c | 70 ++++++++++ sound/soc/sof/intel/hda.h | 6 + sound/soc/sof/intel/lnl.c | 2 - sound/soc/sof/intel/mtl.c | 14 -- sound/soc/sof/intel/mtl.h | 10 -- sound/soc/sof/ipc4-pcm.c | 191 ++++++++++++++++++++++----- sound/soc/sof/ipc4-priv.h | 14 -- sound/soc/sof/ipc4-topology.c | 22 ++- sound/soc/sof/ops.h | 24 +++- sound/soc/sof/pcm.c | 8 ++ sound/soc/sof/sof-audio.h | 9 +- sound/soc/sof/sof-priv.h | 24 +++- 16 files changed, 351 insertions(+), 89 deletions(-) -- 2.44.0

1 year, 3 months

2
18
0 0

[PATCH v1 1/3] mm/secretmem: fix GUP-fast succeeding on secretmem folios

by David Hildenbrand

folio_is_secretmem() states that secretmem folios cannot be LRU folios: so we may only exit early if we find an LRU folio. Yet, we exit early if we find a folio that is not a secretmem folio. Consequently, folio_is_secretmem() fails to detect secretmem folios and, therefore, we can succeed in grabbing a secretmem folio during GUP-fast, crashing the kernel when we later try reading/writing to the folio, because the folio has been unmapped from the directmap. Reported-by: xingwei lee <xrivendell7(a)gmail.com> Reported-by: yue sun <samsun1006219(a)gmail.com> Closes: https://lore.kernel.org/lkml/CABOYnLyevJeravW=QrH0JUPYEcDN160aZFb7kwndm-J2r… Debugged-by: Miklos Szeredi <miklos(a)szeredi.hu> Reviewed-by: Mike Rapoport (IBM) <rppt(a)kernel.org> Tested-by: Miklos Szeredi <mszeredi(a)redhat.com> Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas") Cc: <stable(a)vger.kernel.org> Signed-off-by: David Hildenbrand <david(a)redhat.com> --- include/linux/secretmem.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h index 35f3a4a8ceb1..6996f1f53f14 100644 --- a/include/linux/secretmem.h +++ b/include/linux/secretmem.h @@ -16,7 +16,7 @@ static inline bool folio_is_secretmem(struct folio *folio) * We know that secretmem pages are not compound and LRU so we can * save a couple of cycles here. */ - if (folio_test_large(folio) || !folio_test_lru(folio)) + if (folio_test_large(folio) || folio_test_lru(folio)) return false; mapping = (struct address_space *) -- 2.43.2

1 year, 3 months

2
2
0 0

[PATCH] drm/i915: Pre-populate the cursor physical dma address

by Ville Syrjala

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Calling i915_gem_object_get_dma_address() from the vblank evade critical section triggers might_sleep(). While we know that we've already pinned the framebuffer and thus i915_gem_object_get_dma_address() will in fact not sleep in this case, it seems reasonable to keep the unconditional might_sleep() for maximum coverage. So let's instead pre-populate the dma address during fb pinning, which all happens before we enter the vblank evade critical section. We can use u32 for the dma address as this class of hardware doesn't support >32bit addresses. Cc: stable(a)vger.kernel.org Fixes: 0225a90981c8 ("drm/i915: Make cursor plane registers unlocked") Link: https://lore.kernel.org/intel-gfx/20240227100342.GAZd2zfmYcPS_SndtO@fat_cra… Reported-by: Borislav Petkov <bp(a)alien8.de> Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/gpu/drm/i915/display/intel_cursor.c | 4 +--- drivers/gpu/drm/i915/display/intel_display_types.h | 1 + drivers/gpu/drm/i915/display/intel_fb_pin.c | 10 ++++++++++ 3 files changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c b/drivers/gpu/drm/i915/display/intel_cursor.c index f8b33999d43f..0d3da55e1c24 100644 --- a/drivers/gpu/drm/i915/display/intel_cursor.c +++ b/drivers/gpu/drm/i915/display/intel_cursor.c @@ -36,12 +36,10 @@ static u32 intel_cursor_base(const struct intel_plane_state *plane_state) { struct drm_i915_private *dev_priv = to_i915(plane_state->uapi.plane->dev); - const struct drm_framebuffer *fb = plane_state->hw.fb; - struct drm_i915_gem_object *obj = intel_fb_obj(fb); u32 base; if (DISPLAY_INFO(dev_priv)->cursor_needs_physical) - base = i915_gem_object_get_dma_address(obj, 0); + base = plane_state->phys_dma_addr; else base = intel_plane_ggtt_offset(plane_state); diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h index 8a35fb6b2ade..68f26a33870b 100644 --- a/drivers/gpu/drm/i915/display/intel_display_types.h +++ b/drivers/gpu/drm/i915/display/intel_display_types.h @@ -728,6 +728,7 @@ struct intel_plane_state { #define PLANE_HAS_FENCE BIT(0) struct intel_fb_view view; + u32 phys_dma_addr; /* for cursor_needs_physical */ /* Plane pxp decryption state */ bool decrypt; diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c b/drivers/gpu/drm/i915/display/intel_fb_pin.c index 7b42aef37d2f..b6df9baf481b 100644 --- a/drivers/gpu/drm/i915/display/intel_fb_pin.c +++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c @@ -255,6 +255,16 @@ int intel_plane_pin_fb(struct intel_plane_state *plane_state) return PTR_ERR(vma); plane_state->ggtt_vma = vma; + + /* + * Pre-populate the dma address before we enter the vblank + * evade critical section as i915_gem_object_get_dma_address() + * will trigger might_sleep() even if it won't actually sleep, + * which is the case when the fb has already been pinned. + */ + if (phys_cursor) + plane_state->phys_dma_addr = + i915_gem_object_get_dma_address(intel_fb_obj(fb), 0); } else { struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb); -- 2.43.2

1 year, 3 months

4
5
0 0

[PATCH 0/7] usb: typec: ucsi: fix several issues manifesting on Qualcomm platforms

by Dmitry Baryshkov

Fix several issues discovered while debugging UCSI implementation on Qualcomm platforms (ucsi_glink). With these patches I was able to get a working Type-C port managament implementation. Tested on SC8280XP (Lenovo X13s laptop) and SM8350-HDK. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> --- Dmitry Baryshkov (7): usb: typec: ucsi: fix race condition in connection change ACK'ing usb: typec: ucsi: acknowledge the UCSI_CCI_NOT_SUPPORTED usb: typec: ucsi: make ACK_CC_CI rules more obvious usb: typec: ucsi: allow non-partner GET_PDOS for Qualcomm devices usb: typec: ucsi: limit the UCSI_NO_PARTNER_PDOS even further usb: typec: ucsi: properly register partner's PD device soc: qcom: pmic_glink: reenable UCSI on sc8280xp drivers/soc/qcom/pmic_glink.c | 1 - drivers/usb/typec/ucsi/ucsi.c | 51 +++++++++++++++++++++++++++++++++---------- 2 files changed, 39 insertions(+), 13 deletions(-) --- base-commit: ea86f16f605361af3779af0e0b4be18614282091 change-id: 20240312-qcom-ucsi-fixes-6578d236b60b Best regards, -- Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org>

1 year, 3 months

3
11
0 0

[PATCH v2] ASoC: tegra: Fix DSPK 16-bit playback

by Sameer Pujar

DSPK configuration is wrong for 16-bit playback and this happens because the client config is always fixed at 24-bit in hw_params(). Fix this by updating the client config to 16-bit for the respective playback. Fixes: 327ef6470266 ("ASoC: tegra: Add Tegra186 based DSPK driver") Cc: stable(a)vger.kernel.org Signed-off-by: Sameer Pujar <spujar(a)nvidia.com> --- changes in v2: * moved common setting to S32_LE switch case. sound/soc/tegra/tegra186_dspk.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/sound/soc/tegra/tegra186_dspk.c b/sound/soc/tegra/tegra186_dspk.c index aa37c4ab0adb..21cd41fec7a9 100644 --- a/sound/soc/tegra/tegra186_dspk.c +++ b/sound/soc/tegra/tegra186_dspk.c @@ -1,8 +1,7 @@ // SPDX-License-Identifier: GPL-2.0-only +// SPDX-FileCopyrightText: Copyright (c) 2020-2024 NVIDIA CORPORATION & AFFILIATES. All rights reserved. // // tegra186_dspk.c - Tegra186 DSPK driver -// -// Copyright (c) 2020 NVIDIA CORPORATION. All rights reserved. #include <linux/clk.h> #include <linux/device.h> @@ -241,14 +240,14 @@ static int tegra186_dspk_hw_params(struct snd_pcm_substream *substream, return -EINVAL; } - cif_conf.client_bits = TEGRA_ACIF_BITS_24; - switch (params_format(params)) { case SNDRV_PCM_FORMAT_S16_LE: cif_conf.audio_bits = TEGRA_ACIF_BITS_16; + cif_conf.client_bits = TEGRA_ACIF_BITS_16; break; case SNDRV_PCM_FORMAT_S32_LE: cif_conf.audio_bits = TEGRA_ACIF_BITS_32; + cif_conf.client_bits = TEGRA_ACIF_BITS_24; break; default: dev_err(dev, "unsupported format!\n"); -- 2.25.1

1 year, 3 months

1
0
0 0

[PATCH v6 1/2] driver core: Introduce device_link_wait_removal()

by Herve Codina

The commit 80dd33cf72d1 ("drivers: base: Fix device link removal") introduces a workqueue to release the consumer and supplier devices used in the devlink. In the job queued, devices are release and in turn, when all the references to these devices are dropped, the release function of the device itself is called. Nothing is present to provide some synchronisation with this workqueue in order to ensure that all ongoing releasing operations are done and so, some other operations can be started safely. For instance, in the following sequence: 1) of_platform_depopulate() 2) of_overlay_remove() During the step 1, devices are released and related devlinks are removed (jobs pushed in the workqueue). During the step 2, OF nodes are destroyed but, without any synchronisation with devlink removal jobs, of_overlay_remove() can raise warnings related to missing of_node_put(): ERROR: memory leak, expected refcount 1 instead of 2 Indeed, the missing of_node_put() call is going to be done, too late, from the workqueue job execution. Introduce device_link_wait_removal() to offer a way to synchronize operations waiting for the end of devlink removals (i.e. end of workqueue jobs). Also, as a flushing operation is done on the workqueue, the workqueue used is moved from a system-wide workqueue to a local one. Cc: stable(a)vger.kernel.org Signed-off-by: Herve Codina <herve.codina(a)bootlin.com> Tested-by: Luca Ceresoli <luca.ceresoli(a)bootlin.com> Reviewed-by: Nuno Sa <nuno.sa(a)analog.com> Reviewed-by: Saravana Kannan <saravanak(a)google.com> --- drivers/base/core.c | 26 +++++++++++++++++++++++--- include/linux/device.h | 1 + 2 files changed, 24 insertions(+), 3 deletions(-) diff --git a/drivers/base/core.c b/drivers/base/core.c index 7e3af0ad770a..f2242aadffb0 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -44,6 +44,7 @@ static bool fw_devlink_is_permissive(void); static void __fw_devlink_link_to_consumers(struct device *dev); static bool fw_devlink_drv_reg_done; static bool fw_devlink_best_effort; +static struct workqueue_struct *device_link_wq; /** * __fwnode_link_add - Create a link between two fwnode_handles. @@ -533,12 +534,26 @@ static void devlink_dev_release(struct device *dev) /* * It may take a while to complete this work because of the SRCU * synchronization in device_link_release_fn() and if the consumer or - * supplier devices get deleted when it runs, so put it into the "long" - * workqueue. + * supplier devices get deleted when it runs, so put it into the + * dedicated workqueue. */ - queue_work(system_long_wq, &link->rm_work); + queue_work(device_link_wq, &link->rm_work); } +/** + * device_link_wait_removal - Wait for ongoing devlink removal jobs to terminate + */ +void device_link_wait_removal(void) +{ + /* + * devlink removal jobs are queued in the dedicated work queue. + * To be sure that all removal jobs are terminated, ensure that any + * scheduled work has run to completion. + */ + flush_workqueue(device_link_wq); +} +EXPORT_SYMBOL_GPL(device_link_wait_removal); + static struct class devlink_class = { .name = "devlink", .dev_groups = devlink_groups, @@ -4165,9 +4180,14 @@ int __init devices_init(void) sysfs_dev_char_kobj = kobject_create_and_add("char", dev_kobj); if (!sysfs_dev_char_kobj) goto char_kobj_err; + device_link_wq = alloc_workqueue("device_link_wq", 0, 0); + if (!device_link_wq) + goto wq_err; return 0; + wq_err: + kobject_put(sysfs_dev_char_kobj); char_kobj_err: kobject_put(sysfs_dev_block_kobj); block_kobj_err: diff --git a/include/linux/device.h b/include/linux/device.h index 1795121dee9a..d7d8305a72e8 100644 --- a/include/linux/device.h +++ b/include/linux/device.h @@ -1249,6 +1249,7 @@ void device_link_del(struct device_link *link); void device_link_remove(void *consumer, struct device *supplier); void device_links_supplier_sync_state_pause(void); void device_links_supplier_sync_state_resume(void); +void device_link_wait_removal(void); /* Create alias, so I can be autoloaded. */ #define MODULE_ALIAS_CHARDEV(major,minor) \ -- 2.44.0

1 year, 3 months

4
6
0 0

[PATCH] ASoC: tegra: Fix DSPK 16-bit playback

by Sameer Pujar

DSPK configuration is wrong for 16-bit playback and this happens because the client config is always fixed at 24-bit in hw_params(). Fix this by updating the client config to 16-bit for the respective playback. Fixes: 327ef6470266 ("ASoC: tegra: Add Tegra186 based DSPK driver") Cc: stable(a)vger.kernel.org Signed-off-by: Sameer Pujar <spujar(a)nvidia.com> --- sound/soc/tegra/tegra186_dspk.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/tegra/tegra186_dspk.c b/sound/soc/tegra/tegra186_dspk.c index aa37c4ab0adb..3a152e76122b 100644 --- a/sound/soc/tegra/tegra186_dspk.c +++ b/sound/soc/tegra/tegra186_dspk.c @@ -1,8 +1,7 @@ // SPDX-License-Identifier: GPL-2.0-only +// SPDX-FileCopyrightText: Copyright (c) 2020-2024 NVIDIA CORPORATION & AFFILIATES. All rights reserved. // // tegra186_dspk.c - Tegra186 DSPK driver -// -// Copyright (c) 2020 NVIDIA CORPORATION. All rights reserved. #include <linux/clk.h> #include <linux/device.h> @@ -246,6 +245,7 @@ static int tegra186_dspk_hw_params(struct snd_pcm_substream *substream, switch (params_format(params)) { case SNDRV_PCM_FORMAT_S16_LE: cif_conf.audio_bits = TEGRA_ACIF_BITS_16; + cif_conf.client_bits = TEGRA_ACIF_BITS_16; break; case SNDRV_PCM_FORMAT_S32_LE: cif_conf.audio_bits = TEGRA_ACIF_BITS_32; -- 2.25.1

1 year, 3 months

2
2
0 0

[PATCH] scsi: core: Fix unremoved procfs host directory regression

by Guilherme G. Piccoli

Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name} directory earlier") fixed a bug related to modules loading/unloading, by adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led to a potential duplicate call to the hostdir_rm() routine, since it's also called from scsi_host_dev_release(). That triggered a regression report, which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host directory removal regression"). The fix just dropped the hostdir_rm() call from dev_release(). But happens that this proc directory is created on scsi_host_alloc(), and that function "pairs" with scsi_host_dev_release(), while scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the reason for removing the proc directory on dev_release() was meant to cover cases in which a SCSI host structure was allocated, but the call to scsi_add_host() didn't happen. And that pattern happens to exist in some error paths, for example. Syzkaller causes that by using USB raw gadget device, error'ing on usb-storage driver, at usb_stor_probe2(). By checking that path, we can see that the BadDevice label leads to a scsi_host_put() after a SCSI host allocation, but there's no call to scsi_add_host() in such path. That leads to messages like this in dmesg (and a leak of the SCSI host proc structure): usb-storage 4-1:87.51: USB Mass Storage device detected proc_dir_entry 'scsi/usb-storage' already registered WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376 The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(), but guard that with the state check for SHOST_CREATED; there is even a comment in scsi_host_dev_release() detailing that: such conditional is meant for cases where the SCSI host was allocated but there was no calls to {add,remove}_host(), like the usb-storage case. This is what we propose here and with that, the error path of usb-storage does not trigger the warning anymore. Reported-by: syzbot+c645abf505ed21f931b5(a)syzkaller.appspotmail.com Fixes: be03df3d4bfe ("scsi: core: Fix a procfs host directory removal regression") Cc: stable(a)vger.kernel.org Cc: Bart Van Assche <bvanassche(a)acm.org> Cc: John Garry <john.g.garry(a)oracle.com> Cc: Shin'ichiro Kawasaki <shinichiro.kawasaki(a)wdc.com> Signed-off-by: Guilherme G. Piccoli <gpiccoli(a)igalia.com> --- Hi folks, thanks in advance for reviews. The issue with usb-storage happens upstream but despite we have a repro in the aforementioned Syzkaller report, it's only easy to reproduce the proc_dir_entry warning in a timely manner on stable right now. The reason for that is commit 036abd614007 ("scsi: core: Introduce a new list for SCSI proc directory entries") not being present on stable. This commit (indirectly) bumps the ->present field from unsigned char to uint, and the bug reproducer shows the warning whenever such field overflows, hence it's way easier/faster to see this problem in stable, though it's present in latest v6.8.0 too. Cheers, Guilherme drivers/scsi/hosts.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c index d7f51b84f3c7..445f4a220df3 100644 --- a/drivers/scsi/hosts.c +++ b/drivers/scsi/hosts.c @@ -353,12 +353,13 @@ static void scsi_host_dev_release(struct device *dev) if (shost->shost_state == SHOST_CREATED) { /* - * Free the shost_dev device name here if scsi_host_alloc() - * and scsi_host_put() have been called but neither + * Free the shost_dev device name and remove the proc host dir + * here if scsi_host_{alloc,put}() have been called but neither * scsi_host_add() nor scsi_remove_host() has been called. * This avoids that the memory allocated for the shost_dev - * name is leaked. + * name as well as the proc dir structure are leaked. */ + scsi_proc_hostdir_rm(shost->hostt); kfree(dev_name(&shost->shost_dev)); } -- 2.43.0

1 year, 3 months

3
2
0 0

[PATCH] scsi: sg: Avoid sg device teardown race

by Alexander Wetzel

sg_remove_sfp_usercontext() must not use sg_device_destroy() after calling scsi_device_put(). sg_device_destroy() is accessling the device queue. Which will be set to NULL if scsi_device_put() removes the last reference to the sg device. Link: https://lore.kernel.org/r/20240305150509.23896-1-Alexander@wetzel-home.de Cc: <stable(a)vger.kernel.org> Signed-off-by: Alexander Wetzel <Alexander(a)wetzel-home.de> --- This is my best shot for a real fix of the issue. I confirmed with printk's that I get the NULL pointer freeze ony when scsi_device_put() is deleting the last reference to the device. In the cases where it's not crashing there is still a reference left after the call. I don't see any obvious down side of simply swapping the calls. The alternative would by my first patch, just without the WARN_ON. Alexander --- drivers/scsi/sg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c index 86210e4dd0d3..80e0d1981191 100644 --- a/drivers/scsi/sg.c +++ b/drivers/scsi/sg.c @@ -2232,8 +2232,8 @@ sg_remove_sfp_usercontext(struct work_struct *work) "sg_remove_sfp: sfp=0x%p\n", sfp)); kfree(sfp); - scsi_device_put(sdp->device); kref_put(&sdp->d_ref, sg_device_destroy); + scsi_device_put(sdp->device); module_put(THIS_MODULE); } -- 2.44.0

1 year, 3 months

5
10
0 0

DHL International Shipping Notification Arrival

by DHL International

1 year, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2024