On Sun, Jan 16, 2022 at 8:06 PM Pavel Pisa <pisa@xxxxxxxxxxxxxxxx> wrote: > > Dear Wander and Greg, > Hi there, Notice that by no means I am an expert either on the TTY or CAN subsystems. > [resend on base of email-bot of Greg Kroah-Hartman's inbox] > > I have noticed that you have sent enhancements > to the TTY layer. > > I have worked on architecture of automotive LIN-bus > support for Linux UARTs. The SocketCAN API was idea > of Oliver Hartkopp and we have designed internals > to implement actual protocol. Rostislav Lisovy > was main author at our university in 2011. The code > has been used and is used by more people and I have > helped its integration to local Volkswagen subsidiary > projects. I have helped to maintain it for years > even that I have actually no use for it or contract. > But is seems usable... > > I am not sure if it can reach quality standards > for mainline but I have tried to consolidate > many forks and copies from our original GIT > server which can be found on GitHub and united > project under > > https://github.com/lin-bus > > Kernel part - slLIN TTY discipline - can be found there > > https://github.com/lin-bus/linux-lin/tree/master/sllin > > Documentation > > https://github.com/lin-bus/linux-lin/wiki/ > > The main obstacle to have version which can be used > with different UARTs seamlessly is missing internal low > level kernel API which would allow to control Rx trig > level. > Do you mean the electric wire-level or Rx buffer threshold? > I have not checked your changes yet but I would be happy > if some API is available for this control. Please see > issue > > https://github.com/lin-bus/linux-lin/issues/13 > >From what I read I believe you are talking about the FIFO threshold. One approach Is adding a new function to serdev_controller_ops for supported (and tested) controllers, I think. > Please suggest where to discuss the proposal/solutions > or if you plan to implement something like that. > > I would be happy to work on that myself or with my students > but I personally do not get to that probably earlier > than in summer. I have to finish project for European Space > Agency at PiKRON company. We have quite lot of work > to switch our Computer Architectures classes and corresponding > QtMips/QtRvSim simulator to RISC-V etc... > Mainlining CTU CAN FD driver has higher priority than LIN for > me as well. > > So my actual motivation is to document the need and get some > feedback if some such solution is on the horizon > and what should API look like if I get to it ourselves etc.. > As Greg said, it is easier to organize the work in a series of patches and send them for review. > Best wishes, > > 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://dce.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 > >
