March 2024 - Linux-stable-mirror

[PATCH v3 2/5] Bluetooth: add quirk for broken address properties

by Johan Hovold

Some Bluetooth controllers lack persistent storage for the device address and instead one can be provided by the boot firmware using the 'local-bd-address' devicetree property. The Bluetooth devicetree bindings clearly states that the address should be specified in little-endian order, but due to a long-standing bug in the Qualcomm driver which reversed the address some boot firmware has been providing the address in big-endian order instead. Add a new quirk that can be set on platforms with broken firmware and use it to reverse the address when parsing the property so that the underlying driver bug can be fixed. Fixes: 5c0a1001c8be ("Bluetooth: hci_qca: Add helper to set device address") Cc: stable(a)vger.kernel.org # 5.1 Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- include/net/bluetooth/hci.h | 9 +++++++++ net/bluetooth/hci_sync.c | 5 ++++- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h index bdee5d649cc6..191077d8d578 100644 --- a/include/net/bluetooth/hci.h +++ b/include/net/bluetooth/hci.h @@ -176,6 +176,15 @@ enum { */ HCI_QUIRK_USE_BDADDR_PROPERTY, + /* When this quirk is set, the Bluetooth Device Address provided by + * the 'local-bd-address' fwnode property is incorrectly specified in + * big-endian order. + * + * This quirk can be set before hci_register_dev is called or + * during the hdev->setup vendor callback. + */ + HCI_QUIRK_BDADDR_PROPERTY_BROKEN, + /* When this quirk is set, the duplicate filtering during * scanning is based on Bluetooth devices addresses. To allow * RSSI based updates, restart scanning if needed. diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c index 5716345a26df..283ae8edc1e5 100644 --- a/net/bluetooth/hci_sync.c +++ b/net/bluetooth/hci_sync.c @@ -3215,7 +3215,10 @@ static void hci_dev_get_bd_addr_from_property(struct hci_dev *hdev) if (ret < 0 || !bacmp(&ba, BDADDR_ANY)) return; - bacpy(&hdev->public_addr, &ba); + if (test_bit(HCI_QUIRK_BDADDR_PROPERTY_BROKEN, &hdev->quirks)) + baswap(&hdev->public_addr, &ba); + else + bacpy(&hdev->public_addr, &ba); } struct hci_init_stage { -- 2.43.2

1 year, 3 months

6
7
0 0

[PATCH RESEND 0/2] ARM: prctl: Reject PR_SET_MDWE where not supported

by Zev Weiss

