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 gmane.linux.serial,gmane.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