From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0C4E03C0630 for ; Wed, 7 Oct 2026 09:43:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791366230; cv=none; b=gpoaP0TeqyVdE6CXl0WTcrJFCveGXdsxUV/SzHs52+Vi52cMOjjo2MlIBaRJS2/scTEEnn4ALvPh56qKnJmNyszBHeGY3Xm5glMacaiFsKH9T8l3E0zELy2GoX4sW4Dl/MNgnDPXXW8fmn6qUti8eetnIiMsZWIO7NbCvvBmVbM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791366230; c=relaxed/simple; bh=2Ca4c6JhbUhObXxK45OX5E/BGcmEtmnbf8+3sn3jJZg=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=q3t8vtUe/m6wgpJG84uaTFu5Q5yE74Cvs5iz8gtFbZJtNxFVXYGOtdFoVq3kVXrroPTBuxzko/7Rft6W7u+hw37eia04ZcWwAVu4h35FVSkzv7nHzCwRdyAimKIfb0dGVksMrxALcNOrkvFIPPIjSxC4Etv4dbKZTsvj5QNaB18= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bRV99i5I; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bRV99i5I" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 86F601F0089B; Wed, 7 Oct 2026 09:43:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791366222; bh=rew8+mN/mRA6btRgXvptfYblVa4h98O6Rp7e//4KBlc=; h=Date:From:Subject:To:Cc:References:In-Reply-To; b=bRV99i5I7+mgq4n5NX9/D2Z7fqCShc8qXZ77WY17kY2+WHZfuhvISnkrd0KI8thd/ 3CzoBVtfREFFj3YVTfQrMUiEZIttt0vpr7IofVBQjsEuXAClxhnNBvzMl9wFuuPbAW YnQ3XXLF6Xu/ElJpbOU9tH4na+IRUBvPFQV0gpxMbTNCJmzhwJKZvQ7T4Ljxg4qi23 yFmrQd/H2W3AFSyIV9ETGw0+IrmqZo+g1w+uG4FBn/6gAdKk8t/uVV4Xtid3eMAzRf LUKJIZdllFkc5QltZQp8fKxcGATBiKUhO9bY8aI7Xklc71v+txGnrdPToCC62LMpXE Ab+kYcUJd62Mg== Message-ID: Date: Wed, 7 Oct 2026 11:43:35 +0200 Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Hans Verkuil Subject: Re: [PATCH 1/1] media: subdev: Make get_fmt on INTERNAL pads without STREAMS an error To: Sakari Ailus , linux-media@vger.kernel.org Cc: laurent.pinchart@ideasonboard.com, Prabhakar , Kate Hsuan , Dave Stevenson , Tommaso Merciai , Benjamin Mugnier , Sylvain Petinot , Christophe JAILLET , Julien Massot , Naushir Patuck , "Yan, Dongcheng" , Stefan Klug , Mirela Rabulea , =?UTF-8?Q?Andr=C3=A9_Apitzsch?= , Heimir Thor Sverrisson , Kieran Bingham , Mehdi Djait , Ricardo Ribalda Delgado , Hans de Goede , Jacopo Mondi , Tomi Valkeinen , David Plowman , "Yu, Ong Hock" , "Ng, Khai Wen" , Jai Luthra , Rishikesh Donadkar , Mattijs Korpershoek , Antti Laakso References: <20261006092950.690101-1-sakari.ailus@linux.intel.com> Content-Language: en-US, nl In-Reply-To: <20261006092950.690101-1-sakari.ailus@linux.intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 06/10/2026 11:29, Sakari Ailus wrote: > Internal pads should only be accessible to file handles with > V4L2_SUBDEV_CLIENT_CAP_STREAMS flag set. Return an error otherwise. > > Fixes: 49cdf56876d3 ("media: mc: Add INTERNAL pad flag") > Signed-off-by: Sakari Ailus > --- > drivers/media/v4l2-core/v4l2-subdev.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/media/v4l2-core/v4l2-subdev.c b/drivers/media/v4l2-core/v4l2-subdev.c > index a07d77e584c3..7cb5a40f0f8c 100644 > --- a/drivers/media/v4l2-core/v4l2-subdev.c > +++ b/drivers/media/v4l2-core/v4l2-subdev.c > @@ -854,8 +854,13 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg, > case VIDIOC_SUBDEV_G_FMT: { > struct v4l2_subdev_format *format = arg; > > - if (!client_supports_streams) > + if (!client_supports_streams) { > + if (format->pad < sd->entity.num_pads && > + sd->entity.pads[format->pad].flags & MEDIA_PAD_FL_INTERNAL) > + return -EINVAL; > + > format->stream = 0; > + } > > memset(format->reserved, 0, sizeof(format->reserved)); > memset(format->format.reserved, 0, sizeof(format->format.reserved)); > There is no documentation that I can find that says that MEDIA_PAD_FL_INTERNAL is only available if V4L2_SUBDEV_CLIENT_CAP_STREAMS is set. I think this needs some more thought: if internal pads are only available if that cap is set, then I expect that a lot more ioctls will need this check. In that case the check should become a helper function. But how does this affect e.g. G_TOPOLOGY or ENUM_LINKS? If the cap is not set, should internal pads still be reported? And you need checks in v4l2-compliance, ensuring that trying to access internal pads without that cap will indeed fail. Ideally you would like to have this emulated in vimc as well. In other words, I think this needs more work, both in the core and w.r.t. documentation. Regards, Hans