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 003BDC04FFE for ; Tue, 16 Apr 2024 03:34:28 +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=AldA+ApGbEE9bjaw/ZIn+5cDi7Q+lQy9+TjSsmH+0aw=; b=z3zfIj5wz9I1RZ dBTYylYi/zTAiVyCdZGJ5YE5r8JXY8WUjqvfFga5vCnemMrsxITxrk9+nv49lxHspITy0gEgHxSeB hSRCXyQDaP29Af6BqoEOC0uS9peqJGct4VgOGD4zTOqLB/UIIk/zJnnEBuqDoqE0P7Tu0wygF5usB VgUhLnrKeWXLdeay6zI0SHMutU6ULg+TIeUjzp2koK9202uiq3M3PDaGWR1dNphn4Nu7YBLnDjpMZ vwfGnRi7yYgcDtQXmur8+ZJcM/gdqKC/KSaQjw9Ps1HhYAJdT4jRPAvBZN8dDJTq37duadZpwmrTQ oei1HEUqNJEuo50i1CKg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rwZaH-0000000Ag69-2GcF; Tue, 16 Apr 2024 03:34:13 +0000 Received: from mail-pf1-x433.google.com ([2607:f8b0:4864:20::433]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rwZaE-0000000Ag4s-187Y for linux-arm-kernel@lists.infradead.org; Tue, 16 Apr 2024 03:34:11 +0000 Received: by mail-pf1-x433.google.com with SMTP id d2e1a72fcca58-6ecee1f325bso3652517b3a.2 for ; Mon, 15 Apr 2024 20:34:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1713238448; x=1713843248; 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=+EWmrrioxcbdhmgLzVDWs0ZmfxosK3ySncICyoT9RVM=; b=t6xXIrm/gd4jP9vhV3B5tT02l46HhTyzTIG1KIKg6AP3PvRkYC2eBKRUKwA+jRouXe S663zoPnvUnwJ6xadxV4f8ch7bwWoTOCHfzQ1uAerxDxxsuvSn/EojuSCifNHH8dcXfh 2w5dl9G73ylCtnnKxZdmsa8AcnHTKvpY4/D5Q4KkffYuPfwY/Z34FBnPE4qWPxkjJdTG aHHmTXj316Bf8DsEoGVg7VCG/lIBF/WOlD2v8tQQ/+S7nhpnGgcLyUZHymyjmKUXSP8F KPJ5C67kwgThTWIyLBez/2GGJXYND5m2qo+ZEoppUHfkLUXZWcYQc2RBUNSNPGM1D6aC nBVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713238448; x=1713843248; 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=+EWmrrioxcbdhmgLzVDWs0ZmfxosK3ySncICyoT9RVM=; b=H9gmIbkJ+69r67z4PRS94AYEjxwlqjb0jOjQ/FG4/f4Q9VyconZMpJQt1g8T1MAFBc V4ay7EVFwPVKwkXEBIiefZEuItGRPaNkyxkl70VUw9wdgK1ch2znQTAdkCX2TtkMpEKE pVizkJ4Fw/mLvEzBA6Dnf64GUc0JN/k11xfiEBxI5M3qz+A4T+vhmT1yddjyOXXHtvTN E7o3vkje3oCf7A7JqH9gJJMp5UYlon6PQIVGAm2Tt6/Ew8eF+yi98IBBCb9OVbOalWFt OIDulTiOdo/lgVoNmRy295KMGw0wuVVy1bI9VZVIw6QeWfbtJgSblGCdO+cQia31qMhN Bxfw== X-Forwarded-Encrypted: i=1; AJvYcCUifkQF3bbjK7GV7e1me2PuPexwTkdVx22Cqq40JI0uuzdZGRuQ9HjDf7WB+wmJs9dg64DNVT2pPwrTg6d4pJDvCa9lWvn2ucIL187mK81dVZNYvqM= X-Gm-Message-State: AOJu0Yws90COwFe6xDIo8Zb9mAGlO15qda9R7Fp3i1xwooe0RPoWEm1o caFtnxE930EwxffZujyPr7Kuu/q4sbKdW24gDMSM+i5vu3oAy48PWMB8ihs8Ti0= X-Google-Smtp-Source: AGHT+IG9jfOvCmqHl4/Fyo/8q6SyIRFlYI9sihLFkiHMi13PEhJw0HyUWWTm9jC0FXv9X1osScl9nA== X-Received: by 2002:a05:6a21:8889:b0:1a5:bc5d:3c0a with SMTP id tb9-20020a056a21888900b001a5bc5d3c0amr15476979pzc.61.1713238448517; Mon, 15 Apr 2024 20:34:08 -0700 (PDT) Received: from ghost ([2601:647:5700:6860:fd:b04f:bfdd:b666]) by smtp.gmail.com with ESMTPSA id i15-20020a170902c94f00b001e25da6f2f2sm8653509pla.68.2024.04.15.20.34.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Apr 2024 20:34:08 -0700 (PDT) Date: Mon, 15 Apr 2024 20:34:05 -0700 From: Charlie Jenkins To: Conor Dooley Cc: Conor Dooley , Rob Herring , Krzysztof Kozlowski , Paul Walmsley , Palmer Dabbelt , Albert Ou , Guo Ren , Conor Dooley , Chen-Yu Tsai , Jernej Skrabec , Samuel Holland , Evan Green , =?iso-8859-1?Q?Cl=E9ment_L=E9ger?= , Jonathan Corbet , Shuah Khan , linux-riscv@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Palmer Dabbelt , linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH 02/19] riscv: cpufeature: Fix thead vector hwcap removal Message-ID: References: <20240411-dev-charlie-support_thead_vector_6_9-v1-0-4af9815ec746@rivosinc.com> <20240411-dev-charlie-support_thead_vector_6_9-v1-2-4af9815ec746@rivosinc.com> <20240412-tuesday-resident-d9d07e75463c@wendy> <20240412-eastcoast-disparity-9c9e7d178df5@spud> <20240412-chemist-haunt-0a30a8f280ca@spud> <20240413-sharper-unlivable-5a65660b19e2@spud> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240413-sharper-unlivable-5a65660b19e2@spud> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240415_203410_427867_20A4564A X-CRM114-Status: GOOD ( 37.21 ) 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 Sat, Apr 13, 2024 at 12:40:26AM +0100, Conor Dooley wrote: > On Fri, Apr 12, 2024 at 02:31:42PM -0700, Charlie Jenkins wrote: > > On Fri, Apr 12, 2024 at 10:27:47PM +0100, Conor Dooley wrote: > > > On Fri, Apr 12, 2024 at 01:48:46PM -0700, Charlie Jenkins wrote: > > > > On Fri, Apr 12, 2024 at 07:47:48PM +0100, Conor Dooley wrote: > > > > > On Fri, Apr 12, 2024 at 10:12:20AM -0700, Charlie Jenkins wrote: > > > > > > > This is already falling back on the boot CPU, but that is not a solution > > > > > > that scales. Even though all systems currently have homogenous > > > > > > marchid/mvendorid I am hesitant to assert that all systems are > > > > > > homogenous without providing an option to override this. > > > > > > > > > > There are already is an option. Use the non-deprecated property in your > > > > > new system for describing what extesions you support. We don't need to > > > > > add any more properties (for now at least). > > > > > > > > The issue is that it is not possible to know which vendor extensions are > > > > associated with a vendor. That requires a global namespace where each > > > > extension can be looked up in a table. I have opted to have a > > > > vendor-specific namespace so that vendors don't have to worry about > > > > stepping on other vendor's toes (or the other way around). In order to > > > > support that, the vendorid of the hart needs to be known prior. > > > > > > Nah, I think you're mixing up something like hwprobe and having > > > namespaces there with needing namespacing on the devicetree probing side > > > too. You don't need any vendor namespacing, it's perfectly fine (IMO) > > > for a vendor to implement someone else's extension and I think we should > > > allow probing any vendors extension on any CPU. > > > > I am not mixing it up. Sure a vendor can implement somebody else's > > extension, they just need to add it to their namespace too. > > I didn't mean that you were mixing up how your implementation worked, my > point was that you're mixing up the hwprobe stuff which may need > namespacing for $a{b,p}i_reason and probing from DT which does not. > I don't think that the kernel should need to be changed at all if > someone shows up and implements another vendor's extension - we already > have far too many kernel changes required to display support for > extensions and I don't welcome potential for more. Yes I understand where you are coming from. We do not want it to require very many changes to add an extension. With this framework, there are the same number of changes to add a vendor extension as there is to add a standard extension. There is the upfront cost of creating the struct for the first vendor extension from a vendor, but after that the extension only needs to be added to the associated vendor's file (I am extracting this out to a vendor file in the next version). This is also a very easy task since the fields from a different vendor can be copied and adapted. > > Another thing I just thought of was systems where the SoC vendor > implements some extension that gets communicated in the ISA string but > is not the vendor in mvendorid in their various CPUs. I wouldn't want to > see several different entries in structs (or several different hwprobe > keys, but that's another story) for this situation because you're only > allowing probing what's in the struct matching the vendorid. Since the isa string is a per-hart field, the vendor associated with the hart will be used. - Charlie _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel