<div dir="auto">Hi <span class="gmail_chip gmail_plusreply" dir="auto"><a href="mailto:Carlo.Brokering@dlr.de" style="color:#15c;text-decoration:underline">@Carlo.Brokering@dlr.de</a></span>, <div dir="auto"><br></div><div dir="auto">Once the commands are defined the corresponding command and buffer should be passed as arguments. As the commands are not defined Null and zero are passed as buffer and command respectively. </div><div dir="auto"><br></div><div dir="auto">Regards</div><div dir="auto">Prashanth S</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 2 Mar, 2023, 2:22 pm , <<a href="mailto:Carlo.Brokering@dlr.de">Carlo.Brokering@dlr.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="DE" link="blue" vlink="purple"><div class="m_-7909787354523239245WordSection1"><p class="MsoNormal"><span>Hello <a id="m_-7909787354523239245OWAAMCDB6EB0D968649DA9AE24CE4538BB300" href="mailto:fishesprashanth@gmail.com" target="_blank" rel="noreferrer"><span style="font-family:"Calibri",sans-serif;text-decoration:none">@Prashanth S</span></a><u></u><u></u></span></p><p class="MsoNormal"><span><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">> I saw in discord there was a discussion for the rework of CAN framework, so you could start a discussion in this mailing list or in discord.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">Good to know. I’ll have a look there.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">> The ioctl commands are not defined for the CAN framework, so NULL and 0 are passed to dev_ioctl.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">Ok but i don't quite understand how commands are otherwise sent to the bsp driver.<u></u><u></u></span></p><p class="MsoNormal"><span class="m_-7909787354523239245rynqvb"><span lang="EN">Should that only work once defined commands have been discussed and implemented?<u></u><u></u></span></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">Best regards<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">Carlo Brokering<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><b>Von:</b> Prashanth S <<a href="mailto:fishesprashanth@gmail.com" target="_blank" rel="noreferrer">fishesprashanth@gmail.com</a>> <br><b>Gesendet:</b> Donnerstag, 2. März 2023 07:25<br><b>An:</b> Brokering, Carlo <<a href="mailto:Carlo.Brokering@dlr.de" target="_blank" rel="noreferrer">Carlo.Brokering@dlr.de</a>><br><b>Cc:</b> <a href="mailto:devel@rtems.org" target="_blank" rel="noreferrer">devel@rtems.org</a><br><b>Betreff:</b> Re: CAN driver implementation for Xilinx Zynq<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">Hi <a href="mailto:Carlo.Brokering@dlr.de" target="_blank" rel="noreferrer">@Carlo.Brokering@dlr.de</a> ,<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><span lang="EN-US">> the design for the rx data path including the RxFIFO looks promising. If nobody is working on it yet, I would try to implement it. You said it still needs to be approved -</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">> who do I have to contact for this?</span><u></u><u></u></p></div><blockquote style="margin-left:30.0pt;margin-right:0cm"><div><p class="MsoNormal"><span lang="EN-US">I saw in discord there was a discussion for the rework of CAN framework, so you could start a discussion in this mailing list or in discord.</span><u></u><u></u></p></div></blockquote><div><p class="MsoNormal"><span lang="EN-US">> </span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">> I think you misunderstood me about the ioctl api. My main question was why command and buffer are not passed to the dev_ioctl here:</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">> </span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">> bus->can_dev_ops->dev_ioctl(bus->priv, NULL, 0);</span><u></u><u></u></p></div><blockquote style="margin-left:30.0pt;margin-right:0cm"><p class="MsoNormal">The ioctl commands are not defined for the CAN framework, so NULL and 0 are passed to dev_ioctl.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p></blockquote><p class="MsoNormal">Regards<u></u><u></u></p><div><p class="MsoNormal">Prashanth S<u></u><u></u></p></div></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Wed, 1 Mar 2023 at 21:08, <<a href="mailto:Carlo.Brokering@dlr.de" target="_blank" rel="noreferrer">Carlo.Brokering@dlr.de</a>> wrote:<u></u><u></u></p></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm"><div><div><div><p class="MsoNormal"><span lang="EN-US">Hello Prashanth S,</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">the design for the rx data path including the RxFIFO looks promising. If nobody is working on it yet, I would try to implement it. You said it still needs to be approved - who do I have to contact for this?</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">I think you misunderstood me about the ioctl api. My main question was why command and buffer are not passed to the dev_ioctl here:</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">bus->can_dev_ops->dev_ioctl(bus->priv, NULL, 0);</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">Regards</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">Carlo Brokering</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p><p class="MsoNormal"><b>Von:</b> Prashanth S <<a href="mailto:fishesprashanth@gmail.com" target="_blank" rel="noreferrer">fishesprashanth@gmail.com</a>> <br><b>Gesendet:</b> Mittwoch, 1. März 2023 11:53<br><b>An:</b> Brokering, Carlo <<a href="mailto:Carlo.Brokering@dlr.de" target="_blank" rel="noreferrer">Carlo.Brokering@dlr.de</a>><br><b>Cc:</b> <a href="mailto:devel@rtems.org" target="_blank" rel="noreferrer">devel@rtems.org</a><br><b>Betreff:</b> Re: CAN driver implementation for Xilinx Zynq<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><div><div><p class="MsoNormal">Hello @Carlo Brokering<span style="font-size:12.0pt;color:black">,</span><u></u><u></u></p><div><p class="MsoNormal"> <u></u><u></u></p></div><div><div><p class="MsoNormal"><span style="font-size:12.0pt;color:#9900ff">> As part of an internship at the German Aerospace Center, I am currently working on the implementation of a CAN driver for a Xilinx</span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:12.0pt;color:#9900ff">> Zynq SoC. </span><span lang="EN" style="font-size:12.0pt;color:#9900ff">For this I used the existing CAN framework /dev/can/can.h. A merge request will follow soon.</span><u></u><u></u></p></div></div><blockquote style="margin-left:30.0pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt"><div><div><p class="MsoNormal"><span lang="EN" style="font-size:12.0pt;color:black">All the best for your Internship.</span><u></u><u></u></p></div></div></blockquote><div><div><p class="MsoNormal"><span style="font-size:12.0pt;color:#9900ff">></span><span style="font-size:12.0pt;color:#500050"> </span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:12.0pt;color:#9900ff">><br>> Here's what I'd like to add to the framework if it hasn't already been done:<br>><br>> * RxFIFO. Currently can_bus_read only stores the latest CAN message in can_bus->can_rx_msg.</span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:12.0pt;color:#9900ff">> There is a FIXME note on this in can.c, line 188, but I couldn't find an implementation of it.</span><u></u><u></u></p></div></div><blockquote style="margin-left:30.0pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt"><div><div><p class="MsoNormal"><span style="font-size:12.0pt;color:black">Currently, the CAN framework has minimal rx support. The design of the rx data path in the CAN Framework is ready (You could use that design if approved or you can have your own design).</span><u></u><u></u></p></div></div><div><p class="MsoNormal"><span style="font-size:12.0pt"> </span><u></u><u></u></p></div></blockquote><blockquote style="margin-left:30.0pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt"><div><p class="MsoNormal"><span style="font-size:12.0pt;color:black">Note: The tx data path has been implemented, it supports multiple open among different tasks, configurable buffers.</span><u></u><u></u></p></div></blockquote><div><div><p class="MsoNormal"><span style="font-size:12.0pt;color:#9900ff">><br>> * ioctl functionality. can_bus_ioctl does not forward the commands and arguments to can_dev_ops->dev_ioctl.</span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:12.0pt;color:#9900ff">> Is there a reason for that? I propose a command enum that would provide consistency.</span><u></u><u></u></p></div></div><blockquote style="margin-left:30.0pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt"><div><p class="MsoNormal"><span style="font-size:12.0pt">The bsp CAN driver should register the ioctl api with the CAN Framework for device specific commands (To add commands for hardware independent functionality the commands can be added before "if (bus == NULL || bus->can_dev_ops->dev_ioctl == NULL)" statement.</span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:12.0pt"> </span><u></u><u></u></p></div></blockquote><blockquote style="margin-left:30.0pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt"><div><div><p class="MsoNormal"><span style="font-size:12.0pt">struct can_dev_ops dev_ops (.dev_ioctl member should be registered).</span><u></u><u></u></p></div></div></blockquote><div><div><p class="MsoNormal"><span style="font-size:12.0pt;color:#9900ff">></span><span style="font-size:12.0pt;color:#500050"> </span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:12.0pt;color:#9900ff">><br>> @Prashanth S (<a href="mailto:fishesprashanth@gmail.com" target="_blank" rel="noreferrer">fishesprashanth@gmail.com</a>) have you already worked on these points?</span><u></u><u></u></p></div></div><div><p class="MsoNormal"><span style="font-size:12.0pt;color:#500050"> </span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:12.0pt">For the overview of the CAN framework, tx, rx, data paths you can refer the docs files in the gitlab link (.puml version of the docs are also available if you needed (<a href="https://gitlab.com/slpp95prashanth/gsoc-2022/-/commit/f42e192afefdd94a66456181f9d169f0728d5b4f)" target="_blank" rel="noreferrer">https://gitlab.com/slpp95prashanth/gsoc-2022/-/commit/f42e192afefdd94a66456181f9d169f0728d5b4f)</a>).</span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:12.0pt"> </span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:12.0pt">You can use the gitlab <a href="https://gitlab.com/slpp95prashanth/gsoc-2022/-/tree/can-bsp-docs/can-docs" target="_blank" rel="noreferrer">https://gitlab.com/slpp95prashanth/gsoc-2022/-/tree/can-bsp-docs/can-docs</a> link for the design documents.</span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:12.0pt"> </span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:12.0pt">Regards</span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:12.0pt;color:#888888">Prashanth S</span><u></u><u></u></p></div></div></div></div></div></div></blockquote></div></div></div></blockquote></div>