Hi Mark,
On Mon, 30 Jan 2023 at 08:18, Mark Kettenis mark.kettenis@xs4all.nl wrote:
Date: Mon, 30 Jan 2023 09:52:52 -0500 From: Tom Rini trini@konsulko.com
On Mon, Jan 30, 2023 at 03:50:23PM +0100, Heinrich Schuchardt wrote:
On 1/30/23 15:40, Simon Glass wrote:
This is implicitly used in the source and seems useful, so add it.
Please, provide a clear description how this will be used.
To follow up on what I just sent, Simon seems to be taking a pass at adding to Kconfig many / most of the options that aren't available today but are implied by the usage of CONFIG_IS_ENABLED(FOO). So, this is another case where IS_ENABLED(CONFIG_FOO) should be used.
Hi Tom, Simon,
I fear we have a documentation/communication/naming issue here. Before Simon pointed out an issue to me in the s5p serial driver my mential picture of this was:
#if -> CONFIG_IS_ENABLED(FOO)
if () -> IS_ENABLED(CONFIG_FOO)
possibly because that's the pattern you see if you grep the source code (IS_ENABLED(CONFIG_FOO) is rarely used with preprocessor conditionals). And that makes me think I'm not the only developer that got this wrong.
After I realized that the purpose of CONFIG_IS_ENABLED(FOO) is to cover TPL, SPL and U-Boot proper with a single condition it was fairly obvious to me that there are many, many cases where IS_ENABLED(CONFIG_FOO) should be used instead.
And I fear Simon's series only makes it harder to fix that. Right now you can easily see that CONFIG_IS_ENABLED(FOO) is probably the wrong construction since no CONFIG_TPL_FOO and CONFIG_SPL_FOO Kconfig symbols exist.
Not after this series, though. You can use 'move_config.py --scan-source -l' to check that.
Regards, Simon