Device tree kernel summit 2017 action items

= Device Tree Workshop 2017 Action Items =


 * YAML data schema must enable 3rd party tools, switch from using anchors and labels as in YAML to special properties.
 * 1) foo: &foo_label -> foo: { $label: foo_label }
 * 2) prop: [ *foo_label, 1 ] -> prop: [ $foo_label, 1 ]

Assigned: Pantelis

Assigned: None
 * YAML tools need to preserve comments (yes/no)
 * 1) Hard requirement or not?
 * 2) Comments are preserved for ruamel
 * 3) Comments are not preserved for yamldt


 * Select YAML or JSON for deduplicated machine readable format.
 * 1) Example in source YAML format is: foo: [ "string", 10+2, $reference, !int16 8 ] declares a property which is comprised of a sequence of 4 scalars. One string equal to "string", one integer/cell value with the value 12, a reference to a node with the label 'reference' and finally a 16 bit value with a value of 8.
 * 2) YAML is easier to read and maps to source file format. Easily distinguish strings, integer values and references. Type information is preserved too. foo: [ "string", 12, $reference, !int16 8 ] Strings are always quoted, integer values are expressions, references are tagged by being unquoted strings starting with $, and if a tag exists it is preserved.
 * 3) JSON is easier for machines to parse but does not preserve types.  foo: [ "string", 12, "$reference", 8 ]  Requires use of the bindings to retrieve type information. Quoted strings maybe either strings or references, values require binding info to know whether they are 32 bit or something elese.
 * 4) Alternative JSON encoding with type information using escapes.  foo: [ "string", 12 "\aref reference", "\aint8 8" ] Would require disallowing presence of the \a characters in normal strings and encoding tags that can not be deduced in quoted strings. Pro is that it's straight forward, con looks weird for human readers.

Assigned: Grant, Pantelis


 * YAML schemas
 * 1) Grant is using ruamel, validates using json schema format file. Hand written, how it would pick rules from binding files?
 * 2) Pantelis is using yamldt, no extra format file, pick up everything from bindings.
 * 3) Handle extra constraints. JSON schema does not define arbitrary constraints as expressions. They are needed for validation of busses etc. yamldt can eventually generate constraints from a subset of the JSON schema.

Assigned: Grant, Pantelis


 * Extendable schemas
 * 1) Core bindings refer to hardware definitions
 * 2) Operating systems/bootloaders may require extensions that are configuration related or specific use related. I.e. Linux specific configuration properties, u-boot spl node tags, etc.
 * 3) There can be a systematic method of separating and then combining them for validation/code generation

A ssigned: None


 * Code generation
 * 1) Project require generation of code/defines from device tree sources.
 * 2) u-boot
 * 3) Zephyr
 * 4) Xilinx?
 * 5) Possible to have a common infrastructure to generate code, based on bindings?

Assigned: None


 * Device Tree Overlays
 * 1) How they should be structured? Differences between how Android does it and how Linux does it.
 * 2) Android structure is:
 * Main DT. The SoC-only part and the default configurations, provided by SoC vendor.
 * Overlay DT. The device-specific configurations, provided by ODM/OEM.
 * https://source.android.com/devices/architecture/dto/implement
 * 1) Android bootloader applies the overlay, and passes the merged device tree to the kernel.
 * 2) Where should they live? Part of the kernel tree or external repo?
 * 3) Frank: The source in overlays soon (4.15-rc1?) should be in .dtsi files, which are included from an overlay .dts that supplies the /plugin/ directive.  They should live wherever the .dtsi files live.
 * 4) Git submodules use if external repo?
 * 1) Frank: The source in overlays soon (4.15-rc1?) should be in .dtsi files, which are included from an overlay .dts that supplies the /plugin/ directive.  They should live wherever the .dtsi files live.
 * 2) Git submodules use if external repo?

Assigned: None


 * Device Tree duplication avoidance.
 * 1) New marvell parts are using highly duplicated IP. How to support those cases
 * 2) Thomas: Use CPP macros -> works now
 * 3) David: Could be easier if relative paths would work: <&/foo/bar> -> <&../bar>
 * 4) David: Node names generated via expression might make things easier. What kind of expressions?
 * 5) Pantelis: Possible expression might refer to a property, could tie in with unit-names. foo@10 { reg = <10>; }; -> foo@{reg[0]} { reg = <10>; };
 * 6) YAML can use merge keys and templating instead. Not specified yet.

Assigned: None


 * DT foreign bindings
 * 1) Different projects use the same bindings differently
 * 2) devicetree.org?
 * 3) Could be part of Extendable Schemas

Assigned: None


 * Sharing generic bindings
 * 1) Geert: On certain cases generic bindings apply to devices in the whole domain
 * 2) Inheritable bindings. How to define them in schemas?

Assigned: None


 * Linux kernel device tree overlays specific
 * 1) configfs patch not admissible yet, due to the way that the kernel breakage
 * 2) Culprit is of_* accessor methods that directly return pointer to device tree properties
 * 3) Switch to using a safer API for drivers
 * 4) Locking should be revisited or revised completely
 * 5) Pantelis, Frank: switch drivers to using devm_ managed memory accessor methods new API (architecture TBD)

Assigned: Frank, Pantelis