On Tue, 2018-05-22 at 15:53 -0600, Jason Gunthorpe wrote:
> On Tue, May 22, 2018 at 05:48:43PM -0400, Jonathan Toppins wrote:
> > On 05/22/2018 02:56 PM, Doug Ledford wrote:
> > > On Mon, 2018-05-14 at 13:47 -0400, Devesh Sharma wrote:
> > > > This 2 patch series mainly focus on assigning MSIx vectors
> > > > to RoCE driver when L2 driver dynamically changes vectors
> > > > allowed for RoCE driver.
> > > >
> > > > Patch 1 is mainly refactoring code while Patch 2 is the one
> > > > to handle the real reassignment.
> > > >
> > > > Devesh Sharma (2):
> > > > bnxt_re: refactor creq irq init and fp irq init
> > > > bnxt_re: pause roce irqs when l2 need reshuffling
> > > >
> > > > drivers/infiniband/hw/bnxt_re/main.c | 55 ++++++++++++++++-
> > > > drivers/infiniband/hw/bnxt_re/qplib_fp.c | 95 +++++++++++++++++++-----------
> > > > drivers/infiniband/hw/bnxt_re/qplib_fp.h | 3 +
> > > > drivers/infiniband/hw/bnxt_re/qplib_rcfw.c | 61 +++++++++++++------
> > > > drivers/infiniband/hw/bnxt_re/qplib_rcfw.h | 3 +
> > > > 5 files changed, 164 insertions(+), 53 deletions(-)
> > > >
> > >
> > > Thanks, series applied.
> > >
> >
> >
> > Hi Doug,
> >
> > I see these made it into your 'wip/dl-for-next' branch. However, it is
> > my understanding that without these patches in v4.17 VFs for bnxt_re
> > will be broken as the bnxt_en patches causing the breakage made it into
> > v4.17.
> >
> > Can we get these into v4.17 or should we forward these on to
> > linux-stable to be backported to v4.17.y?
>
> The commit messages are not good enough for -rc at this point, they
> need Fixes lines and they need to actually explain that the driver is
> broken and not be described as 'refactoring code'
>
> .. and the cover letter shouldn't describe the series as though it is a
> new feature.
>
> .. nor should it ask to be put into for-next
>
> Broadcom will have to sort this out, there is probably about 12 hours
> to ask the patches be dropped out of wip's for-next if that is the
> desire. Otherwise they have to manage to get it submitted to
> 4.17-stable after it is released.
>
> Wow, I'm having this great sense of dejavu like I wrote a message just
> like this a few months ago..
>
> Jason
I'm actually really liking the wip/* workflow. It does give a 12 to 24
hour window to fix things up.
Now, as to the fact that the commit messages are not really good...we
can fix them up as long as we can get the needed commit log messages
from Broadcom:
What's broken without these changes? What is the user visible symptom
of that brokenness? How do these changes resolve that brokenness?
Relevant Fixes: tags and stable tags as well. That will take care of
4.17.
However, as Don/Jon both know, fixing up these commit messages will
result in a new upstream hash :-(. Not that big of a deal, just throws
off Don's and Jon's work if they've already picked these up for backport
purposes.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDDAttachment:
signature.asc
Description: This is a digitally signed message part
