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 05:30:04 -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

>> As things are right now both SPI subsystem and SPIDEV driver are
>> limited by their APIs to SPI transactions that are no longer than 255
>> bits and that problem is exacerbated by the fact that transction
>> length validity verification code does not have provisions for
>> anything bigger than 32 bits.
>
> No, that's not the case at all.  A spi_transfer can have a length that's
> an unsigned integer number of bytes which is much larger than 255 bits.
> What is the actual problem you're trying to solve here?  I suspect the
> driver you are using is just badly implemented...

Yes, and you're absolutely right about spi_transfer, however I wasn't
talking about spi_transfer at all. My point was about SPI transaction
which is all the bits shifted out on the bus(and shifted in as well)
during the duration of the CS/SS signal assertion.

>
>> +             if (!u_tmp->bits_per_word && u_tmp->bits_per_burst)
>> +                     k_tmp->bits_per_word = u_tmp->bits_per_burst;
>> +             else
>> +                     k_tmp->bits_per_word = u_tmp->bits_per_word;
>
> This is setting the number of bits per word which is nothing to do with
> FIFOs or the lengths of transfers but instead concerns the formatting of
> data onto the bus.

I don't believe I said that this commit had anything to do with FIFO.
I did acknowledge that fact that modern SoC have large FIFO and this
is relevant because often times the size of that FIFO is what
determines the size of a single SPI transaction. I tried to be careful
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

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/