8250_pci: Prevent Exar/RTD Boards from binding.

PATCH New Rob Groner 4 participants 22 messages Sep 25, 2015 – Nov 12, 2015 TTY layer and serial drivers

Share & tools

Rob Groner

author

2015-09-25 15:46 UTC #0 lore raw

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

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.

This patch prevents RTD sub-vendor boards from being bound by the 8250_pci driver, if it uses the XR17V358 chip. Other RTD boards using Exar chips are not affected.

Signed-off-by Rob Groner <[email protected]>

---
 drivers/tty/serial/8250/8250_pci.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

drivers/tty/serial/8250/8250_pci.c +20 -0

index 68042dd..89baf7f 100644
@@ -359,6 +359,16 @@ static void pci_ni8430_exit(struct pci_dev *dev)
 	iounmap(p);
 }
 
+/*
+ * RTD Embedded Technologies, Inc. boards
+ * Prevent from being bound to 8250 driver
+ */
+static int
+pci_xr17v35x_rtd_probe(struct pci_dev *dev)
+{
+	return -ENODEV;
+}
+
 /* SBS Technologies Inc. PMC-OCTPRO and P-OCTAL cards */
 static int
 sbs_setup(struct serial_private *priv, const struct pciserial_board *board,

@@ -2105,6 +2115,8 @@ pci_wch_ch38x_setup(struct serial_private *priv,
 #define PCI_DEVICE_ID_PERICOM_PI7C9X7954	0x7954
 #define PCI_DEVICE_ID_PERICOM_PI7C9X7958	0x7958
 
+#define PCI_SUBVENDOR_ID_RTD		0x1435
+
 /* Unknown vendors/cards - this should not be in linux/pci_ids.h */
 #define PCI_SUBDEVICE_ID_UNKNOWN_0x1584	0x1584
 #define PCI_SUBDEVICE_ID_UNKNOWN_0x1588	0x1588

@@ -2608,6 +2620,14 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
 	{
 		.vendor = PCI_VENDOR_ID_EXAR,
 		.device = PCI_DEVICE_ID_EXAR_XR17V358,
+		.subvendor = PCI_SUBVENDOR_ID_RTD,
+		.subdevice	= PCI_ANY_ID,
+		.probe		= pci_xr17v35x_rtd_probe,
+		.setup		= pci_xr17v35x_setup,
+	},
+	{
+		.vendor = PCI_VENDOR_ID_EXAR,
+		.device = PCI_DEVICE_ID_EXAR_XR17V358,
 		.subvendor	= PCI_ANY_ID,
 		.subdevice	= PCI_ANY_ID,
 		.setup		= pci_xr17v35x_setup,

Signature · 1 line

1.9.1

Valdis.Kletnieks at vt.edu

2015-09-25 16:47 UTC #1 lore raw

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

Quoted 6 lines · Rob Groner

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)?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150925/c19f0fe7/attachment.bin

Rob Groner

author

2015-09-25 17:37 UTC #2 lore raw

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

Quoted 9 lines

-----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 <[email protected]>
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:

Quoted 8 lines

Quoted 5 lines
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.

Rob Groner

Greg KH

2015-09-25 18:37 UTC #3 lore raw

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

Quoted 18 lines · Rob Groner

Quoted 9 lines
-----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 <[email protected]>
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:
Quoted 8 lines
Quoted 5 lines
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)?

Quoted 6 lines

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,

greg k-h

Rob Groner

author

2015-09-25 19:08 UTC #4 lore raw

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

Quoted 35 lines

-----Original Message-----
From: Greg KH [mailto:greg at kroah.com]
Sent: Friday, September 25, 2015 2:37 PM
To: Rob Groner <[email protected]>
Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 8 lines · Rob Groner
Quoted 8 lines
-----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 <[email protected]>
Cc: kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 6 lines
Quoted 6 lines · Rob Groner
Quoted 5 lines
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 3 lines
Quoted 3 lines
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 7 lines
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 3 lines

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.

Thank you,

Rob Groner

Greg KH

2015-09-25 19:14 UTC #5 lore raw

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

Quoted 41 lines · Rob Groner

Quoted 35 lines
-----Original Message-----
From: Greg KH [mailto:greg at kroah.com]
Sent: Friday, September 25, 2015 2:37 PM
To: Rob Groner <[email protected]>
Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 8 lines · Rob Groner
Quoted 8 lines
-----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 <[email protected]>
Cc: kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 6 lines
Quoted 6 lines · Rob Groner
Quoted 5 lines
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 3 lines
Quoted 3 lines
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 7 lines
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 3 lines
Where is the exar driver, in the kernel already?
confused,
I'm sorry for the confusion. Let me summup:

Quoted 7 lines

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

Rob Groner

author

2015-09-25 19:21 UTC #6 lore raw

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

Quoted 43 lines · Greg KH

Quoted 42 lines · Rob Groner
Quoted 31 lines
-----Original Message-----
From: Greg KH [mailto:greg at kroah.com]
Sent: Friday, September 25, 2015 2:37 PM
To: Rob Groner <[email protected]>
Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 7 lines · Rob Groner
Quoted 7 lines
-----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 <[email protected]>
Cc: kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 6 lines
Quoted 6 lines · Rob Groner
Quoted 5 lines
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 2 lines
Quoted 2 lines
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 6 lines
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 3 lines
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.

Quoted 8 lines

Quoted 1 line
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

Thank you,

Rob Groner

Greg KH

2015-09-26 00:45 UTC #7 lore raw

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

Quoted 50 lines · Rob Groner

Quoted 48 lines · Greg KH
Quoted 36 lines · Rob Groner
Quoted 31 lines
-----Original Message-----
From: Greg KH [mailto:greg at kroah.com]
Sent: Friday, September 25, 2015 2:37 PM
To: Rob Groner <[email protected]>
Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 7 lines · Rob Groner
Quoted 7 lines
-----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 <[email protected]>
Cc: kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 6 lines
Quoted 6 lines · Rob Groner
Quoted 5 lines
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 2 lines
Quoted 2 lines
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 6 lines
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 3 lines
Where is the exar driver, in the kernel already?
confused,
I'm sorry for the confusion. Let me summup:
Quoted 7 lines
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?

Quoted 6 lines

Quoted 3 lines
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

Rob Groner

author

2015-09-28 12:53 UTC #8 lore raw

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

Quoted 62 lines · Greg KH

Quoted 50 lines · Rob Groner
Quoted 48 lines · Greg KH
Quoted 36 lines · Rob Groner
Quoted 31 lines
-----Original Message-----
From: Greg KH [mailto:greg at kroah.com]
Sent: Friday, September 25, 2015 2:37 PM
To: Rob Groner <[email protected]>
Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 7 lines · Rob Groner
Quoted 7 lines
-----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 <[email protected]>
Cc: kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 6 lines
Quoted 6 lines · Rob Groner
Quoted 5 lines
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 2 lines
Quoted 2 lines
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 6 lines
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 3 lines
Where is the exar driver, in the kernel already?
confused,
I'm sorry for the confusion. Let me summup:
Quoted 7 lines
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?
Quoted 6 lines
Quoted 3 lines
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.

Quoted 6 lines

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?

Thank you.

Rob Groner

Greg KH

2015-09-28 14:11 UTC #9 lore raw

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

Quoted 70 lines · Rob Groner

Quoted 62 lines · Greg KH
Quoted 50 lines · Rob Groner
Quoted 48 lines · Greg KH
Quoted 36 lines · Rob Groner
Quoted 31 lines
-----Original Message-----
From: Greg KH [mailto:greg at kroah.com]
Sent: Friday, September 25, 2015 2:37 PM
To: Rob Groner <[email protected]>
Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 7 lines · Rob Groner
Quoted 7 lines
-----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 <[email protected]>
Cc: kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 6 lines
Quoted 6 lines · Rob Groner
Quoted 5 lines
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 2 lines
Quoted 2 lines
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 6 lines
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 3 lines
Where is the exar driver, in the kernel already?
confused,
I'm sorry for the confusion. Let me summup:
Quoted 7 lines
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?
Quoted 6 lines
Quoted 3 lines
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.
Quoted 6 lines
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

Quoted 7 lines

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

Rob Groner

author

2015-09-28 15:33 UTC #10 lore raw

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

Quoted 89 lines · Greg KH

Quoted 70 lines · Rob Groner
Quoted 62 lines · Greg KH
Quoted 50 lines · Rob Groner
Quoted 48 lines · Greg KH
Quoted 36 lines · Rob Groner
Quoted 31 lines
-----Original Message-----
From: Greg KH [mailto:greg at kroah.com]
Sent: Friday, September 25, 2015 2:37 PM
To: Rob Groner <[email protected]>
Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 7 lines · Rob Groner
Quoted 7 lines
-----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 <[email protected]>
Cc: kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 6 lines
Quoted 6 lines · Rob Groner
Quoted 5 lines
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 2 lines
Quoted 2 lines
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 6 lines
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 3 lines
Where is the exar driver, in the kernel already?
confused,
I'm sorry for the confusion. Let me summup:
Quoted 7 lines
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?
Quoted 6 lines
Quoted 3 lines
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.
Quoted 6 lines
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
Quoted 7 lines
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 3 lines

thanks,
greg k-h

Ok, I'll keep an eye out for it.

Thanks for the effort you've offered and I'll help how I can.

Rob Groner

author

2015-10-26 12:28 UTC #11 lore raw

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

In reply to Greg KH

Quoted 118 lines

-----Original Message-----
From: Greg KH [mailto:greg at kroah.com]
Sent: Monday, September 28, 2015 10:12 AM
To: Rob Groner <[email protected]>
Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 11 lines · Rob Groner
Quoted 10 lines · Greg KH
Quoted 9 lines · Rob Groner
Quoted 7 lines · Greg KH
Quoted 6 lines · Rob Groner
Quoted 6 lines
-----Original Message-----
From: Greg KH [mailto:greg at kroah.com]
Sent: Friday, September 25, 2015 2:37 PM
To: Rob Groner <[email protected]>
Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from
binding.
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines · Rob Groner
Quoted 7 lines
Quoted 7 lines
-----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 <[email protected]>
Cc: kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from
binding.
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 8 lines
Quoted 8 lines · Rob Groner
Quoted 6 lines
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 3 lines
Quoted 3 lines
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
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
case)?
Quoted 6 lines
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 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
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 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
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 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
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 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
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 22 lines
Quoted 15 lines
Quoted 10 lines
Quoted 7 lines
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.
Quoted 6 lines
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
Quoted 7 lines
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 3 lines

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

