Dear Greg, thanks for the reply. On Monday 17 of January 2022 14:03:18 Greg Kroah-Hartman wrote: > On Mon, Jan 17, 2022 at 12:06:31AM +0100, Pavel Pisa wrote: > > https://github.com/lin-bus > > > > Kernel part - slLIN TTY discipline - can be found there > > > > https://github.com/lin-bus/linux-lin/tree/master/sllin > > So it's just a 2000 line kernel module? That should be easy to turn > into a patch and submit for review, right? > > Odds are it can be made much smaller based on an initial glance at it. > Review comments can help show what to do. Thanks for encouragement for mainlining or at least review on the list. I agree that it can shrink when patch for mainline without sections providing compatibility with old kernels is prepared. Generally, I think that it is doable and important is feedback from the user base that there is interrest... and time... I think that resolution of APO for the trigger/FIFO control is critical for thinking about mainlining. Rest is the usual work... > > https://github.com/lin-bus/linux-lin/issues/13 > > > Discuss it here by submitting patches please. Links to random github > repos do not do much as we can do nothing with them, sorry. Yes, I understand but I would like to hear some suggestion the first where/into which object operations structure should be the function added. There is required functionality in 8250 driver linux/drivers/tty/serial/8250/8250_port.c do_set_rxtrig(struct tty_port *port, unsigned char bytes) do_serial8250_set_rxtrig(...) serial8250_set_attr_rx_trig_bytes(...) DEVICE_ATTR_RW(rx_trig_bytes) But to make slLIN generally usable, we would need to have functionality reachable from the line discipline Do you agree that right place is struct uart_ops? https://elixir.bootlin.com/linux/latest/source/include/linux/serial_core.h#L38 What should be a prototype? In general, it would worth to have possibility to set Rx trigger level and Rx iddle timeout. It would be ideal if the set function would adjust value down to the first equal or smaller level supported by uart HW and in the case of lack of support can switch FIFO off. The iddle time can be specified in microseconds, nanoseconds and or number of character times. So questions: Is more preferred to add two functions, one for iddle time, one for trigger level or combined function is better? How should work reporting of the supported values? Should there be more functions etc... I can imagine generic API which would provide all functionality by single function to not inflate struct uart_ops too much. int (*rx_trigger)(struct uart_port *, int mode, int *rx_trigger_bytes, int *rx_trigger_iddle_time) The rx_trigger_bytes equal to 0 would mean switch FIFO off. Trigger time can be in nanoseconds??? and would be recomputed to number of character for some, most of the HW??? The mode could have UART_RX_TRIGGER_MODE_SET UART_RX_TRIGGER_MODE_CHECK_ROUND_DOWN UART_RX_TRIGGER_MODE_CHECK_ROUND_UP When specified parameters cannot be set, the function returns error. When called with ROUND_UP/DOWN it modifies parameters to the first available value in given direction and next call to UART_RX_TRIGGER_MODE_SET would be guaranteed to succeed. Other option is to combine functionality to set_termios call, but it is quite convoluted by its history and connection to user space API. Not that maintaining trigger levels from userspace is not usefull, but... I would be happy if you or somebody other with linux kernel and serial port style taste would comment. Best wishes ant thanks for your time and work, 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
