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
