[PATCH 02/14] workqueue: add wq_numa_tbl_len and wq_numa_possible_cpumask[]
Unbound workqueues are going to be NUMA-affine. Add wq_numa_tbl_len
and wq_numa_possible_cpumask[] in preparation. The former is the
highest NUMA node ID + 1 and the latter is masks of possibles CPUs for
each NUMA node.
This patch only introduces these. Future patches will make use of
them.
v2: NUMA initialization move into wq_numa_init(). Also, the possible
cpumask array is not created if there aren't multiple nodes on the
system. wq_numa_enabled bool added.
Signed-off-by: Tejun Heo
---
kernel/workqueue.c | 46 ++
1 file changed, 46 insertions(+)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 26771f4e..54b5048 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -44,6 +44,7 @@
#include
#include
#include
+#include
#include "workqueue_internal.h"
@@ -253,6 +254,12 @@ struct workqueue_struct {
static struct kmem_cache *pwq_cache;
+static int wq_numa_tbl_len;/* highest possible NUMA node id + 1 */
+static cpumask_var_t *wq_numa_possible_cpumask;
+ /* possible CPUs of each node */
+
+static bool wq_numa_enabled; /* unbound NUMA affinity enabled */
+
static DEFINE_MUTEX(wq_pool_mutex);/* protects pools and workqueues list */
static DEFINE_SPINLOCK(wq_mayday_lock);/* protects wq->maydays list */
@@ -4402,6 +4409,43 @@ out_unlock:
}
#endif /* CONFIG_FREEZER */
+static void __init wq_numa_init(void)
+{
+ cpumask_var_t *tbl;
+ int node, cpu;
+
+ /* determine NUMA pwq table len - highest node id + 1 */
+ for_each_node(node)
+ wq_numa_tbl_len = max(wq_numa_tbl_len, node + 1);
+
+ if (num_possible_nodes() <= 1)
+ return;
+
+ /*
+* We want masks of possible CPUs of each node which isn't readily
+* available. Build one from cpu_to_node() which should have been
+* fully initialized by now.
+*/
+ tbl = kzalloc(wq_numa_tbl_len * sizeof(tbl[0]), GFP_KERNEL);
+ BUG_ON(!tbl);
+
+ for_each_node(node)
+ BUG_ON(!alloc_cpumask_var_node(&tbl[node], GFP_KERNEL, node));
+
+ for_each_possible_cpu(cpu) {
+ node = cpu_to_node(cpu);
+ if (WARN_ON(node == NUMA_NO_NODE)) {
+ pr_warn("workqueue: NUMA node mapping not available for
cpu%d, disabling NUMA support\n", cpu);
+ /* happens iff arch is bonkers, let's just proceed */
+ return;
+ }
+ cpumask_set_cpu(cpu, tbl[node]);
+ }
+
+ wq_numa_possible_cpumask = tbl;
+ wq_numa_enabled = true;
+}
+
static int __init init_workqueues(void)
{
int std_nice[NR_STD_WORKER_POOLS] = { 0, HIGHPRI_NICE_LEVEL };
@@ -4418,6 +4462,8 @@ static int __init init_workqueues(void)
cpu_notifier(workqueue_cpu_up_callback, CPU_PRI_WORKQUEUE_UP);
hotcpu_notifier(workqueue_cpu_down_callback, CPU_PRI_WORKQUEUE_DOWN);
+ wq_numa_init();
+
/* initialize CPU pools */
for_each_possible_cpu(cpu) {
struct worker_pool *pool;
--
1.8.1.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 12/14] workqueue: introduce put_pwq_unlocked()
Factor out lock pool, put_pwq(), unlock sequence into
put_pwq_unlocked(). The two existing places are converted and there
will be more with NUMA affinity support.
This is to prepare for NUMA affinity support for unbound workqueues
and doesn't introduce any functional difference.
Signed-off-by: Tejun Heo
---
kernel/workqueue.c | 36 +++-
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 527dc418..e656931 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1057,6 +1057,25 @@ static void put_pwq(struct pool_workqueue *pwq)
schedule_work(&pwq->unbound_release_work);
}
+/**
+ * put_pwq_unlocked - put_pwq() with surrounding pool lock/unlock
+ * @pwq: pool_workqueue to put (can be %NULL)
+ *
+ * put_pwq() with locking. This function also allows %NULL @pwq.
+ */
+static void put_pwq_unlocked(struct pool_workqueue *pwq)
+{
+ if (pwq) {
+ /*
+* As both pwqs and pools are sched-RCU protected, the
+* following lock operations are safe.
+*/
+ spin_lock_irq(&pwq->pool->lock);
+ put_pwq(pwq);
+ spin_unlock_irq(&pwq->pool->lock);
+ }
+}
+
static void pwq_activate_delayed_work(struct work_struct *work)
{
struct pool_workqueue *pwq = get_work_pwq(work);
@@ -3759,12 +3778,7 @@ int apply_workqueue_attrs(struct workqueue_struct *wq,
mutex_unlock(&wq->mutex);
- if (last_pwq) {
- spin_lock_irq(&last_pwq->pool->lock);
- put_pwq(last_pwq);
- spin_unlock_irq(&last_pwq->pool->lock);
- }
-
+ put_pwq_unlocked(last_pwq);
return 0;
enomem:
@@ -3975,16 +3989,12 @@ void destroy_workqueue(struct workqueue_struct *wq)
} else {
/*
* We're the sole accessor of @wq at this point. Directly
-* access the first pwq and put the base ref. As both pwqs
-* and pools are sched-RCU protected, the lock operations
-* are safe. @wq will be freed when the last pwq is
-* released.
+* access the first pwq and put the base ref. @wq will be
+* freed when the last pwq is released.
*/
pwq = list_first_entry(&wq->pwqs, struct pool_workqueue,
pwqs_node);
- spin_lock_irq(&pwq->pool->lock);
- put_pwq(pwq);
- spin_unlock_irq(&pwq->pool->lock);
+ put_pwq_unlocked(pwq);
}
}
EXPORT_SYMBOL_GPL(destroy_workqueue);
--
1.8.1.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 05/14] workqueue: add workqueue->unbound_attrs
Currently, when exposing attrs of an unbound workqueue via sysfs, the
workqueue_attrs of first_pwq() is used as that should equal the
current state of the workqueue.
The planned NUMA affinity support will make unbound workqueues make
use of multiple pool_workqueues for different NUMA nodes and the above
assumption will no longer hold. Introduce workqueue->unbound_attrs
which records the current attrs in effect and use it for sysfs instead
of first_pwq()->attrs.
Signed-off-by: Tejun Heo
---
kernel/workqueue.c | 36
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index fab2630..65f200c 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -244,6 +244,8 @@ struct workqueue_struct {
int nr_drainers;/* WQ: drain in progress */
int saved_max_active; /* WQ: saved pwq max_active */
+ struct workqueue_attrs *unbound_attrs; /* WQ: only for unbound wqs */
+
#ifdef CONFIG_SYSFS
struct wq_device*wq_dev;/* I: for sysfs interface */
#endif
@@ -3088,10 +3090,9 @@ static ssize_t wq_nice_show(struct device *dev, struct
device_attribute *attr,
struct workqueue_struct *wq = dev_to_wq(dev);
int written;
- rcu_read_lock_sched();
- written = scnprintf(buf, PAGE_SIZE, "%d\n",
- first_pwq(wq)->pool->attrs->nice);
- rcu_read_unlock_sched();
+ mutex_lock(&wq->mutex);
+ written = scnprintf(buf, PAGE_SIZE, "%d\n", wq->unbound_attrs->nice);
+ mutex_unlock(&wq->mutex);
return written;
}
@@ -3105,9 +3106,9 @@ static struct workqueue_attrs *wq_sysfs_prep_attrs(struct
workqueue_struct *wq)
if (!attrs)
return NULL;
- rcu_read_lock_sched();
- copy_workqueue_attrs(attrs, first_pwq(wq)->pool->attrs);
- rcu_read_unlock_sched();
+ mutex_lock(&wq->mutex);
+ copy_workqueue_attrs(attrs, wq->unbound_attrs);
+ mutex_unlock(&wq->mutex);
return attrs;
}
@@ -3138,10 +3139,9 @@ static ssize_t wq_cpumask_show(struct device *dev,
struct workqueue_struct *wq = dev_to_wq(dev);
int written;
- rcu_read_lock_sched();
- written = cpumask_scnprintf(buf, PAGE_SIZE,
- first_pwq(wq)->pool->attrs->cpumask);
- rcu_read_unlock_sched();
+ mutex_lock(&wq->mutex);
+ written = cpumask_scnprintf(buf, PAGE_SIZE, wq->unbound_attrs->cpumask);
+ mutex_unlock(&wq->mutex);
written += scnprintf(buf + written, PAGE_SIZE - written, "\n");
return written;
@@ -3558,8 +3558,10 @@ static void pwq_unbound_release_workfn(struct
work_struct *work)
* If we're the last pwq going away, @wq is already dead and no one
* is gonna access it anymore. Free it.
*/
- if (is_last)
+ if (is_last) {
+ free_workqueue_attrs(wq->unbound_attrs);
kfree(wq);
+ }
}
/**
@@ -3634,6 +3636,9 @@ static void init_and_link_pwq(struct pool_workqueue *pwq,
/* link in @pwq */
list_add_rcu(&pwq->pwqs_node, &wq->pwqs);
+ if (wq->flags & WQ_UNBOUND)
+ copy_workqueue_attrs(wq->unbound_attrs, pool->attrs);
+
mutex_unlock(&wq->mutex);
}
@@ -3761,6 +3766,12 @@ struct workqueue_struct *__alloc_workqueue_key(const
char *fmt,
if (!wq)
return NULL;
+ if (flags & WQ_UNBOUND) {
+ wq->unbound_attrs = alloc_workqueue_attrs(GFP_KERNEL);
+ if (!wq->unbound_attrs)
+ goto err_free_wq;
+ }
+
vsnprintf(wq->name, namelen, fmt, args1);
va_end(args);
va_end(args1);
@@ -3830,6 +3841,7 @@ struct workqueue_struct *__alloc_workqueue_key(const char
*fmt,
return wq;
err_free_wq:
+ free_workqueue_attrs(wq->unbound_attrs);
kfree(wq);
return NULL;
err_destroy:
--
1.8.1.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 04/14] workqueue: determine NUMA node of workers accourding to the allowed cpumask
When worker tasks are created using kthread_create_on_node(),
currently only per-cpu ones have the matching NUMA node specified.
All unbound workers are always created with NUMA_NO_NODE.
Now that an unbound worker pool may have an arbitrary cpumask
associated with it, this isn't optimal. Add pool->node which is
determined by the pool's cpumask. If the pool's cpumask is contained
inside a NUMA node proper, the pool is associated with that node, and
all workers of the pool are created on that node.
This currently only makes difference for unbound worker pools with
cpumask contained inside single NUMA node, but this will serve as
foundation for making all unbound pools NUMA-affine.
Signed-off-by: Tejun Heo
---
kernel/workqueue.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 57ced49..fab2630 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -138,6 +138,7 @@ enum {
struct worker_pool {
spinlock_t lock; /* the pool lock */
int cpu;/* I: the associated cpu */
+ int node; /* I: the associated node ID */
int id; /* I: pool ID */
unsigned intflags; /* X: flags */
@@ -1645,7 +1646,6 @@ static struct worker *alloc_worker(void)
static struct worker *create_worker(struct worker_pool *pool)
{
struct worker *worker = NULL;
- int node = pool->cpu >= 0 ? cpu_to_node(pool->cpu) : NUMA_NO_NODE;
int id = -1;
char id_buf[16];
@@ -1678,7 +1678,7 @@ static struct worker *create_worker(struct worker_pool
*pool)
else
snprintf(id_buf, sizeof(id_buf), "u%d:%d", pool->id, id);
- worker->task = kthread_create_on_node(worker_thread, worker, node,
+ worker->task = kthread_create_on_node(worker_thread, worker, pool->node,
"kworker/%s", id_buf);
if (IS_ERR(worker->task))
goto fail;
@@ -3360,6 +3360,7 @@ static int init_worker_pool(struct worker_pool *pool)
spin_lock_init(&pool->lock);
pool->id = -1;
pool->cpu = -1;
+ pool->node = NUMA_NO_NODE;
pool->flags |= POOL_DISASSOCIATED;
INIT_LIST_HEAD(&pool->worklist);
INIT_LIST_HEAD(&pool->idle_list);
@@ -3465,6 +3466,7 @@ static struct worker_pool *get_unbound_pool(const struct
workqueue_attrs *attrs)
{
u32 hash = wqattrs_hash(attrs);
struct worker_pool *pool;
+ int node;
lockdep_assert_held(&wq_pool_mutex);
@@ -3487,6 +3489,17 @@ static struct worker_pool *get_unbound_pool(const struct
workqueue_attrs *attrs)
lockdep_set_subclass(&pool->lock, 1); /* see put_pwq() */
copy_workqueue_attrs(pool->attrs, attrs);
+ /* if cpumask is contained inside a NUMA node, we belong to that node */
+ if (wq_numa_enabled) {
+ for_each_node(node) {
+ if (cpumask_subset(pool->attrs->cpumask,
+ wq_numa_possible_cpumask[node])) {
+ pool->node = node;
+ break;
+ }
+ }
+ }
+
if (worker_pool_assign_id(pool) < 0)
goto fail;
@@ -4475,6 +4488,7 @@ static int __init init_workqueues(void)
pool->cpu = cpu;
cpumask_copy(pool->attrs->cpumask, cpumask_of(cpu));
pool->attrs->nice = std_nice[i++];
+ pool->node = cpu_to_node(cpu);
/* alloc pool ID */
mutex_lock(&wq_pool_mutex);
--
1.8.1.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 03/14] workqueue: drop 'H' from kworker names of unbound worker pools
Currently, all workqueue workers which have negative nice value has
'H' postfixed to their names. This is necessary for per-cpu workers
as they use the CPU number instead of pool->id to identify the pool
and the 'H' postfix is the only thing distinguishing normal and
highpri workers.
As workers for unbound pools use pool->id, the 'H' postfix is purely
informational. TASK_COMM_LEN is 16 and after the static part and
delimiters, there are only five characters left for the pool and
worker IDs. We're expecting to have more unbound pools with the
scheduled NUMA awareness support. Let's drop the non-essential 'H'
postfix from unbound kworker name.
While at it, restructure kthread_create*() invocation to help future
NUMA related changes.
Signed-off-by: Tejun Heo
---
kernel/workqueue.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 54b5048..57ced49 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1644,9 +1644,10 @@ static struct worker *alloc_worker(void)
*/
static struct worker *create_worker(struct worker_pool *pool)
{
- const char *pri = pool->attrs->nice < 0 ? "H" : "";
struct worker *worker = NULL;
+ int node = pool->cpu >= 0 ? cpu_to_node(pool->cpu) : NUMA_NO_NODE;
int id = -1;
+ char id_buf[16];
lockdep_assert_held(&pool->manager_mutex);
@@ -1672,13 +1673,13 @@ static struct worker *create_worker(struct worker_pool
*pool)
worker->id = id;
if (pool->cpu >= 0)
- worker->task = kthread_create_on_node(worker_thread,
- worker, cpu_to_node(pool->cpu),
- "kworker/%d:%d%s", pool->cpu, id, pri);
+ snprintf(id_buf, sizeof(id_buf), "%d:%d%s", pool->cpu, id,
+pool->attrs->nice < 0 ? "H" : "");
else
- worker->task = kthread_create(worker_thread, worker,
- "kworker/u%d:%d%s",
- pool->id, id, pri);
+ snprintf(id_buf, sizeof(id_buf), "u%d:%d", pool->id, id);
+
+ worker->task = kthread_create_on_node(worker_thread, worker, node,
+ "kworker/%s", id_buf);
if (IS_ERR(worker->task))
goto fail;
--
1.8.1.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 14/14] workqueue: update sysfs interface to reflect NUMA awareness and a kernel param to disable NUMA affinity
Unbound workqueues are now NUMA aware. Let's add some control knobs
and update sysfs interface accordingly.
* Add kernel param workqueue.numa_disable which disables NUMA affinity
globally.
* Replace sysfs file "pool_id" with "pool_ids" which contain
node:pool_id pairs. This change is userland-visible but "pool_id"
hasn't seen a release yet, so this is okay.
* Add a new sysf files "numa" which can toggle NUMA affinity on
individual workqueues. This is implemented as attrs->no_numa whichn
is special in that it isn't part of a pool's attributes. It only
affects how apply_workqueue_attrs() picks which pools to use.
After "pool_ids" change, first_pwq() doesn't have any user left.
Removed.
Signed-off-by: Tejun Heo
---
Documentation/kernel-parameters.txt | 9
include/linux/workqueue.h | 5 +++
kernel/workqueue.c | 82 ++---
3 files changed, 73 insertions(+), 23 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 4609e81..c75ea0b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3222,6 +3222,15 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
or other driver-specific files in the
Documentation/watchdog/ directory.
+ workqueue.disable_numa
+ By default, all work items queued to unbound
+ workqueues are affine to the NUMA nodes they're
+ issued on, which results in better behavior in
+ general. If NUMA affinity needs to be disabled for
+ whatever reason, this option can be used. Note
+ that this also can be controlled per-workqueue for
+ workqueues visible under /sys/bus/workqueue/.
+
x2apic_phys [X86-64,APIC] Use x2apic physical mode instead of
default x2apic cluster mode on platforms
supporting x2apic.
diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index 835d12b..7179756 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -119,10 +119,15 @@ struct delayed_work {
/*
* A struct for workqueue attributes. This can be used to change
* attributes of an unbound workqueue.
+ *
+ * Unlike other fields, ->no_numa isn't a property of a worker_pool. It
+ * only modifies how apply_workqueue_attrs() select pools and thus doesn't
+ * participate in pool hash calculations or equality comparisons.
*/
struct workqueue_attrs {
int nice; /* nice level */
cpumask_var_t cpumask;/* allowed CPUs */
+ boolno_numa;/* disable NUMA affinity */
};
static inline struct delayed_work *to_delayed_work(struct work_struct *work)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 637debe..0b6a3b0 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -268,6 +268,9 @@ static int wq_numa_tbl_len; /* highest possible
NUMA node id + 1 */
static cpumask_var_t *wq_numa_possible_cpumask;
/* possible CPUs of each node */
+static bool wq_disable_numa;
+module_param_named(disable_numa, wq_disable_numa, bool, 0444);
+
static bool wq_numa_enabled; /* unbound NUMA affinity enabled */
/* buf for wq_update_unbound_numa_attrs(), protected by CPU hotplug exclusion
*/
@@ -517,21 +520,6 @@ static int worker_pool_assign_id(struct worker_pool *pool)
}
/**
- * first_pwq - return the first pool_workqueue of the specified workqueue
- * @wq: the target workqueue
- *
- * This must be called either with wq->mutex held or sched RCU read locked.
- * If the pwq needs to be used beyond the locking in effect, the caller is
- * responsible for guaranteeing that the pwq stays online.
- */
-static struct pool_workqueue *first_pwq(struct workqueue_struct *wq)
-{
- assert_rcu_or_wq_mutex(wq);
- return list_first_or_null_rcu(&wq->pwqs, struct pool_workqueue,
- pwqs_node);
-}
-
-/**
* unbound_pwq_by_node - return the unbound pool_workqueue for the given node
* @wq: the target workqueue
* @node: the node ID
@@ -3114,16 +3102,21 @@ static struct device_attribute wq_sysfs_attrs[] = {
__ATTR_NULL,
};
-static ssize_t wq_pool_id_show(struct device *dev,
- struct device_attribute *attr, char *buf)
+static ssize_t wq_pool_ids_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
struct workqueue_struct *wq = dev_to_wq(dev);
- struct worker_pool *pool;
- int written;
+ const char *delim = "";
+ int node, written = 0;
rcu_read_lock_sched();
- pool = first_pwq(wq)->pool;
- written = scnprintf(b
[PATCH 13/14] workqueue: implement NUMA affinity for unbound workqueues
Currently, an unbound workqueue has single current, or first, pwq
(pool_workqueue) to which all new work items are queued. This often
isn't optimal on NUMA machines as workers may jump around across node
boundaries and work items get assigned to workers without any regard
to NUMA affinity.
This patch implements NUMA affinity for unbound workqueues. Instead
of mapping all entries of numa_pwq_tbl[] to the same pwq,
apply_workqueue_attrs() now creates a separate pwq covering the
intersecting CPUs for each NUMA node which has online CPUs in
@attrs->cpumask. Nodes which don't have intersecting possible CPUs
are mapped to pwqs covering whole @attrs->cpumask.
As CPUs come up and go down, the pool association is changed
accordingly. Changing pool association may involve allocating new
pools which may fail. To avoid failing CPU_DOWN, each workqueue
always keeps a default pwq which covers whole attrs->cpumask which is
used as fallback if pool creation fails during a CPU hotplug
operation.
This ensures that all work items issued on a NUMA node is executed on
the same node as long as the workqueue allows execution on the CPUs of
the node.
As this maps a workqueue to multiple pwqs and max_active is per-pwq,
this change the behavior of max_active. The limit is now per NUMA
node instead of global. While this is an actual change, max_active is
already per-cpu for per-cpu workqueues and primarily used as safety
mechanism rather than for active concurrency control. Concurrency is
usually limited from workqueue users by the number of concurrently
active work items and this change shouldn't matter much.
v2: Fixed pwq freeing in apply_workqueue_attrs() error path. Spotted
by Lai.
v3: The previous version incorrectly made a workqueue spanning
multiple nodes spread work items over all online CPUs when some of
its nodes don't have any desired cpus. Reimplemented so that NUMA
affinity is properly updated as CPUs go up and down. This problem
was spotted by Lai Jiangshan.
Signed-off-by: Tejun Heo
Cc: Lai Jiangshan
---
kernel/workqueue.c | 278 +
1 file changed, 258 insertions(+), 20 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index e656931..637debe 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
#include "workqueue_internal.h"
@@ -245,6 +246,7 @@ struct workqueue_struct {
int saved_max_active; /* WQ: saved pwq max_active */
struct workqueue_attrs *unbound_attrs; /* WQ: only for unbound wqs */
+ struct pool_workqueue *dfl_pwq; /* WQ: only for unbound wqs */
#ifdef CONFIG_SYSFS
struct wq_device*wq_dev;/* I: for sysfs interface */
@@ -268,6 +270,9 @@ static cpumask_var_t *wq_numa_possible_cpumask;
static bool wq_numa_enabled; /* unbound NUMA affinity enabled */
+/* buf for wq_update_unbound_numa_attrs(), protected by CPU hotplug exclusion
*/
+static struct workqueue_attrs *wq_update_unbound_numa_attrs_buf;
+
static DEFINE_MUTEX(wq_pool_mutex);/* protects pools and workqueues list */
static DEFINE_SPINLOCK(wq_mayday_lock);/* protects wq->maydays list */
@@ -3710,6 +3715,61 @@ static struct pool_workqueue *alloc_unbound_pwq(struct
workqueue_struct *wq,
return pwq;
}
+/* undo alloc_unbound_pwq(), used only in the error path */
+static void free_unbound_pwq(struct pool_workqueue *pwq)
+{
+ lockdep_assert_held(&wq_pool_mutex);
+
+ if (pwq) {
+ put_unbound_pool(pwq->pool);
+ kfree(pwq);
+ }
+}
+
+/**
+ * wq_calc_node_mask - calculate a wq_attrs' cpumask for the specified node
+ * @attrs: the wq_attrs of interest
+ * @node: the target NUMA node
+ * @cpu_going_down: if >= 0, the CPU to consider as offline
+ * @cpumask: outarg, the resulting cpumask
+ *
+ * Calculate the cpumask a workqueue with @attrs should use on @node. If
+ * @cpu_going_down is >= 0, that cpu is considered offline during
+ * calculation. The result is stored in @cpumask. This function returns
+ * %true if the resulting @cpumask is different from @attrs->cpumask,
+ * %false if equal.
+ *
+ * If NUMA affinity is not enabled, @attrs->cpumask is always used. If
+ * enabled and @node has online CPUs requested by @attrs, the returned
+ * cpumask is the intersection of the possible CPUs of @node and
+ * @attrs->cpumask.
+ *
+ * The caller is responsible for ensuring that the cpumask of @node stays
+ * stable.
+ */
+static bool wq_calc_node_cpumask(const struct workqueue_attrs *attrs, int node,
+int cpu_going_down, cpumask_t *cpumask)
+{
+ if (!wq_numa_enabled)
+ goto use_dfl;
+
+ /* does @node have any online CPUs @attrs wants? */
+ cpumask_and(cpumask, cpumask_of_node(node), attrs->cpumask);
+ if (cpu_going_down >= 0)
+ cpumask_clear_cpu(
[PATCH 10/14] workqueue: use NUMA-aware allocation for pool_workqueues
Use kmem_cache_alloc_node() with @pool->node instead of
kmem_cache_zalloc() when allocating a pool_workqueue so that it's
allocated on the same node as the associated worker_pool. As there's
no no kmem_cache_zalloc_node(), move zeroing to init_pwq().
This was suggested by Lai Jiangshan.
Signed-off-by: Tejun Heo
Cc: Lai Jiangshan
---
kernel/workqueue.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 58c7663..a4420be 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3626,12 +3626,14 @@ static void pwq_adjust_max_active(struct pool_workqueue
*pwq)
spin_unlock_irq(&pwq->pool->lock);
}
-/* initialize newly zalloced @pwq which is associated with @wq and @pool */
+/* initialize newly alloced @pwq which is associated with @wq and @pool */
static void init_pwq(struct pool_workqueue *pwq, struct workqueue_struct *wq,
struct worker_pool *pool)
{
BUG_ON((unsigned long)pwq & WORK_STRUCT_FLAG_MASK);
+ memset(pwq, 0, sizeof(*pwq));
+
pwq->pool = pool;
pwq->wq = wq;
pwq->flush_color = -1;
@@ -3677,7 +3679,7 @@ static struct pool_workqueue *alloc_unbound_pwq(struct
workqueue_struct *wq,
if (!pool)
return NULL;
- pwq = kmem_cache_zalloc(pwq_cache, GFP_KERNEL);
+ pwq = kmem_cache_alloc_node(pwq_cache, GFP_KERNEL, pool->node);
if (!pwq) {
put_unbound_pool(pool);
return NULL;
--
1.8.1.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 11/14] workqueue: introduce numa_pwq_tbl_install()
Factor out pool_workqueue linking and installation into numa_pwq_tbl[]
from apply_workqueue_attrs() into numa_pwq_tbl_install(). link_pwq()
is made safe to call multiple times. numa_pwq_tbl_install() links the
pwq, installs it into numa_pwq_tbl[] at the specified node and returns
the old entry.
@last_pwq is removed from link_pwq() as the return value of the new
function can be used instead.
This is to prepare for NUMA affinity support for unbound workqueues.
Signed-off-by: Tejun Heo
---
kernel/workqueue.c | 35 ++-
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index a4420be..527dc418 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3639,24 +3639,26 @@ static void init_pwq(struct pool_workqueue *pwq, struct
workqueue_struct *wq,
pwq->flush_color = -1;
pwq->refcnt = 1;
INIT_LIST_HEAD(&pwq->delayed_works);
+ INIT_LIST_HEAD(&pwq->pwqs_node);
INIT_LIST_HEAD(&pwq->mayday_node);
INIT_WORK(&pwq->unbound_release_work, pwq_unbound_release_workfn);
}
/* sync @pwq with the current state of its associated wq and link it */
-static void link_pwq(struct pool_workqueue *pwq,
-struct pool_workqueue **p_last_pwq)
+static void link_pwq(struct pool_workqueue *pwq)
{
struct workqueue_struct *wq = pwq->wq;
lockdep_assert_held(&wq->mutex);
+ /* may be called multiple times, ignore if already linked */
+ if (!list_empty(&pwq->pwqs_node))
+ return;
+
/*
* Set the matching work_color. This is synchronized with
* wq->mutex to avoid confusing flush_workqueue().
*/
- if (p_last_pwq)
- *p_last_pwq = first_pwq(wq);
pwq->work_color = wq->work_color;
/* sync max_active to the current setting */
@@ -3689,6 +3691,23 @@ static struct pool_workqueue *alloc_unbound_pwq(struct
workqueue_struct *wq,
return pwq;
}
+/* install @pwq into @wq's numa_pwq_tbl[] for @node and return the old pwq */
+static struct pool_workqueue *numa_pwq_tbl_install(struct workqueue_struct *wq,
+ int node,
+ struct pool_workqueue *pwq)
+{
+ struct pool_workqueue *old_pwq;
+
+ lockdep_assert_held(&wq->mutex);
+
+ /* link_pwq() can handle duplicate calls */
+ link_pwq(pwq);
+
+ old_pwq = rcu_access_pointer(wq->numa_pwq_tbl[node]);
+ rcu_assign_pointer(wq->numa_pwq_tbl[node], pwq);
+ return old_pwq;
+}
+
/**
* apply_workqueue_attrs - apply new workqueue_attrs to an unbound workqueue
* @wq: the target workqueue
@@ -3707,7 +3726,7 @@ int apply_workqueue_attrs(struct workqueue_struct *wq,
const struct workqueue_attrs *attrs)
{
struct workqueue_attrs *new_attrs;
- struct pool_workqueue *pwq, *last_pwq;
+ struct pool_workqueue *pwq, *last_pwq = NULL;
int node;
/* only unbound workqueues can change attributes */
@@ -3734,11 +3753,9 @@ int apply_workqueue_attrs(struct workqueue_struct *wq,
mutex_lock(&wq->mutex);
- link_pwq(pwq, &last_pwq);
-
copy_workqueue_attrs(wq->unbound_attrs, new_attrs);
for_each_node(node)
- rcu_assign_pointer(wq->numa_pwq_tbl[node], pwq);
+ last_pwq = numa_pwq_tbl_install(wq, node, pwq);
mutex_unlock(&wq->mutex);
@@ -3774,7 +3791,7 @@ static int alloc_and_link_pwqs(struct workqueue_struct
*wq)
init_pwq(pwq, wq, &cpu_pools[highpri]);
mutex_lock(&wq->mutex);
- link_pwq(pwq, NULL);
+ link_pwq(pwq);
mutex_unlock(&wq->mutex);
}
return 0;
--
1.8.1.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 08/14] workqueue: map an unbound workqueues to multiple per-node pool_workqueues
Currently, an unbound workqueue has only one "current" pool_workqueue
associated with it. It may have multple pool_workqueues but only the
first pool_workqueue servies new work items. For NUMA affinity, we
want to change this so that there are multiple current pool_workqueues
serving different NUMA nodes.
Introduce workqueue->numa_pwq_tbl[] which is indexed by NUMA node and
points to the pool_workqueue to use for each possible node. This
replaces first_pwq() in __queue_work() and workqueue_congested().
numa_pwq_tbl[] is currently initialized to point to the same
pool_workqueue as first_pwq() so this patch doesn't make any behavior
changes.
v2: Use rcu_dereference_raw() in unbound_pwq_by_node() as the function
may be called only with wq->mutex held.
Signed-off-by: Tejun Heo
---
kernel/workqueue.c | 48 +---
1 file changed, 37 insertions(+), 11 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 9297ea3..5b53705 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -257,6 +257,7 @@ struct workqueue_struct {
/* hot fields used during command issue, aligned to cacheline */
unsigned intflags cacheline_aligned; /* WQ: WQ_* flags
*/
struct pool_workqueue __percpu *cpu_pwqs; /* I: per-cpu pwqs */
+ struct pool_workqueue __rcu *numa_pwq_tbl[]; /* FR: unbound pwqs
indexed by node */
};
static struct kmem_cache *pwq_cache;
@@ -525,6 +526,22 @@ static struct pool_workqueue *first_pwq(struct
workqueue_struct *wq)
pwqs_node);
}
+/**
+ * unbound_pwq_by_node - return the unbound pool_workqueue for the given node
+ * @wq: the target workqueue
+ * @node: the node ID
+ *
+ * This must be called either with pwq_lock held or sched RCU read locked.
+ * If the pwq needs to be used beyond the locking in effect, the caller is
+ * responsible for guaranteeing that the pwq stays online.
+ */
+static struct pool_workqueue *unbound_pwq_by_node(struct workqueue_struct *wq,
+ int node)
+{
+ assert_rcu_or_wq_mutex(wq);
+ return rcu_dereference_raw(wq->numa_pwq_tbl[node]);
+}
+
static unsigned int work_color_to_flags(int color)
{
return color << WORK_STRUCT_COLOR_SHIFT;
@@ -1278,14 +1295,14 @@ static void __queue_work(int cpu, struct
workqueue_struct *wq,
WARN_ON_ONCE(!is_chained_work(wq)))
return;
retry:
+ if (req_cpu == WORK_CPU_UNBOUND)
+ cpu = raw_smp_processor_id();
+
/* pwq which will be used unless @work is executing elsewhere */
- if (!(wq->flags & WQ_UNBOUND)) {
- if (cpu == WORK_CPU_UNBOUND)
- cpu = raw_smp_processor_id();
+ if (!(wq->flags & WQ_UNBOUND))
pwq = per_cpu_ptr(wq->cpu_pwqs, cpu);
- } else {
- pwq = first_pwq(wq);
- }
+ else
+ pwq = unbound_pwq_by_node(wq, cpu_to_node(cpu));
/*
* If @work was previously on a different pool, it might still be
@@ -1315,8 +1332,8 @@ retry:
* pwq is determined and locked. For unbound pools, we could have
* raced with pwq release and it could already be dead. If its
* refcnt is zero, repeat pwq selection. Note that pwqs never die
-* without another pwq replacing it as the first pwq or while a
-* work item is executing on it, so the retying is guaranteed to
+* without another pwq replacing it in the numa_pwq_tbl or while
+* work items are executing on it, so the retrying is guaranteed to
* make forward-progress.
*/
if (unlikely(!pwq->refcnt)) {
@@ -3614,6 +3631,8 @@ static void init_and_link_pwq(struct pool_workqueue *pwq,
struct worker_pool *pool,
struct pool_workqueue **p_last_pwq)
{
+ int node;
+
BUG_ON((unsigned long)pwq & WORK_STRUCT_FLAG_MASK);
pwq->pool = pool;
@@ -3640,8 +3659,11 @@ static void init_and_link_pwq(struct pool_workqueue *pwq,
/* link in @pwq */
list_add_rcu(&pwq->pwqs_node, &wq->pwqs);
- if (wq->flags & WQ_UNBOUND)
+ if (wq->flags & WQ_UNBOUND) {
copy_workqueue_attrs(wq->unbound_attrs, pool->attrs);
+ for_each_node(node)
+ rcu_assign_pointer(wq->numa_pwq_tbl[node], pwq);
+ }
mutex_unlock(&wq->mutex);
}
@@ -3756,12 +3778,16 @@ struct workqueue_struct *__alloc_workqueue_key(const
char *fmt,
struct lock_class_key *key,
const char *lock_name, ...)
{
+ size_t tbl_size = 0;
va_list args;
struct workqueue_struct *wq;
struct pool_workqueue *pwq;
/* allocate wq and format name */
- wq = kzalloc(sizeof(*wq), GFP_KERNEL);
+ if (flags & WQ_U
[PATCH 09/14] workqueue: break init_and_link_pwq() into two functions and introduce alloc_unbound_pwq()
Break init_and_link_pwq() into init_pwq() and link_pwq() and move
unbound-workqueue specific handling into apply_workqueue_attrs().
Also, factor out unbound pool and pool_workqueue allocation into
alloc_unbound_pwq().
This reorganization is to prepare for NUMA affinity and doesn't
introduce any functional changes.
Signed-off-by: Tejun Heo
---
kernel/workqueue.c | 77 ++
1 file changed, 49 insertions(+), 28 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 5b53705..58c7663 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3626,13 +3626,10 @@ static void pwq_adjust_max_active(struct pool_workqueue
*pwq)
spin_unlock_irq(&pwq->pool->lock);
}
-static void init_and_link_pwq(struct pool_workqueue *pwq,
- struct workqueue_struct *wq,
- struct worker_pool *pool,
- struct pool_workqueue **p_last_pwq)
+/* initialize newly zalloced @pwq which is associated with @wq and @pool */
+static void init_pwq(struct pool_workqueue *pwq, struct workqueue_struct *wq,
+struct worker_pool *pool)
{
- int node;
-
BUG_ON((unsigned long)pwq & WORK_STRUCT_FLAG_MASK);
pwq->pool = pool;
@@ -3642,8 +3639,15 @@ static void init_and_link_pwq(struct pool_workqueue *pwq,
INIT_LIST_HEAD(&pwq->delayed_works);
INIT_LIST_HEAD(&pwq->mayday_node);
INIT_WORK(&pwq->unbound_release_work, pwq_unbound_release_workfn);
+}
- mutex_lock(&wq->mutex);
+/* sync @pwq with the current state of its associated wq and link it */
+static void link_pwq(struct pool_workqueue *pwq,
+struct pool_workqueue **p_last_pwq)
+{
+ struct workqueue_struct *wq = pwq->wq;
+
+ lockdep_assert_held(&wq->mutex);
/*
* Set the matching work_color. This is synchronized with
@@ -3658,14 +3662,29 @@ static void init_and_link_pwq(struct pool_workqueue
*pwq,
/* link in @pwq */
list_add_rcu(&pwq->pwqs_node, &wq->pwqs);
+}
- if (wq->flags & WQ_UNBOUND) {
- copy_workqueue_attrs(wq->unbound_attrs, pool->attrs);
- for_each_node(node)
- rcu_assign_pointer(wq->numa_pwq_tbl[node], pwq);
+/* obtain a pool matching @attr and create a pwq associating the pool and @wq
*/
+static struct pool_workqueue *alloc_unbound_pwq(struct workqueue_struct *wq,
+ const struct workqueue_attrs *attrs)
+{
+ struct worker_pool *pool;
+ struct pool_workqueue *pwq;
+
+ lockdep_assert_held(&wq_pool_mutex);
+
+ pool = get_unbound_pool(attrs);
+ if (!pool)
+ return NULL;
+
+ pwq = kmem_cache_zalloc(pwq_cache, GFP_KERNEL);
+ if (!pwq) {
+ put_unbound_pool(pool);
+ return NULL;
}
- mutex_unlock(&wq->mutex);
+ init_pwq(pwq, wq, pool);
+ return pwq;
}
/**
@@ -3686,8 +3705,8 @@ int apply_workqueue_attrs(struct workqueue_struct *wq,
const struct workqueue_attrs *attrs)
{
struct workqueue_attrs *new_attrs;
- struct pool_workqueue *pwq = NULL, *last_pwq;
- struct worker_pool *pool;
+ struct pool_workqueue *pwq, *last_pwq;
+ int node;
/* only unbound workqueues can change attributes */
if (WARN_ON(!(wq->flags & WQ_UNBOUND)))
@@ -3706,22 +3725,21 @@ int apply_workqueue_attrs(struct workqueue_struct *wq,
cpumask_and(new_attrs->cpumask, new_attrs->cpumask, cpu_possible_mask);
mutex_lock(&wq_pool_mutex);
-
- pwq = kmem_cache_zalloc(pwq_cache, GFP_KERNEL);
- if (!pwq) {
- mutex_unlock(&wq_pool_mutex);
+ pwq = alloc_unbound_pwq(wq, new_attrs);
+ mutex_unlock(&wq_pool_mutex);
+ if (!pwq)
goto enomem;
- }
- pool = get_unbound_pool(new_attrs);
- if (!pool) {
- mutex_unlock(&wq_pool_mutex);
- goto enomem;
- }
+ mutex_lock(&wq->mutex);
- mutex_unlock(&wq_pool_mutex);
+ link_pwq(pwq, &last_pwq);
+
+ copy_workqueue_attrs(wq->unbound_attrs, new_attrs);
+ for_each_node(node)
+ rcu_assign_pointer(wq->numa_pwq_tbl[node], pwq);
+
+ mutex_unlock(&wq->mutex);
- init_and_link_pwq(pwq, wq, pool, &last_pwq);
if (last_pwq) {
spin_lock_irq(&last_pwq->pool->lock);
put_pwq(last_pwq);
@@ -3731,7 +3749,6 @@ int apply_workqueue_attrs(struct workqueue_struct *wq,
return 0;
enomem:
- kmem_cache_free(pwq_cache, pwq);
free_workqueue_attrs(new_attrs);
return -ENOMEM;
}
@@ -3752,7 +3769,11 @@ static int alloc_and_link_pwqs(struct workqueue_struct
*wq)
struct worker_pool *cpu_pools =
per_cpu(cpu_worker_pools, cpu);
-
[PATCH 06/14] workqueue: make workqueue->name[] fixed len
Currently workqueue->name[] is of flexible length. We want to use the
flexible field for something more useful and there isn't much benefit
in allowing arbitrary name length anyway. Make it fixed len capping
at 24 bytes.
Signed-off-by: Tejun Heo
---
kernel/workqueue.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 65f200c..23c9099 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -101,6 +101,8 @@ enum {
*/
RESCUER_NICE_LEVEL = -20,
HIGHPRI_NICE_LEVEL = -20,
+
+ WQ_NAME_LEN = 24,
};
/*
@@ -252,7 +254,7 @@ struct workqueue_struct {
#ifdef CONFIG_LOCKDEP
struct lockdep_map lockdep_map;
#endif
- charname[]; /* I: workqueue name */
+ charname[WQ_NAME_LEN]; /* I: workqueue name */
};
static struct kmem_cache *pwq_cache;
@@ -3752,17 +3754,12 @@ struct workqueue_struct *__alloc_workqueue_key(const
char *fmt,
struct lock_class_key *key,
const char *lock_name, ...)
{
- va_list args, args1;
+ va_list args;
struct workqueue_struct *wq;
struct pool_workqueue *pwq;
- size_t namelen;
-
- /* determine namelen, allocate wq and format name */
- va_start(args, lock_name);
- va_copy(args1, args);
- namelen = vsnprintf(NULL, 0, fmt, args) + 1;
- wq = kzalloc(sizeof(*wq) + namelen, GFP_KERNEL);
+ /* allocate wq and format name */
+ wq = kzalloc(sizeof(*wq), GFP_KERNEL);
if (!wq)
return NULL;
@@ -3772,9 +3769,9 @@ struct workqueue_struct *__alloc_workqueue_key(const char
*fmt,
goto err_free_wq;
}
- vsnprintf(wq->name, namelen, fmt, args1);
+ va_start(args, lock_name);
+ vsnprintf(wq->name, sizeof(wq->name), fmt, args);
va_end(args);
- va_end(args1);
max_active = max_active ?: WQ_DFL_ACTIVE;
max_active = wq_clamp_max_active(max_active, flags, wq->name);
--
1.8.1.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 07/14] workqueue: move hot fields of workqueue_struct to the end
Move wq->flags and ->cpu_pwqs to the end of workqueue_struct and align
them to the cacheline. These two fields are used in the work item
issue path and thus hot. The scheduled NUMA affinity support will add
dispatch table at the end of workqueue_struct and relocating these two
fields will allow us hitting only single cacheline on hot paths.
Note that wq->pwqs isn't moved although it currently is being used in
the work item issue path for unbound workqueues. The dispatch table
mentioned above will replace its use in the issue path, so it will
become cold once NUMA support is implemented.
Signed-off-by: Tejun Heo
---
kernel/workqueue.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 23c9099..9297ea3 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -227,8 +227,6 @@ struct wq_device;
* the appropriate worker_pool through its pool_workqueues.
*/
struct workqueue_struct {
- unsigned intflags; /* WQ: WQ_* flags */
- struct pool_workqueue __percpu *cpu_pwqs; /* I: per-cpu pwq's */
struct list_headpwqs; /* WR: all pwqs of this wq */
struct list_headlist; /* PL: list of all workqueues */
@@ -255,6 +253,10 @@ struct workqueue_struct {
struct lockdep_map lockdep_map;
#endif
charname[WQ_NAME_LEN]; /* I: workqueue name */
+
+ /* hot fields used during command issue, aligned to cacheline */
+ unsigned intflags cacheline_aligned; /* WQ: WQ_* flags
*/
+ struct pool_workqueue __percpu *cpu_pwqs; /* I: per-cpu pwqs */
};
static struct kmem_cache *pwq_cache;
--
1.8.1.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/
Subject: [PATCHSET v2 wq/for-3.10] workqueue: NUMA affinity for unbound workqueues
Hello,
Changes from the last take[L] are
* Lai pointed out that the previous implementation was broken in that
if a workqueue spans over multiple nodes and some of the nodes don't
have any desired online CPUs, work items queued on those nodes would
be spread across all CPUs violating the configured cpumask.
The patchset is updated such that apply_workqueue_attrs() now only
assigns NUMA-affine pwqs to nodes with desired online CPUs and
default pwq to all other nodes. To track CPU online state,
wq_update_unbound_numa_attrs() is added. The function is called for
each workqueue during hot[un]plug and updates pwq association
accordingly.
* Rolled in updated patches from the previous posting.
* More helper routines are factored out such that
apply_workqueue_attrs() is easier to follow and can share code paths
with wq_update_unbound_numa_attrs().
* Various cleanups and fixes.
Patchset description from the original posting follows.
There are two types of workqueues - per-cpu and unbound. The former
is bound to each CPU and the latter isn't not bound to any by default.
While the recently added attrs support allows unbound workqueues to be
confined to subset of CPUs, it still is quite cumbersome for
applications where CPU affinity is too constricted but NUMA locality
still matters.
This patchset tries to solve that issue by automatically making
unbound workqueues affine to NUMA nodes by default. A work item
queued to an unbound workqueue is executed on one of the CPUs allowed
by the workqueue in the same node. If there's none allowed, it may be
executed on any cpu allowed by the workqueue. It doesn't require any
changes on the user side. Every interface of workqueues functions the
same as before.
This would be most helpful to subsystems which use some form of async
execution to process significant amount of data - e.g. crypto and
btrfs; however, I wanted to find out whether it would make any dent in
much less favorable use cases. The following is total run time in
seconds of buliding allmodconfig kernel w/ -j20 on a dual socket
opteron machine with writeback thread pool converted to unbound
workqueue and thus made NUMA-affine. The file system is ext4 on top
of a WD SSD.
before conversion after conversion
1396.1261394.763
1397.6211394.965
1399.6361394.738
1397.4631398.162
1395.5431393.670
AVG 1397.2781395.260DIFF2.018
STDEV 1.585 1.700
And, yes, it actually made things go faster by about 1.2 sigma, which
isn't completely conclusive but is a pretty good indication that it's
actually faster. Note that this is a workload which is dominated by
CPU time and while there's writeback going on continously it really
isn't touching too much data or a dominating factor, so the gain is
understandably small, 0.14%, but hey it's still a gain and it should
be much more interesting for crypto and btrfs which would actully
access the data or workloads which are more sensitive to NUMA
affinity.
The implementation is fairly simple. After the recent attrs support
changes, a lot of the differences in pwq (pool_workqueue) handling
between unbound and per-cpu workqueues are gone. An unbound workqueue
still has one "current" pwq that it uses for queueing any new work
items but can handle multiple pwqs perfectly well while they're
draining, so this patchset adds pwq dispatch table to unbound
workqueues which is indexed by NUMA node and points to the matching
pwq. Unbound workqueues now simply have multiple "current" pwqs keyed
by NUMA node.
NUMA affinity can be turned off system-wide by workqueue.disable_numa
kernel param or per-workqueue using "numa" sysfs file.
This patchset contains the following fourteen patches.
0001-workqueue-move-pwq_pool_locking-outside-of-get-put_u.patch
0002-workqueue-add-wq_numa_tbl_len-and-wq_numa_possible_c.patch
0003-workqueue-drop-H-from-kworker-names-of-unbound-worke.patch
0004-workqueue-determine-NUMA-node-of-workers-accourding-.patch
0005-workqueue-add-workqueue-unbound_attrs.patch
0006-workqueue-make-workqueue-name-fixed-len.patch
0007-workqueue-move-hot-fields-of-workqueue_struct-to-the.patch
0008-workqueue-map-an-unbound-workqueues-to-multiple-per-.patch
0009-workqueue-break-init_and_link_pwq-into-two-functions.patch
0010-workqueue-use-NUMA-aware-allocation-for-pool_workque.patch
0011-workqueue-introduce-numa_pwq_tbl_install.patch
0012-workqueue-introduce-put_pwq_unlocked.patch
0013-workqueue-implement-NUMA-affinity-for-unbound-workqu.patch
0014-workqueue-update-sysfs-interface-to-reflect-NUMA-awa.patch
0001-0009 are prep patches.
0010-0013 implement NUMA affinity.
0014 adds control knobs and updates sysfs interface.
This patchset is on top of
wq/for-3.10 b59276054 ("workqueue: remove
[PATCH 01/14] workqueue: move pwq_pool_locking outside of get/put_unbound_pool()
The scheduled NUMA affinity support for unbound workqueues would need
to walk workqueues list and pool related operations on each workqueue.
Move wq_pool_mutex locking out of get/put_unbound_pool() to their
callers so that pool operations can be performed while walking the
workqueues list, which is also protected by wq_pool_mutex.
Signed-off-by: Tejun Heo
---
kernel/workqueue.c | 36 ++--
1 file changed, 22 insertions(+), 14 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index abe1f0d..26771f4e 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3395,31 +3395,28 @@ static void rcu_free_pool(struct rcu_head *rcu)
* safe manner. get_unbound_pool() calls this function on its failure path
* and this function should be able to release pools which went through,
* successfully or not, init_worker_pool().
+ *
+ * Should be called with wq_pool_mutex held.
*/
static void put_unbound_pool(struct worker_pool *pool)
{
struct worker *worker;
- mutex_lock(&wq_pool_mutex);
- if (--pool->refcnt) {
- mutex_unlock(&wq_pool_mutex);
+ lockdep_assert_held(&wq_pool_mutex);
+
+ if (--pool->refcnt)
return;
- }
/* sanity checks */
if (WARN_ON(!(pool->flags & POOL_DISASSOCIATED)) ||
- WARN_ON(!list_empty(&pool->worklist))) {
- mutex_unlock(&wq_pool_mutex);
+ WARN_ON(!list_empty(&pool->worklist)))
return;
- }
/* release id and unhash */
if (pool->id >= 0)
idr_remove(&worker_pool_idr, pool->id);
hash_del(&pool->hash_node);
- mutex_unlock(&wq_pool_mutex);
-
/*
* Become the manager and destroy all workers. Grabbing
* manager_arb prevents @pool's workers from blocking on
@@ -3453,13 +3450,15 @@ static void put_unbound_pool(struct worker_pool *pool)
* reference count and return it. If there already is a matching
* worker_pool, it will be used; otherwise, this function attempts to
* create a new one. On failure, returns NULL.
+ *
+ * Should be called with wq_pool_mutex held.
*/
static struct worker_pool *get_unbound_pool(const struct workqueue_attrs
*attrs)
{
u32 hash = wqattrs_hash(attrs);
struct worker_pool *pool;
- mutex_lock(&wq_pool_mutex);
+ lockdep_assert_held(&wq_pool_mutex);
/* do we already have a matching pool? */
hash_for_each_possible(unbound_pool_hash, pool, hash_node, hash) {
@@ -3490,10 +3489,8 @@ static struct worker_pool *get_unbound_pool(const struct
workqueue_attrs *attrs)
/* install */
hash_add(unbound_pool_hash, &pool->hash_node, hash);
out_unlock:
- mutex_unlock(&wq_pool_mutex);
return pool;
fail:
- mutex_unlock(&wq_pool_mutex);
if (pool)
put_unbound_pool(pool);
return NULL;
@@ -3530,7 +3527,10 @@ static void pwq_unbound_release_workfn(struct
work_struct *work)
is_last = list_empty(&wq->pwqs);
mutex_unlock(&wq->mutex);
+ mutex_lock(&wq_pool_mutex);
put_unbound_pool(pool);
+ mutex_unlock(&wq_pool_mutex);
+
call_rcu_sched(&pwq->rcu, rcu_free_pwq);
/*
@@ -3653,13 +3653,21 @@ int apply_workqueue_attrs(struct workqueue_struct *wq,
copy_workqueue_attrs(new_attrs, attrs);
cpumask_and(new_attrs->cpumask, new_attrs->cpumask, cpu_possible_mask);
+ mutex_lock(&wq_pool_mutex);
+
pwq = kmem_cache_zalloc(pwq_cache, GFP_KERNEL);
- if (!pwq)
+ if (!pwq) {
+ mutex_unlock(&wq_pool_mutex);
goto enomem;
+ }
pool = get_unbound_pool(new_attrs);
- if (!pool)
+ if (!pool) {
+ mutex_unlock(&wq_pool_mutex);
goto enomem;
+ }
+
+ mutex_unlock(&wq_pool_mutex);
init_and_link_pwq(pwq, wq, pool, &last_pwq);
if (last_pwq) {
--
1.8.1.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/
Re: [PATCH 1/2] extcon: max77693: Fix return value
Hi Chanwoo, On 28 March 2013 04:51, Chanwoo Choi wrote: > On 03/27/2013 08:23 PM, Sachin Kamat wrote: >> Return the value obtained from the function instead of hardcoding. >> Silences the following warning: >> drivers/extcon/extcon-max77693.c:297 max77693_muic_set_path() >> info: why not propagate 'ret' from max77693_update_reg() instead of (-11)? >> drivers/extcon/extcon-max77693.c:310 max77693_muic_set_path() >> info: why not propagate 'ret' from max77693_update_reg() instead of (-11)? >> >> Signed-off-by: Sachin Kamat [snip] >> dev_info(info->dev, > As my comment about "extcon: max8997: Fix return value", > I wish to receive one patch which modify all of return value with 'ret' > in extcon-max77693.c. Resent both patches as per your suggestion. -- With warm regards, Sachin -- 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/
s390x: kernel BUG at fs/ext4/inode.c:1591!
System hung when running xfstests-dev 013 test case on an s390x guest. Never saw this on 3.9-rc3 before but need to double-check. Any idea? CAI Qian Ý 1113.795759¨ Ý cut here ¨ Ý 1113.795771¨ kernel BUG at fs/ext4/inode.c:1591! Ý 1113.795845¨ illegal operation: 0001 Ý#1¨ SMP Ý 1113.795848¨ Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ipt able_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT nf_conntrack_ipv4 nf_defra g_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tab les iptable_filter ip_tables sg qeth_l2 vmur xfs libcrc32c dasd_fba_mod dasd_eck d_mod dasd_mod lcs ctcm qeth fsm qdio ccwgroup dm_mirror dm_region_hash dm_log d m_mod Ý 1113.795880¨ CPU: 1 Not tainted 3.9.0-rc4+ #2 Ý 1113.795882¨ Process flush-253:1 (pid: 12418, task: 03f04890, ksp: 000 032eab3b8) Ý 1113.795885¨ Krnl PSW : 0704e0018000 0030bc62 (mpage_da_submit_io+ 0x38e/0x3c0) Ý 1113.795895¨R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 EA: 3 Krnl GPRS: 0100 1b5823a8 0010 1b5823a8 Ý 1113.795900¨ 00af 1000 000 032eab9c8 Ý 1113.795902¨03d10053bb40 32eaba30 00a1 000 032eaba98 Ý 1113.795905¨000100b0 00a1 0030b9a8 000 032eab8a0 Ý 1113.795921¨ Krnl Code: 0030bc54: f0dca7f4fecfsrp 2036(14, %r10),3791(%r15),12 MORE... ZVM-RHTS 0030bc5a: a7f40001 brc 15,30bc5c #0030bc5e: a7f40001 brc 15,30bc60 >0030bc62: a7f40001 brc 15,30bc64 0030bc66: a7f40001 brc 15,30bc68 0030bc6a: 4120f0e8 la %r2,232(%r15) 0030bc6e: a718 lhi %r1,0 Ý 1113.796303¨ Call Trace: Ý 1113.796306¨ (Ý<0030b9a8>¨ mpage_da_submit_io+0xd4/0x3c0) Ý 1113.796311¨ Ý<0031204c>¨ mpage_da_map_and_submit+0x150/0x41c Ý 1113.796314¨ Ý<00312bac>¨ ext4_da_writepages+0x364/0x628 Ý 1113.796317¨ Ý<002a08c8>¨ __writeback_single_inode+0x54/0x27c Ý 1113.796322¨ Ý<002a2c6c>¨ writeback_sb_inodes+0x284/0x4d8 Ý 1113.796325¨ Ý<002a30b6>¨ wb_writeback+0x10e/0x374 Ý 1113.796327¨ Ý<002a3d22>¨ wb_do_writeback+0x102/0x2e0 Ý 1113.796330¨ Ý<002a3fa2>¨ bdi_writeback_thread+0xa2/0x270 Ý 1113.796333¨ Ý<001581b2>¨ kthread+0xda/0xe4 Ý 1113.796338¨ Ý<00629836>¨ kernel_thread_starter+0x6/0xc Ý 1113.796342¨ Ý<00629830>¨ kernel_thread_starter+0x0/0xc Ý 1113.796345¨ Last Breaking-Event-Address: Ý 1113.796346¨ Ý<0030bc5e>¨ mpage_da_submit_io+0x38a/0x3c0 Ý 1113.796349¨ Ý 1113.796351¨ ---Ý end trace 45df5089b835470e ¨--- Ý 1113.796365¨ Ý cut here ¨ Ý 1113.796367¨ WARNING: at kernel/exit.c:715 Ý 1113.796369¨ Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ipt able_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT nf_conntrack_ipv4 nf_defra g_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tab les iptable_filter ip_tables sg qeth_l2 vmur xfs libcrc32c dasd_fba_mod dasd_eck d_mod dasd_mod lcs ctcm qeth fsm qdio ccwgroup dm_mirror dm_region_hash dm_log d m_mod Ý 1113.796393¨ CPU: 1 Tainted: G D 3.9.0-rc4+ #2 Ý 1113.796396¨ Process flush-253:1 (pid: 12418, task: 03f04890, ksp: 000 032eab3b8) Ý 1113.796398¨ Krnl PSW : 0704e0018000 00133074 (do_exit+0x54/0xab8) Ý 1113.796404¨R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 EA: 3 Krnl GPRS: 0015 32eabb60 32eabb68 Ý 1113.796408¨00133058 0001 00 MORE... ZVM-RHTS 032eab9c8 Ý 1113.796411¨0704e0018000 0030bc62 03f04890 000 000778d38 Ý 1113.796413¨000b 00634140 00133058 000 032eab4a0 Ý 1113.796423¨ Krnl Code: 00133066: e32010080020cg %r2,8(%r 1) 0013306c: a78403fa brc 8,133860 #00133070: a7f40001 brc 15,133072 >00133074: e31003180004 lg %r1,792 0013307a: 5810101c l %r1,28(%r1) 0013307e: c01b0100 nilf%r1,33554176 00133084: a7740481 brc 7,133986
[PATCH v2 1/2] extcon: max77693: Fix return value
Return the value obtained from the function instead of hardcoding.
Silences the following warnings:
drivers/extcon/extcon-max77693.c:297 max77693_muic_set_path()
info: why not propagate 'ret' from max77693_update_reg() instead of (-11)?
drivers/extcon/extcon-max77693.c:310 max77693_muic_set_path()
info: why not propagate 'ret' from max77693_update_reg() instead of (-11)?
Signed-off-by: Sachin Kamat
---
Changes since v1:
Include additional instances.
Compile tested.
---
drivers/extcon/extcon-max77693.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c
index 8f3c947..924db01 100644
--- a/drivers/extcon/extcon-max77693.c
+++ b/drivers/extcon/extcon-max77693.c
@@ -258,7 +258,7 @@ static int max77693_muic_set_debounce_time(struct
max77693_muic_info *info,
CONTROL3_ADCDBSET_MASK);
if (ret) {
dev_err(info->dev, "failed to set ADC debounce time\n");
- return -EAGAIN;
+ return ret;
}
break;
default:
@@ -294,7 +294,7 @@ static int max77693_muic_set_path(struct max77693_muic_info
*info,
MAX77693_MUIC_REG_CTRL1, ctrl1, COMP_SW_MASK);
if (ret < 0) {
dev_err(info->dev, "failed to update MUIC register\n");
- return -EAGAIN;
+ return ret;
}
if (attached)
@@ -307,7 +307,7 @@ static int max77693_muic_set_path(struct max77693_muic_info
*info,
CONTROL2_LOWPWR_MASK | CONTROL2_CPEN_MASK);
if (ret < 0) {
dev_err(info->dev, "failed to update MUIC register\n");
- return -EAGAIN;
+ return ret;
}
dev_info(info->dev,
@@ -1035,7 +1035,7 @@ static int max77693_muic_detect_accessory(struct
max77693_muic_info *info)
if (ret) {
dev_err(info->dev, "failed to read MUIC register\n");
mutex_unlock(&info->mutex);
- return -EINVAL;
+ return ret;
}
adc = max77693_muic_get_cable_type(info, MAX77693_CABLE_GROUP_ADC,
--
1.7.4.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 v2 2/2] extcon: max8997: Fix return value
Return the value obtained from the function instead of hardcoding.
Fixes the following warnings:
drivers/extcon/extcon-max8997.c:235 max8997_muic_set_path() info:
why not propagate 'ret' from max8997_update_reg() instead of (-11)?
drivers/extcon/extcon-max8997.c:248 max8997_muic_set_path() info:
why not propagate 'ret' from max8997_update_reg() instead of (-11)?
Signed-off-by: Sachin Kamat
---
drivers/extcon/extcon-max8997.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/extcon/extcon-max8997.c b/drivers/extcon/extcon-max8997.c
index 69641bc..3c593e8 100644
--- a/drivers/extcon/extcon-max8997.c
+++ b/drivers/extcon/extcon-max8997.c
@@ -196,7 +196,7 @@ static int max8997_muic_set_debounce_time(struct
max8997_muic_info *info,
CONTROL3_ADCDBSET_MASK);
if (ret) {
dev_err(info->dev, "failed to set ADC debounce time\n");
- return -EAGAIN;
+ return ret;
}
break;
default:
@@ -232,7 +232,7 @@ static int max8997_muic_set_path(struct max8997_muic_info
*info,
MAX8997_MUIC_REG_CONTROL1, ctrl1, COMP_SW_MASK);
if (ret < 0) {
dev_err(info->dev, "failed to update MUIC register\n");
- return -EAGAIN;
+ return ret;
}
if (attached)
@@ -245,7 +245,7 @@ static int max8997_muic_set_path(struct max8997_muic_info
*info,
CONTROL2_LOWPWR_MASK | CONTROL2_CPEN_MASK);
if (ret < 0) {
dev_err(info->dev, "failed to update MUIC register\n");
- return -EAGAIN;
+ return ret;
}
dev_info(info->dev,
@@ -397,7 +397,7 @@ static int max8997_muic_handle_jig_uart(struct
max8997_muic_info *info,
ret = max8997_muic_set_path(info, info->path_uart, attached);
if (ret) {
dev_err(info->dev, "failed to update muic register\n");
- return -EINVAL;
+ return ret;
}
extcon_set_cable_state(info->edev, "JIG", attached);
@@ -608,7 +608,7 @@ static int max8997_muic_detect_dev(struct max8997_muic_info
*info)
if (ret) {
dev_err(info->dev, "failed to read MUIC register\n");
mutex_unlock(&info->mutex);
- return -EINVAL;
+ return ret;
}
adc = max8997_muic_get_cable_type(info, MAX8997_CABLE_GROUP_ADC,
--
1.7.4.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 v2 1/4] iio: adc: Document the regulator/clocks for exynos-adc
Doug Anderson wrote: >Hi, > >On Wed, Mar 27, 2013 at 11:40 AM, Lars-Peter Clausen >wrote: >> On 03/27/2013 07:35 PM, Naveen Krishna Ch wrote: >>> On 13 March 2013 13:39, Doug Anderson wrote: The exynos ADC won't work without a regulator called "vdd" and a >clock called "adc". Document this fact in the device tree bindings. Signed-off-by: Doug Anderson >>> Reviewed-by: Naveen Krishna Chatradhi >>> >>> Lars, any update on this patch set. This change is required. >> >> Uhm, looks fine to me. I'm sure Jonathan will pick it up :) > >Part 2 made it in, but not the documentation patch. Now that it has a >Reviewed-by it can probably go in... :) > >-Doug I'll take it sometime over the weekend. Thanks. Jonathan -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- 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 1/2] workqueue: fix race condition in unbound workqueue free path
Oops, forgot something. Both patches are against wq/for-3.10 and fix problems introduced in this devel cycle, so no need to be alarmed. Thanks. -- tejun -- 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/2] workqueue: fix unbound workqueue attrs hashing / comparison
>From b37c3e3a74346749f0278c349dc0857107cb4370 Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Wed, 27 Mar 2013 23:27:41 -0700
29c91e9912b ("workqueue: implement attribute-based unbound worker_pool
management") implemented attrs based worker_pool matching. It tried
to avoid false negative when comparing cpumasks with custom hash
function; unfortunately, the hash and comparison functions fail to
ignore CPUs which are not possible. It incorrectly assumed that
bitmap_copy() skips leftover bits in the last word of bitmap and
cpumask_equal() ignores impossible CPUs.
This patch updates attrs->cpumask handling such that impossible CPUs
are properly ignored.
* Hash and copy functions no longer do anything special. They expect
their callers to clear impossible CPUs.
* alloc_workqueue_attrs() initializes the cpumask to cpu_possible_mask
instead of setting all bits and explicit cpumask_setall() for
unbound_std_wq_attrs[] in init_workqueues() is dropped.
* apply_workqueue_attrs() is now responsible for ignoring impossible
CPUs. It makes a copy of @attrs and clears impossible CPUs before
doing anything else.
Signed-off-by: Tejun Heo
---
kernel/workqueue.c | 54 ++
1 file changed, 22 insertions(+), 32 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 4d34432..abe1f0d 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3302,7 +3302,7 @@ struct workqueue_attrs *alloc_workqueue_attrs(gfp_t
gfp_mask)
if (!alloc_cpumask_var(&attrs->cpumask, gfp_mask))
goto fail;
- cpumask_setall(attrs->cpumask);
+ cpumask_copy(attrs->cpumask, cpu_possible_mask);
return attrs;
fail:
free_workqueue_attrs(attrs);
@@ -3316,33 +3316,14 @@ static void copy_workqueue_attrs(struct workqueue_attrs
*to,
cpumask_copy(to->cpumask, from->cpumask);
}
-/*
- * Hacky implementation of jhash of bitmaps which only considers the
- * specified number of bits. We probably want a proper implementation in
- * include/linux/jhash.h.
- */
-static u32 jhash_bitmap(const unsigned long *bitmap, int bits, u32 hash)
-{
- int nr_longs = bits / BITS_PER_LONG;
- int nr_leftover = bits % BITS_PER_LONG;
- unsigned long leftover = 0;
-
- if (nr_longs)
- hash = jhash(bitmap, nr_longs * sizeof(long), hash);
- if (nr_leftover) {
- bitmap_copy(&leftover, bitmap + nr_longs, nr_leftover);
- hash = jhash(&leftover, sizeof(long), hash);
- }
- return hash;
-}
-
/* hash value of the content of @attr */
static u32 wqattrs_hash(const struct workqueue_attrs *attrs)
{
u32 hash = 0;
hash = jhash_1word(attrs->nice, hash);
- hash = jhash_bitmap(cpumask_bits(attrs->cpumask), nr_cpu_ids, hash);
+ hash = jhash(cpumask_bits(attrs->cpumask),
+BITS_TO_LONGS(nr_cpumask_bits) * sizeof(long), hash);
return hash;
}
@@ -3652,7 +3633,8 @@ static void init_and_link_pwq(struct pool_workqueue *pwq,
int apply_workqueue_attrs(struct workqueue_struct *wq,
const struct workqueue_attrs *attrs)
{
- struct pool_workqueue *pwq, *last_pwq;
+ struct workqueue_attrs *new_attrs;
+ struct pool_workqueue *pwq = NULL, *last_pwq;
struct worker_pool *pool;
/* only unbound workqueues can change attributes */
@@ -3663,15 +3645,21 @@ int apply_workqueue_attrs(struct workqueue_struct *wq,
if (WARN_ON((wq->flags & __WQ_ORDERED) && !list_empty(&wq->pwqs)))
return -EINVAL;
+ /* make a copy of @attrs and sanitize it */
+ new_attrs = alloc_workqueue_attrs(GFP_KERNEL);
+ if (!new_attrs)
+ goto enomem;
+
+ copy_workqueue_attrs(new_attrs, attrs);
+ cpumask_and(new_attrs->cpumask, new_attrs->cpumask, cpu_possible_mask);
+
pwq = kmem_cache_zalloc(pwq_cache, GFP_KERNEL);
if (!pwq)
- return -ENOMEM;
+ goto enomem;
- pool = get_unbound_pool(attrs);
- if (!pool) {
- kmem_cache_free(pwq_cache, pwq);
- return -ENOMEM;
- }
+ pool = get_unbound_pool(new_attrs);
+ if (!pool)
+ goto enomem;
init_and_link_pwq(pwq, wq, pool, &last_pwq);
if (last_pwq) {
@@ -3681,6 +3669,11 @@ int apply_workqueue_attrs(struct workqueue_struct *wq,
}
return 0;
+
+enomem:
+ kmem_cache_free(pwq_cache, pwq);
+ free_workqueue_attrs(new_attrs);
+ return -ENOMEM;
}
static int alloc_and_link_pwqs(struct workqueue_struct *wq)
@@ -4450,10 +4443,7 @@ static int __init init_workqueues(void)
struct workqueue_attrs *attrs;
BUG_ON(!(attrs = alloc_workqueue_attrs(GFP_KERNEL)));
-
attrs->nice = std_nice[i];
- cpumask_setall(attrs->cpumask);
-
unbound_std_wq_attrs[i] = attrs;
}
[PATCH 1/2] workqueue: fix race condition in unbound workqueue free path
>From b2277a4e655c0858da7d85b99f0925abeedc3b6c Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Wed, 27 Mar 2013 23:27:41 -0700
8864b4e59 ("workqueue: implement get/put_pwq()") implemented pwq
(pool_workqueue) refcnting which frees workqueue when the last pwq
goes away. It determined whether it was the last pwq by testing
wq->pwqs is empty. Unfortunately, the test was done outside wq->mutex
and multiple pwq release could race and try to free wq multiple times
leading to oops.
Test wq->pwqs emptiness while holding wq->mutex.
Signed-off-by: Tejun Heo
---
kernel/workqueue.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 04a8b98..4d34432 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3534,6 +3534,7 @@ static void pwq_unbound_release_workfn(struct work_struct
*work)
unbound_release_work);
struct workqueue_struct *wq = pwq->wq;
struct worker_pool *pool = pwq->pool;
+ bool is_last;
if (WARN_ON_ONCE(!(wq->flags & WQ_UNBOUND)))
return;
@@ -3545,6 +3546,7 @@ static void pwq_unbound_release_workfn(struct work_struct
*work)
*/
mutex_lock(&wq->mutex);
list_del_rcu(&pwq->pwqs_node);
+ is_last = list_empty(&wq->pwqs);
mutex_unlock(&wq->mutex);
put_unbound_pool(pool);
@@ -3554,7 +3556,7 @@ static void pwq_unbound_release_workfn(struct work_struct
*work)
* If we're the last pwq going away, @wq is already dead and no one
* is gonna access it anymore. Free it.
*/
- if (list_empty(&wq->pwqs))
+ if (is_last)
kfree(wq);
}
--
1.8.1.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 3/3] backlight: vgg2432a4: convert vgg2432a4_driver to dev_pm_ops
Instead of using legacy suspend/resume methods, using newer dev_pm_ops
structure allows better control over power management. Also, use of
pm_message_t is deprecated. Thus, it is removed.
Signed-off-by: Jingoo Han
---
drivers/video/backlight/ili9320.c | 24 +---
drivers/video/backlight/ili9320.h |2 +-
drivers/video/backlight/vgg2432a4.c | 18 --
3 files changed, 18 insertions(+), 26 deletions(-)
diff --git a/drivers/video/backlight/ili9320.c
b/drivers/video/backlight/ili9320.c
index 1235bf9..f5edbbe 100644
--- a/drivers/video/backlight/ili9320.c
+++ b/drivers/video/backlight/ili9320.c
@@ -270,27 +270,21 @@ int ili9320_remove(struct ili9320 *ili)
}
EXPORT_SYMBOL_GPL(ili9320_remove);
-#ifdef CONFIG_PM
-int ili9320_suspend(struct ili9320 *lcd, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+int ili9320_suspend(struct ili9320 *lcd)
{
int ret;
- dev_dbg(lcd->dev, "%s: event %d\n", __func__, state.event);
+ ret = ili9320_power(lcd, FB_BLANK_POWERDOWN);
- if (state.event == PM_EVENT_SUSPEND) {
- ret = ili9320_power(lcd, FB_BLANK_POWERDOWN);
-
- if (lcd->platdata->suspend == ILI9320_SUSPEND_DEEP) {
- ili9320_write(lcd, ILI9320_POWER1, lcd->power1 |
- ILI9320_POWER1_SLP |
- ILI9320_POWER1_DSTB);
- lcd->initialised = 0;
- }
-
- return ret;
+ if (lcd->platdata->suspend == ILI9320_SUSPEND_DEEP) {
+ ili9320_write(lcd, ILI9320_POWER1, lcd->power1 |
+ ILI9320_POWER1_SLP |
+ ILI9320_POWER1_DSTB);
+ lcd->initialised = 0;
}
- return 0;
+ return ret;
}
EXPORT_SYMBOL_GPL(ili9320_suspend);
diff --git a/drivers/video/backlight/ili9320.h
b/drivers/video/backlight/ili9320.h
index e0db738..42329e7 100644
--- a/drivers/video/backlight/ili9320.h
+++ b/drivers/video/backlight/ili9320.h
@@ -76,5 +76,5 @@ extern void ili9320_shutdown(struct ili9320 *lcd);
/* PM */
-extern int ili9320_suspend(struct ili9320 *lcd, pm_message_t state);
+extern int ili9320_suspend(struct ili9320 *lcd);
extern int ili9320_resume(struct ili9320 *lcd);
diff --git a/drivers/video/backlight/vgg2432a4.c
b/drivers/video/backlight/vgg2432a4.c
index 84d582f..d538947 100644
--- a/drivers/video/backlight/vgg2432a4.c
+++ b/drivers/video/backlight/vgg2432a4.c
@@ -205,18 +205,15 @@ static int vgg2432a4_lcd_init(struct ili9320 *lcd,
return ret;
}
-#ifdef CONFIG_PM
-static int vgg2432a4_suspend(struct spi_device *spi, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int vgg2432a4_suspend(struct device *dev)
{
- return ili9320_suspend(spi_get_drvdata(spi), state);
+ return ili9320_suspend(dev_get_drvdata(dev));
}
-static int vgg2432a4_resume(struct spi_device *spi)
+static int vgg2432a4_resume(struct device *dev)
{
- return ili9320_resume(spi_get_drvdata(spi));
+ return ili9320_resume(dev_get_drvdata(dev));
}
-#else
-#define vgg2432a4_suspend NULL
-#define vgg2432a4_resume NULL
#endif
static struct ili9320_client vgg2432a4_client = {
@@ -249,16 +246,17 @@ static void vgg2432a4_shutdown(struct spi_device *spi)
ili9320_shutdown(spi_get_drvdata(spi));
}
+static SIMPLE_DEV_PM_OPS(vgg2432a4_pm_ops, vgg2432a4_suspend,
vgg2432a4_resume);
+
static struct spi_driver vgg2432a4_driver = {
.driver = {
.name = "VGG2432A4",
.owner = THIS_MODULE,
+ .pm = &vgg2432a4_pm_ops,
},
.probe = vgg2432a4_probe,
.remove = vgg2432a4_remove,
.shutdown = vgg2432a4_shutdown,
- .suspend= vgg2432a4_suspend,
- .resume = vgg2432a4_resume,
};
module_spi_driver(vgg2432a4_driver);
--
1.7.2.5
--
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] backlight: tosa: convert tosa to dev_pm_ops
Instead of using legacy suspend/resume methods, using newer dev_pm_ops
structure allows better control over power management.
Signed-off-by: Jingoo Han
---
drivers/video/backlight/tosa_bl.c | 18 --
drivers/video/backlight/tosa_lcd.c | 18 --
2 files changed, 16 insertions(+), 20 deletions(-)
diff --git a/drivers/video/backlight/tosa_bl.c
b/drivers/video/backlight/tosa_bl.c
index 2326fa8..9df66ac 100644
--- a/drivers/video/backlight/tosa_bl.c
+++ b/drivers/video/backlight/tosa_bl.c
@@ -134,28 +134,27 @@ static int tosa_bl_remove(struct i2c_client *client)
return 0;
}
-#ifdef CONFIG_PM
-static int tosa_bl_suspend(struct i2c_client *client, pm_message_t pm)
+#ifdef CONFIG_PM_SLEEP
+static int tosa_bl_suspend(struct device *dev)
{
- struct tosa_bl_data *data = i2c_get_clientdata(client);
+ struct tosa_bl_data *data = dev_get_drvdata(dev);
tosa_bl_set_backlight(data, 0);
return 0;
}
-static int tosa_bl_resume(struct i2c_client *client)
+static int tosa_bl_resume(struct device *dev)
{
- struct tosa_bl_data *data = i2c_get_clientdata(client);
+ struct tosa_bl_data *data = dev_get_drvdata(dev);
backlight_update_status(data->bl);
return 0;
}
-#else
-#define tosa_bl_suspend NULL
-#define tosa_bl_resume NULL
#endif
+static SIMPLE_DEV_PM_OPS(tosa_bl_pm_ops, tosa_bl_suspend, tosa_bl_resume);
+
static const struct i2c_device_id tosa_bl_id[] = {
{ "tosa-bl", 0 },
{ },
@@ -165,11 +164,10 @@ static struct i2c_driver tosa_bl_driver = {
.driver = {
.name = "tosa-bl",
.owner = THIS_MODULE,
+ .pm = &tosa_bl_pm_ops,
},
.probe = tosa_bl_probe,
.remove = tosa_bl_remove,
- .suspend= tosa_bl_suspend,
- .resume = tosa_bl_resume,
.id_table = tosa_bl_id,
};
diff --git a/drivers/video/backlight/tosa_lcd.c
b/drivers/video/backlight/tosa_lcd.c
index 666fe25..bf08157 100644
--- a/drivers/video/backlight/tosa_lcd.c
+++ b/drivers/video/backlight/tosa_lcd.c
@@ -240,19 +240,19 @@ static int tosa_lcd_remove(struct spi_device *spi)
return 0;
}
-#ifdef CONFIG_PM
-static int tosa_lcd_suspend(struct spi_device *spi, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int tosa_lcd_suspend(struct device *dev)
{
- struct tosa_lcd_data *data = spi_get_drvdata(spi);
+ struct tosa_lcd_data *data = dev_get_drvdata(dev);
tosa_lcd_tg_off(data);
return 0;
}
-static int tosa_lcd_resume(struct spi_device *spi)
+static int tosa_lcd_resume(struct device *dev)
{
- struct tosa_lcd_data *data = spi_get_drvdata(spi);
+ struct tosa_lcd_data *data = dev_get_drvdata(dev);
tosa_lcd_tg_init(data);
if (POWER_IS_ON(data->lcd_power))
@@ -262,20 +262,18 @@ static int tosa_lcd_resume(struct spi_device *spi)
return 0;
}
-#else
-#define tosa_lcd_suspend NULL
-#define tosa_lcd_resume NULL
#endif
+static SIMPLE_DEV_PM_OPS(tosa_lcd_pm_ops, tosa_lcd_suspend, tosa_lcd_resume);
+
static struct spi_driver tosa_lcd_driver = {
.driver = {
.name = "tosa-lcd",
.owner = THIS_MODULE,
+ .pm = &tosa_lcd_pm_ops,
},
.probe = tosa_lcd_probe,
.remove = tosa_lcd_remove,
- .suspend= tosa_lcd_suspend,
- .resume = tosa_lcd_resume,
};
module_spi_driver(tosa_lcd_driver);
--
1.7.2.5
--
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] backlight: omap1: convert omapbl to dev_pm_ops
Instead of using legacy suspend/resume methods, using newer dev_pm_ops
structure allows better control over power management.
Signed-off-by: Jingoo Han
---
drivers/video/backlight/omap1_bl.c | 22 ++
1 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/video/backlight/omap1_bl.c
b/drivers/video/backlight/omap1_bl.c
index 0aed176..812e22e 100644
--- a/drivers/video/backlight/omap1_bl.c
+++ b/drivers/video/backlight/omap1_bl.c
@@ -71,27 +71,24 @@ static void omapbl_blank(struct omap_backlight *bl, int
mode)
}
}
-#ifdef CONFIG_PM
-static int omapbl_suspend(struct platform_device *pdev, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int omapbl_suspend(struct device *dev)
{
- struct backlight_device *dev = platform_get_drvdata(pdev);
- struct omap_backlight *bl = bl_get_data(dev);
+ struct backlight_device *bl_dev = dev_get_drvdata(dev);
+ struct omap_backlight *bl = bl_get_data(bl_dev);
omapbl_blank(bl, FB_BLANK_POWERDOWN);
return 0;
}
-static int omapbl_resume(struct platform_device *pdev)
+static int omapbl_resume(struct device *dev)
{
- struct backlight_device *dev = platform_get_drvdata(pdev);
- struct omap_backlight *bl = bl_get_data(dev);
+ struct backlight_device *bl_dev = dev_get_drvdata(dev);
+ struct omap_backlight *bl = bl_get_data(bl_dev);
omapbl_blank(bl, bl->powermode);
return 0;
}
-#else
-#define omapbl_suspend NULL
-#define omapbl_resume NULL
#endif
static int omapbl_set_power(struct backlight_device *dev, int state)
@@ -182,13 +179,14 @@ static int omapbl_remove(struct platform_device *pdev)
return 0;
}
+static SIMPLE_DEV_PM_OPS(omapbl_pm_ops, omapbl_suspend, omapbl_resume);
+
static struct platform_driver omapbl_driver = {
.probe = omapbl_probe,
.remove = omapbl_remove,
- .suspend= omapbl_suspend,
- .resume = omapbl_resume,
.driver = {
.name = "omap-bl",
+ .pm = &omapbl_pm_ops,
},
};
--
1.7.2.5
--
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] hw_random: Add Broadcom BCM2835 RNG driver
This adds a driver for random number generator present on Broadcom BCM2835 SoC,
used in Raspberry Pi and Roku 2 devices.
Signed-off-by: Dom Cobley
Signed-off-by: Lubomir Rintel
Tested-by: Stephen Warren
Cc: Herbert Xu
Cc: Stephen Warren
Cc: Matt Mackall
Cc: linux-rpi-ker...@lists.infradead.org
---
Changes for v2:
- Device tree and defconfig changes split out
- Licence changed from GPLv2+BSD to GPLv2 only
- Style fixes
Changes for v3:
- Device tree binding documentation added
.../devicetree/bindings/rng/brcm,bcm2835.txt | 13 +++
drivers/char/hw_random/Kconfig | 12 ++
drivers/char/hw_random/Makefile|1 +
drivers/char/hw_random/bcm2835-rng.c | 113
4 files changed, 139 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
create mode 100644 drivers/char/hw_random/bcm2835-rng.c
diff --git a/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
b/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
new file mode 100644
index 000..07ccdaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
@@ -0,0 +1,13 @@
+BCM2835 Random number generator
+
+Required properties:
+
+- compatible : should be "brcm,bcm2835-rng"
+- reg : Specifies base physical address and size of the registers.
+
+Example:
+
+rng {
+compatible = "brcm,bcm2835-rng";
+reg = <0x7e104000 0x10>;
+};
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index c5a0262..2f9dbf7 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -86,6 +86,18 @@ config HW_RANDOM_BCM63XX
If unusure, say Y.
+config HW_RANDOM_BCM2835
+ tristate "Broadcom BCM2835 Random Number Generator support"
+ depends on HW_RANDOM && ARCH_BCM2835
+ default HW_RANDOM
+ ---help---
+ This driver provides kernel-side support for the Random Number
+ Generator hardware found on the Broadcom BCM2835 SoCs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called bcm2835-rng
+
+ If unsure, say Y.
config HW_RANDOM_GEODE
tristate "AMD Geode HW Random Number Generator support"
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 1fd7eec..bed467c 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -26,3 +26,4 @@ obj-$(CONFIG_HW_RANDOM_PPC4XX) += ppc4xx-rng.o
obj-$(CONFIG_HW_RANDOM_PSERIES) += pseries-rng.o
obj-$(CONFIG_HW_RANDOM_EXYNOS) += exynos-rng.o
obj-$(CONFIG_HW_RANDOM_TPM) += tpm-rng.o
+obj-$(CONFIG_HW_RANDOM_BCM2835) += bcm2835-rng.o
diff --git a/drivers/char/hw_random/bcm2835-rng.c
b/drivers/char/hw_random/bcm2835-rng.c
new file mode 100644
index 000..eb7f147
--- /dev/null
+++ b/drivers/char/hw_random/bcm2835-rng.c
@@ -0,0 +1,113 @@
+/**
+ * Copyright (c) 2010-2012 Broadcom. All rights reserved.
+ * Copyright (c) 2013 Lubomir Rintel
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License ("GPL")
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define RNG_CTRL 0x0
+#define RNG_STATUS 0x4
+#define RNG_DATA 0x8
+
+/* enable rng */
+#define RNG_RBGEN 0x1
+
+/* the initial numbers generated are "less random" so will be discarded */
+#define RNG_WARMUP_COUNT 0x4
+
+static int bcm2835_rng_read(struct hwrng *rng, void *buf, size_t max,
+ bool wait)
+{
+ void __iomem *rng_base = (void __iomem *)rng->priv;
+
+ while ((__raw_readl(rng_base + RNG_STATUS) >> 24) == 0) {
+ if (!wait)
+ return 0;
+ cpu_relax();
+ }
+
+ *(u32 *)buf = __raw_readl(rng_base + RNG_DATA);
+ return sizeof(u32);
+}
+
+static struct hwrng bcm2835_rng_ops = {
+ .name = "bcm2835",
+ .read = bcm2835_rng_read,
+};
+
+static int bcm2835_rng_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ void __iomem *rng_base;
+ int err;
+
+ /* map peripheral */
+ rng_base = of_iomap(np, 0);
+ if (!rng_base) {
+ dev_err(dev, "failed to remap rng regs");
+ return -ENODEV;
+ }
+ bcm2835_rng_ops.priv = (unsigned long)rng_base;
+
+ /* register driver */
+ err = hwrng_register(&bcm2835_rng_ops);
+ if (err) {
+ dev_err(dev, "hwrng registration failed\n");
+ iounmap(rng_base);
+ } else {
+ dev_info(dev, "hwrng registered\n");
+
+ /* set warm-up count & enable */
+ __raw_writel(RNG_WARMUP_COUNT, rng_base + RNG_STATUS);
+
[PATCH] iommu: exynos: Fix out of bound array access
In the case of no-match in "for (i = 0; i < (pdev->num_resources / 2); i++)",
i is "pdev->num_resources / 2". Fix the boundary checking to avoid the out of
bound array access for data->sfrbases[i].
Signed-off-by: Axel Lin
---
drivers/iommu/exynos-iommu.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 238a3ca..de04e6a 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -357,7 +357,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
break;
}
- if (i == pdev->num_resources) {
+ if (i == pdev->num_resources / 2) {
itype = SYSMMU_FAULT_UNKNOWN;
} else {
itype = (enum exynos_sysmmu_inttype)
--
1.7.10.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/
Re: [PATCH] pinctrl: bcm2835: make use of of_property_read_u32_index()
On Wed, 2013-03-27 at 23:09 -0600, Stephen Warren wrote: > Use the new standard API of_property_read_u32_index() instead of open- > coding it. > > Signed-off-by: Stephen Warren > --- > Note: This depends on the proposed patch "of: Add support for reading > a u32 from a multi-value property" by Tony Prisk. > > BTW, I realized why I didn't create that standard API, but wrote custom > prop_u32() instead; the code has already looked up the properties, and > validated their length, so prop_u32() can simply index into the property > data, whereas of_property_read_u32_index() needs to go search for the > property and re-validate it every time, so there's a bunch more overhead. > It also means duplicating the property name, although I could use a > define for that. I'm not entirely convinced that using this standard API > is a win in this case. LinusW, Tony, what do you think? > --- When I was writing the function I had a similar thought about the fact we need to work out the length first, which as you mentioned, requires all the prior work on the property anyway. I didn't bring it up, because I thought someone might say 'hey, you should add a function to get the count as well' :) In both the brcm and vt8500 use cases, we will have the issue of multiple lookups on the same property using 'generic' functions. Price we have to pay for generic code? Regards Tony P -- 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] hw_random: Add Broadcom BCM2835 RNG Driver
On Fri, 2013-03-22 at 20:44 -0600, Stephen Warren wrote: > On 03/22/2013 06:55 AM, Lubomir Rintel wrote: > > Signed-off-by: Lubomir Rintel > > A commit description would be useful. > > > arch/arm/boot/dts/bcm2835.dtsi |5 + > > arch/arm/configs/bcm2835_defconfig |3 +- > > drivers/char/hw_random/Kconfig | 12 +++ > > drivers/char/hw_random/Makefile |1 + > > drivers/char/hw_random/bcm2835-rng.c | 137 > > ++ > > This should be split into 3 separate patches: (1) The driver itself, (2) > the change to bcm2835.dtsi, and (3) the change to bcm2835_defconfig. > > Since you're adding a new device to device tree for the first time, you > should write a binding document for it; most likely > Documentation/devicetree/bindings/rng/brcm,bcm2835.txt (or perhaps > /random/ rather than /rng/?) > > Is this driver based on the downstream Raspberry Pi kernel's driver? If > so, some mention of that fact would be appropriate in the commit > description, or even the git author field. I note that in the downstream > kernel, the commit which adds the RNG driver isn't signed off at all. > This probably means you need to get Dom to add his signed-off-by line > for that commit before basing your work on it. See > Documentation/SubmittingPatches for more details. Got this message, will follow up with updated patch: On Wed, 2013-03-27 at 18:22 +, popcornmix wrote: On Wed, Mar 27, 2013 at 4:55 PM, Lubomir Rintel wrote: > > Hi! > > > > I'm currently in the process of mainlining the drivers from Raspberry Pi > > tree. I was asked for a signoff for the random number generator. It > > seems to have been commit by you in the downstream tree, I'm wondering > > if you could help me, and respond with a Signed-off-by tag if the code > > comes from you, or point me to someone else? > > > > commit e95a8204d7f8fc4f38900c99080103254c3cef11 > > Author: popcornmix > > Date: Wed Jan 30 11:44:26 2013 + > > > > Add hwrng (hardware random number generator) driver > > > > Thank you! > > -- > > Lubomir Rintel > > > > Sorry, I'm not up to speed with exactly what constitutes a sign off. > I did write the original hw-rng driver, and give my permission for it > to be upstreamed. > Is this sufficient? > Signed-off-by: Dom Cobley > Signed-off-by: Dom Cobley > Signed-off-by: popcornmix > > (not sure which is more suitable - they are all me). -- Lubomir Rintel (ext. #7715) GoodData Code Feng Shui Critic -- 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] ALSA: hda - Clean up documentation a bit
On 03/27/2013 03:30:22 AM, Paul Bolle wrote:
CONFIG_SND_HDA_POWER_SAVE was removed in v3.6.7, see commit
83012a7ccbb90dee33c97a004b3e374f988612af ("ALSA: hda - Clean up
CONFIG_SND_HDA_POWER_SAVE"). Clean up hda's documentation to reflect
that.
Signed-off-by: Paul Bolle
---
0) I send this to the sound maintainers. I guess this they need to
send
it to the Documentation maintainer (after review).
No, it can go in via their tree. I'm more a librarian trying to keep
the shelves in order, and some light copyediting on the side. I'm not a
domain expert in everything, and thus can't _write_ most of this stuff.
Rob
--
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] bcm2835: Add Broadcom BCM2835 RNG to the device tree
This adds a device tree binding for random number generator present on Broadcom
BCM2835 SoC, used in Raspberry Pi and Roku 2 devices.
Signed-off-by: Lubomir Rintel
Tested-by: Stephen Warren
Cc: Stephen Warren
Cc: linux-rpi-ker...@lists.infradead.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
---
Changes for v2:
- Split out from the driver changeset
- Added documentation
Changes for v3:
- Moved documentation away to the driver commit
arch/arm/boot/dts/bcm2835.dtsi |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 7e0481e..dc22336 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -34,6 +34,11 @@
reg = <0x7e10 0x28>;
};
+ rng {
+ compatible = "brcm,bcm2835-rng";
+ reg = <0x7e104000 0x10>;
+ };
+
uart@20201000 {
compatible = "brcm,bcm2835-pl011", "arm,pl011",
"arm,primecell";
reg = <0x7e201000 0x1000>;
--
1.7.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/
[PATCHv3 2/6] arm: vt8500: Increase available GPIOs on arch-vt8500
With the inclusion of the pin control driver, more GPIO pins have been identified on the arch-vt8500 SoCs requiring an increase in the available GPIOs. Signed-off-by: Tony Prisk --- arch/arm/Kconfig |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 13b7394..244c618 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1661,7 +1661,8 @@ config ARCH_NR_GPIO default 1024 if ARCH_SHMOBILE || ARCH_TEGRA default 512 if SOC_OMAP5 default 355 if ARCH_U8500 - default 288 if ARCH_VT8500 || ARCH_SUNXI + default 352 if ARCH_VT8500 + default 288 if ARCH_SUNXI default 264 if MACH_H4700 default 0 help -- 1.7.9.5 -- 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/
[PATCHv3 1/6] of: Add support for reading a u32 from a multi-value property.
This patch adds an of_property_read_u32_index() function to allow
reading a single indexed u32 value from a property containing multiple
u32 values.
Signed-off-by: Tony Prisk
---
drivers/of/base.c | 33 +
include/linux/of.h |9 +
2 files changed, 42 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 321d3ef..7dc001e 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -746,6 +746,39 @@ struct device_node *of_find_node_by_phandle(phandle handle)
EXPORT_SYMBOL(of_find_node_by_phandle);
/**
+ * of_property_read_u32_index - Find and read a u32 from a multi-value
property.
+ *
+ * @np:device node from which the property value is to be read.
+ * @propname: name of the property to be searched.
+ * @index: index of the u32 in the list of values
+ * @out_value: pointer to return value, modified only if no error.
+ *
+ * Search for a property in a device node and read nth 32-bit value from
+ * it. Returns 0 on success, -EINVAL if the property does not exist,
+ * -ENODATA if property does not have a value, and -EOVERFLOW if the
+ * property data isn't large enough.
+ *
+ * The out_value is modified only if a valid u32 value can be decoded.
+ */
+int of_property_read_u32_index(const struct device_node *np,
+ const char *propname,
+ u32 index, u32 *out_value)
+{
+ struct property *prop = of_find_property(np, propname, NULL);
+
+ if (!prop)
+ return -EINVAL;
+ if (!prop->value)
+ return -ENODATA;
+ if ((index * sizeof(*out_value)) > prop->length)
+ return -EOVERFLOW;
+
+ *out_value = be32_to_cpup(((__be32 *)prop->value) + index);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_property_read_u32_index);
+
+/**
* of_property_read_u8_array - Find and read an array of u8 from a property.
*
* @np:device node from which the property value is to be read.
diff --git a/include/linux/of.h b/include/linux/of.h
index a0f1292..c0747a4 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -235,6 +235,9 @@ extern struct device_node *of_find_node_with_property(
extern struct property *of_find_property(const struct device_node *np,
const char *name,
int *lenp);
+extern int of_property_read_u32_index(const struct device_node *np,
+ const char *propname,
+ u32 index, u32 *out_value);
extern int of_property_read_u8_array(const struct device_node *np,
const char *propname, u8 *out_values, size_t sz);
extern int of_property_read_u16_array(const struct device_node *np,
@@ -394,6 +397,12 @@ static inline struct device_node *of_find_compatible_node(
return NULL;
}
+static inline int of_property_read_u32_index(const struct device_node *np,
+ const char *propname, u32 index, u32 *out_value)
+{
+ return -ENOSYS;
+}
+
static inline int of_property_read_u8_array(const struct device_node *np,
const char *propname, u8 *out_values, size_t sz)
{
--
1.7.9.5
--
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/
[PATCHv3 6/6] gpio: vt8500: Remove arch-vt8500 gpio driver
With the move to a combined pinctrl/gpio driver, the arch-vt8500
gpio driver is no longer required.
Signed-off-by: Tony Prisk
---
.../devicetree/bindings/gpio/gpio-vt8500.txt | 24 --
drivers/gpio/Kconfig |6 -
drivers/gpio/Makefile |1 -
drivers/gpio/gpio-vt8500.c | 355
4 files changed, 386 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
delete mode 100644 drivers/gpio/gpio-vt8500.c
diff --git a/Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
b/Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
deleted file mode 100644
index f4dc523..000
--- a/Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-VIA/Wondermedia VT8500 GPIO Controller
--
-
-Required properties:
-- compatible : "via,vt8500-gpio", "wm,wm8505-gpio"
- or "wm,wm8650-gpio" depending on your SoC
-- reg : Should contain 1 register range (address and length)
-- #gpio-cells : should be <3>.
- 1) bank
- 2) pin number
- 3) flags - should be 0
-
-Example:
-
- gpio: gpio-controller@d811 {
- compatible = "via,vt8500-gpio";
- gpio-controller;
- reg = <0xd811 0x1>;
- #gpio-cells = <3>;
- };
-
- vibrate {
- gpios = <&gpio 0 1 0>; /* Bank 0, Pin 1, No flags */
- };
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 93aaadf..b166e30 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -227,12 +227,6 @@ config GPIO_TS5500
blocks of the TS-5500: DIO1, DIO2 and the LCD port, and the TS-5600
LCD port.
-config GPIO_VT8500
- bool "VIA/Wondermedia SoC GPIO Support"
- depends on ARCH_VT8500
- help
- Say yes here to support the VT8500/WM8505/WM8650 GPIO controller.
-
config GPIO_XILINX
bool "Xilinx GPIO support"
depends on PPC_OF || MICROBLAZE
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 22e07bc..a274d7d 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -80,7 +80,6 @@ obj-$(CONFIG_GPIO_TWL6040)+= gpio-twl6040.o
obj-$(CONFIG_GPIO_UCB1400) += gpio-ucb1400.o
obj-$(CONFIG_GPIO_VIPERBOARD) += gpio-viperboard.o
obj-$(CONFIG_GPIO_VR41XX) += gpio-vr41xx.o
-obj-$(CONFIG_GPIO_VT8500) += gpio-vt8500.o
obj-$(CONFIG_GPIO_VX855) += gpio-vx855.o
obj-$(CONFIG_GPIO_WM831X) += gpio-wm831x.o
obj-$(CONFIG_GPIO_WM8350) += gpio-wm8350.o
diff --git a/drivers/gpio/gpio-vt8500.c b/drivers/gpio/gpio-vt8500.c
deleted file mode 100644
index 81683ca..000
--- a/drivers/gpio/gpio-vt8500.c
+++ /dev/null
@@ -1,355 +0,0 @@
-/* drivers/gpio/gpio-vt8500.c
- *
- * Copyright (C) 2012 Tony Prisk
- * Based on arch/arm/mach-vt8500/gpio.c:
- * - Copyright (C) 2010 Alexey Charkov
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-/*
- We handle GPIOs by bank, each bank containing up to 32 GPIOs covered
- by one set of registers (although not all may be valid).
-
- Because different SoC's have different register offsets, we pass the
- register offsets as data in vt8500_gpio_dt_ids[].
-
- A value of NO_REG is used to indicate that this register is not
- supported. Only used for ->en at the moment.
-*/
-
-#define NO_REG 0x
-
-/*
- * struct vt8500_gpio_bank_regoffsets
- * @en: offset to enable register of the bank
- * @dir: offset to direction register of the bank
- * @data_out: offset to the data out register of the bank
- * @data_in: offset to the data in register of the bank
- * @ngpio: highest valid pin in this bank
- */
-
-struct vt8500_gpio_bank_regoffsets {
- unsigned inten;
- unsigned intdir;
- unsigned intdata_out;
- unsigned intdata_in;
- unsigned char ngpio;
-};
-
-struct vt8500_gpio_data {
- unsigned intnum_banks;
- struct vt8500_gpio_bank_regoffsets banks[];
-};
-
-#define VT8500_BANK(__en, __dir, __out, __in, __ngpio) \
-{ \
- .en = __en, \
- .dir = __dir, \
- .data_out = __out,
[PATCHv3 4/6] arm: dts: vt8500: Update Wondermedia SoC dtsi files for pinctrl driver
This patch adds pinctrl nodes to the VIA VT8500 and Wondermedia SoC dtsi
files to support the pinctrl driver.
Signed-off-by: Tony Prisk
---
arch/arm/boot/dts/vt8500.dtsi |9 +
arch/arm/boot/dts/wm8505.dtsi |9 +
arch/arm/boot/dts/wm8650.dtsi |9 +
arch/arm/boot/dts/wm8850.dtsi |9 +
4 files changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/vt8500.dtsi b/arch/arm/boot/dts/vt8500.dtsi
index cf31ced..8e87aa9 100644
--- a/arch/arm/boot/dts/vt8500.dtsi
+++ b/arch/arm/boot/dts/vt8500.dtsi
@@ -32,6 +32,15 @@
#gpio-cells = <3>;
};
+ pinctrl: pinctrl@d811 {
+ compatible = "via,vt8500-pinctrl";
+ reg = <0xd811 0x1>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
pmc@d813 {
compatible = "via,vt8500-pmc";
reg = <0xd813 0x1000>;
diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
index e74a1c0..e4f768a 100644
--- a/arch/arm/boot/dts/wm8505.dtsi
+++ b/arch/arm/boot/dts/wm8505.dtsi
@@ -47,6 +47,15 @@
#gpio-cells = <3>;
};
+ pinctrl: pinctrl@d811 {
+ compatible = "wm,wm8505-pinctrl";
+ reg = <0xd811 0x1>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
pmc@d813 {
compatible = "via,vt8500-pmc";
reg = <0xd813 0x1000>;
diff --git a/arch/arm/boot/dts/wm8650.dtsi b/arch/arm/boot/dts/wm8650.dtsi
index db3c0a1..01b6a8d 100644
--- a/arch/arm/boot/dts/wm8650.dtsi
+++ b/arch/arm/boot/dts/wm8650.dtsi
@@ -41,6 +41,15 @@
#gpio-cells = <3>;
};
+ pinctrl: pinctrl@d811 {
+ compatible = "wm,wm8650-pinctrl";
+ reg = <0xd811 0x1>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
pmc@d813 {
compatible = "via,vt8500-pmc";
reg = <0xd813 0x1000>;
diff --git a/arch/arm/boot/dts/wm8850.dtsi b/arch/arm/boot/dts/wm8850.dtsi
index e8cbfdc..297aa05 100644
--- a/arch/arm/boot/dts/wm8850.dtsi
+++ b/arch/arm/boot/dts/wm8850.dtsi
@@ -48,6 +48,15 @@
#gpio-cells = <3>;
};
+ pinctrl: pinctrl@d811 {
+ compatible = "wm,wm8850-pinctrl";
+ reg = <0xd811 0x1>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
pmc@d813 {
compatible = "via,vt8500-pmc";
reg = <0xd813 0x1000>;
--
1.7.9.5
--
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/
[PATCHv3 5/6] arm: vt8500: Remove gpio devicetree nodes
Remove the gpio related devicetree nodes as these are no longer required
with the move to a combined pinctrl/gpio driver.
Signed-off-by: Tony Prisk
---
arch/arm/boot/dts/vt8500.dtsi |7 ---
arch/arm/boot/dts/wm8505.dtsi |7 ---
arch/arm/boot/dts/wm8650.dtsi |7 ---
arch/arm/boot/dts/wm8850.dtsi |7 ---
4 files changed, 28 deletions(-)
diff --git a/arch/arm/boot/dts/vt8500.dtsi b/arch/arm/boot/dts/vt8500.dtsi
index 8e87aa9..e1c3926 100644
--- a/arch/arm/boot/dts/vt8500.dtsi
+++ b/arch/arm/boot/dts/vt8500.dtsi
@@ -25,13 +25,6 @@
#interrupt-cells = <1>;
};
- gpio: gpio-controller@d811 {
- compatible = "via,vt8500-gpio";
- gpio-controller;
- reg = <0xd811 0x1>;
- #gpio-cells = <3>;
- };
-
pinctrl: pinctrl@d811 {
compatible = "via,vt8500-pinctrl";
reg = <0xd811 0x1>;
diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
index e4f768a..bb92ef8 100644
--- a/arch/arm/boot/dts/wm8505.dtsi
+++ b/arch/arm/boot/dts/wm8505.dtsi
@@ -40,13 +40,6 @@
interrupts = <56 57 58 59 60 61 62 63>;
};
- gpio: gpio-controller@d811 {
- compatible = "wm,wm8505-gpio";
- gpio-controller;
- reg = <0xd811 0x1>;
- #gpio-cells = <3>;
- };
-
pinctrl: pinctrl@d811 {
compatible = "wm,wm8505-pinctrl";
reg = <0xd811 0x1>;
diff --git a/arch/arm/boot/dts/wm8650.dtsi b/arch/arm/boot/dts/wm8650.dtsi
index 01b6a8d..bb4af58 100644
--- a/arch/arm/boot/dts/wm8650.dtsi
+++ b/arch/arm/boot/dts/wm8650.dtsi
@@ -34,13 +34,6 @@
interrupts = <56 57 58 59 60 61 62 63>;
};
- gpio: gpio-controller@d811 {
- compatible = "wm,wm8650-gpio";
- gpio-controller;
- reg = <0xd811 0x1>;
- #gpio-cells = <3>;
- };
-
pinctrl: pinctrl@d811 {
compatible = "wm,wm8650-pinctrl";
reg = <0xd811 0x1>;
diff --git a/arch/arm/boot/dts/wm8850.dtsi b/arch/arm/boot/dts/wm8850.dtsi
index 297aa05..11cd180 100644
--- a/arch/arm/boot/dts/wm8850.dtsi
+++ b/arch/arm/boot/dts/wm8850.dtsi
@@ -41,13 +41,6 @@
interrupts = <56 57 58 59 60 61 62 63>;
};
- gpio: gpio-controller@d811 {
- compatible = "wm,wm8650-gpio";
- gpio-controller;
- reg = <0xd811 0x1>;
- #gpio-cells = <3>;
- };
-
pinctrl: pinctrl@d811 {
compatible = "wm,wm8850-pinctrl";
reg = <0xd811 0x1>;
--
1.7.9.5
--
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/
[PATCHv3 0/6] arm: vt8500: Add support for pinctrl/gpio module
v3 changes: Rebased onto v3.9-rc4 Added the missing interrupt-controller info to the relevant dtsi files. Removed the gpio-vt8500.txt binding along with the gpio driver. Changes made as requested by Linux Walleij: Removed the wm,pinmux property which has caused too much confusion, and left the open-coded version in arm/arch-vt8500/vt8500.c until a proper solution is sorted out. Changes made as requested by Stephen Warren: Defined an active-low flag for gpio since its useful and we will have a use-case for it with our LCD power-on/off. v2 changes: Rebased onto v3.9-rc2 Changes made as requested by Linus Walleij: Moved the files into drivers/pinctrl/vt8500/ to keep them tidy. Changed readl/writel to *_relaxed variants. Comment indentation corrected and remove additional whitespace. Changed wmt_pctl_find_group_by_pin() error code from -1 to -EINVAL. Removed OF read indexed-u32 function to OF subsystem. General code tidy up as requested. Changes made as requested by Stephen Warren: Add binding information for interrupt generation. Move optional properties to correct location in document. This patch series removes the existing GPIO driver and replaces it with a combined pinctrl+gpio driver. Patch 1 - Add an OF function to read the nth u32 value from a property listing multiple values. Patch 2 - Increase the available GPIO space for the newly added gpios. Because there is no hardware documentation from Wondermedia we don't know how many GPIO's there actually are. New gpio pins have been located since the original GPIO driver was written, hence the increase. Patch 3 - The main pinctrl/gpio driver and the data for the 5 supported SoCs. Each SoC is different, and therefore has its own data. This design was borrowed from the Tegra pinctrl driver. The pin numbering is based on a bank+pin encoding so that when other pin functions are found later on we can add them without having to renumber existing pins. Patch 4 - Update the SoC dts(i) files to support the new pinctrl driver. Patch 5 - Remove the existing GPIO driver nodes from the dtsi's. Patch 6 - Remove the existing GPIO driver. I suspect this series may need to be broken up since there are two arm-soc patches, and 4 pinctrl/gpio patches. Patch 1 is required for the new driver to function properly. Patch 2 is independant, but required for the driver to function properly. Patches 3-4 are pinctrl/gpio patches. Patch 5-6 remove the old gpio code which is no longer required. Patch 2 could go via arm-soc if necessary. Regards Tony Prisk Tony Prisk (6): of: Add support for reading a u32 from a multi-value property. arm: vt8500: Increase available GPIOs on arch-vt8500 pinctrl: gpio: vt8500: Add pincontrol driver for arch-vt8500 arm: dts: vt8500: Update Wondermedia SoC dtsi files for pinctrl driver arm: vt8500: Remove gpio devicetree nodes gpio: vt8500: Remove arch-vt8500 gpio driver .../devicetree/bindings/gpio/gpio-vt8500.txt | 24 - .../devicetree/bindings/pinctrl/pinctrl-vt8500.txt | 57 ++ arch/arm/Kconfig |3 +- arch/arm/boot/dts/vt8500.dtsi | 10 +- arch/arm/boot/dts/wm8505.dtsi | 10 +- arch/arm/boot/dts/wm8650.dtsi | 10 +- arch/arm/boot/dts/wm8850.dtsi | 10 +- arch/arm/mach-vt8500/Kconfig |1 + drivers/gpio/Kconfig |6 - drivers/gpio/Makefile |1 - drivers/gpio/gpio-vt8500.c | 355 --- drivers/of/base.c | 33 + drivers/pinctrl/Kconfig|1 + drivers/pinctrl/Makefile |1 + drivers/pinctrl/vt8500/Kconfig | 52 ++ drivers/pinctrl/vt8500/Makefile|8 + drivers/pinctrl/vt8500/pinctrl-vt8500.c| 509 drivers/pinctrl/vt8500/pinctrl-wm8505.c| 540 + drivers/pinctrl/vt8500/pinctrl-wm8650.c| 378 drivers/pinctrl/vt8500/pinctrl-wm8750.c| 417 + drivers/pinctrl/vt8500/pinctrl-wm8850.c| 396 drivers/pinctrl/vt8500/pinctrl-wmt.c | 628 drivers/pinctrl/vt8500/pinctrl-wmt.h | 79 +++ include/linux/of.h |9 + 24 files changed, 3135 insertions(+), 403 deletions(-) delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-vt8500.txt create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt delete mode 100644 drivers/gpio/gpio-vt8500.c create mode 100644 drivers/pinctrl/vt8500/Kconfig create mode 100644 drivers/pinctrl/vt8500/Makefile create mode 100644 drivers/pinctrl/vt8500/pinctrl-vt8500.c create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8505.c cre
Re: [PATCH] gpio: palmas: add dt support
On Wednesday 27 March 2013 09:27 PM, Stephen Warren wrote: On 03/27/2013 07:00 AM, Linus Walleij wrote: On Thu, Mar 21, 2013 at 3:30 PM, Laxman Dewangan wrote: #ifdef CONFIG_OF_GPIO - palmas_gpio->gpio_chip.of_node = palmas->dev->of_node; + palmas_gpio->gpio_chip.of_node = pdev->dev.of_node; #endif OK I think that #ifdef is necessary... Laxman, Don't we need to resolve and agree on the final DT bindings before we can start making changes like this? It's not clear yet whether everyone is on the same page re: how the MFD sub-devices are modelled in DT - whether each sub-component really is a standalone device, or whether the MFD itself instantiates all its children based on internal static tables rather than DT. Yes, we need to agree on DT. I sent the patch based on the patches came from TI/Slimlogic and other discussion about DT patches. Recently, you commented on DT for palmas, it need to be completely IP based or hw based. Mix will not work. If it is IP based then almost all palmas-* file need to be rewrite, no one is written as IP based. All are using palma structures, palma header, palma macro etc which should not be there. Given that, I'm not sure why the Slimlogic people aren't CC'd on this patch:-( I have not added then on my original patch as ./script/get_maintainers.pl did not give me name. However, you added immediately them (TI and slimlogic) on this patch itself. I have not got any feedback from them yet. I -- 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 v2 1/2] PM / devfreq: Fix compiler warnings
On Wed, Mar 27, 2013 at 10:52 PM, Rajagopal Venkat
wrote:
> Fix compiler warnings generated when devfreq is not enabled
> (CONFIG_PM_DEVFREQ is not set).
>
> Signed-off-by: Rajagopal Venkat
Thanks!
Acked-by: MyungJoo Ham
> ---
> include/linux/devfreq.h | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
> index 04ad61d..5f1ab92 100644
> --- a/include/linux/devfreq.h
> +++ b/include/linux/devfreq.h
> @@ -215,7 +215,7 @@ struct devfreq_simple_ondemand_data {
> #endif
>
> #else /* !CONFIG_PM_DEVFREQ */
> -static struct devfreq *devfreq_add_device(struct device *dev,
> +static inline struct devfreq *devfreq_add_device(struct device *dev,
> struct devfreq_dev_profile *profile,
> const char *governor_name,
> void *data)
> @@ -223,34 +223,34 @@ static struct devfreq *devfreq_add_device(struct device
> *dev,
> return NULL;
> }
>
> -static int devfreq_remove_device(struct devfreq *devfreq)
> +static inline int devfreq_remove_device(struct devfreq *devfreq)
> {
> return 0;
> }
>
> -static int devfreq_suspend_device(struct devfreq *devfreq)
> +static inline int devfreq_suspend_device(struct devfreq *devfreq)
> {
> return 0;
> }
>
> -static int devfreq_resume_device(struct devfreq *devfreq)
> +static inline int devfreq_resume_device(struct devfreq *devfreq)
> {
> return 0;
> }
>
> -static struct opp *devfreq_recommended_opp(struct device *dev,
> +static inline struct opp *devfreq_recommended_opp(struct device *dev,
>unsigned long *freq, u32 flags)
> {
> - return -EINVAL;
> + return ERR_PTR(-EINVAL);
> }
>
> -static int devfreq_register_opp_notifier(struct device *dev,
> +static inline int devfreq_register_opp_notifier(struct device *dev,
> struct devfreq *devfreq)
> {
> return -EINVAL;
> }
>
> -static int devfreq_unregister_opp_notifier(struct device *dev,
> +static inline int devfreq_unregister_opp_notifier(struct device *dev,
>struct devfreq *devfreq)
> {
> return -EINVAL;
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
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] gpio: palmas: add dt support
On Wednesday 27 March 2013 06:30 PM, Linus Walleij wrote:
On Thu, Mar 21, 2013 at 3:30 PM, Laxman Dewangan wrote:
+#ifdef CONFIG_OF
+static struct of_device_id of_palmas_gpio_match[] = {
+ { .compatible = "ti,palmas-gpio"},
+ { },
+};
+MODULE_DEVICE_TABLE(of, of_palmas_gpio_match);
+#endif
But please drop the #ifdef here unless it causes compile errors
(I don't think it will.)
I am using this table as
driver.of_match_table = of_match_ptr(of_palmas_gpio_match),
of_match_ptr is macro which is NULL in case of CONFIG_OF not defined.
So if I remove ifdefs then it may create build warning as unused variable.
Therefore, I think it is require here.
--
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] include/linux: printk is needed in filter.h when CONFIG_BPF_JIT is defined
for make V=1 EXTRA_CFLAGS=-W ARCH=arm allmodconfig printk is need when CONFIG_BPF_JIT is defined or it will report pr_err and print_hex_dump are implicit declaration Signed-off-by: Chen Gang --- include/linux/filter.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/linux/filter.h b/include/linux/filter.h index d7d2508..d1248f4 100644 --- a/include/linux/filter.h +++ b/include/linux/filter.h @@ -48,6 +48,9 @@ extern int sk_chk_filter(struct sock_filter *filter, unsigned int flen); extern int sk_get_filter(struct sock *sk, struct sock_filter __user *filter, unsigned len); #ifdef CONFIG_BPF_JIT +#include +#include + extern void bpf_jit_compile(struct sk_filter *fp); extern void bpf_jit_free(struct sk_filter *fp); -- 1.7.7.6 -- 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 1/1] Input: mma8450 - fix signed 12bits to 32bits conversion
Hi Seb, On Wed, Mar 27, 2013 at 09:17:43AM +0100, seb wrote: > Event value is wrong. Should be in range -2048 to 2047, but is in range 0 to > 4095. > Use int8_t to int conversion and remove 0xfff mask. > > Signed-off-by: seb > --- > drivers/input/misc/mma8450.c | 15 ++- > 1 file changed, 10 insertions(+), 5 deletions(-) > > diff --git a/drivers/input/misc/mma8450.c b/drivers/input/misc/mma8450.c > index 480557f..c3781a1 100644 > --- a/drivers/input/misc/mma8450.c > +++ b/drivers/input/misc/mma8450.c > @@ -110,7 +110,7 @@ static void mma8450_poll(struct input_polled_dev *dev) > struct mma8450 *m = dev->private; > int x, y, z; > int ret; > - u8 buf[6]; > + int8_t buf[6]; > > ret = mma8450_read(m, MMA8450_STATUS); > if (ret < 0) > @@ -119,13 +119,18 @@ static void mma8450_poll(struct input_polled_dev *dev) > if (!(ret & MMA8450_STATUS_ZXYDR)) > return; > > - ret = mma8450_read_block(m, MMA8450_OUT_X_LSB, buf, sizeof(buf)); > + ret = mma8450_read_block(m, MMA8450_OUT_X_LSB, (u8*)buf, sizeof(buf)); > if (ret < 0) > return; > > - x = ((buf[1] << 4) & 0xff0) | (buf[0] & 0xf); > - y = ((buf[3] << 4) & 0xff0) | (buf[2] & 0xf); > - z = ((buf[5] << 4) & 0xff0) | (buf[4] & 0xf); > + /* convert 8 MSB from int8_t to int */ > + x = buf[1]; > + y = buf[3]; > + z = buf[5]; > + /* add 4 LSB */ > + x = (x << 4) | (buf[0] & 0xf); > + y = (y << 4) | (buf[2] & 0xf); > + z = (z << 4) | (buf[4] & 0xf); Should we just say: x = ((int)(s8)buf[1] << 4) | (buf[0] & 0xf); y = ... z = ... and leave the rest as is? Thanks. -- Dmitry -- 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 v4 5/6] ARM: dts: omap: update usb_otg_hs data
Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
binding in order for the driver to use the new generic PHY framework.
Also updated the Documentation to include the binding information.
The PHY binding information can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt
Signed-off-by: Kishon Vijay Abraham I
---
Documentation/devicetree/bindings/usb/omap-usb.txt |5 +
arch/arm/boot/dts/omap3.dtsi |2 ++
arch/arm/boot/dts/omap4.dtsi |2 ++
3 files changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index abce256..9324e79 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -19,6 +19,9 @@ OMAP MUSB GLUE
- power : Should be "50". This signifies the controller can supply upto
100mA when operating in host mode.
- usb-phy : the phandle for the PHY device
+ - phys : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs present in the
+ *phy* phandle.
Optional properties:
- ctrl-module : phandle of the control module this glue uses to write to
@@ -33,6 +36,8 @@ usb_otg_hs: usb_otg_hs@4a0ab000 {
num_eps = <16>;
ram_bits = <12>;
ctrl-module = <&omap_control_usb>;
+ phys = <&usb2_phy>;
+ phy-names = "usb2-phy";
};
Board specific device node entry
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1e21565..dd7d2ff 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -405,6 +405,8 @@
interrupt-names = "mc", "dma";
ti,hwmods = "usb_otg_hs";
usb-phy = <&usb2_phy>;
+ phys = <&usb2_phy>;
+ phy-names = "usb2-phy";
multipoint = <1>;
num-eps = <16>;
ram-bits = <12>;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 06d044e..b673f0f 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -550,6 +550,8 @@
interrupt-names = "mc", "dma";
ti,hwmods = "usb_otg_hs";
usb-phy = <&usb2_phy>;
+ phys = <&usb2_phy>;
+ phy-names = "usb2-phy";
multipoint = <1>;
num-eps = <16>;
ram-bits = <12>;
--
1.7.10.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 v4 0/6] Generic PHY Framework
Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. Making omap-usb2 and twl4030 to use this framework is provided as a sample. This patch series is developed on linus tree HEAD. Once the patch series gets finalised I'll resend omap-usb2 and twl4030 part based on Felipe's tree. Changes from v3: * Changed the return value of PHY APIs to ENOSYS * Added APIs of_phy_get_with_args/devm_of_phy_get_with_args to support getting PHYs if the same IP implements multiple PHYs. * modified phy_bind API so that the binding information can now be _updated_. In effect of this removed the binding information added in board files and added only in usb-musb.c. If a particular board uses a different phy binding, it can update it in board file after usb_musb_init(). * Added Documentation/devicetree/bindings/phy/phy-bindings.txt for dt binding information. Changes from v2: * removed phy_descriptor structure completely so changed the APIs which were taking phy_descriptor as parameters * Added 2 more APIs *of_phy_get_byname* and *devm_of_phy_get_byname* to be used by PHY user drivers which has *phy* and *phy-names* binding in the dt data * Fixed a few typos * Removed phy_list and we now use class_dev_iter_init, class_dev_iter_next and class_dev_iter_exit for traversing through the phy list. (Note we still need phy_bind list and phy_bind_mutex). * Changed the sysfs entry name from *bind* to *phy_bind*. Changes from v1: * Added Documentation for the PHY framework * Added few more APIs mostly w.r.t devres * Modified omap-usb2 and twl4030 to make use of the new framework Did USB enumeration testing in panda and beagle. Kishon Vijay Abraham I (6): drivers: phy: add generic PHY framework usb: phy: omap-usb2: use the new generic PHY framework usb: otg: twl4030: use the new generic PHY framework ARM: OMAP: USB: Add phy binding information ARM: dts: omap: update usb_otg_hs data usb: musb: omap2430: use the new generic PHY framework Documentation/ABI/testing/sysfs-class-phy | 15 + .../devicetree/bindings/phy/phy-bindings.txt | 76 +++ Documentation/devicetree/bindings/usb/omap-usb.txt |5 + Documentation/phy.txt | 119 MAINTAINERS|7 + arch/arm/boot/dts/omap3.dtsi |2 + arch/arm/boot/dts/omap4.dtsi |2 + arch/arm/mach-omap2/usb-musb.c |7 +- drivers/Kconfig|2 + drivers/Makefile |2 + drivers/phy/Kconfig| 13 + drivers/phy/Makefile |5 + drivers/phy/phy-core.c | 689 drivers/usb/musb/musb_core.h |2 + drivers/usb/musb/omap2430.c| 22 +- drivers/usb/otg/twl4030-usb.c | 36 + drivers/usb/phy/omap-usb2.c| 47 ++ include/linux/phy/phy.h| 237 +++ 18 files changed, 1281 insertions(+), 7 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-class-phy create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt create mode 100644 Documentation/phy.txt create mode 100644 drivers/phy/Kconfig create mode 100644 drivers/phy/Makefile create mode 100644 drivers/phy/phy-core.c create mode 100644 include/linux/phy/phy.h -- 1.7.10.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 v4 2/6] usb: phy: omap-usb2: use the new generic PHY framework
Used the generic PHY framework API to create the PHY. omap_usb2_suspend
is split into omap_usb_suspend and omap_usb_resume in order to align
with the new framework.
However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break OTG. Once we have a separate OTG state machine, we
can get rid of the USB PHY library.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/phy/omap-usb2.c | 47 +++
1 file changed, 47 insertions(+)
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index 844ab68..819ba71 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
/**
* omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -119,9 +120,48 @@ static int omap_usb2_suspend(struct usb_phy *x, int
suspend)
return 0;
}
+static int omap_usb_suspend(struct phy *x)
+{
+ struct omap_usb *phy = dev_get_drvdata(&x->dev);
+
+ if (!phy->is_suspended) {
+ omap_control_usb_phy_power(phy->control_dev, 0);
+ pm_runtime_put_sync(phy->dev);
+ phy->is_suspended = 1;
+ }
+
+ return 0;
+}
+
+static int omap_usb_resume(struct phy *x)
+{
+ u32 ret;
+ struct omap_usb *phy = dev_get_drvdata(&x->dev);
+
+ if (phy->is_suspended) {
+ ret = pm_runtime_get_sync(phy->dev);
+ if (ret < 0) {
+ dev_err(phy->dev, "get_sync failed with err %d\n",
+ ret);
+ return ret;
+ }
+ omap_control_usb_phy_power(phy->control_dev, 1);
+ phy->is_suspended = 0;
+ }
+
+ return 0;
+}
+
+static struct phy_ops ops = {
+ .suspend= omap_usb_suspend,
+ .resume = omap_usb_resume,
+ .owner = THIS_MODULE,
+};
+
static int omap_usb2_probe(struct platform_device *pdev)
{
struct omap_usb *phy;
+ struct phy *generic_phy;
struct usb_otg *otg;
phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
@@ -144,6 +184,13 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy->phy.otg= otg;
phy->phy.type = USB_PHY_TYPE_USB2;
+ generic_phy = devm_phy_create(phy->dev, "omap-usb2", pdev->dev.of_node,
+ USB_PHY_TYPE_USB2, &ops, phy);
+ if (IS_ERR(generic_phy)) {
+ dev_dbg(&pdev->dev, "Failed to create PHY\n");
+ return PTR_ERR(generic_phy);
+ }
+
phy->control_dev = omap_get_control_dev();
if (IS_ERR(phy->control_dev)) {
dev_dbg(&pdev->dev, "Failed to get control device\n");
--
1.7.10.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 v4 3/6] usb: otg: twl4030: use the new generic PHY framework
Used the generic PHY framework API to create the PHY. twl4030_usb_suspend
and twl4030_usb_resume is added to phy_ops in order to align
with the new framework.
However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new
framework completely will break OTG. Once we have a separate OTG state machine,
we can get rid of the USB PHY library.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/otg/twl4030-usb.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index a994715..aebcd6a 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -575,10 +576,38 @@ static int twl4030_set_host(struct usb_otg *otg, struct
usb_bus *host)
return 0;
}
+static int twl4030_usb_suspend(struct phy *phy)
+{
+ struct twl4030_usb *twl = dev_get_drvdata(&phy->dev);
+
+ twl4030_phy_suspend(twl, 1);
+
+ return 0;
+}
+
+static int twl4030_usb_resume(struct phy *phy)
+{
+ struct twl4030_usb *twl = dev_get_drvdata(&phy->dev);
+
+ if (!twl->asleep)
+ return -EBUSY;
+ __twl4030_phy_resume(twl);
+ twl->asleep = 0;
+
+ return 0;
+}
+
+static struct phy_ops ops = {
+ .suspend= twl4030_usb_suspend,
+ .resume = twl4030_usb_resume,
+ .owner = THIS_MODULE,
+};
+
static int twl4030_usb_probe(struct platform_device *pdev)
{
struct twl4030_usb_data *pdata = pdev->dev.platform_data;
struct twl4030_usb *twl;
+ struct phy *phy;
int status, err;
struct usb_otg *otg;
struct device_node *np = pdev->dev.of_node;
@@ -617,6 +646,13 @@ static int twl4030_usb_probe(struct platform_device *pdev)
otg->set_host = twl4030_set_host;
otg->set_peripheral = twl4030_set_peripheral;
+ phy = devm_phy_create(twl->dev, "twl4030", pdev->dev.of_node,
+ USB_PHY_TYPE_USB2, &ops, twl);
+ if (IS_ERR(phy)) {
+ dev_dbg(&pdev->dev, "Failed to create PHY\n");
+ return PTR_ERR(phy);
+ }
+
/* init spinlock for workqueue */
spin_lock_init(&twl->lock);
--
1.7.10.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 v4 4/6] ARM: OMAP: USB: Add phy binding information
In order for controllers to get PHY in case of non dt boot, the phy
binding information should be added in the platform specific
initialization code using phy_bind.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/mach-omap2/usb-musb.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 3242a55..f01bc42 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "omap_device.h"
#include "soc.h"
@@ -85,8 +86,12 @@ void __init usb_musb_init(struct omap_musb_board_data
*musb_board_data)
musb_plat.mode = board_data->mode;
musb_plat.extvbus = board_data->extvbus;
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx()) {
musb_plat.has_mailbox = true;
+ phy_bind("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
+ } else if (cpu_is_omap34xx()) {
+ phy_bind("musb-hdrc.0.auto", 0, "twl4030_usb");
+ }
if (soc_is_am35xx()) {
oh_name = "am35x_otg_hs";
--
1.7.10.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 v4 1/6] drivers: phy: add generic PHY framework
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. To obtain a reference to the PHY without
using phandle, the platform specfic intialization code (say from board file)
should have already called phy_bind with the binding information. The binding
information consists of phy's device name, phy user device name and an index.
The index is used when the same phy user binds to mulitple phys.
PHY drivers should create the PHY by passing phy_descriptor that has
describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
poweron, shutdown.
The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for the sysfs entry is added
in Documentation/ABI/testing/sysfs-class-phy and the documentation for
dt binding is can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt
Signed-off-by: Kishon Vijay Abraham I
---
Documentation/ABI/testing/sysfs-class-phy | 15 +
.../devicetree/bindings/phy/phy-bindings.txt | 76 +++
Documentation/phy.txt | 119
MAINTAINERS|7 +
drivers/Kconfig|2 +
drivers/Makefile |2 +
drivers/phy/Kconfig| 13 +
drivers/phy/Makefile |5 +
drivers/phy/phy-core.c | 689
include/linux/phy/phy.h| 237 +++
10 files changed, 1165 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-phy
create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
create mode 100644 Documentation/phy.txt
create mode 100644 drivers/phy/Kconfig
create mode 100644 drivers/phy/Makefile
create mode 100644 drivers/phy/phy-core.c
create mode 100644 include/linux/phy/phy.h
diff --git a/Documentation/ABI/testing/sysfs-class-phy
b/Documentation/ABI/testing/sysfs-class-phy
new file mode 100644
index 000..47f17c9
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-phy
@@ -0,0 +1,15 @@
+What: /sys/class/phy//label
+Date: Feb 2013
+KernelVersion: 3.10
+Contact: Kishon Vijay Abraham I
+Description:
+ This is a read-only file for getting the label of the phy.
+
+What: /sys/class/phy//phy_bind
+Date: Feb 2013
+KernelVersion: 3.10
+Contact: Kishon Vijay Abraham I
+Description:
+ This is a read-only file for reading the phy binding
+ information. It contains the device name of the controller,
+ the index and the device name of the PHY in that order.
diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt
b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 000..35696b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,76 @@
+This document explains only the dt data binding. For general information about
+PHY subsystem refer Documentation/phy.txt
+
+PHY device node
+===
+
+Optional Properties:
+#phy-cells:Number of cells in a PHY specifier; The meaning of all those
+ cells is defined by the binding for the phy node. However
+ in-order to return the correct PHY, the PHY susbsystem
+ requires the first cell always refers to the port.
+
+This property is optional because it is needed only for the case where a
+single IP implements multiple PHYs.
+
+For example:
+
+phys: phy {
+compatible = "xxx";
+reg1 = <...>;
+reg2 = <...>;
+reg3 = <...>;
+.
+.
+#phy-cells = <1>;
+.
+.
+};
+
+That node describes an IP block that implements 3 different PHYs. In order to
+differentiate between these 3 PHYs, an additonal specifier should be given
+while trying to get a reference to it. (The PHY subsystem assumes the
+specifier is port id).
+
+PHY user node
+=
+
+Required Properties:
+phys : the phandle for the PHY device (used by the PHY subsystem)
+
+Optional properties:
+phy-names : the names of the PHY corresponding to the PHYs present in the
+ *phys* phandle
+
+example1:
+phys: phy {
+compatible = "xxx";
+reg = <...>;
+.
+.
+phys = <&usb2_phy>, <&usb3_phy>;
+phy-names = "usb2phy", "usb3phy";
+.
+.
+};
+This node represents a controller that uses two PHYs one for usb2 and one for
+usb3. The controller driver can get the appropriate PHY either by using
+devm_of_phy_get/of_phy_get by passing the correct index or by using
+of_phy_get_byname/devm_of_phy_get_byname by passing the names given in
+*phy-names*.
+
+example2:
+phys: phy {
+compatible = "xxx";
+reg = <...>;
+.
+.
+phys = <&phys 1>;
+.
+.
+};
+
+This node represents a control
[PATCH v4 6/6] usb: musb: omap2430: use the new generic PHY framework
Use the generic PHY framework API to get the PHY. The usb_phy_set_suspend
and usb_phy_set_resume is replaced with phy_suspend and phy_resume to
align with the new PHY framework.
musb->xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state machine to handle otg, these can be
moved out of xceiv and then we can start using the generic PHY framework.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/musb/musb_core.h |2 ++
drivers/usb/musb/omap2430.c | 22 --
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7fb4819..78251fd 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -46,6 +46,7 @@
#include
#include
#include
+#include
struct musb;
struct musb_hw_ep;
@@ -357,6 +358,7 @@ struct musb {
u16 int_tx;
struct usb_phy *xceiv;
+ struct phy *phy;
int nIrq;
unsignedirq_wake:1;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 1a42a45..55f071d 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -349,14 +349,24 @@ static int omap2430_musb_init(struct musb *musb)
* up through ULPI. TWL4030-family PMICs include one,
* which needs a driver, drivers aren't always needed.
*/
- if (dev->parent->of_node)
+ if (dev->parent->of_node) {
+ musb->phy = devm_of_phy_get_byname(dev->parent, "usb2-phy");
+
+ /* We can't totally remove musb->xceiv as of now because
+* musb core uses xceiv.state and xceiv.otg. Once we have
+* a separate state machine to handle otg, these can be moved
+* out of xceiv and then we can start using the generic PHY
+* framework
+*/
musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
"usb-phy", 0);
- else
+ } else {
musb->xceiv = devm_usb_get_phy_dev(dev, 0);
+ musb->phy = devm_phy_get(dev, 0);
+ }
- if (IS_ERR_OR_NULL(musb->xceiv)) {
- pr_err("HS USB OTG: no transceiver configured\n");
+ if (IS_ERR_OR_NULL(musb->xceiv) || IS_ERR_OR_NULL(musb->phy)) {
+ dev_err(dev, "no transceiver configured\n");
return -EPROBE_DEFER;
}
@@ -612,7 +622,7 @@ static int omap2430_runtime_suspend(struct device *dev)
OTG_INTERFSEL);
omap2430_low_level_exit(musb);
- usb_phy_set_suspend(musb->xceiv, 1);
+ phy_suspend(musb->phy);
}
return 0;
@@ -628,7 +638,7 @@ static int omap2430_runtime_resume(struct device *dev)
musb_writel(musb->mregs, OTG_INTERFSEL,
musb->context.otg_interfsel);
- usb_phy_set_suspend(musb->xceiv, 0);
+ phy_resume(musb->phy);
}
return 0;
--
1.7.10.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/
Re: Generic syscall ABI support
On 03/27/2013 08:09 PM, Ley Foon Tan wrote: > Need advise regarding the generic syscall ABI support. > > We are planning to upstream our Nios II kernel (arch/nios2) to mainline. > But it doesn't support generic syscall ABI yet (It requires an updated > Glibc port as well). > > The question is, is it a requirement for new arch to support generic > syscall ABI when upstreaming? Can we upstream a non-generic syscall ABI > first and migrate to generic syscall ABI in future? > Thanks. > > Regards > LFTAN > That would be extremely difficult. In general, you should use the generic ABI for a new port unless you have *very* strong and convincing reasons not to. Given how long the Nios2 port has been in upstreaming (unfortunate, I like to play with FPGAs ;) it seems worthwhile to adjust it before pushing it. -hpa -- 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] Input: trackpoint - Optimize trackpoint init to use power-on reset
Hi Shawn,
On Tue, Mar 26, 2013 at 12:36:41PM -0700, Shawn Nematbakhsh wrote:
> The trackpoint driver sets various parameter default values, all of
> which happen to be power-on defaults (Source: IBM TrackPoint Engineering
> Specification, Version 4.0. Also confirmed by empirical data).
>
> By sending the power-on reset command to reset all parameters to
> power-on state, we can skip the lengthy process of programming all
> parameters. In testing, ~2.5 secs of time writing parameters was reduced
> to .35 seconds waiting for power-on reset to complete.
>
> Signed-off-by: Shawn Nematbakhsh
> ---
> drivers/input/mouse/trackpoint.c | 223
> +--
> drivers/input/mouse/trackpoint.h | 7 +-
> 2 files changed, 149 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/input/mouse/trackpoint.c
> b/drivers/input/mouse/trackpoint.c
> index f310249..17e9b36 100644
> --- a/drivers/input/mouse/trackpoint.c
> +++ b/drivers/input/mouse/trackpoint.c
> @@ -20,6 +20,26 @@
> #include "trackpoint.h"
>
> /*
> + * Power-on Reset: Resets all trackpoint parameters, including RAM values,
> + * to defaults.
> + * Returns zero on success, non-zero on failure.
> + */
> +static int trackpoint_power_on_reset(struct ps2dev *ps2dev)
> +{
> + unsigned char results[2];
> +
> + if (ps2_command(ps2dev, NULL, MAKE_PS2_CMD(0, 0, TP_COMMAND)) ||
> + ps2_command(ps2dev, results, MAKE_PS2_CMD(0, 2, TP_POR))) {
> + return -1;
> + }
> +
> + /* POR response should be 0xAA00 or 0xFC00 */
> + if ((results[0] != 0xAA && results[0] != 0xFC) || results[1] != 0x00)
> + return -1;
I am a bit concerned about this. 0xfc00 indicates POR failure. In this
case shouldn't we try to reset the device, issue another POR and bail if
it fails again?
>
> static struct attribute *trackpoint_attrs[] = {
> &psmouse_attr_sensitivity.dattr.attr,
> @@ -179,6 +241,9 @@ static struct attribute *trackpoint_attrs[] = {
> &psmouse_attr_press_to_select.dattr.attr,
> &psmouse_attr_skipback.dattr.attr,
> &psmouse_attr_ext_dev.dattr.attr,
> + &psmouse_attr_twohand.dattr.attr,
> + &psmouse_attr_source_tag.dattr.attr,
> + &psmouse_attr_mb.dattr.attr,
What is the benefit of adding these 3 new attributes?
Thanks.
--
Dmitry
--
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] arm: omap: RX-51: ARM errata 430973 workaround
Tony, Who do you expect to make that code merge? Do you expect us to mechanically merge RX51 PPA API patch with the existing generic OMAP PPA API code putting #ifdefs all over the place? Not that it is impossible, but the only real piece of HW I have here is n900, so I just can't be sure the code will still work on the other platforms besides RX51, once the code modified. Please, advice on how to proceed. Regards, Ivo > Оригинално писмо >От: Tony Lindgren >Относно: Re: [PATCH] arm: omap: RX-51: ARM errata 430973 workaround >До: Pali Rohár >Изпратено на: Сряда, 2013, Март 27 23:12:09 EET > > >* Pali Rohár [130327 14:09]: >> On Wednesday 27 March 2013 21:56:07 Tony Lindgren wrote: >> > * Pali Rohár [130324 07:31]: >> > > it is possible to upstream errata 430973 workaround for >> > > RX-51? >> > >> > I think we should make the SMC handling a generic function for >> > ARM. >> > >> > AFAIK just the SMC call numbering is different for various >> > implementations. So the handler and passing of the parameters >> > seems like it should be generic. >> > >> >> Not only, look at freemangordon's email: >> https://lkml.org/lkml/2013/3/1/62 > >Seem like you may need some SoC specific wrapper to the >generic function to deal with the params. But still seems >like we can have an ARM generic smc funtion. > >Regards, > >Tony > -- 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/
linux-next: Tree for Mar 28
Hi all, The next linux-next release will be on Tuesday April 2. Changes since 20130327: The vl4-dvb tree still had its build failure for which I disabled a staging driver. The hid tree gained a conflict against Linus' tree. The net-next tree gained a build failure for which I reverted a commit. The block tree still had its build failure for which I applied a patch. The usb tree gained a build failure for which I reverted a commit. The signal tree gained a conflict against Linus' tree. The akpm tree lost a patch that turned up elsewhere. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 222 trees (counting Linus' and 31 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (9064171 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes) Merging fixes/master (9064171 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes) Merging kbuild-current/rc-fixes (6dbe51c Linux 3.9-rc1) Merging arc-current/for-curr (367f3fc ARC: Fix the typo in event identifier flags used by ptrace) Merging arm-current/fixes (68a154f ARM: 7681/1: hw_breakpoint: use warn_once to avoid spam from reset_ctrl_regs()) Merging m68k-current/for-linus (5618395 m68k: Sort out !CONFIG_MMU_SUN3 vs. CONFIG_HAS_DMA) Merging powerpc-merge/merge (af81d78 powerpc: Rename USER_ESID_BITS* to ESID_BITS*) Merging sparc/master (53b6809 Merge tag 'rdma-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband) Merging net/master (30de83a Merge branch 'fixes-for-3.9' of git://gitorious.org/linux-can/linux-can) Merging ipsec/master (799ef90 xfrm: Fix esn sequence number diff calculation in xfrm_replay_notify_esn()) Merging sound-current/for-linus (55a63d4 ALSA: hda - Fix DAC assignment for independent HP) Merging pci-current/for-linus (249bfb8 PCI/PM: Clean up PME state when removing a device) Merging wireless/master (2e1253d b43: N-PHY: use more bits for offset in RSSI calibration) Merging driver-core.current/driver-core-linus (e5110f4 sysfs: handle failure path correctly for readdir()) Merging tty.current/tty-linus (855f6fd Xilinx: ARM: UART: clear pending irqs before enabling irqs) Merging usb.current/usb-linus (c8fa48d usb: Fix compile error by selecting USB_OTG_UTILS) Merging staging.current/staging-linus (e4317ce8 staging: comedi: s626: fix continuous acquisition) Merging char-misc.current/char-misc-linus (347e089 VMCI: Fix process-to-process DRGAMs.) Merging input-current/for-linus (4b7d293 Input: mms114 - Fix regulator enable and disable paths) Merging md-current/for-linus (238f590 md: remove CONFIG_MULTICORE_RAID456 entirely) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (246bbed Revert "crypto: caam - add IPsec ESN support") Merging ide/master (bf6b438 ide: gayle: use module_platform_driver_probe()) Merging dwmw2/master (63662139 params: Fix potential memory leak in add_sysfs_param()) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline
Re: linux-next: build failure after merge of the final tree (net-next tree related)
From: Stephen Rothwell
Date: Thu, 28 Mar 2013 16:04:20 +1100
> Hi all,
>
> After merging the final tree, today's linux-next build (powerpc
> ppc44x_defconfig) failed like this:
>
> net/packet/af_packet.c: In function 'packet_sendmsg_spkt':
> net/packet/af_packet.c:1515:2: error: implicit declaration of function
> 'skb_probe_transport_header' [-Werror=implicit-function-declaration]
> drivers/net/tun.c: In function 'tun_get_user':
> drivers/net/tun.c:1206:2: error: implicit declaration of function
> 'skb_probe_transport_header' [-Werror=implicit-function-declaration]
>
> Caused by commit 40893fd0fd4e ("net: switch to use
> skb_probe_transport_header()"). This is a 32 bit build, so that
> "BITS_PER_LONG > 32" is false and so NET_SKBUFF_DATA_USES_OFFSET is not
> defined ... and skb_probe_transport_header() is only defined in an area of
> skbuff.h protected by "#ifdef NET_SKBUFF_DATA_USES_OFFSET" :-(
>
> I have reverted that commit for today.
This got fixed about an hour ago :-)
--
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] pinctrl: bcm2835: make use of of_property_read_u32_index()
Use the new standard API of_property_read_u32_index() instead of open-
coding it.
Signed-off-by: Stephen Warren
---
Note: This depends on the proposed patch "of: Add support for reading
a u32 from a multi-value property" by Tony Prisk.
BTW, I realized why I didn't create that standard API, but wrote custom
prop_u32() instead; the code has already looked up the properties, and
validated their length, so prop_u32() can simply index into the property
data, whereas of_property_read_u32_index() needs to go search for the
property and re-validate it every time, so there's a bunch more overhead.
It also means duplicating the property name, although I could use a
define for that. I'm not entirely convinced that using this standard API
is a win in this case. LinusW, Tony, what do you think?
---
drivers/pinctrl/pinctrl-bcm2835.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-bcm2835.c
b/drivers/pinctrl/pinctrl-bcm2835.c
index f28d4b0..c8f20a3 100644
--- a/drivers/pinctrl/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/pinctrl-bcm2835.c
@@ -699,11 +699,6 @@ static int bcm2835_pctl_dt_node_to_map_pull(struct
bcm2835_pinctrl *pc,
return 0;
}
-static inline u32 prop_u32(struct property *p, int i)
-{
- return be32_to_cpup(((__be32 *)p->value) + i);
-}
-
static int bcm2835_pctl_dt_node_to_map(struct pinctrl_dev *pctldev,
struct device_node *np,
struct pinctrl_map **map, unsigned *num_maps)
@@ -761,7 +756,9 @@ static int bcm2835_pctl_dt_node_to_map(struct pinctrl_dev
*pctldev,
return -ENOMEM;
for (i = 0; i < num_pins; i++) {
- pin = prop_u32(pins, i);
+ err = of_property_read_u32_index(np, "brcm,pins", i, &pin);
+ if (err)
+ goto out;
if (pin >= ARRAY_SIZE(bcm2835_gpio_pins)) {
dev_err(pc->dev, "%s: invalid brcm,pins value %d\n",
of_node_full_name(np), pin);
@@ -770,14 +767,20 @@ static int bcm2835_pctl_dt_node_to_map(struct pinctrl_dev
*pctldev,
}
if (num_funcs) {
- func = prop_u32(funcs, (num_funcs > 1) ? i : 0);
+ err = of_property_read_u32_index(np, "brcm,function",
+ (num_funcs > 1) ? i : 0, &func);
+ if (err)
+ goto out;
err = bcm2835_pctl_dt_node_to_map_func(pc, np, pin,
func, &cur_map);
if (err)
goto out;
}
if (num_pulls) {
- pull = prop_u32(pulls, (num_pulls > 1) ? i : 0);
+ err = of_property_read_u32_index(np, "brcm,pull",
+ (num_funcs > 1) ? i : 0, &pull);
+ if (err)
+ goto out;
err = bcm2835_pctl_dt_node_to_map_pull(pc, np, pin,
pull, &cur_map);
if (err)
--
1.7.10.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/
linux-next: build failure after merge of the final tree (net-next tree related)
Hi all,
After merging the final tree, today's linux-next build (powerpc
ppc44x_defconfig) failed like this:
net/packet/af_packet.c: In function 'packet_sendmsg_spkt':
net/packet/af_packet.c:1515:2: error: implicit declaration of function
'skb_probe_transport_header' [-Werror=implicit-function-declaration]
drivers/net/tun.c: In function 'tun_get_user':
drivers/net/tun.c:1206:2: error: implicit declaration of function
'skb_probe_transport_header' [-Werror=implicit-function-declaration]
Caused by commit 40893fd0fd4e ("net: switch to use
skb_probe_transport_header()"). This is a 32 bit build, so that
"BITS_PER_LONG > 32" is false and so NET_SKBUFF_DATA_USES_OFFSET is not
defined ... and skb_probe_transport_header() is only defined in an area of
skbuff.h protected by "#ifdef NET_SKBUFF_DATA_USES_OFFSET" :-(
I have reverted that commit for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp5E6pZjGGBR.pgp
Description: PGP signature
Re: [PATCH 6/6] video: fb: vt8500: Convert framebuffer drivers to standardized binding
On Wed, 2013-03-27 at 13:10 +0200, Tomi Valkeinen wrote:
> Hi,
>
> On 2013-03-27 10:47, Tony Prisk wrote:
> > Now that a display timing binding is available, convert our almost identical
> > binding to use the standard binding.
> >
> > This patch converts the vt8500 and wm8505 framebuffer drivers and
> > associated dts/dtsi files to use the standard binding as defined in
> > bindings/video/display-timing.txt.
> >
> > There are two side-effects of making this conversion:
> >
> > 1) The fb node should now be in the board file, rather than the soc file as
> > the display-timing node is a child of the fb node.
> >
> > 2) We still require a bits per pixel property to initialize the framebuffer
> > for the different lcd panels. Rather than including this as part of the
> > display timing, it is moved into the framebuffer node.
> >
> > I have also taken the opportunity to alphabetise the includes of each
> > driver to avoid double-ups.
>
> I don't think this is correct. I don't have that much experience with
> DT, but I think you should have, for example:
>
> wm8850.dtsi:
>
> fb: fb@d8051700 {
> compatible = "wm,wm8505-fb";
> reg = <0xd8051700 0x200>;
> };
>
> wm8850-w70v2.dts:
>
> &fb {
> bits-per-pixel = <16>;
>
> display-timings {
> native-mode = <&timing0>;
> timing0: 800x480 {
> clock-frequency = <0>;
> ...
> };
> };
> };
>
> So, the core fb part should be in the SoC's file, as it's part of the
> SoC. And the stuff that tells what kind of display is attached is in the
> board dts file.
>
> Also, just a word of warning, I think the videomode series I've sent for
> review will cause some breakage with this series if the videomode series
> is accepted. Nothing difficult to fix, though, but we'll need some extra
> management to avoid compilation failures.
>
> Tomi
>
>
Thanks for the feedback and the heads-up.
I believe you are correct about the DT info - it looks right when
described the way you did, so I have changed it.
If there is no other feedback, I will post a version 2 after Easter.
Regards
Tony P
--
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: [Bulk] [PATCH] video: fix invalid free of devm_ allocated data
On Thu, 2013-03-28 at 01:55 +0200, Andrei Epure wrote: > The objects allocated by devm_* APIs are managed by devres and are freed when > the device is detached. Hence there is no need to use kfree() explicitly. > Patch found using coccinelle. > > Signed-off-by: Andrei Epure > --- > drivers/video/vt8500lcdfb.c |3 --- > drivers/video/wm8505fb.c|3 --- > 2 files changed, 6 deletions(-) > > diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c > index b4ccca2..ea3ee61 100644 > --- a/drivers/video/vt8500lcdfb.c > +++ b/drivers/video/vt8500lcdfb.c > @@ -465,7 +465,6 @@ failed_free_res: > release_mem_region(res->start, resource_size(res)); > failed_fbi: > platform_set_drvdata(pdev, NULL); > - kfree(fbi); > failed: > return ret; > } > @@ -494,8 +493,6 @@ static int vt8500lcd_remove(struct platform_device *pdev) > res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > release_mem_region(res->start, resource_size(res)); > > - kfree(fbi); > - > return 0; > } > > diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c > index 2e8298e..34a2de1 100644 > --- a/drivers/video/wm8505fb.c > +++ b/drivers/video/wm8505fb.c > @@ -427,7 +427,6 @@ failed_free_res: > release_mem_region(res->start, resource_size(res)); > failed_fbi: > platform_set_drvdata(pdev, NULL); > - kfree(fbi); > failed: > return ret; > } > @@ -451,8 +450,6 @@ static int wm8505fb_remove(struct platform_device *pdev) > res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > release_mem_region(res->start, resource_size(res)); > > - kfree(fbi); > - > return 0; > } > NACK Already have a patch queued up for this from Julia Lawall Regards Tony P -- 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] video: fixed missing iounmap coccinelle errors
On Thu, 2013-03-28 at 01:43 +0200, Andrei Epure wrote:
> Modified or added the necessary goto statements so that the ioremapped
> regions get unmapped before return.
>
> Signed-off-by: Andrei Epure
> ---
> drivers/video/vt8500lcdfb.c |7 ---
> drivers/video/wm8505fb.c|7 ---
> 2 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
> index aa2579c..b4ccca2 100644
> --- a/drivers/video/vt8500lcdfb.c
> +++ b/drivers/video/vt8500lcdfb.c
> @@ -350,7 +350,7 @@ static int vt8500lcd_probe(struct platform_device *pdev)
> if (!np) {
> pr_err("%s: No display description in Device Tree\n", __func__);
> ret = -EINVAL;
> - goto failed_free_res;
> + goto failed_free_io;
> }
>
> /*
> @@ -369,7 +369,7 @@ static int vt8500lcd_probe(struct platform_device *pdev)
> ret |= of_property_read_u32(np, "bpp", &bpp);
> if (ret) {
> pr_err("%s: Unable to read display properties\n", __func__);
> - goto failed_free_res;
> + goto failed_free_io;
> }
> of_mode.vmode = FB_VMODE_NONINTERLACED;
>
> @@ -379,7 +379,8 @@ static int vt8500lcd_probe(struct platform_device *pdev)
> GFP_KERNEL);
> if (!fb_mem_virt) {
> pr_err("%s: Failed to allocate framebuffer\n", __func__);
> - return -ENOMEM;
> + ret = -ENOMEM;
> + goto failed_free_io;
> };
>
> fbi->fb.fix.smem_start = fb_mem_phys;
> diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
> index 4dd0580..2e8298e 100644
> --- a/drivers/video/wm8505fb.c
> +++ b/drivers/video/wm8505fb.c
> @@ -332,7 +332,7 @@ static int wm8505fb_probe(struct platform_device *pdev)
> if (!np) {
> pr_err("%s: No display description in Device Tree\n", __func__);
> ret = -EINVAL;
> - goto failed_free_res;
> + goto failed_free_io;
> }
>
> /*
> @@ -351,7 +351,7 @@ static int wm8505fb_probe(struct platform_device *pdev)
> ret |= of_property_read_u32(np, "bpp", &bpp);
> if (ret) {
> pr_err("%s: Unable to read display properties\n", __func__);
> - goto failed_free_res;
> + goto failed_free_io;
> }
>
> of_mode.vmode = FB_VMODE_NONINTERLACED;
> @@ -369,7 +369,8 @@ static int wm8505fb_probe(struct platform_device *pdev)
> GFP_KERNEL);
> if (!fb_mem_virt) {
> pr_err("%s: Failed to allocate framebuffer\n", __func__);
> - return -ENOMEM;
> + ret = -ENOMEM;
> + goto failed_free_io;
> };
>
> fbi->fb.var.xres_virtual= of_mode.xres;
NACK
Already have a patch queued up for this from Julia Lawall
Regards
Tony P
--
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/2] clk: allow reentrant calls into the clk framework
Reentrancy into the clock framework is necessary for clock operations
that result in nested calls to the clk api. A common example is a clock
that is prepared via an i2c transaction, such as a clock inside of a
discrete audio chip or a power management IC. The i2c subsystem itself
will use the clk api resulting in a deadlock:
clk_prepare(audio_clk)
i2c_transfer(..)
clk_prepare(i2c_controller_clk)
The ability to reenter the clock framework prevents this deadlock.
Other use cases exist such as allowing .set_rate callbacks to call
clk_set_parent to achieve the best rate, or to save power in certain
configurations. Yet another example is performing pinctrl operations
from a clk_ops callback. Calls into the pinctrl subsystem may call
clk_{un}prepare on an unrelated clock. Allowing for nested calls to
reenter the clock framework enables both of these use cases.
Reentrancy is implemented by two global pointers that track the owner
currently holding a global lock. One pointer tracks the owner during
sleepable, mutex-protected operations and the other one tracks the owner
during non-interruptible, spinlock-protected operations.
When the clk framework is entered we try to hold the global lock. If it
is held we compare the current task id against the current owner; a
match implies a nested call and we reenter. If the values do not match
then we block on the lock until it is released.
Signed-off-by: Mike Turquette
Cc: Rajagopal Venkat
Cc: David Brown
Cc: Ulf Hansson
Cc: Laurent Pinchart
Cc: Thomas Gleixner
---
Changes since v4:
* remove uneccesary atomic operations
* remove casting bugs
* place reentrancy logic into locking helper functions
* improve debugging with reference counting and WARNs
drivers/clk/clk.c | 43 +--
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index bea47d5..fe7c054 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -19,10 +19,17 @@
#include
#include
#include
+#include
static DEFINE_SPINLOCK(enable_lock);
static DEFINE_MUTEX(prepare_lock);
+static struct task_struct *prepare_owner;
+static struct task_struct *enable_owner;
+
+static int prepare_refcnt;
+static int enable_refcnt;
+
static HLIST_HEAD(clk_root_list);
static HLIST_HEAD(clk_orphan_list);
static LIST_HEAD(clk_notifier_list);
@@ -30,21 +37,53 @@ static LIST_HEAD(clk_notifier_list);
/*** locking ***/
static void clk_prepare_lock(void)
{
- mutex_lock(&prepare_lock);
+ if (!mutex_trylock(&prepare_lock)) {
+ if (prepare_owner == current) {
+ prepare_refcnt++;
+ return;
+ }
+ mutex_lock(&prepare_lock);
+ }
+ WARN_ON_ONCE(prepare_owner != NULL);
+ WARN_ON_ONCE(prepare_refcnt != 0);
+ prepare_owner = current;
+ prepare_refcnt = 1;
}
static void clk_prepare_unlock(void)
{
+ WARN_ON_ONCE(prepare_owner != current);
+ WARN_ON_ONCE(prepare_refcnt == 0);
+
+ if (--prepare_refcnt)
+ return;
+ prepare_owner = NULL;
mutex_unlock(&prepare_lock);
}
static void clk_enable_lock(unsigned long *flags)
{
- spin_lock_irqsave(&enable_lock, *flags);
+ if (!spin_trylock_irqsave(&enable_lock, *flags)) {
+ if (enable_owner == current) {
+ enable_refcnt++;
+ return;
+ }
+ spin_lock_irqsave(&enable_lock, *flags);
+ }
+ WARN_ON_ONCE(enable_owner != NULL);
+ WARN_ON_ONCE(enable_refcnt != 0);
+ enable_owner = current;
+ enable_refcnt = 1;
}
static void clk_enable_unlock(unsigned long *flags)
{
+ WARN_ON_ONCE(enable_owner != current);
+ WARN_ON_ONCE(enable_refcnt == 0);
+
+ if (--enable_refcnt)
+ return;
+ enable_owner = NULL;
spin_unlock_irqrestore(&enable_lock, *flags);
}
--
1.7.10.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 1/2] clk: abstract locking out into helper functions
Create locking helpers for the global mutex and global spinlock. The
definitions of these helpers will be expanded upon in the next patch
which introduces reentrancy into the locking scheme.
Signed-off-by: Mike Turquette
Cc: Rajagopal Venkat
Cc: David Brown
Cc: Ulf Hansson
Cc: Laurent Pinchart
Cc: Thomas Gleixner
---
drivers/clk/clk.c | 97 -
1 file changed, 59 insertions(+), 38 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 5e8..bea47d5 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -27,6 +27,27 @@ static HLIST_HEAD(clk_root_list);
static HLIST_HEAD(clk_orphan_list);
static LIST_HEAD(clk_notifier_list);
+/*** locking ***/
+static void clk_prepare_lock(void)
+{
+ mutex_lock(&prepare_lock);
+}
+
+static void clk_prepare_unlock(void)
+{
+ mutex_unlock(&prepare_lock);
+}
+
+static void clk_enable_lock(unsigned long *flags)
+{
+ spin_lock_irqsave(&enable_lock, *flags);
+}
+
+static void clk_enable_unlock(unsigned long *flags)
+{
+ spin_unlock_irqrestore(&enable_lock, *flags);
+}
+
/***debugfs support***/
#ifdef CONFIG_COMMON_CLK_DEBUG
@@ -69,7 +90,7 @@ static int clk_summary_show(struct seq_file *s, void *data)
seq_printf(s, " clockenable_cnt prepare_cnt
rate\n");
seq_printf(s,
"-\n");
- mutex_lock(&prepare_lock);
+ clk_prepare_lock();
hlist_for_each_entry(c, &clk_root_list, child_node)
clk_summary_show_subtree(s, c, 0);
@@ -77,7 +98,7 @@ static int clk_summary_show(struct seq_file *s, void *data)
hlist_for_each_entry(c, &clk_orphan_list, child_node)
clk_summary_show_subtree(s, c, 0);
- mutex_unlock(&prepare_lock);
+ clk_prepare_unlock();
return 0;
}
@@ -130,7 +151,7 @@ static int clk_dump(struct seq_file *s, void *data)
seq_printf(s, "{");
- mutex_lock(&prepare_lock);
+ clk_prepare_lock();
hlist_for_each_entry(c, &clk_root_list, child_node) {
if (!first_node)
@@ -144,7 +165,7 @@ static int clk_dump(struct seq_file *s, void *data)
clk_dump_subtree(s, c, 0);
}
- mutex_unlock(&prepare_lock);
+ clk_prepare_unlock();
seq_printf(s, "}");
return 0;
@@ -316,7 +337,7 @@ static int __init clk_debug_init(void)
if (!orphandir)
return -ENOMEM;
- mutex_lock(&prepare_lock);
+ clk_prepare_lock();
hlist_for_each_entry(clk, &clk_root_list, child_node)
clk_debug_create_subtree(clk, rootdir);
@@ -326,7 +347,7 @@ static int __init clk_debug_init(void)
inited = 1;
- mutex_unlock(&prepare_lock);
+ clk_prepare_unlock();
return 0;
}
@@ -372,7 +393,7 @@ static void clk_disable_unused_subtree(struct clk *clk)
hlist_for_each_entry(child, &clk->children, child_node)
clk_disable_unused_subtree(child);
- spin_lock_irqsave(&enable_lock, flags);
+ clk_enable_lock(&flags);
if (clk->enable_count)
goto unlock_out;
@@ -393,7 +414,7 @@ static void clk_disable_unused_subtree(struct clk *clk)
}
unlock_out:
- spin_unlock_irqrestore(&enable_lock, flags);
+ clk_enable_unlock(&flags);
out:
return;
@@ -403,7 +424,7 @@ static int clk_disable_unused(void)
{
struct clk *clk;
- mutex_lock(&prepare_lock);
+ clk_prepare_lock();
hlist_for_each_entry(clk, &clk_root_list, child_node)
clk_disable_unused_subtree(clk);
@@ -417,7 +438,7 @@ static int clk_disable_unused(void)
hlist_for_each_entry(clk, &clk_orphan_list, child_node)
clk_unprepare_unused_subtree(clk);
- mutex_unlock(&prepare_lock);
+ clk_prepare_unlock();
return 0;
}
@@ -600,9 +621,9 @@ void __clk_unprepare(struct clk *clk)
*/
void clk_unprepare(struct clk *clk)
{
- mutex_lock(&prepare_lock);
+ clk_prepare_lock();
__clk_unprepare(clk);
- mutex_unlock(&prepare_lock);
+ clk_prepare_unlock();
}
EXPORT_SYMBOL_GPL(clk_unprepare);
@@ -648,9 +669,9 @@ int clk_prepare(struct clk *clk)
{
int ret;
- mutex_lock(&prepare_lock);
+ clk_prepare_lock();
ret = __clk_prepare(clk);
- mutex_unlock(&prepare_lock);
+ clk_prepare_unlock();
return ret;
}
@@ -692,9 +713,9 @@ void clk_disable(struct clk *clk)
{
unsigned long flags;
- spin_lock_irqsave(&enable_lock, flags);
+ clk_enable_lock(&flags);
__clk_disable(clk);
- spin_unlock_irqrestore(&enable_lock, flags);
+ clk_enable_unlock(&flags);
}
EXPORT_SYMBOL_GPL(clk_disable);
@@ -745,9 +766,9 @@ int clk_enable(struct clk *clk)
unsigned long flags;
int ret;
-
[PATCH v5 0/2] reentrancy in the common clk framework
This fifth attempt at allowing calls to the clk api to reenter splits the last patch into two parts. The first patch abstracts out the locking details into some helper functions and converts all of the direct calls to the mutex and spinlock api to use these helpers. The second patch introduces the reentrancy logic into these helper functions. Fundamentally the reentrancy logic hasn't changed since v4, but fixing casting bugs, removing unnecessary barriers and better design & beautification separate this approach from the last one. Changes tested on top of the latest clk-next branch with an OMAP4430 Panda board. Mike Turquette (2): clk: abstract locking out into helper functions clk: allow reentrant calls into the clk framework drivers/clk/clk.c | 136 ++--- 1 file changed, 98 insertions(+), 38 deletions(-) -- 1.7.10.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/
Re: [PATCH -next] mg_disk: fix error return code in mg_probe()
On Thursday, March 28, 2013 1:32 PM, Wei Yongjun wrote:
>
> From: Wei Yongjun
>
> Fix to return a negative error code from the error handling
> case instead of 0, as returned elsewhere in this function.
>
> Signed-off-by: Wei Yongjun
CC'ed Jens Axboe
It looks good.
Reviewed-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> drivers/block/mg_disk.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/block/mg_disk.c b/drivers/block/mg_disk.c
> index 532bb89..a56cfcd 100644
> --- a/drivers/block/mg_disk.c
> +++ b/drivers/block/mg_disk.c
> @@ -892,8 +892,10 @@ static int mg_probe(struct platform_device *plat_dev)
> gpio_direction_output(host->rst, 1);
>
> /* reset out pin */
> - if (!(prv_data->dev_attr & MG_DEV_MASK))
> + if (!(prv_data->dev_attr & MG_DEV_MASK)) {
> + err = -EINVAL;
> goto probe_err_3a;
> + }
>
> if (prv_data->dev_attr != MG_BOOT_DEV) {
> rsc = platform_get_resource_byname(plat_dev, IORESOURCE_IO,
--
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] ARM: davinci: use is IS_ENABLED macro
Hi Sekhar,
On Wed, Mar 27, 2013 at 4:13 PM, Stephen Rothwell wrote:
> Hi,
>
> On Mon, 25 Mar 2013 16:51:35 +0530 Prabhakar lad
> wrote:
>>
>> --- a/arch/arm/mach-davinci/board-da830-evm.c
>> +++ b/arch/arm/mach-davinci/board-da830-evm.c
>> @@ -298,7 +298,7 @@ static const short da830_evm_emif25_pins[] = {
>> -1
>> };
>>
>> -#if defined(CONFIG_MMC_DAVINCI) || defined(CONFIG_MMC_DAVINCI_MODULE)
>> +#if IS_ENABLED(CONFIG_MMC_DAVINCI)
>> #define HAS_MMC 1
>> #else
>> #define HAS_MMC 0
>
> Why not
>
> #define HAS_MMC IS_ENABLED(CONFIG_MMC_DAVINCI)
>
> and similarly in the rest?
>
Stephen's suggestion looks good to me, if you haven’t queued it i'll post a v2,
or if you have already queued it I'll create a patch on top of the
same patch fixing it.
lemme know how would you want it.
Regards,
--Prabhakar
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
--
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 -next] mg_disk: fix error return code in mg_probe()
From: Wei Yongjun
Fix to return a negative error code from the error handling
case instead of 0, as returned elsewhere in this function.
Signed-off-by: Wei Yongjun
---
drivers/block/mg_disk.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/block/mg_disk.c b/drivers/block/mg_disk.c
index 532bb89..a56cfcd 100644
--- a/drivers/block/mg_disk.c
+++ b/drivers/block/mg_disk.c
@@ -892,8 +892,10 @@ static int mg_probe(struct platform_device *plat_dev)
gpio_direction_output(host->rst, 1);
/* reset out pin */
- if (!(prv_data->dev_attr & MG_DEV_MASK))
+ if (!(prv_data->dev_attr & MG_DEV_MASK)) {
+ err = -EINVAL;
goto probe_err_3a;
+ }
if (prv_data->dev_attr != MG_BOOT_DEV) {
rsc = platform_get_resource_byname(plat_dev, IORESOURCE_IO,
--
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: zsmalloc zbud hybrid design discussion?
On 03/28/2013 04:04 AM, Dan Magenheimer wrote: > Seth and all zproject folks -- > > I've been giving some deep thought as to how a zpage > allocator might be designed that would incorporate the > best of both zsmalloc and zbud. > > Rather than dive into coding, it occurs to me that the > best chance of success would be if all interested parties > could first discuss (on-list) and converge on a design > that we can all agree on. If we achieve that, I don't > care who writes the code and/or gets the credit or > chooses the name. If we can't achieve consensus, at > least it will be much clearer where our differences lie. > > Any thoughts? Can't agree more! Hoping we would agree on a design dealing well with density/fragmentation/pageframe-reclaim and better integration with MM. And then working together to implement it. -- Regards, -Bob -- 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] PCI, ACPI: Don't query OSC support with all possible controls
Found problem on system that firmware that could handle pci aer.
Firmware get error reporting after pci injecting error, before os boots.
But after os boots, firmware can not get report anymore, even pci=noaer
is passed.
Root cause: BIOS _OSC has problem with query bit checking.
It turns out that BIOS vendor is copying example code from ACPI Spec.
In ACPI Spec 5.0, page 290:
If (Not(And(CDW1,1))) // Query flag clear?
{ // Disable GPEs for features granted native control.
If (And(CTRL,0x01)) // Hot plug control granted?
{
Store(0,HPCE) // clear the hot plug SCI enable bit
Store(1,HPCS) // clear the hot plug SCI status bit
}
...
}
When Query flag is set, And(CDW1,1) will be 1, Not(1) will return 0xfffe.
So it will get into code path that should be for control set only.
BIOS acpi code should be changed to "If (LEqual(And(CDW1,1), 0)))"
Current kernel code is using _OSC query to notify firmware about support
from OS and then use _OSC to set control bits.
During query support, current code is using all possible controls.
So will execute code that should be only for control set stage.
That will have problem when pci=noaer or aer firmware_first is used.
As firmware have that control set for os aer already in query support stage,
but later will not os aer handling.
We should avoid passing all possible controls, just use osc_control_set
instead.
That should workaround BIOS bugs with affected systems on the field
as more bios vendors are copying sample code from ACPI spec.
Signed-off-by: Yinghai Lu
Cc: sta...@kernel.org
---
drivers/acpi/pci_root.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6/drivers/acpi/pci_root.c
===
--- linux-2.6.orig/drivers/acpi/pci_root.c
+++ linux-2.6/drivers/acpi/pci_root.c
@@ -201,8 +201,8 @@ static acpi_status acpi_pci_query_osc(st
*control &= OSC_PCI_CONTROL_MASKS;
capbuf[OSC_CONTROL_TYPE] = *control | root->osc_control_set;
} else {
- /* Run _OSC query for all possible controls. */
- capbuf[OSC_CONTROL_TYPE] = OSC_PCI_CONTROL_MASKS;
+ /* Run _OSC query only with existing controls. */
+ capbuf[OSC_CONTROL_TYPE] = root->osc_control_set;
}
status = acpi_pci_run_osc(root->device->handle, capbuf, &result);
--
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/
linux-next: manual merge of the signal tree with Linus' tree
Hi Al,
Today's linux-next merge of the signal tree got a conflict in fs/splice.c
between commit 06ae43f34bcc ("Don't bother with redoing rw_verify_area()
from default_file_splice_from()") from Linus' tree and commit
76b021d053ed ("convert vmsplice to COMPAT_SYSCALL_DEFINE") from the
signal tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/splice.c
index 29e394e,23ade0e..000
--- a/fs/splice.c
+++ b/fs/splice.c
@@@ -31,7 -31,7 +31,8 @@@
#include
#include
#include
+ #include
+#include "internal.h"
/*
* Attempt to steal a page from a pipe buffer. This should perhaps go into
pgprhdhWDGjRn.pgp
Description: PGP signature
[PATCH 2/2] eisa, PCI: init eisa early before pnp step in
Mathhew reported kernels fail the pci_eisa probe and are later successful
with the virtual_eisa_root_init force probe without slot0.
The reason for that is: pnp probing is early than pci_eisa_init get called
as pci_eisa_init is called via pci_driver.
pnp 00:0f has 0xc80 - 0xc84 reserved.
[9.700409] pnp 00:0f: [io 0x0c80-0x0c84]
so eisa_probe will fail from pci_eisa_init
==>eisa_root_register
==>eisa_probe path.
as force_probe is not set in pci_eisa_root, it will bail early when
slot0 is not probed and initialized.
Try to use subsys_initcall_sync instead, and will keep following sequence:
pci_subsys_init
pci_eisa_init_early
pnpacpi_init/isapnp_init
After this patch eisa can be initialized properly, and pnp overlapping
resource will not be reserved.
[ 10.104434] system 00:0f: [io 0x0c80-0x0c84] could not be reserved
Reported-by: Matthew Whitehead
Tested-by: Matthew Whitehead
Signed-off-by: Yinghai Lu
Cc: sta...@kernel.org
---
drivers/eisa/pci_eisa.c | 41 ++---
1 file changed, 22 insertions(+), 19 deletions(-)
Index: linux-2.6/drivers/eisa/pci_eisa.c
===
--- linux-2.6.orig/drivers/eisa/pci_eisa.c
+++ linux-2.6/drivers/eisa/pci_eisa.c
@@ -19,8 +19,7 @@
/* There is only *one* pci_eisa device per machine, right ? */
static struct eisa_root_device pci_eisa_root;
-static int __init pci_eisa_init(struct pci_dev *pdev,
- const struct pci_device_id *ent)
+static int __init pci_eisa_init(struct pci_dev *pdev)
{
int rc, n = 0;
struct resource *bus_res;
@@ -49,22 +48,26 @@ static int __init pci_eisa_init(struct p
return 0;
}
-static struct pci_device_id pci_eisa_pci_tbl[] = {
- { PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
- PCI_CLASS_BRIDGE_EISA << 8, 0x00, 0 },
- { 0, }
-};
-
-static struct pci_driver __refdata pci_eisa_driver = {
- .name = "pci_eisa",
- .id_table = pci_eisa_pci_tbl,
- .probe = pci_eisa_init,
-};
-
-static int __init pci_eisa_init_module (void)
+/*
+ * We have to call pci_eisa_init_early() before pnpacpi_init()/isapnp_init().
+ * Otherwise pnp resource will get enabled early and could prevent eisa
+ * to be initialized.
+ * Also need to make sure pci_eisa_init_early() is called after
+ * x86/pci_subsys_init().
+ * So need to use subsys_initcall_sync with it.
+ */
+static int __init pci_eisa_init_early(void)
{
- return pci_register_driver (&pci_eisa_driver);
-}
+ struct pci_dev *dev = NULL;
+ int ret;
+
+ for_each_pci_dev(dev)
+ if ((dev->class >> 8) == PCI_CLASS_BRIDGE_EISA) {
+ ret = pci_eisa_init(dev);
+ if (ret)
+ return ret;
+ }
-device_initcall(pci_eisa_init_module);
-MODULE_DEVICE_TABLE(pci, pci_eisa_pci_tbl);
+ return 0;
+}
+subsys_initcall_sync(pci_eisa_init_early);
--
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/2] eisa, PCI: Fix bus res reference
Matthem found that 3.8.3 is having problems with an old (ancient)
PCI-to-EISA bridge, the Intel 82375. It worked with the 3.2 kernel.
He identified the 82375, but doesn't assign the struct resource *res
pointer inside the struct eisa_root_device, and panics.
After looking at pci_eisa_init(), found it referring bus resource
directly instead of pci_bus_resource_n().
After commit 45ca9e97 (PCI: add helpers for building PCI bus resource lists)
and commit 0efd5aab (PCI: add struct pci_host_bridge_window with CPU/bus
address offset), bus->resource[] is not used for pci root bus any more.
Fix it by using pci_bus_resource_n() and correct idx for root bus.
Reported-by: Matthew Whitehead
Tested-by: Matthew Whitehead
Signed-off-by: Yinghai Lu
Cc: sta...@kernel.org
---
drivers/eisa/pci_eisa.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
Index: linux-2.6/drivers/eisa/pci_eisa.c
===
--- linux-2.6.orig/drivers/eisa/pci_eisa.c
+++ linux-2.6/drivers/eisa/pci_eisa.c
@@ -22,7 +22,8 @@ static struct eisa_root_device pci_eisa_
static int __init pci_eisa_init(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
- int rc;
+ int rc, n = 0;
+ struct resource *bus_res;
if ((rc = pci_enable_device (pdev))) {
printk (KERN_ERR "pci_eisa : Could not enable device %s\n",
@@ -30,9 +31,12 @@ static int __init pci_eisa_init(struct p
return rc;
}
+ if (pci_is_root_bus(pdev->bus))
+ n = PCI_BRIDGE_RESOURCE_NUM;
+ bus_res = pci_bus_resource_n(pdev->bus, n);
pci_eisa_root.dev = &pdev->dev;
- pci_eisa_root.res = pdev->bus->resource[0];
- pci_eisa_root.bus_base_addr= pdev->bus->resource[0]->start;
+ pci_eisa_root.res = bus_res;
+ pci_eisa_root.bus_base_addr= bus_res->start;
pci_eisa_root.slots= EISA_MAX_SLOTS;
pci_eisa_root.dma_mask = pdev->dma_mask;
dev_set_drvdata(pci_eisa_root.dev, &pci_eisa_root);
--
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/2] eisa: fix eisa with PCI
Looks like pci eisa bridge support is broken for a while. one is root io resource reference, and other one is pnp related. Please check if we can put them in v3.9. eisa, PCI: Fix bus res reference eisa, PCI: init eisa early before pnp step in Thanks Yinghai Lu -- 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 6/7] cpuacct: Remove redundant NULL checks in cpuacct_acount_field()
This is a micro optimazation for a hot path.
- We don't need to check if @ca returned from task_ca() is NULL.
- We don't need to check if @ca returned from parent_ca() is NULL.
Signed-off-by: Li Zefan
---
kernel/sched/cpuacct.c | 4 ++--
kernel/sched/cpuacct.h | 5 +
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index b2aaaba..071ae8d 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -237,10 +237,10 @@ void cpuacct_account_field(struct task_struct *p, int
index, u64 val)
rcu_read_lock();
ca = task_ca(p);
- while (ca && (ca != &root_cpuacct)) {
+ while (ca != &root_cpuacct) {
kcpustat = this_cpu_ptr(ca->cpustat);
kcpustat->cpustat[index] += val;
- ca = parent_ca(ca);
+ ca = __parent_ca(ca);
}
rcu_read_unlock();
}
diff --git a/kernel/sched/cpuacct.h b/kernel/sched/cpuacct.h
index 45c1682..b2f79ad 100644
--- a/kernel/sched/cpuacct.h
+++ b/kernel/sched/cpuacct.h
@@ -34,6 +34,11 @@ static inline struct cpuacct *task_ca(struct task_struct
*tsk)
struct cpuacct, css);
}
+static inline struct cpuacct *__parent_ca(struct cpuacct *ca)
+{
+ return cgroup_ca(ca->css.cgroup->parent);
+}
+
static inline struct cpuacct *parent_ca(struct cpuacct *ca)
{
if (!ca->css.cgroup->parent)
--
1.8.0.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 7/7] cpuacct: Clean up cpuacct.h
Now most of the code in cpuacct.h can be moved to cpuacct.c
Signed-off-by: Li Zefan
---
kernel/sched/cpuacct.c | 44 +++-
kernel/sched/cpuacct.h | 46 --
2 files changed, 43 insertions(+), 47 deletions(-)
diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index 071ae8d..9305fd2 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -16,7 +16,49 @@
* (bal...@in.ibm.com).
*/
-struct cpuacct root_cpuacct;
+/* Time spent by the tasks of the cpu accounting group executing in ... */
+enum cpuacct_stat_index {
+ CPUACCT_STAT_USER, /* ... user mode */
+ CPUACCT_STAT_SYSTEM,/* ... kernel mode */
+
+ CPUACCT_STAT_NSTATS,
+};
+
+/* track cpu usage of a group of tasks and its child groups */
+struct cpuacct {
+ struct cgroup_subsys_state css;
+ /* cpuusage holds pointer to a u64-type object on every cpu */
+ u64 __percpu *cpuusage;
+ struct kernel_cpustat __percpu *cpustat;
+};
+
+/* return cpu accounting group corresponding to this container */
+static inline struct cpuacct *cgroup_ca(struct cgroup *cgrp)
+{
+ return container_of(cgroup_subsys_state(cgrp, cpuacct_subsys_id),
+ struct cpuacct, css);
+}
+
+/* return cpu accounting group to which this task belongs */
+static inline struct cpuacct *task_ca(struct task_struct *tsk)
+{
+ return container_of(task_subsys_state(tsk, cpuacct_subsys_id),
+ struct cpuacct, css);
+}
+
+static inline struct cpuacct *__parent_ca(struct cpuacct *ca)
+{
+ return cgroup_ca(ca->css.cgroup->parent);
+}
+
+static inline struct cpuacct *parent_ca(struct cpuacct *ca)
+{
+ if (!ca->css.cgroup->parent)
+ return NULL;
+ return cgroup_ca(ca->css.cgroup->parent);
+}
+
+static struct cpuacct root_cpuacct;
/* create a new cpu accounting group */
static struct cgroup_subsys_state *cpuacct_css_alloc(struct cgroup *cgrp)
diff --git a/kernel/sched/cpuacct.h b/kernel/sched/cpuacct.h
index b2f79ad..51cd76e 100644
--- a/kernel/sched/cpuacct.h
+++ b/kernel/sched/cpuacct.h
@@ -1,51 +1,5 @@
-/* Time spent by the tasks of the cpu accounting group executing in ... */
-enum cpuacct_stat_index {
- CPUACCT_STAT_USER, /* ... user mode */
- CPUACCT_STAT_SYSTEM,/* ... kernel mode */
-
- CPUACCT_STAT_NSTATS,
-};
-
#ifdef CONFIG_CGROUP_CPUACCT
-#include
-/* track cpu usage of a group of tasks and its child groups */
-struct cpuacct {
- struct cgroup_subsys_state css;
- /* cpuusage holds pointer to a u64-type object on every cpu */
- u64 __percpu *cpuusage;
- struct kernel_cpustat __percpu *cpustat;
-};
-
-extern struct cgroup_subsys cpuacct_subsys;
-extern struct cpuacct root_cpuacct;
-
-/* return cpu accounting group corresponding to this container */
-static inline struct cpuacct *cgroup_ca(struct cgroup *cgrp)
-{
- return container_of(cgroup_subsys_state(cgrp, cpuacct_subsys_id),
- struct cpuacct, css);
-}
-
-/* return cpu accounting group to which this task belongs */
-static inline struct cpuacct *task_ca(struct task_struct *tsk)
-{
- return container_of(task_subsys_state(tsk, cpuacct_subsys_id),
- struct cpuacct, css);
-}
-
-static inline struct cpuacct *__parent_ca(struct cpuacct *ca)
-{
- return cgroup_ca(ca->css.cgroup->parent);
-}
-
-static inline struct cpuacct *parent_ca(struct cpuacct *ca)
-{
- if (!ca->css.cgroup->parent)
- return NULL;
- return cgroup_ca(ca->css.cgroup->parent);
-}
-
extern void cpuacct_init(void);
extern void cpuacct_charge(struct task_struct *tsk, u64 cputime);
extern void cpuacct_account_field(struct task_struct *p, int index, u64 val);
--
1.8.0.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 2/7] sched: Split cpuacct out of sched.h
Add cpuacct.h and let sched.h include it.
Signed-off-by: Li Zefan
---
kernel/sched/cpuacct.h | 52 ++
kernel/sched/sched.h | 49 +--
2 files changed, 53 insertions(+), 48 deletions(-)
create mode 100644 kernel/sched/cpuacct.h
diff --git a/kernel/sched/cpuacct.h b/kernel/sched/cpuacct.h
new file mode 100644
index 000..a7f3d4a
--- /dev/null
+++ b/kernel/sched/cpuacct.h
@@ -0,0 +1,52 @@
+/* Time spent by the tasks of the cpu accounting group executing in ... */
+enum cpuacct_stat_index {
+ CPUACCT_STAT_USER, /* ... user mode */
+ CPUACCT_STAT_SYSTEM,/* ... kernel mode */
+
+ CPUACCT_STAT_NSTATS,
+};
+
+#ifdef CONFIG_CGROUP_CPUACCT
+
+#include
+/* track cpu usage of a group of tasks and its child groups */
+struct cpuacct {
+ struct cgroup_subsys_state css;
+ /* cpuusage holds pointer to a u64-type object on every cpu */
+ u64 __percpu *cpuusage;
+ struct kernel_cpustat __percpu *cpustat;
+};
+
+extern struct cgroup_subsys cpuacct_subsys;
+extern struct cpuacct root_cpuacct;
+
+/* return cpu accounting group corresponding to this container */
+static inline struct cpuacct *cgroup_ca(struct cgroup *cgrp)
+{
+ return container_of(cgroup_subsys_state(cgrp, cpuacct_subsys_id),
+ struct cpuacct, css);
+}
+
+/* return cpu accounting group to which this task belongs */
+static inline struct cpuacct *task_ca(struct task_struct *tsk)
+{
+ return container_of(task_subsys_state(tsk, cpuacct_subsys_id),
+ struct cpuacct, css);
+}
+
+static inline struct cpuacct *parent_ca(struct cpuacct *ca)
+{
+ if (!ca || !ca->css.cgroup->parent)
+ return NULL;
+ return cgroup_ca(ca->css.cgroup->parent);
+}
+
+extern void cpuacct_charge(struct task_struct *tsk, u64 cputime);
+
+#else
+
+static inline void cpuacct_charge(struct task_struct *tsk, u64 cputime)
+{
+}
+
+#endif
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index cc03cfd..5bfcaba 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -7,6 +7,7 @@
#include
#include "cpupri.h"
+#include "cpuacct.h"
extern __read_mostly int scheduler_running;
@@ -856,15 +857,6 @@ static const u32 prio_to_wmult[40] = {
/* 15 */ 119304647, 148102320, 186737708, 238609294, 286331153,
};
-/* Time spent by the tasks of the cpu accounting group executing in ... */
-enum cpuacct_stat_index {
- CPUACCT_STAT_USER, /* ... user mode */
- CPUACCT_STAT_SYSTEM,/* ... kernel mode */
-
- CPUACCT_STAT_NSTATS,
-};
-
-
#define sched_class_highest (&stop_sched_class)
#define for_each_class(class) \
for (class = sched_class_highest; class; class = class->next)
@@ -904,45 +896,6 @@ extern void init_rt_bandwidth(struct rt_bandwidth *rt_b,
u64 period, u64 runtime
extern void update_idle_cpu_load(struct rq *this_rq);
-#ifdef CONFIG_CGROUP_CPUACCT
-#include
-/* track cpu usage of a group of tasks and its child groups */
-struct cpuacct {
- struct cgroup_subsys_state css;
- /* cpuusage holds pointer to a u64-type object on every cpu */
- u64 __percpu *cpuusage;
- struct kernel_cpustat __percpu *cpustat;
-};
-
-extern struct cgroup_subsys cpuacct_subsys;
-extern struct cpuacct root_cpuacct;
-
-/* return cpu accounting group corresponding to this container */
-static inline struct cpuacct *cgroup_ca(struct cgroup *cgrp)
-{
- return container_of(cgroup_subsys_state(cgrp, cpuacct_subsys_id),
- struct cpuacct, css);
-}
-
-/* return cpu accounting group to which this task belongs */
-static inline struct cpuacct *task_ca(struct task_struct *tsk)
-{
- return container_of(task_subsys_state(tsk, cpuacct_subsys_id),
- struct cpuacct, css);
-}
-
-static inline struct cpuacct *parent_ca(struct cpuacct *ca)
-{
- if (!ca || !ca->css.cgroup->parent)
- return NULL;
- return cgroup_ca(ca->css.cgroup->parent);
-}
-
-extern void cpuacct_charge(struct task_struct *tsk, u64 cputime);
-#else
-static inline void cpuacct_charge(struct task_struct *tsk, u64 cputime) {}
-#endif
-
#ifdef CONFIG_PARAVIRT
static inline u64 steal_ticks(u64 steal)
{
--
1.8.0.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 5/7] cpuacct: Remove redundant NULL checks in cpuacct_charge()
This is micro optimization for the hot path.
- We don't need to check if @ca is NULL in parent_ca().
- We don't need to check if @ca is NULL in the beginning of the for loop.
Signed-off-by: Li Zefan
---
kernel/sched/cpuacct.c | 6 +-
kernel/sched/cpuacct.h | 2 +-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index 72bd971..b2aaaba 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -210,9 +210,13 @@ void cpuacct_charge(struct task_struct *tsk, u64 cputime)
ca = task_ca(tsk);
- for (; ca; ca = parent_ca(ca)) {
+ while (true) {
u64 *cpuusage = per_cpu_ptr(ca->cpuusage, cpu);
*cpuusage += cputime;
+
+ ca = parent_ca(ca);
+ if (!ca)
+ break;
}
rcu_read_unlock();
diff --git a/kernel/sched/cpuacct.h b/kernel/sched/cpuacct.h
index bd0409b..45c1682 100644
--- a/kernel/sched/cpuacct.h
+++ b/kernel/sched/cpuacct.h
@@ -36,7 +36,7 @@ static inline struct cpuacct *task_ca(struct task_struct *tsk)
static inline struct cpuacct *parent_ca(struct cpuacct *ca)
{
- if (!ca || !ca->css.cgroup->parent)
+ if (!ca->css.cgroup->parent)
return NULL;
return cgroup_ca(ca->css.cgroup->parent);
}
--
1.8.0.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 4/7] cpuacct: Add cpuacct_acount_field()
So we can remove open-coded cpuacct code in cputime.c.
Signed-off-by: Li Zefan
---
kernel/sched/cpuacct.c | 23 +++
kernel/sched/cpuacct.h | 6 ++
kernel/sched/cputime.c | 18 +-
3 files changed, 30 insertions(+), 17 deletions(-)
diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index 48b5e91..72bd971 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -218,6 +218,29 @@ void cpuacct_charge(struct task_struct *tsk, u64 cputime)
rcu_read_unlock();
}
+/*
+ * Add user/system time to cpuacct.
+ *
+ * Note: it's the caller that updates the account of the root cgroup.
+ */
+void cpuacct_account_field(struct task_struct *p, int index, u64 val)
+{
+ struct kernel_cpustat *kcpustat;
+ struct cpuacct *ca;
+
+ if (unlikely(!cpuacct_subsys.active))
+ return;
+
+ rcu_read_lock();
+ ca = task_ca(p);
+ while (ca && (ca != &root_cpuacct)) {
+ kcpustat = this_cpu_ptr(ca->cpustat);
+ kcpustat->cpustat[index] += val;
+ ca = parent_ca(ca);
+ }
+ rcu_read_unlock();
+}
+
void __init cpuacct_init(void)
{
root_cpuacct.cpustat = &kernel_cpustat;
diff --git a/kernel/sched/cpuacct.h b/kernel/sched/cpuacct.h
index 551acd7..bd0409b 100644
--- a/kernel/sched/cpuacct.h
+++ b/kernel/sched/cpuacct.h
@@ -43,6 +43,7 @@ static inline struct cpuacct *parent_ca(struct cpuacct *ca)
extern void cpuacct_init(void);
extern void cpuacct_charge(struct task_struct *tsk, u64 cputime);
+extern void cpuacct_account_field(struct task_struct *p, int index, u64 val);
#else
@@ -54,4 +55,9 @@ static inline void cpuacct_charge(struct task_struct *tsk,
u64 cputime)
{
}
+static inline void
+cpuacct_account_field(struct task_struct *p, int index, u64 val)
+{
+}
+
#endif
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index ed12cbb..a5129c7 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -115,10 +115,6 @@ static int irqtime_account_si_update(void)
static inline void task_group_account_field(struct task_struct *p, int index,
u64 tmp)
{
-#ifdef CONFIG_CGROUP_CPUACCT
- struct kernel_cpustat *kcpustat;
- struct cpuacct *ca;
-#endif
/*
* Since all updates are sure to touch the root cgroup, we
* get ourselves ahead and touch it first. If the root cgroup
@@ -127,19 +123,7 @@ static inline void task_group_account_field(struct
task_struct *p, int index,
*/
__get_cpu_var(kernel_cpustat).cpustat[index] += tmp;
-#ifdef CONFIG_CGROUP_CPUACCT
- if (unlikely(!cpuacct_subsys.active))
- return;
-
- rcu_read_lock();
- ca = task_ca(p);
- while (ca && (ca != &root_cpuacct)) {
- kcpustat = this_cpu_ptr(ca->cpustat);
- kcpustat->cpustat[index] += tmp;
- ca = parent_ca(ca);
- }
- rcu_read_unlock();
-#endif
+ cpuacct_account_field(p, index, tmp);
}
/*
--
1.8.0.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 3/7] cpuacct: Add cpuacct_init()
So we don't open-coded initialization of cpuacct in core.c.
Signed-off-by: Li Zefan
---
kernel/sched/core.c| 8 ++--
kernel/sched/cpuacct.c | 7 +++
kernel/sched/cpuacct.h | 5 +
3 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 8eb3096..9f5a804 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6860,12 +6860,8 @@ void __init sched_init(void)
#endif /* CONFIG_CGROUP_SCHED */
-#ifdef CONFIG_CGROUP_CPUACCT
- root_cpuacct.cpustat = &kernel_cpustat;
- root_cpuacct.cpuusage = alloc_percpu(u64);
- /* Too early, not expected to fail */
- BUG_ON(!root_cpuacct.cpuusage);
-#endif
+ cpuacct_init();
+
for_each_possible_cpu(i) {
struct rq *rq;
diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index 50ec24b..48b5e91 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -218,6 +218,13 @@ void cpuacct_charge(struct task_struct *tsk, u64 cputime)
rcu_read_unlock();
}
+void __init cpuacct_init(void)
+{
+ root_cpuacct.cpustat = &kernel_cpustat;
+ root_cpuacct.cpuusage = alloc_percpu(u64);
+ BUG_ON(!root_cpuacct.cpuusage); /* Too early, not expected to fail */
+}
+
struct cgroup_subsys cpuacct_subsys = {
.name = "cpuacct",
.css_alloc = cpuacct_css_alloc,
diff --git a/kernel/sched/cpuacct.h b/kernel/sched/cpuacct.h
index a7f3d4a..551acd7 100644
--- a/kernel/sched/cpuacct.h
+++ b/kernel/sched/cpuacct.h
@@ -41,10 +41,15 @@ static inline struct cpuacct *parent_ca(struct cpuacct *ca)
return cgroup_ca(ca->css.cgroup->parent);
}
+extern void cpuacct_init(void);
extern void cpuacct_charge(struct task_struct *tsk, u64 cputime);
#else
+static inline void cpuacct_init(void)
+{
+}
+
static inline void cpuacct_charge(struct task_struct *tsk, u64 cputime)
{
}
--
1.8.0.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 1/7] sched: Split cpuacct code out of core.c
Signed-off-by: Li Zefan
---
kernel/sched/Makefile | 1 +
kernel/sched/core.c| 220 ---
kernel/sched/cpuacct.c | 227 +
3 files changed, 228 insertions(+), 220 deletions(-)
create mode 100644 kernel/sched/cpuacct.c
diff --git a/kernel/sched/Makefile b/kernel/sched/Makefile
index f06d249..deaf90e 100644
--- a/kernel/sched/Makefile
+++ b/kernel/sched/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_SMP) += cpupri.o
obj-$(CONFIG_SCHED_AUTOGROUP) += auto_group.o
obj-$(CONFIG_SCHEDSTATS) += stats.o
obj-$(CONFIG_SCHED_DEBUG) += debug.o
+obj-$(CONFIG_CGROUP_CPUACCT) += cpuacct.o
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index b7b03cd..8eb3096 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7938,226 +7938,6 @@ struct cgroup_subsys cpu_cgroup_subsys = {
#endif /* CONFIG_CGROUP_SCHED */
-#ifdef CONFIG_CGROUP_CPUACCT
-
-/*
- * CPU accounting code for task groups.
- *
- * Based on the work by Paul Menage (men...@google.com) and Balbir Singh
- * (bal...@in.ibm.com).
- */
-
-struct cpuacct root_cpuacct;
-
-/* create a new cpu accounting group */
-static struct cgroup_subsys_state *cpuacct_css_alloc(struct cgroup *cgrp)
-{
- struct cpuacct *ca;
-
- if (!cgrp->parent)
- return &root_cpuacct.css;
-
- ca = kzalloc(sizeof(*ca), GFP_KERNEL);
- if (!ca)
- goto out;
-
- ca->cpuusage = alloc_percpu(u64);
- if (!ca->cpuusage)
- goto out_free_ca;
-
- ca->cpustat = alloc_percpu(struct kernel_cpustat);
- if (!ca->cpustat)
- goto out_free_cpuusage;
-
- return &ca->css;
-
-out_free_cpuusage:
- free_percpu(ca->cpuusage);
-out_free_ca:
- kfree(ca);
-out:
- return ERR_PTR(-ENOMEM);
-}
-
-/* destroy an existing cpu accounting group */
-static void cpuacct_css_free(struct cgroup *cgrp)
-{
- struct cpuacct *ca = cgroup_ca(cgrp);
-
- free_percpu(ca->cpustat);
- free_percpu(ca->cpuusage);
- kfree(ca);
-}
-
-static u64 cpuacct_cpuusage_read(struct cpuacct *ca, int cpu)
-{
- u64 *cpuusage = per_cpu_ptr(ca->cpuusage, cpu);
- u64 data;
-
-#ifndef CONFIG_64BIT
- /*
-* Take rq->lock to make 64-bit read safe on 32-bit platforms.
-*/
- raw_spin_lock_irq(&cpu_rq(cpu)->lock);
- data = *cpuusage;
- raw_spin_unlock_irq(&cpu_rq(cpu)->lock);
-#else
- data = *cpuusage;
-#endif
-
- return data;
-}
-
-static void cpuacct_cpuusage_write(struct cpuacct *ca, int cpu, u64 val)
-{
- u64 *cpuusage = per_cpu_ptr(ca->cpuusage, cpu);
-
-#ifndef CONFIG_64BIT
- /*
-* Take rq->lock to make 64-bit write safe on 32-bit platforms.
-*/
- raw_spin_lock_irq(&cpu_rq(cpu)->lock);
- *cpuusage = val;
- raw_spin_unlock_irq(&cpu_rq(cpu)->lock);
-#else
- *cpuusage = val;
-#endif
-}
-
-/* return total cpu usage (in nanoseconds) of a group */
-static u64 cpuusage_read(struct cgroup *cgrp, struct cftype *cft)
-{
- struct cpuacct *ca = cgroup_ca(cgrp);
- u64 totalcpuusage = 0;
- int i;
-
- for_each_present_cpu(i)
- totalcpuusage += cpuacct_cpuusage_read(ca, i);
-
- return totalcpuusage;
-}
-
-static int cpuusage_write(struct cgroup *cgrp, struct cftype *cftype,
- u64 reset)
-{
- struct cpuacct *ca = cgroup_ca(cgrp);
- int err = 0;
- int i;
-
- if (reset) {
- err = -EINVAL;
- goto out;
- }
-
- for_each_present_cpu(i)
- cpuacct_cpuusage_write(ca, i, 0);
-
-out:
- return err;
-}
-
-static int cpuacct_percpu_seq_read(struct cgroup *cgroup, struct cftype *cft,
- struct seq_file *m)
-{
- struct cpuacct *ca = cgroup_ca(cgroup);
- u64 percpu;
- int i;
-
- for_each_present_cpu(i) {
- percpu = cpuacct_cpuusage_read(ca, i);
- seq_printf(m, "%llu ", (unsigned long long) percpu);
- }
- seq_printf(m, "\n");
- return 0;
-}
-
-static const char *cpuacct_stat_desc[] = {
- [CPUACCT_STAT_USER] = "user",
- [CPUACCT_STAT_SYSTEM] = "system",
-};
-
-static int cpuacct_stats_show(struct cgroup *cgrp, struct cftype *cft,
- struct cgroup_map_cb *cb)
-{
- struct cpuacct *ca = cgroup_ca(cgrp);
- int cpu;
- s64 val = 0;
-
- for_each_online_cpu(cpu) {
- struct kernel_cpustat *kcpustat = per_cpu_ptr(ca->cpustat, cpu);
- val += kcpustat->cpustat[CPUTIME_USER];
- val += kcpustat->cpustat[CPUTIME_NICE];
- }
- val = cputime64_to_clock_t(val);
- cb->fill(cb, cpuacct_stat_desc[CPUACCT_STAT_USER], val);
-
- val = 0;
- for_each_online_cpu(cpu) {
- struct kernel_cpustat *kcpustat = per_cpu_ptr(ca->cpus
[PATCH 0/7] sched: Split cpuacct
- This patchset splits cpuacct out of core scheduler code. - Plus two small optimizations. 0001-sched-Split-cpuacct-code-out-of-core.c.patch 0002-sched-Split-cpuacct-out-of-sched.h.patch 0003-cpuacct-Add-cpuacct_init.patch 0004-cpuacct-Add-cpuacct_acount_field.patch 0005-cpuacct-Remove-redundant-NULL-checks-in-cpuacct_char.patch 0006-cpuacct-Remove-redundant-NULL-checks-in-cpuacct_acou.patch 0007-cpuacct-Clean-up-cpuacct.h.patch --- kernel/sched/Makefile | 1 + kernel/sched/core.c| 228 +-- kernel/sched/cpuacct.c | 303 +++ kernel/sched/cpuacct.h | 22 + kernel/sched/cputime.c | 18 +--- kernel/sched/sched.h | 49 +-- 6 files changed, 330 insertions(+), 291 deletions(-) -- 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 v4] watchdog: Add Broadcom BCM2835 watchdog timer driver
On Wed, Mar 27, 2013 at 09:00:29PM -0600, Stephen Warren wrote: > On 03/27/2013 10:40 AM, Lubomir Rintel wrote: > > This adds a driver for watchdog timer hardware present on Broadcom BCM2835 > > SoC, > > used in Raspberry Pi and Roku 2 devices. > > > > Signed-off-by: Lubomir Rintel > > Signed-off-by: Dom Cobley > > Those two s-o-b lines should be swapped, since if Dom did sign off on > any part of this patch, he did it before you did. > > That said... > > I wonder if it's actually appropriate to include Dom's s-o-b here, since > I don't think he really wrote this patch itself. I think you mentioned > that you hadn't use much of the downstream driver except for some defines? > > To be clear, I mentioned the existence of the S-o-b line downstream > simply to demonstrate that the commits you were getting information from > had correctly followed the process described in > Documentation/SubmittingPatches, and so it was OK to use that > information while creating a GPL'd driver. > > So there are a couple of ways that this patch could have been created: > > 1) You took the downstream commit itself, cherry-picked it into the > upstream kernel, modified it to suit upstream, and then submitted that. > The modifications might be extensive, such as renaming the file, > removing parts of the code that the upstream watchdog core now handles, > adding some new features, fixing bugs, cleanup, etc.; whatever is needed > to upstream the patch. > > In this case, I believe it would be appropriate to maintain any S-o-b > lines from the original downstream commit, and add yours. But, I believe > you should also (a) maintain the git author field from the original > downstream commit (b) include a list of the changes you made to the > patch in the commit description, so you can be blamed for them rather > than the original author:-) > > 2) You read the downstream commit for information, but created a > completely new driver for the upstream kernel, using the downstream > driver just as a reference. In this case, I believe it's fine for the > git author field to be you, and for the only s-o-b line present to be > yours, since you really did write the patch from scratch. However, you > should credit the downstream work in the (c) header and/or commit > description. > > This current patch sees to be a slight hybrid of both approaches (you're > listed as the git author, but have included Dom's s-o-b line on a patch > I don't think he created, and wasn't directly derived from one he created). > > I'm not sure if I'm being too picky. I guess I'll leave it up to Wim Van > Sebroeck, since he's the watchdog maintainer and would be the person who > applies this patch. > I wondered about the same. I think 2) would be more appropriate. My approach would have been to reference previous work in the file header, something along the line of "derived from xxx", and add a copyright statement from the original work if there was one - pretty much what you propose above. Guenter -- 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] checkpatch: do not exit in main process subroutine
Currently checkpatch program exit when process empty file,
This will cause issue when @ARGV include many files ready to check.
For example, there may have Module.symvers empty file in kernel directory.
[root@jovi ~]# scripts/checkpatch.pl -f kernel/*
then many file "after" empty file will not be check by script.
so disallow exit in main process subroutine.
Signed-off-by: zhangwei(Jovi)
---
scripts/checkpatch.pl |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index b28cc38..6924733 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3634,19 +3634,19 @@ sub process {
# If we have no input at all, then there is nothing to report on
# so just keep quiet.
if ($#rawlines == -1) {
- exit(0);
+ return $clean;
}
# In mailback mode only produce a report in the negative, for
# things that appear to be patches.
if ($mailback && ($clean == 1 || !$is_patch)) {
- exit(0);
+ return $clean;
}
# This is not a patch, and we are are in 'no-patch' mode so
# just keep quiet.
if (!$chk_patch && !$is_patch) {
- exit(0);
+ return $clean;
}
if (!$is_patch) {
--
1.7.9.7
--
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] tokenring: delete last holdout of CONFIG_TR
From: Paul Bolle Date: Wed, 27 Mar 2013 21:52:28 +0100 > Tokenring support was deleted in v3.5. One last holdout of the macro > CONFIG_TR escaped that fate. Until now. > > Signed-off-by: Paul Bolle Applied to net-next, thanks. -- 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: Davicom Linux driver
Dear Miller, This is Joseph CHANG. I had sent you the patches used my gmail earlier than Allen did. My gmail account is josright...@gmail.com The patches's subjects were: [PATCH 1/2] ethernet: dm9000 driver: davicom: upgrade driver: 3rd trial [PATCH 2/2] ethernet: dm9000 driver: davicom: upgrade driver: 3rd trial patch2 Would you help confirm it again, Thanks. Best Regards, Joseph CHANG System Application Engineering Division Davicom Semiconductor, Inc. No. 6 Li-Hsin Rd. VI, Science-Based Park, Hsin-Chu, Taiwan. Tel: 886-3-5798797 Ex 8534 Fax: 886-3-5646929 Web: http://www.davicom.com.tw -Original Message- From: David Miller [mailto:da...@davemloft.net] Sent: Thursday, March 28, 2013 10:10 AM To: allen_hu...@davicom.com.tw Cc: r.e.wo...@bitwizard.nl; cor...@lwn.net; bonb...@linux-vserver.org; wf...@virginia.edu; matt...@mattleach.net; gre...@linuxfoundation.org; j...@resnulli.us; net...@vger.kernel.org; linux-kernel@vger.kernel.org; michael_c...@mail.davicom.com.tw; andrew_c...@davicom.com.tw; spenser_t...@davicom.com.tw; willie_n...@mail.davicom.com.tw; charles_t...@davicom.com.tw; joseph_ch...@mail.davicom.com.tw Subject: Re: Davicom Linux driver This is not the correct way to submit a patch for inclusion upstream You should post each patch in a seperate, numbered, list posting, in plain ASCII text, and not as an attachment. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: Davicom Linux driver
From: "Joseph Chang" Date: Thu, 28 Mar 2013 10:25:58 +0800 > Dear Miller, > > This is Joseph CHANG. > I had sent you the patches used my gmail earlier than Allen did. > My gmail account is josright...@gmail.com > The patches's subjects were: >[PATCH 1/2] ethernet: dm9000 driver: davicom: upgrade driver: 3rd trial >[PATCH 2/2] ethernet: dm9000 driver: davicom: upgrade driver: 3rd trial > patch2 You were given feedback and requested to make changes to those patches. -- 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: intel_pstate_timer_func divide by zero oops
On Wed, Mar 27, 2013 at 10:51 PM, Dirk Brandewie wrote: > > Is there any way to capture the beginning of this trace? I tried but since the oops scrolls fast followed by a hard freeze, I wasn't able to capture it completely. May be I can try netconsole and see if that helps. > > pid_param_set() is on the stack which means that something is changing > the debugfs parameters or the stack is FUBAR. > I somehow doubt the stack is messed up as the call traces are always identical. (pid_param_set() seems to be in first trace as well.) > > I don't see how duration_us can be zero unless somehow I am getting > back-to-back > timer callbacks which seems unlikely since the timer is not re-armed until > the timer function is about to return and the driver has done all its work > for the sample period Do the two oops with common call stack suggest back to back callbacks? I will add some debugging checks tomorrow to see what is going on. But sounds like a minimal fix would be to guard against callbacks in quick succession? i.e. return from sample if ktime_us_delta(now, cpu->prev_sample) is zero? Thanks, Parag -- 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: Davicom Linux driver
On Thu, Mar 28, 2013 at 10:25:58AM +0800, Joseph Chang wrote: > Dear Miller, > > This is Joseph CHANG. > I had sent you the patches used my gmail earlier than Allen did. > My gmail account is josright...@gmail.com > The patches's subjects were: >[PATCH 1/2] ethernet: dm9000 driver: davicom: upgrade driver: 3rd trial >[PATCH 2/2] ethernet: dm9000 driver: davicom: upgrade driver: 3rd trial > patch2 > > Would you help confirm it again, Thanks. That is not necessary, you can always "confirm" that a patch made it to a mailing list, by looking at the mailing list. -- 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/
Generic syscall ABI support
Need advise regarding the generic syscall ABI support. We are planning to upstream our Nios II kernel (arch/nios2) to mainline. But it doesn't support generic syscall ABI yet (It requires an updated Glibc port as well). The question is, is it a requirement for new arch to support generic syscall ABI when upstreaming? Can we upstream a non-generic syscall ABI first and migrate to generic syscall ABI in future? Thanks. Regards LFTAN -- 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 v4] watchdog: Add Broadcom BCM2835 watchdog timer driver
On 03/27/2013 10:40 AM, Lubomir Rintel wrote: > This adds a driver for watchdog timer hardware present on Broadcom BCM2835 > SoC, > used in Raspberry Pi and Roku 2 devices. > > Signed-off-by: Lubomir Rintel > Signed-off-by: Dom Cobley Those two s-o-b lines should be swapped, since if Dom did sign off on any part of this patch, he did it before you did. That said... I wonder if it's actually appropriate to include Dom's s-o-b here, since I don't think he really wrote this patch itself. I think you mentioned that you hadn't use much of the downstream driver except for some defines? To be clear, I mentioned the existence of the S-o-b line downstream simply to demonstrate that the commits you were getting information from had correctly followed the process described in Documentation/SubmittingPatches, and so it was OK to use that information while creating a GPL'd driver. So there are a couple of ways that this patch could have been created: 1) You took the downstream commit itself, cherry-picked it into the upstream kernel, modified it to suit upstream, and then submitted that. The modifications might be extensive, such as renaming the file, removing parts of the code that the upstream watchdog core now handles, adding some new features, fixing bugs, cleanup, etc.; whatever is needed to upstream the patch. In this case, I believe it would be appropriate to maintain any S-o-b lines from the original downstream commit, and add yours. But, I believe you should also (a) maintain the git author field from the original downstream commit (b) include a list of the changes you made to the patch in the commit description, so you can be blamed for them rather than the original author:-) 2) You read the downstream commit for information, but created a completely new driver for the upstream kernel, using the downstream driver just as a reference. In this case, I believe it's fine for the git author field to be you, and for the only s-o-b line present to be yours, since you really did write the patch from scratch. However, you should credit the downstream work in the (c) header and/or commit description. This current patch sees to be a slight hybrid of both approaches (you're listed as the git author, but have included Dom's s-o-b line on a patch I don't think he created, and wasn't directly derived from one he created). I'm not sure if I'm being too picky. I guess I'll leave it up to Wim Van Sebroeck, since he's the watchdog maintainer and would be the person who applies this patch. -- 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] ia64: Fix example error_injection_tool
I got a "sched_setaffinity:: Invalid argument" error when using err_injection_tool to inject error on a system with over 32 cpus. Error information when injecting an error on a system with over 32 cpus: $ ./err_injection_tool -i /sys/devices/system/cpu/cpu0/err_inject//err_type_info Begine at Tue Mar 26 11:20:08 2013 Configurations: On cpu32: loop=10, interval=5(s) err_type_info=4101,err_struct_info=95 Error sched_setaffinity:: Invalid argument All done This because there is overflow when calculating the cpumask: the type of (1< 31, (1< --- Documentation/ia64/err_inject.txt |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/ia64/err_inject.txt b/Documentation/ia64/err_inject.txt index 223e4f0..ec61ac1 100644 --- a/Documentation/ia64/err_inject.txt +++ b/Documentation/ia64/err_inject.txt @@ -882,7 +882,7 @@ int err_inj() cpu=parameters[i].cpu; k = cpu%64; j = cpu/64; - mask[j]=1
Re: [PATCH v9 RESEND 4/4] ARM: dts: add sram for imx53 and imx6q
On Wed, Mar 20, 2013 at 11:52:47AM +0100, Philipp Zabel wrote:
> Signed-off-by: Philipp Zabel
> Reviewed-by: Shawn Guo
> Acked-by: Grant Likely
> ---
> Changes since v8:
> - Changed device tree compatible string to "mmio-sram"
> ---
> arch/arm/boot/dts/imx53.dtsi |5 +
> arch/arm/boot/dts/imx6q.dtsi |6 ++
> 2 files changed, 11 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
> index edc3f1e..69d0680 100644
> --- a/arch/arm/boot/dts/imx53.dtsi
> +++ b/arch/arm/boot/dts/imx53.dtsi
> @@ -664,5 +664,10 @@
> status = "disabled";
> };
> };
> +
> + ocram: ocram@f800 {
> + compatible = "fsl,imx-ocram", "mmio-sram";
We should probably just drop "fsl,imx-ocram".
Shawn
> + reg = <0xf800 0x2>;
> + };
> };
> };
> diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> index ff1205e..73302db 100644
> --- a/arch/arm/boot/dts/imx6q.dtsi
> +++ b/arch/arm/boot/dts/imx6q.dtsi
> @@ -124,6 +124,12 @@
> status = "disabled";
> };
>
> + ocram: ocram@0090 {
> + compatible = "fsl,imx-ocram", "mmio-sram";
> + reg = <0x0090 0x3f000>;
> + clocks = <&clks 142>;
> + };
> +
> timer@00a00600 {
> compatible = "arm,cortex-a9-twd-timer";
> reg = <0x00a00600 0x20>;
> --
> 1.7.10.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/
Re: intel_pstate_timer_func divide by zero oops
Is there any way to capture the beginning of this trace? pid_param_set() is on the stack which means that something is changing the debugfs parameters or the stack is FUBAR. On 03/27/2013 06:49 PM, Parag Warudkar wrote: I get this same oops occassionally - the machine freezes and there doesn't seem to be any record of the oops on disk. That is - sample->pstate_pct_busy = 100 - div64_u64( sample->idletime_us * 100, sample->duration_us); I don't see how duration_us can be zero unless somehow I am getting back-to-back timer callbacks which seems unlikely since the timer is not re-armed until the timer function is about to return and the driver has done all its work for the sample period --Dirk So looks like sample->duration_us is 0? If so, that implies that ktime_us_delta(now, cpu->prev_sample) is zero. I am not entirely sure how to handle this case - return if sampling too early, or if there is some other bug making the delta calculation go poof. Thanks, Parag -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 1/2] ethernet: dm9000 driver: davicom: upgrade driver: 3rd trial
Dear Denis,
Yes, I can tell more detail, Should I re-do the patch and submit again?
I will revise the log as below: (Please help comment again, thanks.)
- Fixing bug for DM9000B(DSP) which is a DSP revision! 3rd trial.
-
- The chip of DM9000B(DSP) is different in internal PHY compare to
DM9000A(analog) and
- DM9000E(analog).
- This patch add a PHY RESET and a PHY INIT PARAMETER settings in
- "dm9000_init_dm9000()", and
- This patch change set DM9000_NCR by reset-bit to be set DM9000_NCR by
reset-bit
- conjunction with mac_loopback-bit in "dm9000_probe()".
- The driver could get wrong DM9000B FIFO(internal) state during driver
initialize, But not each
- target board case, error rate is around 2%.
- We patch the driver this way to solve this initial fatal issue.
Best Regards,
Joseph CHANG
System Application Engineering Division
Davicom Semiconductor, Inc.
No. 6 Li-Hsin Rd. VI, Science-Based Park,
Hsin-Chu, Taiwan.
Tel: 886-3-5798797 Ex 8534
Fax: 886-3-5646929
Web: http://www.davicom.com.tw
-Original Message-
From: Denis Kirjanov [mailto:k...@linux-powerpc.org]
Sent: Wednesday, March 27, 2013 9:14 PM
To: Joseph CHANG
Cc: David S. Miller; Bill Pemberton; Matthew Leach; Greg Kroah-Hartman; Joseph
CHANG; Jiri Pirko; net...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] ethernet: dm9000 driver: davicom: upgrade driver: 3rd
trial
It's not clear from your log what was wrong with the driver. Could you
please update the log message.
On 3/27/13, Joseph CHANG wrote:
> Fixing bug for DM9000B(DSP) which is a DSP revision! 3rd trial.
>
> Tested to Davicom DM9000 series include DM9000E(analog),
> DM9000A(analog), DM9000B(DSP), and DM9000C(DSP) in X86 and
> ARM Embedded Linux these years.
>
> Signed-off-by: Joseph CHANG
> ---
> drivers/net/ethernet/davicom/dm9000.c | 219
> +
> drivers/net/ethernet/davicom/dm9000.h | 11 ++-
> 2 files changed, 124 insertions(+), 106 deletions(-)
>
> diff --git a/drivers/net/ethernet/davicom/dm9000.c
> b/drivers/net/ethernet/davicom/dm9000.c
> index 8cdf025..9dd4bd6 100644
> --- a/drivers/net/ethernet/davicom/dm9000.c
> +++ b/drivers/net/ethernet/davicom/dm9000.c
> @@ -47,7 +47,7 @@
> #define DM9000_PHY 0x40/* PHY address 0x01 */
>
> #define CARDNAME "dm9000"
> -#define DRV_VERSION "1.31"
> +#define DRV_VERSION "1.39"
>
> /*
> * Transmit timeout, default 5 seconds.
> @@ -257,6 +257,109 @@ static void dm9000_dumpblk_32bit(void __iomem *reg,
> int count)
> tmp = readl(reg);
> }
>
> +/*
> + * Sleep, either by using msleep() or if we are suspending, then
> + * use mdelay() to sleep.
> + */
> +static void dm9000_msleep(board_info_t *db, unsigned int ms)
> +{
> + if (db->in_suspend)
> + mdelay(ms);
> + else
> + msleep(ms);
> +}
> +
> +/*
> + * Read a word from phyxcer
> + */
> +static int
> +dm9000_phy_read(struct net_device *dev, int phy_reg_unused, int reg)
> +{
> + board_info_t *db = netdev_priv(dev);
> + unsigned long flags;
> + unsigned int reg_save;
> + int ret;
> +
> + mutex_lock(&db->addr_lock);
> +
> + spin_lock_irqsave(&db->lock,flags);
> +
> + /* Save previous register address */
> + reg_save = readb(db->io_addr);
> +
> + /* Fill the phyxcer register into REG_0C */
> + iow(db, DM9000_EPAR, DM9000_PHY | reg);
> +
> + iow(db, DM9000_EPCR, EPCR_ERPRR | EPCR_EPOS); /* Issue phyxcer read
> command */
> +
> + writeb(reg_save, db->io_addr);
> + spin_unlock_irqrestore(&db->lock,flags);
> +
> + dm9000_msleep(db, 1); /* Wait read complete */
> +
> + spin_lock_irqsave(&db->lock,flags);
> + reg_save = readb(db->io_addr);
> +
> + iow(db, DM9000_EPCR, 0x0); /* Clear phyxcer read command */
> +
> + /* The read data keeps on REG_0D & REG_0E */
> + ret = (ior(db, DM9000_EPDRH) << 8) | ior(db, DM9000_EPDRL);
> +
> + /* restore the previous address */
> + writeb(reg_save, db->io_addr);
> + spin_unlock_irqrestore(&db->lock,flags);
> +
> + mutex_unlock(&db->addr_lock);
> +
> + dm9000_dbg(db, 5, "phy_read[%02x] -> %04x\n", reg, ret);
> + return ret;
> +}
> +
> +/*
> + * Write a word to phyxcer
> + */
> +static void
> +dm9000_phy_write(struct net_device *dev,
> + int phyaddr_unused, int reg, int value)
> +{
> + board_info_t *db = netdev_priv(dev);
> + unsigned long flags;
> + unsigned long reg_save;
> +
> + dm9000_dbg(db, 5, "phy_write[%02x] = %04x\n", reg, value);
> + mutex_lock(&db->addr_lock);
> +
> + spin_lock_irqsave(&db->lock,flags);
> +
> + /* Save previous register address */
> + reg_save = readb(db->io_addr);
> +
> + /* Fill the phyxcer register into REG_0C */
> + iow(db, DM9000_EPAR, DM9000_PHY | reg);
> +
> + /* Fill the written data into REG_0D & REG_0E */
> + iow(db, DM9000_EPDRL, value);
> + iow(db, DM9000_EPDRH, value >> 8);
> +
> + iow(db, DM
Re: [PATCH v7 5/5] hwmon: add ST-Ericsson ABX500 hwmon driver
On 28 March 2013 03:48, Guenter Roeck wrote: > On Wed, Mar 27, 2013 at 03:13:32PM +0800, Hongbo Zhang wrote: >> Each of ST-Ericsson X500 chip set series consists of both ABX500 and DBX500 >> chips. This is ABX500 hwmon driver, where the abx500.c is a common layer for >> all ABX500s, and the ab8500.c is specific for AB8500 chip. Under this >> designed >> structure, other chip specific files can be added simply using the same >> common >> layer abx500.c. >> >> Signed-off-by: Hongbo Zhang > > Reviewed-by: Guenter Roeck Thank you very much, Guenter. -- 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] i2c: remove CONFIG_HOTPLUG ifdefs
CONFIG_HOTPLUG is going away as an option, cleanup CONFIG_HOTPLUG
ifdefs in i2c files.
Signed-off-by: Yijing Wang
---
drivers/i2c/i2c-core.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 991d38d..d1db97e 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -91,7 +91,6 @@ static int i2c_device_match(struct device *dev, struct
device_driver *drv)
return 0;
}
-#ifdef CONFIG_HOTPLUG
/* uevent helps with hotplug: modprobe -q $(MODALIAS) */
static int i2c_device_uevent(struct device *dev, struct kobj_uevent_env *env)
@@ -105,10 +104,6 @@ static int i2c_device_uevent(struct device *dev, struct
kobj_uevent_env *env)
return 0;
}
-#else
-#define i2c_device_uevent NULL
-#endif /* CONFIG_HOTPLUG */
-
static int i2c_device_probe(struct device *dev)
{
struct i2c_client *client = i2c_verify_client(dev);
--
1.7.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 1/2] mm: remove CONFIG_HOTPLUG ifdefs
CONFIG_HOTPLUG is going away as an option, cleanup CONFIG_HOTPLUG
ifdefs in mm files.
Signed-off-by: Yijing Wang
Cc: Minchan Kim
Cc: Mel Gorman
Cc: Bartlomiej Zolnierkiewicz
Cc: Rik van Riel
Cc: Hugh Dickins
Cc: Bill Pemberton
Cc: Greg Kroah-Hartman
---
include/linux/vmstat.h |7 +--
mm/vmstat.c|2 --
2 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
index 5fd71a7..c586679 100644
--- a/include/linux/vmstat.h
+++ b/include/linux/vmstat.h
@@ -48,13 +48,8 @@ static inline void count_vm_events(enum vm_event_item item,
long delta)
}
extern void all_vm_events(unsigned long *);
-#ifdef CONFIG_HOTPLUG
+
extern void vm_events_fold_cpu(int cpu);
-#else
-static inline void vm_events_fold_cpu(int cpu)
-{
-}
-#endif
#else
diff --git a/mm/vmstat.c b/mm/vmstat.c
index e1d8ed1..c823776 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -52,7 +52,6 @@ void all_vm_events(unsigned long *ret)
}
EXPORT_SYMBOL_GPL(all_vm_events);
-#ifdef CONFIG_HOTPLUG
/*
* Fold the foreign cpu events into our own.
*
@@ -69,7 +68,6 @@ void vm_events_fold_cpu(int cpu)
fold_state->event[i] = 0;
}
}
-#endif /* CONFIG_HOTPLUG */
#endif /* CONFIG_VM_EVENT_COUNTERS */
--
1.7.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 V7 0/5] virtio-scsi multiqueue
On 03/23/2013 07:28 PM, Wanlong Gao wrote: > This series implements virtio-scsi queue steering, which gives > performance improvements of up to 50% (measured both with QEMU and > tcm_vhost backends). > > This version rebased on Rusty's virtio ring rework patches, which > has already gone into virtio-next today. > We hope this can go into virtio-next together with the virtio ring > rework pathes. > > V7: respin to fix the patch apply error > > V6: rework "redo allocation of target data" (James) > fix comments (Venkatesh) > rebase to virtio-next > > V5: improving the grammar of 1/5 (Paolo) > move the dropping of sg_elems to 'virtio-scsi: use virtqueue_add_sgs for > command buffers'. (Asias) > > V4: rebase on virtio ring rework patches (rusty's pending-rebases branch) > > V3 and be found http://marc.info/?l=linux-virtualization&m=136067440717154&w=2 > > > It would probably be easier to get it in via Rusty's tree > because of the prerequisites. James, can we get your Acked-by? James, any thoughts for this version? Thanks, Wanlong Gao > > Paolo Bonzini (3): > virtio-scsi: pass struct virtio_scsi to virtqueue completion function > virtio-scsi: push vq lock/unlock into virtscsi_vq_done > virtio-scsi: introduce multiqueue support > > Wanlong Gao (2): > virtio-scsi: redo allocation of target data > virtio-scsi: reset virtqueue affinity when doing cpu hotplug > > drivers/scsi/virtio_scsi.c | 387 > - > 1 file changed, 309 insertions(+), 78 deletions(-) > -- 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: Davicom Linux driver
This is not the correct way to submit a patch for inclusion upstream You should post each patch in a seperate, numbered, list posting, in plain ASCII text, and not as an attachment. -- 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] cpufreq: cpufreq-cpu0: use the exact frequency for clk_set_rate()
On Wed, Mar 27, 2013 at 11:46:38PM +0100, Guennadi Liakhovetski wrote: > Hi Shawn > > On Mon, 25 Feb 2013, Guennadi Liakhovetski wrote: > > > clk_set_rate() isn't supposed to accept approximate frequencies, instead > > a supported frequency should be obtained from clk_round_rate() and then > > used to set the clock. > > > > Signed-off-by: Guennadi Liakhovetski > > Can I have your ack for this one, please? Acked-by: Shawn Guo -- 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: [RFC] mm: remove swapcache page early
On Thu, Mar 28, 2013 at 10:18:24AM +0900, Minchan Kim wrote: > On Wed, Mar 27, 2013 at 04:16:48PM -0700, Hugh Dickins wrote: > > On Wed, 27 Mar 2013, Dan Magenheimer wrote: > > > > From: Hugh Dickins [mailto:hu...@google.com] > > > > Subject: Re: [RFC] mm: remove swapcache page early > > > > > > > > On Wed, 27 Mar 2013, Minchan Kim wrote: > > > > > > > > > Swap subsystem does lazy swap slot free with expecting the page > > > > > would be swapped out again so we can't avoid unnecessary write. > > > > so we can avoid unnecessary write. > > > > > > > > > > But the problem in in-memory swap is that it consumes memory space > > > > > until vm_swap_full(ie, used half of all of swap device) condition > > > > > meet. It could be bad if we use multiple swap device, small in-memory > > > > > swap > > > > > and big storage swap or in-memory swap alone. > > > > > > > > That is a very good realization: it's surprising that none of us > > > > thought of it before - no disrespect to you, well done, thank you. > > > > > > Yes, my compliments also Minchan. This problem has been thought of before > > > but this patch is the first to identify a possible solution. > > > > > > > And I guess swap readahead is utterly unhelpful in this case too. > > > > > > Yes... as is any "swap writeahead". Excuse my ignorance, but I > > > think this is not done in the swap subsystem but instead the kernel > > > assumes write-coalescing will be done in the block I/O subsystem, > > > which means swap writeahead would affect zram but not zcache/zswap > > > (since frontswap subverts the block I/O subsystem). > > > > I don't know what swap writeahead is; but write coalescing, yes. > > I don't see any problem with it in this context. > > > > > > > > However I think a swap-readahead solution would be helpful to > > > zram as well as zcache/zswap. > > > > Whereas swap readahead on zmem is uncompressing zmem to pagecache > > which may never be needed, and may take a circuit of the inactive > > LRU before it gets reclaimed (if it turns out not to be needed, > > at least it will remain clean and be easily reclaimed). > > But it could evict more important pages before reaching out the tail. > That's thing we really want to avoid if possible. > > > > > > > > > > > This patch changes vm_swap_full logic slightly so it could free > > > > > swap slot early if the backed device is really fast. > > > > > For it, I used SWP_SOLIDSTATE but It might be controversial. > > > > > > > > But I strongly disagree with almost everything in your patch :) > > > > I disagree with addressing it in vm_swap_full(), I disagree that > > > > it can be addressed by device, I disagree that it has anything to > > > > do with SWP_SOLIDSTATE. > > > > > > > > This is not a problem with swapping to /dev/ram0 or to /dev/zram0, > > > > is it? In those cases, a fixed amount of memory has been set aside > > > > for swap, and it works out just like with disk block devices. The > > > > memory set aside may be wasted, but that is accepted upfront. > > > > > > It is (I believe) also a problem with swapping to ram. Two > > > copies of the same page are kept in memory in different places, > > > right? Fixed vs variable size is irrelevant I think. Or am > > > I misunderstanding something about swap-to-ram? > > > > I may be misrembering how /dev/ram0 works, or simply assuming that > > if you want to use it for swap (interesting for testing, but probably > > not for general use), then you make sure to allocate each page of it > > in advance. > > > > The pages of /dev/ram0 don't get freed, or not before it's closed > > (swapoff'ed) anyway. Yes, swapcache would be duplicating data from > > other memory into /dev/ram0 memory; but that /dev/ram0 memory has > > been set aside for this purpose, and removing from swapcache won't > > free any more memory. > > > > > > > > > Similarly, this is not a problem with swapping to SSD. There might > > > > or might not be other reasons for adjusting the vm_swap_full() logic > > > > for SSD or generally, but those have nothing to do with this issue. > > > > > > I think it is at least highly related. The key issue is the > > > tradeoff of the likelihood that the page will soon be read/written > > > again while it is in swap cache vs the time/resource-usage necessary > > > to "reconstitute" the page into swap cache. Reconstituting from disk > > > requires a LOT of elapsed time. Reconstituting from > > > an SSD likely takes much less time. Reconstituting from > > > zcache/zram takes thousands of CPU cycles. > > > > I acknowledge my complete ignorance of how to judge the tradeoff > > between memory usage and cpu usage, but I think Minchan's main > > concern was with the memory usage. Neither hard disk nor SSD > > is occupying memory. > > Hmm, It seems I misunderstood Dan's opinion in previous thread. > You're right, Hugh. My main concern is memory usage but the rationale > I used SWP_SOLIDSTATE is writing
