From: Keith Busch <keith.busch@intel.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
Lukas Wunner <lukas@wunner.de>
Subject: Re: [PATCHv4] pcie: Add driver for Downstream Port Containment
Date: Wed, 11 May 2016 13:06:50 -0400 [thread overview]
Message-ID: <20160511170649.GA31047@localhost.localdomain> (raw)
In-Reply-To: <20160511160817.GA24089@localhost>
On Wed, May 11, 2016 at 11:08:17AM -0500, Bjorn Helgaas wrote:
>
> I know I already merged this, but I just thought of a more
> philosophical question. Why is this a "port service driver" as
> opposed to being simply part of the PCI core like ARI, ACS, etc.?
>
> I guess you did make DPC tristate, so from that point of view, it
> probably has to use the driver structure to make it convenient to load
> after boot. Does that add value? Do we expect people to make a
> decision about whether to load pcie-dpc? Or maybe we plan to autoload
> it if the DPC capability is present? Does your patch enable that,
> i.e., does it expose something udev can use to autoload it?
>
> I've been wondering whether the portdrv service driver concept was a
> mistake. With the exception of DPC, I think all the portdrv service
> drivers are bool, so there's no question of having to load a module.
> I think using portdrv means we delay initialization of some things
> that we should do earlier. For example, I think we should setup
> pciehp much earlier, when we enumerate the bridge. And the service
> driver registration and capability discovery code adds a fair amount
> of complication that I'm not sure is necessary.
>
> So I guess the question is: why did you make DPC a portdrv service
> driver, and what bad things would happen if we integrated it into the
> PCI core without exposing it as a separate service.
Good points. I actually hadn't considered making this part of core,
so I don't have all the pros+cons for making this a port services
driver. Mainly, DPC seemed similar to HP and AER since it takes
interrupts, so followed their example. The other optional extended
capabilities you mention don't need interrupts. Since we rely on the
port driver to initialize port's interrupt vectors, DPC has to be a port
services driver in order to safely use these, right?
I made this tristate from vendor request to allow unloading the module;
sounded reasonable at the time, but didn't consider the implications.
I don't think anyone tested it that way, so may have been a mistake. We
don't have the rules for when it needs to load, so it'd have to load
manually at which point it looks too late.
next prev parent reply other threads:[~2016-05-11 17:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-28 22:24 [PATCHv4] pcie: Add driver for Downstream Port Containment Keith Busch
2016-05-02 20:25 ` Bjorn Helgaas
2016-05-06 16:20 ` Bjorn Helgaas
2016-05-06 17:06 ` Keith Busch
2016-05-11 16:08 ` Bjorn Helgaas
2016-05-11 17:06 ` Keith Busch [this message]
2016-05-11 18:28 ` Bjorn Helgaas
2016-05-11 19:55 ` Lukas Wunner
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=20160511170649.GA31047@localhost.localdomain \
--to=keith.busch@intel.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
/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 NNTP newsgroup(s).