[PATCH v22 0/3] usb: misc: Add onboard_usb_hub driver

[PATCH v22 0/3] usb: misc: Add onboard_usb_hub driver

[Matthias Kaehlcke]

This series adds:
- the onboard_usb_hub_driver
- glue in the generic hub code to create and destroy the
  onboard_usb_hub platform devices if needed
- device tree changes that add RTS5411 entries for the QCA SC7180
  based boards trogdor and lazor
- a couple of stubs for platform device functions to avoid
  unresolved symbols with certain kernel configs

The main issue the driver addresses is that a USB hub needs to be
powered before it can be discovered. For discrete onboard hubs (an
example for such a hub is the Realtek RTS5411) this is often solved
by supplying the hub with an 'always-on' regulator, which is kind
of a hack. Some onboard hubs may require further initialization
steps, like changing the state of a GPIO or enabling a clock, which
requires even more hacks. This driver creates a platform device
representing the hub which performs the necessary initialization.
Currently it only supports switching on a single regulator, support
for multiple regulators or other actions can be added as needed.
Different initialization sequences can be supported based on the
compatible string.

Besides performing the initialization the driver can be configured
to power the hub off during system suspend. This can help to extend
battery life on battery powered devices which have no requirements
to keep the hub powered during suspend. The driver can also be
configured to leave the hub powered when a wakeup capable USB device
is connected when suspending, and power it off otherwise.

Changes in v22:
- call onboard_hub_create/destroy_pdevs() from hub_probe/disconnect()
  instead of doing it from the HCD. When the pdevs are create from the
  HCD usb_of_get_device_node() (called by onboard_hub_create_pdevs())
  may return NULL because the USB device for the root hub doesn't
  exist yet. Creating the pdevs from the hub code also has the
  advantage of enabling support for nested onboard hubs (as long as
  all hubs in the chain have DT nodes and are supported by the driver).
- moved onboard_hub_create_pdevs(), onboard_hub_destroy_pdevs() and
  of_is_onboard_usb_hub() into a separate file to allow them to be
  linked into the USB core module (if CONFIG_USB=m)
- Added extra checks to ensure only one platform device is created
  for each physical hub. This is necessary because
  onboard_hub_create_pdevs() is now called from hub_probe() instead
  of usb_add_hcd(). As a result the function is called twice for
  typical USB3 hub, once for the USB3 part of the hub, and once for
  USB <= 2.x. Generally the parent hub downstream of the primary HCD
  creates the onboard hub platform device.
- use kzalloc() instead of devm_kzalloc() to allocate list entries. Using
  managed memory can cause issues since the managed memory is allocated
  before the device is probed.
- use a workqueue to (re-)attach the USB driver during/after _probe().
  This is necessary to avoid self-deadlocks on systems with nested
  onboard hubs.
- don't initialize list_head in onboard_hub_create_pdevs(), this needs
  to be done by the owner, to ensure that onboard_hub_destroy_pdevs()
  is called with a struct that was properly initialized even when
  onboard_hub_create_pdevs() is not called.
- rebased series on v5.19-rc1

Changes in v21:
- dropped patch 'driver core: Export device_is_bound()'
- refactored _find_onboard_hub()
- removed 'onboard_hub_dev' symlinks from USB devices
- dropped patch 'arm64: dts: qcom: sc7180-trogdor: Add nodes for onboard USB hub'
  (will be sent separately)
- rebased series on v5.17-rc4

Changes in v20:
- addressed review comments from Stephen
- changed DT node names for hubs

Changes in v19:
- added VID:PID pairs and compatible strings for RTS5414 hub
- updated comments with RTS5411 USB versions to reflect those
  reported/supported by the hub
- rebased series on v5.16

Changes in v18:
- introduced hidden Kconfig option to align module vs. builtin
  choice with CONFIG_USB (thanks Doug!)
- added patch 'driver core: Export device_is_bound()'
- also adjust device tree of pompom rev1
- dropped the following patches, which aren't needed anymore by this
  series (though they might still be useful on their own):
  - usb: Specify dependencies on USB_XHCI_PLATFORM with 'depends on'
  - arm64: defconfig: Explicitly enable USB_XHCI_PLATFORM
  - ARM: configs: Explicitly enable USB_XHCI_PLATFORM where needed

Changes in v17:
- rebased on top of v5.16-rc1
- moved creation of onboard_hub platform devices from xhci_platform
  to the generic HCD code
- addressed review comments for the onboard_hub driver
- moved Kconfig/defconfig changes to the end of the series. The
  onboard_hub driver doesn't depend on XHCI_PLATFORM anymore,
  hence these changes aren't really required for the driver, but
  they still seem to be a worthwhile improvement

Changes in v16:
- added patch 'ARM: configs: Explicitly enable USB_XHCI_PLATFORM
  where needed' to keep arm32 defconfigs effectively unchanged

Changes in v15:
- adjusted dependencies of USB_DWC3_CORE to make sure it can only
  be enabled when at least one of USB_DWC3_HOST, USB_DWC3_GADGET
  or USB_DWC3_DUAL_ROLE is selectable

Changes in v14:
- rebased on top of v5.14-rc1
- dropped DT binding patch which landed in v5.13

Changes in v13:
- added patch "usb: Specify dependency on USB_XHCI_PLATFORM with
  'depends on'" to the series to avoid Kconfig conflicts
- added patch "arm64: defconfig: Explicitly enable USB_XHCI_PLATFORM"
  to the series to keep effective defconfig unchanged

Changes in v12:
- onboard_hub driver: use IS_ENABLED(CONFIG_USB_ONBOARD_HUB_MODULE)
  in onboard_hub.h to also check for the driver built as module
- onboard_hub_driver: include onboard_hub.h again to make sure there
  are prototype declarations for the public functions

Changes in v11:
- support multiple onboard hubs connected to the same parent
- don't include ‘onboard_hub.h’ from the onboard hub driver

Changes in v10:
- always use of_is_onboard_usb_hub() stub unless ONBOARD_USB_HUB=y/m
- keep 'regulator-boot-on' property for pp3300_hub

Changes in v9:
- added dependency on ONBOARD_USB_HUB (or !ONBOARD_USB_HUB) to
  USB_PLATFORM_XHCI

Changes in v7:
- updated DT binding
- series rebased on qcom/arm64-for-5.13

Changes in v6:
- updated summary

Changes in v5:
- cover letter added

Matthias Kaehlcke (3):
  of/platform: Add stubs for of_platform_device_create/destroy()
  usb: misc: Add onboard_usb_hub driver
  usb: core: hub: Create platform devices for onboard hubs in
    hub_probe()

 .../sysfs-bus-platform-onboard-usb-hub        |   8 +
 MAINTAINERS                                   |   7 +
 drivers/usb/core/Makefile                     |   1 +
 drivers/usb/core/hub.c                        |   9 +-
 drivers/usb/core/hub.h                        |   1 +
 drivers/usb/misc/Kconfig                      |  23 +
 drivers/usb/misc/Makefile                     |   1 +
 drivers/usb/misc/onboard_usb_hub.c            | 426 ++++++++++++++++++
 drivers/usb/misc/onboard_usb_hub.h            |  17 +
 drivers/usb/misc/onboard_usb_hub_pdevs.c      | 129 ++++++
 include/linux/of_platform.h                   |  22 +-
 include/linux/usb/onboard_hub.h               |  18 +
 12 files changed, 657 insertions(+), 5 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 drivers/usb/misc/onboard_usb_hub.h
 create mode 100644 drivers/usb/misc/onboard_usb_hub_pdevs.c
 create mode 100644 include/linux/usb/onboard_hub.h

-- 
2.36.1.476.g0c4daa206d-goog

[PATCH v22 1/3] of/platform: Add stubs for of_platform_device_create/destroy()

[Matthias Kaehlcke]

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

Changes in v22:
- none

Changes in v21:
- none

Changes in v20:
- added 'Reviewed-by' tags from Stephen and Doug

Changes in v19:
- still no changes ...

Changes in v18:
- still no changes ...

Changes in v17:
- none

Changes in v16:
- none

Changes in v15:
- none

Changes in v14:
- none

Changes in v13:
- none

Changes in v12:
- none

Changes in v11:
- none

Changes in v10:
- none

Changes in v9:
- added Rob's 'Acked-by' tag

Changes in v8:
- fixed C&P error in commit message

Changes in v7:
- none

Changes in v6:
- patch added to the series

 include/linux/of_platform.h | 22 ++++++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
index 84a966623e78..d15b6cd5e1c3 100644
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -61,16 +61,18 @@ static inline struct platform_device *of_find_device_by_node(struct device_node
 }
 #endif
 
+extern int of_platform_bus_probe(struct device_node *root,
+				 const struct of_device_id *matches,
+				 struct device *parent);
+
+#ifdef CONFIG_OF_ADDRESS
 /* Platform devices and busses creation */
 extern struct platform_device *of_platform_device_create(struct device_node *np,
 						   const char *bus_id,
 						   struct device *parent);
 
 extern int of_platform_device_destroy(struct device *dev, void *data);
-extern int of_platform_bus_probe(struct device_node *root,
-				 const struct of_device_id *matches,
-				 struct device *parent);
-#ifdef CONFIG_OF_ADDRESS
+
 extern int of_platform_populate(struct device_node *root,
 				const struct of_device_id *matches,
 				const struct of_dev_auxdata *lookup,
@@ -84,6 +86,18 @@ extern int devm_of_platform_populate(struct device *dev);
 
 extern void devm_of_platform_depopulate(struct device *dev);
 #else
+/* Platform devices and busses creation */
+static inline struct platform_device *of_platform_device_create(struct device_node *np,
+								const char *bus_id,
+								struct device *parent)
+{
+	return NULL;
+}
+static inline int of_platform_device_destroy(struct device *dev, void *data)
+{
+	return -ENODEV;
+}
+
 static inline int of_platform_populate(struct device_node *root,
 					const struct of_device_id *matches,
 					const struct of_dev_auxdata *lookup,
-- 
2.36.1.476.g0c4daa206d-goog

[PATCH v22 2/3] usb: misc: Add onboard_usb_hub driver

[Matthias Kaehlcke]

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).

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>
---

Changes in v22:
- moved onboard_hub_create_pdevs(), onboard_hub_destroy_pdevs() and
  of_is_onboard_usb_hub() into a separate file to allow them to be
  linked into the USB core module (if CONFIG_USB=m)
- Added extra checks to ensure only one platform device is created
  for each physical hub. This is necessary because
  onboard_hub_create_pdevs() is now called from hub_probe() instead
  of usb_add_hcd(). As a result the function is called twice for
  typical USB3 hub, once for the USB3 part of the hub, and once for
  USB <= 2.x. Generally the parent hub downstream of the primary HCD
  creates the onboard hub platform device.
- use kzalloc() instead of devm_kzalloc() to allocate list entries. Using
  managed memory can cause issues since the managed memory is allocated
  before the device is probed.
- use a workqueue to (re-)attach the USB driver during/after _probe().
  This is necessary to avoid self-deadlocks on systems with nested
  onboard hubs.
- don't initialize list_head in onboard_hub_create_pdevs(), this needs
  to be done by the owner, to ensure that onboard_hub_destroy_pdevs()
  is called with a struct that was properly initialized even when
  onboard_hub_create_pdevs() is not called.
- moved 'onboard_hub_match' into an include, so it can be used
  by both the the onboard hub driver and of_is_onboard_usb_hub()
- removed note from the commit message which said that currently only
  onboard hubs connected to a root hub are supported. This isn't the
  case anymore.
- updated kernel version and date in sysfs documentation
- removed tags from Doug and Alan since this version changes quite
  a few things

Changes in v21:
- refactored _find_onboard_hub()
  - check presence of drvdata instead of using device_is_bound()
  - return -ENODEV if the platform device can't be found
  - always check drvdata, not only when looking for the companion
    hub
  - added comment explaining probe deferral
- removed 'onboard_hub_dev' symlinks from USB devices
- updated documentation of 'always_powered_in_suspend' sysfs attribute

Changes in v20:
- s/nontrivial/non-trivial/ in Kconfig doc
- added include of 'export.h'
- initialize variable 'power_off' in onboard_hub_suspend() at
  declaration time
- renamed set_udev_link_name() to get_udev_link_name()
- use kzalloc to allocate struct usbdev_node instead of devm_kzalloc()
- release the lock in onboard_hub_add_usbdev() before calling
  get_udev_link_name()
- free struct usbdev_node in onboard_hub_remove_usbdev(), now that
  it doesn't used managed memory
- make struct onboard_hub const in always_powered_in_suspend_show()
- call put_device() if pdev is not bound in _find_onboard_hub()
- get driver data before calling put_device() in _find_onboard_hub()
- log platform device name when sysfs link creation fails in
  onboard_hub_usbdev_probe()
- added kernel doc for onboard_hub_create_pdevs() and
  onboard_hub_destroy_pdevs()
- added 'Reviewed-by' tag from Doug

Changes in v19:
- added VID:PID pairs and compatible strings for RTS5414 hub
- updated comments with RTS5411 USB versions to reflect those
  reported/supported by the hub

Changes in v18:
- introduced hidden Kconfig option to align module vs. builtin
  choice with CONFIG_USB (thanks Doug!)
- refactored onboard_hub_create_pdevs()

Changes in v17:
- updated date and kernel version in ABI documentation for
  'always_powered_in_suspend' attribute
- removed obsolete .yaml entry from MAINTAINERS file
- added entry for ABI documentation to MAINTAINERS file
- renamed struct 'udev_node' to 'usbdev_node'
- changed return logic in onboard_hub_suspend/resume() to
  get rid of 'rc' variable
- added helper set_udev_link_name() to set link names for
  onboard hub USB devices
- use of_parse_phandle() instead of of_property_read_u32() +
  of_find_node_by_phandle() combo
- defer probing in _find_onboard_hub() if the platform device
  isn't bound yet
- initialize list head passed as parameter to
  onboard_hub_create_pdevs() instead of relying on the caller
  to do so
- don't require the 'companion-hub' property to be specified.
  This is needed to support hubs without companion hub
- use devm_kzalloc() to allocate platform device list entries
  and stop freeing them explicitly
- remove unnecessary INIT_LIST_HEAD() of platform device list
  entries
- use '%pOF' to print DT node name
- delete platform device list entries from the list of devices
  in onboard_hub_destroy_pdevs(). It shouldn't be strictly
  necessary, but better be on the safe side.

Changes in v16:
- none

Changes in v15:
- none

Changes in v14:
- none

Changes in v13:
- none

Changes in v12:
- use IS_ENABLED(CONFIG_USB_ONBOARD_HUB_MODULE) in onboard_hub.h to
  also check for the driver built as module
- include onboard_hub.h again from the driver to make sure there are
  prototype declarations for the public functions
- remove indentation from label in onboard_hub_create_pdevs()

Changes in v11:
- added onboard_hub_create/destroy_pdevs() helpers, to support multiple onboard
  hubs connected to the same parent hub
- don't include ‘onboard_hub.h’ from the onboard hub driver
- updated commit message
- added ‘Acked-by' from Alan

Changes in v10:
- always use of_is_onboard_usb_hub() stub unless ONBOARD_USB_HUB=y/m

Changes in v9:
- none

Changes in v8:
- none

Changes in v7:
- don't declare stub for of_is_onboard_usb_hub() when
  CONFIG_COMPILE_TEST is defined

Changes in v6:
- use 'companion-hub' to locate the platform device, instead of
  scanning through the nodes of the parent
- added ABI documentation for 'always_powered_in_suspend'
- sysfs_emit() instead of sprintf() in always_powered_in_suspend_show()
- register sysfs attribute through driver.dev_groups
- evaluate return value of driver_attach() in _probe()
- use dev_warn() instead of WARN_ON() in _probe()
- include 'onboard_hub.h'

Changes in v5:
- the platform device is now instantiated from the same DT node
  as the 'primary' USB hub device
  - use the USB compatible strings for the platform device
  - refactored _find_onboard_hub() to search the parents child
    nodes for a platform device with a matching compatible string
  - added exported function of_is_onboard_usb_hub() to allow other
    drivers (like xhci_plat) to check if one of their child DT nodes
    is a supported hub
- use late suspend to make sure info about wakeup enabled descendants
  is updated
- call driver_attach() for the USB driver in onboard_hub_probe() to
  make sure the driver is re-attached after the device_release_driver()
  calls in onboard_hub_remove()
- renamed sysfs attribute 'power_off_in_suspend' to
  'always_powered_in_suspend'
- added sysfs symlinks between platform device and USB devices
- marked 'onboard_hub_pm_ops' as __maybe_unused
- removed 'realtek' compatible string which is not needed at this
  point
- fix log for regulator_disable() failure

Changes in v4:
- updated Kconfig documentation
- changed the loop in onboard_hub_remove() to release the hub lock
  before unbinding the USB device and make self deadlock prevention
  less clunky
- fixed return value in onboard_hub_usbdev_probe()
- added entry to MAINTAINERS file

Changes in v3:
- updated the commit message
- updated description in Kconfig
- remove include of 'core/usb.h'
- use 'is_powered_on' flag instead of 'has_wakeup_capable_descendants'
- added 'going_away' flag to struct onboard_hub
  - don't allow adding new USB devices when the platform device is going away
  - don't bother with deleting the list item in onboard_hub_remove_usbdev()
    when the platform device is going away
- don't assume in onboard_hub_suspend() that all USB hub devices are
  connected to the same controller
- removed unnecessary devm_kfree() from onboard_hub_remove_usbdev()
- fixed error handling in onboard_hub_remove_usbdev()
- use kstrtobool() instead of strtobool() in power_off_in_suspend_store()
- unbind USB devices in onboard_hub_remove() to avoid dangling references
  to the platform device
- moved put_device() for platform device to _find_onboard_hub()
- changed return value of onboard_hub_remove_usbdev() to void
- evaluate return value of onboard_hub_add_usbdev()
- register 'power_off_in_suspend' as managed device attribute
- use USB_DEVICE macro instead manual initialization
- add unwinding to onboard_hub_init()
- updated MODULE_DESCRIPTION
- use module_init() instead of device_initcall()

Changes in v2:
- check wakeup enabled state of the USB controller instead of
  using 'wakeup-source' property
- use sysfs attribute instead of DT property to determine if
  the hub should be powered off at all during system suspend
- added missing brace in onboard_hub_suspend()
- updated commit message
- use pm_ptr for pm_ops as suggested by Alan

Changes in v1:
- renamed the driver to 'onboard_usb_hub'
- single file for platform and USB driver
- USB hub devices register with the platform device
  - the DT includes a phandle of the platform device
- the platform device now controls when power is turned off
- the USB driver became a very thin subclass of the generic USB
  driver
- enabled autosuspend support

 .../sysfs-bus-platform-onboard-usb-hub        |   8 +
 MAINTAINERS                                   |   7 +
 drivers/usb/core/Makefile                     |   1 +
 drivers/usb/misc/Kconfig                      |  23 +
 drivers/usb/misc/Makefile                     |   1 +
 drivers/usb/misc/onboard_usb_hub.c            | 426 ++++++++++++++++++
 drivers/usb/misc/onboard_usb_hub.h            |  17 +
 drivers/usb/misc/onboard_usb_hub_pdevs.c      | 129 ++++++
 include/linux/usb/onboard_hub.h               |  18 +
 9 files changed, 630 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 drivers/usb/misc/onboard_usb_hub.h
 create mode 100644 drivers/usb/misc/onboard_usb_hub_pdevs.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..42deb0552065
--- /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:		June 2022
+KernelVersion:	5.20
+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 a6d3bd9d2a8d..caeef7e111c3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14784,6 +14784,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/ABI/testing/sysfs-bus-platform-onboard-usb-hub
+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/core/Makefile b/drivers/usb/core/Makefile
index 18e874b0441e..0ce219f5a343 100644
--- a/drivers/usb/core/Makefile
+++ b/drivers/usb/core/Makefile
@@ -11,6 +11,7 @@ usbcore-y += phy.o port.o
 usbcore-$(CONFIG_OF)		+= of.o
 usbcore-$(CONFIG_USB_PCI)		+= hcd-pci.o
 usbcore-$(CONFIG_ACPI)		+= usb-acpi.o
+usbcore-$(CONFIG_USB_ONBOARD_HUB)	+= ../misc/onboard_usb_hub_pdevs.o
 
 obj-$(CONFIG_USB)		+= usbcore.o
 
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 4c5ddbd75b7e..993d07d2ffe5 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -295,3 +295,26 @@ 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
+	bool "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 non-trivial form of initialization, such as enabling a
+	  power regulator. An example for such a hub is the Realtek
+	  RTS5411.
+
+	  This driver can be used as a module but its state (module vs
+	  builtin) must match the state of the USB subsystem. Enabling
+	  this config will enable the driver and it will automatically
+	  match the state of the USB subsystem. If this driver is a
+	  module it will be called onboard_usb_hub.
+
+if USB_ONBOARD_HUB
+config USB_ONBOARD_HUB_ACTUAL
+	tristate
+	default m if USB=m
+	default y if USB=y
+endif
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index 35bdb4b6c3b6..ea65e202a055 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -33,3 +33,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_ACTUAL)	+= 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..21655b9ff559
--- /dev/null
+++ b/drivers/usb/misc/onboard_usb_hub.c
@@ -0,0 +1,426 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Driver for onboard USB hubs
+ *
+ * Copyright (c) 2022, Google LLC
+ */
+
+#include <linux/device.h>
+#include <linux/export.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/slab.h>
+#include <linux/suspend.h>
+#include <linux/sysfs.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+#include <linux/usb/onboard_hub.h>
+#include <linux/workqueue.h>
+
+#include "onboard_usb_hub.h"
+
+static struct usb_device_driver onboard_hub_usbdev_driver;
+
+/************************** Platform driver **************************/
+
+struct usbdev_node {
+	struct usb_device *udev;
+	struct list_head list;
+};
+
+struct onboard_hub {
+	struct regulator *vdd;
+	struct device *dev;
+	bool always_powered_in_suspend;
+	bool is_powered_on;
+	bool going_away;
+	struct list_head udev_list;
+	struct work_struct attach_usb_driver_work;
+	struct mutex lock;
+};
+
+static int onboard_hub_power_on(struct onboard_hub *hub)
+{
+	int err;
+
+	err = regulator_enable(hub->vdd);
+	if (err) {
+		dev_err(hub->dev, "failed to enable regulator: %d\n", err);
+		return err;
+	}
+
+	hub->is_powered_on = true;
+
+	return 0;
+}
+
+static int onboard_hub_power_off(struct onboard_hub *hub)
+{
+	int err;
+
+	err = regulator_disable(hub->vdd);
+	if (err) {
+		dev_err(hub->dev, "failed to disable regulator: %d\n", err);
+		return err;
+	}
+
+	hub->is_powered_on = false;
+
+	return 0;
+}
+
+static int __maybe_unused onboard_hub_suspend(struct device *dev)
+{
+	struct onboard_hub *hub = dev_get_drvdata(dev);
+	struct usbdev_node *node;
+	bool power_off = true;
+
+	if (hub->always_powered_in_suspend)
+		return 0;
+
+	mutex_lock(&hub->lock);
+
+	list_for_each_entry(node, &hub->udev_list, list) {
+		if (!device_may_wakeup(node->udev->bus->controller))
+			continue;
+
+		if (usb_wakeup_enabled_descendants(node->udev)) {
+			power_off = false;
+			break;
+		}
+	}
+
+	mutex_unlock(&hub->lock);
+
+	if (!power_off)
+		return 0;
+
+	return onboard_hub_power_off(hub);
+}
+
+static int __maybe_unused onboard_hub_resume(struct device *dev)
+{
+	struct onboard_hub *hub = dev_get_drvdata(dev);
+
+	if (hub->is_powered_on)
+		return 0;
+
+	return onboard_hub_power_on(hub);
+}
+
+static inline void get_udev_link_name(const struct usb_device *udev, char *buf, size_t size)
+{
+	snprintf(buf, size, "usb_dev.%s", dev_name(&udev->dev));
+}
+
+static int onboard_hub_add_usbdev(struct onboard_hub *hub, struct usb_device *udev)
+{
+	struct usbdev_node *node;
+	char link_name[64];
+	int err;
+
+	mutex_lock(&hub->lock);
+
+	if (hub->going_away) {
+		err = -EINVAL;
+		goto error;
+	}
+
+	node = kzalloc(sizeof(*node), GFP_KERNEL);
+	if (!node) {
+		err = -ENOMEM;
+		goto error;
+	}
+
+	node->udev = udev;
+
+	list_add(&node->list, &hub->udev_list);
+
+	mutex_unlock(&hub->lock);
+
+	get_udev_link_name(udev, link_name, sizeof(link_name));
+	WARN_ON(sysfs_create_link(&hub->dev->kobj, &udev->dev.kobj, link_name));
+
+	return 0;
+
+error:
+	mutex_unlock(&hub->lock);
+
+	return err;
+}
+
+static void onboard_hub_remove_usbdev(struct onboard_hub *hub, const struct usb_device *udev)
+{
+	struct usbdev_node *node;
+	char link_name[64];
+
+	get_udev_link_name(udev, link_name, sizeof(link_name));
+	sysfs_remove_link(&hub->dev->kobj, link_name);
+
+	mutex_lock(&hub->lock);
+
+	list_for_each_entry(node, &hub->udev_list, list) {
+		if (node->udev == udev) {
+			list_del(&node->list);
+			kfree(node);
+			break;
+		}
+	}
+
+	mutex_unlock(&hub->lock);
+}
+
+static ssize_t always_powered_in_suspend_show(struct device *dev, struct device_attribute *attr,
+			   char *buf)
+{
+	const 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 void onboard_hub_attach_usb_driver(struct work_struct *work)
+{
+	int err;
+
+	err = driver_attach(&onboard_hub_usbdev_driver.drvwrap.driver);
+	if (err)
+		pr_err("Failed to attach USB driver: %d\n", err);
+}
+
+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.
+	 *
+	 * This needs to be done deferred to avoid self-deadlocks on systems
+	 * with nested onboard hubs.
+	 */
+	INIT_WORK(&hub->attach_usb_driver_work, onboard_hub_attach_usb_driver);
+	schedule_work(&hub->attach_usb_driver_work);
+
+	return 0;
+}
+
+static int onboard_hub_remove(struct platform_device *pdev)
+{
+	struct onboard_hub *hub = dev_get_drvdata(&pdev->dev);
+	struct usbdev_node *node;
+	struct usb_device *udev;
+
+	hub->going_away = true;
+
+	cancel_work_sync(&hub->attach_usb_driver_work);
+
+	mutex_lock(&hub->lock);
+
+	/* unbind the USB devices to avoid dangling references to this device */
+	while (!list_empty(&hub->udev_list)) {
+		node = list_first_entry(&hub->udev_list, struct usbdev_node, list);
+		udev = node->udev;
+
+		/*
+		 * Unbinding the driver will call onboard_hub_remove_usbdev(),
+		 * which acquires hub->lock.  We must release the lock first.
+		 */
+		get_device(&udev->dev);
+		mutex_unlock(&hub->lock);
+		device_release_driver(&udev->dev);
+		put_device(&udev->dev);
+		mutex_lock(&hub->lock);
+	}
+
+	mutex_unlock(&hub->lock);
+
+	return onboard_hub_power_off(hub);
+}
+
+MODULE_DEVICE_TABLE(of, onboard_hub_match);
+
+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;
+	struct onboard_hub *hub;
+
+	pdev = of_find_device_by_node(dev->of_node);
+	if (!pdev) {
+		np = of_parse_phandle(dev->of_node, "companion-hub", 0);
+		if (!np) {
+			dev_err(dev, "failed to find device node for companion hub\n");
+			return ERR_PTR(-EINVAL);
+		}
+
+		pdev = of_find_device_by_node(np);
+		of_node_put(np);
+
+		if (!pdev)
+			return ERR_PTR(-ENODEV);
+	}
+
+	hub = dev_get_drvdata(&pdev->dev);
+	put_device(&pdev->dev);
+
+	/*
+	 * The presence of drvdata ('hub') indicates that the platform driver
+	 * finished probing. This handles the case where (conceivably) we could
+	 * be running at the exact same time as the platform driver's probe. If
+	 * we detect the race we request probe deferral and we'll come back and
+	 * try again.
+	 */
+	if (!hub)
+		return ERR_PTR(-EPROBE_DEFER);
+
+	return hub;
+}
+
+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;
+
+	return 0;
+}
+
+static void onboard_hub_usbdev_disconnect(struct usb_device *udev)
+{
+	struct onboard_hub *hub = dev_get_drvdata(&udev->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.1 */
+	{ USB_DEVICE(VENDOR_ID_REALTEK, 0x5411) }, /* RTS5411 USB 2.1 */
+	{ USB_DEVICE(VENDOR_ID_REALTEK, 0x0414) }, /* RTS5414 USB 3.2 */
+	{ USB_DEVICE(VENDOR_ID_REALTEK, 0x5414) }, /* RTS5414 USB 2.1 */
+	{}
+};
+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,
+};
+
+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/drivers/usb/misc/onboard_usb_hub.h b/drivers/usb/misc/onboard_usb_hub.h
new file mode 100644
index 000000000000..d3a5b6938582
--- /dev/null
+++ b/drivers/usb/misc/onboard_usb_hub.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2022, Google LLC
+ */
+
+#ifndef _USB_MISC_ONBOARD_USB_HUB_H
+#define _USB_MISC_ONBOARD_USB_HUB_H
+
+static const struct of_device_id onboard_hub_match[] = {
+	{ .compatible = "usbbda,411" },
+	{ .compatible = "usbbda,5411" },
+	{ .compatible = "usbbda,414" },
+	{ .compatible = "usbbda,5414" },
+	{}
+};
+
+#endif /* _USB_MISC_ONBOARD_USB_HUB_H */
diff --git a/drivers/usb/misc/onboard_usb_hub_pdevs.c b/drivers/usb/misc/onboard_usb_hub_pdevs.c
new file mode 100644
index 000000000000..8f38cca9e530
--- /dev/null
+++ b/drivers/usb/misc/onboard_usb_hub_pdevs.c
@@ -0,0 +1,129 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * API for creating and destroying USB onboard hub platform devices
+ *
+ * Copyright (c) 2022, Google LLC
+ */
+
+#include <linux/device.h>
+#include <linux/export.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+#include <linux/usb/of.h>
+
+#include "onboard_usb_hub.h"
+
+struct pdev_list_entry {
+	struct platform_device *pdev;
+	struct list_head node;
+};
+
+static bool of_is_onboard_usb_hub(const struct device_node *np)
+{
+	return !!of_match_node(onboard_hub_match, np);
+}
+
+/**
+ * onboard_hub_create_pdevs -- create platform devices for onboard USB hubs
+ * @parent_hub	: parent hub to scan for connected onboard hubs
+ * @pdev_list	: list of onboard hub platform devices owned by the parent hub
+ *
+ * Creates a platform device for each supported onboard hub that is connected to
+ * the given parent hub. To keep track of the platform devices they are added to
+ * a list that is owned by the parent hub.
+ */
+void onboard_hub_create_pdevs(struct usb_device *parent_hub, struct list_head *pdev_list)
+{
+	int i;
+	struct usb_hcd *hcd = bus_to_hcd(parent_hub->bus);
+	struct device_node *np, *npc;
+	struct platform_device *pdev = NULL;
+	struct pdev_list_entry *pdle;
+
+	if (!parent_hub->dev.of_node)
+		return;
+
+	for (i = 1; i <= parent_hub->maxchild; i++) {
+		np = usb_of_get_device_node(parent_hub, i);
+		if (!np)
+			continue;
+
+		if (!of_is_onboard_usb_hub(np))
+			goto node_put;
+
+		npc = of_parse_phandle(np, "companion-hub", 0);
+		if (npc) {
+			/*
+			 * Hubs with companions share the same platform device.
+			 * Create the plaform device only for the hub that is
+			 * connected to the primary HCD (directly or through
+			 * other hubs).
+			 */
+			if (!usb_hcd_is_primary_hcd(hcd)) {
+				of_node_put(npc);
+				goto node_put;
+			}
+
+			pdev = of_find_device_by_node(npc);
+			of_node_put(npc);
+		} else {
+			/*
+			 * For root hubs this function can be called multiple times
+			 * for the same root hub node (the HCD node). Make sure only
+			 * one platform device is created for this hub.
+			 */
+			if (!parent_hub->parent && !usb_hcd_is_primary_hcd(hcd))
+				goto node_put;
+		}
+
+		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) {
+			dev_err(&parent_hub->dev,
+				"failed to create platform device for onboard hub '%pOF'\n", np);
+			goto node_put;
+		}
+
+		pdle = kzalloc(sizeof(*pdle), GFP_KERNEL);
+		if (!pdle) {
+			of_platform_device_destroy(&pdev->dev, NULL);
+			goto node_put;
+		}
+
+		pdle->pdev = pdev;
+		list_add(&pdle->node, pdev_list);
+
+node_put:
+		of_node_put(np);
+	}
+}
+EXPORT_SYMBOL_GPL(onboard_hub_create_pdevs);
+
+/**
+ * onboard_hub_destroy_pdevs -- free resources of onboard hub platform devices
+ * @pdev_list	: list of onboard hub platform devices
+ *
+ * Destroys the platform devices in the given list and frees the memory associated
+ * with the list entry.
+ */
+void onboard_hub_destroy_pdevs(struct list_head *pdev_list)
+{
+	struct pdev_list_entry *pdle, *tmp;
+
+	list_for_each_entry_safe(pdle, tmp, pdev_list, node) {
+		list_del(&pdle->node);
+		of_platform_device_destroy(&pdle->pdev->dev, NULL);
+		kfree(pdle);
+	}
+}
+EXPORT_SYMBOL_GPL(onboard_hub_destroy_pdevs);
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.36.1.476.g0c4daa206d-goog

