On Tue, 2012-06-05 at 12:47 +1000, Anton Blanchard wrote: > Hi, > > > On Mon, 2012-06-04 at 16:43 +1000, Michael Ellerman wrote: > > > There is some chance this will result in breakage because the driver > > > asks for N - and assumes that is what was allocated - and the > > > device is configured for > N. > > > > We can fix that. We can whack the configuration back with N, just know > > that we have "allocated" > N.
I think whacking config space is more likely to break something than just configuring more than the driver asked for. > I agree we don't want to be giving back a larger value than requested. > There's only one place that can happen in theory and since firmware only > returns power of two values I dont think it will happen in practise. Don't follow you here. > Even so do we want to do something like this (as yet untested)? If the > rounded up request fails we retry with the original request. Yes we do. Had a chance to test it? > The pseries msi free code just sets our vectors to 0 so it doesn't need > to know how many were originally allocated. Yep, looks like it will cope. We only create virqs for what's in pdev->msi_list, which will be what the driver originally asked for, and we free all those by walking the list again. So the fact that firmware allocated a few extra for us is OK, we have nothing extra to cleanup. cheers _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
