--- /dev/null
+From 96f1b00138cb8f04c742c82d0a7c460b2202e887 Mon Sep 17 00:00:00 2001
+From: Vineet Gupta <vgupta@synopsys.com>
+Date: Tue, 8 Jun 2021 19:39:25 -0700
+Subject: ARCv2: save ABI registers across signal handling
+
+From: Vineet Gupta <vgupta@synopsys.com>
+
+commit 96f1b00138cb8f04c742c82d0a7c460b2202e887 upstream.
+
+ARCv2 has some configuration dependent registers (r30, r58, r59) which
+could be targetted by the compiler. To keep the ABI stable, these were
+unconditionally part of the glibc ABI
+(sysdeps/unix/sysv/linux/arc/sys/ucontext.h:mcontext_t) however we
+missed populating them (by saving/restoring them across signal
+handling).
+
+This patch fixes the issue by
+ - adding arcv2 ABI regs to kernel struct sigcontext
+ - populating them during signal handling
+
+Change to struct sigcontext might seem like a glibc ABI change (although
+it primarily uses ucontext_t:mcontext_t) but the fact is
+ - it has only been extended (existing fields are not touched)
+ - the old sigcontext was ABI incomplete to begin with anyways
+
+Fixes: https://github.com/foss-for-synopsys-dwc-arc-processors/linux/issues/53
+Cc: <stable@vger.kernel.org>
+Tested-by: kernel test robot <lkp@intel.com>
+Reported-by: Vladimir Isaev <isaev@synopsys.com>
+Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arc/include/uapi/asm/sigcontext.h | 1
+ arch/arc/kernel/signal.c | 43 +++++++++++++++++++++++++++++++++
+ 2 files changed, 44 insertions(+)
+
+--- a/arch/arc/include/uapi/asm/sigcontext.h
++++ b/arch/arc/include/uapi/asm/sigcontext.h
+@@ -18,6 +18,7 @@
+ */
+ struct sigcontext {
+ struct user_regs_struct regs;
++ struct user_regs_arcv2 v2abi;
+ };
+
+ #endif /* _ASM_ARC_SIGCONTEXT_H */
+--- a/arch/arc/kernel/signal.c
++++ b/arch/arc/kernel/signal.c
+@@ -64,6 +64,41 @@ struct rt_sigframe {
+ unsigned int sigret_magic;
+ };
+
++static int save_arcv2_regs(struct sigcontext *mctx, struct pt_regs *regs)
++{
++ int err = 0;
++#ifndef CONFIG_ISA_ARCOMPACT
++ struct user_regs_arcv2 v2abi;
++
++ v2abi.r30 = regs->r30;
++#ifdef CONFIG_ARC_HAS_ACCL_REGS
++ v2abi.r58 = regs->r58;
++ v2abi.r59 = regs->r59;
++#else
++ v2abi.r58 = v2abi.r59 = 0;
++#endif
++ err = __copy_to_user(&mctx->v2abi, &v2abi, sizeof(v2abi));
++#endif
++ return err;
++}
++
++static int restore_arcv2_regs(struct sigcontext *mctx, struct pt_regs *regs)
++{
++ int err = 0;
++#ifndef CONFIG_ISA_ARCOMPACT
++ struct user_regs_arcv2 v2abi;
++
++ err = __copy_from_user(&v2abi, &mctx->v2abi, sizeof(v2abi));
++
++ regs->r30 = v2abi.r30;
++#ifdef CONFIG_ARC_HAS_ACCL_REGS
++ regs->r58 = v2abi.r58;
++ regs->r59 = v2abi.r59;
++#endif
++#endif
++ return err;
++}
++
+ static int
+ stash_usr_regs(struct rt_sigframe __user *sf, struct pt_regs *regs,
+ sigset_t *set)
+@@ -97,6 +132,10 @@ stash_usr_regs(struct rt_sigframe __user
+
+ err = __copy_to_user(&(sf->uc.uc_mcontext.regs.scratch), &uregs.scratch,
+ sizeof(sf->uc.uc_mcontext.regs.scratch));
++
++ if (is_isa_arcv2())
++ err |= save_arcv2_regs(&(sf->uc.uc_mcontext), regs);
++
+ err |= __copy_to_user(&sf->uc.uc_sigmask, set, sizeof(sigset_t));
+
+ return err ? -EFAULT : 0;
+@@ -112,6 +151,10 @@ static int restore_usr_regs(struct pt_re
+ err |= __copy_from_user(&uregs.scratch,
+ &(sf->uc.uc_mcontext.regs.scratch),
+ sizeof(sf->uc.uc_mcontext.regs.scratch));
++
++ if (is_isa_arcv2())
++ err |= restore_arcv2_regs(&(sf->uc.uc_mcontext), regs);
++
+ if (err)
+ return -EFAULT;
+
--- /dev/null
+From 5e87ddbe3942e27e939bdc02deb8579b0cbd8ecc Mon Sep 17 00:00:00 2001
+From: Norbert Slusarek <nslusarek@gmx.net>
+Date: Sat, 12 Jun 2021 22:18:54 +0200
+Subject: can: bcm: fix infoleak in struct bcm_msg_head
+
+From: Norbert Slusarek <nslusarek@gmx.net>
+
+commit 5e87ddbe3942e27e939bdc02deb8579b0cbd8ecc upstream.
+
+On 64-bit systems, struct bcm_msg_head has an added padding of 4 bytes between
+struct members count and ival1. Even though all struct members are initialized,
+the 4-byte hole will contain data from the kernel stack. This patch zeroes out
+struct bcm_msg_head before usage, preventing infoleaks to userspace.
+
+Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol")
+Link: https://lore.kernel.org/r/trinity-7c1b2e82-e34f-4885-8060-2cd7a13769ce-1623532166177@3c-app-gmx-bs52
+Cc: linux-stable <stable@vger.kernel.org>
+Signed-off-by: Norbert Slusarek <nslusarek@gmx.net>
+Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/can/bcm.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/net/can/bcm.c
++++ b/net/can/bcm.c
+@@ -393,6 +393,7 @@ static void bcm_tx_timeout_tsklet(unsign
+ if (!op->count && (op->flags & TX_COUNTEVT)) {
+
+ /* create notification to user */
++ memset(&msg_head, 0, sizeof(msg_head));
+ msg_head.opcode = TX_EXPIRED;
+ msg_head.flags = op->flags;
+ msg_head.count = op->count;
+@@ -440,6 +441,7 @@ static void bcm_rx_changed(struct bcm_op
+ /* this element is not throttled anymore */
+ data->flags &= (BCM_CAN_FLAGS_MASK|RX_RECV);
+
++ memset(&head, 0, sizeof(head));
+ head.opcode = RX_CHANGED;
+ head.flags = op->flags;
+ head.count = op->count;
+@@ -554,6 +556,7 @@ static void bcm_rx_timeout_tsklet(unsign
+ struct bcm_msg_head msg_head;
+
+ /* create notification to user */
++ memset(&msg_head, 0, sizeof(msg_head));
+ msg_head.opcode = RX_TIMEOUT;
+ msg_head.flags = op->flags;
+ msg_head.count = op->count;
--- /dev/null
+From 91c02557174be7f72e46ed7311e3bea1939840b0 Mon Sep 17 00:00:00 2001
+From: Pavel Skripkin <paskripkin@gmail.com>
+Date: Thu, 10 Jun 2021 00:58:33 +0300
+Subject: can: mcba_usb: fix memory leak in mcba_usb
+
+From: Pavel Skripkin <paskripkin@gmail.com>
+
+commit 91c02557174be7f72e46ed7311e3bea1939840b0 upstream.
+
+Syzbot reported memory leak in SocketCAN driver for Microchip CAN BUS
+Analyzer Tool. The problem was in unfreed usb_coherent.
+
+In mcba_usb_start() 20 coherent buffers are allocated and there is
+nothing, that frees them:
+
+1) In callback function the urb is resubmitted and that's all
+2) In disconnect function urbs are simply killed, but URB_FREE_BUFFER
+ is not set (see mcba_usb_start) and this flag cannot be used with
+ coherent buffers.
+
+Fail log:
+| [ 1354.053291][ T8413] mcba_usb 1-1:0.0 can0: device disconnected
+| [ 1367.059384][ T8420] kmemleak: 20 new suspected memory leaks (see /sys/kernel/debug/kmem)
+
+So, all allocated buffers should be freed with usb_free_coherent()
+explicitly
+
+NOTE:
+The same pattern for allocating and freeing coherent buffers
+is used in drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c
+
+Fixes: 51f3baad7de9 ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer")
+Link: https://lore.kernel.org/r/20210609215833.30393-1-paskripkin@gmail.com
+Cc: linux-stable <stable@vger.kernel.org>
+Reported-and-tested-by: syzbot+57281c762a3922e14dfe@syzkaller.appspotmail.com
+Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/can/usb/mcba_usb.c | 17 +++++++++++++++--
+ 1 file changed, 15 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/can/usb/mcba_usb.c
++++ b/drivers/net/can/usb/mcba_usb.c
+@@ -93,6 +93,8 @@ struct mcba_priv {
+ bool can_ka_first_pass;
+ bool can_speed_check;
+ atomic_t free_ctx_cnt;
++ void *rxbuf[MCBA_MAX_RX_URBS];
++ dma_addr_t rxbuf_dma[MCBA_MAX_RX_URBS];
+ };
+
+ /* CAN frame */
+@@ -644,6 +646,7 @@ static int mcba_usb_start(struct mcba_pr
+ for (i = 0; i < MCBA_MAX_RX_URBS; i++) {
+ struct urb *urb = NULL;
+ u8 *buf;
++ dma_addr_t buf_dma;
+
+ /* create a URB, and a buffer for it */
+ urb = usb_alloc_urb(0, GFP_KERNEL);
+@@ -653,7 +656,7 @@ static int mcba_usb_start(struct mcba_pr
+ }
+
+ buf = usb_alloc_coherent(priv->udev, MCBA_USB_RX_BUFF_SIZE,
+- GFP_KERNEL, &urb->transfer_dma);
++ GFP_KERNEL, &buf_dma);
+ if (!buf) {
+ netdev_err(netdev, "No memory left for USB buffer\n");
+ usb_free_urb(urb);
+@@ -672,11 +675,14 @@ static int mcba_usb_start(struct mcba_pr
+ if (err) {
+ usb_unanchor_urb(urb);
+ usb_free_coherent(priv->udev, MCBA_USB_RX_BUFF_SIZE,
+- buf, urb->transfer_dma);
++ buf, buf_dma);
+ usb_free_urb(urb);
+ break;
+ }
+
++ priv->rxbuf[i] = buf;
++ priv->rxbuf_dma[i] = buf_dma;
++
+ /* Drop reference, USB core will take care of freeing it */
+ usb_free_urb(urb);
+ }
+@@ -719,7 +725,14 @@ static int mcba_usb_open(struct net_devi
+
+ static void mcba_urb_unlink(struct mcba_priv *priv)
+ {
++ int i;
++
+ usb_kill_anchored_urbs(&priv->rx_submitted);
++
++ for (i = 0; i < MCBA_MAX_RX_URBS; ++i)
++ usb_free_coherent(priv->udev, MCBA_USB_RX_BUFF_SIZE,
++ priv->rxbuf[i], priv->rxbuf_dma[i]);
++
+ usb_kill_anchored_urbs(&priv->tx_submitted);
+ }
+
--- /dev/null
+From db2f77e2bd99dbd2fb23ddde58f0fae392fe3338 Mon Sep 17 00:00:00 2001
+From: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
+Date: Fri, 21 May 2021 21:13:17 -0400
+Subject: PCI: Add ACS quirk for Broadcom BCM57414 NIC
+
+From: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
+
+commit db2f77e2bd99dbd2fb23ddde58f0fae392fe3338 upstream.
+
+The Broadcom BCM57414 NIC may be a multi-function device. While it does
+not advertise an ACS capability, peer-to-peer transactions are not possible
+between the individual functions, so it is safe to treat them as fully
+isolated.
+
+Add an ACS quirk for this device so the functions can be in independent
+IOMMU groups and attached individually to userspace applications using
+VFIO.
+
+[bhelgaas: commit log]
+Link: https://lore.kernel.org/r/1621645997-16251-1-git-send-email-michael.chan@broadcom.com
+Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
+Signed-off-by: Michael Chan <michael.chan@broadcom.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/quirks.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -4711,6 +4711,8 @@ static const struct pci_dev_acs_enabled
+ { PCI_VENDOR_ID_AMPERE, 0xE00A, pci_quirk_xgene_acs },
+ { PCI_VENDOR_ID_AMPERE, 0xE00B, pci_quirk_xgene_acs },
+ { PCI_VENDOR_ID_AMPERE, 0xE00C, pci_quirk_xgene_acs },
++ /* Broadcom multi-function device */
++ { PCI_VENDOR_ID_BROADCOM, 0x16D7, pci_quirk_mf_endpoint_acs },
+ { PCI_VENDOR_ID_BROADCOM, 0xD714, pci_quirk_brcm_acs },
+ { 0 }
+ };
--- /dev/null
+From 4c207e7121fa92b66bf1896bf8ccb9edfb0f9731 Mon Sep 17 00:00:00 2001
+From: Shanker Donthineni <sdonthineni@nvidia.com>
+Date: Tue, 8 Jun 2021 11:18:56 +0530
+Subject: PCI: Mark some NVIDIA GPUs to avoid bus reset
+
+From: Shanker Donthineni <sdonthineni@nvidia.com>
+
+commit 4c207e7121fa92b66bf1896bf8ccb9edfb0f9731 upstream.
+
+Some NVIDIA GPU devices do not work with SBR. Triggering SBR leaves the
+device inoperable for the current system boot. It requires a system
+hard-reboot to get the GPU device back to normal operating condition
+post-SBR. For the affected devices, enable NO_BUS_RESET quirk to avoid the
+issue.
+
+This issue will be fixed in the next generation of hardware.
+
+Link: https://lore.kernel.org/r/20210608054857.18963-8-ameynarkhede03@gmail.com
+Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Sinan Kaya <okaya@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/quirks.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -3464,6 +3464,18 @@ static void quirk_no_bus_reset(struct pc
+ }
+
+ /*
++ * Some NVIDIA GPU devices do not work with bus reset, SBR needs to be
++ * prevented for those affected devices.
++ */
++static void quirk_nvidia_no_bus_reset(struct pci_dev *dev)
++{
++ if ((dev->device & 0xffc0) == 0x2340)
++ quirk_no_bus_reset(dev);
++}
++DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
++ quirk_nvidia_no_bus_reset);
++
++/*
+ * Some Atheros AR9xxx and QCA988x chips do not behave after a bus reset.
+ * The device will throw a Link Down error on AER-capable systems and
+ * regardless of AER, config space of the device is never accessible again
--- /dev/null
+From b5cf198e74a91073d12839a3e2db99994a39995d Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Antti=20J=C3=A4rvinen?= <antti.jarvinen@gmail.com>
+Date: Mon, 15 Mar 2021 10:26:06 +0000
+Subject: PCI: Mark TI C667X to avoid bus reset
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Antti Järvinen <antti.jarvinen@gmail.com>
+
+commit b5cf198e74a91073d12839a3e2db99994a39995d upstream.
+
+Some TI KeyStone C667X devices do not support bus/hot reset. The PCIESS
+automatically disables LTSSM when Secondary Bus Reset is received and
+device stops working. Prevent bus reset for these devices. With this
+change, the device can be assigned to VMs with VFIO, but it will leak state
+between VMs.
+
+Reference: https://e2e.ti.com/support/processors/f/791/t/954382
+Link: https://lore.kernel.org/r/20210315102606.17153-1-antti.jarvinen@gmail.com
+Signed-off-by: Antti Järvinen <antti.jarvinen@gmail.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/quirks.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -3483,6 +3483,16 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_A
+ */
+ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_CAVIUM, 0xa100, quirk_no_bus_reset);
+
++/*
++ * Some TI KeyStone C667X devices do not support bus/hot reset. The PCIESS
++ * automatically disables LTSSM when Secondary Bus Reset is received and
++ * the device stops working. Prevent bus reset for these devices. With
++ * this change, the device can be assigned to VMs with VFIO, but it will
++ * leak state between VMs. Reference
++ * https://e2e.ti.com/support/processors/f/791/t/954382
++ */
++DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TI, 0xb005, quirk_no_bus_reset);
++
+ static void quirk_no_pm_reset(struct pci_dev *dev)
+ {
+ /*
--- /dev/null
+From ce00322c2365e1f7b0312f2f493539c833465d97 Mon Sep 17 00:00:00 2001
+From: Chiqijun <chiqijun@huawei.com>
+Date: Mon, 24 May 2021 17:44:07 -0500
+Subject: PCI: Work around Huawei Intelligent NIC VF FLR erratum
+
+From: Chiqijun <chiqijun@huawei.com>
+
+commit ce00322c2365e1f7b0312f2f493539c833465d97 upstream.
+
+pcie_flr() starts a Function Level Reset (FLR), waits 100ms (the maximum
+time allowed for FLR completion by PCIe r5.0, sec 6.6.2), and waits for the
+FLR to complete. It assumes the FLR is complete when a config read returns
+valid data.
+
+When we do an FLR on several Huawei Intelligent NIC VFs at the same time,
+firmware on the NIC processes them serially. The VF may respond to config
+reads before the firmware has completed its reset processing. If we bind a
+driver to the VF (e.g., by assigning the VF to a virtual machine) in the
+interval between the successful config read and completion of the firmware
+reset processing, the NIC VF driver may fail to load.
+
+Prevent this driver failure by waiting for the NIC firmware to complete its
+reset processing. Not all NIC firmware supports this feature.
+
+[bhelgaas: commit log]
+Link: https://support.huawei.com/enterprise/en/doc/EDOC1100063073/87950645/vm-oss-occasionally-fail-to-load-the-in200-driver-when-the-vf-performs-flr
+Link: https://lore.kernel.org/r/20210414132301.1793-1-chiqijun@huawei.com
+Signed-off-by: Chiqijun <chiqijun@huawei.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/quirks.c | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++
+ 1 file changed, 65 insertions(+)
+
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -3897,6 +3897,69 @@ static int delay_250ms_after_flr(struct
+ return 0;
+ }
+
++#define PCI_DEVICE_ID_HINIC_VF 0x375E
++#define HINIC_VF_FLR_TYPE 0x1000
++#define HINIC_VF_FLR_CAP_BIT (1UL << 30)
++#define HINIC_VF_OP 0xE80
++#define HINIC_VF_FLR_PROC_BIT (1UL << 18)
++#define HINIC_OPERATION_TIMEOUT 15000 /* 15 seconds */
++
++/* Device-specific reset method for Huawei Intelligent NIC virtual functions */
++static int reset_hinic_vf_dev(struct pci_dev *pdev, int probe)
++{
++ unsigned long timeout;
++ void __iomem *bar;
++ u32 val;
++
++ if (probe)
++ return 0;
++
++ bar = pci_iomap(pdev, 0, 0);
++ if (!bar)
++ return -ENOTTY;
++
++ /* Get and check firmware capabilities */
++ val = ioread32be(bar + HINIC_VF_FLR_TYPE);
++ if (!(val & HINIC_VF_FLR_CAP_BIT)) {
++ pci_iounmap(pdev, bar);
++ return -ENOTTY;
++ }
++
++ /* Set HINIC_VF_FLR_PROC_BIT for the start of FLR */
++ val = ioread32be(bar + HINIC_VF_OP);
++ val = val | HINIC_VF_FLR_PROC_BIT;
++ iowrite32be(val, bar + HINIC_VF_OP);
++
++ pcie_flr(pdev);
++
++ /*
++ * The device must recapture its Bus and Device Numbers after FLR
++ * in order generate Completions. Issue a config write to let the
++ * device capture this information.
++ */
++ pci_write_config_word(pdev, PCI_VENDOR_ID, 0);
++
++ /* Firmware clears HINIC_VF_FLR_PROC_BIT when reset is complete */
++ timeout = jiffies + msecs_to_jiffies(HINIC_OPERATION_TIMEOUT);
++ do {
++ val = ioread32be(bar + HINIC_VF_OP);
++ if (!(val & HINIC_VF_FLR_PROC_BIT))
++ goto reset_complete;
++ msleep(20);
++ } while (time_before(jiffies, timeout));
++
++ val = ioread32be(bar + HINIC_VF_OP);
++ if (!(val & HINIC_VF_FLR_PROC_BIT))
++ goto reset_complete;
++
++ pci_warn(pdev, "Reset dev timeout, FLR ack reg: %#010x\n", val);
++
++reset_complete:
++ pci_iounmap(pdev, bar);
++
++ return 0;
++}
++
+ static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82599_SFP_VF,
+ reset_intel_82599_sfp_virtfn },
+@@ -3908,6 +3971,8 @@ static const struct pci_dev_reset_method
+ { PCI_VENDOR_ID_INTEL, 0x0953, delay_250ms_after_flr },
+ { PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
+ reset_chelsio_generic_dev },
++ { PCI_VENDOR_ID_HUAWEI, PCI_DEVICE_ID_HINIC_VF,
++ reset_hinic_vf_dev },
+ { 0 }
+ };
+
pinctrl-ralink-rt2880-avoid-to-error-in-calls-is-pin.patch
radeon-use-memcpy_to-fromio-for-uvd-fw-upload.patch
hwmon-scpi-hwmon-shows-the-negative-temperature-prop.patch
+can-bcm-fix-infoleak-in-struct-bcm_msg_head.patch
+can-mcba_usb-fix-memory-leak-in-mcba_usb.patch
+usb-core-hub-disable-autosuspend-for-cypress-cy7c65632.patch
+tracing-do-not-stop-recording-cmdlines-when-tracing-is-off.patch
+tracing-do-not-stop-recording-comms-if-the-trace-file-is-being-read.patch
+tracing-do-no-increment-trace_clock_global-by-one.patch
+pci-mark-ti-c667x-to-avoid-bus-reset.patch
+pci-mark-some-nvidia-gpus-to-avoid-bus-reset.patch
+pci-add-acs-quirk-for-broadcom-bcm57414-nic.patch
+pci-work-around-huawei-intelligent-nic-vf-flr-erratum.patch
+arcv2-save-abi-registers-across-signal-handling.patch
--- /dev/null
+From 89529d8b8f8daf92d9979382b8d2eb39966846ea Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
+Date: Thu, 17 Jun 2021 17:12:35 -0400
+Subject: tracing: Do no increment trace_clock_global() by one
+
+From: Steven Rostedt (VMware) <rostedt@goodmis.org>
+
+commit 89529d8b8f8daf92d9979382b8d2eb39966846ea upstream.
+
+The trace_clock_global() tries to make sure the events between CPUs is
+somewhat in order. A global value is used and updated by the latest read
+of a clock. If one CPU is ahead by a little, and is read by another CPU, a
+lock is taken, and if the timestamp of the other CPU is behind, it will
+simply use the other CPUs timestamp.
+
+The lock is also only taken with a "trylock" due to tracing, and strange
+recursions can happen. The lock is not taken at all in NMI context.
+
+In the case where the lock is not able to be taken, the non synced
+timestamp is returned. But it will not be less than the saved global
+timestamp.
+
+The problem arises because when the time goes "backwards" the time
+returned is the saved timestamp plus 1. If the lock is not taken, and the
+plus one to the timestamp is returned, there's a small race that can cause
+the time to go backwards!
+
+ CPU0 CPU1
+ ---- ----
+ trace_clock_global() {
+ ts = clock() [ 1000 ]
+ trylock(clock_lock) [ success ]
+ global_ts = ts; [ 1000 ]
+
+ <interrupted by NMI>
+ trace_clock_global() {
+ ts = clock() [ 999 ]
+ if (ts < global_ts)
+ ts = global_ts + 1 [ 1001 ]
+
+ trylock(clock_lock) [ fail ]
+
+ return ts [ 1001]
+ }
+ unlock(clock_lock);
+ return ts; [ 1000 ]
+ }
+
+ trace_clock_global() {
+ ts = clock() [ 1000 ]
+ if (ts < global_ts) [ false 1000 == 1000 ]
+
+ trylock(clock_lock) [ success ]
+ global_ts = ts; [ 1000 ]
+ unlock(clock_lock)
+
+ return ts; [ 1000 ]
+ }
+
+The above case shows to reads of trace_clock_global() on the same CPU, but
+the second read returns one less than the first read. That is, time when
+backwards, and this is not what is allowed by trace_clock_global().
+
+This was triggered by heavy tracing and the ring buffer checker that tests
+for the clock going backwards:
+
+ Ring buffer clock went backwards: 20613921464 -> 20613921463
+ ------------[ cut here ]------------
+ WARNING: CPU: 2 PID: 0 at kernel/trace/ring_buffer.c:3412 check_buffer+0x1b9/0x1c0
+ Modules linked in:
+ [..]
+ [CPU: 2]TIME DOES NOT MATCH expected:20620711698 actual:20620711697 delta:6790234 before:20613921463 after:20613921463
+ [20613915818] PAGE TIME STAMP
+ [20613915818] delta:0
+ [20613915819] delta:1
+ [20613916035] delta:216
+ [20613916465] delta:430
+ [20613916575] delta:110
+ [20613916749] delta:174
+ [20613917248] delta:499
+ [20613917333] delta:85
+ [20613917775] delta:442
+ [20613917921] delta:146
+ [20613918321] delta:400
+ [20613918568] delta:247
+ [20613918768] delta:200
+ [20613919306] delta:538
+ [20613919353] delta:47
+ [20613919980] delta:627
+ [20613920296] delta:316
+ [20613920571] delta:275
+ [20613920862] delta:291
+ [20613921152] delta:290
+ [20613921464] delta:312
+ [20613921464] delta:0 TIME EXTEND
+ [20613921464] delta:0
+
+This happened more than once, and always for an off by one result. It also
+started happening after commit aafe104aa9096 was added.
+
+Cc: stable@vger.kernel.org
+Fixes: aafe104aa9096 ("tracing: Restructure trace_clock_global() to never block")
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_clock.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/kernel/trace/trace_clock.c
++++ b/kernel/trace/trace_clock.c
+@@ -115,9 +115,9 @@ u64 notrace trace_clock_global(void)
+ prev_time = READ_ONCE(trace_clock_struct.prev_time);
+ now = sched_clock_cpu(this_cpu);
+
+- /* Make sure that now is always greater than prev_time */
++ /* Make sure that now is always greater than or equal to prev_time */
+ if ((s64)(now - prev_time) < 0)
+- now = prev_time + 1;
++ now = prev_time;
+
+ /*
+ * If in an NMI context then dont risk lockups and simply return
+@@ -131,7 +131,7 @@ u64 notrace trace_clock_global(void)
+ /* Reread prev_time in case it was already updated */
+ prev_time = READ_ONCE(trace_clock_struct.prev_time);
+ if ((s64)(now - prev_time) < 0)
+- now = prev_time + 1;
++ now = prev_time;
+
+ trace_clock_struct.prev_time = now;
+
--- /dev/null
+From 85550c83da421fb12dc1816c45012e1e638d2b38 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
+Date: Thu, 17 Jun 2021 13:47:25 -0400
+Subject: tracing: Do not stop recording cmdlines when tracing is off
+
+From: Steven Rostedt (VMware) <rostedt@goodmis.org>
+
+commit 85550c83da421fb12dc1816c45012e1e638d2b38 upstream.
+
+The saved_cmdlines is used to map pids to the task name, such that the
+output of the tracing does not just show pids, but also gives a human
+readable name for the task.
+
+If the name is not mapped, the output looks like this:
+
+ <...>-1316 [005] ...2 132.044039: ...
+
+Instead of this:
+
+ gnome-shell-1316 [005] ...2 132.044039: ...
+
+The names are updated when tracing is running, but are skipped if tracing
+is stopped. Unfortunately, this stops the recording of the names if the
+top level tracer is stopped, and not if there's other tracers active.
+
+The recording of a name only happens when a new event is written into a
+ring buffer, so there is no need to test if tracing is on or not. If
+tracing is off, then no event is written and no need to test if tracing is
+off or not.
+
+Remove the check, as it hides the names of tasks for events in the
+instance buffers.
+
+Cc: stable@vger.kernel.org
+Fixes: 7ffbd48d5cab2 ("tracing: Cache comms only after an event occurred")
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -2031,8 +2031,6 @@ static bool tracing_record_taskinfo_skip
+ {
+ if (unlikely(!(flags & (TRACE_RECORD_CMDLINE | TRACE_RECORD_TGID))))
+ return true;
+- if (atomic_read(&trace_record_taskinfo_disabled) || !tracing_is_on())
+- return true;
+ if (!__this_cpu_read(trace_taskinfo_save))
+ return true;
+ return false;
--- /dev/null
+From 4fdd595e4f9a1ff6d93ec702eaecae451cfc6591 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
+Date: Thu, 17 Jun 2021 14:32:34 -0400
+Subject: tracing: Do not stop recording comms if the trace file is being read
+
+From: Steven Rostedt (VMware) <rostedt@goodmis.org>
+
+commit 4fdd595e4f9a1ff6d93ec702eaecae451cfc6591 upstream.
+
+A while ago, when the "trace" file was opened, tracing was stopped, and
+code was added to stop recording the comms to saved_cmdlines, for mapping
+of the pids to the task name.
+
+Code has been added that only records the comm if a trace event occurred,
+and there's no reason to not trace it if the trace file is opened.
+
+Cc: stable@vger.kernel.org
+Fixes: 7ffbd48d5cab2 ("tracing: Cache comms only after an event occurred")
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace.c | 9 ---------
+ 1 file changed, 9 deletions(-)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -1743,9 +1743,6 @@ struct saved_cmdlines_buffer {
+ };
+ static struct saved_cmdlines_buffer *savedcmd;
+
+-/* temporary disable recording */
+-static atomic_t trace_record_taskinfo_disabled __read_mostly;
+-
+ static inline char *get_saved_cmdlines(int idx)
+ {
+ return &savedcmd->saved_cmdlines[idx * TASK_COMM_LEN];
+@@ -3259,9 +3256,6 @@ static void *s_start(struct seq_file *m,
+ return ERR_PTR(-EBUSY);
+ #endif
+
+- if (!iter->snapshot)
+- atomic_inc(&trace_record_taskinfo_disabled);
+-
+ if (*pos != iter->pos) {
+ iter->ent = NULL;
+ iter->cpu = 0;
+@@ -3304,9 +3298,6 @@ static void s_stop(struct seq_file *m, v
+ return;
+ #endif
+
+- if (!iter->snapshot)
+- atomic_dec(&trace_record_taskinfo_disabled);
+-
+ trace_access_unlock(iter->cpu_file);
+ trace_event_read_unlock();
+ }
--- /dev/null
+From a7d8d1c7a7f73e780aa9ae74926ae5985b2f895f Mon Sep 17 00:00:00 2001
+From: Andrew Lunn <andrew@lunn.ch>
+Date: Mon, 14 Jun 2021 17:55:23 +0200
+Subject: usb: core: hub: Disable autosuspend for Cypress CY7C65632
+
+From: Andrew Lunn <andrew@lunn.ch>
+
+commit a7d8d1c7a7f73e780aa9ae74926ae5985b2f895f upstream.
+
+The Cypress CY7C65632 appears to have an issue with auto suspend and
+detecting devices, not too dissimilar to the SMSC 5534B hub. It is
+easiest to reproduce by connecting multiple mass storage devices to
+the hub at the same time. On a Lenovo Yoga, around 1 in 3 attempts
+result in the devices not being detected. It is however possible to
+make them appear using lsusb -v.
+
+Disabling autosuspend for this hub resolves the issue.
+
+Fixes: 1208f9e1d758 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub")
+Cc: stable@vger.kernel.org
+Signed-off-by: Andrew Lunn <andrew@lunn.ch>
+Link: https://lore.kernel.org/r/20210614155524.2228800-1-andrew@lunn.ch
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/core/hub.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/usb/core/hub.c
++++ b/drivers/usb/core/hub.c
+@@ -38,6 +38,8 @@
+ #define USB_VENDOR_GENESYS_LOGIC 0x05e3
+ #define USB_VENDOR_SMSC 0x0424
+ #define USB_PRODUCT_USB5534B 0x5534
++#define USB_VENDOR_CYPRESS 0x04b4
++#define USB_PRODUCT_CY7C65632 0x6570
+ #define HUB_QUIRK_CHECK_PORT_AUTOSUSPEND 0x01
+ #define HUB_QUIRK_DISABLE_AUTOSUSPEND 0x02
+
+@@ -5443,6 +5445,11 @@ static const struct usb_device_id hub_id
+ .bInterfaceClass = USB_CLASS_HUB,
+ .driver_info = HUB_QUIRK_DISABLE_AUTOSUSPEND},
+ { .match_flags = USB_DEVICE_ID_MATCH_VENDOR
++ | USB_DEVICE_ID_MATCH_PRODUCT,
++ .idVendor = USB_VENDOR_CYPRESS,
++ .idProduct = USB_PRODUCT_CY7C65632,
++ .driver_info = HUB_QUIRK_DISABLE_AUTOSUSPEND},
++ { .match_flags = USB_DEVICE_ID_MATCH_VENDOR
+ | USB_DEVICE_ID_MATCH_INT_CLASS,
+ .idVendor = USB_VENDOR_GENESYS_LOGIC,
+ .bInterfaceClass = USB_CLASS_HUB,
projects / thirdparty / kernel / stable-queue.git / commitdiff
