From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 72AEB2F0C45 for ; Wed, 3 Jun 2026 12:32:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780489964; cv=none; b=lyrWTg2jr+Z6H/zxeLWAedhOwRKAqJMi6ts8Cys4KWLxcU+Y3+Nhc2BjJAynmM6ZbUowHjOCvI+gL33TBGKKHJOVoy8LEQ8k1cwfqqeV29zdWjK/c9rpRrORO9a45nY6nHF8Yk9Zu85Xu43rsUGmFZS06xJr2V1s7aiFRnXh2xU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780489964; c=relaxed/simple; bh=LVEYCrAWbx20tY29qGmF9KVkTRBrzHo0yDwAYASBSU0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=VKj5WOsiRcOH9pBHOqVpr+fG4481+Ow1mfEgoPfDwiRlS66k0Bz0YVYBm2BAeNBoK01YPRHNaUzDTVr15zN9dD2wIn9X4UJx/WgsWeLJ06uDx8bLhbkcssV80zMrniXRtHbYbgM2nlfz5fENWqV80JAcdi2Lwu8M6YhzXgPu8Jw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=PaYP3IZJ; arc=none smtp.client-ip=209.85.214.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="PaYP3IZJ" Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-2c0c2c7d45eso34228815ad.1 for ; Wed, 03 Jun 2026 05:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1780489961; x=1781094761; darn=vger.kernel.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=hDeuMdiaAlzBD3KH8UwifnbgyrvnQwNbJEPlcUd8KQc=; b=PaYP3IZJ/UlYTE8BEOEbguTtz2OVBo05ZHPjdQw6K95fCNuO2xo7dZm11UK5z+9D5E jTkTmnJWGhdUWH1uk5EkclpbFQ++fFnINHO7/Y7+yhZ1XmJL3LyXoZcMhi48ubqe1c97 Ccvf0KCerokJKSB+PF8jC4rWMj+bxqMkCZGcRVuYMiJ+TpOT3pjsBHxCPr8qQdPGdODn aqus0SQkwQ7EKFXGofU7H2iYB3Me6/YbqnmfdDGLtD8/vV8XjVMB4P2pNElrsz3r0s61 Vk5yUNsWI42Y5tiGQFmZ7MmefqEMRF17f512G0efx93sGYNbwd6zvsYkDZ3rT+i0Iix8 P+zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780489961; x=1781094761; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=hDeuMdiaAlzBD3KH8UwifnbgyrvnQwNbJEPlcUd8KQc=; b=JdxtVfnFlqWtsbNj06ONFfIqRu78y8NPhwhFS0c+BHorqdhr6UeERA+d0fpIcQGTY6 P+u6FiMdFu2sGYFf/exi+7npOOEeTUjWpRtz5xbJskC3hD14Qdb/3SOQ9RqHffak+thu PpAYuP3r7AAfIcqfOFnQG4NJCjZrnjc3XdihVt3hvBkyXNIh78UbLUn1gvGFhLNZsIMO U0xSzzB1HTm+Cwsg82VWCq9vnvSd00oDNiRp8KSq5HZ9NWXSvyY4oDQuJhBFItHeiRtQ EWalVRzU7xGQvsekwXb/VFX4Yhd1SCKHzXP2Vlo+yEEVydyt/ni54SKxgJ7Ql0AMuUCQ UQpA== X-Forwarded-Encrypted: i=1; AFNElJ9VZciqoImOPWG2Tx/uRZGwq4+a6BZCsTvqIHSs2Ibo70YoIhFIv6tDZjcCfcvO0gFEvCSi2+62O5DCnOM=@vger.kernel.org X-Gm-Message-State: AOJu0YwrO9vAOm3TyQlG0Smna1yKXQNYzesCzlgq1cz2y/1aRO72qZ8D tPNqtzUOpbaK7hkh+WM+pt6XUNIWval9LMA5JrOUEMBdCXwUvfHpzoaPmKiC2vswD3s= X-Gm-Gg: Acq92OEzHGIxY77rpScOWevguME0wVlvGOFu0l6GL+2zR7OzBPLNrnHWkjanZd2YH4k RDvNbo2e4KxS08di07lJNVbWYrEv7BJXhDuq3jenO5jyupyyGShx9xM9CofmCV81NKqF+wQTypS c7ASIYG7AtzW6LK4TVQC5/nBT8NaD6TtDkjOhISbi1hk/suYWC0psL9HYMUiJaQHw/Cnw3kjBFR GoV+1n6B6PPVl+12OLY/USxIf755fawT1ld9lH0QdGQxwj5xsuaTap7l13QJTLshjAQrS/95N+1 DICyk51Zams3xcOn5FVxNrjq6bjnJjy1GtOIFJNOKP2/Yl5CEvri57yvq9N4KYoG5sRT5MTr3lE aKv+23bLR5QCbNK/fCR4935gD5rlrGw2GR/gOkaXDx0rKBnxaQCE39bPvrvrZo8dLiHBIL3YOpv +bDzKyqlelXjXc3AzU+ZY3/Bp4/NON3bTjIkCm1hr27P+rgw== X-Received: by 2002:a17:903:2c47:b0:2b9:7ad1:bf2b with SMTP id d9443c01a7336-2c1640ac13emr35790755ad.29.1780489961586; Wed, 03 Jun 2026 05:32:41 -0700 (PDT) Received: from smtpclient.apple ([240e:694:e20:401::4]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2c164fa0236sm24929025ad.33.2026.06.03.05.32.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jun 2026 05:32:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.300.41.1.7\)) Subject: Re: [PATCH v1] riscv: cpufeature: Add Zic64b ISA extension support From: Qingwei Hu In-Reply-To: <20260530-spoils-studied-d0858257c982@spud> Date: Wed, 3 Jun 2026 20:32:14 +0800 Cc: Vivian Wang , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Deepak Gupta , Pincheng Wang , Chunyan Zhang , Hui Wang , =?utf-8?B?Q2zDqW1lbnQgTMOpZ2Vy?= , Xu Lu , Guodong Xu Content-Transfer-Encoding: 7bit Message-Id: <68DF4B69-6693-447A-ADAC-E943F96CFB77@bytedance.com> References: <20260528141630.2741710-1-qingwei.hu@bytedance.com> <302dfaf7-4a38-408f-997e-68ed27de2341@iscas.ac.cn> <752F28EA-9255-4DBE-8007-F57947305D71@bytedance.com> <20260530-spoils-studied-d0858257c982@spud> To: Conor Dooley X-Mailer: Apple Mail (2.3864.300.41.1.7) > On May 31, 2026, at 07:09, Conor Dooley wrote: > > On Sat, May 30, 2026 at 11:36:11AM +0800, Qingwei Hu wrote: >> Hi Vivian, >> >> Thanks for the feedback. >> >>> On May 29, 2026, at 11:14, Vivian Wang wrote: >>> >>> On 5/28/26 22:16, Qingwei Hu wrote: >>>> Zic64b describes a platform with 64-byte cache block sizes. It is a >>>> mandatory part of RVA23U64, but a system may provide 64-byte CMO block >>>> sizes without satisfying all profile requirements. >>>> >>>> The ISA string parser currently ignores Zic64b because the extension is >>>> not present in the cpufeature table. Add an ISA extension ID and table >>>> entry for Zic64b so it can be reported in /proc/cpuinfo when firmware >>>> advertises it. >>> >>> I'd like to understand: What is the motivation to doing this, given that >>> the very same information is already available as riscv,cbo*-block-size >>> and hwprobe? >> >> The motivation here is not to replace riscv,cbo*-block-size or hwprobe. >> Those are still the right interfaces for software that needs the actual >> CBO block size. >> >> This is more about preserving the ISA extension name reported by >> firmware. Some platforms report zic64b in the ISA string, but Linux >> currently drops it because there is no cpufeature entry, so cpuinfo no >> longer matches what firmware advertised. That makes profile/ISA-string >> comparison tools a bit awkward. >> >> So the patch only makes zic64b visible as a named ISA extension when >> firmware reports it, while still validating it against any CBO block >> sizes that firmware provides. >> >>> If an extension is what we want to go with, then >>> Documentation/devicetree/bindings/riscv/extensions.yaml also needs >>> updating to match. >> >> And yes, if we keep this direction, I agree extensions.yaml should be >> updated in v2. > > And make sure that having zic64b makes the cbo*-block-size properties > mandatory so that people don't confuse themselves and omit them and > wonder why stuff doesn't work. > > Does zic64b mean that all of the zicbo* extensions are supported, or > does it just mean that the supported ones use 64-byte block sizes? > The answer to that will impact how you make the cbo*-block-size > properties mandatory. > > Cheers, > Conor. Thanks, I will check this with the RISC-V unprivileged/ISA folks first, and then handle the binding accordingly in v2.