Re: TTY layer discussion about generic FIFO depth and Rx iddle timeout control

[Wander Costa <wcosta@redhat.com>]

On Wed, Jan 26, 2022 at 5:55 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Wed, Jan 19, 2022 at 02:46:28PM +0100, Pavel Pisa wrote:
> > 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?
>
> For all of these questions, I do not know.  Try it out yourself first
> and see what you feel works best.  We will be glad to review working
> patches, but to discuss options before that is difficult and not
> something we normally worry about.
>

That gives me some time to find more machines to test the fixes.

> thanks,
>
> greg k-h
>