Hi Am 28.01.22 um 09:15 schrieb Thomas Zimmermann: ...
While with the construct below other_map; ... other_map = INITIALIZER() I can rely on the compiler complaining about uninitialized var. Andin most of the cases I can just have this single line in the beggining of thefunction when the offset is constant:struct dma_buf_map other_map = INITIALIZER(bla_map, offsetof(..));This is useful when you have several small functions in charge of updating/reading inner struct members.You won't need an extra variable or the initializer macro if you add an offset parameter to dma_buf_memcpy_{from,to}. Simple pass offsetof(..) to that parameter and it will do the right thing.It avoids the problems of the current macro and is even more flexible. On top of that, you can build whatever convenience macros you need for i915.
And maybe put all changes to the dma_buf_map interface into a single patch. It makes it easier to review and discuss.
Best regards Thomas
Best regards ThomasI've also been very careful to distinguish between .vaddr and .vaddr_iomem, even in places where I wouldn't have to. This macro breaks the assumption.That's one reason I think if we have this macro, it should be in the dma_buf_map.h header (or whatever we rename these APIs to). It's the only place where we can safely add code that relies on the implementation of the "private" fields in struct dma_buf_map. Lucas De MarchiBest regards Thomas/*** dma_buf_map_set_vaddr - Sets a dma-buf mapping structure to an address in system memory* @map: The dma-buf mapping structure-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
