October 2024 - Linux-stable-mirror

FAILED: patch "[PATCH] xhci: Mitigate failed set dequeue pointer commands" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x fe49df60cdb7c2975aa743dc295f8786e4b7db10 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024102120-valid-uncured-dcca@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From fe49df60cdb7c2975aa743dc295f8786e4b7db10 Mon Sep 17 00:00:00 2001 From: Mathias Nyman <mathias.nyman(a)linux.intel.com> Date: Wed, 16 Oct 2024 16:59:58 +0300 Subject: [PATCH] xhci: Mitigate failed set dequeue pointer commands Avoid xHC host from processing a cancelled URB by always turning cancelled URB TDs into no-op TRBs before queuing a 'Set TR Deq' command. If the command fails then xHC will start processing the cancelled TD instead of skipping it once endpoint is restarted, causing issues like Babble error. This is not a complete solution as a failed 'Set TR Deq' command does not guarantee xHC TRB caches are cleared. Fixes: 4db356924a50 ("xhci: turn cancelled td cleanup to its own function") Cc: stable(a)vger.kernel.org Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Link: https://lore.kernel.org/r/20241016140000.783905-3-mathias.nyman@linux.intel… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 4d664ba53fe9..7dedf31bbddd 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -1023,7 +1023,7 @@ static int xhci_invalidate_cancelled_tds(struct xhci_virt_ep *ep) td_to_noop(xhci, ring, cached_td, false); cached_td->cancel_status = TD_CLEARED; } - + td_to_noop(xhci, ring, td, false); td->cancel_status = TD_CLEARING_CACHE; cached_td = td; break;

2 months, 2 weeks

1
0
0 0

Pls pick up two bluetooth fixes

by Thorsten Leemhuis

Hi Greg! Please consider picking up the following two bluetooth fixes for the next round of stable updates, they fix problems quite a few users hit in various stable series due to backports: 4084286151fc91 ("Bluetooth: btusb: Fix not being able to reconnect after suspend") [v6.12-rc4] for 6.11.y and 2c1dda2acc4192 ("Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001") [v6.12-rc4] for 5.10.y and later For details see also: https://lore.kernel.org/all/CABBYNZL0_j4EDWzDS=kXc1Vy0D6ToU+oYnP_uBWTKoXbEa… tia! Ciao, Thorsten

2 months, 2 weeks

2
1
0 0

[PATCH] ALSA: hda/tas2781: select CRC32 instead of CRC32_SARWATE

by Eric Biggers

From: Eric Biggers <ebiggers(a)google.com> Fix the kconfig option for the tas2781 HDA driver to select CRC32 rather than CRC32_SARWATE. CRC32_SARWATE is an option from the kconfig 'choice' that selects the specific CRC32 implementation. Selecting a 'choice' option seems to have no effect, but even if it did work, it would be incorrect for a random driver to override the user's choice. CRC32 is the correct option to select for crc32() to be available. Fixes: 5be27f1e3ec9 ("ALSA: hda/tas2781: Add tas2781 HDA driver") Cc: stable(a)vger.kernel.org Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- sound/pci/hda/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/hda/Kconfig b/sound/pci/hda/Kconfig index bb15a0248250c..68f1eee9e5c93 100644 --- a/sound/pci/hda/Kconfig +++ b/sound/pci/hda/Kconfig @@ -196,11 +196,11 @@ config SND_HDA_SCODEC_TAS2781_I2C depends on ACPI depends on EFI depends on SND_SOC select SND_SOC_TAS2781_COMLIB select SND_SOC_TAS2781_FMWLIB - select CRC32_SARWATE + select CRC32 help Say Y or M here to include TAS2781 I2C HD-audio side codec support in snd-hda-intel driver, such as ALC287. comment "Set to Y if you want auto-loading the side codec driver" base-commit: 715ca9dd687f89ddaac8ec8ccb3b5e5a30311a99 -- 2.47.0

2 months, 2 weeks

2
1
0 0

FAILED: patch "[PATCH] iio: adc: ti-lmp92064: add missing select" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD git cherry-pick -x a985576af824426e33100554a5958a6beda60a1 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024102110-tableful-unnatural-5dab@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From a985576af824426e33100554a5958a6beda60a13 Mon Sep 17 00:00:00 2001 From: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> Date: Thu, 3 Oct 2024 23:04:52 +0200 Subject: [PATCH] iio: adc: ti-lmp92064: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig This driver makes use of triggered buffers, but does not select the required modules. Add the missing 'select IIO_BUFFER' and 'select IIO_TRIGGERED_BUFFER'. Fixes: 6c7bc1d27bb2 ("iio: adc: ti-lmp92064: add buffering support") Signed-off-by: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> Link: https://patch.msgid.link/20241003-iio-select-v1-6-67c0385197cd@gmail.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index 68640fa26f4e..c1197ee3dc68 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -1530,6 +1530,8 @@ config TI_LMP92064 tristate "Texas Instruments LMP92064 ADC driver" depends on SPI select REGMAP_SPI + select IIO_BUFFER + select IIO_TRIGGERED_BUFFER help Say yes here to build support for the LMP92064 Precision Current and Voltage sensor.

2 months, 2 weeks

1
0
0 0

6.6.57-stable regression: "netfilter: xtables: avoid NFPROTO_UNSPEC where needed" broke NFLOG on IPv6

by Krzysztof Olędzki

Hi, After upgrading to 6.6.57 I noticed that my IPv6 firewall config failed to load. Quick investigation flagged NFLOG to be the issue: # ip6tables -I INPUT -j NFLOG Warning: Extension NFLOG revision 0 not supported, missing kernel module? ip6tables: No chain/target/match by that name. The regression is caused by the following commit: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/… More precisely, the bug is in the change below: +#if IS_ENABLED(CONFIG_IP6_NF_IPTABLES) + { + .name = "NFLOG", + .revision = 0, + .family = NFPROTO_IPV4, + .checkentry = nflog_tg_check, + .destroy = nflog_tg_destroy, + .target = nflog_tg, + .targetsize = sizeof(struct xt_nflog_info), + .me = THIS_MODULE, + }, +#endif Replacing NFPROTO_IPV4 with NFPROTO_IPV6 fixed the issue. Looking at the commit, it seems that at least one more target (MARK) may be also impacted: +#if IS_ENABLED(CONFIG_IP6_NF_IPTABLES) + { + .name = "MARK", + .revision = 2, + .family = NFPROTO_IPV4, + .target = mark_tg, + .targetsize = sizeof(struct xt_mark_tginfo2), + .me = THIS_MODULE, + }, +#endif The same errors seem to be present in the main tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… I also suspect other -stable trees may be impacted by the same issue. Best regards, Krzysztof Olędzki

2 months, 2 weeks

3
3
0 0

[PATCH] iio: invensense: fix multiple odr switch when FIFO is off

by Jean-Baptiste Maneyrol via B4 Relay

From: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol(a)tdk.com> When multiple ODR switch happens during FIFO off, the change could not be taken into account if you get back to previous FIFO on value. For example, if you run sensor buffer at 50Hz, stop, change to 200Hz, then back to 50Hz and restart buffer, data will be timestamped at 200Hz. This due to testing against mult and not new_mult. To prevent this, let's just run apply_odr automatically when FIFO is off. It will also simplify driver code. Update inv_mpu6050 and inv_icm42600 to delete now useless apply_odr. Fixes: 95444b9eeb8c ("iio: invensense: fix odr switching to same value") Cc: stable(a)vger.kernel.org Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol(a)tdk.com> --- drivers/iio/common/inv_sensors/inv_sensors_timestamp.c | 4 ++++ drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c | 1 - drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c | 1 - drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c | 1 - 4 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/iio/common/inv_sensors/inv_sensors_timestamp.c b/drivers/iio/common/inv_sensors/inv_sensors_timestamp.c index f44458c380d92823ce2e7e5f78ca877ea4c06118..37d0bdaa8d824f79dcd2f341be7501d249926951 100644 --- a/drivers/iio/common/inv_sensors/inv_sensors_timestamp.c +++ b/drivers/iio/common/inv_sensors/inv_sensors_timestamp.c @@ -70,6 +70,10 @@ int inv_sensors_timestamp_update_odr(struct inv_sensors_timestamp *ts, if (mult != ts->mult) ts->new_mult = mult; + /* When FIFO is off, directly apply the new ODR */ + if (!fifo) + inv_sensors_timestamp_apply_odr(ts, 0, 0, 0); + return 0; } EXPORT_SYMBOL_NS_GPL(inv_sensors_timestamp_update_odr, IIO_INV_SENSORS_TIMESTAMP); diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c index 56ac198142500a2e1fc40b62cdd465cc736d8bf0..d061a64ebbf71859a3bc44644a14137dff0f9efe 100644 --- a/drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c @@ -229,7 +229,6 @@ static int inv_icm42600_accel_update_scan_mode(struct iio_dev *indio_dev, } /* update data FIFO write */ - inv_sensors_timestamp_apply_odr(ts, 0, 0, 0); ret = inv_icm42600_buffer_set_fifo_en(st, fifo_en | st->fifo.en); out_unlock: diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c index 938af5b640b00f58d2b8185f752c4755edfb0d25..f1e5a9648c4f5dd34f40136d02c72c90473eff37 100644 --- a/drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c @@ -128,7 +128,6 @@ static int inv_icm42600_gyro_update_scan_mode(struct iio_dev *indio_dev, } /* update data FIFO write */ - inv_sensors_timestamp_apply_odr(ts, 0, 0, 0); ret = inv_icm42600_buffer_set_fifo_en(st, fifo_en | st->fifo.en); out_unlock: diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c index 3bfeabab0ec4f6fa28fbbcd47afe92af5b8a58e2..5b1088cc3704f1ad1288a0d65b2f957b91455d7f 100644 --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c @@ -112,7 +112,6 @@ int inv_mpu6050_prepare_fifo(struct inv_mpu6050_state *st, bool enable) if (enable) { /* reset timestamping */ inv_sensors_timestamp_reset(&st->timestamp); - inv_sensors_timestamp_apply_odr(&st->timestamp, 0, 0, 0); /* reset FIFO */ d = st->chip_config.user_ctrl | INV_MPU6050_BIT_FIFO_RST; ret = regmap_write(st->map, st->reg->user_ctrl, d); --- base-commit: c3e9df514041ec6c46be83801b1891392f4522f7 change-id: 20241017-invn-inv-sensors-timestamp-fix-switch-fifo-off-3f29110e95d0 Best regards, -- Jean-Baptiste Maneyrol <jean-baptiste.maneyrol(a)tdk.com>

