Re: [PATCH v5 12/14] serial: 8250: allow UART drivers to override rx_trig_bytes handling
Andy Shevchenko <[email protected]> Sun, 2 Aug 2026 12:20:18 +0300
| Newsgroups | org.kernel.vger.linux-serial,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CAHp75VcRkgsBOYWwk9pUxDvc4-YmSvVn0fkrhPSHHerwykVvWQ@mail.gmail.com> |
On Fri, Jul 31, 2026 at 10:49=E2=80=AFAM Crescent Hsieh <[email protected]> wrote: > > The rx_trig_bytes sysfs attribute currently relies on 8250-internal > helper functions and assumes a fixed mapping between trigger levels and > FIFO behavior. > > Some UARTs provide hardware-specific RX trigger mechanisms that do not > fit this model. Add optional uart_port callbacks for setting and getting > the RX trigger level, and use them when provided, while preserving the > existing 8250 helpers as the default fallback. ... > struct tty_port *port =3D dev_get_drvdata(dev); > + struct uart_state *state =3D container_of(port, struct uart_state= , port); > + struct uart_port *uport =3D state->uart_port; > int rxtrig_bytes; Hmm... do_set_rxtrig() and do_get_rxtrig() do the same, but under the mutex lock. Hence there are questions: - is it correct to have without mutex? - if so, why not to propagate these (if you really need it), to the callees= ? - or should these callbacks be integrated in the lower level? > - rxtrig_bytes =3D do_serial8250_get_rxtrig(port); > + if (uport->get_rxtrig) > + rxtrig_bytes =3D uport->get_rxtrig(uport); > + else > + rxtrig_bytes =3D do_serial8250_get_rxtrig(port); --=20 With Best Regards, Andy Shevchenko