| Message ID | 20230129005903.74918-10-sjg@chromium.org |
|---|---|
| State | Superseded |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | Clean up of bad Kconfig options | expand |
On 29/01/2023 01.57, Simon Glass wrote:
> CONFIG options must not use lower-case letter.
Why?
Rasmus
On Sun, Jan 29, 2023 at 10:57:28PM +0100, Rasmus Villemoes wrote: > On 29/01/2023 01.57, Simon Glass wrote: > > CONFIG options must not use lower-case letter. > > Why? So, kconfiglib complains about these. However, I can't find a formal language definition and the kernel documentation doesn't specify, merely imply that it should always be all uppercase. Further, I see now that IS_REACHABLE is a kconfig macro, that would cover our usage of IS_ENABLED.
On 30/01/2023 16.54, Tom Rini wrote: > On Sun, Jan 29, 2023 at 10:57:28PM +0100, Rasmus Villemoes wrote: >> On 29/01/2023 01.57, Simon Glass wrote: >>> CONFIG options must not use lower-case letter. >> >> Why? > > So, kconfiglib complains about these. Which IMO would be a bug in kconfiglib. Can you point me at where that warning is in kconfiglib.py and how it looks and when one would encounter it? > However, I can't find a formal > language definition and the kernel documentation doesn't specify, merely > imply that it should always be all uppercase. Well, yes, mostly, but since the de facto specification (namely, the kernel's implementation) doesn't complain and the kernel's Kconfig files do contain several examples of config symbols with lowercase characters, why deviate? In particular, since we share a lot of code, if some piece of kernel code has an IS_ENABLED(CONFIG_FOO876xx), why make it harder to import and keep that in sync? Perhaps we can get Masahiro to tell us whether lowercase characters are allowed in kconfig symbols or not. For reference, another kconfig-using project decided to fix their own infrastructure around kconfig instead of enforcing uppercase symbols: https://github.com/zephyrproject-rtos/zephyr/issues/40420 Rasmus
On Mon, Jan 30, 2023 at 10:12:19PM +0100, Rasmus Villemoes wrote: > On 30/01/2023 16.54, Tom Rini wrote: > > On Sun, Jan 29, 2023 at 10:57:28PM +0100, Rasmus Villemoes wrote: > >> On 29/01/2023 01.57, Simon Glass wrote: > >>> CONFIG options must not use lower-case letter. > >> > >> Why? > > > > So, kconfiglib complains about these. > > Which IMO would be a bug in kconfiglib. Can you point me at where that > warning is in kconfiglib.py and how it looks and when one would > encounter it? > > > However, I can't find a formal > > language definition and the kernel documentation doesn't specify, merely > > imply that it should always be all uppercase. > > Well, yes, mostly, but since the de facto specification (namely, the > kernel's implementation) doesn't complain and the kernel's Kconfig files > do contain several examples of config symbols with lowercase characters, > why deviate? In particular, since we share a lot of code, if some piece > of kernel code has an IS_ENABLED(CONFIG_FOO876xx), why make it harder to > import and keep that in sync? > > Perhaps we can get Masahiro to tell us whether lowercase characters are > allowed in kconfig symbols or not. > > For reference, another kconfig-using project decided to fix their own > infrastructure around kconfig instead of enforcing uppercase symbols: > > https://github.com/zephyrproject-rtos/zephyr/issues/40420 I think it would be very good if the kconfig language itself declared what does and does not make up a valid symbol. Note that the only thing complaining in U-Boot today is kconfiglib using tools.
Hi Rasmus, On Mon, 30 Jan 2023 at 14:12, Rasmus Villemoes <rasmus.villemoes@prevas.dk> wrote: > > On 30/01/2023 16.54, Tom Rini wrote: > > On Sun, Jan 29, 2023 at 10:57:28PM +0100, Rasmus Villemoes wrote: > >> On 29/01/2023 01.57, Simon Glass wrote: > >>> CONFIG options must not use lower-case letter. > >> > >> Why? > > > > So, kconfiglib complains about these. > > Which IMO would be a bug in kconfiglib. Can you point me at where that > warning is in kconfiglib.py and how it looks and when one would > encounter it? > > > However, I can't find a formal > > language definition and the kernel documentation doesn't specify, merely > > imply that it should always be all uppercase. > > Well, yes, mostly, but since the de facto specification (namely, the > kernel's implementation) doesn't complain and the kernel's Kconfig files > do contain several examples of config symbols with lowercase characters, > why deviate? In particular, since we share a lot of code, if some piece > of kernel code has an IS_ENABLED(CONFIG_FOO876xx), why make it harder to > import and keep that in sync? > > Perhaps we can get Masahiro to tell us whether lowercase characters are > allowed in kconfig symbols or not. > > For reference, another kconfig-using project decided to fix their own > infrastructure around kconfig instead of enforcing uppercase symbols: > > https://github.com/zephyrproject-rtos/zephyr/issues/40420 That's all good context, thank you. When we use #define it is normally with an upper-case string. The is the convention in U-Boot and Linux (and many other projects), I believe. Also, having lower and upper case strings does become confusing, and inconsistent. I was unaware that lower-case was allowed in Linux. It seems there are 35 cases of this in Linux. I'm not sure if any is intended. But perhaps we should not allow it in U-Boot? Regards, Simon
On 31/01/2023 15.16, Simon Glass wrote: > Hi Rasmus, > > On Mon, 30 Jan 2023 at 14:12, Rasmus Villemoes > <rasmus.villemoes@prevas.dk> wrote: >> >> On 30/01/2023 16.54, Tom Rini wrote: >>> On Sun, Jan 29, 2023 at 10:57:28PM +0100, Rasmus Villemoes wrote: >>>> On 29/01/2023 01.57, Simon Glass wrote: >>>>> CONFIG options must not use lower-case letter. >>>> >>>> Why? >>> >>> So, kconfiglib complains about these. >> >> Which IMO would be a bug in kconfiglib. Can you point me at where that >> warning is in kconfiglib.py and how it looks and when one would >> encounter it? >> >>> However, I can't find a formal >>> language definition and the kernel documentation doesn't specify, merely >>> imply that it should always be all uppercase. >> >> Well, yes, mostly, but since the de facto specification (namely, the >> kernel's implementation) doesn't complain and the kernel's Kconfig files >> do contain several examples of config symbols with lowercase characters, >> why deviate? In particular, since we share a lot of code, if some piece >> of kernel code has an IS_ENABLED(CONFIG_FOO876xx), why make it harder to >> import and keep that in sync? >> >> Perhaps we can get Masahiro to tell us whether lowercase characters are >> allowed in kconfig symbols or not. >> >> For reference, another kconfig-using project decided to fix their own >> infrastructure around kconfig instead of enforcing uppercase symbols: >> >> https://github.com/zephyrproject-rtos/zephyr/issues/40420 > > That's all good context, thank you. > > When we use #define it is normally with an upper-case string. The is > the convention in U-Boot and Linux (and many other projects), I > believe. I don't disagree with the "normally", but that very word is precisely my point: It's not universal, and there can be good reasons to deviate. Both projects frown upon camelcase, so you don't see a lot of mixed-case macros, but there's definitely a lot of all-lowercase ones (e.g. iterators), and to pick just one example of a justified mixed-case one, there's a "#define RANGE_mA" in some iio device. Also, having lower and upper case strings does become > confusing, and inconsistent. > > I was unaware that lower-case was allowed in Linux. It seems there are > 35 cases of this in Linux. Dunno how you reach that number, I can easily find 174. Among them stuff like "config FONT_6x11" which is definitely more readable than with an uppercase X. But yes, either way it's a very small fraction of all config symbols, but OTOH I highly doubt linux would accept patches to start renaming those without a very strong reason - it would break out-of-tree defconfig files. > But perhaps we should not allow it in U-Boot? Discourage, definitely, perhaps even add something to checkpatch. But renaming existing seems to be pointless churn, and definitely needs a better rationale than "is not allowed" when that is manifestly not true. Maybe prepend a patch updating codingstyle.rst and amend this to say "is not allowed by the U-Boot coding standard". Or otherwise please provide some reference answering my "why". Rasmus
On Wed, Feb 01, 2023 at 01:19:51PM +0100, Rasmus Villemoes wrote: > On 31/01/2023 15.16, Simon Glass wrote: > > Hi Rasmus, > > > > On Mon, 30 Jan 2023 at 14:12, Rasmus Villemoes > > <rasmus.villemoes@prevas.dk> wrote: > >> > >> On 30/01/2023 16.54, Tom Rini wrote: > >>> On Sun, Jan 29, 2023 at 10:57:28PM +0100, Rasmus Villemoes wrote: > >>>> On 29/01/2023 01.57, Simon Glass wrote: > >>>>> CONFIG options must not use lower-case letter. > >>>> > >>>> Why? > >>> > >>> So, kconfiglib complains about these. > >> > >> Which IMO would be a bug in kconfiglib. Can you point me at where that > >> warning is in kconfiglib.py and how it looks and when one would > >> encounter it? > >> > >>> However, I can't find a formal > >>> language definition and the kernel documentation doesn't specify, merely > >>> imply that it should always be all uppercase. > >> > >> Well, yes, mostly, but since the de facto specification (namely, the > >> kernel's implementation) doesn't complain and the kernel's Kconfig files > >> do contain several examples of config symbols with lowercase characters, > >> why deviate? In particular, since we share a lot of code, if some piece > >> of kernel code has an IS_ENABLED(CONFIG_FOO876xx), why make it harder to > >> import and keep that in sync? > >> > >> Perhaps we can get Masahiro to tell us whether lowercase characters are > >> allowed in kconfig symbols or not. > >> > >> For reference, another kconfig-using project decided to fix their own > >> infrastructure around kconfig instead of enforcing uppercase symbols: > >> > >> https://github.com/zephyrproject-rtos/zephyr/issues/40420 > > > > That's all good context, thank you. > > > > When we use #define it is normally with an upper-case string. The is > > the convention in U-Boot and Linux (and many other projects), I > > believe. > > I don't disagree with the "normally", but that very word is precisely my > point: It's not universal, and there can be good reasons to deviate. > Both projects frown upon camelcase, so you don't see a lot of mixed-case > macros, but there's definitely a lot of all-lowercase ones (e.g. > iterators), and to pick just one example of a justified mixed-case one, > there's a "#define RANGE_mA" in some iio device. > > Also, having lower and upper case strings does become > > confusing, and inconsistent. > > > > I was unaware that lower-case was allowed in Linux. It seems there are > > 35 cases of this in Linux. > > Dunno how you reach that number, I can easily find 174. Among them stuff > like "config FONT_6x11" which is definitely more readable than with an > uppercase X. But yes, either way it's a very small fraction of all > config symbols, but OTOH I highly doubt linux would accept patches to > start renaming those without a very strong reason - it would break > out-of-tree defconfig files. > > > But perhaps we should not allow it in U-Boot? > > Discourage, definitely, perhaps even add something to checkpatch. But > renaming existing seems to be pointless churn, and definitely needs a > better rationale than "is not allowed" when that is manifestly not true. > > Maybe prepend a patch updating codingstyle.rst and amend this to say "is > not allowed by the U-Boot coding standard". Or otherwise please provide > some reference answering my "why". I suspect the answer here is that we should: - Patch (and submit upstream) kconfiglib.py to accept lowercase [a-z] as valid symbol names, as they are. - Add a sentence or two to codingstyle.rst about discouraging lowercase, as suggested by Rasmus - Drop the rename parts of this series.
Hi, On Wed, 1 Feb 2023 at 08:48, Tom Rini <trini@konsulko.com> wrote: > > On Wed, Feb 01, 2023 at 01:19:51PM +0100, Rasmus Villemoes wrote: > > On 31/01/2023 15.16, Simon Glass wrote: > > > Hi Rasmus, > > > > > > On Mon, 30 Jan 2023 at 14:12, Rasmus Villemoes > > > <rasmus.villemoes@prevas.dk> wrote: > > >> > > >> On 30/01/2023 16.54, Tom Rini wrote: > > >>> On Sun, Jan 29, 2023 at 10:57:28PM +0100, Rasmus Villemoes wrote: > > >>>> On 29/01/2023 01.57, Simon Glass wrote: > > >>>>> CONFIG options must not use lower-case letter. > > >>>> > > >>>> Why? > > >>> > > >>> So, kconfiglib complains about these. > > >> > > >> Which IMO would be a bug in kconfiglib. Can you point me at where that > > >> warning is in kconfiglib.py and how it looks and when one would > > >> encounter it? > > >> > > >>> However, I can't find a formal > > >>> language definition and the kernel documentation doesn't specify, merely > > >>> imply that it should always be all uppercase. > > >> > > >> Well, yes, mostly, but since the de facto specification (namely, the > > >> kernel's implementation) doesn't complain and the kernel's Kconfig files > > >> do contain several examples of config symbols with lowercase characters, > > >> why deviate? In particular, since we share a lot of code, if some piece > > >> of kernel code has an IS_ENABLED(CONFIG_FOO876xx), why make it harder to > > >> import and keep that in sync? > > >> > > >> Perhaps we can get Masahiro to tell us whether lowercase characters are > > >> allowed in kconfig symbols or not. > > >> > > >> For reference, another kconfig-using project decided to fix their own > > >> infrastructure around kconfig instead of enforcing uppercase symbols: > > >> > > >> https://github.com/zephyrproject-rtos/zephyr/issues/40420 > > > > > > That's all good context, thank you. > > > > > > When we use #define it is normally with an upper-case string. The is > > > the convention in U-Boot and Linux (and many other projects), I > > > believe. > > > > I don't disagree with the "normally", but that very word is precisely my > > point: It's not universal, and there can be good reasons to deviate. > > Both projects frown upon camelcase, so you don't see a lot of mixed-case > > macros, but there's definitely a lot of all-lowercase ones (e.g. > > iterators), and to pick just one example of a justified mixed-case one, > > there's a "#define RANGE_mA" in some iio device. > > > > Also, having lower and upper case strings does become > > > confusing, and inconsistent. > > > > > > I was unaware that lower-case was allowed in Linux. It seems there are > > > 35 cases of this in Linux. > > > > Dunno how you reach that number, I can easily find 174. Among them stuff Yes I was missing an underscore. git grep -E "CONFIG_([A-Za-z0-9_]*)\b" |sed -n "s/.*\bCONFIG_\([A-Za-z0-9_]*\)\b.*/\1/p" | sort |uniq | grep "[a-z]" |wc -l 187 But some are not real. > > like "config FONT_6x11" which is definitely more readable than with an > > uppercase X. But yes, either way it's a very small fraction of all > > config symbols, but OTOH I highly doubt linux would accept patches to > > start renaming those without a very strong reason - it would break > > out-of-tree defconfig files. FONT_6X11 isn't that bad :-) > > > > > But perhaps we should not allow it in U-Boot? > > > > Discourage, definitely, perhaps even add something to checkpatch. But > > renaming existing seems to be pointless churn, and definitely needs a > > better rationale than "is not allowed" when that is manifestly not true. > > > > Maybe prepend a patch updating codingstyle.rst and amend this to say "is > > not allowed by the U-Boot coding standard". Or otherwise please provide > > some reference answering my "why". OK would you like to have a crack at these? > > I suspect the answer here is that we should: > - Patch (and submit upstream) kconfiglib.py to accept lowercase [a-z] as > valid symbol names, as they are. That project is dead, unfortunately. I've had a PR outstanding for over a year. It looks like someone here might take it on, once we can figure out naming, etc. Rasmus, would you like to take a look at the one in U-Boot? Here is what Zephyr did: https://github.com/zephyrproject-rtos/zephyr/issues/40420 > - Add a sentence or two to codingstyle.rst about discouraging lowercase, > as suggested by Rasmus > - Drop the rename parts of this series. If people still want lower case that's OK with me. We have so few I felt it was just confusing, plus the fact that the widely use kconfiglib doesn't support it... Regards, Simon
Hi, On Wed, 1 Feb 2023 at 09:22, Simon Glass <sjg@chromium.org> wrote: > > Hi, > > On Wed, 1 Feb 2023 at 08:48, Tom Rini <trini@konsulko.com> wrote: > > > > On Wed, Feb 01, 2023 at 01:19:51PM +0100, Rasmus Villemoes wrote: > > > On 31/01/2023 15.16, Simon Glass wrote: > > > > Hi Rasmus, > > > > > > > > On Mon, 30 Jan 2023 at 14:12, Rasmus Villemoes > > > > <rasmus.villemoes@prevas.dk> wrote: > > > >> > > > >> On 30/01/2023 16.54, Tom Rini wrote: > > > >>> On Sun, Jan 29, 2023 at 10:57:28PM +0100, Rasmus Villemoes wrote: > > > >>>> On 29/01/2023 01.57, Simon Glass wrote: > > > >>>>> CONFIG options must not use lower-case letter. > > > >>>> > > > >>>> Why? > > > >>> > > > >>> So, kconfiglib complains about these. > > > >> > > > >> Which IMO would be a bug in kconfiglib. Can you point me at where that > > > >> warning is in kconfiglib.py and how it looks and when one would > > > >> encounter it? > > > >> > > > >>> However, I can't find a formal > > > >>> language definition and the kernel documentation doesn't specify, merely > > > >>> imply that it should always be all uppercase. > > > >> > > > >> Well, yes, mostly, but since the de facto specification (namely, the > > > >> kernel's implementation) doesn't complain and the kernel's Kconfig files > > > >> do contain several examples of config symbols with lowercase characters, > > > >> why deviate? In particular, since we share a lot of code, if some piece > > > >> of kernel code has an IS_ENABLED(CONFIG_FOO876xx), why make it harder to > > > >> import and keep that in sync? > > > >> > > > >> Perhaps we can get Masahiro to tell us whether lowercase characters are > > > >> allowed in kconfig symbols or not. > > > >> > > > >> For reference, another kconfig-using project decided to fix their own > > > >> infrastructure around kconfig instead of enforcing uppercase symbols: > > > >> > > > >> https://github.com/zephyrproject-rtos/zephyr/issues/40420 > > > > > > > > That's all good context, thank you. > > > > > > > > When we use #define it is normally with an upper-case string. The is > > > > the convention in U-Boot and Linux (and many other projects), I > > > > believe. > > > > > > I don't disagree with the "normally", but that very word is precisely my > > > point: It's not universal, and there can be good reasons to deviate. > > > Both projects frown upon camelcase, so you don't see a lot of mixed-case > > > macros, but there's definitely a lot of all-lowercase ones (e.g. > > > iterators), and to pick just one example of a justified mixed-case one, > > > there's a "#define RANGE_mA" in some iio device. > > > > > > Also, having lower and upper case strings does become > > > > confusing, and inconsistent. > > > > > > > > I was unaware that lower-case was allowed in Linux. It seems there are > > > > 35 cases of this in Linux. > > > > > > Dunno how you reach that number, I can easily find 174. Among them stuff > > Yes I was missing an underscore. > > git grep -E "CONFIG_([A-Za-z0-9_]*)\b" |sed -n > "s/.*\bCONFIG_\([A-Za-z0-9_]*\)\b.*/\1/p" | sort |uniq | grep > "[a-z]" |wc -l > 187 > > But some are not real. > > > > like "config FONT_6x11" which is definitely more readable than with an > > > uppercase X. But yes, either way it's a very small fraction of all > > > config symbols, but OTOH I highly doubt linux would accept patches to > > > start renaming those without a very strong reason - it would break > > > out-of-tree defconfig files. > > FONT_6X11 isn't that bad :-) > > > > > > > > But perhaps we should not allow it in U-Boot? > > > > > > Discourage, definitely, perhaps even add something to checkpatch. But > > > renaming existing seems to be pointless churn, and definitely needs a > > > better rationale than "is not allowed" when that is manifestly not true. > > > > > > Maybe prepend a patch updating codingstyle.rst and amend this to say "is > > > not allowed by the U-Boot coding standard". Or otherwise please provide > > > some reference answering my "why". > > OK would you like to have a crack at these? > > > > > I suspect the answer here is that we should: > > - Patch (and submit upstream) kconfiglib.py to accept lowercase [a-z] as > > valid symbol names, as they are. > > That project is dead, unfortunately. I've had a PR outstanding for > over a year. It looks like someone here might take it on, once we can > figure out naming, etc. > > Rasmus, would you like to take a look at the one in U-Boot? > > Here is what Zephyr did: > > https://github.com/zephyrproject-rtos/zephyr/issues/40420 > > > - Add a sentence or two to codingstyle.rst about discouraging lowercase, > > as suggested by Rasmus > > - Drop the rename parts of this series. > > If people still want lower case that's OK with me. We have so few I > felt it was just confusing, plus the fact that the widely use > kconfiglib doesn't support it... Actually that's not true, it does support lower-case Kconfig options, or at least the one we do does. I'll send a v3 with these patches dropped. Regards, Simon
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 3ecd6a86e95..cd5b56034d5 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -1289,7 +1289,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \ mt8516-pumpkin.dtb \ mt8518-ap1-emmc.dtb -dtb-$(CONFIG_ARCH_NPCM7xx) += nuvoton-npcm750-evb.dtb +dtb-$(CONFIG_ARCH_NPCM7XX) += nuvoton-npcm750-evb.dtb dtb-$(CONFIG_ARCH_NPCM8XX) += nuvoton-npcm845-evb.dtb dtb-$(CONFIG_XEN) += xenguest-arm64.dtb diff --git a/arch/arm/mach-npcm/Kconfig b/arch/arm/mach-npcm/Kconfig index 24bd2ad423f..a709e1f2402 100644 --- a/arch/arm/mach-npcm/Kconfig +++ b/arch/arm/mach-npcm/Kconfig @@ -8,9 +8,9 @@ config TEXT_BASE choice prompt "Nuvoton SoC select" - default ARCH_NPCM7xx + default ARCH_NPCM7XX -config ARCH_NPCM7xx +config ARCH_NPCM7XX bool "Support Nuvoton NPCM7xx SoC" select CPU_V7A select OF_CONTROL diff --git a/arch/arm/mach-npcm/Makefile b/arch/arm/mach-npcm/Makefile index b448329dea7..4c15fbb8fe5 100644 --- a/arch/arm/mach-npcm/Makefile +++ b/arch/arm/mach-npcm/Makefile @@ -1,2 +1,2 @@ -obj-$(CONFIG_ARCH_NPCM7xx) += npcm7xx/ +obj-$(CONFIG_ARCH_NPCM7XX) += npcm7xx/ obj-$(CONFIG_ARCH_NPCM8XX) += npcm8xx/ diff --git a/arch/arm/mach-npcm/npcm7xx/Kconfig b/arch/arm/mach-npcm/npcm7xx/Kconfig index 237e7ba7e50..17d0a37e97c 100644 --- a/arch/arm/mach-npcm/npcm7xx/Kconfig +++ b/arch/arm/mach-npcm/npcm7xx/Kconfig @@ -1,4 +1,4 @@ -if ARCH_NPCM7xx +if ARCH_NPCM7XX config SYS_CPU default "armv7" diff --git a/drivers/clk/nuvoton/Makefile b/drivers/clk/nuvoton/Makefile index b55dc80de20..1c210a997d4 100644 --- a/drivers/clk/nuvoton/Makefile +++ b/drivers/clk/nuvoton/Makefile @@ -1,3 +1,3 @@ obj-$(CONFIG_ARCH_NPCM) += clk_npcm.o -obj-$(CONFIG_ARCH_NPCM7xx) += clk_npcm7xx.o +obj-$(CONFIG_ARCH_NPCM7XX) += clk_npcm7xx.o obj-$(CONFIG_ARCH_NPCM8XX) += clk_npcm8xx.o diff --git a/drivers/misc/npcm_otp.c b/drivers/misc/npcm_otp.c index 304910888bb..15d016f606b 100644 --- a/drivers/misc/npcm_otp.c +++ b/drivers/misc/npcm_otp.c @@ -484,7 +484,7 @@ static int npcm_otp_bind(struct udevice *dev) } otp_priv->regs[0] = regs; - if (IS_ENABLED(CONFIG_ARCH_NPCM7xx)) { + if (IS_ENABLED(CONFIG_ARCH_NPCM7XX)) { regs = dev_remap_addr_index(dev, 1); if (!regs) { printf("Cannot find reg address (arr #1), binding failed\n"); diff --git a/drivers/pinctrl/nuvoton/Kconfig b/drivers/pinctrl/nuvoton/Kconfig index e55a0261adb..748d18d40ff 100644 --- a/drivers/pinctrl/nuvoton/Kconfig +++ b/drivers/pinctrl/nuvoton/Kconfig @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only config PINCTRL_NPCM7XX bool "Pinctrl and GPIO driver for Nuvoton NPCM7XX" - depends on DM && PINCTRL_GENERIC && ARCH_NPCM7xx + depends on DM && PINCTRL_GENERIC && ARCH_NPCM7XX help Say Y here to enable pin controller and GPIO support for Nuvoton NPCM750/730/715/705 SoCs.
CONFIG options must not use lower-case letter. Convert this to upper case. Signed-off-by: Simon Glass <sjg@chromium.org> --- (no changes since v1) arch/arm/dts/Makefile | 2 +- arch/arm/mach-npcm/Kconfig | 4 ++-- arch/arm/mach-npcm/Makefile | 2 +- arch/arm/mach-npcm/npcm7xx/Kconfig | 2 +- drivers/clk/nuvoton/Makefile | 2 +- drivers/misc/npcm_otp.c | 2 +- drivers/pinctrl/nuvoton/Kconfig | 2 +- 7 files changed, 8 insertions(+), 8 deletions(-)