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

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

[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 <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

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

[Valdis.Kletnieks at vt.edu]

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)?
-------------- 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 

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

[Greg KH]

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

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

[Rob Groner]

> -----Original Message-----
> From: Greg KH [mailto:greg at kroah.com]
> Sent: Friday, September 25, 2015 1:19 PM
> To: Rob Groner <rgroner@RTD.com>
> Cc: kernelnewbies at 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

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

[Rob Groner]

> -----Original Message-----
> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu]
> Sent: Friday, September 25, 2015 12:48 PM
> To: Rob Groner <rgroner@RTD.com>
> Cc: kernelnewbies at kernelnewbies.org
> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
> 
> On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said:
> > Serial boards made by RTD using the Exar XR17V358 chip rely on the
> > extra capabilities of the Exar-provided driver to allow configuration
> > of the board.  When support for the Exar chip was added to the kernel
> > 8250_pci driver, this then prevented easy use of the board by
> > customers for anything other than standard serial usage in RS232 mode.
> 
> Was it your intent to also prevent the use of this board in standard serial
> usage in RS232 mode (which I'd expect is the most common use case)?

That is a byproduct of giving the non-average user the ability to reconfigure their board.  This will basically move us back to pre-3.8, where the customer would simply have to insmod the provided Exar driver.  The small inconvenience to that more common user seems (to us in Tech Support) outweighed by the much greater inconvenience to the user who wants to reconfigure.

Rob Groner

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

[Greg KH]

On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote:
> 
> > -----Original Message-----
> > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu]
> > Sent: Friday, September 25, 2015 12:48 PM
> > To: Rob Groner <rgroner@RTD.com>
> > Cc: kernelnewbies at kernelnewbies.org
> > Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
> > 
> > On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said:
> > > Serial boards made by RTD using the Exar XR17V358 chip rely on the
> > > extra capabilities of the Exar-provided driver to allow configuration
> > > of the board.  When support for the Exar chip was added to the kernel
> > > 8250_pci driver, this then prevented easy use of the board by
> > > customers for anything other than standard serial usage in RS232 mode.
> > 
> > Was it your intent to also prevent the use of this board in standard serial
> > usage in RS232 mode (which I'd expect is the most common use case)?
> 
> That is a byproduct of giving the non-average user the ability to
> reconfigure their board.  This will basically move us back to pre-3.8,
> where the customer would simply have to insmod the provided Exar
> driver.  The small inconvenience to that more common user seems (to us
> in Tech Support) outweighed by the much greater inconvenience to the
> user who wants to reconfigure.

Where is the exar driver, in the kernel already?

confused,

greg k-h

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

[Rob Groner]

> -----Original Message-----
> From: Greg KH [mailto:greg at kroah.com]
> Sent: Friday, September 25, 2015 2:37 PM
> To: Rob Groner <rgroner@RTD.com>
> Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
> 
> On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote:
> >
> > > -----Original Message-----
> > > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu]
> > > Sent: Friday, September 25, 2015 12:48 PM
> > > To: Rob Groner <rgroner@RTD.com>
> > > Cc: kernelnewbies at kernelnewbies.org
> > > Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
> > >
> > > On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said:
> > > > Serial boards made by RTD using the Exar XR17V358 chip rely on the
> > > > extra capabilities of the Exar-provided driver to allow
> > > > configuration of the board.  When support for the Exar chip was
> > > > added to the kernel 8250_pci driver, this then prevented easy use
> > > > of the board by customers for anything other than standard serial usage
> in RS232 mode.
> > >
> > > Was it your intent to also prevent the use of this board in standard
> > > serial usage in RS232 mode (which I'd expect is the most common use
> case)?
> >
> > That is a byproduct of giving the non-average user the ability to
> > reconfigure their board.  This will basically move us back to pre-3.8,
> > where the customer would simply have to insmod the provided Exar
> > driver.  The small inconvenience to that more common user seems (to us
> > in Tech Support) outweighed by the much greater inconvenience to the
> > user who wants to reconfigure.
> 
> Where is the exar driver, in the kernel already?
> 
> confused,

I'm sorry for the confusion.  Let me summup:

We produce a serial port board that uses the Exar XR17V358 chip.  The board features a jumperless configuration so that to change the board from RS232 to RS422/RS485, you use the GPIO available on the Exar chip, via the Exar driver.  That driver is provided by Exar (from their website, and repackaged on our website and with the board).

Recently, we began to hear from customers who purchased the board but could not get the driver to find the board (and thus could not reconfigure it, nor use the non-standard high baud rates the chip is capable of).  We discovered that in 3.8, support for the Exar chip was added to the 8250_pci driver, thus binding it to the kernel.

Until (and probably if) Exar decides to submit their driver to the kernel, then it leaves us with a problem that we didn't have prior to 3.8...namely that the board won't do what it is advertised to do unless the customer rebuilds the kernel (that is the only supported workaround from Exar).  The only other workaround we know of (unbind) has met with mixed success which I won't go into unless you want me to, and is already resisted by some customers.

The goal of this patch is to get to a point where a customer can install Linux and have full use of this RTD board (using the driver Exar/RTD provides).  No one who has an RTD board is going to feel this is an inconvenience.

Thank you,

Rob Groner

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

[Greg KH]

On Fri, Sep 25, 2015 at 07:08:32PM +0000, Rob Groner wrote:
> > -----Original Message-----
> > From: Greg KH [mailto:greg at kroah.com]
> > Sent: Friday, September 25, 2015 2:37 PM
> > To: Rob Groner <rgroner@RTD.com>
> > Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
> > Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
> > 
> > On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote:
> > >
> > > > -----Original Message-----
> > > > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu]
> > > > Sent: Friday, September 25, 2015 12:48 PM
> > > > To: Rob Groner <rgroner@RTD.com>
> > > > Cc: kernelnewbies at kernelnewbies.org
> > > > Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
> > > >
> > > > On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said:
> > > > > Serial boards made by RTD using the Exar XR17V358 chip rely on the
> > > > > extra capabilities of the Exar-provided driver to allow
> > > > > configuration of the board.  When support for the Exar chip was
> > > > > added to the kernel 8250_pci driver, this then prevented easy use
> > > > > of the board by customers for anything other than standard serial usage
> > in RS232 mode.
> > > >
> > > > Was it your intent to also prevent the use of this board in standard
> > > > serial usage in RS232 mode (which I'd expect is the most common use
> > case)?
> > >
> > > That is a byproduct of giving the non-average user the ability to
> > > reconfigure their board.  This will basically move us back to pre-3.8,
> > > where the customer would simply have to insmod the provided Exar
> > > driver.  The small inconvenience to that more common user seems (to us
> > > in Tech Support) outweighed by the much greater inconvenience to the
> > > user who wants to reconfigure.
> > 
> > Where is the exar driver, in the kernel already?
> > 
> > confused,
> 
> I'm sorry for the confusion.  Let me summup:
> 
> We produce a serial port board that uses the Exar XR17V358 chip.  The board features a jumperless configuration so that to change the board from RS232 to RS422/RS485, you use the GPIO available on the Exar chip, via the Exar driver.  That driver is provided by Exar (from their website, and repackaged on our website and with the board).
> 
> Recently, we began to hear from customers who purchased the board but could not get the driver to find the board (and thus could not reconfigure it, nor use the non-standard high baud rates the chip is capable of).  We discovered that in 3.8, support for the Exar chip was added to the 8250_pci driver, thus binding it to the kernel.
> 
> Until (and probably if) Exar decides to submit their driver to the kernel, then it leaves us with a problem that we didn't have prior to 3.8...namely that the board won't do what it is advertised to do unless the customer rebuilds the kernel (that is the only supported workaround from Exar).  The only other workaround we know of (unbind) has met with mixed success which I won't go into unless you want me to, and is already resisted by some customers.
> 
> The goal of this patch is to get to a point where a customer can install Linux and have full use of this RTD board (using the driver Exar/RTD provides).  No one who has an RTD board is going to feel this is an inconvenience.

Can you point me at the driver and I'll be glad to add it to the kernel
so that the proper driver will bind to the device and this will
not be an issue for users?

thanks,

greg k-h

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

[Rob Groner]

On 09/25/2015 03:14 PM, Greg KH wrote:
> On Fri, Sep 25, 2015 at 07:08:32PM +0000, Rob Groner wrote:
>>> -----Original Message-----
>>> From: Greg KH [mailto:greg at kroah.com]
>>> Sent: Friday, September 25, 2015 2:37 PM
>>> To: Rob Groner <rgroner@RTD.com>
>>> Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
>>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
>>>
>>> On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote:
>>>>> -----Original Message-----
>>>>> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu]
>>>>> Sent: Friday, September 25, 2015 12:48 PM
>>>>> To: Rob Groner <rgroner@RTD.com>
>>>>> Cc: kernelnewbies at kernelnewbies.org
>>>>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
>>>>>
>>>>> On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said:
>>>>>> Serial boards made by RTD using the Exar XR17V358 chip rely on the
>>>>>> extra capabilities of the Exar-provided driver to allow
>>>>>> configuration of the board.  When support for the Exar chip was
>>>>>> added to the kernel 8250_pci driver, this then prevented easy use
>>>>>> of the board by customers for anything other than standard serial usage
>>> in RS232 mode.
>>>>> Was it your intent to also prevent the use of this board in standard
>>>>> serial usage in RS232 mode (which I'd expect is the most common use
>>> case)?
>>>> That is a byproduct of giving the non-average user the ability to
>>>> reconfigure their board.  This will basically move us back to pre-3.8,
>>>> where the customer would simply have to insmod the provided Exar
>>>> driver.  The small inconvenience to that more common user seems (to us
>>>> in Tech Support) outweighed by the much greater inconvenience to the
>>>> user who wants to reconfigure.
>>> Where is the exar driver, in the kernel already?
>>>
>>> confused,
>> I'm sorry for the confusion.  Let me summup:
>>
>> We produce a serial port board that uses the Exar XR17V358 chip.  The board features a jumperless configuration so that to change the board from RS232 to RS422/RS485, you use the GPIO available on the Exar chip, via the Exar driver.  That driver is provided by Exar (from their website, and repackaged on our website and with the board).
>>
>> Recently, we began to hear from customers who purchased the board but could not get the driver to find the board (and thus could not reconfigure it, nor use the non-standard high baud rates the chip is capable of).  We discovered that in 3.8, support for the Exar chip was added to the 8250_pci driver, thus binding it to the kernel.
>>
>> Until (and probably if) Exar decides to submit their driver to the kernel, then it leaves us with a problem that we didn't have prior to 3.8...namely that the board won't do what it is advertised to do unless the customer rebuilds the kernel (that is the only supported workaround from Exar).  The only other workaround we know of (unbind) has met with mixed success which I won't go into unless you want me to, and is already resisted by some customers.
>>
>> The goal of this patch is to get to a point where a customer can install Linux and have full use of this RTD board (using the driver Exar/RTD provides).  No one who has an RTD board is going to feel this is an inconvenience.
> Can you point me at the driver and I'll be glad to add it to the kernel
> so that the proper driver will bind to the device and this will
> not be an issue for users?
>
> thanks,
>
> greg k-h
That would be WONDERFUL.

https://www.exar.com/common/content/document.ashx?id=20121

Thank you,

Rob Groner

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

[Greg KH]

On Fri, Sep 25, 2015 at 03:21:46PM -0400, Rob Groner wrote:
> 
> On 09/25/2015 03:14 PM, Greg KH wrote:
> > On Fri, Sep 25, 2015 at 07:08:32PM +0000, Rob Groner wrote:
> >>> -----Original Message-----
> >>> From: Greg KH [mailto:greg at kroah.com]
> >>> Sent: Friday, September 25, 2015 2:37 PM
> >>> To: Rob Groner <rgroner@RTD.com>
> >>> Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
> >>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
> >>>
> >>> On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote:
> >>>>> -----Original Message-----
> >>>>> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu]
> >>>>> Sent: Friday, September 25, 2015 12:48 PM
> >>>>> To: Rob Groner <rgroner@RTD.com>
> >>>>> Cc: kernelnewbies at kernelnewbies.org
> >>>>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
> >>>>>
> >>>>> On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said:
> >>>>>> Serial boards made by RTD using the Exar XR17V358 chip rely on the
> >>>>>> extra capabilities of the Exar-provided driver to allow
> >>>>>> configuration of the board.  When support for the Exar chip was
> >>>>>> added to the kernel 8250_pci driver, this then prevented easy use
> >>>>>> of the board by customers for anything other than standard serial usage
> >>> in RS232 mode.
> >>>>> Was it your intent to also prevent the use of this board in standard
> >>>>> serial usage in RS232 mode (which I'd expect is the most common use
> >>> case)?
> >>>> That is a byproduct of giving the non-average user the ability to
> >>>> reconfigure their board.  This will basically move us back to pre-3.8,
> >>>> where the customer would simply have to insmod the provided Exar
> >>>> driver.  The small inconvenience to that more common user seems (to us
> >>>> in Tech Support) outweighed by the much greater inconvenience to the
> >>>> user who wants to reconfigure.
> >>> Where is the exar driver, in the kernel already?
> >>>
> >>> confused,
> >> I'm sorry for the confusion.  Let me summup:
> >>
> >> We produce a serial port board that uses the Exar XR17V358 chip.  The board features a jumperless configuration so that to change the board from RS232 to RS422/RS485, you use the GPIO available on the Exar chip, via the Exar driver.  That driver is provided by Exar (from their website, and repackaged on our website and with the board).
> >>
> >> Recently, we began to hear from customers who purchased the board but could not get the driver to find the board (and thus could not reconfigure it, nor use the non-standard high baud rates the chip is capable of).  We discovered that in 3.8, support for the Exar chip was added to the 8250_pci driver, thus binding it to the kernel.
> >>
> >> Until (and probably if) Exar decides to submit their driver to the kernel, then it leaves us with a problem that we didn't have prior to 3.8...namely that the board won't do what it is advertised to do unless the customer rebuilds the kernel (that is the only supported workaround from Exar).  The only other workaround we know of (unbind) has met with mixed success which I won't go into unless you want me to, and is already resisted by some customers.
> >>
> >> The goal of this patch is to get to a point where a customer can install Linux and have full use of this RTD board (using the driver Exar/RTD provides).  No one who has an RTD board is going to feel this is an inconvenience.
> > Can you point me at the driver and I'll be glad to add it to the kernel
> > so that the proper driver will bind to the device and this will
> > not be an issue for users?
> >
> > thanks,
> >
> > greg k-h
> That would be WONDERFUL.
> 
> https://www.exar.com/common/content/document.ashx?id=20121

At first glance, the driver looks pretty good.  Let me do a bit of
cleanup on it for mostly coding style changes and removing some old api
support and see what the patch is.

Would you mind testing it if I make a patch, given that I don't have the
hardware and you do?  :)

thanks,

greg k-h

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

[Rob Groner]

