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

[Marek Vasut <marex@denx.de>]

On 6/11/20 3:44 PM, Patrick DELAUNAY wrote:
> Hi,
> 
>> From: Tom Rini <trini@konsulko.com>
>> Sent: mercredi 10 juin 2020 23:58
>>
>> 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.
> 
> I don't see possible use case where the 3 drivers configurations can be activated at the same time, 
> Except, as Marek indicated it, the same U-Boot binary compiled to be executed for several architecture
> (STM32, IMX, TEGRA).
> 
> But it is not possible (duplicate cote between arch)  as each configuration is linked to archictecture variant 
> (the synopsis IP is modified by SOC vendor).

You can build Linux for all three and use the same zImage, so it should
also be possible for U-Boot.

> For me it should be possible to change the config option to select,
> even it is no more requested and the patch is OK as-is (I keep the possibility to have the 3 options activated).

The patch is OK.