[PATCH v4 4/4] firmware: remove warning at documentation generation time
This patch removes following error at for `make htmldocs`. No functional change. ./drivers/base/firmware_class.c:1348: WARNING: Bullet list ends without a blank line; unexpected unindent. Signed-off-by: Silvio Fricke <silvio.fri...@gmail.com> Reviewed-by: Mauro Carvalho Chehab <mche...@s-opensource.com> --- drivers/base/firmware_class.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c index 22d1760..37b0221 100644 --- a/drivers/base/firmware_class.c +++ b/drivers/base/firmware_class.c @@ -1345,9 +1345,9 @@ static void request_firmware_work_func(struct work_struct *work) * * Asynchronous variant of request_firmware() for user contexts: * - sleep for as small periods as possible since it may - * increase kernel boot time of built-in device drivers - * requesting firmware in their ->probe() methods, if - * @gfp is GFP_KERNEL. + * increase kernel boot time of built-in device drivers + * requesting firmware in their ->probe() methods, if + * @gfp is GFP_KERNEL. * * - can't sleep at all if @gfp is GFP_ATOMIC. **/ -- git-series 0.9.1
[PATCH v4 4/4] firmware: remove warning at documentation generation time
This patch removes following error at for `make htmldocs`. No functional change. ./drivers/base/firmware_class.c:1348: WARNING: Bullet list ends without a blank line; unexpected unindent. Signed-off-by: Silvio Fricke Reviewed-by: Mauro Carvalho Chehab --- drivers/base/firmware_class.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c index 22d1760..37b0221 100644 --- a/drivers/base/firmware_class.c +++ b/drivers/base/firmware_class.c @@ -1345,9 +1345,9 @@ static void request_firmware_work_func(struct work_struct *work) * * Asynchronous variant of request_firmware() for user contexts: * - sleep for as small periods as possible since it may - * increase kernel boot time of built-in device drivers - * requesting firmware in their ->probe() methods, if - * @gfp is GFP_KERNEL. + * increase kernel boot time of built-in device drivers + * requesting firmware in their ->probe() methods, if + * @gfp is GFP_KERNEL. * * - can't sleep at all if @gfp is GFP_ATOMIC. **/ -- git-series 0.9.1
[PATCH v4 3/4] Documentation/atomic_ops.txt: convert to ReST markup
... and move to core-api folder.
Signed-off-by: Silvio Fricke <silvio.fri...@gmail.com>
---
Documentation/atomic_ops.txt => Documentation/core-api/atomic_ops.rst | 324
++--
Documentation/core-api/index.rst | 1 +-
Documentation/process/volatile-considered-harmful.rst | 3 +-
3 files changed, 175 insertions(+), 153 deletions(-)
diff --git a/Documentation/atomic_ops.txt
b/Documentation/core-api/atomic_ops.rst
similarity index 73%
rename from Documentation/atomic_ops.txt
rename to Documentation/core-api/atomic_ops.rst
index 6c5e8a9..55e43f1 100644
--- a/Documentation/atomic_ops.txt
+++ b/Documentation/core-api/atomic_ops.rst
@@ -1,36 +1,42 @@
- Semantics and Behavior of Atomic and
-Bitmask Operations
+===
+Semantics and Behavior of Atomic and Bitmask Operations
+===
- David S. Miller
+:Author: David S. Miller
- This document is intended to serve as a guide to Linux port
+This document is intended to serve as a guide to Linux port
maintainers on how to implement atomic counter, bitops, and spinlock
interfaces properly.
- The atomic_t type should be defined as a signed integer and
+Atomic Type And Operations
+==
+
+The atomic_t type should be defined as a signed integer and
the atomic_long_t type as a signed long integer. Also, they should
be made opaque such that any kind of cast to a normal C integer type
-will fail. Something like the following should suffice:
+will fail. Something like the following should suffice::
typedef struct { int counter; } atomic_t;
typedef struct { long counter; } atomic_long_t;
Historically, counter has been declared volatile. This is now discouraged.
-See Documentation/process/volatile-considered-harmful.rst for the complete
rationale.
+See :ref:`Documentation/process/volatile-considered-harmful.rst
+` for the complete rationale.
local_t is very similar to atomic_t. If the counter is per CPU and only
updated by one CPU, local_t is probably more appropriate. Please see
-Documentation/local_ops.txt for the semantics of local_t.
+:ref:`Documentation/core-api/local_ops.rst ` for the semantics of
+local_t.
The first operations to implement for atomic_t's are the initializers and
-plain reads.
+plain reads. ::
#define ATOMIC_INIT(i) { (i) }
#define atomic_set(v, i)((v)->counter = (i))
-The first macro is used in definitions, such as:
+The first macro is used in definitions, such as::
-static atomic_t my_counter = ATOMIC_INIT(1);
+ static atomic_t my_counter = ATOMIC_INIT(1);
The initializer is atomic in that the return values of the atomic operations
are guaranteed to be correct reflecting the initialized value if the
@@ -38,10 +44,10 @@ initializer is used before runtime. If the initializer is
used at runtime, a
proper implicit or explicit read memory barrier is needed before reading the
value with atomic_read from another thread.
-As with all of the atomic_ interfaces, replace the leading "atomic_"
-with "atomic_long_" to operate on atomic_long_t.
+As with all of the ``atomic_`` interfaces, replace the leading ``atomic_``
+with ``atomic_long_`` to operate on atomic_long_t.
-The second interface can be used at runtime, as in:
+The second interface can be used at runtime, as in::
struct foo { atomic_t counter; };
...
@@ -59,7 +65,7 @@ been set with this operation or set with another operation.
A proper implicit
or explicit memory barrier is needed before the value set with the operation
is guaranteed to be readable with atomic_read from another thread.
-Next, we have:
+Next, we have::
#define atomic_read(v) ((v)->counter)
@@ -73,20 +79,21 @@ initialization by any other thread is visible yet, so the
user of the
interface must take care of that with a proper implicit or explicit memory
barrier.
-*** WARNING: atomic_read() and atomic_set() DO NOT IMPLY BARRIERS! ***
+.. warning::
-Some architectures may choose to use the volatile keyword, barriers, or inline
-assembly to guarantee some degree of immediacy for atomic_read() and
-atomic_set(). This is not uniformly guaranteed, and may change in the future,
-so all users of atomic_t should treat atomic_read() and atomic_set() as simple
-C statements that may be reordered or optimized away entirely by the compiler
-or processor, and explicitly invoke the appropriate compiler and/or memory
-barrier for each use case. Failure to do so will result in code that may
-suddenly break when used with different architectures or compiler
-optimizations, or even changes in unrelated code which changes how the
-compiler optimizes the s
[PATCH v4 3/4] Documentation/atomic_ops.txt: convert to ReST markup
... and move to core-api folder.
Signed-off-by: Silvio Fricke
---
Documentation/atomic_ops.txt => Documentation/core-api/atomic_ops.rst | 324
++--
Documentation/core-api/index.rst | 1 +-
Documentation/process/volatile-considered-harmful.rst | 3 +-
3 files changed, 175 insertions(+), 153 deletions(-)
diff --git a/Documentation/atomic_ops.txt
b/Documentation/core-api/atomic_ops.rst
similarity index 73%
rename from Documentation/atomic_ops.txt
rename to Documentation/core-api/atomic_ops.rst
index 6c5e8a9..55e43f1 100644
--- a/Documentation/atomic_ops.txt
+++ b/Documentation/core-api/atomic_ops.rst
@@ -1,36 +1,42 @@
- Semantics and Behavior of Atomic and
-Bitmask Operations
+===
+Semantics and Behavior of Atomic and Bitmask Operations
+===
- David S. Miller
+:Author: David S. Miller
- This document is intended to serve as a guide to Linux port
+This document is intended to serve as a guide to Linux port
maintainers on how to implement atomic counter, bitops, and spinlock
interfaces properly.
- The atomic_t type should be defined as a signed integer and
+Atomic Type And Operations
+==
+
+The atomic_t type should be defined as a signed integer and
the atomic_long_t type as a signed long integer. Also, they should
be made opaque such that any kind of cast to a normal C integer type
-will fail. Something like the following should suffice:
+will fail. Something like the following should suffice::
typedef struct { int counter; } atomic_t;
typedef struct { long counter; } atomic_long_t;
Historically, counter has been declared volatile. This is now discouraged.
-See Documentation/process/volatile-considered-harmful.rst for the complete
rationale.
+See :ref:`Documentation/process/volatile-considered-harmful.rst
+` for the complete rationale.
local_t is very similar to atomic_t. If the counter is per CPU and only
updated by one CPU, local_t is probably more appropriate. Please see
-Documentation/local_ops.txt for the semantics of local_t.
+:ref:`Documentation/core-api/local_ops.rst ` for the semantics of
+local_t.
The first operations to implement for atomic_t's are the initializers and
-plain reads.
+plain reads. ::
#define ATOMIC_INIT(i) { (i) }
#define atomic_set(v, i)((v)->counter = (i))
-The first macro is used in definitions, such as:
+The first macro is used in definitions, such as::
-static atomic_t my_counter = ATOMIC_INIT(1);
+ static atomic_t my_counter = ATOMIC_INIT(1);
The initializer is atomic in that the return values of the atomic operations
are guaranteed to be correct reflecting the initialized value if the
@@ -38,10 +44,10 @@ initializer is used before runtime. If the initializer is
used at runtime, a
proper implicit or explicit read memory barrier is needed before reading the
value with atomic_read from another thread.
-As with all of the atomic_ interfaces, replace the leading "atomic_"
-with "atomic_long_" to operate on atomic_long_t.
+As with all of the ``atomic_`` interfaces, replace the leading ``atomic_``
+with ``atomic_long_`` to operate on atomic_long_t.
-The second interface can be used at runtime, as in:
+The second interface can be used at runtime, as in::
struct foo { atomic_t counter; };
...
@@ -59,7 +65,7 @@ been set with this operation or set with another operation.
A proper implicit
or explicit memory barrier is needed before the value set with the operation
is guaranteed to be readable with atomic_read from another thread.
-Next, we have:
+Next, we have::
#define atomic_read(v) ((v)->counter)
@@ -73,20 +79,21 @@ initialization by any other thread is visible yet, so the
user of the
interface must take care of that with a proper implicit or explicit memory
barrier.
-*** WARNING: atomic_read() and atomic_set() DO NOT IMPLY BARRIERS! ***
+.. warning::
-Some architectures may choose to use the volatile keyword, barriers, or inline
-assembly to guarantee some degree of immediacy for atomic_read() and
-atomic_set(). This is not uniformly guaranteed, and may change in the future,
-so all users of atomic_t should treat atomic_read() and atomic_set() as simple
-C statements that may be reordered or optimized away entirely by the compiler
-or processor, and explicitly invoke the appropriate compiler and/or memory
-barrier for each use case. Failure to do so will result in code that may
-suddenly break when used with different architectures or compiler
-optimizations, or even changes in unrelated code which changes how the
-compiler optimizes the section accessing atomic_t var
[PATCH v4 2/4] Documentation/local_ops.txt: convert to ReST markup
... and move to core-api folder. Signed-off-by: Silvio Fricke <silvio.fri...@gmail.com> Reviewed-by: Mauro Carvalho Chehab <mche...@s-opensource.com> --- Documentation/core-api/index.rst| 1 +- Documentation/local_ops.txt => Documentation/core-api/local_ops.rst | 273 +++ 2 files changed, 145 insertions(+), 129 deletions(-) diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index 480d9a3..f53555e 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -8,6 +8,7 @@ Kernel and driver related documentation. :maxdepth: 1 assoc_array + local_ops workqueue .. only:: subproject diff --git a/Documentation/local_ops.txt b/Documentation/core-api/local_ops.rst similarity index 57% rename from Documentation/local_ops.txt rename to Documentation/core-api/local_ops.rst index 407576a..1062ddb 100644 --- a/Documentation/local_ops.txt +++ b/Documentation/core-api/local_ops.rst @@ -1,191 +1,206 @@ -Semantics and Behavior of Local Atomic Operations - Mathieu Desnoyers +.. _local_ops: += +Semantics and Behavior of Local Atomic Operations += - This document explains the purpose of the local atomic operations, how +:Author: Mathieu Desnoyers + + +This document explains the purpose of the local atomic operations, how to implement them for any given architecture and shows how they can be used properly. It also stresses on the precautions that must be taken when reading those local variables across CPUs when the order of memory writes matters. -Note that local_t based operations are not recommended for general kernel use. -Please use the this_cpu operations instead unless there is really a special purpose. -Most uses of local_t in the kernel have been replaced by this_cpu operations. -this_cpu operations combine the relocation with the local_t like semantics in -a single instruction and yield more compact and faster executing code. +.. note:: +Note that ``local_t`` based operations are not recommended for general +kernel use. Please use the ``this_cpu`` operations instead unless there is +really a special purpose. Most uses of ``local_t`` in the kernel have been +replaced by ``this_cpu`` operations. ``this_cpu`` operations combine the +relocation with the ``local_t`` like semantics in a single instruction and +yield more compact and faster executing code. -* Purpose of local atomic operations + +Purpose of local atomic operations +== Local atomic operations are meant to provide fast and highly reentrant per CPU counters. They minimize the performance cost of standard atomic operations by removing the LOCK prefix and memory barriers normally required to synchronize across CPUs. -Having fast per CPU atomic counters is interesting in many cases : it does not +Having fast per CPU atomic counters is interesting in many cases: it does not require disabling interrupts to protect from interrupt handlers and it permits coherent counters in NMI handlers. It is especially useful for tracing purposes and for various performance monitoring counters. Local atomic operations only guarantee variable modification atomicity wrt the CPU which owns the data. Therefore, care must taken to make sure that only one -CPU writes to the local_t data. This is done by using per cpu data and making -sure that we modify it from within a preemption safe context. It is however -permitted to read local_t data from any CPU : it will then appear to be written -out of order wrt other memory writes by the owner CPU. +CPU writes to the ``local_t`` data. This is done by using per cpu data and +making sure that we modify it from within a preemption safe context. It is +however permitted to read ``local_t`` data from any CPU: it will then appear to +be written out of order wrt other memory writes by the owner CPU. -* Implementation for a given architecture +Implementation for a given architecture +=== -It can be done by slightly modifying the standard atomic operations : only +It can be done by slightly modifying the standard atomic operations: only their UP variant must be kept. It typically means removing LOCK prefix (on i386 and x86_64) and any SMP synchronization barrier. If the architecture does -not have a different behavior between SMP and UP, including asm-generic/local.h -in your architecture's local.h is sufficient. +not have a different behavior between SMP and UP, including +``asm-generic/local.h`` in your architecture's ``local.h`` is sufficient. -The local_t type is defined as an opaque signed long by embedding an -atomic_long_t inside a structure. This is made so a cast from this type to a -long fails. The definition looks like : +The ``local_t``
[PATCH v4 2/4] Documentation/local_ops.txt: convert to ReST markup
... and move to core-api folder. Signed-off-by: Silvio Fricke Reviewed-by: Mauro Carvalho Chehab --- Documentation/core-api/index.rst| 1 +- Documentation/local_ops.txt => Documentation/core-api/local_ops.rst | 273 +++ 2 files changed, 145 insertions(+), 129 deletions(-) diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index 480d9a3..f53555e 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -8,6 +8,7 @@ Kernel and driver related documentation. :maxdepth: 1 assoc_array + local_ops workqueue .. only:: subproject diff --git a/Documentation/local_ops.txt b/Documentation/core-api/local_ops.rst similarity index 57% rename from Documentation/local_ops.txt rename to Documentation/core-api/local_ops.rst index 407576a..1062ddb 100644 --- a/Documentation/local_ops.txt +++ b/Documentation/core-api/local_ops.rst @@ -1,191 +1,206 @@ -Semantics and Behavior of Local Atomic Operations - Mathieu Desnoyers +.. _local_ops: += +Semantics and Behavior of Local Atomic Operations += - This document explains the purpose of the local atomic operations, how +:Author: Mathieu Desnoyers + + +This document explains the purpose of the local atomic operations, how to implement them for any given architecture and shows how they can be used properly. It also stresses on the precautions that must be taken when reading those local variables across CPUs when the order of memory writes matters. -Note that local_t based operations are not recommended for general kernel use. -Please use the this_cpu operations instead unless there is really a special purpose. -Most uses of local_t in the kernel have been replaced by this_cpu operations. -this_cpu operations combine the relocation with the local_t like semantics in -a single instruction and yield more compact and faster executing code. +.. note:: +Note that ``local_t`` based operations are not recommended for general +kernel use. Please use the ``this_cpu`` operations instead unless there is +really a special purpose. Most uses of ``local_t`` in the kernel have been +replaced by ``this_cpu`` operations. ``this_cpu`` operations combine the +relocation with the ``local_t`` like semantics in a single instruction and +yield more compact and faster executing code. -* Purpose of local atomic operations + +Purpose of local atomic operations +== Local atomic operations are meant to provide fast and highly reentrant per CPU counters. They minimize the performance cost of standard atomic operations by removing the LOCK prefix and memory barriers normally required to synchronize across CPUs. -Having fast per CPU atomic counters is interesting in many cases : it does not +Having fast per CPU atomic counters is interesting in many cases: it does not require disabling interrupts to protect from interrupt handlers and it permits coherent counters in NMI handlers. It is especially useful for tracing purposes and for various performance monitoring counters. Local atomic operations only guarantee variable modification atomicity wrt the CPU which owns the data. Therefore, care must taken to make sure that only one -CPU writes to the local_t data. This is done by using per cpu data and making -sure that we modify it from within a preemption safe context. It is however -permitted to read local_t data from any CPU : it will then appear to be written -out of order wrt other memory writes by the owner CPU. +CPU writes to the ``local_t`` data. This is done by using per cpu data and +making sure that we modify it from within a preemption safe context. It is +however permitted to read ``local_t`` data from any CPU: it will then appear to +be written out of order wrt other memory writes by the owner CPU. -* Implementation for a given architecture +Implementation for a given architecture +=== -It can be done by slightly modifying the standard atomic operations : only +It can be done by slightly modifying the standard atomic operations: only their UP variant must be kept. It typically means removing LOCK prefix (on i386 and x86_64) and any SMP synchronization barrier. If the architecture does -not have a different behavior between SMP and UP, including asm-generic/local.h -in your architecture's local.h is sufficient. +not have a different behavior between SMP and UP, including +``asm-generic/local.h`` in your architecture's ``local.h`` is sufficient. -The local_t type is defined as an opaque signed long by embedding an -atomic_long_t inside a structure. This is made so a cast from this type to a -long fails. The definition looks like : +The ``local_t`` type is defined as an opaque ``signed long`` by embedd
[PATCH v4 1/4] Documentation/assoc_array.txt: convert to ReST markup
... and move to Documentation/core-api folder. Signed-off-by: Silvio Fricke <silvio.fri...@gmail.com> Reviewed-by: Mauro Carvalho Chehab <mche...@s-opensource.com> --- Documentation/assoc_array.txt => Documentation/core-api/assoc_array.rst | 639 ++-- Documentation/core-api/index.rst| 1 +- 2 files changed, 309 insertions(+), 331 deletions(-) diff --git a/Documentation/assoc_array.txt b/Documentation/core-api/assoc_array.rst similarity index 46% rename from Documentation/assoc_array.txt rename to Documentation/core-api/assoc_array.rst index 2f2c6cd..dcda7c6 100644 --- a/Documentation/assoc_array.txt +++ b/Documentation/core-api/assoc_array.rst @@ -1,67 +1,46 @@ - - GENERIC ASSOCIATIVE ARRAY IMPLEMENTATION - + +Generic Associative Array Implementation + -Contents: - - - Overview. - - - The public API. - - Edit script. - - Operations table. - - Manipulation functions. - - Access functions. - - Index key form. - - - Internal workings. - - Basic internal tree layout. - - Shortcuts. - - Splitting and collapsing nodes. - - Non-recursive iteration. - - Simultaneous alteration and iteration. - - - -OVERVIEW +Overview This associative array implementation is an object container with the following properties: - (1) Objects are opaque pointers. The implementation does not care where they - point (if anywhere) or what they point to (if anything). - - [!] NOTE: Pointers to objects _must_ be zero in the least significant bit. +1. Objects are opaque pointers. The implementation does not care where they + point (if anywhere) or what they point to (if anything). +.. note:: Pointers to objects _must_ be zero in the least significant bit.** - (2) Objects do not need to contain linkage blocks for use by the array. This - permits an object to be located in multiple arrays simultaneously. - Rather, the array is made up of metadata blocks that point to objects. +2. Objects do not need to contain linkage blocks for use by the array. This + permits an object to be located in multiple arrays simultaneously. + Rather, the array is made up of metadata blocks that point to objects. - (3) Objects require index keys to locate them within the array. +3. Objects require index keys to locate them within the array. - (4) Index keys must be unique. Inserting an object with the same key as one - already in the array will replace the old object. +4. Index keys must be unique. Inserting an object with the same key as one + already in the array will replace the old object. - (5) Index keys can be of any length and can be of different lengths. +5. Index keys can be of any length and can be of different lengths. - (6) Index keys should encode the length early on, before any variation due to - length is seen. +6. Index keys should encode the length early on, before any variation due to + length is seen. - (7) Index keys can include a hash to scatter objects throughout the array. +7. Index keys can include a hash to scatter objects throughout the array. - (8) The array can iterated over. The objects will not necessarily come out in - key order. +8. The array can iterated over. The objects will not necessarily come out in + key order. - (9) The array can be iterated over whilst it is being modified, provided the - RCU readlock is being held by the iterator. Note, however, under these - circumstances, some objects may be seen more than once. If this is a - problem, the iterator should lock against modification. Objects will not - be missed, however, unless deleted. +9. The array can be iterated over whilst it is being modified, provided the + RCU readlock is being held by the iterator. Note, however, under these + circumstances, some objects may be seen more than once. If this is a + problem, the iterator should lock against modification. Objects will not + be missed, however, unless deleted. -(10) Objects in the array can be looked up by means of their index key. +10. Objects in the array can be looked up by means of their index key. -(11) Objects can be looked up whilst the array is being modified, provided the - RCU readlock is being held by the thread doing the look up. +11. Objects can be looked up whilst the array is being modified, provided the +RCU readlock is being held by the thread doing the look up. The implementation uses a tree of 16-pointer nodes internally that are indexed on each level by nibbles from the index key in the same manner as in a radix @@ -71,25 +50,26 @@ pack leaf object pointers into spare space in the node rather than making a
[PATCH v4 1/4] Documentation/assoc_array.txt: convert to ReST markup
... and move to Documentation/core-api folder. Signed-off-by: Silvio Fricke Reviewed-by: Mauro Carvalho Chehab --- Documentation/assoc_array.txt => Documentation/core-api/assoc_array.rst | 639 ++-- Documentation/core-api/index.rst| 1 +- 2 files changed, 309 insertions(+), 331 deletions(-) diff --git a/Documentation/assoc_array.txt b/Documentation/core-api/assoc_array.rst similarity index 46% rename from Documentation/assoc_array.txt rename to Documentation/core-api/assoc_array.rst index 2f2c6cd..dcda7c6 100644 --- a/Documentation/assoc_array.txt +++ b/Documentation/core-api/assoc_array.rst @@ -1,67 +1,46 @@ - - GENERIC ASSOCIATIVE ARRAY IMPLEMENTATION - + +Generic Associative Array Implementation + -Contents: - - - Overview. - - - The public API. - - Edit script. - - Operations table. - - Manipulation functions. - - Access functions. - - Index key form. - - - Internal workings. - - Basic internal tree layout. - - Shortcuts. - - Splitting and collapsing nodes. - - Non-recursive iteration. - - Simultaneous alteration and iteration. - - - -OVERVIEW +Overview This associative array implementation is an object container with the following properties: - (1) Objects are opaque pointers. The implementation does not care where they - point (if anywhere) or what they point to (if anything). - - [!] NOTE: Pointers to objects _must_ be zero in the least significant bit. +1. Objects are opaque pointers. The implementation does not care where they + point (if anywhere) or what they point to (if anything). +.. note:: Pointers to objects _must_ be zero in the least significant bit.** - (2) Objects do not need to contain linkage blocks for use by the array. This - permits an object to be located in multiple arrays simultaneously. - Rather, the array is made up of metadata blocks that point to objects. +2. Objects do not need to contain linkage blocks for use by the array. This + permits an object to be located in multiple arrays simultaneously. + Rather, the array is made up of metadata blocks that point to objects. - (3) Objects require index keys to locate them within the array. +3. Objects require index keys to locate them within the array. - (4) Index keys must be unique. Inserting an object with the same key as one - already in the array will replace the old object. +4. Index keys must be unique. Inserting an object with the same key as one + already in the array will replace the old object. - (5) Index keys can be of any length and can be of different lengths. +5. Index keys can be of any length and can be of different lengths. - (6) Index keys should encode the length early on, before any variation due to - length is seen. +6. Index keys should encode the length early on, before any variation due to + length is seen. - (7) Index keys can include a hash to scatter objects throughout the array. +7. Index keys can include a hash to scatter objects throughout the array. - (8) The array can iterated over. The objects will not necessarily come out in - key order. +8. The array can iterated over. The objects will not necessarily come out in + key order. - (9) The array can be iterated over whilst it is being modified, provided the - RCU readlock is being held by the iterator. Note, however, under these - circumstances, some objects may be seen more than once. If this is a - problem, the iterator should lock against modification. Objects will not - be missed, however, unless deleted. +9. The array can be iterated over whilst it is being modified, provided the + RCU readlock is being held by the iterator. Note, however, under these + circumstances, some objects may be seen more than once. If this is a + problem, the iterator should lock against modification. Objects will not + be missed, however, unless deleted. -(10) Objects in the array can be looked up by means of their index key. +10. Objects in the array can be looked up by means of their index key. -(11) Objects can be looked up whilst the array is being modified, provided the - RCU readlock is being held by the thread doing the look up. +11. Objects can be looked up whilst the array is being modified, provided the +RCU readlock is being held by the thread doing the look up. The implementation uses a tree of 16-pointer nodes internally that are indexed on each level by nibbles from the index key in the same manner as in a radix @@ -71,25 +50,26 @@ pack leaf object pointers into spare space in the node rather than making an extra branch until as such time an object needs to be ad
[PATCH v4 0/4] core-api ReST: assoc_array, atomic_ops, local_ops
Hi, Some more ReSTification of core-api's: assoc_array, atomic_ops and local_ops. A fourth patch removes a warning about a bullet list without ending at firmware_class.c v3 -> v4 * add Review-by comments * rewrite atomic_ops.rst file with fewer inversive changes * reorder patch series old(1,2,3,4) new(1,3,2,4) v2 -> v3 * change ". ::" to "::" * replace all "code-blocks" with "::" * add two ".. notes" declaration in atomic_ops.rst v1 -> v2 * use format-patch with a rename_threshold of 10%, no other changes Thanks for review. BR Silvio Silvio Fricke (4): Documentation/assoc_array.txt: convert to ReST markup Documentation/local_ops.txt: convert to ReST markup Documentation/atomic_ops.txt: convert to ReST markup firmware: remove warning at documentation generation time Documentation/assoc_array.txt => Documentation/core-api/assoc_array.rst | 639 ++-- Documentation/atomic_ops.txt => Documentation/core-api/atomic_ops.rst | 324 +++-- Documentation/core-api/index.rst| 3 +- Documentation/local_ops.txt => Documentation/core-api/local_ops.rst | 273 --- Documentation/process/volatile-considered-harmful.rst | 3 +- drivers/base/firmware_class.c | 6 +- 6 files changed, 632 insertions(+), 616 deletions(-) base-commit: 9c240d757658a3ae9968dd309e674c61f07c7f48 -- git-series 0.9.1
[PATCH v4 0/4] core-api ReST: assoc_array, atomic_ops, local_ops
Hi, Some more ReSTification of core-api's: assoc_array, atomic_ops and local_ops. A fourth patch removes a warning about a bullet list without ending at firmware_class.c v3 -> v4 * add Review-by comments * rewrite atomic_ops.rst file with fewer inversive changes * reorder patch series old(1,2,3,4) new(1,3,2,4) v2 -> v3 * change ". ::" to "::" * replace all "code-blocks" with "::" * add two ".. notes" declaration in atomic_ops.rst v1 -> v2 * use format-patch with a rename_threshold of 10%, no other changes Thanks for review. BR Silvio Silvio Fricke (4): Documentation/assoc_array.txt: convert to ReST markup Documentation/local_ops.txt: convert to ReST markup Documentation/atomic_ops.txt: convert to ReST markup firmware: remove warning at documentation generation time Documentation/assoc_array.txt => Documentation/core-api/assoc_array.rst | 639 ++-- Documentation/atomic_ops.txt => Documentation/core-api/atomic_ops.rst | 324 +++-- Documentation/core-api/index.rst| 3 +- Documentation/local_ops.txt => Documentation/core-api/local_ops.rst | 273 --- Documentation/process/volatile-considered-harmful.rst | 3 +- drivers/base/firmware_class.c | 6 +- 6 files changed, 632 insertions(+), 616 deletions(-) base-commit: 9c240d757658a3ae9968dd309e674c61f07c7f48 -- git-series 0.9.1
[PATCH v3 0/4] core-api ReST: assoc_array, atomic_ops, local_ops
Hi, Thanks Mauro and Jani for reviewing. Some more ReSTification of core-api's: assoc_array, atomic_ops and local_ops. A fourth patch removes a warning about a bullet list without ending at firmware_class.c v2 -> v3 * change ". ::" to "::" * replace all "code-blocks" with "::" * add two ".. notes" declaration in atomic_ops.rst v1 -> v2 * use format-patch with a rename_threshold of 10%, no other changes Thanks for review. BR Silvio Silvio Fricke (4): Documentation/assoc_array.txt: convert to ReST markup Documentation/atomic_ops.txt: convert to ReST markup Documentation/local_ops.txt: convert to ReST markup firmware: remove warning at documentation generation time Documentation/assoc_array.txt => Documentation/core-api/assoc_array.rst | 639 --- Documentation/atomic_ops.txt => Documentation/core-api/atomic_ops.rst | 777 +--- Documentation/core-api/index.rst| 3 +- Documentation/local_ops.txt => Documentation/core-api/local_ops.rst | 273 + Documentation/process/volatile-considered-harmful.rst | 3 +- drivers/base/firmware_class.c | 6 +- 6 files changed, 861 insertions(+), 840 deletions(-) base-commit: 9c240d757658a3ae9968dd309e674c61f07c7f48 -- git-series 0.9.1
[PATCH v3 2/4] Documentation/atomic_ops.txt: convert to ReST markup
... and move to core-api folder.
Signed-off-by: Silvio Fricke <silvio.fri...@gmail.com>
---
Documentation/atomic_ops.txt => Documentation/core-api/atomic_ops.rst | 777
+---
Documentation/core-api/index.rst | 1 +-
Documentation/process/volatile-considered-harmful.rst | 3 +-
3 files changed, 404 insertions(+), 377 deletions(-)
diff --git a/Documentation/atomic_ops.txt
b/Documentation/core-api/atomic_ops.rst
similarity index 46%
rename from Documentation/atomic_ops.txt
rename to Documentation/core-api/atomic_ops.rst
index 6c5e8a9..6236951 100644
--- a/Documentation/atomic_ops.txt
+++ b/Documentation/core-api/atomic_ops.rst
@@ -1,204 +1,212 @@
- Semantics and Behavior of Atomic and
-Bitmask Operations
+===
+Semantics and Behavior of Atomic and Bitmask Operations
+===
- David S. Miller
+:Author: David S. Miller
- This document is intended to serve as a guide to Linux port
+This document is intended to serve as a guide to Linux port
maintainers on how to implement atomic counter, bitops, and spinlock
interfaces properly.
- The atomic_t type should be defined as a signed integer and
-the atomic_long_t type as a signed long integer. Also, they should
+Atomic Type And Operations
+==
+
+The ``atomic_t type`` should be defined as a signed integer and
+the ``atomic_long_t`` type as a signed long integer. Also, they should
be made opaque such that any kind of cast to a normal C integer type
-will fail. Something like the following should suffice:
+will fail. Something like the following should suffice::
- typedef struct { int counter; } atomic_t;
- typedef struct { long counter; } atomic_long_t;
+typedef struct { int counter; } atomic_t;
+typedef struct { long counter; } atomic_long_t;
Historically, counter has been declared volatile. This is now discouraged.
-See Documentation/process/volatile-considered-harmful.rst for the complete
rationale.
+See :ref:`Documentation/process/volatile-considered-harmful.rst
+` for the complete rationale.
-local_t is very similar to atomic_t. If the counter is per CPU and only
-updated by one CPU, local_t is probably more appropriate. Please see
-Documentation/local_ops.txt for the semantics of local_t.
+``local_t`` is very similar to ``atomic_t``. If the counter is per CPU and only
+updated by one CPU, ``local_t`` is probably more appropriate. Please see
+:ref:`Documentation/local_ops.txt ` for the semantics of
``local_t``.
-The first operations to implement for atomic_t's are the initializers and
-plain reads.
+The first operations to implement for ``atomic_t``'s are the initializers and
+plain reads::
- #define ATOMIC_INIT(i) { (i) }
- #define atomic_set(v, i)((v)->counter = (i))
+#define ATOMIC_INIT(i) { (i) }
+#define atomic_set(v, i)((v)->counter = (i))
-The first macro is used in definitions, such as:
+The first macro is used in definitions, such as::
-static atomic_t my_counter = ATOMIC_INIT(1);
+static atomic_t my_counter = ATOMIC_INIT(1);
The initializer is atomic in that the return values of the atomic operations
are guaranteed to be correct reflecting the initialized value if the
initializer is used before runtime. If the initializer is used at runtime, a
proper implicit or explicit read memory barrier is needed before reading the
-value with atomic_read from another thread.
+value with ``atomic_read`` from another thread.
-As with all of the atomic_ interfaces, replace the leading "atomic_"
-with "atomic_long_" to operate on atomic_long_t.
+As with all of the ``atomic_`` interfaces, replace the leading ``atomic_``
+with ``atomic_long_`` to operate on ``atomic_long_t``.
-The second interface can be used at runtime, as in:
+The second interface can be used at runtime, as in::
- struct foo { atomic_t counter; };
- ...
+struct foo { atomic_t counter; };
+...
- struct foo *k;
+struct foo *k;
- k = kmalloc(sizeof(*k), GFP_KERNEL);
- if (!k)
- return -ENOMEM;
- atomic_set(>counter, 0);
+k = kmalloc(sizeof(*k), GFP_KERNEL);
+if (!k)
+return -ENOMEM;
+atomic_set(>counter, 0);
The setting is atomic in that the return values of the atomic operations by
all threads are guaranteed to be correct reflecting either the value that has
been set with this operation or set with another operation. A proper implicit
or explicit memory barrier is needed before the value set with the operation
-is guaranteed to be readable with atomic_read from another thread.
+is guaranteed to be readable with ``atomic_rea
[PATCH v3 3/4] Documentation/local_ops.txt: convert to ReST markup
... and move to core-api folder. Signed-off-by: Silvio Fricke <silvio.fri...@gmail.com> --- Documentation/core-api/index.rst| 1 +- Documentation/local_ops.txt => Documentation/core-api/local_ops.rst | 273 +++ 2 files changed, 145 insertions(+), 129 deletions(-) diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index f3e5f5e..25b4e4a 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -9,6 +9,7 @@ Kernel and driver related documentation. assoc_array atomic_ops + local_ops workqueue .. only:: subproject diff --git a/Documentation/local_ops.txt b/Documentation/core-api/local_ops.rst similarity index 57% rename from Documentation/local_ops.txt rename to Documentation/core-api/local_ops.rst index 407576a..1062ddb 100644 --- a/Documentation/local_ops.txt +++ b/Documentation/core-api/local_ops.rst @@ -1,191 +1,206 @@ -Semantics and Behavior of Local Atomic Operations - Mathieu Desnoyers +.. _local_ops: += +Semantics and Behavior of Local Atomic Operations += - This document explains the purpose of the local atomic operations, how +:Author: Mathieu Desnoyers + + +This document explains the purpose of the local atomic operations, how to implement them for any given architecture and shows how they can be used properly. It also stresses on the precautions that must be taken when reading those local variables across CPUs when the order of memory writes matters. -Note that local_t based operations are not recommended for general kernel use. -Please use the this_cpu operations instead unless there is really a special purpose. -Most uses of local_t in the kernel have been replaced by this_cpu operations. -this_cpu operations combine the relocation with the local_t like semantics in -a single instruction and yield more compact and faster executing code. +.. note:: +Note that ``local_t`` based operations are not recommended for general +kernel use. Please use the ``this_cpu`` operations instead unless there is +really a special purpose. Most uses of ``local_t`` in the kernel have been +replaced by ``this_cpu`` operations. ``this_cpu`` operations combine the +relocation with the ``local_t`` like semantics in a single instruction and +yield more compact and faster executing code. -* Purpose of local atomic operations + +Purpose of local atomic operations +== Local atomic operations are meant to provide fast and highly reentrant per CPU counters. They minimize the performance cost of standard atomic operations by removing the LOCK prefix and memory barriers normally required to synchronize across CPUs. -Having fast per CPU atomic counters is interesting in many cases : it does not +Having fast per CPU atomic counters is interesting in many cases: it does not require disabling interrupts to protect from interrupt handlers and it permits coherent counters in NMI handlers. It is especially useful for tracing purposes and for various performance monitoring counters. Local atomic operations only guarantee variable modification atomicity wrt the CPU which owns the data. Therefore, care must taken to make sure that only one -CPU writes to the local_t data. This is done by using per cpu data and making -sure that we modify it from within a preemption safe context. It is however -permitted to read local_t data from any CPU : it will then appear to be written -out of order wrt other memory writes by the owner CPU. +CPU writes to the ``local_t`` data. This is done by using per cpu data and +making sure that we modify it from within a preemption safe context. It is +however permitted to read ``local_t`` data from any CPU: it will then appear to +be written out of order wrt other memory writes by the owner CPU. -* Implementation for a given architecture +Implementation for a given architecture +=== -It can be done by slightly modifying the standard atomic operations : only +It can be done by slightly modifying the standard atomic operations: only their UP variant must be kept. It typically means removing LOCK prefix (on i386 and x86_64) and any SMP synchronization barrier. If the architecture does -not have a different behavior between SMP and UP, including asm-generic/local.h -in your architecture's local.h is sufficient. +not have a different behavior between SMP and UP, including +``asm-generic/local.h`` in your architecture's ``local.h`` is sufficient. -The local_t type is defined as an opaque signed long by embedding an -atomic_long_t inside a structure. This is made so a cast from this type to a -long fails. The definition looks like : +The ``local_t`` type is defined as an opaque ``signed long`` by embedding an +``atom
[PATCH v3 1/4] Documentation/assoc_array.txt: convert to ReST markup
... and move to Documentation/core-api folder. Signed-off-by: Silvio Fricke <silvio.fri...@gmail.com> --- Documentation/assoc_array.txt => Documentation/core-api/assoc_array.rst | 639 ++-- Documentation/core-api/index.rst| 1 +- 2 files changed, 309 insertions(+), 331 deletions(-) diff --git a/Documentation/assoc_array.txt b/Documentation/core-api/assoc_array.rst similarity index 46% rename from Documentation/assoc_array.txt rename to Documentation/core-api/assoc_array.rst index 2f2c6cd..dcda7c6 100644 --- a/Documentation/assoc_array.txt +++ b/Documentation/core-api/assoc_array.rst @@ -1,67 +1,46 @@ - - GENERIC ASSOCIATIVE ARRAY IMPLEMENTATION - + +Generic Associative Array Implementation + -Contents: - - - Overview. - - - The public API. - - Edit script. - - Operations table. - - Manipulation functions. - - Access functions. - - Index key form. - - - Internal workings. - - Basic internal tree layout. - - Shortcuts. - - Splitting and collapsing nodes. - - Non-recursive iteration. - - Simultaneous alteration and iteration. - - - -OVERVIEW +Overview This associative array implementation is an object container with the following properties: - (1) Objects are opaque pointers. The implementation does not care where they - point (if anywhere) or what they point to (if anything). - - [!] NOTE: Pointers to objects _must_ be zero in the least significant bit. +1. Objects are opaque pointers. The implementation does not care where they + point (if anywhere) or what they point to (if anything). +.. note:: Pointers to objects _must_ be zero in the least significant bit.** - (2) Objects do not need to contain linkage blocks for use by the array. This - permits an object to be located in multiple arrays simultaneously. - Rather, the array is made up of metadata blocks that point to objects. +2. Objects do not need to contain linkage blocks for use by the array. This + permits an object to be located in multiple arrays simultaneously. + Rather, the array is made up of metadata blocks that point to objects. - (3) Objects require index keys to locate them within the array. +3. Objects require index keys to locate them within the array. - (4) Index keys must be unique. Inserting an object with the same key as one - already in the array will replace the old object. +4. Index keys must be unique. Inserting an object with the same key as one + already in the array will replace the old object. - (5) Index keys can be of any length and can be of different lengths. +5. Index keys can be of any length and can be of different lengths. - (6) Index keys should encode the length early on, before any variation due to - length is seen. +6. Index keys should encode the length early on, before any variation due to + length is seen. - (7) Index keys can include a hash to scatter objects throughout the array. +7. Index keys can include a hash to scatter objects throughout the array. - (8) The array can iterated over. The objects will not necessarily come out in - key order. +8. The array can iterated over. The objects will not necessarily come out in + key order. - (9) The array can be iterated over whilst it is being modified, provided the - RCU readlock is being held by the iterator. Note, however, under these - circumstances, some objects may be seen more than once. If this is a - problem, the iterator should lock against modification. Objects will not - be missed, however, unless deleted. +9. The array can be iterated over whilst it is being modified, provided the + RCU readlock is being held by the iterator. Note, however, under these + circumstances, some objects may be seen more than once. If this is a + problem, the iterator should lock against modification. Objects will not + be missed, however, unless deleted. -(10) Objects in the array can be looked up by means of their index key. +10. Objects in the array can be looked up by means of their index key. -(11) Objects can be looked up whilst the array is being modified, provided the - RCU readlock is being held by the thread doing the look up. +11. Objects can be looked up whilst the array is being modified, provided the +RCU readlock is being held by the thread doing the look up. The implementation uses a tree of 16-pointer nodes internally that are indexed on each level by nibbles from the index key in the same manner as in a radix @@ -71,25 +50,26 @@ pack leaf object pointers into spare space in the node rather than making an extra branch until as such time an object needs to be added to a
[PATCH v3 3/4] Documentation/local_ops.txt: convert to ReST markup
... and move to core-api folder. Signed-off-by: Silvio Fricke --- Documentation/core-api/index.rst| 1 +- Documentation/local_ops.txt => Documentation/core-api/local_ops.rst | 273 +++ 2 files changed, 145 insertions(+), 129 deletions(-) diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index f3e5f5e..25b4e4a 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -9,6 +9,7 @@ Kernel and driver related documentation. assoc_array atomic_ops + local_ops workqueue .. only:: subproject diff --git a/Documentation/local_ops.txt b/Documentation/core-api/local_ops.rst similarity index 57% rename from Documentation/local_ops.txt rename to Documentation/core-api/local_ops.rst index 407576a..1062ddb 100644 --- a/Documentation/local_ops.txt +++ b/Documentation/core-api/local_ops.rst @@ -1,191 +1,206 @@ -Semantics and Behavior of Local Atomic Operations - Mathieu Desnoyers +.. _local_ops: += +Semantics and Behavior of Local Atomic Operations += - This document explains the purpose of the local atomic operations, how +:Author: Mathieu Desnoyers + + +This document explains the purpose of the local atomic operations, how to implement them for any given architecture and shows how they can be used properly. It also stresses on the precautions that must be taken when reading those local variables across CPUs when the order of memory writes matters. -Note that local_t based operations are not recommended for general kernel use. -Please use the this_cpu operations instead unless there is really a special purpose. -Most uses of local_t in the kernel have been replaced by this_cpu operations. -this_cpu operations combine the relocation with the local_t like semantics in -a single instruction and yield more compact and faster executing code. +.. note:: +Note that ``local_t`` based operations are not recommended for general +kernel use. Please use the ``this_cpu`` operations instead unless there is +really a special purpose. Most uses of ``local_t`` in the kernel have been +replaced by ``this_cpu`` operations. ``this_cpu`` operations combine the +relocation with the ``local_t`` like semantics in a single instruction and +yield more compact and faster executing code. -* Purpose of local atomic operations + +Purpose of local atomic operations +== Local atomic operations are meant to provide fast and highly reentrant per CPU counters. They minimize the performance cost of standard atomic operations by removing the LOCK prefix and memory barriers normally required to synchronize across CPUs. -Having fast per CPU atomic counters is interesting in many cases : it does not +Having fast per CPU atomic counters is interesting in many cases: it does not require disabling interrupts to protect from interrupt handlers and it permits coherent counters in NMI handlers. It is especially useful for tracing purposes and for various performance monitoring counters. Local atomic operations only guarantee variable modification atomicity wrt the CPU which owns the data. Therefore, care must taken to make sure that only one -CPU writes to the local_t data. This is done by using per cpu data and making -sure that we modify it from within a preemption safe context. It is however -permitted to read local_t data from any CPU : it will then appear to be written -out of order wrt other memory writes by the owner CPU. +CPU writes to the ``local_t`` data. This is done by using per cpu data and +making sure that we modify it from within a preemption safe context. It is +however permitted to read ``local_t`` data from any CPU: it will then appear to +be written out of order wrt other memory writes by the owner CPU. -* Implementation for a given architecture +Implementation for a given architecture +=== -It can be done by slightly modifying the standard atomic operations : only +It can be done by slightly modifying the standard atomic operations: only their UP variant must be kept. It typically means removing LOCK prefix (on i386 and x86_64) and any SMP synchronization barrier. If the architecture does -not have a different behavior between SMP and UP, including asm-generic/local.h -in your architecture's local.h is sufficient. +not have a different behavior between SMP and UP, including +``asm-generic/local.h`` in your architecture's ``local.h`` is sufficient. -The local_t type is defined as an opaque signed long by embedding an -atomic_long_t inside a structure. This is made so a cast from this type to a -long fails. The definition looks like : +The ``local_t`` type is defined as an opaque ``signed long`` by embedding an +``atomic_long_t`` inside a struct
[PATCH v3 1/4] Documentation/assoc_array.txt: convert to ReST markup
... and move to Documentation/core-api folder. Signed-off-by: Silvio Fricke --- Documentation/assoc_array.txt => Documentation/core-api/assoc_array.rst | 639 ++-- Documentation/core-api/index.rst| 1 +- 2 files changed, 309 insertions(+), 331 deletions(-) diff --git a/Documentation/assoc_array.txt b/Documentation/core-api/assoc_array.rst similarity index 46% rename from Documentation/assoc_array.txt rename to Documentation/core-api/assoc_array.rst index 2f2c6cd..dcda7c6 100644 --- a/Documentation/assoc_array.txt +++ b/Documentation/core-api/assoc_array.rst @@ -1,67 +1,46 @@ - - GENERIC ASSOCIATIVE ARRAY IMPLEMENTATION - + +Generic Associative Array Implementation + -Contents: - - - Overview. - - - The public API. - - Edit script. - - Operations table. - - Manipulation functions. - - Access functions. - - Index key form. - - - Internal workings. - - Basic internal tree layout. - - Shortcuts. - - Splitting and collapsing nodes. - - Non-recursive iteration. - - Simultaneous alteration and iteration. - - - -OVERVIEW +Overview This associative array implementation is an object container with the following properties: - (1) Objects are opaque pointers. The implementation does not care where they - point (if anywhere) or what they point to (if anything). - - [!] NOTE: Pointers to objects _must_ be zero in the least significant bit. +1. Objects are opaque pointers. The implementation does not care where they + point (if anywhere) or what they point to (if anything). +.. note:: Pointers to objects _must_ be zero in the least significant bit.** - (2) Objects do not need to contain linkage blocks for use by the array. This - permits an object to be located in multiple arrays simultaneously. - Rather, the array is made up of metadata blocks that point to objects. +2. Objects do not need to contain linkage blocks for use by the array. This + permits an object to be located in multiple arrays simultaneously. + Rather, the array is made up of metadata blocks that point to objects. - (3) Objects require index keys to locate them within the array. +3. Objects require index keys to locate them within the array. - (4) Index keys must be unique. Inserting an object with the same key as one - already in the array will replace the old object. +4. Index keys must be unique. Inserting an object with the same key as one + already in the array will replace the old object. - (5) Index keys can be of any length and can be of different lengths. +5. Index keys can be of any length and can be of different lengths. - (6) Index keys should encode the length early on, before any variation due to - length is seen. +6. Index keys should encode the length early on, before any variation due to + length is seen. - (7) Index keys can include a hash to scatter objects throughout the array. +7. Index keys can include a hash to scatter objects throughout the array. - (8) The array can iterated over. The objects will not necessarily come out in - key order. +8. The array can iterated over. The objects will not necessarily come out in + key order. - (9) The array can be iterated over whilst it is being modified, provided the - RCU readlock is being held by the iterator. Note, however, under these - circumstances, some objects may be seen more than once. If this is a - problem, the iterator should lock against modification. Objects will not - be missed, however, unless deleted. +9. The array can be iterated over whilst it is being modified, provided the + RCU readlock is being held by the iterator. Note, however, under these + circumstances, some objects may be seen more than once. If this is a + problem, the iterator should lock against modification. Objects will not + be missed, however, unless deleted. -(10) Objects in the array can be looked up by means of their index key. +10. Objects in the array can be looked up by means of their index key. -(11) Objects can be looked up whilst the array is being modified, provided the - RCU readlock is being held by the thread doing the look up. +11. Objects can be looked up whilst the array is being modified, provided the +RCU readlock is being held by the thread doing the look up. The implementation uses a tree of 16-pointer nodes internally that are indexed on each level by nibbles from the index key in the same manner as in a radix @@ -71,25 +50,26 @@ pack leaf object pointers into spare space in the node rather than making an extra branch until as such time an object needs to be added to a full node. +The Public
[PATCH v3 0/4] core-api ReST: assoc_array, atomic_ops, local_ops
Hi, Thanks Mauro and Jani for reviewing. Some more ReSTification of core-api's: assoc_array, atomic_ops and local_ops. A fourth patch removes a warning about a bullet list without ending at firmware_class.c v2 -> v3 * change ". ::" to "::" * replace all "code-blocks" with "::" * add two ".. notes" declaration in atomic_ops.rst v1 -> v2 * use format-patch with a rename_threshold of 10%, no other changes Thanks for review. BR Silvio Silvio Fricke (4): Documentation/assoc_array.txt: convert to ReST markup Documentation/atomic_ops.txt: convert to ReST markup Documentation/local_ops.txt: convert to ReST markup firmware: remove warning at documentation generation time Documentation/assoc_array.txt => Documentation/core-api/assoc_array.rst | 639 --- Documentation/atomic_ops.txt => Documentation/core-api/atomic_ops.rst | 777 +--- Documentation/core-api/index.rst| 3 +- Documentation/local_ops.txt => Documentation/core-api/local_ops.rst | 273 + Documentation/process/volatile-considered-harmful.rst | 3 +- drivers/base/firmware_class.c | 6 +- 6 files changed, 861 insertions(+), 840 deletions(-) base-commit: 9c240d757658a3ae9968dd309e674c61f07c7f48 -- git-series 0.9.1
[PATCH v3 2/4] Documentation/atomic_ops.txt: convert to ReST markup
... and move to core-api folder.
Signed-off-by: Silvio Fricke
---
Documentation/atomic_ops.txt => Documentation/core-api/atomic_ops.rst | 777
+---
Documentation/core-api/index.rst | 1 +-
Documentation/process/volatile-considered-harmful.rst | 3 +-
3 files changed, 404 insertions(+), 377 deletions(-)
diff --git a/Documentation/atomic_ops.txt
b/Documentation/core-api/atomic_ops.rst
similarity index 46%
rename from Documentation/atomic_ops.txt
rename to Documentation/core-api/atomic_ops.rst
index 6c5e8a9..6236951 100644
--- a/Documentation/atomic_ops.txt
+++ b/Documentation/core-api/atomic_ops.rst
@@ -1,204 +1,212 @@
- Semantics and Behavior of Atomic and
-Bitmask Operations
+===
+Semantics and Behavior of Atomic and Bitmask Operations
+===
- David S. Miller
+:Author: David S. Miller
- This document is intended to serve as a guide to Linux port
+This document is intended to serve as a guide to Linux port
maintainers on how to implement atomic counter, bitops, and spinlock
interfaces properly.
- The atomic_t type should be defined as a signed integer and
-the atomic_long_t type as a signed long integer. Also, they should
+Atomic Type And Operations
+==
+
+The ``atomic_t type`` should be defined as a signed integer and
+the ``atomic_long_t`` type as a signed long integer. Also, they should
be made opaque such that any kind of cast to a normal C integer type
-will fail. Something like the following should suffice:
+will fail. Something like the following should suffice::
- typedef struct { int counter; } atomic_t;
- typedef struct { long counter; } atomic_long_t;
+typedef struct { int counter; } atomic_t;
+typedef struct { long counter; } atomic_long_t;
Historically, counter has been declared volatile. This is now discouraged.
-See Documentation/process/volatile-considered-harmful.rst for the complete
rationale.
+See :ref:`Documentation/process/volatile-considered-harmful.rst
+` for the complete rationale.
-local_t is very similar to atomic_t. If the counter is per CPU and only
-updated by one CPU, local_t is probably more appropriate. Please see
-Documentation/local_ops.txt for the semantics of local_t.
+``local_t`` is very similar to ``atomic_t``. If the counter is per CPU and only
+updated by one CPU, ``local_t`` is probably more appropriate. Please see
+:ref:`Documentation/local_ops.txt ` for the semantics of
``local_t``.
-The first operations to implement for atomic_t's are the initializers and
-plain reads.
+The first operations to implement for ``atomic_t``'s are the initializers and
+plain reads::
- #define ATOMIC_INIT(i) { (i) }
- #define atomic_set(v, i)((v)->counter = (i))
+#define ATOMIC_INIT(i) { (i) }
+#define atomic_set(v, i)((v)->counter = (i))
-The first macro is used in definitions, such as:
+The first macro is used in definitions, such as::
-static atomic_t my_counter = ATOMIC_INIT(1);
+static atomic_t my_counter = ATOMIC_INIT(1);
The initializer is atomic in that the return values of the atomic operations
are guaranteed to be correct reflecting the initialized value if the
initializer is used before runtime. If the initializer is used at runtime, a
proper implicit or explicit read memory barrier is needed before reading the
-value with atomic_read from another thread.
+value with ``atomic_read`` from another thread.
-As with all of the atomic_ interfaces, replace the leading "atomic_"
-with "atomic_long_" to operate on atomic_long_t.
+As with all of the ``atomic_`` interfaces, replace the leading ``atomic_``
+with ``atomic_long_`` to operate on ``atomic_long_t``.
-The second interface can be used at runtime, as in:
+The second interface can be used at runtime, as in::
- struct foo { atomic_t counter; };
- ...
+struct foo { atomic_t counter; };
+...
- struct foo *k;
+struct foo *k;
- k = kmalloc(sizeof(*k), GFP_KERNEL);
- if (!k)
- return -ENOMEM;
- atomic_set(>counter, 0);
+k = kmalloc(sizeof(*k), GFP_KERNEL);
+if (!k)
+return -ENOMEM;
+atomic_set(>counter, 0);
The setting is atomic in that the return values of the atomic operations by
all threads are guaranteed to be correct reflecting either the value that has
been set with this operation or set with another operation. A proper implicit
or explicit memory barrier is needed before the value set with the operation
-is guaranteed to be readable with atomic_read from another thread.
+is guaranteed to be readable with ``atomic_read`` from another threa
[PATCH v3 4/4] firmware: remove warning at documentation generation time
This patch removes following error at for `make htmldocs`. No functional change. ./drivers/base/firmware_class.c:1348: WARNING: Bullet list ends without a blank line; unexpected unindent. Signed-off-by: Silvio Fricke <silvio.fri...@gmail.com> --- drivers/base/firmware_class.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c index 22d1760..37b0221 100644 --- a/drivers/base/firmware_class.c +++ b/drivers/base/firmware_class.c @@ -1345,9 +1345,9 @@ static void request_firmware_work_func(struct work_struct *work) * * Asynchronous variant of request_firmware() for user contexts: * - sleep for as small periods as possible since it may - * increase kernel boot time of built-in device drivers - * requesting firmware in their ->probe() methods, if - * @gfp is GFP_KERNEL. + * increase kernel boot time of built-in device drivers + * requesting firmware in their ->probe() methods, if + * @gfp is GFP_KERNEL. * * - can't sleep at all if @gfp is GFP_ATOMIC. **/ -- git-series 0.9.1
[PATCH v3 4/4] firmware: remove warning at documentation generation time
This patch removes following error at for `make htmldocs`. No functional change. ./drivers/base/firmware_class.c:1348: WARNING: Bullet list ends without a blank line; unexpected unindent. Signed-off-by: Silvio Fricke --- drivers/base/firmware_class.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c index 22d1760..37b0221 100644 --- a/drivers/base/firmware_class.c +++ b/drivers/base/firmware_class.c @@ -1345,9 +1345,9 @@ static void request_firmware_work_func(struct work_struct *work) * * Asynchronous variant of request_firmware() for user contexts: * - sleep for as small periods as possible since it may - * increase kernel boot time of built-in device drivers - * requesting firmware in their ->probe() methods, if - * @gfp is GFP_KERNEL. + * increase kernel boot time of built-in device drivers + * requesting firmware in their ->probe() methods, if + * @gfp is GFP_KERNEL. * * - can't sleep at all if @gfp is GFP_ATOMIC. **/ -- git-series 0.9.1
[PATCH v2 3/4] Documentation/local_ops.txt: convert to ReST markup
... and move to core-api folder. Signed-off-by: Silvio Fricke <silvio.fri...@gmail.com> --- Documentation/core-api/index.rst| 1 +- Documentation/local_ops.txt => Documentation/core-api/local_ops.rst | 275 +++ 2 files changed, 147 insertions(+), 129 deletions(-) diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index f3e5f5e..25b4e4a 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -9,6 +9,7 @@ Kernel and driver related documentation. assoc_array atomic_ops + local_ops workqueue .. only:: subproject diff --git a/Documentation/local_ops.txt b/Documentation/core-api/local_ops.rst similarity index 55% rename from Documentation/local_ops.txt rename to Documentation/core-api/local_ops.rst index 407576a..01f1880 100644 --- a/Documentation/local_ops.txt +++ b/Documentation/core-api/local_ops.rst @@ -1,191 +1,208 @@ -Semantics and Behavior of Local Atomic Operations - Mathieu Desnoyers +.. _local_ops: += +Semantics and Behavior of Local Atomic Operations += - This document explains the purpose of the local atomic operations, how +:Author: Mathieu Desnoyers + + +This document explains the purpose of the local atomic operations, how to implement them for any given architecture and shows how they can be used properly. It also stresses on the precautions that must be taken when reading those local variables across CPUs when the order of memory writes matters. -Note that local_t based operations are not recommended for general kernel use. -Please use the this_cpu operations instead unless there is really a special purpose. -Most uses of local_t in the kernel have been replaced by this_cpu operations. -this_cpu operations combine the relocation with the local_t like semantics in -a single instruction and yield more compact and faster executing code. +.. note:: +Note that ``local_t`` based operations are not recommended for general +kernel use. Please use the ``this_cpu`` operations instead unless there is +really a special purpose. Most uses of ``local_t`` in the kernel have been +replaced by ``this_cpu`` operations. ``this_cpu`` operations combine the +relocation with the ``local_t`` like semantics in a single instruction and +yield more compact and faster executing code. -* Purpose of local atomic operations + +Purpose of local atomic operations +== Local atomic operations are meant to provide fast and highly reentrant per CPU counters. They minimize the performance cost of standard atomic operations by removing the LOCK prefix and memory barriers normally required to synchronize across CPUs. -Having fast per CPU atomic counters is interesting in many cases : it does not +Having fast per CPU atomic counters is interesting in many cases: it does not require disabling interrupts to protect from interrupt handlers and it permits coherent counters in NMI handlers. It is especially useful for tracing purposes and for various performance monitoring counters. Local atomic operations only guarantee variable modification atomicity wrt the CPU which owns the data. Therefore, care must taken to make sure that only one -CPU writes to the local_t data. This is done by using per cpu data and making -sure that we modify it from within a preemption safe context. It is however -permitted to read local_t data from any CPU : it will then appear to be written -out of order wrt other memory writes by the owner CPU. +CPU writes to the ``local_t`` data. This is done by using per cpu data and +making sure that we modify it from within a preemption safe context. It is +however permitted to read ``local_t`` data from any CPU: it will then appear to +be written out of order wrt other memory writes by the owner CPU. -* Implementation for a given architecture +Implementation for a given architecture +=== -It can be done by slightly modifying the standard atomic operations : only +It can be done by slightly modifying the standard atomic operations: only their UP variant must be kept. It typically means removing LOCK prefix (on i386 and x86_64) and any SMP synchronization barrier. If the architecture does -not have a different behavior between SMP and UP, including asm-generic/local.h -in your architecture's local.h is sufficient. +not have a different behavior between SMP and UP, including +``asm-generic/local.h`` in your architecture's ``local.h`` is sufficient. -The local_t type is defined as an opaque signed long by embedding an -atomic_long_t inside a structure. This is made so a cast from this type to a -long fails. The definition looks like : +The ``local_t`` type is defined as an opaque ``signed long`` by embedding an +``atom
[PATCH v2 3/4] Documentation/local_ops.txt: convert to ReST markup
... and move to core-api folder. Signed-off-by: Silvio Fricke --- Documentation/core-api/index.rst| 1 +- Documentation/local_ops.txt => Documentation/core-api/local_ops.rst | 275 +++ 2 files changed, 147 insertions(+), 129 deletions(-) diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index f3e5f5e..25b4e4a 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -9,6 +9,7 @@ Kernel and driver related documentation. assoc_array atomic_ops + local_ops workqueue .. only:: subproject diff --git a/Documentation/local_ops.txt b/Documentation/core-api/local_ops.rst similarity index 55% rename from Documentation/local_ops.txt rename to Documentation/core-api/local_ops.rst index 407576a..01f1880 100644 --- a/Documentation/local_ops.txt +++ b/Documentation/core-api/local_ops.rst @@ -1,191 +1,208 @@ -Semantics and Behavior of Local Atomic Operations - Mathieu Desnoyers +.. _local_ops: += +Semantics and Behavior of Local Atomic Operations += - This document explains the purpose of the local atomic operations, how +:Author: Mathieu Desnoyers + + +This document explains the purpose of the local atomic operations, how to implement them for any given architecture and shows how they can be used properly. It also stresses on the precautions that must be taken when reading those local variables across CPUs when the order of memory writes matters. -Note that local_t based operations are not recommended for general kernel use. -Please use the this_cpu operations instead unless there is really a special purpose. -Most uses of local_t in the kernel have been replaced by this_cpu operations. -this_cpu operations combine the relocation with the local_t like semantics in -a single instruction and yield more compact and faster executing code. +.. note:: +Note that ``local_t`` based operations are not recommended for general +kernel use. Please use the ``this_cpu`` operations instead unless there is +really a special purpose. Most uses of ``local_t`` in the kernel have been +replaced by ``this_cpu`` operations. ``this_cpu`` operations combine the +relocation with the ``local_t`` like semantics in a single instruction and +yield more compact and faster executing code. -* Purpose of local atomic operations + +Purpose of local atomic operations +== Local atomic operations are meant to provide fast and highly reentrant per CPU counters. They minimize the performance cost of standard atomic operations by removing the LOCK prefix and memory barriers normally required to synchronize across CPUs. -Having fast per CPU atomic counters is interesting in many cases : it does not +Having fast per CPU atomic counters is interesting in many cases: it does not require disabling interrupts to protect from interrupt handlers and it permits coherent counters in NMI handlers. It is especially useful for tracing purposes and for various performance monitoring counters. Local atomic operations only guarantee variable modification atomicity wrt the CPU which owns the data. Therefore, care must taken to make sure that only one -CPU writes to the local_t data. This is done by using per cpu data and making -sure that we modify it from within a preemption safe context. It is however -permitted to read local_t data from any CPU : it will then appear to be written -out of order wrt other memory writes by the owner CPU. +CPU writes to the ``local_t`` data. This is done by using per cpu data and +making sure that we modify it from within a preemption safe context. It is +however permitted to read ``local_t`` data from any CPU: it will then appear to +be written out of order wrt other memory writes by the owner CPU. -* Implementation for a given architecture +Implementation for a given architecture +=== -It can be done by slightly modifying the standard atomic operations : only +It can be done by slightly modifying the standard atomic operations: only their UP variant must be kept. It typically means removing LOCK prefix (on i386 and x86_64) and any SMP synchronization barrier. If the architecture does -not have a different behavior between SMP and UP, including asm-generic/local.h -in your architecture's local.h is sufficient. +not have a different behavior between SMP and UP, including +``asm-generic/local.h`` in your architecture's ``local.h`` is sufficient. -The local_t type is defined as an opaque signed long by embedding an -atomic_long_t inside a structure. This is made so a cast from this type to a -long fails. The definition looks like : +The ``local_t`` type is defined as an opaque ``signed long`` by embedding an +``atomic_long_t`` inside a struct
[PATCH v2 2/4] Documentation/atomic_ops.txt: convert to ReST markup
... and move to core-api folder.
Signed-off-by: Silvio Fricke <silvio.fri...@gmail.com>
---
Documentation/atomic_ops.txt => Documentation/core-api/atomic_ops.rst | 745
+---
Documentation/core-api/index.rst | 1 +-
Documentation/process/volatile-considered-harmful.rst | 3 +-
3 files changed, 391 insertions(+), 358 deletions(-)
diff --git a/Documentation/atomic_ops.txt
b/Documentation/core-api/atomic_ops.rst
similarity index 47%
rename from Documentation/atomic_ops.txt
rename to Documentation/core-api/atomic_ops.rst
index 6c5e8a9..3ac94ff 100644
--- a/Documentation/atomic_ops.txt
+++ b/Documentation/core-api/atomic_ops.rst
@@ -1,204 +1,212 @@
- Semantics and Behavior of Atomic and
-Bitmask Operations
+===
+Semantics and Behavior of Atomic and Bitmask Operations
+===
- David S. Miller
+:Author: David S. Miller
- This document is intended to serve as a guide to Linux port
+This document is intended to serve as a guide to Linux port
maintainers on how to implement atomic counter, bitops, and spinlock
interfaces properly.
- The atomic_t type should be defined as a signed integer and
-the atomic_long_t type as a signed long integer. Also, they should
+Atomic Type And Operations
+==
+
+The ``atomic_t type`` should be defined as a signed integer and
+the ``atomic_long_t`` type as a signed long integer. Also, they should
be made opaque such that any kind of cast to a normal C integer type
-will fail. Something like the following should suffice:
+will fail. Something like the following should suffice::
- typedef struct { int counter; } atomic_t;
- typedef struct { long counter; } atomic_long_t;
+typedef struct { int counter; } atomic_t;
+typedef struct { long counter; } atomic_long_t;
Historically, counter has been declared volatile. This is now discouraged.
-See Documentation/process/volatile-considered-harmful.rst for the complete
rationale.
+See :ref:`Documentation/process/volatile-considered-harmful.rst
+` for the complete rationale.
-local_t is very similar to atomic_t. If the counter is per CPU and only
-updated by one CPU, local_t is probably more appropriate. Please see
-Documentation/local_ops.txt for the semantics of local_t.
+``local_t`` is very similar to ``atomic_t``. If the counter is per CPU and only
+updated by one CPU, ``local_t`` is probably more appropriate. Please see
+:ref:`Documentation/local_ops.txt ` for the semantics of
``local_t``.
-The first operations to implement for atomic_t's are the initializers and
-plain reads.
+The first operations to implement for ``atomic_t``'s are the initializers and
+plain reads. ::
- #define ATOMIC_INIT(i) { (i) }
- #define atomic_set(v, i)((v)->counter = (i))
+#define ATOMIC_INIT(i) { (i) }
+#define atomic_set(v, i)((v)->counter = (i))
-The first macro is used in definitions, such as:
+The first macro is used in definitions, such as::
-static atomic_t my_counter = ATOMIC_INIT(1);
+static atomic_t my_counter = ATOMIC_INIT(1);
The initializer is atomic in that the return values of the atomic operations
are guaranteed to be correct reflecting the initialized value if the
initializer is used before runtime. If the initializer is used at runtime, a
proper implicit or explicit read memory barrier is needed before reading the
-value with atomic_read from another thread.
+value with ``atomic_read`` from another thread.
-As with all of the atomic_ interfaces, replace the leading "atomic_"
-with "atomic_long_" to operate on atomic_long_t.
+As with all of the ``atomic_`` interfaces, replace the leading ``atomic_``
+with ``atomic_long_`` to operate on ``atomic_long_t``.
-The second interface can be used at runtime, as in:
+The second interface can be used at runtime, as in::
- struct foo { atomic_t counter; };
- ...
+struct foo { atomic_t counter; };
+...
- struct foo *k;
+struct foo *k;
- k = kmalloc(sizeof(*k), GFP_KERNEL);
- if (!k)
- return -ENOMEM;
- atomic_set(>counter, 0);
+k = kmalloc(sizeof(*k), GFP_KERNEL);
+if (!k)
+return -ENOMEM;
+atomic_set(>counter, 0);
The setting is atomic in that the return values of the atomic operations by
all threads are guaranteed to be correct reflecting either the value that has
been set with this operation or set with another operation. A proper implicit
or explicit memory barrier is needed before the value set with the operation
-is guaranteed to be readable with atomic_read from another thread.
+is guaranteed to be readable with ``atomic_rea
[PATCH v2 1/4] Documentation/assoc_array.txt: convert to ReST markup
... and move to Documentation/core-api folder. Signed-off-by: Silvio Fricke <silvio.fri...@gmail.com> --- Documentation/assoc_array.txt => Documentation/core-api/assoc_array.rst | 617 ++-- Documentation/core-api/index.rst| 1 +- 2 files changed, 297 insertions(+), 321 deletions(-) diff --git a/Documentation/assoc_array.txt b/Documentation/core-api/assoc_array.rst similarity index 46% rename from Documentation/assoc_array.txt rename to Documentation/core-api/assoc_array.rst index 2f2c6cd..67a3a50 100644 --- a/Documentation/assoc_array.txt +++ b/Documentation/core-api/assoc_array.rst @@ -1,67 +1,46 @@ - - GENERIC ASSOCIATIVE ARRAY IMPLEMENTATION - + +Generic Associative Array Implementation + -Contents: - - - Overview. - - - The public API. - - Edit script. - - Operations table. - - Manipulation functions. - - Access functions. - - Index key form. - - - Internal workings. - - Basic internal tree layout. - - Shortcuts. - - Splitting and collapsing nodes. - - Non-recursive iteration. - - Simultaneous alteration and iteration. - - - -OVERVIEW +Overview This associative array implementation is an object container with the following properties: - (1) Objects are opaque pointers. The implementation does not care where they - point (if anywhere) or what they point to (if anything). - - [!] NOTE: Pointers to objects _must_ be zero in the least significant bit. +1. Objects are opaque pointers. The implementation does not care where they + point (if anywhere) or what they point to (if anything). + **NOTE: Pointers to objects _must_ be zero in the least significant bit.** - (2) Objects do not need to contain linkage blocks for use by the array. This - permits an object to be located in multiple arrays simultaneously. - Rather, the array is made up of metadata blocks that point to objects. +2. Objects do not need to contain linkage blocks for use by the array. This + permits an object to be located in multiple arrays simultaneously. + Rather, the array is made up of metadata blocks that point to objects. - (3) Objects require index keys to locate them within the array. +3. Objects require index keys to locate them within the array. - (4) Index keys must be unique. Inserting an object with the same key as one - already in the array will replace the old object. +4. Index keys must be unique. Inserting an object with the same key as one + already in the array will replace the old object. - (5) Index keys can be of any length and can be of different lengths. +5. Index keys can be of any length and can be of different lengths. - (6) Index keys should encode the length early on, before any variation due to - length is seen. +6. Index keys should encode the length early on, before any variation due to + length is seen. - (7) Index keys can include a hash to scatter objects throughout the array. +7. Index keys can include a hash to scatter objects throughout the array. - (8) The array can iterated over. The objects will not necessarily come out in - key order. +8. The array can iterated over. The objects will not necessarily come out in + key order. - (9) The array can be iterated over whilst it is being modified, provided the - RCU readlock is being held by the iterator. Note, however, under these - circumstances, some objects may be seen more than once. If this is a - problem, the iterator should lock against modification. Objects will not - be missed, however, unless deleted. +9. The array can be iterated over whilst it is being modified, provided the + RCU readlock is being held by the iterator. Note, however, under these + circumstances, some objects may be seen more than once. If this is a + problem, the iterator should lock against modification. Objects will not + be missed, however, unless deleted. -(10) Objects in the array can be looked up by means of their index key. +10. Objects in the array can be looked up by means of their index key. -(11) Objects can be looked up whilst the array is being modified, provided the - RCU readlock is being held by the thread doing the look up. +11. Objects can be looked up whilst the array is being modified, provided the +RCU readlock is being held by the thread doing the look up. The implementation uses a tree of 16-pointer nodes internally that are indexed on each level by nibbles from the index key in the same manner as in a radix @@ -71,25 +50,24 @@ pack leaf object pointers into spare space in the node rather than making an extra branch until as such time an object needs to be added to a
[PATCH v2 1/4] Documentation/assoc_array.txt: convert to ReST markup
... and move to Documentation/core-api folder. Signed-off-by: Silvio Fricke --- Documentation/assoc_array.txt => Documentation/core-api/assoc_array.rst | 617 ++-- Documentation/core-api/index.rst| 1 +- 2 files changed, 297 insertions(+), 321 deletions(-) diff --git a/Documentation/assoc_array.txt b/Documentation/core-api/assoc_array.rst similarity index 46% rename from Documentation/assoc_array.txt rename to Documentation/core-api/assoc_array.rst index 2f2c6cd..67a3a50 100644 --- a/Documentation/assoc_array.txt +++ b/Documentation/core-api/assoc_array.rst @@ -1,67 +1,46 @@ - - GENERIC ASSOCIATIVE ARRAY IMPLEMENTATION - + +Generic Associative Array Implementation + -Contents: - - - Overview. - - - The public API. - - Edit script. - - Operations table. - - Manipulation functions. - - Access functions. - - Index key form. - - - Internal workings. - - Basic internal tree layout. - - Shortcuts. - - Splitting and collapsing nodes. - - Non-recursive iteration. - - Simultaneous alteration and iteration. - - - -OVERVIEW +Overview This associative array implementation is an object container with the following properties: - (1) Objects are opaque pointers. The implementation does not care where they - point (if anywhere) or what they point to (if anything). - - [!] NOTE: Pointers to objects _must_ be zero in the least significant bit. +1. Objects are opaque pointers. The implementation does not care where they + point (if anywhere) or what they point to (if anything). + **NOTE: Pointers to objects _must_ be zero in the least significant bit.** - (2) Objects do not need to contain linkage blocks for use by the array. This - permits an object to be located in multiple arrays simultaneously. - Rather, the array is made up of metadata blocks that point to objects. +2. Objects do not need to contain linkage blocks for use by the array. This + permits an object to be located in multiple arrays simultaneously. + Rather, the array is made up of metadata blocks that point to objects. - (3) Objects require index keys to locate them within the array. +3. Objects require index keys to locate them within the array. - (4) Index keys must be unique. Inserting an object with the same key as one - already in the array will replace the old object. +4. Index keys must be unique. Inserting an object with the same key as one + already in the array will replace the old object. - (5) Index keys can be of any length and can be of different lengths. +5. Index keys can be of any length and can be of different lengths. - (6) Index keys should encode the length early on, before any variation due to - length is seen. +6. Index keys should encode the length early on, before any variation due to + length is seen. - (7) Index keys can include a hash to scatter objects throughout the array. +7. Index keys can include a hash to scatter objects throughout the array. - (8) The array can iterated over. The objects will not necessarily come out in - key order. +8. The array can iterated over. The objects will not necessarily come out in + key order. - (9) The array can be iterated over whilst it is being modified, provided the - RCU readlock is being held by the iterator. Note, however, under these - circumstances, some objects may be seen more than once. If this is a - problem, the iterator should lock against modification. Objects will not - be missed, however, unless deleted. +9. The array can be iterated over whilst it is being modified, provided the + RCU readlock is being held by the iterator. Note, however, under these + circumstances, some objects may be seen more than once. If this is a + problem, the iterator should lock against modification. Objects will not + be missed, however, unless deleted. -(10) Objects in the array can be looked up by means of their index key. +10. Objects in the array can be looked up by means of their index key. -(11) Objects can be looked up whilst the array is being modified, provided the - RCU readlock is being held by the thread doing the look up. +11. Objects can be looked up whilst the array is being modified, provided the +RCU readlock is being held by the thread doing the look up. The implementation uses a tree of 16-pointer nodes internally that are indexed on each level by nibbles from the index key in the same manner as in a radix @@ -71,25 +50,24 @@ pack leaf object pointers into spare space in the node rather than making an extra branch until as such time an object needs to be added to a full n
[PATCH v2 2/4] Documentation/atomic_ops.txt: convert to ReST markup
... and move to core-api folder.
Signed-off-by: Silvio Fricke
---
Documentation/atomic_ops.txt => Documentation/core-api/atomic_ops.rst | 745
+---
Documentation/core-api/index.rst | 1 +-
Documentation/process/volatile-considered-harmful.rst | 3 +-
3 files changed, 391 insertions(+), 358 deletions(-)
diff --git a/Documentation/atomic_ops.txt
b/Documentation/core-api/atomic_ops.rst
similarity index 47%
rename from Documentation/atomic_ops.txt
rename to Documentation/core-api/atomic_ops.rst
index 6c5e8a9..3ac94ff 100644
--- a/Documentation/atomic_ops.txt
+++ b/Documentation/core-api/atomic_ops.rst
@@ -1,204 +1,212 @@
- Semantics and Behavior of Atomic and
-Bitmask Operations
+===
+Semantics and Behavior of Atomic and Bitmask Operations
+===
- David S. Miller
+:Author: David S. Miller
- This document is intended to serve as a guide to Linux port
+This document is intended to serve as a guide to Linux port
maintainers on how to implement atomic counter, bitops, and spinlock
interfaces properly.
- The atomic_t type should be defined as a signed integer and
-the atomic_long_t type as a signed long integer. Also, they should
+Atomic Type And Operations
+==
+
+The ``atomic_t type`` should be defined as a signed integer and
+the ``atomic_long_t`` type as a signed long integer. Also, they should
be made opaque such that any kind of cast to a normal C integer type
-will fail. Something like the following should suffice:
+will fail. Something like the following should suffice::
- typedef struct { int counter; } atomic_t;
- typedef struct { long counter; } atomic_long_t;
+typedef struct { int counter; } atomic_t;
+typedef struct { long counter; } atomic_long_t;
Historically, counter has been declared volatile. This is now discouraged.
-See Documentation/process/volatile-considered-harmful.rst for the complete
rationale.
+See :ref:`Documentation/process/volatile-considered-harmful.rst
+` for the complete rationale.
-local_t is very similar to atomic_t. If the counter is per CPU and only
-updated by one CPU, local_t is probably more appropriate. Please see
-Documentation/local_ops.txt for the semantics of local_t.
+``local_t`` is very similar to ``atomic_t``. If the counter is per CPU and only
+updated by one CPU, ``local_t`` is probably more appropriate. Please see
+:ref:`Documentation/local_ops.txt ` for the semantics of
``local_t``.
-The first operations to implement for atomic_t's are the initializers and
-plain reads.
+The first operations to implement for ``atomic_t``'s are the initializers and
+plain reads. ::
- #define ATOMIC_INIT(i) { (i) }
- #define atomic_set(v, i)((v)->counter = (i))
+#define ATOMIC_INIT(i) { (i) }
+#define atomic_set(v, i)((v)->counter = (i))
-The first macro is used in definitions, such as:
+The first macro is used in definitions, such as::
-static atomic_t my_counter = ATOMIC_INIT(1);
+static atomic_t my_counter = ATOMIC_INIT(1);
The initializer is atomic in that the return values of the atomic operations
are guaranteed to be correct reflecting the initialized value if the
initializer is used before runtime. If the initializer is used at runtime, a
proper implicit or explicit read memory barrier is needed before reading the
-value with atomic_read from another thread.
+value with ``atomic_read`` from another thread.
-As with all of the atomic_ interfaces, replace the leading "atomic_"
-with "atomic_long_" to operate on atomic_long_t.
+As with all of the ``atomic_`` interfaces, replace the leading ``atomic_``
+with ``atomic_long_`` to operate on ``atomic_long_t``.
-The second interface can be used at runtime, as in:
+The second interface can be used at runtime, as in::
- struct foo { atomic_t counter; };
- ...
+struct foo { atomic_t counter; };
+...
- struct foo *k;
+struct foo *k;
- k = kmalloc(sizeof(*k), GFP_KERNEL);
- if (!k)
- return -ENOMEM;
- atomic_set(>counter, 0);
+k = kmalloc(sizeof(*k), GFP_KERNEL);
+if (!k)
+return -ENOMEM;
+atomic_set(>counter, 0);
The setting is atomic in that the return values of the atomic operations by
all threads are guaranteed to be correct reflecting either the value that has
been set with this operation or set with another operation. A proper implicit
or explicit memory barrier is needed before the value set with the operation
-is guaranteed to be readable with atomic_read from another thread.
+is guaranteed to be readable with ``atomic_read`` from another threa
[PATCH v2 4/4] firmware: remove warning at documentation generation time
This patch removes following error at for `make htmldocs`. No functional change. ./drivers/base/firmware_class.c:1348: WARNING: Bullet list ends without a blank line; unexpected unindent. Signed-off-by: Silvio Fricke <silvio.fri...@gmail.com> --- drivers/base/firmware_class.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c index 22d1760..37b0221 100644 --- a/drivers/base/firmware_class.c +++ b/drivers/base/firmware_class.c @@ -1345,9 +1345,9 @@ static void request_firmware_work_func(struct work_struct *work) * * Asynchronous variant of request_firmware() for user contexts: * - sleep for as small periods as possible since it may - * increase kernel boot time of built-in device drivers - * requesting firmware in their ->probe() methods, if - * @gfp is GFP_KERNEL. + * increase kernel boot time of built-in device drivers + * requesting firmware in their ->probe() methods, if + * @gfp is GFP_KERNEL. * * - can't sleep at all if @gfp is GFP_ATOMIC. **/ -- git-series 0.9.1
[PATCH v2 0/4] core-api ReST: assoc_array, atomic_ops, local_ops
Hi, Some more ReSTification of core-api's: assoc_array, atomic_ops and local_ops. A fourth patch removes a warning about a bullet list without ending at firmware_class.c v1 -> v2 * use format-patch with a rename_threshold of 10%, no other changes Thanks for review. BR Silvio Silvio Fricke (4): Documentation/assoc_array.txt: convert to ReST markup Documentation/atomic_ops.txt: convert to ReST markup Documentation/local_ops.txt: convert to ReST markup firmware: remove warning at documentation generation time Documentation/assoc_array.txt => Documentation/core-api/assoc_array.rst | 617 Documentation/atomic_ops.txt => Documentation/core-api/atomic_ops.rst | 745 +--- Documentation/core-api/index.rst| 3 +- Documentation/local_ops.txt => Documentation/core-api/local_ops.rst | 275 ++- Documentation/process/volatile-considered-harmful.rst | 3 +- drivers/base/firmware_class.c | 6 +- 6 files changed, 838 insertions(+), 811 deletions(-) base-commit: 9c240d757658a3ae9968dd309e674c61f07c7f48 -- git-series 0.9.1
[PATCH v2 4/4] firmware: remove warning at documentation generation time
This patch removes following error at for `make htmldocs`. No functional change. ./drivers/base/firmware_class.c:1348: WARNING: Bullet list ends without a blank line; unexpected unindent. Signed-off-by: Silvio Fricke --- drivers/base/firmware_class.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c index 22d1760..37b0221 100644 --- a/drivers/base/firmware_class.c +++ b/drivers/base/firmware_class.c @@ -1345,9 +1345,9 @@ static void request_firmware_work_func(struct work_struct *work) * * Asynchronous variant of request_firmware() for user contexts: * - sleep for as small periods as possible since it may - * increase kernel boot time of built-in device drivers - * requesting firmware in their ->probe() methods, if - * @gfp is GFP_KERNEL. + * increase kernel boot time of built-in device drivers + * requesting firmware in their ->probe() methods, if + * @gfp is GFP_KERNEL. * * - can't sleep at all if @gfp is GFP_ATOMIC. **/ -- git-series 0.9.1
[PATCH v2 0/4] core-api ReST: assoc_array, atomic_ops, local_ops
Hi, Some more ReSTification of core-api's: assoc_array, atomic_ops and local_ops. A fourth patch removes a warning about a bullet list without ending at firmware_class.c v1 -> v2 * use format-patch with a rename_threshold of 10%, no other changes Thanks for review. BR Silvio Silvio Fricke (4): Documentation/assoc_array.txt: convert to ReST markup Documentation/atomic_ops.txt: convert to ReST markup Documentation/local_ops.txt: convert to ReST markup firmware: remove warning at documentation generation time Documentation/assoc_array.txt => Documentation/core-api/assoc_array.rst | 617 Documentation/atomic_ops.txt => Documentation/core-api/atomic_ops.rst | 745 +--- Documentation/core-api/index.rst| 3 +- Documentation/local_ops.txt => Documentation/core-api/local_ops.rst | 275 ++- Documentation/process/volatile-considered-harmful.rst | 3 +- drivers/base/firmware_class.c | 6 +- 6 files changed, 838 insertions(+), 811 deletions(-) base-commit: 9c240d757658a3ae9968dd309e674c61f07c7f48 -- git-series 0.9.1
[PATCH 3/4] Documentation/local_ops.txt: convert to ReST markup
... and move to core-api folder.
Signed-off-by: Silvio Fricke <silvio.fri...@gmail.com>
---
Documentation/core-api/index.rst | 1 +-
Documentation/core-api/local_ops.rst | 208 -
Documentation/local_ops.txt | 191 +--
3 files changed, 209 insertions(+), 191 deletions(-)
create mode 100644 Documentation/core-api/local_ops.rst
delete mode 100644 Documentation/local_ops.txt
diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst
index f3e5f5e..25b4e4a 100644
--- a/Documentation/core-api/index.rst
+++ b/Documentation/core-api/index.rst
@@ -9,6 +9,7 @@ Kernel and driver related documentation.
assoc_array
atomic_ops
+ local_ops
workqueue
.. only:: subproject
diff --git a/Documentation/core-api/local_ops.rst
b/Documentation/core-api/local_ops.rst
new file mode 100644
index 000..01f1880
--- /dev/null
+++ b/Documentation/core-api/local_ops.rst
@@ -0,0 +1,208 @@
+
+.. _local_ops:
+
+=
+Semantics and Behavior of Local Atomic Operations
+=
+
+:Author: Mathieu Desnoyers
+
+
+This document explains the purpose of the local atomic operations, how
+to implement them for any given architecture and shows how they can be used
+properly. It also stresses on the precautions that must be taken when reading
+those local variables across CPUs when the order of memory writes matters.
+
+.. note::
+
+Note that ``local_t`` based operations are not recommended for general
+kernel use. Please use the ``this_cpu`` operations instead unless there is
+really a special purpose. Most uses of ``local_t`` in the kernel have been
+replaced by ``this_cpu`` operations. ``this_cpu`` operations combine the
+relocation with the ``local_t`` like semantics in a single instruction and
+yield more compact and faster executing code.
+
+
+Purpose of local atomic operations
+==
+
+Local atomic operations are meant to provide fast and highly reentrant per CPU
+counters. They minimize the performance cost of standard atomic operations by
+removing the LOCK prefix and memory barriers normally required to synchronize
+across CPUs.
+
+Having fast per CPU atomic counters is interesting in many cases: it does not
+require disabling interrupts to protect from interrupt handlers and it permits
+coherent counters in NMI handlers. It is especially useful for tracing purposes
+and for various performance monitoring counters.
+
+Local atomic operations only guarantee variable modification atomicity wrt the
+CPU which owns the data. Therefore, care must taken to make sure that only one
+CPU writes to the ``local_t`` data. This is done by using per cpu data and
+making sure that we modify it from within a preemption safe context. It is
+however permitted to read ``local_t`` data from any CPU: it will then appear to
+be written out of order wrt other memory writes by the owner CPU.
+
+
+Implementation for a given architecture
+===
+
+It can be done by slightly modifying the standard atomic operations: only
+their UP variant must be kept. It typically means removing LOCK prefix (on
+i386 and x86_64) and any SMP synchronization barrier. If the architecture does
+not have a different behavior between SMP and UP, including
+``asm-generic/local.h`` in your architecture's ``local.h`` is sufficient.
+
+The ``local_t`` type is defined as an opaque ``signed long`` by embedding an
+``atomic_long_t`` inside a structure. This is made so a cast from this type to
+a ``long`` fails. The definition looks like::
+
+typedef struct { atomic_long_t a; } local_t;
+
+
+Rules to follow when using local atomic operations
+==
+
+* Variables touched by local ops must be per cpu variables.
+* *Only* the CPU owner of these variables must write to them.
+* This CPU can use local ops from any context (process, irq, softirq, nmi, ...)
+ to update its ``local_t`` variables.
+* Preemption (or interrupts) must be disabled when using local ops in
+ process context to make sure the process won't be migrated to a
+ different CPU between getting the per-cpu variable and doing the
+ actual local op.
+* When using local ops in interrupt context, no special care must be
+ taken on a mainline kernel, since they will run on the local CPU with
+ preemption already disabled. I suggest, however, to explicitly
+ disable preemption anyway to make sure it will still work correctly on
+ -rt kernels.
+* Reading the local cpu variable will provide the current copy of the
+ variable.
+* Reads of these variables can be done from any CPU, because updates to
+ "``long``", aligned, variables are always atomic. Since no memory
+ synchronization is done by the writer CPU, an outdated copy of the
+ variable can be read when reading some *other*
[PATCH 3/4] Documentation/local_ops.txt: convert to ReST markup
... and move to core-api folder.
Signed-off-by: Silvio Fricke
---
Documentation/core-api/index.rst | 1 +-
Documentation/core-api/local_ops.rst | 208 -
Documentation/local_ops.txt | 191 +--
3 files changed, 209 insertions(+), 191 deletions(-)
create mode 100644 Documentation/core-api/local_ops.rst
delete mode 100644 Documentation/local_ops.txt
diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst
index f3e5f5e..25b4e4a 100644
--- a/Documentation/core-api/index.rst
+++ b/Documentation/core-api/index.rst
@@ -9,6 +9,7 @@ Kernel and driver related documentation.
assoc_array
atomic_ops
+ local_ops
workqueue
.. only:: subproject
diff --git a/Documentation/core-api/local_ops.rst
b/Documentation/core-api/local_ops.rst
new file mode 100644
index 000..01f1880
--- /dev/null
+++ b/Documentation/core-api/local_ops.rst
@@ -0,0 +1,208 @@
+
+.. _local_ops:
+
+=
+Semantics and Behavior of Local Atomic Operations
+=
+
+:Author: Mathieu Desnoyers
+
+
+This document explains the purpose of the local atomic operations, how
+to implement them for any given architecture and shows how they can be used
+properly. It also stresses on the precautions that must be taken when reading
+those local variables across CPUs when the order of memory writes matters.
+
+.. note::
+
+Note that ``local_t`` based operations are not recommended for general
+kernel use. Please use the ``this_cpu`` operations instead unless there is
+really a special purpose. Most uses of ``local_t`` in the kernel have been
+replaced by ``this_cpu`` operations. ``this_cpu`` operations combine the
+relocation with the ``local_t`` like semantics in a single instruction and
+yield more compact and faster executing code.
+
+
+Purpose of local atomic operations
+==
+
+Local atomic operations are meant to provide fast and highly reentrant per CPU
+counters. They minimize the performance cost of standard atomic operations by
+removing the LOCK prefix and memory barriers normally required to synchronize
+across CPUs.
+
+Having fast per CPU atomic counters is interesting in many cases: it does not
+require disabling interrupts to protect from interrupt handlers and it permits
+coherent counters in NMI handlers. It is especially useful for tracing purposes
+and for various performance monitoring counters.
+
+Local atomic operations only guarantee variable modification atomicity wrt the
+CPU which owns the data. Therefore, care must taken to make sure that only one
+CPU writes to the ``local_t`` data. This is done by using per cpu data and
+making sure that we modify it from within a preemption safe context. It is
+however permitted to read ``local_t`` data from any CPU: it will then appear to
+be written out of order wrt other memory writes by the owner CPU.
+
+
+Implementation for a given architecture
+===
+
+It can be done by slightly modifying the standard atomic operations: only
+their UP variant must be kept. It typically means removing LOCK prefix (on
+i386 and x86_64) and any SMP synchronization barrier. If the architecture does
+not have a different behavior between SMP and UP, including
+``asm-generic/local.h`` in your architecture's ``local.h`` is sufficient.
+
+The ``local_t`` type is defined as an opaque ``signed long`` by embedding an
+``atomic_long_t`` inside a structure. This is made so a cast from this type to
+a ``long`` fails. The definition looks like::
+
+typedef struct { atomic_long_t a; } local_t;
+
+
+Rules to follow when using local atomic operations
+==
+
+* Variables touched by local ops must be per cpu variables.
+* *Only* the CPU owner of these variables must write to them.
+* This CPU can use local ops from any context (process, irq, softirq, nmi, ...)
+ to update its ``local_t`` variables.
+* Preemption (or interrupts) must be disabled when using local ops in
+ process context to make sure the process won't be migrated to a
+ different CPU between getting the per-cpu variable and doing the
+ actual local op.
+* When using local ops in interrupt context, no special care must be
+ taken on a mainline kernel, since they will run on the local CPU with
+ preemption already disabled. I suggest, however, to explicitly
+ disable preemption anyway to make sure it will still work correctly on
+ -rt kernels.
+* Reading the local cpu variable will provide the current copy of the
+ variable.
+* Reads of these variables can be done from any CPU, because updates to
+ "``long``", aligned, variables are always atomic. Since no memory
+ synchronization is done by the writer CPU, an outdated copy of the
+ variable can be read when reading some *other* cpu's variables.
+
+
+How to
[PATCH 2/4] Documentation/atomic_ops.txt: convert to ReST markup
... and move to core-api folder.
Signed-off-by: Silvio Fricke <silvio.fri...@gmail.com>
---
Documentation/atomic_ops.txt | 640 +---
Documentation/core-api/atomic_ops.rst | 669 +++-
Documentation/core-api/index.rst | 1 +-
Documentation/process/volatile-considered-harmful.rst | 3 +-
4 files changed, 673 insertions(+), 640 deletions(-)
delete mode 100644 Documentation/atomic_ops.txt
create mode 100644 Documentation/core-api/atomic_ops.rst
diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt
deleted file mode 100644
index 6c5e8a9..000
--- a/Documentation/atomic_ops.txt
+++ /dev/null
@@ -1,640 +0,0 @@
- Semantics and Behavior of Atomic and
-Bitmask Operations
-
- David S. Miller
-
- This document is intended to serve as a guide to Linux port
-maintainers on how to implement atomic counter, bitops, and spinlock
-interfaces properly.
-
- The atomic_t type should be defined as a signed integer and
-the atomic_long_t type as a signed long integer. Also, they should
-be made opaque such that any kind of cast to a normal C integer type
-will fail. Something like the following should suffice:
-
- typedef struct { int counter; } atomic_t;
- typedef struct { long counter; } atomic_long_t;
-
-Historically, counter has been declared volatile. This is now discouraged.
-See Documentation/process/volatile-considered-harmful.rst for the complete
rationale.
-
-local_t is very similar to atomic_t. If the counter is per CPU and only
-updated by one CPU, local_t is probably more appropriate. Please see
-Documentation/local_ops.txt for the semantics of local_t.
-
-The first operations to implement for atomic_t's are the initializers and
-plain reads.
-
- #define ATOMIC_INIT(i) { (i) }
- #define atomic_set(v, i)((v)->counter = (i))
-
-The first macro is used in definitions, such as:
-
-static atomic_t my_counter = ATOMIC_INIT(1);
-
-The initializer is atomic in that the return values of the atomic operations
-are guaranteed to be correct reflecting the initialized value if the
-initializer is used before runtime. If the initializer is used at runtime, a
-proper implicit or explicit read memory barrier is needed before reading the
-value with atomic_read from another thread.
-
-As with all of the atomic_ interfaces, replace the leading "atomic_"
-with "atomic_long_" to operate on atomic_long_t.
-
-The second interface can be used at runtime, as in:
-
- struct foo { atomic_t counter; };
- ...
-
- struct foo *k;
-
- k = kmalloc(sizeof(*k), GFP_KERNEL);
- if (!k)
- return -ENOMEM;
- atomic_set(>counter, 0);
-
-The setting is atomic in that the return values of the atomic operations by
-all threads are guaranteed to be correct reflecting either the value that has
-been set with this operation or set with another operation. A proper implicit
-or explicit memory barrier is needed before the value set with the operation
-is guaranteed to be readable with atomic_read from another thread.
-
-Next, we have:
-
- #define atomic_read(v) ((v)->counter)
-
-which simply reads the counter value currently visible to the calling thread.
-The read is atomic in that the return value is guaranteed to be one of the
-values initialized or modified with the interface operations if a proper
-implicit or explicit memory barrier is used after possible runtime
-initialization by any other thread and the value is modified only with the
-interface operations. atomic_read does not guarantee that the runtime
-initialization by any other thread is visible yet, so the user of the
-interface must take care of that with a proper implicit or explicit memory
-barrier.
-
-*** WARNING: atomic_read() and atomic_set() DO NOT IMPLY BARRIERS! ***
-
-Some architectures may choose to use the volatile keyword, barriers, or inline
-assembly to guarantee some degree of immediacy for atomic_read() and
-atomic_set(). This is not uniformly guaranteed, and may change in the future,
-so all users of atomic_t should treat atomic_read() and atomic_set() as simple
-C statements that may be reordered or optimized away entirely by the compiler
-or processor, and explicitly invoke the appropriate compiler and/or memory
-barrier for each use case. Failure to do so will result in code that may
-suddenly break when used with different architectures or compiler
-optimizations, or even changes in unrelated code which changes how the
-compiler optimizes the section accessing atomic_t variables.
-
-*** YOU HAVE BEEN WARNED! ***
-
-Properly aligned pointers, longs, ints, and chars (and unsigned
-equivalents) may be atomically loaded from and stored to in the same
-sense as described for atomic_read() and atomic_set(). The READ_ONCE()
-and WRITE_ONCE() macros sho
[PATCH 2/4] Documentation/atomic_ops.txt: convert to ReST markup
... and move to core-api folder.
Signed-off-by: Silvio Fricke
---
Documentation/atomic_ops.txt | 640 +---
Documentation/core-api/atomic_ops.rst | 669 +++-
Documentation/core-api/index.rst | 1 +-
Documentation/process/volatile-considered-harmful.rst | 3 +-
4 files changed, 673 insertions(+), 640 deletions(-)
delete mode 100644 Documentation/atomic_ops.txt
create mode 100644 Documentation/core-api/atomic_ops.rst
diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt
deleted file mode 100644
index 6c5e8a9..000
--- a/Documentation/atomic_ops.txt
+++ /dev/null
@@ -1,640 +0,0 @@
- Semantics and Behavior of Atomic and
-Bitmask Operations
-
- David S. Miller
-
- This document is intended to serve as a guide to Linux port
-maintainers on how to implement atomic counter, bitops, and spinlock
-interfaces properly.
-
- The atomic_t type should be defined as a signed integer and
-the atomic_long_t type as a signed long integer. Also, they should
-be made opaque such that any kind of cast to a normal C integer type
-will fail. Something like the following should suffice:
-
- typedef struct { int counter; } atomic_t;
- typedef struct { long counter; } atomic_long_t;
-
-Historically, counter has been declared volatile. This is now discouraged.
-See Documentation/process/volatile-considered-harmful.rst for the complete
rationale.
-
-local_t is very similar to atomic_t. If the counter is per CPU and only
-updated by one CPU, local_t is probably more appropriate. Please see
-Documentation/local_ops.txt for the semantics of local_t.
-
-The first operations to implement for atomic_t's are the initializers and
-plain reads.
-
- #define ATOMIC_INIT(i) { (i) }
- #define atomic_set(v, i)((v)->counter = (i))
-
-The first macro is used in definitions, such as:
-
-static atomic_t my_counter = ATOMIC_INIT(1);
-
-The initializer is atomic in that the return values of the atomic operations
-are guaranteed to be correct reflecting the initialized value if the
-initializer is used before runtime. If the initializer is used at runtime, a
-proper implicit or explicit read memory barrier is needed before reading the
-value with atomic_read from another thread.
-
-As with all of the atomic_ interfaces, replace the leading "atomic_"
-with "atomic_long_" to operate on atomic_long_t.
-
-The second interface can be used at runtime, as in:
-
- struct foo { atomic_t counter; };
- ...
-
- struct foo *k;
-
- k = kmalloc(sizeof(*k), GFP_KERNEL);
- if (!k)
- return -ENOMEM;
- atomic_set(>counter, 0);
-
-The setting is atomic in that the return values of the atomic operations by
-all threads are guaranteed to be correct reflecting either the value that has
-been set with this operation or set with another operation. A proper implicit
-or explicit memory barrier is needed before the value set with the operation
-is guaranteed to be readable with atomic_read from another thread.
-
-Next, we have:
-
- #define atomic_read(v) ((v)->counter)
-
-which simply reads the counter value currently visible to the calling thread.
-The read is atomic in that the return value is guaranteed to be one of the
-values initialized or modified with the interface operations if a proper
-implicit or explicit memory barrier is used after possible runtime
-initialization by any other thread and the value is modified only with the
-interface operations. atomic_read does not guarantee that the runtime
-initialization by any other thread is visible yet, so the user of the
-interface must take care of that with a proper implicit or explicit memory
-barrier.
-
-*** WARNING: atomic_read() and atomic_set() DO NOT IMPLY BARRIERS! ***
-
-Some architectures may choose to use the volatile keyword, barriers, or inline
-assembly to guarantee some degree of immediacy for atomic_read() and
-atomic_set(). This is not uniformly guaranteed, and may change in the future,
-so all users of atomic_t should treat atomic_read() and atomic_set() as simple
-C statements that may be reordered or optimized away entirely by the compiler
-or processor, and explicitly invoke the appropriate compiler and/or memory
-barrier for each use case. Failure to do so will result in code that may
-suddenly break when used with different architectures or compiler
-optimizations, or even changes in unrelated code which changes how the
-compiler optimizes the section accessing atomic_t variables.
-
-*** YOU HAVE BEEN WARNED! ***
-
-Properly aligned pointers, longs, ints, and chars (and unsigned
-equivalents) may be atomically loaded from and stored to in the same
-sense as described for atomic_read() and atomic_set(). The READ_ONCE()
-and WRITE_ONCE() macros should be used to prevent the compi
[PATCH 1/4] Documentation/assoc_array.txt: convert to ReST markup
... and move to Documentation/core-api folder.
Signed-off-by: Silvio Fricke <silvio.fri...@gmail.com>
---
Documentation/assoc_array.txt | 574 +--
Documentation/core-api/assoc_array.rst | 549 +-
Documentation/core-api/index.rst | 1 +-
3 files changed, 550 insertions(+), 574 deletions(-)
delete mode 100644 Documentation/assoc_array.txt
create mode 100644 Documentation/core-api/assoc_array.rst
diff --git a/Documentation/assoc_array.txt b/Documentation/assoc_array.txt
deleted file mode 100644
index 2f2c6cd..000
--- a/Documentation/assoc_array.txt
+++ /dev/null
@@ -1,574 +0,0 @@
-
- GENERIC ASSOCIATIVE ARRAY IMPLEMENTATION
-
-
-Contents:
-
- - Overview.
-
- - The public API.
- - Edit script.
- - Operations table.
- - Manipulation functions.
- - Access functions.
- - Index key form.
-
- - Internal workings.
- - Basic internal tree layout.
- - Shortcuts.
- - Splitting and collapsing nodes.
- - Non-recursive iteration.
- - Simultaneous alteration and iteration.
-
-
-
-OVERVIEW
-
-
-This associative array implementation is an object container with the following
-properties:
-
- (1) Objects are opaque pointers. The implementation does not care where they
- point (if anywhere) or what they point to (if anything).
-
- [!] NOTE: Pointers to objects _must_ be zero in the least significant bit.
-
- (2) Objects do not need to contain linkage blocks for use by the array. This
- permits an object to be located in multiple arrays simultaneously.
- Rather, the array is made up of metadata blocks that point to objects.
-
- (3) Objects require index keys to locate them within the array.
-
- (4) Index keys must be unique. Inserting an object with the same key as one
- already in the array will replace the old object.
-
- (5) Index keys can be of any length and can be of different lengths.
-
- (6) Index keys should encode the length early on, before any variation due to
- length is seen.
-
- (7) Index keys can include a hash to scatter objects throughout the array.
-
- (8) The array can iterated over. The objects will not necessarily come out in
- key order.
-
- (9) The array can be iterated over whilst it is being modified, provided the
- RCU readlock is being held by the iterator. Note, however, under these
- circumstances, some objects may be seen more than once. If this is a
- problem, the iterator should lock against modification. Objects will not
- be missed, however, unless deleted.
-
-(10) Objects in the array can be looked up by means of their index key.
-
-(11) Objects can be looked up whilst the array is being modified, provided the
- RCU readlock is being held by the thread doing the look up.
-
-The implementation uses a tree of 16-pointer nodes internally that are indexed
-on each level by nibbles from the index key in the same manner as in a radix
-tree. To improve memory efficiency, shortcuts can be emplaced to skip over
-what would otherwise be a series of single-occupancy nodes. Further, nodes
-pack leaf object pointers into spare space in the node rather than making an
-extra branch until as such time an object needs to be added to a full node.
-
-
-==
-THE PUBLIC API
-==
-
-The public API can be found in . The associative array is
-rooted on the following structure:
-
- struct assoc_array {
- ...
- };
-
-The code is selected by enabling CONFIG_ASSOCIATIVE_ARRAY.
-
-
-EDIT SCRIPT
-
-The insertion and deletion functions produce an 'edit script' that can later be
-applied to effect the changes without risking ENOMEM. This retains the
-preallocated metadata blocks that will be installed in the internal tree and
-keeps track of the metadata blocks that will be removed from the tree when the
-script is applied.
-
-This is also used to keep track of dead blocks and dead objects after the
-script has been applied so that they can be freed later. The freeing is done
-after an RCU grace period has passed - thus allowing access functions to
-proceed under the RCU read lock.
-
-The script appears as outside of the API as a pointer of the type:
-
- struct assoc_array_edit;
-
-There are two functions for dealing with the script:
-
- (1) Apply an edit script.
-
- void assoc_array_apply_edit(struct assoc_array_edit *edit);
-
- This will perform the edit functions, interpolating various write barriers
- to permit accesses under the RCU read lock to continue. The edit script
- will then be passed to call_rcu() to free it and any dead stuff it points
- to.
-
- (2) Cancel an edit script.
-
- void assoc_array_cancel_edit(struct assoc_array_edit *edit);
-
- This frees the edit script and all preallocated memory immed
[PATCH 1/4] Documentation/assoc_array.txt: convert to ReST markup
... and move to Documentation/core-api folder.
Signed-off-by: Silvio Fricke
---
Documentation/assoc_array.txt | 574 +--
Documentation/core-api/assoc_array.rst | 549 +-
Documentation/core-api/index.rst | 1 +-
3 files changed, 550 insertions(+), 574 deletions(-)
delete mode 100644 Documentation/assoc_array.txt
create mode 100644 Documentation/core-api/assoc_array.rst
diff --git a/Documentation/assoc_array.txt b/Documentation/assoc_array.txt
deleted file mode 100644
index 2f2c6cd..000
--- a/Documentation/assoc_array.txt
+++ /dev/null
@@ -1,574 +0,0 @@
-
- GENERIC ASSOCIATIVE ARRAY IMPLEMENTATION
-
-
-Contents:
-
- - Overview.
-
- - The public API.
- - Edit script.
- - Operations table.
- - Manipulation functions.
- - Access functions.
- - Index key form.
-
- - Internal workings.
- - Basic internal tree layout.
- - Shortcuts.
- - Splitting and collapsing nodes.
- - Non-recursive iteration.
- - Simultaneous alteration and iteration.
-
-
-
-OVERVIEW
-
-
-This associative array implementation is an object container with the following
-properties:
-
- (1) Objects are opaque pointers. The implementation does not care where they
- point (if anywhere) or what they point to (if anything).
-
- [!] NOTE: Pointers to objects _must_ be zero in the least significant bit.
-
- (2) Objects do not need to contain linkage blocks for use by the array. This
- permits an object to be located in multiple arrays simultaneously.
- Rather, the array is made up of metadata blocks that point to objects.
-
- (3) Objects require index keys to locate them within the array.
-
- (4) Index keys must be unique. Inserting an object with the same key as one
- already in the array will replace the old object.
-
- (5) Index keys can be of any length and can be of different lengths.
-
- (6) Index keys should encode the length early on, before any variation due to
- length is seen.
-
- (7) Index keys can include a hash to scatter objects throughout the array.
-
- (8) The array can iterated over. The objects will not necessarily come out in
- key order.
-
- (9) The array can be iterated over whilst it is being modified, provided the
- RCU readlock is being held by the iterator. Note, however, under these
- circumstances, some objects may be seen more than once. If this is a
- problem, the iterator should lock against modification. Objects will not
- be missed, however, unless deleted.
-
-(10) Objects in the array can be looked up by means of their index key.
-
-(11) Objects can be looked up whilst the array is being modified, provided the
- RCU readlock is being held by the thread doing the look up.
-
-The implementation uses a tree of 16-pointer nodes internally that are indexed
-on each level by nibbles from the index key in the same manner as in a radix
-tree. To improve memory efficiency, shortcuts can be emplaced to skip over
-what would otherwise be a series of single-occupancy nodes. Further, nodes
-pack leaf object pointers into spare space in the node rather than making an
-extra branch until as such time an object needs to be added to a full node.
-
-
-==
-THE PUBLIC API
-==
-
-The public API can be found in . The associative array is
-rooted on the following structure:
-
- struct assoc_array {
- ...
- };
-
-The code is selected by enabling CONFIG_ASSOCIATIVE_ARRAY.
-
-
-EDIT SCRIPT
-
-The insertion and deletion functions produce an 'edit script' that can later be
-applied to effect the changes without risking ENOMEM. This retains the
-preallocated metadata blocks that will be installed in the internal tree and
-keeps track of the metadata blocks that will be removed from the tree when the
-script is applied.
-
-This is also used to keep track of dead blocks and dead objects after the
-script has been applied so that they can be freed later. The freeing is done
-after an RCU grace period has passed - thus allowing access functions to
-proceed under the RCU read lock.
-
-The script appears as outside of the API as a pointer of the type:
-
- struct assoc_array_edit;
-
-There are two functions for dealing with the script:
-
- (1) Apply an edit script.
-
- void assoc_array_apply_edit(struct assoc_array_edit *edit);
-
- This will perform the edit functions, interpolating various write barriers
- to permit accesses under the RCU read lock to continue. The edit script
- will then be passed to call_rcu() to free it and any dead stuff it points
- to.
-
- (2) Cancel an edit script.
-
- void assoc_array_cancel_edit(struct assoc_array_edit *edit);
-
- This frees the edit script and all preallocated memory immediately. If
- this was for insertion
[PATCH 4/4] firmware: remove warning at documentation generation time
This patch removes following error at for `make htmldocs`. No functional change. ./drivers/base/firmware_class.c:1348: WARNING: Bullet list ends without a blank line; unexpected unindent. Signed-off-by: Silvio Fricke <silvio.fri...@gmail.com> --- drivers/base/firmware_class.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c index 22d1760..37b0221 100644 --- a/drivers/base/firmware_class.c +++ b/drivers/base/firmware_class.c @@ -1345,9 +1345,9 @@ static void request_firmware_work_func(struct work_struct *work) * * Asynchronous variant of request_firmware() for user contexts: * - sleep for as small periods as possible since it may - * increase kernel boot time of built-in device drivers - * requesting firmware in their ->probe() methods, if - * @gfp is GFP_KERNEL. + * increase kernel boot time of built-in device drivers + * requesting firmware in their ->probe() methods, if + * @gfp is GFP_KERNEL. * * - can't sleep at all if @gfp is GFP_ATOMIC. **/ -- git-series 0.9.1
[PATCH 0/4] core-api ReST: assoc_array, atomic_ops, local_ops
Hi, Some more ReSTification of core-api's: assoc_array, atomic_ops and local_ops. A fourth patch removes a warning about a bullet list without ending at firmware_class.c Thanks for review. BR Silvio Silvio Fricke (4): Documentation/assoc_array.txt: convert to ReST markup Documentation/atomic_ops.txt: convert to ReST markup Documentation/local_ops.txt: convert to ReST markup firmware: remove warning at documentation generation time Documentation/assoc_array.txt | 574 +- Documentation/atomic_ops.txt | 640 +--- Documentation/core-api/assoc_array.rst| 549 +- Documentation/core-api/atomic_ops.rst | 669 +++- Documentation/core-api/index.rst | 3 +- Documentation/core-api/local_ops.rst | 208 +++- Documentation/local_ops.txt | 191 +--- Documentation/process/volatile-considered-harmful.rst | 3 +- drivers/base/firmware_class.c | 6 +- 9 files changed, 1435 insertions(+), 1408 deletions(-) delete mode 100644 Documentation/assoc_array.txt delete mode 100644 Documentation/atomic_ops.txt create mode 100644 Documentation/core-api/assoc_array.rst create mode 100644 Documentation/core-api/atomic_ops.rst create mode 100644 Documentation/core-api/local_ops.rst delete mode 100644 Documentation/local_ops.txt base-commit: 9c240d757658a3ae9968dd309e674c61f07c7f48 -- git-series 0.9.1
[PATCH 0/4] core-api ReST: assoc_array, atomic_ops, local_ops
Hi, Some more ReSTification of core-api's: assoc_array, atomic_ops and local_ops. A fourth patch removes a warning about a bullet list without ending at firmware_class.c Thanks for review. BR Silvio Silvio Fricke (4): Documentation/assoc_array.txt: convert to ReST markup Documentation/atomic_ops.txt: convert to ReST markup Documentation/local_ops.txt: convert to ReST markup firmware: remove warning at documentation generation time Documentation/assoc_array.txt | 574 +- Documentation/atomic_ops.txt | 640 +--- Documentation/core-api/assoc_array.rst| 549 +- Documentation/core-api/atomic_ops.rst | 669 +++- Documentation/core-api/index.rst | 3 +- Documentation/core-api/local_ops.rst | 208 +++- Documentation/local_ops.txt | 191 +--- Documentation/process/volatile-considered-harmful.rst | 3 +- drivers/base/firmware_class.c | 6 +- 9 files changed, 1435 insertions(+), 1408 deletions(-) delete mode 100644 Documentation/assoc_array.txt delete mode 100644 Documentation/atomic_ops.txt create mode 100644 Documentation/core-api/assoc_array.rst create mode 100644 Documentation/core-api/atomic_ops.rst create mode 100644 Documentation/core-api/local_ops.rst delete mode 100644 Documentation/local_ops.txt base-commit: 9c240d757658a3ae9968dd309e674c61f07c7f48 -- git-series 0.9.1
[PATCH 4/4] firmware: remove warning at documentation generation time
This patch removes following error at for `make htmldocs`. No functional change. ./drivers/base/firmware_class.c:1348: WARNING: Bullet list ends without a blank line; unexpected unindent. Signed-off-by: Silvio Fricke --- drivers/base/firmware_class.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c index 22d1760..37b0221 100644 --- a/drivers/base/firmware_class.c +++ b/drivers/base/firmware_class.c @@ -1345,9 +1345,9 @@ static void request_firmware_work_func(struct work_struct *work) * * Asynchronous variant of request_firmware() for user contexts: * - sleep for as small periods as possible since it may - * increase kernel boot time of built-in device drivers - * requesting firmware in their ->probe() methods, if - * @gfp is GFP_KERNEL. + * increase kernel boot time of built-in device drivers + * requesting firmware in their ->probe() methods, if + * @gfp is GFP_KERNEL. * * - can't sleep at all if @gfp is GFP_ATOMIC. **/ -- git-series 0.9.1
[PATCH] Input: stmpe-ts: add chip threshold function
Signed-off-by: Silvio Fricke
---
.../bindings/input/touchscreen/stmpe.txt | 3 ++
drivers/input/touchscreen/stmpe-ts.c | 38 +++---
include/linux/mfd/stmpe.h | 1 +
3 files changed, 31 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
index 127baa3..586f1e7 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
@@ -23,6 +23,8 @@ Optional properties:
the fractional part) recommended is 7
- st,i-drive: current limit value of the touchscreen drivers (0 -> 20 mA
typical 35
mA max, 1 -> 50 mA typical 80 mA max)
+- st,fifo-threshold: size of samples in chip internal buffer. Needs to be
+ between 1 and 127, defaults to 1
Node name must be stmpe_touchscreen and should be child node of stmpe node to
which it belongs.
@@ -40,4 +42,5 @@ Example:
st,settling = <2>;
st,fraction-z = <7>;
st,i-drive = <1>;
+ st,fifo-threshold = <10>;
};
diff --git a/drivers/input/touchscreen/stmpe-ts.c
b/drivers/input/touchscreen/stmpe-ts.c
index 2d5ff86..a40e573 100644
--- a/drivers/input/touchscreen/stmpe-ts.c
+++ b/drivers/input/touchscreen/stmpe-ts.c
@@ -37,8 +37,12 @@
#define STMPE_REG_FIFO_TH 0x4A
#define STMPE_REG_FIFO_STA 0x4B
#define STMPE_REG_FIFO_SIZE0x4C
+#define STMPE_REG_TSC_DATA_X 0x4d
+#define STMPE_REG_TSC_DATA_Y 0x4f
+#define STMPE_REG_TSC_DATA_Z 0x51
#define STMPE_REG_TSC_DATA_XYZ 0x52
#define STMPE_REG_TSC_FRACTION_Z 0x56
+#define STMPE_REG_TSC_DATA 0xD7
#define STMPE_REG_TSC_I_DRIVE 0x58
#define OP_MOD_XYZ 0
@@ -48,6 +52,7 @@
#define STMPE_FIFO_STA_RESET (1<<0)
#define STMPE_IRQ_TOUCH_DET0
+#define STMPE_IRQ_FIFO_TH 1
#define SAMPLE_TIME(x) ((x & 0xf) << 4)
#define MOD_12B(x) ((x & 0x1) << 3)
@@ -77,6 +82,7 @@ struct stmpe_touch {
u8 settling;
u8 fraction_z;
u8 i_drive;
+ u8 threshold;
};
static int __stmpe_reset_fifo(struct stmpe *stmpe)
@@ -126,7 +132,7 @@ static void stmpe_work(struct work_struct *work)
static irqreturn_t stmpe_ts_handler(int irq, void *data)
{
u8 data_set[4];
- int x, y, z;
+ int x, y, z, i, fsize;
struct stmpe_touch *ts = data;
/*
@@ -144,17 +150,21 @@ static irqreturn_t stmpe_ts_handler(int irq, void *data)
stmpe_set_bits(ts->stmpe, STMPE_REG_TSC_CTRL,
STMPE_TSC_CTRL_TSC_EN, 0);
- stmpe_block_read(ts->stmpe, STMPE_REG_TSC_DATA_XYZ, 4, data_set);
+ fsize = stmpe_reg_read(ts->stmpe, STMPE_REG_FIFO_SIZE);
- x = (data_set[0] << 4) | (data_set[1] >> 4);
- y = ((data_set[1] & 0xf) << 8) | data_set[2];
- z = data_set[3];
+ for (i = 0; i < fsize; i++) {
+ stmpe_block_read(ts->stmpe, STMPE_REG_TSC_DATA, 4, data_set);
- input_report_abs(ts->idev, ABS_X, x);
- input_report_abs(ts->idev, ABS_Y, y);
- input_report_abs(ts->idev, ABS_PRESSURE, z);
- input_report_key(ts->idev, BTN_TOUCH, 1);
- input_sync(ts->idev);
+ x = (data_set[0] << 4) | (data_set[1] >> 4);
+ y = ((data_set[1] & 0xf) << 8) | data_set[2];
+ z = data_set[3];
+
+ input_report_abs(ts->idev, ABS_X, x);
+ input_report_abs(ts->idev, ABS_Y, y);
+ input_report_abs(ts->idev, ABS_PRESSURE, z);
+ input_report_key(ts->idev, BTN_TOUCH, 1);
+ input_sync(ts->idev);
+ }
/* flush the FIFO after we have read out our values. */
__stmpe_reset_fifo(ts->stmpe);
@@ -225,7 +235,7 @@ static int stmpe_init_hw(struct stmpe_touch *ts)
}
/* set FIFO to 1 for single point reading */
- ret = stmpe_reg_write(stmpe, STMPE_REG_FIFO_TH, 1);
+ ret = stmpe_reg_write(stmpe, STMPE_REG_FIFO_TH, ts->threshold);
if (ret) {
dev_err(dev, "Could not set FIFO\n");
return ret;
@@ -285,6 +295,7 @@ static void stmpe_ts_get_platform_info(struct
platform_device *pdev,
ts->settling = ts_pdata->settling;
ts->fraction_z = ts_pdata->fraction_z;
ts->i_drive = ts_pdata->i_drive;
+ ts->threshold = ts_pdata->threshold;
} else if (np) {
u32 val;
@@ -306,7 +317,12 @@ static void stmpe_ts_get_platform_info(struct
platform_device *pdev,
ts
[PATCH] stmpe_ts: add usage of threshold function
Hi, This patch adds treshold functionality for the stmpe811 touchscreen controller. Please review, comment or include it to your repository. Best regards, Silvio Silvio Fricke (1): Input: stmpe-ts: add chip threshold function .../bindings/input/touchscreen/stmpe.txt | 3 ++ drivers/input/touchscreen/stmpe-ts.c | 38 +++--- include/linux/mfd/stmpe.h | 1 + 3 files changed, 31 insertions(+), 11 deletions(-) -- 2.4.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Input: stmpe-ts: add chip threshold function
Signed-off-by: Silvio Fricke silvio.fri...@gmail.com
---
.../bindings/input/touchscreen/stmpe.txt | 3 ++
drivers/input/touchscreen/stmpe-ts.c | 38 +++---
include/linux/mfd/stmpe.h | 1 +
3 files changed, 31 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
index 127baa3..586f1e7 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
@@ -23,6 +23,8 @@ Optional properties:
the fractional part) recommended is 7
- st,i-drive: current limit value of the touchscreen drivers (0 - 20 mA
typical 35
mA max, 1 - 50 mA typical 80 mA max)
+- st,fifo-threshold: size of samples in chip internal buffer. Needs to be
+ between 1 and 127, defaults to 1
Node name must be stmpe_touchscreen and should be child node of stmpe node to
which it belongs.
@@ -40,4 +42,5 @@ Example:
st,settling = 2;
st,fraction-z = 7;
st,i-drive = 1;
+ st,fifo-threshold = 10;
};
diff --git a/drivers/input/touchscreen/stmpe-ts.c
b/drivers/input/touchscreen/stmpe-ts.c
index 2d5ff86..a40e573 100644
--- a/drivers/input/touchscreen/stmpe-ts.c
+++ b/drivers/input/touchscreen/stmpe-ts.c
@@ -37,8 +37,12 @@
#define STMPE_REG_FIFO_TH 0x4A
#define STMPE_REG_FIFO_STA 0x4B
#define STMPE_REG_FIFO_SIZE0x4C
+#define STMPE_REG_TSC_DATA_X 0x4d
+#define STMPE_REG_TSC_DATA_Y 0x4f
+#define STMPE_REG_TSC_DATA_Z 0x51
#define STMPE_REG_TSC_DATA_XYZ 0x52
#define STMPE_REG_TSC_FRACTION_Z 0x56
+#define STMPE_REG_TSC_DATA 0xD7
#define STMPE_REG_TSC_I_DRIVE 0x58
#define OP_MOD_XYZ 0
@@ -48,6 +52,7 @@
#define STMPE_FIFO_STA_RESET (10)
#define STMPE_IRQ_TOUCH_DET0
+#define STMPE_IRQ_FIFO_TH 1
#define SAMPLE_TIME(x) ((x 0xf) 4)
#define MOD_12B(x) ((x 0x1) 3)
@@ -77,6 +82,7 @@ struct stmpe_touch {
u8 settling;
u8 fraction_z;
u8 i_drive;
+ u8 threshold;
};
static int __stmpe_reset_fifo(struct stmpe *stmpe)
@@ -126,7 +132,7 @@ static void stmpe_work(struct work_struct *work)
static irqreturn_t stmpe_ts_handler(int irq, void *data)
{
u8 data_set[4];
- int x, y, z;
+ int x, y, z, i, fsize;
struct stmpe_touch *ts = data;
/*
@@ -144,17 +150,21 @@ static irqreturn_t stmpe_ts_handler(int irq, void *data)
stmpe_set_bits(ts-stmpe, STMPE_REG_TSC_CTRL,
STMPE_TSC_CTRL_TSC_EN, 0);
- stmpe_block_read(ts-stmpe, STMPE_REG_TSC_DATA_XYZ, 4, data_set);
+ fsize = stmpe_reg_read(ts-stmpe, STMPE_REG_FIFO_SIZE);
- x = (data_set[0] 4) | (data_set[1] 4);
- y = ((data_set[1] 0xf) 8) | data_set[2];
- z = data_set[3];
+ for (i = 0; i fsize; i++) {
+ stmpe_block_read(ts-stmpe, STMPE_REG_TSC_DATA, 4, data_set);
- input_report_abs(ts-idev, ABS_X, x);
- input_report_abs(ts-idev, ABS_Y, y);
- input_report_abs(ts-idev, ABS_PRESSURE, z);
- input_report_key(ts-idev, BTN_TOUCH, 1);
- input_sync(ts-idev);
+ x = (data_set[0] 4) | (data_set[1] 4);
+ y = ((data_set[1] 0xf) 8) | data_set[2];
+ z = data_set[3];
+
+ input_report_abs(ts-idev, ABS_X, x);
+ input_report_abs(ts-idev, ABS_Y, y);
+ input_report_abs(ts-idev, ABS_PRESSURE, z);
+ input_report_key(ts-idev, BTN_TOUCH, 1);
+ input_sync(ts-idev);
+ }
/* flush the FIFO after we have read out our values. */
__stmpe_reset_fifo(ts-stmpe);
@@ -225,7 +235,7 @@ static int stmpe_init_hw(struct stmpe_touch *ts)
}
/* set FIFO to 1 for single point reading */
- ret = stmpe_reg_write(stmpe, STMPE_REG_FIFO_TH, 1);
+ ret = stmpe_reg_write(stmpe, STMPE_REG_FIFO_TH, ts-threshold);
if (ret) {
dev_err(dev, Could not set FIFO\n);
return ret;
@@ -285,6 +295,7 @@ static void stmpe_ts_get_platform_info(struct
platform_device *pdev,
ts-settling = ts_pdata-settling;
ts-fraction_z = ts_pdata-fraction_z;
ts-i_drive = ts_pdata-i_drive;
+ ts-threshold = ts_pdata-threshold;
} else if (np) {
u32 val;
@@ -306,7 +317,12 @@ static void stmpe_ts_get_platform_info(struct
platform_device *pdev,
ts-fraction_z = val;
if (!of_property_read_u32(np, st,i-drive, val))
ts-i_drive = val;
+ if (!of_property_read_u32(np, st,threshold, val))
+ ts-threshold
[PATCH] stmpe_ts: add usage of threshold function
Hi, This patch adds treshold functionality for the stmpe811 touchscreen controller. Please review, comment or include it to your repository. Best regards, Silvio Silvio Fricke (1): Input: stmpe-ts: add chip threshold function .../bindings/input/touchscreen/stmpe.txt | 3 ++ drivers/input/touchscreen/stmpe-ts.c | 38 +++--- include/linux/mfd/stmpe.h | 1 + 3 files changed, 31 insertions(+), 11 deletions(-) -- 2.4.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] ARM: tegra: dts: remove unused irq-trigger entry
Signed-off-by: Silvio Fricke
CC: Thomas Gleixner
CC: Jason Cooper
CC: Marc Zyngier
---
arch/arm/boot/dts/tegra30-apalis.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra30-apalis.dtsi
b/arch/arm/boot/dts/tegra30-apalis.dtsi
index a5446cb..c2a7528 100644
--- a/arch/arm/boot/dts/tegra30-apalis.dtsi
+++ b/arch/arm/boot/dts/tegra30-apalis.dtsi
@@ -540,7 +540,6 @@
interrupt-controller;
id = <0>;
blocks = <0x5>;
- irq-trigger = <0x1>;
stmpe_touchscreen {
compatible = "st,stmpe-ts";
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] removing of some unused/unsupported dts entries
Hi, I have found some dts entries which are not evaluated by the drivers. This patch remove this entries from the dts files. Jason has mentioned I should CC: Thomas, Marc and him self to this mails. thanks and best regards, Silvio Silvio Fricke (3): ARM: mx5: dts: remove unused irq-trigger entry ARM: tegra: dts: remove unused irq-trigger entry ARM: SPEAr: dts: remove unused irq-trigger, id and block entries arch/arm/boot/dts/imx53-m53.dtsi | 1 - arch/arm/boot/dts/spear1310-evb.dts | 1 - arch/arm/boot/dts/spear1340-evb.dts | 2 -- arch/arm/boot/dts/spear320-hmi.dts| 3 --- arch/arm/boot/dts/tegra30-apalis.dtsi | 1 - 5 files changed, 8 deletions(-) -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] ARM: SPEAr: dts: remove unused irq-trigger, id and block entries
Signed-off-by: Silvio Fricke
CC: Thomas Gleixner
CC: Jason Cooper
CC: Marc Zyngier
---
arch/arm/boot/dts/spear1310-evb.dts | 1 -
arch/arm/boot/dts/spear1340-evb.dts | 2 --
arch/arm/boot/dts/spear320-hmi.dts | 3 ---
3 files changed, 6 deletions(-)
diff --git a/arch/arm/boot/dts/spear1310-evb.dts
b/arch/arm/boot/dts/spear1310-evb.dts
index d42c84b..95c2ff1 100644
--- a/arch/arm/boot/dts/spear1310-evb.dts
+++ b/arch/arm/boot/dts/spear1310-evb.dts
@@ -369,7 +369,6 @@
pl022,duplex = <0>;
interrupts = <6 0x4>;
interrupt-parent = <>;
- irq-trigger = <0x2>;
stmpe_touchscreen {
compatible = "st,stmpe-ts";
diff --git a/arch/arm/boot/dts/spear1340-evb.dts
b/arch/arm/boot/dts/spear1340-evb.dts
index b23e05e..bba3389 100644
--- a/arch/arm/boot/dts/spear1340-evb.dts
+++ b/arch/arm/boot/dts/spear1340-evb.dts
@@ -325,7 +325,6 @@
reg = <0x41>;
interrupts = <4 0x4>;
interrupt-parent = <>;
- irq-trigger = <0x2>;
stmpegpio: stmpe_gpio {
compatible = "st,stmpe-gpio";
@@ -478,7 +477,6 @@
pl022,duplex = <0>;
interrupts = <100 0>;
interrupt-parent = <>;
- irq-trigger = <0x2>;
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/spear320-hmi.dts
b/arch/arm/boot/dts/spear320-hmi.dts
index 0aa6fef..f8ed01e 100644
--- a/arch/arm/boot/dts/spear320-hmi.dts
+++ b/arch/arm/boot/dts/spear320-hmi.dts
@@ -243,9 +243,6 @@
reg = <0x41>;
irq-over-gpio;
irq-gpios = < 29 0x4>;
- id = <0>;
- blocks = <0x5>;
- irq-trigger = <0x1>;
stmpegpio: stmpe-gpio {
compatible = "stmpe,gpio";
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ARM: mx5: dts: remove unused irq-trigger entry
Signed-off-by: Silvio Fricke
CC: Thomas Gleixner
CC: Jason Cooper
CC: Marc Zyngier
---
arch/arm/boot/dts/imx53-m53.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx53-m53.dtsi b/arch/arm/boot/dts/imx53-m53.dtsi
index 87a7fc7..8a5acb5 100644
--- a/arch/arm/boot/dts/imx53-m53.dtsi
+++ b/arch/arm/boot/dts/imx53-m53.dtsi
@@ -60,7 +60,6 @@
blocks = <0x5>;
interrupts = <6 0x0>;
interrupt-parent = <>;
- irq-trigger = <0x1>;
stmpe_touchscreen {
compatible = "st,stmpe-ts";
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] ARM: SPEAr: dts: remove unused irq-trigger, id and block entries
Signed-off-by: Silvio Fricke silvio.fri...@gmail.com
CC: Thomas Gleixner t...@linutronix.de
CC: Jason Cooper ja...@lakedaemon.net
CC: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/boot/dts/spear1310-evb.dts | 1 -
arch/arm/boot/dts/spear1340-evb.dts | 2 --
arch/arm/boot/dts/spear320-hmi.dts | 3 ---
3 files changed, 6 deletions(-)
diff --git a/arch/arm/boot/dts/spear1310-evb.dts
b/arch/arm/boot/dts/spear1310-evb.dts
index d42c84b..95c2ff1 100644
--- a/arch/arm/boot/dts/spear1310-evb.dts
+++ b/arch/arm/boot/dts/spear1310-evb.dts
@@ -369,7 +369,6 @@
pl022,duplex = 0;
interrupts = 6 0x4;
interrupt-parent = gpio1;
- irq-trigger = 0x2;
stmpe_touchscreen {
compatible = st,stmpe-ts;
diff --git a/arch/arm/boot/dts/spear1340-evb.dts
b/arch/arm/boot/dts/spear1340-evb.dts
index b23e05e..bba3389 100644
--- a/arch/arm/boot/dts/spear1340-evb.dts
+++ b/arch/arm/boot/dts/spear1340-evb.dts
@@ -325,7 +325,6 @@
reg = 0x41;
interrupts = 4 0x4;
interrupt-parent = gpio0;
- irq-trigger = 0x2;
stmpegpio: stmpe_gpio {
compatible = st,stmpe-gpio;
@@ -478,7 +477,6 @@
pl022,duplex = 0;
interrupts = 100 0;
interrupt-parent = gpiopinctrl;
- irq-trigger = 0x2;
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/arm/boot/dts/spear320-hmi.dts
b/arch/arm/boot/dts/spear320-hmi.dts
index 0aa6fef..f8ed01e 100644
--- a/arch/arm/boot/dts/spear320-hmi.dts
+++ b/arch/arm/boot/dts/spear320-hmi.dts
@@ -243,9 +243,6 @@
reg = 0x41;
irq-over-gpio;
irq-gpios = gpiopinctrl 29 0x4;
- id = 0;
- blocks = 0x5;
- irq-trigger = 0x1;
stmpegpio: stmpe-gpio {
compatible = stmpe,gpio;
--
2.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ARM: mx5: dts: remove unused irq-trigger entry
Signed-off-by: Silvio Fricke silvio.fri...@gmail.com
CC: Thomas Gleixner t...@linutronix.de
CC: Jason Cooper ja...@lakedaemon.net
CC: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/boot/dts/imx53-m53.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx53-m53.dtsi b/arch/arm/boot/dts/imx53-m53.dtsi
index 87a7fc7..8a5acb5 100644
--- a/arch/arm/boot/dts/imx53-m53.dtsi
+++ b/arch/arm/boot/dts/imx53-m53.dtsi
@@ -60,7 +60,6 @@
blocks = 0x5;
interrupts = 6 0x0;
interrupt-parent = gpio7;
- irq-trigger = 0x1;
stmpe_touchscreen {
compatible = st,stmpe-ts;
--
2.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] removing of some unused/unsupported dts entries
Hi, I have found some dts entries which are not evaluated by the drivers. This patch remove this entries from the dts files. Jason has mentioned I should CC: Thomas, Marc and him self to this mails. thanks and best regards, Silvio Silvio Fricke (3): ARM: mx5: dts: remove unused irq-trigger entry ARM: tegra: dts: remove unused irq-trigger entry ARM: SPEAr: dts: remove unused irq-trigger, id and block entries arch/arm/boot/dts/imx53-m53.dtsi | 1 - arch/arm/boot/dts/spear1310-evb.dts | 1 - arch/arm/boot/dts/spear1340-evb.dts | 2 -- arch/arm/boot/dts/spear320-hmi.dts| 3 --- arch/arm/boot/dts/tegra30-apalis.dtsi | 1 - 5 files changed, 8 deletions(-) -- 2.1.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] ARM: tegra: dts: remove unused irq-trigger entry
Signed-off-by: Silvio Fricke silvio.fri...@gmail.com
CC: Thomas Gleixner t...@linutronix.de
CC: Jason Cooper ja...@lakedaemon.net
CC: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/boot/dts/tegra30-apalis.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra30-apalis.dtsi
b/arch/arm/boot/dts/tegra30-apalis.dtsi
index a5446cb..c2a7528 100644
--- a/arch/arm/boot/dts/tegra30-apalis.dtsi
+++ b/arch/arm/boot/dts/tegra30-apalis.dtsi
@@ -540,7 +540,6 @@
interrupt-controller;
id = 0;
blocks = 0x5;
- irq-trigger = 0x1;
stmpe_touchscreen {
compatible = st,stmpe-ts;
--
2.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] kconfig: menuconfig: pkg-config should base upon default configuration
Since fc9c6e0 "menuconfig: optionally use pkg-config to detect ncurses
libs" we use pkg-config, but some cross toolchains (like yocto tc)
change the search pathes for pc files with some PKG_CONFIG_* environment
variables.
With this patch we ensure that we only get the host config options for
ncurses and don't mix with others not relevant settings.
Signed-off-by: Silvio Fricke
---
scripts/kconfig/lxdialog/check-lxdialog.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/scripts/kconfig/lxdialog/check-lxdialog.sh
b/scripts/kconfig/lxdialog/check-lxdialog.sh
index 9d2a4c5..a067d3c 100644
--- a/scripts/kconfig/lxdialog/check-lxdialog.sh
+++ b/scripts/kconfig/lxdialog/check-lxdialog.sh
@@ -1,6 +1,9 @@
#!/bin/sh
# Check ncurses compatibility
+unset PKG_CONFIG_PATH
+unset PKG_CONFIG_SYSROOT_DIR
+
# What library to link
ldflags()
{
--
2.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] pkg-config default search paths
Hi, some cross-toolchains change the pkg-config search pathes to do some package-config setups for cross compiling. The init of the toolchain manipulates PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_PATH environment variables. A pkg-config call from kconfig searches now on the wrong place to find the ncurses and relevant packages and gives back the wrong values for the ncurses installation and this break the [x,g,menu]config. Yann, please include this patch to your maintainer repository. V2: no changes to v1 [1], only "RFC" removed [1] http://thread.gmane.org/gmane.linux.kbuild.devel/11993 Cheers, Silvio Silvio Fricke (1): kconfig: menuconfig: pkg-config should base upon default configuration scripts/kconfig/lxdialog/check-lxdialog.sh | 3 +++ 1 file changed, 3 insertions(+) -- 2.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] kconfig: menuconfig: pkg-config should base upon default configuration
Since fc9c6e0 menuconfig: optionally use pkg-config to detect ncurses
libs we use pkg-config, but some cross toolchains (like yocto tc)
change the search pathes for pc files with some PKG_CONFIG_* environment
variables.
With this patch we ensure that we only get the host config options for
ncurses and don't mix with others not relevant settings.
Signed-off-by: Silvio Fricke silvio.fri...@gmail.com
---
scripts/kconfig/lxdialog/check-lxdialog.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/scripts/kconfig/lxdialog/check-lxdialog.sh
b/scripts/kconfig/lxdialog/check-lxdialog.sh
index 9d2a4c5..a067d3c 100644
--- a/scripts/kconfig/lxdialog/check-lxdialog.sh
+++ b/scripts/kconfig/lxdialog/check-lxdialog.sh
@@ -1,6 +1,9 @@
#!/bin/sh
# Check ncurses compatibility
+unset PKG_CONFIG_PATH
+unset PKG_CONFIG_SYSROOT_DIR
+
# What library to link
ldflags()
{
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] pkg-config default search paths
Hi, some cross-toolchains change the pkg-config search pathes to do some package-config setups for cross compiling. The init of the toolchain manipulates PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_PATH environment variables. A pkg-config call from kconfig searches now on the wrong place to find the ncurses and relevant packages and gives back the wrong values for the ncurses installation and this break the [x,g,menu]config. Yann, please include this patch to your maintainer repository. V2: no changes to v1 [1], only RFC removed [1] http://thread.gmane.org/gmane.linux.kbuild.devel/11993 Cheers, Silvio Silvio Fricke (1): kconfig: menuconfig: pkg-config should base upon default configuration scripts/kconfig/lxdialog/check-lxdialog.sh | 3 +++ 1 file changed, 3 insertions(+) -- 2.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: dts: imx6: edmqmx6: add vcc and vio power supplies to stmpe
Signed-off-by: Silvio Fricke
---
arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
b/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
index e4ae38f..8fa08aa 100644
--- a/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
+++ b/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
@@ -216,6 +216,8 @@
reg = <0x40>;
interrupts = <30 0>;
interrupt-parent = <>;
+ vcc-supply = <_reg>;
+ vio-supply = <_reg>;
stmpe_gpio1: stmpe_gpio {
#gpio-cells = <2>;
@@ -228,6 +230,8 @@
reg = <0x44>;
interrupts = <2 0>;
interrupt-parent = <>;
+ vcc-supply = <_reg>;
+ vio-supply = <_reg>;
stmpe_gpio2: stmpe_gpio {
#gpio-cells = <2>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] mfd/gpio: cleanup of STMPE driver
Hi, I have tested this patches with my data-modul imx6q board. So the patches get a: Tested-by: Silvio Fricke Shawn, can you add this patch to your tree if you pull Linus patches? Thx and Cheers, Silvio Silvio Fricke (1): ARM: dts: imx6: edmqmx6: add vcc and vio power supplies to stmpe arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts | 4 1 file changed, 4 insertions(+) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] mfd/gpio: cleanup of STMPE driver
Hi, I have tested this patches with my data-modul imx6q board. So the patches get a: Tested-by: Silvio Fricke silvio.fri...@gmail.com Shawn, can you add this patch to your tree if you pull Linus patches? Thx and Cheers, Silvio Silvio Fricke (1): ARM: dts: imx6: edmqmx6: add vcc and vio power supplies to stmpe arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts | 4 1 file changed, 4 insertions(+) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: dts: imx6: edmqmx6: add vcc and vio power supplies to stmpe
Signed-off-by: Silvio Fricke silvio.fri...@gmail.com
---
arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
b/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
index e4ae38f..8fa08aa 100644
--- a/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
+++ b/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
@@ -216,6 +216,8 @@
reg = 0x40;
interrupts = 30 0;
interrupt-parent = gpio3;
+ vcc-supply = sw2_reg;
+ vio-supply = sw2_reg;
stmpe_gpio1: stmpe_gpio {
#gpio-cells = 2;
@@ -228,6 +230,8 @@
reg = 0x44;
interrupts = 2 0;
interrupt-parent = gpio5;
+ vcc-supply = sw2_reg;
+ vio-supply = sw2_reg;
stmpe_gpio2: stmpe_gpio {
#gpio-cells = 2;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/3] staging: vt6655: removed incorrect casting in iwctl.c
This patch fixes the following type of sparse warning:
drivers/staging/vt6655/iwctl.c:1846:35: warning: cast from restricted gfp_t
Signed-off-by: Silvio Fricke
---
drivers/staging/vt6655/iwctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vt6655/iwctl.c b/drivers/staging/vt6655/iwctl.c
index ac3fc16..5e25535 100644
--- a/drivers/staging/vt6655/iwctl.c
+++ b/drivers/staging/vt6655/iwctl.c
@@ -1843,7 +1843,7 @@ int iwctl_siwencodeext(struct net_device *dev,
PRINT_K("SIOCSIWENCODEEXT.. \n");
blen = sizeof(*param);
- buf = kmalloc((int)blen, (int)GFP_KERNEL);
+ buf = kmalloc((int)blen, GFP_KERNEL);
if (buf == NULL)
return -ENOMEM;
memset(buf, 0, blen);
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/3] remove wrong cast of gfp_t flags
Hi, > > thanks for your review. > > Attached second version of this series. > > I don't understand what the [WIP] marking is. Please just resend these > as "real" patches if you feel they are ready to be merged. If we have > issues with them, we will be sure to let you know :) I removed it. Bye, Silvio v3: * no 'WIP'! Don't do that! v2: * signed-off and message are not the same address Silvio Fricke (3): staging: vt6655: removed incorrect casting in wpactl.c staging: vt6655: removed incorrect casting in ioctl.c staging: vt6655: removed incorrect casting in iwctl.c drivers/staging/vt6655/ioctl.c | 6 -- drivers/staging/vt6655/iwctl.c | 2 +- drivers/staging/vt6655/wpactl.c | 6 +++--- 3 files changed, 8 insertions(+), 6 deletions(-) -- 1.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/3] staging: vt6655: removed incorrect casting in ioctl.c
This patch fixes the following type of sparse warnings:
drivers/staging/vt6655/ioctl.c:308:104: warning: cast from restricted gfp_t
drivers/staging/vt6655/ioctl.c:579:109: warning: cast from restricted gfp_t
Signed-off-by: Silvio Fricke
---
drivers/staging/vt6655/ioctl.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/vt6655/ioctl.c b/drivers/staging/vt6655/ioctl.c
index b5cd2e4..1de5d2c9 100644
--- a/drivers/staging/vt6655/ioctl.c
+++ b/drivers/staging/vt6655/ioctl.c
@@ -305,7 +305,8 @@ int private_ioctl(PSDevice pDevice, struct ifreq *rq)
result = -EINVAL;
break;
}
- pList = (PSBSSIDList)kmalloc(sizeof(SBSSIDList) + (sList.uItem
* sizeof(SBSSIDItem)), (int)GFP_ATOMIC);
+ pList = (PSBSSIDList)kmalloc(sizeof(SBSSIDList) + (sList.uItem
* sizeof(SBSSIDItem)),
+GFP_ATOMIC);
if (pList == NULL) {
result = -ENOMEM;
break;
@@ -576,7 +577,8 @@ int private_ioctl(PSDevice pDevice, struct ifreq *rq)
result = -EINVAL;
break;
}
- pNodeList = (PSNodeList)kmalloc(sizeof(SNodeList) +
(sNodeList.uItem * sizeof(SNodeItem)), (int)GFP_ATOMIC);
+ pNodeList = (PSNodeList)kmalloc(sizeof(SNodeList) +
(sNodeList.uItem * sizeof(SNodeItem)),
+ GFP_ATOMIC);
if (pNodeList == NULL) {
result = -ENOMEM;
break;
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/3] staging: vt6655: removed incorrect casting in wpactl.c
This patch fixes the following type of sparse warnings:
drivers/staging/vt6655/wpactl.c:596:47: warning: cast from restricted gfp_t
drivers/staging/vt6655/wpactl.c:638:68: warning: cast from restricted gfp_t
drivers/staging/vt6655/wpactl.c:860:42: warning: cast from restricted gfp_t
Signed-off-by: Silvio Fricke
---
drivers/staging/vt6655/wpactl.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/vt6655/wpactl.c b/drivers/staging/vt6655/wpactl.c
index d17224f..4745429 100644
--- a/drivers/staging/vt6655/wpactl.c
+++ b/drivers/staging/vt6655/wpactl.c
@@ -593,7 +593,7 @@ static int wpa_get_scan(PSDevice pDevice,
unsigned char *ptempBSS;
- ptempBSS = kmalloc(sizeof(KnownBSS), (int)GFP_ATOMIC);
+ ptempBSS = kmalloc(sizeof(KnownBSS), GFP_ATOMIC);
if (ptempBSS == NULL) {
printk(KERN_ERR "bubble sort kmalloc memory fail@@@\n");
@@ -635,7 +635,7 @@ static int wpa_get_scan(PSDevice pDevice,
count++;
}
- pBuf = kcalloc(count, sizeof(struct viawget_scan_result),
(int)GFP_ATOMIC);
+ pBuf = kcalloc(count, sizeof(struct viawget_scan_result), GFP_ATOMIC);
if (pBuf == NULL) {
ret = -ENOMEM;
@@ -857,7 +857,7 @@ int wpa_ioctl(PSDevice pDevice, struct iw_point *p)
p->length > VIAWGET_WPA_MAX_BUF_SIZE || !p->pointer)
return -EINVAL;
- param = kmalloc((int)p->length, (int)GFP_KERNEL);
+ param = kmalloc((int)p->length, GFP_KERNEL);
if (param == NULL)
return -ENOMEM;
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/3] remove wrong cast of gfp_t flags
Hi, thanks for your review. Attached second version of this series. I don't understand what the [WIP] marking is. Please just resend these as real patches if you feel they are ready to be merged. If we have issues with them, we will be sure to let you know :) I removed it. Bye, Silvio v3: * no 'WIP'! Don't do that! v2: * signed-off and message are not the same address Silvio Fricke (3): staging: vt6655: removed incorrect casting in wpactl.c staging: vt6655: removed incorrect casting in ioctl.c staging: vt6655: removed incorrect casting in iwctl.c drivers/staging/vt6655/ioctl.c | 6 -- drivers/staging/vt6655/iwctl.c | 2 +- drivers/staging/vt6655/wpactl.c | 6 +++--- 3 files changed, 8 insertions(+), 6 deletions(-) -- 1.9.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/3] staging: vt6655: removed incorrect casting in ioctl.c
This patch fixes the following type of sparse warnings:
drivers/staging/vt6655/ioctl.c:308:104: warning: cast from restricted gfp_t
drivers/staging/vt6655/ioctl.c:579:109: warning: cast from restricted gfp_t
Signed-off-by: Silvio Fricke silvio.fri...@gmail.com
---
drivers/staging/vt6655/ioctl.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/vt6655/ioctl.c b/drivers/staging/vt6655/ioctl.c
index b5cd2e4..1de5d2c9 100644
--- a/drivers/staging/vt6655/ioctl.c
+++ b/drivers/staging/vt6655/ioctl.c
@@ -305,7 +305,8 @@ int private_ioctl(PSDevice pDevice, struct ifreq *rq)
result = -EINVAL;
break;
}
- pList = (PSBSSIDList)kmalloc(sizeof(SBSSIDList) + (sList.uItem
* sizeof(SBSSIDItem)), (int)GFP_ATOMIC);
+ pList = (PSBSSIDList)kmalloc(sizeof(SBSSIDList) + (sList.uItem
* sizeof(SBSSIDItem)),
+GFP_ATOMIC);
if (pList == NULL) {
result = -ENOMEM;
break;
@@ -576,7 +577,8 @@ int private_ioctl(PSDevice pDevice, struct ifreq *rq)
result = -EINVAL;
break;
}
- pNodeList = (PSNodeList)kmalloc(sizeof(SNodeList) +
(sNodeList.uItem * sizeof(SNodeItem)), (int)GFP_ATOMIC);
+ pNodeList = (PSNodeList)kmalloc(sizeof(SNodeList) +
(sNodeList.uItem * sizeof(SNodeItem)),
+ GFP_ATOMIC);
if (pNodeList == NULL) {
result = -ENOMEM;
break;
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/3] staging: vt6655: removed incorrect casting in wpactl.c
This patch fixes the following type of sparse warnings:
drivers/staging/vt6655/wpactl.c:596:47: warning: cast from restricted gfp_t
drivers/staging/vt6655/wpactl.c:638:68: warning: cast from restricted gfp_t
drivers/staging/vt6655/wpactl.c:860:42: warning: cast from restricted gfp_t
Signed-off-by: Silvio Fricke silvio.fri...@gmail.com
---
drivers/staging/vt6655/wpactl.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/vt6655/wpactl.c b/drivers/staging/vt6655/wpactl.c
index d17224f..4745429 100644
--- a/drivers/staging/vt6655/wpactl.c
+++ b/drivers/staging/vt6655/wpactl.c
@@ -593,7 +593,7 @@ static int wpa_get_scan(PSDevice pDevice,
unsigned char *ptempBSS;
- ptempBSS = kmalloc(sizeof(KnownBSS), (int)GFP_ATOMIC);
+ ptempBSS = kmalloc(sizeof(KnownBSS), GFP_ATOMIC);
if (ptempBSS == NULL) {
printk(KERN_ERR bubble sort kmalloc memory fail@@@\n);
@@ -635,7 +635,7 @@ static int wpa_get_scan(PSDevice pDevice,
count++;
}
- pBuf = kcalloc(count, sizeof(struct viawget_scan_result),
(int)GFP_ATOMIC);
+ pBuf = kcalloc(count, sizeof(struct viawget_scan_result), GFP_ATOMIC);
if (pBuf == NULL) {
ret = -ENOMEM;
@@ -857,7 +857,7 @@ int wpa_ioctl(PSDevice pDevice, struct iw_point *p)
p-length VIAWGET_WPA_MAX_BUF_SIZE || !p-pointer)
return -EINVAL;
- param = kmalloc((int)p-length, (int)GFP_KERNEL);
+ param = kmalloc((int)p-length, GFP_KERNEL);
if (param == NULL)
return -ENOMEM;
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/3] staging: vt6655: removed incorrect casting in iwctl.c
This patch fixes the following type of sparse warning: drivers/staging/vt6655/iwctl.c:1846:35: warning: cast from restricted gfp_t Signed-off-by: Silvio Fricke silvio.fri...@gmail.com --- drivers/staging/vt6655/iwctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/vt6655/iwctl.c b/drivers/staging/vt6655/iwctl.c index ac3fc16..5e25535 100644 --- a/drivers/staging/vt6655/iwctl.c +++ b/drivers/staging/vt6655/iwctl.c @@ -1843,7 +1843,7 @@ int iwctl_siwencodeext(struct net_device *dev, PRINT_K(SIOCSIWENCODEEXT.. \n); blen = sizeof(*param); - buf = kmalloc((int)blen, (int)GFP_KERNEL); + buf = kmalloc((int)blen, GFP_KERNEL); if (buf == NULL) return -ENOMEM; memset(buf, 0, blen); -- 1.9.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[WIP] [PATCH v2 0/3] remove wrong cast of gfp_t flags
Hi Dan, thanks for your review. Attached second version of this series. Cheers, Silvio Silvio Fricke (3): staging: vt6655: removed incorrect casting in wpactl.c staging: vt6655: removed incorrect casting in ioctl.c staging: vt6655: removed incorrect casting in iwctl.c drivers/staging/vt6655/ioctl.c | 6 -- drivers/staging/vt6655/iwctl.c | 2 +- drivers/staging/vt6655/wpactl.c | 6 +++--- 3 files changed, 8 insertions(+), 6 deletions(-) -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[WIP] [PATCH v2 3/3] staging: vt6655: removed incorrect casting in iwctl.c
This patch fixes the following type of sparse warning:
drivers/staging/vt6655/iwctl.c:1846:35: warning: cast from restricted gfp_t
Signed-off-by: Silvio Fricke
---
drivers/staging/vt6655/iwctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vt6655/iwctl.c b/drivers/staging/vt6655/iwctl.c
index ac3fc16..5e25535 100644
--- a/drivers/staging/vt6655/iwctl.c
+++ b/drivers/staging/vt6655/iwctl.c
@@ -1843,7 +1843,7 @@ int iwctl_siwencodeext(struct net_device *dev,
PRINT_K("SIOCSIWENCODEEXT.. \n");
blen = sizeof(*param);
- buf = kmalloc((int)blen, (int)GFP_KERNEL);
+ buf = kmalloc((int)blen, GFP_KERNEL);
if (buf == NULL)
return -ENOMEM;
memset(buf, 0, blen);
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[WIP] [PATCH v2 1/3] staging: vt6655: removed incorrect casting in wpactl.c
This patch fixes the following type of sparse warnings:
drivers/staging/vt6655/wpactl.c:596:47: warning: cast from restricted gfp_t
drivers/staging/vt6655/wpactl.c:638:68: warning: cast from restricted gfp_t
drivers/staging/vt6655/wpactl.c:860:42: warning: cast from restricted gfp_t
Signed-off-by: Silvio Fricke
---
drivers/staging/vt6655/wpactl.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/vt6655/wpactl.c b/drivers/staging/vt6655/wpactl.c
index d17224f..4745429 100644
--- a/drivers/staging/vt6655/wpactl.c
+++ b/drivers/staging/vt6655/wpactl.c
@@ -593,7 +593,7 @@ static int wpa_get_scan(PSDevice pDevice,
unsigned char *ptempBSS;
- ptempBSS = kmalloc(sizeof(KnownBSS), (int)GFP_ATOMIC);
+ ptempBSS = kmalloc(sizeof(KnownBSS), GFP_ATOMIC);
if (ptempBSS == NULL) {
printk(KERN_ERR "bubble sort kmalloc memory fail@@@\n");
@@ -635,7 +635,7 @@ static int wpa_get_scan(PSDevice pDevice,
count++;
}
- pBuf = kcalloc(count, sizeof(struct viawget_scan_result),
(int)GFP_ATOMIC);
+ pBuf = kcalloc(count, sizeof(struct viawget_scan_result), GFP_ATOMIC);
if (pBuf == NULL) {
ret = -ENOMEM;
@@ -857,7 +857,7 @@ int wpa_ioctl(PSDevice pDevice, struct iw_point *p)
p->length > VIAWGET_WPA_MAX_BUF_SIZE || !p->pointer)
return -EINVAL;
- param = kmalloc((int)p->length, (int)GFP_KERNEL);
+ param = kmalloc((int)p->length, GFP_KERNEL);
if (param == NULL)
return -ENOMEM;
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[WIP] [PATCH v2 2/3] staging: vt6655: removed incorrect casting in ioctl.c
This patch fixes the following type of sparse warnings:
drivers/staging/vt6655/ioctl.c:308:104: warning: cast from restricted gfp_t
drivers/staging/vt6655/ioctl.c:579:109: warning: cast from restricted gfp_t
Signed-off-by: Silvio Fricke
---
drivers/staging/vt6655/ioctl.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/vt6655/ioctl.c b/drivers/staging/vt6655/ioctl.c
index b5cd2e4..1de5d2c9 100644
--- a/drivers/staging/vt6655/ioctl.c
+++ b/drivers/staging/vt6655/ioctl.c
@@ -305,7 +305,8 @@ int private_ioctl(PSDevice pDevice, struct ifreq *rq)
result = -EINVAL;
break;
}
- pList = (PSBSSIDList)kmalloc(sizeof(SBSSIDList) + (sList.uItem
* sizeof(SBSSIDItem)), (int)GFP_ATOMIC);
+ pList = (PSBSSIDList)kmalloc(sizeof(SBSSIDList) + (sList.uItem
* sizeof(SBSSIDItem)),
+GFP_ATOMIC);
if (pList == NULL) {
result = -ENOMEM;
break;
@@ -576,7 +577,8 @@ int private_ioctl(PSDevice pDevice, struct ifreq *rq)
result = -EINVAL;
break;
}
- pNodeList = (PSNodeList)kmalloc(sizeof(SNodeList) +
(sNodeList.uItem * sizeof(SNodeItem)), (int)GFP_ATOMIC);
+ pNodeList = (PSNodeList)kmalloc(sizeof(SNodeList) +
(sNodeList.uItem * sizeof(SNodeItem)),
+ GFP_ATOMIC);
if (pNodeList == NULL) {
result = -ENOMEM;
break;
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[WIP] [PATCH v2 2/3] staging: vt6655: removed incorrect casting in ioctl.c
This patch fixes the following type of sparse warnings:
drivers/staging/vt6655/ioctl.c:308:104: warning: cast from restricted gfp_t
drivers/staging/vt6655/ioctl.c:579:109: warning: cast from restricted gfp_t
Signed-off-by: Silvio Fricke silvio.fri...@gmail.com
---
drivers/staging/vt6655/ioctl.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/vt6655/ioctl.c b/drivers/staging/vt6655/ioctl.c
index b5cd2e4..1de5d2c9 100644
--- a/drivers/staging/vt6655/ioctl.c
+++ b/drivers/staging/vt6655/ioctl.c
@@ -305,7 +305,8 @@ int private_ioctl(PSDevice pDevice, struct ifreq *rq)
result = -EINVAL;
break;
}
- pList = (PSBSSIDList)kmalloc(sizeof(SBSSIDList) + (sList.uItem
* sizeof(SBSSIDItem)), (int)GFP_ATOMIC);
+ pList = (PSBSSIDList)kmalloc(sizeof(SBSSIDList) + (sList.uItem
* sizeof(SBSSIDItem)),
+GFP_ATOMIC);
if (pList == NULL) {
result = -ENOMEM;
break;
@@ -576,7 +577,8 @@ int private_ioctl(PSDevice pDevice, struct ifreq *rq)
result = -EINVAL;
break;
}
- pNodeList = (PSNodeList)kmalloc(sizeof(SNodeList) +
(sNodeList.uItem * sizeof(SNodeItem)), (int)GFP_ATOMIC);
+ pNodeList = (PSNodeList)kmalloc(sizeof(SNodeList) +
(sNodeList.uItem * sizeof(SNodeItem)),
+ GFP_ATOMIC);
if (pNodeList == NULL) {
result = -ENOMEM;
break;
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[WIP] [PATCH v2 1/3] staging: vt6655: removed incorrect casting in wpactl.c
This patch fixes the following type of sparse warnings:
drivers/staging/vt6655/wpactl.c:596:47: warning: cast from restricted gfp_t
drivers/staging/vt6655/wpactl.c:638:68: warning: cast from restricted gfp_t
drivers/staging/vt6655/wpactl.c:860:42: warning: cast from restricted gfp_t
Signed-off-by: Silvio Fricke silvio.fri...@gmail.com
---
drivers/staging/vt6655/wpactl.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/vt6655/wpactl.c b/drivers/staging/vt6655/wpactl.c
index d17224f..4745429 100644
--- a/drivers/staging/vt6655/wpactl.c
+++ b/drivers/staging/vt6655/wpactl.c
@@ -593,7 +593,7 @@ static int wpa_get_scan(PSDevice pDevice,
unsigned char *ptempBSS;
- ptempBSS = kmalloc(sizeof(KnownBSS), (int)GFP_ATOMIC);
+ ptempBSS = kmalloc(sizeof(KnownBSS), GFP_ATOMIC);
if (ptempBSS == NULL) {
printk(KERN_ERR bubble sort kmalloc memory fail@@@\n);
@@ -635,7 +635,7 @@ static int wpa_get_scan(PSDevice pDevice,
count++;
}
- pBuf = kcalloc(count, sizeof(struct viawget_scan_result),
(int)GFP_ATOMIC);
+ pBuf = kcalloc(count, sizeof(struct viawget_scan_result), GFP_ATOMIC);
if (pBuf == NULL) {
ret = -ENOMEM;
@@ -857,7 +857,7 @@ int wpa_ioctl(PSDevice pDevice, struct iw_point *p)
p-length VIAWGET_WPA_MAX_BUF_SIZE || !p-pointer)
return -EINVAL;
- param = kmalloc((int)p-length, (int)GFP_KERNEL);
+ param = kmalloc((int)p-length, GFP_KERNEL);
if (param == NULL)
return -ENOMEM;
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[WIP] [PATCH v2 3/3] staging: vt6655: removed incorrect casting in iwctl.c
This patch fixes the following type of sparse warning: drivers/staging/vt6655/iwctl.c:1846:35: warning: cast from restricted gfp_t Signed-off-by: Silvio Fricke silvio.fri...@gmail.com --- drivers/staging/vt6655/iwctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/vt6655/iwctl.c b/drivers/staging/vt6655/iwctl.c index ac3fc16..5e25535 100644 --- a/drivers/staging/vt6655/iwctl.c +++ b/drivers/staging/vt6655/iwctl.c @@ -1843,7 +1843,7 @@ int iwctl_siwencodeext(struct net_device *dev, PRINT_K(SIOCSIWENCODEEXT.. \n); blen = sizeof(*param); - buf = kmalloc((int)blen, (int)GFP_KERNEL); + buf = kmalloc((int)blen, GFP_KERNEL); if (buf == NULL) return -ENOMEM; memset(buf, 0, blen); -- 1.9.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[WIP] [PATCH v2 0/3] remove wrong cast of gfp_t flags
Hi Dan, thanks for your review. Attached second version of this series. Cheers, Silvio Silvio Fricke (3): staging: vt6655: removed incorrect casting in wpactl.c staging: vt6655: removed incorrect casting in ioctl.c staging: vt6655: removed incorrect casting in iwctl.c drivers/staging/vt6655/ioctl.c | 6 -- drivers/staging/vt6655/iwctl.c | 2 +- drivers/staging/vt6655/wpactl.c | 6 +++--- 3 files changed, 8 insertions(+), 6 deletions(-) -- 1.9.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
