On Mon, 26 Sep 2022 12:18:57 -0500 Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > On Mon, Sep 26, 2022 at 09:31:34PM +0800, Shuai Xue wrote: > > 在 2022/9/23 PM11:54, Jonathan Cameron 写道: > > >> I found a similar definition in arch/ia64/pci/pci.c . > > >> > > >> #define PCI_SAL_ADDRESS(seg, bus, devfn, reg) \ > > >> (((u64) seg << 24) | (bus << 16) | (devfn << 8) | (reg)) > > >> > > >> Should we move it into a common header first? > > > > > > Maybe. The bus, devfn, reg part is standard bdf, but I don't think > > > the PCI 6.0 spec defined a version with the seg in the upper bits. > > > I'm not sure if we want to adopt that in LInux. > > > > I found lots of code use seg,bus,devfn,reg with format "%04x:%02x:%02x.%x", > > I am not quite familiar with PCIe spec. What do you think about it, Bjorn? > > The PCIe spec defines an address encoding for bus/device/function/reg > for the purposes of ECAM (PCIe r6.0, sec 7.2.2), but as far as I know, > it doesn't define anything similar that includes the segment. The > segment is really outside the scope of PCIe because each segment is a > completely separate PCIe hierarchy. It's beginning to get exposed in PCIe 6.0 as a result of enabling cross segment messages. Two places I know of that the segment can be seen in. Captured TLP headers with certain AER reported errors. Hierarchy ID Extended capability - this one takes some digging. Specifically 7.9.17.3 Hierarchy ID Data Register which if you follow link to 6.25 includes Segment Group Number. Anyhow, not particularly relevant here and it never occurs next to any of the BDF stuff but it is now (just about) in scope of PCIe. Jonathan > > So I probably wouldn't make this a generic definition. But if/when > you print things like this out, please do use the format spec you > mentioned above so it matches the style used elsewhere. > > Bjorn
