Re: [PATCH 2/2] iio: adc: ti-adc161s626: use DMA-safe memory for spi_read()

[Jonathan Cameron]

On Sat, 21 Mar 2026 14:27:10 -0500
David Lechner <dlechner@xxxxxxxxxxxx> wrote:

> On 3/16/26 1:31 PM, Jonathan Cameron wrote:
> > On Sat, 14 Mar 2026 18:13:32 -0500
> > David Lechner <dlechner@xxxxxxxxxxxx> wrote:
> >   
> >> Add a DMA-safe buffer and use it for spi_read() instead of a stack
> >> memory. All SPI buffers must be DMA-safe.
> >>  
> 
> ...
> 
> >> diff --git a/drivers/iio/adc/ti-adc161s626.c b/drivers/iio/adc/ti-adc161s626.c
> >> index 1d427548e0b3..6416d6a7ada0 100644
> >> --- a/drivers/iio/adc/ti-adc161s626.c
> >> +++ b/drivers/iio/adc/ti-adc161s626.c
> >> @@ -70,6 +70,7 @@ struct ti_adc_data {
> >>  
> >>  	u8 read_size;
> >>  	u8 shift;
> >> +	u8 buf[3] __aligned(IIO_DMA_MINALIGN);  
> > On this. There is new generic infrastructure for marking these.
> > https://elixir.bootlin.com/linux/v7.0-rc3/source/include/linux/dma-mapping.h#L720
> > https://lore.kernel.org/all/01ea88055ded4d70cac70ba557680fd5fa7d9ff5.1767601130.git.mst@xxxxxxxxxx/
> > 
> > Would look like
> > 	__dma_from_device_group_begin();
> > 	u8 buf[3];
> > 	__dma_from_device_group_end();
> > 
> > Do you think we should adopt them rather than doing our own thing?  
> 
> I have mixed thoughts on this.
> 
> Pros:
> * This would make it more obvious it should be at the end of the struct
>   but doesn't hurt if it isn't.
> Cons:
> * It is more verbose.
> * There doesn't seem to be __dma_to_device_group_begin(), so it isn't
>   clear what we should do for tx buffers.

Agreed. Should add that.  Though it would then imply that we should
treat them differently. Hopefully my understanding that we don't need
tx and rx to live in their own cachelines isn't wrong (at least
for all the stuff we care about)!

Let's let this sit for a cycle or two and see how adoption of those
new toys goes.  Longer term I'd generally like to get rid of as 
much that makes us special as possible.

> 
> > Slowly though I don't want the noise of a mass conversion.
> > 
> > As normal, advantage of standard infrastructure is cutting down
> > in subsystem specific magic.
> > 
> > I 'think' result is the same (though it also forces the trailing padding if anything
> > comes after this and needs it).  
>