linux-kernel - Re: [PATCH V1 1/2] dt-bindings: dmaengine: Add support for ATCDMAC300 DMA engine

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251008-criteria-debit-09f8e855bcec@spud>
Date: Wed, 8 Oct 2025 21:45:42 +0100
From: Conor Dooley <conor@...nel.org>
To: CL Wang <cl634@...estech.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>,
	gg@...inux02.smtp.subspace.kernel.org, vkoul@...nel.org,
	dmaengine@...r.kernel.org, robh@...nel.org, krzk+dt@...nel.org,
	conor+dt@...nel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, tim609@...estech.com
Subject: Re: [PATCH V1 1/2] dt-bindings: dmaengine: Add support for
 ATCDMAC300 DMA engine

On Wed, Oct 08, 2025 at 09:35:15PM +0800, CL Wang wrote:
> 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

Unless there is a significant likelihood of there being different
configurations between devices that are reflected by dedicated properties
there's usually no reason not to use a single compatible for the first
devices and then use that as the fallback for future devices. Either the
future devices will be similar enough for this to work or the fallback
to something not soc-specific wouldn't have helped much since the new
device would need special handling.

This case might be different though Krzysztof, because Andes is an IP
vendor not just someone using an IP in their own devices. People
certainly get tetchy about using someone else's soc-specific compatible
for their device and I can understand that. I also think it's easier to
understand that when you bought an "atcdmac300" IP from a vendor that
the correct fallback is "andes,atcdmac300" rather than
"andes,qilai-dma". Personally, I think what's suggested below is okay.


> 
> 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@...00000 {
> > > -      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
> 

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)