Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp3356171ybl; Mon, 19 Aug 2019 17:23:34 -0700 (PDT) X-Google-Smtp-Source: APXvYqwE4gXZELWSGZ2AdD/3gUxHv7Hla2NieOpFaTuhyfJlhjYJAo9Laria0Ie4U0G07osNR5BX X-Received: by 2002:a17:90a:7304:: with SMTP id m4mr23755093pjk.73.1566260614883; Mon, 19 Aug 2019 17:23:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566260614; cv=none; d=google.com; s=arc-20160816; b=aLNQDTactEfI6ApwA1L2el/CydLRb1hdhiP471MqHR8DbnPxu6W4PnAmfL/HBkmWS3 c3+tnVzyynpfUwO9NwdRw9p1aqpLU8jOYCbK3cohCX4+qDaxk/Y43IiYDBOIa5/CRT4T +JEiLeOQS55FPgUBpNzHpFEowfqMQU5oxnBIn9N0Gc0pQYxmJKtuehNXM2BQcxFGj0IH kKeg9jD5XTKEUlcEN0//L9AGZq3EIMbwQj02FTPMmb2XM0B/GoSRxarbY77ahvz/lDm2 U/83fmpAs5bkJhrGUkA/+VwTHpjhkmXzl0HgOQZJWEp4CjJu8jePYvYUDe/5SqpL6o5v y+IA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=jVuDHc+ipmL7RwIL29Mnx7+XwT/m/lZzSEI+1IJcz/4=; b=Gbt5c+1vDVJEUlSSgoGZKpEBxCyTYYuCcGheKvIvPK1pi5euKMifoBKIz1ZnzyBzZ2 y4WlOLzMwQtwmfUdoY1AD66Awcb3VmkqKaHcr96OikySRXs2bNQSfr+fqRLRYXeKMDUn T4zTvI9tXn3XwLoxVyLBWX1uAITb07nafFhpp67ZCEEUKoNLDpl8RNQzG/4pK63Em/PT Pw/Dy3d+TolUDsFphEsOgRvQcIykEnFpd3OC7LYFpJ0hM7Ihcio6lbT/E2GxDLzunJGW gPz47mezTt6tgLJ7t+ZpWj3LkWDzBKrnHZ129kDP5Wt8XczdbATTGVIJM/GuLC/h4ZSp PryQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n22si9826690pjt.55.2019.08.19.17.23.19; Mon, 19 Aug 2019 17:23:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729108AbfHTAUW (ORCPT + 99 others); Mon, 19 Aug 2019 20:20:22 -0400 Received: from ozlabs.org ([203.11.71.1]:39851 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728985AbfHTAUU (ORCPT ); Mon, 19 Aug 2019 20:20:20 -0400 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 46CBJg0XFkz9sNC; Tue, 20 Aug 2019 10:20:18 +1000 (AEST) From: Michael Ellerman To: Nicholas Piggin , Benjamin Herrenschmidt , Christophe Leroy , Paul Mackerras Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v1 05/10] powerpc/mm: Do early ioremaps from top to bottom on PPC64 too. In-Reply-To: <1566221500.6f5zxv68dm.astroid@bobo.none> References: <6bc35eca507359075528bc0e55938bc1ce8ee485.1565726867.git.christophe.leroy@c-s.fr> <019c5d90f7027ccff00e38a3bcd633d290f6af59.1565726867.git.christophe.leroy@c-s.fr> <1566221500.6f5zxv68dm.astroid@bobo.none> Date: Tue, 20 Aug 2019 10:20:16 +1000 Message-ID: <87r25g662n.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Nicholas Piggin writes: > Christophe Leroy's on August 14, 2019 6:11 am: >> Until vmalloc system is up and running, ioremap basically >> allocates addresses at the border of the IOREMAP area. >> >> On PPC32, addresses are allocated down from the top of the area >> while on PPC64, addresses are allocated up from the base of the >> area. > > This series looks pretty good to me, but I'm not sure about this patch. > > It seems like quite a small divergence in terms of code, and it looks > like the final result still has some ifdefs in these functions. Maybe > you could just keep existing behaviour for this cleanup series so it > does not risk triggering some obscure regression? Yeah that is also my feeling. Changing it *should* work, and I haven't found anything that breaks yet, but it's one of those things that's bound to break something for some obscure reason. Christophe do you think you can rework it to retain the different allocation directions at least for now? cheers