Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp8339401imu; Thu, 15 Nov 2018 09:59:31 -0800 (PST) X-Google-Smtp-Source: AJdET5cbqj4zJbRLUPOcybcJEwCqV0H2SCjbG9Rs9+ExURHPy/puF64gnOcI557jihjqO7FFLKry X-Received: by 2002:a17:902:bb83:: with SMTP id m3-v6mr7066560pls.144.1542304771744; Thu, 15 Nov 2018 09:59:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542304771; cv=none; d=google.com; s=arc-20160816; b=Aqea9GLACsNVwbY3873KvLWZVY8b5zrnkYL/1LaX4UPUn8YiemjTKP0jL9dSg7eHAl xyS0SmcO7ieTSILLkLLieNxQ8A821UoY+ggZRX7kj+J9j664a4rF8rCET1yU6ACkaaR8 jv4wjOQtEgE6f0CZksNt/CHdz5DBzLFdgkDnKcEOy/Zu9snCToisTsKd0nXy2P3B8BIp TD7HJBqiAQJQpUVrlH0gncERv0jYGKP6SCePs4pbQbilORcSwTuc2FAyffmO+mpDJi5T vJC81s/rSwR5YE+/P2oll3yBvcb7Qq+9d9lUl2X8a2QmnqTorXtISmgo+KOf8CEYv00i cDaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=ooXTaPBrKWZJbdOQ4QUrmUpZGa9iRizTaCm7MuadtjU=; b=uE1lfSgxOnL2zlMPIJ2Piba/cgMjiUP9VPdC7a//+HIAELOUJJUPRAS+7IrGBi9E0d KANU9EDbslY5oONVemudADPmFolu2rASYgjcQHxH2tTTv71vgSJLnG0x0V+QKCq+qE5z LdiTA10QyMlpavbrDIwfL/psjxpBpr9tJL7QCCkPjtbQbKOkYPlym663/HAw/bv/P/j6 JdajJ3e/re/lqs3L5V7q3+iqvE8GfEGpa9VPZAicTZAV+RCGdoySbeyTZm7705tOHVwL 17wzSkGDWpB3BAj+DyV423wJzdo8q6T/GkRuCT15MUOcZRD0FfJjihm+5g3sQGSZpBsu U6uQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="gx/VBiNO"; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p19si16060340pgj.375.2018.11.15.09.59.16; Thu, 15 Nov 2018 09:59:31 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b="gx/VBiNO"; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388395AbeKPEHW (ORCPT + 99 others); Thu, 15 Nov 2018 23:07:22 -0500 Received: from mail-it1-f194.google.com ([209.85.166.194]:52545 "EHLO mail-it1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726453AbeKPEHW (ORCPT ); Thu, 15 Nov 2018 23:07:22 -0500 Received: by mail-it1-f194.google.com with SMTP id t190-v6so30715403itb.2; Thu, 15 Nov 2018 09:58:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ooXTaPBrKWZJbdOQ4QUrmUpZGa9iRizTaCm7MuadtjU=; b=gx/VBiNOWSaKoWjwpd5nVmGhpUOiS8OhhULUP+LkM7ei4KmvCRNdjwT64gdG8JPEmQ HVhG64q2fhvt26LmAQhCNeyHEdJNLrjEk0haGp6QRLOeDr0HZuTmjkG7GWPn2OOR4ztk 2uvm0X7xH1j8raEr0bguXoHMsxt/COUd0W7bVUe181tgQ6q93MjxB3LvGmW5SFzbLaYd Akro0jm6llywDWtKbLIDvejCfZpF1EM44CkDW9FO7+hXMhqv2zek/H4b/hgxyjJBCpo2 bZD2wOynPAGychy6+PeoEElm4B0mJDwd+xmYrI1dCnLzHTgVPf48sv8dVYwmJ+dXldd/ ggvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ooXTaPBrKWZJbdOQ4QUrmUpZGa9iRizTaCm7MuadtjU=; b=W5yS4XUNu+ZJUE2eZFRhaPMFPvFj1RPNgw0nZDZ8uQpWe5K8q8yUN2whlDInLtP8G1 Bw3T5DoU6/vLdId3MmEoi4wmm8lAYTBHRpfoeQE4TXEKvx3XBfMGZToAeVpfWykdy70g qJgG2CKwUEjq2g0aAMIgpEyRAL585iNXVlwd5/wnBwv9EBmjmTMFpcY0iWsb3TQojd4J 4R75LjBePdFWpGI6OPuQSE/BN0V4lEbWSP4lse19ZI4lYLCn3JnMPfwKBAO50oEL6CBT cBnVyw6rJeVwnsQuf+/70Vr07USKyhwLwZhW4BlzKCUOCA9NLzMzJdRph3mQPQD+L3YM 2yAQ== X-Gm-Message-State: AGRZ1gL9k9uVwEAgQl05z5m/t0lFTljkDbviaDbug5IAmAJwGtu1yvKj Aj8S9LTws+Jm426zxT6wsLDQR0zI3o2Cr0L5mgM= X-Received: by 2002:a02:954f:: with SMTP id y73-v6mr6976037jah.115.1542304710714; Thu, 15 Nov 2018 09:58:30 -0800 (PST) MIME-Version: 1.0 References: <20181112160628.86620-2-mika.westerberg@linux.intel.com> <20181112180203.lx72gjfplb6xlur7@wunner.de> <20181113105636.GB11202@e107981-ln.cambridge.arm.com> <20181113112700.GT2500@lahna.fi.intel.com> <20181113114527.GA12821@e107981-ln.cambridge.arm.com> <20181115102239.GU2500@lahna.fi.intel.com> <20181115111356.GA599@e107981-ln.cambridge.arm.com> <20181115113737.GW2500@lahna.fi.intel.com> <20181115120736.pscly6zwd3k2tvd2@wunner.de> <20181115121627.GA2500@lahna.fi.intel.com> <20181115174608.GA17691@e107981-ln.cambridge.arm.com> In-Reply-To: <20181115174608.GA17691@e107981-ln.cambridge.arm.com> From: Yehezkel Bernat Date: Thu, 15 Nov 2018 19:58:13 +0200 Message-ID: Subject: Re: [PATCH 1/4] PCI / ACPI: Identify external PCI devices To: lorenzo.pieralisi@arm.com Cc: Mika Westerberg , lukas@wunner.de, iommu@lists.linux-foundation.org, joro@8bytes.org, David Woodhouse , baolu.lu@linux.intel.com, ashok.raj@intel.com, Bjorn Helgaas , rjw@rjwysocki.net, jacob.jun.pan@intel.com, Andreas Noever , michael.jamet@intel.com, Christian Kellner , Mario Limonciello , Anthony Wong , linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org, LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 15, 2018 at 7:46 PM Lorenzo Pieralisi wrote: > > On Thu, Nov 15, 2018 at 02:16:27PM +0200, Mika Westerberg wrote: > > On Thu, Nov 15, 2018 at 01:07:36PM +0100, Lukas Wunner wrote: > > > On Thu, Nov 15, 2018 at 01:37:37PM +0200, Mika Westerberg wrote: > > > > On Thu, Nov 15, 2018 at 11:13:56AM +0000, Lorenzo Pieralisi wrote: > > > > > I have strong objections to the way these bindings have been forced upon > > > > > everybody; if that's the way *generic* ACPI bindings are specified I > > > > > wonder why there still exists an ACPI specification and related working > > > > > group. > > > > > > > > > > I personally (but that's Bjorn and Rafael choice) think that this is > > > > > not a change that belongs in PCI core, ACPI bindings are ill-defined > > > > > and device tree bindings are non-existing. > > > > > > > > Any idea where should I put it then? These systems are already out there > > > > and we need to support them one way or another. > > > > > > I suppose those are all Thunderbolt, so could be handled by the > > > existing ->is_thunderbolt bit? > > > > > > It was said in this thread that ->is_external is more generic in > > > that it could also be used on PCIe slots, however that use case > > > doesn't appear to lend itself to the "plug in while laptop owner > > > is getting coffee" attack. To access PCIe slots on a server you > > > normally need access to a data center. On a desktop, you usually > > > have to open the case, by which time the coffee may already have > > > been fetched. So frankly the binding seems a bit over-engineered > > > to me and yet another thing that BIOS writers may get wrong. > > > > I would not say it should include PCIe slots but there are other cables > > that carry PCIe and I was thinking we could make it to support those as > > well. > > > > I have no problem using is_thunderbolt here, though if we don't want to > > support non-Thunderbolt external devices this way. > > > > However, the question here is more that where I should put the _DSD > > parsing code if it is not suitable to be placed inside PCI/ACPI core as > > I've done in this patch? ;-) > > Do you really need to parse it if the dev->is_thunderbolt check is enough ? From what I know, there are more devices that suffer from similar security issues like Thunderbolt, e.g. FireWire [1]. My assumption is that the same protection may be applied to such devices too, even if currently it sounds like vendors care mostly about Thunderbolt (probably because it removes the need for user approval for device connection; it becames a simple plug-and-play experience). Thus, I don't think binding it with dev->is_thunderbolt is the correct thing to do. [1] https://github.com/carmaa/inception