Re: [PATCH 1/3] IB/vmw_pvrdma: Defer activating device until vmxnet3 link is up

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jan 19, 2017 at 01:45:17AM -0500, Doug Ledford wrote:
> On Wed, 2017-01-18 at 16:31 -0800, Adit Ranadive wrote:
> > On Wed, Jan 18, 2017 at 10:50:54PM +0000, Parav Pandit wrote:
> > > 
> > > Hi Adit,
> > > 
> > > > 
> > > > -----Original Message-----
> > > > From: Adit Ranadive [mailto:aditr@xxxxxxxxxx]
> > > > Sent: Wednesday, January 18, 2017 2:53 PM
> > > > To: Jason Gunthorpe <jgunthorpe@xxxxxxxxxxxxxxxxxxxx>
> > > > Cc: Parav Pandit <parav@xxxxxxxxxxxx>; Leon Romanovsky
> > > > <leon@xxxxxxxxxx>; dledford@xxxxxxxxxx; linux-rdma@xxxxxxxxxxxxxx
> > > > g; pv-
> > > > drivers@xxxxxxxxxx; Aditya Sarwade <asarwade@xxxxxxxxxx>
> > > > Subject: Re: [PATCH 1/3] IB/vmw_pvrdma: Defer activating device
> > > > until
> > > > vmxnet3 link is up
> > > > 
> > > > On Wed, Jan 18, 2017 at 1:41:30PM -0700, Jason Gunthorpe wrote:
> > > > > 
> > > > > On Wed, Jan 18, 2017 at 12:30:07PM -0800, Adit Ranadive wrote:
> > > > > 
> > > > > > 
> > > > > > In order to recover QP1 correctly after a link transition we
> > > > > > had to
> > > > > > go through a register/unregister since it is placed in error
> > > > > > state when the
> > > > port is down.
> > > > > 
> > > > > > 
> > > > > > In this case can the MAD layer re-initialize QP1 if link
> > > > > > transitions are
> > > > performed?
> > > > > 
> > > > > 
> > > > > Your driver needs to deal with this. Do whatever it takes to
> > > > > recover
> > > > > your QP1 without re-registring and do not bother the rest of
> > > > > the
> > > > > system with it.
> > > > 
> > > > Ok. We'll investigate internally on for a better recovery process
> > > > for QP1.
> > > 
> > > By the time I reply, most others requested same.
> > > Thanks for addressing it.
> > 
> > Hi Doug,
> > 
> > Please consider taking the other two patches in this series if
> > possible
> > for your next set of rc fixes.
> 
> If you want me to take these for the -rc cycle, then they need to be
> presented appropriately.  This patch (1/3) is gone just because it was
> the wrong solution (but it at least sounded like a fix).  Patch 2/3
> starts its subject with "Cleanup unused...", that doesn't sound
> remotely like a fix.  Patch 3/3 starts with "Don't hardcode...", which
> also doesn't sound remotely like a fix.  If you want these in the -rc
> cycle, then please repost the two other patches with suitable subjects
> and commit logs that make it clear these are real fixes needed in an
> -rc and not simple patches that should get applied in the for-next
> area.

Ah ok. Sorry for my misunderstanding. In that case there are two oneline
fixes - info leaked to user and an incorrect cleanup on the pci probe error
path. I'll separate them out from these patches and post separately.
Please, drop this series and I'll repost the patches 2,3 separately meant
for for-next.

Thanks,
Adit
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux