Re: [RFC 00/17] DRM: fix struct sg_table nents vs. orig_nents misuse

2020-04-28 Thread Robin Murphy
On 2020-04-28 4:32 pm, Daniel Vetter wrote: On Tue, Apr 28, 2020 at 04:02:57PM +0200, Christoph Hellwig wrote: On Tue, Apr 28, 2020 at 03:19:48PM +0200, Marek Szyprowski wrote: 1. introduce a dma_{map,sync,unmap}_sgtable() wrappers, which will use a proper sg_table entries and call respecti

Re: [RFC 00/17] DRM: fix struct sg_table nents vs. orig_nents misuse

2020-04-28 Thread Daniel Vetter
On Tue, Apr 28, 2020 at 04:02:57PM +0200, Christoph Hellwig wrote: > On Tue, Apr 28, 2020 at 03:19:48PM +0200, Marek Szyprowski wrote: > > 1. introduce a dma_{map,sync,unmap}_sgtable() wrappers, which will use > >a proper sg_table entries and call respective DMA-mapping functions > >and ada

Re: [RFC 00/17] DRM: fix struct sg_table nents vs. orig_nents misuse

2020-04-28 Thread Christoph Hellwig
On Tue, Apr 28, 2020 at 03:19:48PM +0200, Marek Szyprowski wrote: > 1. introduce a dma_{map,sync,unmap}_sgtable() wrappers, which will use >a proper sg_table entries and call respective DMA-mapping functions >and adapt current code to it That sounds reasonable to me. Those could be pretty

[RFC 00/17] DRM: fix struct sg_table nents vs. orig_nents misuse

2020-04-28 Thread Marek Szyprowski
Dear All, During the Exynos DRM GEM rework and fixing the issues in the drm_prime_sg_to_page_addr_arrays() function [1] I've noticed that most drivers in DRM framework incorrectly use nents and orig_nents entries of the struct sg_table. In case of the most DMA-mapping implementations exchanging