RE: [PATCH 2/3] MIPS: Setup an instruction emulation in VDSO protected page instead of user stack
From: Peter Zijlstra [pet...@infradead.org]: >On Fri, Oct 03, 2014 at 08:17:30PM -0700, Leonid Yegoshin wrote: >> --- a/arch/mips/include/asm/switch_to.h > >+++ b/arch/mips/include/asm/switch_to.h >Why raw_smp_processor_id() and why evaluate it 3 times, sure compilers >can be expected to do some CSE but something like: > >int cpu = smp_processor_id(); > >if ( ... [cpu] ...) > >is far more readable as well. Sure. But may be it has sense to use raw_smp_processor_id() due to elevated preemption counter. >> + flush_vdso_page(); \ >So what I didn't see is any talk about the cost of this. Surely a TLB >flush isn't exactly free. Well, flush_vdso_page() uses a local version of TLB page flushing and it is cheap 'per se' in comparison with system-wide. And I take precautions to flush only if it matches the same memory map, so it is the situation then one pthread on some map is replaced by some pthread on the same map on the same CPU. So, it flushes only after real use in previous pthread of that map. However, some performance loss can be expected due to killing TLB. In low-end cores, with small TLB array we can expect that this TLB can be kicked off anyway after context switch. In high end cores we should expect FPU unit available and float point emulation can be very rare (un-normalized operations or so). The only question is a middle line which has enough TLB (32 or more) but may have no float point processor. However, the emulation itself is very slow and it is natural to expect performance degradation because of float point emulation here in much higher degree than possible penalty due to early loss of TLB element. -- 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: Perf lockups / stack overflows on v3.17-rc6, x86_64, arm, arm64
On Thu, 25 Sep 2014, Mark Rutland wrote: > Log 1, x86_64 lockup > [ 223.007005] [] ? poll_select_copy_remaining+0x130/0x130 > [ 223.007005] [] ? getname_flags+0x4a/0x1a0 > [ 223.007005] [] ? final_putname+0x1d/0x40 > [ 223.007005] [] ? putname+0x24/0x40 > [ 223.007005] [] ? user_path_at_empty+0x5a/0x90 > [ 223.007005] [] ? wake_up_state+0x10/0x10 > [ 223.007005] [] ? eventfd_read+0x38/0x60 > [ 223.007005] [] ? ktime_get_ts64+0x45/0xf0 > [ 223.007005] [] SyS_poll+0x60/0xf0 I have seen issues similar to this before, where the problem appeared to be in poll/hrtimer. Never managed to track down anything useful about the bug. > Log 2, x86_64 stack overflow > [ 346.641345] divide error: [#1] SMP > [ 346.642010] Modules linked in: > [ 346.642010] CPU: 0 PID: 4076 Comm: perf_fuzzer Not tainted > 3.17.0-rc6hark-perf-lockup+ #1 > [ 346.642010] Hardware name: LENOVO 7484A3G/LENOVO, BIOS 5CKT54AUS 09/07/2009 > [ 346.642010] task: 8801ac449a70 ti: 8801ac574000 task.ti: > 8801ac574000 > [ 346.642010] RIP: 0010:[] [] > find_busiest_group+0x28e/0x8a0 > [ 346.642010] RSP: 0018:8801ac577760 EFLAGS: 00010006 > [ 346.642010] RAX: 03ff RBX: RCX: > 8801 > [ 346.642010] RDX: RSI: 0001 RDI: > 0001 > [ 346.642010] RBP: 8801ac577890 R08: R09: > > [ 346.704010] [ cut here ] > [ 346.704017] WARNING: CPU: 2 PID: 5 at arch/x86/kernel/irq_64.c:70 > handle_irq+0x141/0x150() > [ 346.704019] do_IRQ(): has overflown the kernel stack > (cur:1,sp:8801b653fe88,irq stk > top-bottom:8801bed00080-8801bed03fc0,exception stk > top-bottom:8801bed04080-8801bed0a000) weird, have not seen this before. Though I was hitting a reboot issue that would give really strange crash messages that was possibly fixed by a patch that went into 3.17-rc7. > Log 3, arm64 lockup > >8 > Seeding random number generator with 1411488270 > /proc/sys/kernel/perf_event_max_sample_rate currently: 285518974/s > /proc/sys/kernel/perf_event_paranoid currently: 1142898651 Those last two lines are suspect. Is my fuzzer broken on arm64 somehow? I do try to test on arm occasionally, but my pandaboard suffered massive SD card failure and I haven't had a chance to get it back running yet. I have trouble getting any of my other flock of arm machines running recent upstream kernels. Sorry that I don't have good answers for these bugs, but I will stick them in my perf_fuzzer outstanding bugs list. Vince -- 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] workqueue: add quiescent state between work items
Similar to the stop_machine deadlock scenario on !PREEMPT kernels addressed in b22ce2785d97 "workqueue: cond_resched() after processing each work item", kworker threads requeueing back-to-back with zero jiffy delay can stall RCU. The cond_resched call introduced in that fix will yield only iff there are other higher priority tasks to run, so force a quiescent RCU state between work items with cond_resched_rcu_qs. Signed-off-by: Joe Lawrence Link: https://lkml.kernel.org/r/20140926105227.01325...@jlaw-desktop.mno.stratus.com Link: https://lkml.kernel.org/r/20140929115445.40221...@jlaw-desktop.mno.stratus.com --- kernel/workqueue.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 5dbe22a..09b685d 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -2043,9 +2043,10 @@ __acquires(>lock) * kernels, where a requeueing work item waiting for something to * happen could deadlock with stop_machine as such work item could * indefinitely requeue itself while all other CPUs are trapped in -* stop_machine. +* stop_machine. At the same time, report a quiescent RCU state so +* the same condition doesn't freeze RCU. */ - cond_resched(); + cond_resched_rcu_qs(); spin_lock_irq(>lock); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] SCSI fixes for 3.17-rc7
This is a set of two small fixes, both to code which went in during the
merge window: cxgb4i has a scheduling in atomic bug in its new ipv6 code
and uas fails to work properly with the new scsi-mq code.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Anish Bhatt (1):
cxgb4i: avoid holding mutex in interrupt context
Christoph Hellwig (1):
uas: disable use of blk-mq I/O path
And the diffstat
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 2 +-
drivers/scsi/cxgbi/libcxgbi.c | 57 ++
drivers/scsi/cxgbi/libcxgbi.h | 3 ++
drivers/usb/storage/uas.c | 7 +
4 files changed, 62 insertions(+), 7 deletions(-)
With full diff below.
James
---
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 79788a1..02e69e7 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -1647,7 +1647,7 @@ static int cxgbi_inet6addr_handler(struct notifier_block
*this,
if (event_dev->priv_flags & IFF_802_1Q_VLAN)
event_dev = vlan_dev_real_dev(event_dev);
- cdev = cxgbi_device_find_by_netdev(event_dev, NULL);
+ cdev = cxgbi_device_find_by_netdev_rcu(event_dev, NULL);
if (!cdev)
return ret;
diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
index d65df6d..addd1dd 100644
--- a/drivers/scsi/cxgbi/libcxgbi.c
+++ b/drivers/scsi/cxgbi/libcxgbi.c
@@ -57,6 +57,9 @@ MODULE_PARM_DESC(dbg_level, "libiscsi debug level
(default=0)");
static LIST_HEAD(cdev_list);
static DEFINE_MUTEX(cdev_mutex);
+static LIST_HEAD(cdev_rcu_list);
+static DEFINE_SPINLOCK(cdev_rcu_lock);
+
int cxgbi_device_portmap_create(struct cxgbi_device *cdev, unsigned int base,
unsigned int max_conn)
{
@@ -142,6 +145,10 @@ struct cxgbi_device *cxgbi_device_register(unsigned int
extra,
list_add_tail(>list_head, _list);
mutex_unlock(_mutex);
+ spin_lock(_rcu_lock);
+ list_add_tail_rcu(>rcu_node, _rcu_list);
+ spin_unlock(_rcu_lock);
+
log_debug(1 << CXGBI_DBG_DEV,
"cdev 0x%p, p# %u.\n", cdev, nports);
return cdev;
@@ -153,9 +160,16 @@ void cxgbi_device_unregister(struct cxgbi_device *cdev)
log_debug(1 << CXGBI_DBG_DEV,
"cdev 0x%p, p# %u,%s.\n",
cdev, cdev->nports, cdev->nports ? cdev->ports[0]->name : "");
+
mutex_lock(_mutex);
list_del(>list_head);
mutex_unlock(_mutex);
+
+ spin_lock(_rcu_lock);
+ list_del_rcu(>rcu_node);
+ spin_unlock(_rcu_lock);
+ synchronize_rcu();
+
cxgbi_device_destroy(cdev);
}
EXPORT_SYMBOL_GPL(cxgbi_device_unregister);
@@ -167,12 +181,9 @@ void cxgbi_device_unregister_all(unsigned int flag)
mutex_lock(_mutex);
list_for_each_entry_safe(cdev, tmp, _list, list_head) {
if ((cdev->flags & flag) == flag) {
- log_debug(1 << CXGBI_DBG_DEV,
- "cdev 0x%p, p# %u,%s.\n",
- cdev, cdev->nports, cdev->nports ?
-cdev->ports[0]->name : "");
- list_del(>list_head);
- cxgbi_device_destroy(cdev);
+ mutex_unlock(_mutex);
+ cxgbi_device_unregister(cdev);
+ mutex_lock(_mutex);
}
}
mutex_unlock(_mutex);
@@ -191,6 +202,7 @@ struct cxgbi_device *cxgbi_device_find_by_lldev(void *lldev)
}
}
mutex_unlock(_mutex);
+
log_debug(1 << CXGBI_DBG_DEV,
"lldev 0x%p, NO match found.\n", lldev);
return NULL;
@@ -230,6 +242,39 @@ struct cxgbi_device *cxgbi_device_find_by_netdev(struct
net_device *ndev,
}
EXPORT_SYMBOL_GPL(cxgbi_device_find_by_netdev);
+struct cxgbi_device *cxgbi_device_find_by_netdev_rcu(struct net_device *ndev,
+int *port)
+{
+ struct net_device *vdev = NULL;
+ struct cxgbi_device *cdev;
+ int i;
+
+ if (ndev->priv_flags & IFF_802_1Q_VLAN) {
+ vdev = ndev;
+ ndev = vlan_dev_real_dev(ndev);
+ pr_info("vlan dev %s -> %s.\n", vdev->name, ndev->name);
+ }
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(cdev, _rcu_list, rcu_node) {
+ for (i = 0; i < cdev->nports; i++) {
+ if (ndev == cdev->ports[i]) {
+ cdev->hbas[i]->vdev = vdev;
+ rcu_read_unlock();
+ if (port)
+ *port = i;
+ return cdev;
+ }
+ }
+ }
+ rcu_read_unlock();
+
+ log_debug(1 <<
Re: [PATCH] fs: use kfree_rcu instead of i_callback
On Sat, Oct 04, 2014 at 11:00:42PM -0400, John de la Garza wrote: > Since the callback is doing nothing more than calling kfree() we can > use kfree_rcu() instead of having to use a callback. Except that this > - kmem_cache_free(inode_cachep, inode); isn't kfree()... -- 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] fs: use kfree_rcu instead of i_callback
Since the callback is doing nothing more than calling kfree() we can
use kfree_rcu() instead of having to use a callback.
Signed-off-by: John de la Garza
---
fs/inode.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/fs/inode.c b/fs/inode.c
index 26753ba..51deccd 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -250,12 +250,6 @@ void __destroy_inode(struct inode *inode)
}
EXPORT_SYMBOL(__destroy_inode);
-static void i_callback(struct rcu_head *head)
-{
- struct inode *inode = container_of(head, struct inode, i_rcu);
- kmem_cache_free(inode_cachep, inode);
-}
-
static void destroy_inode(struct inode *inode)
{
BUG_ON(!list_empty(>i_lru));
@@ -263,7 +257,7 @@ static void destroy_inode(struct inode *inode)
if (inode->i_sb->s_op->destroy_inode)
inode->i_sb->s_op->destroy_inode(inode);
else
- call_rcu(>i_rcu, i_callback);
+ kfree(inode, i_rcu);
}
/**
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers: base: power: domain: Use 'pm_cpu_data' instead of 'cpu_data' for compiling break
On 10/5/14 10:42, Randy Dunlap wrote:
> On 10/04/14 09:00, Greg KH wrote:
>> On Sat, Oct 04, 2014 at 10:19:50PM +0800, Chen Gang wrote:
>>> 'cpu_data' is too common to be already used by some architectures (e.g.
>>> um, m32r, and mn10300), so need use 'pm_cpu_data' instead of, or cause
>>> compiling break. The related error (with allmodconfig under um):
>>>
>>> CC drivers/base/platform.o
>>> In file included from ./arch/x86/um/asm/processor.h:31:0,
>>>from ./arch/um/include/asm/uaccess.h:16,
>>>from ./arch/um/include/asm/thread_info.h:13,
>>>from include/linux/thread_info.h:54,
>>>from include/asm-generic/current.h:4,
>>>from arch/um/include/generated/asm/current.h:1,
>>>from include/linux/mutex.h:13,
>>>from include/linux/kernfs.h:13,
>>>from include/linux/sysfs.h:15,
>>>from include/linux/kobject.h:21,
>>>from include/linux/device.h:17,
>>>from include/linux/platform_device.h:14,
>>>from drivers/base/platform.c:14:
>>> ./arch/um/include/asm/processor-generic.h:107:19: error: expected
>>> identifier or '(' before '&' token
>>>#define cpu_data (_cpu_data)
>>> ^
>>> include/linux/pm_domain.h:74:23: note: in expansion of macro 'cpu_data'
>>> struct gpd_cpu_data *cpu_data;
>>>^
>>>
>>> Also need notice about 80 columns boundary.
>>
>> I don't object to this change at all, but it could be easier to solve
>> this by fixing up 'cpu_data' to be named something a bit less "generic"?
>> What does x86 use for this data type?
>
> The patch makes sense to me.
>
> These arch-es already have 'cpu_data' in some form:
>
> mips, sparc, arm64, blackfin, frv, mn10300, parisc, um(l), c6x, x86, xtensa,
> alpha, m32r, arm, ia64, metag, sn.
>
Yeah, and m32r, mn10300 and um may let cpu_data as macro variable, which
may cause this issue. And others let cpu_data as function (or like a
function), I guess, they may not cause this issue.
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 for-3.17] mm, thp: fix collapsing of hugepages on madvise
If an anonymous mapping is not allowed to fault thp memory and then
madvise(MADV_HUGEPAGE) is used after fault, khugepaged will never
collapse this memory into thp memory.
This occurs because the madvise(2) handler for thp, hugepage_advise(),
clears VM_NOHUGEPAGE on the stack and it isn't stored in vma->vm_flags
until the final action of madvise_behavior(). This causes the
khugepaged_enter_vma_merge() to be a no-op in hugepage_advise() when the
vma had previously had VM_NOHUGEPAGE set.
Fix this by passing the correct vma flags to the khugepaged mm slot
handler. There's no chance khugepaged can run on this vma until after
madvise_behavior() returns since we hold mm->mmap_sem.
It would be possible to clear VM_NOHUGEPAGE directly from vma->vm_flags
in hugepage_advise(), but I didn't want to introduce special case
behavior into madvise_behavior(). I think it's best to just let it
always set vma->vm_flags itself.
Cc:
Reported-by: Suleiman Souhlal
Signed-off-by: David Rientjes
---
include/linux/khugepaged.h | 17 ++---
mm/huge_memory.c | 11 ++-
mm/mmap.c | 8
3 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/include/linux/khugepaged.h b/include/linux/khugepaged.h
--- a/include/linux/khugepaged.h
+++ b/include/linux/khugepaged.h
@@ -6,7 +6,8 @@
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
extern int __khugepaged_enter(struct mm_struct *mm);
extern void __khugepaged_exit(struct mm_struct *mm);
-extern int khugepaged_enter_vma_merge(struct vm_area_struct *vma);
+extern int khugepaged_enter_vma_merge(struct vm_area_struct *vma,
+ unsigned long vm_flags);
#define khugepaged_enabled() \
(transparent_hugepage_flags & \
@@ -35,13 +36,13 @@ static inline void khugepaged_exit(struct mm_struct *mm)
__khugepaged_exit(mm);
}
-static inline int khugepaged_enter(struct vm_area_struct *vma)
+static inline int khugepaged_enter(struct vm_area_struct *vma,
+ unsigned long vm_flags)
{
if (!test_bit(MMF_VM_HUGEPAGE, >vm_mm->flags))
if ((khugepaged_always() ||
-(khugepaged_req_madv() &&
- vma->vm_flags & VM_HUGEPAGE)) &&
- !(vma->vm_flags & VM_NOHUGEPAGE))
+(khugepaged_req_madv() && (vm_flags & VM_HUGEPAGE))) &&
+ !(vm_flags & VM_NOHUGEPAGE))
if (__khugepaged_enter(vma->vm_mm))
return -ENOMEM;
return 0;
@@ -54,11 +55,13 @@ static inline int khugepaged_fork(struct mm_struct *mm,
struct mm_struct *oldmm)
static inline void khugepaged_exit(struct mm_struct *mm)
{
}
-static inline int khugepaged_enter(struct vm_area_struct *vma)
+static inline int khugepaged_enter(struct vm_area_struct *vma,
+ unsigned long vm_flags)
{
return 0;
}
-static inline int khugepaged_enter_vma_merge(struct vm_area_struct *vma)
+static inline int khugepaged_enter_vma_merge(struct vm_area_struct *vma,
+unsigned long vm_flags)
{
return 0;
}
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -803,7 +803,7 @@ int do_huge_pmd_anonymous_page(struct mm_struct *mm, struct
vm_area_struct *vma,
return VM_FAULT_FALLBACK;
if (unlikely(anon_vma_prepare(vma)))
return VM_FAULT_OOM;
- if (unlikely(khugepaged_enter(vma)))
+ if (unlikely(khugepaged_enter(vma, vma->vm_flags)))
return VM_FAULT_OOM;
if (!(flags & FAULT_FLAG_WRITE) &&
transparent_hugepage_use_zero_page()) {
@@ -1970,7 +1970,7 @@ int hugepage_madvise(struct vm_area_struct *vma,
* register it here without waiting a page fault that
* may not happen any time soon.
*/
- if (unlikely(khugepaged_enter_vma_merge(vma)))
+ if (unlikely(khugepaged_enter_vma_merge(vma, *vm_flags)))
return -ENOMEM;
break;
case MADV_NOHUGEPAGE:
@@ -2071,7 +2071,8 @@ int __khugepaged_enter(struct mm_struct *mm)
return 0;
}
-int khugepaged_enter_vma_merge(struct vm_area_struct *vma)
+int khugepaged_enter_vma_merge(struct vm_area_struct *vma,
+ unsigned long vm_flags)
{
unsigned long hstart, hend;
if (!vma->anon_vma)
@@ -2083,11 +2084,11 @@ int khugepaged_enter_vma_merge(struct vm_area_struct
*vma)
if (vma->vm_ops)
/* khugepaged not yet working on file or special mappings */
return 0;
- VM_BUG_ON(vma->vm_flags & VM_NO_THP);
+ VM_BUG_ON(vm_flags & VM_NO_THP);
hstart = (vma->vm_start + ~HPAGE_PMD_MASK) & HPAGE_PMD_MASK;
hend =
Re: [PATCH] drivers: base: power: domain: Use 'pm_cpu_data' instead of 'cpu_data' for compiling break
On 10/04/14 09:00, Greg KH wrote:
> On Sat, Oct 04, 2014 at 10:19:50PM +0800, Chen Gang wrote:
>> 'cpu_data' is too common to be already used by some architectures (e.g.
>> um, m32r, and mn10300), so need use 'pm_cpu_data' instead of, or cause
>> compiling break. The related error (with allmodconfig under um):
>>
>> CC drivers/base/platform.o
>> In file included from ./arch/x86/um/asm/processor.h:31:0,
>>from ./arch/um/include/asm/uaccess.h:16,
>>from ./arch/um/include/asm/thread_info.h:13,
>>from include/linux/thread_info.h:54,
>>from include/asm-generic/current.h:4,
>>from arch/um/include/generated/asm/current.h:1,
>>from include/linux/mutex.h:13,
>>from include/linux/kernfs.h:13,
>>from include/linux/sysfs.h:15,
>>from include/linux/kobject.h:21,
>>from include/linux/device.h:17,
>>from include/linux/platform_device.h:14,
>>from drivers/base/platform.c:14:
>> ./arch/um/include/asm/processor-generic.h:107:19: error: expected
>> identifier or '(' before '&' token
>>#define cpu_data (_cpu_data)
>> ^
>> include/linux/pm_domain.h:74:23: note: in expansion of macro 'cpu_data'
>> struct gpd_cpu_data *cpu_data;
>>^
>>
>> Also need notice about 80 columns boundary.
>
> I don't object to this change at all, but it could be easier to solve
> this by fixing up 'cpu_data' to be named something a bit less "generic"?
> What does x86 use for this data type?
The patch makes sense to me.
These arch-es already have 'cpu_data' in some form:
mips, sparc, arm64, blackfin, frv, mn10300, parisc, um(l), c6x, x86, xtensa,
alpha, m32r, arm, ia64, metag, sn.
--
~Randy
--
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 RESEND v3 5/6] AHCI: Optimize single IRQ interrupt processing
Hey, Alexander. On Wed, Oct 01, 2014 at 04:31:15PM +0100, Alexander Gordeev wrote: > As of your concern wrt threaded handler invocation overhead - I am > not quite sure here, but if SCHED_FIFO policy (the handler runs with) > makes the difference? Anyway, as said above the overall IO does not > suffer. Hmmm so, AFAICS, there's no real pros or cons of going either way, right? The only thing which could be different is possibly slightly lower latency in servicing other IRQs or RT tasks on the same CPU but given that the ahci IRQ handler already doesn't do anything which takes time, I'm doubtful whether that'd be anything measureable. I just don't get why ahci bothers with threaded irq, MMSI or not. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RCU stalls -> lockup.
On Thu, Oct 02, 2014 at 12:36:55PM -0700, Paul E. McKenney wrote: > On Thu, Oct 02, 2014 at 01:55:15PM -0400, Dave Jones wrote: > > I just hit this on my box running 3.17rc7 > > It was followed by a userspace lockup. (Could still ping, and sysrq > > from the console, but even getty wasn't responding on the console). > > > > I was trying to reproduce another bug faster, and had ramped up the > > number of processes trinity to uses to 512. This didn't take long > > to fall out.. > > This might be related to an exchange I had with Tejun (CCed), where > the work queues were running all out, preventing any quiescent states > from happening. One fix under consideration is to add a quiescent state, > similar to the one in softirq handling. Dave, can you please test whether the following patch makes a difference if the problem is reproducible? http://lkml.kernel.org/r/20141003153701.7c7da...@jlaw-desktop.mno.stratus.com Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] mtd: nand: gpmi: add proper raw access support
On Tue, Sep 30, 2014 at 10:07:20AM +0200, Boris Brezillon wrote: > Hi, > > On Tue, 23 Sep 2014 16:07:33 +0200 > Boris BREZILLON wrote: > > > Hello Huang, Brian, > > > > This is just a new proposal to support raw accesses in a more standard way > > in the GPMI driver. > > This series has been tested on an imx28 board. > > > > Any suggestions are welcome. > > Brian, any chance you could take a look at this series and give your > opinion and/or suggest a new approach ? > > Huang, did you have time to think about a better way to implement these > raw access functions ? > sorry for the later reply. I was busy recently. You can send out the new version. Please do not forget add a patch to add more comments for these hooks. I will test your patch(or your new patch set) on Oct 7 and Oct 8. thanks Huang Shijie -- 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: Re: (ltc-kernel 10162) Re: [PATCH ftrace/for-next v6] ftracetest: Add POSIX.3 standard and XFAIL result codes
(2014/10/04 5:53), Steven Rostedt wrote: > On Fri, 03 Oct 2014 20:29:12 +0900 > Masami Hiramatsu wrote: > >> Ping? :) > > Just to make sure. This is just the one patch that I missed before, > right? Yes, this one is the last patch in previous series. > > I pulled it and now testing it (running the tests). I'll push it to my > linux-next branch sometime later today. You'll probably see it as you > wake up ;-) Thanks!! > > -- Steve > >> >> (2014/09/29 21:11), Masami Hiramatsu wrote: >>> Steven, could you pick this instead of old v5 patch? >>> >>> As you pointed, this version shows the log of "unsuppoted" test result. >>> >>> Thank you, >>> >>> (2014/09/29 21:02), Masami Hiramatsu wrote: Add XFAIL and POSIX 1003.3 standard codes (UNRESOLVED/ UNTESTED/UNSUPPORTED) as result codes. These are used for the results that test case is expected to fail or unsupported feature (by config). To return these result code, this introduces exit_unresolved, exit_untested, exit_unsupported and exit_xfail functions, which use real-time signals to notify the result code to ftracetest. This also set "errexit" option for the testcases, so that the tests don't need to exit explicitly. Note that if the test returns UNRESOLVED/UNSUPPORTED/FAIL, its test log including executed commands is shown on console and main logfile as below. > -- > 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/ > -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.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] drivers: base: power: domain: Use 'pm_cpu_data' instead of 'cpu_data' for compiling break
On 10/5/14 9:23, Greg KH wrote:
> On Sun, Oct 05, 2014 at 09:13:09AM +0800, Chen Gang wrote:
>> On 10/5/14 0:00, Greg KH wrote:
>>> On Sat, Oct 04, 2014 at 10:19:50PM +0800, Chen Gang wrote:
'cpu_data' is too common to be already used by some architectures (e.g.
um, m32r, and mn10300), so need use 'pm_cpu_data' instead of, or cause
compiling break. The related error (with allmodconfig under um):
CC drivers/base/platform.o
In file included from ./arch/x86/um/asm/processor.h:31:0,
from ./arch/um/include/asm/uaccess.h:16,
from ./arch/um/include/asm/thread_info.h:13,
from include/linux/thread_info.h:54,
from include/asm-generic/current.h:4,
from arch/um/include/generated/asm/current.h:1,
from include/linux/mutex.h:13,
from include/linux/kernfs.h:13,
from include/linux/sysfs.h:15,
from include/linux/kobject.h:21,
from include/linux/device.h:17,
from include/linux/platform_device.h:14,
from drivers/base/platform.c:14:
./arch/um/include/asm/processor-generic.h:107:19: error: expected
identifier or '(' before '&' token
#define cpu_data (_cpu_data)
^
include/linux/pm_domain.h:74:23: note: in expansion of macro 'cpu_data'
struct gpd_cpu_data *cpu_data;
^
Also need notice about 80 columns boundary.
>>>
>>> I don't object to this change at all, but it could be easier to solve
>>> this by fixing up 'cpu_data' to be named something a bit less "generic"?
>>> What does x86 use for this data type?
>>>
>>
>> It is for some kinds of arm cpu (I let this patch pass arm s3c600
>> def_config building). Other architectures did not use it, at present.
>
> So why not change the name for these archs that have such a generic name
> to something not so generic?
>
All the code are really generic, I don't know whether it will be used
under other architectures in the future (I guess, it will, or it need
not be put to "drivers/base/power/" and "include/linux").
At present, it is not used by other architectures, but it already has
negative effect with other architectures (I found it during compiling
um architecture).
So for me, this issue is not only within arm itself, but also in common
drivers.
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/
Re: [PATCH v2] watchdog: Let XILINX_WATCHDOG and TEGRA_WATCHDOG depend on HAS_IOMEM
On 10/04/2014 06:28 PM, Chen Gang wrote: They need HAS_IOMEM, so let them depend on it, the related error (with allmodconfig under um): MODPOST 1205 modules ERROR: "devm_ioremap_resource" [drivers/watchdog/tegra_wdt.ko] undefined! ERROR: "devm_ioremap_resource" [drivers/watchdog/of_xilinx_wdt.ko] undefined! Signed-off-by: Chen Gang Reviewed-by: Guenter Roeck --- drivers/watchdog/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index a51ccf3..d0ddf90 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -132,6 +132,7 @@ config WM8350_WATCHDOG config XILINX_WATCHDOG tristate "Xilinx Watchdog timer" + depends on HAS_IOMEM select WATCHDOG_CORE help Watchdog driver for the xps_timebase_wdt ip core. @@ -472,7 +473,7 @@ config SIRFSOC_WATCHDOG config TEGRA_WATCHDOG tristate "Tegra watchdog" - depends on ARCH_TEGRA || COMPILE_TEST + depends on (ARCH_TEGRA || COMPILE_TEST) && HAS_IOMEM select WATCHDOG_CORE help Say Y here to include support for the watchdog timer -- 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: base: power: domain: Use 'pm_cpu_data' instead of 'cpu_data' for compiling break
On 10/5/14 9:13, Chen Gang wrote:
> On 10/5/14 0:00, Greg KH wrote:
>> On Sat, Oct 04, 2014 at 10:19:50PM +0800, Chen Gang wrote:
>>> 'cpu_data' is too common to be already used by some architectures (e.g.
>>> um, m32r, and mn10300), so need use 'pm_cpu_data' instead of, or cause
>>> compiling break. The related error (with allmodconfig under um):
>>>
>>> CC drivers/base/platform.o
>>> In file included from ./arch/x86/um/asm/processor.h:31:0,
>>>from ./arch/um/include/asm/uaccess.h:16,
>>>from ./arch/um/include/asm/thread_info.h:13,
>>>from include/linux/thread_info.h:54,
>>>from include/asm-generic/current.h:4,
>>>from arch/um/include/generated/asm/current.h:1,
>>>from include/linux/mutex.h:13,
>>>from include/linux/kernfs.h:13,
>>>from include/linux/sysfs.h:15,
>>>from include/linux/kobject.h:21,
>>>from include/linux/device.h:17,
>>>from include/linux/platform_device.h:14,
>>>from drivers/base/platform.c:14:
>>> ./arch/um/include/asm/processor-generic.h:107:19: error: expected
>>> identifier or '(' before '&' token
>>>#define cpu_data (_cpu_data)
>>> ^
>>> include/linux/pm_domain.h:74:23: note: in expansion of macro 'cpu_data'
>>> struct gpd_cpu_data *cpu_data;
>>>^
>>>
>>> Also need notice about 80 columns boundary.
>>
>> I don't object to this change at all, but it could be easier to solve
>> this by fixing up 'cpu_data' to be named something a bit less "generic"?
>> What does x86 use for this data type?
>>
>
> It is for some kinds of arm cpu (I let this patch pass arm s3c600
Oh, sorry, typo issue, it is s3c6400 def_config.
> def_config building). Other architectures did not use it, at present.
>
> If necessary to complete the comments, please let me know, I shall send
> patch v2 for it.
>
> 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/
Re: [PATCH] drivers: base: power: domain: Use 'pm_cpu_data' instead of 'cpu_data' for compiling break
On Sun, Oct 05, 2014 at 09:13:09AM +0800, Chen Gang wrote:
> On 10/5/14 0:00, Greg KH wrote:
> > On Sat, Oct 04, 2014 at 10:19:50PM +0800, Chen Gang wrote:
> >> 'cpu_data' is too common to be already used by some architectures (e.g.
> >> um, m32r, and mn10300), so need use 'pm_cpu_data' instead of, or cause
> >> compiling break. The related error (with allmodconfig under um):
> >>
> >> CC drivers/base/platform.o
> >> In file included from ./arch/x86/um/asm/processor.h:31:0,
> >>from ./arch/um/include/asm/uaccess.h:16,
> >>from ./arch/um/include/asm/thread_info.h:13,
> >>from include/linux/thread_info.h:54,
> >>from include/asm-generic/current.h:4,
> >>from arch/um/include/generated/asm/current.h:1,
> >>from include/linux/mutex.h:13,
> >>from include/linux/kernfs.h:13,
> >>from include/linux/sysfs.h:15,
> >>from include/linux/kobject.h:21,
> >>from include/linux/device.h:17,
> >>from include/linux/platform_device.h:14,
> >>from drivers/base/platform.c:14:
> >> ./arch/um/include/asm/processor-generic.h:107:19: error: expected
> >> identifier or '(' before '&' token
> >>#define cpu_data (_cpu_data)
> >> ^
> >> include/linux/pm_domain.h:74:23: note: in expansion of macro 'cpu_data'
> >> struct gpd_cpu_data *cpu_data;
> >>^
> >>
> >> Also need notice about 80 columns boundary.
> >
> > I don't object to this change at all, but it could be easier to solve
> > this by fixing up 'cpu_data' to be named something a bit less "generic"?
> > What does x86 use for this data type?
> >
>
> It is for some kinds of arm cpu (I let this patch pass arm s3c600
> def_config building). Other architectures did not use it, at present.
So why not change the name for these archs that have such a generic name
to something not so generic?
thanks,
greg k-h
--
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] watchdog: Let XILINX_WATCHDOG and TEGRA_WATCHDOG depend on HAS_IOMEM
They need HAS_IOMEM, so let them depend on it, the related error (with allmodconfig under um): MODPOST 1205 modules ERROR: "devm_ioremap_resource" [drivers/watchdog/tegra_wdt.ko] undefined! ERROR: "devm_ioremap_resource" [drivers/watchdog/of_xilinx_wdt.ko] undefined! Signed-off-by: Chen Gang --- drivers/watchdog/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index a51ccf3..d0ddf90 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -132,6 +132,7 @@ config WM8350_WATCHDOG config XILINX_WATCHDOG tristate "Xilinx Watchdog timer" + depends on HAS_IOMEM select WATCHDOG_CORE help Watchdog driver for the xps_timebase_wdt ip core. @@ -472,7 +473,7 @@ config SIRFSOC_WATCHDOG config TEGRA_WATCHDOG tristate "Tegra watchdog" - depends on ARCH_TEGRA || COMPILE_TEST + depends on (ARCH_TEGRA || COMPILE_TEST) && HAS_IOMEM select WATCHDOG_CORE help Say Y here to include support for the watchdog timer -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/watchdog/Kconfig: Let XILINX_WATCHDOG and TEGRA_WATCHDOG depend on HAS_IOMEM
On 10/5/14 8:18, Guenter Roeck wrote:
> On 10/04/2014 02:39 AM, Chen Gang wrote:
>> They need HAS_IOMEM, so let them depend on it, the related error (with
>> allmodconfig under um):
>>
>> MODPOST 1205 modules
>>ERROR: "syscall" [fs/hostfs/hostfs.ko] undefined!
>>ERROR: "devm_ioremap_resource" [drivers/watchdog/tegra_wdt.ko] undefined!
>>ERROR: "devm_ioremap_resource" [drivers/watchdog/of_xilinx_wdt.ko]
>> undefined!
>>
> Headline is a bit excessive ("watchdog: ..." would have been sufficient,
> the first error is irrelevant as you found out yourself, and you got an
> extra empty line here. Otherwise looks good.
>
> Can you resubmit with that fixed ?
>
OK, thank, I shall send patch v2 for it.
> On a side note, guess the conclusion was to not provide a dummy for
> devm_ioremap_resource if HAS_IOMEM is not defined. Too bad.
>
For me, it is checked during config time, so need report error during
compiling or building time instead of dummy.
And I'd like to let devm_ioremap* quoted by "#if HAS_IOMEM", so can
find this issue during compiling time, not in linking time (which can
save builder's time resource).
Thanks.
>>
>> Signed-off-by: Chen Gang
>> ---
>> drivers/watchdog/Kconfig | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
>> index a51ccf3..d0ddf90 100644
>> --- a/drivers/watchdog/Kconfig
>> +++ b/drivers/watchdog/Kconfig
>> @@ -132,6 +132,7 @@ config WM8350_WATCHDOG
>>
>> config XILINX_WATCHDOG
>> tristate "Xilinx Watchdog timer"
>> +depends on HAS_IOMEM
>> select WATCHDOG_CORE
>> help
>> Watchdog driver for the xps_timebase_wdt ip core.
>> @@ -472,7 +473,7 @@ config SIRFSOC_WATCHDOG
>>
>> config TEGRA_WATCHDOG
>> tristate "Tegra watchdog"
>> -depends on ARCH_TEGRA || COMPILE_TEST
>> +depends on (ARCH_TEGRA || COMPILE_TEST) && HAS_IOMEM
>> select WATCHDOG_CORE
>> help
>> Say Y here to include support for the watchdog timer
>>
>
--
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/
Re: [PATCH] staging: gdm72xx: fix typo and coding style
On Tue, Sep 30, 2014 at 01:03:03PM +0200, Thibaut Robert wrote:
> Fix a typo in error message.
> Add missing curling braces to conform to coding style.
> Improve readibility.
That's three things in one patch :(
Please only do one thing per patch.
>
> Signed-off-by: Thibaut Robert
> ---
> drivers/staging/gdm72xx/netlink_k.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/staging/gdm72xx/netlink_k.c
> b/drivers/staging/gdm72xx/netlink_k.c
> index 9d78bfc..31862e5 100644
> --- a/drivers/staging/gdm72xx/netlink_k.c
> +++ b/drivers/staging/gdm72xx/netlink_k.c
> @@ -71,10 +71,11 @@ static void netlink_rcv_cb(struct sk_buff *skb)
> if (dev) {
> rcv_cb(dev, nlh->nlmsg_type, msg, mlen);
> dev_put(dev);
> - } else
> + } else {
> netdev_err(skb->dev,
> "dev_get_by_index(%d) is not
> found.\n",
> ifindex);
> + }
> } else {
> netdev_err(skb->dev, "Unregistered Callback\n");
> }
> @@ -120,9 +121,9 @@ int netlink_send(struct sock *sock, int group, u16 type,
> void *msg, int len)
> struct nlmsghdr *nlh;
> int ret = 0;
>
> - if (group > ND_MAX_GROUP) {
> - pr_err("Group %d is invalied.\n", group);
> - pr_err("Valid group is 0 ~ %d.\n", ND_MAX_GROUP);
> + if (group < 0 || group > ND_MAX_GROUP) {
How can group be less than 0?
thanks,
greg k-h
--
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: base: power: domain: Use 'pm_cpu_data' instead of 'cpu_data' for compiling break
On 10/5/14 0:00, Greg KH wrote:
> On Sat, Oct 04, 2014 at 10:19:50PM +0800, Chen Gang wrote:
>> 'cpu_data' is too common to be already used by some architectures (e.g.
>> um, m32r, and mn10300), so need use 'pm_cpu_data' instead of, or cause
>> compiling break. The related error (with allmodconfig under um):
>>
>> CC drivers/base/platform.o
>> In file included from ./arch/x86/um/asm/processor.h:31:0,
>>from ./arch/um/include/asm/uaccess.h:16,
>>from ./arch/um/include/asm/thread_info.h:13,
>>from include/linux/thread_info.h:54,
>>from include/asm-generic/current.h:4,
>>from arch/um/include/generated/asm/current.h:1,
>>from include/linux/mutex.h:13,
>>from include/linux/kernfs.h:13,
>>from include/linux/sysfs.h:15,
>>from include/linux/kobject.h:21,
>>from include/linux/device.h:17,
>>from include/linux/platform_device.h:14,
>>from drivers/base/platform.c:14:
>> ./arch/um/include/asm/processor-generic.h:107:19: error: expected
>> identifier or '(' before '&' token
>>#define cpu_data (_cpu_data)
>> ^
>> include/linux/pm_domain.h:74:23: note: in expansion of macro 'cpu_data'
>> struct gpd_cpu_data *cpu_data;
>>^
>>
>> Also need notice about 80 columns boundary.
>
> I don't object to this change at all, but it could be easier to solve
> this by fixing up 'cpu_data' to be named something a bit less "generic"?
> What does x86 use for this data type?
>
It is for some kinds of arm cpu (I let this patch pass arm s3c600
def_config building). Other architectures did not use it, at present.
If necessary to complete the comments, please let me know, I shall send
patch v2 for it.
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/
Re: [PATCH] drivers/watchdog/Kconfig: Let XILINX_WATCHDOG and TEGRA_WATCHDOG depend on HAS_IOMEM
On 10/04/2014 02:39 AM, Chen Gang wrote:
They need HAS_IOMEM, so let them depend on it, the related error (with
allmodconfig under um):
MODPOST 1205 modules
ERROR: "syscall" [fs/hostfs/hostfs.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/watchdog/tegra_wdt.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/watchdog/of_xilinx_wdt.ko] undefined!
Headline is a bit excessive ("watchdog: ..." would have been sufficient,
the first error is irrelevant as you found out yourself, and you got an
extra empty line here. Otherwise looks good.
Can you resubmit with that fixed ?
On a side note, guess the conclusion was to not provide a dummy for
devm_ioremap_resource if HAS_IOMEM is not defined. Too bad.
Guenter
Signed-off-by: Chen Gang
---
drivers/watchdog/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index a51ccf3..d0ddf90 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -132,6 +132,7 @@ config WM8350_WATCHDOG
config XILINX_WATCHDOG
tristate "Xilinx Watchdog timer"
+ depends on HAS_IOMEM
select WATCHDOG_CORE
help
Watchdog driver for the xps_timebase_wdt ip core.
@@ -472,7 +473,7 @@ config SIRFSOC_WATCHDOG
config TEGRA_WATCHDOG
tristate "Tegra watchdog"
- depends on ARCH_TEGRA || COMPILE_TEST
+ depends on (ARCH_TEGRA || COMPILE_TEST) && HAS_IOMEM
select WATCHDOG_CORE
help
Say Y here to include support for the watchdog timer
--
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 1/4] hwmon: ltc2978: device tree bindings documentation
On 10/04/2014 02:53 AM, Mark Brown wrote:
On Fri, Oct 03, 2014 at 04:23:15PM -0700, Guenter Roeck wrote:
On 10/03/2014 04:13 PM, Mark Brown wrote:
Nope, nothing to do with regulator that I'm aware of and I've not seen
any examples (but I don't tend to review users too often).
Many examples, really. Just picking one.
Documentation/devicetree/bindings/mfd/tps6507x.txt
OK, that's not an actual DTS... I'm not seeing anything in the code.
regulators {
#address-cells = <1>;
#size-cells = <0>;
...
This also uses the reg property for the regulator index
(without explaining it further). Seems to be pretty common.
If it's doing that it's nothing to do with the regulator API.
Since the code does not use those values either, presumably they don't have
to be specified in the first place. I'll test that with a real system
next week.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] power: ab8500_fg: Fix build warning
Hi, On Sat, Oct 04, 2014 at 04:31:13PM -0700, Guenter Roeck wrote: > Fix > > drivers/power/ab8500_fg.c: In function 'ab8500_fg_probe': > drivers/power/ab8500_fg.c:2989:27: > warning: 'i' may be used uninitialized in this function > drivers/power/ab8500_fg.c:2972:15: note: 'i' was declared here > > which actually points to a real bug. > > Signed-off-by: Guenter Roeck Thanks, pushed: http://git.infradead.org/battery-2.6.git/commit/7881c64716f3a7d60b325ed0ad4d15f49b474a43 -- Sebastian signature.asc Description: Digital signature
[PATCH] power: ab8500_fg: Fix build warning
Fix
drivers/power/ab8500_fg.c: In function 'ab8500_fg_probe':
drivers/power/ab8500_fg.c:2989:27:
warning: 'i' may be used uninitialized in this function
drivers/power/ab8500_fg.c:2972:15: note: 'i' was declared here
which actually points to a real bug.
Signed-off-by: Guenter Roeck
---
drivers/power/ab8500_fg.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/power/ab8500_fg.c b/drivers/power/ab8500_fg.c
index 3cb4178..217da4b 100644
--- a/drivers/power/ab8500_fg.c
+++ b/drivers/power/ab8500_fg.c
@@ -2969,7 +2969,7 @@ static struct device_attribute
ab8505_fg_sysfs_psy_attrs[] = {
static int ab8500_fg_sysfs_psy_create_attrs(struct device *dev)
{
- unsigned int i, j;
+ unsigned int i;
struct power_supply *psy = dev_get_drvdata(dev);
struct ab8500_fg *di;
@@ -2978,14 +2978,15 @@ static int ab8500_fg_sysfs_psy_create_attrs(struct
device *dev)
if (((is_ab8505(di->parent) || is_ab9540(di->parent)) &&
abx500_get_chip_id(dev->parent) >= AB8500_CUT2P0)
|| is_ab8540(di->parent)) {
- for (j = 0; j < ARRAY_SIZE(ab8505_fg_sysfs_psy_attrs); j++)
- if (device_create_file(dev,
_fg_sysfs_psy_attrs[j]))
+ for (i = 0; i < ARRAY_SIZE(ab8505_fg_sysfs_psy_attrs); i++)
+ if (device_create_file(dev,
+ _fg_sysfs_psy_attrs[i]))
goto sysfs_psy_create_attrs_failed_ab8505;
}
return 0;
sysfs_psy_create_attrs_failed_ab8505:
dev_err(dev, "Failed creating sysfs psy attrs for ab8505.\n");
- while (j--)
+ while (i--)
device_remove_file(dev, _fg_sysfs_psy_attrs[i]);
return -EIO;
--
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] x86: Quark: Comment setup_arch() to document TLB/PGE behaviour
Quark SoC X1000 advertises Page Global Enable for it's Translation Lookaside Buffer via cpuid. The silicon does not in fact support PGE and hence will not flush the TLB when CR4.PGE is rewritten. The Quark documentation makes clear the necessity to instead rewrite CR3 in order to flush any TLB entries, irrespective of the state of CR4.PGE or an individual PTE.PGE See Intel Quark Core DevMan_001.pdf section 6.4.11 In setup.c setup_arch() the code will load_cr3() and then do a __flush_tlb_all(). On Quark the entire TLB will be flushed at the load_cr3(). The __flush_tlb_all() have no effect and can be safely ignored. Later on in the boot process we switch off the flag for cpu_has_pge() which means that subsequent calls to __flush_tlb_all() will call __flush_tlb() not __flush_tlb_global() flushing the TLB in the correct way via load_cr3() not CR4.PGE rewrite This patch documents the behaviour of flushing the TLB for Quark in setup_arch() Comment text suggested by Thomas Gleixner Signed-off-by: Bryan O'Donoghue --- arch/x86/kernel/setup.c | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 41ead8d..235cfd3 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -879,6 +879,15 @@ void __init setup_arch(char **cmdline_p) KERNEL_PGD_PTRS); load_cr3(swapper_pg_dir); + /* +* Note: Quark X1000 CPUs advertise PGE incorrectly and require +* a cr3 based tlb flush, so the following __flush_tlb_all() +* will not flush anything because the cpu quirk which clears +* X86_FEATURE_PGE has not been invoked yet. Though due to the +* load_cr3() above the TLB has been flushed already. The +* quirk is invoked before subsequent calls to __flush_tlb_all() +* so proper operation is guaranteed. +*/ __flush_tlb_all(); #else printk(KERN_INFO "Command line: %s\n", boot_command_line); -- 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 0/2] Fix legacy_cache detect on Intel. Add Quark to legacy_cache, document TLB quirk
These two patches cover four things. First add legacy_cache callback into init_intel() to enable calling of intel_size_cache() re-enabling detection of PIII Tualatin cache size and allowing Quark SoC X1000 hooked into this mechanism to similarly report it's cache size. Second adding of Quark SoC X1000 to the legacy_cache callback so that it too will report correct cache size. In this case a 4-way set associative cache with a 16 byte cache line and 256 lines per tag. Third add the Quark SoC X1000 string so that /proc/cpuinfo gives the correct description of the processor in the "model name" field. Finally documentation of early TLB flushing behaviour on Quark before cpu_has_pge() has been switched off. For clarity the existing code works fine on Quark. This change to setup.c documents the minutiae of why. Bryan O'Donoghue (2): x86: Add cpu_detect_cache_sizes() to init_intel(), add Quark to legacy_cache x86: Quark: Comment setup_arch() to document TLB/PGE behaviour arch/x86/kernel/cpu/intel.c | 23 +-- arch/x86/kernel/setup.c | 9 + 2 files changed, 30 insertions(+), 2 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 1/2] x86: Add cpu_detect_cache_sizes() to init_intel(), add Quark to legacy_cache()
Intel processors which don't report cache information via cpuid(2)
or cpuid(4) need quirk code in the legacy_cache_size callback to
report this data. For Intel that callback is is intel_size_cache().
This patch enables calling of cpu_detect_cache_sizes() inside of
init_intel() and hence the calling of the legacy_cache callback in
intel_size_cache(). Adding this call will ensure that PIII Tualatin
currently in intel_size_cache() and Quark SoC X1000 being added to
intel_size_cache() in this patch will report their respective cache
sizes.
This model of calling cpu_detect_cache_sizes() is consistent with
AMD/Via/Cirix/Transmeta and Centaur.
Also added is a string to idenitfy the Quark as Quark SoC X1000
giving better and more descriptive output via /proc/cpuinfo
Adding cpu_detect_cache_sizes to init_intel() will enable calling
of intel_size_cache() on Intel processors which currently no code
can reach. Therefore this patch will also re-enable reporting
of PIII Tualatin cache size information as well as add
Quark SoC X1000 support.
Comment text suggested by Thomas Gleixner
Signed-off-by: Bryan O'Donoghue
---
arch/x86/kernel/cpu/intel.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 74e804d..f4248b7 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -381,7 +381,18 @@ static void init_intel(struct cpuinfo_x86 *c)
#endif
}
- l2 = init_intel_cacheinfo(c);
+ /* Detect legacy cache sizes */
+ cpu_detect_cache_sizes(c);
+
+ /*
+* If cache_size has not been initialized via legacy_cache()
+* probe it via init_intel_cacheinfo().
+*/
+ if (c->x86_cache_size == 0)
+ l2 = init_intel_cacheinfo(c);
+ else
+ l2 = c->x86_cache_size;
+
if (c->cpuid_level > 9) {
unsigned eax = cpuid_eax(10);
/* Check for version and the number of counters */
@@ -485,6 +496,13 @@ static unsigned int intel_size_cache(struct cpuinfo_x86
*c, unsigned int size)
*/
if ((c->x86 == 6) && (c->x86_model == 11) && (size == 0))
size = 256;
+
+ /*
+* Intel Quark SoC X1000 contains a 4-way set associative
+* 16K cache with a 16 byte cache line and 256 lines per tag
+*/
+ if ((c->x86 == 5) && (c->x86_model == 9))
+ size = 16;
return size;
}
#endif
@@ -686,7 +704,8 @@ static const struct cpu_dev intel_cpu_dev = {
[3] = "OverDrive PODP5V83",
[4] = "Pentium MMX",
[7] = "Mobile Pentium 75 - 200",
- [8] = "Mobile Pentium MMX"
+ [8] = "Mobile Pentium MMX",
+ [9] = "Quark SoC X1000",
}
},
{ .family = 6, .model_names =
--
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] posix-timers: fix stack info leak in timer_create()
If userland creates a timer without specifying a sigevent info, we'll
create one ourself, using a stack local variable. Particularly will we
use the timer ID as sival_int. But as sigev_value is a union containing
a pointer and an int, that assignment will only partially initialize
sigev_value on systems where the size of a pointer is bigger than the
size of an int. On such systems we'll copy the uninitialized stack bytes
from the timer_create() call to userland when the timer actually fires
and we're going to deliver the signal.
Initialize sigev_value with 0 to plug the stack info leak.
Found in the PaX patch, written by the PaX Team.
Fixes: 5a9fa7307285 ("posix-timers: kill ->it_sigev_signo and...")
Signed-off-by: Mathias Krause
Cc: Oleg Nesterov
Cc: Brad Spengler
Cc: PaX Team
Cc: # v2.6.28+
---
kernel/time/posix-timers.c |1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
index 42b463ad90f2..31ea01f42e1f 100644
--- a/kernel/time/posix-timers.c
+++ b/kernel/time/posix-timers.c
@@ -636,6 +636,7 @@ SYSCALL_DEFINE3(timer_create, const clockid_t, which_clock,
goto out;
}
} else {
+ memset(_value, 0, sizeof(event.sigev_value));
event.sigev_notify = SIGEV_SIGNAL;
event.sigev_signo = SIGALRM;
event.sigev_value.sival_int = new_timer->it_id;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] MIPS: Setup an instruction emulation in VDSO protected page instead of user stack
On Fri, Oct 03, 2014 at 08:17:30PM -0700, Leonid Yegoshin wrote:
> --- a/arch/mips/include/asm/switch_to.h
> +++ b/arch/mips/include/asm/switch_to.h
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
>
> struct task_struct;
>
> @@ -104,6 +105,16 @@ do {
> \
> disable_msa(); \
> } while (0)
>
> +static inline void flush_vdso_page(void)
> +{
> + if (current->mm && cpu_context(raw_smp_processor_id(), current->mm) &&
> + (current->mm->context.vdso_asid[raw_smp_processor_id()] ==
> + cpu_asid(raw_smp_processor_id(), current->mm))) {
> + local_flush_tlb_page(current->mm->mmap, (unsigned
> long)current->mm->context.vdso);
> + current->mm->context.vdso_asid[raw_smp_processor_id()] = 0;
> + }
> +}
Why raw_smp_processor_id() and why evaluate it 3 times, sure compilers
can be expected to do some CSE but something like:
int cpu = smp_processor_id();
if ( ... [cpu] ...)
is far more readable as well.
> +
> #define finish_arch_switch(prev) \
> do { \
> u32 __c0_stat; \
> @@ -118,6 +129,7 @@ do {
> \
> __restore_dsp(current); \
> if (cpu_has_userlocal) \
> write_c0_userlocal(current_thread_info()->tp_value);\
> + flush_vdso_page(); \
> __restore_watch(); \
> } while (0)
So what I didn't see is any talk about the cost of this. Surely a TLB
flush isn't exactly free.
--
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
Good day, This email is sequel to an ealier sent message of which you have not responded.I have a personal charity project which I will want you to execute on my behalf.Please kidnly get back to me with this code MHR/3910/2014 .You can reach me on mrsalimqa...@gmail.com . Thank you Salim Qadri -- 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] rcutorture: Remove obsolete kversion param in kvm.sh
On Sat, Oct 04, 2014 at 01:04:15PM -0400, Pranith Kumar wrote:
> Now that we have removed configs based on kernel version, we can also remove
> the
> kversion parameter in kvm.sh.
>
> Signed-off-by: Pranith Kumar
Reviewed-by: Josh Triplett
> .../selftests/rcutorture/bin/kvm-test-1-run.sh| 2 +-
> tools/testing/selftests/rcutorture/bin/kvm.sh | 19
> +--
> 2 files changed, 6 insertions(+), 15 deletions(-)
>
> diff --git a/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
> b/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
> index e0f8969..8ca9f21 100755
> --- a/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
> +++ b/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
> @@ -45,7 +45,7 @@ trap 'rm -rf $T' 0
> touch $T
>
> . $KVM/bin/functions.sh
> -. $KVPATH/ver_functions.sh
> +. $CONFIGFRAG/ver_functions.sh
>
> config_template=${1}
> config_dir=`echo $config_template | sed -e 's,/[^/]*$,,'`
> diff --git a/tools/testing/selftests/rcutorture/bin/kvm.sh
> b/tools/testing/selftests/rcutorture/bin/kvm.sh
> index e527dc9..368d64a 100755
> --- a/tools/testing/selftests/rcutorture/bin/kvm.sh
> +++ b/tools/testing/selftests/rcutorture/bin/kvm.sh
> @@ -47,7 +47,6 @@ resdir=""
> configs=""
> cpus=0
> ds=`date +%Y.%m.%d-%H:%M:%S`
> -kversion=""
>
> . functions.sh
>
> @@ -64,7 +63,6 @@ usage () {
> echo " --duration minutes"
> echo " --interactive"
> echo " --kmake-arg kernel-make-arguments"
> - echo " --kversion vN.NN"
> echo " --mac nn:nn:nn:nn:nn:nn"
> echo " --no-initrd"
> echo " --qemu-args qemu-system-..."
> @@ -128,11 +126,6 @@ do
> TORTURE_KMAKE_ARG="$2"
> shift
> ;;
> - --kversion)
> - checkarg --kversion "(kernel version)" $# "$2" '^v[0-9.]*$'
> '^error'
> - kversion=$2
> - shift
> - ;;
> --mac)
> checkarg --mac "(MAC address)" $# "$2"
> '^\([0-9a-fA-F]\{2\}:\)\{5\}[0-9a-fA-F]\{2\}$' error
> TORTURE_QEMU_MAC=$2
> @@ -170,11 +163,10 @@ do
> done
>
> CONFIGFRAG=${KVM}/configs/${TORTURE_SUITE}; export CONFIGFRAG
> -KVPATH=${CONFIGFRAG}/$kversion; export KVPATH
>
> if test -z "$configs"
> then
> - configs="`cat $CONFIGFRAG/$kversion/CFLIST`"
> + configs="`cat $CONFIGFRAG/CFLIST`"
> fi
>
> if test -z "$resdir"
> @@ -186,10 +178,10 @@ fi
> touch $T/cfgcpu
> for CF in $configs
> do
> - if test -f "$CONFIGFRAG/$kversion/$CF"
> + if test -f "$CONFIGFRAG/$CF"
> then
> - cpu_count=`configNR_CPUS.sh $CONFIGFRAG/$kversion/$CF`
> - cpu_count=`configfrag_boot_cpus "$TORTURE_BOOTARGS"
> "$CONFIGFRAG/$kversion/$CF" "$cpu_count"`
> + cpu_count=`configNR_CPUS.sh $CONFIGFRAG/$CF`
> + cpu_count=`configfrag_boot_cpus "$TORTURE_BOOTARGS"
> "$CONFIGFRAG/$CF" "$cpu_count"`
> echo $CF $cpu_count >> $T/cfgcpu
> else
> echo "The --configs file $CF does not exist, terminating."
> @@ -252,7 +244,6 @@ END {
> cat << ___EOF___ > $T/script
> CONFIGFRAG="$CONFIGFRAG"; export CONFIGFRAG
> KVM="$KVM"; export KVM
> -KVPATH="$KVPATH"; export KVPATH
> PATH="$PATH"; export PATH
> TORTURE_BOOT_IMAGE="$TORTURE_BOOT_IMAGE"; export TORTURE_BOOT_IMAGE
> TORTURE_BUILDONLY="$TORTURE_BUILDONLY"; export TORTURE_BUILDONLY
> @@ -285,7 +276,7 @@ then
> fi
> ___EOF___
> awk < $T/cfgcpu.pack \
> - -v CONFIGDIR="$CONFIGFRAG/$kversion/" \
> + -v CONFIGDIR="$CONFIGFRAG/" \
> -v KVM="$KVM" \
> -v ncpus=$cpus \
> -v rd=$resdir/$ds/ \
> --
> 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] Staging: media: Added semicolon.
Added semicolon for the line usleep_range(1, 11000);
Signed-off-by: Stevean Raja Kumar
---
drivers/staging/media/cxd2099/cxd2099.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/cxd2099/cxd2099.c
b/drivers/staging/media/cxd2099/cxd2099.c
index cda1595..657ea48 100644
--- a/drivers/staging/media/cxd2099/cxd2099.c
+++ b/drivers/staging/media/cxd2099/cxd2099.c
@@ -527,7 +527,7 @@ static int slot_reset(struct dvb_ca_en50221 *ca, int slot)
u8 val;
#endif
for (i = 0; i < 100; i++) {
- usleep_range(1, 11000)
+ usleep_range(1, 11000);
#if 0
read_reg(ci, 0x06, );
dev_info(>i2c->dev, "%d:%02x\n", i, val);
--
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/
xhci_hcd: WARN Event TRB for slot 6 ep 4 with no TDs queued?
Hi, I'm getting xhci_hcd :00:14.0: WARN Event TRB for slot 6 ep 4 with no TDs queued? on each interaction with my built-in CCID smartcard reader (Celsius H730). The device is working fine otherwise, just the log fills up. What's the reason? What can be done about it? Find lsusb -v of the reader below. Jan --- Bus 001 Device 006: ID 0b97:7772 O2 Micro, Inc. OZ776 CCID Smartcard Reader Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0b97 O2 Micro, Inc. idProduct 0x7772 OZ776 CCID Smartcard Reader bcdDevice1.10 iManufacturer 1 O2 iProduct2 O2Micro CCID SC Reader iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 93 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass11 Chip/SmartCard bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0003 1x 3 bytes bInterval 255 ChipCard Interface Descriptor: bLength54 bDescriptorType33 bcdCCID 1.00 nMaxSlotIndex 0 bVoltageSupport 7 5.0V 3.0V 1.8V dwProtocols 3 T=0 T=1 dwDefaultClock 4000 dwMaxiumumClock 4000 bNumClockSupported 0 dwDataRate 9600 bps dwMaxDataRate 307200 bps bNumDataRatesSupp. 0 dwMaxIFSD 254 dwSyncProtocols dwMechanical dwFeatures 0030 Auto clock change Auto baud rate change dwMaxCCIDMsgLen 271 bClassGetResponse 00 bClassEnvelope 00 wlcdLayout none bPINSupport 0 bMaxCCIDBusySlots 1 Device Status: 0x0001 Self Powered signature.asc Description: OpenPGP digital signature
uas: module not loaded automatically
Hi, my Delock external USB drive stopped working after updating from a UAS-disabled distro kernel to latest 3.17-rc7 with UAS on. That UAS was key became clear to me only after looking at storage_probe(): the device is ignored by usb-storage if it is UAS-capable. However, nothing causes uas.ko to be loaded when the drive is plugged here. How is this supposed to work in the normal case? lsusb of the device below. Jan --- Bus 001 Device 009: ID 174c:5136 ASMedia Technology Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x174c ASMedia Technology Inc. idProduct 0x5136 bcdDevice1.00 iManufacturer 2 Delock iProduct3 42514 iSerial 1 2CB4 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 85 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 1 bNumEndpoints 4 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 98 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Data-in pipe (0x03) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Data-out pipe (0x04) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Status pipe (0x02) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Command pipe (0x01) Binary Object Store Descriptor: bLength 5 bDescriptorType15 wTotalLength 22 bNumDeviceCaps 2 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType16 bDevCapabilityType 2 bmAttributes 0x0002 Link Power Management (LPM) Supported SuperSpeed USB Device Capability: bLength10 bDescriptorType16 bDevCapabilityType 3 bmAttributes 0x00 wSpeedsSupported 0x000e Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps)
[PATCH v2] toshiba_acpi: Adapt kbd_bl_timeout_store to the new kbd type
With the introduccion of the new keyboard backlight
implementation, the *_timeout_store function is
broken, as it only supports the first kbd_type.
This patch adapt such function for the new kbd_type,
as well as convert from using sscanf to kstrtoint.
Signed-off-by: Azael Avalos
---
Changes since v1:
- Check for timeout values depending on kbd_type
- Removed some misleading comments
Note: I'll be out of town until the next weekend,
in case something else needs to be changed, I'll
catch up whenever I'm back.
drivers/platform/x86/toshiba_acpi.c | 38 -
1 file changed, 29 insertions(+), 9 deletions(-)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 5d509ea..f360dac 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -1453,18 +1453,38 @@ static ssize_t toshiba_kbd_bl_timeout_store(struct
device *dev,
const char *buf, size_t count)
{
struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
- int time = -1;
+ int time;
+ int ret;
- if (sscanf(buf, "%i", ) != 1 && (time < 0 || time > 60))
- return -EINVAL;
+ ret = kstrtoint(buf, 0, );
+ if (ret)
+ return ret;
- /* Set the Keyboard Backlight Timeout: 0-60 seconds */
- if (time != -1 && toshiba->kbd_time != time) {
+ /* Check for supported values depending on kbd_type */
+ if (toshiba->kbd_type == 1) {
+ if (time < 0 || time > 60)
+ return -EINVAL;
+ } else if (toshiba->kbd_type == 2) {
+ if (time < 1 || time > 60)
+ return -EINVAL;
+ }
+
+ /* Set the Keyboard Backlight Timeout */
+
+ /* Only make a change if the actual timeout has changed */
+ if (toshiba->kbd_time != time) {
+ /* Shift the time to "base time" (0x3c == 60 seconds) */
time = time << HCI_MISC_SHIFT;
- time = (toshiba->kbd_mode == SCI_KBD_MODE_AUTO) ?
- time + 1 : time + 2;
- if (toshiba_kbd_illum_status_set(toshiba, time) < 0)
- return -EIO;
+ /* OR the "base time" to the actual method format */
+ if (toshiba->kbd_type == 1)
+ time |= SCI_KBD_MODE_FNZ;
+ else if (toshiba->kbd_type == 2)
+ time |= SCI_KBD_MODE_AUTO;
+
+ ret = toshiba_kbd_illum_status_set(toshiba, time);
+ if (ret)
+ return ret;
+
toshiba->kbd_time = time >> HCI_MISC_SHIFT;
}
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: (Song) Fk SystemD
On Sat, Oct 04, 2014 at 06:49:30PM +0200, Tom Collins wrote: [snip masturbation] To quote Jordan Hubbard, Your brand of "advocacy" is akin to having the KKK show up at one's wedding to congradulate the happy couple on their choice of marrying within their race. Some kinds of "support" you just don't need if all it leaves you with the desire to take a couple of dozen showers. That was about a different dipshit in a different flamefest, but it applies to you nicely. Incidentally, as you obviously understand and don't give a fuck about, you are actively helping the Fine Piece Of Software in question, letting the pushers of said FPOS to paint everyone who has objections with your, er, output... Go play in the traffic, kid. Remember to arrange a video... -- 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: [perf] BUG: unable to handle kernel NULL pointer dereference at 00000085
On Sat, Oct 04, 2014 at 09:46:22PM +0800, Fengguang Wu wrote:
> Hi Peter,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git perf/core
>
> commit a54b3e27e27c1bb6d2610eade895c04934c2667e
> Author: Peter Zijlstra
> AuthorDate: Wed Sep 24 13:48:42 2014 +0200
> Commit: Peter Zijlstra
> CommitDate: Thu Oct 2 23:11:50 2014 +0200
>
> perf: improve perf_sample_data struct layout
>
> This patch reorders fields in the perf_sample_data
> struct in order to minimize the number of cachelines
> touched in perf_sample_data_init(). It also removes
> some intializations which are redundant with the
> code in kernel/events/core.c
>
> Cc: mi...@elte.hu
> Cc: a...@linux.intel.com
> Cc: jo...@redhat.com
> Cc: a...@redhat.com
> Cc: cebbert.l...@gmail.com
> Cc: pet...@infradead.org
>
> Signed-off-by: Peter Zijlstra (Intel)
> Link:
> http://lkml.kernel.org/r/1411559322-16548-7-git-send-email-eran...@google.com
>
> [ 267.547006] debug: unmapping init [mem 0xc28f9000-0xc2b03fff]
> [ 267.694378] random: init urandom read with 4 bits of entropy available
> [ 279.465522] sock: process `trinity-main' is using obsolete setsockopt
> SO_BSDCOMPAT
> [ 285.269144] BUG: unable to handle kernel NULL pointer dereference at
> 0085
> [ 285.273002] IP: [] perf_prepare_sample+0x33e/0x496
> [ 285.276062] *pde =
> [ 285.279106] Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [ 285.279106] Modules linked in:
> [ 285.279106] CPU: 1 PID: 1583 Comm: trinity-main Not tainted
> 3.17.0-rc4-00210-ga54b3e2 #1
> [ 285.279106] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.7.5-20140531_083030-gandalf 04/01/2014
> [ 285.279106] task: c9475e80 ti: c967 task.ti: c967
> [ 285.279106] EIP: 0060:[] EFLAGS: 00010046 CPU: 1
> [ 285.279106] EIP is at perf_prepare_sample+0x33e/0x496
> [ 285.279106] EAX: EBX: ECX: 0049 EDX:
> [ 285.279106] ESI: cfd71c40 EDI: cfd71b84 EBP: cfd71b58 ESP: cfd71b34
> [ 285.279106] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> [ 285.279106] CR0: 80050033 CR2: 0085 CR3: 095b4000 CR4: 06d0
> [ 285.279106] DR0: 4143 DR1: DR2: DR3:
> [ 285.279106] DR6: 0ff0 DR7: 00010602
Could you try the below patch to confirm it works?
> This script may reproduce the error.
>
>
> #!/bin/bash
>
> kernel=$1
> initrd=quantal-core-i386.cgz
>
> wget --no-clobber
> https://github.com/fengguang/reproduce-kernel-bug/raw/master/initrd/$initrd
>
> kvm=(
> qemu-system-x86_64
> -cpu kvm64
> -enable-kvm
> -kernel $kernel
> -initrd $initrd
> -m 320
> -smp 2
> -net nic,vlan=1,model=e1000
> -net user,vlan=1
> -boot order=nc
> -no-reboot
> -watchdog i6300esb
> -rtc base=localtime
> -serial stdio
> -display none
> -monitor null
> )
>
> append=(
> hung_task_panic=1
> earlyprintk=ttyS0,115200
> debug
> apic=debug
> sysrq_always_enabled
> rcupdate.rcu_cpu_stall_timeout=100
> panic=-1
> softlockup_panic=1
> nmi_watchdog=panic
> oops=panic
> load_ramdisk=2
> prompt_ramdisk=0
> console=ttyS0,115200
> console=tty0
> vga=normal
> root=/dev/ram0
> rw
> drbd.minor_count=8
> )
>
> "${kvm[@]}" --append "${append[*]}"
>
What is lacking is the actual .config.
Also the times above (~285 seconds) seem to suggest userspace needs to
do something ?
I tried with i386-defconfig and the above receptie gives me:
...
[4.887413] tsc: Refined TSC clocksource calibration: 2693.765 MHz
[5.257469] hwclock (874) used greatest stack depth: 6624 bytes left
[5.299754] input: ImExPS/2 Generic Explorer Mouse as
/devices/platform/i8042/serio1/input/input3
[5.911225] Switched to clocksource tsc
[6.613714] init: Failed to create pty - disabling logging for job
[6.615490] init: Temporary process spawn error: No space left on device
[8.058431] initctl (926) used greatest stack depth: 6192 bytes left
[9.084036] init: plymouth-log main process (940) terminated with
status 1
Kernel tests: Boot OK!
[ 71.302525] reboot: Restarting system
Which I take is 'good', right?
---
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4953,12 +4953,13 @@ void perf_prepare_sample(struct perf_eve
header->size += size;
}
+ if (sample_type & (PERF_SAMPLE_REGS_USER | PERF_SAMPLE_STACK_USER))
+ perf_sample_regs_user(>regs_user, regs);
+
if (sample_type & PERF_SAMPLE_REGS_USER) {
/* regs dump ABI info */
int size = sizeof(u64);
-
Re: 3.17.0-rc7 kernel NULL pointer dereference (3ware 9650SE)
Finally got some more useful traces. [ 4629.957226] BUG: unable to handle kernel NULL pointer dereference at 0018 [ 4629.960539] IP: [] swiotlb_unmap_sg_attrs+0x30/0x70 [ 4629.960539] PGD 3e4176067 PUD 3e4177067 PMD 0 [ 4629.960539] Oops: [#1] SMP [ 4629.960539] Modules linked in: nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack serio_raw microcode [ 4629.960539] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G I 3.17.0-rc7-00086-gee042ec #20 [ 4629.960539] Hardware name: empty empty/S5393, BIOS V1.05 04/24/2009 [ 4629.960539] task: 8804295c3040 ti: 8804295cc000 task.ti: 8804295cc000 [ 4629.960539] RIP: 0010:[] [] swiotlb_unmap_sg_attrs+0x30/0x70 [ 4629.960539] RSP: 0018:88043fd83de8 EFLAGS: 00010002 [ 4629.960539] RAX: 88042903b898 RBX: RCX: 0001 [ 4629.960539] RDX: 0001 RSI: RDI: 88042903b898 [ 4629.960539] RBP: 88043fd83e18 R08: R09: 814aa230 [ 4629.960539] R10: R11: R12: [ 4629.960539] R13: 0001 R14: 0001 R15: 88042903b898 [ 4629.960539] FS: () GS:88043fd8() knlGS: [ 4629.960539] CS: 0010 DS: ES: CR0: 8005003b [ 4629.960539] CR2: 0018 CR3: 0003e4175000 CR4: 000407e0 [ 4629.960539] Stack: [ 4629.960539] 00f0 88003688c6c0 00f0 00f0 [ 4629.960539] 880036a7c000 88043fd83e28 81580cb0 [ 4629.960539] 88043fd83e38 815d7cc9 88043fd83ea8 815d89e4 [ 4629.960539] Call Trace: [ 4629.960539] [ 4629.960539] [ 4629.960539] [] scsi_dma_unmap+0x50/0x70 [ 4629.960539] [] twa_unmap_scsi_data+0x29/0x30 [ 4629.960539] [] twa_interrupt+0x414/0x800 [ 4629.960539] [] handle_irq_event_percpu+0x54/0x1b0 [ 4629.960539] [] handle_irq_event+0x3c/0x60 [ 4629.960539] [] handle_fasteoi_irq+0x77/0x130 [ 4629.960539] [] handle_irq+0x1d/0x30 [ 4629.960539] [] do_IRQ+0x59/0x110 [ 4629.960539] [] common_interrupt+0x6a/0x6a [ 4629.960539] [ 4629.960539] [ 4629.960539] [] ? default_idle+0x17/0xb0 [ 4629.960539] [] arch_cpu_idle+0xa/0x10 [ 4629.960539] [] cpu_startup_entry+0x2f9/0x330 [ 4629.960539] [] start_secondary+0x1c9/0x240 [ 4629.960539] Code: 57 41 56 41 89 ce 41 55 41 54 53 48 83 ec 08 83 f9 03 74 4c 45 31 e4 85 d2 49 89 ff 41 89 d5 48 89 f3 7e 2d 0f 1f 80 00 00 00 00 <8b> 53 18 44 89 f1 4c 89 ff 48 8b 73 10 41 83 c4 01 e8 8a ff ff [ 4629.960539] RIP [] swiotlb_unmap_sg_attrs+0x30/0x70 [ 4629.960539] RSP [ 4629.960539] CR2: 0018 PID: 0 TASK: 8804295c3040 CPU: 3 COMMAND: "swapper/3" #0 [88043fd839d0] machine_kexec at 8103484d #1 [88043fd83a20] crash_kexec at 810f3343 #2 [88043fd83af0] oops_end at 810063d8 #3 [88043fd83b20] no_context at 817f7b91 #4 [88043fd83b80] __bad_area_nosemaphore at 817f7f21 #5 [88043fd83be0] bad_area_nosemaphore at 817f7f4e #6 [88043fd83bf0] __do_page_fault at 8103b14e #7 [88043fd83d00] do_page_fault at 8103b413 #8 [88043fd83d30] page_fault at 818045e2 [exception RIP: swiotlb_unmap_sg_attrs+48] RIP: 814aa260 RSP: 88043fd83de8 RFLAGS: 00010002 RAX: 88042903b898 RBX: RCX: 0001 RDX: 0001 RSI: RDI: 88042903b898 RBP: 88043fd83e18 R8: R9: 814aa230 R10: R11: R12: R13: 0001 R14: 0001 R15: 88042903b898 ORIG_RAX: CS: 0010 SS: 0018 #9 [88043fd83e20] scsi_dma_unmap at 81580cb0 #10 [88043fd83e30] twa_unmap_scsi_data at 815d7cc9 #11 [88043fd83e40] twa_interrupt at 815d89e4 #12 [88043fd83eb0] handle_irq_event_percpu at 810ca004 #13 [88043fd83f00] handle_irq_event at 810ca19c #14 [88043fd83f30] handle_fasteoi_irq at 810ccde7 #15 [88043fd83f50] handle_irq at 81004ebd #16 [88043fd83f70] do_IRQ at 81004c19 --- --- #17 [8804295cfdd8] ret_from_intr at 818036aa [exception RIP: default_idle+23] RIP: 8100c597 RSP: 8804295cfe88 RFLAGS: 0246 RAX: 0008 RBX: 88043fd8cd40 RCX: 0100 RDX: ffed RSI: RDI: RBP: 8804295cfe98 R8: R9: R10: R11: R12: 0003 R13: 00013680 R14: 0086 R15: 88043fd8d760 ORIG_RAX: ff6e CS: 0010 SS: 0018 #18 [8804295cfea0] arch_cpu_idle at 8100ce0a #19 [8804295cfeb0] cpu_startup_entry at 810be259 #20 [8804295cff20]
[PATCH] rcutorture: Remove obsolete kversion param in kvm.sh
Now that we have removed configs based on kernel version, we can also remove the
kversion parameter in kvm.sh.
Signed-off-by: Pranith Kumar
---
.../selftests/rcutorture/bin/kvm-test-1-run.sh| 2 +-
tools/testing/selftests/rcutorture/bin/kvm.sh | 19 +--
2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
b/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
index e0f8969..8ca9f21 100755
--- a/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
+++ b/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
@@ -45,7 +45,7 @@ trap 'rm -rf $T' 0
touch $T
. $KVM/bin/functions.sh
-. $KVPATH/ver_functions.sh
+. $CONFIGFRAG/ver_functions.sh
config_template=${1}
config_dir=`echo $config_template | sed -e 's,/[^/]*$,,'`
diff --git a/tools/testing/selftests/rcutorture/bin/kvm.sh
b/tools/testing/selftests/rcutorture/bin/kvm.sh
index e527dc9..368d64a 100755
--- a/tools/testing/selftests/rcutorture/bin/kvm.sh
+++ b/tools/testing/selftests/rcutorture/bin/kvm.sh
@@ -47,7 +47,6 @@ resdir=""
configs=""
cpus=0
ds=`date +%Y.%m.%d-%H:%M:%S`
-kversion=""
. functions.sh
@@ -64,7 +63,6 @@ usage () {
echo " --duration minutes"
echo " --interactive"
echo " --kmake-arg kernel-make-arguments"
- echo " --kversion vN.NN"
echo " --mac nn:nn:nn:nn:nn:nn"
echo " --no-initrd"
echo " --qemu-args qemu-system-..."
@@ -128,11 +126,6 @@ do
TORTURE_KMAKE_ARG="$2"
shift
;;
- --kversion)
- checkarg --kversion "(kernel version)" $# "$2" '^v[0-9.]*$'
'^error'
- kversion=$2
- shift
- ;;
--mac)
checkarg --mac "(MAC address)" $# "$2"
'^\([0-9a-fA-F]\{2\}:\)\{5\}[0-9a-fA-F]\{2\}$' error
TORTURE_QEMU_MAC=$2
@@ -170,11 +163,10 @@ do
done
CONFIGFRAG=${KVM}/configs/${TORTURE_SUITE}; export CONFIGFRAG
-KVPATH=${CONFIGFRAG}/$kversion; export KVPATH
if test -z "$configs"
then
- configs="`cat $CONFIGFRAG/$kversion/CFLIST`"
+ configs="`cat $CONFIGFRAG/CFLIST`"
fi
if test -z "$resdir"
@@ -186,10 +178,10 @@ fi
touch $T/cfgcpu
for CF in $configs
do
- if test -f "$CONFIGFRAG/$kversion/$CF"
+ if test -f "$CONFIGFRAG/$CF"
then
- cpu_count=`configNR_CPUS.sh $CONFIGFRAG/$kversion/$CF`
- cpu_count=`configfrag_boot_cpus "$TORTURE_BOOTARGS"
"$CONFIGFRAG/$kversion/$CF" "$cpu_count"`
+ cpu_count=`configNR_CPUS.sh $CONFIGFRAG/$CF`
+ cpu_count=`configfrag_boot_cpus "$TORTURE_BOOTARGS"
"$CONFIGFRAG/$CF" "$cpu_count"`
echo $CF $cpu_count >> $T/cfgcpu
else
echo "The --configs file $CF does not exist, terminating."
@@ -252,7 +244,6 @@ END {
cat << ___EOF___ > $T/script
CONFIGFRAG="$CONFIGFRAG"; export CONFIGFRAG
KVM="$KVM"; export KVM
-KVPATH="$KVPATH"; export KVPATH
PATH="$PATH"; export PATH
TORTURE_BOOT_IMAGE="$TORTURE_BOOT_IMAGE"; export TORTURE_BOOT_IMAGE
TORTURE_BUILDONLY="$TORTURE_BUILDONLY"; export TORTURE_BUILDONLY
@@ -285,7 +276,7 @@ then
fi
___EOF___
awk < $T/cfgcpu.pack \
- -v CONFIGDIR="$CONFIGFRAG/$kversion/" \
+ -v CONFIGDIR="$CONFIGFRAG/" \
-v KVM="$KVM" \
-v ncpus=$cpus \
-v rd=$resdir/$ds/ \
--
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] rcutorture: Remove stale test configurations
2014-10-04 6:56 GMT-04:00 Paul E. McKenney : > On Thu, Oct 02, 2014 at 11:33:48PM -0400, Pranith Kumar wrote: >> Remove rcutorture configuration files which are no longer necessary. >> >> Signed-off-by: Pranith Kumar > > Queued for 3.19, thank you! > > The --kversion argument to the .../rcutorture/bin/kvm.sh script is > not obsolete. Would you be willing to remove it along with the > "kversion" shell variable that it controls? > Sure, I will remove this and send you a patch. Thanks! -- Pranith -- 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] mips: Convert pr_warning to pr_warn
Use the much more common pr_warn instead of pr_warning
with the goal of removing pr_warning eventually.
Other miscellanea:
o Coalesce formats
o Realign arguments
Signed-off-by: Joe Perches
---
arch/mips/ar7/platform.c| 24 ++--
arch/mips/include/asm/octeon/cvmx-pow.h | 69 +
arch/mips/kernel/crash_dump.c | 4 +-
arch/mips/kernel/perf_event_mipsxx.c| 7 ++--
arch/mips/kernel/setup.c| 2 +-
arch/mips/pci/pci-tx4939.c | 2 +-
arch/mips/txx9/generic/setup_tx4927.c | 4 +-
arch/mips/txx9/generic/setup_tx4938.c | 4 +-
arch/mips/txx9/generic/setup_tx4939.c | 4 +-
9 files changed, 52 insertions(+), 68 deletions(-)
diff --git a/arch/mips/ar7/platform.c b/arch/mips/ar7/platform.c
index 7e2356f..af2441d 100644
--- a/arch/mips/ar7/platform.c
+++ b/arch/mips/ar7/platform.c
@@ -311,8 +311,7 @@ static void __init cpmac_get_mac(int instance, unsigned
char *dev_addr)
_addr[0], _addr[1],
_addr[2], _addr[3],
_addr[4], _addr[5]) != 6) {
- pr_warning("cannot parse mac address, "
- "using random address\n");
+ pr_warn("cannot parse mac address, using random
address\n");
eth_random_addr(dev_addr);
}
} else
@@ -665,7 +664,7 @@ static int __init ar7_register_devices(void)
res = platform_device_register(_flash);
if (res)
- pr_warning("unable to register physmap-flash: %d\n", res);
+ pr_warn("unable to register physmap-flash: %d\n", res);
if (ar7_is_titan())
titan_fixup_devices();
@@ -673,13 +672,13 @@ static int __init ar7_register_devices(void)
ar7_device_disable(vlynq_low_data.reset_bit);
res = platform_device_register(_low);
if (res)
- pr_warning("unable to register vlynq-low: %d\n", res);
+ pr_warn("unable to register vlynq-low: %d\n", res);
if (ar7_has_high_vlynq()) {
ar7_device_disable(vlynq_high_data.reset_bit);
res = platform_device_register(_high);
if (res)
- pr_warning("unable to register vlynq-high: %d\n", res);
+ pr_warn("unable to register vlynq-high: %d\n", res);
}
if (ar7_has_high_cpmac()) {
@@ -689,9 +688,10 @@ static int __init ar7_register_devices(void)
res = platform_device_register(_high);
if (res)
- pr_warning("unable to register cpmac-high:
%d\n", res);
+ pr_warn("unable to register cpmac-high: %d\n",
+ res);
} else
- pr_warning("unable to add cpmac-high phy: %d\n", res);
+ pr_warn("unable to add cpmac-high phy: %d\n", res);
} else
cpmac_low_data.phy_mask = 0x;
@@ -700,18 +700,18 @@ static int __init ar7_register_devices(void)
cpmac_get_mac(0, cpmac_low_data.dev_addr);
res = platform_device_register(_low);
if (res)
- pr_warning("unable to register cpmac-low: %d\n", res);
+ pr_warn("unable to register cpmac-low: %d\n", res);
} else
- pr_warning("unable to add cpmac-low phy: %d\n", res);
+ pr_warn("unable to add cpmac-low phy: %d\n", res);
detect_leds();
res = platform_device_register(_gpio_leds);
if (res)
- pr_warning("unable to register leds: %d\n", res);
+ pr_warn("unable to register leds: %d\n", res);
res = platform_device_register(_udc);
if (res)
- pr_warning("unable to register usb slave: %d\n", res);
+ pr_warn("unable to register usb slave: %d\n", res);
/* Register watchdog only if enabled in hardware */
bootcr = ioremap_nocache(AR7_REGS_DCL, 4);
@@ -726,7 +726,7 @@ static int __init ar7_register_devices(void)
ar7_wdt_res.end = ar7_wdt_res.start + 0x20;
res = platform_device_register(_wdt);
if (res)
- pr_warning("unable to register watchdog: %d\n", res);
+ pr_warn("unable to register watchdog: %d\n", res);
}
return 0;
diff --git a/arch/mips/include/asm/octeon/cvmx-pow.h
b/arch/mips/include/asm/octeon/cvmx-pow.h
index 4b4d0ec..2188e65 100644
--- a/arch/mips/include/asm/octeon/cvmx-pow.h
+++ b/arch/mips/include/asm/octeon/cvmx-pow.h
@@ -1066,7 +1066,7 @@ static inline void
__cvmx_pow_warn_if_pending_switch(const char *function)
uint64_t switch_complete;
CVMX_MF_CHORD(switch_complete);
if
(Song) Fk SystemD
youtu.be/JbRztcLaQa8 Fuck Systemd. It is passionless static, worthless. Only here to force us in a direction. And Linus Trovalds agrees 100% with that direction. But he never claimed to be brilliant nor have good taste in women nor be uncorruptable (got to keep that RedHat stock valuable) This was recorded in the morning Fuck Systemd. Fuck Lennart Poettering. -- 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] perf: fix for double free in tools/perf stat
Fix for double free bug in tools/perf due to dangling thread_map pointer in perf_evlist struct. Code path excercised when perf stat -C switch is used but not set and is followed by another switch. Example: perf stat -C -e. Signed-off-by: Yasser Shalabi --- tools/perf/util/evlist.c |1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c index 814e954..09af633 100644 --- a/tools/perf/util/evlist.c +++ b/tools/perf/util/evlist.c @@ -845,6 +845,7 @@ int perf_evlist__create_maps(struct perf_evlist *evlist, struct target *target) out_delete_threads: thread_map__delete(evlist->threads); + evlist->threads = 0; return -1; } -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf top: Add a visual cue for toggle zeroing of samples
When 'perf top' is run, one can't easily find a difference
between -z option and normal output.
So I added a visual cue to know whether it is the zeroing or not.
Signed-off-by: Taeung Song
---
tools/perf/PERF-FEATURES | 1 +
tools/perf/ui/browsers/hists.c | 34 --
2 files changed, 25 insertions(+), 10 deletions(-)
create mode 100644 tools/perf/PERF-FEATURES
diff --git a/tools/perf/PERF-FEATURES b/tools/perf/PERF-FEATURES
new file mode 100644
index 000..bf2723d
--- /dev/null
+++ b/tools/perf/PERF-FEATURES
@@ -0,0 +1 @@
+feature-dwarf(1) feature-glibc(1) feature-gtk2(0) feature-libaudit(1)
feature-libbfd(0) feature-libelf(1) feature-libnuma(1) feature-libperl(1)
feature-libpython(0) feature-libslang(1) feature-libunwind(1)
feature-libdw-dwarf-unwind(1) dwarf-post-unwind(libunwind)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 8f60a97..6af157c 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -35,7 +35,9 @@ struct hist_browser {
extern void hist_browser__init_hpp(void);
-static int hists__browser_title(struct hists *hists, char *bf, size_t size);
+static int hists__browser_title(struct hists *hists,
+ struct hist_browser_timer *hbt,
+ char *bf, size_t size);
static void hist_browser__update_nr_entries(struct hist_browser *hb);
static struct rb_node *hists__filter_entries(struct rb_node *nd,
@@ -390,7 +392,7 @@ static int hist_browser__run(struct hist_browser *browser,
browser->b.entries = >hists->entries;
browser->b.nr_entries = hist_browser__nr_entries(browser);
- hists__browser_title(browser->hists, title, sizeof(title));
+ hists__browser_title(browser->hists, hbt, title, sizeof(title));
if (ui_browser__show(>b, title,
"Press '?' for help on key bindings") < 0)
@@ -417,7 +419,8 @@ static int hist_browser__run(struct hist_browser *browser,
ui_browser__warn_lost_events(>b);
}
- hists__browser_title(browser->hists, title,
sizeof(title));
+ hists__browser_title(browser->hists,
+hbt, title, sizeof(title));
ui_browser__show_title(>b, title);
continue;
}
@@ -1204,7 +1207,16 @@ static struct thread
*hist_browser__selected_thread(struct hist_browser *browser
return browser->he_selection->thread;
}
-static int hists__browser_title(struct hists *hists, char *bf, size_t size)
+/* Check whether the browser is for 'top' or 'report' */
+static inline bool is_report_browser(void *timer)
+{
+ return timer == NULL;
+}
+
+static int hists__browser_title(struct hists *hists,
+ struct hist_browser_timer *hbt,
+ char *bf,
+ size_t size)
{
char unit;
int printed;
@@ -1256,6 +1268,14 @@ static int hists__browser_title(struct hists *hists,
char *bf, size_t size)
if (dso)
printed += scnprintf(bf + printed, size - printed,
", DSO: %s", dso->short_name);
+ if (!is_report_browser(hbt)) {
+ struct perf_top *top = hbt->arg;
+
+ if (top->zero)
+ printed += scnprintf(bf + printed, size - printed,
+", [z]", "");
+ }
+
return printed;
}
@@ -1267,12 +1287,6 @@ static inline void free_popup_options(char **options,
int n)
zfree([i]);
}
-/* Check whether the browser is for 'top' or 'report' */
-static inline bool is_report_browser(void *timer)
-{
- return timer == NULL;
-}
-
/*
* Only runtime switching of perf data file will make "input_name" point
* to a malloced buffer. So add "is_input_name_malloced" flag to decide
--
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/3] MIPS executable stack protection
On Sat, Oct 4, 2014 at 9:17 AM, Leonid Yegoshin wrote: > Linus, it works on CPU with hardware page table walker - MIPS P5600 aka > Apache. > > I was involved in architecture development of HTW and took care of it. Ok, as long as it works architecturally, per-thread TLB fills are fine by me. Linus -- 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/3] MIPS executable stack protection
Linus, it works on CPU with hardware page table walker - MIPS P5600 aka Apache. I was involved in architecture development of HTW and took care of it. Linus Torvalds wrote: On Sat, Oct 4, 2014 at 1:23 AM, Peter Zijlstra wrote: > On Fri, Oct 03, 2014 at 08:17:14PM -0700, Leonid Yegoshin wrote: >> The following series implements an executable stack protection in MIPS. >> >> It sets up a per-thread 'VDSO' page and appropriate TLB support. > > So traditionally we've always avoided per-thread pages like that. What > makes it worth it on MIPS? Nothing makes it worth it on MIPS. It may be easy to implement when you have all software-fill of TLB's, but it's a mistake even then - because it means that you'll never be able to do hardware TLB walkers. And MIPS *does* have hardware TLB walkers, even if they are not necessarily available everywhere. So this is a horrible idea. Don't do it. Page tables need to be per-process, not per thread, so that page tables can be shared. Linus -- 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] perf top: Add a visual cue for toggle zeroing of samples
When 'perf top' is run, one can't easily find a difference
between -z option and normal output.
So I added a visual cue to know whether it is the zeroing or not.
Signed-off-by: Taeung Song
---
tools/perf/ui/browsers/hists.c | 38 ++
1 file changed, 26 insertions(+), 12 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 8f60a97..be49363 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -35,7 +35,9 @@ struct hist_browser {
extern void hist_browser__init_hpp(void);
-static int hists__browser_title(struct hists *hists, char *bf, size_t size);
+static int hists__browser_title(struct hists *hists,
+ struct hist_browser_timer *hbt,
+ char *bf, size_t size);
static void hist_browser__update_nr_entries(struct hist_browser *hb);
static struct rb_node *hists__filter_entries(struct rb_node *nd,
@@ -390,7 +392,7 @@ static int hist_browser__run(struct hist_browser *browser,
browser->b.entries = >hists->entries;
browser->b.nr_entries = hist_browser__nr_entries(browser);
- hists__browser_title(browser->hists, title, sizeof(title));
+ hists__browser_title(browser->hists, hbt, title, sizeof(title));
if (ui_browser__show(>b, title,
"Press '?' for help on key bindings") < 0)
@@ -417,7 +419,8 @@ static int hist_browser__run(struct hist_browser *browser,
ui_browser__warn_lost_events(>b);
}
- hists__browser_title(browser->hists, title,
sizeof(title));
+ hists__browser_title(browser->hists,
+hbt, title, sizeof(title));
ui_browser__show_title(>b, title);
continue;
}
@@ -1204,7 +1207,16 @@ static struct thread
*hist_browser__selected_thread(struct hist_browser *browser
return browser->he_selection->thread;
}
-static int hists__browser_title(struct hists *hists, char *bf, size_t size)
+/* Check whether the browser is for 'top' or 'report' */
+static inline bool is_report_browser(void *timer)
+{
+ return timer == NULL;
+}
+
+static int hists__browser_title(struct hists *hists,
+ struct hist_browser_timer *hbt,
+ char *bf,
+ size_t size)
{
char unit;
int printed;
@@ -1241,7 +1253,7 @@ static int hists__browser_title(struct hists *hists, char
*bf, size_t size)
nr_samples = convert_unit(nr_samples, );
printed = scnprintf(bf, size,
- "Samples: %lu%c of event '%s', Event count
(approx.): %lu",
+ "Samples: %lu%c of event z'%s', Event count
(approx.): %lu",
nr_samples, unit, ev_name, nr_events);
@@ -1255,7 +1267,15 @@ static int hists__browser_title(struct hists *hists,
char *bf, size_t size)
thread->tid);
if (dso)
printed += scnprintf(bf + printed, size - printed,
- ", DSO: %s", dso->short_name);
+", DSO: %s", dso->short_name);
+ if (!is_report_browser(hbt)) {
+ struct perf_top *top = hbt->arg;
+
+ if (top->zero)
+ printed += scnprintf(bf + printed, size - printed,
+", [z]", "");
+ }
+
return printed;
}
@@ -1267,12 +1287,6 @@ static inline void free_popup_options(char **options,
int n)
zfree([i]);
}
-/* Check whether the browser is for 'top' or 'report' */
-static inline bool is_report_browser(void *timer)
-{
- return timer == NULL;
-}
-
/*
* Only runtime switching of perf data file will make "input_name" point
* to a malloced buffer. So add "is_input_name_malloced" flag to decide
--
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/3] MIPS executable stack protection
On Sat, Oct 4, 2014 at 1:23 AM, Peter Zijlstra wrote: > On Fri, Oct 03, 2014 at 08:17:14PM -0700, Leonid Yegoshin wrote: >> The following series implements an executable stack protection in MIPS. >> >> It sets up a per-thread 'VDSO' page and appropriate TLB support. > > So traditionally we've always avoided per-thread pages like that. What > makes it worth it on MIPS? Nothing makes it worth it on MIPS. It may be easy to implement when you have all software-fill of TLB's, but it's a mistake even then - because it means that you'll never be able to do hardware TLB walkers. And MIPS *does* have hardware TLB walkers, even if they are not necessarily available everywhere. So this is a horrible idea. Don't do it. Page tables need to be per-process, not per thread, so that page tables can be shared. Linus -- 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: base: power: domain: Use 'pm_cpu_data' instead of 'cpu_data' for compiling break
On Sat, Oct 04, 2014 at 10:19:50PM +0800, Chen Gang wrote:
> 'cpu_data' is too common to be already used by some architectures (e.g.
> um, m32r, and mn10300), so need use 'pm_cpu_data' instead of, or cause
> compiling break. The related error (with allmodconfig under um):
>
> CC drivers/base/platform.o
> In file included from ./arch/x86/um/asm/processor.h:31:0,
>from ./arch/um/include/asm/uaccess.h:16,
>from ./arch/um/include/asm/thread_info.h:13,
>from include/linux/thread_info.h:54,
>from include/asm-generic/current.h:4,
>from arch/um/include/generated/asm/current.h:1,
>from include/linux/mutex.h:13,
>from include/linux/kernfs.h:13,
>from include/linux/sysfs.h:15,
>from include/linux/kobject.h:21,
>from include/linux/device.h:17,
>from include/linux/platform_device.h:14,
>from drivers/base/platform.c:14:
> ./arch/um/include/asm/processor-generic.h:107:19: error: expected
> identifier or '(' before '&' token
>#define cpu_data (_cpu_data)
> ^
> include/linux/pm_domain.h:74:23: note: in expansion of macro 'cpu_data'
> struct gpd_cpu_data *cpu_data;
>^
>
> Also need notice about 80 columns boundary.
I don't object to this change at all, but it could be easier to solve
this by fixing up 'cpu_data' to be named something a bit less "generic"?
What does x86 use for this data type?
thanks,
greg k-h
--
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/3] MIPS executable stack protection
Peter Zijlstra wrote:
>> It sets up a per-thread 'VDSO' page and appropriate TLB support.
> So traditionally we've always avoided per-thread pages like that.
> What makes it worth it on MIPS?
MIPS has branch delay slots - it is an instruction after branch which is
executed
before branch is taken. If branch fails due to FPU unavailability then that
instruction should be emulated as well as branch itself.
However, MIPS allows to have a customisable coprocessor 2 instructions
and it is impractical to emulate it and big amount of other traditional MIPS
instructions inside of kernel.
So, some per thread space is needed to put instruction into it, enclose it with
a return kernel call and switch temporary execution into it.
Currently, this space is space at SP register (user stack) but it prevents
switching stack as non-executable.
Handle another stack set (one stack per thread) in common user map is
impractical because of management, scalability and performance difficulties.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [RFC 1/1] net: fix rcu access on phonet_routes
On Sat, 2014-10-04 at 11:57 +0200, Fabian Frederick wrote:
> -Add __rcu annotation on table to fix sparse warnings:
> net/phonet/pn_dev.c:279:25: warning: incorrect type in assignment (different
> address spaces)
> net/phonet/pn_dev.c:279:25:expected struct net_device *
> net/phonet/pn_dev.c:279:25:got void [noderef] *
> net/phonet/pn_dev.c:376:17: warning: incorrect type in assignment (different
> address spaces)
> net/phonet/pn_dev.c:376:17:expected struct net_device *volatile
> net/phonet/pn_dev.c:376:17:got struct net_device [noderef]
> *
> net/phonet/pn_dev.c:392:17: warning: incorrect type in assignment (different
> address spaces)
> net/phonet/pn_dev.c:392:17:expected struct net_device *
> net/phonet/pn_dev.c:392:17:got void [noderef] *
>
> -Access table with rcu_dereference (fixes the following sparse errors):
> net/phonet/pn_dev.c:278:25: error: incompatible types in comparison
> expression (different address spaces)
> net/phonet/pn_dev.c:391:17: error: incompatible types in comparison
> expression (different address spaces)
>
> Signed-off-by: Fabian Frederick
> ---
> net/phonet/pn_dev.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/net/phonet/pn_dev.c b/net/phonet/pn_dev.c
> index 56a6146..5c9c0b2f1 100644
> --- a/net/phonet/pn_dev.c
> +++ b/net/phonet/pn_dev.c
> @@ -36,7 +36,7 @@
>
> struct phonet_routes {
> struct mutexlock;
> - struct net_device *table[64];
> + struct net_device __rcu *table[64];
> };
>
> struct phonet_net {
> @@ -275,7 +275,7 @@ static void phonet_route_autodel(struct net_device *dev)
> bitmap_zero(deleted, 64);
> mutex_lock(>routes.lock);
> for (i = 0; i < 64; i++)
> - if (dev == pnn->routes.table[i]) {
> + if (rcu_dereference(pnn->routes.table[i]) == dev) {
> RCU_INIT_POINTER(pnn->routes.table[i], NULL);
> set_bit(i, deleted);
> }
> @@ -388,7 +388,7 @@ int phonet_route_del(struct net_device *dev, u8 daddr)
>
> daddr = daddr >> 2;
> mutex_lock(>lock);
> - if (dev == routes->table[daddr])
> + if (rcu_dereference(routes->table[daddr]) == dev)
> RCU_INIT_POINTER(routes->table[daddr], NULL);
> else
> dev = NULL;
Hi Fabian
Have you tested this running the kernel with following config options :
CONFIG_LOCKDEP=y
CONFIG_PROVE_RCU=y
LOCKDEP should complain loudly, if not, we should file a bug !
Hint : Use rcu_access_pointer(), and check that LOCKDEP is happy with
that.
Thanks !
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Slowdown due to threads bouncing between HT cores
On Fri, 3 Oct 2014 21:44:29 +0200 "Steinar H. Gunderson" wrote: > Hi, > > I did a chess benchmark of my new machine (2x E5-2650v3, so 20x2.3GHz > Haswell-EP), and it performed a bit worse than comparable Windows setups. > It looks like the scheduler somehow doesn't perform as well with > hyperthreading; HT is on in the BIOS, but I'm only using 20 threads > (chess scales sublinearly, so using all 40 usually isn't a good idea), > so really, the threads should just get one core each and that's it. > It looks like they are bouncing between cores, reducing overall performance > by ~20% for some reason. (The machine is otherwise generally idle.) > Try playing with /proc/sys/kernel/sched_migration_cost_ns. This sets the number of nanoseconds the kernel will wait before considering moving a thread to another CPU. I have mine set to 5000. -- 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: base: power: domain: Use 'pm_cpu_data' instead of 'cpu_data' for compiling break
'cpu_data' is too common to be already used by some architectures (e.g.
um, m32r, and mn10300), so need use 'pm_cpu_data' instead of, or cause
compiling break. The related error (with allmodconfig under um):
CC drivers/base/platform.o
In file included from ./arch/x86/um/asm/processor.h:31:0,
from ./arch/um/include/asm/uaccess.h:16,
from ./arch/um/include/asm/thread_info.h:13,
from include/linux/thread_info.h:54,
from include/asm-generic/current.h:4,
from arch/um/include/generated/asm/current.h:1,
from include/linux/mutex.h:13,
from include/linux/kernfs.h:13,
from include/linux/sysfs.h:15,
from include/linux/kobject.h:21,
from include/linux/device.h:17,
from include/linux/platform_device.h:14,
from drivers/base/platform.c:14:
./arch/um/include/asm/processor-generic.h:107:19: error: expected identifier
or '(' before '&' token
#define cpu_data (_cpu_data)
^
include/linux/pm_domain.h:74:23: note: in expansion of macro 'cpu_data'
struct gpd_cpu_data *cpu_data;
^
Also need notice about 80 columns boundary.
Signed-off-by: Chen Gang
---
drivers/base/power/domain.c | 54 ++---
include/linux/pm_domain.h | 2 +-
2 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 18cc68d..d8d2739 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -142,13 +142,13 @@ static void genpd_recalc_cpu_exit_latency(struct
generic_pm_domain *genpd)
{
s64 usecs64;
- if (!genpd->cpu_data)
+ if (!genpd->pm_cpu_data)
return;
usecs64 = genpd->power_on_latency_ns;
do_div(usecs64, NSEC_PER_USEC);
- usecs64 += genpd->cpu_data->saved_exit_latency;
- genpd->cpu_data->idle_state->exit_latency = usecs64;
+ usecs64 += genpd->pm_cpu_data->saved_exit_latency;
+ genpd->pm_cpu_data->idle_state->exit_latency = usecs64;
}
/**
@@ -188,9 +188,9 @@ static int __pm_genpd_poweron(struct generic_pm_domain
*genpd)
return 0;
}
- if (genpd->cpu_data) {
+ if (genpd->pm_cpu_data) {
cpuidle_pause_and_lock();
- genpd->cpu_data->idle_state->disabled = true;
+ genpd->pm_cpu_data->idle_state->disabled = true;
cpuidle_resume_and_unlock();
goto out;
}
@@ -513,17 +513,17 @@ static int pm_genpd_poweroff(struct generic_pm_domain
*genpd)
}
}
- if (genpd->cpu_data) {
+ if (genpd->pm_cpu_data) {
/*
-* If cpu_data is set, cpuidle should turn the domain off when
-* the CPU in it is idle. In that case we don't decrement the
-* subdomain counts of the master domains, so that power is not
-* removed from the current domain prematurely as a result of
-* cutting off the masters' power.
+* If pm_cpu_data is set, cpuidle should turn the domain off
+* when the CPU in it is idle. In that case we don't decrement
+* the subdomain counts of the master domains, so that power is
+* not removed from the current domain prematurely as a result
+* of cutting off the masters' power.
*/
genpd->status = GPD_STATE_POWER_OFF;
cpuidle_pause_and_lock();
- genpd->cpu_data->idle_state->disabled = false;
+ genpd->pm_cpu_data->idle_state->disabled = false;
cpuidle_resume_and_unlock();
goto out;
}
@@ -1698,7 +1698,7 @@ int pm_genpd_remove_subdomain(struct generic_pm_domain
*genpd,
int pm_genpd_attach_cpuidle(struct generic_pm_domain *genpd, int state)
{
struct cpuidle_driver *cpuidle_drv;
- struct gpd_cpu_data *cpu_data;
+ struct gpd_cpu_data *pm_cpu_data;
struct cpuidle_state *idle_state;
int ret = 0;
@@ -1707,12 +1707,12 @@ int pm_genpd_attach_cpuidle(struct generic_pm_domain
*genpd, int state)
genpd_acquire_lock(genpd);
- if (genpd->cpu_data) {
+ if (genpd->pm_cpu_data) {
ret = -EEXIST;
goto out;
}
- cpu_data = kzalloc(sizeof(*cpu_data), GFP_KERNEL);
- if (!cpu_data) {
+ pm_cpu_data = kzalloc(sizeof(*pm_cpu_data), GFP_KERNEL);
+ if (!pm_cpu_data) {
ret = -ENOMEM;
goto out;
}
@@ -1730,9 +1730,9 @@ int pm_genpd_attach_cpuidle(struct generic_pm_domain
*genpd, int state)
ret = -EAGAIN;
goto err;
}
- cpu_data->idle_state =
Re: [PATCH] drivers: base: power: domain: Use 'pm_cpu_data' instead of 'cpu_data' for compiling break
After this patch, our um can pass allmodconfig compiling.
Thanks.
On 10/4/14 22:19, Chen Gang wrote:
> 'cpu_data' is too common to be already used by some architectures (e.g.
> um, m32r, and mn10300), so need use 'pm_cpu_data' instead of, or cause
> compiling break. The related error (with allmodconfig under um):
>
> CC drivers/base/platform.o
> In file included from ./arch/x86/um/asm/processor.h:31:0,
>from ./arch/um/include/asm/uaccess.h:16,
>from ./arch/um/include/asm/thread_info.h:13,
>from include/linux/thread_info.h:54,
>from include/asm-generic/current.h:4,
>from arch/um/include/generated/asm/current.h:1,
>from include/linux/mutex.h:13,
>from include/linux/kernfs.h:13,
>from include/linux/sysfs.h:15,
>from include/linux/kobject.h:21,
>from include/linux/device.h:17,
>from include/linux/platform_device.h:14,
>from drivers/base/platform.c:14:
> ./arch/um/include/asm/processor-generic.h:107:19: error: expected
> identifier or '(' before '&' token
>#define cpu_data (_cpu_data)
> ^
> include/linux/pm_domain.h:74:23: note: in expansion of macro 'cpu_data'
> struct gpd_cpu_data *cpu_data;
>^
>
> Also need notice about 80 columns boundary.
>
>
> Signed-off-by: Chen Gang
> ---
> drivers/base/power/domain.c | 54
> ++---
> include/linux/pm_domain.h | 2 +-
> 2 files changed, 28 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 18cc68d..d8d2739 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -142,13 +142,13 @@ static void genpd_recalc_cpu_exit_latency(struct
> generic_pm_domain *genpd)
> {
> s64 usecs64;
>
> - if (!genpd->cpu_data)
> + if (!genpd->pm_cpu_data)
> return;
>
> usecs64 = genpd->power_on_latency_ns;
> do_div(usecs64, NSEC_PER_USEC);
> - usecs64 += genpd->cpu_data->saved_exit_latency;
> - genpd->cpu_data->idle_state->exit_latency = usecs64;
> + usecs64 += genpd->pm_cpu_data->saved_exit_latency;
> + genpd->pm_cpu_data->idle_state->exit_latency = usecs64;
> }
>
> /**
> @@ -188,9 +188,9 @@ static int __pm_genpd_poweron(struct generic_pm_domain
> *genpd)
> return 0;
> }
>
> - if (genpd->cpu_data) {
> + if (genpd->pm_cpu_data) {
> cpuidle_pause_and_lock();
> - genpd->cpu_data->idle_state->disabled = true;
> + genpd->pm_cpu_data->idle_state->disabled = true;
> cpuidle_resume_and_unlock();
> goto out;
> }
> @@ -513,17 +513,17 @@ static int pm_genpd_poweroff(struct generic_pm_domain
> *genpd)
> }
> }
>
> - if (genpd->cpu_data) {
> + if (genpd->pm_cpu_data) {
> /*
> - * If cpu_data is set, cpuidle should turn the domain off when
> - * the CPU in it is idle. In that case we don't decrement the
> - * subdomain counts of the master domains, so that power is not
> - * removed from the current domain prematurely as a result of
> - * cutting off the masters' power.
> + * If pm_cpu_data is set, cpuidle should turn the domain off
> + * when the CPU in it is idle. In that case we don't decrement
> + * the subdomain counts of the master domains, so that power is
> + * not removed from the current domain prematurely as a result
> + * of cutting off the masters' power.
>*/
> genpd->status = GPD_STATE_POWER_OFF;
> cpuidle_pause_and_lock();
> - genpd->cpu_data->idle_state->disabled = false;
> + genpd->pm_cpu_data->idle_state->disabled = false;
> cpuidle_resume_and_unlock();
> goto out;
> }
> @@ -1698,7 +1698,7 @@ int pm_genpd_remove_subdomain(struct generic_pm_domain
> *genpd,
> int pm_genpd_attach_cpuidle(struct generic_pm_domain *genpd, int state)
> {
> struct cpuidle_driver *cpuidle_drv;
> - struct gpd_cpu_data *cpu_data;
> + struct gpd_cpu_data *pm_cpu_data;
> struct cpuidle_state *idle_state;
> int ret = 0;
>
> @@ -1707,12 +1707,12 @@ int pm_genpd_attach_cpuidle(struct generic_pm_domain
> *genpd, int state)
>
> genpd_acquire_lock(genpd);
>
> - if (genpd->cpu_data) {
> + if (genpd->pm_cpu_data) {
> ret = -EEXIST;
> goto out;
> }
> - cpu_data = kzalloc(sizeof(*cpu_data), GFP_KERNEL);
> - if (!cpu_data) {
> + pm_cpu_data = kzalloc(sizeof(*pm_cpu_data), GFP_KERNEL);
> + if (!pm_cpu_data) {
> ret = -ENOMEM;
>
Re: Slowdown due to threads bouncing between HT cores
On Sat, Oct 04, 2014 at 06:41:15AM -0700, Andi Kleen wrote: > - something else gets scheduled on these logical CPUs, so > the scheduler tries to balance to run queue lengths > > You could check that with perf timechart or perf sched record/map > or kernelshark. I've never read any of these maps before, but perf sched map really doesn't indicate to me that there's a lot of other stuff going on. It seems to mainly show a lot of Stockfish processes bouncing around seemingly randomly with not much understanding of hyperthread pairs. Of course, there's the odd other job, including ksoftirq or an RCU process. I can send you a copy of the map if you want to, but it is of course rather large. > - there is some IO or communication which causes wakeup affinity. There's a fair amount of communication between the threads; I don't know the architecture very deeply (multithreading in chess is rather nontrivial), but as far as I know, the worker threads access shared data through shm, sometimes using pthread mutexes to lock some of it. This also means, by the way, that occasionally they will sleep. They're not by default going to hog the CPU 100% of the time, more like 90%. > You could try disabling WAKEUP_PREEMPTION or NEXT_BUDDY in > /sys/kernel/debug/sched_features NO_NEXT_BUDDY was already set. (Changing it to NEXT_BUDDY didn't seem to help anything.) I tried setting NO_WAKEUP_PREEMPTION, and it didn't make a difference that I could see; they still bounce around a lot. /* Steinar */ -- Homepage: http://www.sesse.net/ -- 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] mfd: stmpe: fix STMPE24xx GPMR LSB
The least significat byte of the GPIO value read register on the STMPE24xx series is on addres 0xA4 not 0xA5. Correct against datasheet and tested on the STMPE2401 hardware. Signed-off-by: Linus Walleij --- Hi Lee, Sam: this should go in for fixes I think. --- drivers/mfd/stmpe.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mfd/stmpe.h b/drivers/mfd/stmpe.h index 2d045f26f193..bee0abf82040 100644 --- a/drivers/mfd/stmpe.h +++ b/drivers/mfd/stmpe.h @@ -269,7 +269,7 @@ int stmpe_remove(struct stmpe *stmpe); #define STMPE24XX_REG_CHIP_ID 0x80 #define STMPE24XX_REG_IEGPIOR_LSB 0x18 #define STMPE24XX_REG_ISGPIOR_MSB 0x19 -#define STMPE24XX_REG_GPMR_LSB 0xA5 +#define STMPE24XX_REG_GPMR_LSB 0xA4 #define STMPE24XX_REG_GPSR_LSB 0x85 #define STMPE24XX_REG_GPCR_LSB 0x88 #define STMPE24XX_REG_GPDR_LSB 0x8B -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[perf] BUG: unable to handle kernel NULL pointer dereference at 00000085
Hi Peter, 0day kernel testing robot got the below dmesg and the first bad commit is git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git perf/core commit a54b3e27e27c1bb6d2610eade895c04934c2667e Author: Peter Zijlstra AuthorDate: Wed Sep 24 13:48:42 2014 +0200 Commit: Peter Zijlstra CommitDate: Thu Oct 2 23:11:50 2014 +0200 perf: improve perf_sample_data struct layout This patch reorders fields in the perf_sample_data struct in order to minimize the number of cachelines touched in perf_sample_data_init(). It also removes some intializations which are redundant with the code in kernel/events/core.c Cc: mi...@elte.hu Cc: a...@linux.intel.com Cc: jo...@redhat.com Cc: a...@redhat.com Cc: cebbert.l...@gmail.com Cc: pet...@infradead.org Signed-off-by: Peter Zijlstra (Intel) Link: http://lkml.kernel.org/r/1411559322-16548-7-git-send-email-eran...@google.com Attached dmesg for the parent commit, too, to help confirm whether it is a noise error. +---+++--+ | | da2ff6572c | a54b3e27e2 | v3.17-rc7_100306 | +---+++--+ | boot_successes| 886| 227 | 18 | | boot_failures | 314| 73 | 4| | BUG:kernel_boot_hang | 295| 52 | | | WARNING:at_fs/proc/generic.c:remove_proc_entry() | 16 | 8 | | | backtrace:cleanup_net | 16 | 8 | | | BUG:kernel_test_crashed | 4 | 9 | 1| | BUG:unable_to_handle_kernel | 0 | 4 | 2| | Oops | 0 | 4 | 2| | EIP_is_at_perf_prepare_sample | 0 | 4 | 2| | Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 0 | 3 | 2| | backtrace:iterate_dir | 0 | 2 | | | backtrace:SyS_getdents64 | 0 | 2 | | | backtrace:do_sys_open | 0 | 1 | | | backtrace:SyS_openat | 0 | 1 | | | backtrace:vfs_fstatat | 0 | 1 | 1| | backtrace:SyS_fstatat64 | 0 | 1 | 1| | Kernel_panic-not_syncing:Fatal_exception | 0 | 1 | | | BUG:kernel_boot_crashed | 0 | 0 | 1| | backtrace:__fdget_raw | 0 | 0 | 1| | backtrace:SyS_fcntl64 | 0 | 0 | 1| +---+++--+ [ 267.547006] debug: unmapping init [mem 0xc28f9000-0xc2b03fff] [ 267.694378] random: init urandom read with 4 bits of entropy available [ 279.465522] sock: process `trinity-main' is using obsolete setsockopt SO_BSDCOMPAT [ 285.269144] BUG: unable to handle kernel NULL pointer dereference at 0085 [ 285.273002] IP: [] perf_prepare_sample+0x33e/0x496 [ 285.276062] *pde = [ 285.279106] Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 285.279106] Modules linked in: [ 285.279106] CPU: 1 PID: 1583 Comm: trinity-main Not tainted 3.17.0-rc4-00210-ga54b3e2 #1 [ 285.279106] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014 [ 285.279106] task: c9475e80 ti: c967 task.ti: c967 [ 285.279106] EIP: 0060:[] EFLAGS: 00010046 CPU: 1 [ 285.279106] EIP is at perf_prepare_sample+0x33e/0x496 [ 285.279106] EAX: EBX: ECX: 0049 EDX: [ 285.279106] ESI: cfd71c40 EDI: cfd71b84 EBP: cfd71b58 ESP: cfd71b34 [ 285.279106] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 285.279106] CR0: 80050033 CR2: 0085 CR3: 095b4000 CR4: 06d0 [ 285.279106] DR0: 4143 DR1: DR2: DR3: [ 285.279106] DR6: 0ff0 DR7: 00010602 [ 285.279106] Stack: [ 285.279106] 0060 0003a16b c96860d0 c96860d0 [ 285.279106] cfd71bb0 c1125d87 cfd71da8 0002 c1125d59
Re: Slowdown due to threads bouncing between HT cores
"Steinar H. Gunderson" writes: > > So, benchmark: > > - Default: 13266 kN/sec > - Change from ondemand to performance on all cores: 14600 kN/sec > - taskset -c 0-19 (locking affinity to only one set of hyperthreads): >17512 kN/sec iirc the main reasons for unbound threads migrating away are: - something else gets scheduled on these logical CPUs, so the scheduler tries to balance to run queue lengths You could check that with perf timechart or perf sched record/map or kernelshark. - there is some IO or communication which causes wakeup affinity. You could try disabling WAKEUP_PREEMPTION or NEXT_BUDDY in /sys/kernel/debug/sched_features -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3 v3] drivers/bus: Device driver for FSL-MC DPRC devices
From: "J. German Rivera"
A DPRC (Data Path Resource Container) is an isolation device
that contains a set of DPAA networking devices to be
assigned to an isolation domain (e.g., a virtual machine).
Signed-off-by: J. German Rivera
Signed-off-by: Stuart Yoder
---
Changes in v3:
- Addressed comments from Kim Phillips:
* Renamed files:
drivers/bus/fsl-mc/fsl_mc_dprc.c -> drivers/bus/fsl-mc/dprc-driver.c
- Addressed comments from Timur Tabi:
* Changed dprc_scan_container() to just return dprc_scan_objects()
* Changed all functions that had goto out/error when no common cleanup
was done, to just have multiple return points.
* Replaced error cleanup boolean flags with multiple exit points.
* REmoved __must_chewck from dprc_scan_*() functions
Changes in v2:
- Addressed comments from Kim Phillips:
* Fix warning in drivers/bus/fsl-mc/fsl_mc_dprc.c:173
* Fixed linker errors when MC bus driver built as module
drivers/bus/fsl-mc/Makefile |3 +-
drivers/bus/fsl-mc/dprc-driver.c | 383 ++
drivers/bus/fsl-mc/mc-bus.c |8 +
include/linux/fsl/mc-private.h | 10 +
4 files changed, 403 insertions(+), 1 deletion(-)
create mode 100644 drivers/bus/fsl-mc/dprc-driver.c
diff --git a/drivers/bus/fsl-mc/Makefile b/drivers/bus/fsl-mc/Makefile
index decd339..424e58e 100644
--- a/drivers/bus/fsl-mc/Makefile
+++ b/drivers/bus/fsl-mc/Makefile
@@ -10,5 +10,6 @@ obj-$(CONFIG_FSL_MC_BUS) += mc-bus-driver.o
mc-bus-driver-objs := mc-bus.o \
mc-sys.o \
dprc.o \
- dpmng.o
+ dpmng.o \
+ dprc-driver.o
diff --git a/drivers/bus/fsl-mc/dprc-driver.c b/drivers/bus/fsl-mc/dprc-driver.c
new file mode 100644
index 000..8be6a2a
--- /dev/null
+++ b/drivers/bus/fsl-mc/dprc-driver.c
@@ -0,0 +1,383 @@
+/*
+ * Freescale daata path resource container (DPRC) driver
+ *
+ * Copyright (C) 2014 Freescale Semiconductor, Inc.
+ * Author: German Rivera
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include "dprc-cmd.h"
+
+struct dprc_child_objs {
+ int child_count;
+ struct dprc_obj_desc *child_array;
+};
+
+static int __fsl_mc_device_remove_if_not_in_mc(struct device *dev, void *data)
+{
+ int i;
+ struct dprc_child_objs *objs;
+ struct fsl_mc_device *mc_dev;
+
+ WARN_ON(dev == NULL);
+ WARN_ON(data == NULL);
+ mc_dev = to_fsl_mc_device(dev);
+ objs = data;
+
+ for (i = 0; i < objs->child_count; i++) {
+ struct dprc_obj_desc *obj_desc = >child_array[i];
+
+ if (strlen(obj_desc->type) != 0 &&
+ FSL_MC_DEVICE_MATCH(mc_dev, obj_desc))
+ break;
+ }
+
+ if (i == objs->child_count)
+ fsl_mc_device_remove(mc_dev);
+
+ return 0;
+}
+
+static int __fsl_mc_device_remove(struct device *dev, void *data)
+{
+ WARN_ON(dev == NULL);
+ WARN_ON(data != NULL);
+ fsl_mc_device_remove(to_fsl_mc_device(dev));
+ return 0;
+}
+
+/**
+ * dprc_remove_devices - Removes devices for objects removed from a DPRC
+ *
+ * @mc_bus_dev: pointer to the fsl-mc device that represents a DPRC object
+ * @obj_desc_array: array of object descriptors for child objects currently
+ * present in the DPRC in the MC.
+ * @num_child_objects_in_mc: number of entries in obj_desc_array
+ *
+ * Synchronizes the state of the Linux bus driver with the actual state of
+ * the MC by removing devices that represent MC objects that have
+ * been dynamically removed in the physical DPRC.
+ */
+static void dprc_remove_devices(struct fsl_mc_device *mc_bus_dev,
+ struct dprc_obj_desc *obj_desc_array,
+ int num_child_objects_in_mc)
+{
+ if (num_child_objects_in_mc != 0) {
+ /*
+* Remove child objects that are in the DPRC in Linux,
+* but not in the MC:
+*/
+ struct dprc_child_objs objs;
+
+ objs.child_count = num_child_objects_in_mc;
+ objs.child_array = obj_desc_array;
+ device_for_each_child(_bus_dev->dev, ,
+ __fsl_mc_device_remove_if_not_in_mc);
+ } else {
+ /*
+* There are no child objects for this DPRC in the MC.
+* So, remove all the child devices from Linux:
+*/
+ device_for_each_child(_bus_dev->dev, NULL,
+ __fsl_mc_device_remove);
+ }
+}
+
+static int __fsl_mc_device_match(struct device *dev, void *data)
+{
+ struct dprc_obj_desc *obj_desc = data;
+ struct fsl_mc_device *mc_dev =
[PATCH 2/3 v3] drivers/bus: Freescale Management Complex (fsl-mc) bus driver
From: "J. German Rivera"
Platform device driver that sets up the basic bus infrastructure
for the fsl-mc bus type, including support for adding/removing
fsl-mc devices, register/unregister of fsl-mc drivers, and bus
match support to bind devices to drivers.
Signed-off-by: J. German Rivera
Signed-off-by: Stuart Yoder
---
Changes in v3:
- Addressed changes from Kim Phillips:
* Renamed files:
drivers/bus/fsl-mc/fsl_mc_bus.c -> drivers/bus/fsl-mc/mc-bus.c
include/linux/fsl_mc.h -> include/linux/fsl/mc.h
include/linux/fsl_mc_private.h -> include/linux/fsl/mc-private.h
- Addressed comments from Timur Tabi:
* Changed all functions that had goto out/error when no common cleanup
was done, to just have multiple return points.
* Replaced error cleanup boolean flags with multiple exit points.
Changes in v2:
- Addressed comment from Joe Perches:
* Changed pr_debug to dev_dbg in fsl_mc_bus_match
- Addressed comments from Kim Phillips and Alex Graf:
* Changed version check to allow the driver to run with MC
firmware that has major version number greater than or equal
to the driver's major version number.
* Removed minor version check
- Removed unused variable parent_dev in fsl_mc_device_remove
drivers/bus/Kconfig|3 +
drivers/bus/Makefile |3 +
drivers/bus/fsl-mc/Kconfig | 13 +
drivers/bus/fsl-mc/Makefile| 14 +
drivers/bus/fsl-mc/mc-bus.c| 566
include/linux/fsl/mc-private.h | 33 +++
include/linux/fsl/mc.h | 137 ++
7 files changed, 769 insertions(+)
create mode 100644 drivers/bus/fsl-mc/Kconfig
create mode 100644 drivers/bus/fsl-mc/Makefile
create mode 100644 drivers/bus/fsl-mc/mc-bus.c
create mode 100644 include/linux/fsl/mc-private.h
create mode 100644 include/linux/fsl/mc.h
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 603eb1b..2fbb1fd 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -67,4 +67,7 @@ config VEXPRESS_CONFIG
help
Platform configuration infrastructure for the ARM Ltd.
Versatile Express.
+
+source "drivers/bus/fsl-mc/Kconfig"
+
endmenu
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index 2973c18..6abcab1 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -15,3 +15,6 @@ obj-$(CONFIG_ARM_CCI) += arm-cci.o
obj-$(CONFIG_ARM_CCN) += arm-ccn.o
obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o
+
+# Freescale Management Complex (MC) bus drivers
+obj-$(CONFIG_FSL_MC_BUS) += fsl-mc/
diff --git a/drivers/bus/fsl-mc/Kconfig b/drivers/bus/fsl-mc/Kconfig
new file mode 100644
index 000..e3226f9
--- /dev/null
+++ b/drivers/bus/fsl-mc/Kconfig
@@ -0,0 +1,13 @@
+#
+# Freescale Management Complex (MC) bus drivers
+#
+# Copyright (C) 2014 Freescale Semiconductor, Inc.
+#
+# This file is released under the GPLv2
+#
+
+config FSL_MC_BUS
+ tristate "Freescale Management Complex (MC) bus driver"
+ help
+ Driver to enable the bus infrastructure for the Freescale
+ QorIQ Management Complex.
diff --git a/drivers/bus/fsl-mc/Makefile b/drivers/bus/fsl-mc/Makefile
new file mode 100644
index 000..decd339
--- /dev/null
+++ b/drivers/bus/fsl-mc/Makefile
@@ -0,0 +1,14 @@
+#
+# Freescale Management Complex (MC) bus drivers
+#
+# Copyright (C) 2014 Freescale Semiconductor, Inc.
+#
+# This file is released under the GPLv2
+#
+obj-$(CONFIG_FSL_MC_BUS) += mc-bus-driver.o
+
+mc-bus-driver-objs := mc-bus.o \
+ mc-sys.o \
+ dprc.o \
+ dpmng.o
+
diff --git a/drivers/bus/fsl-mc/mc-bus.c b/drivers/bus/fsl-mc/mc-bus.c
new file mode 100644
index 000..d19fb18
--- /dev/null
+++ b/drivers/bus/fsl-mc/mc-bus.c
@@ -0,0 +1,566 @@
+/*
+ * Freescale Management Complex (MC) bus driver
+ *
+ * Copyright (C) 2014 Freescale Semiconductor, Inc.
+ * Author: German Rivera
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "dprc-cmd.h"
+
+static struct kmem_cache *mc_dev_cache;
+
+/**
+ * fsl_mc_bus_match - device to driver matching callback
+ * @dev: the MC object device structure to match against
+ * @drv: the device driver to search for matching MC object device id
+ * structures
+ *
+ * Returns 1 on success, 0 otherwise.
+ */
+static int fsl_mc_bus_match(struct device *dev, struct device_driver *drv)
+{
+ const struct fsl_mc_device_match_id *id;
+ struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
+ struct fsl_mc_driver *mc_drv = to_fsl_mc_driver(drv);
+ bool found = false;
+
+ if (mc_drv->match_id_table == NULL)
+ goto out;
+
+ /*
+* If the object is not 'plugged' don't
[PATCH 1/3 v3] drivers/bus: Added Freescale Management Complex APIs
From: "J. German Rivera" APIs to access the Management Complex (MC) hardware module of Freescale LS2 SoCs. This patch includes APIs to check the MC firmware version and to manipulate DPRC objects in the MC. Signed-off-by: J. German Rivera Signed-off-by: Stuart Yoder --- Changes in v3: - Addressed comment from Greg Kroah-Hartman: * Removed doxygen comments - Addressed comment from Scott Wood: * Replaced udelay() call with usleep_range() call in polling loop - Addressed comments from Kim Phillips: * Fixed license text in all files * Renamed files: drivers/bus/fsl-mc/fsl_dpmng_cmd.h -> drivers/bus/fsl-mc/dpmng-cmd.h drivers/bus/fsl-mc/fsl_dprc_cmd.h -> drivers/bus/fsl-mc/dprc-cmd.h drivers/bus/fsl-mc/fsl_mc_sys.c -> drivers/bus/fsl-mc/mc-sys.c include/linux/fsl_dpmng.h -> include/linux/fsl/dpmng.h include/linux/fsl_dprc.h -> include/linux/fsl/dprc.h include/linux/fsl_mc_cmd.h -> include/linux/fsl/mc-cmd.h include/linux/fsl_mc_sys.h -> include/linux/fsl/mc-sys.h * Changed dpmng_load_iop() to take the DMA address directly, instead of the image virtual address. * Removed if and WARN_ON that checks for NULL fsl_destroy_mc_io() * Removed locking from mc_send_command(). Now the caller of MC flib APIs is responsible for protecting concurrent accesses to the same MC portal. Changes in v2: - Addressed comment from Joe Perches: * Refactored logic to actively fail on err and proceed at the same indent level on success, for all functions in dprc.c and dpmng.c. - Addressed comments from Kim Phillips: * Fixed warning in mc_send_command * Changed serialization logic in mc_send_command() to only use spinlock_irqsave() when both threads and interrupt handlers concurrently access the same portal. * Changed switch to lookup table in mc_status_to_error() * Removed macros iowrite64(), ioread64(), ENOTSUP from fsl_mc_sys.h * Removed #ifdef side for FSL_MC_FIRMWARE in fsl_mc_cmd.h * Changed non-devm_ API calls to devm_ API calls and refactored fsl_create_mc_io()/fsl_destroy_mc_io() to simplify cleanup logic. - Addressed comments from Scott Wood: * Return -ENXIO instead of -EFAULT when ioremap_nocache() fails - Addressed comments from Alex Graf: * Added MAINTAINERS file entries for new files * Added dev param to fsl_create_mc_io(), to enable the use of devm_ APIs in this function and fsl_destroy_mc_io(). * Changed the value of the timeout for MC command completion to be a function of HZ instead of a hard-coded jiffies value. MAINTAINERS|8 + drivers/bus/fsl-mc/dpmng-cmd.h | 83 + drivers/bus/fsl-mc/dpmng.c | 94 + drivers/bus/fsl-mc/dprc-cmd.h | 545 +++ drivers/bus/fsl-mc/dprc.c | 521 ++ drivers/bus/fsl-mc/mc-sys.c| 189 ++ include/linux/fsl/dpmng.h | 121 ++ include/linux/fsl/dprc.h | 791 include/linux/fsl/mc-cmd.h | 169 + include/linux/fsl/mc-sys.h | 68 10 files changed, 2589 insertions(+) create mode 100644 drivers/bus/fsl-mc/dpmng-cmd.h create mode 100644 drivers/bus/fsl-mc/dpmng.c create mode 100644 drivers/bus/fsl-mc/dprc-cmd.h create mode 100644 drivers/bus/fsl-mc/dprc.c create mode 100644 drivers/bus/fsl-mc/mc-sys.c create mode 100644 include/linux/fsl/dpmng.h create mode 100644 include/linux/fsl/dprc.h create mode 100644 include/linux/fsl/mc-cmd.h create mode 100644 include/linux/fsl/mc-sys.h diff --git a/MAINTAINERS b/MAINTAINERS index 8fd05d4..907b50d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3874,6 +3874,14 @@ F: sound/soc/fsl/fsl* F: sound/soc/fsl/imx* F: sound/soc/fsl/mpc8610_hpcd.c +FREESCALE QORIQ MANAGEMENT COMPLEX DRIVER +M: J. German Rivera +L: linux-kernel@vger.kernel.org +S: Maintained +F: include/linux/fsl_mc* +F: include/linux/fsl_dp* +F: drivers/bus/fsl-mc/* + FREEVXFS FILESYSTEM M: Christoph Hellwig W: ftp://ftp.openlinux.org/pub/people/hch/vxfs diff --git a/drivers/bus/fsl-mc/dpmng-cmd.h b/drivers/bus/fsl-mc/dpmng-cmd.h new file mode 100644 index 000..cdeaa16 --- /dev/null +++ b/drivers/bus/fsl-mc/dpmng-cmd.h @@ -0,0 +1,83 @@ +/* Copyright 2013-2014 Freescale Semiconductor Inc. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions are met: + * * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * * Neither the name of the above-listed copyright holders nor the + * names of any
[PATCH 0/3 v3] drivers/bus: Freescale Management Complex bus driver patch series
This patch series introduces Linux support for the Freescale Management Complex (fsl-mc) hardware. This patch series is dependent on the patch series "ARM64: Add support for FSL's LS2085A SoC" (http://thread.gmane.org/gmane.linux.ports.arm.kernel/351829) The fsl-mc is a hardware resource manager that manages specialized hardware objects used in network-oriented packet processing applications. After the fsl-mc block is enabled, pools of hardware resources are available, such as queues, buffer poools, I/O interfaces. These resources are building blocks that can be used to create functional hardware objects such as network interfaces, crypto accelerator instances, or L2 switches. All the fsl-mc managed hardware resources/objects are represented in a physical grouping mechanism called a 'container' or DPRC (data path resource container). >From the point of view of an OS, a DPRC functions similar to a plug and play bus. Using fsl-mc commands software can enumerate the contents of the DPRC discovering the hardware objects present and binding them to drivers. Hardware objects can be created and removed dynamically, providing hot pluggability of the hardware objects. Software contexts interact with the fsl-mc by sending commands through a memory mapped hardware interface called an "MC portal". Every fsl-mc object type has a command set to manage the objects. Key DPRC commands include: -create/destroy a DPRC -enumerate objects and resource pools in the DPRC, including identifying mappable regions and the number of IRQs an object may have -IRQ configuration -move objects/resources between DPRCs -connecting objects (e.g. connecting a network interface to an L2 switch port) -reset Patch 1 contains a minimal set of low level functions to send an d receive commands to the fsl-mc. It includes support for basic management commands and commands to manipulate DPRC objects. Patch 2 contains a platform device driver that sets up and registers the basic bus infrastructure including support for adding/removing devices, register/unregister of drivers, and bus match support to bind devices to drivers. Patch 3 contains an driver that manages DPRC objects (the container that holds the hardware resources). This driver functions as a bus controller and handles enumeration of the objects in the container and hotplug events. CHANGE HISTORY Changes in v3: - Addressed pending issues not resolved in v2: * Removed Doxygen comments as requested by Greg Kroah-Hartman * Moved newly added FSL-specific header files from include/linux to include/linux/fsl * Changed wording of licenses in MC flib source files * Fixed sparse warning about context imbalance in 'mc_send_command' - Addressed additional comments from Kim Phillips, Scott Wood and Timur Tabi. Details in each patch. Issues pending resolution not addressed by v3: - Checkpatch warnings: * WARNING: DT compatible string "fsl,qoriq-mc" appears un-documented This warning will go away once the prerequisite patch series is accepted upstream. * WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? This warning still happens even after adding MAINTAINERS file entries in the same patch where new files were added Changes in v2: - Added reference to the patch series this patch is dependent on for device tree and device tree bindings changes. (See above). - Removed patch 4 (update to the MAINTAINERS file), as this is done now in patch 1 - Addressed comments from Joe Perches, Kim Phillips, Alex Graf and Scott Wood. Details in each patch. Issues pending resolution not addressed by v2: - What to do with Doxygen comments in patch 1 - Whether to move or not FSL-specific header files added in include/linux, by this patch series, to another location - Whether to change or not the wording of the licenses used in some source files - Checkpatch warnings: * WARNING: DT compatible string "fsl,qoriq-mc" appears un-documented This warning will go away once the prerequisite patch series is accepted upstream. * WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? This warning still happens even after adding MAINTAINERS file entries in the same patch where new files were added - Sparse warning: * drivers/bus/fsl-mc/fsl_mc_sys.c:193:9: warning: context imbalance in 'mc_send_command' - different lock contexts for basic block This warning is caused by conditionally acquiring/releasing a lock in function mc_send_command(). Not clear how to solve this warning, as we need to be able to decide at run time based on a flag whether to acquire the lock or not. Changes in v1: - No changes since RFC v4 Changes in RFC v4: - Fixed parameter mismatch for device_find_child() call in fsl_mc_dprc.c - Added back the dma_mask field to struct fsl_mc_device as it is needed by some MC child device drivers. However, the default DMA mask now does not have the 32-bit
Re: [PATCH] [next-20141003] USB: host: st: fix typo 'CONFIG_USB_EHCI_HCD_ST'
On Sat, 2014-10-04 at 13:33 +0200, Arnd Bergmann wrote: > I was about to post the same fix, thanks a lot for addressing this. You're welcome. I just figured that sending a (second) message regarding this typo would have been about as much trouble as sending a one line patch, so I sent that patch. > Sorry for my stupid mistake. That typo was rather easy to make and hard to notice (make won't shout at you for using an unknown macro, etc). See the thread starting at https://lkml.kernel.org/r/1411730854.7866.10.camel@x220 for what I've been doing lately to try to catch these type of things early (ie, in linux-next) and for how Valentin hopes to automate that properly. Paul Bolle -- 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 12/17] mm: sys_remap_anon_pages
Andrea Arcangeli writes: > This new syscall will move anon pages across vmas, atomically and > without touching the vmas. > > It only works on non shared anonymous pages because those can be > relocated without generating non linear anon_vmas in the rmap code. ... > It is an alternative to mremap. Why a new syscall? Couldn't mremap do this transparently? -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 3/8] iio: core: Introduce new MOTION event
On 02/10/14 14:43, Daniel Baluta wrote:
> This is to be used by drivers to signal detection of motion. We also
> add some possible values for motion as IIO events modifiers:
> * running
> * jogging
> * walking
> * still
>
> These values are supported by Frescale's MMA9553 sensor:
>
> http://freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf
>
> Signed-off-by: Daniel Baluta
> Signed-off-by: Irina Tirdea
Hmm.. This is the interesting one.
Not immediately obvious how best to represent this stuff.
> ---
> Documentation/ABI/testing/sysfs-bus-iio | 7 +++
> drivers/iio/industrialio-core.c | 4
> drivers/iio/industrialio-event.c| 1 +
> include/linux/iio/types.h | 7 ++-
> 4 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> b/Documentation/ABI/testing/sysfs-bus-iio
> index d760b02..070346d 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -808,6 +808,13 @@ Description:
> number or direction is not specified, applies to all channels of
> this type.
>
> +What:/sys/.../events/in_activity_motion_either_en
> +KernelVersion: 3.17
> +Contact: linux-...@vger.kernel.org
> +Description:
> + Enables or disables motion detection. Each time motion is
> detected an
> + event of this type will be generated.
> +
The either bit seems a bit random but I can see there is no particularly obvious
alternative.
We really need a clean way of representing a multilevel 'state change' like
this.
Looking at the event code, I almost wonder if we would be better using the
direction element for running, walking etc rather than a modifier.
Having said that we will probably also get devices where this is polled rather
than
event. 'What activity is currently going on?'
If we take that view modifiers make sense as it becomes
'Is the user running?' Perhaps even offering a confidence interval, e.g units
as
percentage
in_activity_running_input 0..100
in_activity_walking_input 0..100
etc
Then our event becomes a state change event (yup we'll need to add that)
/events/in_activity_walking_rising_en will then cause events when the
percentage
confidence on a state rises above the provided threshold or goes above it
(default of 50% perhaps on devices which only report one state).
/events/in_activity_walking_falling_en will do the leaving case.
Note these are just some quick initial thoughts on alternative methods.
I'll want to think on this more and get responses from more interested
parties!
> What:/sys/bus/iio/devices/iio:deviceX/trigger/current_trigger
> KernelVersion: 2.6.35
> Contact: linux-...@vger.kernel.org
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 67e8561..e453ef9 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -92,6 +92,10 @@ static const char * const iio_modifier_names[] = {
> [IIO_MOD_NORTH_TRUE] = "from_north_true",
> [IIO_MOD_NORTH_MAGN_TILT_COMP] = "from_north_magnetic_tilt_comp",
> [IIO_MOD_NORTH_TRUE_TILT_COMP] = "from_north_true_tilt_comp",
> + [IIO_MOD_RUNNING] = "running",
> + [IIO_MOD_JOGGING] = "jogging",
> + [IIO_MOD_WALKING] = "walking",
> + [IIO_MOD_STILL] = "still",
> };
>
> /* relies on pairs of these shared then separate */
> diff --git a/drivers/iio/industrialio-event.c
> b/drivers/iio/industrialio-event.c
> index 0c1e37e..eca5af2 100644
> --- a/drivers/iio/industrialio-event.c
> +++ b/drivers/iio/industrialio-event.c
> @@ -197,6 +197,7 @@ static const char * const iio_ev_type_text[] = {
> [IIO_EV_TYPE_ROC] = "roc",
> [IIO_EV_TYPE_THRESH_ADAPTIVE] = "thresh_adaptive",
> [IIO_EV_TYPE_MAG_ADAPTIVE] = "mag_adaptive",
> + [IIO_EV_TYPE_MOTION] = "motion",
> };
>
> static const char * const iio_ev_dir_text[] = {
> diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
> index d58769a..003638d 100644
> --- a/include/linux/iio/types.h
> +++ b/include/linux/iio/types.h
> @@ -60,7 +60,11 @@ enum iio_modifier {
> IIO_MOD_NORTH_MAGN,
> IIO_MOD_NORTH_TRUE,
> IIO_MOD_NORTH_MAGN_TILT_COMP,
> - IIO_MOD_NORTH_TRUE_TILT_COMP
> + IIO_MOD_NORTH_TRUE_TILT_COMP,
> + IIO_MOD_RUNNING,
> + IIO_MOD_JOGGING,
> + IIO_MOD_WALKING,
> + IIO_MOD_STILL,
> };
>
> enum iio_event_type {
> @@ -69,6 +73,7 @@ enum iio_event_type {
> IIO_EV_TYPE_ROC,
> IIO_EV_TYPE_THRESH_ADAPTIVE,
> IIO_EV_TYPE_MAG_ADAPTIVE,
> + IIO_EV_TYPE_MOTION,
> };
>
> enum iio_event_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/
[PATCH] um: kernel: ksyms: Export symbol syscall() for fixing modpost issue
syscall() is implemented in libc.so/a (e.g. for glibc, in "syscall.o"), so for normal ".o" files, it is undefined, neither can be found within kernel wide, so will break modpost. Since ".o" files is OK, can simply export 'syscall' symbol, let modpost know about that, then can fix this issue. The related error (with allmodconfig under um): MODPOST 1205 modules ERROR: "syscall" [fs/hostfs/hostfs.ko] undefined! Signed-off-by: Chen Gang --- arch/um/kernel/ksyms.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/um/kernel/ksyms.c b/arch/um/kernel/ksyms.c index 543c047..e7780f3 100644 --- a/arch/um/kernel/ksyms.c +++ b/arch/um/kernel/ksyms.c @@ -42,3 +42,6 @@ EXPORT_SYMBOL(os_makedev); EXPORT_SYMBOL(add_sigio_fd); EXPORT_SYMBOL(ignore_sigio_fd); EXPORT_SYMBOL(sigio_broken); + +extern long int syscall (long int __sysno, ...); +EXPORT_SYMBOL(syscall); -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/8] iio: core: Introduce IIO_ACTIVITY channel
On 02/10/14 14:43, Daniel Baluta wrote:
> This channel will be used for exposing information about
> some activity composite sensors including:
> * motion (running, jogging, walking, still).
> * step counter
> * step detector
>
> This will offer an interface for Android composite sensors
> defined here:
> http://source.android.com/devices/sensors/composite_sensors.html
>
> This sensors are supported by Freescale's MMA9553 device.
> http://freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf
>
> Signed-off-by: Daniel Baluta
> Signed-off-by: Irina Tirdea
This interface is interesting As I state on later patches,
get the less fuzzy stuff (step counting) out of here into
it's own type.
I'd also merge this at least with the next patch as it has little meaning
without that...
> ---
> drivers/iio/industrialio-core.c | 1 +
> include/linux/iio/types.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index af3e76d..67e8561 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -70,6 +70,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_CCT] = "cct",
> [IIO_PRESSURE] = "pressure",
> [IIO_HUMIDITYRELATIVE] = "humidityrelative",
> + [IIO_ACTIVITY] = "activity",
> };
>
> static const char * const iio_modifier_names[] = {
> diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
> index 4a2af8a..d58769a 100644
> --- a/include/linux/iio/types.h
> +++ b/include/linux/iio/types.h
> @@ -30,6 +30,7 @@ enum iio_chan_type {
> IIO_CCT,
> IIO_PRESSURE,
> IIO_HUMIDITYRELATIVE,
> + IIO_ACTIVITY,
> };
>
> enum iio_modifier {
>
--
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: [Cocci] [PATCH v2 2/7] module: add extra argument for parse_params() callback
> This adds an extra argument onto parse_params() to be used > as a way to make the unused callback a bit more useful and > generic by allowing the caller to pass on a data structure > of its choice. How do you think about to work with more data type definitions for such callback functions? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 6/8] iio: core: Introduce new STEP_DETECT event
On 02/10/14 14:43, Daniel Baluta wrote:
> From: Irina Tirdea
>
> This event is needed for the step detection functionality of a pedometer:
> an interrupt is generated by the hardware device each time
> a step is detected.
>
> To support this, we add a new iio event.
>
> For more information on the pedometer requirements for Android see
> http://source.android.com/devices/sensors/composite_sensors.html#detector.
>
> A device that has the pedometer functionality this interface needs to
> support is Freescale's MMA9553L:
> http://www.freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf
>
> Signed-off-by: Irina Tirdea
> Signed-off-by: Daniel Baluta
This could be more generic. Perhaps an 'instance' event?
If applied to our step type it would
be in_step_instance_en etc?
> ---
> Documentation/ABI/testing/sysfs-bus-iio | 7 +++
> drivers/iio/industrialio-event.c| 1 +
> include/linux/iio/types.h | 1 +
> 3 files changed, 9 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> b/Documentation/ABI/testing/sysfs-bus-iio
> index c02785d..fd66073 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -815,6 +815,13 @@ Description:
> Enables or disables motion detection. Each time motion is
> detected an
> event of this type will be generated.
>
> +What:/sys/.../events/in_activity_step_detect_either_en
> +KernelVersion: 3.17
> +Contact: linux-...@vger.kernel.org
> +Description:
> + Enables or disables step detection. Each time the user takes a
> step an
> + event of this type will be generated.
> +
> What:/sys/bus/iio/devices/iio:deviceX/trigger/current_trigger
> KernelVersion: 2.6.35
> Contact: linux-...@vger.kernel.org
> diff --git a/drivers/iio/industrialio-event.c
> b/drivers/iio/industrialio-event.c
> index eca5af2..c2ade1f 100644
> --- a/drivers/iio/industrialio-event.c
> +++ b/drivers/iio/industrialio-event.c
> @@ -198,6 +198,7 @@ static const char * const iio_ev_type_text[] = {
> [IIO_EV_TYPE_THRESH_ADAPTIVE] = "thresh_adaptive",
> [IIO_EV_TYPE_MAG_ADAPTIVE] = "mag_adaptive",
> [IIO_EV_TYPE_MOTION] = "motion",
> + [IIO_EV_TYPE_STEP_DETECT] = "step_detect",
> };
>
> static const char * const iio_ev_dir_text[] = {
> diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
> index ae51780..83768a6 100644
> --- a/include/linux/iio/types.h
> +++ b/include/linux/iio/types.h
> @@ -75,6 +75,7 @@ enum iio_event_type {
> IIO_EV_TYPE_THRESH_ADAPTIVE,
> IIO_EV_TYPE_MAG_ADAPTIVE,
> IIO_EV_TYPE_MOTION,
> + IIO_EV_TYPE_STEP_DETECT,
> };
>
> enum iio_event_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/
Re: [RFC PATCH 4/8] iio: core: Introduce pedometer STEP counter modifier
On 02/10/14 14:43, Daniel Baluta wrote:
> From: Irina Tirdea
>
> One of the functionalities of a pedometer is a step counter.
> The step counter needs to be enabled and then it will count the steps
> in its hardware register. Whenever the applications need to check
> the step count, they will read the step counter register.
>
> To support this functionality we need a steps attribute that
> will export the number of steps.
>
> For more information on the pedometer requirements for Android see
> http://source.android.com/devices/sensors/composite_sensors.html#counter.
>
> A device that has the pedometer functionality this interface needs to
> support is Freescale's MMA9553L:
> http://www.freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf
>
> Signed-off-by: Irina Tirdea
> Signed-off-by: Daniel Baluta
I'm not keen on multiplexing different types of data onto a single activity
type.
Steps is well enough defined on it's own to have it's own channel type.
in_steps_input would be fine by me. I suppose steps might mean something else
though...
> ---
> Documentation/ABI/testing/sysfs-bus-iio | 7 +++
> drivers/iio/industrialio-core.c | 1 +
> include/linux/iio/types.h | 1 +
> 3 files changed, 9 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> b/Documentation/ABI/testing/sysfs-bus-iio
> index 070346d..feacb45 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -949,6 +949,13 @@ Description:
> and the relevant _type attributes to establish the data storage
> format.
>
> +What:/sys/.../iio:deviceX/in_activity_steps_raw
> +KernelVersion: 3.17
> +Contact: linux-...@vger.kernel.org
> +Description:
> + This attribute is used to read the number of steps taken by the
> user
> + since the last reboot while activated.
> +
> What:
> /sys/.../iio:deviceX/in_anglvel_z_quadrature_correction_raw
> KernelVersion: 2.6.38
> Contact: linux-...@vger.kernel.org
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index e453ef9..935a8a1 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -96,6 +96,7 @@ static const char * const iio_modifier_names[] = {
> [IIO_MOD_JOGGING] = "jogging",
> [IIO_MOD_WALKING] = "walking",
> [IIO_MOD_STILL] = "still",
> + [IIO_MOD_PED_STEPS] = "steps",
> };
>
> /* relies on pairs of these shared then separate */
> diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
> index 003638d..ae51780 100644
> --- a/include/linux/iio/types.h
> +++ b/include/linux/iio/types.h
> @@ -65,6 +65,7 @@ enum iio_modifier {
> IIO_MOD_JOGGING,
> IIO_MOD_WALKING,
> IIO_MOD_STILL,
> + IIO_MOD_PED_STEPS,
> };
>
> enum iio_event_type {
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/8] iio: dummy: Introduce virtual registers for dummy device
On 02/10/14 14:43, Daniel Baluta wrote:
> We need a way to store events generated by iio_dummy_evgen module,
> in order to correctly process IRQs in iio_simple_dummy_events.
>
> For the moment, we add two registers:
>
> * id_reg - ID register, stores the source of the event
> * id_data - DATA register, stores the type of the event
>
> e.g echo 4 > /sys/bus/iio/devices/iio_evgen/poke2
>
> id_reg 0x02, id_data 0x04
>
> This means, event of type 4 was generated by fake device 2.
>
> We currently use a hardcoded mapping of virtual events to IIO events.
>
> Signed-off-by: Daniel Baluta
> Signed-off-by: Irina Tirdea
Does the job and will look enough like a normal interrupt that
it allows the dummy driver to act as example code.
> ---
> drivers/staging/iio/iio_dummy_evgen.c | 16
> drivers/staging/iio/iio_dummy_evgen.h | 7 +++
> drivers/staging/iio/iio_simple_dummy.h| 2 ++
> drivers/staging/iio/iio_simple_dummy_events.c | 23 ++-
> 4 files changed, 43 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/iio/iio_dummy_evgen.c
> b/drivers/staging/iio/iio_dummy_evgen.c
> index 5a804f1..d44f138 100644
> --- a/drivers/staging/iio/iio_dummy_evgen.c
> +++ b/drivers/staging/iio/iio_dummy_evgen.c
> @@ -33,6 +33,7 @@
> * @base: base of irq range
> * @enabled: mask of which irqs are enabled
> * @inuse: mask of which irqs are connected
> + * @regs: irq regs we are faking
> * @lock: protect the evgen state
> */
> struct iio_dummy_eventgen {
> @@ -40,6 +41,7 @@ struct iio_dummy_eventgen {
> int base;
> bool enabled[IIO_EVENTGEN_NO];
> bool inuse[IIO_EVENTGEN_NO];
> + struct iio_dummy_regs regs[IIO_EVENTGEN_NO];
> struct mutex lock;
> };
>
> @@ -136,6 +138,12 @@ int iio_dummy_evgen_release_irq(int irq)
> }
> EXPORT_SYMBOL_GPL(iio_dummy_evgen_release_irq);
>
> +struct iio_dummy_regs *iio_dummy_evgen_get_regs(int irq)
> +{
> + return _evgen->regs[irq - iio_evgen->base];
> +}
> +EXPORT_SYMBOL_GPL(iio_dummy_evgen_get_regs);
> +
> static void iio_dummy_evgen_free(void)
> {
> irq_free_descs(iio_evgen->base, IIO_EVENTGEN_NO);
> @@ -153,6 +161,14 @@ static ssize_t iio_evgen_poke(struct device *dev,
> size_t len)
> {
> struct iio_dev_attr *this_attr = to_iio_dev_attr(attr);
> + unsigned long event, ret;
> +
> + ret = kstrtoul(buf, 10, );
> + if (ret)
> + return ret;
> +
> + iio_evgen->regs[this_attr->address].reg_id = this_attr->address;
> + iio_evgen->regs[this_attr->address].reg_data = event;
>
> if (iio_evgen->enabled[this_attr->address])
> handle_nested_irq(iio_evgen->base + this_attr->address);
> diff --git a/drivers/staging/iio/iio_dummy_evgen.h
> b/drivers/staging/iio/iio_dummy_evgen.h
> index d8845e2..5273478 100644
> --- a/drivers/staging/iio/iio_dummy_evgen.h
> +++ b/drivers/staging/iio/iio_dummy_evgen.h
> @@ -1,2 +1,9 @@
> +struct iio_dummy_regs {
> + u32 reg_id;
> + u32 reg_data;
> +};
> +
> +struct iio_dummy_regs *iio_dummy_evgen_get_regs(int irq);
> int iio_dummy_evgen_get_irq(void);
> int iio_dummy_evgen_release_irq(int irq);
> +
> diff --git a/drivers/staging/iio/iio_simple_dummy.h
> b/drivers/staging/iio/iio_simple_dummy.h
> index b126196..1a74e26 100644
> --- a/drivers/staging/iio/iio_simple_dummy.h
> +++ b/drivers/staging/iio/iio_simple_dummy.h
> @@ -11,6 +11,7 @@
> #include
>
> struct iio_dummy_accel_calibscale;
> +struct iio_dummy_regs;
>
> /**
> * struct iio_dummy_state - device instance specific state.
> @@ -33,6 +34,7 @@ struct iio_dummy_state {
> int accel_calibbias;
> const struct iio_dummy_accel_calibscale *accel_calibscale;
> struct mutex lock;
> + struct iio_dummy_regs *regs;
> #ifdef CONFIG_IIO_SIMPLE_DUMMY_EVENTS
> int event_irq;
> int event_val;
> diff --git a/drivers/staging/iio/iio_simple_dummy_events.c
> b/drivers/staging/iio/iio_simple_dummy_events.c
> index 64b45b0..719dfa5 100644
> --- a/drivers/staging/iio/iio_simple_dummy_events.c
> +++ b/drivers/staging/iio/iio_simple_dummy_events.c
> @@ -148,12 +148,23 @@ int iio_simple_dummy_write_event_value(struct iio_dev
> *indio_dev,
> static irqreturn_t iio_simple_dummy_event_handler(int irq, void *private)
> {
> struct iio_dev *indio_dev = private;
> + struct iio_dummy_state *st = iio_priv(indio_dev);
> +
> + dev_dbg(_dev->dev, "id %x event %x\n",
> + st->regs->reg_id, st->regs->reg_data);
> +
> + switch (st->regs->reg_data) {
> + case 0:
> + iio_push_event(indio_dev,
> +IIO_EVENT_CODE(IIO_VOLTAGE, 0, 0,
> + IIO_EV_DIR_RISING,
> + IIO_EV_TYPE_THRESH, 0, 0, 0),
> +iio_get_time_ns());
> + break;
> + default:
> + break;
> + }
>
> - iio_push_event(indio_dev,
>
Re: [PATCH 3.16 000/357] 3.16.4-stable review
On Fri, 3 Oct 2014 14:26:26 -0700 Greg Kroah-Hartman wrote: > - > Note: This is a big stable release. Mostly my fault for being on the > road last week, combined with an unusually large number of patches being > tagged for the stable tree. Anyway, I've caught up with all pending > patches before 3.17-rc7, so if you have marked something for the stable > tree that I have not applied, or emailed the stable@v.k.o list asking > for a patch, that is not here, please let me know. > - > > This is the start of the stable review cycle for the 3.16.4 release. > There are 357 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Oct 5 21:28:42 UTC 2014. > Anything received after that time might be too late. > Should also include this one, which fixes CVE-2014-6410: commit c03aa9f6e1f938618e6db2e23afef0574efeeb65 Author: Jan Kara Date: Thu Sep 4 14:06:55 2014 +0200 udf: Avoid infinite loop when processing indirect ICBs -- 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] CMA: Document cma=0
It isn't obvious that CMA can be disabled on the kernel's command
line, so document it.
Signed-off-by: Jean Delvare
Cc: Joonsoo Kim
Cc: Greg Kroah-Hartman
---
Documentation/kernel-parameters.txt |3 ++-
drivers/base/Kconfig|3 +++
2 files changed, 5 insertions(+), 1 deletion(-)
--- linux-3.17-rc7.orig/Documentation/kernel-parameters.txt 2014-09-23
13:19:06.644838292 +0200
+++ linux-3.17-rc7/Documentation/kernel-parameters.txt 2014-10-04
14:10:03.257579721 +0200
@@ -656,7 +656,8 @@ bytes respectively. Such letter suffixes
Sets the size of kernel global memory area for
contiguous memory allocations and optionally the
placement constraint by the physical address range of
- memory allocations. For more information, see
+ memory allocations. A value of 0 disables CMA
+ altogether. For more information, see
include/linux/dma-contiguous.h
cmo_free_hint= [PPC] Format: { yes | no }
--- linux-3.17-rc7.orig/drivers/base/Kconfig2014-09-12 16:23:14.911353676
+0200
+++ linux-3.17-rc7/drivers/base/Kconfig 2014-10-04 13:41:37.672347240 +0200
@@ -231,6 +231,9 @@ config DMA_CMA
to allocate big physically-contiguous blocks of memory for use with
hardware components that do not support I/O map nor scatter-gather.
+ You can disable CMA by specifying "cma=0" on the kernel's command
+ line.
+
For more information see .
If unsure, say "n".
--
Jean Delvare
SUSE L3 Support
--
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] ASoC: da732x: Remove unnecessary KERN_ERR in pr_err()
On Sat, Oct 04, 2014 at 02:17:08AM +0900, Masanari Iida wrote: > This patch remove unnecessary KERN_ERR in pr_err(). Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH v3] iio: iadc: Qualcomm SPMI PMIC current ADC driver
On 01/10/14 17:14, Ivan T. Ivanov wrote:
> The current ADC is peripheral of Qualcomm SPMI PMIC chips. It has
> 16 bits resolution and register space inside PMIC accessible across
> SPMI bus.
>
> The driver registers itself through IIO interface.
>
> Signed-off-by: Ivan T. Ivanov
Looks good to me. I would however like to wait for Mark Rutland to
say whether he is happy with the bindings (and the rest if he
feels like it ;)
Given the merge window will open shortly and hence the IIO merge
window is long closed, we aren't in a particular rush at the moment.
Jonathan
> ---
>
> Changes since v2:
>
> - DT bindings fixed according comments.
> - IADC driver now register 2 channels instead of just one.
> - Fixed sense resistor Ohms dimensions. It is supposed that
> values are around 0.010 Ohms not 10 Mega Ohms.
> - Removed direct driver access to registers in Battery Monitor
> peripheral address space. Which will impact correct internal
> sense resistor calculation on some variants and vendors of
> pm8110 and pm8226. This could be added once we figured out how
> to pass/read PMIC device version from sub-function drivers.
>
> v2: http://www.gossamer-threads.com/lists/linux/kernel/2016613
>
> .../devicetree/bindings/iio/adc/qcom,spmi-iadc.txt | 46 ++
> drivers/iio/adc/Kconfig| 11 +
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/qcom-spmi-iadc.c | 626
> +
> 4 files changed, 684 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.txt
> create mode 100644 drivers/iio/adc/qcom-spmi-iadc.c
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.txt
> b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.txt
> new file mode 100644
> index 000..833afd6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.txt
> @@ -0,0 +1,46 @@
> +Qualcomm's SPMI PMIC current ADC
> +
> +QPNP PMIC current ADC (IADC) provides interface to clients to read current.
> +A 16 bit ADC is used for current measurements. IADC can measure the current
> +through an external resistor(channel 1)or internal(built-in) resistor
> +(channel 0). When using an external resistor it is to be described by
> +qcom,external-resistor-micro-ohms property.
> +
> +IADC node:
> +
> +- compatible:
> +Usage: required
> +Value type:
> +Definition: Should contain "qcom,spmi-iadc".
> +
> +- reg:
> +Usage: required
> +Value type:
> +Definition: IADC base address and length in the SPMI PMIC register map
> +
> +- interrupts:
> +Usage: optional
> +Value type:
> +Definition: End of ADC conversion.
> +
> +- qcom,external-resistor-micro-ohms:
> +Usage: optional
> +Value type:
> +Definition: Sense resister value in micro Ohm.
> +If not defined value of 1 micro Ohms will be used.
> +
> +Example:
> + /* IADC node */
> + pmic_iadc: iadc@3600 {
> + compatible = "qcom,spmi-iadc";
> + reg = <0x3600 0x100>;
> + interrupts = <0x0 0x36 0x0 IRQ_TYPE_EDGE_RISING>;
> + qcom,external-resistor-micro-ohms = <1>;
> + #io-channel-cells = <1>;
> + };
> +
> + /* IIO client node */
> + bat {
> + io-channels = <_iadc>;
> + io-channel-names = "iadc 0";
> + };
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 11b048a..ee1ad5b 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -206,6 +206,17 @@ config NAU7802
> To compile this driver as a module, choose M here: the
> module will be called nau7802.
>
> +config QCOM_SPMI_IADC
> + tristate "Qualcomm SPMI PMIC current ADC"
> + depends on SPMI
> + select REGMAP_SPMI
> + help
> + This is the IIO Current ADC driver for Qualcomm QPNP IADC Chip.
> +
> + The driver supports single mode operation to read from two
> + channels (external or internal). Hardware have additional
> + channels internally used for gain and offset calibration.
> +
> config TI_ADC081C
> tristate "Texas Instruments ADC081C021/027"
> depends on I2C
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index ad81b51..c790543 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -30,3 +30,4 @@ obj-$(CONFIG_VF610_ADC) += vf610_adc.o
> obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
> xilinx-xadc-y := xilinx-xadc-core.o xilinx-xadc-events.o
> obj-$(CONFIG_XILINX_XADC) += xilinx-xadc.o
> +obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
> diff --git a/drivers/iio/adc/qcom-spmi-iadc.c
> b/drivers/iio/adc/qcom-spmi-iadc.c
> new file mode 100644
> index 000..f4328f2
> --- /dev/null
> +++ b/drivers/iio/adc/qcom-spmi-iadc.c
> @@ -0,0 +1,626 @@
> +/*
> + * Copyright (c) 2012-2014, The Linux Foundation. All rights reserved.
> + *
> + * This
Re: [PATCH v2 1/2] spi: fsl-spi: Fix parameter ram offset setup for CPM1
Le 03/10/2014 22:29, Scott Wood a écrit :
On Fri, 2014-10-03 at 18:49 +0200, Christophe Leroy wrote:
On CPM1, the SPI parameter RAM has a default location. In fsl_spi_cpm_get_pram()
there was a confusion between the SPI_BASE register and the base of the SPI
parameter RAM. Fortunatly, it was working properly with MPC866 and MPC885
because they do set SPI_BASE, but on MPC860 and other old MPC8xx that doesn't
set SPI_BASE, pram_ofs was not properly set. This patch fixes this confusion.
Signed-off-by: Christophe Leroy
---
Changes from v1 to v2: none
drivers/spi/spi-fsl-cpm.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/spi/spi-fsl-cpm.c b/drivers/spi/spi-fsl-cpm.c
index 54b0637..0f3a912 100644
--- a/drivers/spi/spi-fsl-cpm.c
+++ b/drivers/spi/spi-fsl-cpm.c
@@ -262,15 +262,14 @@ static unsigned long fsl_spi_cpm_get_pram(struct
mpc8xxx_spi *mspi)
pram_ofs = cpm_muram_alloc(SPI_PRAM_SIZE, 64);
out_be16(spi_base, pram_ofs);
} else {
- struct spi_pram __iomem *pram = spi_base;
- u16 rpbase = in_be16(>rpbase);
+ u16 rpbase = in_be16(spi_base);
- /* Microcode relocation patch applied? */
+ /* Microcode relocation patch applied | rpbase set by default */
if (rpbase) {
pram_ofs = rpbase;
} else {
- pram_ofs = cpm_muram_alloc(SPI_PRAM_SIZE, 64);
- out_be16(spi_base, pram_ofs);
+ pram_ofs = offsetof(cpm8xx_t, cp_dparam[PROFF_SPI]) -
+ offsetof(cpm8xx_t, cp_dpmem[0]);
}
}
Why is PROFF_SPI not coming from the device tree?
That's where it starts to become tricky.
PROFF_SPI is defined in cpm1.h which is included by the driver already.
It provides the default offset from the start of the parameter RAM.
Previously I had the following in my device tree, and the last part of
the source above (the one for rpbase == 0) could not work.
spi: spi@a80 {
cell-index = <0>;
compatible = "fsl,spi", "fsl,cpm1-spi";
reg = <0xa80 0x30 0x3d80 0x30>;
First reg area was the area for SPI registers. Second area was the
parameter RAM zone, which was just mapped to get access to the SPI_BASE
pointer (rpbase)
Now I have
compatible = "fsl,spi", "fsl,cpm1-spi-reloc";
reg = <0xa80 0x30 0x3dac 0x2>;
First reg area is the area for SPI registers. Second area is the
SPI_BASE, as for the CPM2.
On recent 8xx (885 and 866 at least) it contains the offset (=0x1D80) of
the parameter RAM. But on old ones (860, ...) it contains 0. Therefore
we have to get the default index in another way.
What I wanted was to keep something similar to what's done with CPM2.
What should it look like if that offset had to be in the device tree ?
Why don't I see any
cpm spi in any device tree nor any binding for it?
There's one in mgcoge.dts:
spi@11aa0 {
cell-index = <0>;
compatible = "fsl,spi", "fsl,cpm2-spi";
reg = <0x11a80 0x40 0x89fc 0x2>;
Christophe
---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce
que la protection avast! Antivirus est active.
http://www.avast.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 v3 1/2] iio: vadc: Qualcomm SPMI PMIC voltage ADC driver
On 02/10/14 13:08, Ivan T. Ivanov wrote:
> +iio maintainers
>
> On Thu, 2014-10-02 at 12:29 +0300, Ivan T. Ivanov wrote:
>> Hi Stan,
>>
>> On 09/24/2014 03:56 PM, Stanimir Varbanov wrote:
>>
>>
>>
>>> +static int vadc_get_dt_data(struct vadc_priv *vadc, struct device_node
>>> *node)
>>> +{
>>> + struct iio_chan_spec *iio_chan = vadc->iio_chans;
>>> + const struct vadc_channels *vadc_chan;
>>> + struct vadc_channel_prop prop;
>>> + struct device_node *child;
>>> + int ret, index = 0;
>>> +
>>> + for_each_available_child_of_node(node, child) {
>>> + ret = vadc_get_dt_channel_data(vadc->dev, , child);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + vadc->chan_props[index] = prop;
>>> +
>>> + vadc_chan = _chans[prop.channel];
>>> +
>>> + iio_chan->channel = prop.channel;
>>> + iio_chan->datasheet_name = vadc_chan->datasheet_name;
>>> + iio_chan->info_mask_separate = vadc_chan->info_mask;
>>> + iio_chan->type = vadc_chan->type;
>>> + iio_chan->indexed = 1;
>>> + iio_chan->scan_type.sign = 's';
>>> + iio_chan->scan_type.realbits = 15;
>>> + iio_chan->scan_type.storagebits = 16;
>>> + iio_chan->address = index++;
>>> +
>>> + iio_chan++;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>
>>
>>
>>> +static int vadc_probe(struct platform_device *pdev)
>>> +{
>>
>>
>>
>>> +
>>> + indio_dev->dev.parent = dev;
>>> + indio_dev->dev.of_node = node;
>>> + indio_dev->name = pdev->name;
>>> + indio_dev->modes = INDIO_DIRECT_MODE;
>>> + indio_dev->info = _info;
>>> + indio_dev->channels = vadc->iio_chans;
>>> + indio_dev->num_channels = vadc->nchannels;
>>
>> This will not work as we thought. Registration will be fine and entries
>> in sysfs are created as expected, but this is breaking numbering scheme
>> for client drivers. For us the problem is that iio framework expect channels
>> numbering to be linear and channel number should not be greater than
>> channel count. For example even if die temperature channel is always 8, if
>> I describe only 5 channels in DTS files (4 for reference points measurement)
>> and 1 for die temperature, clients could not get OF reference to
>> temperature
>> channel using io-channels = <_vadc 8>;
>>
>> Jonathan, please, could you advise us.
I'd like to let the solution you proposed sit on the list a little longer.
It seems fairly sensible, but lets see what others suggest.
Jonathan
>>
>> Regards,
>> Ivan
>>
>>> +
>>> + return devm_iio_device_register(dev, indio_dev);
>>> +}
>>> +
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rcutorture: Remove stale test configurations
On Sat, Oct 04, 2014 at 03:56:53AM -0700, Paul E. McKenney wrote: > On Thu, Oct 02, 2014 at 11:33:48PM -0400, Pranith Kumar wrote: > > Remove rcutorture configuration files which are no longer necessary. > > > > Signed-off-by: Pranith Kumar > > Queued for 3.19, thank you! Make that 3.20 -- 3.19 is of course upon us. Thanx, Paul > The --kversion argument to the .../rcutorture/bin/kvm.sh script is > not obsolete. Would you be willing to remove it along with the > "kversion" shell variable that it controls? > > Thanx, Paul > > > --- > > .../selftests/rcutorture/configs/rcu/v0.0/CFLIST | 14 -- > > .../configs/rcu/v0.0/N1-S-T-NH-SD-SMP-HP | 18 --- > > .../configs/rcu/v0.0/N2-2-t-nh-sd-SMP-hp | 20 > > .../configs/rcu/v0.0/N3-3-T-nh-SD-SMP-hp | 22 - > > .../configs/rcu/v0.0/N4-A-t-NH-sd-SMP-HP | 18 --- > > .../configs/rcu/v0.0/N5-U-T-NH-sd-SMP-hp | 22 - > > .../selftests/rcutorture/configs/rcu/v0.0/NT1-nh | 23 - > > .../selftests/rcutorture/configs/rcu/v0.0/NT3-NH | 20 > > .../configs/rcu/v0.0/P1-S-T-NH-SD-SMP-HP | 19 > > .../configs/rcu/v0.0/P2-2-t-nh-sd-SMP-hp | 20 > > .../configs/rcu/v0.0/P3-3-T-nh-SD-SMP-hp | 20 > > .../configs/rcu/v0.0/P4-A-t-NH-sd-SMP-HP | 22 - > > .../configs/rcu/v0.0/P5-U-T-NH-sd-SMP-hp | 27 -- > > .../selftests/rcutorture/configs/rcu/v0.0/PT1-nh | 23 - > > .../selftests/rcutorture/configs/rcu/v0.0/PT2-NH | 22 - > > .../rcutorture/configs/rcu/v0.0/ver_functions.sh | 33 - > > .../selftests/rcutorture/configs/rcu/v3.12/CFLIST | 17 --- > > .../configs/rcu/v3.12/N1-S-T-NH-SD-SMP-HP | 19 > > .../configs/rcu/v3.12/N2-2-t-nh-sd-SMP-hp | 20 > > .../configs/rcu/v3.12/N3-3-T-nh-SD-SMP-hp | 22 - > > .../configs/rcu/v3.12/N4-A-t-NH-sd-SMP-HP | 18 --- > > .../configs/rcu/v3.12/N5-U-T-NH-sd-SMP-hp | 22 - > > .../configs/rcu/v3.12/N6---t-nh-SD-smp-hp | 19 > > .../configs/rcu/v3.12/N7-4-T-NH-SD-SMP-HP | 26 -- > > .../configs/rcu/v3.12/N8-2-T-NH-SD-SMP-HP | 22 - > > .../selftests/rcutorture/configs/rcu/v3.12/NT1-nh | 23 - > > .../selftests/rcutorture/configs/rcu/v3.12/NT3-NH | 20 > > .../configs/rcu/v3.12/P1-S-T-NH-SD-SMP-HP | 20 > > .../configs/rcu/v3.12/P2-2-t-nh-sd-SMP-hp | 20 > > .../configs/rcu/v3.12/P3-3-T-nh-SD-SMP-hp | 20 > > .../configs/rcu/v3.12/P4-A-t-NH-sd-SMP-HP | 22 - > > .../configs/rcu/v3.12/P5-U-T-NH-sd-SMP-hp | 27 -- > > .../configs/rcu/v3.12/P6---t-nh-SD-smp-hp | 18 --- > > .../configs/rcu/v3.12/P7-4-T-NH-SD-SMP-HP | 30 > > .../configs/rcu/v3.12/P7-4-T-NH-SD-SMP-HP-all | 30 > > .../configs/rcu/v3.12/P7-4-T-NH-SD-SMP-HP-none | 30 > > .../configs/rcu/v3.12/P7-4-T-NH-SD-SMP-hp | 30 > > .../selftests/rcutorture/configs/rcu/v3.12/PT1-nh | 23 - > > .../selftests/rcutorture/configs/rcu/v3.12/PT2-NH | 22 - > > .../selftests/rcutorture/configs/rcu/v3.3/CFLIST | 14 -- > > .../configs/rcu/v3.3/N1-S-T-NH-SD-SMP-HP | 19 > > .../configs/rcu/v3.3/N2-2-t-nh-sd-SMP-hp | 20 > > .../configs/rcu/v3.3/N3-3-T-nh-SD-SMP-hp | 22 - > > .../configs/rcu/v3.3/N4-A-t-NH-sd-SMP-HP | 18 --- > > .../configs/rcu/v3.3/N5-U-T-NH-sd-SMP-hp | 22 - > > .../selftests/rcutorture/configs/rcu/v3.3/NT1-nh | 23 - > > .../selftests/rcutorture/configs/rcu/v3.3/NT3-NH | 20 > > .../configs/rcu/v3.3/P1-S-T-NH-SD-SMP-HP | 20 > > .../configs/rcu/v3.3/P2-2-t-nh-sd-SMP-hp | 20 > > .../configs/rcu/v3.3/P3-3-T-nh-SD-SMP-hp | 20 > > .../configs/rcu/v3.3/P4-A-t-NH-sd-SMP-HP | 22 - > > .../configs/rcu/v3.3/P5-U-T-NH-sd-SMP-hp | 27 -- > > .../selftests/rcutorture/configs/rcu/v3.3/PT1-nh | 23 - > > .../selftests/rcutorture/configs/rcu/v3.3/PT2-NH | 22 - > > .../rcutorture/configs/rcu/v3.3/ver_functions.sh | 44 - > > .../selftests/rcutorture/configs/rcu/v3.5/CFLIST | 14 -- > > .../configs/rcu/v3.5/N1-S-T-NH-SD-SMP-HP | 19 > > .../configs/rcu/v3.5/N2-2-t-nh-sd-SMP-hp | 20 > > .../configs/rcu/v3.5/N3-3-T-nh-SD-SMP-hp | 22 - > > .../configs/rcu/v3.5/N4-A-t-NH-sd-SMP-HP | 18 --- > > .../configs/rcu/v3.5/N5-U-T-NH-sd-SMP-hp | 22 - > >
Re: [PATCH v4] IIO: add si7020 driver
On 29/09/14 19:28, David Barksdale wrote:
> This patch adds support to the Industrial IO subsystem
> for the Silicon Labs Si7013/20/21 Relative Humidity and
> Temperature Sensors.
>
> Website:
> http://www.silabs.com/products/sensors/humidity-sensors/Pages/si7013-20-21.aspx
>
> These are i2c devices which measure relative humidity
> and temperature and all use the same protocol. The
> Si7013 has an additional input with programmable
> linearization which is not supported because that's
> complicated and I didn't need it.
>
> Signed-off-by: David Barksdale
Applied with some trivial whitespace and comment formatting fixups.
Applied to the togreg branch of iio.git - initially pushed out as
testing for the autobuilders to play with it.
Thanks,
Jonathan
>
> --
> Changes since v1:
> * Renamed to si7020 and replaced Si701x/2x with Si7013/20/21.
> * Removed unneeded mutex.
> * Pre-computed floating-point constant expressions.
> * Removed address_list and I2C_CLASS_HWMON.
>
> Changes since v2:
> * Return correct raw sensor values.
> * Rename dev variable to indio_dev.
> * Issue a software reset command during probe.
> * Un-broke string literal.
>
> Changes since v3:
> * enum changed to #define
>
> ---
> drivers/iio/humidity/Kconfig | 10 +++
> drivers/iio/humidity/Makefile | 1 +
> drivers/iio/humidity/si7020.c | 163
> ++
> 3 files changed, 174 insertions(+)
>
> diff --git a/drivers/iio/humidity/Kconfig b/drivers/iio/humidity/Kconfig
> index e116bd8..4813b79 100644
> --- a/drivers/iio/humidity/Kconfig
> +++ b/drivers/iio/humidity/Kconfig
> @@ -22,4 +22,14 @@ config SI7005
> To compile this driver as a module, choose M here: the module
> will be called si7005.
>
> +config SI7020
> + tristate "Si7013/20/21 Relative Humidity and Temperature Sensors"
> + depends on I2C
> + help
> + Say yes here to build support for the Silicon Labs Si7013/20/21
> + Relative Humidity and Temperature Sensors.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called si7020.
> +
> endmenu
> diff --git a/drivers/iio/humidity/Makefile b/drivers/iio/humidity/Makefile
> index e3f3d94..86e2d26 100644
> --- a/drivers/iio/humidity/Makefile
> +++ b/drivers/iio/humidity/Makefile
> @@ -4,3 +4,4 @@
>
> obj-$(CONFIG_DHT11) += dht11.o
> obj-$(CONFIG_SI7005) += si7005.o
> +obj-$(CONFIG_SI7020) += si7020.o
> diff --git a/drivers/iio/humidity/si7020.c b/drivers/iio/humidity/si7020.c
> new file mode 100644
> index 000..db60ab7
> --- /dev/null
> +++ b/drivers/iio/humidity/si7020.c
> @@ -0,0 +1,163 @@
> +/*
> + * si7020.c - Silicon Labs Si7013/20/21 Relative Humidity and Temp Sensors
> + * Copyright (c) 2013,2014 Uplogix, Inc.
> + * David Barksdale
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +/*
> + * The Silicon Labs Si7013/20/21 Relative Humidity and Temperature Sensors
> + * are i2c devices which have an identical programming interface for
> + * measuring relative humidity and temperature. The Si7013 has an additional
> + * temperature input which this driver does not support.
> + *
> + * Data Sheets:
> + * Si7013:
> http://www.silabs.com/Support%20Documents/TechnicalDocs/Si7013.pdf
> + * Si7020:
> http://www.silabs.com/Support%20Documents/TechnicalDocs/Si7020.pdf
> + * Si7021:
> http://www.silabs.com/Support%20Documents/TechnicalDocs/Si7021.pdf
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +/* Measure Relative Humidity, Hold Master Mode */
> +#define SI7020CMD_RH_HOLD0xE5
> +/* Measure Temperature, Hold Master Mode */
> +#define SI7020CMD_TEMP_HOLD 0xE3
> +/* Software Reset */
> +#define SI7020CMD_RESET 0xFE
> +
> +static int si7020_read_raw(struct iio_dev *indio_dev,
> +struct iio_chan_spec const *chan, int *val,
> +int *val2, long mask)
> +{
> + struct i2c_client **client = iio_priv(indio_dev);
> + int ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + ret = i2c_smbus_read_word_data(*client,
> +chan->type == IIO_TEMP ?
> +SI7020CMD_TEMP_HOLD :
> +SI7020CMD_RH_HOLD);
> + if (ret < 0)
> + return ret;
> + if (chan->type == IIO_TEMP)
> + *val = ret >> 2;
> + else
> + *val
Re: [PATCH] drivers/net/can/m_can/Kconfig: Let CAN_M_CAN depend on HAS_IOMEM
On 10/4/14 19:05, Varka Bhadram wrote: > Hi Chen Gang > > > I think commit message should be short and proper. > > We can remove *drivers/net/can/m_can/Kconfig* in the commit, just > give *can: Kconfig: * > > commit message like : *can: Kconfig: Fix CAN_M_CAN dependency* > OK, thanks, it sounds good to me. If necessary to send patch v2 for it, please let me know. Thanks. > On Saturday 04 October 2014 03:30 PM, Chen Gang wrote: >> CAN_M_CAN needs HAS_IOMEM, so depend on it, the related error (with >> allmodconfig under um): >> >> MODPOST 1205 modules >>ERROR: "devm_ioremap" [drivers/net/can/m_can/m_can.ko] undefined! >>ERROR: "devm_ioremap_resource" [drivers/net/can/m_can/m_can.ko] undefined! >> >> Signed-off-by: Chen Gang >> --- >> drivers/net/can/m_can/Kconfig | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig >> index fca5482..14c9fcf 100644 >> --- a/drivers/net/can/m_can/Kconfig >> +++ b/drivers/net/can/m_can/Kconfig >> @@ -1,4 +1,5 @@ >> config CAN_M_CAN >> tristate "Bosch M_CAN devices" >> +depends on HAS_IOMEM >> ---help--- >> Say Y here if you want to support for Bosch M_CAN controller. > -- 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/
Re: [PATCH] [next-20141003] USB: host: st: fix typo 'CONFIG_USB_EHCI_HCD_ST'
On Friday 03 October 2014 10:21:44 Paul Bolle wrote:
> Signed-off-by: Paul Bolle
> Fixes: 905e300e1043 ("USB: host: st: fix ehci/ohci driver selection")
> ---
> drivers/usb/host/ehci-st.o actually builds (on x86_64. that is) so
> there's no _obvious_ reason not to fix this typo.
>
I was about to post the same fix, thanks a lot for addressing this.
Sorry for my stupid mistake.
Acked-by: Arnd Bergmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/1] net: fix rcu access on phonet_routes
Le samedi 4 octobre 2014, 11:57:56 Fabian Frederick a écrit : (snip) > -Access table with rcu_dereference (fixes the following sparse errors): > net/phonet/pn_dev.c:278:25: error: incompatible types in comparison > expression (different address spaces) net/phonet/pn_dev.c:391:17: error: > incompatible types in comparison expression (different address spaces) Acked-by: Rémi Denis-Courmont -- Rémi Denis-Courmont http://www.remlab.net/ -- 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: Why do we still have 32 bit counters? Interrupt counters overflow within 50 days
On Fre, 2014-10-03 at 07:23 -0500, Christoph Lameter wrote: > On Fri, 3 Oct 2014, Paul Bolle wrote: > > > dc -e "1 k 2 32 ^ 1000 / 86400 / p" > > 49.7 > > > > (That was the number I remembered from stories about a ancient Windows > > lockup.) > > Well yes, I used bc which discards the remainder on integer divides Use `bc -l`;-) snip 2^32 / 1000 / 86400 49.71026962962962962962 snip Bernd -- "I dislike type abstraction if it has no real reason. And saving on typing is not a good reason - if your typing speed is the main issue when you're coding, you're doing something seriously wrong." - 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/
Re: [PATCH] drivers/net/can/m_can/Kconfig: Let CAN_M_CAN depend on HAS_IOMEM
Hi Chen Gang I think commit message should be short and proper. We can remove *drivers/net/can/m_can/Kconfig* in the commit, just give *can: Kconfig: * commit message like : *can: Kconfig: Fix CAN_M_CAN dependency* On Saturday 04 October 2014 03:30 PM, Chen Gang wrote: CAN_M_CAN needs HAS_IOMEM, so depend on it, the related error (with allmodconfig under um): MODPOST 1205 modules ERROR: "devm_ioremap" [drivers/net/can/m_can/m_can.ko] undefined! ERROR: "devm_ioremap_resource" [drivers/net/can/m_can/m_can.ko] undefined! Signed-off-by: Chen Gang --- drivers/net/can/m_can/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig index fca5482..14c9fcf 100644 --- a/drivers/net/can/m_can/Kconfig +++ b/drivers/net/can/m_can/Kconfig @@ -1,4 +1,5 @@ config CAN_M_CAN tristate "Bosch M_CAN devices" + depends on HAS_IOMEM ---help--- Say Y here if you want to support for Bosch M_CAN controller. -- Thanks and Regards, Varka Bhadram. -- 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 04/15] ACPI: Document ACPI device specific properties
On Saturday 04 October 2014 02:13:23 Rafael J. Wysocki wrote:
> > Because people get the format wrong regardless of documentation. The
> > format:
> >
> > Package () {
> > Package () { ^ref1, data, data },
> > Package () { ^ref2, data },
> > Package () { ^ref3, data, data, data },
> > }
> >
> > Is superior to the format:
> >
> > Package () { ^ref1, data, data, ^ref2, data, ^ref3, data, data, data }
> >
> > Because in the former you have delimiters that can be used to verify
> > each tuple. Imagine someone misses a data element for one of these
> > tuples. In the former layout you can detect this easily while in the
> > latter you cannot.
>
> I agree with this particular thing (although other people seem to have
> problems with too many package nesting levels) but I'm not sure what that
> has to do with the example given above (let me quote again):
>
> > Putting everything to a single package results this:
> >
> > Package () { "pwms", Package () {"led-red", ^PWM0, 0, 10,
> > "led-green", ^PWM0, 1, 10 }}
> >
> > But I think the below looks better:
> >
> > Package () { "pwms", Package () {^PWM0, 0, 10, ^PWM0, 1, 10 }}
> > Package () { "pwm-names", Package () {"led-red", "led-green"}}
> >
> > and it is trivial to match with the corresponding DT fragment.
>
> that I was commenting. Both cases contains the
>
> Package () { ^ref1, data, data, ^ref2, data, ^ref3, data, data, data }
>
> format that you don't like, don't they?
>
There are two independent issues:
a) avoiding the need for "pwm-names" by embedding the name in the
"pwms" property
b) avoiding the need for "#pwm-cells" by having explicit separators between
entries in a "pwms" property.
It would be possible to do one but not the other.
Arnd
--
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/
[REGRESSION] ACPI / EC: Events not being cleared on Samsung series 9 laptop
Since updating to kernel 3.16.3 I have noticed that an old bug has returned where EC events like lid open/close and ambient light change are no longer being processed on my Samsung notebook (900X3C). Most of this was previously documented in: Samsung Series 9 np900x4b: ACPI does not seem to reflect charging/discharging... https://bugzilla.kernel.org/show_bug.cgi?id=44161 A workaround was added to the kernel at the time: ad332c8a45330d170bb38b95209de449b31cd1b4 ACPI / EC: Clear stale EC events on Samsung systems 3eba563e280101209bad27d40bfc83ddf1489234 ACPI / EC: Process rather than discard events in acpi_ec_clear That seemed to have solved the problem, but it seems that a recent change between 66b42b78bc1e816f92b662ec89195e4199e1 ACPI / EC: Avoid race condition related to advance_transaction() and 558e4736f2e1b0e6323adf7a5e4df77ed6cfc1a4 ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC Has reintroduced this bug. I have not had time to fully test this myself, but someone else who noticed the same regression has now posted in the kernel bugzilla link above reporting that: > I've narrowed it down to the following commits: > > ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set > 3afcf2ece453e1a8c2c6de19cdf06da3772a1b08 > > ACPI / EC: Add support to disallow QR_EC to be issued before completing > previous QR_EC > 558e4736f2e1b0e6323adf7a5e4df77ed6cfc1a4 > > On 3.17rc7, reverting the latter seems to solve the issue for acpi events > related to > the power supply, however LID switch is still broken. > Reverting both seems to resolve the issue completely. Can anyone (Lv Zheng) think of why these patches have caused this issue on this hardware? Maybe we need to modify the patches above to do something different in case EC_FLAGS_CLEAR_ON_RESUME is set? Regards, Kieran Clancy -- 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/
Pieces placed in juxtaposition.
"Opensource is going mainstream in 2014" -RedHat CEO Systemd presents a large attack surface (where as there are few ways to communicate with init etc), needlessly manages disc cryptography (amongst everything else, normal inits never cared one way or the other), "Obama Administration Argues For Backdoors In Personal Electronics" http://it.slashdot.org/story/14/10/01/186228/obama-administration-argues-for-backdoors-in-personal-electronics (Think of the children, ignore privacy, and religious freedom (that ship set sail in Delaware 1870)) Attorney General Eric Holder called it is "worrisome" that tech companies are providing default encryption on consumer electronics, adding that locking authorities out of being able to access the contents of devices puts children at risk. \u201cIt is fully possible to permit law enforcement to do its job while still adequately protecting personal privacy,\u201d Holder said at a conference on child sexual abuse, according to a text of his prepared remarks. \u201cWhen a child is in danger, law enforcement needs to be able to take every legally available step to quickly find and protect the child and to stop those that abuse children. It is worrisome to see companies thwarting our ability to do so.\u201d -- 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] rcutorture: Remove stale test configurations
On Thu, Oct 02, 2014 at 11:33:48PM -0400, Pranith Kumar wrote: > Remove rcutorture configuration files which are no longer necessary. > > Signed-off-by: Pranith Kumar Queued for 3.19, thank you! The --kversion argument to the .../rcutorture/bin/kvm.sh script is not obsolete. Would you be willing to remove it along with the "kversion" shell variable that it controls? Thanx, Paul > --- > .../selftests/rcutorture/configs/rcu/v0.0/CFLIST | 14 -- > .../configs/rcu/v0.0/N1-S-T-NH-SD-SMP-HP | 18 --- > .../configs/rcu/v0.0/N2-2-t-nh-sd-SMP-hp | 20 > .../configs/rcu/v0.0/N3-3-T-nh-SD-SMP-hp | 22 - > .../configs/rcu/v0.0/N4-A-t-NH-sd-SMP-HP | 18 --- > .../configs/rcu/v0.0/N5-U-T-NH-sd-SMP-hp | 22 - > .../selftests/rcutorture/configs/rcu/v0.0/NT1-nh | 23 - > .../selftests/rcutorture/configs/rcu/v0.0/NT3-NH | 20 > .../configs/rcu/v0.0/P1-S-T-NH-SD-SMP-HP | 19 > .../configs/rcu/v0.0/P2-2-t-nh-sd-SMP-hp | 20 > .../configs/rcu/v0.0/P3-3-T-nh-SD-SMP-hp | 20 > .../configs/rcu/v0.0/P4-A-t-NH-sd-SMP-HP | 22 - > .../configs/rcu/v0.0/P5-U-T-NH-sd-SMP-hp | 27 -- > .../selftests/rcutorture/configs/rcu/v0.0/PT1-nh | 23 - > .../selftests/rcutorture/configs/rcu/v0.0/PT2-NH | 22 - > .../rcutorture/configs/rcu/v0.0/ver_functions.sh | 33 - > .../selftests/rcutorture/configs/rcu/v3.12/CFLIST | 17 --- > .../configs/rcu/v3.12/N1-S-T-NH-SD-SMP-HP | 19 > .../configs/rcu/v3.12/N2-2-t-nh-sd-SMP-hp | 20 > .../configs/rcu/v3.12/N3-3-T-nh-SD-SMP-hp | 22 - > .../configs/rcu/v3.12/N4-A-t-NH-sd-SMP-HP | 18 --- > .../configs/rcu/v3.12/N5-U-T-NH-sd-SMP-hp | 22 - > .../configs/rcu/v3.12/N6---t-nh-SD-smp-hp | 19 > .../configs/rcu/v3.12/N7-4-T-NH-SD-SMP-HP | 26 -- > .../configs/rcu/v3.12/N8-2-T-NH-SD-SMP-HP | 22 - > .../selftests/rcutorture/configs/rcu/v3.12/NT1-nh | 23 - > .../selftests/rcutorture/configs/rcu/v3.12/NT3-NH | 20 > .../configs/rcu/v3.12/P1-S-T-NH-SD-SMP-HP | 20 > .../configs/rcu/v3.12/P2-2-t-nh-sd-SMP-hp | 20 > .../configs/rcu/v3.12/P3-3-T-nh-SD-SMP-hp | 20 > .../configs/rcu/v3.12/P4-A-t-NH-sd-SMP-HP | 22 - > .../configs/rcu/v3.12/P5-U-T-NH-sd-SMP-hp | 27 -- > .../configs/rcu/v3.12/P6---t-nh-SD-smp-hp | 18 --- > .../configs/rcu/v3.12/P7-4-T-NH-SD-SMP-HP | 30 > .../configs/rcu/v3.12/P7-4-T-NH-SD-SMP-HP-all | 30 > .../configs/rcu/v3.12/P7-4-T-NH-SD-SMP-HP-none | 30 > .../configs/rcu/v3.12/P7-4-T-NH-SD-SMP-hp | 30 > .../selftests/rcutorture/configs/rcu/v3.12/PT1-nh | 23 - > .../selftests/rcutorture/configs/rcu/v3.12/PT2-NH | 22 - > .../selftests/rcutorture/configs/rcu/v3.3/CFLIST | 14 -- > .../configs/rcu/v3.3/N1-S-T-NH-SD-SMP-HP | 19 > .../configs/rcu/v3.3/N2-2-t-nh-sd-SMP-hp | 20 > .../configs/rcu/v3.3/N3-3-T-nh-SD-SMP-hp | 22 - > .../configs/rcu/v3.3/N4-A-t-NH-sd-SMP-HP | 18 --- > .../configs/rcu/v3.3/N5-U-T-NH-sd-SMP-hp | 22 - > .../selftests/rcutorture/configs/rcu/v3.3/NT1-nh | 23 - > .../selftests/rcutorture/configs/rcu/v3.3/NT3-NH | 20 > .../configs/rcu/v3.3/P1-S-T-NH-SD-SMP-HP | 20 > .../configs/rcu/v3.3/P2-2-t-nh-sd-SMP-hp | 20 > .../configs/rcu/v3.3/P3-3-T-nh-SD-SMP-hp | 20 > .../configs/rcu/v3.3/P4-A-t-NH-sd-SMP-HP | 22 - > .../configs/rcu/v3.3/P5-U-T-NH-sd-SMP-hp | 27 -- > .../selftests/rcutorture/configs/rcu/v3.3/PT1-nh | 23 - > .../selftests/rcutorture/configs/rcu/v3.3/PT2-NH | 22 - > .../rcutorture/configs/rcu/v3.3/ver_functions.sh | 44 - > .../selftests/rcutorture/configs/rcu/v3.5/CFLIST | 14 -- > .../configs/rcu/v3.5/N1-S-T-NH-SD-SMP-HP | 19 > .../configs/rcu/v3.5/N2-2-t-nh-sd-SMP-hp | 20 > .../configs/rcu/v3.5/N3-3-T-nh-SD-SMP-hp | 22 - > .../configs/rcu/v3.5/N4-A-t-NH-sd-SMP-HP | 18 --- > .../configs/rcu/v3.5/N5-U-T-NH-sd-SMP-hp | 22 - > .../selftests/rcutorture/configs/rcu/v3.5/NT1-nh | 23 - > .../selftests/rcutorture/configs/rcu/v3.5/NT3-NH | 20 > .../configs/rcu/v3.5/P1-S-T-NH-SD-SMP-HP | 20 > .../configs/rcu/v3.5/P2-2-t-nh-sd-SMP-hp | 20 > .../configs/rcu/v3.5/P3-3-T-nh-SD-SMP-hp | 20 >
(Video) Discussion on lennart poettering, syst__d, sysv
Discussion on lennart poettering, syst__d, sysv http://youtu.be/2toVPMHRo8M -- 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/
Debian nolonger claims to be the "Universal Operating System"
Debian nolonger claims to be the "Universal Operating System" On google searches debian pages still turn up like this: Debian -- Mailing Lists - Debian -- The Universal Operating ... When you go to the page "The Universal Operating System" part is gone. A reflection of the problem with the scumbag debian developers failing to explain how "The Universal Operating System" squares with shoving syst__d, gn_me/gtk3, down our throats, and "depreciating" (as if they have the right to do that) many programs that rely on gtk2 and non-syst__d. Ofcourse they ban you from posting the mailing list on the first critical mention of systemd. Worthless trash. They need to be stopped, deposed. Give us back the debian packagers of an earlier age. -- 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 04/15] ACPI: Document ACPI device specific properties
On Saturday 04 October 2014 01:58:30 Rafael J. Wysocki wrote:
> On Friday, October 03, 2014 05:02:13 PM Arnd Bergmann wrote:
> > On Friday 03 October 2014 14:56:10 Mark Rutland wrote:
> > > On Thu, Oct 02, 2014 at 03:55:56PM +0100, Arnd Bergmann wrote:
> > > I'd certainly not like to see #foo-cells in _DSD given it should be
> > > possible with a package to have a package description like the
> > > following:
> > >
> > > Package () {
> > > Package () { ^ref1, data, data },
> > > Package () { ^ref2, dta, data, data },
> > > }
> > >
> > > Where the #foo-cells is implicit in each instance. That makes variadic
> > > properties possible, and makes it possible to perform validation on each
> > > tuple even in the binary format, which we can't do with a DTB
> > >
> > > I'm not so sure on foo-names unless we made names an explicit
> > > requirement from the start (which I wish was the case on the DT side).
> > > Even then we might need other parallel properties anyway (think
> > > clock-indicies).
> >
> > I suppose it might even be possible to define the ACPI references to
> > have an optional string, so you can do
> >
> > Package () {
> > Package () { ^ref1, data, data },
> > Package () { "foo", ^ref2, data, data, data },
> > }
> >
> > The parser should be able to interpret both anonymous and named
> > references just by looking at the type of the first member.
> > You might not want to allow mixing them in a single property, but
> > that is more a style question than a technical requirement.
>
> Yes, that only is a matter of implementing the parser.
>
> For now, it simply is easier for us to parse the
>
> Package () { ^ref1, data, data }
>
> format only, because we have functions for parsing lists of strings,
> lists of numbers etc. for other purposes anyway and we can re-use them
> for the names etc. I don't see a reason why the parser cannot be extended in
> the future to handle "all in one" packages, but not necessarily at the moment.
It only really makes sense to do it that way though if it's used
consistently, and all references do naming like this rather than
the foo-names method.
Arnd
--
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 3.14 104/238] iommu/fsl: Fix warning resulting from adding PCI device twice
Hi Greg, This fix is not required on 3.14. Fix was required to address an issue, introduced by the iommu_group_get_for_dev API in the PAMU driver code. Regards Varun > -Original Message- > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] > Sent: Saturday, October 04, 2014 3:00 AM > To: linux-kernel@vger.kernel.org > Cc: Greg Kroah-Hartman; sta...@vger.kernel.org; Sethi Varun-B16395; Joerg > Roedel > Subject: [PATCH 3.14 104/238] iommu/fsl: Fix warning resulting from adding PCI > device twice > > 3.14-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Varun Sethi > > commit 5a9137a66b521d667236e95c307b92af532fe600 upstream. > > iommu_group_get_for_dev determines the iommu group for the PCI device > and adds the device to the group. > > In the PAMU driver we were again adding the device to the same group > without checking if the device already had an iommu group. This resulted in > the > following warning. > > sysfs: cannot create duplicate filename > '/devices/ffe20.pcie/pci:00/:00:00.0/iommu_group' > [ cut here ] > WARNING: at fs/sysfs/dir.c:31 > Modules linked in: > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc3-2-g7505cea-dirty > #126 > task: c001fe0a ti: c001fe044000 task.ti: c001fe044000 > NIP: c018879c LR: c0188798 CTR: c001ea50 > REGS: c001fe047040 TRAP: 0700 Not tainted (3.17.0-rc3-2-g7505cea- > dirty) > MSR: 80029000 CR: 24ad8e22 XER: 2000 > SOFTE: 1 > GPR00: c0188798 c001fe0472c0 c09a52e0 > 0065 > GPR04: 0001 3a30303a > 2700 > GPR08: 2f696f6d c08d3830 c09b3938 > c09bb3d0 > GPR12: 28ad8e24 cfff4000 c000205c > > GPR16: > > GPR20: > c08a4c70 > GPR24: c07e9010 c001fe0140a8 ffef 0001 > GPR28: c001fe22ebb8 c07e9010 c090bf10 > c001fe22 NIP [c018879c] .sysfs_warn_dup+0x74/0xa4 LR > [c0188798] .sysfs_warn_dup+0x70/0xa4 Call Trace: > [c001fe0472c0] [c0188798] .sysfs_warn_dup+0x70/0xa4 > (unreliable) [c001fe047350] [c0188d34] > .sysfs_do_create_link_sd.clone.2+0x168/0x174 > [c001fe047400] [c04b3cf8] > .iommu_group_add_device+0x78/0x244 > [c001fe0474b0] [c04b6964] .fsl_pamu_add_device+0x88/0x1a8 > [c001fe047570] [c04b3960] .iommu_bus_notifier+0xdc/0x15c > [c001fe047600] [c0059848] .notifier_call_chain+0x8c/0xe8 > [c001fe0476a0] [c0059d04] > .__blocking_notifier_call_chain+0x58/0x84 > [c001fe047750] [c036619c] .device_add+0x464/0x5c8 > [c001fe047820] [c0300ebc] .pci_device_add+0x14c/0x17c > [c001fe0478c0] [c0300fbc] .pci_scan_single_device+0xd0/0xf4 > [c001fe047970] [c030104c] .pci_scan_slot+0x6c/0x18c > [c001fe047a10] [c030226c] .pci_scan_child_bus+0x40/0x114 > [c001fe047ac0] [c0021974] .pcibios_scan_phb+0x240/0x2c8 > [c001fe047b70] [c085a970] .pcibios_init+0x64/0xc8 > [c001fe047c00] [c0001884] .do_one_initcall+0xbc/0x224 > [c001fe047d00] [c0852d50] .kernel_init_freeable+0x14c/0x21c > [c001fe047db0] [c0002078] .kernel_init+0x1c/0xfa4 > [c001fe047e30] [c884] .ret_from_kernel_thread+0x58/0xd4 > Instruction dump: > 7c7f1b79 4182001c 7fe4fb78 7f83e378 38a01000 4bffc905 6000 7c641b78 > e87e8008 7fa5eb78 48482ff5 6000 <0fe0> 7fe3fb78 4bf7bd39 6000 > > Signed-off-by: Varun Sethi > Signed-off-by: Joerg Roedel > Signed-off-by: Greg Kroah-Hartman > > --- > drivers/iommu/fsl_pamu_domain.c | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) > > --- a/drivers/iommu/fsl_pamu_domain.c > +++ b/drivers/iommu/fsl_pamu_domain.c > @@ -1050,7 +1050,7 @@ static int fsl_pamu_add_device(struct de > struct iommu_group *group = NULL; > struct pci_dev *pdev; > const u32 *prop; > - int ret, len; > + int ret = 0, len; > > /* >* For platform devices we allocate a separate group for @@ -1073,7 > +1073,13 @@ static int fsl_pamu_add_device(struct de > if (!group || IS_ERR(group)) > return PTR_ERR(group); > > - ret = iommu_group_add_device(group, dev); > + /* > + * Check if device has already been added to an iommu group. > + * Group could have already been created for a PCI device in > + * the iommu_group_get_for_dev path. > + */ > + if (!dev->iommu_group) > + ret = iommu_group_add_device(group, dev); > > iommu_group_put(group); > return ret;
Re: iio commit dates in future
On 03/10/14 23:34, Anssi Hannula wrote: > 13.09.2014, 23:04, Jonathan Cameron kirjoitti: >> On 12/09/14 18:25, Lars-Peter Clausen wrote: >>> On 09/11/2014 10:55 AM, Subbaraya Sundeep Bhatta wrote: This patch fixes incorrect logic for assigning address to auxiliary channels of xilinx xadc. Signed-off-by: Subbaraya Sundeep Bhatta >>> >>> Acked-by: Lars-Peter Clausen >> Applied to the fixes-togreg branch of iio.git and flagged >> for stable. > > Something weird seems to have happened with this commit and at least a > few others: > 1887e724e2 "iio: adc: xilinx-xadc: assign auxiliary channels address > correctly" > d4f51956ac "iio: adc: at91: don't use the last converted data register" > a31d092899 "iio:magnetometer: bugfix magnetometers gain values". > > They all have their Date in the future (up to Nov 2014), looks to me > like month and day got swapped for some reason. > > Not a big issue I guess, but worth looking into if it is something in > your workflow causing this :) > > Noticed these strange Dates while looking at Greg's stable-queue repo. > I have a suspicion that this is to do with the fact I use thunderbird to manage my email and save it out as plain text. I'm using the import export tools package on top of thunderbird (as it gives a cleaner result) but it is using numeric dates. Which git am is happy with, but apparently it isn't coping well with American date formats vs mine. Superficially looks like this is fine if I use the much more verbose alternative of saving as an eml file and using that... There are some dates that have by coincidence jumped a fair way back into the past as well. I did notice an incidence of this a few months back but thought it was just a one off. Thanks for bringing it up Anssi! Jonathan -- 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 2/2] spi: fsl-spi: Allow dynamic allocation of CPM1 parameter RAM
Le 03/10/2014 22:24, Scott Wood a écrit : On Fri, 2014-10-03 at 22:15 +0200, christophe leroy wrote: Le 03/10/2014 16:44, Mark Brown a écrit : On Fri, Oct 03, 2014 at 02:56:09PM +0200, Christophe Leroy wrote: +config CPM1_RELOCSPI + bool "Dynamic SPI relocation" + default n + help + On recent MPC8xx (at least MPC866 and MPC885) SPI can be relocated + without micropatch. This activates relocation to a dynamically + allocated area in the CPM Dual port RAM. + When combined with SPI relocation patch (for older MPC8xx) it avoids + the "loss" of additional Dual port RAM space just above the patch, + which might be needed for example when using the CPM QMC. Something like this shouldn't be a compile time option. Either it should be unconditional or it should be triggered in some system specific manner (from DT, from knowing about other users or similar). Can't be unconditional as older versions of mpc8xx (eg MPC860) don't support relocation without a micropatch. I have therefore submitted a v2 based on a DTS compatible property. So the device tree change is about whether relocation is supported, not whether it is required? Indeed no, my intension is to say that relocation is requested. Do you mean that it should then not use a compatible ? Is this specific to SPI or does the relocation mechanism work for other things? Relocation is the same for I2C. It is also possible to relocate SMC1 and SMC2 parameter RAM but only with a micropatch. Today, the kernel only implements relocation of SMC1, and it relocates it at a fixed address just after SMC2 at offset 0x1FC0. How about checking for the existing specific-SoC compatibles? What do you mean ? Christophe --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.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 v2 2/2] spi: fsl-spi: Allow dynamic allocation of CPM1 parameter RAM
Le 03/10/2014 21:51, Scott Wood a écrit :
On Fri, 2014-10-03 at 18:49 +0200, Christophe Leroy wrote:
On CPM1, the SPI parameter RAM has a default location. In order to use SPI while
using SCC2 with features like QMC or Ethernet, it is necessary to relocate SPI
parameter RAM in a free location in the CPM dual port RAM.
Please explain in more detail why it's necessary.
SCC2 parameter RAM is located at offset 0x1D00 inside the CPM dual port RAM.
SPI parameter RAM is located at offset 0x1D80.
When using SCC2 in Ethernet Mode, the parameter RAM size is 0xA4.
When using SCC2 in QMC mode, the parameter RAM size is 0xAC.
Therefore in both case, it overlaps the SPI parameter RAM which shall
then be relocated.
On MPC860 this can only be done using an additional microcode.
Therefore, the relocation configuration is managed within
arch/powerpc/sysdep/micropatch.c
On MPC866 and MPC885 (at least) no microcode is needed. Therefore, if we
want to relocate the SPI param, we must handle that outside of micropatch.c
Since the SPI driver already handle dynamic parameter RAM allocation for
CPM2, I though it was the good place to do it also for CPM1.
With this patch,
when "fsl,cpm1-spi-reloc" instead of "fsl,cpm1-spi" compatible is set in the
device tree, the parameter RAM for SPI is dynamically allocated
with cpm_muram_alloc().
Signed-off-by: Christophe Leroy
---
Changes from v1 to v2: using OF compatible instead of compile time option
drivers/spi/spi-fsl-cpm.c | 3 +++
drivers/spi/spi-fsl-lib.c | 2 ++
include/linux/fsl_devices.h | 1 +
3 files changed, 6 insertions(+)
diff --git a/drivers/spi/spi-fsl-cpm.c b/drivers/spi/spi-fsl-cpm.c
index 0f3a912..048ca5f 100644
--- a/drivers/spi/spi-fsl-cpm.c
+++ b/drivers/spi/spi-fsl-cpm.c
@@ -261,6 +261,9 @@ static unsigned long fsl_spi_cpm_get_pram(struct
mpc8xxx_spi *mspi)
if (mspi->flags & SPI_CPM2) {
pram_ofs = cpm_muram_alloc(SPI_PRAM_SIZE, 64);
out_be16(spi_base, pram_ofs);
+ } else if (mspi->flags & SPI_CPM1_RELOC) {
+ pram_ofs = cpm_muram_alloc(SPI_PRAM_SIZE, 32);
+ out_be16(spi_base, pram_ofs);
} else {
u16 rpbase = in_be16(spi_base);
diff --git a/drivers/spi/spi-fsl-lib.c b/drivers/spi/spi-fsl-lib.c
index c3f7802..e9db4c5 100644
--- a/drivers/spi/spi-fsl-lib.c
+++ b/drivers/spi/spi-fsl-lib.c
@@ -227,6 +227,8 @@ int of_mpc8xxx_spi_probe(struct platform_device *ofdev)
pdata->flags = SPI_CPM_MODE | SPI_CPM2;
else if (of_device_is_compatible(np, "fsl,cpm1-spi"))
pdata->flags = SPI_CPM_MODE | SPI_CPM1;
+ else if (of_device_is_compatible(np, "fsl,cpm1-spi-reloc"))
+ pdata->flags = SPI_CPM_MODE | SPI_CPM1 | SPI_CPM1_RELOC;
Where's the binding and device tree update for this? What specific
aspect of hardware does it describe?
Well, the intension was not really to describe any specific aspect of
hardware, but to provide an easy way to tell the driver that we want
dynamic reallocation of the parameter RAM.
On CPM2, dynamic allocation of parameter RAM is the only way.
On CPM1:
* The parameter RAM has a default location.
* When the SPI relocation micropatch is applied, the kernel reallocate
it just after the patch, when loading the patch. This is not good for
using QMC, because it is within the part of dual port RAM used by the
QMC, therefore it reduce even more the number of channels that the QMC
can use.
The bindings for that driver are described in
Documentation/devicetree/bindings/spi/fsl-spi.txt. But it seems that it
doesn't describe anything related to those compatibles. The driver has a
match on "fsl,fsl-spi" only, and for using it with CPM you have to add
"fsl,cpm1-spi" or "fsl,cpm2-spi" to tell the driver that it is CPM
(existing code below).
prop = of_get_property(np, "mode", NULL);
if (prop && !strcmp(prop, "cpu-qe"))
pdata->flags = SPI_QE_CPU_MODE;
else if (prop && !strcmp(prop, "qe"))
pdata->flags = SPI_CPM_MODE | SPI_QE;
else if (of_device_is_compatible(np, "fsl,cpm2-spi"))
pdata->flags = SPI_CPM_MODE | SPI_CPM2;
else if (of_device_is_compatible(np, "fsl,cpm1-spi"))
pdata->flags = SPI_CPM_MODE | SPI_CPM1;
Christophe
---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce
que la protection avast! Antivirus est active.
http://www.avast.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: [x86, locking/rwlocks, btrfs] INFO: rcu_sched self-detected stall on CPU
On Fri, 03 Oct 2014 23:27:58 -0400
Waiman Long wrote:
> On 10/03/2014 09:33 AM, Fengguang Wu wrote:
> > Hi Waiman,
> >
> > FYI, we noticed the below changes on commit
> >
> > bd01ec1a13f9a327950c8e3080096446c7804753 ("x86, locking/rwlocks: Enable
> > qrwlocks on x86")
> >
> > +--+++
> > | | 70af2f8a4f | bd01ec1a13 |
> > +--+++
> > | boot_successes | 3 | 2 |
> > | boot_failures| 7 | 13 |
> > | BUG:kernel_test_crashed | 7 | 8 |
> > | INFO:rcu_sched_self-detected_stall_on_CPU| 0 | 4 |
> > | RIP:intel_idle | 0 | 4 |
> > | RIP:queue_write_lock_slowpath| 0 | 4 |
> > | RIP:queue_read_lock_slowpath | 0 | 4 |
> > | RIP:sys_imageblit_sysimgblt | 0 | 2 |
> > | RIP:default_send_IPI_mask_sequence_phys | 0 | 1 |
> > | RIP:memcpy | 0 | 1 |
> > | RIP:delay_tsc| 0 | 4 |
> > | backtrace:cpu_startup_entry | 0 | 3 |
> > | backtrace:do_fsync | 0 | 4 |
> > | backtrace:SyS_fsync | 0 | 4 |
> > | backtrace:normal_work_helper | 0 | 1 |
> > | backtrace:vfs_write | 0 | 3 |
> > | backtrace:SyS_write | 0 | 3 |
> > | backtrace:do_sys_open| 0 | 4 |
> > | backtrace:SyS_open | 0 | 4 |
> > | backtrace:flush_to_ldisc | 0 | 1 |
> > | RIP:cpu_startup_entry| 0 | 1 |
> > | RIP:native_read_tsc | 0 | 2 |
> > | RIP:rcu_eqs_exit_common | 0 | 1 |
> > | INFO:rcu_sched_detected_stalls_on_CPUs/tasks | 0 | 1 |
> > +--+++
> >
> >
> > run: /lkp/lkp/src/monitors/wrapper sched_debug {"interval"=>"10"}
> > run: /usr/bin/time -v -o /lkp/lkp/src/tmp/time /lkp/lkp/src/tests/wrapper
> > fsmark{"filesize"=>"9B", "test_size"=>"400M",
> > "sync_method"=>"fsyncBeforeClose", "nr_directories"=>"16d",
> > "nr_files_per_directory"=>"256fpd"}
> > run: /lkp/lkp/src/monitors/wrapper pmeter {}
> > [ 125.656200] INFO: rcu_sched self-detected stall on CPU
> > [ 125.657199] INFO: rcu_sched self-detected stall on CPUINFO: rcu_sched
> > self-detected stall on CPUINFO: rcu_sched self-detected stall on CPUINFO:
> > rcu_sched self-detected stall on CPU { { { { 0 9 7 14} } } } (t=10
> > jiffies g=1792 c=1791 q=0)
> > [ 125.657218] (t=10 jiffies g=1792 c=1791 q=0)
> > [ 125.657219] (t=10 jiffies g=1792 c=1791 q=0)
> > [ 125.657221] (t=10 jiffies g=1792 c=1791 q=0)
> > [ 125.657222] sending NMI to all CPUs:
> > [ 125.657224] NMI backtrace for cpu 0
> > [ 125.657227] CPU: 0 PID: 3025 Comm: fs_mark Not tainted 3.16.0 #1
> > [ 125.657227] Hardware name: Intel Corporation S5520UR/S5520UR, BIOS
> > S5500.86B.01.00.0050.050620101605 05/06/2010
> > [ 125.657228] task: 88007ef58000 ti: 88007ef54000 task.ti:
> > 88007ef54000
> > [ 125.657229] RIP: 0010:[] []
> > native_read_tsc+0x6/0x20
> > [ 125.657236] RSP: 0018:88036fc03d20 EFLAGS: 0002
> > [ 125.657237] RAX: 3f172acf RBX: 3f172ab0 RCX:
> > 0028
> > [ 125.657238] RDX: 14e5 RSI: 0018 RDI:
> > 0004773a
> > [ 125.657238] RBP: 88036fc03d20 R08: 81da2200 R09:
> > 0092
> > [ 125.657239] R10: 14e53edc9480 R11: 0008 R12:
> > 0004773a
> > [ 125.657239] R13: R14: 0002 R15:
> > 0001
> > [ 125.657241] FS: 01ee0880(0063) GS:88036fc0()
> > knlGS:
> > [ 125.657241] CS: 0010 DS: ES: CR0: 8005003b
> > [ 125.657242] CR2: 0061c000 CR3: 7ef3c000 CR4:
> > 07f0
> > [ 125.657243] Stack:
> > [ 125.657243] 88036fc03d48 813f85e3 1000
> > 03e9
> > [ 125.657244] 0400 88036fc03d58 813f8538
> > 88036fc03d78
> > [ 125.657246] 81046d1a b032 81da2200
> > 88036fc03dc0
> > [ 125.657247] Call Trace:
> > [ 125.657247] [] delay_tsc+0x43/0x90
> > [ 125.657253] []
[RFC 1/1] net: fix rcu access on phonet_routes
-Add __rcu annotation on table to fix sparse warnings:
net/phonet/pn_dev.c:279:25: warning: incorrect type in assignment (different
address spaces)
net/phonet/pn_dev.c:279:25:expected struct net_device *
net/phonet/pn_dev.c:279:25:got void [noderef] *
net/phonet/pn_dev.c:376:17: warning: incorrect type in assignment (different
address spaces)
net/phonet/pn_dev.c:376:17:expected struct net_device *volatile
net/phonet/pn_dev.c:376:17:got struct net_device [noderef] *
net/phonet/pn_dev.c:392:17: warning: incorrect type in assignment (different
address spaces)
net/phonet/pn_dev.c:392:17:expected struct net_device *
net/phonet/pn_dev.c:392:17:got void [noderef] *
-Access table with rcu_dereference (fixes the following sparse errors):
net/phonet/pn_dev.c:278:25: error: incompatible types in comparison expression
(different address spaces)
net/phonet/pn_dev.c:391:17: error: incompatible types in comparison expression
(different address spaces)
Signed-off-by: Fabian Frederick
---
net/phonet/pn_dev.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/phonet/pn_dev.c b/net/phonet/pn_dev.c
index 56a6146..5c9c0b2f1 100644
--- a/net/phonet/pn_dev.c
+++ b/net/phonet/pn_dev.c
@@ -36,7 +36,7 @@
struct phonet_routes {
struct mutexlock;
- struct net_device *table[64];
+ struct net_device __rcu *table[64];
};
struct phonet_net {
@@ -275,7 +275,7 @@ static void phonet_route_autodel(struct net_device *dev)
bitmap_zero(deleted, 64);
mutex_lock(>routes.lock);
for (i = 0; i < 64; i++)
- if (dev == pnn->routes.table[i]) {
+ if (rcu_dereference(pnn->routes.table[i]) == dev) {
RCU_INIT_POINTER(pnn->routes.table[i], NULL);
set_bit(i, deleted);
}
@@ -388,7 +388,7 @@ int phonet_route_del(struct net_device *dev, u8 daddr)
daddr = daddr >> 2;
mutex_lock(>lock);
- if (dev == routes->table[daddr])
+ if (rcu_dereference(routes->table[daddr]) == dev)
RCU_INIT_POINTER(routes->table[daddr], NULL);
else
dev = NULL;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers/net/can/m_can/Kconfig: Let CAN_M_CAN depend on HAS_IOMEM
CAN_M_CAN needs HAS_IOMEM, so depend on it, the related error (with allmodconfig under um): MODPOST 1205 modules ERROR: "devm_ioremap" [drivers/net/can/m_can/m_can.ko] undefined! ERROR: "devm_ioremap_resource" [drivers/net/can/m_can/m_can.ko] undefined! Signed-off-by: Chen Gang --- drivers/net/can/m_can/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig index fca5482..14c9fcf 100644 --- a/drivers/net/can/m_can/Kconfig +++ b/drivers/net/can/m_can/Kconfig @@ -1,4 +1,5 @@ config CAN_M_CAN tristate "Bosch M_CAN devices" + depends on HAS_IOMEM ---help--- Say Y here if you want to support for Bosch M_CAN controller. -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/4] hwmon: ltc2978: device tree bindings documentation
On Fri, Oct 03, 2014 at 04:23:15PM -0700, Guenter Roeck wrote:
> On 10/03/2014 04:13 PM, Mark Brown wrote:
> >Nope, nothing to do with regulator that I'm aware of and I've not seen
> >any examples (but I don't tend to review users too often).
> Many examples, really. Just picking one.
> Documentation/devicetree/bindings/mfd/tps6507x.txt
OK, that's not an actual DTS... I'm not seeing anything in the code.
> regulators {
> #address-cells = <1>;
> #size-cells = <0>;
> ...
> This also uses the reg property for the regulator index
> (without explaining it further). Seems to be pretty common.
If it's doing that it's nothing to do with the regulator API.
signature.asc
Description: Digital signature
