All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: Stephen Boyd <sboyd@kernel.org>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Peter De Schrijver <pdeschrijver@nvidia.com>,
	Prashant Gaikwad <pgaikwad@nvidia.com>,
	linux-clk@vger.kernel.org, linux-tegra@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] clk: tegra: divider: Check UART's divider enable-bit state on rate's recalculation
Date: Thu, 14 Nov 2019 12:56:56 +0100	[thread overview]
Message-ID: <20191114115656.GC5690@aiwendil> (raw)
In-Reply-To: <02df00b3-5e23-441f-b2d5-b84fdb411e98@gmail.com>

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

On Thu, Nov 14, 2019 at 02:29:51PM +0300, Dmitry Osipenko wrote:
> 14.11.2019 02:03, Stephen Boyd пишет:
> > Quoting Dmitry Osipenko (2019-10-29 17:48:13)
> >> UART clock is divided using divisor values from DLM/DLL registers when
> >> enable-bit is unset in clk register and clk's divider configuration isn't
> >> taken onto account in this case. This doesn't cause any problems, but
> >> let's add a check for the divider's enable-bit state, for consistency.
> >>
> >> Acked-by: Peter De Schrijver <pdeschrijver@nvidia.com>
> >> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
> >> ---
> > 
> > Is this going to be picked up or should I just apply atop the tegra PR?
> 
> Looks like this patch missed the Tegra's PR by accident.
> 
> Stephen, I assume it will be easier if you could apply this patch atop.
> The patch doesn't have any dependencies on any other patches, so it's
> fine to apply it separately. Thanks in advance!
> 
> Thierry, please let us know if you have any objections.

It's not so much that I missed to pick this up. It's just that it didn't
make it in time. This was posted just a couple of days before v5.4-rc6
and I had already finalized the branches at that point. Given that this
doesn't fix any actual issues it didn't seem worth to force it in at
that point.

That said, I don't have any objections if Stephen wants to pick this up
on top of the pull requests.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2019-11-14 11:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-30  0:48 [PATCH v2] clk: tegra: divider: Check UART's divider enable-bit state on rate's recalculation Dmitry Osipenko
2019-11-13 23:03 ` Stephen Boyd
2019-11-14 11:29   ` Dmitry Osipenko
2019-11-14 11:56     ` Thierry Reding [this message]
2019-11-14 12:10       ` Dmitry Osipenko
2019-11-15 21:36         ` Stephen Boyd
2019-11-14 11:54 ` Thierry Reding

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=20191114115656.GC5690@aiwendil \
    --to=thierry.reding@gmail.com \
    --cc=digetx@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=pdeschrijver@nvidia.com \
    --cc=pgaikwad@nvidia.com \
    --cc=sboyd@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 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.