kernel/linux.git/drivers/usb/core/Kconfig, branch v4.11.5

usb: core: Introduce a USB port LED trigger

2016-09-27T10:20:17+00:00

This commit adds a new trigger responsible for turning on LED when USB device gets connected to the selected USB port. This can can useful for various home routers that have USB port(s) and a proper LED telling user a device is connected. The trigger gets its documentation file but basically it just requires enabling it and selecting USB ports (e.g. echo 1 > ports/usb1-1). There was a long discussion on design of this driver. Its current state is a result of picking them most adjustable solution as others couldn't handle all cases. 1) It wasn't possible for the driver to register separated trigger for each USB port. Some physical USB ports are handled by more than one controller and so by more than one USB port. E.g. USB 2.0 physical port may be handled by OHCI's port and EHCI's port. It's also not possible to assign more than 1 trigger to a single LED and implementing such feature would be tricky due to syncing triggers and sysfs conflicts with old triggers. 2) Another idea was to register trigger per USB hub. This wouldn't allow handling devices with multiple USB LEDs and controllers (hubs) controlling more than 1 physical port. It's common for hubs to have few ports and each may have its own LED. This final trigger is highly flexible. It allows selecting any USB ports for any LED. It was also modified (comparing to the initial version) to allow choosing ports rather than having user /guess/ proper names. It was successfully tested on SmartRG SR400ac which has 3 USB LEDs, 2 physical ports and 3 controllers. It was noted USB subsystem already has usb-gadget and usb-host triggers but they are pretty trivial ones. They indicate activity only and can't have ports specified. In future it may be good idea to consider adding activity support to usbport as well. This should allow switching to this more generic driver and maybe marking old ones as obsolete. This can be implemented with another sysfs file for setting mode. The default mode wouldn't change so there won't be ABI breakage and so such feature can be safely implemented later. There was also an idea of supporting other devices (PCI, SDIO, etc.) but as this driver already contains some USB specific code (and will get more) these should be probably separated drivers (triggers). Signed-off-by: Rafał Miłecki Signed-off-by: Greg Kroah-Hartman

usb: Kconfig: move ulpi bus support out of host

2016-09-09T12:13:23+00:00

The ULPI bus is not only for host, but for device mode too, so move it out from host's Kconfig. Signed-off-by: Peter Chen Acked-by: Heikki Krogerus Signed-off-by: Greg Kroah-Hartman

usb: remove redundant dependency on USB_SUPPORT

2016-08-09T14:15:44+00:00

The whole Kconfig entries of the USB subsystem are surrounded with "if USB_SUPPORT" ... "endif", so CONFIG_USB_SUPPORT=y is surely met when these two Kconfig options are visible. Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman

usb: kconfig: fix warning of select USB_OTG

2015-11-20T00:31:42+00:00

When choose randconfig for kernel build, it reports below warning: "warning: (USB_OTG_FSM && FSL_USB2_OTG && USB_MV_OTG) selects USB_OTG which has unmet direct dependencies (USB_SUPPORT && USB && PM)" In fact, USB_OTG is visible symbol and depends on PM, so the driver needs to depend on it to reduce dependency problem. Signed-off-by: Peter Chen Reported-by: Arnd Bergmann Cc: Felipe Balbi Acked-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman

usb: add bus type for USB ULPI

2015-05-13T17:04:55+00:00

UTMI+ Low Pin Interface (ULPI) is a commonly used PHY interface for USB 2.0. The ULPI specification describes a standard set of registers which the vendors can extend for their specific needs. ULPI PHYs provide often functions such as charger detection and ADP sensing and probing. There are two major issues that the bus type is meant to tackle: Firstly, ULPI registers are accessed from the controller. The bus provides convenient method for the controller drivers to share that access with the actual PHY drivers. Secondly, there are already platforms that assume ULPI PHYs are runtime detected, such as many Intel Baytrail based platforms. They do not provide any kind of hardware description for the ULPI PHYs like separate ACPI device object that could be used to enumerate a device from. Signed-off-by: Heikki Krogerus Acked-by: David Cohen Signed-off-by: Felipe Balbi

PM / Kconfig: Replace PM_RUNTIME with PM in dependencies

2014-12-12T23:44:04+00:00

After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is selected) PM_RUNTIME is always set if PM is set, so Kconfig options depending on CONFIG_PM_RUNTIME may now be changed to depend on CONFIG_PM. Replace PM_RUNTIME with PM in Kconfig dependencies throughout the tree. Signed-off-by: Rafael J. Wysocki Acked-by: Felipe Balbi Acked-by: Greg Kroah-Hartman Acked-by: Tejun Heo

usb: core: Kconfig: TPL should apply for both OTG and EH

2014-09-24T04:28:41+00:00

Update configuration for USB_OTG_WHITELIST, any targeted hosts (non PC-hosts) can have TPL (Targered Peripheral List). Signed-off-by: Peter Chen Signed-off-by: Greg Kroah-Hartman

usb: common: rename phy-fsm-usb.c to usb-otg-fsm.c

2014-05-27T22:29:44+00:00

Since usb otg fsm implementation is not related to usb phy. We move it from usb/phy/ to usb/common/, and rename it to reflect its real meaning. Cc: Felipe Balbi Signed-off-by: Peter Chen Signed-off-by: Greg Kroah-Hartman

usb: core: remove the Kconfig entry for USB_DEBUG

2014-05-27T22:18:48+00:00

Since we have already removed the usage of CONFIG_USB_DEBUG, it is meaningless that there is still a configuration entry for CONFIG_USB_DEBUG. Signed-off-by: Peter Chen Signed-off-by: Greg Kroah-Hartman

Kconfig: Remove useless "default N" lines

2014-02-20T13:38:06+00:00

A number of Kconfig entries default to (uppercase) "N". It was clearly intended to use "default n". But since (lowercase) "n" is the default anyway, these lines might as well be removed. Signed-off-by: Paul Bolle Signed-off-by: Jiri Kosina