linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver
@ 2021-08-13 19:52 Matthias Kaehlcke
  2021-08-13 19:52 ` [PATCH v16 1/7] " Matthias Kaehlcke
                   ` (7 more replies)
  0 siblings, 8 replies; 28+ messages in thread
From: Matthias Kaehlcke @ 2021-08-13 19:52 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Alan Stern, Rob Herring, Frank Rowand,
	Mathias Nyman, Felipe Balbi
  Cc: devicetree, Peter Chen, linux-kernel, linux-usb, Bastien Nocera,
	Ravi Chandra Sadineni, Michal Simek, Douglas Anderson,
	Roger Quadros, Krzysztof Kozlowski, Stephen Boyd,
	Matthias Kaehlcke, Al Cooper, Al Viro, Alexandre Belloni,
	Alexandre Torgue, Andrew Lunn, Andrey Zhizhikin, Andy Gross,
	Arnd Bergmann, Aswath Govindraju, Bjorn Andersson,
	Catalin Marinas, Dmitry Baryshkov, Dmitry Osipenko, Dong Aisheng,
	Enric Balletbo i Serra, Fabio Estevam, Fabrice Gasnier,
	Florian Fainelli, Gregory Clement, Grygorii Strashko,
	Guido Günther, Jagan Teki, Jens Axboe, Johan Hovold,
	Krzysztof Kozlowski, Lad Prabhakar, Lionel Debieve,
	Manivannan Sadhasivam, Marek Szyprowski, Mark Brown,
	Martin Jücker, Nishanth Menon, Olivier Moysan,
	Pawel Laszczak, Robert Richter, Russell King,
	Sebastian Hesselbarth, Shawn Guo, Thomas Gleixner, Tony Lindgren,
	Vinod Koul, Viresh Kumar, Will Deacon, William Cohen,
	linux-arm-kernel, linux-arm-msm, linux-omap, linux-samsung-soc,
	Łukasz Stelmach

This series adds:
- the onboard_usb_hub_driver
- glue in the xhci-plat driver to create and destroy the
  onboard_usb_hub platform devices if needed
