On Wed, Jan 27, 2021 at 12:41:41AM +0000, Saleem, Shiraz wrote: > > 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: > > > > > I think this essentially means doing away with .open/.close piece. > > > > Yes, that too, and probably the FSM as well. > > > > > 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@xxxxxxxxxxxxxxxxxxxxxxxxxxxx/ > > > > 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. > > > > > 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
