On Thu, 15 Nov 2012 09:40:54 +1030 Jonathan Woithe <jwoithe@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
