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:   Thu, 3 Aug 2017 09:42:04 +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

our mail server started to mangle outgoing mails, sorry for that, we are 
trying to resolve that...

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 2017-08-02 17:28, Pierre Yves MORDRET wrote:
> Correct router needs 3 parameters and among those 2 are forwarded though out
> dma_spec. But when you say "ChannelID is dynamically allocated" you mean
> dma_get_any_slave_channel ? If yes I can use the already existing bindings to
> carry the channelID to DMA. No changes need to peripheral...

What I actually mean is that you should not need to modify the DMA 
driver at all.
According to stm32-dma.txt:
#dma-cells = <4>;
1. channelID
2. request line number
3. - 4. some parameters

I believe if you don't have the event router (directly using the DMA 
node) you always need to provide these, right?
If I'm not mistaken, when you use the event router you want to omit the 
ChannelID and get a random channel via dma_get_any_slave_channel in the 
DMA driver and feed back the channelID to the event router driver?
I believe the reason for this is that you want to keep mixed binding 
use, to have direct DMA bindings and bindings via event router.

Now what happens if you have direct binding:
device1 {
	dmas = <&dma2 1 4 0x10400 0x3>;
};

and via event router:
device2 {
	dmas =	<&dma_router 10 0x10400 0x3>,
		<&dma_router 11 0x10400 0x3>;
};

device2 probes first, will get channelID 0 and 1 via 
dma_get_any_slave_channel.

When device1 tries to probe, the channelID 1 is already taken..

You need to convert all peripherals to use the event router to avoid 
such a races. I have done the same for the dra7.
Add the event router driver,
add the event router node and convert existing users to use that
when adding new devices, use the event router node.

The event router's binding would have 3 parameters, it manages the 
available channelIDs, like the ti-dma-crossbar does for dra7. At 
allocate time it would pick an unused channelID and craft the dma-spec 
with the four parameters as documented.
The main DMA driver will not need any modification as everything will be 
taken care of by the event router.

The only gotcha is with memcpy type of transfers as they might also need 
unique channelID, but not requested via the slave binding. For that I 
have added properties to the event router to mask out certain channels 
(and I needed to do the same for the eDMA, but it is unrelated to the 
router itself).

- Péter