1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
|
Media Subsystem Profile
=======================
Overview
--------
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
OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS maintainers
(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 linux-media@vger.kernel.org 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:
- https://patchwork.linuxtv.org/project/linux-media/list/
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:
- https://lore.kernel.org/linux-media/
.. [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 <sean@mess.org>
- HDMI CEC:
Hans Verkuil <hverkuil@xs4all.nl>
- Media controller drivers:
Laurent Pinchart <laurent.pinchart@ideasonboard.com>
- ISP, v4l2-async, v4l2-fwnode, v4l2-flash-led-class and Sensor drivers:
Sakari Ailus <sakari.ailus@linux.intel.com>
- V4L2 drivers and core V4L2 frameworks:
Hans Verkuil <hverkuil@xs4all.nl>
The subsystem maintainer is:
Mauro Carvalho Chehab <mchehab@kernel.org>
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 devicetree@vger.kernel.org mailing
list.
There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/
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
subsystem.
Those tests need to pass before the patches go upstream.
Also, please notice that we build the Kernel with::
make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script
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 ``checkpatch.pl`` on strict mode to verify the code
style, e.g.::
$ ./scripts/checkpatch.pl --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 ``checkpatch.pl``.
Please notice that the goal here is to improve code readability. On
a few cases, ``checkpatch.pl`` may actually point to something that would
look worse. So, you should use good sense.
Note that addressing one ``checkpatch.pl`` 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 https://patchwork.linuxtv.org, 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.
|
