Hello Rafał, 2015-02-16 10:35 GMT+03:00 Rafał Miłecki <zajec5@xxxxxxxxx>: > Hi, > > 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. > > As one of workarounds I was thinking about mapping whole space early. > Unfortunately there are many possible registers (0xffff), few PCI > functions (0x30000), many possible PCI devices (0xf80000). It's way to > big space I guess to keep it mapped all the time. > Actual number of slots is much less than 0xf80000, so if you know it (e.g. from DT) then you could do remapping earlier during the PCI controller initialization. -- Sergey
