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 16:54:44 -0400 [thread overview]
Message-ID: <20200610205444.GK24893@bill-the-cat> (raw)
In-Reply-To: <a3f20f91-fecb-81ed-6eb7-5070574f2c64@denx.de>
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.
--
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/34a1515a/attachment.sig>
next prev parent reply other threads:[~2020-06-10 20:54 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 [this message]
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
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=20200610205444.GK24893@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