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 dependsARCH_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.