From patchwork Tue May 23 17:03:20 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andy Shevchenko X-Patchwork-Id: 766107 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3wXMMv4NSKz9sPD for ; Wed, 24 May 2017 03:04:59 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761631AbdEWREN (ORCPT ); Tue, 23 May 2017 13:04:13 -0400 Received: from mga14.intel.com ([192.55.52.115]:43189 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1764841AbdEWREK (ORCPT ); Tue, 23 May 2017 13:04:10 -0400 Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 May 2017 10:04:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,382,1491289200"; d="scan'208";a="972170251" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga003.jf.intel.com with ESMTP; 23 May 2017 10:04:02 -0700 Received: by black.fi.intel.com (Postfix, from userid 1003) id 42DD321A; Tue, 23 May 2017 20:03:28 +0300 (EEST) From: Andy Shevchenko To: Linus Walleij , linux-gpio@vger.kernel.org, Dmitry Torokhov , Hans de Goede , linux-kernel@vger.kernel.org, "Rafael J. Wysocki" , linux-acpi@vger.kernel.org, Mika Westerberg , Jarkko Nikula , Jagadish Krishnamoorthy Cc: Andy Shevchenko Subject: [PATCH v2 05/12] gpio: acpi: Synchronize acpi_find_gpio() and acpi_gpio_count() Date: Tue, 23 May 2017 20:03:20 +0300 Message-Id: <20170523170327.18055-6-andriy.shevchenko@linux.intel.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20170523170327.18055-1-andriy.shevchenko@linux.intel.com> References: <20170523170327.18055-1-andriy.shevchenko@linux.intel.com> Sender: linux-gpio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org If we pass connection ID to the both functions and at the same time acpi_can_fallback_to_crs() returns false we will get different results, i.e. the number of GPIO resources returned by acpi_gpio_count() might be not correct. Fix this by calling acpi_can_fallback_to_crs() in acpi_gpio_count() before trying to fallback. Signed-off-by: Andy Shevchenko Tested-by: Jarkko Nikula Reviewed-by: Mika Westerberg --- drivers/gpio/gpiolib-acpi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c index 0392d8ed332f..740df0e9dcb3 100644 --- a/drivers/gpio/gpiolib-acpi.c +++ b/drivers/gpio/gpiolib-acpi.c @@ -1119,6 +1119,9 @@ int acpi_gpio_count(struct device *dev, const char *con_id) struct list_head resource_list; unsigned int crs_count = 0; + if (!acpi_can_fallback_to_crs(adev, con_id)) + return count; + INIT_LIST_HEAD(&resource_list); acpi_dev_get_resources(adev, &resource_list, acpi_find_gpio_count, &crs_count);