From: Trent Piepho <xyzzy@speakeasy.org>
To: Alex Chiang <achiang@hp.com>
Cc: jbarnes@virtuousgeek.org, djwong@us.ibm.com,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 00/10] PCI core learns 'hotplug'
Date: Thu, 29 Jan 2009 02:44:42 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.58.0901290221480.17300@shell2.speakeasy.net> (raw)
In-Reply-To: <20090128213814.28003.34634.stgit@bob.kio>
On Wed, 28 Jan 2009, Alex Chiang wrote:
> A while ago, Darrick Wong posted a patch for fakephp that kicked off
> some controversy:
>
> http://thread.gmane.org/gmane.linux.kernel/761944
>
> The issue was that I broke the fakephp interface back in the 2.6.27
> timeframe. After some discussion on the lists, Trent Piepho sent some
> patches, and I proposed a solution incorporating those patches.
>
> This is my first cut at making everyone happy. In summary, it:
>
> - introduces /sys/bus/pci/devices/.../remove for function level
> hot-remove
>
> - introduces /sys/bus/pci/devices/.../rescan to rescan the PCI
> hierarchy, starting at that device and descending to all children
>
> - introduces /sys/bus/pci/rescan to rescan the entire PCI hierarchy
>
> - restores the pre-2.6.27 fakephp interface for userspace compatability
I also continued to work on my patches, but then my reasons for caring
about PCI hotplug disappeared due to the current economic climate.
I updated my "remove" patch to include documentation. I created a patch
that added "/sys/bus/pci/scan", but not the per-device version. And I
updated my new fakephp driver to support rescanning.
Everything worked, but when a bridge was rescanned there would be annoying
warning messages. I never got around to figuring about what to do about
that. It seems like the code that assigns bridge resources wasn't intended
to handle bridges that already had resources assigned to them, though it
does work.
Maybe your series can use my latest patches for removal and legacy_fakephp?
It sounds like your patches for rescanning do more than mine.
> - I've been testing this patchset on my ia64 machines, which Linus
> has called "an insane mess of PCI bridges"[1], and it seems to
> work well. I'm just starting to test on some x86 machines, and
> have been noticing some issues with BAR collisions, so this is
> definitely a work-in-progress.
Does it not work, or is it just warnings? I didn't have any problems with
resources ending up unassigned, but I did get warnings. I think there was
also an issue with removed and rescanned devices' resources' ->parent
pointers not being the same as they were before removal. Which doesn't
seem to matter any, but made me feel like the code wasn't right yet.
> If you use the new PCI core removal/rescan and then try to modify
> the slot using acpiphp, you get an oops. My impression is that
> this behavior is the same as pre-2.6.27, where you could have
> loaded fakephp and acpiphp, removed the device with fakephp,
> and encountered an oops with acpiphp.
I came to the same conclusion. fakephp or acpiphp will oops if you use the
other to remove a pci device. The drivers just aren't designed to handle a
pci device being removed out from under them.
> So, I'm not sure what to do about this. The way that we remove
> devices today, using pci_remove_bus_device() doesn't lend itself
> to safety very well, since it will just start removing devices
> from the bus without checking anything.
>
> Maybe we need some other API, or maybe we just live with the
> limitation of, "if you use PCI core hotplug, don't use the
> other hotplug drivers and vice versa".
My new fakephp driver seems to handle this ok, maybe other php drivers
could do the same thing?
next prev parent reply other threads:[~2009-01-29 10:44 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-28 21:59 Alex Chiang
2009-01-28 21:59 ` [RFC PATCH 01/10] PCI: don't scan existing devices Alex Chiang
2009-01-28 21:59 ` [RFC PATCH 02/10] PCI: always scan child buses Alex Chiang
2009-01-28 21:59 ` [RFC PATCH 03/10] PCI: properly clean up ASPM link state on device remove Alex Chiang
2009-02-05 0:37 ` Jesse Barnes
2009-02-05 1:13 ` Alex Chiang
2009-02-08 21:11 ` [stable] " Greg KH
2009-01-28 21:59 ` [RFC PATCH 04/10] PCI: Introduce /sys/bus/pci/devices/.../remove Alex Chiang
2009-01-28 21:59 ` [RFC PATCH 05/10] PCI: Introduce /sys/bus/pci/rescan Alex Chiang
2009-01-28 21:59 ` [RFC PATCH 06/10] PCI: Introduce /sys/bus/pci/devices/.../rescan Alex Chiang
2009-01-28 21:59 ` [RFC PATCH 07/10] PCI Hotplug: restore fakephp interface with complete reimplementation Alex Chiang
2009-01-28 21:59 ` [RFC PATCH 08/10] PCI Hotplug: rename legacy_fakephp to fakephp Alex Chiang
2009-01-28 21:59 ` [RFC PATCH 09/10] PCI Hotplug: schedule fakephp for feature removal Alex Chiang
2009-01-28 21:59 ` [RFC PATCH 10/10] PCI: more whitespace cleanups Alex Chiang
2009-01-29 10:44 ` Trent Piepho [this message]
2009-01-29 10:55 ` [PATCH 1/3] PCI: Method for removing PCI devices Trent Piepho
2009-02-10 22:24 ` Alex Chiang
2009-01-29 10:55 ` [PATCH 2/3] PCI: Add ability to rescan PCI busses Trent Piepho
2009-02-10 22:30 ` Alex Chiang
2009-01-29 10:55 ` [PATCH 3/3] PCI: Legacy fakephp driver Trent Piepho
2009-02-10 22:21 ` [RFC PATCH 00/10] PCI core learns 'hotplug' Alex Chiang
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=Pine.LNX.4.58.0901290221480.17300@shell2.speakeasy.net \
--to=xyzzy@speakeasy.org \
--cc=achiang@hp.com \
--cc=djwong@us.ibm.com \
--cc=jbarnes@virtuousgeek.org \
--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
all inboxes | Powered by JetHome®