2 months, 3 weeks

3
2
0 0

No sound on speakers X1 Carbon Gen 12

by Dean Matthew Menezes

I am not getting sound on the speakers on my Thinkpad X1 Carbon Gen 12 with kernel 6.11.2 The sound is working in kernel 6.8 Dean Menezes

2 months, 3 weeks

4
10
0 0

[PATCH v3] netfilter: xtables: fix a bunch of typos causing some targets to not load on IPv6

by Ilya Katsnelson

The xt_NFLOG and xt_MARK changes were added with the wrong family in 0bfcb7b71e73, which seems to just have been a typo, but now ip6tables rules with --set-mark don't work anymore, which is pretty bad. Pablo spotted another typo introduced in the same commit in xt_TRACE. Fixes: 0bfcb7b71e73 ("netfilter: xtables: avoid NFPROTO_UNSPEC where needed") Reviewed-by: Phil Sutter <phil(a)nwl.cc> Signed-off-by: Ilya Katsnelson <me(a)0upti.me> --- Changes in v3: - Fix another typo spotted by Pablo, adjust text accordingly. - CCing stable because it's a pretty bad regression. - Link to v2: https://lore.kernel.org/r/20241019-xtables-typos-v2-1-6b8b1735dc8e@0upti.me Changes in v2: - Fixed a typo in the commit message (that's karma). - Replaced a reference to backport commit. - Link to v1: https://lore.kernel.org/r/20241018-xtables-typos-v1-1-02a51789c0ec@0upti.me --- net/netfilter/xt_NFLOG.c | 2 +- net/netfilter/xt_TRACE.c | 1 + net/netfilter/xt_mark.c | 2 +- 3 files changed, 3 insertions(+), 2 deletions(-) diff --git a/net/netfilter/xt_NFLOG.c b/net/netfilter/xt_NFLOG.c index d80abd6ccaf8f71fa70605fef7edada827a19ceb..6dcf4bc7e30b2ae364a1cd9ac8df954a90905c52 100644 --- a/net/netfilter/xt_NFLOG.c +++ b/net/netfilter/xt_NFLOG.c @@ -79,7 +79,7 @@ static struct xt_target nflog_tg_reg[] __read_mostly = { { .name = "NFLOG", .revision = 0, - .family = NFPROTO_IPV4, + .family = NFPROTO_IPV6, .checkentry = nflog_tg_check, .destroy = nflog_tg_destroy, .target = nflog_tg, diff --git a/net/netfilter/xt_TRACE.c b/net/netfilter/xt_TRACE.c index f3fa4f11348cd8ad796ce94f012cd48aa7a9020f..2a029b4adbcadf95e493b153f613a210624a9101 100644 --- a/net/netfilter/xt_TRACE.c +++ b/net/netfilter/xt_TRACE.c @@ -49,6 +49,7 @@ static struct xt_target trace_tg_reg[] __read_mostly = { .target = trace_tg, .checkentry = trace_tg_check, .destroy = trace_tg_destroy, + .me = THIS_MODULE, }, #endif }; diff --git a/net/netfilter/xt_mark.c b/net/netfilter/xt_mark.c index f76fe04fc9a4e19f18ac323349ba6f22a00eafd7..65b965ca40ea7ea5d9feff381b433bf267a424c4 100644 --- a/net/netfilter/xt_mark.c +++ b/net/netfilter/xt_mark.c @@ -62,7 +62,7 @@ static struct xt_target mark_tg_reg[] __read_mostly = { { .name = "MARK", .revision = 2, - .family = NFPROTO_IPV4, + .family = NFPROTO_IPV6, .target = mark_tg, .targetsize = sizeof(struct xt_mark_tginfo2), .me = THIS_MODULE, --- base-commit: 75aa74d52f43e75d0beb20572f98529071b700e5 change-id: 20241018-xtables-typos-dfeadb8b122d Best regards, -- Ilya Katsnelson <me(a)0upti.me>

