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

[Greg KH]

On Fri, Sep 18, 2009 at 02:15:57PM +0200, Bart Hartgers wrote:
> Hi Greg,
> 
> Thanks for your reply.
> 
> 2009/9/18 Greg KH <greg@xxxxxxxxx>:
> > 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.

Yes, please work on fixing up the existing driver, that's the proper way
to do it.

> >> 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.

Then work on converting the driver over incrementally, one step at a
time, so that the patches are readable and understandable :)

> > 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?

Well, I will not take such a patch, so I would work on the incremental
change version instead.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/