> From: Jason Gunthorpe <jgg@xxxxxxxx>
> Sent: Tuesday, November 28, 2023 8:46 AM
>
> On Fri, Nov 24, 2023 at 08:46:58AM +0000, Shameerali Kolothum Thodi wrote:
> > > diff --git a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
> > > b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
> > > index b2f9778c8366..2c049b8de4b4 100644
> > > --- a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
> > > +++ b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
> > > @@ -638,17 +638,17 @@ static void
> > > hisi_acc_vf_state_mutex_unlock(struct hisi_acc_vf_core_device
> > > *hisi_acc_vdev)
> > > {
> > > again:
> > > - spin_lock(&hisi_acc_vdev->reset_lock);
> > > + mutex_lock(&hisi_acc_vdev->reset_mutex);
> > > if (hisi_acc_vdev->deferred_reset) {
> > > hisi_acc_vdev->deferred_reset = false;
> > > - spin_unlock(&hisi_acc_vdev->reset_lock);
> > > + mutex_unlock(&hisi_acc_vdev->reset_mutex);
> >
> > Don't think we have that sleeping while atomic case for this here.
> > Same for mlx5 as well. But if the idea is to have a common locking
> > across vendor drivers, it is fine.
>
> Yeah, I'm not sure about changing spinlocks to mutex's for no reason..
> If we don't sleep and don't hold it for very long then the spinlock is
> appropriate
>
It's me suggesting Brett to fix other two drivers, expecting a common
locking pattern would cause less confusion to future new variant drivers.
If both of you don't think it necessary then let's drop it. 😊
