This is the start of the stable review cycle for the 5.15.15 release.
There are 41 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, 16 Jan 2022 08:15:33 +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.15.15-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.15.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 5.15.15-rc1
Arnd Bergmann <[email protected]>
staging: greybus: fix stack size warning with UBSAN
Nathan Chancellor <[email protected]>
drm/i915: Avoid bitwise vs logical OR warning in snb_wm_latency_quirk()
Nathan Chancellor <[email protected]>
staging: wlan-ng: Avoid bitwise vs logical OR warning in hfa384x_usb_throttlefn()
Ricardo Ribalda <[email protected]>
media: Revert "media: uvcvideo: Set unique vdev name based in type"
Alex Hung <[email protected]>
platform/x86/intel: hid: add quirk to support Surface Go 3
Dominik Brodowski <[email protected]>
random: fix crash on multiple early calls to add_bootloader_randomness()
Eric Biggers <[email protected]>
random: fix data race on crng init time
Eric Biggers <[email protected]>
random: fix data race on crng_node_pool
Brian Silverman <[email protected]>
can: gs_usb: gs_can_start_xmit(): zero-initialize hf->{flags,reserved}
Marc Kleine-Budde <[email protected]>
can: isotp: convert struct tpcon::{idx,len} to unsigned int
Marc Kleine-Budde <[email protected]>
can: gs_usb: fix use of uninitialized variable, detach device on reception of invalid USB data
Borislav Petkov <[email protected]>
x86/mce: Remove noinstr annotation from mce_setup()
Andy Shevchenko <[email protected]>
mfd: intel-lpss: Fix too early PM enablement in the ACPI ->probe()
Daniel Borkmann <[email protected]>
veth: Do not record rx queue hint in veth_xmit
Aditya Garg <[email protected]>
Bluetooth: btbcm: disable read tx power for MacBook Air 8,1 and 8,2
Aditya Garg <[email protected]>
Bluetooth: btbcm: disable read tx power for some Macs with the T2 Security chip
Aditya Garg <[email protected]>
Bluetooth: add quirk disabling LE Read Transmit Power
Adrian Hunter <[email protected]>
mmc: sdhci-pci: Add PCI ID for Intel ADL
Sven Eckelmann <[email protected]>
ath11k: Fix buffer overflow when scanning with extraie
Alan Stern <[email protected]>
USB: Fix "slab-out-of-bounds Write" bug in usb_hcd_poll_rh_status
Alan Stern <[email protected]>
USB: core: Fix bug in resuming hub's handling of wakeup requests
Paul Cercueil <[email protected]>
ARM: dts: exynos: Fix BCM4330 Bluetooth reset polarity in I9100
Johan Hovold <[email protected]>
Bluetooth: bfusb: fix division by zero in send path
Aaron Ma <[email protected]>
Bluetooth: btusb: Add support for Foxconn QCA 0xe0d0
Tedd Ho-Jeong An <[email protected]>
Bluetooth: btintel: Fix broken LED quirk for legacy ROM devices
Aaron Ma <[email protected]>
Bluetooth: btusb: Add support for Foxconn MT7922A
Zijun Hu <[email protected]>
Bluetooth: btusb: Add two more Bluetooth parts for WCN6855
Zijun Hu <[email protected]>
Bluetooth: btusb: Add one more Bluetooth part for WCN6855
Linus Torvalds <[email protected]>
fget: clarify and improve __fget_files() implementation
[email protected] <[email protected]>
Bluetooth: btusb: Add the new support IDs for WCN6855
Larry Finger <[email protected]>
Bluetooth: btusb: Add one more Bluetooth part for the Realtek RTL8852AE
mark-yw.chen <[email protected]>
Bluetooth: btusb: enable Mediatek to support AOSP extension
Mark-YW.Chen <[email protected]>
Bluetooth: btusb: fix memory leak in btusb_mtk_submit_wmt_recv_urb()
Larry Finger <[email protected]>
Bbluetooth: btusb: Add another Bluetooth part for Realtek 8852AE
mark-yw.chen <[email protected]>
Bluetooth: btusb: Add support for IMC Networks Mediatek Chip(MT7921)
Max Chou <[email protected]>
Bluetooth: btusb: Add the new support ID for Realtek RTL8852A
mark-yw.chen <[email protected]>
Bluetooth: btusb: Add protocol for MediaTek bluetooth devices(MT7922)
Daniel Borkmann <[email protected]>
bpf: Fix out of bounds access from invalid *_or_null type verification
Martin Kaiser <[email protected]>
staging: r8188eu: switch the led off during deinit
Frederic Weisbecker <[email protected]>
workqueue: Fix unbind_workers() VS wq_worker_running() race
Alexander Egorenkov <[email protected]>
s390/kexec: handle R_390_PLT32DBL rela in arch_kexec_apply_relocations_add()
-------------
Diffstat:
Makefile | 4 +-
arch/arm/boot/dts/exynos4210-i9100.dts | 2 +-
arch/s390/kernel/machine_kexec_file.c | 4 ++
arch/x86/kernel/cpu/mce/core.c | 26 +++++--
drivers/bluetooth/bfusb.c | 3 +
drivers/bluetooth/btbcm.c | 51 ++++++++++++++
drivers/bluetooth/btintel.c | 20 +++---
drivers/bluetooth/btintel.h | 2 +-
drivers/bluetooth/btusb.c | 61 ++++++++++++++--
drivers/char/random.c | 117 ++++++++++++++++++-------------
drivers/gpu/drm/i915/intel_pm.c | 6 +-
drivers/media/usb/uvc/uvc_driver.c | 7 +-
drivers/mfd/intel-lpss-acpi.c | 7 +-
drivers/mmc/host/sdhci-pci-core.c | 1 +
drivers/mmc/host/sdhci-pci.h | 1 +
drivers/net/can/usb/gs_usb.c | 5 +-
drivers/net/veth.c | 1 -
drivers/net/wireless/ath/ath11k/wmi.c | 6 +-
drivers/platform/x86/intel/hid.c | 7 ++
drivers/staging/greybus/audio_topology.c | 92 ++++++++++++------------
drivers/staging/r8188eu/core/rtw_led.c | 1 +
drivers/staging/wlan-ng/hfa384x_usb.c | 22 +++---
drivers/usb/core/hcd.c | 9 ++-
drivers/usb/core/hub.c | 2 +-
fs/file.c | 72 ++++++++++++++-----
include/net/bluetooth/hci.h | 9 +++
kernel/bpf/verifier.c | 6 +-
kernel/workqueue.c | 9 +++
net/bluetooth/hci_core.c | 3 +-
net/can/isotp.c | 4 +-
30 files changed, 389 insertions(+), 171 deletions(-)
From: Dominik Brodowski <[email protected]>
commit f7e67b8e803185d0aabe7f29d25a35c8be724a78 upstream.
Currently, if CONFIG_RANDOM_TRUST_BOOTLOADER is enabled, multiple calls
to add_bootloader_randomness() are broken and can cause a NULL pointer
dereference, as noted by Ivan T. Ivanov. This is not only a hypothetical
problem, as qemu on arm64 may provide bootloader entropy via EFI and via
devicetree.
On the first call to add_hwgenerator_randomness(), crng_fast_load() is
executed, and if the seed is long enough, crng_init will be set to 1.
On subsequent calls to add_bootloader_randomness() and then to
add_hwgenerator_randomness(), crng_fast_load() will be skipped. Instead,
wait_event_interruptible() and then credit_entropy_bits() will be called.
If the entropy count for that second seed is large enough, that proceeds
to crng_reseed().
However, both wait_event_interruptible() and crng_reseed() depends
(at least in numa_crng_init()) on workqueues. Therefore, test whether
system_wq is already initialized, which is a sufficient indicator that
workqueue_init_early() has progressed far enough.
If we wind up hitting the !system_wq case, we later want to do what
would have been done there when wqs are up, so set a flag, and do that
work later from the rand_initialize() call.
Reported-by: Ivan T. Ivanov <[email protected]>
Fixes: 18b915ac6b0a ("efi/random: Treat EFI_RNG_PROTOCOL output as bootloader randomness")
Cc: [email protected]
Signed-off-by: Dominik Brodowski <[email protected]>
[Jason: added crng_need_done state and related logic.]
Signed-off-by: Jason A. Donenfeld <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/char/random.c | 56 ++++++++++++++++++++++++++++++++------------------
1 file changed, 36 insertions(+), 20 deletions(-)
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -461,6 +461,7 @@ static struct crng_state primary_crng =
* its value (from 0->1->2).
*/
static int crng_init = 0;
+static bool crng_need_final_init = false;
#define crng_ready() (likely(crng_init > 1))
static int crng_init_cnt = 0;
static unsigned long crng_global_init_time = 0;
@@ -828,6 +829,36 @@ static void __init crng_initialize_prima
crng->init_time = jiffies - CRNG_RESEED_INTERVAL - 1;
}
+static void crng_finalize_init(struct crng_state *crng)
+{
+ if (crng != &primary_crng || crng_init >= 2)
+ return;
+ if (!system_wq) {
+ /* We can't call numa_crng_init until we have workqueues,
+ * so mark this for processing later. */
+ crng_need_final_init = true;
+ return;
+ }
+
+ invalidate_batched_entropy();
+ numa_crng_init();
+ crng_init = 2;
+ process_random_ready_list();
+ wake_up_interruptible(&crng_init_wait);
+ kill_fasync(&fasync, SIGIO, POLL_IN);
+ pr_notice("crng init done\n");
+ if (unseeded_warning.missed) {
+ pr_notice("%d get_random_xx warning(s) missed due to ratelimiting\n",
+ unseeded_warning.missed);
+ unseeded_warning.missed = 0;
+ }
+ if (urandom_warning.missed) {
+ pr_notice("%d urandom warning(s) missed due to ratelimiting\n",
+ urandom_warning.missed);
+ urandom_warning.missed = 0;
+ }
+}
+
#ifdef CONFIG_NUMA
static void do_numa_crng_init(struct work_struct *work)
{
@@ -982,25 +1013,7 @@ static void crng_reseed(struct crng_stat
memzero_explicit(&buf, sizeof(buf));
WRITE_ONCE(crng->init_time, jiffies);
spin_unlock_irqrestore(&crng->lock, flags);
- if (crng == &primary_crng && crng_init < 2) {
- invalidate_batched_entropy();
- numa_crng_init();
- crng_init = 2;
- process_random_ready_list();
- wake_up_interruptible(&crng_init_wait);
- kill_fasync(&fasync, SIGIO, POLL_IN);
- pr_notice("crng init done\n");
- if (unseeded_warning.missed) {
- pr_notice("%d get_random_xx warning(s) missed due to ratelimiting\n",
- unseeded_warning.missed);
- unseeded_warning.missed = 0;
- }
- if (urandom_warning.missed) {
- pr_notice("%d urandom warning(s) missed due to ratelimiting\n",
- urandom_warning.missed);
- urandom_warning.missed = 0;
- }
- }
+ crng_finalize_init(crng);
}
static void _extract_crng(struct crng_state *crng,
@@ -1780,6 +1793,8 @@ static void __init init_std_data(struct
int __init rand_initialize(void)
{
init_std_data(&input_pool);
+ if (crng_need_final_init)
+ crng_finalize_init(&primary_crng);
crng_initialize_primary(&primary_crng);
crng_global_init_time = jiffies;
if (ratelimit_disable) {
@@ -2288,7 +2303,8 @@ void add_hwgenerator_randomness(const ch
* We'll be woken up again once below random_write_wakeup_thresh,
* or when the calling thread is about to terminate.
*/
- wait_event_interruptible(random_write_wait, kthread_should_stop() ||
+ wait_event_interruptible(random_write_wait,
+ !system_wq || kthread_should_stop() ||
ENTROPY_BITS(&input_pool) <= random_write_wakeup_bits);
mix_pool_bytes(poolp, buffer, count);
credit_entropy_bits(poolp, entropy);
From: Alex Hung <[email protected]>
commit 01e16cb67cce68afaeb9c7bed72299036dbb0bc1 upstream.
Similar to other systems Surface Go 3 requires a DMI quirk to enable
5 button array for power and volume buttons.
Buglink: https://github.com/linux-surface/linux-surface/issues/595
Cc: [email protected]
Signed-off-by: Alex Hung <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/platform/x86/intel/hid.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/platform/x86/intel/hid.c
+++ b/drivers/platform/x86/intel/hid.c
@@ -106,6 +106,13 @@ static const struct dmi_system_id button
DMI_MATCH(DMI_PRODUCT_NAME, "Surface Go 3"),
},
},
+ {
+ .ident = "Microsoft Surface Go 3",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Microsoft Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Surface Go 3"),
+ },
+ },
{ }
};
From: Nathan Chancellor <[email protected]>
commit 2e70570656adfe1c5d9a29940faa348d5f132199 upstream.
A new warning in clang points out a place in this file where a bitwise
OR is being used with boolean types:
drivers/gpu/drm/i915/intel_pm.c:3066:12: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
changed = ilk_increase_wm_latency(dev_priv, dev_priv->wm.pri_latency, 12) |
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This construct is intentional, as it allows every one of the calls to
ilk_increase_wm_latency() to occur (instead of short circuiting with
logical OR) while still caring about the result of each call.
To make this clearer to the compiler, use the '|=' operator to assign
the result of each ilk_increase_wm_latency() call to changed, which
keeps the meaning of the code the same but makes it obvious that every
one of these calls is expected to happen.
Link: https://github.com/ClangBuiltLinux/linux/issues/1473
Reported-by: Nick Desaulniers <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Suggested-by: Dávid Bolvanský <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/i915/intel_pm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3063,9 +3063,9 @@ static void snb_wm_latency_quirk(struct
* The BIOS provided WM memory latency values are often
* inadequate for high resolution displays. Adjust them.
*/
- changed = ilk_increase_wm_latency(dev_priv, dev_priv->wm.pri_latency, 12) |
- ilk_increase_wm_latency(dev_priv, dev_priv->wm.spr_latency, 12) |
- ilk_increase_wm_latency(dev_priv, dev_priv->wm.cur_latency, 12);
+ changed = ilk_increase_wm_latency(dev_priv, dev_priv->wm.pri_latency, 12);
+ changed |= ilk_increase_wm_latency(dev_priv, dev_priv->wm.spr_latency, 12);
+ changed |= ilk_increase_wm_latency(dev_priv, dev_priv->wm.cur_latency, 12);
if (!changed)
return;
From: Nathan Chancellor <[email protected]>
commit 502408a61f4b7eb4713f44bd77f4a48e6cb1b59a upstream.
A new warning in clang points out a place in this file where a bitwise
OR is being used with boolean expressions:
In file included from drivers/staging/wlan-ng/prism2usb.c:2:
drivers/staging/wlan-ng/hfa384x_usb.c:3787:7: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
((test_and_clear_bit(THROTTLE_RX, &hw->usb_flags) &&
~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/staging/wlan-ng/hfa384x_usb.c:3787:7: note: cast one or both operands to int to silence this warning
1 warning generated.
The comment explains that short circuiting here is undesirable, as the
calls to test_and_{clear,set}_bit() need to happen for both sides of the
expression.
Clang's suggestion would work to silence the warning but the readability
of the expression would suffer even more. To clean up the warning and
make the block more readable, use a variable for each side of the
bitwise expression.
Link: https://github.com/ClangBuiltLinux/linux/issues/1478
Signed-off-by: Nathan Chancellor <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/wlan-ng/hfa384x_usb.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -3778,18 +3778,18 @@ static void hfa384x_usb_throttlefn(struc
spin_lock_irqsave(&hw->ctlxq.lock, flags);
- /*
- * We need to check BOTH the RX and the TX throttle controls,
- * so we use the bitwise OR instead of the logical OR.
- */
pr_debug("flags=0x%lx\n", hw->usb_flags);
- if (!hw->wlandev->hwremoved &&
- ((test_and_clear_bit(THROTTLE_RX, &hw->usb_flags) &&
- !test_and_set_bit(WORK_RX_RESUME, &hw->usb_flags)) |
- (test_and_clear_bit(THROTTLE_TX, &hw->usb_flags) &&
- !test_and_set_bit(WORK_TX_RESUME, &hw->usb_flags))
- )) {
- schedule_work(&hw->usb_work);
+ if (!hw->wlandev->hwremoved) {
+ bool rx_throttle = test_and_clear_bit(THROTTLE_RX, &hw->usb_flags) &&
+ !test_and_set_bit(WORK_RX_RESUME, &hw->usb_flags);
+ bool tx_throttle = test_and_clear_bit(THROTTLE_TX, &hw->usb_flags) &&
+ !test_and_set_bit(WORK_TX_RESUME, &hw->usb_flags);
+ /*
+ * We need to check BOTH the RX and the TX throttle controls,
+ * so we use the bitwise OR instead of the logical OR.
+ */
+ if (rx_throttle | tx_throttle)
+ schedule_work(&hw->usb_work);
}
spin_unlock_irqrestore(&hw->ctlxq.lock, flags);
From: Arnd Bergmann <[email protected]>
commit 144779edf598e0896302c35a0926ef0b68f17c4b upstream.
clang warns about excessive stack usage in this driver when
UBSAN is enabled:
drivers/staging/greybus/audio_topology.c:977:12: error: stack frame size of 1836 bytes in function 'gbaudio_tplg_create_widget' [-Werror,-Wframe-larger-than=]
Rework this code to no longer use compound literals for
initializing the structure in each case, but instead keep
the common bits in a preallocated constant array and copy
them as needed.
Link: https://github.com/ClangBuiltLinux/linux/issues/1535
Link: https://lore.kernel.org/r/[email protected]/
Reviewed-by: Nick Desaulniers <[email protected]>
Reviewed-by: Alex Elder <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
[nathan: Address review comments from v1]
Signed-off-by: Nathan Chancellor <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/greybus/audio_topology.c | 92 +++++++++++++++----------------
1 file changed, 45 insertions(+), 47 deletions(-)
--- a/drivers/staging/greybus/audio_topology.c
+++ b/drivers/staging/greybus/audio_topology.c
@@ -974,6 +974,44 @@ static int gbaudio_widget_event(struct s
return ret;
}
+static const struct snd_soc_dapm_widget gbaudio_widgets[] = {
+ [snd_soc_dapm_spk] = SND_SOC_DAPM_SPK(NULL, gbcodec_event_spk),
+ [snd_soc_dapm_hp] = SND_SOC_DAPM_HP(NULL, gbcodec_event_hp),
+ [snd_soc_dapm_mic] = SND_SOC_DAPM_MIC(NULL, gbcodec_event_int_mic),
+ [snd_soc_dapm_output] = SND_SOC_DAPM_OUTPUT(NULL),
+ [snd_soc_dapm_input] = SND_SOC_DAPM_INPUT(NULL),
+ [snd_soc_dapm_switch] = SND_SOC_DAPM_SWITCH_E(NULL, SND_SOC_NOPM,
+ 0, 0, NULL,
+ gbaudio_widget_event,
+ SND_SOC_DAPM_PRE_PMU |
+ SND_SOC_DAPM_POST_PMD),
+ [snd_soc_dapm_pga] = SND_SOC_DAPM_PGA_E(NULL, SND_SOC_NOPM,
+ 0, 0, NULL, 0,
+ gbaudio_widget_event,
+ SND_SOC_DAPM_PRE_PMU |
+ SND_SOC_DAPM_POST_PMD),
+ [snd_soc_dapm_mixer] = SND_SOC_DAPM_MIXER_E(NULL, SND_SOC_NOPM,
+ 0, 0, NULL, 0,
+ gbaudio_widget_event,
+ SND_SOC_DAPM_PRE_PMU |
+ SND_SOC_DAPM_POST_PMD),
+ [snd_soc_dapm_mux] = SND_SOC_DAPM_MUX_E(NULL, SND_SOC_NOPM,
+ 0, 0, NULL,
+ gbaudio_widget_event,
+ SND_SOC_DAPM_PRE_PMU |
+ SND_SOC_DAPM_POST_PMD),
+ [snd_soc_dapm_aif_in] = SND_SOC_DAPM_AIF_IN_E(NULL, NULL, 0,
+ SND_SOC_NOPM, 0, 0,
+ gbaudio_widget_event,
+ SND_SOC_DAPM_PRE_PMU |
+ SND_SOC_DAPM_POST_PMD),
+ [snd_soc_dapm_aif_out] = SND_SOC_DAPM_AIF_OUT_E(NULL, NULL, 0,
+ SND_SOC_NOPM, 0, 0,
+ gbaudio_widget_event,
+ SND_SOC_DAPM_PRE_PMU |
+ SND_SOC_DAPM_POST_PMD),
+};
+
static int gbaudio_tplg_create_widget(struct gbaudio_module_info *module,
struct snd_soc_dapm_widget *dw,
struct gb_audio_widget *w, int *w_size)
@@ -1052,77 +1090,37 @@ static int gbaudio_tplg_create_widget(st
switch (w->type) {
case snd_soc_dapm_spk:
- *dw = (struct snd_soc_dapm_widget)
- SND_SOC_DAPM_SPK(w->name, gbcodec_event_spk);
+ *dw = gbaudio_widgets[w->type];
module->op_devices |= GBAUDIO_DEVICE_OUT_SPEAKER;
break;
case snd_soc_dapm_hp:
- *dw = (struct snd_soc_dapm_widget)
- SND_SOC_DAPM_HP(w->name, gbcodec_event_hp);
+ *dw = gbaudio_widgets[w->type];
module->op_devices |= (GBAUDIO_DEVICE_OUT_WIRED_HEADSET
| GBAUDIO_DEVICE_OUT_WIRED_HEADPHONE);
module->ip_devices |= GBAUDIO_DEVICE_IN_WIRED_HEADSET;
break;
case snd_soc_dapm_mic:
- *dw = (struct snd_soc_dapm_widget)
- SND_SOC_DAPM_MIC(w->name, gbcodec_event_int_mic);
+ *dw = gbaudio_widgets[w->type];
module->ip_devices |= GBAUDIO_DEVICE_IN_BUILTIN_MIC;
break;
case snd_soc_dapm_output:
- *dw = (struct snd_soc_dapm_widget)SND_SOC_DAPM_OUTPUT(w->name);
- break;
case snd_soc_dapm_input:
- *dw = (struct snd_soc_dapm_widget)SND_SOC_DAPM_INPUT(w->name);
- break;
case snd_soc_dapm_switch:
- *dw = (struct snd_soc_dapm_widget)
- SND_SOC_DAPM_SWITCH_E(w->name, SND_SOC_NOPM, 0, 0,
- widget_kctls,
- gbaudio_widget_event,
- SND_SOC_DAPM_PRE_PMU |
- SND_SOC_DAPM_POST_PMD);
- break;
case snd_soc_dapm_pga:
- *dw = (struct snd_soc_dapm_widget)
- SND_SOC_DAPM_PGA_E(w->name, SND_SOC_NOPM, 0, 0, NULL, 0,
- gbaudio_widget_event,
- SND_SOC_DAPM_PRE_PMU |
- SND_SOC_DAPM_POST_PMD);
- break;
case snd_soc_dapm_mixer:
- *dw = (struct snd_soc_dapm_widget)
- SND_SOC_DAPM_MIXER_E(w->name, SND_SOC_NOPM, 0, 0, NULL,
- 0, gbaudio_widget_event,
- SND_SOC_DAPM_PRE_PMU |
- SND_SOC_DAPM_POST_PMD);
- break;
case snd_soc_dapm_mux:
- *dw = (struct snd_soc_dapm_widget)
- SND_SOC_DAPM_MUX_E(w->name, SND_SOC_NOPM, 0, 0,
- widget_kctls, gbaudio_widget_event,
- SND_SOC_DAPM_PRE_PMU |
- SND_SOC_DAPM_POST_PMD);
+ *dw = gbaudio_widgets[w->type];
break;
case snd_soc_dapm_aif_in:
- *dw = (struct snd_soc_dapm_widget)
- SND_SOC_DAPM_AIF_IN_E(w->name, w->sname, 0,
- SND_SOC_NOPM,
- 0, 0, gbaudio_widget_event,
- SND_SOC_DAPM_PRE_PMU |
- SND_SOC_DAPM_POST_PMD);
- break;
case snd_soc_dapm_aif_out:
- *dw = (struct snd_soc_dapm_widget)
- SND_SOC_DAPM_AIF_OUT_E(w->name, w->sname, 0,
- SND_SOC_NOPM,
- 0, 0, gbaudio_widget_event,
- SND_SOC_DAPM_PRE_PMU |
- SND_SOC_DAPM_POST_PMD);
+ *dw = gbaudio_widgets[w->type];
+ dw->sname = w->sname;
break;
default:
ret = -EINVAL;
goto error;
}
+ dw->name = w->name;
dev_dbg(module->dev, "%s: widget of type %d created\n", dw->name,
dw->id);
From: Ricardo Ribalda <[email protected]>
commit f66dcb32af19faf49cc4a9222c3152b10c6ec84a upstream.
A lot of userspace depends on a descriptive name for vdev. Without this
patch, users have a hard time figuring out which camera shall they use
for their video conferencing.
This reverts commit e3f60e7e1a2b451f538f9926763432249bcf39c4.
Link: https://lore.kernel.org/linux-media/[email protected]
Cc: <[email protected]>
Fixes: e3f60e7e1a2b ("media: uvcvideo: Set unique vdev name based in type")
Reported-by: Nicolas Dufresne <[email protected]>
Signed-off-by: Ricardo Ribalda <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Reviewed-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/usb/uvc/uvc_driver.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -2194,7 +2194,6 @@ int uvc_register_video_device(struct uvc
const struct v4l2_file_operations *fops,
const struct v4l2_ioctl_ops *ioctl_ops)
{
- const char *name;
int ret;
/* Initialize the video buffers queue. */
@@ -2223,20 +2222,16 @@ int uvc_register_video_device(struct uvc
case V4L2_BUF_TYPE_VIDEO_CAPTURE:
default:
vdev->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
- name = "Video Capture";
break;
case V4L2_BUF_TYPE_VIDEO_OUTPUT:
vdev->device_caps = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING;
- name = "Video Output";
break;
case V4L2_BUF_TYPE_META_CAPTURE:
vdev->device_caps = V4L2_CAP_META_CAPTURE | V4L2_CAP_STREAMING;
- name = "Metadata";
break;
}
- snprintf(vdev->name, sizeof(vdev->name), "%s %u", name,
- stream->header.bTerminalLink);
+ strscpy(vdev->name, dev->name, sizeof(vdev->name));
/*
* Set the driver data before calling video_register_device, otherwise
From: Aditya Garg <[email protected]>
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 <[email protected]>
Reported-by: Orlando Chamberlain <[email protected]>
Tested-by: Orlando Chamberlain <[email protected]>
Link:
https://lore.kernel.org/r/[email protected]
Fixes: 7c395ea521e6 ("Bluetooth: Query LE tx power on startup")
Cc: [email protected]
Signed-off-by: Marcel Holtmann <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
}
From: Aditya Garg <[email protected]>
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 <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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"),
},
},
From: Daniel Borkmann <[email protected]>
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 <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Cc: Maciej Fijalkowski <[email protected]>
Cc: Toshiaki Makita <[email protected]>
Cc: Eric Dumazet <[email protected]>
Cc: Paolo Abeni <[email protected]>
Cc: John Fastabend <[email protected]>
Cc: Willem de Bruijn <[email protected]>
Acked-by: John Fastabend <[email protected]>
Reviewed-by: Eric Dumazet <[email protected]>
Acked-by: Toshiaki Makita <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
From: Marc Kleine-Budde <[email protected]>
commit 4a8737ff068724f509d583fef404d349adba80d6 upstream.
The received data contains the channel the received data is associated
with. If the channel number is bigger than the actual number of
channels assume broken or malicious USB device and shut it down.
This fixes the error found by clang:
| drivers/net/can/usb/gs_usb.c:386:6: error: variable 'dev' is used
| uninitialized whenever 'if' condition is true
| if (hf->channel >= GS_MAX_INTF)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
| drivers/net/can/usb/gs_usb.c:474:10: note: uninitialized use occurs here
| hf, dev->gs_hf_size, gs_usb_receive_bulk_callback,
| ^~~
Link: https://lore.kernel.org/all/[email protected]
Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices")
Cc: [email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/can/usb/gs_usb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/can/usb/gs_usb.c
+++ b/drivers/net/can/usb/gs_usb.c
@@ -321,7 +321,7 @@ static void gs_usb_receive_bulk_callback
/* device reports out of range channel id */
if (hf->channel >= GS_MAX_INTF)
- goto resubmit_urb;
+ goto device_detach;
dev = usbcan->canch[hf->channel];
@@ -406,6 +406,7 @@ static void gs_usb_receive_bulk_callback
/* USB failure take down all interfaces */
if (rc == -ENODEV) {
+ device_detach:
for (rc = 0; rc < GS_MAX_INTF; rc++) {
if (usbcan->canch[rc])
netif_device_detach(usbcan->canch[rc]->netdev);
From: Andy Shevchenko <[email protected]>
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 <[email protected]>
Reported-by: Aditya Garg <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Tested-by: Aditya Garg <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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)
From: Borislav Petkov <[email protected]>
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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
@@ -130,7 +130,7 @@ static void (*quirk_no_way_out)(int bank
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();
@@ -479,9 +479,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) {
@@ -1327,11 +1333,11 @@ static void queue_task_work(struct mce *
}
/*
- * 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
@@ -1343,6 +1349,14 @@ static void queue_task_work(struct mce *
* 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)
{
From: Brian Silverman <[email protected]>
commit 89d58aebe14a365c25ba6645414afdbf4e41cea4 upstream.
No information is deliberately sent in hf->flags in host -> device
communications, but the open-source candleLight firmware echoes it
back, which can result in the GS_CAN_FLAG_OVERFLOW flag being set and
generating spurious ERRORFRAMEs.
While there also initialize the reserved member with 0.
Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices")
Link: https://lore.kernel.org/all/[email protected]
Link: https://github.com/candle-usb/candleLight_fw/issues/87
Cc: [email protected]
Signed-off-by: Brian Silverman <[email protected]>
[mkl: initialize the reserved member, too]
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/can/usb/gs_usb.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/can/usb/gs_usb.c
+++ b/drivers/net/can/usb/gs_usb.c
@@ -508,6 +508,8 @@ static netdev_tx_t gs_can_start_xmit(str
hf->echo_id = idx;
hf->channel = dev->channel;
+ hf->flags = 0;
+ hf->reserved = 0;
cf = (struct can_frame *)skb->data;
From: Marc Kleine-Budde <[email protected]>
commit 5f33a09e769a9da0482f20a6770a342842443776 upstream.
In isotp_rcv_ff() 32 bit of data received over the network is assigned
to struct tpcon::len. Later in that function the length is checked for
the maximal supported length against MAX_MSG_LENGTH.
As struct tpcon::len is an "int" this check does not work, if the
provided length overflows the "int".
Later on struct tpcon::idx is compared against struct tpcon::len.
To fix this problem this patch converts both struct tpcon::{idx,len}
to unsigned int.
Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol")
Link: https://lore.kernel.org/all/[email protected]
Cc: [email protected]
Acked-by: Oliver Hartkopp <[email protected]>
Reported-by: [email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/can/isotp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/can/isotp.c
+++ b/net/can/isotp.c
@@ -119,8 +119,8 @@ enum {
};
struct tpcon {
- int idx;
- int len;
+ unsigned int idx;
+ unsigned int len;
u32 state;
u8 bs;
u8 sn;
From: Adrian Hunter <[email protected]>
commit e53e97f805cb1abeea000a61549d42f92cb10804 upstream.
Add PCI ID for Intel ADL eMMC host controller.
Signed-off-by: Adrian Hunter <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/mmc/host/sdhci-pci-core.c | 1 +
drivers/mmc/host/sdhci-pci.h | 1 +
2 files changed, 2 insertions(+)
--- a/drivers/mmc/host/sdhci-pci-core.c
+++ b/drivers/mmc/host/sdhci-pci-core.c
@@ -1951,6 +1951,7 @@ static const struct pci_device_id pci_id
SDHCI_PCI_DEVICE(INTEL, JSL_SD, intel_byt_sd),
SDHCI_PCI_DEVICE(INTEL, LKF_EMMC, intel_glk_emmc),
SDHCI_PCI_DEVICE(INTEL, LKF_SD, intel_byt_sd),
+ SDHCI_PCI_DEVICE(INTEL, ADL_EMMC, intel_glk_emmc),
SDHCI_PCI_DEVICE(O2, 8120, o2),
SDHCI_PCI_DEVICE(O2, 8220, o2),
SDHCI_PCI_DEVICE(O2, 8221, o2),
--- a/drivers/mmc/host/sdhci-pci.h
+++ b/drivers/mmc/host/sdhci-pci.h
@@ -59,6 +59,7 @@
#define PCI_DEVICE_ID_INTEL_JSL_SD 0x4df8
#define PCI_DEVICE_ID_INTEL_LKF_EMMC 0x98c4
#define PCI_DEVICE_ID_INTEL_LKF_SD 0x98f8
+#define PCI_DEVICE_ID_INTEL_ADL_EMMC 0x54c4
#define PCI_DEVICE_ID_SYSKONNECT_8000 0x8000
#define PCI_DEVICE_ID_VIA_95D0 0x95d0
On Fri, 14 Jan 2022 at 13:50, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.15.15 release.
> There are 41 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, 16 Jan 2022 08:15:33 +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.15.15-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.15.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]>
## Build
* kernel: 5.15.15-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.15.y
* git commit: f9dc3f25c12ab4f1f1e691dcb48202fbf8d6226d
* git describe: v5.15.14-42-gf9dc3f25c12a
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15.14-42-gf9dc3f25c12a
## Test Regressions (compared to v5.15.14-39-gc9df4d832e20)
No test regressions found.
## Metric Regressions (compared to v5.15.14-39-gc9df4d832e20)
No metric regressions found.
## Test Fixes (compared to v5.15.14-39-gc9df4d832e20)
No test fixes found.
## Metric Fixes (compared to v5.15.14-39-gc9df4d832e20)
No metric fixes found.
## Test result summary
total: 90478, pass: 77086, fail: 780, skip: 11832, xfail: 780
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 259 total, 255 passed, 4 failed
* arm64: 37 total, 37 passed, 0 failed
* i386: 35 total, 35 passed, 0 failed
* mips: 34 total, 30 passed, 4 failed
* parisc: 12 total, 12 passed, 0 failed
* powerpc: 52 total, 48 passed, 4 failed
* riscv: 24 total, 20 passed, 4 failed
* s390: 18 total, 18 passed, 0 failed
* sh: 24 total, 24 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x86_64: 37 total, 37 passed, 0 failed
## Test suites summary
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* kselftest-arm64/arm64.btitest.bti_c_func
* kselftest-arm64/arm64.btitest.bti_j_func
* kselftest-arm64/arm64.btitest.bti_jc_func
* kselftest-arm64/arm64.btitest.bti_none_func
* kselftest-arm64/arm64.btitest.nohint_func
* kselftest-arm64/arm64.btitest.paciasp_func
* kselftest-arm64/arm64.nobtitest.bti_c_func
* kselftest-arm64/arm64.nobtitest.bti_j_func
* kselftest-arm64/arm64.nobtitest.bti_jc_func
* kselftest-arm64/arm64.nobtitest.bti_none_func
* kselftest-arm64/arm64.nobtitest.nohint_func
* kselftest-arm64/arm64.nobtitest.paciasp_func
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* linux-log-parser
* lt[
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* rcutorture
* ssuite
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
On 1/14/22 12:16 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.15 release.
> There are 41 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, 16 Jan 2022 08:15:33 +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.15.15-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.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Warnings:
fs/jffs2/xattr.c: In function 'jffs2_build_xattr_subsystem':
fs/jffs2/xattr.c:887:1: warning: the frame size of 1104 bytes is larger
than 1024 bytes [-Wframe-larger-than=]
887 | }
| ^
lib/crypto/curve25519-hacl64.c: In function 'ladder_cmult.constprop':
lib/crypto/curve25519-hacl64.c:601:1: warning: the frame size of 1040
bytes is larger than 1024 bytes [-Wframe-larger-than=]
601 | }
| ^
drivers/net/wireguard/allowedips.c: In function 'root_remove_peer_lists':
drivers/net/wireguard/allowedips.c:77:1: warning: the frame size of 1040
bytes is larger than 1024 bytes [-Wframe-larger-than=]
77 | }
| ^
drivers/net/wireguard/allowedips.c: In function 'root_free_rcu':
drivers/net/wireguard/allowedips.c:64:1: warning: the frame size of 1040
bytes is larger than 1024 bytes [-Wframe-larger-than=]
64 | }
| ^
drivers/vhost/scsi.c: In function 'vhost_scsi_flush':
drivers/vhost/scsi.c:1444:1: warning: the frame size of 1040 bytes is
larger than 1024 bytes [-Wframe-larger-than=]
1444 | }
| ^
Tested-by: Ron Economos <[email protected]>
On 1/14/22 12:16 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.15 release.
> There are 41 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, 16 Jan 2022 08:15:33 +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.15.15-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.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels:
Tested-by: Florian Fainelli <[email protected]>
--
Florian
On Fri, 14 Jan 2022 09:16:00 +0100, Greg Kroah-Hartman <[email protected]> wrote:
> This is the start of the stable review cycle for the 5.15.15 release.
> There are 41 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, 16 Jan 2022 08:15:33 +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.15.15-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.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
5.15.15-rc1 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)
Tested-by: Fox Chen <[email protected]>
On 1/14/22 1:16 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.15 release.
> There are 41 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, 16 Jan 2022 08:15:33 +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.15.15-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.15.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
On Fri, Jan 14, 2022 at 11:59:57AM -0800, Ron Economos wrote:
> On 1/14/22 12:16 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.15.15 release.
> > There are 41 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, 16 Jan 2022 08:15:33 +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.15.15-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.15.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
>
> Warnings:
>
> fs/jffs2/xattr.c: In function 'jffs2_build_xattr_subsystem':
> fs/jffs2/xattr.c:887:1: warning: the frame size of 1104 bytes is larger than
> 1024 bytes [-Wframe-larger-than=]
> ? 887 | }
> ????? | ^
> lib/crypto/curve25519-hacl64.c: In function 'ladder_cmult.constprop':
> lib/crypto/curve25519-hacl64.c:601:1: warning: the frame size of 1040 bytes
> is larger than 1024 bytes [-Wframe-larger-than=]
> ? 601 | }
> ????? | ^
> drivers/net/wireguard/allowedips.c: In function 'root_remove_peer_lists':
> drivers/net/wireguard/allowedips.c:77:1: warning: the frame size of 1040
> bytes is larger than 1024 bytes [-Wframe-larger-than=]
> ?? 77 | }
> ????? | ^
> drivers/net/wireguard/allowedips.c: In function 'root_free_rcu':
> drivers/net/wireguard/allowedips.c:64:1: warning: the frame size of 1040
> bytes is larger than 1024 bytes [-Wframe-larger-than=]
> ?? 64 | }
> ????? | ^
> drivers/vhost/scsi.c: In function 'vhost_scsi_flush':
> drivers/vhost/scsi.c:1444:1: warning: the frame size of 1040 bytes is larger
> than 1024 bytes [-Wframe-larger-than=]
> ?1444 | }
> ????? | ^
Are these new warnings with this release, or old ones?
thanks,
greg k-h
Hi Greg,
On Fri, Jan 14, 2022 at 09:16:00AM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.15 release.
> There are 41 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, 16 Jan 2022 08:15:33 +0000.
> Anything received after that time might be too late.
Build test:
mips (gcc version 11.2.1 20220106): 61 configs -> no new failure
arm (gcc version 11.2.1 20220106): 99 configs -> no new failure
arm64 (gcc version 11.2.1 20220106): 3 configs -> no failure
x86_64 (gcc version 11.2.1 20220106): 4 configs -> no failure
Boot test:
x86_64: Booted on my test laptop. No regression.
x86_64: Booted on qemu. No regression. [1]
mips: Booted on ci20 board. No regression. [2]
[1]. https://openqa.qa.codethink.co.uk/tests/627
[2]. https://openqa.qa.codethink.co.uk/tests/630
Tested-by: Sudip Mukherjee <[email protected]>
--
Regards
Sudip
On 1/15/22 12:14 AM, Greg Kroah-Hartman wrote:
> On Fri, Jan 14, 2022 at 11:59:57AM -0800, Ron Economos wrote:
>> On 1/14/22 12:16 AM, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 5.15.15 release.
>>> There are 41 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, 16 Jan 2022 08:15:33 +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.15.15-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.15.y
>>> and the diffstat can be found below.
>>>
>>> thanks,
>>>
>>> greg k-h
>> Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
>>
>> Warnings:
>>
>> fs/jffs2/xattr.c: In function 'jffs2_build_xattr_subsystem':
>> fs/jffs2/xattr.c:887:1: warning: the frame size of 1104 bytes is larger than
>> 1024 bytes [-Wframe-larger-than=]
>> 887 | }
>> | ^
>> lib/crypto/curve25519-hacl64.c: In function 'ladder_cmult.constprop':
>> lib/crypto/curve25519-hacl64.c:601:1: warning: the frame size of 1040 bytes
>> is larger than 1024 bytes [-Wframe-larger-than=]
>> 601 | }
>> | ^
>> drivers/net/wireguard/allowedips.c: In function 'root_remove_peer_lists':
>> drivers/net/wireguard/allowedips.c:77:1: warning: the frame size of 1040
>> bytes is larger than 1024 bytes [-Wframe-larger-than=]
>> 77 | }
>> | ^
>> drivers/net/wireguard/allowedips.c: In function 'root_free_rcu':
>> drivers/net/wireguard/allowedips.c:64:1: warning: the frame size of 1040
>> bytes is larger than 1024 bytes [-Wframe-larger-than=]
>> 64 | }
>> | ^
>> drivers/vhost/scsi.c: In function 'vhost_scsi_flush':
>> drivers/vhost/scsi.c:1444:1: warning: the frame size of 1040 bytes is larger
>> than 1024 bytes [-Wframe-larger-than=]
>> 1444 | }
>> | ^
> Are these new warnings with this release, or old ones?
>
> thanks,
>
> greg k-h
They are old ones.
Ron
On Sat, Jan 15, 2022 at 03:52:34AM -0800, Ron Economos wrote:
> On 1/15/22 12:14 AM, Greg Kroah-Hartman wrote:
> > On Fri, Jan 14, 2022 at 11:59:57AM -0800, Ron Economos wrote:
> > > On 1/14/22 12:16 AM, Greg Kroah-Hartman wrote:
> > > > This is the start of the stable review cycle for the 5.15.15 release.
> > > > There are 41 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, 16 Jan 2022 08:15:33 +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.15.15-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.15.y
> > > > and the diffstat can be found below.
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > > Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
> > >
> > > Warnings:
> > >
> > > fs/jffs2/xattr.c: In function 'jffs2_build_xattr_subsystem':
> > > fs/jffs2/xattr.c:887:1: warning: the frame size of 1104 bytes is larger than
> > > 1024 bytes [-Wframe-larger-than=]
> > > ? 887 | }
> > > ????? | ^
> > > lib/crypto/curve25519-hacl64.c: In function 'ladder_cmult.constprop':
> > > lib/crypto/curve25519-hacl64.c:601:1: warning: the frame size of 1040 bytes
> > > is larger than 1024 bytes [-Wframe-larger-than=]
> > > ? 601 | }
> > > ????? | ^
> > > drivers/net/wireguard/allowedips.c: In function 'root_remove_peer_lists':
> > > drivers/net/wireguard/allowedips.c:77:1: warning: the frame size of 1040
> > > bytes is larger than 1024 bytes [-Wframe-larger-than=]
> > > ?? 77 | }
> > > ????? | ^
> > > drivers/net/wireguard/allowedips.c: In function 'root_free_rcu':
> > > drivers/net/wireguard/allowedips.c:64:1: warning: the frame size of 1040
> > > bytes is larger than 1024 bytes [-Wframe-larger-than=]
> > > ?? 64 | }
> > > ????? | ^
> > > drivers/vhost/scsi.c: In function 'vhost_scsi_flush':
> > > drivers/vhost/scsi.c:1444:1: warning: the frame size of 1040 bytes is larger
> > > than 1024 bytes [-Wframe-larger-than=]
> > > ?1444 | }
> > > ????? | ^
> > Are these new warnings with this release, or old ones?
> >
> > thanks,
> >
> > greg k-h
>
> They are old ones.
Ok, that's good. Are they fixed in 5.16? Anyone planning on fixing
them given that -Werror is now allowed to be set?
thanks,
greg k-h
On 1/15/22 4:15 AM, Greg Kroah-Hartman wrote:
> On Sat, Jan 15, 2022 at 03:52:34AM -0800, Ron Economos wrote:
>> On 1/15/22 12:14 AM, Greg Kroah-Hartman wrote:
>>> On Fri, Jan 14, 2022 at 11:59:57AM -0800, Ron Economos wrote:
>>>> On 1/14/22 12:16 AM, Greg Kroah-Hartman wrote:
>>>>> This is the start of the stable review cycle for the 5.15.15 release.
>>>>> There are 41 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, 16 Jan 2022 08:15:33 +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.15.15-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.15.y
>>>>> and the diffstat can be found below.
>>>>>
>>>>> thanks,
>>>>>
>>>>> greg k-h
>>>> Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
>>>>
>>>> Warnings:
>>>>
>>>> fs/jffs2/xattr.c: In function 'jffs2_build_xattr_subsystem':
>>>> fs/jffs2/xattr.c:887:1: warning: the frame size of 1104 bytes is larger than
>>>> 1024 bytes [-Wframe-larger-than=]
>>>> 887 | }
>>>> | ^
>>>> lib/crypto/curve25519-hacl64.c: In function 'ladder_cmult.constprop':
>>>> lib/crypto/curve25519-hacl64.c:601:1: warning: the frame size of 1040 bytes
>>>> is larger than 1024 bytes [-Wframe-larger-than=]
>>>> 601 | }
>>>> | ^
>>>> drivers/net/wireguard/allowedips.c: In function 'root_remove_peer_lists':
>>>> drivers/net/wireguard/allowedips.c:77:1: warning: the frame size of 1040
>>>> bytes is larger than 1024 bytes [-Wframe-larger-than=]
>>>> 77 | }
>>>> | ^
>>>> drivers/net/wireguard/allowedips.c: In function 'root_free_rcu':
>>>> drivers/net/wireguard/allowedips.c:64:1: warning: the frame size of 1040
>>>> bytes is larger than 1024 bytes [-Wframe-larger-than=]
>>>> 64 | }
>>>> | ^
>>>> drivers/vhost/scsi.c: In function 'vhost_scsi_flush':
>>>> drivers/vhost/scsi.c:1444:1: warning: the frame size of 1040 bytes is larger
>>>> than 1024 bytes [-Wframe-larger-than=]
>>>> 1444 | }
>>>> | ^
>>> Are these new warnings with this release, or old ones?
>>>
>>> thanks,
>>>
>>> greg k-h
>> They are old ones.
> Ok, that's good. Are they fixed in 5.16? Anyone planning on fixing
> them given that -Werror is now allowed to be set?
>
> thanks,
>
> greg k-h
They are also in 5.16. I'm using the Ubuntu 21.10 config (which includes
the kitchen sink), so they're probably not showing up for others.
Ron
On Fri, Jan 14, 2022 at 09:16:00AM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.15 release.
> There are 41 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, 16 Jan 2022 08:15:33 +0000.
> Anything received after that time might be too late.
Builds and runs on ThinkPad X220 (nitro mod).
Tested-by: Andrei Rabusov
On Fri, Jan 14, 2022 at 09:16:00AM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.15 release.
> There are 41 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, 16 Jan 2022 08:15:33 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 154 pass: 154 fail: 0
Qemu test results:
total: 480 pass: 480 fail: 0
Tested-by: Guenter Roeck <[email protected]>
Guenter
On Fri, 2022-01-14 at 09:16 +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.15 release.
> There are 41 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, 16 Jan 2022 08:15:33 +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.15.15-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.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted 5.15.15-rc1+ on VivoBook 15_ASUS Laptop X507UAR
.
No Regression from dmesg. except old warning related from dmesg
Tested-by: Jeffrin Jose T <[email protected]>
--
software engineer
rajagiri school of engineering and technology - autonomous