- a device tree binding for the Realtek RTS5411 USB hub controller
- 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 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()
  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'
  usb: host: xhci-plat: Create platform device for onboard hubs in
    probe()
  arm64: dts: qcom: sc7180-trogdor: Add nodes for onboard USB hub

 .../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/dwc3/Kconfig                      |   5 +-
 drivers/usb/host/Kconfig                      |   5 +-
 drivers/usb/host/xhci-plat.c                  |   6 +
 drivers/usb/host/xhci.h                       |   2 +
 drivers/usb/misc/Kconfig                      |  17 +
 drivers/usb/misc/Makefile                     |   1 +
 drivers/usb/misc/onboard_usb_hub.c            | 497 ++++++++++++++++++
 include/linux/of_platform.h                   |  22 +-
 include/linux/usb/onboard_hub.h               |  18 +
 23 files changed, 627 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.33.0.rc1.237.g0d66db33f3-goog


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH v16 1/7] usb: misc: Add onboard_usb_hub driver
  2021-08-13 19:52 [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver Matthias Kaehlcke
@ 2021-08-13 19:52 ` Matthias Kaehlcke
  2021-11-11 23:31   ` Doug Anderson
  2021-08-13 19:52 ` [PATCH v16 2/7] of/platform: Add stubs for of_platform_device_create/destroy() Matthias Kaehlcke
                   ` (6 subsequent siblings)
  7 siblings, 1 reply; 28+ messages in thread
From: Matthias Kaehlcke @ 2021-08-13 19:52 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Alan Stern, Rob Herring, Frank Rowand,
	Mathias Nyman, Felipe Balbi
  Cc: devicetree, Peter Chen, linux-kernel, linux-usb, Bastien Nocera,
	Ravi Chandra Sadineni, Michal Simek, Douglas Anderson,
	Roger Quadros, Krzysztof Kozlowski, Stephen Boyd,
	Matthias Kaehlcke, Al Cooper

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 (through xhci-plat), support for other configurations
could be added if needed.

Co-developed-by: Ravi Chandra Sadineni <ravisadineni@chromium.org>
Signed-off-by: Ravi Chandra Sadineni <ravisadineni@chromium.org>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
---

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            | 497 ++++++++++++++++++
 include/linux/usb/onboard_hub.h               |  18 +
 6 files changed, 548 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..e981d83648e6
--- /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:		March 2021
+KernelVersion:	5.13
+Contact:	Matthias Kaehlcke <matthias@kaehlcke.net>
+		linux-usb@vger.kernel.org
+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 a61f4f3b78a9..b19b990a07c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13796,6 +13796,13 @@ S:	Maintained
 T:	git git://linuxtv.org/media_tree.git
 F:	drivers/media/i2c/ov9734.c
 
+ONBOARD USB HUB DRIVER
+M:	Matthias Kaehlcke <mka@chromium.org>
+L:	linux-usb@vger.kernel.org
+S:	Maintained
+F:	Documentation/devicetree/bindings/usb/onboard_usb_hub.yaml
+F:	drivers/usb/misc/onboard_usb_hub.c
+
 ONENAND FLASH DRIVER
 M:	Kyungmin Park <kyungmin.park@samsung.com>
 L:	linux-mtd@lists.infradead.org
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..ed1f5424ea5f
--- /dev/null
+++ b/drivers/usb/misc/onboard_usb_hub.c
@@ -0,0 +1,497 @@
+// 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 udev_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 udev_node *node;
+	bool power_off;
+	int rc = 0;
+
+	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)
+		rc = onboard_hub_power_off(hub);
+
+	return rc;
+}
+
+static int __maybe_unused onboard_hub_resume(struct device *dev)
+{
+	struct onboard_hub *hub = dev_get_drvdata(dev);
+	int rc = 0;
+
+	if (!hub->is_powered_on)
+		rc = onboard_hub_power_on(hub);
+
+	return rc;
+}
+
+static int onboard_hub_add_usbdev(struct onboard_hub *hub, struct usb_device *udev)
+{
+	struct udev_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);
+
+	snprintf(link_name, sizeof(link_name), "usb_dev.%s", dev_name(&udev->dev));
+	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 udev_node *node;
+	char link_name[64];
+
+	snprintf(link_name, sizeof(link_name), "usb_dev.%s", dev_name(&udev->dev));
+	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 udev_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 udev_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;
+	phandle ph;
+
+	pdev = of_find_device_by_node(dev->of_node);
+	if (!pdev) {
+		if (of_property_read_u32(dev->of_node, "companion-hub", &ph)) {
+			dev_err(dev, "failed to read 'companion-hub' property\n");
+			return ERR_PTR(-EINVAL);
+		}
+
+		np = of_find_node_by_phandle(ph);
+		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)
+			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;
+	phandle ph;
+	struct device_node *np, *npc;
+	struct platform_device *pdev;
+	struct pdev_list_entry *pdle;
+
+	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;
+
+		if (of_property_read_u32(np, "companion-hub", &ph))
+			goto node_put;
+
+		npc = of_find_node_by_phandle(ph);
+		if (!npc)
+			goto node_put;
+
+		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;
+		}
+
+		pdev = of_platform_device_create(np, NULL, &parent_hub->dev);
+		if (pdev) {
+			pdle = kzalloc(sizeof(*pdle), GFP_KERNEL);
+			if (!pdle)
+				goto node_put;
+
+			INIT_LIST_HEAD(&pdle->node);
+
+			pdle->pdev = pdev;
+			list_add(&pdle->node, pdev_list);
+		} else {
+			dev_err(&parent_hub->dev,
+				"failed to create platform device for onboard hub '%s'\n",
+				of_node_full_name(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) {
+		of_platform_device_destroy(&pdle->pdev->dev, NULL);
+		kfree(pdle);
+	}
+}
+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 <mka@chromium.org>");
+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.33.0.rc1.237.g0d66db33f3-goog


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH v16 2/7] of/platform: Add stubs for of_platform_device_create/destroy()
  2021-08-13 19:52 [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver Matthias Kaehlcke
  2021-08-13 19:52 ` [PATCH v16 1/7] " Matthias Kaehlcke
@ 2021-08-13 19:52 ` Matthias Kaehlcke
  2021-08-13 19:52 ` [PATCH v16 3/7] ARM: configs: Explicitly enable USB_XHCI_PLATFORM where needed Matthias Kaehlcke
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 28+ messages in thread
From: Matthias Kaehlcke @ 2021-08-13 19:52 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Alan Stern, Rob Herring, Frank Rowand,
	Mathias Nyman, Felipe Balbi
  Cc: devicetree, Peter Chen, linux-kernel, linux-usb, Bastien Nocera,
	Ravi Chandra Sadineni, Michal Simek, Douglas Anderson,
	Roger Quadros, Krzysztof Kozlowski, Stephen Boyd,
	Matthias Kaehlcke, Rob Herring

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 <mka@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
---

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.33.0.rc1.237.g0d66db33f3-goog


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH v16 3/7] ARM: configs: Explicitly enable USB_XHCI_PLATFORM where needed
  2021-08-13 19:52 [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver Matthias Kaehlcke
  2021-08-13 19:52 ` [PATCH v16 1/7] " Matthias Kaehlcke
  2021-08-13 19:52 ` [PATCH v16 2/7] of/platform: Add stubs for of_platform_device_create/destroy() Matthias Kaehlcke
@ 2021-08-13 19:52 ` Matthias Kaehlcke
  2021-08-26  6:45   ` Roger Quadros
  2021-08-26  7:56   ` Krzysztof Kozlowski
  2021-08-13 19:52 ` [PATCH v16 4/7] arm64: defconfig: Explicitly enable USB_XHCI_PLATFORM Matthias Kaehlcke
                   ` (4 subsequent siblings)
  7 siblings, 2 replies; 28+ messages in thread
From: Matthias Kaehlcke @ 2021-08-13 19:52 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Alan Stern, Rob Herring, Frank Rowand,
	Mathias Nyman, Felipe Balbi
  Cc: devicetree, Peter Chen, linux-kernel, linux-usb, Bastien Nocera,
	Ravi Chandra Sadineni, Michal Simek, Douglas Anderson,
	Roger Quadros, Krzysztof Kozlowski, Stephen Boyd,
	Matthias Kaehlcke, Al Viro, Alexandre Belloni, Alexandre Torgue,
	Andrew Lunn, Arnd Bergmann, Dmitry Osipenko, Dong Aisheng,
	Fabrice Gasnier, Florian Fainelli, Gregory Clement,
	Grygorii Strashko, Jens Axboe, Johan Hovold, Krzysztof Kozlowski,
	Lad Prabhakar, Lionel Debieve, Manivannan Sadhasivam,
	Marek Szyprowski, Mark Brown, Martin Jücker, Olivier Moysan,
	Robert Richter, Russell King, Sebastian Hesselbarth, Shawn Guo,
	Thomas Gleixner, Tony Lindgren, Viresh Kumar, William Cohen,
	linux-arm-kernel, linux-omap, linux-samsung-soc,
	Łukasz Stelmach

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 <mka@chromium.org>
---

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 f4e1873912a3..660fccb40f34 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -255,6 +255,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 52a0400fdd92..4619418e53f4 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -787,6 +787,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 cddce57fe4b9..6cb85ec4fe54 100644
--- a/arch/arm/configs/mvebu_v7_defconfig
+++ b/arch/arm/configs/mvebu_v7_defconfig
@@ -103,6 +103,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 2ac2418084ab..a015fb04fa25 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -562,6 +562,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 363f1b1b08e3..e44763fe2b23 100644
--- a/arch/arm/configs/pxa_defconfig
+++ b/arch/arm/configs/pxa_defconfig
@@ -524,6 +524,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.33.0.rc1.237.g0d66db33f3-goog


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH v16 4/7] arm64: defconfig: Explicitly enable USB_XHCI_PLATFORM
  2021-08-13 19:52 [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver Matthias Kaehlcke
                   ` (2 preceding siblings ...)
  2021-08-13 19:52 ` [PATCH v16 3/7] ARM: configs: Explicitly enable USB_XHCI_PLATFORM where needed Matthias Kaehlcke
@ 2021-08-13 19:52 ` Matthias Kaehlcke
  2021-08-26  6:46   ` Roger Quadros
  2021-08-13 19:52 ` [PATCH v16 5/7] usb: Specify dependencies on USB_XHCI_PLATFORM with 'depends on' Matthias Kaehlcke
                   ` (3 subsequent siblings)
  7 siblings, 1 reply; 28+ messages in thread
From: Matthias Kaehlcke @ 2021-08-13 19:52 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Alan Stern, Rob Herring, Frank Rowand,
	Mathias Nyman, Felipe Balbi
  Cc: devicetree, Peter Chen, linux-kernel, linux-usb, Bastien Nocera,
	Ravi Chandra Sadineni, Michal Simek, Douglas Anderson,
	Roger Quadros, Krzysztof Kozlowski, Stephen Boyd,
	Matthias Kaehlcke, Andrey Zhizhikin, Bjorn Andersson,
	Catalin Marinas, Dmitry Baryshkov, Enric Balletbo i Serra,
	Fabio Estevam, Guido Günther, Jagan Teki, Nishanth Menon,
	Shawn Guo, Vinod Koul, Will Deacon, linux-arm-kernel

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 <mka@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
---

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 f423d08b9a71..b243bd11a4ed 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -802,6 +802,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.33.0.rc1.237.g0d66db33f3-goog


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH v16 5/7] usb: Specify dependencies on USB_XHCI_PLATFORM with 'depends on'
  2021-08-13 19:52 [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver Matthias Kaehlcke
                   ` (3 preceding siblings ...)
  2021-08-13 19:52 ` [PATCH v16 4/7] arm64: defconfig: Explicitly enable USB_XHCI_PLATFORM Matthias Kaehlcke
@ 2021-08-13 19:52 ` Matthias Kaehlcke
  2021-08-26  6:46   ` Roger Quadros
  2021-11-11 23:48   ` Doug Anderson
  2021-08-13 19:52 ` [PATCH v16 6/7] usb: host: xhci-plat: Create platform device for onboard hubs in probe() Matthias Kaehlcke
                   ` (2 subsequent siblings)
  7 siblings, 2 replies; 28+ messages in thread
From: Matthias Kaehlcke @ 2021-08-13 19:52 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Alan Stern, Rob Herring, Frank Rowand,
	Mathias Nyman, Felipe Balbi
  Cc: devicetree, Peter Chen, linux-kernel, linux-usb, Bastien Nocera,
	Ravi Chandra Sadineni, Michal Simek, Douglas Anderson,
	Roger Quadros, Krzysztof Kozlowski, Stephen Boyd,
	Matthias Kaehlcke, Andrew Lunn, Aswath Govindraju,
	Dmitry Osipenko, Fabio Estevam, Gregory Clement,
	Krzysztof Kozlowski, Pawel Laszczak, Sebastian Hesselbarth,
	Tony Lindgren, linux-arm-kernel, linux-omap, linux-samsung-soc

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 <mka@chromium.org>
---

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 66b1454c4db2..870f2251350a 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 && 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 df9428f1dc5e..518c2312ef0c 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.33.0.rc1.237.g0d66db33f3-goog


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH v16 6/7] usb: host: xhci-plat: Create platform device for onboard hubs in probe()
  2021-08-13 19:52 [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver Matthias Kaehlcke
                   ` (4 preceding siblings ...)
  2021-08-13 19:52 ` [PATCH v16 5/7] usb: Specify dependencies on USB_XHCI_PLATFORM with 'depends on' Matthias Kaehlcke
@ 2021-08-13 19:52 ` Matthias Kaehlcke
  2021-10-20 13:05   ` Mathias Nyman
  2021-08-13 19:52 ` [PATCH v16 7/7] arm64: dts: qcom: sc7180-trogdor: Add nodes for onboard USB hub Matthias Kaehlcke
  2021-09-21 17:08 ` [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver Matthias Kaehlcke
  7 siblings, 1 reply; 28+ messages in thread
From: Matthias Kaehlcke @ 2021-08-13 19:52 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Alan Stern, Rob Herring, Frank Rowand,
	Mathias Nyman, Felipe Balbi
  Cc: devicetree, Peter Chen, linux-kernel, linux-usb, Bastien Nocera,
	Ravi Chandra Sadineni, Michal Simek, Douglas Anderson,
	Roger Quadros, Krzysztof Kozlowski, Stephen Boyd,
	Matthias Kaehlcke, Dmitry Osipenko, Fabio Estevam

Call onboard_hub_create/destroy_pdevs() from  _probe()/_remove()
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 xhci_hcd to keep track of the onboard hub
platform devices that are owned by the xHCI.

Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---

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/host/Kconfig     | 1 +
 drivers/usb/host/xhci-plat.c | 6 ++++++
 drivers/usb/host/xhci.h      | 2 ++
 3 files changed, 9 insertions(+)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 518c2312ef0c..099e9615919c 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -54,6 +54,7 @@ config USB_XHCI_PCI_RENESAS
 config USB_XHCI_PLATFORM
 	tristate "Generic xHCI driver for a platform device"
 	select USB_XHCI_RCAR if ARCH_RENESAS
+	depends on USB_ONBOARD_HUB || !USB_ONBOARD_HUB # if USB_ONBOARD_HUB=m, this can't be 'y'
 	help
 	  Adds an xHCI host driver for a generic platform device, which
 	  provides a memory space and an irq.
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index c1edcc9b13ce..ee98a3671619 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -15,6 +15,7 @@
 #include <linux/of.h>
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
+#include <linux/usb/onboard_hub.h>
 #include <linux/usb/phy.h>
 #include <linux/slab.h>
 #include <linux/acpi.h>
@@ -374,6 +375,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
 	 */
 	pm_runtime_forbid(&pdev->dev);
 
+	INIT_LIST_HEAD(&xhci->onboard_hub_devs);
+	onboard_hub_create_pdevs(hcd->self.root_hub, &xhci->onboard_hub_devs);
+
 	return 0;
 
 
@@ -420,6 +424,8 @@ static int xhci_plat_remove(struct platform_device *dev)
 	usb_remove_hcd(hcd);
 	usb_put_hcd(shared_hcd);
 
+	onboard_hub_destroy_pdevs(&xhci->onboard_hub_devs);
+
 	clk_disable_unprepare(clk);
 	clk_disable_unprepare(reg_clk);
 	usb_put_hcd(hcd);
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 3c7d281672ae..5ba01d5ccab8 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1923,6 +1923,8 @@ struct xhci_hcd {
 	struct dentry		*debugfs_slots;
 	struct list_head	regset_list;
 
+	struct list_head	onboard_hub_devs;
+
 	void			*dbc;
 	/* platform-specific data -- must come last */
 	unsigned long		priv[] __aligned(sizeof(s64));
-- 
2.33.0.rc1.237.g0d66db33f3-goog


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH v16 7/7] arm64: dts: qcom: sc7180-trogdor: Add nodes for onboard USB hub
  2021-08-13 19:52 [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver Matthias Kaehlcke
                   ` (5 preceding siblings ...)
  2021-08-13 19:52 ` [PATCH v16 6/7] usb: host: xhci-plat: Create platform device for onboard hubs in probe() Matthias Kaehlcke
@ 2021-08-13 19:52 ` Matthias Kaehlcke
  2021-09-21 17:08 ` [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver Matthias Kaehlcke
  7 siblings, 0 replies; 28+ messages in thread
From: Matthias Kaehlcke @ 2021-08-13 19:52 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Alan Stern, Rob Herring, Frank Rowand,
	Mathias Nyman, Felipe Balbi
  Cc: devicetree, Peter Chen, linux-kernel, linux-usb, Bastien Nocera,
	Ravi Chandra Sadineni, Michal Simek, Douglas Anderson,
	Roger Quadros, Krzysztof Kozlowski, Stephen Boyd,
	Matthias Kaehlcke, Andy Gross, Bjorn Andersson, linux-arm-msm

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 <mka@chromium.org>
---

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 2b522f9e0d8f..2f5263e3d1b9 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-r1.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-r1.dts
@@ -42,17 +42,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";
 };
@@ -61,6 +50,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 77ae7561d436..f89c6a7045e5 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>;
@@ -898,6 +897,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.33.0.rc1.237.g0d66db33f3-goog


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v16 3/7] ARM: configs: Explicitly enable USB_XHCI_PLATFORM where needed
  2021-08-13 19:52 ` [PATCH v16 3/7] ARM: configs: Explicitly enable USB_XHCI_PLATFORM where needed Matthias Kaehlcke
@ 2021-08-26  6:45   ` Roger Quadros
  2021-08-26  7:56   ` Krzysztof Kozlowski
  1 sibling, 0 replies; 28+ messages in thread
From: Roger Quadros @ 2021-08-26  6:45 UTC (permalink / raw)
  To: Matthias Kaehlcke, Greg Kroah-Hartman, Alan Stern, Rob Herring,
	Frank Rowand, Mathias Nyman, Felipe Balbi
  Cc: devicetree, Peter Chen, linux-kernel, linux-usb, Bastien Nocera,
	Ravi Chandra Sadineni, Michal Simek, Douglas Anderson,
	Krzysztof Kozlowski, Stephen Boyd, Al Viro, Alexandre Belloni,
	Alexandre Torgue, Andrew Lunn, Arnd Bergmann, Dmitry Osipenko,
	Dong Aisheng, Fabrice Gasnier, Florian Fainelli, Gregory Clement,
	Grygorii Strashko, Jens Axboe, Johan Hovold, Krzysztof Kozlowski,
	Lad Prabhakar, Lionel Debieve, Manivannan Sadhasivam,
	Marek Szyprowski, Mark Brown, Martin Jücker, Olivier Moysan,
	Robert Richter, Russell King, Sebastian Hesselbarth, Shawn Guo,
	Thomas Gleixner, Tony Lindgren, Viresh Kumar, William Cohen,
	linux-arm-kernel, linux-omap, linux-samsung-soc,
	Łukasz Stelmach



On 13/08/2021 22:52, Matthias Kaehlcke wrote:
> 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 <mka@chromium.org>

Reviewed-by: Roger Quadros <rogerq@kernel.org>

cheers,
-roger

> ---
> 
> 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 f4e1873912a3..660fccb40f34 100644
> --- a/arch/arm/configs/exynos_defconfig
> +++ b/arch/arm/configs/exynos_defconfig
> @@ -255,6 +255,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 52a0400fdd92..4619418e53f4 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -787,6 +787,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 cddce57fe4b9..6cb85ec4fe54 100644
> --- a/arch/arm/configs/mvebu_v7_defconfig
> +++ b/arch/arm/configs/mvebu_v7_defconfig
> @@ -103,6 +103,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 2ac2418084ab..a015fb04fa25 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -562,6 +562,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 363f1b1b08e3..e44763fe2b23 100644
> --- a/arch/arm/configs/pxa_defconfig
> +++ b/arch/arm/configs/pxa_defconfig
> @@ -524,6 +524,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
> 

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v16 4/7] arm64: defconfig: Explicitly enable USB_XHCI_PLATFORM
  2021-08-13 19:52 ` [PATCH v16 4/7] arm64: defconfig: Explicitly enable USB_XHCI_PLATFORM Matthias Kaehlcke
@ 2021-08-26  6:46   ` Roger Quadros
  0 siblings, 0 replies; 28+ messages in thread
