From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from Atcsqr.andestech.com (60-248-80-70.hinet-ip.hinet.net [60.248.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5D34628314A for ; Wed, 8 Oct 2025 13:35:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=60.248.80.70 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759930563; cv=none; b=gUIUl08zSWq+DFvc62g7mOrbLl1nOMDlsJd3UND0imwzXpdCKbiYV/cUI+ygXu4KxXCLlRh+dgp1oXcxOCUocfHg6TDdoLGDWVv8xYr7+18tvkB5gwQyY9NyWwrwNJku6WsjVWGwGA4Guc8AwvkLk1MQE0UCn906YcKbkr4Eixs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759930563; c=relaxed/simple; bh=2++gi+3fbP2waS3+p89+F+/Sm7MsrHb0KRMpSa7Niw0=; h=Date:From:To:CC:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=aivgK2cXKPrKc8Bczy6U79Too/kSQVGpU4AUxCBT5gA1reqwTq5bPkobnix1goErul98hiuETdHAKKY4kFOA5RqD3EnBKS9m6xm6Vb88k6n4x9oFQeJW0lV8RkVZ5wYE6p1lgL4ISd9jdvnJjxq1L/xdxSF5Rgfyx52C4plClEA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=permerror header.from=andestech.com; spf=pass smtp.mailfrom=andestech.com; arc=none smtp.client-ip=60.248.80.70 Authentication-Results: smtp.subspace.kernel.org; dmarc=permerror header.from=andestech.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=andestech.com Received: from mail.andestech.com (ATCPCS31.andestech.com [10.0.1.89]) by Atcsqr.andestech.com with ESMTPS id 598DZFiu019619 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 8 Oct 2025 21:35:15 +0800 (+08) (envelope-from cl634@andestech.com) Received: from swlinux02 (10.0.15.183) by ATCPCS31.andestech.com (10.0.1.89) with Microsoft SMTP Server id 14.3.498.0; Wed, 8 Oct 2025 21:35:15 +0800 Date: Wed, 8 Oct 2025 21:35:15 +0800 From: CL Wang To: Krzysztof Kozlowski , CC: Conor Dooley , , , , , , , , , Subject: Re: [PATCH V1 1/2] dt-bindings: dmaengine: Add support for ATCDMAC300 DMA engine Message-ID: References: <20251002131659.973955-1-cl634@andestech.com> <20251002131659.973955-2-cl634@andestech.com> <20251002-absolute-spinning-f899e75b2c4a@spud> <734de17e-a712-4eb5-96fa-b7e75f86d880@kernel.org> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.2.12 (2023-09-09) X-DKIM-Results: atcpcs31.andestech.com; dkim=none; X-DNSRBL: X-SPAM-SOURCE-CHECK: pass X-MAIL:Atcsqr.andestech.com 598DZFiu019619 Hi Krzysztof, Thanks for the clarification, and sorry for the earlier confusion. To elaborate on the rationale: "andestech,atcdmac300" is the IP core name of the DMA controller, which serves as a generic fallback compatible shared across multiple Andes SoCs. Primary compatible (SoC-specific): andestech,qilai-dma refers to the DMA controller instance implemented on the Qilai SoC, following the SoC-specific recommendation. Fallback compatible (IP-core specific): andestech,atcdmac300 represents the reusable IP block used across different Andes SoCs that share the same register map and programming model. Keeping andestech,atcdmac300 as a fallback helps avoid code duplication and allows a single driver to support future SoCs using the same hardware IP. This approach follows the DeviceTree binding guideline: “DO use a SoC-specific compatible for all SoC devices, followed by a fallback if appropriate. SoC-specific compatibles are also preferred for the fallbacks.” — Documentation/devicetree/bindings/writing-bindings.rst, line 42 Please let me know if this aligns with your expectation. Best regards, CL On Wed, Oct 08, 2025 at 05:04:53PM +0900, Krzysztof Kozlowski wrote: > [EXTERNAL MAIL] > > On 08/10/2025 12:13, CL Wang wrote: > > Hi Krzysztof, > > > > Thank you for pointing this out. > > > > "ATCDMAC300" is the IP block name of the DMA controller used in Andes SoC. > > According to your suggestion, I have updated the binding to use SoC-specific > > compatibles with "andestech,atcdmac300" as a fallback, as shown below: > > > > - const: andestech,atcdmac300 > > + items: > > + - enum: > > + - andestech,qilai-dma > > + - const: andestech,atcdmac300 > > ... > > dma-controller@f0c00000 { > > - compatible = "andestech,atcdmac300"; > > + compatible = "andestech,qilai-dma", "andestech,atcdmac300"; > > That's exactly the same code as you pasted before. Please do not repeat > the same as argument to my comment. > > Best regards, > Krzysztof