1 files changed, 145 insertions, 0 deletions

diff --git a/Documentation/SubmittingDrivers b/Documentation/SubmittingDrivers
new file mode 100644
index 000000000000..de3b252e717d
--- /dev/null
+++ b/Documentation/SubmittingDrivers
@@ -0,0 +1,145 @@
+Submitting Drivers For The Linux Kernel
+---------------------------------------
+
+This document is intended to explain how to submit device drivers to the
+various kernel trees. Note that if you are interested in video card drivers
+you should probably talk to XFree86 (http://www.xfree86.org/) and/or X.Org
+(http://x.org/) instead.
+
+Also read the Documentation/SubmittingPatches document.
+
+
+Allocating Device Numbers
+-------------------------
+
+Major and minor numbers for block and character devices are allocated
+by the Linux assigned name and number authority (currently better
+known as H Peter Anvin). The site is http://www.lanana.org/. This
+also deals with allocating numbers for devices that are not going to
+be submitted to the mainstream kernel.
+
+If you don't use assigned numbers then when you device is submitted it will
+get given an assigned number even if that is different from values you may
+have shipped to customers before.
+
+Who To Submit Drivers To
+------------------------
+
+Linux 2.0:
+        No new drivers are accepted for this kernel tree
+
+Linux 2.2:
+        If the code area has a general maintainer then please submit it to
+        the maintainer listed in MAINTAINERS in the kernel file. If the
+        maintainer does not respond or you cannot find the appropriate
+        maintainer then please contact Alan Cox <alan@lxorguk.ukuu.org.uk>
+
+Linux 2.4:
+        The same rules apply as 2.2. The final contact point for Linux 2.4
+        submissions is Marcelo Tosatti <marcelo.tosatti@cyclades.com>.
+
+Linux 2.6:
+        The same rules apply as 2.4 except that you should follow linux-kernel
+        to track changes in API's. The final contact point for Linux 2.6
+        submissions is Andrew Morton <akpm@osdl.org>.
+
+What Criteria Determine Acceptance
+----------------------------------
+
+Licensing:      The code must be released to us under the
+                GNU General Public License. We don't insist on any kind
+                of exclusively GPL licensing, and if you wish the driver
+                to be useful to other communities such as BSD you may well
+                wish to release under multiple licenses.
+
+Copyright:      The copyright owner must agree to use of GPL.
+                It's best if the submitter and copyright owner
+                are the same person/entity. If not, the name of
+                the person/entity authorizing use of GPL should be
+                listed in case it's necessary to verify the will of
+                the copright owner.
+
+Interfaces:     If your driver uses existing interfaces and behaves like
+                other drivers in the same class it will be much more likely
+                to be accepted than if it invents gratuitous new ones. 
+                If you need to implement a common API over Linux and NT
+                drivers do it in userspace.
+
+Code:           Please use the Linux style of code formatting as documented
+                in Documentation/CodingStyle. If you have sections of code
+                that need to be in other formats, for example because they
+                are shared with a windows driver kit and you want to
+                maintain them just once separate them out nicely and note
+                this fact.
+
+Portability:    Pointers are not always 32bits, not all computers are little
+                endian, people do not all have floating point and you
+                shouldn't use inline x86 assembler in your driver without
+                careful thought. Pure x86 drivers generally are not popular.
+                If you only have x86 hardware it is hard to test portability
+                but it is easy to make sure the code can easily be made
+                portable.
+
+Clarity:        It helps if anyone can see how to fix the driver. It helps
+                you because you get patches not bug reports. If you submit a
+                driver that intentionally obfuscates how the hardware works
+                it will go in the bitbucket.
+
+Control:        In general if there is active maintainance of a driver by
+                the author then patches will be redirected to them unless 
+                they are totally obvious and without need of checking.
+                If you want to be the contact and update point for the
+                driver it is a good idea to state this in the comments,
+                and include an entry in MAINTAINERS for your driver.
+
+What Criteria Do Not Determine Acceptance
+-----------------------------------------
+
+Vendor:         Being the hardware vendor and maintaining the driver is
+                often a good thing. If there is a stable working driver from
+                other people already in the tree don't expect 'we are the
+                vendor' to get your driver chosen. Ideally work with the 
+                existing driver author to build a single perfect driver.
+
+Author:         It doesn't matter if a large Linux company wrote the driver,
+                or you did. Nobody has any special access to the kernel
+                tree. Anyone who tells you otherwise isn't telling the
+                whole story.
+
+
+Resources
+---------
+
+Linux kernel master tree:
+        ftp.??.kernel.org:/pub/linux/kernel/...
+        ?? == your country code, such as "us", "uk", "fr", etc.
+
+Linux kernel mailing list:              
+        linux-kernel@vger.kernel.org
+        [mail majordomo@vger.kernel.org to subscribe]
+
+Linux Device Drivers, Third Edition (covers 2.6.10):
+        http://lwn.net/Kernel/LDD3/  (free version)
+
+Kernel traffic:
+        Weekly summary of kernel list activity (much easier to read)
+        http://www.kerneltraffic.org/kernel-traffic/
+
+LWN.net:
+        Weekly summary of kernel development activity - http://lwn.net/
+        2.6 API changes:
+                http://lwn.net/Articles/2.6-kernel-api/
+        Porting drivers from prior kernels to 2.6:
+                http://lwn.net/Articles/driver-porting/
+
+KernelTrap:
+        Occasional Linux kernel articles and developer interviews
+        http://kerneltrap.org/
+
+KernelNewbies:
+        Documentation and assistance for new kernel programmers
+        http://kernelnewbies.org/
+
+Linux USB project:
+        http://sourceforge.net/projects/linux-usb/
+