linux-kernel - RE: [PATCH v1 RFC 1/2] spi: introduce fallback to pio

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:   Tue, 16 Jun 2020 03:05:54 +0000
From:   Robin Gong <yibin.gong@....com>
To:     Vinod Koul <vkoul@...nel.org>
CC:     Mark Brown <broonie@...nel.org>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        "festevam@...il.com" <festevam@...il.com>,
        "robin.murphy@....com" <robin.murphy@....com>,
        "matthias.schiffer@...tq-group.com" 
        <matthias.schiffer@...tq-group.com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        dl-linux-imx <linux-imx@....com>,
        "linux-spi@...r.kernel.org" <linux-spi@...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 v1 RFC 1/2] spi: introduce fallback to pio

On 2020/06/15 Vinod Koul <vkoul@...nel.org> wrote:
> Hi Robin,
> 
> On 15-06-20, 08:59, Robin Gong wrote:
> > Hi Vinod,
> > 	Is there any way to let the device driver to know dma controller is
> > ready (in sdma case is sdma firmware loaded or not)before prep_call?
> > Hence, spi core could map dma buffer or not. Prep_call is too late for
> > spi core since the buffers have been already mapped.
> 
> Can you use .device_alloc_chan_resources for that? This is where all the
> resource allocation for a channel should happen...
But many client driver request dma channel(device_alloc_chan_resources)
in driver probe phase instead of later transfer startup phase.

> > 	From my view, seems dmaengine_slave_config is the only one...Further,
> > sdma need direction in dmaengine_slave_config phase, because currently
> > what's the tx/rx script used on sdma channel is decided not only
> > peripheral_type but also direction. For example, spi tx dma is running
> > ram script to workaround ecspi ERR009165 while rx dma is running rom
> > script, so only spi tx dma channel depends on sdma firmware loaded(now
> > that could be detect by ' load_address < 0' in sdma_load_context() and prep_
> call finally).
> >    I knew direction is deprecated in dmaengine_slave_config, but
> > that's really very useful for sdma to check if firmware loaded and spi
> > core could get it earlier before prep_call(fallback to PIO if dma is not ready).
> 
> I think that is wrong expectation, dmaengine_slave_config should pass the
> slave_config to driver and nothing else. The relevant action should be taken in
> respective prep_ calls here, so that should be fixed as well
Got it, thanks for your clarification.