On Fri, 2015-09-25 at 17:45 -0700, Greg KH wrote:
> On Fri, Sep 25, 2015 at 03:21:46PM -0400, Rob Groner wrote:
> > 
> > On 09/25/2015 03:14 PM, Greg KH wrote:
> > > On Fri, Sep 25, 2015 at 07:08:32PM +0000, Rob Groner wrote:
> > >>> -----Original Message-----
> > >>> From: Greg KH [mailto:greg at kroah.com]
> > >>> Sent: Friday, September 25, 2015 2:37 PM
> > >>> To: Rob Groner <rgroner@RTD.com>
> > >>> Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
> > >>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
> > >>>
> > >>> On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote:
> > >>>>> -----Original Message-----
> > >>>>> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu]
> > >>>>> Sent: Friday, September 25, 2015 12:48 PM
> > >>>>> To: Rob Groner <rgroner@RTD.com>
> > >>>>> Cc: kernelnewbies at kernelnewbies.org
> > >>>>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
> > >>>>>
> > >>>>> On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said:
> > >>>>>> Serial boards made by RTD using the Exar XR17V358 chip rely on the
> > >>>>>> extra capabilities of the Exar-provided driver to allow
> > >>>>>> configuration of the board.  When support for the Exar chip was
> > >>>>>> added to the kernel 8250_pci driver, this then prevented easy use
> > >>>>>> of the board by customers for anything other than standard serial usage
> > >>> in RS232 mode.
> > >>>>> Was it your intent to also prevent the use of this board in standard
> > >>>>> serial usage in RS232 mode (which I'd expect is the most common use
> > >>> case)?
> > >>>> That is a byproduct of giving the non-average user the ability to
> > >>>> reconfigure their board.  This will basically move us back to pre-3.8,
> > >>>> where the customer would simply have to insmod the provided Exar
> > >>>> driver.  The small inconvenience to that more common user seems (to us
> > >>>> in Tech Support) outweighed by the much greater inconvenience to the
> > >>>> user who wants to reconfigure.
> > >>> Where is the exar driver, in the kernel already?
> > >>>
> > >>> confused,
> > >> I'm sorry for the confusion.  Let me summup:
> > >>
> > >> We produce a serial port board that uses the Exar XR17V358 chip.  The board features a jumperless configuration so that to change the board from RS232 to RS422/RS485, you use the GPIO available on the Exar chip, via the Exar driver.  That driver is provided by Exar (from their website, and repackaged on our website and with the board).
> > >>
> > >> Recently, we began to hear from customers who purchased the board but could not get the driver to find the board (and thus could not reconfigure it, nor use the non-standard high baud rates the chip is capable of).  We discovered that in 3.8, support for the Exar chip was added to the 8250_pci driver, thus binding it to the kernel.
> > >>
> > >> Until (and probably if) Exar decides to submit their driver to the kernel, then it leaves us with a problem that we didn't have prior to 3.8...namely that the board won't do what it is advertised to do unless the customer rebuilds the kernel (that is the only supported workaround from Exar).  The only other workaround we know of (unbind) has met with mixed success which I won't go into unless you want me to, and is already resisted by some customers.
> > >>
> > >> The goal of this patch is to get to a point where a customer can install Linux and have full use of this RTD board (using the driver Exar/RTD provides).  No one who has an RTD board is going to feel this is an inconvenience.
> > > Can you point me at the driver and I'll be glad to add it to the kernel
> > > so that the proper driver will bind to the device and this will
> > > not be an issue for users?
> > >
> > > thanks,
> > >
> > > greg k-h
> > That would be WONDERFUL.
> > 
> > https://www.exar.com/common/content/document.ashx?id=20121
> 
> At first glance, the driver looks pretty good.  Let me do a bit of
> cleanup on it for mostly coding style changes and removing some old api
> support and see what the patch is.
> 
> Would you mind testing it if I make a patch, given that I don't have the
> hardware and you do?  :)
> 
> thanks,
> 
> greg k-h

I don't mind in the slightest, it's the least I can do!  I've got my
test station ready and have 3 different CPUs I can test with.  Being new
to the whole patching thing, I may need a few hints and helps to make
sure I apply the patch correctly...

Will it be showing up here in kernel newbies mailing list, or
linux-serial, or other?

Thank you.

Rob Groner

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

[Greg KH]

On Mon, Sep 28, 2015 at 08:53:49AM -0400, Rob Groner wrote:
> On Fri, 2015-09-25 at 17:45 -0700, Greg KH wrote:
> > On Fri, Sep 25, 2015 at 03:21:46PM -0400, Rob Groner wrote:
> > > 
> > > On 09/25/2015 03:14 PM, Greg KH wrote:
> > > > On Fri, Sep 25, 2015 at 07:08:32PM +0000, Rob Groner wrote:
> > > >>> -----Original Message-----
> > > >>> From: Greg KH [mailto:greg at kroah.com]
> > > >>> Sent: Friday, September 25, 2015 2:37 PM
> > > >>> To: Rob Groner <rgroner@RTD.com>
> > > >>> Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
> > > >>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
> > > >>>
> > > >>> On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote:
> > > >>>>> -----Original Message-----
> > > >>>>> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu]
> > > >>>>> Sent: Friday, September 25, 2015 12:48 PM
> > > >>>>> To: Rob Groner <rgroner@RTD.com>
> > > >>>>> Cc: kernelnewbies at kernelnewbies.org
> > > >>>>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
> > > >>>>>
> > > >>>>> On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said:
> > > >>>>>> Serial boards made by RTD using the Exar XR17V358 chip rely on the
> > > >>>>>> extra capabilities of the Exar-provided driver to allow
> > > >>>>>> configuration of the board.  When support for the Exar chip was
> > > >>>>>> added to the kernel 8250_pci driver, this then prevented easy use
> > > >>>>>> of the board by customers for anything other than standard serial usage
> > > >>> in RS232 mode.
> > > >>>>> Was it your intent to also prevent the use of this board in standard
> > > >>>>> serial usage in RS232 mode (which I'd expect is the most common use
> > > >>> case)?
> > > >>>> That is a byproduct of giving the non-average user the ability to
> > > >>>> reconfigure their board.  This will basically move us back to pre-3.8,
> > > >>>> where the customer would simply have to insmod the provided Exar
> > > >>>> driver.  The small inconvenience to that more common user seems (to us
> > > >>>> in Tech Support) outweighed by the much greater inconvenience to the
> > > >>>> user who wants to reconfigure.
> > > >>> Where is the exar driver, in the kernel already?
> > > >>>
> > > >>> confused,
> > > >> I'm sorry for the confusion.  Let me summup:
> > > >>
> > > >> We produce a serial port board that uses the Exar XR17V358 chip.  The board features a jumperless configuration so that to change the board from RS232 to RS422/RS485, you use the GPIO available on the Exar chip, via the Exar driver.  That driver is provided by Exar (from their website, and repackaged on our website and with the board).
> > > >>
> > > >> Recently, we began to hear from customers who purchased the board but could not get the driver to find the board (and thus could not reconfigure it, nor use the non-standard high baud rates the chip is capable of).  We discovered that in 3.8, support for the Exar chip was added to the 8250_pci driver, thus binding it to the kernel.
> > > >>
> > > >> Until (and probably if) Exar decides to submit their driver to the kernel, then it leaves us with a problem that we didn't have prior to 3.8...namely that the board won't do what it is advertised to do unless the customer rebuilds the kernel (that is the only supported workaround from Exar).  The only other workaround we know of (unbind) has met with mixed success which I won't go into unless you want me to, and is already resisted by some customers.
> > > >>
> > > >> The goal of this patch is to get to a point where a customer can install Linux and have full use of this RTD board (using the driver Exar/RTD provides).  No one who has an RTD board is going to feel this is an inconvenience.
> > > > Can you point me at the driver and I'll be glad to add it to the kernel
> > > > so that the proper driver will bind to the device and this will
> > > > not be an issue for users?
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > > That would be WONDERFUL.
> > > 
> > > https://www.exar.com/common/content/document.ashx?id=20121
> > 
> > At first glance, the driver looks pretty good.  Let me do a bit of
> > cleanup on it for mostly coding style changes and removing some old api
> > support and see what the patch is.
> > 
> > Would you mind testing it if I make a patch, given that I don't have the
> > hardware and you do?  :)
> > 
> > thanks,
> > 
> > greg k-h
> 
> I don't mind in the slightest, it's the least I can do!  I've got my
> test station ready and have 3 different CPUs I can test with.  Being new
> to the whole patching thing, I may need a few hints and helps to make
> sure I apply the patch correctly...
> 
> Will it be showing up here in kernel newbies mailing list, or
> linux-serial, or other?

