2020-10-16 09:17:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 00/22] 5.4.72-rc1 review

This is the start of the stable review cycle for the 5.4.72 release.
There are 22 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun, 18 Oct 2020 09:04:25 +0000.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.72-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>
Linux 5.4.72-rc1

Dominik Przychodni <[email protected]>
crypto: qat - check cipher length for aead AES-CBC-HMAC-SHA

Herbert Xu <[email protected]>
crypto: bcm - Verify GCM/CCM key length in setkey

Juergen Gross <[email protected]>
xen/events: don't use chip_data for legacy IRQs

Jan Kara <[email protected]>
reiserfs: Fix oops during mount

Jan Kara <[email protected]>
reiserfs: Initialize inode keys properly

Mychaela N. Falconia <[email protected]>
USB: serial: ftdi_sio: add support for FreeCalypso JTAG+UART adapters

Scott Chen <[email protected]>
USB: serial: pl2303: add device-id for HP GC device

Anant Thazhemadam <[email protected]>
staging: comedi: check validity of wMaxPacketSize of usb endpoints found

Leonid Bloch <[email protected]>
USB: serial: option: Add Telit FT980-KS composition

Wilken Gottwalt <[email protected]>
USB: serial: option: add Cellient MPL200 card

Oliver Neukum <[email protected]>
media: usbtv: Fix refcounting mixup

Luiz Augusto von Dentz <[email protected]>
Bluetooth: Disconnect if E0 is used for Level 4

Patrick Steinhardt <[email protected]>
Bluetooth: Fix update of connection state in `hci_encrypt_cfm`

Luiz Augusto von Dentz <[email protected]>
Bluetooth: Consolidate encryption handling in hci_encrypt_cfm

Luiz Augusto von Dentz <[email protected]>
Bluetooth: MGMT: Fix not checking if BT_HS is enabled

Luiz Augusto von Dentz <[email protected]>
Bluetooth: L2CAP: Fix calling sk_filter on non-socket based channel

Luiz Augusto von Dentz <[email protected]>
Bluetooth: A2MP: Fix not initializing all members

Arjan van de Ven <[email protected]>
ACPI: Always build evged in

Dmitry Golovin <[email protected]>
ARM: 8939/1: kbuild: use correct nm executable

Josef Bacik <[email protected]>
btrfs: take overcommit into account in inc_block_group_ro

Josef Bacik <[email protected]>
btrfs: don't pass system_chunk into can_overcommit

Leo Yan <[email protected]>
perf cs-etm: Move definition of 'traceid_list' global variable from header file


-------------

Diffstat:

Makefile | 4 +--
arch/arm/boot/compressed/Makefile | 4 +--
drivers/acpi/Makefile | 2 +-
drivers/crypto/bcm/cipher.c | 15 +++++++++-
drivers/crypto/qat/qat_common/qat_algs.c | 10 ++++++-
drivers/media/usb/usbtv/usbtv-core.c | 3 +-
drivers/staging/comedi/drivers/vmk80xx.c | 3 ++
drivers/usb/serial/ftdi_sio.c | 5 ++++
drivers/usb/serial/ftdi_sio_ids.h | 7 +++++
drivers/usb/serial/option.c | 5 ++++
drivers/usb/serial/pl2303.c | 1 +
drivers/usb/serial/pl2303.h | 1 +
drivers/xen/events/events_base.c | 29 +++++++++++++-----
fs/btrfs/block-group.c | 38 ++++++++++++++++--------
fs/btrfs/space-info.c | 50 +++++++++++++-------------------
fs/btrfs/space-info.h | 3 ++
fs/reiserfs/inode.c | 6 +---
fs/reiserfs/xattr.c | 7 +++++
include/net/bluetooth/hci_core.h | 30 +++++++++++++++----
include/net/bluetooth/l2cap.h | 2 ++
net/bluetooth/a2mp.c | 22 +++++++++++++-
net/bluetooth/hci_conn.c | 17 +++++++++++
net/bluetooth/hci_event.c | 48 +++++++-----------------------
net/bluetooth/l2cap_core.c | 7 +++--
net/bluetooth/l2cap_sock.c | 14 +++++++++
net/bluetooth/mgmt.c | 7 ++++-
tools/perf/util/cs-etm.c | 3 ++
tools/perf/util/cs-etm.h | 3 --
28 files changed, 232 insertions(+), 114 deletions(-)



