Received: by 2002:ab2:6a05:0:b0:1f8:1780:a4ed with SMTP id w5csp550129lqo; Fri, 10 May 2024 07:46:31 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCXmLfJlZLS8ypo/3yDpPyxnxIIH/hOpY59/VlcMLh0/FZ7GF+cYk1wVfFAH94XplMMK8sPatVVa6lp60jFD1l7qqzh+mMqXZ+0W6Uytiw== X-Google-Smtp-Source: AGHT+IFu6eXORWGeNGbMXLWkTZsIMbeCNivMEMFh8YbAgpgWlZ5a44TLatCPb/PNCRsKRAO9U2jo X-Received: by 2002:a50:cdd5:0:b0:570:38a:57ea with SMTP id 4fb4d7f45d1cf-5734d67ab20mr1980269a12.33.1715352391206; Fri, 10 May 2024 07:46:31 -0700 (PDT) Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id 4fb4d7f45d1cf-5733beaccfdsi2188893a12.112.2024.05.10.07.46.31 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 May 2024 07:46:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-175916-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@intel.com header.s=Intel header.b=e6M65UEp; arc=fail (body hash mismatch); spf=pass (google.com: domain of linux-kernel+bounces-175916-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-175916-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id E9E501F25604 for ; Fri, 10 May 2024 14:46:30 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3ADBF171088; Fri, 10 May 2024 14:46:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=intel.com header.i=@intel.com header.b="e6M65UEp" Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DA00B168AFC; Fri, 10 May 2024 14:46:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.19 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715352381; cv=none; b=i+BqwmF1bQL5F55Lg9Pvi/m7xHWjEhnPCgyRCXgIv/SIOFJoPfiiQLDqm2/JWKka0NQpvb+hARuwSDLDqsLMj4bo2DGLyD8Ww2a58OOkkwpCzoNYhEl5S0dTJgPsIYIhmglh3WpZRgXqzo1glWcX8q2z8LcIPCotr8AjQFZbIZo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715352381; c=relaxed/simple; bh=PiJqpHpxECsvIuqM1iLqQKFUGF/+tlUVyGz3yiigaxc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=eN4QDnp+cxd8vvqkvT9xCA5Mms3qj0PN6JlqQAUcdNGmGDzuw443iTMk3V5xbwF9xQq5rrFU26usFXLTFZX9geiZMxWNG8GuZOYADScrABzTbMFFXgGYqR4LI/4b9ir5CLBBtjsua+CBY8CgFHtUi7jtxrHNgv0tVtS/00leelI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=e6M65UEp; arc=none smtp.client-ip=198.175.65.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1715352380; x=1746888380; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=PiJqpHpxECsvIuqM1iLqQKFUGF/+tlUVyGz3yiigaxc=; b=e6M65UEpiVRZGk0vyMlIXzGZUZKg6wH/jXjxK2BE7w7J4vp2bJt0c/7m IXqdspOLU7ReSCBVN8yIupzT9f+RjgWaaUul5sXjXCbqcqngkrVt+wW9N 4FCLHrHr2GBKRCVBqQf8Q+LKV1PGQ/cXjwBh95OSDjM7/e7FcGapepCvv /kJ47Z0RM6uDiwbHVJwptQcsT+0O+X2rH7Xc22hwZsIqiSNVi1+3+UwmR ei3JjUhMS8yEMTEfKwk0A7TVnMb+aqe1d3DEMcvZuZq97mYdz6QHaX9Qc qgGCpdozTk2a0oZ6eSxe1Ze8Jr1xdwsce5Cqywjyag+vW+mAEqBi+r7F6 w==; X-CSE-ConnectionGUID: kLZfFGoOT6mNfacOOXS0Sg== X-CSE-MsgGUID: kwqZNo8TT6i7RG+TKneDYg== X-IronPort-AV: E=McAfee;i="6600,9927,11068"; a="11186325" X-IronPort-AV: E=Sophos;i="6.08,151,1712646000"; d="scan'208";a="11186325" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 May 2024 07:46:20 -0700 X-CSE-ConnectionGUID: JXtM5Uk0SgKoHE4imzvCnQ== X-CSE-MsgGUID: vDUdxz2dS/2Nxpe5MFM+EQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,151,1712646000"; d="scan'208";a="34284943" Received: from smile.fi.intel.com ([10.237.72.54]) by orviesa003.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 May 2024 07:46:17 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.97) (envelope-from ) id 1s5RVm-000000068IS-1O6i; Fri, 10 May 2024 17:46:14 +0300 Date: Fri, 10 May 2024 17:46:13 +0300 From: Andy Shevchenko To: Laura Nao Cc: mika.westerberg@linux.intel.com, linus.walleij@linaro.org, brgl@bgdev.pl, kernel@collabora.com, linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org, linux-acpi@vger.kernel.org, "kernelci.org bot" Subject: Re: [PATCH] gpiolib: acpi: Add ACPI device NULL check to acpi_can_fallback_to_crs() Message-ID: References: <20240509104605.538274-1-laura.nao@collabora.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240509104605.538274-1-laura.nao@collabora.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo On Thu, May 09, 2024 at 12:46:05PM +0200, Laura Nao wrote: > Check ACPI device for NULL inside acpi_can_fallback_to_crs(), so callers > won't need to. Thank you for the patch, one change seems good to have along this. .. > /* Never allow fallback if the device has properties */ > - if (acpi_dev_has_props(adev) || adev->driver_gpios) > + if (!adev || acpi_dev_has_props(adev) || adev->driver_gpios) Right, since it was adev || _crs() combined. > return false; Now we may remove that check from __acpi_find_gpio(): --- a/drivers/gpio/gpiolib-acpi.c +++ b/drivers/gpio/gpiolib-acpi.c @@ -988,10 +988,10 @@ __acpi_find_gpio(struct fwnode_handle *fwnode, const char *con_id, unsigned int } /* Then from plain _CRS GPIOs */ - if (!adev || !can_fallback) - return ERR_PTR(-ENOENT); + if (can_fallback) + return acpi_get_gpiod_by_index(adev, NULL, idx, info); - return acpi_get_gpiod_by_index(adev, NULL, idx, info); + return ERR_PTR(-ENOENT); } struct gpio_desc *acpi_find_gpio(struct fwnode_handle *fwnode, As a side effect it will make the comment better to understand. With above suggestion applied, feel free to add mine Reviewed-by: Andy Shevchenko You might need to rephrase the commit message to say that "We also move the check in additional to the moving the function call outside of __acpi_find_gpio()." or something similar, up to you. -- With Best Regards, Andy Shevchenko