On Wed, 2015-12-09 at 12:00 +1100, Michael Neuling wrote: > On Tue, 2015-12-08 at 17:30 +1100, Andrew Donnellan wrote: > > Finally looking at this patch again for the first time in a couple of > > months... > > > > On 04/11/15 17:17, Andrew Donnellan wrote: > > > On 03/11/15 20:09, Michael Ellerman wrote: > > > > Part of your problem is you're storing afu->crs_len which is not > > > > __iomem in > > > > cfg_data which is, and so that's leading to some of your casts. > > > > > > > > I don't really see why you're using cfg_data like that, you have the > > > > afu in phb->private_data. But maybe cfg_data needs to hold that value > > > > for some other code I'm not seeing. > > > > > > I can't see any obvious reason why we need to use cfg_data either. > > > > Ian/Mikey - do you happen to know why we're using cfg_data? I've > > taken another look and I can't see anything obvious. > > IIRC, when I coded this up, benh just said these (cfg_addr/data) are > just private data and we can stick whatever we like in there. > > We could store it in the AFU struct but it's (was just) convenient to > just store it here.
You're storing afu->crs_len in there, so it is in the AFU struct. Unless there's a different "AFU struct", in which case meh. Please send me a patch to clean it up Andrew. cheers _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev