Discussion:
pciehp & other hot-plug drivers (shpc etc..)
Rajat Jain
2013-09-29 18:27:23 UTC
Permalink
Hello List,

Today all the PCI Hot-plug drivers (shpc, acpihp, cpqhp, ibmhp etc
except pciedhp) directly claim the downstream port bridge device.
Where as in case of pciehp, the PCIe port bus driver claims the bridge
device, and service drivers (aer, pm, pciehp) simply register for the
service with it.

1) Does that mean that in a system where I am using a driver other
than pciehp for hot-plug (eg. shpc), I cannot use service drivers like
AER or PM on the same port (since the device would be claimed by
shpc, it would not be available to port bus driver)?

2) In the same system, can I use SHPC on one port, and pciehp on
another port? I believe not?

Please note that it may not be a realistic scenarios, my intent of
asking is to just understand how things are intended to behave.

Thanks,

Rajat
Greg KH
2013-09-30 02:05:00 UTC
Permalink
Post by Rajat Jain
Hello List,
Today all the PCI Hot-plug drivers (shpc, acpihp, cpqhp, ibmhp etc
except pciedhp) directly claim the downstream port bridge device.
Where as in case of pciehp, the PCIe port bus driver claims the bridge
device, and service drivers (aer, pm, pciehp) simply register for the
service with it.
1) Does that mean that in a system where I am using a driver other
than pciehp for hot-plug (eg. shpc), I cannot use service drivers like
AER or PM on the same port (since the device would be claimed by
shpc, it would not be available to port bus driver)?
It depends on your system, and you BIOS, which sets up all of this
stuff. It's up to the kernel to bind to the proper things it exposes.
Post by Rajat Jain
2) In the same system, can I use SHPC on one port, and pciehp on
another port? I believe not?
Yes you can, but such a system seems really strange, do you know of any
that require it?
Post by Rajat Jain
Please note that it may not be a realistic scenarios, my intent of
asking is to just understand how things are intended to behave.
Again, it depends on your BIOS / hardware. They are the ones that
determine which driver handles this type of thing.

Hope this helps,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Rajat Jain
2013-10-04 01:08:15 UTC
Permalink
Hello,
Post by Greg KH
Post by Rajat Jain
Hello List,
Today all the PCI Hot-plug drivers (shpc, acpihp, cpqhp, ibmhp etc
except pciedhp) directly claim the downstream port bridge device.
Where as in case of pciehp, the PCIe port bus driver claims the bridge
device, and service drivers (aer, pm, pciehp) simply register for the
service with it.
1) Does that mean that in a system where I am using a driver other
than pciehp for hot-plug (eg. shpc), I cannot use service drivers like
AER or PM on the same port (since the device would be claimed by
shpc, it would not be available to port bus driver)?
It depends on your system, and you BIOS, which sets up all of this
stuff. It's up to the kernel to bind to the proper things it exposes.
Actually, I just wanted to understand that on a machine where
shpchp.ko is to be used for hot-plug, can I still use the AER port bus
service driver? My understanding is NO, because shpc will claim the
downstream port bridge, and hence port bus driver will not be able to
claim it?
Post by Greg KH
Post by Rajat Jain
2) In the same system, can I use SHPC on one port, and pciehp on
another port? I believe not?
Yes you can, but such a system seems really strange, do you know of any
that require it?
Post by Rajat Jain
Please note that it may not be a realistic scenarios, my intent of
asking is to just understand how things are intended to behave.
Again, it depends on your BIOS / hardware. They are the ones that
determine which driver handles this type of thing.
Hope this helps,
greg k-h
Bjorn Helgaas
2013-10-04 23:01:18 UTC
Permalink
Post by Rajat Jain
Hello,
Post by Greg KH
Post by Rajat Jain
Hello List,
Today all the PCI Hot-plug drivers (shpc, acpihp, cpqhp, ibmhp etc
except pciedhp) directly claim the downstream port bridge device.
Where as in case of pciehp, the PCIe port bus driver claims the bridge
device, and service drivers (aer, pm, pciehp) simply register for the
service with it.
1) Does that mean that in a system where I am using a driver other
than pciehp for hot-plug (eg. shpc), I cannot use service drivers like
AER or PM on the same port (since the device would be claimed by
shpc, it would not be available to port bus driver)?
It depends on your system, and you BIOS, which sets up all of this
stuff. It's up to the kernel to bind to the proper things it exposes.
Actually, I just wanted to understand that on a machine where
shpchp.ko is to be used for hot-plug, can I still use the AER port bus
service driver? My understanding is NO, because shpc will claim the
downstream port bridge, and hence port bus driver will not be able to
claim it?
I think you are correct, at least in principle. Both pcie_portdriver
and shpc_driver try to claim all PCI bridge devices. pcie_portdrv_probe()
succeeds only for PCIe Root Ports, Upstream Ports, and Downstream Ports.
shpc_probe() succeeds only for bridges with the SHPC capability. If
one of them does claim the bridge, the driver core should not call the
other probe method.

So if you have a PCIe Root Port or switch port that has the SHPC
capability, either pcie_portdrv_probe() or shpc_probe() will fail,
depending on which was called first.

I've never seen such a device, so I don't know whether this is a
problem in practice.

Bjorn

Loading...