date:20130201

(forgot to cc Kirill A. Shutemov , added)

On 2013/2/2 14:50, Li Zefan wrote:
> There're three bugs.
> 
> - If thread A is removing a cgroup, while thread B is closing an eventfd, the
> two threads might free the same cgroup event and thus crash the kernel.
> 
> This is fixed by patch #1 and patch #2.
> 
> - If there're multiple threads are blocking in read() on the same eventfd,
> and someone removes the cgroup, only one thread will be notified and 
> unblocked,
> and others won't be unblocked until those threads are killed.
> 
> - If thread A is removing a cgroup, while thread B is registering a cgroup 
> event
> and then read the eventfd, it might block until the thread is killed.
> 
> These two are fixed by patch #3.
> 
> 0001-eventfd-Introduce-eventfd_signal_hangup.patch
> 0002-cgroup-fix-cgroup_rmdir-vs-close-eventfd-race.patch
> 0003-eventfd-make-operations-on-eventfd-return-EIDRM-if-i.patch
> 0004-cgroup-adapt-to-the-new-way-of-detecting-cgroup-remo.patch
> 
> --
>  fs/eventfd.c | 30 ++
>  include/linux/eventfd.h  |  5 +
>  kernel/cgroup.c  | 30 ++
>  tools/cgroup/cgroup_event_listener.c | 12 +---
>  4 files changed, 58 insertions(+), 19 deletions(-)
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/4] cgroup: adapt to the new way of detecting cgroup removal

If read() returns with errno == EIDRM, we know the cgroup has been
removed.

Signed-off-by: Li Zefan 
---
 tools/cgroup/cgroup_event_listener.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/tools/cgroup/cgroup_event_listener.c 
b/tools/cgroup/cgroup_event_listener.c
index 4eb5507..19e3d4a 100644
--- a/tools/cgroup/cgroup_event_listener.c
+++ b/tools/cgroup/cgroup_event_listener.c
@@ -62,18 +62,16 @@ int main(int argc, char **argv)
if (ret == -1) {
if (errno == EINTR)
continue;
-   err(1, "Cannot read from eventfd");
+   if (errno != EIDRM)
+   err(1, "Cannot read from eventfd");
}
-   assert(ret == sizeof(result));
 
-   ret = access(event_control_path, W_OK);
-   if ((ret == -1) && (errno == ENOENT)) {
-   puts("The cgroup seems to have removed.");
+   if (ret == -1 && errno == EIDRM) {
+   puts("The cgroup has been removed.");
break;
}
 
-   if (ret == -1)
-   err(1, "cgroup.event_control is not accessible any 
more");
+   assert(ret == sizeof(result));
 
printf("%s %s: crossed\n", argv[1], argv[2]);
}
-- 
1.8.0.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/4] eventfd: make operations on eventfd return -EIDRM if it's hung up

Currently when a cgroup is removed, it calls eventfd_signal() for
each registered cgroup event, so userspace can be notified and blocked
reads can be unblocked.

The problem is, if we have multiple threads blocked on the same eventfd,
only one of them will be unlocked.

This patch makes sure all operations on the same eventfd can be unbocked.

There's another problem, a new cgroup event can be registered while we
are removing the cgroup, and then reading the eventfd will be blocked
until the thread is killed. This patch also fixes this issue.

Signed-off-by: Li Zefan 
---
 fs/eventfd.c| 23 +--
 kernel/cgroup.c |  1 -
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/fs/eventfd.c b/fs/eventfd.c
index acf15e3..48de15a 100644
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@ -35,6 +35,7 @@ struct eventfd_ctx {
 */
__u64 count;
unsigned int flags;
+   bool hung_up;
 };
 
 /**
@@ -71,11 +72,19 @@ EXPORT_SYMBOL_GPL(eventfd_signal);
  * eventfd_signal_hangup - Notify that this eventfd is hung up.
  * @ctx: [in] Pointer to the eventfd context.
  *
- * Issue a POLLHUP wakeup.
+ * Issue a POLLHUP wakeup. All current blocked reads, writes and polls on
+ * this eventfd will return with -EIDRM. Future operations on it will also
+ * return with -EDIRM.
  */
 void eventfd_signal_hangup(struct eventfd_ctx *ctx)
 {
-   wake_up_poll(>wqh, POLLHUP);
+   unsigned long flags;
+
+   spin_lock_irqsave(>wqh.lock, flags);
+   ctx->hung_up = true;
+   if (waitqueue_active(>wqh))
+   wake_up_locked_poll(>wqh, POLLHUP);
+   spin_unlock_irqrestore(>wqh.lock, flags);
 }
 
 static void eventfd_free_ctx(struct eventfd_ctx *ctx)
@@ -140,6 +149,8 @@ static unsigned int eventfd_poll(struct file *file, 
poll_table *wait)
events |= POLLERR;
if (ULLONG_MAX - 1 > ctx->count)
events |= POLLOUT;
+   if (ctx->hung_up)
+   events |= POLLHUP;
spin_unlock_irqrestore(>wqh.lock, flags);
 