2 months, 3 weeks

3
2
0 0

[PATCH] usb: typec: qcom-pmic-typec: fix missing fwnode removal in error path

by Javier Carrasco

If drm_dp_hpd_bridge_register() fails, the probe function returns without removing the fwnode via fwnode_remove_software_node(), leaking the resource. Jump to fwnode_remove if drm_dp_hpd_bridge_register() fails to remove the software node acquired with device_get_named_child_node(). Cc: stable(a)vger.kernel.org Fixes: 7d9f1b72b296 ("usb: typec: qcom-pmic-typec: switch to DRM_AUX_HPD_BRIDGE") Signed-off-by: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> --- drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c b/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c index 2201eeae5a99..776fc7f93f37 100644 --- a/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c +++ b/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c @@ -93,8 +93,10 @@ static int qcom_pmic_typec_probe(struct platform_device *pdev) return -EINVAL; bridge_dev = devm_drm_dp_hpd_bridge_alloc(tcpm->dev, to_of_node(tcpm->tcpc.fwnode)); - if (IS_ERR(bridge_dev)) - return PTR_ERR(bridge_dev); + if (IS_ERR(bridge_dev)) { + ret = PTR_ERR(bridge_dev); + goto fwnode_remove; + } tcpm->tcpm_port = tcpm_register_port(tcpm->dev, &tcpm->tcpc); if (IS_ERR(tcpm->tcpm_port)) { --- base-commit: f2493655d2d3d5c6958ed996b043c821c23ae8d3 change-id: 20241019-qcom_pmic_typec-fwnode_remove-00dc49054cf7 Best regards, -- Javier Carrasco <javier.carrasco.cruz(a)gmail.com>

2 months, 3 weeks

2
2
0 0

[PATCH] PCI: endpoint: Fix API devm_pci_epc_destroy() can not destroy the EPC device

by Zijun Hu

From: Zijun Hu <quic_zijuhu(a)quicinc.com> For devm_pci_epc_destroy(), its comment says it needs to destroy the EPC device, but it does not do that actually, so it can not fully undo what the API devm_pci_epc_create() does, that is wrong, fixed by using devres_release() instead of devres_destroy() within the API. Fixes: 5e8cb4033807 ("PCI: endpoint: Add EP core layer to enable EP controller and EP functions") Cc: stable(a)vger.kernel.org Signed-off-by: Zijun Hu <quic_zijuhu(a)quicinc.com> --- drivers/pci/endpoint/pci-epc-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c index 17f007109255..71b6d100056e 100644 --- a/drivers/pci/endpoint/pci-epc-core.c +++ b/drivers/pci/endpoint/pci-epc-core.c @@ -857,7 +857,7 @@ void devm_pci_epc_destroy(struct device *dev, struct pci_epc *epc) { int r; - r = devres_destroy(dev, devm_pci_epc_release, devm_pci_epc_match, + r = devres_release(dev, devm_pci_epc_release, devm_pci_epc_match, epc); dev_WARN_ONCE(dev, r, "couldn't find PCI EPC resource\n"); } --- base-commit: 715ca9dd687f89ddaac8ec8ccb3b5e5a30311a99 change-id: 20241020-pci-epc-core_fix-a92512fa9d19 Best regards, -- Zijun Hu <quic_zijuhu(a)quicinc.com>

2 months, 3 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2024