linux-kernel - Re: New ark3116 driver - how to get included into kernel?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7eb6a4d80909180515k48ee2197q8f6e5ff8933c4647@mail.gmail.com>
Date:	Fri, 18 Sep 2009 14:15:57 +0200
From:	Bart Hartgers <bart.hartgers@...il.com>
To:	Greg KH <greg@...ah.com>
Cc:	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	Ondrej Zary <linux@...nbow-software.org>,
	ark3116_driver@...tionant.de
Subject: Re: New ark3116 driver - how to get included into kernel?

Hi Greg,

Thanks for your reply.

2009/9/18 Greg KH <greg@...ah.com>:
> On Thu, Sep 17, 2009 at 02:52:29PM +0200, Bart Hartgers wrote:
>> (Sorry for sending an HTML-ized version of this mail before)
>>
>> Hi All,
>>
>> I managed to write an improved ark3116 driver after I figured out that
>> it is just an 16450 UART with some USB glue logic.
>>
>> The attached files can be compiled outside the kernel tree, and work
>> for 2.6.31. However, I would like this driver to (eventually) end up
>> in the kernel tree. In order to get there, who should I sent patches
>> against what? I've contributed code to the kernel before, but not in
>> the last 5 or so years, so I am a bit out of touch.
>
> Take a look at the file, Documentation/SubmittingPatches, it should
> describe what you need to do.
>
Thanks. But the question I had was more that I didn't know where to
put a new driver. In drivers/usb/serial, or perhaps in
drivers/staging. Anyway, if we are going to replace the existing
driver, it is obvious what the patch should be against.

>> Compared to the old ark3116 driver this one offers the following improvements:
>>  - cts/rts handshake support
>>  - break signalling
>>  - line error detection
>
> Why can't you just send patches adding support for these features to the
> existing driver?  It shouldn't be that much different between the two
> versions, right?

The difference is actually quite significant. The old driver is pretty
much a dumb parameterized replay of the windows usb-snoops. The new
driver actually "understands" the hardware. That's why I made a
completely new driver in the first place. A diff between the two is
ore or less the same as a complete replacing. I could try to minimize
the differences, but I would be surprised if more than 30% of the
lines will be shared, and most of those will be red tape, not actual
code. The patch will be hard to read anyhow.

>
> That's the preferred method, I'd like to not drop the existing one if at
> all possible.
>

Do you think it is worth the effort to minimize the diff, or should I
just replace ark3116.c by ark3116new.c?

Groeten,
Bart

> thanks,
>
> greg k-h
>



-- 
Bart Hartgers - New e-mail: bart.hartgers@...il.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/