[Acx100-devel] [PATCH 10/19] inlines.h: #ifdef, comment cleanup

[Jim C. <jim...@gm...>]

- #ifdef guard: use correct guard name
- fixup comment grammar
- drop some obsolete comments
- change code-fence to not match with git's conflict markers

Signed-off-by: Jim Cromie <jim...@gm...>
---
 inlines.h | 51 +++++++++++++++++++--------------------------------
 1 file changed, 19 insertions(+), 32 deletions(-)

diff --git a/inlines.h b/inlines.h
index deb256a..b62f1c3 100644
--- a/inlines.h
+++ b/inlines.h
@@ -1,29 +1,20 @@
-#ifndef _MEM_INLINES_H_
-#define _MEM_INLINES_H_
+#ifndef _INLINES_H_
+#define _INLINES_H_
 
-/* currently need this even for no-mem builds, as it contains the
- * locking elements used in merge.c. TBD whether its worth
- * repartitioning to achieve this
- */
-#if defined(CONFIG_ACX_MAC80211_MEM) || 1
-
-/*
+/* ##################################################
  * BOM Data Access
  * Locking in mem
- * ==================================================
- */
-
-/*
- * Locking in mem is more complex as for pci, because the different
+ *
+ * Locking in mem is more complex than for pci, because the different
  * data-access functions below need to be protected against incoming
  * interrupts.
  *
- * Data-access on the mem device is always going in serveral,
- * none-atomic steps, involving 2 or more register writes
- * (e.g. ACX_SLV_REG_ADDR, ACX_SLV_REG_DATA).
+ * Data-access on the mem device is always going in several non-atomic
+ * steps, involving 2 or more register writes (e.g. ACX_SLV_REG_ADDR,
+ * ACX_SLV_REG_DATA).
  *
  * If an interrupt is serviced while a data-access function is
- * ongoing, this may give access interference with by the involved
+ * ongoing, this may cause access interference with the involved
  * operations, since the irq routine is also using the same
  * data-access functions.
  *
@@ -43,14 +34,14 @@
  * accesses well enough, that simple driver operation without
  * inbetween scans work without problems.
  *
- * Different locking approaches a possible to solves this (e.g. fine
+ * Different locking approaches are possible to solve this (e.g. fine
  * vs coarse-grained).
  *
  * The chosen approach is:
  *
- * 1) Mem.c data-access functions contain all a check to insure, they
- * are executed under the acx-spinlock.  => This is the red line that
- * tells, if something needs coverage.
+ * 1) Mem.c data-access functions all contain a check to insure that
+ * they are executed under the acx-spinlock.  => This is the red line
+ * that tells, if something needs coverage.
  *
  * 2) The scope of acx-spinlocking is local, in this case here only to
  * mem.c.  All common.c functions are already protected by the sem.
@@ -61,20 +52,17 @@
  *
  * a) as coarse-grained as possible, and ...
  *
- * b) ... as fine-grained as required. Basically that means, that
- * before functions, that sleep, unlocking needs to be done. And
- * locking is taken up again inside the sleeping
- * function. Specifically the cmd-functions are used in this path.
+ * b) ... as fine-grained as required.  Basically that means that
+ * before functions that sleep are called, unlocking needs to be done.
+ * And locks are taken again inside the sleeping function.
+ * Specifically the cmd-functions are used in this path.
  *
  * Once stable, the locking checks in the data-access functions could
- * be #defined away. Mem.c is anyway more used two smaller cpus (pxa
+ * be #defined away.  Mem.c is anyway more used two smaller cpus (pxa
  * UP e.g.), so the implied runtime constraints by the lock won't take
  * much effect.
  */
 
-/* These are used in many mem.c funcs, including those which should be
- * merged with their pci counterparts.
- */
 #define acxmem_lock_flags	unsigned long flags = 0
 #define acxmem_lock()						\
 	if (IS_MEM(adev))					\
@@ -447,5 +435,4 @@ INLINE_IO u16 read_slavemem16(acx_device_t *adev, u32 slave_address)
 	return val;
 }
 
-#endif /* CONFIG_ACX_MAC80211_MEM */
-#endif /* _MEM_INLINES_H_ */
+#endif /* _INLINES_H_ */
-- 
1.7.10.1.487.ga3935e6