[lkml]   [2009]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: New ark3116 driver - how to get included into kernel?
    Hi Greg,

    Thanks for your reply.

    2009/9/18 Greg KH <>:
    > 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?


    > thanks,
    > greg k-h

    Bart Hartgers - New e-mail:
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-09-18 14:19    [W:0.028 / U:8.240 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site