On Sun, Feb 13, 2022 at 11:27:29PM +0100, Lino Sanfilippo wrote:
> Several drivers that support setting the RS485 configuration via userspace
> implement on or more of the following tasks:
s/on/one/
>
> - 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.
s/beheviour/behaviour/
> Signed-off-by: Lino Sanfilippo <[email protected]>
> ---
> 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);
> + memset(rs485.padding, 0, sizeof(rs485.padding));
> +
> spin_lock_irqsave(&port->lock, flags);
> ret = port->rs485_config(port, &rs485);
> + if (!ret)
> + port->rs485 = rs485;
I was only Cc:d for the imx patch (patch #7) and tried to verify the
claim there that "the serial core already assigns the passed
configuration to the uart port". That failed when I looked at my kernel
tree.
So it would be great, if you sent dependencies (or at least a cover
letter) to all recipients of a given patch to ease review. Also I want
to suggest to mention uart_set_rs485_config() in the commit log of the
imx patch (and probably the others) to simplify verifying the claim
there.
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Hi,
On 14.02.22 at 08:06, Uwe Kleine-K?nig wrote:
> On Sun, Feb 13, 2022 at 11:27:29PM +0100, Lino Sanfilippo wrote:
>> Several drivers that support setting the RS485 configuration via userspace
>> implement on or more of the following tasks:
>
> s/on/one/
Ok
>
>>
>> - 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.
>
> s/beheviour/behaviour/
>
Ok
>> Signed-off-by: Lino Sanfilippo <[email protected]>
>> ---
>> 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);
>> + memset(rs485.padding, 0, sizeof(rs485.padding));
>> +
>> spin_lock_irqsave(&port->lock, flags);
>> ret = port->rs485_config(port, &rs485);
>> + if (!ret)
>> + port->rs485 = rs485;
>
> I was only Cc:d for the imx patch (patch #7) and tried to verify the
> claim there that "the serial core already assigns the passed
> configuration to the uart port". That failed when I looked at my kernel
> tree.
>
> So it would be great, if you sent dependencies (or at least a cover
> letter) to all recipients of a given patch to ease review. Also I want
> to suggest to mention uart_set_rs485_config() in the commit log of the
> imx patch (and probably the others) to simplify verifying the claim
> there.
>
Thanks for the review, I will correct the typos in the next version.
I will also cc you directly for the next version if you dont mind.
get_maintainers only spit out "Pengutronix Kernel Team" so I used that
address for the whole series (including the cover letter).
Regards,
Lino
Hello Lino,
On Mon, Feb 14, 2022 at 04:09:53PM +0100, Lino Sanfilippo wrote:
> On 14.02.22 at 08:06, Uwe Kleine-K?nig wrote:
> > I was only Cc:d for the imx patch (patch #7) and tried to verify the
> > claim there that "the serial core already assigns the passed
> > configuration to the uart port". That failed when I looked at my kernel
> > tree.
> >
> > So it would be great, if you sent dependencies (or at least a cover
> > letter) to all recipients of a given patch to ease review. Also I want
> > to suggest to mention uart_set_rs485_config() in the commit log of the
> > imx patch (and probably the others) to simplify verifying the claim
> > there.
>
> Thanks for the review, I will correct the typos in the next version.
> I will also cc you directly for the next version if you dont mind.
I don't mind. I get so many patches by mail, I'm good at ignoring them
;-)
> get_maintainers only spit out "Pengutronix Kernel Team" so I used that
> address for the whole series (including the cover letter).
That's why I eventually found the whole series and could reply to patch
#1.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |