- 06 Oct, 2004 40 commits
-
-
Greg Kroah-Hartman authored
No, pci_register_driver() does not return the number of pci devices found, sorry. No, if pci_register_driver() fails, you do not need to call pci_unregister_driver(). Signed-off-by:Greg Kroah-Hartman <greg@kroah.com>
-
Greg Kroah-Hartman authored
It shouldn't return 1, it needs to return either -ERROR or 0. Signed-off-by: -
Greg Kroah-Hartman authored
Signed-off-by: -
Greg Kroah-Hartman authored
Signed-off-by: -
John Rose authored
Here's a really long explanation for a really short patch! :) As an unfortunate side effect of runtime addition/removal of PCI Host Bridges, the RPA DLPAR driver can no longer depend on the success of ioremap_explicit() (and therefore remap_page_range()) for the case of DLPAR adding an I/O Slot. Without addressing this, an attempt to add the first child slot of a newly added PHB will fail when __ioremap_explicit() determines the mappings for that range to already exist. For a little context, __ioremap_explicit() creates mappings for the range of a newly added slot. Here's why these calls will be expected to fail in some cases. Keep in mind that at boot-time, the PPC64 kernel calls ioremap() for the entire range spanned by each PHB. Consider the following scenarios of DLPAR-adding an I/O slot. 1) Just after boot, one removes an I/O slot. At this point the range associated with the parent PHB is fragmented, and the child range for the slot in question is iounmap()'ed. One then re-adds the slot, at which point remap_page_range()/ioremap_explicit() restores the mappings that were previously removed. 2) One adds a new PHB, at which point the ppc64-specific addition ioremaps the entire PHB range. One then performs a DLPAR-add of a child slot of that PHB. At this point, mappings already exist for the range of the slot to be added. So remap_page_range()/ioremap_explicit() will fail at this point. The problem is, there's not a good way to distinguish between cases 1 and 2 from the perspective of the DLPAR driver. Because of that, I believe the correct solution to be: - Removal of relevant error prints from iounmap_explicit(), which is only used for DLPAR. - Removal of error code checks from the RPA driver Signed-off-by:
John Rose <johnrose@austin.ibm.com> Signed-off-by:
-
Greg Kroah-Hartman authored
Signed-off-by: -
Greg Kroah-Hartman authored
Signed-off-by: -
Paul Mackerras authored
From: John Rose <johnrose@austin.ibm.com> The following patch implements the ppc64-specific bits for dynamic (DLPAR) addition of PCI Host Bridges. The entry point for this operation is init_phb_dynamic(), which will be called by the RPA DLPAR driver. Among the implementation details, the global number aka PCI domain for the newly added PHB is assigned using the same simple counter that assigns it at boot. This has two consequences. First, the PCI domain associated with a PHB will not persist across DLPAR remove and subsequent add. Second, stress tests that repeatedly add/remove PHBs might generate some large values for PCI domain. If we decide at a later point to hash an OF property to PCI domain value, this can be easily fixed up. Also, the linux,pci-domain property is not generated for the newly added PHBs at the moment. Because there doesn't seem to be an easy way to dynamically add single properties to the OFDT, and because the userspace dependency on this property is being questioned, I've ignored it for now. If we decide on a solution for this at a later point, it can also be easily fixed up. Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Greg Kroah-Hartman authored
Signed-off-by: -
Paul Mackerras authored
From: John Rose <johnrose@austin.ibm.com> The following patch creates pcibios_remove_root_bus(), which performs the ppc64-specific actions for removal of PCI Host Bridges. This call is invoked by the RPA DLPAR driver upon PHB removal. Signed-off-by:
-
Nishanth Aravamudan authored
Use msleep_interruptible() instead of schedule_timeout() to guarantee the task delays as expected. Signed-off-by:
Nishanth Aravamudan <nacc@us.ibm.com> Signed-off-by:
-
Nishanth Aravamudan authored
Use msleep_interruptible() instead of schedule_timeout() to guarantee the task delays as expected. Signed-off-by:
-
Nishanth Aravamudan authored
Use msleep_interruptible() instead of schedule_timeout() to guarantee the task delays as expected. Signed-off-by:
-
Nishanth Aravamudan authored
Use msleep_interruptible() instead of schedule_timeout() to guarantee the task delays as expected. Signed-off-by:
-
Dely Sy authored
In kernel 2.6.8, MSI has been updated. This patch updates the two hot-plug drivers to call pci_disable_msi() per MSI change to undo the effect of pci_enable_msi() when the driver is unloading. Signed-off-by:
Dely Sy <dely.l.sy@intel.com> Signed-off-by:
-
Roger Luethi authored
This is the second (and hopefully final) iteration of the interface change we talked about a while ago. The patch applies cleanly against 2.6.9-rc2-mm4. This removes the second argument (buffer for storing PCI state) from pci_{save,restore}_state since pci_dev contains such a buffer now. Fixed all callers. Three drivers used to pass a buffer of 256 bytes, one only 48(!). The rest was correct. Changes were compile tested, except for Alpha. Signed-off-by:Roger Luethi <rl@hellgate.ch> Signed-off-by:
-
Lennert Buytenhek authored
Here is another patch (against 2.6.9-rc2, not sure if that has the latest version of the PCI db) that removes the vendor names from Intel IXP and Radisys ENP entries, as per Martin's suggestion. Signed-off-by: -
Greg Kroah-Hartman authored
Signed-off-by:
Hanna Linder <hannal@us.ibm.com> Signed-off-by:
-
Greg Kroah-Hartman authored
This is needed to help get rid of the pci_find_device() usage in the tree. Signed-off-by:
-
Luiz Capitulino authored
I noticed drivers/pci/probe.c::pci_scan_bus_parented() has some functions which the return value is not checked. The patch bellow adds the check for device_register(), class_device_register(), class_device_create_file() and sysfs_create_link(). (hope the error label names are not too ugly). Signed-off-by:
Luiz Capitulino <lcapitulino@conectiva.com.br> Signed-off-by:
-
Dely Sy authored
This patch contains a fix that was missed out in the last patch I sent you regarding fixes for writing 1's to RsvdZ in Slot Status register causing hot-plugging of PCI-X cards not working in some slots. Signed-off-by:
-
Hanna V. Linder authored
Another simple patch to complete the /i386 conversion to pci_get_device. I was able to compile and boot this patch to verify it didn't break anything (on my T22). Signed-off-by:
-
Vernon Mauery authored
This patch fixes an off by one error that one of the IBM machines that uses the acpiphp_ibm driver. The slots were numbered starting at 0 in BIOS instead of starting at 1 like the pci hotplug subsystem names them. So this patch provides a lookup to translate the Linux slot numbers to the internal ACPI numbers. Signed-off-by:
Vernon Mauery <vernux@us.ibm.com> Signed-off-by:
-
John Rose authored
The following patch implements the RPA PCI Hotplug and DLPAR driver changes for the dynamic addition/removal of PCI Host bridges (PHBs). These operations are initiated in the same way as existing slot DLPAR operations, which is by writing the firmware (drc) name of the PHB to: /sys/bus/pci/slots/control/[add,remove]_slot The "kernel" entry points for these operations are: pcibios_remove_root_bus() ppc64-specific, submitted to ppc64 list on 8/19, not yet accepted http://ozlabs.org/ppc64-patches/patch.pl?id=241 init_phb_dynamic() ppc64-specific, submitted to ppc64 list on 9/16, not yet accepted http://ozlabs.org/ppc64-patches/patch.pl?id=292 pci_remove_bus() generic, submitted and accepted by Greg http://www.uwsg.iu.edu/hypermail/linux/kernel/0408.3/0595.htmlSigned-off-by:
-
Greg Kroah-Hartman authored
Signed-off-by: -
Hanna V. Linder authored
Just noticed this in my update to the latest mm kernel... Signed-off-by: -
Greg Kroah-Hartman authored
Signed-off-by: -
Dely Sy authored
Can you please apply the following patch that has bug fixes for shpchp driver? One bug was writing 1's to RsvdZ in Slot Status register causing hot-plugging of PCI-X cards not working in some slots. The other fix is for getting the correct bus number. Signed-off-by:
-
Greg Kroah-Hartman authored
Signed-off-by: -
Greg Kroah-Hartman authored
Signed-off-by: -
Greg Kroah-Hartman authored
Signed-off-by: -
Dely Sy authored
Greg, Here is a patch (against 2.6.8-rc2) that fixes the following things: 1) adds code to lower bus speed if the adapter card added run at a lower speed that the current bus speed; 2) checks for any devices on the same bus - not just those that sit on slots controlled by the same shpc; 3) cleans up the code in the check bus speed area in board_added() by creating two functions to handle common code. Signed-off-by:
-
Kenji Kaneshige authored
As mentioned in Documentaion/pci.txt, pci device driver should call pci_disable_device() when it decides to stop using the device. But there are some drivers that don't use pci_disable_device() so far. This patch adds warning messages that are displayed if the device is removed without properly calling pci_disable_device(). 'WARN_ON(1)' is commented out for now because I guess many people (including some distros) enables 'CONFIG_DEBUG_KERNEL'. People might be surprised if many stack dumps are displayed on their console. Signed-off-by:
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by:
-
John Rose authored
The following patch implements the registration of PCI Host Bridges as hotplug slots. Only host bridges that are dynamically removable will be registered. The hotplug slots directory goes from looking like this: # ls /sys/bus/pci/slots . 0000:00:02.2 0001:00:02.4 0002:00:02.2 30000000 .. 0000:00:02.4 0001:00:02.6 0002:00:02.4 control 0000:00:02.0 0001:00:02.2 0002:00:02.0 0002:00:02.6 to this: # ls /sys/bus/pci/slots . 0000:00:02.0 0001:00:00.0 0001:00:02.6 0002:00:02.2 30000000 .. 0000:00:02.2 0001:00:02.2 0002:00:00.0 0002:00:02.4 control 0000:00:00.0 0000:00:02.4 0001:00:02.4 0002:00:02.0 0002:00:02.6 This work is precursory to the DLPAR module changes that implement addition/removal of these bridges. Please apply if there are no objections. Signed-off-by:
-
Greg Kroah-Hartman authored
yeah, I ignored the ppc64 hotplug pci driver, they can fix it up themselves... Signed-off-by: -
Greg Kroah-Hartman authored
Signed-off-by: -
Andrew Morton authored
From: Bjorn Helgaas <bjorn.helgaas@hp.com> Nick Piggin's USB driver stopped working when I removed the unconditional PCI ACPI IRQ routing stuff. He has verified that the attached patch fixes it. I sort of hate to add another pass of PCI fixups, so I'm open to alternate solutions if anybody suggests one. Add a "pci_fixup_enable" pass of PCI fixups. These are run at the end of pci_enable_device() to fix up things like IRQs that are not set up until then. Some VIA boards require a fixup after the IRQ is set up. Found by Nick Piggin, initial patch by Bjorn Helgaas, reworked to fit into current -mm by Nick. Signed-off-by:
Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by:
Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Maximilian Attems authored
list_for_each & pci_(dev|bus)_[bg] replaced by list_for_each_entry. Signed-off-by:
Domen Puncer <domen@coderock.org> Signed-off-by:
Maximilian Attems <janitor@sternwelten.at> Signed-off-by:
-
Maximilian Attems authored
s/for/list_for_each/ Signed-off-by:
-
Maximilian Attems authored
s/for/list_for_each/ Signed-off-by:
-