[PATCH v22 3/3] usb: core: hub: Create platform devices for onboard hubs in hub_probe()

[Matthias Kaehlcke]

Call onboard_hub_create/destroy_pdevs() from hub_probe/disconnect()
to create/destroy platform devices for onboard USB hubs that may be
connected to the hub. The onboard hubs must have nodes in the
device tree.

onboard_hub_create/destroy_pdevs() are NOPs unless
CONFIG_USB_ONBOARD_HUB=y/m.

Also add a field to struct usb_hub to keep track of the onboard hub
platform devices that are owned by the hub.

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

Changes in v22:
- patch added to the series (moved creation/deletion from HCD)

 drivers/usb/core/hub.c | 9 ++++++++-
 drivers/usb/core/hub.h | 1 +
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 68e9121c1878..8055130ee602 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -23,6 +23,7 @@
 #include <linux/usb.h>
 #include <linux/usbdevice_fs.h>
 #include <linux/usb/hcd.h>
+#include <linux/usb/onboard_hub.h>
 #include <linux/usb/otg.h>
 #include <linux/usb/quirks.h>
 #include <linux/workqueue.h>
@@ -1752,6 +1753,8 @@ static void hub_disconnect(struct usb_interface *intf)
 	if (hub->quirk_disable_autosuspend)
 		usb_autopm_put_interface(intf);
 
+	onboard_hub_destroy_pdevs(&hub->onboard_hub_devs);
+
 	kref_put(&hub->kref, hub_release);
 }
 
@@ -1869,6 +1872,7 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id)
 	INIT_DELAYED_WORK(&hub->leds, led_work);
 	INIT_DELAYED_WORK(&hub->init_work, NULL);
 	INIT_WORK(&hub->events, hub_event);
+	INIT_LIST_HEAD(&hub->onboard_hub_devs);
 	spin_lock_init(&hub->irq_urb_lock);
 	timer_setup(&hub->irq_urb_retry, hub_retry_irq_urb, 0);
 	usb_get_intf(intf);
@@ -1889,8 +1893,11 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id)
 		usb_autopm_get_interface_no_resume(intf);
 	}
 
-	if (hub_configure(hub, &desc->endpoint[0].desc) >= 0)
+	if (hub_configure(hub, &desc->endpoint[0].desc) >= 0) {
+		onboard_hub_create_pdevs(hdev, &hub->onboard_hub_devs);
+
 		return 0;
+	}
 
 	hub_disconnect(intf);
 	return -ENODEV;
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 22ea1f4f2d66..ccf90052d12a 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -73,6 +73,7 @@ struct usb_hub {
 	spinlock_t		irq_urb_lock;
 	struct timer_list	irq_urb_retry;
 	struct usb_port		**ports;
+	struct list_head        onboard_hub_devs;
 };
 
 /**
-- 
2.36.1.476.g0c4daa206d-goog

Re: [PATCH v22 2/3] usb: misc: Add onboard_usb_hub driver

[Doug Anderson]

Hi,

On Thu, Jun 9, 2022 at 12:20 PM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> @@ -11,6 +11,7 @@ usbcore-y += phy.o port.o
>  usbcore-$(CONFIG_OF)           += of.o
>  usbcore-$(CONFIG_USB_PCI)              += hcd-pci.o
>  usbcore-$(CONFIG_ACPI)         += usb-acpi.o
> +usbcore-$(CONFIG_USB_ONBOARD_HUB)      += ../misc/onboard_usb_hub_pdevs.o

I'm OK with this solution of just linking the code into the "usbcore"
if USB folks are. Thinking about it, I guess another way to solve the
circular dependency is to somehow create some type of generic
notification scheme where the USB hub driver subscribes to "a hub has
appeared" notification. ...but I don't personally have any intuition
about whether people would like that better than your solution.


> +config USB_ONBOARD_HUB
> +       bool "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 non-trivial form of initialization, such as enabling a
> +         power regulator. An example for such a hub is the Realtek
> +         RTS5411.
> +
> +         This driver can be used as a module but its state (module vs
> +         builtin) must match the state of the USB subsystem. Enabling
> +         this config will enable the driver and it will automatically
> +         match the state of the USB subsystem. If this driver is a
> +         module it will be called onboard_usb_hub.
> +
> +if USB_ONBOARD_HUB
> +config USB_ONBOARD_HUB_ACTUAL
> +       tristate
> +       default m if USB=m
> +       default y if USB=y
> +endif

Do you still need to play the games with "_ACTUAL"? The USB core no
longer calls the hub directly. I think that means you can just "depend
on USB" and be done with the mess. That allows USB to be builtin and
USB_ONBOARD_HUB can be a module, right?


> +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.
> +        *
> +        * This needs to be done deferred to avoid self-deadlocks on systems
> +        * with nested onboard hubs.
> +        */
> +       INIT_WORK(&hub->attach_usb_driver_work, onboard_hub_attach_usb_driver);
> +       schedule_work(&hub->attach_usb_driver_work);

I'm sure that the above is totally necessary but it's been long enough
since I looked at this code last that I've totally forgotten why. Any
chance you could add comments to say under what situation
onboard_hub_remove() would have detached the USB driver? Is this
something where you unbind the platform driver and then bind it again?
...and why does that cause the driver to be detached?


