Looking for help with Kconfig dependencies

DISCUSSION Matthias Kaehlcke 3 participants 6 messages Jun 18, 2021 – Jun 22, 2021

Subsystems (2)

USB Kbuild

lore

Share & tools

lore

Matthias Kaehlcke

author

2021-06-18 17:05 UTC #0 lore raw

Hi,

I'm adding a new driver and have an issue with Kconfig dependencies that I coulnd't sort out so far.

Patch https://lore.kernel.org/patchwork/patch/1444212/ adds the new onboard_usb_hub driver which exports two functions, onboard_hub_create_pdevs() and onboard_hub_destroy_pdevs(). It also provides stubs for these functions which are used when the driver is not selected (CONFIG_USB_ONBOARD_HUB=n).

The new exported functions are called by the xhci-plat driver
(https://lore.kernel.org/patchwork/patch/1444215/). Since xhci-plat now depends on symbols from the onboard_hub_driver the following dependency was added to its Kconfig entry:

config USB_XHCI_PLATFORM
tristate "Generic xHCI driver for a platform device" select USB_XHCI_RCAR if ARCH_RENESAS
+ depends on USB_ONBOARD_HUB || !USB_ONBOARD_HUB

This generally seems to work, however when USB_XHCI_PLATFORM is forced to be builtin by another driver that depends on it (e.g. USB_DWC3) it is still possible to build the onboard_hub driver as a module, which results in unresolved symbols:

aarch64-linux-gnu-ld: drivers/usb/host/xhci-plat.o: in function `xhci_plat_remove':
drivers/usb/host/xhci-plat.c:427: undefined reference to onboard_hub_destroy_pdevs' drivers/usb/host/xhci-plat.c:427:(.text+0x82c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol onboard_hub_destroy_pdevs'
aarch64-linux-gnu-ld: drivers/usb/host/xhci-plat.o: in function `xhci_plat_probe':
drivers/usb/host/xhci-plat.c:379: undefined reference to onboard_hub_create_pdevs' drivers/usb/host/xhci-plat.c:379:(.text+0x131c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol onboard_hub_create_pdevs'

Kconfig generates the following warning with this configuration:

WARNING: unmet direct dependencies detected for USB_XHCI_PLATFORM
Depends on [m]: USB_SUPPORT [=y] && USB [=y] && USB_XHCI_HCD [=y] && (USB_ONBOARD_HUB [=m] || !USB_ONBOARD_HUB [=m]) Selected by [y]:
- USB_DWC3 [=y] && USB_SUPPORT [=y] && (USB [=y] || USB_GADGET [=y]) && HAS_DMA [=y] && USB_XHCI_HCD [=y] Selected by [m]:
- USB_CDNS_SUPPORT [=m] && USB_SUPPORT [=y] && (USB [=y] || USB_GADGET [=y]) && HAS_DMA [=y] && USB_XHCI_HCD [=y]
- USB_BRCMSTB [=m] && USB_SUPPORT [=y] && USB [=y] && (ARCH_BRCMSTB [=y] && PHY_BRCM_USB [=m] || COMPILE_TEST [=y]) && USB_XHCI_HCD [=y]
- USB_XHCI_MVEBU [=m] && USB_SUPPORT [=y] && USB [=y] && USB_XHCI_HCD [=y] && HAS_IOMEM [=y] && (ARCH_MVEBU [=y] || COMPILE_TEST [=y])

I read through kconfig-language.rst and experimented a fair bit, but haven't found a working solution. Any advice would be appreciated.

Thanks

Matthias

Masahiro Yamada

2021-06-19 01:31 UTC #1 lore raw

Quoted 53 lines · Matthias Kaehlcke

Hi,
I'm adding a new driver and have an issue with Kconfig dependencies that I coulnd't sort out so far.
Patch https://lore.kernel.org/patchwork/patch/1444212/ adds the new onboard_usb_hub driver which exports two functions, onboard_hub_create_pdevs() and onboard_hub_destroy_pdevs(). It also provides stubs for these functions which are used when the driver is not selected (CONFIG_USB_ONBOARD_HUB=n).
The new exported functions are called by the xhci-plat driver
(https://lore.kernel.org/patchwork/patch/1444215/). Since xhci-plat now depends on symbols from the onboard_hub_driver the following dependency was added to its Kconfig entry:
config USB_XHCI_PLATFORM
tristate "Generic xHCI driver for a platform device" select USB_XHCI_RCAR if ARCH_RENESAS
+ depends on USB_ONBOARD_HUB || !USB_ONBOARD_HUB
This generally seems to work, however when USB_XHCI_PLATFORM is forced to be builtin by another driver that depends on it (e.g. USB_DWC3) it is still possible to build the onboard_hub driver as a module, which results in unresolved symbols:
aarch64-linux-gnu-ld: drivers/usb/host/xhci-plat.o: in function `xhci_plat_remove':
drivers/usb/host/xhci-plat.c:427: undefined reference to onboard_hub_destroy_pdevs' drivers/usb/host/xhci-plat.c:427:(.text+0x82c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol onboard_hub_destroy_pdevs'
aarch64-linux-gnu-ld: drivers/usb/host/xhci-plat.o: in function `xhci_plat_probe':
drivers/usb/host/xhci-plat.c:379: undefined reference to onboard_hub_create_pdevs' drivers/usb/host/xhci-plat.c:379:(.text+0x131c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol onboard_hub_create_pdevs'
Kconfig generates the following warning with this configuration:
WARNING: unmet direct dependencies detected for USB_XHCI_PLATFORM
Depends on [m]: USB_SUPPORT [=y] && USB [=y] && USB_XHCI_HCD [=y] && (USB_ONBOARD_HUB [=m] || !USB_ONBOARD_HUB [=m]) Selected by [y]:
- USB_DWC3 [=y] && USB_SUPPORT [=y] && (USB [=y] || USB_GADGET [=y]) && HAS_DMA [=y] && USB_XHCI_HCD [=y] Selected by [m]:
- USB_CDNS_SUPPORT [=m] && USB_SUPPORT [=y] && (USB [=y] || USB_GADGET [=y]) && HAS_DMA [=y] && USB_XHCI_HCD [=y]
- USB_BRCMSTB [=m] && USB_SUPPORT [=y] && USB [=y] && (ARCH_BRCMSTB [=y] && PHY_BRCM_USB [=m] || COMPILE_TEST [=y]) && USB_XHCI_HCD [=y]
- USB_XHCI_MVEBU [=m] && USB_SUPPORT [=y] && USB [=y] && USB_XHCI_HCD [=y] && HAS_IOMEM [=y] && (ARCH_MVEBU [=y] || COMPILE_TEST [=y])

Quoted 7 lines

I read through kconfig-language.rst and experimented a fair bit, but haven't found a working solution. Any advice would be appreciated.
Thanks
Matthias

This issue should be discussed in the USB ML,
but probably 'depends on USB_XHCI_PLATFORM'
should be used everywhere instead of
'depends on USB_XHCI_PLATFORM'.

--
Best Regards
Masahiro Yamada

Matthias Kaehlcke

author

2021-06-21 14:55 UTC #2 lore raw

Quoted 58 lines · Masahiro Yamada

Quoted 57 lines · Matthias Kaehlcke
Hi,
I'm adding a new driver and have an issue with Kconfig dependencies that I coulnd't sort out so far.
Patch https://lore.kernel.org/patchwork/patch/1444212/ adds the new onboard_usb_hub driver which exports two functions, onboard_hub_create_pdevs() and onboard_hub_destroy_pdevs(). It also provides stubs for these functions which are used when the driver is not selected (CONFIG_USB_ONBOARD_HUB=n).
The new exported functions are called by the xhci-plat driver
(https://lore.kernel.org/patchwork/patch/1444215/). Since xhci-plat now depends on symbols from the onboard_hub_driver the following dependency was added to its Kconfig entry:
config USB_XHCI_PLATFORM
tristate "Generic xHCI driver for a platform device" select USB_XHCI_RCAR if ARCH_RENESAS
+ depends on USB_ONBOARD_HUB || !USB_ONBOARD_HUB
This generally seems to work, however when USB_XHCI_PLATFORM is forced to be builtin by another driver that depends on it (e.g. USB_DWC3) it is still possible to build the onboard_hub driver as a module, which results in unresolved symbols:
aarch64-linux-gnu-ld: drivers/usb/host/xhci-plat.o: in function `xhci_plat_remove':
drivers/usb/host/xhci-plat.c:427: undefined reference to onboard_hub_destroy_pdevs' drivers/usb/host/xhci-plat.c:427:(.text+0x82c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol onboard_hub_destroy_pdevs'
aarch64-linux-gnu-ld: drivers/usb/host/xhci-plat.o: in function `xhci_plat_probe':
drivers/usb/host/xhci-plat.c:379: undefined reference to onboard_hub_create_pdevs' drivers/usb/host/xhci-plat.c:379:(.text+0x131c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol onboard_hub_create_pdevs'
Kconfig generates the following warning with this configuration:
WARNING: unmet direct dependencies detected for USB_XHCI_PLATFORM
Depends on [m]: USB_SUPPORT [=y] && USB [=y] && USB_XHCI_HCD [=y] && (USB_ONBOARD_HUB [=m] || !USB_ONBOARD_HUB [=m]) Selected by [y]:
- USB_DWC3 [=y] && USB_SUPPORT [=y] && (USB [=y] || USB_GADGET [=y]) && HAS_DMA [=y] && USB_XHCI_HCD [=y] Selected by [m]:
- USB_CDNS_SUPPORT [=m] && USB_SUPPORT [=y] && (USB [=y] || USB_GADGET [=y]) && HAS_DMA [=y] && USB_XHCI_HCD [=y]
- USB_BRCMSTB [=m] && USB_SUPPORT [=y] && USB [=y] && (ARCH_BRCMSTB [=y] && PHY_BRCM_USB [=m] || COMPILE_TEST [=y]) && USB_XHCI_HCD [=y]
- USB_XHCI_MVEBU [=m] && USB_SUPPORT [=y] && USB [=y] && USB_XHCI_HCD [=y] && HAS_IOMEM [=y] && (ARCH_MVEBU [=y] || COMPILE_TEST [=y])
I read through kconfig-language.rst and experimented a fair bit, but haven't found a working solution. Any advice would be appreciated.

Quoted 7 lines

Quoted 3 lines
Thanks
Matthias
This issue should be discussed in the USB ML,

That's where it was initially brought up, but it didn't get the attention of anyone in the position to give advice. Since the issue is more about kbuild dependencies than USB specifically I brought it up here. The driver already landed in the USB tree but was reverted due to this issue, I'm stuck on this problem and really don't want the driver to die on the finish line.

A workaround could be to make the driver 'bool' rather than 'tristate', but I'm not sure if that would be acceptable.

Quoted 2 lines

but probably 'depends on USB_XHCI_PLATFORM' should be used everywhere instead of 'depends on USB_XHCI_PLATFORM'.

Did you mean 'select USB_XHCI_PLATFORM' rather than 'depends on USB_XHCI_PLATFORM'? In general that sounds reasonable, since the drivers don't actually depend on USB_XHCI_PLATFORM from a build perspective, and it's what some drivers actually do. However it doesn't fix the problem, apparently a 'select X' from CONFIG_Y still results in CONFIG_X being 'y' if CONFIG_Y is 'y' (see the USB_DWC3 case above).

Matthias Kaehlcke

author

2021-06-22 23:49 UTC #3 lore raw

Quoted 80 lines · Matthias Kaehlcke

Quoted 58 lines · Masahiro Yamada
Quoted 57 lines · Matthias Kaehlcke
Hi,
I'm adding a new driver and have an issue with Kconfig dependencies that I coulnd't sort out so far.
Patch https://lore.kernel.org/patchwork/patch/1444212/ adds the new onboard_usb_hub driver which exports two functions, onboard_hub_create_pdevs() and onboard_hub_destroy_pdevs(). It also provides stubs for these functions which are used when the driver is not selected (CONFIG_USB_ONBOARD_HUB=n).
The new exported functions are called by the xhci-plat driver
(https://lore.kernel.org/patchwork/patch/1444215/). Since xhci-plat now depends on symbols from the onboard_hub_driver the following dependency was added to its Kconfig entry:
config USB_XHCI_PLATFORM
tristate "Generic xHCI driver for a platform device" select USB_XHCI_RCAR if ARCH_RENESAS
+ depends on USB_ONBOARD_HUB || !USB_ONBOARD_HUB
This generally seems to work, however when USB_XHCI_PLATFORM is forced to be builtin by another driver that depends on it (e.g. USB_DWC3) it is still possible to build the onboard_hub driver as a module, which results in unresolved symbols:
aarch64-linux-gnu-ld: drivers/usb/host/xhci-plat.o: in function `xhci_plat_remove':
drivers/usb/host/xhci-plat.c:427: undefined reference to onboard_hub_destroy_pdevs' drivers/usb/host/xhci-plat.c:427:(.text+0x82c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol onboard_hub_destroy_pdevs'
aarch64-linux-gnu-ld: drivers/usb/host/xhci-plat.o: in function `xhci_plat_probe':
drivers/usb/host/xhci-plat.c:379: undefined reference to onboard_hub_create_pdevs' drivers/usb/host/xhci-plat.c:379:(.text+0x131c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol onboard_hub_create_pdevs'
Kconfig generates the following warning with this configuration:
WARNING: unmet direct dependencies detected for USB_XHCI_PLATFORM
Depends on [m]: USB_SUPPORT [=y] && USB [=y] && USB_XHCI_HCD [=y] && (USB_ONBOARD_HUB [=m] || !USB_ONBOARD_HUB [=m]) Selected by [y]:
- USB_DWC3 [=y] && USB_SUPPORT [=y] && (USB [=y] || USB_GADGET [=y]) && HAS_DMA [=y] && USB_XHCI_HCD [=y] Selected by [m]:
- USB_CDNS_SUPPORT [=m] && USB_SUPPORT [=y] && (USB [=y] || USB_GADGET [=y]) && HAS_DMA [=y] && USB_XHCI_HCD [=y]
- USB_BRCMSTB [=m] && USB_SUPPORT [=y] && USB [=y] && (ARCH_BRCMSTB [=y] && PHY_BRCM_USB [=m] || COMPILE_TEST [=y]) && USB_XHCI_HCD [=y]
- USB_XHCI_MVEBU [=m] && USB_SUPPORT [=y] && USB [=y] && USB_XHCI_HCD [=y] && HAS_IOMEM [=y] && (ARCH_MVEBU [=y] || COMPILE_TEST [=y])
I read through kconfig-language.rst and experimented a fair bit, but haven't found a working solution. Any advice would be appreciated.
Quoted 7 lines
Quoted 3 lines
Thanks
Matthias
This issue should be discussed in the USB ML,
That's where it was initially brought up, but it didn't get the attention of anyone in the position to give advice. Since the issue is more about kbuild dependencies than USB specifically I brought it up here. The driver already landed in the USB tree but was reverted due to this issue, I'm stuck on this problem and really don't want the driver to die on the finish line.
A workaround could be to make the driver 'bool' rather than 'tristate', but I'm not sure if that would be acceptable.
Quoted 2 lines
but probably 'depends on USB_XHCI_PLATFORM' should be used everywhere instead of 'depends on USB_XHCI_PLATFORM'.

Quoted 6 lines

Did you mean 'select USB_XHCI_PLATFORM' rather than 'depends on USB_XHCI_PLATFORM'? In general that sounds reasonable, since the drivers don't actually depend on USB_XHCI_PLATFORM from a build perspective, and it's what some drivers actually do. However it doesn't fix the problem, apparently a 'select X' from CONFIG_Y still results in CONFIG_X being 'y' if CONFIG_Y is 'y' (see the USB_DWC3 case above).

After some more experimentation it looks like the opposite fixes the conflict, i.e. changing all instances of 'select USB_XHCI_PLATFORM' to 'depends on USB_XHCI_PLATFORM'.

That's also in line with the recommendation to limit the use of 'select' to certain use cases:

select should be used with care. select will force a symbol to a value without visiting the dependencies. By abusing select you are able to select a symbol FOO even if FOO depends on BAR that is not set. In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies. That will limit the usefulness but on the other hand avoid the illegal configurations all over.

https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html

Enrico Weigelt, metux IT consult

2021-06-21 11:26 UTC #4 lore raw

In reply to Matthias Kaehlcke

On 18.06.21 19:05, Matthias Kaehlcke wrote:

Hi,

Cc'ing to linux-usb ...

Quoted 11 lines

Patch https://lore.kernel.org/patchwork/patch/1444212/ adds the new onboard_usb_hub driver which exports two functions, onboard_hub_create_pdevs() and onboard_hub_destroy_pdevs(). It also provides stubs for these functions which are used when the driver is not selected (CONFIG_USB_ONBOARD_HUB=n).
The new exported functions are called by the xhci-plat driver
(https://lore.kernel.org/patchwork/patch/1444215/). Since xhci-plat now depends on symbols from the onboard_hub_driver the following dependency was added to its Kconfig entry:

Quoted 4 lines

config USB_XHCI_PLATFORM
tristate "Generic xHCI driver for a platform device" select USB_XHCI_RCAR if ARCH_RENESAS
+ depends on USB_ONBOARD_HUB || !USB_ONBOARD_HUB

What exactly do you intent to archieve with this ?

X or !X = 1, isn't it ?

Why should something depend on something present or absent ?

Is that depends on ... statement necessary at all ?

Quoted 22 lines

This generally seems to work, however when USB_XHCI_PLATFORM is forced to be builtin by another driver that depends on it (e.g. USB_DWC3) it is still possible to build the onboard_hub driver as a module, which results in unresolved symbols:
aarch64-linux-gnu-ld: drivers/usb/host/xhci-plat.o: in function `xhci_plat_remove':
drivers/usb/host/xhci-plat.c:427: undefined reference to onboard_hub_destroy_pdevs' drivers/usb/host/xhci-plat.c:427:(.text+0x82c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol onboard_hub_destroy_pdevs'
aarch64-linux-gnu-ld: drivers/usb/host/xhci-plat.o: in function `xhci_plat_probe':
drivers/usb/host/xhci-plat.c:379: undefined reference to onboard_hub_create_pdevs' drivers/usb/host/xhci-plat.c:379:(.text+0x131c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol onboard_hub_create_pdevs'
Kconfig generates the following warning with this configuration:

Quoted 8 lines

WARNING: unmet direct dependencies detected for USB_XHCI_PLATFORM
Depends on [m]: USB_SUPPORT [=y] && USB [=y] && USB_XHCI_HCD [=y] && (USB_ONBOARD_HUB [=m] || !USB_ONBOARD_HUB [=m]) Selected by [y]:
- USB_DWC3 [=y] && USB_SUPPORT [=y] && (USB [=y] || USB_GADGET [=y]) && HAS_DMA [=y] && USB_XHCI_HCD [=y] Selected by [m]:
- USB_CDNS_SUPPORT [=m] && USB_SUPPORT [=y] && (USB [=y] || USB_GADGET [=y]) && HAS_DMA [=y] && USB_XHCI_HCD [=y]
- USB_BRCMSTB [=m] && USB_SUPPORT [=y] && USB [=y] && (ARCH_BRCMSTB [=y] && PHY_BRCM_USB [=m] || COMPILE_TEST [=y]) && USB_XHCI_HCD [=y]
- USB_XHCI_MVEBU [=m] && USB_SUPPORT [=y] && USB [=y] && USB_XHCI_HCD [=y] && HAS_IOMEM [=y] && (ARCH_MVEBU [=y] || COMPILE_TEST [=y])

It seems that Kconfig is confused by trying to enforce contradicting dependencies.

Now for your driver:

If I understand it correctly, you've got a topology like this:

root hub -+--> 2ndary hub #0 -+--> usb-dev #0

          |                   \--> usb-dev #1
          |                     ..
          \--> 2ndary hub #1 -+--> usb-dev #3
                              \--> usb-dev #4

And in order to get usb-dev #foo running, you need the corresponding hub on its path powered (which in turn is platform specific).

Correct ?

So, why not reflecting exactly this topology in the device tree ? In that case, the power management *IMHO* could pretty automatically (assuming you've implemented the corresponding pm functions on the 2ndary hub driver).

Okay, that could become a bit tricky when the usb-dev's are automatically enumerated on the root hub and would need to be reparented somehow ... @usb folks: it that possible ?

Another option could be implementing this as a regulator that the individual usb devices will be attached to. Not completely semantically correct (since a hub isn't exactly a regulator :o), but should at least do the job: the regulator will be switched on when the device is used and can be switched off when it isn't used anymore.

The cleanest approach, IMHO, might be adding an hub subsys, somewhat similar to the existing phy subsys. I can imagine similar cases with other interfaces, not just USB only, at least certainly not specific to xhci.

Or could existing phy subsys already be sufficient for that ?

--mtx

Signature · 8 lines

---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
[email protected] -- +49-151-27565287

Matthias Kaehlcke

author

2021-06-21 15:35 UTC #5 lore raw

Quoted 23 lines · metux IT consult

On 18.06.21 19:05, Matthias Kaehlcke wrote:
Hi,
Cc'ing to linux-usb ...
Quoted 11 lines
Patch https://lore.kernel.org/patchwork/patch/1444212/ adds the new onboard_usb_hub driver which exports two functions, onboard_hub_create_pdevs() and onboard_hub_destroy_pdevs(). It also provides stubs for these functions which are used when the driver is not selected (CONFIG_USB_ONBOARD_HUB=n).
The new exported functions are called by the xhci-plat driver
(https://lore.kernel.org/patchwork/patch/1444215/). Since xhci-plat now depends on symbols from the onboard_hub_driver the following dependency was added to its Kconfig entry:
Quoted 4 lines
config USB_XHCI_PLATFORM
tristate "Generic xHCI driver for a platform device" select USB_XHCI_RCAR if ARCH_RENESAS
+ depends on USB_ONBOARD_HUB || !USB_ONBOARD_HUB

Quoted 7 lines

What exactly do you intent to archieve with this ?
X or !X = 1, isn't it ?
Why should something depend on something present or absent ?
Is that depends on ... statement necessary at all ?

I know, it's confusing, I had the same reaction when I first saw that construct.

Effectively USB_XHCI_PLATFORM can be built without USB_ONBOARD_HUB. However if USB_ONBOARD_HUB is built as a module then USB_XHCI_PLATFORM should also be built as a module, which is what the above statement achieves, unless there are conflicting dependencies.

The same construct is used for CONFIG_USB_XHCI_PCI.

Quoted 31 lines

Quoted 22 lines
This generally seems to work, however when USB_XHCI_PLATFORM is forced to be builtin by another driver that depends on it (e.g. USB_DWC3) it is still possible to build the onboard_hub driver as a module, which results in unresolved symbols:
aarch64-linux-gnu-ld: drivers/usb/host/xhci-plat.o: in function `xhci_plat_remove':
drivers/usb/host/xhci-plat.c:427: undefined reference to onboard_hub_destroy_pdevs' drivers/usb/host/xhci-plat.c:427:(.text+0x82c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol onboard_hub_destroy_pdevs'
aarch64-linux-gnu-ld: drivers/usb/host/xhci-plat.o: in function `xhci_plat_probe':
drivers/usb/host/xhci-plat.c:379: undefined reference to onboard_hub_create_pdevs' drivers/usb/host/xhci-plat.c:379:(.text+0x131c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol onboard_hub_create_pdevs'
Kconfig generates the following warning with this configuration:
Quoted 8 lines
WARNING: unmet direct dependencies detected for USB_XHCI_PLATFORM
Depends on [m]: USB_SUPPORT [=y] && USB [=y] && USB_XHCI_HCD [=y] && (USB_ONBOARD_HUB [=m] || !USB_ONBOARD_HUB [=m]) Selected by [y]:
- USB_DWC3 [=y] && USB_SUPPORT [=y] && (USB [=y] || USB_GADGET [=y]) && HAS_DMA [=y] && USB_XHCI_HCD [=y] Selected by [m]:
- USB_CDNS_SUPPORT [=m] && USB_SUPPORT [=y] && (USB [=y] || USB_GADGET [=y]) && HAS_DMA [=y] && USB_XHCI_HCD [=y]
- USB_BRCMSTB [=m] && USB_SUPPORT [=y] && USB [=y] && (ARCH_BRCMSTB [=y] && PHY_BRCM_USB [=m] || COMPILE_TEST [=y]) && USB_XHCI_HCD [=y]
- USB_XHCI_MVEBU [=m] && USB_SUPPORT [=y] && USB [=y] && USB_XHCI_HCD [=y] && HAS_IOMEM [=y] && (ARCH_MVEBU [=y] || COMPILE_TEST [=y])

Quoted 2 lines

It seems that Kconfig is confused by trying to enforce contradicting dependencies.

yep, the purpose of my post was to sort that out :)

Quoted 1 line

Now for your driver:

TBH I don't think this is the right thread to discuss the driver, this should be done on the corresponding patches.

Quoted 10 lines

If I understand it correctly, you've got a topology like this:
root hub -+--> 2ndary hub #0 -+--> usb-dev #0
          |                   \--> usb-dev #1
          |                     ..
          \--> 2ndary hub #1 -+--> usb-dev #3
                              \--> usb-dev #4

Quoted 4 lines

And in order to get usb-dev #foo running, you need the corresponding hub on its path powered (which in turn is platform specific).
Correct ?

yep

Quoted 8 lines

So, why not reflecting exactly this topology in the device tree ? In that case, the power management *IMHO* could pretty automatically (assuming you've implemented the corresponding pm functions on the 2ndary hub driver).
Okay, that could become a bit tricky when the usb-dev's are automatically enumerated on the root hub and would need to be reparented somehow ... @usb folks: it that possible ?

AFAIK the USB devices (including the secondary hubs) are all automatically enumerated, the representation in the device tree is optional in the vast majority of cases, so it's a bit of a chicken-egg problem.

Quoted 5 lines

Another option could be implementing this as a regulator that the individual usb devices will be attached to. Not completely semantically correct (since a hub isn't exactly a regulator :o), but should at least do the job: the regulator will be switched on when the device is used and can be switched off when it isn't used anymore.

IMO the representation as a hub is preferable, also initialization might be more complex than switching on a single regulator (e.g. multiple regulators, GPIOs, clocks, ...)

Quoted 6 lines

The cleanest approach, IMHO, might be adding an hub subsys, somewhat similar to the existing phy subsys. I can imagine similar cases with other interfaces, not just USB only, at least certainly not specific to xhci.
Or could existing phy subsys already be sufficient for that ?

I'll leave that to the USB maintainers, who seem to be happy/ok with the current approach. There was discussion about other solutions, including a revival of the pwrseq series
(https://lore.kernel.org/patchwork/project/lkml/list/?series=314989&state=%2A&archive=both),
which was discarded.

In any case the current solution isn't specific to xHCI. At this point only xhci-plat is supported, however it could be extended to other USB controllers if needed.