[U-Boot] [PATCH v4 00/19] sunxi: sync H3, H5, A64 DTs from mainline Linux

From: Maxime Ripard <maxime.ripard@bootlin.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v4 00/19] sunxi: sync H3, H5, A64 DTs from mainline Linux
Date: Thu, 29 Mar 2018 11:30:55 +0200	[thread overview]
Message-ID: <20180329093055.gbmligwxgyarl2pn@flea> (raw)
In-Reply-To: <22104532-6ed7-d2cd-4292-9795525af3a5@arm.com>

Hi,

Replying to one part of the mail only, since I agree with everything
else.

On Thu, Mar 29, 2018 at 10:19:22AM +0100, Andre Przywara wrote:
> > What I'm trying to say is we should anyway sync to Linux bindings and
> > dts files, but that could be like step-by-step based on the relevant
> > driver support with proper testing this way we can monitor the "Size"
> > instead of adding unneeded(for now) and untested once now struggling
> > to think about size constraints later.
> 
> I hope we will never have to deal with hard size constraint for U-Boot
> proper anymore. I would like to judge any increase in size by its
> benefit. And booting random UEFI enabled OSes out of the box is a very
> good rationale for adding 10KB to the image size.
> 
> Keep in mind: Eventually you have to load this DT anyway, so effectively
> you will save on the image size, because you avoid duplication. Actually
> the OS does not need to carry all supported DTs, because the only one
> needed is provided by U-Boot.

I really don't have to deal with it ever again as well, and I really
think we'll need to pay more attention to whatever we'll be merging
that would enable any option.

Given the current craze that everyone thinks their new Kconfig option
is so awesome that everyone must want it, that's probably going to be
a bit hard to achieve, but if we have a patch coming our way that
enables something that is already covered by an option we have, we
must say no.

A pretty good example would be for example in our current case why do
we have DFU and fastboot enabled, while both cover pretty much the
same usecase. Or why do we have USB gadget mass storage support on by
default, while most of the users probably will never use it.

Of course, those options are in, so we can't really remove them now,
especially without any strong incentive. But we can prevent any
uneeded option from creeping in in the future.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180329/3157a6c5/attachment.sig>