Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp367678pxb; Thu, 2 Sep 2021 06:09:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwo3wHRiSCCgu6AofMZaUhAWQ5sSq2x/BAidtowC5TRGZ2UYPogRT4SIPJt86X1jHu6KeGT X-Received: by 2002:a05:6e02:964:: with SMTP id q4mr2314033ilt.229.1630588175069; Thu, 02 Sep 2021 06:09:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630588175; cv=none; d=google.com; s=arc-20160816; b=VhvoTR+iMqoWycR92cxGG2HY1ft7yVFU1ZXSL2poTj63L1EfZqSyhtdB7WjkqsvsoU d8RaYGnv3BB2EUHEjMWl0ZBi7BFMxR4+4LiKVoTDT24GfADvpWKeWMoWO3xs0skcxrW3 v2Zfii+4Qb7SDXY7HJ/hZbH6WL2OTPFihkM99xajfRLoUAc8D6Pzqhnz710thcVwuEna VbAcBj58BdUTdIrEQYwnOvul17lFiUqWkyZKCHjCL+ZpBV1RHlV2BZzYNLbSH6geOG6n g2Eckk1RDbk2bEQX+wG92K2NUA8h2qKKvrJ4nq573PNMP//ucXo2NoUXMohdmciuSRlt C++A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=unKIazBqyvQbrR9UQIRevnjqdPPRRF9AKLZwTd2FBTw=; b=FqR+Gy17s8SYJ1MGwdtves4BNK/8gXkINch748mRFeEciiWBDC8T1avAD8OZLhYuDX /KTPLsjdrQE8wu9p5Ca2n72CsoRMWumM6gX9DtDwOpBOyvsAExcwBn+1klA+ojijeqAH 0QRD5t7mlqXX7Smtjkxlunrnt4dQbQVeJpAs/rP08/yFRbZyx8OXNZjZ1LzN9KxNfVUf yJ8MFJjYQEMdv1vvOwlPB9YIjtsrvju1TBiY6YxOzFH+KjZcE2SiQXQzWIMx5uKorZkQ HaPxTf2GYPhil93Wbr3YHcn2lod5zKkQxUH80QokSwUe4/guHb5zsP4pAjHscyynbp6x OXgw== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 192si1836316ioc.91.2021.09.02.06.09.17; Thu, 02 Sep 2021 06:09:35 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344734AbhIBNIU (ORCPT + 99 others); Thu, 2 Sep 2021 09:08:20 -0400 Received: from foss.arm.com ([217.140.110.172]:49222 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234054AbhIBNIS (ORCPT ); Thu, 2 Sep 2021 09:08:18 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6FBE51FB; Thu, 2 Sep 2021 06:07:19 -0700 (PDT) Received: from [10.57.15.112] (unknown [10.57.15.112]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 41B0D3F5A1; Thu, 2 Sep 2021 06:07:17 -0700 (PDT) Subject: Re: [PATCH v4] iommu/of: Fix pci_request_acs() before enumerating PCI devices To: Anders Roxell Cc: Marek Szyprowski , Wang Xingang , Rob Herring , Will Deacon , joro@8bytes.org, helgaas@kernel.org, Rob Herring , Greg Kroah-Hartman , iommu@lists.linux-foundation.org, Linux Kernel Mailing List , linux-pci@vger.kernel.org, xieyingtai@huawei.com, "linux-arm-kernel@lists.infradead.org" , Linux-Next Mailing List References: <1621566204-37456-1-git-send-email-wangxingang5@huawei.com> <01314d70-41e6-70f9-e496-84091948701a@samsung.com> From: Robin Murphy Message-ID: <25b0b214-b9b4-4066-3912-a5bcb054dc0d@arm.com> Date: Thu, 2 Sep 2021 14:07:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-09-02 13:51, Anders Roxell wrote: > On Wed, 1 Sept 2021 at 11:58, Robin Murphy wrote: >> >> On 2021-09-01 09:59, Marek Szyprowski wrote: >>> On 21.05.2021 05:03, Wang Xingang wrote: >>>> From: Xingang Wang >>>> >>>> When booting with devicetree, the pci_request_acs() is called after the >>>> enumeration and initialization of PCI devices, thus the ACS is not >>>> enabled. And ACS should be enabled when IOMMU is detected for the >>>> PCI host bridge, so add check for IOMMU before probe of PCI host and call >>>> pci_request_acs() to make sure ACS will be enabled when enumerating PCI >>>> devices. >>>> >>>> Fixes: 6bf6c24720d33 ("iommu/of: Request ACS from the PCI core when >>>> configuring IOMMU linkage") >>>> Signed-off-by: Xingang Wang >>> >>> This patch landed in linux-next as commit 57a4ab1584e6 ("iommu/of: Fix >>> pci_request_acs() before enumerating PCI devices"). Sadly it breaks PCI >>> operation on ARM Juno R1 board (arch/arm64/boot/dts/arm/juno-r1.dts). It > > We've seen this on ARM Juno R2 boards too in the Linaro testfarm. > > The problem is that the device can't get the "SATA link up" while booting. > > see https://lkft.validation.linaro.org/scheduler/job/3416767#L577 Hmm, what's odd there is that you don't seem to be even detecting any of the endpoints there. Notably, the switch (which both the slots and the on-board endpoints are behind) *does* support ACS even though the Root Complex doesn't, so I wonder if it's getting enabled there and causing it to forward TLPs with ACS bits set which the RC doesn't like? I'm far from a PCI expert, but I might try running this patch on my board to see if anything else stands out. Robin. > When reverting this patch we are able to see the "SATA link up". > > Cheers, > Anders >