Hi, > > It does seem like the way we expose PCIe slot information is unnecessarily > tied to the question of whether the slot supports hotplug. Maybe the slot > number, e.g., the PCIe or SHPC "Physical Slot Number" could be exposed in > the device directory of the upstream bridge, e.g., > /sys/devices/pci0000:00/0000:00:1c.3/slot. I agree. I was looking for something similar but now I know I wasn't the only one :-). Please let me know when I take the conversation into another direction, but: There are more limitations, or maybe I just don't know how to achieve this: I have user space applications that, let's say for the sake of it, want to display the state of different hot pluggable slots in the system (occupied / unoccupied etc). They rely on UDEV insertion / removal events. However, currently the UDEV event that they get is a simple UDEV event for the PCI device that was added. Thus they get a long PCI pathname, instead of any clues about the slot number. And walking that path doesn't help them figuring out the slot number either. They have to look at the address of each slot in /sys/bus/pci/slots/ and then parse & compare and logically deduct which slot does this activity belong to. It would be much nice to have that slot info in all of the PCIe devices. > We currently make a > /sys/bus/pci/slots/X directory for hotplug slots, but X is a logical slot number > that is not the same as the physical slot number from the PCIe capability. Ummm, why do you say so? Looking at pciehp, atleast it attempts to create the slot with the same name as PCIe capability. Although the pci_create_slot() may rename it, but only if the firmware assigns same slot number to multiple slots. What is really missing is use of "chassis number" register as specified in the "Slot numbering" section of the specs (My system crashed last night and I do not have the specs in front of me anymore, I can provide references tomorrow). Consider a main chassis that has 2 slots, that have 2 cards (of the same type) populated. The add on cards themselves have hot pluggable slots on them. This is not an uncommon scenario, and I actually see this issue very frequently. In such scenario, pciehp is guaranteed to find the slot numbers programmed identically on the add-on cards. Depending on insertion / removal events, today, we cannot tell in advance what the slot number shall look like. Would be great if we could have the flexibility to name the slots something like <chassis-number>.<slot-number>. I think what we are missing today is that neither the chassis number register is populated, not it is used for slot numbering. I guess one of the reasons is that a lot of vendors do not implement that register at all, and even if they do, there is no way to tell (by looking at capability register), that the register is implemented. Thanks, Rajat > > Bjorn > > [1] > https://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming > > > On Fri, Mar 21, 2014 at 6:35 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> > wrote: > >> On Fri, Mar 21, 2014 at 3:47 PM, Cristina Olariu <colariu@xxxxxxxxx> wrote: > >> > >>> https://bugzilla.kernel.org/show_bug.cgi?id=72681 > >> > >>>>>> On Fri, Mar 21, 2014 at 11:56 AM, Cristina Olariu > >>>>>> <colariu@xxxxxxxxx> > >>>>>> wrote: > >>>>>> > > >>>>>> > I was trying to use the pci_slot module in order to associate a > >>>>>> > network interface to its corresponding network port by > >>>>>> > matching devices with physical slot information. > >>>>>> > > >>>>>> > Unfortunately the PCIe slots on our platform don't support the > >>>>>> > hot-plug function and the pci_slot module doesn't expose the > >>>>>> > slots interface in sysfs. > >>>>>> > > >>>>>> > Is there another way to list devices by physical add-in slots? > >>>>>> > We are using kernel version 3.4.67. > >>>>>> > Any pointers you may be able to offer would be appreciated. > >> > >> Your lspci (from the bugzilla mentioned above) shows 12 devices that > >> claim to have a slot, based on the PCIe Capabilities Register, but > >> most of them have a "Physical Slot Number" of zero: > >> > >> 00:01.0 Intel Root Port Slot #0 to [bus 01] > >> 00:02.0 Intel Root Port Slot #0 to [bus 02] > >> 00:02.2 Intel Root Port Slot #0 to [bus 03-09] > >> 00:03.0 Intel Root Port Slot #0 to [bus 0a-0b] > >> 00:03.1 Intel Root Port Slot #0 to [bus 0c-0d] > >> 00:03.2 Intel Root Port Slot #0 to [bus 0e] > >> 00:1c.0 Intel Root Port Slot #0 to [bus 10] > >> 00:1c.1 Intel Root Port Slot #0 to [bus 11] > >> 00:1c.2 Intel Root Port Slot #0 to [bus 12] > >> 04:00.0 PLX Downstream Port Slot #0 to [bus 05-06] > >> 04:01.0 PLX Downstream Port Slot #1 to [bus 07-08] > >> 04:08.0 PLX Downstream Port Slot #8 to [bus 09] > >> > >> 03:00.0 PLX Upstream Port to [bus 04-09] > >> 05:00.0 Intel 82599ES 10G NIC (in Slot #0) > >> 07:00.0 Intel 82599ES 10G NIC (in Slot #1) > >> > >> My guess is that the ones you care about are the slots connected to > >> the PLX Downstream Ports, but I don't know how to make a rule about > >> which ones we should expose. I think the slot code can disambiguate > >> them by adding a suffix, so I guess one possibility is to expose them > >> all as, e.g., "0", "0-1", "0-2", "0-3", etc. Then you'd end up with > >> the PLX Downstream Port slots being "0-9", "1", and "8", which seems > >> sort of ugly. > >> > >> What's the network port information you want to match up with these > >> slot numbers? > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in the > body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at > http://vger.kernel.org/majordomo-info.html > ��.n��������+%������w��{.n�����{���"�)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
