From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oa1-f47.google.com (mail-oa1-f47.google.com [209.85.160.47]) (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 9509F354AF9 for ; Wed, 14 Jan 2026 23:57:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768435029; cv=none; b=NZDEYc0i3pskC1sey3excXNlTns3ad7MoLf8FLKQ+SvSBVgricp6ZXp7K4I08yi4ohdLscxtyTCjRSiqvvMOXnzYsUj2HWfkib4ypCGToKztm99jp05VgdOUf9nvL1OFQLI2tr3h2D4DzUpiL9qcJBydGmAMK0UkuWNflSQ6ZXs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768435029; c=relaxed/simple; bh=HDziqQp0ZHq73qfDA8T8c1LSXjVu6KKuZcSbqhyXZsk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=e7z+YqTah0pB24rt6IwdL6p4zT/8h8eMuxk09C5RL3Blaxybns0iNvRibgu1FrAIdFad/PLFsjs/fXZoniZPzSK4ccQqFnRSMaUy3em3fXNZSSyaFekJHNN62xeTAH65Jv5L5pnQ5SM+oHISA7WAGHvBtil2GxBFNKttqVEtqww= 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=mw+XGQ96; arc=none smtp.client-ip=209.85.160.47 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="mw+XGQ96" Received: by mail-oa1-f47.google.com with SMTP id 586e51a60fabf-4041b3c1fa1so142800fac.3 for ; Wed, 14 Jan 2026 15:57:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1768435026; x=1769039826; 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=lrZ0xz6rtJrpX2gJTATZXWCSjCkVy/ptUp7g0PyWV/k=; b=mw+XGQ96V1W6i5Fis6GP34a5P2UqxfwqhEWpw16B9pk3SHGCTfbZwAM8msON/4NyRy 27wIuSu+IbN1RMsQrEI0Znanp2UXOjYLlTXWv6KEhvpqQ1eKrbazy8Jpb9uE7gMBc8a4 c5Ylk48ZSPOA/l08LUhuxdviCAKe/nTYXUcvV3feBt2ubTeaFKVG6Dub7vIUWp0f7rx7 1KCIT0wNJWKHXOg+khCTe0XXSUk1/A/NguVFTuk2PZYU7at3v7EaSMSgZRGREyb3GIu8 562RVx3o2WDTqaf+YImfijvtZPFZuKW+gK646lD1f/6+4X2bw4hKznMIeWTHH56BgdL1 XJFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768435026; x=1769039826; 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=lrZ0xz6rtJrpX2gJTATZXWCSjCkVy/ptUp7g0PyWV/k=; b=QpAypj1fZPDJ4cZJpP9ZMFYQjT+dFxnAC32DFbAyPs7dgoae5FxiyqKYz2LbDZDncJ JgrhYEbEodhfOcMIvpBeotPHQPFN8uMFO0tVTZXBQXkO43cQq3zPvZkLZKkzW+FcAF4u 23it4tq7DLtYmR1EnvMEpuDQ8U2/5+Y+Pc+KdBY0Ev3y2dSSEFZmjetyruyi5tvnPWaL /c0IVeVk5NlfCE5/Je2YHCHJt7ryDGmi55fJ66dtuWLr6DqxqcjIMFPp2oI+plLmBkdJ clfESeWIYIspwTHWCEPFAUdbYdHVxqlvMLC38LxyMW8/+wsI9dx6CZGkQy6yUUJdwD4a dj4g== X-Forwarded-Encrypted: i=1; AJvYcCUWiwwLtb1UDilGAH/38tIZUwzlYJs3o7ozRfaxxpE249u0bLQXL4D4p4pbIqS4zo8awA47+7sUROT46r4=@vger.kernel.org X-Gm-Message-State: AOJu0YyMl67V3tV6hn1Kjh0ip/bhT2sxRv0giDz7rUEQhGUGEqyo18Q7 y/Ql8KtxvFc6fFFIU58QX2unGzkxVkXN5d2jB9+24ATLS6vBcjs9PJnAVOYnKbj6Ub0= X-Gm-Gg: AY/fxX5SdDDnIirnYJJ43K0KpnUOMsPn5E0P2QES4T29n0MDjqTQvqrKe3Zyt6y+s/x gwKAmPHqof8AUYS9kEulrMefWpOvIVqagiUo9ik7EWCw26ZOWiu2k6qgV4kzPF4NDZEfyUqM3yZ wnyLHkOsjERzzJTTxbHe576FWU1wOP7TVfErYtlGyD5oZYiJBkqtKM84zDVlwLB77sHB7IuFCno Y9JvF2NNWMZMT5tn9EUkyldztjh6i8RaQsoDmwYtsvm8FS0yktQf9JH6fqOd0YXbm5aMKpeS1Pd vE76UwboIOgVbmZtE4BdumrChCLSKoi5xF8h4kNLB4gVYtGJxi0jYwVyXRNfs6OBcpohWvPnFLp dEyAiY/rXvThxzivIrxEl4rEGHyLKx7ifItR69gFmD9V9LA+GnSZbemMhN9RQ6DM9se0jp7JKNc woxZIf7unkBEXgvE2hTq9+5REVZQJw X-Received: by 2002:a05:6871:3393:b0:404:2fe7:e184 with SMTP id 586e51a60fabf-4042fe7e4b3mr317528fac.43.1768435026295; Wed, 14 Jan 2026 15:57:06 -0800 (PST) Received: from [100.64.0.1] ([170.85.11.118]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-3ffa515f4dasm17826541fac.21.2026.01.14.15.57.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 15:57:05 -0800 (PST) Message-ID: Date: Wed, 14 Jan 2026 17:57:04 -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 v3 10/11] riscv: dts: spacemit: add initial device tree of SpacemiT K3 SoC To: Guodong Xu Cc: Paul Walmsley , Conor Dooley , Heinrich Schuchardt , Kevin Meng Zhang , Andrew Jones , 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: <20260108-k3-basic-dt-v3-0-ed99eb4c3ad3@riscstar.com> <20260108-k3-basic-dt-v3-10-ed99eb4c3ad3@riscstar.com> <77f9a001-7f0a-4c29-abcb-501e875da117@sifive.com> From: Samuel Holland Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Guodong, On 2026-01-09 3:58 AM, Guodong Xu wrote: > Hi, Samuel > > On Fri, Jan 9, 2026 at 2:19 AM Samuel Holland wrote: >> >> On 2026-01-08 6:26 AM, Guodong Xu wrote: >>> SpacemiT K3 is equipped with 8 X100 cores, which are RVA23 compliant. >>> Add nodes of uarts, timer and interrupt-controllers. >>> >>> Signed-off-by: Guodong Xu >>> --- >>> v3: Remove "supm" from the riscv,isa-extensions list. >>> v2: Remove aliases from k3.dtsi, they should be in board DTS. >>> Updated riscv,isa-extensions with new extensions from the extensions.yaml >>> --- >>> arch/riscv/boot/dts/spacemit/k3.dtsi | 548 +++++++++++++++++++++++++++++++++++ >>> 1 file changed, 548 insertions(+) >>> >>> diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi >>> new file mode 100644 >>> index 0000000000000000000000000000000000000000..be9335fba32cb9e81915b2b91cf08c55a5e96809 >>> --- /dev/null >>> +++ b/arch/riscv/boot/dts/spacemit/k3.dtsi >>> [...] >>> + reg = <0x0 0xe0400000 0x0 0x00200000>; >>> + interrupt-controller; >>> + #interrupt-cells = <0>; >>> + msi-controller; >>> + #msi-cells = <0>; >>> + interrupts-extended = <&cpu0_intc 9>, <&cpu1_intc 9>, >>> + <&cpu2_intc 9>, <&cpu3_intc 9>, >>> + <&cpu4_intc 9>, <&cpu5_intc 9>, >>> + <&cpu6_intc 9>, <&cpu7_intc 9>; >>> + riscv,num-ids = <511>; >>> + riscv,num-guest-ids = <511>; >>> + riscv,hart-index-bits = <4>; >>> + riscv,guest-index-bits = <6>; >>> + }; >>> + >>> + saplic: interrupt-controller@e0804000 { >>> + compatible = "spacemit,k3-aplic", "riscv,aplic"; >>> + reg = <0x0 0xe0804000 0x0 0x4000>; >>> + msi-parent = <&simsic>; >>> + #interrupt-cells = <2>; >>> + interrupt-controller; >>> + riscv,num-sources = <512>; >>> + }; >> >> Does the chip also have M-mode IMSIC and APLIC instances? Those need to be >> represented in the devicetree as well, for M-mode firmware to access them, just >> like the CLINT below. > > Yes, the K3 chip does have M-mode IMSIC and APLIC instances. Currently, the > boot firmware (U-Boot) transfers information about these nodes to OpenSBI. > However, you are correct that they should be properly described in the DT. > > In the next version, I will add the M-mode APLIC (maplic) and IMSIC (mimsic) > nodes to k3.dtsi, for topology representation and potential firmware usage. > I will set their status to "disabled" because exposing them as "okay" to Linux > causes access faults during driver probing. > > Please let me know if this approach (adding them but keeping them disabled) > looks okay to you. I think this is a reasonable compromise. Personally, I think of the DTS files in the Linux repository as the "static" devicetree, which should describe a "complete" view of the hardware--that is, as seen from the highest privilege level. Then it is the responsibility of that highly-privileged software to modify the FDT as needed to provide a limited view of the hardware to lower-privileged software. And this modification is exactly what OpenSBI does before it passes the FDT to U-Boot. So the "static" devicetree would not disable these M-mode-only devices. However, I recognize that people want to use the DTB files generated by the Linux build process with Linux directly, ignoring the firmware-provided FDT. In that cases the M-mode-only devices need to be disabled. And then you need a -u-boot.dtsi file to set `status = "okay"` for the firmware build. I think that's a reasonable compromise to make the "static" devicetree as complete as possible while still being usable directly in S-mode in some cases. (It still breaks if some peripheral is assigned to a different supervisor domain, or some DRAM is reserved by M-mode, etc., which is why I really recommend using the firmware FDT and not a file.) Regards, Samuel