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
>
>
prev parent 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).