return events;
@@ -208,6 +219,10 @@ ssize_t eventfd_ctx_read(struct eventfd_ctx *ctx, int 
no_wait, __u64 *cnt)
__add_wait_queue(>wqh, );
for (;;) {
set_current_state(TASK_INTERRUPTIBLE);
+   if (ctx->hung_up) {
+   res = -EIDRM;
+   break;
+   }
if (ctx->count > 0) {
res = 0;
break;
@@ -272,6 +287,10 @@ static ssize_t eventfd_write(struct file *file, const char 
__user *buf, size_t c
__add_wait_queue(>wqh, );
for (res = 0;;) {
set_current_state(TASK_INTERRUPTIBLE);
+   if (ctx->hung_up) {
+   res = -EIDRM;
+   break;
+   }
if (ULLONG_MAX - ctx->count > ucnt) {
res = sizeof(ucnt);
break;
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index a3d361b..fcb1ab6 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -4373,7 +4373,6 @@ static int cgroup_destroy_locked(struct cgroup *cgrp)
ctx = eventfd_ctx_get(event->eventfd);
spin_unlock(>event_list_lock);
 
-   eventfd_signal(ctx, 1);
eventfd_signal_hangup(ctx);
eventfd_ctx_put(ctx);
 
-- 
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/4] cgroup: bug fixes for eventfd

There're three bugs.

- If thread A is removing a cgroup, while thread B is closing an eventfd, the
two threads might free the same cgroup event and thus crash the kernel.

This is fixed by patch #1 and patch #2.

- If there're multiple threads are blocking in read() on the same eventfd,
and someone removes the cgroup, only one thread will be notified and unblocked,
and others won't be unblocked until those threads are killed.

- If thread A is removing a cgroup, while thread B is registering a cgroup event
and then read the eventfd, it might block until the thread is killed.

These two are fixed by patch #3.

0001-eventfd-Introduce-eventfd_signal_hangup.patch
0002-cgroup-fix-cgroup_rmdir-vs-close-eventfd-race.patch
0003-eventfd-make-operations-on-eventfd-return-EIDRM-if-i.patch
0004-cgroup-adapt-to-the-new-way-of-detecting-cgroup-remo.patch

--
 fs/eventfd.c | 30 ++
 include/linux/eventfd.h  |  5 +
 kernel/cgroup.c  | 30 ++
 tools/cgroup/cgroup_event_listener.c | 12 +---
 4 files changed, 58 insertions(+), 19 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/4] cgroup: fix cgroup_rmdir() vs close(eventfd) race

commit 205a872bd6f9a9a09ef035ef1e90185a8245cc58 ("cgroup: fix lockdep
warning for event_control") sovled a deadlock by introducing a new
bug.

We can't access @event without event_list_lock, otherwise we'll race
with cgroup_event_wake() called when closing the eventfd, and then
both threads will try to free the same @event.

CPU0  CPU1
---   -
cgroup_rmdir()close(eventfd)
  list_for_each_entry() cgroup_event_wake()
  list_del(event)
list_del(event)
cgroup_event_remove(event)
  cgroup_event_remove(event)

To fix this, use the new eventfd_signal_hangup() to notify userspace
cgroup is removed.

Signed-off-by: Li Zefan 
---
 kernel/cgroup.c | 31 +++
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 3d21adf..a3d361b 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -4302,9 +4302,9 @@ static int cgroup_destroy_locked(struct cgroup *cgrp)
struct dentry *d = cgrp->dentry;
struct cgroup *parent = cgrp->parent;
DEFINE_WAIT(wait);
-   struct cgroup_event *event, *tmp;
+   struct eventfd_ctx *ctx;
+   struct cgroup_event *event;
struct cgroup_subsys *ss;
-   LIST_HEAD(tmp_list);
 
lockdep_assert_held(>d_inode->i_mutex);
lockdep_assert_held(_mutex);
@@ -4359,20 +4359,27 @@ static int cgroup_destroy_locked(struct cgroup *cgrp)
/*
 * Unregister events and notify userspace.
 * Notify userspace about cgroup removing only after rmdir of cgroup
-* directory to avoid race between userspace and kernelspace. Use
-* a temporary list to avoid a deadlock with cgroup_event_wake(). Since
+* directory to avoid race between userspace and kernelspace. Since
 * cgroup_event_wake() is called with the wait queue head locked,
-* remove_wait_queue() cannot be called while holding event_list_lock.
+* eventfd_signal() cannot be called while holding event_list_lock.
 */
spin_lock(>event_list_lock);
-   list_splice_init(>event_list, _list);
-   spin_unlock(>event_list_lock);
-   list_for_each_entry_safe(event, tmp, _list, list) {
-   list_del_init(>list);
-   remove_wait_queue(event->wqh, >wait);
-   eventfd_signal(event->eventfd, 1);
-   schedule_work(>remove);
+   while (true) {
+   if (list_empty(>event_list))
+   break;
+
+   event = list_first_entry(>event_list,
+struct cgroup_event, list);
+   ctx = eventfd_ctx_get(event->eventfd);
+   spin_unlock(>event_list_lock);
+
+   eventfd_signal(ctx, 1);
+   eventfd_signal_hangup(ctx);
+   eventfd_ctx_put(ctx);
+
+   spin_lock(>event_list_lock);
}
+   spin_unlock(>event_list_lock);
 
return 0;
 }
-- 
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/4] eventfd: introduce eventfd_signal_hangup()

When an eventfd is closed, a wakeup with POLLHUP will be issued,
but cgroup wants to issue wakeup explicitly, so when a cgroup is
removed userspace can be notified.

Signed-off-by: Li Zefan 
---
 fs/eventfd.c| 11 +++
 include/linux/eventfd.h |  5 +
 2 files changed, 16 insertions(+)

diff --git a/fs/eventfd.c b/fs/eventfd.c
index 35470d9..acf15e3 100644
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@ -67,6 +67,17 @@ __u64 eventfd_signal(struct eventfd_ctx *ctx, __u64 n)
 }
 EXPORT_SYMBOL_GPL(eventfd_signal);
 
+/**
+ * eventfd_signal_hangup - Notify that this eventfd is hung up.
+ * @ctx: [in] Pointer to the eventfd context.
+ *
+ * Issue a POLLHUP wakeup.
+ */
+void eventfd_signal_hangup(struct eventfd_ctx *ctx)
+{
+   wake_up_poll(>wqh, POLLHUP);
+}
+
 static void eventfd_free_ctx(struct eventfd_ctx *ctx)
 {
kfree(ctx);
diff --git a/include/linux/eventfd.h b/include/linux/eventfd.h
index 3c3ef19..68af706 100644
--- a/include/linux/eventfd.h
+++ b/include/linux/eventfd.h
@@ -35,6 +35,7 @@ struct file *eventfd_fget(int fd);
 struct eventfd_ctx *eventfd_ctx_fdget(int fd);
 struct eventfd_ctx *eventfd_ctx_fileget(struct file *file);
 __u64 eventfd_signal(struct eventfd_ctx *ctx, __u64 n);
+void eventfd_signal_hangup(struct eventfd_ctx *ctx);
 ssize_t eventfd_ctx_read(struct eventfd_ctx *ctx, int no_wait, __u64 *cnt);
 int eventfd_ctx_remove_wait_queue(struct eventfd_ctx *ctx, wait_queue_t *wait,
  __u64 *cnt);
@@ -60,6 +61,10 @@ static inline int eventfd_signal(struct eventfd_ctx *ctx, 
int n)
return -ENOSYS;
 }
 
+static inline void eventfd_signal_hangup(struct eventfd_ctx *ctx)
+{
+}
+
 static inline void eventfd_ctx_put(struct eventfd_ctx *ctx)
 {
 
-- 
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] udf: add extent cache support in case of file reading

2013-02-01 Thread Namjae Jeon

Hi. Jan.

Sorry for interrupt.
Have you taken this patch to your tree ? I can not find it..
or Is there any issue regarding this patch ?

Thanks!

2013/1/22, Namjae Jeon :
> 2013/1/22, Jan Kara :
>> On Tue 22-01-13 09:45:09, Namjae Jeon wrote:
>>> 2013/1/21, Jan Kara :
>>> > @@ -,6 +2219,8 @@ int udf_read_extent_cache(struct inode *inode,
>>> > loff_t
>>> > bcount,
>>> >   *lbcount = iinfo->cached_extent.lstart;
>>> >   memcpy(pos, >cached_extent.epos,
>>> >  sizeof(struct extent_position));
>>> > + if (pos->bh)
>>> > + get_bh(pos->bh);
>>> >   spin_unlock(>i_extent_cache_lock);
>>> >   return 1;
>>> >   } else
>>> >   This is the most important - we should give buffer reference to
>>> > pos->bh.
>>> > Caller will eventually free it right?
>>> This change is not required as we give buffer reference to pos->bh at
>>> the time of cache update.
>>> When we start reading a file, first we try to read the cache which
>>> will lead to cache miss.
>>> So, we would really access the pos->bh in udf_update_extent_cache for
>>> the first time, and this is where the buffer reference is incremented.
>>> Calling get_bh at 2 places will eventually lead to mem leak.
>>> Let me know your opinion.
>>   Yes, udf_update_extent_cache() gets its own reference to bh but that is
>> dropped in udf_clear_extent_cache(). So I think udf_read_extent_cache()
>> needs to get a reference to the caller (as the caller will eventually
>> free
>> the bh via brelse(epos.bh) e.g. in udf_extend_file(). Also I realized
>> udf_update_extent_cache() needs to first clear the cache if it is valid.
>> Otherwise it just overwrites bh pointer and reference is leaked. Is it
>> clearer now?
> Yes, you're right. Also, this patch looks good to me.
>>
>>   I've also changed locking of udf_clear_extent_cache() so that
>> i_extent_cache_lock is always taken for that function - it makes the
>> locking rules obvious at the first sight.
> Yes, right. it is needed.
> When we test with this patch, working fine.
> Thanks Jan!
>>
>>   Attached is the patch I currently carry.
>>
>>  Honza
>>
>> --
>> Jan Kara 
>> SUSE Labs, CR
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 05/12] iommu/exynos: support for device tree

2013-02-01 Thread KyongHo Cho

On Fri, Feb 1, 2013 at 10:51 PM, Joerg Roedel  wrote:
> Cho,
>
> On Wed, Jan 02, 2013 at 02:53:49PM +0900, KyongHo Cho wrote:
>> On Tuesday, January 1, 2013, Sylwester Nawrocki 
>> 
>
>> > Cc: devicetree-disc...@lists.ozlabs.org
>
> Since patch 7 of this set is already merged, do you mind to re-post the
> rest of this patch-set with the latest comments addressed? I can have a
> look at it again then and consider it for 3.9.
>
Thank you for your considerations.

I also think that I need to post the patch set again with some fixes that are
addressed in the comments.

Due to the heavy workload in my business I have hardly had a chance to
handle this patch-set.
As soon as the business lets me handle other pending issues, I will
work on this patchset.
I think I can start to it in the next 2 weeks.

Thank you.

KyongHo.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: build warning after merge of the tip tree

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:

arch/x86/mm/numa.c: In function 'setup_node_data':
arch/x86/mm/numa.c:222:3: warning: passing argument 1 of '__phys_addr_nodebug' 
makes integer from pointer without a cast [enabled by default]
arch/x86/include/asm/page_64.h:12:29: note: expected 'long unsigned int' but 
argument is of type 'void *'

Introduced by commit a25b9316841c ("x86, mm: Make DEBUG_VIRTUAL work
earlier in boot").
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpXp5EUxL5Fy.pgp
Description: PGP signature

linux-next: build warning after merge of the tip tree

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:

arch/x86/kernel/kvm.c: At top level:
arch/x86/kernel/kvm.c:509:2: warning: initialization from incompatible pointer 
type [enabled by default]
arch/x86/kernel/kvm.c:509:2: warning: (near initialization for 
'x86_hyper_kvm.x2apic_available') [enabled by default]

Introduced by commit 4cca6ea04d31 ("x86/apic: Allow x2apic without IR on
VMware platform").
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp34ZuUX_q9y.pgp
Description: PGP signature

Re: [PATCH 3/6] cpufreq: Do not track governor name for scaling drivers with internal governors.

On 2 February 2013 11:14, Dirk Brandewie  wrote:
> Hi viresh,
>
> This is based on 3.8-rc5.  I think this should work against bleeding_edge
> but I have not tested against bleeding_edge

Rafael wouldn't be able to apply these patches. There are a lot of core patches
present in bleeding_edge.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the kvm tree with Linus' tree

Hi all,

Today's linux-next merge of the kvm tree got a conflict in
arch/x86/include/asm/vmx.h between commit af170c5061dd ("UAPI: (Scripted)
Disintegrate arch/x86/include/asm") from Linus' tree and commits
83d4c286931c ("x86, apicv: add APICv register virtualization support")
and c7c9c56ca26f ("x86, apicv: add virtual interrupt delivery support")
from the kvm tree.

I fixed it up (by applying the merge fix patch below) and can carry the
fix as necessary (no action is required).

From: Stephen Rothwell 
Date: Sat, 2 Feb 2013 16:43:02 +1100
Subject: [PATCH] x86, apicv: merge fixup for uapi include file split

Signed-off-by: Stephen Rothwell 
---
 arch/x86/include/uapi/asm/vmx.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/include/uapi/asm/vmx.h b/arch/x86/include/uapi/asm/vmx.h
index 979d03b..9a74505 100644
--- a/arch/x86/include/uapi/asm/vmx.h
+++ b/arch/x86/include/uapi/asm/vmx.h
@@ -62,10 +62,12 @@
 #define EXIT_REASON_MCE_DURING_VMENTRY  41
 #define EXIT_REASON_TPR_BELOW_THRESHOLD 43
 #define EXIT_REASON_APIC_ACCESS 44
+#define EXIT_REASON_EOI_INDUCED 45
 #define EXIT_REASON_EPT_VIOLATION   48
 #define EXIT_REASON_EPT_MISCONFIG   49
 #define EXIT_REASON_WBINVD  54
 #define EXIT_REASON_XSETBV  55
+#define EXIT_REASON_APIC_WRITE  56
 #define EXIT_REASON_INVPCID 58
 
 #define VMX_EXIT_REASONS \
-- 
1.8.1

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpdDyPuu9oJ6.pgp
Description: PGP signature

linux-next: build warning after merge of the tip tree

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:

arch/x86/kernel/kvm.c: In function 'kvm_register_steal_time':
arch/x86/kernel/kvm.c:302:3: warning: format '%lx' expects argument of type 
'long unsigned int', but argument 3 has type 'phys_addr_t' [-Wformat]

Introduced by commit 5dfd486c4750 ("x86, kvm: Fix kvm's use of __pa() on
percpu areas").

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpKZq1GypVXI.pgp
Description: PGP signature

Re: [PATCH 5/6] cpufreq: balance out cpufreq_cpu_{get,put} for scaling drivers using setpolicy

On Sat, Feb 2, 2013 at 12:15 AM,   wrote:
> From: Dirk Brandewie 
>
> There is an additional reference added to the driver in
> cpufreq_add_dev_policy() that is removed in__cpufreq_governor() if the
> driver implements target().  Remove the last reference when the driver
> implements setpolicy()
>
> Signed-off-by: Dirk Brandewie 

Rebase it on latest work as cpufreq_add_dev_policy() doesn't exist anymore.

> ---
>  drivers/cpufreq/cpufreq.c |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index a4fd51e..ec103bf 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1119,6 +1119,9 @@ static int __cpufreq_remove_dev(struct device *dev, 
> struct subsys_interface *sif
> if (cpufreq_driver->target)
> __cpufreq_governor(data, CPUFREQ_GOV_STOP);
>
> +   if (cpufreq_driver->setpolicy)
> +   cpufreq_cpu_put(data);
> +
> kobj = >kobj;
> cmp = >kobj_unregister;
> unlock_policy_rwsem_write(cpu);
> --
> 1.7.7.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] cpufreq_stats: Do not track policies without associated governors.

On Sat, Feb 2, 2013 at 12:15 AM,   wrote:
> From: Dirk Brandewie 
>
> Scaling drivers that implement internal governors do not have governor
> sturctures associated with them.  Do not create/remove statisitcs
> entries for polices that do not have governors associated with them.
>
> Signed-off-by: Dirk Brandewie 

It is not based of latest work.

Why don't we want stats to be updated for these? What does stats have
to do with governor?

> ---
>  drivers/cpufreq/cpufreq_stats.c |4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
> index 9d7732b..8a1daf4 100644
> --- a/drivers/cpufreq/cpufreq_stats.c
> +++ b/drivers/cpufreq/cpufreq_stats.c
> @@ -183,7 +183,7 @@ static void cpufreq_stats_free_table(unsigned int cpu)
>  static void cpufreq_stats_free_sysfs(unsigned int cpu)
>  {
> struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
> -   if (policy && policy->cpu == cpu)
> +   if (policy && policy->cpu == cpu && policy->governor)
> sysfs_remove_group(>kobj, _attr_group);
> if (policy)
> cpufreq_cpu_put(policy);
> @@ -271,6 +271,8 @@ static int cpufreq_stat_notifier_policy(struct 
> notifier_block *nb,
> unsigned int cpu = policy->cpu;
> if (val != CPUFREQ_NOTIFY)
> return 0;
> +   if (!policy->governor)
> +   return 0;
> table = cpufreq_frequency_get_table(cpu);
> if (!table)
> return 0;
> --
> 1.7.7.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: build failure after merge of the tip tree

Hi all,

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

arch/powerpc/perf/power7-pmu.c:397:2: error: initialization from incompatible 
pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:397:2: error: (near initialization for 
'power7_events_attr[0]') [-Werror]
arch/powerpc/perf/power7-pmu.c:398:2: error: initialization from incompatible 
pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:398:2: error: (near initialization for 
'power7_events_attr[1]') [-Werror]
arch/powerpc/perf/power7-pmu.c:399:2: error: initialization from incompatible 
pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:399:2: error: (near initialization for 
'power7_events_attr[2]') [-Werror]
arch/powerpc/perf/power7-pmu.c:400:2: error: initialization from incompatible 
pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:400:2: error: (near initialization for 
'power7_events_attr[3]') [-Werror]
arch/powerpc/perf/power7-pmu.c:401:2: error: initialization from incompatible 
pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:401:2: error: (near initialization for 
'power7_events_attr[4]') [-Werror]
arch/powerpc/perf/power7-pmu.c:402:2: error: initialization from incompatible 
pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:402:2: error: (near initialization for 
'power7_events_attr[5]') [-Werror]
arch/powerpc/perf/power7-pmu.c:403:2: error: initialization from incompatible 
pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:403:2: error: (near initialization for 
'power7_events_attr[6]') [-Werror]
arch/powerpc/perf/power7-pmu.c:404:2: error: initialization from incompatible 
pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:404:2: error: (near initialization for 
'power7_events_attr[7]') [-Werror]
arch/powerpc/perf/power7-pmu.c:406:2: error: initialization from incompatible 
pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:406:2: error: (near initialization for 
'power7_events_attr[8]') [-Werror]
arch/powerpc/perf/power7-pmu.c:407:2: error: initialization from incompatible 
pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:407:2: error: (near initialization for 
'power7_events_attr[9]') [-Werror]
arch/powerpc/perf/power7-pmu.c:408:2: error: initialization from incompatible 
pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:408:2: error: (near initialization for 
'power7_events_attr[10]') [-Werror]
arch/powerpc/perf/power7-pmu.c:409:2: error: initialization from incompatible 
pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:409:2: error: (near initialization for 
'power7_events_attr[11]') [-Werror]
arch/powerpc/perf/power7-pmu.c:410:2: error: initialization from incompatible 
pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:410:2: error: (near initialization for 
'power7_events_attr[12]') [-Werror]
arch/powerpc/perf/power7-pmu.c:411:2: error: initialization from incompatible 
pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:411:2: error: (near initialization for 
'power7_events_attr[13]') [-Werror]
arch/powerpc/perf/power7-pmu.c:412:2: error: initialization from incompatible 
pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:412:2: error: (near initialization for 
'power7_events_attr[14]') [-Werror]
arch/powerpc/perf/power7-pmu.c:413:2: error: initialization from incompatible 
pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:413:2: error: (near initialization for 
'power7_events_attr[15]') [-Werror]

Caused by commit 1c53a270724d ("perf/POWER7: Make generic event
translations available in sysfs").

I have used the tip tree from 20130128 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp7Hn9uNZUOP.pgp
Description: PGP signature

[RESEND] [PATCH] kernel/res_counter.c: remove useless return statement at res_counter_member()

2013-02-01 Thread Jeff Liu

The return statement after BUG() is invalid, move BUG() to the default choice 
of the switch.

Signed-off-by: Jie Liu 
---
 kernel/res_counter.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/kernel/res_counter.c b/kernel/res_counter.c
index ff55247..748a3bc 100644
--- a/kernel/res_counter.c
+++ b/kernel/res_counter.c
@@ -135,10 +135,9 @@ res_counter_member(struct res_counter *counter, int member)
return >failcnt;
case RES_SOFT_LIMIT:
return >soft_limit;
+   default:
+   BUG();
};
-
-   BUG();
-   return NULL;
 }
 
 ssize_t res_counter_read(struct res_counter *counter, int member,
-- 
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

CPU hotplug hang due to "swap: make each swap partition have one address_space"

2013-02-01 Thread Stephen Warren

Shaohua,

In next-20130128, commit 174f064 "swap: make each swap partition have
one address_space" (from the mm/akpm tree) appears causes a hang/RCU
stall for me when hot-unplugging a CPU.

I'm running on a quad-core ARM system, and hot-unplugging a CPU using:

echo 0 > /sys/devices/system/cpu/cpu2/online

CONFIG_SWAP is enabled, but I don't have any swap devices activated.

If I either disable CONFIG_SWAP, or revert commit 174f064, then CPU
hotplug works fine for me.

I read through the patch and didn't see anything obvious, but I'm not
remotely familiar with the code in question.

Do you have any idea what might be wrong? Thanks.

The RCU stall kernel log is:

> [   36.152471] CPU2: shutdown
> [   57.151682] INFO: rcu_sched self-detected stall on CPU { 1}  (t=2100 
> jiffies g=4294966997 c=4294966996 q=1)
> [   57.164730] [] (unwind_backtrace+0x0/0xf8) from [] 
> (rcu_check_callbacks+0x360/0x81c)
> [   57.177468] [] (rcu_check_callbacks+0x360/0x81c) from 
> [] (update_process_times+0x38/0x64)
> [   57.182152] INFO: rcu_sched detected stalls on CPUs/tasks: { 1} (detected 
> by 3, t=2103 jiffies, g=4294966997, c=4294966996, q=1)
> [   57.182154] Task dump for CPU 1:
> [   57.182162] sh  R running  0   569568 0x0002
> [   57.182200] [] (__schedule+0x33c/0x6ac) from [] 
> (__irq_svc+0x40/0x70)
> [   57.182211] [] (__irq_svc+0x40/0x70) from [] 
> (_raw_spin_unlock_irqrestore+0x28/0x50)
> [   57.182221] [] (_raw_spin_unlock_irqrestore+0x28/0x50) from 
> [] (percpu_counter_hotcpu_callback+0x68/0x9c)
> [   57.182235] [] (percpu_counter_hotcpu_callback+0x68/0x9c) from 
> [] (notifier_call_chain+0x44/0x84)
> [   57.182246] [] (notifier_call_chain+0x44/0x84) from [] 
> (__cpu_notify+0x28/0x44)
> [   57.182255] [] (__cpu_notify+0x28/0x44) from [] 
> (cpu_notify_nofail+0x8/0x14)
> [   57.182276] [] (cpu_notify_nofail+0x8/0x14) from [] 
> (_cpu_down+0xf8/0x25c)
> [   57.182286] [] (_cpu_down+0xf8/0x25c) from [] 
> (cpu_down+0x24/0x40)
> [   57.182296] [] (cpu_down+0x24/0x40) from [] 
> (store_online+0x30/0x78)
> [   57.182317] [] (store_online+0x30/0x78) from [] 
> (dev_attr_store+0x18/0x24)
> [   57.182332] [] (dev_attr_store+0x18/0x24) from [] 
> (sysfs_write_file+0x168/0x198)
> [   57.182354] [] (sysfs_write_file+0x168/0x198) from [] 
> (vfs_write+0x9c/0x140)
> [   57.182364] [] (vfs_write+0x9c/0x140) from [] 
> (sys_write+0x3c/0x70)
> [   57.182374] [] (sys_write+0x3c/0x70) from [] 
> (ret_fast_syscall+0x0/0x30)
> [   57.404633] [] (update_process_times+0x38/0x64) from 
> [] (tick_sched_timer+0x44/0x74)
> [   57.418340] [] (tick_sched_timer+0x44/0x74) from [] 
> (__run_hrtimer.isra.15+0x58/0x114)
> [   57.432362] [] (__run_hrtimer.isra.15+0x58/0x114) from 
> [] (hrtimer_interrupt+0x100/0x290)
> [   57.446620] [] (hrtimer_interrupt+0x100/0x290) from [] 
> (twd_handler+0x2c/0x40)
> [   57.459981] [] (twd_handler+0x2c/0x40) from [] 
> (handle_percpu_devid_irq+0x64/0x80)
> [   57.473749] [] (handle_percpu_devid_irq+0x64/0x80) from 
> [] (generic_handle_irq+0x20/0x30)
> [   57.488197] [] (generic_handle_irq+0x20/0x30) from [] 
> (handle_IRQ+0x38/0x94)
> [   57.501559] [] (handle_IRQ+0x38/0x94) from [] 
> (gic_handle_irq+0x28/0x5c)
> [   57.514610] [] (gic_handle_irq+0x28/0x5c) from [] 
> (__irq_svc+0x40/0x70)
> [   57.527606] Exception stack(0xed57be58 to 0xed57bea0)
> [   57.537292] be40:   
> c06e5c50 2113
> [   57.550216] be60:  55ec55ec   0002 c06ea074 
> c06daf08 c06e5c50
> [   57.563134] be80:  00015ef8  ed57bea0 c04d4660 c04dae04 
> 4113 
> [   57.576119] [] (__irq_svc+0x40/0x70) from [] 
> (_raw_spin_unlock_irqrestore+0x28/0x50)
> [   57.590515] [] (_raw_spin_unlock_irqrestore+0x28/0x50) from 
> [] (percpu_counter_hotcpu_callback+0x68/0x9c)
> [   57.606765] [] (percpu_counter_hotcpu_callback+0x68/0x9c) from 
> [] (notifier_call_chain+0x44/0x84)
> [   57.622320] [] (notifier_call_chain+0x44/0x84) from [] 
> (__cpu_notify+0x28/0x44)
> [   57.636338] [] (__cpu_notify+0x28/0x44) from [] 
> (cpu_notify_nofail+0x8/0x14)
> [   57.650161] [] (cpu_notify_nofail+0x8/0x14) from [] 
> (_cpu_down+0xf8/0x25c)
> [   57.663859] [] (_cpu_down+0xf8/0x25c) from [] 
> (cpu_down+0x24/0x40)
> [   57.676850] [] (cpu_down+0x24/0x40) from [] 
> (store_online+0x30/0x78)
> [   57.690010] [] (store_online+0x30/0x78) from [] 
> (dev_attr_store+0x18/0x24)
> [   57.703767] [] (dev_attr_store+0x18/0x24) from [] 
> (sysfs_write_file+0x168/0x198)
> [   57.717948] [] (sysfs_write_file+0x168/0x198) from [] 
> (vfs_write+0x9c/0x140)
> [   57.731866] [] (vfs_write+0x9c/0x140) from [] 
> (sys_write+0x3c/0x70)
> [   57.744841] [] (sys_write+0x3c/0x70) from [] 
> (ret_fast_syscall+0x0/0x30)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at

Re: [PATCH] IRQ CORE: irq_work_queue function return value not used.

2013-02-01 Thread Frederic Weisbecker

2013/2/2 anish kumar :
> On Sat, 2013-01-26 at 17:24 +0100, Frederic Weisbecker wrote:
>> 2012/11/3 anish kumar :
>> > From: anish kumar 
>> >
>> > As no one is using the return value of irq_work_queue function
>> > it is better to just make it void.
>> >
>> > Acked-by: Steven Rostedt 
>> > Signed-off-by: anish kumar 
>> > ---
>> >  kernel/irq_work.c |5 ++---
>> >  1 files changed, 2 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/kernel/irq_work.c b/kernel/irq_work.c
>> > index 1588e3b..4829a31 100644
>> > --- a/kernel/irq_work.c
>> > +++ b/kernel/irq_work.c
>> > @@ -79,17 +79,16 @@ static void __irq_work_queue(struct irq_work *work)
>> >   *
>> >   * Can be re-enqueued while the callback is still in progress.
>> >   */
>> > -bool irq_work_queue(struct irq_work *work)
>> > +void irq_work_queue(struct irq_work *work)
>>
>> Please also update the headers in include/linux/irq_work.h accordingly.
> I have sent the patch again(some time back).Is it picked up?
> http://www.gossamer-threads.com/lists/linux/kernel/1667796

Yep, I'm applying it and if it passes basic tests I'll relay it to Ingo.

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/

linux-next: build warnings after merge of the l2-mtd tree

Hi Artem,

After merging the l2-mtd tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:

In file included from drivers/mtd/chips/cfi_cmdset_0002.c:36:0:
include/linux/of_platform.h:107:13: warning: 'struct of_device_id' declared 
inside parameter list [enabled by default]
include/linux/of_platform.h:107:13: warning: its scope is only this definition 
or declaration, which is probably not what you want [enabled by default]
include/linux/of_platform.h:107:13: warning: 'struct device_node' declared 
inside parameter list [enabled by default]
drivers/mtd/chips/cfi_cmdset_0002.c: In function 'cfi_cmdset_0002':
drivers/mtd/chips/cfi_cmdset_0002.c:504:22: warning: unused variable 'np' 
[-Wunused-variable]
drivers/mtd/chips/cfi_cmdset_0002.c: At top level:
drivers/mtd/chips/cfi_cmdset_0002.c:2279:12: warning: 'cfi_ppb_lock' defined 
but not used [-Wunused-function]
drivers/mtd/chips/cfi_cmdset_0002.c:2285:12: warning: 'cfi_ppb_unlock' defined 
but not used [-Wunused-function]
drivers/mtd/chips/cfi_cmdset_0002.c:2382:12: warning: 'cfi_ppb_is_locked' 
defined but not used [-Wunused-function]

Introduced by commit c3a02f171365 ("mtd: cfi_cmdset_0002: Support
Persistent Protection Bits (PPB) locking").
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp4t_J_4Vcm_.pgp
Description: PGP signature

Re: [PATCH] fs:ext4:hash.c: reduce one "if" comparison

2013-02-01 Thread Theodore Ts'o

On Sat, Dec 01, 2012 at 11:33:41PM +, Cong Ding wrote:
> it is unnecessary to check i<4 after the loop. just do it before the break.
> 
> Signed-off-by: Cong Ding 

Thanks, applied.

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] cpufreq: Do not track governor name for scaling drivers with internal governors.

On Sat, Feb 2, 2013 at 12:15 AM,   wrote:
> From: Dirk Brandewie 
>
> Scaling drivers that implement internal governors do not have governor
> structures assocaited with them.  Only track the name of the governor
> associated with the CPU if the driver does not implement
> cpufreq_driver.setpolicy()
>
> Signed-off-by: Dirk Brandewie 

Is this rebased on latest stuff? i.e. rafael/bleeding_edge ?

--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] cpufreq: Only query drivers that implement cpufreq_driver.target()

On Sat, Feb 2, 2013 at 12:15 AM,   wrote:
> From: Dirk Brandewie 
>
> Scaling drivers that implement cpufreq_driver.setpolicy() have
> internal governors and may/will change the current operating frequency
> very frequently this will cause cpufreq_out_of_sync() to be called
> every time. Only call cpufreq_driver.get() for drivers that implement
> cpufreq_driver.target()
>
> Signed-off-by: Dirk Brandewie 
> ---
>  drivers/cpufreq/cpufreq.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 1c037f0..493cd50 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1794,7 +1794,7 @@ int cpufreq_update_policy(unsigned int cpu)
>
> /* BIOS might change freq behind our back
>   -> ask driver for current freq and notify governors about a change 
> */
> -   if (cpufreq_driver->get) {
> +   if (cpufreq_driver->get && cpufreq_driver->target) {

This would mean policy->cur has a garbage value. I don't really know
how would other routine behave on this. Would it make sense to make
policy->cur zero atleast?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the net-next tree with the net tree

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/vmxnet3/vmxnet3_drv.c between commit 6cdd20c380eb ("vmxnet3:
set carrier state properly on probe") from the net tree and commit
204a6e659439 ("vmxnet3: use netdev_ printk wrappers") from the net-next
tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/net/vmxnet3/vmxnet3_drv.c
index 12c6440,b1c90f8..000
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@@ -152,9 -148,10 +148,9 @@@ vmxnet3_check_link(struct vmxnet3_adapt
  
adapter->link_speed = ret >> 16;
if (ret & 1) { /* Link is up. */
-   printk(KERN_INFO "%s: NIC Link is Up %d Mbps\n",
-  adapter->netdev->name, adapter->link_speed);
+   netdev_info(adapter->netdev, "NIC Link is Up %d Mbps\n",
+   adapter->link_speed);
 -  if (!netif_carrier_ok(adapter->netdev))
 -  netif_carrier_on(adapter->netdev);
 +  netif_carrier_on(adapter->netdev);
  
if (affectTxQueue) {
for (i = 0; i < adapter->num_tx_queues; i++)
@@@ -162,9 -159,9 +158,8 @@@
 adapter);
}
} else {
-   printk(KERN_INFO "%s: NIC Link is Down\n",
-  adapter->netdev->name);
+   netdev_info(adapter->netdev, "NIC Link is Down\n");
 -  if (netif_carrier_ok(adapter->netdev))
 -  netif_carrier_off(adapter->netdev);
 +  netif_carrier_off(adapter->netdev);
  
if (affectTxQueue) {
for (i = 0; i < adapter->num_tx_queues; i++)


pgp_qNat49OxM.pgp
Description: PGP signature

linux-next: manual merge of the net-next tree with the net tree

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/ipv6/route.c between commit bd30e947207e ("ipv6: do not create
neighbor entries for local delivery") from the net tree and commit
c440f1609b65 ("ipv6: Do not depend on rt->n in ip6_pol_route()") from the
net-next tree.

I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc net/ipv6/route.c
index 363d8b7,f3328bc..000
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@@ -928,7 -884,7 +884,7 @@@ restart
dst_hold(>dst);
read_unlock_bh(>tb6_lock);
  
-   if (!rt->n && !(rt->rt6i_flags & (RTF_NONEXTHOP | RTF_LOCAL)))
 -  if (!(rt->rt6i_flags & (RTF_NONEXTHOP | RTF_GATEWAY)))
++  if (!(rt->rt6i_flags & (RTF_NONEXTHOP | RTF_LOCAL | RTF_GATEWAY)))
nrt = rt6_alloc_cow(rt, >daddr, >saddr);
else if (!(rt->dst.flags & DST_HOST))
nrt = rt6_alloc_clone(rt, >daddr);


pgpnMEgTx34RT.pgp
Description: PGP signature

Re: [PATCH] [Watchdog][Trivial] Added comments to explain watchdog_disabled variable

2013-02-01 Thread anish kumar

On Fri, 2013-02-01 at 09:59 -0500, Don Zickus wrote:
> On Fri, Feb 01, 2013 at 07:19:07PM +0530, anish kumar wrote:
> > From: anish kumar 
> > 
> > This watchdog_disabled flag is bit of cryptic.Howerver it's usefullnes is 
> > multifold.
> > Uses are:
> > 1. Check if smpboot_register_percpu_thread function passed.
> > 2. Makes sure that user enables and disables the watchdog in sequence
> >i.e. enable watchdog->disable watchdog->enable watchdog
> >Unlike enable watchdog->enable watchdog which is wrong.
> > 
> > Signed-off-by: anish kumar 
> > ---
> >  kernel/watchdog.c |5 +
> >  1 files changed, 5 insertions(+), 0 deletions(-)
> > 
> > diff --git a/kernel/watchdog.c b/kernel/watchdog.c
> > index 6ef638b..dfd843a 100644
> > --- a/kernel/watchdog.c
> > +++ b/kernel/watchdog.c
> > @@ -519,6 +519,11 @@ int proc_dowatchdog(struct ctl_table *table, int write,
> > return ret;
> >  
> > set_sample_period();
> > +   /*
> > +* We shouldn't enable watchdog threads if it is not
>   ^^^
> the 'not' is not needed I believe.  Other than that, if it helps
> to understand the code better.  I am fine with it.
> 
> Acked-by: Don Zickus 
Should I wait for some more acked-by's?
> 
> > +* disabled.This is done by watchdog_disabled
> > +* variable check in watchdog_*_all_cpus function.
> > +*/
> > if (watchdog_enabled && watchdog_thresh)
> > watchdog_enable_all_cpus();
> > else
> > -- 
> > 1.7.1
> > 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] IRQ CORE: irq_work_queue function return value not used.

2013-02-01 Thread anish kumar

On Sat, 2013-01-26 at 17:24 +0100, Frederic Weisbecker wrote:
> 2012/11/3 anish kumar :
> > From: anish kumar 
> >
> > As no one is using the return value of irq_work_queue function
> > it is better to just make it void.
> >
> > Acked-by: Steven Rostedt 
> > Signed-off-by: anish kumar 
> > ---
> >  kernel/irq_work.c |5 ++---
> >  1 files changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/kernel/irq_work.c b/kernel/irq_work.c
> > index 1588e3b..4829a31 100644
> > --- a/kernel/irq_work.c
> > +++ b/kernel/irq_work.c
> > @@ -79,17 +79,16 @@ static void __irq_work_queue(struct irq_work *work)
> >   *
> >   * Can be re-enqueued while the callback is still in progress.
> >   */
> > -bool irq_work_queue(struct irq_work *work)
> > +void irq_work_queue(struct irq_work *work)
> 
> Please also update the headers in include/linux/irq_work.h accordingly.
I have sent the patch again(some time back).Is it picked up?
http://www.gossamer-threads.com/lists/linux/kernel/1667796
> 
> Thanks.
> 
> >  {
> > if (!irq_work_claim(work)) {
> > /*
> >  * Already enqueued, can't do!
> >  */
> > -   return false;
> > +   return;
> > }
> >
> > __irq_work_queue(work);
> > -   return true;
> >  }
> >  EXPORT_SYMBOL_GPL(irq_work_queue);
> >
> > --
> > 1.7.1
> >


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/6] cpufreq: Retrieve current frequency from scaling drivers with internal governors

On Sat, Feb 2, 2013 at 12:19 AM,   wrote:
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c

> @@ -1219,6 +1219,9 @@ unsigned int cpufreq_quick_get(unsigned int cpu)
> struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
> unsigned int ret_freq = 0;
>
> +   if (cpufreq_driver && cpufreq_driver->setpolicy && 
> cpufreq_driver->get)
> +   return cpufreq_driver->get(cpu);

You are required to do cpufreq_cpu_put() in this case too... Better do
cpufreq_cpu_get() after your check.

> +
> if (policy) {
> ret_freq = policy->cur;
> cpufreq_cpu_put(policy);
> --
> 1.7.7.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe cpufreq" 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: [RFC] [DONOTAPPLY] [PATCH] enhanceio: STEC EnhanceIO SSD caching software for Linux kernel

2013-02-01 Thread Amit Kale

End user documentation is on our github. I think it should go with the user 
level utilities, rather than the kernel driver.
-Amit

> -Original Message-
> From: Kent Overstreet [mailto:koverstr...@google.com]
> Sent: Friday, February 01, 2013 5:25 PM
> To: Michel Lespinasse
> Cc: Darrick J. Wong; Amit Kale; linux-bcache; device-mapper
> development; Kent Overstreet; Mike Snitzer; LKML; Jason Warr;
> thorn...@redhat.com
> Subject: Re: [RFC] [DONOTAPPLY] [PATCH] enhanceio: STEC EnhanceIO SSD
> caching software for Linux kernel
> 
> Also, where's the end user documentation?
> 
> On Fri, Feb 1, 2013 at 5:23 PM, Kent Overstreet
>  wrote:
> > On Fri, Feb 1, 2013 at 4:57 PM, Michel Lespinasse 
> wrote:
> >> On Fri, Feb 1, 2013 at 4:44 PM, Darrick J. Wong
>  wrote:
> >>> This is a patch to migrate STEC's enhanceio driver out of their
> >>> github repository and into the staging tree.  From their README:
> >>>
> >>> "EnhanceIO driver is based on EnhanceIO SSD caching software
> product
> >>> developed by STEC Inc. EnhanceIO was derived from Facebook's open
> >>> source Flashcache project. EnhanceIO uses SSDs as cache devices for
> >>> traditional rotating hard disk drives (referred to as source
> volumes throughout this document).
> >>> EnhanceIO can work with any block device, be it an entire physical
> >>> disk, an individual disk partition,  a RAIDed DAS device, a SAN
> >>> volume, a device mapper volume or a software RAID (md) device."
> >>
> >> What's your take on the benefits of this vs bcache ?
> >
> > I've been trying to review it it for cache coherency and consistency
> > wrt. power failures, but the complete lack of high level
> documentation
> > is making that difficult.
> >
> > I saw some benchmarks the other day where on writes EIO was faster
> > than the raw device, which was... suspicious.

PROPRIETARY-CONFIDENTIAL INFORMATION INCLUDED



This electronic transmission, and any documents attached hereto, may contain 
confidential, proprietary and/or legally privileged information. The 
information is intended only for use by the recipient named above. If you 
received this electronic message in error, please notify the sender and delete 
the electronic message. Any disclosure, copying, distribution, or use of the 
contents of information received in error is strictly prohibited, and violators 
will be pursued legally.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] acpiphp: create companion ACPI devices before creating PCI devices

2013-02-01 Thread Yijing Wang

On 2013/2/2 7:06, Bjorn Helgaas wrote:
> On Wed, Jan 30, 2013 at 9:10 AM, Jiang Liu  wrote:
>> From: Jiang Liu 
>>
>> With commit 4f535093cf8f6da8c "PCI: Put pci_dev in device tree as
>> early as possible", companion ACPI devices should be created before
>> creating correspoding PCI devices, otherwise it will break the ACPI
>> PCI binding logic.
>>
>> Signed-off-by: Jiang Liu 
>> ---
>> Hi Bjorn,
>> This patch set applies to your pci/yinghai-root-bus branch.
>> There are still other potential bugs in the acpiphp driver under
>> investigation. So I will send out these two first to catch up with
>> the 3.9 merging window.
>> Thanks!
>> Gerry
> 
> I assume this fixes some sort of user-visible issue with acpiphp.
> What failure does the user see?

Hi Bjorn,
   Before applied this patch, after hot remove and hot add pci device by 
acpiphp,
we can find firmware_node under the pci device was missed.

Detailed info as bellow:
linux-ha2:/sys/bus/pci/slots # ls /sys/bus/pci/devices/\:05\:00.0/ -al
total 0
drwxr-xr-x 3 root root 0 Jan 31 10:19 .
drwxr-xr-x 9 root root 0 Jan 31 10:19 ..
-r--r--r-- 1 root root 65536 Jan 31 10:31 boot_vga
-rw-r--r-- 1 root root 65536 Jan 31 10:31 broken_parity_status
-r--r--r-- 1 root root 65536 Jan 31 10:19 class
-rw-r--r-- 1 root root  4096 Jan 31 10:31 config
-r--r--r-- 1 root root 65536 Jan 31 10:31 consistent_dma_mask_bits
-rw-r--r-- 1 root root 65536 Jan 31 10:31 d3cold_allowed
-r--r--r-- 1 root root 65536 Jan 31 10:19 device
-r--r--r-- 1 root root 65536 Jan 31 10:31 dma_mask_bits
-rw--- 1 root root 65536 Jan 31 10:31 enable
lrwxrwxrwx 1 root root 0 Jan 31 10:31 firmware_node -> 
../../../LNXSYSTM:00/device:00/ACPI0004:00/PNP0A08:00/device:07/device:08
-r--r--r-- 1 root root 65536 Jan 31 10:19 irq
-r--r--r-- 1 root root 65536 Jan 31 10:31 local_cpulist
-r--r--r-- 1 root root 65536 Jan 31 10:20 local_cpus
-r--r--r-- 1 root root 65536 Jan 31 10:31 modalias
-rw-r--r-- 1 root root 65536 Jan 31 10:31 msi_bus
-r--r--r-- 1 root root 65536 Jan 31 10:31 numa_node
drwxr-xr-x 2 root root 0 Jan 31 10:31 power
--w--w 1 root root 65536 Jan 31 10:31 remove
--w--w 1 root root 65536 Jan 31 10:31 rescan
-r--r--r-- 1 root root 65536 Jan 31 10:19 resource
-rw--- 1 root root  16777216 Jan 31 10:31 resource0
-rw--- 1 root root 268435456 Jan 31 10:31 resource1
-rw--- 1 root root 268435456 Jan 31 10:31 resource1_wc
-rw--- 1 root root  33554432 Jan 31 10:31 resource3
-rw--- 1 root root  33554432 Jan 31 10:31 resource3_wc
-rw--- 1 root root   128 Jan 31 10:31 resource5
-rw--- 1 root root524288 Jan 31 10:31 rom
lrwxrwxrwx 1 root root 0 Jan 31 10:19 subsystem -> ../../../../bus/pci
-r--r--r-- 1 root root 65536 Jan 31 10:19 subsystem_device
-r--r--r-- 1 root root 65536 Jan 31 10:19 subsystem_vendor
-rw-r--r-- 1 root root 65536 Jan 31 10:19 uevent
-r--r--r-- 1 root root 65536 Jan 31 10:19 vendor
linux-ha2:/sys/bus/pci/slots # cd 0
linux-ha2:/sys/bus/pci/slots/0 # cat address
:05:00
linux-ha2:/sys/bus/pci/slots/0 # cat power
1
linux-ha2:/sys/bus/pci/slots/0 # echo 0 > power
linux-ha2:/sys/bus/pci/slots/0 # echo 1 > power
linux-ha2:/sys/bus/pci/slots/0 # ls /sys/bus/pci/devices/\:05\:00.0/ -al
total 0
drwxr-xr-x 3 root root 0 Jan 31 10:31 .
drwxr-xr-x 9 root root 0 Jan 31 10:19 ..
-r--r--r-- 1 root root 65536 Jan 31 10:31 boot_vga
-rw-r--r-- 1 root root 65536 Jan 31 10:31 broken_parity_status
-r--r--r-- 1 root root 65536 Jan 31 10:31 class
-rw-r--r-- 1 root root  4096 Jan 31 10:31 config
-r--r--r-- 1 root root 65536 Jan 31 10:31 consistent_dma_mask_bits
-rw-r--r-- 1 root root 65536 Jan 31 10:31 d3cold_allowed
-r--r--r-- 1 root root 65536 Jan 31 10:31 device
-r--r--r-- 1 root root 65536 Jan 31 10:31 dma_mask_bits
-rw--- 1 root root 65536 Jan 31 10:31 enable
-r--r--r-- 1 root root 65536 Jan 31 10:31 irq
-r--r--r-- 1 root root 65536 Jan 31 10:31 local_cpulist
-r--r--r-- 1 root root 65536 Jan 31 10:31 local_cpus
-r--r--r-- 1 root root 65536 Jan 31 10:31 modalias
-rw-r--r-- 1 root root 65536 Jan 31 10:31 msi_bus
-r--r--r-- 1 root root 65536 Jan 31 10:31 numa_node
drwxr-xr-x 2 root root 0 Jan 31 10:31 power
--w--w 1 root root 65536 Jan 31 10:31 remove
--w--w 1 root root 65536 Jan 31 10:31 rescan
-r--r--r-- 1 root root 65536 Jan 31 10:31 resource
-rw--- 1 root root  16777216 Jan 31 10:31 resource0
-rw--- 1 root root 268435456 Jan 31 10:31 resource1
-rw--- 1 root root 268435456 Jan 31 10:31 resource1_wc
-rw--- 1 root root  33554432 Jan 31 10:31 resource3
-rw--- 1 root root  33554432 Jan 31 10:31 resource3_wc
-rw--- 1 root root   128 Jan 31 10:31 resource5
-rw--- 1 root root524288 Jan 31 10:31 rom
lrwxrwxrwx 1 root root 0 Jan 31 10:31 subsystem ->

Re: [PATCH 1/4] intel_idle: stop using driver_data for static flags

2013-02-01 Thread Len Brown


>> intel_idle already uses a driver-specific flag:
>>
>> #define CPUIDLE_FLAG_TLB_FLUSHED0x1
>>
>> This patch just uses 4 more bits along with that one.
> 
> Ok. In this case it would make sense to move this flag out of the
> generic core code to the intel_idle.c file ?

This flag is already local to intel_idle.c.
If another architecture finds it useful,
then yes, it would make sense to move it to the shared header.

> and move the [dec/en]coding
> macro flags_2_MWAIT_EAX and MWAIT_EAX_2_flags (with a more appropriate
> name for a generic code) to the cpuidle.h file ?

I think that a driver's private flag definitions
should remain local to the driver.  It makes no sense
to pollute the name space of other drivers for stuff
that doesn't mean anything to them.  MWAIT is pretty
specific to x86 -- and re-naming it to something 'generic'
isn't going to make the code easier to read.

thanks,
Len Brown, Intel Open Source Technology Center


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common


Hello.

On 02-02-2013 4:44, Russell King - ARM Linux wrote:


On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:

good point, do you wanna send some patches ?



 I have already sent them countless times and even stuck CPPI 4.1 support 
(in
arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the
patch. :-(



sticking into arch/arm/common/ wasn't a nice move. But then again, so
wasn't asking for the patch to be removed :-s



Err, patches don't get removed, they get moved to 'discarded'.



Any chance to bring it back to life? :-)
Although... drivers/usb/musb/cppi41.c would need to be somewhat
reworked for at least AM35x and I don't have time. But that may change,
of course.



Right, I've just looked back at the various meeting minutes from December
2010 when the CPPI stuff was discussed.  Yes, I archive these things and
all email discussions for referencing in cases like this.


   Thanks.


Unfortunately, they do not contain any useful information other than the
topic having been brought up.  At that point, the CPPI stuff was in
mach-davinci, and I had suggested moving it into drivers/dma.


   I don't remember that, probably was out of the loop again.


The result of that was to say that it doesn't fit the DMA engine APIs.


   I remember this as a discussion happening post me sending the patch to the 
patch system and it being discarded...



So someone came up with the idea of putting it in arch/arm/common - which


   Probably was me. There was also idea of putting it into drivers/usb/musb/ 
-- which TI indeed followed in its Arago prject. I firmly denied that suggestion.



I frankly ignored by email (how long have we been saying "no drivers in
arch/arm" ?)


   But there *are* drivers there! And look at edma.c which is about to be 
moved there... Anyway, I haven't seen such warnings, probably was too late in 
the game.



Now, it would've been discussed in that meeting, but unfortunately no
record exists of that.  What does follow that meeting is a discussion
trail.  From what I can see there, but it looks to me like the decision
was taken to move it to the DMA engine API, and work on sorting out MUSB
was going to commence.



The last email in that says "I'll get to that soon"... and that is also
the final email I have on this topic.  I guess if nothing has happened...
Shrug, that's someone elses problem.


   Well, as usual... :-(


Anyway, the answer for putting it in arch/arm/common hasn't changed,
and really, where we are now, post Linus having a moan about the size
of arch/arm, that answer is even more concrete in the negative.  It's
54K of code which should not be under arch/arm at all.



Anyway, if you need to look at the patch, it's 6305/1.  Typing into the
summary search box 'cppi' found it in one go.


   Thanks, I remember this variant was under arch/arm/common/.
   Now however, I see what happened to that variant in somewhat different 
light. Looks like it was entirely your decision to discard the patch, without 
TI's request...


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: build failure after merge of the nfsd tree

Hi,

After merging the nfsd tree, today's linux-next build (x86_64
allmodconfig) failed like this:

fs/nfs/dns_resolve.c: In function 'nfs_dns_resolver_cache_init':
fs/nfs/dns_resolve.c:375:4: error: 'struct cache_detail' has no member named 
'cache_upcall'
fs/nfs/dns_resolve.c:375:35: warning: left-hand operand of comma expression has 
no effect [-Wunused-value]
fs/nfs/dns_resolve.c:375:35: warning: value computed is not used 
[-Wunused-value]
fs/nfs/dns_resolve.c:375:35: warning: value computed is not used 
[-Wunused-value]
fs/nfs/dns_resolve.c:375:35: warning: value computed is not used 
[-Wunused-value]
fs/nfs/dns_resolve.c:375:35: warning: value computed is not used 
[-Wunused-value]
fs/nfs/dns_resolve.c:375:35: warning: value computed is not used 
[-Wunused-value]
fs/nfs/dns_resolve.c:375:35: warning: value computed is not used 
[-Wunused-value]

Caused by commit aab982cb5dfb ("SUNRPC: remove cache_detail->cache_upcall
callback").  Also, why don't those statements end in semicolons?

I have used the nsfd tree from next-20130128 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpyhH42jfvim.pgp
Description: PGP signature

[PATCH 1/5] perf, x86: Add PEBSv2 record support

From: Andi Kleen 

Add support for the v2 PEBS format. It has a superset of the v1 PEBS
fields, but has a longer record so we need to adjust the code paths.

The main advantage is the new "EventingRip" support which directly
gives the instruction, not off-by-one instruction. So with precise == 2
we use that directly and don't try to use LBRs and walking basic blocks.
This lowers the overhead significantly.

Some other features are added in later patches.

Reviewed-by: Stephane Eranian 
Signed-off-by: Andi Kleen 
---
 arch/x86/kernel/cpu/perf_event.c  |2 +-
 arch/x86/kernel/cpu/perf_event_intel_ds.c |  101 ++---
 2 files changed, 79 insertions(+), 24 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 6774c17..c95290a 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -397,7 +397,7 @@ int x86_pmu_hw_config(struct perf_event *event)
 * check that PEBS LBR correction does not conflict with
 * whatever the user is asking with attr->branch_sample_type
 */
-   if (event->attr.precise_ip > 1) {
+   if (event->attr.precise_ip > 1 && x86_pmu.intel_cap.pebs_format 
< 2) {
u64 *br_type = >attr.branch_sample_type;
 
if (has_branch_stack(event)) {
diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c 
b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index 826054a..9d0dae0 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -41,6 +41,12 @@ struct pebs_record_nhm {
u64 status, dla, dse, lat;
 };
 
+struct pebs_record_v2 {
+   struct pebs_record_nhm nhm;
+   u64 eventingrip;
+   u64 tsx_tuning;
+};
+
 void init_debug_store_on_cpu(int cpu)
 {
struct debug_store *ds = per_cpu(cpu_hw_events, cpu).ds;
@@ -559,8 +565,7 @@ static void __intel_pmu_pebs_event(struct perf_event *event,
 {
/*
 * We cast to pebs_record_core since that is a subset of
-* both formats and we don't use the other fields in this
-* routine.
+* both formats.
 */
struct cpu_hw_events *cpuc = &__get_cpu_var(cpu_hw_events);
struct pebs_record_core *pebs = __pebs;
@@ -588,7 +593,10 @@ static void __intel_pmu_pebs_event(struct perf_event 
*event,
regs.bp = pebs->bp;
regs.sp = pebs->sp;
 
-   if (event->attr.precise_ip > 1 && intel_pmu_pebs_fixup_ip())
+   if (event->attr.precise_ip > 1 && x86_pmu.intel_cap.pebs_format >= 2) {
+   regs.ip = ((struct pebs_record_v2 *)pebs)->eventingrip;
+   regs.flags |= PERF_EFLAGS_EXACT;
+   } else if (event->attr.precise_ip > 1 && intel_pmu_pebs_fixup_ip())
regs.flags |= PERF_EFLAGS_EXACT;
else
regs.flags &= ~PERF_EFLAGS_EXACT;
@@ -641,35 +649,21 @@ static void intel_pmu_drain_pebs_core(struct pt_regs 
*iregs)
__intel_pmu_pebs_event(event, iregs, at);
 }
 
-static void intel_pmu_drain_pebs_nhm(struct pt_regs *iregs)
+static void intel_pmu_drain_pebs_common(struct pt_regs *iregs, void *at,
+   void *top)
 {
struct cpu_hw_events *cpuc = &__get_cpu_var(cpu_hw_events);
struct debug_store *ds = cpuc->ds;
-   struct pebs_record_nhm *at, *top;
struct perf_event *event = NULL;
u64 status = 0;
-   int bit, n;
-
-   if (!x86_pmu.pebs_active)
-   return;
-
-   at  = (struct pebs_record_nhm *)(unsigned long)ds->pebs_buffer_base;
-   top = (struct pebs_record_nhm *)(unsigned long)ds->pebs_index;
+   int bit;
 
ds->pebs_index = ds->pebs_buffer_base;
 
-   n = top - at;
-   if (n <= 0)
-   return;
+   for ( ; at < top; at += x86_pmu.pebs_record_size) {
+   struct pebs_record_nhm *p = at;
 
-   /*
-* Should not happen, we program the threshold at 1 and do not
-* set a reset value.
-*/
-   WARN_ONCE(n > x86_pmu.max_pebs_events, "Unexpected number of pebs 
records %d\n", n);
-
-   for ( ; at < top; at++) {
-   for_each_set_bit(bit, (unsigned long *)>status, 
x86_pmu.max_pebs_events) {
+   for_each_set_bit(bit, (unsigned long *)>status, 
x86_pmu.max_pebs_events) {
event = cpuc->events[bit];
if (!test_bit(bit, cpuc->active_mask))
continue;
@@ -692,6 +686,61 @@ static void intel_pmu_drain_pebs_nhm(struct pt_regs *iregs)
}
 }
 
+static void intel_pmu_drain_pebs_nhm(struct pt_regs *iregs)
+{
+   struct cpu_hw_events *cpuc = &__get_cpu_var(cpu_hw_events);
+   struct debug_store *ds = cpuc->ds;
+   struct pebs_record_nhm *at, *top;
+   int n;
+
+   if (!x86_pmu.pebs_active)
+   return;
+
+   at  = (struct pebs_record_nhm *)(unsigned

[PATCH 4/5] perf, x86: Support full width counting

From: Andi Kleen 

Recent Intel CPUs have a new alternative MSR range for perfctrs that allows
writing the full counter width. Enable this range if the hardware reports it
using a new capability bit. This lowers overhead of perf stat slightly because
it has to do less interrupts to accumulate the counter value. On Haswell it
also avoids some problems with TSX aborting when the end of the counter
range is reached.

Signed-off-by: Andi Kleen 
---
 arch/x86/include/uapi/asm/msr-index.h  |3 +++
 arch/x86/kernel/cpu/perf_event.h   |1 +
 arch/x86/kernel/cpu/perf_event_intel.c |6 ++
 3 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/uapi/asm/msr-index.h 
b/arch/x86/include/uapi/asm/msr-index.h
index 433a59f..af41a77 100644
--- a/arch/x86/include/uapi/asm/msr-index.h
+++ b/arch/x86/include/uapi/asm/msr-index.h
@@ -163,6 +163,9 @@
 #define MSR_KNC_EVNTSEL0   0x0028
 #define MSR_KNC_EVNTSEL1   0x0029
 
+/* Alternative perfctr range with full access. */
+#define MSR_IA32_PMC0  0x04c1
+
 /* AMD64 MSRs. Not complete. See the architecture manual for a more
complete list. */
 
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index 1567b0d..ce2a863 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -278,6 +278,7 @@ union perf_capabilities {
u64 pebs_arch_reg:1;
u64 pebs_format:4;
u64 smm_freeze:1;
+   u64 fw_write:1;
};
u64 capabilities;
 };
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c 
b/arch/x86/kernel/cpu/perf_event_intel.c
index aa48048..d96010a 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -2228,5 +2228,11 @@ __init int intel_pmu_init(void)
}
}
 
+   /* Support full width counters using alternative MSR range */
+   if (x86_pmu.intel_cap.fw_write) {
+   x86_pmu.max_period = x86_pmu.cntval_mask;
+   x86_pmu.perfctr = MSR_IA32_PMC0;
+   }
+
return 0;
 }
-- 
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/5] perf, x86: Basic Haswell PEBS support v4

From: Andi Kleen 

Add basic PEBS support for Haswell.
The constraints are similar to SandyBridge with a few new events.

v2: Readd missing pebs_aliases
v3: Readd missing hunk. Fix some constraints.
v4: Fix typo in PEBS event table (Stephane Eranian)
Reviewed-by: Stephane Eranian 
Signed-off-by: Andi Kleen 
---
 arch/x86/kernel/cpu/perf_event.h  |2 ++
 arch/x86/kernel/cpu/perf_event_intel.c|6 --
 arch/x86/kernel/cpu/perf_event_intel_ds.c |   29 +
 3 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index 8941899..1567b0d 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -596,6 +596,8 @@ extern struct event_constraint 
intel_snb_pebs_event_constraints[];
 
 extern struct event_constraint intel_ivb_pebs_event_constraints[];
 
+extern struct event_constraint intel_hsw_pebs_event_constraints[];
+
 struct event_constraint *intel_pebs_constraints(struct perf_event *event);
 
 void intel_pmu_pebs_enable(struct perf_event *event);
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c 
b/arch/x86/kernel/cpu/perf_event_intel.c
index 58b737d..aa48048 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -827,7 +827,8 @@ static inline bool intel_pmu_needs_lbr_smpl(struct 
perf_event *event)
return true;
 
/* implicit branch sampling to correct PEBS skid */
-   if (x86_pmu.intel_cap.pebs_trap && event->attr.precise_ip > 1)
+   if (x86_pmu.intel_cap.pebs_trap && event->attr.precise_ip > 1 &&
+   x86_pmu.intel_cap.pebs_format < 2)
return true;
 
return false;
@@ -2167,8 +2168,9 @@ __init int intel_pmu_init(void)
intel_pmu_lbr_init_snb();
 
x86_pmu.event_constraints = intel_hsw_event_constraints;
-
+   x86_pmu.pebs_constraints = intel_hsw_pebs_event_constraints;
x86_pmu.extra_regs = intel_snb_extra_regs;
+   x86_pmu.pebs_aliases = intel_pebs_aliases_snb;
/* all extra regs are per-cpu when HT is on */
x86_pmu.er_flags |= ERF_HAS_RSP_1;
x86_pmu.er_flags |= ERF_NO_HT_SHARING;
diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c 
b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index 9d0dae0..0252930 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -427,6 +427,35 @@ struct event_constraint intel_ivb_pebs_event_constraints[] 
= {
 EVENT_CONSTRAINT_END
 };
 
+struct event_constraint intel_hsw_pebs_event_constraints[] = {
+   INTEL_UEVENT_CONSTRAINT(0x01c0, 0x2), /* INST_RETIRED.PRECDIST */
+   INTEL_UEVENT_CONSTRAINT(0x01c2, 0xf), /* UOPS_RETIRED.ALL */
+   INTEL_UEVENT_CONSTRAINT(0x02c2, 0xf), /* UOPS_RETIRED.RETIRE_SLOTS */
+   INTEL_EVENT_CONSTRAINT(0xc4, 0xf),/* BR_INST_RETIRED.* */
+   INTEL_UEVENT_CONSTRAINT(0x01c5, 0xf), /* BR_MISP_RETIRED.CONDITIONAL */
+   INTEL_UEVENT_CONSTRAINT(0x04c5, 0xf), /* BR_MISP_RETIRED.ALL_BRANCHES */
+   INTEL_UEVENT_CONSTRAINT(0x20c5, 0xf), /* BR_MISP_RETIRED.NEAR_TAKEN */
+   INTEL_EVENT_CONSTRAINT(0xcd, 0x8),/* MEM_TRANS_RETIRED.* */
+   INTEL_UEVENT_CONSTRAINT(0x11d0, 0xf), /* 
MEM_UOPS_RETIRED.STLB_MISS_LOADS */
+   INTEL_UEVENT_CONSTRAINT(0x12d0, 0xf), /* 
MEM_UOPS_RETIRED.STLB_MISS_STORES */
+   INTEL_UEVENT_CONSTRAINT(0x21d0, 0xf), /* MEM_UOPS_RETIRED.LOCK_LOADS */
+   INTEL_UEVENT_CONSTRAINT(0x41d0, 0xf), /* MEM_UOPS_RETIRED.SPLIT_LOADS */
+   INTEL_UEVENT_CONSTRAINT(0x42d0, 0xf), /* MEM_UOPS_RETIRED.SPLIT_STORES 
*/
+   INTEL_UEVENT_CONSTRAINT(0x81d0, 0xf), /* MEM_UOPS_RETIRED.ALL_LOADS */
+   INTEL_UEVENT_CONSTRAINT(0x82d0, 0xf), /* MEM_UOPS_RETIRED.ALL_STORES */
+   INTEL_UEVENT_CONSTRAINT(0x01d1, 0xf), /* MEM_LOAD_UOPS_RETIRED.L1_HIT */
+   INTEL_UEVENT_CONSTRAINT(0x02d1, 0xf), /* MEM_LOAD_UOPS_RETIRED.L2_HIT */
+   INTEL_UEVENT_CONSTRAINT(0x04d1, 0xf), /* MEM_LOAD_UOPS_RETIRED.L3_HIT */
+   INTEL_UEVENT_CONSTRAINT(0x40d1, 0xf), /* MEM_LOAD_UOPS_RETIRED.HIT_LFB 
*/
+   INTEL_UEVENT_CONSTRAINT(0x01d2, 0xf), /* 
MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_MISS */
+   INTEL_UEVENT_CONSTRAINT(0x02d2, 0xf), /* 
MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_HIT */
+   INTEL_UEVENT_CONSTRAINT(0x01d3, 0xf), /* 
MEM_LOAD_UOPS_LLC_MISS_RETIRED.LOCAL_DRAM */
+   INTEL_UEVENT_CONSTRAINT(0x04c8, 0xf), /* HLE_RETIRED.Abort */
+   INTEL_UEVENT_CONSTRAINT(0x04c9, 0xf), /* RTM_RETIRED.Abort */
+
+   EVENT_CONSTRAINT_END
+};
+
 struct event_constraint *intel_pebs_constraints(struct perf_event *event)
 {
struct event_constraint *c;
-- 
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read

[PATCH 2/5] perf, x86: Basic Haswell PMU support v4

From: Andi Kleen 

Add basic Haswell PMU support.

Similar to SandyBridge, but has a few new events and two
new counter bits.

There are some new counter flags that need to be prevented
from being set on fixed counters, and allowed to be set
for generic counters.

Also we add support for the counter 2 constraint to handle
all raw events.

Contains fixes from Stephane Eranian

v2: Folded TSX bits into standard FIXED_EVENT_CONSTRAINTS
v3: Use SNB LBR init code. Comment fix (Stephane Eranian)
v4: Add the counter2 constraints. Fix comment in the right place.
Reviewed-by: Stephane Eranian 
Signed-off-by: Andi Kleen 
---
 arch/x86/include/asm/perf_event.h  |3 +
 arch/x86/kernel/cpu/perf_event.h   |5 ++-
 arch/x86/kernel/cpu/perf_event_intel.c |   71 
 3 files changed, 78 insertions(+), 1 deletions(-)

diff --git a/arch/x86/include/asm/perf_event.h 
b/arch/x86/include/asm/perf_event.h
index 4fabcdf..4003bb6 100644
--- a/arch/x86/include/asm/perf_event.h
+++ b/arch/x86/include/asm/perf_event.h
@@ -29,6 +29,9 @@
 #define ARCH_PERFMON_EVENTSEL_INV  (1ULL << 23)
 #define ARCH_PERFMON_EVENTSEL_CMASK0xFF00ULL
 
+#define HSW_INTX   (1ULL << 32)
+#define HSW_INTX_CHECKPOINTED  (1ULL << 33)
+
 #define AMD_PERFMON_EVENTSEL_GUESTONLY (1ULL << 40)
 #define AMD_PERFMON_EVENTSEL_HOSTONLY  (1ULL << 41)
 
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index 115c1ea..8941899 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -219,11 +219,14 @@ struct cpu_hw_events {
  *  - inv
  *  - edge
  *  - cnt-mask
+ *  - intx
+ *  - intx_cp
  *  The other filters are supported by fixed counters.
  *  The any-thread option is supported starting with v3.
  */
+#define FIXED_EVENT_FLAGS (X86_RAW_EVENT_MASK|HSW_INTX|HSW_INTX_CHECKPOINTED)
 #define FIXED_EVENT_CONSTRAINT(c, n)   \
-   EVENT_CONSTRAINT(c, (1ULL << (32+n)), X86_RAW_EVENT_MASK)
+   EVENT_CONSTRAINT(c, (1ULL << (32+n)), FIXED_EVENT_FLAGS)
 
 /*
  * Constraint on the Event code + UMask
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c 
b/arch/x86/kernel/cpu/perf_event_intel.c
index 93b9e11..58b737d 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -133,6 +134,17 @@ static struct extra_reg intel_snb_extra_regs[] 
__read_mostly = {
EVENT_EXTRA_END
 };
 
+static struct event_constraint intel_hsw_event_constraints[] =
+{
+   FIXED_EVENT_CONSTRAINT(0x00c0, 0), /* INST_RETIRED.ANY */
+   FIXED_EVENT_CONSTRAINT(0x003c, 1), /* CPU_CLK_UNHALTED.CORE */
+   FIXED_EVENT_CONSTRAINT(0x0300, 2), /* CPU_CLK_UNHALTED.REF */
+   INTEL_EVENT_CONSTRAINT(0x48, 0x4), /* L1D_PEND_MISS.* */
+   INTEL_UEVENT_CONSTRAINT(0x01c0, 0x2), /* INST_RETIRED.PREC_DIST */
+   INTEL_EVENT_CONSTRAINT(0xcd, 0x8), /* MEM_TRANS_RETIRED.LOAD_LATENCY */
+   EVENT_CONSTRAINT_END
+};
+
 static u64 intel_pmu_event_map(int hw_event)
 {
return intel_perfmon_event_map[hw_event];
@@ -1585,6 +1597,45 @@ static void core_pmu_enable_all(int added)
}
 }
 
+static int hsw_hw_config(struct perf_event *event)
+{
+   int ret = intel_pmu_hw_config(event);
+
+   if (ret)
+   return ret;
+   if (!boot_cpu_has(X86_FEATURE_RTM) && !boot_cpu_has(X86_FEATURE_HLE))
+   return 0;
+   event->hw.config |= event->attr.config & 
(HSW_INTX|HSW_INTX_CHECKPOINTED);
+
+   /*
+* INTX/INTX-CP do not play well with PEBS or ANY thread mode.
+*/
+   if ((event->hw.config & (HSW_INTX|HSW_INTX_CHECKPOINTED)) &&
+((event->hw.config & ARCH_PERFMON_EVENTSEL_ANY) ||
+ event->attr.precise_ip > 0))
+   return -EOPNOTSUPP;
+
+   return 0;
+}
+
+static struct event_constraint counter2_constraint =
+   EVENT_CONSTRAINT(0, 0x4, 0);
+
+static struct event_constraint *
+hsw_get_event_constraints(struct cpu_hw_events *cpuc, struct perf_event *event)
+{
+   struct event_constraint *c = intel_get_event_constraints(cpuc, event);
+
+   /* Handle special quirk on intx_checkpointed only in counter 2 */
+   if (event->hw.config & HSW_INTX_CHECKPOINTED) {
+   if (c->idxmsk64 & (1U << 2))
+   return _constraint;
+   return 
+   }
+
+   return c;
+}
+
 PMU_FORMAT_ATTR(event, "config:0-7");
 PMU_FORMAT_ATTR(umask, "config:8-15"   );
 PMU_FORMAT_ATTR(edge,  "config:18" );
@@ -2107,6 +2158,26 @@ __init int intel_pmu_init(void)
break;
 
 
+   case 60: /* Haswell Client */
+   case 70:
+   case 71:
+   memcpy(hw_cache_event_ids, snb_hw_cache_event_ids,
+  sizeof(hw_cache_event_ids));
+
+

Basic perf PMU support for Haswell v3

This is based on v7 of the full Haswell PMU support, but 
ported to the latest perf/core and stripped down to the
extreme "perf for dummies" edition as requested.  

I removed some more patches, these will come soon later.
I moved parts of an later patch (counter constraints for qualifiers) 
into an earlier patch, to support the full raw bits at least.

For anything beyond basic usage this is not very useful.
I expect speedy merging of the other parts now.
No git branch, because it doesn't make sense to have that 
many branches.

Contains support for:
- Basic Haswell PMU and PEBS support
- Late unmasking of the PMI
- Support for wide counters

v2: Addressed Stephane's feedback. See individual patches for details.
v3: now even more bite-sized. Qualifier constraints merged earlier.
Add some Reviewed-bys.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/5] perf, x86: Move NMI clearing to end of PMI handler after the counter registers are reset

From: Andi Kleen 

This avoids some problems with spurious PMIs on Haswell.
Haswell seems to behave more like P4 in this regard. Do
the same thing as the P4 perf handler by unmasking
the NMI only at the end. Shouldn't make any difference
for earlier non P4 cores.

Signed-off-by: Andi Kleen 
---
 arch/x86/kernel/cpu/perf_event_intel.c |   15 +--
 1 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event_intel.c 
b/arch/x86/kernel/cpu/perf_event_intel.c
index d96010a..33fc662 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -1122,16 +1122,6 @@ static int intel_pmu_handle_irq(struct pt_regs *regs)
 
cpuc = &__get_cpu_var(cpu_hw_events);
 
-   /*
-* Some chipsets need to unmask the LVTPC in a particular spot
-* inside the nmi handler.  As a result, the unmasking was pushed
-* into all the nmi handlers.
-*
-* This handler doesn't seem to have any issues with the unmasking
-* so it was left at the top.
-*/
-   apic_write(APIC_LVTPC, APIC_DM_NMI);
-
intel_pmu_disable_all();
handled = intel_pmu_drain_bts_buffer();
status = intel_pmu_get_status();
@@ -1191,6 +1181,11 @@ again:
 
 done:
intel_pmu_enable_all(0);
+   /*
+* Only unmask the NMI after the overflow counters
+* have been reset.
+*/
+   apic_write(APIC_LVTPC, APIC_DM_NMI);
return handled;
 }
 
-- 
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] [DONOTAPPLY] [PATCH] enhanceio: STEC EnhanceIO SSD caching software for Linux kernel

2013-02-01 Thread Darrick J. Wong

On Fri, Feb 01, 2013 at 05:25:29PM -0800, Kent Overstreet wrote:
> Also, where's the end user documentation?

I was trying not to explode this patch's size, since the doc can go straight
into Documentation/ without as much fuss as, say, the ~1600 checkpatch
warnings and all the other comments we'll have about the source code.

> On Fri, Feb 1, 2013 at 5:23 PM, Kent Overstreet  
> wrote:
> > On Fri, Feb 1, 2013 at 4:57 PM, Michel Lespinasse  wrote:
> >> On Fri, Feb 1, 2013 at 4:44 PM, Darrick J. Wong  
> >> wrote:
> >>> This is a patch to migrate STEC's enhanceio driver out of their github
> >>> repository and into the staging tree.  From their README:
> >>>
> >>> "EnhanceIO driver is based on EnhanceIO SSD caching software product 
> >>> developed
> >>> by STEC Inc. EnhanceIO was derived from Facebook's open source Flashcache
> >>> project. EnhanceIO uses SSDs as cache devices for traditional rotating 
> >>> hard
> >>> disk drives (referred to as source volumes throughout this document).
> >>> EnhanceIO can work with any block device, be it an entire physical disk, 
> >>> an
> >>> individual disk partition,  a RAIDed DAS device, a SAN volume, a device 
> >>> mapper
> >>> volume or a software RAID (md) device."
> >>
> >> What's your take on the benefits of this vs bcache ?
> >
> > I've been trying to review it it for cache coherency and consistency
> > wrt. power failures, but the complete lack of high level documentation
> > is making that difficult.

Agreed. :/

> > I saw some benchmarks the other day where on writes EIO was faster
> > than the raw device, which was... suspicious.

Hmm, I haven't seen /that/, but then I wasn't specifically looking for it
either.

--D
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] perf: add new uncore command

> And there's a patchset [1] from Jiri to support some kind of formula -
> yeah, now I've written the correct spelling. :) - that might fit to this
> purpose if you provide suitable formula file IMHO.  So I guess we don't
> need to have another command and can reuse perf stat, no?

Yes with a proper expression engine it's all redundant. I haven't 
looked at Jiri's stuff in detail, but it seemed very simple-minded
and may not support all the computation needed.

Also would allow to finally replace the bogus perf stat -d frontend/backend
counters.

For stat there's no really a compelling reason to integrate
it, the usual wrappers work as well. They have the advantage that
they can be written in real programing languages, instead of trying
to invent a new one.

Expressions integrated would be mainly useful for things like
"counting perf top"

-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] [DONOTAPPLY] [PATCH] enhanceio: STEC EnhanceIO SSD caching software for Linux kernel

2013-02-01 Thread Kent Overstreet

Also, where's the end user documentation?

On Fri, Feb 1, 2013 at 5:23 PM, Kent Overstreet  wrote:
> On Fri, Feb 1, 2013 at 4:57 PM, Michel Lespinasse  wrote:
>> On Fri, Feb 1, 2013 at 4:44 PM, Darrick J. Wong  
>> wrote:
>>> This is a patch to migrate STEC's enhanceio driver out of their github
>>> repository and into the staging tree.  From their README:
>>>
>>> "EnhanceIO driver is based on EnhanceIO SSD caching software product 
>>> developed
>>> by STEC Inc. EnhanceIO was derived from Facebook's open source Flashcache
>>> project. EnhanceIO uses SSDs as cache devices for traditional rotating hard
>>> disk drives (referred to as source volumes throughout this document).
>>> EnhanceIO can work with any block device, be it an entire physical disk, an
>>> individual disk partition,  a RAIDed DAS device, a SAN volume, a device 
>>> mapper
>>> volume or a software RAID (md) device."
>>
>> What's your take on the benefits of this vs bcache ?
>
> I've been trying to review it it for cache coherency and consistency
> wrt. power failures, but the complete lack of high level documentation
> is making that difficult.
>
> I saw some benchmarks the other day where on writes EIO was faster
> than the raw device, which was... suspicious.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [DONOTAPPLY] [PATCH] enhanceio: STEC EnhanceIO SSD caching software for Linux kernel

2013-02-01 Thread Kent Overstreet

On Fri, Feb 1, 2013 at 4:57 PM, Michel Lespinasse  wrote:
> On Fri, Feb 1, 2013 at 4:44 PM, Darrick J. Wong  
> wrote:
>> This is a patch to migrate STEC's enhanceio driver out of their github
>> repository and into the staging tree.  From their README:
>>
>> "EnhanceIO driver is based on EnhanceIO SSD caching software product 
>> developed
>> by STEC Inc. EnhanceIO was derived from Facebook's open source Flashcache
>> project. EnhanceIO uses SSDs as cache devices for traditional rotating hard
>> disk drives (referred to as source volumes throughout this document).
>> EnhanceIO can work with any block device, be it an entire physical disk, an
>> individual disk partition,  a RAIDed DAS device, a SAN volume, a device 
>> mapper
>> volume or a software RAID (md) device."
>
> What's your take on the benefits of this vs bcache ?

I've been trying to review it it for cache coherency and consistency
wrt. power failures, but the complete lack of high level documentation
is making that difficult.

I saw some benchmarks the other day where on writes EIO was faster
than the raw device, which was... suspicious.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 9/16] fs/ext4/indirect.c: use WARN

2013-02-01 Thread Theodore Ts'o

On Sat, Nov 03, 2012 at 11:58:30AM +0100, Julia Lawall wrote:
> From: Julia Lawall 
> 
> Use WARN rather than printk followed by WARN_ON(1), for conciseness.
> 
> A simplified version of the semantic patch that makes this transformation
> is as follows: (http://coccinelle.lip6.fr/)
> 
> // 
> @@
> expression list es;
> @@
> 
> -printk(
> +WARN(1,
>   es);
> -WARN_ON(1);
> // 
> 
> Signed-off-by: Julia Lawall 

Thanks, applied.

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [DONOTAPPLY] [PATCH] enhanceio: STEC EnhanceIO SSD caching software for Linux kernel

2013-02-01 Thread Michel Lespinasse

On Fri, Feb 1, 2013 at 4:44 PM, Darrick J. Wong  wrote:
> This is a patch to migrate STEC's enhanceio driver out of their github
> repository and into the staging tree.  From their README:
>
> "EnhanceIO driver is based on EnhanceIO SSD caching software product developed
> by STEC Inc. EnhanceIO was derived from Facebook's open source Flashcache
> project. EnhanceIO uses SSDs as cache devices for traditional rotating hard
> disk drives (referred to as source volumes throughout this document).
> EnhanceIO can work with any block device, be it an entire physical disk, an
> individual disk partition,  a RAIDed DAS device, a SAN volume, a device mapper
> volume or a software RAID (md) device."

What's your take on the benefits of this vs bcache ?

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

2013-02-01 Thread Russell King - ARM Linux

On Sat, Feb 02, 2013 at 04:07:59AM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 02-02-2013 1:30, Russell King - ARM Linux wrote:
>
>>> On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
> good point, do you wanna send some patches ?
>
 I have already sent them countless times and even stuck CPPI 4.1 
 support (in
 arch/arm/common/cppi41.c) in Russell's patch system. TI requested to 
 remove the
 patch. :-(
>
>>> sticking into arch/arm/common/ wasn't a nice move. But then again, so
>>> wasn't asking for the patch to be removed :-s
>
>> Err, patches don't get removed, they get moved to 'discarded'.
>
>Any chance to bring it back to life? :-)
>Although... drivers/usb/musb/cppi41.c would need to be somewhat 
> reworked for at least AM35x and I don't have time. But that may change, 
> of course.

Right, I've just looked back at the various meeting minutes from December
2010 when the CPPI stuff was discussed.  Yes, I archive these things and
all email discussions for referencing in cases like this.

Unfortunately, they do not contain any useful information other than the
topic having been brought up.  At that point, the CPPI stuff was in
mach-davinci, and I had suggested moving it into drivers/dma.

The result of that was to say that it doesn't fit the DMA engine APIs.
So someone came up with the idea of putting it in arch/arm/common - which
I frankly ignored by email (how long have we been saying "no drivers in
arch/arm" ?)

Now, it would've been discussed in that meeting, but unfortunately no
record exists of that.  What does follow that meeting is a discussion
trail.  From what I can see there, but it looks to me like the decision
was taken to move it to the DMA engine API, and work on sorting out MUSB
was going to commence.

The last email in that says "I'll get to that soon"... and that is also
the final email I have on this topic.  I guess if nothing has happened...
Shrug, that's someone elses problem.

Anyway, the answer for putting it in arch/arm/common hasn't changed,
and really, where we are now, post Linus having a moan about the size
of arch/arm, that answer is even more concrete in the negative.  It's
54K of code which should not be under arch/arm at all.

Anyway, if you need to look at the patch, it's 6305/1.  Typing into the
summary search box 'cppi' found it in one go.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/9] mm: zone & pgdat accessors plus some cleanup

On Thu, 17 Jan 2013 14:52:52 -0800
Cody P Schafer  wrote:

> Summaries:
> 1 - avoid repeating checks for section in page flags by adding a define.
> 2 - add & switch to zone_end_pfn() and zone_spans_pfn()
> 3 - adds zone_is_initialized() & zone_is_empty()
> 4 - adds a VM_BUG using zone_is_initialized() in __free_one_page()
> 5 - add pgdat_end_pfn() and pgdat_is_empty()
> 6 - add debugging message to VM_BUG check.
> 7 - add ensure_zone_is_initialized() (for memory_hotplug)
> 8 - use the above addition in memory_hotplug
> 9 - use pgdat_end_pfn()

Well that's a nice little patchset.

Some of the patches were marked From:c...@linux.vnet.ibm.com and others
were From:jmes...@gmail.com.  This is strange.  If you want me to fix
that up, please let me know which is preferred.

> As a general concern: spanned_pages & start_pfn (in pgdat & zone) are supposed
> to be locked (via a seqlock) when read (due to changes to them via
> memory_hotplug), but very few (only 1?) of their users appear to actually lock
> them.

OK, thanks.  Perhaps this is something which the memory-hotplug
developers could take a look at?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/9] mm/page_alloc: add informative debugging message in page_outside_zone_boundaries()

On Fri, 1 Feb 2013 16:28:48 -0800
Andrew Morton  wrote:

> > +   if (ret)
> > +   pr_debug("page %lu outside zone [ %lu - %lu ]\n",
> > +   pfn, start_pfn, start_pfn + sp);
> > +
> > return ret;
> >  }
> 
> As this condition leads to a VM_BUG_ON(), "pr_debug" seems rather wimpy
> and I doubt if we need to be concerned about flooding the console.
> 
> I'll switch it to pr_err.

otoh, as nobody has ever hit that VM_BUG_ON() (yes?), do we really need
the patch?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/9] mm/page_alloc: add informative debugging message in page_outside_zone_boundaries()

On Thu, 17 Jan 2013 14:52:58 -0800
Cody P Schafer  wrote:

> Add a debug message which prints when a page is found outside of the
> boundaries of the zone it should belong to. Format is:
>   "page $pfn outside zone [ $start_pfn - $end_pfn ]"
> 
> Signed-off-by: Cody P Schafer 
> ---
>  mm/page_alloc.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index f8ed277..f1783cf 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -239,13 +239,20 @@ static int page_outside_zone_boundaries(struct zone 
> *zone, struct page *page)
>   int ret = 0;
>   unsigned seq;
>   unsigned long pfn = page_to_pfn(page);
> + unsigned long sp, start_pfn;
>  
>   do {
>   seq = zone_span_seqbegin(zone);
> + start_pfn = zone->zone_start_pfn;
> + sp = zone->spanned_pages;
>   if (!zone_spans_pfn(zone, pfn))
>   ret = 1;
>   } while (zone_span_seqretry(zone, seq));
>  
> + if (ret)
> + pr_debug("page %lu outside zone [ %lu - %lu ]\n",
> + pfn, start_pfn, start_pfn + sp);
> +
>   return ret;
>  }

As this condition leads to a VM_BUG_ON(), "pr_debug" seems rather wimpy
and I doubt if we need to be concerned about flooding the console.

I'll switch it to pr_err.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/9] mmzone: add pgdat_{end_pfn,is_empty}() helpers & consolidate.

On Thu, 17 Jan 2013 14:52:57 -0800
Cody P Schafer  wrote:

> From: Cody P Schafer 
> 
> Add pgdat_end_pfn() and pgdat_is_empty() helpers which match the similar
> zone_*() functions.
> 
> Change node_end_pfn() to be a wrapper of pgdat_end_pfn().
> 
> ...
>
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -772,11 +772,17 @@ typedef struct pglist_data {
>  #define nid_page_nr(nid, pagenr) pgdat_page_nr(NODE_DATA(nid),(pagenr))
>  
>  #define node_start_pfn(nid)  (NODE_DATA(nid)->node_start_pfn)
> +#define node_end_pfn(nid) pgdat_end_pfn(NODE_DATA(nid))

I wonder if these could be implemented in nice C code rather than nasty
cpp code.

> -#define node_end_pfn(nid) ({\
> - pg_data_t *__pgdat = NODE_DATA(nid);\
> - __pgdat->node_start_pfn + __pgdat->node_spanned_pages;\
> -})
> +static inline unsigned long pgdat_end_pfn(pg_data_t *pgdat)
> +{
> + return pgdat->node_start_pfn + pgdat->node_spanned_pages;
> +}

It wouldn't hurt to add a little comment pointing out that this returns
"end pfn plus one", or similar.  ie, it is exclusive, not inclusive. 
Ditto the "zone_*() functions", if needed.

> +static inline bool pgdat_is_empty(pg_data_t *pgdat)
> +{
> + return !pgdat->node_start_pfn && !pgdat->node_spanned_pages;
> +}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/9] mm: add SECTION_IN_PAGE_FLAGS

On Thu, 17 Jan 2013 14:52:53 -0800
Cody P Schafer  wrote:

> Instead of directly utilizing a combination of config options to determine 
> this,
> add a macro to specifically address it.
> 
> ...
>
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -625,6 +625,10 @@ static inline pte_t maybe_mkwrite(pte_t pte, struct 
> vm_area_struct *vma)
>  #define NODE_NOT_IN_PAGE_FLAGS
>  #endif
>  
> +#if defined(CONFIG_SPARSEMEM) && !defined(CONFIG_SPARSEMEM_VMEMMAP)
> +#define SECTION_IN_PAGE_FLAGS
> +#endif

We could do this in Kconfig itself, in the definition of a new
CONFIG_SECTION_IN_PAGE_FLAGS.

I'm not sure that I like that sort of thing a lot though - it's rather a
pain to have to switch from .[ch] over to Kconfig to find the
definitions of things.  I should get off my tail and teach my ctags
scripts to handle this.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common


Hello.

On 02-02-2013 1:30, Russell King - ARM Linux wrote:


On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:

good point, do you wanna send some patches ?



I have already sent them countless times and even stuck CPPI 4.1 support (in
arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the
patch. :-(



sticking into arch/arm/common/ wasn't a nice move. But then again, so
wasn't asking for the patch to be removed :-s



Err, patches don't get removed, they get moved to 'discarded'.



I guess to make the MUSB side simpler we would need musb-dma-engine glue
to map dmaengine to the private MUSB API. Then we would have some
starting point to also move inventra (and anybody else) to dmaengine
API.



Why? Inventra is a dedicated device's private DMA controller, why make
universal DMA driver for it?



because it doesn't make sense to support multiple DMA APIs. We can check
from MUSB's registers if it was configured with Inventra DMA support and
based on that we can register MUSB's own DMA Engine to dmaengine API.



Hang on.  This is one of the DMA implementations which is closely
coupled with the USB and only the USB?  If it is...



I thought this had been discussed _extensively_ before.  I thought the
resolution on it was:
1. It would not use the DMA engine API.
2. It would not live in arch/arm.
3. It would be placed nearby the USB driver it's associated with.


   Note that all this doesn't apply to CPPI 4.1 controller (as contrasted to 
CPPI 3.0 support in MUSB aand EMAC drivers) -- it's shared by design. Just the 
implementations that are in tree have it as MUSB's sub-block, serving only MUSB.


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm: accelerate mm_populate() treatment of THP pages

On Wed, 30 Jan 2013 16:26:19 -0800
Michel Lespinasse  wrote:

> This change adds a page_mask argument to follow_page.
> 
> follow_page sets *page_mask to HPAGE_PMD_NR - 1 when it encounters a THP page,
> and to 0 in other cases.
> 
> __get_user_pages() makes use of this in order to accelerate populating
> THP ranges - that is, when both the pages and vmas arrays are NULL,
> we don't need to iterate HPAGE_PMD_NR times to cover a single THP page
> (and we also avoid taking mm->page_table_lock that many times).
> 
> Other follow_page() call sites can safely ignore the value returned in
> *page_mask.

Seems sensible, but the implementation is rather ungainly.

If we're going to add this unused page_mask local to many functions
then let's at least miminize the scope of that variable and explain why
it's there.  For example,

--- a/mm/ksm.c~mm-accelerate-mm_populate-treatment-of-thp-pages-fix
+++ a/mm/ksm.c
@@ -356,9 +356,10 @@ static int break_ksm(struct vm_area_stru
 {
struct page *page;
int ret = 0;
-   long page_mask;
 
do {
+   long page_mask; /* unused */
+
cond_resched();
page = follow_page(vma, addr, FOLL_GET, _mask);
if (IS_ERR_OR_NULL(page))
@@ -454,7 +455,7 @@ static struct page *get_mergeable_page(s
unsigned long addr = rmap_item->address;
struct vm_area_struct *vma;
struct page *page;
-   long page_mask;
+   long page_mask; /* unused */
 
down_read(>mmap_sem);
vma = find_mergeable_vma(mm, addr);
@@ -1525,7 +1526,6 @@ static struct rmap_item *scan_get_next_r
struct mm_slot *slot;
struct vm_area_struct *vma;
struct rmap_item *rmap_item;
-   long page_mask;
int nid;
 
if (list_empty(_mm_head.mm_list))
@@ -1600,6 +1600,8 @@ next_mm:
ksm_scan.address = vma->vm_end;
 
while (ksm_scan.address < vma->vm_end) {
+   long page_mask; /* unused */
+
if (ksm_test_exit(mm))
break;
*page = follow_page(vma, ksm_scan.address, FOLL_GET,



Alternatively we could permit the passing of page_mask==NULL, which is
a common convention in the get_user_pages() area.  Possibly that's a
tad more expensive, but it will save a stack slot.


However I think the best approach here is to just leave the
follow_page() interface alone.  Rename the present implementation to
follow_page_mask() or whatever and add

static inline void follow_page(args)
{
long page_mask; /* unused */

return follow_page_mask(args, _mask);
}

Also, I see no sense in permitting negative page_mask values and I
doubt if we'll be needing 64-bit values here.  Make it `unsigned int'?


Finally, this version of the patch surely breaks the nommu build?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common


Hello.

On 02-02-2013 1:30, Russell King - ARM Linux wrote:


On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:

good point, do you wanna send some patches ?



I have already sent them countless times and even stuck CPPI 4.1 support (in
arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the
patch. :-(



sticking into arch/arm/common/ wasn't a nice move. But then again, so
wasn't asking for the patch to be removed :-s



Err, patches don't get removed, they get moved to 'discarded'.


   Any chance to bring it back to life? :-)
   Although... drivers/usb/musb/cppi41.c would need to be somewhat reworked 
for at least AM35x and I don't have time. But that may change, of course.



I guess to make the MUSB side simpler we would need musb-dma-engine glue
to map dmaengine to the private MUSB API. Then we would have some
starting point to also move inventra (and anybody else) to dmaengine
API.



Why? Inventra is a dedicated device's private DMA controller, why make
universal DMA driver for it?



because it doesn't make sense to support multiple DMA APIs. We can check
from MUSB's registers if it was configured with Inventra DMA support and
based on that we can register MUSB's own DMA Engine to dmaengine API.



Hang on.  This is one of the DMA implementations which is closely
coupled with the USB and only the USB?  If it is...



I thought this had been discussed _extensively_ before.  I thought the
resolution on it was:
1. It would not use the DMA engine API.
2. It would not live in arch/arm.
3. It would be placed nearby the USB driver it's associated with.



(1) because we don't use APIs just for the hell of it - think.  Do we
use the DMA engine API for PCI bus mastering ethernet controllers?  No.
Do we use it for PCI bus mastering SCSI controllers?  No.  Because the
DMA is integral to the rest of the device.



The DMA engine API only makes sense if the DMA engine is a shared
system resource.


   Thanks for such extensive wording in the support of my point. :-)

WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common


Hello.

On 01-02-2013 22:59, Matt Porter wrote:


Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.



I think this should rather go to drivers/dma/?



No, this is the private EDMA API. It's the analogous thing to
the private OMAP dma API that is in plat-omap/dma.c. The actual
dmaengine driver is in drivers/dma/edma.c as a wrapper around
this...same way OMAP DMA engine conversion is being done.



   Keeps me wondering why we couldn't have the same with CPPI 4.1 when I 
proposed
that, instead of waiting indefinitely for TI to convert it to drivers/dma/
directly. We could have working MUSB DMA on OMAP-L1x/Sitara all this time... 
Sigh.



That is a shame. Yeah, I've pointed out that I was doing this exactly
the same way as was acceptable for the OMAP DMA conversion since it was
in RFC. The reasons are sound since in both cases, we have many drivers
to convert that need to continue using the private DMA APIs.


   In case of CPPI 4.1, we'd only have to convert MUSB DMA driver. Other 
in-tree CPPI 4.1 having SoCs don't use it for anything but MUSB -- it even is 
sub-block of their MUSB device, AFAIK (I maybe wrong about Sitaras -- I don't 
know them well).



-Matt


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] acpiphp: remove dead code for PCI host bridge hotplug

2013-02-01 Thread Yinghai Lu

On Fri, Feb 1, 2013 at 12:50 AM, Yijing Wang  wrote:
> On 2013/1/31 23:59, Yinghai Lu wrote:
>> On Thu, Jan 31, 2013 at 7:37 AM, Jiang Liu  wrote:
>>>
>>> So I think the code in handle_hotplug_event_bridge() to handle P2P 
>>> hot-addition
>>> is dead. Yijing has helped to test the code by faking ACPI CUSTOM_METHOD, 
>>> and it
>>> does work as expected.
>>
>> ok, then.
>>
>> It would be better if you can append some print out from Yijing's test
>> in the changelog.
>>
>
> Hi Yinghai,
>I used custom_method module to make root port device :00:07.0 support 
> acpi hotplug (by adding _EJ0 method),
> This root port device also connected to a slot which support hotplug. I 
> tested to hot plug root port device :00:07.0,
> and test steps and info as bellow, if there are somethings missing during 
> test, please let me know.
> Thanks very much!
>
> linux-ha2:/sys/bus/pci/slots # lspci -tv
>  \-[:00]-+-00.0  Intel Corporation 5520/5500/X58 I/O Hub to ESI Port
>  +-01.0-[:01]--+-00.0  Intel Corporation 82576 Gigabit 
> Network Connection
>  | \-00.1  Intel Corporation 82576 Gigabit 
> Network Connection
>  +-03.0-[:02]00.0  LSI Logic / Symbios Logic SAS1064ET 
> PCI-Express Fusion-MPT SAS
>  +-04.0-[:03]--
>  +-05.0-[:04]--
>  +-07.0-[:05]--+-00.0  nVidia Corporation GT218 [GeForce G210]
>  | \-00.1  nVidia Corporation High Definition 
> Audio Controller
>  +-0d.0  Intel Corporation Device 343a
> linux-ha2:/sys/bus/pci/slots # ls
> 0  0-1  1  3  5  7
> linux-ha2:/sys/bus/pci/slots # cat 1/address
> :00:07
> linux-ha2:/sys/bus/pci/slots # cd 1
> linux-ha2:/sys/bus/pci/slots/1 # ls
> adapter  address  attention  cur_bus_speed  latch  max_bus_speed  module  
> power
> linux-ha2:/sys/bus/pci/slots/1 # cat power
> 1
> linux-ha2:/sys/bus/pci/slots/1 # echo "\_SB_.NOD0.PCI0.MRP7 3" > 
> /sys/kernel/debug/acpi/sci_notify
> linux-ha2:/sys/bus/pci/slots/1 # cat power
> 0
> linux-ha2:/sys/bus/pci/slots/1 # lspci -tv
>  \-[:00]-+-00.0  Intel Corporation 5520/5500/X58 I/O Hub to ESI Port
>  +-01.0-[:01]--+-00.0  Intel Corporation 82576 Gigabit 
> Network Connection
>  | \-00.1  Intel Corporation 82576 Gigabit 
> Network Connection
>  +-03.0-[:02]00.0  LSI Logic / Symbios Logic SAS1064ET 
> PCI-Express Fusion-MPT SAS
>  +-04.0-[:03]--
>  +-05.0-[:04]--
>  +-0d.0  Intel Corporation Device 343a
> linux-ha2:/sys/bus/pci/slots/1 # echo "\_SB_.NOD0.PCI0.MRP7 1" > 
> /sys/kernel/debug/acpi/sci_notify
> linux-ha2:/sys/bus/pci/slots/1 # cat power
> 1
> linux-ha2:/sys/bus/pci/slots/1 # lspci -tv
>  \-[:00]-+-00.0  Intel Corporation 5520/5500/X58 I/O Hub to ESI Port
>  +-01.0-[:01]--+-00.0  Intel Corporation 82576 Gigabit 
> Network Connection
>  | \-00.1  Intel Corporation 82576 Gigabit 
> Network Connection
>  +-03.0-[:02]00.0  LSI Logic / Symbios Logic SAS1064ET 
> PCI-Express Fusion-MPT SAS
>  +-04.0-[:03]--
>  +-05.0-[:04]--
>  +-07.0-[:05]--+-00.0  nVidia Corporation GT218 [GeForce G210]
>  | \-00.1  nVidia Corporation High Definition 
> Audio Controller
>  +-0d.0  Intel Corporation Device 343a

looks good.

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: [Xen-devel] [PATCH] PVH linux: Use ballooning to allocate grant table pages

2013-02-01 Thread Mukesh Rathor

On Fri, 1 Feb 2013 14:00:58 -0800
Mukesh Rathor  wrote:

> On Thu, 31 Jan 2013 18:44:46 -0800
> Mukesh Rathor  wrote:
> 
> > On Thu, 31 Jan 2013 18:30:15 -0800
> > Mukesh Rathor  wrote:
> > 
> > > This patch fixes a fixme in Linux to use
> > > alloc_xenballooned_pages() to allocate pfns for grant table pages
> > > instead of kmalloc. This also simplifies add to physmap on the
> > > xen side a bit.
> > 
> > Looking at it again, I realized rc should be signed in
> > gnttab_resume(). Below again. Thanks.
> 
> Konrad, Please hold off on this patch. I discovered an issue on the 
> domU side with this change. I'm currently investigating if it's 
> related.

Ah right, I forgot the pfn's from balloon may not be always contigous.
Besides these are special pfns so to speak, so in gnttab_map()
virt_to_pfn doesn't work. 

I'm gonna have to create a separate gnttab map routine for pvh case, it
appears. Shouldn't be too bad tho.

thanks,
Mukesh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 00/33] 3.4.29-stable review

2013-02-01 Thread Shuah Khan

On Fri, Feb 1, 2013 at 3:49 AM, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 3.4.29 release.
> There are 33 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 Feb  3 10:47:08 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.29-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Patches applied cleanly to 3.0.61, 3.4.28, and 3.7.5.
Compiled and booted on the following systems:
HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics

Cross-compile tests:
alpha: defconfig passed on all
arm: defconfig passed on all
arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.7.y
c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.7.y.
mips: defconfig passed on all
mipsel: defconfig passed on all
powerpc: wii_defconfig passed on all
sh: defconfig passed on all
sparc: defconfig passed on all
tile: tilegx_defconfig passed on all

-- Shuah
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 00/89] 3.7.6-stable review

2013-02-01 Thread Shuah Khan

On Fri, Feb 1, 2013 at 6:07 AM, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 3.7.6 release.
> There are 89 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 Feb  3 13:01:49 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.7.6-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Patches applied cleanly to 3.0.61, 3.4.28, and 3.7.5.
Compiled and booted on the following systems:
HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics

Cross-compile tests:
alpha: defconfig passed on all
arm: defconfig passed on all
arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.7.y
c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.7.y.
mips: defconfig passed on all
mipsel: defconfig passed on all
powerpc: wii_defconfig passed on all
sh: defconfig passed on all
sparc: defconfig passed on all
tile: tilegx_defconfig passed on all

-- Shuah
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v2 01/12] Add sys_hotplug.h for system device hotplug framework

2013-02-01 Thread Toshi Kani

On Fri, 2013-02-01 at 23:21 +0100, Rafael J. Wysocki wrote:
> On Friday, February 01, 2013 01:40:10 PM Toshi Kani wrote:
> > On Fri, 2013-02-01 at 07:30 +, Greg KH wrote:
> > > On Thu, Jan 31, 2013 at 06:32:18PM -0700, Toshi Kani wrote:
> > >  > This is already done for PCI host bridges and platform devices and I 
> > > don't
> > > > > see why we can't do that for the other types of devices too.
> > > > > 
> > > > > The only missing piece I see is a way to handle the "eject" problem, 
> > > > > i.e.
> > > > > when we try do eject a device at the top of a subtree and need to 
> > > > > tear down
> > > > > the entire subtree below it, but if that's going to lead to a system 
> > > > > crash,
> > > > > for example, we want to cancel the eject.  It seems to me that we'll 
> > > > > need some
> > > > > help from the driver core here.
> > > > 
> > > > There are three different approaches suggested for system device
> > > > hot-plug:
> > > >  A. Proceed within system device bus scan.
> > > >  B. Proceed within ACPI bus scan.
> > > >  C. Proceed with a sequence (as a mini-boot).
> > > > 
> > > > Option A uses system devices as tokens, option B uses acpi devices as
> > > > tokens, and option C uses resource tables as tokens, for their handlers.
> > > > 
> > > > Here is summary of key questions & answers so far.  I hope this
> > > > clarifies why I am suggesting option 3.
> > > > 
> > > > 1. What are the system devices?
> > > > System devices provide system-wide core computing resources, which are
> > > > essential to compose a computer system.  System devices are not
> > > > connected to any particular standard buses.
> > > 
> > > Not a problem, lots of devices are not connected to any "particular
> > > standard busses".  All this means is that system devices are connected
> > > to the "system" bus, nothing more.
> > 
> > Can you give me a few examples of other devices that support hotplug and
> > are not connected to any particular buses?  I will investigate them to
> > see how they are managed to support hotplug.
> > 
> > > > 2. Why are the system devices special?
> > > > The system devices are initialized during early boot-time, by multiple
> > > > subsystems, from the boot-up sequence, in pre-defined order.  They
> > > > provide low-level services to enable other subsystems to come up.
> > > 
> > > Sorry, no, that doesn't mean they are special, nothing here is unique
> > > for the point of view of the driver model from any other device or bus.
> > 
> > I think system devices are unique in a sense that they are initialized
> > before drivers run.
> > 
> > > > 3. Why can't initialize the system devices from the driver structure at
> > > > boot?
> > > > The driver structure is initialized at the end of the boot sequence and
> > > > requires the low-level services from the system devices initialized
> > > > beforehand.
> > > 
> > > Wait, what "driver structure"?  
> > 
> > Sorry it was not clear.  cpu_dev_init() and memory_dev_init() are called
> > from driver_init() at the end of the boot sequence, and initialize
> > system/cpu and system/memory devices.  I assume they are the system bus
> > you are referring with option A.
> > 
> > > If you need to initialize the driver
> > > core earlier, then do so.  Or, even better, just wait until enough of
> > > the system has come up and then go initialize all of the devices you
> > > have found so far as part of your boot process.
> > 
> > They are pseudo drivers that provide sysfs entry points of cpu and
> > memory.  They do not actually initialize cpu and memory.  I do not think
> > initializing cpu and memory fits into the driver model either, since
> > drivers should run after cpu and memory are initialized.
> > 
> > > None of the above things you have stated seem to have anything to do
> > > with your proposed patch, so I don't understand why you have mentioned
> > > them...
> > 
> > You suggested option A before, which uses system bus scan to initialize
> > all system devices at boot time as well as hot-plug.  I tried to say
> > that this option would not be doable.
> > 
> > > > 4. Why do we need a new common framework?
> > > > Sysfs CPU and memory on-lining/off-lining are performed within the CPU
> > > > and memory modules.  They are common code and do not depend on ACPI.
> > > > Therefore, a new common framework is necessary to integrate both
> > > > on-lining/off-lining operation and hot-plugging operation of system
> > > > devices into a single framework.
> > > 
> > > {sigh}
> > > 
> > > Removing and adding devices and handling hotplug operations is what the
> > > driver core was written for, almost 10 years ago.  To somehow think that
> > > your devices are "special" just because they don't use ACPI is odd,
> > > because the driver core itself has nothing to do with ACPI.  Don't get
> > > the current mix of x86 system code tied into ACPI confused with an
> > > driver core issues here please.
> > 
> > CPU online/offline operation is performed within the CPU

Re: [PATCH 2/2] acpiphp: remove dead code for PCI host bridge hotplug

On Wed, Jan 30, 2013 at 9:10 AM, Jiang Liu  wrote:
> From: Jiang Liu 
>
> Commit 668192b678201d2fff27c "PCI: acpiphp: Move host bridge hotplug
> to pci_root.c" has moved PCI host bridge hotplug logic from acpiphp
> to pci_root, but there is still PCI host bridge hotplug related
> dead code left in acpiphp. So remove those dead code.
>
> Now companion ACPI devices are always created before corresponding
> PCI devices. And the ACPI event handle_hotplug_event_bridge() will be
> installed only if it has associated PCI device. So remove dead code to
> handle bridge hot-adding in function handle_hotplug_event_bridge().
>
> Signed-off-by: Jiang Liu 

Applied to pci/yinghai-root-bus-hotplug for v3.9.  Thanks!

> ---
>  drivers/pci/hotplug/acpiphp.h  |   13 +---
>  drivers/pci/hotplug/acpiphp_glue.c |  124 
> 
>  2 files changed, 14 insertions(+), 123 deletions(-)
>
> diff --git a/drivers/pci/hotplug/acpiphp.h b/drivers/pci/hotplug/acpiphp.h
> index b3ead7a..b70ac00 100644
> --- a/drivers/pci/hotplug/acpiphp.h
> +++ b/drivers/pci/hotplug/acpiphp.h
> @@ -79,7 +79,6 @@ struct acpiphp_bridge {
> /* Ejectable PCI-to-PCI bridge (PCI bridge and PCI function) */
> struct acpiphp_func *func;
>
> -   int type;
> int nr_slots;
>
> u32 flags;
> @@ -146,10 +145,6 @@ struct acpiphp_attention_info
>  /* PCI bus bridge HID */
>  #define ACPI_PCI_HOST_HID  "PNP0A03"
>
> -/* PCI BRIDGE type */
> -#define BRIDGE_TYPE_HOST   0
> -#define BRIDGE_TYPE_P2P1
> -
>  /* ACPI _STA method value (ignore bit 4; battery present) */
>  #define ACPI_STA_PRESENT   (0x0001)
>  #define ACPI_STA_ENABLED   (0x0002)
> @@ -158,13 +153,7 @@ struct acpiphp_attention_info
>  #define ACPI_STA_ALL   (0x000f)
>
>  /* bridge flags */
> -#define BRIDGE_HAS_STA (0x0001)
> -#define BRIDGE_HAS_EJ0 (0x0002)
> -#define BRIDGE_HAS_HPP (0x0004)
> -#define BRIDGE_HAS_PS0 (0x0010)
> -#define BRIDGE_HAS_PS1 (0x0020)
> -#define BRIDGE_HAS_PS2 (0x0040)
> -#define BRIDGE_HAS_PS3 (0x0080)
> +#define BRIDGE_HAS_EJ0 (0x0001)
>
>  /* slot flags */
>
> diff --git a/drivers/pci/hotplug/acpiphp_glue.c 
> b/drivers/pci/hotplug/acpiphp_glue.c
> index acb7af2..4681d2c 100644
> --- a/drivers/pci/hotplug/acpiphp_glue.c
> +++ b/drivers/pci/hotplug/acpiphp_glue.c
> @@ -325,8 +325,8 @@ static void init_bridge_misc(struct acpiphp_bridge 
> *bridge)
> return;
> }
>
> -   /* install notify handler */
> -   if (bridge->type != BRIDGE_TYPE_HOST) {
> +   /* install notify handler for P2P bridges */
> +   if (!pci_is_root_bus(bridge->pci_bus)) {
> if ((bridge->flags & BRIDGE_HAS_EJ0) && bridge->func) {
> status = 
> acpi_remove_notify_handler(bridge->func->handle,
> ACPI_SYSTEM_NOTIFY,
> @@ -369,27 +369,12 @@ static struct acpiphp_func 
> *acpiphp_bridge_handle_to_function(acpi_handle handle
>  static inline void config_p2p_bridge_flags(struct acpiphp_bridge *bridge)
>  {
> acpi_handle dummy_handle;
> +   struct acpiphp_func *func;
>
> if (ACPI_SUCCESS(acpi_get_handle(bridge->handle,
> -   "_STA", _handle)))
> -   bridge->flags |= BRIDGE_HAS_STA;
> -
> -   if (ACPI_SUCCESS(acpi_get_handle(bridge->handle,
> -   "_EJ0", _handle)))
> +   "_EJ0", _handle))) {
> bridge->flags |= BRIDGE_HAS_EJ0;
>
> -   if (ACPI_SUCCESS(acpi_get_handle(bridge->handle,
> -   "_PS0", _handle)))
> -   bridge->flags |= BRIDGE_HAS_PS0;
> -
> -   if (ACPI_SUCCESS(acpi_get_handle(bridge->handle,
> -   "_PS3", _handle)))
> -   bridge->flags |= BRIDGE_HAS_PS3;
> -
> -   /* is this ejectable p2p bridge? */
> -   if (bridge->flags & BRIDGE_HAS_EJ0) {
> -   struct acpiphp_func *func;
> -
> dbg("found ejectable p2p bridge\n");
>
> /* make link between PCI bridge and PCI function */
> @@ -412,7 +397,6 @@ static void add_host_bridge(struct acpi_pci_root *root)
> if (bridge == NULL)
> return;
>
> -   bridge->type = BRIDGE_TYPE_HOST;
> bridge->handle = handle;
>
> bridge->pci_bus = root->bus;
> @@ -432,7 +416,6 @@ static void add_p2p_bridge(acpi_handle *handle)
> return;
> }
>
> -   bridge->type = BRIDGE_TYPE_P2P;
> bridge->handle = handle;
> config_p2p_bridge_flags(bridge);
>
> @@ -543,7 +526,7 @@ static void cleanup_bridge(struct acpiphp_bridge *bridge)
> acpi_status status;
> acpi_handle handle = bridge->handle;
>
> -   if

Re: [PATCH 1/2] acpiphp: create companion ACPI devices before creating PCI devices

On Fri, Feb 1, 2013 at 4:06 PM, Bjorn Helgaas  wrote:
> On Wed, Jan 30, 2013 at 9:10 AM, Jiang Liu  wrote:
>> From: Jiang Liu 
>>
>> With commit 4f535093cf8f6da8c "PCI: Put pci_dev in device tree as
>> early as possible", companion ACPI devices should be created before
>> creating correspoding PCI devices, otherwise it will break the ACPI
>> PCI binding logic.
>>
>> Signed-off-by: Jiang Liu 

Applied to pci/yinghai-root-bus for v3.9.  Thanks!

>> ---
>> Hi Bjorn,
>> This patch set applies to your pci/yinghai-root-bus branch.
>> There are still other potential bugs in the acpiphp driver under
>> investigation. So I will send out these two first to catch up with
>> the 3.9 merging window.
>> Thanks!
>> Gerry
>
> I assume this fixes some sort of user-visible issue with acpiphp.
> What failure does the user see?
>
>> ---
>>  drivers/pci/hotplug/acpiphp_glue.c |6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/pci/hotplug/acpiphp_glue.c 
>> b/drivers/pci/hotplug/acpiphp_glue.c
>> index bd784ff..acb7af2 100644
>> --- a/drivers/pci/hotplug/acpiphp_glue.c
>> +++ b/drivers/pci/hotplug/acpiphp_glue.c
>> @@ -839,6 +839,9 @@ static int __ref enable_device(struct acpiphp_slot *slot)
>> if (slot->flags & SLOT_ENABLED)
>> goto err_exit;
>>
>> +   list_for_each_entry(func, >funcs, sibling)
>> +   acpiphp_bus_add(func);
>> +
>> num = pci_scan_slot(bus, PCI_DEVFN(slot->device, 0));
>> if (num == 0) {
>> /* Maybe only part of funcs are added. */
>> @@ -862,9 +865,6 @@ static int __ref enable_device(struct acpiphp_slot *slot)
>> }
>> }
>>
>> -   list_for_each_entry(func, >funcs, sibling)
>> -   acpiphp_bus_add(func);
>> -
>> pci_bus_assign_resources(bus);
>> acpiphp_sanitize_bus(bus);
>> acpiphp_set_hpp_values(bus);
>> --
>> 1.7.9.5
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 10/18] mm: teach truncate_inode_pages_range() to handle non page aligned ranges

On Fri,  1 Feb 2013 11:43:36 +0100
Lukas Czerner  wrote:

> This commit changes truncate_inode_pages_range() so it can handle non
> page aligned regions of the truncate. Currently we can hit BUG_ON when
> the end of the range is not page aligned, but we can handle unaligned
> start of the range.
> 
> Being able to handle non page aligned regions of the page can help file
> system punch_hole implementations and save some work, because once we're
> holding the page we might as well deal with it right away.
> 
> In previous commits we've changed ->invalidatepage() prototype to accept
> 'length' argument to be able to specify range to invalidate. No we can
> use that new ability in truncate_inode_pages_range().

The change seems sensible.

> This was based on the code provided by Hugh Dickins

Despite this ;)

> changes to make use of do_invalidatepage_range().
>
> ...
>
>  void truncate_inode_pages_range(struct address_space *mapping,
>   loff_t lstart, loff_t lend)
>  {
> - const pgoff_t start = (lstart + PAGE_CACHE_SIZE-1) >> PAGE_CACHE_SHIFT;
> - const unsigned partial = lstart & (PAGE_CACHE_SIZE - 1);
> + pgoff_t start = (lstart + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
> + pgoff_t end = (lend + 1) >> PAGE_CACHE_SHIFT;
> + unsigned int partial_start = lstart & (PAGE_CACHE_SIZE - 1);
> + unsigned int partial_end = (lend + 1) & (PAGE_CACHE_SIZE - 1);
>   struct pagevec pvec;
>   pgoff_t index;
> - pgoff_t end;
>   int i;

This is starting to get pretty hairy.  Some of these "end" variables
are inclusive and some are exclusive.

Can we improve things?  We can drop all this tiresome
intialisation-at-declaration-site stuff and do:

pgoff_t start;  /* inclusive */
pgoff_t end;/* exclusive */
unsigned int partial_start; /* inclusive */
unsigned int partial_end;   /* exclusive */
struct pagevec pvec;
pgoff_t index;
int i;

start = (lstart + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
end = (lend + 1) >> PAGE_CACHE_SHIFT;
partial_start = lstart & (PAGE_CACHE_SIZE - 1);
partial_end = (lend + 1) & (PAGE_CACHE_SIZE - 1);

And lo, I see that the "inclusive" thing only applies to incoming arg
`lend'.  I seem to recall that being my handiwork and somehow I seem to
not have documented the reason: it was so that we can pass
lend=0x into truncate_inode_pages_range) to indicate "end of
file".

Your code handles this in a rather nasty fashion.  It permits the above
overflow to occur then later fixes it up with an explicit test for -1. 
And it then sets `end' (which is a pgoff_t!) to -1.

I guess this works, but let's make it clearer, with something like:

if (lend == -1) {
/*
 * Nice explanation goes here
 */
end = -1;
} else {
end = (lend + 1) >> PAGE_CACHE_SHIFT;
}


>   cleancache_invalidate_inode(mapping);
>   if (mapping->nrpages == 0)
>   return;
>  
> - BUG_ON((lend & (PAGE_CACHE_SIZE - 1)) != (PAGE_CACHE_SIZE - 1));
> - end = (lend >> PAGE_CACHE_SHIFT);
> + if (lend == -1)
> + end = -1;   /* unsigned, so actually very big */
>  
>   pagevec_init(, 0);
>   index = start;
> - while (index <= end && pagevec_lookup(, mapping, index,
> - min(end - index, (pgoff_t)PAGEVEC_SIZE - 1) + 1)) {
> + while (index < end && pagevec_lookup(, mapping, index,
> + min(end - index, (pgoff_t)PAGEVEC_SIZE))) {

Here, my brain burst.  You've effectively added 1 to (end - index).  Is
that correct?

>   mem_cgroup_uncharge_start();
>   for (i = 0; i < pagevec_count(); i++) {
>   struct page *page = pvec.pages[i];
>  
>   /* We rely upon deletion not changing page->index */
>   index = page->index;
> - if (index > end)
> + if (index >= end)

hm.  This change implies that the patch changed `end' from inclusive to
exclusive.  But the patch didn't do that.

>   break;
>  
>   if (!trylock_page(page))
> @@ -250,27 +247,51 @@ void truncate_inode_pages_range(struct address_space 
> *mapping,
>   index++;
>   }
>  
> - if (partial) {
> + if (partial_start) {
>   struct page *page = find_lock_page(mapping, start - 1);
>   if (page) {
> + unsigned int top = PAGE_CACHE_SIZE;
> + if (start > end) {

How can this be true?

> + top = partial_end;
> + partial_end = 0;
> + }
> + wait_on_page_writeback(page);
> + zero_user_segment(page, partial_start, top);
> +

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

Hello.

On 02-02-2013 0:56, Felipe Balbi wrote:

good point, do you wanna send some patches ?

I have already sent them countless times and even stuck CPPI 4.1 support (in
arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the
patch. :-(

sticking into arch/arm/common/ wasn't a nice move.

   Like with EDMA we have nothing else to do with CPPI 4.1 being shared by 
DaVinci-like and OMAP-like SOCs. Thank TI for creatring this mess. And 
actually even that is not a good place since I think I know of a MIPS SoC 
having CPPI 4.1 as well, just out of tree.

> But then again, so
> wasn't asking for the patch to be removed :-s

   Unfortunately, Russell has done it -- all that was discuseed without me in 
the loop even. :-/

I guess to make the MUSB side simpler we would need musb-dma-engine glue
to map dmaengine to the private MUSB API. Then we would have some
starting point to also move inventra (and anybody else) to dmaengine
API.

Why? Inventra is a dedicated device's private DMA controller, why make
universal DMA driver for it?

because it doesn't make sense to support multiple DMA APIs. We can check
from MUSB's registers if it was configured with Inventra DMA support and
based on that we can register MUSB's own DMA Engine to dmaengine API.

I still disagree. IMO drivers/dma/ is for standalone DMA engines. Else we 
could stick every bus mastering device's DMA engines there. CPPI 4.1 is in 
design standlone DMA engine, despite all in-tree implementations having it as 
subblock of MUSB and serving only MUSB.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [PREEMPT_RT] make pagefault_{disable,enable}() back into static inlines

2013-02-01 Thread Clark Williams

Thomas,

The PREEMPT_RT behavior of moving pagefault_disable() and
pagefault_enable() into mm/memory.c as EXPORT_SYMBOL_GPL symbols breaks
compilation of a third-party driver that builds fine on a stock kernel.
Yes, I know, I know, it's a binary driver, but my problem is that it
already compiles and works on a stock kernel; the compile breaks only
on a PREEMPT_RT kernel. The driver doesn't use the fault routines
directly but the symbols get pulled in due to references in
include/linux/io-memory.h.

One way to "fix" it would be to change the definitions to EXPORT_SYMBOL,
but what I wondered is if we should move them back into uaccess.h as
static inlines (like the upstream versions). I've done that in the
attached patch and it seems to work fine. What I'm not sure of are the
performance implications of calling migrate_{disable,enable} from a
static inline. 

Thoughts?

Signed-off-by: Clark Williams 
---
 include/linux/uaccess.h | 25 +++--
 mm/memory.c | 26 --
 2 files changed, 23 insertions(+), 28 deletions(-)

diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
index 44b3751..f2f6c08 100644
--- a/include/linux/uaccess.h
+++ b/include/linux/uaccess.h
@@ -4,6 +4,8 @@
 #include 
 #include 
 
+#include 
+
 /*
  * These routines enable/disable the pagefault handler in that
  * it will not take any MM locks and go straight to the fixup table.
@@ -33,8 +35,27 @@ static inline void pagefault_enable(void)
raw_pagefault_enable();
 }
 #else
-extern void pagefault_disable(void);
-extern void pagefault_enable(void);
+static inline void pagefault_disable(void)
+{
+   migrate_disable();
+   current->pagefault_disabled++;
+   /*
+* make sure to have issued the store before a pagefault
+* can hit.
+*/
+   barrier();
+}
+
+static inline void pagefault_enable(void)
+{
+   /*
+* make sure to issue those last loads/stores before enabling
+* the pagefault handler again.
+*/
+   barrier();
+   current->pagefault_disabled--;
+   migrate_enable();
+}
 #endif
 
 #ifndef ARCH_HAS_NOCACHE_UACCESS
diff --git a/mm/memory.c b/mm/memory.c
index 66f0ca8..6140eb8 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3484,32 +3484,6 @@ unlock:
return 0;
 }
 
-#ifdef CONFIG_PREEMPT_RT_FULL
-void pagefault_disable(void)
-{
-   migrate_disable();
-   current->pagefault_disabled++;
-   /*
-* make sure to have issued the store before a pagefault
-* can hit.
-*/
-   barrier();
-}
-EXPORT_SYMBOL_GPL(pagefault_disable);
-
-void pagefault_enable(void)
-{
-   /*
-* make sure to issue those last loads/stores before enabling
-* the pagefault handler again.
-*/
-   barrier();
-   current->pagefault_disabled--;
-   migrate_enable();
-}
-EXPORT_SYMBOL_GPL(pagefault_enable);
-#endif
-
 /*
  * By the time we get here, we already hold the mm semaphore
  */
-- 
1.7.11.7



signature.asc
Description: PGP signature

Re: [PATCH 1/2] acpiphp: create companion ACPI devices before creating PCI devices

On Wed, Jan 30, 2013 at 9:10 AM, Jiang Liu  wrote:
> From: Jiang Liu 
>
> With commit 4f535093cf8f6da8c "PCI: Put pci_dev in device tree as
> early as possible", companion ACPI devices should be created before
> creating correspoding PCI devices, otherwise it will break the ACPI
> PCI binding logic.
>
> Signed-off-by: Jiang Liu 
> ---
> Hi Bjorn,
> This patch set applies to your pci/yinghai-root-bus branch.
> There are still other potential bugs in the acpiphp driver under
> investigation. So I will send out these two first to catch up with
> the 3.9 merging window.
> Thanks!
> Gerry

I assume this fixes some sort of user-visible issue with acpiphp.
What failure does the user see?

> ---
>  drivers/pci/hotplug/acpiphp_glue.c |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/hotplug/acpiphp_glue.c 
> b/drivers/pci/hotplug/acpiphp_glue.c
> index bd784ff..acb7af2 100644
> --- a/drivers/pci/hotplug/acpiphp_glue.c
> +++ b/drivers/pci/hotplug/acpiphp_glue.c
> @@ -839,6 +839,9 @@ static int __ref enable_device(struct acpiphp_slot *slot)
> if (slot->flags & SLOT_ENABLED)
> goto err_exit;
>
> +   list_for_each_entry(func, >funcs, sibling)
> +   acpiphp_bus_add(func);
> +
> num = pci_scan_slot(bus, PCI_DEVFN(slot->device, 0));
> if (num == 0) {
> /* Maybe only part of funcs are added. */
> @@ -862,9 +865,6 @@ static int __ref enable_device(struct acpiphp_slot *slot)
> }
> }
>
> -   list_for_each_entry(func, >funcs, sibling)
> -   acpiphp_bus_add(func);
> -
> pci_bus_assign_resources(bus);
> acpiphp_sanitize_bus(bus);
> acpiphp_set_hpp_values(bus);
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [tpmdd-devel] [PATCH] TPM: Work around buggy TPMs that block during continue self test

2013-02-01 Thread Jason Gunthorpe

On Fri, Feb 01, 2013 at 04:38:42PM -0600, Kent Yoder wrote:

> >> > https://github.com/shpedoikal/linux.git tpmdd-01-22-13
> >>
> >> Thanks Kent, I will try to test your branch next week, if I am able.
> >>
> >> Can you also grab
> >>
> >> https://github.com/jgunthorpe/linux/commit/98b2a198b43b41b0535200bf475160786398f114
> >
> >  Thanks, I missed this, I'll start testing it.
> 
>   Ok, after yet another round of fixes to the stm i2c driver, I have a
> staging tree.  I'll submit this as-is next week unless something super
> ground-breaking comes up.

Great, I'll put this on my list..

I didn't receive your prior message, thank you for quoting it..

> >> https://github.com/jgunthorpe/linux/commit/9981e3e622bf702394982117134bed731ffd6f7e
> >
> >   This one is a bit out of date atm, for instance the __dev* stuff is
> > going away.  The thing that most makes me hesitant though is the config
> > if (X86 || OF).  A hardware platform or a firmware type..  What platform
> > should this actually target?

Right on the __dev stuff..

Well the 'depends on' buisness is only due to the unconditional
probing of TIS_MEM_BASE for a tpm, and then the autodetection of an
IRQ number. That procedure is very much X86 only.

My patch removes the unconditional probe when OF support is turned on,
so it is safe to use on any platform only when OF is enabled.

Yes it is really wonky, but unconditionally probing HW in a driver is
wonky these days too..

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] firewire: Fix ohci free_irq() warning

2013-02-01 Thread Mark Einon

On 1 February 2013 21:09, Peter Hurley  wrote:
> Hi Mark,
>
> I think what Alan means is that the suspend/resume code should just
> mask/unmask interrupts at the OHCI controller, via the OHCI
> IntEventClear/Set registers (naturally, saving the current mask and
> restoring it on resume).
>
> Of course, there's a lot more to do with an OHCI controller -- as you
> note. Like stopping running DMA contexts :)  And restarting them on
> resume.
>
> I'd do it, but I'm buried to my eyeballs in tty right now -- not fun. I
> can _eventually_ do this as I need to address problems with the FW643
> anyway at some point, but it's going to be a little while.

Hi Peter,

Ok, understood. I can certainly attempt a patch if I get time.

>
> In the meantime, I'm a little confused: you say you can't test this code
> because you have no hardware; but then how'd you trip this bug?

I can test the code in that I have a firewire port on my laptop, but
haven't got anything to plug into the port.
I assume that any large changes I make are quite capable of breaking
something there...

Cheers,

Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PCI: pciehp: drop ENTRY messages

On Thu, Jan 31, 2013 at 11:35 AM, Paul Bolle  wrote:
> In each suspend and resume cycle my laptop prints these messages at
> KERN_INFO level:
> pciehp :00:1c.1:pcie04: pciehp_suspend ENTRY
> pciehp :00:1c.0:pcie04: pciehp_suspend ENTRY
>
> and
> pciehp :00:1c.0:pcie04: pciehp_resume ENTRY
> pciehp :00:1c.1:pcie04: pciehp_resume ENTRY
>
> Drop these messages, that were probably used to debug the suspend and
> resume code, but now serve no purpose.
>
> Signed-off-by: Paul Bolle 

I applied this to pci/misc for v3.9.  Thanks!

Bjorn

> ---
> 0) v1 was called "PCI: pciehp: hide ENTRY messages behind ctrl_dbg()".
> But Bjorn and Rafael prefer to drop these messages completely.
>
> 1) Not even compile tested!
>
>  drivers/pci/hotplug/pciehp_core.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/pci/hotplug/pciehp_core.c 
> b/drivers/pci/hotplug/pciehp_core.c
> index 939bd1d..7d72c5e 100644
> --- a/drivers/pci/hotplug/pciehp_core.c
> +++ b/drivers/pci/hotplug/pciehp_core.c
> @@ -293,7 +293,6 @@ static void pciehp_remove(struct pcie_device *dev)
>  #ifdef CONFIG_PM
>  static int pciehp_suspend (struct pcie_device *dev)
>  {
> -   dev_info(>device, "%s ENTRY\n", __func__);
> return 0;
>  }
>
> @@ -303,7 +302,6 @@ static int pciehp_resume (struct pcie_device *dev)
> struct slot *slot;
> u8 status;
>
> -   dev_info(>device, "%s ENTRY\n", __func__);
> ctrl = get_service_data(dev);
>
> /* reinitialize the chipset's event detection logic */
> --
> 1.7.11.7
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] intel_irq_remapping: Clean up x2apic optout security warning mess

2013-02-01 Thread Andy Lutomirski

Current kernels print this on my Dell server:

   [ cut here ]
   WARNING: at drivers/iommu/intel_irq_remapping.c:542
   intel_enable_irq_remapping+0x7b/0x27e()
   Hardware name: PowerEdge R620
   Your BIOS is broken and requested that x2apic be disabled
   This will leave your machine vulnerable to irq-injection attacks
   Use 'intremap=no_x2apic_optout' to override BIOS request
   [...]
   Enabled IRQ remapping in xapic mode
   x2apic not enabled, IRQ remapping is in xapic mode

This is inconsistent with itself -- interrupt remapping is *on*.

Fix the mess by making the warnings say what they mean and my making
sure that compatibility format interrupts (the dangerous ones) are
disabled if x2apic is present regardless of BIOS settings.

With this patch applied, the output is:

  Your BIOS is broken and requested that x2apic be disabled.
  This will slightly decrease performance.
  Use 'intremap=no_x2apic_optout' to override BIOS request.
  Enabled IRQ remapping in xapic mode
  x2apic not enabled, IRQ remapping is in xapic mode

This should make us as or more secure than we are now and replace
a rather scary warning with a much less scary warning on silly
but functional systems.

Signed-off-by: Andy Lutomirski 
---
 drivers/iommu/intel_irq_remapping.c | 36 
 1 file changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/iommu/intel_irq_remapping.c 
b/drivers/iommu/intel_irq_remapping.c
index af8904d..eca8832 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -425,11 +425,22 @@ static void iommu_set_irq_remapping(struct intel_iommu 
*iommu, int mode)
 
/* Enable interrupt-remapping */
iommu->gcmd |= DMA_GCMD_IRE;
+   iommu->gcmd &= ~DMA_GCMD_CFI;  /* Block compatibility-format MSIs */
writel(iommu->gcmd, iommu->reg + DMAR_GCMD_REG);
 
IOMMU_WAIT_OP(iommu, DMAR_GSTS_REG,
  readl, (sts & DMA_GSTS_IRES), sts);
 
+   /*
+* With CFI clear in the Global Command register, we should be
+* protected from dangerous (i.e. compatibility) interrupts
+* regardless of x2apic status.  Check just to be sure.
+*/
+   if (sts & DMA_GSTS_CFIS)
+   WARN(1, KERN_WARNING
+   "Compatibility-format IRQs enabled despite intr 
remapping;\n"
+   "you are vulnerable to IRQ injection.\n");
+
raw_spin_unlock_irqrestore(>register_lock, flags);
 }
 
@@ -526,20 +537,24 @@ static int __init intel_irq_remapping_supported(void)
 static int __init intel_enable_irq_remapping(void)
 {
struct dmar_drhd_unit *drhd;
+   bool x2apic_present;
int setup = 0;
int eim = 0;
 
+   x2apic_present = x2apic_supported();
+
if (parse_ioapics_under_ir() != 1) {
printk(KERN_INFO "Not enable interrupt remapping\n");
-   return -1;
+   goto error;
}
 
-   if (x2apic_supported()) {
+   if (x2apic_present) {
eim = !dmar_x2apic_optout();
-   WARN(!eim, KERN_WARNING
-  "Your BIOS is broken and requested that x2apic be 
disabled\n"
-  "This will leave your machine vulnerable to 
irq-injection attacks\n"
-  "Use 'intremap=no_x2apic_optout' to override BIOS 
request\n");
+   if (!eim)
+   printk(KERN_WARNING
+   "Your BIOS is broken and requested that x2apic 
be disabled.\n"
+   "This will slightly decrease performance.\n"
+   "Use 'intremap=no_x2apic_optout' to override 
BIOS request.\n");
}
 
for_each_drhd_unit(drhd) {
@@ -578,7 +593,7 @@ static int __init intel_enable_irq_remapping(void)
if (eim && !ecap_eim_support(iommu->ecap)) {
printk(KERN_INFO "DRHD %Lx: EIM not supported by DRHD, "
   " ecap %Lx\n", drhd->reg_base_addr, iommu->ecap);
-   return -1;
+   goto error;
}
}
 
@@ -594,7 +609,7 @@ static int __init intel_enable_irq_remapping(void)
printk(KERN_ERR "DRHD %Lx: failed to enable queued, "
   " invalidation, ecap %Lx, ret %d\n",
   drhd->reg_base_addr, iommu->ecap, ret);
-   return -1;
+   goto error;
}
}
 
@@ -625,6 +640,11 @@ error:
/*
 * handle error condition gracefully here!
 */
+
+   if (x2apic_present)
+   WARN(1, KERN_WARNING
+   "Failed to enable irq remapping.  You are vulnerable to 
irq-injection attacks.\n");
+
return -1;
 }
 
-- 
1.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of

Re: [PATCH 2/7] clk: tegra: Use common of_clk_init() function

2013-02-01 Thread Mike Turquette

Quoting Prashant Gaikwad (2013-01-31 20:49:47)
> On Friday 25 January 2013 10:14 AM, Stephen Warren wrote:
> > On 01/24/2013 04:57 PM, Mike Turquette wrote:
> >> Quoting Stephen Warren (2013-01-24 11:32:37)
> >>> On 01/24/2013 11:20 AM, Mike Turquette wrote:
>  Quoting Prashant Gaikwad (2013-01-04 18:44:48)
> > On Friday 04 January 2013 10:00 PM, Stephen Warren wrote:
> >> On 01/04/2013 12:00 AM, Prashant Gaikwad wrote:
> >>> Use common of_clk_init() function for clocks initialization.
> >>>drivers/clk/tegra/clk-tegra20.c |3 ++-
> >>>drivers/clk/tegra/clk-tegra30.c |3 ++-
> >> Oh, so this series is written assuming that the Tegra CCF rework is
> >> already applied then? That makes the dependencies quite painful, since 
> >> I
> >> think we'll end up with the following order being needed:
> >>
> >> 1) clk: Add composite clock type
> >>  -> This would usually go through the clk tree.
> >> 2) The Tegra CCF rework series
> >>  -> This must go through the Tegra tree due to lots of dependencies
> >>  and merge conflicts with other Tegra patches.
> >> 3) This series
> >>  -> This would usually go through the clk tree.
> >>
> >> Is it possible to re-order the dependencies as (1) (3) (2), so that 
> >> Mike
> >> can apply (1) and (3) to the clock tree, then I can use the clk tree as
> >> the basis for a branch in the Tegra tree to apply (2) and all the other
> >> Tegra patches that will conflict with (2)?
> > If Mike approves the concept and implementation in (1) and (3) then I
> > will repost (2) and (3) with dependencies re-ordered.
>  Patch (1) still has some unaddressed comments, and is not a real
>  dependency for this series.
> >>> I assume "Patch (1)" refers to the list of series a couple emails above,
> >>> not the first patch in the series you're replying to; that threw me for
> >>> a moment.
> >>>
>  Since all of the patches have received their
>  Tested-by's then I propose to merge all patches from this series into
>  clk-next, which exception of patch 2/7 (the Tegra patch).
> 
>  This reduces your Tegra CCF conversion dependencies and you can role the
>  necessary of_clk_init change into your Tegra CCF conversion branch (it
>  has my implicit Ack and can be taken through your tree).
> 
>  Let me know if this is OK for you.
> >>> OK, I'm happy to merge your clock tree into the Tegra tree and then
> >>> apply 2/7 on top of the Tegra CCF work.
> >> Hmm, maybe the clk tree needs to be a dependency branch of arm-soc
> >> again, as it has in the past.  Would that help with any Tegra merge
> >> pain?
> > Yes, I think that's what would end up happening if I merge the clk tree
> > into the Tegra tree anyway.
> 
> Hi Mike,
> 
> Have you merged these patches for 3.9?

Yes, these have been sitting in clk-next for a few days now.

Regards,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [REVERT][v3.x.y] EHCI: Update qTD next pointer in QH overlay region during unlink

2013-02-01 Thread Joseph Salisbury

On 01/17/2013 01:56 PM, Alan Stern wrote:

On Thu, 17 Jan 2013, Joseph Salisbury wrote:

Hello,

Please consider reverting commit
3d037774b42ed677f699b1dce7d548d55f4e4c2b in mainline as well as in the
current stable releases. It was included upstream as of v3.6-rc6. This
commit introduced a regression, described in the following bug report:

http://bugs.launchpad.net/bugs/1088733

Reverting commit 3d037774b42ed677f699b1dce7d548d55f4e4c2b in the v3.2
kernel has been confirmed to resolve the aforementioned bug.

I do not want to revert this commit without first understanding what is
going wrong. Please ask the reporter to post usbmon traces showing
what happens in both a failed and a successful recording attempt.

Alan Stern

Hi Alan,

There is a tar file[0] attached to the bug report[1]. The tar file
contains a few examples of failed and successful recording attempts
while collecting usbmon traces. There is a readme.txt file available
after extracting the files.

The bug reporter states that only the first recording after boot fails.
Subsequent recordings succeed will succeed.

Thanks again for reviewing this, Alan. Just let me know if you would
like any additional data or testing.

Thanks,

Joe

[0]
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088733/+attachment/3510887/+files/usbmon-1088733.tar.gz

[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088733
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 0/8] introduce PCI bus notifier chain to get rid of the ACPI PCI subdriver interfaces

On Fri, Feb 1, 2013 at 9:13 AM, Jiang Liu  wrote:
> On 01/29/2013 10:04 AM, Jiang Liu wrote:
>> On 2013-1-29 8:34, Rafael J. Wysocki wrote:
>>> On Monday, January 28, 2013 01:56:33 PM Bjorn Helgaas wrote:
 On Fri, Jan 18, 2013 at 9:07 AM, Jiang Liu  wrote:
> This is an RFC patchset to address review comments in thread at:
> https://patchwork.kernel.org/patch/1946851/. The patch just pasts
> compilation. If no objection to the new implementation, I will
> go on to modify acpiphp driver and conduct tests.
>
> The main changes from V4 to V5 includes:
> 1) introduce a dedicated notifier chain for PCI buses
> 2) change pci_slot as built-in driver
> 3) unify the way to create/destroy PCI slots
> 4) introduce a kernel option to disable PCIe native hotplug
>
> TODO:
> 1) change acpiphp as built-in and unify the way to create/destroy ACPI
>based hotplug slots.
> 2) change other ACPI PCI subdriver in Yinghai's root bridge hotplug series
>to use the PCI bus notifier chain.
> 3) Remove the ACPI PCI subdriver interface eventaully.
>
> Jiang Liu (8):
>   PCI: make PCI device create/destroy logic symmetric
>   PCI: split registration of PCI bus devices into two stages
>   PCI: add a blocking notifier chain for PCI bus addition/removal
>   ACPI, PCI: avoid building pci_slot as module
>   PCI, ACPI: hook PCI bus notifications to create/destroy PCI slots
>   pci_slot: replace printk(KERN_xxx) with pr_xxx()
>   PCI/PCIe: add "pci=nopciehp" to disable PCIe native hotplug
>   PCI/PCIe: only claim PME from firmware when CONFIG_PCIE_PME is
> enabled
>
>  Documentation/kernel-parameters.txt |2 +
>  drivers/acpi/Kconfig|5 +-
>  drivers/acpi/internal.h |5 +
>  drivers/acpi/pci_root.c |8 +-
>  drivers/acpi/pci_slot.c |  217 
> ++-
>  drivers/acpi/scan.c |1 +
>  drivers/pci/bus.c   |   26 -
>  drivers/pci/pci.c   |2 +
>  drivers/pci/pci.h   |1 +
>  drivers/pci/pcie/portdrv_core.c |7 +-
>  drivers/pci/pcie/portdrv_pci.c  |3 +
>  drivers/pci/probe.c |7 +-
>  drivers/pci/remove.c|   15 +--
>  include/linux/pci.h |   21 
>  14 files changed, 142 insertions(+), 178 deletions(-)

 I think the problem we're trying to solve is that we don't initialize
 hot-added devices, correctly, e.g., we don't set up AER, we don't
 update acpi/pci_slot stuff, we probably don't set up PME etc.  We also
 have similar issues like IOMMU init on powerpc.

 Notifier chains seem like an unnecessarily complicated way to deal
 with this.  They're great for communicating between modules that stay
 at arm's length from each other.  But that's not the case here --
 everything is PCI and is quite closely coupled.  I think AER, PME,
 slot, etc., should  be initialized directly in pci_device_add() or
 somewhere nearby.
>>>
>>> I agree.
>>>
 This might sound a bit radical because it implies some fairly
 far-reaching changes.  It means this code can't be a module (the only
 one that can be built as a module today is pciehp, and I think
 everybody agrees that we should make it static as soon as we can
 figure out the acpiphp/pciehp issue).  I think it also means the
 pcieportdrv concept is of dubious value, since all the services should
 be known at build-time and we probably don't need a registration
 interface for them.
>>>
>>> It is of dubious value regardless.  It just adds complexity for no gain.
>>> Moreover, these things are in fact not mutually independent.
>>>
>>> I've had a lot of headaches trying to work around that when I was working
>>> on PME support and later on _OSC for root bridges.  Let's just take that
>>> stuff away once and for good. :-)
>> Hi Bjorn and Rafael,
>>   Thanks for advice. We will go this direction to change those modules
>> as built-in.
>> Regards!
>> Gerry
>>
> Hi Bjorn,
> I have done some investigation about how to implement this without
> using notifier chain. Due to commit "PCI: Put pci_dev in device tree as early
> as possible", a PCI device will be registered to the driver core before 
> creating
> the subordinate PCI bus. So we can't reply on the ACPI PCI device glue code
> to create/destroy PCI slots or acpiphp hotplug slots. So my current plan is
> to introduce two weak functions as below, is it acceptable?

That seems fine to me.  I think you wrote "pcibios_remove_bus(b)"
below in pci_create_root_bus() when you probably meant
"pcibios_add_bus(b)."  But I'm sure you would have found that soon :)

Anyway, I think a directly-called weak function will be much easier to
understand than a notifier-based

Re: [PATCH v1] block: partition: optimize memory allocation in check_partition

On Fri,  1 Feb 2013 20:23:12 +0800
Ming Lei  wrote:

> Currently, sizeof(struct parsed_partitions) may be 64KB in 32bit arch,
> so it is easy to trigger page allocation failure by check_partition,
> especially in hotplug block device situation(such as, USB mass storage,
> MMC card, ...), and Felipe Balbi has observed the failure.
> 
> This patch does below optimizations on the allocation of struct
> parsed_partitions to try to address the issue:
> 
> - make parsed_partitions.parts as pointer so that the pointed memory
> can fit in 32KB buffer, then approximate 32KB memory can be saved
> 
> - vmalloc the buffer pointed by parsed_partitions.parts because
> 32KB is still a bit big for kmalloc
> 
> - given that many devices have the partition count limit, so only
> allocate disk_max_parts() partitions instead of 256 partitions

This is only true when !(disk->flags & GENHD_FL_EXT_DEVT) in
disk_max_parts().  Which I suspect is basically "never".  Oh well.

> Cc: sta...@vger.kernel.org

I don't think I agree with the -stable backport.  The bug isn't
terribly serious and the patch is far more extensive than it really
needed to be.

If we do think the fix should be backported then it would be better to
do it as a series of two patches.  A nice simple one (say, a basic
s/kmalloc/vmalloc/) for 3.8 and -stable, then a more extensive
optimise-things patch for 3.9-rc1.

> Signed-off-by: Ming Lei 

A Reported-by:Felipe would be nice here.  We appreciate bug reports and
this little gesture is the least we can do.

>
> ...
>
>  struct parsed_partitions *
>  check_partition(struct gendisk *hd, struct block_device *bdev)
>  {
>   struct parsed_partitions *state;
>   int i, res, err;
>  
> - state = kzalloc(sizeof(struct parsed_partitions), GFP_KERNEL);
> + i = disk_max_parts(hd);
> + state = allocate_partitions(i);
>   if (!state)
>   return NULL;
> + state->limit = i;

I suggest this assignment be performed in allocate_partitions() itself.
That's better than requiring that all allocate_partitions() callers
remember to fill it in.

>   state->pp_buf = (char *)__get_free_page(GFP_KERNEL);
>   if (!state->pp_buf) {
> - kfree(state);
> + free_partitions(state);
>   return NULL;
>   }
>   state->pp_buf[0] = '\0';
>
> ...
>
> --- a/block/partitions/check.h
> +++ b/block/partitions/check.h
> @@ -15,13 +15,15 @@ struct parsed_partitions {
>   int flags;
>   bool has_info;
>   struct partition_meta_info info;
> - } parts[DISK_MAX_PARTS];
> + } *parts;
>   int next;
>   int limit;
>   bool access_beyond_eod;
>   char *pp_buf;
>  };

With this change, DISK_MAX_PARTS becomes a rather dangerous thing - do
we have code floating around which does

for (i = 0; i < DISK_MAX_PARTS; i++)
access(parsed_partitions.parts[i]);

?

If so, we should do s/DISK_MAX_PARTS/parsed_partitions.limit/.

The only such code I can find is in
block/partitions/mac.c:mac_partition().  And with your patch, this code
is potentially buggy, I suspect.  We could do
s/DISK_MAX_PARTS/state->limit/, but would that work?  What happens if
disk_max_parts() returned a value which is smaller than blocks_in_map?

It needs some thought.  I'm reluctant to apply this version of the
patch due to this.

>
> ...
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [tpmdd-devel] [PATCH] TPM: Work around buggy TPMs that block during continue self test

2013-02-01 Thread Kent Yoder

On Mon, Jan 28, 2013 at 8:11 AM, Kent Yoder  wrote:
> On Fri, Jan 25, 2013 at 01:25:38PM -0700, Jason Gunthorpe wrote:
>> On Tue, Jan 22, 2013 at 05:29:23PM -0600, Kent Yoder wrote:
>> > Hi Jason,
>> >
>> > On Wed, Nov 21, 2012 at 3:15 PM, Jason Gunthorpe
>> >  wrote:
>> > > We've been testing an alternative TPM for our embedded products and
>> > > found random kernel boot failures due to time outs after the continue
>> > > self test command.
>> > >
>> > > This was happening randomly, and has been *very* hard to track down, but 
>> > > it
>> > > looks like with this chip there is some kind of race with the 
>> > > tpm_tis_status()
>> > > check of TPM_STS_COMMAND_READY. If things get there 'too fast' then
>> > > it sees the chip is ready, or tpm_tis_ready() works. Otherwise it takes
>> > > somewhere over 400ms before the chip will return TPM_STS_COMMAND_READY.
>> > >
>> > > Adding some delay after tpm_continue_selftest() makes things reliably
>> > > hit the failure path, otherwise it is a crapshot.
>> >
>> >   I've staged this patch here, please test:
>> >
>> > https://github.com/shpedoikal/linux.git tpmdd-01-22-13
>>
>> Thanks Kent, I will try to test your branch next week, if I am able.
>>
>> Can you also grab
>>
>> https://github.com/jgunthorpe/linux/commit/98b2a198b43b41b0535200bf475160786398f114
>
>  Thanks, I missed this, I'll start testing it.

  Ok, after yet another round of fixes to the stm i2c driver, I have a
staging tree.  I'll submit this as-is next week unless something super
ground-breaking comes up.

https://github.com/shpedoikal/linux.git tpmdd-01-31-13

Thanks,
Kent

>> And did you have any comments on:
>>
>> https://github.com/jgunthorpe/linux/commit/9981e3e622bf702394982117134bed731ffd6f7e
>
>   This one is a bit out of date atm, for instance the __dev* stuff is
> going away.  The thing that most makes me hesitant though is the config
> if (X86 || OF).  A hardware platform or a firmware type..  What platform
> should this actually target?
>
> Kent
>
>> Both were posted to the list a bit ago.
>>
>> Regards,
>> --
>> Jason Gunthorpe (780)4406067x832
>> Chief Technology Officer, Obsidian Research Corp Edmonton, Canada
>>
>> --
>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>> MVPs and experts. ON SALE this month only -- learn more at:
>> http://p.sf.net/sfu/learnnow-d2d
>> ___
>> tpmdd-devel mailing list
>> tpmdd-de...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RFC v2] media: tvp514x: add OF support

2013-02-01 Thread Sylwester Nawrocki


Hi Prabhakar,

On 01/29/2013 02:07 PM, Prabhakar Lad wrote:
[...]

diff --git a/Documentation/devicetree/bindings/media/i2c/tvp514x.txt 
b/Documentation/devicetree/bindings/media/i2c/tvp514x.txt
new file mode 100644
index 000..55d3ffd
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tvp514x.txt
@@ -0,0 +1,38 @@
+* Texas Instruments TVP514x video decoder
+
+The TVP5146/TVP5146m2/TVP5147/TVP5147m1 device is high quality, single-chip
+digital video decoder that digitizes and decodes all popular baseband analog
+video formats into digital video component. The tvp514x decoder supports 
analog-
+to-digital (A/D) conversion of component RGB and YPbPr signals as well as A/D
+conversion and decoding of NTSC, PAL and SECAM composite and S-video into
+component YCbCr.
+
+Required Properties :
+- compatible: Must be "ti,tvp514x-decoder"


There are no significant differences among TVP514* devices as listed above,
you would like to handle above ?

I'm just wondering if you don't need ,for instance, two separate compatible
properties, e.g. "ti,tvp5146-decoder" and "ti,tvp5147-decoder" ?


+- hsync-active: HSYNC Polarity configuration for current interface.
+- vsync-active: VSYNC Polarity configuration for current interface.
+- data-active: Clock polarity of the current interface.


I guess you mean "pclk-sample: Clock polarity..." ?


+
+Example:
+
+i2c0@1c22000 {
+   ...
+   ...
+
+   tvp514x@5c {
+   compatible = "ti,tvp514x-decoder";
+   reg =<0x5c>;
+
+   port {
+   tvp514x_1: endpoint {
+   /* Active high (Defaults to 0) */
+   hsync-active =<1>;
+   /* Active high (Defaults to 0) */
+   hsync-active =<1>;


Should it be vsync-active ?


+   /* Active low (Defaults to 0) */
+   data-active =<0>;


and this pclk-sample ?


+   };
+   };
+   };
+   ...
+};
diff --git a/drivers/media/i2c/tvp514x.c b/drivers/media/i2c/tvp514x.c
index a4f0a70..24ce759 100644
--- a/drivers/media/i2c/tvp514x.c
+++ b/drivers/media/i2c/tvp514x.c
@@ -12,6 +12,7 @@
   * Hardik Shah
   * Manjunath Hadli
   * Karicheri Muralidharan
+ * Prabhakar Lad
   *
   * This package is free software; you can redistribute it and/or modify
   * it under the terms of the GNU General Public License version 2 as
@@ -33,7 +34,9 @@
  #include
  #include
  #include
+#include

+#include
  #include
  #include
  #include
@@ -930,6 +933,58 @@ static struct tvp514x_decoder tvp514x_dev = {

  };

+#if defined(CONFIG_OF)
+static const struct of_device_id tvp514x_of_match[] = {
+   {.compatible = "ti,tvp514x-decoder", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, tvp514x_of_match);
+
+static struct tvp514x_platform_data
+   *tvp514x_get_pdata(struct i2c_client *client)
+{
+   if (!client->dev.platform_data&&  client->dev.of_node) {
+   struct tvp514x_platform_data *pdata;
+   struct v4l2_of_endpoint bus_cfg;
+   struct device_node *endpoint;
+
+   pdata = devm_kzalloc(>dev,
+   sizeof(struct tvp514x_platform_data),
+   GFP_KERNEL);
+   client->dev.platform_data = pdata;


Do you really need to set client->dev.platform_data this way ?
What about passing struct tvp514x_decoder pointer to this function
and initializing struct tvp514x_decoder::pdata instead ?


+   if (!pdata)
+   return NULL;
+
+   endpoint = of_get_child_by_name(client->dev.of_node, "port");
+   if (endpoint)
+   endpoint = of_get_child_by_name(endpoint, "endpoint");


I think you could replace these two calls above with

endpoint = v4l2_of_get_next_endpoint(client->dev.of_node);

Now I see I should have modified this function to ensure it works also when
'port' nodes are grouped in a 'ports' node.


+   if (!endpoint) {
+   v4l2_info(client, "Using default data!!\n");
+   } else {
+   v4l2_of_parse_parallel_bus(endpoint,_cfg);
+
+   if (bus_cfg.mbus_flags&  V4L2_MBUS_HSYNC_ACTIVE_HIGH)
+   pdata->hs_polarity = 1;
+   if (bus_cfg.mbus_flags&  V4L2_MBUS_VSYNC_ACTIVE_HIGH)
+   pdata->vs_polarity = 1;
+   if (bus_cfg.mbus_flags&  V4L2_MBUS_PCLK_SAMPLE_RISING)
+   pdata->clk_polarity = 1;
+   }
+   }
+
+   return client->dev.platform_data;
+}
+#else
+#define tvp514x_of_match NULL
+
+static struct tvp514x_platform_data
+   *tvp514x_get_pdata(struct i2c_client *client)
+{
+   return client->dev.platform_data;
+}
+#endif
+
  /**
   * tvp514x_probe() -

[PATCH 2/4] Platform: x86: chromeos_laptop - Add Acer C7 trackpad

Add support for the Acer C7's trackpad, which is a reuse
of the Samsung Series 5 550 trackpad.

Signed-off-by: Benson Leung 
---
 drivers/platform/x86/chromeos_laptop.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/platform/x86/chromeos_laptop.c 
b/drivers/platform/x86/chromeos_laptop.c
index 6440d22..9293c66 100644
--- a/drivers/platform/x86/chromeos_laptop.c
+++ b/drivers/platform/x86/chromeos_laptop.c
@@ -176,6 +176,13 @@ static struct dmi_system_id __initdata 
chromeos_laptop_dmi_table[] = {
},
.callback = setup_isl29018_als,
},
+   {
+   .ident = "Acer C7 Chromebook - Touchpad",
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "Parrot"),
+   },
+   .callback = setup_cyapa_smbus_tp,
+   },
{ }
 };
 MODULE_DEVICE_TABLE(dmi, chromeos_laptop_dmi_table);
-- 
1.8.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 4/4] Platform: x86: chromeos_laptop - Add Taos tsl2583 device

The Samsung Series 5 Chromebook is equipped with  a Taos tsl2583
light sensor. Instatiate it here.

Signed-off-by: Benson Leung 
---
 drivers/platform/x86/chromeos_laptop.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/platform/x86/chromeos_laptop.c 
b/drivers/platform/x86/chromeos_laptop.c
index 188b7da..95bf94f 100644
--- a/drivers/platform/x86/chromeos_laptop.c
+++ b/drivers/platform/x86/chromeos_laptop.c
@@ -50,6 +50,10 @@ static struct i2c_board_info __initdata isl_als_device = {
I2C_BOARD_INFO("isl29018", ISL_ALS_I2C_ADDR),
 };
 
+static struct i2c_board_info __initdata tsl2583_als_device = {
+   I2C_BOARD_INFO("tsl2583", TAOS_ALS_I2C_ADDR),
+};
+
 static struct i2c_board_info __initdata tsl2563_als_device = {
I2C_BOARD_INFO("tsl2563", TAOS_ALS_I2C_ADDR),
 };
@@ -164,6 +168,13 @@ static int __init setup_isl29018_als(const struct 
dmi_system_id *id)
return 0;
 }
 
+static int __init setup_tsl2583_als(const struct dmi_system_id *id)
+{
+   /* add tsl2583 light sensor on smbus */
+   als = add_smbus_device(NULL, _als_device);
+   return 0;
+}
+
 static int __init setup_tsl2563_als(const struct dmi_system_id *id)
 {
/* add tsl2563 light sensor on smbus */
@@ -196,6 +207,13 @@ static struct dmi_system_id __initdata 
chromeos_laptop_dmi_table[] = {
.callback = setup_cyapa_smbus_tp,
},
{
+   .ident = "Samsung Series 5 - Light Sensor",
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "Alex"),
+   },
+   .callback = setup_tsl2583_als,
+   },
+   {
.ident = "Cr-48 - Light Sensor",
.matches = {
DMI_MATCH(DMI_PRODUCT_NAME, "Mario"),
-- 
1.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/4] Platform: x86: chromeos_laptop - Rename setup_lumpy_tp to setup_cyapa_smbus_tp

The Cypress trackpad on smbus is used on other systems
as well. Lets make the name more generic.

Signed-off-by: Benson Leung 
---
 drivers/platform/x86/chromeos_laptop.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/chromeos_laptop.c 
b/drivers/platform/x86/chromeos_laptop.c
index a8329c3..6440d22 100644
--- a/drivers/platform/x86/chromeos_laptop.c
+++ b/drivers/platform/x86/chromeos_laptop.c
@@ -145,7 +145,7 @@ static struct i2c_client __init *add_smbus_device(const 
char *name,
   addr_list);
 }
 
-static int __init setup_lumpy_tp(const struct dmi_system_id *id)
+static int __init setup_cyapa_smbus_tp(const struct dmi_system_id *id)
 {
/* add cyapa touchpad on smbus */
tp = add_smbus_device("trackpad", _device);
@@ -166,7 +166,7 @@ static struct dmi_system_id __initdata 
chromeos_laptop_dmi_table[] = {
DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG"),
DMI_MATCH(DMI_PRODUCT_NAME, "Lumpy"),
},
-   .callback = setup_lumpy_tp,
+   .callback = setup_cyapa_smbus_tp,
},
{
.ident = "Samsung Series 5 550 - Light Sensor",
-- 
1.8.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 3/4] Platform: x86: chromeos_laptop - Add Taos tsl2563 device

Two legacy Chromebooks, the Cr-48, and the Acer AC700,
are equipped with a Taos tsl2563 light sensor.
This will instantiate the sensor on those laptops.

Signed-off-by: Benson Leung 
---
 drivers/platform/x86/chromeos_laptop.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/platform/x86/chromeos_laptop.c 
b/drivers/platform/x86/chromeos_laptop.c
index 9293c66..188b7da 100644
--- a/drivers/platform/x86/chromeos_laptop.c
+++ b/drivers/platform/x86/chromeos_laptop.c
@@ -27,6 +27,7 @@
 
 #define CYAPA_TP_I2C_ADDR  0x67
 #define ISL_ALS_I2C_ADDR   0x44
+#define TAOS_ALS_I2C_ADDR  0x29
 
 static struct i2c_client *als;
 static struct i2c_client *tp;
@@ -49,6 +50,10 @@ static struct i2c_board_info __initdata isl_als_device = {
I2C_BOARD_INFO("isl29018", ISL_ALS_I2C_ADDR),
 };
 
+static struct i2c_board_info __initdata tsl2563_als_device = {
+   I2C_BOARD_INFO("tsl2563", TAOS_ALS_I2C_ADDR),
+};
+
 static struct i2c_client __init *__add_probed_i2c_device(
const char *name,
int bus,
@@ -159,6 +164,13 @@ static int __init setup_isl29018_als(const struct 
dmi_system_id *id)
return 0;
 }
 
+static int __init setup_tsl2563_als(const struct dmi_system_id *id)
+{
+   /* add tsl2563 light sensor on smbus */
+   als = add_smbus_device(NULL, _als_device);
+   return 0;
+}
+
 static struct dmi_system_id __initdata chromeos_laptop_dmi_table[] = {
{
.ident = "Samsung Series 5 550 - Touchpad",
@@ -183,6 +195,20 @@ static struct dmi_system_id __initdata 
chromeos_laptop_dmi_table[] = {
},
.callback = setup_cyapa_smbus_tp,
},
+   {
+   .ident = "Cr-48 - Light Sensor",
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "Mario"),
+   },
+   .callback = setup_tsl2563_als,
+   },
+   {
+   .ident = "Acer AC700 - Light Sensor",
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "ZGB"),
+   },
+   .callback = setup_tsl2563_als,
+   },
{ }
 };
 MODULE_DEVICE_TABLE(dmi, chromeos_laptop_dmi_table);
-- 
1.8.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 0/4] Platform: x86: chromeos_laptop - Add more x86 Chromebooks

This patch series will add support for the following devices on
the following laptops:

Acer C7 Chromebook - Cypress APA Smbus Trackpad
Acer AC700 - Taos tsl2563 light sensor
Samsung Series 5 Chromebook - Taos tsl2583 light sensor
Cr-48 - Taos tsl2563 light sensor

Cheers,
Benson

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tile: revert pr_info to printk in

2013-02-01 Thread Joe Perches

On Fri, 2013-02-01 at 12:34 -0500, Chris Metcalf wrote:
> Using pr_info in a header exposes us to potential trouble from
> subsystems that define pr_fmt.  This change fixes:
>
>   In file included from include/linux/scatterlist.h:10,
>from include/scsi/scsi.h:12,
>from drivers/infiniband/ulp/srp/ib_srp.c:46:
>   arch/tile/include/asm/io.h: In function ‘ioport_map’:
>   arch/tile/include/asm/io.h:296: error: expected ‘)’ before ‘PFX’

Interesting.

> diff --git a/arch/tile/include/asm/io.h b/arch/tile/include/asm/io.h
[]
> @@ -292,7 +292,7 @@ static inline long ioport_panic(void)
>  
>  static inline void __iomem *ioport_map(unsigned long port, unsigned int len)
>  {
> - pr_info("ioport_map: mapping IO resources is unsupported on tile.\n");
> + printk("ioport_map: mapping IO resources is unsupported on tile.\n");

It'd be nicer to add an appropriate KERN_ here.

My preference would be to change ib_srp.c (and ib_srpt) like:
---
 drivers/infiniband/ulp/srp/ib_srp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/ulp/srp/ib_srp.c 
b/drivers/infiniband/ulp/srp/ib_srp.c
index d5088ce..59bf409 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -30,7 +30,7 @@
  * SOFTWARE.
  */
 
-#define pr_fmt(fmt) PFX fmt
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include 
 #include 



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] PCI: ASPM exit link state code could skip devices

On Fri, Feb 1, 2013 at 12:55 PM, Joe Lawrence  wrote:
> On Thu, 31 Jan 2013, Myron Stowe wrote:

>> PCI: ASPM exit link state code is skipping devices
>>
>> From: Myron Stowe 
>>
>> On PCI bus hotplug removal, 'pcie_aspm_exit_link_state' can potentially
>> skip parent devices that have link_state allocated.  Instead of exiting
>> early if a given device in not PCIe, check whether or not the device's
>> parent has link_state allocated.  This enables 'pcie_aspm_exit_link_state'
>> to properly clean up parent link_state when the last function in a slot
>> might not be PCIe.
>>
>> Reported-by: Joe Lawrence 
>> Signed-off-by: Myron Stowe 
>> ---
>>
>>  drivers/pci/pcie/aspm.c |5 +
>>  1 files changed, 1 insertions(+), 4 deletions(-)
>>
>>
>> diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
>> index 8474b6a..aa52727 100644
>> --- a/drivers/pci/pcie/aspm.c
>> +++ b/drivers/pci/pcie/aspm.c
>> @@ -634,10 +634,7 @@ void pcie_aspm_exit_link_state(struct pci_dev *pdev)
>>   struct pci_dev *parent = pdev->bus->self;
>>   struct pcie_link_state *link, *root, *parent_link;
>>
>> - if (!pci_is_pcie(pdev) || !parent || !parent->link_state)
>> - return;
>> - if ((pci_pcie_type(parent) != PCI_EXP_TYPE_ROOT_PORT) &&
>> - (pci_pcie_type(parent) != PCI_EXP_TYPE_DOWNSTREAM))
>> + if (!parent || !parent->link_state)
>>   return;
>>
>>   down_read(_bus_sem);
>>
>>
>>
>
> Hi Myron,
>
> The patch tests eliminates the reported crash when hotplugging our
> problem PCI bus.
>
> The additional checks removed from pcie_aspm_exit_link_state (ie, the
> simplification) do appear to be unnecessary as pcie_aspm_init_link_state
> is already preventing such devices from allocating link state.

I added a Tested-by for you, Joe, and applied this to my pci/joe-aspm
branch for v3.9.  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: [RFC][PATCH v8 2/3] trace,x86: add x86 irq vector tracepoints

2013-02-01 Thread Seiji Aguchi

> 
> Also, don't forget to add the mutex protection that I suggested in another 
> email.

Will do. 
Thanks,

Seiji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpufreq: governors: Remove code redundancy between governors

On Friday, February 01, 2013 08:08:42 AM Viresh Kumar wrote:
> On 1 February 2013 08:01, Viresh Kumar  wrote:
> > Really!! I see bleeding edge as df0e3f4 and i don't see the $(subject) patch
> > in it :)
> 
> Well it might have been dropped by Rafael due to build error,

Precisely.

> which would be fixed by:
> 
> diff --git a/drivers/cpufreq/cpufreq_governor.c
> b/drivers/cpufreq/cpufreq_governor.c
> index dc99472..7aaa9b1 100644
> --- a/drivers/cpufreq/cpufreq_governor.c
> +++ b/drivers/cpufreq/cpufreq_governor.c
> @@ -194,6 +194,7 @@ bool need_load_eval(struct cpu_dbs_common_info *cdbs,
> 
> return true;
>  }
> +EXPORT_SYMBOL_GPL(need_load_eval);
> 
>  int cpufreq_governor_dbs(struct dbs_data *dbs_data,
> struct cpufreq_policy *policy, unsigned int event)
> 
> 
> Original patch attached with this change.

OK, thanks!

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND PATCH 1/4] ACPI/PM: Fix acpi_bus_get_device() check in drivers/acpi/device_pm.c

On Friday, February 01, 2013 08:43:09 AM Yasuaki Ishimatsu wrote:
> Hi Rafael,
> 
> 2013/02/01 5:21, Rafael J. Wysocki wrote:
> > On Thursday, January 31, 2013 12:22:14 PM Yasuaki Ishimatsu wrote:
> >> I fogot to change subject. So I resend a patch.
> >
> > I have applied patches [1-3/4] to my bleeding-edge branch,
> 
> Thanks.
> 
> > but please note that
> > something (probably your MUA) added a space in front of every line 
> > originally
> > starting with a space.
> 
> I apologize for bothering you.

No problem.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] intel_idle: stop using driver_data for static flags

2013-02-01 Thread Daniel Lezcano

On 02/01/2013 07:40 PM, Len Brown wrote:
> On 02/01/2013 03:44 AM, Daniel Lezcano wrote:
>> On 02/01/2013 05:11 AM, Len Brown wrote:
>>> From: Len Brown 
>>>
>>> The commit, 4202735e8ab6ecfb0381631a0d0b58fefe0bd4e2
>>> (cpuidle: Split cpuidle_state structure and move per-cpu statistics fields)
>>> observed that the MWAIT flags for Cn on every processor to date were the
>>> same, and created get_driver_data() to supply them.
>>>
>>> Unfortunately, that assumption is false, going forward.
>>> So here we restore the MWAIT flags to the cpuidle_state table.
>>> However, instead restoring the old "driver_data" field,
>>> we put the flags into the existing "flags" field,
>>> where they probalby should have lived all along.
>>
>> Removing the driver_data is a good thing but I am not sure it is the
>> case by moving the MWAIT flags to the cpuidle_state's flags field. We
>> are mixing arch specific flags with a generic code.
>>
>> This is prone to errors because new flags could appear for the cpuidle
>> core code and could collide with the arch specific flags.
>>
>> Wouldn't make sense to add a private field in the struct cpuidle_state
>> structure to let the driver/arch specific to store whatever is needed ?
>>
>> struct cpuidle_state {
>>
>>  ...
>>  unsigned long private;
>>  ...
>>
>> }
> 
> The top half of the flags are reserved for the driver,
> as noted by the definition of CPUIDLE_DRIVER_FLAGS_MASK
> with the generic flag definitions:
> 
> #define CPUIDLE_FLAG_TIME_VALID (0x01) /* is residency time measurable? */
> #define CPUIDLE_FLAG_COUPLED(0x02) /* state applies to multiple cpus */
> 
> #define CPUIDLE_DRIVER_FLAGS_MASK (0x)
> 
> intel_idle already uses a driver-specific flag:
> 
> #define CPUIDLE_FLAG_TLB_FLUSHED0x1
> 
> This patch just uses 4 more bits along with that one.

Ok. In this case it would make sense to move this flag out of the
generic core code to the intel_idle.c file ? and move the [dec/en]coding
macro flags_2_MWAIT_EAX and MWAIT_EAX_2_flags (with a more appropriate
name for a generic code) to the cpuidle.h file ?

  -- Daniel



> Sure, if we run out of space, we can add an additional field.
> But I don't see an immediate need for it.
> 
> thanks,
> Len Brown
> Intel Open Source Technology Center
> 


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v8 2/3] trace,x86: add x86 irq vector tracepoints

2013-02-01 Thread Steven Rostedt

On Fri, 2013-02-01 at 21:06 +, Seiji Aguchi wrote:
> > > +#include 
> > > +#include 
> > > +
> > > +static struct desc_ptr trace_idt_descr = { NR_VECTORS * 16 - 1,
> > > + (unsigned long) trace_idt_table };
> > > +
> > > +#ifndef CONFIG_X86_64
> > > +gate_desc trace_idt_table[NR_VECTORS] __page_aligned_data
> > > + = { { { { 0, 0 } } }, };
> > > +#endif
> > > +
> > > +static struct desc_ptr orig_idt_descr[NR_CPUS];
> > 
> > BTW, this should be:
> > 
> > static DEFINE_PER_CPU(struct desc_ptr, orig_idt_descr);
> > 
> > And look at the patch I made about the NMI/DEBUG trap handling to see how 
> > to use it.
> 
> Thanks.
> I'm looking at your patch right now and will update my patch.

Also, don't forget to add the mutex protection that I suggested in
another email.

Thanks,

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v2 01/12] Add sys_hotplug.h for system device hotplug framework

On Friday, February 01, 2013 01:40:10 PM Toshi Kani wrote:
> On Fri, 2013-02-01 at 07:30 +, Greg KH wrote:
> > On Thu, Jan 31, 2013 at 06:32:18PM -0700, Toshi Kani wrote:
> >  > This is already done for PCI host bridges and platform devices and I 
> > don't
> > > > see why we can't do that for the other types of devices too.
> > > > 
> > > > The only missing piece I see is a way to handle the "eject" problem, 
> > > > i.e.
> > > > when we try do eject a device at the top of a subtree and need to tear 
> > > > down
> > > > the entire subtree below it, but if that's going to lead to a system 
> > > > crash,
> > > > for example, we want to cancel the eject.  It seems to me that we'll 
> > > > need some
> > > > help from the driver core here.
> > > 
> > > There are three different approaches suggested for system device
> > > hot-plug:
> > >  A. Proceed within system device bus scan.
> > >  B. Proceed within ACPI bus scan.
> > >  C. Proceed with a sequence (as a mini-boot).
> > > 
> > > Option A uses system devices as tokens, option B uses acpi devices as
> > > tokens, and option C uses resource tables as tokens, for their handlers.
> > > 
> > > Here is summary of key questions & answers so far.  I hope this
> > > clarifies why I am suggesting option 3.
> > > 
> > > 1. What are the system devices?
> > > System devices provide system-wide core computing resources, which are
> > > essential to compose a computer system.  System devices are not
> > > connected to any particular standard buses.
> > 
> > Not a problem, lots of devices are not connected to any "particular
> > standard busses".  All this means is that system devices are connected
> > to the "system" bus, nothing more.
> 
> Can you give me a few examples of other devices that support hotplug and
> are not connected to any particular buses?  I will investigate them to
> see how they are managed to support hotplug.
> 
> > > 2. Why are the system devices special?
> > > The system devices are initialized during early boot-time, by multiple
> > > subsystems, from the boot-up sequence, in pre-defined order.  They
> > > provide low-level services to enable other subsystems to come up.
> > 
> > Sorry, no, that doesn't mean they are special, nothing here is unique
> > for the point of view of the driver model from any other device or bus.
> 
> I think system devices are unique in a sense that they are initialized
> before drivers run.
> 
> > > 3. Why can't initialize the system devices from the driver structure at
> > > boot?
> > > The driver structure is initialized at the end of the boot sequence and
> > > requires the low-level services from the system devices initialized
> > > beforehand.
> > 
> > Wait, what "driver structure"?  
> 
> Sorry it was not clear.  cpu_dev_init() and memory_dev_init() are called
> from driver_init() at the end of the boot sequence, and initialize
> system/cpu and system/memory devices.  I assume they are the system bus
> you are referring with option A.
> 
> > If you need to initialize the driver
> > core earlier, then do so.  Or, even better, just wait until enough of
> > the system has come up and then go initialize all of the devices you
> > have found so far as part of your boot process.
> 
> They are pseudo drivers that provide sysfs entry points of cpu and
> memory.  They do not actually initialize cpu and memory.  I do not think
> initializing cpu and memory fits into the driver model either, since
> drivers should run after cpu and memory are initialized.
> 
> > None of the above things you have stated seem to have anything to do
> > with your proposed patch, so I don't understand why you have mentioned
> > them...
> 
> You suggested option A before, which uses system bus scan to initialize
> all system devices at boot time as well as hot-plug.  I tried to say
> that this option would not be doable.
> 
> > > 4. Why do we need a new common framework?
> > > Sysfs CPU and memory on-lining/off-lining are performed within the CPU
> > > and memory modules.  They are common code and do not depend on ACPI.
> > > Therefore, a new common framework is necessary to integrate both
> > > on-lining/off-lining operation and hot-plugging operation of system
> > > devices into a single framework.
> > 
> > {sigh}
> > 
> > Removing and adding devices and handling hotplug operations is what the
> > driver core was written for, almost 10 years ago.  To somehow think that
> > your devices are "special" just because they don't use ACPI is odd,
> > because the driver core itself has nothing to do with ACPI.  Don't get
> > the current mix of x86 system code tied into ACPI confused with an
> > driver core issues here please.
> 
> CPU online/offline operation is performed within the CPU module.  Memory
> online/offline operation is performed within the memory module.  CPU and
> memory hotplug operations are performed within ACPI.  While they deal
> with the same set of devices, they operate independently and are not
> managed under a same

Re: [PATCH] leds-ot200: Fix error caused by shifted mask

On Fri, 1 Feb 2013 16:08:15 +0100
Christian Gmeiner  wrote:

> ping

Bryan is handling LEDs patches (see ./MAINTAINERS).  Without a cc he
presumably missed this in the lkml flood.

> 2013/1/23 GMEINER.Christian :
> >> -Urspr__ngliche Nachricht-
> >> Von: Christian Gmeiner [mailto:christian.gmei...@gmail.com]
> >> Gesendet: Mittwoch, 23. Januar 2013 09:11
> >> An: linux-n...@vger.kernel.org; a...@linux-foundation.org;
> >> rpur...@rpsys.net; linux-kernel@vger.kernel.org; GMEINER.Christian
> >> Cc: Christian Gmeiner
> >> Betreff: [PATCH] leds-ot200: Fix error caused by shifted mask
> >>
> >> During the development of this driver an in-house register documentation
> >> was used. The last weeks some integration tests were done and this problem
> >> was found. It turned out that the released register documentation is wrong.
> >>
> >> The fix is very simple: shift all masks by one.
> >>

The changelog failed to describe the effects of the bug it fixes.  This
is a grave (and all too common) omission; it makes it difficult for
others to determine whether the patch should be backported into earlier
kernels.

So, please tell us.  And feel free to explain whether you believe the
fix should be backported.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] SubmittingPatches: add penalty for forcing a maintainer to edit a patch

2013-02-01 Thread Randy Dunlap

On 02/01/13 13:07, Anca Emanuel wrote:
> Joe, read lkml and decide after that.
> I fully apove the pathch.
> 
> Reviewed-by: Anca Emanuel 
> 
> Review-requested-by: Joe Perches 
> 
> 
> Comments:
> You have 3 kernels to maintain as stable, plus drivers, plus etc.
> If somebody post something without reading the docs, and you have to
> repeat to them the same, again and more, then you MUST give an beer.

If someone is a repeat-repeat offender, they should just learn
how to submit patches correctly.  I.e., the maintainer should just
keep saying to them, Sorry, please submit your patch correctly
so that I can apply it.


> On Fri, Feb 1, 2013 at 5:48 PM, Joe Perches  wrote:
>> On Fri, 2013-02-01 at 16:43 +0100, Greg Kroah-Hartman wrote:
>>> From: Greg Kroah-Hartman 
>>>
>>> Maintainers have to hand-edit patches (body of patches and changelog
>>> entries) all the time.  There needs to be some kind of penalty put into
>>> place to keep developers from abusing maintainers.
>>
>> No, there doesn't.
>>
>> It's funny as a joke, it's not as an actual patch.


-- 
~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/

[PATCH] stmmac: don't return zero on failure path in stmmac_pci_probe()

2013-02-01 Thread Alexey Khoroshilov

If stmmac_dvr_probe() fails in stmmac_pci_probe(), it breaks off initialization,
deallocates all resources, but returns zero.
The patch adds -ENODEV as return value in this case.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 064eaac..19b3a25 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -102,6 +102,7 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
priv = stmmac_dvr_probe(&(pdev->dev), _dat, addr);
if (!priv) {
pr_err("%s: main driver probe failed", __func__);
+   ret = -ENODEV;
goto err_out;
}
priv->dev->irq = pdev->irq;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework