linux-kernel - Re: [PATCH RFC 12/13] dmaengine: sdxi: Add Kconfig and Makefile

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: <20250915160856.000005bc@huawei.com>
Date: Mon, 15 Sep 2025 16:08:56 +0100
From: Jonathan Cameron <jonathan.cameron@...wei.com>
To: Nathan Lynch via B4 Relay <devnull+nathan.lynch.amd.com@...nel.org>
CC: <nathan.lynch@....com>, Vinod Koul <vkoul@...nel.org>, Wei Huang
	<wei.huang2@....com>, Mario Limonciello <mario.limonciello@....com>, "Bjorn
 Helgaas" <bhelgaas@...gle.com>, <linux-pci@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <dmaengine@...r.kernel.org>
Subject: Re: [PATCH RFC 12/13] dmaengine: sdxi: Add Kconfig and Makefile

On Fri, 05 Sep 2025 13:48:35 -0500
Nathan Lynch via B4 Relay <devnull+nathan.lynch.amd.com@...nel.org> wrote:

> From: Nathan Lynch <nathan.lynch@....com>
> 
> Add SDXI Kconfig that includes debug and unit test options in addition
> to the usual tristate. SDXI_DEBUG seems necessary because
> DMADEVICES_DEBUG makes dmatest too verbose.
> 
> One goal is to keep the bus-agnostic portions of the driver buildable
> without PCI(_MSI), in case non-PCI SDXI implementations come along
> later.
> 
> Co-developed-by: Wei Huang <wei.huang2@....com>
> Signed-off-by: Wei Huang <wei.huang2@....com>
> Signed-off-by: Nathan Lynch <nathan.lynch@....com>
It's up to the dma maintainer, but personally and for subsystems I
do maintain this approach of putting the build files in at the end
is not something I'd accept.

The reason being that it leads to issues in earlier patches being
hidden with stuff not well separated.  I'd much rather see the driver
built up so that it builds at each step with each new patch
adding additional functionality.  Also avoids things like comments
on the build dependencies in patch descriptions earlier in the series.
They become clear as the code is with the patch.  The one about MSIX
for example doesn't seem to be related to what is here.

Anyhow, no idea if dma maintainers prefer that or this approach.

> ---
>  drivers/dma/Kconfig       |  2 ++
>  drivers/dma/Makefile      |  1 +
>  drivers/dma/sdxi/Kconfig  | 23 +++++++++++++++++++++++
>  drivers/dma/sdxi/Makefile | 17 +++++++++++++++++
>  4 files changed, 43 insertions(+)
> 
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index 05c7c7d9e5a4e52a8ad7ada8c8b9b1a6f9d875f6..cccf00b73e025944681b03cffe441c372526d3f3 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -774,6 +774,8 @@ source "drivers/dma/fsl-dpaa2-qdma/Kconfig"
>  
>  source "drivers/dma/lgm/Kconfig"
>  
> +source "drivers/dma/sdxi/Kconfig"
> +
>  source "drivers/dma/stm32/Kconfig"
>  
>  # clients
> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
> index a54d7688392b1a0e956fa5d23633507f52f017d9..ae4154595e1a6250b441a90078e9df3607d3d1dd 100644
> --- a/drivers/dma/Makefile
> +++ b/drivers/dma/Makefile
> @@ -85,6 +85,7 @@ obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
>  obj-$(CONFIG_ST_FDMA) += st_fdma.o
>  obj-$(CONFIG_FSL_DPAA2_QDMA) += fsl-dpaa2-qdma/
>  obj-$(CONFIG_INTEL_LDMA) += lgm/
> +obj-$(CONFIG_SDXI) += sdxi/
>  
>  obj-y += amd/
>  obj-y += mediatek/
> diff --git a/drivers/dma/sdxi/Kconfig b/drivers/dma/sdxi/Kconfig
> new file mode 100644
> index 0000000000000000000000000000000000000000..c9757cffb5f64fbc175ded8d0c9d751f0a22b6df
> --- /dev/null
> +++ b/drivers/dma/sdxi/Kconfig
> @@ -0,0 +1,23 @@
> +config SDXI
> +	tristate "SDXI support"
> +	select DMA_ENGINE
> +	select DMA_VIRTUAL_CHANNELS
> +	select PACKING
> +	help
> +	  Enable support for Smart Data Accelerator Interface (SDXI)
> +	  Platform Data Mover devices. SDXI is a vendor-neutral
> +	  standard for a memory-to-memory data mover and acceleration
> +	  interface.
> +
> +config SDXI_DEBUG
> +	bool "SDXI driver debug"
> +	default DMADEVICES_DEBUG
> +	depends on SDXI != n
> +	help
> +	  Enable debug output from the SDXI driver. This is an option
> +	  for use by developers and most users should say N here.
> +
> +config SDXI_KUNIT_TEST
> +       tristate "SDXI unit tests" if !KUNIT_ALL_TESTS
> +       depends on SDXI && KUNIT
> +       default KUNIT_ALL_TESTS
> diff --git a/drivers/dma/sdxi/Makefile b/drivers/dma/sdxi/Makefile
> new file mode 100644
> index 0000000000000000000000000000000000000000..c67e475689b45d6260fe970fb4afcc25f8f9ebc1
> --- /dev/null
> +++ b/drivers/dma/sdxi/Makefile
> @@ -0,0 +1,17 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +ccflags-$(CONFIG_SDXI_DEBUG) += -DDEBUG

What does this actually do?  More modern drivers rarely
do this any more because we have nice facilities like dynamic debug.

> +
> +obj-$(CONFIG_SDXI) += sdxi.o
> +
> +sdxi-objs += \
> +	context.o     \
> +	descriptor.o  \
> +	device.o      \
> +	dma.o         \
> +	enqueue.o     \
> +	error.o
> +
> +sdxi-$(CONFIG_PCI_MSI) += pci.o
> +
> +obj-$(CONFIG_SDXI_KUNIT_TEST) += descriptor_kunit.o
>