On Wed, Sep 27, 2017 at 05:34:04PM +0200, Maxime Ripard wrote: > On Wed, Sep 27, 2017 at 12:33:06PM +0000, Tom Rini wrote: > > On Wed, Sep 27, 2017 at 12:31:16PM +0200, Maxime Ripard wrote: > > > Hi Tom, > > > > > > Here is a pull request for the sunxi related changes for the next > > > U-Boot version. > > > > > > The diffstat is a bit scary, but mostly because of the Kconfig > > > migration of the USB ethernet related options, which were enabled by a > > > big number of boards. The fastboot options simplification is also one > > > of the offenders. > > > > > > This is my first pull request ever, so I might have done something > > > wrong, let me know if it's the case. > > > > Sorry, this is pretty broken: > > $ make O=/tmp/T sandbox_config > > make[1]: Entering directory `/tmp/T' > > GEN ./Makefile > > drivers/usb/Kconfig:1:error: recursive dependency detected! > > For a resolution refer to Documentation/kbuild/kconfig-language.txt > > subsection "Kconfig recursive dependency limitations" > > drivers/usb/Kconfig:1: symbol USB is selected by ARCH_SUNXI > > For a resolution refer to Documentation/kbuild/kconfig-language.txt > > subsection "Kconfig recursive dependency limitations" > > arch/arm/Kconfig:674: symbol ARCH_SUNXI is part of choice <choice> > > For a resolution refer to Documentation/kbuild/kconfig-language.txt > > subsection "Kconfig recursive dependency limitations" > > arch/arm/Kconfig:291: choice <choice> contains symbol ARCH_SUNXI > > For a resolution refer to Documentation/kbuild/kconfig-language.txt > > subsection "Kconfig recursive dependency limitations" > > arch/arm/Kconfig:674: symbol ARCH_SUNXI depends on USB_MUSB_GADGET > > For a resolution refer to Documentation/kbuild/kconfig-language.txt > > subsection "Kconfig recursive dependency limitations" > > drivers/usb/musb-new/Kconfig:11: symbol USB_MUSB_GADGET depends on > > USB > > Gah. Sorry for that. So much for slipping in a fix without testing > it... > > I wonder why it's considered a recursive dependency though. > > The situation seems to be: > > selects depends > ARCH_SUNXI --------> USB <--------- USB_MUSB_GADGET > | > +-------> USB_ETHER > implies > > USB_ETHER is implied only if USB_MUSB_GADGET is set, but that looks > like a directed graph without any loop, right? > > Or am I missing something?
implies is tricky, and I think it comes down to ARCH_SUNXI being under a choice. What I think we generally need to do here is use 'default y if ...' under things like USB_MUSB_GADGET instead of imply X if Y, under the ARCH_xxx choice and similar. An alternative that may, or may not, make sense would be mirroring TI_COMMON_CMD_OPTIONS from board/ti/common/Kconfig, where the intent there is that that TI-the-vendor wants a consistent experience on their various EVMs so that gets set to enable X/Y/Z, but a custom board based on a TI SoC might not want to enable all of that since it's not an EVM that wants the kitchen sink, so to speak. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
