aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/usb
Commit message (Collapse)AuthorAgeFilesLines
* USB: PL2303: correctly handle baudrates above 115200Michal Sroczynski2011-10-031-4/+22
| | | | | | | | | | commit 8d48fdf689fed2c73c493e5146d1463689246442 upstream. PL2303: correctly handle baudrates above 115200 Signed-off-by: Michal Sroczynski <msroczyn@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* ehci: add pci quirk for Ordissimo and RM Slate 100 tooAnisse Astier2011-10-031-0/+7
| | | | | | | | | | | | commit 0c42a4e84502533ec40544324debe2a62836ae11 upstream. Add another variant of the Pegatron tablet used by Ordissimo, and apparently RM Slate 100, to the list of models that should skip the negociation for the handoff of the EHCI controller. Signed-off-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* ehci: refactor pci quirk to use standard dmi_check_system methodAnisse Astier2011-10-031-7/+14
| | | | | | | | | | | | | | commit 03c75362181b0b1d6a330e7cf8def10ba988dfbe upstream. In commit 3610ea5397b80822e417aaa0e706fd803fb05680 (ehci: workaround for pci quirk timeout on ExoPC), a workaround was added to skip the negociation for the handoff of the EHCI controller. Refactor the DMI detection code to use standard dmi_check_system function. Signed-off-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: xhci: Set change bit when warm reset change is set.Sarah Sharp2011-10-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 44f4c3ed60fb21e1d2dd98304390ac121e6c7c6d upstream. Sometimes, when a USB 3.0 device is disconnected, the Intel Panther Point xHCI host controller will report a link state change with the state set to "SS.Inactive". This causes the xHCI host controller to issue a warm port reset, which doesn't finish before the USB core times out while waiting for it to complete. When the warm port reset does complete, and the xHC gives back a port status change event, the xHCI driver kicks khubd. However, it fails to set the bit indicating there is a change event for that port because the logic in xhci-hub.c doesn't check for the warm port reset bit. After that, the warm port status change bit is never cleared by the USB core, and the xHC stops reporting port status change bits. (The xHCI spec says it shouldn't report more port events until all change bits are cleared.) This means any port changes when a new device is connected will never be reported, and the port will seem "dead" until the xHCI driver is unloaded and reloaded, or the computer is rebooted. Fix this by making the xHCI driver set the port change bit when a warm port reset change bit is set. A better solution would be to make the USB core handle warm port reset in differently, merging the current code with the standard port reset code that does an incremental backoff on the timeout, and tries to complete the port reset two more times before giving up. That more complicated fix will be merged next window, and this fix will be backported to stable. This should be backported to kernels as old as 3.0, since that was the first kernel with commit a11496ebf375 ("xHCI: warm reset support"). Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* xhci: Handle zero-length isochronous packets.Sarah Sharp2011-10-031-10/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 48df4a6fd8c40c0bbcbca2044f5f2bc75dcf6db1 upstream. For a long time, the xHCI driver has had this note: /* FIXME: Ignoring zero-length packets, can those happen? */ It turns out that, yes, there are drivers that need to queue zero-length transfers for isochronous OUT transfers. Without this patch, users will see kernel hang messages when a driver attempts to enqueue an isochronous URB with a zero length transfer (because count_isoc_trbs_needed will return zero for that TD, xhci_td->last_trb will never be set, and updating the dequeue pointer will cause an infinite loop). Matěj ran into this issue when using an NI Audio4DJ USB soundcard with the snd-usb-caiaq driver. See https://bugzilla.kernel.org/show_bug.cgi?id=40702 Fix count_isoc_trbs_needed() to return 1 for zero-length transfers (thanks Alan on the math help). Update the various TRB field calculations to deal with zero-length transfers. We're still transferring one packet with a zero-length data payload, so the total_packet_count should be 1. The Transfer Burst Count (TBC) and Transfer Last Burst Packet Count (TLBPC) fields should be set to zero. This patch should be backported to kernels as old as 2.6.36. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Matěj Laitl <matej@laitl.cz> Cc: Daniel Mack <zonque@gmail.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* xhci: Remove TDs from TD lists when URBs are canceled.Sarah Sharp2011-10-032-8/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 585df1d90cb07a02ca6c7a7d339e56e46d50dafb upstream. When a driver tries to cancel an URB, and the host controller is dying, xhci_urb_dequeue will giveback the URB without removing the xhci_tds that comprise that URB from the td_list or the cancelled_td_list. This can cause a race condition between the driver calling URB dequeue and the stop endpoint command watchdog timer. If the timer fires on a dying host, and a driver attempts to resubmit while the watchdog timer has dropped the xhci->lock to giveback a cancelled URB, URBs may be given back by the xhci_urb_dequeue() function. At that point, the URB's priv pointer will be freed and set to NULL, but the TDs will remain on the td_list. This will cause an oops in xhci_giveback_urb_in_irq() when the watchdog timer attempts to loop through the endpoints' td_lists, giving back killed URBs. Make sure that xhci_urb_dequeue() removes TDs from the TD lists and canceled TD lists before it gives back the URB. This patch should be backported to kernels as old as 2.6.36. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* xhci: Fix failed enqueue in the middle of isoch TD.Sarah Sharp2011-10-031-6/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 522989a27c7badb608155b1f1dea3487ed431f74 upstream. When an isochronous transfer is enqueued, xhci_queue_isoc_tx_prepare() will ensure that there is enough room on the transfer rings for all of the isochronous TDs for that URB. However, when xhci_queue_isoc_tx() is enqueueing individual isoc TDs, the prepare_transfer() function can fail if the endpoint state has changed to disabled, error, or some other unknown state. With the current code, if Nth TD (not the first TD) fails, the ring is left in a sorry state. The partially enqueued TDs are left on the ring, and the first TRB of the TD is not given back to the hardware. The enqueue pointer is left on the TRB after the last successfully enqueued TD. This means the ring is basically useless. Any new transfers will be enqueued after the failed TDs, which the hardware will never read because the cycle bit indicates it does not own them. The ring will fill up with untransferred TDs, and the endpoint will be basically unusable. The untransferred TDs will also remain on the TD list. Since the td_list is a FIFO, this basically means the ring handler will be waiting on TDs that will never be completed (or worse, dereference memory that doesn't exist any more). Change the code to clean up the isochronous ring after a failed transfer. If the first TD failed, simply return and allow the xhci_urb_enqueue function to free the urb_priv. If the Nth TD failed, first remove the TDs from the td_list. Then convert the TRBs that were enqueued into No-op TRBs. Make sure to flip the cycle bit on all enqueued TRBs (including any link TRBs in the middle or between TDs), but leave the cycle bit of the first TRB (which will show software-owned) intact. Then move the ring enqueue pointer back to the first TRB and make sure to change the xhci_ring's cycle state to what is appropriate for that ring segment. This ensures that the No-op TRBs will be overwritten by subsequent TDs, and the hardware will not start executing random TRBs because the cycle bit was left as hardware-owned. This bug is unlikely to be hit, but it was something I noticed while tracking down the watchdog timer issue. I verified that the fix works by injecting some errors on the 250th isochronous URB queued, although I could not verify that the ring is in the correct state because uvcvideo refused to talk to the device after the first usb_submit_urb() failed. Ring debugging shows that the ring looks correct, however. This patch should be backported to kernels as old as 2.6.36. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* xhci: Fix memory leak during failed enqueue.Sarah Sharp2011-10-032-8/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit d13565c12828ce0cd2a3862bf6260164a0653352 upstream. When the isochronous transfer support was introduced, and the xHCI driver switched to using urb->hcpriv to store an "urb_priv" pointer, a couple of memory leaks were introduced into the URB enqueue function in its error handling paths. xhci_urb_enqueue allocates urb_priv, but it doesn't free it if changing the control endpoint's max packet size fails or the bulk endpoint is in the middle of allocating or deallocating streams. xhci_urb_enqueue also doesn't free urb_priv if any of the four endpoint types' enqueue functions fail. Instead, it expects those functions to free urb_priv if an error occurs. However, the bulk, control, and interrupt enqueue functions do not free urb_priv if the endpoint ring is NULL. It will, however, get freed if prepare_transfer() fails in those enqueue functions. Several of the error paths in the isochronous endpoint enqueue function also fail to free it. xhci_queue_isoc_tx_prepare() doesn't free urb_priv if prepare_ring() indicates there is not enough room for all the isochronous TDs in this URB. If individual isochronous TDs fail to be queued (perhaps due to an endpoint state change), urb_priv is also leaked. This argues that the freeing of urb_priv should be done in the function that allocated it, xhci_urb_enqueue. This patch looks rather ugly, but refactoring the code will have to wait because this patch needs to be backported to stable kernels. This patch should be backported to kernels as old as 2.6.36. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* xHCI: report USB2 port in resuming as suspendAndiry Xu2011-10-031-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 8a8ff2f9399b23b968901f585ccb5a70a537c5ae upstream. When a USB2 port initiate a remote wakeup, software shall ensure that resume is signaled for at least 20ms, and then write '0' to the PLS field. According to this, xhci driver do the following things: 1. When receive a remote wakeup event in irq_handler, set the resume_done value as jiffies + 20ms, and modify rh_timer to poll root hub status at that time; 2. When receive a GetPortStatus request, if the jiffies is after the resume_done value, clear the resume signal and resume_done. However, if usb_port_resume() is called before the rh_timer triggered, it will indicate the port as Suspend Cleared and skip the clear resume signal part. The device will fail the usb_get_status request in finish_port_resume(), and usbcore will try a reset-resume instead. Device will work OK after reset-resume, but resume_done value is not cleared in this case, and xhci_bus_suspend() will fail because when it finds a non-zero resume_done value, it will regard the port as resuming and return -EBUSY. This causes issue on some platforms that the system fail to suspend after remote wakeup from suspend by USB2 devices connected to xHCI port. To fix this issue, report the port status as suspend if the resume is signaling less that 20ms, and usb_port_resume() will wait 25ms and check port status again, so xHCI driver can clear the resume signaling and resume_done value. This should be backported to kernels as old as 2.6.37. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* xHCI: fix port U3 status check conditionAndiry Xu2011-10-031-1/+1
| | | | | | | | | | | | | | | commit 5ac04bf190e6f8b17238aef179ebd7f2bdfec919 upstream. Fix the port U3 status check when Clear PORT_SUSPEND Feature. The port status should be masked with PORT_PLS_MASK to check if it's in U3 state. This should be backported to kernels as old as 2.6.37. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: EHCI: Do not rely on PORT_SUSPEND to stop USB resuming in ↵Wang Zhi2011-10-031-4/+3
| | | | | | | | | | | | | | | | | | ehci_bus_resume(). commit d0f2fb2500b1c5fe4967eb45d8c9bc758d7aef80 upstream. From EHCI Spec p.28 HC should clear PORT_SUSPEND when SW clears PORT_RESUME. In Intel Oaktrail platform, MPH (Multi-Port Host Controller) core clears PORT_SUSPEND directly when SW sets PORT_RESUME bit. If we rely on PORT_SUSPEND bit to stop USB resume, we will miss the action of clearing PORT_RESUME. This will cause unexpected long resume signal on USB bus. Signed-off-by: Wang Zhi <zhi.wang@windriver.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* usb: musb: cppi: fix build errors due to DBG and missing musb variablePer Forlin2011-10-031-9/+17
| | | | | | | | | | | | commit f847a79ab3c1faca3022061045cd22e4678c1b1c upstream. Replace DBG with dev_dbg and fix invalid access of musb->controller. With this patch cppi_dma builds successfully. Signed-off-by: Per Forlin <per.forlin@linaro.org> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB option driver K3765/K4505 avoid CDC_DATA interfaceAndrew Bird2011-10-031-1/+2
| | | | | | | | | | | | | commit 6118514e8749105334f46ccec6faf9a439be6cf9 upstream. Currently the Option driver avoids binding interface 1 on Huawei K3765 and K4505 broadband modems as it should be handled by the cdc_ether driver instead. This patch ensures we don't bind the interface 2 on those devices as that is CDC_DATA. Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: option: add YUGA device id to driverGavin.zhu2011-10-031-0/+92
| | | | | | | | commit c6eb2d75ffcdfafa37ff010bf467de20d468ef79 upstream. Signed-off-by: Gavin.zhu <gavin.kx@qq.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB option driver add PID of Huawei Vodafone K4605Andrew Bird2011-10-031-2/+5
| | | | | | | | | | | | | | | | commit 7e1805844da18a37e6d251d286f93c94b52d791e upstream. This patch adds the product ID of Huawei's Vodafone K4605 mobile broadband modem to option.c. This is necessary so that the driver gets loaded on demand without the intervention of usb_modeswitch. This has the benefit of it becoming available faster and also ensures that the option driver is not bound to a network interface that should be claimed by suitable network driver. Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk> Signed-off-by: Alex Chiang <achiang@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB option driver add PID of Huawei Vodafone K3806Andrew Bird2011-10-031-0/+2
| | | | | | | | | | | | | | | commit 0e69d75ccb2f091757b38d4d6a2ed739e06b615e upstream. This patch adds the product ID of Huawei's Vodafone K3806 mobile broadband modem to option.c. This is necessary so that the driver gets loaded on demand without the intervention of usb_modeswitch. This has the benefit of it becoming available faster and also ensures that the option driver is not bound to a network interface that should be claimed by cdc_ether. Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk> Signed-off-by: Alex Chiang <achiang@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* usb: s5p-ehci: fix a NULL pointer deferenceYulgon Kim2011-10-031-0/+1
| | | | | | | | | | | | | | commit e5d3d4463fb30998385f9e78ab3c7f63b5813000 upstream. This patch fixes a NULL pointer deference. A NULL pointer dereference happens since s5p_ehci->hcd field is not initialized yet in probe function. [jg1.han@samsung.com: edit commit message] Signed-off-by: Yulgon Kim <yulgon.kim@samsung.com> Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: ftdi_sio: add Calao reference board supportJean-Christophe PLAGNIOL-VILLARD2011-10-031-1/+19
| | | | | | | | | | | | | | | | | | commit c96fbdd0ab97235f930ebf24b38fa42a2e3458cf upstream. Calao use on there dev kits a FT2232 where the port 0 is used for the JTAG and port 1 for the UART They use the same VID and PID as FTDI Chip but they program the manufacturer name in the eeprom So use this information to detect it Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Cc: Gregory Hermant <gregory.hermant@calao-systems.com> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: option driver: add PID for Vodafone-Huawei K4511Andrew Bird2011-08-171-0/+3
| | | | | | | | | | | | | | commit 35e9e21fb30dc4452b33aed5cbf233743bffca40 upstream. This patch adds the product ID of Huawei's Vodafone K4511 mobile broadband modem to option.c. This is necessary so that the driver gets loaded on demand without the intervention of usb_modeswitch. This has the benefit of it becoming available faster and also ensures that the option driver is not bound to a network interface that should be claimed by cdc_ether. Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: option driver: add PID for Vodafone-Huawei K4510Andrew Bird2011-08-171-0/+3
| | | | | | | | | | | | | | commit 0930bb46bbbb43afe3381ece2cb2f8a5bc3fb544 upstream. This patch adds the product ID of Huawei's Vodafone K4510 mobile broadband modem to option.c. This is necessary so that the driver gets loaded on demand without the intervention of usb_modeswitch. This has the benefit of it becoming available faster and also ensures that the option driver is not bound to a network interface that should be claimed by cdc_ether. Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: option driver: add PID for Vodafone-Huawei K3771Andrew Bird2011-08-171-0/+3
| | | | | | | | | | | | | | commit e2949080792256d1c979aaf30ecd4cab42829f87 upstream. This patch adds the product ID of Huawei's Vodafone K3771 mobile broadband modem to option.c. This is necessary so that the driver gets loaded on demand without the intervention of usb_modeswitch. This has the benefit of it becoming available faster and also ensures that the option driver is not bound to a network interface that should be claimed by cdc_ether. Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: option driver: add PID for Vodafone-Huawei K3770Andrew Bird2011-08-171-0/+3
| | | | | | | | | | | | | | commit 07b21fd83606263fe6f327b98774d51e13e502fd upstream. This patch adds the product ID of Huawei's Vodafone K3770 mobile broadband modem to option.c. This is necessary so that the driver gets loaded on demand without the intervention of usb_modeswitch. This has the benefit of it becoming available faster and also ensures that the option driver is not bound to a network interface that should be claimed by cdc_ether. Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: Serial: Added device ID for Qualcomm Modem in Sagemcom's HiLo3GVijay Chavan2011-08-171-0/+1
| | | | | | | | | | commit e468561739fffb972d486b98f66c723936335136 upstream. A new device ID pair is added for Qualcomm Modem present in Sagemcom's HiLo3G module. Signed-off-by: Vijay Chavan <VijayChavan007@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: usb-storage: unusual_devs entry for ARM V2M motherboard.Nick Bowler2011-08-171-0/+10
| | | | | | | | | | | | | | | | | | | commit a871e4f5519d8c52430052e1d340dd5710eb5ad6 upstream. Connecting the V2M to a Linux host results in a constant stream of errors spammed to the console, all of the form sd 1:0:0:0: ioctl_internal_command return code = 8070000 : Sense Key : 0x4 [current] : ASC=0x0 ASCQ=0x0 The errors appear to be otherwise harmless. Add an unusual_devs entry which eliminates all of the error messages. Signed-off-by: Nick Bowler <nbowler@elliptictech.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: ftdi_sio: fix minor typo in get_ftdi_divisorIonut Nicu2011-08-171-1/+1
| | | | | | | | | | | | commit 1862cdd542025218f7a390b7e6ddc83a1362d1e0 upstream. Even if it's unlikely for this to cause an error, there is a typo in the code that uses the bitwise-AND operator instead of the logical one. Signed-off-by: Ionut Nicu <ionut.nicu@cloudbit.ro> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: assign instead of equal in usbtmc.cMaxim Nikulin2011-08-171-1/+1
| | | | | | | | | | commit 4f1a7a3e78037721496283ea3e87cfefc64d99c7 upstream. Assign operator instead of equality test in the usbtmc_ioctl_abort_bulk_in() function. Signed-off-by: Maxim A. Nikulin <M.A.Nikulin@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* usb: musb: fix oops on musb_gadget_pullupJohn Stultz2011-08-171-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | commit 72c487dfb94d02025fb7437dfe2314d836d5a9ab upstream. an 'unhandled fault' is causes when a gadget driver calls usb_gadget_connect() while the USB cable isn't plugged into the OTG port. the fault is caused by an access to MUSB's memory space while its clock is turned off due to pm_runtime kicking in. in order to fix the fault, we enclose musb_gadget_pullup() with pm_runtime_get_sync() ... pm_runtime_put() calls to be sure we will always reach that path with clock turned on. [ balbi@ti.com : simplified commit log; removed few things which didn't belong there ] Reported-by: Zach Pfeffer <zach.pfeffer@linaro.org> Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* usb/config: use proper endian access for wMaxPacketSizeSebastian Andrzej Siewior2011-08-171-5/+6
| | | | | | | | | | | | | | | | | commit 7de7c7d2cb49900e0b967be871bf695c7d6135c9 upstream. wMaxPacketSize is __le16 and should be accessed as such. Also fix the wBytesPerInterval assignment while here. v2: also fix the wBytesPerInterval assigment, noticed by Matt Evans This patch should be backported to the 3.0 kernel. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* xhci: Don't submit commands or URBs to halted hosts.Sarah Sharp2011-08-171-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 7bd89b4017f46a9b92853940fd9771319acb578a upstream. Commit fccf4e86200b8f5edd9a65da26f150e32ba79808 "USB: Free bandwidth when usb_disable_device is called" caused a bit of an issue when the xHCI host controller driver is unloaded. It changed the USB core to remove all endpoints when a USB device is disabled. When the driver is unloaded, it will remove the SuperSpeed split root hub, which will disable all devices under that roothub and then halt the host controller. When the second High Speed split roothub is removed, the USB core will attempt to disable the endpoints, which will submit a Configure Endpoint command to a halted host controller. The command will eventually time out, but it makes the xHCI driver unload take *minutes* if there are a couple of USB 1.1/2.0 devices attached. We must halt the host controller when the SuperSpeed roothub is removed, because we can't allow any interrupts from things like port status changes. Make several different functions not submit commands or URBs to the host controller when the host is halted, by adding a check in xhci_check_args(). xhci_check_args() is used by these functions: xhci.c-int xhci_urb_enqueue() xhci.c-int xhci_drop_endpoint() xhci.c-int xhci_add_endpoint() xhci.c-int xhci_check_bandwidth() xhci.c-void xhci_reset_bandwidth() xhci.c-static int xhci_check_streams_endpoint() xhci.c-int xhci_discover_or_reset_device() It's also used by xhci_free_dev(). However, we have to take special care in that case, because we want the device memory to be freed if the host controller is halted. This patch should be backported to the 2.6.39 and 3.0 kernel. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: xhci: fix OS want to own HCJiSheng Zhang2011-08-171-1/+1
| | | | | | | | | | | | | commit 6768458b17f9bf48a4c3a34e49b20344091b5f7e upstream. Software should set XHCI_HC_OS_OWNED bit to request ownership of xHC. This patch should be backported to kernels as far back as 2.6.31. Signed-off-by: JiSheng Zhang <jszhang3@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* EHCI: fix direction handling for interrupt data togglesAlan Stern2011-08-042-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit e04f5f7e423018bcec84c11af2058cdce87816f3 upstream. This patch (as1480) fixes a rather obscure bug in ehci-hcd. The qh_update() routine needs to know the number and direction of the endpoint corresponding to its QH argument. The number can be taken directly from the QH data structure, but the direction isn't stored there. The direction is taken instead from the first qTD linked to the QH. However, it turns out that for interrupt transfers, qh_update() gets called before the qTDs are linked to the QH. As a result, qh_update() computes a bogus direction value, which messes up the endpoint toggle handling. Under the right combination of circumstances this causes usb_reset_endpoint() not to work correctly, which causes packets to be dropped and communications to fail. Now, it's silly for the QH structure not to have direct access to all the descriptor information for the corresponding endpoint. Ultimately it may get a pointer to the usb_host_endpoint structure; for now, adding a copy of the direction flag solves the immediate problem. This allows the Spyder2 color-calibration system (a low-speed USB device that sends all its interrupt data packets with the toggle set to 0 and hance requires constant use of usb_reset_endpoint) to work when connected through a high-speed hub. Thanks to Graeme Gill for supplying the hardware that allowed me to track down this bug. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Graeme Gill <graeme@argyllcms.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* EHCI: only power off port if over-current is activeSergei Shtylyov2011-08-041-1/+2
| | | | | | | | | | | | | | | | | | | | commit 81463c1d707186adbbe534016cd1249edeab0dac upstream. MAX4967 USB power supply chip we use on our boards signals over-current when power is not enabled; once it's enabled, over-current signal returns to normal. That unfortunately caused the endless stream of "over-current change on port" messages. The EHCI root hub code reacts on every over-current signal change with powering off the port -- such change event is generated the moment the port power is enabled, so once enabled the power is immediately cut off. I think we should only cut off power when we're seeing the active over-current signal, so I'm adding such check to that code. I also think that the fact that we've cut off the port power should be reflected in the result of GetPortStatus request immediately, hence I'm adding a PORTSCn register readback after write... Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* usb: musb: restore INDEX register in resume pathAjay Kumar Gupta2011-08-041-0/+1
| | | | | | | | | | | | | | commit 3c5fec75e121b21a2eb35e5a6b44291509abba6f upstream. Restoring the missing INDEX register value in musb_restore_context(). Without this suspend resume functionality is broken with offmode enabled. Acked-by: Anand Gadiyar <gadiyar@ti.com> Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: EHCI: go back to using the system clock for QH unlinksAlan Stern2011-08-043-48/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 004c19682884d4f40000ce1ded53f4a1d0b18206 upstream. This patch (as1477) fixes a problem affecting a few types of EHCI controller. Contrary to what one might expect, these controllers automatically stop their internal frame counter when no ports are enabled. Since ehci-hcd currently relies on the frame counter for determining when it should unlink QHs from the async schedule, those controllers run into trouble: The frame counter stops and the QHs never get unlinked. Some systems have also experienced other problems traced back to commit b963801164618e25fbdc0cd452ce49c3628b46c8 (USB: ehci-hcd unlink speedups), which made the original switch from using the system clock to using the frame counter. It never became clear what the reason was for these problems, but evidently it is related to use of the frame counter. To fix all these problems, this patch more or less reverts that commit and goes back to using the system clock. But this can't be done cleanly because other changes have since been made to the scan_async() subroutine. One of these changes involved the tricky logic that tries to avoid rescanning QHs that have already been seen when the scanning loop is restarted, which happens whenever an URB is given back. Switching back to clock-based unlinks would make this logic even more complicated. Therefore the new code doesn't rescan the entire async list whenever a giveback occurs. Instead it rescans only the current QH and continues on from there. This requires the use of a separate pointer to keep track of the next QH to scan, since the current QH may be unlinked while the scanning is in progress. That new pointer must be global, so that it can be adjusted forward whenever the _next_ QH gets unlinked. (uhci-hcd uses this same trick.) Simplification of the scanning loop removes a level of indentation, which accounts for the size of the patch. The amount of code changed is relatively small, and it isn't exactly a reversion of the b963801164 commit. This fixes Bugzilla #32432. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Matej Kenda <matejken@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: OHCI: fix another regression for NVIDIA controllersAlan Stern2011-08-041-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 6ea12a04d295235ed67010a09fdea58c949e3eb0 upstream. The NVIDIA series of OHCI controllers continues to be troublesome. A few people using the MCP67 chipset have reported that even with the most recent kernels, the OHCI controller fails to handle new connections and spams the system log with "unable to enumerate USB port" messages. This is different from the other problems previously reported for NVIDIA OHCI controllers, although it is probably related. It turns out that the MCP67 controller does not like to be kept in the RESET state very long. After only a few seconds, it decides not to work any more. This patch (as1479) changes the PCI initialization quirk code so that NVIDIA controllers are switched into the SUSPEND state after 50 ms of RESET. With no interrupts enabled and all the downstream devices reset, and thus unable to send wakeup requests, this should be perfectly safe (even for non-NVIDIA hardware). The removal code in ohci-hcd hasn't been changed; it will still leave the controller in the RESET state. As a result, if someone unloads ohci-hcd and then reloads it, the controller won't work again until the system is rebooted. If anybody complains about this, the removal code can be updated similarly. This fixes Bugzilla #22052. Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: serial: add IDs for WinChipHead USB->RS232 adapterWolfgang Denk2011-08-042-0/+5
| | | | | | | | | | | commit 026dfaf18973404a01f488d6aa556a8c466e06a4 upstream. Add ID 4348:5523 for WinChipHead USB->RS 232 adapter with Prolifec PL2303 chipset Signed-off-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: additional regression fix for device removalAlan Stern2011-07-071-1/+8
| | | | | | | | | | | | | | | | | Commit e534c5b831c8b8e9f5edee5c8a37753c808b80dc (USB: fix regression occurring during device removal) didn't go far enough. It failed to take into account that when a driver claims multiple interfaces, it may release them all at the same time. As a result, some interfaces can get released before they are unregistered, and we deadlock trying to acquire the bandwidth_mutex that we already own. This patch (asl478) handles this case by setting the "unregistering" flag on all the interfaces before removing any of them. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Tested-by: Éric Piel <eric.piel@tremplin-utc.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: fix regression occurring during device removalAlan Stern2011-07-011-0/+2
| | | | | | | | | | | | | | | | | | This patch (as1476) fixes a regression introduced by fccf4e86200b8f5edd9a65da26f150e32ba79808 (USB: Free bandwidth when usb_disable_device is called). usb_disconnect() grabs the bandwidth_mutex before calling usb_disable_device(), which calls down indirectly to usb_set_interface(), which tries to acquire the bandwidth_mutex. The fix causes usb_set_interface() to return early when it is called for an interface that has already been unregistered, which is what happens in usb_disable_device(). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: fsl_udc_core: fix build breakage when building for ARM archAnatolij Gustschin2011-07-011-12/+24
| | | | | | | | | | | | | | | | | | Commit 09ba0def (USB: fsl_udc_core: prepare for SoCs with BE registers and descriptors) introduced build breakage on ARM arch. Fix it by setting accessors using a static inline function which is a nop when compiling the driver for ARM arch. Commit 2ea6698 (USB: fsl_udc_core: support device mode of MPC5121E DR USB Controller) caused another breakage on ARM by using flush_dcache_range(). Don't use it, convert to the DMA API usage instead. USB2.0CV Halt Endpoint Test succeeds on PPC. Tested both on ARM i.MX31 and mpc5121 PPC, also with CONFIG_DMA_API_DEBUG enabled. Signed-off-by: Anatolij Gustschin <agust@denx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Merge branch 'usb-linus' of ↵Linus Torvalds2011-06-2819-31/+146
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6 * 'usb-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6: MAINTAINERS: add myself as maintainer of USB/IP usb: r8a66597-hcd: fix cannot detect low/full speed device USB: ehci-ath79: fix a NULL pointer dereference USB: Add new FT232H chip to drivers/usb/serial/ftdi_sio.c usb/isp1760: Fix bug preventing the unlinking of control urbs USB: Fix up URB error codes to reflect implementation. xhci: Always set urb->status to zero for isoc endpoints. xhci: Add reset on resume quirk for asrock p67 host xHCI 1.0: Incompatible Device Error USB: don't let errors prevent system sleep USB: don't let the hub driver prevent system sleep USB: change maintainership of ohci-hcd and ehci-hcd xHCI 1.0: Force Stopped Event(FSE) xhci: Don't warn about zeroed bMaxBurst descriptor field. USB: Free bandwidth when usb_disable_device is called. xhci: Reject double add of active endpoints. USB: TI 3410/5052 USB Serial Driver: Fix mem leak when firmware is too big. usb: musb: gadget: clear TXPKTRDY flag when set FLUSHFIFO usb: musb: host: compare status for negative error values
| * usb: r8a66597-hcd: fix cannot detect low/full speed deviceYoshihiro Shimoda2011-06-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | This controller can control "Transaction Translators", but the hcd->has_tt is not set. Since the commit d199c96d41d80a567493e12b8e96ea056a1350c1 ("USB: prevent buggy from crashing the USB stack") has checked it, the driver could not work the low/full speed device. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * USB: ehci-ath79: fix a NULL pointer dereferenceGabor Juhos2011-06-271-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Loading the ehci-hcd module on the ath79 platform causes a NULL pointer dereference: CPU 0 Unable to handle kernel paging request at virtual address 00000000, epc == c0252928, ra == c00de968 Oops[#1]: Cpu 0 $ 0 : 00000000 00000070 00000001 00000000 $ 4 : 802cf870 0000117e ffffffff 8019c7bc $ 8 : 0000000a 00000002 00000001 fffffffb $12 : 8026ef20 0000000f ffffff80 802dad3c $16 : 8077a2d4 8077a200 c00f3484 8019ed84 $20 : c00f0000 00000003 000000a0 80262c2c $24 : 00000002 80079da0 $28 : 80788000 80789c80 80262b14 c00de968 Hi : 00000000 Lo : b61f0000 epc : c0252928 __mod_vermagic5+0xc260/0xc7e8 [ehci_hcd] Not tainted ra : c00de968 usb_add_hcd+0x2a4/0x858 [usbcore] Status: 1000c003 KERNEL EXL IE Cause : 00800008 BadVA : 00000000 PrId : 00019374 (MIPS 24Kc) Modules linked in: ehci_hcd(+) pppoe pppox ipt_REJECT xt_TCPMSS ipt_LOG xt_comment xt_multiport xt_mac xt_limit iptable_mangle iptable_filte r ip_tables xt_tcpudp x_tables ppp_async ppp_generic slhc ath mac80211 usbcore nls_base input_polldev crc_ccitt cfg80211 compat input_core a rc4 aes_generic crypto_algapi Process insmod (pid: 379, threadinfo=80788000, task=80ca2180, tls=77fe52d0) Stack : c0253184 80c57d80 80789cac 8077a200 00000001 8019edc0 807fa800 8077a200 8077a290 c00f3484 8019ed84 c00f0000 00000003 000000a0 80262c2c c00de968 802d0000 800878cc c0253228 c02528e4 c0253184 80c57d80 80bf6800 80ca2180 8007b75c 00000000 8077a200 802cf830 802d0000 00000003 fffffff4 00000015 00000348 00000124 800b189c c024bb4c c0255000 801a27e8 c0253228 c02528e4 ... Call Trace: [<c0252928>] __mod_vermagic5+0xc260/0xc7e8 [ehci_hcd] It is caused by: commit c430131a02d677aa708f56342c1565edfdacb3c0 Author: Jan Andersson <jan@gaisler.com> Date: Tue May 3 20:11:57 2011 +0200 USB: EHCI: Support controllers with big endian capability regs The two first HC capability registers (CAPLENGTH and HCIVERSION) are defined as one 8-bit and one 16-bit register. Most HC implementations have selected to treat these registers as part of a 32-bit register, giving the same layout for both big and small endian systems. This patch adds a new quirk, big_endian_capbase, to support controllers with big endian register interfaces that treat HCIVERSION and CAPLENGTH as individual registers. Signed-off-by: Jan Andersson <jan@gaisler.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> The reading of the HC capability register has been moved by that commit to a place where the ehci->caps field is not initialized yet. This patch moves the reading of the register back to the original place. Acked-by: Jan Andersson <jan@gaisler.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * USB: Add new FT232H chip to drivers/usb/serial/ftdi_sio.cUwe Bonnes2011-06-273-6/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | appended patch adds support for the new FTDI FT232H chip. This chip is a single channel version of the dual FT2232H/quad FT4232H, coming with it's own default PID 0x6014 (FT2232H uses the same PID 0x6010 like FT2232C, FT4232H has also it's own PID). The patch was checked on an UM232H module and a terminal program with TX/RX shorted to that typing in the terminal reproduced the characters. Signed-off-by: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * usb/isp1760: Fix bug preventing the unlinking of control urbsArvid Brodin2011-06-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Both control and bulk transfers use isp1760 slots of type ATL, but the driver unlink code for ATL slots only acts on urbs describing a bulk transfer, letting the code for INT slots take care of the unlink instead, which often ended up removing the interrupt transfer for root hub events instead. That's not good, and gets fixed by this patch. Signed-off-by: Arvid Brodin <arvid.brodin@enea.com> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * Merge branch 'for-usb-linus' of ↵Greg Kroah-Hartman2011-06-277-12/+88
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus * 'for-usb-linus' of git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sarah/xhci: USB: Fix up URB error codes to reflect implementation. xhci: Always set urb->status to zero for isoc endpoints. xhci: Add reset on resume quirk for asrock p67 host xHCI 1.0: Incompatible Device Error xHCI 1.0: Force Stopped Event(FSE) xhci: Don't warn about zeroed bMaxBurst descriptor field. USB: Free bandwidth when usb_disable_device is called. xhci: Reject double add of active endpoints.
| | * xhci: Always set urb->status to zero for isoc endpoints.Sarah Sharp2011-06-171-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the xHCI driver encounters a Missed Service Interval event for an isochronous endpoint ring, it means the host controller skipped over one or more isochronous TDs. For TD that is skipped, skip_isoc_td() is called. This sets the frame descriptor status to -EXDEV, and also sets the value stored in the int pointed to by status to -EXDEV. If the isochronous TD happens to be the last TD in an URB, handle_tx_event() will use the status variable to give back the URB to the USB core. That means drivers will see urb->status as -EXDEV. It turns out that EHCI, UHCI, and OHCI always set urb->status to zero for an isochronous urb, regardless of what the frame status is. See itd_complete() in ehci-sched.c: } else { /* URB was too late */ desc->status = -EXDEV; } } /* handle completion now? */ if (likely ((urb_index + 1) != urb->number_of_packets)) goto done; /* ASSERT: it's really the last itd for this urb list_for_each_entry (itd, &stream->td_list, itd_list) BUG_ON (itd->urb == urb); */ /* give urb back to the driver; completion often (re)submits */ dev = urb->dev; ehci_urb_done(ehci, urb, 0); ehci_urb_done() completes the URB with the status of the third argument, which is always zero in this case. It turns out that many USB webcam drivers, such as uvcvideo, cannot handle urb->status set to a non-zero value. They will not resubmit their isochronous URBs in that case, and userspace will see a frozen video. Change the xHCI driver to be consistent with the EHCI and UHCI driver, and always set urb->status to 0 for isochronous URBs. This patch should be backported to kernels as old as 2.6.36 Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: "Xu, Andiry" <Andiry.Xu@amd.com> Cc: stable@kernel.org
| | * xhci: Add reset on resume quirk for asrock p67 hostMaarten Lankhorst2011-06-173-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The asrock p67 xhci controller completely dies on resume, add a quirk for this, to bring the host back online after a suspend. This should be backported to stable kernels as old as 2.6.37. Signed-off-by: Maarten Lankhorst <m.b.lankhorst@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@kernel.org
| | * xHCI 1.0: Incompatible Device ErrorAlex He2011-06-173-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is one new TRB Completion Code for the xHCI spec v1.0. Asserted if the xHC detects a problem with a device that does not allow it to be successfully accessed, e.g. due to a device compliance or compatibility problem. This error may be returned by any command or transfer, and is fatal as far as the Slot is concerned. Return -EPROTO by urb->status or frame->status of ISOC for transfer case. And return -ENODEV for configure endpoint command, evaluate context command and address device command if there is an incompatible Device Error. The error codes will be sent back to the USB core to decide how to do. It's unnecessary for other commands because after the three commands run successfully means that the device has been accepted. Signed-off-by: Alex He <alex.he@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
| | * xHCI 1.0: Force Stopped Event(FSE)Alex He2011-06-151-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FSE shall occur on the TD natural boundary. The software ep_ring dequeue pointer exceed the hardware ep_ring dequeue pointer in these cases of Table-3. As a result, the event_trb(pointed by hardware dequeue pointer) of the FSE can't be found in the current TD(pointed by software dequeue pointer). What should we do is to figured out the FSE case and skip over it. Signed-off-by: Alex He <alex.he@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
| | * xhci: Don't warn about zeroed bMaxBurst descriptor field.Sarah Sharp2011-06-151-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The USB 3.0 specification says that the bMaxBurst field in the SuperSpeed Endpoint Companion descriptor is supposed to indicate how many packets a SS device can handle before it needs to wait for an explicit handshake from the host controller. A zero value means the device can only handle one packet before it needs a handshake. Remove a warning in the xHCI driver that implies this is an invalid value. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
generated by cgit v1.1 at 2025-08-07 19:25:58 +0000