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

Maxime Ripard maxime.ripard at free-electrons.com
Wed Sep 27 15:55:31 UTC 2017


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.

> 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

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170927/d0bbda39/attachment.sig>


More information about the U-Boot mailing list