From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753612AbbCIJMv (ORCPT ); Mon, 9 Mar 2015 05:12:51 -0400 Received: from smtp-out-074.synserver.de ([212.40.185.74]:1105 "EHLO smtp-out-074.synserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752737AbbCIJMr (ORCPT ); Mon, 9 Mar 2015 05:12:47 -0400 X-SynServer-TrustedSrc: 1 X-SynServer-AuthUser: lars@metafoo.de X-SynServer-PPID: 5852 Message-ID: <54FD6411.90401@metafoo.de> Date: Mon, 09 Mar 2015 10:12:49 +0100 From: Lars-Peter Clausen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: Andy Shevchenko CC: Mark Brown , Stanimir Varbanov , "linux-kernel@vger.kernel.org" , linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-spi@vger.kernel.org, Rob Herring , Mark Rutland , Kumar Gala , Andy Gross , Sagar Dharia , Daniel Sneddon Subject: Re: [PATCH v4] spi: qup: Add DMA capabilities References: <1425463325-25805-1-git-send-email-stanimir.varbanov@linaro.org> <20150307112109.GJ28806@sirena.org.uk> <54FC30BE.1070606@metafoo.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/08/2015 01:20 PM, Andy Shevchenko wrote: > On Sun, Mar 8, 2015 at 1:21 PM, Lars-Peter Clausen wrote: >> On 03/07/2015 08:43 PM, Andy Shevchenko wrote: >>> >>> On Sat, Mar 7, 2015 at 1:21 PM, Mark Brown wrote: > >>>> Applied, but why is there no devm_dma_request_slave_channel_reason()? >>> >>> I suppose the answer would be "we have a lot of slightly different >>> cases and we have to get rid of current mess with legacy API calls". >>> The most problematic stuff now inside DMA slave subsystem is so called >>> "filter function". It's a main impediment right now as I understand. >> >> dma_request_slave_channel_reason() is the sane API though and does not use >> the filter functions. Adding a devm version of it seems reasonable. > > It would be dma_request_slave_channel() in the first place, but legacy > stuff didn't allow to do that, so here we are. I wouldn't like the > idea of creating devm_dma_* before we will have stable function names > without legacy involving. > At some point when all callers dma_request_slave_channel() have been updated to use dma_request_slave_channel_reason(), the later might be renamed to the former. I don't see the problem with having to do the same for a devm_dma_request_slave_channel_reason(). - Lars