aboutsummaryrefslogtreecommitdiff
path: root/drivers/usb
AgeCommit message (Collapse)AuthorFilesLines
2020-09-21Merge 5.0-rc6 into usb-nextGreg Kroah-Hartman7-11/+36
We want the USB fixes in here, and this resolves a merge issue in the uas driver. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-20usb: xhci: add debugfs support for ep with streamLi Jun3-1/+119
To show the trb ring of streams, use the exsiting ring files of bulk ep to show trb ring of one specific stream ID, which stream ID's trb ring will be shown, is controlled by a new debugfs file stream_id, this is to avoid to create a large number of dir for every allocate stream IDs, another debugfs file stream_context_array is created to show all the allocated stream context array entries. Signed-off-by: Li Jun <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-20xhci: don't create endpoint debugfs entry before ring buffer is set.Mathias Nyman1-2/+1
Make sure xHC completes the configure endpoint command and xhci driver sets the ring pointers correctly before we create the user readable debugfs file. In theory there was a small gap where a user could have read the debugfs file and cause a NULL pointer dereference error as ring pointer was not yet set, in practise we want this change to simplify the upcoming streams debugfs support. Fixes: 02b6fdc2a153 ("usb: xhci: Add debugfs interface for xHCI driver") Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-20xhci: Tune interrupt blocking for isochronous transfersMathias Nyman1-4/+19
controllers with XHCI_AVOID_BEI quirk cause too frequent interrupts and affect power management. To avoid interrupting on every isochronous interval the BEI (Block Event Interrupt) flag is set for all except the last Isoch TRB in a URB. This lead to event ring filling up in case several isoc URB were queued and cancelled rapidly, which some controllers didn't handle well, and thus the XHCI_AVOID_BEI quirk was introduced. see commit 227a4fd801c8 ("usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers") With the XHCI_AVOID_BEI quirk each Isoch TRB will trigger an interrupt. This can cause up to 8000 interrupts per second for isochronous transfers with HD USB3 cameras, affecting power saving. The event ring fits 256 events, instead of interrupting on every isochronous TRB if XHCI_AVOID_BEI is set we make sure at least every 8th Isochronous TRB asserts an interrupt, clearing the event ring. Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-20usb: xhci: omit duplicate actions when suspending a runtime suspended host.Peter Chen1-2/+5
If the xhci-plat.c is the platform driver, after the runtime pm is enabled, the xhci_suspend is called if nothing is connected on the port. When the system goes to suspend, it will call xhci_suspend again if USB wakeup is enabled. Since the runtime suspend wakeup setting is not always the same as system suspend wakeup setting, eg, at runtime suspend we always need wakeup if the controller is in low power mode; but at system suspend, we may not need wakeup. So, we move the judgement after changing wakeup setting. [commit message rewording -Mathias] Reviewed-by: Jun Li <[email protected]> Signed-off-by: Peter Chen <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-20usb: host: xhci-plat: improve the comments for xhci_plat_suspendPeter Chen1-5/+1
To reflect the current code status. Signed-off-by: Peter Chen <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-20usb: host: xhci-plat: add wakeup entry at sysfsPeter Chen1-1/+1
With this change, there will be a wakeup entry at /sys/../power/wakeup, and the user could use this entry to choose whether enable xhci wakeup features (wake up system from suspend) or not. Tested-by: Matthias Kaehlcke <[email protected]> Reviewed-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Peter Chen <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-20usb: host: xhci-plat: add priv quirk for skip PHY initializationPeter Chen2-2/+7
Some DRD controllers (eg, dwc3 & cdns3) have PHY management at their own driver to cover both device and host mode, so add one priv quirk for such users to skip PHY management from HCD core. Reviewed-by: Jun Li <[email protected]> Signed-off-by: Peter Chen <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-20usb: host: xhci-plat: delete the unnecessary codePeter Chen1-2/+1
The if {} condition is duplicated with outer if {} condition. Reviewed-by: Jun Li <[email protected]> Signed-off-by: Peter Chen <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-20usb: host: xhci-plat: add .suspend_quirk for struct xhci_plat_privPeter Chen2-0/+20
Some platforms (eg cdns3) may have special sequences between xhci_bus_suspend and xhci_suspend, add .suspend_quick for it. Reviewed-by: Jun Li <[email protected]> Signed-off-by: Peter Chen <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-20usb: host: xhci-plat: add platform data supportPeter Chen1-1/+5
Some xhci hosts (eg dwc3 and cdns3) do not use OF to create platform device, they create xhci-plat platform device runtime. And these platforms may also have quirks, and the quirks could be supplied by their parent device through platform data. Reviewed-by: Jun Li <[email protected]> Signed-off-by: Peter Chen <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-17USB: cdc-acm: cleanup of data structuresOliver Neukum2-9/+10
Buffers should be u8*, not unsigned char* Buffers have an unsigned length and using an int as a boolean is a bit outdated. No functional change intended. Signed-off-by: Oliver Neukum <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-17USB: adutux: fix debuggingOliver Neukum1-0/+1
Handling for removal of the controller was missing at one place. Add it. Signed-off-by: Oliver Neukum <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-17usblp: fix race between disconnect() and read()Oliver Neukum1-0/+5
read() needs to check whether the device has been disconnected before it tries to talk to the device. Signed-off-by: Oliver Neukum <[email protected]> Reported-by: [email protected] Link: https://lore.kernel.org/r/[email protected] Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-17usb: don't inherity DMA properties for USB devicesChristoph Hellwig2-18/+0
As the comment in usb_alloc_dev correctly states, drivers can't use the DMA API on usb device, and at least calling dma_set_mask on them is highly dangerous. Unlike what the comment states upper level drivers also can't really use the presence of a dma mask to check for DMA support, as the dma_mask is set by default for most busses. Setting the dma_mask comes from "[PATCH] usbcore dma updates (and doc)" in BitKeeper times, as it seems like it was primarily for setting the NETIF_F_HIGHDMA flag in USB drivers, something that has long been fixed up since. Setting the dma_pfn_offset comes from commit b44bbc46a8bb ("usb: core: setup dma_pfn_offset for USB devices and, interfaces"), which worked around the fact that the scsi_calculate_bounce_limits functions wasn't going through the proper driver interface to query DMA information, but that function was removed in commit 21e07dba9fb1 ("scsi: reduce use of block bounce buffers") years ago. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]>
2020-09-17ehci-hcd: Move include to keep CRC stableQuentin Perret2-1/+1
The CRC calculation done by genksyms is triggered when the parser hits EXPORT_SYMBOL*() macros. At this point, genksyms recursively expands the types of the function parameters, and uses that as the input for the CRC calculation. In the case of forward-declared structs, the type expands to 'UNKNOWN'. Following this, it appears that the result of the expansion of each type is cached somewhere, and seems to be re-used when/if the same type is seen again for another exported symbol in the same C file. Unfortunately, this can cause CRC 'stability' issues when a struct definition becomes visible in the middle of a C file. For example, let's assume code with the following pattern: struct foo; int bar(struct foo *arg) { /* Do work ... */ } EXPORT_SYMBOL_GPL(bar); /* This contains struct foo's definition */ #include "foo.h" int baz(struct foo *arg) { /* Do more work ... */ } EXPORT_SYMBOL_GPL(baz); Here, baz's CRC will be computed using the expansion of struct foo that was cached after bar's CRC calculation ('UNKOWN' here). But if EXPORT_SYMBOL_GPL(bar) is removed from the file (because of e.g. symbol trimming using CONFIG_TRIM_UNUSED_KSYMS), struct foo will be expanded late, during baz's CRC calculation, which now has visibility over the full struct definition, hence resulting in a different CRC for baz. The proper fix for this certainly is in genksyms, but that will take me some time to get right. In the meantime, we have seen one occurrence of this in the ehci-hcd code which hits this problem because of the way it includes C files halfway through the code together with an unlucky mix of symbol trimming. In order to workaround this, move the include done in ehci-hub.c early in ehci-hcd.c, hence making sure the struct definitions are visible to the entire file. This improves CRC stability of the ehci-hcd exports even when symbol trimming is enabled. Acked-by: Alan Stern <[email protected]> Cc: stable <[email protected]> Signed-off-by: Quentin Perret <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-16usb: typec: intel_pmc_mux: Handle SCU IPC error conditionsMadhusudanarao Amara1-3/+9
Check and return if there are errors. The response bits are valid only on no errors. Fixes: b7404a29cd3d ("usb: typec: intel_pmc_mux: Definitions for response status bits") Signed-off-by: Madhusudanarao Amara <[email protected]> Signed-off-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-16USB: quirks: Add USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk for BYD zhaoxin notebookPenghao1-0/+4
Add a USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk for the BYD zhaoxin notebook. This notebook come with usb touchpad. And we would like to disable touchpad wakeup on this notebook by default. Signed-off-by: Penghao <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-16usb: dwc2: Always disable regulators on driver teardownMarc Zyngier1-4/+13
If the dwc2 driver fails to probe after having enabled the regulators, it ends up being unregistered with regulators enabled, something the core regulator code is legitimately upset about: dwc2 ff400000.usb: supply vusb_d not found, using dummy regulator dwc2 ff400000.usb: supply vusb_a not found, using dummy regulator dwc2 ff400000.usb: dwc2_core_reset: HANG! AHB Idle timeout GRSTCTL GRSTCTL_AHBIDLE WARNING: CPU: 2 PID: 112 at drivers/regulator/core.c:2074 _regulator_put.part.0+0x16c/0x174 Modules linked in: dwc2(E+) dwc3(E) udc_core(E) rtc_hym8563(E) dwmac_generic(E) ulpi(E) usbcore(E) dwc3_meson_g12a(E) roles(E) meson_gx_mmc(E+) i2c_meson(E) mdio_mux_meson_g12a(E) mdio_mux(E) dwmac_meson8b(E) stmmac_platform(E) stmmac(E) mdio_xpcs(E) phylink(E) of_mdio(E) fixed_phy(E) libphy(E) pwm_regulator(E) fixed(E) CPU: 2 PID: 112 Comm: systemd-udevd Tainted: G E 5.9.0-rc4-00102-g423583bc8cf9 #1840 Hardware name: amlogic w400/w400, BIOS 2020.04 05/22/2020 pstate: 80400009 (Nzcv daif +PAN -UAO BTYPE=--) pc : _regulator_put.part.0+0x16c/0x174 lr : regulator_bulk_free+0x6c/0x9c sp : ffffffc012353820 x29: ffffffc012353820 x28: ffffff805a4b7000 x27: ffffff8059c2eac0 x26: ffffff8059c2e810 x25: ffffff805a4b7d00 x24: ffffffc008cf3028 x23: ffffffc011729ef8 x22: ffffff807e2761d8 x21: ffffffc01171df78 x20: ffffff805a4b7700 x19: ffffff805a4b7700 x18: 0000000000000030 x17: 0000000000000000 x16: 0000000000000000 x15: ffffff807ea8d178 x14: 3935312820435455 x13: 2038323a36313a37 x12: ffffffffffffffff x11: 0000000000000040 x10: 0000000000000007 x9 : ffffffc0106f77d0 x8 : ffffffffffffffe0 x7 : ffffffffffffffff x6 : 0000000000017702 x5 : ffffff805a4b7400 x4 : 0000000000000000 x3 : ffffffc01171df78 x2 : ffffff807ea8cc40 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: _regulator_put.part.0+0x16c/0x174 regulator_bulk_free+0x6c/0x9c devm_regulator_bulk_release+0x28/0x3c release_nodes+0x1c8/0x2c0 devres_release_all+0x44/0x6c really_probe+0x1ec/0x504 driver_probe_device+0x100/0x170 device_driver_attach+0xcc/0xd4 __driver_attach+0xb0/0x17c bus_for_each_dev+0x7c/0xd4 driver_attach+0x30/0x3c bus_add_driver+0x154/0x250 driver_register+0x84/0x140 __platform_driver_register+0x54/0x60 dwc2_platform_driver_init+0x2c/0x1000 [dwc2] do_one_initcall+0x54/0x2d0 do_init_module+0x68/0x29c In order to fix this, tie the regulator disabling to the teardown process by registering a devm action callback. This makes sure that the regulators are disabled at the right time (just before they are released). Cc: Minas Harutyunyan <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-16usb: typec: tcpci: update ROLE_CONTROL for DRPBadhri Jagan Sridharan1-1/+36
ROLE_CONTROL register would not have the actual CC terminations unless the port does not set ROLE_CONTROL.DRP. For DRP ports, CC_STATUS.cc1/cc2 indicates the final terminations applied when TCPC enters potential_connect_as_source/_sink. For DRP ports, infer port role from CC_STATUS and set corresponding CC terminations before setting the orientation. Reviewed-by: Heikki Krogerus <[email protected]> Signed-off-by: Badhri Jagan Sridharan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-16usb: typec: tcpci: Add support when hidden tx registers are inaccessibleBadhri Jagan Sridharan2-11/+43
TCPCI spec forbids direct access of TX_BUF_BYTE_x register. The existing version of tcpci driver assumes that those registers are directly addressible. Add support for tcpci chips which do not support direct access to TX_BUF_BYTE_x registers. TX_BUF_BYTE_x can only be accessed by I2C_WRITE_BYTE_COUNT. Reviewed-by: Heikki Krogerus <[email protected]> Signed-off-by: Badhri Jagan Sridharan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-16usb: typec: tcpci: Add register definitions to tcpciBadhri Jagan Sridharan1-0/+5
Add register definitions to trap extended alerts. Reviewed-by: Heikki Krogerus <[email protected]> Signed-off-by: Badhri Jagan Sridharan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-16USB: UAS: use macro for reporting resultsOliver Neukum1-6/+6
The SCSI layer has introduced a new macro for recording the result of a command. Use it. Signed-off-by: Oliver Neukum <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-16USB: UAS: fix disconnect by unplugging a hubOliver Neukum1-2/+12
The SCSI layer can go into an ugly loop if you ignore that a device is gone. You need to report an error in the command rather than in the return value of the queue method. We need to specifically check for ENODEV. The issue goes back to the introduction of the driver. Fixes: 115bb1ffa54c3 ("USB: Add UAS driver") Signed-off-by: Oliver Neukum <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-16usb: typec: intel_pmc_mux: Pass correct USB Type-C port number to SoCAzhar Shaikh1-1/+6
The SoC expects the USB Type-C ports numbers to be starting with 0. If the port number is passed as it is, the IOM status will not be updated. The IOM port status check fails which will eventually lead to PMC IPC communication failure. Fixes: 43d596e32276 ("usb: typec: intel_pmc_mux: Check the port status before connect") Suggested-by: Utkarsh Patel <[email protected]> Signed-off-by: Azhar Shaikh <[email protected]> Signed-off-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-16usb: typec: intel_pmc_mux: Add dependency on ACPIHeikki Krogerus1-0/+1
Since the driver now needs to find the IOM ACPI node, the driver depends on ACPI. Without the dependency set, the driver will only fail to compile when ACPI is not enabled. Fixes: 43d596e32276 ("usb: typec: intel_pmc_mux: Check the port status before connect") Reported-by: Randy Dunlap <[email protected]> Signed-off-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-16USB: microtek: use set_host_byte()Oliver Neukum1-7/+7
The SCSI layer is providing a new macro. Let's use it. Signed-off-by: Oliver Neukum <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-16USB: UAS: fix disconnect by unplugging a hubOliver Neukum1-2/+12
The SCSI layer can go into an ugly loop if you ignore that a device is gone. You need to report an error in the command rather than in the return value of the queue method. We need to specifically check for ENODEV. The issue goes back to the introduction of the driver. Fixes: 115bb1ffa54c3 ("USB: Add UAS driver") Signed-off-by: Oliver Neukum <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-16usb: typec: ucsi: Prevent mode overrunHeikki Krogerus1-6/+16
Sometimes the embedded controller firmware does not terminate the list of alternate modes that the partner supports in its response to the GET_ALTERNATE_MODES command. Instead the firmware returns the supported alternate modes over and over again until the driver stops requesting them. If that happens, the number of modes for each alternate mode will exceed the maximum 6 that is defined in the USB Power Delivery specification. Making sure that can't happen by adding a check for it. This fixes NULL pointer dereference that is caused by the overrun. Fixes: ad74b8649beaf ("usb: typec: ucsi: Preliminary support for alternate modes") Cc: [email protected] Reported-by: Zwane Mwaikambo <[email protected]> Signed-off-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-16usb: typec: ucsi: acpi: Increase command completion timeout valueHeikki Krogerus1-1/+1
UCSI specification quite clearly states that if a command can't be completed in 10ms, the firmware must notify about BUSY condition. Unfortunately almost none of the platforms (the firmware on them) generate the BUSY notification even if a command can't be completed in time. The driver already considered that, and used a timeout value of 5 seconds, but processing especially the alternate mode discovery commands takes often considerable amount of time from the firmware, much more than the 5 seconds. That happens especially after bootup when devices are already connected to the USB Type-C connector. For now on those platforms the alternate mode discovery has simply failed because of the timeout. To improve the situation, increasing the timeout value for the command completion to 1 minute. That should give enough time for even the slowest firmware to process the commands. Fixes: f56de278e8ec ("usb: typec: ucsi: acpi: Move to the new API") Cc: [email protected] Signed-off-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-16USB: legousbtower: use usb_control_msg_recv()Greg Kroah-Hartman1-41/+19
The usb_control_msg_recv() function can handle data on the stack, as well as properly detecting short reads, so move to use that function instead of the older usb_control_msg() call. This ends up removing a lot of extra lines in the driver. Cc: Juergen Stuber <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-16USB: core: hub.c: use usb_control_msg_send() in a few placesGreg Kroah-Hartman1-59/+40
There are a few calls to usb_control_msg() that can be converted to use usb_control_msg_send() instead, so do that in order to make the error checking a bit simpler and the code smaller. Reviewed-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-16USB: core: message.c: use usb_control_msg_send() in a few placesGreg Kroah-Hartman1-19/+19
There are a few calls to usb_control_msg() that can be converted to use usb_control_msg_send() instead, so do that in order to make the error checking a bit simpler. Cc: Alan Stern <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-16USB: add usb_control_msg_send() and usb_control_msg_recv()Greg Kroah-Hartman1-0/+133
New core functions to make sending/receiving USB control messages easier and saner. In discussions, it turns out that the large majority of users of usb_control_msg() do so in potentially incorrect ways. The most common issue is where a "short" message is received, yet never detected properly due to "incorrect" error handling. Handle all of this in the USB core with two new functions to try to make working with USB control messages simpler. No more need for dynamic data, messages can be on the stack, and only "complete" send/receive will work without causing an error. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-16USB: move snd_usb_pipe_sanity_check into the USB coreGreg Kroah-Hartman1-8/+23
snd_usb_pipe_sanity_check() is a great function, so let's move it into the USB core so that other parts of the kernel, including the USB core, can call it. Name it usb_pipe_type_check() to match the existing usb_urb_ep_type_check() call, which now uses this function. Cc: Jaroslav Kysela <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Cc: Eli Billauer <[email protected]> Cc: Emiliano Ingrassia <[email protected]> Cc: Alan Stern <[email protected]> Cc: Alexander Tsoy <[email protected]> Cc: "Geoffrey D. Bennett" <[email protected]> Cc: Jussi Laako <[email protected]> Cc: Nick Kossifidis <[email protected]> Cc: Dmitry Panchenko <[email protected]> Cc: Chris Wulff <[email protected]> Cc: Jesus Ramos <[email protected]> Reviewed-by: Takashi Iwai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-16usbip: simplify the return expression of usbip_core_init()Liu Shixin1-7/+1
Simplify the return expression. Acked-by: Shuah Khan <[email protected]> Signed-off-by: Liu Shixin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-16usb typec: mt6360: Add support for mt6360 Type-C driverChiYuan Huang3-0/+221
Mediatek MT6360 is a multi-functional IC that includes USB Type-C. It works with Type-C Port Controller Manager to provide USB PD and USB Type-C functionalities. Reviewed-by: Heikki Krogerus <[email protected]> Signed-off-by: ChiYuan Huang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-14usb: phy: phy-ab8500-usb: fix spello of "function"Randy Dunlap1-1/+1
Fix typo/spello of "function". Cc: Felipe Balbi <[email protected]> Cc: Jiri Kosina <[email protected]> Signed-off-by: Randy Dunlap <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-14usb: host: ehci-sched: Remove ununsed function tt_start_uframe()YueHaibing1-20/+0
commit b35c5009bbf6 ("USB: EHCI: create per-TT bandwidth tables") left behind this, remove it. Acked-by: Alan Stern <[email protected]> Signed-off-by: YueHaibing <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-14usb: ohci: Make distrust_firmware param default to falseHamish Martin1-1/+1
The 'distrust_firmware' module parameter dates from 2004 and the USB subsystem is a lot more mature and reliable now than it was then. Alter the default to false now. Suggested-by: Alan Stern <[email protected]> Acked-by: Alan Stern <[email protected]> Signed-off-by: Hamish Martin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-14usb: ohci: Default to per-port over-current protectionHamish Martin1-6/+10
Some integrated OHCI controller hubs do not expose all ports of the hub to pins on the SoC. In some cases the unconnected ports generate spurious over-current events. For example the Broadcom 56060/Ranger 2 SoC contains a nominally 3 port hub but only the first port is wired. Default behaviour for ohci-platform driver is to use global over-current protection mode (AKA "ganged"). This leads to the spurious over-current events affecting all ports in the hub. We now alter the default to use per-port over-current protection. This patch results in the following configuration changes depending on quirks: - For quirk OHCI_QUIRK_SUPERIO no changes. These systems remain set up for ganged power switching and no over-current protection. - For quirk OHCI_QUIRK_AMD756 or OHCI_QUIRK_HUB_POWER power switching remains at none, while over-current protection is now guaranteed to be set to per-port rather than the previous behaviour where it was either none or global over-current protection depending on the value at function entry. Suggested-by: Alan Stern <[email protected]> Acked-by: Alan Stern <[email protected]> Signed-off-by: Hamish Martin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-14usb: host: ehci-platform: Add workaround for brcm, xgs-iproc-ehciChris Packham1-0/+8
The ehci controller found in some Broadcom switches with integrated SoCs has an issue which causes a soft lockup with large transfers like you see when running ext4 on USB3 flash drive. Port the fix from the Broadcom XLDK to increase the OUT_THRESHOLD to avoid the problem. Acked-by: Alan Stern <[email protected]> Signed-off-by: Chris Packham <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-14Merge 5.9-rc5 into usb-nextGreg Kroah-Hartman8-78/+75
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-14Merge 5.9-rc5 into driver-core-nextGreg Kroah-Hartman55-281/+492
We need the driver core changes in here as well. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-13Merge tag 'samsung-soc-s3c-5.10' of ↵Olof Johansson4-74/+162
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/soc Samsung S3C24xx and S3C64xx machine code cleanup for v5.10 Big cleanup for the Samsung S3C24xx and S3C64xx platforms, although it also touches files shared with S5Pv210 and Exynos. This is mostly Arnd Bergmann work which Krzysztof Kozlowski took over, rebased and polished. The goal is to cleanup, merge and finally make the Samsung S3C24xx and S3C64xx architectures multiplatform. The multiplatform did not happen yet here - just cleaning up and merging into one arch/arm/mach-s3c directory. However this is step forward for multiplatform or at least to keep this code still maintainable. This pulls also branch with changes for Samsung SoC sound drivers from broonie/sound because the cleanups there were part of this series and all further patches depend on them. * tag 'samsung-soc-s3c-5.10' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: (62 commits) ARM: s3c: Avoid naming clash of S3C24xx and S3C64xx timer setup ARM: s3c: Cleanup from old plat-samsung include ARM: s3c: make headers local if possible ARM: s3c: move into a common directory ARM: s3c24xx: stop including mach/hardware.h from mach/io.h cpufreq: s3c24xx: move low-level clk reg access into platform code cpufreq: s3c2412: use global s3c2412_cpufreq_setrefresh ARM: s3c: remove cpufreq header dependencies cpufreq: s3c24xx: split out registers fbdev: s3c2410fb: remove mach header dependency ARM: s3c24xx: bast: avoid irq_desc array usage ARM: s3c24xx: spi: avoid hardcoding fiq number in driver ARM: s3c24xx: include mach/irqs.h where needed ARM: s3c24xx: move s3cmci pinctrl handling into board files ARM: s3c24xx: move iis pinctrl config into boards ARM: s3c24xx: move spi fiq handler into platform ARM: s3c: adc: move header to linux/soc/samsung ARM: s3c24xx: move irqchip driver back into platform ARM: s3c24xx: move regs-spi.h into spi driver ARM: s3c64xx: remove mach/hardware.h ... Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Olof Johansson <[email protected]>
2020-09-08Merge tag 'usb-serial-5.9-rc5' of ↵Greg Kroah-Hartman3-8/+16
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB-serial fixes for 5.9-rc5 Here are some new device ids for 5.9. All have been in linux-next with no reported issues. * tag 'usb-serial-5.9-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: option: support dynamic Quectel USB compositions USB: serial: option: add support for SIM7070/SIM7080/SIM7090 modules USB: serial: ftdi_sio: add IDs for Xsens Mti USB converter
2020-09-07usb: typec: intel_pmc_mux: Support for device role (UFP)Heikki Krogerus1-33/+35
This adds support for device data role, and data role swapping. The driver no longer relies on the cached role, as it may not be valid (for example after bootup). Instead, the role is always checked by readding the port status from IOM. Note. After this, the orientation is always only cached, so the driver does not support scenario where the role is set before orientation. It means the typec drivers must always set the orientation first before role. Signed-off-by: Heikki Krogerus <[email protected]> Reviewed-by: Rajmohan Mani <[email protected]> Reviewed-by: Utkarsh Patel <[email protected]> Tested-by: Utkarsh Patel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-07usb: typec: intel_pmc_mux: Check the port status before connectHeikki Krogerus1-11/+141
The PMC microcontroller that we use for configuration, does not supply any status information back. For port status we need to talk to another controller on the board called IOM (I/O manager). By checking the port status before configuring the muxes, we can make sure that we do not reconfigure the port after bootup when the system firmware (for example BIOS) has already configured it. Using the status information also to check if DisplayPort HPD is still asserted when the cable plug is disconnected, and clearing it if it is. Signed-off-by: Heikki Krogerus <[email protected]> Reviewed-by: Rajmohan Mani <[email protected]> Reviewed-by: Utkarsh Patel <[email protected]> Tested-by: Utkarsh Patel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-07usb: typec: intel_pmc_mux: Do not configure SBU and HSL Orientation in ↵Utkarsh Patel1-8/+0
Alternate modes According to the PMC Type C Subsystem (TCSS) Mux programming guide rev 0.7, bits 4 and 5 are reserved in Alternate modes. SBU Orientation and HSL Orientation needs to be configured only during initial cable detection in USB connect flow based on device property of "sbu-orientation" and "hsl-orientation". Configuring these reserved bits in the Alternate modes may result in delay in display link training or some unexpected behaviour. So do not configure them while issuing Alternate Mode requests. Fixes: ff4a30d5e243 ("usb: typec: mux: intel_pmc_mux: Support for static SBU/HSL orientation") Signed-off-by: Utkarsh Patel <[email protected]> Cc: stable <[email protected]> Signed-off-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-07usb: typec: intel_pmc_mux: Do not configure Altmode HPD HighUtkarsh Patel1-4/+0
According to the PMC Type C Subsystem (TCSS) Mux programming guide rev 0.7, bit 14 is reserved in Alternate mode. In DP Alternate Mode state, if the HPD_STATE (bit 7) field in the status update command VDO is set to HPD_HIGH, HPD is configured via separate HPD mode request after configuring DP Alternate mode request. Configuring reserved bit may show unexpected behaviour. So do not configure them while issuing the Alternate Mode request. Fixes: 7990be48ef4d ("usb: typec: mux: intel: Handle alt mode HPD_HIGH") Cc: [email protected] Signed-off-by: Utkarsh Patel <[email protected]> Signed-off-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.