summaryrefslogtreecommitdiffstats
path: root/drivers/usb/host/xhci.h
Commit message (Collapse)AuthorAgeFilesLines
* Merge 4.1-rc7 into usb-nextGreg Kroah-Hartman2015-06-081-0/+2
|\ | | | | | | | | | | | | This resolves a merge issue in musb_core.c and we want the fixes that were in Linus's tree in this branch as well for testing. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: host: xhci: add mutex for non-thread-safe dataChris Bainbridge2015-05-241-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Regression in commit 638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel") The regression resulted in intermittent failure to initialise a 10-port hub (with three internal VL812 4-port hub controllers) on boot, with a failure rate of around 8%, due to multiple race conditions when accessing addr_dev and slot_id in struct xhci_hcd. This regression also exposed a problem with xhci_setup_device, which "should be protected by the usb_address0_mutex" but no longer is due to commit 6fecd4f2a58c ("USB: separate usb_address0 mutexes for each bus") With separate buses (and locks) it is no longer the case that a single lock will protect xhci_setup_device from accesses by two parallel threads processing events on the two buses. Fix this by adding a mutex to protect addr_dev and slot_id in struct xhci_hcd, and by making the assignment of slot_id atomic. Fixes multiple boot errors: [ 0.583008] xhci_hcd 0000:00:14.0: Bad Slot ID 2 [ 0.583009] xhci_hcd 0000:00:14.0: Could not allocate xHCI USB device data structures [ 0.583012] usb usb1-port3: couldn't allocate usb_device And: [ 0.637409] xhci_hcd 0000:00:14.0: Error while assigning device slot ID [ 0.637417] xhci_hcd 0000:00:14.0: Max number of devices this xHCI host supports is 32. [ 0.637421] usb usb1-port1: couldn't allocate usb_device And: [ 0.753372] xhci_hcd 0000:00:14.0: ERROR: unexpected setup context command completion code 0x0. [ 0.753373] usb 1-3: hub failed to enable device, error -22 [ 0.753400] xhci_hcd 0000:00:14.0: Error while assigning device slot ID [ 0.753402] xhci_hcd 0000:00:14.0: Max number of devices this xHCI host supports is 32. [ 0.753403] usb usb1-port3: couldn't allocate usb_device And: [ 11.018386] usb 1-3: device descriptor read/all, error -110 And: [ 5.753838] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command Tested with 200 reboots, resulting in no USB hub init related errors. Fixes: 638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel") Link: https://lkml.kernel.org/g/CAP-bSRb=A0iEYobdGCLpwynS7pkxpt_9ZnwyZTPVAoy0Y=Zo3Q@mail.gmail.com Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com> Cc: <stable@vger.kernel.org> # 3.18+ [changed git commit description style for checkpatch -Mathias] Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | usb: xhci: cleanup xhci_hcd allocationRoger Quadros2015-05-311-2/+17
|/ | | | | | | | | | | | | | | HCD core allocates memory for HCD private data in usb_create_[shared_]hcd() so make use of that mechanism to allocate the struct xhci_hcd. Introduce struct xhci_driver_overrides to provide the size of HCD private data and hc_driver operation overrides. As of now we only need to override the reset and start methods. Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Solve full event ring by increasing TRBS_PER_SEGMENT to 256Mathias Nyman2015-05-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our event ring consists of only one segment, and we risk filling the event ring in case we get isoc transfers with short intervals such as webcams that fill a TD every microframe (125us) With 64 TRB segment size one usb camera could fill the event ring in 8ms. A setup with several cameras and other devices can fill up the event ring as it is shared between all devices. This has occurred when uvcvideo queues 5 * 32TD URBs which then get cancelled when the video mode changes. The cancelled URBs are returned in the xhci interrupt context and blocks the interrupt handler from handling the new events. A full event ring will block xhci from scheduling traffic and affect all devices conneted to the xhci, will see errors such as Missed Service Intervals for isoc devices, and and Split transaction errors for LS/FS interrupt devices. Increasing the TRB_PER_SEGMENT will also increase the default endpoint ring size, which is welcome as for most isoc transfer we had to dynamically expand the endpoint ring anyway to be able to queue the 5 * 32TDs uvcvideo queues. The default size used to be 64 TRBs per segment Cc: <stable@vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Revert "xhci: Clear the host side toggle manually when endpoint is 'soft reset'"Mathias Nyman2015-03-111-2/+0Star
| | | | | | | | | | | | | | | This reverts commit 27082e2654dc ("xhci: Clear the host side toggle manually") Turns out this fix to enable soft resetting endpoints wasn't mature enough. It caused regression with some usb DVB-T devices and needs some more tuning to get the endpiont ring pointers set correctly. The original commit was tagged for stable 3.18, and should be reverted from there as well. Cc: stable <stable@vger.kernel.org> # v3.18 Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Workaround for PME stuck issues in Intel xhciMathias Nyman2015-03-061-0/+1
| | | | | | | | | | | | | | | | The xhci in Intel Sunrisepoint and Cherryview platforms need a driver workaround for a Stuck PME that might either block PME events in suspend, or create spurious PME events preventing runtime suspend. Workaround is to clear a internal PME flag, BIT(28) in a vendor specific PMCTRL register at offset 0x80a4, in both suspend resume callbacks Without this, xhci connected usb devices might never be able to wake up the system from suspend, or prevent device from going to suspend (xhci d3) Cc: <stable@vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: fix reporting of 0-sized URBs in control endpointAleksander Morgado2015-03-061-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | When a control transfer has a short data stage, the xHCI controller generates two transfer events: a COMP_SHORT_TX event that specifies the untransferred amount, and a COMP_SUCCESS event. But when the data stage is not short, only the COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb->actual_length to urb->transfer_buffer_length while processing the COMP_SUCCESS event, unless urb->actual_length was set already by a previous COMP_SHORT_TX event. The driver checks this by seeing whether urb->actual_length == 0, but this alone is the wrong test, as it is entirely possible for a short transfer to have an urb->actual_length = 0. This patch changes the xhci driver to rely on a new td->urb_length_set flag, which is set to true when a COMP_SHORT_TX event is received and the URB length updated at that stage. This fixes a bug which affected the HSO plugin, which relies on URBs with urb->actual_length == 0 to halt re-submitting the RX URB in the control endpoint. Cc: <stable@vger.kernel.org> Signed-off-by: Aleksander Morgado <aleksander@aleksander.es> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Clear the host side toggle manually when endpoint is 'soft reset'Mathias Nyman2015-02-241-0/+2
| | | | | | | | | | | | | | | Main benefit of this is to get xhci connected USB scanners to work. Some devices use a clear endpoint halt request as a 'soft reset' even if the endpoint is not halted. This will clear the toggle and sequence on the device side. xHCI however refuses to reset a non-halted endpoint, so instead we need to issue a configure endpoint command on xHCI to clear its host side toggle and sequence, and get it in sync with the device side. Tested-by: Mike Mammarella <mikem@crystalorb.net> Cc: <stable@vger.kernel.org> # v3.18 Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Allocate correct amount of scratchpad buffersMathias Nyman2015-02-241-2/+3
| | | | | | | | | | | | | | | | | Include the high order bit fields for Max scratchpad buffers when calculating how many scratchpad buffers are needed. I'm suprised this hasn't caused more issues, we never allocated more than 32 buffers even if xhci needed more. Either we got lucky and xhci never really used past that area, or then we got enough zeroed dma memory anyway. Should be backported as far back as possible Reported-by: Tim Chen <tim.c.chen@linux.intel.com> Tested-by: Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Print hcc params, version and quirks on initHans de Goede2015-01-251-0/+2
| | | | | | | | To help debugging xhci problems. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: clean up work to remove unused parameters for functions in xhci-mem.cLin Wang2015-01-091-4/+3Star
| | | | | | | | | | | | Some parameters are not used by functions in xhci-mem.c, just remove it. Changes compared to v1: - Rebase to the latest usb-next branch Signed-off-by: Lin Wang <lin.x.wang@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: remove unused parameter 'xhci' in function xhci_handshake().Lin Wang2015-01-091-2/+1Star
| | | | | | | | | Parameter 'xhci' is no longer be used in function xhci_handshake(), just remove it. Signed-off-by: Lin Wang <lin.x.wang@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: xhci: fix comment for PORT_DEV_REMOVELu Baolu2014-12-031-1/+1
| | | | | | | | | | According to xHCI specification, PORT_DEV_REMOVE(bit 30) in PORTSC true means "Device is non-removable". Reported-by: Juro Bystricky <jurobystricky@hotmail.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: don't use the same variable for stopped and halted rings current TDMathias Nyman2014-12-031-1/+1
| | | | | | | | | | | | | Endpoints halted on errors, and endpoints stopped manually both used the same ep->stopped_td to store the halted or stopped td. this causes confusion and possible races. There is no longer a need to use the ep->stopped_td variable to store the halted TD. A halted endpoint is handled immediately and we can pass it to the handling function directly. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: xhci: rework root port wake bits if controller isn't allowed to wakeupLu Baolu2014-11-221-1/+1
| | | | | | | | | | | | | | | | | | When system is being suspended, if host device is not allowed to do wakeup, xhci_suspend() needs to clear all root port wake on bits. Otherwise, some platforms may generate spurious wakeup, even if PCI PME# is disabled. The initial commit ff8cbf250b44 ("xhci: clear root port wake on bits"), which also got into stable, turned out to not work correctly and had to be reverted, and is now rewritten. Cc: stable <stable@vger.kernel.org> # v3.2+ Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> [Mathias Nyman: reword commit message] Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Allow xHCI drivers to be built as separate modulesAndrew Bresticker2014-10-031-19/+0Star
| | | | | | | | | | | | Instead of building all of the xHCI code into a single module, separate it out into the core (xhci-hcd), PCI (xhci-pci, now selected by the new config option CONFIG_USB_XHCI_PCI), and platform (xhci-plat) drivers. Also update the PCI/platform drivers with module descriptions/licenses and have them register their respective drivers in their initcalls. Signed-off-by: Andrew Bresticker <abrestic@chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Check for XHCI_COMP_MODE_QUIRK when disabling D3coldAndrew Bresticker2014-10-031-3/+0Star
| | | | | | | | | | | Instead of calling xhci_compliance_mode_recovery_timer_quirk_check() again in the PCI suspend path, just check for XHCI_COMP_MODE_QUIRK which will have been set based on xhci_compliance_mode_recovery_timer_quirk_check() in xhci_init(). Signed-off-by: Andrew Bresticker <abrestic@chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Introduce xhci_init_driver()Andrew Bresticker2014-10-031-0/+1
| | | | | | | | | | | | | | | Since the struct hc_driver is mostly the same across the xhci-pci, xhci-plat, and the upcoming xhci-tegra driver, introduce the function xhci_init_driver() which will populate the hc_driver with the default xHCI operations. The caller must supply a setup function which will be used as the hc_driver's reset callback. Note that xhci-plat also overrides the default ->start() callback so that it can do rcar-specific initialization. Signed-off-by: Andrew Bresticker <abrestic@chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Log extra info on "ERROR Transfer event TRB DMA ptr not part of ↵Hans de Goede2014-09-241-3/+3
| | | | | | | | | | | | | current TD" Lately (with the use of uas / bulk-streams) we have been seeing several cases where this error triggers (which should never happen). Add some extra logging to make debugging these errors easier. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Move allocating of command for new_dequeue_state to queue_set_tr_deq()Hans de Goede2014-09-241-1/+0Star
| | | | | | | | | | | | | | | | | | There are multiple reasons for this: 1) This fixes a missing check for xhci_alloc_command failing in xhci_handle_cmd_stop_ep() 2) This adds a warning when we cannot set the new dequeue state because of xhci_alloc_command failing 3) It puts the allocation of the command after the sanity checks in queue_set_tr_deq(), avoiding leaking the command if those fail 4) Since queue_set_tr_deq now owns the command it can free it if queue_command fails 5) It reduces code duplication Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Blacklist using streams on the Etron EJ168 controllerHans de Goede2014-08-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Streams on the EJ168 do not work as they should. I've spend 2 days trying to get them to work, but without success. The first problem is that when ever you ring the stream-ring doorbell, the controller starts executing trbs at the beginning of the first ring segment, event if it ended somewhere else previously. This can be worked around by allowing enqueing only one td (not a problem with how streams are typically used) and then resetting our copies of the enqueueing en dequeueing pointers on a td completion to match what the controller seems to be doing. This way things seem to start working with uas and instead of being able to complete only the very first scsi command, the scsi core can probe the disk. But then things break later on when td-s get enqueued with more then one trb. The controller does seem to increase its dequeue pointer while executing a stream-ring (data transfer events I inserted for debugging do trigger). However execution seems to stop at the final normal trb of a multi trb td, even if there is a data transfer event inserted after the final trb. The first problem alone is a serious deviation from the spec, and esp. dealing with cancellation would have been very tricky if not outright impossible, but the second problem simply is a deal breaker altogether, so this patch simply disables streams. Note this will cause the usb-storage + uas driver pair to automatically switch to using usb-storage instead of uas on these devices, essentially reverting to the 3.14 and earlier behavior when uas was marked CONFIG_BROKEN. https://bugzilla.redhat.com/show_bug.cgi?id=1121288 https://bugzilla.kernel.org/show_bug.cgi?id=80101 Cc: stable@vger.kernel.org # 3.15 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: host: xhci-plat: add clock supportGregory CLEMENT2014-05-281-0/+2
| | | | | | | | | | | | | | | | | | Some platforms (such as the Armada 38x ones) can gate the clock of their USB controller. This patch adds the support for one clock in xhci-plat, by enabling it during probe and disabling it on remove. To achieve this, it adds a 'struct clk *' member in xhci_hcd. While only used for now in xhci-plat, it might be used by other drivers in the future. Moreover, the xhci_hcd structure already holds other members such as msix_count and msix_entries, which are MSI-X specific, and therefore only used by xhci-pci. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Felipe Balbi <balbi@ti.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: rework command timeout and cancellation,Mathias Nyman2014-05-201-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use one timer to control command timeout. start/kick the timer every time a command is completed and a new command is waiting, or a new command is added to a empty list. If the timer runs out, then tag the current command as "aborted", and start the xhci command abortion process. Previously each function that submitted a command had its own timer. If that command timed out, a new command structure for the command was created and it was put on a cancel_cmd_list list, then a pci write to abort the command ring was issued. when the ring was aborted, it checked if the current command was the one to be canceled, later when the ring was stopped the driver got ownership of the TRBs in the command ring, compared then to the TRBs in the cancel_cmd_list, and turned them into No-ops. Now, instead, at timeout we tag the status of the command in the command queue to be aborted, and start the ring abortion. Ring abortion stops the command ring and gives control of the commands to us. All the aborted commands are now turned into No-ops. If the ring is already stopped when the command times outs its not possible to start the ring abortion, in this case the command is turnd to No-op right away. All these changes allows us to remove the entire cancel_cmd_list code. The functions waiting for a command to finish no longer have their own timeouts. They will wait either until the command completes normally, or until the whole command abortion is done. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Use completion and status in global command queueMathias Nyman2014-05-201-3/+0Star
| | | | | | | | | Remove the per-device command list and handle_cmd_in_cmd_wait_list() and use the completion and status variables found in the command structure in the global command list. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Add a global command queueMathias Nyman2014-05-201-0/+2
| | | | | | | | | | | | | | Create a list to store command structures, add a structure to it every time a command is submitted, and remove it from the list once we get a command completion event matching the command. Callers that wait for completion will free their command structures themselves. The other command structures are freed in the command completion event handler. Also add a check that prevents queuing commands if host is dying Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Use command structures when queuing commands on the command ringMathias Nyman2014-05-201-14/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To create a global command queue we require that each command put on the command ring is submitted with a command structure. Functions that queue commands and wait for completion need to allocate a command before submitting it, and free it once completed. The following command queuing functions need to be modified. xhci_configure_endpoint() xhci_address_device() xhci_queue_slot_control() xhci_queue_stop_endpoint() xhci_queue_new_dequeue_state() xhci_queue_reset_ep() xhci_configure_endpoint() xhci_configure_endpoint() could already be called with a command structure, and only xhci_check_maxpacket and xhci_check_bandwidth did not do so. These are changed and a command structure is now required. This change also simplifies the configure endpoint command completion handling and the "goto bandwidth_change" handling code can be removed. In some cases the command queuing function is called in interrupt context. These commands needs to be allocated atomically, and they can't wait for completion. These commands will in this patch be freed directly after queuing, but freeing will be moved to the command completion event handler in a later patch once we get the global command queue up.(Just so that we won't leak memory in the middle of the patch set) Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: xhci: Use IS_ENABLED() macroFabio Estevam2014-05-201-2/+1Star
| | | | | | | | Using the IS_ENABLED() macro can make the code shorter and easier to read. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: xhci: Prefer endpoint context dequeue pointer over stopped_trbJulius Werner2014-04-251-2/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have observed a rare cycle state desync bug after Set TR Dequeue Pointer commands on Intel LynxPoint xHCs (resulting in an endpoint that doesn't fetch new TRBs and thus an unresponsive USB device). It always triggers when a previous Set TR Dequeue Pointer command has set the pointer to the final Link TRB of a segment, and then another URB gets enqueued and cancelled again before it can be completed. Further investigation showed that the xHC had returned the Link TRB in the TRB Pointer field of the Transfer Event (CC == Stopped -- Length Invalid), but when xhci_find_new_dequeue_state() later accesses the Endpoint Context's TR Dequeue Pointer field it is set to the first TRB of the next segment. The driver expects those two values to be the same in this situation, and uses the cycle state of the latter together with the address of the former. This should be fine according to the XHCI specification, since the endpoint ring should be stopped when returning the Transfer Event and thus should not advance over the Link TRB before it gets restarted. However, real-world XHCI implementations apparently don't really care that much about these details, so the driver should follow a more defensive approach to try to work around HC spec violations. This patch removes the stopped_trb variable that had been used to store the TRB Pointer from the last Transfer Event of a stopped TRB. Instead, xhci_find_new_dequeue_state() now relies only on the Endpoint Context, requiring a small amount of additional processing to find the virtual address corresponding to the TR Dequeue Pointer. Some other parts of the function were slightly rearranged to better fit into this model. This patch should be backported to kernels as old as 2.6.31 that contain the commit ae636747146ea97efa18e04576acd3416e2514f5 "USB: xhci: URB cancellation support." Signed-off-by: Julius Werner <jwerner@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>
* xhci: For streams the dequeue ptr must be read from the stream ctxHans de Goede2014-03-051-0/+1
| | | | | | | | | | | | | | This fixes TR dequeue validation failing on Intel XHCI controllers with the following warning: Mismatch between completed Set TR Deq Ptr command & xHCI internal state. Interestingly enough reading the deq ptr from the ep ctx after a TR Deq Ptr command does work on a Nec XHCI controller, it seems the Nec writes the ptr to both the ep and stream contexts when streams are used. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* xhci: Set SCT field for Set TR dequeue on streamsHans de Goede2014-03-051-1/+2
| | | | | | | | | | | | | Nec XHCI controllers don't seem to care, but without this Intel XHCI controllers reject Set TR dequeue commands with a COMP_TRB_ERR, leading to the following warning: WARN Set TR Deq Ptr cmd invalid because of stream ID configuration And very shortly after this the system completely freezes. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* xhci: fix usb3 streamsGerd Hoffmann2014-03-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | xhci maintains a radix tree for each stream endpoint because it must be able to map a trb address to the stream ring. Each ring segment must be added to the ring for this to work. Currently xhci sticks only the first segment of each stream ring into the radix tree. Result is that things work initially, but as soon as the first segment is full xhci can't map the trb address from the completion event to the stream ring any more -> BOOM. You'll find this message in the logs: ERROR Transfer event for disabled endpoint or incorrect stream ring This patch adds a helper function to update the radix tree, and a function to remove ring segments from the tree. Both functions loop over the segment list and handles all segments instead of just the first. [Note: Sarah changed this patch to add radix_tree_maybe_preload() and radix_tree_preload_end() calls around the radix tree insert, since we can now insert entries in interrupt context. There are now two helper functions to make the code cleaner, and those functions are moved to make them static.] Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* Revert "xhci: Set scatter-gather limit to avoid failed block writes."Sarah Sharp2014-02-071-1/+1
| | | | | | | | | | | | | This reverts commit f2d9b991c549f159dc9ae81f77d8206c790cbfee. We are ripping out commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e "usb: xhci: Link TRB must not occur within a USB payload burst" because it's a hack that caused regressions in the usb-storage and userspace USB drivers that use usbfs and libusb. This commit attempted to fix the issues with that patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org #3.12
* Revert "xhci: replace xhci_read_64() with readq()"Sarah Sharp2014-01-301-2/+8
| | | | | | | | | This reverts commit e8b373326d8efcaf9ec1da8b618556c89bd5ffc4. Many xHCI host controllers can only handle 32-bit addresses, and writing 64-bits at a time causes them to fail. Reading 64-bits at a time may also cause them to return 0xffffffff, so revert this commit as well. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* Revert "xhci: replace xhci_write_64() with writeq()"Sarah Sharp2014-01-301-9/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 7dd09a1af2c7150269350aaa567a11b06e831003. Many xHCI host controllers can only handle 32-bit addresses, and writing 64-bits at a time causes them to fail. Rafał reports that USB devices simply do not enumerate, and reverting this patch helps. Branimir reports that his host controller doesn't respond to an Enable Slot command and dies: [ 75.576160] xhci_hcd 0000:03:00.0: Timeout while waiting for a slot [ 88.991634] xhci_hcd 0000:03:00.0: Stopped the command ring failed, maybe the host is dead [ 88.991748] xhci_hcd 0000:03:00.0: Abort command ring failed [ 88.991845] xhci_hcd 0000:03:00.0: HC died; cleaning up [ 93.985489] xhci_hcd 0000:03:00.0: Timeout while waiting for a slot [ 93.985494] xhci_hcd 0000:03:00.0: Abort the command ring, but the xHCI is dead. [ 98.982586] xhci_hcd 0000:03:00.0: Timeout while waiting for a slot [ 98.982591] xhci_hcd 0000:03:00.0: Abort the command ring, but the xHCI is dead. [ 103.979696] xhci_hcd 0000:03:00.0: Timeout while waiting for a slot [ 103.979702] xhci_hcd 0000:03:00.0: Abort the command ring, but the xHCI is dead Signed-off-by: Sarah Sharp <sarah.a.sharp@intel.com> Reported-by: Rafał Miłecki <zajec5@gmail.com> Reported-by: Branimir Maksimovic <branimir.maksimovic@gmail.com> Cc: Xenia Ragiadakou <burzalodowa@gmail.com>
* xhci: Set scatter-gather limit to avoid failed block writes.Sarah Sharp2014-01-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e "usb: xhci: Link TRB must not occur within a USB payload burst" attempted to fix an issue found with USB ethernet adapters, and inadvertently broke USB storage devices. The patch attempts to ensure that transfers never span a segment, and rejects transfers that have more than 63 entries (or possibly less, if some entries cross 64KB boundaries). usb-storage limits the maximum transfer size to 120K, and we had assumed the block layer would pass a scatter-gather list of 4K entries, resulting in no more than 31 sglist entries: http://marc.info/?l=linux-usb&m=138498190419312&w=2 That assumption was wrong, since we've seen the driver reject a write that was 218 sectors long (of probably 512 bytes each): Jan 1 07:04:49 jidanni5 kernel: [ 559.624704] xhci_hcd 0000:00:14.0: Too many fragments 79, max 63 ... Jan 1 07:04:58 jidanni5 kernel: [ 568.622583] Write(10): 2a 00 00 06 85 0e 00 00 da 00 Limit the number of scatter-gather entries to half a ring segment. That should be margin enough in case some entries cross 64KB boundaries. Increase the number of TRBs per segment from 64 to 256, which should result in ring segments fitting on a 4K page. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: jidanni@jidanni.org References: http://bugs.debian.org/733907 Fixes: 35773dac5f86 ('usb: xhci: Link TRB must not occur within a USB payload burst') Cc: stable <stable@vger.kernel.org> # 3.12
* usb: xhci: change enumeration scheme to 'new scheme' by defaultDan Williams2013-12-101-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change the default enumeration scheme for xhci attached non-SuperSpeed devices from: Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(8) GetDescriptor(18) ...to: Reset [xhci address-device BSR = 1] GetDescriptor(64) Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(18) ...as some devices misbehave when encountering a SetAddress command prior to GetDescriptor. There are known legacy devices that require this scheme, but testing has found at least one USB3 device that fails enumeration when presented with this ordering. For now, follow the ehci case and enable 'new scheme' by default for non-SuperSpeed devices. To support this enumeration scheme on xhci the AddressDevice operation needs to be performed twice. The first instance of the command enables the HC's device and slot context info for the device, but omits sending the device a SetAddress command (BSR == block set address request). Then, after GetDescriptor completes, follow up with the full AddressDevice+SetAddress operation. As mentioned before, this ordering of events with USB3 devices causes an extra state transition to be exposed to xhci. Previously USB3 devices would transition directly from 'enabled' to 'addressed' and never need to underrun responses to 'get descriptor'. We do see the 64-byte descriptor fetch the correct data, but the following 18-byte descriptor read after the reset gets: bLength = 0 bDescriptorType = 0 bcdUSB = 0 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 instead of: bLength = 12 bDescriptorType = 1 bcdUSB = 300 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 which results in the discovery process looping until falling back to 'old scheme' enumeration. Acked-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: David Moore <david.moore@gmail.com> Suggested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* xhci: replace xhci_write_64() with writeq()Xenia Ragiadakou2013-12-021-20/+9Star
| | | | | | | | | | | | | | | | | Function xhci_write_64() is used to write 64bit xHC registers residing in MMIO. On 32bit systems, xHC registers need to be written with 32bit accesses by writing first the lower 32bits and then the higher 32bits. The header file asm-generic/io-64-nonatomic-lo-hi.h ensures that on 32bit systems writeq() will will write 64bit registers in 32bit chunks with low-high order. Replace all calls to xhci_write_64() with calls to writeq(). This is done to reduce code duplication since 64bit low-high write logic is already implemented and to take advantage of inherent "atomic" 64bit write operations on 64bit systems. Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* xhci: replace xhci_read_64() with readq()Xenia Ragiadakou2013-12-021-8/+2Star
| | | | | | | | | | | | | | | | | Function xhci_read_64() is used to read 64bit xHC registers residing in MMIO. On 32bit systems, xHC registers need to be read with 32bit accesses by reading first the lower 32bits and then the higher 32bits. Replace all calls to xhci_read_64() with calls to readq() and include asm-generic/io-64-nonatomic-lo-hi.h header file, so that if the system is not 64bit, readq() will read registers in 32bit chunks with low-high order. This is done to reduce code duplication since 64bit low-high read logic is already implemented and to take advantage of inherent "atomic" 64bit read operations on 64bit systems. Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* xhci: replace xhci_writel() with writel()Xenia Ragiadakou2013-12-021-8/+0Star
| | | | | | | | | | | | | | Function xhci_writel() is used to write a 32bit value in xHC registers residing in MMIO address space. It takes as first argument a pointer to the xhci_hcd although it does not use it. xhci_writel() internally simply calls writel(). This creates an illusion that xhci_writel() is an xhci specific function that has to be called in a context where a pointer to xhci_hcd is available. Remove xhci_writel() wrapper function and replace its calls with calls to writel() to make the code more straight-forward. Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* xhci: replace xhci_readl() with readl()Xenia Ragiadakou2013-12-021-5/+0Star
| | | | | | | | | | | | | | Function xhci_readl() is used to read 32bit xHC registers residing in MMIO address space. It takes as first argument a pointer to the xhci_hcd although it does not use it. xhci_readl() internally simply calls readl(). This creates an illusion that xhci_readl() is an xhci specific function that has to be called in a context where a pointer to xhci_hcd is available. Remove the unnecessary xhci_readl() wrapper function and replace its calls to with calls to readl() to make the code more straightforward. Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* xhci: fix SCT_FOR_CTX(p) macroXenia Ragiadakou2013-12-021-1/+1
| | | | | | | | | | | | | SCT_FOR_CTX(p) is defined as (((p) << 1) & 0x7) in which case if we want to set the stream context type to SCT_SSA_256 i.e 0x7 (although secondary stream arrays are not yet supported) using this macro definition we will get actually 0x6 which is not what we want. This patch fixes the above issue by defining the SCT_FOR_CTX(p) macro as (((p) & 0x7) << 1) Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* Merge tag 'for-usb-next-2013-10-17' of ↵Greg Kroah-Hartman2013-10-191-2/+1Star
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-next Sarah writes: xhci: Final patches for 3.13 Hi Greg, Here's my pull request for usb-next and 3.13. My xHCI tree is closed after this point, since I won't be able to run my full tests while I'm in Scotland. After Kernel Summit, I'll be on vacation with access to email from Oct 26th to Nov 6th. Here's what's in this request: - Patches to fix USB 2.0 Link PM issues that cause USB 3.0 devices to not enumerate or misbehave when plugged into a USB 2.0 port. Those are marked for stable. - A msec vs jiffies bug fix by xiao jin, which results in fairly harmless behavior, and thus isn't marked for stable. - Xenia's patches to refactor the xHCI command handling code, which makes it much more readable and consistent. - Misc cleanup patches, one by Sachin Kamat and three from Dan Williams. Here's what's not in this request: - Dan's two patches to allow the xHCI host to use the "Windows" or "new" enumeration scheme. I did not have time to test those, and I want to run them with as many USB devices as I can get a hold of. That will have to wait for 3.14. - Xenia's patches to remove xhci_readl in favor of readl. I'll queue those for 3.14 after I test them. - The xHCI streams update, UAS fixes, and usbfs streams support. I'm not comfortable with changes and fixes to that patchset coming in this late. I would rather wait for 3.14 and be really sure the streams support is stable before we add new userspace API and remove CONFIG_BROKEN from the uas driver. - Julius' patch to clear the port reset bit on hub resume that came in a couple days ago. It looks harmless, but I would rather take the time to test and queue it for usb-linus and the stable trees once 3.13-rc1 is out. Sarah Sharp
| * usb: xhci: remove the unused ->address fieldDan Williams2013-10-171-2/+0Star
| | | | | | | | | | | | | | Only used for debug output, so we don't need to save it. Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
| * xhci: Set L1 device slot on USB2 LPM enable/disable.Sarah Sharp2013-10-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To enable USB 2.0 Link Power Management (LPM), the xHCI host controller needs the device slot ID to generate the device address used in L1 entry tokens. That information is set in the L1 device slot ID field of the USB 2.0 LPM registers. Currently, the L1 device slot ID is overwritten when the xHCI driver initiates the software test of USB 2.0 Link PM in xhci_usb2_software_lpm_test. It is never cleared when USB 2.0 Link PM is disabled for the device. That should be harmless, because the Hardware LPM Enable (HLE) bit is cleared when USB 2.0 Link PM is disabled, so the host should not pay attention to the slot ID. This patch should have no effect on host behavior, but since xhci_usb2_software_lpm_test is going away in an upcoming bug fix patch, we need to move that code to the function that enables and disables USB 2.0 Link PM. This patch should be backported to kernels as old as 3.11, that contain the commit a558ccdcc71c7770c5e80c926a31cfe8a3892a09 "usb: xhci: add USB2 Link power management BESL support". The upcoming bug fix patch is also marked for that stable kernel. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
* | xhci: Fix spurious wakeups after S5 on HaswellTakashi Iwai2013-10-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Haswell LynxPoint and LynxPoint-LP with the recent Intel BIOS show mysterious wakeups after shutdown occasionally. After discussing with BIOS engineers, they explained that the new BIOS expects that the wakeup sources are cleared and set to D3 for all wakeup devices when the system is going to sleep or power off, but the current xhci driver doesn't do this properly (partly intentionally). This patch introduces a new quirk, XHCI_SPURIOUS_WAKEUP, for fixing the spurious wakeups at S5 by calling xhci_reset() in the xhci shutdown ops as done in xhci_stop(), and setting the device to PCI D3 at shutdown and remove ops. The PCI D3 call is based on the initial fix patch by Oliver Neukum. [Note: Sarah changed the quirk name from XHCI_HSW_SPURIOUS_WAKEUP to XHCI_SPURIOUS_WAKEUP, since none of the other quirks have system names in them. Sarah also fixed a collision with a quirk submitted around the same time, by changing the xhci->quirks bit from 17 to 18.] This patch should be backported to kernels as old as 3.0, that contain the commit 1c12443ab8eba71a658fae4572147e56d1f84f66 "xhci: Add Lynx Point to list of Intel switchable hosts." Cc: Oliver Neukum <oneukum@suse.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
* | xhci: quirk for extra long delay for S4Oliver Neukum2013-10-101-0/+1
|/ | | | | | | | | | | | | | It has been reported that this chipset really cannot sleep without this extraordinary delay. This patch should be backported, in order to ensure this host functions under stable kernels. The last quirk for Fresco Logic hosts (commit bba18e33f25072ebf70fd8f7f0cdbf8cdb59a746 "xhci: Extend Fresco Logic MSI quirk.") was backported to stable kernels as old as 2.6.36. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
* usb: Fix xHCI host issues on remote wakeup.Sarah Sharp2013-09-241-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a device signals remote wakeup on a roothub, and the suspend change bit is set, the host controller driver must not give control back to the USB core until the port goes back into the active state. EHCI accomplishes this by waiting in the get port status function until the PORT_RESUME bit is cleared: /* stop resume signaling */ temp &= ~(PORT_RWC_BITS | PORT_SUSPEND | PORT_RESUME); ehci_writel(ehci, temp, status_reg); clear_bit(wIndex, &ehci->resuming_ports); retval = ehci_handshake(ehci, status_reg, PORT_RESUME, 0, 2000 /* 2msec */); Similarly, the xHCI host should wait until the port goes into U0, before passing control up to the USB core. When the port transitions from the RExit state to U0, the xHCI driver will get a port status change event. We need to wait for that event before passing control up to the USB core. After the port transitions to the active state, the USB core should time a recovery interval before it talks to the device. The length of that recovery interval is TRSMRCY, 10 ms, mentioned in the USB 2.0 spec, section 7.1.7.7. The previous xHCI code (which did not wait for the port to go into U0) would cause the USB core to violate that recovery interval. This bug caused numerous USB device disconnects on remote wakeup under ChromeOS and a Lynx Point LP xHCI host that takes up to 20 ms to move from RExit to U0. ChromeOS is very aggressive about power savings, and sets the autosuspend_delay to 100 ms, and disables USB persist. I attempted to replicate this bug with Ubuntu 12.04, but could not. I used Ubuntu 12.04 on the same platform, with the same BIOS that the bug was triggered on ChromeOS with. I also changed the USB sysfs settings as described above, but still could not reproduce the bug under Ubuntu. It may be that ChromeOS userspace triggers this bug through additional settings. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* xhci: Ensure a command structure points to the correct trb on the command ringMathias Nyman2013-09-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If a command on the command ring needs to be cancelled before it is handled it can be turned to a no-op operation when the ring is stopped. We want to store the command ring enqueue pointer in the command structure when the command in enqueued for the cancellation case. Some commands used to store the command ring dequeue pointers instead of enqueue (these often worked because enqueue happends to equal dequeue quite often) Other commands correctly used the enqueue pointer but did not check if it pointed to a valid trb or a link trb, this caused for example stop endpoint command to timeout in xhci_stop_device() in about 2% of suspend/resume cases. This should also solve some weird behavior happening in command cancellation cases. This patch is based on a patch submitted by Sarah Sharp to linux-usb, but then forgotten: http://marc.info/?l=linux-usb&m=136269803207465&w=2 This patch should be backported to kernels as old as 3.7, that contain the commit b92cc66c047ff7cf587b318fe377061a353c120f "xHCI: add aborting command ring function" Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
* Merge tag 'for-usb-2013-08-15-step-1' into for-usb-nextSarah Sharp2013-08-161-0/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | xhci: Step 1 to fix usb-linus and usb-next. Hi Greg, This is the first of three steps to fix your usb-linus and usb-next trees. As I mentioned, commit 4fae6f0fa86f92e6bc7429371b1e177ad0aaac66 "USB: handle LPM errors during device suspend correctly" was incorrectly added to usb-next when it should have been added to usb-linus and marked for stable. Two port power off bug fixes touch the same code that patch touches, but it's not easy to simply move commit 4fae6f0f patch to usb-linus because commit 28e861658e23ca94692f98e245d254c75c8088a7 "USB: refactor code for enabling/disabling remote wakeup" also touched those code sections. I propose a two step process to fix this: 1. Pull these four patches into usb-linus. 2. Revert commit 28e861658e23ca94692f98e245d254c75c8088a7 from usb-next. Merge usb-linus into usb-next, and resolve the conflicts. I will be sending pull requests for these steps. This pull request is step one, and contains the backported version of commit 4fae6f0fa86f92e6bc7429371b1e177ad0aaac66, the two port power off fixes, and an unrelated xhci-plat bug fix. Sarah Sharp Resolved conflicts: drivers/usb/core/hub.c
| * xhci-plat: Don't enable legacy PCI interrupts.Sarah Sharp2013-08-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The xHCI platform driver calls into usb_add_hcd to register the irq for its platform device. It does not want the xHCI generic driver to register an interrupt for it at all. The original code did that by setting the XHCI_BROKEN_MSI quirk, which tells the xHCI driver to not enable MSI or MSI-X for a PCI host. Unfortunately, if CONFIG_PCI is enabled, and CONFIG_USB_DW3 is enabled, the xHCI generic driver will attempt to register a legacy PCI interrupt for the xHCI platform device in xhci_try_enable_msi(). This will result in a bogus irq being registered, since the underlying device is a platform_device, not a pci_device, and thus the pci_device->irq pointer will be bogus. Add a new quirk, XHCI_PLAT, so that the xHCI generic driver can distinguish between a PCI device that can't handle MSI or MSI-X, and a platform device that should not have its interrupts touched at all. This quirk may be useful in the future, in case other corner cases like this arise. This patch should be backported to kernels as old as 3.9, that contain the commit 00eed9c814cb8f281be6f0f5d8f45025dc0a97eb "USB: xhci: correctly enable interrupts". Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Yu Y Wang <yu.y.wang@intel.com> Tested-by: Yu Y Wang <yu.y.wang@intel.com> Reviewed-by: Felipe Balbi <balbi@ti.com> Cc: stable@vger.kernel.org
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-17 07:54:56 +0200