linux-mips.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Serge Semin <fancer.lancer@gmail.com>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.com>,
	Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>,
	Arnd Bergmann <arnd@arndb.de>, Maxime Ripard <mripard@kernel.org>,
	Will Deacon <will@kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	<linux-mips@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-serial@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 3/3] serial: 8250_dw: Fix common clocks usage race condition
Date: Tue, 26 May 2020 20:41:49 +0300	[thread overview]
Message-ID: <20200526174149.wpmto6vx775idbaj@mobilestation> (raw)
In-Reply-To: <20200526165701.GX1634618@smile.fi.intel.com>

On Tue, May 26, 2020 at 07:57:01PM +0300, Andy Shevchenko wrote:
> On Tue, May 26, 2020 at 07:03:16PM +0300, Serge Semin wrote:
> > The race condition may happen if the UART reference clock is shared with
> > some other device (on Baikal-T1 SoC it's another DW UART port). In this
> > case if that device changes the clock rate while serial console is using
> > it the DW 8250 UART port might not only end up with an invalid uartclk
> > value saved, but may also experience a distorted output data since
> > baud-clock could have been changed. In order to fix this lets at least
> > try to adjust the 8250 port setting like UART clock rate in case if the
> > reference clock rate change is discovered. The driver will call the new
> > method to update 8250 UART port clock rate settings. It's done by means of
> > the clock event notifier registered at the port startup and unregistered
> > in the shutdown callback method.
> > 
> > Note 1. In order to avoid deadlocks we had to execute the UART port update
> > method in a dedicated deferred work. This is due to (in my opinion
> > redundant) the clock update implemented in the dw8250_set_termios()
> > method.
> > Note 2. Before the ref clock is manually changed by the custom
> > set_termios() function we swap the port uartclk value with new rate
> > adjusted to be suitable for the requested baud. It is necessary in
> > order to effectively disable a functionality of the ref clock events
> > handler for the current UART port, since uartclk update will be done
> > a bit further in the generic serial8250_do_set_termios() function.
> 
> ...
> 
> > +static void dw8250_clk_work_cb(struct work_struct *work)
> > +{
> > +	struct dw8250_data *d = work_to_dw8250_data(work);
> > +	struct uart_8250_port *up;
> > +	unsigned long rate;
> > +
> > +	rate = clk_get_rate(d->clk);
> 

> > +	if (rate) {
> 
> 	if (rate <= 0)
> 		return;
> 
> ?

Ok. Though there isn't point in a function consisting of a few lines. 

> 
> > +		up = serial8250_get_port(d->data.line);
> > +
> > +		serial8250_update_uartclk(&up->port, rate);
> > +	}
> > +}
> 
> ...
> 
> > +static int dw8250_startup(struct uart_port *p)
> > +{
> > +	struct dw8250_data *d = to_dw8250_data(p->private_data);
> > +	int ret;
> > +
> > +	/*
> > +	 * Some platforms may provide a reference clock shared between several
> > +	 * devices. In this case before using the serial port first we have to
> > +	 * make sure that any clock state change is known to the UART port at
> > +	 * least post factum.
> > +	 */
> 

> > +	if (d->clk) {
> 
> Do you need this?

Yes, I do. The same way as clk_get_rate() needs this.

> 
> > +		ret = clk_notifier_register(d->clk, &d->clk_notifier);
> 
> Okay, seems clk_notifier_register() and its counterpart should be fixed for
> optional clocks.

In order to use the clk_get_rate() function we need to make sure the clk isn't
optional otherwise -EINVAL will be returned, which is indistinguishable from
any another error. The same situation is for the clk_notifier_register() and
clk_notifier_unregister() counterpart.

> 
> > +		if (ret)
> > +			dev_warn(p->dev, "Failed to set the clock notifier\n");
> 
> So, what does this warning mean on the platforms which does not need notifier
> at all

It means "The clk-notifier subsystem is broken. Though if reference clock rate
doesn't change, it won't a problem." Due to the last statement we print a
warning, but not an error message.

> (i.o.w. all but baikal)?

No. As we discussed earlier in the previous pacthset versions there are another
platforms with shared reference clocks behind the DW APB UART, like: Allwinner SoCs,
RPi 3/4, etc.

> 
> > +		/*
> > +		 * Get current reference clock rate to make sure the UART port
> > +		 * is equipped with an up-to-date value before it's started up.
> > +		 */
> 
> Why? We call ->set_termios() for it, no?

This makes sense. Thanks. I'll remove this part.

-Sergey

> 
> > +		p->uartclk = clk_get_rate(d->clk);
> > +		if (!p->uartclk) {
> > +			dev_err(p->dev, "Clock rate not defined\n");
> > +			return -EINVAL;
> > +		}
> > +	}
> > +
> > +	return serial8250_do_startup(p);
> > +}
> > +
> > +static void dw8250_shutdown(struct uart_port *p)
> > +{
> > +	struct dw8250_data *d = to_dw8250_data(p->private_data);
> > +
> > +	serial8250_do_shutdown(p);
> > +
> 
> > +	if (d->clk) {
> 
> Ditto.
> 
> > +		clk_notifier_unregister(d->clk, &d->clk_notifier);
> > +
> > +		flush_work(&d->clk_work);
> > +	}
> > +}
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 

      reply	other threads:[~2020-05-26 17:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-26 16:03 [PATCH v4 0/3] serial: 8250_dw: Fix ref clock usage Serge Semin
2020-05-26 16:03 ` [PATCH v4 1/3] serial: 8250: Add 8250 port clock update method Serge Semin
2020-05-26 16:03 ` [PATCH v4 2/3] serial: 8250_dw: Simplify the ref clock rate setting procedure Serge Semin
2020-05-26 16:03 ` [PATCH v4 3/3] serial: 8250_dw: Fix common clocks usage race condition Serge Semin
2020-05-26 16:57   ` Andy Shevchenko
2020-05-26 17:41     ` Serge Semin [this message]

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=20200526174149.wpmto6vx775idbaj@mobilestation \
    --to=sergey.semin@baikalelectronics.ru \
    --cc=Alexey.Malahov@baikalelectronics.ru \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=fancer.lancer@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mripard@kernel.org \
    --cc=tsbogend@alpha.franken.de \
    --cc=will@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).