From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 10 Jun 2020 18:17:47 -0400 Subject: [PATCH] net: dwc_eth_qos: add Kconfig option to select supported configuration In-Reply-To: <7db25e91-a2ad-26d8-2fb9-f65ea7db0bce@denx.de> References: <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> <20200610215737.GO24893@bill-the-cat> <7db25e91-a2ad-26d8-2fb9-f65ea7db0bce@denx.de> Message-ID: <20200610221747.GQ24893@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 Thu, Jun 11, 2020 at 12:02:08AM +0200, Marek Vasut wrote: > On 6/10/20 11:57 PM, Tom Rini wrote: > [...] > > >> 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. > > I don't want to resolve these problems one-by-one , the obvious solution > for them AND the growth of Kconfig files with multiple copies of the > same symbol for SPL/TPL/U-Boot is the have Kconfig generate those > symbols automatically for SPL/TPL/U-Boot and then let user pick the > configuration as needed. That would make the undefs in > include/configs/board.h go away easily and would reduce the duplication > in Kconfig files. I strongly disagree that having two or three times the number of symbols to select from will result in a better outcome. I see 386 SPL_ '^config ' lines (of which a number are 'default y' lines) and that's more than I thought there would be. There's also 6175 overall symbols today. I would be hopeful that the "lets look at the DTS files and see what we can tell about a platform" thread could help with configuring a good binary better. Because to me the worrisome entries are things like MMC_HS200_SUPPORT / SPL_MMC_HS200_SUPPORT as I would start by asking if the cases where we don't enable that in SPL are intention or oversight. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: