January 2022 - Linux-stable-mirror

[PATCH AUTOSEL 4.19 1/5] x86/PCI: Ignore E820 reservations for bridge windows on newer systems

by Sasha Levin

From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit 7f7b4236f2040d19df1ddaf30047128b41e78de7 ] Some BIOS-es contain a bug where they add addresses which map to system RAM in the PCI host bridge window returned by the ACPI _CRS method, see commit 4dc2287c1805 ("x86: avoid E820 regions when allocating address space"). To work around this bug Linux excludes E820 reserved addresses when allocating addresses from the PCI host bridge window since 2010. Recently (2019) some systems have shown-up with E820 reservations which cover the entire _CRS returned PCI bridge memory window, causing all attempts to assign memory to PCI BARs which have not been setup by the BIOS to fail. For example here are the relevant dmesg bits from a Lenovo IdeaPad 3 15IIL 81WE: [mem 0x000000004bc50000-0x00000000cfffffff] reserved pci_bus 0000:00: root bus resource [mem 0x65400000-0xbfffffff window] The ACPI specifications appear to allow this new behavior: The relationship between E820 and ACPI _CRS is not really very clear. ACPI v6.3, sec 15, table 15-374, says AddressRangeReserved means: This range of addresses is in use or reserved by the system and is not to be included in the allocatable memory pool of the operating system's memory manager. and it may be used when: The address range is in use by a memory-mapped system device. Furthermore, sec 15.2 says: Address ranges defined for baseboard memory-mapped I/O devices, such as APICs, are returned as reserved. A PCI host bridge qualifies as a baseboard memory-mapped I/O device, and its apertures are in use and certainly should not be included in the general allocatable pool, so the fact that some BIOS-es reports the PCI aperture as "reserved" in E820 doesn't seem like a BIOS bug. So it seems that the excluding of E820 reserved addresses is a mistake. Ideally Linux would fully stop excluding E820 reserved addresses, but then the old systems this was added for will regress. Instead keep the old behavior for old systems, while ignoring the E820 reservations for any systems from now on. Old systems are defined here as BIOS year < 2018, this was chosen to make sure that E820 reservations will not be used on the currently affected systems, while at the same time also taking into account that the systems for which the E820 checking was originally added may have received BIOS updates for quite a while (esp. CVE related ones), giving them a more recent BIOS year then 2010. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206459 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1868899 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1871793 BugLink: https://bugs.launchpad.net/bugs/1878279 BugLink: https://bugs.launchpad.net/bugs/1931715 BugLink: https://bugs.launchpad.net/bugs/1932069 BugLink: https://bugs.launchpad.net/bugs/1921649 Reviewed-by: Mika Westerberg <mika.westerberg(a)linux.intel.com> Acked-by: Bjorn Helgaas <bhelgaas(a)google.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/x86/kernel/resource.c | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/resource.c b/arch/x86/kernel/resource.c index 9b9fb7882c206..9ae64f9af9568 100644 --- a/arch/x86/kernel/resource.c +++ b/arch/x86/kernel/resource.c @@ -1,4 +1,5 @@ // SPDX-License-Identifier: GPL-2.0 +#include <linux/dmi.h> #include <linux/ioport.h> #include <asm/e820/api.h> @@ -23,11 +24,31 @@ static void resource_clip(struct resource *res, resource_size_t start, res->start = end + 1; } +/* + * Some BIOS-es contain a bug where they add addresses which map to + * system RAM in the PCI host bridge window returned by the ACPI _CRS + * method, see commit 4dc2287c1805 ("x86: avoid E820 regions when + * allocating address space"). To avoid this Linux by default excludes + * E820 reservations when allocating addresses since 2010. + * In 2019 some systems have shown-up with E820 reservations which cover + * the entire _CRS returned PCI host bridge window, causing all attempts + * to assign memory to PCI BARs to fail if Linux uses E820 reservations. + * + * Ideally Linux would fully stop using E820 reservations, but then + * the old systems this was added for will regress. + * Instead keep the old behavior for old systems, while ignoring the + * E820 reservations for any systems from now on. + */ static void remove_e820_regions(struct resource *avail) { - int i; + int i, year = dmi_get_bios_year(); struct e820_entry *entry; + if (year >= 2018) + return; + + pr_info_once("PCI: Removing E820 reservations from host bridge windows\n"); + for (i = 0; i < e820_table->nr_entries; i++) { entry = &e820_table->entries[i]; -- 2.34.1

