linux-kernel - Re: dmaengine.c: question about device_alloc_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: <20080921112605.1e00b92b@hskinnemo-gx745.norway.atmel.com>
Date:	Sun, 21 Sep 2008 11:26:05 +0200
From:	Haavard Skinnemoen <haavard.skinnemoen@...el.com>
To:	"Dan Williams" <dan.j.williams@...el.com>
Cc:	"Timur Tabi" <timur@...escale.com>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: dmaengine.c: question about device_alloc_chan_resources

"Dan Williams" <dan.j.williams@...el.com> wrote:
> On Fri, Sep 19, 2008 at 7:34 AM, Timur Tabi <timur@...escale.com> wrote:
> > Haavard Skinnemoen wrote:
> >
> >> Yes, or maybe provide an interface for simply requesting a channel
> >> without having to register any callbacks.
> >
> > I could use this feature.  The sound drivers for our MPC8610 processor use DMA,
> > but the drivers need to control the DMA hardware directly, so I can't use
> > dmaengine.  I would like to be able to just reserve the channels and program
> > them as I see fit.
> >
> 
> I think its a good idea especially since it would be best not to
> needlessly proliferate client implementations with competing channel
> allocation schemes.  However it would need to be more descriptive
> than:
> 
> struct dma_chan *dma_request_channel(dma_cap_mask_t request_mask);

Yes. It would definitely require a struct dma_slave too, unless we
create a separate function for that.

> Why:
> 1/  What if the requester initializes before a dmaengine device has
> been registered?  What if a device is never registered?

It should just return NULL if it cannot satisfy the request. That might
cause problems since the requesting module normally won't depend on the
dmaengine driver, but I think it's better than requiring drivers to
deal with channels that may come and go at any time. Those drivers will
inevitably be buggy.

> 2/ What about platform specific concerns where dma_cap_mask_t is not
> descriptive enough e.g. only one memcpy channel can address a certain
> bus?  Currently a client implementation can have some intelligence to
> return DMA_DUP for channels that do not have the platform capability.

Currently, clients requesting the DMA_SLAVE capability can specify
which particular DMA device they need. Would it make sense to allow
other clients to do that as well?

Also, struct dma_slave can be extended with
controller-/platform-specific fields. Maybe we need a similar mechanism
for passing platform-specific constraints when requesting "regular"
channels?

> At the very least clients should be allowed to set an 'exclusive' bit
> to prevent the channel from leaking elsewhere.

Agreed. Perhaps we should allow the DMA engine driver to set that flag
too, in case certain parameters make channels difficult to share on
certain controllers.

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