Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp306678ybg; Wed, 10 Jun 2020 01:03:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxaEz8XTtrFEDQSJD23GP5xNG1hGZfi0HcGyFkz18+beopbqdhmvaOqbDia8yOIG0cJfA+3 X-Received: by 2002:a17:906:cec5:: with SMTP id si5mr2124012ejb.447.1591776220840; Wed, 10 Jun 2020 01:03:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591776220; cv=none; d=google.com; s=arc-20160816; b=tC7N5culOzNXet1bwESO+nraxdY+7WZXHU3jmNtPBfQTKUOGwsgftp47US0/N/SbiW F2OIvMzZtu/x2+9mZBhjB1kX+Le1nd0HyFqz50Vl2xny2q2owd60hHUdDos1r8igSPrO t3dXnQtPeuetVgIdYrh5BEvQGzdfiw7KGC+bRe6mxJbPTMscoiBk5ZqZLaqixotGa8LG ppIa6xJqDpfXGlYqTucqafiZxTI625tp/Zw5uZMvpox3dDzaEXBk9tH2DK9LvtUusEw9 X35evANM8B3Yg2tvSrCG1444TwiHweq3SxseGjJyj8UBSdQsHlQ1/TSbnsqxkEMt7Lt4 cMkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=FigR6Fu5ol375mSGWPn8xPCDdjv0gWOe2L/pdNKXlMU=; b=aTMjqrIv7DTUNlu2wp2BRkXPzgWu1CZScttq4rYRInpw+oaVh/s33GTQcApSlceYMG 0QiRNMUp6FuV9GP/oCxV9h9gD9AS/gHeEO9+AxR1AddLuTm/tMU/rO0E+iCi9Bd0r3S3 B1uGK0UAXD9HKo6URlg/t0mfscbEjioIjyjwED6KCPAAw8c70bTf/ja6b/iyG2Z7+65y zJppPMXkv8K8nG5fzwKcWZVicPBTQkWmtVxiEv75sqC6LnaBwdGnIRYjGBqQh2TOyGa3 /cuwREQrOg6BNPBwsh3GeW9ioXWnza7F9FSf172rQhWGhNxV25SBq/tkx3/20/Au1pAB zvBQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=JfDwzSE1; 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=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m8si2557299ejq.294.2020.06.10.01.03.17; Wed, 10 Jun 2020 01:03:40 -0700 (PDT) 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=@linaro.org header.s=google header.b=JfDwzSE1; 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=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726728AbgFJIAg (ORCPT + 99 others); Wed, 10 Jun 2020 04:00:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59802 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726081AbgFJIAe (ORCPT ); Wed, 10 Jun 2020 04:00:34 -0400 Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [IPv6:2607:f8b0:4864:20::642]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 66036C03E96F for ; Wed, 10 Jun 2020 01:00:33 -0700 (PDT) Received: by mail-pl1-x642.google.com with SMTP id y18so663537plr.4 for ; Wed, 10 Jun 2020 01:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=FigR6Fu5ol375mSGWPn8xPCDdjv0gWOe2L/pdNKXlMU=; b=JfDwzSE1KL+Q3A2TyU/jrhZCyadqfoBvLT8/R1PiG7xIUCM9Np6BoUuvUThDVaPg8g BBcjRPSEvm7MKSwK6/6K9Fi+fCJ6glJxWTocuPbALAaJDHZUB6U1FgovZ/xxExGhG8rF fHpATrWhTB88V6xY/+U6CWxgy9fQoMI0/C9fbgUiK3NcPhIzEYHxXDsCeNaWpUUiovtO AdPGmoG+P5SK0964eCJdCf5aB102wsxPXShkx84U+V5Oa74EJJp7p/5s40c6MbV3Hxpp 2u40QuCnikfdSGIoh9UWqCCr6ZWo/IZYU78O8pz787ZET6ttaHdTHxNsRh/bwm/YG+Z+ y2KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=FigR6Fu5ol375mSGWPn8xPCDdjv0gWOe2L/pdNKXlMU=; b=h3ZJnA8I3XWHvZ4sFj2LNPinxnjlG0qi9U+Tz3cKo12KZLsgSASFfzE4/5aDh1lLDg Z2y46JcWd2X57gpVUzSDeDqhXBdTBam0mx7+jHAvRs6TlrHX5MJnxYPjg7loe1RW4jK1 ta5MRRIdnQBMlIhEsX5Lh5vj9sdi854qP7GEsIrRyJfzclgJyo1uZAJgT14tYaauJ7jE cmeho1r4ZqTJjgHtIOUvPLG5fUjb2A43AghylDHcyCMkXk1fwkrxJJ4mEkzY+8xZgRau O5jJnK3ZNTHJqPZNC3RRR5EEKV/7gzVFQY2kG0hovIUdOpvUje+BrGSuPYgaDoa18CGu SUNw== X-Gm-Message-State: AOAM533Lbl7rbzn/rtVcpIZdHmbUIyysTIqKlZqYpzUFGhXbpv39kXby SGcFNj44Z2LynZeHPOCoHh09X04o4NlVFA== X-Received: by 2002:a17:902:ee12:: with SMTP id z18mr1884864plb.274.1591776032640; Wed, 10 Jun 2020 01:00:32 -0700 (PDT) Received: from [10.175.1.226] ([45.135.186.20]) by smtp.gmail.com with ESMTPSA id g19sm11992320pfo.209.2020.06.10.01.00.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Jun 2020 01:00:32 -0700 (PDT) Subject: Re: [RFC PATCH] PCI: Remove End-End TLP as PASID dependency To: Jean-Philippe Brucker Cc: Bjorn Helgaas , Greg Kroah-Hartman , Arnd Bergmann , kenneth-lee-2012@foxmail.com, Wangzhou , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org References: <1591762694-9131-1-git-send-email-zhangfei.gao@linaro.org> <20200610074633.GA6844@myrica> From: Zhangfei Gao Message-ID: Date: Wed, 10 Jun 2020 16:00:25 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200610074633.GA6844@myrica> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/6/10 下午3:46, Jean-Philippe Brucker wrote: > On Wed, Jun 10, 2020 at 12:18:14PM +0800, Zhangfei Gao wrote: >> Some platform devices appear as PCI and have PCI cfg space, >> but are actually on the AMBA bus. >> They can support PASID via smmu stall feature, but does not >> support tlp since they are not real pci devices. >> So remove tlp as a PASID dependency. >> >> Signed-off-by: Zhangfei Gao >> --- >> drivers/pci/ats.c | 3 --- >> 1 file changed, 3 deletions(-) >> >> diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c >> index 390e92f..8e31278 100644 >> --- a/drivers/pci/ats.c >> +++ b/drivers/pci/ats.c >> @@ -344,9 +344,6 @@ int pci_enable_pasid(struct pci_dev *pdev, int features) >> if (WARN_ON(pdev->pasid_enabled)) >> return -EBUSY; >> >> - if (!pdev->eetlp_prefix_path) >> - return -EINVAL; >> - > This check is useful, and follows the PCI specification (4.0r1.0 > 2.2.10.2 End-End TLP Prefix Processing: "Software should ensure that TLPs > containing End-End TLP Prefixes are not sent to components that do not > support them.") Thanks Jean, > > Why not set the eetlp_prefix_path bit from a PCI quirk? Unlike the stall > problem from the other thread, this one looks like a simple design mistake > that can be fixed easily in future iterations of the platform: just set > the "End-End TLP Prefix Supported" bit in the Device Capability 2 Register > of all bridges. Yes, we can still set eetlp_prefix_path bit from a PCI quirk. And we also have considered adding this bit in Device Capability 2 Register in future silicon. But we hesitated that it does reflect the real function: from register, it can support tlp, but in fact, it does not. Thanks