2 years, 11 months

1
4
0 0

[PATCH AUTOSEL 5.4 1/8] hwspinlock: stm32: enable clock at probe

by Sasha Levin

From: Fabien Dessenne <fabien.dessenne(a)foss.st.com> [ Upstream commit 60630924bb5af8751adcecc896e7763c3783ca89 ] Set the clock during probe and keep its control during suspend / resume operations. This fixes an issue when CONFIG_PM is not set and where the clock is never enabled. Make use of devm_ functions to simplify the code. Signed-off-by: Fabien Dessenne <fabien.dessenne(a)foss.st.com> Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> Link: https://lore.kernel.org/r/20211011135836.1045437-1-fabien.dessenne@foss.st.… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/hwspinlock/stm32_hwspinlock.c | 58 +++++++++++++++++---------- 1 file changed, 37 insertions(+), 21 deletions(-) diff --git a/drivers/hwspinlock/stm32_hwspinlock.c b/drivers/hwspinlock/stm32_hwspinlock.c index c8eacf4f9692b..f1ca4717230ac 100644 --- a/drivers/hwspinlock/stm32_hwspinlock.c +++ b/drivers/hwspinlock/stm32_hwspinlock.c @@ -54,8 +54,23 @@ static const struct hwspinlock_ops stm32_hwspinlock_ops = { .relax = stm32_hwspinlock_relax, }; +static void stm32_hwspinlock_disable_clk(void *data) +{ + struct platform_device *pdev = data; + struct stm32_hwspinlock *hw = platform_get_drvdata(pdev); + struct device *dev = &pdev->dev; + + pm_runtime_get_sync(dev); + pm_runtime_disable(dev); + pm_runtime_set_suspended(dev); + pm_runtime_put_noidle(dev); + + clk_disable_unprepare(hw->clk); +} + static int stm32_hwspinlock_probe(struct platform_device *pdev) { + struct device *dev = &pdev->dev; struct stm32_hwspinlock *hw; void __iomem *io_base; struct resource *res; @@ -68,41 +83,43 @@ static int stm32_hwspinlock_probe(struct platform_device *pdev) return PTR_ERR(io_base); array_size = STM32_MUTEX_NUM_LOCKS * sizeof(struct hwspinlock); - hw = devm_kzalloc(&pdev->dev, sizeof(*hw) + array_size, GFP_KERNEL); + hw = devm_kzalloc(dev, sizeof(*hw) + array_size, GFP_KERNEL); if (!hw) return -ENOMEM; - hw->clk = devm_clk_get(&pdev->dev, "hsem"); + hw->clk = devm_clk_get(dev, "hsem"); if (IS_ERR(hw->clk)) return PTR_ERR(hw->clk); - for (i = 0; i < STM32_MUTEX_NUM_LOCKS; i++) - hw->bank.lock[i].priv = io_base + i * sizeof(u32); + ret = clk_prepare_enable(hw->clk); + if (ret) { + dev_err(dev, "Failed to prepare_enable clock\n"); + return ret; + } platform_set_drvdata(pdev, hw); - pm_runtime_enable(&pdev->dev); - ret = hwspin_lock_register(&hw->bank, &pdev->dev, &stm32_hwspinlock_ops, - 0, STM32_MUTEX_NUM_LOCKS); + pm_runtime_get_noresume(dev); + pm_runtime_set_active(dev); + pm_runtime_enable(dev); + pm_runtime_put(dev); - if (ret) - pm_runtime_disable(&pdev->dev); + ret = devm_add_action_or_reset(dev, stm32_hwspinlock_disable_clk, pdev); + if (ret) { + dev_err(dev, "Failed to register action\n"); + return ret; + } - return ret; -} + for (i = 0; i < STM32_MUTEX_NUM_LOCKS; i++) + hw->bank.lock[i].priv = io_base + i * sizeof(u32); -static int stm32_hwspinlock_remove(struct platform_device *pdev) -{ - struct stm32_hwspinlock *hw = platform_get_drvdata(pdev); - int ret; + ret = devm_hwspin_lock_register(dev, &hw->bank, &stm32_hwspinlock_ops, + 0, STM32_MUTEX_NUM_LOCKS); - ret = hwspin_lock_unregister(&hw->bank); if (ret) - dev_err(&pdev->dev, "%s failed: %d\n", __func__, ret); - - pm_runtime_disable(&pdev->dev); + dev_err(dev, "Failed to register hwspinlock\n"); - return 0; + return ret; } static int __maybe_unused stm32_hwspinlock_runtime_suspend(struct device *dev) @@ -137,7 +154,6 @@ MODULE_DEVICE_TABLE(of, stm32_hwpinlock_ids); static struct platform_driver stm32_hwspinlock_driver = { .probe = stm32_hwspinlock_probe, - .remove = stm32_hwspinlock_remove, .driver = { .name = "stm32_hwspinlock", .of_match_table = stm32_hwpinlock_ids, -- 2.34.1

