linux-kernel - Re: [PATCH 1/3] mfd: cros ec: spi: Add delay for raising CS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <528B9A7F.1040504@nvidia.com>
Date:	Tue, 19 Nov 2013 12:06:07 -0500
From:	Rhyland Klein <rklein@...dia.com>
To:	Thierry Reding <thierry.reding@...il.com>,
	Mark Rutland <mark.rutland@....com>
CC:	Samuel Ortiz <sameo@...ux.intel.com>,
	Lee Jones <lee.jones@...aro.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	Pawel Moll <Pawel.Moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Bernie Thompson <bhthompson@...omium.org>,
	Andrew Bresticker <abrestic@...omium.org>
Subject: Re: [PATCH 1/3] mfd: cros ec: spi: Add delay for raising CS

On 11/19/2013 3:42 AM, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Mon, Nov 18, 2013 at 11:48:10AM +0000, Mark Rutland wrote:
>> On Mon, Nov 18, 2013 at 10:30:47AM +0000, Thierry Reding wrote:
>>> From: Rhyland Klein <rklein@...dia.com>
>>>
>>> The EC has specific timing it requires. Add support for an optional delay
>>> after raising CS to fix timing issues. This is configurable based on
>>> a DT property "google,cros-ec-spi-msg-delay".
>>>
>>> If this property isn't set, then no delay will be added. However, if set
>>> it will cause a delay equal to the value passed to it to be inserted at
>>> the end of a transaction.
>>>
>>> Signed-off-by: Rhyland Klein <rklein@...dia.com>
>>> Reviewed-by: Bernie Thompson <bhthompson@...omium.org>
>>> Reviewed-by: Andrew Bresticker <abrestic@...omium.org>
>>> Cc: Rob Herring <rob.herring@...xeda.com>
>>> Cc: Pawel Moll <pawel.moll@....com>
>>> Cc: Mark Rutland <mark.rutland@....com>
>>> Cc: Ian Campbell <ijc+devicetree@...lion.org.uk>
>>> Signed-off-by: Thierry Reding <treding@...dia.com>
>>> ---
>>>  Documentation/devicetree/bindings/mfd/cros-ec.txt |  4 +++
>>>  drivers/mfd/cros_ec_spi.c                         | 30 +++++++++++++++++++++++
>>>  2 files changed, 34 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mfd/cros-ec.txt b/Documentation/devicetree/bindings/mfd/cros-ec.txt
>>> index 5f229c5f6da9..fb3034a87ae0 100644
>>> --- a/Documentation/devicetree/bindings/mfd/cros-ec.txt
>>> +++ b/Documentation/devicetree/bindings/mfd/cros-ec.txt
>>> @@ -17,6 +17,10 @@ Required properties (SPI):
>>>  - compatible: "google,cros-ec-spi"
>>>  - reg: SPI chip select
>>>  
>>> +Optional properties (SPI):
>>> +- google,cros-ec-spi-msg-delay: This property is how long of a delay, in usecs,
>>> +  to use on the last transfer of a message, to force time between transactions.
>>> +
>>
>> Lose the "This property is", that's obvious from the structure of the
>> document.
> 
> Will do.
> 
>> It would be nice to have an explanation in the binding document as to
>> _why_ you might want to do this (e.g. the HW expects the rising edge to
>> come some number of uS after the data, if it comes too early it
>> explodes).
> 
> From what I can tell, this might differ on the exact variant of the EC,
> but generally it seems that when the interval between two transactions
> isn't long enough the EC won't be able to respond properly in time and
> cause subsequent transactions to hang. Perhaps Rhyland, Bernie or Andrew
> are more familiar with the details and therefore can provide a better or
> more accurate explanation.

I believe this explanation is correct. As I recall, I think adding this
delay helped stabilize communication with the EC, where before sometimes
transactions would time out.

-rhyland

> 
>> Otherwise this looks fine to me.
> 
> Thanks,
> Thierry
> 
> * Unknown Key
> * 0x7F3EB3A1
> 


-- 
nvpublic
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/