From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Tue, 18 Nov 2014 21:34:00 +0100 Subject: [U-Boot] [PATCH 0/2] spl: MMC U-Boot image load from raw partition In-Reply-To: <20141118135237.GX21184@bill-the-cat> References: <1415484896-28928-1-git-send-email-contact@paulk.fr> <20141108231923.243bf07a@lilith> <20141110184609.GX24724@bill-the-cat> <20141113121601.7177bdb4@lilith> <1415916969.2372.10.camel@collins> <20141115212720.4ae35619@lilith> <20141118135237.GX21184@bill-the-cat> Message-ID: <20141118213400.7d36384f@lilith> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Tom, On Tue, 18 Nov 2014 08:52:37 -0500, Tom Rini wrote: > 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 > > 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). I still don't agree, as a Kconfig option is no different from any other addition, so I consider that we should only introduce a Kconfig choice because/when it is needed, not just because it could be needed; but you're the boss. > -- > Tom Amicalement, -- Albert.