From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EE85AC47089 for ; Thu, 27 May 2021 15:29:05 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7E204613B5 for ; Thu, 27 May 2021 15:29:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7E204613B5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=openbmc-bounces+openbmc=archiver.kernel.org@lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4FrWv42dWGz307L for ; Fri, 28 May 2021 01:29:04 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=linux.intel.com (client-ip=134.134.136.31; helo=mga06.intel.com; envelope-from=jason.m.bills@linux.intel.com; receiver=) X-Greylist: delayed 63 seconds by postgrey-1.36 at boromir; Fri, 28 May 2021 01:28:41 AEST Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4FrWtd71lDz2yjL for ; Fri, 28 May 2021 01:28:41 +1000 (AEST) IronPort-SDR: bhw7ipYxcIzaW6udquvKHQrbGVUR4ZrWO60pOGBOzkblqYCf66fXvmAR/rHbdCh+uBwipmfSGG /G7cEtW7JEYw== X-IronPort-AV: E=McAfee;i="6200,9189,9997"; a="263961152" X-IronPort-AV: E=Sophos;i="5.82,334,1613462400"; d="scan'208";a="263961152" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 May 2021 08:27:26 -0700 IronPort-SDR: XYcqwtXHUciCkql71EXnYHt3dvc+G/Oivj9KYnWzusxSl66bm4LxjE5+wVcxbhttKIwKbmBGvj boxJs2AgnduQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.82,334,1613462400"; d="scan'208";a="548002628" Received: from linux.intel.com ([10.54.29.200]) by fmsmga001.fm.intel.com with ESMTP; 27 May 2021 08:27:22 -0700 Received: from [10.212.151.81] (jmbills-MOBL.amr.corp.intel.com [10.212.151.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by linux.intel.com (Postfix) with ESMTPS id B429E5807BA for ; Thu, 27 May 2021 08:27:22 -0700 (PDT) Subject: Re: Implement PCIeType Property To: openbmc@lists.ozlabs.org References: From: "Bills, Jason M" Message-ID: <7703a5cf-a967-a256-71e4-be3f2d7fa411@linux.intel.com> Date: Thu, 27 May 2021 08:27:22 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=big5; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: openbmc@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development list for OpenBMC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: openbmc-bounces+openbmc=archiver.kernel.org@lists.ozlabs.org Sender: "openbmc" On 5/27/2021 12:09 AM, Spencer Ku (¥j¥@·ì) wrote: > Hi All, > We would like to implement PCIeInterface "PCIeType" property on both peci-pcie and bmcweb, then I find the PR which implement inventory properties like SparePartNumber, Model, PartNumber, SerialNumber for PCIe devices in bmcweb: https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/40051 > > I think we modify similar part of bmcweb, but I am not sure does it will implement "PCIeType" property in the future. So could we implement "PCIeType" property first since the PR status is WIP? > > About the implement method, for peci-pcie part, first we use peci command to get the pointer of capability in PCI configure space. Then go through capability structure to find capability ID in 3rd capability structure. If the ID is PCI Express, then get the link speed in link status register. Finally, set the PCIeType property to D-Bus after translating (under /xyz/openbmc_project/PCIe/) . > > And for bmcweb part, we will create PCIeInterface {"PCIeType"} level (under /redfish/v1/Systems/system/PCIeDevices// ) and fill the info from D-bus. > > On the other hand, we also interested about how to get PartNumber and SerialNumber information? I already try to get from FRU over I2C but I cannot mapping the info between FRU and peci-pcie, or is it can easily get by peci-pcie? Any comments and suggestions are welcome! peci-pcie currently can only get information that is available over PCI. If these new fields come from somewhere other than PCI, it could be difficult to add them. If these new fields all come from the FRU, then we should already have that data in other applications, so we shouldn't need to get it in a PCI application. It may be good to discuss the design a bit for https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/40051. For example, I think FruDevice already has the FRU information for the PCIe devices. Does the PCI application need to communicate with FruDevice and expose the same information again in the PCIe inventory on D-Bus? Or, should bmcweb directly look for the FruDevice to populate these new fields? > > Please let us know if there's any issue, thank you! > > Sincerely, > Spencer Ku >