--- /dev/null
+From e54f30befa7990b897189b44a56c1138c6bfdbb5 Mon Sep 17 00:00:00 2001
+From: Hui Wang <hui.wang@canonical.com>
+Date: Sat, 20 Mar 2021 17:15:42 +0800
+Subject: ALSA: hda/realtek: call alc_update_headset_mode() in hp_automute_hook
+
+From: Hui Wang <hui.wang@canonical.com>
+
+commit e54f30befa7990b897189b44a56c1138c6bfdbb5 upstream.
+
+We found the alc_update_headset_mode() is not called on some machines
+when unplugging the headset, as a result, the mode of the
+ALC_HEADSET_MODE_UNPLUGGED can't be set, then the current_headset_type
+is not cleared, if users plug a differnt type of headset next time,
+the determine_headset_type() will not be called and the audio jack is
+set to the headset type of previous time.
+
+On the Dell machines which connect the dmic to the PCH, if we open
+the gnome-sound-setting and unplug the headset, this issue will
+happen. Those machines disable the auto-mute by ucm and has no
+internal mic in the input source, so the update_headset_mode() will
+not be called by cap_sync_hook or automute_hook when unplugging, and
+because the gnome-sound-setting is opened, the codec will not enter
+the runtime_suspend state, so the update_headset_mode() will not be
+called by alc_resume when unplugging. In this case the
+hp_automute_hook is called when unplugging, so add
+update_headset_mode() calling to this function.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Hui Wang <hui.wang@canonical.com>
+Link: https://lore.kernel.org/r/20210320091542.6748-2-hui.wang@canonical.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -4811,6 +4811,7 @@ static void alc_update_headset_jack_cb(s
+ struct alc_spec *spec = codec->spec;
+ spec->current_headset_type = ALC_HEADSET_TYPE_UNKNOWN;
+ snd_hda_gen_hp_automute(codec, jack);
++ alc_update_headset_mode(codec);
+ }
+
+ static void alc_probe_headset_mode(struct hda_codec *codec)
--- /dev/null
+From febf22565549ea7111e7d45e8f2d64373cc66b11 Mon Sep 17 00:00:00 2001
+From: Hui Wang <hui.wang@canonical.com>
+Date: Sat, 20 Mar 2021 17:15:41 +0800
+Subject: ALSA: hda/realtek: fix a determine_headset_type issue for a Dell AIO
+
+From: Hui Wang <hui.wang@canonical.com>
+
+commit febf22565549ea7111e7d45e8f2d64373cc66b11 upstream.
+
+We found a recording issue on a Dell AIO, users plug a headset-mic and
+select headset-mic from UI, but can't record any sound from
+headset-mic. The root cause is the determine_headset_type() returns a
+wrong type, e.g. users plug a ctia type headset, but that function
+returns omtp type.
+
+On this machine, the internal mic is not connected to the codec, the
+"Input Source" is headset mic by default. And when users plug a
+headset, the determine_headset_type() will be called immediately, the
+codec on this AIO is alc274, the delay time for this codec in the
+determine_headset_type() is only 80ms, the delay is too short to
+correctly determine the headset type, the fail rate is nearly 99% when
+users plug the headset with the normal speed.
+
+Other codecs set several hundred ms delay time, so here I change the
+delay time to 850ms for alc2x4 series, after this change, the fail
+rate is zero unless users plug the headset slowly on purpose.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Hui Wang <hui.wang@canonical.com>
+Link: https://lore.kernel.org/r/20210320091542.6748-1-hui.wang@canonical.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -4642,7 +4642,7 @@ static void alc_determine_headset_type(s
+ case 0x10ec0274:
+ case 0x10ec0294:
+ alc_process_coef_fw(codec, coef0274);
+- msleep(80);
++ msleep(850);
+ val = alc_read_coef_idx(codec, 0x46);
+ is_ctia = (val & 0x00f0) == 0x00f0;
+ break;
--- /dev/null
+From 625bd5a616ceda4840cd28f82e957c8ced394b6a Mon Sep 17 00:00:00 2001
+From: Ikjoon Jang <ikjn@chromium.org>
+Date: Wed, 24 Mar 2021 18:51:52 +0800
+Subject: ALSA: usb-audio: Apply sample rate quirk to Logitech Connect
+
+From: Ikjoon Jang <ikjn@chromium.org>
+
+commit 625bd5a616ceda4840cd28f82e957c8ced394b6a upstream.
+
+Logitech ConferenceCam Connect is a compound USB device with UVC and
+UAC. Not 100% reproducible but sometimes it keeps responding STALL to
+every control transfer once it receives get_freq request.
+
+This patch adds 046d:0x084c to a snd_usb_get_sample_rate_quirk list.
+
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203419
+Signed-off-by: Ikjoon Jang <ikjn@chromium.org>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210324105153.2322881-1-ikjn@chromium.org
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/usb/quirks.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/usb/quirks.c
++++ b/sound/usb/quirks.c
+@@ -1156,6 +1156,7 @@ bool snd_usb_get_sample_rate_quirk(struc
+ case USB_ID(0x21B4, 0x0081): /* AudioQuest DragonFly */
+ case USB_ID(0x2912, 0x30c8): /* Audioengine D1 */
+ case USB_ID(0x413c, 0xa506): /* Dell AE515 sound bar */
++ case USB_ID(0x046d, 0x084c): /* Logitech ConferenceCam Connect */
+ return true;
+ }
+ return false;
--- /dev/null
+From 6306c1189e77a513bf02720450bb43bd4ba5d8ae Mon Sep 17 00:00:00 2001
+From: Jesper Dangaard Brouer <brouer@redhat.com>
+Date: Tue, 9 Feb 2021 14:38:09 +0100
+Subject: bpf: Remove MTU check in __bpf_skb_max_len
+
+From: Jesper Dangaard Brouer <brouer@redhat.com>
+
+commit 6306c1189e77a513bf02720450bb43bd4ba5d8ae upstream.
+
+Multiple BPF-helpers that can manipulate/increase the size of the SKB uses
+__bpf_skb_max_len() as the max-length. This function limit size against
+the current net_device MTU (skb->dev->mtu).
+
+When a BPF-prog grow the packet size, then it should not be limited to the
+MTU. The MTU is a transmit limitation, and software receiving this packet
+should be allowed to increase the size. Further more, current MTU check in
+__bpf_skb_max_len uses the MTU from ingress/current net_device, which in
+case of redirects uses the wrong net_device.
+
+This patch keeps a sanity max limit of SKB_MAX_ALLOC (16KiB). The real limit
+is elsewhere in the system. Jesper's testing[1] showed it was not possible
+to exceed 8KiB when expanding the SKB size via BPF-helper. The limiting
+factor is the define KMALLOC_MAX_CACHE_SIZE which is 8192 for
+SLUB-allocator (CONFIG_SLUB) in-case PAGE_SIZE is 4096. This define is
+in-effect due to this being called from softirq context see code
+__gfp_pfmemalloc_flags() and __do_kmalloc_node(). Jakub's testing showed
+that frames above 16KiB can cause NICs to reset (but not crash). Keep this
+sanity limit at this level as memory layer can differ based on kernel
+config.
+
+[1] https://github.com/xdp-project/bpf-examples/tree/master/MTU-tests
+
+Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Acked-by: John Fastabend <john.fastabend@gmail.com>
+Link: https://lore.kernel.org/bpf/161287788936.790810.2937823995775097177.stgit@firesoul
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/core/filter.c | 11 ++++-------
+ 1 file changed, 4 insertions(+), 7 deletions(-)
+
+--- a/net/core/filter.c
++++ b/net/core/filter.c
+@@ -2279,17 +2279,14 @@ static int bpf_skb_net_shrink(struct sk_
+ return 0;
+ }
+
+-static u32 __bpf_skb_max_len(const struct sk_buff *skb)
+-{
+- return skb->dev->mtu + skb->dev->hard_header_len;
+-}
++#define BPF_SKB_MAX_LEN SKB_MAX_ALLOC
+
+ static int bpf_skb_adjust_net(struct sk_buff *skb, s32 len_diff)
+ {
+ bool trans_same = skb->transport_header == skb->network_header;
+ u32 len_cur, len_diff_abs = abs(len_diff);
+ u32 len_min = bpf_skb_net_base_len(skb);
+- u32 len_max = __bpf_skb_max_len(skb);
++ u32 len_max = BPF_SKB_MAX_LEN;
+ __be16 proto = skb->protocol;
+ bool shrink = len_diff < 0;
+ int ret;
+@@ -2368,7 +2365,7 @@ static int bpf_skb_trim_rcsum(struct sk_
+ BPF_CALL_3(bpf_skb_change_tail, struct sk_buff *, skb, u32, new_len,
+ u64, flags)
+ {
+- u32 max_len = __bpf_skb_max_len(skb);
++ u32 max_len = BPF_SKB_MAX_LEN;
+ u32 min_len = __bpf_skb_min_len(skb);
+ int ret;
+
+@@ -2419,7 +2416,7 @@ static const struct bpf_func_proto bpf_s
+ BPF_CALL_3(bpf_skb_change_head, struct sk_buff *, skb, u32, head_room,
+ u64, flags)
+ {
+- u32 max_len = __bpf_skb_max_len(skb);
++ u32 max_len = BPF_SKB_MAX_LEN;
+ u32 new_len = skb->len + head_room;
+ int ret;
+
net-ethernet-aquantia-handle-error-cleanup-of-start-.patch
appletalk-fix-skb-allocation-size-in-loopback-case.patch
net-wan-lmc-unregister-device-when-no-matching-devic.patch
+bpf-remove-mtu-check-in-__bpf_skb_max_len.patch
+alsa-usb-audio-apply-sample-rate-quirk-to-logitech-connect.patch
+alsa-hda-realtek-fix-a-determine_headset_type-issue-for-a-dell-aio.patch
+alsa-hda-realtek-call-alc_update_headset_mode-in-hp_automute_hook.patch
+tracing-fix-stack-trace-event-size.patch
--- /dev/null
+From 9deb193af69d3fd6dd8e47f292b67c805a787010 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
+Date: Thu, 1 Apr 2021 13:54:40 -0400
+Subject: tracing: Fix stack trace event size
+
+From: Steven Rostedt (VMware) <rostedt@goodmis.org>
+
+commit 9deb193af69d3fd6dd8e47f292b67c805a787010 upstream.
+
+Commit cbc3b92ce037 fixed an issue to modify the macros of the stack trace
+event so that user space could parse it properly. Originally the stack
+trace format to user space showed that the called stack was a dynamic
+array. But it is not actually a dynamic array, in the way that other
+dynamic event arrays worked, and this broke user space parsing for it. The
+update was to make the array look to have 8 entries in it. Helper
+functions were added to make it parse it correctly, as the stack was
+dynamic, but was determined by the size of the event stored.
+
+Although this fixed user space on how it read the event, it changed the
+internal structure used for the stack trace event. It changed the array
+size from [0] to [8] (added 8 entries). This increased the size of the
+stack trace event by 8 words. The size reserved on the ring buffer was the
+size of the stack trace event plus the number of stack entries found in
+the stack trace. That commit caused the amount to be 8 more than what was
+needed because it did not expect the caller field to have any size. This
+produced 8 entries of garbage (and reading random data) from the stack
+trace event:
+
+ <idle>-0 [002] d... 1976396.837549: <stack trace>
+ => trace_event_raw_event_sched_switch
+ => __traceiter_sched_switch
+ => __schedule
+ => schedule_idle
+ => do_idle
+ => cpu_startup_entry
+ => secondary_startup_64_no_verify
+ => 0xc8c5e150ffff93de
+ => 0xffff93de
+ => 0
+ => 0
+ => 0xc8c5e17800000000
+ => 0x1f30affff93de
+ => 0x00000004
+ => 0x200000000
+
+Instead, subtract the size of the caller field from the size of the event
+to make sure that only the amount needed to store the stack trace is
+reserved.
+
+Link: https://lore.kernel.org/lkml/your-ad-here.call-01617191565-ext-9692@work.hours/
+
+Cc: stable@vger.kernel.org
+Fixes: cbc3b92ce037 ("tracing: Set kernel_stack's caller size properly")
+Reported-by: Vasily Gorbik <gor@linux.ibm.com>
+Tested-by: Vasily Gorbik <gor@linux.ibm.com>
+Acked-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -2631,7 +2631,8 @@ static void __ftrace_trace_stack(struct
+ size *= sizeof(unsigned long);
+
+ event = __trace_buffer_lock_reserve(buffer, TRACE_STACK,
+- sizeof(*entry) + size, flags, pc);
++ (sizeof(*entry) - sizeof(entry->caller)) + size,
++ flags, pc);
+ if (!event)
+ goto out;
+ entry = ring_buffer_event_data(event);
projects / thirdparty / kernel / stable-queue.git / commitdiff
