On Thu, Nov 21, 2019 at 2:38 PM Alexey Kardashevskiy <a...@ozlabs.ru> wrote:
>
>
>
> On 20/11/2019 12:28, Oliver O'Halloran wrote:
> > After resetting a VF we call eeh_restore_vf_config() to restore several
> > registers in the VFs config space. For physical functions this is normally
> > handled by the pci_reinit_device() OPAL call which requests firmware to
> > re-program the device with whatever defaults were set at boot time. We
> > can't use that for VFs since OPAL (being firmware) doesn't know (or care)
> > about VFs.
> >
> > However, the fields that are restored here are all marked as reserved for
> > VFs in the SR-IOV spec. In other words, eeh_restore_vf_config() doesn't
> > actually do anything.
> >
> > There is an argument to be made that we should be saving and restoring
> > some of these fields since they are marked as "Reserved, but Preserve"
> > (ResvP) to allow these fields to be used in new versions of the SR-IOV.
> > However, the current code doesn't even do that properly since it assumes
> > they can be set to whatever the EEH core has assumed to be correct. If
> > the fields *are* used in future versions of the SR-IOV spec this code
> > is still broken since it doesn't take into account any changes made
> > by the driver, or the Linux IOV core.
> > Given the above, just delete the code. It's broken, it's mis-leading,
> > and it's getting in the way of doing useful cleanups.
>
>
> There is still a prototype for this in arch/powerpc/include/asm/eeh.h,
> and pci_dn::mps as well.
>
>
> With the history of this explained offline,
>
> Reviewed-by: Alexey Kardashevskiy <a...@ozlabs.ru>


The commit message used to have some of the background, but I thought
it was too long already and took it out. I'll add it back in I guess.

Reply via email to