Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
MIME-Version: 1.0
References: <20231211-primate-arbitrate-fbcd307a0b00@spud> <CAMuHMdX0bETuMoZCZM7pAodbwyf0ttZMpKuq0ibBZX7S-YV8xw@mail.gmail.com>
 <20231212-ambition-karma-4834afd4eb16@wendy>
In-Reply-To: <20231212-ambition-karma-4834afd4eb16@wendy>
From:   Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Wed, 13 Dec 2023 17:18:24 +0100
Message-ID: <CAMuHMdUS4zjgZp4r1CwE-sO7Ggdk2D=fgfHHqaCpW7dR4Prx6A@mail.gmail.com>
Subject: Re: [PATCH v1] soc: renesas: make ARCH_R9A07G043 depend on !DMA_DIRECT_REMAP
To:     Conor Dooley <conor.dooley@microchip.com>
Cc:     Conor Dooley <conor@kernel.org>, linux-riscv@lists.infradead.org,
        Randy Dunlap <rdunlap@infradead.org>,
        Magnus Damm <magnus.damm@gmail.com>,
        Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>,
        linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org,
        Emil Renner Berthing <kernel@esmil.dk>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Precedence: bulk

On Tue, Dec 12, 2023 at 9:43 AM Conor Dooley <conor.dooley@microchip.com> wrote:
> On Tue, Dec 12, 2023 at 09:19:32AM +0100, Geert Uytterhoeven wrote:
> > On Mon, Dec 11, 2023 at 11:06 PM Conor Dooley <conor@kernel.org> wrote:
> > > From: Conor Dooley <conor.dooley@microchip.com>
> > >
> > > Randy reported yet another build issue with randconfigs on rv32:
> > > WARNING: unmet direct dependencies detected for DMA_GLOBAL_POOL
> > >   Depends on [n]: !ARCH_HAS_DMA_SET_UNCACHED [=n] && !DMA_DIRECT_REMAP [=y]
> > >   Selected by [y]:
> > >   - ARCH_R9A07G043 [=y] && SOC_RENESAS [=y] && RISCV [=y] && NONPORTABLE [=y] && RISCV_ALTERNATIVE [=y] && !RISCV_ISA_ZICBOM [=n] && RISCV_SBI [=y]
> > >
> > > This happens when DMA_DIRECT_REMAP is selected by the T-Head CMO erratum
> >
> > or by the Zicbom extension support?
>
> Probably, yeah. That was just the conditions for this particular
> randconfig IIRC.
>
> > > option and DMA_GLOBAL_POOL is selected by the Andes CMO erratum. Block
> > > selecting the RZ/Five config option, and by extension DMA_GLOBAL_POOL,
> > > if DMA_DIRECT_REMAP has already been enabled.
> > >
> > > Fixes: 484861e09f3e ("soc: renesas: Kconfig: Select the required configs for RZ/Five SoC")
> > > Reported-by: Randy Dunlap <rdunlap@infradead.org>
> > > Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
> > > Closes: https://lore.kernel.org/all/24942b4d-d16a-463f-b39a-f9dfcb89d742@infradead.org/
> > > Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> >
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > i.e. will queue in renesas-devel for v6.8.
> >
> > Or should this be queued as a fix for v6.7 instead?
>
> Depends on your opinion on how critical such a fix is I suppose.
>
> > > ---
> > > I don't know what the exact fixes tag here is as I did not bisect with
> > > the randconfig, so I blamed the one that added DMA_GLOBAL_POOL.
> >
> > Bisection leads to commit da323d4640704001 ("dma-direct: add
> > dependencies to CONFIG_DMA_GLOBAL_POOL") in v6.7-rc1, but that is
> > merely making visible the symptoms, so I think your Fixes tag is fine.

Actually this change cannot be applied (by hand) to the commit in
the Fixes tag, as at that time RISCV_DMA_NONCOHERENT still selected
DMA_DIRECT_REMAP, thus causing a recursive dependency :-(
So I'm gonna drop the Fixes tag, and just queue it for v6.8.  After all
it's "just a randconfig failure", and I don't want anyone to encourage
backporting any of this NONPORTABLE mess to older stable kernels...

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