[PATCH] 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 <rgroner@rtd.com> --- drivers/tty/serial/8250/8250_pci.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c index 68042dd..89baf7f 100644 --- a/drivers/tty/serial/8250/8250_pci.c +++ b/drivers/tty/serial/8250/8250_pci.c @@ -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, -- 1.9.1
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)?
-----Original Message----- From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Friday, September 25, 2015 12:48 PM To: Rob Groner <rgroner@RTD.com> Cc: kernelnewbies@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. Rob Groner
On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote:
-----Original Message----- From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Friday, September 25, 2015 12:48 PM To: Rob Groner <rgroner@RTD.com> Cc: kernelnewbies@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, greg k-h
-----Original Message----- From: Greg KH [mailto:greg@kroah.com] Sent: Friday, September 25, 2015 2:37 PM To: Rob Groner <rgroner@RTD.com> Cc: Valdis.Kletnieks@vt.edu; kernelnewbies@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@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Friday, September 25, 2015 12:48 PM To: Rob Groner <rgroner@RTD.com> Cc: kernelnewbies@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. Thank you, Rob Groner
On Fri, Sep 25, 2015 at 11:46:29AM -0400, Rob Groner wrote:
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 <rgroner@rtd.com> --- drivers/tty/serial/8250/8250_pci.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c index 68042dd..89baf7f 100644 --- a/drivers/tty/serial/8250/8250_pci.c +++ b/drivers/tty/serial/8250/8250_pci.c @@ -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,
Why do you need the .setup callback if you are just not wanting to bind to this driver? thanks, greg k-h
-----Original Message----- From: Greg KH [mailto:greg@kroah.com] Sent: Friday, September 25, 2015 1:19 PM To: Rob Groner <rgroner@RTD.com> Cc: kernelnewbies@kernelnewbies.org Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
On Fri, Sep 25, 2015 at 11:46:29AM -0400, Rob Groner wrote:
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 <rgroner@rtd.com> --- drivers/tty/serial/8250/8250_pci.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c index 68042dd..89baf7f 100644 --- a/drivers/tty/serial/8250/8250_pci.c +++ b/drivers/tty/serial/8250/8250_pci.c @@ -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,
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
participants (4)
-
Greg KH -
Rob Groner -
Rob Groner
-
Valdis.Kletnieks＠vt.edu