On Thu, 2017-09-07 at 08:59 +0000, Joakim Tjernlund wrote: > > > Hrm it's tricky, you shouldn't just turn that ifdef back on without > > also changing pci_resource_to_user(). > > There are two ifdef to change: > __pci_mmap_make_offset(): > #if 0 /* See comment in pci_resource_to_user() for why this is disabled */ > *offset += hose->pci_mem_offset; > #endif > > and > > pci_resource_to_user() > /* We pass a fully fixed up address to userland for MMIO instead of > * a BAR value because X is lame and expects to be able to use that > * to pass to /dev/mem ! > * > * That means that we'll have potentially 64 bits values where some > * userland apps only expect 32 (like X itself since it thinks only > * Sparc has 64 bits MMIO) but if we don't do that, we break it on > * 32 bits CHRPs :-( > * > * Hopefully, the sysfs insterface is immune to that gunk. Once X > * has been fixed (and the fix spread enough), we can re-enable the > * 2 lines below and pass down a BAR value to userland. In that case > * we'll also have to re-enable the matching code in > * __pci_mmap_make_offset(). > * > * BenH. > */ > #if 0 > else if (rsrc->flags & IORESOURCE_MEM) > offset = hose->pci_mem_offset; > #endif > > Problem is that pci_mem_offset is gone, the closed I can find is mem_offset > but that is an array,maybe just mem_offset[0] ?
No, you'd have to scan the array of resources to find which offset applies. > > I'm not sure exactly what's going > > on in your case, if you have a problem can you add printk to instrument > > ? > > Seems to be something else going on in out board. Anyhow, the mem_offset > should > be fixed to compile, nice to have it behind a CONFIG option. Then > one can start the process to remove the special casing easier. Again, why do you need to remove it ? Can you find anything with the existing code (with its #if'0) that is broken ? Cheers, Ben.
