[PATCH] dmaengine: ARM_DMA350 should depend on ARM/ARM64

[PATCH] dmaengine: ARM_DMA350 should depend on ARM/ARM64

[Geert Uytterhoeven]

The Arm DMA-350 controller is only present on Arm-based SoCs.  Hence add
dependencies on ARM and ARM64, to prevent asking the user about this
driver when configuring a kernel for a non-Arm architecture.

Fixes: 5d099706449d54b4 ("dmaengine: Add Arm DMA-350 driver")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/dma/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 8109f73baf10fc3b..db87dd2a07f7606e 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -95,6 +95,7 @@ config APPLE_ADMAC
 
 config ARM_DMA350
 	tristate "Arm DMA-350 support"
+	depends on ARM || ARM64 || COMPILE_TEST
 	select DMA_ENGINE
 	select DMA_VIRTUAL_CHANNELS
 	help
-- 
2.43.0

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

[Robin Murphy]

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.

Would you propose making all the DesignWare drivers depend on ARC 
because those happen to come from the same company too? ;)

Thanks,
Robin.

>  Hence add
> dependencies on ARM and ARM64, to prevent asking the user about this
> driver when configuring a kernel for a non-Arm architecture.
> 
> Fixes: 5d099706449d54b4 ("dmaengine: Add Arm DMA-350 driver")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>   drivers/dma/Kconfig | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index 8109f73baf10fc3b..db87dd2a07f7606e 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -95,6 +95,7 @@ config APPLE_ADMAC
>   
>   config ARM_DMA350
>   	tristate "Arm DMA-350 support"
> +	depends on ARM || ARM64 || COMPILE_TEST
>   	select DMA_ENGINE
>   	select DMA_VIRTUAL_CHANNELS
>   	help

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

[Geert Uytterhoeven]

Hi Robin,

On Wed, 23 Apr 2025 at 12:59, Robin Murphy <robin.murphy@arm.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...

Unlike drivers for other AMBA devices, this driver is a plain platform
driver, not an amba driver, so it does not depend on ARM_AMBA.

> Would you propose making all the DesignWare drivers depend on ARC
> because those happen to come from the same company too? ;)

No, I am fully aware they may appear anywhere.

> >  Hence add
> > dependencies on ARM and ARM64, to prevent asking the user about this
> > driver when configuring a kernel for a non-Arm architecture.
> >
> > Fixes: 5d099706449d54b4 ("dmaengine: Add Arm DMA-350 driver")
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> >   drivers/dma/Kconfig | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> > index 8109f73baf10fc3b..db87dd2a07f7606e 100644
> > --- a/drivers/dma/Kconfig
> > +++ b/drivers/dma/Kconfig
> > @@ -95,6 +95,7 @@ config APPLE_ADMAC
> >
> >   config ARM_DMA350
> >       tristate "Arm DMA-350 support"
> > +     depends on ARM || ARM64 || COMPILE_TEST
> >       select DMA_ENGINE
> >       select DMA_VIRTUAL_CHANNELS
> >       help

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Vinod Koul]

On 23-04-25, 13:11, Geert Uytterhoeven wrote:
> Hi Robin,
> 
> On Wed, 23 Apr 2025 at 12:59, Robin Murphy <robin.murphy@arm.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...

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?

-- 
~Vinod

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

[Geert Uytterhoeven]

Hi Vinod,

On Wed, 23 Apr 2025 at 13:48, Vinod Koul <vkoul@kernel.org> wrote:
> On 23-04-25, 13:11, Geert Uytterhoeven wrote:
> > On Wed, 23 Apr 2025 at 12:59, Robin Murphy <robin.murphy@arm.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...
>
> 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...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Vinod Koul]

On 23-04-25, 14:13, Geert Uytterhoeven wrote:
> Hi Vinod,
> 
> On Wed, 23 Apr 2025 at 13:48, Vinod Koul <vkoul@kernel.org> wrote:
> > On 23-04-25, 13:11, Geert Uytterhoeven wrote:
> > > On Wed, 23 Apr 2025 at 12:59, Robin Murphy <robin.murphy@arm.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...
> >
> > 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...

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

-- 
~Vinod

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

[Robin Murphy]

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@kernel.org> wrote:
>>> On 23-04-25, 13:11, Geert Uytterhoeven wrote:
>>>> On Wed, 23 Apr 2025 at 12:59, Robin Murphy <robin.murphy@arm.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.

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

[Geert Uytterhoeven]

Hi Robin,

On Wed, 23 Apr 2025 at 15:29, Robin Murphy <robin.murphy@arm.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@kernel.org> wrote:
> >>> On 23-04-25, 13:11, Geert Uytterhoeven wrote:
> >>>> On Wed, 23 Apr 2025 at 12:59, Robin Murphy <robin.murphy@arm.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?

> >>> 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...

> > 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....

Thanks!

[1] https://lore.kernel.org/all/CAHk-=wg+38EHPKGou1MqXwAAXC30cM8sMgZAGnZ7TcFO4L9J2w@mail.gmail.com

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Vinod Koul]

On Tue, 22 Apr 2025 20:11:19 +0200, Geert Uytterhoeven wrote:
> The Arm DMA-350 controller is only present on Arm-based SoCs.  Hence add
> dependencies on ARM and ARM64, to prevent asking the user about this
> driver when configuring a kernel for a non-Arm architecture.
> 
> 

Applied, thanks!

[1/1] dmaengine: ARM_DMA350 should depend on ARM/ARM64
      commit: 86071b369dbdf0a8f7e4424c4e0b613ba7b8ab5e

Best regards,
-- 
~Vinod

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

[Robin Murphy]

On 2025-04-23 3:34 pm, Geert Uytterhoeven wrote:
> Hi Robin,
> 
> On Wed, 23 Apr 2025 at 15:29, Robin Murphy <robin.murphy@arm.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@kernel.org> wrote:
>>>>> On 23-04-25, 13:11, Geert Uytterhoeven wrote:
>>>>>> On Wed, 23 Apr 2025 at 12:59, Robin Murphy <robin.murphy@arm.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.