[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2023082403-masculine-scuttle-f0ad@gregkh>
Date: Thu, 24 Aug 2023 16:48:52 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Simon Arlott <simon@...iron.net>
Cc: Oliver Neukum <oneukum@...e.com>,
Jiri Slaby <jirislaby@...nel.org>,
linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
linux-serial@...r.kernel.org
Subject: Re: [PATCH] USB: cdc-acm: expose serial close_delay and closing_wait
in sysfs
On Wed, Aug 23, 2023 at 09:37:45PM +0100, Simon Arlott wrote:
> If the serial device never reads data written to it (because it is "output
> only") then the write buffers will still be waiting for the URB to complete
> on close(), which will hang for 30s until the closing_wait timeout expires.
>
> This can happen with the ESP32-H2/ESP32-C6 USB serial interface. Instead of
> changing all userspace applications to flush (discard) their output in this
> specific scenario it would be easier to adjust the closing_wait timeout
> with udev rules but the only available interface is the TIOCGSERIAL ioctl.
Then why not use that?
> The serial_core driver (ttySx) exposes its supported ioctl values as
> read-only sysfs attributes. Add read-write sysfs attributes "close_delay"
> and "closing_wait" to cdc-acm (ttyACMx) devices. These are the same as the
> attributes in serial_core except that the "closing_wait" sysfs values are
> modified so that "-1" is used for "infinite wait" (instead of 0) and "0"
> is used for "no wait" (instead of 65535).
Adding tty-driver-specific sysfs files for tty devices is a big no-no,
sorry. We don't want to go down that rabbit hole at all.
If any apis are needed, let's make them for all tty devices, through the
existing ioctl api, so they work for all devices and userspace doesn't
have to try to figure out just exactly what type of tty/serial device it
is talking to (as that will not scale and is exactly the opposite of
what common apis are for.)
sorry, we can't take this, and in the end, you don't want us to as it's
not maintainable.
thanks,
greg k-h
Powered by blists - more mailing lists