linux-kernel - Re: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver

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]

Date:   Fri, 4 Aug 2017 17:21:03 +0300
From:   Peter Ujfalusi <peter.ujfalusi@...com>
To:     Pierre Yves MORDRET <pierre-yves.mordret@...com>,
        Vinod Koul <vinod.koul@...el.com>
CC:     Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre TORGUE <alexandre.torgue@...com>,
        Russell King <linux@...linux.org.uk>,
        Dan Williams <dan.j.williams@...el.com>,
        "M'boumba Cedric Madianga" <cedric.madianga@...il.com>,
        Fabrice GASNIER <fabrice.gasnier@...com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Fabien DESSENNE <fabien.dessenne@...com>,
        Amelie DELAUNAY <amelie.delaunay@...com>,
        "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver

On 08/04/2017 03:50 PM, Pierre Yves MORDRET wrote:
> Our DMAMUX can manage up to 255 request lines (only 128 is eventually assigned
> though) onto 16 events: 8 events mapped on 1 DMA and the 8 others onto the
> second DMA. Request line numbering is fixed (a peripheral DMA request is
> assigned to one MUX input) and but can be routed randomly onto the any 16
> channels. We use chanID to mux input on event.
> chanID given by dma_get_any_slave_channe is enough in our case.

I would think that if you have in the router node:
dma-masters = <&dma1>, <&dma2>;

and request a DMA via the router:
dmas = <&dma_router req_in param1 param2>;

then the router driver would decide which dma-master it is going to assign the
given request line and craft the dma-spec based on this decision. This
requires no callback to the router from the DMA master driver at all.

The idea of the dma event router is to be transparent for the DMA clients
(peripherals needing DMA channel) and for the DMA drivers as well. Neither
should know that the events are muxed as it does not really matter for them.

-- 
Péter