Thread (22 messages) 22 messages, 4 authors, 2015-11-12
STALE3894d

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

From: Greg KH <hidden>
Date: 2015-11-11 17:32:11

On Wed, Nov 11, 2015 at 03:46:23PM +0000, Rob Groner wrote:
quoted
-----Original Message-----
From: kernelnewbies-bounces at kernelnewbies.org [mailto:kernelnewbies-
bounces at kernelnewbies.org] On Behalf Of Rob Groner
Sent: Monday, October 26, 2015 8:28 AM
To: Greg KH <redacted>
Cc: kernelnewbies at kernelnewbies.org
Subject: RE: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
quoted
-----Original Message-----
From: Greg KH [mailto:greg at kroah.com]
Sent: Monday, September 28, 2015 10:12 AM
To: Rob Groner <redacted>
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:
quoted
On Fri, 2015-09-25 at 17:45 -0700, Greg KH wrote:
quoted
On Fri, Sep 25, 2015 at 03:21:46PM -0400, Rob Groner wrote:
quoted
On 09/25/2015 03:14 PM, Greg KH wrote:
quoted
On Fri, Sep 25, 2015 at 07:08:32PM +0000, Rob Groner wrote:
quoted
quoted
-----Original Message-----
From: Greg KH [mailto:greg at kroah.com]
Sent: Friday, September 25, 2015 2:37 PM
To: Rob Groner <redacted>
Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from
binding.
quoted
quoted
quoted
quoted
quoted
quoted
On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote:
quoted
quoted
-----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 <redacted>
Cc: kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards
from
binding.
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said:
quoted
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.
quoted
quoted
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)?
quoted
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.
quoted
quoted
quoted
quoted
quoted
quoted
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).
quoted
quoted
quoted
quoted
quoted
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.
quoted
quoted
quoted
quoted
quoted
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.
quoted
quoted
quoted
quoted
quoted
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.
quoted
quoted
quoted
quoted
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
quoted
quoted
quoted
quoted
ta=01%7c01%7crgroner%40rtd.com%7c261e5150b71d4b17e91308d2de03148
quoted
quoted
quoted
quoted
e%7c16f82b7977b8423dbafdd6c19032e267%7c0&sdata=Tl%2br4Vjgut%2bRh
quoted
quoted
quoted
quoted
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...
quoted
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.
I don't remember what your "original patch" was, sorry.

greg k-h
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help