author

2015-11-11 15:46 UTC #12 lore raw

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

Quoted 138 lines

-----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 <[email protected]>
Cc: kernelnewbies at kernelnewbies.org
Subject: RE: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 78 lines
-----Original Message-----
From: Greg KH [mailto:greg at kroah.com]
Sent: Monday, September 28, 2015 10:12 AM
To: Rob Groner <[email protected]>
Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 11 lines · Rob Groner
Quoted 10 lines · Greg KH
Quoted 9 lines · Rob Groner
Quoted 7 lines · Greg KH
Quoted 6 lines · Rob Groner
Quoted 6 lines
-----Original Message-----
From: Greg KH [mailto:greg at kroah.com]
Sent: Friday, September 25, 2015 2:37 PM
To: Rob Groner <[email protected]>
Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from
binding.
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines · Rob Groner
Quoted 8 lines
Quoted 8 lines
-----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 <[email protected]>
Cc: kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from
binding.
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 8 lines
Quoted 8 lines · Rob Groner
Quoted 6 lines
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 3 lines
Quoted 3 lines
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
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
case)?
Quoted 7 lines
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 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
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 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
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 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 16 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
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 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 7 lines
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 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
ta=01%7c01%7crgroner%40rtd.com%7c261e5150b71d4b17e91308d2de03148
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
e%7c16f82b7977b8423dbafdd6c19032e267%7c0&sdata=Tl%2br4Vjgut%2bRh
Quoted 21 lines
Quoted 13 lines
Quoted 6 lines
Quoted 1 line
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.
Quoted 6 lines
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
Quoted 7 lines
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?
Quoted 8 lines
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,

