- 22 Jun, 2020 40 commits
-
-
Larry Finger authored
commit ec4d3e3a upstream. This patch fixes commit 75388acd ("add mac80211-based driver for legacy BCM43xx devices") In https://bugzilla.kernel.org/show_bug.cgi?id=207093, a defect in b43legacy is reported. Upon testing, thus problem exists on PPC and X86 platforms, is present in the oldest kernel tested (3.2), and has been present in the driver since it was first added to the kernel. The problem is a corrupted channel status received from the device. Both the internal card in a PowerBook G4 and the PCMCIA version (Broadcom BCM4306 with PCI ID 14e4:4320) have the problem. Only Rev, 2 (revision 4 of the 802.11 core) of the chip has been tested. No other devices using b43legacy are available for testing. Various sources of the problem were considered. Buffer overrun and other sources of corruption within the driver were rejected because the faulty channel status is always the same, not a random value. It was concluded that the faulty data is coming from the device, probably due to a firmware bug. As that source is not available, the driver must take appropriate action to recover. At present, the driver reports the error, and them continues to process the bad packet. This is believed that to be a mistake, and the correct action is to drop the correpted packet. Fixes: 75388acd ("add mac80211-based driver for legacy BCM43xx devices") Cc: Stable <stable@vger.kernel.org> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Reported-and-tested by: F. Erhard <erhard_f@mailbox.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200407190043.1686-1-Larry.Finger@lwfinger.netSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Michał Mirosław authored
commit 81bd5d0c upstream. When BT module can't be initialized, but it has an IRQ, unloading the driver WARNs when trying to free not-yet-requested IRQ. Fix it by noting whether the IRQ was requested. WARNING: CPU: 2 PID: 214 at kernel/irq/devres.c:144 devm_free_irq+0x49/0x4ca [...] WARNING: CPU: 2 PID: 214 at kernel/irq/manage.c:1746 __free_irq+0x8b/0x27c Trying to free already-free IRQ 264 Modules linked in: hci_uart(-) btbcm bluetooth ecdh_generic ecc libaes CPU: 2 PID: 214 Comm: rmmod Tainted: G W 5.6.1mq-00044-ga5f9ea098318-dirty #928 [...] [<b016aefb>] (devm_free_irq) from [<af8ba1ff>] (bcm_close+0x97/0x118 [hci_uart]) [<af8ba1ff>] (bcm_close [hci_uart]) from [<af8b736f>] (hci_uart_unregister_device+0x33/0x3c [hci_uart]) [<af8b736f>] (hci_uart_unregister_device [hci_uart]) from [<b035930b>] (serdev_drv_remove+0x13/0x20) [<b035930b>] (serdev_drv_remove) from [<b037093b>] (device_release_driver_internal+0x97/0x118) [<b037093b>] (device_release_driver_internal) from [<b0370a0b>] (driver_detach+0x2f/0x58) [<b0370a0b>] (driver_detach) from [<b036f855>] (bus_remove_driver+0x41/0x94) [<b036f855>] (bus_remove_driver) from [<af8ba8db>] (bcm_deinit+0x1b/0x740 [hci_uart]) [<af8ba8db>] (bcm_deinit [hci_uart]) from [<af8ba86f>] (hci_uart_exit+0x13/0x30 [hci_uart]) [<af8ba86f>] (hci_uart_exit [hci_uart]) from [<b01900bd>] (sys_delete_module+0x109/0x1d0) [<b01900bd>] (sys_delete_module) from [<b0101001>] (ret_fast_syscall+0x1/0x5a) [...] Cc: stable@vger.kernel.org Fixes: 6cc4396c ("Bluetooth: hci_bcm: Add wake-up capability") Signed-off-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Chuhong Yuan authored
commit 9453264e upstream. go7007_snd_init() misses a snd_card_free() in an error path. Add the missed call to fix it. Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> [Salvatore Bonaccorso: Adjust context for backport to versions which do not contain c0decac1 ("media: use strscpy() instead of strlcpy()") and ba78170e ("media: go7007: Fix misuse of strscpy")] Signed-off-by:
Salvatore Bonaccorso <carnil@debian.org> Signed-off-by:
-
Christian Lamparter authored
commit b14fba7e upstream. This patch follows up on a bug-report by Frank Schäfer that discovered P2P GO wasn't working with wpa_supplicant. This patch removes part of the broken P2P GO support but keeps the vif switchover code in place. Cc: <stable@vger.kernel.org> Link: <https://lkml.kernel.org/r/3a9d86b6-744f-e670-8792-9167257edef8@googlemail.com> Reported-by:
Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by:
Christian Lamparter <chunkeey@gmail.com> Signed-off-by:
-
Punit Agrawal authored
commit d601afca upstream. It's an error if the value of the RX/TX tail descriptor does not match what was written. The error condition is true regardless the duration of the interference from ME. But the driver only performs the reset if E1000_ICH_FWSM_PCIM2PCI_COUNT (2000) iterations of 50us delay have transpired. The extra condition can lead to inconsistency between the state of hardware as expected by the driver. Fix this by dropping the check for number of delay iterations. While at it, also make __ew32_prepare() static as it's not used anywhere else. CC: stable <stable@vger.kernel.org> Signed-off-by:
Punit Agrawal <punit1.agrawal@toshiba.co.jp> Reviewed-by:
Alexander Duyck <alexander.h.duyck@linux.intel.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Kai-Heng Feng authored
commit f2980103 upstream. Commit b10effb9 ("e1000e: fix buffer overrun while the I219 is processing DMA transactions") imposes roughly 30% performance penalty. The commit log states that "Disabling TSO eliminates performance loss for TCP traffic without a noticeable impact on CPU performance", so let's disable TSO by default to regain the loss. CC: stable <stable@vger.kernel.org> Fixes: b10effb9 ("e1000e: fix buffer overrun while the I219 is processing DMA transactions") BugLink: https://bugs.launchpad.net/bugs/1802691Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by:
-
Ashok Raj authored
commit aa0ce96d upstream. Root Complex Integrated Endpoints (RCiEPs) do not have an upstream bridge, so pci_configure_mps() previously ignored them, which may result in reduced performance. Instead, program the Max_Payload_Size of RCiEPs to the maximum supported value (unless it is limited for the PCIE_BUS_PEER2PEER case). This also affects the subsequent programming of Max_Read_Request_Size because Linux programs MRRS based on the MPS value. Fixes: 9dae3a97 ("PCI: Move MPS configuration check to pci_configure_device()") Link: https://lore.kernel.org/r/1585343775-4019-1-git-send-email-ashok.raj@intel.comTested-by:
Dave Jiang <dave.jiang@intel.com> Signed-off-by:
Ashok Raj <ashok.raj@intel.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Roberto Sassu authored
[ Upstream commit 6cc7c266 ] If the template field 'd' is chosen and the digest to be added to the measurement entry was not calculated with SHA1 or MD5, it is recalculated with SHA1, by using the passed file descriptor. However, this cannot be done for boot_aggregate, because there is no file descriptor. This patch adds a call to ima_calc_boot_aggregate() in ima_eventdigest_init(), so that the digest can be recalculated also for the boot_aggregate entry. Cc: stable@vger.kernel.org # 3.13.x Fixes: 3ce1217d ("ima: define template fields library and new helpers") Reported-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Roberto Sassu <roberto.sassu@huawei.com> Signed-off-by:
Mimi Zohar <zohar@linux.ibm.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Filipe Manana authored
[ Upstream commit e2c8e92d ] If an error happens while running dellaloc in COW mode for a range, we can end up calling extent_clear_unlock_delalloc() for a range that goes beyond our range's end offset by 1 byte, which affects 1 extra page. This results in clearing bits and doing page operations (such as a page unlock) outside our target range. Fix that by calling extent_clear_unlock_delalloc() with an inclusive end offset, instead of an exclusive end offset, at cow_file_range(). Fixes: a315e68f ("Btrfs: fix invalid attempt to free reserved space on failure to cow range") CC: stable@vger.kernel.org # 4.14+ Signed-off-by:
Filipe Manana <fdmanana@suse.com> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Omar Sandoval authored
[ Upstream commit 6d3113a1 ] In btrfs_submit_direct_hook(), if a direct I/O write doesn't span a RAID stripe or chunk, we submit orig_bio without cloning it. In this case, we don't increment pending_bios. Then, if btrfs_submit_dio_bio() fails, we decrement pending_bios to -1, and we never complete orig_bio. Fix it by initializing pending_bios to 1 instead of incrementing later. Fixing this exposes another bug: we put orig_bio prematurely and then put it again from end_io. Fix it by not putting orig_bio. After this change, pending_bios is really more of a reference count, but I'll leave that cleanup separate to keep the fix small. Fixes: e65e1535 ("btrfs: fix panic caused by direct IO") CC: stable@vger.kernel.org # 4.4+ Reviewed-by:
Nikolay Borisov <nborisov@suse.com> Reviewed-by:
Josef Bacik <josef@toxicpanda.com> Reviewed-by:
Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by:
Omar Sandoval <osandov@fb.com> Signed-off-by:
-
Abhishek Sahu authored
[ Upstream commit a17beb1a ] Although not allowed by the PCI specs, some multi-function devices have power dependencies between the functions. For example, function 1 may not work unless function 0 is in the D0 power state. The existing quirk_gpu_hda() adds a device link to express this dependency for GPU and HDA devices, but it really is not specific to those device types. Generalize it and rename it to pci_create_device_link() so we can create dependencies between any "consumer" and "producer" functions of a multi-function device, where the consumer is only functional if the producer is in D0. This reorganization should not affect any functionality. Link: https://lore.kernel.org/lkml/20190606092225.17960-2-abhsahu@nvidia.comSigned-off-by:
Abhishek Sahu <abhsahu@nvidia.com> [bhelgaas: commit log, reword diagnostic] Signed-off-by:
-
Bjorn Helgaas authored
[ Upstream commit 7cf2cba4 ] Most of the ACS quirks have a similar pattern of: acs_flags &= ~( <controls provided by this device> ); return acs_flags ? 0 : 1; Pull this out into a helper function to simplify the quirks slightly. The helper function is also a convenient place for comments about what the list of ACS controls means. No functional change intended. Signed-off-by:
Logan Gunthorpe <logang@deltatee.com> Reviewed-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Bjorn Helgaas authored
[ Upstream commit c8de8ed2 ] The ACS quirks differ in needless ways, which makes them look more different than they really are. Reorder the ACS flags in order of definitions in the spec: PCI_ACS_SV Source Validation PCI_ACS_TB Translation Blocking PCI_ACS_RR P2P Request Redirect PCI_ACS_CR P2P Completion Redirect PCI_ACS_UF Upstream Forwarding PCI_ACS_EC P2P Egress Control PCI_ACS_DT Direct Translated P2P (PCIe r5.0, sec 7.7.8.2) and use similar code structure in all. No functional change intended. Signed-off-by:
-
Kai-Heng Feng authored
[ Upstream commit 62a7f300 ] Move the IDs to pci_ids.h so it can be used by next patch. Link: https://lore.kernel.org/r/20200508065343.32751-1-kai.heng.feng@canonical.comSigned-off-by:
-
Tiezhu Yang authored
[ Upstream commit 9acb9fe1 ] Add the Loongson vendor ID to pci_ids.h to be used by the controller driver in the future. The Loongson vendor ID can be found at the following link: https://git.kernel.org/pub/scm/utils/pciutils/pciutils.git/tree/pci.idsSigned-off-by:
Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Yazen Ghannam authored
[ Upstream commit b3f79ae4 ] Add the new PCI Device 18h IDs for AMD Family 19h systems. Note that Family 19h systems will not have a new PCI root device ID. Signed-off-by:
Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20200110015651.14887-4-Yazen.Ghannam@amd.comSigned-off-by:
-
Jon Derrick authored
[ Upstream commit ec11e5c2 ] This patch adds support for this VMD device which supports the bus restriction mode. Signed-off-by:
Jon Derrick <jonathan.derrick@intel.com> Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
-
Jonathan Chocron authored
[ Upstream commit 4a36a60c ] Add Amazon's Annapurna Labs vendor ID to pci_ids.h. Signed-off-by:
Jonathan Chocron <jonnyc@amazon.com> Signed-off-by:
Andrew Murray <andrew.murray@arm.com> Acked-by:
-
Ben Chuang authored
[ Upstream commit 4460d68f ] Add the Genesys Logic, Inc. vendor ID to pci_ids.h. Signed-off-by:
Ben Chuang <ben.chuang@genesyslogic.com.tw> Co-developed-by:
Michael K Johnson <johnsonm@danlj.org> Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Tim Blechmann authored
[ Upstream commit 789492f0 ] The pci express variant of the digigram lx6464es card has a different device ID, but works without changes to the driver. Thanks to Nikolas Slottke for reporting and testing. Signed-off-by:
Tim Blechmann <tim@klingt.org> Link: https://lore.kernel.org/r/20190906082119.40971-1-tim@klingt.orgSigned-off-by:
-
Marcel Bocu authored
[ Upstream commit af4e1c5e ] The AMD Ryzen gen 3 processors came with a different PCI IDs for the function 3 & 4 which are used to access the SMN interface. The root PCI address however remained at the same address as the model 30h. Adding the F3/F4 PCI IDs respectively to the misc and link ids appear to be sufficient for k10temp, so let's add them and follow up on the patch if other functions need more tweaking. Vicki Pfau sent an identical patch after I checked that no-one had written this patch. I would have been happy about dropping my patch but unlike for his patch series, I had already Cc:ed the x86 people and they already reviewed the changes. Since Vicki has not answered to any email after his initial series, let's assume she is on vacation and let's avoid duplication of reviews from the maintainers and merge my series. To acknowledge Vicki's anteriority, I added her S-o-b to the patch. v2, suggested by Guenter Roeck and Brian Woods: - rename from 71h to 70h Signed-off-by:
Vicki Pfau <vi@endrift.com> Signed-off-by:
Marcel Bocu <marcel.p.bocu@gmail.com> Tested-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Brian Woods <brian.woods@amd.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> # pci_ids.h Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: x86@kernel.org Cc: "Woods, Brian" <Brian.Woods@amd.com> Cc: Clemens Ladisch <clemens@ladisch.de> Cc: Jean Delvare <jdelvare@suse.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: linux-hwmon@vger.kernel.org Link: https://lore.kernel.org/r/20190722174510.2179-1-marcel.p.bocu@gmail.comSigned-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Jianjun Wang authored
[ Upstream commit 0cccd42e ] MT7629 is an ARM platform SoC which has the same PCIe IP as MT7622. The HW default value of its PCI host controller Device ID is invalid, fix it to match the hardware implementation. Signed-off-by:
Jianjun Wang <jianjun.wang@mediatek.com> [lorenzo.pieralisi@arm.com: commit log/minor spelling update] Signed-off-by:
Ryder Lee <ryder.lee@mediatek.com> Signed-off-by:
-
Lukas Wunner authored
[ Upstream commit b516ea58 ] Many NVIDIA GPUs can be configured as either a single-function video device or a multi-function device with video at function 0 and an HDA audio controller at function 1. The HDA controller can be enabled or disabled by a bit in the function 0 config space. Some BIOSes leave the HDA disabled, which means the HDMI connector from the NVIDIA GPU may not work. Sometimes the BIOS enables the HDA if an HDMI cable is connected at boot time, but that doesn't handle hotplug cases. Enable the HDA controller on device enumeration and resume and re-read the header type, which tells us whether the GPU is a multi-function device. This quirk is limited to NVIDIA PCI devices with the VGA Controller device class. This is expected to correspond to product configurations where the NVIDIA GPU has connectors attached. Other products where the device class is 3D Controller are expected to correspond to configurations where the NVIDIA GPU is dedicated (dGPU) and has no connectors. See original post (URL below) for more details. This commit takes inspiration from an earlier patch by Daniel Drake. Link: https://lore.kernel.org/r/20190708051744.24039-1-drake@endlessm.com v2 Link: https://lore.kernel.org/r/20190613063514.15317-1-drake@endlessm.com v1 Link: https://devtalk.nvidia.com/default/topic/1024022 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75985Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
Daniel Drake <drake@endlessm.com> [bhelgaas: commit log, log message, return early if already enabled] Signed-off-by:
-
Abhishek Sahu authored
[ Upstream commit 6d2e369f ] The NVIDIA Turing GPU is a multi-function PCI device with the following functions: - Function 0: VGA display controller - Function 1: Audio controller - Function 2: USB xHCI Host controller - Function 3: USB Type-C UCSI controller Function 0 is tightly coupled with other functions in the hardware. When function 0 is in D3, it gates power for hardware blocks used by other functions, which means those functions only work when function 0 is in D0. If any of these functions (1/2/3) are in D0, then function 0 should also be in D0. Commit 07f4f97d ("vga_switcheroo: Use device link for HDA controller") already creates a device link to show the dependency of function 1 on function 0 of this GPU. Create additional device links to express the dependencies of functions 2 and 3 on function 0. This means function 0 will be in D0 if any other function is in D0. [bhelgaas: I think the PCI spec expectation is that functions can be power-managed independently, so I don't think this device is technically compliant. For example, the PCIe r5.0 spec, sec 1.4, says "the PCI/PCIe hardware/software model includes architectural constructs necessary to discover, configure, and use a Function, without needing Function-specific knowledge" and sec 5.1 says "D states are associated with a particular Function" and "PM provides ... a mechanism to identify power management capabilities of a given Function [and] the ability to transition a Function into a certain power management state."] Link: https://lore.kernel.org/lkml/20190606092225.17960-3-abhsahu@nvidia.comSigned-off-by:
-
Gustavo Pimentel authored
[ Upstream commit 1f418f46 ] Create and add Synopsys Endpoint EDDA Device ID to PCI ID list, since this ID is now being use on two different drivers (pci_endpoint_test.ko and dw-edma-pcie.ko). Signed-off-by:
Gustavo Pimentel <gustavo.pimentel@synopsys.com> Acked-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Kishon Vijay Abraham I authored
[ Upstream commit 5bb04b19 ] TI's AM654x PCIe EP has a restriction that BAR_0 is mapped to application registers. "PCIe Inbound Address Translation" section in AM65x Sitara Processors TRM (SPRUID7 – April 2018) describes BAR0 as reserved. Configure pci_endpoint_test to use BAR_2 instead. Also set alignment to 64K since "PCIe Subsystem Address Translation" section in TRM indicates minimum ATU window size is 64K. Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
-
Xiaowei Bao authored
[ Upstream commit 85cef374 ] Add the layerscape EP device support in pci_endpoint_test driver. Signed-off-by:
Xiaowei Bao <xiaowei.bao@nxp.com> Signed-off-by:
Minghuan Lian <minghuan.lian@nxp.com> Reviewed-by:
Zhiqiang Hou <zhiqiang.hou@nxp.com> Reviewed-by:
-
Andy Shevchenko authored
[ Upstream commit 0ce26a1c ] Move the Rohm Vendor ID to pci_ids.h instead of defining it in several drivers. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Thinh Nguyen authored
[ Upstream commit b6061b1e ] Move Synopsys HAPS platform device IDs to pci_ids.h so that both drivers/pci/quirks.c and dwc3-haps driver can reference these IDs. Signed-off-by:
Thinh Nguyen <thinhn@synopsys.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Heiner Kallweit authored
[ Upstream commit 9206eb0b ] The PCI vendor id of U.S. Robotics isn't defined in pci_ids.h so far, only ISDN driver w6692 has a private definition. Move the definition to pci_ids.h and use it in the r8169 driver too. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Woods, Brian authored
[ Upstream commit be3518a1 ] Add the PCI device IDs for family 17h model 30h, since they are needed for accessing various registers via the data fabric/SMN interface. Signed-off-by:
-
Woods, Brian authored
[ Upstream commit dedf7dce ] Consolidate shared PCI_DEVICE_IDs that were scattered through k10temp and amd_nb, and move them into pci_ids. Signed-off-by:
-
Corey Minyard authored
[ Upstream commit 05c3d056 ] Signed-off-by:
Corey Minyard <cminyard@mvista.com> Acked-by:
-
Jakub Kicinski authored
[ Upstream commit 1ccce46c ] Defines for NFP32xx are no longer used anywhere, remove them. Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
-
Ashok Raj authored
[ Upstream commit 3247bd10 ] All Intel platforms guarantee that all root complex implementations must send transactions up to IOMMU for address translations. Hence for Intel RCiEP devices, we can assume some ACS-type isolation even without an ACS capability. From the Intel VT-d spec, r3.1, sec 3.16 ("Root-Complex Peer to Peer Considerations"): When DMA remapping is enabled, peer-to-peer requests through the Root-Complex must be handled as follows: - The input address in the request is translated (through first-level, second-level or nested translation) to a host physical address (HPA). The address decoding for peer addresses must be done only on the translated HPA. Hardware implementations are free to further limit peer-to-peer accesses to specific host physical address regions (or to completely disallow peer-forwarding of translated requests). - Since address translation changes the contents (address field) of the PCI Express Transaction Layer Packet (TLP), for PCI Express peer-to-peer requests with ECRC, the Root-Complex hardware must use the new ECRC (re-computed with the translated address) if it decides to forward the TLP as a peer request. - Root-ports, and multi-function root-complex integrated endpoints, may support additional peer-to-peer control features by supporting PCI Express Access Control Services (ACS) capability. Refer to ACS capability in PCI Express specifications for details. Since Linux didn't give special treatment to allow this exception, certain RCiEP MFD devices were grouped in a single IOMMU group. This doesn't permit a single device to be assigned to a guest for instance. In one vendor system: Device 14.x were grouped in a single IOMMU group. /sys/kernel/iommu_groups/5/devices/0000:00:14.0 /sys/kernel/iommu_groups/5/devices/0000:00:14.2 /sys/kernel/iommu_groups/5/devices/0000:00:14.3 After this patch: /sys/kernel/iommu_groups/5/devices/0000:00:14.0 /sys/kernel/iommu_groups/5/devices/0000:00:14.2 /sys/kernel/iommu_groups/6/devices/0000:00:14.3 <<< new group 14.0 and 14.2 are integrated devices, but legacy end points, whereas 14.3 was a PCIe-compliant RCiEP. 00:14.3 Network controller: Intel Corporation Device 9df0 (rev 30) Capabilities: [40] Express (v2) Root Complex Integrated Endpoint, MSI 00 This permits assigning this device to a guest VM. [bhelgaas: drop "Fixes" tag since this doesn't fix a bug in that commit] Link: https://lore.kernel.org/r/1590699462-7131-1-git-send-email-ashok.raj@intel.comTested-by:
Darrel Goeddel <dgoeddel@forcepoint.com> Signed-off-by:
-
Abhinav Ratna authored
[ Upstream commit 46b2c32d ] iProc PAXB Root Ports don't advertise an ACS capability, but they do not allow peer-to-peer transactions between Root Ports. Add an ACS quirk so each Root Port can be in a separate IOMMU group. [bhelgaas: commit log, comment, use common implementation style] Link: https://lore.kernel.org/r/1566275985-25670-1-git-send-email-srinath.mannam@broadcom.comSigned-off-by:
Abhinav Ratna <abhinav.ratna@broadcom.com> Signed-off-by:
Srinath Mannam <srinath.mannam@broadcom.com> Signed-off-by:
Scott Branden <scott.branden@broadcom.com> Signed-off-by:
-
Kevin Buettner authored
[ Upstream commit 5727043c ] The AMD Starship USB 3.0 host controller advertises Function Level Reset support, but it apparently doesn't work. Add a quirk to prevent use of FLR on this device. Without this quirk, when attempting to assign (pass through) an AMD Starship USB 3.0 host controller to a guest OS, the system becomes increasingly unresponsive over the course of several minutes, eventually requiring a hard reset. Shortly after attempting to start the guest, I see these messages: vfio-pci 0000:05:00.3: not ready 1023ms after FLR; waiting vfio-pci 0000:05:00.3: not ready 2047ms after FLR; waiting vfio-pci 0000:05:00.3: not ready 4095ms after FLR; waiting vfio-pci 0000:05:00.3: not ready 8191ms after FLR; waiting And then eventually: vfio-pci 0000:05:00.3: not ready 65535ms after FLR; giving up INFO: NMI handler (perf_event_nmi_handler) took too long to run: 0.000 msecs perf: interrupt took too long (642744 > 2500), lowering kernel.perf_event_max_sample_rate to 1000 INFO: NMI handler (perf_event_nmi_handler) took too long to run: 82.270 msecs INFO: NMI handler (perf_event_nmi_handler) took too long to run: 680.608 msecs INFO: NMI handler (perf_event_nmi_handler) took too long to run: 100.952 msecs ... watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [qemu-system-x86:7487] Tested on a Micro-Star International Co., Ltd. MS-7C59/Creator TRX40 motherboard with an AMD Ryzen Threadripper 3970X. Link: https://lore.kernel.org/r/20200524003529.598434ff@f31-4.lanSigned-off-by:
Kevin Buettner <kevinb@redhat.com> Signed-off-by:
-
Marcos Scriven authored
[ Upstream commit 0d14f06c ] The AMD Matisse HD Audio & USB 3.0 devices advertise Function Level Reset support, but hang when an FLR is triggered. To reproduce the problem, attach the device to a VM, then detach and try to attach again. Rename the existing quirk_intel_no_flr(), which was not Intel-specific, to quirk_no_flr(), and apply it to prevent the use of FLR on these AMD devices. Link: https://lore.kernel.org/r/CAAri2DpkcuQZYbT6XsALhx2e6vRqPHwtbjHYeiH7MNp4zmt1RA@mail.gmail.comSigned-off-by:
Marcos Scriven <marcos@scriven.org> Signed-off-by:
-
Kai-Heng Feng authored
[ Upstream commit 68f5fc4e ] Both Pericom OHCI and EHCI devices advertise PME# support from all power states: 06:00.0 USB controller [0c03]: Pericom Semiconductor PI7C9X442SL USB OHCI Controller [12d8:400e] (rev 01) (prog-if 10 [OHCI]) Subsystem: Pericom Semiconductor PI7C9X442SL USB OHCI Controller [12d8:400e] Capabilities: [80] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+) 06:00.2 USB controller [0c03]: Pericom Semiconductor PI7C9X442SL USB EHCI Controller [12d8:400f] (rev 01) (prog-if 20 [EHCI]) Subsystem: Pericom Semiconductor PI7C9X442SL USB EHCI Controller [12d8:400f] Capabilities: [80] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+) But testing shows that it's unreliable: there is a 20% chance PME# won't be asserted when a USB device is plugged. Remove PME support for both devices to make USB plugging work reliably. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205981 Link: https://lore.kernel.org/r/20200508065343.32751-2-kai.heng.feng@canonical.comSigned-off-by:
-
Eric Biggers authored
commit 08adf452 upstream. 'igrab(d_inode(dentry->d_parent))' without holding dentry->d_lock is broken because without d_lock, d_parent can be concurrently changed due to a rename(). Then if the old directory is immediately deleted, old d_parent->inode can be NULL. That causes a NULL dereference in igrab(). To fix this, use dget_parent() to safely grab a reference to the parent dentry, which pins the inode. This also eliminates the need to use d_find_any_alias() other than for the initial inode, as we no longer throw away the dentry at each step. This is an extremely hard race to hit, but it is possible. Adding a udelay() in between the reads of ->d_parent and its ->d_inode makes it reproducible on a no-journal filesystem using the following program: #include <fcntl.h> #include <unistd.h> int main() { if (fork()) { for (;;) { mkdir("dir1", 0700); int fd = open("dir1/file", O_RDWR|O_CREAT|O_SYNC); write(fd, "X", 1); close(fd); } } else { mkdir("dir2", 0700); for (;;) { rename("dir1/file", "dir2/file"); rmdir("dir1"); } } } Fixes: d59729f4 ("ext4: fix races in ext4_sync_parent()") Cc: stable@vger.kernel.org Signed-off-by:
Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20200506183140.541194-1-ebiggers@kernel.orgSigned-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
