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
| ||
|
Date: Mon, 14 Feb 2022 06:41:13 +0100 From: Jiri Slaby <jirislaby@...nel.org> To: Lino Sanfilippo <LinoSanfilippo@....de>, gregkh@...uxfoundation.org Cc: linux@...linux.org.uk, richard.genoud@...il.com, nicolas.ferre@...rochip.com, alexandre.belloni@...tlin.com, ludovic.desroches@...rochip.com, shawnguo@...nel.org, s.hauer@...gutronix.de, kernel@...gutronix.de, festevam@...il.com, linux-imx@....com, mcoquelin.stm32@...il.com, alexandre.torgue@...s.st.com, linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, linux-stm32@...md-mailman.stormreply.com, lukas@...ner.de Subject: Re: [PATCH 1/9] serial: core: move RS485 configuration tasks from drivers into core On 13. 02. 22, 23:27, Lino Sanfilippo wrote: > Several drivers that support setting the RS485 configuration via userspace > implement on or more of the following tasks: > > - in case of an invalid RTS configuration (both RTS after send and RTS on > send set or both unset) fall back to enable RTS on send and disable RTS > after send > > - nullify the padding field of the returned serial_rs485 struct > > - copy the configuration into the uart port struct > > - limit RTS delays to 100 ms > > Move these tasks into the serial core to make them generic and to provide > a consistent beheviour among all drivers. > > Signed-off-by: Lino Sanfilippo <LinoSanfilippo@....de> > --- > drivers/tty/serial/serial_core.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c > index 846192a7b4bf..3fab4070359c 100644 > --- a/drivers/tty/serial/serial_core.c > +++ b/drivers/tty/serial/serial_core.c > @@ -1282,8 +1282,21 @@ static int uart_set_rs485_config(struct uart_port *port, > if (copy_from_user(&rs485, rs485_user, sizeof(*rs485_user))) > return -EFAULT; > > + /* pick sane settings if the user hasn't */ > + if (!(rs485.flags & SER_RS485_RTS_ON_SEND) == > + !(rs485.flags & SER_RS485_RTS_AFTER_SEND)) { > + rs485.flags |= SER_RS485_RTS_ON_SEND; > + rs485.flags &= ~SER_RS485_RTS_AFTER_SEND; > + } > + /* clamp the delays to [0, 100ms] */ > + rs485.delay_rts_before_send = min(rs485.delay_rts_before_send, 100U); > + rs485.delay_rts_after_send = min(rs485.delay_rts_after_send, 100U); Why is this magic 100? Can we have that number somehow documented? You should define a macro for that anyway. > + memset(rs485.padding, 0, sizeof(rs485.padding)); What is this memset good for? > spin_lock_irqsave(&port->lock, flags); > ret = port->rs485_config(port, &rs485); > + if (!ret) > + port->rs485 = rs485; > spin_unlock_irqrestore(&port->lock, flags); > if (ret) > return ret; thanks, -- js suse labs
Powered by blists - more mailing lists