Re: Comments requested: driver for Quatech PCI serial cards

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

On Thu, 15 Nov 2012 09:40:54 +1030
Jonathan Woithe <jwoithe@just42.net> wrote:

> On Wed, Nov 14, 2012 at 12:12:22PM +0000, Alan Cox wrote:
> > >  - the name of the module.  Anything with "qt" in it will confuse people.
> > >    I'm thinking along the lines of serial-quatech or quatech-serial:
> > >    comments welcome.
> > 
> > qt is fine in kernel - just be careful of the qt usb module.
> 
> Ok.
> 
> > I think in the same place I'd start by just adding the needed identifiers
> > to the 8250_pci driver along with any needed init helper.
> 
> Is this in relation to the proposed signal routing API?

No in relation to throwing that driver away and doing it right.

> supplied by Quatech (which are not opensource unfortunately) will not be
> compatible with the new driver, necessitating the writing of new replacement
> userspace utilities.

tragedy 8)

> > As far as I can see the issues are
> > 
> > 1.	Clock multiplier feature
> > 
> > Supportable by flags in 8250.c and worst case by providing a custom
> > set_termios. No API needed.
> > 
> > 2.	RS485/RS422 options
> > 
> > Supportable by adding TIOCRS485 handling/callout to 8250.c (needs doing
> > anyway)
> 
> Based on this, is it fair to say that the driver in its current basic form
> (clean-ups notwithstanding) cannot be considered for inclusion in mainline?

It is.

> our upcoming system.  I'm guessing that the difficulties with the driver as
> it's currently structured may have been the reason it was never pushed to
> mainline by the original author in 2007.

There are not many difficulties I can see. You just add the identifiers
to the 8250_pci tables and a couple of small bits of code and everything
but the RS422/485 stuff just works.

If you need the RS422 stuff then yes its a bit more work.

Alan