From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-178.mta0.migadu.com [91.218.175.178]) (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 B76133D3D11 for ; Tue, 22 Sep 2026 08:06:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790064430; cv=none; b=jsMlvZed0D1WH7FW7G5X0TWaw1M2Q3V6IsZLwMRuayfssXj8hl/OCVIrxPkYR9xyNTq3Fg4AJwcLmktpN+f+FqLBll9RqB6WAELjMaKJIeTyb4ID5I44H7sxFL88fwKsNpT4qnNVjXgfa+u8ClGb0ONcz6aX5/CKVPOxaQoRv68= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790064430; c=relaxed/simple; bh=cB4FZPFGZEQzYGYS86n3W200daWOvuyV72CbgzKsGHs=; h=Mime-Version:Content-Type:Date:Message-Id:From:To:Cc:Subject: In-Reply-To:References; b=t67r1ugdV2E8hnM4i0sCHKDzT7JBdOfJhrX50H8wlMzN4TL953Uyz8UGaNPU6/lT2cRbNyueLpqF0vbsfeak2rjeGEPPeG+FWNENLeHK0VZ2CMl3Y/bGnQj9Hw5d+bHXCdj8Y+vXvWuYQy7ZmHHW0898xP9s+DZzPNs2yqRXzEE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=Lvf9EUVm; arc=none smtp.client-ip=91.218.175.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="Lvf9EUVm" X-Envelope-To: devicetree@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=cB4FZPFGZEQzYGYS86n3W200daWOvuyV72CbgzKsGHs=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1790064415; v=1; x=1790669215; b=Lvf9EUVmJhdRZQobQnfL0Rkgf4hnI5XohrOcCJbxr3bYMcUxXocm+zICEyADiWWJICZYnpcc t+DfaU8uJP/oIdb9FQJzIoELY3aURKIi2NEu9hASzWjqRXz079D5QULozg59Glblsfx5wtqEybb ZvlxYpHK12DA6kNqK1pVfESo= X-Envelope-To: devicetree@vger.kernel.org Received: by mta12.migadu.com with ESMTPS id 426168b88e5d5557; Tue, 22 Sep 2026 08:06:55 +0000 X-Mizu-Trace-ID: 426168b88e5d5557 X-Migadu-Flow: FLOW_OUT Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: multipart/signed; boundary=2e2b99b56de2a9e6360ff5979e30d653e8172a1b1e603da005f3ee51c34d; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Tue, 22 Sep 2026 16:06:50 +0800 Message-Id: From: "Troy Mitchell" To: "Sudeep Holla" , "Greg Kroah-Hartman" , "Rafael J. Wysocki" , "Danilo Krummrich" , "Paul Walmsley" , "Palmer Dabbelt" , "Albert Ou" , "Alexandre Ghiti" Cc: "Catalin Marinas" , "Will Deacon" , "Mark Rutland" , "Rob Herring" , "Krzysztof Kozlowski" , "Conor Dooley" , , , , , , "Troy Mitchell" Subject: Re: [PATCH RFC 2/3] arch_topology: Parse die nodes in /cpu-map In-Reply-To: <20260921-rational-frisky-jerboa-0f2ff0@sudeepholla> References: <20260920-riscv-die-topology-rfc-v1-0-071c0bf61d5f@linux.dev> <20260920-riscv-die-topology-rfc-v1-2-071c0bf61d5f@linux.dev> <20260921-rational-frisky-jerboa-0f2ff0@sudeepholla> Content-Transfer-Encoding: 7bit --2e2b99b56de2a9e6360ff5979e30d653e8172a1b1e603da005f3ee51c34d Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 > Where is the associated bindings ? Am I missing to check it in the series > or it is really missing ? It is essential to add any code using the bindi= ng. I left the binding out to get initial feedback on the topology model, but I agree it should be available for review alongside the code. The cpu-map binding lives in dt-schema. I have now opened a draft PR [1] with the proposed dieN hierarchy. The PR also links back to this kernel series. > Also how does it align with ACPI implementation ? It is preferred to be > in parity here, so we need some binding there as well IMHO. This series does not implement ACPI die discovery and leaves die_id at -1 on that path. I agree that DT and ACPI should describe the same topology model. RISC-V does not define topology fields in hart IDs. PPTT can describe intermediate processor hierarchy nodes, but I could not find an explicit die indicator in the ACPI 6.6 processor-node flags. Is there an existing PPTT convention for identifying die boundaries that we should follow? Would it be acceptable to add DT support first, keeping ACPI die IDs unknown until that mapping is agreed, or should the ACPI mapping be defined as part of this RFC? Link: https://github.com/devicetree-org/dt-schema/pull/208 [1]. --=20 Troy Mitchell --2e2b99b56de2a9e6360ff5979e30d653e8172a1b1e603da005f3ee51c34d Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iJcEABYKAD8WIQSL4Ay2cExaPXAQcU2YCe+A+TM0LwUCarI3GiEcdHJveS5taXRj aGVsbEBsaW51eC5zcGFjZW1pdC5jb20ACgkQmAnvgPkzNC/dtgEAw8G9zoZFaHkE oAhSnQKlX8ec/LwA/1LdZjuOaqjDmOsBAIqD7X1Vd3GQdkDDrnwDkXKuMRP0FRGz 9ZibisfJBz8N =lRK8 -----END PGP SIGNATURE----- --2e2b99b56de2a9e6360ff5979e30d653e8172a1b1e603da005f3ee51c34d--