[PATCH] net: dwc_eth_qos: add Kconfig option to select supported configuration

[Marek Vasut]

On 6/11/20 12:17 AM, Tom Rini wrote:
> 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.

Surely HS200 (and HS400/SDR104/UHS) , which wastes _A_LOT_ of boot time
and a lot of space, is a good candidate for something to be disabled in SPL.

Some core platform-specific symbols are fine with not having matching
_SPL/_TPL counterpart, sure, but that's not the majority of the Kconfig
symbols, right? Or maybe we need some new Kconfig keyword (instead of
'config') to describe symbols which do need _SPL/_TPL variants ?