linux-kernel - Re: [PATCH v3] iio: adc: Add support for TI ADC108S102 and ADC128S102

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:   Sun, 7 May 2017 12:17:24 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Jan Kiszka <jan.kiszka@...mens.com>
Cc:     linux-iio@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Sascha Weisenberger <sascha.weisenberger@...mens.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        Rob Herring <robh@...nel.org>
Subject: Re: [PATCH v3] iio: adc: Add support for TI ADC108S102 and ADC128S102

On 05/05/17 20:09, Andy Shevchenko wrote:
> On Fri, 2017-05-05 at 19:55 +0100, Jonathan Cameron wrote:
>> On 05/05/17 07:31, Jan Kiszka wrote:
> 
>>> +
>>> +	/*
>>> +	 * SPI message buffers:
>>> +	 *  tx_buf: |C0|C1|C2|C3|C4|C5|C6|C7|XX|
>>> +	 *  rx_buf: |XX|R0|R1|R2|R3|R4|R5|R6|R7|tt|tt|tt|tt|
>>> +	 *
>>> +	 *  tx_buf: 8 channel read commands, plus 1 dummy command
>>> +	 *  rx_buf: 1 dummy response, 8 channel responses, plus 64-
>>> bit timestamp
>>> +	 */
>>> +	__be16				rx_buf[13]
>>> ____cacheline_aligned;
>>> +	__be16				tx_buf[9]
>>> ____cacheline_aligned;
>>
>> I would have thought the SPI dma wouldn't take itself out so you
>> should be
>> good with just the one cacheline_aligned?  Maybe I'm missing
>> something.
> 
> It was my idea for sake of consistency. Just to explicitly show that
> buffers a cache aligned.
> 
> If you insist to remove one, it's your call at the end ;-)
> 
As far as I know the only reason the 'need' to be cacheline aligned
is to avoid corruption issues if any other elements sharing the
cacheline (ie.earlier elements in our structure) change whilst the
dma is progress.  Doesn't matter if the second is also so aligned
as we should only have one dma type transfer going on at a time
(plenty of locking in spi to ensure this).

It's not a big point though so doesn't really matter as it is
safe either way!

Jonathan