lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 14 Nov 2023 20:50:42 -0600
From:   Brenda Streiff <brenda.streiff@...com>
To:     Crescent CY Hsieh <crescentcy.hsieh@...a.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>
Cc:     linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org
Subject: Re: [PATCH v4] tty: serial: Add RS422 flag to struct serial_rs485

Hi,

On 11/13/2023 3:41 AM, Crescent CY Hsieh wrote:
> Add "SER_RS485_MODE_RS422" flag to struct serial_rs485, so that serial
> port can switch interface into RS422 if supported by using ioctl command
> "TIOCSRS485".
> 
> By treating RS422 as a mode of RS485, which means while enabling RS422
> there are two flags need to be set (SER_RS485_ENABLED and
> SER_RS485_MODE_RS422), it would make things much easier. For example
> some places that checks for "SER_RS485_ENABLED" won't need to be rewritten.
> 
> There are only two things need to be noticed:
> 
> - While enabling RS422, other RS485 flags should not be set.
> - RS422 doesn't need to deal with termination, so while disabling RS485
>   or enabling RS422, uart_set_rs485_termination() shall return.
> 
> Signed-off-by: Crescent CY Hsieh <crescentcy.hsieh@...a.com>
> > [...]
> diff --git a/include/uapi/linux/serial.h b/include/uapi/linux/serial.h
> index 53bc1af67..9086367db 100644
> --- a/include/uapi/linux/serial.h
> +++ b/include/uapi/linux/serial.h
> @@ -11,6 +11,7 @@
>  #ifndef _UAPI_LINUX_SERIAL_H
>  #define _UAPI_LINUX_SERIAL_H
>  
> +#include <linux/const.h>
>  #include <linux/types.h>
>  
>  #include <linux/tty_flags.h>
> @@ -137,17 +138,19 @@ struct serial_icounter_struct {
>   * * %SER_RS485_ADDRB		- Enable RS485 addressing mode.
>   * * %SER_RS485_ADDR_RECV - Receive address filter (enables @addr_recv). Requires %SER_RS485_ADDRB.
>   * * %SER_RS485_ADDR_DEST - Destination address (enables @addr_dest). Requires %SER_RS485_ADDRB.
> + * * %SER_RS485_MODE_RS422	- Enable RS422. Requires %SER_RS485_ENABLED.
>   */

Documentation/driver-api/serial/serial-rs485.rst could also use an update,
since it doesn't mention your new flag at all.

The documentation as it is also doesn't give a very good idea of what flags
userspace might need to set for RS-232 vs RS-422 vs RS-485 (2- or 4-wire).

If I compare this to your original patch set [1] for your hardware, then
your proposed flag would be used in the following ways, correct?

RS-232:                       rs485->flags = 0
RS-422:                       rs485->flags = SER_RS485_ENABLED|SER_RS485_MODE_RS422
RS-485 (2-wire half-duplex):  rs485->flags = SER_RS485_ENABLED
RS-485 (4-wire full-duplex):  rs485->flags = SER_RS485_ENABLED|SER_RS485_RX_DURING_TX

In iot2040_rs485_config in 8250_exar.c [2] we already seem to have:
RS-232:                       rs485->flags = 0
RS-422:                       rs485->flags = SER_RS485_ENABLED|SER_RS485_RX_DURING_TX
RS-485 (2-wire half-duplex?): rs485->flags = SER_RS485_ENABLED

This would seem to create an inconsistency in this API.

I've also been trying to get a driver for NI's serial hardware upstream [3]; we
have "RS-485" products that can do both RS-422/RS-485, and also have use of
functionality to toggle between the two modes, so-- whichever way this flag
goes-- I'd like to be consistent with how other drivers do it.

[1] https://lore.kernel.org/linux-serial/20231018091739.10125-7-crescentcy.hsieh@moxa.com/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/serial/8250/8250_exar.c?h=v6.6#n459
[3] https://lore.kernel.org/linux-serial/20231023210458.447779-3-brenda.streiff@ni.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