--- /dev/null
+From 0ed08faded1da03eb3def61502b27f81aef2e615 Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Wed, 22 Apr 2020 16:18:48 -0400
+Subject: HID: usbhid: Fix race between usbhid_close() and usbhid_stop()
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit 0ed08faded1da03eb3def61502b27f81aef2e615 upstream.
+
+The syzbot fuzzer discovered a bad race between in the usbhid driver
+between usbhid_stop() and usbhid_close(). In particular,
+usbhid_stop() does:
+
+ usb_free_urb(usbhid->urbin);
+ ...
+ usbhid->urbin = NULL; /* don't mess up next start */
+
+and usbhid_close() does:
+
+ usb_kill_urb(usbhid->urbin);
+
+with no mutual exclusion. If the two routines happen to run
+concurrently so that usb_kill_urb() is called in between the
+usb_free_urb() and the NULL assignment, it will access the
+deallocated urb structure -- a use-after-free bug.
+
+This patch adds a mutex to the usbhid private structure and uses it to
+enforce mutual exclusion of the usbhid_start(), usbhid_stop(),
+usbhid_open() and usbhid_close() callbacks.
+
+Reported-and-tested-by: syzbot+7bf5a7b0f0a1f9446f4c@syzkaller.appspotmail.com
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+CC: <stable@vger.kernel.org>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hid/usbhid/hid-core.c | 37 +++++++++++++++++++++++++++++--------
+ drivers/hid/usbhid/usbhid.h | 1 +
+ 2 files changed, 30 insertions(+), 8 deletions(-)
+
+--- a/drivers/hid/usbhid/hid-core.c
++++ b/drivers/hid/usbhid/hid-core.c
+@@ -685,16 +685,21 @@ static int usbhid_open(struct hid_device
+ struct usbhid_device *usbhid = hid->driver_data;
+ int res;
+
++ mutex_lock(&usbhid->mutex);
++
+ set_bit(HID_OPENED, &usbhid->iofl);
+
+- if (hid->quirks & HID_QUIRK_ALWAYS_POLL)
+- return 0;
++ if (hid->quirks & HID_QUIRK_ALWAYS_POLL) {
++ res = 0;
++ goto Done;
++ }
+
+ res = usb_autopm_get_interface(usbhid->intf);
+ /* the device must be awake to reliably request remote wakeup */
+ if (res < 0) {
+ clear_bit(HID_OPENED, &usbhid->iofl);
+- return -EIO;
++ res = -EIO;
++ goto Done;
+ }
+
+ usbhid->intf->needs_remote_wakeup = 1;
+@@ -728,6 +733,9 @@ static int usbhid_open(struct hid_device
+ msleep(50);
+
+ clear_bit(HID_RESUME_RUNNING, &usbhid->iofl);
++
++ Done:
++ mutex_unlock(&usbhid->mutex);
+ return res;
+ }
+
+@@ -735,6 +743,8 @@ static void usbhid_close(struct hid_devi
+ {
+ struct usbhid_device *usbhid = hid->driver_data;
+
++ mutex_lock(&usbhid->mutex);
++
+ /*
+ * Make sure we don't restart data acquisition due to
+ * a resumption we no longer care about by avoiding racing
+@@ -746,12 +756,13 @@ static void usbhid_close(struct hid_devi
+ clear_bit(HID_IN_POLLING, &usbhid->iofl);
+ spin_unlock_irq(&usbhid->lock);
+
+- if (hid->quirks & HID_QUIRK_ALWAYS_POLL)
+- return;
++ if (!(hid->quirks & HID_QUIRK_ALWAYS_POLL)) {
++ hid_cancel_delayed_stuff(usbhid);
++ usb_kill_urb(usbhid->urbin);
++ usbhid->intf->needs_remote_wakeup = 0;
++ }
+
+- hid_cancel_delayed_stuff(usbhid);
+- usb_kill_urb(usbhid->urbin);
+- usbhid->intf->needs_remote_wakeup = 0;
++ mutex_unlock(&usbhid->mutex);
+ }
+
+ /*
+@@ -1060,6 +1071,8 @@ static int usbhid_start(struct hid_devic
+ unsigned int n, insize = 0;
+ int ret;
+
++ mutex_lock(&usbhid->mutex);
++
+ clear_bit(HID_DISCONNECTED, &usbhid->iofl);
+
+ usbhid->bufsize = HID_MIN_BUFFER_SIZE;
+@@ -1180,6 +1193,8 @@ static int usbhid_start(struct hid_devic
+ usbhid_set_leds(hid);
+ device_set_wakeup_enable(&dev->dev, 1);
+ }
++
++ mutex_unlock(&usbhid->mutex);
+ return 0;
+
+ fail:
+@@ -1190,6 +1205,7 @@ fail:
+ usbhid->urbout = NULL;
+ usbhid->urbctrl = NULL;
+ hid_free_buffers(dev, hid);
++ mutex_unlock(&usbhid->mutex);
+ return ret;
+ }
+
+@@ -1205,6 +1221,8 @@ static void usbhid_stop(struct hid_devic
+ usbhid->intf->needs_remote_wakeup = 0;
+ }
+
++ mutex_lock(&usbhid->mutex);
++
+ clear_bit(HID_STARTED, &usbhid->iofl);
+ spin_lock_irq(&usbhid->lock); /* Sync with error and led handlers */
+ set_bit(HID_DISCONNECTED, &usbhid->iofl);
+@@ -1225,6 +1243,8 @@ static void usbhid_stop(struct hid_devic
+ usbhid->urbout = NULL;
+
+ hid_free_buffers(hid_to_usb_dev(hid), hid);
++
++ mutex_unlock(&usbhid->mutex);
+ }
+
+ static int usbhid_power(struct hid_device *hid, int lvl)
+@@ -1385,6 +1405,7 @@ static int usbhid_probe(struct usb_inter
+ INIT_WORK(&usbhid->reset_work, hid_reset);
+ timer_setup(&usbhid->io_retry, hid_retry_timeout, 0);
+ spin_lock_init(&usbhid->lock);
++ mutex_init(&usbhid->mutex);
+
+ ret = hid_add_device(hid);
+ if (ret) {
+--- a/drivers/hid/usbhid/usbhid.h
++++ b/drivers/hid/usbhid/usbhid.h
+@@ -93,6 +93,7 @@ struct usbhid_device {
+ dma_addr_t outbuf_dma; /* Output buffer dma */
+ unsigned long last_out; /* record of last output for timeouts */
+
++ struct mutex mutex; /* start/stop/open/close */
+ spinlock_t lock; /* fifo spinlock */
+ unsigned long iofl; /* I/O flags (CTRL_RUNNING, OUT_RUNNING) */
+ struct timer_list io_retry; /* Retry timer */
--- /dev/null
+From 778fbf4179991e7652e97d7f1ca1f657ef828422 Mon Sep 17 00:00:00 2001
+From: Jason Gerecke <jason.gerecke@wacom.com>
+Date: Wed, 1 Apr 2020 14:23:29 -0700
+Subject: HID: wacom: Read HID_DG_CONTACTMAX directly for non-generic devices
+
+From: Jason Gerecke <jason.gerecke@wacom.com>
+
+commit 778fbf4179991e7652e97d7f1ca1f657ef828422 upstream.
+
+We've recently switched from extracting the value of HID_DG_CONTACTMAX
+at a fixed offset (which may not be correct for all tablets) to
+injecting the report into the driver for the generic codepath to handle.
+Unfortunately, this change was made for *all* tablets, even those which
+aren't generic. Because `wacom_wac_report` ignores reports from non-
+generic devices, the contact count never gets initialized. Ultimately
+this results in the touch device itself failing to probe, and thus the
+loss of touch input.
+
+This commit adds back the fixed-offset extraction for non-generic devices.
+
+Link: https://github.com/linuxwacom/input-wacom/issues/155
+Fixes: 184eccd40389 ("HID: wacom: generic: read HID_DG_CONTACTMAX from any feature report")
+Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
+Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
+CC: stable@vger.kernel.org # 5.3+
+Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Cc: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hid/wacom_sys.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/hid/wacom_sys.c
++++ b/drivers/hid/wacom_sys.c
+@@ -290,9 +290,11 @@ static void wacom_feature_mapping(struct
+ data[0] = field->report->id;
+ ret = wacom_get_report(hdev, HID_FEATURE_REPORT,
+ data, n, WAC_CMD_RETRIES);
+- if (ret == n) {
++ if (ret == n && features->type == HID_GENERIC) {
+ ret = hid_report_raw_event(hdev,
+ HID_FEATURE_REPORT, data, n, 0);
++ } else if (ret == 2 && features->type != HID_GENERIC) {
++ features->touch_max = data[1];
+ } else {
+ features->touch_max = 16;
+ hid_warn(hdev, "wacom_feature_mapping: "
--- /dev/null
+From 1c32ca5dc6d00012f0c964e5fdd7042fcc71efb1 Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <maz@kernel.org>
+Date: Tue, 14 Apr 2020 15:10:08 +0100
+Subject: KVM: arm: vgic: Fix limit condition when writing to GICD_I[CS]ACTIVER
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Marc Zyngier <maz@kernel.org>
+
+commit 1c32ca5dc6d00012f0c964e5fdd7042fcc71efb1 upstream.
+
+When deciding whether a guest has to be stopped we check whether this
+is a private interrupt or not. Unfortunately, there's an off-by-one bug
+here, and we fail to recognize a whole range of interrupts as being
+global (GICv2 SPIs 32-63).
+
+Fix the condition from > to be >=.
+
+Cc: stable@vger.kernel.org
+Fixes: abd7229626b93 ("KVM: arm/arm64: Simplify active_change_prepare and plug race")
+Reported-by: André Przywara <andre.przywara@arm.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ virt/kvm/arm/vgic/vgic-mmio.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/virt/kvm/arm/vgic/vgic-mmio.c
++++ b/virt/kvm/arm/vgic/vgic-mmio.c
+@@ -381,7 +381,7 @@ static void vgic_mmio_change_active(stru
+ static void vgic_change_active_prepare(struct kvm_vcpu *vcpu, u32 intid)
+ {
+ if (vcpu->kvm->arch.vgic.vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3 ||
+- intid > VGIC_NR_PRIVATE_IRQS)
++ intid >= VGIC_NR_PRIVATE_IRQS)
+ kvm_arm_halt_guest(vcpu->kvm);
+ }
+
+@@ -389,7 +389,7 @@ static void vgic_change_active_prepare(s
+ static void vgic_change_active_finish(struct kvm_vcpu *vcpu, u32 intid)
+ {
+ if (vcpu->kvm->arch.vgic.vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3 ||
+- intid > VGIC_NR_PRIVATE_IRQS)
++ intid >= VGIC_NR_PRIVATE_IRQS)
+ kvm_arm_resume_guest(vcpu->kvm);
+ }
+
--- /dev/null
+From 0225fd5e0a6a32af7af0aefac45c8ebf19dc5183 Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <maz@kernel.org>
+Date: Wed, 29 Apr 2020 11:21:55 +0100
+Subject: KVM: arm64: Fix 32bit PC wrap-around
+
+From: Marc Zyngier <maz@kernel.org>
+
+commit 0225fd5e0a6a32af7af0aefac45c8ebf19dc5183 upstream.
+
+In the unlikely event that a 32bit vcpu traps into the hypervisor
+on an instruction that is located right at the end of the 32bit
+range, the emulation of that instruction is going to increment
+PC past the 32bit range. This isn't great, as userspace can then
+observe this value and get a bit confused.
+
+Conversly, userspace can do things like (in the context of a 64bit
+guest that is capable of 32bit EL0) setting PSTATE to AArch64-EL0,
+set PC to a 64bit value, change PSTATE to AArch32-USR, and observe
+that PC hasn't been truncated. More confusion.
+
+Fix both by:
+- truncating PC increments for 32bit guests
+- sanitizing all 32bit regs every time a core reg is changed by
+ userspace, and that PSTATE indicates a 32bit mode.
+
+Cc: stable@vger.kernel.org
+Acked-by: Will Deacon <will@kernel.org>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/kvm/guest.c | 7 +++++++
+ virt/kvm/arm/hyp/aarch32.c | 8 ++++++--
+ 2 files changed, 13 insertions(+), 2 deletions(-)
+
+--- a/arch/arm64/kvm/guest.c
++++ b/arch/arm64/kvm/guest.c
+@@ -179,6 +179,13 @@ static int set_core_reg(struct kvm_vcpu
+ }
+
+ memcpy((u32 *)regs + off, valp, KVM_REG_SIZE(reg->id));
++
++ if (*vcpu_cpsr(vcpu) & PSR_MODE32_BIT) {
++ int i;
++
++ for (i = 0; i < 16; i++)
++ *vcpu_reg32(vcpu, i) = (u32)*vcpu_reg32(vcpu, i);
++ }
+ out:
+ return err;
+ }
+--- a/virt/kvm/arm/hyp/aarch32.c
++++ b/virt/kvm/arm/hyp/aarch32.c
+@@ -125,12 +125,16 @@ static void __hyp_text kvm_adjust_itstat
+ */
+ void __hyp_text kvm_skip_instr32(struct kvm_vcpu *vcpu, bool is_wide_instr)
+ {
++ u32 pc = *vcpu_pc(vcpu);
+ bool is_thumb;
+
+ is_thumb = !!(*vcpu_cpsr(vcpu) & PSR_AA32_T_BIT);
+ if (is_thumb && !is_wide_instr)
+- *vcpu_pc(vcpu) += 2;
++ pc += 2;
+ else
+- *vcpu_pc(vcpu) += 4;
++ pc += 4;
++
++ *vcpu_pc(vcpu) = pc;
++
+ kvm_adjust_itstate(vcpu);
+ }
--- /dev/null
+From 145cb2f7177d94bc54563ed26027e952ee0ae03c Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Jere=20Lepp=C3=A4nen?= <jere.leppanen@nokia.com>
+Date: Tue, 21 Apr 2020 22:03:41 +0300
+Subject: sctp: Fix bundling of SHUTDOWN with COOKIE-ACK
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Jere Leppänen <jere.leppanen@nokia.com>
+
+commit 145cb2f7177d94bc54563ed26027e952ee0ae03c upstream.
+
+When we start shutdown in sctp_sf_do_dupcook_a(), we want to bundle
+the SHUTDOWN with the COOKIE-ACK to ensure that the peer receives them
+at the same time and in the correct order. This bundling was broken by
+commit 4ff40b86262b ("sctp: set chunk transport correctly when it's a
+new asoc"), which assigns a transport for the COOKIE-ACK, but not for
+the SHUTDOWN.
+
+Fix this by passing a reference to the COOKIE-ACK chunk as an argument
+to sctp_sf_do_9_2_start_shutdown() and onward to
+sctp_make_shutdown(). This way the SHUTDOWN chunk is assigned the same
+transport as the COOKIE-ACK chunk, which allows them to be bundled.
+
+In sctp_sf_do_9_2_start_shutdown(), the void *arg parameter was
+previously unused. Now that we're taking it into use, it must be a
+valid pointer to a chunk, or NULL. There is only one call site where
+it's not, in sctp_sf_autoclose_timer_expire(). Fix that too.
+
+Fixes: 4ff40b86262b ("sctp: set chunk transport correctly when it's a new asoc")
+Signed-off-by: Jere Leppänen <jere.leppanen@nokia.com>
+Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Cc: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/sctp/sm_statefuns.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/net/sctp/sm_statefuns.c
++++ b/net/sctp/sm_statefuns.c
+@@ -1880,7 +1880,7 @@ static enum sctp_disposition sctp_sf_do_
+ */
+ sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(repl));
+ return sctp_sf_do_9_2_start_shutdown(net, ep, asoc,
+- SCTP_ST_CHUNK(0), NULL,
++ SCTP_ST_CHUNK(0), repl,
+ commands);
+ } else {
+ sctp_add_cmd_sf(commands, SCTP_CMD_NEW_STATE,
+@@ -5483,7 +5483,7 @@ enum sctp_disposition sctp_sf_do_9_2_sta
+ * in the Cumulative TSN Ack field the last sequential TSN it
+ * has received from the peer.
+ */
+- reply = sctp_make_shutdown(asoc, NULL);
++ reply = sctp_make_shutdown(asoc, arg);
+ if (!reply)
+ goto nomem;
+
+@@ -6081,7 +6081,7 @@ enum sctp_disposition sctp_sf_autoclose_
+ disposition = SCTP_DISPOSITION_CONSUME;
+ if (sctp_outq_is_empty(&asoc->outqueue)) {
+ disposition = sctp_sf_do_9_2_start_shutdown(net, ep, asoc, type,
+- arg, commands);
++ NULL, commands);
+ }
+
+ return disposition;
bnxt_en-improve-aer-slot-reset.patch
bnxt_en-fix-vf-anti-spoof-filter-setup.patch
net-stricter-validation-of-untrusted-gso-packets.patch
+hid-wacom-read-hid_dg_contactmax-directly-for-non-generic-devices.patch
+sctp-fix-bundling-of-shutdown-with-cookie-ack.patch
+hid-usbhid-fix-race-between-usbhid_close-and-usbhid_stop.patch
+usb-uas-add-quirk-for-lacie-2big-quadra.patch
+usb-serial-garmin_gps-add-sanity-checking-for-data-length.patch
+tracing-add-a-vmalloc_sync_mappings-for-safe-measure.patch
+kvm-arm-vgic-fix-limit-condition-when-writing-to-gicd_iactiver.patch
+kvm-arm64-fix-32bit-pc-wrap-around.patch
--- /dev/null
+From 11f5efc3ab66284f7aaacc926e9351d658e2577b Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
+Date: Wed, 6 May 2020 10:36:18 -0400
+Subject: tracing: Add a vmalloc_sync_mappings() for safe measure
+
+From: Steven Rostedt (VMware) <rostedt@goodmis.org>
+
+commit 11f5efc3ab66284f7aaacc926e9351d658e2577b upstream.
+
+x86_64 lazily maps in the vmalloc pages, and the way this works with per_cpu
+areas can be complex, to say the least. Mappings may happen at boot up, and
+if nothing synchronizes the page tables, those page mappings may not be
+synced till they are used. This causes issues for anything that might touch
+one of those mappings in the path of the page fault handler. When one of
+those unmapped mappings is touched in the page fault handler, it will cause
+another page fault, which in turn will cause a page fault, and leave us in
+a loop of page faults.
+
+Commit 763802b53a42 ("x86/mm: split vmalloc_sync_all()") split
+vmalloc_sync_all() into vmalloc_sync_unmappings() and
+vmalloc_sync_mappings(), as on system exit, it did not need to do a full
+sync on x86_64 (although it still needed to be done on x86_32). By chance,
+the vmalloc_sync_all() would synchronize the page mappings done at boot up
+and prevent the per cpu area from being a problem for tracing in the page
+fault handler. But when that synchronization in the exit of a task became a
+nop, it caused the problem to appear.
+
+Link: https://lore.kernel.org/r/20200429054857.66e8e333@oasis.local.home
+
+Cc: stable@vger.kernel.org
+Fixes: 737223fbca3b1 ("tracing: Consolidate buffer allocation code")
+Reported-by: "Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com>
+Suggested-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/trace/trace.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -7750,6 +7750,19 @@ static int allocate_trace_buffers(struct
+ */
+ allocate_snapshot = false;
+ #endif
++
++ /*
++ * Because of some magic with the way alloc_percpu() works on
++ * x86_64, we need to synchronize the pgd of all the tables,
++ * otherwise the trace events that happen in x86_64 page fault
++ * handlers can't cope with accessing the chance that a
++ * alloc_percpu()'d memory might be touched in the page fault trace
++ * event. Oh, and we need to audit all other alloc_percpu() and vmalloc()
++ * calls in tracing, because something might get triggered within a
++ * page fault trace event!
++ */
++ vmalloc_sync_mappings();
++
+ return 0;
+ }
+
--- /dev/null
+From e9b3c610a05c1cdf8e959a6d89c38807ff758ee6 Mon Sep 17 00:00:00 2001
+From: Oliver Neukum <oneukum@suse.com>
+Date: Wed, 15 Apr 2020 16:03:04 +0200
+Subject: USB: serial: garmin_gps: add sanity checking for data length
+
+From: Oliver Neukum <oneukum@suse.com>
+
+commit e9b3c610a05c1cdf8e959a6d89c38807ff758ee6 upstream.
+
+We must not process packets shorter than a packet ID
+
+Signed-off-by: Oliver Neukum <oneukum@suse.com>
+Reported-and-tested-by: syzbot+d29e9263e13ce0b9f4fd@syzkaller.appspotmail.com
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/serial/garmin_gps.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/serial/garmin_gps.c
++++ b/drivers/usb/serial/garmin_gps.c
+@@ -1138,8 +1138,8 @@ static void garmin_read_process(struct g
+ send it directly to the tty port */
+ if (garmin_data_p->flags & FLAGS_QUEUING) {
+ pkt_add(garmin_data_p, data, data_length);
+- } else if (bulk_data ||
+- getLayerId(data) == GARMIN_LAYERID_APPL) {
++ } else if (bulk_data || (data_length >= sizeof(u32) &&
++ getLayerId(data) == GARMIN_LAYERID_APPL)) {
+
+ spin_lock_irqsave(&garmin_data_p->lock, flags);
+ garmin_data_p->flags |= APP_RESP_SEEN;
--- /dev/null
+From 9f04db234af691007bb785342a06abab5fb34474 Mon Sep 17 00:00:00 2001
+From: Oliver Neukum <oneukum@suse.com>
+Date: Wed, 29 Apr 2020 17:52:18 +0200
+Subject: USB: uas: add quirk for LaCie 2Big Quadra
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Oliver Neukum <oneukum@suse.com>
+
+commit 9f04db234af691007bb785342a06abab5fb34474 upstream.
+
+This device needs US_FL_NO_REPORT_OPCODES to avoid going
+through prolonged error handling on enumeration.
+
+Signed-off-by: Oliver Neukum <oneukum@suse.com>
+Reported-by: Julian Groß <julian.g@posteo.de>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200429155218.7308-1-oneukum@suse.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/storage/unusual_uas.h | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/usb/storage/unusual_uas.h
++++ b/drivers/usb/storage/unusual_uas.h
+@@ -28,6 +28,13 @@
+ * and don't forget to CC: the USB development list <linux-usb@vger.kernel.org>
+ */
+
++/* Reported-by: Julian Groß <julian.g@posteo.de> */
++UNUSUAL_DEV(0x059f, 0x105f, 0x0000, 0x9999,
++ "LaCie",
++ "2Big Quadra USB3",
++ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
++ US_FL_NO_REPORT_OPCODES),
++
+ /*
+ * Apricorn USB3 dongle sometimes returns "USBSUSBSUSBS" in response to SCSI
+ * commands in UAS mode. Observed with the 1.28 firmware; are there others?
projects / thirdparty / kernel / stable-queue.git / commitdiff
