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

[PATCH v2] drm/imx/tve: fix probe device leak

by Johan Hovold

Make sure to drop the reference taken to the DDC device during probe on probe failure (e.g. probe deferral) and on driver unbind. Fixes: fcbc51e54d2a ("staging: drm/imx: Add support for Television Encoder (TVEv2)") Cc: stable(a)vger.kernel.org # 3.10 Cc: Philipp Zabel <p.zabel(a)pengutronix.de> Reviewed-by: Frank Li <Frank.Li(a)nxp.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- Changes in v2: - add missing NULL ddc check drivers/gpu/drm/imx/ipuv3/imx-tve.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/gpu/drm/imx/ipuv3/imx-tve.c b/drivers/gpu/drm/imx/ipuv3/imx-tve.c index fd1e617e171e..68bbbdbd347b 100644 --- a/drivers/gpu/drm/imx/ipuv3/imx-tve.c +++ b/drivers/gpu/drm/imx/ipuv3/imx-tve.c @@ -525,6 +525,13 @@ static const struct component_ops imx_tve_ops = { .bind = imx_tve_bind, }; +static void imx_tve_put_device(void *_dev) +{ + struct device *dev = _dev; + + put_device(dev); +} + static int imx_tve_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; @@ -546,6 +553,12 @@ static int imx_tve_probe(struct platform_device *pdev) if (ddc_node) { tve->ddc = of_find_i2c_adapter_by_node(ddc_node); of_node_put(ddc_node); + if (tve->ddc) { + ret = devm_add_action_or_reset(dev, imx_tve_put_device, + &tve->ddc->dev); + if (ret) + return ret; + } } tve->mode = of_get_tve_mode(np); -- 2.51.0

9 hours, 48 minutes

1
1
0 0

[PATCH 1/2] ata: libata-scsi: Fix system suspend for a security locked drive

by Niklas Cassel

Commit cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error() status handling") fixed ata_to_sense_error() to properly generate sense key ABORTED COMMAND (without any additional sense code), instead of the previous bogus sense key ILLEGAL REQUEST with the additional sense code UNALIGNED WRITE COMMAND, for a failed command. However, this broke suspend for Security locked drives (drives that have Security enabled, and have not been Security unlocked by boot firmware). The reason for this is that the SCSI disk driver, for the Synchronize Cache command only, treats any sense data with sense key ILLEGAL REQUEST as a successful command (regardless of ASC / ASCQ). After commit cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error() status handling") the code that treats any sense data with sense key ILLEGAL REQUEST as a successful command is no longer applicable, so the command fails, which causes the system suspend to be aborted: sd 1:0:0:0: PM: dpm_run_callback(): scsi_bus_suspend returns -5 sd 1:0:0:0: PM: failed to suspend async: error -5 PM: Some devices failed to suspend, or early wake event detected To make suspend work once again, for a Security locked device only, return sense data LOGICAL UNIT ACCESS NOT AUTHORIZED, the actual sense data which a real SCSI device would have returned if locked. The SCSI disk driver treats this sense data as a successful command. Cc: stable(a)vger.kernel.org Reported-by: Ilia Baryshnikov <qwelias(a)gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220704 Fixes: cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error() status handling") Signed-off-by: Niklas Cassel <cassel(a)kernel.org> --- drivers/ata/libata-scsi.c | 7 +++++++ include/linux/ata.h | 1 + 2 files changed, 8 insertions(+) diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c index b43a3196e2be..58efa88e4882 100644 --- a/drivers/ata/libata-scsi.c +++ b/drivers/ata/libata-scsi.c @@ -992,6 +992,13 @@ static void ata_gen_ata_sense(struct ata_queued_cmd *qc) return; } + if (ata_id_is_locked(dev->id)) { + /* Security locked */ + /* LOGICAL UNIT ACCESS NOT AUTHORIZED */ + ata_scsi_set_sense(dev, cmd, DATA_PROTECT, 0x74, 0x71); + return; + } + if (!(qc->flags & ATA_QCFLAG_RTF_FILLED)) { ata_dev_dbg(dev, "Missing result TF: reporting aborted command\n"); diff --git a/include/linux/ata.h b/include/linux/ata.h index 792e10a09787..c9013e472aa3 100644 --- a/include/linux/ata.h +++ b/include/linux/ata.h @@ -566,6 +566,7 @@ struct ata_bmdma_prd { #define ata_id_has_ncq(id) ((id)[ATA_ID_SATA_CAPABILITY] & (1 << 8)) #define ata_id_queue_depth(id) (((id)[ATA_ID_QUEUE_DEPTH] & 0x1f) + 1) #define ata_id_removable(id) ((id)[ATA_ID_CONFIG] & (1 << 7)) +#define ata_id_is_locked(id) (((id)[ATA_ID_DLF] & 0x7) == 0x7) #define ata_id_has_atapi_AN(id) \ ((((id)[ATA_ID_SATA_CAPABILITY] != 0x0000) && \ ((id)[ATA_ID_SATA_CAPABILITY] != 0xffff)) && \ -- 2.51.1

