- Linaro-mm-sig - lists.linaro.org

Re: [PATCH] dma-buf: add DMA_BUF_IOCTL_SYNC_PARTIAL support

by Christian König

Am 07.04.24 um 09:50 schrieb Rong Qianfeng: > [SNIP] >> Am 13.11.21 um 07:22 schrieb Jianqun Xu: >>> Add DMA_BUF_IOCTL_SYNC_PARTIAL support for user to sync dma-buf with >>> offset and len. >> >> You have not given an use case for this so it is a bit hard to >> review. And from the existing use cases I don't see why this should >> be necessary. >> >> Even worse from the existing backend implementation I don't even see >> how drivers should be able to fulfill this semantics. >> >> Please explain further, >> Christian. > Here is a practical case: > The user space can allocate a large chunk of dma-buf for > self-management, used as a shared memory pool. > Small dma-buf can be allocated from this shared memory pool and > released back to it after use, thus improving the speed of dma-buf > allocation and release. > Additionally, custom functionalities such as memory statistics and > boundary checking can be implemented in the user space. > Of course, the above-mentioned functionalities require the > implementation of a partial cache sync interface. Well that is obvious, but where is the code doing that? You can't send out code without an actual user of it. That will obviously be rejected. Regards, Christian. > > Thanks > Rong Qianfeng.

1 year, 10 months

1
0
0 0

[PATCH v9 0/6] iio: new DMABUF based API

by Paul Cercueil

Hi Jonathan, Here's the final-er version of the IIO DMABUF patchset. This v9 fixes the few issues reported by the kernel bot. This was based on next-20240308. Changelog: - [3/6]: - Select DMA_SHARED_BUFFER in Kconfig - Remove useless forward declaration of 'iio_dma_fence' - Import DMA-BUF namespace - Add missing __user tag to iio_buffer_detach_dmabuf() argument Cheers, -Paul Paul Cercueil (6): dmaengine: Add API function dmaengine_prep_peripheral_dma_vec() dmaengine: dma-axi-dmac: Implement device_prep_peripheral_dma_vec iio: core: Add new DMABUF interface infrastructure iio: buffer-dma: Enable support for DMABUFs iio: buffer-dmaengine: Support new DMABUF based userspace API Documentation: iio: Document high-speed DMABUF based API Documentation/iio/iio_dmabuf_api.rst | 54 ++ Documentation/iio/index.rst | 1 + drivers/dma/dma-axi-dmac.c | 40 ++ drivers/iio/Kconfig | 1 + drivers/iio/buffer/industrialio-buffer-dma.c | 181 ++++++- .../buffer/industrialio-buffer-dmaengine.c | 59 ++- drivers/iio/industrialio-buffer.c | 462 ++++++++++++++++++ include/linux/dmaengine.h | 27 + include/linux/iio/buffer-dma.h | 31 ++ include/linux/iio/buffer_impl.h | 30 ++ include/uapi/linux/iio/buffer.h | 22 + 11 files changed, 891 insertions(+), 17 deletions(-) create mode 100644 Documentation/iio/iio_dmabuf_api.rst -- 2.43.0

1 year, 10 months

4
12
0 0

Re: [PATCH] dmabuf: fix dmabuf file poll uaf issue

by Christian König

