"Oliver O'Halloran" <ooh...@gmail.com> writes: > On Thu, May 19, 2022 at 10:38 PM Michael Ellerman <m...@ellerman.id.au> wrote: >> Christophe Leroy <christophe.le...@csgroup.eu> writes: >> > Le 02/09/2020 à 05:51, Oliver O'Halloran a écrit : >> >> The MPS field in the VF config space is marked as reserved in current >> >> versions of the SR-IOV spec. In other words, this fixup doesn't do >> >> anything. >> >> >> >> Signed-off-by: Oliver O'Halloran <ooh...@gmail.com> >> > >> > A lot of cleanup patches from Oliver were merged in Septembre 2020 but >> > not this one. >> > >> > Any reason ? >> >> It wasn't clear to me that it's safe to remove. The commit that added it >> seemed to think it was important. >> >> The fact that it's out-of-spec doesn't mean we don't have some hardware >> somewhere that relies on that. > > There is no hardware that depends on it. It was added in response to a > bug report on the IBM internal bugzilla about virtual functions not > reporting the same MPS as the physical function in the output of > lspci. This is by design since MPS is a property that is only relevant > to the PF. There was a corresponding patch to skiboot to intercept > writes to the MPS field of VFs which was used to fake a writable MPS > field in firmware. I removed that hack in 2019 > (https://github.com/open-power/skiboot/commit/22057f868f3b2b1fd02647a738f6da0858b5eb6c) > since it was pointless and was causing other problems. There's no real > reason to keep this code around IMO.
Thanks for the extra detail, I am persuaded :) cheers
