Message ID | 20240117102526.557006-3-s-vadapalli@ti.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-28829-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:42cf:b0:101:a8e8:374 with SMTP id q15csp814228dye; Wed, 17 Jan 2024 02:26:45 -0800 (PST) X-Google-Smtp-Source: AGHT+IG0IIEZ7ElSsDCzNlGurwBfAWZgHKJRJWF3FlGSBnaSwJXugke7XG6KdMNGvBpXHMhKB1Qt X-Received: by 2002:a05:6a20:c52a:b0:19a:1c9a:3fb4 with SMTP id gm42-20020a056a20c52a00b0019a1c9a3fb4mr7136393pzb.107.1705487205579; Wed, 17 Jan 2024 02:26:45 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1705487205; cv=pass; d=google.com; s=arc-20160816; b=zYOVWphXulAmI3qPsxBHlaPBQTFfH/I7Dx/sdG1e4VjWVingugKRksjqzZi8C39PQB 9rbRk9+miOPj/I48Jogw0XPx+CA3e6iKjG7OnSLCUAD/UwzphvQoBilHSsrf5uv/7Ty1 hchfh2DiCZswPe8vAc0yG7Jh6B882EyZmPDS0oKhsB9yQfe6gYudVV6ayu2UaerTSGKP Zv+9xo6zV47fmK1OTsURTVqeRRjvEK0RKdwF10HS95zGcNkaOmBxq0DeQQZepkpvxtXT ZPmwHhpyUvsWOUEG3R/CBX7c5KOvJY4gVdG/aKvyKyKnJFAaduXeflH7xcV4R/jw20ig xCgw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=5ebXy5GPqux5fMHU7cuSKJ1s77z14M6gC1nB/S0E6pA=; fh=1tSud9VoLT0v/ChNP3lwxus1msGB94U+kParf/F3Rds=; b=DtpehGWUbEswypIGCW4NfTY1qh6rFXlm1v8wKTfKznSpb62tVF+EpUxf11XfUkoEoW kaVA2Zq5smQP/63mjDKAY018XTMFkpgqSUM3zoocnky7GyPMCe2BFL44vGpnMx/HiFOe q4K8JWovmmW7PsF9I3sOAD3Nfik6aIaVeP1HNOnHmOKFTfBKSE7PR5s1cyOiyK5RBybp O+ilWltZdrzuKSigXXMluyPbrHA79ziYY2wd1vyxOPZhHdu8TmsESrcCOECVLcT6xg/Y VVLCbQv7/shL3+6LkQEyRDUuppcx1c4eHF2Mr95SCWajETGhUUoH0c4Bm6Id+e40jf3A 7yrA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=gkm45FAU; arc=pass (i=1 spf=pass spfdomain=ti.com dkim=pass dkdomain=ti.com dmarc=pass fromdomain=ti.com); spf=pass (google.com: domain of linux-kernel+bounces-28829-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-28829-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id v12-20020a63150c000000b005c68d9545c7si13225119pgl.334.2024.01.17.02.26.45 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Jan 2024 02:26:45 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-28829-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=gkm45FAU; arc=pass (i=1 spf=pass spfdomain=ti.com dkim=pass dkdomain=ti.com dmarc=pass fromdomain=ti.com); spf=pass (google.com: domain of linux-kernel+bounces-28829-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-28829-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id D9951285B9D for <ouuuleilei@gmail.com>; Wed, 17 Jan 2024 10:26:27 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id DEA801D532; Wed, 17 Jan 2024 10:25:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b="gkm45FAU" Received: from lelv0142.ext.ti.com (lelv0142.ext.ti.com [198.47.23.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ABA131426B; Wed, 17 Jan 2024 10:25:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.47.23.249 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705487157; cv=none; b=eN22C6qVoeFgdXRLPW79SPWGfxoysRKw4AJv4+y+uieqEYfe9Gw5/DZSbRqyA24Ls36qnveuLQZDQotZmwxDON/glYOEjVtAw7mZfd5uA5AGS5zFqOBH6NRnFgKiFZMDCIAdH6SvxNQiq2c9vI/65Ug9eTXhkaGWXedCAccazmE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705487157; c=relaxed/simple; bh=zEq/Rqwzz58yugJ7O6HFCLNcp/L546wF05MutcUd85w=; h=Received:DKIM-Signature:Received:Received:Received:Received:From: To:CC:Subject:Date:Message-ID:X-Mailer:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type: X-EXCLAIMER-MD-CONFIG; b=qQxNJF7kdNLlhPWe96DsCKlZ7ncy4ix9mHOpAuB1YG2Wkmvp76a0Q9q9qjpG4os58uhiINQ/J8lTKAyP2+bJvNkHt13LTJ03IM0ZEML8wP1N6CfXq9oj0DVZSAFPkTdqkyN7TjFhOlvmUZTfRg5jd9j5ORlkMVkwG28AzrhBIQU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ti.com; spf=pass smtp.mailfrom=ti.com; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b=gkm45FAU; arc=none smtp.client-ip=198.47.23.249 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ti.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ti.com Received: from fllv0034.itg.ti.com ([10.64.40.246]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id 40HAPePa114425; Wed, 17 Jan 2024 04:25:40 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1705487140; bh=5ebXy5GPqux5fMHU7cuSKJ1s77z14M6gC1nB/S0E6pA=; h=From:To:CC:Subject:Date:In-Reply-To:References; b=gkm45FAU84k14nOb8OKdn8czXYJz7CWNcFkP0hsUe1oGo9EIfeyLWttDl5hXOjpZh vROkeg940FPWf7C/MvhxAdrh/S49MRQZ+QnKTbz4U6GSJX5Dj32GiBsYDfrJInuGKC Js4c89rPn5Y418HgR2ffL/WU/F4CpciwXXxvu3n8= Received: from DFLE115.ent.ti.com (dfle115.ent.ti.com [10.64.6.36]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 40HAPexv035508 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 17 Jan 2024 04:25:40 -0600 Received: from DFLE114.ent.ti.com (10.64.6.35) by DFLE115.ent.ti.com (10.64.6.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Wed, 17 Jan 2024 04:25:40 -0600 Received: from lelvsmtp5.itg.ti.com (10.180.75.250) by DFLE114.ent.ti.com (10.64.6.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Wed, 17 Jan 2024 04:25:40 -0600 Received: from uda0492258.dhcp.ti.com (uda0492258.dhcp.ti.com [172.24.227.9]) by lelvsmtp5.itg.ti.com (8.15.2/8.15.2) with ESMTP id 40HAPQIh042834; Wed, 17 Jan 2024 04:25:36 -0600 From: Siddharth Vadapalli <s-vadapalli@ti.com> To: <bhelgaas@google.com>, <lpieralisi@kernel.org>, <kw@linux.com>, <robh@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org> CC: <linux-pci@vger.kernel.org>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <vigneshr@ti.com>, <afd@ti.com>, <srk@ti.com>, <s-vadapalli@ti.com> Subject: [PATCH 2/3] dt-bindings: PCI: ti,j721e-pci-*: Add checks for max-link-speed Date: Wed, 17 Jan 2024 15:55:25 +0530 Message-ID: <20240117102526.557006-3-s-vadapalli@ti.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240117102526.557006-1-s-vadapalli@ti.com> References: <20240117102526.557006-1-s-vadapalli@ti.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1788332952020663831 X-GMAIL-MSGID: 1788332952020663831 |
Series |
Fix and update ti,j721e-pci-* bindings
|
|
Commit Message
Siddharth Vadapalli
Jan. 17, 2024, 10:25 a.m. UTC
Extend the existing compatible based checks for validating and enforcing
the "max-link-speed" property.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
---
.../devicetree/bindings/pci/ti,j721e-pci-ep.yaml | 8 ++++++++
.../devicetree/bindings/pci/ti,j721e-pci-host.yaml | 8 ++++++++
2 files changed, 16 insertions(+)
Comments
On 17/01/2024 11:25, Siddharth Vadapalli wrote: > Extend the existing compatible based checks for validating and enforcing > the "max-link-speed" property. Based on what? Driver or hardware? Your entire change suggests you should just drop it from the binding, because this can be deduced from compatible. Best regards, Krzysztof
On 17/01/24 16:05, Krzysztof Kozlowski wrote: > On 17/01/2024 11:25, Siddharth Vadapalli wrote: >> Extend the existing compatible based checks for validating and enforcing >> the "max-link-speed" property. > > Based on what? Driver or hardware? Your entire change suggests you Hardware. The PCIe controller on AM64 SoC supports up to Gen2 link speed while the PCIe controllers on other SoCs support Gen3 link speed. > should just drop it from the binding, because this can be deduced from > compatible. Could you please clarify? Isn't the addition of the checks for "max-link-speed" identical to the checks which were added for "num-lanes", both of which are Hardware specific?
On 17/01/2024 11:58, Siddharth Vadapalli wrote: > On 17/01/24 16:05, Krzysztof Kozlowski wrote: >> On 17/01/2024 11:25, Siddharth Vadapalli wrote: >>> Extend the existing compatible based checks for validating and enforcing >>> the "max-link-speed" property. >> >> Based on what? Driver or hardware? Your entire change suggests you > > Hardware. The PCIe controller on AM64 SoC supports up to Gen2 link speed while > the PCIe controllers on other SoCs support Gen3 link speed. > >> should just drop it from the binding, because this can be deduced from >> compatible. > > Could you please clarify? Isn't the addition of the checks for "max-link-speed" > identical to the checks which were added for "num-lanes", both of which are > Hardware specific? Compatible defines these values, at least what it looks like from the patch. Best regards, Krzysztof
On 17/01/24 16:30, Krzysztof Kozlowski wrote: > On 17/01/2024 11:58, Siddharth Vadapalli wrote: >> On 17/01/24 16:05, Krzysztof Kozlowski wrote: >>> On 17/01/2024 11:25, Siddharth Vadapalli wrote: >>>> Extend the existing compatible based checks for validating and enforcing >>>> the "max-link-speed" property. >>> >>> Based on what? Driver or hardware? Your entire change suggests you >> >> Hardware. The PCIe controller on AM64 SoC supports up to Gen2 link speed while >> the PCIe controllers on other SoCs support Gen3 link speed. >> >>> should just drop it from the binding, because this can be deduced from >>> compatible. >> >> Could you please clarify? Isn't the addition of the checks for "max-link-speed" >> identical to the checks which were added for "num-lanes", both of which are >> Hardware specific? > > Compatible defines these values, at least what it looks like from the patch. In this patch, I have added checks for the "max-link-speed" property in the same section that "num-lanes" is being evaluated. The values for "max-link-speed" are based on the Hardware support and this patch is validating the "max-link-speed" property in the device-tree nodes for the devices against the Hardware supported values which this patch is adding in the corresponding section. Kindly let me know if I misunderstood what you meant to convey.
On 17/01/2024 12:15, Siddharth Vadapalli wrote: > > > On 17/01/24 16:30, Krzysztof Kozlowski wrote: >> On 17/01/2024 11:58, Siddharth Vadapalli wrote: >>> On 17/01/24 16:05, Krzysztof Kozlowski wrote: >>>> On 17/01/2024 11:25, Siddharth Vadapalli wrote: >>>>> Extend the existing compatible based checks for validating and enforcing >>>>> the "max-link-speed" property. >>>> >>>> Based on what? Driver or hardware? Your entire change suggests you >>> >>> Hardware. The PCIe controller on AM64 SoC supports up to Gen2 link speed while >>> the PCIe controllers on other SoCs support Gen3 link speed. >>> >>>> should just drop it from the binding, because this can be deduced from >>>> compatible. >>> >>> Could you please clarify? Isn't the addition of the checks for "max-link-speed" >>> identical to the checks which were added for "num-lanes", both of which are >>> Hardware specific? >> >> Compatible defines these values, at least what it looks like from the patch. > > In this patch, I have added checks for the "max-link-speed" property in the same > section that "num-lanes" is being evaluated. I know what you did in patch. I read it. > The values for "max-link-speed" are > based on the Hardware support and this patch is validating the "max-link-speed" > property in the device-tree nodes for the devices against the Hardware supported > values which this patch is adding in the corresponding section. Kindly let me > know if I misunderstood what you meant to convey. Nothing of this is relevant. I used two entirely different wordings for this and you still don't get it, so I don't know if I have third one. Maybe this: Move it to driver match data. So three entirely different wordings for the same. I don't have fourth... Best regards, Krzysztof
On 17/01/24 16:49, Krzysztof Kozlowski wrote: > On 17/01/2024 12:15, Siddharth Vadapalli wrote: >> >> >> On 17/01/24 16:30, Krzysztof Kozlowski wrote: >>> On 17/01/2024 11:58, Siddharth Vadapalli wrote: >>>> On 17/01/24 16:05, Krzysztof Kozlowski wrote: >>>>> On 17/01/2024 11:25, Siddharth Vadapalli wrote: >>>>>> Extend the existing compatible based checks for validating and enforcing >>>>>> the "max-link-speed" property. >>>>> >>>>> Based on what? Driver or hardware? Your entire change suggests you >>>> >>>> Hardware. The PCIe controller on AM64 SoC supports up to Gen2 link speed while >>>> the PCIe controllers on other SoCs support Gen3 link speed. >>>> >>>>> should just drop it from the binding, because this can be deduced from >>>>> compatible. >>>> >>>> Could you please clarify? Isn't the addition of the checks for "max-link-speed" >>>> identical to the checks which were added for "num-lanes", both of which are >>>> Hardware specific? >>> >>> Compatible defines these values, at least what it looks like from the patch. >> >> In this patch, I have added checks for the "max-link-speed" property in the same >> section that "num-lanes" is being evaluated. > > I know what you did in patch. I read it. > >> The values for "max-link-speed" are >> based on the Hardware support and this patch is validating the "max-link-speed" >> property in the device-tree nodes for the devices against the Hardware supported >> values which this patch is adding in the corresponding section. Kindly let me >> know if I misunderstood what you meant to convey. > > Nothing of this is relevant. > > I used two entirely different wordings for this and you still don't get > it, so I don't know if I have third one. > > Maybe this: > Move it to driver match data. Ok. I will drop the checks for "max-link-speed" and move them to the driver. But I wonder why the checks for "num-lanes" are needed in the first place when they could be in the driver as well. > > So three entirely different wordings for the same. I don't have fourth... > > Best regards, > Krzysztof >
On 17/01/2024 12:22, Siddharth Vadapalli wrote: > > > On 17/01/24 16:49, Krzysztof Kozlowski wrote: >> On 17/01/2024 12:15, Siddharth Vadapalli wrote: >>> >>> >>> On 17/01/24 16:30, Krzysztof Kozlowski wrote: >>>> On 17/01/2024 11:58, Siddharth Vadapalli wrote: >>>>> On 17/01/24 16:05, Krzysztof Kozlowski wrote: >>>>>> On 17/01/2024 11:25, Siddharth Vadapalli wrote: >>>>>>> Extend the existing compatible based checks for validating and enforcing >>>>>>> the "max-link-speed" property. >>>>>> >>>>>> Based on what? Driver or hardware? Your entire change suggests you >>>>> >>>>> Hardware. The PCIe controller on AM64 SoC supports up to Gen2 link speed while >>>>> the PCIe controllers on other SoCs support Gen3 link speed. >>>>> >>>>>> should just drop it from the binding, because this can be deduced from >>>>>> compatible. >>>>> >>>>> Could you please clarify? Isn't the addition of the checks for "max-link-speed" >>>>> identical to the checks which were added for "num-lanes", both of which are >>>>> Hardware specific? >>>> >>>> Compatible defines these values, at least what it looks like from the patch. >>> >>> In this patch, I have added checks for the "max-link-speed" property in the same >>> section that "num-lanes" is being evaluated. >> >> I know what you did in patch. I read it. >> >>> The values for "max-link-speed" are >>> based on the Hardware support and this patch is validating the "max-link-speed" >>> property in the device-tree nodes for the devices against the Hardware supported >>> values which this patch is adding in the corresponding section. Kindly let me >>> know if I misunderstood what you meant to convey. >> >> Nothing of this is relevant. >> >> I used two entirely different wordings for this and you still don't get >> it, so I don't know if I have third one. >> >> Maybe this: >> Move it to driver match data. > > Ok. I will drop the checks for "max-link-speed" and move them to the driver. But > I wonder why the checks for "num-lanes" are needed in the first place when they > could be in the driver as well. Yes, that's why I commented in your next patch. Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml b/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml index 278e0892f8ac..4839a9574e20 100644 --- a/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml +++ b/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml @@ -73,6 +73,8 @@ allOf: - const: ti,j721e-pcie-ep then: properties: + max-link-speed: + const: 2 num-lanes: const: 1 @@ -84,6 +86,8 @@ allOf: - const: ti,j721e-pcie-ep then: properties: + max-link-speed: + const: 3 num-lanes: minimum: 1 maximum: 2 @@ -95,6 +99,8 @@ allOf: - const: ti,j721e-pcie-ep then: properties: + max-link-speed: + const: 3 num-lanes: minimum: 1 maximum: 4 @@ -106,6 +112,8 @@ allOf: - const: ti,j784s4-pcie-ep then: properties: + max-link-speed: + const: 3 num-lanes: minimum: 1 maximum: 4 diff --git a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml index 36bcc8cb7896..005546dc8bd4 100644 --- a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml +++ b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml @@ -102,6 +102,8 @@ allOf: - const: ti,j721e-pcie-host then: properties: + max-link-speed: + const: 2 num-lanes: const: 1 @@ -113,6 +115,8 @@ allOf: - const: ti,j721e-pcie-host then: properties: + max-link-speed: + const: 3 num-lanes: minimum: 1 maximum: 2 @@ -124,6 +128,8 @@ allOf: - const: ti,j721e-pcie-host then: properties: + max-link-speed: + const: 3 num-lanes: minimum: 1 maximum: 4 @@ -135,6 +141,8 @@ allOf: - const: ti,j784s4-pcie-host then: properties: + max-link-speed: + const: 3 num-lanes: minimum: 1 maximum: 4