From: Roger Quadros @ 2021-08-26  6:46 UTC (permalink / raw)
  To: Matthias Kaehlcke, Greg Kroah-Hartman, Alan Stern, Rob Herring,
	Frank Rowand, Mathias Nyman, Felipe Balbi
  Cc: devicetree, Peter Chen, linux-kernel, linux-usb, Bastien Nocera,
	Ravi Chandra Sadineni, Michal Simek, Douglas Anderson,
	Krzysztof Kozlowski, Stephen Boyd, Andrey Zhizhikin,
	Bjorn Andersson, Catalin Marinas, Dmitry Baryshkov,
	Enric Balletbo i Serra, Fabio Estevam, Guido Günther,
	Jagan Teki, Nishanth Menon, Shawn Guo, Vinod Koul, Will Deacon,
	linux-arm-kernel



On 13/08/2021 22:52, Matthias Kaehlcke wrote:
> 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 <mka@chromium.org>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>

Reviewed-by: Roger Quadros <rogerq@kernel.org>

cheers,
-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 f423d08b9a71..b243bd11a4ed 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -802,6 +802,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
> 

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v16 5/7] usb: Specify dependencies on USB_XHCI_PLATFORM with 'depends on'
  2021-08-13 19:52 ` [PATCH v16 5/7] usb: Specify dependencies on USB_XHCI_PLATFORM with 'depends on' Matthias Kaehlcke
@ 2021-08-26  6:46   ` Roger Quadros
  2021-11-11 23:48   ` Doug Anderson
  1 sibling, 0 replies; 28+ messages in thread
From: Roger Quadros @ 2021-08-26  6:46 UTC (permalink / raw)
  To: Matthias Kaehlcke, Greg Kroah-Hartman, Alan Stern, Rob Herring,
	Frank Rowand, Mathias Nyman, Felipe Balbi
  Cc: devicetree, Peter Chen, linux-kernel, linux-usb, Bastien Nocera,
	Ravi Chandra Sadineni, Michal Simek, Douglas Anderson,
	Krzysztof Kozlowski, Stephen Boyd, Andrew Lunn,
	Aswath Govindraju, Dmitry Osipenko, Fabio Estevam,
	Gregory Clement, Krzysztof Kozlowski, Pawel Laszczak,
	Sebastian Hesselbarth, Tony Lindgren, linux-arm-kernel,
	linux-omap, linux-samsung-soc



On 13/08/2021 22:52, 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 <mka@chromium.org>

Reviewed-by: Roger Quadros <rogerq@kernel.org>

cheers,
-roger

> ---
> 
> 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 66b1454c4db2..870f2251350a 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 && 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 df9428f1dc5e..518c2312ef0c 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.
> 

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v16 3/7] ARM: configs: Explicitly enable USB_XHCI_PLATFORM where needed
  2021-08-13 19:52 ` [PATCH v16 3/7] ARM: configs: Explicitly enable USB_XHCI_PLATFORM where needed Matthias Kaehlcke
  2021-08-26  6:45   ` Roger Quadros
@ 2021-08-26  7:56   ` Krzysztof Kozlowski
  1 sibling, 0 replies; 28+ messages in thread
From: Krzysztof Kozlowski @ 2021-08-26  7:56 UTC (permalink / raw)
  To: Matthias Kaehlcke, Greg Kroah-Hartman, Alan Stern, Rob Herring,
	Frank Rowand, Mathias Nyman, Felipe Balbi
  Cc: devicetree, Peter Chen, linux-kernel, linux-usb, Bastien Nocera,
	Ravi Chandra Sadineni, Michal Simek, Douglas Anderson,
	Roger Quadros, Krzysztof Kozlowski, Stephen Boyd, Al Viro,
	Alexandre Belloni, Alexandre Torgue, Andrew Lunn, Arnd Bergmann,
	Dmitry Osipenko, Dong Aisheng, Fabrice Gasnier, Florian Fainelli,
	Gregory Clement, Grygorii Strashko, Jens Axboe, Johan Hovold,
	Lad Prabhakar, Lionel Debieve, Manivannan Sadhasivam,
	Marek Szyprowski, Mark Brown, Martin Jücker, Olivier Moysan,
	Robert Richter, Russell King, Sebastian Hesselbarth, Shawn Guo,
	Thomas Gleixner, Tony Lindgren, Viresh Kumar, William Cohen,
	linux-arm-kernel, linux-omap, linux-samsung-soc,
	Łukasz Stelmach

On 13/08/2021 21:52, Matthias Kaehlcke wrote:
> 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 <mka@chromium.org>
> ---
> 
> Changes in v16:
> - patch added to the series
> 
>  arch/arm/configs/exynos_defconfig    | 1 +


Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>


Best regards,
Krzysztof

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver
  2021-08-13 19:52 [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver Matthias Kaehlcke
                   ` (6 preceding siblings ...)
  2021-08-13 19:52 ` [PATCH v16 7/7] arm64: dts: qcom: sc7180-trogdor: Add nodes for onboard USB hub Matthias Kaehlcke
@ 2021-09-21 17:08 ` Matthias Kaehlcke
  2021-10-14 21:38   ` Doug Anderson
  7 siblings, 1 reply; 28+ messages in thread
From: Matthias Kaehlcke @ 2021-09-21 17:08 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Alan Stern, Rob Herring, Frank Rowand,
	Mathias Nyman, Felipe Balbi
  Cc: devicetree, Peter Chen, linux-kernel, linux-usb, Bastien Nocera,
	Ravi Chandra Sadineni, Michal Simek, Douglas Anderson,
	Roger Quadros, Krzysztof Kozlowski, Stephen Boyd, Al Cooper,
	Al Viro, Alexandre Belloni, Alexandre Torgue, Andrew Lunn,
	Andrey Zhizhikin, Andy Gross, Arnd Bergmann, Aswath Govindraju,
	Bjorn Andersson, Catalin Marinas, Dmitry Baryshkov,
	Dmitry Osipenko, Dong Aisheng, Enric Balletbo i Serra,
	Fabio Estevam, Fabrice Gasnier, Florian Fainelli,
	Gregory Clement, Grygorii Strashko, Guido Günther,
	Jagan Teki, Jens Axboe, Johan Hovold, Krzysztof Kozlowski,
	Lad Prabhakar, Lionel Debieve, Manivannan Sadhasivam,
	Marek Szyprowski, Mark Brown, Martin Jücker, Nishanth Menon,
	Olivier Moysan, Pawel Laszczak, Robert Richter, Russell King,
	Sebastian Hesselbarth, Shawn Guo, Thomas Gleixner, Tony Lindgren,
	Vinod Koul, Viresh Kumar, Will Deacon, William Cohen,
	linux-arm-kernel, linux-arm-msm, linux-omap, linux-samsung-soc,
	Łukasz Stelmach

Hi Greg,

are there any actions pending or can this land in usb-testing?

I confirmed that this series can be rebased on top of v5.15-rc2
without conflicts.

Thanks

m.

On Fri, Aug 13, 2021 at 12:52:21PM -0700, Matthias Kaehlcke wrote:
> This series adds:
> - the onboard_usb_hub_driver
> - glue in the xhci-plat driver to create and destroy the
>   onboard_usb_hub platform devices if needed
> - a device tree binding for the Realtek RTS5411 USB hub controller
> - 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 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()
>   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'
>   usb: host: xhci-plat: Create platform device for onboard hubs in
>     probe()
>   arm64: dts: qcom: sc7180-trogdor: Add nodes for onboard USB hub
> 
>  .../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/dwc3/Kconfig                      |   5 +-
>  drivers/usb/host/Kconfig                      |   5 +-
>  drivers/usb/host/xhci-plat.c                  |   6 +
>  drivers/usb/host/xhci.h                       |   2 +
>  drivers/usb/misc/Kconfig                      |  17 +
>  drivers/usb/misc/Makefile                     |   1 +
>  drivers/usb/misc/onboard_usb_hub.c            | 497 ++++++++++++++++++
>  include/linux/of_platform.h                   |  22 +-
>  include/linux/usb/onboard_hub.h               |  18 +
>  23 files changed, 627 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.33.0.rc1.237.g0d66db33f3-goog
> 

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver
  2021-09-21 17:08 ` [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver Matthias Kaehlcke
@ 2021-10-14 21:38   ` Doug Anderson
  2021-10-15  6:39     ` Greg Kroah-Hartman
  0 siblings, 1 reply; 28+ messages in thread
From: Doug Anderson @ 2021-10-14 21:38 UTC (permalink / raw)
  To: Matthias Kaehlcke
  Cc: Greg Kroah-Hartman, Alan Stern, Rob Herring, Frank Rowand,
	Mathias Nyman, Felipe Balbi,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Peter Chen, LKML, Linux USB List, Bastien Nocera,
	Ravi Chandra Sadineni, Michal Simek, Roger Quadros,
	Krzysztof Kozlowski, Stephen Boyd, Al Cooper, Al Viro,
	Alexandre Belloni, Alexandre Torgue, Andrew Lunn,
	Andrey Zhizhikin, Andy Gross, Arnd Bergmann, Aswath Govindraju,
	Bjorn Andersson, Catalin Marinas, Dmitry Baryshkov,
	Dmitry Osipenko, Dong Aisheng, Enric Balletbo i Serra,
	Fabio Estevam, Fabrice Gasnier, Florian Fainelli,
	Gregory Clement, Grygorii Strashko, Guido Günther,
	Jagan Teki, Jens Axboe, Johan Hovold, Krzysztof Kozlowski,
	Lad Prabhakar, Lionel Debieve, Manivannan Sadhasivam,
	Marek Szyprowski, Mark Brown, Martin Jücker, Nishanth Menon,
	Olivier Moysan, Pawel Laszczak, Robert Richter, Russell King,
	Sebastian Hesselbarth, Shawn Guo, Thomas Gleixner, Tony Lindgren,
	Vinod Koul, Viresh Kumar, Will Deacon, William Cohen, Linux ARM,
	linux-arm-msm, linux-omap, linux-samsung-soc,
	Łukasz Stelmach

Hi,

On Tue, Sep 21, 2021 at 10:09 AM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> Hi Greg,
>
> are there any actions pending or can this land in usb-testing?
>
> I confirmed that this series can be rebased on top of v5.15-rc2
> without conflicts.

I'm quite interested to know what the next action items are, too. This
is one of the very few patches we have for trogdor (excluding MIPI
camera, which is a long story) that we're carrying downstream, so I'm
keenly interested in making sure it's unblocked (if, indeed, it's
blocked on anything).

If folks feel that this needs more review eyes before landing again
then I'll try to find some time in the next week or two. If it's just
waiting for the merge window to open/close so it can have maximal bake
time, that's cool too. Please yell if there's something that I can do
to help, though! :-)


> On Fri, Aug 13, 2021 at 12:52:21PM -0700, Matthias Kaehlcke wrote:
> > This series adds:
> > - the onboard_usb_hub_driver
> > - glue in the xhci-plat driver to create and destroy the
> >   onboard_usb_hub platform devices if needed
> > - a device tree binding for the Realtek RTS5411 USB hub controller
> > - 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 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()
> >   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'
> >   usb: host: xhci-plat: Create platform device for onboard hubs in
> >     probe()
> >   arm64: dts: qcom: sc7180-trogdor: Add nodes for onboard USB hub
> >
> >  .../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/dwc3/Kconfig                      |   5 +-
> >  drivers/usb/host/Kconfig                      |   5 +-
> >  drivers/usb/host/xhci-plat.c                  |   6 +
> >  drivers/usb/host/xhci.h                       |   2 +
> >  drivers/usb/misc/Kconfig                      |  17 +
> >  drivers/usb/misc/Makefile                     |   1 +
> >  drivers/usb/misc/onboard_usb_hub.c            | 497 ++++++++++++++++++
> >  include/linux/of_platform.h                   |  22 +-
> >  include/linux/usb/onboard_hub.h               |  18 +
> >  23 files changed, 627 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.33.0.rc1.237.g0d66db33f3-goog
> >

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver
  2021-10-14 21:38   ` Doug Anderson
@ 2021-10-15  6:39     ` Greg Kroah-Hartman
  2021-10-19 16:04       ` Fabrice Gasnier
  0 siblings, 1 reply; 28+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-15  6:39 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Matthias Kaehlcke, Alan Stern, Rob Herring, Frank Rowand,
	Mathias Nyman, Felipe Balbi,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Peter Chen, LKML, Linux USB List, Bastien Nocera,
	Ravi Chandra Sadineni, Michal Simek, Roger Quadros,
	Krzysztof Kozlowski, Stephen Boyd, Al Cooper, Al Viro,
	Alexandre Belloni, Alexandre Torgue, Andrew Lunn,
	Andrey Zhizhikin, Andy Gross, Arnd Bergmann, Aswath Govindraju,
	Bjorn Andersson, Catalin Marinas, Dmitry Baryshkov,
	Dmitry Osipenko, Dong Aisheng, Enric Balletbo i Serra,
	Fabio Estevam, Fabrice Gasnier, Florian Fainelli,
	Gregory Clement, Grygorii Strashko, Guido Günther,
	Jagan Teki, Jens Axboe, Johan Hovold, Krzysztof Kozlowski,
	Lad Prabhakar, Lionel Debieve, Manivannan Sadhasivam,
	Marek Szyprowski, Mark Brown, Martin Jücker, Nishanth Menon,
	Olivier Moysan, Pawel Laszczak, Robert Richter, Russell King,
	Sebastian Hesselbarth, Shawn Guo, Thomas Gleixner, Tony Lindgren,
	Vinod Koul, Viresh Kumar, Will Deacon, William Cohen, Linux ARM,
	linux-arm-msm, linux-omap, linux-samsung-soc,
	Łukasz Stelmach

On Thu, Oct 14, 2021 at 02:38:55PM -0700, Doug Anderson wrote:
> Hi,
> 
> On Tue, Sep 21, 2021 at 10:09 AM Matthias Kaehlcke <mka@chromium.org> wrote:
> >
> > Hi Greg,
> >
> > are there any actions pending or can this land in usb-testing?
> >
> > I confirmed that this series can be rebased on top of v5.15-rc2
> > without conflicts.
> 
> I'm quite interested to know what the next action items are, too. This
> is one of the very few patches we have for trogdor (excluding MIPI
> camera, which is a long story) that we're carrying downstream, so I'm
> keenly interested in making sure it's unblocked (if, indeed, it's
> blocked on anything).
> 
> If folks feel that this needs more review eyes before landing again
> then I'll try to find some time in the next week or two. If it's just
> waiting for the merge window to open/close so it can have maximal bake
> time, that's cool too. Please yell if there's something that I can do
> to help, though! :-)

