On Thu, Aug 08, 2019 at 07:57:53AM +0300, Denis Efremov wrote: > octeon_mbox_process_cmd() directly writes the PCI_EXP_DEVCTL_BCR_FLR > bit, which bypasses timing requirements imposed by the PCIe spec. > This patch fixes the function to use the pcie_flr() interface instead. > > Signed-off-by: Denis Efremov <efre...@linux.com> > --- > drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c > b/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c > index 021d99cd1665..614d07be7181 100644 > --- a/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c > +++ b/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c > @@ -260,9 +260,7 @@ static int octeon_mbox_process_cmd(struct octeon_mbox > *mbox, > dev_info(&oct->pci_dev->dev, > "got a request for FLR from VF that owns DPI ring > %u\n", > mbox->q_no); > - pcie_capability_set_word( > - oct->sriov_info.dpiring_to_vfpcidev_lut[mbox->q_no], > - PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_BCR_FLR); > + pcie_flr(oct->sriov_info.dpiring_to_vfpcidev_lut[mbox->q_no]); > break;
It's possible for pcie_flr to fail if the device doesn't become ready soon enough after reset in which case it returns ENOTTY. I think it's OK not to test the return value here though, as pci_dev_wait will print a warning anyway, and I'm not sure what you'd do with it anyway. Reviewed-by: Andrew Murray <andrew.mur...@arm.com> > > case OCTEON_PF_CHANGED_VF_MACADDR: > -- > 2.21.0 >
