Re: pcmcia: ti: regression cannot get IRQ

[Arnd Bergmann]

On Sun, Jan 1, 2023, at 19:10, Corentin Labbe wrote:
> Hello
>
> I was trying to boot again my old compaq armada 7400 laptop and the 
> network card is unusable.
>
> Last known working kernel is 4.16.18.
> First known bad kernel is 4.17.19
>
> The interesting log is:
> [    3.503348] yenta_cardbus 0000:00:0c.0: ISA IRQ mask 0x0698, PCI irq 
> 0
> [    3.503442] yenta_cardbus 0000:00:0c.0: Socket status: 30000006
> [    3.505250] yenta_cardbus 0000:00:0c.1: CardBus bridge found 
> [0e11:b048]
> [    3.505370] yenta_cardbus 0000:00:0c.1: adjusting diagnostic: 60 -> 
> 00
> [    3.505457] yenta_cardbus 0000:00:0c.1: Using INTVAL to route CSC 
> interrupts to PCI
> [    3.505554] yenta_cardbus 0000:00:0c.1: Routing CardBus interrupts 
> to ISA
> [    3.505556] yenta_cardbus 0000:00:0c.1: TI: mfunc 0x00000000, devctl 
> 0x64
> [    3.505556] yenta_cardbus 0000:00:0c.1: TI: no PCI interrupts. Fish. 
> Please report.
> [    3.505556] yenta_cardbus 0000:00:0c.1: no PCI IRQ, CardBus support 
> disabled for this socket.
> [    3.505556] yenta_cardbus 0000:00:0c.1: check your BIOS CardBus, 
> BIOS IRQ or ACPI settings.
> [    3.632323] yenta_cardbus 0000:00:0c.1: ISA IRQ mask 0x0698, PCI irq 
> 0
> [    3.632416] yenta_cardbus 0000:00:0c.1: Socket status: 30000020
>
> Full 4.16.18 log is availlable at: 
> http://kernel.montjoie.ovh/zoo/armada/dmesg-4.16.18.txt
> Since 4.17 (and 4.18) is stuck sarting init, I have log for 5.0.29
> Full 5.0.29 log is availlable at: 
> http://kernel.montjoie.ovh/zoo/armada/dmesg-5.0.21.txt

I see you hit this code path:

        if (!socket->cb_irq || request_irq(socket->cb_irq, yenta_interrupt, IRQF_SHARED, "yenta", socket)) {
                /* No IRQ or request_irq failed. Poll */
                socket->cb_irq = 0; /* But zero is a valid IRQ number. */
                timer_setup(&socket->poll_timer, yenta_interrupt_wrapper, 0);
                mod_timer(&socket->poll_timer, jiffies + HZ);
                dev_info(&dev->dev,
                         "no PCI IRQ, CardBus support disabled for this socket.\n");
                dev_info(&dev->dev,
                         "check your BIOS CardBus, BIOS IRQ or ACPI settings.\n");
        } else {


The "socket->cb_irq" is just the device IRQ, which is originally
set to "11", and this one appears to be shared with all the other
PCI devices:

[    2.402035] ACPI: PCI Interrupt Link [C168] (IRQs *11)
[    2.403507] ACPI: PCI Interrupt Link [C16C] (IRQs *11)
[    2.405461] ACPI: Blank _CRS EXT IRQ resource
[    2.405546] ACPI: PCI Interrupt Link [C16D] (IRQs 11) *0, disabled.
[    2.407578] ACPI: Blank _CRS EXT IRQ resource
[    2.407663] ACPI: PCI Interrupt Link [C16E] (IRQs 11) *0, disabled.
[    2.409610] ACPI: Blank _CRS EXT IRQ resource
[    2.409695] ACPI: PCI Interrupt Link [C16F] (IRQs 11) *0, disabled.
[    2.411647] ACPI: Blank _CRS EXT IRQ resource
[    2.411733] ACPI: PCI Interrupt Link [C170] (IRQs 11) *0, disabled.
[    2.413690] ACPI: Blank _CRS EXT IRQ resource
[    2.413775] ACPI: PCI Interrupt Link [C171] (IRQs 11) *0, disabled.
[    2.416055] ACPI: Blank _CRS EXT IRQ resource
[    2.416140] ACPI: PCI Interrupt Link [C172] (IRQs 11) *0, disabled.

If any of them try to get the IRQ as non-shared, then the cardbus
one would fail. Do you see anything suspicious in /proc/interrupts?

     Arnd