Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752704AbdG1Twn (ORCPT ); Fri, 28 Jul 2017 15:52:43 -0400 Received: from gum.cmpxchg.org ([85.214.110.215]:52442 "EHLO gum.cmpxchg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752505AbdG1Twm (ORCPT ); Fri, 28 Jul 2017 15:52:42 -0400 Date: Fri, 28 Jul 2017 15:52:36 -0400 From: Johannes Weiner To: Matthias Kaehlcke Cc: Michal Hocko , Vladimir Davydov , Andrew Morton , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Doug Anderson Subject: Re: [PATCH] mm: memcontrol: Use int for event/state parameter in several functions Message-ID: <20170728195236.GA22303@cmpxchg.org> References: <20170727211004.34435-1-mka@chromium.org> <20170728182354.GC84665@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170728182354.GC84665@google.com> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1267 Lines: 28 On Fri, Jul 28, 2017 at 11:23:54AM -0700, Matthias Kaehlcke wrote: > El Thu, Jul 27, 2017 at 02:10:04PM -0700 Matthias Kaehlcke ha dit: > > > Several functions use an enum type as parameter for an event/state, > > but are called in some locations with an argument of a different enum > > type. Adjust the interface of these functions to reality by changing the > > parameter to int. > > > > This fixes a ton of enum-conversion warnings that are generated when > > building the kernel with clang. Thanks for fixing this, Matthias. Acked-by: Johannes Weiner > While building for another target with a different configuration I > noticed that inc/dec/mod_memcg_page_state() are also called with a > conflicting enum type. Changing the parameter type for these functions > also would make the API more consistent, with the current patch there > is a somewhat odd mix of related functions, with some receiving an > enum and others an int. > > Depending on your preference I can send a v3 of this patch or a > separate patch to address the remaining functions (since this patch > has already been added to -mm). Since it's the exact same rationale for the other functions, it would make sense to me to do a v3 that includes the remaining sites.