docs: process: remove outdated submitting-drivers.rst

Commit 31b24bee3357 ("docs: add a warning to submitting-drivers.rst")
in October 2016 already warns "This (...) should maybe just be deleted,
but I'm not quite ready to do that yet".

Maybe, six years ago, we were not ready but let us remove old content
for the better now and structure and maintain less content in the kernel
documentation with a better result.

Drop this already outdated document and adjust all textual references.

Here is an argument why deleting the content will not remove any useful
information to the existing kernel documentation, individually broken down
for each section.

Section "Allocating Device Numbers" refers to https://www.lanana.org/, and
then refers to Documentation/admin-guide/devices.rst.

However, the devices.rst clearly states:

  "The version of this document at lanana.org is no longer maintained."

Everything needed for submitting drivers is already stated in devices.rst
and the reference to https://www.lanana.org/ is outdated, and should be
just deleted.

Section "Who To Submit Drivers To" is all about Linux 2.0 - 2.6, before
the new release version scheme; the mentioned developers are still around,
but actually not the first developers to contact anymore.

Section "What Criteria Determine Acceptance" has a few bullet points:

Licensing and Copyright is well-covered in process/kernel-license.rst.

Interfaces, Code, Portability, Clarity state some obvious things about
ensuring kernel code quality.

Control suggests to add a MAINTAINERS entry, which is already mentioned in
6.Followthrough.rst: "... added yourself to the MAINTAINERS file..."

PM support states a bit about implementing and testing power management of
a driver, it remains an open question where to place that in the process
documents. Driver developers interested in power management will find the
corresponding part on power management in the kernel documentation anyway.

In section "What Criteria Do Not Determine Acceptance", the points Vendor
and Author states something basic consequence of the kernel being an
open-source community software development. Probably no need to mention it
nowadays.

Section "Resources" lists resources that are also mentioned elsewhere more
central.

  - Linux kernel tree and mailing list is mentioned in many places.
  - https://lwn.net/Kernel/LDD3/ is mentioned in
    Documentation/process/kernel-docs.rst.

  - https://lwn.net/ is mentioned in:
    - Documentation/process/8.Conclusion.rst
    - Documentation/process/kernel-docs.rst

  - https://kernelnewbies.org/ is mentioned in:
      - Documentation/process/8.Conclusion.rst
      - Documentation/process/kernel-docs.rst

  - http://www.linux-usb.org/ is mentioned in
    Documentation/driver-api/usb/usb.rst

  - https://landley.net/kdocs/ols/2002/ols2002-pages-545-555.pdf
    is mentioned in Documentation/process/kernel-docs.rst

  - https://kernelnewbies.org/KernelJanitors is mentioned in
    Documentation/process/howto.rst

  - https://git-scm.com/ is mentioned in
    - Documentation/process/2.Process.rst
    - Documentation/process/7.AdvancedTopics.rst
    - Documentation/process/howto.rst

Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Link: https://lore.kernel.org/r/20220704122537.3407-7-lukas.bulwahn@gmail.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

1 files changed, 2 insertions, 2 deletions

diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
index e4beeca57e5f..cd6997a9d203 100644
--- a/Documentation/process/howto.rst
+++ b/Documentation/process/howto.rst
@@ -105,8 +105,8 @@ required reading:
     patches if these rules are followed, and many people will only
     review code if it is in the proper style.
 
-  :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` and :ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>`
-    These files describe in explicit detail how to successfully create
+  :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
+    This file describes in explicit detail how to successfully create
     and send a patch, including (but not limited to):
 
        - Email contents