[patch 1/2] Documentation/process: Add maintainer handbooks section

[Thomas Gleixner]

General rules for patch submission, coding style and related details are
available, but most subsystems have their sub-system specific extra rules
which differ or go beyond the common rules.

Mark suggested to add a subsystem/maintainer handbook section, where
subsystem maintainers can explain their specific quirks.

Add the section and link to it from the submitting-patches document.

Suggested-by: Mark Brown <broonie@xxxxxxxxxx>
Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
---
 Documentation/process/index.rst                |    1 +
 Documentation/process/maintainer-handbooks.rst |   14 ++++++++++++++
 Documentation/process/submitting-patches.rst   |    4 ++++
 3 files changed, 19 insertions(+)

--- a/Documentation/process/index.rst
+++ b/Documentation/process/index.rst
@@ -27,6 +27,7 @@ Below are the essential guides that ever
    submitting-patches
    programming-language
    coding-style
+   maintainer-handbooks
    maintainer-pgp-guide
    email-clients
    kernel-enforcement-statement
--- /dev/null
+++ b/Documentation/process/maintainer-handbooks.rst
@@ -0,0 +1,14 @@
+.. _maintainer_handbooks_main:
+
+Subsystem and maintainer tree specific development process notes
+================================================================
+
+The purpose of this document is to provide subsystem specific information
+which is supplementary to the general development process handbook
+:ref:`Documentation/process <development_process_main>`.
+
+Contents:
+
+.. toctree::
+   :numbered:
+   :maxdepth: 2
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -18,6 +18,10 @@ submitting code.  If you are submitting
 for device tree binding patches, read
 Documentation/devicetree/bindings/submitting-patches.txt.
 
+Some subsystems and maintainer trees have additional information about
+their workflow and expectations, see :ref:`Documentation/process
+<maintainer_handbooks_main>`.
+
 Many of these steps describe the default behavior of the ``git`` version
 control system; if you use ``git`` to prepare your patches, you'll find much
 of the mechanical work done for you, though you'll still need to prepare