[U-Boot] [PATCH 12/16] configs: sun50i: enable ums on bananapi-m64

[Maxime Ripard]

Hi,

On Tue, Dec 12, 2017 at 02:39:59PM +0530, Jagan Teki wrote:
> On Tue, Dec 12, 2017 at 1:42 PM, Maxime Ripard
> <maxime.ripard at free-electrons.com> wrote:
> > Hi,
> >
> > On Tue, Dec 12, 2017 at 12:28:27PM +0530, Jagan Teki wrote:
> >> This patch enable ums through CMD_USB_MASS_STORAGE.
> >>
> >> Signed-off-by: Jagan Teki <jagan at amarulasolutions.com>
> >> ---
> >>  configs/bananapi_m64_defconfig | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/configs/bananapi_m64_defconfig b/configs/bananapi_m64_defconfig
> >> index 55feafe..d4aade5 100644
> >> --- a/configs/bananapi_m64_defconfig
> >> +++ b/configs/bananapi_m64_defconfig
> >> @@ -11,6 +11,7 @@ CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-bananapi-m64"
> >>  CONFIG_SPL=y
> >>  # CONFIG_CMD_FLASH is not set
> >>  # CONFIG_CMD_FPGA is not set
> >> +CONFIG_CMD_USB_MASS_STORAGE=y
> >
> > How does that work with the current over-size issue we have on the
> > A64?
> >
> > And I'd also like to keep the way we did things for several years now,
> > which is to *not* have board-specific options selected besides the
> > hardware-related ones.
> >
> > If you want to enable a general feature, do it for all the boards so
> > that our users will have a consistent experience across boards, and we
> > will not have to always chase all the defconfigs to provide it.
> 
> I always believe test-proven even it is general feature there may be
> changes it may(not) work on all boards. Once the relevant boards have
> needed it and then it will anyway added.

And this leads to inconsistencies across boards in the features they
support, which in turn lead to downstream users being unable to rely
on one particular feature being enabled. And really, this is what
we've doing all along.

> > And I guess the next question would be: what is the targetted use case
> > and why should we enable it for all the boards? We're having binary
> > size issues on the A64, so we really want to provide something
> > meaningful for the majority of our users.
> >
> > We won't enable something used by only a small fraction, especially
> > when it's so easy to enable it.
> 
> Yes, this was tested on this board and it is working. the use-case
> I've seen to upgrade the target partitioned-disk directly from host
> instead of plug-and-play every time and especially with eMMC.

We already have DFU and fastboot to cover that. Do we really need to
have a third option when we already have size issues in our binary?

Really, if someone uses it, then yeah, we should make it as convenient
as possible to enable it. But since it's just one option to check,
what's the point?

That's also why we have Kconfig after all.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.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/20171213/fdea2d2c/attachment.sig>