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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 25 Jul 2011 11:55:45 -0700
From:	"Williams, Dan J" <dan.j.williams@...el.com>
To:	Jaswinder Singh <jaswinder.singh@...aro.org>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	linux-kernel@...r.kernel.org, vinod.koul@...el.com,
	rmk+kernel@....linux.org.uk, 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 Fri, Jul 22, 2011 at 8:56 PM, Jaswinder Singh
<jaswinder.singh@...aro.org> wrote:
> On 23 July 2011 03:53, Williams, Dan J <dan.j.williams@...el.com> wrote:
>
>>
>> Unless you guaranteed that every id is globally unique I don't see how
>> they are generically usable by common clients?
>>
> Yes. And the first step is to allow DMAC drivers to freely set chan_id value.
> Platform could pass the list and mapping of supported 'global channels'
> via platform_data(?) which the DMAC drivers could set in chan_id
> And I am not sure of defining a new variable for that, because chan_id
> is actually used only by some dmac drivers for internal purpose only -
> which they could do by private variables.

Yes, it does appear to have grown a lot of dubious usage in
drivers/dma/ for something that is described as just a "channel ID for
sysfs".  The intent was for drivers that need to maintain their own
hardware specific identification to define a local id scheme (like
iop-adma does in the iop3xx case).

I can sort of see why it is attractive for the goal of having clients
being able to talk to multiple DMACs since it is a field that all
channels already implement.  But, I don't think we should be mixing
sysfs presentation details with a capability that indicates a certain
compatibility level in a DMAC driver implementation.  If the goal is
to be able to use a single client with multiple drivers that, to me,
is asking for a new capability bit (dma_transaction_type) rather than
an id.  Do you have an example of the client and the DMACs that would
first take advantage of such a cross DMAC compatibility?

> Proposal to have global cross-platform enum of channel-IDs defined by
> client drivers, was to be my next patch.
> Though I think, this patch is valid in it's own light.

This is not the purpose of chan_id.

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