On 21/03/18 10:59, Luke Ross wrote: > On Wed, 2018-03-21 at 09:58 +0200, Adrian Hunter wrote: >> On 20/03/18 21:40, Luke Ross wrote: >>> >>> Please excuse the direct email - I'm writing to you as you were >>> connected (author/reviewer) with Linux kernel commit >>> 1b7ba57ecc864173ef42fff7f8c2e9a880b42bd2 - "mmc: sdhci-acpi: Handle >>> return value of platform_get_irq". >>> >>> Unfortunately this commit has caused a regression on hardware I >>> use, >>> and I'm looking for guidance on how best to fix this. I've raised a >>> ticket at bugzilla.kernel.org, outlining the issue: >>> >>> https://bugzilla.kernel.org/show_bug.cgi?id=199105 >>> >>> ...and I've also posted on the linux-mmc list: >>> >>> https://www.spinics.net/lists/linux-mmc/msg48411.html >>> >>> Unfortunately nobody else has, so far, been able to assist via >>> either >>> of these. >>> >>> Would it be possible for you to have a look at this? If you can >>> suggest >>> the best way to resolve this I'd be happy to try and construct a >>> suitable patch and submit it. I'd be very happy to discuss this on >>> the >>> linux-mmc list if you would prefer. >> >> On the system where you have eMMC working, please show the results >> of: >> >> cat /proc/interrupts >> >> And: >> >> grep -H . /sys/kernel/irq/0/* > > Thanks for your reply. > > /proc/interrupts: > > CPU0 CPU1 CPU2 CPU3 > 0: 13219 23168 0 0 IO-APIC 45- > fasteoi mmc0 > 1: 0 0 0 0 IO-APIC 47- > fasteoi mmc1 > 6: 0 0 0 0 IO-APIC 41- > fasteoi 8086228E:00 > 7: 0 0 0 0 IO-APIC 89- > fasteoi 8086228E:01 > 8: 0 0 0 0 IO-APIC 90- > fasteoi 8086228E:02 > 9: 0 0 0 0 IO-APIC 32- > fasteoi 808622C1:00 > 10: 274 233 0 0 IO-APIC 33- > fasteoi 808622C1:01 > 11: 5 2352 0 0 IO-APIC 34- > fasteoi 808622C1:02 > 12: 0 0 0 0 IO-APIC 35- > fasteoi 808622C1:03 > 13: 0 0 0 0 IO-APIC 36- > fasteoi 808622C1:04 > 14: 253 1323 0 0 IO-APIC 37- > fasteoi 808622C1:05 > 15: 729 435 0 0 IO-APIC 38- > fasteoi 808622C1:06 > 21: 59 101 0 0 IO-APIC 29- > fasteoi intel_sst_driver > 67: 1 0 0 0 chv- > gpio 43 volume_up > 69: 1 0 0 0 chv- > gpio 45 volume_down > 84: 0 0 0 0 chv- > gpio 3 INT3496:00 > 89: 0 0 0 0 chv-gpio 8 home > 90: 0 0 0 0 chv- > gpio 9 axp288_irq_chip > 94: 143 0 0 0 chv- > gpio 13 GDIX1001:00 > 116: 0 0 0 0 IO-APIC 9- > fasteoi INT0002 > 138: 0 0 0 0 chv-gpio 8 power > 205: 0 0 0 0 chv- > gpio 50 80860F14:01 cd > 213: 0 0 0 0 PCI-MSI 458752- > edge PCIe PME > 215: 548 9 0 0 PCI-MSI 327680- > edge xhci_hcd > 217: 1024 0 0 1733 PCI-MSI 32768- > edge i915 > 219: 0 0 0 0 INT0002 Virtual > GPIO 2 ACPI:Event > 222: 0 0 0 0 axp288_irq_chip 2 > axp288_extcon > 223: 0 0 0 0 axp288_irq_chip 3 > axp288_extcon > 224: 0 0 0 0 axp288_irq_chip 4 > axp288_charger > 230: 0 0 0 0 axp288_irq_chip 10 > axp288_charger > 231: 0 0 0 0 axp288_irq_chip 11 > axp288_charger > 232: 0 0 0 0 axp288_irq_chip 12 > axp288_charger > 233: 0 0 0 0 axp288_irq_chip 13 > axp288_charger > 236: 0 0 0 0 axp288_irq_chip 16 > axp288_fuel_gauge > 237: 0 0 0 0 axp288_irq_chip 17 > axp288_fuel_gauge > 238: 0 0 0 0 axp288_irq_chip 18 > axp288_fuel_gauge > 239: 0 0 0 0 axp288_irq_chip 19 > axp288_fuel_gauge > 240: 0 0 0 0 axp288_irq_chip 20 > axp288_charger > 241: 0 0 0 0 axp288_irq_chip 21 > axp288_charger > 242: 0 0 0 0 axp288_irq_chip 22 > axp288_charger > 243: 0 0 0 0 axp288_irq_chip 23 > axp288_charger > 244: 0 0 0 0 axp288_irq_chip 24 > axp288_fuel_gauge > 245: 0 0 0 0 axp288_irq_chip 25 > axp288_fuel_gauge > 260: 0 0 0 0 axp288_irq_chip 40 > axp288_extcon > 261: 0 0 0 0 axp288_irq_chip 41 > axp288_extcon > 263: 0 0 0 0 PCI-MSI 180224- > edge proc_thermal > 264: 21 0 0 0 PCI-MSI 425984- > edge mei_txe > 265: 280 2823 0 0 PCI-MSI 524288- > edge iwlwifi > NMI: 6 3 5 4 Non-maskable > interrupts > LOC: 19814 19515 17574 15631 Local timer > interrupts > SPU: 0 0 0 0 Spurious interrupts > PMI: 6 3 5 4 Performance > monitoring interrupts > IWI: 0 0 0 0 IRQ work interrupts > RTR: 0 0 0 0 APIC ICR read > retries > RES: 4969 3833 5244 4811 Rescheduling > interrupts > CAL: 2975 2371 2514 2386 Function call > interrupts > TLB: 694 558 311 146 TLB shootdowns > TRM: 0 0 0 0 Thermal event > interrupts > THR: 0 0 0 0 Threshold APIC > interrupts > DFR: 0 0 0 0 Deferred Error APIC > interrupts > MCE: 0 0 0 0 Machine check > exceptions > MCP: 1 1 1 1 Machine check polls > ERR: 0 > MIS: 0 > PIN: 0 0 0 0 Posted-interrupt > notification event > NPI: 0 0 0 0 Nested posted- > interrupt event > PIW: 0 0 0 0 Posted-interrupt > wakeup event > > grep -H . /sys/kernel/irq/0/* > > /sys/kernel/irq/0/actions:mmc0 > /sys/kernel/irq/0/chip_name:IO-APIC > /sys/kernel/irq/0/hwirq:45 > /sys/kernel/irq/0/name:fasteoi > /sys/kernel/irq/0/per_cpu_count:13219,19524,0,0 > /sys/kernel/irq/0/type:level > > I've also attached a dmesg to the bugzilla.kernel.org ticket. These > were all taken with a 4.13 kernel. > > I'm guessing that the above means the eMMC does have an interrupt, > IRQ0? Yes. Ulf, here is the fix: From: Adrian Hunter <adrian.hunter@xxxxxxxxx> Date: Wed, 21 Mar 2018 11:34:44 +0200 Subject: [PATCH] mmc: sdhci-acpi: Fix IRQ 0 Zero is a valid IRQ number and is being used on some CHT tablets. Stop treating it as an error. Reported-by: Luke Ross <luke@xxxxxxxxxxxxx> Fixes: 1b7ba57ecc86 ("mmc: sdhci-acpi: Handle return value of platform_get_irq") Cc: Arvind Yadav <arvind.yadav.cs@xxxxxxxxx> Signed-off-by: Adrian Hunter <adrian.hunter@xxxxxxxxx> Cc: stable@xxxxxxxxxxxxxxx --- drivers/mmc/host/sdhci-acpi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c index 4065da58789d..32321bd596d8 100644 --- a/drivers/mmc/host/sdhci-acpi.c +++ b/drivers/mmc/host/sdhci-acpi.c @@ -680,7 +680,7 @@ static int sdhci_acpi_probe(struct platform_device *pdev) host->hw_name = "ACPI"; host->ops = &sdhci_acpi_ops_dflt; host->irq = platform_get_irq(pdev, 0); - if (host->irq <= 0) { + if (host->irq < 0) { err = -EINVAL; goto err_free; } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
