From: Johan Hovold <johan@kernel.org>
To: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Jiri Slaby <jslaby@suse.cz>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-serial@vger.kernel.org
Subject: Re: [GIT PULL] TTY/Serial driver fixes for 5.5-rc3
Date: Fri, 10 Jan 2020 11:37:52 +0100 [thread overview]
Message-ID: <20200110103752.GB4273@localhost> (raw)
In-Reply-To: <20191227183011.ij5wcawu6kpf52fb@debian>
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
next prev parent reply other threads:[~2020-01-10 10:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-20 7:07 [GIT PULL] TTY/Serial driver fixes for 5.5-rc3 Greg KH
2019-12-20 18:08 ` Linus Torvalds
2019-12-23 12:06 ` Greg KH
2019-12-25 12:52 ` Sudip Mukherjee
2019-12-27 18:30 ` Sudip Mukherjee
2020-01-10 10:37 ` Johan Hovold [this message]
2019-12-20 18:15 ` pr-tracker-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200110103752.GB4273@localhost \
--to=johan@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
--cc=sudipm.mukherjee@gmail.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.