Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

2015-11-20 Thread Andy Shevchenko
On Fri, Nov 20, 2015 at 2:30 PM, Peter Ujfalusi wrote: > On 11/20/2015 02:24 PM, Andy Shevchenko wrote: >> On Fri, Nov 20, 2015 at 12:58 PM, Arnd Bergmann wrote: >>> On Friday 20 November 2015 12:25:06 Peter Ujfalusi wrote: On 11/19/2015 01:25 PM, Arnd Bergmann wrote: >> >>> Another idea wou

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

2015-11-20 Thread Arnd Bergmann
On Friday 20 November 2015 14:52:03 Peter Ujfalusi wrote: > > >> For legacy the filter function is pretty much needed to handle the > >> differences > >> between the platforms as not all of them does the filtering in a same way. > >> So > >> the first type of map would be feasible IMHO. > > > >

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

2015-11-20 Thread Peter Ujfalusi
On 11/20/2015 12:58 PM, Arnd Bergmann wrote: >>> That way the vast majority of drivers can use one of the two nice interfaces >>> and the rest can be converted to use __dma_request_chan(). >>> >>> On a related topic, we had in the past considered providing a way for >>> platform code to register a

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

2015-11-20 Thread Peter Ujfalusi
On 11/20/2015 02:24 PM, Andy Shevchenko wrote: > On Fri, Nov 20, 2015 at 12:58 PM, Arnd Bergmann wrote: >> On Friday 20 November 2015 12:25:06 Peter Ujfalusi wrote: >>> On 11/19/2015 01:25 PM, Arnd Bergmann wrote: > >> Another idea would be to remove the filter function from struct dma_chan_map >

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

2015-11-20 Thread Andy Shevchenko
On Fri, Nov 20, 2015 at 12:58 PM, Arnd Bergmann wrote: > On Friday 20 November 2015 12:25:06 Peter Ujfalusi wrote: >> On 11/19/2015 01:25 PM, Arnd Bergmann wrote: > Another idea would be to remove the filter function from struct dma_chan_map > and pass the map through platform data Why not unifi

[RFC] KEYS: Exposing {a,}symmetric key ops to userspace and other bits

2015-11-20 Thread David Howells
Hi Marcel, Mimi, Tadeus, I want to consider adding or doing the following bits to the keyrings facility, aiming for the next merge window: (*) Bring in the patches that I posted to change how the trust model on a keyring works. The model will then be that keys aren't automatically mar

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

2015-11-20 Thread Arnd Bergmann
On Friday 20 November 2015 12:25:06 Peter Ujfalusi wrote: > On 11/19/2015 01:25 PM, Arnd Bergmann wrote: > >> dma_request_channel(mask); /* memcpy. etc, non slave mostly */ > >> > >> Not sure how to name this as reusing existing (good, descriptive) function > >> names would mean changes all over th

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

2015-11-20 Thread Peter Ujfalusi
On 11/19/2015 01:25 PM, Arnd Bergmann wrote: >> If we have two main APIs, one to request slave channels and one to get any >> channel with given capability >> dma_request_slave_channel(NULL, NULL, &mask, fn, fn_param); /* Legacy slave >> */ >> dma_request_slave_channel(dev, name, NULL, NULL, NULL)