On Tue, Mar 13, 2018 at 04:45:49PM -0500, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> If a device already has MSI or MSI-X enabled, there's no need to set up its
> legacy INTx interrupt.
>
> bba6f6fc68e7 ("[PATCH] MSI-X: fix resume crash") changed the cris, frv,
> x86,
On Tue, Mar 13, 2018 at 04:45:49PM -0500, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> If a device already has MSI or MSI-X enabled, there's no need to set up its
> legacy INTx interrupt.
>
> bba6f6fc68e7 ("[PATCH] MSI-X: fix resume crash") changed the cris, frv,
> x86, and ia64 arches to
On Wed, Mar 14, 2018 at 7:49 PM, Bjorn Helgaas wrote:
> On Wed, Mar 14, 2018 at 06:31:38PM +0200, Andy Shevchenko wrote:
>> On Tue, Mar 13, 2018 at 11:45 PM, Bjorn Helgaas wrote:
>> > If a device already has MSI or MSI-X enabled, there's no need to set up
On Wed, Mar 14, 2018 at 7:49 PM, Bjorn Helgaas wrote:
> On Wed, Mar 14, 2018 at 06:31:38PM +0200, Andy Shevchenko wrote:
>> On Tue, Mar 13, 2018 at 11:45 PM, Bjorn Helgaas wrote:
>> > If a device already has MSI or MSI-X enabled, there's no need to set up its
>> > legacy INTx interrupt.
>>
>>
On Wed, Mar 14, 2018 at 06:31:38PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 13, 2018 at 11:45 PM, Bjorn Helgaas wrote:
> > From: Bjorn Helgaas
>
> Agree with Christoph's comment.
>
> > If a device already has MSI or MSI-X enabled, there's no need to
On Wed, Mar 14, 2018 at 06:31:38PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 13, 2018 at 11:45 PM, Bjorn Helgaas wrote:
> > From: Bjorn Helgaas
>
> Agree with Christoph's comment.
>
> > If a device already has MSI or MSI-X enabled, there's no need to set up its
> > legacy INTx interrupt.
>
On Wed, Mar 14, 2018 at 01:35:19AM -0700, Christoph Hellwig wrote:
> Should this logic go into a little helper so that everyone is kept
> in sync?
Great point, thanks! What I'd really like is to completely get rid of
most of the pcibios_enable_device() implementations. Most of them
contain
On Wed, Mar 14, 2018 at 01:35:19AM -0700, Christoph Hellwig wrote:
> Should this logic go into a little helper so that everyone is kept
> in sync?
Great point, thanks! What I'd really like is to completely get rid of
most of the pcibios_enable_device() implementations. Most of them
contain
On Tue, Mar 13, 2018 at 11:45 PM, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
Agree with Christoph's comment.
> If a device already has MSI or MSI-X enabled, there's no need to set up its
> legacy INTx interrupt.
Just point to the actual behaviour of
On Tue, Mar 13, 2018 at 11:45 PM, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
Agree with Christoph's comment.
> If a device already has MSI or MSI-X enabled, there's no need to set up its
> legacy INTx interrupt.
Just point to the actual behaviour of this. In some cases code in
question has
On 3/13/2018 10:45 PM, Bjorn Helgaas wrote:
From: Bjorn Helgaas
If a device already has MSI or MSI-X enabled, there's no need to set up its
legacy INTx interrupt.
bba6f6fc68e7 ("[PATCH] MSI-X: fix resume crash") changed the cris, frv,
x86, and ia64 arches to skip INTx
On 3/13/2018 10:45 PM, Bjorn Helgaas wrote:
From: Bjorn Helgaas
If a device already has MSI or MSI-X enabled, there's no need to set up its
legacy INTx interrupt.
bba6f6fc68e7 ("[PATCH] MSI-X: fix resume crash") changed the cris, frv,
x86, and ia64 arches to skip INTx setup when MSI is
Should this logic go into a little helper so that everyone is kept
in sync?
Should this logic go into a little helper so that everyone is kept
in sync?
> Change the remaining arches (cris, frv, and ia64) to skip INTx setup when
> either MSI or MSI-X is enabled.
My ia64 still boots with this patch applied (and doesn't have any new/different
messages
in the console log). So:
Tested-by: Tony Luck
-Tony
> Change the remaining arches (cris, frv, and ia64) to skip INTx setup when
> either MSI or MSI-X is enabled.
My ia64 still boots with this patch applied (and doesn't have any new/different
messages
in the console log). So:
Tested-by: Tony Luck
-Tony
16 matches
Mail list logo