All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <marc.zyngier@arm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jiang Liu <jiang.liu@linux.intel.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Andre Przywara <Andre.Przywara@arm.com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Russell King <linux@arm.linux.org.uk>
Subject: Re: [PATCH] PCI: Fix pcibios_update_irq misuse of irq number
Date: Tue, 03 Feb 2015 11:37:30 +0000	[thread overview]
Message-ID: <54D0B2FA.9080600@arm.com> (raw)
In-Reply-To: <4324891.mqG6Yyfi6J@wuerfel>

On 03/02/15 11:31, Arnd Bergmann wrote:
> On Tuesday 03 February 2015 10:38:25 Marc Zyngier wrote:
>>
>> That's exactly what I thought until Lorenzo reported kvmtool falling
>> over because of this write. Obviously, some platforms must actually
>> require this (possibly for bridges that are not known by the firmware).
> 
> This sounds much like a bug in kvmtool.

Lorenzo and I just came to a similar conclusion, given that the HW
should never use that information.

>> Entirely removing that code solves my problem too, but that'd cannot be
>> the right solution...
> 
> The comment in pdev_fixup_irq() says 
> 
>         /* Always tell the device, so the driver knows what is
>            the real IRQ to use; the device does not use it. */
> 
> which I read to mean that there are drivers that incorrectly use
> 'pci_read_config_byte(dev, PCI_INTERRUPT_LINE)' as the number
> they pass into request_irq, rather than using dev->irq.
> However, this means that your patch is actually wrong, because
> what the driver cares about is the virtual irq number (which
> request_irq expects), not the number relative to some interrupt
> controller.

Yes, I now realise that. That makes a lot more sense actually, because I
was getting very confused about how the HW should interpret that number.

Side question: In the probe-only case, should we still allow this write
to happen?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

WARNING: multiple messages have this Message-ID (diff)
From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] PCI: Fix pcibios_update_irq misuse of irq number
Date: Tue, 03 Feb 2015 11:37:30 +0000	[thread overview]
Message-ID: <54D0B2FA.9080600@arm.com> (raw)
In-Reply-To: <4324891.mqG6Yyfi6J@wuerfel>

On 03/02/15 11:31, Arnd Bergmann wrote:
> On Tuesday 03 February 2015 10:38:25 Marc Zyngier wrote:
>>
>> That's exactly what I thought until Lorenzo reported kvmtool falling
>> over because of this write. Obviously, some platforms must actually
>> require this (possibly for bridges that are not known by the firmware).
> 
> This sounds much like a bug in kvmtool.

Lorenzo and I just came to a similar conclusion, given that the HW
should never use that information.

>> Entirely removing that code solves my problem too, but that'd cannot be
>> the right solution...
> 
> The comment in pdev_fixup_irq() says 
> 
>         /* Always tell the device, so the driver knows what is
>            the real IRQ to use; the device does not use it. */
> 
> which I read to mean that there are drivers that incorrectly use
> 'pci_read_config_byte(dev, PCI_INTERRUPT_LINE)' as the number
> they pass into request_irq, rather than using dev->irq.
> However, this means that your patch is actually wrong, because
> what the driver cares about is the virtual irq number (which
> request_irq expects), not the number relative to some interrupt
> controller.

Yes, I now realise that. That makes a lot more sense actually, because I
was getting very confused about how the HW should interpret that number.

Side question: In the probe-only case, should we still allow this write
to happen?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

  reply	other threads:[~2015-02-03 11:37 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-28 14:51 [PATCH] PCI: Fix pcibios_update_irq misuse of irq number Marc Zyngier
2015-01-28 14:51 ` Marc Zyngier
2015-01-28 15:21 ` Jiang Liu
2015-01-28 15:21   ` Jiang Liu
2015-01-28 15:27   ` Marc Zyngier
2015-01-28 15:27     ` Marc Zyngier
2015-01-28 15:43     ` Bjorn Helgaas
2015-01-28 15:43       ` Bjorn Helgaas
2015-02-02 16:15       ` Marc Zyngier
2015-02-02 16:15         ` Marc Zyngier
2015-02-02 16:22         ` Bjorn Helgaas
2015-02-02 16:22           ` Bjorn Helgaas
2015-02-02 15:57 ` Bjorn Helgaas
2015-02-02 15:57   ` Bjorn Helgaas
2015-02-02 16:06   ` Jiang Liu
2015-02-02 16:06     ` Jiang Liu
2015-02-02 16:23   ` Marc Zyngier
2015-02-02 16:23     ` Marc Zyngier
2015-02-02 16:33 ` Russell King - ARM Linux
2015-02-02 16:33   ` Russell King - ARM Linux
2015-02-02 18:08   ` Marc Zyngier
2015-02-02 18:08     ` Marc Zyngier
2015-02-02 18:20     ` Russell King - ARM Linux
2015-02-02 18:20       ` Russell King - ARM Linux
2015-02-02 17:02 ` Arnd Bergmann
2015-02-02 17:02   ` Arnd Bergmann
2015-02-03 10:38   ` Marc Zyngier
2015-02-03 10:38     ` Marc Zyngier
2015-02-03 11:31     ` Arnd Bergmann
2015-02-03 11:31       ` Arnd Bergmann
2015-02-03 11:37       ` Marc Zyngier [this message]
2015-02-03 11:37         ` Marc Zyngier
2015-02-03 12:57         ` Arnd Bergmann
2015-02-03 12:57           ` Arnd Bergmann
2015-02-04 15:39       ` [PATCH] kvmtool: don't use PCI config space IRQ line field Andre Przywara
2015-02-04 15:39         ` Andre Przywara
2015-02-06 18:55         ` Will Deacon
2015-02-06 18:55           ` Will Deacon
2015-02-06 19:02           ` Peter Maydell
2015-02-06 19:02             ` Peter Maydell
2015-02-06 19:07             ` Will Deacon
2015-02-06 19:07               ` Will Deacon
2015-02-07 21:24               ` arnd at arndb.de
2015-02-07 21:24                 ` arnd

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=54D0B2FA.9080600@arm.com \
    --to=marc.zyngier@arm.com \
    --cc=Andre.Przywara@arm.com \
    --cc=Lorenzo.Pieralisi@arm.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=jiang.liu@linux.intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=tglx@linutronix.de \
    /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.