Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp5433307rdb; Wed, 13 Dec 2023 08:30:19 -0800 (PST) X-Google-Smtp-Source: AGHT+IEaCfHr6TKjkB0rDKvAVfLfIwHHxzjVYjPjUF4LgVUOMKpkYTCdxvMZSss2ZuRRi+RS7Cwi X-Received: by 2002:a17:902:d342:b0:1cf:fc91:e4d0 with SMTP id l2-20020a170902d34200b001cffc91e4d0mr10084375plk.16.1702485019325; Wed, 13 Dec 2023 08:30:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702485019; cv=none; d=google.com; s=arc-20160816; b=Qz6WShRbIt/ph8m1IR5dfj0/YXR8zNWLky9MTNwoCBtOMw31gXZaRWHOaxGj90wBBH amAmgyvf36LPyimrDS4sF1X1TPHZH/1mQZkLahIm9Vpq8kYiwXkaLyKd1uKhXGSsncsR wmeWhuDHzRc7fKhdMTQG9LiBTCay35dEWlF+2E5KE3FQHQiBTthDOYyKn06UFR9A5P6X H3k/5fnEhHYpNcipL5y1LuihjiIjDCNz+lggiUvpDNVRY+vbvo42V1EwJAldtXhYP3Ly O8w7cHobdrjVa7mZrNovrGxnEvlLW3MIBgt2HIi4AnN5+TjCb7iSm487BYOI6wcQ9TKS vfkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=fAQdzTaU9yNIt/5mpTBt1vtGy7MWmzp6dnnIPLXmytE=; fh=gWgQkwRx1pRN6B0a6aHplanYDEUMdd1fFwHIg8IIY4Q=; b=bJGmpf1ptgdT3HYeelZva4pVDU/3DFAR6Z0tg9clO+b/sey06Ls2Y0+XLXs8uAGeZM eB5kvg5ZBhBM9hoH6wiPOxoOzjLyVvKqhhP08+xtILPx61pwrwjgJqbnUHZUJN/iiatg oDL5TkxAwgsrfP+HUKgM0gCgC/WV2kMXHe/t9mXnD83Z/rYj8r+bY5niUuagnKeWDSjH sRhD/5TN16HD7+IrqRht7X9ICbP9Q6DcXSld8NO44xBtpoEXdJwT7uT3wBU51eJplr6Z q1TK9CyFhMXewjuXSJoZL/aMJz2w0ElyWM91Jq8gsprhFZYbwrdBU5wnLmNLwBGHe7AG np9w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id k17-20020a170902ba9100b001d05aa54912si9534261pls.504.2023.12.13.08.30.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Dec 2023 08:30:19 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id D511C80BE60D; Wed, 13 Dec 2023 08:30:11 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232699AbjLMQ34 (ORCPT + 99 others); Wed, 13 Dec 2023 11:29:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50114 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235433AbjLMQ3w (ORCPT ); Wed, 13 Dec 2023 11:29:52 -0500 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F12BF199; Wed, 13 Dec 2023 08:29:50 -0800 (PST) X-IronPort-AV: E=McAfee;i="6600,9927,10923"; a="16540646" X-IronPort-AV: E=Sophos;i="6.04,273,1695711600"; d="scan'208";a="16540646" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Dec 2023 08:29:51 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10923"; a="839939338" X-IronPort-AV: E=Sophos;i="6.04,273,1695711600"; d="scan'208";a="839939338" Received: from smile.fi.intel.com ([10.237.72.54]) by fmsmga008.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Dec 2023 08:29:49 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.97) (envelope-from ) id 1rDS7G-00000005ZZv-2YRa; Wed, 13 Dec 2023 18:29:46 +0200 Date: Wed, 13 Dec 2023 18:29:46 +0200 From: Andy Shevchenko To: Bartosz Golaszewski Cc: Kent Gibson , linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org, linus.walleij@linaro.org Subject: Re: [PATCH 1/4] gpiolib: cdev: relocate debounce_period_us from struct gpio_desc Message-ID: References: <20231212054253.50094-1-warthog618@gmail.com> <20231212054253.50094-2-warthog618@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Wed, 13 Dec 2023 08:30:12 -0800 (PST) On Wed, Dec 13, 2023 at 05:15:38PM +0100, Bartosz Golaszewski wrote: > On Wed, Dec 13, 2023 at 5:12 PM Andy Shevchenko wrote: > > On Wed, Dec 13, 2023 at 11:59:26PM +0800, Kent Gibson wrote: > > > On Wed, Dec 13, 2023 at 04:40:12PM +0100, Bartosz Golaszewski wrote: > > > > On Wed, Dec 13, 2023 at 3:27 PM Kent Gibson wrote: > > > > > On Wed, Dec 13, 2023 at 03:54:53PM +0200, Andy Shevchenko wrote: > > > > > > On Tue, Dec 12, 2023 at 01:42:50PM +0800, Kent Gibson wrote: ... > > > > > > > +static struct supinfo supinfo; > > > > > > > > > > > > Why supinfo should be a struct to begin with? Seems to me as an unneeded > > > > > > complication. > > > > > > > > I think we should keep it as a struct but defined the following way: > > > > > > > > struct { > > > > spinlock_t lock; > > > > struct rb_root tree; > > > > } supinfo; > > > > > > That is what I meant be merging the struct definition with the variable > > > definition. Or is there some other way to completely do away with the > > > struct that I'm missing? > > > > Look at the top of gpiolib.c: > > > > static DEFINE_MUTEX(gpio_lookup_lock); > > static LIST_HEAD(gpio_lookup_list); > > > > In the similar way you can simply do > > > > static DEFINE_SPINLOCK(gpio_sup_lock); > > static struct rb_root gpio_sup_tree; > > The fact that this has been like this, doesn't mean it's the only > right way. IMO putting these into the same structure makes logical > sense. I disagree on the struct like this on the grounds: - it's global - it's one time use - it adds complications for no benefit - it makes code uglier and longer What we probably want to have is a singleton objects in C language or at least inside Linux kernel project. But I'm not sure it's feasible. > > > > > Yeah, that is a hangover from an earlier iteration where supinfo was > > > > > contained in other object rather than being a global. > > > > > Could merge the struct definition into the variable now. -- With Best Regards, Andy Shevchenko