Received: by 2002:a05:6a10:8a4d:0:0:0:0 with SMTP id dn13csp1060592pxb; Fri, 13 Aug 2021 12:29:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwMbiU1QtsruazaA9R7ySRHV5tiduT9t//T5OFCH9BafLnj6Y2qVMdpWft+U08kg0687iC+ X-Received: by 2002:a17:906:7302:: with SMTP id di2mr3948191ejc.409.1628882989912; Fri, 13 Aug 2021 12:29:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628882989; cv=none; d=google.com; s=arc-20160816; b=XXLZLammrgIf5xdcZicEu/JXLxeUASGRMHsnZxea0OXMO7E6NFQlCb/0kInyKv1HpQ +gadGgvhGGj+/0U0nUDa/8yoVKKQDHP/3eLmK1N/8hSJSfq9/pJeRMFR6rYVIEtWwxgi d583HVSqW1HWofCjhP5cPW+lc6nXUtA8AhaAf0ckqB21ZHg5EnwuQkm+n5huNDxegQdK guZZcuvquINIHuB5PgMd8a9O7c/ETTcP3TJDVepR2DAOnEO6qiXzg7mSm8CyLlEneycF nWeiMWDzmfr60FjKMyCaZoWgrYNr0rgJoyjDOjwA21DPFFxhMY2nsNpvy7NDyObEKCLu 2Nsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:message-id:subject:cc:to:from:date :dkim-signature; bh=uILqcGcFiEKxSNc3rSVzqWOz7YTomYBJailaxIdANuM=; b=Dle+5IJTKRiPSYsQZdCG6nPFz2uIB+LhC0Wd7cChRqzW1+9DNKHoCbyhmCLMTMp2P4 RcHZV9bpqi9bAgXRaQwhlllx0fXv0lnJhoJRqOOCFZZs6ORHAmWBBR8JmBsg2kvsfPb7 QqUyBi1cVFvksmBBg2nzikcHqCuwv1/n2VvQzXgmFAPIKezAWLhLWWYNbBPDIfVTYA3z vI1skeJIfS6Pvrwia6Dysp6Q3i5YEcnh4b++dcM6Qhl9OtbPfkLPidYlJGeojfemy4nc 8LZXGxjskk27xWz13s7cqrezaIVmWwj/8H2OZe8m15kbFkIUIwA6dZTWNOlZS+si4diT lH8Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="o4dhA/iD"; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id by8si2401049ejb.590.2021.08.13.12.29.25; Fri, 13 Aug 2021 12:29:49 -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=@kernel.org header.s=k20201202 header.b="o4dhA/iD"; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233662AbhHMTXY (ORCPT + 99 others); Fri, 13 Aug 2021 15:23:24 -0400 Received: from mail.kernel.org ([198.145.29.99]:42084 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229601AbhHMTXX (ORCPT ); Fri, 13 Aug 2021 15:23:23 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 32EA3608FC; Fri, 13 Aug 2021 19:22:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1628882576; bh=IwlgeTmsHnWv+9SX8uMxnltkECACWYzF6awWr2YZcrU=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=o4dhA/iDEfMJoYZ2bq9y+AcVgg5wyrNkht08+6Sokb5kptg8j5bwvX9SmE5lLoUTh ZnDMjBLQ6j7rDj0Ln6vUmfsasFfH5boVhF99nKnzKOL2/Net1VIjBOEB1zpvk8m8Mx OCjYYYH+WEcZkiI6u2jmHs6LaAuK9KvOOXRVy4rHDv36CdDd9TAV3hI+JX01X53NwO LW7GPazfmHAcDUbmk5dexWqvvSJH6su5jN6Bcy8neKCTPMz994v5+NdsupUfw2r6mY 1IGPOlgeF8kz9pBj2oeCpdpcM2EJ84ewb7R1xMPk+aJ9j0O0T51amSvu65Xisy2/MQ YztMO3hb56Y+g== Date: Fri, 13 Aug 2021 14:22:54 -0500 From: Bjorn Helgaas To: Krzysztof =?utf-8?Q?Ha=C5=82asa?= Cc: Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Bjorn Helgaas , linux-pci@vger.kernel.org, Artem Lapkin , Neil Armstrong , Huacai Chen , Rob Herring , Lorenzo Pieralisi , Richard Zhu , Lucas Stach , linux-kernel@vger.kernel.org Subject: Re: [PATCH] PCIe: limit Max Read Request Size on i.MX to 512 bytes Message-ID: <20210813192254.GA2604116@bjorn-Precision-5520> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 13, 2021 at 02:09:51PM +0200, Krzysztof HaƂasa wrote: > Krzysztof, :-) > > > Would it be possible to implement this particular MRRS fix as a quirk > > only for the i.MX6 controller? Unless this is something that we need in > > the core, a quirk would be preferred over something that changes the PCI > > core. > > I have briefly considered it, but I think it would be *much* more > complicated and error-prone. It also appears that there are more > platforms which need it - the old CNS3xxx, which currently subverts the > PCIE_BUS_PEER2PEER, the loongson, keystone, maybe all DWC PCIe. > Multiplication of the "quirk" code doesn't really look good to me. > > TBH I don't think of this as of a "quirk" - all systems have MRRS > limits, it just happens that these ones have their limit lower than 4096 > bytes. This isn't a limitation of a particular PCIe device, this is a > common limit of the whole system. Do you have a reference for this? I don't see anything in the PCIe spec that suggests platforms must limit MRRS, and it seems that only these ARM-related controllers have this issue. If there *is* a platform connection here, we'll need some way to discover it, e.g., an ACPI _DSM method or similar. The only guidance in the spec about setting MRRS is that: - Software must set Max_Read_Request_Size of an isochronous-configured device with a value that does not exceed the Max_Payload_Size set for the device (PCIe r5.0, sec 6.3.4.1) - The Max_Read_Request_Size mechanism allows improved control of bandwidth allocation in systems where Quality of Service (QoS) is important for the target applications. For example, an arbitration scheme based on counting Requests (and not the sizes of those Requests) provides imprecise bandwidth allocation when some Requesters use much larger sizes than others. The Max_Read_Request_Size mechanism can be used to force more uniform allocation of bandwidth, by restricting the upper size of Read Requests (sec 7.5.3.4 implementation note)