path: root/Documentation/driver-api
diff options
authorMauro Carvalho Chehab <>2019-09-18 10:59:44 -0300
committerMauro Carvalho Chehab <>2021-03-22 08:56:42 +0100
commit86ee6729c9b41797442f51768a676696560ecd88 (patch)
treecdbd77894efeb7900b87bbcedbac14e2fd01b5af /Documentation/driver-api
parent1f6c45ac5fd70ab59136ab5babc7def269f3f509 (diff)
media: add a subsystem profile documentation
Document the basic policies of the media subsystem profile. Signed-off-by: Mauro Carvalho Chehab <>
Diffstat (limited to 'Documentation/driver-api')
2 files changed, 208 insertions, 0 deletions
diff --git a/Documentation/driver-api/media/index.rst b/Documentation/driver-api/media/index.rst
index c140692454b1..2ad71dfa8828 100644
--- a/Documentation/driver-api/media/index.rst
+++ b/Documentation/driver-api/media/index.rst
@@ -28,6 +28,8 @@ Please see:
:maxdepth: 5
+ maintainer-entry-profile
diff --git a/Documentation/driver-api/media/maintainer-entry-profile.rst b/Documentation/driver-api/media/maintainer-entry-profile.rst
new file mode 100644
index 000000000000..eb1cdfd280ba
--- /dev/null
+++ b/Documentation/driver-api/media/maintainer-entry-profile.rst
@@ -0,0 +1,206 @@
+Media Subsystem Profile
+The media subsystem covers support for a variety of devices: stream
+capture, analog and digital TV streams, cameras, remote controllers, HDMI CEC
+and media pipeline control.
+It covers, mainly, the contents of those directories:
+ - drivers/media
+ - drivers/staging/media
+ - Documentation/admin-guide/media
+ - Documentation/driver-api/media
+ - Documentation/userspace-api/media
+ - Documentation/devicetree/bindings/media/\ [1]_
+ - include/media
+.. [1] Device tree bindings are maintained by the
+ (see the MAINTAINERS file). So, changes there must be reviewed
+ by them before being merged via the media subsystem's development
+ tree.
+Both media userspace and Kernel APIs are documented and the documentation
+must be kept in sync with the API changes. It means that all patches that
+add new features to the subsystem must also bring changes to the
+corresponding API files.
+Due to the size and wide scope of the media subsystem, media's
+maintainership model is to have sub-maintainers that have a broad
+knowledge of a specific aspect of the subsystem. It is the sub-maintainers'
+task to review the patches, providing feedback to users if the patches are
+following the subsystem rules and are properly using the media kernel and
+userspace APIs.
+Patches for the media subsystem must be sent to the media mailing list
+at as plain text only e-mail. Emails with
+HTML will be automatically rejected by the mail server. It could be wise
+to also copy the sub-maintainer(s).
+Media's workflow is heavily based on Patchwork, meaning that, once a patch
+is submitted, the e-mail will first be accepted by the mailing list
+server, and, after a while, it should appear at:
+ -
+If it doesn't automatically appear there after a few minutes, then
+probably something went wrong on your submission. Please check if the
+email is in plain text\ [2]_ only and if your emailer is not mangling
+whitespaces before complaining or submitting them again.
+You can check if the mailing list server accepted your patch, by looking at:
+ -
+.. [2] If your email contains HTML, the mailing list server will simply
+ drop it, without any further notice.
+Media maintainers
+At the media subsystem, we have a group of senior developers that
+are responsible for doing the code reviews at the drivers (also known as
+sub-maintainers), and another senior developer responsible for the
+subsystem as a whole. For core changes, whenever possible, multiple
+media maintainers do the review.
+The media maintainers that work on specific areas of the subsystem are:
+- Digital TV and remote controllers:
+ Sean Young <>
+ Hans Verkuil <>
+- Media controller drivers:
+ Laurent Pinchart <>
+- ISP, v4l2-async, v4l2-fwnode, v4l2-flash-led-class and Sensor drivers:
+ Sakari Ailus <>
+- V4L2 drivers and core V4L2 frameworks:
+ Hans Verkuil <>
+The subsystem maintainer is:
+ Mauro Carvalho Chehab <>
+Media maintainers may delegate a patch to other media maintainers as needed.
+On such case, checkpatch's ``delegate`` field indicates who's currently
+responsible for reviewing a patch.
+Submit Checklist Addendum
+Patches that change the Open Firmware/Device Tree bindings must be
+reviewed by the Device Tree maintainers. So, DT maintainers should be
+Cc:ed when those are submitted via mailing
+There is a set of compliance tools at
+that should be used in order to check if the drivers are properly
+implementing the media APIs:
+==================== =======================================================
+Type Tool
+==================== =======================================================
+V4L2 drivers\ [3]_ ``v4l2-compliance``
+V4L2 virtual drivers ``contrib/test/test-media``
+CEC drivers ``cec-compliance``
+==================== =======================================================
+.. [3] The ``v4l2-compliance`` also covers the media controller usage inside
+ V4L2 drivers.
+Other compilance tools are under development to check other parts of the
+Those tests need to pass before the patches go upstream.
+Also, please notice that we build the Kernel with::
+Where the check script is::
+ #!/bin/bash
+ /devel/smatch/smatch -p=kernel $@ >&2
+ /devel/sparse/sparse $@ >&2
+Be sure to not introduce new warnings on your patches without a
+very good reason.
+Style Cleanup Patches
+Style cleanups are welcome when they come together with other changes
+at the files where the style changes will affect.
+We may accept pure standalone style cleanups, but they should ideally
+be one patch for the whole subsystem (if the cleanup is low volume),
+or at least be grouped per directory. So, for example, if you're doing a
+big cleanup change set at drivers under drivers/media, please send a single
+patch for all drivers under drivers/media/pci, another one for
+drivers/media/usb and so on.
+Coding Style Addendum
+Media development uses ```` on strict mode to verify the code
+style, e.g.::
+ $ ./scripts/ --strict --max-line-length=80
+In principle, patches should follow the coding style rules, but exceptions
+are allowed if there are good reasons. On such case, maintainers and reviewers
+may question about the rationale for not addressing the ````.
+Please notice that the goal here is to improve code readability. On
+a few cases, ```` may actually point to something that would
+look worse. So, you should use good sense.
+Note that addressing one ```` issue (of any kind) alone may lead
+to having longer lines than 80 characters per line. While this is not
+strictly prohibited, efforts should be made towards staying within 80
+characters per line. This could include using re-factoring code that leads
+to less indentation, shorter variable or function names and last but not
+least, simply wrapping the lines.
+In particular, we accept lines with more than 80 columns:
+ - on strings, as they shouldn't be broken due to line length limits;
+ - when a function or variable name need to have a big identifier name,
+ which keeps hard to honor the 80 columns limit;
+ - on arithmetic expressions, when breaking lines makes them harder to
+ read;
+ - when they avoid a line to end with an open parenthesis or an open
+ bracket.
+Key Cycle Dates
+New submissions can be sent at any time, but if they intend to hit the
+next merge window they should be sent before -rc5, and ideally stabilized
+in the linux-media branch by -rc6.
+Review Cadence
+Provided that your patch is at, it should
+be sooner or later handled, so you don't need to re-submit a patch.
+Except for bug fixes, we don't usually add new patches to the development
+tree between -rc6 and the next -rc1.
+Please notice that the media subsystem is a high traffic one, so it
+could take a while for us to be able to review your patches. Feel free
+to ping if you don't get a feedback in a couple of weeks or to ask
+other developers to publicly add Reviewed-by and, more importantly,
+``Tested-by:`` tags.
+Please note that we expect a detailed description for ``Tested-by:``,
+identifying what boards were used at the test and what it was tested.