From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) (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 C42A733A702 for ; Fri, 10 Apr 2026 13:31:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.167.242.64 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775827900; cv=none; b=uuwMRf/EXu3shThhNEMju0gSr7ekBvIIZnr4xW4j/+0bO0EGqWZ2/OWx9DVEmU8coQdsidGxWh61YPULLIH/NW8EQQxC4uyQh3/jsOeKEqBEXgBsHr9MVVCfvDOWNPH92c2viRiDyYfdrtpPJPGfwDjHLc+KzbhzhqaM43MIhO4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775827900; c=relaxed/simple; bh=FI4sv2wc/0kUlHDnJsc/NYpt1SyN2EhEcMY6AAi47Tk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=OXtqvyCGcg68XmmUfmbHU+BV194mvUrYZJHLyLZGL8Oo0vMOz9JOZ74Gwg9kPDVfkAFVv3sZIgGIVOPYabqqcRl7M8EwfzNk3XlY7ucc8MYYh47B6IHyuJPxQ1w4WAMSnuyGjw1gSIgGBwnQG6rFnhnVQ+atKKKUovR4fZleRPI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com; spf=pass smtp.mailfrom=ideasonboard.com; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b=CdEVK8PA; arc=none smtp.client-ip=213.167.242.64 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="CdEVK8PA" Received: from ideasonboard.com (net-93-65-100-155.cust.vodafonedsl.it [93.65.100.155]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 5E3D1225; Fri, 10 Apr 2026 15:30:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1775827806; bh=FI4sv2wc/0kUlHDnJsc/NYpt1SyN2EhEcMY6AAi47Tk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=CdEVK8PAriUDIe9+Z9I7gXQKnb2yikdd3IODhpynKWAjBzGH3o4sUdXfYn/JVbTxb faGT8sc9D604SpP1fF1pZd10Fi9gT4bA4Qtd6DTaZcrN7azQJKyAbBtBxA+pqveEvB 6zMO5gDcRHNsx2oE10oLABQQ2jnTvQHatXUnK+Zs= Date: Fri, 10 Apr 2026 15:31:32 +0200 From: Jacopo Mondi To: Sakari Ailus Cc: linux-media@vger.kernel.org, hans@jjverkuil.nl, laurent.pinchart@ideasonboard.com, Prabhakar , Kate Hsuan , Dave Stevenson , Tommaso Merciai , Benjamin Mugnier , Sylvain Petinot , Christophe JAILLET , Julien Massot , Naushir Patuck , "Yan, Dongcheng" , "Cao, Bingbu" , "Qiu, Tian Shu" , Stefan Klug , Mirela Rabulea , =?utf-8?B?QW5kcsOp?= 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 Subject: Re: [PATCH v4 25/29] media: v4l2-subdev: Move subdev client capabilities into a new struct Message-ID: References: <20260408153939.969381-1-sakari.ailus@linux.intel.com> <20260408153939.969381-26-sakari.ailus@linux.intel.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260408153939.969381-26-sakari.ailus@linux.intel.com> Hi Sakari On Wed, Apr 08, 2026 at 06:39:34PM +0300, Sakari Ailus wrote: > Add struct v4l2_subdev_client_info to hold sub-device client capability > bits that used to be stored in the client_caps field of struct > v4l2_subdev_fh. The intent is to enable passing this struct to sub-device > pad operation callbacks for capability information. The main reason why > this is a new struct instead of a u64 field is that modifying the callback > arguments requires touching almost every sub-device driver and that is > desirable to avoid in the future, should more than the client capability bits > need to be known to the callbacks. > > Signed-off-by: Sakari Ailus > Reviewed-by: Mirela Rabulea > --- > drivers/media/v4l2-core/v4l2-subdev.c | 8 ++++---- > include/media/v4l2-subdev.h | 12 ++++++++++-- > 2 files changed, 14 insertions(+), 6 deletions(-) > > diff --git a/drivers/media/v4l2-core/v4l2-subdev.c b/drivers/media/v4l2-core/v4l2-subdev.c > index 40b28e070726..eaa408832c6b 100644 > --- a/drivers/media/v4l2-core/v4l2-subdev.c > +++ b/drivers/media/v4l2-core/v4l2-subdev.c > @@ -612,7 +612,7 @@ subdev_ioctl_get_state(struct v4l2_subdev *sd, struct v4l2_subdev_fh *subdev_fh, > case VIDIOC_SUBDEV_S_FRAME_INTERVAL: { > struct v4l2_subdev_frame_interval *fi = arg; > > - if (!(subdev_fh->client_caps & > + if (!(subdev_fh->ci.client_caps & > V4L2_SUBDEV_CLIENT_CAP_INTERVAL_USES_WHICH)) > fi->which = V4L2_SUBDEV_FORMAT_ACTIVE; > > @@ -652,7 +652,7 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg, > struct v4l2_subdev_fh *subdev_fh = to_v4l2_subdev_fh(vfh); > bool ro_subdev = test_bit(V4L2_FL_SUBDEV_RO_DEVNODE, &vdev->flags); > bool streams_subdev = sd->flags & V4L2_SUBDEV_FL_STREAMS; > - bool client_supports_streams = subdev_fh->client_caps & > + bool client_supports_streams = subdev_fh->ci.client_caps & > V4L2_SUBDEV_CLIENT_CAP_STREAMS; > int rval; > > @@ -1119,7 +1119,7 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg, > case VIDIOC_SUBDEV_G_CLIENT_CAP: { > struct v4l2_subdev_client_capability *client_cap = arg; > > - client_cap->capabilities = subdev_fh->client_caps; > + client_cap->capabilities = subdev_fh->ci.client_caps; > > return 0; > } > @@ -1139,7 +1139,7 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg, > client_cap->capabilities &= (V4L2_SUBDEV_CLIENT_CAP_STREAMS | > V4L2_SUBDEV_CLIENT_CAP_INTERVAL_USES_WHICH); > > - subdev_fh->client_caps = client_cap->capabilities; > + subdev_fh->ci.client_caps = client_cap->capabilities; I'm sorry for being annoying, but the discussion on v2 ended with the question on why we can't propagate the client caps to the drivers using the subdev state. I understand we have the active state which is stored in the subdev and not per-file handle. But ioctls are called on a file handle and it seems trivial to me copy the caps from the subdev_fh to the active state. It would result in a much smaller set of changes. What am I missing ? > > return 0; > } > diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h > index 93b672edd08e..e0861acc638d 100644 > --- a/include/media/v4l2-subdev.h > +++ b/include/media/v4l2-subdev.h > @@ -734,6 +734,14 @@ struct v4l2_subdev_state { > struct v4l2_subdev_stream_configs stream_configs; > }; > > +/** > + * struct v4l2_subdev_client_info - Sub-device client information > + * @client_caps: bitmask of ``V4L2_SUBDEV_CLIENT_CAP_*`` > + */ > +struct v4l2_subdev_client_info { > + u64 client_caps; > +}; > + > /** > * struct v4l2_subdev_pad_ops - v4l2-subdev pad level operations > * > @@ -1129,14 +1137,14 @@ struct v4l2_subdev { > * @vfh: pointer to &struct v4l2_fh > * @state: pointer to &struct v4l2_subdev_state > * @owner: module pointer to the owner of this file handle > - * @client_caps: bitmask of ``V4L2_SUBDEV_CLIENT_CAP_*`` > + * @ci: sub-device client info related to this file handle > */ > struct v4l2_subdev_fh { > struct v4l2_fh vfh; > struct module *owner; > #if defined(CONFIG_VIDEO_V4L2_SUBDEV_API) > struct v4l2_subdev_state *state; > - u64 client_caps; > + struct v4l2_subdev_client_info ci; > #endif > }; > > -- > 2.47.3 > >