linux-kernel - Tearing down DMA transfer setup after DMA client has finished

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-next>] [day] [month] [year] [list]

Message-ID: <58356EA8.2010806@free.fr>
Date:   Wed, 23 Nov 2016 11:25:44 +0100
From:   Mason <slash.tmp@...e.fr>
To:     dmaengine@...r.kernel.org, Vinod Koul <vinod.koul@...el.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Dan Williams <dan.j.williams@...el.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Jon Mason <jon.mason@...el.com>,
        Mark Brown <broonie@...aro.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Lee Jones <lee.jones@...aro.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Arnd Bergmann <arnd@...db.de>,
        Maxime Ripard <maxime.ripard@...e-electrons.com>,
        Dave Jiang <dave.jiang@...el.com>,
        Peter Ujfalusi <peter.ujfalusi@...com>,
        Mans Rullgard <mans@...sr.com>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
Subject: Tearing down DMA transfer setup after DMA client has finished

Hello,

On my platform, setting up a DMA transfer is a two-step process:

1) configure the "switch box" to connect a device to a memory channel
2) configure the transfer details (address, size, command)

When the transfer is done, the sbox setup can be torn down,
and the DMA driver can start another transfer.

The current software architecture for my NFC (NAND Flash controller)
driver is as follows (for one DMA transfer).

  sg_init_one
  dma_map_sg
  dmaengine_prep_slave_sg
  dmaengine_submit
  dma_async_issue_pending
  configure_NFC_transfer
  wait_for_IRQ_from_DMA_engine // via DMA_PREP_INTERRUPT
  wait_for_NFC_idle
  dma_unmap_sg

The problem is that the DMA driver tears down the sbox setup
as soon as it receives the IRQ. However, when writing to the
device, the interrupt only means "I have pushed all data from
memory to the memory channel". These data have not reached
the device yet, and may still be "in flight". Thus the sbox
setup can only be torn down after the NFC is idle.

How do I call back into the DMA driver after wait_for_NFC_idle,
to request sbox tear down?

The new architecture would become:

  sg_init_one
  dma_map_sg
  dmaengine_prep_slave_sg
  dmaengine_submit
  dma_async_issue_pending
  configure_NFC_transfer
  wait_for_IRQ_from_DMA_engine // via DMA_PREP_INTERRUPT
  wait_for_NFC_idle
  request_sbox_tear_down /*** HOW TO DO THAT ***/
  dma_unmap_sg

As far as I can tell, my NFC driver should call dmaengine_synchronize ??
(In other words request_sbox_tear_down == dmaengine_synchronize)

So the DMA driver should implement the device_synchronize hook,
and tear the sbox down in that function.

Is that correct? Or am I on the wrong track?

Regards.