[Resending as per Russell's request...] Hello, I noticed after a recent kernel update that my ARM926 system started segfaulting on any execve() after calling prctl(PR_SET_MDWE). After some investigation it appears that ARMv5 is incapable of providing the appropriate protections for MDWE, since any readable memory is also implicitly executable. (Note that I'm not an expert in either ARM arch details or the mm subsystem, so please bear with me if I've botched something in the above analysis.) The prctl_set_mdwe() function already had some special-case logic added disabling it on PARISC (commit 793838138c15, "prctl: Disable prctl(PR_SET_MDWE) on parisc"); this patch series (1) generalizes that check to use an arch_*() function, and (2) adds a corresponding override for ARM to disable MDWE on pre-ARMv6 CPUs. With the series applied, prctl(PR_SET_MDWE) is rejected on ARMv5 and subsequent execve() calls (as well as mmap(PROT_READ|PROT_WRITE)) can succeed instead of unconditionally failing; on ARMv6 the prctl works as it did previously. Thanks, Zev [0] https://lore.kernel.org/all/2023112456-linked-nape-bf19@gregkh/ Zev Weiss (2): prctl: Generalize PR_SET_MDWE support check to be per-arch ARM: prctl: Reject PR_SET_MDWE on pre-ARMv6 arch/arm/include/asm/mman.h | 14 ++++++++++++++ arch/parisc/include/asm/mman.h | 14 ++++++++++++++ include/linux/mman.h | 8 ++++++++ kernel/sys.c | 7 +++++-- 4 files changed, 41 insertions(+), 2 deletions(-) create mode 100644 arch/arm/include/asm/mman.h create mode 100644 arch/parisc/include/asm/mman.h -- 2.43.2

1 year, 3 months

3
5
0 0

[PATCH v3 3/5] Bluetooth: qca: fix device-address endianness

by Johan Hovold

The WCN6855 firmware on the Lenovo ThinkPad X13s expects the Bluetooth device address in big-endian order when setting it using the EDL_WRITE_BD_ADDR_OPCODE command. Presumably, this is the case for all non-ROME devices which all use the EDL_WRITE_BD_ADDR_OPCODE command for this (unlike the ROME devices which use a different command and expect the address in little-endian order). Reverse the little-endian address before setting it to make sure that the address can be configured using tools like btmgmt or using the 'local-bd-address' devicetree property. Note that this can potentially break systems with boot firmware which has started relying on the broken behaviour and is incorrectly passing the address via devicetree in big-endian order. Fixes: 5c0a1001c8be ("Bluetooth: hci_qca: Add helper to set device address") Cc: stable(a)vger.kernel.org # 5.1 Cc: Balakrishna Godavarthi <quic_bgodavar(a)quicinc.com> Cc: Matthias Kaehlcke <mka(a)chromium.org> Tested-by: Nikita Travkin <nikita(a)trvn.ru> # sc7180 Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- drivers/bluetooth/btqca.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c index b40b32fa7f1c..19cfc342fc7b 100644 --- a/drivers/bluetooth/btqca.c +++ b/drivers/bluetooth/btqca.c @@ -826,11 +826,15 @@ EXPORT_SYMBOL_GPL(qca_uart_setup); int qca_set_bdaddr(struct hci_dev *hdev, const bdaddr_t *bdaddr) { + bdaddr_t bdaddr_swapped; struct sk_buff *skb; int err; - skb = __hci_cmd_sync_ev(hdev, EDL_WRITE_BD_ADDR_OPCODE, 6, bdaddr, - HCI_EV_VENDOR, HCI_INIT_TIMEOUT); + baswap(&bdaddr_swapped, bdaddr); + + skb = __hci_cmd_sync_ev(hdev, EDL_WRITE_BD_ADDR_OPCODE, 6, + &bdaddr_swapped, HCI_EV_VENDOR, + HCI_INIT_TIMEOUT); if (IS_ERR(skb)) { err = PTR_ERR(skb); bt_dev_err(hdev, "QCA Change address cmd failed (%d)", err); -- 2.43.2

1 year, 3 months

3
5
0 0

[PATCH v3 5/5] arm64: dts: qcom: sc7180-trogdor: mark bluetooth address as broken

by Johan Hovold

Several Qualcomm Bluetooth controllers lack persistent storage for the device address and instead one can be provided by the boot firmware using the 'local-bd-address' devicetree property. The Bluetooth bindings clearly states that the address should be specified in little-endian order, but due to a long-standing bug in the Qualcomm driver which reversed the address some boot firmware has been providing the address in big-endian order instead. The boot firmware in SC7180 Trogdor Chromebooks is known to be affected so mark the 'local-bd-address' property as broken to maintain backwards compatibility with older firmware when fixing the underlying driver bug. Note that ChromeOS always updates the kernel and devicetree in lockstep so that there is no need to handle backwards compatibility with older devicetrees. Fixes: 7ec3e67307f8 ("arm64: dts: qcom: sc7180-trogdor: add initial trogdor and lazor dt") Cc: stable(a)vger.kernel.org # 5.10 Cc: Rob Clark <robdclark(a)chromium.org> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi index 46aaeba28604..ebe37678102f 100644 --- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi @@ -943,6 +943,8 @@ bluetooth: bluetooth { vddrf-supply = <&pp1300_l2c>; vddch0-supply = <&pp3300_l10c>; max-speed = <3200000>; + + qcom,local-bd-address-broken; }; }; -- 2.43.2

1 year, 3 months

2
1
0 0

[PATCH 2/2] Bluetooth: qca: fix NULL-deref on non-serdev setup

by Johan Hovold

Qualcomm ROME controllers can be registered from the Bluetooth line discipline and in this case the HCI UART serdev pointer is NULL. Add the missing sanity check to prevent a NULL-pointer dereference when setup() is called for a non-serdev controller. Fixes: e9b3e5b8c657 ("Bluetooth: hci_qca: only assign wakeup with serial port support") Cc: stable(a)vger.kernel.org # 6.2 Cc: Zhengping Jiang <jiangzp(a)google.com> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- drivers/bluetooth/hci_qca.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index 84f728943962..6a69a7f9ef64 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -1960,8 +1960,10 @@ static int qca_setup(struct hci_uart *hu) qca_debugfs_init(hdev); hu->hdev->hw_error = qca_hw_error; hu->hdev->cmd_timeout = qca_cmd_timeout; - if (device_can_wakeup(hu->serdev->ctrl->dev.parent)) - hu->hdev->wakeup = qca_wakeup; + if (hu->serdev) { + if (device_can_wakeup(hu->serdev->ctrl->dev.parent)) + hu->hdev->wakeup = qca_wakeup; + } } else if (ret == -ENOENT) { /* No patch/nvm-config found, run with original fw/config */ set_bit(QCA_ROM_FW, &qca->flags); -- 2.43.2

1 year, 3 months

1
0
0 0

[PATCH 1/2] Bluetooth: qca: fix NULL-deref on non-serdev suspend

by Johan Hovold

Qualcomm ROME controllers can be registered from the Bluetooth line discipline and in this case the HCI UART serdev pointer is NULL. Add the missing sanity check to prevent a NULL-pointer dereference when wakeup() is called for a non-serdev controller during suspend. Just return true for now to restore the original behaviour and address the crash with pre-6.2 kernels, which do not have commit e9b3e5b8c657 ("Bluetooth: hci_qca: only assign wakeup with serial port support") that causes the crash to happen already at setup() time. Fixes: c1a74160eaf1 ("Bluetooth: hci_qca: Add device_may_wakeup support") Cc: stable(a)vger.kernel.org # 5.13 Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- drivers/bluetooth/hci_qca.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index c73481c57741..84f728943962 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -1672,6 +1672,9 @@ static bool qca_wakeup(struct hci_dev *hdev) struct hci_uart *hu = hci_get_drvdata(hdev); bool wakeup; + if (!hu->serdev) + return true; + /* BT SoC attached through the serial bus is handled by the serdev driver. * So we need to use the device handle of the serdev driver to get the * status of device may wakeup. -- 2.43.2

1 year, 3 months

1
0
0 0

[PATCH v3 4/5] Bluetooth: qca: add workaround for broken address properties

by Johan Hovold

Due to a long-standing bug in the Qualcomm Bluetooth driver, the device address has so far been reversed when configuring non-ROME controllers. This, in turn, has led to one vendor reversing the address that the boot firmware provides using the 'local-bd-address' devicetree property. The only device affected by this should be the WCN3991 used in some Chromebooks. As ChromeOS updates the kernel and devicetree in lockstep, the new 'qcom,local-bd-address-broken' property can be used to determine if the firmware is buggy so that the underlying driver bug can be fixed without breaking backwards compatibility. Set the HCI_QUIRK_BDADDR_PROPERTY_BROKEN quirk for such platforms so that the address is reversed when parsing the address property. Fixes: 5c0a1001c8be ("Bluetooth: hci_qca: Add helper to set device address") Cc: stable(a)vger.kernel.org # 5.1 Cc: Balakrishna Godavarthi <quic_bgodavar(a)quicinc.com> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- drivers/bluetooth/hci_qca.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index f989c05f8177..c73481c57741 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -225,6 +225,7 @@ struct qca_serdev { struct qca_power *bt_power; u32 init_speed; u32 oper_speed; + bool bdaddr_property_broken; const char *firmware_name; }; @@ -1842,6 +1843,7 @@ static int qca_setup(struct hci_uart *hu) const char *firmware_name = qca_get_firmware_name(hu); int ret; struct qca_btsoc_version ver; + struct qca_serdev *qcadev; const char *soc_name; ret = qca_check_speeds(hu); @@ -1904,6 +1906,11 @@ static int qca_setup(struct hci_uart *hu) case QCA_WCN6855: case QCA_WCN7850: set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks); + + qcadev = serdev_device_get_drvdata(hu->serdev); + if (qcadev->bdaddr_property_broken) + set_bit(HCI_QUIRK_BDADDR_PROPERTY_BROKEN, &hdev->quirks); + hci_set_aosp_capable(hdev); ret = qca_read_soc_version(hdev, &ver, soc_type); @@ -2284,6 +2291,9 @@ static int qca_serdev_probe(struct serdev_device *serdev) if (!qcadev->oper_speed) BT_DBG("UART will pick default operating speed"); + qcadev->bdaddr_property_broken = device_property_read_bool(&serdev->dev, + "qcom,local-bd-address-broken"); + if (data) qcadev->btsoc_type = data->soc_type; else -- 2.43.2

1 year, 3 months

1
0
0 0

Re: Patch "selftests: mptcp: explicitly trigger the listener diag code-path" has been added to the 6.7-stable tree

by Matthieu Baerts

Hi Sasha, On 19/03/2024 00:00, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > selftests: mptcp: explicitly trigger the listener diag code-path > > to the 6.7-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > selftests-mptcp-explicitly-trigger-the-listener-diag.patch > and it can be found in the queue-6.7 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. I do :) > commit 02dc7e7327bc1a3551665745a40029cf96d6a8e6 > Author: Paolo Abeni <pabeni(a)redhat.com> > Date: Fri Feb 23 17:14:20 2024 +0100 > > selftests: mptcp: explicitly trigger the listener diag code-path > > [ Upstream commit b4b51d36bbaa3ddb93b3e1ca3a1ef0aa629d6521 ] I think something went wrong: this patch was not supposed to be added to both 6.6 and 6.7 queues: https://lore.kernel.org/stable/Zfg36tcGXUsZnJCh@sashalap/ Do you mind dropping them from both queues, please? Cheers, Matt -- Sponsored by the NGI0 Core fund.

