linux-kernel - Re: [PATCH v2 2/2] iio: adc: ti-ads1298: Add driver

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20240210160850.7495b410@jic23-huawei>
Date: Sat, 10 Feb 2024 16:08:50 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Mike Looijmans <mike.looijmans@...ic.nl>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
 devicetree@...r.kernel.org, linux-iio@...r.kernel.org, Lars-Peter Clausen
 <lars@...afoo.de>, Liam Beguin <liambeguin@...il.com>, Liam Girdwood
 <lgirdwood@...il.com>, Maksim Kiselev <bigunclemax@...il.com>, Marcus
 Folkesson <marcus.folkesson@...il.com>, Marius Cristea
 <marius.cristea@...rochip.com>, Mark Brown <broonie@...nel.org>, Niklas
 Schnelle <schnelle@...ux.ibm.com>, Okan Sahin <okan.sahin@...log.com>,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] iio: adc: ti-ads1298: Add driver


> 
> >  
> >>> +	spinlock_t irq_busy_lock; /* Handshake between SPI and DRDY irqs */
> >>> +	int rdata_xfer_busy;
> >>> +
> >>> +	/* Temporary storage for demuxing data after SPI transfer */
> >>> +	u32 bounce_buffer[ADS1298_MAX_CHANNELS];
> >>> +
> >>> +	/* For synchronous SPI exchanges (read/write registers) */
> >>> +	u8 cmd_buffer[ADS1298_SPI_CMD_BUFFER_SIZE] __aligned(IIO_DMA_MINALIGN);
> >>> +
> >>> +	/* Buffer used for incoming SPI data */
> >>> +	u8 rx_buffer[ADS1298_SPI_RDATA_BUFFER_SIZE];  
> > Cacheline aligned?
> > I see the cmd_buffer, but shouldn't this be also aligned?  
> 
> I understood from Jonathan that that wasn't needed... "My" SPI 
> controller is rather dumb and doesn't even have DMA.
> 
> Will take a closer look though.
It should be fine.  The aim here is to ensure that nothing access data in
the same cacheline from the CPU side whilst DMA is ongoing (and unwanted
write backs of stale data can occur). As long at the handling isn't
very complex, a single marking of the first buffer used for DMA (and
being sure there is nothing other than other DMA buffers after it
the same cacheline (potentially multiple lines) is enough.

So the __aligend(IIO_DMA_MINALIGN) on cmd_buffer should work for allt hese
buffers.