Message ID | 20231025053833.16014-1-raag.jadav@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:ce89:0:b0:403:3b70:6f57 with SMTP id p9csp2384344vqx; Tue, 24 Oct 2023 22:39:17 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEJ4fZXYjFAPM9PifxpLt/lTN9wvsYcUWJdcmETkpdUJ6IFqcACCcs9i+OAbqA2ee9tWPH6 X-Received: by 2002:a0d:ebc4:0:b0:5a7:be8c:e85 with SMTP id u187-20020a0debc4000000b005a7be8c0e85mr15554786ywe.24.1698212357635; Tue, 24 Oct 2023 22:39:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698212357; cv=none; d=google.com; s=arc-20160816; b=A8t1a/PmaS+JLJXApSHGY11TzcqC/oCX5Oqsf1yepl4zxKNEie0DBIIvrT2lhElHAY zkIA+P5Hjo4T3FAo3B/VqbfscsuTj44spZaWvf0idzMa+ENBQjSGord8j8WblrOSTO0k qwVBjO012nqrM3qy48fTAJl7bUqvYq7cC9kIhHn/kTfyZz/wiaUMFzNDkR7eDR8m8uA9 uqv+XL/NzSOqq+RrF3qon/Ccbii48Z8mQdu/QCD+RqpiIBZboun1jLMWnBqc2/qfS40X yIMe4jJjO2miegFhCQ9TmYtD+AQpEM6VB9VpT4m/UGrh5Q56Ee39/pi/WWyfcWG509aG hSXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from :dkim-signature; bh=ITrKN4d+7d5/1lqm/vHOxrWTGY9R5qp0jslzzkMD3j0=; fh=2xctz/0e/SucHBlfO1OvWtxLt2i80Mg3jU6mKooxmDA=; b=lHrVL5vGxP7zYdFYv7fui/armhWde3SwtUKXeTVj1qvnstqqWHX43VIoN9fdY7dGsL 5nTEMdx3nBgWEA8ncx5V5PXqCPiqHgwzaw+9VfSFz+N2fcAjf3eUTonuWB0EwO4Bh37e //2xuxiiZCqEDdKHiIuNtCWYWjJnRbPP7yzpGuZodWwP9DuCDgitPMi8OPpe7nNEun13 a5ycwTnHKn9YEjRLDuSrqS0xyMGGhOZGsk7QltpOSZn9U0001iEqQD5N8psDGMiBd0yD 0IOgysTjt5dKmBTJc4tlt88nqLpUBRkXn38eBP8EJR6fuuvCoQQcTosyk99u1gKsfxUi MqcQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=GE0fIbM2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 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 pete.vger.email (pete.vger.email. [2620:137:e000::3:6]) by mx.google.com with ESMTPS id x128-20020a814a86000000b005a1cf5ae57csi9313919ywa.472.2023.10.24.22.39.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Oct 2023 22:39:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=GE0fIbM2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 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 pete.vger.email (Postfix) with ESMTP id 46DE28029B50; Tue, 24 Oct 2023 22:39:15 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231254AbjJYFiv (ORCPT <rfc822;aposhian.dev@gmail.com> + 26 others); Wed, 25 Oct 2023 01:38:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53356 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229456AbjJYFit (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 25 Oct 2023 01:38:49 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C479C12A; Tue, 24 Oct 2023 22:38:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1698212327; x=1729748327; h=from:to:cc:subject:date:message-id; bh=zkjMnmvGuvGDKzRPgyPhClkD5mU4/NkRV/n4i7OeNek=; b=GE0fIbM2r8xuUKnAElME65i5gfGxjeA1Dpb+leLT8nPZXZVHUz43La+w 5Gwp/YkG9KqzIEXOUaUQFEaeh7iLAUQIdRSxUtP1AFZbEhXgUdNAlFjRs i/LBCxZ3ufpjCGw1Ny5DAUa9fk3ATtEf36hk/X9AHjSbyIkXsuagKgPi/ TqBHfJzzEDgikYL585qHPHNF+qjpUaTRzIC3aE5+oMRO+PX/CT3T1VNHu rgp43i7gL+CbL+3O1xybJm+XABDGDl5ERq39CdFpzrL5r+i2cNQwwVeBh +NXhDX4cSvj9VSI89ibRkGnYn3R/l0zgnNQ9BpoLzvmhkfp/9HdT+dVT0 g==; X-IronPort-AV: E=McAfee;i="6600,9927,10873"; a="390096231" X-IronPort-AV: E=Sophos;i="6.03,249,1694761200"; d="scan'208";a="390096231" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Oct 2023 22:38:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10873"; a="793753056" X-IronPort-AV: E=Sophos;i="6.03,249,1694761200"; d="scan'208";a="793753056" Received: from inlubt0316.iind.intel.com ([10.191.20.213]) by orsmga001.jf.intel.com with ESMTP; 24 Oct 2023 22:38:44 -0700 From: Raag Jadav <raag.jadav@intel.com> To: rafael@kernel.org, len.brown@intel.com, mika.westerberg@linux.intel.com, andriy.shevchenko@linux.intel.com Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, mallikarjunappa.sangannavar@intel.com, bala.senthil@intel.com, Raag Jadav <raag.jadav@intel.com> Subject: [PATCH v1] ACPI: LPSS: use acpi_dev_uid_match() for matching _UID Date: Wed, 25 Oct 2023 11:08:33 +0530 Message-Id: <20231025053833.16014-1-raag.jadav@intel.com> X-Mailer: git-send-email 2.17.1 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 pete.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 (pete.vger.email [0.0.0.0]); Tue, 24 Oct 2023 22:39:15 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780704720722812531 X-GMAIL-MSGID: 1780704720722812531 |
Series |
[v1] ACPI: LPSS: use acpi_dev_uid_match() for matching _UID
|
|
Commit Message
Raag Jadav
Oct. 25, 2023, 5:38 a.m. UTC
Use acpi_dev_uid_match() for matching _UID instead of treating it
as an integer.
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
---
drivers/acpi/acpi_lpss.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
base-commit: 72d54941cd56ac3fedca6f7ae00a300b33ead29e
Comments
On Wed, Oct 25, 2023 at 11:08:33AM +0530, Raag Jadav wrote: > Use acpi_dev_uid_match() for matching _UID instead of treating it > as an integer. > > Signed-off-by: Raag Jadav <raag.jadav@intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
On Wed, Oct 25, 2023 at 7:53 AM Mika Westerberg <mika.westerberg@linux.intel.com> wrote: > > On Wed, Oct 25, 2023 at 11:08:33AM +0530, Raag Jadav wrote: > > Use acpi_dev_uid_match() for matching _UID instead of treating it > > as an integer. > > > > Signed-off-by: Raag Jadav <raag.jadav@intel.com> > > Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> I was about to apply this, but then I realized that it might change the behavior in a subtle way, because what if the _UID string is something like "01"?
On Wed, Oct 25, 2023 at 08:04:44PM +0200, Rafael J. Wysocki wrote: > On Wed, Oct 25, 2023 at 7:53 AM Mika Westerberg > <mika.westerberg@linux.intel.com> wrote: > > > > On Wed, Oct 25, 2023 at 11:08:33AM +0530, Raag Jadav wrote: > > > Use acpi_dev_uid_match() for matching _UID instead of treating it > > > as an integer. > > > > > > Signed-off-by: Raag Jadav <raag.jadav@intel.com> > > > > Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> > > I was about to apply this, but then I realized that it might change > the behavior in a subtle way, because what if the _UID string is > something like "01"? I checked the git history and found below. commit 2a036e489eb1571810126d6fa47bd8af1e237c08 Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: Tue Sep 13 19:31:41 2022 +0300 ACPI: LPSS: Refactor _UID handling to use acpi_dev_uid_to_integer() ACPI utils provide acpi_dev_uid_to_integer() helper to extract _UID as an integer. Use it instead of custom approach. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c index c4d4d21391d7..4d415e210c32 100644 --- a/drivers/acpi/acpi_lpss.c +++ b/drivers/acpi/acpi_lpss.c @@ -167,10 +167,10 @@ static struct pwm_lookup byt_pwm_lookup[] = { static void byt_pwm_setup(struct lpss_private_data *pdata) { - struct acpi_device *adev = pdata->adev; + u64 uid; /* Only call pwm_add_table for the first PWM controller */ - if (!adev->pnp.unique_id || strcmp(adev->pnp.unique_id, "1")) + if (acpi_dev_uid_to_integer(pdata->adev, &uid) || uid != 1) return; pwm_add_table(byt_pwm_lookup, ARRAY_SIZE(byt_pwm_lookup)); So if we consider the original logic with strcmp, which is more inline with acpi_dev_uid_match(), "01" should not be the case here in my opinion. Thanks for sharing your concern though. Raag
On Wed, Oct 25, 2023 at 8:21 PM Raag Jadav <raag.jadav@intel.com> wrote: > > On Wed, Oct 25, 2023 at 08:04:44PM +0200, Rafael J. Wysocki wrote: > > On Wed, Oct 25, 2023 at 7:53 AM Mika Westerberg > > <mika.westerberg@linux.intel.com> wrote: > > > > > > On Wed, Oct 25, 2023 at 11:08:33AM +0530, Raag Jadav wrote: > > > > Use acpi_dev_uid_match() for matching _UID instead of treating it > > > > as an integer. > > > > > > > > Signed-off-by: Raag Jadav <raag.jadav@intel.com> > > > > > > Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> > > > > I was about to apply this, but then I realized that it might change > > the behavior in a subtle way, because what if the _UID string is > > something like "01"? > > I checked the git history and found below. > > commit 2a036e489eb1571810126d6fa47bd8af1e237c08 > Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > Date: Tue Sep 13 19:31:41 2022 +0300 > > ACPI: LPSS: Refactor _UID handling to use acpi_dev_uid_to_integer() > > ACPI utils provide acpi_dev_uid_to_integer() helper to extract _UID as > an integer. Use it instead of custom approach. > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > Reviewed-by: Hans de Goede <hdegoede@redhat.com> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c > index c4d4d21391d7..4d415e210c32 100644 > --- a/drivers/acpi/acpi_lpss.c > +++ b/drivers/acpi/acpi_lpss.c > @@ -167,10 +167,10 @@ static struct pwm_lookup byt_pwm_lookup[] = { > > static void byt_pwm_setup(struct lpss_private_data *pdata) > { > - struct acpi_device *adev = pdata->adev; > + u64 uid; > > /* Only call pwm_add_table for the first PWM controller */ > - if (!adev->pnp.unique_id || strcmp(adev->pnp.unique_id, "1")) > + if (acpi_dev_uid_to_integer(pdata->adev, &uid) || uid != 1) > return; > > pwm_add_table(byt_pwm_lookup, ARRAY_SIZE(byt_pwm_lookup)); > > So if we consider the original logic with strcmp, which is more inline > with acpi_dev_uid_match(), "01" should not be the case here in my opinion. > > Thanks for sharing your concern though. Well, this means that what the patch really does is to effectively revert commit 2a036e489eb1571810126d6fa47bd8af1e237c08 and use the new helper instead of the open-coded check that was there before, so all of this information should be present in the changelog.
On Wed, Oct 25, 2023 at 11:08:33AM +0530, Raag Jadav wrote: > Use acpi_dev_uid_match() for matching _UID instead of treating it > as an integer. NAK. See below why. ... > static void byt_pwm_setup(struct lpss_private_data *pdata) > { > - u64 uid; > - > /* Only call pwm_add_table for the first PWM controller */ > - if (acpi_dev_uid_to_integer(pdata->adev, &uid) || uid != 1) > + if (!acpi_dev_uid_match(pdata->adev, "1")) _UID by specification is a type of _string_. Yet, that string may represent an integer number. Now, how many variants of the strings can you imagine that may be interpreted as integer 1? I can tell about dozens. With your change you restricted the all possible spectre of the 1 representations to a single one. Have you checked ALL of the DSDTs for these platforms to say 'hey, all current tables uses "1" and this is not an issue'? Further question, will you guarantee that new platforms on this chip won't use something different? (Not that big issue, but will require to actively revert your change in the future). > return; > > pwm_add_table(byt_pwm_lookup, ARRAY_SIZE(byt_pwm_lookup)); > @@ -218,10 +216,8 @@ static struct pwm_lookup bsw_pwm_lookup[] = { > > static void bsw_pwm_setup(struct lpss_private_data *pdata) > { > - u64 uid; > - > /* Only call pwm_add_table for the first PWM controller */ > - if (acpi_dev_uid_to_integer(pdata->adev, &uid) || uid != 1) > + if (!acpi_dev_uid_match(pdata->adev, "1")) > return;
On Wed, Oct 25, 2023 at 11:33:40PM +0300, Andy Shevchenko wrote: > On Wed, Oct 25, 2023 at 11:08:33AM +0530, Raag Jadav wrote: > > Use acpi_dev_uid_match() for matching _UID instead of treating it > > as an integer. > > NAK. See below why. > > ... > > > static void byt_pwm_setup(struct lpss_private_data *pdata) > > { > > - u64 uid; > > - > > /* Only call pwm_add_table for the first PWM controller */ > > - if (acpi_dev_uid_to_integer(pdata->adev, &uid) || uid != 1) > > + if (!acpi_dev_uid_match(pdata->adev, "1")) > > _UID by specification is a type of _string_. Yet, that string may represent an > integer number. Now, how many variants of the strings can you imagine that may > be interpreted as integer 1? I can tell about dozens. > > With your change you restricted the all possible spectre of the 1 > representations to a single one. Have you checked ALL of the DSDTs > for these platforms to say 'hey, all current tables uses "1" and > this is not an issue'? I'm not sure if I'm following you, this would basically invalidate every usage of acpi_dev_hid_uid_match() helper across the driver. Raag
On Thu, Oct 26, 2023 at 06:00:25AM +0300, Raag Jadav wrote: > On Wed, Oct 25, 2023 at 11:33:40PM +0300, Andy Shevchenko wrote: > > On Wed, Oct 25, 2023 at 11:08:33AM +0530, Raag Jadav wrote: ... > > > static void byt_pwm_setup(struct lpss_private_data *pdata) > > > { > > > - u64 uid; > > > - > > > /* Only call pwm_add_table for the first PWM controller */ > > > - if (acpi_dev_uid_to_integer(pdata->adev, &uid) || uid != 1) > > > + if (!acpi_dev_uid_match(pdata->adev, "1")) > > > > _UID by specification is a type of _string_. Yet, that string may represent an > > integer number. Now, how many variants of the strings can you imagine that may > > be interpreted as integer 1? I can tell about dozens. > > > > With your change you restricted the all possible spectre of the 1 > > representations to a single one. Have you checked ALL of the DSDTs > > for these platforms to say 'hey, all current tables uses "1" and > > this is not an issue'? > > I'm not sure if I'm following you, this would basically invalidate every > usage of acpi_dev_hid_uid_match() helper across the driver. It depends.
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c index 875de44961bf..6aaa6b066510 100644 --- a/drivers/acpi/acpi_lpss.c +++ b/drivers/acpi/acpi_lpss.c @@ -167,10 +167,8 @@ static struct pwm_lookup byt_pwm_lookup[] = { static void byt_pwm_setup(struct lpss_private_data *pdata) { - u64 uid; - /* Only call pwm_add_table for the first PWM controller */ - if (acpi_dev_uid_to_integer(pdata->adev, &uid) || uid != 1) + if (!acpi_dev_uid_match(pdata->adev, "1")) return; pwm_add_table(byt_pwm_lookup, ARRAY_SIZE(byt_pwm_lookup)); @@ -218,10 +216,8 @@ static struct pwm_lookup bsw_pwm_lookup[] = { static void bsw_pwm_setup(struct lpss_private_data *pdata) { - u64 uid; - /* Only call pwm_add_table for the first PWM controller */ - if (acpi_dev_uid_to_integer(pdata->adev, &uid) || uid != 1) + if (!acpi_dev_uid_match(pdata->adev, "1")) return; pwm_add_table(bsw_pwm_lookup, ARRAY_SIZE(bsw_pwm_lookup));