All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
Cc: rjw@rjwysocki.net, linux-acpi@vger.kernel.org,
	linux-kernel@vger.kernel.org, lenb@kernel.org,
	izumi.taku@jp.fujitsu.com, wency@cn.fujitsu.com,
	caoj.fnst@cn.fujitsu.com, ddaney.cavm@gmail.com,
	okaya@codeaurora.org, bhelgaas@google.com,
	jiang.liu@linux.intel.com, linux-pci@vger.kernel.org,
	tglx@linutronix.de, linux@roeck-us.net
Subject: Re: [RESEND PATCH v4] x86/PCI: Recognize that Interrupt Line 255 means "not connected"
Date: Fri, 29 Jan 2016 16:08:12 -0600	[thread overview]
Message-ID: <20160129220812.GF12965@localhost> (raw)
In-Reply-To: <1454038814-3486-1-git-send-email-chen.fan.fnst@cn.fujitsu.com>

On Fri, Jan 29, 2016 at 11:40:14AM +0800, Chen Fan wrote:
> Per the x86-specific footnote to PCI spec r3.0, sec 6.2.4, the value 255 in
> the Interrupt Line register means "unknown" or "no connection."
> Previously, when we couldn't derive an IRQ from the _PRT, we fell back to
> using the value from Interrupt Line as an IRQ.  It's questionable whether
> we should do that at all, but the spec clearly suggests we shouldn't do it
> for the value 255 on x86.
> 
> Calling request_irq() with IRQ 255 may succeed, but the driver won't
> receive any interrupts.  Or, if IRQ 255 is shared with another device, it
> may succeed, and the driver's ISR will be called at random times when the
> *other* device interrupts.  Or it may fail if another device is using IRQ
> 255 with incompatible flags.  What we *want* is for request_irq() to fail
> predictably so the driver can fall back to polling.
> 
> On x86, assume 255 in the Interrupt Line means the INTx line is not
> connected.  In that case, set dev->irq to IRQ_NOTCONNECTED so request_irq()
> will fail gracefully with -ENOTCONN.
> 
> We found this problem on a system where Secure Boot firmware assigned
> Interrupt Line 255 to an i801_smbus device and another device was already
> using MSI-X IRQ 255.  This was in v3.10, where i801_probe() fails if
> request_irq() fails:
> 
>   i801_smbus 0000:00:1f.3: enabling device (0140 -> 0143)
>   i801_smbus 0000:00:1f.3: can't derive routing for PCI INT C
>   i801_smbus 0000:00:1f.3: PCI INT C: no GSI
>   genirq: Flags mismatch irq 255. 00000080 (i801_smbus) vs. 00000000 (megasa)
>   CPU: 0 PID: 2487 Comm: kworker/0:1 Not tainted 3.10.0-229.el7.x86_64 #1
>   Hardware name: FUJITSU PRIMEQUEST 2800E2/D3736, BIOS PRIMEQUEST 2000 Serie5
>   Call Trace:
>     dump_stack+0x19/0x1b
>     __setup_irq+0x54a/0x570
>     request_threaded_irq+0xcc/0x170
>     i801_probe+0x32f/0x508 [i2c_i801]
>     local_pci_probe+0x45/0xa0
>   i801_smbus 0000:00:1f.3: Failed to allocate irq 255: -16
>   i801_smbus: probe of 0000:00:1f.3 failed with error -16
> 
> After aeb8a3d16ae0 ("i2c: i801: Check if interrupts are disabled"),
> i801_probe() will fall back to polling if request_irq() fails.  But we
> still need this patch because request_irq() may succeed or fail depending
> on other devices in the system.  If request_irq() fails, i801_smbus will
> work by falling back to polling, but if it succeeds, i801_smbus won't work
> because it expects interrupts that it may not receive.
> 
> Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
> Acked-by: Thomas Gleixner <tglx@linutronix.de>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>

Hi Chen,

You already have my ack, but I'm just curious if you can tell whether
i801_smbus works if IRQ 255 isn't in use, e.g., if you can remove the
megasa driver or tell it not to use MSI?

Bjorn

      reply	other threads:[~2016-01-29 22:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-29  3:40 [RESEND PATCH v4] x86/PCI: Recognize that Interrupt Line 255 means "not connected" Chen Fan
2016-01-29  3:40 ` Chen Fan
2016-01-29 22:08 ` Bjorn Helgaas [this message]

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=20160129220812.GF12965@localhost \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=caoj.fnst@cn.fujitsu.com \
    --cc=chen.fan.fnst@cn.fujitsu.com \
    --cc=ddaney.cavm@gmail.com \
    --cc=izumi.taku@jp.fujitsu.com \
    --cc=jiang.liu@linux.intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=okaya@codeaurora.org \
    --cc=rjw@rjwysocki.net \
    --cc=tglx@linutronix.de \
    --cc=wency@cn.fujitsu.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.