From patchwork Fri Jun 5 13:40:33 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andy Shevchenko X-Patchwork-Id: 1304158 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=23.128.96.18; helo=vger.kernel.org; envelope-from=linux-gpio-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=linux.intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by ozlabs.org (Postfix) with ESMTP id 49dkLM5vWvz9sSJ for ; Fri, 5 Jun 2020 23:40:43 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726844AbgFENkl (ORCPT ); Fri, 5 Jun 2020 09:40:41 -0400 Received: from mga06.intel.com ([134.134.136.31]:61677 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726553AbgFENkk (ORCPT ); Fri, 5 Jun 2020 09:40:40 -0400 IronPort-SDR: yu1F1gpBxLw0VcljA6GsIuNvJmQAFH9W5Y8wj68qv/3hPxnGRHF2gaQk9xQwzVy9c77DHkEoRH +w4RlV4UWrMw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Jun 2020 06:40:39 -0700 IronPort-SDR: ds+TaJtRvlShUDrfzmkqUPJGYmNiL8dav8nGpC+LLXtruJ/jmFZ9orQ0mPgWS54xzu2x9fFgWU 0HgUHNB0tcWQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,476,1583222400"; d="scan'208";a="258033471" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga007.fm.intel.com with ESMTP; 05 Jun 2020 06:40:37 -0700 Received: by black.fi.intel.com (Postfix, from userid 1003) id 1BB57190; Fri, 5 Jun 2020 16:40:37 +0300 (EEST) From: Andy Shevchenko To: Linus Walleij , Bartosz Golaszewski , linux-gpio@vger.kernel.org Cc: Andy Shevchenko , Marek Vasut , Roland Stigge Subject: [PATCH v1 1/4] gpio: pca953x: Synchronize interrupt handler properly Date: Fri, 5 Jun 2020 16:40:33 +0300 Message-Id: <20200605134036.9013-1-andriy.shevchenko@linux.intel.com> X-Mailer: git-send-email 2.27.0.rc2 MIME-Version: 1.0 Sender: linux-gpio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org Since the commit aa58a21ae378 ("gpio: pca953x: disable regmap locking") the locking of regmap is disabled and that immediately introduces a synchronization issue. It's easy to see when we try to monitor more than one interrupt from the same chip. It seems that the problem exists from the day one and even commit 6e20fb18054c ("drivers/gpio/pca953x.c: add a mutex to fix race condition") missed this. Below are the traces and shell reproducers before and after proposed change. Note duplicates in the IRQ events. /proc/interrupts also shows a deviation, i.e. sum of children interrupts higher than parent's one. When locking is disabled for regmap and no protection in IRQ handler ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... gpioset-194 regmap_hw_write_start: i2c-INT3491:02 reg=2 count=1 irq/31-i2c-INT3-139 regmap_hw_read_start: i2c-INT3491:02 reg=4c count=2 gpioset-194 regmap_hw_write_done: i2c-INT3491:02 reg=2 count=1 gpioset-194 regmap_reg_read_cache: i2c-INT3491:02 reg=6 val=f5 gpioset-194 regmap_reg_write: i2c-INT3491:02 reg=6 val=f5 gpioset-194 regmap_hw_write_start: i2c-INT3491:02 reg=6 count=1 irq/31-i2c-INT3-139 regmap_hw_read_done: i2c-INT3491:02 reg=4c count=2 ... % gpiomon gpiochip3 0 & % gpioset gpiochip3 1=0 % gpioset gpiochip3 1=1 event: RISING EDGE offset: 0 timestamp: [ 302.782583765] % gpiomon gpiochip3 2 & % gpioset gpiochip3 1=0 event: RISING EDGE offset: 2 timestamp: [ 312.033148829] event: FALLING EDGE offset: 0 timestamp: [ 312.022757525] % gpioset gpiochip3 1=1 event: RISING EDGE offset: 2 timestamp: [ 316.201148473] event: RISING EDGE offset: 0 timestamp: [ 316.191759599] When locking is disabled for regmap and protection in IRQ handler ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... gpioset-202 regmap_hw_write_start: i2c-INT3491:02 reg=2 count=1 gpioset-202 regmap_hw_write_done: i2c-INT3491:02 reg=2 count=1 gpioset-202 regmap_reg_read_cache: i2c-INT3491:02 reg=6 val=fd gpioset-202 regmap_reg_write: i2c-INT3491:02 reg=6 val=fd gpioset-202 regmap_hw_write_start: i2c-INT3491:02 reg=6 count=1 gpioset-202 regmap_hw_write_done: i2c-INT3491:02 reg=6 count=1 irq/31-i2c-INT3-139 regmap_hw_read_start: i2c-INT3491:02 reg=4c count=2 irq/31-i2c-INT3-139 regmap_hw_read_done: i2c-INT3491:02 reg=4c count=2 ... % gpiomon gpiochip3 0 & % gpioset gpiochip3 1=0 event: FALLING EDGE offset: 0 timestamp: [ 531.330078107] % gpioset gpiochip3 1=1 event: RISING EDGE offset: 0 timestamp: [ 532.912239128] % gpiomon gpiochip3 2 & % gpioset gpiochip3 1=0 event: FALLING EDGE offset: 0 timestamp: [ 539.633669484] % gpioset gpiochip3 1=1 event: RISING EDGE offset: 0 timestamp: [ 542.256978461] Fixes: 6e20fb18054c ("drivers/gpio/pca953x.c: add a mutex to fix race condition") Depends-on: 35d13d94893f ("gpio: pca953x: convert to use bitmap API") Depends-on: 49427232764d ("gpio: pca953x: Perform basic regmap conversion") Cc: Marek Vasut Cc: Roland Stigge Signed-off-by: Andy Shevchenko --- drivers/gpio/gpio-pca953x.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c index 1fca8dd7824f..afe78639ec58 100644 --- a/drivers/gpio/gpio-pca953x.c +++ b/drivers/gpio/gpio-pca953x.c @@ -734,14 +734,16 @@ static irqreturn_t pca953x_irq_handler(int irq, void *devid) struct gpio_chip *gc = &chip->gpio_chip; DECLARE_BITMAP(pending, MAX_LINE); int level; + bool ret; - if (!pca953x_irq_pending(chip, pending)) - return IRQ_NONE; + mutex_lock(&chip->i2c_lock); + ret = pca953x_irq_pending(chip, pending); + mutex_unlock(&chip->i2c_lock); for_each_set_bit(level, pending, gc->ngpio) handle_nested_irq(irq_find_mapping(gc->irq.domain, level)); - return IRQ_HANDLED; + return IRQ_RETVAL(ret); } static int pca953x_irq_setup(struct pca953x_chip *chip, int irq_base) From patchwork Fri Jun 5 13:40:34 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andy Shevchenko X-Patchwork-Id: 1304160 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=23.128.96.18; helo=vger.kernel.org; envelope-from=linux-gpio-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=linux.intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by ozlabs.org (Postfix) with ESMTP id 49dkLN4XPvz9sTC for ; Fri, 5 Jun 2020 23:40:44 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726981AbgFENkm (ORCPT ); Fri, 5 Jun 2020 09:40:42 -0400 Received: from mga07.intel.com ([134.134.136.100]:63304 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726553AbgFENkm (ORCPT ); Fri, 5 Jun 2020 09:40:42 -0400 IronPort-SDR: BPFcSMh7jtsemFPg4CJ5I/7fRE/KP9c/ZVLcsaVConI+LLLzybquhDd7saiA+sIfshVH19GYs5 LVqTNjeHhMSw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Jun 2020 06:40:41 -0700 IronPort-SDR: OqtIsrlpr1oxssqjIC8A75H281j8bGJ0CRfiLuU2A5rMHvfrl8IowwT0x0isuH+qbpeRZcanLQ o9hxfje3enmA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,476,1583222400"; d="scan'208";a="471795242" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga006.fm.intel.com with ESMTP; 05 Jun 2020 06:40:39 -0700 Received: by black.fi.intel.com (Postfix, from userid 1003) id 27F3D132; Fri, 5 Jun 2020 16:40:37 +0300 (EEST) From: Andy Shevchenko To: Linus Walleij , Bartosz Golaszewski , linux-gpio@vger.kernel.org Cc: Andy Shevchenko , Mika Westerberg Subject: [PATCH v1 2/4] gpio: pca953x: Override IRQ for one of the expanders on Galileo Gen 2 Date: Fri, 5 Jun 2020 16:40:34 +0300 Message-Id: <20200605134036.9013-2-andriy.shevchenko@linux.intel.com> X-Mailer: git-send-email 2.27.0.rc2 In-Reply-To: <20200605134036.9013-1-andriy.shevchenko@linux.intel.com> References: <20200605134036.9013-1-andriy.shevchenko@linux.intel.com> MIME-Version: 1.0 Sender: linux-gpio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org ACPI table on Intel Galileo Gen 2 has wrong pin number for IRQ resource of one of the I²C GPIO expanders. Since we know what that number is and luckily have GPIO bases fixed for SoC's controllers, we may use a simple DMI quirk to match the platform and retrieve GpioInt() pin on it for the expander in question. Mika suggested the way to avoid a quirk in the GPIO ACPI library and here is the second, almost rewritten version of it. Fixes: f32517bf1ae0 ("gpio: pca953x: support ACPI devices found on Galileo Gen2") Depends-on: 25e3ef894eef ("gpio: acpi: Split out acpi_gpio_get_irq_resource() helper") Suggested-by: Mika Westerberg Reviewed-by: Mika Westerberg Signed-off-by: Andy Shevchenko --- drivers/gpio/gpio-pca953x.c | 79 +++++++++++++++++++++++++++++++++++++ 1 file changed, 79 insertions(+) diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c index afe78639ec58..4d3157d8b5cd 100644 --- a/drivers/gpio/gpio-pca953x.c +++ b/drivers/gpio/gpio-pca953x.c @@ -107,6 +107,79 @@ static const struct i2c_device_id pca953x_id[] = { }; MODULE_DEVICE_TABLE(i2c, pca953x_id); +#ifdef CONFIG_GPIO_PCA953X_IRQ + +#include +#include +#include + +static const struct dmi_system_id pca953x_dmi_acpi_irq_info[] = { + { + /* + * On Intel Galileo Gen 2 board the IRQ pin of one of + * the I²C GPIO expanders, which has GpioInt() resource, + * is provided as an absolute number instead of being + * relative. Since first controller (gpio-sch.c) and + * second (gpio-dwapb.c) are at the fixed bases, we may + * safely refer to the number in the global space to get + * an IRQ out of it. + */ + .matches = { + DMI_EXACT_MATCH(DMI_BOARD_NAME, "GalileoGen2"), + }, + }, + {} +}; + +#ifdef CONFIG_ACPI +static int pca953x_acpi_get_pin(struct acpi_resource *ares, void *data) +{ + struct acpi_resource_gpio *agpio; + int *pin = data; + + if (acpi_gpio_get_irq_resource(ares, &agpio)) + *pin = agpio->pin_table[0]; + return 1; +} + +static int pca953x_acpi_find_pin(struct device *dev) +{ + struct acpi_device *adev = ACPI_COMPANION(dev); + int pin = -ENOENT, ret; + LIST_HEAD(r); + + ret = acpi_dev_get_resources(adev, &r, pca953x_acpi_get_pin, &pin); + acpi_dev_free_resource_list(&r); + if (ret < 0) + return ret; + + return pin; +} +#else +static inline int pca953x_acpi_find_pin(struct device *dev) { return -ENXIO; } +#endif + +static int pca953x_acpi_get_irq(struct device *dev) +{ + int pin, ret; + + pin = pca953x_acpi_find_pin(dev); + if (pin < 0) + return pin; + + dev_info(dev, "Applying ACPI interrupt quirk (GPIO %d)\n", pin); + + if (!gpio_is_valid(pin)) + return -EINVAL; + + ret = gpio_request(pin, "pca953x interrupt"); + if (ret) + return ret; + + return gpio_to_irq(pin); +} +#endif + static const struct acpi_device_id pca953x_acpi_ids[] = { { "INT3491", 16 | PCA953X_TYPE | PCA_LATCH_INT, }, { } @@ -754,6 +827,12 @@ static int pca953x_irq_setup(struct pca953x_chip *chip, int irq_base) DECLARE_BITMAP(irq_stat, MAX_LINE); int ret; + if (dmi_first_match(pca953x_dmi_acpi_irq_info)) { + ret = pca953x_acpi_get_irq(&client->dev); + if (ret > 0) + client->irq = ret; + } + if (!client->irq) return 0; From patchwork Fri Jun 5 13:40:35 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andy Shevchenko X-Patchwork-Id: 1304157 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=23.128.96.18; helo=vger.kernel.org; envelope-from=linux-gpio-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=linux.intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by ozlabs.org (Postfix) with ESMTP id 49dkLM2hWCz9sRR for ; Fri, 5 Jun 2020 23:40:43 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726965AbgFENkk (ORCPT ); Fri, 5 Jun 2020 09:40:40 -0400 Received: from mga18.intel.com ([134.134.136.126]:6614 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726844AbgFENkk (ORCPT ); Fri, 5 Jun 2020 09:40:40 -0400 IronPort-SDR: gDPgdjs3agIxW5P+Q/MNwy2PE9wzi6rQKNA3ab7NjVslPVC+U2yZ3Yke8SZEdZtaZQgPHZIIId 0vPanXVV3QQw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Jun 2020 06:40:39 -0700 IronPort-SDR: LcfXYzroyINkoPd7ayonJCRZ+/GCSSWU39W0pCuiKJzp9YO16cps1/nJwsuT6iOFx7c6v6UZnO PmPknEA54w2A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,476,1583222400"; d="scan'208";a="269768927" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga003.jf.intel.com with ESMTP; 05 Jun 2020 06:40:38 -0700 Received: by black.fi.intel.com (Postfix, from userid 1003) id 2F2DD2C7; Fri, 5 Jun 2020 16:40:37 +0300 (EEST) From: Andy Shevchenko To: Linus Walleij , Bartosz Golaszewski , linux-gpio@vger.kernel.org Cc: Andy Shevchenko , Marek Vasut Subject: [PATCH v1 3/4] gpio: pca953x: Fix direction setting when configure an IRQ Date: Fri, 5 Jun 2020 16:40:35 +0300 Message-Id: <20200605134036.9013-3-andriy.shevchenko@linux.intel.com> X-Mailer: git-send-email 2.27.0.rc2 In-Reply-To: <20200605134036.9013-1-andriy.shevchenko@linux.intel.com> References: <20200605134036.9013-1-andriy.shevchenko@linux.intel.com> MIME-Version: 1.0 Sender: linux-gpio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org The commit 0f25fda840a9 ("gpio: pca953x: Zap ad-hoc reg_direction cache") seems inadvertently made a typo in pca953x_irq_bus_sync_unlock(). When the direction bit is 1 it means input, and the piece of code in question was looking for output ones that should be turned to inputs. Fix direction setting when configure an IRQ by injecting a bitmap complement operation. Fixes: 0f25fda840a9 ("gpio: pca953x: Zap ad-hoc reg_direction cache") Depends-on: 35d13d94893f ("gpio: pca953x: convert to use bitmap API") Cc: Marek Vasut Signed-off-by: Andy Shevchenko --- drivers/gpio/gpio-pca953x.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c index 4d3157d8b5cd..97c9ac31ecb5 100644 --- a/drivers/gpio/gpio-pca953x.c +++ b/drivers/gpio/gpio-pca953x.c @@ -696,8 +696,6 @@ static void pca953x_irq_bus_sync_unlock(struct irq_data *d) DECLARE_BITMAP(reg_direction, MAX_LINE); int level; - pca953x_read_regs(chip, chip->regs->direction, reg_direction); - if (chip->driver_data & PCA_PCAL) { /* Enable latch on interrupt-enabled inputs */ pca953x_write_regs(chip, PCAL953X_IN_LATCH, chip->irq_mask); @@ -708,7 +706,11 @@ static void pca953x_irq_bus_sync_unlock(struct irq_data *d) pca953x_write_regs(chip, PCAL953X_INT_MASK, irq_mask); } + /* Switch direction to input if needed */ + pca953x_read_regs(chip, chip->regs->direction, reg_direction); + bitmap_or(irq_mask, chip->irq_trig_fall, chip->irq_trig_raise, gc->ngpio); + bitmap_complement(reg_direction, reg_direction, gc->ngpio); bitmap_and(irq_mask, irq_mask, reg_direction, gc->ngpio); /* Look for any newly setup interrupt */ From patchwork Fri Jun 5 13:40:36 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andy Shevchenko X-Patchwork-Id: 1304159 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=23.128.96.18; helo=vger.kernel.org; envelope-from=linux-gpio-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=linux.intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by ozlabs.org (Postfix) with ESMTP id 49dkLN1qqyz9sT8 for ; Fri, 5 Jun 2020 23:40:44 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726988AbgFENkm (ORCPT ); Fri, 5 Jun 2020 09:40:42 -0400 Received: from mga06.intel.com ([134.134.136.31]:61677 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726981AbgFENkl (ORCPT ); Fri, 5 Jun 2020 09:40:41 -0400 IronPort-SDR: ofbkWt8wzKdOKg780+tC1SsiWJd/ZHtiV8932LOxGaK+4r1sMa0BGVMUEVS19wQof0yTydUr5w unxqm3/kuCxw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Jun 2020 06:40:39 -0700 IronPort-SDR: fHikN9QEsACU9YVbdzNnr64FofFhwjV74rhpK3hrPPDVi3I+BL7FOhQcf7Pg/qnF6unPkKjgkG AgeRQikBBxiw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,476,1583222400"; d="scan'208";a="258695056" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga007.jf.intel.com with ESMTP; 05 Jun 2020 06:40:38 -0700 Received: by black.fi.intel.com (Postfix, from userid 1003) id 362BE2FB; Fri, 5 Jun 2020 16:40:37 +0300 (EEST) From: Andy Shevchenko To: Linus Walleij , Bartosz Golaszewski , linux-gpio@vger.kernel.org Cc: Andy Shevchenko , =?utf-8?q?Uwe_Klein?= =?utf-8?q?e-K=C3=B6nig?= Subject: [PATCH v1 4/4] gpio: pca953x: disable regmap locking for automatic address incrementing Date: Fri, 5 Jun 2020 16:40:36 +0300 Message-Id: <20200605134036.9013-4-andriy.shevchenko@linux.intel.com> X-Mailer: git-send-email 2.27.0.rc2 In-Reply-To: <20200605134036.9013-1-andriy.shevchenko@linux.intel.com> References: <20200605134036.9013-1-andriy.shevchenko@linux.intel.com> MIME-Version: 1.0 Sender: linux-gpio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org It's a repetition of the commit aa58a21ae378 ("gpio: pca953x: disable regmap locking") which states the following: This driver uses its own locking but regmap silently uses a mutex for all operations too. Add the option to disable locking to the regmap config struct. Fixes: bcf41dc480b1 ("gpio: pca953x: fix handling of automatic address incrementing") Cc: Uwe Kleine-König Signed-off-by: Andy Shevchenko Reviewed-by: Uwe Kleine-König --- drivers/gpio/gpio-pca953x.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c index 97c9ac31ecb5..6f409ee0b033 100644 --- a/drivers/gpio/gpio-pca953x.c +++ b/drivers/gpio/gpio-pca953x.c @@ -395,6 +395,7 @@ static const struct regmap_config pca953x_ai_i2c_regmap = { .writeable_reg = pca953x_writeable_register, .volatile_reg = pca953x_volatile_register, + .disable_locking = true, .cache_type = REGCACHE_RBTREE, .max_register = 0x7f, };