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