Commit Graph

7 Commits

Author SHA1 Message Date
Gerard Marull-Paretas c6b1375400 drivers: pwm: stm32: remove remaining Kconfig instances
Following other drivers, Kconfig based instances are now entirely
removed. In order to do this change, PWM nodes in board DT files have
been given a pwm{N} label so that both:

- DT API checks such as #if DT_HAS_NODE(DT_NODELABEL(pwmN)) can be
  used (N being PWM instance number).
- DT references can be written as pwms = <&pwmN x y>; instead of
  pwms = <&{/soc/timers@XXXXXXXX/pwm} x y>;

This approach is also used on the Linux Kernel.

Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
2020-05-05 10:52:51 -05:00
Erwan Gouriou 81f27c2265 boards: stm32: Use dt API for serial peripheral configuration
Replace use of Kconfig UART_X symbols by calls to DT API.
Clean driver from symbols definitions

Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
2020-04-20 15:27:56 -05:00
Erwan Gouriou 67f9b6527b boards: stm32: Remove Kconfig I2C symbols
Following conversion of stm32 i2c driver to use of DT_NODELABEL
macros, configuration of i2c instance in stm32 boards should
no more be done thanks to Kconfig symbols, but is done thanks
to device tree file.
Clean boards files from these symbols.

Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
2020-04-15 08:21:30 -05:00
Ulf Magnusson a42a42cd5a kconfig: Replace defconfig singe-symbol 'if's with 'depends on'
Same deal as in commit eddd98f ("kconfig: Replace some single-symbol
'if's with 'depends on'"), for all symbols defined within defconfig
files. See that commit for an explanation.

Maybe 'if's were used originally to mirror the 'if's in the main Kconfig
files, and then it got copied around by people assuming 'if' must work
differently from 'depends on'. It doesn't match in every spot at least.
Better to keep it simple and just consistently use 'depends on' when
it's a single symbol/choice I think. Helps reinforce that 'if' isn't
magic too.

Verified by printing all Kconfig menu nodes (symbols, choices, menus,
etc.) before and after the change and diffing (should show no
difference).

Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2020-02-12 10:32:13 -06:00
Ulf Magnusson bd6e04411e kconfig: Clean up header comments and make them consistent
Use this short header style in all Kconfig files:

    # <description>

    # <copyright>
    # <license>

    ...

Also change all <description>s from

    # Kconfig[.extension] - Foo-related options

to just

    # Foo-related options

It's clear enough that it's about Kconfig.

The <description> cleanup was done with this command, along with some
manual cleanup (big letter at the start, etc.)

    git ls-files '*Kconfig*' | \
        xargs sed -i -E '1 s/#\s*Kconfig[\w.-]*\s*-\s*/# /'

Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2019-11-04 17:31:27 -05:00
Ulf Magnusson 975de21858 kconfig: Global whitespace/consistency cleanup
Clean up space errors and use a consistent style throughout the Kconfig
files. This makes reading the Kconfig files more distraction-free, helps
with grepping, and encourages the same style getting copied around
everywhere (meaning another pass hopefully won't be needed).

Go for the most common style:

 - Indent properties with a single tab, including for choices.

   Properties on choices work exactly the same syntactically as
   properties on symbols, so not sure how the no-indentation thing
   happened.

 - Indent help texts with a tab followed by two spaces

 - Put a space between 'config' and the symbol name, not a tab. This
   also helps when grepping for definitions.

 - Do '# A comment' instead of '#A comment'

I tweaked Kconfiglib a bit to find most of the stuff.

Some help texts were reflowed to 79 columns with 'gq' in Vim as well,
though not all, because I was afraid I'd accidentally mess up
formatting.

Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2019-11-01 15:53:23 +01:00
NavinSankar Velliangiri f2163de6ed boards: arm: Add steval_fcu001v1 board support
BSP for steval_fcu001v1 resubmitted as per PR #18746

Signed-off-by: NavinSankar Velliangiri <navin@linumiz.com>
2019-10-07 08:57:36 -05:00