Am 02.04.24 um 08:49 schrieb zhiguojiang: >> As far as I can see that's not because of the DMA-buf code, but >> because you are somehow using this interface incorrectly. >> >> When dma_buf_poll() is called it is mandatory for the caller to hold >> a reference to the file descriptor on which the poll operation is >> executed. >> >> So adding code like "if (!file_count(file))" in the beginning of >> dma_buf_poll() is certainly broken. >> >> My best guess is that you have some unbalanced >> dma_buf_get()/dma_buf_put() somewhere instead. >> >> > Hi Christian, > > The kernel dma_buf_poll() code shound not cause system crashes due to > the user mode usage logical issues ? What user mode logical issues are you talking about? Closing a file while polling on it is perfectly valid. dma_buf_poll() is called by the filesystem layer and it's the filesystem layer which should make sure that a file can't be closed while polling for an event. If that doesn't work then you have stumbled over a massive bug in the fs layer. And I have some doubts that this is actually the case. What is more likely is that some driver messes up the reference count and because of this you see an UAF. Anyway as far as I can see the DMA-buf code is correct regarding this. Regards, Christian. > > Thanks > > > 在 2024/4/1 20:22, Christian König 写道: >> Am 27.03.24 um 03:29 schrieb Zhiguo Jiang: >>> The issue is a UAF issue of dmabuf file fd. Throght debugging, we found >>> that the dmabuf file fd is added to the epoll event listener list, and >>> when it is released, it is not removed from the epoll list, which leads >>> to the UAF(Use-After-Free) issue. >> >> As far as I can see that's not because of the DMA-buf code, but >> because you are somehow using this interface incorrectly. >> >> When dma_buf_poll() is called it is mandatory for the caller to hold >> a reference to the file descriptor on which the poll operation is >> executed. >> >> So adding code like "if (!file_count(file))" in the beginning of >> dma_buf_poll() is certainly broken. >> >> My best guess is that you have some unbalanced >> dma_buf_get()/dma_buf_put() somewhere instead. >> >> Regards, >> Christian. >> >>> >>> The UAF issue can be solved by checking dmabuf file->f_count value and >>> skipping the poll operation for the closed dmabuf file in the >>> dma_buf_poll(). We have tested this solved patch multiple times and >>> have not reproduced the uaf issue. >>> >>> crash dump: >>> list_del corruption, ffffff8a6f143a90->next is LIST_POISON1 >>> (dead000000000100) >>> ------------[ cut here ]------------ >>> kernel BUG at lib/list_debug.c:55! >>> Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP >>> pc : __list_del_entry_valid+0x98/0xd4 >>> lr : __list_del_entry_valid+0x98/0xd4 >>> sp : ffffffc01d413d00 >>> x29: ffffffc01d413d00 x28: 00000000000000c0 x27: 0000000000000020 >>> x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000080007 >>> x23: ffffff8b22e5dcc0 x22: ffffff88a6be12d0 x21: ffffff8b22e572b0 >>> x20: ffffff80254ed0a0 x19: ffffff8a6f143a00 x18: ffffffda5efed3c0 >>> x17: 6165642820314e4f x16: 53494f505f545349 x15: 4c20736920747865 >>> x14: 6e3e2d3039613334 x13: 2930303130303030 x12: 0000000000000018 >>> x11: ffffff8b6c188000 x10: 00000000ffffffff x9 : 6c8413a194897b00 >>> x8 : 6c8413a194897b00 x7 : 74707572726f6320 x6 : 6c65645f7473696c >>> x5 : ffffff8b6c3b2a3e x4 : ffffff8b6c3b2a40 x3 : ffff103000001005 >>> x2 : 0000000000000001 x1 : 00000000000000c0 x0 : 000000000000004e >>> Call trace: >>> __list_del_entry_valid+0x98/0xd4 >>> dma_buf_file_release+0x48/0x90 >>> __fput+0xf4/0x280 >>> ____fput+0x10/0x20 >>> task_work_run+0xcc/0xf4 >>> do_notify_resume+0x2a0/0x33c >>> el0_svc+0x5c/0xa4 >>> el0t_64_sync_handler+0x68/0xb4 >>> el0t_64_sync+0x1a0/0x1a4 >>> Code: d0006fe0 912c5000 f2fbd5a2 94231a01 (d4210000) >>> ---[ end trace 0000000000000000 ]--- >>> Kernel panic - not syncing: Oops - BUG: Fatal exception >>> SMP: stopping secondary CPUs >>> >>> Signed-off-by: Zhiguo Jiang <justinjiang(a)vivo.com> >>> --- >>> drivers/dma-buf/dma-buf.c | 28 ++++++++++++++++++++++++---- >>> 1 file changed, 24 insertions(+), 4 deletions(-) >>> mode change 100644 => 100755 drivers/dma-buf/dma-buf.c >>> >>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c >>> index 8fe5aa67b167..e469dd9288cc >>> --- a/drivers/dma-buf/dma-buf.c >>> +++ b/drivers/dma-buf/dma-buf.c >>> @@ -240,6 +240,10 @@ static __poll_t dma_buf_poll(struct file *file, >>> poll_table *poll) >>> struct dma_resv *resv; >>> __poll_t events; >>> + /* Check if the file exists */ >>> + if (!file_count(file)) >>> + return EPOLLERR; >>> + >>> dmabuf = file->private_data; >>> if (!dmabuf || !dmabuf->resv) >>> return EPOLLERR; >>> @@ -266,8 +270,15 @@ static __poll_t dma_buf_poll(struct file *file, >>> poll_table *poll) >>> spin_unlock_irq(&dmabuf->poll.lock); >>> if (events & EPOLLOUT) { >>> - /* Paired with fput in dma_buf_poll_cb */ >>> - get_file(dmabuf->file); >>> + /* >>> + * Paired with fput in dma_buf_poll_cb, >>> + * Skip poll for the closed file. >>> + */ >>> + if (!get_file_rcu(&dmabuf->file)) { >>> + events &= ~EPOLLOUT; >>> + dcb->active = 0; >>> + goto clear_out_event; >>> + } >>> if (!dma_buf_poll_add_cb(resv, true, dcb)) >>> /* No callback queued, wake up any other waiters */ >>> @@ -277,6 +288,7 @@ static __poll_t dma_buf_poll(struct file *file, >>> poll_table *poll) >>> } >>> } >>> +clear_out_event: >>> if (events & EPOLLIN) { >>> struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_in; >>> @@ -289,8 +301,15 @@ static __poll_t dma_buf_poll(struct file >>> *file, poll_table *poll) >>> spin_unlock_irq(&dmabuf->poll.lock); >>> if (events & EPOLLIN) { >>> - /* Paired with fput in dma_buf_poll_cb */ >>> - get_file(dmabuf->file); >>> + /* >>> + * Paired with fput in dma_buf_poll_cb, >>> + * Skip poll for the closed file. >>> + */ >>> + if (!get_file_rcu(&dmabuf->file)) { >>> + events &= ~EPOLLIN; >>> + dcb->active = 0; >>> + goto clear_in_event; >>> + } >>> if (!dma_buf_poll_add_cb(resv, false, dcb)) >>> /* No callback queued, wake up any other waiters */ >>> @@ -300,6 +319,7 @@ static __poll_t dma_buf_poll(struct file *file, >>> poll_table *poll) >>> } >>> } >>> +clear_in_event: >>> dma_resv_unlock(resv); >>> return events; >>> } >> >

1 year, 10 months

2
1
0 0

Re: [PATCH] dma-buf: Do not build debugfs related code when !CONFIG_DEBUG_FS

by Christian König

Am 01.04.24 um 14:39 schrieb Tvrtko Ursulin: > > On 29/03/2024 00:00, T.J. Mercier wrote: >> On Thu, Mar 28, 2024 at 7:53 AM Tvrtko Ursulin <tursulin(a)igalia.com> >> wrote: >>> >>> From: Tvrtko Ursulin <tursulin(a)ursulin.net> >>> >>> There is no point in compiling in the list and mutex operations >>> which are >>> only used from the dma-buf debugfs code, if debugfs is not compiled in. >>> >>> Put the code in questions behind some kconfig guards and so save >>> some text >>> and maybe even a pointer per object at runtime when not enabled. >>> >>> Signed-off-by: Tvrtko Ursulin <tursulin(a)ursulin.net> >> >> Reviewed-by: T.J. Mercier <tjmercier(a)google.com> > > Thanks! > > How would patches to dma-buf be typically landed? Via what tree I > mean? drm-misc-next? That should go through drm-misc-next. And feel free to add Reviewed-by: Christian König <christian.koenig(a)amd.com> as well. Regards, Christian. > > Regards, > > Tvrtko

1 year, 10 months

1
0
0 0

Re: [PATCH] dmabuf: fix dmabuf file poll uaf issue

by Christian König

Am 27.03.24 um 03:29 schrieb Zhiguo Jiang: > The issue is a UAF issue of dmabuf file fd. Throght debugging, we found > that the dmabuf file fd is added to the epoll event listener list, and > when it is released, it is not removed from the epoll list, which leads > to the UAF(Use-After-Free) issue. As far as I can see that's not because of the DMA-buf code, but because you are somehow using this interface incorrectly. When dma_buf_poll() is called it is mandatory for the caller to hold a reference to the file descriptor on which the poll operation is executed. So adding code like "if (!file_count(file))" in the beginning of dma_buf_poll() is certainly broken. My best guess is that you have some unbalanced dma_buf_get()/dma_buf_put() somewhere instead. Regards, Christian. > > The UAF issue can be solved by checking dmabuf file->f_count value and > skipping the poll operation for the closed dmabuf file in the > dma_buf_poll(). We have tested this solved patch multiple times and > have not reproduced the uaf issue. > > crash dump: > list_del corruption, ffffff8a6f143a90->next is LIST_POISON1 > (dead000000000100) > ------------[ cut here ]------------ > kernel BUG at lib/list_debug.c:55! > Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP > pc : __list_del_entry_valid+0x98/0xd4 > lr : __list_del_entry_valid+0x98/0xd4 > sp : ffffffc01d413d00 > x29: ffffffc01d413d00 x28: 00000000000000c0 x27: 0000000000000020 > x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000080007 > x23: ffffff8b22e5dcc0 x22: ffffff88a6be12d0 x21: ffffff8b22e572b0 > x20: ffffff80254ed0a0 x19: ffffff8a6f143a00 x18: ffffffda5efed3c0 > x17: 6165642820314e4f x16: 53494f505f545349 x15: 4c20736920747865 > x14: 6e3e2d3039613334 x13: 2930303130303030 x12: 0000000000000018 > x11: ffffff8b6c188000 x10: 00000000ffffffff x9 : 6c8413a194897b00 > x8 : 6c8413a194897b00 x7 : 74707572726f6320 x6 : 6c65645f7473696c > x5 : ffffff8b6c3b2a3e x4 : ffffff8b6c3b2a40 x3 : ffff103000001005 > x2 : 0000000000000001 x1 : 00000000000000c0 x0 : 000000000000004e > Call trace: > __list_del_entry_valid+0x98/0xd4 > dma_buf_file_release+0x48/0x90 > __fput+0xf4/0x280 > ____fput+0x10/0x20 > task_work_run+0xcc/0xf4 > do_notify_resume+0x2a0/0x33c > el0_svc+0x5c/0xa4 > el0t_64_sync_handler+0x68/0xb4 > el0t_64_sync+0x1a0/0x1a4 > Code: d0006fe0 912c5000 f2fbd5a2 94231a01 (d4210000) > ---[ end trace 0000000000000000 ]--- > Kernel panic - not syncing: Oops - BUG: Fatal exception > SMP: stopping secondary CPUs > > Signed-off-by: Zhiguo Jiang <justinjiang(a)vivo.com> > --- > drivers/dma-buf/dma-buf.c | 28 ++++++++++++++++++++++++---- > 1 file changed, 24 insertions(+), 4 deletions(-) > mode change 100644 => 100755 drivers/dma-buf/dma-buf.c > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 8fe5aa67b167..e469dd9288cc > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -240,6 +240,10 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) > struct dma_resv *resv; > __poll_t events; > > + /* Check if the file exists */ > + if (!file_count(file)) > + return EPOLLERR; > + > dmabuf = file->private_data; > if (!dmabuf || !dmabuf->resv) > return EPOLLERR; > @@ -266,8 +270,15 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) > spin_unlock_irq(&dmabuf->poll.lock); > > if (events & EPOLLOUT) { > - /* Paired with fput in dma_buf_poll_cb */ > - get_file(dmabuf->file); > + /* > + * Paired with fput in dma_buf_poll_cb, > + * Skip poll for the closed file. > + */ > + if (!get_file_rcu(&dmabuf->file)) { > + events &= ~EPOLLOUT; > + dcb->active = 0; > + goto clear_out_event; > + } > > if (!dma_buf_poll_add_cb(resv, true, dcb)) > /* No callback queued, wake up any other waiters */ > @@ -277,6 +288,7 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) > } > } > > +clear_out_event: > if (events & EPOLLIN) { > struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_in; > > @@ -289,8 +301,15 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) > spin_unlock_irq(&dmabuf->poll.lock); > > if (events & EPOLLIN) { > - /* Paired with fput in dma_buf_poll_cb */ > - get_file(dmabuf->file); > + /* > + * Paired with fput in dma_buf_poll_cb, > + * Skip poll for the closed file. > + */ > + if (!get_file_rcu(&dmabuf->file)) { > + events &= ~EPOLLIN; > + dcb->active = 0; > + goto clear_in_event; > + } > > if (!dma_buf_poll_add_cb(resv, false, dcb)) > /* No callback queued, wake up any other waiters */ > @@ -300,6 +319,7 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) > } > } > > +clear_in_event: > dma_resv_unlock(resv); > return events; > }

1 year, 10 months

1
0
0 0

Re: [PATCH net-next v5 1/3] net: ethernet: ti: Add accessors for struct k3_cppi_desc_pool members

by Russell King (Oracle)

On Thu, Mar 28, 2024 at 12:06:56PM +0000, Naveen Mamindlapalli wrote: > > diff --git a/drivers/net/ethernet/ti/k3-cppi-desc-pool.c b/drivers/net/ethernet/ti/k3- > > cppi-desc-pool.c > > index 05cc7aab1ec8..fe8203c05731 100644 > > --- a/drivers/net/ethernet/ti/k3-cppi-desc-pool.c > > +++ b/drivers/net/ethernet/ti/k3-cppi-desc-pool.c > > @@ -132,5 +132,17 @@ size_t k3_cppi_desc_pool_avail(struct > > k3_cppi_desc_pool *pool) } EXPORT_SYMBOL_GPL(k3_cppi_desc_pool_avail); > > > > +size_t k3_cppi_desc_pool_desc_size(struct k3_cppi_desc_pool *pool) { > > + return pool->desc_size; > > Don't you need to add NULL check on pool ptr since this function is exported? What bearing does exporting a function have on whether it should check for NULL? Given that this function returns size_t, it can't return an error number. So what value would it return if "pool" were NULL? It can only return a positive integer or zero. Also, the argument should be const as the function doesn't modify the contents of "pool". -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

1 year, 10 months

1
0
0 0

Re: [PATCH] dmabuf: fix dmabuf file poll uaf issue

by T.J. Mercier

On Tue, Mar 26, 2024 at 7:29 PM Zhiguo Jiang <justinjiang(a)vivo.com> wrote: > > The issue is a UAF issue of dmabuf file fd. Throght debugging, we found > that the dmabuf file fd is added to the epoll event listener list, and > when it is released, it is not removed from the epoll list, which leads > to the UAF(Use-After-Free) issue. > > The UAF issue can be solved by checking dmabuf file->f_count value and > skipping the poll operation for the closed dmabuf file in the > dma_buf_poll(). We have tested this solved patch multiple times and > have not reproduced the uaf issue. > Hi Zhiguo, What is the most recent kernel version you've seen the bug on? You are closing the dmabuf fd from another thread while it is still part of the epoll interest list? Thanks, T.J.

1 year, 10 months

1
0
0 0

Re: [PATCH] dma-buf: Do not build debugfs related code when !CONFIG_DEBUG_FS

by T.J. Mercier

On Thu, Mar 28, 2024 at 7:53 AM Tvrtko Ursulin <tursulin(a)igalia.com> wrote: > > From: Tvrtko Ursulin <tursulin(a)ursulin.net> > > There is no point in compiling in the list and mutex operations which are > only used from the dma-buf debugfs code, if debugfs is not compiled in. > > Put the code in questions behind some kconfig guards and so save some text > and maybe even a pointer per object at runtime when not enabled. > > Signed-off-by: Tvrtko Ursulin <tursulin(a)ursulin.net> Reviewed-by: T.J. Mercier <tjmercier(a)google.com>

1 year, 10 months

1
0
0 0

[PATCH] drm/prime: Unbreak virtgpu dma-buf export

by Rob Clark

From: Rob Clark <robdclark(a)chromium.org> virtgpu "vram" GEM objects do not implement obj->get_sg_table(). But they also don't use drm_gem_map_dma_buf(). In fact they may not even have guest visible pages. But it is perfectly fine to export and share with other virtual devices. Reported-by: Dominik Behr <dbehr(a)chromium.org> Fixes: 207395da5a97 ("drm/prime: reject DMA-BUF attach when get_sg_table is missing") Signed-off-by: Rob Clark <robdclark(a)chromium.org> --- drivers/gpu/drm/drm_prime.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 7352bde299d5..64dd6276e828 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -582,7 +582,12 @@ int drm_gem_map_attach(struct dma_buf *dma_buf, { struct drm_gem_object *obj = dma_buf->priv; - if (!obj->funcs->get_sg_table) + /* + * drm_gem_map_dma_buf() requires obj->get_sg_table(), but drivers + * that implement their own ->map_dma_buf() do not. + */ + if ((dma_buf->ops->map_dma_buf == drm_gem_map_dma_buf) && + !obj->funcs->get_sg_table) return -ENOSYS; return drm_gem_pin(obj); -- 2.44.0

1 year, 10 months

2
4
0 0

Re: [PATCH] drm/prime: Unbreak virtgpu dma-buf export

by Rob Clark

This is actually a bit concerning.. importing a host page backed buffer without guest mapping into a passthru device probably doesn't work and should be rejected earlier. I do think we should relax the restriction (either taking my patch or reverting the commit it fixes) until we work this out properly (because the original patch is a regression), but importing a buffer without guest pages into a passthru device can't possibly work properly. Maybe it works by chance if the host buffer is mapped to the guest, but that is not guaranteed. BR, -R On Mon, Mar 25, 2024 at 3:35 PM Dominik Behr <dbehr(a)chromium.org> wrote: > > It also fixes importing virtgpu blobs into real hardware, for instance amdgpu for DRI_PRIME rendering. > > On Fri, Mar 22, 2024 at 2:48 PM Rob Clark <robdclark(a)gmail.com> wrote: >> >> From: Rob Clark <robdclark(a)chromium.org> >> >> virtgpu "vram" GEM objects do not implement obj->get_sg_table(). But >> they also don't use drm_gem_map_dma_buf(). In fact they may not even >> have guest visible pages. But it is perfectly fine to export and share >> with other virtual devices. >> >> Reported-by: Dominik Behr <dbehr(a)chromium.org> >> Fixes: 207395da5a97 ("drm/prime: reject DMA-BUF attach when get_sg_table is missing") >> Signed-off-by: Rob Clark <robdclark(a)chromium.org> >> --- >> drivers/gpu/drm/drm_prime.c | 7 ++++++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c >> index 7352bde299d5..64dd6276e828 100644 >> --- a/drivers/gpu/drm/drm_prime.c >> +++ b/drivers/gpu/drm/drm_prime.c >> @@ -582,7 +582,12 @@ int drm_gem_map_attach(struct dma_buf *dma_buf, >> { >> struct drm_gem_object *obj = dma_buf->priv; >> >> - if (!obj->funcs->get_sg_table) >> + /* >> + * drm_gem_map_dma_buf() requires obj->get_sg_table(), but drivers >> + * that implement their own ->map_dma_buf() do not. >> + */ >> + if ((dma_buf->ops->map_dma_buf == drm_gem_map_dma_buf) && >> + !obj->funcs->get_sg_table) >> return -ENOSYS; >> >> return drm_gem_pin(obj); >> -- >> 2.44.0 >>

1 year, 10 months

1
0
0 0

Re: [PATCH v4 03/14] drm/mediatek: Rename "mtk_drm_plane" to "mtk_plane"

by AngeloGioacchino Del Regno

Il 22/03/24 02:27, Shawn Sung ha scritto: > From: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> > > Rename all "mtk_drm_plane" to "mtk_plane": > - To align the naming rule > - To reduce the code size > > Reviewed-by: AngeloGiaocchino Del Regno <angelogioacchino.delregno(a)collabora.com> Shawn - please - can you fix my typo'ed name also here and on all of the patches of this series? Thanks. > Reviewed-by: CK Hu <ck.hu(a)mediatek.com> > Signed-off-by: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> > --- > drivers/gpu/drm/mediatek/mtk_drm_plane.c | 6 +++--- > drivers/gpu/drm/mediatek/mtk_drm_plane.h | 4 ++-- > 2 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c > index cbdb70677d305..43137c46fc148 100644 > --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c > +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c > @@ -93,8 +93,8 @@ static bool mtk_plane_format_mod_supported(struct drm_plane *plane, > return true; > } > > -static void mtk_drm_plane_destroy_state(struct drm_plane *plane, > - struct drm_plane_state *state) > +static void mtk_plane_destroy_state(struct drm_plane *plane, > + struct drm_plane_state *state) > { > __drm_atomic_helper_plane_destroy_state(state); > kfree(to_mtk_plane_state(state)); > @@ -241,7 +241,7 @@ static const struct drm_plane_funcs mtk_plane_funcs = { > .destroy = drm_plane_cleanup, > .reset = mtk_plane_reset, > .atomic_duplicate_state = mtk_plane_duplicate_state, > - .atomic_destroy_state = mtk_drm_plane_destroy_state, > + .atomic_destroy_state = mtk_plane_destroy_state, > .format_mod_supported = mtk_plane_format_mod_supported, > }; > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.h b/drivers/gpu/drm/mediatek/mtk_drm_plane.h > index 99aff7da0831d..231bb7aac9473 100644 > --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.h > +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.h > @@ -4,8 +4,8 @@ > * Author: CK Hu <ck.hu(a)mediatek.com> > */ > > -#ifndef _MTK_DRM_PLANE_H_ > -#define _MTK_DRM_PLANE_H_ > +#ifndef _MTK_PLANE_H_ > +#define _MTK_PLANE_H_ > > #include <drm/drm_crtc.h> > #include <linux/types.h>

1 year, 10 months

1
0
0 0

Re: [PATCH v3 09/14] drm/mediatek: Rename files "mtk_drm_ddp_comp.c" to "mtk_ddp_comp.c"

by AngeloGioacchino Del Regno

Il 20/03/24 03:42, Shawn Sung ha scritto: > From: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> > > Rename files mtk_drm_ddp_comp.c to mtk_ddp_comp.c and > modify the Makefile accordingly. > > Reviewed-by: CK Hu <ck.hu(a)mediatek.com> > Signed-off-by: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com>

1 year, 11 months

1
0
0 0

Re: [PATCH v3 07/14] drm/mediatek: Rename files "mtk_drm_crtc.c" to "mtk_crtc.c"

by AngeloGioacchino Del Regno

Il 20/03/24 03:42, Shawn Sung ha scritto: > From: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> > > Rename files mtk_drm_crtc.c to mtk_crtc.c and > modify the Makefile accordingly. > > Reviewed-by: CK Hu <ck.hu(a)mediatek.com> > Signed-off-by: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com>

1 year, 11 months

1
0
0 0

[PATCH] dma-buf: Fix NULL pointer dereference in sanitycheck()

by Pavel Sakharov

If due to a memory allocation failure mock_chain() returns NULL, it is passed to dma_fence_enable_sw_signaling() resulting in NULL pointer dereference there. Call dma_fence_enable_sw_signaling() only if mock_chain() succeeds. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: d62c43a953ce ("dma-buf: Enable signaling on fence for selftests") Signed-off-by: Pavel Sakharov <p.sakharov(a)ispras.ru> --- drivers/dma-buf/st-dma-fence-chain.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/st-dma-fence-chain.c b/drivers/dma-buf/st-dma-fence-chain.c index 9c2a0c082a76..ed4b323886e4 100644 --- a/drivers/dma-buf/st-dma-fence-chain.c +++ b/drivers/dma-buf/st-dma-fence-chain.c @@ -84,11 +84,11 @@ static int sanitycheck(void *arg) return -ENOMEM; chain = mock_chain(NULL, f, 1); - if (!chain) + if (chain) + dma_fence_enable_sw_signaling(chain); + else err = -ENOMEM; - dma_fence_enable_sw_signaling(chain); - dma_fence_signal(f); dma_fence_put(f); -- 2.44.0

1 year, 11 months

2
1
0 0

Re: [PATCH v2 02/14] drm/mediatek: Rename "mtk_drm_ddp_comp" to "mtk_ddp_comp"

by AngeloGioacchino Del Regno

Il 19/03/24 08:02, Shawn Sung ha scritto: > From: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> > > Rename all "mtk_drm_ddp_comp" to "mtk_ddp_comp": > - To align the naming rule > - To reduce the code size > > Reviewed-by: AngeloGiaocchino Del Regno <angelogioacchino.delregno(a)collabora.com> Shawn, I don't know if I typoed my own name (which is actually possible, since I write the tags by hand), or what actually happened to my Reviewed-by tags on the entire series. Can you please fix the typo in the tag? Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> Use this one, please. Thanks, Angelo > Reviewed-by: CK Hu <ck.hu(a)mediatek.com> > Signed-off-by: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com>

1 year, 11 months

1
0
0 0

Re: [PATCH v2 11/14] drm/mediatek: Rename files "mtk_drm_plane.c" to "mtk_plane.c"

by AngeloGioacchino Del Regno

Il 19/03/24 08:02, Shawn Sung ha scritto: > From: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> > > Rename files mtk_drm_plane.c to mtk_plane.c and > modify the Makefile accordingly. > > Signed-off-by: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com>

1 year, 11 months

1
0
0 0

Re: [PATCH 12/18] ASoC: codecs: mt6357: add MT6357 codec

by Mark Brown

On Fri, Mar 15, 2024 at 06:36:19PM +0100, Alexandre Mergnat wrote: > On 15/03/2024 16:15, Mark Brown wrote: > > On Fri, Mar 15, 2024 at 04:05:21PM +0100, Alexandre Mergnat wrote: > > > > In the register. You only need to reset the gain to -40dB at the start > > > > of the ramp. > > > Sorry but I don't understand your logic, I'm not able to implement it... > > > If I'm at -10dB and doing a ramp to reach -40dB, next time I will read the > > > register the value will be -40dB. > > After we've done the ramp and turned the amplifier off we can just > > restore the desired value? The hardware is not going to care what the > > volume is while it's not enabled. > If you do that, HP will be enabled at the saved gain, and after that you > will do the ramp. To avoid pop, the driver should be rewrite to: So reset the volume to -40dB prior to turning the amplifier on... > Read gain in the reg and save it locally > Set -40dB in the reg > Enable HP > Do ramp ...as you yourself suggest? > > > AFAII from the comment in the code, it's done to avoid the "pop noises". > > Yes, that's the usual reason to ramp gains. Though if you've just > > copied the code without checking that it's needed it's possible that > > this is something that's been fixed in current hardware. > I did the test at 24dB with and without the "pop filter". Isn't big but I > ear the pop at the start of the record without the "pop filter". OK, it probably is still doing something then. > To be clear, the algo/behavior of this code is an implementation based on > the 6k+ lines downstream code for this specific audio codec. But the > shape/style is based on upstreamed drivers like mt6358.c. The Mediatek code has a bunch of issues, I wouldn't read too much into something being present in the code.

1 year, 11 months

1
0
0 0

Re: [PATCH 12/18] ASoC: codecs: mt6357: add MT6357 codec

by Mark Brown

On Fri, Mar 15, 2024 at 04:05:21PM +0100, Alexandre Mergnat wrote: > On 15/03/2024 15:30, Mark Brown wrote: > > > Let me know, when you change de gain to do a ramp down (start from user gain > > > to gain=-40db), next time for the ramp up, how/where do you find the user > > > gain ? > > In the register. You only need to reset the gain to -40dB at the start > > of the ramp. > Sorry but I don't understand your logic, I'm not able to implement it... > If I'm at -10dB and doing a ramp to reach -40dB, next time I will read the > register the value will be -40dB. After we've done the ramp and turned the amplifier off we can just restore the desired value? The hardware is not going to care what the volume is while it's not enabled. > This implementation is also done in other MTK audio codec drivers. Perhaps they should be updated too? > > > When microphone isn't capturing, the gain read back from the register is > > > 0dB. I've put some logs in my code and do capture to show how it works: > > Is this a property of the hardware or a property of your driver? > At the end of the capture, the gain is set to 0dB by the driver. > At the start of the capture, the gain is set to the setup gain. So that's a property of the driver then? > AFAII from the comment in the code, it's done to avoid the "pop noises". Yes, that's the usual reason to ramp gains. Though if you've just copied the code without checking that it's needed it's possible that this is something that's been fixed in current hardware.

1 year, 11 months

1
0
0 0

Re: [PATCH 00/18] Add audio support for the MediaTek Genio 350-evk board

by Mark Brown

On Tue, Mar 12, 2024 at 09:58:05AM +0100, Alexandre Mergnat wrote: > I'm a bit lost for mixer-test and pcm-test. > Currently, I cross-compile the alsa lib project to be able to build the > tests and put it on my board. > I can execute it, but I still have 2 issues: > 1) I've a lot of missing module in my environment (Encode.so, Encode.pm, > Symbol.pm, IO/Handle.pm, ...). AFAII, I've to cross compile the missing perl > modules and install them in the rootfs These tests are both simple C programs... > 2) I don't know how to configure pcm-test.conf & > Lenovo_ThinkPad_P1_Gen2.conf (or new file to match with my board). The configuration is optional. > My test cmd: > ./run_kselftest.sh -c alsa Just run the programs directly. I'm only asking for the output from two of them anyway.

1 year, 11 months

1
0
0 0

Re: [PATCH 12/18] ASoC: codecs: mt6357: add MT6357 codec

by Mark Brown

On Fri, Mar 15, 2024 at 12:01:12PM +0100, Alexandre Mergnat wrote: > On 13/03/2024 18:23, Mark Brown wrote: > > On Tue, Mar 12, 2024 at 07:03:25PM +0100, Alexandre Mergnat wrote: > > > Actually you must save the values because the gain selected by the user will > > > be override to do a ramp => volume_ramp(.....): > > > - When you switch on the HP, you start from gain=-40db to final_gain > > > (selected by user). > > > - When you switch off the HP, you start from final_gain (selected by user) > > > to gain=-40db. > > You can just read the value back when you need to do a ramp? > You can't. Because you will read -40db when HP isn't playing sound. That is > why the gain is saved into the struct. > Let me know, when you change de gain to do a ramp down (start from user gain > to gain=-40db), next time for the ramp up, how/where do you find the user > gain ? In the register. You only need to reset the gain to -40dB at the start of the ramp. > > > Also, the microphone's gain change when it's enabled/disabled. > > I don't understand what this means? > When microphone isn't capturing, the gain read back from the register is > 0dB. I've put some logs in my code and do capture to show how it works: Is this a property of the hardware or a property of your driver? > > > > > + /* ul channel swap */ > > > > > + SOC_SINGLE("UL LR Swap", MT6357_AFE_UL_DL_CON0, AFE_UL_LR_SWAP_SFT, 1, 0), > > > > On/off controls should end in Switch. > > > Sorry, I don't understand your comment. Can you reword it please ? > > See control-names.rst. Run mixer-test on a card with this driver and > > fix all the issues it reports. > Ok the name is the issue for you AFAII. > This control isn't for on/off but swap Left and Right. > From the codec documentation: > "Swaps audio UL L/R channel before UL SRC" > This control is overkill, I will remove it This is turning the swapping on and off.

1 year, 11 months

1
0
0 0

Re: [PATCH 12/18] ASoC: codecs: mt6357: add MT6357 codec

by Mark Brown

On Wed, Mar 13, 2024 at 06:11:50PM +0100, Alexandre Mergnat wrote: > On 26/02/2024 17:09, Mark Brown wrote: > > > index 000000000000..13e95c227114 > > > --- /dev/null > > > +++ b/sound/soc/codecs/mt6357.c > > > @@ -0,0 +1,1805 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > > +/* > > > + * MT6357 ALSA SoC audio codec driver > > Please use a C++ comment for the whole comment to make it clearer that > > this is intentional. > If I do that, the checkpatch raise a warning: > WARNING: Improper SPDX comment style for > 'sound/soc/mediatek/mt8365/mt8365-afe-clk.c', please use '//' instead > #22: FILE: sound/soc/mediatek/mt8365/mt8365-afe-clk.c:1: > +/* SPDX-License-Identifier: GPL-2.0 That's not a C++ comment so checkpatch is correctly warning?

1 year, 11 months

1
0
0 0

Re: [PATCH 12/18] ASoC: codecs: mt6357: add MT6357 codec

by Mark Brown

On Tue, Mar 12, 2024 at 07:03:25PM +0100, Alexandre Mergnat wrote: > On 26/02/2024 17:09, Mark Brown wrote: > > > + case MT6357_ZCD_CON2: > > > + regmap_read(priv->regmap, MT6357_ZCD_CON2, &reg); > > > + priv->ana_gain[ANALOG_VOLUME_HPOUTL] = > > > + (reg & AUD_HPL_GAIN_MASK) >> AUD_HPL_GAIN_SFT; > > > + priv->ana_gain[ANALOG_VOLUME_HPOUTR] = > > > + (reg & AUD_HPR_GAIN_MASK) >> AUD_HPR_GAIN_SFT; > > > + break; > > It would probably be less code and would definitely be clearer and > > simpler to just read the values when we need them rather than constatly > > keeping a cache separate to the register cache. > Actually you must save the values because the gain selected by the user will > be override to do a ramp => volume_ramp(.....): > - When you switch on the HP, you start from gain=-40db to final_gain > (selected by user). > - When you switch off the HP, you start from final_gain (selected by user) > to gain=-40db. You can just read the value back when you need to do a ramp? > Also, the microphone's gain change when it's enabled/disabled. I don't understand what this means? > > > + /* ul channel swap */ > > > + SOC_SINGLE("UL LR Swap", MT6357_AFE_UL_DL_CON0, AFE_UL_LR_SWAP_SFT, 1, 0), > > On/off controls should end in Switch. > Sorry, I don't understand your comment. Can you reword it please ? See control-names.rst. Run mixer-test on a card with this driver and fix all the issues it reports. > > > +static int hslo_mux_map_value[] = { > > > + 0x0, 0x1, 0x2, 0x3, > > > +}; > > Why not just use a normal mux here, there's no missing values or > > reordering? Similarly for other muxes. > I've dug into some other codecs and it's done like that, but I've probably > misunderstood something. > The only bad thing I see is enum is missing currently: > > enum { > PGA_MUX_OPEN = 0, > PGA_MUX_DACR, > PGA_MUX_PB, > PGA_MUX_TM, > PGA_MUX_MASK = 0x3, > }; The whole thing with explicitly specfying the mapping is just completely redundant, you may as well remove it.

1 year, 11 months

1
0
0 0

[PATCH] drm/shmem-helper: Remove duplicate include

by Jiapeng Chong

./drivers/gpu/drm/drm_gem_shmem_helper.c: linux/module.h is included more than once. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4567 Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- drivers/gpu/drm/drm_gem_shmem_helper.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c index 4ea6507a77e5..f401df26facf 100644 --- a/drivers/gpu/drm/drm_gem_shmem_helper.c +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c @@ -10,7 +10,6 @@ #include <linux/shmem_fs.h> #include <linux/slab.h> #include <linux/vmalloc.h> -#include <linux/module.h> #ifdef CONFIG_X86 #include <asm/set_memory.h> -- 2.20.1.7.g153144c

1 year, 11 months

2
2
0 0

Re: [PATCH 12/18] ASoC: codecs: mt6357: add MT6357 codec

by AngeloGioacchino Del Regno

Il 12/03/24 15:50, Alexandre Mergnat ha scritto: > > > On 26/02/2024 16:25, AngeloGioacchino Del Regno wrote: >>> + if (enable) { >>> + /* set gpio mosi mode */ >>> + regmap_write(priv->regmap, MT6357_GPIO_MODE2_CLR, GPIO_MODE2_CLEAR_ALL); >>> + regmap_write(priv->regmap, MT6357_GPIO_MODE2_SET, >>> GPIO8_MODE_SET_AUD_CLK_MOSI | >>> + GPIO9_MODE_SET_AUD_DAT_MOSI0 | >>> + GPIO10_MODE_SET_AUD_DAT_MOSI1 | >>> + GPIO11_MODE_SET_AUD_SYNC_MOSI); >> >> Are you sure that you need to write to MODE2_SET *and* to MODE2?! > > This is downstream code and these registers aren't in my documentation. > I've removed the MODE2_SET write and test the audio: it's still working. > > So I will keep the spurious write removed for v2. :) > Usually, MediaTek registers are laid out like "REG" being R/legacy-W and "REG_SET/CLR" for setting and clearing bits in "REG" internally, and that might account for internal latencies and such. Can you please try to remove the MODE2 write instead of the MODE2_SET one and check if that works? You're already using the SETCLR way when manipulating registers in here, so I would confidently expect that to work. Cheers, Angelo

1 year, 11 months

1
0
0 0

[PATCH v8 0/6] iio: new DMABUF based API

by Paul Cercueil

Hi Jonathan, Here's the final(tm) version of the IIO DMABUF patchset. This v8 fixes the remaining few issues that Christian reported. I also updated the documentation patch as there has been changes to index.rst. This was based on next-20240308. Changelog: - [3/6]: - Fix swapped fence direction - Simplify fence wait mechanism - Remove "Buffer closed with active transfers" print, as it was dead code - Un-export iio_buffer_dmabuf_{get,put}. They are not used anywhere else so they can even be static. - Prevent attaching already-attached DMABUFs - [6/6]: Renamed dmabuf_api.rst -> iio_dmabuf_api.rst, and updated index.rst whose format changed in iio/togreg. Cheers, -Paul Paul Cercueil (6): dmaengine: Add API function dmaengine_prep_peripheral_dma_vec() dmaengine: dma-axi-dmac: Implement device_prep_peripheral_dma_vec iio: core: Add new DMABUF interface infrastructure iio: buffer-dma: Enable support for DMABUFs iio: buffer-dmaengine: Support new DMABUF based userspace API Documentation: iio: Document high-speed DMABUF based API Documentation/iio/iio_dmabuf_api.rst | 54 ++ Documentation/iio/index.rst | 1 + drivers/dma/dma-axi-dmac.c | 40 ++ drivers/iio/buffer/industrialio-buffer-dma.c | 181 ++++++- .../buffer/industrialio-buffer-dmaengine.c | 59 ++- drivers/iio/industrialio-buffer.c | 462 ++++++++++++++++++ include/linux/dmaengine.h | 27 + include/linux/iio/buffer-dma.h | 31 ++ include/linux/iio/buffer_impl.h | 30 ++ include/uapi/linux/iio/buffer.h | 22 + 10 files changed, 890 insertions(+), 17 deletions(-) create mode 100644 Documentation/iio/iio_dmabuf_api.rst -- 2.43.0

1 year, 11 months

3
10
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig