Message ID | 12149290.O9o76ZdvQC@kreacher |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp2889344wrt; Tue, 10 Jan 2023 10:00:44 -0800 (PST) X-Google-Smtp-Source: AMrXdXvW3GQkg0MzYFe32BnFHQwH66VYOmDE5RRr5J2uwGzkWQdjcvBo1uVc+pP80OaXq7kNVeLE X-Received: by 2002:aa7:c2c5:0:b0:498:2223:2df9 with SMTP id m5-20020aa7c2c5000000b0049822232df9mr13025714edp.4.1673373644733; Tue, 10 Jan 2023 10:00:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673373644; cv=none; d=google.com; s=arc-20160816; b=xGjvmaKTvkPnUSmlptArze4ywvpqHDGkoz9tfs3wiQ5qq1yK3nw/cc4UBQAvXJwEji WQ3mPKf7SOGgZ2ZxuxKi9gNSG9FXF64AvbFNkLsvjqdUKLrHUZZ1JWkqcKhBM13X7Nx2 JKEitSQy7J+9gKOZ9+JpPc63N02wf0YD89GJgc7nTyVbfYh7WRMmvnAHRdHx3kenFg2q nGDp8LbrauONEij0u37S93gxxcfUqixE723ecqaMEUnm9CRc5SJU9d+397aqRdaspGBo 3gs6SwHlv6pzqUBPjebfVGC7us6jbWn9Aljj4zstD7gFeLU38ipIP5i5/xlJTEoo1ysR IUSQ== 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; bh=H3LJB6gI8KUNdcfsnFIDgFRNaIb6DV5Taoazh/9SA1Y=; b=EsNHWxVPdofotNDyISOej98W9HeFwFK1e7G5ZKEKJIgQS2yWrS6isSGbQsVTMnmAFI 6pHwQVCg3qFJzl9U0KrZy58vS4jbdBmU0n3VqjwkVbNSM/IsZT3p9kai+uVgNJGDci7J TTSkcGKubv9LH5wBDXeE7BWRX0IhgQgb8sEa16X0PLa2mPz9s7T8yEJsAsbrRvys3fv6 kXFkKftQc8stYaRr23rLMPKq9tF4g7YCOsSMKD4YHfc/brRBB80GJW8HaJyQIfEkSLpK 23uOxC+z2ihhy2Tu+FMpp8orm2S+BmjkKuXfbMvbwS6V0WxBaceZhiQyKGepaMQrkwIg oH1A== ARC-Authentication-Results: i=1; mx.google.com; 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p34-20020a056402502200b0046aee4c4ebfsi11054700eda.105.2023.01.10.10.00.21; Tue, 10 Jan 2023 10:00:44 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234694AbjAJR7T (ORCPT <rfc822;syz17693488234@gmail.com> + 99 others); Tue, 10 Jan 2023 12:59:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39900 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238843AbjAJR6R (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 10 Jan 2023 12:58:17 -0500 Received: from cloudserver094114.home.pl (cloudserver094114.home.pl [79.96.170.134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6B907A44E; Tue, 10 Jan 2023 09:58:09 -0800 (PST) Received: from localhost (127.0.0.1) (HELO v370.home.net.pl) by /usr/run/smtp (/usr/run/postfix/private/idea_relay_lmtp) via UNIX with SMTP (IdeaSmtpServer 5.1.0) id 322c10ed6f9fbde9; Tue, 10 Jan 2023 18:58:07 +0100 Received: from kreacher.localnet (unknown [213.134.183.108]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by v370.home.net.pl (Postfix) with ESMTPSA id 9B0452625407; Tue, 10 Jan 2023 18:58:06 +0100 (CET) From: "Rafael J. Wysocki" <rjw@rjwysocki.net> To: Linux ACPI <linux-acpi@vger.kernel.org> Cc: LKML <linux-kernel@vger.kernel.org>, Chen Yu <yu.c.chen@intel.com>, Zhang Rui <rui.zhang@intel.com> Subject: [PATCH v1] ACPI: PNP: Introduce list of known non-PNP devices Date: Tue, 10 Jan 2023 18:58:05 +0100 Message-ID: <12149290.O9o76ZdvQC@kreacher> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" X-CLIENT-IP: 213.134.183.108 X-CLIENT-HOSTNAME: 213.134.183.108 X-VADE-SPAMSTATE: clean X-VADE-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvhedrledvgdeghecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfjqffogffrnfdpggftiffpkfenuceurghilhhouhhtmecuudehtdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkggfgtgesthfuredttddtjeenucfhrhhomhepfdftrghfrggvlhculfdrucghhihsohgtkhhifdcuoehrjhifsehrjhifhihsohgtkhhirdhnvghtqeenucggtffrrghtthgvrhhnpeffffffkefgheehffelteeiveeffeevhfelteejvddvieejjeelvdeiheeuveeuffenucfkphepvddufedrudefgedrudekfedruddtkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpedvudefrddufeegrddukeefrddutdekpdhhvghlohepkhhrvggrtghhvghrrdhlohgtrghlnhgvthdpmhgrihhlfhhrohhmpedftfgrfhgrvghlucflrdcuhgihshhotghkihdfuceorhhjfiesrhhjfiihshhotghkihdrnhgvtheqpdhnsggprhgtphhtthhopeegpdhrtghpthhtoheplhhinhhugidqrggtphhisehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtohephihurdgtrdgthhgvnhesihhnthgvlhdrtghomhdprhgtphhtthhopehruhhirdiihhgrnhhgsehinhhtvghlrdgtohhm X-DCC--Metrics: v370.home.net.pl 1024; Body=4 Fuz1=4 Fuz2=4 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS 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?1754659442868503010?= X-GMAIL-MSGID: =?utf-8?q?1754659442868503010?= |
Series |
[v1] ACPI: PNP: Introduce list of known non-PNP devices
|
|
Commit Message
Rafael J. Wysocki
Jan. 10, 2023, 5:58 p.m. UTC
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> In some cases, PNP device IDs from acpi_pnp_device_ids[] are returned by _CID for devices for which matching platform drivers are present in the kernel and should be bound to them. However, the IDs coming from _CID cause the PNP scan handler to attach to those devices which prevents platform device objects from being created for them. Address this by introducing a list of known non-PNP device IDs into acpi_pnp.c such that if a device ID is there in that list, it cannot be attached to by the PNP scan handler and add the platform runtime update and telemetry device IDs to that list to start with. Reported-by: Chen Yu <yu.c.chen@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> --- drivers/acpi/acpi_pnp.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-)
Comments
On Tue, 2023-01-10 at 18:58 +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > In some cases, PNP device IDs from acpi_pnp_device_ids[] are returned > by > _CID for devices for which matching platform drivers are present in > the > kernel and should be bound to them. However, the IDs coming from > _CID > cause the PNP scan handler to attach to those devices which prevents > platform device objects from being created for them. > > Address this by introducing a list of known non-PNP device IDs into > acpi_pnp.c such that if a device ID is there in that list, it cannot > be > attached to by the PNP scan handler and add the platform runtime > update > and telemetry device IDs to that list to start with. > > Reported-by: Chen Yu <yu.c.chen@intel.com> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > --- > drivers/acpi/acpi_pnp.c | 14 +++++++++++++- > 1 file changed, 13 insertions(+), 1 deletion(-) > > Index: linux-pm/drivers/acpi/acpi_pnp.c > =================================================================== > --- linux-pm.orig/drivers/acpi/acpi_pnp.c > +++ linux-pm/drivers/acpi/acpi_pnp.c > @@ -348,10 +348,22 @@ static bool acpi_pnp_match(const char *i > return false; > } > > +/* > + * If one of the device IDs below is present in the list of device > IDs of a > + * given ACPI device object, the PNP scan handler will not attach to > that > + * object, because there is a proper non-PNP driver in the kernel > for the > + * device represented by it. > + */ > +static const struct acpi_device_id acpi_nonpnp_device_ids[] = { > + {"INTC1080"}, > + {"INTC1081"}, > + {""}, > +}; > + > static int acpi_pnp_attach(struct acpi_device *adev, > const struct acpi_device_id *id) > { > - return 1; > + return !!acpi_match_device_ids(adev, acpi_nonpnp_device_ids); acpi_match_device_ids() returns True if the id matches, and in this case, acpi_pnp_attach() should return false, right? thanks, rui > } > > static struct acpi_scan_handler acpi_pnp_handler = { > > >
CC Zhang Yang who has tested the patch. On Wed, 2023-01-11 at 07:25 +0000, Zhang, Rui wrote: > On Tue, 2023-01-10 at 18:58 +0100, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > In some cases, PNP device IDs from acpi_pnp_device_ids[] are > > returned > > by > > _CID for devices for which matching platform drivers are present in > > the > > kernel and should be bound to them. However, the IDs coming from > > _CID > > cause the PNP scan handler to attach to those devices which > > prevents > > platform device objects from being created for them. > > > > Address this by introducing a list of known non-PNP device IDs into > > acpi_pnp.c such that if a device ID is there in that list, it > > cannot > > be > > attached to by the PNP scan handler and add the platform runtime > > update > > and telemetry device IDs to that list to start with. > > > > Reported-by: Chen Yu <yu.c.chen@intel.com> > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > --- > > drivers/acpi/acpi_pnp.c | 14 +++++++++++++- > > 1 file changed, 13 insertions(+), 1 deletion(-) > > > > Index: linux-pm/drivers/acpi/acpi_pnp.c > > =================================================================== > > --- linux-pm.orig/drivers/acpi/acpi_pnp.c > > +++ linux-pm/drivers/acpi/acpi_pnp.c > > @@ -348,10 +348,22 @@ static bool acpi_pnp_match(const char *i > > return false; > > } > > > > +/* > > + * If one of the device IDs below is present in the list of device > > IDs of a > > + * given ACPI device object, the PNP scan handler will not attach > > to > > that > > + * object, because there is a proper non-PNP driver in the kernel > > for the > > + * device represented by it. > > + */ > > +static const struct acpi_device_id acpi_nonpnp_device_ids[] = { > > + {"INTC1080"}, > > + {"INTC1081"}, > > + {""}, > > +}; > > + > > static int acpi_pnp_attach(struct acpi_device *adev, > > const struct acpi_device_id *id) > > { > > - return 1; > > + return !!acpi_match_device_ids(adev, acpi_nonpnp_device_ids); > > acpi_match_device_ids() returns True if the id matches, and in this > case, acpi_pnp_attach() should return false, right? > It is __acpi_match_device() that returns True when matches, and acpi_match_device_ids() returns 0 in this case. So this is not a bug, sorry for the noise. thanks, rui > thanks, > rui > > > } > > > > static struct acpi_scan_handler acpi_pnp_handler = { > > > > > >
-----Original Message----- From: Zhang, Rui <rui.zhang@intel.com> Sent: Wednesday, January 11, 2023 4:02 PM To: rjw@rjwysocki.net; linux-acpi@vger.kernel.org Cc: linux-kernel@vger.kernel.org; Chen, Yu C <yu.c.chen@intel.com>; Zhang, Yang5 <yang5.zhang@intel.com> Subject: Re: [PATCH v1] ACPI: PNP: Introduce list of known non-PNP devices CC Zhang Yang who has tested the patch. On Wed, 2023-01-11 at 07:25 +0000, Zhang, Rui wrote: > On Tue, 2023-01-10 at 18:58 +0100, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > In some cases, PNP device IDs from acpi_pnp_device_ids[] are > > returned by _CID for devices for which matching platform drivers are > > present in the kernel and should be bound to them. However, the IDs > > coming from _CID cause the PNP scan handler to attach to those > > devices which prevents platform device objects from being created > > for them. > > > > Address this by introducing a list of known non-PNP device IDs into > > acpi_pnp.c such that if a device ID is there in that list, it cannot > > be attached to by the PNP scan handler and add the platform runtime > > update and telemetry device IDs to that list to start with. > > > > Reported-by: Chen Yu <yu.c.chen@intel.com> > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Zhang Yang <Yang5.zhang@intel.com> Thanks Yang > > --- > > drivers/acpi/acpi_pnp.c | 14 +++++++++++++- > > 1 file changed, 13 insertions(+), 1 deletion(-) > > > > Index: linux-pm/drivers/acpi/acpi_pnp.c > > =================================================================== > > --- linux-pm.orig/drivers/acpi/acpi_pnp.c > > +++ linux-pm/drivers/acpi/acpi_pnp.c > > @@ -348,10 +348,22 @@ static bool acpi_pnp_match(const char *i > > return false; > > } > > > > +/* > > + * If one of the device IDs below is present in the list of device > > IDs of a > > + * given ACPI device object, the PNP scan handler will not attach > > to > > that > > + * object, because there is a proper non-PNP driver in the kernel > > for the > > + * device represented by it. > > + */ > > +static const struct acpi_device_id acpi_nonpnp_device_ids[] = { > > + {"INTC1080"}, > > + {"INTC1081"}, > > + {""}, > > +}; > > + > > static int acpi_pnp_attach(struct acpi_device *adev, > > const struct acpi_device_id *id) { > > - return 1; > > + return !!acpi_match_device_ids(adev, acpi_nonpnp_device_ids); > > acpi_match_device_ids() returns True if the id matches, and in this > case, acpi_pnp_attach() should return false, right? > It is __acpi_match_device() that returns True when matches, and acpi_match_device_ids() returns 0 in this case. So this is not a bug, sorry for the noise. thanks, rui > thanks, > rui > > > } > > > > static struct acpi_scan_handler acpi_pnp_handler = { > > > > > >
Index: linux-pm/drivers/acpi/acpi_pnp.c =================================================================== --- linux-pm.orig/drivers/acpi/acpi_pnp.c +++ linux-pm/drivers/acpi/acpi_pnp.c @@ -348,10 +348,22 @@ static bool acpi_pnp_match(const char *i return false; } +/* + * If one of the device IDs below is present in the list of device IDs of a + * given ACPI device object, the PNP scan handler will not attach to that + * object, because there is a proper non-PNP driver in the kernel for the + * device represented by it. + */ +static const struct acpi_device_id acpi_nonpnp_device_ids[] = { + {"INTC1080"}, + {"INTC1081"}, + {""}, +}; + static int acpi_pnp_attach(struct acpi_device *adev, const struct acpi_device_id *id) { - return 1; + return !!acpi_match_device_ids(adev, acpi_nonpnp_device_ids); } static struct acpi_scan_handler acpi_pnp_handler = {