linux-kernel - Re: [PATCH 3/3] iio: adc: ti-ads7950: use SPI_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] [thread-next>] [day] [month] [year] [list]

Message-ID: <7a70711c-5d38-5ba6-ec90-b2506dc0727d@lechnology.com>
Date:   Tue, 18 Sep 2018 12:14:50 -0500
From:   David Lechner <david@...hnology.com>
To:     linux-spi@...r.kernel.org, linux-iio@...r.kernel.org
Cc:     Jonathan Cameron <jic23@...nel.org>,
        Hartmut Knaack <knaack.h@....de>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        Mark Brown <broonie@...nel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] iio: adc: ti-ads7950: use SPI_CS_WORD to reduce CPU
 usage

On 09/18/2018 12:08 PM, David Lechner wrote:
> This changes how the SPI message for the triggered buffer is setup in
> the TI ADS7950 A/DC driver. By using the SPI_CS_WORD flag, we can read
> multiple samples in a single SPI transfer. If the SPI controller
> supports DMA transfers, we can see a significant reduction in CPU usage.
> 
> For example, on an ARM9 system running at 456MHz reading just 4 channels
> at 100Hz: before this change, top shows the CPU usage of the IRQ thread
> of this driver to be ~7.7%. After this change, the CPU usage drops to
> ~3.8%.
> 
> The use of big-endian for the raw data was cargo culted from another
> driver when this driver was originally written. It used an SPI word size
> of 8 bits and big-endian byte ordering to effectively emulate 16 bit
> words.
> 
> Now, in order to inject a CS toggle between each word, we need to use
> the correct word size, otherwise we would get a CS toggle half way
> through each word 16-bit. The SPI subsystem uses CPU byte ordering for
> multi-byte words. So, the data we get back from the SPI is going to be
> CPU endian now no matter what. Converting that to big endian will just
> add overhead on little endian systems so we opt to change the raw data
> format from big endian to CPU endian.
> 
> There is a small risk that this could break some lazy userspace programs
> that use the raw data without checking the data format. We can address
> this if/when it actually comes up.
> 
> Signed-off-by: David Lechner <david@...hnology.com>
> ---

And I just realized I forgot to pick up...


Reviewed-by: Jonathan Cameron <Jonathan.Cameron@...wei.com>