linux-sh.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [PATCH 1/2] dmaengine: sh: Do not enable SH_DMAE_BASE by default during compile testing
       [not found] <20250404122114.359087-1-krzysztof.kozlowski@linaro.org>
@ 2025-07-08 13:07 ` Geert Uytterhoeven
  2025-07-08 13:21   ` Krzysztof Kozlowski
  0 siblings, 1 reply; 3+ messages in thread
From: Geert Uytterhoeven @ 2025-07-08 13:07 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Vinod Koul, Peter Ujfalusi, dmaengine, linux-kernel,
	Linux-sh list

CC linux-sh

Hi Krzysztof,

On Fri, 4 Apr 2025 at 14:22, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
> Enabling the compile test should not cause automatic enabling of all
> drivers.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.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.

>         select RENESAS_DMA
>         help
>           Enable support for the Renesas SuperH DMA controllers.

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH 1/2] dmaengine: sh: Do not enable SH_DMAE_BASE by default during compile testing
  2025-07-08 13:07 ` [PATCH 1/2] dmaengine: sh: Do not enable SH_DMAE_BASE by default during compile testing Geert Uytterhoeven
@ 2025-07-08 13:21   ` Krzysztof Kozlowski
  2025-07-08 13:31     ` Geert Uytterhoeven
  0 siblings, 1 reply; 3+ messages in thread
From: Krzysztof Kozlowski @ 2025-07-08 13:21 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Vinod Koul, Peter Ujfalusi, dmaengine, linux-kernel,
	Linux-sh list

On 08/07/2025 15:07, Geert Uytterhoeven wrote:
> CC linux-sh
> 
> Hi Krzysztof,
> 
> On Fri, 4 Apr 2025 at 14:22, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>> Enabling the compile test should not cause automatic enabling of all
>> drivers.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.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.

Best regards,
Krzysztof

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH 1/2] dmaengine: sh: Do not enable SH_DMAE_BASE by default during compile testing
  2025-07-08 13:21   ` Krzysztof Kozlowski
@ 2025-07-08 13:31     ` Geert Uytterhoeven
  0 siblings, 0 replies; 3+ messages in thread
From: Geert Uytterhoeven @ 2025-07-08 13:31 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Vinod Koul, Peter Ujfalusi, dmaengine, linux-kernel,
	Linux-sh list, Laurent Pinchart

Hi Krzysztof,

On Tue, 8 Jul 2025 at 15:21, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
> On 08/07/2025 15:07, Geert Uytterhoeven wrote:
> > On Fri, 4 Apr 2025 at 14:22, Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >> Enabling the compile test should not cause automatic enabling of all
> >> drivers.
> >>
> >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.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@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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2025-07-08 13:31 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20250404122114.359087-1-krzysztof.kozlowski@linaro.org>
2025-07-08 13:07 ` [PATCH 1/2] dmaengine: sh: Do not enable SH_DMAE_BASE by default during compile testing Geert Uytterhoeven
2025-07-08 13:21   ` Krzysztof Kozlowski
2025-07-08 13:31     ` Geert Uytterhoeven

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).