stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Norris <briannorris@chromium.org>
To: gregkh@linuxfoundation.org
Cc: jonathanh@nvidia.com, bleung@chromium.org, dianders@chromium.org,
	lee.jones@linaro.org, stable@vger.kernel.org,
	stable-commits@vger.kernel.org
Subject: Re: Patch "mfd: cros ec: spi: Don't send first message too soon" has been added to the 3.18-stable tree
Date: Wed, 3 Jan 2018 10:49:21 -0800	[thread overview]
Message-ID: <20180103184920.GA217657@google.com> (raw)
In-Reply-To: <15143882673143@kroah.com>

Hi Greg,

On Wed, Dec 27, 2017 at 04:24:27PM +0100, Greg Kroah-Hartman wrote:
> 
> This is a note to let you know that I've just added the patch titled
> 
>     mfd: cros ec: spi: Don't send first message too soon
> 
> to the 3.18-stable tree which can be found at:
>     http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> 
> The filename of the patch is:
>      mfd-cros-ec-spi-don-t-send-first-message-too-soon.patch
> and it can be found in the queue-3.18 subdirectory.
> 
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable@vger.kernel.org> know about it.
> 
> 
> From 15d8374874ded0bec37ef27f8301a6d54032c0e5 Mon Sep 17 00:00:00 2001
> From: Jon Hunter <jonathanh@nvidia.com>
> Date: Tue, 14 Nov 2017 14:43:27 +0000
> Subject: mfd: cros ec: spi: Don't send first message too soon
> 
> From: Jon Hunter <jonathanh@nvidia.com>
> 
> commit 15d8374874ded0bec37ef27f8301a6d54032c0e5 upstream.
> 
> On the Tegra124 Nyan-Big chromebook the very first SPI message sent to
> the EC is failing.
> 
> The Tegra SPI driver configures the SPI chip-selects to be active-high
> by default (and always has for many years). The EC SPI requires an
> active-low chip-select and so the Tegra chip-select is reconfigured to
> be active-low when the EC SPI driver calls spi_setup(). The problem is
> that if the first SPI message to the EC is sent too soon after
> reconfiguring the SPI chip-select, it fails.
> 
> The EC SPI driver prevents back-to-back SPI messages being sent too
> soon by keeping track of the time the last transfer was sent via the
> variable 'last_transfer_ns'. To prevent the very first transfer being
> sent too soon, initialise the 'last_transfer_ns' variable after calling
> spi_setup() and before sending the first SPI message.
> 
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> Acked-by: Benson Leung <bleung@chromium.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> ---
>  drivers/mfd/cros_ec_spi.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> --- a/drivers/mfd/cros_ec_spi.c
> +++ b/drivers/mfd/cros_ec_spi.c
> @@ -23,6 +23,7 @@
>  #include <linux/slab.h>
>  #include <linux/spi/spi.h>
>  
> +	ec_spi->last_transfer_ns = ktime_get_ns();

Umm, that's not even close to correct? You've stuck this line just below
the headers... You may still need to adjust for some context changes in
3.18 vs. Linus' latest, but this should at least be in
cros_ec_spi_probe().

(The kbuild bots are complaining about your RC branch.)

Brian

>  
>  /* The header byte, which follows the preamble */
>  #define EC_MSG_HEADER			0xec
> 
> 
> Patches currently in stable-queue which might be from jonathanh@nvidia.com are
> 
> queue-3.18/mfd-cros-ec-spi-don-t-send-first-message-too-soon.patch

  reply	other threads:[~2018-01-03 18:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-27 15:24 Patch "mfd: cros ec: spi: Don't send first message too soon" has been added to the 3.18-stable tree gregkh
2018-01-03 18:49 ` Brian Norris [this message]
2018-01-03 19:44   ` Greg KH
2018-01-03 20:35     ` Brian Norris
2018-01-03 20:52       ` Greg KH

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=20180103184920.GA217657@google.com \
    --to=briannorris@chromium.org \
    --cc=bleung@chromium.org \
    --cc=dianders@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jonathanh@nvidia.com \
    --cc=lee.jones@linaro.org \
    --cc=stable-commits@vger.kernel.org \
    --cc=stable@vger.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).