linux-kernel - Re: [PATCH 1/3] dt-bindings: mmc: mmci: add a property to disable DMA LLI

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: <CACRpkdYMWXEX6dpT0aUrCrFd-8-U35OG9Zmpkfty=zMH=mQqbA@mail.gmail.com>
Date:   Fri, 25 Mar 2022 21:12:09 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Yann Gautier <yann.gautier@...s.st.com>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org,
        linux-stm32@...md-mailman.stormreply.com,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Christophe Kerello <christophe.kerello@...s.st.com>,
        Ludovic Barre <ludovic.barre@...s.st.com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Russell King <linux@...linux.org.uk>,
        Marek Vasut <marex@...x.de>, kernel@...electronics.com,
        Manivannan Sadhasivam <mani@...nel.org>,
        Grzegorz Szymaszek <gszymaszek@...rt.pl>
Subject: Re: [PATCH 1/3] dt-bindings: mmc: mmci: add a property to disable DMA LLI

On Tue, Mar 15, 2022 at 9:26 AM Yann Gautier <yann.gautier@...s.st.com> wrote:

> The STM32 variant uses an internal DMA, and the DMA functions are in its
> dedicated file. So I was planning to do the same as what is done in
> meson-gx-mmc.c: using a bounce buffer to copy from/to in case DMA
> constraints are not fulfilled. Not sure it can help for Ux500.
>
> Ulf, before I send my new series (although it is not ready yet), would
> you be OK with the bounce buffer idea?

Would it not be better if the bounce buffer is something available
for all MMCI variants and not restricted to the STM32 DMA add-on?

What I'm thinking is that this is a problem with the MMCI hardware
rather than with the DMA hardware, so the problem kind of gets
fixed in the wrong place if the bounce buffer is in the DMA add-on
code.

Maybe this is how you fixed it in later patches, I'll take a look.

Yours,
Linus Walleij