From patchwork Thu Mar 23 19:46:14 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andy Shevchenko X-Patchwork-Id: 9641881 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 791F3602D6 for ; Thu, 23 Mar 2017 19:48:24 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 696AB2833B for ; Thu, 23 Mar 2017 19:48:24 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5DFBE2840E; Thu, 23 Mar 2017 19:48:24 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DF5D32833B for ; Thu, 23 Mar 2017 19:48:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933679AbdCWTsG (ORCPT ); Thu, 23 Mar 2017 15:48:06 -0400 Received: from mga11.intel.com ([192.55.52.93]:4433 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933031AbdCWTsF (ORCPT ); Thu, 23 Mar 2017 15:48:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1490298484; x=1521834484; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=FUw7pOaNocMpOZkkDbJntSzniI72fO24Mlgnjt0kgfc=; b=NobKhlkCMBJFKm4PRV0A9YMIVUufwxD8QHpMDt7Km0Wco5Y4OA6VSHXQ vhsAK5+NMnEg1e6KBsF0ghtZUam6Hg==; Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Mar 2017 12:47:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,211,1486454400"; d="scan'208";a="1146202191" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga002.fm.intel.com with ESMTP; 23 Mar 2017 12:47:50 -0700 Received: by black.fi.intel.com (Postfix, from userid 1003) id 8D9AE239; Thu, 23 Mar 2017 21:46:19 +0200 (EET) From: Andy Shevchenko To: Linus Walleij , Alexandre Courbot , linux-gpio@vger.kernel.org, Dmitry Torokhov , Hans de Goede , linux-kernel@vger.kernel.org, Mika Westerberg , Jarkko Nikula , linux-acpi@vger.kernel.org Cc: Andy Shevchenko Subject: [PATCH v1 4/8] gpio: acpi: Even more tighten up ACPI GPIO lookups Date: Thu, 23 Mar 2017 21:46:14 +0200 Message-Id: <20170323194618.26548-5-andriy.shevchenko@linux.intel.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20170323194618.26548-1-andriy.shevchenko@linux.intel.com> References: <20170323194618.26548-1-andriy.shevchenko@linux.intel.com> Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The commit 10cf4899f8af ("gpiolib: tighten up ACPI legacy gpio lookups") prevents to getting same resource twice if the driver asks twice using same connection ID. But the whole idea of fallback might bring some problems. Imagine the case when we have two versions of BIOS/hardware where in one _DSD is introduced along with GPIO resources, but the other one uses just plain GPIO resource for another purpose Case 1: Device (DEVX) { ... Name (_CRS, ResourceTemplate () { GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly, "\\_SB.GPO0", 0, ResourceConsumer) {15} }) Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () {"some-gpios", Package() {^DEVX, 0, 0, 0 }}, } }) } Case 2: Device (DEVX) { ... Name (_CRS, ResourceTemplate () { GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly, "\\_SB.GPO0", 0, ResourceConsumer) {27} }) } To prevent the possible misconfiguration tighten up even more ACPI GPIO lookups for case without connection ID provided. In the past the issue had been triggered by "use mctrl_gpio helpers" series [1,2]. Besides above, removal of the main logic of acpi_can_fallback_to_crs() eliminates a potential memory leak when the same device has been unbound and bound again. [1] commit 4ef03d328769 ("tty/serial/8250: use mctrl_gpio helpers") [2] https://patchwork.kernel.org/patch/9283745/ Cc: Dmitry Torokhov Signed-off-by: Andy Shevchenko --- drivers/gpio/gpiolib-acpi.c | 36 +----------------------------------- 1 file changed, 1 insertion(+), 35 deletions(-) diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c index 21e4930ca2db..e516b7a0cc50 100644 --- a/drivers/gpio/gpiolib-acpi.c +++ b/drivers/gpio/gpiolib-acpi.c @@ -1121,45 +1121,11 @@ int acpi_gpio_count(struct device *dev, const char *con_id) return count ? count : -ENOENT; } -struct acpi_crs_lookup { - struct list_head node; - struct acpi_device *adev; - const char *con_id; -}; - -static DEFINE_MUTEX(acpi_crs_lookup_lock); -static LIST_HEAD(acpi_crs_lookup_list); - bool acpi_can_fallback_to_crs(struct acpi_device *adev, const char *con_id) { - struct acpi_crs_lookup *l, *lookup = NULL; - /* Never allow fallback if the device has properties */ if (adev->data.properties || adev->driver_gpios) return false; - mutex_lock(&acpi_crs_lookup_lock); - - list_for_each_entry(l, &acpi_crs_lookup_list, node) { - if (l->adev == adev) { - lookup = l; - break; - } - } - - if (!lookup) { - lookup = kmalloc(sizeof(*lookup), GFP_KERNEL); - if (lookup) { - lookup->adev = adev; - lookup->con_id = kstrdup(con_id, GFP_KERNEL); - list_add_tail(&lookup->node, &acpi_crs_lookup_list); - } - } - - mutex_unlock(&acpi_crs_lookup_lock); - - return lookup && - ((!lookup->con_id && !con_id) || - (lookup->con_id && con_id && - strcmp(lookup->con_id, con_id) == 0)); + return con_id == NULL; }