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:	Fri, 09 Sep 2011 03:08:03 +0530
From:	Vinod Koul <vkoul@...radead.org>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	vinod.koul@...el.com, Linus Walleij <linus.walleij@...aro.org>,
	Barry Song <21cnbao@...il.com>, linux-kernel@...r.kernel.org,
	workgroup.linux@....com, Rongjun Ying <rongjun.ying@....com>,
	Barry Song <Baohua.Song@....com>, dan.j.williams@...el.com,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] dmaengine: add CSR SiRFprimaII DMAC driver

On Thu, 2011-09-08 at 22:11 +0200, Arnd Bergmann wrote:
> On Thursday 08 September 2011 20:48:26 Linus Walleij wrote:
> > 2011/9/8 Arnd Bergmann <arnd@...db.de>:
> > > On Thursday 08 September 2011, Barry Song wrote:
> > >>
> > >> this filter is used by all drivers with DMA since every dma channel is
> > >> fixed to be assigned to one device.
> > >
> > > Ok, I see now. I think it would be best to introduce a generic
> > > 'filter by device tree property' function or alternatively an
> > > dma_of_request_channel function like this:
> > 
> > You'd have to discuss that with Vinod, the thing is that x86 Atom
> > systems are using dmaengine for device slave transfers too, and
> > IIRC these things don't use devicetrees. I may be wrong...
> 
> Some of them use device tree, some don't.
> 
> I'm not saying that we have to convert all drivers to use this, but
> for platforms that always have device tree available, it seems by far
> the cleanest solution.
We don't have a very clean solution for filter function in case of slave
dmaengine. How should the client specify which channel it wants is not
really clear.

We can look at device tree but that's something which wont work in case
of non device tree platforms (atom x86).
What we need is this information of channel mapping, which IMO is
platform specific and needs to come from platform data, we can abstract
it actually from the device tree data/PCI/firmware etc but essentially a
mechanism to publish channels and slaves uniquely and match them in this
kind of data

Linus W, any progress on that patches you posted??
 
-- 
~Vinod Koul
Intel Corp.



--
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