From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 90B8EEB64D7 for ; Wed, 28 Jun 2023 17:34:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231346AbjF1ReD (ORCPT ); Wed, 28 Jun 2023 13:34:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230379AbjF1Rd7 (ORCPT ); Wed, 28 Jun 2023 13:33:59 -0400 Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5EF5A210B for ; Wed, 28 Jun 2023 10:33:58 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-4fb8574a3a1so3542618e87.1 for ; Wed, 28 Jun 2023 10:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20221208.gappssmtp.com; s=20221208; t=1687973636; x=1690565636; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=mu8Gi2wSnoTXkOMcCin+xgkyW4SfsZOtfaMQ9m+MZ5U=; b=ctXSjsQSzaufeY9GTPqn+avzhgMNvjo9PgbMSWr3gC1OzFmKrqHpkfW/Hh4/BxaRHj oatlyGdfBX5is3/rXAkRtPpuVaBjnbVAWHtGueEalCtd0kiWVV+nHvycDQA6ttsaegMd 3lcR9743n2mULg7SZFP8WAzgB7VrDSJyHfySHd5R6/1eVpsEDvWiJ7WrXlv0a9KSs29x WETDEpY2W0csY2Kc8h8MS0M9gIM0+saldCRjt5f4n2ePrtvwjqb9Q37Q+s3b2t5w550r rE7oMwUkLRYM2F7ETOGVj7LBn7mLZofgXEPOlaZgFM5DxnuqH6dXXJk0pzK8+aL2GhCR 7xfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687973636; x=1690565636; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mu8Gi2wSnoTXkOMcCin+xgkyW4SfsZOtfaMQ9m+MZ5U=; b=OQQmwBiWtUaJUnsrwTwIHmgorMucU/y96TcvcrLP2EfAuPlE87ST6ziIzDSyST7xkq 29EzpeEPu0JH+mByAbCPeBQ3Q0BY1Z8LtTx97vJBZzKn/mwXTpzjNEsFmvxu4nVjrRp/ EJs8/1gm5ndvCRrRPCrUrGSRhJfQvy1xDkTHQ1GR/7Vv/6deQelPxdYruFOXrHZg8XRU vDsPNWjxMU9yr7SJAjyCCUFALy57EGg3fgCYjXTeQJg+aHVvSu0hefUIA5PVzVa3Wo+1 IkLXrd0pr9zOabxo8B2kChZJiM3AI0R0FbPuEnJyGSMwlQzsdzqCWtdpkO2y5X/cuCRK 1SvQ== X-Gm-Message-State: AC+VfDxZrqPDWXquVRtwS4czGNPKTcTyftrLZrFHdlbTHpiDu71bmK+H RSlAUqEFdqP8L0lCqbCcpUUFVhmZe6vgtcEYNsZHAw== X-Google-Smtp-Source: ACHHUZ7/LXypQ2b7zt5BdRodKsoDzSYUcdIaTGpou0UZUfpPyxiEPFkUIurdLsWJ+cccDbdbnTpgIrlMLbBaiJoTBCY= X-Received: by 2002:a19:7710:0:b0:4f8:6800:86f6 with SMTP id s16-20020a197710000000b004f8680086f6mr16992828lfc.49.1687973636628; Wed, 28 Jun 2023 10:33:56 -0700 (PDT) MIME-Version: 1.0 References: <20230626-provable-angrily-81760e8c3cc6@wendy> <20230626-sensuous-clothing-124f7ae0aedf@wendy> In-Reply-To: <20230626-sensuous-clothing-124f7ae0aedf@wendy> From: Evan Green Date: Wed, 28 Jun 2023 10:33:20 -0700 Message-ID: Subject: Re: [PATCH v1 6/9] RISC-V: add single letter extensions to riscv_isa_ext To: Conor Dooley Cc: palmer@dabbelt.com, conor@kernel.org, Rob Herring , Krzysztof Kozlowski , Paul Walmsley , Albert Ou , Andrew Jones , Heiko Stuebner , Sunil V L , linux-riscv@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Mon, Jun 26, 2023 at 4:21=E2=80=AFAM Conor Dooley wrote: > > So that riscv_fill_hwcap() can use riscv_isa_ext to probe for single > letter extensions, add them to it. riscv_isa_ext_data grows a new > member, signifying whether an extension is multi-letter & thus requiring > special handling. > As a result, what gets spat out in /proc/cpuinfo will become borked, as > single letter extensions will be printed as part of the base extensions > and while printing from riscv_isa_arr. Take the opportunity to unify the > printing of the isa string, using the new member of riscv_isa_ext_data > in the process. > > Signed-off-by: Conor Dooley > --- > arch/riscv/include/asm/hwcap.h | 1 + > arch/riscv/kernel/cpu.c | 36 ++++++---------------- > arch/riscv/kernel/cpufeature.c | 56 +++++++++++++++++++++------------- > 3 files changed, 46 insertions(+), 47 deletions(-) > > diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwca= p.h > index a35bee219dd7..6ad896dc4342 100644 > --- a/arch/riscv/include/asm/hwcap.h > +++ b/arch/riscv/include/asm/hwcap.h > @@ -77,6 +77,7 @@ unsigned long riscv_get_elf_hwcap(void); > struct riscv_isa_ext_data { > const unsigned int id; > const char *name; > + const bool multi_letter; Instead of defining a new member, could we just infer this by making a macro like #define MULTI_LETTER(name) (name[0] && name[1])?