What are the benefits of merging code upstream?
Merging your source code upstream takes effort, dedication and time. The process is not easy, because the moment Linus accepts code into his tree, he runs the risk of having to maintain that code for the rest of his life. If bad quality code got accepted, maintaining the Linux kernel would become much more difficult. These reasons and more mean that the threshold for getting source code accepted into the Linux kernel is relatively high.
Keeping up with the changes in the upstream kernel can be a challenge, wasting days or weeks of developer time every time the upstream kernel changes. Code that lives in the upstream kernel does not have this issue, since kernel developers tend to simply grep the sources and fix up any driver that is impacted by a proposed API change. This frees up your developers for more important work.
Your source code will be present in every Linux distribution. This matters if you would like to sell your hardware to every Linux user. No more need to lobby distributions to include your patches (hard), you can just ask them to switch on a config option (easy).
Some of the world's best developers will be going over your source code with a fine comb. This may be embarrassing for a few days or weeks, but in the end the code tends to work better and be more easily maintained. In some cases the upstream developers have made network and storage drivers 30% faster, making the hardware more attractive to customers.
How to merge code upstream
/MergingStrategy strategies for merging code upstream.
/WhatNotToDo what you should never do if you want to merge upstream.
/GettingFlamed Oh no! The kernel developers said bad things about me, my code and my cat! What do I do now?
/SubmittingDrivers how to submit device drivers to the linux kernel.
/SubmittingPatches how to submit patches to the linux kernel.
/SubmitChecklist a checklist for submitting code upstream.
https://www.ozlabs.org/~akpm/stuff/tpp.txt The Perfect Patch