2 years, 11 months

1
7
0 0

[PATCH AUTOSEL 4.4 01/29] Bluetooth: Fix debugfs entry leak in hci_register_dev()

by Sasha Levin

From: Wei Yongjun <weiyongjun1(a)huawei.com> [ Upstream commit 5a4bb6a8e981d3d0d492aa38412ee80b21033177 ] Fault injection test report debugfs entry leak as follows: debugfs: Directory 'hci0' with parent 'bluetooth' already present! When register_pm_notifier() failed in hci_register_dev(), the debugfs create by debugfs_create_dir() do not removed in the error handing path. Add the remove debugfs code to fix it. Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com> Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- net/bluetooth/hci_core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c index eefaa10c74dbb..1cc78b88a0d9f 100644 --- a/net/bluetooth/hci_core.c +++ b/net/bluetooth/hci_core.c @@ -3459,6 +3459,7 @@ int hci_register_dev(struct hci_dev *hdev) return id; err_wqueue: + debugfs_remove_recursive(hdev->debugfs); destroy_workqueue(hdev->workqueue); destroy_workqueue(hdev->req_workqueue); err: -- 2.34.1

2 years, 11 months

5
35
0 0

[PATCH AUTOSEL 5.10 001/116] Bluetooth: Fix debugfs entry leak in hci_register_dev()

by Sasha Levin

From: Wei Yongjun <weiyongjun1(a)huawei.com> [ Upstream commit 5a4bb6a8e981d3d0d492aa38412ee80b21033177 ] Fault injection test report debugfs entry leak as follows: debugfs: Directory 'hci0' with parent 'bluetooth' already present! When register_pm_notifier() failed in hci_register_dev(), the debugfs create by debugfs_create_dir() do not removed in the error handing path. Add the remove debugfs code to fix it. Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com> Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- net/bluetooth/hci_core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c index 2ad66f64879f1..2e7998bad133b 100644 --- a/net/bluetooth/hci_core.c +++ b/net/bluetooth/hci_core.c @@ -3810,6 +3810,7 @@ int hci_register_dev(struct hci_dev *hdev) return id; err_wqueue: + debugfs_remove_recursive(hdev->debugfs); destroy_workqueue(hdev->workqueue); destroy_workqueue(hdev->req_workqueue); err: -- 2.34.1

2 years, 11 months

3
119
0 0

[PATCH AUTOSEL 5.15 001/188] Bluetooth: Fix debugfs entry leak in hci_register_dev()

by Sasha Levin

From: Wei Yongjun <weiyongjun1(a)huawei.com> [ Upstream commit 5a4bb6a8e981d3d0d492aa38412ee80b21033177 ] Fault injection test report debugfs entry leak as follows: debugfs: Directory 'hci0' with parent 'bluetooth' already present! When register_pm_notifier() failed in hci_register_dev(), the debugfs create by debugfs_create_dir() do not removed in the error handing path. Add the remove debugfs code to fix it. Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com> Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- net/bluetooth/hci_core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c index 8a47a3017d61d..cc48a8a9901c0 100644 --- a/net/bluetooth/hci_core.c +++ b/net/bluetooth/hci_core.c @@ -3998,6 +3998,7 @@ int hci_register_dev(struct hci_dev *hdev) return id; err_wqueue: + debugfs_remove_recursive(hdev->debugfs); destroy_workqueue(hdev->workqueue); destroy_workqueue(hdev->req_workqueue); err: -- 2.34.1

