lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aSYdUzpqX38xxywI@trex>
Date: Tue, 25 Nov 2025 22:19:15 +0100
From: Jorge Ramirez <jorge.ramirez@....qualcomm.com>
To: Dikshita Agarwal <dikshita.agarwal@....qualcomm.com>
Cc: Jorge Ramirez <jorge.ramirez@....qualcomm.com>,
        vikash.garodia@....qualcomm.com, bod@...nel.org, mchehab@...nel.org,
        linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] media: venus: assign unique bus_info strings for encoder
 and decoder

On 25/11/25 18:39:14, Dikshita Agarwal wrote:
> 
> 
> On 11/25/2025 6:22 PM, Jorge Ramirez wrote:
> > On 25/11/25 13:59:56, Dikshita Agarwal wrote:
> >>
> >>
> >> On 11/22/2025 12:13 AM, Jorge Ramirez-Ortiz wrote:
> >>> The Venus encoder and decoder video devices currently report the same
> >>> bus_info string ("platform:qcom-venus").
> >>>
> >>> Assign unique bus_info identifiers by appending ":dec" and ":enc" to the
> >>> parent device name. With this change v4l2-ctl will display two separate
> >>> logical devices
> >>>
> >>> Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez@....qualcomm.com>
> >>> ---
> >>>  drivers/media/platform/qcom/venus/vdec.c | 5 +++++
> >>>  drivers/media/platform/qcom/venus/venc.c | 5 +++++
> >>>  2 files changed, 10 insertions(+)
> >>>
> >>> diff --git a/drivers/media/platform/qcom/venus/vdec.c b/drivers/media/platform/qcom/venus/vdec.c
> >>> index 4a6641fdffcf..63f6ae1ff6ac 100644
> >>> --- a/drivers/media/platform/qcom/venus/vdec.c
> >>> +++ b/drivers/media/platform/qcom/venus/vdec.c
> >>> @@ -433,9 +433,14 @@ vdec_g_selection(struct file *file, void *fh, struct v4l2_selection *s)
> >>>  static int
> >>>  vdec_querycap(struct file *file, void *fh, struct v4l2_capability *cap)
> >>>  {
> >>> +	struct venus_inst *inst = to_inst(file);
> >>> +	struct venus_core *core = inst->core;
> >>> +
> >>>  	strscpy(cap->driver, "qcom-venus", sizeof(cap->driver));
> >>>  	strscpy(cap->card, "Qualcomm Venus video decoder", sizeof(cap->card));
> >>>  	strscpy(cap->bus_info, "platform:qcom-venus", sizeof(cap->bus_info));
> >>> +	snprintf(cap->bus_info, sizeof(cap->bus_info),
> >>> +		 "platform:%s:dec", dev_name(core->dev));
> >>
> >> Is there a reason to keep both strscpy() and snprintf() for cap->bus_info?
> >> The second call to snprintf() seems to overwrite the value set by
> >> strscpy(), making the first assignment redundant. Would it be cleaner to
> >> remove the strscpy() line and rely solely on snprintf()?
> > 
> > argh, my bad, you are right. will fix.
> > 
> > perhaps we should just have instead
> > 
> > decoder:
> > strscpy(cap->bus_info,"platform:qcom-venus-dec", sizeof(cap->bus_info));
> > 
> > encoder:
> > strscpy(cap->bus_info, "platform:qcom-venus-enc",sizeof(cap->bus_info)); on the encoder
> > 
> > I suppose the additional info provided by the dev_name is not really
> > important to consumers.
> 
> In-fact, we don't even need to fill the bus_info, received a similar
> comment on iris [1]
> [1]:
> https://lore.kernel.org/linux-media/c4350128-a05c-47af-a7e7-2810171cd311@xs4all.nl/


Nope, that is wrong. 

if we dont fill bus_info we will end up with the following again:

root@...2210-rb1-core-kit:~# v4l2-ctl --list-devices
Qualcomm Venus video encoder (platform:5a00000.video-codec):
	 /dev/video0
	 /dev/video1  

instead of something like this:

root@...2210-rb1-core-kit:~# v4l2-ctl --list-devices
Qualcomm Venus video decoder (platform:qcom-venus_dec):
	 /dev/video1

Qualcomm Venus video encoder (platform:qcom-venus_enc):
	 /dev/video0

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