1 year, 3 months

2
1
0 0

[PATCH v3 1/1] driver core: Keep the supplier fwnode consistent with the device

by Herve Codina

The commit 3a2dbc510c43 ("driver core: fw_devlink: Don't purge child fwnode's consumer links") introduces the possibility to use the supplier's parent device instead of the supplier itself. In that case the supplier fwnode used is not updated and is no more consistent with the supplier device used. Use the fwnode consistent with the supplier device when checking flags. Fixes: 3a2dbc510c43 ("driver core: fw_devlink: Don't purge child fwnode's consumer links") Cc: stable(a)vger.kernel.org Signed-off-by: Herve Codina <herve.codina(a)bootlin.com> --- Changes v2 -> v3: Do not update the supplier handle in order to keep the original handle for debug traces. Changes v1 -> v2: Remove sup_handle check and related pr_debug() call as sup_handle cannot be invalid if sup_dev is valid. drivers/base/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/base/core.c b/drivers/base/core.c index 4d8b315c48a1..440b52ec027f 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -2082,7 +2082,7 @@ static int fw_devlink_create_devlink(struct device *con, * supplier device indefinitely. */ if (sup_dev->links.status == DL_DEV_NO_DRIVER && - sup_handle->flags & FWNODE_FLAG_INITIALIZED) { + sup_dev->fwnode->flags & FWNODE_FLAG_INITIALIZED) { dev_dbg(con, "Not linking %pfwf - dev might never probe\n", sup_handle); -- 2.41.0

