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

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

[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)?

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

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

[Greg KH]

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.

> 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?

> 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

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

[Rajat Jain]

 Hello,

On Sun, Sep 29, 2013 at 7:05 PM, Greg KH <gregkh@linuxfoundation.org> 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?

>
>> 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?
>
>> 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

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

[Bjorn Helgaas]

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 <gregkh@linuxfoundation.org> 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