LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Ralf Ramsauer <ralf.ramsauer@oth-regensburg.de>
To: Jiri Slaby <jirislaby@kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	<linux-serial@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [EXT] Re: [PATCH v1 3/4] serial: 8250_pci: Always try MSI/MSI-X
Date: Wed, 14 Jul 2021 14:49:51 +0200	[thread overview]
Message-ID: <784629f9-677e-ee53-aceb-89397ce0951a@oth-regensburg.de> (raw)
In-Reply-To: <9af24b96-8119-7ccf-f0d0-d725af80aa0b@kernel.org>



On 14/07/2021 08:54, Jiri Slaby wrote:
> On 13. 07. 21, 12:40, Andy Shevchenko wrote:
>> There is no need to try MSI/MSI-X only on selected devices.
>> If MSI is not supported while neing advertised it means device
> 
> being
> 
>> is broken and we rather introduce a list of such devices which
>> hopefully will be small or never appear.
> 
> Hmm, have you checked the commit which introduced the whitelist?
> 
>     Nevertheless, this needs to handled with care: while many 8250 devices
>     actually claim to support MSI(-X) interrupts it should not be
> enabled be
>     default. I had at least one device in my hands with broken MSI
>     implementation.
> 
>     So better introduce a whitelist with devices that are known to support
>     MSI(-X) interrupts. I tested all devices mentioned in the patch.
> 
> 
> You should have at least CCed the author for an input.

Yep, back then I was testing three different 8250 pci cards. All of them
claimed to support MSI, while one really worked with MSI, the one that I
whitelisted. So I thought it would be better to use legacy IRQs as long
as no one tested a specific card to work with MSI.

> 
>> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>> ---
>>   drivers/tty/serial/8250/8250_pci.c | 28 ++++++++--------------------
>>   1 file changed, 8 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/tty/serial/8250/8250_pci.c
>> b/drivers/tty/serial/8250/8250_pci.c
>> index 937861327aca..02825c8c5f84 100644
>> --- a/drivers/tty/serial/8250/8250_pci.c
>> +++ b/drivers/tty/serial/8250/8250_pci.c
>> @@ -58,18 +58,6 @@ struct serial_private {
>>     #define PCI_DEVICE_ID_HPE_PCI_SERIAL    0x37e
>>   -static const struct pci_device_id pci_use_msi[] = {
>> -    { PCI_DEVICE_SUB(PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9900,
>> -             0xA000, 0x1000) },
>> -    { PCI_DEVICE_SUB(PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9912,
>> -             0xA000, 0x1000) },
>> -    { PCI_DEVICE_SUB(PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9922,
>> -             0xA000, 0x1000) },
>> -    { PCI_DEVICE_SUB(PCI_VENDOR_ID_HP_3PAR,
>> PCI_DEVICE_ID_HPE_PCI_SERIAL,
>> -             PCI_ANY_ID, PCI_ANY_ID) },
>> -    { }
>> -};
>> -

Don't do that… And don't convert it to a blacklist. A blacklist will
break users until they report that something doesn't work.

  Ralf

>>   static int pci_default_setup(struct serial_private*,
>>         const struct pciserial_board*, struct uart_8250_port *, int);
>>   @@ -3994,14 +3982,9 @@ pciserial_init_ports(struct pci_dev *dev,
>> const struct pciserial_board *board)
>>       if (board->flags & FL_NOIRQ) {
>>           uart.port.irq = 0;
>>       } else {
>> -        if (pci_match_id(pci_use_msi, dev)) {
>> -            dev_dbg(&dev->dev, "Using MSI(-X) interrupts\n");
>> -            pci_set_master(dev);
>> -            rc = pci_alloc_irq_vectors(dev, 1, 1, PCI_IRQ_ALL_TYPES);
>> -        } else {
>> -            dev_dbg(&dev->dev, "Using legacy interrupts\n");
>> -            rc = pci_alloc_irq_vectors(dev, 1, 1, PCI_IRQ_LEGACY);
>> -        }
>> +        pci_set_master(dev);
> 
> But bus mastering is not about MSIs. I *think* it's still OK, but you
> need to document that in the commit log too.
> 
> Actually, why the commit which added this code turns on bus mastering?
> 
>> +
>> +        rc = pci_alloc_irq_vectors(dev, 1, 1, PCI_IRQ_ALL_TYPES);
>>           if (rc < 0) {
>>               kfree(priv);
>>               priv = ERR_PTR(rc);
>> @@ -4009,6 +3992,11 @@ pciserial_init_ports(struct pci_dev *dev, const
>> struct pciserial_board *board)
>>           }
>>             uart.port.irq = pci_irq_vector(dev, 0);
>> +
>> +        if (pci_dev_msi_enabled(dev))
>> +            dev_dbg(&dev->dev, "Using MSI(-X) interrupts\n");
>> +        else
>> +            dev_dbg(&dev->dev, "Using legacy interrupts\n");
>>       }
>>         uart.port.dev = &dev->dev;
>>
> 
> thanks,

  parent reply	other threads:[~2021-07-14 12:55 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-13 10:40 [PATCH v1 1/4] serial: 8250_pci: Refactor the loop in pci_ite887x_init() Andy Shevchenko
2021-07-13 10:40 ` [PATCH v1 2/4] serial: 8250_pci: Get rid of redundant 'else' keyword Andy Shevchenko
2021-07-13 10:40 ` [PATCH v1 3/4] serial: 8250_pci: Always try MSI/MSI-X Andy Shevchenko
2021-07-14  6:54   ` Jiri Slaby
2021-07-14  7:58     ` Jiri Slaby
2021-07-14  9:31       ` Andy Shevchenko
2021-07-14  9:15     ` Andy Shevchenko
2021-07-14 16:56       ` rwright
2021-07-14 12:49     ` Ralf Ramsauer [this message]
2021-07-14 13:35       ` [EXT] " Andy Shevchenko
2021-07-14 16:49         ` Ralf Ramsauer
2021-07-16 13:07         ` Ralf Ramsauer
2021-07-16 15:01           ` Andy Shevchenko
2021-07-16 15:27             ` Ralf Ramsauer
2021-07-16 17:27               ` Andy Shevchenko
2021-07-17 12:44                 ` Ralf Ramsauer
2021-07-13 10:40 ` [PATCH v1 4/4] serial: 8250_pci: Replace dev_*() by pci_*() macros Andy Shevchenko
2021-07-13 21:05   ` Joe Perches
2021-07-14  6:57 ` [PATCH v1 1/4] serial: 8250_pci: Refactor the loop in pci_ite887x_init() Jiri Slaby
2021-07-14 12:37   ` Andy Shevchenko
2021-07-14  8:07 ` Dan Carpenter
2021-07-14 10:44 ` Joe Perches
2021-07-14 12:36   ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=784629f9-677e-ee53-aceb-89397ce0951a@oth-regensburg.de \
    --to=ralf.ramsauer@oth-regensburg.de \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --subject='Re: [EXT] Re: [PATCH v1 3/4] serial: 8250_pci: Always try MSI/MSI-X' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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