Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp1492600ybj; Fri, 8 May 2020 02:35:01 -0700 (PDT) X-Google-Smtp-Source: APiQypIXN1JaJc3J+4gYXEx8hUDR/rdWHTb1mHDbBZDXfATjWEyVA9BmYumCHXfpPVqrdhiHWtH5 X-Received: by 2002:a17:906:57d7:: with SMTP id u23mr1009281ejr.354.1588930500911; Fri, 08 May 2020 02:35:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588930500; cv=none; d=google.com; s=arc-20160816; b=Gjckn8KCVCraeSBkbeeZA8wGYytGYFrrloI/ma+kmTWbOFV5Nj0WrL33PgvHGT/gIM +Q44rffgnl1emE9f3ZhNQCZ3iIOiYbDXXUzRYhSEhARpFSkQHgBURajhCsSGLKFYN2bd izCfwoMcpKDG2+37Qaa/yqGUoVWVTPfVRLJ1JSAUKwxyO0S60amiW66GQvf6y9JPsMTD 4ANxoT+8b/VINnd/Oy773wqrTUeVjh/ApNWVpSILWYjkjra5rH9cB5Wv7gk4dGSrrb5X 5sltJ8IILfnQU+zT6yVppbKQevrdGCD9K41X4q2kY8BsQkus9bPsaReC2VO1wGEbAEFw Mk0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=O7+vyl+5HsmfOdO8UKBI71oeY5TwwiDLRYp9qGZpA8c=; b=lJaBA3wxmFDvbJtiEs2NSL5Lw1t28mYhD1SPQhhV04wfVb5DFnNsUQkBfs7VgUoW9A oQapHJuCmFlqIldcE/BibS71951gd3ti/TKmIq+nV8IIprbUekyV5MQowR/d/bJpz2n+ eEm4SFh+0fI3hWZOQciVe9cSsPW7goVxOFmeUwVGmSLwJZ/puWYh0JPkXBt/67c2di6n A2ecNicN003ur0qVgF6cLDxLNsHUXwALlcoMuOYY1oRqipQ39Txc23XAlFN5D+Xr9Sjj fWEQy+MN0+X2gPaHbGYGE/trdv9oW/mQnwll2f+G20GezD6gX2pt86jye+BY36cVYgnM GXcw== 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 i5si601954eds.369.2020.05.08.02.34.37; Fri, 08 May 2020 02:35:00 -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 S1726873AbgEHJdO (ORCPT + 99 others); Fri, 8 May 2020 05:33:14 -0400 Received: from elvis.franken.de ([193.175.24.41]:44677 "EHLO elvis.franken.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725775AbgEHJdN (ORCPT ); Fri, 8 May 2020 05:33:13 -0400 Received: from uucp (helo=alpha) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1jWzNV-0001bD-00; Fri, 08 May 2020 11:33:09 +0200 Received: by alpha.franken.de (Postfix, from userid 1000) id A9DC3C040C; Fri, 8 May 2020 11:22:36 +0200 (CEST) Date: Fri, 8 May 2020 11:22:36 +0200 From: Thomas Bogendoerfer To: Serge Semin Cc: Alexey Malahov , Paul Burton , Ralf Baechle , Arnd Bergmann , Rob Herring , linux-pm@vger.kernel.org, devicetree@vger.kernel.org, Zhou Yanjie , Paul Cercueil , Jiaxun Yang , linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 11/20] mips: MAAR: Use more precise address mask Message-ID: <20200508092236.GA9085@alpha.franken.de> 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> <20200507191337.la6z476myszqethj@mobilestation> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200507191337.la6z476myszqethj@mobilestation> User-Agent: Mutt/1.5.23 (2014-03-12) 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 10:13:37PM +0300, Serge Semin wrote: > 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; \ > +}) that looks horrible. > What do you think? What is better: the macro above or setting > GENMASK_ULL(55, 12)? just that one ;-) Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ]