Re: [PATCH v1 4/4] usb: serial: mxuport: add sysfs control for UART FIFO

[Johan Hovold <johan@kernel.org>]

On Tue, May 12, 2026 at 07:28:19PM +0800, Crescent Hsieh wrote:
> On Thu, May 07, 2026 at 05:59:05PM +0200, Johan Hovold wrote:
> > On Tue, Mar 24, 2026 at 11:50:41AM +0800, Crescent Hsieh wrote:
> > > Add a per-port sysfs attribute, uart_fifo, to allow userspace to enable
> > > or disable the UART FIFO at runtime.
> > 
> > Why would you want to do that?
> > 
> > We should try to avoid driver specific sysfs knobs.
> 
> The motivation is to allow userspace to choose between lower latency and
> higher throughput at runtime. Some latency-sensitive request/response
> deployments become unreliable if the UART FIFO is enabled due to the
> added buffering delay.

Please mention this in the commit message.

> I understand the concern about driver-specific sysfs knobs. UART FIFO
> enable/disable seems more like a common UART capability than a
> device-unique behaviour.
> 
> If a driver-specific sysfs attribute is not the right approach here, do
> you have a suggestion for a better interface?

We have one USB serial driver and one serial driver using the legacy
ASYNC_LOW_LATENCY flag (which can be set using setserial) to set the
lowest rx fifo trigger level.

I'm not sure we want to promote further use of it though.

We also have a couple of non-documented driver-specific sysfs attributes
(and a module parameter) and one documented interface for 8250, which may
be considered the standard way to set the rx fifo trigger level:

	/sys/class/tty/ttyS<x>/rx_trig_bytes

I guess something like that could be generalised to mxuport as disabling
the FIFOs is effectively setting a trigger level of one character.

What exactly does RQ_VENDOR_SET_FIFO_DISABLE do? Does it really disable
the TX fifo? That doesn't seem to make much sense, especially since you
already have the endpoint buffers.

What happens if you flip this switch while the port is in use?

Johan