How about let's take it to linux-serial, and I'll cc: you as well,
that's the proper place for this.

Note, the driver does do some "odd" things in that it has some "custom"
ioctls for unknown reasons, and it grabs a major number of another
driver, both things that I can't accept upstream.  It also seems to
duplicate a lot of existing code, so maybe it doesn't really need to be
a separate driver.  I'll dig around in it and see what I can come up
with, give me a week or so...

thanks,

greg k-h

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

[Rob Groner]

On Mon, 2015-09-28 at 07:11 -0700, Greg KH wrote:
> On Mon, Sep 28, 2015 at 08:53:49AM -0400, Rob Groner wrote:
> > On Fri, 2015-09-25 at 17:45 -0700, Greg KH wrote:
> > > On Fri, Sep 25, 2015 at 03:21:46PM -0400, Rob Groner wrote:
> > > > 
> > > > On 09/25/2015 03:14 PM, Greg KH wrote:
> > > > > On Fri, Sep 25, 2015 at 07:08:32PM +0000, Rob Groner wrote:
> > > > >>> -----Original Message-----
> > > > >>> From: Greg KH [mailto:greg at kroah.com]
> > > > >>> Sent: Friday, September 25, 2015 2:37 PM
> > > > >>> To: Rob Groner <rgroner@RTD.com>
> > > > >>> Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
> > > > >>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
> > > > >>>
> > > > >>> On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote:
> > > > >>>>> -----Original Message-----
> > > > >>>>> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu]
> > > > >>>>> Sent: Friday, September 25, 2015 12:48 PM
> > > > >>>>> To: Rob Groner <rgroner@RTD.com>
> > > > >>>>> Cc: kernelnewbies at kernelnewbies.org
> > > > >>>>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
> > > > >>>>>
> > > > >>>>> On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said:
> > > > >>>>>> Serial boards made by RTD using the Exar XR17V358 chip rely on the
> > > > >>>>>> extra capabilities of the Exar-provided driver to allow
> > > > >>>>>> configuration of the board.  When support for the Exar chip was
> > > > >>>>>> added to the kernel 8250_pci driver, this then prevented easy use
> > > > >>>>>> of the board by customers for anything other than standard serial usage
> > > > >>> in RS232 mode.
> > > > >>>>> Was it your intent to also prevent the use of this board in standard
> > > > >>>>> serial usage in RS232 mode (which I'd expect is the most common use
> > > > >>> case)?
> > > > >>>> That is a byproduct of giving the non-average user the ability to
> > > > >>>> reconfigure their board.  This will basically move us back to pre-3.8,
> > > > >>>> where the customer would simply have to insmod the provided Exar
> > > > >>>> driver.  The small inconvenience to that more common user seems (to us
> > > > >>>> in Tech Support) outweighed by the much greater inconvenience to the
> > > > >>>> user who wants to reconfigure.
> > > > >>> Where is the exar driver, in the kernel already?
> > > > >>>
> > > > >>> confused,
> > > > >> I'm sorry for the confusion.  Let me summup:
> > > > >>
> > > > >> We produce a serial port board that uses the Exar XR17V358 chip.  The board features a jumperless configuration so that to change the board from RS232 to RS422/RS485, you use the GPIO available on the Exar chip, via the Exar driver.  That driver is provided by Exar (from their website, and repackaged on our website and with the board).
> > > > >>
> > > > >> Recently, we began to hear from customers who purchased the board but could not get the driver to find the board (and thus could not reconfigure it, nor use the non-standard high baud rates the chip is capable of).  We discovered that in 3.8, support for the Exar chip was added to the 8250_pci driver, thus binding it to the kernel.
> > > > >>
> > > > >> Until (and probably if) Exar decides to submit their driver to the kernel, then it leaves us with a problem that we didn't have prior to 3.8...namely that the board won't do what it is advertised to do unless the customer rebuilds the kernel (that is the only supported workaround from Exar).  The only other workaround we know of (unbind) has met with mixed success which I won't go into unless you want me to, and is already resisted by some customers.
> > > > >>
> > > > >> The goal of this patch is to get to a point where a customer can install Linux and have full use of this RTD board (using the driver Exar/RTD provides).  No one who has an RTD board is going to feel this is an inconvenience.
> > > > > Can you point me at the driver and I'll be glad to add it to the kernel
> > > > > so that the proper driver will bind to the device and this will
> > > > > not be an issue for users?
> > > > >
> > > > > thanks,
> > > > >
> > > > > greg k-h
> > > > That would be WONDERFUL.
> > > > 
> > > > https://www.exar.com/common/content/document.ashx?id=20121
> > > 
> > > At first glance, the driver looks pretty good.  Let me do a bit of
> > > cleanup on it for mostly coding style changes and removing some old api
> > > support and see what the patch is.
> > > 
> > > Would you mind testing it if I make a patch, given that I don't have the
> > > hardware and you do?  :)
> > > 
> > > thanks,
> > > 
> > > greg k-h
> > 
> > I don't mind in the slightest, it's the least I can do!  I've got my
> > test station ready and have 3 different CPUs I can test with.  Being new
> > to the whole patching thing, I may need a few hints and helps to make
> > sure I apply the patch correctly...
> > 
> > Will it be showing up here in kernel newbies mailing list, or
> > linux-serial, or other?
> 
> How about let's take it to linux-serial, and I'll cc: you as well,
> that's the proper place for this.
> 
> Note, the driver does do some "odd" things in that it has some "custom"
> ioctls for unknown reasons, and it grabs a major number of another
> driver, both things that I can't accept upstream.  It also seems to
> duplicate a lot of existing code, so maybe it doesn't really need to be
> a separate driver.  I'll dig around in it and see what I can come up
> with, give me a week or so...
> 
> thanks,
> 
> greg k-h

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

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

[Rob Groner]

