Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp1402998ybl; Thu, 22 Aug 2019 14:03:26 -0700 (PDT) X-Google-Smtp-Source: APXvYqxjR4bAyUDGOIRwm/IDhlrz0yHUaBp/qZaSWcOiHO9AQ2vTaqReW+qK6714yjmqSMvqmK+k X-Received: by 2002:a17:902:8ecc:: with SMTP id x12mr857106plo.258.1566507806883; Thu, 22 Aug 2019 14:03:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566507806; cv=none; d=google.com; s=arc-20160816; b=acgZV9VBrnd9LXPzMmZAKhjloZrydDF5V2eyyynWYmV8xmamtQf5nczNPVGsd92fnb WhYu6J/hYf3Iziz3G4WyQiugN7lwmxsdFX7lCQsxCbsKFECQtNCScsPY9OaM5EctLkk5 831nXEev/Y9XslcBQHQsbDrvFR+0aTf2Rh+hKhkvgh3St+p1UZCOSQnXtCUkSOqIN+h6 QnX/BSlactgw4esXosUCk9Kctd1OE88nWo+K3PrIDYvof4F3zRJZSBzrOKcQcvfdBNpC aWRXvbphYWuCnqB31qWvcNS17avZsxt69S0bwxXQojz5iF9F5bTE+n96iGbXhv4WdNnk 3ejQ== 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; bh=rea/bGzmavD6kntnPjHgI/EzZ1r/q2LuRfxmKGFU2Tw=; b=klVtOtjRxVm6NZ2zCcdpLozKTw4tGE1C4pH/WdIy0KFPVniULAD6t96bbzJWHx4Zca o8K6uBQFiCOvYMSKRn1rKyz5zVG9Qy7vfB/EFKfPG1KTCQfMXz2HIr2fMmQQNfod1tq4 4U9lubPKirPCU7bcozM3M81+3y4Av2VUBLSNrQNn40Nx20MA8oVhPdBeTbBibYwns0Eq OKUV62DWPaSPsv61rPGMJ/V1WKWrMTOHInWTII8SVS+4K0M4Jp9AoxKBNAGPpzTQqZJP xi9bmK2+5NJqCvicKsGMTZn37vF5R21jKvWL52BRX5hzgs+EqWJF3pKWC+G+qsoxBOJc 2LRw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j1si642457pfa.91.2019.08.22.14.03.11; Thu, 22 Aug 2019 14:03:26 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390167AbfHVQsX (ORCPT + 99 others); Thu, 22 Aug 2019 12:48:23 -0400 Received: from foss.arm.com ([217.140.110.172]:48996 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731428AbfHVQsX (ORCPT ); Thu, 22 Aug 2019 12:48:23 -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 E40FC28; Thu, 22 Aug 2019 09:48:21 -0700 (PDT) Received: from e121166-lin.cambridge.arm.com (unknown [10.1.196.255]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3C2FD3F718; Thu, 22 Aug 2019 09:48:20 -0700 (PDT) Date: Thu, 22 Aug 2019 17:48:15 +0100 From: Lorenzo Pieralisi To: "Z.q. Hou" Cc: "linux-pci@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "gustavo.pimentel@synopsys.com" , "jingoohan1@gmail.com" , "bhelgaas@google.com" , "robh+dt@kernel.org" , "mark.rutland@arm.com" , "shawnguo@kernel.org" , Leo Li , "andrew.murray@arm.com" , "M.h. Lian" Subject: Re: [PATCHv2 0/4] Layerscape: Remove num-lanes property from PCIe nodes Message-ID: <20190822164815.GA12855@e121166-lin.cambridge.arm.com> References: <20190820073022.24217-1-Zhiqiang.Hou@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190820073022.24217-1-Zhiqiang.Hou@nxp.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 20, 2019 at 07:28:37AM +0000, Z.q. Hou wrote: > From: Hou Zhiqiang > > On FSL Layerscape SoCs, the number of lanes assigned to PCIe > controller is not fixed, it is determined by the selected > SerDes protocol. The current num-lanes indicates the max lanes > PCIe controller can support up to, instead of the lanes assigned > to the PCIe controller. This can result in PCIe link training fail > after hot-reset. > > Hou Zhiqiang (4): > dt-bindings: PCI: designware: Remove the num-lanes from Required > properties > PCI: dwc: Return directly when num-lanes is not found > ARM: dts: ls1021a: Remove num-lanes property from PCIe nodes > arm64: dts: fsl: Remove num-lanes property from PCIe nodes > > Documentation/devicetree/bindings/pci/designware-pcie.txt | 1 - > arch/arm/boot/dts/ls1021a.dtsi | 2 -- > arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 1 - > arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 3 --- > arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 6 ------ > arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 3 --- > arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 4 ---- > drivers/pci/controller/dwc/pcie-designware.c | 6 ++++-- > 8 files changed, 4 insertions(+), 22 deletions(-) What a mess. I am going to apply these but first if anyone can explain to me what commit 907fce090253 was _supposed_ to to I would be grateful, I read it multiple times but I still have not understood it. This series does the right thing but why things are they way they are in the mainline honestly I have no idea, this does not make any sense in the slightest: ret = of_property_read_u32(np, "num-lanes", &lanes); if (ret) lanes = 0; /* Set the number of lanes */ val = dw_pcie_readl_dbi(pci, PCIE_PORT_LINK_CONTROL); val &= ~PORT_LINK_MODE_MASK; switch (lanes) { case 1: val |= PORT_LINK_MODE_1_LANES; break; case 2: val |= PORT_LINK_MODE_2_LANES; break; case 4: val |= PORT_LINK_MODE_4_LANES; break; case 8: val |= PORT_LINK_MODE_8_LANES; break; default: dev_err(pci->dev, "num-lanes %u: invalid value\n", lanes); return; } why do we need to set lanes to 0 if num-lanes is not present ? To print an error message ? I really do not understand this code. Lorenzo