Second try after webmail messed up my first message. > On Thu, Dec 17, 2015 at 11:29:52PM +0200, Matti Laakso wrote: > > Hello all, > > > > I have some oldish MIPS-based (Lantiq Danube) routers that have a PCI > > bus and a VIA 6212 USB-controller connected to it. The USB controller > > requires I/O resources in addition to memory. It seems that with > > kernel > > 3.18 and newer PCI I/O resources can no longer be allocated on this > > platform. I tracked the problem down to a patch set from Liviu Dudau > > (Support for creating generic PCI host bridges from DT). After this > > patch the function pci_address_to_pio in drivers/of/address.c hits the > > check > > > > address > IO_SPACE_LIMIT > > > > since address on this SoC is 0x1AE00000 and IO_SPACE_LIMIT is 0xFFFF > > on MIPS (PCI_IOBASE is not defined). Changing IO_SPACE_LIMIT to > > 0xFFFFFFFF I can work around the problem, but I think that is not the proper solution. > > if PCI_IOBASE is not defined then you should not hit the code I have added with commit 41f8bba7f5552d0 but the old code path, in which case I would guess the code was broken before my change? > Well, before your change of_pci_range_to_resource() simply filled the resource struct without any checks. Now it fills it with OF_BAD_ADDR. Maybe it was broken, but at least it worked in this case. > > > > Any ideas on how to fix this? > > > > There is a distinction between IO range being visible from the CPU @ 0x1AE00000 and the IO address being used by the PCI subsystem. The IO address is a bus address and it should be between 0 - IO_SPACE_LIMIT. > >From reading the code in of_pci_range_to_resource() I'd expect pci_address_to_pio(range->cpu_addr) to get the CPU address as its argument. Why is it checked against IO_SPACE_LIMIT? Or is the IO address yet different from PCI address (meaning, range->pci_addr)? > I would look into the actual user of pci_address_to_pio(), and maybe define PCI_IOBASE for your platform to tell it where the IO space starts from CPU point of view. > Best regards, Matti Laakso
