public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [PATCH] net: dwc_eth_qos: add Kconfig option to select supported configuration
Date: Wed, 10 Jun 2020 18:17:47 -0400	[thread overview]
Message-ID: <20200610221747.GQ24893@bill-the-cat> (raw)
In-Reply-To: <7db25e91-a2ad-26d8-2fb9-f65ea7db0bce@denx.de>

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.

-- 
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/84b93f8c/attachment.sig>

  reply	other threads:[~2020-06-10 22:17 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-08  9:27 [PATCH] net: dwc_eth_qos: add Kconfig option to select supported configuration Patrick Delaunay
2020-06-10 18:10 ` Tom Rini
2020-06-10 18:42   ` Marek Vasut
2020-06-10 18:52     ` Tom Rini
2020-06-10 18:55       ` Marek Vasut
2020-06-10 18:58         ` Tom Rini
2020-06-10 19:01           ` Marek Vasut
2020-06-10 20:11             ` Tom Rini
2020-06-10 20:46               ` Marek Vasut
2020-06-10 20:54                 ` Tom Rini
2020-06-10 20:56                   ` Marek Vasut
2020-06-10 21:35                     ` Tom Rini
2020-06-10 21:40                       ` Marek Vasut
2020-06-10 21:57                         ` Tom Rini
2020-06-10 22:02                           ` Marek Vasut
2020-06-10 22:17                             ` Tom Rini [this message]
2020-06-10 22:32                               ` Marek Vasut
2020-06-11 13:44                           ` Patrick DELAUNAY
2020-06-11 16:42                             ` Marek Vasut
2020-08-05 20:26 ` Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200610221747.GQ24893@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox