- 13 Mar, 2009 16 commits
-
-
David Miller authored
In compat mode, the cmdbuf->buf 64-bit address cookie can potentially be only 32-bit aligned. Dereferencing this as 64-bit causes expensive unaligned traps on platforms like sparc64. Use get_unaligned() to fix. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
David Miller authored
Platforms such as sparc64 have D-cache aliasing issues. We cannot allow virtual mappings in different contexts to be such that two cache lines can be loaded for the same backing data. Updates to one cache line won't be seen by accesses to the other cache line. Code in sparc64 and other architectures solve this problem by making sure that all userland mappings of MAP_SHARED objects have the same virtual address base. They implement this by keying off of the page offset, and using that to choose a suitably consistent virtual address for mmap() requests. Making things even worse, getting this wrong on sparc64 can result in hangs during DRM lock acquisition. This is because, at least on UltraSPARC-III, normal loads consult the D-cache but atomics such as 'cas' (which is what cmpxchg() is implement using) only consult the L2 cache. So if a D-cache alias is inserted, the load can see different data than the atomic, and we'll loop forever because the atomic compare-and-exchange will never complete successfully. So to make this all work properly, we need to make sure that the hash address computed by drm_map_handle() preserves the SHMLBA relevant bits, and that's what this patch does for _DRM_SHM mappings. As a historical note, many years ago this bug didn't exist because we used to just use the low 32-bits of the address as the hash and just hope for the best. This preserved the SHMLBA bits properly. But when the hashtab code was added to DRM, this was no longer the case. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
David Miller authored
The variable 'max_pages' is ambiguous. There are two concepts of "pages" being used in this function. First, we have ATI GART pages which are always 4096 bytes. Then, we have system pages which are of size PAGE_SIZE. Eliminate the confusion by creating max_ati_pages and max_real_pages. Calculate and use them as appropriate. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Dave Airlie <airlied@linux.ie>
-
David Miller authored
This allocates a physical surface for the PCI GART table, this way no matter what other surface configurations exist the GART table will always be seen by the hardware properly. We encode the file pointer of the virtual surface allocate using a special cookie value, called PCIGART_FILE_PRIV. On the last close, we release that surface. Just to be doubly safe, we run the pcigart table setup with the main surface control register clear. Based upon ideas from David Airlie and Ben Benjamin Herrenschmidt. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Dave Airlie <airlied@linux.ie>
-
David Miller authored
The address needs to be a GART relative address, rather than a PCI DMA address. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Dave Airlie <airlied@linux.ie>
-
David Miller authored
These are not supposed to be booleans, they are supposed to be bit masks. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Dave Airlie <airlied@linux.ie>
-
David Miller authored
The memory behind ring_rptr can either be in ioremapped memory or a vmalloc() normal kernel memory buffer. However, the code unconditionally uses DRM_{READ,WRITE}32() (and thus readl() and writel()) to access it. Basically, if RADEON_IS_AGP then it's ioremap()'d memory else it's vmalloc'd memory. Adjust all of the ring_rptr access code as needed. While we're here, kill the 'scratch' pointer in drm_radeon_private. It's only used in the one place where it is initialized. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Dave Airlie <airlied@linux.ie>
-
David Miller authored
The buffers mapped by the PCI GART can be written to by the device, not just read. For example, this happens via the RB_RPTR writeback on Radeon. So we can't use PCI_DMA_TODEVICE else we'll get protection faults on IOMMU platforms. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Dave Airlie <airlied@linux.ie>
-
David Miller authored
The PCI GART table initialization code treats the GART table mapping unconditionally as a kernel virtual address. But it could be in the framebuffer, for example, and thus we're dealing with a PCI MEM space ioremap() cookie. Treating that as a virtual address is illegal and will crash some system types (such as sparc64 where the ioremap() return value is actually a physical I/O address). So access the area correctly, using gart_info->gart_table_location as our guide. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Dave Airlie <airlied@linux.ie>
-
Kristian Høgsberg authored
The kernel shouldn't be in the business of telling user space which driver to load. The kernel defers mapping PCI IDs to module names to user space and we should do the same for DRI drivers. And in fact, that's how it does work today. Nothing uses the dri_library_name attribute, and the attribute is in fact broken. For intel devices, it falls back to the default behaviour of returning the kernel module name as the DRI driver name, which doesn't work for i965 devices. Nobody has ever hit this problem or filed a bug about this. Signed-off-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Dave Airlie <airlied@linux.ie>
-
Kristian Høgsberg authored
Under kernel modesetting, we manage the device at all times, regardless of VT switching and X servers, so the only decent thing to do is to claim the PCI device. In that case, we call the suspend/resume hooks directly from the pci driver hooks instead of the current class device detour. Signed-off-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Dave Airlie <airlied@linux.ie>
-
Benjamin Herrenschmidt authored
This changes drm_local_map to use a resource_size for its "offset" member instead of an unsigned long, thus allowing 32-bit machines with a >32-bit physical address space to be able to store there their register or framebuffer addresses when those are above 4G, such as when using a PCI video card on a recent AMCC 440 SoC. This patch isn't as "trivial" as it sounds: A few functions needed to have some unsigned long/int changed to resource_size_t and a few printk's had to be adjusted. But also, because userspace isn't capable of passing such offsets, I had to modify drm_find_matching_map() to ignore the offset passed in for maps of type _DRM_FRAMEBUFFER or _DRM_REGISTERS. If we ever support multiple _DRM_FRAMEBUFFER or _DRM_REGISTERS maps for a given device, we might have to change that trick, but I don't think that happens on any current driver. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Dave Airlie <airlied@linux.ie>
-
Benjamin Herrenschmidt authored
Once upon a time, the DRM made the distinction between the drm_map data structure exchanged with user space and the drm_local_map used in the kernel. For some reasons, while the BSD port still has that "feature", the linux part abused drm_map for kernel internal usage as the local map only existed as a typedef of the struct drm_map. This patch fixes it by declaring struct drm_local_map separately (though its content is currently identical to the userspace variant), and changing the kernel code to only use that, except when it's a user<->kernel interface (ie. ioctl). This allows subsequent changes to the in-kernel format I've also replaced the use of drm_local_map_t with struct drm_local_map in a couple of places. Mostly by accident but they are the same (the former is a typedef of the later) and I have some remote plans and half finished patch to completely kill the drm_local_map_t typedef so I left those bits in. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@linux.ie>
-
Benjamin Herrenschmidt authored
The DRM uses its own wrappers to obtain resources from PCI devices, which currently convert the resource_size_t into an unsigned long. This is broken on 32-bit platforms with >32-bit physical address space. This fixes them, along with a few occurences of unsigned long used to store such a resource in drivers. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Dave Airlie <airlied@linux.ie>
-
Linus Torvalds authored
-
Linus Torvalds authored
Guennadi Liakhovetski noticed that the end condition for the loop in bitmap_find_free_region() is wrong, and the "return if error" was also using the wrong conditional that would only trigger if the bitmap was an exact multiple of the allocation size, which is not necessarily the case with dma_alloc_from_coherent(). Such a failure would end up in bitmap_find_free_region() accessing beyond the end of the bitmap. Reported-by: Guennadi Liakhovetski <lg@denx.de> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
- 12 Mar, 2009 24 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild-fixesLinus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild-fixes: kbuild: remove unused -r option for module-init-tool depmod kbuild: fix 'make rpm' when CONFIG_LOCALVERSION_AUTO=y and using SCM tree kbuild: fix mkspec to cleanup RPM_BUILD_ROOT kbuild: fix C libary confusion in unifdef.c due to getline()
-
git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linusLinus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus: cpumask: mm_cpumask for accessing the struct mm_struct's cpu_vm_mask. cpumask: tsk_cpumask for accessing the struct task_struct's cpus_allowed.
-
git://git.kernel.org/pub/scm/linux/kernel/git/pkl/squashfs-linusLinus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/pkl/squashfs-linus: Squashfs: Valid filesystems are flagged as bad by the corrupted fs patch
-
git://jdelvare.pck.nerim.net/jdelvare-2.6Linus Torvalds authored
* 'hwmon-for-linus' of git://jdelvare.pck.nerim.net/jdelvare-2.6: hwmon: (f75375s) Remove unnecessary and confusing initialization hwmon: (it87) Properly decode -128 degrees C temperature hwmon: (lm90) Document support for the MAX6648/6692 chips hwmon: (abituguru3) Fix I/O error handling
-
Jody McIntyre authored
Trivial patch to fix bad links in the ext2 and ext3 documentation. Signed-off-by: Jody McIntyre <scjody@sun.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/willy/pciLinus Torvalds authored
* 'fixes-20090312' of git://git.kernel.org/pub/scm/linux/kernel/git/willy/pci: PCIe: portdrv: call pci_disable_device during remove pci: Fix typo in message while disabling HT MSI mapping pci: don't disable too many HT MSI mapping powerpc/pseries: The RPA PCI hotplug driver depends on EEH PCIe: AER: during disable, check subordinate before walking PCI: Add PCI quirk to disable L0s ASPM state for 82575 and 82598
-
Faisal Latif authored
STag zero is a special STag that allows consumers to access any bus address without registering memory. The nes driver unfortunately allows STag zero to be used even with QPs created by unprivileged userspace consumers, which means that any process with direct verbs access to the nes device can read and write any memory accessible to the underlying PCI device (usually any memory in the system). Such access is usually given for cluster software such as MPI to use, so this is a local privilege escalation bug on most systems running this driver. The driver was using STag zero to receive the last streaming mode data; to allow STag zero to be disabled for unprivileged QPs, the driver now registers a special MR for this data. Cc: <stable@kernel.org> Signed-off-by: Faisal Latif <faisal.latif@intel.com> Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Nick Piggin authored
There was a report of a data corruption http://lkml.org/lkml/2008/11/14/121. There is a script included to reproduce the problem. During testing, I encountered a number of strange things with ext3, so I tried ext2 to attempt to reduce complexity of the problem. I found that fsstress would quickly hang in wait_on_inode, waiting for I_LOCK to be cleared, even though instrumentation showed that unlock_new_inode had already been called for that inode. This points to memory scribble, or synchronisation problme. i_state of I_NEW inodes is not protected by inode_lock because other processes are not supposed to touch them until I_LOCK (and I_NEW) is cleared. Adding WARN_ON(inode->i_state & I_NEW) to sites where we modify i_state revealed that generic_sync_sb_inodes is picking up new inodes from the inode lists and passing them to __writeback_single_inode without waiting for I_NEW. Subsequently modifying i_state causes corruption. In my case it would look like this: CPU0 CPU1 unlock_new_inode() __sync_single_inode() reg <- inode->i_state reg -> reg & ~(I_LOCK|I_NEW) reg <- inode->i_state reg -> inode->i_state reg -> reg | I_SYNC reg -> inode->i_state Non-atomic RMW on CPU1 overwrites CPU0 store and sets I_LOCK|I_NEW again. Fix for this is rather than wait for I_NEW inodes, just skip over them: inodes concurrently being created are not subject to data integrity operations, and should not significantly contribute to dirty memory either. After this change, I'm unable to reproduce any of the added warnings or hangs after ~1hour of running. Previously, the new warnings would start immediately and hang would happen in under 5 minutes. I'm also testing on ext3 now, and so far no problems there either. I don't know whether this fixes the problem reported above, but it fixes a real problem for me. Cc: "Jorge Boncompte [DTI2]" <jorge@dti2.net> Reported-by: Adrian Hunter <ext-adrian.hunter@nokia.com> Cc: Jan Kara <jack@suse.cz> Cc: <stable@kernel.org> Signed-off-by: Nick Piggin <npiggin@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
KOSAKI Motohiro authored
Even when page reclaim is under mem_cgroup, # of scan page is determined by status of global LRU. Fix that. Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> Cc: Balbir Singh <balbir@in.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Mark Brown authored
No software visible difference from revision A. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Samuel Ortiz <sameo@openedhand.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Michael Spang authored
Currently we disable the Acer WMI backlight device if there is no ACPI backlight device. As a result, we end up with no backlight device at all. We should instead disable it if there is an ACPI device, as the other laptop drivers do. This regression was introduced in febf2d95 ("Acer-WMI: fingers off backlight if video.ko is serving this functionality"). Each laptop driver with backlight support got a similar change around febf2d95. The changes to the other drivers look correct; see e.g. a598c82f for a similar but correct change. The regression is also in 2.6.28. Signed-off-by: Michael Spang <mspang@csclub.uwaterloo.ca> Acked-by: Thomas Renninger <trenn@suse.de> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Carlos Corbacho <carlos@strangeworlds.co.uk> Cc: Len Brown <len.brown@intel.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: <stable@kernel.org> [2.6.28.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Ben Dooks authored
The s3cmci driver is calling s3c2410_dma_config with incorrect data for the DCON register. The S3C2410_DCON_HWTRIG is implicit in the channel configuration and the device selection of S3C2410_DCON_CH0_SDI is incorrect as the DMA system may not select channel 0. Signed-off-by: Ben Dooks <ben@simtec.co.uk> Acked-by: Pierre Ossman <drzeus@drzeus.cx> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Michael Kerrisk authored
Unfortunately, Linux Foundation funding for my work on man-pages/testing/doc under the auspices of the LF documentation fellowship unfortunately ran out a short while ago (after earlier attempts to seek funding, only Google stepped forward with a bit of further funding for the position), so the patch below acknowledges something closer to reality. Unfortunately, there will (probably very) soon be a further downgrade from "Maintained" to "Odd Fixes" or "Orphan", unless some funding miracle occurs. So, if anyone is looking to become man-pages maintainer, there may soon be an opening (okay, don't trample me in the rush ;-).) Signed-off-by: Michael Kerrisk <mtk.manpages@googlemail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Daniel Mack authored
The 'battery remaining capacity' calculation in drivers/power/ds2760_battery.c lacks a parameter check to a division operation which causes the kernel to oops on my board. [ 21.233750] Division by zero in kernel. [ 21.237646] [<c002955c>] (__div0+0x0/0x20) from [<c012561c>] (Ldiv0+0x8/0x10) [ 21.244816] [<c01bef34>] (ds2760_battery_read_status+0x0/0x2a4) from [<c01bf3a4>] (ds2760_battery_get_property+0x30/0xdc) [ 21.255803] r8:c03a22c0 r7:c7886100 r6:00000009 r5:c782fe7c r4:c7886084 [ 21.262518] [<c01bf374>] (ds2760_battery_get_property+0x0/0xdc) from [<c01bde98>] (power_supply_show_property+0x48/0x114) [ 21.273480] r6:c7996000 r5:00000009 r4:00000000 [ 21.278111] [<c01bde50>] (power_supply_show_property+0x0/0x114) from [<c01be158>] (power_supply_uevent+0x188/0x280) [ 21.288537] r8:00000001 r7:c7886100 r6:c7996000 r5:000000b4 r4:00000000 [ 21.295222] [<c01bdfd0>] (power_supply_uevent+0x0/0x280) from [<c015c664>] (dev_uevent+0xd4/0x10c) [ 21.304199] [<c015c590>] (dev_uevent+0x0/0x10c) from [<c0128440>] (kobject_uevent_env+0x180/0x390) [ 21.313170] r5:00000000 r4:c78860ac [ 21.316725] [<c01282c0>] (kobject_uevent_env+0x0/0x390) from [<c0128664>] (kobject_uevent+0x14/0x18) [ 21.325850] [<c0128650>] (kobject_uevent+0x0/0x18) from [<c01bdc34>] (power_supply_changed_work+0x5c/0x70) [ 21.335506] [<c01bdbd8>] (power_supply_changed_work+0x0/0x70) from [<c004d290>] (run_workqueue+0xbc/0x144) [ 21.345167] r4:c7812040 [ 21.347716] [<c004d1d4>] (run_workqueue+0x0/0x144) from [<c004d94c>] (worker_thread+0xa8/0xbc) [ 21.356296] r7:c7812040 r6:c7820b00 r5:c782ffa4 r4:c7812048 [ 21.361957] [<c004d8a4>] (worker_thread+0x0/0xbc) from [<c0051008>] (kthread+0x5c/0x94) [ 21.369971] r7:00000000 r6:c004d8a4 r5:c7812040 r4:c782e000 [ 21.375612] [<c0050fac>] (kthread+0x0/0x94) from [<c00403d0>] (do_exit+0x0/0x688) Signed-off-by: Daniel Mack <daniel@caiaq.de> Cc: Szabolcs Gyurko <szabolcs.gyurko@tlt.hu> Acked-by: Matt Reimer <mreimer@vpop.net> Acked-by: Anton Vorontsov <cbou@mail.ru> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Li Zefan authored
In sget(), destroy_super(s) is called with s->s_umount held, which makes lockdep unhappy. Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> Cc: Al Viro <viro@ZenIV.linux.org.uk> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Menage <menage@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Oleg Nesterov authored
If the second fasync_helper() fails, pipe_rdwr_fasync() returns the error but leaves the file on ->fasync_readers. This was always wrong, but since 233e70f4 "saner FASYNC handling on file close" we have the new problem. Because in this case setfl() doesn't set FASYNC bit, __fput() will not do ->fasync(0), and we leak fasync_struct with ->fa_file pointing to the freed file. Signed-off-by: Oleg Nesterov <oleg@redhat.com> Cc: Al Viro <viro@ZenIV.linux.org.uk> Cc: Andi Kleen <andi@firstfloor.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Daniel Mack authored
W1 master implementations are expected to return 0 or 1 from their read_bit() function. However, not all platforms do return these values from gpio_get_value() - namely PXAs won't. Hence the w1 gpio-master needs to break the result down to 0 or 1 itself. Signed-off-by: Daniel Mack <daniel@caiaq.de> Cc: Ville Syrjala <syrjala@sci.fi> Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
akpm@linux-foundation.org authored
Fix the following warning on x86_64: LD vmlinux.o MODPOST vmlinux.o WARNING: vmlinux: 'memcpy' exported twice. Previous export was in vmlinux For x86_64, this symbol is already exported from arch/um/sys-x86_64/ksyms.c. Reported-by: Boaz Harrosh <bharrosh@panasas.com> Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com> Tested-by: Boaz Harrosh <bharrosh@panasas.com> Cc: Jeff Dike <jdike@addtoit.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Renzo Davoli authored
It is currently impossible to run a user-mode linux machine inside another user-mode linux (UML on UML). It breaks after a few instructions. When it tries to check whether SYSEMU is installed (the inner) UML receives an inconsistent result (from the outer UML). This is the output of a broken attempt: $ ./linux mem=256m ubd0=cow Locating the bottom of the address space ... 0x0 Locating the top of the address space ... 0xc0000000 Core dump limits : soft - 0 hard - NONE Checking that ptrace can change system call numbers...OK Checking ptrace new tags for syscall emulation...unsupported Checking syscall emulation patch for ptrace...check_sysemu : expected SIGTRAP, got status = 256 $ The problem is the following: PTRACE_SYSCALL/SINGLESTEP is currently managed inside arch_ptrace for ARCH=um. PTRACE_SYSEMU/SUSEMU_SINGLESTEP is not captured in arch_ptrace's switch, therefore it is erroneously passed back to ptrace_request (in kernel/ptrace). This simple patch simply forces ptrace to return an error on PTRACE_SYSEMU/SUSEMU_SINGLESTEP as it is unsupported on ARCH=um, and fixes the problem. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Renzo Davoli <renzo@cs.unibo.it> Reviewed-by: WANG Cong <xiyou.wangcong@gmail.com> Cc: Jeff Dike <jdike@addtoit.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Alex Chiang authored
The PCIe port driver calls pci_enable_device() during probe but never calls pci_disable_device() during remove. Cc: stable@kernel.org Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
-
Prakash Punnoor authored
"Enabling" should read "Disabling" Signed-off-by: Prakash Punnoor <prakash@punnoor.de> Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
-
Prakash Punnoor authored
Prakash's system needs MSI disabled on some bridges, but not all. This seems to be the minimal fix for 2.6.29, but should be replaced during 2.6.30. Signed-off-by: Prakash Punnoor <prakash@punnoor.de> Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
-
Michael Ellerman authored
The RPA PCI hotplug driver calls EEH routines, so should depend on EEH. Also PPC_PSERIES implies PPC64, so remove that. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
-
Alex Chiang authored
Commit 47a8b0cc (Enable PCIe AER only after checking firmware support) wants to walk the PCI bus in the remove path to disable AER, and calls pci_walk_bus for downstream bridges. Unfortunately, in the remove path, we remove devices and bridges in a depth-first manner, starting with the furthest downstream bridge and working our way backwards. The furthest downstream bridges will not have a dev->subordinate, and we hit a NULL deref in pci_walk_bus. Check for dev->subordinate first before attempting to walk the PCI hierarchy below us. Acked-by: Andrew Patterson <andrew.patterson@hp.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
-