On Wed, Jan 27, 2021 at 12:41:41AM +0000, Saleem, Shiraz wrote:

quoted

Subject: Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver and
implement private channel OPs

On Tue, Jan 26, 2021 at 12:42:16AM +0000, Saleem, Shiraz wrote:

quoted

I think this essentially means doing away with .open/.close piece.

Yes, that too, and probably the FSM as well.

quoted

Or are you saying that is ok?  Yes we had a discussion in the past and
I thought we concluded. But maybe I misunderstood.

https://lore.kernel.org/linux-rdma/9DD61F30A802C4429A01CA4200E302A7DCD
4FD03@fmsmsx124.amr.corp.intel.com/

Well, having now seen how aux bus ended up and the way it effected the
mlx5 driver, I am more firmly of the opinion this needs to be fixed. It is extremly
hard to get everything right with two different registration schemes running around.

You never answered my question:

Sorry I missed it.

quoted

quoted

Still, you need to be able to cope with the user unbinding your
drivers in any order via sysfs. What happens to the VFs when the PF is
unbound and releases whatever resources? This is where the broadcom
driver ran into troubles..

?

echo -n "ice.intel_rdma.0" > /sys/bus/auxiliary/drivers/irdma/unbind  ???

That I believe will trigger a drv.remove() on the rdma PF side which require
the rdma VFs to go down.

How? They could be in VMs

Jason