When you have changed some bit of the kernel, e.g. supported a new device or fixed a bug, you need to make a patch of your changes in order to distribute it to others and put it back in the kernel. This is easy to do. Say you have the patched version of the kernel in linux and the original version in linux.orig, then issue these commands.
make mrproper
diff -urN linux.orig linux > my_changes.diff
The make mrproper tidies up all the extra files lying around so that the diff is only of the actual relevant files. Note that the order of the linux.orig and linux arguments above is significant. If you do it the wrong way round you will have made a 'reversed' patch, which is at best confusing. You now have linux/ and linux.orig/ as well as a patch - my_changes.diff. You may now want to rename linux/ to linux.orig so that future patches do not duplicate the chages thus far - this enables each patch to be specific to a change, rather than monolithic. This helps the kernel maintainer (see below).
Russell King maintains an automated 'Patch State System' on his website at http://www.arm.linux.org.uk/developer/patches/ which tracks patches applied to the ARM Linux kernel. It is intended that all ARMLinux developers who wish their patch to be integrated into the ARMLinux kernel (aka -rmk kernels) should submit their patch to this system. These patches will then find their way to Linus.
However, this does not give the full story of patches applied; changes that go into Linus kernels are outside the scope of this patch system.
Please note that by submitting a patch or code to the patch system, you implicitly agree that it is suitable for redistribution with the kernel source. In other words, it is up to you to ensure that the material you submit to the patch system is suitable for inclusion in my kernel, and Linus' kernel. If you have any doubts about this point, please discuss it with Russell in private email.
There are certain restrictions on the system, so please follow these instructions carefully.
If you wish to send in a patch, please use the following procedure. It contains some important points that need to be followed:
Generate the patch. Please tell diff to generate unified patches, recursing and new files if necessary. The options are diff -urN. Also, please generate them using a path relative to the directory directly above the main linux/ source tree. If you only want a small area of the kernel, then use diff -urN linux.org/arch/arm/kernel linux/arch/arm/kernel. In the extremely rare case that you absolutely must generate the patch using a different path, please make this obviously visible in the textual part of the patch mail (not following this will result in delays with application of your patch).
Give the mail a descriptive subject line. This will appear on the web page, and in the release notes for the next -rmk version of the kernel.
Include some text in the message explaining what the new feature is, the bug, or why the patch is needed.
Put on a blank line "PATCH FOLLOWS". There must be no space before or after these words on this line.
On a separate line, add a tag "KernelVersion: " followed by the kernel version that the patch was generated against.
Append your patch as plain unwrapped text after this line to the end of the message. Note that the patches must be precisely what diff generates. It is not acceptable for TABs to be converted to spaces, or extra newlines or spaces to be added into the file. If you are unsure about the behaviour of your mailer, send the patch to yourself and examine it.
Mail it to <patches@arm.linux.org.uk>
When you receive a reply, you may wish to supply a detailed follow up article that explains exactly what your patch does. You can do this by replying to the mail you receive from the patch system.
If at any other time you wish to follow up on the patch, please use the subject line as the key (it should include the exact string "(Patch #number)", where 'number' is the patch number that you wish to follow up to).
Please absolutely do not send MIME encoded emails, even quoted-printable MIME encoded emails to the above address. If quoted-printable emails are sent, then you will receive an error message. All mails to <patches@arm.linux.org.uk> should be plain unwrapped text.
If you have developed a device driver that uses a major/minor pair, please get it allocated according to the linux/Documentation/devices.txt file. Major/minor numbers are device driver specific, not device specific. Any device driver which re-uses major/minor numbers without an extremely good reason (included along with the patch) do not stand any chance of being accepted.
To ease the problems of applying patches, I recommend that you send a patch that adds exactly one feature or bug fix in a single email. Mails containing zero or less, or two or more features stand a greater chance of not being applied if any one part of the patch is not acceptable for some reason.
Patches that are inter-dependent should not be sent - these significantly increase the probability of both patches being rejected, unless both get applied at the same time. My recommendation is: don't do it.
All patches should be complete, that is applying it should not cause any breakage. i.e., adding a new architecture inline function in include/asm-arm/arch-* should be done such that all existing architectures will still at the very least compile correctly. If you're not sure how it should be handled on a particular architecture, put in a GCC #warning statement.