> +/**
> + * onboard_hub_create_pdevs -- create platform devices for onboard USB hubs
> + * @parent_hub : parent hub to scan for connected onboard hubs
> + * @pdev_list  : list of onboard hub platform devices owned by the parent hub
> + *
> + * 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.

I'm ashamed to admit how long it took me to remember why exactly we
needed a platform device to begin with and why the normal USB devices
weren't enough (it's because we won't enumerate the USB devices until
we're powered and so the platform device is in charge of powering
things up). Finally I re-read the commit message and then it made
sense, but someone looking at the code later might not think to look
at the commit message for a while. Maybe remind people in the comments
for this function? Even if it's somewhere else in the code and I
missed it, I wouldn't mind a tiny blurb here.


> +void onboard_hub_create_pdevs(struct usb_device *parent_hub, struct list_head *pdev_list)
> +{
> +       int i;
> +       struct usb_hcd *hcd = bus_to_hcd(parent_hub->bus);
> +       struct device_node *np, *npc;
> +       struct platform_device *pdev = NULL;
> +       struct pdev_list_entry *pdle;
> +
> +       if (!parent_hub->dev.of_node)
> +               return;
> +
> +       for (i = 1; i <= parent_hub->maxchild; i++) {
> +               np = usb_of_get_device_node(parent_hub, i);
> +               if (!np)
> +                       continue;
> +
> +               if (!of_is_onboard_usb_hub(np))
> +                       goto node_put;
> +
> +               npc = of_parse_phandle(np, "companion-hub", 0);
> +               if (npc) {
> +                       /*
> +                        * Hubs with companions share the same platform device.
> +                        * Create the plaform device only for the hub that is
> +                        * connected to the primary HCD (directly or through
> +                        * other hubs).
> +                        */
> +                       if (!usb_hcd_is_primary_hcd(hcd)) {
> +                               of_node_put(npc);
> +                               goto node_put;
> +                       }
> +
> +                       pdev = of_find_device_by_node(npc);
> +                       of_node_put(npc);
> +               } else {
> +                       /*
> +                        * For root hubs this function can be called multiple times
> +                        * for the same root hub node (the HCD node). Make sure only
> +                        * one platform device is created for this hub.
> +                        */
> +                       if (!parent_hub->parent && !usb_hcd_is_primary_hcd(hcd))
> +                               goto node_put;

I don't understand the "else" case above. What case exactly are we
handling again? This is when:
* the hub is presumably just a 2.0 hub since there is no companion.
* our parent is the root hub and the USB 2.0 hub we're looking at is
not the primary

...but that doesn't make a lot of sense to me? I must have missed something...

In general though, do we even need to look at the "companion-hub"
property? If this node matches an onboard USB hub and it's the primary
HCD then we want a platform dev. Otherwise we don't, right?

-Doug

Re: [PATCH v22 3/3] usb: core: hub: Create platform devices for onboard hubs in hub_probe()

[Doug Anderson]

Hi,

On Thu, Jun 9, 2022 at 12:20 PM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> Call onboard_hub_create/destroy_pdevs() from hub_probe/disconnect()
> to create/destroy platform devices for onboard USB hubs that may be
> connected to the hub. The onboard hubs must have nodes in the
> device tree.
>
> onboard_hub_create/destroy_pdevs() are NOPs unless
> CONFIG_USB_ONBOARD_HUB=y/m.
>
> Also add a field to struct usb_hub to keep track of the onboard hub
> platform devices that are owned by the hub.
>
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
>
> Changes in v22:
> - patch added to the series (moved creation/deletion from HCD)
>
>  drivers/usb/core/hub.c | 9 ++++++++-
>  drivers/usb/core/hub.h | 1 +
>  2 files changed, 9 insertions(+), 1 deletion(-)

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

Re: [PATCH v22 2/3] usb: misc: Add onboard_usb_hub driver

[Matthias Kaehlcke]

Hi Doug,

Thanks for the review!

On Wed, Jun 15, 2022 at 02:09:43PM -0700, Doug Anderson wrote:
> Hi,
> 
> On Thu, Jun 9, 2022 at 12:20 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> >
> > @@ -11,6 +11,7 @@ usbcore-y += phy.o port.o
> >  usbcore-$(CONFIG_OF)           += of.o
> >  usbcore-$(CONFIG_USB_PCI)              += hcd-pci.o
> >  usbcore-$(CONFIG_ACPI)         += usb-acpi.o
> > +usbcore-$(CONFIG_USB_ONBOARD_HUB)      += ../misc/onboard_usb_hub_pdevs.o
> 
> I'm OK with this solution of just linking the code into the "usbcore"
> if USB folks are. Thinking about it, I guess another way to solve the
> circular dependency is to somehow create some type of generic
> notification scheme where the USB hub driver subscribes to "a hub has
> appeared" notification. ...but I don't personally have any intuition
> about whether people would like that better than your solution.

Not sure if it would be better (if feasible). In any case it would require
the hub to be powered (to be enumerated) which is precisely what the
onboard_usb_hub driver intends to do.

> > +config USB_ONBOARD_HUB
> > +       bool "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 non-trivial form of initialization, such as enabling a
> > +         power regulator. An example for such a hub is the Realtek
> > +         RTS5411.
> > +
> > +         This driver can be used as a module but its state (module vs
> > +         builtin) must match the state of the USB subsystem. Enabling
> > +         this config will enable the driver and it will automatically
> > +         match the state of the USB subsystem. If this driver is a
> > +         module it will be called onboard_usb_hub.
> > +
> > +if USB_ONBOARD_HUB
> > +config USB_ONBOARD_HUB_ACTUAL
> > +       tristate
> > +       default m if USB=m
> > +       default y if USB=y
> > +endif
> 
> Do you still need to play the games with "_ACTUAL"? The USB core no
> longer calls the hub directly. I think that means you can just "depend
> on USB" and be done with the mess. That allows USB to be builtin and
> USB_ONBOARD_HUB can be a module, right?

Good point, with the pdev creation inside the USB core it shouldn't be
needed anymore.

> > +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.
> > +        *
> > +        * This needs to be done deferred to avoid self-deadlocks on systems
> > +        * with nested onboard hubs.
> > +        */
> > +       INIT_WORK(&hub->attach_usb_driver_work, onboard_hub_attach_usb_driver);
> > +       schedule_work(&hub->attach_usb_driver_work);
> 
> I'm sure that the above is totally necessary but it's been long enough
> since I looked at this code last that I've totally forgotten why. Any
> chance you could add comments to say under what situation
> onboard_hub_remove() would have detached the USB driver? Is this
> something where you unbind the platform driver and then bind it again?

Yes, that's the scenario in which I encountered that the hub USB
devices wouldn't be bound to the onboard_hub_driver again.

> ...and why does that cause the driver to be detached?

We call device_release_driver(udev) in onboard_hub_remove() to
make sure the USB devices don't keep a reference to the platform
device after it is removed.

> > +/**
> > + * onboard_hub_create_pdevs -- create platform devices for onboard USB hubs
> > + * @parent_hub : parent hub to scan for connected onboard hubs
> > + * @pdev_list  : list of onboard hub platform devices owned by the parent hub
> > + *
> > + * 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.
> 
> I'm ashamed to admit how long it took me to remember why exactly we
> needed a platform device to begin with and why the normal USB devices
> weren't enough (it's because we won't enumerate the USB devices until
> we're powered and so the platform device is in charge of powering
> things up). Finally I re-read the commit message and then it made
> sense, but someone looking at the code later might not think to look
> at the commit message for a while. Maybe remind people in the comments
> for this function? Even if it's somewhere else in the code and I
> missed it, I wouldn't mind a tiny blurb here.

Ok, I can add a short note.

> > +void onboard_hub_create_pdevs(struct usb_device *parent_hub, struct list_head *pdev_list)
> > +{
> > +       int i;
> > +       struct usb_hcd *hcd = bus_to_hcd(parent_hub->bus);
> > +       struct device_node *np, *npc;
> > +       struct platform_device *pdev = NULL;
> > +       struct pdev_list_entry *pdle;
> > +
> > +       if (!parent_hub->dev.of_node)
> > +               return;
> > +
> > +       for (i = 1; i <= parent_hub->maxchild; i++) {
> > +               np = usb_of_get_device_node(parent_hub, i);
> > +               if (!np)
> > +                       continue;
> > +
> > +               if (!of_is_onboard_usb_hub(np))
> > +                       goto node_put;
> > +
> > +               npc = of_parse_phandle(np, "companion-hub", 0);
> > +               if (npc) {
> > +                       /*
> > +                        * Hubs with companions share the same platform device.
> > +                        * Create the plaform device only for the hub that is
> > +                        * connected to the primary HCD (directly or through
> > +                        * other hubs).
> > +                        */
> > +                       if (!usb_hcd_is_primary_hcd(hcd)) {
> > +                               of_node_put(npc);
> > +                               goto node_put;
> > +                       }
> > +
> > +                       pdev = of_find_device_by_node(npc);
> > +                       of_node_put(npc);
> > +               } else {
> > +                       /*
> > +                        * For root hubs this function can be called multiple times
> > +                        * for the same root hub node (the HCD node). Make sure only
> > +                        * one platform device is created for this hub.
> > +                        */
> > +                       if (!parent_hub->parent && !usb_hcd_is_primary_hcd(hcd))
> > +                               goto node_put;
> 
> I don't understand the "else" case above. What case exactly are we
> handling again? This is when:
> * the hub is presumably just a 2.0 hub since there is no companion.
> * our parent is the root hub and the USB 2.0 hub we're looking at is
> not the primary

The 'else' case can be entered for hubs connected to a root hub or to another
hub further down in the tree, but we bail out only for first level hubs.

> ...but that doesn't make a lot of sense to me? I must have missed something...

It's not super-obvious, this bit is important: "this function can be called
multiple times for the same root hub node". For any first level hub we only
create a pdev if this function is called on behalf of the primary HCD. That
is also true of a hub connected to the secondary HCD. We only want to create
one pdev and there is supposedly always a primary HCD.

Maybe it would be slightly clearer if the function returned before the loop
if this condition is met. Unfortunately we can't just always ignore the
secondary HCD because:

> In general though, do we even need to look at the "companion-hub"
> property? If this node matches an onboard USB hub and it's the primary
> HCD then we want a platform dev. Otherwise we don't, right?

This wouldn't work for some topologies like:

3.x root hub
  <nothing connected>

2.x root hub
  2.x-only hub

no platform device would be created for the 2.x-only hub since it isn't
connected to the primary HCD

or

3.x root hub
  3.x hub

2.x root hub
  2.x hub
    2.x-only hub

The first level hub would have a platform device for being a companion hub
of the 3.x hub, however no pdev would be created for the second level hub
since the 2.x root hub isn't primary.

Re: [PATCH v22 2/3] usb: misc: Add onboard_usb_hub driver

[Doug Anderson]

Hi,

On Wed, Jun 15, 2022 at 4:22 PM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> > > +void onboard_hub_create_pdevs(struct usb_device *parent_hub, struct list_head *pdev_list)
> > > +{
> > > +       int i;
> > > +       struct usb_hcd *hcd = bus_to_hcd(parent_hub->bus);
> > > +       struct device_node *np, *npc;
> > > +       struct platform_device *pdev = NULL;
> > > +       struct pdev_list_entry *pdle;
> > > +
> > > +       if (!parent_hub->dev.of_node)
> > > +               return;
> > > +
> > > +       for (i = 1; i <= parent_hub->maxchild; i++) {
> > > +               np = usb_of_get_device_node(parent_hub, i);
> > > +               if (!np)
> > > +                       continue;
> > > +
> > > +               if (!of_is_onboard_usb_hub(np))
> > > +                       goto node_put;
> > > +
> > > +               npc = of_parse_phandle(np, "companion-hub", 0);
> > > +               if (npc) {
> > > +                       /*
> > > +                        * Hubs with companions share the same platform device.
> > > +                        * Create the plaform device only for the hub that is
> > > +                        * connected to the primary HCD (directly or through
> > > +                        * other hubs).
> > > +                        */
> > > +                       if (!usb_hcd_is_primary_hcd(hcd)) {
> > > +                               of_node_put(npc);
> > > +                               goto node_put;
> > > +                       }
> > > +
> > > +                       pdev = of_find_device_by_node(npc);
> > > +                       of_node_put(npc);
> > > +               } else {
> > > +                       /*
> > > +                        * For root hubs this function can be called multiple times
> > > +                        * for the same root hub node (the HCD node). Make sure only
> > > +                        * one platform device is created for this hub.
> > > +                        */
> > > +                       if (!parent_hub->parent && !usb_hcd_is_primary_hcd(hcd))
> > > +                               goto node_put;
> >
> > I don't understand the "else" case above. What case exactly are we
> > handling again? This is when:
> > * the hub is presumably just a 2.0 hub since there is no companion.
> > * our parent is the root hub and the USB 2.0 hub we're looking at is
> > not the primary
>
> The 'else' case can be entered for hubs connected to a root hub or to another
> hub further down in the tree, but we bail out only for first level hubs.
>
> > ...but that doesn't make a lot of sense to me? I must have missed something...
>
> It's not super-obvious, this bit is important: "this function can be called
> multiple times for the same root hub node". For any first level hub we only
> create a pdev if this function is called on behalf of the primary HCD. That
> is also true of a hub connected to the secondary HCD. We only want to create
> one pdev and there is supposedly always a primary HCD.
>
> Maybe it would be slightly clearer if the function returned before the loop
> if this condition is met.

I guess I'm still pretty confused. You say "For root hubs this
function can be called multiple times for the same root hub node".
Does that mean that the function will be called multiple times with
the same "parent_hub", or something else.

Unless it's called with the same "parent_hub" then it seems like if
the USB device has a device tree node and that device tree node is for
a onboard_usb_hub and there's no companion node then we _always_ want
to create the platform device, don't we? If it is called with the same
"parent_hub" then I'm confused how your test does something different
the first time the function is called vs. the 2nd.

-Doug

Re: [PATCH v22 2/3] usb: misc: Add onboard_usb_hub driver

[Matthias Kaehlcke]

On Thu, Jun 16, 2022 at 01:12:32PM -0700, Doug Anderson wrote:
> Hi,
> 
> On Wed, Jun 15, 2022 at 4:22 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> >
> > > > +void onboard_hub_create_pdevs(struct usb_device *parent_hub, struct list_head *pdev_list)
> > > > +{
> > > > +       int i;
> > > > +       struct usb_hcd *hcd = bus_to_hcd(parent_hub->bus);
> > > > +       struct device_node *np, *npc;
> > > > +       struct platform_device *pdev = NULL;
> > > > +       struct pdev_list_entry *pdle;
> > > > +
> > > > +       if (!parent_hub->dev.of_node)
> > > > +               return;
> > > > +
> > > > +       for (i = 1; i <= parent_hub->maxchild; i++) {
> > > > +               np = usb_of_get_device_node(parent_hub, i);
> > > > +               if (!np)
> > > > +                       continue;
> > > > +
> > > > +               if (!of_is_onboard_usb_hub(np))
> > > > +                       goto node_put;
> > > > +
> > > > +               npc = of_parse_phandle(np, "companion-hub", 0);
> > > > +               if (npc) {
> > > > +                       /*
> > > > +                        * Hubs with companions share the same platform device.
> > > > +                        * Create the plaform device only for the hub that is
> > > > +                        * connected to the primary HCD (directly or through
> > > > +                        * other hubs).
> > > > +                        */
> > > > +                       if (!usb_hcd_is_primary_hcd(hcd)) {
> > > > +                               of_node_put(npc);
> > > > +                               goto node_put;
> > > > +                       }
> > > > +
> > > > +                       pdev = of_find_device_by_node(npc);
> > > > +                       of_node_put(npc);
> > > > +               } else {
> > > > +                       /*
> > > > +                        * For root hubs this function can be called multiple times
> > > > +                        * for the same root hub node (the HCD node). Make sure only
> > > > +                        * one platform device is created for this hub.
> > > > +                        */
> > > > +                       if (!parent_hub->parent && !usb_hcd_is_primary_hcd(hcd))
> > > > +                               goto node_put;
> > >
> > > I don't understand the "else" case above. What case exactly are we
> > > handling again? This is when:
> > > * the hub is presumably just a 2.0 hub since there is no companion.
> > > * our parent is the root hub and the USB 2.0 hub we're looking at is
> > > not the primary
> >
> > The 'else' case can be entered for hubs connected to a root hub or to another
> > hub further down in the tree, but we bail out only for first level hubs.
> >
> > > ...but that doesn't make a lot of sense to me? I must have missed something...
> >
> > It's not super-obvious, this bit is important: "this function can be called
> > multiple times for the same root hub node". For any first level hub we only
> > create a pdev if this function is called on behalf of the primary HCD. That
> > is also true of a hub connected to the secondary HCD. We only want to create
> > one pdev and there is supposedly always a primary HCD.
> >
> > Maybe it would be slightly clearer if the function returned before the loop
> > if this condition is met.
> 
> I guess I'm still pretty confused. You say "For root hubs this
> function can be called multiple times for the same root hub node".
> Does that mean that the function will be called multiple times with
> the same "parent_hub", or something else.

It is called with a different "parent_hub", however for root hubs the
DT node is the same for both root hubs (it's the DT node of the
controller since there are no dedicated nodes for the root hubs).

Just to make sure this isn't the source of the confusion: the root hubs
are part of the USB controller, not 'external' hubs which are directly
connected to the controller. I call the latter 'first level hubs'.

> Unless it's called with the same "parent_hub" then it seems like if
> the USB device has a device tree node and that device tree node is for
> a onboard_usb_hub and there's no companion node then we _always_ want
> to create the platform device, don't we? If it is called with the same
> "parent_hub" then I'm confused how your test does something different
> the first time the function is called vs. the 2nd.

Let's use an adapted trogdor DT with only a USB 2.x hub as an example:

usb_1_dwc3 {
         dr_mode = "host";
	 #address-cells = <1>;
	 #size-cells = <0>;

	 /* 2.x hub on port 1 */
	 usb_hub_2_x: hub@1 {
	         compatible = "usbbda,5411";
	         reg = <1>;
	         vdd-supply = <&pp3300_hub>;
	 };
};

1st call: the 'parent_hub' corresponds to the USB 3.x root hub of
usb_1_dwc3, the DT node of the hub is 'usb_1_dwc3'. The function
iterates over the ports, finds usb_hub_2_x, enters the else branch
(no companion hub), checks that the function was called on behalf
of the primary controller and creates the pdev.

2nd call: the 'parent_hub' corresponds to the USB 2.x root hub of
usb_1_dwc3, the DT node of the hub is also 'usb_1_dwc3'. The function
iterates over the ports, finds usb_hub_2_x, enters the else branch
(no companion hub), sees that it is not called on behalf of the
primary controller and does not create a second (unnecessary) pdev.

Is it clearer now?

Re: [PATCH v22 2/3] usb: misc: Add onboard_usb_hub driver

[Doug Anderson]

Hi,

On Thu, Jun 16, 2022 at 2:08 PM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> On Thu, Jun 16, 2022 at 01:12:32PM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Wed, Jun 15, 2022 at 4:22 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> > >
> > > > > +void onboard_hub_create_pdevs(struct usb_device *parent_hub, struct list_head *pdev_list)
> > > > > +{
> > > > > +       int i;
> > > > > +       struct usb_hcd *hcd = bus_to_hcd(parent_hub->bus);
> > > > > +       struct device_node *np, *npc;
> > > > > +       struct platform_device *pdev = NULL;
> > > > > +       struct pdev_list_entry *pdle;
> > > > > +
> > > > > +       if (!parent_hub->dev.of_node)
> > > > > +               return;
> > > > > +
> > > > > +       for (i = 1; i <= parent_hub->maxchild; i++) {
> > > > > +               np = usb_of_get_device_node(parent_hub, i);
> > > > > +               if (!np)
> > > > > +                       continue;
> > > > > +
> > > > > +               if (!of_is_onboard_usb_hub(np))
> > > > > +                       goto node_put;
> > > > > +
> > > > > +               npc = of_parse_phandle(np, "companion-hub", 0);
> > > > > +               if (npc) {
> > > > > +                       /*
> > > > > +                        * Hubs with companions share the same platform device.
> > > > > +                        * Create the plaform device only for the hub that is
> > > > > +                        * connected to the primary HCD (directly or through
> > > > > +                        * other hubs).
> > > > > +                        */
> > > > > +                       if (!usb_hcd_is_primary_hcd(hcd)) {
> > > > > +                               of_node_put(npc);
> > > > > +                               goto node_put;
> > > > > +                       }
> > > > > +
> > > > > +                       pdev = of_find_device_by_node(npc);
> > > > > +                       of_node_put(npc);
> > > > > +               } else {
> > > > > +                       /*
> > > > > +                        * For root hubs this function can be called multiple times
> > > > > +                        * for the same root hub node (the HCD node). Make sure only
> > > > > +                        * one platform device is created for this hub.
> > > > > +                        */
> > > > > +                       if (!parent_hub->parent && !usb_hcd_is_primary_hcd(hcd))
> > > > > +                               goto node_put;
> > > >
> > > > I don't understand the "else" case above. What case exactly are we
> > > > handling again? This is when:
> > > > * the hub is presumably just a 2.0 hub since there is no companion.
> > > > * our parent is the root hub and the USB 2.0 hub we're looking at is
> > > > not the primary
> > >
> > > The 'else' case can be entered for hubs connected to a root hub or to another
> > > hub further down in the tree, but we bail out only for first level hubs.
> > >
> > > > ...but that doesn't make a lot of sense to me? I must have missed something...
> > >
> > > It's not super-obvious, this bit is important: "this function can be called
> > > multiple times for the same root hub node". For any first level hub we only
> > > create a pdev if this function is called on behalf of the primary HCD. That
> > > is also true of a hub connected to the secondary HCD. We only want to create
> > > one pdev and there is supposedly always a primary HCD.
> > >
> > > Maybe it would be slightly clearer if the function returned before the loop
> > > if this condition is met.
> >
> > I guess I'm still pretty confused. You say "For root hubs this
> > function can be called multiple times for the same root hub node".
> > Does that mean that the function will be called multiple times with
> > the same "parent_hub", or something else.
>
> It is called with a different "parent_hub", however for root hubs the
> DT node is the same for both root hubs (it's the DT node of the
> controller since there are no dedicated nodes for the root hubs).
>
> Just to make sure this isn't the source of the confusion: the root hubs
> are part of the USB controller, not 'external' hubs which are directly
> connected to the controller. I call the latter 'first level hubs'.
>
> > Unless it's called with the same "parent_hub" then it seems like if
> > the USB device has a device tree node and that device tree node is for
> > a onboard_usb_hub and there's no companion node then we _always_ want
> > to create the platform device, don't we? If it is called with the same
> > "parent_hub" then I'm confused how your test does something different
> > the first time the function is called vs. the 2nd.
>
> Let's use an adapted trogdor DT with only a USB 2.x hub as an example:
>
> usb_1_dwc3 {
>          dr_mode = "host";
>          #address-cells = <1>;
>          #size-cells = <0>;
>
>          /* 2.x hub on port 1 */
>          usb_hub_2_x: hub@1 {
>                  compatible = "usbbda,5411";
>                  reg = <1>;
>                  vdd-supply = <&pp3300_hub>;
>          };
> };
>
> 1st call: the 'parent_hub' corresponds to the USB 3.x root hub of
> usb_1_dwc3, the DT node of the hub is 'usb_1_dwc3'. The function
> iterates over the ports, finds usb_hub_2_x, enters the else branch
> (no companion hub), checks that the function was called on behalf
> of the primary controller and creates the pdev.
>
> 2nd call: the 'parent_hub' corresponds to the USB 2.x root hub of
> usb_1_dwc3, the DT node of the hub is also 'usb_1_dwc3'. The function
> iterates over the ports, finds usb_hub_2_x, enters the else branch
> (no companion hub), sees that it is not called on behalf of the
> primary controller and does not create a second (unnecessary) pdev.
>
> Is it clearer now?

Ah, I get it now! Sorry for being so dense... So like this:

Root hubs (those hubs with no parent) are all created with the same
device_node, the one for the controller itself. We don't want to
iterate through the same children multiple times, so we bail right
away if we're detect that `parent_hub` is a root hub and we're not on
the primary HCD. For all other cases the primary and secondary
controllers have distinct device_nodes.

I guess in theory that test could go before the "companion-hub" test,
though I don't see any case where it truly matters...

-Doug

Re: [PATCH v22 2/3] usb: misc: Add onboard_usb_hub driver

[Matthias Kaehlcke]

On Thu, Jun 16, 2022 at 02:28:38PM -0700, Doug Anderson wrote:
> Hi,
> 
> On Thu, Jun 16, 2022 at 2:08 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> >
> > On Thu, Jun 16, 2022 at 01:12:32PM -0700, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Wed, Jun 15, 2022 at 4:22 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> > > >
> > > > > > +void onboard_hub_create_pdevs(struct usb_device *parent_hub, struct list_head *pdev_list)
> > > > > > +{
> > > > > > +       int i;
> > > > > > +       struct usb_hcd *hcd = bus_to_hcd(parent_hub->bus);
> > > > > > +       struct device_node *np, *npc;
> > > > > > +       struct platform_device *pdev = NULL;
> > > > > > +       struct pdev_list_entry *pdle;
> > > > > > +
> > > > > > +       if (!parent_hub->dev.of_node)
> > > > > > +               return;
> > > > > > +
> > > > > > +       for (i = 1; i <= parent_hub->maxchild; i++) {
> > > > > > +               np = usb_of_get_device_node(parent_hub, i);
> > > > > > +               if (!np)
> > > > > > +                       continue;
> > > > > > +
> > > > > > +               if (!of_is_onboard_usb_hub(np))
> > > > > > +                       goto node_put;
> > > > > > +
> > > > > > +               npc = of_parse_phandle(np, "companion-hub", 0);
> > > > > > +               if (npc) {
> > > > > > +                       /*
> > > > > > +                        * Hubs with companions share the same platform device.
> > > > > > +                        * Create the plaform device only for the hub that is
> > > > > > +                        * connected to the primary HCD (directly or through
> > > > > > +                        * other hubs).
> > > > > > +                        */
> > > > > > +                       if (!usb_hcd_is_primary_hcd(hcd)) {
> > > > > > +                               of_node_put(npc);
> > > > > > +                               goto node_put;
> > > > > > +                       }
> > > > > > +
> > > > > > +                       pdev = of_find_device_by_node(npc);
> > > > > > +                       of_node_put(npc);
> > > > > > +               } else {
> > > > > > +                       /*
> > > > > > +                        * For root hubs this function can be called multiple times
> > > > > > +                        * for the same root hub node (the HCD node). Make sure only
> > > > > > +                        * one platform device is created for this hub.
> > > > > > +                        */
> > > > > > +                       if (!parent_hub->parent && !usb_hcd_is_primary_hcd(hcd))
> > > > > > +                               goto node_put;
> > > > >
> > > > > I don't understand the "else" case above. What case exactly are we
> > > > > handling again? This is when:
> > > > > * the hub is presumably just a 2.0 hub since there is no companion.
> > > > > * our parent is the root hub and the USB 2.0 hub we're looking at is
> > > > > not the primary
> > > >
> > > > The 'else' case can be entered for hubs connected to a root hub or to another
> > > > hub further down in the tree, but we bail out only for first level hubs.
> > > >
> > > > > ...but that doesn't make a lot of sense to me? I must have missed something...
> > > >
> > > > It's not super-obvious, this bit is important: "this function can be called
> > > > multiple times for the same root hub node". For any first level hub we only
> > > > create a pdev if this function is called on behalf of the primary HCD. That
> > > > is also true of a hub connected to the secondary HCD. We only want to create
> > > > one pdev and there is supposedly always a primary HCD.
> > > >
> > > > Maybe it would be slightly clearer if the function returned before the loop
> > > > if this condition is met.
> > >
> > > I guess I'm still pretty confused. You say "For root hubs this
> > > function can be called multiple times for the same root hub node".
> > > Does that mean that the function will be called multiple times with
> > > the same "parent_hub", or something else.
> >
> > It is called with a different "parent_hub", however for root hubs the
> > DT node is the same for both root hubs (it's the DT node of the
> > controller since there are no dedicated nodes for the root hubs).
> >
> > Just to make sure this isn't the source of the confusion: the root hubs
> > are part of the USB controller, not 'external' hubs which are directly
> > connected to the controller. I call the latter 'first level hubs'.
> >
> > > Unless it's called with the same "parent_hub" then it seems like if
> > > the USB device has a device tree node and that device tree node is for
> > > a onboard_usb_hub and there's no companion node then we _always_ want
> > > to create the platform device, don't we? If it is called with the same
> > > "parent_hub" then I'm confused how your test does something different
> > > the first time the function is called vs. the 2nd.
> >
> > Let's use an adapted trogdor DT with only a USB 2.x hub as an example:
> >
> > usb_1_dwc3 {
> >          dr_mode = "host";
> >          #address-cells = <1>;
> >          #size-cells = <0>;
> >
> >          /* 2.x hub on port 1 */
> >          usb_hub_2_x: hub@1 {
> >                  compatible = "usbbda,5411";
> >                  reg = <1>;
> >                  vdd-supply = <&pp3300_hub>;
> >          };
> > };
> >
> > 1st call: the 'parent_hub' corresponds to the USB 3.x root hub of
> > usb_1_dwc3, the DT node of the hub is 'usb_1_dwc3'. The function
> > iterates over the ports, finds usb_hub_2_x, enters the else branch
> > (no companion hub), checks that the function was called on behalf
> > of the primary controller and creates the pdev.
> >
> > 2nd call: the 'parent_hub' corresponds to the USB 2.x root hub of
> > usb_1_dwc3, the DT node of the hub is also 'usb_1_dwc3'. The function
> > iterates over the ports, finds usb_hub_2_x, enters the else branch
> > (no companion hub), sees that it is not called on behalf of the
> > primary controller and does not create a second (unnecessary) pdev.
> >
> > Is it clearer now?
> 
> Ah, I get it now! Sorry for being so dense...

No worries, it's certainly not obvious and probably my commentary could
have been clearer.

> So like this:
>
> Root hubs (those hubs with no parent) are all created with the same
> device_node, the one for the controller itself. We don't want to
> iterate through the same children multiple times, so we bail right
> away if we're detect that `parent_hub` is a root hub and we're not on
> the primary HCD.

yep

> For all other cases the primary and secondary controllers have distinct
> device_nodes.

You probably mean that all non-root hubs have distinct nodes, so for these
the function is only called once.

> I guess in theory that test could go before the "companion-hub" test,
> though I don't see any case where it truly matters...

Yeah, I'm still wondering whether it would be slightly less confusing to
bail before the loop (besides saving a few cycles), it would eliminate
the conflation with the 'companion-hub' check.

Re: [PATCH v22 2/3] usb: misc: Add onboard_usb_hub driver

[Doug Anderson]

Hi,

On Thu, Jun 16, 2022 at 3:01 PM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> On Thu, Jun 16, 2022 at 02:28:38PM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Jun 16, 2022 at 2:08 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> > >
> > > On Thu, Jun 16, 2022 at 01:12:32PM -0700, Doug Anderson wrote:
> > > > Hi,
> > > >
> > > > On Wed, Jun 15, 2022 at 4:22 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> > > > >
> > > > > > > +void onboard_hub_create_pdevs(struct usb_device *parent_hub, struct list_head *pdev_list)
> > > > > > > +{
> > > > > > > +       int i;
> > > > > > > +       struct usb_hcd *hcd = bus_to_hcd(parent_hub->bus);
> > > > > > > +       struct device_node *np, *npc;
> > > > > > > +       struct platform_device *pdev = NULL;
> > > > > > > +       struct pdev_list_entry *pdle;
> > > > > > > +
> > > > > > > +       if (!parent_hub->dev.of_node)
> > > > > > > +               return;
> > > > > > > +
> > > > > > > +       for (i = 1; i <= parent_hub->maxchild; i++) {
> > > > > > > +               np = usb_of_get_device_node(parent_hub, i);
> > > > > > > +               if (!np)
> > > > > > > +                       continue;
> > > > > > > +
> > > > > > > +               if (!of_is_onboard_usb_hub(np))
> > > > > > > +                       goto node_put;
> > > > > > > +
> > > > > > > +               npc = of_parse_phandle(np, "companion-hub", 0);
> > > > > > > +               if (npc) {
> > > > > > > +                       /*
> > > > > > > +                        * Hubs with companions share the same platform device.
> > > > > > > +                        * Create the plaform device only for the hub that is
> > > > > > > +                        * connected to the primary HCD (directly or through
> > > > > > > +                        * other hubs).
> > > > > > > +                        */
> > > > > > > +                       if (!usb_hcd_is_primary_hcd(hcd)) {
> > > > > > > +                               of_node_put(npc);
> > > > > > > +                               goto node_put;
> > > > > > > +                       }
> > > > > > > +
> > > > > > > +                       pdev = of_find_device_by_node(npc);
> > > > > > > +                       of_node_put(npc);
> > > > > > > +               } else {
> > > > > > > +                       /*
> > > > > > > +                        * For root hubs this function can be called multiple times
> > > > > > > +                        * for the same root hub node (the HCD node). Make sure only
> > > > > > > +                        * one platform device is created for this hub.
> > > > > > > +                        */
> > > > > > > +                       if (!parent_hub->parent && !usb_hcd_is_primary_hcd(hcd))
> > > > > > > +                               goto node_put;
> > > > > >
> > > > > > I don't understand the "else" case above. What case exactly are we
> > > > > > handling again? This is when:
> > > > > > * the hub is presumably just a 2.0 hub since there is no companion.
> > > > > > * our parent is the root hub and the USB 2.0 hub we're looking at is
> > > > > > not the primary
> > > > >
> > > > > The 'else' case can be entered for hubs connected to a root hub or to another
> > > > > hub further down in the tree, but we bail out only for first level hubs.
> > > > >
> > > > > > ...but that doesn't make a lot of sense to me? I must have missed something...
> > > > >
> > > > > It's not super-obvious, this bit is important: "this function can be called
> > > > > multiple times for the same root hub node". For any first level hub we only
> > > > > create a pdev if this function is called on behalf of the primary HCD. That
> > > > > is also true of a hub connected to the secondary HCD. We only want to create
> > > > > one pdev and there is supposedly always a primary HCD.
> > > > >
> > > > > Maybe it would be slightly clearer if the function returned before the loop
> > > > > if this condition is met.
> > > >
> > > > I guess I'm still pretty confused. You say "For root hubs this
> > > > function can be called multiple times for the same root hub node".
> > > > Does that mean that the function will be called multiple times with
> > > > the same "parent_hub", or something else.
> > >
> > > It is called with a different "parent_hub", however for root hubs the
> > > DT node is the same for both root hubs (it's the DT node of the
> > > controller since there are no dedicated nodes for the root hubs).
> > >
> > > Just to make sure this isn't the source of the confusion: the root hubs
> > > are part of the USB controller, not 'external' hubs which are directly
> > > connected to the controller. I call the latter 'first level hubs'.
> > >
> > > > Unless it's called with the same "parent_hub" then it seems like if
> > > > the USB device has a device tree node and that device tree node is for
> > > > a onboard_usb_hub and there's no companion node then we _always_ want
> > > > to create the platform device, don't we? If it is called with the same
> > > > "parent_hub" then I'm confused how your test does something different
> > > > the first time the function is called vs. the 2nd.
> > >
> > > Let's use an adapted trogdor DT with only a USB 2.x hub as an example:
> > >
> > > usb_1_dwc3 {
> > >          dr_mode = "host";
> > >          #address-cells = <1>;
> > >          #size-cells = <0>;
> > >
> > >          /* 2.x hub on port 1 */
> > >          usb_hub_2_x: hub@1 {
> > >                  compatible = "usbbda,5411";
> > >                  reg = <1>;
> > >                  vdd-supply = <&pp3300_hub>;
> > >          };
> > > };
> > >
> > > 1st call: the 'parent_hub' corresponds to the USB 3.x root hub of
> > > usb_1_dwc3, the DT node of the hub is 'usb_1_dwc3'. The function
> > > iterates over the ports, finds usb_hub_2_x, enters the else branch
> > > (no companion hub), checks that the function was called on behalf
> > > of the primary controller and creates the pdev.
> > >
> > > 2nd call: the 'parent_hub' corresponds to the USB 2.x root hub of
> > > usb_1_dwc3, the DT node of the hub is also 'usb_1_dwc3'. The function
> > > iterates over the ports, finds usb_hub_2_x, enters the else branch
> > > (no companion hub), sees that it is not called on behalf of the
> > > primary controller and does not create a second (unnecessary) pdev.
> > >
> > > Is it clearer now?
> >
> > Ah, I get it now! Sorry for being so dense...
>
> No worries, it's certainly not obvious and probably my commentary could
> have been clearer.
>
> > So like this:
> >
> > Root hubs (those hubs with no parent) are all created with the same
> > device_node, the one for the controller itself. We don't want to
> > iterate through the same children multiple times, so we bail right
> > away if we're detect that `parent_hub` is a root hub and we're not on
> > the primary HCD.
>
> yep
>
> > For all other cases the primary and secondary controllers have distinct
> > device_nodes.
>
> You probably mean that all non-root hubs have distinct nodes, so for these
> the function is only called once.
>
> > I guess in theory that test could go before the "companion-hub" test,
> > though I don't see any case where it truly matters...
>
> Yeah, I'm still wondering whether it would be slightly less confusing to
> bail before the loop (besides saving a few cycles), it would eliminate
> the conflation with the 'companion-hub' check.

I'm not sure how that would work, though? You'd essentially need two loops then?

-Doug

Re: [PATCH v22 2/3] usb: misc: Add onboard_usb_hub driver

[Matthias Kaehlcke]

On Thu, Jun 16, 2022 at 03:46:15PM -0700, Doug Anderson wrote:
> Hi,
> 
> On Thu, Jun 16, 2022 at 3:01 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> >
> > On Thu, Jun 16, 2022 at 02:28:38PM -0700, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Thu, Jun 16, 2022 at 2:08 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> > > >
> > > > On Thu, Jun 16, 2022 at 01:12:32PM -0700, Doug Anderson wrote:
> > > > > Hi,
> > > > >
> > > > > On Wed, Jun 15, 2022 at 4:22 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> > > > > >
> > > > > > > > +void onboard_hub_create_pdevs(struct usb_device *parent_hub, struct list_head *pdev_list)
> > > > > > > > +{
> > > > > > > > +       int i;
> > > > > > > > +       struct usb_hcd *hcd = bus_to_hcd(parent_hub->bus);
> > > > > > > > +       struct device_node *np, *npc;
> > > > > > > > +       struct platform_device *pdev = NULL;
> > > > > > > > +       struct pdev_list_entry *pdle;
> > > > > > > > +
> > > > > > > > +       if (!parent_hub->dev.of_node)
> > > > > > > > +               return;
> > > > > > > > +
> > > > > > > > +       for (i = 1; i <= parent_hub->maxchild; i++) {
> > > > > > > > +               np = usb_of_get_device_node(parent_hub, i);
> > > > > > > > +               if (!np)
> > > > > > > > +                       continue;
> > > > > > > > +
> > > > > > > > +               if (!of_is_onboard_usb_hub(np))
> > > > > > > > +                       goto node_put;
> > > > > > > > +
> > > > > > > > +               npc = of_parse_phandle(np, "companion-hub", 0);
> > > > > > > > +               if (npc) {
> > > > > > > > +                       /*
> > > > > > > > +                        * Hubs with companions share the same platform device.
> > > > > > > > +                        * Create the plaform device only for the hub that is
> > > > > > > > +                        * connected to the primary HCD (directly or through
> > > > > > > > +                        * other hubs).
> > > > > > > > +                        */
> > > > > > > > +                       if (!usb_hcd_is_primary_hcd(hcd)) {
> > > > > > > > +                               of_node_put(npc);
> > > > > > > > +                               goto node_put;
> > > > > > > > +                       }
> > > > > > > > +
> > > > > > > > +                       pdev = of_find_device_by_node(npc);
> > > > > > > > +                       of_node_put(npc);
> > > > > > > > +               } else {
> > > > > > > > +                       /*
> > > > > > > > +                        * For root hubs this function can be called multiple times
> > > > > > > > +                        * for the same root hub node (the HCD node). Make sure only
> > > > > > > > +                        * one platform device is created for this hub.
> > > > > > > > +                        */
> > > > > > > > +                       if (!parent_hub->parent && !usb_hcd_is_primary_hcd(hcd))
> > > > > > > > +                               goto node_put;
> > > > > > >
> > > > > > > I don't understand the "else" case above. What case exactly are we
> > > > > > > handling again? This is when:
> > > > > > > * the hub is presumably just a 2.0 hub since there is no companion.
> > > > > > > * our parent is the root hub and the USB 2.0 hub we're looking at is
> > > > > > > not the primary
> > > > > >
> > > > > > The 'else' case can be entered for hubs connected to a root hub or to another
> > > > > > hub further down in the tree, but we bail out only for first level hubs.
> > > > > >
> > > > > > > ...but that doesn't make a lot of sense to me? I must have missed something...
> > > > > >
> > > > > > It's not super-obvious, this bit is important: "this function can be called
> > > > > > multiple times for the same root hub node". For any first level hub we only
> > > > > > create a pdev if this function is called on behalf of the primary HCD. That
> > > > > > is also true of a hub connected to the secondary HCD. We only want to create
> > > > > > one pdev and there is supposedly always a primary HCD.
> > > > > >
> > > > > > Maybe it would be slightly clearer if the function returned before the loop
> > > > > > if this condition is met.
> > > > >
> > > > > I guess I'm still pretty confused. You say "For root hubs this
> > > > > function can be called multiple times for the same root hub node".
> > > > > Does that mean that the function will be called multiple times with
> > > > > the same "parent_hub", or something else.
> > > >
> > > > It is called with a different "parent_hub", however for root hubs the
> > > > DT node is the same for both root hubs (it's the DT node of the
> > > > controller since there are no dedicated nodes for the root hubs).
> > > >
> > > > Just to make sure this isn't the source of the confusion: the root hubs
> > > > are part of the USB controller, not 'external' hubs which are directly
> > > > connected to the controller. I call the latter 'first level hubs'.
> > > >
> > > > > Unless it's called with the same "parent_hub" then it seems like if
> > > > > the USB device has a device tree node and that device tree node is for
> > > > > a onboard_usb_hub and there's no companion node then we _always_ want
> > > > > to create the platform device, don't we? If it is called with the same
> > > > > "parent_hub" then I'm confused how your test does something different
> > > > > the first time the function is called vs. the 2nd.
> > > >
> > > > Let's use an adapted trogdor DT with only a USB 2.x hub as an example:
> > > >
> > > > usb_1_dwc3 {
> > > >          dr_mode = "host";
> > > >          #address-cells = <1>;
> > > >          #size-cells = <0>;
> > > >
> > > >          /* 2.x hub on port 1 */
> > > >          usb_hub_2_x: hub@1 {
> > > >                  compatible = "usbbda,5411";
> > > >                  reg = <1>;
> > > >                  vdd-supply = <&pp3300_hub>;
> > > >          };
> > > > };
> > > >
> > > > 1st call: the 'parent_hub' corresponds to the USB 3.x root hub of
> > > > usb_1_dwc3, the DT node of the hub is 'usb_1_dwc3'. The function
> > > > iterates over the ports, finds usb_hub_2_x, enters the else branch
> > > > (no companion hub), checks that the function was called on behalf
> > > > of the primary controller and creates the pdev.
> > > >
> > > > 2nd call: the 'parent_hub' corresponds to the USB 2.x root hub of
> > > > usb_1_dwc3, the DT node of the hub is also 'usb_1_dwc3'. The function
> > > > iterates over the ports, finds usb_hub_2_x, enters the else branch
> > > > (no companion hub), sees that it is not called on behalf of the
> > > > primary controller and does not create a second (unnecessary) pdev.
> > > >
> > > > Is it clearer now?
> > >
> > > Ah, I get it now! Sorry for being so dense...
> >
> > No worries, it's certainly not obvious and probably my commentary could
> > have been clearer.
> >
> > > So like this:
> > >
> > > Root hubs (those hubs with no parent) are all created with the same
> > > device_node, the one for the controller itself. We don't want to
> > > iterate through the same children multiple times, so we bail right
> > > away if we're detect that `parent_hub` is a root hub and we're not on
> > > the primary HCD.
> >
> > yep
> >
> > > For all other cases the primary and secondary controllers have distinct
> > > device_nodes.
> >
> > You probably mean that all non-root hubs have distinct nodes, so for these
> > the function is only called once.
> >
> > > I guess in theory that test could go before the "companion-hub" test,
> > > though I don't see any case where it truly matters...
> >
> > Yeah, I'm still wondering whether it would be slightly less confusing to
> > bail before the loop (besides saving a few cycles), it would eliminate
> > the conflation with the 'companion-hub' check.
> 
> I'm not sure how that would work, though? You'd essentially need two loops then?

Maybe I got myself confused, but I think the behavior would be the same as
now, without a second loop:

We never create a pdev if the parent is a root hub and the controller is the
secondary. Even for a hub with companion the pdev is only created when the call
comes from the primary controller.

Does that make sense?

Re: [PATCH v22 2/3] usb: misc: Add onboard_usb_hub driver

[Doug Anderson]

Hi,

On Thu, Jun 16, 2022 at 5:36 PM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> On Thu, Jun 16, 2022 at 03:46:15PM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Jun 16, 2022 at 3:01 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> > >
> > > On Thu, Jun 16, 2022 at 02:28:38PM -0700, Doug Anderson wrote:
> > > > Hi,
> > > >
> > > > On Thu, Jun 16, 2022 at 2:08 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> > > > >
> > > > > On Thu, Jun 16, 2022 at 01:12:32PM -0700, Doug Anderson wrote:
> > > > > > Hi,
> > > > > >
> > > > > > On Wed, Jun 15, 2022 at 4:22 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> > > > > > >
> > > > > > > > > +void onboard_hub_create_pdevs(struct usb_device *parent_hub, struct list_head *pdev_list)
> > > > > > > > > +{
> > > > > > > > > +       int i;
> > > > > > > > > +       struct usb_hcd *hcd = bus_to_hcd(parent_hub->bus);
> > > > > > > > > +       struct device_node *np, *npc;
> > > > > > > > > +       struct platform_device *pdev = NULL;
> > > > > > > > > +       struct pdev_list_entry *pdle;
> > > > > > > > > +
> > > > > > > > > +       if (!parent_hub->dev.of_node)
> > > > > > > > > +               return;
> > > > > > > > > +
> > > > > > > > > +       for (i = 1; i <= parent_hub->maxchild; i++) {
> > > > > > > > > +               np = usb_of_get_device_node(parent_hub, i);
> > > > > > > > > +               if (!np)
> > > > > > > > > +                       continue;
> > > > > > > > > +
> > > > > > > > > +               if (!of_is_onboard_usb_hub(np))
> > > > > > > > > +                       goto node_put;
> > > > > > > > > +
> > > > > > > > > +               npc = of_parse_phandle(np, "companion-hub", 0);
> > > > > > > > > +               if (npc) {
> > > > > > > > > +                       /*
> > > > > > > > > +                        * Hubs with companions share the same platform device.
> > > > > > > > > +                        * Create the plaform device only for the hub that is
> > > > > > > > > +                        * connected to the primary HCD (directly or through
> > > > > > > > > +                        * other hubs).
> > > > > > > > > +                        */
> > > > > > > > > +                       if (!usb_hcd_is_primary_hcd(hcd)) {
> > > > > > > > > +                               of_node_put(npc);
> > > > > > > > > +                               goto node_put;
> > > > > > > > > +                       }
> > > > > > > > > +
> > > > > > > > > +                       pdev = of_find_device_by_node(npc);
> > > > > > > > > +                       of_node_put(npc);
> > > > > > > > > +               } else {
> > > > > > > > > +                       /*
> > > > > > > > > +                        * For root hubs this function can be called multiple times
> > > > > > > > > +                        * for the same root hub node (the HCD node). Make sure only
> > > > > > > > > +                        * one platform device is created for this hub.
> > > > > > > > > +                        */
> > > > > > > > > +                       if (!parent_hub->parent && !usb_hcd_is_primary_hcd(hcd))
> > > > > > > > > +                               goto node_put;
> > > > > > > >
> > > > > > > > I don't understand the "else" case above. What case exactly are we
> > > > > > > > handling again? This is when:
> > > > > > > > * the hub is presumably just a 2.0 hub since there is no companion.
> > > > > > > > * our parent is the root hub and the USB 2.0 hub we're looking at is
> > > > > > > > not the primary
> > > > > > >
> > > > > > > The 'else' case can be entered for hubs connected to a root hub or to another
> > > > > > > hub further down in the tree, but we bail out only for first level hubs.
> > > > > > >
> > > > > > > > ...but that doesn't make a lot of sense to me? I must have missed something...
> > > > > > >
> > > > > > > It's not super-obvious, this bit is important: "this function can be called
> > > > > > > multiple times for the same root hub node". For any first level hub we only
> > > > > > > create a pdev if this function is called on behalf of the primary HCD. That
> > > > > > > is also true of a hub connected to the secondary HCD. We only want to create
> > > > > > > one pdev and there is supposedly always a primary HCD.
> > > > > > >
> > > > > > > Maybe it would be slightly clearer if the function returned before the loop
> > > > > > > if this condition is met.
> > > > > >
> > > > > > I guess I'm still pretty confused. You say "For root hubs this
> > > > > > function can be called multiple times for the same root hub node".
> > > > > > Does that mean that the function will be called multiple times with
> > > > > > the same "parent_hub", or something else.
> > > > >
> > > > > It is called with a different "parent_hub", however for root hubs the
> > > > > DT node is the same for both root hubs (it's the DT node of the
> > > > > controller since there are no dedicated nodes for the root hubs).
> > > > >
> > > > > Just to make sure this isn't the source of the confusion: the root hubs
> > > > > are part of the USB controller, not 'external' hubs which are directly
> > > > > connected to the controller. I call the latter 'first level hubs'.
> > > > >
> > > > > > Unless it's called with the same "parent_hub" then it seems like if
> > > > > > the USB device has a device tree node and that device tree node is for
> > > > > > a onboard_usb_hub and there's no companion node then we _always_ want
> > > > > > to create the platform device, don't we? If it is called with the same
> > > > > > "parent_hub" then I'm confused how your test does something different
> > > > > > the first time the function is called vs. the 2nd.
> > > > >
> > > > > Let's use an adapted trogdor DT with only a USB 2.x hub as an example:
> > > > >
> > > > > usb_1_dwc3 {
> > > > >          dr_mode = "host";
> > > > >          #address-cells = <1>;
> > > > >          #size-cells = <0>;
> > > > >
> > > > >          /* 2.x hub on port 1 */
> > > > >          usb_hub_2_x: hub@1 {
> > > > >                  compatible = "usbbda,5411";
> > > > >                  reg = <1>;
> > > > >                  vdd-supply = <&pp3300_hub>;
> > > > >          };
> > > > > };
> > > > >
> > > > > 1st call: the 'parent_hub' corresponds to the USB 3.x root hub of
> > > > > usb_1_dwc3, the DT node of the hub is 'usb_1_dwc3'. The function
> > > > > iterates over the ports, finds usb_hub_2_x, enters the else branch
> > > > > (no companion hub), checks that the function was called on behalf
> > > > > of the primary controller and creates the pdev.
> > > > >
> > > > > 2nd call: the 'parent_hub' corresponds to the USB 2.x root hub of
> > > > > usb_1_dwc3, the DT node of the hub is also 'usb_1_dwc3'. The function
> > > > > iterates over the ports, finds usb_hub_2_x, enters the else branch
> > > > > (no companion hub), sees that it is not called on behalf of the
> > > > > primary controller and does not create a second (unnecessary) pdev.
> > > > >
> > > > > Is it clearer now?
> > > >
> > > > Ah, I get it now! Sorry for being so dense...
> > >
> > > No worries, it's certainly not obvious and probably my commentary could
> > > have been clearer.
> > >
> > > > So like this:
> > > >
> > > > Root hubs (those hubs with no parent) are all created with the same
> > > > device_node, the one for the controller itself. We don't want to
> > > > iterate through the same children multiple times, so we bail right
> > > > away if we're detect that `parent_hub` is a root hub and we're not on
> > > > the primary HCD.
> > >
> > > yep
> > >
> > > > For all other cases the primary and secondary controllers have distinct
> > > > device_nodes.
> > >
> > > You probably mean that all non-root hubs have distinct nodes, so for these
> > > the function is only called once.
> > >
> > > > I guess in theory that test could go before the "companion-hub" test,
> > > > though I don't see any case where it truly matters...
> > >
> > > Yeah, I'm still wondering whether it would be slightly less confusing to
> > > bail before the loop (besides saving a few cycles), it would eliminate
> > > the conflation with the 'companion-hub' check.
> >
> > I'm not sure how that would work, though? You'd essentially need two loops then?
>
> Maybe I got myself confused, but I think the behavior would be the same as
> now, without a second loop:
>
> We never create a pdev if the parent is a root hub and the controller is the
> secondary. Even for a hub with companion the pdev is only created when the call
> comes from the primary controller.
>
> Does that make sense?

Yes, looking at it with fresh eyes I think you're right.

Looking at the "companion-hub" case with fresh eyes, too, I wonder if
that can be simpler. If we find a companion hub, do we need both the
check for usb_hcd_is_primary_hcd() and the check to see whether the
pdev was already created?


-Doug

Re: [PATCH v22 2/3] usb: misc: Add onboard_usb_hub driver

[Matthias Kaehlcke]

On Fri, Jun 17, 2022 at 08:09:06AM -0700, Doug Anderson wrote:
> Hi,
> 
> On Thu, Jun 16, 2022 at 5:36 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> >
> > On Thu, Jun 16, 2022 at 03:46:15PM -0700, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Thu, Jun 16, 2022 at 3:01 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> > > >
> > > > On Thu, Jun 16, 2022 at 02:28:38PM -0700, Doug Anderson wrote:
> > > > > Hi,
> > > > >
> > > > > On Thu, Jun 16, 2022 at 2:08 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> > > > > >
> > > > > > On Thu, Jun 16, 2022 at 01:12:32PM -0700, Doug Anderson wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Wed, Jun 15, 2022 at 4:22 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> > > > > > > >
> > > > > > > > > > +void onboard_hub_create_pdevs(struct usb_device *parent_hub, struct list_head *pdev_list)
> > > > > > > > > > +{
> > > > > > > > > > +       int i;
> > > > > > > > > > +       struct usb_hcd *hcd = bus_to_hcd(parent_hub->bus);
> > > > > > > > > > +       struct device_node *np, *npc;
> > > > > > > > > > +       struct platform_device *pdev = NULL;
> > > > > > > > > > +       struct pdev_list_entry *pdle;
> > > > > > > > > > +
> > > > > > > > > > +       if (!parent_hub->dev.of_node)
> > > > > > > > > > +               return;
> > > > > > > > > > +
> > > > > > > > > > +       for (i = 1; i <= parent_hub->maxchild; i++) {
> > > > > > > > > > +               np = usb_of_get_device_node(parent_hub, i);
> > > > > > > > > > +               if (!np)
> > > > > > > > > > +                       continue;
> > > > > > > > > > +
> > > > > > > > > > +               if (!of_is_onboard_usb_hub(np))
> > > > > > > > > > +                       goto node_put;
> > > > > > > > > > +
> > > > > > > > > > +               npc = of_parse_phandle(np, "companion-hub", 0);
> > > > > > > > > > +               if (npc) {
> > > > > > > > > > +                       /*
> > > > > > > > > > +                        * Hubs with companions share the same platform device.
> > > > > > > > > > +                        * Create the plaform device only for the hub that is
> > > > > > > > > > +                        * connected to the primary HCD (directly or through
> > > > > > > > > > +                        * other hubs).
> > > > > > > > > > +                        */
> > > > > > > > > > +                       if (!usb_hcd_is_primary_hcd(hcd)) {
> > > > > > > > > > +                               of_node_put(npc);
> > > > > > > > > > +                               goto node_put;
> > > > > > > > > > +                       }
> > > > > > > > > > +
> > > > > > > > > > +                       pdev = of_find_device_by_node(npc);
> > > > > > > > > > +                       of_node_put(npc);
> > > > > > > > > > +               } else {
> > > > > > > > > > +                       /*
> > > > > > > > > > +                        * For root hubs this function can be called multiple times
> > > > > > > > > > +                        * for the same root hub node (the HCD node). Make sure only
> > > > > > > > > > +                        * one platform device is created for this hub.
> > > > > > > > > > +                        */
> > > > > > > > > > +                       if (!parent_hub->parent && !usb_hcd_is_primary_hcd(hcd))
> > > > > > > > > > +                               goto node_put;
> > > > > > > > >
> > > > > > > > > I don't understand the "else" case above. What case exactly are we
> > > > > > > > > handling again? This is when:
> > > > > > > > > * the hub is presumably just a 2.0 hub since there is no companion.
> > > > > > > > > * our parent is the root hub and the USB 2.0 hub we're looking at is
> > > > > > > > > not the primary
> > > > > > > >
> > > > > > > > The 'else' case can be entered for hubs connected to a root hub or to another
> > > > > > > > hub further down in the tree, but we bail out only for first level hubs.
> > > > > > > >
> > > > > > > > > ...but that doesn't make a lot of sense to me? I must have missed something...
> > > > > > > >
> > > > > > > > It's not super-obvious, this bit is important: "this function can be called
> > > > > > > > multiple times for the same root hub node". For any first level hub we only
> > > > > > > > create a pdev if this function is called on behalf of the primary HCD. That
> > > > > > > > is also true of a hub connected to the secondary HCD. We only want to create
> > > > > > > > one pdev and there is supposedly always a primary HCD.
> > > > > > > >
> > > > > > > > Maybe it would be slightly clearer if the function returned before the loop
> > > > > > > > if this condition is met.
> > > > > > >
> > > > > > > I guess I'm still pretty confused. You say "For root hubs this
> > > > > > > function can be called multiple times for the same root hub node".
> > > > > > > Does that mean that the function will be called multiple times with
> > > > > > > the same "parent_hub", or something else.
> > > > > >
> > > > > > It is called with a different "parent_hub", however for root hubs the
> > > > > > DT node is the same for both root hubs (it's the DT node of the
> > > > > > controller since there are no dedicated nodes for the root hubs).
> > > > > >
> > > > > > Just to make sure this isn't the source of the confusion: the root hubs
> > > > > > are part of the USB controller, not 'external' hubs which are directly
> > > > > > connected to the controller. I call the latter 'first level hubs'.
> > > > > >
> > > > > > > Unless it's called with the same "parent_hub" then it seems like if
> > > > > > > the USB device has a device tree node and that device tree node is for
> > > > > > > a onboard_usb_hub and there's no companion node then we _always_ want
> > > > > > > to create the platform device, don't we? If it is called with the same
> > > > > > > "parent_hub" then I'm confused how your test does something different
> > > > > > > the first time the function is called vs. the 2nd.
> > > > > >
> > > > > > Let's use an adapted trogdor DT with only a USB 2.x hub as an example:
> > > > > >
> > > > > > usb_1_dwc3 {
> > > > > >          dr_mode = "host";
> > > > > >          #address-cells = <1>;
> > > > > >          #size-cells = <0>;
> > > > > >
> > > > > >          /* 2.x hub on port 1 */
> > > > > >          usb_hub_2_x: hub@1 {
> > > > > >                  compatible = "usbbda,5411";
> > > > > >                  reg = <1>;
> > > > > >                  vdd-supply = <&pp3300_hub>;
> > > > > >          };
> > > > > > };
> > > > > >
> > > > > > 1st call: the 'parent_hub' corresponds to the USB 3.x root hub of
> > > > > > usb_1_dwc3, the DT node of the hub is 'usb_1_dwc3'. The function
> > > > > > iterates over the ports, finds usb_hub_2_x, enters the else branch
> > > > > > (no companion hub), checks that the function was called on behalf
> > > > > > of the primary controller and creates the pdev.
> > > > > >
> > > > > > 2nd call: the 'parent_hub' corresponds to the USB 2.x root hub of
> > > > > > usb_1_dwc3, the DT node of the hub is also 'usb_1_dwc3'. The function
> > > > > > iterates over the ports, finds usb_hub_2_x, enters the else branch
> > > > > > (no companion hub), sees that it is not called on behalf of the
> > > > > > primary controller and does not create a second (unnecessary) pdev.
> > > > > >
> > > > > > Is it clearer now?
> > > > >
> > > > > Ah, I get it now! Sorry for being so dense...
> > > >
> > > > No worries, it's certainly not obvious and probably my commentary could
> > > > have been clearer.
> > > >
> > > > > So like this:
> > > > >
> > > > > Root hubs (those hubs with no parent) are all created with the same
> > > > > device_node, the one for the controller itself. We don't want to
> > > > > iterate through the same children multiple times, so we bail right
> > > > > away if we're detect that `parent_hub` is a root hub and we're not on
> > > > > the primary HCD.
> > > >
> > > > yep
> > > >
> > > > > For all other cases the primary and secondary controllers have distinct
> > > > > device_nodes.
> > > >
> > > > You probably mean that all non-root hubs have distinct nodes, so for these
> > > > the function is only called once.
> > > >
> > > > > I guess in theory that test could go before the "companion-hub" test,
> > > > > though I don't see any case where it truly matters...
> > > >
> > > > Yeah, I'm still wondering whether it would be slightly less confusing to
> > > > bail before the loop (besides saving a few cycles), it would eliminate
> > > > the conflation with the 'companion-hub' check.
> > >
> > > I'm not sure how that would work, though? You'd essentially need two loops then?
> >
> > Maybe I got myself confused, but I think the behavior would be the same as
> > now, without a second loop:
> >
> > We never create a pdev if the parent is a root hub and the controller is the
> > secondary. Even for a hub with companion the pdev is only created when the call
> > comes from the primary controller.
> >
> > Does that make sense?
> 
> Yes, looking at it with fresh eyes I think you're right.
> 
> Looking at the "companion-hub" case with fresh eyes, too, I wonder if
> that can be simpler. If we find a companion hub, do we need both the
> check for usb_hcd_is_primary_hcd() and the check to see whether the
> pdev was already created?

I was also doubting about this and concluded that it is still needed.

Let's use once more the trogdor config as example, which has one physical
onboard hub chip with a USB 3.1 hub and a USB 2.1 companion hub, connected
to the dwc3 controller:

&usb_1_dwc3 {
	dr_mode = "host";
	#address-cells = <1>;
	#size-cells = <0>;

	/* 2.x hub on port 1 */
	usb_hub_2_x: hub@1 {
		compatible = "usbbda,5411";
		reg = <1>;
		vdd-supply = <&pp3300_hub>;
		companion-hub = <&usb_hub_3_x>;
	};

	/* 3.x hub on port 2 */
	usb_hub_3_x: hub@2 {
		compatible = "usbbda,411";
		reg = <2>;
		vdd-supply = <&pp3300_hub>;
		companion-hub = <&usb_hub_2_x>;
	};
};

Let's assume we don't check for the pdev. With our change above for root hubs
the loop is now only executed for the primary HCD. In the first iteration
we encounter the 2.x hub, it has a companion hub, but that alone doesn't
tell us much, so we create a pdev. In the next iteration we encouter the
3.x hub, it also has a companion hub, but we don't know/check that the
companion already has a pdev, so we create another one for the same
physical hub.

Re: [PATCH v22 2/3] usb: misc: Add onboard_usb_hub driver

[Doug Anderson]

Hi,

On Fri, Jun 17, 2022 at 9:34 AM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> > Looking at the "companion-hub" case with fresh eyes, too, I wonder if
> > that can be simpler. If we find a companion hub, do we need both the
> > check for usb_hcd_is_primary_hcd() and the check to see whether the
> > pdev was already created?
>
> I was also doubting about this and concluded that it is still needed.
>
> Let's use once more the trogdor config as example, which has one physical
> onboard hub chip with a USB 3.1 hub and a USB 2.1 companion hub, connected
> to the dwc3 controller:
>
> &usb_1_dwc3 {
>         dr_mode = "host";
>         #address-cells = <1>;
>         #size-cells = <0>;
>
>         /* 2.x hub on port 1 */
>         usb_hub_2_x: hub@1 {
>                 compatible = "usbbda,5411";
>                 reg = <1>;
>                 vdd-supply = <&pp3300_hub>;
>                 companion-hub = <&usb_hub_3_x>;
>         };
>
>         /* 3.x hub on port 2 */
>         usb_hub_3_x: hub@2 {
>                 compatible = "usbbda,411";
>                 reg = <2>;
>                 vdd-supply = <&pp3300_hub>;
>                 companion-hub = <&usb_hub_2_x>;
>         };
> };
>
> Let's assume we don't check for the pdev. With our change above for root hubs
> the loop is now only executed for the primary HCD. In the first iteration
> we encounter the 2.x hub, it has a companion hub, but that alone doesn't
> tell us much, so we create a pdev. In the next iteration we encouter the
> 3.x hub, it also has a companion hub, but we don't know/check that the
> companion already has a pdev, so we create another one for the same
> physical hub.

Ah, you are correct. You only run into that case for the root hub,
correct? For everything else it's impossible?

...and I guess things would be different if inside the loop you
actually set "hcd" to point to the "hcd" of the child device. I guess
that's where my confusion keeps stemming from. "hcd" is the parent's
host controller which is not always the same as the child's host
controller.

It would have been keen if we could somehow know the child's host
controller and get a pointer to that, but we can't because the child
device hasn't been enumerated yet.

OK, I'm convinced. I'll mention it in your v23 but maybe I'll have a
slightly better chance of figuring this out if/when I look at this
again if we rename "hcd" to "parent_hcd".


-Doug

Re: [PATCH v22 2/3] usb: misc: Add onboard_usb_hub driver

[Matthias Kaehlcke]

On Fri, Jun 24, 2022 at 01:33:19PM -0700, Doug Anderson wrote:
> Hi,
> 
> On Fri, Jun 17, 2022 at 9:34 AM Matthias Kaehlcke <mka@chromium.org> wrote:
> >
> > > Looking at the "companion-hub" case with fresh eyes, too, I wonder if
> > > that can be simpler. If we find a companion hub, do we need both the
> > > check for usb_hcd_is_primary_hcd() and the check to see whether the
> > > pdev was already created?
> >
> > I was also doubting about this and concluded that it is still needed.
> >
> > Let's use once more the trogdor config as example, which has one physical
> > onboard hub chip with a USB 3.1 hub and a USB 2.1 companion hub, connected
> > to the dwc3 controller:
> >
> > &usb_1_dwc3 {
> >         dr_mode = "host";
> >         #address-cells = <1>;
> >         #size-cells = <0>;
> >
> >         /* 2.x hub on port 1 */
> >         usb_hub_2_x: hub@1 {
> >                 compatible = "usbbda,5411";
> >                 reg = <1>;
> >                 vdd-supply = <&pp3300_hub>;
> >                 companion-hub = <&usb_hub_3_x>;
> >         };
> >
> >         /* 3.x hub on port 2 */
> >         usb_hub_3_x: hub@2 {
> >                 compatible = "usbbda,411";
> >                 reg = <2>;
> >                 vdd-supply = <&pp3300_hub>;
> >                 companion-hub = <&usb_hub_2_x>;
> >         };
> > };
> >
> > Let's assume we don't check for the pdev. With our change above for root hubs
> > the loop is now only executed for the primary HCD. In the first iteration
> > we encounter the 2.x hub, it has a companion hub, but that alone doesn't
> > tell us much, so we create a pdev. In the next iteration we encouter the
> > 3.x hub, it also has a companion hub, but we don't know/check that the
> > companion already has a pdev, so we create another one for the same
> > physical hub.
> 
> Ah, you are correct. You only run into that case for the root hub,
> correct? For everything else it's impossible?
> 
> ...and I guess things would be different if inside the loop you
> actually set "hcd" to point to the "hcd" of the child device. I guess
> that's where my confusion keeps stemming from. "hcd" is the parent's
> host controller which is not always the same as the child's host
> controller.

I'd phrase it differently: for root hubs the 'parent_hub' isn't necessarily
the parent of each 'child' node.

> It would have been keen if we could somehow know the child's host
> controller and get a pointer to that, but we can't because the child
> device hasn't been enumerated yet.
> 
> OK, I'm convinced. I'll mention it in your v23 but maybe I'll have a
> slightly better chance of figuring this out if/when I look at this
> again if we rename "hcd" to "parent_hcd".

I'm not convinced that this would generally help to reduce the confusion.
To me 'parent_hcd' sounds as if there was a tree of HCDs, which isn't
the case. Also one could still read 'parent_hcd' as the HCD of all
'child' nodes.

Maybe a bit more verbose documentation like this could help:

  Some background about the logic in this function, which can be a bit hard
  to follow:

  Root hubs don't have dedicated device tree nodes, but use the node of their
  HCD. The primary and secondary HCD are usually represented by a single DT
  node. That means the root hubs of the primary and secondary HCD share the
  same device tree node (the HCD node). As a result this function can be
  called twice with the same DT node for root hubs. We only want to create a
  single platform device for each physical onboard hub, hence for root hubs
  the loop is only executed for the primary hub. Since the function scans
  through all child nodes it still creates pdevs for onboard hubs connected
  to the secondary hub if needed.

  Further there must be only one platform device for onboard hubs with a
  companion hub (the hub is a single physical device). To achieve this two
  measures are taken: pdevs for onboard hubs with a companion are only
  created when the function is called on behalf of the parent hub that is
  connected to the primary HCD (directly or through other hubs). For onboard
  hubs connected to root hubs the function processes the nodes of both
  companions. A platform device is only created if the companion hub doesn't
  have one already.


When writing this I realized that the check for an existing platform device
for companions could be put inside an 'if (!parent_hub->parent)' block. It
isn't necessary for hubs deeper down in the chain, since their pdev will only
be created for the hub (indirectly) connected to the primary HCD.

Re: [PATCH v22 2/3] usb: misc: Add onboard_usb_hub driver

[Alan Stern]

On Mon, Jun 27, 2022 at 11:14:47AM -0700, Matthias Kaehlcke wrote:
> Maybe a bit more verbose documentation like this could help:
> 
>   Some background about the logic in this function, which can be a bit hard
>   to follow:
> 
>   Root hubs don't have dedicated device tree nodes, but use the node of their
>   HCD. The primary and secondary HCD are usually represented by a single DT
>   node. That means the root hubs of the primary and secondary HCD share the
>   same device tree node (the HCD node). As a result this function can be
>   called twice with the same DT node for root hubs. We only want to create a
>   single platform device for each physical onboard hub, hence for root hubs
>   the loop is only executed for the primary hub. Since the function scans

By "primary hub", you mean "root hub for the primary HCD", right?  This 
should be clarified.

>   through all child nodes it still creates pdevs for onboard hubs connected
>   to the secondary hub if needed.

And likewise for "secondary hub".

> 
>   Further there must be only one platform device for onboard hubs with a
>   companion hub (the hub is a single physical device). To achieve this two

What do you mean by "companion hub"?  I think you are using the wrong 
word here.  If you're talking about the relation between the two logical 
hubs (one attached to the SuperSpeed bus and one attached to the 
Low/Full/High-speed bus) within a physical USB-3 hub, the correct term 
for this is "peer".  See the existing usages in hub.h, hub.c, and 
port.c.

"Companion" refers to something completely different (i.e., the UHCI or 
OHCI controllers that handle Low/Full-speed connections on behalf of a 
High-speed EHCI controller).

Alan Stern

Re: [PATCH v22 2/3] usb: misc: Add onboard_usb_hub driver

[Matthias Kaehlcke]

On Mon, Jun 27, 2022 at 02:54:03PM -0400, Alan Stern wrote:
> On Mon, Jun 27, 2022 at 11:14:47AM -0700, Matthias Kaehlcke wrote:
> > Maybe a bit more verbose documentation like this could help:
> > 
> >   Some background about the logic in this function, which can be a bit hard
> >   to follow:
> > 
> >   Root hubs don't have dedicated device tree nodes, but use the node of their
> >   HCD. The primary and secondary HCD are usually represented by a single DT
> >   node. That means the root hubs of the primary and secondary HCD share the
> >   same device tree node (the HCD node). As a result this function can be
> >   called twice with the same DT node for root hubs. We only want to create a
> >   single platform device for each physical onboard hub, hence for root hubs
> >   the loop is only executed for the primary hub. Since the function scans
> 
> By "primary hub", you mean "root hub for the primary HCD", right?  This 
> should be clarified.

Ok, thanks for the suggestion!

> >   through all child nodes it still creates pdevs for onboard hubs connected
> >   to the secondary hub if needed.
> 
> And likewise for "secondary hub".
>
> > 
> >   Further there must be only one platform device for onboard hubs with a
> >   companion hub (the hub is a single physical device). To achieve this two
> 
> What do you mean by "companion hub"?  I think you are using the wrong 
> word here.  If you're talking about the relation between the two logical 
> hubs (one attached to the SuperSpeed bus and one attached to the 
> Low/Full/High-speed bus) within a physical USB-3 hub, the correct term 
> for this is "peer".  See the existing usages in hub.h, hub.c, and 
> port.c.
> 
> "Companion" refers to something completely different (i.e., the UHCI or 
> OHCI controllers that handle Low/Full-speed connections on behalf of a 
> High-speed EHCI controller).

Yes it's the relation between the two logical hub. The term 'companion-hub'
stems from the binding and has been around since v6 of this series. I guess
we should update the binding if the terminology isn't correct.

Re: [PATCH v22 2/3] usb: misc: Add onboard_usb_hub driver

[Alan Stern]

On Mon, Jun 27, 2022 at 12:06:21PM -0700, Matthias Kaehlcke wrote:
> On Mon, Jun 27, 2022 at 02:54:03PM -0400, Alan Stern wrote:
> > On Mon, Jun 27, 2022 at 11:14:47AM -0700, Matthias Kaehlcke wrote:
> > > 
> > >   Further there must be only one platform device for onboard hubs with a
> > >   companion hub (the hub is a single physical device). To achieve this two
> > 
> > What do you mean by "companion hub"?  I think you are using the wrong 
> > word here.  If you're talking about the relation between the two logical 
> > hubs (one attached to the SuperSpeed bus and one attached to the 
> > Low/Full/High-speed bus) within a physical USB-3 hub, the correct term 
> > for this is "peer".  See the existing usages in hub.h, hub.c, and 
> > port.c.
> > 
> > "Companion" refers to something completely different (i.e., the UHCI or 
> > OHCI controllers that handle Low/Full-speed connections on behalf of a 
> > High-speed EHCI controller).
> 
> Yes it's the relation between the two logical hub. The term 'companion-hub'
> stems from the binding and has been around since v6 of this series. I guess
> we should update the binding if the terminology isn't correct.

That sounds like a good idea.

Alan Stern

Re: [PATCH v22 2/3] usb: misc: Add onboard_usb_hub driver

[Doug Anderson]

Hi,

On Mon, Jun 27, 2022 at 11:14 AM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> On Fri, Jun 24, 2022 at 01:33:19PM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Fri, Jun 17, 2022 at 9:34 AM Matthias Kaehlcke <mka@chromium.org> wrote:
> > >
> > > > Looking at the "companion-hub" case with fresh eyes, too, I wonder if
> > > > that can be simpler. If we find a companion hub, do we need both the
> > > > check for usb_hcd_is_primary_hcd() and the check to see whether the
> > > > pdev was already created?
> > >
> > > I was also doubting about this and concluded that it is still needed.
> > >
> > > Let's use once more the trogdor config as example, which has one physical
> > > onboard hub chip with a USB 3.1 hub and a USB 2.1 companion hub, connected
> > > to the dwc3 controller:
> > >
> > > &usb_1_dwc3 {
> > >         dr_mode = "host";
> > >         #address-cells = <1>;
> > >         #size-cells = <0>;
> > >
> > >         /* 2.x hub on port 1 */
> > >         usb_hub_2_x: hub@1 {
> > >                 compatible = "usbbda,5411";
> > >                 reg = <1>;
> > >                 vdd-supply = <&pp3300_hub>;
> > >                 companion-hub = <&usb_hub_3_x>;
> > >         };
> > >
> > >         /* 3.x hub on port 2 */
> > >         usb_hub_3_x: hub@2 {
> > >                 compatible = "usbbda,411";
> > >                 reg = <2>;
> > >                 vdd-supply = <&pp3300_hub>;
> > >                 companion-hub = <&usb_hub_2_x>;
> > >         };
> > > };
> > >
> > > Let's assume we don't check for the pdev. With our change above for root hubs
> > > the loop is now only executed for the primary HCD. In the first iteration
> > > we encounter the 2.x hub, it has a companion hub, but that alone doesn't
> > > tell us much, so we create a pdev. In the next iteration we encouter the
> > > 3.x hub, it also has a companion hub, but we don't know/check that the
> > > companion already has a pdev, so we create another one for the same
> > > physical hub.
> >
> > Ah, you are correct. You only run into that case for the root hub,
> > correct? For everything else it's impossible?
> >
> > ...and I guess things would be different if inside the loop you
> > actually set "hcd" to point to the "hcd" of the child device. I guess
> > that's where my confusion keeps stemming from. "hcd" is the parent's
> > host controller which is not always the same as the child's host
> > controller.
>
> I'd phrase it differently: for root hubs the 'parent_hub' isn't necessarily
> the parent of each 'child' node.
>
> > It would have been keen if we could somehow know the child's host
> > controller and get a pointer to that, but we can't because the child
> > device hasn't been enumerated yet.
> >
> > OK, I'm convinced. I'll mention it in your v23 but maybe I'll have a
> > slightly better chance of figuring this out if/when I look at this
> > again if we rename "hcd" to "parent_hcd".
>
> I'm not convinced that this would generally help to reduce the confusion.
> To me 'parent_hcd' sounds as if there was a tree of HCDs, which isn't
> the case. Also one could still read 'parent_hcd' as the HCD of all
> 'child' nodes.
>
> Maybe a bit more verbose documentation like this could help:
>
>   Some background about the logic in this function, which can be a bit hard
>   to follow:
>
>   Root hubs don't have dedicated device tree nodes, but use the node of their
>   HCD. The primary and secondary HCD are usually represented by a single DT
>   node. That means the root hubs of the primary and secondary HCD share the
>   same device tree node (the HCD node). As a result this function can be
>   called twice with the same DT node for root hubs. We only want to create a
>   single platform device for each physical onboard hub, hence for root hubs
>   the loop is only executed for the primary hub. Since the function scans
>   through all child nodes it still creates pdevs for onboard hubs connected
>   to the secondary hub if needed.
>
>   Further there must be only one platform device for onboard hubs with a
>   companion hub (the hub is a single physical device). To achieve this two
>   measures are taken: pdevs for onboard hubs with a companion are only
>   created when the function is called on behalf of the parent hub that is
>   connected to the primary HCD (directly or through other hubs). For onboard
>   hubs connected to root hubs the function processes the nodes of both
>   companions. A platform device is only created if the companion hub doesn't
>   have one already.

Sounds good. Extra docs explaining this are always good and I'm fine
with more docs and leaving it called "hcd" instead of "parent_hcd"


> When writing this I realized that the check for an existing platform device
> for companions could be put inside an 'if (!parent_hub->parent)' block. It
> isn't necessary for hubs deeper down in the chain, since their pdev will only
> be created for the hub (indirectly) connected to the primary HCD.

Yup. I'm not 100% sure if it's worth adding the extra "if" test or
not. Could make the argument either way.

-Doug