1 year, 3 months

2
3
0 0

[REGRESSION] 6.7.1: md: raid5 hang and unresponsive system; successfully bisected

by Dan Moulding

After upgrading from 6.7.0 to 6.7.1 a couple of my systems with md RAID-5 arrays started experiencing hangs. It starts with some processes which write to the array getting stuck. The whole system eventually becomes unresponsive and unclean shutdown must be performed (poweroff and reboot don't work). While trying to diagnose the issue, I noticed that the md0_raid5 kernel thread consumes 100% CPU after the issue occurs. No relevant warnings or errors were found in dmesg. On 6.7.1, I can reproduce the issue somewhat reliably by copying a large amount of data to the array. I am unable to reproduce the issue at all on 6.7.0. The bisection was a bit difficult since I don't have a 100% reliable method to reproduce the problem, but with some perseverence I eventually managed to whittle it down to commit 0de40f76d567 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"). After reverting that commit (i.e. reapplying the reverted commit) on top of 6.7.1 I can no longer reproduce the problem at all. Some details that might be relevant: - Both systems are running MD RAID-5 with a journal device. - mdadm in monitor mode is always running on both systems. - Both systems were previously running 6.7.0 and earlier just fine. - The older of the two systems has been running a raid5 array without incident for many years (kernel going back to at least 5.1) -- this is the first raid5 issue it has encountered. Please let me know if there is any other helpful information that I might be able to provide. -- Dan #regzbot introduced: 0de40f76d567133b871cd6ad46bb87afbce46983

1 year, 3 months

9
52
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2024