On Mon, Sep 28, 2015 at 08:53:49AM -0400, Rob Groner wrote: > On Fri, 2015-09-25 at 17:45 -0700, Greg KH wrote: > > On Fri, Sep 25, 2015 at 03:21:46PM -0400, Rob Groner wrote: > > > > > > On 09/25/2015 03:14 PM, Greg KH wrote: > > > > On Fri, Sep 25, 2015 at 07:08:32PM +0000, Rob Groner wrote: > > > >>> -----Original Message----- > > > >>> From: Greg KH [mailto:[email protected]] > > > >>> Sent: Friday, September 25, 2015 2:37 PM > > > >>> To: Rob Groner <[email protected]> > > > >>> Cc: [email protected]; [email protected] > > > >>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. > > > >>> > > > >>> On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote: > > > >>>>> -----Original Message----- > > > >>>>> From: [email protected] [mailto:[email protected]] > > > >>>>> Sent: Friday, September 25, 2015 12:48 PM > > > >>>>> To: Rob Groner <[email protected]> > > > >>>>> Cc: [email protected] > > > >>>>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. > > > >>>>> > > > >>>>> On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said: > > > >>>>>> Serial boards made by RTD using the Exar XR17V358 chip rely on the > > > >>>>>> extra capabilities of the Exar-provided driver to allow > > > >>>>>> configuration of the board. When support for the Exar chip was > > > >>>>>> added to the kernel 8250_pci driver, this then prevented easy use > > > >>>>>> of the board by customers for anything other than standard serial > > > >>>>>> usage > > > >>> in RS232 mode. > > > >>>>> Was it your intent to also prevent the use of this board in standard > > > >>>>> serial usage in RS232 mode (which I'd expect is the most common use > > > >>> case)? > > > >>>> That is a byproduct of giving the non-average user the ability to > > > >>>> reconfigure their board. This will basically move us back to > > > >>>> pre-3.8, > > > >>>> where the customer would simply have to insmod the provided Exar > > > >>>> driver. The small inconvenience to that more common user seems (to > > > >>>> us > > > >>>> in Tech Support) outweighed by the much greater inconvenience to the > > > >>>> user who wants to reconfigure. > > > >>> Where is the exar driver, in the kernel already? > > > >>> > > > >>> confused, > > > >> I'm sorry for the confusion. Let me summup: > > > >> > > > >> We produce a serial port board that uses the Exar XR17V358 chip. The > > > >> board features a jumperless configuration so that to change the board > > > >> from RS232 to RS422/RS485, you use the GPIO available on the Exar > > > >> chip, via the Exar driver. That driver is provided by Exar (from > > > >> their website, and repackaged on our website and with the board). > > > >> > > > >> Recently, we began to hear from customers who purchased the board but > > > >> could not get the driver to find the board (and thus could not > > > >> reconfigure it, nor use the non-standard high baud rates the chip is > > > >> capable of). We discovered that in 3.8, support for the Exar chip was > > > >> added to the 8250_pci driver, thus binding it to the kernel. > > > >> > > > >> Until (and probably if) Exar decides to submit their driver to the > > > >> kernel, then it leaves us with a problem that we didn't have prior to > > > >> 3.8...namely that the board won't do what it is advertised to do > > > >> unless the customer rebuilds the kernel (that is the only supported > > > >> workaround from Exar). The only other workaround we know of (unbind) > > > >> has met with mixed success which I won't go into unless you want me > > > >> to, and is already resisted by some customers. > > > >> > > > >> The goal of this patch is to get to a point where a customer can > > > >> install Linux and have full use of this RTD board (using the driver > > > >> Exar/RTD provides). No one who has an RTD board is going to feel this > > > >> is an inconvenience. > > > > Can you point me at the driver and I'll be glad to add it to the kernel > > > > so that the proper driver will bind to the device and this will > > > > not be an issue for users? > > > > > > > > thanks, > > > > > > > > greg k-h > > > That would be WONDERFUL. > > > > > > https://www.exar.com/common/content/document.ashx?id=20121 > > > > At first glance, the driver looks pretty good. Let me do a bit of > > cleanup on it for mostly coding style changes and removing some old api > > support and see what the patch is. > > > > Would you mind testing it if I make a patch, given that I don't have the > > hardware and you do? :) > > > > thanks, > > > > greg k-h > > I don't mind in the slightest, it's the least I can do! I've got my > test station ready and have 3 different CPUs I can test with. Being new > to the whole patching thing, I may need a few hints and helps to make > sure I apply the patch correctly... > > Will it be showing up here in kernel newbies mailing list, or > linux-serial, or other?
How about let's take it to linux-serial, and I'll cc: you as well, that's the proper place for this. Note, the driver does do some "odd" things in that it has some "custom" ioctls for unknown reasons, and it grabs a major number of another driver, both things that I can't accept upstream. It also seems to duplicate a lot of existing code, so maybe it doesn't really need to be a separate driver. I'll dig around in it and see what I can come up with, give me a week or so... thanks, greg k-h _______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