2020-10-16 12:38:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 14/22] USB: serial: option: Add Telit FT980-KS composition

From: Leonid Bloch <[email protected]>

commit 924a9213358fb92fa3c3225d6d042aa058167405 upstream.

This commit adds the following Telit FT980-KS composition:

0x1054: rndis, diag, adb, nmea, modem, modem, aux

AT commands can be sent to /dev/ttyUSB2.

Signed-off-by: Leonid Bloch <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/serial/option.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1187,6 +1187,8 @@ static const struct usb_device_id option
.driver_info = NCTRL(2) | RSVD(3) },
{ USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1053, 0xff), /* Telit FN980 (ECM) */
.driver_info = NCTRL(0) | RSVD(1) },
+ { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1054, 0xff), /* Telit FT980-KS */
+ .driver_info = NCTRL(2) | RSVD(3) },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_ME910),
.driver_info = NCTRL(0) | RSVD(1) | RSVD(3) },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_ME910_DUAL_MODEM),


2020-10-16 12:38:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 03/22] btrfs: take overcommit into account in inc_block_group_ro

From: Josef Bacik <[email protected]>

commit a30a3d2067536cbcce26c055e70cc3a6ae4fd45c upstream

inc_block_group_ro does a calculation to see if we have enough room left
over if we mark this block group as read only in order to see if it's ok
to mark the block group as read only.

The problem is this calculation _only_ works for data, where our used is
always less than our total. For metadata we will overcommit, so this
will almost always fail for metadata.

Fix this by exporting btrfs_can_overcommit, and then see if we have
enough space to remove the remaining free space in the block group we
are trying to mark read only. If we do then we can mark this block
group as read only.

Reviewed-by: Qu Wenruo <[email protected]>
Signed-off-by: Josef Bacik <[email protected]>
Reviewed-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Anand Jain <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
fs/btrfs/block-group.c | 38 ++++++++++++++++++++++++++------------
fs/btrfs/space-info.c | 18 ++++++++++--------
fs/btrfs/space-info.h | 3 +++
3 files changed, 39 insertions(+), 20 deletions(-)

diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c
index b167649f5f5de..ace49a999ecec 100644
--- a/fs/btrfs/block-group.c
+++ b/fs/btrfs/block-group.c
@@ -1186,7 +1186,6 @@ static int inc_block_group_ro(struct btrfs_block_group_cache *cache, int force)
{
struct btrfs_space_info *sinfo = cache->space_info;
u64 num_bytes;
- u64 sinfo_used;
u64 min_allocable_bytes;
int ret = -ENOSPC;

@@ -1213,20 +1212,38 @@ static int inc_block_group_ro(struct btrfs_block_group_cache *cache, int force)

num_bytes = cache->key.offset - cache->reserved - cache->pinned -
cache->bytes_super - btrfs_block_group_used(&cache->item);
- sinfo_used = btrfs_space_info_used(sinfo, true);

/*
- * sinfo_used + num_bytes should always <= sinfo->total_bytes.
- *
- * Here we make sure if we mark this bg RO, we still have enough
- * free space as buffer (if min_allocable_bytes is not 0).
+ * Data never overcommits, even in mixed mode, so do just the straight
+ * check of left over space in how much we have allocated.
*/
- if (sinfo_used + num_bytes + min_allocable_bytes <=
- sinfo->total_bytes) {
+ if (force) {
+ ret = 0;
+ } else if (sinfo->flags & BTRFS_BLOCK_GROUP_DATA) {
+ u64 sinfo_used = btrfs_space_info_used(sinfo, true);
+
+ /*
+ * Here we make sure if we mark this bg RO, we still have enough
+ * free space as buffer.
+ */
+ if (sinfo_used + num_bytes <= sinfo->total_bytes)
+ ret = 0;
+ } else {
+ /*
+ * We overcommit metadata, so we need to do the
+ * btrfs_can_overcommit check here, and we need to pass in
+ * BTRFS_RESERVE_NO_FLUSH to give ourselves the most amount of
+ * leeway to allow us to mark this block group as read only.
+ */
+ if (btrfs_can_overcommit(cache->fs_info, sinfo, num_bytes,
+ BTRFS_RESERVE_NO_FLUSH))
+ ret = 0;
+ }
+
+ if (!ret) {
sinfo->bytes_readonly += num_bytes;
cache->ro++;
list_add_tail(&cache->ro_list, &sinfo->ro_bgs);
- ret = 0;
}
out:
spin_unlock(&cache->lock);
@@ -1235,9 +1252,6 @@ static int inc_block_group_ro(struct btrfs_block_group_cache *cache, int force)
btrfs_info(cache->fs_info,
"unable to make block group %llu ro",
cache->key.objectid);
- btrfs_info(cache->fs_info,
- "sinfo_used=%llu bg_num_bytes=%llu min_allocable=%llu",
- sinfo_used, num_bytes, min_allocable_bytes);
btrfs_dump_space_info(cache->fs_info, cache->space_info, 0, 0);
}
return ret;
diff --git a/fs/btrfs/space-info.c b/fs/btrfs/space-info.c
index e19e538d05f93..90500b6c41fc6 100644
--- a/fs/btrfs/space-info.c
+++ b/fs/btrfs/space-info.c
@@ -160,9 +160,9 @@ static inline u64 calc_global_rsv_need_space(struct btrfs_block_rsv *global)
return (global->size << 1);
}

