Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5205027imu; Tue, 13 Nov 2018 02:57:55 -0800 (PST) X-Google-Smtp-Source: AJdET5dSKSnF+orzEppa2v06noJw/gOiYXlKmldNOS/YkcwYRL5AxCV+UuuFzDr3E4dCXHoAYYWA X-Received: by 2002:a63:1d62:: with SMTP id d34-v6mr4391706pgm.180.1542106675167; Tue, 13 Nov 2018 02:57:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542106675; cv=none; d=google.com; s=arc-20160816; b=v+43iYO9By8eD6f89GBuFzKInpTbYIY6Kvl/9iRwutNvB6ijkLQSlVtm4GlpxIR3GA POqYEc+cHQsI1Qt06yMs9DuXImLOc5bYyPjwF4MXBsGiRgIRywHXWpLfrpIqdnCbX7G7 D/3RdCJP7UFuwX80IiQtgB0A0gl8Rax1ZBCEOpkzTuiFtwyxIRsv4senZy2OQVduLfaa XwKvmj5YchwDoGfoeGaP3c4IIPRRWxAxx4HhPgmfG3Fr4fxOCXh9bCUzRQE12GQz6UMm B+97JXMVqAhtv5uJ4YVchY+Jq+Cu7/nfxYUvQzyaJlbi0D4tdk5ezCMxouojsi99v28w uIDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=EU24k+xpe4VxfiVuuAFyVo4MJBm2RAzWLIkf8VOl7vs=; b=SdAM3JR9R0fsUlI4WBarvWAIwSczgfXgy3XE5dFV/4sJfLv0AFBWbYZXW9wlQHYOVm XVjcbgKc8Jjw53PTq3ORTtww/bhkF9jAYpvu9DXyP8SmEVV+hbAfdbLETDlv3x+9a62c PEgDnans14vRYkGASeBKVje4PEZAD+j+qKdd4J+kLK9X46/MZmzgKqmOGW7ChUZDi9So N7NXU59olpmJLmgKM9x8OctyEX1cpEsYy290mJtYFPrPf8hCsVylOSr9LEZ7IJnx0er+ 9ib61uhQV2Pr7uLqs7J0ns1AWqpGxj75MmQOsDgbtS+gcFh/6oVkSYPB7djTUyIF3oXu oZog== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j135-v6si23254854pfd.243.2018.11.13.02.57.39; Tue, 13 Nov 2018 02:57:55 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732416AbeKMUyR (ORCPT + 99 others); Tue, 13 Nov 2018 15:54:17 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:51948 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726581AbeKMUyR (ORCPT ); Tue, 13 Nov 2018 15:54:17 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C2D6DA78; Tue, 13 Nov 2018 02:56:42 -0800 (PST) Received: from e107981-ln.cambridge.arm.com (e107981-ln.cambridge.arm.com [10.1.197.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AB0FD3F5CF; Tue, 13 Nov 2018 02:56:39 -0800 (PST) Date: Tue, 13 Nov 2018 10:56:36 +0000 From: Lorenzo Pieralisi To: Lukas Wunner Cc: Mika Westerberg , iommu@lists.linux-foundation.org, Joerg Roedel , David Woodhouse , Lu Baolu , Ashok Raj , Bjorn Helgaas , "Rafael J. Wysocki" , Jacob jun Pan , Andreas Noever , Michael Jamet , Yehezkel Bernat , Christian Kellner , Mario.Limonciello@dell.com, Anthony Wong , linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/4] PCI / ACPI: Identify external PCI devices Message-ID: <20181113105636.GB11202@e107981-ln.cambridge.arm.com> References: <20181112160628.86620-1-mika.westerberg@linux.intel.com> <20181112160628.86620-2-mika.westerberg@linux.intel.com> <20181112180203.lx72gjfplb6xlur7@wunner.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181112180203.lx72gjfplb6xlur7@wunner.de> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 12, 2018 at 07:02:03PM +0100, Lukas Wunner wrote: > On Mon, Nov 12, 2018 at 07:06:25PM +0300, Mika Westerberg wrote: > > --- a/drivers/pci/probe.c > > +++ b/drivers/pci/probe.c > > @@ -1378,6 +1378,27 @@ static void set_pcie_thunderbolt(struct pci_dev *dev) > > } > > } > > > > +static void set_pcie_external(struct pci_dev *dev) > > +{ > > + struct pci_dev *parent; > > + > > + /* > > + * Walk up the device hierarchy and check for any upstream > > + * bridge that has is_external_facing set to true. This means > > + * the hierarchy is below PCIe port that is exposed externally > > + * (such as Thunderbolt). > > + */ > > + parent = pci_upstream_bridge(dev); > > + while (parent) { > > + if (parent->is_external) { > > + dev->is_external = true; > > + break; > > + } > > + > > + parent = pci_upstream_bridge(parent); > > + } > > +} > > + > > This looks pretty much like a duplication of the is_thunderbolt bit > in struct pci_dev and the pci_is_thunderbolt_attached() helper. > > Why constrain the functionality to ports with the _DSD property > instead of making it available for *any* Thunderbolt port? I assume it is because this is just not needed for Thuderbolt ports but rather for all PCIe devices that are "external" (whatever that is supposed to mean), ie it is valid also for PCIe slots. To be frank the concept (and Microsoft _DSD bindings) seems a bit vague and not thoroughly defined and I would question its detection at PCI/ACPI core level, I would hope this can be clarified at ACPI specification level, at least. Thanks, Lorenzo