> -----Original Message-----
> From: Greg KH [mailto:greg at kroah.com]
> Sent: Monday, September 28, 2015 10:12 AM
> To: Rob Groner <rgroner@RTD.com>
> Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
> 
> On Mon, Sep 28, 2015 at 08:53:49AM -0400, Rob Groner wrote:
> > On Fri, 2015-09-25 at 17:45 -0700, Greg KH wrote:
> > > On Fri, Sep 25, 2015 at 03:21:46PM -0400, Rob Groner wrote:
> > > >
> > > > On 09/25/2015 03:14 PM, Greg KH wrote:
> > > > > On Fri, Sep 25, 2015 at 07:08:32PM +0000, Rob Groner wrote:
> > > > >>> -----Original Message-----
> > > > >>> From: Greg KH [mailto:greg at kroah.com]
> > > > >>> Sent: Friday, September 25, 2015 2:37 PM
> > > > >>> To: Rob Groner <rgroner@RTD.com>
> > > > >>> Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
> > > > >>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from
> binding.
> > > > >>>
> > > > >>> On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote:
> > > > >>>>> -----Original Message-----
> > > > >>>>> From: Valdis.Kletnieks at vt.edu
> > > > >>>>> [mailto:Valdis.Kletnieks at vt.edu]
> > > > >>>>> Sent: Friday, September 25, 2015 12:48 PM
> > > > >>>>> To: Rob Groner <rgroner@RTD.com>
> > > > >>>>> Cc: kernelnewbies at kernelnewbies.org
> > > > >>>>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from
> binding.
> > > > >>>>>
> > > > >>>>> On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said:
> > > > >>>>>> Serial boards made by RTD using the Exar XR17V358 chip rely
> > > > >>>>>> on the extra capabilities of the Exar-provided driver to
> > > > >>>>>> allow configuration of the board.  When support for the
> > > > >>>>>> Exar chip was added to the kernel 8250_pci driver, this
> > > > >>>>>> then prevented easy use of the board by customers for
> > > > >>>>>> anything other than standard serial usage
> > > > >>> in RS232 mode.
> > > > >>>>> Was it your intent to also prevent the use of this board in
> > > > >>>>> standard serial usage in RS232 mode (which I'd expect is the
> > > > >>>>> most common use
> > > > >>> case)?
> > > > >>>> That is a byproduct of giving the non-average user the
> > > > >>>> ability to reconfigure their board.  This will basically move
> > > > >>>> us back to pre-3.8, where the customer would simply have to
> > > > >>>> insmod the provided Exar driver.  The small inconvenience to
> > > > >>>> that more common user seems (to us in Tech Support)
> > > > >>>> outweighed by the much greater inconvenience to the user who
> wants to reconfigure.
> > > > >>> Where is the exar driver, in the kernel already?
> > > > >>>
> > > > >>> confused,
> > > > >> I'm sorry for the confusion.  Let me summup:
> > > > >>
> > > > >> We produce a serial port board that uses the Exar XR17V358 chip.
> The board features a jumperless configuration so that to change the board
> from RS232 to RS422/RS485, you use the GPIO available on the Exar chip, via
> the Exar driver.  That driver is provided by Exar (from their website, and
> repackaged on our website and with the board).
> > > > >>
> > > > >> Recently, we began to hear from customers who purchased the
> board but could not get the driver to find the board (and thus could not
> reconfigure it, nor use the non-standard high baud rates the chip is capable
> of).  We discovered that in 3.8, support for the Exar chip was added to the
> 8250_pci driver, thus binding it to the kernel.
> > > > >>
> > > > >> Until (and probably if) Exar decides to submit their driver to the
> kernel, then it leaves us with a problem that we didn't have prior to
> 3.8...namely that the board won't do what it is advertised to do unless the
> customer rebuilds the kernel (that is the only supported workaround from
> Exar).  The only other workaround we know of (unbind) has met with mixed
> success which I won't go into unless you want me to, and is already resisted
> by some customers.
> > > > >>
> > > > >> The goal of this patch is to get to a point where a customer can install
> Linux and have full use of this RTD board (using the driver Exar/RTD
> provides).  No one who has an RTD board is going to feel this is an
> inconvenience.
> > > > > Can you point me at the driver and I'll be glad to add it to the
> > > > > kernel so that the proper driver will bind to the device and
> > > > > this will not be an issue for users?
> > > > >
> > > > > thanks,
> > > > >
> > > > > greg k-h
> > > > That would be WONDERFUL.
> > > >
> > > > https://www.exar.com/common/content/document.ashx?id=20121
> > >
> > > At first glance, the driver looks pretty good.  Let me do a bit of
> > > cleanup on it for mostly coding style changes and removing some old
> > > api support and see what the patch is.
> > >
> > > Would you mind testing it if I make a patch, given that I don't have
> > > the hardware and you do?  :)
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > I don't mind in the slightest, it's the least I can do!  I've got my
> > test station ready and have 3 different CPUs I can test with.  Being
> > new to the whole patching thing, I may need a few hints and helps to
> > make sure I apply the patch correctly...
> >
> > Will it be showing up here in kernel newbies mailing list, or
> > linux-serial, or other?
> 
> How about let's take it to linux-serial, and I'll cc: you as well, that's the proper
> place for this.
> 
> Note, the driver does do some "odd" things in that it has some "custom"
> ioctls for unknown reasons, and it grabs a major number of another driver,
> both things that I can't accept upstream.  It also seems to duplicate a lot of
> existing code, so maybe it doesn't really need to be a separate driver.  I'll dig
> around in it and see what I can come up with, give me a week or so...
> 
> thanks,
> 
> greg k-h

I know you're incredibly busy, so I added as much "so" to the week as I could.  Any way I can help with this endeavor, other than testing?

Thanks,

Rob Groner

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

[Rob Groner]

> -----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 <greg@kroah.com>
> Cc: kernelnewbies at kernelnewbies.org
> Subject: RE: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
> 
> > -----Original Message-----
> > From: Greg KH [mailto:greg at kroah.com]
> > Sent: Monday, September 28, 2015 10:12 AM
> > To: Rob Groner <rgroner@RTD.com>
> > Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
> > Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
> >
> > On Mon, Sep 28, 2015 at 08:53:49AM -0400, Rob Groner wrote:
> > > On Fri, 2015-09-25 at 17:45 -0700, Greg KH wrote:
> > > > On Fri, Sep 25, 2015 at 03:21:46PM -0400, Rob Groner wrote:
> > > > >
> > > > > On 09/25/2015 03:14 PM, Greg KH wrote:
> > > > > > On Fri, Sep 25, 2015 at 07:08:32PM +0000, Rob Groner wrote:
> > > > > >>> -----Original Message-----
> > > > > >>> From: Greg KH [mailto:greg at kroah.com]
> > > > > >>> Sent: Friday, September 25, 2015 2:37 PM
> > > > > >>> To: Rob Groner <rgroner@RTD.com>
> > > > > >>> Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
> > > > > >>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from
> > binding.
> > > > > >>>
> > > > > >>> On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote:
> > > > > >>>>> -----Original Message-----
> > > > > >>>>> From: Valdis.Kletnieks at vt.edu
> > > > > >>>>> [mailto:Valdis.Kletnieks at vt.edu]
> > > > > >>>>> Sent: Friday, September 25, 2015 12:48 PM
> > > > > >>>>> To: Rob Groner <rgroner@RTD.com>
> > > > > >>>>> Cc: kernelnewbies at kernelnewbies.org
> > > > > >>>>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards
> > > > > >>>>> from
> > binding.
> > > > > >>>>>
> > > > > >>>>> On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said:
> > > > > >>>>>> Serial boards made by RTD using the Exar XR17V358 chip
> > > > > >>>>>> rely on the extra capabilities of the Exar-provided
> > > > > >>>>>> driver to allow configuration of the board.  When support
> > > > > >>>>>> for the Exar chip was added to the kernel 8250_pci
> > > > > >>>>>> driver, this then prevented easy use of the board by
> > > > > >>>>>> customers for anything other than standard serial usage
> > > > > >>> in RS232 mode.
> > > > > >>>>> Was it your intent to also prevent the use of this board
> > > > > >>>>> in standard serial usage in RS232 mode (which I'd expect
> > > > > >>>>> is the most common use
> > > > > >>> case)?
> > > > > >>>> That is a byproduct of giving the non-average user the
> > > > > >>>> ability to reconfigure their board.  This will basically
> > > > > >>>> move us back to pre-3.8, where the customer would simply
> > > > > >>>> have to insmod the provided Exar driver.  The small
> > > > > >>>> inconvenience to that more common user seems (to us in Tech
> > > > > >>>> Support) outweighed by the much greater inconvenience to
> > > > > >>>> the user who
> > wants to reconfigure.
> > > > > >>> Where is the exar driver, in the kernel already?
> > > > > >>>
> > > > > >>> confused,
> > > > > >> I'm sorry for the confusion.  Let me summup:
> > > > > >>
> > > > > >> We produce a serial port board that uses the Exar XR17V358 chip.
> > The board features a jumperless configuration so that to change the
> > board from RS232 to RS422/RS485, you use the GPIO available on the
> > Exar chip, via the Exar driver.  That driver is provided by Exar (from
> > their website, and repackaged on our website and with the board).
> > > > > >>
> > > > > >> Recently, we began to hear from customers who purchased the
> > board but could not get the driver to find the board (and thus could
> > not reconfigure it, nor use the non-standard high baud rates the chip
> > is capable of).  We discovered that in 3.8, support for the Exar chip
> > was added to the 8250_pci driver, thus binding it to the kernel.
> > > > > >>
> > > > > >> Until (and probably if) Exar decides to submit their driver
> > > > > >> to the
> > kernel, then it leaves us with a problem that we didn't have prior to
> > 3.8...namely that the board won't do what it is advertised to do
> > unless the customer rebuilds the kernel (that is the only supported
> > workaround from Exar).  The only other workaround we know of (unbind)
> > has met with mixed success which I won't go into unless you want me
> > to, and is already resisted by some customers.
> > > > > >>
> > > > > >> The goal of this patch is to get to a point where a customer
> > > > > >> can install
> > Linux and have full use of this RTD board (using the driver Exar/RTD
> > provides).  No one who has an RTD board is going to feel this is an
> > inconvenience.
> > > > > > Can you point me at the driver and I'll be glad to add it to
> > > > > > the kernel so that the proper driver will bind to the device
> > > > > > and this will not be an issue for users?
> > > > > >
> > > > > > thanks,
> > > > > >
> > > > > > greg k-h
> > > > > That would be WONDERFUL.
> > > > >
> > > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2
> > > > >
> fwww.exar.com%2fcommon%2fcontent%2fdocument.ashx%3fid%3d20121&
> da
> > > > >
> ta=01%7c01%7crgroner%40rtd.com%7c261e5150b71d4b17e91308d2de03148
> > > > >
> e%7c16f82b7977b8423dbafdd6c19032e267%7c0&sdata=Tl%2br4Vjgut%2bRh
> > > > > 3nam6wTMwbpBDpqIW%2fb2dzsTJtE0A4%3d
> > > >
> > > > At first glance, the driver looks pretty good.  Let me do a bit of
> > > > cleanup on it for mostly coding style changes and removing some
> > > > old api support and see what the patch is.
> > > >
> > > > Would you mind testing it if I make a patch, given that I don't
> > > > have the hardware and you do?  :)
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > >
> > > I don't mind in the slightest, it's the least I can do!  I've got my
> > > test station ready and have 3 different CPUs I can test with.  Being
> > > new to the whole patching thing, I may need a few hints and helps to
> > > make sure I apply the patch correctly...
> > >
> > > Will it be showing up here in kernel newbies mailing list, or
> > > linux-serial, or other?
> >
> > How about let's take it to linux-serial, and I'll cc: you as well,
> > that's the proper place for this.
> >
> > Note, the driver does do some "odd" things in that it has some "custom"
> > ioctls for unknown reasons, and it grabs a major number of another
> > driver, both things that I can't accept upstream.  It also seems to
> > duplicate a lot of existing code, so maybe it doesn't really need to
> > be a separate driver.  I'll dig around in it and see what I can come up with,
> give me a week or so...
> >
> > thanks,
> >
> > greg k-h
> 
> I know you're incredibly busy, so I added as much "so" to the week as I could.
> Any way I can help with this endeavor, other than testing?

Would it be possible to consider my original patch, if putting in the Exar driver is too time consuming? 
I'd rather have the Exar driver than my patch, but I'd also rather have my patch than the current situation.

Thanks still for the offer of submitting the driver.

Rob G.

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

[Greg KH]

On Wed, Nov 11, 2015 at 03:46:23PM +0000, Rob Groner wrote:
> 
> > -----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 <greg@kroah.com>
> > Cc: kernelnewbies at kernelnewbies.org
> > Subject: RE: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
> > 
> > > -----Original Message-----
> > > From: Greg KH [mailto:greg at kroah.com]
> > > Sent: Monday, September 28, 2015 10:12 AM
> > > To: Rob Groner <rgroner@RTD.com>
> > > Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
> > > Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
> > >
> > > On Mon, Sep 28, 2015 at 08:53:49AM -0400, Rob Groner wrote:
> > > > On Fri, 2015-09-25 at 17:45 -0700, Greg KH wrote:
> > > > > On Fri, Sep 25, 2015 at 03:21:46PM -0400, Rob Groner wrote:
> > > > > >
> > > > > > On 09/25/2015 03:14 PM, Greg KH wrote:
> > > > > > > On Fri, Sep 25, 2015 at 07:08:32PM +0000, Rob Groner wrote:
> > > > > > >>> -----Original Message-----
> > > > > > >>> From: Greg KH [mailto:greg at kroah.com]
> > > > > > >>> Sent: Friday, September 25, 2015 2:37 PM
> > > > > > >>> To: Rob Groner <rgroner@RTD.com>
> > > > > > >>> Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
> > > > > > >>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from
> > > binding.
> > > > > > >>>
> > > > > > >>> On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote:
> > > > > > >>>>> -----Original Message-----
> > > > > > >>>>> From: Valdis.Kletnieks at vt.edu
> > > > > > >>>>> [mailto:Valdis.Kletnieks at vt.edu]
> > > > > > >>>>> Sent: Friday, September 25, 2015 12:48 PM
> > > > > > >>>>> To: Rob Groner <rgroner@RTD.com>
> > > > > > >>>>> Cc: kernelnewbies at kernelnewbies.org
> > > > > > >>>>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards
> > > > > > >>>>> from
> > > binding.
> > > > > > >>>>>
> > > > > > >>>>> On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said:
> > > > > > >>>>>> Serial boards made by RTD using the Exar XR17V358 chip
> > > > > > >>>>>> rely on the extra capabilities of the Exar-provided
> > > > > > >>>>>> driver to allow configuration of the board.  When support
> > > > > > >>>>>> for the Exar chip was added to the kernel 8250_pci
> > > > > > >>>>>> driver, this then prevented easy use of the board by
> > > > > > >>>>>> customers for anything other than standard serial usage
> > > > > > >>> in RS232 mode.
> > > > > > >>>>> Was it your intent to also prevent the use of this board
> > > > > > >>>>> in standard serial usage in RS232 mode (which I'd expect
> > > > > > >>>>> is the most common use
> > > > > > >>> case)?
> > > > > > >>>> That is a byproduct of giving the non-average user the
> > > > > > >>>> ability to reconfigure their board.  This will basically
> > > > > > >>>> move us back to pre-3.8, where the customer would simply
> > > > > > >>>> have to insmod the provided Exar driver.  The small
> > > > > > >>>> inconvenience to that more common user seems (to us in Tech
> > > > > > >>>> Support) outweighed by the much greater inconvenience to
> > > > > > >>>> the user who
> > > wants to reconfigure.
> > > > > > >>> Where is the exar driver, in the kernel already?
> > > > > > >>>
> > > > > > >>> confused,
> > > > > > >> I'm sorry for the confusion.  Let me summup:
> > > > > > >>
> > > > > > >> We produce a serial port board that uses the Exar XR17V358 chip.
> > > The board features a jumperless configuration so that to change the
> > > board from RS232 to RS422/RS485, you use the GPIO available on the
> > > Exar chip, via the Exar driver.  That driver is provided by Exar (from
> > > their website, and repackaged on our website and with the board).
> > > > > > >>
> > > > > > >> Recently, we began to hear from customers who purchased the
> > > board but could not get the driver to find the board (and thus could
> > > not reconfigure it, nor use the non-standard high baud rates the chip
> > > is capable of).  We discovered that in 3.8, support for the Exar chip
> > > was added to the 8250_pci driver, thus binding it to the kernel.
> > > > > > >>
> > > > > > >> Until (and probably if) Exar decides to submit their driver
> > > > > > >> to the
> > > kernel, then it leaves us with a problem that we didn't have prior to
> > > 3.8...namely that the board won't do what it is advertised to do
> > > unless the customer rebuilds the kernel (that is the only supported
> > > workaround from Exar).  The only other workaround we know of (unbind)
> > > has met with mixed success which I won't go into unless you want me
> > > to, and is already resisted by some customers.
> > > > > > >>
> > > > > > >> The goal of this patch is to get to a point where a customer
> > > > > > >> can install
> > > Linux and have full use of this RTD board (using the driver Exar/RTD
> > > provides).  No one who has an RTD board is going to feel this is an
> > > inconvenience.
> > > > > > > Can you point me at the driver and I'll be glad to add it to
> > > > > > > the kernel so that the proper driver will bind to the device
> > > > > > > and this will not be an issue for users?
> > > > > > >
> > > > > > > thanks,
> > > > > > >
> > > > > > > greg k-h
> > > > > > That would be WONDERFUL.
> > > > > >
> > > > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2
> > > > > >
> > fwww.exar.com%2fcommon%2fcontent%2fdocument.ashx%3fid%3d20121&
> > da
> > > > > >
> > ta=01%7c01%7crgroner%40rtd.com%7c261e5150b71d4b17e91308d2de03148
> > > > > >
> > e%7c16f82b7977b8423dbafdd6c19032e267%7c0&sdata=Tl%2br4Vjgut%2bRh
> > > > > > 3nam6wTMwbpBDpqIW%2fb2dzsTJtE0A4%3d
> > > > >
> > > > > At first glance, the driver looks pretty good.  Let me do a bit of
> > > > > cleanup on it for mostly coding style changes and removing some
> > > > > old api support and see what the patch is.
> > > > >
> > > > > Would you mind testing it if I make a patch, given that I don't
> > > > > have the hardware and you do?  :)
> > > > >
> > > > > thanks,
> > > > >
> > > > > greg k-h
> > > >
> > > > I don't mind in the slightest, it's the least I can do!  I've got my
> > > > test station ready and have 3 different CPUs I can test with.  Being
> > > > new to the whole patching thing, I may need a few hints and helps to
> > > > make sure I apply the patch correctly...
> > > >
> > > > Will it be showing up here in kernel newbies mailing list, or
> > > > linux-serial, or other?
> > >
> > > How about let's take it to linux-serial, and I'll cc: you as well,
> > > that's the proper place for this.
> > >
> > > Note, the driver does do some "odd" things in that it has some "custom"
> > > ioctls for unknown reasons, and it grabs a major number of another
> > > driver, both things that I can't accept upstream.  It also seems to
> > > duplicate a lot of existing code, so maybe it doesn't really need to
> > > be a separate driver.  I'll dig around in it and see what I can come up with,
> > give me a week or so...
> > >
> > > thanks,
> > >
> > > greg k-h
> > 
> > I know you're incredibly busy, so I added as much "so" to the week as I could.
> > Any way I can help with this endeavor, other than testing?
> 
> Would it be possible to consider my original patch, if putting in the Exar driver is too time consuming? 
> I'd rather have the Exar driver than my patch, but I'd also rather have my patch than the current situation.

I don't remember what your "original patch" was, sorry.

greg k-h

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

[Rob Groner]

> -----Original Message-----
> From: Greg KH [mailto:greg at kroah.com]
> Sent: Wednesday, November 11, 2015 12:32 PM
> To: Rob Groner <rgroner@RTD.com>
> Cc: kernelnewbies at kernelnewbies.org
> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
> 
> On Wed, Nov 11, 2015 at 03:46:23PM +0000, Rob Groner wrote:
> >
> > > -----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 <greg@kroah.com>
> > > Cc: kernelnewbies at kernelnewbies.org
> > > Subject: RE: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
> > >
> > > > -----Original Message-----
> > > > From: Greg KH [mailto:greg at kroah.com]
> > > > Sent: Monday, September 28, 2015 10:12 AM
> > > > To: Rob Groner <rgroner@RTD.com>
> > > > Cc: Valdis.Kletnieks at vt.edu; kernelnewbies at kernelnewbies.org
> > > > Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
> > > >
> > > > On Mon, Sep 28, 2015 at 08:53:49AM -0400, Rob Groner wrote:
> > > > > On Fri, 2015-09-25 at 17:45 -0700, Greg KH wrote:
> > > > > > On Fri, Sep 25, 2015 at 03:21:46PM -0400, Rob Groner wrote:
> > > > > > >
> > > > > > > On 09/25/2015 03:14 PM, Greg KH wrote:
> > > > > > > > On Fri, Sep 25, 2015 at 07:08:32PM +0000, Rob Groner wrote:
> > > > > > > >>> -----Original Message-----
> > > > > > > >>> From: Greg KH [mailto:greg at kroah.com]
> > > > > > > >>> Sent: Friday, September 25, 2015 2:37 PM
> > > > > > > >>> To: Rob Groner <rgroner@RTD.com>
> > > > > > > >>> Cc: Valdis.Kletnieks at vt.edu;
> > > > > > > >>> kernelnewbies at kernelnewbies.org
> > > > > > > >>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards
> > > > > > > >>> from
> > > > binding.
> > > > > > > >>>
> > > > > > > >>> On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote:
> > > > > > > >>>>> -----Original Message-----
> > > > > > > >>>>> From: Valdis.Kletnieks at vt.edu
> > > > > > > >>>>> [mailto:Valdis.Kletnieks at vt.edu]
> > > > > > > >>>>> Sent: Friday, September 25, 2015 12:48 PM
> > > > > > > >>>>> To: Rob Groner <rgroner@RTD.com>
> > > > > > > >>>>> Cc: kernelnewbies at kernelnewbies.org
> > > > > > > >>>>> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards
> > > > > > > >>>>> from
> > > > binding.
> > > > > > > >>>>>
> > > > > > > >>>>> On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said:
> > > > > > > >>>>>> Serial boards made by RTD using the Exar XR17V358
> > > > > > > >>>>>> chip rely on the extra capabilities of the
> > > > > > > >>>>>> Exar-provided driver to allow configuration of the
> > > > > > > >>>>>> board.  When support for the Exar chip was added to
> > > > > > > >>>>>> the kernel 8250_pci driver, this then prevented easy
> > > > > > > >>>>>> use of the board by customers for anything other than
> > > > > > > >>>>>> standard serial usage
> > > > > > > >>> in RS232 mode.
> > > > > > > >>>>> Was it your intent to also prevent the use of this
> > > > > > > >>>>> board in standard serial usage in RS232 mode (which
> > > > > > > >>>>> I'd expect is the most common use
> > > > > > > >>> case)?
> > > > > > > >>>> That is a byproduct of giving the non-average user the
> > > > > > > >>>> ability to reconfigure their board.  This will
> > > > > > > >>>> basically move us back to pre-3.8, where the customer
> > > > > > > >>>> would simply have to insmod the provided Exar driver.
> > > > > > > >>>> The small inconvenience to that more common user seems
> > > > > > > >>>> (to us in Tech
> > > > > > > >>>> Support) outweighed by the much greater inconvenience
> > > > > > > >>>> to the user who
> > > > wants to reconfigure.
> > > > > > > >>> Where is the exar driver, in the kernel already?
> > > > > > > >>>
> > > > > > > >>> confused,
> > > > > > > >> I'm sorry for the confusion.  Let me summup:
> > > > > > > >>
> > > > > > > >> We produce a serial port board that uses the Exar XR17V358
> chip.
> > > > The board features a jumperless configuration so that to change
> > > > the board from RS232 to RS422/RS485, you use the GPIO available on
> > > > the Exar chip, via the Exar driver.  That driver is provided by
> > > > Exar (from their website, and repackaged on our website and with the
> board).
> > > > > > > >>
> > > > > > > >> Recently, we began to hear from customers who purchased
> > > > > > > >> the
> > > > board but could not get the driver to find the board (and thus
> > > > could not reconfigure it, nor use the non-standard high baud rates
> > > > the chip is capable of).  We discovered that in 3.8, support for
> > > > the Exar chip was added to the 8250_pci driver, thus binding it to the
> kernel.
> > > > > > > >>
> > > > > > > >> Until (and probably if) Exar decides to submit their
> > > > > > > >> driver to the
> > > > kernel, then it leaves us with a problem that we didn't have prior
> > > > to 3.8...namely that the board won't do what it is advertised to
> > > > do unless the customer rebuilds the kernel (that is the only
> > > > supported workaround from Exar).  The only other workaround we
> > > > know of (unbind) has met with mixed success which I won't go into
> > > > unless you want me to, and is already resisted by some customers.
> > > > > > > >>
> > > > > > > >> The goal of this patch is to get to a point where a
> > > > > > > >> customer can install
> > > > Linux and have full use of this RTD board (using the driver
> > > > Exar/RTD provides).  No one who has an RTD board is going to feel
> > > > this is an inconvenience.
> > > > > > > > Can you point me at the driver and I'll be glad to add it
> > > > > > > > to the kernel so that the proper driver will bind to the
> > > > > > > > device and this will not be an issue for users?
> > > > > > > >
> > > > > > > > thanks,
> > > > > > > >
> > > > > > > > greg k-h
> > > > > > > That would be WONDERFUL.
> > > > > > >
> > > > > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%
> > > > > > > 2f%2
> > > > > > >
> > >
> fwww.exar.com%2fcommon%2fcontent%2fdocument.ashx%3fid%3d20121&
> > > da
> > > > > > >
> > >
> ta=01%7c01%7crgroner%40rtd.com%7c261e5150b71d4b17e91308d2de03148
> > > > > > >
> > >
> e%7c16f82b7977b8423dbafdd6c19032e267%7c0&sdata=Tl%2br4Vjgut%2bRh
> > > > > > > 3nam6wTMwbpBDpqIW%2fb2dzsTJtE0A4%3d
> > > > > >
> > > > > > At first glance, the driver looks pretty good.  Let me do a
> > > > > > bit of cleanup on it for mostly coding style changes and
> > > > > > removing some old api support and see what the patch is.
> > > > > >
> > > > > > Would you mind testing it if I make a patch, given that I
> > > > > > don't have the hardware and you do?  :)
> > > > > >
> > > > > > thanks,
> > > > > >
> > > > > > greg k-h
> > > > >
> > > > > I don't mind in the slightest, it's the least I can do!  I've
> > > > > got my test station ready and have 3 different CPUs I can test
> > > > > with.  Being new to the whole patching thing, I may need a few
> > > > > hints and helps to make sure I apply the patch correctly...
> > > > >
> > > > > Will it be showing up here in kernel newbies mailing list, or
> > > > > linux-serial, or other?
> > > >
> > > > How about let's take it to linux-serial, and I'll cc: you as well,
> > > > that's the proper place for this.
> > > >
> > > > Note, the driver does do some "odd" things in that it has some
> "custom"
> > > > ioctls for unknown reasons, and it grabs a major number of another
> > > > driver, both things that I can't accept upstream.  It also seems
> > > > to duplicate a lot of existing code, so maybe it doesn't really
> > > > need to be a separate driver.  I'll dig around in it and see what
> > > > I can come up with,
> > > give me a week or so...
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > >
> > > I know you're incredibly busy, so I added as much "so" to the week as I
> could.
> > > Any way I can help with this endeavor, other than testing?
> >
> > Would it be possible to consider my original patch, if putting in the Exar
> driver is too time consuming?
> > I'd rather have the Exar driver than my patch, but I'd also rather have my
> patch than the current situation.
> 
> 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.

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

[Sudip Mukherjee]

On Wed, Nov 11, 2015 at 11:02 PM, Greg KH <greg@kroah.com> wrote:

> On Wed, Nov 11, 2015 at 03:46:23PM +0000, Rob Groner wrote:
> >
>
<snip>

> > > 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.
>

Hi Greg,
Quoting from your old reply
> > > 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.

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

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

[Greg KH]

On Wed, Nov 11, 2015 at 11:50:33PM +0530, Sudip Mukherjee wrote:
> On Wed, Nov 11, 2015 at 11:02 PM, Greg KH <greg@kroah.com> wrote:
> 
>     On Wed, Nov 11, 2015 at 03:46:23PM +0000, Rob Groner wrote:
>     >
> 
> <snip>
> 
>     > > 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.
> 
> 
> Hi Greg,
> Quoting from your old reply
> > > > 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

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

[Rob Groner]

> -----Original Message-----
> From: Greg KH [mailto:greg at kroah.com]
> Sent: Wednesday, November 11, 2015 4:41 PM
> To: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
> Cc: Rob Groner <rgroner@RTD.com>; kernelnewbies at kernelnewbies.org
> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
> 
> On Wed, Nov 11, 2015 at 11:50:33PM +0530, Sudip Mukherjee wrote:
> > On Wed, Nov 11, 2015 at 11:02 PM, Greg KH <greg@kroah.com> wrote:
> >
> >     On Wed, Nov 11, 2015 at 03:46:23PM +0000, Rob Groner wrote:
> >     >
> >
> > <snip>
> >
> >     > > 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.
> >
> >
> > Hi Greg,
> > Quoting from your old reply
> > > > > 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

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.

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

[Greg KH]

On Wed, Nov 11, 2015 at 09:49:11PM +0000, Rob Groner wrote:
> > > 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
> 
> 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

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

[Rob Groner]

> -----Original Message-----
> From: Greg KH [mailto:greg at kroah.com]
> Sent: Wednesday, November 11, 2015 5:13 PM
> To: Rob Groner <rgroner@RTD.com>
> Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>;
> kernelnewbies at kernelnewbies.org
> Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
> 
> On Wed, Nov 11, 2015 at 09:49:11PM +0000, Rob Groner wrote:
> > > > 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
> >
> > 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

Oooo, ok.  Fantastic!  Testing is standing by.

Rob G