Hello Tom,
On Tue, 18 Nov 2014 08:52:37 -0500, Tom Rini trini@ti.com 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 contact@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).
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,