Re: pciehp & other hot-plug drivers (shpc etc..)

On Thu, Oct 03, 2013 at 06:08:15PM -0700, Rajat Jain wrote:
>  Hello,
> 
> On Sun, Sep 29, 2013 at 7:05 PM, Greg KH <[email protected]> wrote:
> > On Sun, Sep 29, 2013 at 11:27:23AM -0700, Rajat Jain wrote:
> >> 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