Some delayed initialization is performed in this driver. Make sure
resources that are used during driver clean-up (e.g. during driver's
release() function) are fully initialized before first use. This is
particularly important for the case when the delayed initialization
isn't completed, leaving behind a partially initialized driver.
Such a scenario can occur when RAR is not available on the platform,
and the driver is release()d.
Signed-off-by: Ossama Othman <ossama.othman@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fixed several witespace and tab related warnings and errors reported by the
chechpatch.pl tool.
Signed-off-by: Matti Lammi <mattij.lammi@gmail.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alan said that memrar should depend on RAR_REGISTER
(instead of selecting it).
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Ossama Othman <ossama.othman@intel.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
rar: perform a clean up pass
- Move to a registration model where each RAR is claimed/unclaimed
- Use that to fix the client stuff (one client per RAR so no need to queue stuff)
- Support unregister so drivers can rmmod themselves safely
- Fix locking hang on calling rar lock from rar callback
- Clean up
- Kerneldoc
Folded in the memrar update as Greg asked
- Fix various unload related bugs
- Use the per RAR allocator/deallocator
- Add kerneldoc
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fix printk format warning in memrar:
drivers/staging/memrar/memrar_handler.c:393: warning: format '%u' expects type 'unsigned int', but argument 4 has type 'size_t'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Ossama Othman <ossama.othman@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The Intel Restricted Access Region Handler provides a buffer allocation
mechanism to RAR users. Since the intended usage model is to lock out
CPU access to RAR (the CPU will not be able to access RAR memory), this
driver does not access RAR memory, and merely keeps track of what areas
of RAR memory are in use. It has it's own simple allocator that does
not rely on existing kernel allocators (SLAB, etc) since those
allocators are too tightly coupled with the paging mechanism, which isn't
needed for the intended RAR use cases.
An mmap() implementation is provided for debugging purposes to simplify
RAR memory access from the user space. However, it will effectively be
a no-op when RAR access control is enabled since the CPU will not be
able to access RAR.
This driver should not be confused with the rar_register driver. That
driver exposes an interface to access RAR registers on the Moorestown
platform. The RAR handler driver relies on the rar_register driver for
low level RAR register reads and writes.
This patch was generated and built against the latest linux-2.6 master
branch.
Signed-off-by: Ossama Othman <ossama.othman@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
