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.we...@ge.com | VAT:GB 927559189 _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
