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: <20180511120457.GD30118@vkoul-mobl>
Date:   Fri, 11 May 2018 17:34:57 +0530
From:   Vinod Koul <vinod.koul@...aro.org>
To:     Baolin Wang <baolin.wang@...aro.org>
Cc:     Vinod Koul <vkoul@...nel.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Eric Long <eric.long@...eadtrum.com>,
        Mark Brown <broonie@...nel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        dmaengine@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] dmaengine: sprd: Add Spreadtrum DMA configuration

On 11-05-18, 19:58, Baolin Wang wrote:
> On 11 May 2018 at 19:53, Vinod Koul <vkoul@...nel.org> wrote:
> >> >
> >> >> +/*
> >> >> + * struct sprd_dma_config - DMA configuration structure
> >> >> + * @cfg: dma slave channel runtime config
> >> >> + * @src_addr: the source physical address
> >> >> + * @dst_addr: the destination physical address
> >> >> + * @block_len: specify one block transfer length
> >> >> + * @transcation_len: specify one transcation transfer length
> >> >> + * @src_step: source transfer step
> >> >> + * @dst_step: destination transfer step
> >> >> + * @wrap_ptr: wrap pointer address, once the transfer address reaches the
> >> >> + * 'wrap_ptr', the next transfer address will jump to the 'wrap_to' address.
> >> >> + * @wrap_to: wrap jump to address
> >> >> + * @req_mode: specify the DMA request mode
> >> >> + * @int_mode: specify the DMA interrupt type
> >> >> + */
> >> >> +struct sprd_dma_config {
> >> >> +     struct dma_slave_config cfg;
> >> >> +     phys_addr_t src_addr;
> >> >> +     phys_addr_t dst_addr;
> >> >
> >> > these are already in cfg so why duplicate, same for few more here.
> >>
> >> We save them in 'struct sprd_dma_config' as one parameter for
> >> sprd_dma_config(), otherwise we need add 2 more parameters (src and
> >> dst) for sprd_dma_config().
> >
> > I am not sure I follow...
> >
> > I meant you can use sprd_dma_config.cfg->src_addr/dst_addr and remove src_addr &
> > dst_addr in the sprd_dma_config. It duplicate..
> 
> But we can not set values if dir == DMA_MEM_TO_DEV, since they
> represent the device address, right?
> sprd_dma_config.cfg->src_addr = sg_dma_address(sg);

Ah right and that is another issue to fix then :) we should not store addresses
you get for prep_ calls. They are supposed to be stored in the descriptor.
Current approach is not correct.

You can get different prepare calls  (i think fixing this will remove 1 sg
limitation).. and use the argument values and store in respective descriptors.
Pls do see the other driver examples..

-- 
~Vinod

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