- 21 Oct, 2023 32 commits
-
-
Uwe Kleine-König authored
module_platform_driver_probe() has the advantage that the .probe() and .remove() calls can live in .init.text and .exit.text respectively and so some memory is saved. The downside is that dynamic bind and unbind are impossible. As the driver doesn't benefit from the advantages (both .probe and .remove are defined in plain .text), stop suffering from the downsides and use module_platform_driver() instead of module_platform_driver_probe(). Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231017204442.1625925-14-u.kleine-koenig@pengutronix.deSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Uwe Kleine-König authored
module_platform_driver_probe() has the advantage that the .probe() and .remove() calls can live in .init.text and .exit.text respectively and so some memory is saved. The downside is that dynamic bind and unbind are impossible. As the driver doesn't benefit from the advantages (both .probe and .remove are defined in plain .text), stop suffering from the downsides and use module_platform_driver() instead of module_platform_driver_probe(). Signed-off-by:
-
Uwe Kleine-König authored
module_platform_driver_probe() has the advantage that the .probe() and .remove() calls can live in .init.text and .exit.text respectively and so some memory is saved. The downside is that dynamic bind and unbind are impossible. As the driver doesn't benefit from the advantages (both .probe and .remove are defined in plain .text), stop suffering from the downsides and use module_platform_driver() instead of module_platform_driver_probe(). Signed-off-by:
-
Uwe Kleine-König authored
module_platform_driver_probe() has the advantage that the .probe() and .remove() calls can live in .init.text and .exit.text respectively and so some memory is saved. The downside is that dynamic bind and unbind are impossible. As the driver doesn't benefit from the advantages (both .probe and .remove are defined in plain .text), stop suffering from the downsides and use module_platform_driver() instead of module_platform_driver_probe(). Signed-off-by:
-
Uwe Kleine-König authored
module_platform_driver_probe() has the advantage that the .probe() and .remove() calls can live in .init.text and .exit.text respectively and so some memory is saved. The downside is that dynamic bind and unbind are impossible. As the driver doesn't benefit from the advantages (both .probe and .remove are defined in plain .text), stop suffering from the downsides and use module_platform_driver() instead of module_platform_driver_probe(). Signed-off-by:
-
Uwe Kleine-König authored
module_platform_driver_probe() has the advantage that the .probe() and .remove() calls can live in .init.text and .exit.text respectively and so some memory is saved. The downside is that dynamic bind and unbind are impossible. As the driver doesn't benefit from the advantages (both .probe and .remove are defined in plain .text), stop suffering from the downsides and use module_platform_driver() instead of module_platform_driver_probe(). Signed-off-by:
-
Rob Herring authored
Commit 14485de4 ("usb: Use device_get_match_data()") dropped the unconditional use of ci_hdrc_usb2_of_match resulting in this warning: drivers/usb/chipidea/ci_hdrc_usb2.c:41:34: warning: unused variable 'ci_hdrc_usb2_of_match' [-Wunused-const-variable] The fix is to drop of_match_ptr() which is not necessary because DT is always used for this driver. Fixes: 14485de4 ("usb: Use device_get_match_data()") Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202310131627.M43j234A-lkp@intel.com/Signed-off-by:
Rob Herring <robh@kernel.org> Acked-by:
Peter Chen <peter.chen@kernel.org> Link: https://lore.kernel.org/r/20231019183015.841460-1-robh@kernel.orgSigned-off-by:
-
Tomer Maimon authored
Add Nuvoton NPCM BMC SoCs support to USB ChipIdea driver. NPCM SoC includes ChipIdea IP block that is used for USB device controller mode. Signed-off-by:
Tomer Maimon <tmaimon77@gmail.com> Acked-by:
-
Tomer Maimon authored
Add a compatible string for Nuvoton BMC NPCM750 and Nuvoton BMC NPCM845. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231017195903.1665260-3-tmaimon77@gmail.comSigned-off-by:
-
Tomer Maimon authored
Adding CI_HDRC_FORCE_VBUS_ACTIVE_ALWAYS flag to modify the vbus_active parameter to active in case the ChipIdea USB IP role is device-only and there is no otgsc register. Signed-off-by:
-
Jisheng Zhang authored
The "reset-gpios" is optional in real case, for example reset pin is is hard wired to "high". And this fact is also reflected by the devm_gpio_get_optional() calling in driver code. Signed-off-by:
Jisheng Zhang <jszhang@kernel.org> Acked-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231018150448.1980-1-jszhang@kernel.orgSigned-off-by:
-
Milan Broz authored
Switch internal usb-storage quirk value to 64-bit as quirks currently use all 32 bits. Signed-off-by:
Milan Broz <gmazyland@gmail.com> Reviewed-by:
Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20231016072604.40179-3-gmazyland@gmail.comSigned-off-by:
-
Milan Broz authored
This patch removes macro that was used only by commit that was reverted in commit ab4b7164 ("USB: storage: fix Huawei mode switching regression") Signed-off-by:
-
Wesley Cheng authored
There is a 120ms delay implemented for allowing the XHCI host controller to detect a U3 wakeup pulse. The intention is to wait for the device to retry the wakeup event if the USB3 PORTSC doesn't reflect the RESUME link status by the time it is checked. As per the USB3 specification: tU3WakeupRetryDelay ("Table 7-12. LTSSM State Transition Timeouts") This would allow the XHCI resume sequence to determine if the root hub needs to be also resumed. However, in case there is no device connected, or if there is only a HSUSB device connected, this delay would still affect the overall resume timing. Since this delay is solely for detecting U3 wake events (USB3 specific) then ignore this delay for the disconnected case and the HSUSB connected only case. [skip helper function, rename usb3_connected variable -Mathias ] Signed-off-by:Wesley Cheng <quic_wcheng@quicinc.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20231019102924.2797346-20-mathias.nyman@linux.intel.comSigned-off-by:
-
Sergey Shtylyov authored
If this driver enables the xHC clocks while resuming from sleep, it calls clk_prepare_enable() without checking for errors and blithely goes on to read/write the xHC's registers -- which, with the xHC not being clocked, at least on ARM32 usually causes an imprecise external abort exceptions which cause kernel oops. Currently, the chips for which the driver does the clock dance on suspend/resume seem to be the Broadcom STB SoCs, based on ARM32 CPUs, as it seems... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. Fixes: 8bd954c5 ("usb: host: xhci-plat: suspend and resume clocks") Signed-off-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by:
-
Udipto Goswami authored
In some situations where xhci removal happens parallel to xhci_handshake, we encounter a scenario where the xhci_handshake can't succeed, and it polls until timeout. If xhci_handshake runs until timeout it can on some platforms result in a long wait which might lead to a watchdog timeout. Add a helper that checks xhci status during the handshake, and exits if set state is entered. Use this helper in places where xhci_handshake is called unlocked and has a long timeout. For example xhci command timeout and xhci reset. [commit message and code comment rewording -Mathias] Signed-off-by:
Udipto Goswami <quic_ugoswami@quicinc.com> Signed-off-by:
-
Mathias Nyman authored
The current function that both removes and frees an interrupter isn't optimal when using several interrupters. The array of interrupters need to be protected with a lock while removing interrupters, but the default xhci spin lock can't be used while freeing the interrupters event ring segment table as dma_free_coherent() should be called with IRQs enabled. There is no need to free the interrupter under the lock, so split this code into separate unlocked free part, and a lock protected remove part. Signed-off-by:
-
Basavaraj Natikar authored
Use the low-power states of the underlying platform to enable runtime PM. If the platform doesn't support runtime D3, then enabling default RPM will result in the controller malfunctioning, as in the case of hotplug devices not being detected because of a failed interrupt generation. Cc: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by:
Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by:
-
Basavaraj Natikar authored
The AMD USB host controller (1022:43f7) isn't going into PCI D3 by default without anything connected. This is because the policy that was introduced by commit a611bf47 ("xhci-pci: Set runtime PM as default policy on all xHC 1.2 or later devices") only covered 1.2 or later. The 1.1 specification also has the same requirement as the 1.2 specification for D3 support. So expand the runtime PM as default policy to all AMD 1.1 devices as well. Fixes: a611bf47 ("xhci-pci: Set runtime PM as default policy on all xHC 1.2 or later devices") Link: https://composter.com.ua/documents/xHCI_Specification_for_USB.pdfCo-developed-by:
Mario Limonciello <mario.limonciello@amd.com> Signed-off-by:
-
Mathias Nyman authored
Increase the event ring dequeue pointer for port change events in the same way as other event types. No need to handle it separately. This only touches the driver side tracking of event ring dequeue. Note: this does move forward the event ring dequeue increase for port change events a bit. Previously the dequeue was increased before temporarily dropping the xhci lock while kicking roothub polling. Now dequeue is increased after re-aquiring the lock. This should not matter as event ring dequeue is not touched at all by hub thread. It's only touched in xhci interrupt handler. Signed-off-by:
-
Mathias Nyman authored
No matter what type of event we receive we want to increase the event ring dequeue pointer one step for every event that is handled. For unknown reasons the event ring dequeue increase is done inside the transfer event handler and port event handler. As the transfer event handler got more complex and can now loop through several transfer TRBs on a transfer ring, there were additinal checks added to avoid increasing event ring dequeue more than one step. No need for elaborate checks to avoid increasing event ring dequeue in case the transfer event handler goes through a loop. Just increasing the event ring dequeue outside the transfer event handler. End goal is to increase event ring dequeue in just one place. Signed-off-by:
-
Lukas Wunner authored
xhci_alloc_erst() has global scope even though it's only used in xhci-mem.c. Declare it static. xhci_free_erst() was removed by commit b17a57f8 ("xhci: Refactor interrupter code for initial multi interrupter support."), but a declaration in xhci.h still remains. Drop it. Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
-
Lukas Wunner authored
Commit ebd88cf5 ("xhci: Remove unused defines for ERST_SIZE and ERST_ENTRIES") removed the ERST_SIZE macro but retained a code comment explaining the quantity chosen in the macro. Remove the code comment as well. Signed-off-by:
-
Lukas Wunner authored
Mathias notes that the ERST_PTR_MASK macro is named as if it's masking the Event Ring Dequeue Pointer in the ERDP register, but in actuality it's masking the inverse. Invert the macro's value for clarity. Migrate it to the modern GENMASK_ULL() syntax to avoid u64 casts. Signed-off-by:
-
Lukas Wunner authored
Ring segments have just been amended with a monotonically increasing number. To allow developers to inspect the segment numbers and ensure correctness in particular after ring expansion, expose them in each ring's "trbs" file in debugfs. Signed-off-by:
-
Lukas Wunner authored
When expanding a ring at its "end", ring->last_seg needs to be updated for Event Rings as well, not just for all the other ring types. This is not a fix because ring expansion currently isn't done on the Event Ring. It's just in preparation for when it's added. Signed-off-by:
-
Lukas Wunner authored
Initial xhci_ring allocation has just been amended to assign a monotonically increasing number to each ring segment. However rings may be expanded after initial allocation. So number newly inserted segments starting from the preceding segment in the ring and renumber all segments succeeding the newly inserted ones. This is not a fix because ring expansion currently isn't done on the Event Ring and that's the only ring type using the segment number. It's just in preparation for when either Event Ring expansion is added or when other ring types start making use of the segment number. Signed-off-by:
-
Jonathan Bell authored
Users have reported log spam created by "Event Ring Full" xHC event TRBs. These are caused by interrupt latency in conjunction with a very busy set of devices on the bus. The errors are benign, but throughput will suffer as the xHC will pause processing of transfers until the Event Ring is drained by the kernel. Commit dc0ffbea ("usb: host: xhci: update event ring dequeue pointer on purpose") mitigated the issue by advancing the Event Ring Dequeue Pointer already after half a segment has been processed. Nevertheless, providing a larger Event Ring would be useful to cope with load peaks. Expand the number of event TRB slots available by increasing the number of Event Ring segments in the ERST. Controllers have a hardware-defined limit as to the number of ERST entries they can process, but with up to 32k it can be excessively high (sec 5.3.4). So cap the actual number at 2 (configurable through the ERST_MAX_SEGS macro), which seems like a reasonable quantity. It is supported by any xHC because the limit in the HCSPARAMS2 register is defined as a power of 2. Renesas uPD720201 and VIA VL805 controllers do not support more than 2 ERST entries. An alternative to increasing the number of Event Ring segments would be an increase of the segment size. But that requires allocating multiple contiguous pages, which may be impossible if memory is fragmented. Signed-off-by:
Jonathan Bell <jonathan@raspberrypi.com> Signed-off-by:
-
Lukas Wunner authored
When using more than one Event Ring segment (ERSTSZ > 1), software shall set the DESI bits in the ERDP register to the number of the segment to which the upper ERDP bits are pointing. The xHC may use the DESI bits as a shortcut to determine whether it needs to check for an Event Ring Full condition: If it's enqueueing events in a different segment, it need not compare its internal Enqueue Pointer with the Dequeue Pointer in the upper bits of the ERDP register (sec 5.5.2.3.3). Not setting the DESI bits correctly can result in the xHC enqueueing events past the Dequeue Pointer. On Renesas uPD720201 host controllers, incorrect DESI bits cause an interrupt storm. For comparison, VIA VL805 host controllers do not exhibit such problems. Perhaps they do not take advantage of the optimization afforded by the DESI bits. To fix the issue, assign the segment number to each struct xhci_segment in xhci_segment_alloc(). When advancing the Dequeue Pointer in xhci_update_erst_dequeue(), write the segment number to the DESI bits. On driver probe, set the DESI bits to zero in xhci_set_hc_event_deq() as processing starts in segment 0. Likewise on driver teardown, clear the DESI bits to zero in xhci_free_interrupter() when clearing the upper bits of the ERDP register. Previously those functions (incorrectly) treated the DESI bits as if they're declared RsvdP. Signed-off-by:
-
Mathias Nyman authored
The next_trb() helper relies on a link TRB at the end of a ring segment to know a segment ends. This works well with transfer rings that use link trbs, but not with event rings. Event rings segments are always filled by host to segment size before moving to next segment. It does not use link TRBs Check for both link trb and full segment in next_trb() helper to support event rings. Useful if several interrupters with several event rings are supported. Signed-off-by:
-
Mathias Nyman authored
With several xhci controllers active at the same time its hard to keep track of ports without knowing bus number Signed-off-by:
-
Mathias Nyman authored
We want to trace other port structure members than just port number so pass entire port structure as parameter instead of just port number. Dig the port number from the port structure. Signed-off-by:
-
- 16 Oct, 2023 5 commits
-
-
Fabio Estevam authored
On a i.MX8QXP MEK board that has an NXP CBDTU02043 mux, there is no mode-switch support, only orientation switch. Make the 'mode-switch' property a non-required one. Signed-off-by:
Fabio Estevam <festevam@denx.de> Acked-by:
-
Heikki Krogerus authored
The Type-C port drivers can make PM related decisions based on is the device USB3 or USB2. Suggested-by:
Benson Leung <bleung@chromium.org> Tested-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20231011105825.320062-3-heikki.krogerus@linux.intel.comSigned-off-by:
-
Heikki Krogerus authored
Adding functions that USB hub code can use to inform the Type-C class about connected USB devices. Once taken into use, it will allow the Type-C port drivers to power off components that are not needed, for example if USB2 device is enumerated, everything that is only relevant for USB3 (retimers, etc.), can be powered off. This will also create a symlink "typec" for the USB devices pointing to the USB Type-C partner device. Suggested-by:
-
Hongren Zheng authored
.data of platform_device_info will be copied into .platform_data of struct device via platform_device_add_data. However, vhcis[i] contains a spinlock, is dynamically allocated and used by other code, so it is not meant to be copied. The workaround was to use void *vhci as an agent, but it was removed in the commit suggested below. This patch adds back the workaround and changes the way of using platform_data accordingly. Reported-by: syzbot+e0dbc33630a092ccf033@syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/00000000000029242706077f3145@google.com/ Reported-by: syzbot+6867a9777f4b8dc4e256@syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/0000000000007634c1060793197c@google.com/ Fixes: b8aaf639 ("usbip: Use platform_device_register_full()") Tested-by: syzbot+6867a9777f4b8dc4e256@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/0000000000007ac87d0607979b6b@google.com/Signed-off-by:
Hongren Zheng <i@zenithal.me> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/ZSpHPCaQ5DDA9Ysl@SunSigned-off-by:
-
Greg Kroah-Hartman authored
We need the USB and Thunderbolt fixes in here as well. Signed-off-by:
-
- 15 Oct, 2023 3 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
This reverts commit 45e34c8a, and the two subsequent fixes to it: 3f874c9b ("x86/smp: Don't send INIT to non-present and non-booted CPUs") b1472a60 ("x86/smp: Don't send INIT to boot CPU") because it seems to result in hung machines at shutdown. Particularly some Dell machines, but Thomas says "The rest seems to be Lenovo and Sony with Alderlake/Raptorlake CPUs - at least that's what I could figure out from the various bug reports. I don't know which CPUs the DELL machines have, so I can't say it's a pattern. I agree with the revert for now" Ashok Raj chimes in: "There was a report (probably this same one), and it turns out it was a bug in the BIOS SMI handler. The client BIOS's were waiting for the lowest APICID to be the SMI rendevous master. If this is MeteorLake, the BSP wasn't the one with the lowest APIC and it triped here. The BIOS change is also being pushed to others for assimilation :) Server BIOS's had this correctly for a while now" and it does look likely to be some bad interaction between SMI and the non-BSP cores having put into INIT (and thus unresponsive until reset). Link: https://bbs.archlinux.org/viewtopic.php?pid=2124429 Link: https://www.reddit.com/r/openSUSE/comments/16qq99b/tumbleweed_shutdown_did_not_finish_completely/ Link: https://forum.artixlinux.org/index.php/topic,5997.0.html Link: https://bugzilla.redhat.com/show_bug.cgi?id=2241279Acked-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Ashok Raj <ashok.raj@intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Xuan Zhuo authored
Commit 295525e2 ("virtio_net: merge dma operations when filling mergeable buffers") unmaps the buffer with DMA_ATTR_SKIP_CPU_SYNC when the dma->ref is zero. We do that with DMA_ATTR_SKIP_CPU_SYNC, because we do not want to do the sync for the entire page_frag. But that misses the sync for the current area. This patch does cpu sync regardless of whether the ref is zero or not. Fixes: 295525e2 ("virtio_net: merge dma operations when filling mergeable buffers") Reported-by:
Michael Roth <michael.roth@amd.com> Closes: http://lore.kernel.org/all/20230926130451.axgodaa6tvwqs3ut@amd.comSigned-off-by:
Xuan Zhuo <xuanzhuo@linux.alibaba.com> Acked-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
-
