>Laurent Pinchart wrote: >Sent: Friday, July 09, 2010 5:32 PM >To: [email protected] >Cc: [email protected] >Subject: [RFC/PATCH v2 7/7] v4l: subdev: Generic ioctl support > >Instead of returning an error when receiving an ioctl call with an >unsupported command, forward the call to the subdev core::ioctl handler. > >Signed-off-by: Laurent Pinchart <[email protected]> >--- > Documentation/video4linux/v4l2-framework.txt | 5 +++++ > drivers/media/video/v4l2-subdev.c | 2 +- > 2 files changed, 6 insertions(+), 1 deletions(-) > >diff --git a/Documentation/video4linux/v4l2-framework.txt >b/Documentation/video4linux/v4l2-framework.txt >index 89bd881..581e7db 100644 >--- a/Documentation/video4linux/v4l2-framework.txt >+++ b/Documentation/video4linux/v4l2-framework.txt >@@ -365,6 +365,11 @@ VIDIOC_UNSUBSCRIBE_EVENT > To properly support events, the poll() file operation is also > implemented. > >+Private ioctls >+ >+ All ioctls not in the above list are passed directly to the sub-device >+ driver through the core::ioctl operation. >+ > > I2C sub-device drivers > ---------------------- >diff --git a/drivers/media/video/v4l2-subdev.c b/drivers/media/video/v4l2- >subdev.c >index 31bec67..ce47772 100644 >--- a/drivers/media/video/v4l2-subdev.c >+++ b/drivers/media/video/v4l2-subdev.c >@@ -120,7 +120,7 @@ static long subdev_do_ioctl(struct file *file, unsigned >int cmd, void *arg) > return v4l2_subdev_call(sd, core, unsubscribe_event, fh, arg); > > default: >- return -ENOIOCTLCMD; >+ return v4l2_subdev_call(sd, core, ioctl, cmd, arg); > } > > return 0;
Hi, one remark about this: (@Laurent: this is what've been discussing on Saturday on IRC) It looks to me that with this, a subdev will only be able to have either kernel or userspace-callable ioctls, not both. Note, that I don't mean one ioctl callable from both, but 2 ioctls, where one is kernel-callable and the other is userspace-callable. Technically that would work, but would become a security risk. Malicious userspace would be able to call the kernel-only ioctl. So a driver has to be careful not to expose a node to the userspace if it has kernel-callable subdev ioctls. As long as drivers obey that rule and we do not require both types of ioctls in one subdev, there is no problem. Best regards -- Pawel Osciak Linux Platform Group Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
