[PATCH V2 1/2] mfd: cros ec: spi: Don't send first message too soon

[PATCH V2 1/2] mfd: cros ec: spi: Don't send first message too soon

[Jon Hunter]

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.

Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>

Signed-off-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
Changes since V1:
- Added stable-tag and Brian's reviewed-by.

Looks like this issue has been around for several Linux releases now
and it just depends on timing if this issue is seen or not and so there
is no specific commit this fixes. However, would be good to include for
v4.15.

 drivers/mfd/cros_ec_spi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index c9714072e224..a14196e95e9b 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -667,6 +667,7 @@ static int cros_ec_spi_probe(struct spi_device *spi)
 			   sizeof(struct ec_response_get_protocol_info);
 	ec_dev->dout_size = sizeof(struct ec_host_request);
 
+	ec_spi->last_transfer_ns = ktime_get_ns();
 
 	err = cros_ec_register(ec_dev);
 	if (err) {
-- 
2.7.4

[PATCH V2 1/2] mfd: cros ec: spi: Don't send first message too soon

[Jon Hunter]

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.

Cc: <stable@vger.kernel.org>

Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
---
Changes since V1:
- Added stable-tag and Brian's reviewed-by.

Looks like this issue has been around for several Linux releases now
and it just depends on timing if this issue is seen or not and so there
is no specific commit this fixes. However, would be good to include for
v4.15.

 drivers/mfd/cros_ec_spi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index c9714072e224..a14196e95e9b 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -667,6 +667,7 @@ static int cros_ec_spi_probe(struct spi_device *spi)
 			   sizeof(struct ec_response_get_protocol_info);
 	ec_dev->dout_size = sizeof(struct ec_host_request);
 
+	ec_spi->last_transfer_ns = ktime_get_ns();
 
 	err = cros_ec_register(ec_dev);
 	if (err) {
-- 
2.7.4

[PATCH V2 2/2] mfd: cros ec: spi: Simplify delay handling between SPI messages

[Jon Hunter]

The EC SPI driver prevents SPI transfers being to rapidly by keeping
track of the time the last transfer was issued via the
'last_transfer_ns' variable. Previously, if the 'last_transfer_ns'
variable was zero, this indicated that no previous transfer had been
sent and that no delay was needed. However, the EC SPI driver has
been updated to always initialise the 'last_transfer_ns' variable
during probe and therefore, it is no longer necessary to test if it
is zero. Remove the code that checks if this variable is zero.

Signed-off-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
Changes since V1:
- Added Brian's reviewed-by.

 drivers/mfd/cros_ec_spi.c | 25 +++++++++----------------
 1 file changed, 9 insertions(+), 16 deletions(-)

diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index a14196e95e9b..7849d781c6bb 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -72,8 +72,7 @@
  * struct cros_ec_spi - information about a SPI-connected EC
  *
  * @spi: SPI device we are connected to
- * @last_transfer_ns: time that we last finished a transfer, or 0 if there
- *	if no record
+ * @last_transfer_ns: time that we last finished a transfer.
  * @start_of_msg_delay: used to set the delay_usecs on the spi_transfer that
  *      is sent when we want to turn on CS at the start of a transaction.
  * @end_of_msg_delay: used to set the delay_usecs on the spi_transfer that
@@ -378,18 +377,15 @@ static int cros_ec_pkt_xfer_spi(struct cros_ec_device *ec_dev,
 	u8 *rx_buf;
 	u8 sum;
 	int ret = 0, final_ret;
+	unsigned long delay;
 
 	len = cros_ec_prepare_tx(ec_dev, ec_msg);
 	dev_dbg(ec_dev->dev, "prepared, len=%d\n", len);
 
 	/* If it's too soon to do another transaction, wait */
-	if (ec_spi->last_transfer_ns) {
-		unsigned long delay;	/* The delay completed so far */
-
-		delay = ktime_get_ns() - ec_spi->last_transfer_ns;
-		if (delay < EC_SPI_RECOVERY_TIME_NS)
-			ndelay(EC_SPI_RECOVERY_TIME_NS - delay);
-	}
+	delay = ktime_get_ns() - ec_spi->last_transfer_ns;
+	if (delay < EC_SPI_RECOVERY_TIME_NS)
+		ndelay(EC_SPI_RECOVERY_TIME_NS - delay);
 
 	rx_buf = kzalloc(len, GFP_KERNEL);
 	if (!rx_buf)
@@ -510,18 +506,15 @@ static int cros_ec_cmd_xfer_spi(struct cros_ec_device *ec_dev,
 	u8 *rx_buf;
 	int sum;
 	int ret = 0, final_ret;
+	unsigned long delay;
 
 	len = cros_ec_prepare_tx(ec_dev, ec_msg);
 	dev_dbg(ec_dev->dev, "prepared, len=%d\n", len);
 
 	/* If it's too soon to do another transaction, wait */
-	if (ec_spi->last_transfer_ns) {
-		unsigned long delay;	/* The delay completed so far */
-
-		delay = ktime_get_ns() - ec_spi->last_transfer_ns;
-		if (delay < EC_SPI_RECOVERY_TIME_NS)
-			ndelay(EC_SPI_RECOVERY_TIME_NS - delay);
-	}
+	delay = ktime_get_ns() - ec_spi->last_transfer_ns;
+	if (delay < EC_SPI_RECOVERY_TIME_NS)
+		ndelay(EC_SPI_RECOVERY_TIME_NS - delay);
 
 	rx_buf = kzalloc(len, GFP_KERNEL);
 	if (!rx_buf)
-- 
2.7.4

[PATCH V2 2/2] mfd: cros ec: spi: Simplify delay handling between SPI messages

[Jon Hunter]

The EC SPI driver prevents SPI transfers being to rapidly by keeping
track of the time the last transfer was issued via the
'last_transfer_ns' variable. Previously, if the 'last_transfer_ns'
variable was zero, this indicated that no previous transfer had been
sent and that no delay was needed. However, the EC SPI driver has
been updated to always initialise the 'last_transfer_ns' variable
during probe and therefore, it is no longer necessary to test if it
is zero. Remove the code that checks if this variable is zero.

Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
---
Changes since V1:
- Added Brian's reviewed-by.

 drivers/mfd/cros_ec_spi.c | 25 +++++++++----------------
 1 file changed, 9 insertions(+), 16 deletions(-)

diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index a14196e95e9b..7849d781c6bb 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -72,8 +72,7 @@
  * struct cros_ec_spi - information about a SPI-connected EC
  *
  * @spi: SPI device we are connected to
- * @last_transfer_ns: time that we last finished a transfer, or 0 if there
- *	if no record
+ * @last_transfer_ns: time that we last finished a transfer.
  * @start_of_msg_delay: used to set the delay_usecs on the spi_transfer that
  *      is sent when we want to turn on CS at the start of a transaction.
  * @end_of_msg_delay: used to set the delay_usecs on the spi_transfer that
@@ -378,18 +377,15 @@ static int cros_ec_pkt_xfer_spi(struct cros_ec_device *ec_dev,
 	u8 *rx_buf;
 	u8 sum;
 	int ret = 0, final_ret;
+	unsigned long delay;
 
 	len = cros_ec_prepare_tx(ec_dev, ec_msg);
 	dev_dbg(ec_dev->dev, "prepared, len=%d\n", len);
 
 	/* If it's too soon to do another transaction, wait */
-	if (ec_spi->last_transfer_ns) {
-		unsigned long delay;	/* The delay completed so far */
-
-		delay = ktime_get_ns() - ec_spi->last_transfer_ns;
-		if (delay < EC_SPI_RECOVERY_TIME_NS)
-			ndelay(EC_SPI_RECOVERY_TIME_NS - delay);
-	}
+	delay = ktime_get_ns() - ec_spi->last_transfer_ns;
+	if (delay < EC_SPI_RECOVERY_TIME_NS)
+		ndelay(EC_SPI_RECOVERY_TIME_NS - delay);
 
 	rx_buf = kzalloc(len, GFP_KERNEL);
 	if (!rx_buf)
@@ -510,18 +506,15 @@ static int cros_ec_cmd_xfer_spi(struct cros_ec_device *ec_dev,
 	u8 *rx_buf;
 	int sum;
 	int ret = 0, final_ret;
+	unsigned long delay;
 
 	len = cros_ec_prepare_tx(ec_dev, ec_msg);
 	dev_dbg(ec_dev->dev, "prepared, len=%d\n", len);
 
 	/* If it's too soon to do another transaction, wait */
-	if (ec_spi->last_transfer_ns) {
-		unsigned long delay;	/* The delay completed so far */
-
-		delay = ktime_get_ns() - ec_spi->last_transfer_ns;
-		if (delay < EC_SPI_RECOVERY_TIME_NS)
-			ndelay(EC_SPI_RECOVERY_TIME_NS - delay);
-	}
+	delay = ktime_get_ns() - ec_spi->last_transfer_ns;
+	if (delay < EC_SPI_RECOVERY_TIME_NS)
+		ndelay(EC_SPI_RECOVERY_TIME_NS - delay);
 
 	rx_buf = kzalloc(len, GFP_KERNEL);
 	if (!rx_buf)
-- 
2.7.4

Re: [PATCH V2 1/2] mfd: cros ec: spi: Don't send first message too soon

[Doug Anderson]

Hi,

On Tue, Nov 14, 2017 at 6:43 AM, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> 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.
>
> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
>
> Signed-off-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> ---
> Changes since V1:
> - Added stable-tag and Brian's reviewed-by.
>
> Looks like this issue has been around for several Linux releases now
> and it just depends on timing if this issue is seen or not and so there
> is no specific commit this fixes. However, would be good to include for
> v4.15.
>
>  drivers/mfd/cros_ec_spi.c | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

Re: [PATCH V2 1/2] mfd: cros ec: spi: Don't send first message too soon

[Doug Anderson]

Hi,

On Tue, Nov 14, 2017 at 6:43 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
> 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.
>
> Cc: <stable@vger.kernel.org>
>
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
> ---
> Changes since V1:
> - Added stable-tag and Brian's reviewed-by.
>
> Looks like this issue has been around for several Linux releases now
> and it just depends on timing if this issue is seen or not and so there
> is no specific commit this fixes. However, would be good to include for
> v4.15.
>
>  drivers/mfd/cros_ec_spi.c | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Douglas Anderson <dianders@chromium.org>

Re: [PATCH V2 2/2] mfd: cros ec: spi: Simplify delay handling between SPI messages

[Doug Anderson]

Hi,

On Tue, Nov 14, 2017 at 6:43 AM, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> The EC SPI driver prevents SPI transfers being to rapidly by keeping
> track of the time the last transfer was issued via the
> 'last_transfer_ns' variable. Previously, if the 'last_transfer_ns'
> variable was zero, this indicated that no previous transfer had been
> sent and that no delay was needed. However, the EC SPI driver has
> been updated to always initialise the 'last_transfer_ns' variable
> during probe and therefore, it is no longer necessary to test if it
> is zero. Remove the code that checks if this variable is zero.
>
> Signed-off-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> ---
> Changes since V1:
> - Added Brian's reviewed-by.
>
>  drivers/mfd/cros_ec_spi.c | 25 +++++++++----------------
>  1 file changed, 9 insertions(+), 16 deletions(-)

Reviewed-by: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

Re: [PATCH V2 2/2] mfd: cros ec: spi: Simplify delay handling between SPI messages

[Doug Anderson]

Hi,

On Tue, Nov 14, 2017 at 6:43 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
> The EC SPI driver prevents SPI transfers being to rapidly by keeping
> track of the time the last transfer was issued via the
> 'last_transfer_ns' variable. Previously, if the 'last_transfer_ns'
> variable was zero, this indicated that no previous transfer had been
> sent and that no delay was needed. However, the EC SPI driver has
> been updated to always initialise the 'last_transfer_ns' variable
> during probe and therefore, it is no longer necessary to test if it
> is zero. Remove the code that checks if this variable is zero.
>
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
> ---
> Changes since V1:
> - Added Brian's reviewed-by.
>
>  drivers/mfd/cros_ec_spi.c | 25 +++++++++----------------
>  1 file changed, 9 insertions(+), 16 deletions(-)

Reviewed-by: Douglas Anderson <dianders@chromium.org>

Re: [PATCH V2 1/2] mfd: cros ec: spi: Don't send first message too soon

[Benson Leung]

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

Hi Jon,

On Tue, Nov 14, 2017 at 02:43:27PM +0000, Jon Hunter wrote:
> 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.
> 
> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> 
> Signed-off-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

Acked-by: Benson Leung <bleung-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
bleung-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
Chromium OS Project
bleung-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH V2 1/2] mfd: cros ec: spi: Don't send first message too soon

[Benson Leung]

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

Hi Jon,

On Tue, Nov 14, 2017 at 02:43:27PM +0000, Jon Hunter wrote:
> 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.
> 
> Cc: <stable@vger.kernel.org>
> 
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> Reviewed-by: Brian Norris <briannorris@chromium.org>

Acked-by: Benson Leung <bleung@chromium.org>

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
bleung@google.com
Chromium OS Project
bleung@chromium.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH V2 2/2] mfd: cros ec: spi: Simplify delay handling between SPI messages

[Benson Leung]

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

Hi Jon,

On Tue, Nov 14, 2017 at 02:43:28PM +0000, Jon Hunter wrote:
> The EC SPI driver prevents SPI transfers being to rapidly by keeping
> track of the time the last transfer was issued via the
> 'last_transfer_ns' variable. Previously, if the 'last_transfer_ns'
> variable was zero, this indicated that no previous transfer had been
> sent and that no delay was needed. However, the EC SPI driver has
> been updated to always initialise the 'last_transfer_ns' variable
> during probe and therefore, it is no longer necessary to test if it
> is zero. Remove the code that checks if this variable is zero.
> 
> Signed-off-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

Acked-by: Benson Leung <bleung-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
bleung-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
Chromium OS Project
bleung-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH V2 2/2] mfd: cros ec: spi: Simplify delay handling between SPI messages

[Benson Leung]

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

Hi Jon,

On Tue, Nov 14, 2017 at 02:43:28PM +0000, Jon Hunter wrote:
> The EC SPI driver prevents SPI transfers being to rapidly by keeping
> track of the time the last transfer was issued via the
> 'last_transfer_ns' variable. Previously, if the 'last_transfer_ns'
> variable was zero, this indicated that no previous transfer had been
> sent and that no delay was needed. However, the EC SPI driver has
> been updated to always initialise the 'last_transfer_ns' variable
> during probe and therefore, it is no longer necessary to test if it
> is zero. Remove the code that checks if this variable is zero.
> 
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> Reviewed-by: Brian Norris <briannorris@chromium.org>

Acked-by: Benson Leung <bleung@chromium.org>

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
bleung@google.com
Chromium OS Project
bleung@chromium.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH V2 1/2] mfd: cros ec: spi: Don't send first message too soon

[Jon Hunter]

Hi Lee,

On 14/11/17 14:43, Jon Hunter wrote:
> 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.
> 
> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> 
> Signed-off-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> ---
> Changes since V1:
> - Added stable-tag and Brian's reviewed-by.
> 
> Looks like this issue has been around for several Linux releases now
> and it just depends on timing if this issue is seen or not and so there
> is no specific commit this fixes. However, would be good to include for
> v4.15.
> 
>  drivers/mfd/cros_ec_spi.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
> index c9714072e224..a14196e95e9b 100644
> --- a/drivers/mfd/cros_ec_spi.c
> +++ b/drivers/mfd/cros_ec_spi.c
> @@ -667,6 +667,7 @@ static int cros_ec_spi_probe(struct spi_device *spi)
>  			   sizeof(struct ec_response_get_protocol_info);
>  	ec_dev->dout_size = sizeof(struct ec_host_request);
>  
> +	ec_spi->last_transfer_ns = ktime_get_ns();
>  
>  	err = cros_ec_register(ec_dev);
>  	if (err) {

Can you queue this as a fix for v4.15-rc1?

Cheers
Jon

-- 
nvpublic

Re: [PATCH V2 1/2] mfd: cros ec: spi: Don't send first message too soon

[Jon Hunter]

Hi Lee,

On 14/11/17 14:43, Jon Hunter wrote:
> 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.
> 
> Cc: <stable@vger.kernel.org>
> 
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
> ---
> Changes since V1:
> - Added stable-tag and Brian's reviewed-by.
> 
> Looks like this issue has been around for several Linux releases now
> and it just depends on timing if this issue is seen or not and so there
> is no specific commit this fixes. However, would be good to include for
> v4.15.
> 
>  drivers/mfd/cros_ec_spi.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
> index c9714072e224..a14196e95e9b 100644
> --- a/drivers/mfd/cros_ec_spi.c
> +++ b/drivers/mfd/cros_ec_spi.c
> @@ -667,6 +667,7 @@ static int cros_ec_spi_probe(struct spi_device *spi)
>  			   sizeof(struct ec_response_get_protocol_info);
>  	ec_dev->dout_size = sizeof(struct ec_host_request);
>  
> +	ec_spi->last_transfer_ns = ktime_get_ns();
>  
>  	err = cros_ec_register(ec_dev);
>  	if (err) {

Can you queue this as a fix for v4.15-rc1?

Cheers
Jon

-- 
nvpublic

Re: [PATCH V2 1/2] mfd: cros ec: spi: Don't send first message too soon

[Lee Jones]

On Tue, 28 Nov 2017, Jon Hunter wrote:
> On 14/11/17 14:43, Jon Hunter wrote:
> > 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.
> > 
> > Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> > 
> > Signed-off-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > ---
> > Changes since V1:
> > - Added stable-tag and Brian's reviewed-by.
> > 
> > Looks like this issue has been around for several Linux releases now
> > and it just depends on timing if this issue is seen or not and so there
> > is no specific commit this fixes. However, would be good to include for
> > v4.15.
> > 
> >  drivers/mfd/cros_ec_spi.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
> > index c9714072e224..a14196e95e9b 100644
> > --- a/drivers/mfd/cros_ec_spi.c
> > +++ b/drivers/mfd/cros_ec_spi.c
> > @@ -667,6 +667,7 @@ static int cros_ec_spi_probe(struct spi_device *spi)
> >  			   sizeof(struct ec_response_get_protocol_info);
> >  	ec_dev->dout_size = sizeof(struct ec_host_request);
> >  
> > +	ec_spi->last_transfer_ns = ktime_get_ns();
> >  
> >  	err = cros_ec_register(ec_dev);
> >  	if (err) {
> 
> Can you queue this as a fix for v4.15-rc1?

No, but I will submit it for one of the v4.15-rcs.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH V2 1/2] mfd: cros ec: spi: Don't send first message too soon

[Lee Jones]

On Tue, 28 Nov 2017, Jon Hunter wrote:
> On 14/11/17 14:43, Jon Hunter wrote:
> > 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.
> > 
> > Cc: <stable@vger.kernel.org>
> > 
> > Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> > Reviewed-by: Brian Norris <briannorris@chromium.org>
> > ---
> > Changes since V1:
> > - Added stable-tag and Brian's reviewed-by.
> > 
> > Looks like this issue has been around for several Linux releases now
> > and it just depends on timing if this issue is seen or not and so there
> > is no specific commit this fixes. However, would be good to include for
> > v4.15.
> > 
> >  drivers/mfd/cros_ec_spi.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
> > index c9714072e224..a14196e95e9b 100644
> > --- a/drivers/mfd/cros_ec_spi.c
> > +++ b/drivers/mfd/cros_ec_spi.c
> > @@ -667,6 +667,7 @@ static int cros_ec_spi_probe(struct spi_device *spi)
> >  			   sizeof(struct ec_response_get_protocol_info);
> >  	ec_dev->dout_size = sizeof(struct ec_host_request);
> >  
> > +	ec_spi->last_transfer_ns = ktime_get_ns();
> >  
> >  	err = cros_ec_register(ec_dev);
> >  	if (err) {
> 
> Can you queue this as a fix for v4.15-rc1?

No, but I will submit it for one of the v4.15-rcs.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog