linux-kernel - Re: [PATCH] dmaengine: ARM_DMA350 should depend on ARM/ARM64

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: <b7557def-d0a1-4035-9586-a2651e28ab24@arm.com>
Date: Wed, 23 Apr 2025 14:29:21 +0100
From: Robin Murphy <robin.murphy@....com>
To: Vinod Koul <vkoul@...nel.org>, Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: dmaengine@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dmaengine: ARM_DMA350 should depend on ARM/ARM64

On 2025-04-23 1:17 pm, Vinod Koul wrote:
> On 23-04-25, 14:13, Geert Uytterhoeven wrote:
>> Hi Vinod,
>>
>> On Wed, 23 Apr 2025 at 13:48, Vinod Koul <vkoul@...nel.org> wrote:
>>> On 23-04-25, 13:11, Geert Uytterhoeven wrote:
>>>> On Wed, 23 Apr 2025 at 12:59, Robin Murphy <robin.murphy@....com> wrote:
>>>>> On 2025-04-22 7:11 pm, Geert Uytterhoeven wrote:
>>>>>> The Arm DMA-350 controller is only present on Arm-based SoCs.
>>>>>
>>>>> Do you know that for sure? I certainly don't. This is a licensable,
>>>>> self-contained DMA controller IP with no relationship whatsoever to any
>>>>> particular CPU ISA - our other system IP products have turned up in the
>>>>> wild paired with non-Arm CPUs, so I don't see any reason that DMA-350
>>>>> wouldn't either.
>>>>
>>>> The dependency can always be relaxed later, when the need arises.
>>>> Note that currently there are no users at all...

Huh? There is now an upstream DT binding, and DTs using that binding 
most certainly already exist - not least the one I have, but I'm not the 
only one. We don't have a requirement that bindings must have 
upstream-supported consumers.

>>> True, but do we have any warnings generated as a result, if there are no
>>> dependency should we still limit a driver to an arch?
>>
>> I am not aware of any warnings (I built it on MIPS yesterday ;-).
>> It is just one more question that pops up during "make oldconfig",
>> and Linus may notice and complain, too...

Well, yeah? It's a new driver for some (relatively) new hardware; every 
release always adds loads of new drivers for things I don't personally 
care about, so I press "n" a lot when updating my config, just like I 
imagine most other people do, Linus included.

> True, give there are no users, lets pick this and drop if we get a non
> arm user

Well by that logic surely it should just depend on COMPILE_TEST, because 
there are no ARM or ARM64 "users" either?

FWIW the not-quite-upstream platform I developed on (a custom build of 
fvp-base-revc with a DMA-350 component added) did happen to be ARM64, as 
are some other Arm-internal designs and one available SoC that I do know 
of containing DMA-350; I am not aware of any Linux-capable 32-bit 
platforms to justify an ARM dependency, so I'd consider that just as 
arbitrarily pulled out of thin air.

But then to pick another example at random, XILINX_DMA equally has no 
"users", so please make that depend on something arbitrary as well for 
consistency; it's only fair.

Thanks,
Robin.