[Question] dt bindings for BeagleConnect

[Ayush Singh <ayushsingh1325@gmail.com>]

Hello everyone, I am working on writing a BeagleConnect driver for 
Beagleplay board. Let me first go over some terminology:

BeagleConnect is both a technology concept and a line of board designs 
that implement the technology. Born from Greybus, a mechanism for 
dynamically extending a Linux system with embedded peripherals, 
BeagleConnect adds two key elements: a 6LoWPAN transport and mikroBUS 
manifests. The 6LoWPAN transport provides for arbitrary connections, 
including the IEEE802.15.4g long-range wireless transport supported 
between BeaglePlay and BeagleConnect Freedom (the first BeagleConnect 
board design). The mikroBUS manifests provide for rapid prototyping and 
low-node-count production with sensor boards following the mikroBUS 
freely-licensable embedded bus standard, such that existing Linux 
drivers can be loaded upon Greybus discovery of the nodes.

BeaglePlay consists of a main AM62 processor and a CC1352 co-processor 
which is responsible for providing 6LoWPAN support along with Greybus 
node discovery. The AM62 processor and CC1352 are internally connected 
over UART. The CC1352 coprocessor is supposed to run a specific firmware 
as a part BeagleConnect setup. It looks as follows:

AM62 (Linux Driver) <--UART--> CC1352 (Zephyr Firmware) <--6LoWPAN--> 
BeagleConnect Freedom

I need a way to access this bridge UART. The most straightforward method 
is adding a `compatible` property to the device tree of this UART. But I 
am not sure how to go about adding a DT binding for it that can be 
merged upstream.

Here are a few comments I have encountered:

1. DT bindings need to be hardware

I am not sure which hardware the bindings need to target in my case. 
Should the bindings be serial in nature, since I need to use the UART 
device? Or they should be about SoC since CC1352 is the device I am 
actually communicating with? Or maybe there is a 3rd category for an SoC 
running a specialized firmware for a technology/protocol?

2. DON'T create nodes just for the sake of instantiating drivers.

I guess this means that adding a child node just to add a `compatible` 
property is not allowed? For some reason, the driver probe is not called 
if I simply try to override the top level `compatible` property of the 
serial device. But maybe that is just an issue with my approach?

3. DO attempt to make bindings complete even if a driver doesn't support 
some features.

This is only relevant if the answer to 1) is the SoC. Since the CC1352 
device cannot be directly controlled by, the capability of this device 
is defined by the firmware running on top of it rather than the 
hardware. So I am not quite sure what a complete binding for such a 
device even mean. The only property I can make required would be the 
`compatible` property and everything else will be optional I guess?


I understand that strict guidelines are required since once a property 
is added to the Kernel device tree, it will almost be impossible to 
remove without breaking compatibility. So I would like some guidance or 
maybe some similar devices that are already a part of the kernel which I 
can look to for guidance.

Ayush Singh


[BeagleConnect]: 
https://docs.beagleboard.org/latest/boards/beagleconnect/index.html

[BeaglePlay]: 
https://docs.beagleboard.org/latest/boards/beagleplay/index.html

[My Last Patch]: 
https://lists.linaro.org/archives/list/greybus-dev@lists.linaro.org/thread/GKOFWZ5IJMNXIWVDOM3WRNU2B2S4244G/

[My Patch Github]: https://github.com/Ayush1325/linux/tree/gb-beagleplay