10 hours, 13 minutes

4
4
0 0

[PATCH 6.12.y] net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry()

by Chen Yu

From: Vladimir Oltean <vladimir.oltean(a)nxp.com> [ Upstream commit 5f2b28b79d2d1946ee36ad8b3dc0066f73c90481 ] There are actually 2 problems: - deleting the last element doesn't require the memmove of elements [i + 1, end) over it. Actually, element i+1 is out of bounds. - The memmove itself should move size - i - 1 elements, because the last element is out of bounds. The out-of-bounds element still remains out of bounds after being accessed, so the problem is only that we touch it, not that it becomes in active use. But I suppose it can lead to issues if the out-of-bounds element is part of an unmapped page. Fixes: 6666cebc5e30 ("net: dsa: sja1105: Add support for VLAN operations") Signed-off-by: Vladimir Oltean <vladimir.oltean(a)nxp.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://patch.msgid.link/20250318115716.2124395-4-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Chen Yu <xnguchen(a)sina.cn> --- drivers/net/dsa/sja1105/sja1105_static_config.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/dsa/sja1105/sja1105_static_config.c b/drivers/net/dsa/sja1105/sja1105_static_config.c index baba204ad62f..2ac91fe2a79b 100644 --- a/drivers/net/dsa/sja1105/sja1105_static_config.c +++ b/drivers/net/dsa/sja1105/sja1105_static_config.c @@ -1921,8 +1921,10 @@ int sja1105_table_delete_entry(struct sja1105_table *table, int i) if (i > table->entry_count) return -ERANGE; - memmove(entries + i * entry_size, entries + (i + 1) * entry_size, - (table->entry_count - i) * entry_size); + if (i + 1 < table->entry_count) { + memmove(entries + i * entry_size, entries + (i + 1) * entry_size, + (table->entry_count - i - 1) * entry_size); + } table->entry_count--; -- 2.17.1

10 hours, 15 minutes

2
1
0 0

[PATCH v4] usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer

by guhuinan

From: Owen Gu <guhuinan(a)xiaomi.com> When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete(). Fixes: eb2a86ae8c54 ("USB: UAS: fix disconnect by unplugging a hub") Cc: stable(a)vger.kernel.org Signed-off-by: Yu Chen <chenyu45(a)xiaomi.com> Signed-off-by: Owen Gu <guhuinan(a)xiaomi.com> Acked-by: Oliver Neukum <oneukum(a)suse.com> --- v4: Add the fix tag, cc stable and acked-by tag v3: Add some commit message. v2: Upon uas_submit_urbs() returning -ENODEV despite successful URB submission, the cmnd is added to the devinfo->cmnd array before exiting uas_queuecommand_lck(). https://lore.kernel.org/linux-usb/20251015153157.11870-1-guhuinan@xiaomi.co… v1: https://lore.kernel.org/linux-usb/20250930045309.21588-1-guhuinan@xiaomi.co… --- --- drivers/usb/storage/uas.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c index 03043d567fa1..02fe411567fa 100644 --- a/drivers/usb/storage/uas.c +++ b/drivers/usb/storage/uas.c @@ -698,6 +698,10 @@ static int uas_queuecommand_lck(struct scsi_cmnd *cmnd) * of queueing, no matter how fatal the error */ if (err == -ENODEV) { + if (cmdinfo->state & (COMMAND_INFLIGHT | DATA_IN_URB_INFLIGHT | + DATA_OUT_URB_INFLIGHT)) + goto out; + set_host_byte(cmnd, DID_NO_CONNECT); scsi_done(cmnd); goto zombie; @@ -711,6 +715,7 @@ static int uas_queuecommand_lck(struct scsi_cmnd *cmnd) uas_add_work(cmnd); } +out: devinfo->cmnd[idx] = cmnd; zombie: spin_unlock_irqrestore(&devinfo->lock, flags); -- 2.43.0

