buf_unalloc() frees the memory buffers allocated with vme_alloc_consistent.
The associated VME resource is needed in both vme_alloc_consistent and
vme_free_consistent; however the slave VME resources are being freed before
the calls to vme_free_consistent are made, which means the buffers
are never returned.
Fix this by freeing the VME resources only after the consistent buffers have
been returned.
Signed-off-by: Emilio G. Cota <cota@braap.org>
Acked-by: Martyn Welch <martyn.welch@ge.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
kern_buf is not iomem; it comes from kmalloc and is directly
dereferenced.
Signed-off-by: Emilio G. Cota <cota@braap.org>
Acked-by: Martyn Welch <martyn.welch@ge.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
tsi148_irq_exit is called twice in .remove, which causes an oops.
Remove the second call, which apart from being redundant cannot
possibly work; the CR/CSR space has been already unmapped.
Signed-off-by: Emilio G. Cota <cota@braap.org>
Acked-by: Martyn Welch <martyn.welch@ge.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
From a95892fc2246d6dc45f57b7dd68f32b9b28bd0f7 Mon Sep 17 00:00:00 2001
From: Arthur Benilov <arthur.benilov@gmail.com>
Date: Fri, 24 Sep 2010 13:51:07 +0200
Subject: [PATCH] Staging: vme: Assure D16 cycle if required in master_read and master_write
memcpy_fromio() and memcpy_toio() functions apply internally to __memcpy() that
performs data transfer in 32-bits or 8-bits blocks (at least on x86). This makes
impossible to perform D16 cycle with ca91cx42 bridge. Provided modification
assures performing data transfer with 32, 16, and 8 bits chunks.
Signed-off-by: Arthur Benilov <arthur.benilov@iba-group.com>
Signed-off-by: Martyn Welch <martyn.welch@ge.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
All these files use the big kernel lock in a trivial
way to serialize their private file operations,
typically resulting from an earlier semi-automatic
pushdown from VFS.
None of these drivers appears to want to lock against
other code, and they all use the BKL as the top-level
lock in their file operations, meaning that there
is no lock-order inversion problem.
Consequently, we can remove the BKL completely,
replacing it with a per-file mutex in every case.
Using a scripted approach means we can avoid
typos.
file=$1
name=$2
if grep -q lock_kernel ${file} ; then
if grep -q 'include.*linux.mutex.h' ${file} ; then
sed -i '/include.*<linux\/smp_lock.h>/d' ${file}
else
sed -i 's/include.*<linux\/smp_lock.h>.*$/include <linux\/mutex.h>/g' ${file}
fi
sed -i ${file} \
-e "/^#include.*linux.mutex.h/,$ {
1,/^\(static\|int\|long\)/ {
/^\(static\|int\|long\)/istatic DEFINE_MUTEX(${name}_mutex);
} }" \
-e "s/\(un\)*lock_kernel\>[ ]*()/mutex_\1lock(\&${name}_mutex)/g" \
-e '/[ ]*cycle_kernel_lock();/d'
else
sed -i -e '/include.*\<smp_lock.h\>/d' ${file} \
-e '/cycle_kernel_lock()/d'
fi
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Namhyung Kim
Emilio G. Cota
Arthur Benilov
Thomas Gleixner
Arnd Bergmann