Quoted 8 lines

give me a week or so...
Quoted 4 lines
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.

Greg KH

2015-11-11 17:32 UTC #13 lore raw

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

Quoted 142 lines · Rob Groner

Quoted 142 lines
-----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 <[email protected]>
Cc: kernelnewbies at kernelnewbies.org
Subject: RE: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 78 lines
-----Original Message-----
From: Greg KH [mailto:greg at kroah.com]
Sent: Monday, September 28, 2015 10:12 AM
To: Rob Groner <[email protected]>
Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 11 lines · Rob Groner
Quoted 10 lines · Greg KH
Quoted 9 lines · Rob Groner
Quoted 7 lines · Greg KH
Quoted 6 lines · Rob Groner
Quoted 6 lines
-----Original Message-----
From: Greg KH [mailto:greg at kroah.com]
Sent: Friday, September 25, 2015 2:37 PM
To: Rob Groner <[email protected]>
Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from
binding.
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines · Rob Groner
Quoted 8 lines
Quoted 8 lines
-----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 <[email protected]>
Cc: kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from
binding.
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 8 lines
Quoted 8 lines · Rob Groner
Quoted 6 lines
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 3 lines
Quoted 3 lines
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
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
case)?
Quoted 7 lines
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 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
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 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
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 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 16 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
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 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 7 lines
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 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
ta=01%7c01%7crgroner%40rtd.com%7c261e5150b71d4b17e91308d2de03148
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
e%7c16f82b7977b8423dbafdd6c19032e267%7c0&sdata=Tl%2br4Vjgut%2bRh
Quoted 21 lines
Quoted 13 lines
Quoted 6 lines
Quoted 1 line
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.
Quoted 6 lines
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
Quoted 7 lines
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?
Quoted 8 lines
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 3 lines
thanks,

