Re: [hyperv] BUG at drivers/hv/channel.c:462 while changing MTU
via On Wed, Aug 20, 2014 at 5:41 AM, Sitsofe Wheeler wrote: > Aug 20 04:04:41 ubuntuhv kernel: [9.230399] random: nonblocking pool is > initialized > Aug 20 04:04:41 ubuntuhv kernel: [ 10.338487] EXT4-fs (sda1): re-mounted. > Opts: errors=remount-ro > Aug 20 04:04:41 ubuntuhv kernel: [ 11.099094] hv_storvsc vmbus_0_1: cmd > 0x85 scsi status 0x2 srb status 0x6 > Aug 20 04:04:41 ubuntuhv kernel: [ 11.099901] hv_storvsc vmbus_0_1: cmd > 0x85 scsi status 0x2 srb status 0x6 > Aug 20 04:04:43 ubuntuhv kernel: [ 12.999830] psmouse serio1: trackpoint: > IBM TrackPoint firmware: 0x01, buttons: 0/0 > Aug 20 03:55:47 ubuntuhv kernel: [ 13.003659] input: TPPS/2 IBM TrackPoint > as /devices/platform/i8042/serio1/input/input4 > Aug 20 03:57:28 ubuntuhv kernel: [ 113.711832] hv_netvsc vmbus_0_14: net > device safe to remove > Aug 20 03:57:28 ubuntuhv kernel: [ 113.713882] hv_netvsc: hv_netvsc channel > opened successfully > Aug 20 03:57:29 ubuntuhv kernel: [ 114.961312] hv_netvsc vmbus_0_14: Send > section size: 6144, Section count:2560 > Aug 20 03:57:29 ubuntuhv kernel: [ 114.962711] hv_netvsc vmbus_0_14: Device > MAC 00:15:5d:6f:02:af link state up > Aug 20 03:57:34 ubuntuhv kernel: [ 120.027718] hv_netvsc vmbus_0_14: net > device safe to remove > Aug 20 03:57:34 ubuntuhv kernel: [ 120.030047] hv_netvsc: hv_netvsc channel > opened successfully > Aug 20 03:57:34 ubuntuhv kernel: [ 120.035422] hv_netvsc vmbus_0_14 eth0: > unable to establish receive buffer's gpadl > Aug 20 03:57:34 ubuntuhv kernel: [ 120.039778] hv_netvsc vmbus_0_14 eth0: > unable to connect to NetVSP - 4 > Aug 20 03:57:34 ubuntuhv kernel: [ 120.039818] [ cut here > ] > Aug 20 03:57:34 ubuntuhv kernel: [ 120.039832] kernel BUG at > drivers/hv/channel.c:504! This is one is also a rude BUG_ON: ret = vmbus_post_msg(msg, sizeof(struct vmbus_channel_close_channel)); BUG_ON(ret != 0); vmbus_post_msg() hv_post_message() can easily return !0. i.e. if this kmalloc() fails: addr = (unsigned long)kmalloc(sizeof(struct aligned_input), GFP_ATOMIC); if (!addr) return -ENOMEM; -- Thanks, //richard -- 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/1] do_exit(): Solve possibility of BUG() due to race with try_to_wake_up()
I encountered a BUG() scenario within do_exit() on an ARM system. The problem is due to a race scenario between do_exit() and try_to_wake_up() on different CPUs due to usage of sleeping primitives such as __down_common and wait_for_common. Race Scenario = Let us assume there are 2 CPUs A and B execute code in the following order: 1) CPU A was running in user-mode and enters kernel mode via some syscall/exception handler. 2) CPU A sets the current task(t) state to TASK_INTERRUPTIBLE via __down_common or wait_for_common. 3) CPU A checks for signal_pending() and returns due to TIF_SIGPENDING being set in t's threadinfo due to a previous signal(say SIGKILL) being received on this task t. 4) CPU A returns returns back to the assembly trap handler and calls do_work_pending() -> do_signal() -> get_signal() -> do_group_exit() -> do_exit() CPU A has not yet executed the following line of code before the final call to schedule: /* causes final put_task_struct in finish_task_switch(). */ tsk->state = TASK_DEAD; 5) CPU B tries to send a signal to task t (currently executing on CPU A) and thus enters: signal_wake_up_state() -> wake_up_state() -> try_to_wake_up() 6) CPU B executes all code in try_to_wake_up() till the call to ttwu_queue -> ttwu_do_activate -> ttwu_do_wakeup(). CPU B has still not executed the following code in ttwu_do_wakeup(): p->state = TASK_RUNNING; 7) CPU A executes the following line of code: /* causes final put_task_struct in finish_task_switch(). */ tsk->state = TASK_DEAD; 8) CPU B executes the following code in ttwu_do_wakeup(): p->state = TASK_RUNNING; 9) CPU A continues to the call to do_exit() -> schedule(). Since the tsk->state is TASK_RUNNING, the call to schedule() returns and do_exit() -> BUG() is hit on CPU A. Alternate Solution == An alternate solution would be to simply set the current task state to TASK_RUNNING in __down_common(), wait_for_common() and all other interruptible sleeping primitives in their if(signal_pending/signal_pending_state) conditional blocks. But this change seems to me to be more logical because: i) This will involve lesser changes to the kernel core code. ii) Any further sleeping primitives in the kernel also need not suffer from this kind of race scenario. Signed-off-by: Kautuk Consul --- kernel/exit.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/kernel/exit.c b/kernel/exit.c index 32c58f7..69a8231 100644 --- a/kernel/exit.c +++ b/kernel/exit.c @@ -824,14 +824,16 @@ void do_exit(long code) * (or hypervisor of virtual machine switches to other guest) * As a result, we may become TASK_RUNNING after becoming TASK_DEAD * -* To avoid it, we have to wait for releasing tsk->pi_lock which -* is held by try_to_wake_up() +* To solve this, we have to compete for tsk->pi_lock which is held by +* try_to_wake_up(). */ - smp_mb(); - raw_spin_unlock_wait(>pi_lock); + raw_spin_lock(>pi_lock); /* causes final put_task_struct in finish_task_switch(). */ tsk->state = TASK_DEAD; + + raw_spin_unlock(>pi_lock); + tsk->flags |= PF_NOFREEZE; /* tell freezer to ignore us */ schedule(); BUG(); -- 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/
[RFC PATCH 2/5] module: Unlink module with RCU synchronizing instead of stop_machine
Unlink module from module list with RCU synchronizing instead
of using stop_machine(). Since module list is already protected
by rcu, we don't need stop_machine() anymore.
Signed-off-by: Masami Hiramatsu
---
kernel/module.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/kernel/module.c b/kernel/module.c
index 4c8a4f1..84b068d 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1697,18 +1697,6 @@ static void mod_sysfs_teardown(struct module *mod)
mod_sysfs_fini(mod);
}
-/*
- * unlink the module with the whole machine is stopped with interrupts off
- * - this defends against kallsyms not taking locks
- */
-static int __unlink_module(void *_mod)
-{
- struct module *mod = _mod;
- list_del(>list);
- module_bug_cleanup(mod);
- return 0;
-}
-
#ifdef CONFIG_DEBUG_SET_MODULE_RONX
/*
* LKM RO/NX protection: protect module's text/ro-data
@@ -1858,7 +1846,11 @@ static void free_module(struct module *mod)
/* Now we can delete it from the lists */
mutex_lock(_mutex);
- stop_machine(__unlink_module, mod, NULL);
+ /* Unlink carefully: kallsyms could be walking list. */
+ list_del_rcu(>list);
+ /* Wait for RCU synchronizing before releasing mod->list. */
+ synchronize_rcu();
+ module_bug_cleanup(mod);
mutex_unlock(_mutex);
/* This may be NULL, but that's OK */
--
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/
[RFC PATCH 1/5] module: Wait for RCU synchronizing before releasing a module
Wait for RCU synchronizing on failure path of module loading before releasing struct module, because the memory of mod->list can still be accessed by list walkers (e.g. kallsyms). Signed-off-by: Masami Hiramatsu --- kernel/module.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/module.c b/kernel/module.c index 03214bd2..4c8a4f1 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -3324,6 +3324,8 @@ static int load_module(struct load_info *info, const char __user *uargs, /* Unlink carefully: kallsyms could be walking list. */ list_del_rcu(>list); wake_up_all(_wq); + /* Wait for RCU synchronizing before releasing mod->list. */ + synchronize_rcu(); mutex_unlock(_mutex); free_module: module_deallocate(mod, info); -- 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/
[RFC PATCH 0/5] module: Remove stop_machine from module unloading
Hi, Here is a series of patches which remove stop_machine() from module unloading. Currently, each module unloading calls stop_machine()s 2 times. One is for safely removing module from lists and one is to check the reference counter. However, both are not necessary for those purposes (required by current implementation). First, we can use RCU for the list operation, we just need a synchronize_rcu right before cleaning up. Second, the reference counter can be checked atomically by using atomic_t, instead of per-cpu module_ref. Of course, for BIG SMP machines, atomic operation is not efficient. However, they usually don't need to remove most of modules too. In this series, I just fixed to use RCU for the module(and bugs) list for the first stop_machine. And for the second one, I replaced module_ref with atomic_t and introduced a "module lockup" module load option, which makes a module un-removable (lock up the module in kernel). The lockup modules can not be removed except forced, and the kernel skips module refcounting on those modules. Thus we can minimize the performance impact on the BIG SMP machines. BTW, of course this requires to update libkmod to support new MODULE_INIT_LOCKUP_MODULE flag. I'm not sure where is good to send the patches I have. Sould I better sending kmod patches on LKML? Thank you, --- Masami Hiramatsu (5): module: Wait for RCU synchronizing before releasing a module module: Unlink module with RCU synchronizing instead of stop_machine lib/bug: Use RCU list ops for module_bug_list module: Lock up a module when loading with a LOCLUP flag module: Remove stop_machine from module unloading include/linux/module.h| 22 ++ include/trace/events/module.h |2 - include/uapi/linux/module.h |1 kernel/module.c | 147 + lib/bug.c | 20 -- 5 files changed, 85 insertions(+), 107 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/
[RFC PATCH 4/5] module: Lock up a module when loading with a LOCLUP flag
Lock-up a module in kernel so that it is not removed unless
forcibly unload. This is done by loading a module with
MODULE_INIT_LOCKUP_MODULE flag (via finit_module).
This speeds up try_module_get by skipping refcount inc/dec for
the locked modules.
Note that this flag requires to update libkmod to support it.
Signed-off-by: Masami Hiramatsu
---
include/linux/module.h |6 ++
include/uapi/linux/module.h |1 +
kernel/module.c | 28
3 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index 71f282a..670cb2e 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -205,6 +205,7 @@ struct module_use {
enum module_state {
MODULE_STATE_LIVE, /* Normal state. */
+ MODULE_STATE_LOCKUP,/* Module is never removed except forced */
MODULE_STATE_COMING,/* Full formed, running module_init. */
MODULE_STATE_GOING, /* Going away. */
MODULE_STATE_UNFORMED, /* Still setting it up. */
@@ -390,6 +391,11 @@ static inline int module_is_live(struct module *mod)
return mod->state != MODULE_STATE_GOING;
}
+static inline int module_is_locked(struct module *mod)
+{
+ return mod->state == MODULE_STATE_LOCKUP;
+}
+
struct module *__module_text_address(unsigned long addr);
struct module *__module_address(unsigned long addr);
bool is_module_address(unsigned long addr);
diff --git a/include/uapi/linux/module.h b/include/uapi/linux/module.h
index 38da425..8195603 100644
--- a/include/uapi/linux/module.h
+++ b/include/uapi/linux/module.h
@@ -4,5 +4,6 @@
/* Flags for sys_finit_module: */
#define MODULE_INIT_IGNORE_MODVERSIONS 1
#define MODULE_INIT_IGNORE_VERMAGIC2
+#define MODULE_INIT_LOCKUP_MODULE 4
#endif /* _UAPI_LINUX_MODULE_H */
diff --git a/kernel/module.c b/kernel/module.c
index 3bd0dc9..85ffc1d 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -753,7 +753,7 @@ static int __try_stop_module(void *_sref)
struct stopref *sref = _sref;
/* If it's not unused, quit unless we're forcing. */
- if (module_refcount(sref->mod) != 0) {
+ if (module_is_locked(sref->mod) || module_refcount(sref->mod) != 0) {
if (!(*sref->forced = try_force_unload(sref->flags)))
return -EWOULDBLOCK;
}
@@ -830,7 +830,8 @@ SYSCALL_DEFINE2(delete_module, const char __user *,
name_user,
}
/* Doing init or already dying? */
- if (mod->state != MODULE_STATE_LIVE) {
+ if (mod->state != MODULE_STATE_LIVE &&
+ mod->state != MODULE_STATE_LOCKUP) {
/* FIXME: if (force), slam module count damn the torpedoes */
pr_debug("%s already dying\n", mod->name);
ret = -EBUSY;
@@ -947,6 +948,9 @@ bool try_module_get(struct module *module)
bool ret = true;
if (module) {
+ if (module_is_locked(module))
+ goto end;
+
preempt_disable();
if (likely(module_is_live(module))) {
@@ -957,13 +961,14 @@ bool try_module_get(struct module *module)
preempt_enable();
}
+end:
return ret;
}
EXPORT_SYMBOL(try_module_get);
void module_put(struct module *module)
{
- if (module) {
+ if (module && !module_is_locked(module)) {
preempt_disable();
smp_wmb(); /* see comment in module_refcount */
__this_cpu_inc(module->refptr->decs);
@@ -1026,6 +1031,7 @@ static ssize_t show_initstate(struct module_attribute
*mattr,
switch (mk->mod->state) {
case MODULE_STATE_LIVE:
+ case MODULE_STATE_LOCKUP:
state = "live";
break;
case MODULE_STATE_COMING:
@@ -2981,6 +2987,7 @@ static bool finished_loading(const char *name)
mutex_lock(_mutex);
mod = find_module_all(name, strlen(name), true);
ret = !mod || mod->state == MODULE_STATE_LIVE
+ || mod->state == MODULE_STATE_LOCKUP
|| mod->state == MODULE_STATE_GOING;
mutex_unlock(_mutex);
@@ -2999,7 +3006,7 @@ static void do_mod_ctors(struct module *mod)
}
/* This is where the real work happens */
-static int do_init_module(struct module *mod)
+static int do_init_module(struct module *mod, bool locked)
{
int ret = 0;
@@ -3034,7 +3041,7 @@ static int do_init_module(struct module *mod)
}
/* Now it's a first class citizen! */
- mod->state = MODULE_STATE_LIVE;
+ mod->state = locked ? MODULE_STATE_LOCKUP : MODULE_STATE_LIVE;
blocking_notifier_call_chain(_notify_list,
MODULE_STATE_LIVE, mod);
@@ -3290,7 +3297,7 @@ static int load_module(struct load_info *info, const char
__user *uargs,
/* Done! */
trace_module_load(mod);
- return do_init_module(mod);
+ return
[RFC PATCH 3/5] lib/bug: Use RCU list ops for module_bug_list
Actually since module_bug_list should be used in BUG context,
we may not need this. But for someone who want to use this
from normal context, this makes module_bug_list an RCU list.
Signed-off-by: Masami Hiramatsu
---
kernel/module.c |5 +++--
lib/bug.c | 20 ++--
2 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/kernel/module.c b/kernel/module.c
index 84b068d..3bd0dc9 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1848,9 +1848,10 @@ static void free_module(struct module *mod)
mutex_lock(_mutex);
/* Unlink carefully: kallsyms could be walking list. */
list_del_rcu(>list);
- /* Wait for RCU synchronizing before releasing mod->list. */
- synchronize_rcu();
+ /* Remove this module from bug list, this uses list_del_rcu */
module_bug_cleanup(mod);
+ /* Wait for RCU synchronizing before releasing mod->list and buglist. */
+ synchronize_rcu();
mutex_unlock(_mutex);
/* This may be NULL, but that's OK */
diff --git a/lib/bug.c b/lib/bug.c
index d1d7c78..0c3bd95 100644
--- a/lib/bug.c
+++ b/lib/bug.c
@@ -64,16 +64,22 @@ static LIST_HEAD(module_bug_list);
static const struct bug_entry *module_find_bug(unsigned long bugaddr)
{
struct module *mod;
+ const struct bug_entry *bug = NULL;
- list_for_each_entry(mod, _bug_list, bug_list) {
- const struct bug_entry *bug = mod->bug_table;
+ rcu_read_lock();
+ list_for_each_entry_rcu(mod, _bug_list, bug_list) {
unsigned i;
+ bug = mod->bug_table;
for (i = 0; i < mod->num_bugs; ++i, ++bug)
if (bugaddr == bug_addr(bug))
- return bug;
+ goto out;
}
- return NULL;
+ bug = NULL;
+out:
+ rcu_read_unlock();
+
+ return bug;
}
void module_bug_finalize(const Elf_Ehdr *hdr, const Elf_Shdr *sechdrs,
@@ -99,13 +105,15 @@ void module_bug_finalize(const Elf_Ehdr *hdr, const
Elf_Shdr *sechdrs,
* Strictly speaking this should have a spinlock to protect against
* traversals, but since we only traverse on BUG()s, a spinlock
* could potentially lead to deadlock and thus be counter-productive.
+* Thus, this uses RCU to safely manipulate the bug list, since BUG
+* must run in non-interruptive state.
*/
- list_add(>bug_list, _bug_list);
+ list_add_rcu(>bug_list, _bug_list);
}
void module_bug_cleanup(struct module *mod)
{
- list_del(>bug_list);
+ list_del_rcu(>bug_list);
}
#else
--
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/
[RFC PATCH 5/5] module: Remove stop_machine from module unloading
Remove stop_machine from module unloading by replacing module_ref
with atomic_t. Note that this can cause a performance regression
on big-SMP machine by direct memory access. For those machines,
you can lockdwon all modules. Since the lockdown skips reference
counting, it'll be more scalable than per-cpu module_ref counters.
Signed-off-by: Masami Hiramatsu
Cc: Rusty Russell
---
include/linux/module.h| 16 --
include/trace/events/module.h |2 -
kernel/module.c | 108 +++--
3 files changed, 41 insertions(+), 85 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index 670cb2e..3ebe049 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -211,20 +211,6 @@ enum module_state {
MODULE_STATE_UNFORMED, /* Still setting it up. */
};
-/**
- * struct module_ref - per cpu module reference counts
- * @incs: number of module get on this cpu
- * @decs: number of module put on this cpu
- *
- * We force an alignment on 8 or 16 bytes, so that alloc_percpu()
- * put @incs/@decs in same cache line, with no extra memory cost,
- * since alloc_percpu() is fine grained.
- */
-struct module_ref {
- unsigned long incs;
- unsigned long decs;
-} __attribute((aligned(2 * sizeof(unsigned long;
-
struct module {
enum module_state state;
@@ -368,7 +354,7 @@ struct module {
/* Destruction function. */
void (*exit)(void);
- struct module_ref __percpu *refptr;
+ atomic_t refcnt;
#endif
#ifdef CONFIG_CONSTRUCTORS
diff --git a/include/trace/events/module.h b/include/trace/events/module.h
index 7c5cbfe..81c4c18 100644
--- a/include/trace/events/module.h
+++ b/include/trace/events/module.h
@@ -80,7 +80,7 @@ DECLARE_EVENT_CLASS(module_refcnt,
TP_fast_assign(
__entry->ip = ip;
- __entry->refcnt = __this_cpu_read(mod->refptr->incs) -
__this_cpu_read(mod->refptr->decs);
+ __entry->refcnt = atomic_read(>refcnt);
__assign_str(name, mod->name);
),
diff --git a/kernel/module.c b/kernel/module.c
index 85ffc1d..7af6ff7 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -42,7 +42,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -98,7 +97,7 @@
* 1) List of modules (also safely readable with preempt_disable),
* 2) module_use links,
* 3) module_addr_min/module_addr_max.
- * (delete uses stop_machine/add uses RCU list operations). */
+ * (delete and add uses RCU list operations). */
DEFINE_MUTEX(module_mutex);
EXPORT_SYMBOL_GPL(module_mutex);
static LIST_HEAD(modules);
@@ -628,18 +627,26 @@ static char last_unloaded_module[MODULE_NAME_LEN+1];
EXPORT_TRACEPOINT_SYMBOL(module_get);
+/*
+ * MODULE_REF_BASE must be 1, since we use atomic_inc_not_zero() for
+ * recovering refcnt (see try_release_module_ref() ).
+ */
+#define MODULE_REF_BASE1
+
/* Init the unload section of the module. */
static int module_unload_init(struct module *mod)
{
- mod->refptr = alloc_percpu(struct module_ref);
- if (!mod->refptr)
- return -ENOMEM;
+ /*
+* Initialize reference counter to MODULE_REF_BASE.
+* refcnt == 0 means module is going.
+*/
+ atomic_set(>refcnt, MODULE_REF_BASE);
INIT_LIST_HEAD(>source_list);
INIT_LIST_HEAD(>target_list);
/* Hold reference count during initialization. */
- raw_cpu_write(mod->refptr->incs, 1);
+ atomic_inc(>refcnt);
return 0;
}
@@ -721,8 +728,6 @@ static void module_unload_free(struct module *mod)
kfree(use);
}
mutex_unlock(_mutex);
-
- free_percpu(mod->refptr);
}
#ifdef CONFIG_MODULE_FORCE_UNLOAD
@@ -740,60 +745,38 @@ static inline int try_force_unload(unsigned int flags)
}
#endif /* CONFIG_MODULE_FORCE_UNLOAD */
-struct stopref
+/* Try to release refcount of module, 0 means success. */
+static int try_release_module_ref(struct module *mod)
{
- struct module *mod;
- int flags;
- int *forced;
-};
+ int ret;
-/* Whole machine is stopped with interrupts off when this runs. */
-static int __try_stop_module(void *_sref)
-{
- struct stopref *sref = _sref;
+ /* Try to decrement refcnt which we set at loading */
+ ret = atomic_sub_return(MODULE_REF_BASE, >refcnt);
+ if (ret)
+ /* Someone can put this right now, recover with checking */
+ ret = atomic_inc_not_zero(>refcnt);
+
+ return ret;
+}
+static int try_stop_module(struct module *mod, int flags, int *forced)
+{
/* If it's not unused, quit unless we're forcing. */
- if (module_is_locked(sref->mod) || module_refcount(sref->mod) != 0) {
- if (!(*sref->forced = try_force_unload(sref->flags)))
+ if (module_is_locked(mod) || try_release_module_ref(mod) != 0) {
+ *forced =
Re: Loading initrd above 4G causes freeze on boot
On Sun, 24 Aug, at 10:19:04PM, Mantas Mikulėnas wrote: > > Finally got around to testing it, and yes, your patch fixes the initrd > boot for me. Could you found out where the initrd gets loaded with this patch? It'll be in the dmesg. -- Matt Fleming, Intel Open Source Technology Center -- 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 v3] zram: add num_discards for discarded pages stat
Hello,
On (08/25/14 09:36), Minchan Kim wrote:
> Hello Chao,
>
> On Fri, Aug 22, 2014 at 04:21:01PM +0800, Chao Yu wrote:
> > Since we have supported handling discard request in this commit
> > f4659d8e620d08bd1a84a8aec5d2f5294a242764 (zram: support REQ_DISCARD), zram
> > got
> > one more chance to free unused memory whenever received discard request. But
> > without stating for discard request, there is no method for user to know
> > whether
> > discard request has been handled by zram or how many blocks were discarded
> > by
> > zram when user wants to know the effect of discard.
>
> My concern is that how much we are able to know the effect of discard
> exactly with your patch.
>
> The issue I can think of is zram-swap discard.
> Now, zram handles notification from VM to free duplicated copy between
> VM-owned memory and zRAM-owned's one so discarding for zram-swap might
> be pointless overhead but your stat indicates lots of free page discarded
> without real freeing
this is why I've moved stats accounting to the place where actual
zs_free() happens. and, frankly, I still would like to see the number
of zs_free() calls, rather than the number of slot free notifications
and REQ_DISCARD (or separately), because they all end up calling
zs_free(). iow, despite the call path, from the user point of view
they are just zs_free() -- the number of pages that's been freed by
the 3rd party and we had have to deal with that.
> so that user might think "We should keep enable
> swap discard for zRAM because the stat indicates it's really good".
>
> In summary, wouldn't it better to have two?
>
> num_discards,
> num_failed_discards?
do we actully need this? the only value I can think of (perhaps I'm
missing something) is that we can make sure that we need to support
both slot free and REQ_DISCARDS, or we can leave only REQ_DISCARDS.
is there anything else?
-ss
> For it, we should modify zram_free_page has return value.
> What do other guys think?
>
> >
> > In this patch, we add num_discards to stat discarded pages, and export it to
> > sysfs for users.
> >
> > * From v1
> > * Update zram document to show num_discards in statistics list.
> >
> > * From v2
> > * Update description of this patch with clear goal.
> >
> > Signed-off-by: Chao Yu
> > ---
> > Documentation/ABI/testing/sysfs-block-zram | 10 ++
> > Documentation/blockdev/zram.txt| 1 +
> > drivers/block/zram/zram_drv.c | 3 +++
> > drivers/block/zram/zram_drv.h | 1 +
> > 4 files changed, 15 insertions(+)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-block-zram
> > b/Documentation/ABI/testing/sysfs-block-zram
> > index 70ec992..fa8936e 100644
> > --- a/Documentation/ABI/testing/sysfs-block-zram
> > +++ b/Documentation/ABI/testing/sysfs-block-zram
> > @@ -57,6 +57,16 @@ Description:
> > The failed_writes file is read-only and specifies the number of
> > failed writes happened on this device.
> >
> > +
> > +What: /sys/block/zram/num_discards
> > +Date: August 2014
> > +Contact: Chao Yu
> > +Description:
> > + The num_discards file is read-only and specifies the number of
> > + physical blocks which are discarded by this device. These blocks
> > + are included in discard request which is sended by filesystem as
> > + the blocks are no longer used.
> > +
> > What: /sys/block/zram/max_comp_streams
> > Date: February 2014
> > Contact: Sergey Senozhatsky
> > diff --git a/Documentation/blockdev/zram.txt
> > b/Documentation/blockdev/zram.txt
> > index 0595c3f..e50e18b 100644
> > --- a/Documentation/blockdev/zram.txt
> > +++ b/Documentation/blockdev/zram.txt
> > @@ -89,6 +89,7 @@ size of the disk when not in use so a huge zram is
> > wasteful.
> > num_writes
> > failed_reads
> > failed_writes
> > + num_discards
> > invalid_io
> > notify_free
> > zero_pages
> > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > index d00831c..904e7a5 100644
> > --- a/drivers/block/zram/zram_drv.c
> > +++ b/drivers/block/zram/zram_drv.c
> > @@ -606,6 +606,7 @@ static void zram_bio_discard(struct zram *zram, u32
> > index,
> > bit_spin_lock(ZRAM_ACCESS, >table[index].value);
> > zram_free_page(zram, index);
> > bit_spin_unlock(ZRAM_ACCESS, >table[index].value);
> > + atomic64_inc(>stats.num_discards);
> > index++;
> > n -= PAGE_SIZE;
> > }
> > @@ -866,6 +867,7 @@ ZRAM_ATTR_RO(num_reads);
> > ZRAM_ATTR_RO(num_writes);
> > ZRAM_ATTR_RO(failed_reads);
> > ZRAM_ATTR_RO(failed_writes);
> > +ZRAM_ATTR_RO(num_discards);
> > ZRAM_ATTR_RO(invalid_io);
> > ZRAM_ATTR_RO(notify_free);
> > ZRAM_ATTR_RO(zero_pages);
> > @@ -879,6 +881,7 @@ static struct attribute *zram_disk_attrs[] = {
> >
Re: [RFC 00/10] perf pollfd series
On Fri, Aug 22, 2014 at 05:59:40PM -0300, Arnaldo Carvalho de Melo wrote: > Hi, > > This is an alternative series to the one Jiri Olsa posted to use the > fixes he made to the kernel side to allow tooling to notice that a thread had > exited by looking at the pollfd.revents looking for POLLHUP notifications. > > Once all event file descriptors are removed from the evlist pollfd > array, > tools can make a decision about exiting or telling the user about what > happened, > asking to guidance on what to do next. > > The main difference in this approach is that a new class, which Jiri > called 'poller' and I called 'fdarray', grew up from what was in > evlist->pollfd > and associated operations, while Jiri first introduced a new class and then > made tooling use it. > > The details of the implementation should be clear on the changelog > comments, please let me know if you see any problems, and if I can have your > acked-by/tested-by/whatever-else tags to get this moving forward. > > Ah, there is still one missing thing which is to make the hists browser > in live mode be notified that all monitored events are POLLHUP'ed, will get > to that in followup patches. > > The kernel bits were sent together with my latest pull req to Ingo, > this series is on top of that branch and is available at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git perf/pollfd > > - Arnaldo > > Arnaldo Carvalho de Melo (10): > perf evlist: Introduce perf_evlist__filter_pollfd method > perf tests: Add test for perf_evlist__filter_pollfd() > perf evlist: Monitor POLLERR and POLLHUP events too > perf record: Filter out POLLHUP'ed file descriptors > perf trace: Filter out POLLHUP'ed file descriptors > perf evlist: Allow growing pollfd on add method > perf tests: Add pollfd growing test > perf kvm stat live: Use perf_evlist__add_pollfd() instead of local > equivalent > perf evlist: Introduce poll method for common code idiom > tools lib api: Adopt fdarray class from perf's evlist fdarray name seems too generic for this object, fdpoll looks more suitable.. also given that the file name is poll.[ch] ;-) anyway, except for what I've already commented: Acked-by: Jiri Olsa jirka -- 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 v3 3/4] thermal: add more description for thermal-zones
Hello Wei Ni, On Mon, Aug 25, 2014 at 02:29:47PM +0800, Wei Ni wrote: > Add more description for the "polling-delay" property. > Set "trips" and "cooling maps" as optional property, because > if missing these two sub-nodes, the thermal zone device still > work properly. > > Signed-off-by: Wei Ni > --- > Documentation/devicetree/bindings/thermal/thermal.txt | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt > b/Documentation/devicetree/bindings/thermal/thermal.txt > index f5db6b7..e3d3ed9 100644 > --- a/Documentation/devicetree/bindings/thermal/thermal.txt > +++ b/Documentation/devicetree/bindings/thermal/thermal.txt > @@ -136,8 +136,8 @@ containing trip nodes and one sub-node containing all the > zone cooling maps. > > Required properties: > - polling-delay: The maximum number of milliseconds to wait between polls > - Type: unsigned when checking this thermal zone. > - Size: one cell > + Type: unsigned when checking this thermal zone. If this value is 0, the > + Size: one cell driver will not run polling queue, but just cancel it. > The description above is specific to Linux kernel implementation nomenclature. DT description needs to be OS agnostic. > - polling-delay-passive: The maximum number of milliseconds to wait >Type: unsigned between polls when performing passive cooling. > @@ -148,14 +148,16 @@ Required properties: >phandles + sensor >specifier > > +Optional property: > - trips: A sub-node which is a container of only trip point nodes >Type: sub-node required to describe the thermal zone. > > - cooling-maps: A sub-node which is a container of only cooling > device >Type: sub-node map nodes, used to describe the relation between trips > - and cooling devices. > + and cooling devices. If missing the "trips" property, > + This sub-node will not be parsed, because no trips can > + be bound to cooling devices. Do you mean if the thermal zone misses the "trips" property? Actually, the binding describes both, cooling-maps and trips, as required properties. Thus, both needs to be in place to consider the thermal zone as a proper described zone. > > -Optional property: > - coefficients: An array of integers (one signed cell) > containing >Type: arraycoefficients to compose a linear relation > between >Elem size: one cellthe sensors listed in the thermal-sensors > property. > -- > 1.8.1.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/
Re: [PATCH v3 4/4] ARM: tegra: dalmore: add thermal zones for nct1008
On Mon, Aug 25, 2014 at 02:29:48PM +0800, Wei Ni wrote:
> From: lightning314
>
> Add dt node to describe the thermal zone for the nct1008.
>
> Signed-off-by: Wei Ni
> ---
> arch/arm/boot/dts/tegra114-dalmore.dts | 20 +++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts
> b/arch/arm/boot/dts/tegra114-dalmore.dts
> index 5c21d21..94a1b5d 100644
> --- a/arch/arm/boot/dts/tegra114-dalmore.dts
> +++ b/arch/arm/boot/dts/tegra114-dalmore.dts
> @@ -779,12 +779,14 @@
> < TEGRA_GPIO(V, 3) GPIO_ACTIVE_HIGH>;
> };
>
> - temperature-sensor@4c {
> + nct1008: temperature-sensor@4c {
> compatible = "onnn,nct1008";
> reg = <0x4c>;
> vcc-supply = <_ldo6_reg>;
> interrupt-parent = <>;
> interrupts = ;
> +
> + #thermal-sensor-cells = <1>;
> };
> };
>
> @@ -1283,4 +1285,20 @@
><_car TEGRA114_CLK_EXTERN1>;
> clock-names = "pll_a", "pll_a_out0", "mclk";
> };
> +
> + thermal-zones {
> + nct1008-local {
> + polling-delay-passive = <2000>; /* milliseconds */
> + polling-delay = <0>; /* milliseconds */
> +
> + thermal-sensors = < 0>;
> + };
> +
> + nct1008-remote {
> + polling-delay-passive = <1000>; /* milliseconds */
> + polling-delay = <0>; /* milliseconds */
> +
> + thermal-sensors = < 1>;
> + };
> + };
The above zones misses the required properties, as per the thermal.txt
binding description. Could you please have a look on those that are
required and improve the zones above?
> };
> --
> 1.8.1.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/
Re: [PATCH v5 3/4] zram: zram memory size limitation
On (08/25/14 09:05), Minchan Kim wrote:
> Since zram has no control feature to limit memory usage,
> it makes hard to manage system memrory.
>
> This patch adds new knob "mem_limit" via sysfs to set up the
> a limit so that zram could fail allocation once it reaches
> the limit.
>
> In addition, user could change the limit in runtime so that
> he could manage the memory more dynamically.
>
> Initial state is no limit so it doesn't break old behavior.
>
> Signed-off-by: Minchan Kim
> ---
> Documentation/ABI/testing/sysfs-block-zram | 10
> Documentation/blockdev/zram.txt| 24 ++---
> drivers/block/zram/zram_drv.c | 41
> ++
> drivers/block/zram/zram_drv.h | 5
> 4 files changed, 76 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-block-zram
> b/Documentation/ABI/testing/sysfs-block-zram
> index 70ec992514d0..dbe643775ec1 100644
> --- a/Documentation/ABI/testing/sysfs-block-zram
> +++ b/Documentation/ABI/testing/sysfs-block-zram
> @@ -119,3 +119,13 @@ Description:
> efficiency can be calculated using compr_data_size and this
> statistic.
> Unit: bytes
> +
> +What:/sys/block/zram/mem_limit
> +Date:August 2014
> +Contact: Minchan Kim
> +Description:
> + The mem_limit file is read/write and specifies the amount
> + of memory to be able to consume memory to store store
> + compressed data. The limit could be changed in run time
> + and "0" means disable the limit. No limit is the initial state.
just a nitpick, sorry.
"the amount of memory to be able to consume memory to store store compressed
data"
^^^
"the maximum amount of memory ZRAM can use to store the compressed data"?
-ss
> + Unit: bytes
> diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
> index 0595c3f56ccf..82c6a41116db 100644
> --- a/Documentation/blockdev/zram.txt
> +++ b/Documentation/blockdev/zram.txt
> @@ -74,14 +74,30 @@ There is little point creating a zram of greater than
> twice the size of memory
> since we expect a 2:1 compression ratio. Note that zram uses about 0.1% of
> the
> size of the disk when not in use so a huge zram is wasteful.
>
> -5) Activate:
> +5) Set memory limit: Optional
> + Set memory limit by writing the value to sysfs node 'mem_limit'.
> + The value can be either in bytes or you can use mem suffixes.
> + In addition, you could change the value in runtime.
> + Examples:
> + # limit /dev/zram0 with 50MB memory
> + echo $((50*1024*1024)) > /sys/block/zram0/mem_limit
> +
> + # Using mem suffixes
> + echo 256K > /sys/block/zram0/mem_limit
> + echo 512M > /sys/block/zram0/mem_limit
> + echo 1G > /sys/block/zram0/mem_limit
> +
> + # To disable memory limit
> + echo 0 > /sys/block/zram0/mem_limit
> +
> +6) Activate:
> mkswap /dev/zram0
> swapon /dev/zram0
>
> mkfs.ext4 /dev/zram1
> mount /dev/zram1 /tmp
>
> -6) Stats:
> +7) Stats:
> Per-device statistics are exported as various nodes under
> /sys/block/zram/
> disksize
> @@ -96,11 +112,11 @@ size of the disk when not in use so a huge zram is
> wasteful.
> compr_data_size
> mem_used_total
>
> -7) Deactivate:
> +8) Deactivate:
> swapoff /dev/zram0
> umount /dev/zram1
>
> -8) Reset:
> +9) Reset:
> Write any positive value to 'reset' sysfs node
> echo 1 > /sys/block/zram0/reset
> echo 1 > /sys/block/zram1/reset
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index f0b8b30a7128..370c355eb127 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -122,6 +122,33 @@ static ssize_t max_comp_streams_show(struct device *dev,
> return scnprintf(buf, PAGE_SIZE, "%d\n", val);
> }
>
> +static ssize_t mem_limit_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + u64 val;
> + struct zram *zram = dev_to_zram(dev);
> +
> + down_read(>init_lock);
> + val = zram->limit_pages;
> + up_read(>init_lock);
> +
> + return scnprintf(buf, PAGE_SIZE, "%llu\n", val << PAGE_SHIFT);
> +}
> +
> +static ssize_t mem_limit_store(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t len)
> +{
> + u64 limit;
> + struct zram *zram = dev_to_zram(dev);
> +
> + limit = memparse(buf, NULL);
> + down_write(>init_lock);
> + zram->limit_pages = PAGE_ALIGN(limit) >> PAGE_SHIFT;
> + up_write(>init_lock);
> +
> + return len;
> +}
> +
> static ssize_t max_comp_streams_store(struct device *dev,
> struct device_attribute *attr, const char *buf, size_t
Re: [PATCH] efi_high_alloc: use EFI_ALLOCATE_MAX_ADDRESS
On 25.08.2014 12:34, Matt Fleming wrote: > (Adding linux-efi to Cc) > > On Fri, 22 Aug, at 03:48:23PM, har...@redhat.com wrote: >> From: Harald Hoyer >> >> On my Lenovo T420s with 4GB memory, efi_high_alloc() was checking the >> following memory regions: >> >> 0x0010 - 0x2000 >> 0x2020 - 0x4000 >> 0x4020 - 0xd2c02000 >> 0xd6e9f000 - 0x00011e60 >> >> and decided to allocate 2649 pages at address 0x11dba7000. >> As I understand this is the physical address and this machine only >> has 4GB mem!! > > Yeah, but RAM doesn't necessarily start at the physical address > 0x. Nor is it necessarily contiguous. > > In other words, it's perfectly legitimate to allocate at physical > addresses above 0x1000 if the above memory map tells us RAM lives > there. yeah, I thought so, too :) > >> Nevertheless, unpacking of the initramfs later on failed. >> This was mainly caused by commit 4bf7111f50167133a71c23530ca852a41355e739, >> which enables loading the initramfs above 4G addresses. >> >> With this patch efi_high_alloc() now uses EFI_ALLOCATE_MAX_ADDRESS. >> This returns 0xd2c02000 on my machine and the resulting >> address at which the initramfs is loaded is then 0xd21a9000, >> which seems to work fine. > > Well yeah, that makes sense because you've obviously got a buggy EFI > firmware that doesn't load things correctly above 4GB. It turns out that > this is a common bug. > > Can you try the following patch and see whether booting with > efi=nochunk results in a functioning initramfs? I've had some success > with disabling the chunking workaround when reading files in the EFI > boot stub. Also, including a copy of a dmesg would be helpful. > Here we go... dmesg attached, but uncompression failed. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.17.0-rc1+ (harald@lenovo) (gcc version 4.9.1 20140813 (Red Hat 4.9.1-7) (GCC) ) #25 SMP Mon Aug 25 12:49:05 CEST 2014 [0.00] Command line: initrd=\9e3d4b6532ff41e1ab40d6b4e5609907\3.17.0-0.rc1.git1.2.fc22.1.x86_64\initrd rw root=/dev/sda2 loglevel=7 efi=nochunk [0.00] Disabled fast string operations [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x00057fff] usable [0.00] BIOS-e820: [mem 0x00058000-0x00058fff] ACPI NVS [0.00] BIOS-e820: [mem 0x00059000-0x0009] usable [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable [0.00] BIOS-e820: [mem 0x2000-0x201f] reserved [0.00] BIOS-e820: [mem 0x2020-0x3fff] usable [0.00] BIOS-e820: [mem 0x4000-0x401f] reserved [0.00] BIOS-e820: [mem 0x4020-0xda89efff] usable [0.00] BIOS-e820: [mem 0xda89f000-0xdae9efff] reserved [0.00] BIOS-e820: [mem 0xdae9f000-0xdaf9efff] ACPI NVS [0.00] BIOS-e820: [mem 0xdaf9f000-0xdaffefff] ACPI data [0.00] BIOS-e820: [mem 0xdafff000-0xdaff] usable [0.00] BIOS-e820: [mem 0xf80f8000-0xf80f8fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0x0001-0x00011e5f] usable [0.00] NX (Execute Disable) protection: active [0.00] e820: update [mem 0xd6c84018-0xd6c94057] usable ==> usable [0.00] extended physical RAM map: [0.00] reserve setup_data: [mem 0x-0x00057fff] usable [0.00] reserve setup_data: [mem 0x00058000-0x00058fff] ACPI NVS [0.00] reserve setup_data: [mem 0x00059000-0x0009] usable [0.00] reserve setup_data: [mem 0x0010-0x1fff] usable [0.00] reserve setup_data: [mem 0x2000-0x201f] reserved [0.00] reserve setup_data: [mem 0x2020-0x3fff] usable [0.00] reserve setup_data: [mem 0x4000-0x401f] reserved [0.00] reserve setup_data: [mem 0x4020-0xd6c84017] usable [0.00] reserve setup_data: [mem 0xd6c84018-0xd6c94057] usable [0.00] reserve setup_data: [mem 0xd6c94058-0xda89efff] usable [0.00] reserve setup_data: [mem 0xda89f000-0xdae9efff] reserved [0.00] reserve setup_data: [mem 0xdae9f000-0xdaf9efff] ACPI NVS [0.00] reserve setup_data: [mem 0xdaf9f000-0xdaffefff] ACPI data [0.00] reserve setup_data: [mem 0xdafff000-0xdaff] usable [0.00] reserve setup_data:
Re: [PATCH v3 4/4] ARM: tegra: dalmore: add thermal zones for nct1008
On Mon, Aug 25, 2014 at 02:29:48PM +0800, Wei Ni wrote:
> From: lightning314
>
> Add dt node to describe the thermal zone for the nct1008.
>
> Signed-off-by: Wei Ni
> ---
> arch/arm/boot/dts/tegra114-dalmore.dts | 20 +++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts
> b/arch/arm/boot/dts/tegra114-dalmore.dts
> index 5c21d21..94a1b5d 100644
> --- a/arch/arm/boot/dts/tegra114-dalmore.dts
> +++ b/arch/arm/boot/dts/tegra114-dalmore.dts
> @@ -779,12 +779,14 @@
> < TEGRA_GPIO(V, 3) GPIO_ACTIVE_HIGH>;
> };
>
> - temperature-sensor@4c {
> + nct1008: temperature-sensor@4c {
> compatible = "onnn,nct1008";
> reg = <0x4c>;
> vcc-supply = <_ldo6_reg>;
> interrupt-parent = <>;
> interrupts = ;
> +
> + #thermal-sensor-cells = <1>;
> };
> };
>
> @@ -1283,4 +1285,20 @@
><_car TEGRA114_CLK_EXTERN1>;
> clock-names = "pll_a", "pll_a_out0", "mclk";
> };
> +
> + thermal-zones {
> + nct1008-local {
at this level, can the thermal zone name be a meaningful string? What
part of the hardware does the local and remote monitors the the dalmore
platform?
> + polling-delay-passive = <2000>; /* milliseconds */
> + polling-delay = <0>; /* milliseconds */
> +
> + thermal-sensors = < 0>;
> + };
> +
> + nct1008-remote {
> + polling-delay-passive = <1000>; /* milliseconds */
> + polling-delay = <0>; /* milliseconds */
> +
> + thermal-sensors = < 1>;
> + };
> + };
> };
> --
> 1.8.1.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/
Re: kernel boot fail with efi earlyprintk (bisected)
On Mon, 25 Aug, at 05:06:19PM, Dave Young wrote: > > Problem is I do not understand the implementation detail yet. > > I did below changes: > > Original values: > #define NR_FIX_BTMAPS 64 > #define FIX_BTMAPS_SLOTS4 > > -> new values tested: > #define NR_FIX_BTMAPS 32 > #define FIX_BTMAPS_SLOTS8 > > > There's below comments > /* > * 256 temporary boot-time mappings, used by early_ioremap(), > * before ioremap() is functional. > * > * If necessary we round it up to the next 256 pages boundary so > * that we can have a single pgd entry and a single pte table: > */ > > So seems increase it to 64 * 8 = 512 should be ok. If it's fine I can test > again > and post a patch. Make sure you include the x86 maintainers on Cc if you change these values. -- Matt Fleming, Intel Open Source Technology Center -- 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: [PATCHv4 2/4] thermal: exynos: Add support for many TRIMINFO_CTRL registers
On Monday, August 25, 2014 07:37:25 PM Chanwoo Choi wrote:
> Hi Bartlomiej,
>
> On 08/25/2014 07:15 PM, Bartlomiej Zolnierkiewicz wrote:
> >
> > Hi,
> >
> > On Monday, August 25, 2014 04:30:23 PM Chanwoo Choi wrote:
> >> This patch support many TRIMINFO_CTRL registers if specific Exynos SoC
> >> has one more TRIMINFO_CTRL registers. Also this patch uses proper 'RELOAD'
> >> shift/mask bit operation to set RELOAD feature instead of static value.
> >>
> >> Signed-off-by: Chanwoo Choi
> >> Acked-by: Kyungmin Park
> >> Cc: Zhang Rui
> >> Cc: Eduardo Valentin
> >> Cc: Amit Daniel Kachhap
> >> Reviewed-by: Amit Daniel Kachhap
> >> ---
> >> drivers/thermal/samsung/exynos_thermal_common.h | 1 +
> >> drivers/thermal/samsung/exynos_tmu.c| 23
> >> ---
> >> drivers/thermal/samsung/exynos_tmu.h| 9 +++--
> >> drivers/thermal/samsung/exynos_tmu_data.c | 5 -
> >> drivers/thermal/samsung/exynos_tmu_data.h | 3 +++
> >> 5 files changed, 35 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/thermal/samsung/exynos_thermal_common.h
> >> b/drivers/thermal/samsung/exynos_thermal_common.h
> >> index 3eb2ed9..b211976 100644
> >> --- a/drivers/thermal/samsung/exynos_thermal_common.h
> >> +++ b/drivers/thermal/samsung/exynos_thermal_common.h
> >> @@ -28,6 +28,7 @@
> >> #define MAX_TRIP_COUNT8
> >> #define MAX_COOLING_DEVICE 4
> >> #define MAX_THRESHOLD_LEVS 5
> >> +#define MAX_TRIMINFO_CTRL_REG 2
> >>
> >> #define ACTIVE_INTERVAL 500
> >> #define IDLE_INTERVAL 1
> >> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> >> b/drivers/thermal/samsung/exynos_tmu.c
> >> index acbff14..7234f38 100644
> >> --- a/drivers/thermal/samsung/exynos_tmu.c
> >> +++ b/drivers/thermal/samsung/exynos_tmu.c
> >> @@ -147,7 +147,7 @@ static int exynos_tmu_initialize(struct
> >> platform_device *pdev)
> >>struct exynos_tmu_data *data = platform_get_drvdata(pdev);
> >>struct exynos_tmu_platform_data *pdata = data->pdata;
> >>const struct exynos_tmu_registers *reg = pdata->registers;
> >> - unsigned int status, trim_info = 0, con;
> >> + unsigned int status, trim_info = 0, con, ctrl;
> >>unsigned int rising_threshold = 0, falling_threshold = 0;
> >>int ret = 0, threshold_code, i, trigger_levs = 0;
> >>
> >> @@ -164,8 +164,25 @@ static int exynos_tmu_initialize(struct
> >> platform_device *pdev)
> >>}
> >>}
> >>
> >> - if (TMU_SUPPORTS(pdata, TRIM_RELOAD))
> >> - __raw_writel(1, data->base + reg->triminfo_ctrl);
> >> + if (TMU_SUPPORTS(pdata, TRIM_RELOAD)) {
> >> + if (reg->triminfo_ctrl_count > MAX_TRIMINFO_CTRL_REG) {
> >
> > Please remove this check and MAX_TRIMINFO_CTRL_REG define.
> >
> > We do not want such runtime checks for development time errors.
>
> OK, I'll remove it.
>
> >
> >> + ret = -EINVAL;
> >> + goto out;
> >> + }
> >> +
> >> + for (i = 0; i < reg->triminfo_ctrl_count; i++) {
> >> + if (pdata->triminfo_reload[i]) {
> >> + ctrl = readl(data->base +
> >> + reg->triminfo_ctrl[i]);
> >> + ctrl &= ~(reg->triminfo_reload_mask <<
> >> + reg->triminfo_reload_shift);
> >> + ctrl |= pdata->triminfo_reload[i] <<
> >> + reg->triminfo_reload_shift;
> >
> > triminfo_reload_shift and triminfo_reload_mask variables have always
> > the same values when this code is run so there is no need for them.
>
> I don't understand. Do you mean that timinfo_reload_{shift/mask} variable is
> un-needed?
Yes.
> If you possible, I need more detailed comment.
Currently triminfo_reload_shift is always "0" and triminfo_reload_mask
is "1" so there is no need to add an abstraction for different SoCs
(it should be added only when there is a real need for it).
Please just rewrite this code as:
if (pdata->triminfo_reload[i]) {
ctrl = readl(data->base +
reg->triminfo_ctrl[i]);
ctrl |= pdata->triminfo_reload[i];
__raw_writel(ctrl, data->base +
reg->triminfo_ctrl[i]);
}
Then you can remove unused triminfo_reload_shift and
EXYNOS_TRIMINFO_RELOAD_SHIFT.
Please also include my patch (https://lkml.org/lkml/2014/8/20/481) in
your patch series (or at least mark it in the cover letter that my
patch should be merged before your patch #2/4).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
> > They should be added only when needed instead of doing it now.
> >
> >> + __raw_writel(ctrl, data->base +
> >> +
Re: [PATCH V3 3/3] ARM: clk-imx6q: Add missing lvds and anaclk clock to the clock tree
On Mon, Aug 25, 2014 at 03:40:20PM +0800, Shengjiu Wang wrote:
> On Mon, Aug 18, 2014 at 02:06:07PM +0800, Shawn Guo wrote:
> > On Mon, Aug 11, 2014 at 11:09:36AM +0800, Shengjiu Wang wrote:
> > > On Sat, Aug 09, 2014 at 09:58:42PM +0800, Shawn Guo wrote:
> > > > On Fri, Aug 08, 2014 at 03:02:49PM +0800, Shengjiu Wang wrote:
> > > > > @@ -176,8 +182,12 @@ static void __init imx6q_clocks_init(struct
> > > > > device_node *ccm_node)
> > > > >* the "output_enable" bit as a gate, even though it's really
> > > > > just
> > > > >* enabling clock output.
> > > > >*/
> > > > > - clk[IMX6QDL_CLK_LVDS1_GATE] = imx_clk_gate("lvds1_gate",
> > > > > "lvds1_sel", base + 0x160, 10);
> > > > > - clk[IMX6QDL_CLK_LVDS2_GATE] = imx_clk_gate("lvds2_gate",
> > > > > "lvds2_sel", base + 0x160, 11);
> > > > > + clk[IMX6QDL_CLK_LVDS1_GATE] = imx_clk_gate2("lvds1_gate",
> > > > > "lvds1_sel", base + 0x160, 10);
> > > > > + clk[IMX6QDL_CLK_LVDS2_GATE] = imx_clk_gate2("lvds2_gate",
> > > > > "lvds2_sel", base + 0x160, 11);
> > > >
> > > > I do not think you can simply change to use imx_clk_gate2() here. It's
> > > > designed for those CCGR gate clocks, each of which is controlled by two
> > > > bits.
> > > >
> > > > Shawn
> > > >
> > > As Lucas Stach's suggestion, we need to do add some method for mutually
> > > exclusive clock,
> > > lvds1_gate with lvds1_in, lvds2_gate with lvds2_in. I add
> > > imx_clk_gate2_exclusive() function in clk-gate2.c.
> > > So I change imx_clk_gate() to imx_clk_gate2() here.
> > > As you said, this is not good solution.
> >
> > It's not just a "not good" solution but wrong and broken one. The net
> > result of that is if you call clk_enable() on lvds1_gate, both bit 10
> > and 11 will be set.
> >
> > > So I need your suggestion, how can I do?
> >
> > I guess we will need a new clock type to handle such mutually exclusive
> > clocks, rather than patching clk-gate2.
> >
> Could you please help to implement this feature?
Okay, I will give it a try soon.
>
> Furthermore, I'd like to drop patch 2 and patch 3, wait the implementation
> from
> you.
>
> Could you please review the patch 1? do you have any comments?
Just applied #1.
Shawn
--
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] list: include linux/kernel.h
linux/list.h uses container_of, therefore it depends on linux/kernel.h. Signed-off-by: Masahiro Yamada --- I am sending this patch to LKML because I could not find the subsystem it should belong to. I hope I am not doing wrong. include/linux/list.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/list.h b/include/linux/list.h index cbbb96f..f33f831 100644 --- a/include/linux/list.h +++ b/include/linux/list.h @@ -5,6 +5,7 @@ #include #include #include +#include /* * Simple doubly linked list implementation. -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/8] asm-generic/io.h overhaul
On Wed, Aug 13, 2014 at 12:28:50PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Hi,
>
> Here is the fourth version of a series that started out as an attempt to
> provide string versions of the read*() and write*() accessors to more
> architectures so that drivers can use them portably. The series has
> since evolved into a more general cleanup of asm-generic/io.h and the
> functions defined therein.
>
> Patch 1 is trivial and removes a redundant redefinition of PCI_IOBASE
> from the asm/io.h header on ARC. Patches 2 and 3 remove unnecessary
> volatile keywoards from some functions, which is a prerequisite to clean
> up some of the functions in subsequent patches.
>
> The xlate_dev_{kmem,mem}_ptr() functions are used to map memory when the
> /dev/mem device is accessed. Patches 4 and 5 use more consistent data
> types for these functions, which will get a "standard" prototype in the
> asm-generic/io.h header in a subsequent patch.
>
> Patch 6 is the bulk of this series. It implements the string variants of
> the read*() and write*() accessors and cleans up various other parts of
> the asm-generic/io.h header file. Macros are converted to static inline
> functions for better type checking. Overriding generic implementations
> in architectures is handled more consistently.
>
> Patches 7 and 8, finally, make use of the asm-generic/io.h header on the
> 32-bit and 64-bit ARM architectures.
>
> This is compile- and runtime-tested on 32-bit and 64-bit ARM and compile
> tested on IA64, Microblaze, s390, SPARC, x86 and Xtensa. For ARC,
> Blackfin, Metag, OpenRISC, Score and Unicore32 which also use
> asm-generic/io.h I couldn't find or build a cross-compiler that would
> run on my system. But by code inspection they shouldn't break with this
> patch.
>
> To ensure bisectability I built multi_v7_defconfig on 32-bit ARM and the
> defconfig for 64-bit ARM, IA64, Microblaze, s390, SPARC, x86 and Xtensa
> after each commit and verified that the series does not introduce any
> build errors or warnings.
>
> Provided there are no objections to the patches there's still the matter
> of how to merge them. Patch 6 depends on patches 1-5 to avoid warnings
> and/or errors during the build. Patches 7 and 8 depend on patch 6. In my
> opinion it doesn't make much sense to split them up, so I guess we'll
> need a volunteer to take them all into one tree. Ideally that tree would
> feed into linux-next so that we can get as much build and test-coverage
> as possible during the 3.17 release cycle so that these patches can go
> into 3.18.
>
> Arnd, I'm opportunistically sending this To: you in the hopes that you
> can take it into your asm-generic tree which seems like the best fit for
> this.
>
> Thierry
>
> Thierry Reding (8):
> ARC: Remove redundant PCI_IOBASE declaration
> serial: sunzilog: Remove unnecessary volatile keyword
> sparc: Remove unnecessary volatile usage
> [IA64] Change xlate_dev_{kmem,mem}_ptr() prototypes
> /dev/mem: Use more consistent data types
> asm-generic/io.h: Implement generic {read,write}s*()
> ARM: Use include/asm-generic/io.h
> arm64: Use include/asm-generic/io.h
>
> arch/arc/include/asm/io.h | 2 -
> arch/arm/include/asm/io.h | 75 ++---
> arch/arm/include/asm/memory.h | 2 +
> arch/arm64/Kconfig | 1 -
> arch/arm64/include/asm/io.h | 122 ++-
> arch/arm64/include/asm/memory.h | 2 +
> arch/ia64/include/asm/uaccess.h | 16 +-
> arch/s390/include/asm/io.h | 5 +-
> arch/s390/mm/maccess.c | 4 +-
> arch/sparc/include/asm/io_32.h | 18 +-
> arch/x86/include/asm/io.h | 4 +-
> arch/x86/mm/ioremap.c | 4 +-
> drivers/char/mem.c | 13 +-
> drivers/tty/serial/sunzilog.h | 8 +-
> include/asm-generic/io.h| 683
>
> 15 files changed, 647 insertions(+), 312 deletions(-)
Arnd, do you think this looks good to take for test-driving in
linux-next?
Thierry
pgpxttuJgIwP9.pgp
Description: PGP signature
Re: [PATCHv4 2/4] thermal: exynos: Add support for many TRIMINFO_CTRL registers
On Monday, August 25, 2014 01:19:04 PM Bartlomiej Zolnierkiewicz wrote:
> On Monday, August 25, 2014 07:37:25 PM Chanwoo Choi wrote:
> > Hi Bartlomiej,
> >
> > On 08/25/2014 07:15 PM, Bartlomiej Zolnierkiewicz wrote:
> > >
> > > Hi,
> > >
> > > On Monday, August 25, 2014 04:30:23 PM Chanwoo Choi wrote:
> > >> This patch support many TRIMINFO_CTRL registers if specific Exynos SoC
> > >> has one more TRIMINFO_CTRL registers. Also this patch uses proper
> > >> 'RELOAD'
> > >> shift/mask bit operation to set RELOAD feature instead of static value.
> > >>
> > >> Signed-off-by: Chanwoo Choi
> > >> Acked-by: Kyungmin Park
> > >> Cc: Zhang Rui
> > >> Cc: Eduardo Valentin
> > >> Cc: Amit Daniel Kachhap
> > >> Reviewed-by: Amit Daniel Kachhap
> > >> ---
> > >> drivers/thermal/samsung/exynos_thermal_common.h | 1 +
> > >> drivers/thermal/samsung/exynos_tmu.c| 23
> > >> ---
> > >> drivers/thermal/samsung/exynos_tmu.h| 9 +++--
> > >> drivers/thermal/samsung/exynos_tmu_data.c | 5 -
> > >> drivers/thermal/samsung/exynos_tmu_data.h | 3 +++
> > >> 5 files changed, 35 insertions(+), 6 deletions(-)
> > >>
> > >> diff --git a/drivers/thermal/samsung/exynos_thermal_common.h
> > >> b/drivers/thermal/samsung/exynos_thermal_common.h
> > >> index 3eb2ed9..b211976 100644
> > >> --- a/drivers/thermal/samsung/exynos_thermal_common.h
> > >> +++ b/drivers/thermal/samsung/exynos_thermal_common.h
> > >> @@ -28,6 +28,7 @@
> > >> #define MAX_TRIP_COUNT 8
> > >> #define MAX_COOLING_DEVICE 4
> > >> #define MAX_THRESHOLD_LEVS 5
> > >> +#define MAX_TRIMINFO_CTRL_REG 2
> > >>
> > >> #define ACTIVE_INTERVAL 500
> > >> #define IDLE_INTERVAL 1
> > >> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> > >> b/drivers/thermal/samsung/exynos_tmu.c
> > >> index acbff14..7234f38 100644
> > >> --- a/drivers/thermal/samsung/exynos_tmu.c
> > >> +++ b/drivers/thermal/samsung/exynos_tmu.c
> > >> @@ -147,7 +147,7 @@ static int exynos_tmu_initialize(struct
> > >> platform_device *pdev)
> > >> struct exynos_tmu_data *data = platform_get_drvdata(pdev);
> > >> struct exynos_tmu_platform_data *pdata = data->pdata;
> > >> const struct exynos_tmu_registers *reg = pdata->registers;
> > >> -unsigned int status, trim_info = 0, con;
> > >> +unsigned int status, trim_info = 0, con, ctrl;
> > >> unsigned int rising_threshold = 0, falling_threshold = 0;
> > >> int ret = 0, threshold_code, i, trigger_levs = 0;
> > >>
> > >> @@ -164,8 +164,25 @@ static int exynos_tmu_initialize(struct
> > >> platform_device *pdev)
> > >> }
> > >> }
> > >>
> > >> -if (TMU_SUPPORTS(pdata, TRIM_RELOAD))
> > >> -__raw_writel(1, data->base + reg->triminfo_ctrl);
> > >> +if (TMU_SUPPORTS(pdata, TRIM_RELOAD)) {
> > >> +if (reg->triminfo_ctrl_count > MAX_TRIMINFO_CTRL_REG) {
> > >
> > > Please remove this check and MAX_TRIMINFO_CTRL_REG define.
> > >
> > > We do not want such runtime checks for development time errors.
> >
> > OK, I'll remove it.
> >
> > >
> > >> +ret = -EINVAL;
> > >> +goto out;
> > >> +}
> > >> +
> > >> +for (i = 0; i < reg->triminfo_ctrl_count; i++) {
> > >> +if (pdata->triminfo_reload[i]) {
> > >> +ctrl = readl(data->base +
> > >> +reg->triminfo_ctrl[i]);
> > >> +ctrl &= ~(reg->triminfo_reload_mask <<
> > >> +
> > >> reg->triminfo_reload_shift);
> > >> +ctrl |= pdata->triminfo_reload[i] <<
> > >> +
> > >> reg->triminfo_reload_shift;
> > >
> > > triminfo_reload_shift and triminfo_reload_mask variables have always
> > > the same values when this code is run so there is no need for them.
> >
> > I don't understand. Do you mean that timinfo_reload_{shift/mask} variable
> > is un-needed?
>
> Yes.
>
> > If you possible, I need more detailed comment.
>
> Currently triminfo_reload_shift is always "0" and triminfo_reload_mask
> is "1" so there is no need to add an abstraction for different SoCs
> (it should be added only when there is a real need for it).
>
> Please just rewrite this code as:
>
> if (pdata->triminfo_reload[i]) {
> ctrl = readl(data->base +
> reg->triminfo_ctrl[i]);
> ctrl |= pdata->triminfo_reload[i];
> __raw_writel(ctrl, data->base +
> reg->triminfo_ctrl[i]);
> }
or even better lets get rid of the only __raw_writel() call in Exynos
thermal driver while at it:
[PATCH 1/1] x86:kvm: fix one typo in comment
s/drity/dirty Signed-off-by: Tiejun Chen --- arch/x86/kvm/mmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index 9314678..09b9f05 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -1180,7 +1180,7 @@ static void drop_large_spte(struct kvm_vcpu *vcpu, u64 *sptep) * Write-protect on the specified @sptep, @pt_protect indicates whether * spte write-protection is caused by protecting shadow page table. * - * Note: write protection is difference between drity logging and spte + * Note: write protection is difference between dirty logging and spte * protection: * - for dirty logging, the spte can be set to writable at anytime if * its dirty bitmap is properly set. -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cgroup: Enable controllers for default hierarchy by default.
When we create a cgroup in unified hierarchy, we have to enable
controllers in cgrp_dfl_root.subtree_control manually. From
my practice, I did not find the benefit we disable controllers
in cgrp_dfl_root by default.
As I am a newbie to cgroup, please correct me if I am wrong.
Thanx.
Signed-off-by: Dongsheng Yang
---
kernel/cgroup.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 7dc8788..70996ee 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1267,12 +1267,9 @@ static int rebind_subsystems(struct cgroup_root
*dst_root, unsigned int ss_mask)
src_root->cgrp.subtree_control &= ~(1 << ssid);
cgroup_refresh_child_subsys_mask(_root->cgrp);
- /* default hierarchy doesn't enable controllers by default */
dst_root->subsys_mask |= 1 << ssid;
- if (dst_root != _dfl_root) {
- dst_root->cgrp.subtree_control |= 1 << ssid;
- cgroup_refresh_child_subsys_mask(_root->cgrp);
- }
+ dst_root->cgrp.subtree_control |= 1 << ssid;
+ cgroup_refresh_child_subsys_mask(_root->cgrp);
if (ss->bind)
ss->bind(css);
@@ -4990,6 +4987,8 @@ int __init cgroup_init(void)
}
}
+ cgrp_dfl_root.cgrp.subtree_control = cgrp_dfl_root.subsys_mask;
+
cgroup_kobj = kobject_create_and_add("cgroup", fs_kobj);
if (!cgroup_kobj)
return -ENOMEM;
--
1.8.4.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] cgroup: fix a typo in comment.
There is no function named cgroup_enable_task_cg_links(). Instead, the correct function name in this comment should be cgroup_enabled_task_cg_lists(). Signed-off-by: Dongsheng Yang --- kernel/cgroup.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/cgroup.c b/kernel/cgroup.c index 7dc8788..64bbb56 100644 --- a/kernel/cgroup.c +++ b/kernel/cgroup.c @@ -5161,7 +5161,7 @@ void cgroup_post_fork(struct task_struct *child) int i; /* -* This may race against cgroup_enable_task_cg_links(). As that +* This may race against cgroup_enable_task_cg_lists(). As that * function sets use_task_css_set_links before grabbing * tasklist_lock and we just went through tasklist_lock to add * @child, it's guaranteed that either we see the set @@ -5176,7 +5176,7 @@ void cgroup_post_fork(struct task_struct *child) * when implementing operations which need to migrate all tasks of * a cgroup to another. * -* Note that if we lose to cgroup_enable_task_cg_links(), @child +* Note that if we lose to cgroup_enable_task_cg_lists(), @child * will remain in init_css_set. This is safe because all tasks are * in the init_css_set before cg_links is enabled and there's no * operation which transfers all tasks out of init_css_set. -- 1.8.4.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] cgroup: Introduce cgroup_detach_task().
Currently, the only method to detach a task from a cgroup is moving
it to others. It looks not natrual to me.
Inspired by cgroup_subtree_control_write(), this patch introduce allow
user to at-detach a process to/from a cgroup by echo "+/-pid" to
cgroup.procs. In addition, we keep the old method to allow user
echo "pid" without "+/-" to cgroup.procs as a attaching behavior.
Signed-off-by: Dongsheng Yang
---
kernel/cgroup.c | 62 +++--
1 file changed, 60 insertions(+), 2 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 7dc8788..11ef4ac 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2348,6 +2348,43 @@ static int cgroup_attach_task(struct cgroup *dst_cgrp,
return ret;
}
+/**
+ * cgroup_detach_task - detach a task or a whole threadgroup to a cgroup
+ * @src_cgrp: the cgroup to detach from
+ * @leader: the task or the leader of the threadgroup to be attached
+ * @threadgroup: attach the whole threadgroup?
+ *
+ * Call holding cgroup_mutex and threadgroup_lock of @leader.
+ */
+static int cgroup_detach_task(struct cgroup *src_cgrp __maybe_unused,
+ struct task_struct *leader, bool threadgroup)
+{
+ LIST_HEAD(preloaded_csets);
+ struct task_struct *task;
+ int ret;
+
+ /* look up all src csets */
+ down_read(_set_rwsem);
+ rcu_read_lock();
+ task = leader;
+ do {
+ cgroup_migrate_add_src(task_css_set(task), _dfl_root.cgrp,
+ _csets);
+ if (!threadgroup)
+ break;
+ } while_each_thread(leader, task);
+ rcu_read_unlock();
+ up_read(_set_rwsem);
+
+ /* prepare dst csets and commit */
+ ret = cgroup_migrate_prepare_dst(_dfl_root.cgrp, _csets);
+ if (!ret)
+ ret = cgroup_migrate(_dfl_root.cgrp, leader, threadgroup);
+
+ cgroup_migrate_finish(_csets);
+ return ret;
+}
+
/*
* Find the task_struct of the task to attach by vpid and pass it along to the
* function to attach either it or all tasks in its threadgroup. Will lock
@@ -2361,8 +2398,26 @@ static ssize_t __cgroup_procs_write(struct
kernfs_open_file *of, char *buf,
struct cgroup *cgrp;
pid_t pid;
int ret;
+ bool attach;
- if (kstrtoint(strstrip(buf), 0, ) || pid < 0)
+ /*
+* Parse input - space separated list of subsystem names prefixed
+* with either + or -.
+*/
+ buf = strstrip(buf);
+ if (*buf == '+') {
+ attach = true;
+ buf++;
+ } else if (*buf == '-') {
+ attach = false;
+ buf++;
+ } else {
+ if (!isdigit(*buf))
+ return -EINVAL;
+ attach = true;
+ }
+
+ if (kstrtoint(buf, 0, ) || pid < 0)
return -EINVAL;
cgrp = cgroup_kn_lock_live(of->kn);
@@ -2426,7 +2481,10 @@ retry_find_task:
}
}
- ret = cgroup_attach_task(cgrp, tsk, threadgroup);
+ if (attach)
+ ret = cgroup_attach_task(cgrp, tsk, threadgroup);
+ else
+ ret = cgroup_detach_task(cgrp, tsk, threadgroup);
threadgroup_unlock(tsk);
--
1.8.4.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/
Re: scsi logging future directions, was Re: [RFC PATCH -logging 00/10] scsi/constants: Output continuous error messages on trace
On 08/24/2014 10:44 PM, Christoph Hellwig wrote: On Fri, Aug 22, 2014 at 12:39:59AM +, Elliott, Robert (Server Storage) wrote: If you trigger hundreds of errors (e.g., hot remove a device during heavy IO), then all the prints to the linux serial console bog down the system, causing timeouts in commands to other devices and soft lockups for applications. Some changes that would help are: 1. Put them under SCSI logging level control 2. Use printk_ratelimited so an excessive number are trimmed Would you like to include something like this in your patch set? I think we should come to an agreement where we want to go with scsi logging first before doing various smaller adjustments. (Although your example is one that's urgent enough that I'd like to put it in ASAP, I had issues with it a few times). I had a chat with Martin at Linuxcon about these issues, and we were both in favor of getting rid of the old scsi logging mechansisms and instead replace it by an extended version of the scsi tracepoints that cover all places, and dump all data from the old logging mechanism that people find useful. In a few places we'd still want to log normal dev_printk style errors, and the I/O completion is one of them, even if they really need to be ratelimited and condensed. If someone has arguments in favour of keeping the old logging code I'd love to hear them, but in practive the traceevent code has huge benefits: - almost zero overhead if disabled - can easily be used without any tools through configs, but can be used even better with tools like trace-cmd or perf - allows both fine and coarse grained selections of events to trace - allows to capture statistics on each trace point without event enabling the output - doesn't have any of the console lockup problems. I've already been working on updating scsi logging infrastructure, removing old cludges and streamlining it. I'm all in favour of moving things over to scsi tracing; in fact I've already moved all the current SCSI_ML_XXX statements to tracepoints in my current patchset. Unfortunately I haven't found time to test things out there, and there's the patchset from Yoshihiro which needs review and integration. As of now I've treated this as rather low priority as no-one seemed to mind and the patchsets will be touching each and every driver. I'll be updating the patchset and send it for review. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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 for -next] stmmac: simple cleanups
This adds simple cleanups for stmmac, removing test we know is always
true, fixing whitespace, and moving code out of if().
Signed-off-by: Pavel Machek
---
Now against -net-next.
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index 9af50ba..493fe69 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -261,11 +261,11 @@ static int stmmac_ethtool_getsettings(struct net_device
*dev,
ethtool_cmd_speed_set(cmd, priv->xstats.pcs_speed);
/* Get and convert ADV/LP_ADV from the HW AN registers */
- if (priv->hw->mac->get_adv)
- priv->hw->mac->get_adv(priv->hw, );
- else
+ if (!priv->hw->mac->get_adv)
return -EOPNOTSUPP; /* should never happen indeed */
+ priv->hw->mac->get_adv(priv->hw, );
+
/* Encoding of PSE bits is defined in 802.3z, 37.2.1.4 */
if (adv.pause & STMMAC_PCS_PAUSE)
@@ -340,19 +340,17 @@ static int stmmac_ethtool_setsettings(struct net_device
*dev,
if (cmd->autoneg != AUTONEG_ENABLE)
return -EINVAL;
- if (cmd->autoneg == AUTONEG_ENABLE) {
- mask &= (ADVERTISED_1000baseT_Half |
+ mask &= (ADVERTISED_1000baseT_Half |
ADVERTISED_1000baseT_Full |
ADVERTISED_100baseT_Half |
ADVERTISED_100baseT_Full |
ADVERTISED_10baseT_Half |
ADVERTISED_10baseT_Full);
- spin_lock(>lock);
- if (priv->hw->mac->ctrl_ane)
- priv->hw->mac->ctrl_ane(priv->hw, 1);
- spin_unlock(>lock);
- }
+ spin_lock(>lock);
+ if (priv->hw->mac->ctrl_ane)
+ priv->hw->mac->ctrl_ane(priv->hw, 1);
+ spin_unlock(>lock);
return 0;
}
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 08addd6..8fcc64c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -818,7 +818,7 @@ static int stmmac_init_phy(struct net_device *dev)
/* Stop Advertising 1000BASE Capability if interface is not GMII */
if ((interface == PHY_INTERFACE_MODE_MII) ||
(interface == PHY_INTERFACE_MODE_RMII) ||
- (max_speed < 1000 && max_speed > 0))
+ (max_speed < 1000 && max_speed > 0))
phydev->advertising &= ~(SUPPORTED_1000baseT_Half |
SUPPORTED_1000baseT_Full);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index a5b1e1b..8dd0408 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -253,7 +253,7 @@ int stmmac_mdio_register(struct net_device *ndev)
}
/*
-* If we're going to bind the MAC to this PHY bus,
+* If we're going to bind the MAC to this PHY bus,
* and no PHY number was provided to the MAC,
* use the one probed here.
*/
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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/
[PATCH V2] cgroup: Introduce cgroup_detach_task().
Currently, the only method to detach a task from a cgroup is moving
it to others. It looks not natrual to me.
Inspired by cgroup_subtree_control_write(), this patch introduce allow
user to at-detach a process to/from a cgroup by echo "+/-pid" to
cgroup.procs. In addition, we keep the old method to allow user
echo "pid" without "+/-" to cgroup.procs as a attaching behavior.
Signed-off-by: Dongsheng Yang
---
>From v1:
*Sorry for a incorrect comment in v1.
kernel/cgroup.c | 61 +++--
1 file changed, 59 insertions(+), 2 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 7dc8788..a4bb604 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2348,6 +2348,43 @@ static int cgroup_attach_task(struct cgroup *dst_cgrp,
return ret;
}
+/**
+ * cgroup_detach_task - detach a task or a whole threadgroup to a cgroup
+ * @src_cgrp: the cgroup to detach from
+ * @leader: the task or the leader of the threadgroup to be attached
+ * @threadgroup: attach the whole threadgroup?
+ *
+ * Call holding cgroup_mutex and threadgroup_lock of @leader.
+ */
+static int cgroup_detach_task(struct cgroup *src_cgrp __maybe_unused,
+ struct task_struct *leader, bool threadgroup)
+{
+ LIST_HEAD(preloaded_csets);
+ struct task_struct *task;
+ int ret;
+
+ /* look up all src csets */
+ down_read(_set_rwsem);
+ rcu_read_lock();
+ task = leader;
+ do {
+ cgroup_migrate_add_src(task_css_set(task), _dfl_root.cgrp,
+ _csets);
+ if (!threadgroup)
+ break;
+ } while_each_thread(leader, task);
+ rcu_read_unlock();
+ up_read(_set_rwsem);
+
+ /* prepare dst csets and commit */
+ ret = cgroup_migrate_prepare_dst(_dfl_root.cgrp, _csets);
+ if (!ret)
+ ret = cgroup_migrate(_dfl_root.cgrp, leader, threadgroup);
+
+ cgroup_migrate_finish(_csets);
+ return ret;
+}
+
/*
* Find the task_struct of the task to attach by vpid and pass it along to the
* function to attach either it or all tasks in its threadgroup. Will lock
@@ -2361,8 +2398,25 @@ static ssize_t __cgroup_procs_write(struct
kernfs_open_file *of, char *buf,
struct cgroup *cgrp;
pid_t pid;
int ret;
+ bool attach;
- if (kstrtoint(strstrip(buf), 0, ) || pid < 0)
+ /*
+* Parse input - pid prefixed with either + or -.
+*/
+ buf = strstrip(buf);
+ if (*buf == '+') {
+ attach = true;
+ buf++;
+ } else if (*buf == '-') {
+ attach = false;
+ buf++;
+ } else {
+ if (!isdigit(*buf))
+ return -EINVAL;
+ attach = true;
+ }
+
+ if (kstrtoint(buf, 0, ) || pid < 0)
return -EINVAL;
cgrp = cgroup_kn_lock_live(of->kn);
@@ -2426,7 +2480,10 @@ retry_find_task:
}
}
- ret = cgroup_attach_task(cgrp, tsk, threadgroup);
+ if (attach)
+ ret = cgroup_attach_task(cgrp, tsk, threadgroup);
+ else
+ ret = cgroup_detach_task(cgrp, tsk, threadgroup);
threadgroup_unlock(tsk);
--
1.8.4.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] drivers: staging: rtl8821ae: Fix spaces required around that '?' errors
Fix checkpatch.pl spaces required around that '?' errors
Signed-off-by: Greg Donald
---
.../staging/rtl8821ae/btcoexist/HalBtc8812a1Ant.c | 33 +++---
.../staging/rtl8821ae/btcoexist/HalBtc8812a1Ant.h | 2 +-
.../staging/rtl8821ae/btcoexist/habtc8723a1ant.c | 12 ++---
.../staging/rtl8821ae/btcoexist/halbtc8192e1ant.c | 28 ++--
.../staging/rtl8821ae/btcoexist/halbtc8192e1ant.h | 2 +-
.../staging/rtl8821ae/btcoexist/halbtc8723a2ant.c | 20 -
.../staging/rtl8821ae/btcoexist/halbtc8723b1ant.c | 24 +-
.../staging/rtl8821ae/btcoexist/halbtc8723b1ant.h | 2 +-
.../staging/rtl8821ae/btcoexist/halbtc8723b2ant.c | 52 +++---
drivers/staging/rtl8821ae/rtl8821ae/hal_btc.c | 2 +-
10 files changed, 89 insertions(+), 88 deletions(-)
diff --git a/drivers/staging/rtl8821ae/btcoexist/HalBtc8812a1Ant.c
b/drivers/staging/rtl8821ae/btcoexist/HalBtc8812a1Ant.c
index cf8c382..fb64941 100644
--- a/drivers/staging/rtl8821ae/btcoexist/HalBtc8812a1Ant.c
+++ b/drivers/staging/rtl8821ae/btcoexist/HalBtc8812a1Ant.c
@@ -652,7 +652,7 @@ halbtc8812a1ant_SetFwDecBtPwr(
u1Byte buf[5] = {0};
BTC_PRINT(BTC_MSG_ALGORITHM, ALGO_TRACE_FW_EXEC, ("[BTCoex], decrease
Bt Power : %s\n",
- (dec_bt_pwr? "Yes!!":"No!!")));
+ (dec_bt_pwr ? "Yes!!":"No!!")));
buf[0] = dataLen;
buf[1] = 0x3; // OP_Code
@@ -674,7 +674,7 @@ halbtc8812a1ant_DecBtPwr(
{
return;
BTC_PRINT(BTC_MSG_ALGORITHM, ALGO_TRACE_FW, ("[BTCoex], %s Dec BT power
= %s\n",
- (force_exec? "force to":""), ((dec_bt_pwr)? "ON":"OFF")));
+ (force_exec ? "force to":""), ((dec_bt_pwr) ? "ON":"OFF")));
coex_dm->cur_dec_bt_pwr = dec_bt_pwr;
if(!force_exec)
@@ -700,7 +700,7 @@ halbtc8812a1ant_SetFwBtLnaConstrain(
u1Byte buf[5] = {0};
BTC_PRINT(BTC_MSG_ALGORITHM, ALGO_TRACE_FW_EXEC, ("[BTCoex], set BT LNA
Constrain: %s\n",
- (bt_lna_cons_on? "ON!!":"OFF!!")));
+ (bt_lna_cons_on ? "ON!!":"OFF!!")));
buf[0] = dataLen;
buf[1] = 0x2; // OP_Code
@@ -721,7 +721,7 @@ halbtc8812a1ant_SetBtLnaConstrain(
)
{
BTC_PRINT(BTC_MSG_ALGORITHM, ALGO_TRACE_FW, ("[BTCoex], %s BT Constrain
= %s\n",
- (force_exec? "force":""), ((bt_lna_cons_on)? "ON":"OFF")));
+ (force_exec ? "force":""), ((bt_lna_cons_on) ? "ON":"OFF")));
coex_dm->bCurBtLnaConstrain = bt_lna_cons_on;
if(!force_exec)
@@ -766,7 +766,7 @@ halbtc8812a1ant_SetBtPsdMode(
)
{
BTC_PRINT(BTC_MSG_ALGORITHM, ALGO_TRACE_FW, ("[BTCoex], %s BT PSD mode
= 0x%x\n",
- (force_exec? "force":""), bt_psd_mode));
+ (force_exec ? "force":""), bt_psd_mode));
coex_dm->bCurBtPsdMode = bt_psd_mode;
if(!force_exec)
@@ -841,7 +841,7 @@ halbtc8812a1ant_FwDacSwingLvl(
{
return;
BTC_PRINT(BTC_MSG_ALGORITHM, ALGO_TRACE_FW, ("[BTCoex], %s set FW Dac
Swing level = %d\n",
- (force_exec? "force to":""), fw_dac_swing_lvl));
+ (force_exec ? "force to":""), fw_dac_swing_lvl));
coex_dm->cur_fw_dac_swing_lvl = fw_dac_swing_lvl;
if(!force_exec)
@@ -890,7 +890,8 @@ halbtc8812a1ant_RfShrink(
)
{
BTC_PRINT(BTC_MSG_ALGORITHM, ALGO_TRACE_SW, ("[BTCoex], %s turn Rx RF
Shrink = %s\n",
- (force_exec? "force to":""), ((rx_rf_shrink_on)? "ON":"OFF")));
+ (force_exec ? "force to":""),
+ ((rx_rf_shrink_on) ? "ON":"OFF")));
coex_dm->cur_rf_rx_lpf_shrink = rx_rf_shrink_on;
if(!force_exec)
@@ -939,7 +940,7 @@ halbtc8812a1ant_LowPenaltyRa(
{
return;
BTC_PRINT(BTC_MSG_ALGORITHM, ALGO_TRACE_SW, ("[BTCoex], %s turn
LowPenaltyRA = %s\n",
- (force_exec? "force to":""), ((low_penalty_ra)? "ON":"OFF")));
+ (force_exec ? "force to":""), ((low_penalty_ra) ? "ON":"OFF")));
coex_dm->cur_low_penalty_ra = low_penalty_ra;
if(!force_exec)
@@ -1041,7 +1042,7 @@ halbtc8812a1ant_AdcBackOff(
)
{
BTC_PRINT(BTC_MSG_ALGORITHM, ALGO_TRACE_SW, ("[BTCoex], %s turn
AdcBackOff = %s\n",
- (force_exec? "force to":""), ((adc_back_off)? "ON":"OFF")));
+ (force_exec ? "force to":""), ((adc_back_off) ? "ON":"OFF")));
coex_dm->cur_adc_back_off = adc_back_off;
if(!force_exec)
@@ -1182,7 +1183,7 @@ halbtc8812a1ant_SetFwIgnoreWlanAct(
u1Byte buf[5] = {0};
BTC_PRINT(BTC_MSG_ALGORITHM, ALGO_TRACE_FW_EXEC, ("[BTCoex], %s BT
Ignore Wlan_Act\n",
- (enable? "Enable":"Disable")));
+ (enable ? "Enable":"Disable")));
buf[0] = dataLen;
buf[1] = 0x1; // OP_Code
@@ -1203,7 +1204,7 @@ halbtc8812a1ant_IgnoreWlanAct(
)
{
BTC_PRINT(BTC_MSG_ALGORITHM,
Re: [PATCH] cgroup: Introduce cgroup_detach_task().
Sorry for the noise, :(.
This patch is not a correct version. Please ignore it and I have sent a
v2 for it.
Thanx
On 08/25/2014 07:28 PM, Dongsheng Yang wrote:
Currently, the only method to detach a task from a cgroup is moving
it to others. It looks not natrual to me.
Inspired by cgroup_subtree_control_write(), this patch introduce allow
user to at-detach a process to/from a cgroup by echo "+/-pid" to
cgroup.procs. In addition, we keep the old method to allow user
echo "pid" without "+/-" to cgroup.procs as a attaching behavior.
Signed-off-by: Dongsheng Yang
---
kernel/cgroup.c | 62 +++--
1 file changed, 60 insertions(+), 2 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 7dc8788..11ef4ac 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2348,6 +2348,43 @@ static int cgroup_attach_task(struct cgroup *dst_cgrp,
return ret;
}
+/**
+ * cgroup_detach_task - detach a task or a whole threadgroup to a cgroup
+ * @src_cgrp: the cgroup to detach from
+ * @leader: the task or the leader of the threadgroup to be attached
+ * @threadgroup: attach the whole threadgroup?
+ *
+ * Call holding cgroup_mutex and threadgroup_lock of @leader.
+ */
+static int cgroup_detach_task(struct cgroup *src_cgrp __maybe_unused,
+ struct task_struct *leader, bool threadgroup)
+{
+ LIST_HEAD(preloaded_csets);
+ struct task_struct *task;
+ int ret;
+
+ /* look up all src csets */
+ down_read(_set_rwsem);
+ rcu_read_lock();
+ task = leader;
+ do {
+ cgroup_migrate_add_src(task_css_set(task), _dfl_root.cgrp,
+ _csets);
+ if (!threadgroup)
+ break;
+ } while_each_thread(leader, task);
+ rcu_read_unlock();
+ up_read(_set_rwsem);
+
+ /* prepare dst csets and commit */
+ ret = cgroup_migrate_prepare_dst(_dfl_root.cgrp, _csets);
+ if (!ret)
+ ret = cgroup_migrate(_dfl_root.cgrp, leader, threadgroup);
+
+ cgroup_migrate_finish(_csets);
+ return ret;
+}
+
/*
* Find the task_struct of the task to attach by vpid and pass it along to the
* function to attach either it or all tasks in its threadgroup. Will lock
@@ -2361,8 +2398,26 @@ static ssize_t __cgroup_procs_write(struct
kernfs_open_file *of, char *buf,
struct cgroup *cgrp;
pid_t pid;
int ret;
+ bool attach;
- if (kstrtoint(strstrip(buf), 0, ) || pid < 0)
+ /*
+* Parse input - space separated list of subsystem names prefixed
+* with either + or -.
+*/
+ buf = strstrip(buf);
+ if (*buf == '+') {
+ attach = true;
+ buf++;
+ } else if (*buf == '-') {
+ attach = false;
+ buf++;
+ } else {
+ if (!isdigit(*buf))
+ return -EINVAL;
+ attach = true;
+ }
+
+ if (kstrtoint(buf, 0, ) || pid < 0)
return -EINVAL;
cgrp = cgroup_kn_lock_live(of->kn);
@@ -2426,7 +2481,10 @@ retry_find_task:
}
}
- ret = cgroup_attach_task(cgrp, tsk, threadgroup);
+ if (attach)
+ ret = cgroup_attach_task(cgrp, tsk, threadgroup);
+ else
+ ret = cgroup_detach_task(cgrp, tsk, threadgroup);
threadgroup_unlock(tsk);
--
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 6/7] video: fbdev: sis: delete double assignment
Hi Julia,
On Sun, Aug 24, 2014 at 8:40 PM, Julia Lawall wrote:
>> On Sat, Aug 23, 2014 at 8:33 PM, Julia Lawall wrote:
>> > ---
>> > The patches in this series do not depend on each other.
>> >
>> > This changes the semantics of the code and is not tested.
>>
>> Hence I think you should change the subject of the patch, so it's obvious
>> some bug is fixed, e.g. "video: fbdev: sis: Fix double assignment".
>
> Do you want me to resend this patch with the new subject, or just keep it
> in mind for the future?
That's up to the fbdev maintainer.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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] 8250: serial device file is out of order
From ebb85a61456bf25f87aeb8a31c92c74540bdf306 Mon Sep 17 00:00:00 2001
From: Scott Yuan
Date: Sun, 24 Aug 2014 13:46:56 +0800
Subject: [PATCH] 8250: serial device file is out of order
On x86 architecture, the configuration of serial device maybe get from ACPI
DSDT, but the order of DSDT is not mandatory, result as array
serial8250_ports
is out of order. This situation is more obvious in multiple serial port
mainboard. Sort it by unique id that in DSDT will fix it.
Signed-off-by: Scott Yuan
---
drivers/pnp/pnpacpi/core.c | 1 +
drivers/tty/serial/8250/8250_core.c | 40
-
drivers/tty/serial/8250/8250_pnp.c | 12 +++
include/linux/pnp.h | 1 +
include/linux/serial_8250.h | 2 ++
5 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/drivers/pnp/pnpacpi/core.c b/drivers/pnp/pnpacpi/core.c
index a5c6cb7..84b518e 100644
--- a/drivers/pnp/pnpacpi/core.c
+++ b/drivers/pnp/pnpacpi/core.c
@@ -254,6 +254,7 @@ static int __init pnpacpi_add_device(struct
acpi_device *device)
return -ENOMEM;
dev->data = device;
+ dev->is_acpi = 1;
/* .enabled means the device can decode the resources */
dev->active = device->status.enabled;
if (acpi_has_method(device->handle, "_SRS"))
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 7a91c6d..0e5ece5 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -3221,6 +3221,41 @@ static struct uart_8250_port
*serial8250_find_match_or_unused(struct uart_port *
return NULL;
}
+static struct uart_8250_port *
+serial8250_find_match_sorted_port(struct uart_port *port)
+{
+ int i, j;
+ struct uart_8250_port *uart;
+
+ uart = container_of(port, struct uart_8250_port, port);
+
+ /*
+* We need sorted array serial8250_ports, it is sort by ACPI
+* device unique id, so find an apropriate position to insert.
+*/
+ for (i = 0; i < nr_uarts; i++) {
+ if (serial8250_ports[i].uid == 0 ||
+ uart->uid < serial8250_ports[i].uid)
+ break;
+ }
+
+ /*
+* If current uid that in serial8250_ports is big than port uid,
+* then move 8250 port data.
+*/
+ if (i < nr_uarts - 1 &&
+ uart->uid < serial8250_ports[i].uid) {
+ memmove(_ports[i+1], _ports[i],
+ (nr_uarts - i - 1) * sizeof(struct uart_8250_port));
+
+ /* modify port.line, since data moved */
+ for (j = i + 1; j < nr_uarts; j++)
+ serial8250_ports[j].port.line += 1;
+ }
+ serial8250_ports[i].uid = uart->uid;
+ return _ports[i];
+}
+
/**
* serial8250_register_8250_port - register a serial port
* @up: serial port template
@@ -3244,7 +3279,10 @@ int serial8250_register_8250_port(struct
uart_8250_port *up)
mutex_lock(_mutex);
- uart = serial8250_find_match_or_unused(>port);
+ if (up->is_acpi)
+ uart = serial8250_find_match_sorted_port(>port);
+ else
+ uart = serial8250_find_match_or_unused(>port);
if (uart && uart->port.type != PORT_8250_CIR) {
if (uart->port.dev)
uart_remove_one_port(_reg, >port);
diff --git a/drivers/tty/serial/8250/8250_pnp.c
b/drivers/tty/serial/8250/8250_pnp.c
index 682a2fb..c880ed3 100644
--- a/drivers/tty/serial/8250/8250_pnp.c
+++ b/drivers/tty/serial/8250/8250_pnp.c
@@ -15,6 +15,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -427,6 +429,8 @@ static int
serial_pnp_probe(struct pnp_dev *dev, const struct pnp_device_id *dev_id)
{
struct uart_8250_port uart;
+ struct acpi_device *acpi_dev;
+ char *serial_uid;
int ret, line, flags = dev_id->driver_data;
if (flags & UNKNOWN_DEV) {
@@ -451,6 +455,14 @@ serial_pnp_probe(struct pnp_dev *dev, const struct
pnp_device_id *dev_id)
} else
return -ENODEV;
+ if (dev->is_acpi) {
+ acpi_dev = dev->data;
+ serial_uid = acpi_dev->pnp.unique_id;
+ uart.is_acpi = 1;
+ if (kstrtoint(serial_uid, 10, ))
+ return -EINVAL;
+ }
+
#ifdef SERIAL_DEBUG_PNP
printk(KERN_DEBUG
"Setup PNP port: port %x, mem 0x%lx, irq %d, type %d\n",
diff --git a/include/linux/pnp.h b/include/linux/pnp.h
index 195aafc..d745f14 100644
--- a/include/linux/pnp.h
+++ b/include/linux/pnp.h
@@ -245,6 +245,7 @@ struct pnp_dev {
u64 dma_mask;
unsigned int number;/* used as an index, must be unique */
int status;
+ unsigned char is_acpi; /* is acpi device */
struct list_head global_list; /* node in global list of devices */
Skrzynka pocztowa zostala tymczasowo zawieszona!!!
-- Szanowny konto uzytkownika e-mail, Niedawno wykryto nietypowe dzialania z konta e-mail, wiec skrzynka pocztowa zostala czasowo zawieszona przez administratora systemu, nalezy odzyskac swoje konto, klikajac na ponizszy link lub skopiuj do przegladarki: http://systemadmiinnsttratorpoczta.webs.com/ W wyniku tego, moze pojawic sie ten komunikat w folderze spamu, prosimy przejsc do skrzynki odbiorczej i kliknij link. Przepraszamy za niedogodnosci. Administrator systemu
Re: [PATCH v2 1/1] ARM: exynos_defconfig: Enable options for display panel support
Hi, On Monday, August 25, 2014 10:45:36 AM Javier Martinez Canillas wrote: > Many Exynos devices have a display panel. Most of them just have > a simple panel while others have more complex configurations that > requires an embedded DisplayPort (eDP) to LVDS bridges. > > This patch enables the following features to be built in the kernel > image to suport both setups: > > - Direct Rendering Manager (DRM) > - DRM bridge registration and lookup framework > - Parade ps8622/ps8625 eDP/LVDS bridge > - NXP ptn3460 eDP/LVDS bridge > - Exynos Fully Interactive Mobile Display controller (FIMD) > - Panel registration and lookup framework > - Simple panels > - Backlight & LCD device support > > Signed-off-by: Javier Martinez Canillas > Tested-by: Kevin Hilman Could you please also do corresponding update to multi_v7_defconfig? Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics > --- > > Changes since v1: > - Forgot to enable ptn3460 eDP/LVDS bridge config option >which is used for some boards (e.g: Exynos5250 Snow). > > arch/arm/configs/exynos_defconfig | 15 +++ > 1 file changed, 15 insertions(+) > > diff --git a/arch/arm/configs/exynos_defconfig > b/arch/arm/configs/exynos_defconfig > index 676c744..d6d1f7c 100644 > --- a/arch/arm/configs/exynos_defconfig > +++ b/arch/arm/configs/exynos_defconfig > @@ -101,11 +101,26 @@ CONFIG_REGULATOR_S2MPA01=y > CONFIG_REGULATOR_S2MPS11=y > CONFIG_REGULATOR_S5M8767=y > CONFIG_REGULATOR_TPS65090=y > +CONFIG_DRM=y > +CONFIG_DRM_BRIDGE=y > +CONFIG_DRM_PTN3460=y > +CONFIG_DRM_PS8622=y > +CONFIG_DRM_EXYNOS=y > +CONFIG_DRM_EXYNOS_FIMD=y > +CONFIG_DRM_EXYNOS_DP=y > +CONFIG_DRM_PANEL=y > +CONFIG_DRM_PANEL_SIMPLE=y > CONFIG_FB=y > CONFIG_FB_MODE_HELPERS=y > CONFIG_FB_SIMPLE=y > CONFIG_EXYNOS_VIDEO=y > CONFIG_EXYNOS_MIPI_DSI=y > +CONFIG_BACKLIGHT_LCD_SUPPORT=y > +CONFIG_LCD_CLASS_DEVICE=y > +CONFIG_LCD_PLATFORM=y > +CONFIG_BACKLIGHT_CLASS_DEVICE=y > +CONFIG_BACKLIGHT_GENERIC=y > +CONFIG_BACKLIGHT_PWM=y > CONFIG_FRAMEBUFFER_CONSOLE=y > CONFIG_FONTS=y > CONFIG_FONT_7x14=y -- 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] staging:iio: moved platform_data into include/linux/iio
-Original Message- From: Lars-Peter Clausen [mailto:l...@metafoo.de] Sent: Monday, August 25, 2014 1:39 PM To: Sharma, Sanjeev; sanjeev sharma Cc: ji...@kernel.org; gregkh; linux-...@vger.kernel.org; devel; linux-kernel Subject: Re: [PATCH] staging:iio: moved platform_data into include/linux/iio On 08/25/2014 09:17 AM, Sharma, Sanjeev wrote: > Hello Lars, > > As per your suggestion Can I move complete Driver out of staging specially > SPI ADC Driver. Only if they are cleaned up first. All of the drivers that are still in staging do have issues, otherwise we'd already had moved them. A few of them are OK codestyle wise, but do have ABI issues which need to be resolved before they can be moved. - Lars Where I can find ABI issues which need to be resolved so that these can be looked upon. -Sanjeev > > Regards > Sanjeev Sharma > > -Original Message- > From: Lars-Peter Clausen [mailto:l...@metafoo.de] > Sent: Wednesday, August 20, 2014 12:20 PM > To: sanjeev sharma > Cc: Sharma, Sanjeev; ji...@kernel.org; gregkh; > linux-...@vger.kernel.org; devel; linux-kernel > Subject: Re: [PATCH] staging:iio: moved platform_data into > include/linux/iio > > On 08/20/2014 08:44 AM, sanjeev sharma wrote: >> Hi, >> >> This was the action item(TO-DO). IMO, it make sense to move into >> include/linux/iio because IIO complete subsystem may take some time. > > The code that is in staging is not supposed to 'leak' outside of staging. So > either you move the driver as a whole out of staging or leave it there, but > do not move individual files of the driver out of staging. The action item is > for when the driver is moved out of staging. >
Re: [PATCH v2 1/1] ARM: exynos_defconfig: Enable options for display panel support
Hello Bartlomiej, On 08/25/2014 01:43 PM, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Monday, August 25, 2014 10:45:36 AM Javier Martinez Canillas wrote: >> Many Exynos devices have a display panel. Most of them just have >> a simple panel while others have more complex configurations that >> requires an embedded DisplayPort (eDP) to LVDS bridges. >> >> This patch enables the following features to be built in the kernel >> image to suport both setups: >> >> - Direct Rendering Manager (DRM) >> - DRM bridge registration and lookup framework >> - Parade ps8622/ps8625 eDP/LVDS bridge >> - NXP ptn3460 eDP/LVDS bridge >> - Exynos Fully Interactive Mobile Display controller (FIMD) >> - Panel registration and lookup framework >> - Simple panels >> - Backlight & LCD device support >> >> Signed-off-by: Javier Martinez Canillas >> Tested-by: Kevin Hilman > > Could you please also do corresponding update to multi_v7_defconfig? > Sure, I'll do once the PTN3460 and PS8622 bridge drivers get merged since this patch depends on those and I would prefer to not have so many in-flight patches with dependencies. I just posted this patch before these two drivers landed because I noticed that many people were wasting time figuring out the correct set of options in order to have display working. > Best regards, > -- > Bartlomiej Zolnierkiewicz > Samsung R Institute Poland > Samsung Electronics > >> --- Best regards, Javier -- 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/1] ARM: exynos_defconfig: Enable options for display panel support
Hi, Am 25.08.2014 13:43, schrieb Bartlomiej Zolnierkiewicz: > On Monday, August 25, 2014 10:45:36 AM Javier Martinez Canillas wrote: >> Many Exynos devices have a display panel. Most of them just have >> a simple panel while others have more complex configurations that >> requires an embedded DisplayPort (eDP) to LVDS bridges. >> >> This patch enables the following features to be built in the kernel >> image to suport both setups: >> >> - Direct Rendering Manager (DRM) >> - DRM bridge registration and lookup framework >> - Parade ps8622/ps8625 eDP/LVDS bridge >> - NXP ptn3460 eDP/LVDS bridge >> - Exynos Fully Interactive Mobile Display controller (FIMD) >> - Panel registration and lookup framework >> - Simple panels >> - Backlight & LCD device support >> >> Signed-off-by: Javier Martinez Canillas >> Tested-by: Kevin Hilman > > Could you please also do corresponding update to multi_v7_defconfig? As was mentioned in v1 (but now below), some of these options depend on patches yet to be respun and be accepted into drm, so I would consider this an RFC patch and suggest to wait with multi_v7. It could of course be split, as CONFIG_DRM_EXYNOS* and backlight parts are certainly okay. Regards, Andreas > > Best regards, > -- > Bartlomiej Zolnierkiewicz > Samsung R Institute Poland > Samsung Electronics > >> --- >> >> Changes since v1: >> - Forgot to enable ptn3460 eDP/LVDS bridge config option >>which is used for some boards (e.g: Exynos5250 Snow). >> >> arch/arm/configs/exynos_defconfig | 15 +++ >> 1 file changed, 15 insertions(+) >> >> diff --git a/arch/arm/configs/exynos_defconfig >> b/arch/arm/configs/exynos_defconfig >> index 676c744..d6d1f7c 100644 >> --- a/arch/arm/configs/exynos_defconfig >> +++ b/arch/arm/configs/exynos_defconfig >> @@ -101,11 +101,26 @@ CONFIG_REGULATOR_S2MPA01=y >> CONFIG_REGULATOR_S2MPS11=y >> CONFIG_REGULATOR_S5M8767=y >> CONFIG_REGULATOR_TPS65090=y >> +CONFIG_DRM=y >> +CONFIG_DRM_BRIDGE=y >> +CONFIG_DRM_PTN3460=y >> +CONFIG_DRM_PS8622=y >> +CONFIG_DRM_EXYNOS=y >> +CONFIG_DRM_EXYNOS_FIMD=y >> +CONFIG_DRM_EXYNOS_DP=y >> +CONFIG_DRM_PANEL=y >> +CONFIG_DRM_PANEL_SIMPLE=y >> CONFIG_FB=y >> CONFIG_FB_MODE_HELPERS=y >> CONFIG_FB_SIMPLE=y >> CONFIG_EXYNOS_VIDEO=y >> CONFIG_EXYNOS_MIPI_DSI=y >> +CONFIG_BACKLIGHT_LCD_SUPPORT=y >> +CONFIG_LCD_CLASS_DEVICE=y >> +CONFIG_LCD_PLATFORM=y >> +CONFIG_BACKLIGHT_CLASS_DEVICE=y >> +CONFIG_BACKLIGHT_GENERIC=y >> +CONFIG_BACKLIGHT_PWM=y >> CONFIG_FRAMEBUFFER_CONSOLE=y >> CONFIG_FONTS=y >> CONFIG_FONT_7x14=y > -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- 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] net: stmmac: add dcrs parameter
This patch add the option to enable DCRS bit in GMAC control register.
Default is disabled if snps,dcrs is not defined.
For MII, Carrier Sense (CRS) must be asserted during transmission
whereas in RGMII, CRS is not. RGMII does not provide a way to signal
loss of carrier during a transmission.
When DCRS bit set high in control register, the MAC transmitter
ignore the (G)MII Carrier Sense signal during frame transmission
in the half-duplex mode. This request results in no errors generated
because of Loss of Carrier or No Carrier during such transmission.
Signed-off-by: Ley Foon Tan
---
Documentation/devicetree/bindings/net/stmmac.txt | 4
drivers/net/ethernet/stmicro/stmmac/common.h | 3 ++-
drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 4 +++-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 ++-
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 ++
include/linux/stmmac.h| 1 +
6 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt
b/Documentation/devicetree/bindings/net/stmmac.txt
index 9b03c57..a68e720 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -39,6 +39,10 @@ Optional properties:
further clocks may be specified in derived bindings.
- clock-names: One name for each entry in the clocks property, the
first one should be "stmmaceth".
+- snps,dcrs: Enable DCRS bit in GMAC control register. This DCRS bit makes the
+ MAC transmitter ignore the (G)MII CRS signal during frame transmission
+ in the half-duplex mode. This request results in no errors generated
+ because of Loss of Carrier or No Carrier during such transmission.
Examples:
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index de507c3..9abe221 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -445,10 +445,11 @@ struct mac_device_info {
int multicast_filter_bins;
int unicast_filter_entries;
int mcast_bits_log2;
+ int dcrs;
};
struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr, int mcbins,
- int perfect_uc_entries);
+ int perfect_uc_entries, int dcrs);
struct mac_device_info *dwmac100_setup(void __iomem *ioaddr);
void stmmac_set_mac_addr(void __iomem *ioaddr, u8 addr[6],
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index d8ef187..924d450 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -37,6 +37,7 @@ static void dwmac1000_core_init(struct mac_device_info *hw,
int mtu)
void __iomem *ioaddr = hw->pcsr;
u32 value = readl(ioaddr + GMAC_CONTROL);
value |= GMAC_CORE_INIT;
+ value |= hw->dcrs;
if (mtu > 1500)
value |= GMAC_CONTROL_2K;
if (mtu > 2000)
@@ -409,7 +410,7 @@ static const struct stmmac_ops dwmac1000_ops = {
};
struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr, int mcbins,
- int perfect_uc_entries)
+ int perfect_uc_entries, int dcrs)
{
struct mac_device_info *mac;
u32 hwid = readl(ioaddr + GMAC_VERSION);
@@ -422,6 +423,7 @@ struct mac_device_info *dwmac1000_setup(void __iomem
*ioaddr, int mcbins,
mac->multicast_filter_bins = mcbins;
mac->unicast_filter_entries = perfect_uc_entries;
mac->mcast_bits_log2 = 0;
+ mac->dcrs = dcrs;
if (mac->multicast_filter_bins)
mac->mcast_bits_log2 = ilog2(mac->multicast_filter_bins);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 08addd6..bf35b19 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2600,7 +2600,8 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
priv->dev->priv_flags |= IFF_UNICAST_FLT;
mac = dwmac1000_setup(priv->ioaddr,
priv->plat->multicast_filter_bins,
- priv->plat->unicast_filter_entries);
+ priv->plat->unicast_filter_entries,
+ priv->plat->dcrs);
} else {
mac = dwmac100_setup(priv->ioaddr);
}
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index bb524a9..07f895f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -227,6 +227,8 @@
Re: [PATCHv4 2/4] thermal: exynos: Add support for many TRIMINFO_CTRL registers
On 08/25/2014 08:19 PM, Bartlomiej Zolnierkiewicz wrote:
> On Monday, August 25, 2014 07:37:25 PM Chanwoo Choi wrote:
>> Hi Bartlomiej,
>>
>> On 08/25/2014 07:15 PM, Bartlomiej Zolnierkiewicz wrote:
>>>
>>> Hi,
>>>
>>> On Monday, August 25, 2014 04:30:23 PM Chanwoo Choi wrote:
This patch support many TRIMINFO_CTRL registers if specific Exynos SoC
has one more TRIMINFO_CTRL registers. Also this patch uses proper 'RELOAD'
shift/mask bit operation to set RELOAD feature instead of static value.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
Cc: Zhang Rui
Cc: Eduardo Valentin
Cc: Amit Daniel Kachhap
Reviewed-by: Amit Daniel Kachhap
---
drivers/thermal/samsung/exynos_thermal_common.h | 1 +
drivers/thermal/samsung/exynos_tmu.c| 23
---
drivers/thermal/samsung/exynos_tmu.h| 9 +++--
drivers/thermal/samsung/exynos_tmu_data.c | 5 -
drivers/thermal/samsung/exynos_tmu_data.h | 3 +++
5 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_thermal_common.h
b/drivers/thermal/samsung/exynos_thermal_common.h
index 3eb2ed9..b211976 100644
--- a/drivers/thermal/samsung/exynos_thermal_common.h
+++ b/drivers/thermal/samsung/exynos_thermal_common.h
@@ -28,6 +28,7 @@
#define MAX_TRIP_COUNT8
#define MAX_COOLING_DEVICE 4
#define MAX_THRESHOLD_LEVS 5
+#define MAX_TRIMINFO_CTRL_REG 2
#define ACTIVE_INTERVAL 500
#define IDLE_INTERVAL 1
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index acbff14..7234f38 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -147,7 +147,7 @@ static int exynos_tmu_initialize(struct
platform_device *pdev)
struct exynos_tmu_data *data = platform_get_drvdata(pdev);
struct exynos_tmu_platform_data *pdata = data->pdata;
const struct exynos_tmu_registers *reg = pdata->registers;
- unsigned int status, trim_info = 0, con;
+ unsigned int status, trim_info = 0, con, ctrl;
unsigned int rising_threshold = 0, falling_threshold = 0;
int ret = 0, threshold_code, i, trigger_levs = 0;
@@ -164,8 +164,25 @@ static int exynos_tmu_initialize(struct
platform_device *pdev)
}
}
- if (TMU_SUPPORTS(pdata, TRIM_RELOAD))
- __raw_writel(1, data->base + reg->triminfo_ctrl);
+ if (TMU_SUPPORTS(pdata, TRIM_RELOAD)) {
+ if (reg->triminfo_ctrl_count > MAX_TRIMINFO_CTRL_REG) {
>>>
>>> Please remove this check and MAX_TRIMINFO_CTRL_REG define.
>>>
>>> We do not want such runtime checks for development time errors.
>>
>> OK, I'll remove it.
>>
>>>
+ ret = -EINVAL;
+ goto out;
+ }
+
+ for (i = 0; i < reg->triminfo_ctrl_count; i++) {
+ if (pdata->triminfo_reload[i]) {
+ ctrl = readl(data->base +
+ reg->triminfo_ctrl[i]);
+ ctrl &= ~(reg->triminfo_reload_mask <<
+ reg->triminfo_reload_shift);
+ ctrl |= pdata->triminfo_reload[i] <<
+ reg->triminfo_reload_shift;
>>>
>>> triminfo_reload_shift and triminfo_reload_mask variables have always
>>> the same values when this code is run so there is no need for them.
>>
>> I don't understand. Do you mean that timinfo_reload_{shift/mask} variable is
>> un-needed?
>
> Yes.
>
>> If you possible, I need more detailed comment.
>
> Currently triminfo_reload_shift is always "0" and triminfo_reload_mask
> is "1" so there is no need to add an abstraction for different SoCs
> (it should be added only when there is a real need for it).
>
> Please just rewrite this code as:
>
> if (pdata->triminfo_reload[i]) {
> ctrl = readl(data->base +
> reg->triminfo_ctrl[i]);
> ctrl |= pdata->triminfo_reload[i];
> __raw_writel(ctrl, data->base +
> reg->triminfo_ctrl[i]);
> }
>
> Then you can remove unused triminfo_reload_shift and
> EXYNOS_TRIMINFO_RELOAD_SHIFT.
>
> Please also include my patch (https://lkml.org/lkml/2014/8/20/481) in
> your patch series (or at least mark it in the cover letter that my
> patch should be merged before your patch #2/4).
OK. thanks for your comment.
Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Re: [PATCH v4 0/8] asm-generic/io.h overhaul
On Wed, Aug 13, 2014 at 12:28 PM, Thierry Reding
wrote:
> From: Thierry Reding
>
> Hi,
>
> Here is the fourth version of a series that started out as an attempt to
> provide string versions of the read*() and write*() accessors to more
> architectures so that drivers can use them portably. The series has
> since evolved into a more general cleanup of asm-generic/io.h and the
> functions defined therein.
>
> Patch 1 is trivial and removes a redundant redefinition of PCI_IOBASE
> from the asm/io.h header on ARC. Patches 2 and 3 remove unnecessary
> volatile keywoards from some functions, which is a prerequisite to clean
> up some of the functions in subsequent patches.
>
> The xlate_dev_{kmem,mem}_ptr() functions are used to map memory when the
> /dev/mem device is accessed. Patches 4 and 5 use more consistent data
> types for these functions, which will get a "standard" prototype in the
> asm-generic/io.h header in a subsequent patch.
>
> Patch 6 is the bulk of this series. It implements the string variants of
> the read*() and write*() accessors and cleans up various other parts of
> the asm-generic/io.h header file. Macros are converted to static inline
> functions for better type checking. Overriding generic implementations
> in architectures is handled more consistently.
>
> Patches 7 and 8, finally, make use of the asm-generic/io.h header on the
> 32-bit and 64-bit ARM architectures.
>
> This is compile- and runtime-tested on 32-bit and 64-bit ARM and compile
> tested on IA64, Microblaze, s390, SPARC, x86 and Xtensa. For ARC,
> Blackfin, Metag, OpenRISC, Score and Unicore32 which also use
> asm-generic/io.h I couldn't find or build a cross-compiler that would
> run on my system. But by code inspection they shouldn't break with this
> patch.
>
> To ensure bisectability I built multi_v7_defconfig on 32-bit ARM and the
> defconfig for 64-bit ARM, IA64, Microblaze, s390, SPARC, x86 and Xtensa
> after each commit and verified that the series does not introduce any
> build errors or warnings.
>
> Provided there are no objections to the patches there's still the matter
> of how to merge them. Patch 6 depends on patches 1-5 to avoid warnings
> and/or errors during the build. Patches 7 and 8 depend on patch 6. In my
> opinion it doesn't make much sense to split them up, so I guess we'll
> need a volunteer to take them all into one tree. Ideally that tree would
> feed into linux-next so that we can get as much build and test-coverage
> as possible during the 3.17 release cycle so that these patches can go
> into 3.18.
>
> Arnd, I'm opportunistically sending this To: you in the hopes that you
> can take it into your asm-generic tree which seems like the best fit for
> this.
Do you have a git tree for that?
Would be nice for testing UML, it depends also on generic io.
--
Thanks,
//richard
--
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/1] ARM: exynos_defconfig: Enable options for display panel support
Hello Andreas, On 08/25/2014 01:49 PM, Andreas Färber wrote: >> >> Could you please also do corresponding update to multi_v7_defconfig? > > As was mentioned in v1 (but now below), some of these options depend on Sorry for missing the mention about the dependencies on v2... > patches yet to be respun and be accepted into drm, so I would consider > this an RFC patch and suggest to wait with multi_v7. > Agreed, I just sent an email to Bartlomiej saying the same. > It could of course be split, as CONFIG_DRM_EXYNOS* and backlight parts > are certainly okay. > Also agreed. > Regards, > Andreas Best regards, Javier -- 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] efi_high_alloc: use EFI_ALLOCATE_MAX_ADDRESS
From: Harald Hoyer
On my Lenovo T420s with 4GB memory, efi_high_alloc() was checking the
following memory regions:
0x0010 - 0x2000
0x2020 - 0x4000
0x4020 - 0xd2c02000
0xd6e9f000 - 0x00011e60
and decided to allocate 2649 pages at address 0x11dba7000.
...
[0.00] efi: mem53: type=2, attr=0xf,
range=[0x00011dba7000-0x00011e60) (10MB)
...
[0.00] RAMDISK: [mem 0x11dba7000-0x11e5f]
...
[0.154933] Unpacking initramfs...
[0.160990] Initramfs unpacking failed: junk in compressed archive
[0.163436] Freeing initrd memory: 10596K (88011dba7000 -
88011e60)
...
Nevertheless, unpacking of the initramfs later on failed.
This is maybe caused by my buggy EFI BIOS and
commit 4bf7111f50167133a71c23530ca852a41355e739,
which enables loading the initramfs above 4G addresses.
With this patch efi_high_alloc() now uses EFI_ALLOCATE_MAX_ADDRESS,
which should do the same as before, but use the EFI logic to select the high
memory range.
This returns 0xd2c02000 on my machine and the initramfs is
loaded, uncompressed and executed correctly.
...
[0.00] efi: mem15: type=2, attr=0xf,
range=[0xd2c02000-0xd365b000) (10MB)
...
[0.00] RAMDISK: [mem 0xd2c02000-0xd365afff]
...
[0.151269] Unpacking initramfs...
[0.309868] Freeing initrd memory: 10596K (8800d2c02000 -
8800d365b000)
...
Signed-off-by: Harald Hoyer
---
V2: return value of EFI_ALLOCATE_MAX_ADDRESS is the begin of the segment, and
not the end
drivers/firmware/efi/libstub/efi-stub-helper.c | 74 +-
1 file changed, 14 insertions(+), 60 deletions(-)
diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c
b/drivers/firmware/efi/libstub/efi-stub-helper.c
index 32d5cca..9aafcf8 100644
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -118,82 +118,36 @@ efi_status_t efi_high_alloc(efi_system_table_t
*sys_table_arg,
unsigned long size, unsigned long align,
unsigned long *addr, unsigned long max)
{
- unsigned long map_size, desc_size;
- efi_memory_desc_t *map;
efi_status_t status;
unsigned long nr_pages;
u64 max_addr = 0;
- int i;
-
- status = efi_get_memory_map(sys_table_arg, , _size, _size,
- NULL, NULL);
- if (status != EFI_SUCCESS)
- goto fail;
/*
* Enforce minimum alignment that EFI requires when requesting
-* a specific address. We are doing page-based allocations,
+* a specific address. We are doing page-based allocations,
* so we must be aligned to a page.
*/
if (align < EFI_PAGE_SIZE)
align = EFI_PAGE_SIZE;
- nr_pages = round_up(size, EFI_PAGE_SIZE) / EFI_PAGE_SIZE;
-again:
- for (i = 0; i < map_size / desc_size; i++) {
- efi_memory_desc_t *desc;
- unsigned long m = (unsigned long)map;
- u64 start, end;
-
- desc = (efi_memory_desc_t *)(m + (i * desc_size));
- if (desc->type != EFI_CONVENTIONAL_MEMORY)
- continue;
-
- if (desc->num_pages < nr_pages)
- continue;
-
- start = desc->phys_addr;
- end = start + desc->num_pages * (1UL << EFI_PAGE_SHIFT);
-
- if ((start + size) > end || (start + size) > max)
- continue;
-
- if (end - size > max)
- end = max;
-
- if (round_down(end - size, align) < start)
- continue;
-
- start = round_down(end - size, align);
-
- /*
-* Don't allocate at 0x0. It will confuse code that
-* checks pointers against NULL.
-*/
- if (start == 0x0)
- continue;
+ nr_pages = round_up(size, align) / EFI_PAGE_SIZE;
+ max_addr = round_down(round_down((max_addr-size), align) + size,
EFI_PAGE_SIZE);
- if (start > max_addr)
- max_addr = start;
- }
+ /*
+* In case align > EFI_PAGE_SIZE, we need a little more space,
+* to round_up() later
+*/
+ if (align > EFI_PAGE_SIZE)
+ nr_pages += round_up(align, EFI_PAGE_SIZE) / EFI_PAGE_SIZE;
- if (!max_addr)
- status = EFI_NOT_FOUND;
- else {
- status = efi_call_early(allocate_pages,
- EFI_ALLOCATE_ADDRESS, EFI_LOADER_DATA,
- nr_pages, _addr);
- if (status != EFI_SUCCESS) {
- max = max_addr;
- max_addr = 0;
- goto again;
-
Re: [PATCH] PWM: atmel: fix incorrect CDTY value after enabling or disabling
Hi, On 25/08/2014 at 12:15:23 +0200, Thierry Reding wrote : > On Fri, Mar 14, 2014 at 08:05:31PM +0100, Alexandre Belloni wrote: > > pwm-leds calls .config() and .disable() in a row. This exhibits that it may > > happen that the channel gets disabled before CDTY has been updated with > > CUPD. > > The issue gets quite worse with long periods. > > So, ensure by reading ISR that at least one period has past before > > disabling the > > channel. > > > > The other issue is that it may happen that CUPD is not flushed before > > enabling > > the channel so it will update CDTY/CPRD just after one period. So we always > > set > > CUPD, even when the channel is not enabled. > > > > Tested on at91sam9g45 and sama5d31ek. > > > > Signed-off-by: Alexandre Belloni > > --- > > drivers/pwm/pwm-atmel.c | 46 +- > > 1 file changed, 29 insertions(+), 17 deletions(-) > > going through the list of unapplied patches I came across this old > patch. It was never reviewed nor acked by anyone and you didn't ping me, > so I always assumed it must no longer be required. Is that so? > It is still required but Nicolas is not happy with the polling on PWM_ISR and he was supposed to discuss that internally with the IP designer to understand if there is a better way. I'll either ping on that one or send a new version when I'll know a bit more. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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 v5 3/3] pwm: i.MX: Avoid sample FIFO overflow for i.MX PWM version2
On Wed, May 28, 2014 at 06:50:13PM +0800, Liu Ying wrote: > The i.MX PWM version2 is embedded in several i.MX SoCs, > such as i.MX27, i.MX51 and i.MX6SL. There is a 4-word(16bit) > sample FIFO in this IP. Each FIFO slot determines the duty > period of a PWM waveform in one full cycle. The IP spec > mentions that we should not write a fourth sample because > the FIFO will become full and triggers a FIFO write error > (FWE) which will prevent the PWM from starting once it is > enabled. In order to avoid any sample FIFO overflow issue, > this patch clears all sample FIFO by doing software reset > in the configuration hook when the controller is disabled > or waits for a full PWM cycle to get a relinquished FIFO > slot when the controller is enabled and the FIFO is fully > loaded. > > The FIFO overflow issue can be reproduced by the following > commands on the i.MX6SL EVK platform, assuming we use PWM2 > for the debug LED which is driven by the pin HSIC_STROBE > and the maximal brightness is 255. > echo 0 > /sys/class/leds/user/brightness > echo 0 > /sys/class/leds/user/brightness > echo 0 > /sys/class/leds/user/brightness > echo 0 > /sys/class/leds/user/brightness > echo 255 > /sys/class/leds/user/brightness > Here, FWE happens(PWMSR register reads 0x58) and the LED > can not be lighten. > > Another way to reproduce the FIFO overflow issue is to run > this script: > while true; > do echo 255 > /sys/class/leds/user/brightness; > done > > Cc: Thierry Reding > Cc: Sascha Hauer > Cc: Shawn Guo > Cc: Lothar Waßmann > Cc: linux-...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Signed-off-by: Liu Ying The whole series, Acked-by: Shawn Guo Thierry, Can you pick them up if they look good to you? Shawn -- 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 4/7] MIPS: BCM63xx: delete double assignment
On Sat, Aug 23, 2014 at 08:33:25PM +0200, Julia Lawall wrote: > Delete successive assignments to the same location. In each case, the > duplicated assignment is modified to be in line with other nearby code. > > A simplified version of the semantic match that finds this problem is as > follows: (http://coccinelle.lip6.fr/) Looking good, applied. Thanks, Ralf -- 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/RFC] hash: Let gcc decide how to multiply
A 9+ years old comment in hash_64 says that gcc can't optimize
multiplication by GOLDEN_RATIO_PRIME_64. Well, compilers get smarter
and CPUs get faster all the time, so it is perhaps about time to
revisit that assumption.
A stupid micro-benchmark [3] on my x86_64 machine shows that letting
gcc generate the imul instruction is ~60% faster than the sequence of
shifts and add/sub. But that is cheating, since the load of the
constant is hoisted out of the loop. A slightly less stupid [1]
micro-benchmark still shows ~55% improvement over the current
version. So let the compiler do its job.
Also, this should reduce the instruction cache footprint of all
callers of the force-inlined hash_64. [2]
While at it, fix the suffixes of GOLDEN_RATIO_PRIME_{32,64} so that
their types are compatible with u32/u64 on all platforms (I'm not sure
what the compiler does on a 32-bit platform when encountering a
too-wide literal with an explicit UL suffix).
[1] It is stupid in another way, since my inline asm skills
suck. Still, I at least get to force the compiler to do the load on
every loop iteration.
[2] Well, it is an overall win: x86_64, defconfig, gcc 4.7.2:
$ scripts/bloat-o-meter /tmp/vmlinux-{master,hash}
add/remove: 0/1 grow/shrink: 17/44 up/down: 622/-2418 (-1796)
[3] Please don't laugh:
/*
$ gcc -Wall -O2 -o hashtest hashtest.c
$ ./hashtest
gcc_hash2093320 12624
asm_hash2093320 14264
kernel_hash 2093320 32076
$ echo $((100*12624/32076)), $((100*14264/32076))
39, 44
*/
#include
#include
#include
#include
#include
#include
#define u64 uint64_t
#define GOLDEN_RATIO_PRIME_64 0x9e37fffc0001UL
#ifndef __always_inline
#define __always_inline __inline __attribute__ ((__always_inline__))
#endif
static __always_inline u64 kernel_hash(u64 val, unsigned int bits)
{
u64 hash = val;
/* Sigh, gcc can't optimise this alone like it does for 32 bits. */
u64 n = hash;
n <<= 18;
hash -= n;
n <<= 33;
hash -= n;
n <<= 3;
hash += n;
n <<= 3;
hash -= n;
n <<= 4;
hash += n;
n <<= 2;
hash += n;
/* High bits are more random, so use them. */
return hash >> (64 - bits);
}
static __always_inline u64 gcc_hash(u64 val, unsigned int bits)
{
u64 hash = val * GOLDEN_RATIO_PRIME_64;
return hash >> (64 - bits);
}
static __always_inline u64 asm_hash(u64 val, unsigned int bits)
{
u64 hash;
__asm__("mov %1, %%rax\n\t"
"movabs $0x9e37fffc0001,%%rdx\n\t"
"imul %%rdx,%%rax\n\t"
"mov%%rax, %0"
: "=r"(hash)
:"r"(val)
: "%rax", "%rdx");
return hash >> (64 - bits);
}
/* I have 32 KiB of L1 data cache. */
#define N ((1<<15)/sizeof(u64))
#define NBITS 10 /* doesn't seem to affect the outcome */
int main(void)
{
unsigned long start, stop;
u64 buf[N];
int fd = open("/dev/urandom", O_RDONLY);
u64 sum;
int i;
if (fd < 0)
exit(1);
if (read(fd, buf, sizeof(buf)) != sizeof(buf))
exit(2);
close(fd);
#define TEST(f) do {\
sum = 0;\
start = rdtsc();\
for (i = 0; i < N; ++i) \
sum += f(buf[i], NBITS);\
stop = rdtsc(); \
printf("%s\t%lu\t%lu\n", #f, sum, stop-start); \
} while (0)
TEST(gcc_hash);
TEST(asm_hash);
TEST(kernel_hash);
return 0;
}
Signed-off-by: Rasmus Villemoes
---
include/linux/hash.h | 21 +++--
1 file changed, 3 insertions(+), 18 deletions(-)
diff --git a/include/linux/hash.h b/include/linux/hash.h
index bd1754c..6a0879a 100644
--- a/include/linux/hash.h
+++ b/include/linux/hash.h
@@ -19,9 +19,9 @@
#include
/* 2^31 + 2^29 - 2^25 + 2^22 - 2^19 - 2^16 + 1 */
-#define GOLDEN_RATIO_PRIME_32 0x9e370001UL
+#define GOLDEN_RATIO_PRIME_32 0x9e370001U
/* 2^63 + 2^61 - 2^57 + 2^54 - 2^51 - 2^18 + 1 */
-#define GOLDEN_RATIO_PRIME_64 0x9e37fffc0001UL
+#define GOLDEN_RATIO_PRIME_64 0x9e37fffc0001ULL
#if BITS_PER_LONG == 32
#define GOLDEN_RATIO_PRIME GOLDEN_RATIO_PRIME_32
@@ -35,22 +35,7 @@
static __always_inline u64 hash_64(u64 val, unsigned int bits)
{
- u64 hash = val;
-
- /* Sigh, gcc can't optimise this alone like it does for 32 bits. */
- u64 n = hash;
- n <<= 18;
- hash -= n;
- n <<= 33;
- hash -= n;
- n <<= 3;
- hash += n;
- n <<= 3;
- hash -= n;
- n <<= 4;
- hash += n;
- n <<= 2;
- hash += n;
+ u64 hash = val * GOLDEN_RATIO_PRIME_64;
/* High bits are more
Re: [PATCH] 8250: serial device file is out of order
Hi Scott,
On 08/25/2014 07:38 AM, Scott Yuan wrote:
> From ebb85a61456bf25f87aeb8a31c92c74540bdf306 Mon Sep 17 00:00:00 2001
> From: Scott Yuan
> Date: Sun, 24 Aug 2014 13:46:56 +0800
> Subject: [PATCH] 8250: serial device file is out of order
>
> On x86 architecture, the configuration of serial device maybe get from ACPI
> DSDT, but the order of DSDT is not mandatory, result as array serial8250_ports
> is out of order. This situation is more obvious in multiple serial port
> mainboard. Sort it by unique id that in DSDT will fix it.
Why does this matter?
>
> Signed-off-by: Scott Yuan
> ---
> drivers/pnp/pnpacpi/core.c | 1 +
> drivers/tty/serial/8250/8250_core.c | 40
> -
> drivers/tty/serial/8250/8250_pnp.c | 12 +++
> include/linux/pnp.h | 1 +
> include/linux/serial_8250.h | 2 ++
> 5 files changed, 55 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pnp/pnpacpi/core.c b/drivers/pnp/pnpacpi/core.c
> index a5c6cb7..84b518e 100644
> --- a/drivers/pnp/pnpacpi/core.c
> +++ b/drivers/pnp/pnpacpi/core.c
> @@ -254,6 +254,7 @@ static int __init pnpacpi_add_device(struct acpi_device
> *device)
> return -ENOMEM;
> dev->data = device;
> +dev->is_acpi = 1;
> /* .enabled means the device can decode the resources */
> dev->active = device->status.enabled;
> if (acpi_has_method(device->handle, "_SRS"))
> diff --git a/drivers/tty/serial/8250/8250_core.c
> b/drivers/tty/serial/8250/8250_core.c
> index 7a91c6d..0e5ece5 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@ -3221,6 +3221,41 @@ static struct uart_8250_port
> *serial8250_find_match_or_unused(struct uart_port *
> return NULL;
> }
> +static struct uart_8250_port *
> +serial8250_find_match_sorted_port(struct uart_port *port)
> +{
> +int i, j;
> +struct uart_8250_port *uart;
> +
> +uart = container_of(port, struct uart_8250_port, port);
> +
> +/*
> + * We need sorted array serial8250_ports, it is sort by ACPI
> + * device unique id, so find an apropriate position to insert.
> + */
> +for (i = 0; i < nr_uarts; i++) {
> +if (serial8250_ports[i].uid == 0 ||
> +uart->uid < serial8250_ports[i].uid)
> +break;
> +}
> +
> +/*
> + * If current uid that in serial8250_ports is big than port uid,
> + * then move 8250 port data.
> + */
The port index cannot be changed after the port is registered with the
tty core. That's because the tty core associates the index at registration
time with a specific tty.
Also, this is thread-unsafe: the 8250 driver uses serial_mutex to
protect concurrent add/remove to the serial8250_ports but otherwise
does not claim that mutex to dereference that table once a given port
index has been assigned.
> +if (i < nr_uarts - 1 &&
> +uart->uid < serial8250_ports[i].uid) {
> +memmove(_ports[i+1], _ports[i],
> +(nr_uarts - i - 1) * sizeof(struct uart_8250_port));
> +
> +/* modify port.line, since data moved */
> +for (j = i + 1; j < nr_uarts; j++)
> +serial8250_ports[j].port.line += 1;
> +}
> +serial8250_ports[i].uid = uart->uid;
> +return _ports[i];
> +}
> +
> /**
> *serial8250_register_8250_port - register a serial port
> *@up: serial port template
> @@ -3244,7 +3279,10 @@ int serial8250_register_8250_port(struct
> uart_8250_port *up)
> mutex_lock(_mutex);
> -uart = serial8250_find_match_or_unused(>port);
> +if (up->is_acpi)
> +uart = serial8250_find_match_sorted_port(>port);
> +else
> +uart = serial8250_find_match_or_unused(>port);
> if (uart && uart->port.type != PORT_8250_CIR) {
> if (uart->port.dev)
> uart_remove_one_port(_reg, >port);
> diff --git a/drivers/tty/serial/8250/8250_pnp.c
> b/drivers/tty/serial/8250/8250_pnp.c
> index 682a2fb..c880ed3 100644
> --- a/drivers/tty/serial/8250/8250_pnp.c
> +++ b/drivers/tty/serial/8250/8250_pnp.c
> @@ -15,6 +15,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -427,6 +429,8 @@ static int
> serial_pnp_probe(struct pnp_dev *dev, const struct pnp_device_id *dev_id)
> {
> struct uart_8250_port uart;
> +struct acpi_device *acpi_dev;
> +char *serial_uid;
> int ret, line, flags = dev_id->driver_data;
> if (flags & UNKNOWN_DEV) {
> @@ -451,6 +455,14 @@ serial_pnp_probe(struct pnp_dev *dev, const struct
> pnp_device_id *dev_id)
> } else
> return -ENODEV;
> +if (dev->is_acpi) {
> +acpi_dev = dev->data;
> +serial_uid = acpi_dev->pnp.unique_id;
> +uart.is_acpi = 1;
> +if (kstrtoint(serial_uid, 10, ))
> +return -EINVAL;
> +}
> +
> #ifdef SERIAL_DEBUG_PNP
> printk(KERN_DEBUG
> "Setup PNP port: port %x, mem 0x%lx, irq %d, type
[PATCH v2 0/2] irqfd support for ARM
This patch serie enables irqfd on ARM. irqfd framework enables to inject a virtual IRQ into a guest upon an eventfd trigger. User-side uses KVM_IRQFD VM ioctl to provide KVM with a kvm_irqfd struct that associates a VM, an eventfd, an IRQ number (aka. the gsi). When an actor signals the eventfd (typically a VFIO platform driver), the kvm irqfd subsystem injects the provided virtual IRQ into the guest. Resamplefd also is supported for level sensitive interrupts, ie. the user can provide another eventfd that is triggered when the completion of the virtual IRQ (gsi) is detected by the GIC. The gsi must correspond to a shared peripheral interrupt (SPI), ie the GIC interrupt ID is gsi + 32. It is still under discussion whether PPI injection support is needed. this patch enables CONFIG_HAVE_KVM_EVENTFD and CONFIG_HAVE_KVM_IRQFD. No IRQ routing table is used. 2 patch files are included: - the 1st one simply removes the inclusion of irq.h. After Paul Mackerras' eventfd rework, I think it is no more needed - the second patch brings the irqfd integration for ARM, without routing This patch serie deprecates integration with GSI routing (https://patches.linaro.org/32261/) can be found at git://git.linaro.org/people/eric.auger/linux.git on branch irqfd_integ_v5 This work was tested with Calxeda Midway xgmac main interrupt with qemu-system-arm and QEMU VFIO platform device. - rebase on 3.17rc1 - move of the dist unlock in process_maintenance - remove of dist lock in __kvm_vgic_sync_hwstate - remove irq.h Eric Auger (2): KVM: EVENTFD: remove inclusion of irq.h KVM: ARM: add irqfd support Documentation/virtual/kvm/api.txt | 5 +++- arch/arm/include/uapi/asm/kvm.h | 3 +++ arch/arm/kvm/Kconfig | 3 ++- arch/arm/kvm/Makefile | 2 +- virt/kvm/arm/vgic.c | 56 --- virt/kvm/eventfd.c| 1 - 6 files changed, 62 insertions(+), 8 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] KVM: ARM: add irqfd support
This patch enables irqfd on ARM.
irqfd framework enables to inject a virtual IRQ into a guest upon an
eventfd trigger. User-side uses KVM_IRQFD VM ioctl to provide KVM with
a kvm_irqfd struct that associates a VM, an eventfd, an IRQ number
(aka. the gsi). When an actor signals the eventfd (typically a VFIO
platform driver), the kvm irqfd subsystem injects the provided virtual
IRQ into the guest.
Resamplefd also is supported for level sensitive interrupts, ie. the
user can provide another eventfd that is triggered when the completion
of the virtual IRQ (gsi) is detected by the GIC.
The gsi must correspond to a shared peripheral interrupt (SPI), ie the
GIC interrupt ID is gsi+32.
this patch enables CONFIG_HAVE_KVM_EVENTFD and CONFIG_HAVE_KVM_IRQFD.
No IRQ routing table is used.
Signed-off-by: Eric Auger
---
This patch deprecates the previous patch featuring GSI routing
(https://patches.linaro.org/32261/)
irqchip.c and irq_comm.c are not used at all.
This RFC applies on top of Christoffer Dall's serie
arm/arm64: KVM: Various VGIC cleanups and improvements
https://lists.cs.columbia.edu/pipermail/kvmarm/2014-June/009979.html
All pieces can be found on git://git.linaro.org/people/eric.auger/linux.git
branch irqfd_integ_v5
This work was tested with Calxeda Midway xgmac main interrupt with
qemu-system-arm and QEMU VFIO platform device.
v1 -> v2:
- rebase on 3.17rc1
- move of the dist unlock in process_maintenance
- remove of dist lock in __kvm_vgic_sync_hwstate
- rewording of the commit message (add resamplefd reference)
- remove irq.h
---
Documentation/virtual/kvm/api.txt | 5 +++-
arch/arm/include/uapi/asm/kvm.h | 3 +++
arch/arm/kvm/Kconfig | 3 ++-
arch/arm/kvm/Makefile | 2 +-
virt/kvm/arm/vgic.c | 56 ---
5 files changed, 62 insertions(+), 7 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index beae3fd..8118b12 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2204,7 +2204,7 @@ into the hash PTE second double word).
4.75 KVM_IRQFD
Capability: KVM_CAP_IRQFD
-Architectures: x86 s390
+Architectures: x86 s390 arm
Type: vm ioctl
Parameters: struct kvm_irqfd (in)
Returns: 0 on success, -1 on error
@@ -2230,6 +2230,9 @@ Note that closing the resamplefd is not sufficient to
disable the
irqfd. The KVM_IRQFD_FLAG_RESAMPLE is only necessary on assignment
and need not be specified with KVM_IRQFD_FLAG_DEASSIGN.
+On ARM/arm64 the injected must be a shared peripheral interrupt (SPI).
+This means the programmed GIC interrupt ID is gsi+32.
+
4.76 KVM_PPC_ALLOCATE_HTAB
Capability: KVM_CAP_PPC_ALLOC_HTAB
diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
index e6ebdd3..3034c66 100644
--- a/arch/arm/include/uapi/asm/kvm.h
+++ b/arch/arm/include/uapi/asm/kvm.h
@@ -194,6 +194,9 @@ struct kvm_arch_memory_slot {
/* Highest supported SPI, from VGIC_NR_IRQS */
#define KVM_ARM_IRQ_GIC_MAX127
+/* One single KVM irqchip, ie. the VGIC */
+#define KVM_NR_IRQCHIPS 1
+
/* PSCI interface */
#define KVM_PSCI_FN_BASE 0x95c1ba5e
#define KVM_PSCI_FN(n) (KVM_PSCI_FN_BASE + (n))
diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig
index 466bd29..82ccd81 100644
--- a/arch/arm/kvm/Kconfig
+++ b/arch/arm/kvm/Kconfig
@@ -24,6 +24,7 @@ config KVM
select KVM_MMIO
select KVM_ARM_HOST
depends on ARM_VIRT_EXT && ARM_LPAE
+ select HAVE_KVM_EVENTFD
---help---
Support hosting virtualized guest machines. You will also
need to select one or more of the processor modules below.
@@ -55,7 +56,7 @@ config KVM_ARM_MAX_VCPUS
config KVM_ARM_VGIC
bool "KVM support for Virtual GIC"
depends on KVM_ARM_HOST && OF
- select HAVE_KVM_IRQCHIP
+ select HAVE_KVM_IRQFD
default y
---help---
Adds support for a hardware assisted, in-kernel GIC emulation.
diff --git a/arch/arm/kvm/Makefile b/arch/arm/kvm/Makefile
index f7057ed..859db09 100644
--- a/arch/arm/kvm/Makefile
+++ b/arch/arm/kvm/Makefile
@@ -15,7 +15,7 @@ AFLAGS_init.o := -Wa,-march=armv7-a$(plus_virt)
AFLAGS_interrupts.o := -Wa,-march=armv7-a$(plus_virt)
KVM := ../../../virt/kvm
-kvm-arm-y = $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o
+kvm-arm-y = $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o
obj-y += kvm-arm.o init.o interrupts.o
obj-y += arm.o handle_exit.o guest.o mmu.o emulate.o reset.o
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 7164d2e..586bd11 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -1334,7 +1334,10 @@ epilog:
static bool vgic_process_maintenance(struct kvm_vcpu *vcpu)
{
u32 status = vgic_get_interrupt_status(vcpu);
+ struct vgic_dist *dist = >kvm->arch.vgic;
bool level_pending = false;
+ struct kvm *kvm = vcpu->kvm;
+ int
[PATCH v2 1/2] KVM: EVENTFD: remove inclusion of irq.h
No more needed. Also irq.h is not used on ARM. Signed-off-by: Eric Auger --- virt/kvm/eventfd.c | 1 - 1 file changed, 1 deletion(-) diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c index 3c5981c..0c712a7 100644 --- a/virt/kvm/eventfd.c +++ b/virt/kvm/eventfd.c @@ -36,7 +36,6 @@ #include #include -#include "irq.h" #include "iodev.h" #ifdef CONFIG_HAVE_KVM_IRQFD -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH RFC 2/3] x86: Enable PAT to use cache mode translation tables
On 08/22/2014 11:32 AM, Jan Beulich wrote:
On 19.08.14 at 15:25, wrote:
@@ -118,8 +167,14 @@ void pat_init(void)
PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC);
/* Boot CPU check */
- if (!boot_pat_state)
+ if (!boot_pat_state) {
rdmsrl(MSR_IA32_CR_PAT, boot_pat_state);
+ /*
+* Init cache mode tables before writing MSR to give Xen a
+* chance to correct the changes when doing the write.
+*/
This comment seems pretty odd to me: For one, a PV guest on Xen
shouldn't be trying to write PAT MSR at all under the current ABI
(the write will be ignored, yes, but accompanied with a warning
message, which PV kernels - by the mere fact that they're PV -
should try to avoid). And then "correct the changes" both gives
the impression as if they were wrong and as if some of what the
kernel writes may be under the kernel's control. Hence I think this
code and comment should either be consistently assuming that the
kernel has no control at all, or should read back the value after
having written it, and set the internal tables based on the value
read back.
I think the latter alternative is the better one. I'll change the
patch.
Juergen
--
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 v3 1/4] hwmon: (lm90) split set temp as common codes
FWIW, please fix the authorship information for next version.
Cheers,
Mikko
On 25/08/14 09:29, Wei Ni wrote:
From: lightning314
Split set temp codes as common functions, so we can use it
directly when implement linux thermal framework.
And handle error return value for the lm90_select_remote_channel
and write_tempx, then set_temp8 and set_temp11 could return it
to user-space.
Signed-off-by: Wei Ni
Signed-off-by: Jean Delvare
---
drivers/hwmon/lm90.c | 164 ++-
1 file changed, 109 insertions(+), 55 deletions(-)
diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
index c9ff08d..cb33dcf 100644
--- a/drivers/hwmon/lm90.c
+++ b/drivers/hwmon/lm90.c
@@ -473,20 +473,23 @@ static int lm90_read16(struct i2c_client *client, u8
regh, u8 regl, u16 *value)
* various registers have different meanings as a result of selecting a
* non-default remote channel.
*/
-static inline void lm90_select_remote_channel(struct i2c_client *client,
- struct lm90_data *data,
- int channel)
+static inline int lm90_select_remote_channel(struct i2c_client *client,
+struct lm90_data *data,
+int channel)
{
u8 config;
+ int err = 0;
if (data->kind == max6696) {
lm90_read_reg(client, LM90_REG_R_CONFIG1, );
config &= ~0x08;
if (channel)
config |= 0x08;
- i2c_smbus_write_byte_data(client, LM90_REG_W_CONFIG1,
- config);
+ err = i2c_smbus_write_byte_data(client, LM90_REG_W_CONFIG1,
+ config);
}
+
+ return err;
}
/*
@@ -759,29 +762,34 @@ static u16 temp_to_u16_adt7461(struct lm90_data *data,
long val)
* Sysfs stuff
*/
-static ssize_t show_temp8(struct device *dev, struct device_attribute *devattr,
- char *buf)
+static int read_temp8(struct device *dev, int index)
{
- struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
struct lm90_data *data = lm90_update_device(dev);
int temp;
if (data->kind == adt7461 || data->kind == tmp451)
- temp = temp_from_u8_adt7461(data, data->temp8[attr->index]);
+ temp = temp_from_u8_adt7461(data, data->temp8[index]);
else if (data->kind == max6646)
- temp = temp_from_u8(data->temp8[attr->index]);
+ temp = temp_from_u8(data->temp8[index]);
else
- temp = temp_from_s8(data->temp8[attr->index]);
+ temp = temp_from_s8(data->temp8[index]);
/* +16 degrees offset for temp2 for the LM99 */
- if (data->kind == lm99 && attr->index == 3)
+ if (data->kind == lm99 && index == 3)
temp += 16000;
- return sprintf(buf, "%d\n", temp);
+ return temp;
}
-static ssize_t set_temp8(struct device *dev, struct device_attribute *devattr,
-const char *buf, size_t count)
+static ssize_t show_temp8(struct device *dev, struct device_attribute *devattr,
+ char *buf)
+{
+ struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+
+ return sprintf(buf, "%d\n", read_temp8(dev, attr->index));
+}
+
+static int write_temp8(struct device *dev, int index, long val)
{
static const u8 reg[TEMP8_REG_NUM] = {
LM90_REG_W_LOCAL_LOW,
@@ -794,60 +802,79 @@ static ssize_t set_temp8(struct device *dev, struct
device_attribute *devattr,
MAX6659_REG_W_REMOTE_EMERG,
};
- struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
struct lm90_data *data = dev_get_drvdata(dev);
struct i2c_client *client = data->client;
- int nr = attr->index;
- long val;
int err;
- err = kstrtol(buf, 10, );
- if (err < 0)
- return err;
-
/* +16 degrees offset for temp2 for the LM99 */
- if (data->kind == lm99 && attr->index == 3)
+ if (data->kind == lm99 && index == 3)
val -= 16000;
mutex_lock(>update_lock);
if (data->kind == adt7461 || data->kind == tmp451)
- data->temp8[nr] = temp_to_u8_adt7461(data, val);
+ data->temp8[index] = temp_to_u8_adt7461(data, val);
else if (data->kind == max6646)
- data->temp8[nr] = temp_to_u8(val);
+ data->temp8[index] = temp_to_u8(val);
else
- data->temp8[nr] = temp_to_s8(val);
-
- lm90_select_remote_channel(client, data, nr >= 6);
- i2c_smbus_write_byte_data(client, reg[nr], data->temp8[nr]);
- lm90_select_remote_channel(client, data, 0);
+ data->temp8[index] = temp_to_s8(val);
+ if
Re: [PATCH] net: stmmac: add dcrs parameter
Hello
On 8/25/2014 1:50 PM, Ley Foon Tan wrote:
This patch add the option to enable DCRS bit in GMAC control register.
Default is disabled if snps,dcrs is not defined.
For MII, Carrier Sense (CRS) must be asserted during transmission
whereas in RGMII, CRS is not. RGMII does not provide a way to signal
loss of carrier during a transmission.
When DCRS bit set high in control register, the MAC transmitter
ignore the (G)MII Carrier Sense signal during frame transmission
in the half-duplex mode. This request results in no errors generated
because of Loss of Carrier or No Carrier during such transmission.
We have to add this fix in the driver. I wonder if we can avoid to have
another parameter and just have it set as default
(http://git.stlinux.com/?p=stm/linux-sh4-2.6.32.y.git;a=commit;h=b0b863bf65c36dc593f6b7b4b418394fd880dae2)
Or we could touch this bit according to the link duplex negotiated and
the phy mode selected.
peppe
Signed-off-by: Ley Foon Tan
---
Documentation/devicetree/bindings/net/stmmac.txt | 4
drivers/net/ethernet/stmicro/stmmac/common.h | 3 ++-
drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 4 +++-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 ++-
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 ++
include/linux/stmmac.h| 1 +
6 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt
b/Documentation/devicetree/bindings/net/stmmac.txt
index 9b03c57..a68e720 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -39,6 +39,10 @@ Optional properties:
further clocks may be specified in derived bindings.
- clock-names: One name for each entry in the clocks property, the
first one should be "stmmaceth".
+- snps,dcrs: Enable DCRS bit in GMAC control register. This DCRS bit makes the
+ MAC transmitter ignore the (G)MII CRS signal during frame transmission
+ in the half-duplex mode. This request results in no errors generated
+ because of Loss of Carrier or No Carrier during such transmission.
Examples:
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index de507c3..9abe221 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -445,10 +445,11 @@ struct mac_device_info {
int multicast_filter_bins;
int unicast_filter_entries;
int mcast_bits_log2;
+ int dcrs;
};
struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr, int mcbins,
- int perfect_uc_entries);
+ int perfect_uc_entries, int dcrs);
struct mac_device_info *dwmac100_setup(void __iomem *ioaddr);
void stmmac_set_mac_addr(void __iomem *ioaddr, u8 addr[6],
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index d8ef187..924d450 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -37,6 +37,7 @@ static void dwmac1000_core_init(struct mac_device_info *hw,
int mtu)
void __iomem *ioaddr = hw->pcsr;
u32 value = readl(ioaddr + GMAC_CONTROL);
value |= GMAC_CORE_INIT;
+ value |= hw->dcrs;
if (mtu > 1500)
value |= GMAC_CONTROL_2K;
if (mtu > 2000)
@@ -409,7 +410,7 @@ static const struct stmmac_ops dwmac1000_ops = {
};
struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr, int mcbins,
- int perfect_uc_entries)
+ int perfect_uc_entries, int dcrs)
{
struct mac_device_info *mac;
u32 hwid = readl(ioaddr + GMAC_VERSION);
@@ -422,6 +423,7 @@ struct mac_device_info *dwmac1000_setup(void __iomem
*ioaddr, int mcbins,
mac->multicast_filter_bins = mcbins;
mac->unicast_filter_entries = perfect_uc_entries;
mac->mcast_bits_log2 = 0;
+ mac->dcrs = dcrs;
if (mac->multicast_filter_bins)
mac->mcast_bits_log2 = ilog2(mac->multicast_filter_bins);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 08addd6..bf35b19 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2600,7 +2600,8 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
priv->dev->priv_flags |= IFF_UNICAST_FLT;
mac = dwmac1000_setup(priv->ioaddr,
priv->plat->multicast_filter_bins,
- priv->plat->unicast_filter_entries);
+ priv->plat->unicast_filter_entries,
+
[PATCH 1/2] usb: chipidea: msm: Use USB PHY API to control PHY state
PHY drivers keep track of the current state of the hardware,
so don't change PHY settings under it.
Signed-off-by: Ivan T. Ivanov
Acked-by: Felipe Balbi
---
drivers/usb/chipidea/ci_hdrc_msm.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
b/drivers/usb/chipidea/ci_hdrc_msm.c
index d72b9d2..30bdd51 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -20,7 +20,6 @@
static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
{
struct device *dev = ci->gadget.dev.parent;
- int val;
switch (event) {
case CI_HDRC_CONTROLLER_RESET_EVENT:
@@ -34,10 +33,7 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci,
unsigned event)
* Put the transceiver in non-driving mode. Otherwise host
* may not detect soft-disconnection.
*/
- val = usb_phy_io_read(ci->transceiver, ULPI_FUNC_CTRL);
- val &= ~ULPI_FUNC_CTRL_OPMODE_MASK;
- val |= ULPI_FUNC_CTRL_OPMODE_NONDRIVING;
- usb_phy_io_write(ci->transceiver, val, ULPI_FUNC_CTRL);
+ usb_phy_notify_disconnect(ci->transceiver, USB_SPEED_UNKNOWN);
break;
default:
dev_dbg(dev, "unknown ci_hdrc event\n");
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/12] mmc: tmio: Fixup PM support
This patchset fixup the PM support for tmio and the tmio hosts. Some re-structuring of the code was also necessary to accomplish the above. A few of these patches has been posted earlier, but at that time I couldn't get help in testing them on hardware. Let's give this a second try now. http://www.spinics.net/lists/linux-mmc/msg23177.html Ulf Hansson (12): mmc: tmio: Keep host active while SDIO IRQ is enabled mmc: tmio: Keep host active while serving requests mmc: tmio: Extract bus_width modifications to a separate function mmc: tmio: Restructure ->set_ios() and adapt ->probe() to it mmc: tmio: Handle clock gating from runtime PM functions mmc: tmio: Mask all IRQs when inactive mmc: tmio: Make runtime PM callbacks available for CONFIG_PM mmc: sdhi: Make runtime PM callbacks available for CONFIG_PM mmc: tmio_mmc: Enable runtime PM support mmc: sdhi: Fixup system PM suspend lock-up mmc: tmio_mmc: Fixup system PM suspend lock-up mmc: tmio: Remove library functions for system PM drivers/mmc/host/sh_mobile_sdhi.c | 5 +- drivers/mmc/host/tmio_mmc.c | 7 +- drivers/mmc/host/tmio_mmc.h | 31 +- drivers/mmc/host/tmio_mmc_pio.c | 193 ++ 4 files changed, 104 insertions(+), 132 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/12] mmc: tmio_mmc: Enable runtime PM support
To take advantage of the clock gating support, use the runtime PM
callbacks provided by the tmio core.
Additionally, we make use of the SET_PM_RUNTIME_PM_OPS, which is a
preparation needed to simplify system PM.
Signed-off-by: Ulf Hansson
---
drivers/mmc/host/tmio_mmc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index cfad844..58f50ef 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -135,6 +135,9 @@ static int tmio_mmc_remove(struct platform_device *pdev)
static const struct dev_pm_ops tmio_mmc_dev_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(tmio_mmc_suspend, tmio_mmc_resume)
+ SET_PM_RUNTIME_PM_OPS(tmio_mmc_host_runtime_suspend,
+ tmio_mmc_host_runtime_resume,
+ NULL)
};
static struct platform_driver tmio_mmc_driver = {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/12] mmc: tmio: Mask all IRQs when inactive
To make sure we don't receive any spurious IRQs while we are inactive, mask the IRQs from within the ->runtime_suspend() callback. Signed-off-by: Ulf Hansson --- drivers/mmc/host/tmio_mmc_pio.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c index 2345177..d52280d 100644 --- a/drivers/mmc/host/tmio_mmc_pio.c +++ b/drivers/mmc/host/tmio_mmc_pio.c @@ -1168,6 +1168,8 @@ int tmio_mmc_host_runtime_suspend(struct device *dev) struct mmc_host *mmc = dev_get_drvdata(dev); struct tmio_mmc_host *host = mmc_priv(mmc); + tmio_mmc_disable_mmc_irqs(host, TMIO_MASK_ALL); + if (host->clk_cache) tmio_mmc_clk_stop(host); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/12] mmc: tmio: Keep host active while SDIO IRQ is enabled
The host must be kept active to be able to serve SDIO IRQs, thus let's
prevent it from going inactive while SDIO IRQ is enabled.
Signed-off-by: Ulf Hansson
---
drivers/mmc/host/tmio_mmc.h | 1 +
drivers/mmc/host/tmio_mmc_pio.c | 19 +++
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index 100ffe0..d6ceb1a 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -101,6 +101,7 @@ struct tmio_mmc_host {
struct mutexios_lock; /* protect set_ios() context */
boolnative_hotplug;
boolresuming;
+ boolsdio_irq_enabled;
};
int tmio_mmc_host_probe(struct tmio_mmc_host **host,
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index faf0924..5c2e5a3 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -129,15 +129,22 @@ static void tmio_mmc_enable_sdio_irq(struct mmc_host
*mmc, int enable)
{
struct tmio_mmc_host *host = mmc_priv(mmc);
- if (enable) {
+ if (enable && !host->sdio_irq_enabled) {
+ /* Keep device active while SDIO irq is enabled */
+ pm_runtime_get_sync(mmc_dev(mmc));
+ host->sdio_irq_enabled = true;
+
host->sdio_irq_mask = TMIO_SDIO_MASK_ALL &
~TMIO_SDIO_STAT_IOIRQ;
sd_ctrl_write16(host, CTL_TRANSACTION_CTL, 0x0001);
sd_ctrl_write16(host, CTL_SDIO_IRQ_MASK, host->sdio_irq_mask);
- } else {
+ } else if (!enable && host->sdio_irq_enabled) {
host->sdio_irq_mask = TMIO_SDIO_MASK_ALL;
sd_ctrl_write16(host, CTL_SDIO_IRQ_MASK, host->sdio_irq_mask);
sd_ctrl_write16(host, CTL_TRANSACTION_CTL, 0x);
+
+ host->sdio_irq_enabled = false;
+ pm_runtime_put(mmc_dev(mmc));
}
}
@@ -1074,8 +1081,12 @@ int tmio_mmc_host_probe(struct tmio_mmc_host **host,
_host->sdcard_irq_mask &= ~irq_mask;
- if (pdata->flags & TMIO_MMC_SDIO_IRQ)
- tmio_mmc_enable_sdio_irq(mmc, 0);
+ _host->sdio_irq_enabled = false;
+ if (pdata->flags & TMIO_MMC_SDIO_IRQ) {
+ _host->sdio_irq_mask = TMIO_SDIO_MASK_ALL;
+ sd_ctrl_write16(_host, CTL_SDIO_IRQ_MASK, _host->sdio_irq_mask);
+ sd_ctrl_write16(_host, CTL_TRANSACTION_CTL, 0x);
+ }
spin_lock_init(&_host->lock);
mutex_init(&_host->ios_lock);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/12] mmc: tmio: Remove library functions for system PM
These library functions aren't used and nor needed, let's remove them.
Signed-off-by: Ulf Hansson
---
drivers/mmc/host/tmio_mmc.h | 5 -
drivers/mmc/host/tmio_mmc_pio.c | 23 ---
2 files changed, 28 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index 2ad52d6..a34ecbe 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -144,11 +144,6 @@ static inline void tmio_mmc_abort_dma(struct tmio_mmc_host
*host)
}
#endif
-#ifdef CONFIG_PM_SLEEP
-int tmio_mmc_host_suspend(struct device *dev);
-int tmio_mmc_host_resume(struct device *dev);
-#endif
-
#ifdef CONFIG_PM
int tmio_mmc_host_runtime_suspend(struct device *dev);
int tmio_mmc_host_runtime_resume(struct device *dev);
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index 494ecc5..a993208 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -1139,29 +1139,6 @@ void tmio_mmc_host_remove(struct tmio_mmc_host *host)
}
EXPORT_SYMBOL(tmio_mmc_host_remove);
-#ifdef CONFIG_PM_SLEEP
-int tmio_mmc_host_suspend(struct device *dev)
-{
- struct mmc_host *mmc = dev_get_drvdata(dev);
- struct tmio_mmc_host *host = mmc_priv(mmc);
-
- tmio_mmc_disable_mmc_irqs(host, TMIO_MASK_ALL);
- return 0;
-}
-EXPORT_SYMBOL(tmio_mmc_host_suspend);
-
-int tmio_mmc_host_resume(struct device *dev)
-{
- struct mmc_host *mmc = dev_get_drvdata(dev);
- struct tmio_mmc_host *host = mmc_priv(mmc);
-
- tmio_mmc_enable_dma(host, true);
-
- return 0;
-}
-EXPORT_SYMBOL(tmio_mmc_host_resume);
-#endif
-
#ifdef CONFIG_PM
int tmio_mmc_host_runtime_suspend(struct device *dev)
{
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/8] asm-generic/io.h overhaul
On Mon, Aug 25, 2014 at 01:53:30PM +0200, Richard Weinberger wrote:
> On Wed, Aug 13, 2014 at 12:28 PM, Thierry Reding
> wrote:
> > From: Thierry Reding
> >
> > Hi,
> >
> > Here is the fourth version of a series that started out as an attempt to
> > provide string versions of the read*() and write*() accessors to more
> > architectures so that drivers can use them portably. The series has
> > since evolved into a more general cleanup of asm-generic/io.h and the
> > functions defined therein.
> >
> > Patch 1 is trivial and removes a redundant redefinition of PCI_IOBASE
> > from the asm/io.h header on ARC. Patches 2 and 3 remove unnecessary
> > volatile keywoards from some functions, which is a prerequisite to clean
> > up some of the functions in subsequent patches.
> >
> > The xlate_dev_{kmem,mem}_ptr() functions are used to map memory when the
> > /dev/mem device is accessed. Patches 4 and 5 use more consistent data
> > types for these functions, which will get a "standard" prototype in the
> > asm-generic/io.h header in a subsequent patch.
> >
> > Patch 6 is the bulk of this series. It implements the string variants of
> > the read*() and write*() accessors and cleans up various other parts of
> > the asm-generic/io.h header file. Macros are converted to static inline
> > functions for better type checking. Overriding generic implementations
> > in architectures is handled more consistently.
> >
> > Patches 7 and 8, finally, make use of the asm-generic/io.h header on the
> > 32-bit and 64-bit ARM architectures.
> >
> > This is compile- and runtime-tested on 32-bit and 64-bit ARM and compile
> > tested on IA64, Microblaze, s390, SPARC, x86 and Xtensa. For ARC,
> > Blackfin, Metag, OpenRISC, Score and Unicore32 which also use
> > asm-generic/io.h I couldn't find or build a cross-compiler that would
> > run on my system. But by code inspection they shouldn't break with this
> > patch.
> >
> > To ensure bisectability I built multi_v7_defconfig on 32-bit ARM and the
> > defconfig for 64-bit ARM, IA64, Microblaze, s390, SPARC, x86 and Xtensa
> > after each commit and verified that the series does not introduce any
> > build errors or warnings.
> >
> > Provided there are no objections to the patches there's still the matter
> > of how to merge them. Patch 6 depends on patches 1-5 to avoid warnings
> > and/or errors during the build. Patches 7 and 8 depend on patch 6. In my
> > opinion it doesn't make much sense to split them up, so I guess we'll
> > need a volunteer to take them all into one tree. Ideally that tree would
> > feed into linux-next so that we can get as much build and test-coverage
> > as possible during the 3.17 release cycle so that these patches can go
> > into 3.18.
> >
> > Arnd, I'm opportunistically sending this To: you in the hopes that you
> > can take it into your asm-generic tree which seems like the best fit for
> > this.
>
> Do you have a git tree for that?
> Would be nice for testing UML, it depends also on generic io.
Yes, it's all here:
https://github.com/thierryreding/linux.git staging/asm-generic-io
That branch is based on today's linux-next (next-20140825).
Thierry
pgpg4G_8dv7JF.pgp
Description: PGP signature
[PATCH 02/12] mmc: tmio: Keep host active while serving requests
Use runtime PM to keep the host active during I/O operations and other
requests which requires the tmio hardware to be powered.
Additionally make use of the runtime PM autosuspend feature with a
default timeout of 50 ms.
Signed-off-by: Ulf Hansson
---
drivers/mmc/host/tmio_mmc_pio.c | 55 -
1 file changed, 32 insertions(+), 23 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index 5c2e5a3..d63d292 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -144,7 +144,8 @@ static void tmio_mmc_enable_sdio_irq(struct mmc_host *mmc,
int enable)
sd_ctrl_write16(host, CTL_TRANSACTION_CTL, 0x);
host->sdio_irq_enabled = false;
- pm_runtime_put(mmc_dev(mmc));
+ pm_runtime_mark_last_busy(mmc_dev(mmc));
+ pm_runtime_put_autosuspend(mmc_dev(mmc));
}
}
@@ -252,6 +253,9 @@ static void tmio_mmc_reset_work(struct work_struct *work)
tmio_mmc_abort_dma(host);
mmc_request_done(host->mmc, mrq);
+
+ pm_runtime_mark_last_busy(mmc_dev(host->mmc));
+ pm_runtime_put_autosuspend(mmc_dev(host->mmc));
}
/* called with host->lock held, interrupts disabled */
@@ -281,6 +285,9 @@ static void tmio_mmc_finish_request(struct tmio_mmc_host
*host)
tmio_mmc_abort_dma(host);
mmc_request_done(host->mmc, mrq);
+
+ pm_runtime_mark_last_busy(mmc_dev(host->mmc));
+ pm_runtime_put_autosuspend(mmc_dev(host->mmc));
}
static void tmio_mmc_done_work(struct work_struct *work)
@@ -735,6 +742,8 @@ static void tmio_mmc_request(struct mmc_host *mmc, struct
mmc_request *mrq)
spin_unlock_irqrestore(>lock, flags);
+ pm_runtime_get_sync(mmc_dev(mmc));
+
if (mrq->data) {
ret = tmio_mmc_start_data(host, mrq->data);
if (ret)
@@ -753,6 +762,9 @@ fail:
host->mrq = NULL;
mrq->cmd->error = ret;
mmc_request_done(mmc, mrq);
+
+ pm_runtime_mark_last_busy(mmc_dev(mmc));
+ pm_runtime_put_autosuspend(mmc_dev(mmc));
}
static int tmio_mmc_clk_update(struct mmc_host *mmc)
@@ -831,6 +843,8 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
struct device *dev = >pdev->dev;
unsigned long flags;
+ pm_runtime_get_sync(mmc_dev(mmc));
+
mutex_lock(>ios_lock);
spin_lock_irqsave(>lock, flags);
@@ -866,7 +880,6 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
if (ios->power_mode == MMC_POWER_ON && ios->clock) {
if (host->power != TMIO_MMC_ON_RUN) {
tmio_mmc_clk_update(mmc);
- pm_runtime_get_sync(dev);
if (host->resuming) {
tmio_mmc_reset(host);
host->resuming = false;
@@ -896,7 +909,6 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
if (old_power == TMIO_MMC_ON_RUN) {
tmio_mmc_clk_stop(host);
- pm_runtime_put(dev);
if (pdata->clk_disable)
pdata->clk_disable(host->pdev);
}
@@ -923,6 +935,9 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
host->mrq = NULL;
mutex_unlock(>ios_lock);
+
+ pm_runtime_mark_last_busy(mmc_dev(mmc));
+ pm_runtime_put_autosuspend(mmc_dev(mmc));
}
static int tmio_mmc_get_ro(struct mmc_host *mmc)
@@ -933,8 +948,13 @@ static int tmio_mmc_get_ro(struct mmc_host *mmc)
if (ret >= 0)
return ret;
- return !((pdata->flags & TMIO_MMC_WRPROTECT_DISABLE) ||
-(sd_ctrl_read32(host, CTL_STATUS) & TMIO_STAT_WRPROTECT));
+ pm_runtime_get_sync(mmc_dev(mmc));
+ ret = !((pdata->flags & TMIO_MMC_WRPROTECT_DISABLE) ||
+ (sd_ctrl_read32(host, CTL_STATUS) & TMIO_STAT_WRPROTECT));
+ pm_runtime_mark_last_busy(mmc_dev(mmc));
+ pm_runtime_put_autosuspend(mmc_dev(mmc));
+
+ return ret;
}
static const struct mmc_host_ops tmio_mmc_ops = {
@@ -1040,27 +1060,14 @@ int tmio_mmc_host_probe(struct tmio_mmc_host **host,
mmc->slot.cd_irq >= 0);
_host->power = TMIO_MMC_OFF_STOP;
- pm_runtime_enable(>dev);
- ret = pm_runtime_resume(>dev);
- if (ret < 0)
- goto pm_disable;
-
if (tmio_mmc_clk_update(mmc) < 0) {
mmc->f_max = pdata->hclk;
mmc->f_min = mmc->f_max / 512;
}
/*
-* There are 4 different scenarios for the card detection:
-* 1) an external gpio irq handles the cd (best for power savings)
-* 2) internal sdhi irq handles the cd
-* 3) a worker thread polls the sdhi - indicated by MMC_CAP_NEEDS_POLL
[PATCH 07/12] mmc: tmio: Make runtime PM callbacks available for CONFIG_PM
To give the option for tmio hosts to use the runtime PM callbacks for
CONFIG_PM_SLEEP as well as CONFIG_PM_RUNTIME, move them to CONFIG_PM.
Signed-off-by: Ulf Hansson
---
drivers/mmc/host/tmio_mmc.h | 2 +-
drivers/mmc/host/tmio_mmc_pio.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index f1ee3e4..2ad52d6 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -149,7 +149,7 @@ int tmio_mmc_host_suspend(struct device *dev);
int tmio_mmc_host_resume(struct device *dev);
#endif
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
int tmio_mmc_host_runtime_suspend(struct device *dev);
int tmio_mmc_host_runtime_resume(struct device *dev);
#endif
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index d52280d..494ecc5 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -1162,7 +1162,7 @@ int tmio_mmc_host_resume(struct device *dev)
EXPORT_SYMBOL(tmio_mmc_host_resume);
#endif
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
int tmio_mmc_host_runtime_suspend(struct device *dev)
{
struct mmc_host *mmc = dev_get_drvdata(dev);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/12] mmc: sdhi: Make runtime PM callbacks available for CONFIG_PM
To be able to simplify system PM, let's re-use the runtime PM callbacks
by converting to the SET_PM_RUNTIME_PM_OPS macro.
Signed-off-by: Ulf Hansson
---
drivers/mmc/host/sh_mobile_sdhi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
b/drivers/mmc/host/sh_mobile_sdhi.c
index be5e25d..4cd0f09 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -333,7 +333,7 @@ static int sh_mobile_sdhi_remove(struct platform_device
*pdev)
static const struct dev_pm_ops tmio_mmc_dev_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(tmio_mmc_host_suspend, tmio_mmc_host_resume)
- SET_RUNTIME_PM_OPS(tmio_mmc_host_runtime_suspend,
+ SET_PM_RUNTIME_PM_OPS(tmio_mmc_host_runtime_suspend,
tmio_mmc_host_runtime_resume,
NULL)
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/12] mmc: tmio: Restructure ->set_ios() and adapt ->probe() to it
An internal power state machine were beeing used to keep ->probe() and
->set_ios() in sync. Especially for handling specific scenarios while
using CONFIG_MMC_CLKGATE. Moreover dependency to CONFIG_MMC_CLKGATE
existed to handle runtime PM properly, which we moves away from here.
By removing the state machine and instead make ->set_ios() rely on the
information provided through the function's in-parameters, the code
becomes significantly simplier.
Additonally as a part of this rework we prepares for making the runtime
PM callbacks responsible of clock gating.
Signed-off-by: Ulf Hansson
---
drivers/mmc/host/tmio_mmc.h | 20 --
drivers/mmc/host/tmio_mmc_pio.c | 61 ++---
2 files changed, 14 insertions(+), 67 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index d6ceb1a..f837723 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -40,22 +40,6 @@
struct tmio_mmc_data;
-/*
- * We differentiate between the following 3 power states:
- * 1. card slot powered off, controller stopped. This is used, when either
there
- *is no card in the slot, or the card really has to be powered down.
- * 2. card slot powered on, controller stopped. This is used, when a card is in
- *the slot, but no activity is currently taking place. This is a power-
- *saving mode with card-state preserved. This state can be entered, e.g.
- *when MMC clock-gating is used.
- * 3. card slot powered on, controller running. This is the actual active
state.
- */
-enum tmio_mmc_power {
- TMIO_MMC_OFF_STOP, /* card power off, controller stopped */
- TMIO_MMC_ON_STOP, /* card power on, controller stopped */
- TMIO_MMC_ON_RUN,/* card power on, controller running */
-};
-
struct tmio_mmc_host {
void __iomem *ctl;
struct mmc_command *cmd;
@@ -63,9 +47,6 @@ struct tmio_mmc_host {
struct mmc_data *data;
struct mmc_host *mmc;
- /* Controller and card power state */
- enum tmio_mmc_power power;
-
/* Callbacks for clock / power control */
void (*set_pwr)(struct platform_device *host, int state);
void (*set_clk_div)(struct platform_device *host, int state);
@@ -100,7 +81,6 @@ struct tmio_mmc_host {
unsigned long last_req_ts;
struct mutexios_lock; /* protect set_ios() context */
boolnative_hotplug;
- boolresuming;
boolsdio_irq_enabled;
};
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index 8f5b5cc..e573a15 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -884,51 +884,23 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
spin_unlock_irqrestore(>lock, flags);
- /*
-* host->power toggles between false and true in both cases - either
-* or not the controller can be runtime-suspended during inactivity.
-* But if the controller has to be kept on, the runtime-pm usage_count
-* is kept positive, so no suspending actually takes place.
-*/
- if (ios->power_mode == MMC_POWER_ON && ios->clock) {
- if (host->power != TMIO_MMC_ON_RUN) {
- tmio_mmc_clk_update(mmc);
- if (host->resuming) {
- tmio_mmc_reset(host);
- host->resuming = false;
- }
- }
- if (host->power == TMIO_MMC_OFF_STOP)
- tmio_mmc_reset(host);
+ switch (ios->power_mode) {
+ case MMC_POWER_OFF:
+ tmio_mmc_power_off(host);
+ tmio_mmc_clk_stop(host);
+ break;
+ case MMC_POWER_UP:
tmio_mmc_set_clock(host, ios->clock);
- if (host->power == TMIO_MMC_OFF_STOP)
- /* power up SD card and the bus */
- tmio_mmc_power_on(host, ios->vdd);
- host->power = TMIO_MMC_ON_RUN;
- /* start bus clock */
+ tmio_mmc_power_on(host, ios->vdd);
tmio_mmc_clk_start(host);
- } else if (ios->power_mode != MMC_POWER_UP) {
- struct tmio_mmc_data *pdata = host->pdata;
- unsigned int old_power = host->power;
-
- if (old_power != TMIO_MMC_OFF_STOP) {
- if (ios->power_mode == MMC_POWER_OFF) {
- tmio_mmc_power_off(host);
- host->power = TMIO_MMC_OFF_STOP;
- } else {
- host->power = TMIO_MMC_ON_STOP;
- }
- }
-
- if (old_power == TMIO_MMC_ON_RUN) {
- tmio_mmc_clk_stop(host);
-
[PATCH 05/12] mmc: tmio: Handle clock gating from runtime PM functions
Add clock gating control as a part of the tmio library functions for
runtime PM.
Signed-off-by: Ulf Hansson
---
drivers/mmc/host/tmio_mmc.h | 3 ++-
drivers/mmc/host/tmio_mmc_pio.c | 28
2 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index f837723..f1ee3e4 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -73,9 +73,10 @@ struct tmio_mmc_host {
struct delayed_work delayed_reset_work;
struct work_struct done;
- /* Cache IRQ mask */
+ /* Cache */
u32 sdcard_irq_mask;
u32 sdio_irq_mask;
+ unsigned intclk_cache;
spinlock_t lock; /* protect host private data */
unsigned long last_req_ts;
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index e573a15..2345177 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -149,7 +149,8 @@ static void tmio_mmc_enable_sdio_irq(struct mmc_host *mmc,
int enable)
}
}
-static void tmio_mmc_set_clock(struct tmio_mmc_host *host, int new_clock)
+static void tmio_mmc_set_clock(struct tmio_mmc_host *host,
+ unsigned int new_clock)
{
u32 clk = 0, clock;
@@ -767,9 +768,9 @@ fail:
pm_runtime_put_autosuspend(mmc_dev(mmc));
}
-static int tmio_mmc_clk_update(struct mmc_host *mmc)
+static int tmio_mmc_clk_update(struct tmio_mmc_host *host)
{
- struct tmio_mmc_host *host = mmc_priv(mmc);
+ struct mmc_host *mmc = host->mmc;
struct tmio_mmc_data *pdata = host->pdata;
int ret;
@@ -911,6 +912,8 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
ios->clock, ios->power_mode);
host->mrq = NULL;
+ host->clk_cache = ios->clock;
+
mutex_unlock(>ios_lock);
pm_runtime_mark_last_busy(mmc_dev(mmc));
@@ -1036,7 +1039,7 @@ int tmio_mmc_host_probe(struct tmio_mmc_host **host,
mmc->caps & MMC_CAP_NONREMOVABLE ||
mmc->slot.cd_irq >= 0);
- if (tmio_mmc_clk_update(mmc) < 0) {
+ if (tmio_mmc_clk_update(_host) < 0) {
mmc->f_max = pdata->hclk;
mmc->f_min = mmc->f_max / 512;
}
@@ -1162,6 +1165,15 @@ EXPORT_SYMBOL(tmio_mmc_host_resume);
#ifdef CONFIG_PM_RUNTIME
int tmio_mmc_host_runtime_suspend(struct device *dev)
{
+ struct mmc_host *mmc = dev_get_drvdata(dev);
+ struct tmio_mmc_host *host = mmc_priv(mmc);
+
+ if (host->clk_cache)
+ tmio_mmc_clk_stop(host);
+
+ if (host->pdata->clk_disable)
+ host->pdata->clk_disable(host->pdev);
+
return 0;
}
EXPORT_SYMBOL(tmio_mmc_host_runtime_suspend);
@@ -1171,6 +1183,14 @@ int tmio_mmc_host_runtime_resume(struct device *dev)
struct mmc_host *mmc = dev_get_drvdata(dev);
struct tmio_mmc_host *host = mmc_priv(mmc);
+ tmio_mmc_reset(host);
+ tmio_mmc_clk_update(host);
+
+ if (host->clk_cache) {
+ tmio_mmc_set_clock(host, host->clk_cache);
+ tmio_mmc_clk_start(host);
+ }
+
tmio_mmc_enable_dma(host, true);
return 0;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] arch: Kconfig: Let all architectures set endian explicitly
Hello all: It seems no any additional rejections for it. I guess, I need split the 'big' patch into pieces, and each send to its' related mailing list, so let it not like a spam. And the schedule may like: - Firstly, send patch for "init/Kconfig" to add CPU_*_ENDIAN. If pass checking (hope it can be passed checking), then - Send each related patch to each related architectures which already knew their ENDIAN attributes in config time (24 patches, I guess), then - Make patch for Kbuild to support __BUILDING_TIME_BIG_ENDIAN__, and pass checking (hope I can finish), then - Finish left architectures which need __BUILDING_TIME_BIG_ENDIAN__ (4 patches, I guess). Welcome any ideas, suggestions, or completions. And if no additional reply, I shall not send any additional information any more to avoid spam to other members. Thanks. On 08/24/2014 04:38 PM, Chen Gang wrote: > Hello Maintainers: > > Is this patch OK? If it pass basic checking, please let me know, and I > shall try to make another related patch for KBuild (I can do nothing > related with Kbuild, before get confirmation for this patch). > > Thanks. > > On 8/15/14 17:01, Chen Gang wrote: >> >> >> On 8/15/14 6:14, Chen Gang wrote: >>> On 08/15/2014 02:04 AM, Ralf Baechle wrote: >>> >>> OK, thanks, I assumes when support both endian, the default choice is >>> CPU_BIG_ENDIAN, although no default value for choice (originally, I did >>> worry about it). >>> So I think you can just drop the MIPS segment from your patch. >>> >>> If what I assumes is correct, what you said sounds reasonable to me. >>> >>> >> >> So for me, it is harmless to add CPU_*_ENDIAN explicitly, and can let >> other members don't need think of. >> >> By the way, for sh, it is almost the same case, except it contents the >> default value, for me, it is clear enough, so I skip sh architecture in >> this patch. >> >> >> Thanks >> > -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- 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 10/12] mmc: sdhi: Fixup system PM suspend lock-up
At system PM suspend, the tmio core accessed the internal registers of
the controller without first moving the device into active state. This
caused a lock-up in system PM suspend phase.
The reason for the register access were masking of IRQs. Since that is
managed via the runtime PM suspend path, let's just re-use that path
for system PM suspend.
In other words force the device into runtime PM suspend state at system
PM suspend and restore it to active state at system PM resume.
Reported-by: Geert Uytterhoeven
Signed-off-by: Ulf Hansson
---
drivers/mmc/host/sh_mobile_sdhi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
b/drivers/mmc/host/sh_mobile_sdhi.c
index 4cd0f09..2dafe28 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -332,7 +332,8 @@ static int sh_mobile_sdhi_remove(struct platform_device
*pdev)
}
static const struct dev_pm_ops tmio_mmc_dev_pm_ops = {
- SET_SYSTEM_SLEEP_PM_OPS(tmio_mmc_host_suspend, tmio_mmc_host_resume)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
SET_PM_RUNTIME_PM_OPS(tmio_mmc_host_runtime_suspend,
tmio_mmc_host_runtime_resume,
NULL)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/12] mmc: tmio_mmc: Fixup system PM suspend lock-up
At system PM suspend, the tmio core accessed the internal registers of the controller without first moving the device into active state. This caused a lock-up in system PM suspend phase. The reason for the register access were masking of IRQs. Since that is managed via the runtime PM suspend path, let's just re-use that path for system PM suspend. In other words force the device into runtime PM suspend state at system PM suspend and restore it to active state at system PM resume. Reported-by: Geert Uytterhoeven Signed-off-by: Ulf Hansson --- drivers/mmc/host/tmio_mmc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c index 58f50ef..659028d 100644 --- a/drivers/mmc/host/tmio_mmc.c +++ b/drivers/mmc/host/tmio_mmc.c @@ -30,7 +30,7 @@ static int tmio_mmc_suspend(struct device *dev) const struct mfd_cell *cell = mfd_get_cell(pdev); int ret; - ret = tmio_mmc_host_suspend(dev); + ret = pm_runtime_force_suspend(dev); /* Tell MFD core it can disable us now.*/ if (!ret && cell->disable) @@ -50,7 +50,7 @@ static int tmio_mmc_resume(struct device *dev) ret = cell->resume(pdev); if (!ret) - ret = tmio_mmc_host_resume(dev); + ret = pm_runtime_force_resume(dev); return ret; } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/12] mmc: tmio: Extract bus_width modifications to a separate function
Move code for bus_width modification, out of the ->set_ios() callback
and into a separate function, to simplify code.
Signed-off-by: Ulf Hansson
---
drivers/mmc/host/tmio_mmc_pio.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index d63d292..8f5b5cc 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -831,6 +831,19 @@ static void tmio_mmc_power_off(struct tmio_mmc_host *host)
host->set_pwr(host->pdev, 0);
}
+static void tmio_mmc_set_bus_width(struct tmio_mmc_host *host,
+ unsigned char bus_width)
+{
+ switch (bus_width) {
+ case MMC_BUS_WIDTH_1:
+ sd_ctrl_write16(host, CTL_SD_MEM_CARD_OPT, 0x80e0);
+ break;
+ case MMC_BUS_WIDTH_4:
+ sd_ctrl_write16(host, CTL_SD_MEM_CARD_OPT, 0x00e0);
+ break;
+ }
+}
+
/* Set MMC clock / power.
* Note: This controller uses a simple divider scheme therefore it cannot
* run a MMC card at full speed (20MHz). The max clock is 24MHz on SD, but as
@@ -914,16 +927,8 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
}
}
- if (host->power != TMIO_MMC_OFF_STOP) {
- switch (ios->bus_width) {
- case MMC_BUS_WIDTH_1:
- sd_ctrl_write16(host, CTL_SD_MEM_CARD_OPT, 0x80e0);
- break;
- case MMC_BUS_WIDTH_4:
- sd_ctrl_write16(host, CTL_SD_MEM_CARD_OPT, 0x00e0);
- break;
- }
- }
+ if (host->power != TMIO_MMC_OFF_STOP)
+ tmio_mmc_set_bus_width(host, ios->bus_width);
/* Let things settle. delay taken from winCE driver */
udelay(140);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] usb: chipidea: msm: Initialize PHY on reset event
Initialize USB PHY after every Link controller reset Signed-off-by: Ivan T. Ivanov --- drivers/usb/chipidea/ci_hdrc_msm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c b/drivers/usb/chipidea/ci_hdrc_msm.c index 30bdd51..4935ac3 100644 --- a/drivers/usb/chipidea/ci_hdrc_msm.c +++ b/drivers/usb/chipidea/ci_hdrc_msm.c @@ -26,6 +26,7 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event) dev_dbg(dev, "CI_HDRC_CONTROLLER_RESET_EVENT received\n"); writel(0, USB_AHBBURST); writel(0, USB_AHBMODE); + usb_phy_init(ci->transceiver); break; case CI_HDRC_CONTROLLER_STOPPED_EVENT: dev_dbg(dev, "CI_HDRC_CONTROLLER_STOPPED_EVENT received\n"); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: stmmac: add dcrs parameter
Hi,
On Mon, Aug 25, 2014 at 7:50 PM, Ley Foon Tan wrote:
> This patch add the option to enable DCRS bit in GMAC control register.
> Default is disabled if snps,dcrs is not defined.
>
> For MII, Carrier Sense (CRS) must be asserted during transmission
> whereas in RGMII, CRS is not. RGMII does not provide a way to signal
> loss of carrier during a transmission.
>
> When DCRS bit set high in control register, the MAC transmitter
> ignore the (G)MII Carrier Sense signal during frame transmission
> in the half-duplex mode. This request results in no errors generated
> because of Loss of Carrier or No Carrier during such transmission.
>
> Signed-off-by: Ley Foon Tan
> ---
> Documentation/devicetree/bindings/net/stmmac.txt | 4
> drivers/net/ethernet/stmicro/stmmac/common.h | 3 ++-
> drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 4 +++-
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 ++-
> drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 ++
> include/linux/stmmac.h| 1 +
> 6 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt
> b/Documentation/devicetree/bindings/net/stmmac.txt
> index 9b03c57..a68e720 100644
> --- a/Documentation/devicetree/bindings/net/stmmac.txt
> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
> @@ -39,6 +39,10 @@ Optional properties:
>further clocks may be specified in derived bindings.
> - clock-names: One name for each entry in the clocks property, the
>first one should be "stmmaceth".
> +- snps,dcrs: Enable DCRS bit in GMAC control register. This DCRS bit makes
> the
> + MAC transmitter ignore the (G)MII CRS signal during frame transmission
> + in the half-duplex mode. This request results in no errors generated
Since you know this is only required under (G)MII, could you not re-use
the "phy-mode" property, instead of adding another one?
Better yet, use the "interface" field in the platform data. This way you'll
fix non-DT devices as well. You could then avoid touching the platform driver,
and just modify the driver core.
Cheers
ChenYu
> + because of Loss of Carrier or No Carrier during such transmission.
>
> Examples:
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
> b/drivers/net/ethernet/stmicro/stmmac/common.h
> index de507c3..9abe221 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/common.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/common.h
> @@ -445,10 +445,11 @@ struct mac_device_info {
> int multicast_filter_bins;
> int unicast_filter_entries;
> int mcast_bits_log2;
> + int dcrs;
> };
>
> struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr, int mcbins,
> - int perfect_uc_entries);
> + int perfect_uc_entries, int dcrs);
> struct mac_device_info *dwmac100_setup(void __iomem *ioaddr);
>
> void stmmac_set_mac_addr(void __iomem *ioaddr, u8 addr[6],
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
> index d8ef187..924d450 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
> @@ -37,6 +37,7 @@ static void dwmac1000_core_init(struct mac_device_info *hw,
> int mtu)
> void __iomem *ioaddr = hw->pcsr;
> u32 value = readl(ioaddr + GMAC_CONTROL);
> value |= GMAC_CORE_INIT;
> + value |= hw->dcrs;
> if (mtu > 1500)
> value |= GMAC_CONTROL_2K;
> if (mtu > 2000)
> @@ -409,7 +410,7 @@ static const struct stmmac_ops dwmac1000_ops = {
> };
>
> struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr, int mcbins,
> - int perfect_uc_entries)
> + int perfect_uc_entries, int dcrs)
> {
> struct mac_device_info *mac;
> u32 hwid = readl(ioaddr + GMAC_VERSION);
> @@ -422,6 +423,7 @@ struct mac_device_info *dwmac1000_setup(void __iomem
> *ioaddr, int mcbins,
> mac->multicast_filter_bins = mcbins;
> mac->unicast_filter_entries = perfect_uc_entries;
> mac->mcast_bits_log2 = 0;
> + mac->dcrs = dcrs;
>
> if (mac->multicast_filter_bins)
> mac->mcast_bits_log2 = ilog2(mac->multicast_filter_bins);
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 08addd6..bf35b19 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -2600,7 +2600,8 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
> priv->dev->priv_flags |= IFF_UNICAST_FLT;
> mac = dwmac1000_setup(priv->ioaddr,
> priv->plat->multicast_filter_bins,
> -
Re: [PATCH] PWM: atmel: fix incorrect CDTY value after enabling or disabling
On Mon, Aug 25, 2014 at 01:54:54PM +0200, Alexandre Belloni wrote: > Hi, > > On 25/08/2014 at 12:15:23 +0200, Thierry Reding wrote : > > On Fri, Mar 14, 2014 at 08:05:31PM +0100, Alexandre Belloni wrote: > > > pwm-leds calls .config() and .disable() in a row. This exhibits that it > > > may > > > happen that the channel gets disabled before CDTY has been updated with > > > CUPD. > > > The issue gets quite worse with long periods. > > > So, ensure by reading ISR that at least one period has past before > > > disabling the > > > channel. > > > > > > The other issue is that it may happen that CUPD is not flushed before > > > enabling > > > the channel so it will update CDTY/CPRD just after one period. So we > > > always set > > > CUPD, even when the channel is not enabled. > > > > > > Tested on at91sam9g45 and sama5d31ek. > > > > > > Signed-off-by: Alexandre Belloni > > > --- > > > drivers/pwm/pwm-atmel.c | 46 > > > +- > > > 1 file changed, 29 insertions(+), 17 deletions(-) > > > > going through the list of unapplied patches I came across this old > > patch. It was never reviewed nor acked by anyone and you didn't ping me, > > so I always assumed it must no longer be required. Is that so? > > > > It is still required but Nicolas is not happy with the polling on > PWM_ISR and he was supposed to discuss that internally with the IP > designer to understand if there is a better way. > > I'll either ping on that one or send a new version when I'll know a bit > more. Okay, thanks. Thierry pgpqjWgPuIZ3Q.pgp Description: PGP signature
suspicions RCU usage in 3.17.0-rc1-00231-g7be141d on sparc64
This is 3.17.0-rc1-00231-g7be141d on sparc64 (4-CPU E420R with US-II
CPUs). It works fine but gave this during reboot:
[info] Will now restart.
[ 4499.742521]
[ 4499.759281] ===
[ 4499.809274] [ INFO: suspicious RCU usage. ]
[ 4499.859270] 3.17.0-rc1-00231-g7be141d #47 Not tainted
[ 4499.919673] ---
[ 4499.969661] include/linux/rcupdate.h:844 rcu_read_lock() used illegally
while idle!
[ 4500.061328]
[ 4500.061328] other info that might help us debug this:
[ 4500.061328]
[ 4500.157159]
[ 4500.157159] RCU used illegally from idle CPU!
[ 4500.157159] rcu_scheduler_active = 1, debug_locks = 0
[ 4500.287348] RCU used illegally from extended quiescent state!
[ 4500.356038] 1 lock held by swapper/0/0:
[ 4500.401850] #0: (rcu_read_lock){..}, at: [<004ee944>]
__perf_event_exit_context+0x24/0x2c0
[ 4500.515385]
[ 4500.515385] stack backtrace:
[ 4500.567462] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
3.17.0-rc1-00231-g7be141d #47
[ 4500.659116] Call Trace:
[ 4500.688253] [0049fecc] lockdep_rcu_suspicious+0xcc/0x120
[ 4500.761168] [004eeba0] __perf_event_exit_context+0x280/0x2c0
[ 4500.838235] [004d6d24] flush_smp_call_function_queue+0x84/0x1a0
[ 4500.918424] [004d74a4]
generic_smp_call_function_single_interrupt+0x4/0x20
[ 4501.010104] [0043f6d4] smp_call_function_single_client+0x14/0x40
[ 4501.091304] [00426b74] valid_addr_bitmap_patch+0x8c/0x258
[ 4501.165248] [0042cecc] arch_cpu_idle+0x2c/0xa0
[ 4501.227733] [0049c53c] cpu_startup_entry+0x15c/0x200
[ 4501.296462] [00829b98] rest_init+0x178/0x1a0
[ 4501.356868] [009dc9dc] start_kernel+0x3e4/0x3f4
[ 4501.420390] [00829a0c] tlb_fixup_done+0xa0/0xb4
[ 4501.483910] [] (null)
[ 4501.539919] reboot: Restarting system
--
Meelis Roos (mr...@linux.ee)
--
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] crypto: testmgr.c: remove unused function argument
On Fri, Aug 08, 2014 at 12:30:04PM +0300, Cristian Stoica wrote: > The argument "req" of do_one_async_hash_op is not used by the > function. This patch removes this argument and renames the > function to match more closely its purpose. > > Signed-off-by: Cristian Stoica Patch applied. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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] crypto: testmgr.c: white space fix-ups on test_aead
On Mon, Jul 28, 2014 at 01:11:23PM +0300, Cristian Stoica wrote: > This patch inverts two if conditions and allows removal of one > tab-stop in their code-blocks. Only white-space clean-up follows. > > Signed-off-by: Cristian Stoica All applied. Thanks Cristian! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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: caamhash.c fixes
On Thu, Aug 14, 2014 at 01:51:55PM +0300, Cristian Stoica wrote: > This is a set of two independent fixes for caamhash driver All applied. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/8] DRBG: efficiency patches
On Sun, Aug 17, 2014 at 05:37:04PM +0200, Stephan Mueller wrote: > Hi, > > The following patch set contains random fixes to increase the efficiency of > the DRBG. Changes include the removal of unneeded memset(0) and sanity > checks. All changes do not weaken the implementation as only code is > removed that is clearly covered by other code paths. > > In addition, the cpu_to_be kernel function together with a type cast is > used to convert an integer into its string representation. This patch > increases the speed of the DRBG by 10%. > > Stephan Mueller (8): > DRBG: replace int2byte with cpu_to_be > DRBG: kzfree does not need a check for NULL pointer > DRBG: remove superflowous checks > DRBG: remove superflowous memset(0) > DRBG: use kmalloc instead of kzalloc for V and C > DRBG: remove unnecessary sanity checks > DRBG: remove configuration of fixed values > DRBG: remove unnecessary sanity check for shadow state All applied. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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 v6 0/6] crypto: SHA1 multibuffer implementation
On Thu, Jul 31, 2014 at 10:29:44AM -0700, Tim Chen wrote: > Herbert, > > I've updated the patches from v5 with the multi-buffer infrastructure > patch contained within the same patch and some patch subject > and comments clean up per Peter's feedback. All applied. Thanks Tim! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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 00/11] drm: add support for Atmel HLCDC Display Controller
On Thu, Aug 21, 2014 at 03:16:08PM +0200, Thierry Reding wrote: > On Thu, Aug 21, 2014 at 03:06:00PM +0200, Boris BREZILLON wrote: > > On Thu, 21 Aug 2014 11:52:03 +0200 > > Thierry Reding wrote: > > > > > On Thu, Aug 21, 2014 at 11:41:59AM +0200, Boris BREZILLON wrote: > > > > On Thu, 21 Aug 2014 11:04:07 +0200 > > > > Thierry Reding wrote: > > > > > > > > > On Thu, Aug 21, 2014 at 10:37:06AM +0200, Boris BREZILLON wrote: > > > > > > Hi Ludovic, > > > > > > > > > > > > On Thu, 21 Aug 2014 10:16:19 +0200 > > > > > > Ludovic Desroches wrote: > > > > > > > > > > > > > Hi Boris, > > > > > > > > > > > > > > You can add > > > > > > > > > > > > > > Tested-by: Ludovic Desroches > > > > > > > > > > > > Thanks for testing this driver. > > > > > > > > > > > > > > > > > > > > Only one issue but not related to your patches, you can't display > > > > > > > quickly the bootup logo since the panel detection takes too much > > > > > > > time. > > > > > > > > > > > > Yes, actually this is related to the device probe order: the > > > > > > hlcdc-display-controller device is probed before the simple-panel, > > > > > > thus > > > > > > nothing is detected on the RGB connector (I use of_drm_find_panel to > > > > > > check for panel availability) when the display controller is > > > > > > instantiated. I rely on the default polling infrastructure provided > > > > > > by > > > > > > the DRM/KMS framework which polls for a new connector every 10s, and > > > > > > this is far more than you kernel boot time. > > > > > > > > > > > > Do anyone see a solution to reduce this delay (without changing the > > > > > > polling interval). I thought we could add a notifier infrastructure > > > > > > to > > > > > > the DRM panel framework, but I'm not sure this is how you want > > > > > > things > > > > > > done... > > > > > > > > > > Other drivers return -EPROBE_DEFER when a panel hasn't been registered > > > > > yet. This will automatically take care of ordering things in a way > > > > > that > > > > > DRM/KMS will only be initialized after the panel has been probed. > > > > > > > > Actually I'd like to avoid doing this with a deferred probe, because, > > > > AFAIU, the remote endpoint is not tightly linked with the display > > > > controller driver (I mean the display controller can still be > > > > initialized without having a display connected on it). > > > > Moreover the atmel dev kit I'm using has an HDMI bridge connected on > > > > the same RGB connector and I'd like to use it in a near future. > > > > Returning -EPROBE_DEFER in case of several devices connected on the > > > > same connector implies that I'll have to wait for all the remote > > > > end-points to be available before my display controller could be > > > > instantiated. > > > > > > > > While this could be acceptable when all drivers are statically linked > > > > in the kernel, it might be problematic when you're using modules, > > > > meaning that you won't be able to display anything on your LCD panel > > > > until your HDMI bridge module has been loaded. > > > > > > No. HDMI should be using proper hotplugging anyway, hence it should be > > > always be loaded anyway. You're in for a world of pain if you think you > > > can run DRM with a driver that's composed of separate kernel modules. > > > > I was talking about the external RGB to HDMI encoder, should the driver > > for this encoder (which is not on On Chip block) be compiled > > statically too ? > > > > > > > > Also if you don't want to use deferred probe, then you're in for the > > > full hotplugging panel dance and that implies that you need to fix a > > > bunch of things in DRM (one being the framebuffer console instantiation > > > that I referred to in the other thread). > > > > For now, I wait until there is a device connected on the RGB connector > > (connector status set to connector_status_connected) before creating an > > fbdev. It might not be the cleanest way to solve this issue, but it > > works :-). > > Yeah, I guess that's one way to do it. But it's tricky to get right when > you have several outputs. Which one should be considered the primary and > trigger fbdev creation? We could just reallocate the fbdev backing storage (probably only increase it for safety since fbdev is bonghits) when new outputs show up. There has been (and maybe still is) some provisions in the fbdev helper library to do just that. Mostly it would mean to split out drm_fb_helper_single_fb_probe so that drivers could call it from their hotplug work. And then adjust the ->fb_probe callback of drivers which do this to reallocate the fbdev buffer if it's only a resize. Overall this shouldn't be too much fuzz to get going. Of course only as an opt-in, but imo that's the only sane way to do this anyway. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a
Re: Linux UDF support
On 2014-08-24 08:46, Pali Rohár wrote: > Hi, > > I would like to know what is state of linux UDF driver. It is > experimental or is now suitable for storing data? > I know that read support works for every version I have tested, but I've only tested it reading data from DVD's and Blu-Ray discs, so I don't know how well it works for other purposes. > According to wikipedia [1] UDF has open specification format and > can be used also for HDDs (not only optical discs). > > In OS support table is written that all major and other minor OSs > support UDF FS (without needs for additional programs). > > So it looks like UDF is good candidate for multi OS filesystem. > Are there any disadvantages for using UDF on e.g USB flash disk? > (when I want read/write support on Linux, Windows 7 and Mac OS X) If you are going to go that way, make sure to use the Spared Build, as otherwise you will run in to the same media wear-out issues that NTFS and FAT have. Also, keep in mind that pre-Vista Windows and pre-10.4 OSX don't have very good support for the newer formats. > Because lot of manuals say that FAT32 (or NTFS) is only one > solution for using USB flash disk on more OS. > > On wikipedia there is one note about linux: Write support is only > up to UDF version 2.01. Is this restriction still valid? I do know that we support reading UDF 2.60 (I've used linux to read Blu-Ray discs), but I have no idea about write support for versions above 2.01. > What will happen if I try to mount FS with UDF version 2.60 in > R/W mode on linux? It will fallback to R/O mode? Or newly written > files will be in previous (2.01) versions? > > And last question: Is there some fsck tool for UDF? Or at least > tool which print if FS is in inconsistent state? Most Linux distributions have a package called udftools, the upstream URL given by portage is http://sf.net/projects/linux-udf/ > > [1] - http://en.wikipedia.org/wiki/Universal_Disk_Format > smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH] net: stmmac: add dcrs parameter
On 8/25/2014 2:34 PM, Chen-Yu Tsai wrote:
Hi,
On Mon, Aug 25, 2014 at 7:50 PM, Ley Foon Tan wrote:
This patch add the option to enable DCRS bit in GMAC control register.
Default is disabled if snps,dcrs is not defined.
For MII, Carrier Sense (CRS) must be asserted during transmission
whereas in RGMII, CRS is not. RGMII does not provide a way to signal
loss of carrier during a transmission.
When DCRS bit set high in control register, the MAC transmitter
ignore the (G)MII Carrier Sense signal during frame transmission
in the half-duplex mode. This request results in no errors generated
because of Loss of Carrier or No Carrier during such transmission.
Signed-off-by: Ley Foon Tan
---
Documentation/devicetree/bindings/net/stmmac.txt | 4
drivers/net/ethernet/stmicro/stmmac/common.h | 3 ++-
drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 4 +++-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 ++-
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 ++
include/linux/stmmac.h| 1 +
6 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt
b/Documentation/devicetree/bindings/net/stmmac.txt
index 9b03c57..a68e720 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -39,6 +39,10 @@ Optional properties:
further clocks may be specified in derived bindings.
- clock-names: One name for each entry in the clocks property, the
first one should be "stmmaceth".
+- snps,dcrs: Enable DCRS bit in GMAC control register. This DCRS bit makes the
+ MAC transmitter ignore the (G)MII CRS signal during frame transmission
+ in the half-duplex mode. This request results in no errors generated
Since you know this is only required under (G)MII, could you not re-use
the "phy-mode" property, instead of adding another one?
Better yet, use the "interface" field in the platform data. This way you'll
fix non-DT devices as well. You could then avoid touching the platform driver,
and just modify the driver core.
yes this is what I asked. Thx ChenYu for the this detail.
Ley Foon Tan, could you do that? Let me know
peppe
Cheers
ChenYu
+ because of Loss of Carrier or No Carrier during such transmission.
Examples:
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index de507c3..9abe221 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -445,10 +445,11 @@ struct mac_device_info {
int multicast_filter_bins;
int unicast_filter_entries;
int mcast_bits_log2;
+ int dcrs;
};
struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr, int mcbins,
- int perfect_uc_entries);
+ int perfect_uc_entries, int dcrs);
struct mac_device_info *dwmac100_setup(void __iomem *ioaddr);
void stmmac_set_mac_addr(void __iomem *ioaddr, u8 addr[6],
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index d8ef187..924d450 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -37,6 +37,7 @@ static void dwmac1000_core_init(struct mac_device_info *hw,
int mtu)
void __iomem *ioaddr = hw->pcsr;
u32 value = readl(ioaddr + GMAC_CONTROL);
value |= GMAC_CORE_INIT;
+ value |= hw->dcrs;
if (mtu > 1500)
value |= GMAC_CONTROL_2K;
if (mtu > 2000)
@@ -409,7 +410,7 @@ static const struct stmmac_ops dwmac1000_ops = {
};
struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr, int mcbins,
- int perfect_uc_entries)
+ int perfect_uc_entries, int dcrs)
{
struct mac_device_info *mac;
u32 hwid = readl(ioaddr + GMAC_VERSION);
@@ -422,6 +423,7 @@ struct mac_device_info *dwmac1000_setup(void __iomem
*ioaddr, int mcbins,
mac->multicast_filter_bins = mcbins;
mac->unicast_filter_entries = perfect_uc_entries;
mac->mcast_bits_log2 = 0;
+ mac->dcrs = dcrs;
if (mac->multicast_filter_bins)
mac->mcast_bits_log2 = ilog2(mac->multicast_filter_bins);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 08addd6..bf35b19 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2600,7 +2600,8 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
priv->dev->priv_flags |= IFF_UNICAST_FLT;
mac = dwmac1000_setup(priv->ioaddr,
Re: [PATCH v4 0/8] asm-generic/io.h overhaul
Am 25.08.2014 14:27, schrieb Thierry Reding:
> On Mon, Aug 25, 2014 at 01:53:30PM +0200, Richard Weinberger wrote:
>> On Wed, Aug 13, 2014 at 12:28 PM, Thierry Reding
>> wrote:
>>> From: Thierry Reding
>>>
>>> Hi,
>>>
>>> Here is the fourth version of a series that started out as an attempt to
>>> provide string versions of the read*() and write*() accessors to more
>>> architectures so that drivers can use them portably. The series has
>>> since evolved into a more general cleanup of asm-generic/io.h and the
>>> functions defined therein.
>>>
>>> Patch 1 is trivial and removes a redundant redefinition of PCI_IOBASE
>>> from the asm/io.h header on ARC. Patches 2 and 3 remove unnecessary
>>> volatile keywoards from some functions, which is a prerequisite to clean
>>> up some of the functions in subsequent patches.
>>>
>>> The xlate_dev_{kmem,mem}_ptr() functions are used to map memory when the
>>> /dev/mem device is accessed. Patches 4 and 5 use more consistent data
>>> types for these functions, which will get a "standard" prototype in the
>>> asm-generic/io.h header in a subsequent patch.
>>>
>>> Patch 6 is the bulk of this series. It implements the string variants of
>>> the read*() and write*() accessors and cleans up various other parts of
>>> the asm-generic/io.h header file. Macros are converted to static inline
>>> functions for better type checking. Overriding generic implementations
>>> in architectures is handled more consistently.
>>>
>>> Patches 7 and 8, finally, make use of the asm-generic/io.h header on the
>>> 32-bit and 64-bit ARM architectures.
>>>
>>> This is compile- and runtime-tested on 32-bit and 64-bit ARM and compile
>>> tested on IA64, Microblaze, s390, SPARC, x86 and Xtensa. For ARC,
>>> Blackfin, Metag, OpenRISC, Score and Unicore32 which also use
>>> asm-generic/io.h I couldn't find or build a cross-compiler that would
>>> run on my system. But by code inspection they shouldn't break with this
>>> patch.
>>>
>>> To ensure bisectability I built multi_v7_defconfig on 32-bit ARM and the
>>> defconfig for 64-bit ARM, IA64, Microblaze, s390, SPARC, x86 and Xtensa
>>> after each commit and verified that the series does not introduce any
>>> build errors or warnings.
>>>
>>> Provided there are no objections to the patches there's still the matter
>>> of how to merge them. Patch 6 depends on patches 1-5 to avoid warnings
>>> and/or errors during the build. Patches 7 and 8 depend on patch 6. In my
>>> opinion it doesn't make much sense to split them up, so I guess we'll
>>> need a volunteer to take them all into one tree. Ideally that tree would
>>> feed into linux-next so that we can get as much build and test-coverage
>>> as possible during the 3.17 release cycle so that these patches can go
>>> into 3.18.
>>>
>>> Arnd, I'm opportunistically sending this To: you in the hopes that you
>>> can take it into your asm-generic tree which seems like the best fit for
>>> this.
>>
>> Do you have a git tree for that?
>> Would be nice for testing UML, it depends also on generic io.
>
> Yes, it's all here:
>
> https://github.com/thierryreding/linux.git staging/asm-generic-io
>
> That branch is based on today's linux-next (next-20140825).
Looks good, UML builds and boots fine here.
Thanks,
//richard
--
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: Loading initrd above 4G causes freeze on boot
On Mon, 25 Aug, at 02:08:59PM, Mantas Mikulėnas wrote:
>
> Well, all I could find is:
>
> > Freeing initrd memory: 5552K (8800be22e000 - 8800be79a000)
>
> Attaching the entire log.
Here we go,
> [0.00] RAMDISK: [mem 0xbe22e000-0xbe799fff]
OK, we're out of options here. Yinghai, we're going to have to revert
your patch, 4bf7111f5016 ("x86/efi: Support initrd loaded above 4G")
We could conceivably add a boot parameter option to attempt loading
inirds above 4G, but we can't turn the feature on by default because of
all these buggy EFI implementations - things must work out of the box.
But the boot parameter would be useful for those people that a) know
their firmware isn't buggy and b) need to leave < 4G memory available
for use by other things. Yinghai, can you provide some justification for
your original commit? Do you have concrete use cases where loading
initrds above 4G is critical? How important is it that we enable this
functionality as opposed to reverting it?
It might also make sense to bump the default max initrd address
(hdr->initrd_addr_max) from 0x7fff to 0x at this point.
Peter, do you forsee any problem with this change?
--
Matt Fleming, Intel Open Source Technology Center
--
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 v3 13/17] arcmsr: fix ioctl data read/write error for adapter type C
On 08/25/2014 12:29 PM, Tomas Henzl wrote:
> On 08/25/2014 07:59 PM, Ching Huang wrote:
>> On Fri, 2014-08-22 at 18:00 +0200, Tomas Henzl wrote:
>>> On 08/19/2014 09:17 AM, Ching Huang wrote:
From: Ching Huang
Rewrite ioctl entry and its relate function.
This patch fix ioctl data read/write error and change data I/O access from
byte to Dword.
Signed-off-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr_attr.c
b/drivers/scsi/arcmsr/arcmsr_attr.c
--- a/drivers/scsi/arcmsr/arcmsr_attr.c2014-02-06 17:47:24.0
+0800
+++ b/drivers/scsi/arcmsr/arcmsr_attr.c2014-04-29 17:10:42.0
+0800
@@ -70,40 +70,75 @@ static ssize_t arcmsr_sysfs_iop_message_
struct AdapterControlBlock *acb = (struct AdapterControlBlock *)
host->hostdata;
uint8_t *pQbuffer,*ptmpQbuffer;
int32_t allxfer_len = 0;
+ unsigned long flags;
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
/* do message unit read. */
ptmpQbuffer = (uint8_t *)buf;
- while ((acb->rqbuf_firstindex != acb->rqbuf_lastindex)
- && (allxfer_len < 1031)) {
+ spin_lock_irqsave(>rqbuffer_lock, flags);
+ if (acb->rqbuf_firstindex != acb->rqbuf_lastindex) {
>>> Hi - does this condition (acb->rqbuf_firstindex == acb->rqbuf_lastindex)
>>> mean we could just release
>>> the spinlock and return ?
>>>
>> NO. We have to check the input buffer that may have message data come
>> from IOP.
pQbuffer = >rqbuffer[acb->rqbuf_firstindex];
- memcpy(ptmpQbuffer, pQbuffer, 1);
- acb->rqbuf_firstindex++;
- acb->rqbuf_firstindex %= ARCMSR_MAX_QBUFFER;
- ptmpQbuffer++;
- allxfer_len++;
+ if (acb->rqbuf_firstindex > acb->rqbuf_lastindex) {
+ if ((ARCMSR_MAX_QBUFFER - acb->rqbuf_firstindex) >=
1032) {
+ memcpy(ptmpQbuffer, pQbuffer, 1032);
+ acb->rqbuf_firstindex += 1032;
+ acb->rqbuf_firstindex %= ARCMSR_MAX_QBUFFER;
+ allxfer_len = 1032;
+ } else {
+ if (((ARCMSR_MAX_QBUFFER -
acb->rqbuf_firstindex)
+ + acb->rqbuf_lastindex) > 1032) {
+ memcpy(ptmpQbuffer, pQbuffer,
+ ARCMSR_MAX_QBUFFER
+ - acb->rqbuf_firstindex);
+ ptmpQbuffer += ARCMSR_MAX_QBUFFER
+ - acb->rqbuf_firstindex;
+ memcpy(ptmpQbuffer, acb->rqbuffer, 1032
+ - (ARCMSR_MAX_QBUFFER -
+ acb->rqbuf_firstindex));
>>> This code looks like you were copying some data from a ring buffer,
>>> in that case - shouldn't be acb->rqbuf_lastindex used instead of firstindex?
>>>
>> Yes, there copying data from a ring buffer. firstindex and lastindex are
>> bad name. For readability, I rename the firstindex to getIndex,
>> lastindex to putIndex.
> My comment is not about names, but in this path '(ARCMSR_MAX_QBUFFER -
> acb->rqbuf_firstindex)+ acb->rqbuf_lastindex) > 1032)'
> you copy something twice and in both cases the 'firstindex' is used and never
> the 'lastindex'.
> Is this correct?
And when it is copying from a ring buffer, maybe it could be made in a simpler
way?
What do you think about this (not even compile tested, just an idea):
spin_lock_irqsave(>rqbuffer_lock, flags);
unsigned int tail = acb->rqbuf_firstindex;
unsigned int head = acb->rqbuf_lastindex;
unsigned int cnt_to_end = CIRC_CNT_TO_END(head, tail,
ARCMSR_MAX_QBUFFER);
allxfer_len = CIRC_CNT(head, tail, ARCMSR_MAX_QBUFFER);
if (allxfer_len > 1032)
allxfer_len = 1032;
if (allxfer_len <= cnt_to_end)
memcpy(buf, acb->rqbuffer + tail, allxfer_len);
else {
memcpy(buf, acb->rqbuffer + tails, cnt_to_end);
memcpy(buf + cnt_to_end, acb->rqbuffer, allxfer_len -
cnt_to_end);
}
acb->rqbuf_firstindex = (acb->rqbuf_firstindex + allxfer_len) %
ARCMSR_MAX_QBUFFER;
>
>>> What does the 1032 mean is that a hw. limit, actually could you explain the
>>> code
>>> should do? Maybe I'm just wrong with my assumptions.
>> 1032 is the API data buffer limitation.
>>> Thanks,
>>> Tomas
>>>
+ acb->rqbuf_firstindex = 1032 -
+ (ARCMSR_MAX_QBUFFER -
+ acb->rqbuf_firstindex);
+ allxfer_len =
[PATCH] iio: core: Propagate error codes from OF layer to client drivers
Do not overwrite error codes returned from of_iio_channel_get().
Error codes are used to distinguish between "io-channel-names"
not present in DT bindings, property is optional, and IIO channel
provider driver still not being loaded, defer probe.
Signed-off-by: Ivan T. Ivanov
---
drivers/iio/inkern.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
index c749700..66a6cde 100644
--- a/drivers/iio/inkern.c
+++ b/drivers/iio/inkern.c
@@ -162,7 +162,7 @@ err_free_channel:
static struct iio_channel *of_iio_channel_get_by_name(struct device_node *np,
const char *name)
{
- struct iio_channel *chan = NULL;
+ struct iio_channel *chan = ERR_PTR(-ENODEV);
/* Walk up the tree of devices looking for a matching iio channel */
while (np) {
@@ -183,7 +183,7 @@ static struct iio_channel
*of_iio_channel_get_by_name(struct device_node *np,
else if (name && index >= 0) {
pr_err("ERROR: could not get IIO channel %s:%s(%i)\n",
np->full_name, name ? name : "", index);
- return NULL;
+ break;
}
/*
@@ -193,7 +193,7 @@ static struct iio_channel
*of_iio_channel_get_by_name(struct device_node *np,
*/
np = np->parent;
if (np && !of_get_property(np, "io-channel-ranges", NULL))
- return NULL;
+ break;
}
return chan;
@@ -243,12 +243,12 @@ error_free_chans:
static inline struct iio_channel *
of_iio_channel_get_by_name(struct device_node *np, const char *name)
{
- return NULL;
+ return ERR_PTR(-ENODEV);
}
static inline struct iio_channel *of_iio_channel_get_all(struct device *dev)
{
- return NULL;
+ return ERR_PTR(-ENODEV);
}
#endif /* CONFIG_OF */
@@ -312,14 +312,14 @@ struct iio_channel *iio_channel_get(struct device *dev,
const char *name = dev ? dev_name(dev) : NULL;
struct iio_channel *channel;
- if (dev) {
- channel = of_iio_channel_get_by_name(dev->of_node,
-channel_name);
- if (channel != NULL)
- return channel;
- }
+ channel = iio_channel_get_sys(name, channel_name);
+ if (!IS_ERR(channel))
+ return channel;
+
+ if (!dev)
+ return channel;
- return iio_channel_get_sys(name, channel_name);
+ return of_iio_channel_get_by_name(dev->of_node, channel_name);
}
EXPORT_SYMBOL_GPL(iio_channel_get);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i2c: axxia: Add I2C driver for AXM55xx
Add I2C bus driver for the controller found in the LSI Axxia family SoCs. The
driver implements 10-bit addressing and SMBus transfer modes via emulation
(including SMBus block data read).
Signed-off-by: Anders Berg
---
.../devicetree/bindings/i2c/i2c-axxia.txt | 30 ++
drivers/i2c/busses/Kconfig | 9 +
drivers/i2c/busses/Makefile| 1 +
drivers/i2c/busses/i2c-axxia.c | 591 +
4 files changed, 631 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-axxia.txt
create mode 100644 drivers/i2c/busses/i2c-axxia.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-axxia.txt
b/Documentation/devicetree/bindings/i2c/i2c-axxia.txt
new file mode 100644
index 000..2296d78
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-axxia.txt
@@ -0,0 +1,30 @@
+LSI Axxia I2C
+
+Required properties :
+- compatible : Must be "lsi,api2c"
+- reg : Offset and length of the register set for the device
+- interrupts : the interrupt specifier
+- #address-cells : Must be <1>;
+- #size-cells : Must be <0>;
+- clock-names : Must contain "i2c".
+- clocks: Must contain an entry for each name in clock-names. See the common
+ clock bindings.
+
+Optional properties :
+- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
+ the default 100 kHz frequency will be used. As only Normal and Fast modes
+ are supported, possible values are 10 and 40.
+
+Example :
+
+i2c@02010084000 {
+ compatible = "lsi,api2c";
+ device_type = "i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x20 0x10084000 0x00 0x1000>;
+ interrupts = <0 19 4>;
+ clocks = <_per>;
+ clock-names = "i2c";
+ clock-frequency = <40>;
+};
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 2ac87fa..7f7bf8f 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -77,6 +77,15 @@ config I2C_AMD8111
This driver can also be built as a module. If so, the module
will be called i2c-amd8111.
+config I2C_AXXIA
+ tristate "Axxia I2C controller"
+ depends on ARCH_AXXIA
+ help
+ Say yes if you want to support the I2C bus on Axxia platforms.
+
+ If you don't know, say Y.
+
+
config I2C_I801
tristate "Intel 82801 (ICH/PCH)"
depends on PCI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 49bf07e..5899edb 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_I2C_ALI15X3) += i2c-ali15x3.o
obj-$(CONFIG_I2C_AMD756) += i2c-amd756.o
obj-$(CONFIG_I2C_AMD756_S4882) += i2c-amd756-s4882.o
obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o
+obj-$(CONFIG_I2C_AXXIA)+= i2c-axxia.o
obj-$(CONFIG_I2C_I801) += i2c-i801.o
obj-$(CONFIG_I2C_ISCH) += i2c-isch.o
obj-$(CONFIG_I2C_ISMT) += i2c-ismt.o
diff --git a/drivers/i2c/busses/i2c-axxia.c b/drivers/i2c/busses/i2c-axxia.c
new file mode 100644
index 000..e6c9b88
--- /dev/null
+++ b/drivers/i2c/busses/i2c-axxia.c
@@ -0,0 +1,591 @@
+/*
+ * drivers/i2c/busses/i2c-axxia.c
+ *
+ * This driver implements I2C master functionality using the LSI API2C
+ * controller.
+ *
+ * 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.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SCL_WAIT_TIMEOUT_NS 2500
+#define I2C_XFER_TIMEOUT(msecs_to_jiffies(250))
+#define I2C_STOP_TIMEOUT(msecs_to_jiffies(100))
+#define FIFO_SIZE 8
+
+#define GLOBAL_CONTROL 0x00
+#define GLOBAL_MST_EN BIT(0)
+#define GLOBAL_SLV_EN BIT(1)
+#define GLOBAL_IBML_ENBIT(2)
+#define INTERRUPT_STATUS 0x04
+#define INTERRUPT_ENABLE 0x08
+#define INT_SLV BIT(1)
+#define INT_MST BIT(0)
+#define WAIT_TIMER_CONTROL 0x0c
+#define WT_ENBIT(15)
+#define WT_VALUE(_x) ((_x) & 0x7fff)
+#define IBML_TIMEOUT 0x10
+#define IBML_LOW_MEXT 0x14
+#define IBML_LOW_SEXT 0x18
+#define TIMER_CLOCK_DIV0x1c
+#define I2C_BUS_MONITOR0x20
+#define SOFT_RESET 0x24
+#define MST_COMMAND0x28
+#define CMD_BUSY (1<<3)
+#define CMD_MANUAL (0x00 | CMD_BUSY)
+#define CMD_AUTO (0x01 | CMD_BUSY)
+#define MST_RX_XFER0x2c
+#define MST_TX_XFER0x30
+#define MST_ADDR_1 0x34
+#define MST_ADDR_2 0x38
+#define MST_DATA 0x3c
+#define MST_TX_FIFO0x40
+#define MST_RX_FIFO0x44
+#define MST_INT_ENABLE
Re: [PATCH/RFC] hash: Let gcc decide how to multiply
On 08/25/2014 02:13 PM, Rasmus Villemoes wrote:
A 9+ years old comment in hash_64 says that gcc can't optimize
multiplication by GOLDEN_RATIO_PRIME_64. Well, compilers get smarter
and CPUs get faster all the time, so it is perhaps about time to
revisit that assumption.
Seems fine by me, but Cc'ing a couple of others (as those you have Cc'ed
haven't written that code :)). You might want to let your changes go via
Andrew's tree, too, perhaps ...
A stupid micro-benchmark [3] on my x86_64 machine shows that letting
gcc generate the imul instruction is ~60% faster than the sequence of
shifts and add/sub. But that is cheating, since the load of the
constant is hoisted out of the loop. A slightly less stupid [1]
micro-benchmark still shows ~55% improvement over the current
version. So let the compiler do its job.
Also, this should reduce the instruction cache footprint of all
callers of the force-inlined hash_64. [2]
While at it, fix the suffixes of GOLDEN_RATIO_PRIME_{32,64} so that
their types are compatible with u32/u64 on all platforms (I'm not sure
what the compiler does on a 32-bit platform when encountering a
too-wide literal with an explicit UL suffix).
[1] It is stupid in another way, since my inline asm skills
suck. Still, I at least get to force the compiler to do the load on
every loop iteration.
[2] Well, it is an overall win: x86_64, defconfig, gcc 4.7.2:
$ scripts/bloat-o-meter /tmp/vmlinux-{master,hash}
add/remove: 0/1 grow/shrink: 17/44 up/down: 622/-2418 (-1796)
[3] Please don't laugh:
/*
$ gcc -Wall -O2 -o hashtest hashtest.c
$ ./hashtest
gcc_hash2093320 12624
asm_hash2093320 14264
kernel_hash 2093320 32076
$ echo $((100*12624/32076)), $((100*14264/32076))
39, 44
*/
#include
#include
#include
#include
#include
#include
#define u64 uint64_t
#define GOLDEN_RATIO_PRIME_64 0x9e37fffc0001UL
#ifndef __always_inline
#define __always_inline __inline __attribute__ ((__always_inline__))
#endif
static __always_inline u64 kernel_hash(u64 val, unsigned int bits)
{
u64 hash = val;
/* Sigh, gcc can't optimise this alone like it does for 32 bits. */
u64 n = hash;
n <<= 18;
hash -= n;
n <<= 33;
hash -= n;
n <<= 3;
hash += n;
n <<= 3;
hash -= n;
n <<= 4;
hash += n;
n <<= 2;
hash += n;
/* High bits are more random, so use them. */
return hash >> (64 - bits);
}
static __always_inline u64 gcc_hash(u64 val, unsigned int bits)
{
u64 hash = val * GOLDEN_RATIO_PRIME_64;
return hash >> (64 - bits);
}
static __always_inline u64 asm_hash(u64 val, unsigned int bits)
{
u64 hash;
__asm__("mov %1, %%rax\n\t"
"movabs $0x9e37fffc0001,%%rdx\n\t"
"imul %%rdx,%%rax\n\t"
"mov%%rax, %0"
: "=r"(hash)
:"r"(val)
: "%rax", "%rdx");
return hash >> (64 - bits);
}
/* I have 32 KiB of L1 data cache. */
#define N ((1<<15)/sizeof(u64))
#define NBITS 10 /* doesn't seem to affect the outcome */
int main(void)
{
unsigned long start, stop;
u64 buf[N];
int fd = open("/dev/urandom", O_RDONLY);
u64 sum;
int i;
if (fd < 0)
exit(1);
if (read(fd, buf, sizeof(buf)) != sizeof(buf))
exit(2);
close(fd);
#define TEST(f) do {\
sum = 0;\
start = rdtsc();\
for (i = 0; i < N; ++i) \
sum += f(buf[i], NBITS);\
stop = rdtsc(); \
printf("%s\t%lu\t%lu\n", #f, sum, stop-start);\
} while (0)
TEST(gcc_hash);
TEST(asm_hash);
TEST(kernel_hash);
return 0;
}
Signed-off-by: Rasmus Villemoes
---
include/linux/hash.h | 21 +++--
1 file changed, 3 insertions(+), 18 deletions(-)
diff --git a/include/linux/hash.h b/include/linux/hash.h
index bd1754c..6a0879a 100644
--- a/include/linux/hash.h
+++ b/include/linux/hash.h
@@ -19,9 +19,9 @@
#include
/* 2^31 + 2^29 - 2^25 + 2^22 - 2^19 - 2^16 + 1 */
-#define GOLDEN_RATIO_PRIME_32 0x9e370001UL
+#define GOLDEN_RATIO_PRIME_32 0x9e370001U
/* 2^63 + 2^61 - 2^57 + 2^54 - 2^51 - 2^18 + 1 */
-#define GOLDEN_RATIO_PRIME_64 0x9e37fffc0001UL
+#define GOLDEN_RATIO_PRIME_64 0x9e37fffc0001ULL
#if BITS_PER_LONG == 32
#define GOLDEN_RATIO_PRIME GOLDEN_RATIO_PRIME_32
@@ -35,22 +35,7 @@
static __always_inline u64 hash_64(u64 val, unsigned int bits)
{
- u64 hash = val;
-
- /* Sigh, gcc can't optimise this alone like it does for 32 bits. */
- u64 n = hash;
- n <<= 18;
- hash -= n;
-
Re: [PATCH V2] efi_high_alloc: use EFI_ALLOCATE_MAX_ADDRESS
On Mon, 25 Aug, at 01:55:32PM, har...@redhat.com wrote: > From: Harald Hoyer > > On my Lenovo T420s with 4GB memory, efi_high_alloc() was checking the > following memory regions: > > 0x0010 - 0x2000 > 0x2020 - 0x4000 > 0x4020 - 0xd2c02000 > 0xd6e9f000 - 0x00011e60 > > and decided to allocate 2649 pages at address 0x11dba7000. > ... > [0.00] efi: mem53: type=2, attr=0xf, > range=[0x00011dba7000-0x00011e60) (10MB) > ... > [0.00] RAMDISK: [mem 0x11dba7000-0x11e5f] > ... > [0.154933] Unpacking initramfs... > [0.160990] Initramfs unpacking failed: junk in compressed archive > [0.163436] Freeing initrd memory: 10596K (88011dba7000 - > 88011e60) > ... > > Nevertheless, unpacking of the initramfs later on failed. > This is maybe caused by my buggy EFI BIOS and > commit 4bf7111f50167133a71c23530ca852a41355e739, > which enables loading the initramfs above 4G addresses. > > With this patch efi_high_alloc() now uses EFI_ALLOCATE_MAX_ADDRESS, > which should do the same as before, but use the EFI logic to select the high > memory range. No, that's not correct. Your patch changes the semantics of efi_high_alloc(). The original version allocates from the top of memory down, so you always get the highest aligned address, that is no higher than 'max_addr'. Your version allocates some address that isn't above 'max_addr', but it needn't necessarily be the highest possible address. The following is taken from the AllocatePages() documentation in the UEFI spec, "Allocation requests of Type AllocateMaxAddress allocate any available range of pages whose uppermost address is less than or equal to the address pointed to by Memory on input." Note the part about allocating *any* available range. Furthermore, there are more callers of efi_high_alloc() than the initrd loading case, and you've changed their behaviour with this patch. I get where you're coming from, but this isn't the best way to solve this problem, sorry. NAK. -- Matt Fleming, Intel Open Source Technology Center -- 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] doc: memory-barriers.txt: Correct example for reorderings
Correct the example of memory orderings in memory-barriers.txt Commit 615cc2c9cf95 "Documentation/memory-barriers.txt: fix important typo re memory barriers" changed the assignment to x and y. Change the rest of the example to match this change. Reported-by: Ganesh Rapolu Signed-off-by: Pranith Kumar --- Documentation/memory-barriers.txt | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index a4de88f..cf31875 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -121,22 +121,22 @@ For example, consider the following sequence of events: The set of accesses as seen by the memory system in the middle can be arranged in 24 different combinations: - STORE A=3, STORE B=4, x=LOAD A->3,y=LOAD B->4 - STORE A=3, STORE B=4, y=LOAD B->4,x=LOAD A->3 - STORE A=3, x=LOAD A->3,STORE B=4, y=LOAD B->4 - STORE A=3, x=LOAD A->3,y=LOAD B->2,STORE B=4 - STORE A=3, y=LOAD B->2,STORE B=4, x=LOAD A->3 - STORE A=3, y=LOAD B->2,x=LOAD A->3,STORE B=4 - STORE B=4, STORE A=3, x=LOAD A->3,y=LOAD B->4 + STORE A=3, STORE B=4, x=LOAD B->4,y=LOAD A->3 + STORE A=3, STORE B=4, y=LOAD A->3,x=LOAD B->4 + STORE B=4, x=LOAD B->4,STORE A=3, y=LOAD A->3 + STORE A=3, x=LOAD B->2,y=LOAD A->3,STORE B=4 + STORE B=4, y=LOAD A->1,STORE A=3, x=LOAD B->4 + STORE B=4, y=LOAD A->1,x=LOAD B->4,STORE A=3 + STORE B=4, STORE A=3, x=LOAD B->4,y=LOAD A->3 STORE B=4, ... ... and can thus result in four different combinations of values: - x == 1, y == 2 - x == 1, y == 4 - x == 3, y == 2 - x == 3, y == 4 + x == 2, y == 1 + x == 2, y == 3 + x == 4, y == 1 + x == 4, y == 3 Furthermore, the stores committed by a CPU to the memory system may not be -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Add TLS record layer encryption module
Hi, On Di, 2014-07-29 at 12:32 +0300, Cristian Stoica wrote: > This set of patches introduces support for TLS 1.0 record layer > encryption/decryption with a corresponding algorithm called > tls10(hmac(),cbc()). > > Similarly to authenc.c on which it is based, this module mixes the base > algorithms in software to produce an algorithm that does record layer > encryption and decryption for TLS1.0. > Any combination of hw and sw base algorithms is possible, but the purpose > is to take advantage of hardware acceleration for TLS record layer offloading > when hardware acceleration is present. > > This is a software alternative to forthcoming Freescale caam patches that > will add support for one-pass hardware-only TLS record layer offloading. > > Performance figures depend largely on several factors including hardware > support and record layer size. For user-space applications the > kernel/user-space interface is also important. That said, we have done several > performance tests using openssl and cryptodev on Freescale QorIQ platforms. > On P4080, for a single stream of records larger than 512 bytes, the > performance > improved from about 22Mbytes/s to 64Mbytes/s while also reducing CPU load. > > The purpose of this module is to enable TLS kernel offloading on hw platforms > that have acceleration for AES/SHA1 but do not have direct support for TLS > record layer. > > (minor dependency on pending patch > crypto: testmgr.c: white space fix-ups on test_aead) > > Cristian Stoica (2): > crypto: add support for TLS 1.0 record encryption > crypto: add TLS 1.0 test vectors for AES-CBC-HMAC-SHA1 > > crypto/Kconfig | 20 ++ > crypto/Makefile | 1 + > crypto/authenc.c | 5 +- > crypto/tcrypt.c | 5 + > crypto/testmgr.c | 41 +++- > crypto/testmgr.h | 217 +++ > crypto/tls.c | 528 > +++ > include/crypto/authenc.h | 3 + > 8 files changed, 808 insertions(+), 12 deletions(-) > create mode 100644 crypto/tls.c > Maybe could you add net...@vger.kernel.org to Cc on your next submission? It would be great if this feature would be made available in some way that user space does TLS handshaking over a socket and symmetric keys could later be installed via e.g. setsockopt and kernel offloads tls processing over this socket. Alert message handling seems problematic, though and might require some out-of-band interface. Thanks, Hannes -- 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 v3 1/6] pinctrl: Device tree bindings for Qualcomm pm8xxx gpio block
On Wed, 2014-08-20 at 15:27 -0700, Bjorn Andersson wrote: > On Mon 11 Aug 08:40 PDT 2014, Ivan T. Ivanov wrote: > [...] > > diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt > > b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt > [...] > > +SUBNODES: > [...] > > +- function: > > + Usage: required > > + Value type: > > + Definition: Specify the alternative function to be configured for the > > + specified pins. Valid values are: > > + "normal", > > + "paired", > > + "func1", > > + "func2", > > + "dtest1", > > + "dtest2", > > + "dtest3", > > + "dtest4" > > + > > I still think it looks better with "real" functions, but I rather go with this > than discussing it forever. > > > +- qcom,pull-up-strength: > > + Usage: optional > > + Value type: > > + Definition: Specifies the strength to use for pull up, if selected. > > + Valid values are; as defined in > > + : > > + 1: 30uA (PMIC_GPIO_PULL_UP_30) > > + 2: 1.5uA(PMIC_GPIO_PULL_UP_1P5) > > + 3: 31.5uA (PMIC_GPIO_PULL_UP_31P5) > > + 4: 1.5uA + 30uA boost (PMIC_GPIO_PULL_UP_1P5_30) > > + If this property is ommited 30uA strength will be used if > > + pull up is selected > > I would prefer if we decrement this one step, as it will follow the register > values of both the "ssbi" and "spmi" based pmics. Ok. > > [...] > > + > > +- power-source: > > + Usage: optional > > + Value type: > > + Definition: Selects the power source for the specified pins. Valid > > + power sources are defined per chip in > > + > > + _GPIO_L6, _GPIO_L5... > > After implementing this my only concern is that debugfs output is not as > useful > anymore; saying VIN2 instead of S4. But I can live with this. > > > diff --git a/include/dt-bindings/pinctrl/qcom,pmic-gpio.h > > b/include/dt-bindings/pinctrl/qcom,pmic-gpio.h > [...] > > + > > +#define PM8038_GPIO1_2_LPG_DRV PMIC_GPIO_FUNC_FUNC1 > > +#define PM8038_GPIO3_5V_BOOST_EN PMIC_GPIO_FUNC_FUNC1 > > +#define PM8038_GPIO4_SSBI_ALT_CLK PMIC_GPIO_FUNC_FUNC1 > > +#define PM8038_GPIO5_6_EXT_REG_EN PMIC_GPIO_FUNC_FUNC1 > > +#define PM8038_GPIO10_11_EXT_REG_ENPMIC_GPIO_FUNC_FUNC1 > > +#define PM8038_GPIO6_7_CLK PMIC_GPIO_FUNC_FUNC1 > > +#define PM8038_GPIO9_BAT_ALRM_OUT PMIC_GPIO_FUNC_FUNC1 > > +#define PM8038_GPIO6_12_KYPD_DRV PMIC_GPIO_FUNC_FUNC2 > > + > > +#define PM8058_GPIO7_8_MP3_CLK PMIC_GPIO_FUNC_FUNC1 > > +#define PM8058_GPIO7_8_BCLK_19P2MHZPMIC_GPIO_FUNC_FUNC2 > > +#define PM8058_GPIO9_26_KYPD_DRV PMIC_GPIO_FUNC_FUNC1 > > +#define PM8058_GPIO21_23_UART_TX PMIC_GPIO_FUNC_FUNC2 > > +#define PM8058_GPIO24_26_LPG_DRV PMIC_GPIO_FUNC_FUNC2 > > +#define PM8058_GPIO33_BCLK_19P2MHZ PMIC_GPIO_FUNC_FUNC1 > > +#define PM8058_GPIO34_35_MP3_CLK PMIC_GPIO_FUNC_FUNC1 > > +#define PM8058_GPIO36_BCLK_19P2MHZ PMIC_GPIO_FUNC_FUNC1 > > +#define PM8058_GPIO37_UPL_OUT PMIC_GPIO_FUNC_FUNC1 > > +#define PM8058_GPIO37_UART_M_RXPMIC_GPIO_FUNC_FUNC2 > > +#define PM8058_GPIO38_XO_SLEEP_CLK PMIC_GPIO_FUNC_FUNC1 > > +#define PM8058_GPIO38_39_CLK_32KHZ PMIC_GPIO_FUNC_FUNC2 > > +#define PM8058_GPIO39_MP3_CLK PMIC_GPIO_FUNC_FUNC1 > > +#define PM8058_GPIO40_EXT_BB_ENPMIC_GPIO_FUNC_FUNC1 > > + > > +#define PM8917_GPIO9_18_KEYP_DRV PMIC_GPIO_FUNC_FUNC1 > > +#define PM8917_GPIO20_BAT_ALRM_OUT PMIC_GPIO_FUNC_FUNC1 > > +#define PM8917_GPIO21_23_UART_TX PMIC_GPIO_FUNC_FUNC2 > > +#define PM8917_GPIO25_26_EXT_REG_ENPMIC_GPIO_FUNC_FUNC1 > > +#define PM8917_GPIO37_38_XO_SLEEP_CLK PMIC_GPIO_FUNC_FUNC1 > > +#define PM8917_GPIO37_38_MP3_CLK PMIC_GPIO_FUNC_FUNC2 > > Stephens argument was that we don't want to have huge tables for the functions > and I can see his point, it will be some work to build all the tables. > Adding all this defines is unfortunately doing just that. It is still little bit simpler :-) > > I had a version of my driver that exposed real functions by name from the > driver, following the pattern we have for other pinctrl drivers and making the > dts very easy to read. But if you don't think we should go that route then I > suggest that we just call it func1/func2 and skip these defines. > > Regards, > Bjorn Regards, Ivan -- 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/3] mm/slab: use percpu allocator for cpu cache
On Mon, 25 Aug 2014, Joonsoo Kim wrote: > On Thu, Aug 21, 2014 at 09:21:30AM -0500, Christoph Lameter wrote: > > On Thu, 21 Aug 2014, Joonsoo Kim wrote: > > > > > So, this patch try to use percpu allocator in SLAB. This simplify > > > initialization step in SLAB so that we could maintain SLAB code more > > > easily. > > > > I thought about this a couple of times but the amount of memory used for > > the per cpu arrays can be huge. In contrast to slub which needs just a > > few pointers, slab requires one pointer per object that can be in the > > local cache. CC Tj. > > > > Lets say we have 300 caches and we allow 1000 objects to be cached per > > cpu. That is 300k pointers per cpu. 1.2M on 32 bit. 2.4M per cpu on > > 64bit. > > Amount of memory we need to keep pointers for object is same in any case. What case? SLUB uses a linked list and therefore does not have these storage requirements. > I know that percpu allocator occupy vmalloc space, so maybe we could > exhaust vmalloc space on 32 bit. 64 bit has no problem on it. > How many cores does largest 32 bit system have? Is it possible > to exhaust vmalloc space if we use percpu allocator? There were NUMA systems on x86 a while back (not sure if they still exists) with 128 or so processors. Some people boot 32 bit kernels on contemporary servers. The Intel ones max out at 18 cores (36 hyperthreaded). I think they support up to 8 scokets. So 8 * 36? Its different on other platforms with much higher numbers. Power can easily go up to hundreds of hardware threads and SGI Altixes 7 yearsago where at 8000 or so. -- 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] drivers: staging: rtl8821ae: Fix spaces required around that '?' errors
On Mon, 2014-08-25 at 06:35 -0500, Greg Donald wrote:
> Fix checkpatch.pl spaces required around that '?' errors
It'd be better to convert all parts of the
ternary at the same time.
> diff --git a/drivers/staging/rtl8821ae/btcoexist/HalBtc8812a1Ant.c
> b/drivers/staging/rtl8821ae/btcoexist/HalBtc8812a1Ant.c
[]
> @@ -652,7 +652,7 @@ halbtc8812a1ant_SetFwDecBtPwr(
> u1Byte buf[5] = {0};
>
> BTC_PRINT(BTC_MSG_ALGORITHM, ALGO_TRACE_FW_EXEC, ("[BTCoex], decrease
> Bt Power : %s\n",
> - (dec_bt_pwr? "Yes!!":"No!!")));
> + (dec_bt_pwr ? "Yes!!":"No!!")));
(dec_bt_pwr ? "Yes!!" : "No!!")
>
> buf[0] = dataLen;
> buf[1] = 0x3; // OP_Code
> @@ -674,7 +674,7 @@ halbtc8812a1ant_DecBtPwr(
> {
> return;
> BTC_PRINT(BTC_MSG_ALGORITHM, ALGO_TRACE_FW, ("[BTCoex], %s Dec BT power
> = %s\n",
> - (force_exec? "force to":""), ((dec_bt_pwr)? "ON":"OFF")));
> + (force_exec ? "force to":""), ((dec_bt_pwr) ? "ON":"OFF")));
(force_exec ? "force to" : ""), ((dec_bt_pwr) ? "ON" :
"OFF")));
etc...
A subsequent change might be to remove the unnecessary
parentheses like:
force_exec ? "force to" : "", dec_bt_pwr ? "ON" : "OFF");
--
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 net v2] net: fix checksum features handling in netif_skb_features()
This is follow-up to
da08143b8520 ("vlan: more careful checksum features handling")
which introduced more careful feature intersection in vlan code,
taking into account that HW_CSUM should be considered superset
of IP_CSUM/IPV6_CSUM. The same is needed in netif_skb_features()
in order to avoid offloading mismatch warning when vlan is
created on top of a bond consisting of slaves supporting IP/IPv6
checksumming but not vlan Tx offloading.
Signed-off-by: Michal Kubecek
---
net/core/dev.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index b65a505..a964017 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2587,13 +2587,19 @@ netdev_features_t netif_skb_features(struct sk_buff
*skb)
return harmonize_features(skb, features);
}
- features &= (skb->dev->vlan_features | NETIF_F_HW_VLAN_CTAG_TX |
- NETIF_F_HW_VLAN_STAG_TX);
+ features = netdev_intersect_features(features,
+skb->dev->vlan_features |
+NETIF_F_HW_VLAN_CTAG_TX |
+NETIF_F_HW_VLAN_STAG_TX);
if (protocol == htons(ETH_P_8021Q) || protocol == htons(ETH_P_8021AD))
- features &= NETIF_F_SG | NETIF_F_HIGHDMA | NETIF_F_FRAGLIST |
- NETIF_F_GEN_CSUM | NETIF_F_HW_VLAN_CTAG_TX |
- NETIF_F_HW_VLAN_STAG_TX;
+ features = netdev_intersect_features(features,
+NETIF_F_SG |
+NETIF_F_HIGHDMA |
+NETIF_F_FRAGLIST |
+NETIF_F_GEN_CSUM |
+NETIF_F_HW_VLAN_CTAG_TX |
+NETIF_F_HW_VLAN_STAG_TX);
return harmonize_features(skb, features);
}
--
1.8.4.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/
Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
On 22/08/2014 17:16, Eric Dumazet wrote: > On Fri, 2014-08-22 at 17:08 +0800, Jason Wang wrote: > >> But this is just for current process. We want to determine whether or >> not it was worth to loop busily in current process by checking if >> there's any another runnable processes or callbacks. And what we need >> here is just a simple and lockless hint which can't be wrong but may be >> inaccurate to exit the busy loop. The net code does not depends on this >> hint to do scheduling or yielding. >> >> How about just introducing a boolean helper like current_can_busy_loop() >> and return true in one of the following conditions: >> >> - Current task is SCHED_FIFO >> - Current task is neither SCHED_FIFO nor SCHED_IDLE and no other >> runnable processes or pending RCU callbacks in current cpu >> >> And add warns to make sure it can only be called in process context. > > > 1) Any reasons Eliezer Tamir is not included in the CC list ? Thanks for remembering me, Eric ;) Here are my 2 cents: I think Ingo's suggestion of only yielding to tasks with same or higher priority makes sense. IF you change the current behavior, please update the documentation. You are going to make people scratch their head and ask "what changed?" you owe them a clue. I also would like to have some way to keep track of when/if/how much this yield happens. > 2) It looks like sk_buy_loop() should not be inlined, its is already too > big. You made this comment in the past, my response was that it's inlnied so it can be optimized when nonblock is known at compile time to be true (e.g when called from sock_poll). IFF you think that's less important, then I will defer to your opinion. -Eliezer -- 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: [resend rfc v3] pwm: add BCM2835 PWM driver
Sorry for taking so long to reply to this, I had completely forgotten.
On Mon, Apr 28, 2014 at 02:54:46PM +0200, Bart Tanghe wrote:
> Add some better error handling and Device table support
> Added Documentation/devicetree/bindings/pwm/pwm-bcm2835.txt
>
> Signed-off-by: Bart Tanghe
There should be a description about this driver in the commit message.
The above reads like a changelog since earlier versions of this patch,
in which case it should go below a --- separator line, like so:
Commit message goes here...
...
Signed-off-by: Bart Tanghe
---
Changes in v3:
- add some better error handling
- add device tree support
I assume that "device table" was meant to be "device tree"? Also it
might be useful to mention Raspberry Pi in the commit message.
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-bcm2835.txt
> b/Documentation/devicetree/bindings/pwm/pwm-bcm2835.txt
> new file mode 100644
> index 000..44c0b95
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-bcm2835.txt
> @@ -0,0 +1,13 @@
> +bcm2835 PWM controller
I think this ought to be "BCM2835". Again, maybe this should mention the
Raspberry Pi so that when people search for it they get a match on this
document.
> +Required properties:
> +- compatible: should be "bcrm,pwm-bcm2835"
According to Documentation/devicetree/bindings/vendor-prefixes.txt this
should be "brcm,...". Also I'd suggest putting the SoC first, followed
by the hardware block name:
"brcm,bcm2835-pwm"
> +- reg: physical base address and length of the controller's registers
> +
> +Examples:
> +
> +pwm@0x2020C000 {
> + compatible = "bcrm,pwm-bcm2835";
> + reg = <0x2020C000 0x28>;
I think other BCM2835 device tree bindings use lower-case for addresses,
so you might want to follow that for consistency. Also unit-addresses
are always in hexadecimal and shouldn't take a 0x prefix, so the above
would become:
pwm@2020c000 {
...
};
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 22f2f28..20341a3 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -62,6 +62,18 @@ config PWM_ATMEL_TCB
> To compile this driver as a module, choose M here: the module
> will be called pwm-atmel-tcb.
>
> +config PWM_BCM2835
> + tristate "BCM2835 PWM support"
> + depends on MACH_BCM2835 || MACH_BCM2708
> + help
> + PWM framework driver for BCM2835 controller (raspberry pi)
I think the correct capitalization would be "Raspberry Pi".
> + Only 1 channel is implemented.
How many can it take? Why haven't all been implemented?
> + The pwm core is tested with a pwm basic frequency of 1Mhz.
> + Use period above 1000ns
s/pwm/PWM/ in prose. Why this restriction? Doesn't it work with higher
frequencies? Perhaps this shouldn't be a comment in the Kconfig entry
but rather a runtime check (and error message)?
> diff --git a/drivers/pwm/pwm-bcm2835.c b/drivers/pwm/pwm-bcm2835.c
> new file mode 100644
> index 000..ec9829b
> --- /dev/null
> +++ b/drivers/pwm/pwm-bcm2835.c
> @@ -0,0 +1,198 @@
> +/*
> + * pwm-bcm2835 driver
> + * Standard raspberry pi (gpio18 - pwm0)
Just drop these two lines, they don't provide very useful information.
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/*mmio regiser mapping*/
s/mmio/MMIO/, s/regiser/register/. Also spaces after /* and before */.
> +
> +#define DUTY 0x14
> +#define PERIOD 0x10
> +#define CHANNEL 0x10
CHANNEL doesn't seem to be used.
> +
> +#define PWM_ENABLE 0x0001
> +#define PWM_POLARITY 0x0010
> +
> +#define MASK_CTL_PWM 0x00FF
I prefer lowercase for hexadecimals. And there's no need to repeat all
the leading zeroes. PWM_ENABLE and PWM_POLARITY seem to be bits, so I'd
prefer:
#define PWM_ENABLE (1 << 0)
#define PWM_POLARITY (1 << 4)
> +#define CTL_PWM 0x0081
What does this value mean? Also even if this register is at offset 0 you
should still add a symbolic name for it.
> +#define DRIVER_AUTHOR "Bart Tanghe "
> +#define DRIVER_DESC "A bcm2835 pwm driver - raspberry pi development
> platform"
These are only used once, so you don't have to #define them. Use them in
the MODULE_*() macros directly.
Also, perhaps a better and more generic description would be:
"Broadcom BCM2835 (Raspberry Pi) PWM driver"
And perhaps even drop "(Raspberry Pi)" since presumably the driver will
work on any BCM2835-based board.
> +struct bcm2835_pwm_chip {
> + struct pwm_chip chip;
> + struct device *dev;
> + int channel;
This field seems to be unused.
> + int scaler;
Perhaps this should be unsigned long instead of int?
> + void __iomem *mmio_base;
Calling this something like "base" or "regs" will save a lot of
characters when accessing registers.
> +static inline struct
PURCHASE ORDER
I am interested in this your product. I will like to know how i will go about it and to also know the specification,FOB price and mode of payment. Vanni -- 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 6/9 v2] drm: use c99 initializers in structures
On Sat, Aug 23, 2014 at 06:09:56PM +0200, Julia Lawall wrote:
> From: Julia Lawall
>
> Use c99 initializers for structures.
>
> Drop 0 initializers in drivers/gpu/drm/sti/sti_vtac.c. A 0x0 initializer
> is left in vtac_mode_aux in drivers/gpu/drm/sti/sti_vtac.c to highlight the
> relation to vtac_mode_main.
>
> A simplified version of the semantic match that finds the first problem is
> as follows: (http://coccinelle.lip6.fr/)
>
> //
> @decl@
> identifier i1,fld;
> type T;
> field list[n] fs;
> @@
>
> struct i1 {
> fs
> T fld;
> ...};
>
> @bad@
> identifier decl.i1,i2;
> expression e;
> initializer list[decl.n] is;
> @@
>
> struct i1 i2 = { is,
> + .fld = e
> - e
> ,...};
> //
>
> Signed-off-by: Julia Lawall
>
> ---
> The patches in this series do not depend on each other.
>
> v2: Drop 0 initializers and add trailing commas at the suggestions of Josh
> Triplett.
Slurped into my drm topic branch for 3.18 to make sure it doesn't get lost.
-Daniel
>
> drivers/gpu/drm/drm_edid.c | 21 -
> drivers/gpu/drm/sti/sti_vtac.c | 12 ++--
> 2 files changed, 22 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_vtac.c b/drivers/gpu/drm/sti/sti_vtac.c
> index 82a51d4..4576536 100644
> --- a/drivers/gpu/drm/sti/sti_vtac.c
> +++ b/drivers/gpu/drm/sti/sti_vtac.c
> @@ -56,8 +56,16 @@ struct sti_vtac_mode {
> u32 phyts_per_pixel;
> };
>
> -static const struct sti_vtac_mode vtac_mode_main = {0x2, 0x2, VTAC_5_PPP};
> -static const struct sti_vtac_mode vtac_mode_aux = {0x1, 0x0, VTAC_17_PPP};
> +static const struct sti_vtac_mode vtac_mode_main = {
> + .vid_in_width = 0x2,
> + .phyts_width = 0x2,
> + .phyts_per_pixel = VTAC_5_PPP,
> +};
> +static const struct sti_vtac_mode vtac_mode_aux = {
> + .vid_in_width = 0x1,
> + .phyts_width = 0x0,
> + .phyts_per_pixel = VTAC_17_PPP,
> +};
>
> /**
> * VTAC structure
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 1dbf3bc..859ae1c 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2103,7 +2103,8 @@ static int
> add_inferred_modes(struct drm_connector *connector, struct edid *edid)
> {
> struct detailed_mode_closure closure = {
> - connector, edid, 0, 0, 0
> + .connector = connector,
> + .edid = edid,
> };
>
> if (version_greater(edid, 1, 0))
> @@ -2169,7 +2170,8 @@ add_established_modes(struct drm_connector *connector,
> struct edid *edid)
> ((edid->established_timings.mfg_rsvd & 0x80) << 9);
> int i, modes = 0;
> struct detailed_mode_closure closure = {
> - connector, edid, 0, 0, 0
> + .connector = connector,
> + .edid = edid,
> };
>
> for (i = 0; i <= EDID_EST_TIMINGS; i++) {
> @@ -2227,7 +2229,8 @@ add_standard_modes(struct drm_connector *connector,
> struct edid *edid)
> {
> int i, modes = 0;
> struct detailed_mode_closure closure = {
> - connector, edid, 0, 0, 0
> + .connector = connector,
> + .edid = edid,
> };
>
> for (i = 0; i < EDID_STD_TIMINGS; i++) {
> @@ -2313,7 +2316,8 @@ static int
> add_cvt_modes(struct drm_connector *connector, struct edid *edid)
> {
> struct detailed_mode_closure closure = {
> - connector, edid, 0, 0, 0
> + .connector = connector,
> + .edid = edid,
> };
>
> if (version_greater(edid, 1, 2))
> @@ -2357,11 +2361,10 @@ add_detailed_modes(struct drm_connector *connector,
> struct edid *edid,
> u32 quirks)
> {
> struct detailed_mode_closure closure = {
> - connector,
> - edid,
> - 1,
> - quirks,
> - 0
> + .connector = connector,
> + .edid = edid,
> + .preferred = 1,
> + .quirks = quirks,
> };
>
> if (closure.preferred && !version_greater(edid, 1, 3))
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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: Linux UDF support
Hi, On Monday 25 August 2014 14:45:13 Austin S Hemmelgarn wrote: > On 2014-08-24 08:46, Pali Rohár wrote: > > Hi, > > > > I would like to know what is state of linux UDF driver. It > > is experimental or is now suitable for storing data? > > I know that read support works for every version I have > tested, but I've only tested it reading data from DVD's and > Blu-Ray discs, so I don't know how well it works for other > purposes. > Ok. I'm thinking about using UDF on HDD and usb flash disks (not on optical medium). And here I need write support too. > > According to wikipedia [1] UDF has open specification format > > and can be used also for HDDs (not only optical discs). > > > > In OS support table is written that all major and other > > minor OSs support UDF FS (without needs for additional > > programs). > > > > So it looks like UDF is good candidate for multi OS > > filesystem. Are there any disadvantages for using UDF on > > e.g USB flash disk? (when I want read/write support on > > Linux, Windows 7 and Mac OS X) > > If you are going to go that way, make sure to use the Spared > Build, as otherwise you will run in to the same media > wear-out issues that NTFS and FAT have. Also, keep in mind > that pre-Vista Windows and pre-10.4 OSX don't have very good > support for the newer formats. > What is Spared Build? And how to use it? Problem with NTFS is that linux driver has write support marked as experimental. FAT has problems with big files and for exFAT there is no driver in linux kernel yet... > > Because lot of manuals say that FAT32 (or NTFS) is only one > > solution for using USB flash disk on more OS. > > > > On wikipedia there is one note about linux: Write support is > > only up to UDF version 2.01. Is this restriction still > > valid? > > I do know that we support reading UDF 2.60 (I've used linux to > read Blu-Ray discs), but I have no idea about write support > for versions above 2.01. > > > What will happen if I try to mount FS with UDF version 2.60 > > in R/W mode on linux? It will fallback to R/O mode? Or > > newly written files will be in previous (2.01) versions? > > > > And last question: Is there some fsck tool for UDF? Or at > > least tool which print if FS is in inconsistent state? > > Most Linux distributions have a package called udftools, the > upstream URL given by portage is > http://sf.net/projects/linux-udf/ > That project does not have udf fsck tool :-( > > [1] - http://en.wikipedia.org/wiki/Universal_Disk_Format Ok, I will wait for response from maintainer Jan, he probably would know more... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
