Message ID | 20231020084732.17130-5-raag.jadav@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2010:b0:403:3b70:6f57 with SMTP id fe16csp913756vqb; Fri, 20 Oct 2023 01:48:48 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEi20cSF5ZjzkBLRRlwOXnQyhcLSOtOJTa24JPtCxFk4VRgoNLmnrmIcJXK2NL8j1yRs/jh X-Received: by 2002:a17:90b:1098:b0:27d:54b9:c3d4 with SMTP id gj24-20020a17090b109800b0027d54b9c3d4mr1303185pjb.1.1697791728060; Fri, 20 Oct 2023 01:48:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697791728; cv=none; d=google.com; s=arc-20160816; b=ZMqEyBERrjYAFHBAyvyd/Puv9IAPLLjLIsbeScp4sjtiLFEK+h3XO+lb/uUM46HQIV HRfktx1R38iZs0MxN+jrOs0B9oAvwcHxBt7wyAWpvVUuI2BFYTZ+a9axpR1Zstfdwqbh 12+3nwITfTvA4GFhjGZ2xX6I/6zg0Iw5PdAwHpF075uMKN6uEagkwUgfXBYs60VXHf5f YiSqvtcx6NINI18Mqq3eAaCGpPUYbi7EHNv4pPV+Nyams3veYzNZaYGlxNWi7EQFKYJQ sLvRbJycoo7jKZ9ROkRJbH4kOHZDWlIQSR/0JHESUPn2Wh3MOdkFu8eATu9zUHADuzUS Kz5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from:dkim-signature; bh=kYa/xpwnZCtEe037BAOyBsZeRgBEad5iTJirNwI+95Y=; fh=WAU8dvHbCVEKt7PKP55MCP59DfghQ92mfS2Ma7uEses=; b=hCml0qsnG5TajUofjwDfHhICJzqr/gE0ksAuSsBsveE5JcuBhMoqBgLbvS4RGk2Cre MC7WiyXLLt3oqFZ0IVZjBqjngq62zmxRj1F6tTvnxv8+N4rdFEl//9w2dDNTjZUaRxzE EQkZRpP9MdOPMF+aPj5f8sDZ8YEsCsONxK8Oiy5htlSx9TkCT19EziGPGMRl82TimZgS uCVA01ei/Q6/LhKbUcr34Pm37WtjvtKW+G8peMT95IvAV9sUDj2bEgT3brn/LPEtOOVb 9E5w2eOV8btFulcyH9XV8vJo+m8TBXGffCIYotNfrCCsRNXxIoydDwaLGs/lZkCwMvID wJwQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=DGUfNDHy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from agentk.vger.email (agentk.vger.email. [2620:137:e000::3:2]) by mx.google.com with ESMTPS id kk2-20020a17090b4a0200b0026b51ae4574si4493202pjb.36.2023.10.20.01.48.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Oct 2023 01:48:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=DGUfNDHy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 3AC9281F853F; Fri, 20 Oct 2023 01:48:43 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376561AbjJTIs1 (ORCPT <rfc822;lkml4gm@gmail.com> + 25 others); Fri, 20 Oct 2023 04:48:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33928 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376523AbjJTIsP (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 20 Oct 2023 04:48:15 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C69FED52; Fri, 20 Oct 2023 01:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697791693; x=1729327693; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=ycYM//IBzYahr1OT+k/0SqcANs76449DXAt6/AuLX9M=; b=DGUfNDHyfUwZk67l/7ienlCmcACFM+T7a4497ecipvcMGwx61kTH96cj hjnCzgj9WGBuqM+LFN8O8o3+9/xOkEF2BA+lTCQnVDWD7hcve1H7IGHLI nLK7P48ZxPFlyKsutg+LrQgjACIV7Caxs6wZNmXM5vi0MKPZQbrEhQd/W Q8CYhzQeRCI96r5vfj5wRaj9L8v60Swjwd1o024ecpzsmjufeA/421ZF0 RGn0sW/HRZCp7U0/Sj+wR41rZlQ3XVciY8XDuSsrJGK3K/ygaQOI3r3Js 5U9Pfiy1CSvrtUs17fxQ7GO5GaXDwckDTfuFNsyGTe0ByS2544JgchEqI Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10868"; a="450683524" X-IronPort-AV: E=Sophos;i="6.03,238,1694761200"; d="scan'208";a="450683524" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Oct 2023 01:48:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10868"; a="873832171" X-IronPort-AV: E=Sophos;i="6.03,238,1694761200"; d="scan'208";a="873832171" Received: from inlubt0316.iind.intel.com ([10.191.20.213]) by fmsmga002.fm.intel.com with ESMTP; 20 Oct 2023 01:48:01 -0700 From: Raag Jadav <raag.jadav@intel.com> To: rafael@kernel.org, len.brown@intel.com, robert.moore@intel.com, mika.westerberg@linux.intel.com, andriy.shevchenko@linux.intel.com, mark.rutland@arm.com, will@kernel.org, linux@roeck-us.net Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, acpica-devel@lists.linuxfoundation.org, linux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-hwmon@vger.kernel.org, mallikarjunappa.sangannavar@intel.com, bala.senthil@intel.com, Raag Jadav <raag.jadav@intel.com> Subject: [PATCH v1 4/8] ACPI: utils: use acpi_dev_uid_match() for matching _UID Date: Fri, 20 Oct 2023 14:17:28 +0530 Message-Id: <20231020084732.17130-5-raag.jadav@intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20231020084732.17130-1-raag.jadav@intel.com> References: <20231020084732.17130-1-raag.jadav@intel.com> X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Fri, 20 Oct 2023 01:48:43 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780263658796646805 X-GMAIL-MSGID: 1780263658796646805 |
Series |
Refine _UID references across kernel
|
|
Commit Message
Raag Jadav
Oct. 20, 2023, 8:47 a.m. UTC
Convert manual _UID references to use standard ACPI helpers.
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
---
drivers/acpi/utils.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Comments
On Fri, Oct 20, 2023 at 02:17:28PM +0530, Raag Jadav wrote: > Convert manual _UID references to use standard ACPI helpers. Yes, while not so obvious this is the correct replacement. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
On Fri, Oct 20, 2023 at 01:36:27PM +0300, Andy Shevchenko wrote: > On Fri, Oct 20, 2023 at 02:17:28PM +0530, Raag Jadav wrote: > > Convert manual _UID references to use standard ACPI helpers. > > Yes, while not so obvious this is the correct replacement. > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> I think this is the only case which would suffer from the more obvious behaviour, i.e. bool acpi_dev_uid_match(struct acpi_device *adev, const char *uid2) { const char *uid1 = acpi_device_uid(adev); return uid1 && uid2 && !strcmp(uid1, uid2); } That said, we can't be particularly sure about it's potential future users, especially when the usage will not be limited to just ACPI core since we're exporting it. Raag
On Fri, Oct 20, 2023 at 02:38:06PM +0300, Raag Jadav wrote: > On Fri, Oct 20, 2023 at 01:36:27PM +0300, Andy Shevchenko wrote: > > On Fri, Oct 20, 2023 at 02:17:28PM +0530, Raag Jadav wrote: > > > Convert manual _UID references to use standard ACPI helpers. > > > > Yes, while not so obvious this is the correct replacement. > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > I think this is the only case which would suffer from the more obvious > behaviour, i.e. No, that's not true. The same with override CPU in the other patch, where the check is simply absent, but the result will be the same. So, all with negation will suffer from the "obvious" implementation. > bool acpi_dev_uid_match(struct acpi_device *adev, const char *uid2) > { > const char *uid1 = acpi_device_uid(adev); > > return uid1 && uid2 && !strcmp(uid1, uid2); > } > > That said, we can't be particularly sure about it's potential future users, > especially when the usage will not be limited to just ACPI core since we're > exporting it.
On Fri, Oct 20, 2023 at 04:42:08PM +0300, Andy Shevchenko wrote: > On Fri, Oct 20, 2023 at 02:38:06PM +0300, Raag Jadav wrote: > > On Fri, Oct 20, 2023 at 01:36:27PM +0300, Andy Shevchenko wrote: > > > On Fri, Oct 20, 2023 at 02:17:28PM +0530, Raag Jadav wrote: > > > > Convert manual _UID references to use standard ACPI helpers. > > > > > > Yes, while not so obvious this is the correct replacement. > > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > > > I think this is the only case which would suffer from the more obvious > > behaviour, i.e. > > No, that's not true. The same with override CPU in the other patch, where the > check is simply absent, but the result will be the same. So, all with negation > will suffer from the "obvious" implementation. Forgot to add, we don't need to change the original acpi_dev_hid_uid_match() behaviour, i.e. bool acpi_dev_hid_uid_match(struct acpi_device *adev, const char *hid2, const char *uid2) { const char *hid1 = acpi_device_hid(adev); if (strcmp(hid1, hid2)) return false; if (!uid2) return true; return acpi_dev_uid_match(adev, uid2); } I'm fine with both, this just makes more sense to me. Raag
On Fri, Oct 20, 2023 at 1:38 PM Raag Jadav <raag.jadav@intel.com> wrote: > > On Fri, Oct 20, 2023 at 01:36:27PM +0300, Andy Shevchenko wrote: > > On Fri, Oct 20, 2023 at 02:17:28PM +0530, Raag Jadav wrote: > > > Convert manual _UID references to use standard ACPI helpers. > > > > Yes, while not so obvious this is the correct replacement. > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > I think this is the only case which would suffer from the more obvious > behaviour, i.e. > > bool acpi_dev_uid_match(struct acpi_device *adev, const char *uid2) > { > const char *uid1 = acpi_device_uid(adev); > > return uid1 && uid2 && !strcmp(uid1, uid2); > } > > That said, we can't be particularly sure about it's potential future users, > especially when the usage will not be limited to just ACPI core since we're > exporting it. I actually agree with this, so please switch over to the above. The above is straightforward and easy to understand and if somebody wants to treat uid2 == NULL as a match, let them check that explicitly before calling this function.
On Fri, Oct 20, 2023 at 07:11:53PM +0200, Rafael J. Wysocki wrote: > On Fri, Oct 20, 2023 at 1:38 PM Raag Jadav <raag.jadav@intel.com> wrote: > > > > On Fri, Oct 20, 2023 at 01:36:27PM +0300, Andy Shevchenko wrote: > > > On Fri, Oct 20, 2023 at 02:17:28PM +0530, Raag Jadav wrote: > > > > Convert manual _UID references to use standard ACPI helpers. > > > > > > Yes, while not so obvious this is the correct replacement. > > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > > > I think this is the only case which would suffer from the more obvious > > behaviour, i.e. > > > > bool acpi_dev_uid_match(struct acpi_device *adev, const char *uid2) > > { > > const char *uid1 = acpi_device_uid(adev); > > > > return uid1 && uid2 && !strcmp(uid1, uid2); > > } > > > > That said, we can't be particularly sure about it's potential future users, > > especially when the usage will not be limited to just ACPI core since we're > > exporting it. > > I actually agree with this, so please switch over to the above. Will send out a v2, thanks. Andy, can I add your review for this? Raag
On Fri, Oct 20, 2023 at 09:11:56PM +0300, Raag Jadav wrote: > On Fri, Oct 20, 2023 at 07:11:53PM +0200, Rafael J. Wysocki wrote: > > On Fri, Oct 20, 2023 at 1:38 PM Raag Jadav <raag.jadav@intel.com> wrote: > > > > > > On Fri, Oct 20, 2023 at 01:36:27PM +0300, Andy Shevchenko wrote: > > > > On Fri, Oct 20, 2023 at 02:17:28PM +0530, Raag Jadav wrote: > > > > > Convert manual _UID references to use standard ACPI helpers. > > > > > > > > Yes, while not so obvious this is the correct replacement. > > > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > > > > > I think this is the only case which would suffer from the more obvious > > > behaviour, i.e. > > > > > > bool acpi_dev_uid_match(struct acpi_device *adev, const char *uid2) > > > { > > > const char *uid1 = acpi_device_uid(adev); > > > > > > return uid1 && uid2 && !strcmp(uid1, uid2); > > > } > > > > > > That said, we can't be particularly sure about it's potential future users, > > > especially when the usage will not be limited to just ACPI core since we're > > > exporting it. > > > > I actually agree with this, so please switch over to the above. > > Will send out a v2, thanks. > > Andy, can I add your review for this? IIUC you agree with the usage format, but not the actual helper. So I'm gonna drop it from the first patch and keep it for the rest, except this one. Let me know if I'm doing this wrong. Raag
diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c index 664b9890b625..e3ba835e6590 100644 --- a/drivers/acpi/utils.c +++ b/drivers/acpi/utils.c @@ -889,8 +889,7 @@ static int acpi_dev_match_cb(struct device *dev, const void *data) if (acpi_match_device_ids(adev, match->hid)) return 0; - if (match->uid && (!adev->pnp.unique_id || - strcmp(adev->pnp.unique_id, match->uid))) + if (!acpi_dev_uid_match(adev, match->uid)) return 0; if (match->hrv == -1)