From: Matthias Kaehlcke <mka@chromium.org>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Douglas Anderson <dianders@chromium.org>
Subject: Re: Looking for help with Kconfig dependencies
Date: Tue, 22 Jun 2021 16:49:36 -0700 [thread overview]
Message-ID: <YNJ3EBDSbqfT/sAk@google.com> (raw)
In-Reply-To: <YNCoYnurpk64+jlF@google.com>
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 <mka@chromium.org> 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
next prev parent reply other threads:[~2021-06-22 23:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-18 17:05 Looking for help with Kconfig dependencies Matthias Kaehlcke
2021-06-19 1:30 ` Masahiro Yamada
2021-06-21 14:55 ` Matthias Kaehlcke
2021-06-22 23:49 ` Matthias Kaehlcke [this message]
2021-06-21 11:26 ` Enrico Weigelt, metux IT consult
2021-06-21 15:35 ` Matthias Kaehlcke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YNJ3EBDSbqfT/sAk@google.com \
--to=mka@chromium.org \
--cc=dianders@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox