lin-bus / linux-lin

Linux kernel LIN bus support implemented as TTY line discipline for generic UART conrollers, documentation https://github.com/lin-bus/linux-lin/wiki, based on https://github.com/lin-bus/linux-lin/wiki/sllin-rtlws14-paper.pdf, more CAN related projects http://canbus.pages.fel.cvut.cz/
https://github.com/lin-bus/linux-lin/wiki
38 stars 26 forks source link

Doesn't work with newer kernel versions #3

Closed kbader94 closed 3 years ago

kbader94 commented 3 years ago

In addition to your previously mentioned kernel changes & changing the LDISC, the project doesn't work on newer kernel versions because of changes in alloc_netdev. Changing sll_alloc() to:

    size = ALIGN(sizeof(*sl), NETDEV_ALIGN) + sizeof(struct can_ml_priv);
    dev = alloc_netdev(size, name, NET_NAME_UNKNOWN, sll_setup);

` and

sl = netdev_priv(dev);
dev->ml_priv = (void *)sl + ALIGN(sizeof(*sl), NETDEV_ALIGN);

seems to make it run on kernel v5.10.17

ppisa commented 3 years ago

Thanks for the report. I would prefer to find solution which works even for the older kernels. As discussed in the previous issue, at this moment I would consider 4.4 as the alive still.

Please report problems again https://github.com/ppisa/linux-lin . I have started UART LIN support with my students on the demand of Oliver Hartkopp from Volkswagen in 2011.

We have used GIT repo outside GitHub then I have found that trainman419 setup repo on GitHub without notice to us. When I have found this repo I have integrated and cleand what I have found, but there are no changes from 2016. This stalled repo has been forked by many other people. Because our mainline has not been followed, I have created own fork of this repo on GitHub to at least point users to the progress by Insight Networking. So, please check state in my repo https://github.com/ppisa/linux-lin which I try to maintain, mostly in spare time, I have no actual LIN project now.

As for the line discipline collision, we need to register that into mainline and even push the project into mainline. But it depends on the some statistics and reports that our project is really in use which would backup mainlining.

kbader94 commented 3 years ago

Yea the code is kind of pseudo code, you'd definitely want an if statement to handle different versions I just didn't get to finding which version it changes in yet. I didn't realize any of these repos were active I'm definitely willing to fork yours and work towards getting this working with newer kernel versions. It's kind of on my back burner right now, though I do plan on getting it fully implemented at least with my device(a Raspberry pi 4) but from what I understand universal support is out the door without kernel support for universal 1 byte fifo buffers.

ppisa commented 3 years ago

I have prepared pull request based on your patches, redundant patches squashed, line discipline number changes separated.

As for the module parameters, control of master/slave by module parameters is problematic, because you can have more interfaces. So my preference is to use two line disciplines or find way how to send parameter during attach. To document which number is used for master and slave, I suggest t export numbers through sys or proc interface. One option is to add module paramenetrs ldisc_master and ldisc_slave which allows to obtain actual values used by module registration from

/sys/module/sllin/parameters

for now before we get registered into mainline kernel.

Please test with available kernels that I have not introduced some problem.

ppisa commented 3 years ago

@kbader94 work and testing resolved compatibility with 5.10+ linux kernels. Thanks.

It is highly probable that compatibility would be broken again as mainline evolves, please open new issue in such case. Long term solution is to mainline slLIN.