Message ID | 20230621151652.79579-1-andriy.shevchenko@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp4468984vqr; Wed, 21 Jun 2023 09:00:47 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7ylEDa2nicmojJLxBzMjr79GcYkvXpzivShi71BZIzi14bClEDbA1Fr8BarAmXYO8e9ELU X-Received: by 2002:a17:90a:d996:b0:256:d262:e686 with SMTP id d22-20020a17090ad99600b00256d262e686mr14940563pjv.19.1687363246874; Wed, 21 Jun 2023 09:00:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687363246; cv=none; d=google.com; s=arc-20160816; b=vQA+4q55DumKeLLGnILmbFjMn9GPqxjH5ANbVOK/AiuA3iQee482ARObjIGBZueaby TCR1pCbYUKCaJZ0WybgsNDNb5Knoz9q6eR0TThI2GChhYvWXtj+SX6PqV4GGlumYlJqE pNhS4nYMILgmSOdhF/JuCSbBbOQgIKp+9jFBHZ/fOBRLCPv/Hcz0dujAVaCZb9iltOlD ut1prY8wkVSJgoELwARy+ygsniOlLfJlDxjPR8K6Zk5+WE+N6ujb91BLEmf+k7oz+5iW 7ur1+5i5uR9ehB6FTN0xjuzx5Djfj7DrDOnPT8TSGeS4up/WtRaIPKh+ufxsC9Kgrrp5 UQ1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=m+78IWs0M4APlCqYH+5sy26NI6QM5jPd4CYyajqLXd0=; b=LVbwvCtuUMLFOQDTdUZIS98JfYK3KArQsX1khlAtY/4cUEG+7O5jym1h4iiDbPHfsp nYDPSHi06/Bhoc2+CgheWMp1Fcf3ruNujy4hI2vCXQUuGfaSozfxb0LdkLxlZDj5yNlE BmuNh+k6HRft6+1EPULrcab2nKLM05pkNEmhkigsGHOVDGOB4QdEwbRr3Dh8YnKCcVuO shTsYH0iT20itlsZYFUpGVH4tyIFmp76LgDa+M8c6SbINHqVQ2PgRA8v5eVKMDVNq7PU 4Fh5MDAI5UYyd4yaawNeu0qUQaPUReAxp2pcbvJAmlHOLSvLlyIRiRAcnPHIctRHHgha 5JAg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="l//1jgSk"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j14-20020a17090aeb0e00b0025e81e3e0c1si4271207pjz.187.2023.06.21.09.00.04; Wed, 21 Jun 2023 09:00:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="l//1jgSk"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231243AbjFUPUK (ORCPT <rfc822;maxin.john@gmail.com> + 99 others); Wed, 21 Jun 2023 11:20:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56270 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233356AbjFUPTu (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 21 Jun 2023 11:19:50 -0400 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7B9984C05; Wed, 21 Jun 2023 08:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1687360609; x=1718896609; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=VblY/rm86Nrtd/B1UCaI/PliO/WD8SqNOUgqlsMUt7g=; b=l//1jgSkwfkYX76FIKACDJUB4PKtFBr0f4x/qiTfudQ1nHTreJzfGwI5 FkmFcC4y+u0R3HuXrm9ETdg5Okl4/8qf7+9Imh/tQ20D6gZMq4k9ylANO jxT1aGfvHx2pONaPQhzxPMUtulf3iS5LXlsBSGYbreGiueTgcd5O+QHPA h1q/bIuTputnGbb+7CbD25v7Ynjvib7DQ0HJpiera0TB0AtzRYCCr0+eH qKwpT1ABSKoFJcw90lOpuuFzE080yUIAEm7ustQPgATjA8sHC42D47eDz z1SgqFG/8QcN2/0N74iKeFcuSBmvVW4shLwy+vC+oLxb27eGTwpxwbyzw Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10748"; a="446584489" X-IronPort-AV: E=Sophos;i="6.00,260,1681196400"; d="scan'208";a="446584489" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jun 2023 08:16:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10748"; a="664702531" X-IronPort-AV: E=Sophos;i="6.00,260,1681196400"; d="scan'208";a="664702531" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga003.jf.intel.com with ESMTP; 21 Jun 2023 08:16:44 -0700 Received: by black.fi.intel.com (Postfix, from userid 1003) id 43DDF1FD; Wed, 21 Jun 2023 18:16:55 +0300 (EEST) From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org, acpica-devel@lists.linuxfoundation.org Cc: "Rafael J. Wysocki" <rafael@kernel.org>, Len Brown <lenb@kernel.org>, Andi Shyti <andi.shyti@kernel.org>, Robert Moore <robert.moore@intel.com>, Michael Brunner <michael.brunner@kontron.com> Subject: [PATCH v2 1/2] ACPI: platform: Ignore SMB0001 only when it has resources Date: Wed, 21 Jun 2023 18:16:51 +0300 Message-Id: <20230621151652.79579-1-andriy.shevchenko@linux.intel.com> X-Mailer: git-send-email 2.40.0.1.gaa8946217a0b MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1769328603811384455?= X-GMAIL-MSGID: =?utf-8?q?1769328603811384455?= |
Series |
[v2,1/2] ACPI: platform: Ignore SMB0001 only when it has resources
|
|
Commit Message
Andy Shevchenko
June 21, 2023, 3:16 p.m. UTC
After switching i2c-scmi driver to be a plaform one, it stopped being enumerated on number of Kontron platforms, because it's listed in the forbidden_id_list. To resolve the situation, split the list to generic one and another that holds devices that has to be skipped if and only if they have bogus resources attached (_CRS method returns some). Fixes: 03d4287add6e ("i2c: scmi: Convert to be a platform driver") Closes: https://lore.kernel.org/r/60c1756765b9a3f1eab0dcbd84f59f00fe1caf48.camel@kontron.com Reported-by: Michael Brunner <michael.brunner@kontron.com> Tested-by: Michael Brunner <michael.brunner@kontron.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20230620163534.1042-1-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> --- v2: added tags (Andi, Michael), fixed spelling (Andi) drivers/acpi/acpi_platform.c | 27 +++++++++++++++++++++++++-- 1 file changed, 25 insertions(+), 2 deletions(-)
Comments
On Wed, Jun 21, 2023 at 5:16 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > After switching i2c-scmi driver to be a plaform one, it stopped "platform" > being enumerated on number of Kontron platforms, because it's > listed in the forbidden_id_list. > > To resolve the situation, split the list to generic one and > another that holds devices that has to be skipped if and only "have" > if they have bogus resources attached (_CRS method returns some). > > Fixes: 03d4287add6e ("i2c: scmi: Convert to be a platform driver") > Closes: https://lore.kernel.org/r/60c1756765b9a3f1eab0dcbd84f59f00fe1caf48.camel@kontron.com > Reported-by: Michael Brunner <michael.brunner@kontron.com> > Tested-by: Michael Brunner <michael.brunner@kontron.com> > Reviewed-by: Andi Shyti <andi.shyti@kernel.org> > Link: https://lore.kernel.org/r/20230620163534.1042-1-andriy.shevchenko@linux.intel.com > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > --- > v2: added tags (Andi, Michael), fixed spelling (Andi) > drivers/acpi/acpi_platform.c | 27 +++++++++++++++++++++++++-- > 1 file changed, 25 insertions(+), 2 deletions(-) > > diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c > index fe00a5783f53..089a98bd18bf 100644 > --- a/drivers/acpi/acpi_platform.c > +++ b/drivers/acpi/acpi_platform.c > @@ -19,13 +19,17 @@ > > #include "internal.h" > > +static const struct acpi_device_id forbidden_id_with_resourses[] = { I don't quite like this name and the driver_data field could be used to indicate the need to check the resources. > + {"SMB0001", 0}, /* ACPI SMBUS virtual device */ > + { } > +}; > + > static const struct acpi_device_id forbidden_id_list[] = { > {"ACPI0009", 0}, /* IOxAPIC */ > {"ACPI000A", 0}, /* IOAPIC */ > {"PNP0000", 0}, /* PIC */ > {"PNP0100", 0}, /* Timer */ > {"PNP0200", 0}, /* AT DMA Controller */ > - {"SMB0001", 0}, /* ACPI SMBUS virtual device */ > { } > }; > > @@ -83,6 +87,15 @@ static void acpi_platform_fill_resource(struct acpi_device *adev, > dest->parent = pci_find_resource(to_pci_dev(parent), dest); > } > > +static int acpi_platform_resource_count(struct acpi_resource *ares, void *data) > +{ > + int *count = data; > + > + *count = *count + 1; Why not (*count)++? > + > + return 1; > +} > + > /** > * acpi_create_platform_device - Create platform device for ACPI device node > * @adev: ACPI device node to create a platform device for. > @@ -103,7 +116,8 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev, > struct resource_entry *rentry; > struct list_head resource_list; > struct resource *resources = NULL; > - int count; > + int count = 0; > + int ret; > > /* If the ACPI node already has a physical device attached, skip it. */ > if (adev->physical_node_count) > @@ -113,6 +127,15 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev, > return ERR_PTR(-EINVAL); > > INIT_LIST_HEAD(&resource_list); > + ret = acpi_dev_get_resources(adev, &resource_list, acpi_platform_resource_count, &count); > + if (ret < 0) > + return ERR_PTR(ret); Why not use acpi_walk_resources() directly here? Also, this extra resources walk is only needed if the resources check is needed to decide whether or not to skip the device, so what's the benefit of doing it for every device that's not skipped? > + > + acpi_dev_free_resource_list(&resource_list); > + > + if (count > 0 && !acpi_match_device_ids(adev, forbidden_id_with_resourses)) > + return ERR_PTR(-EINVAL); > + > count = acpi_dev_get_resources(adev, &resource_list, NULL, NULL); > if (count < 0) > return NULL; > --
On Thu, Jun 22, 2023 at 05:53:13PM +0200, Rafael J. Wysocki wrote: > On Wed, Jun 21, 2023 at 5:16 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > > > After switching i2c-scmi driver to be a plaform one, it stopped > > "platform" > > > being enumerated on number of Kontron platforms, because it's > > listed in the forbidden_id_list. > > > > To resolve the situation, split the list to generic one and > > another that holds devices that has to be skipped if and only > > "have" > > > if they have bogus resources attached (_CRS method returns some). Thanks for the typo fixes! ... > > +static const struct acpi_device_id forbidden_id_with_resourses[] = { > > I don't quite like this name and the driver_data field could be used > to indicate the need to check the resources. Okay, something like /* Check if the device has resources provided by _CRS method */ #define ACPI_PLATFORM_CHECK_RES BIT(0) ? > > + {"SMB0001", 0}, /* ACPI SMBUS virtual device */ > > + { } > > +}; ... > > +static int acpi_platform_resource_count(struct acpi_resource *ares, void *data) > > +{ > > + int *count = data; > > + > > + *count = *count + 1; > > Why not (*count)++? Can be that way, I just copied'n'pasted from the existing code. > > + return 1; > > +} ... > > INIT_LIST_HEAD(&resource_list); > > + ret = acpi_dev_get_resources(adev, &resource_list, acpi_platform_resource_count, &count); > > + if (ret < 0) > > + return ERR_PTR(ret); > > Why not use acpi_walk_resources() directly here? Can be done that way. Again, I just used a template (existing code in kernel) for similar functionality. > Also, this extra resources walk is only needed if the resources check > is needed to decide whether or not to skip the device, so what's the > benefit of doing it for every device that's not skipped? Ah, indeed. Makes sense to have done it conditionally. > > + acpi_dev_free_resource_list(&resource_list); ... Thank you for the review!
On Thu, Jun 22, 2023 at 8:19 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Thu, Jun 22, 2023 at 05:53:13PM +0200, Rafael J. Wysocki wrote: > > On Wed, Jun 21, 2023 at 5:16 PM Andy Shevchenko > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > > After switching i2c-scmi driver to be a plaform one, it stopped > > > > "platform" > > > > > being enumerated on number of Kontron platforms, because it's > > > listed in the forbidden_id_list. > > > > > > To resolve the situation, split the list to generic one and > > > another that holds devices that has to be skipped if and only > > > > "have" > > > > > if they have bogus resources attached (_CRS method returns some). > > Thanks for the typo fixes! > > ... > > > > +static const struct acpi_device_id forbidden_id_with_resourses[] = { > > > > I don't quite like this name and the driver_data field could be used > > to indicate the need to check the resources. > > Okay, something like > > /* Check if the device has resources provided by _CRS method */ > #define ACPI_PLATFORM_CHECK_RES BIT(0) > > ? Could be, but this is specific to forbidden_ids_list[]. Maybe ACPI_ALLOW_WO_RESOURCES or similar. > > > + {"SMB0001", 0}, /* ACPI SMBUS virtual device */ > > > + { } > > > +}; > > ... > > > > +static int acpi_platform_resource_count(struct acpi_resource *ares, void *data) > > > +{ > > > + int *count = data; > > > + > > > + *count = *count + 1; > > > > Why not (*count)++? > > Can be that way, I just copied'n'pasted from the existing code. > > > > + return 1; > > > +} BTW, this doesn't need to increment the count even. It could just terminate the walk on the first valid resource found and tell the caller to return true in that case.
On Fri, Jun 23, 2023 at 04:43:55PM +0200, Rafael J. Wysocki wrote: > On Thu, Jun 22, 2023 at 8:19 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > On Thu, Jun 22, 2023 at 05:53:13PM +0200, Rafael J. Wysocki wrote: > > > On Wed, Jun 21, 2023 at 5:16 PM Andy Shevchenko > > > <andriy.shevchenko@linux.intel.com> wrote: ... > > /* Check if the device has resources provided by _CRS method */ > > #define ACPI_PLATFORM_CHECK_RES BIT(0) > > > > ? > > Could be, but this is specific to forbidden_ids_list[]. Maybe > ACPI_ALLOW_WO_RESOURCES or similar. Got it, will do this way. ... > BTW, this doesn't need to increment the count even. It could just > terminate the walk on the first valid resource found and tell the > caller to return true in that case. Indeed, thank you for the hint!
On Mon, Jun 26, 2023 at 11:15:19AM +0300, Andy Shevchenko wrote: > On Fri, Jun 23, 2023 at 04:43:55PM +0200, Rafael J. Wysocki wrote: > > On Thu, Jun 22, 2023 at 8:19 PM Andy Shevchenko > > <andriy.shevchenko@linux.intel.com> wrote: > > > On Thu, Jun 22, 2023 at 05:53:13PM +0200, Rafael J. Wysocki wrote: > > > > On Wed, Jun 21, 2023 at 5:16 PM Andy Shevchenko > > > > <andriy.shevchenko@linux.intel.com> wrote: ... > > BTW, this doesn't need to increment the count even. It could just > > terminate the walk on the first valid resource found and tell the > > caller to return true in that case. > > Indeed, thank you for the hint! Actually it's doesn't matter if we count them or not, we still must use the context of the call to set up a flag or whatever. With the current code in mind I prefer to count resources and compare that to be non-zero. This will help to read and understand code better. That said, I will go with (*counter)++;
On Mon, Jun 26, 2023 at 12:44 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Mon, Jun 26, 2023 at 11:15:19AM +0300, Andy Shevchenko wrote: > > On Fri, Jun 23, 2023 at 04:43:55PM +0200, Rafael J. Wysocki wrote: > > > On Thu, Jun 22, 2023 at 8:19 PM Andy Shevchenko > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > On Thu, Jun 22, 2023 at 05:53:13PM +0200, Rafael J. Wysocki wrote: > > > > > On Wed, Jun 21, 2023 at 5:16 PM Andy Shevchenko > > > > > <andriy.shevchenko@linux.intel.com> wrote: > > ... > > > > BTW, this doesn't need to increment the count even. It could just > > > terminate the walk on the first valid resource found and tell the > > > caller to return true in that case. > > > > Indeed, thank you for the hint! > > Actually it's doesn't matter if we count them or not, we still must use the > context of the call to set up a flag or whatever. No, it is sufficient to pass a pointer to a bool variable. > With the current code in mind I prefer to count resources and compare that > to be non-zero. This will help to read and understand code better. I'm not sure. The condition is "if there is at least one valid resource, skip the device". Counting them all will make casual readers wonder why IMO.
On Mon, Jun 26, 2023 at 02:11:10PM +0200, Rafael J. Wysocki wrote: > On Mon, Jun 26, 2023 at 12:44 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > On Mon, Jun 26, 2023 at 11:15:19AM +0300, Andy Shevchenko wrote: > > > On Fri, Jun 23, 2023 at 04:43:55PM +0200, Rafael J. Wysocki wrote: > > > > On Thu, Jun 22, 2023 at 8:19 PM Andy Shevchenko > > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > On Thu, Jun 22, 2023 at 05:53:13PM +0200, Rafael J. Wysocki wrote: > > > > > > On Wed, Jun 21, 2023 at 5:16 PM Andy Shevchenko > > > > > > <andriy.shevchenko@linux.intel.com> wrote: ... > > > > BTW, this doesn't need to increment the count even. It could just > > > > terminate the walk on the first valid resource found and tell the > > > > caller to return true in that case. > > > > > > Indeed, thank you for the hint! > > > > Actually it's doesn't matter if we count them or not, we still must use the > > context of the call to set up a flag or whatever. > > No, it is sufficient to pass a pointer to a bool variable. > > > With the current code in mind I prefer to count resources and compare that > > to be non-zero. This will help to read and understand code better. > > I'm not sure. The condition is "if there is at least one valid > resource, skip the device". Counting them all will make casual > readers wonder why IMO. Okay, Can you check v3 for the rest and I can send a v4 if nothing else there?
diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c index fe00a5783f53..089a98bd18bf 100644 --- a/drivers/acpi/acpi_platform.c +++ b/drivers/acpi/acpi_platform.c @@ -19,13 +19,17 @@ #include "internal.h" +static const struct acpi_device_id forbidden_id_with_resourses[] = { + {"SMB0001", 0}, /* ACPI SMBUS virtual device */ + { } +}; + static const struct acpi_device_id forbidden_id_list[] = { {"ACPI0009", 0}, /* IOxAPIC */ {"ACPI000A", 0}, /* IOAPIC */ {"PNP0000", 0}, /* PIC */ {"PNP0100", 0}, /* Timer */ {"PNP0200", 0}, /* AT DMA Controller */ - {"SMB0001", 0}, /* ACPI SMBUS virtual device */ { } }; @@ -83,6 +87,15 @@ static void acpi_platform_fill_resource(struct acpi_device *adev, dest->parent = pci_find_resource(to_pci_dev(parent), dest); } +static int acpi_platform_resource_count(struct acpi_resource *ares, void *data) +{ + int *count = data; + + *count = *count + 1; + + return 1; +} + /** * acpi_create_platform_device - Create platform device for ACPI device node * @adev: ACPI device node to create a platform device for. @@ -103,7 +116,8 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev, struct resource_entry *rentry; struct list_head resource_list; struct resource *resources = NULL; - int count; + int count = 0; + int ret; /* If the ACPI node already has a physical device attached, skip it. */ if (adev->physical_node_count) @@ -113,6 +127,15 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev, return ERR_PTR(-EINVAL); INIT_LIST_HEAD(&resource_list); + ret = acpi_dev_get_resources(adev, &resource_list, acpi_platform_resource_count, &count); + if (ret < 0) + return ERR_PTR(ret); + + acpi_dev_free_resource_list(&resource_list); + + if (count > 0 && !acpi_match_device_ids(adev, forbidden_id_with_resourses)) + return ERR_PTR(-EINVAL); + count = acpi_dev_get_resources(adev, &resource_list, NULL, NULL); if (count < 0) return NULL;