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

[Tom Rini <trini@konsulko.com>]

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.

> 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.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200610/647cddd5/attachment.sig>