From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423029AbcFMRlq (ORCPT ); Mon, 13 Jun 2016 13:41:46 -0400 Received: from mx2.suse.de ([195.135.220.15]:54983 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964924AbcFMRlo (ORCPT ); Mon, 13 Jun 2016 13:41:44 -0400 Date: Mon, 13 Jun 2016 19:41:40 +0200 From: "Luis R. Rodriguez" To: Christoph Hellwig Cc: "Luis R. Rodriguez" , Krzysztof Kozlowski , Andrew Morton , 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: <20160613174140.GM11948@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> <20160613160041.GA23851@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160613160041.GA23851@infradead.org> 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 Mon, Jun 13, 2016 at 09:00:41AM -0700, Christoph Hellwig wrote: > On Fri, Jun 10, 2016 at 04:49:47PM +0200, Luis R. Rodriguez wrote: > > Do we not expect the number of argument to grow ? This "cleanup" would > > do away with such possibilities, and then require adding the API later, > > and this requiring a full set of collateral evolutions again when this > > is needed. What was the original motivation for using this instead of > > the approach you are suggesting ? > > We still got plenty of space for attrs. If you're worried about running > out of 32 flags we could do a dma_attrs_t typedef that we could swich > to a u64. That would have another advantage in that we could add a > __bitwise sparse annotation to avoid people passing the wrong kind of > flags. History shows only sparse use of extensions of these these attributes so I think the approach with a typedef is definitely more suitable for this API, and should last long enough. The added gain of the annotation is a nice bonus. Luis