[U-Boot] [GIT PULL] u-boot-sunxi/master

[Tom Rini]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170927/bc30e912/attachment.sig>