From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 10 Jun 2020 17:57:37 -0400 Subject: [PATCH] net: dwc_eth_qos: add Kconfig option to select supported configuration In-Reply-To: <0b8142d8-2375-ee8f-515d-680f8e93beed@denx.de> References: <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> <20200610213522.GM24893@bill-the-cat> <0b8142d8-2375-ee8f-515d-680f8e93beed@denx.de> Message-ID: <20200610215737.GO24893@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 11:40:33PM +0200, Marek Vasut wrote: > On 6/10/20 11:35 PM, Tom Rini wrote: > > 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 think I don't understand this part. You're talking about a binary that runs on more than one dissimilar SoC, yes? > > 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. > > This patch is OK as-is. Yes, since I'm no longer asking for changes to it, it's fine. > My point is more in the general direction of being able to configure > SPL/TPL/U-Boot separately, without being forced to craft nasty ifdeffery > in include/config/board.h if I need something enabled in SPL, but not in > U-Boot, and vice versa. And for that the Kconfig should be able to > somehow emit the _SPL/_TPL/U-Boot options of all symbols I think, so > that we won't need separate entry for each. I haven't seen a case where the nasty ifdeffery in a config header file wasn't basically either: - Now wrong (we _have_ the symbols today to say we don't want X in SPL) - Working around a case where we need to use $(SPL_TPL_) somewhere but didn't know that we could use $(SPL_TPL_) to fix the problem instead. - Now not useful (for example, disable CMD_xxx for SPL, but we've really sorted things out so now so doing that didn't help anything). Now I'm happy to admit that I just might be missing a case as I've only gotten as far as "undef CONFIG_[ABC]" and BOOTCOMMAND is possibly leading to embedding a long string where we really don't want it. Please point me at more undef cases that need to be resolved in some way. Thanks! -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: