Re: [Question] dt bindings for BeagleConnect

[Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>]

On 23/09/2023 18:04, Ayush Singh wrote:
> 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?

Referring to some comments without the context - patch and the comments
given - makes any discussion difficult. We do not work like this in
upstream communities. Please respond inline, not top posting, to the
comments you received.


> 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.

There are plenty of other serial-attached MCUs. Just look for "mcu {"
(for serial) or mcu@ (for other buses).

Best regards,
Krzysztof