Hello What is holding the drivers for the Freerunner back from being merged upstream? Can I do something to help? Following is a suggestion for what I could do. (Please be aware that English is not my native language. So if something is unclear, impossible to understand, easy to misunderstand or written in an insulting tone please ask me to clarify)
First some background on my thinking. I think the drivers that still are missing can be divided in four classes: Those that are believed to have a good enough quality to go in but haven't been sent yet, those that aren't there yet (if for example user space interfaces may change) but have someone working on bringing them closer to the quality needed to get them into the stable parts of Linux, those that aren't there and aren't being worked on and those drivers that duplicate upstream drivers. I don't know what driver is in what class since thing may have changes since [1]. I know that some drivers have been merged and others have had alternatives merged since then but I'm unsure about the rest. If my understanding of the process for Linux development is correct the situation is this: Drivers that are believed to be in the first class could go right into the stable parts of the Linux kernel. On the other hand they could have issues and it could take time to get the maintainers of the correct sub systems to review them. They could also go into staging with an "ask for feedback" in the todo. Drivers in the second category could only go into staging. (With issues that needs to be fixed in the todo) Drivers in the third category can't even go into staging unless they're already in widespread use or someone is willing to work on them. Drivers in staging can be thrown out if they don't make progress but unlike staying in a separate tree they will get more upstream attention. The attention means more people working to clean them up, help to change them when API's changes, etc. Since my C currently isn't the best I don't think I can help with drivers that don't have others working on them as well. But I realize that in addition to technical issues there are also other issues that may delay submitting code upstreams like getting the author information right. One thing I could do is to try to get patches containing the drivers and the authorship information that are in the second class or in the first class (but not expected to be submitted before after 2.6.36) into staging. Before sending them I would check Andy-tracking, the 2.6.3x series on git.openmoko.org, the source code and other sources for authorship information (if someone could point them out to me) to get the authorship correct. Then I would ask on this list if anyone feels left out just to be sure before sending them. If they were accepted into staging I could post patches for the trees on git.openmoko.org to move the code into the staging directory there as well to make patches easier to port between them and the upstream tree. I would also try to forward patches committed there to staging if the author doesn't. If other issues than getting authorship right and the act of sending patches are in the way of getting them closer to upstream I could try to solve them if they are pointed out to me. For example I think that my C is good enough to convert drivers that include firmware to use firmware loader to avoid legal issues if a driver has that kind of problems. If you think this sounds like a good idea please give me a hint about what driver(s) I could start with. If not please tell me why. If you have other ideas on how I can help make the drivers move upstream (or closer to upstream like staging) faster please tell me so I can consider it. Sincerely Sveinung Kvilhaugsvik [1] http://lists.openmoko.org/pipermail/openmoko-kernel/2009-July/010379.html