10 hours, 25 minutes

1
0
0 0

[PATCH REPOST net v2] atm/fore200e: Fix possible data race in fore200e_open()

by Gui-Dong Han

Protect access to fore200e->available_cell_rate with rate_mtx lock to prevent potential data race. In this case, since the update depends on a prior read, a data race could lead to a wrong fore200e.available_cell_rate value. The field fore200e.available_cell_rate is generally protected by the lock fore200e.rate_mtx when accessed. In all other read and write cases, this field is consistently protected by the lock, except for this case and during initialization. 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: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Gui-Dong Han <hanguidong02(a)gmail.com> Reviewed-by: Simon Horman <horms(a)kernel.org> --- v2: * Added a description of the data race hazard in fore200e_open(), as suggested by Jakub Kicinski and Simon Horman. REPOST: * Reposting v2 as it seems to have been overlooked. --- drivers/atm/fore200e.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c index 4fea1149e003..f62e38571440 100644 --- a/drivers/atm/fore200e.c +++ b/drivers/atm/fore200e.c @@ -1374,7 +1374,9 @@ fore200e_open(struct atm_vcc *vcc) vcc->dev_data = NULL; + mutex_lock(&fore200e->rate_mtx); fore200e->available_cell_rate += vcc->qos.txtp.max_pcr; + mutex_unlock(&fore200e->rate_mtx); kfree(fore200e_vcc); return -EINVAL; -- 2.34.1

10 hours, 45 minutes

2
2
0 0

[PATCH v4] usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer

by guhuinan

From: Owen Gu <guhuinan(a)xiaomi.com> When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete(). Fixes: eb2a86ae8c54 ("USB: UAS: fix disconnect by unplugging a hub") Cc: stable(a)vger.kernel.org Signed-off-by: Yu Chen <chenyu45(a)xiaomi.com> Signed-off-by: Owen Gu <guhuinan(a)xiaomi.com> Acked-by: Oliver Neukum <oneukum(a)suse.com> --- v4: Add the fix tag, cc stable and acked-by tag v3: Add some commit message. v2: Upon uas_submit_urbs() returning -ENODEV despite successful URB submission, the cmnd is added to the devinfo->cmnd array before exiting uas_queuecommand_lck(). https://lore.kernel.org/linux-usb/20251015153157.11870-1-guhuinan@xiaomi.co… v1: https://lore.kernel.org/linux-usb/20250930045309.21588-1-guhuinan@xiaomi.co… --- --- drivers/usb/storage/uas.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c index 03043d567fa1..02fe411567fa 100644 --- a/drivers/usb/storage/uas.c +++ b/drivers/usb/storage/uas.c @@ -698,6 +698,10 @@ static int uas_queuecommand_lck(struct scsi_cmnd *cmnd) * of queueing, no matter how fatal the error */ if (err == -ENODEV) { + if (cmdinfo->state & (COMMAND_INFLIGHT | DATA_IN_URB_INFLIGHT | + DATA_OUT_URB_INFLIGHT)) + goto out; + set_host_byte(cmnd, DID_NO_CONNECT); scsi_done(cmnd); goto zombie; @@ -711,6 +715,7 @@ static int uas_queuecommand_lck(struct scsi_cmnd *cmnd) uas_add_work(cmnd); } +out: devinfo->cmnd[idx] = cmnd; zombie: spin_unlock_irqrestore(&devinfo->lock, flags); -- 2.43.0

10 hours, 46 minutes

1
0
0 0

[PATCH AUTOSEL 6.17] ALSA: hda/tas2781: Add new quirk for HP new projects

by Sasha Levin

