lkml.org 
[lkml]   [2021]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2] media: add a subsystem profile documentation
Em Fri, 26 Feb 2021 16:23:55 -0800
Randy Dunlap <rdunlap@infradead.org> escreveu:

> Hi Mauro-

Thanks for the review! Just sent a v3 today that should address
the pointed issues.

Regards,
Mauro

>
>
> On 2/25/21 5:41 AM, Mauro Carvalho Chehab wrote:
> > Document the basic policies of the media subsystem profile.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> > ---
> >
> > v2: fix the Documentation/*/media directories
> >
> >
> > Documentation/driver-api/media/index.rst | 2 +
> > .../media/maintainer-entry-profile.rst | 161 ++++++++++++++++++
> > .../maintainer/maintainer-entry-profile.rst | 1 +
> > 3 files changed, 164 insertions(+)
> > create mode 100644 Documentation/driver-api/media/maintainer-entry-profile.rst
> >
>
> > 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..6318be833bfb
> > --- /dev/null
> > +++ b/Documentation/driver-api/media/maintainer-entry-profile.rst
> > @@ -0,0 +1,161 @@
> > +Media Subsystem Profile
> > +=======================
> > +
> > +Overview
> > +--------
> > +
> > +The media subsystem covers support for a variety of devices: stream
> > +capture, analog and digital TV, 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
> > + - include/media
> > +
> > +Both media userspace and Kernel APIs are documented and should be kept in
> > +sync with the API changes. It means that all patches that add new
> > +features to the subsystem should 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 should 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, 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 got wrong on your submission. Please check if the
> > +email is in plain text only and if your emailer is not mangling with
> > +whitespaces before complaining or submitting them again.
> > +
> > +Sub-maintainers
> > ++++++++++++++++
> > +
> > +At the media subsystem, we have a group of experienced developers that
> > +are responsible for doing the code reviews at the drivers (called
> > +sub-maintainers), and another senior developer responsible for the
> > +subsystem as a hole. For core changes, whenever possible, multiple
> > +media (sub-)maintainers do the review.
> > +
> > +The sub-maintainers work on specific areas of the subsystem, as
> > +described below:
> > +
> > +Digital TV:
> > + Sean Young <sean@mess.org>
> > +
> > +HDMI CEC:
> > + Hans Verkuil <hverkuil@xs4all.nl>
> > +
> > +Media controller drivers:
> > + Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > +
> > +Remote Controllers:
> > + Sean Young <sean@mess.org>
> > +
> > +Sensor drivers:
> > + Sakari Ailus <sakari.ailus@linux.intel.com>
> > +
> > +V4L2 drivers:
> > + Hans Verkuil <hverkuil@xs4all.nl>
> > +
> > +Submit Checklist Addendum
> > +-------------------------
> > +
> > +Patches that change the Open Firmware/Device Tree bindings should be
> > +reviewed by the Device Tree maintainers. So, DT maintainers should be
> > +c/c when those are submitted.
>
> Cc:ed
>
> > +
> > +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.
> > +
> > +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
>
> Style cleanups
>
> > +at the files where the style changes will affect.
> > +
> > +We may accept pure standalone style-cleanups, but they should ideally
>
> style cleanups,
>
> > +be one patch for the hole subsystem (if the cleanup is low volume),
>
> whole (or entire)
>
> > +or at least be grouped per directory. So, for example, if you're doing
>
> 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 on strict mode to verify the code style,
> > +e. g.::
>
> usually no space (in the kernel source tree)
> e.g.::
>
> > +
> > + $ ./script/checkpatch.pl --strict
> > +
> > +Please notice that the goal here is to improve code readability. On a few
> > +cases, checkpatch may actually point to something that would look worse.
> > +
> > +So, you should use good send sense here, being prepared to justify any
> > +coding style decision.
> > +
> > +Please also notice that, on some cases, when you fix one issue, you may
> > +receive warnings about lines longer than 80 columns. It is fine to have
> > +longer lines if this means that other warnings will be fixed by that.
> > +
> > +Yet, if you're having more than 80 columns on a line, please consider
> > +simplifying the code - if too indented - or to use shorter names for
> > +variables.
> > +
> > +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.
>
> Good info here.
> Thanks.
>



Thanks,
Mauro

\
 
 \ /
  Last update: 2021-03-01 10:43    [W:0.075 / U:2.960 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site