I would love more review-eyes on this please.

It's in my queue to review, I just need to spend the time on it, sorry
for the delay.

greg k-h

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Re: [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver
  2021-10-15  6:39     ` Greg Kroah-Hartman
@ 2021-10-19 16:04       ` Fabrice Gasnier
  2021-10-19 22:10         ` Matthias Kaehlcke
  2021-10-20  6:21         ` Michal Simek
  0 siblings, 2 replies; 28+ messages in thread
From: Fabrice Gasnier @ 2021-10-19 16:04 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Doug Anderson, Matthias Kaehlcke, Rob Herring
  Cc: Alan Stern, Frank Rowand, Mathias Nyman, Felipe Balbi,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Peter Chen, LKML, Linux USB List, Bastien Nocera,
	Ravi Chandra Sadineni, Michal Simek, Roger Quadros,
	Krzysztof Kozlowski, Stephen Boyd, Al Cooper, Al Viro,
	Alexandre Belloni, Alexandre TORGUE - foss, Andrew Lunn,
	Andrey Zhizhikin, Andy Gross, Arnd Bergmann, Aswath Govindraju,
	Bjorn Andersson, Catalin Marinas, Dmitry Baryshkov,
	Dmitry Osipenko, Dong Aisheng, Enric Balletbo i Serra,
	Fabio Estevam, Florian Fainelli, Gregory Clement,
	Grygorii Strashko, Guido Günther, Jagan Teki, Jens Axboe,
	Johan Hovold, Krzysztof Kozlowski, Lad Prabhakar, Lionel DEBIEVE,
	Manivannan Sadhasivam, Marek Szyprowski, Mark Brown,
	Martin Jücker, Nishanth Menon, Olivier MOYSAN,
	Pawel Laszczak, Robert Richter, Russell King,
	Sebastian Hesselbarth, Shawn Guo, Thomas Gleixner, Tony Lindgren,
	Vinod Koul, Viresh Kumar, Will Deacon, William Cohen, Linux ARM,
	linux-arm-msm, linux-omap, linux-samsung-soc,
	Łukasz Stelmach

On 10/15/21 8:39 AM, Greg Kroah-Hartman wrote:
> On Thu, Oct 14, 2021 at 02:38:55PM -0700, Doug Anderson wrote:
>> Hi,
>>
>> On Tue, Sep 21, 2021 at 10:09 AM Matthias Kaehlcke <mka@chromium.org> wrote:
>>>
>>> Hi Greg,
>>>
>>> are there any actions pending or can this land in usb-testing?
>>>
>>> I confirmed that this series can be rebased on top of v5.15-rc2
>>> without conflicts.
>>
>> I'm quite interested to know what the next action items are, too. This
>> is one of the very few patches we have for trogdor (excluding MIPI
>> camera, which is a long story) that we're carrying downstream, so I'm
>> keenly interested in making sure it's unblocked (if, indeed, it's
>> blocked on anything).
>>
>> If folks feel that this needs more review eyes before landing again
>> then I'll try to find some time in the next week or two. If it's just
>> waiting for the merge window to open/close so it can have maximal bake
>> time, that's cool too. Please yell if there's something that I can do
>> to help, though! :-)
> 
> I would love more review-eyes on this please.
> 

Hi,

I noticed this series some time ago, and wanted to take a closer look.

The same issue this series address is seen on stm32 board for instance.
(arch/arm/boot/dts/stm32mp15xx-dkx.dtsi). On board HUB (not described in
the DT) is supplied by an always-on regulator.
So it could could be interesting/useful to address the same case ,
on stm32 boards, where USB2 (ehci-platform driver) is used currently.

I noticed a few things, especially on the dt-bindings. I've some
questions here.

In this series, RTS5411 is used. The dt-bindings documents it as a child
node of the USB controller. E.g.

&usb {
	usb_hub_2_0: hub@1 {
		...
	};

	usb_hub_3_0: hub@2 {
	};
}

