linux-kernel - Re: [PATCH 1/2 v2] dmaengine: rcar-dmac: ensure CHCR DE bit is actually 0 after clear

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: <CAMuHMdX67os-V3Gi4kh+p02j+zXK4DsrJVticA==pp_dYdm1qA@mail.gmail.com>
Date:   Thu, 16 Nov 2017 10:46:41 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>
Cc:     Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Vinod Koul <vinod.koul@...el.com>,
        Niklas Söderlund 
        <niklas.soderlund+renesas@...natech.se>, dmaengine@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@...esas.com>
Subject: Re: [PATCH 1/2 v2] dmaengine: rcar-dmac: ensure CHCR DE bit is
 actually 0 after clear

Hi Morimoto-san,

On Thu, Nov 16, 2017 at 5:33 AM, Kuninori Morimoto
<kuninori.morimoto.gx@...esas.com> wrote:
> From: Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>

Thanks for your patch!

> DMAC reads data from source device, and buffered it until transferable
> size for shink device. Because of this behavoir, DMAC is including

sink, behavior

> buffered data .
>
> Now, CHCR DE bit is controlling DMA transfer enable/disable.
>
> If DE bit was cleared during data transferring, or during buffering,
> it will flush buffered data if source device was peripheral device
> (The buffered data will be removed if source device was memory).
> Because of this behavior, driver should ensure that DE bit is actually
> 0 after cleared.

clearing

> This patch adds new rcar_dmac_chcr_de_barrier() and call it after CHCR
> register access.
>
> Tested-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@...esas.com>
> Tested-by: Ryo Kodama <ryo.kodama.vz@...esas.com>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>
> ---
>  drivers/dma/sh/rcar-dmac.c | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
>
> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index 2b2c7db..16ebd5d 100644
> --- a/drivers/dma/sh/rcar-dmac.c
> +++ b/drivers/dma/sh/rcar-dmac.c
> @@ -10,6 +10,7 @@
>   * published by the Free Software Foundation.
>   */
>
> +#include <linux/delay.h>
>  #include <linux/dma-mapping.h>
>  #include <linux/dmaengine.h>
>  #include <linux/interrupt.h>
> @@ -741,6 +742,24 @@ static int rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
>  /* -----------------------------------------------------------------------------
>   * Stop and reset
>   */
> +static void rcar_dmac_chcr_de_barrier(struct rcar_dmac_chan *chan)
> +{
> +       u32 chcr;
> +       int i;

unsigned int

> +
> +       /*
> +        * Ensure that the setting of the DE bit is actually 0 after
> +        * clearing it.
> +        */
> +       for (i = 0; i < 1024; i++) {
> +               chcr = rcar_dmac_chan_read(chan, RCAR_DMACHCR);
> +               if (!(chcr & RCAR_DMACHCR_DE))
> +                       return;
> +               udelay(1);
> +       }

What's a typical number of loops needed before DE is really cleared?

> +
> +       dev_err(chan->chan.device->dev, "CHCR DE check error\n");
> +}

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