[Linux-stable-mirror] Patch "mfd: cros ec: spi: Don't send first message too soon" has been added to the 3.18-stable tree
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%3Ba=su...
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();
/* 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
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 soonto the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git%3Ba=su...
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
On Wed, Jan 03, 2018 at 10:49:21AM -0800, Brian Norris wrote:
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 soonto the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git%3Ba=su...
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.)
This was long fixed, did your email just sync?
thanks,
greg k-h
On Wed, Jan 03, 2018 at 08:44:25PM +0100, Greg Kroah-Hartman wrote:
On Wed, Jan 03, 2018 at 10:49:21AM -0800, Brian Norris wrote:
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.)
This was long fixed, did your email just sync?
No. I see no update in my mail (neither in reply to this thread nor to the kbuild email I saw). However, I also don't see this patch in your stable-rc repo now, so maybe you just backed the change out? Perhaps there's some thread(s) where I'm CC'd and some where I'm not?
Anyway, if you aren't applying the previously-quoted patch, then we're OK for now :) It might be good to see a corrected version of this show up in 3.18 -stable still.
Brian
On Wed, Jan 03, 2018 at 12:35:45PM -0800, Brian Norris wrote:
On Wed, Jan 03, 2018 at 08:44:25PM +0100, Greg Kroah-Hartman wrote:
On Wed, Jan 03, 2018 at 10:49:21AM -0800, Brian Norris wrote:
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.)
This was long fixed, did your email just sync?
No. I see no update in my mail (neither in reply to this thread nor to the kbuild email I saw). However, I also don't see this patch in your stable-rc repo now, so maybe you just backed the change out? Perhaps there's some thread(s) where I'm CC'd and some where I'm not?
I dropped it.
Anyway, if you aren't applying the previously-quoted patch, then we're OK for now :) It might be good to see a corrected version of this show up in 3.18 -stable still.
I'll take a working backport if you think it should be there :)
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Brian Norris -
Greg KH -
gregkh＠linuxfoundation.org