From: Sergey Semin <Sergey.Semin@baikalelectronics.ru>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
Kefeng Wang <wangkefeng.wang@huawei.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Heiko Stuebner <heiko@sntech.de>,
Catalin Marinas <catalin.marinas@arm.com>,
Michael Turquette <mturquette@baylibre.com>,
Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>,
Will Deacon <will@kernel.org>,
linux-clk@vger.kernel.org,
Florian Fainelli <f.fainelli@gmail.com>,
Maxim Kaurkin <Maxim.Kaurkin@baikalelectronics.ru>,
Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>,
Gregory Clement <gregory.clement@bootlin.com>,
Russell King <linux@armlinux.org.uk>,
Wei Xu <xuwei5@hisilicon.com>, Chen-Yu Tsai <wens@csie.org>,
Ekaterina Skachko <Ekaterina.Skachko@baikalelectronics.ru>,
Jiri Slaby <jslaby@suse.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
Jason Cooper <jason@lakedaemon.net>, Ray Jui <rjui@broadcom.com>,
Maxime Ripard <mripard@kernel.org>,
Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>,
linux-serial@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Vadim Vlasov <V.Vlasov@baikalelectronics.ru>,
Paul Burton <paulburton@kernel.org>,
Scott Branden <sbranden@broadcom.com>,
Stephen Boyd <sboyd@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>,
Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Subject: Re: [PATCH v2] serial: 8250_dw: Fix common clocks usage race condition
Date: Mon, 23 Mar 2020 20:07:09 +0300 [thread overview]
Message-ID: <20200323170709.izdecff3hfctzumv@ubsrv2.baikal.int> (raw)
In-Reply-To: <20200323115225.GJ1922688@smile.fi.intel.com>
On Mon, Mar 23, 2020 at 01:52:25PM +0200, Andy Shevchenko wrote:
> On Mon, Mar 23, 2020 at 02:11:49PM +0300, Sergey Semin wrote:
> > On Mon, Mar 23, 2020 at 11:20:51AM +0200, Andy Shevchenko wrote:
> > > On Mon, Mar 23, 2020 at 05:46:09AM +0300, Sergey.Semin@baikalelectronics.ru wrote:
> > > > From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > >
> > > The question to CLK framework maintainers, is it correct approach in general
> > > for this case?
> >
> > You should have been more specific then, if you wanted to see someone
> > special.
>
> I didn't get your comment here. Since you put the question under a pile of
> words in the commit message, and actually in the changelog, not even in the
> message, I repeated it clearly that clock maintainers can see it.
>
> > > On Wed, Mar 18, 2020 at 05:19:53PM +0200, Andy Shevchenko wrote:
> > >> Also it would be nice to see come clock framework guys' opinions...
> >
> > Who can give a better comments regarding the clk API if not the
> > subsystem maintainers?
>
> You already got one from Maxime.
>
> ...
>
> > > > + /*
> > > > + * 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 nothing will change the rate behind our back and second
> > > > + * the tty/serial subsystem knows the actual reference clock rate of
> > > > + * the port.
> > > > + */
> > >
> > > > + if (clk_rate_exclusive_get(d->clk)) {
> > > > + dev_warn(p->dev, "Couldn't lock the clock rate\n");
> > >
> > > So, if this fails, in ->shutdown you will disbalance reference count, or did I
> > > miss something?
> > >
> >
> > Hm, you are right. I didn't fully thought this through. The thing is
> > that according to the clk_rate_exclusive_get() function code currently
> > it never fails. Though this isn't excuse for introducing a prone to future
> > bugs code.
> >
> > Anyway if according to design a function may return an error we must take
> > into account in the code using it. Due to this obligation and seeing we can't
> > easily detect whether clk_rate_exclusive_get() has been failed while the
> > driver is being executed in the shutdown method, the best approach would be
> > to just return an error in startup method in case of the clock rate exclusivity
> > acquisition failure. If you are ok with this, I'll have it fixed in v3
> > patchset.
>
> It needs to be carefully tested on other platforms than yours.
>
Alas I don't have one. But it can be done by other kernel users at rc-s stage
of the next kernel release.
> > > > + } else if (d->clk) {
> > >
> > > > + p->uartclk = clk_get_rate(d->clk);
> > > > + if (!p->uartclk) {
> > > > + clk_rate_exclusive_put(d->clk);
> > > > + dev_err(p->dev, "Clock rate not defined\n");
> > > > + return -EINVAL;
> > > > + }
> > >
> > > This operations I didn't get. If we have d->clk and suddenly get 0 as a rate
> > > (and note, that we still update uartclk member!), we try to put (why?) the
> > > exclusiveness of rate.
> > >
> >
> > Here is what I had in my mind while implementing this code. If d->clk
> > isn't NULL, then there is a "baudclk" clock handler and we can use it to
> > alter/retrieve the baud clock rate. But the same clock could be used by
> > some other driver and that driver could have changed the rate while we
> > didn't have this tty port started up (opened). In this case that driver
> > could also have the clock exclusively acquired. So instead of trying to
> > set the current p->uartclk rate to the clock, check the return value,
> > if it's an error, try to get the current clock rate, check the return
> > value, and so on, I just get the current baud clock rate and make sure
> > the value is not zero
>
> > (clk_get_rate() returns a zero rate in case of
> > internal errors).
>
> Have you considered !CLK case?
>
Yes. It's a case of optional clock. Have a look at how the clock API
works. You are already using it here in this driver when calling
clk_prepare_enable()/clk_disable_unprepare().
> > At the same time dw8250_set_termios() will try to update
> > the baud clock rate anyway (also by the serial core at the point of the port
> > startup), so we don't need such complication in the DW 8250 port startup
> > code.
> >
> > > (and note, that we still update uartclk member!),
> >
> > Yes, if we can't determine the current baud clock rate, then the there is
> > a problem with the clock device, so we don't know at what rate it's
> > currently working. Zero is the most appropriate value to be set in this case.
> >
> > > we try to put (why?) the > exclusiveness of rate.
> >
> > Yes, we put the exclusivity and return an error, because this if-branch has
> > been taken only if the exclusivity has been successfully acquired.
>
> So, this means that above code requires elaboration in the comments to explain
> how it supposed to work.
>
That's what I did by the comment: "... second the tty/serial subsystem knows
the actual reference clock rate of the port." If you think, that checking a
return value and undoing things in case of an error need elaboration in a
comment I'll do it in v3.
-Regards,
Sergey
> --
> With Best Regards,
> Andy Shevchenko
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-03-23 17:07 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200306130231.05BBC8030795@mail.baikalelectronics.ru>
2020-03-23 2:46 ` [PATCH v2] serial: 8250_dw: Fix common clocks usage race condition Sergey.Semin
2020-03-23 9:20 ` Andy Shevchenko
2020-03-23 11:11 ` Sergey Semin
2020-03-23 11:52 ` Andy Shevchenko
2020-03-23 17:07 ` Sergey Semin [this message]
2020-03-23 10:01 ` Maxime Ripard
2020-03-23 13:50 ` Sergey Semin
2020-03-24 9:41 ` Maxime Ripard
2020-03-24 10:12 ` Andy Shevchenko
2020-03-25 17:11 ` Sergey Semin
2020-03-26 1:44 ` Stephen Boyd
2020-03-27 9:12 ` Sergey Semin
2020-05-06 23:31 ` [PATCH v3 0/4] serial: 8250_dw: Fix ref clock usage Serge Semin
2020-05-06 23:31 ` [PATCH v3 1/4] serial: 8250: Fix max baud limit in generic 8250 port Serge Semin
2020-05-15 13:48 ` Andy Shevchenko
2020-05-06 23:31 ` [PATCH v3 2/4] serial: 8250: Add 8250 port clock update method Serge Semin
2020-05-15 12:45 ` Greg Kroah-Hartman
2020-05-15 14:32 ` Serge Semin
2020-05-06 23:31 ` [PATCH v3 3/4] serial: 8250_dw: Simplify the ref clock rate setting procedure Serge Semin
2020-05-15 14:05 ` Andy Shevchenko
2020-05-15 14:50 ` Serge Semin
2020-05-15 15:05 ` Andy Shevchenko
2020-05-06 23:31 ` [PATCH v3 4/4] serial: 8250_dw: Fix common clocks usage race condition Serge Semin
2020-05-15 14:10 ` Andy Shevchenko
2020-05-15 15:19 ` Serge Semin
2020-05-07 18:29 ` [PATCH v3 0/4] serial: 8250_dw: Fix ref clock usage Andy Shevchenko
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=20200323170709.izdecff3hfctzumv@ubsrv2.baikal.int \
--to=sergey.semin@baikalelectronics.ru \
--cc=Alexey.Malahov@baikalelectronics.ru \
--cc=Ekaterina.Skachko@baikalelectronics.ru \
--cc=Jisheng.Zhang@synaptics.com \
--cc=Maxim.Kaurkin@baikalelectronics.ru \
--cc=Pavel.Parkhomenko@baikalelectronics.ru \
--cc=Ramil.Zaripov@baikalelectronics.ru \
--cc=V.Vlasov@baikalelectronics.ru \
--cc=andrew@lunn.ch \
--cc=andriy.shevchenko@linux.intel.com \
--cc=catalin.marinas@arm.com \
--cc=f.fainelli@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=gregory.clement@bootlin.com \
--cc=heikki.krogerus@linux.intel.com \
--cc=heiko@sntech.de \
--cc=jason@lakedaemon.net \
--cc=jslaby@suse.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mripard@kernel.org \
--cc=mturquette@baylibre.com \
--cc=paulburton@kernel.org \
--cc=ralf@linux-mips.org \
--cc=rjui@broadcom.com \
--cc=sboyd@kernel.org \
--cc=sbranden@broadcom.com \
--cc=sebastian.hesselbarth@gmail.com \
--cc=tsbogend@alpha.franken.de \
--cc=wangkefeng.wang@huawei.com \
--cc=wens@csie.org \
--cc=will@kernel.org \
--cc=xuwei5@hisilicon.com \
/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).