summaryrefslogtreecommitdiff
path: root/drivers/usb/host/xhci.c
AgeCommit message (Collapse)Author
2021-06-21xhci: remove redundant continue statementColin Ian King
The continue statement at the end of a for-loop has no effect, remove it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Addresses-Coverity: ("Continue has no effect") Cc: Mathias Nyman <mathias.nyman@intel.com> Link: https://lore.kernel.org/r/20210618090447.99114-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-17xhci: handle failed buffer copy to URB sg list and fix a W=1 copiler warningMathias Nyman
Set the urb->actual_length to bytes successfully copied in case all bytes weren't copied from a temporary buffer to the URB sg list. Also print a debug message Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210617150354.1512157-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13xhci: Do not use GFP_KERNEL in (potentially) atomic contextChristophe JAILLET
'xhci_urb_enqueue()' is passed a 'mem_flags' argument, because "URBs may be submitted in interrupt context" (see comment related to 'usb_submit_urb()' in 'drivers/usb/core/urb.c') So this flag should be used in all the calling chain. Up to now, 'xhci_check_maxpacket()' which is only called from 'xhci_urb_enqueue()', uses GFP_KERNEL. Be safe and pass the mem_flags to this function as well. Fixes: ddba5cd0aeff ("xhci: Use command structures when queuing commands on the command ring") Cc: <stable@vger.kernel.org> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210512080816.866037-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-06xhci: fix potential array out of bounds with several interruptersMathias Nyman
The Max Interrupters supported by the controller is given in a 10bit wide bitfield, but the driver uses a fixed 128 size array to index these interrupters. Klockwork reports a possible array out of bounds case which in theory is possible. In practice this hasn't been hit as a common number of Max Interrupters for new controllers is 8, not even close to 128. This needs to be fixed anyway Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210406070208.3406266-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-06xhci: check control context is valid before dereferencing it.Mathias Nyman
Don't dereference ctrl_ctx before checking it's valid. Issue reported by Klockwork Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210406070208.3406266-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-23usb: xhci: Init root hub SSP rateThinh Nguyen
Initialize USB 3.x root hub SuperSpeed Plus rate. Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/f1698a96d5f9dfaefb857b95e5db6135ae0c9e93.1615432770.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-15Merge 5.12-rc3 into usb-nextGreg Kroah-Hartman
We want the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-11xhci: Fix repeated xhci wake after suspend due to uncleared internal wake stateMathias Nyman
If port terminations are detected in suspend, but link never reaches U0 then xHCI may have an internal uncleared wake state that will cause an immediate wake after suspend. This wake state is normally cleared when driver clears the PORT_CSC bit, which is set after a device is enabled and in U0. Write 1 to clear PORT_CSC for ports that don't have anything connected when suspending. This makes sure any pending internal wake states in xHCI are cleared. Cc: stable@vger.kernel.org Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210311115353.2137560-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-11xhci: Improve detection of device initiated wake signal.Mathias Nyman
A xHC USB 3 port might miss the first wake signal from a USB 3 device if the port LFPS reveiver isn't enabled fast enough after xHC resume. xHC host will anyway be resumed by a PME# signal, but will go back to suspend if no port activity is seen. The device resends the U3 LFPS wake signal after a 100ms delay, but by then host is already suspended, starting all over from the beginning of this issue. USB 3 specs say U3 wake LFPS signal is sent for max 10ms, then device needs to delay 100ms before resending the wake. Don't suspend immediately if port activity isn't detected in resume. Instead add a retry. If there is no port activity then delay for 120ms, and re-check for port activity. Cc: <stable@vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210311115353.2137560-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-10usb: xhci-mtk: support to build xhci-mtk-hcd.koChunfeng Yun
Currently xhci-hcd.ko building depends on USB_XHCI_MTK, this is not flexible for some cases. For example: USB_XHCI_HCD is y, and USB_XHCI_MTK is m, then we can't implement extended functions if only update xhci-mtk.ko This patch is used to remove the dependence. Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/0b62e21ddfacc1c2874726dd27ccab80c993f303.1615170625.git.chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-02-08Merge 5.11-rc7 into usb-nextGreg Kroah-Hartman
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-29xhci: split handling halted endpoints into two stepsMathias Nyman
Don't queue both a reset endpoint command and a set TR deq command at once when handling a halted endpoint. split this into two steps. Initially only queue a reset endpoint command, and then if needed queue a set TR deq command in the reset endpoint handler. Note: This removes the RESET_EP_QUIRK handling which was added in commit ac9d8fe7c6a8 ("USB: xhci: Add quirk for Fresco Logic xHCI hardware.") This quirk was added in 2009 for prototype xHCI hardware meant for evaluation purposes only, and should not reach consumers. This hardware could not handle two commands queued at once, and had bad data in the output context after a reset endpoint command. After this patch two command are no longer queued at once, so that part is solved in this rewrite, but the workaround for bad data in the output context solved by issuing an extra configure endpoint command is bluntly removed. Adding this workaround to the new rewrite just adds complexity, and I think it's time to let this quirk go. Print a debug message instead. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210129130044.206855-22-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-26usb: xhci-mtk: fix unreleased bandwidth dataIkjoon Jang
xhci-mtk needs XHCI_MTK_HOST quirk functions in add_endpoint() and drop_endpoint() to handle its own sw bandwidth management. It stores bandwidth data into an internal table every time add_endpoint() is called, and drops those in drop_endpoint(). But when bandwidth allocation fails at one endpoint, all earlier allocation from the same interface could still remain at the table. This patch moves bandwidth management codes to check_bandwidth() and reset_bandwidth() path. To do so, this patch also adds those functions to xhci_driver_overrides and lets mtk-xhci to release all failed endpoints in reset_bandwidth() path. Fixes: 08e469de87a2 ("usb: xhci-mtk: supports bandwidth scheduling with multi-TT") Signed-off-by: Ikjoon Jang <ikjn@chromium.org> Link: https://lore.kernel.org/r/20210113180444.v6.1.Id0d31b5f3ddf5e734d2ab11161ac5821921b1e1e@changeid Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-28USB: xhci: fix U1/U2 handling for hardware with XHCI_INTEL_HOST quirk setMichael Grzeschik
The commit 0472bf06c6fd ("xhci: Prevent U1/U2 link pm states if exit latency is too long") was constraining the xhci code not to allow U1/U2 sleep states if the latency to wake up from the U-states reached the service interval of an periodic endpoint. This fix was not taking into account that in case the quirk XHCI_INTEL_HOST is set, the wakeup time will be calculated and configured differently. It checks for u1_params.mel/u2_params.mel as a limit. But the code could decide to write another MEL into the hardware. This leads to broken cases where not enough bandwidth is available for other devices: usb 1-2: can't set config #1, error -28 This patch is fixing that case by checking for timeout_ns after the wakeup time was calculated depending on the quirks. Fixes: 0472bf06c6fd ("xhci: Prevent U1/U2 link pm states if exit latency is too long") Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201215193147.11738-1-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-09usb: xhci: Use temporary buffer to consolidate SGTejas Joglekar
The Synopsys xHC has an internal TRB cache of size TRB_CACHE_SIZE for each endpoint. The default value for TRB_CACHE_SIZE is 16 for SS and 8 for HS. The controller loads and updates the TRB cache from the transfer ring in system memory whenever the driver issues a start transfer or update transfer command. For chained TRBs, the Synopsys xHC requires that the total amount of bytes for all TRBs loaded in the TRB cache be greater than or equal to 1 MPS. Or the chain ends within the TRB cache (with a last TRB). If this requirement is not met, the controller will not be able to send or receive a packet and it will hang causing a driver timeout and error. This can be a problem if a class driver queues SG requests with many small-buffer entries. The XHCI driver will create a chained TRB for each entry which may trigger this issue. This patch adds logic to the XHCI driver to detect and prevent this from happening. For every (TRB_CACHE_SIZE - 2), we check the total buffer size of the SG list and if the last window of (TRB_CACHE_SIZE - 2) SG list length and we don't make up at least 1 MPS, we create a temporary buffer to consolidate full SG list into the buffer. We check at (TRB_CACHE_SIZE - 2) window because it is possible that there would be a link and/or event data TRB that take up to 2 of the cache entries. We discovered this issue with devices on other platforms but have not yet come across any device that triggers this on Linux. But it could be a real problem now or in the future. All it takes is N number of small chained TRBs. And other instances of the Synopsys IP may have smaller values for the TRB_CACHE_SIZE which would exacerbate the problem. Signed-off-by: Tejas Joglekar <joglekar@synopsys.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20201208092912.1773650-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-02Merge 5.10-rc2 into usb-nextGreg Kroah-Hartman
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-29xhci: Don't create stream debugfs files with spinlock held.Mathias Nyman
Creating debugfs files while loding the spin_lock_irqsave(xhci->lock) creates a lock dependecy that could possibly deadlock. Lockdep warns: ===================================================== WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected 5.10.0-rc1pdx86+ #8 Not tainted ----------------------------------------------------- systemd-udevd/386 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: ffffffffb1a94038 (pin_fs_lock){+.+.}-{2:2}, at: simple_pin_fs+0x22/0xa0 and this task is already holding: ffff9e7b87fbc430 (&xhci->lock){-.-.}-{2:2}, at: xhci_alloc_streams+0x5f9/0x810 which would create a new lock dependency: (&xhci->lock){-.-.}-{2:2} -> (pin_fs_lock){+.+.}-{2:2} Create the files a bit later after lock is released. Fixes: 673d74683627 ("usb: xhci: add debugfs support for ep with stream") CC: Li Jun <jun.li@nxp.com> Reported-by: Hans de Goede <hdegoede@redhat.com> Reported-by: Mike Galbraith <efault@gmx.de> Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20201028203124.375344-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-28usb: xhci: Remove in_interrupt() checksAhmed S. Darwish
The usage of in_interrupt() in drivers is phased out for various reasons. xhci_set_hc_event_deq() has an !in_interrupt() check which is pointless because the function is only invoked from xhci_mem_init() which is clearly task context as it does GFP_KERNEL allocations. Remove it. xhci_urb_enqueue() prints a debug message if an URB is submitted after the underlying hardware was suspended. But that warning is only issued when in_interrupt() is true, which makes no sense. Simply return -ESHUTDOWN and be done with it. Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Mathias Nyman <mathias.nyman@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Link: https://lore.kernel.org/r/20201019101110.148631116@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-20usb: xhci: add debugfs support for ep with streamLi Jun
To show the trb ring of streams, use the exsiting ring files of bulk ep to show trb ring of one specific stream ID, which stream ID's trb ring will be shown, is controlled by a new debugfs file stream_id, this is to avoid to create a large number of dir for every allocate stream IDs, another debugfs file stream_context_array is created to show all the allocated stream context array entries. Signed-off-by: Li Jun <jun.li@nxp.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200918131752.16488-11-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-20xhci: don't create endpoint debugfs entry before ring buffer is set.Mathias Nyman
Make sure xHC completes the configure endpoint command and xhci driver sets the ring pointers correctly before we create the user readable debugfs file. In theory there was a small gap where a user could have read the debugfs file and cause a NULL pointer dereference error as ring pointer was not yet set, in practise we want this change to simplify the upcoming streams debugfs support. Fixes: 02b6fdc2a153 ("usb: xhci: Add debugfs interface for xHCI driver") Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200918131752.16488-10-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-20usb: xhci: omit duplicate actions when suspending a runtime suspended host.Peter Chen
If the xhci-plat.c is the platform driver, after the runtime pm is enabled, the xhci_suspend is called if nothing is connected on the port. When the system goes to suspend, it will call xhci_suspend again if USB wakeup is enabled. Since the runtime suspend wakeup setting is not always the same as system suspend wakeup setting, eg, at runtime suspend we always need wakeup if the controller is in low power mode; but at system suspend, we may not need wakeup. So, we move the judgement after changing wakeup setting. [commit message rewording -Mathias] Reviewed-by: Jun Li <jun.li@nxp.com> Signed-off-by: Peter Chen <peter.chen@nxp.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200918131752.16488-8-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-30Merge tag 'usb-5.9-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB fixes from Greg KH: "Let's try this again... Here are some USB fixes for 5.9-rc3. This differs from the previous pull request for this release in that the usb gadget patch now does not break some systems, and actually does what it was intended to do. Many thanks to Marek Szyprowski for quickly noticing and testing the patch from Andy Shevchenko to resolve this issue. Additionally, some more new USB quirks have been added to get some new devices to work properly based on user reports. Other than that, the patches are all here, and they contain: - usb gadget driver fixes - xhci driver fixes - typec fixes - new quirks and ids - fixes for USB patches that went into 5.9-rc1. All of these have been tested in linux-next with no reported issues" * tag 'usb-5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (33 commits) usb: storage: Add unusual_uas entry for Sony PSZ drives USB: Ignore UAS for JMicron JMS567 ATA/ATAPI Bridge usb: host: ohci-exynos: Fix error handling in exynos_ohci_probe() USB: gadget: u_f: Unbreak offset calculation in VLAs USB: quirks: Ignore duplicate endpoint on Sound Devices MixPre-D usb: typec: tcpm: Fix Fix source hard reset response for TDA 2.3.1.1 and TDA 2.3.1.2 failures USB: PHY: JZ4770: Fix static checker warning. USB: gadget: f_ncm: add bounds checks to ncm_unwrap_ntb() USB: gadget: u_f: add overflow checks to VLA macros xhci: Always restore EP_SOFT_CLEAR_TOGGLE even if ep reset failed xhci: Do warm-reset when both CAS and XDEV_RESUME are set usb: host: xhci: fix ep context print mismatch in debugfs usb: uas: Add quirk for PNY Pro Elite tools: usb: move to tools buildsystem USB: Fix device driver race USB: Also match device drivers using the ->match vfunc usb: host: xhci-tegra: fix tegra_xusb_get_phy() usb: host: xhci-tegra: otg usb2/usb3 port init usb: hcd: Fix use after free in usb_hcd_pci_remove() usb: typec: ucsi: Hold con->lock for the entire duration of ucsi_register_port() ...
2020-08-23treewide: Use fallthrough pseudo-keywordGustavo A. R. Silva
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
2020-08-23xhci: Always restore EP_SOFT_CLEAR_TOGGLE even if ep reset failedDing Hui
Some device drivers call libusb_clear_halt when target ep queue is not empty. (eg. spice client connected to qemu for usb redir) Before commit f5249461b504 ("xhci: Clear the host side toggle manually when endpoint is soft reset"), that works well. But now, we got the error log: EP not empty, refuse reset xhci_endpoint_reset failed and left ep_state's EP_SOFT_CLEAR_TOGGLE bit still set So all the subsequent urb sumbits to the ep will fail with the warn log: Can't enqueue URB while manually clearing toggle We need to clear ep_state EP_SOFT_CLEAR_TOGGLE bit after xhci_endpoint_reset, even if it failed. Fixes: f5249461b504 ("xhci: Clear the host side toggle manually when endpoint is soft reset") Cc: stable <stable@vger.kernel.org> # v4.17+ Signed-off-by: Ding Hui <dinghui@sangfor.com.cn> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200821091549.20556-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-09usb: host: xhci: Demote obvious misuse of kerneldoc to standard comment blockLee Jones
No attempt has been made to document the demoted function here. Fixes the following W=1 kernel build warning(s): drivers/usb/host/xhci.c:1285: warning: Function parameter or member 'desc' not described in 'xhci_get_endpoint_index' Cc: Mathias Nyman <mathias.nyman@intel.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20200703174148.2749969-14-lee.jones@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-24xhci: Poll for U0 after disabling USB2 LPMKai-Heng Feng
USB2 devices with LPM enabled may interrupt the system suspend: [ 932.510475] usb 1-7: usb suspend, wakeup 0 [ 932.510549] hub 1-0:1.0: hub_suspend [ 932.510581] usb usb1: bus suspend, wakeup 0 [ 932.510590] xhci_hcd 0000:00:14.0: port 9 not suspended [ 932.510593] xhci_hcd 0000:00:14.0: port 8 not suspended .. [ 932.520323] xhci_hcd 0000:00:14.0: Port change event, 1-7, id 7, portsc: 0x400e03 .. [ 932.591405] PM: pci_pm_suspend(): hcd_pci_suspend+0x0/0x30 returns -16 [ 932.591414] PM: dpm_run_callback(): pci_pm_suspend+0x0/0x160 returns -16 [ 932.591418] PM: Device 0000:00:14.0 failed to suspend async: error -16 During system suspend, USB core will let HC suspends the device if it doesn't have remote wakeup enabled and doesn't have any children. However, from the log above we can see that the usb 1-7 doesn't get bus suspended due to not in U0. After a while the port finished U2 -> U0 transition, interrupts the suspend process. The observation is that after disabling LPM, port doesn't transit to U0 immediately and can linger in U2. xHCI spec 4.23.5.2 states that the maximum exit latency for USB2 LPM should be BESL + 10us. The BESL for the affected device is advertised as 400us, which is still not enough based on my testing result. So let's use the maximum permitted latency, 10000, to poll for U0 status to solve the issue. Cc: stable@vger.kernel.org Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200624135949.22611-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-24xhci: Return if xHCI doesn't support LPMKai-Heng Feng
Just return if xHCI is quirked to disable LPM. We can save some time from reading registers and doing spinlocks. Add stable tag as we want this patch together with the next one, "Poll for U0 after disabling USB2 LPM" which fixes a suspend issue for some USB2 LPM devices Cc: stable@vger.kernel.org Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200624135949.22611-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-24xhci: Fix enumeration issue when setting max packet size for FS devices.Al Cooper
Unable to complete the enumeration of a USB TV Tuner device. Per XHCI spec (4.6.5), the EP state field of the input context shall be cleared for a set address command. In the special case of an FS device that has "MaxPacketSize0 = 8", the Linux XHCI driver does not do this before evaluating the context. With an XHCI controller that checks the EP state field for parameter context error this causes a problem in cases such as the device getting reset again after enumeration. When that field is cleared, the problem does not occur. This was found and fixed by Sasi Kumar. Cc: stable@vger.kernel.org Signed-off-by: Al Cooper <alcooperx@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200624135949.22611-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-21xhci: Fix handling halted endpoint even if endpoint ring appears emptyMathias Nyman
If a class driver cancels its only URB then the endpoint ring buffer will appear empty to the xhci driver. xHC hardware may still process cached TRBs, and complete with a STALL, halting the endpoint. This halted endpoint was not handled correctly by xhci driver as events on empty rings were all assumed to be spurious events. xhci driver refused to restart the ring with EP_HALTED flag set, so class driver was never informed the endpoint halted even if it queued new URBs. The host side of the endpoint needs to be reset, and dequeue pointer should be moved in order to clear the cached TRBs and resetart the endpoint. Small adjustments in finding the new dequeue pointer are needed to support the case of stall on an empty ring and unknown current TD. Cc: <stable@vger.kernel.org> cc: Jeremy Compostella <jeremy.compostella@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200421140822.28233-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-12xhci: bail out early if driver can't accress host in resumeMathias Nyman
Bail out early if the xHC host needs to be reset at resume but driver can't access xHC PCI registers. If xhci driver already fails to reset the controller then there is no point in attempting to free, re-initialize, re-allocate and re-start the host. If failure to access the host is detected later, failing the resume, xhci interrupts will be double freed when remove is called. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200312144517.1593-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-11xhci: Increase STS_HALT timeout in xhci_suspend()Kai-Heng Feng
I've recently observed failed xHCI suspend attempt on AMD Raven Ridge system: kernel: xhci_hcd 0000:04:00.4: WARN: xHC CMD_RUN timeout kernel: PM: suspend_common(): xhci_pci_suspend+0x0/0xd0 returns -110 kernel: PM: pci_pm_suspend(): hcd_pci_suspend+0x0/0x30 returns -110 kernel: PM: dpm_run_callback(): pci_pm_suspend+0x0/0x150 returns -110 kernel: PM: Device 0000:04:00.4 failed to suspend async: error -110 Similar to commit ac343366846a ("xhci: Increase STS_SAVE timeout in xhci_suspend()") we also need to increase the HALT timeout to make it be able to suspend again. Cc: <stable@vger.kernel.org> # 5.2+ Fixes: f7fac17ca925 ("xhci: Convert xhci_handshake() to use readl_poll_timeout_atomic()") Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20191211142007.8847-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-11usb: xhci: only set D3hot for pci deviceHenry Lin
Xhci driver cannot call pci_set_power_state() on non-pci xhci host controllers. For example, NVIDIA Tegra XHCI host controller which acts as platform device with XHCI_SPURIOUS_WAKEUP quirk set in some platform hits this issue during shutdown. Cc: <stable@vger.kernel.org> Fixes: 638298dc66ea ("xhci: Fix spurious wakeups after S5 on Haswell") Signed-off-by: Henry Lin <henryl@nvidia.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20191211142007.8847-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-16usb: host: xhci: Support running urb giveback in tasklet contextSuwan Kim
Patch "USB: HCD: support giveback of URB in tasklet context"[1] introduced giveback of urb in tasklet context. [1] This patch was applied to ehci but not xhci. [2] This patch significantly reduces the hard irq time of xhci. Especially for uvc driver, the hard irq including the uvc completion function runs quite long but applying this patch reduces the hard irq time of xhci. I have tested four SS devices to check if performance degradation occurs when urb completion functions run in the tasklet context. As a result of the test, all devices works well and shows very similar performance with the upstream kernel. Moreover, usb ethernet adapter show better performance than the upstream kernel about 5% for RX and 2% for TX. Four SS devices is as follows. SS devices for test 1. WD My Passport 2TB (external hard drive) 2. Sandisk Ultra Flair USB 3.0 32GB 3. Logitech Brio webcam 4. Iptime 1gigabit ethernet adapter (Mediatek RTL8153) Test description 1. Mass storage (hard drive) performance test - run below command 10 times and compute the average performance dd if=/dev/sdN iflag=direct of=/dev/null bs=1G count=1 2. Mass storage (flash memory) performance test - run below command 10 times and compute the average performance dd if=/dev/sdN iflag=direct of=/dev/null bs=1G count=1 3. Webcam streaming performance test - run simple capture program and get the average frame rate per second - capture 1500 frames - program link https://github.com/asfaca/Webcam-performance-analyzing-tool - video resolution : 4096 X 2160 (4K) at 30 or 24 fps - device (Logitech Brio) spec url for the highest resolution and fps https://support.logitech.com/en_gb/product/brio-stream/specs 4. USB Ethernet adapter performance test - directly connect two linux machines with ethernet cable - run pktgen of linux kernel and send 1500 bytes packets - run vnstat to measure the network bandwidth for 180 seconds Test machine - CPU : Intel i5-7600 @ 3.5GHz Test results 1. Mass storage (hard drive) performance test WD My Passport 2TB (external hard drive) -------------------------------------------------------------------- xhci without tasklet | xhci with tasklet -------------------------------------------------------------------- 103.667MB/s | 103.692MB/s -------------------------------------------------------------------- 2. Mass storage (flash memory) performance test Sandisk Ultra Flair USB 3.0 32GB -------------------------------------------------------------------- xhci without tasklet | xhci with tasklet -------------------------------------------------------------------- 129.727MB/s | 130.2MB/s -------------------------------------------------------------------- 3. Webcam streaming performance test Logitech Brio webcam -------------------------------------------------------------------- xhci without tasklet | xhci with tasklet -------------------------------------------------------------------- 26.4451 fps | 26.3949 fps -------------------------------------------------------------------- 4. USB Ethernet adapter performance test Iptime 1gigabit ethernet adapter (Mediatek RTL8153) -------------------------------------------------------------------- xhci without tasklet | xhci with tasklet -------------------------------------------------------------------- RX 933.86 Mbit/s | 983.86 Mbit/s -------------------------------------------------------------------- TX 830.18 Mbit/s | 882.75 Mbit/s -------------------------------------------------------------------- [1], https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=94dfd7edfd5c9b605caf7b562de7a813d216e011 [2], https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=428aac8a81058e2303677a8fbf26670229e51d3a Signed-off-by: Suwan Kim <suwan.kim027@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/1573836603-10871-4-git-send-email-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-28xhci: Fix use-after-free regression in xhci clear hub TT implementationMathias Nyman
commit ef513be0a905 ("usb: xhci: Add Clear_TT_Buffer") schedules work to clear TT buffer, but causes a use-after-free regression at the same time Make sure hub_tt_work finishes before endpoint is disabled, otherwise the work will dereference already freed endpoint and device related pointers. This was triggered when usb core failed to read the configuration descriptor of a FS/LS device during enumeration. xhci driver queued clear_tt_work while usb core freed and reallocated a new device for the next enumeration attempt. EHCI driver implents ehci_endpoint_disable() that makes sure clear_tt_work has finished before it returns, but xhci lacks this support. usb core will call hcd->driver->endpoint_disable() callback before disabling endpoints, so we want this in xhci as well. The added xhci_endpoint_disable() is based on ehci_endpoint_disable() Fixes: ef513be0a905 ("usb: xhci: Add Clear_TT_Buffer") Cc: <stable@vger.kernel.org> # v5.3 Reported-by: Johan Hovold <johan@kernel.org> Suggested-by: Johan Hovold <johan@kernel.org> Reviewed-by: Johan Hovold <johan@kernel.org> Tested-by: Johan Hovold <johan@kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/1572013829-14044-2-git-send-email-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-04xhci: Fix NULL pointer dereference in xhci_clear_tt_buffer_complete()Mathias Nyman
udev stored in ep->hcpriv might be NULL if tt buffer is cleared due to a halted control endpoint during device enumeration xhci_clear_tt_buffer_complete is called by hub_tt_work() once it's scheduled, and by then usb core might have freed and allocated a new udev for the next enumeration attempt. Fixes: ef513be0a905 ("usb: xhci: Add Clear_TT_Buffer") Cc: <stable@vger.kernel.org> # v5.3 Reported-by: Johan Hovold <johan@kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/1570190373-30684-9-git-send-email-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-04xhci: Increase STS_SAVE timeout in xhci_suspend()Kai-Heng Feng
After commit f7fac17ca925 ("xhci: Convert xhci_handshake() to use readl_poll_timeout_atomic()"), ASMedia xHCI may fail to suspend. Although the algorithms are essentially the same, the old max timeout is (usec + usec * time of doing readl()), and the new max timeout is just usec, which is much less than the old one. Increase the timeout to make ASMedia xHCI able to suspend again. BugLink: https://bugs.launchpad.net/bugs/1844021 Fixes: f7fac17ca925 ("xhci: Convert xhci_handshake() to use readl_poll_timeout_atomic()") Cc: <stable@vger.kernel.org> # v5.2+ Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/1570190373-30684-8-git-send-email-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-04xhci: Prevent deadlock when xhci adapter breaks during initBill Kuzeja
The system can hit a deadlock if an xhci adapter breaks while initializing. The deadlock is between two threads: thread 1 is tearing down the adapter and is stuck in usb_unlocked_disable_lpm waiting to lock the hcd->handwidth_mutex. Thread 2 is holding this mutex (while still trying to add a usb device), but is stuck in xhci_endpoint_reset waiting for a stop or config command to complete. A reboot is required to resolve. It turns out when calling xhci_queue_stop_endpoint and xhci_queue_configure_endpoint in xhci_endpoint_reset, the return code is not checked for errors. If the timing is right and the adapter dies just before either of these commands get issued, we hang indefinitely waiting for a completion on a command that didn't get issued. This wasn't a problem before the following fix because we didn't send commands in xhci_endpoint_reset: commit f5249461b504 ("xhci: Clear the host side toggle manually when endpoint is soft reset") With the patch I am submitting, a duration test which breaks adapters during initialization (and which deadlocks with the standard kernel) runs without issue. Fixes: f5249461b504 ("xhci: Clear the host side toggle manually when endpoint is soft reset") Cc: <stable@vger.kernel.org> # v4.17+ Cc: Torez Smith <torez@redhat.com> Signed-off-by: Bill Kuzeja <william.kuzeja@stratus.com> Signed-off-by: Torez Smith <torez@redhat.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/1570190373-30684-7-git-send-email-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-04usb: xhci: wait for CNR controller not ready bit in xhci resumeRick Tseng
NVIDIA 3.1 xHCI card would lose power when moving power state into D3Cold. Thus we need to wait for CNR bit to clear in xhci resume, just as in xhci init. [Minor changes to comment and commit message -Mathias] Cc: <stable@vger.kernel.org> Signed-off-by: Rick Tseng <rtseng@nvidia.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/1570190373-30684-6-git-send-email-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-04xhci: Fix USB 3.1 capability detection on early xHCI 1.1 spec based hostsMathias Nyman
Early xHCI 1.1 spec did not mention USB 3.1 capable hosts should set sbrn to 0x31, or that the minor revision is a two digit BCD containing minor and sub-minor numbers. This was later clarified in xHCI 1.2. Some USB 3.1 capable hosts therefore have sbrn set to 0x30, or minor revision set to 0x1 instead of 0x10. Detect the USB 3.1 capability correctly for these hosts as well Fixes: ddd57980a0fd ("xhci: detect USB 3.2 capable host controllers correctly") Cc: <stable@vger.kernel.org> # v4.18+ Cc: Loïc Yhuel <loic.yhuel@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/1570190373-30684-5-git-send-email-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-04xhci: Check all endpoints for LPM timeoutJan Schmidt
If an endpoint is encountered that returns USB3_LPM_DEVICE_INITIATED, keep checking further endpoints, as there might be periodic endpoints later that return USB3_LPM_DISABLED due to shorter service intervals. Without this, the code can set too high a maximum-exit-latency and prevent the use of multiple USB3 cameras that should be able to work. Cc: <stable@vger.kernel.org> Signed-off-by: Jan Schmidt <jan@centricular.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/1570190373-30684-4-git-send-email-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-04xhci: Prevent device initiated U1/U2 link pm if exit latency is too longMathias Nyman
If host/hub initiated link pm is prevented by a driver flag we still must ensure that periodic endpoints have longer service intervals than link pm exit latency before allowing device initiated link pm. Fix this by continue walking and checking endpoint service interval if xhci_get_timeout_no_hub_lpm() returns anything else than USB3_LPM_DISABLED While at it fix the split line error message Tested-by: Jan Schmidt <jan@centricular.com> Cc: <stable@vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/1570190373-30684-3-git-send-email-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-03xhci: fix possible memleak on setup address fails.Ikjoon Jang
Xhci re-enables a slot on transaction error in set_address using xhci_disable_slot() + xhci_alloc_dev(). But in this case, xhci_alloc_dev() creates debugfs entries upon an existing device without cleaning up old entries, thus memory leaks. So this patch simply moves calling xhci_debugfs_free_dev() from xhci_free_dev() to xhci_disable_slot(). [added "possible" to header as this is about failure codepath -Mathias] Signed-off-by: Ikjoon Jang <ikjn@chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/1567172356-12915-5-git-send-email-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-21usb: add a HCD_DMA flag instead of guestimating DMA capabilitiesChristoph Hellwig
The usb core is the only major place in the kernel that checks for a non-NULL device dma_mask to see if a device is DMA capable. This is generally a bad idea, as all major busses always set up a DMA mask, even if the device is not DMA capable - in fact bus layers like PCI can't even know if a device is DMA capable at enumeration time. This leads to lots of workaround in HCD drivers, and also prevented us from setting up a DMA mask for platform devices by default last time we tried. Replace this guess with an explicit HCD_DMA that is set by drivers that appear to have DMA support. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20190816062435.881-4-hch@lst.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-02xhci: Fix NULL pointer dereference at endpoint zero reset.Mathias Nyman
Usb core will reset the default control endpoint "ep0" before resetting a device. if the endpoint has a valid pointer back to the usb device then the xhci driver reset callback will try to clear the toggle for the endpoint. ep0 didn't use to have this pointer set as ep0 was always allocated by default together with a xhci slot for the usb device. Other endpoints got their usb device pointer set in xhci_add_endpoint() This changed with commit ef513be0a905 ("usb: xhci: Add Clear_TT_Buffer") which sets the pointer for any endpoint on a FS/LS device behind a HS hub that halts, including ep0. If xHC controller needs to be reset at resume, then all the xhci slots will be lost. Slots will be reenabled and reallocated at device reset, but unlike other endpoints the ep0 is reset before device reset, while the xhci slot may still be invalid, causing NULL pointer dereference. Fix it by checking that the endpoint has both a usb device pointer and valid xhci slot before trying to clear the toggle. This issue was not seen earlier as ep0 didn't use to have a valid usb device pointer, and other endpoints were only reset after device reset when xhci slots were properly reenabled. Reported-by: Bob Gleitsmann <rjgleits@bellsouth.net> Reported-by: Enric Balletbo Serra <eballetbo@gmail.com> Fixes: ef513be0a905 ("usb: xhci: Add Clear_TT_Buffer") Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/1564758044-24748-1-git-send-email-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-23Merge 5.2-rc6 into usb-nextGreg Kroah-Hartman
We need the USB fixes in here too. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-18xhci: detect USB 3.2 capable host controllers correctlyMathias Nyman
USB 3.2 capability in a host can be detected from the xHCI Supported Protocol Capability major and minor revision fields. If major is 0x3 and minor 0x20 then the host is USB 3.2 capable. For USB 3.2 capable hosts set the root hub lane count to 2. The Major Revision and Minor Revision fields contain a BCD version number. The value of the Major Revision field is JJh and the value of the Minor Revision field is MNh for version JJ.M.N, where JJ = major revision number, M - minor version number, N = sub-minor version number, e.g. version 3.1 is represented with a value of 0310h. Also fix the extra whitespace printed out when announcing regular SuperSpeed hosts. Cc: <stable@vger.kernel.org> # v4.18+ Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-18usb: xhci: Don't try to recover an endpoint if port is in error state.Mathias Nyman
A USB3 device needs to be reset and re-enumarated if the port it connects to goes to a error state, with link state inactive. There is no use in trying to recover failed transactions by resetting endpoints at this stage. Tests show that in rare cases, after multiple endpoint resets of a roothub port the whole host controller might stop completely. Several retries to recover from transaction error can happen as it can take a long time before the hub thread discovers the USB3 port error and inactive link. We can't reliably detect the port error from slot or endpoint context due to a limitation in xhci, see xhci specs section 4.8.3: "There are several cases where the EP State field in the Output Endpoint Context may not reflect the current state of an endpoint" and "Software should maintain an accurate value for EP State, by tracking it with an internal variable that is driven by Events and Doorbell accesses" Same appears to be true for slot state. set a flag to the corresponding slot if a USB3 roothub port link goes inactive to prevent both queueing new URBs and resetting endpoints. Reported-by: Rapolu Chiranjeevi <chiranjeevi.rapolu@intel.com> Tested-by: Rapolu Chiranjeevi <chiranjeevi.rapolu@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-05usb: xhci: Add Clear_TT_BufferJim Lin
USB 2.0 specification chapter 11.17.5 says "as part of endpoint halt processing for full-/low-speed endpoints connected via a TT, the host software must use the Clear_TT_Buffer request to the TT to ensure that the buffer is not in the busy state". In our case, a full-speed speaker (ConferenceCam) is behind a high- speed hub (ConferenceCam Connect), sometimes once we get STALL on a request we may continue to get STALL with the folllowing requests, like Set_Interface. Here we invoke usb_hub_clear_tt_buffer() to send Clear_TT_Buffer request to the hub of the device for the following Set_Interface requests to the device to get ACK successfully. Signed-off-by: Jim Lin <jilin@nvidia.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-05usb: Add devaddr in struct usb_deviceJim Lin
The Clear_TT_Buffer request sent to the hub includes the address of the LS/FS child device in wValue field. usb_hub_clear_tt_buffer() uses udev->devnum to set the address wValue. This won't work for devices connected to xHC. For other host controllers udev->devnum is the same as the address of the usb device, chosen and set by usb core. With xHC the controller hardware assigns the address, and won't be the same as devnum. Here we add devaddr in "struct usb_device" for usb_hub_clear_tt_buffer() to use. Signed-off-by: Jim Lin <jilin@nvidia.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-22xhci: Convert xhci_handshake() to use readl_poll_timeout_atomic()Andrey Smirnov
Xhci_handshake() implements the algorithm already captured by readl_poll_timeout_atomic(). Convert the former to use the latter to avoid repetition. Turned out this patch also fixes a bug on the AMD Stoneyridge platform where usleep(1) sometimes takes over 10ms. This means a 5 second timeout can easily take over 15 seconds which will trigger the watchdog and reboot the system. [Add info about patch fixing a bug to commit message -Mathias] Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Tested-by: Raul E Rangel <rrangel@chromium.org> Reviewed-by: Raul E Rangel <rrangel@chromium.org> Cc: <stable@vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit (git 2.34.1) at 2025-07-18 01:22:49 +0000