From patchwork Fri Jan 4 01:00:38 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bjorn Helgaas X-Patchwork-Id: 1930791 Return-Path: X-Original-To: patchwork-linux-acpi@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id AC4EBDF25A for ; Fri, 4 Jan 2013 01:00:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754539Ab3ADBAl (ORCPT ); Thu, 3 Jan 2013 20:00:41 -0500 Received: from mail-qa0-f74.google.com ([209.85.216.74]:38032 "EHLO mail-qa0-f74.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754522Ab3ADBAj (ORCPT ); Thu, 3 Jan 2013 20:00:39 -0500 Received: by mail-qa0-f74.google.com with SMTP id r4so1731999qaq.3 for ; Thu, 03 Jan 2013 17:00:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=qRdflKRpQ3GKIamxnzYRhO+tTfnz9uXzV07lHxoSeeA=; b=eTPG3Yv2EuYQFnYr9WRlH+1Lry3fWoYfuu4v/mDJP5PfZrCSTp5raoaVd2lsKDH0GY e/cKDKxxgKi3cOQiPzunRIZ1M2qgF7L1IPBUwEuwxk4MiEJ0kWXah1PvfXLzftqyiIub FBvggsy7HG4C3Q2Zr9vgRpmPdJ2z1yIRZwkNmd2Z6qDkYUatceQypYCUys7QMiYwOFCU C2hpn6uGm8UqFqH8PaNA35Avu2alWWN7vuqi4JRlBbuk7qDlj/ST1gUvj+8/zbBXQnrh FrmMDQ/9oG+pztdkMoXHHnU3QGLWJHqkUJctS2oRvlywOFqDIZ7pn8VcNtBrtBsWqfxr iM0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:x-gm-message-state; bh=qRdflKRpQ3GKIamxnzYRhO+tTfnz9uXzV07lHxoSeeA=; b=XLeTX+lnLRPlDFobC3Y3FeAFAQkMt3+IYWtqQysecIxrRl0H9N8s+paSK5+DXos2fH Sp74LZjS6BeA5FQgvYdEVQterhD+dkufwuFPtB0LluL5IpTzYYdQdlD6NJ5IxPUbgOrQ EYmIoK+nXjBrAQCndIgt5eH7I2lRqgjuwab5pzjXhQUOfmm7C9I0BOv2PczAqkSzoz0I Igw4q3eUWuZFlz71tl86AqIqNiiUYCtpqF9BoNTlC3v9kB8aXfEsk8qOfTBjK7F8OXhL 9WMXEFGU1O4M4yEE4bIVr5oCD6TUOTNpwiwm01VrBUGtv4QXIL6Jry4KY2AkxSGsr24Q NwTg== X-Received: by 10.101.8.33 with SMTP id l33mr6869345ani.15.1357261238986; Thu, 03 Jan 2013 17:00:38 -0800 (PST) Received: from wpzn3.hot.corp.google.com (216-239-44-65.google.com [216.239.44.65]) by gmr-mx.google.com with ESMTPS id j11si2124132ank.2.2013.01.03.17.00.38 (version=TLSv1/SSLv3 cipher=AES128-SHA); Thu, 03 Jan 2013 17:00:38 -0800 (PST) Received: from bhelgaas.mtv.corp.google.com (bhelgaas.mtv.corp.google.com [172.17.131.112]) by wpzn3.hot.corp.google.com (Postfix) with ESMTP id C67E3100047; Thu, 3 Jan 2013 17:00:38 -0800 (PST) Received: by bhelgaas.mtv.corp.google.com (Postfix, from userid 131485) id 6C31C180324; Thu, 3 Jan 2013 17:00:38 -0800 (PST) Date: Thu, 3 Jan 2013 18:00:38 -0700 From: Bjorn Helgaas To: "Rafael J. Wysocki" Cc: "linux-pci@vger.kernel.org" , ACPI Devel Maling List , Greg Kroah-Hartman , LKML , Tony Luck , "H. Peter Anvin" , Yinghai Lu , Jiang Liu , Myron Stowe Subject: Re: [Alternative 2][PATCH] ACPI / PCI: Set root bridge ACPI handle in advance Message-ID: <20130104010038.GA11155@google.com> References: <1558789.gX8cmBgyDV@vostro.rjw.lan> <1635295.TkbrarASZn@vostro.rjw.lan> <113112384.JZ1gZKlJRa@vostro.rjw.lan> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <113112384.JZ1gZKlJRa@vostro.rjw.lan> User-Agent: Mutt/1.5.20 (2009-06-14) X-Gm-Message-State: ALoCoQmcp0KkBSDnbkbeYt0DB0MhHEiFT1nYEFTwrDyQI7XVEAHoecBHPmaXHadow3j9qKPPnDKuOe981sxAWYBzj4BCk1ZV3abhqYA8eZ/lfD4O9MkN944wgTO2skZd2qC1TrEl9Q9NsxVASjwa7CoNTb4XWi1VS0Ow9nu4i65LuKYDGeTB03nrBbRID1/k1bdwnGICSxHaVkcN/fWOiTfOSCwm1qs3pw== Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Thu, Jan 03, 2013 at 11:56:55PM +0100, Rafael J. Wysocki wrote: > OK, I now have sent no less than three working version of the patch that fixes > the current code which _is_ insane. You haven't even responded to the last > one, but for the first two the reason why you didn't like them was something > similar to "it may conflict with some future changes I'm planning". Well, > that might be used to reject prety much any change and I'm not considering it > as a good enough reason for blocking a fix. Sorry about that. I think your memory is faulty. My response to the first (https://lkml.org/lkml/2012/12/20/407) was "Thanks for cleaning this up, I have an interface concern, here's an outline of a possible alternative." My response to the second (https://lkml.org/lkml/2012/12/26/72) was "I like this much better, Acked-by: Bjorn Helgaas." Then Yinghai noticed the issue with non-ACPI host bridges, and you abandoned that approach. I took a few days of vacation, then spent the better part of yesterday exploring the reasons why x86 and ia64 don't use the "parent" argument when several other arches do, and worked up a patch (https://lkml.org/lkml/2013/1/2/285). It turned out to have a fatal flaw, but was done in good faith. It's true I haven't responded to the third one, posted about 12 hours ago. I still like the approach of the second patch. What would you think of the following incremental change to it? I did reproduce Yinghai's issue with non-ACPI host bridges, and this change resolves it for me. --- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff -u b/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c --- b/arch/x86/pci/acpi.c +++ b/arch/x86/pci/acpi.c @@ -522,6 +522,7 @@ sd = &info->sd; sd->domain = domain; sd->node = node; + sd->acpi_handle = device->handle; /* * Maybe the desired pci bus has been already scanned. In such case * it is unnecessary to scan the pci bus with the given domain,busnum. @@ -596,9 +597,8 @@ int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge) { struct pci_sysdata *sd = bridge->bus->sysdata; - struct pci_root_info *info = container_of(sd, struct pci_root_info, sd); - ACPI_HANDLE_SET(&bridge->dev, info->bridge->handle); + ACPI_HANDLE_SET(&bridge->dev, sd->acpi_handle); return 0; } --- a/arch/x86/include/asm/pci.h +++ b/arch/x86/include/asm/pci.h @@ -14,6 +14,7 @@ struct pci_sysdata { int domain; /* PCI domain */ int node; /* NUMA node */ + void *acpi_handle; #ifdef CONFIG_X86_64 void *iommu; /* IOMMU private data */ #endif