linux-kernel - Re: [PATCH v10 3/4] media: docs: add glossary.rst with common terms used at V4L2 spec

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: <20200828105040.GA844@valkosipuli.retiisi.org.uk>
Date:   Fri, 28 Aug 2020 13:50:41 +0300
From:   Sakari Ailus <sakari.ailus@....fi>
To:     Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
Cc:     Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        linux-kernel@...r.kernel.org, Jonathan Corbet <corbet@....net>,
        linux-media@...r.kernel.org
Subject: Re: [PATCH v10 3/4] media: docs: add glossary.rst with common terms
 used at V4L2 spec

Hi Mauro,

On Fri, Aug 28, 2020 at 11:11:00AM +0200, Mauro Carvalho Chehab wrote:
> Em Thu, 27 Aug 2020 14:08:11 +0300
> Sakari Ailus <sakari.ailus@....fi> escreveu:
> 
> > > +    MC-centric
> > > +	:term:`V4L2 hardware` that requires a :term:`MC API`.
> > > +
> > > +	Such hardware have ``V4L2_CAP_IO_MC`` device_caps field set
> > > +	(see :ref:`VIDIOC_QUERYCAP`).
> > > +
> > > +	See :ref:`v4l2_hardware_control` for more details.  
> > 	
> > I think this should be documented as referring to drivers, for it's a
> > property of a driver, not hardware.
> > 
> > There is hardware that better fits for MC-enabled drivers but still has
> > V4L2-centric driver written for it. The matter is further complicated by
> > e.g. raw camera systems that may consist of several different kinds of
> > devices, including external ISPs.
> > 
> > Say, a simple raw sensor + a CSI-2 receiver would fit for V4L2-centric
> > model well, but add a more complex sensor or that external ISP and that no
> > longer is the case. The CSI-2 receiver is still the same in both cases
> > though.
> > 
> > Similar comment on video-node-centric.
> 
> I guess I got what you meant. I'm folding it with the following diff:
> 
> diff --git a/Documentation/userspace-api/media/glossary.rst b/Documentation/userspace-api/media/glossary.rst
> index 45f0933e03c0..023bb561c406 100644
> --- a/Documentation/userspace-api/media/glossary.rst
> +++ b/Documentation/userspace-api/media/glossary.rst
> @@ -138,9 +138,9 @@ Glossary
>  	See :ref:`media_controller`.
>  
>      MC-centric
> -	:term:`V4L2 hardware` that requires a :term:`MC API`.
> +	:term:`V4L2 hardware` device driver that requires :term:`MC API`.
>  
> -	Such hardware have ``V4L2_CAP_IO_MC`` device_caps field set
> +	Such drivers have ``V4L2_CAP_IO_MC`` device_caps field set
>  	(see :ref:`VIDIOC_QUERYCAP`).
>  
>  	See :ref:`v4l2_hardware_control` for more details.
> @@ -203,9 +203,9 @@ Glossary
>  	:term:`bridge driver`. See :ref:`subdev`.
>  
>      Video-node-centric
> -	V4L2 hardware that doesn't require a media controller to be used.
> +	V4L2 device driver that doesn't require a media controller to be used.
>  
> -	Such hardware have the ``V4L2_CAP_IO_MC`` device_caps field unset
> +	Such drivers have the ``V4L2_CAP_IO_MC`` device_caps field unset
>  	(see :ref:`VIDIOC_QUERYCAP`).
>  
>      V4L2 Sub-device API

Yes, something like that. I also looked at a few more terms such as "V4L2
hardware" that are a bit of an oxymoron. This isn't in current
documentation so we should give them a little bit more thought before
adding them. I'll reply to the latest patch.

-- 
Kind regards,

Sakari Ailus