> -----Original Message----- > From: kernelnewbies-bounces@xxxxxxxxxxxxxxxxx [mailto:kernelnewbies- > bounces@xxxxxxxxxxxxxxxxx] On Behalf Of Rob Groner > Sent: Monday, October 26, 2015 8:28 AM > To: Greg KH <greg@xxxxxxxxx> > Cc: kernelnewbies@xxxxxxxxxxxxxxxxx > Subject: RE: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. > > > -----Original Message----- > > From: Greg KH [mailto:greg@xxxxxxxxx] > > Sent: Monday, September 28, 2015 10:12 AM > > To: Rob Groner <rgroner@xxxxxxx> > > Cc: Valdis.Kletnieks@xxxxxx; kernelnewbies@xxxxxxxxxxxxxxxxx > > Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. > > > > 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:greg@xxxxxxxxx] > > > > > >>> Sent: Friday, September 25, 2015 2:37 PM > > > > > >>> To: Rob Groner <rgroner@xxxxxxx> > > > > > >>> Cc: Valdis.Kletnieks@xxxxxx; kernelnewbies@xxxxxxxxxxxxxxxxx > > > > > >>> 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: Valdis.Kletnieks@xxxxxx > > > > > >>>>> [mailto:Valdis.Kletnieks@xxxxxx] > > > > > >>>>> Sent: Friday, September 25, 2015 12:48 PM > > > > > >>>>> To: Rob Groner <rgroner@xxxxxxx> > > > > > >>>>> Cc: kernelnewbies@xxxxxxxxxxxxxxxxx > > > > > >>>>> 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://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2 > > > > > > fwww.exar.com%2fcommon%2fcontent%2fdocument.ashx%3fid%3d20121& > da > > > > > > ta=01%7c01%7crgroner%40rtd.com%7c261e5150b71d4b17e91308d2de03148 > > > > > > e%7c16f82b7977b8423dbafdd6c19032e267%7c0&sdata=Tl%2br4Vjgut%2bRh > > > > > 3nam6wTMwbpBDpqIW%2fb2dzsTJtE0A4%3d > > > > > > > > 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 > > I know you're incredibly busy, so I added as much "so" to the week as I could. > Any way I can help with this endeavor, other than testing? Would it be possible to consider my original patch, if putting in the Exar driver is too time consuming? I'd rather have the Exar driver than my patch, but I'd also rather have my patch than the current situation. Thanks still for the offer of submitting the driver. Rob G. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
