- 06 Oct, 2004 40 commits
-
-
Greg Kroah-Hartman authored
This is needed to help get rid of the pci_find_device() usage in the tree. Signed-off-by:
Hanna Linder <hannal@us.ibm.com> Signed-off-by:
Greg Kroah-Hartman <greg@kroah.com>
-
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:
Dely Sy <dely.l.sy@intel.com> 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:
John Rose <johnrose@austin.ibm.com> Signed-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:
-
Maximilian Attems authored
s/for/list_for_each/ 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:
-
Maximilian Attems authored
Change for loops with list_for_each_entry(). Signed-off-by:
-
Maximilian Attems authored
Change for loops with list_for_each(). Signed-off-by:
-
Maximilian Attems authored
Replace for with more readable list_for_each. Compile tested. Signed-off-by:
-
Li Shaohua authored
On Tuesday, August 31, 2004, Linus Torvalds wrote: > That list per se obviously looks ok by me, although I'd worry that some > other fs_initcall depends on the ACPI stuff having been run (ie while the > abover ordering is great, I worry that some _other_ part doesn't fit in > the above ordering). Doing a quick check finds "chr_dev_init()", for > example, which will do fbmem_init(), which might depend on the ACPI/PnP > stuff having run already. > > So it _might_ be safer to make this ordering more explicit, rather than Yes, I agree. The problem is there isn't a straightforward method for it. It possibly is hard to get it. > depending on the different phases of the initcalls. But I'd happily be > proven wrogn with some simple argument for why this is guaranteed to be > ok.. For example, maybe ACPI and PnP is linked before chr/mem.c, in which > case it should all be ok. Original PCI assign resources code is the last 'subsys_initcall' according to the makefile, so move some code of it to 'fs_initcall' (just below 'subsystem_initcall') should be ok. As you said, ACPI and PnP is linked before chr/mem.c. The method requires all other 'fs_initcall' don't touch PCI resources, since 'pcibios_assign_resources' is a 'fs_initcall' and maybe don't run, but it looks ok currently. Again, I will be appreciated if we can find a solution to make the ordering explicit. Signed-off-by: -
David Brownell authored
That document was wrong on some things, misleading on others; this fixes some of the issues I noticed. However it probably needs to say that drivers for devices that implement the PCI PM spec "should" always use pci_set_power_state() to reduce the power usage. If I get ambitions I might submit a patch to the PCI core to print a nag message for drivers that don't do that. Updates the PCI PM docs, better matching the specs and code. - List both D3 states (D3hot, D3cold) up front. - Clarify that suspend() methods should disable I/0 (including DMA) and IRQs; it's not optional. - More accurately describe resume(); there are common cases where device re-initialization isn't appropriate. The previous text said re-init was always required; that's false. Signed-off-by:David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
Christoph Hellwig authored
Signed-off-by: -
Evgeniy Polyakov authored
Remove pci_find_device() in arch/i386/kernel/scx200.c. Signed-off-by:
Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by:
-
Greg Kroah-Hartman authored
Thanks to Joe Perches for pointing this out. Signed-off-by: -
Greg Kroah-Hartman authored
Signed-off-by: -
Greg Kroah-Hartman authored
Signed-off-by: -
Greg Kroah-Hartman authored
Signed-off-by: -
Greg Kroah-Hartman authored
Signed-off-by: -
Greg Kroah-Hartman authored
Signed-off-by: -
Greg Kroah-Hartman authored
Signed-off-by: -
Greg Kroah-Hartman authored
Signed-off-by:
-
