--- /dev/null
+From d2f8114f9574509580a8506d2ef72e7e43d1a5bd Mon Sep 17 00:00:00 2001
+From: Aditya Garg <gargaditya08@live.com>
+Date: Thu, 2 Dec 2021 12:41:59 +0000
+Subject: Bluetooth: add quirk disabling LE Read Transmit Power
+
+From: Aditya Garg <gargaditya08@live.com>
+
+commit d2f8114f9574509580a8506d2ef72e7e43d1a5bd upstream.
+
+Some devices have a bug causing them to not work if they query
+LE tx power on startup. Thus we add a quirk in order to not query it
+and default min/max tx power values to HCI_TX_POWER_INVALID.
+
+Signed-off-by: Aditya Garg <gargaditya08@live.com>
+Reported-by: Orlando Chamberlain <redecorating@protonmail.com>
+Tested-by: Orlando Chamberlain <redecorating@protonmail.com>
+Link:
+https://lore.kernel.org/r/4970a940-211b-25d6-edab-21a815313954@protonmail.com
+Fixes: 7c395ea521e6 ("Bluetooth: Query LE tx power on startup")
+Cc: stable@vger.kernel.org
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/net/bluetooth/hci.h | 9 +++++++++
+ net/bluetooth/hci_core.c | 3 ++-
+ 2 files changed, 11 insertions(+), 1 deletion(-)
+
+--- a/include/net/bluetooth/hci.h
++++ b/include/net/bluetooth/hci.h
+@@ -246,6 +246,15 @@ enum {
+ * HCI after resume.
+ */
+ HCI_QUIRK_NO_SUSPEND_NOTIFIER,
++
++ /*
++ * When this quirk is set, LE tx power is not queried on startup
++ * and the min/max tx power values default to HCI_TX_POWER_INVALID.
++ *
++ * This quirk can be set before hci_register_dev is called or
++ * during the hdev->setup vendor callback.
++ */
++ HCI_QUIRK_BROKEN_READ_TRANSMIT_POWER,
+ };
+
+ /* HCI device flags */
+--- a/net/bluetooth/hci_core.c
++++ b/net/bluetooth/hci_core.c
+@@ -619,7 +619,8 @@ static int hci_init3_req(struct hci_requ
+ hci_req_add(req, HCI_OP_LE_READ_ADV_TX_POWER, 0, NULL);
+ }
+
+- if (hdev->commands[38] & 0x80) {
++ if ((hdev->commands[38] & 0x80) &&
++ !test_bit(HCI_QUIRK_BROKEN_READ_TRANSMIT_POWER, &hdev->quirks)) {
+ /* Read LE Min/Max Tx Power*/
+ hci_req_add(req, HCI_OP_LE_READ_TRANSMIT_POWER,
+ 0, NULL);
--- /dev/null
+From 3318ae23bbcb14b7f68e9006756ba6d970955635 Mon Sep 17 00:00:00 2001
+From: Aditya Garg <gargaditya08@live.com>
+Date: Mon, 3 Jan 2022 13:28:42 +0000
+Subject: Bluetooth: btbcm: disable read tx power for MacBook Air 8,1 and 8,2
+
+From: Aditya Garg <gargaditya08@live.com>
+
+commit 3318ae23bbcb14b7f68e9006756ba6d970955635 upstream.
+
+The MacBook Air 8,1 and 8,2 also need querying of LE Tx power
+to be disabled for Bluetooth to work.
+
+Signed-off-by: Aditya Garg <gargaditya08@live.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/bluetooth/btbcm.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/drivers/bluetooth/btbcm.c
++++ b/drivers/bluetooth/btbcm.c
+@@ -366,6 +366,18 @@ static const struct dmi_system_id disabl
+ {
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Apple Inc."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookAir8,1"),
++ },
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_BOARD_VENDOR, "Apple Inc."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookAir8,2"),
++ },
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_BOARD_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "iMac20,1"),
+ },
+ },
--- /dev/null
+From 801b4c027b44a185292007d3cf7513999d644723 Mon Sep 17 00:00:00 2001
+From: Aditya Garg <gargaditya08@live.com>
+Date: Thu, 2 Dec 2021 12:42:59 +0000
+Subject: Bluetooth: btbcm: disable read tx power for some Macs with the T2 Security chip
+
+From: Aditya Garg <gargaditya08@live.com>
+
+commit 801b4c027b44a185292007d3cf7513999d644723 upstream.
+
+Some Macs with the T2 security chip had Bluetooth not working.
+To fix it we add DMI based quirks to disable querying of LE Tx power.
+
+Signed-off-by: Aditya Garg <gargaditya08@live.com>
+Reported-by: Orlando Chamberlain <redecorating@protonmail.com>
+Tested-by: Orlando Chamberlain <redecorating@protonmail.com>
+Link:
+https://lore.kernel.org/r/4970a940-211b-25d6-edab-21a815313954@protonmail.com
+Fixes: 7c395ea521e6 ("Bluetooth: Query LE tx power on startup")
+Cc: stable@vger.kernel.org
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/bluetooth/btbcm.c | 39 +++++++++++++++++++++++++++++++++++++++
+ 1 file changed, 39 insertions(+)
+
+--- a/drivers/bluetooth/btbcm.c
++++ b/drivers/bluetooth/btbcm.c
+@@ -8,6 +8,7 @@
+
+ #include <linux/module.h>
+ #include <linux/firmware.h>
++#include <linux/dmi.h>
+ #include <asm/unaligned.h>
+
+ #include <net/bluetooth/bluetooth.h>
+@@ -343,6 +344,40 @@ static struct sk_buff *btbcm_read_usb_pr
+ return skb;
+ }
+
++static const struct dmi_system_id disable_broken_read_transmit_power[] = {
++ {
++ .matches = {
++ DMI_MATCH(DMI_BOARD_VENDOR, "Apple Inc."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,1"),
++ },
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_BOARD_VENDOR, "Apple Inc."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,2"),
++ },
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_BOARD_VENDOR, "Apple Inc."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,4"),
++ },
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_BOARD_VENDOR, "Apple Inc."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "iMac20,1"),
++ },
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_BOARD_VENDOR, "Apple Inc."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "iMac20,2"),
++ },
++ },
++ { }
++};
++
+ static int btbcm_read_info(struct hci_dev *hdev)
+ {
+ struct sk_buff *skb;
+@@ -363,6 +398,10 @@ static int btbcm_read_info(struct hci_de
+ bt_dev_info(hdev, "BCM: features 0x%2.2x", skb->data[1]);
+ kfree_skb(skb);
+
++ /* Read DMI and disable broken Read LE Min/Max Tx Power */
++ if (dmi_first_match(disable_broken_read_transmit_power))
++ set_bit(HCI_QUIRK_BROKEN_READ_TRANSMIT_POWER, &hdev->quirks);
++
+ return 0;
+ }
+
--- /dev/null
+From c9e143084d1a602f829115612e1ec79df3727c8b Mon Sep 17 00:00:00 2001
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Date: Mon, 1 Nov 2021 21:00:08 +0200
+Subject: mfd: intel-lpss: Fix too early PM enablement in the ACPI ->probe()
+
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+commit c9e143084d1a602f829115612e1ec79df3727c8b upstream.
+
+The runtime PM callback may be called as soon as the runtime PM facility
+is enabled and activated. It means that ->suspend() may be called before
+we finish probing the device in the ACPI case. Hence, NULL pointer
+dereference:
+
+ intel-lpss INT34BA:00: IRQ index 0 not found
+ BUG: kernel NULL pointer dereference, address: 0000000000000030
+ ...
+ Workqueue: pm pm_runtime_work
+ RIP: 0010:intel_lpss_suspend+0xb/0x40 [intel_lpss]
+
+To fix this, first try to register the device and only after that enable
+runtime PM facility.
+
+Fixes: 4b45efe85263 ("mfd: Add support for Intel Sunrisepoint LPSS devices")
+Reported-by: Orlando Chamberlain <redecorating@protonmail.com>
+Reported-by: Aditya Garg <gargaditya08@live.com>
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Tested-by: Aditya Garg <gargaditya08@live.com>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Link: https://lore.kernel.org/r/20211101190008.86473-1-andriy.shevchenko@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mfd/intel-lpss-acpi.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/mfd/intel-lpss-acpi.c
++++ b/drivers/mfd/intel-lpss-acpi.c
+@@ -136,6 +136,7 @@ static int intel_lpss_acpi_probe(struct
+ {
+ struct intel_lpss_platform_info *info;
+ const struct acpi_device_id *id;
++ int ret;
+
+ id = acpi_match_device(intel_lpss_acpi_ids, &pdev->dev);
+ if (!id)
+@@ -149,10 +150,14 @@ static int intel_lpss_acpi_probe(struct
+ info->mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ info->irq = platform_get_irq(pdev, 0);
+
++ ret = intel_lpss_probe(&pdev->dev, info);
++ if (ret)
++ return ret;
++
+ pm_runtime_set_active(&pdev->dev);
+ pm_runtime_enable(&pdev->dev);
+
+- return intel_lpss_probe(&pdev->dev, info);
++ return 0;
+ }
+
+ static int intel_lpss_acpi_remove(struct platform_device *pdev)
usb-fix-slab-out-of-bounds-write-bug-in-usb_hcd_poll_rh_status.patch
ath11k-fix-buffer-overflow-when-scanning-with-extraie.patch
mmc-sdhci-pci-add-pci-id-for-intel-adl.patch
+bluetooth-add-quirk-disabling-le-read-transmit-power.patch
+bluetooth-btbcm-disable-read-tx-power-for-some-macs-with-the-t2-security-chip.patch
+bluetooth-btbcm-disable-read-tx-power-for-macbook-air-8-1-and-8-2.patch
+veth-do-not-record-rx-queue-hint-in-veth_xmit.patch
+mfd-intel-lpss-fix-too-early-pm-enablement-in-the-acpi-probe.patch
+x86-mce-remove-noinstr-annotation-from-mce_setup.patch
--- /dev/null
+From 710ad98c363a66a0cd8526465426c5c5f8377ee0 Mon Sep 17 00:00:00 2001
+From: Daniel Borkmann <daniel@iogearbox.net>
+Date: Thu, 6 Jan 2022 01:46:06 +0100
+Subject: veth: Do not record rx queue hint in veth_xmit
+
+From: Daniel Borkmann <daniel@iogearbox.net>
+
+commit 710ad98c363a66a0cd8526465426c5c5f8377ee0 upstream.
+
+Laurent reported that they have seen a significant amount of TCP retransmissions
+at high throughput from applications residing in network namespaces talking to
+the outside world via veths. The drops were seen on the qdisc layer (fq_codel,
+as per systemd default) of the phys device such as ena or virtio_net due to all
+traffic hitting a _single_ TX queue _despite_ multi-queue device. (Note that the
+setup was _not_ using XDP on veths as the issue is generic.)
+
+More specifically, after edbea9220251 ("veth: Store queue_mapping independently
+of XDP prog presence") which made it all the way back to v4.19.184+,
+skb_record_rx_queue() would set skb->queue_mapping to 1 (given 1 RX and 1 TX
+queue by default for veths) instead of leaving at 0.
+
+This is eventually retained and callbacks like ena_select_queue() will also pick
+single queue via netdev_core_pick_tx()'s ndo_select_queue() once all the traffic
+is forwarded to that device via upper stack or other means. Similarly, for others
+not implementing ndo_select_queue() if XPS is disabled, netdev_pick_tx() might
+call into the skb_tx_hash() and check for prior skb_rx_queue_recorded() as well.
+
+In general, it is a _bad_ idea for virtual devices like veth to mess around with
+queue selection [by default]. Given dev->real_num_tx_queues is by default 1,
+the skb->queue_mapping was left untouched, and so prior to edbea9220251 the
+netdev_core_pick_tx() could do its job upon __dev_queue_xmit() on the phys device.
+
+Unbreak this and restore prior behavior by removing the skb_record_rx_queue()
+from veth_xmit() altogether.
+
+If the veth peer has an XDP program attached, then it would return the first RX
+queue index in xdp_md->rx_queue_index (unless configured in non-default manner).
+However, this is still better than breaking the generic case.
+
+Fixes: edbea9220251 ("veth: Store queue_mapping independently of XDP prog presence")
+Fixes: 638264dc9022 ("veth: Support per queue XDP ring")
+Reported-by: Laurent Bernaille <laurent.bernaille@datadoghq.com>
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Cc: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
+Cc: Toshiaki Makita <toshiaki.makita1@gmail.com>
+Cc: Eric Dumazet <eric.dumazet@gmail.com>
+Cc: Paolo Abeni <pabeni@redhat.com>
+Cc: John Fastabend <john.fastabend@gmail.com>
+Cc: Willem de Bruijn <willemb@google.com>
+Acked-by: John Fastabend <john.fastabend@gmail.com>
+Reviewed-by: Eric Dumazet <edumazet@google.com>
+Acked-by: Toshiaki Makita <toshiaki.makita1@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/veth.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/drivers/net/veth.c
++++ b/drivers/net/veth.c
+@@ -342,7 +342,6 @@ static netdev_tx_t veth_xmit(struct sk_b
+ */
+ use_napi = rcu_access_pointer(rq->napi) &&
+ veth_skb_is_eligible_for_gro(dev, rcv, skb);
+- skb_record_rx_queue(skb, rxq);
+ }
+
+ skb_tx_timestamp(skb);
--- /dev/null
+From 487d654db3edacc31dee86b10258cc740640fad8 Mon Sep 17 00:00:00 2001
+From: Borislav Petkov <bp@suse.de>
+Date: Tue, 5 Oct 2021 19:54:47 +0200
+Subject: x86/mce: Remove noinstr annotation from mce_setup()
+
+From: Borislav Petkov <bp@suse.de>
+
+commit 487d654db3edacc31dee86b10258cc740640fad8 upstream.
+
+Instead, sandwitch around the call which is done in noinstr context and
+mark the caller - mce_gather_info() - as noinstr.
+
+Also, document what the whole instrumentation strategy with #MC is going
+to be in the future and where it all is supposed to be going to.
+
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Link: https://lore.kernel.org/r/20211208111343.8130-5-bp@alien8.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cpu/mce/core.c | 26 ++++++++++++++++++++------
+ 1 file changed, 20 insertions(+), 6 deletions(-)
+
+--- a/arch/x86/kernel/cpu/mce/core.c
++++ b/arch/x86/kernel/cpu/mce/core.c
+@@ -128,7 +128,7 @@ static struct irq_work mce_irq_work;
+ BLOCKING_NOTIFIER_HEAD(x86_mce_decoder_chain);
+
+ /* Do initial initialization of a struct mce */
+-noinstr void mce_setup(struct mce *m)
++void mce_setup(struct mce *m)
+ {
+ memset(m, 0, sizeof(struct mce));
+ m->cpu = m->extcpu = smp_processor_id();
+@@ -433,9 +433,15 @@ static noinstr void mce_wrmsrl(u32 msr,
+ * check into our "mce" struct so that we can use it later to assess
+ * the severity of the problem as we read per-bank specific details.
+ */
+-static inline void mce_gather_info(struct mce *m, struct pt_regs *regs)
++static noinstr void mce_gather_info(struct mce *m, struct pt_regs *regs)
+ {
++ /*
++ * Enable instrumentation around mce_setup() which calls external
++ * facilities.
++ */
++ instrumentation_begin();
+ mce_setup(m);
++ instrumentation_end();
+
+ m->mcgstatus = mce_rdmsrl(MSR_IA32_MCG_STATUS);
+ if (regs) {
+@@ -1320,11 +1326,11 @@ static noinstr void unexpected_machine_c
+ }
+
+ /*
+- * The actual machine check handler. This only handles real
+- * exceptions when something got corrupted coming in through int 18.
++ * The actual machine check handler. This only handles real exceptions when
++ * something got corrupted coming in through int 18.
+ *
+- * This is executed in NMI context not subject to normal locking rules. This
+- * implies that most kernel services cannot be safely used. Don't even
++ * This is executed in #MC context not subject to normal locking rules.
++ * This implies that most kernel services cannot be safely used. Don't even
+ * think about putting a printk in there!
+ *
+ * On Intel systems this is entered on all CPUs in parallel through
+@@ -1336,6 +1342,14 @@ static noinstr void unexpected_machine_c
+ * issues: if the machine check was due to a failure of the memory
+ * backing the user stack, tracing that reads the user stack will cause
+ * potentially infinite recursion.
++ *
++ * Currently, the #MC handler calls out to a number of external facilities
++ * and, therefore, allows instrumentation around them. The optimal thing to
++ * have would be to do the absolutely minimal work required in #MC context
++ * and have instrumentation disabled only around that. Further processing can
++ * then happen in process context where instrumentation is allowed. Achieving
++ * that requires careful auditing and modifications. Until then, the code
++ * allows instrumentation temporarily, where required. *
+ */
+ noinstr void do_machine_check(struct pt_regs *regs)
+ {
projects / thirdparty / kernel / stable-queue.git / commitdiff
