- 23 Mar, 2006 40 commits
-
-
Kristen Accardi authored
Remove dock station support from ibm_acpi by default. This support has been put into acpiphp instead. Allow ibm_acpi to continue to provide docking station support via config option for laptops/docking stations that are not supported by acpiphp. Signed-off-by:
Kristen Carlson Accardi <kristen.c.accardi@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Kristen Accardi authored
These patches add generic dock event handling to acpiphp. If there are pci devices that need to be inserted/removed after the dock event, the event notification will be handed down to the normal pci hotplug event handler in acpiphp so that new bridges/devices can be enumerated. Because some dock stations do not have pci bridges or pci devices that need to be inserted after a dock, acpiphp will remain loaded to handle dock events even if no hotpluggable pci slots are discovered. You probably need to have the pci=assign-busses kernel parameter enabled to use these patches, and you may not allow ibm_acpi to handle docking notifications and use this patch. This patch incorporates feedback provided by many. Signed-off-by:
-
Kristen Accardi authored
Export the acpi_bus_trim function so that the pci hotplug driver can use it. Signed-off-by:
-
Kristen Accardi authored
If we add a new bridge with subordinate busses, we should call make sure that acpi is notified so that the PRT (if present) can be read and drivers who have registered on this bus will be notified when it is started. Also make sure to use the max reserved bus number for the starting the bus scan. Signed-off-by:
-
Alan Stern authored
This patch (as659) fixes a might_sleep problem in the PCI core, by moving a call to pci_dev_put() outside the scope of a spinlock. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Bernhard Kaindl authored
"In some cases, especially on modern laptops with a lot of PCI and cardbus bridges, we're unable to assign correct secondary/subordinate bus numbers to all cardbus bridges due to BIOS limitations unless we are using "pci=assign-busses" boot option." -- Ivan Kokshaysky (from a patch comment) Without it, Cardbus cards inserted are never seen by PCI because the parent PCI-PCI Bridge of the Cardbus bridge will not pass and translate Type 1 PCI configuration cycles correctly and the system will fail to find and initialise the PCI devices in the system. Reference: PCI-PCI Bridges: PCI Configuration Cycles and PCI Bus Numbering: http://www.science.unitn.it/~fiorella/guidelinux/tlk/node72.html The reason for this is that: ``All PCI busses located behind a PCI-PCI bridge must reside between the secondary bus number and the subordinate bus number (inclusive).'' "pci=assign-busses" makes pcibios_assign_all_busses return 1 and this turns on PCI renumbering during PCI probing. Alan suggested to use DMI automatically set assign-busses on problem systems. The only question for me was where to put it. I put it directly before scanning PCI bus into pcibios_scan_root() because it's called from legacy, acpi and numa and so it can be one place for all systems and configurations which may need it. AMD64 Laptops are also affected and fixed by assign-busses, and the code is also incuded from arch/x86_64/pci/ that place will also work for x86_64 kernels, I only ifdef'-ed the x86-only Laptop in this example. Affected and known or assumed to be fixed with it are (found by googling): * ASUS Z71V and L3s * Samsung X20 * Compaq R3140us and all Compaq R3000 series laptops with TI1620 Controller, also Compaq R4000 series (from a kernel.org bugreport) * HP zv5000z (AMD64 3700+, known that fixup_parent_subordinate_busnr fixes it) * HP zv5200z * IBM ThinkPad 240 * An IBM ThinkPad (1.8 GHz Pentium M) debugged by Pavel Machek gives the correspondig message which detects the possible problem. * MSI S260 / Medion SIM 2100 MD 95600 The patch also expands the "try pci=assign-busses" warning so testers will help us to update the DMI table. Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Grant Grundler authored
Use "unsigned long" when dealing with PCI resources. The BAR Indicator Register (BIR) can be a 64-bit value or the resource could be a 64-bit host physical address. Enables ib_mthca and cciss drivers to use MSI-X on ia64 HW. Problem showed up now because of new system firmware on one platform. Symptom will either be memory corruption or MCA. Second part of this patch deals with "useless" code. We walk through the steps to find the phys_addr and then don't use the result. I suspect the intent was to zero out the respective MSI-X entry but I'm not sure at the moment. Delete the code inside the #if 0/#endif if it's really not needed. Signed-off-by:
Grant Grundler <iod00d@hp.com> Signed-off-by:
-
Linus Torvalds authored
On Tue, 21 Feb 2006, Ivan Kokshaysky wrote: > There are two bogus entries in the BIOS memory map table which are > conflicting with a prefetchable memory range of the AGP bridge: > > BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) > BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) > > 0000:00:02.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual PCI-to-PCI bridge (AGP) (prog-if 00 [Normal decode]) > Flags: bus master, fast devsel, latency 0 > Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 > I/O behind bridge: 0000c000-0000cfff > Memory behind bridge: e7e00000-e7efffff > Prefetchable memory behind bridge: fec00000-ffcfffff > ^^^^^^^^^^^^^^^^^ Yes. However, it's pretty clear that the e820 entries are there for a reason. Probably they are a hack by the BIOS maintainers to keep Windows from stomping/moving that region, exactly because they want to keep the bridge where it is (or, it's actually for the BIOS itself - the BIOS tables are a horrid mess, and BIOS engineers are pretty hacky people: they'll add random entries to make their own broken algorithms do the "right thing"). > Starting from 2.6.13, kernel tries to resolve that sort of conflicts, > so that prefetch window of the bridge and the framebuffer memory behind > it get moved to 0x10000000. I think we could (and probably should) solve this another way: consider the ACPI "reserved regions" from the e820 map exactly the same way that we do other ACPI hints - they should restrict _new_ allocations, but not impact stuff we figure out on our own. Basically, right now we assign _unassigned_ resources at "fs_initcall" time. If we were to add in the e820 "reserved region" stuff before that (but after we've done PCI discovery), we'd probably do the right thing. Right now we do the e820 reserved regions very early indeed: we call "register_memory()" from setup_arch(). We could move at least part of it (the part that registers the resources) down a bit. Here's a test-patch. I'm not saying we should absolutely do this, but it might be interesting to try... Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: <bjk@luxsci.net> Signed-off-by:
-
Shaohua Li authored
Remove pcie port driver's msi save/restore code. Signed-off-by:
Shaohua Li <shaohua.li@intel.com> Signed-off-by:
-
Michael S. Tsirkin authored
It turns out AMD 8131 quirk only affects MSI for devices behind the 8131 bridge. Handle this by adding a flags field in pci_bus, inherited from parent to child. Signed-off-by:
Michael S. Tsirkin <mst@mellanox.co.il> Signed-off-by:
-
Bauke Jan Douma authored
On ASUS A8V and A8V Deluxe boards, the onboard AC97 audio controller and MC97 modem controller are deactivated when a second PCI soundcard is present. This patch enables them. Signed-off-by:
Bauke Jan Douma <bjdouma@xs4all.nl> Signed-off-by:
-
tomek@koprowski.org authored
I attach a trivial patch for 2.6.15.4 that unhides SMBus controller on an HP Compaq nx6110 notebook. Signed-off-by:
Tomasz Koprowski <tomek@koprowski.org> Signed-off-by:
-
Brian Gerst authored
The extra compatability code is not necessary. Any code still using the old shutdown method will trigger the warning in driver_register() instead. Signed-off-by:
Brian Gerst <bgerst@didntduck.org> Signed-off-by:
-
Kenji Kaneshige authored
This patch adapts SHPCHP driver to the PCI device driver model. Signed-off-by:
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by:
-
Kenji Kaneshige authored
Current SHPCHP driver doesn't care about the confliction between hotplug operation via sysfs and hotplug operation via attention button. So if those ware conflicted, slot could be an unexpected state. This patch changes SHPCHP driver to handle slot state properly. With this patch, slot events are handled according to the current slot state as shown at the Table below. Table. Slot States and Event Handling ========================================================================= Slot State Event and Action ========================================================================= STATIC - Go to POWERON state if user initiates (Slot enabled, insertion request via sysfs Slot disabled) - Go to POWEROFF state if user initiates removal request via sysfs - Go to BLINKINGON state if user presses attention button when the slot is disabled - Go to BLINKINGOFF state if user presses attention button when the slot is enabled
-
Kenji Kaneshige authored
The event handler of SHPCHP driver is unnecessarily very complex. In addition, current event handler can only a fixed number of events at the same time, and some of events would be lost if several number of events happened at the same time. This patch simplify the event handler by using 'work queue', and it also fix the above-mentioned issue. Signed-off-by:
-
Kenji Kaneshige authored
The wait_for_ctrl_irq() function in SHPCHP driver is no longer needed. This patch removes that. This patch has no functional change. Signed-off-by:
-
Kenji Kaneshige authored
This patch removes unused 'pci_bus' member from controller structure. This patch have no functional change. Signed-off-by:
-
Ralf Baechle authored
> On Mon, Feb 13, 2006 at 05:13:21PM -0800, David S. Miller wrote: > > > > In drivers/pci/probe.c:pci_scan_bridge(), if this is not the first > > pass (pass != 0) we don't restore the PCI_BRIDGE_CONTROL_REGISTER and > > thus leave PCI_BRIDGE_CTL_MASTER_ABORT off: > > > > int __devinit pci_scan_bridge(struct pci_bus *bus, struct pci_dev * dev, int max, int pass) > > { > > ... > > /* Disable MasterAbortMode during probing to avoid reporting > > of bus errors (in some architectures) */ > > pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &bctl); > > pci_write_config_word(dev, PCI_BRIDGE_CONTROL, > > bctl & ~PCI_BRIDGE_CTL_MASTER_ABORT); > > ... > > if ((buses & 0xffff00) && !pcibios_assign_all_busses() && !is_cardbus) { > > unsigned int cmax, busnr; > > /* > > * Bus already configured by firmware, process it in the first > > * pass and just note the configuration. > > */ > > if (pass) > > return max; > > ... > > } > > > > pci_write_config_word(dev, PCI_BRIDGE_CONTROL, bctl); > > ... > > > > This doesn't seem intentional. Agreed, looks like an accident. The patch [1] originally came from Kip Walker (Broadcom back then) between 2.6.0-test3 and 2.6.0-test4. As I recall it was supposed to fix an issue with with PCI aborts being signalled by the PCI bridge of the Broadcom BCM1250 family of SOCs when probing behind pci_scan_bridge. It is undeseriable to disable PCI_BRIDGE_CTL_MASTER_ABORT in pci_{read,write)_config_* and the behaviour wasn't considered a bug in need of a workaround, so this was put in probe.c. I don't have an affected system at hand, so can't really test but I propose something like the below patch. [1] http://www.linux-mips.org/git?p=linux.git;a=commit;h=599457e0cb702a31a3247ea6a5d9c6c99c4cf195 [PCI] Avoid leaving MASTER_ABORT disabled permanently when returning from pci_scan_bridge. Signed-off-by:Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Andi Kleen authored
I moved it to a separate function which is safer. This avoids problems with the linker reordering them and the less useful PCI config space access methods taking priority over the better ones. Fixes some problems with broken MMCONFIG Cc: Dave Hansen <haveblue@us.ibm.com> Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
-
Kenji Kaneshige authored
Current SHPCHP driver has a bug in its interrupt handler which cause "IRQ #: nobody cared" oops. This problem can be reproduced easily by the following operation. # cd /sys/bus/pci/slots/<slot#> # while true; do echo 1 > attention ; done & The reason is that when command complete interrupt is raised, current SHPCHP driver's interrupt handler returns IRQ_NONE regardless of if the interrupt is handled or not. This patch fixes this issue. Signed-off-by: -
Kenji Kaneshige authored
This patch moves slot name area into struct slot. Signed-off-by:
-
Kenji Kaneshige authored
This patch removes unnecessary 'magic' member from struct slot of SHPCHP driver. Signed-off-by:
-
Kenji Kaneshige authored
This patch replaces kmalloc() and memset() pair with kzalloc() and cleans up the arg of sizeof() in SHPCHP driver. Signed-off-by:
-
Kenji Kaneshige authored
This patch cleans up pcihp_skelton.c as follows. o Move slot name area into struct slot. o Replace kmalloc with kzalloc and clean up the arg of sizeof() o Fix the wrong use of get_*_status() functions. Signed-off-by:
-
Kenji Kaneshige authored
Current shpchp driver might cause system panic because of lack of serialization. It can be reproduced very easily by the following operation. # cd /sys/bus/pci/slots/<slot#> # while true; do echo 0 > power ; echo 1 > power ; done & # while true; do echo 0 > power ; echo 1 > power ; done & This patch fixes this issue by changing shpchp to get appropreate semaphore for hot-plug operation. Signed-off-by:
-
Kenji Kaneshige authored
This patch cleanups codes that check the command status. For this, it introduces a new semaphore "cmd_sem" for each controller. Signed-off-by:
-
Kenji Kaneshige authored
This patch changes SHPCHP driver to use list_head structure for managing controller list. Signed-off-by:
-
Kenji Kaneshige authored
This patch changes SHPCHP driver to use list_head structure for managing slot list. Signed-off-by:
-
Kenji Kaneshige authored
This patch cleanups some codes in shpchp_core.c. This patch has no functional changes. Signed-off-by:
-
Kenji Kaneshige authored
This patch cleanups init_slots() function of SHPCHP driver based on pcihp_skelton.c. This patch has no functional change. Signed-off-by:
-
Ingo Molnar authored
semaphore to mutex conversion. the conversion was generated via scripts, and the result was validated automatically via a script as well. build tested with allyesconfig. Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Kristen Accardi authored
The IBM Dock II cardbus bridges require some extra configuration before Yenta is loaded in order to setup the Interrupts to be routed properly. Signed-off-by:
-
Kristen Accardi authored
After you find the maximum value of the subordinate buses below the child bus, you must fix the parent's subordinate bus number again, otherwise it may be too small. Signed-off-by:
-
Kristen Accardi authored
Change the semantics of this call to return the max reserved bus number instead of just the max assigned bus number. Signed-off-by:
-
Grant Grundler authored
Clean up: move assignments outside of if() statements. AFAICT, no functional change. Easier to read/understand. Depends on "[PATCH 1/3] msi vector targeting abstractions" by Mark Maule <maule@sgi.com>. I expect one hunk to fail if applied against 2.6.15. This is essentially Joe Perches' patch. I've cleaned up the one instance added by Mark's patch. Signed-off-by:
Grant Grundler <grundler@parisc-linux.org> Signed-off-by:
-
Benjamin LaHaise authored
The biovec default mempool limit of 256 entries results in over 3MB of RAM being permanently pinned, even on systems with only 128MB of RAM. Since mempool tries to allocate from the system pool first, it makes sense to reduce the size of the mempool fallbacks to a more reasonable limit of 1-5 entries -- enough for the system to be able to make progress even under load. Signed-off-by:
Benjamin LaHaise <bcrl@kvack.org> Acked-by:
Jens Axboe <axboe@suse.de> Cc: Matt Mackall <mpm@selenic.com> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Eric Dumazet authored
Now CONFIG_DEBUG_INITDATA is in, initial percpu data [__per_cpu_start,__per_cpu_end] can be declared as a redzone, and invalid accesses after boot can be detected, at least for i386. We can let non possible cpus percpu data point to this 'redzone' instead of NULL . NULL was not a good choice because part of [0..32768] memory may be readable and invalid accesses may happen unnoticed. If CONFIG_DEBUG_INITDATA is not defined, each non possible cpu points to the initial percpu data (__per_cpu_offset[cpu] == 0), thus invalid accesses wont be detected/crash. This patch also moves __per_cpu_offset[] to read_mostly area to avoid false sharing. Signed-off-by:
Eric Dumazet <dada1@cosmosbay.com> Signed-off-by:
-
Andrew Morton authored
When we stop allocating percpu memory for not-possible CPUs we must not touch the percpu data for not-possible CPUs at all. The correct way of doing this is to test cpu_possible() or to use for_each_cpu(). This patch is a kernel-wide sweep of all instances of NR_CPUS. I found very few instances of this bug, if any. But the patch converts lots of open-coded test to use the preferred helper macros. Cc: Mikael Starvik <starvik@axis.com> Cc: David Howells <dhowells@redhat.com> Acked-by:
Kyle McMartin <kyle@parisc-linux.org> Cc: Anton Blanchard <anton@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Paul Mundt <lethal@linux-sh.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: William Lee Irwin III <wli@holomorphy.com> Cc: Andi Kleen <ak@muc.de> Cc: Christian Zankel <chris@zankel.net> Cc: Philippe Elie <phil.el@wanadoo.fr> Cc: Nathan Scott <nathans@sgi.com> Cc: Jens Axboe <axboe@suse.de> Cc: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by:
-
Eric Dumazet authored
percpu_data blindly allocates bootmem memory to store NR_CPUS instances of cpudata, instead of allocating memory only for possible cpus. This patch saves ram, allocating num_possible_cpus() (instead of NR_CPUS) instances. Signed-off-by:
"David S. Miller" <davem@davemloft.net> Cc: James Bottomley <James.Bottomley@steeleye.com> Cc: Jens Axboe <axboe@suse.de> Acked-by:
William Irwin <wli@holomorphy.com> Signed-off-by:
-
