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