The patch below does not apply to the 5.15-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.15.y
git checkout FETCH_HEAD
git cherry-pick -x e84cb860ac3ce67ec6ecc364433fd5b412c448bc
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102646-unwary-premises-4a2c@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From e84cb860ac3ce67ec6ecc364433fd5b412c448bc Mon Sep 17 00:00:00 2001
From: "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org>
Date: Mon, 20 Oct 2025 22:53:26 +0200
Subject: [PATCH] mptcp: pm: in-kernel: C-flag: handle late ADD_ADDR
The special C-flag case expects the ADD_ADDR to be received when
switching to 'fully-established'. But for various reasons, the ADD_ADDR
could be sent after the "4th ACK", and the special case doesn't work.
On NIPA, the new test validating this special case for the C-flag failed
a few times, e.g.
102 default limits, server deny join id 0
syn rx [FAIL] got 0 JOIN[s] syn rx expected 2
Server ns stats
(...)
MPTcpExtAddAddrTx 1
MPTcpExtEchoAdd 1
Client ns stats
(...)
MPTcpExtAddAddr 1
MPTcpExtEchoAddTx 1
synack rx [FAIL] got 0 JOIN[s] synack rx expected 2
ack rx [FAIL] got 0 JOIN[s] ack rx expected 2
join Rx [FAIL] see above
syn tx [FAIL] got 0 JOIN[s] syn tx expected 2
join Tx [FAIL] see above
I had a suspicion about what the issue could be: the ADD_ADDR might have
been received after the switch to the 'fully-established' state. The
issue was not easy to reproduce. The packet capture shown that the
ADD_ADDR can indeed be sent with a delay, and the client would not try
to establish subflows to it as expected.
A simple fix is not to mark the endpoints as 'used' in the C-flag case,
when looking at creating subflows to the remote initial IP address and
port. In this case, there is no need to try.
Note: newly added fullmesh endpoints will still continue to be used as
expected, thanks to the conditions behind mptcp_pm_add_addr_c_flag_case.
Fixes: 4b1ff850e0c1 ("mptcp: pm: in-kernel: usable client side with C-flag")
Cc: stable(a)vger.kernel.org
Reviewed-by: Geliang Tang <geliang(a)kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org>
Link: https://patch.msgid.link/20251020-net-mptcp-c-flag-late-add-addr-v1-1-82070…
Signed-off-by: Jakub Kicinski <kuba(a)kernel.org>
diff --git a/net/mptcp/pm_kernel.c b/net/mptcp/pm_kernel.c
index e0f44dc232aa..2ae95476dba3 100644
--- a/net/mptcp/pm_kernel.c
+++ b/net/mptcp/pm_kernel.c
@@ -370,6 +370,10 @@ static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk)
}
subflow:
+ /* No need to try establishing subflows to remote id0 if not allowed */
+ if (mptcp_pm_add_addr_c_flag_case(msk))
+ goto exit;
+
/* check if should create a new subflow */
while (msk->pm.local_addr_used < endp_subflow_max &&
msk->pm.extra_subflows < limit_extra_subflows) {
@@ -401,6 +405,8 @@ static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk)
__mptcp_subflow_connect(sk, &local, &addrs[i]);
spin_lock_bh(&msk->pm.lock);
}
+
+exit:
mptcp_pm_nl_check_work_pending(msk);
}
Changes in v2:
- Add also resets
- Drop cc-stable tag in the last patch
- Link to v1: https://patch.msgid.link/20251029-dt-bindings-pci-qcom-fixes-power-domains-…
Recent binding changes forgot to make power-domains and resets required.
I am not updating SC8180xp because it will be fixed other way in my next
patchset.
Best regards,
Krzysztof
---
Krzysztof Kozlowski (9):
dt-bindings: PCI: qcom,pcie-sa8775p: Add missing required power-domains and resets
dt-bindings: PCI: qcom,pcie-sc7280: Add missing required power-domains and resets
dt-bindings: PCI: qcom,pcie-sc8280xp: Add missing required power-domains and resets
dt-bindings: PCI: qcom,pcie-sm8150: Add missing required power-domains and resets
dt-bindings: PCI: qcom,pcie-sm8250: Add missing required power-domains and resets
dt-bindings: PCI: qcom,pcie-sm8350: Add missing required power-domains and resets
dt-bindings: PCI: qcom,pcie-sm8450: Add missing required power-domains and resets
dt-bindings: PCI: qcom,pcie-sm8550: Add missing required power-domains and resets
dt-bindings: PCI: qcom,pcie-x1e80100: Add missing required power-domains and resets
Documentation/devicetree/bindings/pci/qcom,pcie-sa8775p.yaml | 3 +++
Documentation/devicetree/bindings/pci/qcom,pcie-sc7280.yaml | 5 +++++
Documentation/devicetree/bindings/pci/qcom,pcie-sc8280xp.yaml | 3 +++
Documentation/devicetree/bindings/pci/qcom,pcie-sm8150.yaml | 5 +++++
Documentation/devicetree/bindings/pci/qcom,pcie-sm8250.yaml | 5 +++++
Documentation/devicetree/bindings/pci/qcom,pcie-sm8350.yaml | 5 +++++
Documentation/devicetree/bindings/pci/qcom,pcie-sm8450.yaml | 5 +++++
Documentation/devicetree/bindings/pci/qcom,pcie-sm8550.yaml | 5 +++++
Documentation/devicetree/bindings/pci/qcom,pcie-x1e80100.yaml | 5 +++++
9 files changed, 41 insertions(+)
---
base-commit: 326bbf6e2b1ce8d1e6166cce2ca414aa241c382f
change-id: 20251029-dt-bindings-pci-qcom-fixes-power-domains-36a669b2e252
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org>
From: Takashi Iwai <tiwai(a)suse.de>
commit 94c1ceb043c1a002de9649bb630c8e8347645982 upstream.
snprintf() returns the would-be-filled size when the string overflows
the given buffer size, hence using this value may result in the buffer
overflow (although it's unrealistic).
This patch replaces with a safer version, scnprintf() for papering
over such a potential issue.
Fixes: 29c8e4398f02 ("ASoC: SOF: Intel: hda: add extended rom status dump to error log")
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Link: https://lore.kernel.org/r/20220801165420.25978-4-tiwai@suse.de
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Alexandra Diupina <adiupina(a)astralinux.ru>
---
Backport fix for CVE-2022-50050
sound/soc/sof/intel/hda.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c
index b4cc72483137..1d879c2b81e1 100644
--- a/sound/soc/sof/intel/hda.c
+++ b/sound/soc/sof/intel/hda.c
@@ -437,7 +437,7 @@ static void hda_dsp_dump_ext_rom_status(struct snd_sof_dev *sdev)
for (i = 0; i < HDA_EXT_ROM_STATUS_SIZE; i++) {
value = snd_sof_dsp_read(sdev, HDA_DSP_BAR, HDA_DSP_SRAM_REG_ROM_STATUS + i * 0x4);
- len += snprintf(msg + len, sizeof(msg) - len, " 0x%x", value);
+ len += scnprintf(msg + len, sizeof(msg) - len, " 0x%x", value);
}
sof_dev_dbg_or_err(sdev->dev, hda->boot_iteration == HDA_FW_BOOT_ATTEMPTS,
--
2.30.2
Commit under Fixes enabled loadable module support for the driver under
the assumption that it shall be the sole user of the Cadence Host and
Endpoint library APIs. This assumption guarantees that we won't end up
in a case where the driver is built-in and the library support is built
as a loadable module.
With the introduction of [1], this assumption is no longer valid. The
SG2042 driver could be built as a loadable module, implying that the
Cadence Host library is also selected as a loadable module. However, the
pci-j721e.c driver could be built-in as indicated by CONFIG_PCI_J721E=y
due to which the Cadence Endpoint library is built-in. Despite the
library drivers being built as specified by their respective consumers,
since the 'pci-j721e.c' driver has references to the Cadence Host
library APIs as well, we run into a build error as reported at [0].
Fix this by adding config guards as a temporary workaround. The proper
fix is to split the 'pci-j721e.c' driver into independent Host and
Endpoint drivers as aligned at [2].
Fixes: a2790bf81f0f ("PCI: j721e: Add support to build as a loadable module")
Reported-by: kernel test robot <lkp(a)intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202511111705.MZ7ls8Hm-lkp@intel.com/
Cc: <stable(a)vger.kernel.org>
[0]: https://lore.kernel.org/r/202511111705.MZ7ls8Hm-lkp@intel.com/
[1]: commit 1c72774df028 ("PCI: sg2042: Add Sophgo SG2042 PCIe driver")
[2]: https://lore.kernel.org/r/37f6f8ce-12b2-44ee-a94c-f21b29c98821@app.fastmail…
Suggested-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Siddharth Vadapalli <s-vadapalli(a)ti.com>
---
drivers/pci/controller/cadence/pci-j721e.c | 43 +++++++++++++---------
1 file changed, 26 insertions(+), 17 deletions(-)
diff --git a/drivers/pci/controller/cadence/pci-j721e.c b/drivers/pci/controller/cadence/pci-j721e.c
index 5bc5ab20aa6d..67c5e02afccf 100644
--- a/drivers/pci/controller/cadence/pci-j721e.c
+++ b/drivers/pci/controller/cadence/pci-j721e.c
@@ -628,10 +628,12 @@ static int j721e_pcie_probe(struct platform_device *pdev)
gpiod_set_value_cansleep(gpiod, 1);
}
- ret = cdns_pcie_host_setup(rc);
- if (ret < 0) {
- clk_disable_unprepare(pcie->refclk);
- goto err_pcie_setup;
+ if (IS_ENABLED(CONFIG_PCI_J721E_HOST)) {
+ ret = cdns_pcie_host_setup(rc);
+ if (ret < 0) {
+ clk_disable_unprepare(pcie->refclk);
+ goto err_pcie_setup;
+ }
}
break;
@@ -642,9 +644,11 @@ static int j721e_pcie_probe(struct platform_device *pdev)
goto err_get_sync;
}
- ret = cdns_pcie_ep_setup(ep);
- if (ret < 0)
- goto err_pcie_setup;
+ if (IS_ENABLED(CONFIG_PCI_J721E_EP)) {
+ ret = cdns_pcie_ep_setup(ep);
+ if (ret < 0)
+ goto err_pcie_setup;
+ }
break;
}
@@ -669,10 +673,11 @@ static void j721e_pcie_remove(struct platform_device *pdev)
struct cdns_pcie_ep *ep;
struct cdns_pcie_rc *rc;
- if (pcie->mode == PCI_MODE_RC) {
+ if (IS_ENABLED(CONFIG_PCI_J721E_HOST) &&
+ pcie->mode == PCI_MODE_RC) {
rc = container_of(cdns_pcie, struct cdns_pcie_rc, pcie);
cdns_pcie_host_disable(rc);
- } else {
+ } else if (IS_ENABLED(CONFIG_PCI_J721E_EP)) {
ep = container_of(cdns_pcie, struct cdns_pcie_ep, pcie);
cdns_pcie_ep_disable(ep);
}
@@ -739,10 +744,12 @@ static int j721e_pcie_resume_noirq(struct device *dev)
gpiod_set_value_cansleep(pcie->reset_gpio, 1);
}
- ret = cdns_pcie_host_link_setup(rc);
- if (ret < 0) {
- clk_disable_unprepare(pcie->refclk);
- return ret;
+ if (IS_ENABLED(CONFIG_PCI_J721E_HOST)) {
+ ret = cdns_pcie_host_link_setup(rc);
+ if (ret < 0) {
+ clk_disable_unprepare(pcie->refclk);
+ return ret;
+ }
}
/*
@@ -752,10 +759,12 @@ static int j721e_pcie_resume_noirq(struct device *dev)
for (enum cdns_pcie_rp_bar bar = RP_BAR0; bar <= RP_NO_BAR; bar++)
rc->avail_ib_bar[bar] = true;
- ret = cdns_pcie_host_init(rc);
- if (ret) {
- clk_disable_unprepare(pcie->refclk);
- return ret;
+ if (IS_ENABLED(CONFIG_PCI_J721E_HOST)) {
+ ret = cdns_pcie_host_init(rc);
+ if (ret) {
+ clk_disable_unprepare(pcie->refclk);
+ return ret;
+ }
}
}
--
2.51.1
#regzbot introduced: v6.13.1..v6.13.2
Distro: Arch Linux
Kernel: since v6.13.2
The bluetooth adapter would be recognized and the bluetooth worked flawlessly till v6.13.1 , but since the v6.13.2 , the bluetooth adapter doesn't get recognized by the bluetooth service and therefore the bluetooth functionality doesn't work .
I suspect the bluetooth's driver failing to load at the kernel-level.
- The output of bluetoothctl :
$: bluetoothctl
Agent registered
[bluetoothctl]> list
[bluetoothctl]> devices
No default controller available
[bluetoothctl]>
- The output of systemctl status bluetooth.service :
● bluetooth.service - Bluetooth service
Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; preset: disabled)
Active: active (running) since Sat 2025-11-15 22:57:00 +0545; 1 day 8h ago
Invocation: bddf190655fd4a4290d41cde594f2efa
Docs: man:bluetoothd(8)
Main PID: 617 (bluetoothd)
Status: "Running"
Tasks: 1 (limit: 18701)
Memory: 2.8M (peak: 3.8M)
CPU: 38ms
CGroup: /system.slice/bluetooth.service
└─617 /usr/lib/bluetooth/bluetoothd
Nov 15 22:57:00 Incog systemd[1]: Starting Bluetooth service...
Nov 15 22:57:00 Incog bluetoothd[617]: Bluetooth daemon 5.84
Nov 15 22:57:00 Incog systemd[1]: Started Bluetooth service.
Nov 15 22:57:00 Incog bluetoothd[617]: Starting SDP server
Nov 15 22:57:00 Incog bluetoothd[617]: Bluetooth management interface 1.23 initialized
- The output of lspci is attached below .
- The logs for journalctl -b for both v6.13.1 and v6.13.2 are attached below.
Regards,
IncogCyberpunk
Commit 5c2f7727d437 ("mtd: mtdpart: check for subpartitions parsing
result") introduced some kind of regression with parser on subpartitions
where if a parser emits an error then the entire parsing process from the
upper parser fails and partitions are deleted.
Not checking for error in subpartitions was originally intended as
special parser can emit error also in the case of the partition not
correctly init (for example a wiped partition) or special case where the
partition should be skipped due to some ENV variables externally
provided (from bootloader for example)
One example case is the TRX partition where, in the context of a wiped
partition, returns a -ENOENT as the trx_magic is not found in the
expected TRX header (as the partition is wiped)
To better handle this and still keep some kind of error tracking (for
example to catch -ENOMEM errors or -EINVAL errors), permit parser on
subpartition to emit -ENOENT error, print a debug log and skip them
accordingly.
This results in giving better tracking of the status of the parser
(instead of returning just 0, dropping any kind of signal that there is
something wrong with the parser) and to some degree restore the original
logic of the subpartitions parse.
(worth to notice that some special partition might have all the special
header present for the parser and declare 0 partition in it, this is why
it would be wrong to simply return 0 in the case of a special partition
that is NOT init for the scanning parser)
Cc: stable(a)vger.kernel.org
Fixes: 5c2f7727d437 ("mtd: mtdpart: check for subpartitions parsing result")
Signed-off-by: Christian Marangi <ansuelsmth(a)gmail.com>
---
drivers/mtd/mtdpart.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 994e8c51e674..2876501a7814 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -425,9 +425,12 @@ int add_mtd_partitions(struct mtd_info *parent,
mtd_add_partition_attrs(child);
- /* Look for subpartitions */
+ /* Look for subpartitions (skip if no maching parser found) */
ret = parse_mtd_partitions(child, parts[i].types, NULL);
- if (ret < 0) {
+ if (ret < 0 && ret == -ENOENT) {
+ pr_debug("Skip parsing subpartitions: %d\n", ret);
+ continue;
+ } else if (ret < 0) {
pr_err("Failed to parse subpartitions: %d\n", ret);
goto err_del_partitions;
}
--
2.51.0
The drivers associated with the PCIE_CADENCE, PCIE_CADENCE_HOST AND
PCIE_CADENCE_EP configs are used by multiple vendor drivers and serve as a
library of helpers. Since the vendor drivers could individually be built
as built-in or as loadable modules, it is possible to select a build
configuration wherein a vendor driver is built-in while the library is
built as a loadable module. This will result in a build error as reported
in the 'Closes' link below.
Address the build error by changing the library configs to be 'bool'
instead of 'tristate'.
Reported-by: kernel test robot <lkp(a)intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202511111705.MZ7ls8Hm-lkp@intel.com/
Fixes: 1c72774df028 ("PCI: sg2042: Add Sophgo SG2042 PCIe driver")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Siddharth Vadapalli <s-vadapalli(a)ti.com>
---
drivers/pci/controller/cadence/Kconfig | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/cadence/Kconfig b/drivers/pci/controller/cadence/Kconfig
index 02a639e55fd8..980da64ce730 100644
--- a/drivers/pci/controller/cadence/Kconfig
+++ b/drivers/pci/controller/cadence/Kconfig
@@ -4,16 +4,16 @@ menu "Cadence-based PCIe controllers"
depends on PCI
config PCIE_CADENCE
- tristate
+ bool
config PCIE_CADENCE_HOST
- tristate
+ bool
depends on OF
select IRQ_DOMAIN
select PCIE_CADENCE
config PCIE_CADENCE_EP
- tristate
+ bool
depends on OF
depends on PCI_ENDPOINT
select PCIE_CADENCE
--
2.51.1