All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Spencer Ku (古世瑜)" <Spencer.Ku@quantatw.com>
To: "Bills, Jason M" <jason.m.bills@linux.intel.com>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
Subject: RE: Implement PCIeType Property
Date: Fri, 28 May 2021 08:38:00 +0000	[thread overview]
Message-ID: <HK0PR04MB3299AA6B3FA2E231728394A7E4229@HK0PR04MB3299.apcprd04.prod.outlook.com> (raw)
In-Reply-To: <7703a5cf-a967-a256-71e4-be3f2d7fa411@linux.intel.com>

Hi Bills,
Thanks for your suggestions!

> -----Original Message-----
> From: openbmc
> <openbmc-bounces+spencer.ku=quantatw.com@lists.ozlabs.org> On Behalf Of
> Bills, Jason M
> Sent: Thursday, May 27, 2021 11:27 PM
> To: openbmc@lists.ozlabs.org
> Subject: Re: Implement PCIeType Property
> 
> 
> 
> On 5/27/2021 12:09 AM, Spencer Ku (古世瑜) 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://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgerr
> >
> it.openbmc-project.xyz%2Fc%2Fopenbmc%2Fbmcweb%2F%2B%2F40051&amp;
> data=0
> >
> 4%7C01%7CSpencer.Ku%40quantatw.com%7Ccbc719c5057040f0540308d9212
> 42702%
> >
> 7C179b032707fc4973ac738de7313561b2%7C1%7C0%7C637577261446247949
> %7CUnkn
> >
> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
> aWwi
> >
> LCJXVCI6Mn0%3D%7C1000&amp;sdata=cp1tGa%2FR7fp2yKODaB8HX8%2BXPS
> mVGjHj4R
> > E6XANstic%3D&amp;reserved=0
> >
> > 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/<str>) . > And for bmcweb part, we will create
> PCIeInterface {"PCIeType"} level (under
> /redfish/v1/Systems/system/PCIeDevices/<str>/ ) 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.
Yes, it is actually the question what I meet. Since it is hard to add them together, I am try to find is there a way to get those data over PCI. 
>
> 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.
I think this is because redfish schema defined the property and it is convenience if we can get PCI information through one redfish URI.
But of course it should be a feasible method.
> 
> It may be good to discuss the design a bit for
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgerrit.op
> enbmc-project.xyz%2Fc%2Fopenbmc%2Fbmcweb%2F%2B%2F40051&amp;data
> =04%7C01%7CSpencer.Ku%40quantatw.com%7Ccbc719c5057040f0540308d92
> 1242702%7C179b032707fc4973ac738de7313561b2%7C1%7C0%7C637577261
> 446247949%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=cp1tGa%2FR
> 7fp2yKODaB8HX8%2BXPSmVGjHj4RE6XANstic%3D&amp;reserved=0.  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?
Yes, I think that's the good point to discuss about the design. I will put my comment to the PR.
> >
> > Please let us know if there's any issue, thank you!
> >
> > Sincerely,
> > Spencer Ku
> >

  reply	other threads:[~2021-05-28  8:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-27  7:09 Implement PCIeType Property Spencer Ku (古世瑜)
2021-05-27 15:27 ` Bills, Jason M
2021-05-28  8:38   ` Spencer Ku (古世瑜) [this message]
2021-05-31  7:01   ` Spencer Ku (古世瑜)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=HK0PR04MB3299AA6B3FA2E231728394A7E4229@HK0PR04MB3299.apcprd04.prod.outlook.com \
    --to=spencer.ku@quantatw.com \
    --cc=jason.m.bills@linux.intel.com \
    --cc=openbmc@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.