From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Simon Arlott <simon@octiron.net>
Cc: Oliver Neukum <oneukum@suse.com>,
Jiri Slaby <jirislaby@kernel.org>,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-serial@vger.kernel.org
Subject: Re: [PATCH] USB: cdc-acm: expose serial close_delay and closing_wait in sysfs
Date: Thu, 24 Aug 2023 16:48:52 +0200 [thread overview]
Message-ID: <2023082403-masculine-scuttle-f0ad@gregkh> (raw)
In-Reply-To: <ea1a13ad-a1e0-540a-e97a-4c44f6d2d33b@0882a8b5-c6c3-11e9-b005-00805fc181fe.uuid.home.arpa>
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
next prev parent reply other threads:[~2023-08-24 14:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-23 20:37 [PATCH] USB: cdc-acm: expose serial close_delay and closing_wait in sysfs Simon Arlott
2023-08-23 21:12 ` [PATCH (v2)] " Simon Arlott
2023-08-24 7:18 ` [PATCH] docs: ABI: sysfs-tty: close times are in hundredths of a second Simon Arlott
2023-08-25 5:33 ` Jiri Slaby
2023-08-27 18:23 ` [PATCH (v2)] docs: ABI: sysfs-tty: close times are in centiseconds Simon Arlott
2023-08-24 8:21 ` [PATCH] USB: cdc-acm: expose serial close_delay and closing_wait in sysfs Oliver Neukum
2023-08-24 14:48 ` Greg Kroah-Hartman [this message]
2023-08-24 18:02 ` Simon Arlott
2023-08-24 19:22 ` Greg Kroah-Hartman
2023-08-27 15:36 ` Simon Arlott
2023-08-24 23:46 ` Oliver Neukum
2023-08-25 1:53 ` Alan Stern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2023082403-masculine-scuttle-f0ad@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=oneukum@suse.com \
--cc=simon@octiron.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox