[PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.

[Rob Groner]

> -----Original Message-----
> From: Greg KH [mailto:greg at kroah.com]
> Sent: Monday, September 28, 2015 10:12 AM
> To: Rob Groner <rgroner at RTD.com>
> Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
> 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 at kroah.com]
> > > > >>> Sent: Friday, September 25, 2015 2:37 PM
> > > > >>> To: Rob Groner <rgroner at RTD.com>
> > > > >>> Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
> > > > >>> 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 at vt.edu
> > > > >>>>> [mailto:Valdis.Kletnieks at vt.edu]
> > > > >>>>> Sent: Friday, September 25, 2015 12:48 PM
> > > > >>>>> To: Rob Groner <rgroner at RTD.com>
> > > > >>>>> Cc: kernelnewbies at kernelnewbies.org
> > > > >>>>> 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

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?

Thanks,

Rob Groner