Hello Oliver, On Wednesday 20 of April 2022 18:40:18 Oliver Hartkopp wrote: > On 19.04.22 17:35, Marc Kleine-Budde wrote: > > On 06.04.2022 10:20:42, Pavel Pisa wrote: > >> I have missed timing for 5.18 but v5.18-rc1 is out so I would be > >> happy if we do not miss 5.19 merge window at least with minimal version. > > > > I've taken the patch (almost) as is, I marked both can_bittiming_const > > static, as sparse complained about that and I changed the order of two > > variable declarations to look nicer :) > > > > Looking forward for more patches! > > The patches now landed in net-next \o/ This is a big day... > But while checking the automatic review results from Patchwork here ... > > https://patchwork.kernel.org/project/netdevbpf/list/?series=&submitter=7454 >&state=*&q=CTU+CAN+FD&archive=&delegate= > > ... it looks like that at least the two red 'failed' markers should be > addressed in follow up patches. > > The 'inline' warnings are easy to fix: > > https://patchwork.hopto.org/static/nipa/633430/12818712/source_inline/stder If it means that no local function should be marked as inline if they are in C file then inline removal is fully OK and according to current compilers behavior probably comletely equivalent. > But the module_param()'s in > > https://patchwork.hopto.org/static/nipa/633430/12818710/module_param/stderr > > should probably be revisited, whether the parameters (PCI/MSI and > 'second IP core') could be handled by some automatic detection. The situation is handled automatically. The parameters are there only for situation when there is problem with PCIe design on the FPGA side to allow disable MSI interrupts and test if without that FPGA behaves correctly. It is great help to debug problems. In my case, if I remember well, problem was that some reference clocks has not been connected into core so it could sync for CPU initiated transfers and for MSI own initiated it failed horribly. > Or did I miss something that makes these module parameters really > necessary? They can go away for normal use. They are help for those who want to debug problems of CTU CAN FD core connection to PCIe FPGA design to test and identify one of possible sources problems sources in in the PCIe core setup and clocking. But that can be kept as separate patches for debugging purposes. Parameters can be connected directly to instances in sys or tuned some other way as well. But I think that they do no belong to netling or something networking related. It is strictly related to hardware and module load testing after magic sequence to get rid of broken test FPGA design and rescan for newly loaded Intel/Altera FPGA design https://gitlab.fel.cvut.cz/canbus/pcie-ctucanfd/-/blob/master/scripts/db4cgx15-program https://gitlab.fel.cvut.cz/canbus/pcie-ctucanfd/-/blob/master/scripts/test-ip-read Device reapears after echo 1 > /sys/bus/pci/rescan then driver can be connected and tested. But I prepare patch to get remove these debug options when it is preferred. I expect that we test net-next soon and Mataj Vasilevski prepares patches for timestamping. Probably optional/controlled by some compile time option. Again it is good to have option to eliminate possible source of problems. The base has been tested really many times but addons are relatively new. Best wises, Pavel -- Pavel Pisa phone: +420 603531357 e-mail: pisa@xxxxxxxxxxxxxxxx Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35, Prague 2 university: http://control.fel.cvut.cz/ personal: http://cmp.felk.cvut.cz/~pisa projects: https://www.openhub.net/accounts/ppisa CAN related:http://canbus.pages.fel.cvut.cz/ Open Technologies Research Education and Exchange Services https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
