Merging device drivers to LK tree

Merging device drivers to LK tree

[alexhoppus]

Hello!

I have several questions regarding how device drivers are merged into 
linux-kernel. First of all, I have found some document regarding 
submitting drivers to LK, but it  looks like pretty out-dated, 
https://kernelnewbies.org/UpstreamMerge/SubmittingDrivers
is this info still relevant? Or there is a new one?

Actually, I want to know more about the process. To start with this, I 
would like to ask an example question. Surfing through the kernel source 
I have found several ra-link usb wi-fi adapter drivers (rtl8188eu, 
rtl8192e, rtl8712 ...). Suppose one have datasheet that gives the 
possibility for writing a device driver for say rtlxxxxx based device. 
Can third-party person write & submit this driver to LK or this must be 
done explicitly by device vendor? What are the requirements from LK 
community side? Are there any license issues with this? (besides the 
author should publish code under GPL)

Merging device drivers to LK tree

[Greg KH]

On Mon, Mar 13, 2017 at 11:21:24PM +0300, alexhoppus wrote:
> Hello!
> 
> I have several questions regarding how device drivers are merged into 
> linux-kernel. First of all, I have found some document regarding 
> submitting drivers to LK, but it  looks like pretty out-dated, 
> https://kernelnewbies.org/UpstreamMerge/SubmittingDrivers
> is this info still relevant? Or there is a new one?

Look in the kernel source tree at Documentation/SubmittingDrivers for
the latest version.

> Actually, I want to know more about the process. To start with this, I 
> would like to ask an example question. Surfing through the kernel source 
> I have found several ra-link usb wi-fi adapter drivers (rtl8188eu, 
> rtl8192e, rtl8712 ...). Suppose one have datasheet that gives the 
> possibility for writing a device driver for say rtlxxxxx based device. 
> Can third-party person write & submit this driver to LK or this must be 
> done explicitly by device vendor?

Anyone can submit a driver.

> What are the requirements from LK community side?

It has to match our coding style rules and pass our code review.

> Are there any license issues with this? (besides the author should
> publish code under GPL)

Nope, just has to be compatible with GPLv2.

Do you have a specific driver you wish to get merged that isn't already
in the tree?

thanks,

greg k-h

Merging device drivers to LK tree

[alexhoppus]

On 14.03.2017 00:45, Greg KH wrote:
> On Mon, Mar 13, 2017 at 11:21:24PM +0300, alexhoppus wrote:
>> Hello!
>>
>> I have several questions regarding how device drivers are merged into
>> linux-kernel. First of all, I have found some document regarding
>> submitting drivers to LK, but it  looks like pretty out-dated,
>> https://kernelnewbies.org/UpstreamMerge/SubmittingDrivers
>> is this info still relevant? Or there is a new one?
>
> Look in the kernel source tree at Documentation/SubmittingDrivers for
> the latest version.
>
>> Actually, I want to know more about the process. To start with this, I
>> would like to ask an example question. Surfing through the kernel source
>> I have found several ra-link usb wi-fi adapter drivers (rtl8188eu,
>> rtl8192e, rtl8712 ...). Suppose one have datasheet that gives the
>> possibility for writing a device driver for say rtlxxxxx based device.
>> Can third-party person write & submit this driver to LK or this must be
>> done explicitly by device vendor?
>
> Anyone can submit a driver.
>
>> What are the requirements from LK community side?
>
> It has to match our coding style rules and pass our code review.
>
>> Are there any license issues with this? (besides the author should
>> publish code under GPL)
>
> Nope, just has to be compatible with GPLv2.
>
> Do you have a specific driver you wish to get merged that isn't already
> in the tree?

No, I just try to understand the process. I don't fully understand what 
is the role of independent developer in the process of submitting new 
drivers to LK. What I mean is - hardware device vendors always ship 
device driver with their products. In this case several options are 
available:
1.) HW vendor ships only closed-source drivers and is not interested to 
open source this work.
2.) HW vendor publishes device drivers to the community by himself
3.) HW vendor put the device driver sources to their website ready for 
downloading and building, but make no effort for integrating them to LK.

Actually, I see that in this plot independent developer could only 
participate in case 3 - i.e. take the published sources, fix coding 
style, satisfy other community needs and integrate this driver to LK 
(By the way is this a real case? Or drivers aren't integrated in such 
way?). I see no other ways how independent person could participate. Am 
I wrong?

>
> thanks,
>
> greg k-h
>

Merging device drivers to LK tree

[valdis.kletnieks at vt.edu]

On Tue, 14 Mar 2017 22:54:37 +0300, alexhoppus said:

> No, I just try to understand the process. I don't fully understand what
> is the role of independent developer in the process of submitting new
> drivers to LK. What I mean is - hardware device vendors always ship
> device driver with their products. In this case several options are
> available:
> 1.) HW vendor ships only closed-source drivers and is not interested to
> open source this work.
> 2.) HW vendor publishes device drivers to the community by himself
> 3.) HW vendor put the device driver sources to their website ready for
> downloading and building, but make no effort for integrating them to LK.

You missed one:

4.) HW vendor only ships a Windows or OSX client.

This happens more often than you think.

At which point, somebody buys the widget and reverse-engineers it. This
is trivial if the device chipset is already supported - it may just be a
matter of adding the devices PCI or USB ID to the driver code's table.
If it's similar to an existing device that's supported, the data sheet
and some hacking may be required. And sometimes, you're stuck with using
a JTAG and a logic analyzer.

> Actually, I see that in this plot independent developer could only
> participate in case 3 - i.e. take the published sources, fix coding
> style, satisfy other community needs and integrate this driver to LK
> (By the way is this a real case? Or drivers aren't integrated in such
> way?). I see no other ways how independent person could participate. Am
> I wrong?

Or the developer could take an existing in-tree driver and patch it to work.
This has also been done plenty of times (especially for vendors who have
released long series of hardware that's fairly similar).

Or the developer could just write the entire driver. This has been done plenty
of times.  Alan Cox probably holds the record for most drivers written. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170314/3f45366a/attachment.bin 

Merging device drivers to LK tree

[Bjørn Mork]

valdis.kletnieks at vt.edu writes:
> On Tue, 14 Mar 2017 22:54:37 +0300, alexhoppus said:
>
>> No, I just try to understand the process. I don't fully understand what
>> is the role of independent developer in the process of submitting new
>> drivers to LK. What I mean is - hardware device vendors always ship
>> device driver with their products. In this case several options are
>> available:
>> 1.) HW vendor ships only closed-source drivers and is not interested to
>> open source this work.
>> 2.) HW vendor publishes device drivers to the community by himself
>> 3.) HW vendor put the device driver sources to their website ready for
>> downloading and building, but make no effort for integrating them to LK.
>
> You missed one:
>
> 4.) HW vendor only ships a Windows or OSX client.


And another one:

 5.) vendor independent class drivers


IMHO perfect for the independent developer since there will be
documentation available.  The USB class specs are freely available for
example.



Bj?rn

Merging device drivers to LK tree

[valdis.kletnieks at vt.edu]

On Tue, 14 Mar 2017 21:59:20 +0100, Bj?rn Mork said:

> And another one:
>
>  5.) vendor independent class drivers
>
>
> IMHO perfect for the independent developer since there will be
> documentation available.  The USB class specs are freely available for
> example.

Hmm... /sys/class has a bunch of stuff already.  How many class drivers
are missing from there? And more importantly, class drivers for a hardware
class that's actually available (i.e. neither extinct or not shipping yet)?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170314/2e1d90e7/attachment.bin 

Merging device drivers to LK tree

[Greg KH]

On Tue, Mar 14, 2017 at 05:14:12PM -0400, valdis.kletnieks at vt.edu wrote:
> On Tue, 14 Mar 2017 21:59:20 +0100, Bj?rn Mork said:
> 
> > And another one:
> >
> >  5.) vendor independent class drivers
> >
> >
> > IMHO perfect for the independent developer since there will be
> > documentation available.  The USB class specs are freely available for
> > example.
> 
> Hmm... /sys/class has a bunch of stuff already.

/sys/class has nothing to do with a USB class specification :)

> How many class drivers
> are missing from there? And more importantly, class drivers for a hardware
> class that's actually available (i.e. neither extinct or not shipping yet)?

A USB "class" is a set of devices that follow a published specification.
Like a USB HID device (keyboard/mouse/etc.)  These are all published on
the usb.org website.  I think there still are a few class specs that are
not yet implemented on Linux, usually because no one actually made any
devices for them, or not enough that anyone really cares.

A /sys/class/ entry is a kernel subsystem that describes a set of
devices that interact with userspace in a defined way.  Like an "input"
class.  That is how userspace interacts with _all_ keyboards, be they
USB or PS/2 or i2c or whatever.

Hope this helps,

greg k-h