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 A340DC54E94 for ; Wed, 25 Jan 2023 15:21:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235678AbjAYPV6 (ORCPT ); Wed, 25 Jan 2023 10:21:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46252 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234862AbjAYPVy (ORCPT ); Wed, 25 Jan 2023 10:21:54 -0500 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6D68C18AA8; Wed, 25 Jan 2023 07:21:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1674660113; x=1706196113; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=wK3p8oOR9HlAtXRXux6KGj539I6sXbcsgCvp9ZNibfE=; b=EQxme39ZAQy07Jr8nr1e3BuAh0m0vmWpSm9l3mptGDvW9DJYabb1AM6I kKe8br9qXIp9y+Kt0N6KETBEKKJsb4A9KvvetBrW301qgN3IexZT7eDWm m4wg90VhVvgF8zC3/CqxsRFuSGu02USMmhshdjS2UVs5KqzunGf0aCCHB yGls6pgYeutJLEsWYFcL2e4LejIi2yn9oA3v5Kw0utYU5fS8regpfvRGU uprYVLqs80Zw7OTixwJgUIhysulVFr9pY57fNaGlxcSwINyUf8mdsERyg C8AVbIAkOFlZIKCbcPHE1gX7EgEtnnv9nWvpZBWpgz3CIRVsOspqfbOQF g==; X-IronPort-AV: E=McAfee;i="6500,9779,10601"; a="412811035" X-IronPort-AV: E=Sophos;i="5.97,245,1669104000"; d="scan'208";a="412811035" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jan 2023 07:21:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10601"; a="612455983" X-IronPort-AV: E=Sophos;i="5.97,245,1669104000"; d="scan'208";a="612455983" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga003.jf.intel.com with ESMTP; 25 Jan 2023 07:21:50 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1pKhau-00Eupa-2F; Wed, 25 Jan 2023 17:21:48 +0200 Date: Wed, 25 Jan 2023 17:21:48 +0200 From: Andy Shevchenko To: Hans de Goede , "Rafael J. Wysocki" , linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, acpica-devel@lists.linuxfoundation.org Cc: "Rafael J. Wysocki" , Len Brown , Robert Moore Subject: Re: [PATCH v1 2/3] ACPI: utils: Add acpi_get_first_match_physical_node() Message-ID: References: <20230123171006.58274-1-andriy.shevchenko@linux.intel.com> <20230123171006.58274-2-andriy.shevchenko@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230123171006.58274-2-andriy.shevchenko@linux.intel.com> 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, Jan 23, 2023 at 07:10:05PM +0200, Andy Shevchenko wrote: > There are drivers that are using a logic that is combined in the offered > acpi_get_first_match_physical_node(). The rationale to have this helper > not only redunction of the lines of code, but improving the robustness > by properly handling the reference counters on the error paths. After rebasing on top of the latest code base (with Hans' patches included) I checked the users of similar code flow and found that there is no sense to provide this helper now. It's only one user for this API as is, otherwise it needs an access to struct acpi_device, which the proposed API doesn't provide. Hence, self-NAK. -- With Best Regards, Andy Shevchenko