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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 13B20C54E58 for ; Fri, 15 Mar 2024 08:11:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=My9LFgUnU8gTf4PcRxC25tpTm0wFCol87KrHsknvsoI=; b=YsA5GsYHbqvWfq UU5qGg6sBNKgK+YJUdgQG+OtgSwbEN8npQ85qaVpNiMAfj3h9w8UCyCOCE0NVWDH0OuYwq5QZgWYp F4hvAFv2dPzSWIVzF/49Kbv+gPptNaZtLxKMdJvmmE6gJ2urYf6VI9O+2x0HUKgJGsupbml3imh56 rRNW/R3XdHzuwdACD8HMm9Kb9fRAA0/t3aiX7Ao17hiPN8J/S81yfeygbAhvahAZLL0xnl3WztkMm 9iMsYTLtMVkm7V29fTqenYWh9XOAIDGbZje8IxdGiUr19ZoeWl4N+6SKP0eGfQLEpqqzjyoRwN8xK rFOiqty1tUYPl2YiD2oA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rl2fG-0000000H66e-0hfy; Fri, 15 Mar 2024 08:11:42 +0000 Received: from mail-ej1-x62d.google.com ([2a00:1450:4864:20::62d]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rl2fC-0000000H64W-3ChB for linux-arm-kernel@lists.infradead.org; Fri, 15 Mar 2024 08:11:40 +0000 Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-a468004667aso91161466b.2 for ; Fri, 15 Mar 2024 01:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1710490296; x=1711095096; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=s/GjHxvspqde5PDmyzE58y/UK2LQWPcFmtqDdmYzTvY=; b=ZVEZZQYn8RQysOVnnHwpcWI6Xlh+iGKkGf1r+6x1YAvneydNXlG62qKxdt2O0AKIBz kdvNjgrJx23qAAewYZ9/jTzhwt8nIspejYTbZ7VcY6slsL3XVIfn4rKKFOC4xsplnxaI qjx7Yzwhv+cm342trG6j6z3raNZzh3P/J31yDUYZHdP0vV/K5R3KnvPuhpcGpKL6jlRf Q7cBtDHAqwFi7zlq45haTB2WaR/PNosVunHFxObtO+F85iukr5zhN0h9OmLomSsu3oWg XZp4pCAOvH+EYzpkcBjD6kokgkd1KSkxfOSjEHyJGskFKv0/7rJmDB4l/2RRDZZPKfgS bAIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710490296; x=1711095096; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=s/GjHxvspqde5PDmyzE58y/UK2LQWPcFmtqDdmYzTvY=; b=Po3a+/zsgxzC9AX0uDxhoxbWy1p24wJZk818U6G/irh+SQk0/sVNo8ZDOtRq1Uk22E 8UBMDAvZnQ+KHQNXeE+lR7MR4fwTMpWtNVg16RGo4QvCJBzZoIJ3LE/FU8sAs55RcB3i bLYc0lJjaSgvH5EDEoq2f5ytrYhnbhTHJR9MU1ImfJgZxp1ZTKOEZY5WIk4uEISoBBcx lTFM0+rNO1qJQ96XkIHD+SoWRIB60CQlqwc7lrAsw7dM1dfFLOocyjfqkWMKePKuFT4h xI6Tus8oZmJ8BbkTmWHVFh8zxSCpVv4qHbNCdTTp30r71KuTt8iERN9/8rvKhILjgHdA sVfg== X-Forwarded-Encrypted: i=1; AJvYcCUpo9eE0prYrgZMYbq4RhBs49II7FXDnIRmqSB0UBWuXi2p4PDPIaQclemfBMdocSURN/mQxOo0Bn+EvOeYdbQWEGEkhAiFttLvkBsgReCBCVeP0ts= X-Gm-Message-State: AOJu0YzpmsTpiQf3O+m1VfHfmZ3hI1HkWlmsaLK8U0nkIFp3Gkls7ihY lsgRhI+2exaXNb+DXO686gYyOYdB6i369RM3IZDkZxipSND12UC2mb0mCaUBP7A= X-Google-Smtp-Source: AGHT+IHkkLwS46uOPoHgx+M42KZhCd2StM3WX/KkNEtooUlZc+lcqKpZL+XZ9e/wUMtsDkqtuWHieg== X-Received: by 2002:a17:906:c144:b0:a46:9395:818e with SMTP id dp4-20020a170906c14400b00a469395818emr156069ejc.68.1710490296654; Fri, 15 Mar 2024 01:11:36 -0700 (PDT) Received: from localhost (cst2-173-16.cust.vodafone.cz. [31.30.173.16]) by smtp.gmail.com with ESMTPSA id h11-20020a1709062dcb00b00a433f470cf1sm1467996eji.138.2024.03.15.01.11.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Mar 2024 01:11:36 -0700 (PDT) Date: Fri, 15 Mar 2024 09:11:35 +0100 From: Andrew Jones To: Inochi Amaoto Cc: Conor Dooley , Qingfang Deng , Paul Walmsley , Palmer Dabbelt , Albert Ou , Atish Patra , Anup Patel , Will Deacon , Mark Rutland , Conor Dooley , Heiko Stuebner , Guo Ren , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] perf: RISC-V: fix IRQ detection on T-Head C908 Message-ID: <20240315-73aa13079ef83a4559869084@orel> References: <20240311063018.1886757-1-dqfext@gmail.com> <20240312-evil-resource-66370b68b9b4@spud> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240315_011138_886690_E1A6DE09 X-CRM114-Status: GOOD ( 20.94 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Mar 13, 2024 at 09:31:26AM +0800, Inochi Amaoto wrote: ... > IMHO, it may be better to use a new DT property like "riscv,cpu-errata" or > ",cpu-errata". It can achieve almost everything like using pseudo > isa. And the only cost I think is a small amount code to parse this. > What's the ACPI equivalent for this new DT property? If there isn't one, then the cost is also to introduce something to the ACPI spec and add the ACPI parsing code. I'd much rather we call specified behaviors "extensions", whether they are vendor-specific or RVI standard, and then treat all extensions the same way in hardware descriptions and Linux. It'd also be best if errata in extension implementations were handled by replacing the extension in the hardware description with a new name which is specifically for the behavior Linux should expect. (Just because two extensions are almost the same doesn't mean we should say we have one and then have some second mechanism to say, "well, not really, instead of that, it's this". It's cleaner to just remove the extension it doesn't properly implement from its hardware description and create a name for the behavior it does have.) Errata in behaviors which don't have extension names (are hopefully few) and are where mvendorid and friends would need to be checked, but then why not create a pseudo extension name, as Conor suggests, so the rest of Linux code can manage errata the same way it manages every other behavior? The growth rate of the ISA bitmap is worth thinking about, though, since we have several copies of it (at least one "all harts" bitmap, one bitmap for each hart, another one for each vcpu, and then there's nested virt...) We don't have enough extensions to worry about it now, but we can eventually try partitioning, using common maps for common bits, not storing bits which can be inferred from other bits, etc. Thanks, drew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel