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

[Marek Vasut <marex@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.