On Wed, 2012-06-13 at 15:18 +1000, Michael Ellerman wrote: > 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.
How so ? I tend to disagree here.. . > > 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. The firmware interface is busted anyway. We want to be able to enable/allocate individual MSI-X at runtime, we need to get a new interface sorted. Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
