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
On Sat, Jun 19, 2021 at 2:05 AM Matthias Kaehlcke <[email protected]> wrote:
>
> 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
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
On 18.06.21 19:05, Matthias Kaehlcke wrote:
Hi,
Cc'ing to linux-usb ...
> 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
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 ?
> 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])
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
--
---
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
On Sat, Jun 19, 2021 at 10:30:22AM +0900, Masahiro Yamada wrote:
> On Sat, Jun 19, 2021 at 2:05 AM Matthias Kaehlcke <[email protected]> wrote:
> >
> > 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
>
>
>
> 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.
> 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).
On Mon, Jun 21, 2021 at 01:26:01PM +0200, Enrico Weigelt, metux IT consult wrote:
> On 18.06.21 19:05, Matthias Kaehlcke wrote:
>
> Hi,
>
>
> Cc'ing to linux-usb ...
>
> > 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
>
> 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.
> > 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])
>
> It seems that Kconfig is confused by trying to enforce contradicting
> dependencies.
yep, the purpose of my post was to sort that out :)
> 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.
> 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 ?
yep
> 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.
> 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, ...)
> 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.
On Mon, Jun 21, 2021 at 07:55:30AM -0700, Matthias Kaehlcke wrote:
> On Sat, Jun 19, 2021 at 10:30:22AM +0900, Masahiro Yamada wrote:
> > On Sat, Jun 19, 2021 at 2:05 AM Matthias Kaehlcke <[email protected]> wrote:
> > >
> > > 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
> >
> >
> >
> > 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.
>
> > 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).
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