Simon has been helping out with the reviews of the LED PRs. So let's add
him as a collaborator to help PRs move forward.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
This commit rewrite renesas R-Car clock driver in order
to be able to support any new SoC easier.
This work is so creating a clock driver per soc alongside a
common driver for all reneasas r-car boars.
- drivers: create a driver per soc
- create a common driver
- create a common header used by soc & common driver
- create a soc specific driver calling for common driver
- dts: use new compatible
- use old yaml as common yaml
- create a new "child" yaml to define the new compatible field
- change compatible in device tree
As in Linux, the driver can support both r8a77951 and r8a77950
SoC's so we decided to name the new driver as in Linux with Zephyr
prefix : "clock_control_r8a7795_cpg_mssr.c".
Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
This commit adds @keith-packard, the author of the picolibc, as a
collaborator for the C library area.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit adds a MAINTAINERS entry for the picolibc module with
@keith-packard as the maintainer and @stephanosio as a collaborator.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This code has gone unmaintained and bugs continue to be reported
against it. We do not have the resources as a project to maintain this
in "odd fixes" mode, and nobody has stepped up to maintain it [1], so
sadly this must be removed for now.
If anyone would like to see civetweb supported in upstream Zephyr
again, they are welcome to add it back, as long as they promise to
maintain it going forward.
Many thanks to everyone who has contributed to civetweb support in
Zephyr while it was here. So long and thanks for all the fish.
Fixes: #45807Fixes: #43910Fixes: #34226Fixes: #46743
[1] https://lists.zephyrproject.org/g/devel/message/8466
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Herman (hermabe) has been involved in the Bluetooth host, mostly for
EATT. So we would like to add him as a reviewer to select PRs.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Adding myself as collaborator for both logging and cbprintf so that
I get notifications when PRs are submitted against them.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
A test is added that uses the new device and verifies that all
desired memory is included in the core dump when a crash occurs.
Signed-off-by: Mark Holden <mholden@fb.com>
Add a pseudo device diver with device tree bindings for coredump.
The device tree bindings exposes memory address/size values to be
included in any dump. And the driver exposes an API to add/remove
dump memory regions at runtime.
Signed-off-by: Mark Holden <mholden@fb.com>
This commit renames the 'Microchip Platforms' entry to 'Microchip
MEC Platforms' since this entry is specific to the Microchip MEC family
devices.
This is in preparation for adding an entry for the Microchip (formerly
Atmel) SAM family devices.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit updates the label name in the 'Nuvoton_Numicro Platforms'
entry to match the actual GitHub label name, which is 'platform:
Nuvoton Numicro Platforms'.
In addition, the entry name is also updated to match the label styling
(underscore is removed).
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit updates the label name in the 'Nuvoton_NPCX Platforms'
entry to match the actual GitHub label name, which is 'platform:
Nuvoton NPCX Platforms'.
In addition, the entry name is also updated to match the label styling
(underscore is removed).
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit updates the label name in the 'nRF52 BSIM' entry to match
the actual GitHub label name, which is 'platform: nRF52 BSIM'.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit adds the MAINTAINERS entry for the Toolchain Integration,
with @tejlmand as the maintainer and @stephanosio as a collaborator.
The purpose of this is to provide a corresponding MAINTAINERS entry for
the "area: Toolchains" and differentiate the toolchain integration-
related maintenance tasks from the general build system maintenance
tasks.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit adds the MAINTAINERS entry for the CMSIS-NN integration,
with @JordanYates, the initial contributor, as the maintainer and
@stephanosio as a collaborator.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This is part of the road towards replacing CODEOWNERS with
MAINTAINERS (tracked in the process working group as #38725).
As part of that work, we wanted to have a way to track the maintainers
of each west project (entry in west.yml) by name of project.
This is an initial attempt at that, based mostly on my personal
knowledge, the git logs, and some rough guesswork. I fully expect
omissions and errors, but it should be enough to get us started, with
fixes to follow incrementally from the people who know their
individual areas better than I do.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
So far, the majority of support has been through Linaro for these
platforms, but we do expect to bring a maintainer on from TI in the
near future.
Signed-off-by: Christopher Friedt <chrisfriedt@gmail.com>
Move include paths and add new target_include_directories to support
backwards compatibility:
* /include -> /include/zephyr
example: <irq.h> -> <zephyr/irq.h>
Issue #41543
Signed-off-by: Yuval Peress <peress@google.com>
Move the kernel documentation up and make it a main chapter. Right now
it is hidden very low in the structure under references.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
There is a typo (s/ares/area/).
More importantly, there are examples of areas with this status that do
not have any collaborators:
- Drivers: Interrupt controllers
- Little FS
Fix the text to reflect reality.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
an area without maintainer is still considered active, calling it orphan
is a bit extreme. We have some areas that can be considered "orphaned",
those now will be covered with 'odd fixes' status, meaning that they
might have one or more collaborator and getting some changes from time
to time, but nothing beyond fixes and nobody driving the area beyond
where it is right now.
Even an area with a dedicated maintainer can be have the status of 'odd
fixes', i.e. there is a maintainer but the area is stale and no further
development is happening.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>