Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp995230ybj; Thu, 7 May 2020 12:15:53 -0700 (PDT) X-Google-Smtp-Source: APiQypL2wniMM8iDPh5rCg7l8XwbkSYLAzK7Cv9jem4b+ygkjXzwCf+DL6Wl19fOJY6yYShBil9d X-Received: by 2002:a17:907:9481:: with SMTP id dm1mr14231223ejc.268.1588878953318; Thu, 07 May 2020 12:15:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588878953; cv=none; d=google.com; s=arc-20160816; b=iXLFwhK3MZwGsyB7fZOD2xnTr3ka9HhRKUCOdCbxsnzGdpvh22kAGzFITDKw7hKJUq rXlc39GEeh9z9arIVnxzYm9gYbuBzRI5t6V7wk+RC6AhDkiXKsj6ENIs12fYr59WcrQZ NNjcLF1TDyhFGj7xe1vIy/EgDs7Ta4hHzFN2pXxa7EepeHsNMXy42rfaCbb9oELOMmiD wZkEfYpWJKNz6q4Q+qf/myWa+Lw4BHsJYO0YxR3v6k9M1/byJQrOPU3HeIm/yBGBww6v LMwzUI49aFt2X6Od6Vfg4UwihtDh8HmZGRSFXGWrBQO3zz1oJCesG6/z23oNgaj8NFWs Sapw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=b8wnGywjLiHrE5yDrP5mlkPO8ZCDcEsRxkIUh15iOP8=; b=YePS3EYh5HtBXpHaPxMKX/xnszN/EfoVjox9/WVNnYIrgGxuiFtv9bTFPmmscHaS+W +zJFZkVh1DhMzKE/NOuAys1g+lOyw1Z8hXiW6wmZhivLwySm9NxJwaBiK8juTWh5LNnH fARvyhPE6SjiFaAguEclVe7GsfZCksxvPN6o1FQwJvS3kA3CMitpM83CA0Osr1oJvoI5 SZVNrWu2Z3olcX8Pl6aYV03aux4krhImsQWTJIE2UDhgXvOa9CNDKbflS7cGI0p6DIkh dohvydFA2Y9Oz6jkhI2CtjrFIRA1mAQwgiJ8MfO7EkigIo7FXk0r/0xts5g65HiJTOFQ 0YmA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id oy7si3712400ejb.169.2020.05.07.12.15.29; Thu, 07 May 2020 12:15:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728378AbgEGTNt (ORCPT + 99 others); Thu, 7 May 2020 15:13:49 -0400 Received: from mail.baikalelectronics.com ([87.245.175.226]:38258 "EHLO mail.baikalelectronics.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726558AbgEGTNt (ORCPT ); Thu, 7 May 2020 15:13:49 -0400 Received: from localhost (unknown [127.0.0.1]) by mail.baikalelectronics.ru (Postfix) with ESMTP id 590F2803087B; Thu, 7 May 2020 19:13:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at baikalelectronics.ru Received: from mail.baikalelectronics.ru ([127.0.0.1]) by localhost (mail.baikalelectronics.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gxrh3JYj9Az; Thu, 7 May 2020 22:13:38 +0300 (MSK) Date: Thu, 7 May 2020 22:13:37 +0300 From: Serge Semin To: Thomas Bogendoerfer CC: Alexey Malahov , Paul Burton , Ralf Baechle , Arnd Bergmann , Rob Herring , , , Zhou Yanjie , Paul Cercueil , Jiaxun Yang , , Subject: Re: [PATCH v2 11/20] mips: MAAR: Use more precise address mask Message-ID: <20200507191337.la6z476myszqethj@mobilestation> References: <20200306124807.3596F80307C2@mail.baikalelectronics.ru> <20200506174238.15385-1-Sergey.Semin@baikalelectronics.ru> <20200506174238.15385-12-Sergey.Semin@baikalelectronics.ru> <20200507110951.GD11616@alpha.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20200507110951.GD11616@alpha.franken.de> X-ClientProxiedBy: MAIL.baikal.int (192.168.51.25) To mail (192.168.51.25) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 07, 2020 at 01:09:51PM +0200, Thomas Bogendoerfer wrote: > On Wed, May 06, 2020 at 08:42:29PM +0300, Sergey.Semin@baikalelectronics.ru wrote: > > From: Serge Semin > > > > Indeed according to the P5600/P6000 manual the MAAR pair register > > address field either takes [12:31] bits for 32-bits non-XPA systems > > and [12:35] otherwise. In any case the current address mask is just > > wrong for 64-bit and 32-bits XPA chips. So lets extend it to 39-bits > > value. This shall cover the 64-bits architecture and systems with XPA > > enabled, and won't cause any problem for non-XPA 32-bit systems, since > > the value will be just truncated when written to the 32-bits register. > > according to MIPS32 Priveleged Resoure Architecture Rev. 6.02 > ADDR spans from bit 12 to bit 55. So your patch fits only for P5600. > Does the wider mask cause any problems ? No, it won't. Bits written to the [40:62] range will be just ignored, while reading from there should return zeros. Setting GENMASK_ULL(55, 12) would also work. Though this solution is a bit workarounding because MIPS_MAAR_ADDR wouldn't reflect the real mask of the ADDR field. Something like the next macro would work better: +#define MIPS_MAAR_ADDR \ +({ \ + u64 __mask; \ + \ + if (cpu_has_lpa && read_c0_pagegrain() & PG_ELPA) { \ + __mask = GENMASK_ULL(55, 12); \ + else \ + __mask = GENMASK_ULL(31, 12); \ + \ + __mask; \ +}) What do you think? What is better: the macro above or setting GENMASK_ULL(55, 12)? BTW I've just figured out, that since XPA is currently only supported by kernels with CPU_MIPS32x config enabled, then only MIPS32 may have extended physical addressing of 2^60 bytes if CONFIG_XPA is enabled. Generic MIPS64 doesn't support the extended phys addressing so only 2^36 bytes are available on such platforms. (Loongson64 doesn't count, the platform code sets the PG_ELPA bit manually in kernel-entry-init.h) -Sergey > > Thomas. > > -- > Crap can work. Given enough thrust pigs will fly, but it's not necessarily a > good idea. [ RFC1925, 2.3 ]