From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 97EBDECE58D for ; Wed, 9 Oct 2019 17:09:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6CCA8218AC for ; Wed, 9 Oct 2019 17:09:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731906AbfJIRJY (ORCPT ); Wed, 9 Oct 2019 13:09:24 -0400 Received: from mga04.intel.com ([192.55.52.120]:26159 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731375AbfJIRJX (ORCPT ); Wed, 9 Oct 2019 13:09:23 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Oct 2019 10:09:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,277,1566889200"; d="scan'208";a="206918443" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by fmsmga001.fm.intel.com with ESMTP; 09 Oct 2019 10:09:19 -0700 Received: from andy by smile with local (Exim 4.92.2) (envelope-from ) id 1iIFSf-00036t-U0; Wed, 09 Oct 2019 20:09:17 +0300 Date: Wed, 9 Oct 2019 20:09:17 +0300 From: Andy Shevchenko To: Masahiro Yamada Cc: William Breathitt Gray , Linus Walleij , Bartosz Golaszewski , Andrew Morton , "open list:GPIO SUBSYSTEM" , Linux Kernel Mailing List , linux-arch , Rasmus Villemoes , linux-arm-kernel , Linux PM mailing list , Geert Uytterhoeven , preid@electromag.com.au, Lukas Wunner , sean.nyekjaer@prevas.dk, morten.tiljeset@prevas.dk, Arnd Bergmann Subject: Re: [PATCH v17 01/14] bitops: Introduce the for_each_set_clump8 macro Message-ID: <20191009170917.GG32742@smile.fi.intel.com> References: <893c3b4f03266c9496137cc98ac2b1bd27f92c73.1570633189.git.vilhelm.gray@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 10, 2019 at 01:28:08AM +0900, Masahiro Yamada wrote: > On Thu, Oct 10, 2019 at 12:27 AM William Breathitt Gray > wrote: > > > > This macro iterates for each 8-bit group of bits (clump) with set bits, > > within a bitmap memory region. For each iteration, "start" is set to the > > bit offset of the found clump, while the respective clump value is > > stored to the location pointed by "clump". Additionally, the > > bitmap_get_value8 and bitmap_set_value8 functions are introduced to > > respectively get and set an 8-bit value in a bitmap memory region. > Why is the return type "unsigned long" where you know > it return the 8-bit value ? Because bitmap API operates on unsigned long type. This is not only consistency, but for sake of flexibility in case we would like to introduce more calls like clump16 or so. Same comment for the rest. -- With Best Regards, Andy Shevchenko