I had a quick look at RTS5411 datasheet. It looks like there's an i2c
interface too.
- I guess the I2C interface isn't used in your case ?
  (I haven't checked what it could be used for...)

In the stm32 boards (stm32mp15xx-dkx), there's an usb2514b chip
- that also could be wired on I2C interface (0R mount option)
- unused on stm32 boards by default

usb2514b chip already has a dt-bindings (with compatible), and a driver:
- drivers/usb/misc/usb251xb.c
- Documentation/devicetree/bindings/usb/usb251xb.txt

It is defined more as an i2c chip, so I'd expect it as an i2c child,
e.g. like:

&i2c {
	usb2514b@2c {
		compatible = "microchip,usb2514b";
		...
	};
};


This way, I don't see how it could be used together with onboard_usb_hub
driver ? (But I may have missed it)
Is it possible to use a phandle, instead of a child node ?

However, in the stm32mp15xx-dkx case, i2c interface isn't wired/used by
default. So obviously the i2c driver isn't used. In this case, could the
"microchip,usb2514b" be listed in onboard_usb_hub driver ?
(wouldn't it be redundant ?)

In this case it would be a child node of the usb DT node... Maybe that's
more a question for Rob: would it be "legal" regarding existing
dt-bindings ?


Thanks in advance
Best Regards,
Fabrice


> It's in my queue to review, I just need to spend the time on it, sorry
> for the delay.
> 
> greg k-h
> 

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver
  2021-10-19 16:04       ` Fabrice Gasnier
@ 2021-10-19 22:10         ` Matthias Kaehlcke
  2021-10-20  6:21         ` Michal Simek
  1 sibling, 0 replies; 28+ messages in thread
From: Matthias Kaehlcke @ 2021-10-19 22:10 UTC (permalink / raw)
  To: Fabrice Gasnier
  Cc: Greg Kroah-Hartman, Doug Anderson, Rob Herring, Alan Stern,
	Frank Rowand, Mathias Nyman, Felipe Balbi,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Peter Chen, LKML, Linux USB List, Bastien Nocera,
	Ravi Chandra Sadineni, Michal Simek, Roger Quadros,
	Krzysztof Kozlowski, Stephen Boyd, Al Cooper, Al Viro,
	Alexandre Belloni, Alexandre TORGUE - foss, Andrew Lunn,
	Andrey Zhizhikin, Andy Gross, Arnd Bergmann, Aswath Govindraju,
	Bjorn Andersson, Catalin Marinas, Dmitry Baryshkov,
	Dmitry Osipenko, Dong Aisheng, Enric Balletbo i Serra,
	Fabio Estevam, Florian Fainelli, Gregory Clement,
	Grygorii Strashko, Guido Günther, Jagan Teki, Jens Axboe,
	Johan Hovold, Krzysztof Kozlowski, Lad Prabhakar, Lionel DEBIEVE,
	Manivannan Sadhasivam, Marek Szyprowski, Mark Brown,
	Martin Jücker, Nishanth Menon, Olivier MOYSAN,
	Pawel Laszczak, Robert Richter, Russell King,
	Sebastian Hesselbarth, Shawn Guo, Thomas Gleixner, Tony Lindgren,
	Vinod Koul, Viresh Kumar, Will Deacon, William Cohen, Linux ARM,
	linux-arm-msm, linux-omap, linux-samsung-soc,
	Łukasz Stelmach

On Tue, Oct 19, 2021 at 06:04:06PM +0200, Fabrice Gasnier wrote:
> On 10/15/21 8:39 AM, Greg Kroah-Hartman wrote:
> > On Thu, Oct 14, 2021 at 02:38:55PM -0700, Doug Anderson wrote:
> >> Hi,
> >>
> >> On Tue, Sep 21, 2021 at 10:09 AM Matthias Kaehlcke <mka@chromium.org> wrote:
> >>>
> >>> Hi Greg,
> >>>
> >>> are there any actions pending or can this land in usb-testing?
> >>>
> >>> I confirmed that this series can be rebased on top of v5.15-rc2
> >>> without conflicts.
> >>
> >> I'm quite interested to know what the next action items are, too. This
> >> is one of the very few patches we have for trogdor (excluding MIPI
> >> camera, which is a long story) that we're carrying downstream, so I'm
> >> keenly interested in making sure it's unblocked (if, indeed, it's
> >> blocked on anything).
> >>
> >> If folks feel that this needs more review eyes before landing again
> >> then I'll try to find some time in the next week or two. If it's just
> >> waiting for the merge window to open/close so it can have maximal bake
> >> time, that's cool too. Please yell if there's something that I can do
> >> to help, though! :-)
> > 
> > I would love more review-eyes on this please.
> > 
> 
> Hi,
> 
> I noticed this series some time ago, and wanted to take a closer look.
> 
> The same issue this series address is seen on stm32 board for instance.
> (arch/arm/boot/dts/stm32mp15xx-dkx.dtsi). On board HUB (not described in
> the DT) is supplied by an always-on regulator.
> So it could could be interesting/useful to address the same case ,
> on stm32 boards, where USB2 (ehci-platform driver) is used currently.
> 
> I noticed a few things, especially on the dt-bindings. I've some
> questions here.
> 
> In this series, RTS5411 is used. The dt-bindings documents it as a child
> node of the USB controller. E.g.
> 
> &usb {
> 	usb_hub_2_0: hub@1 {
> 		...
> 	};
> 
> 	usb_hub_3_0: hub@2 {
> 	};
> }
> 
> I had a quick look at RTS5411 datasheet. It looks like there's an i2c
> interface too.
> - I guess the I2C interface isn't used in your case ?
>   (I haven't checked what it could be used for...)

Correct, the i2c interface isn't used on my board.

Also the binding isn't completely new, it is based on the generic USB
binding (https://www.kernel.org/doc/Documentation/devicetree/bindings/usb/usb-device.txt)

> In the stm32 boards (stm32mp15xx-dkx), there's an usb2514b chip
> - that also could be wired on I2C interface (0R mount option)
> - unused on stm32 boards by default
> 
> usb2514b chip already has a dt-bindings (with compatible), and a driver:
> - drivers/usb/misc/usb251xb.c
> - Documentation/devicetree/bindings/usb/usb251xb.txt
> 
> It is defined more as an i2c chip, so I'd expect it as an i2c child,
> e.g. like:
> 
> &i2c {
> 	usb2514b@2c {
> 		compatible = "microchip,usb2514b";
> 		...
> 	};
> };
> 
> 
> This way, I don't see how it could be used together with onboard_usb_hub
> driver ? (But I may have missed it)

Indeed, you can either use the i2c driver for the hub or the onboard_usb_hub
driver, but not both at the same time. The i2c driver requires the hub to be
powered before communicating with it over i2c, hence the power sequence
should not be delegated to the onboard_usb_hub driver.

> Is it possible to use a phandle, instead of a child node ?

The child node is part of the generic USB binding. The onboard_usb_hub
driver needs it to find the USB device(s) that correspond to the hub,
to optionally power the hub off during system suspend when no wakeup
capable devices are connected.

> However, in the stm32mp15xx-dkx case, i2c interface isn't wired/used by
> default. So obviously the i2c driver isn't used. In this case, could the
> "microchip,usb2514b" be listed in onboard_usb_hub driver ?
> (wouldn't it be redundant ?)

You would use the compatible string of the generic USB binding, i.e.
"usbVID,PID", which would have to be added to the onboard_usb_hub driver.

> In this case it would be a child node of the usb DT node... Maybe that's
> more a question for Rob: would it be "legal" regarding existing
> dt-bindings ?

The USB node is always there implicitly (the USB device exists), the only
difference is that the node is added explicitly (plus additional
properties).

There was a somewhat related long-winded discussion with Rob on an earlier
version of the driver/binding:
https://lore.kernel.org/linux-usb/1613055380.685661.519681.nullmailer@robh.at.kernel.org/

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver
  2021-10-19 16:04       ` Fabrice Gasnier
  2021-10-19 22:10         ` Matthias Kaehlcke
@ 2021-10-20  6:21         ` Michal Simek
  2021-10-20 17:41           ` Matthias Kaehlcke
  1 sibling, 1 reply; 28+ messages in thread
From: Michal Simek @ 2021-10-20  6:21 UTC (permalink / raw)
  To: Fabrice Gasnier, Greg Kroah-Hartman, Doug Anderson,
	Matthias Kaehlcke, Rob Herring
  Cc: Alan Stern, Frank Rowand, Mathias Nyman, Felipe Balbi,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Peter Chen, LKML, Linux USB List, Bastien Nocera,
	Ravi Chandra Sadineni, Michal Simek, Roger Quadros,
	Krzysztof Kozlowski, Stephen Boyd, Al Cooper, Al Viro,
	Alexandre Belloni, Alexandre TORGUE - foss, Andrew Lunn,
	Andrey Zhizhikin, Andy Gross, Arnd Bergmann, Aswath Govindraju,
	Bjorn Andersson, Catalin Marinas, Dmitry Baryshkov,
	Dmitry Osipenko, Dong Aisheng, Enric Balletbo i Serra,
	Fabio Estevam, Florian Fainelli, Gregory Clement,
	Grygorii Strashko, Guido Günther, Jagan Teki, Jens Axboe,
	Johan Hovold, Krzysztof Kozlowski, Lad Prabhakar, Lionel DEBIEVE,
	Manivannan Sadhasivam, Marek Szyprowski, Mark Brown,
	Martin Jücker, Nishanth Menon, Olivier MOYSAN,
	Pawel Laszczak, Robert Richter, Russell King,
	Sebastian Hesselbarth, Shawn Guo, Thomas Gleixner, Tony Lindgren,
	Vinod Koul, Viresh Kumar, Will Deacon, William Cohen, Linux ARM,
	linux-arm-msm, linux-omap, linux-samsung-soc,
	Łukasz Stelmach



On 10/19/21 18:04, Fabrice Gasnier wrote:
> On 10/15/21 8:39 AM, Greg Kroah-Hartman wrote:
>> On Thu, Oct 14, 2021 at 02:38:55PM -0700, Doug Anderson wrote:
>>> Hi,
>>>
>>> On Tue, Sep 21, 2021 at 10:09 AM Matthias Kaehlcke <mka@chromium.org> wrote:
>>>>
>>>> Hi Greg,
>>>>
>>>> are there any actions pending or can this land in usb-testing?
>>>>
>>>> I confirmed that this series can be rebased on top of v5.15-rc2
>>>> without conflicts.
>>>
>>> I'm quite interested to know what the next action items are, too. This
>>> is one of the very few patches we have for trogdor (excluding MIPI
>>> camera, which is a long story) that we're carrying downstream, so I'm
>>> keenly interested in making sure it's unblocked (if, indeed, it's
>>> blocked on anything).
>>>
>>> If folks feel that this needs more review eyes before landing again
>>> then I'll try to find some time in the next week or two. If it's just
>>> waiting for the merge window to open/close so it can have maximal bake
>>> time, that's cool too. Please yell if there's something that I can do
>>> to help, though! :-)
>>
>> I would love more review-eyes on this please.
>>
> 
> Hi,
> 
> I noticed this series some time ago, and wanted to take a closer look.
> 
> The same issue this series address is seen on stm32 board for instance.
> (arch/arm/boot/dts/stm32mp15xx-dkx.dtsi). On board HUB (not described in
> the DT) is supplied by an always-on regulator.
> So it could could be interesting/useful to address the same case ,
> on stm32 boards, where USB2 (ehci-platform driver) is used currently.
> 
> I noticed a few things, especially on the dt-bindings. I've some
> questions here.
> 
> In this series, RTS5411 is used. The dt-bindings documents it as a child
> node of the USB controller. E.g.
> 
> &usb {
> 	usb_hub_2_0: hub@1 {
> 		...
> 	};
> 
> 	usb_hub_3_0: hub@2 {
> 	};
> }
> 
> I had a quick look at RTS5411 datasheet. It looks like there's an i2c
> interface too.
> - I guess the I2C interface isn't used in your case ?
>    (I haven't checked what it could be used for...)
> 
> In the stm32 boards (stm32mp15xx-dkx), there's an usb2514b chip
> - that also could be wired on I2C interface (0R mount option)
> - unused on stm32 boards by default
> 
> usb2514b chip already has a dt-bindings (with compatible), and a driver:
> - drivers/usb/misc/usb251xb.c
> - Documentation/devicetree/bindings/usb/usb251xb.txt
> 
> It is defined more as an i2c chip, so I'd expect it as an i2c child,
> e.g. like:
> 
> &i2c {
> 	usb2514b@2c {
> 		compatible = "microchip,usb2514b";
> 		...
> 	};
> };
> 
> 
> This way, I don't see how it could be used together with onboard_usb_hub
> driver ? (But I may have missed it)
> Is it possible to use a phandle, instead of a child node ?
> 
> However, in the stm32mp15xx-dkx case, i2c interface isn't wired/used by
> default. So obviously the i2c driver isn't used. In this case, could the
> "microchip,usb2514b" be listed in onboard_usb_hub driver ?
> (wouldn't it be redundant ?)
> 
> In this case it would be a child node of the usb DT node... Maybe that's
> more a question for Rob: would it be "legal" regarding existing
> dt-bindings ?

We wanted to upstream driver for microchip usb5744 and based on this 
thread with Rob

https://lore.kernel.org/all/CAL_JsqJZBbu+UXqUNdZwg-uv0PAsNg55026PTwhKr5wQtxCjVQ@mail.gmail.com/

the recommendation was to use i2c-bus link. And in our usb5744 case 
where usb hub has only one i2c address we just hardcoded it in the 
driver. I should be pushing this driver to xilinx soc tree soon if you 
want to take a look.

Thanks,
Michal

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v16 6/7] usb: host: xhci-plat: Create platform device for onboard hubs in probe()
  2021-08-13 19:52 ` [PATCH v16 6/7] usb: host: xhci-plat: Create platform device for onboard hubs in probe() Matthias Kaehlcke
@ 2021-10-20 13:05   ` Mathias Nyman
  2021-10-20 20:27     ` Matthias Kaehlcke
  0 siblings, 1 reply; 28+ messages in thread
From: Mathias Nyman @ 2021-10-20 13:05 UTC (permalink / raw)
  To: Matthias Kaehlcke, Greg Kroah-Hartman, Alan Stern, Rob Herring,
	Frank Rowand, Mathias Nyman, Felipe Balbi
  Cc: devicetree, Peter Chen, linux-kernel, linux-usb, Bastien Nocera,
	Ravi Chandra Sadineni, Michal Simek, Douglas Anderson,
	Roger Quadros, Krzysztof Kozlowski, Stephen Boyd,
	Dmitry Osipenko, Fabio Estevam

Hi

On 13.8.2021 22.52, Matthias Kaehlcke wrote:
> Call onboard_hub_create/destroy_pdevs() from  _probe()/_remove()
> 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 xhci_hcd to keep track of the onboard hub
> platform devices that are owned by the xHCI.
> 
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---

Haven't really looked at this series until now.

Is there any reason why the xhci platform driver was selected as 
the best place to create/remove these onboard hub devices?

This ties the onboard hubs to xhci, and won't work in case we have onboard
hubs connected to a ehci controllers.

If separate devices for controlling onboard hub power is the right solution then
how about creating the onboard hub device in usb_add_hcd() (hcd.c), and
store it in struct usb_hcd.

A bit like how the roothub device is created, or PHYs are tuned.

Thanks
Mathias












^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver
  2021-10-20  6:21         ` Michal Simek
@ 2021-10-20 17:41           ` Matthias Kaehlcke
  0 siblings, 0 replies; 28+ messages in thread
From: Matthias Kaehlcke @ 2021-10-20 17:41 UTC (permalink / raw)
  To: Michal Simek
  Cc: Fabrice Gasnier, Greg Kroah-Hartman, Doug Anderson, Rob Herring,
	Alan Stern, Frank Rowand, Mathias Nyman, Felipe Balbi,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Peter Chen, LKML, Linux USB List, Bastien Nocera,
	Ravi Chandra Sadineni, Roger Quadros, Krzysztof Kozlowski,
	Stephen Boyd, Al Cooper, Al Viro, Alexandre Belloni,
	Alexandre TORGUE - foss, Andrew Lunn, Andrey Zhizhikin,
	Andy Gross, Arnd Bergmann, Aswath Govindraju, Bjorn Andersson,
	Catalin Marinas, Dmitry Baryshkov, Dmitry Osipenko, Dong Aisheng,
	Enric Balletbo i Serra, Fabio Estevam, Florian Fainelli,
	Gregory Clement, Grygorii Strashko, Guido Günther,
	Jagan Teki, Jens Axboe, Johan Hovold, Krzysztof Kozlowski,
	Lad Prabhakar, Lionel DEBIEVE, Manivannan Sadhasivam,
	Marek Szyprowski, Mark Brown, Martin Jücker, Nishanth Menon,
	Olivier MOYSAN, Pawel Laszczak, Robert Richter, Russell King,
	Sebastian Hesselbarth, Shawn Guo, Thomas Gleixner, Tony Lindgren,
	Vinod Koul, Viresh Kumar, Will Deacon, William Cohen, Linux ARM,
	linux-arm-msm, linux-omap, linux-samsung-soc,
	Łukasz Stelmach

On Wed, Oct 20, 2021 at 08:21:21AM +0200, Michal Simek wrote:
> 
> 
> On 10/19/21 18:04, Fabrice Gasnier wrote:
> > On 10/15/21 8:39 AM, Greg Kroah-Hartman wrote:
> > > On Thu, Oct 14, 2021 at 02:38:55PM -0700, Doug Anderson wrote:
> > > > Hi,
> > > > 
> > > > On Tue, Sep 21, 2021 at 10:09 AM Matthias Kaehlcke <mka@chromium.org> wrote:
> > > > > 
> > > > > Hi Greg,
> > > > > 
> > > > > are there any actions pending or can this land in usb-testing?
> > > > > 
> > > > > I confirmed that this series can be rebased on top of v5.15-rc2
> > > > > without conflicts.
> > > > 
> > > > I'm quite interested to know what the next action items are, too. This
> > > > is one of the very few patches we have for trogdor (excluding MIPI
> > > > camera, which is a long story) that we're carrying downstream, so I'm
> > > > keenly interested in making sure it's unblocked (if, indeed, it's
> > > > blocked on anything).
> > > > 
> > > > If folks feel that this needs more review eyes before landing again
> > > > then I'll try to find some time in the next week or two. If it's just
> > > > waiting for the merge window to open/close so it can have maximal bake
> > > > time, that's cool too. Please yell if there's something that I can do
> > > > to help, though! :-)
> > > 
> > > I would love more review-eyes on this please.
> > > 
> > 
> > Hi,
> > 
> > I noticed this series some time ago, and wanted to take a closer look.
> > 
> > The same issue this series address is seen on stm32 board for instance.
> > (arch/arm/boot/dts/stm32mp15xx-dkx.dtsi). On board HUB (not described in
> > the DT) is supplied by an always-on regulator.
> > So it could could be interesting/useful to address the same case ,
> > on stm32 boards, where USB2 (ehci-platform driver) is used currently.
> > 
> > I noticed a few things, especially on the dt-bindings. I've some
> > questions here.
> > 
> > In this series, RTS5411 is used. The dt-bindings documents it as a child
> > node of the USB controller. E.g.
> > 
> > &usb {
> > 	usb_hub_2_0: hub@1 {
> > 		...
> > 	};
> > 
> > 	usb_hub_3_0: hub@2 {
> > 	};
> > }
> > 
> > I had a quick look at RTS5411 datasheet. It looks like there's an i2c
> > interface too.
> > - I guess the I2C interface isn't used in your case ?
> >    (I haven't checked what it could be used for...)
> > 
> > In the stm32 boards (stm32mp15xx-dkx), there's an usb2514b chip
> > - that also could be wired on I2C interface (0R mount option)
> > - unused on stm32 boards by default
> > 
> > usb2514b chip already has a dt-bindings (with compatible), and a driver:
> > - drivers/usb/misc/usb251xb.c
> > - Documentation/devicetree/bindings/usb/usb251xb.txt
> > 
> > It is defined more as an i2c chip, so I'd expect it as an i2c child,
> > e.g. like:
> > 
> > &i2c {
> > 	usb2514b@2c {
> > 		compatible = "microchip,usb2514b";
> > 		...
> > 	};
> > };
> > 
> > 
> > This way, I don't see how it could be used together with onboard_usb_hub
> > driver ? (But I may have missed it)
> > Is it possible to use a phandle, instead of a child node ?
> > 
> > However, in the stm32mp15xx-dkx case, i2c interface isn't wired/used by
> > default. So obviously the i2c driver isn't used. In this case, could the
> > "microchip,usb2514b" be listed in onboard_usb_hub driver ?
> > (wouldn't it be redundant ?)
> > 
> > In this case it would be a child node of the usb DT node... Maybe that's
> > more a question for Rob: would it be "legal" regarding existing
> > dt-bindings ?
> 
> We wanted to upstream driver for microchip usb5744 and based on this thread
> with Rob
> 
> https://lore.kernel.org/all/CAL_JsqJZBbu+UXqUNdZwg-uv0PAsNg55026PTwhKr5wQtxCjVQ@mail.gmail.com/
> 
> the recommendation was to use i2c-bus link. And in our usb5744 case where
> usb hub has only one i2c address we just hardcoded it in the driver. I
> should be pushing this driver to xilinx soc tree soon if you want to take a
> look.

Interesting, with the 'i2c-bus' link it might be feasible to support the
i2c functionality in the onboard_usb_hub driver if desired. Not sure how
things would look when the hub can have different i2c addresses. Also in
case of powering down the hub during system suspend any configuration
through i2c would have to be done again on resume.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v16 6/7] usb: host: xhci-plat: Create platform device for onboard hubs in probe()
  2021-10-20 13:05   ` Mathias Nyman
@ 2021-10-20 20:27     ` Matthias Kaehlcke
  2021-10-20 20:37       ` Alan Stern
  0 siblings, 1 reply; 28+ messages in thread
From: Matthias Kaehlcke @ 2021-10-20 20:27 UTC (permalink / raw)
  To: Mathias Nyman
  Cc: Greg Kroah-Hartman, Alan Stern, Rob Herring, Frank Rowand,
	Mathias Nyman, Felipe Balbi, devicetree, Peter Chen,
	linux-kernel, linux-usb, Bastien Nocera, Ravi Chandra Sadineni,
	Michal Simek, Douglas Anderson, Roger Quadros,
	Krzysztof Kozlowski, Stephen Boyd, Dmitry Osipenko,
	Fabio Estevam

Hi Mathias,

On Wed, Oct 20, 2021 at 04:05:37PM +0300, Mathias Nyman wrote:
> Hi
> 
> On 13.8.2021 22.52, Matthias Kaehlcke wrote:
> > Call onboard_hub_create/destroy_pdevs() from  _probe()/_remove()
> > 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 xhci_hcd to keep track of the onboard hub
> > platform devices that are owned by the xHCI.
> > 
> > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > ---
> 
> Haven't really looked at this series until now.
> 
> Is there any reason why the xhci platform driver was selected as
> the best place to create/remove these onboard hub devices?

IIRC Alan suggested to use the xhci platform driver for creating/removing
the onboard hub devices when we were trying to get rid of a separate DT
node on the 'platform bus', which was suitable the board for my use case.

> This ties the onboard hubs to xhci, and won't work in case we have onboard
> hubs connected to a ehci controllers.

Right, the driver itself isn't limited to xhci. The initial idea was that
support for other types of USB controllers could be added as needed (I only
have a config with xhci for testing).

> If separate devices for controlling onboard hub power is the right solution then
> how about creating the onboard hub device in usb_add_hcd() (hcd.c), and
> store it in struct usb_hcd.
> 
> A bit like how the roothub device is created, or PHYs are tuned.

Sure, that sounds feasible, even better if it's handled in a single place
and different types of controllers don't have to add support separately.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v16 6/7] usb: host: xhci-plat: Create platform device for onboard hubs in probe()
  2021-10-20 20:27     ` Matthias Kaehlcke
@ 2021-10-20 20:37       ` Alan Stern
  2021-10-20 21:01         ` Matthias Kaehlcke
  0 siblings, 1 reply; 28+ messages in thread
From: Alan Stern @ 2021-10-20 20:37 UTC (permalink / raw)
  To: Matthias Kaehlcke
  Cc: Mathias Nyman, Greg Kroah-Hartman, Rob Herring, Frank Rowand,
	Mathias Nyman, Felipe Balbi, devicetree, Peter Chen,
	linux-kernel, linux-usb, Bastien Nocera, Ravi Chandra Sadineni,
	Michal Simek, Douglas Anderson, Roger Quadros,
	Krzysztof Kozlowski, Stephen Boyd, Dmitry Osipenko,
	Fabio Estevam

On Wed, Oct 20, 2021 at 01:27:40PM -0700, Matthias Kaehlcke wrote:
> Hi Mathias,
> 
> On Wed, Oct 20, 2021 at 04:05:37PM +0300, Mathias Nyman wrote:
> > If separate devices for controlling onboard hub power is the right solution then
> > how about creating the onboard hub device in usb_add_hcd() (hcd.c), and
> > store it in struct usb_hcd.
> > 
> > A bit like how the roothub device is created, or PHYs are tuned.
> 
> Sure, that sounds feasible, even better if it's handled in a single place
> and different types of controllers don't have to add support separately.

Bear in mind that this would prevent you from working with onboard 
non-root hubs.

Alan Stern

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v16 6/7] usb: host: xhci-plat: Create platform device for onboard hubs in probe()
  2021-10-20 20:37       ` Alan Stern
@ 2021-10-20 21:01         ` Matthias Kaehlcke
  2021-10-20 21:57           ` Alan Stern
  0 siblings, 1 reply; 28+ messages in thread
From: Matthias Kaehlcke @ 2021-10-20 21:01 UTC (permalink / raw)
  To: Alan Stern
  Cc: Mathias Nyman, Greg Kroah-Hartman, Rob Herring, Frank Rowand,
	Mathias Nyman, Felipe Balbi, devicetree, Peter Chen,
	linux-kernel, linux-usb, Bastien Nocera, Ravi Chandra Sadineni,
	Michal Simek, Douglas Anderson, Roger Quadros,
	Krzysztof Kozlowski, Stephen Boyd, Dmitry Osipenko,
	Fabio Estevam

On Wed, Oct 20, 2021 at 04:37:20PM -0400, Alan Stern wrote:
> On Wed, Oct 20, 2021 at 01:27:40PM -0700, Matthias Kaehlcke wrote:
> > Hi Mathias,
> > 
> > On Wed, Oct 20, 2021 at 04:05:37PM +0300, Mathias Nyman wrote:
> > > If separate devices for controlling onboard hub power is the right solution then
> > > how about creating the onboard hub device in usb_add_hcd() (hcd.c), and
> > > store it in struct usb_hcd.
> > > 
> > > A bit like how the roothub device is created, or PHYs are tuned.
> > 
> > Sure, that sounds feasible, even better if it's handled in a single place
> > and different types of controllers don't have to add support separately.
> 
> Bear in mind that this would prevent you from working with onboard
> non-root hubs.

My goal is to (architecturally) support nested hubs, but TBH I haven't
looked much into such a configuration since I don't have hardware for
testing. My assumption was that support for onboard hubs connected to
non-root hubs whould have to be added to the generic hub driver.

Could you elaborate in how far you think it would be different for
xhci_plat vs generic hcd?

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v16 6/7] usb: host: xhci-plat: Create platform device for onboard hubs in probe()
  2021-10-20 21:01         ` Matthias Kaehlcke
