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: <CAJe_ZhcNM7m-eWA0nDUrOrHxeAhNS00gewf=txmvOFL_uOPhrw@mail.gmail.com>
Date:	Tue, 26 Jul 2011 23:42:54 +0530
From:	Jaswinder Singh <jaswinder.singh@...aro.org>
To:	"Williams, Dan J" <dan.j.williams@...el.com>
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 26 July 2011 20:59, Williams, Dan J <dan.j.williams@...el.com> wrote:
> On Tue, Jul 26, 2011 at 7:30 AM, Jaswinder Singh
> <jaswinder.singh@...aro.org> wrote:
>> On 26 July 2011 01:38, Williams, Dan J <dan.j.williams@...el.com> wrote:
>>> Correct, it is meant that chan_id is only a sysfs property.  Any
>>> driver usage that is assuming chan_id is anything more than a
>>> guaranteed unique number within a given dma_device's list of channels
>>> is probably inferring too much.
>>
>> So you mean dmac/client drivers are wrong if they make use of chan_id.
>> They shouldn't count upon it's value - which is set by DMA API for a completely
>> independent purpose, i.e, creating contiguous sysfs entries.
>
> They can count on it being unique, and maybe the fact that it is in
> the same order as dma_device.channels.
The latter implies the former. And it is already the dmac driver that
decides the
rank of a channel in the list.

>
>>
>> Since "chan_id is only a sysfs property" and the fact that it is used
>> only _once_
>> by the DMA API
>>
>> In drivers/dma/dmaengine.c
>>
>>      chan->chan_id = chancnt++;
>>      dev_set_name(&chan->dev->device, "dma%dchan%d",
>>                             device->dev_id, chan->chan_id);
>>
>>
>> Can't we do away with chan_id altogether ? by having
>>
>>      dev_set_name(&chan->dev->device, "dma%dchan%d",
>>                             device->dev_id, chancnt++);
>>
>> I mean why make every instance of dma_chan bigger by 4bytes ?
>>
>> So why shouldn't we remove chan_id completely from the DMA API ?
>
> Good point...  Let's remove chan_id from the core and push it into the
> drivers that need it.
>
If you agree, I would preserve the chan_id in 'struct dma_chan' but remove
any assignment to it in dmaengine.c  and let the dmac drivers use it freely.
That would:-
a) Let dmac drivers decide what numbers they want to show up in sysfs.
b) chan_id is easily reachable by client drivers, so it is better this way.
c) It would mean lesser and simpler changes to extant users of it.

Thanks,
-Jassi

-- 
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
--
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/