From: Bjorn Helgaas <bhelgaas@google.com>
To: Rajat Jain <rajatjain.linux@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
linux-pci@vger.kernel.org, linux-hotplug@vger.kernel.org,
tom.l.nguyen@intel.com, yanmin.zhang@intel.com
Subject: Re: pciehp & other hot-plug drivers (shpc etc..)
Date: Fri, 04 Oct 2013 23:01:18 +0000 [thread overview]
Message-ID: <20131004230118.GB26108@google.com> (raw)
In-Reply-To: <CADTPrLSpfnY6Z1MgpR=C4SRH7yXJ2BKi3w5ChLpTuWL3zZWx_Q@mail.gmail.com>
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
prev parent reply other threads:[~2013-10-04 23:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-29 18:27 pciehp & other hot-plug drivers (shpc etc..) Rajat Jain
2013-09-30 2:05 ` Greg KH
2013-10-04 1:08 ` Rajat Jain
2013-10-04 23:01 ` Bjorn Helgaas [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131004230118.GB26108@google.com \
--to=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-hotplug@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rajatjain.linux@gmail.com \
--cc=tom.l.nguyen@intel.com \
--cc=yanmin.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).