All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.