From: Baojun Xu <baojun.xu(a)ti.com> [ Upstream commit 7a39c723b7472b8aaa2e0a67d2b6c7cf1c45cafb ] Add new vendor_id and subsystem_id in quirk for HP new projects. Signed-off-by: Baojun Xu <baojun.xu(a)ti.com> Link: https://patch.msgid.link/20251108142325.2563-1-baojun.xu@ti.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: Now I have all the information needed for a comprehensive analysis. Let me compile my findings: ## COMPREHENSIVE ANALYSIS ### 1. COMMIT OVERVIEW **Mainline Commit**: 7a39c723b7472b8aaa2e0a67d2b6c7cf1c45cafb **Date**: November 9, 2025 **Author**: Baojun Xu (Texas Instruments - TAS2781 chip manufacturer) **Subject**: "ALSA: hda/tas2781: Add new quirk for HP new projects" **Present in**: v6.18-rc6 ### 2. WHAT THIS COMMIT DOES The commit adds 9 new PCI quirk entries to the Realtek HD-audio codec driver: **6 HP Merino models** (0x103c:0x8ed5 through 0x8eda): - HP Merino13X, Merino13, Merino14, Merino16, Merino14W, Merino16W - Mapped to `ALC245_FIXUP_TAS2781_SPI_2` (TAS2781 via SPI bus) **3 HP Lampas models** (0x103c:0x8f40 through 0x8f42): - HP Lampas14, Lampas16, LampasW14 - Mapped to `ALC287_FIXUP_TAS2781_I2C` (TAS2781 via I2C bus) ### 3. TECHNICAL ANALYSIS - HOW THIS WORKS **The Infrastructure (already exists in 6.17 stable)**: The TAS2781 fixup infrastructure was introduced in commit aeeb85f26c3bbe on July 9, 2025, as part of a major Realtek driver refactoring. I verified it exists in the current 6.17.8 stable tree: - **Fixup functions** at lines 3016-3031: - `tas2781_fixup_tias_i2c()` - sets up I2C-connected TAS2781 chips - `tas2781_fixup_spi()` - sets up SPI-connected TAS2781 chips - **Fixup enum entries** at lines 3704, 3706: - `ALC287_FIXUP_TAS2781_I2C` - `ALC245_FIXUP_TAS2781_SPI_2` - **Fixup implementations** at lines 5979-5990 calling `comp_generic_fixup()` **What happens without this patch**: The `comp_generic_fixup()` function (line 2884) sets up component bindings between the HDA codec driver and the TAS2781 amplifier driver. Without the correct quirk entry mapping the subsystem ID to the fixup: 1. The kernel won't recognize these HP laptop models 2. The TAS2781 audio amplifier chips won't be properly initialized 3. **Audio output (speakers) will not work** on these devices 4. Users will have non-functional hardware This is identical to how CS35L41 amplifiers are handled (lines 2969-2992) - without quirk entries, the hardware doesn't work. ### 4. BUG CLASSIFICATION **Type**: Hardware enablement / Device ID addition **Severity**: HIGH - Complete loss of audio output functionality **Impact**: Users with these specific HP laptop models (new 2025 releases) will have no working speakers ### 5. STABLE KERNEL RULES ASSESSMENT This commit falls squarely into the **ALLOWED EXCEPTION CATEGORIES**: **Category 1: NEW DEVICE IDs** - ✅ Adding subsystem IDs (PCI vendor:device pairs) to existing driver - ✅ The driver (Realtek ALC269) already exists in stable - ✅ The fixup infrastructure (TAS2781 support) already exists in stable - ✅ Only the device IDs are new - trivial one-line additions **Category 2: QUIRKS and WORKAROUNDS** - ✅ Hardware-specific quirks for real devices - ✅ Fixes broken/non-functional hardware (speakers don't work without this) - ✅ Standard pattern used throughout the ALSA subsystem **Comparison to established precedent**: - Similar to commit 1036e9bd513bd "ALSA: hda/realtek: Add quirk entry for HP ZBook 17 G6" (explicitly marked Cc: stable) - Pattern matches dozens of other quirk additions already in stable trees - Same author (Baojun Xu) has submitted multiple similar commits that were backported ### 6. CODE ANALYSIS **Change scope**: MINIMAL and SURGICAL - **9 lines added**, 0 lines removed - Single file modified: `sound/hda/codecs/realtek/alc269.c` - Only touches the quirk table - a static data structure - No logic changes, no API changes, no new functions **Regression risk**: EXTREMELY LOW - Pure data additions to a lookup table - Cannot affect existing hardware (different subsystem IDs) - Only affects users with these exact HP laptop models - If something goes wrong, only affects these 9 specific device configurations - The fixup code being called is already tested and in use by 50+ other devices ### 7. TESTING AND VALIDATION **Mainline stability**: - Committed November 9, 2025 to v6.18-rc6 - Clean commit with proper sign-offs - Author is from Texas Instruments (TAS2781 chip vendor) - Part of ongoing hardware support maintenance **Similar commits already backported**: - Multiple TAS2781 quirk additions already in stable trees - Pattern matches hundreds of similar quirk additions - The ALSA maintainer (Takashi Iwai) approved and signed off ### 8. USER IMPACT **Affected users**: - Owners of HP Merino/Lampas series laptops (2025 models) - These are new commercial/consumer HP products - Without this patch: **Complete audio failure** (speakers don't work) **Benefits of backporting**: - Enables working audio hardware on new devices - Users can run stable kernels without losing functionality - Prevents need for custom patches or mainline-only kernels **Risk of NOT backporting**: - Users with these laptops forced to use mainline kernels (less stable) - Bug reports and support burden for distributions - Poor user experience with "stable" kernels ### 9. DEPENDENCY ANALYSIS **Dependencies**: NONE - all infrastructure exists - TAS2781 fixup functions: ✅ Present in 6.17 stable (verified at lines 3016-3031) - Fixup enum values: ✅ Present in 6.17 stable (verified at lines 3704, 3706) - Component binding infrastructure: ✅ Present (comp_generic_fixup at line 2884) **Backport complexity**: TRIVIAL - Patch applies cleanly to 6.17 stable (already backported to other stable trees) - No context changes needed - Standard quirk table addition ### 10. MAINTAINER SIGNALS - ❌ No explicit "Cc: stable(a)vger.kernel.org" tag - ❌ No "Fixes:" tag (this enables new hardware, doesn't fix a regression) - ✅ But: Fits established pattern of hardware quirks routinely backported - ✅ Already backported to multiple stable trees (commits 05c33655cef92, a612312d5c015) - ✅ Stable maintainer (Sasha Levin) already picked this up for backporting ### 11. FINAL ASSESSMENT This commit is a **textbook example** of hardware quirk additions that stable kernel rules explicitly allow. It: 1. **Fixes real hardware** (non-functional speakers on new HP laptops) 2. **Minimal code change** (9 data-only lines) 3. **Zero regression risk** (only affects 9 specific device IDs) 4. **Infrastructure exists** (all TAS2781 support already in place) 5. **Matches established pattern** (hundreds of similar quirks in stable) 6. **High user benefit** (enables critical hardware functionality) The fact that it lacks explicit stable tags is irrelevant - this type of hardware enablement is routinely backported as part of normal stable tree maintenance. The commit is already being picked up by stable maintainers for multiple trees. **YES** sound/hda/codecs/realtek/alc269.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c index 28297e936a96f..d1b9f43c883c2 100644 --- a/sound/hda/codecs/realtek/alc269.c +++ b/sound/hda/codecs/realtek/alc269.c @@ -6683,6 +6683,15 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x8e60, "HP Trekker ", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x103c, 0x8e61, "HP Trekker ", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x103c, 0x8e62, "HP Trekker ", ALC287_FIXUP_CS35L41_I2C_2), + SND_PCI_QUIRK(0x103c, 0x8ed5, "HP Merino13X", ALC245_FIXUP_TAS2781_SPI_2), + SND_PCI_QUIRK(0x103c, 0x8ed6, "HP Merino13", ALC245_FIXUP_TAS2781_SPI_2), + SND_PCI_QUIRK(0x103c, 0x8ed7, "HP Merino14", ALC245_FIXUP_TAS2781_SPI_2), + SND_PCI_QUIRK(0x103c, 0x8ed8, "HP Merino16", ALC245_FIXUP_TAS2781_SPI_2), + SND_PCI_QUIRK(0x103c, 0x8ed9, "HP Merino14W", ALC245_FIXUP_TAS2781_SPI_2), + SND_PCI_QUIRK(0x103c, 0x8eda, "HP Merino16W", ALC245_FIXUP_TAS2781_SPI_2), + SND_PCI_QUIRK(0x103c, 0x8f40, "HP Lampas14", ALC287_FIXUP_TAS2781_I2C), + SND_PCI_QUIRK(0x103c, 0x8f41, "HP Lampas16", ALC287_FIXUP_TAS2781_I2C), + SND_PCI_QUIRK(0x103c, 0x8f42, "HP LampasW14", ALC287_FIXUP_TAS2781_I2C), SND_PCI_QUIRK(0x1043, 0x1032, "ASUS VivoBook X513EA", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1034, "ASUS GU605C", ALC285_FIXUP_ASUS_GU605_SPI_SPEAKER2_TO_DAC1), SND_PCI_QUIRK(0x1043, 0x103e, "ASUS X540SA", ALC256_FIXUP_ASUS_MIC), -- 2.51.0

10 hours, 51 minutes

1
15
0 0

[PATCH net v3] atm/fore200e: Fix possible data race in fore200e_open()

by Gui-Dong Han

Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Gui-Dong Han <hanguidong02(a)gmail.com> Reviewed-by: Simon Horman <horms(a)kernel.org> --- v3: * Expanded the commit message to describe the specific call paths causing the race, as suggested by Jakub Kicinski and Paolo Abeni. v2: * Added a description of the data race hazard in fore200e_open(), as suggested by Jakub Kicinski and Simon Horman. --- drivers/atm/fore200e.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c index 4fea1149e003..f62e38571440 100644 --- a/drivers/atm/fore200e.c +++ b/drivers/atm/fore200e.c @@ -1374,7 +1374,9 @@ fore200e_open(struct atm_vcc *vcc) vcc->dev_data = NULL; + mutex_lock(&fore200e->rate_mtx); fore200e->available_cell_rate += vcc->qos.txtp.max_pcr; + mutex_unlock(&fore200e->rate_mtx); kfree(fore200e_vcc); return -EINVAL; -- 2.34.1

10 hours, 52 minutes

1
0
0 0

stable 6.6: commit "sched/cpufreq: Rework schedutil governor performance estimation' causes a regression

by Sergey Senozhatsky

