From patchwork Thu Mar 30 20:56:36 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Rafael J. Wysocki" X-Patchwork-Id: 745411 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3vvHBt0QXsz9s1y for ; Fri, 31 Mar 2017 08:02:30 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934971AbdC3VC2 (ORCPT ); Thu, 30 Mar 2017 17:02:28 -0400 Received: from cloudserver094114.home.net.pl ([79.96.170.134]:48467 "EHLO cloudserver094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934865AbdC3VC1 (ORCPT ); Thu, 30 Mar 2017 17:02:27 -0400 Received: from adkt166.ipv4.supernova.orange.pl (79.184.253.166) (HELO aspire.rjw.lan) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.82) id 23f8da939a7897ff; Thu, 30 Mar 2017 23:02:24 +0200 From: "Rafael J. Wysocki" To: Hans de Goede Cc: Mika Westerberg , Adrian Hunter , Ulf Hansson , ACPI Devel Maling List , Andy Shevchenko , Linux PCI Subject: Re: [PATCH] ACPI / scan: Prefer devices without _HID/_CID for _ADR matching Date: Thu, 30 Mar 2017 22:56:36 +0200 Message-ID: <1816647.tOAZ7v3nRx@aspire.rjw.lan> User-Agent: KMail/4.14.10 (Linux/4.10.0+; KDE/4.14.9; x86_64; ; ) In-Reply-To: <651067e1-e87f-6dba-0b99-c158655d2086@redhat.com> References: <20161225102148.7706-1-hdegoede@redhat.com> <2022116.4lq1KAmrJA@aspire.rjw.lan> <651067e1-e87f-6dba-0b99-c158655d2086@redhat.com> MIME-Version: 1.0 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Sunday, January 01, 2017 09:30:06 PM Hans de Goede wrote: > Hi, > > On 30-12-16 02:27, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > The way acpi_find_child_device() works currently is that, if there > > are two (or more) devices with the same _ADR value in the same > > namespace scope (which is not specifically allowed by the spec and > > the OS behavior in that case is not defined), the first one of them > > found to be present (with the help of _STA) will be returned. > > > > This covers the majority of cases, but is not sufficient if some of > > the devices in question have a _HID (or _CID) returning some valid > > ACPI/PNP device IDs (which is disallowed by the spec) and the > > ASL writers' expectation appears to be that the OS will match > > devices without a valid ACPI/PNP device ID against a given bus > > address first. > > > > To cover this special case as well, modify find_child_checks() > > to prefer devices without ACPI/PNP device IDs over devices that > > have them. > > > > Suggested-by: Mika Westerberg > > Signed-off-by: Rafael J. Wysocki > > --- > > > > I'm not actually sure if this is sufficient to fix the original 80860F14 uid "2" > > sd-controller problem on CherryTrail. Hans, can you please check? > > Ok, just booted a kernel with this patch replacing my own attempt > at fixing this, and the kernel still sees and initializes the > mmc controller in question correctly with this patch: > > Tested-by: Hans de Goede Unfortunately, this breaks discrete graphics enumeration in https://bugzilla.kernel.org/show_bug.cgi?id=194889 so can you please check if the patch below doesn't break the platform fixed by the above? Thanks, Rafael --- drivers/acpi/glue.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) Index: linux-pm/drivers/acpi/glue.c =================================================================== --- linux-pm.orig/drivers/acpi/glue.c +++ linux-pm/drivers/acpi/glue.c @@ -99,13 +99,13 @@ static int find_child_checks(struct acpi return -ENODEV; /* - * If the device has a _HID (or _CID) returning a valid ACPI/PNP - * device ID, it is better to make it look less attractive here, so that - * the other device with the same _ADR value (that may not have a valid - * device ID) can be matched going forward. [This means a second spec - * violation in a row, so whatever we do here is best effort anyway.] + * If the device has a _HID returning a valid ACPI/PNP device ID, it is + * better to make it look less attractive here, so that the other device + * with the same _ADR value (that may not have a valid device ID) can be + * matched going forward. [This means a second spec violation in a row, + * so whatever we do here is best effort anyway.] */ - return sta_present && list_empty(&adev->pnp.ids) ? + return sta_present && !adev->pnp.type.platform_id ? FIND_CHILD_MAX_SCORE : FIND_CHILD_MIN_SCORE; }