From mboxrd@z Thu Jan 1 00:00:00 1970 From: Davidlohr Bueso Subject: Re: [PATCH 05/11] IB/hfi1: convert __mmu_int_rb to half closed intervals Date: Fri, 4 Oct 2019 12:41:11 -0700 Message-ID: <20191004194111.2ntsr5kus5dgnnt4@linux-p48b> References: <20191003201858.11666-1-dave@stgolabs.net> <20191003201858.11666-6-dave@stgolabs.net> <20191004115057.GA2371@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Return-path: Content-Disposition: inline In-Reply-To: <20191004115057.GA2371@google.com> Sender: linux-kernel-owner@vger.kernel.org To: Michel Lespinasse Cc: akpm@linux-foundation.org, peterz@infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, dri-devel@lists.freedesktop.org, linux-rdma@vger.kernel.org, Mike Marciniszyn , Dennis Dalessandro , Doug Ledford , Davidlohr Bueso List-Id: dri-devel@lists.freedesktop.org On Fri, 04 Oct 2019, Michel Lespinasse wrote: >On Thu, Oct 03, 2019 at 01:18:52PM -0700, Davidlohr Bueso wrote: >> diff --git a/drivers/infiniband/hw/hfi1/mmu_rb.c b/drivers/infiniband/hw/hfi1/mmu_rb.c >> index 14d2a90964c3..fb6382b2d44e 100644 >> --- a/drivers/infiniband/hw/hfi1/mmu_rb.c >> +++ b/drivers/infiniband/hw/hfi1/mmu_rb.c >> @@ -47,7 +47,7 @@ >> #include >> #include >> #include >> -#include >> +#include >> >> #include "mmu_rb.h" >> #include "trace.h" >> @@ -89,7 +89,7 @@ static unsigned long mmu_node_start(struct mmu_rb_node *node) >> >> static unsigned long mmu_node_last(struct mmu_rb_node *node) >> { >> - return PAGE_ALIGN(node->addr + node->len) - 1; >> + return PAGE_ALIGN(node->addr + node->len); >> } > >May as well rename the function mmu_node_end(). I was worried if it >was used anywhere else, but it turned out it's only used when defining >the interval tree. Right. In general I tried not to rename everything to end because I wanted to avoid bloating the diffstat, albeit having naming discrepancies within the code (which isn't new either fwiw). > >I would also suggest moving this function (as well as mmu_node_first) >right before its use, rather than just after, which would allow you to >also remove the function prototype a few lines earlier. Indeed, but again I don't want to unnecessarily grow the patch. I have several notes to come back to once/if this series is settled. > >Looks good to me otherwise. > >Reviewed-by: Michel Lespinasse Thanks, Davidlohr