[GIT PULL] TTY/Serial driver fixes for 5.5-rc3

[GIT PULL] TTY/Serial driver fixes for 5.5-rc3

[Greg KH]

The following changes since commit e42617b825f8073569da76dc4510bfa019b1c35a:

  Linux 5.5-rc1 (2019-12-08 14:57:55 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-5.5-rc3

for you to fetch changes up to cb47b9f8630ae3fa3f5fbd0c7003faba7abdf711:

  tty/serial: atmel: fix out of range clock divider handling (2019-12-17 14:17:32 +0100)

----------------------------------------------------------------
TTY/Serial fixes for 5.5-rc3

Here are some small tty and serial driver fixes for 5.5-rc3.

Only 4 small patches here:
  - atmel serial driver fix
  - msm_serial driver fix
  - sprd serial driver fix
  - tty core port fix

The last tty core fix should resolve a long-standing bug with a race
at port creation time that some people would see, and Sudip finally
tracked down.

All of these have been in linux-next with no reported issues.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

----------------------------------------------------------------
David Engraf (1):
      tty/serial: atmel: fix out of range clock divider handling

Leo Yan (1):
      tty: serial: msm_serial: Fix lockup for sysrq and oops

Sudip Mukherjee (1):
      tty: link tty and port before configuring it as console

Yonghan Ye (1):
      serial: sprd: Add clearing break interrupt operation

 drivers/tty/serial/atmel_serial.c | 43 ++++++++++++++++++++-------------------
 drivers/tty/serial/msm_serial.c   | 13 ++++++++++--
 drivers/tty/serial/serial_core.c  |  1 +
 drivers/tty/serial/sprd_serial.c  |  3 +++
 drivers/tty/tty_port.c            |  3 ++-
 5 files changed, 39 insertions(+), 24 deletions(-)

Re: [GIT PULL] TTY/Serial driver fixes for 5.5-rc3

[Linus Torvalds]

On Thu, Dec 19, 2019 at 11:07 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> The last tty core fix should resolve a long-standing bug with a race
> at port creation time that some people would see, and Sudip finally
> tracked down.

Hmm, looks good. But it makes me wonder if we should now try to remove
the second call to tty_port_link_device()?

Now we have a number of helpers that do that tty_port_link_device()
call for the driver (eg tty_port_register_device_attr_serdev(),
tty_port_register_device_attr(), and the just added
uart_add_one_port()).

But we also have drivers doing it by hand, and presumably we now have
drivers that do it through multiple paths? I guess it's harmless, but
it feels a bit odd. No?

            Linus

Re: [GIT PULL] TTY/Serial driver fixes for 5.5-rc3

[Greg KH]

On Fri, Dec 20, 2019 at 10:08:03AM -0800, Linus Torvalds wrote:
> On Thu, Dec 19, 2019 at 11:07 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > The last tty core fix should resolve a long-standing bug with a race
> > at port creation time that some people would see, and Sudip finally
> > tracked down.
> 
> Hmm, looks good. But it makes me wonder if we should now try to remove
> the second call to tty_port_link_device()?
> 
> Now we have a number of helpers that do that tty_port_link_device()
> call for the driver (eg tty_port_register_device_attr_serdev(),
> tty_port_register_device_attr(), and the just added
> uart_add_one_port()).
> 
> But we also have drivers doing it by hand, and presumably we now have
> drivers that do it through multiple paths? I guess it's harmless, but
> it feels a bit odd. No?

It does.  I'll try to look at this after the holidays unless Sudip beats
me to it.

thanks,

greg k-h

Re: [GIT PULL] TTY/Serial driver fixes for 5.5-rc3

[Sudip Mukherjee]

On Mon, Dec 23, 2019 at 12:06 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Fri, Dec 20, 2019 at 10:08:03AM -0800, Linus Torvalds wrote:
> > On Thu, Dec 19, 2019 at 11:07 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > The last tty core fix should resolve a long-standing bug with a race
> > > at port creation time that some people would see, and Sudip finally
> > > tracked down.
> >
> > Hmm, looks good. But it makes me wonder if we should now try to remove
> > the second call to tty_port_link_device()?
> >
> > Now we have a number of helpers that do that tty_port_link_device()
> > call for the driver (eg tty_port_register_device_attr_serdev(),
> > tty_port_register_device_attr(), and the just added
> > uart_add_one_port()).
> >
> > But we also have drivers doing it by hand, and presumably we now have
> > drivers that do it through multiple paths? I guess it's harmless, but
> > it feels a bit odd. No?
>
> It does.  I'll try to look at this after the holidays unless Sudip beats
> me to it.

A regression reported by Kenny for this change. I have sent him a patch to test.
I think that has to go in rc4. Will remove the second call after he has tested.


--
Regards
Sudip

Re: [GIT PULL] TTY/Serial driver fixes for 5.5-rc3

[Sudip Mukherjee]

[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]

On Mon, Dec 23, 2019 at 07:06:51AM -0500, Greg KH wrote:
> On Fri, Dec 20, 2019 at 10:08:03AM -0800, Linus Torvalds wrote:
> > On Thu, Dec 19, 2019 at 11:07 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > The last tty core fix should resolve a long-standing bug with a race
> > > at port creation time that some people would see, and Sudip finally
> > > tracked down.
> > 
> > Hmm, looks good. But it makes me wonder if we should now try to remove
> > the second call to tty_port_link_device()?
> > 
> > Now we have a number of helpers that do that tty_port_link_device()
> > call for the driver (eg tty_port_register_device_attr_serdev(),
> > tty_port_register_device_attr(), and the just added
> > uart_add_one_port()).
> > 
> > But we also have drivers doing it by hand, and presumably we now have
> > drivers that do it through multiple paths? I guess it's harmless, but
> > it feels a bit odd. No?
> 
> It does.  I'll try to look at this after the holidays unless Sudip beats
> me to it.

The second call to tty_port_link_device() is in
tty_port_register_device_attr_serdev() and tty_port_register_device_attr()
is being called from many other places apart from uart_add_one_port().
The attached patch should be safe. I will test and send it properly unless
someone objects to it.

--
Regards
Sudip

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 2336 bytes --]

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 7c2782785736..09df885442ae 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -2858,7 +2858,8 @@ int uart_add_one_port(struct uart_driver *drv, struct uart_port *uport)
 	 * setserial to be used to alter this port's parameters.
 	 */
 	tty_dev = tty_port_register_device_attr_serdev(port, drv->tty_driver,
-			uport->line, uport->dev, port, uport->tty_groups);
+			uport->line, uport->dev, port, uport->tty_groups,
+			false);
 	if (!IS_ERR(tty_dev)) {
 		device_set_wakeup_capable(tty_dev, 1);
 	} else {
diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index 5023c85ebc6e..dc66543fa2c3 100644
--- a/drivers/tty/tty_port.c
+++ b/drivers/tty/tty_port.c
@@ -152,11 +152,12 @@ EXPORT_SYMBOL_GPL(tty_port_register_device_attr);
 struct device *tty_port_register_device_attr_serdev(struct tty_port *port,
 		struct tty_driver *driver, unsigned index,
 		struct device *device, void *drvdata,
-		const struct attribute_group **attr_grp)
+		const struct attribute_group **attr_grp, bool link)
 {
 	struct device *dev;
 
-	tty_port_link_device(port, driver, index);
+	if (link)
+		tty_port_link_device(port, driver, index);
 
 	dev = serdev_tty_port_register(port, device, driver, index);
 	if (PTR_ERR(dev) != -ENODEV) {
@@ -184,7 +185,7 @@ struct device *tty_port_register_device_serdev(struct tty_port *port,
 		struct device *device)
 {
 	return tty_port_register_device_attr_serdev(port, driver, index,
-			device, NULL, NULL);
+			device, NULL, NULL, true);
 }
 EXPORT_SYMBOL_GPL(tty_port_register_device_serdev);
 
diff --git a/include/linux/tty.h b/include/linux/tty.h
index bfa4e2ee94a9..7f2ad47ecf88 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -587,7 +587,7 @@ extern struct device *tty_port_register_device_serdev(struct tty_port *port,
 extern struct device *tty_port_register_device_attr_serdev(struct tty_port *port,
 		struct tty_driver *driver, unsigned index,
 		struct device *device, void *drvdata,
-		const struct attribute_group **attr_grp);
+		const struct attribute_group **attr_grp, bool link);
 extern void tty_port_unregister_device(struct tty_port *port,
 		struct tty_driver *driver, unsigned index);
 extern int tty_port_alloc_xmit_buf(struct tty_port *port);

Re: [GIT PULL] TTY/Serial driver fixes for 5.5-rc3

[Johan Hovold]

On Fri, Dec 27, 2019 at 06:30:11PM +0000, Sudip Mukherjee wrote:
> On Mon, Dec 23, 2019 at 07:06:51AM -0500, Greg KH wrote:
> > On Fri, Dec 20, 2019 at 10:08:03AM -0800, Linus Torvalds wrote:
> > > On Thu, Dec 19, 2019 at 11:07 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > The last tty core fix should resolve a long-standing bug with a race
> > > > at port creation time that some people would see, and Sudip finally
> > > > tracked down.
> > > 
> > > Hmm, looks good. But it makes me wonder if we should now try to remove
> > > the second call to tty_port_link_device()?
> > > 
> > > Now we have a number of helpers that do that tty_port_link_device()
> > > call for the driver (eg tty_port_register_device_attr_serdev(),
> > > tty_port_register_device_attr(), and the just added
> > > uart_add_one_port()).
> > > 
> > > But we also have drivers doing it by hand, and presumably we now have
> > > drivers that do it through multiple paths? I guess it's harmless, but
> > > it feels a bit odd. No?
> > 
> > It does.  I'll try to look at this after the holidays unless Sudip beats
> > me to it.
> 
> The second call to tty_port_link_device() is in
> tty_port_register_device_attr_serdev() and tty_port_register_device_attr()
> is being called from many other places apart from uart_add_one_port().
> The attached patch should be safe. I will test and send it properly unless
> someone objects to it.

No, this is horrid. There's certainly room for some clean up here but we
shouldn't make things worse. ;)

Why not look into registering the console only after the port has been
set up and registered and revert fb2b90014d78 ("tty: link tty and port
before configuring it as console") completely instead?

Johan

Re: [GIT PULL] TTY/Serial driver fixes for 5.5-rc3

[pr-tracker-bot]

The pull request you sent on Fri, 20 Dec 2019 08:07:47 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-5.5-rc3

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1a4ee8673a775faf4164e66e03b2bcb0cc915d5d

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker