| Message ID | 1456459256-32643-10-git-send-email-sjg@chromium.org |
|---|---|
| State | Accepted |
| Commit | 9a6598daaf0d0681bd423196364b2e4e3959ebbc |
| Delegated to: | Tom Rini |
| Headers | show |
On Thu, Feb 25, 2016 at 09:00:56PM -0700, 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. > > Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
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?
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.
Hi, On 29 February 2016 at 16:56, Tom Rini <trini@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? Regards, Simon
On Wed, Mar 02, 2016 at 05:25:27PM -0700, Simon Glass wrote: > Hi, > > On 29 February 2016 at 16:56, Tom Rini <trini@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.
diff --git a/include/config_fallbacks.h b/include/config_fallbacks.h index ddfe045..6b6ec00 100644 --- a/include/config_fallbacks.h +++ b/include/config_fallbacks.h @@ -97,4 +97,14 @@ # endif #endif +#ifndef CONFIG_CMDLINE +#undef CONFIG_CMDLINE_EDITING +#undef CONFIG_SYS_LONGHELP +#undef CONFIG_CMD_BOOTD +#undef CONFIG_CMD_RUN +#undef CONFIG_SYS_HUSH_PARSER +#undef CONFIG_CMD_ASKENV +#undef CONFIG_MENU +#endif + #endif /* __CONFIG_FALLBACKS_H */
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. Signed-off-by: Simon Glass <sjg@chromium.org> --- include/config_fallbacks.h | 10 ++++++++++ 1 file changed, 10 insertions(+)