Commit Graph

5 Commits

Author SHA1 Message Date
Kumar Gala 4372efe4ef drivers: uart: miv: convert to DT_INST defines
Convert driver to fully use DT_INST_ defines.

Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2020-03-11 16:37:22 -06: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 c5839f834b kconfig: Remove assignments to CONFIG_<arch> syms and hide them
All board defconfig files currently set the architecture in addition to
the board and the SoC, by setting e.g. CONFIG_ARM=y. This spams up
defconfig files.

CONFIG_<arch> symbols currently being set in configuration files also
means that they are configurable (can be changed in menuconfig and in
configuration files), even though changing the architecture won't work,
since other things get set from -DBOARD=<board>. Many boards also allow
changing the architecture symbols independently from the SoC symbols,
which doesn't make sense.

Get rid of all assignments to CONFIG_<arch> symbols and clean up the
relationships between symbols and the configuration interface, like
this:

1. Remove the choice with the CONFIG_<arch> symbols in arch/Kconfig and
   turn the CONFIG_<arch> symbols into invisible
   (promptless/nonconfigurable) symbols instead.

   Getting rid of the choice allows the symbols to be 'select'ed (choice
   symbols don't support 'select').

2. Select the right CONFIG_<arch> symbol from the SOC_SERIES_* symbols.
   This makes sense since you know the architecture if you know the SoC.

   Put the select on the SOC_* symbol instead for boards that don't have
   a SOC_SERIES_*.

3. Remove all assignments to CONFIG_<arch> symbols. The assignments
   would generate errors now, since the symbols are promptless.

The change was done by grepping for assignments to CONFIG_<arch>
symbols, finding the SOC_SERIES_* (or SOC_*) symbol being set in the
same defconfig file, and putting a 'select' on it instead.

See
https://github.com/ulfalizer/zephyr/commits/hide-arch-syms-unsquashed
for a split-up version of this commit, which will make it easier to see
how stuff was done. This needs to go in as one commit though.

This change is safer than it might seem re. outstanding PRs, because any
assignment to CONFIG_<arch> symbols generates an error now, making
outdated stuff easy to catch.

Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2020-02-08 00:50:08 -06:00
Erwan Gouriou 5a12d51285 boards: Clean up references to env variable PROJECT_SOURCE_DIR
As recommended in cmake/app/boilerplate.cmake, ZEPHYR_BASE should
be preferred to PROJECT_SOURCE_DIR.
Do the change for all boards still referring to PROJECT_SOURCE_DIR.

Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
2019-09-12 13:16:16 -05:00
Nicolas Pitre 1f4b5ddd0f riscv32: rename to riscv
With the upcoming riscv64 support, it is best to use "riscv" as the
subdirectory name and common symbols as riscv32 and riscv64 support
code is almost identical. Then later decide whether 32-bit or 64-bit
compilation is wanted.

Redirects for the web documentation are also included.

Then zephyrbot complained about this:

"
New files added that are not covered in CODEOWNERS:

dts/riscv/microsemi-miv.dtsi
dts/riscv/riscv32-fe310.dtsi

Please add one or more entries in the CODEOWNERS file to cover
those files
"

So I assigned them to those who created them. Feel free to readjust
as necessary.

Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-08-02 13:54:48 -07:00