Skip to contentSkip to conversation

Patch "mfd: cros ec: spi: Don't send first message too soon" has been added to the 3.18-stable tree

PATCH [email protected] 2 participants 5 messages Dec 27, 2017 – Jan 3, 2018

Subsystems (3)
Stable branch Multifunction devices (MFD) ChromeOS EC subdrivers
lore
Share & tools
lore

[email protected]

author maintainer Applied
#0 lore raw

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 <[email protected]> know about it.

Quoted 1 line

From 15d8374874ded0bec37ef27f8301a6d54032c0e5 Mon Sep 17 00:00:00 2001

From: Jon Hunter <[email protected]>
Date: Tue, 14 Nov 2017 14:43:27 +0000
Subject: mfd: cros ec: spi: Don't send first message too soon

From: Jon Hunter <[email protected]>

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 <[email protected]>
Reviewed-by Brian Norris <[email protected]>
Reviewed-by Douglas Anderson <[email protected]>
Acked-by Benson Leung <[email protected]>
Signed-off-by Lee Jones <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 drivers/mfd/cros_ec_spi.c |    1 +
 1 file changed, 1 insertion(+)
drivers/mfd/cros_ec_spi.c +1 -0
@@ -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 [email protected] are

queue-3.18/mfd-cros-ec-spi-don-t-send-first-message-too-soon.patch

#1 lore raw

Hi Greg,

Quoted 55 lines · Greg Kroah-Hartman

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 <[email protected]> know about it.

From 15d8374874ded0bec37ef27f8301a6d54032c0e5 Mon Sep 17 00:00:00 2001
From: Jon Hunter <[email protected]>
Date: Tue, 14 Nov 2017 14:43:27 +0000
Subject: mfd: cros ec: spi: Don't send first message too soon

From: Jon Hunter <[email protected]>

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 <[email protected]>
Reviewed-by Brian Norris <[email protected]>
Reviewed-by Douglas Anderson <[email protected]>
Acked-by Benson Leung <[email protected]>
Signed-off-by Lee Jones <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 drivers/mfd/cros_ec_spi.c |    1 +
 1 file changed, 1 insertion(+)

drivers/mfd/cros_ec_spi.c line 26

Quoted 4 lines
drivers/mfd/cros_ec_spi.c +1 -0
@@ -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

Quoted 8 lines
drivers/mfd/cros_ec_spi.c +0 -0
 /* The header byte, which follows the preamble */
 #define EC_MSG_HEADER			0xec

Patches currently in stable-queue which might be from [email protected] are

queue-3.18/mfd-cros-ec-spi-don-t-send-first-message-too-soon.patch

author maintainer
#2 lore raw
Quoted 61 lines · Brian Norris

Hi Greg,

Quoted 58 lines · Greg Kroah-Hartman

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 <[email protected]> know about it.

From 15d8374874ded0bec37ef27f8301a6d54032c0e5 Mon Sep 17 00:00:00 2001
From: Jon Hunter <[email protected]>
Date: Tue, 14 Nov 2017 14:43:27 +0000
Subject: mfd: cros ec: spi: Don't send first message too soon

From: Jon Hunter <[email protected]>

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 <[email protected]>
Reviewed-by Brian Norris <[email protected]>
Reviewed-by Douglas Anderson <[email protected]>
Acked-by Benson Leung <[email protected]>
Signed-off-by Lee Jones <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 drivers/mfd/cros_ec_spi.c |    1 +
 1 file changed, 1 insertion(+)
drivers/mfd/cros_ec_spi.c +0 -0
@@ -23,6 +23,7 @@
 #include <linux/slab.h>
 #include <linux/spi/spi.h>
Quoted 8 lines

drivers/mfd/cros_ec_spi.c line 26

Quoted 1 line
drivers/mfd/cros_ec_spi.c +1 -0
+	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

#3 lore raw
Quoted 9 lines · Greg Kroah-Hartman
Quoted 6 lines · Brian Norris

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

author maintainer
#4 lore raw
Quoted 7 lines · Brian Norris
Quoted 6 lines · Greg Kroah-Hartman
Quoted 5 lines · Brian Norris

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().

Quoted 8 lines
Quoted 3 lines
Quoted 1 line

(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.

Quoted 3 lines

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