From patchwork Mon Dec 5 14:45:23 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Conor Dooley X-Patchwork-Id: 2607 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp2299275wrr; Mon, 5 Dec 2022 06:54:40 -0800 (PST) X-Google-Smtp-Source: AA0mqf4zZm/K44yuRZn1LSghQF+/s9/YhTb7etNiEI2S2z+U2pBPv7ZmCL9xcAU/oQBvI9gfXWxm X-Received: by 2002:a63:145e:0:b0:473:c377:b82 with SMTP id 30-20020a63145e000000b00473c3770b82mr58404897pgu.113.1670252080021; Mon, 05 Dec 2022 06:54:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670252080; cv=none; d=google.com; s=arc-20160816; b=rob7PiuMGHcVVM05ildsEdu3IYZOMuWrRzNQOF3SW66CPESZSNWH4wXrA++0//p4Gl 9FkfTMkEubYxKlqMv1fA5zO8ObKTWj59LYOzrtjoIPxjiPBfKIIjQNrZLhSQgjlLQbfM I4xKlFjUiUEL39WqrSZJK4tRscggz3zkWdrFmwgODgNndUWmk82EeRLnVT8/giCs8MCp 5XAZeowSUdElvx06vbjO5caqKU3yORUd7Ybm9g9whA3vru1lvb8lsey7CZIkuzVVJauc rKwfuookykr6voPur6CQZVNwowY4COXPiq93GQEZ5y84jx9ftxb1mY5Osn30Uk02QSZT 4hug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=xsO3DCYcVM1b3rj/J0oimrOG8Q72pelZ58zq0TvXR7c=; b=nHCalfcbwmkBrrtrBnzNxh5t2YtZVdAG5SCJbwIPn+ffPVWAjnuGMaHh9yg7DtySPT BkE/d7h8NlTnBOZu7TYv1bdOpQPpFEdTqw51JpYsmIeqvHoVNnS4Lq6p+EKLqEYkiaXQ Ph1d7F7f2nPB4QQVJ4SP1UKwbZr9+DA510S3zaeqTcB4g7iFkfV2S4hR7oNG5611qarV dytydTFq58kPN/V7B2TfRtVamqNepBetqyBJ1cN/WTFUX2zdIj/IIEmygAWWgSCYqQB2 1spp6IjqiIYHTcqVg14xFeruEiw0pDTnye2m1pDxEV/UdYqVRn5TyVVycq+HluqBTvkv wm2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@microchip.com header.s=mchp header.b=Nv9TCsQc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=microchip.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x133-20020a63318b000000b004784a56bccbsi14991304pgx.130.2022.12.05.06.54.24; Mon, 05 Dec 2022 06:54:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@microchip.com header.s=mchp header.b=Nv9TCsQc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=microchip.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232170AbiLEOqY (ORCPT + 99 others); Mon, 5 Dec 2022 09:46:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49702 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231770AbiLEOqR (ORCPT ); Mon, 5 Dec 2022 09:46:17 -0500 Received: from esa.microchip.iphmx.com (esa.microchip.iphmx.com [68.232.154.123]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BC2EF1B1FA; Mon, 5 Dec 2022 06:46:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1670251573; x=1701787573; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=fNYiF1ogl3tzaX/gkv9v+1He+AojtwgLXxTo8k5gkC4=; b=Nv9TCsQc5jgg8O5OmVo+ipvS4H6BBva2QI8YkwtneHjis5lvKR/B0KDN xs+UkqWizoEyLLoP99r42BJcHiqcwC8IKotdON0/NVg3b8cvsHalS+vAh KefP12qNonobpXGrf9XN2saJHMGXz/WNUh6YKSXD2q16rn6vrO1XJUKY7 QkNY1l3vH2ZNlIHOUM5TAo093gDJDUbl1p93Sxxr4RZur9eB98nbMBIwb wuO8u33CqBlYZS+uCV7OrOQMnOFrXQpOucUfvBB3IZ4oUZYqvTtX3jJoK PhnxoDsKQOuhRMTpg+L7CPCq6bYKtCeoZ6yeCf/V0tx8p6IRTmKiXkQLL w==; X-IronPort-AV: E=Sophos;i="5.96,219,1665471600"; d="scan'208";a="126535113" Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa6.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 05 Dec 2022 07:46:12 -0700 Received: from chn-vm-ex04.mchp-main.com (10.10.85.152) by chn-vm-ex01.mchp-main.com (10.10.85.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.12; Mon, 5 Dec 2022 07:46:12 -0700 Received: from wendy.microchip.com (10.10.115.15) by chn-vm-ex04.mchp-main.com (10.10.85.152) with Microsoft SMTP Server id 15.1.2507.12 via Frontend Transport; Mon, 5 Dec 2022 07:46:10 -0700 From: Conor Dooley To: , Palmer Dabbelt CC: Conor Dooley , , , , , , , , , Subject: [PATCH v2 0/3] Putting some basic order on isa extension lists Date: Mon, 5 Dec 2022 14:45:23 +0000 Message-ID: <20221205144525.2148448-1-conor.dooley@microchip.com> X-Mailer: git-send-email 2.38.1 MIME-Version: 1.0 X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1751386244991732376?= X-GMAIL-MSGID: =?utf-8?q?1751386244991732376?= For v2+, I added another path with some uapi docs & switched to Drew's suggested ordering of alphabetically, except in the /proc/cpuinfo array, as per the discussion today in the pw-sync call. I also added a sprinkling of comments around which things should be sorted in which way. Pasting from the chat on v2, since it's relevant to whether re-ordering what appears in /proc/cpuinfo is even permitted.. I wrote: > Drew wrote: > > My biggest concern is how much we need to care about the order of the > > string in proc and whether or not we're allowed to fix its order like > > we're doing with this patch. I hope we can, and I vote we do. > > Being a bit hard-nosed about it: > - the spec has said for years that this order is not correct > > - their parser cannot assume any given extension is even present, so the > index at which the extension starts was only ever going to vary wildly > > - to break a parser, it must expect to see extension Abcd before Efgh & > that order has to change for them > > - expecting that a given pair of extensions that appeared one after > another would always do so is not something we should worry about > breaking as it was always noted in the comment (and by the specs?) > that new extensions would be added in alphabetical order (I'd like to > think that if a clairvoyant wrote a parser and knew that there'd be > nothing in the gap between the extensions we have now & what may be > produced they'd also account for this re-ordering...) > > - the re-order of sstc is going to land for v6.1 & the addition of sstc > out of order landed in v6.0, so either that is an issue too or this is > fine I'm sending the patchset, so I think it's bordering on obvious that I think doing this is likely okay & maintaining a "strict" interpretation of what the spec says is the way to go. I think the only case we have to worry about breaking uABI stuff is if this changes behaviour in a way that could not be done by an otherwise valid change in the ISA string, so bullet 3 above. I'll leave that determination up to the Higher Powers, but I think it's going to be very difficult not to accidentally break this order in the future if we decide that what is currently there, must remain exactly as-is. Thanks, Conor. Changes since v1: - strengthened some wording to use "must" - reworded the bits in both code & doc about what canonical order is - added some missing "... must be in alphabetical order" sections to both code & doc - forced an _ before multi-letter extensions - there's likely a trivial conflict with drew's addition of an assert for RISCV_ISA_EXT_ID_MAX. CC: ajones@ventanamicro.com CC: aou@eecs.berkeley.edu CC: conor@kernel.org CC: conor.dooley@microchip.com CC: corbet@lwn.net CC: guoren@kernel.org CC: heiko@sntech.de CC: palmer@dabbelt.com CC: paul.walmsley@sifive.com CC: linux-kernel@vger.kernel.org CC: linux-riscv@lists.infradead.org CC: linux-doc@vger.kernel.org Conor Dooley (3): RISC-V: clarify ISA string ordering rules in cpu.c RISC-V: resort all extensions in consistent orders Documentation: riscv: add a section about ISA string ordering in /proc/cpuinfo Documentation/riscv/uabi.rst | 42 +++++++++++++++++++++++++++ arch/riscv/include/asm/hwcap.h | 12 ++++---- arch/riscv/kernel/cpu.c | 53 ++++++++++++++++++++++++---------- arch/riscv/kernel/cpufeature.c | 6 ++-- 4 files changed, 91 insertions(+), 22 deletions(-)