@ 2021-10-20 21:57           ` Alan Stern
  0 siblings, 0 replies; 28+ messages in thread
From: Alan Stern @ 2021-10-20 21:57 UTC (permalink / raw)
  To: Matthias Kaehlcke
  Cc: Mathias Nyman, Greg Kroah-Hartman, Rob Herring, Frank Rowand,
	Mathias Nyman, Felipe Balbi, devicetree, Peter Chen,
	linux-kernel, linux-usb, Bastien Nocera, Ravi Chandra Sadineni,
	Michal Simek, Douglas Anderson, Roger Quadros,
	Krzysztof Kozlowski, Stephen Boyd, Dmitry Osipenko,
	Fabio Estevam

On Wed, Oct 20, 2021 at 02:01:21PM -0700, Matthias Kaehlcke wrote:
> On Wed, Oct 20, 2021 at 04:37:20PM -0400, Alan Stern wrote:
> > On Wed, Oct 20, 2021 at 01:27:40PM -0700, Matthias Kaehlcke wrote:
> > > Hi Mathias,
> > > 
> > > On Wed, Oct 20, 2021 at 04:05:37PM +0300, Mathias Nyman wrote:
> > > > If separate devices for controlling onboard hub power is the right solution then
> > > > how about creating the onboard hub device in usb_add_hcd() (hcd.c), and
> > > > store it in struct usb_hcd.
> > > > 
> > > > A bit like how the roothub device is created, or PHYs are tuned.
> > > 
> > > Sure, that sounds feasible, even better if it's handled in a single place
> > > and different types of controllers don't have to add support separately.
> > 
> > Bear in mind that this would prevent you from working with onboard
> > non-root hubs.
> 
> My goal is to (architecturally) support nested hubs, but TBH I haven't
> looked much into such a configuration since I don't have hardware for
> testing. My assumption was that support for onboard hubs connected to
> non-root hubs whould have to be added to the generic hub driver.
> 
> Could you elaborate in how far you think it would be different for
> xhci_plat vs generic hcd?

A lot of this material has slipped from my mind.  However, I don't see 
much difference between those two approaches.

Alan Stern

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v16 1/7] usb: misc: Add onboard_usb_hub driver
  2021-08-13 19:52 ` [PATCH v16 1/7] " Matthias Kaehlcke
@ 2021-11-11 23:31   ` Doug Anderson
  2021-11-16  2:08     ` Matthias Kaehlcke
  0 siblings, 1 reply; 28+ messages in thread
From: Doug Anderson @ 2021-11-11 23:31 UTC (permalink / raw)
  To: Matthias Kaehlcke
  Cc: Greg Kroah-Hartman, Alan Stern, Rob Herring, Frank Rowand,
	Mathias Nyman, Felipe Balbi, devicetree, Peter Chen,
	linux-kernel, linux-usb, Bastien Nocera, Ravi Chandra Sadineni,
	Michal Simek, Roger Quadros, Krzysztof Kozlowski, Stephen Boyd,
	Al Cooper

Hi,

On Fri, Aug 13, 2021 at 12:52 PM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> +++ 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:          March 2021
> +KernelVersion: 5.13

I dunno how stuff like this is usually managed, but March 2021 and
5.13 is no longer correct.


> +ONBOARD USB HUB DRIVER
> +M:     Matthias Kaehlcke <mka@chromium.org>
> +L:     linux-usb@vger.kernel.org
> +S:     Maintained
> +F:     Documentation/devicetree/bindings/usb/onboard_usb_hub.yaml

I'm confused. Where is this .yaml file? It doesn't look landed and it
doesn't look to be in your series. I guess this should be updated to:

F: Documentation/devicetree/bindings/usb/realtek,rts5411.yaml

Also: should this have:

F: Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub


> +struct udev_node {
> +       struct usb_device *udev;
> +       struct list_head list;
> +};

nit: 'udev' has a whole different connotation to me. Maybe just go
with `usbdev_node` ?


> +static int __maybe_unused onboard_hub_suspend(struct device *dev)
> +{
> +       struct onboard_hub *hub = dev_get_drvdata(dev);
> +       struct udev_node *node;
> +       bool power_off;
> +       int rc = 0;
> +
> +       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)
> +               rc = onboard_hub_power_off(hub);
> +
> +       return rc;

optional nit: get rid of "rc" and write the above as:

if (power_off)
  return onboard_hub_power_off(hub);

return 0;


