* [PATCH] 8250_pci.c: Update NI specific devices class to multi serial
@ 2019-01-14 14:10 Guan Yung Tseng
2019-01-18 11:57 ` Greg KH
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Guan Yung Tseng @ 2019-01-14 14:10 UTC (permalink / raw)
To: gregkh; +Cc: linux-serial, linux-kernel, Guan Yung Tseng
Modified NI devices class to PCI_CLASS_COMMUNICATION_MULTISERIAL.
The reason of doing this is because all NI multi port serial cards
use PCI_CLASS_COMMUNICATION_OTHER class and thus fail the
serial_pci_is_class_communication test added in the commit 7d8905d06405
("serial: 8250_pci: Enable device after we check black list").
Signed-off-by: Guan Yung Tseng <guan.yung.tseng@ni.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 4986b4a..0949db1 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -663,6 +663,13 @@ static int pci_xircom_init(struct pci_dev *dev)
return 0;
}
+static int pci_ni_probe(struct pci_dev *dev)
+{
+ dev->class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8 |
+ (dev->class & 0xff);
+ return 0;
+}
+
static int pci_ni8420_init(struct pci_dev *dev)
{
void __iomem *p;
@@ -1850,6 +1857,7 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
.device = PCI_DEVICE_ID_NI_PCI23216,
.subvendor = PCI_ANY_ID,
.subdevice = PCI_ANY_ID,
+ .probe = pci_ni_probe,
.init = pci_ni8420_init,
.setup = pci_default_setup,
.exit = pci_ni8420_exit,
@@ -1859,6 +1867,7 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
.device = PCI_DEVICE_ID_NI_PCI2328,
.subvendor = PCI_ANY_ID,
.subdevice = PCI_ANY_ID,
+ .probe = pci_ni_probe,
.init = pci_ni8420_init,
.setup = pci_default_setup,
.exit = pci_ni8420_exit,
@@ -1868,6 +1877,7 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
.device = PCI_DEVICE_ID_NI_PCI2324,
.subvendor = PCI_ANY_ID,
.subdevice = PCI_ANY_ID,
+ .probe = pci_ni_probe,
.init = pci_ni8420_init,
.setup = pci_default_setup,
.exit = pci_ni8420_exit,
@@ -1877,6 +1887,7 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
.device = PCI_DEVICE_ID_NI_PCI2322,
.subvendor = PCI_ANY_ID,
.subdevice = PCI_ANY_ID,
+ .probe = pci_ni_probe,
.init = pci_ni8420_init,
.setup = pci_default_setup,
.exit = pci_ni8420_exit,
@@ -1886,6 +1897,7 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
.device = PCI_DEVICE_ID_NI_PCI2324I,
.subvendor = PCI_ANY_ID,
.subdevice = PCI_ANY_ID,
+ .probe = pci_ni_probe,
.init = pci_ni8420_init,
.setup = pci_default_setup,
.exit = pci_ni8420_exit,
@@ -1895,6 +1907,7 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
.device = PCI_DEVICE_ID_NI_PCI2322I,
.subvendor = PCI_ANY_ID,
.subdevice = PCI_ANY_ID,
+ .probe = pci_ni_probe,
.init = pci_ni8420_init,
.setup = pci_default_setup,
.exit = pci_ni8420_exit,
@@ -1904,6 +1917,7 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
.device = PCI_DEVICE_ID_NI_PXI8420_23216,
.subvendor = PCI_ANY_ID,
.subdevice = PCI_ANY_ID,
+ .probe = pci_ni_probe,
.init = pci_ni8420_init,
.setup = pci_default_setup,
.exit = pci_ni8420_exit,
@@ -1913,6 +1927,7 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
.device = PCI_DEVICE_ID_NI_PXI8420_2328,
.subvendor = PCI_ANY_ID,
.subdevice = PCI_ANY_ID,
+ .probe = pci_ni_probe,
.init = pci_ni8420_init,
.setup = pci_default_setup,
.exit = pci_ni8420_exit,
@@ -1922,6 +1937,7 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
.device = PCI_DEVICE_ID_NI_PXI8420_2324,
.subvendor = PCI_ANY_ID,
.subdevice = PCI_ANY_ID,
+ .probe = pci_ni_probe,
.init = pci_ni8420_init,
.setup = pci_default_setup,
.exit = pci_ni8420_exit,
@@ -1931,6 +1947,7 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
.device = PCI_DEVICE_ID_NI_PXI8420_2322,
.subvendor = PCI_ANY_ID,
.subdevice = PCI_ANY_ID,
+ .probe = pci_ni_probe,
.init = pci_ni8420_init,
.setup = pci_default_setup,
.exit = pci_ni8420_exit,
@@ -1940,6 +1957,7 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
.device = PCI_DEVICE_ID_NI_PXI8422_2324,
.subvendor = PCI_ANY_ID,
.subdevice = PCI_ANY_ID,
+ .probe = pci_ni_probe,
.init = pci_ni8420_init,
.setup = pci_default_setup,
.exit = pci_ni8420_exit,
@@ -1949,6 +1967,7 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
.device = PCI_DEVICE_ID_NI_PXI8422_2322,
.subvendor = PCI_ANY_ID,
.subdevice = PCI_ANY_ID,
+ .probe = pci_ni_probe,
.init = pci_ni8420_init,
.setup = pci_default_setup,
.exit = pci_ni8420_exit,
@@ -1958,6 +1977,7 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
.device = PCI_ANY_ID,
.subvendor = PCI_ANY_ID,
.subdevice = PCI_ANY_ID,
+ .probe = pci_ni_probe,
.init = pci_ni8430_init,
.setup = pci_ni8430_setup,
.exit = pci_ni8430_exit,
--
2.7.4
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH] 8250_pci.c: Update NI specific devices class to multi serial
2019-01-14 14:10 [PATCH] 8250_pci.c: Update NI specific devices class to multi serial Guan Yung Tseng
@ 2019-01-18 11:57 ` Greg KH
2019-01-22 11:55 ` Heikki Krogerus
2019-01-23 15:18 ` Andy Shevchenko
2 siblings, 0 replies; 9+ messages in thread
From: Greg KH @ 2019-01-18 11:57 UTC (permalink / raw)
To: Guan Yung Tseng; +Cc: linux-serial, linux-kernel
On Mon, Jan 14, 2019 at 10:10:05PM +0800, Guan Yung Tseng wrote:
> Modified NI devices class to PCI_CLASS_COMMUNICATION_MULTISERIAL.
> The reason of doing this is because all NI multi port serial cards
> use PCI_CLASS_COMMUNICATION_OTHER class and thus fail the
> serial_pci_is_class_communication test added in the commit 7d8905d06405
> ("serial: 8250_pci: Enable device after we check black list").
>
> Signed-off-by: Guan Yung Tseng <guan.yung.tseng@ni.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 4986b4a..0949db1 100644
> --- a/drivers/tty/serial/8250/8250_pci.c
> +++ b/drivers/tty/serial/8250/8250_pci.c
> @@ -663,6 +663,13 @@ static int pci_xircom_init(struct pci_dev *dev)
> return 0;
> }
>
> +static int pci_ni_probe(struct pci_dev *dev)
> +{
> + dev->class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8 |
> + (dev->class & 0xff);
As Christoph said, this looks really odd. This field comes from the
PCI structure on the device, it should not be modified by the kernel.
Unless the device is broken and needs to be fixed up in the kernel?
Also, you have sent 2 different patches here for this type of issue, are
both needed? If so, please resend both of them as a patch series, with
more explainations in this one as to why you are modifying this field.
I've dropped all pending patches from you from my queue now.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH] 8250_pci.c: Update NI specific devices class to multi serial
2019-01-14 14:10 [PATCH] 8250_pci.c: Update NI specific devices class to multi serial Guan Yung Tseng
2019-01-18 11:57 ` Greg KH
@ 2019-01-22 11:55 ` Heikki Krogerus
2019-01-23 14:11 ` Andy Shevchenko
2019-01-23 15:18 ` Andy Shevchenko
2 siblings, 1 reply; 9+ messages in thread
From: Heikki Krogerus @ 2019-01-22 11:55 UTC (permalink / raw)
To: Guan Yung Tseng, Andy Shevchenko; +Cc: gregkh, linux-serial, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]
+Andy
On Mon, Jan 14, 2019 at 10:10:05PM +0800, Guan Yung Tseng wrote:
> Modified NI devices class to PCI_CLASS_COMMUNICATION_MULTISERIAL.
> The reason of doing this is because all NI multi port serial cards
> use PCI_CLASS_COMMUNICATION_OTHER class and thus fail the
> serial_pci_is_class_communication test added in the commit 7d8905d06405
> ("serial: 8250_pci: Enable device after we check black list").
OK, so commit 7d8905d06405 ("serial: 8250_pci: Enable device after we
check black list") has created a regression. If the device does not
use PCI_CLASS_COMMUNICATION*SERIAL class, probe will fail, and I
don't think that is how the driver should function.
If the device id is listed in serial_pci_tbl, we need to probe the
device, regardless of the class id.
> Signed-off-by: Guan Yung Tseng <guan.yung.tseng@ni.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 4986b4a..0949db1 100644
> --- a/drivers/tty/serial/8250/8250_pci.c
> +++ b/drivers/tty/serial/8250/8250_pci.c
> @@ -663,6 +663,13 @@ static int pci_xircom_init(struct pci_dev *dev)
> return 0;
> }
>
> +static int pci_ni_probe(struct pci_dev *dev)
> +{
> + dev->class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8 |
> + (dev->class & 0xff);
> + return 0;
> +}
This is only working around the regression that 7d8905d064058 created,
and only with your UART. There may be others.
We need to fix the regression, not work around it. How about something
like the attached diff?
thanks,
--
heikki
[-- Attachment #2: improved_7d8905d064058.diff --]
[-- Type: text/plain, Size: 2360 bytes --]
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index f80a300b5d68..8b555c3a3670 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -3375,10 +3375,22 @@ static const struct pci_device_id blacklist[] = {
/* Exar devices */
{ PCI_VDEVICE(EXAR, PCI_ANY_ID), },
{ PCI_VDEVICE(COMMTECH, PCI_ANY_ID), },
+ { }
};
-static int serial_pci_is_class_communication(struct pci_dev *dev)
+/*
+ * Given a complete unknown PCI device, try to use some heuristics to
+ * guess what the configuration might be, based on the pitiful PCI
+ * serial specs. Returns 0 on success, -ENODEV on failure.
+ */
+static int
+serial_pci_guess_board(struct pci_dev *dev, struct pciserial_board *board)
{
+ int first_port = -1;
+ int num_iomem;
+ int num_port;
+ int i;
+
/*
* If it is not a communications device or the programming
* interface is greater than 6, give up.
@@ -3389,38 +3401,6 @@ static int serial_pci_is_class_communication(struct pci_dev *dev)
(dev->class & 0xff) > 6)
return -ENODEV;
- return 0;
-}
-
-static int serial_pci_is_blacklisted(struct pci_dev *dev)
-{
- const struct pci_device_id *bldev;
-
- /*
- * Do not access blacklisted devices that are known not to
- * feature serial ports or are handled by other modules.
- */
- for (bldev = blacklist;
- bldev < blacklist + ARRAY_SIZE(blacklist);
- bldev++) {
- if (dev->vendor == bldev->vendor &&
- dev->device == bldev->device)
- return -ENODEV;
- }
-
- return 0;
-}
-
-/*
- * Given a complete unknown PCI device, try to use some heuristics to
- * guess what the configuration might be, based on the pitiful PCI
- * serial specs. Returns 0 on success, -ENODEV on failure.
- */
-static int
-serial_pci_guess_board(struct pci_dev *dev, struct pciserial_board *board)
-{
- int num_iomem, num_port, first_port = -1, i;
-
/*
* Should we try to make guesses for multiport serial devices later?
*/
@@ -3647,13 +3627,8 @@ pciserial_init_one(struct pci_dev *dev, const struct pci_device_id *ent)
board = &pci_boards[ent->driver_data];
- rc = serial_pci_is_class_communication(dev);
- if (rc)
- return rc;
-
- rc = serial_pci_is_blacklisted(dev);
- if (rc)
- return rc;
+ if (pci_match_id(blacklist, dev))
+ return -ENODEV;
rc = pcim_enable_device(dev);
pci_save_state(dev);
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH] 8250_pci.c: Update NI specific devices class to multi serial
2019-01-22 11:55 ` Heikki Krogerus
@ 2019-01-23 14:11 ` Andy Shevchenko
0 siblings, 0 replies; 9+ messages in thread
From: Andy Shevchenko @ 2019-01-23 14:11 UTC (permalink / raw)
To: Heikki Krogerus; +Cc: Guan Yung Tseng, gregkh, linux-serial, linux-kernel
On Tue, Jan 22, 2019 at 01:55:08PM +0200, Heikki Krogerus wrote:
> On Mon, Jan 14, 2019 at 10:10:05PM +0800, Guan Yung Tseng wrote:
> > Modified NI devices class to PCI_CLASS_COMMUNICATION_MULTISERIAL.
> > The reason of doing this is because all NI multi port serial cards
> > use PCI_CLASS_COMMUNICATION_OTHER class and thus fail the
> > serial_pci_is_class_communication test added in the commit 7d8905d06405
> > ("serial: 8250_pci: Enable device after we check black list").
>
> OK, so commit 7d8905d06405 ("serial: 8250_pci: Enable device after we
> check black list") has created a regression. If the device does not
> use PCI_CLASS_COMMUNICATION*SERIAL class, probe will fail, and I
> don't think that is how the driver should function.
>
> If the device id is listed in serial_pci_tbl, we need to probe the
> device, regardless of the class id.
I need to check what should be a better fix.
> This is only working around the regression that 7d8905d064058 created,
> and only with your UART. There may be others.
>
> We need to fix the regression, not work around it. How about something
> like the attached diff?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] 8250_pci.c: Update NI specific devices class to multi serial
2019-01-14 14:10 [PATCH] 8250_pci.c: Update NI specific devices class to multi serial Guan Yung Tseng
2019-01-18 11:57 ` Greg KH
2019-01-22 11:55 ` Heikki Krogerus
@ 2019-01-23 15:18 ` Andy Shevchenko
2019-01-23 16:06 ` Andy Shevchenko
2 siblings, 1 reply; 9+ messages in thread
From: Andy Shevchenko @ 2019-01-23 15:18 UTC (permalink / raw)
To: Guan Yung Tseng
Cc: Greg Kroah-Hartman, open list:SERIAL DRIVERS,
Linux Kernel Mailing List
On Mon, Jan 14, 2019 at 4:13 PM Guan Yung Tseng <guan.yung.tseng@ni.com> wrote:
>
> Modified NI devices class to PCI_CLASS_COMMUNICATION_MULTISERIAL.
> The reason of doing this is because all NI multi port serial cards
> use PCI_CLASS_COMMUNICATION_OTHER class and thus fail the
> serial_pci_is_class_communication test added in the commit 7d8905d06405
> ("serial: 8250_pci: Enable device after we check black list").
Guan, can you provide an output of the
lspci -nk -xx -vv -s <BDF>
of your device, where <BDF> is a PCI address in a form of bus:device.function?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH] 8250_pci.c: Update NI specific devices class to multi serial
2019-01-23 15:18 ` Andy Shevchenko
@ 2019-01-23 16:06 ` Andy Shevchenko
[not found] ` <d24b4177fda84042b4f59f2bb77e149e@atfkex01.bachmann.at>
2019-01-28 8:04 ` Guan Yung Tseng
0 siblings, 2 replies; 9+ messages in thread
From: Andy Shevchenko @ 2019-01-23 16:06 UTC (permalink / raw)
To: Guan Yung Tseng
Cc: Greg Kroah-Hartman, open list:SERIAL DRIVERS,
Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 817 bytes --]
On Wed, Jan 23, 2019 at 5:18 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Mon, Jan 14, 2019 at 4:13 PM Guan Yung Tseng <guan.yung.tseng@ni.com> wrote:
> >
> > Modified NI devices class to PCI_CLASS_COMMUNICATION_MULTISERIAL.
> > The reason of doing this is because all NI multi port serial cards
> > use PCI_CLASS_COMMUNICATION_OTHER class and thus fail the
> > serial_pci_is_class_communication test added in the commit 7d8905d06405
> > ("serial: 8250_pci: Enable device after we check black list").
>
> Guan, can you provide an output of the
>
> lspci -nk -xx -vv -s <BDF>
>
> of your device, where <BDF> is a PCI address in a form of bus:device.function?
While I'm still wondering of the above, can you also test the bellow
patch if it fixes your issue?
--
With Best Regards,
Andy Shevchenko
[-- Attachment #2: 8250-pci-1.diff --]
[-- Type: text/x-patch, Size: 805 bytes --]
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index f80a300b5d68..48bd694a5fa1 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -3420,6 +3420,11 @@ static int
serial_pci_guess_board(struct pci_dev *dev, struct pciserial_board *board)
{
int num_iomem, num_port, first_port = -1, i;
+ int rc;
+
+ rc = serial_pci_is_class_communication(dev);
+ if (rc)
+ return rc;
/*
* Should we try to make guesses for multiport serial devices later?
@@ -3647,10 +3652,6 @@ pciserial_init_one(struct pci_dev *dev, const struct pci_device_id *ent)
board = &pci_boards[ent->driver_data];
- rc = serial_pci_is_class_communication(dev);
- if (rc)
- return rc;
-
rc = serial_pci_is_blacklisted(dev);
if (rc)
return rc;
^ permalink raw reply related [flat|nested] 9+ messages in thread[parent not found: <d24b4177fda84042b4f59f2bb77e149e@atfkex01.bachmann.at>]
* Re: [PATCH] 8250_pci.c: Update NI specific devices class to multi serial
[not found] ` <d24b4177fda84042b4f59f2bb77e149e@atfkex01.bachmann.at>
@ 2019-01-24 22:47 ` Andy Shevchenko
0 siblings, 0 replies; 9+ messages in thread
From: Andy Shevchenko @ 2019-01-24 22:47 UTC (permalink / raw)
To: KHUENY.Gerhard
Cc: Guan Yung Tseng, Greg Kroah-Hartman, open list:SERIAL DRIVERS,
Linux Kernel Mailing List
On Thu, Jan 24, 2019 at 1:15 PM KHUENY.Gerhard
<Gerhard.KHUENY@bachmann.info> wrote:
>
> Hi,
>
> I would appreciate this change since this would solve my problem also ;-)
>
I have sent couple of hours ago the patch to upstream. If I'm not
mistaken, you did test it and I put deliberatly your tag. Tell me if
it's not the case or, if you have a chance, test it.
> Best regards,
> Gerhard Khüny
>
> -----Ursprüngliche Nachricht-----
> Von: linux-serial-owner@vger.kernel.org <linux-serial-owner@vger.kernel.org> Im Auftrag von Andy Shevchenko
> Gesendet: Mittwoch, 23. Jänner 2019 17:07
> An: Guan Yung Tseng <guan.yung.tseng@ni.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>; open list:SERIAL DRIVERS <linux-serial@vger.kernel.org>; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Betreff: Re: [PATCH] 8250_pci.c: Update NI specific devices class to multi serial
>
> On Wed, Jan 23, 2019 at 5:18 PM Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> >
> > On Mon, Jan 14, 2019 at 4:13 PM Guan Yung Tseng <guan.yung.tseng@ni.com> wrote:
> > >
> > > Modified NI devices class to PCI_CLASS_COMMUNICATION_MULTISERIAL.
> > > The reason of doing this is because all NI multi port serial cards
> > > use PCI_CLASS_COMMUNICATION_OTHER class and thus fail the
> > > serial_pci_is_class_communication test added in the commit
> > > 7d8905d06405
> > > ("serial: 8250_pci: Enable device after we check black list").
> >
> > Guan, can you provide an output of the
> >
> > lspci -nk -xx -vv -s <BDF>
> >
> > of your device, where <BDF> is a PCI address in a form of bus:device.function?
>
> While I'm still wondering of the above, can you also test the bellow patch if it fixes your issue?
>
>
>
>
> --
> With Best Regards,
> Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [PATCH] 8250_pci.c: Update NI specific devices class to multi serial
2019-01-23 16:06 ` Andy Shevchenko
[not found] ` <d24b4177fda84042b4f59f2bb77e149e@atfkex01.bachmann.at>
@ 2019-01-28 8:04 ` Guan Yung Tseng
1 sibling, 0 replies; 9+ messages in thread
From: Guan Yung Tseng @ 2019-01-28 8:04 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Greg Kroah-Hartman, open list:SERIAL DRIVERS,
Linux Kernel Mailing List
> On Wed, Jan 23, 2019 at 5:18 PM Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> >
> > On Mon, Jan 14, 2019 at 4:13 PM Guan Yung Tseng <guan.yung.tseng@ni.com> wrote:
> > >
> > > Modified NI devices class to PCI_CLASS_COMMUNICATION_MULTISERIAL.
> > > The reason of doing this is because all NI multi port serial cards
> > > use PCI_CLASS_COMMUNICATION_OTHER class and thus fail the
> > > serial_pci_is_class_communication test added in the commit
> > > 7d8905d06405
> > > ("serial: 8250_pci: Enable device after we check black list").
> >
> > Guan, can you provide an output of the
> >
> > lspci -nk -xx -vv -s <BDF>
> >
> > of your device, where <BDF> is a PCI address in a form of bus:device.function?
>
Output of lspci before applied the patch
admin@NI-PXIe-8840Quad-Core-0308D657:~# lspci -nk -xx -vv -s 0d:0e.0
0d:0e.0 0780: 1093:70e8
Subsystem: 1093:70e8
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping
- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <M
Abort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 10
Region 0: Memory at fe201000 (32-bit, non-prefetchable) [disabled] [size=4K]
00: 93 10 e8 70 40 01 80 02 00 00 80 07 10 20 00 00
10: 00 10 20 fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 93 10 e8 70
30: 00 00 00 00 f0 00 00 00 00 00 00 00 0a 01 00 00
admin@NI-PXIe-8840Quad-Core-0308D657:~# lspci -nk -xx -vv -s 0d:0f.0
0d:0f.0 0780: 1093:70ec
Subsystem: 1093:70ec
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping
- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <M
Abort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 11
Region 0: Memory at fe200000 (32-bit, non-prefetchable) [disabled] [size=4K]
00: 93 10 ec 70 40 01 80 02 00 00 80 07 10 20 00 00
10: 00 00 20 fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 93 10 ec 70
30: 00 00 00 00 f0 00 00 00 00 00 00 00 0b 01 00 00
> While I'm still wondering of the above, can you also test the bellow patch if it fixes your issue?
The patch fixes the issue. The devices bind to the serial kernel driver successfully.
Below is the output of lspci -nk -xx -vv -s <BDF> for the same devices after I applied the patch.
admin@NI-PXIe-8840Quad-Core-0308D657:~# lspci -nk -xx -vv -s 0d:0e.0
0d:0e.0 0780: 1093:70e8
Subsystem: 1093:70e8
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping
- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <M
Abort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 17
Region 0: Memory at fe201000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: serial
00: 93 10 e8 70 42 01 80 02 00 00 80 07 10 20 00 00
10: 00 10 20 fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 93 10 e8 70
30: 00 00 00 00 f0 00 00 00 00 00 00 00 0a 01 00 00
admin@NI-PXIe-8840Quad-Core-0308D657:~# lspci -nk -xx -vv -s 0d:0f.0
0d:0f.0 0780: 1093:70ec
Subsystem: 1093:70ec
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping
- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <M
Abort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 18
Region 0: Memory at fe200000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: serial
00: 93 10 ec 70 42 01 80 02 00 00 80 07 10 20 00 00
10: 00 00 20 fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 93 10 ec 70
30: 00 00 00 00 f0 00 00 00 00 00 00 00 0b 01 00 00
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] 8250_pci.c: Update NI specific devices class to multi serial
@ 2019-01-24 7:07 Guan Yung Tseng
0 siblings, 0 replies; 9+ messages in thread
From: Guan Yung Tseng @ 2019-01-24 7:07 UTC (permalink / raw)
To: andy.shevchenko; +Cc: gregkh, linux-serial, linux-kernel, Guan Yung Tseng
> On Wed, Jan 23, 2019 at 5:18 PM Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> >
> > On Mon, Jan 14, 2019 at 4:13 PM Guan Yung Tseng <guan.yung.tseng@ni.com> wrote:
> > >
> > > Modified NI devices class to PCI_CLASS_COMMUNICATION_MULTISERIAL.
> > > The reason of doing this is because all NI multi port serial cards
> > > use PCI_CLASS_COMMUNICATION_OTHER class and thus fail the
> > > serial_pci_is_class_communication test added in the commit
> > > 7d8905d06405
> > > ("serial: 8250_pci: Enable device after we check black list").
> >
> > Guan, can you provide an output of the
> >
> > lspci -nk -xx -vv -s <BDF>
> >
> > of your device, where <BDF> is a PCI address in a form of bus:device.function?
>
Output of lspci before applied the patch
admin@NI-PXIe-8840Quad-Core-0308D657:~# lspci -nk -xx -vv -s 0d:0e.0
0d:0e.0 0780: 1093:70e8
Subsystem: 1093:70e8
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping
- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <M
Abort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 10
Region 0: Memory at fe201000 (32-bit, non-prefetchable) [disabled] [size=4K]
00: 93 10 e8 70 40 01 80 02 00 00 80 07 10 20 00 00
10: 00 10 20 fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 93 10 e8 70
30: 00 00 00 00 f0 00 00 00 00 00 00 00 0a 01 00 00
admin@NI-PXIe-8840Quad-Core-0308D657:~# lspci -nk -xx -vv -s 0d:0f.0
0d:0f.0 0780: 1093:70ec
Subsystem: 1093:70ec
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping
- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <M
Abort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 11
Region 0: Memory at fe200000 (32-bit, non-prefetchable) [disabled] [size=4K]
00: 93 10 ec 70 40 01 80 02 00 00 80 07 10 20 00 00
10: 00 00 20 fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 93 10 ec 70
30: 00 00 00 00 f0 00 00 00 00 00 00 00 0b 01 00 00
> While I'm still wondering of the above, can you also test the bellow patch if it fixes your issue?
The patch fixes the issue. The devices bind to the serial kernel driver successfully.
Below is the output of lspci -nk -xx -vv -s <BDF> for the same devices after I applied the patch.
admin@NI-PXIe-8840Quad-Core-0308D657:~# lspci -nk -xx -vv -s 0d:0e.0
0d:0e.0 0780: 1093:70e8
Subsystem: 1093:70e8
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping
- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <M
Abort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 17
Region 0: Memory at fe201000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: serial
00: 93 10 e8 70 42 01 80 02 00 00 80 07 10 20 00 00
10: 00 10 20 fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 93 10 e8 70
30: 00 00 00 00 f0 00 00 00 00 00 00 00 0a 01 00 00
admin@NI-PXIe-8840Quad-Core-0308D657:~# lspci -nk -xx -vv -s 0d:0f.0
0d:0f.0 0780: 1093:70ec
Subsystem: 1093:70ec
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping
- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <M
Abort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 18
Region 0: Memory at fe200000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: serial
00: 93 10 ec 70 42 01 80 02 00 00 80 07 10 20 00 00
10: 00 00 20 fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 93 10 ec 70
30: 00 00 00 00 f0 00 00 00 00 00 00 00 0b 01 00 00
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-01-28 8:04 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-01-14 14:10 [PATCH] 8250_pci.c: Update NI specific devices class to multi serial Guan Yung Tseng
2019-01-18 11:57 ` Greg KH
2019-01-22 11:55 ` Heikki Krogerus
2019-01-23 14:11 ` Andy Shevchenko
2019-01-23 15:18 ` Andy Shevchenko
2019-01-23 16:06 ` Andy Shevchenko
[not found] ` <d24b4177fda84042b4f59f2bb77e149e@atfkex01.bachmann.at>
2019-01-24 22:47 ` Andy Shevchenko
2019-01-28 8:04 ` Guan Yung Tseng
-- strict thread matches above, loose matches on Subject: below --
2019-01-24 7:07 Guan Yung Tseng
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).