Add missing RADIO and EGU nodes. We already have compatibles for
these defined, and the peripherals are present, so define them for
consistency across SoCs.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Add missing EGU nodes. We already have a compatible for
these defined, and the peripherals are present, so define them for
consistency across SoCs.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Add missing RADIO and EGU nodes. We already have compatibles for
these defined, and the peripherals are present, so define them for
consistency across SoCs.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Add missing EGU and TIMER nodes. We already have compatibles for these
defined, and the peripherals are present, so define them for
consistency across SoCs.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Add missing RADIO and EGU nodes. We already have compatibles for these
defined, and the peripherals are present, so define them for
consistency across SoCs.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Add missing RADIO and EGU nodes. We already have compatibles for these
defined, and the peripherals are present, so define them for
consistency across SoCs.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Add missing FICR, UICR, RADIO, and EGU nodes. We already have
compatibles for these defined, and the peripherals are present, so
define them for consistency across SoCs.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Add missing FICR, UICR, RADIO nodes. We already have compatibles for
these defined, and the peripherals are present, so define them for
consistency across SoCs.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The way we currently handle direction finding extension (DFE) support
on Nordic nRF5 controllers relies on required devicetree properties
related to DFE in the "nordic,nrf-radio" node.
That doesn't make sense on radios without DFE support, though.
Any .dtsi for an SoC without DFE support which has such a node would
require extraneous DFE related properties like dfe-antenna-num.
Instead of making the properties required, mark them optional. We
indicate the presence of DFE support via a new 'dfe-supported' boolean
property which the SoC .dtsi files can set (or not) depending on
support.
This gives us the opportunity to do some cleanup in the Kconfig,
removing CONFIG_HAS_HW_NRF_RADIO_BLE_DF since we know from the
devicetree whether DFE support is available.
Handle that change appropriately in radio_df.c. This gives us an
opportunity to improve readability in the devicetree-related macro
magic in that file.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The documentation for Bluetooth Direction Finding Extension (DFE)
samples has various issues:
- references to 'child' images, which do not exist in mainline zephyr
- invalid RST syntax: there are missing ` characters to end arguments
to :zephyr_file: roles, creating unintelligible output
- incorrect RST usage:
- using :zephyr_file: instead of :file: when referring to a file
that the user must create, creating broken links to nonexistent
files in the zephyr tree
- using :code: instead of :kconfig: to refer to kconfig options,
creating output without links to the help for those options
- redundant or duplicated information
- grammar, typos, various bits and pieces
Clean this up. As part of that, move various common bits and pieces of
information to the devicetree bindings index so they can just be
linked to from the sample docs.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Signed-off-by: Piotr Pryga <piotr.pryga@nordicsemi.no>
Sort by unit address. This involves multiple files since there are
includes and secure/non-secure files to deal with.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This has an unrecognized vendor prefix which does not seem to serve
any purpose. Removing it is a way forward to turning warnings into
errors on unrecognized vendor prefixes.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The Linux vendor prefixes list uses 'cdns'. Match it, especially since
we have that prefix in our own list as well.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
These IP blocks' vendor is Cadence, whose proper vendor prefix is
'cdns' if we are going to match the Linux vendor prefixes list.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
As far as I can tell, 'vexriscv' does not name a vendor:
https://github.com/SpinalHDL/VexRiscv
It also doesn't seem entrenched enough to merit a special case
exception to the de factor rule 'the "vnd,foo" namespace is for
vendors'. This is open to debate and we can revise as needed in the
future, but for now let's just rename the compatible to avoid
triggering warnings/errors about unknown vendors.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The original NIOS-II developer and former vendor is Altera, which is
now part of Intel. Let's not add a new vendor prefix for something
that already exists and has been acquired; move it to use the existing
'altr,' prefix instead.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Rename:
- grove,light to seeed,grove-light
- grove,temperature to seeed,grove-temperature
The "grove" brand applies to a family of products by Seeed (sic):
https://www.seeedstudio.com/category/Grove-c-1003.html
Therefore we should use the existing vendor seeed.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
I can't find any reference anywhere showing that the manufacturer of
the LPD8803 or LPD8806 LED scripts is a company called 'colorway'.
Use 'greeled' instead; these seem to actually be manufactured by
GreeLed corporation.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
It should be "maxim,max30101", because the vendor prefix for this
company is "maxim", not "max".
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
It should be "u-blox,sara-r4", because the vendor prefix for this
company is "u-blox", not "ublox".
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
We have a ftdi,ft800 binding, and it's easy to imagine additional
bindings coming in the future since their USB/UART chips are very
commonly used.
I didn't find anything in Linux for this vendor.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This is used for microbit,edge-connector. I couldn't find anything in
Linux, which is not surprising given these boards have constrained
Cortex-M chips.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
We have various compatibles matching this in a DTSI file.
Linux tracks this vendor too:
4071883fd8
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
We have a binding for apa,apa102 in zephyr.
I can't find any bindings for this vendor in Linux.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
