Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp900927pxb; Fri, 28 Jan 2022 12:42:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJz8zivJadmn9o153qQnbbI3VIHtqJqb0D9HKCe8O/MSquojTdSq/DKqftWuNswK44BLui7F X-Received: by 2002:a17:907:2d11:: with SMTP id gs17mr8425174ejc.189.1643402529620; Fri, 28 Jan 2022 12:42:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643402529; cv=none; d=google.com; s=arc-20160816; b=urvWFCmn9ZJZvemANvfP9+Ke2O5SPrIueXvDidyo/gpBVaZxZ4AbiVi/BcV9KGnlmO SUQDyuMP68HSqJGpdhDscdmpS10qVlYiVS50qpJ8rJmQwULVtQHaiSTZkGo+Ca25Znm0 Zm7SBpExfsSI9RdCI7P3DOBbmUBcd0Krv/3220QgbeCBby0ifqPcfB524JXrgi7WRJyk fDHlaFHpOKQGkYyarQFRo7HkVu2NKqICogikA5IbP81mGvcpuDXQK1EZKakU+vamInwd cnW9Fjyi2eKiVe+I4MLJTXmr251iUqTc49aSPkKQ3FDAcPCZ+VLbPoOGAsTyulZNQggF QRwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=mFJYwHho4FfiR59k7zwtTLakJoJ7lquDQcT100wA/fo=; b=CcbpWRBV2ZTnB9w2KZCJ9ZglwGWASExk6RRNvq6Lxa/PbcLklIDDL71xwFu434RWAe m1h2ZDWdl7DFWjjkoe1NcWcIDLZJd9uIP+5XfXab42dn0pGQfsGElfD79egEsI8yRjTh I795sckrE1rG/xskpTFJvM6PofDYI/unviHh+EY0QTBHNUqwywahhyaPIeL7ZRc6D+AX ctSP5iYP0uVpBo1KQYDT11yE1Mp7BmiNso6LIxdkd29qRJIa5cCBoxWzIa4R6pubRwh2 W/viBBTctXTtAsqVl/opYas3RzlnVLDlzeBKMWmPbkjAUsIcrNfB9ruNDvsx8Zsvtfsu ex0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=rpfrv8BD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s2si3516283ejs.741.2022.01.28.12.41.45; Fri, 28 Jan 2022 12:42:09 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=rpfrv8BD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240782AbiA0W0r (ORCPT + 99 others); Thu, 27 Jan 2022 17:26:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48564 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235048AbiA0W0p (ORCPT ); Thu, 27 Jan 2022 17:26:45 -0500 Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2A6DAC061747 for ; Thu, 27 Jan 2022 14:26:45 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id j24so1691986qkk.10 for ; Thu, 27 Jan 2022 14:26:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mFJYwHho4FfiR59k7zwtTLakJoJ7lquDQcT100wA/fo=; b=rpfrv8BDIFTyw0uXk3zhjbYHebBePgDawS9sfK5yt/3wAcmbth4KY/h1zZYsTsLmfN fgtl4SHqwhNnU1VpfET/gxU+KeCIQuY2bY5tL049r02z/HXrI9EVe8pEkqCaOH7+l5iP MYM+4Ja/dB8RlQxMxP38UuFeP/X7Crbu69hVCO8cZExf21rOYU9+cdei7iXGuvusrtum 629IrQY7wICIsgR94zbqAfNcOYwhKLk2SiOWNK6dOdtXsFIyz1nRbN322w3uSxtkSFsd AZHE+HjNKiIvU3wrfthwQ3i2Vtr4Rt93scHtFCDroNqbQvLrAzI9XLMuhIo2xo0ZGpo6 DTpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mFJYwHho4FfiR59k7zwtTLakJoJ7lquDQcT100wA/fo=; b=6R9M3A0Z/FItRXnofC4OhjhCF9G/a2z2Y96xNy+Aryk5oGlXsdvPI0DFNjQeDTTqwi OgAhLFLf97KmJsYcyWtR0y23zF7BWBg+FRg9i/hruwbn96rd3acMQe+h0sOFXYNe9+Aq Kb0Ps4QrwHGtO4qJ15vwn4M3TiVg09TG65arDfunx8i4CoN8l9aiYFLyy4/0GJQn405N 2fSnFjm3DBjFjcs55BN11qmw6c7zu/Qkl9DhlYYS6qNC7Dh7BsxvhhkZ4HeCJaMfh+cX J9MWXeoEzkRf/BxOMMEoEzyimdukl6Fc4OapzF5fM+3Vf4g/+k5v0USLP9pLAGaPUr08 ZECg== X-Gm-Message-State: AOAM5337B9ngSLVhjgN/roinmQtKom2WvtjyfP0e7YZdiBRZEpvKb1VN zGHA5ZoBHMsQxKpFJyp/LWnE8uh9BXs9ZuyReHt2qw== X-Received: by 2002:a05:620a:103c:: with SMTP id a28mr4056658qkk.413.1643322403889; Thu, 27 Jan 2022 14:26:43 -0800 (PST) MIME-Version: 1.0 References: <20220120000409.2706549-1-rajatja@google.com> <20220121214117.GA1154852@bhelgaas> In-Reply-To: From: Rajat Jain Date: Thu, 27 Jan 2022 14:26:07 -0800 Message-ID: Subject: Re: [PATCH] PCI: ACPI: Allow internal devices to be marked as untrusted To: "Rafael J. Wysocki" Cc: Mika Westerberg , Greg Kroah-Hartman , Bjorn Helgaas , Len Brown , Bjorn Helgaas , ACPI Devel Maling List , Linux PCI , Linux Kernel Mailing List , Rajat Jain , Dmitry Torokhov , Jesse Barnes , Jean-Philippe Brucker , Pavel Machek , "Oliver O'Halloran" , Joerg Roedel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Rafael, Bjorn, Mika, Dmitry, Greg, Thanks a lot for your comments. On Tue, Jan 25, 2022 at 6:45 AM Rafael J. Wysocki wrote: > > On Tue, Jan 25, 2022 at 1:55 PM Mika Westerberg > wrote: > > > > On Tue, Jan 25, 2022 at 12:15:02PM +0100, Greg Kroah-Hartman wrote: > > > On Tue, Jan 25, 2022 at 12:58:52PM +0200, Mika Westerberg wrote: > > > > On Mon, Jan 24, 2022 at 08:27:17AM +0200, Mika Westerberg wrote: > > > > > > > This patch introduces a new "UntrustedDevice" property that can be used > > > > > > > by the firmware to mark any device as untrusted. > > > > > > > > > > I think this new property should be documented somewhere too (also > > > > > explain when to use it instead of ExternalFacingPort). If not in the > > > > > next ACPI spec or some supplemental doc then perhaps in the DT bindings > > > > > under Documentation/devicetree/bindings. > > > > > > > > Actually Microsoft has similar already: > > > > > > > > https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identifying-internal-pcie-ports-accessible-to-users-and-requiring-dma-protection > > > > > > > > I think we should use that too here. But because this property also applies to a root port (only), it only helps if the device is downstream a PCIe root port. In our case, we have an internal (wifi) device 00:14.3 (sits on the internal PCI bus 0), so cannot use this. > > > > > > But we do not have "dma protection" for Linux, so how will that value > > > make sense? > > > > Yes I think we do - IOMMU. That's the same thing what we do now for > > "External Facing Ports". This one just is for internal ones. > > > > > And shouldn't this be an ACPI standard? > > > > Probably should or some supplemental doc but not sure how easy these > > "properties" can be added there to be honest. AIUI, the principal comment I have received here is that this property needs to be documented somewhere. I agree. Rafael, do you know if this new property can be added to the ACPI spec, and if so, how to do so? I'm happy to initiate a process if someone can point me to, I just hope that publishing a new property to the ACPI does not have to block this patch. The other option I was thinking of was to use the same property name (say "untrusted-device") for both ACPI and device tree platforms, and document it in Documentation/devicetree/bindings/pci/pci.txt along with others. Since there are other properties there that seem to be used similarly (Mika highlighted some below), perhaps that is an acceptable solution? I had one last question on the property name itself. I was trying to understand why a property might have 2 names i.e. "external-facing" for DT and "ExternalFacingPort" in ACPI? Are there any naming convention requirements that require ACPI and DT property names to be different? Is "untrusted-device" an acceptable ACPI property name? Thanks & Best Regards, Rajat > > > > Some of these that we use in Linux too are from that same page: > > > > https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports > > > > Namely these: HotPlugSupportInD3, ExternalFacingPort, usb4-host-interface, > > usb4-port-number and StorageD3Enable. > > Right. > > We are kind of on the receiving end here, because at the time we learn > about these things the decisions to use them have been made already.