> +static int __maybe_unused onboard_hub_resume(struct device *dev)
> +{
> +       struct onboard_hub *hub = dev_get_drvdata(dev);
> +       int rc = 0;
> +
> +       if (!hub->is_powered_on)
> +               rc = onboard_hub_power_on(hub);
> +
> +       return rc;

optional nit: get rid of "rc" and write the above as:

if (!hub->is_powered_on)
  return onboard_hub_power_on(hub);

return 0;


> +static void onboard_hub_remove_usbdev(struct onboard_hub *hub, struct usb_device *udev)
> +{
> +       struct udev_node *node;
> +       char link_name[64];
> +
> +       snprintf(link_name, sizeof(link_name), "usb_dev.%s", dev_name(&udev->dev));
> +       sysfs_remove_link(&hub->dev->kobj, link_name);

I would be at least moderately worried about the duplicate snprintf
between here and the add function. Any way that could be a helper?


> +static struct onboard_hub *_find_onboard_hub(struct device *dev)
> +{
> +       struct platform_device *pdev;
> +       struct device_node *np;
> +       phandle ph;
> +
> +       pdev = of_find_device_by_node(dev->of_node);
> +       if (!pdev) {
> +               if (of_property_read_u32(dev->of_node, "companion-hub", &ph)) {
> +                       dev_err(dev, "failed to read 'companion-hub' property\n");
> +                       return ERR_PTR(-EINVAL);
> +               }
> +
> +               np = of_find_node_by_phandle(ph);
> +               if (!np) {
> +                       dev_err(dev, "failed to find device node for companion hub\n");
> +                       return ERR_PTR(-EINVAL);
> +               }

Aren't the above two calls equivalent to this?

npc = of_parse_phandle(dev->of_node, "companion-hub", 0)


> +
> +               pdev = of_find_device_by_node(np);
> +               of_node_put(np);
> +
> +               if (!pdev)
> +                       return ERR_PTR(-EPROBE_DEFER);

Shouldn't you also defer if the dev_get_drvdata() returns NULL? What
if you're racing the probe of the platform device?


> +       }
> +
> +       put_device(&pdev->dev);
> +
> +       return dev_get_drvdata(&pdev->dev);

It feels like it would be safer to call dev_get_drvdata() before
putting the device? ...and actually, are you sure you should even be
putting the device? Maybe we should wait to put it until
onboard_hub_usbdev_disconnect()


> +static struct usb_device_driver onboard_hub_usbdev_driver = {
> +
> +       .name = "onboard-usb-hub",

Remove the extra blank line at the start of the structure?


> +void onboard_hub_create_pdevs(struct usb_device *parent_hub, struct list_head *pdev_list)
> +{
> +       int i;
> +       phandle ph;
> +       struct device_node *np, *npc;
> +       struct platform_device *pdev;
> +       struct pdev_list_entry *pdle;

Should the `INIT_LIST_HEAD(pdev_list);` go here? Is there any reason
why we need to push this into the caller?


> +       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;
> +
> +               if (of_property_read_u32(np, "companion-hub", &ph))
> +                       goto node_put;
> +
> +               npc = of_find_node_by_phandle(ph);
> +               if (!npc)
> +                       goto node_put;

Aren't the above two calls equivalent to this?

npc = of_parse_phandle(np, "companion-hub", 0)

I'm also curious why a companion-hub is a _required_ property.
Couldn't you support USB 2.0 hubs better by just allowing
companion-hub to be optional? I guess that could be a future
improvement, but it also seems trivial to support from the start.


> +               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;
> +               }
> +
> +               pdev = of_platform_device_create(np, NULL, &parent_hub->dev);
> +               if (pdev) {
> +                       pdle = kzalloc(sizeof(*pdle), GFP_KERNEL);

Maybe devm_kzalloc(&pdev->dev, GFP_KERNEL) ? Then you can get rid of
the free in the destroy function?


> +                       if (!pdle)
> +                               goto node_put;

If your memory allocation fails here, don't you need to
of_platform_device_destroy() ?


> +                       INIT_LIST_HEAD(&pdle->node);

I don't believe that the INIT_LIST_HEAD() does anything useful here.
&pdle->node is not a list head--it's a list element. Adding it to the
end of the existing list will fully initialize its ->next and ->prev
pointers but won't look at what they were.


> +                       pdle->pdev = pdev;
> +                       list_add(&pdle->node, pdev_list);
> +               } else {
> +                       dev_err(&parent_hub->dev,
> +                               "failed to create platform device for onboard hub '%s'\n",
> +                               of_node_full_name(np));

Use "%pOF" instead of open-coding.


> +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) {
> +               of_platform_device_destroy(&pdle->pdev->dev, NULL);
> +               kfree(pdle);

It feels like you should be removing the node from the list too,
right? Otherwise if you unbind / bind the USB driver you'll still have
garbage in your list the 2nd time?

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v16 5/7] usb: Specify dependencies on USB_XHCI_PLATFORM with 'depends on'
  2021-08-13 19:52 ` [PATCH v16 5/7] usb: Specify dependencies on USB_XHCI_PLATFORM with 'depends on' Matthias Kaehlcke
  2021-08-26  6:46   ` Roger Quadros
@ 2021-11-11 23:48   ` Doug Anderson
  2021-11-16 18:07     ` Matthias Kaehlcke
  1 sibling, 1 reply; 28+ messages in thread
From: Doug Anderson @ 2021-11-11 23:48 UTC (permalink / raw)
  To: Matthias Kaehlcke
  Cc: Greg Kroah-Hartman, Alan Stern, Rob Herring, Frank Rowand,
	Mathias Nyman, Felipe Balbi, devicetree, Peter Chen,
	linux-kernel, linux-usb, Bastien Nocera, Ravi Chandra Sadineni,
	Michal Simek, Roger Quadros, Krzysztof Kozlowski, Stephen Boyd,
	Andrew Lunn, Aswath Govindraju, Dmitry Osipenko, Fabio Estevam,
	Gregory Clement, Krzysztof Kozlowski, Pawel Laszczak,
	Sebastian Hesselbarth, Tony Lindgren, linux-arm-kernel,
	linux-omap, linux-samsung-soc

Hi,

On Fri, Aug 13, 2021 at 12:52 PM Matthias Kaehlcke <mka@chromium.org> wrote:
>
>  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 && USB_XHCI_PLATFORM) || USB_GADGET) && HAS_DMA

Technically you don't need the "USB &&", right? Since
USB_XHCI_PLATFORM is defined in 'usb/host/Kconfig' and that's only
even included if USB is defined. So it can be just:

depends on (USB_XHCI_PLATFORM || USB_GADGET) && HAS_DMA

That's not terribly important, though, so:

Reviewed-by: Douglas Anderson <dianders@chromium.org>

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v16 1/7] usb: misc: Add onboard_usb_hub driver
  2021-11-11 23:31   ` Doug Anderson
@ 2021-11-16  2:08     ` Matthias Kaehlcke
  0 siblings, 0 replies; 28+ messages in thread
From: Matthias Kaehlcke @ 2021-11-16  2:08 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Greg Kroah-Hartman, Alan Stern, Rob Herring, Frank Rowand,
	Mathias Nyman, Felipe Balbi, devicetree, Peter Chen,
	linux-kernel, linux-usb, Bastien Nocera, Ravi Chandra Sadineni,
	Michal Simek, Roger Quadros, Krzysztof Kozlowski, Stephen Boyd,
	Al Cooper

Hi Doug,

thanks for the thorough review!

On Thu, Nov 11, 2021 at 03:31:31PM -0800, Doug Anderson wrote:
> Hi,
> 
> On Fri, Aug 13, 2021 at 12:52 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> >
> > +++ 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:          March 2021
> > +KernelVersion: 5.13
> 
> I dunno how stuff like this is usually managed, but March 2021 and
> 5.13 is no longer correct.

will update, though it's not unlikely it will go stale again before this
series lands.

> > +ONBOARD USB HUB DRIVER
> > +M:     Matthias Kaehlcke <mka@chromium.org>
> > +L:     linux-usb@vger.kernel.org
> > +S:     Maintained
> > +F:     Documentation/devicetree/bindings/usb/onboard_usb_hub.yaml
> 
> I'm confused. Where is this .yaml file? It doesn't look landed and it
> doesn't look to be in your series.

It's a leftover from the early days of the series, when the driver had
it's own binding, I'll remove it.

> I guess this should be updated to:
> 
> F: Documentation/devicetree/bindings/usb/realtek,rts5411.yaml

Not sure about that, the rts5411 binding could exist without this driver.

> Also: should this have:
> 
> F: Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub

ack

> > +struct udev_node {
> > +       struct usb_device *udev;
> > +       struct list_head list;
> > +};
> 
> nit: 'udev' has a whole different connotation to me. Maybe just go
> with `usbdev_node` ?

Will change to 'usbdev_dev' node as suggested, I think it's ok to keep
'udev' for the pointer to the USB device itself, since that abbreviation
is used commonly in USB kernel land.

> > +static int __maybe_unused onboard_hub_suspend(struct device *dev)
> > +{
> > +       struct onboard_hub *hub = dev_get_drvdata(dev);
> > +       struct udev_node *node;
> > +       bool power_off;
> > +       int rc = 0;
> > +
> > +       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)
> > +               rc = onboard_hub_power_off(hub);
> > +
> > +       return rc;
> 
> optional nit: get rid of "rc" and write the above as:
> 
> if (power_off)
>   return onboard_hub_power_off(hub);
> 
> return 0;

ok, I plan to revert the suggested logic though and bail out 'early' if there
is nothing to do.

> > +static int __maybe_unused onboard_hub_resume(struct device *dev)
> > +{
> > +       struct onboard_hub *hub = dev_get_drvdata(dev);
> > +       int rc = 0;
> > +
> > +       if (!hub->is_powered_on)
> > +               rc = onboard_hub_power_on(hub);
> > +
> > +       return rc;
> 
> optional nit: get rid of "rc" and write the above as:
> 
> if (!hub->is_powered_on)
>   return onboard_hub_power_on(hub);
> 
> return 0;

ok, same as above

> > +static void onboard_hub_remove_usbdev(struct onboard_hub *hub, struct usb_device *udev)
> > +{
> > +       struct udev_node *node;
> > +       char link_name[64];
> > +
> > +       snprintf(link_name, sizeof(link_name), "usb_dev.%s", dev_name(&udev->dev));
> > +       sysfs_remove_link(&hub->dev->kobj, link_name);
> 
> I would be at least moderately worried about the duplicate snprintf
> between here and the add function. Any way that could be a helper?

I'll add a helper

> > +static struct onboard_hub *_find_onboard_hub(struct device *dev)
> > +{
> > +       struct platform_device *pdev;
> > +       struct device_node *np;
> > +       phandle ph;
> > +
> > +       pdev = of_find_device_by_node(dev->of_node);
> > +       if (!pdev) {
> > +               if (of_property_read_u32(dev->of_node, "companion-hub", &ph)) {
> > +                       dev_err(dev, "failed to read 'companion-hub' property\n");
> > +                       return ERR_PTR(-EINVAL);
> > +               }
> > +
> > +               np = of_find_node_by_phandle(ph);
> > +               if (!np) {
> > +                       dev_err(dev, "failed to find device node for companion hub\n");
> > +                       return ERR_PTR(-EINVAL);
> > +               }
> 
> Aren't the above two calls equivalent to this?
> 
> npc = of_parse_phandle(dev->of_node, "companion-hub", 0)

Indeed, will use of_parse_phandle() instead

> > +
> > +               pdev = of_find_device_by_node(np);
> > +               of_node_put(np);
> > +
> > +               if (!pdev)
> > +                       return ERR_PTR(-EPROBE_DEFER);
> 
> Shouldn't you also defer if the dev_get_drvdata() returns NULL? What
> if you're racing the probe of the platform device?

Yeah, it seems that race could happen. IIUC we could use device_is_bound()
to check if probing completed, really_probe() calls driver_bound() only
after successfully probing the device.

> > +       }
> > +
> > +       put_device(&pdev->dev);
> > +
> > +       return dev_get_drvdata(&pdev->dev);
> 
> It feels like it would be safer to call dev_get_drvdata() before
> putting the device? ...and actually, are you sure you should even be
> putting the device? Maybe we should wait to put it until
> onboard_hub_usbdev_disconnect()

It shouldn't be necessary, when the platform device is destroyed it
unbinds the associated USB devices (see onboard_hub_remove()), hence
they don't keep using the drvdata. There was a related discussion in
the early days of this series: https://lkml.org/lkml/2020/9/21/2153

> > +static struct usb_device_driver onboard_hub_usbdev_driver = {
> > +
> > +       .name = "onboard-usb-hub",
> 
> Remove the extra blank line at the start of the structure?

ok

> > +void onboard_hub_create_pdevs(struct usb_device *parent_hub, struct list_head *pdev_list)
> > +{
> > +       int i;
> > +       phandle ph;
> > +       struct device_node *np, *npc;
> > +       struct platform_device *pdev;
> > +       struct pdev_list_entry *pdle;
> 
> Should the `INIT_LIST_HEAD(pdev_list);` go here? Is there any reason
> why we need to push this into the caller?

That would limit pdev_list to a single entry, which is not what we want. A
parent hub might have multiple compatible onboard hubs connected to it.

> > +       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;
> > +
> > +               if (of_property_read_u32(np, "companion-hub", &ph))
> > +                       goto node_put;
> > +
> > +               npc = of_find_node_by_phandle(ph);
> > +               if (!npc)
> > +                       goto node_put;
> 
> Aren't the above two calls equivalent to this?
> 
> npc = of_parse_phandle(np, "companion-hub", 0)

yes, will change to of_parse_phandle()

> I'm also curious why a companion-hub is a _required_ property.
> Couldn't you support USB 2.0 hubs better by just allowing
> companion-hub to be optional? I guess that could be a future
> improvement, but it also seems trivial to support from the start.

The evolution of this driver somewhat tied it to xHCI, however that
isn't strictly necessary. In a sense it is nice when 'companion-hub'
is mandatory, since things can get messy if it is forgotten when it
should be there.

The property should be mandatory in the bindings of the USB >= 3.0
hubs that are supported by this driver, but it could be optional
for USB 2.0 hubs. Instead of doing the enforcement in the driver
it could be limited to checking a DT against the bindings in .yaml.
It's also an option to make it mandatory in the driver through a
list of compatible strings / VIDs/PIDs.

> > +               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;
> > +               }
> > +
> > +               pdev = of_platform_device_create(np, NULL, &parent_hub->dev);
> > +               if (pdev) {
> > +                       pdle = kzalloc(sizeof(*pdle), GFP_KERNEL);
> 
> Maybe devm_kzalloc(&pdev->dev, GFP_KERNEL) ? Then you can get rid of
> the free in the destroy function?

it feels a bit sneaky to do it after creation instead of probe(), but I guess
it's fine.

> > +                       if (!pdle)
> > +                               goto node_put;
> 
> If your memory allocation fails here, don't you need to
> of_platform_device_destroy() ?

right, will call of_platform_device_destroy() in case of failure

> > +                       INIT_LIST_HEAD(&pdle->node);
> 
> I don't believe that the INIT_LIST_HEAD() does anything useful here.
> &pdle->node is not a list head--it's a list element. Adding it to the
> end of the existing list will fully initialize its ->next and ->prev
> pointers but won't look at what they were.

indeed, will remove

> > +                       pdle->pdev = pdev;
> > +                       list_add(&pdle->node, pdev_list);
> > +               } else {
> > +                       dev_err(&parent_hub->dev,
> > +                               "failed to create platform device for onboard hub '%s'\n",
> > +                               of_node_full_name(np));
> 
> Use "%pOF" instead of open-coding.

ack

> > +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) {
> > +               of_platform_device_destroy(&pdle->pdev->dev, NULL);
> > +               kfree(pdle);
> 
> It feels like you should be removing the node from the list too,
> right? Otherwise if you unbind / bind the USB driver you'll still have
> garbage in your list the 2nd time?

Could catch, it seems I limited testing to a single removal ...

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v16 5/7] usb: Specify dependencies on USB_XHCI_PLATFORM with 'depends on'
  2021-11-11 23:48   ` Doug Anderson
@ 2021-11-16 18:07     ` Matthias Kaehlcke
  0 siblings, 0 replies; 28+ messages in thread
From: Matthias Kaehlcke @ 2021-11-16 18:07 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Greg Kroah-Hartman, Alan Stern, Rob Herring, Frank Rowand,
	Mathias Nyman, Felipe Balbi, devicetree, Peter Chen,
	linux-kernel, linux-usb, Bastien Nocera, Ravi Chandra Sadineni,
	Michal Simek, Roger Quadros, Krzysztof Kozlowski, Stephen Boyd,
	Andrew Lunn, Aswath Govindraju, Dmitry Osipenko, Fabio Estevam,
	Gregory Clement, Krzysztof Kozlowski, Pawel Laszczak,
	Sebastian Hesselbarth, Tony Lindgren, linux-arm-kernel,
	linux-omap, linux-samsung-soc

On Thu, Nov 11, 2021 at 03:48:06PM -0800, Doug Anderson wrote:
> Hi,
> 
> On Fri, Aug 13, 2021 at 12:52 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> >
> >  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 && USB_XHCI_PLATFORM) || USB_GADGET) && HAS_DMA
> 
> Technically you don't need the "USB &&", right? Since
> USB_XHCI_PLATFORM is defined in 'usb/host/Kconfig' and that's only
> even included if USB is defined. So it can be just:
> 
> depends on (USB_XHCI_PLATFORM || USB_GADGET) && HAS_DMA

True, the dependency on USB isn't strictly needed.

> That's not terribly important, though, so:
> 
> Reviewed-by: Douglas Anderson <dianders@chromium.org>

Thanks!

^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, other threads:[~2021-11-16 18:07 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-13 19:52 [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver Matthias Kaehlcke
2021-08-13 19:52 ` [PATCH v16 1/7] " Matthias Kaehlcke
2021-11-11 23:31   ` Doug Anderson
2021-11-16  2:08     ` Matthias Kaehlcke
2021-08-13 19:52 ` [PATCH v16 2/7] of/platform: Add stubs for of_platform_device_create/destroy() Matthias Kaehlcke
2021-08-13 19:52 ` [PATCH v16 3/7] ARM: configs: Explicitly enable USB_XHCI_PLATFORM where needed Matthias Kaehlcke
2021-08-26  6:45   ` Roger Quadros
2021-08-26  7:56   ` Krzysztof Kozlowski
2021-08-13 19:52 ` [PATCH v16 4/7] arm64: defconfig: Explicitly enable USB_XHCI_PLATFORM Matthias Kaehlcke
2021-08-26  6:46   ` Roger Quadros
2021-08-13 19:52 ` [PATCH v16 5/7] usb: Specify dependencies on USB_XHCI_PLATFORM with 'depends on' Matthias Kaehlcke
2021-08-26  6:46   ` Roger Quadros
2021-11-11 23:48   ` Doug Anderson
2021-11-16 18:07     ` Matthias Kaehlcke
2021-08-13 19:52 ` [PATCH v16 6/7] usb: host: xhci-plat: Create platform device for onboard hubs in probe() Matthias Kaehlcke
2021-10-20 13:05   ` Mathias Nyman
2021-10-20 20:27     ` Matthias Kaehlcke
2021-10-20 20:37       ` Alan Stern
2021-10-20 21:01         ` Matthias Kaehlcke
2021-10-20 21:57           ` Alan Stern
2021-08-13 19:52 ` [PATCH v16 7/7] arm64: dts: qcom: sc7180-trogdor: Add nodes for onboard USB hub Matthias Kaehlcke
2021-09-21 17:08 ` [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver Matthias Kaehlcke
2021-10-14 21:38   ` Doug Anderson
2021-10-15  6:39     ` Greg Kroah-Hartman
2021-10-19 16:04       ` Fabrice Gasnier
2021-10-19 22:10         ` Matthias Kaehlcke
2021-10-20  6:21         ` Michal Simek
2021-10-20 17:41           ` Matthias Kaehlcke

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).