Quoted 7 lines

Quoted 4 lines
Quoted 1 line
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

Rob Groner

author

2015-11-11 18:15 UTC #14 lore raw

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

Quoted 172 lines

-----Original Message-----
From: Greg KH [mailto:greg at kroah.com]
Sent: Wednesday, November 11, 2015 12:32 PM
To: Rob Groner <[email protected]>
Cc: kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 3 lines · Rob Groner
Quoted 3 lines
-----Original Message-----
From: kernelnewbies-bounces at kernelnewbies.org
[mailto:kernelnewbies-
Quoted 61 lines
Quoted 61 lines
bounces at kernelnewbies.org] On Behalf Of Rob Groner
Sent: Monday, October 26, 2015 8:28 AM
To: Greg KH <[email protected]>
Cc: kernelnewbies at kernelnewbies.org
Subject: RE: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 55 lines
-----Original Message-----
From: Greg KH [mailto:greg at kroah.com]
Sent: Monday, September 28, 2015 10:12 AM
To: Rob Groner <[email protected]>
Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 5 lines · Rob Groner
Quoted 4 lines · Greg KH
Quoted 3 lines · Rob Groner
Quoted 1 line · Greg KH
On Fri, Sep 25, 2015 at 07:08:32PM +0000, Rob Groner wrote:
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
-----Original Message-----
From: Greg KH [mailto:greg at kroah.com]
Sent: Friday, September 25, 2015 2:37 PM
To: Rob Groner <[email protected]>
Cc: Valdis.Kletnieks at vt.edu;
kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from
binding.
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines · Rob Groner
Quoted 8 lines
Quoted 8 lines
-----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 <[email protected]>
Cc: kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from
binding.
Quoted 22 lines
Quoted 22 lines
Quoted 22 lines
Quoted 22 lines
Quoted 22 lines
Quoted 22 lines
Quoted 9 lines
Quoted 9 lines · Rob Groner
Quoted 7 lines
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 3 lines
Quoted 3 lines
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 8 lines
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
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
wants to reconfigure.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
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.
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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 21 lines
Quoted 21 lines
Quoted 21 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
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,
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 1 line
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&
Quoted 3 lines
Quoted 3 lines
da
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
ta=01%7c01%7crgroner%40rtd.com%7c261e5150b71d4b17e91308d2de03148
Quoted 2 lines
Quoted 2 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
e%7c16f82b7977b8423dbafdd6c19032e267%7c0&sdata=Tl%2br4Vjgut%2bRh
Quoted 18 lines
Quoted 18 lines
Quoted 18 lines
Quoted 18 lines
Quoted 6 lines
Quoted 1 line
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.
Quoted 6 lines
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...
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 2 lines
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"
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
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,
Quoted 7 lines
Quoted 7 lines
give me a week or so...
Quoted 4 lines
thanks,
greg k-h
I know you're incredibly busy, so I added as much "so" to the week as I
could.
Quoted 2 lines
Quoted 1 line
Any way I can help with this endeavor, other than testing?

Quoted 8 lines

Quoted 1 line
Would it be possible to consider my original patch, if putting in the Exar
driver is too time consuming?
Quoted 1 line
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

My patch prevented RTD-subvendor boards that have the Exar serial chip on them from being bound to the kernel 8250_pci driver. That allows our customers to insert the Exar-provided driver which then gives them access to configuring the board.

You asked for a link to the Exar driver, and you graciously offered to put the driver into the kernel, which would also solve our problem.

Thank you,

Rob G.

Sudip Mukherjee

2015-11-11 18:20 UTC #15 lore raw

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

In reply to Greg KH

Quoted 3 lines · Greg KH

Quoted 1 line · Rob Groner

<snip>

Quoted 11 lines

Quoted 1 line
Quoted 1 line
I know you're incredibly busy, so I added as much "so" to the week as
I could.
Quoted 3 lines
Quoted 1 line
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?
Quoted 1 line
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.

Hi Greg,
Quoting from your old reply

Quoted 2 lines

Quoted 2 lines
Quoted 2 lines
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

Quoted 1 line

Quoted 1 line
Quoted 1 line
support and see what the patch is.

We all know you are busy. If you want I can try the cleanup and send it to Rob
for testing.

Regards
sudip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151111/b29115b1/attachment.html

Greg KH

2015-11-11 21:41 UTC #16 lore raw

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

Quoted 19 lines · Sudip Mukherjee

On Wed, Nov 11, 2015 at 11:02 PM, Greg KH <[email protected]> wrote:
    On Wed, Nov 11, 2015 at 03:46:23PM +0000, Rob Groner wrote:
    >
<snip>
Quoted 1 line
Quoted 1 line
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.

Quoted 8 lines

Hi Greg,
Quoting from your old reply
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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.
We all know you are busy. If you want I can try the cleanup and send it to Rob for testing.

Yes please, it should just require a change to the existing 8250 driver code for this platform, it should not be a stand-alone driver.

thanks,

greg k-h

Rob Groner

author

2015-11-11 21:49 UTC #17 lore raw

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

Quoted 38 lines

-----Original Message-----
From: Greg KH [mailto:greg at kroah.com]
Sent: Wednesday, November 11, 2015 4:41 PM
To: Sudip Mukherjee <[email protected]>
Cc: Rob Groner <[email protected]>; kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 8 lines · Sudip Mukherjee
On Wed, Nov 11, 2015 at 11:02 PM, Greg KH <[email protected]> wrote:
    On Wed, Nov 11, 2015 at 03:46:23PM +0000, Rob Groner wrote:
    >
<snip>
Quoted 1 line
Quoted 1 line
I know you're incredibly busy, so I added as much "so" to the week as
I
Quoted 11 lines
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.
Quoted 8 lines
Hi Greg,
Quoting from your old reply
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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.
We all know you are busy. If you want I can try the cleanup and send it to Rob for testing.

Quoted 6 lines

Yes please, it should just require a change to the existing 8250 driver code for this platform, it should not be a stand-alone driver.
thanks,
greg k-h

I'm a little confused by that, but I'm happily standing by, ready to test the result, or any other way I can help.

As long as our boards that use the Exar chip aren't sucked up by the kernel 8250 driver, then mission accomplished!

Rob G.

Greg KH

2015-11-11 22:13 UTC #18 lore raw

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

Quoted 8 lines · Rob Groner

Quoted 8 lines
Quoted 2 lines
We all know you are busy. If you want I can try the cleanup and send it to Rob for testing.
Yes please, it should just require a change to the existing 8250 driver code for this platform, it should not be a stand-alone driver.
thanks,

Quoted 7 lines

Quoted 1 line
greg k-h
I'm a little confused by that, but I'm happily standing by, ready to test the result, or any other way I can help.
As long as our boards that use the Exar chip aren't sucked up by the kernel 8250 driver, then mission accomplished!

It should be sucked up by the 8250 driver, the driver they posted is just a fork of the existing driver with a few small, odd, modifications. the 8250 framework is _so_ flexible that I'm sure it can support this hardware as-is, the hardware just needs to be properly described to the driver.

The last time I did this, it took 2 days of reading the driver and figuring it all out, and then only 16 new lines of code/tables added to the driver to support a new device that was a bit "odd" from a normal uart. I expect the same thing would be needed here, but maybe more lines of code :)

thanks,

greg k-h

Rob Groner

author

2015-11-12 13:28 UTC #19 lore raw

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

Quoted 31 lines

-----Original Message-----
From: Greg KH [mailto:greg at kroah.com]
Sent: Wednesday, November 11, 2015 5:13 PM
To: Rob Groner <[email protected]>
Cc: Sudip Mukherjee <[email protected]>; kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 8 lines · Rob Groner
Quoted 8 lines
Quoted 2 lines
We all know you are busy. If you want I can try the cleanup and send it to Rob for testing.
Yes please, it should just require a change to the existing 8250 driver code for this platform, it should not be a stand-alone driver.
thanks,
Quoted 7 lines
Quoted 1 line
greg k-h
I'm a little confused by that, but I'm happily standing by, ready to test the result, or any other way I can help.
As long as our boards that use the Exar chip aren't sucked up by the kernel 8250 driver, then mission accomplished!
It should be sucked up by the 8250 driver, the driver they posted is just a fork of the existing driver with a few small, odd, modifications.
the 8250 framework is _so_ flexible that I'm sure it can support this hardware as-is, the hardware just needs to be properly described to the driver.

Quoted 8 lines

The last time I did this, it took 2 days of reading the driver and figuring it all out, and then only 16 new lines of code/tables added to the driver to support a new device that was a bit "odd" from a normal uart. I expect the same thing would be needed here, but maybe more lines of code :)
thanks,
greg k-h

Oooo, ok. Fantastic! Testing is standing by.

Rob G

Greg KH

2015-09-25 17:18 UTC #20 lore raw

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

In reply to Rob Groner

Quoted 47 lines · Rob Groner

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.
This patch prevents RTD sub-vendor boards from being bound by the 8250_pci driver, if it uses the XR17V358 chip. Other RTD boards using Exar chips are not affected.
Signed-off-by Rob Groner <[email protected]>
---
 drivers/tty/serial/8250/8250_pci.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
drivers/tty/serial/8250/8250_pci.c +12 -0
index 68042dd..89baf7f 100644
@@ -359,6 +359,16 @@ static void pci_ni8430_exit(struct pci_dev *dev)
 	iounmap(p);
 }
 
+/*
+ * RTD Embedded Technologies, Inc. boards
+ * Prevent from being bound to 8250 driver
+ */
+static int
+pci_xr17v35x_rtd_probe(struct pci_dev *dev)
+{
+	return -ENODEV;
+}
+
 /* SBS Technologies Inc. PMC-OCTPRO and P-OCTAL cards */
 static int
 sbs_setup(struct serial_private *priv, const struct pciserial_board *board,
@@ -2105,6 +2115,8 @@ pci_wch_ch38x_setup(struct serial_private *priv,
 #define PCI_DEVICE_ID_PERICOM_PI7C9X7954	0x7954
 #define PCI_DEVICE_ID_PERICOM_PI7C9X7958	0x7958
 
+#define PCI_SUBVENDOR_ID_RTD		0x1435
+
 /* Unknown vendors/cards - this should not be in linux/pci_ids.h */
 #define PCI_SUBDEVICE_ID_UNKNOWN_0x1584	0x1584
 #define PCI_SUBDEVICE_ID_UNKNOWN_0x1588	0x1588

drivers/tty/serial/8250/8250_pci.c static struct pci_serial_quirk pci_serial_quirks[] __refdata = { · line 2626

Quoted 7 lines

drivers/tty/serial/8250/8250_pci.c +4 -0

@@ -2608,6 +2620,14 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
 	{
 		.vendor = PCI_VENDOR_ID_EXAR,
 		.device = PCI_DEVICE_ID_EXAR_XR17V358,
+		.subvendor = PCI_SUBVENDOR_ID_RTD,
+		.subdevice	= PCI_ANY_ID,
+		.probe		= pci_xr17v35x_rtd_probe,
+		.setup		= pci_xr17v35x_setup,

Why do you need the .setup callback if you are just not wanting to bind to this driver?

thanks,

greg k-h

Rob Groner

author

2015-09-25 17:30 UTC #21 lore raw

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

Quoted 54 lines

-----Original Message-----
From: Greg KH [mailto:greg at kroah.com]
Sent: Friday, September 25, 2015 1:19 PM
To: Rob Groner <[email protected]>
Cc: kernelnewbies at kernelnewbies.org
Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
Quoted 32 lines · Rob Groner
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.
This patch prevents RTD sub-vendor boards from being bound by the 8250_pci driver, if it uses the XR17V358 chip. Other RTD boards using Exar chips are not affected.
Signed-off-by Rob Groner <[email protected]>
---
 drivers/tty/serial/8250/8250_pci.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
drivers/tty/serial/8250/8250_pci.c +7 -0
index 68042dd..89baf7f 100644
@@ -359,6 +359,16 @@ static void pci_ni8430_exit(struct pci_dev *dev)
 	iounmap(p);
 }
 
+/*
+ * RTD Embedded Technologies, Inc. boards
+ * Prevent from being bound to 8250 driver  */ static int
+pci_xr17v35x_rtd_probe(struct pci_dev *dev) {
+	return -ENODEV;
+}
+
 /* SBS Technologies Inc. PMC-OCTPRO and P-OCTAL cards */  static int
Quoted 2 lines
sbs_setup(struct serial_private *priv, const struct pciserial_board *board, @@ -2105,6 +2115,8 @@ pci_wch_ch38x_setup(struct
serial_private *priv,
drivers/tty/serial/8250/8250_pci.c static struct pci_serial_quirk pci_serial_quirks[]
Quoted 9 lines
#define PCI_DEVICE_ID_PERICOM_PI7C9X7954 0x7954
#define PCI_DEVICE_ID_PERICOM_PI7C9X7958 0x7958
drivers/tty/serial/8250/8250_pci.c +2 -0
+#define PCI_SUBVENDOR_ID_RTD		0x1435
+
 /* Unknown vendors/cards - this should not be in linux/pci_ids.h */
 #define PCI_SUBDEVICE_ID_UNKNOWN_0x1584	0x1584
 #define PCI_SUBDEVICE_ID_UNKNOWN_0x1588	0x1588
@@ -2608,6 +2620,14 @@ static struct pci_serial_quirk pci_serial_quirks[]
__refdata = {

Quoted 11 lines

drivers/tty/serial/8250/8250_pci.c static struct pci_serial_quirk pci_serial_quirks[] __refdata = { · line 2626
Quoted 7 lines
drivers/tty/serial/8250/8250_pci.c +4 -0
 	{
 		.vendor = PCI_VENDOR_ID_EXAR,
 		.device = PCI_DEVICE_ID_EXAR_XR17V358,
+		.subvendor = PCI_SUBVENDOR_ID_RTD,
+		.subdevice	= PCI_ANY_ID,
+		.probe		= pci_xr17v35x_rtd_probe,
+		.setup		= pci_xr17v35x_setup,
Why do you need the .setup callback if you are just not wanting to bind to this driver?

You're right, that doesn't need to be set.

Rob Groner