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

Reply via email to