2 years, 11 months

3
192
0 0

[PATCH AUTOSEL 5.16 001/217] Bluetooth: hci_sock: purge socket queues in the destruct() callback

by Sasha Levin

From: Nguyen Dinh Phi <phind.uet(a)gmail.com> [ Upstream commit 709fca500067524381e28a5f481882930eebac88 ] The receive path may take the socket right before hci_sock_release(), but it may enqueue the packets to the socket queues after the call to skb_queue_purge(), therefore the socket can be destroyed without clear its queues completely. Moving these skb_queue_purge() to the hci_sock_destruct() will fix this issue, because nothing is referencing the socket at this point. Signed-off-by: Nguyen Dinh Phi <phind.uet(a)gmail.com> Reported-by: syzbot+4c4ffd1e1094dae61035(a)syzkaller.appspotmail.com Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- net/bluetooth/hci_sock.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c index d0dad1fafe079..446573a125711 100644 --- a/net/bluetooth/hci_sock.c +++ b/net/bluetooth/hci_sock.c @@ -889,10 +889,6 @@ static int hci_sock_release(struct socket *sock) } sock_orphan(sk); - - skb_queue_purge(&sk->sk_receive_queue); - skb_queue_purge(&sk->sk_write_queue); - release_sock(sk); sock_put(sk); return 0; @@ -2058,6 +2054,12 @@ static int hci_sock_getsockopt(struct socket *sock, int level, int optname, return err; } +static void hci_sock_destruct(struct sock *sk) +{ + skb_queue_purge(&sk->sk_receive_queue); + skb_queue_purge(&sk->sk_write_queue); +} + static const struct proto_ops hci_sock_ops = { .family = PF_BLUETOOTH, .owner = THIS_MODULE, @@ -2111,6 +2113,7 @@ static int hci_sock_create(struct net *net, struct socket *sock, int protocol, sock->state = SS_UNCONNECTED; sk->sk_state = BT_OPEN; + sk->sk_destruct = hci_sock_destruct; bt_sock_link(&hci_sk_list, sk); return 0; -- 2.34.1

2 years, 11 months

5
225
0 0

[PATCH AUTOSEL 5.10 01/34] ALSA: usb-audio: Fix dB level of Bose Revolve+ SoundLink

by Sasha Levin

From: Takashi Iwai <tiwai(a)suse.de> [ Upstream commit 02eb1d098e26f34c8f047b0b1cee6f4433a34bd1 ] Bose Revolve+ SoundLink (0a57:40fa) advertises invalid dB level for the speaker volume. This patch provides the correction in the mixer map quirk table entry. Note that this requires the prerequisite change to add min_mute flag to the dB map table. BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1192375 Link: https://lore.kernel.org/r/20211116065415.11159-4-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/usb/mixer_maps.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/sound/usb/mixer_maps.c b/sound/usb/mixer_maps.c index 8f6823df944ff..01a30968e7e1f 100644 --- a/sound/usb/mixer_maps.c +++ b/sound/usb/mixer_maps.c @@ -337,6 +337,13 @@ static const struct usbmix_name_map bose_companion5_map[] = { { 0 } /* terminator */ }; +/* Bose Revolve+ SoundLink, correction of dB maps */ +static const struct usbmix_dB_map bose_soundlink_dB = {-8283, -0, true}; +static const struct usbmix_name_map bose_soundlink_map[] = { + { 2, NULL, .dB = &bose_soundlink_dB }, + { 0 } /* terminator */ +}; + /* Sennheiser Communications Headset [PC 8], the dB value is reported as -6 negative maximum */ static const struct usbmix_dB_map sennheiser_pc8_dB = {-9500, 0}; static const struct usbmix_name_map sennheiser_pc8_map[] = { @@ -551,6 +558,11 @@ static const struct usbmix_ctl_map usbmix_ctl_maps[] = { .id = USB_ID(0x05a7, 0x1020), .map = bose_companion5_map, }, + { + /* Bose Revolve+ SoundLink */ + .id = USB_ID(0x05a7, 0x40fa), + .map = bose_soundlink_map, + }, { /* Corsair Virtuoso SE (wired mode) */ .id = USB_ID(0x1b1c, 0x0a3d), -- 2.34.1

2 years, 11 months

2
35
0 0

[PATCH AUTOSEL 5.16 01/52] clk: imx: Use div64_ul instead of do_div

by Sasha Levin

From: Changcheng Deng <deng.changcheng(a)zte.com.cn> [ Upstream commit c1b6ad9a902539f9c037b6b3c35cb134c5724022 ] do_div() does a 64-by-32 division. Here the divisor is an unsigned long which on some platforms is 64 bit wide. So use div64_ul instead of do_div to avoid a possible truncation. Reported-by: Zeal Robot <zealci(a)zte.com.cn> Signed-off-by: Changcheng Deng <deng.changcheng(a)zte.com.cn> Reviewed-by: Abel Vesa <abel.vesa(a)nxp.com> Link: https://lore.kernel.org/r/20211118080634.165275-1-deng.changcheng@zte.com.cn Signed-off-by: Abel Vesa <abel.vesa(a)nxp.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/clk/imx/clk-pllv3.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c index 20ee9611ba6e3..eea32f87c60aa 100644 --- a/drivers/clk/imx/clk-pllv3.c +++ b/drivers/clk/imx/clk-pllv3.c @@ -247,7 +247,7 @@ static long clk_pllv3_av_round_rate(struct clk_hw *hw, unsigned long rate, div = rate / parent_rate; temp64 = (u64) (rate - div * parent_rate); temp64 *= mfd; - do_div(temp64, parent_rate); + temp64 = div64_ul(temp64, parent_rate); mfn = temp64; temp64 = (u64)parent_rate; @@ -277,7 +277,7 @@ static int clk_pllv3_av_set_rate(struct clk_hw *hw, unsigned long rate, div = rate / parent_rate; temp64 = (u64) (rate - div * parent_rate); temp64 *= mfd; - do_div(temp64, parent_rate); + temp64 = div64_ul(temp64, parent_rate); mfn = temp64; val = readl_relaxed(pll->base); @@ -334,7 +334,7 @@ static struct clk_pllv3_vf610_mf clk_pllv3_vf610_rate_to_mf( /* rate = parent_rate * (mfi + mfn/mfd) */ temp64 = rate - parent_rate * mf.mfi; temp64 *= mf.mfd; - do_div(temp64, parent_rate); + temp64 = div64_ul(temp64, parent_rate); mf.mfn = temp64; } -- 2.34.1

2 years, 11 months

5
58
0 0

Very Importante Notice

by Vlieghe

Sir/Madam, Good day to you. I am Dr.Gertjan Vlieghe personal Secretary to Andrew Bailey who double as the Governor, Bank of England (https://en.wikipedia.org/wiki/Andrew_Bailey_%28banker%29). We have an inheritance of a deceased client, who bear the same name with your surname. kindly contact Andrew Bailey through his personal email ( andbaill228(a)mail2world.com ) with your details for more information. Thank you. Dr.Gertjan Vlieghe

2 years, 11 months

1
0
0 0

FINANZIELLE HILFE

by Mr. Anthony Rolle

-- BENÖTIGEN SIE EIN PERSÖNLICHES DARLEHEN ODER EIN GESCHÄFTSDARLEHEN, EIN DARLEHEN VON €5000 BIS €90.000.000? WENN JA, KONTAKTIEREN SIE UNS PER E-MAIL: anthonyloanfunds(a)gmail.com MIT DEN UNTENSTEHENDEN INFORMATIONEN. Ihr vollständiger Name: ... Benötigte Menge:... Dauer: .. Telefon: .... Land: .. Kontakt über: anthonyloanfunds(a)gmail.com

2 years, 11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2022