This series adds:
- the onboard_usb_hub_driver
- glue in the generic HCD code to create and destroy the
onboard_usb_hub platform devices if needed
- device tree changes that add RTS5411 entries for the QCA SC7180
based boards trogdor and lazor
- a couple of stubs for platform device functions to avoid
unresolved symbols with certain kernel configs
The main issue the driver addresses is that a USB hub needs to be
powered before it can be discovered. For discrete onboard hubs (an
example for such a hub is the Realtek RTS5411) this is often solved
by supplying the hub with an 'always-on' regulator, which is kind
of a hack. Some onboard hubs may require further initialization
steps, like changing the state of a GPIO or enabling a clock, which
requires even more hacks. This driver creates a platform device
representing the hub which performs the necessary initialization.
Currently it only supports switching on a single regulator, support
for multiple regulators or other actions can be added as needed.
Different initialization sequences can be supported based on the
compatible string.
Besides performing the initialization the driver can be configured
to power the hub off during system suspend. This can help to extend
battery life on battery powered devices which have no requirements
to keep the hub powered during suspend. The driver can also be
configured to leave the hub powered when a wakeup capable USB device
is connected when suspending, and power it off otherwise.
Changes in v17:
- rebased on top of v5.16-rc1
- moved creation of onboard_hub platform devices from xhci_platform
to the generic HCD code
- addressed review comments for the onboard_hub driver
- moved Kconfig/defconfig changes to the end of the series. The
onboard_hub driver doesn't depend on XHCI_PLATFORM anymore,
hence these changes aren't really required for the driver, but
they still seem to be a worthwhile improvement
Changes in v16:
- added patch 'ARM: configs: Explicitly enable USB_XHCI_PLATFORM
where needed' to keep arm32 defconfigs effectively unchanged
Changes in v15:
- adjusted dependencies of USB_DWC3_CORE to make sure it can only
be enabled when at least one of USB_DWC3_HOST, USB_DWC3_GADGET
or USB_DWC3_DUAL_ROLE is selectable
Changes in v14:
- rebased on top of v5.14-rc1
- dropped DT binding patch which landed in v5.13
Changes in v13:
- added patch "usb: Specify dependency on USB_XHCI_PLATFORM with
'depends on'" to the series to avoid Kconfig conflicts
- added patch "arm64: defconfig: Explicitly enable USB_XHCI_PLATFORM"
to the series to keep effective defconfig unchanged
Changes in v12:
- onboard_hub driver: use IS_ENABLED(CONFIG_USB_ONBOARD_HUB_MODULE)
in onboard_hub.h to also check for the driver built as module
- onboard_hub_driver: include onboard_hub.h again to make sure there
are prototype declarations for the public functions
Changes in v11:
- support multiple onboard hubs connected to the same parent
- don't include ‘onboard_hub.h’ from the onboard hub driver
Changes in v10:
- always use of_is_onboard_usb_hub() stub unless ONBOARD_USB_HUB=y/m
- keep 'regulator-boot-on' property for pp3300_hub
Changes in v9:
- added dependency on ONBOARD_USB_HUB (or !!ONBOARD_USB_HUB) to
USB_PLATFORM_XHCI
Changes in v7:
- updated DT binding
- series rebased on qcom/arm64-for-5.13
Changes in v6:
- updated summary
Changes in v5:
- cover letter added
Matthias Kaehlcke (7):
usb: misc: Add onboard_usb_hub driver
of/platform: Add stubs for of_platform_device_create/destroy()
usb: core: hcd: Create platform devices for onboard hubs in probe()
arm64: dts: qcom: sc7180-trogdor: Add nodes for onboard USB hub
ARM: configs: Explicitly enable USB_XHCI_PLATFORM where needed
arm64: defconfig: Explicitly enable USB_XHCI_PLATFORM
usb: Specify dependencies on USB_XHCI_PLATFORM with 'depends on'
.../sysfs-bus-platform-onboard-usb-hub | 8 +
MAINTAINERS | 7 +
arch/arm/configs/exynos_defconfig | 1 +
arch/arm/configs/keystone_defconfig | 1 +
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/configs/mvebu_v7_defconfig | 1 +
arch/arm/configs/omap2plus_defconfig | 1 +
arch/arm/configs/pxa_defconfig | 1 +
.../boot/dts/qcom/sc7180-trogdor-lazor-r0.dts | 19 +-
.../boot/dts/qcom/sc7180-trogdor-lazor-r1.dts | 12 +-
.../arm64/boot/dts/qcom/sc7180-trogdor-r1.dts | 19 +-
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 19 +-
arch/arm64/configs/defconfig | 1 +
drivers/usb/cdns3/Kconfig | 2 +-
drivers/usb/core/hcd.c | 6 +
drivers/usb/dwc3/Kconfig | 5 +-
drivers/usb/host/Kconfig | 4 +-
drivers/usb/misc/Kconfig | 17 +
drivers/usb/misc/Makefile | 1 +
drivers/usb/misc/onboard_usb_hub.c | 491 ++++++++++++++++++
include/linux/of_platform.h | 22 +-
include/linux/usb/hcd.h | 1 +
include/linux/usb/onboard_hub.h | 18 +
23 files changed, 619 insertions(+), 39 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub
create mode 100644 drivers/usb/misc/onboard_usb_hub.c
create mode 100644 include/linux/usb/onboard_hub.h
--
2.34.0.rc1.387.gb447b232ab-goog
Code for platform_device_create() and of_platform_device_destroy() is
only generated if CONFIG_OF_ADDRESS=y. Add stubs to avoid unresolved
symbols when CONFIG_OF_ADDRESS is not set.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Acked-by: Rob Herring <[email protected]>
---
Changes in v17:
- none
Changes in v16:
- none
Changes in v15:
- none
Changes in v14:
- none
Changes in v13:
- none
Changes in v12:
- none
Changes in v11:
- none
Changes in v10:
- none
Changes in v9:
- added Rob's 'Acked-by' tag
Changes in v8:
- fixed C&P error in commit message
Changes in v7:
- none
Changes in v6:
- patch added to the series
include/linux/of_platform.h | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
index 84a966623e78..d15b6cd5e1c3 100644
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -61,16 +61,18 @@ static inline struct platform_device *of_find_device_by_node(struct device_node
}
#endif
+extern int of_platform_bus_probe(struct device_node *root,
+ const struct of_device_id *matches,
+ struct device *parent);
+
+#ifdef CONFIG_OF_ADDRESS
/* Platform devices and busses creation */
extern struct platform_device *of_platform_device_create(struct device_node *np,
const char *bus_id,
struct device *parent);
extern int of_platform_device_destroy(struct device *dev, void *data);
-extern int of_platform_bus_probe(struct device_node *root,
- const struct of_device_id *matches,
- struct device *parent);
-#ifdef CONFIG_OF_ADDRESS
+
extern int of_platform_populate(struct device_node *root,
const struct of_device_id *matches,
const struct of_dev_auxdata *lookup,
@@ -84,6 +86,18 @@ extern int devm_of_platform_populate(struct device *dev);
extern void devm_of_platform_depopulate(struct device *dev);
#else
+/* Platform devices and busses creation */
+static inline struct platform_device *of_platform_device_create(struct device_node *np,
+ const char *bus_id,
+ struct device *parent)
+{
+ return NULL;
+}
+static inline int of_platform_device_destroy(struct device *dev, void *data)
+{
+ return -ENODEV;
+}
+
static inline int of_platform_populate(struct device_node *root,
const struct of_device_id *matches,
const struct of_dev_auxdata *lookup,
--
2.34.0.rc1.387.gb447b232ab-goog
The main issue this driver addresses is that a USB hub needs to be
powered before it can be discovered. For discrete onboard hubs (an
example for such a hub is the Realtek RTS5411) this is often solved
by supplying the hub with an 'always-on' regulator, which is kind
of a hack. Some onboard hubs may require further initialization
steps, like changing the state of a GPIO or enabling a clock, which
requires even more hacks. This driver creates a platform device
representing the hub which performs the necessary initialization.
Currently it only supports switching on a single regulator, support
for multiple regulators or other actions can be added as needed.
Different initialization sequences can be supported based on the
compatible string.
Besides performing the initialization the driver can be configured
to power the hub off during system suspend. This can help to extend
battery life on battery powered devices which have no requirements
to keep the hub powered during suspend. The driver can also be
configured to leave the hub powered when a wakeup capable USB device
is connected when suspending, and power it off otherwise.
Technically the driver consists of two drivers, the platform driver
described above and a very thin USB driver that subclasses the
generic driver. The purpose of this driver is to provide the platform
driver with the USB devices corresponding to the hub(s) (a hub
controller may provide multiple 'logical' hubs, e.g. one to support
USB 2.0 and another for USB 3.x).
Note: the current series only supports hubs connected directly to
a root hub, support for other configurations could be added if
needed.
Co-developed-by: Ravi Chandra Sadineni <[email protected]>
Signed-off-by: Ravi Chandra Sadineni <[email protected]>
Signed-off-by: Matthias Kaehlcke <[email protected]>
Acked-by: Alan Stern <[email protected]>
---
Changes in v17:
- updated date and kernel version in ABI documentation for
'always_powered_in_suspend' attribute
- removed obsolete .yaml entry from MAINTAINERS file
- added entry for ABI documentation to MAINTAINERS file
- renamed struct 'udev_node' to 'usbdev_node'
- changed return logic in onboard_hub_suspend/resume() to
get rid of 'rc' variable
- added helper set_udev_link_name() to set link names for
onboard hub USB devices
- use of_parse_phandle() instead of of_property_read_u32() +
of_find_node_by_phandle() combo
- defer probing in _find_onboard_hub() if the platform device
isn't bound yet
- initialize list head passed as parameter to
onboard_hub_create_pdevs() instead of relying on the caller
to do so
- don't require the 'companion-hub' property to be specified.
This is needed to support hubs without companion hub
- use devm_kzalloc() to allocate platform device list entries
and stop freeing them explicitly
- remove unnecessary INIT_LIST_HEAD() of platform device list
entries
- use '%pOF' to print DT node name
- delete platform device list entries from the list of devices
in onboard_hub_destroy_pdevs(). It shouldn't be strictly
necessary, but better be on the safe side.
Changes in v16:
- none
Changes in v15:
- none
Changes in v14:
- none
Changes in v13:
- none
Changes in v12:
- use IS_ENABLED(CONFIG_USB_ONBOARD_HUB_MODULE) in onboard_hub.h to
also check for the driver built as module
- include onboard_hub.h again from the driver to make sure there are
prototype declarations for the public functions
- remove indentation from label in onboard_hub_create_pdevs()
Changes in v11:
- added onboard_hub_create/destroy_pdevs() helpers, to support multiple onboard
hubs connected to the same parent hub
- don't include ‘onboard_hub.h’ from the onboard hub driver
- updated commit message
- added ‘Acked-by' from Alan
Changes in v10:
- always use of_is_onboard_usb_hub() stub unless ONBOARD_USB_HUB=y/m
Changes in v9:
- none
Changes in v8:
- none
Changes in v7:
- don't declare stub for of_is_onboard_usb_hub() when
CONFIG_COMPILE_TEST is defined
Changes in v6:
- use 'companion-hub' to locate the platform device, instead of
scanning through the nodes of the parent
- added ABI documentation for 'always_powered_in_suspend'
- sysfs_emit() instead of sprintf() in always_powered_in_suspend_show()
- register sysfs attribute through driver.dev_groups
- evaluate return value of driver_attach() in _probe()
- use dev_warn() instead of WARN_ON() in _probe()
- include 'onboard_hub.h'
Changes in v5:
- the platform device is now instantiated from the same DT node
as the 'primary' USB hub device
- use the USB compatible strings for the platform device
- refactored _find_onboard_hub() to search the parents child
nodes for a platform device with a matching compatible string
- added exported function of_is_onboard_usb_hub() to allow other
drivers (like xhci_plat) to check if one of their child DT nodes
is a supported hub
- use late suspend to make sure info about wakeup enabled descendants
is updated
- call driver_attach() for the USB driver in onboard_hub_probe() to
make sure the driver is re-attached after the device_release_driver()
calls in onboard_hub_remove()
- renamed sysfs attribute 'power_off_in_suspend' to
'always_powered_in_suspend'
- added sysfs symlinks between platform device and USB devices
- marked 'onboard_hub_pm_ops' as __maybe_unused
- removed 'realtek' compatible string which is not needed at this
point
- fix log for regulator_disable() failure
Changes in v4:
- updated Kconfig documentation
- changed the loop in onboard_hub_remove() to release the hub lock
before unbinding the USB device and make self deadlock prevention
less clunky
- fixed return value in onboard_hub_usbdev_probe()
- added entry to MAINTAINERS file
Changes in v3:
- updated the commit message
- updated description in Kconfig
- remove include of 'core/usb.h'
- use 'is_powered_on' flag instead of 'has_wakeup_capable_descendants'
- added 'going_away' flag to struct onboard_hub
- don't allow adding new USB devices when the platform device is going away
- don't bother with deleting the list item in onboard_hub_remove_usbdev()
when the platform device is going away
- don't assume in onboard_hub_suspend() that all USB hub devices are
connected to the same controller
- removed unnecessary devm_kfree() from onboard_hub_remove_usbdev()
- fixed error handling in onboard_hub_remove_usbdev()
- use kstrtobool() instead of strtobool() in power_off_in_suspend_store()
- unbind USB devices in onboard_hub_remove() to avoid dangling references
to the platform device
- moved put_device() for platform device to _find_onboard_hub()
- changed return value of onboard_hub_remove_usbdev() to void
- evaluate return value of onboard_hub_add_usbdev()
- register 'power_off_in_suspend' as managed device attribute
- use USB_DEVICE macro instead manual initialization
- add unwinding to onboard_hub_init()
- updated MODULE_DESCRIPTION
- use module_init() instead of device_initcall()
Changes in v2:
- check wakeup enabled state of the USB controller instead of
using 'wakeup-source' property
- use sysfs attribute instead of DT property to determine if
the hub should be powered off at all during system suspend
- added missing brace in onboard_hub_suspend()
- updated commit message
- use pm_ptr for pm_ops as suggested by Alan
Changes in v1:
- renamed the driver to 'onboard_usb_hub'
- single file for platform and USB driver
- USB hub devices register with the platform device
- the DT includes a phandle of the platform device
- the platform device now controls when power is turned off
- the USB driver became a very thin subclass of the generic USB
driver
- enabled autosuspend support
.../sysfs-bus-platform-onboard-usb-hub | 8 +
MAINTAINERS | 7 +
drivers/usb/misc/Kconfig | 17 +
drivers/usb/misc/Makefile | 1 +
drivers/usb/misc/onboard_usb_hub.c | 491 ++++++++++++++++++
include/linux/usb/onboard_hub.h | 18 +
6 files changed, 542 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub
create mode 100644 drivers/usb/misc/onboard_usb_hub.c
create mode 100644 include/linux/usb/onboard_hub.h
diff --git a/Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub b/Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub
new file mode 100644
index 000000000000..39fa2ed29fed
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub
@@ -0,0 +1,8 @@
+What: /sys/bus/platform/devices/<dev>/always_powered_in_suspend
+Date: November 2021
+KernelVersion: 5.17
+Contact: Matthias Kaehlcke <[email protected]>
+ [email protected]
+Description:
+ (RW) Controls whether the USB hub remains always powered
+ during system suspend or not.
\ No newline at end of file
diff --git a/MAINTAINERS b/MAINTAINERS
index 7a2345ce8521..58363244a673 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14172,6 +14172,13 @@ S: Maintained
T: git git://linuxtv.org/media_tree.git
F: drivers/media/i2c/ov9734.c
+ONBOARD USB HUB DRIVER
+M: Matthias Kaehlcke <[email protected]>
+L: [email protected]
+S: Maintained
+F: Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub
+F: drivers/usb/misc/onboard_usb_hub.c
+
ONENAND FLASH DRIVER
M: Kyungmin Park <[email protected]>
L: [email protected]
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 8f1144359012..f534269fbb20 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -284,3 +284,20 @@ config BRCM_USB_PINMAP
This option enables support for remapping some USB external
signals, which are typically on dedicated pins on the chip,
to any gpio.
+
+config USB_ONBOARD_HUB
+ tristate "Onboard USB hub support"
+ depends on OF || COMPILE_TEST
+ help
+ Say Y here if you want to support discrete onboard USB hubs that
+ don't require an additional control bus for initialization, but
+ need some nontrivial form of initialization, such as enabling a
+ power regulator. An example for such a hub is the Realtek
+ RTS5411.
+
+ The driver can be configured to turn off the power of the hub
+ during system suspend. This may reduce power consumption while
+ the system is suspended.
+
+ To compile this driver as a module, choose M here: the
+ module will be called onboard_usb_hub.
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index 5f4e598573ab..2c5aec6f1b26 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -32,3 +32,4 @@ obj-$(CONFIG_USB_CHAOSKEY) += chaoskey.o
obj-$(CONFIG_USB_SISUSBVGA) += sisusbvga/
obj-$(CONFIG_USB_LINK_LAYER_TEST) += lvstest.o
obj-$(CONFIG_BRCM_USB_PINMAP) += brcmstb-usb-pinmap.o
+obj-$(CONFIG_USB_ONBOARD_HUB) += onboard_usb_hub.o
diff --git a/drivers/usb/misc/onboard_usb_hub.c b/drivers/usb/misc/onboard_usb_hub.c
new file mode 100644
index 000000000000..8ab38548ac86
--- /dev/null
+++ b/drivers/usb/misc/onboard_usb_hub.c
@@ -0,0 +1,491 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Driver for onboard USB hubs
+ *
+ * Copyright (c) 2020, Google LLC
+ */
+
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/suspend.h>
+#include <linux/sysfs.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+#include <linux/usb/of.h>
+#include <linux/usb/onboard_hub.h>
+
+static struct usb_device_driver onboard_hub_usbdev_driver;
+
+/************************** Platform driver **************************/
+
+struct usbdev_node {
+ struct usb_device *udev;
+ struct list_head list;
+};
+
+struct onboard_hub {
+ struct regulator *vdd;
+ struct device *dev;
+ bool always_powered_in_suspend;
+ bool is_powered_on;
+ bool going_away;
+ struct list_head udev_list;
+ struct mutex lock;
+};
+
+static int onboard_hub_power_on(struct onboard_hub *hub)
+{
+ int err;
+
+ err = regulator_enable(hub->vdd);
+ if (err) {
+ dev_err(hub->dev, "failed to enable regulator: %d\n", err);
+ return err;
+ }
+
+ hub->is_powered_on = true;
+
+ return 0;
+}
+
+static int onboard_hub_power_off(struct onboard_hub *hub)
+{
+ int err;
+
+ err = regulator_disable(hub->vdd);
+ if (err) {
+ dev_err(hub->dev, "failed to disable regulator: %d\n", err);
+ return err;
+ }
+
+ hub->is_powered_on = false;
+
+ return 0;
+}
+
+static int __maybe_unused onboard_hub_suspend(struct device *dev)
+{
+ struct onboard_hub *hub = dev_get_drvdata(dev);
+ struct usbdev_node *node;
+ bool power_off;
+
+ if (hub->always_powered_in_suspend)
+ return 0;
+
+ power_off = true;
+
+ mutex_lock(&hub->lock);
+
+ list_for_each_entry(node, &hub->udev_list, list) {
+ if (!device_may_wakeup(node->udev->bus->controller))
+ continue;
+
+ if (usb_wakeup_enabled_descendants(node->udev)) {
+ power_off = false;
+ break;
+ }
+ }
+
+ mutex_unlock(&hub->lock);
+
+ if (!power_off)
+ return 0;
+
+ return onboard_hub_power_off(hub);
+}
+
+static int __maybe_unused onboard_hub_resume(struct device *dev)
+{
+ struct onboard_hub *hub = dev_get_drvdata(dev);
+
+ if (hub->is_powered_on)
+ return 0;
+
+ return onboard_hub_power_on(hub);
+}
+
+static inline void set_udev_link_name(struct usb_device *udev, char *buf, size_t size)
+{
+ snprintf(buf, size, "usb_dev.%s", dev_name(&udev->dev));
+}
+
+static int onboard_hub_add_usbdev(struct onboard_hub *hub, struct usb_device *udev)
+{
+ struct usbdev_node *node;
+ char link_name[64];
+ int ret = 0;
+
+ mutex_lock(&hub->lock);
+
+ if (hub->going_away) {
+ ret = -EINVAL;
+ goto unlock;
+ }
+
+ node = devm_kzalloc(hub->dev, sizeof(*node), GFP_KERNEL);
+ if (!node) {
+ ret = -ENOMEM;
+ goto unlock;
+ }
+
+ node->udev = udev;
+
+ list_add(&node->list, &hub->udev_list);
+
+ set_udev_link_name(udev, link_name, sizeof(link_name));
+ WARN_ON(sysfs_create_link(&hub->dev->kobj, &udev->dev.kobj, link_name));
+
+unlock:
+ mutex_unlock(&hub->lock);
+
+ return ret;
+}
+
+static void onboard_hub_remove_usbdev(struct onboard_hub *hub, struct usb_device *udev)
+{
+ struct usbdev_node *node;
+ char link_name[64];
+
+ set_udev_link_name(udev, link_name, sizeof(link_name));
+ sysfs_remove_link(&hub->dev->kobj, link_name);
+
+ mutex_lock(&hub->lock);
+
+ list_for_each_entry(node, &hub->udev_list, list) {
+ if (node->udev == udev) {
+ list_del(&node->list);
+ break;
+ }
+ }
+
+ mutex_unlock(&hub->lock);
+}
+
+static ssize_t always_powered_in_suspend_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct onboard_hub *hub = dev_get_drvdata(dev);
+
+ return sysfs_emit(buf, "%d\n", hub->always_powered_in_suspend);
+}
+
+static ssize_t always_powered_in_suspend_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct onboard_hub *hub = dev_get_drvdata(dev);
+ bool val;
+ int ret;
+
+ ret = kstrtobool(buf, &val);
+ if (ret < 0)
+ return ret;
+
+ hub->always_powered_in_suspend = val;
+
+ return count;
+}
+static DEVICE_ATTR_RW(always_powered_in_suspend);
+
+static struct attribute *onboard_hub_attrs[] = {
+ &dev_attr_always_powered_in_suspend.attr,
+ NULL,
+};
+ATTRIBUTE_GROUPS(onboard_hub);
+
+static int onboard_hub_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct onboard_hub *hub;
+ int err;
+
+ hub = devm_kzalloc(dev, sizeof(*hub), GFP_KERNEL);
+ if (!hub)
+ return -ENOMEM;
+
+ hub->vdd = devm_regulator_get(dev, "vdd");
+ if (IS_ERR(hub->vdd))
+ return PTR_ERR(hub->vdd);
+
+ hub->dev = dev;
+ mutex_init(&hub->lock);
+ INIT_LIST_HEAD(&hub->udev_list);
+
+ dev_set_drvdata(dev, hub);
+
+ err = onboard_hub_power_on(hub);
+ if (err)
+ return err;
+
+ /*
+ * The USB driver might have been detached from the USB devices by
+ * onboard_hub_remove(), make sure to re-attach it if needed.
+ */
+ err = driver_attach(&onboard_hub_usbdev_driver.drvwrap.driver);
+ if (err) {
+ onboard_hub_power_off(hub);
+ return err;
+ }
+
+ return 0;
+}
+
+static int onboard_hub_remove(struct platform_device *pdev)
+{
+ struct onboard_hub *hub = dev_get_drvdata(&pdev->dev);
+ struct usbdev_node *node;
+ struct usb_device *udev;
+
+ hub->going_away = true;
+
+ mutex_lock(&hub->lock);
+
+ /* unbind the USB devices to avoid dangling references to this device */
+ while (!list_empty(&hub->udev_list)) {
+ node = list_first_entry(&hub->udev_list, struct usbdev_node, list);
+ udev = node->udev;
+
+ /*
+ * Unbinding the driver will call onboard_hub_remove_usbdev(),
+ * which acquires hub->lock. We must release the lock first.
+ */
+ get_device(&udev->dev);
+ mutex_unlock(&hub->lock);
+ device_release_driver(&udev->dev);
+ put_device(&udev->dev);
+ mutex_lock(&hub->lock);
+ }
+
+ mutex_unlock(&hub->lock);
+
+ return onboard_hub_power_off(hub);
+}
+
+static const struct of_device_id onboard_hub_match[] = {
+ { .compatible = "usbbda,411" },
+ { .compatible = "usbbda,5411" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, onboard_hub_match);
+
+static bool of_is_onboard_usb_hub(const struct device_node *np)
+{
+ return !!of_match_node(onboard_hub_match, np);
+}
+
+static const struct dev_pm_ops __maybe_unused onboard_hub_pm_ops = {
+ SET_LATE_SYSTEM_SLEEP_PM_OPS(onboard_hub_suspend, onboard_hub_resume)
+};
+
+static struct platform_driver onboard_hub_driver = {
+ .probe = onboard_hub_probe,
+ .remove = onboard_hub_remove,
+
+ .driver = {
+ .name = "onboard-usb-hub",
+ .of_match_table = onboard_hub_match,
+ .pm = pm_ptr(&onboard_hub_pm_ops),
+ .dev_groups = onboard_hub_groups,
+ },
+};
+
+/************************** USB driver **************************/
+
+#define VENDOR_ID_REALTEK 0x0bda
+
+/*
+ * Returns the onboard_hub platform device that is associated with the USB
+ * device passed as parameter.
+ */
+static struct onboard_hub *_find_onboard_hub(struct device *dev)
+{
+ struct platform_device *pdev;
+ struct device_node *np;
+
+ pdev = of_find_device_by_node(dev->of_node);
+ if (!pdev) {
+ np = of_parse_phandle(dev->of_node, "companion-hub", 0);
+ if (!np) {
+ dev_err(dev, "failed to find device node for companion hub\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ pdev = of_find_device_by_node(np);
+ of_node_put(np);
+
+ if (!pdev || !device_is_bound(&pdev->dev))
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+
+ put_device(&pdev->dev);
+
+ return dev_get_drvdata(&pdev->dev);
+}
+
+static int onboard_hub_usbdev_probe(struct usb_device *udev)
+{
+ struct device *dev = &udev->dev;
+ struct onboard_hub *hub;
+ int err;
+
+ /* ignore supported hubs without device tree node */
+ if (!dev->of_node)
+ return -ENODEV;
+
+ hub = _find_onboard_hub(dev);
+ if (IS_ERR(hub))
+ return PTR_ERR(hub);
+
+ dev_set_drvdata(dev, hub);
+
+ err = onboard_hub_add_usbdev(hub, udev);
+ if (err)
+ return err;
+
+ err = sysfs_create_link(&udev->dev.kobj, &hub->dev->kobj, "onboard_hub_dev");
+ if (err)
+ dev_warn(&udev->dev, "failed to create symlink to platform device: %d\n", err);
+
+ return 0;
+}
+
+static void onboard_hub_usbdev_disconnect(struct usb_device *udev)
+{
+ struct onboard_hub *hub = dev_get_drvdata(&udev->dev);
+
+ sysfs_remove_link(&udev->dev.kobj, "onboard_hub_dev");
+
+ onboard_hub_remove_usbdev(hub, udev);
+}
+
+static const struct usb_device_id onboard_hub_id_table[] = {
+ { USB_DEVICE(VENDOR_ID_REALTEK, 0x0411) }, /* RTS5411 USB 3.0 */
+ { USB_DEVICE(VENDOR_ID_REALTEK, 0x5411) }, /* RTS5411 USB 2.0 */
+ {},
+};
+
+MODULE_DEVICE_TABLE(usb, onboard_hub_id_table);
+
+static struct usb_device_driver onboard_hub_usbdev_driver = {
+ .name = "onboard-usb-hub",
+ .probe = onboard_hub_usbdev_probe,
+ .disconnect = onboard_hub_usbdev_disconnect,
+ .generic_subclass = 1,
+ .supports_autosuspend = 1,
+ .id_table = onboard_hub_id_table,
+};
+
+/*** Helpers for creating/destroying platform devices for onboard hubs ***/
+
+struct pdev_list_entry {
+ struct platform_device *pdev;
+ struct list_head node;
+};
+
+/*
+ * Creates a platform device for each supported onboard hub that is connected to
+ * the given parent hub. To keep track of the platform devices they are added to
+ * a list that is owned by the parent hub.
+ */
+void onboard_hub_create_pdevs(struct usb_device *parent_hub, struct list_head *pdev_list)
+{
+ int i;
+ struct device_node *np, *npc;
+ struct platform_device *pdev;
+ struct pdev_list_entry *pdle;
+
+ INIT_LIST_HEAD(pdev_list);
+
+ for (i = 1; i <= parent_hub->maxchild; i++) {
+ np = usb_of_get_device_node(parent_hub, i);
+ if (!np)
+ continue;
+
+ if (!of_is_onboard_usb_hub(np))
+ goto node_put;
+
+ npc = of_parse_phandle(np, "companion-hub", 0);
+ if (!npc)
+ goto create_pdev;
+
+ pdev = of_find_device_by_node(npc);
+ of_node_put(npc);
+
+ if (pdev) {
+ /* the companion hub already has a platform device, nothing to do here */
+ put_device(&pdev->dev);
+ goto node_put;
+ }
+
+create_pdev:
+ pdev = of_platform_device_create(np, NULL, &parent_hub->dev);
+ if (pdev) {
+ pdle = devm_kzalloc(&pdev->dev, sizeof(*pdle), GFP_KERNEL);
+ if (!pdle) {
+ of_platform_device_destroy(&pdev->dev, NULL);
+ goto node_put;
+ }
+
+ pdle->pdev = pdev;
+ list_add(&pdle->node, pdev_list);
+ } else {
+ dev_err(&parent_hub->dev,
+ "failed to create platform device for onboard hub '%pOF'\n", np);
+ }
+
+node_put:
+ of_node_put(np);
+ }
+}
+EXPORT_SYMBOL_GPL(onboard_hub_create_pdevs);
+
+/*
+ * Destroys the platform devices in the given list and frees the memory associated
+ * with the list entry.
+ */
+void onboard_hub_destroy_pdevs(struct list_head *pdev_list)
+{
+ struct pdev_list_entry *pdle, *tmp;
+
+ list_for_each_entry_safe(pdle, tmp, pdev_list, node) {
+ list_del(&pdle->node);
+ of_platform_device_destroy(&pdle->pdev->dev, NULL);
+ }
+}
+EXPORT_SYMBOL_GPL(onboard_hub_destroy_pdevs);
+
+/************************** Driver (de)registration **************************/
+
+static int __init onboard_hub_init(void)
+{
+ int ret;
+
+ ret = platform_driver_register(&onboard_hub_driver);
+ if (ret)
+ return ret;
+
+ ret = usb_register_device_driver(&onboard_hub_usbdev_driver, THIS_MODULE);
+ if (ret)
+ platform_driver_unregister(&onboard_hub_driver);
+
+ return ret;
+}
+module_init(onboard_hub_init);
+
+static void __exit onboard_hub_exit(void)
+{
+ usb_deregister_device_driver(&onboard_hub_usbdev_driver);
+ platform_driver_unregister(&onboard_hub_driver);
+}
+module_exit(onboard_hub_exit);
+
+MODULE_AUTHOR("Matthias Kaehlcke <[email protected]>");
+MODULE_DESCRIPTION("Driver for discrete onboard USB hubs");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/usb/onboard_hub.h b/include/linux/usb/onboard_hub.h
new file mode 100644
index 000000000000..d9373230556e
--- /dev/null
+++ b/include/linux/usb/onboard_hub.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __LINUX_USB_ONBOARD_HUB_H
+#define __LINUX_USB_ONBOARD_HUB_H
+
+struct usb_device;
+struct list_head;
+
+#if IS_ENABLED(CONFIG_USB_ONBOARD_HUB)
+void onboard_hub_create_pdevs(struct usb_device *parent_hub, struct list_head *pdev_list);
+void onboard_hub_destroy_pdevs(struct list_head *pdev_list);
+#else
+static inline void onboard_hub_create_pdevs(struct usb_device *parent_hub,
+ struct list_head *pdev_list) {}
+static inline void onboard_hub_destroy_pdevs(struct list_head *pdev_list) {}
+#endif
+
+#endif /* __LINUX_USB_ONBOARD_HUB_H */
--
2.34.0.rc1.387.gb447b232ab-goog
Call onboard_hub_create/destroy_pdevs() from usb_add/remove_hcd()
for primary HCDs to create/destroy platform devices for onboard
USB hubs that may be connected to the root hub of the controller.
These functions are a NOP unless CONFIG_USB_ONBOARD_HUB=y/m.
Also add a field to struct usb_hcd to keep track of the onboard hub
platform devices that are owned by the HCD.
Signed-off-by: Matthias Kaehlcke <[email protected]>
---
Changes in v17:
- create the platform devices in the generic HCD code instead of
the xhci_platform driver
- updated subject and commit message to reflect the above change
- dropped initialization of platform device list, which is now
done in onboard_hub_create_pdevs()
Changes in v16:
- none
Changes in v15:
- none
Changes in v14:
- none
Changes in v13:
- added comment for 'depends on USB_ONBOARD_HUB || !USB_ONBOARD_HUB'
construct
Changes in v12:
- none
Changes in v11:
- use onboard_hub_create/destroy_pdevs() to support multiple onboard
hubs that are connected to the same root hub
- moved field/list to keep track of platform devices from struct
usb_hcd to struct xhci_hcd
- updated commit message
Changes in v10:
- none
Changes in v9:
- added dependency on USB_ONBOARD_HUB (or !!USB_ONBOARD_HUB) to
USB_XHCI_PLATFORM
Changes in v8:
- none
Changes in v7:
- none
Changes in v6:
- none
Changes in v5:
- patch added to the series
drivers/usb/core/hcd.c | 6 ++++++
include/linux/usb/hcd.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 4d326ee12c36..b8220e411e07 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -36,6 +36,7 @@
#include <linux/phy/phy.h>
#include <linux/usb.h>
#include <linux/usb/hcd.h>
+#include <linux/usb/onboard_hub.h>
#include <linux/usb/otg.h>
#include "usb.h"
@@ -2963,6 +2964,9 @@ int usb_add_hcd(struct usb_hcd *hcd,
if (hcd->uses_new_polling && HCD_POLL_RH(hcd))
usb_hcd_poll_rh_status(hcd);
+ if (usb_hcd_is_primary_hcd(hcd))
+ onboard_hub_create_pdevs(hcd->self.root_hub, &hcd->onboard_hub_devs);
+
return retval;
err_register_root_hub:
@@ -3041,6 +3045,8 @@ void usb_remove_hcd(struct usb_hcd *hcd)
if (usb_hcd_is_primary_hcd(hcd)) {
if (hcd->irq > 0)
free_irq(hcd->irq, hcd);
+
+ onboard_hub_destroy_pdevs(&hcd->onboard_hub_devs);
}
usb_deregister_bus(&hcd->self);
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index 548a028f2dab..4ebc91c09182 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -198,6 +198,7 @@ struct usb_hcd {
struct usb_hcd *shared_hcd;
struct usb_hcd *primary_hcd;
+ struct list_head onboard_hub_devs;
#define HCD_BUFFER_POOLS 4
struct dma_pool *pool[HCD_BUFFER_POOLS];
--
2.34.0.rc1.387.gb447b232ab-goog
Add nodes for the onboard USB hub on trogdor devices. Remove the
'always-on' property from the hub regulator, since the regulator
is now managed by the onboard_usb_hub driver.
Signed-off-by: Matthias Kaehlcke <[email protected]>
---
Changes in v17:
- none
Changes in v16:
- none
Changes in v15:
- none
Changes in v14:
- none
Changes in v13:
- none
Changes in v12:
- none
Changes in v11:
- rebased on qcom/arm64-for-5.14 (with the rest of the series)
Changes in v10:
- keep 'regulator-boot-on' property
- updated commit message
Changes in v9:
- none
Changes in v8:
- none
Changes in v7:
- rebased on qcom/arm64-for-5.13 (with the rest of the series)
Changes in v6:
- added 'companion-hub' entry to both USB devices
- added 'vdd-supply' also to hub@2
Changes in v5:
- patch added to the series
.../boot/dts/qcom/sc7180-trogdor-lazor-r0.dts | 19 ++++++++-----------
.../boot/dts/qcom/sc7180-trogdor-lazor-r1.dts | 12 +++++-------
.../arm64/boot/dts/qcom/sc7180-trogdor-r1.dts | 19 ++++++++-----------
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 19 ++++++++++++++++++-
4 files changed, 39 insertions(+), 30 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r0.dts b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r0.dts
index 30e3e769d2b4..5fb8e12af1a0 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r0.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r0.dts
@@ -14,17 +14,6 @@ / {
compatible = "google,lazor-rev0", "qcom,sc7180";
};
-&pp3300_hub {
- /* pp3300_l7c is used to power the USB hub */
- /delete-property/regulator-always-on;
- /delete-property/regulator-boot-on;
-};
-
-&pp3300_l7c {
- regulator-always-on;
- regulator-boot-on;
-};
-
&sn65dsi86_out {
/*
* Lane 0 was incorrectly mapped on the cable, but we've now decided
@@ -33,3 +22,11 @@ &sn65dsi86_out {
*/
lane-polarities = <1 0>;
};
+
+&usb_hub_2_0 {
+ vdd-supply = <&pp3300_l7c>;
+};
+
+&usb_hub_3_0 {
+ vdd-supply = <&pp3300_l7c>;
+};
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1.dts b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1.dts
index c2ef06367baf..1dae714250f5 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1.dts
@@ -14,13 +14,11 @@ / {
compatible = "google,lazor-rev1", "google,lazor-rev2", "qcom,sc7180";
};
-&pp3300_hub {
- /* pp3300_l7c is used to power the USB hub */
- /delete-property/regulator-always-on;
- /delete-property/regulator-boot-on;
+
+&usb_hub_2_0 {
+ vdd-supply = <&pp3300_l7c>;
};
-&pp3300_l7c {
- regulator-always-on;
- regulator-boot-on;
+&usb_hub_3_0 {
+ vdd-supply = <&pp3300_l7c>;
};
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-r1.dts b/arch/arm64/boot/dts/qcom/sc7180-trogdor-r1.dts
index 457c25499863..8477c82c410a 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-r1.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-r1.dts
@@ -43,17 +43,6 @@ &panel {
compatible = "auo,b116xa01";
};
-&pp3300_hub {
- /* pp3300_l7c is used to power the USB hub */
- /delete-property/regulator-always-on;
- /delete-property/regulator-boot-on;
-};
-
-&pp3300_l7c {
- regulator-always-on;
- regulator-boot-on;
-};
-
&sdhc_2 {
status = "okay";
};
@@ -62,6 +51,14 @@ &trackpad {
interrupts = <58 IRQ_TYPE_EDGE_FALLING>;
};
+&usb_hub_2_0 {
+ vdd-supply = <&pp3300_l7c>;
+};
+
+&usb_hub_3_0 {
+ vdd-supply = <&pp3300_l7c>;
+};
+
/* PINCTRL - modifications to sc7180-trogdor.dtsi */
&trackpad_int_1v8_odl {
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index d4f4441179fc..cd31460b3bd6 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -202,7 +202,6 @@ pp3300_hub: pp3300-hub {
pinctrl-names = "default";
pinctrl-0 = <&en_pp3300_hub>;
- regulator-always-on;
regulator-boot-on;
vin-supply = <&pp3300_a>;
@@ -839,6 +838,24 @@ &usb_1 {
&usb_1_dwc3 {
dr_mode = "host";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 2.0 hub on port 1 */
+ usb_hub_2_0: hub@1 {
+ compatible = "usbbda,5411";
+ reg = <1>;
+ vdd-supply = <&pp3300_hub>;
+ companion-hub = <&usb_hub_3_0>;
+ };
+
+ /* 3.0 hub on port 2 */
+ usb_hub_3_0: hub@2 {
+ compatible = "usbbda,411";
+ reg = <2>;
+ vdd-supply = <&pp3300_hub>;
+ companion-hub = <&usb_hub_2_0>;
+ };
};
&usb_1_hsphy {
--
2.34.0.rc1.387.gb447b232ab-goog
The dependency of USB_DWC3 and USB_XHCI_MVEBU on USB_XHCI_PLATFORM
is being changed from 'select' to 'depends on' by another patch.
With that patch the defconfigs that enable one of these host
controllers also need to select USB_XHCI_PLATFORM explicitly
to keep the resulting config unchanged.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Roger Quadros <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
---
Changes in v17:
- added 'Reviewed-by' tag from Roger
- added 'Acked-by' tag from Krzysztof
Changes in v16:
- patch added to the series
arch/arm/configs/exynos_defconfig | 1 +
arch/arm/configs/keystone_defconfig | 1 +
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/configs/mvebu_v7_defconfig | 1 +
arch/arm/configs/omap2plus_defconfig | 1 +
arch/arm/configs/pxa_defconfig | 1 +
6 files changed, 6 insertions(+)
diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
index cae09010a799..2e07f5bb352b 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -256,6 +256,7 @@ CONFIG_SND_SIMPLE_CARD=y
CONFIG_USB=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_PLATFORM=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_EXYNOS=y
CONFIG_USB_OHCI_HCD=y
diff --git a/arch/arm/configs/keystone_defconfig b/arch/arm/configs/keystone_defconfig
index 33c917df7b32..4f66c5a5d94d 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -164,6 +164,7 @@ CONFIG_USB=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
CONFIG_USB_MON=y
CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_PLATFORM=y
CONFIG_USB_STORAGE=y
CONFIG_USB_DWC3=y
CONFIG_NOP_USB_XCEIV=y
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index c951aeed2138..14b339fb4958 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -775,6 +775,7 @@ CONFIG_SND_AUDIO_GRAPH_CARD=m
CONFIG_USB=y
CONFIG_USB_OTG=y
CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_PLATFORM=y
CONFIG_USB_XHCI_MVEBU=y
CONFIG_USB_XHCI_TEGRA=m
CONFIG_USB_EHCI_HCD=y
diff --git a/arch/arm/configs/mvebu_v7_defconfig b/arch/arm/configs/mvebu_v7_defconfig
index 7b713c083a2a..4e492afca076 100644
--- a/arch/arm/configs/mvebu_v7_defconfig
+++ b/arch/arm/configs/mvebu_v7_defconfig
@@ -101,6 +101,7 @@ CONFIG_SND_SIMPLE_CARD=y
CONFIG_USB=y
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_MVEBU=y
+CONFIG_USB_XHCI_PLATFORM=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_STORAGE=y
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index d933b787d934..2eb85491be03 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -563,6 +563,7 @@ CONFIG_USB=m
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
CONFIG_USB_MON=m
CONFIG_USB_XHCI_HCD=m
+CONFIG_USB_XHCI_PLATFORM=m
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_OHCI_HCD=m
CONFIG_USB_ACM=m
diff --git a/arch/arm/configs/pxa_defconfig b/arch/arm/configs/pxa_defconfig
index 58f4834289e6..510406d6e7a5 100644
--- a/arch/arm/configs/pxa_defconfig
+++ b/arch/arm/configs/pxa_defconfig
@@ -523,6 +523,7 @@ CONFIG_USB=m
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
CONFIG_USB_MON=m
CONFIG_USB_XHCI_HCD=m
+CONFIG_USB_XHCI_PLATFORM=m
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_HCD_PLATFORM=m
CONFIG_USB_ISP116X_HCD=m
--
2.34.0.rc1.387.gb447b232ab-goog
The dependency of USB_DWC3 on USB_XHCI_PLATFORM is being changed
from 'select' to 'depends on' by another patch. The defconfig selects
USB_DWC3 and implicitly USB_DWC3_DUAL_ROLE, to keep this unchanged
USB_XHCI_PLATFORM now needs to be selected explicitly.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Reviewed-by: Roger Quadros <[email protected]>
---
Changes in v17:
- added 'Reviewed-by' tag from Roger
Changes in v16:
- none
Changes in v15:
- none
Changes in v14:
- rebased on v5.14-rc1 (with the rest of the series)
- added 'Reviewed-by' tag from Doug
Changes in v13:
- patch added to the series
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index f2e2b9bdd702..588ab6aef755 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -811,6 +811,7 @@ CONFIG_USB_OTG=y
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_PCI=m
CONFIG_USB_XHCI_PCI_RENESAS=m
+CONFIG_USB_XHCI_PLATFORM=y
CONFIG_USB_XHCI_TEGRA=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_EXYNOS=y
--
2.34.0.rc1.387.gb447b232ab-goog
Some USB controller drivers that depend on the xhci-plat driver
specify this dependency using 'select' in Kconfig. This is not
recommended for symbols that have other dependencies as it may
lead to invalid configurations. Use 'depends on' to specify the
dependency instead of 'select'.
For dwc3 specify the dependency on USB_XHCI_PLATFORM in
USB_DWC3_HOST and USB_DWC3_DUAL_ROLE. Also adjust the
dependencies of USB_DWC3_CORE to make sure that at least one
of USB_DWC3_HOST, USB_DWC3_GADGET or USB_DWC3_DUAL_ROLE can be
selected.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Roger Quadros <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
---
Changes in v17:
- removed explicit dependency on USB from USB_DWC3
- added 'Reviewed-by' tags from Roger and Doug
Changes in v16:
- none
Changes in v15:
- adjusted dependencies of USB_DWC3_CORE to make sure it can only
be enabled when at least one of USB_DWC3_HOST, USB_DWC3_GADGET
or USB_DWC3_DUAL_ROLE is selectable
- updated commit message
Changes in v14:
- none
Changes in v13:
- patch added to the series
drivers/usb/cdns3/Kconfig | 2 +-
drivers/usb/dwc3/Kconfig | 5 +++--
drivers/usb/host/Kconfig | 4 ++--
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/cdns3/Kconfig b/drivers/usb/cdns3/Kconfig
index b98ca0a1352a..07e12f786d48 100644
--- a/drivers/usb/cdns3/Kconfig
+++ b/drivers/usb/cdns3/Kconfig
@@ -1,7 +1,7 @@
config USB_CDNS_SUPPORT
tristate "Cadence USB Support"
depends on USB_SUPPORT && (USB || USB_GADGET) && HAS_DMA
- select USB_XHCI_PLATFORM if USB_XHCI_HCD
+ depends on !USB_XHCI_HCD || USB_XHCI_PLATFORM
select USB_ROLE_SWITCH
help
Say Y here if your system has a Cadence USBSS or USBSSP
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index c483f28b695d..8f08b0724379 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -2,8 +2,7 @@
config USB_DWC3
tristate "DesignWare USB3 DRD Core Support"
- depends on (USB || USB_GADGET) && HAS_DMA
- select USB_XHCI_PLATFORM if USB_XHCI_HCD
+ depends on (USB_XHCI_PLATFORM || USB_GADGET) && HAS_DMA
select USB_ROLE_SWITCH if USB_DWC3_DUAL_ROLE
help
Say Y or M here if your system has a Dual Role SuperSpeed
@@ -30,6 +29,7 @@ choice
config USB_DWC3_HOST
bool "Host only mode"
depends on USB=y || USB=USB_DWC3
+ depends on USB_XHCI_PLATFORM
help
Select this when you want to use DWC3 in host mode only,
thereby the gadget feature will be regressed.
@@ -44,6 +44,7 @@ config USB_DWC3_GADGET
config USB_DWC3_DUAL_ROLE
bool "Dual Role mode"
depends on ((USB=y || USB=USB_DWC3) && (USB_GADGET=y || USB_GADGET=USB_DWC3))
+ depends on USB_XHCI_PLATFORM
depends on (EXTCON=y || EXTCON=USB_DWC3)
help
This is the default mode of working of DWC3 controller where
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index d1d926f8f9c2..e5e612f143a1 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -80,7 +80,7 @@ config USB_XHCI_MTK
config USB_XHCI_MVEBU
tristate "xHCI support for Marvell Armada 375/38x/37xx"
- select USB_XHCI_PLATFORM
+ depends on USB_XHCI_PLATFORM
depends on HAS_IOMEM
depends on ARCH_MVEBU || COMPILE_TEST
help
@@ -112,9 +112,9 @@ config USB_EHCI_BRCMSTB
config USB_BRCMSTB
tristate "Broadcom STB USB support"
depends on (ARCH_BRCMSTB && PHY_BRCM_USB) || COMPILE_TEST
+ depends on !USB_XHCI_HCD || USB_XHCI_PLATFORM
select USB_OHCI_HCD_PLATFORM if USB_OHCI_HCD
select USB_EHCI_BRCMSTB if USB_EHCI_HCD
- select USB_XHCI_PLATFORM if USB_XHCI_HCD
help
Enables support for XHCI, EHCI and OHCI host controllers
found in Broadcom STB SoC's.
--
2.34.0.rc1.387.gb447b232ab-goog
On Tue, Nov 16, 2021 at 12:07:39PM -0800, Matthias Kaehlcke wrote:
> Some USB controller drivers that depend on the xhci-plat driver
> specify this dependency using 'select' in Kconfig. This is not
> recommended for symbols that have other dependencies as it may
> lead to invalid configurations. Use 'depends on' to specify the
> dependency instead of 'select'.
>
> For dwc3 specify the dependency on USB_XHCI_PLATFORM in
> USB_DWC3_HOST and USB_DWC3_DUAL_ROLE. Also adjust the
> dependencies of USB_DWC3_CORE to make sure that at least one
> of USB_DWC3_HOST, USB_DWC3_GADGET or USB_DWC3_DUAL_ROLE can be
> selected.
>
> Signed-off-by: Matthias Kaehlcke <[email protected]>
> Reviewed-by: Roger Quadros <[email protected]>
> Reviewed-by: Douglas Anderson <[email protected]>
> ---
>
> Changes in v17:
> - removed explicit dependency on USB from USB_DWC3
> - added 'Reviewed-by' tags from Roger and Doug
>
> Changes in v16:
> - none
>
> Changes in v15:
> - adjusted dependencies of USB_DWC3_CORE to make sure it can only
> be enabled when at least one of USB_DWC3_HOST, USB_DWC3_GADGET
> or USB_DWC3_DUAL_ROLE is selectable
> - updated commit message
>
> Changes in v14:
> - none
>
> Changes in v13:
> - patch added to the series
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index d1d926f8f9c2..e5e612f143a1 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -80,7 +80,7 @@ config USB_XHCI_MTK
>
> config USB_XHCI_MVEBU
> tristate "xHCI support for Marvell Armada 375/38x/37xx"
> - select USB_XHCI_PLATFORM
> + depends on USB_XHCI_PLATFORM
> depends on HAS_IOMEM
> depends on ARCH_MVEBU || COMPILE_TEST
> help
> @@ -112,9 +112,9 @@ config USB_EHCI_BRCMSTB
> config USB_BRCMSTB
> tristate "Broadcom STB USB support"
> depends on (ARCH_BRCMSTB && PHY_BRCM_USB) || COMPILE_TEST
> + depends on !USB_XHCI_HCD || USB_XHCI_PLATFORM
> select USB_OHCI_HCD_PLATFORM if USB_OHCI_HCD
> select USB_EHCI_BRCMSTB if USB_EHCI_HCD
> - select USB_XHCI_PLATFORM if USB_XHCI_HCD
> help
> Enables support for XHCI, EHCI and OHCI host controllers
> found in Broadcom STB SoC's.
It should be pointed out that this now requires people with xHCI systems
to actively turn on CONFIG_USB_XHCI_PLATFORM before they can enable
CONFIG_USB_BRCMSTB. Before, that was not necessary. Some users might
get confused and not realize what is needed. Perhaps something should
be added to the "help" text.
Alan Stern
Hi,
On Tue, Nov 16, 2021 at 12:07 PM Matthias Kaehlcke <[email protected]> wrote:
>
> Add nodes for the onboard USB hub on trogdor devices. Remove the
> 'always-on' property from the hub regulator, since the regulator
> is now managed by the onboard_usb_hub driver.
>
> Signed-off-by: Matthias Kaehlcke <[email protected]>
> ---
>
> Changes in v17:
> - none
>
> Changes in v16:
> - none
>
> Changes in v15:
> - none
>
> Changes in v14:
> - none
>
> Changes in v13:
> - none
>
> Changes in v12:
> - none
>
> Changes in v11:
> - rebased on qcom/arm64-for-5.14 (with the rest of the series)
>
> Changes in v10:
> - keep 'regulator-boot-on' property
> - updated commit message
>
> Changes in v9:
> - none
>
> Changes in v8:
> - none
>
> Changes in v7:
> - rebased on qcom/arm64-for-5.13 (with the rest of the series)
>
> Changes in v6:
> - added 'companion-hub' entry to both USB devices
> - added 'vdd-supply' also to hub@2
>
> Changes in v5:
> - patch added to the series
>
> .../boot/dts/qcom/sc7180-trogdor-lazor-r0.dts | 19 ++++++++-----------
> .../boot/dts/qcom/sc7180-trogdor-lazor-r1.dts | 12 +++++-------
> .../arm64/boot/dts/qcom/sc7180-trogdor-r1.dts | 19 ++++++++-----------
> arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 19 ++++++++++++++++++-
> 4 files changed, 39 insertions(+), 30 deletions(-)
sc7180-trogdor-pompom-r1.dts is missing? It seems to need similar
fixups to the early lazor/trogdor borads.
Other than that this looks good to me.
-Doug
Hi,
On Tue, Nov 16, 2021 at 12:07 PM Matthias Kaehlcke <[email protected]> wrote:
>
> Call onboard_hub_create/destroy_pdevs() from usb_add/remove_hcd()
> for primary HCDs to create/destroy platform devices for onboard
> USB hubs that may be connected to the root hub of the controller.
> These functions are a NOP unless CONFIG_USB_ONBOARD_HUB=y/m.
>
> Also add a field to struct usb_hcd to keep track of the onboard hub
> platform devices that are owned by the HCD.
>
> Signed-off-by: Matthias Kaehlcke <[email protected]>
> ---
>
> Changes in v17:
> - create the platform devices in the generic HCD code instead of
> the xhci_platform driver
> - updated subject and commit message to reflect the above change
> - dropped initialization of platform device list, which is now
> done in onboard_hub_create_pdevs()
>
> Changes in v16:
> - none
>
> Changes in v15:
> - none
>
> Changes in v14:
> - none
>
> Changes in v13:
> - added comment for 'depends on USB_ONBOARD_HUB || !USB_ONBOARD_HUB'
> construct
>
> Changes in v12:
> - none
>
> Changes in v11:
> - use onboard_hub_create/destroy_pdevs() to support multiple onboard
> hubs that are connected to the same root hub
> - moved field/list to keep track of platform devices from struct
> usb_hcd to struct xhci_hcd
> - updated commit message
>
> Changes in v10:
> - none
>
> Changes in v9:
> - added dependency on USB_ONBOARD_HUB (or !!USB_ONBOARD_HUB) to
> USB_XHCI_PLATFORM
>
> Changes in v8:
> - none
>
> Changes in v7:
> - none
>
> Changes in v6:
> - none
>
> Changes in v5:
> - patch added to the series
>
> drivers/usb/core/hcd.c | 6 ++++++
> include/linux/usb/hcd.h | 1 +
> 2 files changed, 7 insertions(+)
This looks sane to me, so:
Reviewed-by: Douglas Anderson <[email protected]>
That being said, I don't know these functions and can't say with any
authority that this is the "right" place to put the
onboard_hub_create_pdevs() and onboard_hub_destroy_pdevs(). I'm
assuming that Alan, Greg, or someone else on this CC list will
scrutinize that more closely and make sure where Matthias picked is
OK.
-Doug
Hi,
On Tue, Nov 16, 2021 at 12:07 PM Matthias Kaehlcke <[email protected]> wrote:
>
> --- a/drivers/usb/misc/Kconfig
> +++ b/drivers/usb/misc/Kconfig
> @@ -284,3 +284,20 @@ config BRCM_USB_PINMAP
> This option enables support for remapping some USB external
> signals, which are typically on dedicated pins on the chip,
> to any gpio.
> +
> +config USB_ONBOARD_HUB
> + tristate "Onboard USB hub support"
Aren't you back to shenanigans now that you're being called straight
from the USB core? What if you're a module and the USB core is
builtin? It can't call you, right? ...or what if you're builtin but
the USB core is a module (yeah, I know that sounds insane but I don't
think anything technically prevents it)?
Can you just add a dependency here such that if the USB core is a
module that you're a module and if the USB core is builtin that you're
builtin?
> +void onboard_hub_create_pdevs(struct usb_device *parent_hub, struct list_head *pdev_list)
> +{
> + int i;
> + struct device_node *np, *npc;
> + struct platform_device *pdev;
> + struct pdev_list_entry *pdle;
> +
> + INIT_LIST_HEAD(pdev_list);
> +
> + for (i = 1; i <= parent_hub->maxchild; i++) {
> + np = usb_of_get_device_node(parent_hub, i);
> + if (!np)
> + continue;
> +
> + if (!of_is_onboard_usb_hub(np))
> + goto node_put;
> +
> + npc = of_parse_phandle(np, "companion-hub", 0);
> + if (!npc)
> + goto create_pdev;
> +
> + pdev = of_find_device_by_node(npc);
> + of_node_put(npc);
> +
> + if (pdev) {
> + /* the companion hub already has a platform device, nothing to do here */
> + put_device(&pdev->dev);
> + goto node_put;
> + }
> +
> +create_pdev:
I don't really like this "goto". I'd rather just use an "if" test for
the few lines even if the indentation gets to be a bit much.
-Doug
On Tue, Nov 16, 2021 at 09:21:44PM -0500, Alan Stern wrote:
> On Tue, Nov 16, 2021 at 12:07:39PM -0800, Matthias Kaehlcke wrote:
> > Some USB controller drivers that depend on the xhci-plat driver
> > specify this dependency using 'select' in Kconfig. This is not
> > recommended for symbols that have other dependencies as it may
> > lead to invalid configurations. Use 'depends on' to specify the
> > dependency instead of 'select'.
> >
> > For dwc3 specify the dependency on USB_XHCI_PLATFORM in
> > USB_DWC3_HOST and USB_DWC3_DUAL_ROLE. Also adjust the
> > dependencies of USB_DWC3_CORE to make sure that at least one
> > of USB_DWC3_HOST, USB_DWC3_GADGET or USB_DWC3_DUAL_ROLE can be
> > selected.
> >
> > Signed-off-by: Matthias Kaehlcke <[email protected]>
> > Reviewed-by: Roger Quadros <[email protected]>
> > Reviewed-by: Douglas Anderson <[email protected]>
> > ---
> >
> > Changes in v17:
> > - removed explicit dependency on USB from USB_DWC3
> > - added 'Reviewed-by' tags from Roger and Doug
> >
> > Changes in v16:
> > - none
> >
> > Changes in v15:
> > - adjusted dependencies of USB_DWC3_CORE to make sure it can only
> > be enabled when at least one of USB_DWC3_HOST, USB_DWC3_GADGET
> > or USB_DWC3_DUAL_ROLE is selectable
> > - updated commit message
> >
> > Changes in v14:
> > - none
> >
> > Changes in v13:
> > - patch added to the series
>
> > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> > index d1d926f8f9c2..e5e612f143a1 100644
> > --- a/drivers/usb/host/Kconfig
> > +++ b/drivers/usb/host/Kconfig
> > @@ -80,7 +80,7 @@ config USB_XHCI_MTK
> >
> > config USB_XHCI_MVEBU
> > tristate "xHCI support for Marvell Armada 375/38x/37xx"
> > - select USB_XHCI_PLATFORM
> > + depends on USB_XHCI_PLATFORM
> > depends on HAS_IOMEM
> > depends on ARCH_MVEBU || COMPILE_TEST
> > help
> > @@ -112,9 +112,9 @@ config USB_EHCI_BRCMSTB
> > config USB_BRCMSTB
> > tristate "Broadcom STB USB support"
> > depends on (ARCH_BRCMSTB && PHY_BRCM_USB) || COMPILE_TEST
> > + depends on !USB_XHCI_HCD || USB_XHCI_PLATFORM
> > select USB_OHCI_HCD_PLATFORM if USB_OHCI_HCD
> > select USB_EHCI_BRCMSTB if USB_EHCI_HCD
> > - select USB_XHCI_PLATFORM if USB_XHCI_HCD
> > help
> > Enables support for XHCI, EHCI and OHCI host controllers
> > found in Broadcom STB SoC's.
>
> It should be pointed out that this now requires people with xHCI systems
> to actively turn on CONFIG_USB_XHCI_PLATFORM before they can enable
> CONFIG_USB_BRCMSTB. Before, that was not necessary. Some users might
> get confused and not realize what is needed. Perhaps something should
> be added to the "help" text.
I agree that the change could cause confusion, I'm not sure though if
adding something to the "help" text is a good mitigation. Users won't see
the text unless they can select the option, which requires
CONFIG_USB_XHCI_PLATFORM to be enabled. Also the dependencies are specified
nearby (and displayed), so it seems similar to a code comment on something
that the code evidently does (e.g. "initialize foobar with 0").
On a different note: I'm considering to break the CONFIG_USB_XHCI_PLATFORM
related patches out of the onboard_usb_hub series, since the driver
doesn't any longer depend on xhci_plat. In that sense I'm also open
to abandon those patches, if they aren't considered an improvement on
their own.
On Wed, Nov 17, 2021 at 04:11:34PM -0800, Doug Anderson wrote:
> Hi,
>
> On Tue, Nov 16, 2021 at 12:07 PM Matthias Kaehlcke <[email protected]> wrote:
> >
> > --- a/drivers/usb/misc/Kconfig
> > +++ b/drivers/usb/misc/Kconfig
> > @@ -284,3 +284,20 @@ config BRCM_USB_PINMAP
> > This option enables support for remapping some USB external
> > signals, which are typically on dedicated pins on the chip,
> > to any gpio.
> > +
> > +config USB_ONBOARD_HUB
> > + tristate "Onboard USB hub support"
>
> Aren't you back to shenanigans now that you're being called straight
> from the USB core? What if you're a module and the USB core is
> builtin? It can't call you, right? ...or what if you're builtin but
> the USB core is a module (yeah, I know that sounds insane but I don't
> think anything technically prevents it)?
Indeed, a dependency involving USB host mode is needed, as previously
with xhci_plat.
> Can you just add a dependency here such that if the USB core is a
> module that you're a module and if the USB core is builtin that you're
> builtin?
I couldn't find a way to specify that in the config options of the driver
itself. I fear the dependency has to be specified in CONFIG_USB, like it
was done previously with USB_XHCI_PLATFORM:
https://patchwork.kernel.org/project/linux-usb/patch/20210813125146.v16.6.I7a3a7d9d2126c34079b1cab87aa0b2ec3030f9b7@changeid/
Hope that isn't controversial.
> > +void onboard_hub_create_pdevs(struct usb_device *parent_hub, struct list_head *pdev_list)
> > +{
> > + int i;
> > + struct device_node *np, *npc;
> > + struct platform_device *pdev;
> > + struct pdev_list_entry *pdle;
> > +
> > + INIT_LIST_HEAD(pdev_list);
> > +
> > + for (i = 1; i <= parent_hub->maxchild; i++) {
> > + np = usb_of_get_device_node(parent_hub, i);
> > + if (!np)
> > + continue;
> > +
> > + if (!of_is_onboard_usb_hub(np))
> > + goto node_put;
> > +
> > + npc = of_parse_phandle(np, "companion-hub", 0);
> > + if (!npc)
> > + goto create_pdev;
> > +
> > + pdev = of_find_device_by_node(npc);
> > + of_node_put(npc);
> > +
> > + if (pdev) {
> > + /* the companion hub already has a platform device, nothing to do here */
> > + put_device(&pdev->dev);
> > + goto node_put;
> > + }
> > +
> > +create_pdev:
>
> I don't really like this "goto". I'd rather just use an "if" test for
> the few lines even if the indentation gets to be a bit much.
Ok, I'll remove the "goto" in the next version.
Hi Matthias,
I love your patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on driver-core/driver-core-testing linus/master v5.16-rc1 next-20211118]
[cannot apply to usb/usb-testing]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Matthias-Kaehlcke/usb-misc-Add-onboard_usb_hub-driver/20211117-040918
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/faa2d834f6d4083b63ab466134738d1befaa83b6
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Matthias-Kaehlcke/usb-misc-Add-onboard_usb_hub-driver/20211117-040918
git checkout faa2d834f6d4083b63ab466134738d1befaa83b6
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross ARCH=m68k
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <[email protected]>
All errors (new ones prefixed by >>, old ones prefixed by <<):
>> ERROR: modpost: "device_is_bound" [drivers/usb/misc/onboard_usb_hub.ko] undefined!
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/[email protected]
On Fri, Nov 19, 2021 at 02:13:52AM +0800, kernel test robot wrote:
> Hi Matthias,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on robh/for-next]
> [also build test ERROR on driver-core/driver-core-testing linus/master v5.16-rc1 next-20211118]
> [cannot apply to usb/usb-testing]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
>
> url: https://github.com/0day-ci/linux/commits/Matthias-Kaehlcke/usb-misc-Add-onboard_usb_hub-driver/20211117-040918
> base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
> config: m68k-allmodconfig (attached as .config)
> compiler: m68k-linux-gcc (GCC) 11.2.0
> reproduce (this is a W=1 build):
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # https://github.com/0day-ci/linux/commit/faa2d834f6d4083b63ab466134738d1befaa83b6
> git remote add linux-review https://github.com/0day-ci/linux
> git fetch --no-tags linux-review Matthias-Kaehlcke/usb-misc-Add-onboard_usb_hub-driver/20211117-040918
> git checkout faa2d834f6d4083b63ab466134738d1befaa83b6
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross ARCH=m68k
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <[email protected]>
>
> All errors (new ones prefixed by >>, old ones prefixed by <<):
>
> >> ERROR: modpost: "device_is_bound" [drivers/usb/misc/onboard_usb_hub.ko] undefined!
Looks like device_is_bound() needs to be exported to use it from a module.
On Wed, Nov 17, 2021 at 04:03:10PM -0800, Doug Anderson wrote:
> Hi,
>
> On Tue, Nov 16, 2021 at 12:07 PM Matthias Kaehlcke <[email protected]> wrote:
> >
> > Add nodes for the onboard USB hub on trogdor devices. Remove the
> > 'always-on' property from the hub regulator, since the regulator
> > is now managed by the onboard_usb_hub driver.
> >
> > Signed-off-by: Matthias Kaehlcke <[email protected]>
> > ---
> >
> > Changes in v17:
> > - none
> >
> > Changes in v16:
> > - none
> >
> > Changes in v15:
> > - none
> >
> > Changes in v14:
> > - none
> >
> > Changes in v13:
> > - none
> >
> > Changes in v12:
> > - none
> >
> > Changes in v11:
> > - rebased on qcom/arm64-for-5.14 (with the rest of the series)
> >
> > Changes in v10:
> > - keep 'regulator-boot-on' property
> > - updated commit message
> >
> > Changes in v9:
> > - none
> >
> > Changes in v8:
> > - none
> >
> > Changes in v7:
> > - rebased on qcom/arm64-for-5.13 (with the rest of the series)
> >
> > Changes in v6:
> > - added 'companion-hub' entry to both USB devices
> > - added 'vdd-supply' also to hub@2
> >
> > Changes in v5:
> > - patch added to the series
> >
> > .../boot/dts/qcom/sc7180-trogdor-lazor-r0.dts | 19 ++++++++-----------
> > .../boot/dts/qcom/sc7180-trogdor-lazor-r1.dts | 12 +++++-------
> > .../arm64/boot/dts/qcom/sc7180-trogdor-r1.dts | 19 ++++++++-----------
> > arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 19 ++++++++++++++++++-
> > 4 files changed, 39 insertions(+), 30 deletions(-)
>
> sc7180-trogdor-pompom-r1.dts is missing? It seems to need similar
> fixups to the early lazor/trogdor borads.
ack, also needs to be done for pompom rev1, thanks for pointing that out!
On Tue, Nov 16, 2021 at 12:07:34PM -0800, Matthias Kaehlcke wrote:
> Code for platform_device_create() and of_platform_device_destroy() is
> only generated if CONFIG_OF_ADDRESS=y. Add stubs to avoid unresolved
> symbols when CONFIG_OF_ADDRESS is not set.
>
> Signed-off-by: Matthias Kaehlcke <[email protected]>
> Acked-by: Rob Herring <[email protected]>
Is anything preventing this patch from landing? It has Rob's ack and is
an improvement regardless of the fate of the rest of the series it is
part of. The patch was carried around unchanged in the last 10 versions
of the series, it would be nice if it could just get landed instead of
keep carrying it around :)
On Mon, Nov 22, 2021 at 09:43:57AM -0800, Matthias Kaehlcke wrote:
> On Tue, Nov 16, 2021 at 12:07:34PM -0800, Matthias Kaehlcke wrote:
> > Code for platform_device_create() and of_platform_device_destroy() is
> > only generated if CONFIG_OF_ADDRESS=y. Add stubs to avoid unresolved
> > symbols when CONFIG_OF_ADDRESS is not set.
> >
> > Signed-off-by: Matthias Kaehlcke <[email protected]>
> > Acked-by: Rob Herring <[email protected]>
>
> Is anything preventing this patch from landing? It has Rob's ack and is
> an improvement regardless of the fate of the rest of the series it is
> part of. The patch was carried around unchanged in the last 10 versions
> of the series, it would be nice if it could just get landed instead of
> keep carrying it around :)
ping
Rob/Frank: is there any reason why this patch can't be landed?
Thanks
Matthias
On Thu, Nov 18, 2021 at 09:52:28AM -0800, Matthias Kaehlcke wrote:
> On Wed, Nov 17, 2021 at 04:11:34PM -0800, Doug Anderson wrote:
> > Hi,
> >
> > On Tue, Nov 16, 2021 at 12:07 PM Matthias Kaehlcke <[email protected]> wrote:
> > >
> > > --- a/drivers/usb/misc/Kconfig
> > > +++ b/drivers/usb/misc/Kconfig
> > > @@ -284,3 +284,20 @@ config BRCM_USB_PINMAP
> > > This option enables support for remapping some USB external
> > > signals, which are typically on dedicated pins on the chip,
> > > to any gpio.
> > > +
> > > +config USB_ONBOARD_HUB
> > > + tristate "Onboard USB hub support"
> >
> > Aren't you back to shenanigans now that you're being called straight
> > from the USB core? What if you're a module and the USB core is
> > builtin? It can't call you, right? ...or what if you're builtin but
> > the USB core is a module (yeah, I know that sounds insane but I don't
> > think anything technically prevents it)?
>
> Indeed, a dependency involving USB host mode is needed, as previously
> with xhci_plat.
>
> > Can you just add a dependency here such that if the USB core is a
> > module that you're a module and if the USB core is builtin that you're
> > builtin?
>
> I couldn't find a way to specify that in the config options of the driver
> itself. I fear the dependency has to be specified in CONFIG_USB, like it
> was done previously with USB_XHCI_PLATFORM:
>
> https://patchwork.kernel.org/project/linux-usb/patch/20210813125146.v16.6.I7a3a7d9d2126c34079b1cab87aa0b2ec3030f9b7@changeid/
>
> Hope that isn't controversial.
Ugh, actually adding
depends on USB_ONBOARD_HUB || !USB_ONBOARD_HUB
to CONFIG_USB does not work. The problem is that USB_ONBOARD_HUB depends on
CONFIG_USB (not through an explicit dependency, but the 'misc' directory it
resides in is only included when CONFIG_USB=y/m), so the above rule would
introduce a circular dependency.
Unless there is some other way to specify "don't allow building
USB_ONBOARD_HUB as a module, unless USB is a module" I fear USB_ONBOARD_HUB
must be bool, which isn't really great :(
On Tue, Nov 16, 2021 at 12:07:39PM -0800, Matthias Kaehlcke wrote:
> Some USB controller drivers that depend on the xhci-plat driver
> specify this dependency using 'select' in Kconfig. This is not
> recommended for symbols that have other dependencies as it may
> lead to invalid configurations. Use 'depends on' to specify the
> dependency instead of 'select'.
>
> For dwc3 specify the dependency on USB_XHCI_PLATFORM in
> USB_DWC3_HOST and USB_DWC3_DUAL_ROLE. Also adjust the
> dependencies of USB_DWC3_CORE to make sure that at least one
> of USB_DWC3_HOST, USB_DWC3_GADGET or USB_DWC3_DUAL_ROLE can be
> selected.
>
> Signed-off-by: Matthias Kaehlcke <[email protected]>
> Reviewed-by: Roger Quadros <[email protected]>
> Reviewed-by: Douglas Anderson <[email protected]>
Note: This patch has been removed from the onboard_usb_hub series,
together with "ARM: configs: Explicitly enable USB_XHCI_PLATFORM
where needed" and "arm64: defconfig: Explicitly enable
USB_XHCI_PLATFORM". These patches aren't any longer needed for the
series. If maintainers think they are useful independently from
the series please pick them or let me know what needs to be
changed to get them landed.
17.12.2021 02:56, Matthias Kaehlcke пишет:
> On Tue, Nov 16, 2021 at 12:07:39PM -0800, Matthias Kaehlcke wrote:
>> Some USB controller drivers that depend on the xhci-plat driver
>> specify this dependency using 'select' in Kconfig. This is not
>> recommended for symbols that have other dependencies as it may
>> lead to invalid configurations. Use 'depends on' to specify the
>> dependency instead of 'select'.
>>
>> For dwc3 specify the dependency on USB_XHCI_PLATFORM in
>> USB_DWC3_HOST and USB_DWC3_DUAL_ROLE. Also adjust the
>> dependencies of USB_DWC3_CORE to make sure that at least one
>> of USB_DWC3_HOST, USB_DWC3_GADGET or USB_DWC3_DUAL_ROLE can be
>> selected.
>>
>> Signed-off-by: Matthias Kaehlcke <[email protected]>
>> Reviewed-by: Roger Quadros <[email protected]>
>> Reviewed-by: Douglas Anderson <[email protected]>
>
> Note: This patch has been removed from the onboard_usb_hub series,
> together with "ARM: configs: Explicitly enable USB_XHCI_PLATFORM
> where needed" and "arm64: defconfig: Explicitly enable
> USB_XHCI_PLATFORM". These patches aren't any longer needed for the
> series. If maintainers think they are useful independently from
> the series please pick them or let me know what needs to be
> changed to get them landed.
>
Hi,
I don't know what this all is about, perhaps I'm CC'ed semi-randomly
because touched that Kconfig once.
All I can say here is that the commit message tells us "This is not
recommended" and doesn't explain what's the actual problem is being
solved. If there is no real problem, why bother?
On Fri, Dec 17, 2021 at 03:47:24AM +0300, Dmitry Osipenko wrote:
> 17.12.2021 02:56, Matthias Kaehlcke пишет:
> > On Tue, Nov 16, 2021 at 12:07:39PM -0800, Matthias Kaehlcke wrote:
> >> Some USB controller drivers that depend on the xhci-plat driver
> >> specify this dependency using 'select' in Kconfig. This is not
> >> recommended for symbols that have other dependencies as it may
> >> lead to invalid configurations. Use 'depends on' to specify the
> >> dependency instead of 'select'.
> >>
> >> For dwc3 specify the dependency on USB_XHCI_PLATFORM in
> >> USB_DWC3_HOST and USB_DWC3_DUAL_ROLE. Also adjust the
> >> dependencies of USB_DWC3_CORE to make sure that at least one
> >> of USB_DWC3_HOST, USB_DWC3_GADGET or USB_DWC3_DUAL_ROLE can be
> >> selected.
> >>
> >> Signed-off-by: Matthias Kaehlcke <[email protected]>
> >> Reviewed-by: Roger Quadros <[email protected]>
> >> Reviewed-by: Douglas Anderson <[email protected]>
> >
> > Note: This patch has been removed from the onboard_usb_hub series,
> > together with "ARM: configs: Explicitly enable USB_XHCI_PLATFORM
> > where needed" and "arm64: defconfig: Explicitly enable
> > USB_XHCI_PLATFORM". These patches aren't any longer needed for the
> > series. If maintainers think they are useful independently from
> > the series please pick them or let me know what needs to be
> > changed to get them landed.
> >
>
> Hi,
>
> I don't know what this all is about, perhaps I'm CC'ed semi-randomly
> because touched that Kconfig once.
Yes, it seems tools select you based on their heuristics because you
made changes to that file.
> All I can say here is that the commit message tells us "This is not
> recommended" and doesn't explain what's the actual problem is being
> solved. If there is no real problem, why bother?
Earlier versions of the onboard_usb_hub series [1] which had a dependency
involving USB_XHCI_PLATFORM had an issue with invalid (rand)configs
that was related with the 'selects'.
The series doesn't depend on USB_XHCI_PLATFORM any longer, hence the
original issue doesn't exist anymore, however it might re-surface in
the future.
Personally I have no vested interest at this point in getting the
config changes landed, I just wanted to make clear what the status
is (split off from the series, no future versions unless someone
requests them), rather than abandoning them silently.
[1]: https://patchwork.kernel.org/project/linux-usb/list/?series=531343
20.12.2021 21:44, Matthias Kaehlcke пишет:
> On Fri, Dec 17, 2021 at 03:47:24AM +0300, Dmitry Osipenko wrote:
>> 17.12.2021 02:56, Matthias Kaehlcke пишет:
>>> On Tue, Nov 16, 2021 at 12:07:39PM -0800, Matthias Kaehlcke wrote:
>>>> Some USB controller drivers that depend on the xhci-plat driver
>>>> specify this dependency using 'select' in Kconfig. This is not
>>>> recommended for symbols that have other dependencies as it may
>>>> lead to invalid configurations. Use 'depends on' to specify the
>>>> dependency instead of 'select'.
>>>>
>>>> For dwc3 specify the dependency on USB_XHCI_PLATFORM in
>>>> USB_DWC3_HOST and USB_DWC3_DUAL_ROLE. Also adjust the
>>>> dependencies of USB_DWC3_CORE to make sure that at least one
>>>> of USB_DWC3_HOST, USB_DWC3_GADGET or USB_DWC3_DUAL_ROLE can be
>>>> selected.
>>>>
>>>> Signed-off-by: Matthias Kaehlcke <[email protected]>
>>>> Reviewed-by: Roger Quadros <[email protected]>
>>>> Reviewed-by: Douglas Anderson <[email protected]>
>>>
>>> Note: This patch has been removed from the onboard_usb_hub series,
>>> together with "ARM: configs: Explicitly enable USB_XHCI_PLATFORM
>>> where needed" and "arm64: defconfig: Explicitly enable
>>> USB_XHCI_PLATFORM". These patches aren't any longer needed for the
>>> series. If maintainers think they are useful independently from
>>> the series please pick them or let me know what needs to be
>>> changed to get them landed.
>>>
>>
>> Hi,
>>
>> I don't know what this all is about, perhaps I'm CC'ed semi-randomly
>> because touched that Kconfig once.
>
> Yes, it seems tools select you based on their heuristics because you
> made changes to that file.
>
>> All I can say here is that the commit message tells us "This is not
>> recommended" and doesn't explain what's the actual problem is being
>> solved. If there is no real problem, why bother?
>
> Earlier versions of the onboard_usb_hub series [1] which had a dependency
> involving USB_XHCI_PLATFORM had an issue with invalid (rand)configs
> that was related with the 'selects'.
>
> The series doesn't depend on USB_XHCI_PLATFORM any longer, hence the
> original issue doesn't exist anymore, however it might re-surface in
> the future.
>
> Personally I have no vested interest at this point in getting the
> config changes landed, I just wanted to make clear what the status
> is (split off from the series, no future versions unless someone
> requests them), rather than abandoning them silently.
>
> [1]: https://patchwork.kernel.org/project/linux-usb/list/?series=531343
>
My point is that you should always explain in a commit message what
problem is being solved and how it's solved. There is no explanation of
the problem in the commit of this patch. If there is no real problem and
patch is a minor improvement, then it also should be explained explicitly.
16.11.2021 23:07, Matthias Kaehlcke пишет:
> +static const struct usb_device_id onboard_hub_id_table[] = {
> + { USB_DEVICE(VENDOR_ID_REALTEK, 0x0411) }, /* RTS0411 USB 3.0 */
> + { USB_DEVICE(VENDOR_ID_REALTEK, 0x5411) }, /* RTS5411 USB 2.0 */
> + {},
> +};
RTS5411 two times in the comments? Internet suggests that RTS5411 is USB 3.0
Are these hubs expected to be powered-on only when upstream port is
enabled? Shouldn't runtime PM be used for that somehow?
On Mon, Dec 20, 2021 at 11:05:28PM +0300, Dmitry Osipenko wrote:
> 16.11.2021 23:07, Matthias Kaehlcke пишет:
> > +static const struct usb_device_id onboard_hub_id_table[] = {
> > + { USB_DEVICE(VENDOR_ID_REALTEK, 0x0411) }, /* RTS0411 USB 3.0 */
> > + { USB_DEVICE(VENDOR_ID_REALTEK, 0x5411) }, /* RTS5411 USB 2.0 */
> > + {},
> > +};
>
> RTS5411 two times in the comments?
One time, the other is RTS0511
> Internet suggests that RTS5411 is USB 3.0
Correct, however the chip internally has two hubs, one for USB2 and one for
USB3:
Bus 002 Device 002: ID 0bda:0411 Realtek Semiconductor Corp. 4-Port USB 3.1 Hub
Bus 001 Device 002: ID 0bda:5411 Realtek Semiconductor Corp. 4-Port USB 2.1 Hub
> Are these hubs expected to be powered-on only when upstream port is
> enabled? Shouldn't runtime PM be used for that somehow?
In the general case I would expect that a onboard hub is connected to a port
that is enabled. For now I think it's fine to power the hub always when the
system is running (which is also the current situation with using always-on
regulators). If someone has an actual use case where the upstream port can
be disabled they can add support for that later.
30.12.2021 23:17, Matthias Kaehlcke пишет:
> On Mon, Dec 20, 2021 at 11:05:28PM +0300, Dmitry Osipenko wrote:
>> 16.11.2021 23:07, Matthias Kaehlcke пишет:
>>> +static const struct usb_device_id onboard_hub_id_table[] = {
>>> + { USB_DEVICE(VENDOR_ID_REALTEK, 0x0411) }, /* RTS0411 USB 3.0 */
>>> + { USB_DEVICE(VENDOR_ID_REALTEK, 0x5411) }, /* RTS5411 USB 2.0 */
>>> + {},
>>> +};
>>
>> RTS5411 two times in the comments?
>
> One time, the other is RTS0511
>
>> Internet suggests that RTS5411 is USB 3.0
>
> Correct, however the chip internally has two hubs, one for USB2 and one for
> USB3:
>
> Bus 002 Device 002: ID 0bda:0411 Realtek Semiconductor Corp. 4-Port USB 3.1 Hub
> Bus 001 Device 002: ID 0bda:5411 Realtek Semiconductor Corp. 4-Port USB 2.1 Hub
Alright, thanks.
>> Are these hubs expected to be powered-on only when upstream port is
>> enabled? Shouldn't runtime PM be used for that somehow?
>
> In the general case I would expect that a onboard hub is connected to a port
> that is enabled. For now I think it's fine to power the hub always when the
> system is running (which is also the current situation with using always-on
> regulators). If someone has an actual use case where the upstream port can
> be disabled they can add support for that later.
>
I see that you're handling the wakeup-capable devices during the
driver's suspend, perhaps it should work okay then.
BTW, shouldn't the "companion-hub" need to be turned into a generic USB
property? The onboard-usb-hub looks like a generic thing, but
"companion-hub" is specific to the RTS5411 binding.
On Sat, Jan 01, 2022 at 03:23:22PM +0300, Dmitry Osipenko wrote:
> 30.12.2021 23:17, Matthias Kaehlcke пишет:
> > On Mon, Dec 20, 2021 at 11:05:28PM +0300, Dmitry Osipenko wrote:
> >> 16.11.2021 23:07, Matthias Kaehlcke пишет:
> >>> +static const struct usb_device_id onboard_hub_id_table[] = {
> >>> + { USB_DEVICE(VENDOR_ID_REALTEK, 0x0411) }, /* RTS0411 USB 3.0 */
> >>> + { USB_DEVICE(VENDOR_ID_REALTEK, 0x5411) }, /* RTS5411 USB 2.0 */
> >>> + {},
> >>> +};
> >>
> >> RTS5411 two times in the comments?
> >
> > One time, the other is RTS0511
> >
> >> Internet suggests that RTS5411 is USB 3.0
> >
> > Correct, however the chip internally has two hubs, one for USB2 and one for
> > USB3:
> >
> > Bus 002 Device 002: ID 0bda:0411 Realtek Semiconductor Corp. 4-Port USB 3.1 Hub
> > Bus 001 Device 002: ID 0bda:5411 Realtek Semiconductor Corp. 4-Port USB 2.1 Hub
>
> Alright, thanks.
>
> >> Are these hubs expected to be powered-on only when upstream port is
> >> enabled? Shouldn't runtime PM be used for that somehow?
> >
> > In the general case I would expect that a onboard hub is connected to a port
> > that is enabled. For now I think it's fine to power the hub always when the
> > system is running (which is also the current situation with using always-on
> > regulators). If someone has an actual use case where the upstream port can
> > be disabled they can add support for that later.
> >
>
> I see that you're handling the wakeup-capable devices during the
> driver's suspend, perhaps it should work okay then.
>
> BTW, shouldn't the "companion-hub" need to be turned into a generic USB
> property? The onboard-usb-hub looks like a generic thing, but
> "companion-hub" is specific to the RTS5411 binding.
The series started with a generic binding, however Rob didn't like that. To my
knowledge there is currently no dedicated binding for USB hubs where such a
property could be added.