From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oa1-f66.google.com (mail-oa1-f66.google.com [209.85.160.66]) (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 CB618319875 for ; Thu, 8 Jan 2026 19:23:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.66 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767900221; cv=none; b=PyZ7VPesOLsEyF58MYtWKsqd67NmXAMkHJazdE7uY9N1UXW5YSeijj2YaCulkM6TvGEfIvzTpR8FIf7c8+zvpmR4ddQetgpBtbqG5VEUqBB1WSoCKs4RIo2A/FUM+O6exWJWO9Qq3SPgQIeIJJg67oEi9W7cx0QrqXtV9eAPNok= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767900221; c=relaxed/simple; bh=rQuCPnYPLg4Ui2a0ObeA7TCLE/RLxICLMmiEBGi0cLE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=M/V08qJq9vHLC6AGaPUTOm1j5O2BJel0B4U1K4mCot1FhEmemfew1U5cNkQT2babhHB+D0492nqdp58BAjK3rPDdjHrZvOdLjH0TakeGCTrdFEd6Qfr5I+BHIyOD/JW87JuwCoRY+Sas7nbzp5Qlk5/CEq9vNtnyB14Zj4aseuM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=sifive.com; spf=pass smtp.mailfrom=sifive.com; dkim=pass (2048-bit key) header.d=sifive.com header.i=@sifive.com header.b=mbTe6U7i; arc=none smtp.client-ip=209.85.160.66 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=sifive.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sifive.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=sifive.com header.i=@sifive.com header.b="mbTe6U7i" Received: by mail-oa1-f66.google.com with SMTP id 586e51a60fabf-3e3dac349easo3145508fac.2 for ; Thu, 08 Jan 2026 11:23:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1767900215; x=1768505015; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Hjqd0wbUL/0gATLT7Jr3bq/fYYzs5CcoqUGsadwzmFw=; b=mbTe6U7i2ohQaLiGP4AJMR2slaLEUYJYOOFgiI2EgQIi2pbFpQrGe4XUGLYmFqgHsk brk4vS927Z1lDWdEYlahWkHycmYrbsq9K5n+2wr4zt88WYQK4yNSSQxoWeYR6Ig9hRZJ k4zwlI2cJ96wWmoZ2I9qBw9zDXMVZM6gRFBOLfOIFgE4a2Uh7CUOQSOTvo2+wOVQl43c MLrfvFGhRBJRj6rRO7B11zsEkxW1eU05hICE6RTVH+UyXMOqqqncGVhdQLdEGl/LWYr/ MGIJuVWkraLtLahbvfdTiGzOA1TcTdidS1XFU3rxUAinEPAw08R4OXObSQ8o2R1i10EP qBdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767900215; x=1768505015; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Hjqd0wbUL/0gATLT7Jr3bq/fYYzs5CcoqUGsadwzmFw=; b=FxMU+ZPP7w3/j4a/nv5w6VmT3Lsc9HB8Uazh/xr8zRWidUgNfPcC7zqkkrqPP8Ikkb JQoOHpZHChZu1p/6oLOG7CXRH9iEsnXCqI8+nSOZgWLaWQTr7Ge7ZC40siRP8LLhiETD iXxm6bSJnS5ORh4ZRUJANU8kw5ZbFVF5MvYvmSo7udBk+mD6KtKn0yEYPblz1McknK19 VKjXiT0e8QrSGRZkzN8oFDR8wEocG0kMBjQmWIcxaGIehUq5HyVakSzopuPlxAjQVkmb iR3QuATzTozo4vgB5cHhJIUdNBP6db0vEG6Fg7fml7/dkkIRfQKECqBJMqE3miQ9DhTF pjrg== X-Forwarded-Encrypted: i=1; AJvYcCUEcpbARdOJFxGbQBDo3KhPM2q9FrjKGUUpKlycdJfG2biqmIon3ier7zhQTdGLPDzZ5HGWmbBGm9K/Il4=@vger.kernel.org X-Gm-Message-State: AOJu0YwknoLsihvOo+ZGsIMbc4tj1vUN4fTfj0KNqAM/P1Rm7PnwG+8V jx2pYjt5B8J0SkyY3gtk8WHhTw3ogHYP5nXz/z9Rj0Fybf/kdzXTvQnu/5OKnQf/SwI= X-Gm-Gg: AY/fxX61eH3qQ+qoSEkD4UH6j4bAPs1XZz0bNCJvZgvchX6WRUkip0EwXqcDq6n4kSy IW7n6iAkqdHu7utSqr7peKxCR0ZiUP80o6AEpblAt1B/tN/pMRCFysmItOGeDpTlYPm/FGtoHeF nZcirlkstEgcyHcpTy1yAMqDY0O0FVGMGDUxV4EZRLNtwx1KfRw9r8HZm95+9C92eZJPB6QpJs+ krt5bmj/GbM98w77vIKh+68rNyiRyjsCqk7XplUv6hnOiUF/b2m7cfC4eCxfo6qDfNFigp5SzDW KhaoRuaJrAkyMqpqbmrhy/uUYvEruU5anhXf5459XfLxuw/lIQzzWgLcGBdWzKgYYmJcLUDzOxu AICQQwLNRIvbd42PGF9KqCyJqkbJXB4vuS542eK/Tcug94tCWLjJM31752Ffc/q8FuhHeHLYYs7 mFiPPB7oxYqRUi7X4PF8MR2eyWK+I= X-Google-Smtp-Source: AGHT+IHKLUgghrPd29RErvBws0kQ87awrcNfi7vgU0Zf7ngrlTJY/amh5n0uvlMoYU4vmYrjhXLVGQ== X-Received: by 2002:a05:6870:c243:b0:3e8:95d2:389d with SMTP id 586e51a60fabf-3ffc0c02c95mr3135629fac.43.1767900214837; Thu, 08 Jan 2026 11:23:34 -0800 (PST) Received: from [100.64.0.1] ([170.85.11.86]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-3ffa4de40bfsm5357385fac.5.2026.01.08.11.23.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jan 2026 11:23:34 -0800 (PST) Message-ID: <9504b2f6-12f5-46c2-ac74-826dba3fb530@sifive.com> Date: Thu, 8 Jan 2026 13:23:32 -0600 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 7/8] riscv: dts: spacemit: add initial device tree of SpacemiT K3 SoC To: Conor Dooley , Heinrich Schuchardt Cc: Guodong Xu , Paul Walmsley , Palmer Dabbelt , Kevin Meng Zhang , devicetree@vger.kernel.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, spacemit@lists.linux.dev, linux-serial@vger.kernel.org, Rob Herring , Krzysztof Kozlowski , Conor Dooley , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Yixun Lan , Daniel Lezcano , Thomas Gleixner , Anup Patel , Greg Kroah-Hartman , Jiri Slaby , Lubomir Rintel , Yangyu Chen References: <20251216-k3-basic-dt-v1-0-a0d256c9dc92@riscstar.com> <20251216-k3-basic-dt-v1-7-a0d256c9dc92@riscstar.com> <60948ca2-ed3d-485b-9b11-15df7ef8791d@canonical.com> <20251218-basil-quantum-225ce16e4699@spud> <20251220-repacking-football-c79e660e788a@spud> <4e4c9e7b-d95c-4157-94c3-b06002f94a48@canonical.com> <20251222-dimmer-wooing-db29fe925498@spud> From: Samuel Holland Content-Language: en-US In-Reply-To: <20251222-dimmer-wooing-db29fe925498@spud> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi all, Sorry, I wasn't following this thread. On 2025-12-22 2:36 PM, Conor Dooley wrote: > On Sun, Dec 21, 2025 at 01:10:15AM +0100, Heinrich Schuchardt wrote: >> On 12/21/25 00:23, Conor Dooley wrote: >>> On Fri, Dec 19, 2025 at 10:03:24AM +0800, Guodong Xu wrote: >>>> Hi, Conor and Heinrich >>>> >>>> On Thu, Dec 18, 2025 at 8:56 AM Conor Dooley wrote: >>>>> >>>>> On Wed, Dec 17, 2025 at 09:07:14AM +0100, Heinrich Schuchardt wrote: >>>>>> On 12/17/25 08:11, Guodong Xu wrote: >>>>> >>>>>>> Specifically, I must adhere to >>>>>>> Documentation/devicetree/bindings/riscv/extensions.yaml (and cpus.yaml for >>>>>>> properties like 'riscv,sv39' which stands for the extension Sv39). If I >>>>>>> add extension strings that are not yet defined in these schemas, such as >>>>>>> supm, running 'make dtbs_check W=3' fails with: 'supm' is not one of >>>>>>> ['i', 'm', 'a', ...], followed by "Unevaluated properties are not allowed." >>>>>> >>>>>> If Documentation/devicetree/bindings/riscv/extensions.yaml is incomplete >>>>>> with respect to ratified extensions, I guess the right approach is to amend >>>>>> it and not to curtail the CPU description. >>>>> >>>>> Absolutely. If the cpu supports something that is not documented, then >>>>> please document it rather than omit from the devicetree. >>>> >>>> Thanks for the review. May I clarify one thing? Both of you mentioned >>>> document them, given the amount of missing extensions, is it acceptable if >>>> I submit a prerequisite patch that only documents these strings in >>>> riscv/extensions.yaml plus the necessary hwprobe export? Leaving the actual >>>> usage of these extensions (named features) to the future patches. >>>> >>>> To provide some context on why I ask: I've investigated the commits & lkml >>>> history of RISC-V extensions since v6.5, and I summarized the current status >>>> regarding the RVA23 profile here: >>>> [1] status in v6.18 (inc. v6.19-rc1): >>>> https://docularxu.github.io/rva23/linux-kernel-coverage.html >>>> [2] support evolution since v6.5: >>>> https://docularxu.github.io/rva23/rva23-kernel-support-evolution.html >>>> >>>> Strictly describing the SpacemiT X100/K3 (or any core) as RVA23-compliant >>>> requires adding these extensions that are currently missing from >>>> the kernel bindings: >>>> RVA23U64: Ziccif, Ziccamoa, Zicclsm, Za64rs >>>> RVA23S64: Ss1p13, Ssccptr, Sstvecd, Sstvala, Sscounterenw, Ssu64xl, >>>> Sha, Shcounterenw, Shvstvala, Shtvala, Shvstvecd, Shvsatpa, Shgatpa >>> >>> >>>> Plus 'Supm', 'Zic64b', 'Ssstateen', 'B' where the kernel supports them but >>>> they are not literally documented in yaml. >>> >>> I don't think Supm is suitable for devicetree, doesn't it describe >>> what the kernel/userspace are capable of rather than hardware? >>> Zic64b doesn't sound like hardware description (so not really suitable >>> for devicetree either) but block size information is already represented >>> by some existing properties (see riscv,cbo*-block-size in riscv/cpus.yaml) >>> and duplicating that information is not really a great idea. >>> >>> I'll admit that I do not really understand Sxstateen and how they work, >>> but my understanding was that knowing about Smstateen is sufficient and >>> implied Sstateen, but having Ssstateen defined seems harmless and >>> possible. I think kvm is the only user of this at the moment, so >>> probably worth CCing Anup and maybe Drew Jones on the patch adding >>> Ssstateen to make sure it makes sense. >> >> Supm is described in >> >> RISC-V Pointer Masking >> Version 1.0, 10/2024: Ratified >> https://raw.githubusercontent.com/riscv/riscv-j-extension/master/zjpm-spec.pdf >> >> The interpretation taken by QEMU has been: >> >> * Supm implies Ssnpm and Smnpm This is not correct for system emulation. Supm (pointer masking visible in the U-mode execution environment) requires exactly (S ? Ssnpm : Smnpm), not both of them. >> * RVA23 capable machine models display it in the device-tree This is also not correct for system emulation. It is impossible for QEMU to know if pointer masking is visible to the U-mode execution environment, because QEMU does not provide the U-mode execution environment. Software inside the VM does. >> If Supm is not shown in the device-tree, software might assume that the >> system does not support pointer masking in user mode and is not RVA23 >> compliant. Software shouldn't be looking for Supm in the devicetree, because the devicetree does not describe the properties of the U-mode execution environment. >> Hence I would suggest: >> >> If the X100 cores have Ssnpm and Smnpm, add Supm to the device-tree. >> >> If the kernel does not support user space pointer masking, the kernel should >> filter out Supm and not announce it, neither in /proc/cpuinfo nor via >> hwprobe. > > Samuel seems to have some specific thoughts on how this works, given he > didn't blindly implement ssnpm and smnpm, but has made supm be mode > dependent and not permitted in dt, hopefully he sees this. > > Personally I'm not convinced that putting supm in dt makes sense, but > instead the kernel should imply it if the sxnpm extension matching the > mode the kernel is operating in is present and RISCV_ISA_SUPM is set in > Kconfig. That's effectively how it works at present, except it'd involve > promoting RISCV_ISA_SUPM to a "real" extension instead of being a macro. > A validate callback should easily be able to handle checking the > mode and whether the Kconfig option is set. > That way it would get exposed to userspace using the actual mechanisms, > reading the devicetree itself from userspace is not a valid way of > checking what extensions are usable after all. We already do this for hwprobe(), so the only difference is that Supm would be added to /proc/cpuinfo. I don't think I have a problem with this. Regards, Samuel