Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1951082pxb; Sat, 27 Feb 2021 05:47:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJyuP4gyO9rCsiZUmwI8u7gOBS066gfJVRBZNO+OdvFtVGm7luLjqPkRUdLF5nA85iTSMj/P X-Received: by 2002:aa7:d64f:: with SMTP id v15mr8163276edr.358.1614433643360; Sat, 27 Feb 2021 05:47:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614433643; cv=none; d=google.com; s=arc-20160816; b=NbzvjKrLnUFQLVcaqs0zKsa+o3/kDff27l0vCH9rjSK57ztsj3xxu1FMR2HnZXw7AM +Uv4zxwYwNHKGS+KV1mWcSoIcJmt5XDlC/RqiS57JLnDGutZ1BrQJhjozn0kynUL7nT3 d/szBQtyHVHHNk5Zt4P9um3FLp6vXx/b8+Nac+zQstwmyWey5W9puJzLHdzU1EmP3FmK lVaIbxt4mqlHuubVHbdisLOG/JvLXocfgiYPNWQPbFUBdTkXwK/tiPkW1AAm1Lf78FjN lVhP2yzu7jgCLh7nmOfOVegYw2VSt2Ifez+MeAwUDDchvtl+/kpvtaajzr4iF0OXetj+ QVVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date; bh=3cmf9t5I3yHdci+fRY/4sJwWt/O38VR9XkDbEqpv284=; b=t/BpOC0ue52xgCQeypoaos8hgZEuk1uuBNvfTcsxabCTf4t+73ML+hbGHEVSC5+TGL yEaUkzdSeVLGjW0yjEU/tMutWaBnrjoYu7xvVONfQdLaxAkghq6gGZ11u3xODYom40He k1uPBB5e84O9c+Y9iKVSHOFF7aeHu9RFtVD4Y2D3x+4QqSq2KCnOKPiYrWL0NvpJSgr+ CeqonXsE9KZjKI9iPVDCoDZrhEOrswXuVLcC34jH1+zkqrhK4ReEhCEr/DdstkGPVLNg rbQRKza25lSoWev1jC+CEqMxTDkrTG6RsJhkLoN9wHEhYsF+DArxWJiy7DCC24J1y8PK RO7A== 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 kb16si846547ejb.190.2021.02.27.05.46.59; Sat, 27 Feb 2021 05:47:23 -0800 (PST) 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 S230049AbhB0Nlh (ORCPT + 99 others); Sat, 27 Feb 2021 08:41:37 -0500 Received: from angie.orcam.me.uk ([157.25.102.26]:36996 "EHLO angie.orcam.me.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229912AbhB0Nlg (ORCPT ); Sat, 27 Feb 2021 08:41:36 -0500 Received: by angie.orcam.me.uk (Postfix, from userid 500) id 1379E92009C; Sat, 27 Feb 2021 14:40:55 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 06EF692009B; Sat, 27 Feb 2021 14:40:55 +0100 (CET) Date: Sat, 27 Feb 2021 14:40:54 +0100 (CET) From: "Maciej W. Rozycki" To: "Jason A. Donenfeld" cc: linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, Thomas Bogendoerfer , Ralf Baechle , George Cherian , Huacai Chen , Jiaxun Yang Subject: Re: [PATCH] MIPS: select CPU_MIPS64 for remaining MIPS64 CPUs In-Reply-To: <20210227122605.2680138-1-Jason@zx2c4.com> Message-ID: References: <20210227122605.2680138-1-Jason@zx2c4.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 27 Feb 2021, Jason A. Donenfeld wrote: > The CPU_MIPS64 and CPU_MIPS32 variables are supposed to be able to > distinguish broadly between 64-bit and 32-bit MIPS CPUs. However, they That is not true. The purpose of these options is to identify MIPS64 and MIPS32 ISA processors respectively (and the generic features these ISAs imply). There are 64-bit and 32-bit MIPS processors which do not qualify, specifically all MIPS I, MIPS II, MIPS III, and MIPS IV implementations. > weren't selected by the specialty CPUs, Octeon and Loongson, which meant > it was possible to hit a weird state of: > > MIPS=y, CONFIG_64BIT=y, CPU_MIPS64=n This is a correct combination for MIPS III and MIPS IV processors. > This commit rectifies the issue by having CPU_MIPS64 be selected when > the missing Octeon or Loongson models are selected. From the description and/or other options selected by CPU_LOONGSON64 and CPU_CAVIUM_OCTEON I infer the change itself is correct, so you only need to rewrite the change description. Though overall it seems we have quite a mess here, several other CPUs, such as at the very least CPU_XLR and CPU_XLP, do not select this option either, and then we have say CPU_MIPSR2 that is selected by some CPUs while being conditional on other ones. All this stuff asks for being rewritten in a consistent manner. In any case your change may have to be run-time verified though with the respective processors. Maciej