- 03 Jul, 2019 15 commits
-
-
Greg Kroah-Hartman authored
Merge tag 'usb-for-v5.3-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next Felipe writes: USB: more changes for v5.3 merge window Turns out a few more important changes came about. We have the new Cadence DRD Driver being added here and that's the biggest, most important part. Together with that we have suport for new imx7ulp phy. Support for TigerLake Devices on dwc3. Also a couple important fixes which weren't completed in time for the -rc cycle. Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> * tag 'usb-for-v5.3-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb: usb: renesas_usbhs: add a workaround for a race condition of workqueue usb: gadget: udc: renesas_usb3: remove redundant assignment to ret usb: dwc2: use a longer AHB idle timeout in dwc2_core_reset() USB: gadget: function: fix issue Unneeded variable: "value" usb: phy: phy-mxs-usb: add imx7ulp support doc: dt-binding: mxs-usb-phy: add compatible for 7ulp usb:cdns3 Fix for stuck packets in on-chip OUT buffer. usb:cdns3 Add Cadence USB3 DRD Driver usb:gadget Simplify usb_decode_get_set_descriptor function. usb:gadget Patch simplify usb_decode_set_clear_feature function. usb:gadget Separated decoding functions from dwc3 driver. dt-bindings: add binding for USBSS-DRD controller. usb: dwc3: pci: add support for TigerLake Devices
-
Yoshihiro Shimoda authored
The old commit 6e4b74e4 ("usb: renesas: fix scheduling in atomic context bug") fixed an atomic issue by using workqueue for the shdmac dmaengine driver. However, this has a potential race condition issue between the work pending and usbhsg_ep_free_request() in gadget mode. When usbhsg_ep_free_request() is called while pending the queue, since the work_struct will be freed and then the work handler is called, kernel panic happens on process_one_work(). To fix the issue, if we could call cancel_work_sync() at somewhere before the free request, it could be easy. However, the usbhsg_ep_free_request() is called on atomic (e.g. f_ncm driver calls free request via gether_disconnect()). For now, almost all users are having "USB-DMAC" and the DMAengine driver can be used on atomic. So, this patch adds a workaround for a race condition to call the DMAengine APIs without the workqueue. This means we still have TODO on shdmac environment (SH7724), but since it doesn't have SMP, the race condition might not happen. Fixes: ab330cf3 ("usb: renesas_usbhs: add support for USB-DMAC") Cc: <stable@vger.kernel.org> # v4.1+ Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
-
Colin Ian King authored
Variable ret is being initialized with a value that is never read and ret is being re-assigned immediately after the initialization in both paths of an if statement. This is redundant and can be removed. Addresses-Coverity: ("Unused value") Reviewed-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Martin Blumenstingl authored
Use a 10000us AHB idle timeout in dwc2_core_reset() and make it consistent with the other "wait for AHB master IDLE state" ocurrences. This fixes a problem for me where dwc2 would not want to initialize when updating to 4.19 on a MIPS Lantiq VRX200 SoC. dwc2 worked fine with 4.14. Testing on my board shows that it takes 180us until AHB master IDLE state is signalled. The very old vendor driver for this SoC (ifxhcd) used a 1 second timeout. Use the same timeout that is used everywhere when polling for GRSTCTL_AHBIDLE instead of using a timeout that "works for one board" (180us in my case) to have consistent behavior across the dwc2 driver. Cc: linux-stable <stable@vger.kernel.org> # 4.19+ Acked-by:
Minas Harutyunyan <hminas@synopsys.com> Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
-
Hariprasad Kelam authored
fix below issue reported by coccicheck drivers/usb/gadget/function/f_eem.c:169:7-12: Unneeded variable: "value". Return "- EOPNOTSUPP" on line 179 We can not change return type of eem_setup as its registered with callback function Signed-off-by:
Hariprasad Kelam <hariprasad.kelam@gmail.com> Signed-off-by:
-
Peter Chen authored
At imx7ulp, the USB related analog register is located in PHY register region too, so we need to control PLL at PHY driver directly. Signed-off-by:
Peter Chen <peter.chen@nxp.com> Signed-off-by:
-
Peter Chen authored
Add compatible for 7ulp USB PHY. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Pawel Laszczak authored
Controller for OUT endpoints has shared on-chip buffers for all incoming packets, including ep0out. It's FIFO buffer, so packets must be handled by DMA in correct order. If the first packet in the buffer will not be handled, then the following packets directed for other endpoints and functions will be blocked. Additionally the packets directed to one endpoint can block entire on-chip buffers. In this case transfer to other endpoints also will blocked. To resolve this issue after raising the descriptor missing interrupt driver prepares internal usb_request object and use it to arm DMA transfer. The problematic situation was observed in case when endpoint has been enabled but no usb_request were queued. Driver try detects such endpoints and will use this workaround only for these endpoint. Driver use limited number of buffer. This number can be set by macro CDNS_WA2_NUM_BUFFERS. Such blocking situation was observed on ACM gadget. For this function host send OUT data packet but ACM function is not prepared for this packet. It's cause that buffer placed in on chip memory block transfer to other endpoints. Issue has been fixed for DEV_VER_V2 version of controller. Signed-off-by:
Pawel Laszczak <pawell@cadence.com> Signed-off-by:
-
Pawel Laszczak authored
This patch introduce new Cadence USBSS DRD driver to Linux kernel. The Cadence USBSS DRD Controller is a highly configurable IP Core which can be instantiated as Dual-Role Device (DRD), Peripheral Only and Host Only (XHCI)configurations. The current driver has been validated with FPGA platform. We have support for PCIe bus, which is used on FPGA prototyping. The host side of USBSS-DRD controller is compliant with XHCI specification, so it works with standard XHCI Linux driver. Signed-off-by:
-
Pawel Laszczak authored
Patch moves switch responsible for decoding descriptor type outside snprintf. It improves code readability a little. Signed-off-by:
-
Pawel Laszczak authored
Patch adds usb_decode_test_mode and usb_decode_device_feature functions, which allow to make more readable and simplify the usb_decode_set_clear_feature function. Signed-off-by:
-
Pawel Laszczak authored
Patch moves some decoding functions from driver/usb/dwc3/debug.h driver to driver/usb/gadget/debug.c file. These moved functions include: dwc3_decode_get_status dwc3_decode_set_clear_feature dwc3_decode_set_address dwc3_decode_get_set_descriptor dwc3_decode_get_configuration dwc3_decode_set_configuration dwc3_decode_get_intf dwc3_decode_set_intf dwc3_decode_synch_frame dwc3_decode_set_sel dwc3_decode_set_isoch_delay dwc3_decode_ctrl These functions are used also in inroduced cdns3 driver. All functions prefixes were changed from dwc3 to usb. Also, function's parameters has been extended according to the name of fields in standard SETUP packet. Additionally, patch adds usb_decode_ctrl function to include/linux/usb/gadget.h file. Signed-off-by: -
Pawel Laszczak authored
This patch aim at documenting USB related dt-bindings for the Cadence USBSS-DRD controller. Signed-off-by:
-
Felipe Balbi authored
This patch adds the necessary PCI ID for TGP-LP devices. Signed-off-by: -
Greg Kroah-Hartman authored
Merge tag 'usb-serial-5.3-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next Johan writes: USB-serial updates for 5.3-rc1 Here are the USB-serial updates for 5.3-rc1; just some new device ids this time. All have been in linux-next with no reported issues. Signed-off-by:
Johan Hovold <johan@kernel.org> * tag 'usb-serial-5.3-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: ftdi_sio: add ID for isodebug v1 USB: serial: option: add support for GosunCn ME3630 RNDIS mode
-
- 01 Jul, 2019 3 commits
-
-
Greg Kroah-Hartman authored
Merge tag 'phy-for-5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-next phy: for 5.3 *) Add a new PHY driver for Qualcomm PCIe2 PHY *) Add a new PHY driver for Mixel DPHY present in i.MX8 *) Fix Qualcomm QMP UFS PHY driver from incorrectly reporting that PHY enable failed *) Fix _BUG_ on Amlogic G12A USB3 + PCIE Combo PHY Driver due to calling a sleeping function from invalid context *) Fix WARN_ON dump on rcar-gen3-usb2 PHY driver caused due to imbalance powered flag *) Fix .cocci and sparse warnings Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> * tag 'phy-for-5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy: phy: qcom-qmp: Raise qcom_qmp_phy_enable() polling delay phy: meson-g12a-usb3-pcie: disable locking for cr_regmap phy: Add driver for mixel mipi dphy found on NXP's i.MX8 SoCs dt-bindings: phy: Add documentation for mixel dphy dt-bindings: phy-pxa-usb: add bindings phy: renesas: rcar-gen3-usb2: fix imbalance powered flag phy: qcom-qmp: Drop useless msm8998_pciephy_cfg setting phy: qcom-qmp: Correct READY_STATUS poll break condition phy: ti: am654-serdes: Make serdes_am654_xlate() static phy: usb: phy-brcm-usb: Fix platform_no_drv_owner.cocci warnings phy: samsung: Use struct_size() in devm_kzalloc() phy: qcom: Add Qualcomm PCIe2 PHY driver dt-bindings: phy: Add binding for Qualcomm PCIe2 PHY
-
Greg Kroah-Hartman authored
Merge tag 'phy-for-5.2-rc_v2' of git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-next Kishon writes: phy: for 5.2-rc *) Move Tegra124 PLL power supplies to be enabled by xusb-tegra124 *) Move Tegra210 PLL power supplies to be enabled by xusb-tegra210 *) Minor fixes: fix memory leaks at error path and addresses coverity. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usbGreg Kroah-Hartman authored
Felipe writes: usb: changes for v5.3 merge window The biggest part here is a set of patches removing unnecesary variables from several drivers. Meson-g12a's dwc3 glue implemented IRQ-based OTG/DRD role swap. Qcom's dwc3 glue added support for ACPI, mainly for the AArch64-based SoCs. DWC3 also got support for Intel Elkhart Lake platforms. * tag 'usb-for-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb: (30 commits) usb: dwc3: remove unused @lock member of dwc3_ep struct usb: dwc3: pci: Add Support for Intel Elkhart Lake Devices usb: Replace snprintf with scnprintf in gether_get_ifname usb: gadget: ether: Fix race between gether_disconnect and rx_submit usb: gadget: storage: Remove warning message usb: dwc3: gadget: Add support for disabling U1 and U2 entries usb: gadget: send usb_gadget as an argument in get_config_params doc: dt: bindings: usb: dwc3: Update entries for disabling U1 and U2 usb: dwc3: qcom: Use of_clk_get_parent_count() usb: dwc3: Fix core validation in probe, move after clocks are enabled usb: dwc3: qcom: Improve error handling usb: dwc3: qcom: Start USB in 'host mode' on the SDM845 usb: dwc3: qcom: Add support for booting with ACPI soc: qcom: geni: Add support for ACPI Revert "usb: dwc2: host: Setting qtd to NULL after freeing it" usb: gadget: net2272: remove redundant assignments to pointer 's' usb: gadget: Zero ffs_io_data USB: omap_udc: Remove unneeded variable fotg210-udc: Remove unneeded variable usb: gadget: at91_udc: Remove unneeded variable ...
-
- 28 Jun, 2019 1 commit
-
-
Andreas Fritiofson authored
This adds the vid:pid of the isodebug v1 isolated JTAG/SWD+UART. Only the second channel is available for use as a serial port. Signed-off-by:
Andreas Fritiofson <andreas.fritiofson@unjo.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
- 26 Jun, 2019 15 commits
-
-
Yoshihiro Shimoda authored
Now the driver fixes the issue of the commit 48298206 ("usb: gadget: renesas_usbhs: bugfix: don't modify platform data") by using usbhs_mod_info.get_vbus, this patches uses the pointer instead of copied value to avoid redundancy. Note that struct renesas_usbhs_driver_param has to use copied value because the driver has to set some members (e.g. buswait_bwait). Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Yoshihiro Shimoda authored
In device tree environment, the previous code allocates renesas_usbhs_platform_info by using devm_kzalloc() and then copies usbhs_of_data to the allocated memory. This reason is some values (e.g. .platform_callback.get_vbus) are overwritten by the driver, but the of_device_id.data is "const". Now the driver doesn't have such a code, so this patch uses renesas_usbhs_platform_info on of_device_id.data. Note that the previous code set the pdev->dev.platform_data pointer even if device tree environment, but the value is not used. So, this patch also remove such a code. Signed-off-by:
-
Yoshihiro Shimoda authored
All platform related codes (rcar[23].c and rza{2}.c) has its own .get_id function as "USBHS_GADGET". So, we can use a common function for it. Signed-off-by: -
Yoshihiro Shimoda authored
In the future, each struct renesas_usbhs_driver_param is stored on the each platform related source code (e.g. rcar3.c) to remove usbhs_parse_dt(). So, this patch moves device tree properties parsing to usbhs_probe(). Signed-off-by:
-
Yoshihiro Shimoda authored
Since this can remove over 80 charactors in a line, this patch adds struct device * declaration in usbhs_probe(). Signed-off-by:
-
Yoshihiro Shimoda authored
In the future, each struct renesas_usbhs_driver_param is stored on the each platform related source code (e.g. rcar3.c). So, to simplify the source code, this patch adds a new flag has_new_pipe_configs. Signed-off-by:
-
Yoshihiro Shimoda authored
This patch uses the dev_of_node macro instead of open coded to be better. Signed-off-by:
-
Yoshihiro Shimoda authored
Now no one uses the type member so that this patch removes it. Signed-off-by:
-
Yoshihiro Shimoda authored
To remove the type of renesas_usbhs_driver_param in the future, this patch uses a specific flag "multi_clks". Signed-off-by:
-
Yoshihiro Shimoda authored
The very old commit 48298206 ("usb: gadget: renesas_usbhs: bugfix: don't modify platform data") changed to use copied whole structures values to fix the "hung-up" issue. However, we also can fix the issue if the driver copies the get_vbus function pointer to the driver's value. So, this patch adds get_vbus member into struct usbhs_mod_info and use the pointer instead of struct renesas_usbhs_platform_callback. Signed-off-by:
-
Yoshihiro Shimoda authored
In the future, since other source code of this driver will use these macros, this patch moves it to the header file. Signed-off-by:
-
Yoshihiro Shimoda authored
The notify_hotplug callback was supported in v3.10, but the last user (armadillo800eva) was removed by the commit 1fa59bda ("ARM: shmobile: Remove legacy board code for Armadillo-800 EVA"). So, this patch removes it. Signed-off-by:
-
Yoshihiro Shimoda authored
Since the irq_vbus comments doesn't match with the current implementation, this patch revises it. This patch also changes new lines to reduce the source code lines. Signed-off-by:
-
Alan Stern authored
In the current kernel, devio.c generates a number of compiler warnings about taking the address of a member of a packed structure. The warnings all look like this one: drivers/usb/core/devio.c: In function ‘proc_do_submiturb’: drivers/usb/core/devio.c:1489:43: warning: taking address of packed member of ‘struct usb_ctrlrequest’ may result in an unaligned pointer value [-Waddress-of-packed-member] 1489 | if (uurb->buffer_length < (le16_to_cpup(&dr->wLength) + 8)) { | ^~~~~~~~~~~~ These warnings can easily be eliminated by changing various le16_to_cpup() calls to use le16_to_cpu() instead. Signed-off-by:Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Alan Stern authored
Commit 4a2a8a2c ("usbfs: private mutex for open, release, and remove") is now obsolete. The commit was created back when we had to handle both usbfs device nodes and the old usbdevfs filesystem (/proc/bus/usb/), but usbdevfs no longer exists. This means there's no longer any need to hold a mutex during two separate removal operations (and thus during an entire notifier chain call). Furthermore, the one remaining remove/release pair doesn't race with open thanks to the synchronization provided by the device model core in bus_find_device(). Remove and release don't race with each other because they both run with the device lock held. The upshot is that usbfs_mutex isn't needed any more. This patch removes it entirely. Signed-off-by:
-
- 25 Jun, 2019 2 commits
-
-
Marc Gonzalez authored
readl_poll_timeout() calls usleep_range() to sleep between reads. usleep_range() doesn't work efficiently for tiny values. Raise the polling delay in qcom_qmp_phy_enable() to bring it in line with the delay in qcom_qmp_phy_com_init(). Signed-off-by:
Marc Gonzalez <marc.w.gonzalez@free.fr> Signed-off-by:
-
Neil Armstrong authored
Locking is not needed for the phy_g12a_usb3_pcie_cr_bus_read/write() and currently it causes the following BUG because of the usage of the regmap_read_poll_timeout() running in spinlock_irq, configured by regmap fast_io. Simply disable locking in the cr_regmap config since it's only used from the PHY init callback function. BUG: sleeping function called from invalid context at drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c:85 in_atomic(): 1, irqs_disabled(): 128, pid: 60, name: kworker/3:1 [snip] Workqueue: events deferred_probe_work_func Call trace: dump_backtrace+0x0/0x190 show_stack+0x14/0x20 dump_stack+0x90/0xb4 ___might_sleep+0xec/0x110 __might_sleep+0x50/0x88 phy_g12a_usb3_pcie_cr_bus_addr.isra.0+0x80/0x1a8 phy_g12a_usb3_pcie_cr_bus_read+0x34/0x1d8 _regmap_read+0x60/0xe0 _regmap_update_bits+0xc4/0x110 regmap_update_bits_base+0x60/0x90 phy_g12a_usb3_pcie_init+0xdc/0x210 phy_init+0x74/0xd0 dwc3_meson_g12a_probe+0x2cc/0x4d0 platform_drv_probe+0x50/0xa0 really_probe+0x20c/0x3b8 driver_probe_device+0x68/0x150 __device_attach_driver+0xa8/0x170 bus_for_each_drv+0x64/0xc8 __device_attach+0xd8/0x158 device_initial_probe+0x10/0x18 bus_probe_device+0x90/0x98 deferred_probe_work_func+0x94/0xe8 process_one_work+0x1e0/0x338 worker_thread+0x230/0x458 kthread+0x134/0x138 ret_from_fork+0x10/0x1c Fixes: 36077e16 ("phy: amlogic: Add Amlogic G12A USB3 + PCIE Combo PHY Driver") Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Tested-by:
Kevin Hilman <khilman@baylibre.com> Signed-off-by:
-
- 23 Jun, 2019 1 commit
-
-
Greg Kroah-Hartman authored
We need the USB fixes in here too. Signed-off-by:
-
- 22 Jun, 2019 3 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommuLinus Torvalds authored
Pull iommu fix from Joerg Roedel: "Revert a commit from the previous pile of fixes which causes new lockdep splats. It is better to revert it for now and work on a better and more well tested fix" * tag 'iommu-fix-v5.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: Revert "iommu/vt-d: Fix lock inversion between iommu->lock and device_domain_lock"
-
Peter Xu authored
This reverts commit 7560cc3c. With 5.2.0-rc5 I can easily trigger this with lockdep and iommu=pt: ====================================================== WARNING: possible circular locking dependency detected 5.2.0-rc5 #78 Not tainted ------------------------------------------------------ swapper/0/1 is trying to acquire lock: 00000000ea2b3beb (&(&iommu->lock)->rlock){+.+.}, at: domain_context_mapping_one+0xa5/0x4e0 but task is already holding lock: 00000000a681907b (device_domain_lock){....}, at: domain_context_mapping_one+0x8d/0x4e0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (device_domain_lock){....}: _raw_spin_lock_irqsave+0x3c/0x50 dmar_insert_one_dev_info+0xbb/0x510 domain_add_dev_info+0x50/0x90 dev_prepare_static_identity_mapping+0x30/0x68 intel_iommu_init+0xddd/0x1422 pci_iommu_init+0x16/0x3f do_one_initcall+0x5d/0x2b4 kernel_init_freeable+0x218/0x2c1 kernel_init+0xa/0x100 ret_from_fork+0x3a/0x50 -> #0 (&(&iommu->lock)->rlock){+.+.}: lock_acquire+0x9e/0x170 _raw_spin_lock+0x25/0x30 domain_context_mapping_one+0xa5/0x4e0 pci_for_each_dma_alias+0x30/0x140 dmar_insert_one_dev_info+0x3b2/0x510 domain_add_dev_info+0x50/0x90 dev_prepare_static_identity_mapping+0x30/0x68 intel_iommu_init+0xddd/0x1422 pci_iommu_init+0x16/0x3f do_one_initcall+0x5d/0x2b4 kernel_init_freeable+0x218/0x2c1 kernel_init+0xa/0x100 ret_from_fork+0x3a/0x50 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(device_domain_lock); lock(&(&iommu->lock)->rlock); lock(device_domain_lock); lock(&(&iommu->lock)->rlock); *** DEADLOCK *** 2 locks held by swapper/0/1: #0: 00000000033eb13d (dmar_global_lock){++++}, at: intel_iommu_init+0x1e0/0x1422 #1: 00000000a681907b (device_domain_lock){....}, at: domain_context_mapping_one+0x8d/0x4e0 stack backtrace: CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.2.0-rc5 #78 Hardware name: LENOVO 20KGS35G01/20KGS35G01, BIOS N23ET50W (1.25 ) 06/25/2018 Call Trace: dump_stack+0x85/0xc0 print_circular_bug.cold.57+0x15c/0x195 __lock_acquire+0x152a/0x1710 lock_acquire+0x9e/0x170 ? domain_context_mapping_one+0xa5/0x4e0 _raw_spin_lock+0x25/0x30 ? domain_context_mapping_one+0xa5/0x4e0 domain_context_mapping_one+0xa5/0x4e0 ? domain_context_mapping_one+0x4e0/0x4e0 pci_for_each_dma_alias+0x30/0x140 dmar_insert_one_dev_info+0x3b2/0x510 domain_add_dev_info+0x50/0x90 dev_prepare_static_identity_mapping+0x30/0x68 intel_iommu_init+0xddd/0x1422 ? printk+0x58/0x6f ? lockdep_hardirqs_on+0xf0/0x180 ? do_early_param+0x8e/0x8e ? e820__memblock_setup+0x63/0x63 pci_iommu_init+0x16/0x3f do_one_initcall+0x5d/0x2b4 ? do_early_param+0x8e/0x8e ? rcu_read_lock_sched_held+0x55/0x60 ? do_early_param+0x8e/0x8e kernel_init_freeable+0x218/0x2c1 ? rest_init+0x230/0x230 kernel_init+0xa/0x100 ret_from_fork+0x3a/0x50 domain_context_mapping_one() is taking device_domain_lock first then iommu lock, while dmar_insert_one_dev_info() is doing the reverse. That should be introduced by commit: 7560cc3c ("iommu/vt-d: Fix lock inversion between iommu->lock and device_domain_lock", 2019-05-27) So far I still cannot figure out how the previous deadlock was triggered (I cannot find iommu lock taken before calling of iommu_flush_dev_iotlb()), however I'm pretty sure that that change should be incomplete at least because it does not fix all the places so we're still taking the locks in different orders, while reverting that commit is very clean to me so far that we should always take device_domain_lock first then the iommu lock. We can continue to try to find the real culprit mentioned in 7560cc3c, but for now I think we should revert it to fix current breakage. CC: Joerg Roedel <joro@8bytes.org> CC: Lu Baolu <baolu.lu@linux.intel.com> CC: dave.jiang@intel.com Signed-off-by:
Peter Xu <peterx@redhat.com> Tested-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Joerg Roedel <jroedel@suse.de>
-
