Hi Dmitry,
These are looking good to me.
You mention error handling in relation to vme_master_mmap, am I right in
thinking patch 3 avoids errors being recorded when triggered by an mmap
access (so as not to appear as a spurious error on a later access)?
I think it would be worth at least logging errors to the kernel log
should they be generated and not be handled by a error handler, so
someone using mmap gets at least some form of notification that their
accesses are resulting on bus errors. What do you think?
Martyn
On 02/07/15 15:11, Dmitry Kalinkin wrote:
This moves tsi148 error handling into VME subsystem so it can be shared with
the other bridge driver. Then there is a change to close a fixme on separating
errors by address space. And finally a fix for memory leak problem that was
introduced with support of mmap's.
The next logical step in this direction would be to add error handling support
to ca91cx42 and make it unconditional for tsi148. It also makes much sense to
add synchronization to error-related list operations (spinlocks, rcu).
Dmitry Kalinkin (3):
vme: move tsi148 error handling into VME subsystem
vme: include address space in error filtering
vme: change bus error handling scheme
drivers/vme/bridges/vme_ca91cx42.c | 3 +-
drivers/vme/bridges/vme_tsi148.c | 170 ++++++++++---------------------------
drivers/vme/vme.c | 83 ++++++++++++++++++
drivers/vme/vme_bridge.h | 21 +++--
4 files changed, 147 insertions(+), 130 deletions(-)
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.welch@xxxxxx | VAT:GB 927559189
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
