Hello Randy and Rob, thanks much for review, I have corrected FPGA spelling and binding YAML license. On Sunday 16 of August 2020 01:28:13 Randy Dunlap wrote: > On 8/15/20 12:43 PM, Pavel Pisa wrote: > > diff --git a/drivers/net/can/ctucanfd/Kconfig > > b/drivers/net/can/ctucanfd/Kconfig index e1636373628a..a8c9cc38f216 > > 100644 > > --- a/drivers/net/can/ctucanfd/Kconfig > > +++ b/drivers/net/can/ctucanfd/Kconfig > > @@ -21,4 +21,15 @@ config CAN_CTUCANFD_PCI > > PCIe board with PiKRON.com designed transceiver riser shield is > > available at https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd . > > > > +config CAN_CTUCANFD_PLATFORM > > + tristate "CTU CAN-FD IP core platform (FPGA, SoC) driver" > > + depends on OF > > Can this be > depends on OF || COMPILE_TEST > ? I am not sure for this change. Is it ensured/documented somewhere that header files provide dummy definition such way, that OF drivers builds even if OF support is disabled? If I remember well, CTU CAN FD OF module build fails if attempted in the frame of native x86_64 build where OF has been disabled. Does COMPILE_TEST ensure that such build succeeds. As for the next steps, I expect that without any review of Marc Kleine-Budde or Wolfgang Grandegger from initial attempt for submission from February 2019, we are at the end of the road now. If there is confirmed preference, I would shorten license headers in the C files, but I am not sure if SPDX-License-Identifier is recognized by copyright law and because code and CTU CAN FD IP can be used outside of Linux kernel by others, we would like to keep legally binding preamble. It is reduced by not listing address to obtain complete GPL-2.0 from anyway. And change of preamble requires to update main repository, because header files are generated from IP core IPXACT definition by Python based tools. I am aware of only one other suggestion not followed yet and it is separation of part of ctucan_tx_interrupt() function into new one suggested by Pavel Machek. I agree that function length of 108 lines is big. When blank lines are removed we are on 68 lines and 28 lines are switch statement. The function consist of two nested loops. External one required to ensure no lost interrupt when edge triggered delivery or implementation is used. For me personally, it is more readable in the actual format then to separate and propagate local variables to another function. And particular function code received only formatting and ctu_can_fd_ -> ctucan_hw_ rename in past year so it is tested many/many times by manual PCI test and automated Zynq tests. Each of the following pipelines which contains two jobs ands by test of FPGA design and driver build and tests on real HW https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top/pipelines You can go through years of the testing and development back. So I have even tendency to not shuffle code which does not result in indisputable better readability and breaks more than year of unmodified code successful (pass) test result line and confidence. Because I understand that you all are loaded a lot I expect that after ACK/review-by by Rob, there is no need to send v6 to devicetree@xxxxxxxxxxxxxxx I am not sure about cross-post to netdev@xxxxxxxxxxxxxxx linux-kernel@xxxxxxxxxxxxxxx when the progress is stuck on linux-can@xxxxxxxxxxxxxxx Problem is that linux-can seems to eat core driver patch, probably because it is too long. Thanks to all for patience and if somebody does want to be loaded by minor updates, resends and pings to linux-can, send me note to not bother you again. Thanks for your time, Pavel PS: I would be available on Drew Fustini's LPC 2020 BoF: upstream drivers for open source FPGA SoC peripherals today. If there is interrest I can provide some information and show some overview and results.