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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D955EC4167B for ; Tue, 28 Nov 2023 16:09:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344263AbjK1QI7 (ORCPT ); Tue, 28 Nov 2023 11:08:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43456 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232712AbjK1QI4 (ORCPT ); Tue, 28 Nov 2023 11:08:56 -0500 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3B48C1BC; Tue, 28 Nov 2023 08:09:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1701187743; x=1732723743; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=bUDTt3o1DE03wIRYkYueaBcLdCqYQmU2dGzx0wmGR44=; b=n/GbhaiQbdnyPWod7LuIbCwAATzIdEUefqGmTkarLRJwivHZTa9W6eb4 xmZt4Y3qlUAhlx/PBIww5pZmHy1BoXA+hUUAm284WVYUQqTW4cbepGMma x34gm27LBfHhqkW4RoncSpL7z46udZftAGtdRGdLpYGxUrs6g7PzbEf1S F+Tp8A/fR0zMGXiJPfe0yOaoKusmj0plFu2C9oqLoraxcoGVQi4VNSZDV fN4uunE+svXDuEHwB/QIcIGnvbUuzGrfX5g9eNOM2x/t94sVvHECAv19m fMBEDnIsENS90UQ9DcDgAZLZEvMO3zunXLLjrQlK8kov8f/kKKwr9Qf14 g==; X-IronPort-AV: E=McAfee;i="6600,9927,10908"; a="373123836" X-IronPort-AV: E=Sophos;i="6.04,234,1695711600"; d="scan'208";a="373123836" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Nov 2023 08:09:03 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10908"; a="1100152703" X-IronPort-AV: E=Sophos;i="6.04,234,1695711600"; d="scan'208";a="1100152703" Received: from smile.fi.intel.com ([10.237.72.54]) by fmsmga005.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Nov 2023 08:09:01 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.97) (envelope-from ) id 1r80du-00000000ClQ-2Zof; Tue, 28 Nov 2023 18:08:58 +0200 Date: Tue, 28 Nov 2023 18:08:58 +0200 From: Andy Shevchenko To: Bartosz Golaszewski Cc: Linus Walleij , Kent Gibson , linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, Bartosz Golaszewski Subject: Re: [PATCH 2/2] gpio: use a mutex to protect the list of GPIO devices Message-ID: References: <20231127193716.63143-1-brgl@bgdev.pl> <20231127193716.63143-2-brgl@bgdev.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231127193716.63143-2-brgl@bgdev.pl> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 27, 2023 at 08:37:16PM +0100, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > The global list of GPIO devices is never modified or accessed from > atomic context so it's fine to protect it using a mutex. Add a new > global lock dedicated to the gpio_devices list and use it whenever > accessing or modifying it. > > While at it: fold the sysfs registering of existing devices into > gpiolib.c and make gpio_devices static within its compilation unit. ... > + scoped_guard(mutex, &gpio_devices_lock) { This is a lot of churn with this because of switching to RAII. Can the body be firstly moved to a helper? > + /* > + * TODO: this allocates a Linux GPIO number base in the global > + * GPIO numberspace for this chip. In the long run we want to > + * get *rid* of this numberspace and use only descriptors, but > + * it may be a pipe dream. It will not happen before we get rid > + * of the sysfs interface anyways. > + */ ... > list_for_each_entry(gdev, &gpio_devices, list) > + if (index-- == 0) > return gdev; I believe this is better with outer {}. -- With Best Regards, Andy Shevchenko