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

[Patrick DELAUNAY]

Hi,

> From: Tom Rini <trini at 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).

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).

Regards

Patrick