-static int can_overcommit(struct btrfs_fs_info *fs_info,
- struct btrfs_space_info *space_info, u64 bytes,
- enum btrfs_reserve_flush_enum flush)
+int btrfs_can_overcommit(struct btrfs_fs_info *fs_info,
+ struct btrfs_space_info *space_info, u64 bytes,
+ enum btrfs_reserve_flush_enum flush)
{
u64 profile;
u64 avail;
@@ -227,7 +227,8 @@ void btrfs_try_granting_tickets(struct btrfs_fs_info *fs_info,

/* Check and see if our ticket can be satisified now. */
if ((used + ticket->bytes <= space_info->total_bytes) ||
- can_overcommit(fs_info, space_info, ticket->bytes, flush)) {
+ btrfs_can_overcommit(fs_info, space_info, ticket->bytes,
+ flush)) {
btrfs_space_info_update_bytes_may_use(fs_info,
space_info,
ticket->bytes);
@@ -647,13 +648,14 @@ btrfs_calc_reclaim_metadata_size(struct btrfs_fs_info *fs_info,
return to_reclaim;

to_reclaim = min_t(u64, num_online_cpus() * SZ_1M, SZ_16M);
- if (can_overcommit(fs_info, space_info, to_reclaim,
- BTRFS_RESERVE_FLUSH_ALL))
+ if (btrfs_can_overcommit(fs_info, space_info, to_reclaim,
+ BTRFS_RESERVE_FLUSH_ALL))
return 0;

used = btrfs_space_info_used(space_info, true);

- if (can_overcommit(fs_info, space_info, SZ_1M, BTRFS_RESERVE_FLUSH_ALL))
+ if (btrfs_can_overcommit(fs_info, space_info, SZ_1M,
+ BTRFS_RESERVE_FLUSH_ALL))
expected = div_factor_fine(space_info->total_bytes, 95);
else
expected = div_factor_fine(space_info->total_bytes, 90);
@@ -1045,7 +1047,7 @@ static int __reserve_metadata_bytes(struct btrfs_fs_info *fs_info,
*/
if (!pending_tickets &&
((used + orig_bytes <= space_info->total_bytes) ||
- can_overcommit(fs_info, space_info, orig_bytes, flush))) {
+ btrfs_can_overcommit(fs_info, space_info, orig_bytes, flush))) {
btrfs_space_info_update_bytes_may_use(fs_info, space_info,
orig_bytes);
ret = 0;
diff --git a/fs/btrfs/space-info.h b/fs/btrfs/space-info.h
index 8b9a1d8fefcb7..b9cffc62cafac 100644
--- a/fs/btrfs/space-info.h
+++ b/fs/btrfs/space-info.h
@@ -129,6 +129,9 @@ int btrfs_reserve_metadata_bytes(struct btrfs_root *root,
enum btrfs_reserve_flush_enum flush);
void btrfs_try_granting_tickets(struct btrfs_fs_info *fs_info,
struct btrfs_space_info *space_info);
+int btrfs_can_overcommit(struct btrfs_fs_info *fs_info,
+ struct btrfs_space_info *space_info, u64 bytes,
+ enum btrfs_reserve_flush_enum flush);

static inline void btrfs_space_info_free_bytes_may_use(
struct btrfs_fs_info *fs_info,
--
2.25.1



2020-10-16 12:38:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 05/22] ACPI: Always build evged in

From: Arjan van de Ven <[email protected]>

commit ac36d37e943635fc072e9d4f47e40a48fbcdb3f0 upstream.

Although the Generic Event Device is a Hardware-reduced
platfom device in principle, it should not be restricted to
ACPI_REDUCED_HARDWARE_ONLY.

Kernels supporting both fixed and hardware-reduced ACPI platforms
should be able to probe the GED when dynamically detecting that a
platform is hardware-reduced. For that, the driver must be
unconditionally built in.

Signed-off-by: Arjan van de Ven <[email protected]>
Signed-off-by: Samuel Ortiz <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Cc: Vishnu Rangayyan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/acpi/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -48,7 +48,7 @@ acpi-y += acpi_pnp.o
acpi-$(CONFIG_ARM_AMBA) += acpi_amba.o
acpi-y += power.o
acpi-y += event.o
-acpi-$(CONFIG_ACPI_REDUCED_HARDWARE_ONLY) += evged.o
+acpi-y += evged.o
acpi-y += sysfs.o
acpi-y += property.o
acpi-$(CONFIG_X86) += acpi_cmos_rtc.o


2020-10-16 12:40:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 10/22] Bluetooth: Fix update of connection state in `hci_encrypt_cfm`

From: Patrick Steinhardt <[email protected]>

commit 339ddaa626995bc6218972ca241471f3717cc5f4 upstream.

Starting with the upgrade to v5.8-rc3, I've noticed I wasn't able to
connect to my Bluetooth headset properly anymore. While connecting to
the device would eventually succeed, bluetoothd seemed to be confused
about the current connection state where the state was flapping hence
and forth. Bisecting this issue led to commit 3ca44c16b0dc (Bluetooth:
Consolidate encryption handling in hci_encrypt_cfm, 2020-05-19), which
refactored `hci_encrypt_cfm` to also handle updating the connection
state.

The commit in question changed the code to call `hci_connect_cfm` inside
`hci_encrypt_cfm` and to change the connection state. But with the
conversion, we now only update the connection state if a status was set
already. In fact, the reverse should be true: the status should be
updated if no status is yet set. So let's fix the isuse by reversing the
condition.

Fixes: 3ca44c16b0dc ("Bluetooth: Consolidate encryption handling in hci_encrypt_cfm")
Signed-off-by: Patrick Steinhardt <[email protected]>
Acked-by: Luiz Augusto von Dentz <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
include/net/bluetooth/hci_core.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -1314,7 +1314,7 @@ static inline void hci_encrypt_cfm(struc
__u8 encrypt;

if (conn->state == BT_CONFIG) {
- if (status)
+ if (!status)
conn->state = BT_CONNECTED;

hci_connect_cfm(conn, status);


2020-10-16 14:07:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 01/22] perf cs-etm: Move definition of traceid_list global variable from header file

From: Leo Yan <[email protected]>

commit 168200b6d6ea0cb5765943ec5da5b8149701f36a upstream.

The variable 'traceid_list' is defined in the header file cs-etm.h,
if multiple C files include cs-etm.h the compiler might complaint for
multiple definition of 'traceid_list'.

To fix multiple definition error, move the definition of 'traceid_list'
into cs-etm.c.

Fixes: cd8bfd8c973e ("perf tools: Add processing of coresight metadata")
Reported-by: Thomas Backlund <[email protected]>
Signed-off-by: Leo Yan <[email protected]>
Reviewed-by: Mathieu Poirier <[email protected]>
Reviewed-by: Mike Leach <[email protected]>
Tested-by: Mike Leach <[email protected]>
Tested-by: Thomas Backlund <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Suzuki Poulouse <[email protected]>
Cc: Tor Jeremiassen <[email protected]>
Cc: [email protected]
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Cc: Paul Barker <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
tools/perf/util/cs-etm.c | 3 +++
tools/perf/util/cs-etm.h | 3 ---
2 files changed, 3 insertions(+), 3 deletions(-)

--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -94,6 +94,9 @@ struct cs_etm_queue {
struct cs_etm_traceid_queue **traceid_queues;
};

+/* RB tree for quick conversion between traceID and metadata pointers */
+static struct intlist *traceid_list;
+
static int cs_etm__update_queues(struct cs_etm_auxtrace *etm);
static int cs_etm__process_queues(struct cs_etm_auxtrace *etm);
static int cs_etm__process_timeless_queues(struct cs_etm_auxtrace *etm,
--- a/tools/perf/util/cs-etm.h
+++ b/tools/perf/util/cs-etm.h
@@ -114,9 +114,6 @@ enum cs_etm_isa {
CS_ETM_ISA_T32,
};

-/* RB tree for quick conversion between traceID and metadata pointers */
-struct intlist *traceid_list;
-
struct cs_etm_queue;

struct cs_etm_packet {


2020-10-16 20:05:20

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/22] 5.4.72-rc1 review

On Fri, Oct 16, 2020 at 11:07:28AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.72 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 18 Oct 2020 09:04:25 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 157 pass: 157 fail: 0
Qemu test results:
total: 430 pass: 430 fail: 0

Tested-by: Guenter Roeck <[email protected]>

Guenter

2020-10-17 10:13:26

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/22] 5.4.72-rc1 review

On Fri, 16 Oct 2020 at 14:41, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.4.72 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 18 Oct 2020 09:04:25 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.72-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Tested-by: Linux Kernel Functional Testing <[email protected]>

Summary
------------------------------------------------------------------------

kernel: 5.4.72-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.4.y
git commit: a3f8c7f24ee00462a09758774aee840317650b51
git describe: v5.4.71-23-ga3f8c7f24ee0
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.71-23-ga3f8c7f24ee0

No regressions (compared to build v5.4.71)

No fixes (compared to build v5.4.71)


Ran 24730 total tests in the following environments and test suites.

Environments
--------------
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- nxp-ls2088
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86
- x86-kasan

Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-fs-tests
* ltp-ipc-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* perf
* v4l2-compliance
* ltp-commands-tests
* ltp-containers-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-math-tests
* ltp-mm-tests
* network-basic-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* ssuite

--
Linaro LKFT
https://lkft.linaro.org

2020-10-17 16:27:39

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/22] 5.4.72-rc1 review

On 10/16/20 3:07 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.72 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 18 Oct 2020 09:04:25 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.72-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Compiled and booted on my test system. No dmesg regressions.

Tested-by: Shuah Khan <[email protected]>

thanks,
-- Shuah