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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies