From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 10 Jun 2020 17:35:22 -0400 Subject: [PATCH] net: dwc_eth_qos: add Kconfig option to select supported configuration In-Reply-To: References: <20200610181019.GE24893@bill-the-cat> <9f331ffe-b156-8add-e098-69908b80cebf@denx.de> <20200610185218.GH24893@bill-the-cat> <552c2b40-7aaf-c015-ca49-ef14ae6ac905@denx.de> <20200610185851.GI24893@bill-the-cat> <20200610201148.GJ24893@bill-the-cat> <20200610205444.GK24893@bill-the-cat> Message-ID: <20200610213522.GM24893@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wed, Jun 10, 2020 at 10:56:40PM +0200, Marek Vasut wrote: > On 6/10/20 10:54 PM, Tom Rini wrote: > > On Wed, Jun 10, 2020 at 10:46:23PM +0200, Marek Vasut wrote: > >> On 6/10/20 10:11 PM, Tom Rini wrote: > >> [...] > >>>>>>> You mean be more like barebox and Linux where the board-specific stuff > >>>>>>> is kicked up one level and we have a more generic binary? I don't know > >>>>>>> and there's so much work that would be required before having to move > >>>>>>> this from a Kconfig choice to just Kconfig options I don't see that as > >>>>>>> being a relevant question here. > >>>>>>> > >>>>>>> Or did I misunderstand the question? > >>>>>> > >>>>>> More like automatically have a Kconfig option generate it's _SPL and > >>>>>> _TPL variant. > >>>>> > >>>>> Ah. Well, that is rephrasing my first question. Would it ever make > >>>>> sense to have more than one of these enabled? > >>>> > >>>> For some sort of universal SPL, maybe ? > >>> > >>> So no, there's not a reason today then and it should be a choice. > >> > >> Can you provide some more detailed explanation why we shouldn't generate > >> _SPL and _TPL variants of Kconfig entries for all Kconfig entries ? It > >> would make things much simpler and permit configuring SPL/TPL the same > >> way U-Boot is configured, with their own set of options. > > > > In the context of this particular thread? I don't see how it's helpful > > to say 3 times that we're in fact building for Tegra or STM32 or SoCFPGA > > when you can't build something that runs on more than one of those. > > In general. > > Here I can imagine it is possible to build SoCFPGA+STM32 universal SD > card image in fact. So that's the case I brought up at first and you said no to. I don't see that in the foreseeable future but I don't feel so strongly about making this config area tidy enough to argue the point. So fine, leave it as separate options, the default y if ... is reasonable enough to ensure we get functional builds. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: