[U-Boot] [PATCH 0/2] spl: MMC U-Boot image load from raw partition
Tom Rini
trini at ti.com
Tue Nov 18 14:52:37 CET 2014
On Sat, Nov 15, 2014 at 09:27:20PM +0100, Albert ARIBAUD wrote:
> Hello Paul,
>
> On Thu, 13 Nov 2014 23:16:09 +0100, Paul Kocialkowski
> <contact at paulk.fr> wrote:
[snip]
> > Well I think it makes sense to not call this dead code as long as it
> > *can be* enabled and used on another supported board (for that matter,
> > any OMAP3+ board will indeed do).
>
> If no board is calling this code right now, that is because none needs
> it. If none needs it, then it has no reason to be added. The day some
> board needs this code, the patch to add this code can be submitted
> along with the patch that calls this code.
>
> > This is very different from e.g. the regulator code that I submitted,
> > which is only relevant for devices with that particular piece of
> > hardware (so far, none supported by U-Boot). So it makes sense to submit
> > that regulator patch only along with support for a board that uses it.
>
> I don't see the difference.
But this is where I see a difference, "tomorrow". Setting this, or not
setting this new behavior is a Kconfig "choice" (in Kconfig-speak). We
do not need a defconfig in-tree for every single possible choice since
at some point we'll do like other Kconfig-based projects and have
randconfig builds possible to cover "odd" choices, along with
allyesconfig and allnoconfig to cover the things which people clearly
need _somewhere_ (and feel the (good!) need to post them in public to
help others) but may not be able to post the whole board port (not the
case here per-se but see the various RTC drivers that get posted from
time to time).
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141118/2085f454/attachment.pgp>
More information about the U-Boot
mailing list