linux-kernel - Re: [RFC, PATCH, RESEND] spi, spidev: Add support for long SPI transfers

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]

Date:	Tue, 25 Nov 2014 13:18:45 -0800
From:	Andrey Smirnov <andrew.smirnov@...il.com>
To:	Mark Brown <broonie@...nel.org>
Cc:	linux-spi@...r.kernel.org, Andrey Yurovsky <yurovsky@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC, PATCH, RESEND] spi, spidev: Add support for long SPI transfers

>
> A spi_message (which is the thing that covers the entire /CS assert
> modulo non-standard fiddling) is composed of multiple spi_transfers
> so the above still applies...
>

You are correct, I think I was confused because the driver I was
working with didn't seem to implement it this way for hardware CS
case.

>
> No it doesn't, chip select can frequently be manipulated independently of
> data transfers and almost all controllers can support transfers much
> longer than their FIFOs either by doing that or by keeping the FIFO
> topped up during transfer.

You are correct, I reread the datasheet and even from my niche use
case FIFO depth is irrelevant. I apologize.

>
>> in my wording of the summary and not use the word "transfer" anywhere,
>> but it looks like I slipped twice and that might have contributed to
>> this confusion. I apologize for this and hope that my comments
>> clarified my meaning/intent
>
> Sorry it's still not at all clear, please re-read what I wrote about
> what bits_per_word means since I really don't think you've understood
> what it's for.

OK, I think I use too generic terms and descriptions and maybe that's
why it is not very clear what I mean. Just to give more context I am
working with i.MX6 SPI peripheral, and AFAIK I have two options of
using it:

- Use a generic GPIO as SS/CS. This way everything works exactly as
you describe, but unfortunately using GPIO leads to a significant
overhead for SS/CS assertion/deassertion.

- Use hardware controlled SS/CS in which case peripheral toggles the
line every "burst" it transmits, "burst" is n bits where n can be from
1 to 2^12
 For 1 <= n <= 32, and software SS/CS the concept of a "burst" matches
the meaning of "bits_per_word" field and this is exactly how it is
setup in the driver.

So with all of this in mind what I am trying to achive is to have
longest transaction with minimal CS/SS switching overhead. The change
in my patch allows me to set the length of a burst to its limit.

Andrey
--
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/