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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot