Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
Message-ID: <trinity-24577b7c-5c5c-4fc6-a651-76ff5306989f-1645784200761@3c-app-gmx-bs22>
From:   Lino Sanfilippo <LinoSanfilippo@gmx.de>
To:     Jiri Slaby <jirislaby@kernel.org>
Cc:     gregkh@linuxfoundation.org, u.kleine-koenig@pengutronix.de,
        linux@armlinux.org.uk, richard.genoud@gmail.com,
        nicolas.ferre@microchip.com, alexandre.belloni@bootlin.com,
        ludovic.desroches@microchip.com, shawnguo@kernel.org,
        s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
        linux-imx@nxp.com, mcoquelin.stm32@gmail.com,
        alexandre.torgue@foss.st.com, linux-serial@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-stm32@st-md-mailman.stormreply.com, lukas@wunner.de,
        p.rosenberger@kunbus.com
Subject: Aw: Re: [PATCH v3 1/9] serial: core: move RS485 configuration tasks
 from drivers into core
Content-Type: text/plain; charset=UTF-8
Date:   Fri, 25 Feb 2022 11:16:40 +0100
Importance: normal
Sensitivity: Normal
In-Reply-To: <8c65bc42-438e-bf3e-fb76-2a4cbc7296c0@kernel.org>
References: <20220222011433.8761-1-LinoSanfilippo@gmx.de>
 <20220222011433.8761-2-LinoSanfilippo@gmx.de>
 <e883ccb5-68ea-f802-e4fd-864672d8ad7b@kernel.org>
 <8c65bc42-438e-bf3e-fb76-2a4cbc7296c0@kernel.org>
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi,


> On 22=2E 02=2E 22, 7:51, Jiri Slaby wrote:
> > On 22=2E 02=2E 22, 2:14, Lino Sanfilippo wrote:
> >> Several drivers that support setting the RS485 configuration via=20
> >> userspace
> >> implement one or more of the following tasks:
> >>
> >> - in case of an invalid RTS configuration (both RTS after send and RT=
S on
> >> =C2=A0=C2=A0 send set or both unset) fall back to enable RTS on send =
and disable=20
> >> RTS
> >> =C2=A0=C2=A0 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 pro=
vide
> >> a consistent behaviour among all drivers=2E
> >>
> >> Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx=2Ede>
> >> ---
> >> =C2=A0 drivers/tty/serial/serial_core=2Ec | 29 ++++++++++++++++++++++=
+++++++
> >> =C2=A0 1 file changed, 29 insertions(+)
> >>
> >> diff --git a/drivers/tty/serial/serial_core=2Ec=20
> >> b/drivers/tty/serial/serial_core=2Ec
> >> index 846192a7b4bf=2E=2E2b3afe038c1c 100644
> >> --- a/drivers/tty/serial/serial_core=2Ec
> >> +++ b/drivers/tty/serial/serial_core=2Ec
> >> @@ -42,6 +42,11 @@ static struct lock_class_key port_lock_key;
> >> =C2=A0 #define HIGH_BITS_OFFSET=C2=A0=C2=A0=C2=A0 ((sizeof(long)-size=
of(int))*8)
> >> +/*
> >> + * Max time with active RTS before/after data is sent=2E
> >> + */
> >> +#define RS485_MAX_RTS_DELAY=C2=A0=C2=A0=C2=A0 100 /* msecs */
> >> +
> >> =C2=A0 static void uart_change_speed(struct tty_struct *tty, struct=
=20
> >> uart_state *state,
> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct ktermios *=
old_termios);
> >> =C2=A0 static void uart_wait_until_sent(struct tty_struct *tty, int t=
imeout);
> >> @@ -1282,8 +1287,32 @@ static int uart_set_rs485_config(struct=20
> >> uart_port *port,
> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (copy_from_user(&rs485, rs485_user,=
 sizeof(*rs485_user)))
> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return -EFAULT=
;
> >> +=C2=A0=C2=A0=C2=A0 /* pick sane settings if the user hasn't */
> >> +=C2=A0=C2=A0=C2=A0 if (!(rs485=2Eflags & SER_RS485_RTS_ON_SEND) =3D=
=3D
> >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 !(rs485=2Eflags & SER_RS4=
85_RTS_AFTER_SEND)) {
> >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pr_warn("invalid RTS sett=
ing, using RTS_ON_SEND instead\n");
> >=20
> > Can't we have a device prefix here, so that everyone knows what device=
=20
> > is affected? Without that, it's not that useful=2E At least port->name=
 &=20
> > port->line could be printed=2E The uart core uses dev_* prints, but pr=
ints=20
> > also line as uport->dev can be NULL sometimes=2E
>=20
> And this comes from userspace, so should be ratelimited=2E
>=20

Right, ratelimiting makes sense here=2E I will change it as suggested in t=
he next patch version=2E
Thanks a lot for the review=2E

Regards,
Lino