Hi,
On Wed, Sep 27, 2017 at 03:45:20PM +0000, Tom Rini wrote:
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.
Yeah, I tested a similar option in parallel, and putting a default y if ARCH_SUNXI && USB_MUSB_GADGET under USB_ETHER work fine.
Would that work for you? I'll respin the pull request with this change if so.
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.
Yeah, we were also starting to think about it (mostly for tablets vs dev boards uses), but the discussion didn't really settle yet.
Thanks! Maxime