Re: [RFC/PATCH]reconfigure MSI registers after resume
On Thu, Sep 01, 2005 at 01:59:32PM -0700, Nguyen, Tom L wrote: > On Thursday, September 01, 2005 1:10 PM Andrew Morton wrote: > > Is it not possible to do this in some single centralized place? > Existing pci_save_state(dev)/pci_restore_state(dev) covers only 64 bytes > of PCI header. One solution is to extend these APIs to cover up to 256 > bytes. What do you think? > No, we can't have these generic functions blindly save/restore device specific parts of the config space (offset 64+). I know of several chipset devices which have read-clear or write-clear bits where reading/writing would have bad side effects. If at all the pci core does this, it needs to explicitly walk the capability list and save/restore the well known capability registers only. Rajesh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH]reconfigure MSI registers after resume
On Thu, Sep 01, 2005 at 01:59:32PM -0700, Nguyen, Tom L wrote: On Thursday, September 01, 2005 1:10 PM Andrew Morton wrote: Is it not possible to do this in some single centralized place? Existing pci_save_state(dev)/pci_restore_state(dev) covers only 64 bytes of PCI header. One solution is to extend these APIs to cover up to 256 bytes. What do you think? No, we can't have these generic functions blindly save/restore device specific parts of the config space (offset 64+). I know of several chipset devices which have read-clear or write-clear bits where reading/writing would have bad side effects. If at all the pci core does this, it needs to explicitly walk the capability list and save/restore the well known capability registers only. Rajesh - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Problem while inserting pciehp (PCI Express Hot-plug) driver
On Sun, Jul 31, 2005 at 12:20:30AM +0800, kylin wrote: > I wonder if i can workaround the MSI using the polling way on the > server geared by E7520 and the firmware with no OSC implemented > Per the PCI firmware spec (I'm looking at draft 0.9, version 3.0), the OS must explicitly get control of native pcie hotplug from firmware using _OSC before trying to use it. Firmware may be deliberately not creating an _OSC because it is controlling the hotplug hardware, or may be aware of other reasons (e.g. errata) why OS native pcie hotplug should not be used on this platform. So no, I don't think we can load and use pciehp if there's no _OSC implemented in firmware. Rajesh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Problem while inserting pciehp (PCI Express Hot-plug) driver
On Sun, Jul 31, 2005 at 12:20:30AM +0800, kylin wrote: I wonder if i can workaround the MSI using the polling way on the server geared by E7520 and the firmware with no OSC implemented Per the PCI firmware spec (I'm looking at draft 0.9, version 3.0), the OS must explicitly get control of native pcie hotplug from firmware using _OSC before trying to use it. Firmware may be deliberately not creating an _OSC because it is controlling the hotplug hardware, or may be aware of other reasons (e.g. errata) why OS native pcie hotplug should not be used on this platform. So no, I don't think we can load and use pciehp if there's no _OSC implemented in firmware. Rajesh - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Problem while inserting pciehp (PCI Express Hot-plug) driver
On Thu, Jul 28, 2005 at 07:45:49PM +0900, Rajat Jain wrote: > > Okay. I'm sorry but I'm not very clear with this. I'm just putting > down here my understanding. So basically we have two mutually > EXCLUSIVE hotplug drivers I can use for PCI Express: > A hotplug slot can be controlled only by a single hotplug technology - pcie shpc or acpiphp. However, different parts of the I/O hierarchy can be controlled by different technologies. For example, a host bridge I/O complex can be hotplugged using acpiphp, but end devices under this IO complex may be hotpplugged using pcie or shpc hotplug. > 1) "pciehp.ko" : We use this PCIE HP driver when our BIOS supports > Native Hot-plug for PCI Express (which means that hot-plug will be > handled by OS single handedly). > > 2) "acpiphp.ko" : We use this "generic" ACPI HP driver when BIOS > allows only ITSELF to handle hot-plug events. > No, acpi hotplug is not handled by BIOS only. Both acpi and pcie hotplug need firmware support as well as hardware support. Hardware in many (but not all) systems support both types of hotplug and its up to the BIOS to decide which type to support. If the platform supports pcie hotplug, you see an _OSC & _SUN methods in the ACPI namespace and the pciehp driver controls hotplug slots. If the system supports acpi hotplug, you see _ADR and _EJ0 methods in the ACPI namespace and the acpiphp driver controls the corresponding hotplug slots. Rajesh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Problem while inserting pciehp (PCI Express Hot-plug) driver
On Thu, Jul 28, 2005 at 07:45:49PM +0900, Rajat Jain wrote: Okay. I'm sorry but I'm not very clear with this. I'm just putting down here my understanding. So basically we have two mutually EXCLUSIVE hotplug drivers I can use for PCI Express: A hotplug slot can be controlled only by a single hotplug technology - pcie shpc or acpiphp. However, different parts of the I/O hierarchy can be controlled by different technologies. For example, a host bridge I/O complex can be hotplugged using acpiphp, but end devices under this IO complex may be hotpplugged using pcie or shpc hotplug. 1) pciehp.ko : We use this PCIE HP driver when our BIOS supports Native Hot-plug for PCI Express (which means that hot-plug will be handled by OS single handedly). 2) acpiphp.ko : We use this generic ACPI HP driver when BIOS allows only ITSELF to handle hot-plug events. No, acpi hotplug is not handled by BIOS only. Both acpi and pcie hotplug need firmware support as well as hardware support. Hardware in many (but not all) systems support both types of hotplug and its up to the BIOS to decide which type to support. If the platform supports pcie hotplug, you see an _OSC _SUN methods in the ACPI namespace and the pciehp driver controls hotplug slots. If the system supports acpi hotplug, you see _ADR and _EJ0 methods in the ACPI namespace and the acpiphp driver controls the corresponding hotplug slots. Rajesh - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hot-addacpi-hotplug-decouple-slot-power-state-changes-from-physical-hotplug.patch
On Sat, Apr 16, 2005 at 11:46:13AM -0700, Paul Ionescu wrote: > > Was this setup supposed to work ? > Not yet, sorry. This patch was simply decoupling the power state of the device from its physical presence in the slot. It had nothing to do about programming p2p bridges and subordinate devices correctly. I know some folks from Fujitsu are working on this and should be sending out patches shortly. Not sure if these will support docking stations fully but even if they don't, we'll have a better starting base to build on. Rajesh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hot-addacpi-hotplug-decouple-slot-power-state-changes-from-physical-hotplug.patch
On Sat, Apr 16, 2005 at 11:46:13AM -0700, Paul Ionescu wrote: Was this setup supposed to work ? Not yet, sorry. This patch was simply decoupling the power state of the device from its physical presence in the slot. It had nothing to do about programming p2p bridges and subordinate devices correctly. I know some folks from Fujitsu are working on this and should be sending out patches shortly. Not sure if these will support docking stations fully but even if they don't, we'll have a better starting base to build on. Rajesh - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pcihpd-discuss] RE: [RFC/Patch 0/12] ACPI based root bridge hot-add
On Wed, Mar 23, 2005 at 03:03:16PM -0800, Tom Duffy wrote:
>
> I have updated to Wilcox's rewrite, Rajesh's stuff, and Dely's latest
> patch. Still seeing these:
>
> [EMAIL PROTECTED] ~]# modprobe acpiphp
> acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> acpiphp: Slot [4] registered
> acpiphp: Slot [3] registered
>
> [EMAIL PROTECTED] ~]# cd /sys/bus/pci/slots/4
>
> [EMAIL PROTECTED] 4]# echo 0 > power
>
> This *does* take this slot off line. Before, I see in lscpi
Note that the current code also attempts to physically eject the
card when you power it off like this.
> After, these are gone.
>
> [EMAIL PROTECTED] 4]# cat power
> 1
>
> Hrm, this should be 0.
>
The code invokes an ACPI _STAtus method to report the power state.
It can get confused if that reports that the device is still
present. The code does keep internal info about the power state
of each slot, but it doesn't use it to report power state.
> [EMAIL PROTECTED] 4]# echo 1 > power
> acpiphp_glue: No new device found
>
If the firmware had a working _EJ0 method for this slot, the
card has been physically ejected.
Does this patch help? It decouples power changes from physical
ejection. With this, you can use the sysfs power control file
to repeatedly power a device on and off. You have to use an
acpi button press to actually physically eject it. Patch
applies on 2.6.12-rc1-mm4 on top of the acpiphp re-write
plus all the other new patches.
---
Current acpiphp code does not distinguish between the physical
presence and power state of a device/slot. That is, if a device
has to be disabled, it also tries to physically ejects the device.
This patch decouples power state from physical presence. You can
now echo to the corresponding sysfs power control file to
repeatedly enable and disable a device without having to
physically re-insert it.
Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---
linux-2.6.12-rc1-mm4-rshah1/drivers/pci/hotplug/acpiphp_glue.c | 69
+-
1 files changed, 38 insertions(+), 31 deletions(-)
diff -puN drivers/pci/hotplug/acpiphp_glue.c~acpiphp-decouple-power-eject
drivers/pci/hotplug/acpiphp_glue.c
---
linux-2.6.12-rc1-mm4/drivers/pci/hotplug/acpiphp_glue.c~acpiphp-decouple-power-eject
2005-03-31 13:10:24.846754032 -0800
+++ linux-2.6.12-rc1-mm4-rshah1/drivers/pci/hotplug/acpiphp_glue.c
2005-03-31 13:12:20.483471366 -0800
@@ -592,8 +592,6 @@ static int power_off_slot(struct acpiphp
acpi_status status;
struct acpiphp_func *func;
struct list_head *l;
- struct acpi_object_list arg_list;
- union acpi_object arg;
int retval = 0;
@@ -615,27 +613,6 @@ static int power_off_slot(struct acpiphp
}
}
- list_for_each (l, >funcs) {
- func = list_entry(l, struct acpiphp_func, sibling);
-
- /* We don't want to call _EJ0 on non-existing functions. */
- if (func->flags & FUNC_HAS_EJ0) {
- /* _EJ0 method take one argument */
- arg_list.count = 1;
- arg_list.pointer =
- arg.type = ACPI_TYPE_INTEGER;
- arg.integer.value = 1;
-
- status = acpi_evaluate_object(func->handle, "_EJ0",
_list, NULL);
- if (ACPI_FAILURE(status)) {
- warn("%s: _EJ0 failed\n", __FUNCTION__);
- retval = -1;
- goto err_exit;
- } else
- break;
- }
- }
-
/* TBD: evaluate _STA to check if the slot is disabled */
slot->flags &= (~SLOT_POWEREDON);
@@ -782,6 +759,39 @@ static unsigned int get_slot_status(stru
}
/**
+ * acpiphp_eject_slot - physically eject the slot
+ */
+static int acpiphp_eject_slot(struct acpiphp_slot *slot)
+{
+ acpi_status status;
+ struct acpiphp_func *func;
+ struct list_head *l;
+ struct acpi_object_list arg_list;
+ union acpi_object arg;
+
+ list_for_each (l, >funcs) {
+ func = list_entry(l, struct acpiphp_func, sibling);
+
+ /* We don't want to call _EJ0 on non-existing functions. */
+ if ((func->flags & FUNC_HAS_EJ0)) {
+ /* _EJ0 method take one argument */
+ arg_list.count = 1;
+ arg_list.pointer =
+ arg.type = ACPI_TYPE_INTEGER;
+ arg.integer.value = 1;
+
+ status = acpi_evaluate_object(func->handle, "_EJ0",
_list, NULL);
+ if (ACPI_FAILURE(status)) {
+ warn("%s: _EJ0 failed\n", __FUNCTION__);
Re: [Pcihpd-discuss] RE: [RFC/Patch 0/12] ACPI based root bridge hot-add
On Wed, Mar 23, 2005 at 03:03:16PM -0800, Tom Duffy wrote:
I have updated to Wilcox's rewrite, Rajesh's stuff, and Dely's latest
patch. Still seeing these:
[EMAIL PROTECTED] ~]# modprobe acpiphp
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
acpiphp: Slot [4] registered
acpiphp: Slot [3] registered
[EMAIL PROTECTED] ~]# cd /sys/bus/pci/slots/4
[EMAIL PROTECTED] 4]# echo 0 power
This *does* take this slot off line. Before, I see in lscpi
Note that the current code also attempts to physically eject the
card when you power it off like this.
After, these are gone.
[EMAIL PROTECTED] 4]# cat power
1
Hrm, this should be 0.
The code invokes an ACPI _STAtus method to report the power state.
It can get confused if that reports that the device is still
present. The code does keep internal info about the power state
of each slot, but it doesn't use it to report power state.
[EMAIL PROTECTED] 4]# echo 1 power
acpiphp_glue: No new device found
If the firmware had a working _EJ0 method for this slot, the
card has been physically ejected.
Does this patch help? It decouples power changes from physical
ejection. With this, you can use the sysfs power control file
to repeatedly power a device on and off. You have to use an
acpi button press to actually physically eject it. Patch
applies on 2.6.12-rc1-mm4 on top of the acpiphp re-write
plus all the other new patches.
---
Current acpiphp code does not distinguish between the physical
presence and power state of a device/slot. That is, if a device
has to be disabled, it also tries to physically ejects the device.
This patch decouples power state from physical presence. You can
now echo to the corresponding sysfs power control file to
repeatedly enable and disable a device without having to
physically re-insert it.
Signed-off-by: Rajesh Shah [EMAIL PROTECTED]
---
linux-2.6.12-rc1-mm4-rshah1/drivers/pci/hotplug/acpiphp_glue.c | 69
+-
1 files changed, 38 insertions(+), 31 deletions(-)
diff -puN drivers/pci/hotplug/acpiphp_glue.c~acpiphp-decouple-power-eject
drivers/pci/hotplug/acpiphp_glue.c
---
linux-2.6.12-rc1-mm4/drivers/pci/hotplug/acpiphp_glue.c~acpiphp-decouple-power-eject
2005-03-31 13:10:24.846754032 -0800
+++ linux-2.6.12-rc1-mm4-rshah1/drivers/pci/hotplug/acpiphp_glue.c
2005-03-31 13:12:20.483471366 -0800
@@ -592,8 +592,6 @@ static int power_off_slot(struct acpiphp
acpi_status status;
struct acpiphp_func *func;
struct list_head *l;
- struct acpi_object_list arg_list;
- union acpi_object arg;
int retval = 0;
@@ -615,27 +613,6 @@ static int power_off_slot(struct acpiphp
}
}
- list_for_each (l, slot-funcs) {
- func = list_entry(l, struct acpiphp_func, sibling);
-
- /* We don't want to call _EJ0 on non-existing functions. */
- if (func-flags FUNC_HAS_EJ0) {
- /* _EJ0 method take one argument */
- arg_list.count = 1;
- arg_list.pointer = arg;
- arg.type = ACPI_TYPE_INTEGER;
- arg.integer.value = 1;
-
- status = acpi_evaluate_object(func-handle, _EJ0,
arg_list, NULL);
- if (ACPI_FAILURE(status)) {
- warn(%s: _EJ0 failed\n, __FUNCTION__);
- retval = -1;
- goto err_exit;
- } else
- break;
- }
- }
-
/* TBD: evaluate _STA to check if the slot is disabled */
slot-flags = (~SLOT_POWEREDON);
@@ -782,6 +759,39 @@ static unsigned int get_slot_status(stru
}
/**
+ * acpiphp_eject_slot - physically eject the slot
+ */
+static int acpiphp_eject_slot(struct acpiphp_slot *slot)
+{
+ acpi_status status;
+ struct acpiphp_func *func;
+ struct list_head *l;
+ struct acpi_object_list arg_list;
+ union acpi_object arg;
+
+ list_for_each (l, slot-funcs) {
+ func = list_entry(l, struct acpiphp_func, sibling);
+
+ /* We don't want to call _EJ0 on non-existing functions. */
+ if ((func-flags FUNC_HAS_EJ0)) {
+ /* _EJ0 method take one argument */
+ arg_list.count = 1;
+ arg_list.pointer = arg;
+ arg.type = ACPI_TYPE_INTEGER;
+ arg.integer.value = 1;
+
+ status = acpi_evaluate_object(func-handle, _EJ0,
arg_list, NULL);
+ if (ACPI_FAILURE(status)) {
+ warn(%s: _EJ0 failed\n, __FUNCTION__);
+ return -1;
+ } else
+ break;
+ }
+ }
+ return 0;
+}
+
+/**
* acpiphp_check_bridge - re-enumerate
Reading root bridge resources
Greg, A while back I had volunteered to write a patch that stores the resource ranges being decoded by root bridges for ACPI based i386 and x86_64 systems. The thread at: http://sourceforge.net/mailarchive/message.php?msg_id=10604487 has some context regarding this. The basic intent was to allow hot-plugged devices sitting directly under a root bridge (versus under a p2p bridge) to claim the correct resources. The current code in pci_scan_bus_parented() simply assigns ioport_resource and iomem_resource to each root bridge, even if it decodes a subset of those resources. I did such a patch recently, and ran into problems while testing it. I made the changes in arch/i386, just like Matthew had done for arch/ia64. I found that ACPI firmware on some systems was not reporting the correct resources in the _CRS method per the ACPI specification. On other systems, there were too many resource ranges to fit in the 4 slots available in the pci_bus structure. Getting an inaccurate picture of root bridge resources broke 2 of my test systems, since some devices failed to claim resources at boot time even though they were otherwise properly configured by BIOS. I am therefore inclined to just drop this patch. This may break hotplug on systems that support hotplug slots directly connected to the root bridge. If a slot is under a p2p bridge, we already read bridge bases correctly so this problem does not affect us. Note however that I was not able to find any such i386 or x86_64 machine anyway. Does somebody have access to such a machine? Any other suggestions? Note that a similar patch went into 2.6.11-mm4'ish for ia64. I haven't heard of any breakage there, so apparently ia64 system firmware is better behaved. Rajesh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Reading root bridge resources
Greg, A while back I had volunteered to write a patch that stores the resource ranges being decoded by root bridges for ACPI based i386 and x86_64 systems. The thread at: http://sourceforge.net/mailarchive/message.php?msg_id=10604487 has some context regarding this. The basic intent was to allow hot-plugged devices sitting directly under a root bridge (versus under a p2p bridge) to claim the correct resources. The current code in pci_scan_bus_parented() simply assigns ioport_resource and iomem_resource to each root bridge, even if it decodes a subset of those resources. I did such a patch recently, and ran into problems while testing it. I made the changes in arch/i386, just like Matthew had done for arch/ia64. I found that ACPI firmware on some systems was not reporting the correct resources in the _CRS method per the ACPI specification. On other systems, there were too many resource ranges to fit in the 4 slots available in the pci_bus structure. Getting an inaccurate picture of root bridge resources broke 2 of my test systems, since some devices failed to claim resources at boot time even though they were otherwise properly configured by BIOS. I am therefore inclined to just drop this patch. This may break hotplug on systems that support hotplug slots directly connected to the root bridge. If a slot is under a p2p bridge, we already read bridge bases correctly so this problem does not affect us. Note however that I was not able to find any such i386 or x86_64 machine anyway. Does somebody have access to such a machine? Any other suggestions? Note that a similar patch went into 2.6.11-mm4'ish for ia64. I haven't heard of any breakage there, so apparently ia64 system firmware is better behaved. Rajesh - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: [RFC/Patch 0/12] ACPI based root bridge hot-add
On Mon, Mar 21, 2005 at 12:34:07PM -0800, Paul Ionescu wrote: > > --- Rajesh Shah <[EMAIL PROTECTED]> wrote: > > > > No. The current patches only trigger when a _root_ bridge is > > hot-added, not a PCI to PCI bridge (which is what the docking > > station is). The code to support p2p bridge hotplug will benefit > > from these patches but more code is needed to support that. > > > > Thanks for the info. > Is p2p hotplug in your roadmap (for i386) ? > Can you please give me an example of a root bridge ? > I believe others are already working on it. I expect to free up a bit more in a couple of weeks. If I don't see any patches or indication of activity by then, I'll work on adding this support too. Rajesh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: [RFC/Patch 0/12] ACPI based root bridge hot-add
On Sat, Mar 19, 2005 at 03:50:16PM +0200, Paul Ionescu wrote: > > Does this mean that when it will be ported for i386, I will be able to > really use my Docking Station ? No. The current patches only trigger when a _root_ bridge is hot-added, not a PCI to PCI bridge (which is what the docking station is). The code to support p2p bridge hotplug will benefit from these patches but more code is needed to support that. > Does it rescan the DSDT to find new additions to ACPI devices ? > It scans the ACPI namespace under the root bridge that was added. Any pci devices underneath are scanned and added, but there isn't any code to look for non-PCI devices there. Rajesh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/Patch 0/12] ACPI based root bridge hot-add
On Fri, Mar 18, 2005 at 09:13:32PM -0800, Greg KH wrote: > > This all looks very good, nice job. I only had one minor comment on the > patches, which I'll reply to directly. > > But I did have a few questions: > - This series relys on Mathew's rewrite of the acpiphp driver. > Is that acceptable? Is that patch necessary for your work? > And if so, can you include it in the whole series? The last patch (12) in the series is the only one that depends on Matthew's acpiphp rewrite. I do have a really old version of my patch that worked with the original acpiphp code base but this version is cleaner. I could probably resurrect my old patch if you want, but I'd rather prefer to work on and fix any other objections you or others may have with Matthew's re-write, since that's the better overall approach. > - Does this break the i386 acpiphp functionality? Dely Sy had tested hotplug with an earlier version of my patches (with minor differences from the current series) on i386 and it worked fine. She probably hasn't tested the latest one. Dely, could you check that please? The i386 hotplug capable box I have doesn't seem to have the right firmware, so I haven't been able to test hotplug on that (I'm working on fixing that). Of course, I tested my patches on i386 (ACPI as well as non-ACPI) and x86_64 machines to make sure I didn't break boot on those. > - Have you tested other pci hotplug systems with this patch > series? Like pci express hotplug, standard pci hotplug, > cardbus, etc? No, because I the one system I have access to isn't doing any hot-plug. I'm working on fixing that but was also hoping to hear from others who surely have access to more machines than I do. > - Are you wanting the acpi specific patches to go into the tree > through the acpi developers? How about the ia64 specific > patches? I honestly don't know what the best approach is here - what do you recommend? I did receive an email from Andrew indicating he wants to pick these up for the next mm. Perhaps the best thing is to let Andrew include the whole series after I've addressed all feedback and you, Tony, Len etc. all agree these are OK to go in. > - Have the acpi developers agreed with your acpi patches? > This is the first time I sent the patches to the acpi list, so I do need to give them a few days to weigh in. Rajesh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/Patch 0/12] ACPI based root bridge hot-add
On Fri, Mar 18, 2005 at 09:13:32PM -0800, Greg KH wrote: This all looks very good, nice job. I only had one minor comment on the patches, which I'll reply to directly. But I did have a few questions: - This series relys on Mathew's rewrite of the acpiphp driver. Is that acceptable? Is that patch necessary for your work? And if so, can you include it in the whole series? The last patch (12) in the series is the only one that depends on Matthew's acpiphp rewrite. I do have a really old version of my patch that worked with the original acpiphp code base but this version is cleaner. I could probably resurrect my old patch if you want, but I'd rather prefer to work on and fix any other objections you or others may have with Matthew's re-write, since that's the better overall approach. - Does this break the i386 acpiphp functionality? Dely Sy had tested hotplug with an earlier version of my patches (with minor differences from the current series) on i386 and it worked fine. She probably hasn't tested the latest one. Dely, could you check that please? The i386 hotplug capable box I have doesn't seem to have the right firmware, so I haven't been able to test hotplug on that (I'm working on fixing that). Of course, I tested my patches on i386 (ACPI as well as non-ACPI) and x86_64 machines to make sure I didn't break boot on those. - Have you tested other pci hotplug systems with this patch series? Like pci express hotplug, standard pci hotplug, cardbus, etc? No, because I the one system I have access to isn't doing any hot-plug. I'm working on fixing that but was also hoping to hear from others who surely have access to more machines than I do. - Are you wanting the acpi specific patches to go into the tree through the acpi developers? How about the ia64 specific patches? I honestly don't know what the best approach is here - what do you recommend? I did receive an email from Andrew indicating he wants to pick these up for the next mm. Perhaps the best thing is to let Andrew include the whole series after I've addressed all feedback and you, Tony, Len etc. all agree these are OK to go in. - Have the acpi developers agreed with your acpi patches? This is the first time I sent the patches to the acpi list, so I do need to give them a few days to weigh in. Rajesh - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: [RFC/Patch 0/12] ACPI based root bridge hot-add
On Sat, Mar 19, 2005 at 03:50:16PM +0200, Paul Ionescu wrote: Does this mean that when it will be ported for i386, I will be able to really use my Docking Station ? No. The current patches only trigger when a _root_ bridge is hot-added, not a PCI to PCI bridge (which is what the docking station is). The code to support p2p bridge hotplug will benefit from these patches but more code is needed to support that. Does it rescan the DSDT to find new additions to ACPI devices ? It scans the ACPI namespace under the root bridge that was added. Any pci devices underneath are scanned and added, but there isn't any code to look for non-PCI devices there. Rajesh - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: [RFC/Patch 0/12] ACPI based root bridge hot-add
On Mon, Mar 21, 2005 at 12:34:07PM -0800, Paul Ionescu wrote: --- Rajesh Shah [EMAIL PROTECTED] wrote: No. The current patches only trigger when a _root_ bridge is hot-added, not a PCI to PCI bridge (which is what the docking station is). The code to support p2p bridge hotplug will benefit from these patches but more code is needed to support that. Thanks for the info. Is p2p hotplug in your roadmap (for i386) ? Can you please give me an example of a root bridge ? I believe others are already working on it. I expect to free up a bit more in a couple of weeks. If I don't see any patches or indication of activity by then, I'll work on adding this support too. Rajesh - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 12/12] ACPI based root bridge hot-add
acpiphp changes to support acpi based root bridge hot-add.
This patch applies on top of the acpiphp re-write patch by
Matthew Wilcox at:
http://marc.theaimsgroup.com/?l=linux-ia64=110616116714938=2
Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---
linux-2.6.11-mm4-iohp-rshah1/drivers/pci/hotplug/acpiphp_glue.c | 211
+-
1 files changed, 202 insertions(+), 9 deletions(-)
diff -puN drivers/pci/hotplug/acpiphp_glue.c~acpiphp_h2p_add
drivers/pci/hotplug/acpiphp_glue.c
--- linux-2.6.11-mm4-iohp/drivers/pci/hotplug/acpiphp_glue.c~acpiphp_h2p_add
2005-03-16 13:37:08.716126010 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/pci/hotplug/acpiphp_glue.c
2005-03-16 13:37:08.825501009 -0800
@@ -6,6 +6,8 @@
* Copyright (C) 2002,2003 NEC Corporation
* Copyright (C) 2003-2005 Matthew Wilcox ([EMAIL PROTECTED])
* Copyright (C) 2003-2005 Hewlett Packard
+ * Copyright (C) 2005 Rajesh Shah ([EMAIL PROTECTED])
+ * Copyright (C) 2005 Intel Corporation
*
* All rights reserved.
*
@@ -304,13 +306,15 @@ static void init_bridge_misc(struct acpi
register_slot, bridge, NULL);
/* install notify handler */
- status = acpi_install_notify_handler(bridge->handle,
+ if (bridge->type != BRIDGE_TYPE_HOST) {
+ status = acpi_install_notify_handler(bridge->handle,
ACPI_SYSTEM_NOTIFY,
handle_hotplug_event_bridge,
bridge);
- if (ACPI_FAILURE(status)) {
- err("failed to register interrupt notify handler\n");
+ if (ACPI_FAILURE(status)) {
+ err("failed to register interrupt notify handler\n");
+ }
}
list_add(>list, _list);
@@ -802,6 +806,143 @@ static int acpiphp_check_bridge(struct a
return retval;
}
+static void program_hpp(struct pci_dev *dev, struct acpiphp_bridge *bridge)
+{
+ u16 pci_cmd, pci_bctl;
+ struct pci_dev *cdev;
+
+ /* Program hpp values for this device */
+ if (!(dev->hdr_type == PCI_HEADER_TYPE_NORMAL ||
+ (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE &&
+ (dev->class >> 8) == PCI_CLASS_BRIDGE_PCI)))
+ return;
+ pci_write_config_byte(dev, PCI_CACHE_LINE_SIZE,
+ bridge->hpp.cache_line_size);
+ pci_write_config_byte(dev, PCI_LATENCY_TIMER,
+ bridge->hpp.latency_timer);
+ pci_read_config_word(dev, PCI_COMMAND, _cmd);
+ if (bridge->hpp.enable_SERR)
+ pci_cmd |= PCI_COMMAND_SERR;
+ else
+ pci_cmd &= ~PCI_COMMAND_SERR;
+ if (bridge->hpp.enable_PERR)
+ pci_cmd |= PCI_COMMAND_PARITY;
+ else
+ pci_cmd &= ~PCI_COMMAND_PARITY;
+ pci_write_config_word(dev, PCI_COMMAND, pci_cmd);
+
+ /* Program bridge control value and child devices */
+ if ((dev->class >> 8) == PCI_CLASS_BRIDGE_PCI) {
+ pci_write_config_byte(dev, PCI_SEC_LATENCY_TIMER,
+ bridge->hpp.latency_timer);
+ pci_read_config_word(dev, PCI_BRIDGE_CONTROL, _bctl);
+ if (bridge->hpp.enable_SERR)
+ pci_bctl |= PCI_BRIDGE_CTL_SERR;
+ else
+ pci_bctl &= ~PCI_BRIDGE_CTL_SERR;
+ if (bridge->hpp.enable_PERR)
+ pci_bctl |= PCI_BRIDGE_CTL_PARITY;
+ else
+ pci_bctl &= ~PCI_BRIDGE_CTL_PARITY;
+ pci_write_config_word(dev, PCI_BRIDGE_CONTROL, pci_bctl);
+ if (dev->subordinate) {
+ list_for_each_entry(cdev, >subordinate->devices,
+ bus_list)
+ program_hpp(cdev, bridge);
+ }
+ }
+}
+
+static void acpiphp_set_hpp_values(acpi_handle handle, struct pci_bus *bus)
+{
+ struct acpiphp_bridge bridge;
+ struct pci_dev *dev;
+
+ memset(, 0, sizeof(bridge));
+ bridge.handle = handle;
+ decode_hpp();
+ list_for_each_entry(dev, >devices, bus_list)
+ program_hpp(dev, );
+
+}
+
+/*
+ * Remove devices for which we could not assign resources, call
+ * arch specific code to fix-up the bus
+ */
+static void acpiphp_sanitize_bus(struct pci_bus *bus)
+{
+ struct pci_dev *dev;
+ int i;
+ unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM;
+
+ list_for_each_entry(dev, >devices, bus_list) {
+ for (i=0; iresource[i];
+ if ((res->flags & type_mask) && !res->start &&
+ res->end) {
+ /* Could
[patch 08/12] Remove hot-plugged devices that could not be allocated resources
When hot-plugging an I/O hierarchy that contains many bridges
and leaf devices, it's possible that there are not enough
resources to start all the device present. If we fail to assign
a resource, clear the corresponding value in the pci_dev structure,
so other code can take corrective action.
Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---
linux-2.6.11-mm4-iohp-rshah1/drivers/pci/setup-bus.c |5 -
1 files changed, 4 insertions(+), 1 deletion(-)
diff -puN drivers/pci/setup-bus.c~discard_no_resource_devs
drivers/pci/setup-bus.c
--- linux-2.6.11-mm4-iohp/drivers/pci/setup-bus.c~discard_no_resource_devs
2005-03-16 13:07:26.557944717 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/pci/setup-bus.c2005-03-16
13:07:26.666343153 -0800
@@ -72,7 +72,10 @@ pbus_assign_resources_sorted(struct pci_
for (list = head.next; list;) {
res = list->res;
idx = res - >dev->resource[0];
- pci_assign_resource(list->dev, idx);
+ if (pci_assign_resource(list->dev, idx)) {
+ res->start = 0;
+ res->flags = 0;
+ }
tmp = list;
list = list->next;
kfree(tmp);
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 10/12] Allow ACPI .add and .start operations to be done independently
Create new interfaces to recursively add an acpi namespace object
to the acpi device list, and recursively start the namespace
object. This is needed for ACPI based hotplug of a root bridge
hierarchy where the add operation must be performed first and
the start operation must be performed separately after the
hot-plugged devices have been properly configured.
Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---
linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/container.c |2
linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/processor_core.c |2
linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/scan.c | 126 ++---
linux-2.6.11-mm4-iohp-rshah1/include/acpi/acpi_bus.h | 17 +
4 files changed, 119 insertions(+), 28 deletions(-)
diff -puN drivers/acpi/scan.c~acpi_separate_device_start drivers/acpi/scan.c
--- linux-2.6.11-mm4-iohp/drivers/acpi/scan.c~acpi_separate_device_start
2005-03-16 13:07:34.326499309 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/scan.c2005-03-16
13:07:34.452475870 -0800
@@ -553,20 +553,29 @@ acpi_bus_driver_init (
* upon possible configuration and currently allocated resources.
*/
+ ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Driver successfully bound to
device\n"));
+ return_VALUE(0);
+}
+
+int
+acpi_start_single_object (
+ struct acpi_device *device)
+{
+ int result = 0;
+ struct acpi_driver *driver;
+
+ ACPI_FUNCTION_TRACE("acpi_start_single_object");
+
+ if (!(driver = device->driver))
+ return_VALUE(0);
+
if (driver->ops.start) {
result = driver->ops.start(device);
if (result && driver->ops.remove)
driver->ops.remove(device, ACPI_BUS_REMOVAL_NORMAL);
- return_VALUE(result);
- }
-
- ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Driver successfully bound to
device\n"));
-
- if (driver->ops.scan) {
- driver->ops.scan(device);
}
- return_VALUE(0);
+ return_VALUE(result);
}
static int acpi_driver_attach(struct acpi_driver * drv)
@@ -586,6 +595,7 @@ static int acpi_driver_attach(struct acp
if (!acpi_bus_match(dev, drv)) {
if (!acpi_bus_driver_init(dev, drv)) {
+ acpi_start_single_object(dev);
atomic_inc(>references);
count++;
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Found driver
[%s] for device [%s]\n",
@@ -1009,8 +1019,8 @@ acpi_bus_remove (
}
-int
-acpi_bus_add (
+static int
+acpi_add_single_object (
struct acpi_device **child,
struct acpi_device *parent,
acpi_handle handle,
@@ -1019,7 +1029,7 @@ acpi_bus_add (
int result = 0;
struct acpi_device *device = NULL;
- ACPI_FUNCTION_TRACE("acpi_bus_add");
+ ACPI_FUNCTION_TRACE("acpi_add_single_object");
if (!child)
return_VALUE(-EINVAL);
@@ -1140,7 +1150,7 @@ acpi_bus_add (
*
* TBD: Assumes LDM provides driver hot-plug capability.
*/
- acpi_bus_find_driver(device);
+ result = acpi_bus_find_driver(device);
end:
if (!result)
@@ -1153,10 +1163,10 @@ end:
return_VALUE(result);
}
-EXPORT_SYMBOL(acpi_bus_add);
-int acpi_bus_scan (struct acpi_device *start)
+static int acpi_bus_scan (struct acpi_device *start,
+ struct acpi_bus_ops *ops)
{
acpi_status status = AE_OK;
struct acpi_device *parent = NULL;
@@ -1229,9 +1239,20 @@ int acpi_bus_scan (struct acpi_device*s
continue;
}
- status = acpi_bus_add(, parent, chandle, type);
- if (ACPI_FAILURE(status))
- continue;
+ if (ops->acpi_op_add)
+ status = acpi_add_single_object(, parent,
+ chandle, type);
+else
+ status = acpi_bus_get_device(chandle, );
+
+if (ACPI_FAILURE(status))
+continue;
+
+ if (ops->acpi_op_start) {
+ status = acpi_start_single_object(child);
+ if (ACPI_FAILURE(status))
+ continue;
+ }
/*
* If the device is present, enabled, and functioning then
@@ -1257,8 +1278,50 @@ int acpi_bus_scan (struct acpi_device*s
return_VALUE(0);
}
-EXPORT_SYMBOL(acpi_bus_scan);
+int
+acpi_bus_add (
+ struct acpi_device **child,
+ struct acpi_device *parent,
+ acpi_handle handle,
+ int type)
+{
+ int
[patch 11/12] Export the interface to get PCI id for an ACPI handle
Export an acpi interface to get PCI domain/bus/devfn information
from the corresponding namespace handle. Used by acpiphp code
to transpate the device handle of the hot-plugged root bridge to
the corresponding pci location information.
Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---
linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/pci_bind.c | 11 +--
linux-2.6.11-mm4-iohp-rshah1/include/acpi/acpi_drivers.h |1 +
2 files changed, 6 insertions(+), 6 deletions(-)
diff -puN drivers/acpi/pci_bind.c~acpi-get-pci-id drivers/acpi/pci_bind.c
--- linux-2.6.11-mm4-iohp/drivers/acpi/pci_bind.c~acpi-get-pci-id
2005-03-16 13:07:39.028647689 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/pci_bind.c2005-03-16
13:07:39.141928937 -0800
@@ -61,15 +61,14 @@ acpi_pci_data_handler (
/**
- * acpi_os_get_pci_id
+ * acpi_get_pci_id
* --
* This function is used by the ACPI Interpreter (a.k.a. Core Subsystem)
* to resolve PCI information for ACPI-PCI devices defined in the namespace.
* This typically occurs when resolving PCI operation region information.
*/
-#ifdef ACPI_FUTURE_USAGE
acpi_status
-acpi_os_get_pci_id (
+acpi_get_pci_id (
acpi_handle handle,
struct acpi_pci_id *id)
{
@@ -78,7 +77,7 @@ acpi_os_get_pci_id (
struct acpi_device *device = NULL;
struct acpi_pci_data*data = NULL;
- ACPI_FUNCTION_TRACE("acpi_os_get_pci_id");
+ ACPI_FUNCTION_TRACE("acpi_get_pci_id");
if (!id)
return_ACPI_STATUS(AE_BAD_PARAMETER);
@@ -92,7 +91,7 @@ acpi_os_get_pci_id (
}
status = acpi_get_data(handle, acpi_pci_data_handler, (void**) );
- if (ACPI_FAILURE(status) || !data || !data->dev) {
+ if (ACPI_FAILURE(status) || !data) {
ACPI_DEBUG_PRINT((ACPI_DB_ERROR,
"Invalid ACPI-PCI context for device %s\n",
acpi_device_bid(device)));
@@ -115,7 +114,7 @@ acpi_os_get_pci_id (
return_ACPI_STATUS(AE_OK);
}
-#endif /* ACPI_FUTURE_USAGE */
+EXPORT_SYMBOL(acpi_get_pci_id);
int
diff -puN include/acpi/acpi_drivers.h~acpi-get-pci-id
include/acpi/acpi_drivers.h
--- linux-2.6.11-mm4-iohp/include/acpi/acpi_drivers.h~acpi-get-pci-id
2005-03-16 13:07:39.033530501 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/include/acpi/acpi_drivers.h2005-03-16
13:07:39.142905500 -0800
@@ -68,6 +68,7 @@ void acpi_pci_irq_del_prt (int segment,
struct pci_bus;
+acpi_status acpi_get_pci_id (acpi_handle handle, struct acpi_pci_id *id);
int acpi_pci_bind (struct acpi_device *device);
int acpi_pci_unbind (struct acpi_device *device);
int acpi_pci_bind_root (struct acpi_device *device, struct acpi_pci_id *id,
struct pci_bus *bus);
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 09/12] Read bridge resources when fixing up the bus
Read bridge io/mem/pfmem ranges when fixing up the bus so that
bus resources are tracked. This is required to properly support
pci end device and bridge hotplug.
Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---
linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c |4
1 files changed, 4 insertions(+)
diff -puN arch/ia64/pci/pci.c~ia64-read_bridge_bases arch/ia64/pci/pci.c
--- linux-2.6.11-mm4-iohp/arch/ia64/pci/pci.c~ia64-read_bridge_bases
2005-03-16 13:07:30.503257168 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c2005-03-16
13:07:30.612632167 -0800
@@ -436,6 +436,10 @@ pcibios_fixup_bus (struct pci_bus *b)
{
struct pci_dev *dev;
+ if (b->self) {
+ pci_read_bridge_bases(b);
+ pcibios_fixup_device_resources(b->self);
+ }
list_for_each_entry(dev, >devices, bus_list)
pcibios_fixup_device_resources(dev);
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 06/12] Link newly created pci child bus to its parent on creation
When a pci child bus is created, add it to the parent's children
list immediately rather than waiting till pci_bus_add_devices().
For hot-plug bridges/devices, pci_bus_add_devices() may be called
much later, after they have been properly configured. In the
meantime, this allows us to use the normal pci bus search functions
for the hot-plug bridges/buses.
Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---
linux-2.6.11-mm4-iohp-rshah1/drivers/pci/bus.c | 11 +++
linux-2.6.11-mm4-iohp-rshah1/drivers/pci/probe.c |4 ++--
2 files changed, 9 insertions(+), 6 deletions(-)
diff -puN drivers/pci/probe.c~pci_link_child_bus drivers/pci/probe.c
--- linux-2.6.11-mm4-iohp/drivers/pci/probe.c~pci_link_child_bus
2005-03-16 13:07:18.745444812 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/pci/probe.c2005-03-16
13:07:18.857749498 -0800
@@ -457,7 +457,7 @@ int __devinit pci_scan_bridge(struct pci
return max;
}
- child = pci_alloc_child_bus(bus, dev, busnr);
+ child = pci_add_new_bus(bus, dev, busnr);
if (!child)
return max;
child->primary = buses & 0xFF;
@@ -484,7 +484,7 @@ int __devinit pci_scan_bridge(struct pci
* This can happen when a bridge is hot-plugged */
if (pci_find_bus(pci_domain_nr(bus), max+1))
return max;
- child = pci_alloc_child_bus(bus, dev, ++max);
+ child = pci_add_new_bus(bus, dev, ++max);
buses = (buses & 0xff00)
| ((unsigned int)(child->primary) << 0)
| ((unsigned int)(child->secondary) << 8)
diff -puN drivers/pci/bus.c~pci_link_child_bus drivers/pci/bus.c
--- linux-2.6.11-mm4-iohp/drivers/pci/bus.c~pci_link_child_bus 2005-03-16
13:07:18.749351062 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/pci/bus.c 2005-03-16
13:07:18.858726061 -0800
@@ -121,10 +121,13 @@ void __devinit pci_bus_add_devices(struc
* If there is an unattached subordinate bus, attach
* it and then scan for unattached PCI devices.
*/
- if (dev->subordinate && list_empty(>subordinate->node)) {
- spin_lock(_bus_lock);
- list_add_tail(>subordinate->node,
>bus->children);
- spin_unlock(_bus_lock);
+ if (dev->subordinate) {
+ if (list_empty(>subordinate->node)) {
+ spin_lock(_bus_lock);
+ list_add_tail(>subordinate->node,
+ >bus->children);
+ spin_unlock(_bus_lock);
+ }
pci_bus_add_devices(dev->subordinate);
sysfs_create_link(>subordinate->class_dev.kobj,
>dev.kobj, "bridge");
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 07/12] Make the PCI remove routines safe for failed hot-plug
When a root bridge hierarchy is hot-plugged, resource requirements
for the new devices may be greater than what the root bridge is
decoding. In this case, we want to remove devices that did not
get needed resources. These devices have been scanned into bus
specific lists but not yet added to the global device list.
Make sure the pci remove functions can handle this case.
Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---
linux-2.6.11-mm4-iohp-rshah1/drivers/pci/remove.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff -puN drivers/pci/remove.c~pci-remove-device-hotplug-safe
drivers/pci/remove.c
--- linux-2.6.11-mm4-iohp/drivers/pci/remove.c~pci-remove-device-hotplug-safe
2005-03-16 13:07:22.667319764 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/pci/remove.c 2005-03-16
13:07:22.775718200 -0800
@@ -26,17 +26,21 @@ static void pci_free_resources(struct pc
static void pci_destroy_dev(struct pci_dev *dev)
{
- pci_proc_detach_device(dev);
- pci_remove_sysfs_dev_files(dev);
- device_unregister(>dev);
+ if (!list_empty(>global_list)) {
+ pci_proc_detach_device(dev);
+ pci_remove_sysfs_dev_files(dev);
+ device_unregister(>dev);
+ spin_lock(_bus_lock);
+ list_del(>global_list);
+ dev->global_list.next = dev->global_list.prev = NULL;
+ spin_unlock(_bus_lock);
+ }
/* Remove the device from the device lists, and prevent any further
* list accesses from this device */
spin_lock(_bus_lock);
list_del(>bus_list);
- list_del(>global_list);
dev->bus_list.next = dev->bus_list.prev = NULL;
- dev->global_list.next = dev->global_list.prev = NULL;
spin_unlock(_bus_lock);
pci_free_resources(dev);
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 05/12] Take the PCI lock when modifying pci bus or device lists
With root bridge and pci bridge hot-plug, new buses and devices
can be added or removed at run time. Protect the pci bus and
device lists with the pci lock when doing so.
Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---
linux-2.6.11-mm4-iohp-rshah1/drivers/pci/probe.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletion(-)
diff -puN drivers/pci/probe.c~lock-pci-root-bus-add drivers/pci/probe.c
--- linux-2.6.11-mm4-iohp/drivers/pci/probe.c~lock-pci-root-bus-add
2005-03-16 13:07:14.694663612 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/pci/probe.c2005-03-16
13:07:14.802085486 -0800
@@ -8,6 +8,7 @@
#include
#include
#include
+#include "pci.h"
#undef DEBUG
@@ -380,8 +381,11 @@ struct pci_bus * __devinit pci_add_new_b
struct pci_bus *child;
child = pci_alloc_child_bus(parent, dev, busnr);
- if (child)
+ if (child) {
+ spin_lock(_bus_lock);
list_add_tail(>node, >children);
+ spin_unlock(_bus_lock);
+ }
return child;
}
@@ -771,7 +775,9 @@ pci_scan_single_device(struct pci_bus *b
* and the bus list for fixup functions, etc.
*/
INIT_LIST_HEAD(>global_list);
+ spin_lock(_bus_lock);
list_add_tail(>bus_list, >devices);
+ spin_unlock(_bus_lock);
return dev;
}
@@ -891,7 +897,9 @@ struct pci_bus * __devinit pci_scan_bus_
DBG("PCI: Bus %04x:%02x already known\n", pci_domain_nr(b),
bus);
goto err_out;
}
+ spin_lock(_bus_lock);
list_add_tail(>node, _root_buses);
+ spin_unlock(_bus_lock);
memset(dev, 0, sizeof(*dev));
dev->parent = parent;
@@ -933,7 +941,9 @@ class_dev_create_file_err:
class_dev_reg_err:
device_unregister(dev);
dev_reg_err:
+ spin_lock(_bus_lock);
list_del(>node);
+ spin_unlock(_bus_lock);
err_out:
kfree(dev);
kfree(b);
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 04/12] Prevent duplicate bus numbers when scanning PCI bridge
When hot-plugging a root bridge, as we try to assign bus numbers
we may find that the hotplugged hieratchy has more PCI to PCI
bridges (i.e. bus requirements) than available. Make sure we
don't step over an existing bus when that happens.
Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---
linux-2.6.11-mm4-iohp-rshah1/drivers/pci/probe.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff -puN drivers/pci/probe.c~prevent_duplicate_busnr drivers/pci/probe.c
--- linux-2.6.11-mm4-iohp/drivers/pci/probe.c~prevent_duplicate_busnr
2005-03-16 13:07:10.376304290 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/pci/probe.c2005-03-16
13:07:10.496421476 -0800
@@ -417,7 +417,7 @@ int __devinit pci_scan_bridge(struct pci
{
struct pci_bus *child;
int is_cardbus = (dev->hdr_type == PCI_HEADER_TYPE_CARDBUS);
- u32 buses;
+ u32 buses, i;
u16 bctl;
pci_read_config_dword(dev, PCI_PRIMARY_BUS, );
@@ -476,6 +476,10 @@ int __devinit pci_scan_bridge(struct pci
/* Clear errors */
pci_write_config_word(dev, PCI_STATUS, 0x);
+ /* Prevent assigning a bus number that already exists.
+* This can happen when a bridge is hot-plugged */
+ if (pci_find_bus(pci_domain_nr(bus), max+1))
+ return max;
child = pci_alloc_child_bus(bus, dev, ++max);
buses = (buses & 0xff00)
| ((unsigned int)(child->primary) << 0)
@@ -507,7 +511,11 @@ int __devinit pci_scan_bridge(struct pci
* as cards with a PCI-to-PCI bridge can be
* inserted later.
*/
- max += CARDBUS_RESERVE_BUSNR;
+ for (i=0; ihttp://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 03/12] Make pcibios_fixup_bus() hot-plug safe
PCI scan code calls the arch specific pcibios_fixup_bus() each
time it scans a new bridge. For root bridge hot-plug, the bridge
and it's attached devices may not have been configured properly
yet, so it's not safe to claim those resources at this time.
This code goes away when we clean up the way pci resources are
claimed (in pci_enable_device()), so this is only a stopgap fix.
Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---
linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c | 22 +-
1 files changed, 21 insertions(+), 1 deletion(-)
diff -puN arch/ia64/pci/pci.c~ia64-pcibios_fixup_bus-hotplug-safe
arch/ia64/pci/pci.c
---
linux-2.6.11-mm4-iohp/arch/ia64/pci/pci.c~ia64-pcibios_fixup_bus-hotplug-safe
2005-03-16 13:07:06.343101214 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c2005-03-16
13:07:06.450523088 -0800
@@ -391,6 +391,25 @@ void pcibios_bus_to_resource(struct pci_
res->end = region->end + offset;
}
+static int __devinit is_valid_resource(struct pci_dev *dev, int idx)
+{
+ unsigned int i, type_mask = IORESOURCE_IO | IORESOURCE_MEM;
+ struct resource *devr = >resource[idx];
+
+ if (!dev->bus)
+ return 0;
+ for (i=0; ibus->resource[i];
+
+ if (!busr || ((busr->flags ^ devr->flags) & type_mask))
+ continue;
+ if ((devr->start) && (devr->start >= busr->start) &&
+ (devr->end <= busr->end))
+ return 1;
+ }
+ return 0;
+}
+
static void __devinit pcibios_fixup_device_resources(struct pci_dev *dev)
{
struct pci_bus_region region;
@@ -404,7 +423,8 @@ static void __devinit pcibios_fixup_devi
region.start = dev->resource[i].start;
region.end = dev->resource[i].end;
pcibios_bus_to_resource(dev, >resource[i], );
- pci_claim_resource(dev, i);
+ if ((is_valid_resource(dev, i)))
+ pci_claim_resource(dev, i);
}
}
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch 2/12] Fix pci_enable_device() for p2p bridges
When checking if a PCI to PCI bridge should be enabled to decode
memory and/or IO resources, we need to look at all device
resources not just the first 6. This is needed to allow PCI
bridges to pass down memory and IO accesses to child devices
even when the bridge itself does not consume resources in its
PCI BARs.
Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---
linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff -puN arch/ia64/pci/pci.c~fix-ia64-pcibios_enable_resources
arch/ia64/pci/pci.c
--- linux-2.6.11-mm4-iohp/arch/ia64/pci/pci.c~fix-ia64-pcibios_enable_resources
2005-03-16 13:07:02.055015329 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c2005-03-16
13:07:02.164390328 -0800
@@ -436,18 +436,24 @@ pcibios_enable_resources (struct pci_dev
u16 cmd, old_cmd;
int idx;
struct resource *r;
+ unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM;
if (!dev)
return -EINVAL;
pci_read_config_word(dev, PCI_COMMAND, );
old_cmd = cmd;
- for (idx=0; idx<6; idx++) {
+ for (idx=0; idxresource[idx];
+ if (!(r->flags & type_mask))
+ continue;
+ if ((idx == PCI_ROM_RESOURCE) &&
+ (!(r->flags & IORESOURCE_ROM_ENABLE)))
+ continue;
if (!r->start && r->end) {
printk(KERN_ERR
"PCI: Device %s not available because of
resource collisions\n",
@@ -459,8 +465,6 @@ pcibios_enable_resources (struct pci_dev
if (r->flags & IORESOURCE_MEM)
cmd |= PCI_COMMAND_MEMORY;
}
- if (dev->resource[PCI_ROM_RESOURCE].start)
- cmd |= PCI_COMMAND_MEMORY;
if (cmd != old_cmd) {
printk("PCI: Enabling device %s (%04x -> %04x)\n",
pci_name(dev), old_cmd, cmd);
pci_write_config_word(dev, PCI_COMMAND, cmd);
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch 1/12] ACPI based root bridge hot-add
When you hot-plug a (root) bridge hierarchy, it may have p2p
bridges and devices attached to it that have not been configured
by firmware. In this case, we need to configure the devices
before starting them. This patch separates device start from
device scan so that we can introduce the configuration step in
the middle.
I kept the existing semantics for pci_scan_bus() since there
are a huge number of callers to that function.
Also, I have no way of testing the changes I made to the parisc
files, so this needs review by those folks. Sorry for the massive
cross-post, this touches files in many different places.
Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---
linux-2.6.11-mm4-iohp-rshah1/arch/i386/pci/common.c |2 -
linux-2.6.11-mm4-iohp-rshah1/arch/i386/pci/legacy.c |2 +
linux-2.6.11-mm4-iohp-rshah1/arch/i386/pci/numa.c |2 +
linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c |2 -
linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/pci_bind.c | 16 +++-
linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/pci_root.c | 24 +-
linux-2.6.11-mm4-iohp-rshah1/drivers/parisc/dino.c|1
linux-2.6.11-mm4-iohp-rshah1/drivers/parisc/lba_pci.c |2 +
linux-2.6.11-mm4-iohp-rshah1/drivers/pci/probe.c |2 -
linux-2.6.11-mm4-iohp-rshah1/include/linux/pci.h |8 --
10 files changed, 53 insertions(+), 8 deletions(-)
diff -puN arch/i386/pci/common.c~pci_serparate_device_add arch/i386/pci/common.c
--- linux-2.6.11-mm4-iohp/arch/i386/pci/common.c~pci_serparate_device_add
2005-03-16 13:06:53.259117000 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/arch/i386/pci/common.c 2005-03-16
13:06:53.419273248 -0800
@@ -133,7 +133,7 @@ struct pci_bus * __devinit pcibios_scan_
printk("PCI: Probing PCI hardware (bus %02x)\n", busnum);
- return pci_scan_bus(busnum, _root_ops, NULL);
+ return pci_scan_bus_parented(NULL, busnum, _root_ops, NULL);
}
extern u8 pci_cache_line_size;
diff -puN arch/i386/pci/legacy.c~pci_serparate_device_add arch/i386/pci/legacy.c
--- linux-2.6.11-mm4-iohp/arch/i386/pci/legacy.c~pci_serparate_device_add
2005-03-16 13:06:53.263999812 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/arch/i386/pci/legacy.c 2005-03-16
13:06:53.420249810 -0800
@@ -45,6 +45,8 @@ static int __init pci_legacy_init(void)
printk("PCI: Probing PCI hardware\n");
pci_root_bus = pcibios_scan_root(0);
+ if (pci_root_bus)
+ pci_bus_add_devices(pci_root_bus);
pcibios_fixup_peer_bridges();
diff -puN arch/i386/pci/numa.c~pci_serparate_device_add arch/i386/pci/numa.c
--- linux-2.6.11-mm4-iohp/arch/i386/pci/numa.c~pci_serparate_device_add
2005-03-16 13:06:53.267906062 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/arch/i386/pci/numa.c 2005-03-16
13:06:53.421226373 -0800
@@ -115,6 +115,8 @@ static int __init pci_numa_init(void)
return 0;
pci_root_bus = pcibios_scan_root(0);
+ if (pci_root_bus)
+ pci_bus_add_devices(pci_root_bus);
if (num_online_nodes() > 1)
for_each_online_node(quad) {
if (quad == 0)
diff -puN arch/ia64/pci/pci.c~pci_serparate_device_add arch/ia64/pci/pci.c
--- linux-2.6.11-mm4-iohp/arch/ia64/pci/pci.c~pci_serparate_device_add
2005-03-16 13:06:53.272788874 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c2005-03-16
13:06:53.430991997 -0800
@@ -330,7 +330,7 @@ pci_acpi_scan_root(struct acpi_device *d
acpi_walk_resources(device->handle, METHOD_NAME__CRS, add_window,
);
- pbus = pci_scan_bus(bus, _root_ops, controller);
+ pbus = pci_scan_bus_parented(NULL, bus, _root_ops, controller);
if (pbus)
pcibios_setup_root_windows(pbus, controller);
diff -puN drivers/acpi/pci_bind.c~pci_serparate_device_add
drivers/acpi/pci_bind.c
--- linux-2.6.11-mm4-iohp/drivers/acpi/pci_bind.c~pci_serparate_device_add
2005-03-16 13:06:53.276695124 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/pci_bind.c2005-03-16
13:06:53.431968560 -0800
@@ -129,6 +129,8 @@ acpi_pci_bind (
char*pathname = NULL;
struct acpi_buffer buffer = {0, NULL};
acpi_handle handle = NULL;
+ struct pci_dev *dev;
+ struct pci_bus *bus;
ACPI_FUNCTION_TRACE("acpi_pci_bind");
@@ -193,8 +195,20 @@ acpi_pci_bind (
* Locate matching device in PCI namespace. If it doesn't exist
* this typically means that the device isn't currently inserted
* (e.g. docking station, port replicator, etc.).
+* We cannot simply search the global pci device list, since
+* PCI devices are added to the global pci list when the root
+* bridge start ops are run, which may not have happened yet.
*/
- data->dev = pci_find_slot(data->id.bus, PCI_DEVFN(da
[RFC/Patch 0/12] ACPI based root bridge hot-add
Here is a series of patches to support ACPI hot-add of a root bridge hierarchy. The added hierarchy may contain other p2p bridges and end/leaf I/O devices too. The root bridge itself is assumed to have been assigned resource ranges, but the p2p bridges and end devices are not required to be initialized by firmware. Most of the code changes are to make the existing code flows suitable for such a hierarchy of bridges & devices. This code supports hot-add on ia64 only for now.It does not yet support I/O APIC hot-add, which is needed to make this fully functional. The patches are against 2.6.11-mm4 (plus the patch needed for ia64 to boot). I've tested to make sure this does not break end/leaf device hotplug on the hotplug capable ia64 box I have. Thanks, Rajesh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC/Patch 0/12] ACPI based root bridge hot-add
Here is a series of patches to support ACPI hot-add of a root bridge hierarchy. The added hierarchy may contain other p2p bridges and end/leaf I/O devices too. The root bridge itself is assumed to have been assigned resource ranges, but the p2p bridges and end devices are not required to be initialized by firmware. Most of the code changes are to make the existing code flows suitable for such a hierarchy of bridges devices. This code supports hot-add on ia64 only for now.It does not yet support I/O APIC hot-add, which is needed to make this fully functional. The patches are against 2.6.11-mm4 (plus the patch needed for ia64 to boot). I've tested to make sure this does not break end/leaf device hotplug on the hotplug capable ia64 box I have. Thanks, Rajesh - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch 1/12] ACPI based root bridge hot-add
When you hot-plug a (root) bridge hierarchy, it may have p2p
bridges and devices attached to it that have not been configured
by firmware. In this case, we need to configure the devices
before starting them. This patch separates device start from
device scan so that we can introduce the configuration step in
the middle.
I kept the existing semantics for pci_scan_bus() since there
are a huge number of callers to that function.
Also, I have no way of testing the changes I made to the parisc
files, so this needs review by those folks. Sorry for the massive
cross-post, this touches files in many different places.
Signed-off-by: Rajesh Shah [EMAIL PROTECTED]
---
linux-2.6.11-mm4-iohp-rshah1/arch/i386/pci/common.c |2 -
linux-2.6.11-mm4-iohp-rshah1/arch/i386/pci/legacy.c |2 +
linux-2.6.11-mm4-iohp-rshah1/arch/i386/pci/numa.c |2 +
linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c |2 -
linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/pci_bind.c | 16 +++-
linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/pci_root.c | 24 +-
linux-2.6.11-mm4-iohp-rshah1/drivers/parisc/dino.c|1
linux-2.6.11-mm4-iohp-rshah1/drivers/parisc/lba_pci.c |2 +
linux-2.6.11-mm4-iohp-rshah1/drivers/pci/probe.c |2 -
linux-2.6.11-mm4-iohp-rshah1/include/linux/pci.h |8 --
10 files changed, 53 insertions(+), 8 deletions(-)
diff -puN arch/i386/pci/common.c~pci_serparate_device_add arch/i386/pci/common.c
--- linux-2.6.11-mm4-iohp/arch/i386/pci/common.c~pci_serparate_device_add
2005-03-16 13:06:53.259117000 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/arch/i386/pci/common.c 2005-03-16
13:06:53.419273248 -0800
@@ -133,7 +133,7 @@ struct pci_bus * __devinit pcibios_scan_
printk(PCI: Probing PCI hardware (bus %02x)\n, busnum);
- return pci_scan_bus(busnum, pci_root_ops, NULL);
+ return pci_scan_bus_parented(NULL, busnum, pci_root_ops, NULL);
}
extern u8 pci_cache_line_size;
diff -puN arch/i386/pci/legacy.c~pci_serparate_device_add arch/i386/pci/legacy.c
--- linux-2.6.11-mm4-iohp/arch/i386/pci/legacy.c~pci_serparate_device_add
2005-03-16 13:06:53.263999812 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/arch/i386/pci/legacy.c 2005-03-16
13:06:53.420249810 -0800
@@ -45,6 +45,8 @@ static int __init pci_legacy_init(void)
printk(PCI: Probing PCI hardware\n);
pci_root_bus = pcibios_scan_root(0);
+ if (pci_root_bus)
+ pci_bus_add_devices(pci_root_bus);
pcibios_fixup_peer_bridges();
diff -puN arch/i386/pci/numa.c~pci_serparate_device_add arch/i386/pci/numa.c
--- linux-2.6.11-mm4-iohp/arch/i386/pci/numa.c~pci_serparate_device_add
2005-03-16 13:06:53.267906062 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/arch/i386/pci/numa.c 2005-03-16
13:06:53.421226373 -0800
@@ -115,6 +115,8 @@ static int __init pci_numa_init(void)
return 0;
pci_root_bus = pcibios_scan_root(0);
+ if (pci_root_bus)
+ pci_bus_add_devices(pci_root_bus);
if (num_online_nodes() 1)
for_each_online_node(quad) {
if (quad == 0)
diff -puN arch/ia64/pci/pci.c~pci_serparate_device_add arch/ia64/pci/pci.c
--- linux-2.6.11-mm4-iohp/arch/ia64/pci/pci.c~pci_serparate_device_add
2005-03-16 13:06:53.272788874 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c2005-03-16
13:06:53.430991997 -0800
@@ -330,7 +330,7 @@ pci_acpi_scan_root(struct acpi_device *d
acpi_walk_resources(device-handle, METHOD_NAME__CRS, add_window,
info);
- pbus = pci_scan_bus(bus, pci_root_ops, controller);
+ pbus = pci_scan_bus_parented(NULL, bus, pci_root_ops, controller);
if (pbus)
pcibios_setup_root_windows(pbus, controller);
diff -puN drivers/acpi/pci_bind.c~pci_serparate_device_add
drivers/acpi/pci_bind.c
--- linux-2.6.11-mm4-iohp/drivers/acpi/pci_bind.c~pci_serparate_device_add
2005-03-16 13:06:53.276695124 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/pci_bind.c2005-03-16
13:06:53.431968560 -0800
@@ -129,6 +129,8 @@ acpi_pci_bind (
char*pathname = NULL;
struct acpi_buffer buffer = {0, NULL};
acpi_handle handle = NULL;
+ struct pci_dev *dev;
+ struct pci_bus *bus;
ACPI_FUNCTION_TRACE(acpi_pci_bind);
@@ -193,8 +195,20 @@ acpi_pci_bind (
* Locate matching device in PCI namespace. If it doesn't exist
* this typically means that the device isn't currently inserted
* (e.g. docking station, port replicator, etc.).
+* We cannot simply search the global pci device list, since
+* PCI devices are added to the global pci list when the root
+* bridge start ops are run, which may not have happened yet.
*/
- data-dev = pci_find_slot(data-id.bus, PCI_DEVFN(data-id.device,
data-id.function));
+ bus
[Patch 2/12] Fix pci_enable_device() for p2p bridges
When checking if a PCI to PCI bridge should be enabled to decode
memory and/or IO resources, we need to look at all device
resources not just the first 6. This is needed to allow PCI
bridges to pass down memory and IO accesses to child devices
even when the bridge itself does not consume resources in its
PCI BARs.
Signed-off-by: Rajesh Shah [EMAIL PROTECTED]
---
linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff -puN arch/ia64/pci/pci.c~fix-ia64-pcibios_enable_resources
arch/ia64/pci/pci.c
--- linux-2.6.11-mm4-iohp/arch/ia64/pci/pci.c~fix-ia64-pcibios_enable_resources
2005-03-16 13:07:02.055015329 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c2005-03-16
13:07:02.164390328 -0800
@@ -436,18 +436,24 @@ pcibios_enable_resources (struct pci_dev
u16 cmd, old_cmd;
int idx;
struct resource *r;
+ unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM;
if (!dev)
return -EINVAL;
pci_read_config_word(dev, PCI_COMMAND, cmd);
old_cmd = cmd;
- for (idx=0; idx6; idx++) {
+ for (idx=0; idxPCI_NUM_RESOURCES; idx++) {
/* Only set up the desired resources. */
if (!(mask (1 idx)))
continue;
r = dev-resource[idx];
+ if (!(r-flags type_mask))
+ continue;
+ if ((idx == PCI_ROM_RESOURCE)
+ (!(r-flags IORESOURCE_ROM_ENABLE)))
+ continue;
if (!r-start r-end) {
printk(KERN_ERR
PCI: Device %s not available because of
resource collisions\n,
@@ -459,8 +465,6 @@ pcibios_enable_resources (struct pci_dev
if (r-flags IORESOURCE_MEM)
cmd |= PCI_COMMAND_MEMORY;
}
- if (dev-resource[PCI_ROM_RESOURCE].start)
- cmd |= PCI_COMMAND_MEMORY;
if (cmd != old_cmd) {
printk(PCI: Enabling device %s (%04x - %04x)\n,
pci_name(dev), old_cmd, cmd);
pci_write_config_word(dev, PCI_COMMAND, cmd);
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 03/12] Make pcibios_fixup_bus() hot-plug safe
PCI scan code calls the arch specific pcibios_fixup_bus() each
time it scans a new bridge. For root bridge hot-plug, the bridge
and it's attached devices may not have been configured properly
yet, so it's not safe to claim those resources at this time.
This code goes away when we clean up the way pci resources are
claimed (in pci_enable_device()), so this is only a stopgap fix.
Signed-off-by: Rajesh Shah [EMAIL PROTECTED]
---
linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c | 22 +-
1 files changed, 21 insertions(+), 1 deletion(-)
diff -puN arch/ia64/pci/pci.c~ia64-pcibios_fixup_bus-hotplug-safe
arch/ia64/pci/pci.c
---
linux-2.6.11-mm4-iohp/arch/ia64/pci/pci.c~ia64-pcibios_fixup_bus-hotplug-safe
2005-03-16 13:07:06.343101214 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c2005-03-16
13:07:06.450523088 -0800
@@ -391,6 +391,25 @@ void pcibios_bus_to_resource(struct pci_
res-end = region-end + offset;
}
+static int __devinit is_valid_resource(struct pci_dev *dev, int idx)
+{
+ unsigned int i, type_mask = IORESOURCE_IO | IORESOURCE_MEM;
+ struct resource *devr = dev-resource[idx];
+
+ if (!dev-bus)
+ return 0;
+ for (i=0; iPCI_BUS_NUM_RESOURCES; i++) {
+ struct resource *busr = dev-bus-resource[i];
+
+ if (!busr || ((busr-flags ^ devr-flags) type_mask))
+ continue;
+ if ((devr-start) (devr-start = busr-start)
+ (devr-end = busr-end))
+ return 1;
+ }
+ return 0;
+}
+
static void __devinit pcibios_fixup_device_resources(struct pci_dev *dev)
{
struct pci_bus_region region;
@@ -404,7 +423,8 @@ static void __devinit pcibios_fixup_devi
region.start = dev-resource[i].start;
region.end = dev-resource[i].end;
pcibios_bus_to_resource(dev, dev-resource[i], region);
- pci_claim_resource(dev, i);
+ if ((is_valid_resource(dev, i)))
+ pci_claim_resource(dev, i);
}
}
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 04/12] Prevent duplicate bus numbers when scanning PCI bridge
When hot-plugging a root bridge, as we try to assign bus numbers
we may find that the hotplugged hieratchy has more PCI to PCI
bridges (i.e. bus requirements) than available. Make sure we
don't step over an existing bus when that happens.
Signed-off-by: Rajesh Shah [EMAIL PROTECTED]
---
linux-2.6.11-mm4-iohp-rshah1/drivers/pci/probe.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff -puN drivers/pci/probe.c~prevent_duplicate_busnr drivers/pci/probe.c
--- linux-2.6.11-mm4-iohp/drivers/pci/probe.c~prevent_duplicate_busnr
2005-03-16 13:07:10.376304290 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/pci/probe.c2005-03-16
13:07:10.496421476 -0800
@@ -417,7 +417,7 @@ int __devinit pci_scan_bridge(struct pci
{
struct pci_bus *child;
int is_cardbus = (dev-hdr_type == PCI_HEADER_TYPE_CARDBUS);
- u32 buses;
+ u32 buses, i;
u16 bctl;
pci_read_config_dword(dev, PCI_PRIMARY_BUS, buses);
@@ -476,6 +476,10 @@ int __devinit pci_scan_bridge(struct pci
/* Clear errors */
pci_write_config_word(dev, PCI_STATUS, 0x);
+ /* Prevent assigning a bus number that already exists.
+* This can happen when a bridge is hot-plugged */
+ if (pci_find_bus(pci_domain_nr(bus), max+1))
+ return max;
child = pci_alloc_child_bus(bus, dev, ++max);
buses = (buses 0xff00)
| ((unsigned int)(child-primary) 0)
@@ -507,7 +511,11 @@ int __devinit pci_scan_bridge(struct pci
* as cards with a PCI-to-PCI bridge can be
* inserted later.
*/
- max += CARDBUS_RESERVE_BUSNR;
+ for (i=0; iCARDBUS_RESERVE_BUSNR; i++)
+ if (pci_find_bus(pci_domain_nr(bus),
+ max+i+1))
+ break;
+ max += i;
}
/*
* Set the subordinate bus number to its real value.
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 05/12] Take the PCI lock when modifying pci bus or device lists
With root bridge and pci bridge hot-plug, new buses and devices
can be added or removed at run time. Protect the pci bus and
device lists with the pci lock when doing so.
Signed-off-by: Rajesh Shah [EMAIL PROTECTED]
---
linux-2.6.11-mm4-iohp-rshah1/drivers/pci/probe.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletion(-)
diff -puN drivers/pci/probe.c~lock-pci-root-bus-add drivers/pci/probe.c
--- linux-2.6.11-mm4-iohp/drivers/pci/probe.c~lock-pci-root-bus-add
2005-03-16 13:07:14.694663612 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/pci/probe.c2005-03-16
13:07:14.802085486 -0800
@@ -8,6 +8,7 @@
#include linux/slab.h
#include linux/module.h
#include linux/cpumask.h
+#include pci.h
#undef DEBUG
@@ -380,8 +381,11 @@ struct pci_bus * __devinit pci_add_new_b
struct pci_bus *child;
child = pci_alloc_child_bus(parent, dev, busnr);
- if (child)
+ if (child) {
+ spin_lock(pci_bus_lock);
list_add_tail(child-node, parent-children);
+ spin_unlock(pci_bus_lock);
+ }
return child;
}
@@ -771,7 +775,9 @@ pci_scan_single_device(struct pci_bus *b
* and the bus list for fixup functions, etc.
*/
INIT_LIST_HEAD(dev-global_list);
+ spin_lock(pci_bus_lock);
list_add_tail(dev-bus_list, bus-devices);
+ spin_unlock(pci_bus_lock);
return dev;
}
@@ -891,7 +897,9 @@ struct pci_bus * __devinit pci_scan_bus_
DBG(PCI: Bus %04x:%02x already known\n, pci_domain_nr(b),
bus);
goto err_out;
}
+ spin_lock(pci_bus_lock);
list_add_tail(b-node, pci_root_buses);
+ spin_unlock(pci_bus_lock);
memset(dev, 0, sizeof(*dev));
dev-parent = parent;
@@ -933,7 +941,9 @@ class_dev_create_file_err:
class_dev_reg_err:
device_unregister(dev);
dev_reg_err:
+ spin_lock(pci_bus_lock);
list_del(b-node);
+ spin_unlock(pci_bus_lock);
err_out:
kfree(dev);
kfree(b);
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 07/12] Make the PCI remove routines safe for failed hot-plug
When a root bridge hierarchy is hot-plugged, resource requirements
for the new devices may be greater than what the root bridge is
decoding. In this case, we want to remove devices that did not
get needed resources. These devices have been scanned into bus
specific lists but not yet added to the global device list.
Make sure the pci remove functions can handle this case.
Signed-off-by: Rajesh Shah [EMAIL PROTECTED]
---
linux-2.6.11-mm4-iohp-rshah1/drivers/pci/remove.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff -puN drivers/pci/remove.c~pci-remove-device-hotplug-safe
drivers/pci/remove.c
--- linux-2.6.11-mm4-iohp/drivers/pci/remove.c~pci-remove-device-hotplug-safe
2005-03-16 13:07:22.667319764 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/pci/remove.c 2005-03-16
13:07:22.775718200 -0800
@@ -26,17 +26,21 @@ static void pci_free_resources(struct pc
static void pci_destroy_dev(struct pci_dev *dev)
{
- pci_proc_detach_device(dev);
- pci_remove_sysfs_dev_files(dev);
- device_unregister(dev-dev);
+ if (!list_empty(dev-global_list)) {
+ pci_proc_detach_device(dev);
+ pci_remove_sysfs_dev_files(dev);
+ device_unregister(dev-dev);
+ spin_lock(pci_bus_lock);
+ list_del(dev-global_list);
+ dev-global_list.next = dev-global_list.prev = NULL;
+ spin_unlock(pci_bus_lock);
+ }
/* Remove the device from the device lists, and prevent any further
* list accesses from this device */
spin_lock(pci_bus_lock);
list_del(dev-bus_list);
- list_del(dev-global_list);
dev-bus_list.next = dev-bus_list.prev = NULL;
- dev-global_list.next = dev-global_list.prev = NULL;
spin_unlock(pci_bus_lock);
pci_free_resources(dev);
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 06/12] Link newly created pci child bus to its parent on creation
When a pci child bus is created, add it to the parent's children
list immediately rather than waiting till pci_bus_add_devices().
For hot-plug bridges/devices, pci_bus_add_devices() may be called
much later, after they have been properly configured. In the
meantime, this allows us to use the normal pci bus search functions
for the hot-plug bridges/buses.
Signed-off-by: Rajesh Shah [EMAIL PROTECTED]
---
linux-2.6.11-mm4-iohp-rshah1/drivers/pci/bus.c | 11 +++
linux-2.6.11-mm4-iohp-rshah1/drivers/pci/probe.c |4 ++--
2 files changed, 9 insertions(+), 6 deletions(-)
diff -puN drivers/pci/probe.c~pci_link_child_bus drivers/pci/probe.c
--- linux-2.6.11-mm4-iohp/drivers/pci/probe.c~pci_link_child_bus
2005-03-16 13:07:18.745444812 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/pci/probe.c2005-03-16
13:07:18.857749498 -0800
@@ -457,7 +457,7 @@ int __devinit pci_scan_bridge(struct pci
return max;
}
- child = pci_alloc_child_bus(bus, dev, busnr);
+ child = pci_add_new_bus(bus, dev, busnr);
if (!child)
return max;
child-primary = buses 0xFF;
@@ -484,7 +484,7 @@ int __devinit pci_scan_bridge(struct pci
* This can happen when a bridge is hot-plugged */
if (pci_find_bus(pci_domain_nr(bus), max+1))
return max;
- child = pci_alloc_child_bus(bus, dev, ++max);
+ child = pci_add_new_bus(bus, dev, ++max);
buses = (buses 0xff00)
| ((unsigned int)(child-primary) 0)
| ((unsigned int)(child-secondary) 8)
diff -puN drivers/pci/bus.c~pci_link_child_bus drivers/pci/bus.c
--- linux-2.6.11-mm4-iohp/drivers/pci/bus.c~pci_link_child_bus 2005-03-16
13:07:18.749351062 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/pci/bus.c 2005-03-16
13:07:18.858726061 -0800
@@ -121,10 +121,13 @@ void __devinit pci_bus_add_devices(struc
* If there is an unattached subordinate bus, attach
* it and then scan for unattached PCI devices.
*/
- if (dev-subordinate list_empty(dev-subordinate-node)) {
- spin_lock(pci_bus_lock);
- list_add_tail(dev-subordinate-node,
dev-bus-children);
- spin_unlock(pci_bus_lock);
+ if (dev-subordinate) {
+ if (list_empty(dev-subordinate-node)) {
+ spin_lock(pci_bus_lock);
+ list_add_tail(dev-subordinate-node,
+ dev-bus-children);
+ spin_unlock(pci_bus_lock);
+ }
pci_bus_add_devices(dev-subordinate);
sysfs_create_link(dev-subordinate-class_dev.kobj,
dev-dev.kobj, bridge);
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 09/12] Read bridge resources when fixing up the bus
Read bridge io/mem/pfmem ranges when fixing up the bus so that
bus resources are tracked. This is required to properly support
pci end device and bridge hotplug.
Signed-off-by: Rajesh Shah [EMAIL PROTECTED]
---
linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c |4
1 files changed, 4 insertions(+)
diff -puN arch/ia64/pci/pci.c~ia64-read_bridge_bases arch/ia64/pci/pci.c
--- linux-2.6.11-mm4-iohp/arch/ia64/pci/pci.c~ia64-read_bridge_bases
2005-03-16 13:07:30.503257168 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c2005-03-16
13:07:30.612632167 -0800
@@ -436,6 +436,10 @@ pcibios_fixup_bus (struct pci_bus *b)
{
struct pci_dev *dev;
+ if (b-self) {
+ pci_read_bridge_bases(b);
+ pcibios_fixup_device_resources(b-self);
+ }
list_for_each_entry(dev, b-devices, bus_list)
pcibios_fixup_device_resources(dev);
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 10/12] Allow ACPI .add and .start operations to be done independently
Create new interfaces to recursively add an acpi namespace object
to the acpi device list, and recursively start the namespace
object. This is needed for ACPI based hotplug of a root bridge
hierarchy where the add operation must be performed first and
the start operation must be performed separately after the
hot-plugged devices have been properly configured.
Signed-off-by: Rajesh Shah [EMAIL PROTECTED]
---
linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/container.c |2
linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/processor_core.c |2
linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/scan.c | 126 ++---
linux-2.6.11-mm4-iohp-rshah1/include/acpi/acpi_bus.h | 17 +
4 files changed, 119 insertions(+), 28 deletions(-)
diff -puN drivers/acpi/scan.c~acpi_separate_device_start drivers/acpi/scan.c
--- linux-2.6.11-mm4-iohp/drivers/acpi/scan.c~acpi_separate_device_start
2005-03-16 13:07:34.326499309 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/scan.c2005-03-16
13:07:34.452475870 -0800
@@ -553,20 +553,29 @@ acpi_bus_driver_init (
* upon possible configuration and currently allocated resources.
*/
+ ACPI_DEBUG_PRINT((ACPI_DB_INFO, Driver successfully bound to
device\n));
+ return_VALUE(0);
+}
+
+int
+acpi_start_single_object (
+ struct acpi_device *device)
+{
+ int result = 0;
+ struct acpi_driver *driver;
+
+ ACPI_FUNCTION_TRACE(acpi_start_single_object);
+
+ if (!(driver = device-driver))
+ return_VALUE(0);
+
if (driver-ops.start) {
result = driver-ops.start(device);
if (result driver-ops.remove)
driver-ops.remove(device, ACPI_BUS_REMOVAL_NORMAL);
- return_VALUE(result);
- }
-
- ACPI_DEBUG_PRINT((ACPI_DB_INFO, Driver successfully bound to
device\n));
-
- if (driver-ops.scan) {
- driver-ops.scan(device);
}
- return_VALUE(0);
+ return_VALUE(result);
}
static int acpi_driver_attach(struct acpi_driver * drv)
@@ -586,6 +595,7 @@ static int acpi_driver_attach(struct acp
if (!acpi_bus_match(dev, drv)) {
if (!acpi_bus_driver_init(dev, drv)) {
+ acpi_start_single_object(dev);
atomic_inc(drv-references);
count++;
ACPI_DEBUG_PRINT((ACPI_DB_INFO, Found driver
[%s] for device [%s]\n,
@@ -1009,8 +1019,8 @@ acpi_bus_remove (
}
-int
-acpi_bus_add (
+static int
+acpi_add_single_object (
struct acpi_device **child,
struct acpi_device *parent,
acpi_handle handle,
@@ -1019,7 +1029,7 @@ acpi_bus_add (
int result = 0;
struct acpi_device *device = NULL;
- ACPI_FUNCTION_TRACE(acpi_bus_add);
+ ACPI_FUNCTION_TRACE(acpi_add_single_object);
if (!child)
return_VALUE(-EINVAL);
@@ -1140,7 +1150,7 @@ acpi_bus_add (
*
* TBD: Assumes LDM provides driver hot-plug capability.
*/
- acpi_bus_find_driver(device);
+ result = acpi_bus_find_driver(device);
end:
if (!result)
@@ -1153,10 +1163,10 @@ end:
return_VALUE(result);
}
-EXPORT_SYMBOL(acpi_bus_add);
-int acpi_bus_scan (struct acpi_device *start)
+static int acpi_bus_scan (struct acpi_device *start,
+ struct acpi_bus_ops *ops)
{
acpi_status status = AE_OK;
struct acpi_device *parent = NULL;
@@ -1229,9 +1239,20 @@ int acpi_bus_scan (struct acpi_device*s
continue;
}
- status = acpi_bus_add(child, parent, chandle, type);
- if (ACPI_FAILURE(status))
- continue;
+ if (ops-acpi_op_add)
+ status = acpi_add_single_object(child, parent,
+ chandle, type);
+else
+ status = acpi_bus_get_device(chandle, child);
+
+if (ACPI_FAILURE(status))
+continue;
+
+ if (ops-acpi_op_start) {
+ status = acpi_start_single_object(child);
+ if (ACPI_FAILURE(status))
+ continue;
+ }
/*
* If the device is present, enabled, and functioning then
@@ -1257,8 +1278,50 @@ int acpi_bus_scan (struct acpi_device*s
return_VALUE(0);
}
-EXPORT_SYMBOL(acpi_bus_scan);
+int
+acpi_bus_add (
+ struct acpi_device **child,
+ struct acpi_device *parent,
+ acpi_handle handle,
+ int type)
+{
+ int result;
+ struct acpi_bus_ops ops;
+
+ ACPI_FUNCTION_TRACE(acpi_bus_add);
+
+ result
[patch 11/12] Export the interface to get PCI id for an ACPI handle
Export an acpi interface to get PCI domain/bus/devfn information
from the corresponding namespace handle. Used by acpiphp code
to transpate the device handle of the hot-plugged root bridge to
the corresponding pci location information.
Signed-off-by: Rajesh Shah [EMAIL PROTECTED]
---
linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/pci_bind.c | 11 +--
linux-2.6.11-mm4-iohp-rshah1/include/acpi/acpi_drivers.h |1 +
2 files changed, 6 insertions(+), 6 deletions(-)
diff -puN drivers/acpi/pci_bind.c~acpi-get-pci-id drivers/acpi/pci_bind.c
--- linux-2.6.11-mm4-iohp/drivers/acpi/pci_bind.c~acpi-get-pci-id
2005-03-16 13:07:39.028647689 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/pci_bind.c2005-03-16
13:07:39.141928937 -0800
@@ -61,15 +61,14 @@ acpi_pci_data_handler (
/**
- * acpi_os_get_pci_id
+ * acpi_get_pci_id
* --
* This function is used by the ACPI Interpreter (a.k.a. Core Subsystem)
* to resolve PCI information for ACPI-PCI devices defined in the namespace.
* This typically occurs when resolving PCI operation region information.
*/
-#ifdef ACPI_FUTURE_USAGE
acpi_status
-acpi_os_get_pci_id (
+acpi_get_pci_id (
acpi_handle handle,
struct acpi_pci_id *id)
{
@@ -78,7 +77,7 @@ acpi_os_get_pci_id (
struct acpi_device *device = NULL;
struct acpi_pci_data*data = NULL;
- ACPI_FUNCTION_TRACE(acpi_os_get_pci_id);
+ ACPI_FUNCTION_TRACE(acpi_get_pci_id);
if (!id)
return_ACPI_STATUS(AE_BAD_PARAMETER);
@@ -92,7 +91,7 @@ acpi_os_get_pci_id (
}
status = acpi_get_data(handle, acpi_pci_data_handler, (void**) data);
- if (ACPI_FAILURE(status) || !data || !data-dev) {
+ if (ACPI_FAILURE(status) || !data) {
ACPI_DEBUG_PRINT((ACPI_DB_ERROR,
Invalid ACPI-PCI context for device %s\n,
acpi_device_bid(device)));
@@ -115,7 +114,7 @@ acpi_os_get_pci_id (
return_ACPI_STATUS(AE_OK);
}
-#endif /* ACPI_FUTURE_USAGE */
+EXPORT_SYMBOL(acpi_get_pci_id);
int
diff -puN include/acpi/acpi_drivers.h~acpi-get-pci-id
include/acpi/acpi_drivers.h
--- linux-2.6.11-mm4-iohp/include/acpi/acpi_drivers.h~acpi-get-pci-id
2005-03-16 13:07:39.033530501 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/include/acpi/acpi_drivers.h2005-03-16
13:07:39.142905500 -0800
@@ -68,6 +68,7 @@ void acpi_pci_irq_del_prt (int segment,
struct pci_bus;
+acpi_status acpi_get_pci_id (acpi_handle handle, struct acpi_pci_id *id);
int acpi_pci_bind (struct acpi_device *device);
int acpi_pci_unbind (struct acpi_device *device);
int acpi_pci_bind_root (struct acpi_device *device, struct acpi_pci_id *id,
struct pci_bus *bus);
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 08/12] Remove hot-plugged devices that could not be allocated resources
When hot-plugging an I/O hierarchy that contains many bridges
and leaf devices, it's possible that there are not enough
resources to start all the device present. If we fail to assign
a resource, clear the corresponding value in the pci_dev structure,
so other code can take corrective action.
Signed-off-by: Rajesh Shah [EMAIL PROTECTED]
---
linux-2.6.11-mm4-iohp-rshah1/drivers/pci/setup-bus.c |5 -
1 files changed, 4 insertions(+), 1 deletion(-)
diff -puN drivers/pci/setup-bus.c~discard_no_resource_devs
drivers/pci/setup-bus.c
--- linux-2.6.11-mm4-iohp/drivers/pci/setup-bus.c~discard_no_resource_devs
2005-03-16 13:07:26.557944717 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/pci/setup-bus.c2005-03-16
13:07:26.666343153 -0800
@@ -72,7 +72,10 @@ pbus_assign_resources_sorted(struct pci_
for (list = head.next; list;) {
res = list-res;
idx = res - list-dev-resource[0];
- pci_assign_resource(list-dev, idx);
+ if (pci_assign_resource(list-dev, idx)) {
+ res-start = 0;
+ res-flags = 0;
+ }
tmp = list;
list = list-next;
kfree(tmp);
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 12/12] ACPI based root bridge hot-add
acpiphp changes to support acpi based root bridge hot-add.
This patch applies on top of the acpiphp re-write patch by
Matthew Wilcox at:
http://marc.theaimsgroup.com/?l=linux-ia64m=110616116714938w=2
Signed-off-by: Rajesh Shah [EMAIL PROTECTED]
---
linux-2.6.11-mm4-iohp-rshah1/drivers/pci/hotplug/acpiphp_glue.c | 211
+-
1 files changed, 202 insertions(+), 9 deletions(-)
diff -puN drivers/pci/hotplug/acpiphp_glue.c~acpiphp_h2p_add
drivers/pci/hotplug/acpiphp_glue.c
--- linux-2.6.11-mm4-iohp/drivers/pci/hotplug/acpiphp_glue.c~acpiphp_h2p_add
2005-03-16 13:37:08.716126010 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/pci/hotplug/acpiphp_glue.c
2005-03-16 13:37:08.825501009 -0800
@@ -6,6 +6,8 @@
* Copyright (C) 2002,2003 NEC Corporation
* Copyright (C) 2003-2005 Matthew Wilcox ([EMAIL PROTECTED])
* Copyright (C) 2003-2005 Hewlett Packard
+ * Copyright (C) 2005 Rajesh Shah ([EMAIL PROTECTED])
+ * Copyright (C) 2005 Intel Corporation
*
* All rights reserved.
*
@@ -304,13 +306,15 @@ static void init_bridge_misc(struct acpi
register_slot, bridge, NULL);
/* install notify handler */
- status = acpi_install_notify_handler(bridge-handle,
+ if (bridge-type != BRIDGE_TYPE_HOST) {
+ status = acpi_install_notify_handler(bridge-handle,
ACPI_SYSTEM_NOTIFY,
handle_hotplug_event_bridge,
bridge);
- if (ACPI_FAILURE(status)) {
- err(failed to register interrupt notify handler\n);
+ if (ACPI_FAILURE(status)) {
+ err(failed to register interrupt notify handler\n);
+ }
}
list_add(bridge-list, bridge_list);
@@ -802,6 +806,143 @@ static int acpiphp_check_bridge(struct a
return retval;
}
+static void program_hpp(struct pci_dev *dev, struct acpiphp_bridge *bridge)
+{
+ u16 pci_cmd, pci_bctl;
+ struct pci_dev *cdev;
+
+ /* Program hpp values for this device */
+ if (!(dev-hdr_type == PCI_HEADER_TYPE_NORMAL ||
+ (dev-hdr_type == PCI_HEADER_TYPE_BRIDGE
+ (dev-class 8) == PCI_CLASS_BRIDGE_PCI)))
+ return;
+ pci_write_config_byte(dev, PCI_CACHE_LINE_SIZE,
+ bridge-hpp.cache_line_size);
+ pci_write_config_byte(dev, PCI_LATENCY_TIMER,
+ bridge-hpp.latency_timer);
+ pci_read_config_word(dev, PCI_COMMAND, pci_cmd);
+ if (bridge-hpp.enable_SERR)
+ pci_cmd |= PCI_COMMAND_SERR;
+ else
+ pci_cmd = ~PCI_COMMAND_SERR;
+ if (bridge-hpp.enable_PERR)
+ pci_cmd |= PCI_COMMAND_PARITY;
+ else
+ pci_cmd = ~PCI_COMMAND_PARITY;
+ pci_write_config_word(dev, PCI_COMMAND, pci_cmd);
+
+ /* Program bridge control value and child devices */
+ if ((dev-class 8) == PCI_CLASS_BRIDGE_PCI) {
+ pci_write_config_byte(dev, PCI_SEC_LATENCY_TIMER,
+ bridge-hpp.latency_timer);
+ pci_read_config_word(dev, PCI_BRIDGE_CONTROL, pci_bctl);
+ if (bridge-hpp.enable_SERR)
+ pci_bctl |= PCI_BRIDGE_CTL_SERR;
+ else
+ pci_bctl = ~PCI_BRIDGE_CTL_SERR;
+ if (bridge-hpp.enable_PERR)
+ pci_bctl |= PCI_BRIDGE_CTL_PARITY;
+ else
+ pci_bctl = ~PCI_BRIDGE_CTL_PARITY;
+ pci_write_config_word(dev, PCI_BRIDGE_CONTROL, pci_bctl);
+ if (dev-subordinate) {
+ list_for_each_entry(cdev, dev-subordinate-devices,
+ bus_list)
+ program_hpp(cdev, bridge);
+ }
+ }
+}
+
+static void acpiphp_set_hpp_values(acpi_handle handle, struct pci_bus *bus)
+{
+ struct acpiphp_bridge bridge;
+ struct pci_dev *dev;
+
+ memset(bridge, 0, sizeof(bridge));
+ bridge.handle = handle;
+ decode_hpp(bridge);
+ list_for_each_entry(dev, bus-devices, bus_list)
+ program_hpp(dev, bridge);
+
+}
+
+/*
+ * Remove devices for which we could not assign resources, call
+ * arch specific code to fix-up the bus
+ */
+static void acpiphp_sanitize_bus(struct pci_bus *bus)
+{
+ struct pci_dev *dev;
+ int i;
+ unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM;
+
+ list_for_each_entry(dev, bus-devices, bus_list) {
+ for (i=0; iPCI_BRIDGE_RESOURCES; i++) {
+ struct resource *res = dev-resource[i];
+ if ((res-flags type_mask) !res-start
+ res-end) {
+ /* Could not assign a required resources
