Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1244494pxb; Tue, 1 Feb 2022 23:46:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJyPRHxMitGQDAVxf8MJE9TfnCbS7owDrdwZvW0wtaKTXQhRNFPHkEgtHWqUQt87NsM4/iMo X-Received: by 2002:a17:906:eb8a:: with SMTP id mh10mr21215094ejb.492.1643787986554; Tue, 01 Feb 2022 23:46:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643787986; cv=none; d=google.com; s=arc-20160816; b=g2LurQuPClCHE2sqpta9Me0BkdECGZ2OBeIEkWMoDgdsfBjFz5EO8+aQzGVvRXd43u 9tzkT8z023V/Kq5tyaX9kxY+5uPcCpgwz/Mer+przWOafl/+/86Zh1WSNXq/5iwCJ+BV G2Ci9ofwL1ycq3p5CHn2e3WlYM6ndDv+isnQ0v+r7IR3L6Ovq25nJDXY3EepCf1odv9N XjgQTvlUm+YEMV1AXnkUd+oqoxPaNdrlazaDn35MQF5baYZpZ4lwcTgm/0Zvy6wbiWpy O/6Z5uchcIKwnKFyWFkG+Dp9NqVQRZEon/mDqe+4+xW6T6SxS0hFWciVVXa+3vGgmH3j 7aSw== 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=H8NaK6sogIQ9vr23uq3ONCRZOGt+JDgbjU55p0WZp4U=; b=s8GnZXsBnnDFrX60rYIy9V8Eq3dT8cj97M7jYj8or8RMklzHh9hfJtE9ejgU9v0zek VkmFWyuXVNR7GXxhwGQn/PcDDdeZzwNfRK8WsgSwY+OPh/WKxiGGdk6auB2eNa+6Tl2j Fu7quD0fwUMkeK8B+gl8N+OhjFhhUKp9H8oIZTvvmGGHhUzAi3mKxnyLMxQZzVfFn1Gr 8hugtWKdvTKkzzQ9HMF6R/ugIxcavwCOa19npaZ+11pSWYETcH01g+UugwmuwC1NwpI1 GYK3w+dd2O7EXtBo57LQGZCRmRPfJC54JUu1rTeqTByKzJHQVy3mguM1Ex7Aj0Ep9Sl8 GQNA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=bfP6aLcc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e7si12971602edz.397.2022.02.01.23.46.01; Tue, 01 Feb 2022 23:46:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=bfP6aLcc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S243771AbiBBCGg (ORCPT + 99 others); Tue, 1 Feb 2022 21:06:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44488 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231835AbiBBCGf (ORCPT ); Tue, 1 Feb 2022 21:06:35 -0500 Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6C3EAC06173B for ; Tue, 1 Feb 2022 18:06:35 -0800 (PST) Received: by mail-pj1-x1036.google.com with SMTP id h12so18871812pjq.3 for ; Tue, 01 Feb 2022 18:06:35 -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=H8NaK6sogIQ9vr23uq3ONCRZOGt+JDgbjU55p0WZp4U=; b=bfP6aLccvV4nBE91AzyhEB+9wzkc3lnTdeQz2pDYN+pboTQ/PNybvwrn+LpcyKBBxv KeWaA+rToyLUpVDwgxI7FDgZtJGZOoMSTMPsXpPVcPiqQyWtb2hOp8ZCp27GHqDI6sb1 0GOVrybLfDhc8lgnSrII4ufgbX/XH6ixzM7lF3uFWj44zEQ6yJZwv6q+szt45nm91d7m X8DZr01oeCBpXuNWL4yP263MF73rs3FBn5OxE7LQ/rCISl86epCO1jHqvAJ9uqZNIU6H PXs1dzc2aqAO/WtzZGqCliKcS+jd6L2aiYOnXmSA0C6GFVrXo8k8BeNRgHnxGVTJFO+c B1cw== 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=H8NaK6sogIQ9vr23uq3ONCRZOGt+JDgbjU55p0WZp4U=; b=KGazxjh72qfeY3Ixqc6JoWHcWz7gHxTu55UypyL3+u6kOldFZhg8UmxgWlXITZ4Dnh mJL14vlc+8DtLlSAkLUF+aXw2QYSb3VNUGHeBULGsmyyJ6sNDxTBOXIcG7JH0jsQVQ/w aiAl7KYQoLrHFatmfyBmoRuqhdQhjO/wQ4Z+PbzQxYMDosW1l2Ej75E/RDeV/iktyw7o VJQSeDHPeUGJg9MAxFfGGqHwGvOh5HeFAA/fwKutHGHs/6XBCWe1CQ/bejTQTfMphY1W uTmemfoQpCqvA2VuguIxvv2CGhK3RrBgiqdkDB3Flk12UO671GJcGUcFYZGl/w1mcx+T /kyQ== X-Gm-Message-State: AOAM532VgwTcTS5MC1aUBnRhRvB/85ZnCSLdxodcWfCP8zkXH+6ThaXz FVqQbZah6CQR1UEkB3dWhBCgh87fTJyZRwuB/HIRUA== X-Received: by 2002:a17:902:ced2:: with SMTP id d18mr28827516plg.21.1643767594601; Tue, 01 Feb 2022 18:06:34 -0800 (PST) MIME-Version: 1.0 References: <20220121214117.GA1154852@bhelgaas> In-Reply-To: From: Rajat Jain Date: Tue, 1 Feb 2022 18:05:58 -0800 Message-ID: Subject: Re: [PATCH] PCI: ACPI: Allow internal devices to be marked as untrusted To: Mika Westerberg Cc: "Rafael J. Wysocki" , 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 On Mon, Jan 31, 2022 at 11:57 AM Rajat Jain wrote: > > Hello Mika, Rafael, > > On Sun, Jan 30, 2022 at 10:42 PM Mika Westerberg > wrote: > > > > Hi, > > > > On Sun, Jan 30, 2022 at 03:30:39PM +0100, Rafael J. Wysocki wrote: > > > > I'm open to doing so if the others also feel the same way. IMHO > > > > though, the semantics of ACPI "DmaProperty" differ from the semantics > > > > of the property I'm proposing here. > > > > > > > > The current (documented) semantics (of "DmaProperty"): *This device > > > > (root port) is trusted*, but any devices downstream are not to be > > > > trusted. > > > > > > > > What I need and am proposing (new "UntrustedDevice"): *This device as > > > > well as any downstream devices* are untrusted. > > > > > > > > Note that there may be firmware implementing "DmaProperty" already out > > > > there (for windows), and if we decide to use it for my purposes, then > > > > there shall be a discrepancy in how Linux uses that property vs > > > > Windows. Is that acceptable? > > > > > > It may be confusing, so I'd rather not do that. > > > > > > The platform firmware will use it with the Windows use case in mind > > > and if it has side effects in Linux, problems are likely to appear in > > > the field. > > > > > > So the question is rather not about it being acceptable, but about > > > whether or not this is generally going to work. > > > > I was kind of implying that we could perhaps contact Microsoft and ask > > them if the wording could be changed to cover all the devices, not just > > PCIe root ports. I think this is something they will also need for > > things like internal WI-FI controllers. > > We (Chromeos) do not have a contact at Microsoft, not sure if Intel > does. If someone can point me to a contact I will be happy to initiate > a conversation. However, given that they have already published it, > and changing the semantics might mean they will also have to change > windows implementation. Not sure if we have enough leverage with > Microsoft here, so I wouldn't have any high hopes though. To keep everyone updated, Mika has helped me initiate a conversation with Microsoft on this (Thanks a lot Mika!). We're still waiting to hear their feedback. Until then, I've posted a v2 for review at: https://patchwork.kernel.org/project/linux-pci/patch/20220202020103.2149130-1-rajatja@google.com/ If we can reach an agreement with Microsoft, I can change the property name in the patch (to "DmaProperty"), but would appreciate review of any other aspects of v2 in the meantime. Thanks & Best Regards, Rajat > Like Rafael > said, we're on the receiving end here. > > Rafael, one last question: is "untrusted-device" an acceptable ACPI > property name, or does it have to be Camel case? > > Thanks & Best Regards, > > Rajat > > > > > If that's not possible then no objections adding "UntrustedDevice". We > > just need to deal with the "DmaProperty" anyway and both end up setting > > pdev->untrusted in the similar manner.