Olof, Olof Johansson wrote: > Move away from using the pci config access functions for simple register > access. Our device has all of the registers in the config space (hey, > from the hardware point of view it looks reasonable :-), so we need to > somehow get to it. Newer firmwares have it in the device tree such that > we can just get it and ioremap it there (in case it ever moves in future > products). For now, provide a hardcoded fallback for older firmwares.
I have recently tried to apply a group of your MAC patches that includes the one from this email. Strangely, I got a pretty random kernel panics (or kernel freezes) when this patch is included. Panics happen in a random, places and have random causes. What I observed is that replacing newly introduced mac->iob_regs with the corresponding offset from (already ioremapped) hose->cfg_data removed the problem. So, it seems that dereferencing pointers based on a second ioremap on a subset of 0xe000_0000 addresses is problematic. Here are the questions that come to my mind: - I am testing on a A2 hw, what what your testing setup, anything newer than this (something closer B0 maybe), did you have a chance to try that on a A2 board? - Is there any particular patch or set of patches/updates that this patch may depend on? Switching from pci accessors to direct in_* out_* calls drops the guard pci spinlock. Initially, I thought that this may be the reason, but it's not, adding the spinlock is not solving the problem. But anyway, shouldn't we be using it to coordinate access? Thanks, Marian _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev