Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2383104yba; Fri, 10 May 2019 10:32:55 -0700 (PDT) X-Google-Smtp-Source: APXvYqzaEOTIgqR3GNN/FkSJYSByTUxet8sXLHMYB2KNL6XCG3pJBBYMr9p/yzNstqUveaspS5SP X-Received: by 2002:a63:1604:: with SMTP id w4mr15580773pgl.148.1557509575022; Fri, 10 May 2019 10:32:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557509574; cv=none; d=google.com; s=arc-20160816; b=hvgJqNLDfpvOkNKA591HSyN1elj7nJoNW8JelxRBEAaxdCaPGdRVW1/HGr2v8RXRoV CUegNFDfoZnYmOg9r7VHS0+fn1UTVqIQYUCK0Z62QRGxSHakO1sxCNgov2uU55Mq9XEA eauCnBNEaPgB2bz1DHEbEsOfy8Eb7HTFv0i4ZXSr3gXSJ8o750ChGjzYrY/y49y9H3kk EtpZjVcFpeGm1fIUzgsrrgE5yAeRcIlQs6UiF2tGzLtrWTrtb+IiFZCQXLXH6r69720y p3+elTLpWoPNkDTOgW6/B2y2XC9K4kn4MvhS27761rY4V46daMKVja9ZG+AvZrP2RRn2 UMcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=MgLlmbO5oMMj/WOVuVfMM43xVBSJ5yVsa9xDeCdjLmk=; b=jigTVDv/i3maJSJVyk/cwO/NM9nY6S+4t0eJJMy1zNAXiTALHLwayIzvaJwxyvnf0P rjMM8dNVL90A4Lq5BmH3tMPvNFPAWiMDS3JKH1Q6Kg+6BnOrfz7Sps/C8aooB+4l/bmm 3F6VnSCToBVIoz6QkKnpg8KWovlMemvN6KN5/HcI1bQjW1gpR14FKAS/ibAJRM3Hf1uG midyAsYDcqGHFCq5jSgriDdUASEoMNg4I5OcEMFjwd6nPV8eJtxE6Nnm1srJoWC9RQ/z To/tgha9M0sE9+z43+NBHN4dMVj6jsthz0rlI8VG4rXBlmaAFbiGwPvxss53iO3fKwyd tt8w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=d5iGk90S; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id f92si8227882plf.100.2019.05.10.10.32.39; Fri, 10 May 2019 10:32:54 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=d5iGk90S; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1727735AbfEJQq1 (ORCPT + 99 others); Fri, 10 May 2019 12:46:27 -0400 Received: from mail.kernel.org ([198.145.29.99]:57982 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727678AbfEJQq0 (ORCPT ); Fri, 10 May 2019 12:46:26 -0400 Received: from localhost (50-81-62-123.client.mchsi.com [50.81.62.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 53FD621479; Fri, 10 May 2019 16:46:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557506784; bh=LEjaS1MAo+FVs84vgyW9ohJdElC+EdhY5JNBgJJ0kXc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=d5iGk90ST5ha9qiSiEKOuBLBE/5YfAGKZZqMDt3dtoEyUp2xOSPufHTzJvUhtgSuH bzfRXNuc3hmP81jpY554uu1MC5PG/LY4kYnGnlGLT4d0b3UEoK6V9TK/XUwJO+/rY9 JrSIJXoLDzmEERceK0J4TLYrf8Ptwo0Wc96tETj0= Date: Fri, 10 May 2019 11:46:23 -0500 From: Bjorn Helgaas To: Vidya Sagar Cc: Thierry Reding , "lorenzo.pieralisi@arm.com" , "robh+dt@kernel.org" , "mark.rutland@arm.com" , Jonathan Hunter , "kishon@ti.com" , "catalin.marinas@arm.com" , "will.deacon@arm.com" , "jingoohan1@gmail.com" , "gustavo.pimentel@synopsys.com" , Mikko Perttunen , "linux-pci@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-tegra@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Krishna Thota , Manikanta Maddireddy , "sagar.tv@gmail.com" Subject: Re: [PATCH V5 03/16] PCI: Export pcie_bus_config symbol Message-ID: <20190510164623.GI235064@google.com> References: <20190424052004.6270-1-vidyas@nvidia.com> <20190424052004.6270-4-vidyas@nvidia.com> <20190503110732.GC32400@ulmo> <80616ff5-d7a5-84a4-a71b-569e340d128c@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80616ff5-d7a5-84a4-a71b-569e340d128c@nvidia.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vidya, On Fri, May 10, 2019 at 11:51:24AM +0530, Vidya Sagar wrote: > > -----Original Message----- > > From: linux-pci-owner@vger.kernel.org On > > Behalf Of Thierry Reding > > Sent: Friday, May 3, 2019 4:38 PM > > To: Vidya Sagar > > On Wed, Apr 24, 2019 at 10:49:51AM +0530, Vidya Sagar wrote: > > > Export pcie_bus_config to enable host controller drivers setting it to > > > a specific configuration be able to build as loadable modules > > > > > > Signed-off-by: Vidya Sagar > > It doesn't look to me like this is something that host controller drivers are > > supposed to change. This is set via the pci kernel command- line parameter, > > meaning it's a way of tuning the system configuration. > > Drivers should not be allowed to override this after the fact. > > > > Why do we need to set this? > Here is the reason I'm doing it. > First things first, Tegra194 supports MPS up to 256 bytes. > Assume there are two endpoints with MPS supported up to > a) 128 bytes (Ex:- Realtek NIC with 8168 controller) > b) 256 bytes (Ex:- Kingston NVMe drive) > Now, leaving "pcie_bus_config" untouched in the driver sets it to > PCIE_BUS_DEFAULT by default. With this setting, for both (a) and (b), > MPS is set to 128, which means, even though Tegra194 supports 256 MPS, it is not > set to 256 even in case of (b) thereby not using RP's 256 MPS feature. > If I explicitly set pcie_bus_config=PCIE_BUS_PERFORMACE in the code, then 256 MPS is set when > (b) is connected, but when (a) is connected, for root port MPS 256 is set and for > endpoint MPS 128 is set, because of which root port tries to send packets with 256 > payload that breaks functionality of Realtek NIC card. > The best option I've found out is that when I set 256 in PCI_EXP_DEVCTL of root port > explicitly before link up and use pcie_bus_config=PCIE_BUS_SAFE, then, I get the best of both > PCIE_BUS_DEFAULT and PCIE_BUS_PERFORMANCE i.e. with (a) connected, MPS is set to 128 in both RP > and EP and with (b) connected, MPS is set to 256 in both RP and EP. > > So, is it like, pcie_bus_config shouldn't be set to anything explicitly in the driver and depending on the > platform and what is connected to root port, kernel parameter can be passed with appropriate setting? Host controller drivers shouldn't change this unless there's some host controller defect that means the generic code can't do the right thing. Even then, I'd prefer that the host controller driver merely set a quirk bit that describes the defect, e.g., "mps_*_broken". Then the generic code could pay attention to that and we wouldn't have to make "pcie_bus_config" a part of the ABI. From your description, it sounds like there's nothing actually wrong with the Tegra194 hardware, but the generic code isn't as smart about setting MPS as it possibly could be. My solution to that would be to make the generic code smarter so everybody can benefit. Bjorn > > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index > > > f5ff01dc4b13..731f78508601 100644 > > > --- a/drivers/pci/pci.c > > > +++ b/drivers/pci/pci.c > > > @@ -94,6 +94,7 @@ unsigned long pci_hotplug_mem_size = > > > DEFAULT_HOTPLUG_MEM_SIZE; unsigned long pci_hotplug_bus_size = > > > DEFAULT_HOTPLUG_BUS_SIZE; > > > > > > enum pcie_bus_config_types pcie_bus_config = PCIE_BUS_DEFAULT; > > > +EXPORT_SYMBOL_GPL(pcie_bus_config); > > > > > > /* > > > * The default CLS is used if arch didn't set CLS explicitly and not > > > -- > > > 2.17.1 > > >