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>
There are no reference for either K_NUM_PRIORITIES or
K_NUM_PRIO_BITMAPS, with the former being dropped in:
1acd8c2996 kernel: Scheduler rewrite
Dropping both of these, and also the two comments about extra priorities
taking extra RAM space, as those do not seem to apply either.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Document devicetree compatibles which have changed recently and that
have drivers, along with how to handle them.
Recent changes to things like / and CPU nodes aren't worth mentioning
since there are no drivers for such things. I'm similarly not going to
document the vexriscv change since it seems likely that users are
getting this compatible via the DTSI file.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Commit c4079e4be2
("scripts: rework edtlib warnings-turned-errors") was trying to abort
on unknown vendor prefix, but the error log is not fatal.
Fix it by using the same error handling function we use when aborting
due to deprecated property usage.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
There are way too many one-off vendor prefixes set up for individual
boards to bother tracking them in vendor-prefixes.txt. As a practical
matter, the compatible for the root node doesn't matter anyway. So
just relax our check for that node.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
We have a 'mxicy' entry in vendor-prefixes.txt for this vendor. Use it
to be consistent. Linux's
Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml file allows
both, but I'd like to see what happens if we try to be consistent in
Zephyr. There isn't a binding for this compatible in zephyr, so I'm
hopeful this won't break any upstream use cases.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
These are using unknown vendor prefixes.
I did find references to a Nanjing Tianyi Hexin Electronics Co., Ltd.
on Crunchbase and I thought about adding a vendor prefix, but I can't
justify it since it's just a single board that is using it, and there
is no upstream driver.
Similarly, I found hynitron.com, which seems to be an electronics
vendor, but Google Translate says their "about" page translates to
"Incomplete website information, please contact sales" (and the
English version contains no text).
Just change ',' to '-' instead so there is no vendor prefix anymore.
We can revisit this if anyone wants to upstream drivers for these
compatibles in the future, but for now it doesn't seem worth it.
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>
We have a binding for compatible "quectel,bg9x".
I can't find any bindings for this vendor in Linux.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
We have a binding for wiznet,w5500 in zephyr.
Linux has a binding for this device, too:
d5ad8ec3cf/Documentation/devicetree/bindings/net/wiznet,w5x00.txt
But 'wiznet' is not present in the Linux vendor prefixes file for some
reason.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
