linux-kernel - Re: [PATCH v2 2/2] spi: fsl-spi: Implement trailing bits

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <c4950a61-ba9a-5897-1f04-bb2c56979d7d@csgroup.eu>
Date:   Mon, 22 Aug 2022 18:38:22 +0000
From:   Christophe Leroy <christophe.leroy@...roup.eu>
To:     Mark Brown <broonie@...nel.org>
CC:     Rob Herring <robh+dt@...nel.org>, Pratyush Yadav <p.yadav@...com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Herve Codina <herve.codina@...tlin.com>
Subject: Re: [PATCH v2 2/2] spi: fsl-spi: Implement trailing bits



Le 22/08/2022 à 19:15, Mark Brown a écrit :
> On Thu, Aug 18, 2022 at 06:35:39PM +0000, Christophe Leroy wrote:
> 
>> Yes indeed. Therefore in v3 I took a different approach : a flag .cs_off
>> tells to spi_transfer_one_message() that a given transfer has to be
>> performed with chipselect OFF, therefore the consumer has full control
>> of how and when to add those additional fake clock cycles during a
>> transfer, and can eventually add one at anyplace during the transfer.
> 
>> Here an exemple of what will do the consumer.
> 
> Hrm, we should already be able to synthesize that with cs_change though
> there's usability challenges there and AFAICT it doesn't work for the
> first transfer which your proposal would so there's a functional benefit
> even if you don't need it for your device right now.  It would be good
> if you could have a look at using cs_change for your use case.  Sorry, I
> don't think I'd fully realised what you were looking to accomplish here
> until I saw your proposal.

I think we already addressed this possibility back in 2016, see 
https://lore.kernel.org/linux-spi/20160824111206.GD22076@sirena.org.uk/

The conclusion was that it was not possible to accomplish it with cs_change.

Or did we miss something at that time ?

My understanding is that if you set cs_change for any transfer of a 
message except the last, then CS goes OFF then ON again between the said 
transfer and the following one. If you set cs_change for the last 
transfer of a message, then CS stays ON until next message instead of 
going OFF as usual.

My need is to transfer a fake byte with CS off at the end of a message. 
I still can't see how cs_change can achieve that.

Thanks
Christophe