Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp1797799imc; Tue, 12 Mar 2019 00:23:36 -0700 (PDT) X-Google-Smtp-Source: APXvYqySXLGwf580lryiW+MYni/9hz5AOvtiLsqS0KF7QtFpyX/sncomurApEmhEjLZTGMVqTQcJ X-Received: by 2002:a63:e641:: with SMTP id p1mr841818pgj.325.1552375416676; Tue, 12 Mar 2019 00:23:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552375416; cv=none; d=google.com; s=arc-20160816; b=icTSzZBtUTNFAWJgRIgRy6IHkKZ3rR8ypNj1hXqL3vTYYpXaN8APsMsHU7ZKN3OnQd /2z27VafPjU93lksIPAsRUwny4RGEBKgi3epb992p7eIaK6jdHYHe5mQaWMhZ+tteODU sxUt/P5Y5jvElrV+ayFOsfIytuTLthiQ9u6u3eo8XJ65J0M6E5w6+n9BC0hTWOrFOsKh 4VjVQE2Xb88nwkE6bfakLXUSkPxaC4JsWQDYspBoPkRolDWJqR3eBpr/GhvXuSNh406H JQ6WBlKt9Xm0pL8pAckYz2sdkI/Py1BtENPlKZtDanuiq6efHN8YRlV8DBZvVldj6/B8 jnuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=8a8VmXlU8RObQvd/P/gvRLa/m3fDfJy4y8D2hopmt9c=; b=VgRTCYiFdnaZF8BBbiWkPUpQUbuBGy9pZbIYXbtqT5SuIv+v5CvG6wsuaqW8hZ8F5k 9XppxXtUGOfLtCzniX2JNBCeMamOL7IaHkp3jNeIo99Gcpmra+XvrpWHTYna9J6nLz9C Ggf5sgQNSG6ZCSWr7jlQyl8w5XH6TVQMZjothKbjMk6V8HCQyd/bK9RB4hyqOgVjG1/9 emHQA9heWPBeni1bUd2F5EIy42hV/35MVS+JUP20qpCHpJiUh7LPeIQF5pHVG6BTC31K dLqVCJ6Am8JZx3/iqhRxwaeu8NA8NjFb1W1SSgkgX+kEjx06OAyWWMxE+iTfYQO+v0Ia IHaQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=VnJ9vN5H; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o61si784013pld.280.2019.03.12.00.23.20; Tue, 12 Mar 2019 00:23:36 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=VnJ9vN5H; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727115AbfCLHVl (ORCPT + 99 others); Tue, 12 Mar 2019 03:21:41 -0400 Received: from mail-it1-f196.google.com ([209.85.166.196]:54174 "EHLO mail-it1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726209AbfCLHVk (ORCPT ); Tue, 12 Mar 2019 03:21:40 -0400 Received: by mail-it1-f196.google.com with SMTP id x189so2773955itd.3; Tue, 12 Mar 2019 00:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=8a8VmXlU8RObQvd/P/gvRLa/m3fDfJy4y8D2hopmt9c=; b=VnJ9vN5HiV6QDiYzX28+tlyE4Wiy/2cQ4T6oanTuk9E5OjlgQWM6O9b6foDZu7XHCy bDm/zW6hin7Uz2WAAzNwTu2bZxfLnxyaMl3Lhwi4IdZ4wxoVXQoEGPY/c4Axs/gxODEU IkwKUJPA8VyJ36K+rClr6ggh1lVBE/QOOXJNXmlOegRVPBfoYRjUjGOPFo8iOy1+Q04E 1ZTyXO/nvZy3lMxU/oX9uj3Mc8gZKSPYxPoIQNbqZ2gHn0V3KqK5aekeYflC1RE3Q9bH xdaKccyugYLhkId37VauEv1o3i1RjUvU9Xuga70HmqsJwtkZ1GUaoXDOk4W22i2kkvVN SwTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=8a8VmXlU8RObQvd/P/gvRLa/m3fDfJy4y8D2hopmt9c=; b=VaKYc2tdKsEpHWZnzNJTlYDG0W9KdWf//+L01tFjq3rG0To+Mn1F7gCkbUUBUGpWlY hghZ7e31oTv1WmGobe7hnf56xckjbK1VsD+Pxab0UfJ1q0Qg8fjYwrvFs1mWiCoKwgbE LWGozwCVaWxoHj3mTBrng+6jGyj5qd12yg9D2YevOq9U/3/vIOPtG/5wD5BEzVTmmWJV FXk2PfqUz5kxU+b8cRFe+hnG6xd0r0ZtFsJFy0yhL8Avafc05bmdAtaHQbkvZsIVL5c4 LwwPnME3bEjBg06V0CJHrfvN8YkNr5N739uFyERGahH7m8loza4fjg8vNvGYXZYmjqSh THGg== X-Gm-Message-State: APjAAAXEzobMLSnqgxDcMZ5pDXWt6xrLELSVYpSNevveIp6mWN+YnpFc jm1fCIP+NBdJ3rHHaG1vl/kKHDzj X-Received: by 2002:a24:8092:: with SMTP id g140mr1239778itd.15.1552375299117; Tue, 12 Mar 2019 00:21:39 -0700 (PDT) Received: from icarus ([2001:268:c0a3:c255:c70:4af9:86e2:2]) by smtp.gmail.com with ESMTPSA id w6sm2892411iom.22.2019.03.12.00.21.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 12 Mar 2019 00:21:38 -0700 (PDT) Date: Tue, 12 Mar 2019 16:22:22 +0900 From: William Breathitt Gray To: Masahiro Yamada Cc: Linus Walleij , Andrew Morton , "open list:GPIO SUBSYSTEM" , linux-arch , "linux-kernel@vger.kernel.org" , Andy Shevchenko , Rasmus Villemoes , Bartosz Golaszewski , Linux ARM , Andy Shevchenko , Arnd Bergmann Subject: Re: [PATCH v9 1/9] bitops: Introduce the for_each_set_clump8 macro Message-ID: <20190312072222.GA2898@icarus> References: <12b3a364ac7fc32194fa6f55911dd800aca92a56.1551598603.git.vilhelm.gray@gmail.com> <20190308085733.GA3903@icarus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 12, 2019 at 02:36:21PM +0900, Masahiro Yamada wrote: > On Fri, Mar 8, 2019 at 5:57 PM William Breathitt Gray > wrote: > > > > On Fri, Mar 08, 2019 at 09:31:00AM +0100, Linus Walleij wrote: > > > On Sun, Mar 3, 2019 at 8:47 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. > > > > > > > > Suggested-by: Andy Shevchenko > > > > Suggested-by: Rasmus Villemoes > > > > Cc: Arnd Bergmann > > > > Cc: Andrew Morton > > > > Reviewed-by: Andy Shevchenko > > > > Reviewed-by: Linus Walleij > > > > Signed-off-by: William Breathitt Gray > > > > > > Andrew: would you be OK with this being merged in v5.1? > > > > > > If we need to move the code to drivers/gpio that's OK (though > > > I think it's generally useful) but I need to know to proceed with > > > the William's nice optimization of these drivers. > > > > > > Yours, > > > Linus Walleij > > > > I was waiting on Andy to suggest some examples out of the GPIO realm, > > but he may be under a heavy workload right so I decided to do a quick > > search for one. > > > > In drivers/of/unittest.c, there is loop across a bitmap in the > > of_unittest_destroy_tracked_overlays function: > > > > for (id = MAX_UNITTEST_OVERLAYS - 1; id >= 0; id--) { > > if (!(overlay_id_bits[BIT_WORD(id)] & BIT_MASK(id))) > > continue; > > > > This section of code is checking each bit individually, and skipping if > > that bit is not set. This looping can be optimized by using the > > for_each_set_clump8 macro > > > Probably no. > > > I see this comment before the loop. > /* remove in reverse order */ You're right, for_each_set_clump8 wouldn't work in this case since it does not loop in reverse order. I shouldn't have rushed to find a case and ignored the context of the code like that. Since Andy appears to have hardware outside of the GPIO subsystem he's testing, let's wait for that and see how it turns out. William Breathitt Gray > > > Also, the unittest code handles per-bit > whereas your helper does per-byte. > > > > > > > to skip clumps of nonset bits (not to mention > > make the logic of the code much simpler and easier to follow by reducing > > the code to a single line): > > > > for_each_set_clump8(id, clump, overlay_id_bits, MAX_UNITTEST_OVERLAYS-1) > > > > The for_each_set_clump8 macro is not specific to the GPIO subsystem; I > > just happen to use it in these GPIO drivers simply because I am most > > familar with this section of the kernel (it's where most of my > > contributions occur afterall). > > > > Consider this, if I am able to find a use for this macro outside of the > > GPIO subsystem within a matter minutes, then there must be some benefit > > in allowing the rest of the kernel to use the for_each_set_clump8 macro. > > So let's put it in bitops.h rather than restrict it to just the GPIO > > subsystem. > > > If we do not find useful cases in other subsystem, > this patch set looks over-engineering to me. > > > > > > > > William Breathitt Gray > > > -- > Best Regards > Masahiro Yamada