- 25 Apr, 2018 6 commits
-
-
Adam Thomson authored
This commit adds the 'usb_type' property to represent USB supplies which can report a number of different types based on a connection event. Examples of this already exist in drivers whereby the existing 'type' property is updated, based on an event, to represent what was connected (e.g. USB, USB_DCP, USB_ACA, ...). Current implementations however don't show all supported connectable types, so this knowledge has to be exlicitly known for each driver that supports this. The 'usb_type' property is intended to fill this void and show users all possible USB types supported by a driver. The property, when read, shows all available types for the driver, and the one currently chosen is highlighted/bracketed. It is expected that the 'type' property would then just show the top-level type 'USB', and this would be static. Currently the 'usb_type' enum contains all of the USB variant types that exist for the 'type' enum at this time, and in addition has SDP and PPS types. The mirroring is intentional so as to not impact existing usage of the 'type' property. Signed-off-by:
Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by:
Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Adam Thomson authored
Currently there's no error checking of this parameter in the registration function and it's blindly added to psy class and subsequently used as is. For example if this is NULL the call to psy_register_thermal() will try to dereference the pointer thus causing a kernel dump. This commit updates the registration code to add some basic checks on the desc pointer validity, name, and presence of properties. Signed-off-by:
-
Adam Thomson authored
This commit adds generic ABI information regarding power_supply properties. This is an initial attempt to try and align the usage of these properties between drivers. As part of this commit, common Battery and USB related properties have been listed. Signed-off-by:
-
Adam Thomson authored
This commit adds code to handle requesting of PPS APDOs. Switching between standard PDOs and APDOs, and re-requesting an APDO to modify operating voltage/current will be triggered by an external call into TCPM. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Yossi Mansharoff authored
The chipidea usb controller may be connected, in some platforms, to an external mux to toggle between different usb ports for different roles (host and device). The mux-controller property, if set, binds the chipidea usb controller with a mux for this use. Signed-off-by:
Yossi Mansharoff <yossim@codeaurora.org> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Maxim Moseychuk authored
Some low-speed and full-speed devices (for example, bluetooth) do not have time to initialize. For them, ETIMEDOUT is a valid error. We need to give them another try. Otherwise, they will never be initialized correctly and in dmesg will be messages "Bluetooth: hci0 command 0x1002 tx timeout" or similars. Fixes: 264904cc ("usb: retry reset if a device times out") Cc: stable <stable@vger.kernel.org> Signed-off-by:
Maxim Moseychuk <franchesko.salias.hudro.pedros@gmail.com> Signed-off-by:
-
- 23 Apr, 2018 4 commits
-
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 1468266 ("Missing break in switch") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Dmitry Osipenko authored
Tegra's EHCI driver has a build dependency on Tegra's PHY driver and currently Tegra's PHY driver is built only when Tegra's EHCI driver is built. Add own Kconfig entry for the Tegra's PHY driver so that drivers other than ehci-tegra (like ChipIdea UDC) could work with ehci-tegra driver being disabled in kernels config by allowing user to manually select the PHY driver. Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Signed-off-by:
-
Dmitry Osipenko authored
UTMI pads are shared by USB controllers and reset of UTMI pads is shared with the reset of USB1 controller. Currently reset of UTMI pads is done by the EHCI driver and ChipIdea UDC works because EHCI driver always happen to be probed first. Move reset controls from ehci-tegra to tegra-phy in order to resolve the problem. Signed-off-by:
-
Dmitry Osipenko authored
Tegra's PHY driver has a mix of pr_err() and dev_err(), let's switch to dev_err() and use common errors message formatting across the driver for consistency. Signed-off-by:
-
- 22 Apr, 2018 30 commits
-
-
Mathias Nyman authored
rx_lanes and tx_lanes sysfs entries show the number of lanes in use by a device. USB 3.2 adds support for Dual-lane (symmetrical), using 2 rx lanes and 2 tx lanes for normal non Inter-Chip SSIC devices. USB 3.1 and older are all single lane. SSIC devices can have up to 4 lanes per direction in use, with different number of rx and tx lanes. Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Mathias Nyman authored
Add rx_lanes and tx_lanes lane count sysfs entries for a usb device struct usb_devuce rx_lanes and tx_lanes variables. Shows number of lanes used by the usb device Data rate of a device is the lane speed * lane count, for example USB 3.2 Gen 2x2 device uses 10Gbps signaling per lane, and has dual-lane support 10Gbps * 2 = 20Gbps Signed-off-by:
-
Mathias Nyman authored
USB 3.2 specification adds a Gen XxY notion for USB3 devices where X is the signaling rate on the wire. Gen 1xY is 5Gbps Superspeed and Gen 2xY is 10Gbps SuperSpeedPlus. Y is the lane count. For normal, non inter-chip (SSIC) devies the rx and tx lane count is symmetric, and the maximum lane count for USB 3.2 devices is 2 (dual-lane). SSIC devices may have asymmetric lane counts, with up to four lanes per direction. The USB 3.2 specification doesn't point out how to use the Gen XxY notion for these devices, so we limit the Gen Xx2 notion to symmertic Dual lane devies. For other devices just show Gen1 or Gen2 Gen 1 5Gbps Gen 2 10Gbps Gen 1x2 10Gbps Dual-lane (USB 3.2) Gen 2x2 20Gbps Dual-lane (USB 3.2) Signed-off-by:
-
Mathias Nyman authored
Set the the rx_lane and tx_lane count to "2" for USB 3.2 hosts. For all other older hosts set the default lane counts to 1 Signed-off-by:
-
Mathias Nyman authored
USB 3.2 specification adds Dual-lane support, doubling the maximum SuperSpeedPlus data rate from 10Gbps to 20Gbps. Dual-lane takes into use a second set of rx and tx wires/pins in the Type-C cable and connector. Add "rx_lanes" and "tx_lanes" variables to struct usb_device to store the numer of lanes in use. Number of lanes can be read using the extended port status hub request that was introduced in USB 3.1. Extended port status rx and tx lane count are zero based, maximum lanes supported by non inter-chip (SSIC) USB 3.2 is 2 (dual lane) with rx and tx lane count symmetric. SSIC devices support asymmetric lanes up to 4 lanes per direction. If extended port status is not available then default to one lane. Signed-off-by:
-
Mathias Nyman authored
Hosts that support USB 3.2 Enhaned SuperSpeed can set their hcd speed to HCD_USB32 to let usb core and host drivers know that the controller supports new USB 3.2 dual-lane features. make sure usb core handle HCD_USB32 hosts correctly, for now similar to HCD_USB32. Signed-off-by:
-
ShuFan Lee authored
Add device tree binding document for Richtek RT1711H Type-C chip driver Signed-off-by:
ShuFan Lee <shufan_lee@richtek.com> Reviewed-by:
-
ShuFan Lee authored
Richtek RT1711H Type-C chip driver that works with Type-C Port Controller Manager to provide USB PD and USB Type-C functionalities. Add definition of TCPC_CC_STATUS_TOGGLING. Signed-off-by:
-
Gregory CLEMENT authored
On Armada 7K/8K we need to explicitly enable the register clock. This clock is optional because not all the SoCs using this IP need it but at least for Armada 7K/8K it is actually mandatory. The change was done at xhci-plat level and not at a xhci-mvebu.c because, it is expected that other SoC would have this kind of constraint. The binding documentation is updating accordingly. Signed-off-by:
Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by:
-
Gregory CLEMENT authored
clk_disable_unprepare() already checks that the clock pointer is valid. No need to test it before calling it. Signed-off-by:
-
Li Jun authored
Since there is no user of max_snk_*, so we can remove them from tcpm. Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Li Jun <jun.li@nxp.com> Reviewed-by:
-
Li Jun authored
Since max_snk_* is to be deprecated, so remove max_snk_* by adding a variable PDO for sink config. Reviewed-by:
-
Li Jun authored
Remove max-sink-* properties since they are deprecated. Reviewed-by:
-
Li Jun authored
Since max_snk_* is to be deprecated, so remove max_snk_* by adding a variable PDO for sink config. Reviewed-by:
-
Li Jun authored
This patch is a combination of commit 57e6f0d7 ("typec: tcpm: Only request matching pdos") and source pdo selection optimization based on it, instead of only compare between the same pdo type of sink and source, we should check source pdo voltage range is within the voltage range of one sink pdo. Reviewed-by:
-
Dominik Bozek authored
wait_for_connected() wait till a port change status to USB_PORT_STAT_CONNECTION, but this is not possible if the port is unpowered. The loop will only exit at timeout. Such case take place if an over-current incident happen while system is in S3. Then during resume wait_for_connected() will wait 2s, which may be noticeable by the user. Signed-off-by:
Dominik Bozek <dominikx.bozek@intel.com> Signed-off-by:
Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by:
-
Wolfram Sang authored
We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Signed-off-by:
-
Wolfram Sang authored
We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by:
-
Johan Hovold authored
The legacy interface for associating controllers with phys from board files and platform code has been unused since commit 9080b8dc ("ARM: OMAP2+: Remove legacy usb-host.c platform init code"). Since then, all calls to usb_get_phy_dev() and its devres version have been returning -ENODEV. Now that the final calls to these functions have been removed, we can drop this legacy lookup interface altogether. Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Johan Hovold authored
Drop support for legacy phys for rcar2 which hasn't been used with a mainline kernel since commit 9080b8dc ("ARM: OMAP2+: Remove legacy usb-host.c platform init code"). Specifically, since that commit usb_get_phy_dev() have always returned -ENODEV and consequently this code has not been used. Note that the legacy-phy API is still being used in gadget mode to bind the peripheral controller. Acked-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
-
Johan Hovold authored
Drop support for non-DT systems, which hasn't been used by a mainline kernel since commit 9080b8dc ("ARM: OMAP2+: Remove legacy usb-host.c platform init code"). Specifically, since that commit usb_get_phy_dev() have always returned -ENODEV when looking up a legacy phy, something which in turn would have led to the init callback returning -EPROBE_DEFER indefinitely. Signed-off-by:
-
Johan Hovold authored
Drop support for looking up legacy phys defined by board files, something which hasn't been used by a mainline kernel since commit 9080b8dc ("ARM: OMAP2+: Remove legacy usb-host.c platform init code"). Specifically, since that commit usb_get_phy_dev() have always returned -ENODEV and consequently this code has not been used. Signed-off-by:
-
Johan Hovold authored
Drop support for looking up and initialising legacy phys in USB core, something which hasn't been used by a mainline kernel since commit 9080b8dc ("ARM: OMAP2+: Remove legacy usb-host.c platform init code"). Specifically, since that commit usb_get_phy_dev() have always returned -ENODEV and consequently this code has not been used. Signed-off-by:
-
Johan Hovold authored
Drop the unused legacy usb_bind_phy() helper whose last user was removed in 2016 when OMAP moved to device-tree boot (9080b8dc ("ARM: OMAP2+: Remove legacy usb-host.c platform init code")). Note that this means that for the last couple of years the phy_bind_list has been empty (when using mainline kernels) and that consequently all phy lookups using the usb_get_phy_dev() interface have failed with -ENODEV. This helper along with its current users will be removed by follow-on patches. Signed-off-by:
-
Shuah Khan authored
Refine probe and disconnect debug msgs to be useful and say what is in progress. Signed-off-by:
Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by:
-
Geert Uytterhoeven authored
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their dependencies on HAS_DMA, to prevent compiling subsystems or drivers that cannot work anyway. This simplifies the dependencies, and allows to improve compile-testing. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by:
Mark Brown <broonie@kernel.org> Acked-by:
Robin Murphy <robin.murphy@arm.com> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com> [drivers/usb/gadget/] Acked-by:
-
Jia-Ju Bai authored
isp1760_stop() is never called in atomic context. The call chain ending up at isp1760_stop() is: [1] isp1760_stop() <- isp1760_shutdown() isp1760_shutdown() is set as ".shutdown" in struct hc_driver. isp1760_stop() is also set as ".stop" in hc_driver. These functions are not called in atomic context. Despite never getting called from atomic context, isp1760_stop() calls mdelay() to busily wait. This is not necessary and can be replaced with msleep() to avoid busy waiting. This is found by a static analysis tool named DCNS written by myself. And I also manually check it Signed-off-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by:
-
Jia-Ju Bai authored
isp1760_init_core() is never called in atomic context. The call chains ending up at isp1760_init_core() are: [1] isp1760_init_core() <- isp1760_register() <- isp1760_plat_probe() [2] isp1760_init_core() <- isp1760_register() <- isp1761_pci_probe() isp1760_plat_probe() is set as ".probe" in struct platform_driver. isp1761_pci_probe() is set as ".probe" in struct pci_driver. These functions are not called in atomic context. Despite never getting called from atomic context, isp1761_pci_probe() calls mdelay() to busily wait. This is not necessary and can be replaced with msleep() to avoid busy waiting. This is found by a static analysis tool named DCNS written by myself. And I also manually check it. Signed-off-by:
-
Jia-Ju Bai authored
init_freecom() is never called in atomic context. init_freecom() is set as ".initFunction" through UNUSUAL_DEV(). And ->initFunction() is only called by usb_stor_acquire_resources(), which is only called by usb_stor_probe2(). usb_stor_probe2() is called by *_probe() functions (like alauda_probe()) for each USB driver. *_probe() functions are set ".probe" in struct usb_driver. These functions are not called in atomic context. Despite never getting called from atomic context, init_freecom() calls mdelay() to busily wait. This is not necessary and can be replaced with msleep() to avoid busy waiting. This is found by a static analysis tool named DCNS written by myself. And I also manually check it. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Takashi Iwai authored
The comment in UAC2 clock selector descriptor definition mentions the bAssocTerminal after baCSourceID[], but it doesn't exist in the actual definition. Let's correct it. Fixes: 5dd360eb ("include/linux/usb/audio-v2.h: add more UAC2 details") Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
