Message ID | 20240108050735.512445-1-s-vadapalli@ti.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-19086-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:37c1:b0:101:2151:f287 with SMTP id y1csp836204dyq; Sun, 7 Jan 2024 21:08:21 -0800 (PST) X-Google-Smtp-Source: AGHT+IHqvvBuA9rvO1O0riiilSBbKB11zgIPghzuSUJ37F4o8xdWJzc2rCBZcuuBuiJF8VZjJiAK X-Received: by 2002:a05:6a20:8f06:b0:199:b0c8:700a with SMTP id b6-20020a056a208f0600b00199b0c8700amr1543154pzk.25.1704690501109; Sun, 07 Jan 2024 21:08:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704690501; cv=none; d=google.com; s=arc-20160816; b=X3tzXtO5p9raC/VXqKhwsk0xREbZPJQ5ReKK/4Xw9HeFybKROegJ3+oSge/N0cys5Y kZar8hrVQkZmQnroncN5hiqoxuyavDMs+6TXAxIsA4xaD/Swhd3RMaV72APlfLVDRu1Z Ps+ZUE58spwEeyGnWguaJHlzED0qkPF3McSJSdfEZDy1a+lJjgNvSUYBv5FeuToWqbut kXeeA3IhDYG40C2lfcsef+cbEfs/SK9sEnCzoJSxbcSuJUKROFS9BykaQJW+z+VBLb3m js5GjEZV1G/M/pxKT4nMZXNWDzECZg0JOD0PBTOgWjxlkbWDUDsQJLln7To9NmbsVUw3 ulNQ== ARC-Message-Signature: i=1; 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:message-id:date:subject:cc:to :from:dkim-signature; bh=SEOZBEh1rdSE2ER95qLbRtCJXFatCDoGS/5h4fdRzDY=; fh=0XOLlzDkowPUbBxAhqSCnq6sfhoZ87oQOt5Mo1vTv1w=; b=QYD5YGXVsCB1qCGWZ/tXIo3ts9+Y9X8yfkN0/4mvDawlgD1hWQTVR5owpSdT3sK0tO tQZPXB+DzXcYh40s8XfbbfRqAe+FfsxHeCx5ViihDzQfkHp1gqvWCTpU/Rh6KczyEkq3 Y0/bRhr6ml5BKjRzbIT/XNnJe74kCFQLcaFAfT9Ok4/g+fiVytLUsX+QfrMWn54H60u8 FpZSimpegmAO13r4gmUYAP8Kpgt6U6m30rf0Fn1uH8fGGEbZWfm6Dykn9X4RSapZrHDP sXTq87Bw3fj3ovEY6Nn0/dvOwiMJG38xlhalSqBmstue+0s1slD89cxH8jpSziQXt+8p Noug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=tnM+RfbL; spf=pass (google.com: domain of linux-kernel+bounces-19086-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-19086-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id 19-20020a630c53000000b005c65ed0f680si5571993pgm.463.2024.01.07.21.08.20 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Jan 2024 21:08:21 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-19086-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=tnM+RfbL; spf=pass (google.com: domain of linux-kernel+bounces-19086-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-19086-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 sy.mirrors.kernel.org (Postfix) with ESMTPS id 2B2DCB20BE2 for <ouuuleilei@gmail.com>; Mon, 8 Jan 2024 05:08:20 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C4E5579DF; Mon, 8 Jan 2024 05:08:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b="tnM+RfbL" X-Original-To: linux-kernel@vger.kernel.org Received: from lelv0143.ext.ti.com (lelv0143.ext.ti.com [198.47.23.248]) (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 4772079C2; Mon, 8 Jan 2024 05:08:00 +0000 (UTC) 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 lelv0266.itg.ti.com ([10.180.67.225]) by lelv0143.ext.ti.com (8.15.2/8.15.2) with ESMTP id 40857eMO041857; Sun, 7 Jan 2024 23:07:40 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1704690460; bh=SEOZBEh1rdSE2ER95qLbRtCJXFatCDoGS/5h4fdRzDY=; h=From:To:CC:Subject:Date; b=tnM+RfbLMxQxkHCUo99jQJIm2kpYQU1TvbZE1ZOosVH/XarQcicjU7jwoNSiH97Bx l5/e3i+eIHdtgHr5jEIgQcdD9TZA6X6MdCtJzYLUTxwJBahR1VCqUkdT/pkEslaFfQ oHlqIihCLRdawWNTOYBf+ikyohiefhQde2C02dsU= Received: from DLEE105.ent.ti.com (dlee105.ent.ti.com [157.170.170.35]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 40857eOH103780 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 7 Jan 2024 23:07:40 -0600 Received: from DLEE105.ent.ti.com (157.170.170.35) by DLEE105.ent.ti.com (157.170.170.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Sun, 7 Jan 2024 23:07:39 -0600 Received: from lelvsmtp5.itg.ti.com (10.180.75.250) by DLEE105.ent.ti.com (157.170.170.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; Sun, 7 Jan 2024 23:07:39 -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 40857ZP1039261; Sun, 7 Jan 2024 23:07:36 -0600 From: Siddharth Vadapalli <s-vadapalli@ti.com> To: <lpieralisi@kernel.org>, <kw@linux.com>, <robh@kernel.org>, <bhelgaas@google.com>, <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>, <srk@ti.com>, <s-vadapalli@ti.com> Subject: [RFC PATCH] dt-bindings: PCI: ti,j721e-pci-host: Add device-id for TI's J784S4 SoC Date: Mon, 8 Jan 2024 10:37:35 +0530 Message-ID: <20240108050735.512445-1-s-vadapalli@ti.com> X-Mailer: git-send-email 2.34.1 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: 1787497546876973273 X-GMAIL-MSGID: 1787497546876973273 |
Series |
[RFC] dt-bindings: PCI: ti,j721e-pci-host: Add device-id for TI's J784S4 SoC
|
|
Commit Message
Siddharth Vadapalli
Jan. 8, 2024, 5:07 a.m. UTC
Add the device-id of 0xb012 for the PCIe controller on the J784S4 SoC as
described in the CTRL_MMR_PCI_DEVICE_ID register's PCI_DEVICE_ID_DEVICE_ID
field. The Register descriptions and the Technical Reference Manual for
J784S4 SoC can be found at: https://www.ti.com/lit/zip/spruj52
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
---
This patch is based on linux-next tagged next-20240105.
Regards,
Siddharth.
Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml | 1 +
1 file changed, 1 insertion(+)
Comments
On 08/01/2024 06:07, Siddharth Vadapalli wrote: > Add the device-id of 0xb012 for the PCIe controller on the J784S4 SoC as > described in the CTRL_MMR_PCI_DEVICE_ID register's PCI_DEVICE_ID_DEVICE_ID > field. The Register descriptions and the Technical Reference Manual for > J784S4 SoC can be found at: https://www.ti.com/lit/zip/spruj52 > > Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> > --- > > This patch is based on linux-next tagged next-20240105. Why is this patch incomplete? What is missing here? What are you asking about as RFC? Best regards, Krzysztof
Hello Krzysztof, On 08/01/24 12:39, Krzysztof Kozlowski wrote: > On 08/01/2024 06:07, Siddharth Vadapalli wrote: >> Add the device-id of 0xb012 for the PCIe controller on the J784S4 SoC as >> described in the CTRL_MMR_PCI_DEVICE_ID register's PCI_DEVICE_ID_DEVICE_ID >> field. The Register descriptions and the Technical Reference Manual for >> J784S4 SoC can be found at: https://www.ti.com/lit/zip/spruj52 >> >> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> >> --- >> >> This patch is based on linux-next tagged next-20240105. > > Why is this patch incomplete? What is missing here? What are you asking > about as RFC? Since the merge window is closed, I was hoping to get the patch reviewed in order to get any "Reviewed-by" tags if possible. That way, I will be able to post it again as v1 along with the tags when the merge window opens. For that reason, I have marked it as an RFC patch. Is there an alternative to this "RFC patch" method that I have followed? Please let me know. > > Best regards, > Krzysztof >
On 08/01/2024 11:20, Siddharth Vadapalli wrote: > Hello Krzysztof, > > On 08/01/24 12:39, Krzysztof Kozlowski wrote: >> On 08/01/2024 06:07, Siddharth Vadapalli wrote: >>> Add the device-id of 0xb012 for the PCIe controller on the J784S4 SoC as >>> described in the CTRL_MMR_PCI_DEVICE_ID register's PCI_DEVICE_ID_DEVICE_ID >>> field. The Register descriptions and the Technical Reference Manual for >>> J784S4 SoC can be found at: https://www.ti.com/lit/zip/spruj52 >>> >>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> >>> --- >>> >>> This patch is based on linux-next tagged next-20240105. >> >> Why is this patch incomplete? What is missing here? What are you asking >> about as RFC? > > Since the merge window is closed, I was hoping to get the patch reviewed in > order to get any "Reviewed-by" tags if possible. That way, I will be able to > post it again as v1 along with the tags when the merge window opens. For that This is v1, so that would be v2. > reason, I have marked it as an RFC patch. Is there an alternative to this "RFC > patch" method that I have followed? Please let me know. Then how does it differ from posting without RFC? Sorry, RFC is incomplete work. Often ignored during review. Best regards, Krzysztof
On 08/01/24 16:51, Krzysztof Kozlowski wrote: > On 08/01/2024 11:20, Siddharth Vadapalli wrote: >> Hello Krzysztof, >> >> On 08/01/24 12:39, Krzysztof Kozlowski wrote: >>> On 08/01/2024 06:07, Siddharth Vadapalli wrote: >>>> Add the device-id of 0xb012 for the PCIe controller on the J784S4 SoC as >>>> described in the CTRL_MMR_PCI_DEVICE_ID register's PCI_DEVICE_ID_DEVICE_ID >>>> field. The Register descriptions and the Technical Reference Manual for >>>> J784S4 SoC can be found at: https://www.ti.com/lit/zip/spruj52 >>>> >>>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> >>>> --- >>>> >>>> This patch is based on linux-next tagged next-20240105. >>> >>> Why is this patch incomplete? What is missing here? What are you asking >>> about as RFC? >> >> Since the merge window is closed, I was hoping to get the patch reviewed in >> order to get any "Reviewed-by" tags if possible. That way, I will be able to >> post it again as v1 along with the tags when the merge window opens. For that > > This is v1, so that would be v2. > >> reason, I have marked it as an RFC patch. Is there an alternative to this "RFC >> patch" method that I have followed? Please let me know. > > Then how does it differ from posting without RFC? Sorry, RFC is > incomplete work. Often ignored during review. I was under the impression that posting patches when the merge window is closed will be met with a "post your patch later when the merge window is open" response. That is why I chose the "RFC patch" path since RFCs can be posted anytime. For the Networking Subsystem, it is documented that patches with new features shouldn't be posted when the merge window is closed. I have mostly posted patches for the Networking Subsystem and am not sure about the rules for the device-tree bindings and PCI Subsystems. To be on the safe side I posted this patch as an RFC patch. Thank you for clarifying that it is alright to post patches even when merge window is closed. Going forward I shall not post RFC patches unless it really requires feedback and suggestions.
On 08/01/2024 12:34, Siddharth Vadapalli wrote: >>>> >>>> Why is this patch incomplete? What is missing here? What are you asking >>>> about as RFC? >>> >>> Since the merge window is closed, I was hoping to get the patch reviewed in >>> order to get any "Reviewed-by" tags if possible. That way, I will be able to >>> post it again as v1 along with the tags when the merge window opens. For that >> >> This is v1, so that would be v2. >> >>> reason, I have marked it as an RFC patch. Is there an alternative to this "RFC >>> patch" method that I have followed? Please let me know. >> >> Then how does it differ from posting without RFC? Sorry, RFC is >> incomplete work. Often ignored during review. > > I was under the impression that posting patches when the merge window is closed > will be met with a "post your patch later when the merge window is open" > response. That is why I chose the "RFC patch" path since RFCs can be posted anytime. > > For the Networking Subsystem, it is documented that patches with new features > shouldn't be posted when the merge window is closed. I have mostly posted > patches for the Networking Subsystem and am not sure about the rules for the > device-tree bindings and PCI Subsystems. To be on the safe side I posted this > patch as an RFC patch. Ah, so you want to go around that policy by posting non-RFC patch as RFC. It does not work like that. Best regards, Krzysztof
On 08/01/24 17:56, Krzysztof Kozlowski wrote: > On 08/01/2024 12:34, Siddharth Vadapalli wrote: >>>>> >>>>> Why is this patch incomplete? What is missing here? What are you asking >>>>> about as RFC? >>>> >>>> Since the merge window is closed, I was hoping to get the patch reviewed in >>>> order to get any "Reviewed-by" tags if possible. That way, I will be able to >>>> post it again as v1 along with the tags when the merge window opens. For that >>> >>> This is v1, so that would be v2. >>> >>>> reason, I have marked it as an RFC patch. Is there an alternative to this "RFC >>>> patch" method that I have followed? Please let me know. >>> >>> Then how does it differ from posting without RFC? Sorry, RFC is >>> incomplete work. Often ignored during review. >> >> I was under the impression that posting patches when the merge window is closed >> will be met with a "post your patch later when the merge window is open" >> response. That is why I chose the "RFC patch" path since RFCs can be posted anytime. >> >> For the Networking Subsystem, it is documented that patches with new features >> shouldn't be posted when the merge window is closed. I have mostly posted >> patches for the Networking Subsystem and am not sure about the rules for the >> device-tree bindings and PCI Subsystems. To be on the safe side I posted this >> patch as an RFC patch. > > Ah, so you want to go around that policy by posting non-RFC patch as > RFC. It does not work like that. Thank you for clarifying. May I post the v2 of this patch in that case, after rebasing it on the latest linux-next? I wish to receive feedback or Reviewed-by tags for the v2 patch and post the v3 accordingly when the merge window opens again.
On Mon, 08 Jan 2024 10:37:35 +0530, Siddharth Vadapalli wrote: > Add the device-id of 0xb012 for the PCIe controller on the J784S4 SoC as > described in the CTRL_MMR_PCI_DEVICE_ID register's PCI_DEVICE_ID_DEVICE_ID > field. The Register descriptions and the Technical Reference Manual for > J784S4 SoC can be found at: https://www.ti.com/lit/zip/spruj52 > > Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> > --- > > This patch is based on linux-next tagged next-20240105. > > Regards, > Siddharth. > > Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring <robh@kernel.org>
diff --git a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml index b7a534cef24d..0b1f21570ed0 100644 --- a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml +++ b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml @@ -68,6 +68,7 @@ properties: - 0xb00d - 0xb00f - 0xb010 + - 0xb012 - 0xb013 msi-map: true