From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Wed, 10 Jun 2020 23:40:33 +0200 Subject: [PATCH] net: dwc_eth_qos: add Kconfig option to select supported configuration In-Reply-To: <20200610213522.GM24893@bill-the-cat> 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> <20200610213522.GM24893@bill-the-cat> Message-ID: <0b8142d8-2375-ee8f-515d-680f8e93beed@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. > 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. 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.