* Re: [PATCH 1/5] media: i2c: vd55g1: Fix media bus code initialization
From: Benjamin Mugnier @ 2026-06-25 11:41 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Sylvain Petinot, Sakari Ailus, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans Verkuil, linux-media,
linux-kernel, devicetree
In-Reply-To: <ajj90hhNwx7bLkOZ@zed>
Hi Jacopo,
Thank you for your review.
Le 22/06/2026 à 11:28, Jacopo Mondi a écrit :
> Hi Benjamin
>
> On Tue, Apr 28, 2026 at 10:40:55AM +0200, Benjamin Mugnier wrote:
>> In the driver initialization, the index of the default media bus code
>> from the supported media bus code array is passed directly to the
>> vd55g1_get_fmt_code() function instead of the proper media bus code.
>>
>> This works correctly as a proper media bus code is set after
>> initialization but could not have been the case. This also resulted in
>> mutliple "Unsupported mbus format" error messages.
>>
>> Retrieve the media bus code from the media bus code array, and pass this
>> media bus code to vd55g1_get_fmt_code() instead of the code index.
>>
>> Rename VD55G1_MBUS_CODE_DEF to VD55G1_MBUS_CODE_IDX_DEF and
>> VD55G1_MODE_DEF to VD55G1_MODE_IDX_DEF while at it to avoid future
>> confusions. Display the guilty error code in warning message.
>>
>> Fixes: e138e7f00042 ("media: i2c: vd55g1: Add support for vd65g4 RGB variant")
>>
> You should cc stable for fixes
>
> Cc: stable@vger.kernel.org
>
We talked about this very recently and somehow I still forgot.
>
> The CI should have flagged that, but for some reason it didn't run
> properly on your series
> https://gitlab.freedesktop.org/linux-media/users/patchwork/-/pipelines/1655147
>
>> Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
>> ---
>> drivers/media/i2c/vd55g1.c | 17 +++++++++++------
>> 1 file changed, 11 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/media/i2c/vd55g1.c b/drivers/media/i2c/vd55g1.c
>> index 78d18c028154..1e9db21322e3 100644
>> --- a/drivers/media/i2c/vd55g1.c
>> +++ b/drivers/media/i2c/vd55g1.c
>> @@ -114,9 +114,9 @@
>>
>> #define VD55G1_WIDTH 804
>> #define VD55G1_HEIGHT 704
>> -#define VD55G1_MODE_DEF 0
>> +#define VD55G1_MODE_IDX_DEF 0
>> #define VD55G1_NB_GPIOS 4
>> -#define VD55G1_MBUS_CODE_DEF 0
>> +#define VD55G1_MBUS_CODE_IDX_DEF 0
>> #define VD55G1_DGAIN_DEF 256
>> #define VD55G1_AGAIN_DEF 19
>> #define VD55G1_EXPO_MAX_TERM 64
>> @@ -634,7 +634,7 @@ static u32 vd55g1_get_fmt_code(struct vd55g1 *sensor, u32 code)
>
> Unrelated, but it seems you now have 2 codes for MONO. Does
>
> if (sensor->id == VD55G1_MODEL_ID_VD55G1)
> return code;
>
> need an update ?>
Not in this patch because it does not add the new MONO sensor, but in
4/5 I separated the model ID from the color code. Example for the vd55g4 :
.name = "vd55g4",
.id = VD55G1_MODEL_ID_3,
.color = VD55G1_COLOR_VERSION_MONO,
So the patch 4/5 updates the previous 'if' you mentioned to check the
color member instead of the model :
if (sensor->version->color != VD55G1_COLOR_VERSION_BAYER)
Which IMO is a good way to handle this problematic. Tell me if you're
thinking about something else.
>> goto adapt_bayer_pattern;
>> }
>> }
>> - dev_warn(sensor->dev, "Unsupported mbus format\n");
>> + dev_warn(sensor->dev, "Unsupported mbus format: 0x%x\n", code);
>>
>> return code;
>>
>> @@ -1347,6 +1347,7 @@ static int vd55g1_init_state(struct v4l2_subdev *sd,
>> {
>> struct vd55g1 *sensor = to_vd55g1(sd);
>> struct v4l2_subdev_format fmt = { 0 };
>> + int code;
>> struct v4l2_subdev_route routes[] = {
>> { .flags = V4L2_SUBDEV_ROUTE_FL_ACTIVE }
>> };
>> @@ -1361,9 +1362,13 @@ static int vd55g1_init_state(struct v4l2_subdev *sd,
>> if (ret)
>> return ret;
>>
>> - vd55g1_update_pad_fmt(sensor, &vd55g1_supported_modes[VD55G1_MODE_DEF],
>> - vd55g1_get_fmt_code(sensor, VD55G1_MBUS_CODE_DEF),
>> - &fmt.format);
>> + if (sensor->id == VD55G1_MODEL_ID_VD55G1)
>> + code = vd55g1_mbus_formats_mono[VD55G1_MBUS_CODE_IDX_DEF];
>> + else
>> + code = vd55g1_mbus_formats_bayer[VD55G1_MBUS_CODE_IDX_DEF][0];
>
> Being this a multi-dimensional array, I don't seem much value in
> defining VD55G1_MBUS_CODE_IDX_DEF if this is the only place where it
> is used. What's the meaning of VD55G1_MBUS_CODE_IDX_DEF for
> vd55g1_mbus_formats_bayer ? Does it represent the bitwidth or does it
> represent the bayer pattern ?
For vd55g1_mbus_formats_bayer, the first dimension of the array is the
bitwidth, and the second one is the bayer pattern.
>
> I would rather define a
> VD55G1_DEF_MBUS_CODE_MONO MEDIA_BUS_FMT_Y8_1X8
> VD55G1_DEF_MBUS_CODE_BAYER MEDIA_BUS_FMT_SRGGB8_1X8
>
> Or maybe do
>
> code = vd55g1_mbus_formats_bayer[VD55G1_MBUS_CODE_IDX_DEF]
> [VD55G1_MBUS_CODE_IDX_DEF];
>
> if easier.
>
> I understand it's a minor, so up to you.
As you mentioned it's only used here. I won't mind removing
VD55G1_MBUS_CODE_IDX_DEF entirely and do :
code = vd55g1_mbus_formats_bayer[0][0];
Does that sound okay ?
>
>
>
>> + vd55g1_update_pad_fmt(sensor,
>> + &vd55g1_supported_modes[VD55G1_MODE_IDX_DEF],
>> + vd55g1_get_fmt_code(sensor, code), &fmt.format);
>>
>> return vd55g1_set_pad_fmt(sd, sd_state, &fmt);
>> }
>>
>> --
>> 2.43.0
>>
>>
--
Regards,
Benjamin
^ permalink raw reply
* Re: [PATCH 2/5] media: i2c: vd55g1: Remove spurious pad format update on init_state()
From: Benjamin Mugnier @ 2026-06-25 11:41 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Sylvain Petinot, Sakari Ailus, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans Verkuil, linux-media,
linux-kernel, devicetree
In-Reply-To: <ajkAdol1szOK_XPB@zed>
Hi Jacopo,
Le 22/06/2026 à 11:30, Jacopo Mondi a écrit :
> Hi Benjamin
>
> On Tue, Apr 28, 2026 at 10:40:56AM +0200, Benjamin Mugnier wrote:
>> vd55g1_update_pad_fmt() is called in vd55g1_init_state(). But
>> vd55g1_set_pad_fmt(), called at the end of vd55g1_init_state(), also
>> calls vd55g1_update_pad_fmt() itself.
>>
>> Enhance readability and clear confusion by only preparing the format in
>> vd55g1_init_state() and let vd55g1_set_pad_fmt() update it instead,
>> effectively calling it only 1 time instead of 2.
>>
>> Fixes: e138e7f00042 ("media: i2c: vd55g1: Add support for vd65g4 RGB variant")
>
> Does this qualify as a fix ?
That's a good question, indeed this patch does not correct any 'bug' per
se. It's more of a code flow error so I think you're correct. I'm fine
with removing the 'Fixes:' tag.
>
> I think you could maybe squash it with the previous one if you want
> also this change to be backported as part of a larger fix
>
I don't know, this patch solves another issue than the previous patch
does. I'd like to keep it this in the git history if you don't mind.
>>
>> Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
>
> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
>
> Thanks
> j
>
>> ---
>> drivers/media/i2c/vd55g1.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/media/i2c/vd55g1.c b/drivers/media/i2c/vd55g1.c
>> index 1e9db21322e3..e44174056ace 100644
>> --- a/drivers/media/i2c/vd55g1.c
>> +++ b/drivers/media/i2c/vd55g1.c
>> @@ -1366,9 +1366,9 @@ static int vd55g1_init_state(struct v4l2_subdev *sd,
>> code = vd55g1_mbus_formats_mono[VD55G1_MBUS_CODE_IDX_DEF];
>> else
>> code = vd55g1_mbus_formats_bayer[VD55G1_MBUS_CODE_IDX_DEF][0];
>> - vd55g1_update_pad_fmt(sensor,
>> - &vd55g1_supported_modes[VD55G1_MODE_IDX_DEF],
>> - vd55g1_get_fmt_code(sensor, code), &fmt.format);
>> + fmt.format.code = vd55g1_get_fmt_code(sensor, code);
>> + fmt.format.width = vd55g1_supported_modes[VD55G1_MODE_IDX_DEF].width;
>> + fmt.format.height = vd55g1_supported_modes[VD55G1_MODE_IDX_DEF].height;
>>
>> return vd55g1_set_pad_fmt(sd, sd_state, &fmt);
>> }
>>
>> --
>> 2.43.0
>>
>>
--
Regards,
Benjamin
^ permalink raw reply
* Re: [PATCH v3] media: dvb-core: fix use-after-free in dvb_frontend_open()
From: Zhou, Yun @ 2026-06-25 11:24 UTC (permalink / raw)
To: mchehab, kees, linma; +Cc: linux-media, linux-kernel, yun.zhou
In-Reply-To: <20260610083055.3976083-1-yun.zhou@windriver.com>
Friendly ping
On 6/10/26 16:30, Yun Zhou wrote:
> dvb_frontend_open() calls dvb_generic_release() in its error path after
> dvb_generic_open() succeeds. dvb_generic_release() drops the device
> reference via dvb_device_put(), and then dvb_device_open() drops it again
> in its error handling, causing a use-after-free and refcount underflow.
>
> Fix this by incrementing the refcount before dvb_generic_release() in the
> error path, so that the put inside dvb_generic_release() is balanced and
> dvb_device_open() remains the sole effective put on open failure.
>
> Reported-by: syzbot+40339ea82afa8184ad5d@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=40339ea82afa8184ad5d
> Cc: stable@vger.kernel.org
> Fixes: 0fc044b2b5e2 ("media: dvbdev: adopts refcnt to avoid UAF")
> Signed-off-by: Yun Zhou <yun.zhou@windriver.com>
> ---
> v3:
> - Simplify fix: increment refcount before dvb_generic_release() instead
> of introducing __dvb_generic_release()
>
> v2:
> - Fix Fixes tag commit title
> - Add Closes: link after Reported-by
> - Cc stable@vger.kernel.org
>
> drivers/media/dvb-core/dvb_frontend.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/media/dvb-core/dvb_frontend.c b/drivers/media/dvb-core/dvb_frontend.c
> index d082b6c57c76..608525d08277 100644
> --- a/drivers/media/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb-core/dvb_frontend.c
> @@ -2887,6 +2887,7 @@ static int dvb_frontend_open(struct inode *inode, struct file *file)
> mutex_unlock(&fe->dvb->mdev_lock);
> err2:
> #endif
> + dvb_device_get(dvbdev);
> dvb_generic_release(inode, file);
> err1:
> if (dvbdev->users == -1 && fe->ops.ts_bus_ctrl)
^ permalink raw reply
* Re: [PATCH 2/2] media: rzg2l-cru: Align bytesperline to hardware DMA stride requirement
From: Tommaso Merciai @ 2026-06-25 11:01 UTC (permalink / raw)
To: Laurent Pinchart
Cc: tomm.merciai, linux-renesas-soc, biju.das.jz, jacopo.mondi,
Lad Prabhakar, Mauro Carvalho Chehab, Hans Verkuil,
Nicolas Dufresne, Sakari Ailus, Sven Püschel, Mehdi Djait,
Paul Cercueil, Isaac Scott, Daniel Scally, linux-media,
linux-kernel
In-Reply-To: <20260624195334.GI851255@killaraus.ideasonboard.com>
Hi Laurent,
Thanks for your review.
On Wed, Jun 24, 2026 at 10:53:34PM +0300, Laurent Pinchart wrote:
> On Wed, Jun 24, 2026 at 12:41:31PM +0200, Tommaso Merciai wrote:
> > The RZ/G3E CRU programs the line stride via the AMnIS register, whose
> > IS field encodes the value in units of 128 bytes. If bytesperline is
> > not a multiple of 128, the division truncates and the hardware uses a
> > wrong stride, causing horizontal banding.
> >
> > commit ace92ccef0c9 ("media: platform: rzg2l-cru: Use v4l2_fill_pixfmt()")
>
> s/commit/Commit/
thanks.
>
> > replaced the open-coded aligned calculation with v4l2_fill_pixfmt(),
> > which sets no alignment, reintroducing the issue.
>
> I wonder how I missed that. Sorry.
>
> > Switch to v4l2_fill_pixfmt_aligned() with RZG2L_CRU_STRIDE_ALIGN when
> > info->has_stride is set. RZ/G2L has no AMnIS register and keeps using
> > v4l2_fill_pixfmt() unchanged.
> >
> > Fixes: ace92ccef0c9 ("media: platform: rzg2l-cru: Use v4l2_fill_pixfmt()")
> > Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> > ---
> > drivers/media/platform/renesas/rzg2l-cru/rzg2l-video.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/platform/renesas/rzg2l-cru/rzg2l-video.c b/drivers/media/platform/renesas/rzg2l-cru/rzg2l-video.c
> > index 69346a585f9f..478264f26466 100644
> > --- a/drivers/media/platform/renesas/rzg2l-cru/rzg2l-video.c
> > +++ b/drivers/media/platform/renesas/rzg2l-cru/rzg2l-video.c
> > @@ -860,7 +860,8 @@ static void rzg2l_cru_format_align(struct rzg2l_cru_dev *cru,
> > v4l_bound_align_image(&pix->width, 320, info->max_width, 1,
> > &pix->height, 240, info->max_height, 0, 0);
> >
> > - v4l2_fill_pixfmt(pix, pix->pixelformat, pix->width, pix->height);
> > + v4l2_fill_pixfmt_aligned(pix, pix->pixelformat, pix->width, pix->height,
> > + info->has_stride ? RZG2L_CRU_STRIDE_ALIGN : 1);
>
> The documentation states that, for RGB888, the stride has to be a
> multiple of 384 (3*128). Shouldn't you take that into account here ?
>
> Also, for semi-planar YUV 4:2:0, the hardware seems to use a stride
> equal to AMnIS*2, which leaves blank lines after every U/V line. That's
> something userspace doesn't expect.
Correct.
Currently neither RGB888 nor semi-planar YUV 4:2:0 are supported.
I will handle this once the support for those formats will be added
if for you is ok.
Please let me know.
Thanks.
Kind Regards,
Tommaso
>
> >
> > dev_dbg(cru->dev, "Format %ux%u bpl: %u size: %u\n",
> > pix->width, pix->height, pix->bytesperline, pix->sizeimage);
>
> --
> Regards,
>
> Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] udmabuf: serialize the sg_table cache under the reservation lock
From: Christian König @ 2026-06-25 10:48 UTC (permalink / raw)
To: hexlabsecurity, Gerd Hoffmann, Vivek Kasireddy, Sumit Semwal
Cc: Gurchetan Singh, linux-media, linux-kernel, linaro-mm-sig,
dri-devel
In-Reply-To: <20260625-b4-disp-67d1f3db-v1-1-a47fb9edab9e@proton.me>
On 6/25/26 08:10, Bryam Vargas via B4 Relay wrote:
> From: Bryam Vargas <hexlabsecurity@proton.me>
>
> begin_cpu_udmabuf() builds and caches ubuf->sg with an unserialised
> check-then-set, and end_cpu_udmabuf() reads the same field unlocked. The
> core invokes both cpu-access hooks without holding the reservation lock and
> DMA_BUF_IOCTL_SYNC is unlocked, so concurrent SYNC ioctls on a shared
> udmabuf fd race on ubuf->sg: two begins can both observe NULL and both call
> get_sg_table(), and the later store orphans the earlier table and its DMA
> mapping, which release_udmabuf() never frees. Each won race permanently
> leaks an sg_table and an unbalanced DMA mapping.
>
> Serialize both hooks under the buffer's reservation lock, as panfrost and
> panthor do. dma_buf_begin/end_cpu_access() already annotate might_lock() on
> that lock, so taking it here matches the documented contract.
> Single-threaded callers are unaffected.
>
> Fixes: 284562e1f348 ("udmabuf: implement begin_cpu_access/end_cpu_access hooks")
> Cc: stable@vger.kernel.org
> Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
> ---
> Same leak-with-dangling-pointer class as CVE-2024-56712 (export_udmabuf()
> error path) -- a distinct site the 2024 fix does not cover.
>
> udmabuf is the only exporter that lazily builds its sg_table cache inside the
> cpu-access hook without serialising the check-then-set. The exporters that do
> comparable in-hook cache work all take a lock first: panfrost and panthor
> dma_resv_lock() (both hooks), omapdrm omap_obj->lock around its lazy page-get,
> the dma-heaps buffer->lock, and the TTM/GEM exporters (amdgpu, i915, xe) their
> object's reservation lock. tegra and videobuf2 take no lock here because they
> only sync an sg_table built earlier, so there is nothing to serialise.
>
> Confirmed with an out-of-tree A/B exercising the begin/begin race: this driver
> built as a module with get_sg_table()/put_sg_table() counting allocations
> against frees, driven by a userspace racer that creates 3000 udmabufs and fires
> DMA_BUF_IOCTL_SYNC(SYNC_START) from N threads on each shared fd.
>
> arm leaked sg_tables (of 3000 buffers)
> vulnerable, 4 threads 4761
> control, 1 thread 0
> patched (resv lock), 4 threads 0
>
> One sg_table and its DMA mapping leak per won race; the single-thread control
> does not leak, isolating the race; with the lock the lazy-init runs once per
> buffer (3000 allocations, zero leaked). end_cpu_udmabuf() is locked for the
> same field too: an unlocked end could otherwise observe the transient IS_ERR
> store begin makes before resetting ubuf->sg to NULL, and dereference it. In a
> tighter 5000-iteration loop the unpatched leak runs around 15-20 MB/s of slab.
> ---
> drivers/dma-buf/udmabuf.c | 16 +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> index bced421c0d65..702ae13b97d1 100644
> --- a/drivers/dma-buf/udmabuf.c
> +++ b/drivers/dma-buf/udmabuf.c
> @@ -226,6 +226,8 @@ static int begin_cpu_udmabuf(struct dma_buf *buf,
> struct device *dev = ubuf->device->this_device;
> int ret = 0;
>
> + dma_resv_lock(buf->resv, NULL);
Good catch, but we eventually wait for HW to finish while holding this lock.
So if possible lock it interruptible here.
Apart from that looks good to me,
Christian.
> +
> if (!ubuf->sg) {
> ubuf->sg = get_sg_table(dev, buf, direction);
> if (IS_ERR(ubuf->sg)) {
> @@ -238,6 +240,8 @@ static int begin_cpu_udmabuf(struct dma_buf *buf,
> dma_sync_sgtable_for_cpu(dev, ubuf->sg, direction);
> }
>
> + dma_resv_unlock(buf->resv);
> +
> return ret;
> }
>
> @@ -246,12 +250,18 @@ static int end_cpu_udmabuf(struct dma_buf *buf,
> {
> struct udmabuf *ubuf = buf->priv;
> struct device *dev = ubuf->device->this_device;
> + int ret = 0;
> +
> + dma_resv_lock(buf->resv, NULL);
>
> if (!ubuf->sg)
> - return -EINVAL;
> + ret = -EINVAL;
> + else
> + dma_sync_sgtable_for_device(dev, ubuf->sg, direction);
>
> - dma_sync_sgtable_for_device(dev, ubuf->sg, direction);
> - return 0;
> + dma_resv_unlock(buf->resv);
> +
> + return ret;
> }
>
> static const struct dma_buf_ops udmabuf_ops = {
>
> ---
> base-commit: 7eed1fb17959e721031555e5b5654083fe6a7d02
> change-id: 20260625-b4-disp-67d1f3db-0082918fdcb5
>
> Best regards,
> --
> Bryam Vargas <hexlabsecurity@proton.me>
>
>
^ permalink raw reply
* [ANN] new mailing list for CI reports
From: Mauro Carvalho Chehab @ 2026-06-25 9:47 UTC (permalink / raw)
To: linux-media
Hi all,
To improve how CI reports are handled, CI e-mails were moved to a separate
mailing list: media-ci@linuxtv.org.
Currently, it covers e-mails from:
- media-ci, which handles PRs and submitted patches;
- Jenkins, which covers mostly userspace apps.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH] dma-buf: udmabuf: avoid list copy size overflow
From: Yousef Alhouseen @ 2026-06-25 9:07 UTC (permalink / raw)
To: Christian König, Gerd Hoffmann, Vivek Kasireddy,
Sumit Semwal
Cc: dri-devel, linux-media, linaro-mm-sig, linux-kernel
In-Reply-To: <06bddfca-d868-4043-ac6f-28ca103fff02@amd.com>
Hi Christian,
Agreed. I sent a follow-up that makes list_limit unsigned and keeps
the checked array copy path.
Thanks,
Yousef
On Wed, 24 Jun 2026 14:58:58 +0200, "Christian König"
<christian.koenig@amd.com> wrote:
> On 6/24/26 14:52, Yousef Alhouseen wrote:
> > UDMABUF_CREATE_LIST copies an array whose element count comes from
> > userspace. The count is compared against list_limit, but list_limit is a
> > signed module parameter while the count is u32.
>
> We should probably just drop the sign from the module parameter instead.
>
> I don't see an use case for negative values here.
>
> Regards,
> Christian.
>
> >
> > If the limit is raised too far or made negative, that comparison no
> > longer bounds the count to a range where sizeof(*list) * count fits in
> > the u32 temporary used for the copy length. A wrapped copy length lets
> > memdup_user() copy fewer entries than udmabuf_create() subsequently
> > walks, leading to out-of-bounds reads from the copied list.
> >
> > Take a positive snapshot of the module limit and use memdup_array_user()
> > so the multiplication is checked before copying.
> >
> > Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
> > ---
> > drivers/dma-buf/udmabuf.c | 9 +++++----
> > 1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> > index bced421c0..b4078ec84 100644
> > --- a/drivers/dma-buf/udmabuf.c
> > +++ b/drivers/dma-buf/udmabuf.c
> > @@ -469,14 +469,15 @@ static long udmabuf_ioctl_create_list(struct file *filp, unsigned long arg)
> > struct udmabuf_create_list head;
> > struct udmabuf_create_item *list;
> > int ret = -EINVAL;
> > - u32 lsize;
> > + int limit;
> >
> > if (copy_from_user(&head, (void __user *)arg, sizeof(head)))
> > return -EFAULT;
> > - if (head.count > list_limit)
> > + limit = READ_ONCE(list_limit);
> > + if (!head.count || limit <= 0 || head.count > limit)
> > return -EINVAL;
> > - lsize = sizeof(struct udmabuf_create_item) * head.count;
> > - list = memdup_user((void __user *)(arg + sizeof(head)), lsize);
> > + list = memdup_array_user((void __user *)(arg + sizeof(head)),
> > + head.count, sizeof(*list));
> > if (IS_ERR(list))
> > return PTR_ERR(list);
> >
> > --
> > 2.54.0
> >
^ permalink raw reply
* [PATCH] dma-buf: udmabuf: make list limit unsigned
From: Yousef Alhouseen @ 2026-06-25 8:57 UTC (permalink / raw)
To: Gerd Hoffmann, Vivek Kasireddy, Sumit Semwal,
Christian König
Cc: dri-devel, linux-media, linaro-mm-sig, linux-kernel,
Yousef Alhouseen
UDMABUF_CREATE_LIST uses list_limit only as an upper bound for the
unsigned entry count supplied by userspace. Negative values have no
useful meaning and complicate the bounds check.
Make the module parameter unsigned and keep the checked array copy so
large counts cannot wrap the allocation size before udmabuf_create()
walks the copied list.
Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
---
drivers/dma-buf/udmabuf.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index b4078ec84..620113df3 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -16,8 +16,8 @@
#include <linux/vmalloc.h>
#include <linux/iosys-map.h>
-static int list_limit = 1024;
-module_param(list_limit, int, 0644);
+static uint list_limit = 1024;
+module_param(list_limit, uint, 0644);
MODULE_PARM_DESC(list_limit, "udmabuf_create_list->count limit. Default is 1024.");
static int size_limit_mb = 64;
@@ -469,12 +469,10 @@ static long udmabuf_ioctl_create_list(struct file *filp, unsigned long arg)
struct udmabuf_create_list head;
struct udmabuf_create_item *list;
int ret = -EINVAL;
- int limit;
if (copy_from_user(&head, (void __user *)arg, sizeof(head)))
return -EFAULT;
- limit = READ_ONCE(list_limit);
- if (!head.count || limit <= 0 || head.count > limit)
+ if (!head.count || head.count > READ_ONCE(list_limit))
return -EINVAL;
list = memdup_array_user((void __user *)(arg + sizeof(head)),
head.count, sizeof(*list));
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 1/2] media: v4l2-common: add v4l2_fill_pixfmt_aligned() helper
From: Laurent Pinchart @ 2026-06-25 8:51 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, linux-renesas-soc, biju.das.jz, jacopo.mondi,
Lad Prabhakar, Mauro Carvalho Chehab, Hans Verkuil,
Nicolas Dufresne, Sakari Ailus, Sven Püschel, Mehdi Djait,
Paul Cercueil, Isaac Scott, Daniel Scally, linux-media,
linux-kernel
In-Reply-To: <ajzjAVM8F8ZPMWcy@tom-desktop>
On Thu, Jun 25, 2026 at 10:12:49AM +0200, Tommaso Merciai wrote:
> Hi Laurent,
> Thanks for your review.
>
> On Wed, Jun 24, 2026 at 10:28:55PM +0300, Laurent Pinchart wrote:
> > Hi Tommaso,
> >
> > Thank you for the patch.
> >
> > On Wed, Jun 24, 2026 at 12:41:30PM +0200, Tommaso Merciai wrote:
> > > Add v4l2_fill_pixfmt_aligned(), a variant of v4l2_fill_pixfmt()
> > > that accepts a stride_alignment parameter, mirroring the existing
> > > v4l2_fill_pixfmt_mp() / v4l2_fill_pixfmt_mp_aligned() pair.
> > >
> > > v4l2_fill_pixfmt() is refactored to call v4l2_fill_pixfmt_aligned()
> > > with stride_alignment=1, preserving its existing behaviour.
> > >
> > > The new helper is needed by drivers whose DMA engine requires the
> > > line stride to be a multiple of a specific value, such as the
> > > Renesas RZ/G3E CRU which requires 128-byte alignment.
> > >
> > > Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> > > ---
> > > drivers/media/v4l2-core/v4l2-common.c | 17 +++++++++++++----
> > > include/media/v4l2-common.h | 3 +++
> > > 2 files changed, 16 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
> > > index 65db7340ad38..1de246acc7ab 100644
> > > --- a/drivers/media/v4l2-core/v4l2-common.c
> > > +++ b/drivers/media/v4l2-core/v4l2-common.c
> > > @@ -545,8 +545,8 @@ int v4l2_fill_pixfmt_mp(struct v4l2_pix_format_mplane *pixfmt,
> > > }
> > > EXPORT_SYMBOL_GPL(v4l2_fill_pixfmt_mp);
> > >
> > > -int v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt, u32 pixelformat,
> > > - u32 width, u32 height)
> > > +int v4l2_fill_pixfmt_aligned(struct v4l2_pix_format *pixfmt, u32 pixelformat,
> > > + u32 width, u32 height, u8 stride_alignment)
> > > {
> > > const struct v4l2_format_info *info;
> > > int i;
> > > @@ -562,14 +562,23 @@ int v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt, u32 pixelformat,
> > > pixfmt->width = width;
> > > pixfmt->height = height;
> > > pixfmt->pixelformat = pixelformat;
> > > - pixfmt->bytesperline = v4l2_format_plane_stride(info, 0, width, 1);
> > > + pixfmt->bytesperline = v4l2_format_plane_stride(info, 0, width,
> > > + stride_alignment);
> > > pixfmt->sizeimage = 0;
> > >
> > > for (i = 0; i < info->comp_planes; i++)
> > > pixfmt->sizeimage +=
> > > - v4l2_format_plane_size(info, i, width, height, 1);
> > > + v4l2_format_plane_size(info, i, width, height,
> > > + stride_alignment);
> > > return 0;
> > > }
> > > +EXPORT_SYMBOL_GPL(v4l2_fill_pixfmt_aligned);
> > > +
> > > +int v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt, u32 pixelformat,
> > > + u32 width, u32 height)
> > > +{
> > > + return v4l2_fill_pixfmt_aligned(pixfmt, pixelformat, width, height, 1);
> > > +}
> >
> > This could be an inline wrapper in include/media/v4l2-common.h, it would
> > be more efficient.
>
> Ok, thanks.
> I guess we want the same for v4l2_fill_pixfmt_mp() ?
That would be nice, as a separate patch, if you have time.
> > > EXPORT_SYMBOL_GPL(v4l2_fill_pixfmt);
> > >
> > > #ifdef CONFIG_MEDIA_CONTROLLER
> > > diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
> > > index edd416178c33..718a0f47f36b 100644
> > > --- a/include/media/v4l2-common.h
> > > +++ b/include/media/v4l2-common.h
> > > @@ -556,6 +556,9 @@ void v4l2_apply_frmsize_constraints(u32 *width, u32 *height,
> > > const struct v4l2_frmsize_stepwise *frmsize);
> > > int v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt, u32 pixelformat,
> > > u32 width, u32 height);
> > > +/* @stride_alignment is a power of 2 value in bytes */
> > > +int v4l2_fill_pixfmt_aligned(struct v4l2_pix_format *pixfmt, u32 pixelformat,
> > > + u32 width, u32 height, u8 stride_alignment);
> >
> > I know the existing functions lack documentation, but it's not a reason
> > to continue with that bad habit :-)
>
> Ouch :)
>
> > One point that needs to be clearly documented is how the stride
> > alignment is handled for different planes.
>
> Thanks, I will add documentation in v2.
>
> > > int v4l2_fill_pixfmt_mp(struct v4l2_pix_format_mplane *pixfmt, u32 pixelformat,
> > > u32 width, u32 height);
> > > /* @stride_alignment is a power of 2 value in bytes */
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2 1/1 RESEND] staging: media: tegra-video: vi: Improve media graph building logic
From: Svyatoslav Ryhel @ 2026-06-25 8:33 UTC (permalink / raw)
To: Thierry Reding, Jonathan Hunter, Sowjanya Komatineni,
Luca Ceresoli, Mauro Carvalho Chehab, Hans Verkuil,
Greg Kroah-Hartman, Svyatoslav Ryhel
Cc: linux-media, linux-tegra, linux-staging, linux-kernel
In-Reply-To: <20260625083302.71651-1-clamor95@gmail.com>
The existing tegra_vi_graph_build function relies heavily on a one-to-one
match between Device Tree nodes and media pad links. While this works for
simpler configurations, it causes issues when Device Tree nodes do not
match media pad link logic (e.g., mt9m114). Switch to the
media_entity_get_fwnode_pad helper to verify and retrieve the correct pad
linked to an endpoint, rather than assuming the endpoint ID matches the
pad ID.
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # tegra20, parallel camera
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/staging/media/tegra-video/vi.c | 78 ++++++++++++--------------
1 file changed, 35 insertions(+), 43 deletions(-)
diff --git a/drivers/staging/media/tegra-video/vi.c b/drivers/staging/media/tegra-video/vi.c
index f14cdc7b5211..24e4bd438678 100644
--- a/drivers/staging/media/tegra-video/vi.c
+++ b/drivers/staging/media/tegra-video/vi.c
@@ -1468,7 +1468,6 @@ static int tegra_vi_graph_build(struct tegra_vi_channel *chan,
struct tegra_vi *vi = chan->vi;
struct tegra_vi_graph_entity *ent;
struct fwnode_handle *ep = NULL;
- struct v4l2_fwnode_link link;
struct media_entity *local = entity->entity;
struct media_entity *remote;
struct media_pad *local_pad;
@@ -1478,70 +1477,64 @@ static int tegra_vi_graph_build(struct tegra_vi_channel *chan,
dev_dbg(vi->dev, "creating links for entity %s\n", local->name);
- while (1) {
- ep = fwnode_graph_get_next_endpoint(entity->asd.match.fwnode,
- ep);
- if (!ep)
- break;
+ fwnode_graph_for_each_endpoint(entity->asd.match.fwnode, ep) {
+ struct fwnode_handle *remote_parent __free(fwnode_handle) = NULL;
+ struct fwnode_handle *sink_ep __free(fwnode_handle) = NULL;
+ int src_idx, sink_idx;
- ret = v4l2_fwnode_parse_link(ep, &link);
- if (ret < 0) {
- dev_err(vi->dev, "failed to parse link for %pOF: %d\n",
- to_of_node(ep), ret);
+ src_idx = media_entity_get_fwnode_pad(local, ep,
+ MEDIA_PAD_FL_SOURCE);
+ if (src_idx < 0) {
+ dev_dbg(vi->dev, "no source pad found for %pfw\n", ep);
continue;
}
- if (link.local_port >= local->num_pads) {
- dev_err(vi->dev, "invalid port number %u on %pOF\n",
- link.local_port, to_of_node(link.local_node));
- v4l2_fwnode_put_link(&link);
- ret = -EINVAL;
- break;
+ remote_parent = fwnode_graph_get_remote_port_parent(ep);
+ if (!remote_parent) {
+ dev_dbg(vi->dev, "no remote parent found for %pfw\n",
+ ep);
+ continue;
}
- local_pad = &local->pads[link.local_port];
+ local_pad = &local->pads[src_idx];
/* Remote node is vi node. So use channel video entity and pad
* as remote/sink.
*/
- if (link.remote_node == of_fwnode_handle(vi->dev->of_node)) {
+ if (remote_parent == of_fwnode_handle(vi->dev->of_node)) {
remote = &chan->video.entity;
remote_pad = &chan->pad;
goto create_link;
}
- /*
- * Skip sink ports, they will be processed from the other end
- * of the link.
- */
- if (local_pad->flags & MEDIA_PAD_FL_SINK) {
- dev_dbg(vi->dev, "skipping sink port %pOF:%u\n",
- to_of_node(link.local_node), link.local_port);
- v4l2_fwnode_put_link(&link);
- continue;
- }
-
/* find the remote entity from notifier list */
ent = tegra_vi_graph_find_entity(&chan->notifier.done_list,
- link.remote_node);
+ remote_parent);
if (!ent) {
- dev_err(vi->dev, "no entity found for %pOF\n",
- to_of_node(link.remote_node));
- v4l2_fwnode_put_link(&link);
+ fwnode_handle_put(ep);
+ dev_err(vi->dev, "no entity found for %pfw\n",
+ remote_parent);
ret = -ENODEV;
break;
}
remote = ent->entity;
- if (link.remote_port >= remote->num_pads) {
- dev_err(vi->dev, "invalid port number %u on %pOF\n",
- link.remote_port,
- to_of_node(link.remote_node));
- v4l2_fwnode_put_link(&link);
- ret = -EINVAL;
- break;
+
+ sink_ep = fwnode_graph_get_remote_endpoint(ep);
+ if (!sink_ep) {
+ dev_dbg(vi->dev, "no sink ep found for %pfw\n",
+ ep);
+ continue;
+ }
+
+ sink_idx = media_entity_get_fwnode_pad(remote, sink_ep,
+ MEDIA_PAD_FL_SINK);
+ if (sink_idx < 0) {
+ dev_dbg(vi->dev, "no sink pad found for %pfw\n",
+ sink_ep);
+ continue;
}
- remote_pad = &remote->pads[link.remote_port];
+ remote_pad = &remote->pads[sink_idx];
create_link:
dev_dbg(vi->dev, "creating %s:%u -> %s:%u link\n",
@@ -1551,8 +1544,8 @@ static int tegra_vi_graph_build(struct tegra_vi_channel *chan,
ret = media_create_pad_link(local, local_pad->index,
remote, remote_pad->index,
link_flags);
- v4l2_fwnode_put_link(&link);
if (ret < 0) {
+ fwnode_handle_put(ep);
dev_err(vi->dev,
"failed to create %s:%u -> %s:%u link: %d\n",
local->name, local_pad->index,
@@ -1561,7 +1554,6 @@ static int tegra_vi_graph_build(struct tegra_vi_channel *chan,
}
}
- fwnode_handle_put(ep);
return ret;
}
--
2.51.0
^ permalink raw reply related
* [PATCH v2 0/1 RESEND] staging: media: tegra-video: vi: improve VI graph building logic
From: Svyatoslav Ryhel @ 2026-06-25 8:33 UTC (permalink / raw)
To: Thierry Reding, Jonathan Hunter, Sowjanya Komatineni,
Luca Ceresoli, Mauro Carvalho Chehab, Hans Verkuil,
Greg Kroah-Hartman, Svyatoslav Ryhel
Cc: linux-media, linux-tegra, linux-staging, linux-kernel
The existing tegra_vi_graph_build function relies heavily on a one-to-one
match between Device Tree nodes and media pad links. While this works for
simpler configurations, it causes issues when Device Tree nodes do not
match media pad link logic (e.g., mt9m114). Switch to the
media_entity_get_fwnode_pad helper to verify and retrieve the correct pad
linked to an endpoint, rather than assuming the endpoint ID matches the
pad ID.
---
Changes in v2:
- fixed use of NULL fw pointers in debug prints
---
Svyatoslav Ryhel (1):
staging: media: tegra-video: vi: Improve media graph building logic
drivers/staging/media/tegra-video/vi.c | 78 ++++++++++++--------------
1 file changed, 35 insertions(+), 43 deletions(-)
--
2.51.0
^ permalink raw reply
* Re: [RFC PATCH 1/6] media: mc: Implement shared media graph
From: Paul Elder @ 2026-06-25 8:23 UTC (permalink / raw)
To: Kieran Bingham, laurent.pinchart
Cc: michael.riesch, xuhf, stefan.klug, dan.scally, jacopo.mondi,
linux-media, linux-arm-kernel, linux-rockchip, linux-kernel,
hverkuil+cisco, nicolas.dufresne, ribalda, sakari.ailus
In-Reply-To: <178229758404.3075020.12553514371020830845@ping.linuxembedded.co.uk>
Hi Kieran,
Thanks for the not-necessarily-a-full review.
Quoting Kieran Bingham (2026-06-24 19:39:44)
> Hi Paul,
>
> I'm taking a first read through, some comments inline, but not
> necessarily a full review:
>
> Quoting Paul Elder (2026-06-19 06:26:28)
> > Currently, a media graph contains a main device whose driver is
> > responsible for creating the media device. We have however recently run
> > into devices that have multiple devices that can quality as a main
>
> s/quality/qualify/
>
> > device. Examples are the RK3588 which has a VICAP and two ISP
> > instances, and another example is the i.MX8MP which has an ISI and two
> > ISP instances. As there is currently no way to reconcile who the main
> > device is in the media device, these setups simple cannot be used
> > simultaneously.
>
> I'm very excited to see how we could apply this to the NXP i.MX8MP to
> resolve the ISI+ISP issue!
\o/
>
>
> > This patch extends the media controller API with a "shared media graph"
> > framework. This allows drivers to share a media device, thus enabling
> > the setups mentioned above. Instead of owning and creating a media
> > device, drivers can join-or-create a shared media device via the shared
> > media graph API. The matching is done automatically based on the
> > detected endpoints in the device tree.
>
> Sounds great! I'll read on...
>
> >
> > Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
> > ---
> > drivers/media/mc/Makefile | 2 +-
> > drivers/media/mc/mc-shared-graph.c | 335 +++++++++++++++++++++++++++++
> > include/media/mc-shared-graph.h | 92 ++++++++
> > 3 files changed, 428 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/media/mc/mc-shared-graph.c
> > create mode 100644 include/media/mc-shared-graph.h
> >
> > diff --git a/drivers/media/mc/Makefile b/drivers/media/mc/Makefile
> > index 2b7af42ba59c..1d502fdc52ad 100644
> > --- a/drivers/media/mc/Makefile
> > +++ b/drivers/media/mc/Makefile
> > @@ -1,7 +1,7 @@
> > # SPDX-License-Identifier: GPL-2.0
> >
> > mc-objs := mc-device.o mc-devnode.o mc-entity.o \
> > - mc-request.o
> > + mc-request.o mc-shared-graph.o
> >
> > ifneq ($(CONFIG_USB),)
> > mc-objs += mc-dev-allocator.o
> > diff --git a/drivers/media/mc/mc-shared-graph.c b/drivers/media/mc/mc-shared-graph.c
> > new file mode 100644
> > index 000000000000..c4067e5b861d
> > --- /dev/null
> > +++ b/drivers/media/mc/mc-shared-graph.c
> > @@ -0,0 +1,335 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * mc-shared-graph.c - Media Controller Shared Graph API
> > + *
> > + * Copyright (c) 2026 Paul Elder <paul.elder@ideasonboard.com>
> > + */
> > +
> > +/*
> > + * This file adds the Media Controller Shared Graph API. This allows drivers
> > + * to create shared media graphs or join existing media graphs from other
> > + * drivers, so that they can all be in the same media graph. This allows us to
> > + * have more complex media graphs chaining more complex hardware together,
> > + * instead of simple async subdevs.
> > + */
> > +
> > +#include <linux/device.h>
> > +#include <linux/fwnode.h>
> > +#include <linux/kref.h>
> > +#include <linux/property.h>
> > +
> > +#include <media/media-device.h>
> > +
> > +#include <media/mc-shared-graph.h>
> > +
> > +static LIST_HEAD(media_device_shared_list);
> > +static DEFINE_MUTEX(media_device_shared_lock);
> > +
> > +struct media_device_shared_member {
> > + struct device *dev;
> > + struct fwnode_handle *fwnode;
> > + struct list_head list;
> > +};
> > +
> > +struct media_device_shared_link {
> > + struct media_entity *source;
> > + u16 source_pad;
> > + struct media_entity *sink;
> > + u16 sink_pad;
> > + u32 flags;
> > + struct list_head list;
> > +};
> > +
> > +// TODO figure out locking for when multiple drivers touch the media graph;
> > +// maybe macros for shared versions?
>
> Do you mean for when drivers are trying to change link state directly?
I meant for all the operations that act on media device. I'm not sure what
there is because I didn't really find anything significant, and I found some
action point from some meeting notes somewhere that said "deprecate media_ops"
(not assigned to me) so...
If there aren't any then it's a non-issue, but if there are then I was
wondering if we need to return the shared media device to the driver (as
opposed to a non-shared regular media device) and use shared versions of media
device functions that have locking.
>
> > +struct media_device_shared {
> > + struct media_device mdev;
> > + struct list_head members;
> > + struct list_head links;
> > +
> > + struct list_head list;
> > + struct kref refcount;
> > +
> > + struct device *removed_device;
> > +};
> > +
> > +static inline struct media_device_shared *
> > +to_media_device_shared(struct media_device *mdev)
> > +{
> > + return container_of(mdev, struct media_device_shared, mdev);
> > +}
> > +
> > +static void media_device_shared_release(struct kref *kref)
> > +{
> > + struct media_device_shared *mds =
> > + container_of(kref, struct media_device_shared, refcount);
> > +
> > + dev_dbg(mds->removed_device, "%s: releasing Media Device\n", __func__);
> > +
> > + mutex_lock(&media_device_shared_lock);
> > +
> > + media_device_unregister(&mds->mdev);
> > + media_device_cleanup(&mds->mdev);
> > +
> > + list_del(&mds->list);
> > + mutex_unlock(&media_device_shared_lock);
> > +
> > + kfree(mds);
> > +}
> > +
> > +/* Callers should hold media_device_shared_lock when calling this function */
>
> Lets add a lockdep_assert then?
I learned something new today :)
>
>
> > +static bool __media_device_shared_find_match(struct media_device_shared *mds,
> > + struct fwnode_handle *fwnode)
> > +{
> > + struct media_device_shared_member *member;
> > + struct fwnode_handle *ep;
> > + struct fwnode_handle *remote_ep;
> > + bool match = false;
> > +
>
> is it just as easy as:
>
> lockdep_assert_held(&media_device_shared_lock);
> ?
If I understand correctly how lockdep_assert works, yes.
>
> > + // TODO: parse the device tree endpoints graph instead of finding just the
> > + // first-level neighbours
> > + fwnode_graph_for_each_endpoint(fwnode, ep) {
> > + list_for_each_entry(member, &mds->members, list) {
> > + remote_ep = fwnode_graph_get_remote_port_parent(ep);
> > + match = (member->fwnode == remote_ep);
> > + fwnode_handle_put(remote_ep);
> > +
> > + if (!match)
> > + continue;
> > +
> > + goto match_complete;
> > + }
> > + }
> > +
> > +match_complete:
> > + fwnode_handle_put(ep);
> > + return match;
> > +}
> > +
> > +/* Callers should hold media_device_shared_lock when calling this function */
>
> Lets add a lockdep check too then :D (same everywhere/anywhere it's
> needed)
>
>
> > +static struct media_device *__media_device_shared_get(struct device *dev)
> > +{
> > + struct media_device_shared *mds;
> > + struct media_device_shared_member *member;
> > + struct fwnode_handle *fwnode = dev_fwnode(dev);
> > + bool ret;
> > +
> > + dev_dbg(dev, "%s: searching for media device for %pfwf", __func__, fwnode);
> > +
> > + list_for_each_entry(mds, &media_device_shared_list, list) {
> > + ret = __media_device_shared_find_match(mds, fwnode);
> > + if (ret)
> > + break;
> > + }
> > +
> > + if (!ret)
> > + return NULL;
> > +
> > + member = kzalloc_obj(*member);
> > + if (!member)
> > + return NULL;
> > +
> > + member->dev = dev;
> > + member->fwnode = fwnode;
> > + list_add_tail(&member->list, &mds->members);
> > + kref_get(&mds->refcount);
> > +
> > + dev_dbg(dev, "%s: %pfwf joined media device of %pfwf",
> > + __func__, fwnode,
> > + list_first_entry(&mds->members, struct media_device_shared_member, list)->fwnode);
> > +
> > + return &mds->mdev;
> > +}
> > +
> > +/* Callers should hold media_device_shared_lock when calling this function */
> > +static struct media_device *__media_device_shared_create(struct device *dev)
> > +{
> > + struct media_device_shared *mds;
> > + struct media_device_shared_member *member;
> > + struct fwnode_handle *fwnode = dev_fwnode(dev);
> > + int ret;
> > +
> > + mds = kzalloc_obj(*mds);
> > + if (!mds)
> > + return NULL;
> > +
> > + member = kzalloc_obj(*member);
> > + if (!member)
> > + goto err_free_mds;
> > +
> > + media_device_init(&mds->mdev);
> > +
> > + ret = media_device_register(&mds->mdev);
> > + if (ret)
> > + goto err_free_member;
> > +
> > + INIT_LIST_HEAD(&mds->members);
> > + member->dev = dev;
> > + member->fwnode = fwnode;
> > + list_add_tail(&member->list, &mds->members);
> > +
> > + INIT_LIST_HEAD(&mds->links);
> > +
> > + kref_init(&mds->refcount);
> > + list_add_tail(&mds->list, &media_device_shared_list);
> > +
> > + // TODO figure out how to reconcile this with multiple members
>
> Aha, right - becuse the 'media_device dev' becomes whoever registers first.
> I wonder where it's actually used, and maybe that's ok ?
Yes, exactly. So far all I could find it used for was dev_err etc. In my
testing it hasn't caused any problems, since I tested both loading orders
between the rkcif and rkisp2. Maybe I missed something important and somebody
else knows better.
Although it's not very nice to have prints from the other device. Is making a
thin device an option?
>
> > + mds->mdev.dev = dev;
> > +
> > + devv_dbg(dev, "%s: Allocated media device with %pfwf at %p\n",
> > + __func__, fwnode, &mds->mdev);
> > + return &mds->mdev;
> > +
> > +err_free_member:
> > + kfree(member);
> > +err_free_mds:
> > + kfree(mds);
> > + return NULL;
> > +}
> > +
> > +// TODO figure out how to resolve the identifiers (model, driver name, etc);
> > +// atm it's racy and whoever gets it last wins
>
> Maybe that's something we need to pass or set up explicitly then, so
> it's clear it's a 'specific graph'
Yes. I have no clue where that name would come from though.
Although I thought userspace matches on the entity names of the media device?
Does the name of the graph matter? It needs to be consistent though imo.
I considered having a list of names of members, but I'm not sure how useful
that would be. We don't have a userspace API to check it, plus it can already
just list the member entities of the graph. And the driver doesn't really care
who else is in the graph, since the shared media graph machinery already
automatches based on dt endpoints.
Also imo it's also not too nice for userspace when {driver_name} refers to a
driver that doesn't exist.
>
> Would this give us a way to represent the hardware in a new form - i.e.
> thinking about IMX8MP - the existing graph wouldn't be available - so it
> wouldn't be any worry from a UABI perspective because it's just a whole
> new interface/media-device name....
Hm, maybe the media device name could just be something along the lines of
"shared-{platform_name}-media"? Although I suppose that assumes that each
platform only has one media graph and we'll run into problems when we have
multiple. Or we append the youngest register block address in the shared media
graph to the name?
>
>
>
> > +struct media_device *media_device_shared_join(struct device *dev)
> > +{
> > + struct media_device *mdev;
> > +
> > + mutex_lock(&media_device_shared_lock);
> > +
> > + mdev = __media_device_shared_get(dev);
> > + if (!!mdev) {
> > + dev_dbg(dev, "%s: found media device for %pfwf", __func__, dev_fwnode(dev));
> > + mutex_unlock(&media_device_shared_lock);
> > + return mdev;
> > + }
> > +
> > + mdev = __media_device_shared_create(dev);
> > + if (!mdev) {
> > + dev_warn(dev, "%s: failed to create media device for %pfwf", __func__, dev_fwnode(dev));
> > + mutex_unlock(&media_device_shared_lock);
> > + return ERR_PTR(-ENOMEM);
> > + }
> > +
> > + dev_dbg(dev, "%s: created media device for %pfwf", __func__, dev_fwnode(dev));
> > + mutex_unlock(&media_device_shared_lock);
> > + return mdev;
> > +}
> > +EXPORT_SYMBOL_GPL(media_device_shared_join);
> > +
> > +void media_device_shared_leave(struct media_device *mdev, struct device *dev)
> > +{
> > + struct media_device_shared *mds = to_media_device_shared(mdev);
> > + struct media_device_shared_member *member;
> > + struct media_device_shared_member *member_tmp;
> > + bool removed = false;
> > +
> > + mutex_lock(&media_device_shared_lock);
> > +
> > + list_for_each_entry_safe(member, member_tmp, &mds->members, list) {
> > + if (member->dev == dev) {
> > + list_del(&member->list);
> > + kfree(member);
> > + removed = true;
> > + }
> > + }
> > +
> > + if (!removed)
> > + dev_err(dev, "%s: %pfwf trying to leave from graph in which not a member",
> > + __func__, dev_fwnode(dev));
> > +
> > + mds->removed_device = dev;
> > + mutex_unlock(&media_device_shared_lock);
> > + kref_put(&mds->refcount, media_device_shared_release);
> > +}
> > +EXPORT_SYMBOL_GPL(media_device_shared_leave);
> > +
> > +int media_device_shared_join_link_source(struct media_device *mdev,
> > + struct device *dev,
> > + struct media_entity *source,
> > + u16 source_pad, u32 flags)
> > +{
> > + struct media_device_shared *mds = to_media_device_shared(mdev);
> > + struct media_device_shared_link *link;
> > + struct media_device_shared_link *link_tmp;
> > + int ret = 0;
> > +
> > + mutex_lock(&media_device_shared_lock);
> > +
> > + /*
> > + * TODO Figure out flags. Should we use greatest common denominator? Or
> > + * prioritize sink? Or whoever wins the race? For now we just take the flags
> > + * from the sink.
> > + *
> > + * TODO Figure out how to actually do the matching. For now we just match
> > + * whoever comes in first. This works with the simple example we're running
> > + * with now (rkcif + one rkisp2) but with setups with multiple copies of
> > + * hardware this will cause problems, like with rkcif + two rkisp2 and
> > + * imx8-isi + two rkisp1.
> > + */
> > + list_for_each_entry_safe(link, link_tmp, &mds->links, list) {
> > + if (link->sink) {
> > + ret = media_create_pad_link(source, source_pad,
> > + link->sink, link->sink_pad,
> > + link->flags);
> > + list_del(&link->list);
> > + kfree(link);
> > + goto exit_join_link_source;
> > + }
> > + }
> > +
> > + link = kzalloc_obj(*link);
> > + if (!link) {
> > + ret = -ENOMEM;
> > + goto exit_join_link_source;
> > + }
> > +
> > + link->source = source;
> > + link->source_pad = source_pad;
> > + link->flags = flags;
> > + list_add_tail(&link->list, &mds->links);
> > +
> > +exit_join_link_source:
> > + mutex_unlock(&media_device_shared_lock);
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(media_device_shared_join_link_source);
> > +
> > +// TODO deduplicate from above
>
> Indeed, it does look like an opportunity.
Ok this is the one exception that was an actual todo and not a topic for
discussion :)
(Unless someone has the opinion "actually we don't need to deduplicate this")
>
> > +int media_device_shared_join_link_sink(struct media_device *mdev,
> > + struct device *dev,
> > + struct media_entity *sink,
> > + u16 sink_pad, u32 flags)
> > +{
> > + struct media_device_shared *mds = to_media_device_shared(mdev);
> > + struct media_device_shared_link *link;
> > + struct media_device_shared_link *link_tmp;
> > + int ret = 0;
> > +
> > + mutex_lock(&media_device_shared_lock);
> > +
> > + list_for_each_entry_safe(link, link_tmp, &mds->links, list) {
> > + if (link->source) {
> > + ret = media_create_pad_link(link->source, link->source_pad,
> > + sink, sink_pad,
> > + flags);
> > + list_del(&link->list);
> > + kfree(link);
> > + goto exit_join_link_sink;
> > + }
> > + }
> > +
> > + link = kzalloc_obj(*link);
> > + if (!link) {
> > + ret = -ENOMEM;
> > + goto exit_join_link_sink;
> > + }
> > +
> > + link->sink = sink;
> > + link->sink_pad = sink_pad;
> > + link->flags = flags;
> > + list_add_tail(&link->list, &mds->links);
> > +
> > +exit_join_link_sink:
> > + mutex_unlock(&media_device_shared_lock);
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(media_device_shared_join_link_sink);
> > diff --git a/include/media/mc-shared-graph.h b/include/media/mc-shared-graph.h
> > new file mode 100644
> > index 000000000000..487325163f84
> > --- /dev/null
> > +++ b/include/media/mc-shared-graph.h
> > @@ -0,0 +1,92 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * mc-shared-graph.h - Media Controller Shared Graph API
> > + *
> > + * Copyright (c) 2026 Paul Elder <paul.elder@ideasonboard.com>
> > + */
> > +
> > +/*
> > + * This file adds the Media Controller Shared Graph API. This allows drivers
> > + * to create shared media graphs or join existing media graphs from other
> > + * drivers, so that they can all be in the same media graph. This allows us to
> > + * have more complex media graphs chaining more complex hardware together,
> > + * instead of simple async subdevs.
> > + */
> > +
> > +#include <linux/types.h>
> > +
> > +#ifndef _MEDIA_SHARED_GRAPH_H
> > +#define _MEDIA_SHARED_GRAPH_H
> > +
> > +struct device;
> > +struct media_device;
> > +struct media_entity;
> > +
> > +#if defined(CONFIG_MEDIA_CONTROLLER)
> > +/**
> > + * media_device_shared_join() - Join or create a new shared media device
> > + *
> > + * @dev: struct &device pointer
> > + *
> > + * This is the entrance function for a device to join or create a new shared
> > + * media device. It searches for an existing shared media device based on the
> > + * neighbours in the device's device tree ports node. If found, then this
> > + * functions returns the existing shared media device and joins it. If one is
> > + * not found then one is created and initialized and returned.
> > + */
> > +struct media_device *media_device_shared_join(struct device *dev);
> > +
> > +/**
> > + * media_device_shared_leave() - Leave the shared media device.
> > + *
> > + * @mdev: struct &media_device pointer
> > + * @dev: struct &device pointer
> > + *
> > + * This function makes the device leave the shared media device. When all
> > + * members have left the media device it will be freed.
> > + */
> > +void media_device_shared_leave(struct media_device *mdev, struct device *dev);
> > +
> > +/**
> > + * media_device_shared_join_link_source() - Register a link source in the shared media device
> > + *
> > + * @mdev: The struct &media_device pointer that is part of a shared media device
> > + * @dev: struct &device pointer
> > + * @source: The link source
> > + * @source_pad: The pad
> > + * @flags: The flags
> > + *
> > + * This function registers with the shared media device the source part of a
> > + * link. When the shared media device receives the matching sink part of a link
> > + * via media_device_shared_join_link_sink() then the link will be fully created.
> > + */
> > +int media_device_shared_join_link_source(struct media_device *mdev,
> > + struct device *dev,
> > + struct media_entity *source,
> > + u16 source_pad, u32 flags);
> > +
> > +/**
> > + * media_device_shared_join_link_sink() - Register a link sink in the shared media device
> > + *
> > + * Same as media_device_shared_join_link_source() but for sink instead of
> > + * source.
> > + */
> > +int media_device_shared_join_link_sink(struct media_device *mdev,
> > + struct device *dev,
> > + struct media_entity *sink,
> > + u16 sink_pad, u32 flags);
> > +#else
> > +static inline struct media_device *media_device_shared_join(struct device *dev)
> > +{ return NULL; }
> > +static inline void media_device_shared_leave(struct media_device *mdev,
> > + struct device *dev) { }
> > +static inline int media_device_shared_join_link_source(struct media_device *mdev,
> > + struct device *dev,
> > + struct media_entity *source,
> > + u16 source_pad, u32 flags) { }
> > +static inline int media_device_shared_join_link_sink(struct media_device *mdev,
> > + struct device *dev,
> > + struct media_entity *sink,
> > + u16 sink_pad, u32 flags) { }
>
> Should these two stubs which return an int return an error code? -ENODEV or such ?
Ah yes they should. I missed that.
Thanks,
Paul
>
>
> > +#endif /* CONFIG_MEDIA_CONTROLLER */
> > +#endif /* _MEDIA_DEV_SHARED_GRAPH_H */
> > --
> > 2.47.2
> >
^ permalink raw reply
* [PATCH v1 1/1 RESEND] media: i2c: mt9m114: Add get_fwnode_pad operation for IFP
From: Svyatoslav Ryhel @ 2026-06-25 8:21 UTC (permalink / raw)
To: Sakari Ailus, Laurent Pinchart, Mauro Carvalho Chehab,
Svyatoslav Ryhel
Cc: linux-media, linux-kernel
In-Reply-To: <20260625082111.47898-1-clamor95@gmail.com>
Currently, the driver's binding exposes only one endpoint, which maps to
the IFP subdevice's SOURCE pad. This configuration causes failures for
many devices using this camera because both the DT binding and the
one-to-one pad mapping logic map the endpoint to the wrong pad. Fix this
by implementing the get_fwnode_pad operation for the IFP, which correctly
matches the endpoint to the corresponding IFP pad.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/media/i2c/mt9m114.c | 44 ++++++++++++++++++++++++++++---------
1 file changed, 34 insertions(+), 10 deletions(-)
diff --git a/drivers/media/i2c/mt9m114.c b/drivers/media/i2c/mt9m114.c
index e395e2d14e97..16c2582551d3 100644
--- a/drivers/media/i2c/mt9m114.c
+++ b/drivers/media/i2c/mt9m114.c
@@ -1020,14 +1020,6 @@ static int mt9m114_stop_streaming(struct mt9m114 *sensor)
return ret;
}
-/* -----------------------------------------------------------------------------
- * Common Subdev Operations
- */
-
-static const struct media_entity_operations mt9m114_entity_ops = {
- .link_validate = v4l2_subdev_link_validate,
-};
-
/* -----------------------------------------------------------------------------
* Pixel Array Control Operations
*/
@@ -1381,6 +1373,10 @@ static const struct v4l2_subdev_internal_ops mt9m114_pa_internal_ops = {
.init_state = mt9m114_pa_init_state,
};
+static const struct media_entity_operations mt9m114_pa_entity_ops = {
+ .link_validate = v4l2_subdev_link_validate,
+};
+
static int mt9m114_pa_init(struct mt9m114 *sensor)
{
struct v4l2_ctrl_handler *hdl = &sensor->pa.hdl;
@@ -1403,7 +1399,7 @@ static int mt9m114_pa_init(struct mt9m114 *sensor)
/* Initialize the media entity. */
sd->entity.function = MEDIA_ENT_F_CAM_SENSOR;
- sd->entity.ops = &mt9m114_entity_ops;
+ sd->entity.ops = &mt9m114_pa_entity_ops;
pads[0].flags = MEDIA_PAD_FL_SOURCE;
ret = media_entity_pads_init(&sd->entity, 1, pads);
if (ret < 0)
@@ -2092,6 +2088,29 @@ static int mt9m114_ifp_registered(struct v4l2_subdev *sd)
return 0;
}
+/*
+ * The IFP has only one fwnode endpoint, which corresponds to the pad
+ * linked to the PA (PA SINK), while it should be the SOURCE for the
+ * next media device in the pipe.
+ */
+static int mt9m114_ifp_get_fwnode_pad(struct media_entity *entity,
+ struct fwnode_endpoint *endpoint)
+{
+ struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
+ struct mt9m114 *sensor = ifp_to_mt9m114(sd);
+ struct fwnode_handle *ifp_port = dev_fwnode(&sensor->client->dev);
+ struct fwnode_handle *ifp_ep;
+ int ret;
+
+ ifp_ep = fwnode_graph_get_next_endpoint(ifp_port, NULL);
+
+ ret = endpoint->local_fwnode == ifp_ep ? 1 : -ENXIO;
+
+ fwnode_handle_put(ifp_ep);
+
+ return ret;
+}
+
static const struct v4l2_subdev_video_ops mt9m114_ifp_video_ops = {
.s_stream = mt9m114_ifp_s_stream,
};
@@ -2119,6 +2138,11 @@ static const struct v4l2_subdev_internal_ops mt9m114_ifp_internal_ops = {
.unregistered = mt9m114_ifp_unregistered,
};
+static const struct media_entity_operations mt9m114_ifp_entity_ops = {
+ .link_validate = v4l2_subdev_link_validate,
+ .get_fwnode_pad = mt9m114_ifp_get_fwnode_pad,
+};
+
static int mt9m114_ifp_init(struct mt9m114 *sensor)
{
struct v4l2_subdev *sd = &sensor->ifp.sd;
@@ -2136,7 +2160,7 @@ static int mt9m114_ifp_init(struct mt9m114 *sensor)
/* Initialize the media entity. */
sd->entity.function = MEDIA_ENT_F_PROC_VIDEO_ISP;
- sd->entity.ops = &mt9m114_entity_ops;
+ sd->entity.ops = &mt9m114_ifp_entity_ops;
pads[0].flags = MEDIA_PAD_FL_SINK;
pads[1].flags = MEDIA_PAD_FL_SOURCE;
ret = media_entity_pads_init(&sd->entity, 2, pads);
--
2.51.0
^ permalink raw reply related
* [PATCH v1 0/1 RESEND] media: i2c: mt9m114: Add get_fwnode_pad operation for IFP
From: Svyatoslav Ryhel @ 2026-06-25 8:21 UTC (permalink / raw)
To: Sakari Ailus, Laurent Pinchart, Mauro Carvalho Chehab,
Svyatoslav Ryhel
Cc: linux-media, linux-kernel
Currently, the driver's binding exposes only one endpoint, which maps to
the IFP subdevice's SOURCE pad. This configuration causes failures for
many devices using this camera because both the DT binding and the
one-to-one pad mapping logic map the endpoint to the wrong pad. Fix this
by implementing the get_fwnode_pad operation for the IFP, which correctly
matches the endpoint to the corresponding IFP pad.
Svyatoslav Ryhel (1):
media: i2c: mt9m114: Add get_fwnode_pad operation for IFP
drivers/media/i2c/mt9m114.c | 44 ++++++++++++++++++++++++++++---------
1 file changed, 34 insertions(+), 10 deletions(-)
--
2.51.0
^ permalink raw reply
* Re: [PATCH 1/2] media: v4l2-common: add v4l2_fill_pixfmt_aligned() helper
From: Tommaso Merciai @ 2026-06-25 8:12 UTC (permalink / raw)
To: Laurent Pinchart
Cc: tomm.merciai, linux-renesas-soc, biju.das.jz, jacopo.mondi,
Lad Prabhakar, Mauro Carvalho Chehab, Hans Verkuil,
Nicolas Dufresne, Sakari Ailus, Sven Püschel, Mehdi Djait,
Paul Cercueil, Isaac Scott, Daniel Scally, linux-media,
linux-kernel
In-Reply-To: <20260624192855.GH851255@killaraus.ideasonboard.com>
Hi Laurent,
Thanks for your review.
On Wed, Jun 24, 2026 at 10:28:55PM +0300, Laurent Pinchart wrote:
> Hi Tommaso,
>
> Thank you for the patch.
>
> On Wed, Jun 24, 2026 at 12:41:30PM +0200, Tommaso Merciai wrote:
> > Add v4l2_fill_pixfmt_aligned(), a variant of v4l2_fill_pixfmt()
> > that accepts a stride_alignment parameter, mirroring the existing
> > v4l2_fill_pixfmt_mp() / v4l2_fill_pixfmt_mp_aligned() pair.
> >
> > v4l2_fill_pixfmt() is refactored to call v4l2_fill_pixfmt_aligned()
> > with stride_alignment=1, preserving its existing behaviour.
> >
> > The new helper is needed by drivers whose DMA engine requires the
> > line stride to be a multiple of a specific value, such as the
> > Renesas RZ/G3E CRU which requires 128-byte alignment.
> >
> > Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> > ---
> > drivers/media/v4l2-core/v4l2-common.c | 17 +++++++++++++----
> > include/media/v4l2-common.h | 3 +++
> > 2 files changed, 16 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
> > index 65db7340ad38..1de246acc7ab 100644
> > --- a/drivers/media/v4l2-core/v4l2-common.c
> > +++ b/drivers/media/v4l2-core/v4l2-common.c
> > @@ -545,8 +545,8 @@ int v4l2_fill_pixfmt_mp(struct v4l2_pix_format_mplane *pixfmt,
> > }
> > EXPORT_SYMBOL_GPL(v4l2_fill_pixfmt_mp);
> >
> > -int v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt, u32 pixelformat,
> > - u32 width, u32 height)
> > +int v4l2_fill_pixfmt_aligned(struct v4l2_pix_format *pixfmt, u32 pixelformat,
> > + u32 width, u32 height, u8 stride_alignment)
> > {
> > const struct v4l2_format_info *info;
> > int i;
> > @@ -562,14 +562,23 @@ int v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt, u32 pixelformat,
> > pixfmt->width = width;
> > pixfmt->height = height;
> > pixfmt->pixelformat = pixelformat;
> > - pixfmt->bytesperline = v4l2_format_plane_stride(info, 0, width, 1);
> > + pixfmt->bytesperline = v4l2_format_plane_stride(info, 0, width,
> > + stride_alignment);
> > pixfmt->sizeimage = 0;
> >
> > for (i = 0; i < info->comp_planes; i++)
> > pixfmt->sizeimage +=
> > - v4l2_format_plane_size(info, i, width, height, 1);
> > + v4l2_format_plane_size(info, i, width, height,
> > + stride_alignment);
> > return 0;
> > }
> > +EXPORT_SYMBOL_GPL(v4l2_fill_pixfmt_aligned);
> > +
> > +int v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt, u32 pixelformat,
> > + u32 width, u32 height)
> > +{
> > + return v4l2_fill_pixfmt_aligned(pixfmt, pixelformat, width, height, 1);
> > +}
>
> This could be an inline wrapper in include/media/v4l2-common.h, it would
> be more efficient.
Ok, thanks.
I guess we want the same for v4l2_fill_pixfmt_mp() ?
>
> > EXPORT_SYMBOL_GPL(v4l2_fill_pixfmt);
> >
> > #ifdef CONFIG_MEDIA_CONTROLLER
> > diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
> > index edd416178c33..718a0f47f36b 100644
> > --- a/include/media/v4l2-common.h
> > +++ b/include/media/v4l2-common.h
> > @@ -556,6 +556,9 @@ void v4l2_apply_frmsize_constraints(u32 *width, u32 *height,
> > const struct v4l2_frmsize_stepwise *frmsize);
> > int v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt, u32 pixelformat,
> > u32 width, u32 height);
> > +/* @stride_alignment is a power of 2 value in bytes */
> > +int v4l2_fill_pixfmt_aligned(struct v4l2_pix_format *pixfmt, u32 pixelformat,
> > + u32 width, u32 height, u8 stride_alignment);
>
> I know the existing functions lack documentation, but it's not a reason
> to continue with that bad habit :-)
Ouch :)
>
> One point that needs to be clearly documented is how the stride
> alignment is handled for different planes.
Thanks, I will add documentation in v2.
Kind Regards,
Tommaso
>
> > int v4l2_fill_pixfmt_mp(struct v4l2_pix_format_mplane *pixfmt, u32 pixelformat,
> > u32 width, u32 height);
> > /* @stride_alignment is a power of 2 value in bytes */
>
> --
> Regards,
>
> Laurent Pinchart
^ permalink raw reply
* Re: dma_fence cleanup/rework
From: Philipp Stanner @ 2026-06-25 7:25 UTC (permalink / raw)
To: Christian König, phasta, simona, sumit.semwal,
tvrtko.ursulin, dakr
Cc: dri-devel, linux-media, linaro-mm-sig
In-Reply-To: <20260624122917.2483-1-christian.koenig@amd.com>
On Wed, 2026-06-24 at 13:13 +0200, Christian König wrote:
> Then the last piece is dropping calling enable_signaling callback with the
> dma_fence lock held. This makes it possible for backends to acquire locks
> which are semantically ordered outside of the dma_fence lock.
>
> This is necessary to allows using the dma_fence inline lock in more cases,
> previously backends used some common external lock for their dma_fences to
> for example make it possible remove fences from linked lists.
Hi Christian,
thx for all this work! I will review around a bit during the next days.
For completeness, let me ask here:
Is there any relation, or any work in the pipe, which you would
consider a good solution for the race conditions described in these two
threads [1][2]?
Regards
P.
[1] https://lore.kernel.org/dri-devel/20260618-linux-drm_crtc_fix2-v1-1-c03e77b36f34@linaro.org/
[2] https://lore.kernel.org/dri-devel/fa0dc9757bf8343516c4b156a2b70ec91b64ef8f.camel@mailbox.org/
^ permalink raw reply
* Re: [PATCH v2 0/4] media: add and use fwnode_graph_for_each_endpoint_scoped()
From: Sakari Ailus @ 2026-06-25 7:24 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Frank Li, Andy Shevchenko, Daniel Scally, Heikki Krogerus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Mauro Carvalho Chehab, Dafna Hirschfeld, Heiko Stuebner,
Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
driver-core, linux-acpi, linux-kernel, linux-media,
linux-rockchip, linux-arm-kernel, linux-arm-msm, imx, Guoniu Zhou,
Frank Li, Guoniu Zhou
In-Reply-To: <20260624222042.GN851255@killaraus.ideasonboard.com>
Hi Laurent,
On Thu, Jun 25, 2026 at 01:20:42AM +0300, Laurent Pinchart wrote:
> On Wed, Jun 24, 2026 at 03:46:48PM -0500, Frank Li wrote:
> > On Wed, Jun 24, 2026 at 11:02:37PM +0300, Laurent Pinchart wrote:
> > > On Wed, Jun 24, 2026 at 02:35:14PM -0500, Frank Li wrote:
> > > > On Wed, Jun 24, 2026 at 10:19:35PM +0300, Laurent Pinchart wrote:
> > > > > On Wed, Jun 24, 2026 at 01:00:08PM -0400, Frank.Li@oss.nxp.com wrote:
> > > > > > Add new helper macro fwnode_graph_for_each_endpoint_scoped() and use it
> > > > > > simplify media code.
> > > > > >
> > > > > > Typical example should qualcomm's driver (camss.c), the v4l2_mc.c and
> > > > > > rkisp1-dev.c only silience improvement.
> > > > > >
> > > > > > Anyways, *_for_each_*_scoped() already use widely and make code clean.
> > > > > >
> > > > > > Build test only.
> > > > > >
> > > > > > Sakari Ailus:
> > > > > > when I try to improve the patch
> > > > > > "Add common helper library for 1-to-1 subdev registration", I found need
> > > > > > camss.c pattern, so I create this small improvement firstly.
> > > > >
> > > > > Those are nice cleanups, thank you.
> > > > >
> > > > > After applying this series, the only left users of the
> > > > > fwnode_graph_for_each_endpoint() macro are in drivers/base/property.c.
> > > >
> > > > I already checked previously, two place use it.
> > > >
> > > > fwnode_graph_get_endpoint_count(), it will go though all endpoints, last
> > > > ep is NULL, which totally equial to scoped() version.
> > > >
> > > > another one fwnode_graph_get_endpoint_by_id(), which return ep, expect
> > > > caller to call put().
> > > >
> > > > if use scoped() version, need use no_free_ptr() at return, which make think
> > > > a little bit complex.
> > >
> > > It would introduce a tiny bit of extra complexity there, but the
> > > advantage (in my opinion) is that we'll be able to remove the less safe
> > > fwnode_graph_for_each_endpoint() macro.
> > >
> > > Now one may argue that the risk of
> > > fwnode_graph_for_each_endpoint_scoped() is returning the iterator
> > > without using no_free_ptr(). I wonder if that would be easier to catch
> > > in static analysis tools than the current pattern that leaks a reference
> > > when exiting the loop early.
> >
> > It's not big deal, if everyone prefer drop fwnode_graph_for_each_endpoint(),
> > I can do it.
>
> Let's see what others think. If people prefer keeping both versions,
> I'll be OK with that.
I'd prefer to keep both: it depends on the use case which one is better.
--
Kind regards,
Sakari Ailus
^ permalink raw reply
* Re: [PATCH v3 0/3] staging: media: atomisp: use kvmalloc_objs() and drop redundant OOM messages
From: Andy Shevchenko @ 2026-06-25 7:14 UTC (permalink / raw)
To: Rodrigo Gobbi
Cc: andy, hansg, mchehab, sakari.ailus, gregkh, feng, ~lkcamp/patches,
linux-kernel-mentees, linux-kernel, linux-media, linux-staging
In-Reply-To: <20260623221028.40238-1-rodrigo.gobbi.7@gmail.com>
On Tue, Jun 23, 2026 at 07:09:25PM -0300, Rodrigo Gobbi wrote:
> Several allocations in the atomisp driver still size their buffers with
> open-coded multiplication, e.g. width * height * sizeof(*p). When the
> dimensions are large the product can silently wrap, causing kvmalloc()
> to allocate an undersized buffer.
>
> Convert the remaining sites to kvmalloc_objs() with array_size(), which
> saturate to SIZE_MAX on overflow so kvmalloc() returns NULL instead of
> allocating too few bytes.
>
> This continues the work started in commit [2], and picks up the stalled
> sites from [1], unifying with [3].
>
> While here, drop the redundant IA_CSS_ERROR("out of memory") messages on
> the touched allocation paths: the memory management core already emits a
> far more detailed warning on allocation failure as raised at [1].
>
> [1] https://lore.kernel.org/all/20260413112904.98864-1-feng@innora.ai/
> [2] https://github.com/torvalds/linux/commit/d178c7ca8fefc28115d35b94c3b1f4d653e34182
FWIW, since it's in tree, you can refer to it in usual way:
d178c7ca8fef ("staging: media: atomisp: use array3_size() for overflow-safe allocation")
> [3] https://lore.kernel.org/all/20260609215110.118860-1-rodrigo.gobbi.7@gmail.com/
Anyways, the whole series is good, thanks!
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 2/3] staging: media: atomisp: use kvmalloc_objs() for overflow-safe allocation
From: Andy Shevchenko @ 2026-06-25 7:14 UTC (permalink / raw)
To: Rodrigo Gobbi
Cc: andy, hansg, mchehab, sakari.ailus, gregkh, feng, ~lkcamp/patches,
linux-kernel-mentees, linux-kernel, linux-media, linux-staging
In-Reply-To: <20260623221028.40238-3-rodrigo.gobbi.7@gmail.com>
On Tue, Jun 23, 2026 at 07:09:27PM -0300, Rodrigo Gobbi wrote:
> Replace open-coded width * height * sizeof() multiplications with
> kvmalloc_objs() and array_size() to prevent integer overflow in buffer
> allocations.
>
> The atomisp driver computes DVS and statistics buffer sizes using
> unchecked arithmetic. When dimensions are large, the product can
> silently wrap, causing kvmalloc() to allocate an undersized buffer.
>
> kvmalloc_objs() uses size_mul() internally, which saturates to SIZE_MAX
> on overflow, so kvmalloc() returns NULL instead of succeeding with too
> few bytes. array_size() provides the same overflow protection for the
> two-factor dimension products.
>
> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Feng Ning <feng@innora.ai>
> [rodrigo: rebased; convert only the sites left open-coded after
> commit d178c7ca8fef]
Thanks, you can keep this on a single line
[rodrigo: rebased; convert only the sites left open-coded after commit d178c7ca8fef]
> Signed-off-by: Rodrigo Gobbi <rodrigo.gobbi.7@gmail.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 1/4] device property: Introduce fwnode_graph_for_each_endpoint_scoped()
From: Andy Shevchenko @ 2026-06-25 6:33 UTC (permalink / raw)
To: Frank.Li
Cc: Daniel Scally, Heikki Krogerus, Sakari Ailus, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Mauro Carvalho Chehab,
Dafna Hirschfeld, Laurent Pinchart, Heiko Stuebner,
Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
driver-core, linux-acpi, linux-kernel, linux-media,
linux-rockchip, linux-arm-kernel, linux-arm-msm, imx, Guoniu Zhou,
Frank Li, Guoniu Zhou
In-Reply-To: <20260624-fw_scoped-v2-1-0a8db472af4a@nxp.com>
On Wed, Jun 24, 2026 at 01:00:09PM -0400, Frank.Li@oss.nxp.com wrote:
> Similar to recently propose for_each_child_of_node_scoped() this new
> version of the loop macro instantiates a new local struct fwnode_handle *
> that uses the __free(fwnode_handle) auto cleanup handling so that if a
> reference to a node is held on early exit from the loop the reference will
> be released. If the loop runs to completion, the child pointer will be NULL
> and no action will be taken.
>
> The reason this is useful is that it removes the need for
> fwnode_handle_put() on early loop exits. If there is a need to retain the
> reference, then return_ptr(child) or no_free_ptr(child) may be used to
> safely disable the auto cleanup.
...
> +#define fwnode_graph_for_each_endpoint_scoped(fwnode, child) \
> + for (struct fwnode_handle *child __free(fwnode_handle) = \
> + fwnode_graph_get_next_endpoint(fwnode, NULL); \
Now there is a misindentation of the \, id est an additional tab is missing.
> + child; child = fwnode_graph_get_next_endpoint(fwnode, child))
Collect more tags and send a v3 :-)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 0/4] media: add and use fwnode_graph_for_each_endpoint_scoped()
From: Andy Shevchenko @ 2026-06-25 6:31 UTC (permalink / raw)
To: Frank Li
Cc: Laurent Pinchart, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Mauro Carvalho Chehab, Dafna Hirschfeld, Heiko Stuebner,
Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
driver-core, linux-acpi, linux-kernel, linux-media,
linux-rockchip, linux-arm-kernel, linux-arm-msm, imx, Guoniu Zhou,
Frank Li, Guoniu Zhou
In-Reply-To: <ajxCOE3avXXLlrfT@SMW015318>
On Wed, Jun 24, 2026 at 03:46:48PM -0500, Frank Li wrote:
> On Wed, Jun 24, 2026 at 11:02:37PM +0300, Laurent Pinchart wrote:
> > On Wed, Jun 24, 2026 at 02:35:14PM -0500, Frank Li wrote:
> > > On Wed, Jun 24, 2026 at 10:19:35PM +0300, Laurent Pinchart wrote:
> > > > On Wed, Jun 24, 2026 at 01:00:08PM -0400, Frank.Li@oss.nxp.com wrote:
> > > > > Add new helper macro fwnode_graph_for_each_endpoint_scoped() and use it
> > > > > simplify media code.
> > > > >
> > > > > Typical example should qualcomm's driver (camss.c), the v4l2_mc.c and
> > > > > rkisp1-dev.c only silience improvement.
> > > > >
> > > > > Anyways, *_for_each_*_scoped() already use widely and make code clean.
> > > > >
> > > > > Build test only.
> > > > >
> > > > > Sakari Ailus:
> > > > > when I try to improve the patch
> > > > > "Add common helper library for 1-to-1 subdev registration", I found need
> > > > > camss.c pattern, so I create this small improvement firstly.
> > > >
> > > > Those are nice cleanups, thank you.
> > > >
> > > > After applying this series, the only left users of the
> > > > fwnode_graph_for_each_endpoint() macro are in drivers/base/property.c.
> > >
> > > I already checked previously, two place use it.
> > >
> > > fwnode_graph_get_endpoint_count(), it will go though all endpoints, last
> > > ep is NULL, which totally equial to scoped() version.
> > >
> > > another one fwnode_graph_get_endpoint_by_id(), which return ep, expect
> > > caller to call put().
> > >
> > > if use scoped() version, need use no_free_ptr() at return, which make think
> > > a little bit complex.
> >
> > It would introduce a tiny bit of extra complexity there, but the
> > advantage (in my opinion) is that we'll be able to remove the less safe
> > fwnode_graph_for_each_endpoint() macro.
> >
> > Now one may argue that the risk of
> > fwnode_graph_for_each_endpoint_scoped() is returning the iterator
> > without using no_free_ptr(). I wonder if that would be easier to catch
> > in static analysis tools than the current pattern that leaks a reference
> > when exiting the loop early.
>
> It's not big deal, if everyone prefer drop fwnode_graph_for_each_endpoint(),
> I can do it.
I slightly tend to the safest option (see below), but as a compromise I can
suggest to inline the fwnode_graph_for_each_endpoint() into that single user
that doesn't need a put. However, this may uglify the code and rise a question
of the consistency. So, consider that suggestion with grain of salt and apply
only if we have wider agreement with it.
> > > It'd better leave these as it.
TL;DR:
This is the safest option, of course. And as mentioned above I slightly
prefer this way. Another argument is that in some cases we might want to
have it in the future and since we have an existing user, let it live.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v6 2/9] dt-bindings: media: nxp: Add Wave6 video codec device
From: Krzysztof Kozlowski @ 2026-06-25 6:28 UTC (permalink / raw)
To: Nas Chung
Cc: Conor Dooley, mchehab@kernel.org, hverkuil@xs4all.nl,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
shawnguo@kernel.org, s.hauer@pengutronix.de,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-imx@nxp.com,
linux-arm-kernel@lists.infradead.org, jackson.lee, lafley.kim,
marek.vasut@mailbox.org
In-Reply-To: <SL2P216MB2441BB9DC91CCBE494F2B45BFBEC2@SL2P216MB2441.KORP216.PROD.OUTLOOK.COM>
On Thu, Jun 25, 2026 at 01:43:33AM +0000, Nas Chung wrote:
> >> + sram:
> >> + $ref: /schemas/types.yaml#/definitions/phandle
> >> + description:
> >> + phandle to the SRAM node used to store reference data, reducing DMA
> >> + memory bandwidth.
> >> +
> >> + iommus:
> >> + maxItems: 1
> >> +
> >> + "#cooling-cells":
> >> + const: 2
> >> +
> >> + "#address-cells":
> >> + const: 2
> >> +
> >> + "#size-cells":
> >> + const: 2
> >> +
> >> + ranges: true
> >> +
> >> +patternProperties:
> >> + "^interface@[0-9a-f]+$":
> >
> >I have to wonder if this interface business is required at all.
> >Why can this not go into the parent, with each region fetchable via
> >reg-names, interrupt-names and iommu-names?
>
> Thanks for your feedback.
>
> I did try the flat model, but the blocker is the IOMMU.
>
> The control region and four interface regions are independent DMA requesters
> with distinct stream IDs, and each interface can be assigned to a different VM,
> driving the video core with its own isolated memory.
>
> If all stream IDs are listed under the parent's iommus, they bind to a
> single device and share one domain, so the isolation is lost.
> This is the main reason I added the interface nodes.
Feels similar to issue Qualcomm has. I rejected such subnodes and
Qualcomm came with a solution in DMA IOMMU code, but that solution was
rejected by DMA folks:
https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
I don't have proper arguments to convince DMA folks, thus I agree for
Qualcomm for the subnodes. It should be fine here as well, in such case.
Best regards,
Krzysztof
^ permalink raw reply
* [RFC] media: dib0090: stale STANDARD_* guards appear to disable delivery-system paths
From: Pengpeng Hou @ 2026-06-25 6:10 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Kees Cook, linux-media, linux-kernel, Pengpeng Hou
Hi,
while auditing non-Kconfig macro worlds in drivers/media/dvb-frontends/dib0090.c,
I noticed that the file still has conditional paths using older local
CONFIG_STANDARD_* and STANDARD_* names, while nearby source uses current
CONFIG_SYS_* / SYS_* style delivery-system names.
This looks like a conditional data/control-path legality issue: if the old
STANDARD_* world is no longer reachable, register setup and calibration logic
for a delivery system can be silently compiled out even though related source
paths remain.
I am not sending a patch yet because the correct DVB policy is unclear. The
possible repairs appear to be:
1. map the old STANDARD_* world to the current SYS_* names;
2. add an explicit current local gate if the path is still supported; or
3. delete stale support if the path is intentionally dead.
Could you advise whether those STANDARD_* branches are still intended support,
or whether they should be converted or removed?
This is static source/macro analysis only. I have not tested tuner hardware.
Thanks,
Pengpeng
^ permalink raw reply
* [PATCH] udmabuf: serialize the sg_table cache under the reservation lock
From: Bryam Vargas via B4 Relay @ 2026-06-25 6:10 UTC (permalink / raw)
To: Christian König, Gerd Hoffmann, Vivek Kasireddy,
Sumit Semwal
Cc: Gurchetan Singh, linux-media, linux-kernel, linaro-mm-sig,
dri-devel
From: Bryam Vargas <hexlabsecurity@proton.me>
begin_cpu_udmabuf() builds and caches ubuf->sg with an unserialised
check-then-set, and end_cpu_udmabuf() reads the same field unlocked. The
core invokes both cpu-access hooks without holding the reservation lock and
DMA_BUF_IOCTL_SYNC is unlocked, so concurrent SYNC ioctls on a shared
udmabuf fd race on ubuf->sg: two begins can both observe NULL and both call
get_sg_table(), and the later store orphans the earlier table and its DMA
mapping, which release_udmabuf() never frees. Each won race permanently
leaks an sg_table and an unbalanced DMA mapping.
Serialize both hooks under the buffer's reservation lock, as panfrost and
panthor do. dma_buf_begin/end_cpu_access() already annotate might_lock() on
that lock, so taking it here matches the documented contract.
Single-threaded callers are unaffected.
Fixes: 284562e1f348 ("udmabuf: implement begin_cpu_access/end_cpu_access hooks")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
---
Same leak-with-dangling-pointer class as CVE-2024-56712 (export_udmabuf()
error path) -- a distinct site the 2024 fix does not cover.
udmabuf is the only exporter that lazily builds its sg_table cache inside the
cpu-access hook without serialising the check-then-set. The exporters that do
comparable in-hook cache work all take a lock first: panfrost and panthor
dma_resv_lock() (both hooks), omapdrm omap_obj->lock around its lazy page-get,
the dma-heaps buffer->lock, and the TTM/GEM exporters (amdgpu, i915, xe) their
object's reservation lock. tegra and videobuf2 take no lock here because they
only sync an sg_table built earlier, so there is nothing to serialise.
Confirmed with an out-of-tree A/B exercising the begin/begin race: this driver
built as a module with get_sg_table()/put_sg_table() counting allocations
against frees, driven by a userspace racer that creates 3000 udmabufs and fires
DMA_BUF_IOCTL_SYNC(SYNC_START) from N threads on each shared fd.
arm leaked sg_tables (of 3000 buffers)
vulnerable, 4 threads 4761
control, 1 thread 0
patched (resv lock), 4 threads 0
One sg_table and its DMA mapping leak per won race; the single-thread control
does not leak, isolating the race; with the lock the lazy-init runs once per
buffer (3000 allocations, zero leaked). end_cpu_udmabuf() is locked for the
same field too: an unlocked end could otherwise observe the transient IS_ERR
store begin makes before resetting ubuf->sg to NULL, and dereference it. In a
tighter 5000-iteration loop the unpatched leak runs around 15-20 MB/s of slab.
---
drivers/dma-buf/udmabuf.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index bced421c0d65..702ae13b97d1 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -226,6 +226,8 @@ static int begin_cpu_udmabuf(struct dma_buf *buf,
struct device *dev = ubuf->device->this_device;
int ret = 0;
+ dma_resv_lock(buf->resv, NULL);
+
if (!ubuf->sg) {
ubuf->sg = get_sg_table(dev, buf, direction);
if (IS_ERR(ubuf->sg)) {
@@ -238,6 +240,8 @@ static int begin_cpu_udmabuf(struct dma_buf *buf,
dma_sync_sgtable_for_cpu(dev, ubuf->sg, direction);
}
+ dma_resv_unlock(buf->resv);
+
return ret;
}
@@ -246,12 +250,18 @@ static int end_cpu_udmabuf(struct dma_buf *buf,
{
struct udmabuf *ubuf = buf->priv;
struct device *dev = ubuf->device->this_device;
+ int ret = 0;
+
+ dma_resv_lock(buf->resv, NULL);
if (!ubuf->sg)
- return -EINVAL;
+ ret = -EINVAL;
+ else
+ dma_sync_sgtable_for_device(dev, ubuf->sg, direction);
- dma_sync_sgtable_for_device(dev, ubuf->sg, direction);
- return 0;
+ dma_resv_unlock(buf->resv);
+
+ return ret;
}
static const struct dma_buf_ops udmabuf_ops = {
---
base-commit: 7eed1fb17959e721031555e5b5654083fe6a7d02
change-id: 20260625-b4-disp-67d1f3db-0082918fdcb5
Best regards,
--
Bryam Vargas <hexlabsecurity@proton.me>
^ permalink raw reply related
* [RFC PATCH] media: dib0090: enable L/S-band tuning table rows
From: Pengpeng Hou @ 2026-06-25 6:08 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Michael Krufky
Cc: Kees Cook, Bradford Love, Hans Verkuil, linux-media, linux-kernel,
Pengpeng Hou
The DiB0090 tuner source enables C-band, VHF and UHF table rows through
local CONFIG_BAND_* macros, but leaves CONFIG_BAND_LBAND and
CONFIG_BAND_SBAND undefined.
This compiles the L-band and S-band PLL/tuning rows out even though current
frontends still advertise BAND_LBAND and BAND_SBAND in band_caps. The
runtime band classifier can also route requested frequencies above UHF into
BAND_LBAND or BAND_SBAND before the driver walks the tuning and PLL tables.
Enable the existing L-band and S-band rows so the compiled provider tables
match the currently advertised band capabilities.
This is an RFC/RFT patch draft because the issue was found by static source
and macro-world auditing, not by hardware reproduction.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/media/dvb-frontends/dib0090.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/dvb-frontends/dib0090.c b/drivers/media/dvb-frontends/dib0090.c
index e2a48059e854..7221aefcdfe1 100644
--- a/drivers/media/dvb-frontends/dib0090.c
+++ b/drivers/media/dvb-frontends/dib0090.c
@@ -35,6 +35,8 @@ MODULE_PARM_DESC(debug, "turn on debugging (default: 0)");
#define CONFIG_BAND_CBAND
#define CONFIG_BAND_VHF
#define CONFIG_BAND_UHF
+#define CONFIG_BAND_LBAND
+#define CONFIG_BAND_SBAND
#define CONFIG_DIB0090_USE_PWM_AGC
#define EN_LNA0 0x8000
--
2.39.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox