linux-kernel - Re: [PATCH 1/2] dmaengine: sh: Do not enable SH_DMAE

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] [day] [month] [year] [list]

Message-ID: <CAMuHMdUSudUvm-ZhTBMtYn814+My2On3_nag60AHNOfX9eGEcw@mail.gmail.com>
Date: Tue, 8 Jul 2025 15:31:41 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Vinod Koul <vkoul@...nel.org>, Peter Ujfalusi <peter.ujfalusi@...il.com>, 
	dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Linux-sh list <linux-sh@...r.kernel.org>, 
	Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>
Subject: Re: [PATCH 1/2] dmaengine: sh: Do not enable SH_DMAE_BASE by default
 during compile testing

Hi Krzysztof,

On Tue, 8 Jul 2025 at 15:21, Krzysztof Kozlowski
<krzysztof.kozlowski@...aro.org> wrote:
> On 08/07/2025 15:07, Geert Uytterhoeven wrote:
> > On Fri, 4 Apr 2025 at 14:22, Krzysztof Kozlowski
> > <krzysztof.kozlowski@...aro.org> wrote:
> >> Enabling the compile test should not cause automatic enabling of all
> >> drivers.
> >>
> >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
> >
> > Thanks for your patch, which is now commit 587dd30449fb1012
> > ("dmaengine: sh: Do not enable SH_DMAE_BASE by default during
> > compile testing") in dmaengine/next.
> >
> >> --- a/drivers/dma/sh/Kconfig
> >> +++ b/drivers/dma/sh/Kconfig
> >> @@ -16,7 +16,7 @@ config SH_DMAE_BASE
> >>         depends on SUPERH || COMPILE_TEST
> >>         depends on !SUPERH || SH_DMA
> >>         depends on !SH_DMA_API
> >> -       default y
> >> +       default SUPERH || SH_DMA
> >
> > I think the check for SUPERH is superfluous, due to the dependency on
> > "!SUPERH || SH_DMA" above.
>
> Indeed it might be, but I must admit I don't understand the dependencies
> here at all. I think commit 9f2c2bb31258 ("dmaengine: sh: Rework Kconfig
> and Makefile") from Laurent made it confusing and this later just grew
> to even more confusing.
>
> What is the intention for "depends on"? This should be enabled when
> SUPERH AND SH_DMA are enabled?
>
> SH_DMA cannot be enabled without SUPERH (no compile test), right? But
> this "depends on !SUPERH || SH_DMA" suggests it could be. This should be
> read for humans as "if not SUPERH, then require at least SH_DMA".
> Otherwise what is the meaning for humans? This driver will work fine
> without SUERPH?
>
> My change for default could be rewritten but I don't understand the goal
> behind current depends, so not sure how should I rewrite it.

I think the original plan was to use the SH DMA drivers on ARM SH-Mobile
SoCs, too.  But enabling SH_DMA on ARM SH-Mobile was never integrated
upstream, and the focus shifted to ARM R-Car SoCs, for which the shiny new
R-Car DMA driver was written...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-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