--- /dev/null
+From 517b693351a2d04f3af1fc0e506ac7e1346094de Mon Sep 17 00:00:00 2001
+From: Trent Piepho <tpiepho@gmail.com>
+Date: Wed, 9 Dec 2020 17:20:03 -0800
+Subject: Bluetooth: btusb: Always fallback to alt 1 for WBS
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Trent Piepho <tpiepho@gmail.com>
+
+commit 517b693351a2d04f3af1fc0e506ac7e1346094de upstream.
+
+When alt mode 6 is not available, fallback to the kernel <= 5.7 behavior
+of always using alt mode 1.
+
+Prior to kernel 5.8, btusb would always use alt mode 1 for WBS (Wide
+Band Speech aka mSBC aka transparent SCO). In commit baac6276c0a9
+("Bluetooth: btusb: handle mSBC audio over USB Endpoints") this
+was changed to use alt mode 6, which is the recommended mode in the
+Bluetooth spec (Specifications of the Bluetooth System, v5.0, Vol 4.B
+ยง2.2.1). However, many if not most BT USB adapters do not support alt
+mode 6. In fact, I have been unable to find any which do.
+
+In kernel 5.8, this was changed to use alt mode 6, and if not available,
+use alt mode 0. But mode 0 has a zero byte max packet length and can
+not possibly work. It is just there as a zero-bandwidth dummy mode to
+work around a USB flaw that would prevent device enumeration if
+insufficient bandwidth were available for the lowest isoc mode
+supported.
+
+In effect, WBS was broken for all USB-BT adapters that do not support
+alt 6, which appears to nearly all of them.
+
+Then in commit 461f95f04f19 ("Bluetooth: btusb: USB alternate setting 1 for
+WBS") the 5.7 behavior was restored, but only for Realtek adapters.
+
+I've tested a Broadcom BRCM20702A and CSR 8510 adapter, both work with
+the 5.7 behavior and do not with the 5.8.
+
+So get rid of the Realtek specific flag and use the 5.7 behavior for all
+adapters as a fallback when alt 6 is not available. This was the
+kernel's behavior prior to 5.8 and I can find no adapters for which it
+is not correct. And even if there is an adapter for which this does not
+work, the current behavior would be to fall back to alt 0, which can not
+possibly work either, and so is no better.
+
+Signed-off-by: Trent Piepho <tpiepho@gmail.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Cc: Salvatore Bonaccorso <carnil@debian.org>
+Cc: Sjoerd Simons <sjoerd@luon.net>
+Cc: Sebastian Reichel <sre@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/bluetooth/btusb.c | 20 ++++++--------------
+ 1 file changed, 6 insertions(+), 14 deletions(-)
+
+--- a/drivers/bluetooth/btusb.c
++++ b/drivers/bluetooth/btusb.c
+@@ -480,7 +480,6 @@ static const struct dmi_system_id btusb_
+ #define BTUSB_HW_RESET_ACTIVE 12
+ #define BTUSB_TX_WAIT_VND_EVT 13
+ #define BTUSB_WAKEUP_DISABLE 14
+-#define BTUSB_USE_ALT1_FOR_WBS 15
+
+ struct btusb_data {
+ struct hci_dev *hdev;
+@@ -1710,15 +1709,12 @@ static void btusb_work(struct work_struc
+ new_alts = data->sco_num;
+ }
+ } else if (data->air_mode == HCI_NOTIFY_ENABLE_SCO_TRANSP) {
+- /* Check if Alt 6 is supported for Transparent audio */
+- if (btusb_find_altsetting(data, 6)) {
+- data->usb_alt6_packet_flow = true;
+- new_alts = 6;
+- } else if (test_bit(BTUSB_USE_ALT1_FOR_WBS, &data->flags)) {
+- new_alts = 1;
+- } else {
+- bt_dev_err(hdev, "Device does not support ALT setting 6");
+- }
++ /* Bluetooth USB spec recommends alt 6 (63 bytes), but
++ * many adapters do not support it. Alt 1 appears to
++ * work for all adapters that do not have alt 6, and
++ * which work with WBS at all.
++ */
++ new_alts = btusb_find_altsetting(data, 6) ? 6 : 1;
+ }
+
+ if (btusb_switch_alt_setting(hdev, new_alts) < 0)
+@@ -4149,10 +4145,6 @@ static int btusb_probe(struct usb_interf
+ * (DEVICE_REMOTE_WAKEUP)
+ */
+ set_bit(BTUSB_WAKEUP_DISABLE, &data->flags);
+- if (btusb_find_altsetting(data, 1))
+- set_bit(BTUSB_USE_ALT1_FOR_WBS, &data->flags);
+- else
+- bt_dev_err(hdev, "Device does not support ALT setting 1");
+ }
+
+ if (!reset)
--- /dev/null
+From dsterba@suse.com Mon Feb 22 11:17:29 2021
+From: David Sterba <dsterba@suse.com>
+Date: Fri, 19 Feb 2021 19:00:16 +0100
+Subject: btrfs: fix backport of 2175bf57dc952 in 5.10.13
+To: stable@vger.kernel.org
+Cc: wangyugui@e16-tech.com, David Sterba <dsterba@suse.cz>, David Sterba <dsterba@suse.com>
+Message-ID: <20210219180016.4759-1-dsterba@suse.com>
+
+From: David Sterba <dsterba@suse.com>
+
+There's a mistake in backport of upstream commit 2175bf57dc95 ("btrfs:
+fix possible free space tree corruption with online conversion") as
+5.10.13 commit 2175bf57dc95.
+
+The enum value BTRFS_FS_FREE_SPACE_TREE_UNTRUSTED has been added to the
+wrong enum set, colliding with value of BTRFS_FS_QUOTA_ENABLE. This
+could cause problems during the tree conversion, where the quotas
+wouldn't be set up properly but the related code executed anyway due to
+the bit set.
+
+Link: https://lore.kernel.org/linux-btrfs/20210219111741.95DD.409509F4@e16-tech.com
+Reported-by: Wang Yugui <wangyugui@e16-tech.com>
+CC: stable@vger.kernel.org # 5.10.13+
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/ctree.h | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/fs/btrfs/ctree.h
++++ b/fs/btrfs/ctree.h
+@@ -146,9 +146,6 @@ enum {
+ BTRFS_FS_STATE_DEV_REPLACING,
+ /* The btrfs_fs_info created for self-tests */
+ BTRFS_FS_STATE_DUMMY_FS_INFO,
+-
+- /* Indicate that we can't trust the free space tree for caching yet */
+- BTRFS_FS_FREE_SPACE_TREE_UNTRUSTED,
+ };
+
+ #define BTRFS_BACKREF_REV_MAX 256
+@@ -562,6 +559,9 @@ enum {
+
+ /* Indicate that the discard workqueue can service discards. */
+ BTRFS_FS_DISCARD_RUNNING,
++
++ /* Indicate that we can't trust the free space tree for caching yet */
++ BTRFS_FS_FREE_SPACE_TREE_UNTRUSTED,
+ };
+
+ /*
--- /dev/null
+From 3342ff2698e9720f4040cc458a2744b2b32f5c3a Mon Sep 17 00:00:00 2001
+From: Linus Torvalds <torvalds@linux-foundation.org>
+Date: Sat, 20 Feb 2021 21:15:00 -0800
+Subject: tty: protect tty_write from odd low-level tty disciplines
+
+From: Linus Torvalds <torvalds@linux-foundation.org>
+
+commit 3342ff2698e9720f4040cc458a2744b2b32f5c3a upstream.
+
+Al root-caused a new warning from syzbot to the ttyprintk tty driver
+returning a write count larger than the data the tty layer actually gave
+it. Which confused the tty write code mightily, and with the new
+iov_iter based code, caused a WARNING in iov_iter_revert().
+
+syzbot correctly bisected the source of the new warning to commit
+9bb48c82aced ("tty: implement write_iter"), but the oddity goes back
+much further, it just didn't get caught by anything before.
+
+Reported-by: syzbot+3d2c27c2b7dc2a94814d@syzkaller.appspotmail.com
+Fixes: 9bb48c82aced ("tty: implement write_iter")
+Debugged-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/tty_io.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/tty/tty_io.c
++++ b/drivers/tty/tty_io.c
+@@ -963,11 +963,14 @@ static inline ssize_t do_tty_write(
+ if (ret <= 0)
+ break;
+
++ written += ret;
++ if (ret > size)
++ break;
++
+ /* FIXME! Have Al check this! */
+ if (ret != size)
+ iov_iter_revert(from, size-ret);
+
+- written += ret;
+ count -= ret;
+ if (!count)
+ break;
projects / thirdparty / kernel / stable-queue.git / commitdiff
