Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1867017ybb; Thu, 9 Apr 2020 10:27:25 -0700 (PDT) X-Google-Smtp-Source: APiQypI8gbEo6TEyhQE6ljEVz3rx1BacqjgRzTX1XUVHEQi/BKI/CiB2H/bWeb0xilhlVaVbZKuu X-Received: by 2002:ad4:514d:: with SMTP id g13mr1108423qvq.229.1586453245405; Thu, 09 Apr 2020 10:27:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586453245; cv=none; d=google.com; s=arc-20160816; b=OWF+YkwI126obhmLBX6bGlgWv4ioB9wZG/euIHa0CzuBo77k8tewiNw4cEbx80ziac B7KennddO6s4r9g8nx0+6fu5rLAM8v2jOPUoprazUVT1o4VSZaC17DK+tPUw5yfdn0Vm QDUlbqGFBKw9scU/3no934XML9kzGlfbpcOm/wJvMgwCYXNo2s5SNJTwc5CMIxzcrJSw NAoql0BdhzCBfv8k4jd0ODUi1MX3POO04yDphuw3ZWPZrray+eNyaHo34m8BzEjX1qOx ZSrnJP0wKIlC1gUUs9zMWQg8ZYcJQT9wdF2+kXCY4tfso9xh1SxWF+zvBtZ5hImBWioK Dwew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:message-id :in-reply-to:subject:cc:to:from:date; bh=TeSbbxlavhZpj+5F9GJ6bxRBzWmzOSh0o1lj6qxDtfk=; b=OgWczhjNncS6vZ2EUX/JJ3WJRlJFhYE5bC6o2mG77BwzB45YcbnY6R3fKdwZEMNw9I SOngmAiMsv2A0EVNyrn4VfTB88m1iBYTqS0F2NVh0QTtJZfpokRxuKsZ3E6gsKM/WIrr WQCRDGWJcURTCpecpIlPDu73o7cY5tbxe+4c+DMOquUl5pXN8EJaEWTiWG7DfuaTcAg8 P48HBdPLrxfHhUsg95ayjKa4B9PoFzHk0RNYuecnvhwLjP463eNv1Uj1SeuJeSYNaCFw yiA5BtM7nn0j3CsAlhZ/CsCynldiGXW3Zq/ToJPs+7ijdBk8GqTTsxmr4cQMrqPTsu0o +Nng== 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 a26si2207578qko.258.2020.04.09.10.27.09; Thu, 09 Apr 2020 10:27:25 -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 S1728377AbgDIQP3 (ORCPT + 99 others); Thu, 9 Apr 2020 12:15:29 -0400 Received: from eddie.linux-mips.org ([148.251.95.138]:41152 "EHLO cvs.linux-mips.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728254AbgDIQP3 (ORCPT ); Thu, 9 Apr 2020 12:15:29 -0400 Received: (from localhost user: 'macro', uid#1010) by eddie.linux-mips.org with ESMTP id S23994898AbgDIQP1Q4MN1 (ORCPT + 1 other); Thu, 9 Apr 2020 18:15:27 +0200 Date: Thu, 9 Apr 2020 17:15:27 +0100 (BST) From: "Maciej W. Rozycki" To: Jiaxun Yang cc: YunQiang Su , Tiezhu Yang , Thomas Bogendoerfer , linux-mips , LKML , Xuefeng Li Subject: Re: [PATCH] MIPS: Limit check_bugs32() under CONFIG_32BIT In-Reply-To: <7A98E39B-EDCF-496D-9525-0160A368361B@flygoat.com> Message-ID: References: <1586401829-22242-1-git-send-email-yangtiezhu@loongson.cn> <20200409150923.5b224361@flygoat-x1e> <7A98E39B-EDCF-496D-9525-0160A368361B@flygoat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 9 Apr 2020, Jiaxun Yang wrote: > > Why is using Kconfig supposed to be better? Several configurations > >support multiple processor types (e.g. swappable CPU daugthercards or > >FPGA > >soft-cores) and having to list CPU types across platforms as CPUs are > >added is going to be a maintenance nightmare. Whereas having > >workarounds > >or panics associated with run-time determination of the actual CPU type > > > >guarantees they will trigger where necessary. The use of `init' > >sections > >assures the reclaim of memory for use after bootstrap. > > Actually I meant let bug checks depends on Kconfig's CPU selection. > > It's guaranteed that you can only select one kind of CPU one time, > to prevent the overhead of checking bugs on irrelevant processors. That makes no sense to me sorry. When you select say a MIPS32r2 CPU for a Malta configuration, you can run it with a 4KE, 24K, 24KE, 34K, 74K, 1004K, M14K, and probably a few other CPUs I have forgotten about. Are you suggesting now that you want to require a separate kernel configuration for each of these CPUs? > And we still have to check PRID/CPUTYPE during boot to enable > proper workarounds, because the Kconfig options are telling about the possibility, > which means a processor potentially has some kinds of bug. > > In this case, M34K's errata should depends on or selected by > CPU_MIPS32_R2 in Kconfig. > > So there won't be any nightmare, but only reduced code :-) You'll need to manually maintain CPU assignment to configurations, which is not needed now. Anyway, please show your patch to let us see any improvement brought by it and we can discuss it then. Maciej