This series adds a new NORDY port flag to suppress raising the
modem-control lines on open to signal DTE readiness.
This can be used to implement a NORDY termios control flag to complement
HUPCL, which controls lowering of the modem-control lines on final
close.
Initially drivers can export the flag through sysfs, which also allows
control over the lines on first open. Such an interface is implemented
for serial core and USB serial.
The motivation for this is to allow for applications where the DTR and
RTS lines are used for non-standard purposes (e.g. generating power-on
and reset pulses) to open the port without undesirable side effects.
The final patches enables this flag by default for such a USB serial
device.
Greg, are you ok we me taking this through my tree? I'm planning on some
follow ups to the ftdi driver and the tty/serial changes are fairly
self-contained.
Johan
Johan Hovold (3):
tty: add port flag to suppress ready signalling on open
serial: core: add sysfs attribute to suppress ready signalling on open
USB: serial: add sysfs attribute to suppress ready signalling on open
Mychaela N. Falconia (2):
USB: serial: ftdi_sio: pass port to quirk port_probe functions
USB: serial: ftdi_sio: add support for FreeCalypso DUART28C adapter
Documentation/ABI/testing/sysfs-tty | 7 +++++
drivers/tty/serial/serial_core.c | 29 ++++++++++++++++++++
drivers/tty/tty_port.c | 2 +-
drivers/usb/serial/bus.c | 38 ++++++++++++++++++++++++--
drivers/usb/serial/ftdi_sio.c | 42 +++++++++++++++++++++++------
drivers/usb/serial/ftdi_sio_ids.h | 1 +
include/linux/tty.h | 14 ++++++++++
7 files changed, 122 insertions(+), 11 deletions(-)
--
2.26.2
A quick background for Greg and others who haven't seen the Sept-Oct
discussion between me and Johan on the linux-usb ML: I am the hardware
engineer who designed the FT2232D-based DUART28C adapter board, and it
was my desire to have this custom FT2232D adapter supported in mainline
Linux that triggered the chain of discussions and patch revisions that
led to the present patch series by Johan.
My FTDI-based USB to dual UART adapter is special in that the DTR &
RTS signals on one of the two UART channels (FT2232D Channel B
specifically) have been repurposed for a non-serial, non-modem-control
use: they control open drain drivers (a Nexperia 74LVC2G07 buffer IC)
which drive PWON & RESET control signals that would otherwise be
driven by short-to-ground human-finger-operated pushbutton switches.
The standard Unix/POSIX/Linux behaviour (going all the way back to
1970s Original UNIX) of automatically asserting DTR & RTS on serial
port open is a killer for custom hw in which these signals have been
repurposed, thus I need some way to suppress this automatic DTR & RTS
assertion on tty device open. With automatic assertion on open
suppressed, these two signals can then be freely manipulated by
userspace via TIOCMBIS and TIOCMBIC.
There have certainly been other serial devices in the past (whether
true RS-232 or USB-serial) in which DTR and/or RTS has been repurposed
for some non-standard use that does not tolerate unwanted auto-assert
on every device open, and to the best of my knowledge this problem
does not occur on Windows - thus it is quite possible that some other
hw engineer somewhere out there could design and build a custom serial
or USB-serial device with repurposed DTR/RTS that works fine under
Windows, but the moment someone in Linux community tries to get it
working under our free OS, they will run into the problem of unwanted
DTR & RTS auto-assertion on device open.
In our previous discussion Johan said "this has come up the in past",
referring to repurposed DTR and/or RTS signals doing non-standard
things, thus I find it a little surprising that this issue hasn't been
solved long before my time - but I guess I must be the first to
complain loudly enough to get something done about it, and someone
always has to be the first...
Johan's patch series provides two workable solutions to the problem of
unwanted DTR & RTS auto-assertion:
1) For hardware engineers like me who design and build their own
boards with the USB-serial chip fully embedded and who have their own
custom USB IDs, a driver quirk can be applied (as part of adding
support for the new USB ID) that sets the new tty port flag upon
detecting the USB ID of the custom hw device for which it is required
- this approach provides the highest level of friendliness to the
ultimate end user of the finished hardware product.
2) For situations in which the luxury of a custom USB ID is not
available, e.g., a situation where the device that does not tolerate
automatic DTR/RTS assertion on open is a physical RS-232 device that
can be connected to "any" serial port, the new sysfs attribute comes
to the rescue.
Johan's patch comments say that the new flag can also be brought out
to termios in the future, similarly to HUPCL, but I question the
usefulness of doing so, as it is a chicken and egg problem: one needs
to open the tty device in order to do termios ioctls on it, and if
that initial open triggers DTR/RTS hardware actions, then the end user
is still screwed. If Johan or someone else can see a potential use
case for manipulating this new flag via termios (as opposed to sysfs
or USB-ID-based driver quirks), perhaps you could elaborate on it?
Andy Shevchenko wrote:
> > Add a nordy sysfs attribute to suppress raising the modem-control lines
> > on open to signal DTE readiness.
>
> Why not call it nomctrl ?
I have no opinion one way or another as to what the new sysfs attribute
should be called - my use case won't involve this sysfs mechanism at
all, instead I care much more about the path where the tty port flag
gets set via a driver quirk upon seeing my custom USB ID. :)
The naming of the internal tty port flag is likewise a matter which I
gladly leave to more qualified kernel developers like Johan and Greg.
In any case, it would be really awesome if this patch series (with or
without further modifications) can make it into 5.10 - any chance of
such happening, or will it have to be pushed out to 5.11?
Sincerely,
Mychaela,
freelance hardware and software engineer,
she/her/hers
Add a nordy sysfs attribute to suppress raising the modem-control lines
on open to signal DTE readiness.
This can be use to prevent undesirable side-effects on open for
applications where the DTR and RTS lines are used for non-standard
purposes such as generating power-on and reset pulses.
Signed-off-by: Johan Hovold <[email protected]>
---
Documentation/ABI/testing/sysfs-tty | 7 +++++++
drivers/tty/serial/serial_core.c | 29 +++++++++++++++++++++++++++++
2 files changed, 36 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-tty b/Documentation/ABI/testing/sysfs-tty
index e157130a6792..2634b4bf9c7f 100644
--- a/Documentation/ABI/testing/sysfs-tty
+++ b/Documentation/ABI/testing/sysfs-tty
@@ -161,3 +161,10 @@ Contact: Andy Shevchenko <[email protected]>
Description:
Allows user to detach or attach back the given device as
kernel console. It shows and accepts a boolean variable.
+
+What: /sys/class/tty/ttyS0/nordy
+Date: November 2020
+Contact: Johan Hovold <[email protected]>
+Description:
+ Show and store the port NORDY flag which suppresses raising
+ the modem-control lines on open to signal DTE readiness.
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index f41cba10b86b..063a617182ce 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -2805,6 +2805,33 @@ static ssize_t console_store(struct device *dev,
return ret < 0 ? ret : count;
}
+static ssize_t nordy_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct tty_port *port = dev_get_drvdata(dev);
+
+ return sprintf(buf, "%d\n", tty_port_nordy(port));
+}
+
+static ssize_t nordy_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct tty_port *port = dev_get_drvdata(dev);
+ unsigned int val;
+ int ret;
+
+ ret = kstrtouint(buf, 0, &val);
+ if (ret)
+ return ret;
+
+ if (val > 1)
+ return -EINVAL;
+
+ tty_port_set_nordy(port, val);
+
+ return count;
+}
+
static DEVICE_ATTR_RO(uartclk);
static DEVICE_ATTR_RO(type);
static DEVICE_ATTR_RO(line);
@@ -2819,6 +2846,7 @@ static DEVICE_ATTR_RO(io_type);
static DEVICE_ATTR_RO(iomem_base);
static DEVICE_ATTR_RO(iomem_reg_shift);
static DEVICE_ATTR_RW(console);
+static DEVICE_ATTR_RW(nordy);
static struct attribute *tty_dev_attrs[] = {
&dev_attr_uartclk.attr,
@@ -2835,6 +2863,7 @@ static struct attribute *tty_dev_attrs[] = {
&dev_attr_iomem_base.attr,
&dev_attr_iomem_reg_shift.attr,
&dev_attr_console.attr,
+ &dev_attr_nordy.attr,
NULL
};
--
2.26.2
On 30. 11. 20, 22:22, Mychaela Falconia wrote:
> 2) For situations in which the luxury of a custom USB ID is not
> available, e.g., a situation where the device that does not tolerate
> automatic DTR/RTS assertion on open is a physical RS-232 device that
> can be connected to "any" serial port, the new sysfs attribute comes
> to the rescue.
>
> Johan's patch comments say that the new flag can also be brought out
> to termios in the future, similarly to HUPCL,
The difference to other control flags is that open raises DTR/RTS in any
case (i.e. including O_NONBLOCK) -- provided baud rate is set (and it is
for casual serials). That means you cannot open a port to configure it
(using e.g. setserial) without actually raising the DTR/RTS.
> but I question the
> usefulness of doing so, as it is a chicken and egg problem: one needs
> to open the tty device in order to do termios ioctls on it, and if
> that initial open triggers DTR/RTS hardware actions, then the end user
> is still screwed. If Johan or someone else can see a potential use
> case for manipulating this new flag via termios (as opposed to sysfs
> or USB-ID-based driver quirks), perhaps you could elaborate on it?
We would need to (ab)use another open flag (e.g. O_DIRECT). I am not
biased to either of solutions.
thanks,
--
js
On 11/30/20, Jiri Slaby <[email protected]> wrote:
> The difference to other control flags is that open raises DTR/RTS in any
> case (i.e. including O_NONBLOCK)
Yes, this is the exact root-cause problem I am trying to fix, with Johan's help.
> -- provided baud rate is set (and it is
> for casual serials). That means you cannot open a port to configure it
> (using e.g. setserial) without actually raising the DTR/RTS.
Exactly.
M~
On Tue, Dec 01, 2020 at 12:48:48PM +0200, Andy Shevchenko wrote:
> On Mon, Nov 30, 2020 at 11:25 PM Mychaela Falconia
> <[email protected]> wrote:
> > > Why not call it nomctrl ?
> >
> > I have no opinion one way or another as to what the new sysfs attribute
> > should be called - my use case won't involve this sysfs mechanism at
> > all, instead I care much more about the path where the tty port flag
> > gets set via a driver quirk upon seeing my custom USB ID. :)
>
> Then why do we bother with sysfs right now? It's an ABI and Johan is
> completely aware and knows that once it's in the kernel it is close to
> being carved in stone.
> I would vote to remove sysfs from now and see if we really need it in
> the future.
Eh, because this is generally useful and has come up in the past. I'm
not interested in adding quirks for odd devices that want non-standard
behaviour that we need to maintain indefinitely; that's precisely why I
proposed a general interface that can be use with any serial port.
Johan
On Tue, Dec 01, 2020 at 01:19:30PM +0200, Andy Shevchenko wrote:
> On Tue, Dec 1, 2020 at 1:04 PM Johan Hovold <[email protected]> wrote:
> > 0x01 is 1 and is generally treated as boolean true as you know.
>
> Depends how you interpret this. kstrtobool() uses one character (and
> in some cases two) of the input. Everything else is garbage.
> Should we interpret garbage?
No, ideally we should reject the input.
> > So why should a sysfs-interface accept it as valid input and treat it as
> > false? That's just bad design.
>
> I can agree with this.
Looks like part of the problem are commits like 4cc7ecb7f2a6 ("param:
convert some "on"/"off" users to strtobool") which destroyed perfectly
well-defined interfaces.
> > You miss the point; kstrobool accepts "12" today and treats it as true.
> > You cannot extend such an interface to later accept a larger range than
> > 0 and 1 as you didn't return an error for "12" from the start (as someone
> > might now rely on "12" being treated as "1").
>
> Somehow cifs uses kstrtobool() in conjunction with the wider ranges. Nobody
> complained so far. But maybe they had it from day 1.
Wow, that's pretty nasty.
> So, we have two issues here: kstrtobool() doesn't report an error of
> input when it has garbage, the user may rely on garbage to be
> discarded.
Right, parsing is too allowing and there are too many ways to say
true/false.
The power-management attributes use 0 and 1 for boolean like I do here,
and I'd prefer to stick to that until we have deprecated the current
kstrtobool.
Johan
On Tue, Dec 1, 2020 at 3:21 PM Johan Hovold <[email protected]> wrote:
> On Tue, Dec 01, 2020 at 01:19:30PM +0200, Andy Shevchenko wrote:
> > On Tue, Dec 1, 2020 at 1:04 PM Johan Hovold <[email protected]> wrote:
...
> > > 0x01 is 1 and is generally treated as boolean true as you know.
> >
> > Depends how you interpret this. kstrtobool() uses one character (and
> > in some cases two) of the input. Everything else is garbage.
> > Should we interpret garbage?
>
> No, ideally we should reject the input.
We can do it by the way in kstrtobool() and see if anybody complains
(I believe the world is saner than relying on 0x01 for false and 123
for true.
...
> > > So why should a sysfs-interface accept it as valid input and treat it as
> > > false? That's just bad design.
> >
> > I can agree with this.
>
> Looks like part of the problem are commits like 4cc7ecb7f2a6 ("param:
> convert some "on"/"off" users to strtobool") which destroyed perfectly
> well-defined interfaces.
Oh, but the strtobool() in ABI was before that, for instance
% git grep -n -p -w strtobool v3.14
shows a few dozens of users and some of them looks like ABI.
...
> > Somehow cifs uses kstrtobool() in conjunction with the wider ranges. Nobody
> > complained so far. But maybe they had it from day 1.
>
> Wow, that's pretty nasty.
I have checked, the wider range fits one character. So, basically they
had this kind of interface from day 1.
...
> > So, we have two issues here: kstrtobool() doesn't report an error of
> > input when it has garbage, the user may rely on garbage to be
> > discarded.
>
> Right, parsing is too allowing and there are too many ways to say
> true/false.
>
> The power-management attributes use 0 and 1 for boolean like I do here,
> and I'd prefer to stick to that until we have deprecated the current
> kstrtobool.
Okay!
--
With Best Regards,
Andy Shevchenko
On Tue, Dec 01, 2020 at 03:49:19PM +0200, Andy Shevchenko wrote:
> On Tue, Dec 1, 2020 at 3:21 PM Johan Hovold <[email protected]> wrote:
> > On Tue, Dec 01, 2020 at 01:19:30PM +0200, Andy Shevchenko wrote:
> > > On Tue, Dec 1, 2020 at 1:04 PM Johan Hovold <[email protected]> wrote:
>
> ...
>
> > > > 0x01 is 1 and is generally treated as boolean true as you know.
> > >
> > > Depends how you interpret this. kstrtobool() uses one character (and
> > > in some cases two) of the input. Everything else is garbage.
> > > Should we interpret garbage?
> >
> > No, ideally we should reject the input.
>
> We can do it by the way in kstrtobool() and see if anybody complains
> (I believe the world is saner than relying on 0x01 for false and 123
> for true.
I bet someone is using "YEAH!" just because they can. ;)
> ...
>
> > > > So why should a sysfs-interface accept it as valid input and treat it as
> > > > false? That's just bad design.
> > >
> > > I can agree with this.
> >
> > Looks like part of the problem are commits like 4cc7ecb7f2a6 ("param:
> > convert some "on"/"off" users to strtobool") which destroyed perfectly
> > well-defined interfaces.
>
> Oh, but the strtobool() in ABI was before that, for instance
> % git grep -n -p -w strtobool v3.14
> shows a few dozens of users and some of them looks like ABI.
Indeed, it apparently goes further back than strtobool(). The series
introducing strtobool() explicitly mentions the lax parsing and for that
reason wanted to keep it distinct from the other kstrto* function by
dropping the k-prefix:
The naming is still distinct enough from kstrtox to avoid any
implication that this function has the same tight parameter
passing that those functions have.
https://lore.kernel.org/lkml/[email protected]/#t
And it was more recently renamed kstrtobool() anyway.
Let's call it a feature then.
Johan
On Mon, Nov 30, 2020 at 01:22:07PM -0800, Mychaela Falconia wrote:
> Johan's patch comments say that the new flag can also be brought out
> to termios in the future, similarly to HUPCL, but I question the
> usefulness of doing so, as it is a chicken and egg problem: one needs
> to open the tty device in order to do termios ioctls on it, and if
> that initial open triggers DTR/RTS hardware actions, then the end user
> is still screwed. If Johan or someone else can see a potential use
> case for manipulating this new flag via termios (as opposed to sysfs
> or USB-ID-based driver quirks), perhaps you could elaborate on it?
Depending on the application it may be acceptable to assert the
modem-control lines on first open (e.g. before initialisation).
A new termios flag allows for a generic interface which could be shared
with other OSes and controlled through stty.
In case that isn't sufficient and you need control over the default port
setting, you can always fall back to the Linux-specific sysfs interface.
> In any case, it would be really awesome if this patch series (with or
> without further modifications) can make it into 5.10 - any chance of
> such happening, or will it have to be pushed out to 5.11?
Let's see, but I don't think this necessarily has to take that long to
get merged.
Johan
On Mon, Nov 30, 2020 at 11:25 PM Mychaela Falconia
<[email protected]> wrote:
...
> Johan's patch comments say that the new flag can also be brought out
> to termios in the future, similarly to HUPCL, but I question the
> usefulness of doing so, as it is a chicken and egg problem: one needs
> to open the tty device in order to do termios ioctls on it, and if
> that initial open triggers DTR/RTS hardware actions, then the end user
> is still screwed. If Johan or someone else can see a potential use
> case for manipulating this new flag via termios (as opposed to sysfs
> or USB-ID-based driver quirks), perhaps you could elaborate on it?
Thanks for the very detailed description of what you are working on.
Unfortunately I have no thoughts about alternative solutions.
> Andy Shevchenko wrote:
>
> > > Add a nordy sysfs attribute to suppress raising the modem-control lines
> > > on open to signal DTE readiness.
> >
> > Why not call it nomctrl ?
>
> I have no opinion one way or another as to what the new sysfs attribute
> should be called - my use case won't involve this sysfs mechanism at
> all, instead I care much more about the path where the tty port flag
> gets set via a driver quirk upon seeing my custom USB ID. :)
Then why do we bother with sysfs right now? It's an ABI and Johan is
completely aware and knows that once it's in the kernel it is close to
being carved in stone.
I would vote to remove sysfs from now and see if we really need it in
the future.
--
With Best Regards,
Andy Shevchenko
On Tue, Dec 01, 2020 at 08:14:07AM +0100, Jiri Slaby wrote:
> On 30. 11. 20, 22:22, Mychaela Falconia wrote:
> > 2) For situations in which the luxury of a custom USB ID is not
> > available, e.g., a situation where the device that does not tolerate
> > automatic DTR/RTS assertion on open is a physical RS-232 device that
> > can be connected to "any" serial port, the new sysfs attribute comes
> > to the rescue.
> >
> > Johan's patch comments say that the new flag can also be brought out
> > to termios in the future, similarly to HUPCL,
>
> The difference to other control flags is that open raises DTR/RTS in any
> case (i.e. including O_NONBLOCK) -- provided baud rate is set (and it is
> for casual serials). That means you cannot open a port to configure it
> (using e.g. setserial) without actually raising the DTR/RTS.
Right, but depending on the application this may be ok (e.g. reset and
initialise on first open after boot, which may have triggered a reset
anyway).
If control over first open is needed, the sysfs interface provides that
out-of-band.
> > but I question the
> > usefulness of doing so, as it is a chicken and egg problem: one needs
> > to open the tty device in order to do termios ioctls on it, and if
> > that initial open triggers DTR/RTS hardware actions, then the end user
> > is still screwed. If Johan or someone else can see a potential use
> > case for manipulating this new flag via termios (as opposed to sysfs
> > or USB-ID-based driver quirks), perhaps you could elaborate on it?
>
> We would need to (ab)use another open flag (e.g. O_DIRECT). I am not
> biased to either of solutions.
Forgot to mention that using open-flags would prevent using standard
utilities like cat, echo and terminal programs. So for that reason a
termios and/or sysfs interface is also preferred.
Johan
On 02. 12. 20, 12:48, Johan Hovold wrote:
>>> but I question the
>>> usefulness of doing so, as it is a chicken and egg problem: one needs
>>> to open the tty device in order to do termios ioctls on it, and if
>>> that initial open triggers DTR/RTS hardware actions, then the end user
>>> is still screwed. If Johan or someone else can see a potential use
>>> case for manipulating this new flag via termios (as opposed to sysfs
>>> or USB-ID-based driver quirks), perhaps you could elaborate on it?
>>
>> We would need to (ab)use another open flag (e.g. O_DIRECT). I am not
>> biased to either of solutions.
>
> Forgot to mention that using open-flags would prevent using standard
> utilities like cat, echo and terminal programs. So for that reason a
> termios and/or sysfs interface is also preferred.
Nope, I meant it differently. You set it up once using the special open
flag. Like with setserial, one sets I/O port, irqs etc. and then uses
standard tools as the port is already set up (marked as NORDY in this case).
thanks,
--
js
On Fri, Dec 04, 2020 at 07:58:53AM +0100, Jiri Slaby wrote:
> On 02. 12. 20, 12:48, Johan Hovold wrote:
> >>> but I question the
> >>> usefulness of doing so, as it is a chicken and egg problem: one needs
> >>> to open the tty device in order to do termios ioctls on it, and if
> >>> that initial open triggers DTR/RTS hardware actions, then the end user
> >>> is still screwed. If Johan or someone else can see a potential use
> >>> case for manipulating this new flag via termios (as opposed to sysfs
> >>> or USB-ID-based driver quirks), perhaps you could elaborate on it?
> >>
> >> We would need to (ab)use another open flag (e.g. O_DIRECT). I am not
> >> biased to either of solutions.
> >
> > Forgot to mention that using open-flags would prevent using standard
> > utilities like cat, echo and terminal programs. So for that reason a
> > termios and/or sysfs interface is also preferred.
>
> Nope, I meant it differently. You set it up once using the special open
> flag. Like with setserial, one sets I/O port, irqs etc. and then uses
> standard tools as the port is already set up (marked as NORDY in this
> case).
Ok, but leaving the open flag abuse aside, that would still require a
custom tool to do the setup.
There are also no other examples of such an interface with a "sticky"
open flag affecting later opens. But you probably meant that the open
flag only affects the current open, and then the termios flag is used
to make the setting stick.
Note that having a udev rule handle this at boot using a sysfs interface
does not require any custom tools at all.
And in theory nothing prevents extending/abusing POSIX with such an open
behaviour later.
Johan