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>
Replace the existing Apache 2.0 boilerplate header with an SPDX tag
throughout the zephyr code tree. This patch was generated via a
script run over the master branch.
Also updated doc/porting/application.rst that had a dependency on
line numbers in a literal include.
Manually updated subsys/logging/sys_log.c that had a malformed
header in the original file. Also cleanup several cases that already
had a SPDX tag and we either got a duplicate or missed updating.
Jira: ZEP-1457
Change-Id: I6131a1d4ee0e58f5b938300c2d2fc77d2e69572c
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
STM32Cube uses SoC defines made to reflect HW heterogeneity
that should be taken into account by SW.
Aim of this commit is to adapt values used by Zephyr to the same
diversity. This will help create new SoC values only when justified
by a real hardware difference that should be taken into account
by software.
For instance, for SoC stm32f103rb following define is used:
*STM32F103xB
Which means:
*Same SW could be used on STM32F103RB and STM32F103VB:
same CONFIG_SOC could be used
*Different SW should be used on STMF103RB and STM32F103R4:
different CONFIG_SOC should be used
This change focuses on stm32f1xx series.
Change-Id: I5ecfaa52952d04421b27b5e74fb71b4fc108b662
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Introduce an architecture sorting of boards. This is to allow for
easier maintenance going forward as the number of boards grows. It
will be easier for any scripts to know the board/arch mapping without
having to maintain an explicit list of what boards are associated with
which arch. We can also do things like have architecture maintainers
cover reviews and branches for arch/${ARCH} and boards/${ARCH} going
forward.
Change-Id: I02e0a30292b31fad58fb5dfab2682ad1c5a7d5a7
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Ulf Magnusson