All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Li, Aubrey" <aubrey.li@linux.intel.com>
To: Huang Ying <ying.huang@intel.com>
Cc: Ingo Molnar <mingo@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>, LKP ML <lkp@01.org>
Subject: Re: [LKP] [x86/platform, acpi] 7486341a98f: genirq: Flags mismatch irq 8. 00000080 (mmc0) vs. 00000000 (rtc0)
Date: Thu, 26 Mar 2015 20:13:59 +0800	[thread overview]
Message-ID: <5513F807.7070304@linux.intel.com> (raw)
In-Reply-To: <1427268154.17170.40.camel@intel.com>

On 2015/3/25 15:22, Huang Ying wrote:
> [   28.745155] genirq: Flags mismatch irq 8. 00000080 (mmc0) vs. 00000000 (rtc0)

okay, I replicated this on my side now.

Firstly, I don't think the patch did anything wrong. However, the patch
exposes a few issues FWICT currently:

- Should we enable RTC Alarm the kind of Fixed hardware event in
hardware-reduced ACPI mode? I found RTC required registers in ACPI PM
block are not valid(register address = 0)

- I checked RTC device in ACPI table, there is no interrupt resource
under RTC(firmware bug?), So irq 8 should be a hardcoded number. The
question is, shouldn't we update bitmap of allocated_irqs here? Or we
assume irq0~15 is reserved? If we assume IRQ0~15 is reserved, then
requesting IRQ8 without updating bitmap of allocated_irqs is fine.

- Because we don't update bitmap of allocated_irqs when RTC request
IRQ8, so when MMC driver allocate irq resource, it's possible it gets
irq8, so we saw "genirq: Flags mismatch irq 8. 00000080 (mmc0) vs.
00000000 (rtc0)". So here is another question, when we dynamically
allocate irq from irq domain, shouldn't we start from IRQ16? Yes, if
allocated_irqs bitmap is updated, then it should be fine if we start
from IRQ1.

What the patch does is, it changes the behavior of how we allocate irq
from irq domain. Previously we have legacy IRQs so we statically assign
IRQ numbers for IOAPICs to host legacy IRQs, and now we allocate every
IRQ dynamically.

For me I think I can deliver a patch against RTC driver to update
allocated_irqs bitmap, also, we should free irq when we found RTC ACPI
registers are not valid.

Certainly I'm open to any suggestions.

Thanks,
-Aubrey

WARNING: multiple messages have this Message-ID (diff)
From: Li, Aubrey <aubrey.li@linux.intel.com>
To: lkp@lists.01.org
Subject: Re: [x86/platform, acpi] 7486341a98f: genirq: Flags mismatch irq 8. 00000080 (mmc0) vs. 00000000 (rtc0)
Date: Thu, 26 Mar 2015 20:13:59 +0800	[thread overview]
Message-ID: <5513F807.7070304@linux.intel.com> (raw)
In-Reply-To: <1427268154.17170.40.camel@intel.com>

[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]

On 2015/3/25 15:22, Huang Ying wrote:
> [   28.745155] genirq: Flags mismatch irq 8. 00000080 (mmc0) vs. 00000000 (rtc0)

okay, I replicated this on my side now.

Firstly, I don't think the patch did anything wrong. However, the patch
exposes a few issues FWICT currently:

- Should we enable RTC Alarm the kind of Fixed hardware event in
hardware-reduced ACPI mode? I found RTC required registers in ACPI PM
block are not valid(register address = 0)

- I checked RTC device in ACPI table, there is no interrupt resource
under RTC(firmware bug?), So irq 8 should be a hardcoded number. The
question is, shouldn't we update bitmap of allocated_irqs here? Or we
assume irq0~15 is reserved? If we assume IRQ0~15 is reserved, then
requesting IRQ8 without updating bitmap of allocated_irqs is fine.

- Because we don't update bitmap of allocated_irqs when RTC request
IRQ8, so when MMC driver allocate irq resource, it's possible it gets
irq8, so we saw "genirq: Flags mismatch irq 8. 00000080 (mmc0) vs.
00000000 (rtc0)". So here is another question, when we dynamically
allocate irq from irq domain, shouldn't we start from IRQ16? Yes, if
allocated_irqs bitmap is updated, then it should be fine if we start
from IRQ1.

What the patch does is, it changes the behavior of how we allocate irq
from irq domain. Previously we have legacy IRQs so we statically assign
IRQ numbers for IOAPICs to host legacy IRQs, and now we allocate every
IRQ dynamically.

For me I think I can deliver a patch against RTC driver to update
allocated_irqs bitmap, also, we should free irq when we found RTC ACPI
registers are not valid.

Certainly I'm open to any suggestions.

Thanks,
-Aubrey

  reply	other threads:[~2015-03-26 12:14 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-20  8:38 [LKP] [x86/platform, acpi] 7486341a98f: genirq: Flags mismatch irq 8. 00000080 (mmc0) vs. 00000000 (rtc0) Huang Ying
2015-03-20  8:38 ` Huang Ying
2015-03-23  6:18 ` [LKP] " Li, Aubrey
2015-03-23  6:18   ` Li, Aubrey
2015-03-24  0:53   ` [LKP] " Huang Ying
2015-03-24  0:53     ` Huang Ying
2015-03-24  2:16     ` [LKP] " Li, Aubrey
2015-03-24  2:16       ` Li, Aubrey
2015-03-24  5:34     ` [LKP] " Li, Aubrey
2015-03-24  5:34       ` Li, Aubrey
2015-03-25  7:22       ` [LKP] " Huang Ying
2015-03-25  7:22         ` Huang Ying
2015-03-26 12:13         ` Li, Aubrey [this message]
2015-03-26 12:13           ` Li, Aubrey
2015-03-30  8:28           ` [LKP] " Li, Aubrey
2015-03-30  8:28             ` Li, Aubrey
2015-03-30  8:37             ` [LKP] " Jiang Liu
2015-03-30  8:37               ` Jiang Liu
2015-03-30 12:19               ` [LKP] " Li, Aubrey
2015-03-30 12:19                 ` Li, Aubrey

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=5513F807.7070304@linux.intel.com \
    --to=aubrey.li@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@01.org \
    --cc=mingo@kernel.org \
    --cc=ying.huang@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.