On 3 March 2015 at 14:06, Sergey Ryazanov <ryazanov.s.a@xxxxxxxxx> wrote: > 2015-02-16 10:35 GMT+03:00 Rafał Miłecki <zajec5@xxxxxxxxx>: >> Once I've hit >> BUG_ON(in_interrupt()); >> when hacking PCI drivers locally on MIPS board. I see the problem but >> don't know the solution. >> >> 1) I think "read" and "write" of struct pci_ops should be safe to call >> in IRQ handler >> 2) In drivers/bcma/driver_pci_host.c we use ioremap_nocache >> >> This causes a problem for boards with 2 PCI(e) cards. The base address >> for the 2nd card is >> #define BCMA_SOC_PCI1_CFG 0x44000000U >> which doesn't allow MIPS to use KSEG1. >> >> As the result forwardtrace looks like this: >> 1) ioremap_nocache >> 2) __ioremap_mode >> 3) __ioremap >> 4) get_vm_area >> 5) __get_vm_area_node >> And then we can hit BUG_ON(in_interrupt()); >> >> Can you see any solution for this? Currently there isn't any mainline >> code triggering this problem, but it would be nice to have everything >> working anyway. >> > Why do you need to read the PCI configuration space in the interrupt > handler? As you wrote, it uncommon that driver tries to do that. > Usually the PCI configuration read/updated during device > initialization stage (by the PCI core and by a device driver) and then > you interact with the I/O memory and not with the configuration space. This is what brcmsmac does. I copied this behavior locally to b43 when debugging some DMA controller problem. They do: request_irq(pdev->irq, brcms_isr, IRQF_SHARED, KBUILD_MODNAME, wl) And then the forwardtrace looks like this: brcms_isr brcms_c_isr wlc_intstatus brcms_deviceremoved ai_deviceremoved pci_read_config_dword(sii->pcibus, PCI_VENDOR_ID, &w); -- Rafał