Hi, We are observing a performance regression on one of our arm64 boards. We tracked it down to the linux-6.6.y commit ada8d7fa0ad4 ("sched/cpufreq: Rework schedutil governor performance estimation"). UI speedometer benchmark: w/commit: 395 +/-38 w/o commit: 439 +/-14

12 hours, 4 minutes

3
2
0 0

[PATCH net v2 1/1] net: dsa: microchip: lan937x: Fix RGMII delay tuning

by Oleksij Rempel

Correct RGMII delay application logic in lan937x_set_tune_adj(). The function was missing `data16 &= ~PORT_TUNE_ADJ` before setting the new delay value. This caused the new value to be bitwise-OR'd with the existing PORT_TUNE_ADJ field instead of replacing it. For example, when setting the RGMII 2 TX delay on port 4, the intended TUNE_ADJUST value of 0 (RGMII_2_TX_DELAY_2NS) was incorrectly OR'd with the default 0x1B (from register value 0xDA3), leaving the delay at the wrong setting. This patch adds the missing mask to clear the field, ensuring the correct delay value is written. Physical measurements on the RGMII TX lines confirm the fix, showing the delay changing from ~1ns (before change) to ~2ns. While testing on i.MX 8MP showed this was within the platform's timing tolerance, it did not match the intended hardware-characterized value. Fixes: b19ac41faa3f ("net: dsa: microchip: apply rgmii tx and rx delay in phylink mac config") Cc: stable(a)vger.kernel.org Signed-off-by: Oleksij Rempel <o.rempel(a)pengutronix.de> --- drivers/net/dsa/microchip/lan937x_main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/dsa/microchip/lan937x_main.c b/drivers/net/dsa/microchip/lan937x_main.c index b1ae3b9de3d1..5a1496fff445 100644 --- a/drivers/net/dsa/microchip/lan937x_main.c +++ b/drivers/net/dsa/microchip/lan937x_main.c @@ -540,6 +540,7 @@ static void lan937x_set_tune_adj(struct ksz_device *dev, int port, ksz_pread16(dev, port, reg, &data16); /* Update tune Adjust */ + data16 &= ~PORT_TUNE_ADJ; data16 |= FIELD_PREP(PORT_TUNE_ADJ, val); ksz_pwrite16(dev, port, reg, data16); -- 2.47.3

12 hours, 29 minutes

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror