All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dennis Chen <dennis.chen@arm.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-ide@vger.kernel.org,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Steve Capper <steve.capper@arm.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	linux-pci@vger.kernel.org,
	Tom Long Nguyen <tom.l.nguyen@intel.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Tejun Heo <tj@kernel.org>,
	nd@arm.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] PCI:MSI Return -ENOSPC when requested vectors is not enough
Date: Fri, 2 Dec 2016 14:04:41 +0800	[thread overview]
Message-ID: <20161202060440.GA16167@arm.com> (raw)
In-Reply-To: <20161201085243.GA24684@lst.de>

On Thu, Dec 01, 2016 at 09:52:43AM +0100, Christoph Hellwig wrote:
> Hi Dennis,
> 
> I've fixed ahci to treat all errors the same in the meantime, please
> try latest Linux tree.  That being said I don't like the different
> error returns from __pci_enable_msi_range (and __pci_enable_msix_range),
> but they have been there for a while.

Ah, I've noticed that you have the fix recently which is somehow to weaken
the necessary of the change. But, that also being said that I don't like we insist
at least the inconsistent either just because something has been there *for a while*.
Both below comments from cpi_alloc_irq_vectors_affinity() and the logic itself
leads us to think that the correct return value is -NOSPC:
/**
 *...
 *Return the number of vectors allocated,
 * (which might be smaller than @max_vecs) if successful, or a negative
 * error code on error. If less than @min_vecs interrupt vectors are
 * available for @dev the function will fail with -ENOSPC.
 * ...
*/

People maybe argue that almost has no device drivers depending on the different
return value, then why we still need to do that?

Thanks,
Dennis 

WARNING: multiple messages have this Message-ID (diff)
From: Dennis Chen <dennis.chen@arm.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-ide@vger.kernel.org,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Steve Capper <steve.capper@arm.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	linux-pci@vger.kernel.org,
	Tom Long Nguyen <tom.l.nguyen@intel.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Tejun Heo <tj@kernel.org>,
	nd@arm.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] PCI:MSI Return -ENOSPC when requested vectors is not enough
Date: Fri, 2 Dec 2016 14:04:41 +0800	[thread overview]
Message-ID: <20161202060440.GA16167@arm.com> (raw)
In-Reply-To: <20161201085243.GA24684@lst.de>

On Thu, Dec 01, 2016 at 09:52:43AM +0100, Christoph Hellwig wrote:
> Hi Dennis,
> 
> I've fixed ahci to treat all errors the same in the meantime, please
> try latest Linux tree.  That being said I don't like the different
> error returns from __pci_enable_msi_range (and __pci_enable_msix_range),
> but they have been there for a while.

Ah, I've noticed that you have the fix recently which is somehow to weaken
the necessary of the change. But, that also being said that I don't like we insist
at least the inconsistent either just because something has been there *for a while*.
Both below comments from cpi_alloc_irq_vectors_affinity() and the logic itself
leads us to think that the correct return value is -NOSPC:
/**
 *...
 *Return the number of vectors allocated,
 * (which might be smaller than @max_vecs) if successful, or a negative
 * error code on error. If less than @min_vecs interrupt vectors are
 * available for @dev the function will fail with -ENOSPC.
 * ...
*/

People maybe argue that almost has no device drivers depending on the different
return value, then why we still need to do that?

Thanks,
Dennis 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: dennis.chen@arm.com (Dennis Chen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] PCI:MSI Return -ENOSPC when requested vectors is not enough
Date: Fri, 2 Dec 2016 14:04:41 +0800	[thread overview]
Message-ID: <20161202060440.GA16167@arm.com> (raw)
In-Reply-To: <20161201085243.GA24684@lst.de>

On Thu, Dec 01, 2016 at 09:52:43AM +0100, Christoph Hellwig wrote:
> Hi Dennis,
> 
> I've fixed ahci to treat all errors the same in the meantime, please
> try latest Linux tree.  That being said I don't like the different
> error returns from __pci_enable_msi_range (and __pci_enable_msix_range),
> but they have been there for a while.

Ah, I've noticed that you have the fix recently which is somehow to weaken
the necessary of the change. But, that also being said that I don't like we insist
at least the inconsistent either just because something has been there *for a while*.
Both below comments from cpi_alloc_irq_vectors_affinity() and the logic itself
leads us to think that the correct return value is -NOSPC:
/**
 *...
 *Return the number of vectors allocated,
 * (which might be smaller than @max_vecs) if successful, or a negative
 * error code on error. If less than @min_vecs interrupt vectors are
 * available for @dev the function will fail with -ENOSPC.
 * ...
*/

People maybe argue that almost has no device drivers depending on the different
return value, then why we still need to do that?

Thanks,
Dennis 

  reply	other threads:[~2016-12-02  6:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-01  2:15 [PATCH] PCI:MSI Return -ENOSPC when requested vectors is not enough Dennis Chen
2016-12-01  2:15 ` Dennis Chen
2016-12-01  2:15 ` Dennis Chen
2016-12-01  8:52 ` Christoph Hellwig
2016-12-01  8:52   ` Christoph Hellwig
2016-12-01  8:52   ` Christoph Hellwig
2016-12-02  6:04   ` Dennis Chen [this message]
2016-12-02  6:04     ` Dennis Chen
2016-12-02  6:04     ` Dennis Chen
2017-01-11 18:18 ` Bjorn Helgaas
2017-01-11 18:18   ` Bjorn Helgaas
2017-01-11 18:18   ` Bjorn Helgaas
2017-01-12 13:42   ` Christoph Hellwig
2017-01-12 13:42     ` Christoph Hellwig
2017-02-10 22:16 ` Bjorn Helgaas
2017-02-10 22:16   ` Bjorn Helgaas
2017-02-10 22:16   ` Bjorn Helgaas

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=20161202060440.GA16167@arm.com \
    --to=dennis.chen@arm.com \
    --cc=bhelgaas@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=marc.zyngier@arm.com \
    --cc=nd@arm.com \
    --cc=steve.capper@arm.com \
    --cc=tj@kernel.org \
    --cc=tom.l.nguyen@intel.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.