Re: [RFC v1 3/4] swiotlb: Allow dynamic allocation of bounce buffers

[Petr Tesařík]

Hi Robin,

On Fri, 21 Apr 2023 15:58:18 +0100
Robin Murphy <robin.murphy@xxxxxxx> wrote:

> On 2023-04-21 14:03, Petr Tesařík wrote:
>[...]
> > Here my question: What did you want for DMA fields?
> > 
> > A. Only grouping those fields in their own struct?
> > B. Or move the definition to another include file (cf. MAINTAINERS)?
> > C. Or store a pointer in struct device?  
> 
> dev->dma_parms is already this, and IIRC still has some very old 
> comments somewhere about consolidating the other DMA-related fields in 
> there.

Thank you for the hint! I have actually seen dma_parms, but since it
can be NULL and was initialized from various drivers, it did not occur
to me that NULL simply means not DMA-capable.

This is really helpful.

Petr T

> > Since you mentioned "allocated", it sounds like you want to achieve C,
> > but:
> > 
> > 1. Is it worth the extra dereference for every use?
> > 2. How should the struct be allocated? Presumably not with kmalloc() in
> >     device_initialize(), because I don't know how to determine if a
> >     device is DMA capable this low in the call stack. So, should it be
> >     allocated together with the containing structure? AFAICS this would
> >     mean changing nearly all device drivers...  
> 
> The bus code knows whether it's a DMA-capable bus or not, and as such 
> should already be providing a .dma_configure method and/or performing 
> some initialisation of DMA fields. Many of the ones that would need to 
> are already providing dma_parms, in fact.
> 
> Thanks,
> Robin.
> 
> > 
> > As you can see, I need some more guidance from you before I can start
> > working on this. ;-)
> > 
> > Petr T