<div>Yeah, that sounds good. Who know Greg's e-mail,or where to find him?</div><div><div><br></div><div style="font-size: 12px;font-family: Arial Narrow;padding:2px 0 2px 0;">------------------&nbsp;Original&nbsp;------------------</div><div style="font-size: 12px;background:#efefef;padding:8px;"><div><b>From: </b>&nbsp;"Valdis.Kletnieks";&lt;Valdis.Kletnieks@vt.edu&gt;;</div><div><b>Date: </b>&nbsp;Thu, May 12, 2016 01:32 AM</div><div><b>To: </b>&nbsp;"Aric"&lt;583241212@qq.com&gt;; <wbr></div><div><b>Cc: </b>&nbsp;"Robert P. J. Day"&lt;rpjday@crashcourse.ca&gt;; "kernelnewbies"&lt;kernelnewbies@kernelnewbies.org&gt;; <wbr></div><div><b>Subject: </b>&nbsp;Re: How to fast master kernel</div></div><div><br></div>On Wed, 11 May 2016 12:26:17 +0800, "Aric" said:<br><br>&gt; But for each board, it have dedicated kernel code package. For example, what<br>&gt; I want to do first, it I can write kernel drivers and kernel code freely. I can<br>&gt; easily add a I2C (AT24C02) device and finished its driver in a short time.<br><br>Wel, that's only actually helpful for the kernel if somebody's already<br>done the port to that board (which it seems they have, since it already<br>has a kernel package), and failed to add an I2C driver already.<br><br>The other thing that you could do that would benefit the kernel is to take<br>the vendor's code (which is probably some ancient creeping horror like 3.4<br>or even a 2.6.something), and get the drivers up to 4.6 level and get them<br>upstreamed.<br><br>Greg KH is almost certainly reading this, and he *loves* helping get<br>drivers into the main kernel :)<br><br>Greg, meet Aric.&nbsp; Aric, meet Greg.&nbsp; :)<br><br></div>