Message ID | 20231130115044.53512-1-shradha.t@samsung.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp399503vqy; Thu, 30 Nov 2023 05:52:07 -0800 (PST) X-Google-Smtp-Source: AGHT+IHmoJzzeSVxu2XBs5JPs/fsbh6/9XMy+IRLEjLHbrW6NwLHyBxwzxNiD0mdOrYC9jSyeOWZ X-Received: by 2002:a05:6a20:1594:b0:18c:110e:c34e with SMTP id h20-20020a056a20159400b0018c110ec34emr20227397pzj.34.1701352327435; Thu, 30 Nov 2023 05:52:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701352327; cv=none; d=google.com; s=arc-20160816; b=uJNz+vY/pi51FwVgX7FCLWgbFCrLCFos5BVToucmgD5gkPCmr6EeURZyTAfRPWLz4s acdJf0EAbzjvLEYlJeYx3Gu4WM1ARzMLHfL6zX6QImcroxJbgE1G5MN4cnixqVHJNQiw KILOSdN2ll+Wj7Ry4rsrcE+QdHDQTA9zOgR+VVdO2UK8sW3YCWPMl3k/eedqm1/Pef97 b5vrARKThfUmUev50qNI9Dd4RJtzg4pzKvwrzehZifBrdqxDWvfq+JT3753eeVp7faFt y5TutuedECG0/0DFtCQWHaybZ7aAs4+bR38s7ouQXgXf91pzJlCbi0oQzq9stkHSO9Nu e1Gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:dlp-filter:cms-type:message-id:date :subject:cc:to:from:dkim-signature:dkim-filter; bh=AXEPALESso3IHEGnjNE8OOJAITFOwUrOekyzSLBnaRU=; fh=lfAA1d+oAQdqJfpKYHiciCj4TZsJOfTYjH3wzsU3Yt8=; b=XYUDyefP4pQz/cuqz9XOUgNodkh24S9kQQvmYIXCc+7eS4NyAPxSMCTjsqgP7W/YXz biuVLMsSgRO8P3Q7wVfuR/mFErIGqDd97nf5YkoSpIph9V8Pm6Z+bMmSmV+aAR88xcHo W4078+rmIWF4k2N2nes2/ptw5NuS8jBlHFSAkp0GAnyXhkZX7DOW+SyIRuwe0wVMjuuL cj6PtQjVtzzW1zL5L62/CFxhg2w5Kjm9+Mwd98Y9b5JiMNWW2fGVYHizVitcwXig5KUZ 7K5GwTUGjQ5D4jVIW0S9Jx6J2cqXktff85MySG1SPaPXlIBipNy2p1fxMFy8ntg7bCdF Xk1w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@samsung.com header.s=mail20170921 header.b="ioZJ/VfI"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=samsung.com Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id 37-20020a631965000000b005be029a66d1si1324597pgz.806.2023.11.30.05.51.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Nov 2023 05:52:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@samsung.com header.s=mail20170921 header.b="ioZJ/VfI"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=samsung.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id CBC74807D9BE; Thu, 30 Nov 2023 05:51:16 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345732AbjK3NvF (ORCPT <rfc822;ruipengqi7@gmail.com> + 99 others); Thu, 30 Nov 2023 08:51:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41780 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345581AbjK3NvE (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 30 Nov 2023 08:51:04 -0500 Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 374F8131 for <linux-kernel@vger.kernel.org>; Thu, 30 Nov 2023 05:51:07 -0800 (PST) Received: from epcas5p1.samsung.com (unknown [182.195.41.39]) by mailout2.samsung.com (KnoxPortal) with ESMTP id 20231130135103epoutp02888478e6a7e5fd9840f463e171b98497~cat6igOrS1306813068epoutp02w for <linux-kernel@vger.kernel.org>; Thu, 30 Nov 2023 13:51:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.samsung.com 20231130135103epoutp02888478e6a7e5fd9840f463e171b98497~cat6igOrS1306813068epoutp02w DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1701352263; bh=AXEPALESso3IHEGnjNE8OOJAITFOwUrOekyzSLBnaRU=; h=From:To:Cc:Subject:Date:References:From; b=ioZJ/VfI4RzjktxFoBirM9FR0O23p3Z6nsNjWeoxbkLb61c7VwiRASRf/p+2+PD0M ZDaCGkSqvT5Rxj3yZIYeCz04LbtmRxDVNwMjeOUWqJSXGt3fjs75GsvJ3N8JKoI23r mZNVu6MRwp+lCKf2aUUKCqLX+Fy3PquGOGU3TUAc= Received: from epsnrtp4.localdomain (unknown [182.195.42.165]) by epcas5p3.samsung.com (KnoxPortal) with ESMTP id 20231130135102epcas5p3dc90e298d61549c962fd73a108e01383~cat5y5sGU0205102051epcas5p33; Thu, 30 Nov 2023 13:51:02 +0000 (GMT) Received: from epsmges5p1new.samsung.com (unknown [182.195.38.179]) by epsnrtp4.localdomain (Postfix) with ESMTP id 4SgyJj5v3qz4x9Pv; Thu, 30 Nov 2023 13:51:01 +0000 (GMT) Received: from epcas5p3.samsung.com ( [182.195.41.41]) by epsmges5p1new.samsung.com (Symantec Messaging Gateway) with SMTP id 2A.E7.09634.54398656; Thu, 30 Nov 2023 22:51:01 +0900 (KST) Received: from epsmtrp1.samsung.com (unknown [182.195.40.13]) by epcas5p4.samsung.com (KnoxPortal) with ESMTPA id 20231130115055epcas5p4e29befa80877be45dbee308846edc0ba~cZFBa0JFd0967209672epcas5p4Y; Thu, 30 Nov 2023 11:50:55 +0000 (GMT) Received: from epsmgms1p2new.samsung.com (unknown [182.195.42.42]) by epsmtrp1.samsung.com (KnoxPortal) with ESMTP id 20231130115055epsmtrp13238ef79585fb52257838b0a311c40f2~cZFBaDxs41720317203epsmtrp1q; Thu, 30 Nov 2023 11:50:55 +0000 (GMT) X-AuditID: b6c32a49-159fd700000025a2-fc-65689345da6c Received: from epsmtip1.samsung.com ( [182.195.34.30]) by epsmgms1p2new.samsung.com (Symantec Messaging Gateway) with SMTP id 2A.BE.08817.F1778656; Thu, 30 Nov 2023 20:50:55 +0900 (KST) Received: from cheetah.sa.corp.samsungelectronics.net (unknown [107.109.115.53]) by epsmtip1.samsung.com (KnoxPortal) with ESMTPA id 20231130115053epsmtip1ddf7dc43938900250ee67d35bc227628~cZE-UPiZ81499114991epsmtip1R; Thu, 30 Nov 2023 11:50:53 +0000 (GMT) From: Shradha Todi <shradha.t@samsung.com> To: manivannan.sadhasivam@linaro.org, lpieralisi@kernel.org, kw@linux.com, robh@kernel.org, bhelgaas@google.com, jingoohan1@gmail.com, gustavo.pimentel@synopsys.com, josh@joshtriplett.org, lukas.bulwahn@gmail.com, hongxing.zhu@nxp.com, pankaj.dubey@samsung.com Cc: linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, Shradha Todi <shradha.t@samsung.com> Subject: [PATCH v2 0/3] Add support for RAS DES feature in PCIe DW controller Date: Thu, 30 Nov 2023 17:20:41 +0530 Message-Id: <20231130115044.53512-1-shradha.t@samsung.com> X-Mailer: git-send-email 2.17.1 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupik+LIzCtJLcpLzFFi42LZdlhTU9d1ckaqwb5V2hZLmjIsdt3tYLeY tW0uo8WKLzPZLf4vyLdo6PnNanF51xw2i7PzjrNZtPxpYbFoOdrOYnG3pZPVYtHWL0Ble3aw W/QernXg89g56y67x4JNpR63Xtt6bFrVyeZx59oeNo8nV6YzeWx8t4PJo2/LKkaPLfs/M3p8 3iQXwBWVbZORmpiSWqSQmpecn5KZl26r5B0c7xxvamZgqGtoaWGupJCXmJtqq+TiE6DrlpkD dL2SQlliTilQKCCxuFhJ386mKL+0JFUhI7+4xFYptSAlp8CkQK84Mbe4NC9dLy+1xMrQwMDI FKgwITvj2Z9TTAWLBSv2v1zF0sDYz9fFyMkhIWAiMXf7bdYuRi4OIYHdjBKv7nUxgSSEBD4x Snz8Ug2R+MYo8eJXAxtMx6p7nYwQib2MEg8737JBOK1MEttftbOAVLEJaEk0fu1iBkmICHQx STxacZIdJMEskCwxr/8O2A5hAX+Ja03PwMayCKhKTOvvYwWxeQWsJJ6+mcEEsU5eYvWGA8wQ 9l92iYsPeCFsF4mJHfdYIWxhiVfHt7BD2FISL/vboOx0iZWbZ0D15kh827wEaqa9xIErc4AO 5QC6R1Ni/S59iLCsxNRT65ggzuST6P39BKqcV2LHPBhbWeLL3z0sELakxLxjl6FO8JBYue4T CyToYiVeHl3FOIFRdhbChgWMjKsYJVMLinPTU4tNCwzzUsvhEZWcn7uJEZwotTx3MN598EHv ECMTB+MhRgkOZiUR3utP01OFeFMSK6tSi/Lji0pzUosPMZoCg2wis5Rocj4wVeeVxBuaWBqY mJmZmVgamxkqifO+bp2bIiSQnliSmp2aWpBaBNPHxMEp1cDk1Hb5fVsP+7Un9Z1iPwP/z6y+ asBx/uW1ZW6i10R0/3xtVf/eaNXTu9v1oNaigDy/EN3Ed4WiTuePV1r/WdhZ8NVsjcpayfkH U1XeRa7y1z/I9IH3f/Orx2unnU7Qu/vlMaP5tMyzS6/cWHAl+nqsknIOR3nA7xju+9OM4/gZ Nt5PV/yvqjPXv7WpUjjo3pfu7cbc5lsuPev302vtjbXKlhVex5rKK9j6sdjuyArbXUuft0wW aT3lp/nq/M7ggJgCS/336syrmC8dmjVzY/GcC7XnWOrkrFIS3x0Qk8+0y5tR2XwtPmHq9duP qhTdQhvfZcw7VMR0ctfH0px/S9XsH/K3OEoGJa2uOl7+d7kSS3FGoqEWc1FxIgD0xun0HQQA AA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsWy7bCSnK58eUaqwfGpkhZLmjIsdt3tYLeY tW0uo8WKLzPZLf4vyLdo6PnNanF51xw2i7PzjrNZtPxpYbFoOdrOYnG3pZPVYtHWL0Ble3aw W/QernXg89g56y67x4JNpR63Xtt6bFrVyeZx59oeNo8nV6YzeWx8t4PJo2/LKkaPLfs/M3p8 3iQXwBXFZZOSmpNZllqkb5fAlfHszymmgsWCFftfrmJpYOzn62Lk5JAQMJFYda+TsYuRi0NI YDejxPnPK1khEpISny+uY4KwhSVW/nvODlHUzCTx7MYeNpAEm4CWROPXLmaQhIjADCaJlu77 LCAJZoFUiduH54AVCQv4SjxdcQ7MZhFQlZjW3we2gVfASuLpmxlQG+QlVm84wDyBkWcBI8Mq RsnUguLc9NxiwwKjvNRyveLE3OLSvHS95PzcTYzgsNXS2sG4Z9UHvUOMTByMhxglOJiVRHiv P01PFeJNSaysSi3Kjy8qzUktPsQozcGiJM777XVvipBAemJJanZqakFqEUyWiYNTqoHp9EqP +VcX/pdPVtiy7upsr/akUoMzU49qb66+Y8zgtXK55Ebb8rmL3Q2idzAtL7u97DmvUmLT14Ku 1w6Oz3xrf4jM1X7zsJmn96ydbMyeeYEfPt7q76vlXqa8hyWiRbbh5/nuhl+W5xV2bOw2UbV/ afg7a+ty+0/ek8JCJT7mz135OaM1PLdzR/3n2XU8qxfrvgxv9GkLnGTysXm+ponok4hHBfwN HJ27T4tzX1wssVm2eNnzSMHnvzzb/H2jlpXnhrTOFF1fl/pF7uEKpT9xNhcFWmN0K1ef2uiQ Et2yKKnSVsrm+/3SKZsmpy1T1I4u+rfjjHHvqlenpr9sUpx3rUzmZONBd52zNczsl94qsRRn JBpqMRcVJwIA4+CEqsoCAAA= X-CMS-MailID: 20231130115055epcas5p4e29befa80877be45dbee308846edc0ba X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-Sendblock-Type: REQ_APPROVE CMS-TYPE: 105P DLP-Filter: Pass X-CFilter-Loop: Reflected X-CMS-RootMailID: 20231130115055epcas5p4e29befa80877be45dbee308846edc0ba References: <CGME20231130115055epcas5p4e29befa80877be45dbee308846edc0ba@epcas5p4.samsung.com> X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Thu, 30 Nov 2023 05:51:17 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783997218117506996 X-GMAIL-MSGID: 1783997218117506996 |
Series |
Add support for RAS DES feature in PCIe DW controller
|
|
Message
Shradha Todi
Nov. 30, 2023, 11:50 a.m. UTC
DesignWare controller provides a vendor specific extended capability called RASDES as an IP feature. This extended capability provides hardware information like: - Debug registers to know the state of the link or controller. - Error injection mechanisms to inject various PCIe errors including sequence number, CRC - Statistical counters to know how many times a particular event occurred However, in Linux we do not have any generic or custom support to be able to use this feature in an efficient manner. This is the reason we are proposing this framework. Debug and bring up time of high-speed IPs are highly dependent on costlier hardware analyzers and this solution will in some ways help to reduce the HW analyzer usage. The debugfs entries can be used to get information about underlying hardware and can be shared with user space. Separate debugfs entries has been created to cater to all the DES hooks provided by the controller. The debugfs entries interacts with the RASDES registers in the required sequence and provides the meaningful data to the user. This eases the effort to understand and use the register information for debugging. v1 version was posted long back and for some reasons I couldn't work on it. I apologize for the long break. I'm restarting this activity and have taken care of all previous review comments shared. v1: https://lore.kernel.org/all/20210518174618.42089-1-shradha.t@samsung.com/T/ Shradha Todi (3): PCI: dwc: Add support for vendor specific capability search PCI: debugfs: Add support for RASDES framework in DWC PCI: dwc: Create debugfs files in DWC driver drivers/pci/controller/dwc/Kconfig | 8 + drivers/pci/controller/dwc/Makefile | 1 + .../controller/dwc/pcie-designware-debugfs.c | 476 ++++++++++++++++++ .../controller/dwc/pcie-designware-debugfs.h | 0 drivers/pci/controller/dwc/pcie-designware.c | 20 + drivers/pci/controller/dwc/pcie-designware.h | 18 + 6 files changed, 523 insertions(+) create mode 100644 drivers/pci/controller/dwc/pcie-designware-debugfs.c create mode 100644 drivers/pci/controller/dwc/pcie-designware-debugfs.h
Comments
On Thu, Nov 30, 2023 at 05:20:41PM +0530, Shradha Todi wrote: > DesignWare controller provides a vendor specific extended capability > called RASDES as an IP feature. This extended capability provides > hardware information like: > - Debug registers to know the state of the link or controller. > - Error injection mechanisms to inject various PCIe errors including > sequence number, CRC > - Statistical counters to know how many times a particular event > occurred > > However, in Linux we do not have any generic or custom support to be > able to use this feature in an efficient manner. This is the reason we > are proposing this framework. Debug and bring up time of high-speed IPs > are highly dependent on costlier hardware analyzers and this solution > will in some ways help to reduce the HW analyzer usage. > > The debugfs entries can be used to get information about underlying > hardware and can be shared with user space. Separate debugfs entries has > been created to cater to all the DES hooks provided by the controller. > The debugfs entries interacts with the RASDES registers in the required > sequence and provides the meaningful data to the user. This eases the > effort to understand and use the register information for debugging. > > v1 version was posted long back and for some reasons I couldn't work on > it. I apologize for the long break. I'm restarting this activity and > have taken care of all previous review comments shared. > v1: https://lore.kernel.org/all/20210518174618.42089-1-shradha.t@samsung.com/T/ > There is already a series floating to add similar functionality via perf subsystem: https://lore.kernel.org/linux-pci/20231121013400.18367-1-xueshuai@linux.alibaba.com/ - Mani > Shradha Todi (3): > PCI: dwc: Add support for vendor specific capability search > PCI: debugfs: Add support for RASDES framework in DWC > PCI: dwc: Create debugfs files in DWC driver > > drivers/pci/controller/dwc/Kconfig | 8 + > drivers/pci/controller/dwc/Makefile | 1 + > .../controller/dwc/pcie-designware-debugfs.c | 476 ++++++++++++++++++ > .../controller/dwc/pcie-designware-debugfs.h | 0 > drivers/pci/controller/dwc/pcie-designware.c | 20 + > drivers/pci/controller/dwc/pcie-designware.h | 18 + > 6 files changed, 523 insertions(+) > create mode 100644 drivers/pci/controller/dwc/pcie-designware-debugfs.c > create mode 100644 drivers/pci/controller/dwc/pcie-designware-debugfs.h > > -- > 2.17.1 >
> -----Original Message----- > From: Manivannan Sadhasivam [mailto:manivannan.sadhasivam@linaro.org] > Sent: 30 November 2023 22:25 > To: Shradha Todi <shradha.t@samsung.com> > Cc: lpieralisi@kernel.org; kw@linux.com; robh@kernel.org; > bhelgaas@google.com; jingoohan1@gmail.com; > gustavo.pimentel@synopsys.com; josh@joshtriplett.org; > lukas.bulwahn@gmail.com; hongxing.zhu@nxp.com; > pankaj.dubey@samsung.com; linux-kernel@vger.kernel.org; linux- > pci@vger.kernel.org > Subject: Re: [PATCH v2 0/3] Add support for RAS DES feature in PCIe DW > controller > > On Thu, Nov 30, 2023 at 05:20:41PM +0530, Shradha Todi wrote: > > DesignWare controller provides a vendor specific extended capability > > called RASDES as an IP feature. This extended capability provides > > hardware information like: > > - Debug registers to know the state of the link or controller. > > - Error injection mechanisms to inject various PCIe errors including > > sequence number, CRC > > - Statistical counters to know how many times a particular event > > occurred > > > > However, in Linux we do not have any generic or custom support to be > > able to use this feature in an efficient manner. This is the reason we > > are proposing this framework. Debug and bring up time of high-speed > > IPs are highly dependent on costlier hardware analyzers and this > > solution will in some ways help to reduce the HW analyzer usage. > > > > The debugfs entries can be used to get information about underlying > > hardware and can be shared with user space. Separate debugfs entries > > has been created to cater to all the DES hooks provided by the controller. > > The debugfs entries interacts with the RASDES registers in the > > required sequence and provides the meaningful data to the user. This > > eases the effort to understand and use the register information for > debugging. > > > > v1 version was posted long back and for some reasons I couldn't work > > on it. I apologize for the long break. I'm restarting this activity > > and have taken care of all previous review comments shared. > > v1: > > https://lore.kernel.org/all/20210518174618.42089-1-shradha.t@samsung.c > > om/T/ > > > > There is already a series floating to add similar functionality via perf > subsystem: https://lore.kernel.org/linux-pci/20231121013400.18367-1- > xueshuai@linux.alibaba.com/ > > - Mani > Hi Mani, The series proposed in perf includes only time based-analysis and event counters which will monitor performance (Group 6 and 7). The patch or framework that we have proposed includes debug information, error injection facility and error counters (Group 0 - 5) which are not included as part of the functionality implemented via perf. In my opinion, these functionalities don't count as performance monitoring or counters but rather as debug counters. How about we take this up as a debugfs framework as proposed in my patch? Or if others feel it can be taken via perf driver then I am happy to extend the perf driver if authors do not have objection. Let me know what you think of this? Meanwhile I will review the perf patches and share my feedback. > > Shradha Todi (3): > > PCI: dwc: Add support for vendor specific capability search > > PCI: debugfs: Add support for RASDES framework in DWC > > PCI: dwc: Create debugfs files in DWC driver > > > > drivers/pci/controller/dwc/Kconfig | 8 + > > drivers/pci/controller/dwc/Makefile | 1 + > > .../controller/dwc/pcie-designware-debugfs.c | 476 > ++++++++++++++++++ > > .../controller/dwc/pcie-designware-debugfs.h | 0 > > drivers/pci/controller/dwc/pcie-designware.c | 20 + > > drivers/pci/controller/dwc/pcie-designware.h | 18 + > > 6 files changed, 523 insertions(+) > > create mode 100644 > > drivers/pci/controller/dwc/pcie-designware-debugfs.c > > create mode 100644 > > drivers/pci/controller/dwc/pcie-designware-debugfs.h > > > > -- > > 2.17.1 > > > > -- > மணிவண்ணன் சதாசிவம்
> -----Original Message----- > From: Shradha Todi <shradha.t@samsung.com> > Sent: 04 December 2023 14:10 > To: 'Manivannan Sadhasivam' <manivannan.sadhasivam@linaro.org> > Cc: 'lpieralisi@kernel.org' <lpieralisi@kernel.org>; 'kw@linux.com' > <kw@linux.com>; 'robh@kernel.org' <robh@kernel.org>; > 'bhelgaas@google.com' <bhelgaas@google.com>; 'jingoohan1@gmail.com' > <jingoohan1@gmail.com>; 'gustavo.pimentel@synopsys.com' > <gustavo.pimentel@synopsys.com>; 'josh@joshtriplett.org' > <josh@joshtriplett.org>; 'lukas.bulwahn@gmail.com' > <lukas.bulwahn@gmail.com>; 'hongxing.zhu@nxp.com' > <hongxing.zhu@nxp.com>; 'pankaj.dubey@samsung.com' > <pankaj.dubey@samsung.com>; 'linux-kernel@vger.kernel.org' <linux- > kernel@vger.kernel.org>; 'linux-pci@vger.kernel.org' <linux- > pci@vger.kernel.org> > Subject: RE: [PATCH v2 0/3] Add support for RAS DES feature in PCIe DW > controller > > > > > -----Original Message----- > > From: Manivannan Sadhasivam [mailto:manivannan.sadhasivam@linaro.org] > > Sent: 30 November 2023 22:25 > > To: Shradha Todi <shradha.t@samsung.com> > > Cc: lpieralisi@kernel.org; kw@linux.com; robh@kernel.org; > > bhelgaas@google.com; jingoohan1@gmail.com; > > gustavo.pimentel@synopsys.com; josh@joshtriplett.org; > > lukas.bulwahn@gmail.com; hongxing.zhu@nxp.com; > > pankaj.dubey@samsung.com; linux-kernel@vger.kernel.org; linux- > > pci@vger.kernel.org > > Subject: Re: [PATCH v2 0/3] Add support for RAS DES feature in PCIe DW > > controller > > > > On Thu, Nov 30, 2023 at 05:20:41PM +0530, Shradha Todi wrote: > > > DesignWare controller provides a vendor specific extended capability > > > called RASDES as an IP feature. This extended capability provides > > > hardware information like: > > > - Debug registers to know the state of the link or controller. > > > - Error injection mechanisms to inject various PCIe errors including > > > sequence number, CRC > > > - Statistical counters to know how many times a particular event > > > occurred > > > > > > However, in Linux we do not have any generic or custom support to be > > > able to use this feature in an efficient manner. This is the reason > > > we are proposing this framework. Debug and bring up time of > > > high-speed IPs are highly dependent on costlier hardware analyzers > > > and this solution will in some ways help to reduce the HW analyzer usage. > > > > > > The debugfs entries can be used to get information about underlying > > > hardware and can be shared with user space. Separate debugfs entries > > > has been created to cater to all the DES hooks provided by the controller. > > > The debugfs entries interacts with the RASDES registers in the > > > required sequence and provides the meaningful data to the user. This > > > eases the effort to understand and use the register information for > > debugging. > > > > > > v1 version was posted long back and for some reasons I couldn't work > > > on it. I apologize for the long break. I'm restarting this activity > > > and have taken care of all previous review comments shared. > > > v1: > > > https://lore.kernel.org/all/20210518174618.42089-1-shradha.t@samsung > > > .c > > > om/T/ > > > > > > > There is already a series floating to add similar functionality via > > perf > > subsystem: https://lore.kernel.org/linux-pci/20231121013400.18367-1- > > xueshuai@linux.alibaba.com/ > > > > - Mani > > > > Hi Mani, > > The series proposed in perf includes only time based-analysis and event counters > which will monitor performance (Group 6 and 7). The patch or framework that we > have proposed includes debug information, error injection facility and error > counters (Group 0 - 5) which are not included as part of the functionality > implemented via perf. In my opinion, these functionalities don't count as > performance monitoring or counters but rather as debug counters. How about > we take this up as a debugfs framework as proposed in my patch? > Or if others feel it can be taken via perf driver then I am happy to extend the perf > driver if authors do not have objection. Let me know what you think of this? > Meanwhile I will review the perf patches and share my feedback. > Hello Mani, Any update on the above comment? IMO, even though the perf patches and this patchset are both part of the DWC vendor specific capability - RASDES, they cover different features. The perf file includes performance based parameters like time-based analysis and event counters for count of packets whereas this patchset includes debugging fields, error injection and event counters for count of errors. I think having a separate debugfs file fits more but would you suggest we extend the perf file itself? Shradha > > > Shradha Todi (3): > > > PCI: dwc: Add support for vendor specific capability search > > > PCI: debugfs: Add support for RASDES framework in DWC > > > PCI: dwc: Create debugfs files in DWC driver > > > > > > drivers/pci/controller/dwc/Kconfig | 8 + > > > drivers/pci/controller/dwc/Makefile | 1 + > > > .../controller/dwc/pcie-designware-debugfs.c | 476 > > ++++++++++++++++++ > > > .../controller/dwc/pcie-designware-debugfs.h | 0 > > > drivers/pci/controller/dwc/pcie-designware.c | 20 + > > > drivers/pci/controller/dwc/pcie-designware.h | 18 + > > > 6 files changed, 523 insertions(+) > > > create mode 100644 > > > drivers/pci/controller/dwc/pcie-designware-debugfs.c > > > create mode 100644 > > > drivers/pci/controller/dwc/pcie-designware-debugfs.h > > > > > > -- > > > 2.17.1 > > > > > > > -- > > மணிவண்ணன் சதாசிவம்
On Wed, Jan 03, 2024 at 11:13:20AM +0530, Shradha Todi wrote: > > > > -----Original Message----- > > From: Shradha Todi <shradha.t@samsung.com> > > Sent: 04 December 2023 14:10 > > To: 'Manivannan Sadhasivam' <manivannan.sadhasivam@linaro.org> > > Cc: 'lpieralisi@kernel.org' <lpieralisi@kernel.org>; 'kw@linux.com' > > <kw@linux.com>; 'robh@kernel.org' <robh@kernel.org>; > > 'bhelgaas@google.com' <bhelgaas@google.com>; 'jingoohan1@gmail.com' > > <jingoohan1@gmail.com>; 'gustavo.pimentel@synopsys.com' > > <gustavo.pimentel@synopsys.com>; 'josh@joshtriplett.org' > > <josh@joshtriplett.org>; 'lukas.bulwahn@gmail.com' > > <lukas.bulwahn@gmail.com>; 'hongxing.zhu@nxp.com' > > <hongxing.zhu@nxp.com>; 'pankaj.dubey@samsung.com' > > <pankaj.dubey@samsung.com>; 'linux-kernel@vger.kernel.org' <linux- > > kernel@vger.kernel.org>; 'linux-pci@vger.kernel.org' <linux- > > pci@vger.kernel.org> > > Subject: RE: [PATCH v2 0/3] Add support for RAS DES feature in PCIe DW > > controller > > > > > > > > > -----Original Message----- > > > From: Manivannan Sadhasivam [mailto:manivannan.sadhasivam@linaro.org] > > > Sent: 30 November 2023 22:25 > > > To: Shradha Todi <shradha.t@samsung.com> > > > Cc: lpieralisi@kernel.org; kw@linux.com; robh@kernel.org; > > > bhelgaas@google.com; jingoohan1@gmail.com; > > > gustavo.pimentel@synopsys.com; josh@joshtriplett.org; > > > lukas.bulwahn@gmail.com; hongxing.zhu@nxp.com; > > > pankaj.dubey@samsung.com; linux-kernel@vger.kernel.org; linux- > > > pci@vger.kernel.org > > > Subject: Re: [PATCH v2 0/3] Add support for RAS DES feature in PCIe DW > > > controller > > > > > > On Thu, Nov 30, 2023 at 05:20:41PM +0530, Shradha Todi wrote: > > > > DesignWare controller provides a vendor specific extended capability > > > > called RASDES as an IP feature. This extended capability provides > > > > hardware information like: > > > > - Debug registers to know the state of the link or controller. > > > > - Error injection mechanisms to inject various PCIe errors including > > > > sequence number, CRC > > > > - Statistical counters to know how many times a particular event > > > > occurred > > > > > > > > However, in Linux we do not have any generic or custom support to be > > > > able to use this feature in an efficient manner. This is the reason > > > > we are proposing this framework. Debug and bring up time of > > > > high-speed IPs are highly dependent on costlier hardware analyzers > > > > and this solution will in some ways help to reduce the HW analyzer usage. > > > > > > > > The debugfs entries can be used to get information about underlying > > > > hardware and can be shared with user space. Separate debugfs entries > > > > has been created to cater to all the DES hooks provided by the controller. > > > > The debugfs entries interacts with the RASDES registers in the > > > > required sequence and provides the meaningful data to the user. This > > > > eases the effort to understand and use the register information for > > > debugging. > > > > > > > > v1 version was posted long back and for some reasons I couldn't work > > > > on it. I apologize for the long break. I'm restarting this activity > > > > and have taken care of all previous review comments shared. > > > > v1: > > > > https://lore.kernel.org/all/20210518174618.42089-1-shradha.t@samsung > > > > .c > > > > om/T/ > > > > > > > > > > There is already a series floating to add similar functionality via > > > perf > > > subsystem: https://lore.kernel.org/linux-pci/20231121013400.18367-1- > > > xueshuai@linux.alibaba.com/ > > > > > > - Mani > > > > > > > Hi Mani, > > > > The series proposed in perf includes only time based-analysis and event counters > > which will monitor performance (Group 6 and 7). The patch or framework that we > > have proposed includes debug information, error injection facility and error > > counters (Group 0 - 5) which are not included as part of the functionality > > implemented via perf. In my opinion, these functionalities don't count as > > performance monitoring or counters but rather as debug counters. How about > > we take this up as a debugfs framework as proposed in my patch? > > Or if others feel it can be taken via perf driver then I am happy to extend the perf > > driver if authors do not have objection. Let me know what you think of this? > > Meanwhile I will review the perf patches and share my feedback. > > > > Hello Mani, > Any update on the above comment? IMO, even though the perf patches and this > patchset are both part of the DWC vendor specific capability - RASDES, they > cover different features. The perf file includes performance based parameters > like time-based analysis and event counters for count of packets whereas this > patchset includes debugging fields, error injection and event counters for count > of errors. I think having a separate debugfs file fits more but would you suggest > we extend the perf file itself? > For the error injection and counters, we already have the EDAC framework. So adding them in the DWC driver doesn't make sense to me. But first check with the perf driver author if they have any plans on adding the proposed functionality. If they do not have any plan or not working on it, then look into EDAC. - Mani > Shradha > > > > > Shradha Todi (3): > > > > PCI: dwc: Add support for vendor specific capability search > > > > PCI: debugfs: Add support for RASDES framework in DWC > > > > PCI: dwc: Create debugfs files in DWC driver > > > > > > > > drivers/pci/controller/dwc/Kconfig | 8 + > > > > drivers/pci/controller/dwc/Makefile | 1 + > > > > .../controller/dwc/pcie-designware-debugfs.c | 476 > > > ++++++++++++++++++ > > > > .../controller/dwc/pcie-designware-debugfs.h | 0 > > > > drivers/pci/controller/dwc/pcie-designware.c | 20 + > > > > drivers/pci/controller/dwc/pcie-designware.h | 18 + > > > > 6 files changed, 523 insertions(+) > > > > create mode 100644 > > > > drivers/pci/controller/dwc/pcie-designware-debugfs.c > > > > create mode 100644 > > > > drivers/pci/controller/dwc/pcie-designware-debugfs.h > > > > > > > > -- > > > > 2.17.1 > > > > > > > > > > -- > > > மணிவண்ணன் சதாசிவம் > >
> -----Original Message----- > From: 'Manivannan Sadhasivam' <manivannan.sadhasivam@linaro.org> > Sent: 04 January 2024 11:21 > To: Shradha Todi <shradha.t@samsung.com> > Cc: lpieralisi@kernel.org; kw@linux.com; robh@kernel.org; > bhelgaas@google.com; jingoohan1@gmail.com; > gustavo.pimentel@synopsys.com; josh@joshtriplett.org; > lukas.bulwahn@gmail.com; hongxing.zhu@nxp.com; > pankaj.dubey@samsung.com; linux-kernel@vger.kernel.org; linux- > pci@vger.kernel.org > Subject: Re: [PATCH v2 0/3] Add support for RAS DES feature in PCIe DW > controller > > On Wed, Jan 03, 2024 at 11:13:20AM +0530, Shradha Todi wrote: > > > > > > > -----Original Message----- > > > From: Shradha Todi <shradha.t@samsung.com> > > > Sent: 04 December 2023 14:10 > > > To: 'Manivannan Sadhasivam' <manivannan.sadhasivam@linaro.org> > > > Cc: 'lpieralisi@kernel.org' <lpieralisi@kernel.org>; 'kw@linux.com' > > > <kw@linux.com>; 'robh@kernel.org' <robh@kernel.org>; > > > 'bhelgaas@google.com' <bhelgaas@google.com>; 'jingoohan1@gmail.com' > > > <jingoohan1@gmail.com>; 'gustavo.pimentel@synopsys.com' > > > <gustavo.pimentel@synopsys.com>; 'josh@joshtriplett.org' > > > <josh@joshtriplett.org>; 'lukas.bulwahn@gmail.com' > > > <lukas.bulwahn@gmail.com>; 'hongxing.zhu@nxp.com' > > > <hongxing.zhu@nxp.com>; 'pankaj.dubey@samsung.com' > > > <pankaj.dubey@samsung.com>; 'linux-kernel@vger.kernel.org' <linux- > > > kernel@vger.kernel.org>; 'linux-pci@vger.kernel.org' <linux- > > > pci@vger.kernel.org> > > > Subject: RE: [PATCH v2 0/3] Add support for RAS DES feature in PCIe > > > DW controller > > > > > > > > > > > > > -----Original Message----- > > > > From: Manivannan Sadhasivam > > > > [mailto:manivannan.sadhasivam@linaro.org] > > > > Sent: 30 November 2023 22:25 > > > > To: Shradha Todi <shradha.t@samsung.com> > > > > Cc: lpieralisi@kernel.org; kw@linux.com; robh@kernel.org; > > > > bhelgaas@google.com; jingoohan1@gmail.com; > > > > gustavo.pimentel@synopsys.com; josh@joshtriplett.org; > > > > lukas.bulwahn@gmail.com; hongxing.zhu@nxp.com; > > > > pankaj.dubey@samsung.com; linux-kernel@vger.kernel.org; linux- > > > > pci@vger.kernel.org > > > > Subject: Re: [PATCH v2 0/3] Add support for RAS DES feature in > > > > PCIe DW controller > > > > > > > > On Thu, Nov 30, 2023 at 05:20:41PM +0530, Shradha Todi wrote: > > > > > DesignWare controller provides a vendor specific extended > > > > > capability called RASDES as an IP feature. This extended > > > > > capability provides hardware information like: > > > > > - Debug registers to know the state of the link or controller. > > > > > - Error injection mechanisms to inject various PCIe errors including > > > > > sequence number, CRC > > > > > - Statistical counters to know how many times a particular event > > > > > occurred > > > > > > > > > > However, in Linux we do not have any generic or custom support > > > > > to be able to use this feature in an efficient manner. This is > > > > > the reason we are proposing this framework. Debug and bring up > > > > > time of high-speed IPs are highly dependent on costlier hardware > > > > > analyzers and this solution will in some ways help to reduce the HW > analyzer usage. > > > > > > > > > > The debugfs entries can be used to get information about > > > > > underlying hardware and can be shared with user space. Separate > > > > > debugfs entries has been created to cater to all the DES hooks provided > by the controller. > > > > > The debugfs entries interacts with the RASDES registers in the > > > > > required sequence and provides the meaningful data to the user. > > > > > This eases the effort to understand and use the register > > > > > information for > > > > debugging. > > > > > > > > > > v1 version was posted long back and for some reasons I couldn't > > > > > work on it. I apologize for the long break. I'm restarting this > > > > > activity and have taken care of all previous review comments shared. > > > > > v1: > > > > > https://lore.kernel.org/all/20210518174618.42089-1-shradha.t@sam > > > > > sung > > > > > .c > > > > > om/T/ > > > > > > > > > > > > > There is already a series floating to add similar functionality > > > > via perf > > > > subsystem: > > > > https://lore.kernel.org/linux-pci/20231121013400.18367-1- > > > > xueshuai@linux.alibaba.com/ > > > > > > > > - Mani > > > > > > > > > > Hi Mani, > > > > > > The series proposed in perf includes only time based-analysis and > > > event counters which will monitor performance (Group 6 and 7). The > > > patch or framework that we have proposed includes debug information, > > > error injection facility and error counters (Group 0 - 5) which are > > > not included as part of the functionality implemented via perf. In > > > my opinion, these functionalities don't count as performance > > > monitoring or counters but rather as debug counters. How about we take this > up as a debugfs framework as proposed in my patch? > > > Or if others feel it can be taken via perf driver then I am happy to > > > extend the perf driver if authors do not have objection. Let me know what > you think of this? > > > Meanwhile I will review the perf patches and share my feedback. > > > > > > > Hello Mani, > > Any update on the above comment? IMO, even though the perf patches and > > this patchset are both part of the DWC vendor specific capability - > > RASDES, they cover different features. The perf file includes > > performance based parameters like time-based analysis and event > > counters for count of packets whereas this patchset includes debugging > > fields, error injection and event counters for count of errors. I > > think having a separate debugfs file fits more but would you suggest we extend > the perf file itself? > > > > For the error injection and counters, we already have the EDAC framework. So > adding them in the DWC driver doesn't make sense to me. > Sorry for late response, was going through the EDAC framework to understand better how we can fit RAS DES support in it. Below are some technical challenges found so far: 1: This debugfs framework proposed [1] can run on both side of the link i.e. RC and EP as it will be a part of the link controller platform driver Here for the EP side the assumption is that it has Linux running, which is primarily a use case for chip-to-chip communication. After your suggestion to migrate to EDAC framework we studied and here are the findings: - If we move to EDAC framework, we need to have RAS DES as a pci_driver which will be binded based on vendor_id and device_id. Our observation is that on EP side system we are unable to bind two function driver (pci_driver), as pci_endpoint_test function driver or some other chip-to-chip function driver will already be bound. On the other hand, on RC side we observed that if we have portdrv enabled in Linux running on RC system, it gets bound to RC controller and then it does not allow EDAC pci_driver to bind. So basically we see a problem here, that we can't have two pci_driver binding to same PCI device 2: Another point is even though we use EDAC driver framework, we may not be able to use any of EDAC framework APIs as they are mostly suitable for memory controller devices sitting on PCI BUS. We will end up using debugfs entries just via a pci_driver placed inside EDAC framework. Please let me know if my understanding is wrong. > But first check with the perf driver author if they have any plans on adding the > proposed functionality. If they do not have any plan or not working on it, then > look into EDAC. > > - Mani > Since we already worked and posted patches [1], [2], we will continue to work on this and based on consent from community we will adopt to most suitable framework. We see many subsystems like ethernet, usb, gpu, cxl having debugfs files that give information about the current status of the running system and as of now based on our findings, we still feel there is no harm in having debugfs entry based support in DesignWare controller driver itself. Others any opinion please? [1]: https://lkml.org/lkml/2021/5/18/1371 [2]: https://lkml.org/lkml/2023/11/30/574 > > Shradha > > > > > > > Shradha Todi (3): > > > > > PCI: dwc: Add support for vendor specific capability search > > > > > PCI: debugfs: Add support for RASDES framework in DWC > > > > > PCI: dwc: Create debugfs files in DWC driver > > > > > > > > > > drivers/pci/controller/dwc/Kconfig | 8 + > > > > > drivers/pci/controller/dwc/Makefile | 1 + > > > > > .../controller/dwc/pcie-designware-debugfs.c | 476 > > > > ++++++++++++++++++ > > > > > .../controller/dwc/pcie-designware-debugfs.h | 0 > > > > > drivers/pci/controller/dwc/pcie-designware.c | 20 + > > > > > drivers/pci/controller/dwc/pcie-designware.h | 18 + > > > > > 6 files changed, 523 insertions(+) create mode 100644 > > > > > drivers/pci/controller/dwc/pcie-designware-debugfs.c > > > > > create mode 100644 > > > > > drivers/pci/controller/dwc/pcie-designware-debugfs.h > > > > > > > > > > -- > > > > > 2.17.1 > > > > > > > > > > > > > -- > > > > மணிவண்ணன் சதாசிவம் > > > > > > -- > மணிவண்ணன் சதாசிவம்
On Thu, Feb 15, 2024 at 02:55:06PM +0530, Shradha Todi wrote: > > [...] > > For the error injection and counters, we already have the EDAC framework. So > > adding them in the DWC driver doesn't make sense to me. > > > > Sorry for late response, was going through the EDAC framework to understand better how we can fit RAS DES support in it. Below are some technical challenges found so far: > 1: This debugfs framework proposed [1] can run on both side of the link i.e. RC and EP as it will be a part of the link controller platform driver. Here for the EP side the assumption is that it has Linux running, which is primarily a use case for chip-to-chip communication. After your suggestion to migrate to EDAC framework we studied and here are the findings: > - If we move to EDAC framework, we need to have RAS DES as a pci_driver which will be binded based on vendor_id and device_id. Our observation is that on EP side system we are unable to bind two function driver (pci_driver), as pci_endpoint_test function driver or some other chip-to-chip function driver will already be bound. On the other hand, on RC side we observed that if we have portdrv enabled in Linux running on RC system, it gets bound to RC controller and then it does not allow EDAC pci_driver to bind. So basically we see a problem here, that we can't have two pci_driver binding to same PCI device > 2: Another point is even though we use EDAC driver framework, we may not be able to use any of EDAC framework APIs as they are mostly suitable for memory controller devices sitting on PCI BUS. We will end up using debugfs entries just via a pci_driver placed inside EDAC framework. Please wrap your replies to 80 characters. There is no need to bind the edac driver to VID:PID of the device. The edac driver can be a platform driver and you can instantiate the platform device from the DWC driver. This way, the PCI device can be assocaited with whatever driver, but still there can be a separate edac driver for handling errors. Regarding API limitation, you should ask the maintainer about the possibility of extending them. > > Please let me know if my understanding is wrong. > > > But first check with the perf driver author if they have any plans on adding the > > proposed functionality. If they do not have any plan or not working on it, then > > look into EDAC. > > > > - Mani > > > > Since we already worked and posted patches [1], [2], we will continue to work on this and based on consent from community we will adopt to most suitable framework. > We see many subsystems like ethernet, usb, gpu, cxl having debugfs files that give information about the current status of the running system and as of now based on our findings, we still feel there is no harm in having debugfs entry based support in DesignWare controller driver itself. There is no issue in exposing the debug information through debugfs, that's the sole purpose of the interface. But here, you are trying to add support for DWC RAS feature for which a dedicated framework already exists. And there will be more similar requests coming for vendor specific error protocols as well. So your investigation could benefit everyone. From your above investigation, looks like there are some shortcomings of the EDAC framework. So let's get that clarified by writing to the EDAC maintainers (keep us in CC). If the EDAC maintainer suggests you to add support for this feature in DWC driver itself citing some reasons, then no issues with me. - Mani
+ Borislav, Tony, James, Mauro, Robert Hi All, Synopsys DesignWare PCIe controllers have a vendor specific capability (which means that this set of registers are only present in DesignWare controllers) to perform debug operations called "RASDES". The functionalities provided by this extended capability are: 1. Debug: This has some debug related diagnostic features like holding LTSSM in certain states, reading the status of lane detection, checking if any PCIe lanes are broken (RX Valid) and so on. It's a debug only feature used for diagnostic use-cases. 2. Error Injection: This is a way to inject certain errors in PCIe like LCRC, ECRC, Bad TLPs and so on. Again, this is a debug feature and generally not used in functional use-case. 3. Statistical counters: This has 3 parts - Error counters - Non error counters (covered as part of perf [1]) - Time based analysis counters (covered as part of perf [1]) Selective features of the above functionality has been implemented by vendor specific PCIe controller drivers (pcie-tegra194.c) that use Synopsys DesignWare PCIe controllers. In order to make it useful to all vendors using DWC controller, we had proposed a common implementation in DWC PCIe controller directory (drivers/pci/controller/dwc/) and our original idea was based on debugfs filesystem. v1 and v2 are mentioned in [2] and [3]. We got a suggestion to implement this as part of EDAC framework [3] and we looked into the same. But as far as I understood, what I am trying to implement is a very specific feature (only valid for Synopsys DWC PCIe controllers). This doesn't seem to fit in very well with the EDAC framework and we can hardly use any of the EDAC framework APIs. We tried implementing a "pci_driver" but since a function driver will already be running on the EP and portdrv on the root-complex, we will not be able to bind 2 drivers to a single PCI device (root-complex or endpoint). Ultimately, what I will be doing is writing a platform driver with debugfs entries which will be present in EDAC directory instead of DWC directory. Can you please help us out by going through this thread [3] and letting us know if our understanding is wrong at any point. If you think it is a better idea to integrate this in the EDAC framework, can you guide me as to how I can utilize the framework better? Please let me know if you need any other information to conclude. [1] https://lore.kernel.org/linux-pci/20231121013400.18367-1-xueshuai@linux.alibaba.com/ [2] https://lore.kernel.org/all/20210518174618.42089-1-shradha.t@samsung.com/T/ [3] https://lore.kernel.org/all/20231130115044.53512-1-shradha.t@samsung.com/ Thanks, Shradha > -----Original Message----- > From: 'Manivannan Sadhasivam' <manivannan.sadhasivam@linaro.org> > Sent: 16 February 2024 19:19 > To: Shradha Todi <shradha.t@samsung.com> > Cc: lpieralisi@kernel.org; kw@linux.com; robh@kernel.org; > bhelgaas@google.com; jingoohan1@gmail.com; > gustavo.pimentel@synopsys.com; josh@joshtriplett.org; > lukas.bulwahn@gmail.com; hongxing.zhu@nxp.com; > pankaj.dubey@samsung.com; linux-kernel@vger.kernel.org; linux- > pci@vger.kernel.org; vidyas@nvidia.com; gost.dev@samsung.com > Subject: Re: [PATCH v2 0/3] Add support for RAS DES feature in PCIe DW > controller > > On Thu, Feb 15, 2024 at 02:55:06PM +0530, Shradha Todi wrote: > > > > > > [...] > > > > For the error injection and counters, we already have the EDAC > > > framework. So adding them in the DWC driver doesn't make sense to me. > > > > > > > Sorry for late response, was going through the EDAC framework to understand > better how we can fit RAS DES support in it. Below are some technical challenges > found so far: > > 1: This debugfs framework proposed [1] can run on both side of the link i.e. RC > and EP as it will be a part of the link controller platform driver. Here for the EP > side the assumption is that it has Linux running, which is primarily a use case for > chip-to-chip communication. After your suggestion to migrate to EDAC > framework we studied and here are the findings: > > - If we move to EDAC framework, we need to have RAS DES as a > > pci_driver which will be binded based on vendor_id and device_id. Our > > observation is that on EP side system we are unable to bind two > > function driver (pci_driver), as pci_endpoint_test function driver or > > some other chip-to-chip function driver will already be bound. On the > > other hand, on RC side we observed that if we have portdrv enabled in > > Linux running on RC system, it gets bound to RC controller and then it > > does not allow EDAC pci_driver to bind. So basically we see a problem > > here, that we can't have two pci_driver binding to same PCI device > > 2: Another point is even though we use EDAC driver framework, we may not be > able to use any of EDAC framework APIs as they are mostly suitable for memory > controller devices sitting on PCI BUS. We will end up using debugfs entries just via > a pci_driver placed inside EDAC framework. > > Please wrap your replies to 80 characters. > > There is no need to bind the edac driver to VID:PID of the device. The edac driver > can be a platform driver and you can instantiate the platform device from the > DWC driver. This way, the PCI device can be assocaited with whatever driver, but > still there can be a separate edac driver for handling errors. > > Regarding API limitation, you should ask the maintainer about the possibility of > extending them. > > > > > Please let me know if my understanding is wrong. > > > > > But first check with the perf driver author if they have any plans > > > on adding the proposed functionality. If they do not have any plan > > > or not working on it, then look into EDAC. > > > > > > - Mani > > > > > > > Since we already worked and posted patches [1], [2], we will continue to work > on this and based on consent from community we will adopt to most suitable > framework. > > We see many subsystems like ethernet, usb, gpu, cxl having debugfs files that > give information about the current status of the running system and as of now > based on our findings, we still feel there is no harm in having debugfs entry based > support in DesignWare controller driver itself. > > There is no issue in exposing the debug information through debugfs, that's the > sole purpose of the interface. But here, you are trying to add support for DWC > RAS feature for which a dedicated framework already exists. > > And there will be more similar requests coming for vendor specific error protocols > as well. So your investigation could benefit everyone. > > From your above investigation, looks like there are some shortcomings of the > EDAC framework. So let's get that clarified by writing to the EDAC maintainers > (keep us in CC). If the EDAC maintainer suggests you to add support for this > feature in DWC driver itself citing some reasons, then no issues with me. > > - Mani > > -- > மணிவண்ணன் சதாசிவம்