Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751473AbcDTS65 (ORCPT ); Wed, 20 Apr 2016 14:58:57 -0400 Received: from mx2.suse.de ([195.135.220.15]:57754 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750717AbcDTS6z (ORCPT ); Wed, 20 Apr 2016 14:58:55 -0400 Date: Wed, 20 Apr 2016 20:58:44 +0200 From: "Luis R. Rodriguez" To: Chris Wilson Cc: intel-gfx@lists.freedesktop.org, Tvrtko Ursulin , Mika Kuoppala , Joonas Lahtinen , Tvrtko Ursulin , Daniel Vetter , Jani Nikula , David Airlie , Yishai Hadas , Dan Williams , Ingo Molnar , "Peter Zijlstra (Intel)" , David Hildenbrand , "Luis R . Rodriguez" , dri-devel@lists.freedesktop.org, netdev@vger.kernel.org, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 02/19] io-mapping: Specify mapping size for io_mapping_map_wc() Message-ID: <20160420185844.GQ1990@wotan.suse.de> References: <1461177750-20187-1-git-send-email-chris@chris-wilson.co.uk> <1461177750-20187-3-git-send-email-chris@chris-wilson.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1461177750-20187-3-git-send-email-chris@chris-wilson.co.uk> 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 Content-Length: 1535 Lines: 37 On Wed, Apr 20, 2016 at 07:42:13PM +0100, Chris Wilson wrote: > The ioremap() hidden behind the io_mapping_map_wc() convenience helper > can be used for remapping multiple pages. Extend the helper so that > future callers can use it for larger ranges. > > Signed-off-by: Chris Wilson > Cc: Tvrtko Ursulin > Cc: Daniel Vetter > Cc: Jani Nikula > Cc: David Airlie > Cc: Yishai Hadas > Cc: Dan Williams > Cc: Ingo Molnar > Cc: "Peter Zijlstra (Intel)" > Cc: David Hildenbrand > Cc: Luis R. Rodriguez > Cc: intel-gfx@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org > Cc: netdev@vger.kernel.org > Cc: linux-rdma@vger.kernel.org > Cc: linux-kernel@vger.kernel.org We have 2 callers today, in the future, can you envision this API getting more options? If so, in order to avoid the pain of collateral evolutions I can suggest a descriptor being passed with the required settings / options. This lets you evolve the API without needing to go in and modify old users. If you choose not to that's fine too, just figured I'd chime in with that as I've seen the pain with other APIs, and I'm putting an end to the needless set of collateral evolutions this way. Other than that possible API optimization: Reviewed-by: Luis R. Rodriguez Luis