On Wed, Mar 02, 2016 at 05:25:27PM -0700, Simon Glass wrote: > Hi, > > On 29 February 2016 at 16:56, Tom Rini <tr...@konsulko.com> wrote: > > On Mon, Feb 29, 2016 at 04:47:19PM -0700, Stephen Warren wrote: > >> On 02/25/2016 09:00 PM, Simon Glass wrote: > >> >Some features are only useful or meaningful when the command line is > >> >present. Ensure that these features are not compiled in when > >> >CONFIG_CMDLINE > >> >is not enabled. > >> > >> How does this series affect the various code that executes other > >> U-Boot functionality by executing commands rather than calling > >> functions? For instance, drivers/dfu/dfu_mmc.c:mmc_file_op() calls > >> run_command() to perform the actual disk I/O. I assume that is > >> incompatible with enabling this new feature? If so, can Kconfig > >> enforce that? > > > > This is what I was trying to get at as well. We may have to initially > > say that some stuff is dependent on CMDLINE || BROKEN or something as we > > have some even funkier cases for some FSL DDR things. > > Yes, it will break it. I'd like to think we can move to cleaning this > stuff up though. > > IMO mmc_file_op() is wrong. It should work using function calls, not > through the command-line interface. Perhaps that is hard today, and > will get easier with driver model?
The DFU case at least was certainly more ugly at the time when doing function calls, yes. And to start with it's not a big deal to mark some things (even whole SoCs) as requiring CMDLINE. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
