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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANqRtoRz2NF6BEEYcy_BwZ7Hm5EF9zP2Z0eoQcbxaSfUuc2i9Q@mail.gmail.com>
Date:	Thu, 12 Jul 2012 06:55:32 +0900
From:	Magnus Damm <magnus.damm@...il.com>
To:	Guennadi Liakhovetski <g.liakhovetski@....de>
Cc:	Vinod Koul <vinod.koul@...el.com>, linux-sh@...r.kernel.org,
	linux-mmc@...r.kernel.org, Chris Ball <cjb@...top.org>,
	linux-kernel@...r.kernel.org, Paul Mundt <lethal@...ux-sh.org>
Subject: Re: [PATCH 3/4] dma: sh: provide a migration path for slave drivers
 to stop using .private

Hi Guennadi,

[CC Paul]

On Thu, Jul 5, 2012 at 1:17 AM, Guennadi Liakhovetski
<g.liakhovetski@....de> wrote:
> This patch extends the sh dmaengine driver to support the preferred channel
> selection and configuration method, instead of using the "private" field
> from struct dma_chan. We add a standard filter function to be used by
> slave drivers instead of implementing their own ones, and add support for
> the DMA_SLAVE_CONFIG control operation, which must accompany the new
> channel selection method. We still support the legacy .private channel
> allocation method to cater for a smooth driver migration.
>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@....de>
> ---

Thanks for your efforts on this. Something that caught my eye in this
patch is this portion:

+bool shdma_chan_filter(struct dma_chan *chan, void *arg);

If we would use this function in our DMA Engine slave drivers (MMCIF,
SDHI, SCIF, FSI, SIU and so on) then wouldn't we add a strict
dependency on this symbol provided by this particular DMA Engine
driver implementation for the DMAC hardware (that your patch
modifies)?

And what do we do if we want to use the same DMA Engine slave driver
with a different DMA Engine driver implementation?

>From my point of view, there must be some better way to not have such
tight dependencies between the DMA Engine slave consumer and the DMA
Engine driver. Not sure what that looks like though. This symbol
dependency is pretty far from great IMO.

Thanks,

/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