From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753197AbcFJVIM (ORCPT ); Fri, 10 Jun 2016 17:08:12 -0400 Received: from mx2.suse.de ([195.135.220.15]:47445 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753129AbcFJVIK (ORCPT ); Fri, 10 Jun 2016 17:08:10 -0400 Date: Fri, 10 Jun 2016 23:08:07 +0200 From: "Luis R. Rodriguez" To: Krzysztof Kozlowski Cc: "Luis R. Rodriguez" , Andrew Morton , hch@infradead.org, Bartlomiej Zolnierkiewicz , Jonathan Corbet , Russell King , Robin Murphy , Marek Szyprowski , Doug Anderson , Will Deacon , Joerg Roedel , Christian Borntraeger , Zhen Lei , "Michael S. Tsirkin" , Andy Lutomirski , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 01/44] dma-mapping: Use unsigned long for dma_attrs Message-ID: <20160610210807.GF11948@wotan.suse.de> References: <1465553521-27303-1-git-send-email-k.kozlowski@samsung.com> <1465553521-27303-2-git-send-email-k.kozlowski@samsung.com> <20160610144947.GD11948@wotan.suse.de> <20160610201600.GB2235@kozik-lap> <20160610202347.GE11948@wotan.suse.de> <20160610204419.GA4239@kozik-lap> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160610204419.GA4239@kozik-lap> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 10, 2016 at 10:44:19PM +0200, Krzysztof Kozlowski wrote: > On Fri, Jun 10, 2016 at 10:23:47PM +0200, Luis R. Rodriguez wrote: > > On Fri, Jun 10, 2016 at 10:16:00PM +0200, Krzysztof Kozlowski wrote: > > > The dma-attrs in current form were added around 2008 in 74bc7ceebfa1 > > > ("dma: add dma_*map*_attrs() interfaces"), I think. Since that time, for > > > example, the dma_map_*_attrs() did not change. > > > > So we don't expect this to change either? > > I do not know, I am not aware of planned changes to that. If this will not change then I think this change is good. > > > > If the concern is the const data, why not require const struct dma_attr > > > > for the APIs that we know can and should use const ? > > > > > > The const is one concern. Complicated (more than expected) usage of dma > > > attributes by the caller is second. > > > > > > Switching it to const would also reduce the possibilities of API > > > extension. > > > > My point was that const can be used for only APIs that we are sure of > > that need it. > > As of now, dma_attrs should be const everywhere. That would be almost > the same patchset as current one. If you consider extending the > dma_attrs to something new and not yet known, then how will > differentiate between cases when 'const' is needed for sure? Depends on the use case, but if it known it should always be const then great. > I understand your concern. Sticking to current API for that reason might > be a good defensive API programming... or might be way of keeping this > function prototype for long... Since this hasn't changed for years at all I think your change is reasonable. Luis