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

[Tom Rini]

On Wed, Sep 27, 2017 at 05:55:31PM +0200, Maxime Ripard wrote:
> 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        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.
> 
> 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.

That's fine, thanks!

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

OK.

-- 
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/8dbf539c/attachment.sig>