* [Question] dt bindings for BeagleConnect
@ 2023-09-23 16:04 Ayush Singh
2023-09-23 16:08 ` Krzysztof Kozlowski
0 siblings, 1 reply; 6+ messages in thread
From: Ayush Singh @ 2023-09-23 16:04 UTC (permalink / raw)
To: devicetree; +Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, kernelnewbies
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Question] dt bindings for BeagleConnect
2023-09-23 16:04 [Question] dt bindings for BeagleConnect Ayush Singh
@ 2023-09-23 16:08 ` Krzysztof Kozlowski
0 siblings, 0 replies; 6+ messages in thread
From: Krzysztof Kozlowski @ 2023-09-23 16:08 UTC (permalink / raw)
To: Ayush Singh, devicetree
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, kernelnewbies
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Question] dt bindings for BeagleConnect
@ 2023-09-23 16:08 Ayush Singh
2023-09-23 16:09 ` Krzysztof Kozlowski
0 siblings, 1 reply; 6+ messages in thread
From: Ayush Singh @ 2023-09-23 16:08 UTC (permalink / raw)
To: devicetree; +Cc: kernelnewbies, robh+dt, krzysztof.kozlowski+dt, conor+dt
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Question] dt bindings for BeagleConnect
2023-09-23 16:08 Ayush Singh
@ 2023-09-23 16:09 ` Krzysztof Kozlowski
2023-09-23 16:10 ` Ayush Singh
0 siblings, 1 reply; 6+ messages in thread
From: Krzysztof Kozlowski @ 2023-09-23 16:09 UTC (permalink / raw)
To: Ayush Singh, devicetree
Cc: kernelnewbies, robh+dt, krzysztof.kozlowski+dt, conor+dt
On 23/09/2023 18:08, Ayush Singh wrote:
>
> Hello everyone, I am working on writing a BeagleConnect driver for
> Beagleplay board. Let me first go over some terminology:
>
Sending things twice will only make discussion even more confusing for
us, e.g. spread over multiple threads. Don't do it.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Question] dt bindings for BeagleConnect
2023-09-23 16:09 ` Krzysztof Kozlowski
@ 2023-09-23 16:10 ` Ayush Singh
2023-09-23 16:38 ` Krzysztof Kozlowski
0 siblings, 1 reply; 6+ messages in thread
From: Ayush Singh @ 2023-09-23 16:10 UTC (permalink / raw)
To: Krzysztof Kozlowski, devicetree
Cc: kernelnewbies, robh+dt, krzysztof.kozlowski+dt, conor+dt
> On 23/09/2023 18:08, Ayush Singh wrote:
>> Hello everyone, I am working on writing a BeagleConnect driver for
>> Beagleplay board. Let me first go over some terminology:
>>
> Sending things twice will only make discussion even more confusing for
> us, e.g. spread over multiple threads. Don't do it.
>
Sorry, I sent the first using wrong email and then canceled the message
from the link I got back from the mailing list.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Question] dt bindings for BeagleConnect
2023-09-23 16:10 ` Ayush Singh
@ 2023-09-23 16:38 ` Krzysztof Kozlowski
0 siblings, 0 replies; 6+ messages in thread
From: Krzysztof Kozlowski @ 2023-09-23 16:38 UTC (permalink / raw)
To: Ayush Singh, devicetree
Cc: kernelnewbies, robh+dt, krzysztof.kozlowski+dt, conor+dt
On 23/09/2023 18:10, Ayush Singh wrote:
>
>> On 23/09/2023 18:08, Ayush Singh wrote:
>>> Hello everyone, I am working on writing a BeagleConnect driver for
>>> Beagleplay board. Let me first go over some terminology:
>>>
>> Sending things twice will only make discussion even more confusing for
>> us, e.g. spread over multiple threads. Don't do it.
>>
> Sorry, I sent the first using wrong email and then canceled the message
> from the link I got back from the mailing list.
Emails do not work like this. You cannot cancel (or recall) a message.
Your recipients already got your previous message.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-09-23 16:38 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-09-23 16:04 [Question] dt bindings for BeagleConnect Ayush Singh
2023-09-23 16:08 ` Krzysztof Kozlowski
-- strict thread matches above, loose matches on Subject: below --
2023-09-23 16:08 Ayush Singh
2023-09-23 16:09 ` Krzysztof Kozlowski
2023-09-23 16:10 ` Ayush Singh
2023-09-23 16:38 ` Krzysztof Kozlowski
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).