John Rose [Fri, 15 Oct 2004 05:00:07 +0000 (22:00 -0700)]
[PATCH] PCI Hotplug: rpaphp safe list traversal
Hoping you will accept this fix. The bug can cause a crash upon hotplug
remove. The bug involves unsafe traversal of a list while deleting list
members. The fix uses list_for_each_safe() rather than
list_for_each(). Also threw in an initialization to get rid of a
compiler warning.
Signed-off-by: John Rose <johnrose@austin.ibm.com> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Andrew Morton [Wed, 6 Oct 2004 10:20:53 +0000 (03:20 -0700)]
[PATCH] PCI: pci_dev_put() build fix
With CONFIG_PCI=n:
arch/i386/kernel/cpu/mtrr/main.c: In function `have_wrcomb':
arch/i386/kernel/cpu/mtrr/main.c:86: warning: implicit declaration of function `pci_dev_put
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Andrew Morton [Wed, 6 Oct 2004 10:20:23 +0000 (03:20 -0700)]
[PATCH] PCI: CONFIG_PCI=n build fix
With CONFIG_PCI=n:
arch/i386/kernel/cpu/cyrix.c: In function `init_cyrix':
arch/i386/kernel/cpu/cyrix.c:285: `cyrix_55x0' undeclared (first use in this function)
arch/i386/kernel/cpu/cyrix.c:285: (Each undeclared identifier is reported only once
arch/i386/kernel/cpu/cyrix.c:285: for each function it appears in.)
Make pci_dev_present() a macro. It doesn't make sense to require that
pci_device_id's be in scope when CONFIG_PCI=n
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
[PATCH] PCI: audit all callers of pci_register_driver() to work properly.
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().
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 <greg@kroah.com>
Paul Mackerras [Wed, 6 Oct 2004 06:52:11 +0000 (23:52 -0700)]
[PATCH] PPC64: RPA dynamic addition/removal of PCI Host Bridges
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: John Rose <johnrose@austin.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Paul Mackerras [Wed, 6 Oct 2004 06:46:10 +0000 (23:46 -0700)]
[PATCH] PPC64: Add pcibios_remove_root_bus
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: John Rose <johnrose@austin.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Dely Sy [Wed, 6 Oct 2004 06:44:01 +0000 (23:44 -0700)]
[PATCH] PCI: Hot-plug driver updates due to MSI change
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: Greg Kroah-Hartman <greg@kroah.com>
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: Greg Kroah-Hartman <greg@kroah.com>
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.
Dely Sy [Wed, 6 Oct 2004 06:04:35 +0000 (23:04 -0700)]
[PATCH] PCI Hotplug: quirk fix missed out in last patch
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: Greg Kroah-Hartman <greg@kroah.com>
Hanna V. Linder [Wed, 6 Oct 2004 06:04:14 +0000 (23:04 -0700)]
[PATCH] PCI: Changed pci_find_device to pci_get_device for acpi.c
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: Hanna Linder <hannal@us.ibm.com> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Vernon Mauery [Wed, 6 Oct 2004 06:02:03 +0000 (23:02 -0700)]
[PATCH] PCI Hotplug: acpiphp extension fixes
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: Greg Kroah-Hartman <greg@kroah.com>
John Rose [Wed, 6 Oct 2004 06:01:41 +0000 (23:01 -0700)]
[PATCH] PCI Hotplug: RPA dynamic addition/removal of PCI Host Bridges
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.html
Signed-off-by: John Rose <johnrose@austin.ibm.com> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Dely Sy [Wed, 6 Oct 2004 05:55:35 +0000 (22:55 -0700)]
[PATCH] PCI Hotplug: Bug fixes for shpchp driver
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: Dely Sy <dely.l.sy@intel.com> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Dely Sy [Wed, 6 Oct 2004 05:51:12 +0000 (22:51 -0700)]
[PATCH] PCI Hotplug: change bus speed patch
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: Dely Sy <dely.l.sy@intel.com> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Kenji Kaneshige [Wed, 6 Oct 2004 05:50:32 +0000 (22:50 -0700)]
[PATCH] PCI: warn of missing pci_disable_device()
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.
John Rose [Wed, 6 Oct 2004 05:38:06 +0000 (22:38 -0700)]
[PATCH] PCI Hotplug: add host bridges to RPA hotplug subsystem
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: John Rose <johnrose@austin.ibm.com> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Andrew Morton [Wed, 6 Oct 2004 05:25:07 +0000 (22:25 -0700)]
[PATCH] add-pci_fixup_enable-pass.patch
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: Greg Kroah-Hartman <greg@kroah.com>
Li Shaohua [Wed, 6 Oct 2004 04:50:52 +0000 (21:50 -0700)]
[PATCH] PCI: Reorder some initialization code to allow resources to be proper allocated.
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.
David Brownell [Wed, 6 Oct 2004 04:50:24 +0000 (21:50 -0700)]
[PATCH] PCI: update Documentation/power/pci.txt
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: Greg Kroah-Hartman <greg@kroah.com>
Hirokazu Takata [Wed, 6 Oct 2004 01:15:24 +0000 (18:15 -0700)]
[PATCH] m32r: update ioremap routine
Here is a patch to update ioremap*.c for m32r, taken from "Add __iomem
modifier to the return value type of __ioremap() for much stricter
type-checking."
* arch/m32r/mm/ioremap.c: ditto.
- Add __iomem modifier to the return value type of __ioremap()
for much stricter type-checking.
* arch/m32r/mm/ioremap-nommu.c: ditto.
* include/asm-m32r/io.h:
- Modified for much stricter type-checking.
- Change __inline__ to inline.
[PATCH] Disable SW irqbalance/irqaffinity for E7520/E7320/E7525 - change TARGET_CPUS on x86_64
Set TARGET_CPUS on x86_64 to cpu_online_map. This brings the code inline
with x86 mach-default. Fix MSI_TARGET_CPU code which will break with this
target_cpus change.
Andi Kleen [Wed, 6 Oct 2004 01:14:35 +0000 (18:14 -0700)]
[PATCH] x86_64: make in_gate_vma() safer
x86-64 in_gate_vma would take a read lock on the VMA when the passed
address was inside the 32bit vsyscall page.
This would be called by get_user_pages, which already holds the mmap_sem.
Unfortunately some callers of get_user_pages hold the mmap_sem for writing,
which could in theory cause a deadlock.
I think it can currently not happen because the only users who hold it for
write before calling gup() are coredump and AIO in the ring setup, and both
should not ever access the vsyscall page.
But not taking the semaphore is safer and avoid this here.
Andi Kleen [Wed, 6 Oct 2004 01:13:54 +0000 (18:13 -0700)]
[PATCH] x86_64: remove CONFIG_FRAME_POINTER
CONFIG_FRAME_POINTER has never worked on x86-64 because it never passed
-fno-omit-frame-pointer to the compiler, and that is the only way to get a
frame pointer on x86-64.
It also causes complications with profiling. Drop it.
Andi Kleen [Wed, 6 Oct 2004 01:13:42 +0000 (18:13 -0700)]
[PATCH] x86_64: fix profile_pc
This fixes profile_pc to work properly on x86-64 and not crash.
It does now a simple backtrace to the caller of the spin lock without
requiring a frame pointer for this.
Frame pointer support has been dropped because it never worked.
There is still a small race window, but the only way to avoid it would be
to rewrite kernel/spinlock.c in assembler again. The race will account a
profile tick the the parent of the spinlock caller.
David Gibson [Wed, 6 Oct 2004 01:12:54 +0000 (18:12 -0700)]
[PATCH] ppc64: squash EEH warnings
A slightly non-ideal version of the recent patch which fixed EEH being a
no-op went in. The srcsave variable in eeh_memcpy_to_io() is now never
referenced on non-pSeries machines, and so spews hundreds of warnings. The
variable doesn't actually accomplish anything, so this patch gets rid of
it.
Signed-off-by: David Gibson <dwg@au1.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Gerhard Jaeger [Wed, 6 Oct 2004 01:11:53 +0000 (18:11 -0700)]
[PATCH] ppc32: fix PFC1_EPS and PFC1_EPS_SHIFT for IBM440GX
While writing some BSP code for a 440GX custom board, I noticed, that the
DCRN_SDR_PFC1_EPS and DCRN_SDR_PFC1_EPS_SHIFT definitions are wrong and
therefore the functions ibm440gx_get_eth_grp() and ibm440gx_set_eth_grp()
won't work correctly.
Signed-off-by: Matt Porter <mporter@kernel.crashing.org> Signed-off-by: Gerhard Jaeger <gjaeger@sysgo.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
projects / linux / log