Hello Doug, Please drop this patch series from "for-next", I will resend the patches to "for-rc" and address the comments from Jason in the new series. -Regards Devesh On Wed, May 23, 2018 at 5:00 AM, Doug Ledford <dledford@xxxxxxxxxx> wrote: > 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 2FDD -- 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
