linux-kernel - Re: [PATCHv2] DMAEngine: Let dmac drivers to set chan

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: <CABE8wwstQaFpVdQ+uhYzadGj_cDXwVPHMQtRJWMmSS146uEzYg@mail.gmail.com>
Date:	Thu, 28 Jul 2011 11:14:00 -0700
From:	"Williams, Dan J" <dan.j.williams@...el.com>
To:	Jaswinder Singh <jaswinder.singh@...aro.org>
Cc:	Russell King <rmk@....linux.org.uk>,
	"Koul, Vinod" <vinod.koul@...el.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	linux-kernel@...r.kernel.org, linus.walleij@...ricsson.com,
	per.friden@...ricsson.com, wei.zhang@...escale.com,
	ebony.zhu@...escale.com, iws@...o.caltech.edu,
	s.hauer@...gutronix.de, maciej.sosnowski@...el.com,
	saeed@...vell.com, shawn.guo@...escale.com, yur@...raft.com,
	agust@...x.de, iwamatsu.nobuhiro@...esas.com,
	per.forlin@...ricsson.com, jonas.aberg@...ricsson.com,
	anemo@....ocn.ne.jp
Subject: Re: [PATCHv2] DMAEngine: Let dmac drivers to set chan_id

On Thu, Jul 28, 2011 at 10:54 AM, Jaswinder Singh
<jaswinder.singh@...aro.org> wrote:
> On 28 July 2011 02:07, Russell King <rmk@....linux.org.uk> wrote:
>>
>>> On a serious note, my proposal, and the reply, shows the possibility
>>> of having :-
>>> a) Client drivers that are truly platform agnostic -- no platform_data
>>> poking for
>>>       channel selection
>>
>> I really doubt that's even possible.  Take this setup:
>
> I don't want to suggest anything wrong just because I didn't understand
> your h/w.
> I hope you will be kind enough to help me better understand your setup,
> so that I have a fair chance to present my proposal.

I don't understand all the slave usage models but the proposal seems
fragile.  It wants to encode a whole bunch of arch specific details
into a 32-bit code, but it still seems to me that there will always be
platform specific details that don't fit the code.  Especially when we
are still striving to ensure common behavior across drivers.  It seems
the first step should be getting a few instances of a client driver
interfacing with multiple dma drivers (via platform specific
machinery) and see if anything common falls out of those
implementations that can be pulled into dmaengine.  The proposal seems
to be addressing a problem that we don't yet have (several clients
associating with multiple channels in disparate and un-maintainable
ways).

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