public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alex Chiang <achiang@hp.com>
To: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: jbarnes@virtuousgeek.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: pci logical vs. physical hotplug
Date: Tue, 31 Mar 2009 15:00:45 -0600	[thread overview]
Message-ID: <20090331210045.GD16311@ldl.fc.hp.com> (raw)

* Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>:
> I confirmed this patch fix the kernel oops problem I reported.
> 
> Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
> Tested-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>

Thank you for reviewing and testing.

> By the way, /sys/bus/pci/slots/<slot> directory by acpiphp are
> remaining even after the parent bridge/bus of the slots are
> removed. At this point, acpiphp is working with struct pci_bus
> for the already disabled pci bus. I guess some operation against
> the files under /sys/bus/pci/slots/<slot> directory would cause
> something problems. So I think we also need something mechanism
> to unregister acpiphp slots when the parent bus is removed.

Yes, I've been thinking about this (and thank you for your other
mail confirming the issue).

The logical hotplug and physical hotplug don't play very nicely
with each other.

I think one of the core issues is that logical hotplug allows
function level granularity while physical hotplug is naturally
restricted to physical slot granularity, which includes an entire
hierarchy, from host bus down to function.

If a user uses logical hotplug to take out a piece of the tree,
what does that mean if it's part of the physical slot/device?

What should happen?

Take something like this:

[0000:2e-4f]----00.0-[0000:2f-4f]--+-02.0-[0000:30-3f]--+-00.0  Intel GigE
                                   |                    \-00.1  Intel GigE
                                   \-04.0-[0000:40-4f]--+-00.0  Intel GigE
                                                        \-00.1  Intel GigE

Assume that this is a quad-port NIC with a bridge in it, and that
the physical slot is 0000:2e:00.0.

What should we do if the user does a logical hotplug on
0000:2f:04.0 and has acpiphp loaded?

If acpiphp tries to do anything to 0000:40: we'll probably get an
oops.

But just because the user took out one piece of that tree doesn't
mean that we should disable the entire slot. If that was the
case, then he could just use the existing hotplug drivers.

I don't have a good answer for right now, other than, "don't try
to mix logical and physical hotplug". I'm open to any ideas that
you may have.

Thanks.

/ac


             reply	other threads:[~2009-03-31 21:00 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-31 21:00 Alex Chiang [this message]
2009-04-02  1:23 ` pci logical vs. physical hotplug Kenji Kaneshige

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=20090331210045.GD16311@ldl.fc.hp.com \
    --to=achiang@hp.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=kaneshige.kenji@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    /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