From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161967AbbKTNYR (ORCPT ); Fri, 20 Nov 2015 08:24:17 -0500 Received: from mail-qk0-f179.google.com ([209.85.220.179]:33361 "EHLO mail-qk0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934878AbbKTNYQ (ORCPT ); Fri, 20 Nov 2015 08:24:16 -0500 Date: Fri, 20 Nov 2015 08:24:13 -0500 (EST) From: Nicolas Pitre To: Arnd Bergmann cc: Russell King - ARM Linux , linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [GIT PULL] optimize 64-by-32 ddivision for constant divisors on 32-bit machines In-Reply-To: <4208584.1csaaiK5v3@wuerfel> Message-ID: References: <3830931.6tMHPeiNRU@wuerfel> <4208584.1csaaiK5v3@wuerfel> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323328-1378987080-1448025854=:22569" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1378987080-1448025854=:22569 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT On Fri, 20 Nov 2015, Arnd Bergmann wrote: > On Thursday 19 November 2015 19:29:33 Nicolas Pitre wrote: > > On Thu, 19 Nov 2015, Arnd Bergmann wrote: > > > > > On Monday 16 November 2015 20:20:38 Nicolas Pitre wrote: > > > > Arnd, > > > > > > > > Please pull the following branch: > > > > > > > > git://git.linaro.org/people/nicolas.pitre/linux div64 > > > > > > Pulled into my asm-generic tree now, it should show up in linux-next > > > tomorrow. > > > > Thanks. > > > > I removed a small optimization from the top commit that was included by > > mistake into a patch that was supposed to produce identical code > > (noticed by Måns). It's not urgent but it would be good if you could > > repull at some point. > > I already applied another patch on top, could you send a relative > patch instead? If that ends up being ugly, I can redo the branch, > but I generally prefer to not rebase things I have on kernel.org that I > plan to send to Linus. Alternately we can leave things as they are. There is no bugs here, just that the changelog doesn't exactly describe the change. Nicolas --8323328-1378987080-1448025854=:22569--