Message-ID: <7f4207ff-42ec-46ee-beb6-cb27835f955d@arm.com>
Date: Thu, 24 Apr 2025 12:38:28 +0100
From: Robin Murphy <robin.murphy@....com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Vinod Koul <vkoul@...nel.org>, 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 3:34 pm, Geert Uytterhoeven wrote:
> Hi Robin,
> 
> On Wed, 23 Apr 2025 at 15:29, Robin Murphy <robin.murphy@....com> wrote:
>> On 2025-04-23 1:17 pm, Vinod Koul wrote:
>>> On 23-04-25, 14:13, Geert Uytterhoeven wrote:
>>>> 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.
> 
> Dependencies in Kconfig are not related to DT bindings, they only
> control what can be built?

I was questioning how you have decided that there are "no users at all", 
and how you know "the need" hasn't already arisen...

>>>>> 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.
> 
> Please read [1] and ask yourself if Linux wants to see a question
> about Arm DMA-350 when configuring a kernel for his AMD Threadripper
> workstation...

...because the whole point here is that it's *not* "completely 
nonsensical". I am well aware of Linus' view and I share it myself. This 
is not a driver for some deeply platform-vendor-specific firmware 
function. PCIe FPGA prototyping cards are a thing, so yes, just like 
with XILINX_DMA, anyone with one of those and access to the IP could 
absolutely synthesise and drive a functional DMA-350 in their x86 PC 
today if they wish.

Conversely, Linus doesn't have a DMA-350 in his Ampere box or his Mac 
either, so in that context it's still just as meaningless to prompt him 
for his ARM64 builds. And I doubt he has all of the dozens of new IIO 
sensors, USB HIDs, etc. which pop up every release either. I'm not sure 
what point you're trying to make there.

People are building hardware now, which by the time it comes out might 
be able to run a standard distro kernel and use this driver, if said 
distro has already built and shipped the module. Why is that such an 
unacceptably terrible thing?

>>> 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?
> 
> If you want to push it that far, fine for me ;-)
> 
>> 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.
> 
> OK, then the ARM dependency can be dropped for now.
> I had done a quick Google search to find SoCs that contain a DMA-350
> instance, and had only found a Cortex-M0-based SoC, so I assumed it
> would be used on ARM, too.
> 
>> 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.
> 
> Sure, there are lots of Kconfig symbols that could benefit from
> additional dependencies. Unfortunately my time is limited, so usually
> I create and send patches for new Kconfig symbols only....

Dare I suggest your time could be less limited if you avoided spending 
it on nonsensical and unnecessary gatekeeping? ;)

Yes, config options with a clear dependency on a particular platform 
should clearly be restricted to configs which include support for that 
platform. Config options which do not have any such dependency are just 
that - *options*, for the distro/end user to decide whether they might 
be (or become) relevant within the scope and lifetime of the kernel 
being built.

Thanks,
Robin.

Powered by blists - more mailing lists