Re: [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm

[Christoph Hellwig]

On Mon, Jan 23, 2017 at 09:14:04AM -0800, Dan Williams wrote:
> The use case that we have now is distinguishing volatile vs persistent
> memory (brd vs pmem).

brd is a development tool, so until we have other reasons for this
abstraction (which I'm pretty sure will show up rather sooner than later)
I would not worry about it too much.

> I took a look at mtd layering approach and the main difference is that
> layers above the block layer do not appear to know anything about mtd
> specifics.

Or the block layer itself for that matter.  And that's exactly where
I want DAX to be in the future.

> For fs/dax.c we currently need some path to retrieve a dax
> anchor object through the block device.

We have a need to retreiver the anchor object.  We currently do it
though the block layer for historical reasons, but it doesn't have
to be that way.

> > In the longer run I like your dax_operations, but they need to be
> > separate from the block layer.
> 
> I'll move them from block_device_operations to dax data hanging off of
> the bdev_inode, or is there a better way to go from bdev-to-dax?

I don't think that's any better.  What we really want is a way
to find the underlying persistent memory / DAX / whatever we call
it node without going through a block device.  E.g. a library function
to give that object for a given path name, where the path name could
be either that of the /dev/pmemN or the /dev/daxN device.

If the file system for now still needs a block device as well it
will only accept the /dev/pmemN name, and open both the low-level
pmem device and the block device.  Once that file system doesn't
need block code (and I think we could do that easily for XFS,
nevermind any new FS) it won't have to deal with the block
device at all.

pmem.c then becomes a consumer of the dax_ops just like the file system.

Re: [PATCH] block: Initialize cfqq->ioprio_class in cfq_get_queue()

[Jens Axboe]

On 01/23/2017 09:17 AM, Alexander Potapenko wrote:
> On Mon, Jan 23, 2017 at 5:03 PM, Andrey Ryabinin  
> wrote:
>> 2017-01-23 17:06 GMT+03:00 Alexander Potapenko :
>>> KMSAN (KernelMemorySanitizer, a new error detection tool) reports use of
>>> uninitialized memory in cfq_init_cfqq():
>>>
>>> ==
>>> BUG: KMSAN: use of unitialized memory
>>> ...
>>> Call Trace:
>>>  [< inline >] __dump_stack lib/dump_stack.c:15
>>>  [] dump_stack+0x157/0x1d0 lib/dump_stack.c:51
>>>  [] kmsan_report+0x205/0x360 ??:?
>>>  [] __msan_warning+0x5b/0xb0 ??:?
>>>  [< inline >] cfq_init_cfqq block/cfq-iosched.c:3754
>>>  [] cfq_get_queue+0xc80/0x14d0 block/cfq-iosched.c:3857
>>> ...
>>> origin:
>>>  [] save_stack_trace+0x27/0x50 
>>> arch/x86/kernel/stacktrace.c:67
>>>  [] kmsan_internal_poison_shadow+0xab/0x150 ??:?
>>>  [] kmsan_poison_slab+0xbb/0x120 ??:?
>>>  [< inline >] allocate_slab mm/slub.c:1627
>>>  [] new_slab+0x3af/0x4b0 mm/slub.c:1641
>>>  [< inline >] new_slab_objects mm/slub.c:2407
>>>  [] ___slab_alloc+0x323/0x4a0 mm/slub.c:2564
>>>  [< inline >] __slab_alloc mm/slub.c:2606
>>>  [< inline >] slab_alloc_node mm/slub.c:2669
>>>  [] kmem_cache_alloc_node+0x1d2/0x1f0 mm/slub.c:2746
>>>  [] cfq_get_queue+0x47d/0x14d0 block/cfq-iosched.c:3850
>>> ...
>>> ==
>>> (the line numbers are relative to 4.8-rc6, but the bug persists
>>> upstream)
>>>
>>> The uninitialized struct cfq_queue is created by kmem_cache_alloc_node()
>>> and then passed to cfq_init_cfqq(), which accesses cfqq->ioprio_class
>>> before it's initialized.
>>>
>>
>> struct cfq_queue is zero initialized (__GFP_ZERO).
>> The warning is false-positive.
> You are totally right. I've handled __GFP_ZERO in (hopefully) every
> case except for this one, and overlooked the presence of that flag in
> the kmem_cache_alloc_node().
> Thanks for double-checking!
> Jens, sorry for the false alarm.

No worries, I did queue up the patch, since even if it is a false
positive, it's cleaner to set this explicitly to NONE rather than
silently rely on the fact that NONE is 0.

-- 
Jens Axboe

Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic

[Luck, Tony]

On Mon, Jan 23, 2017 at 06:51:30PM +0100, Borislav Petkov wrote:
> Hey Tony,
> 
> a "welcome back" is in order? :-)

Yes - first day back today. Lots of catching up to do.

> And apparently crash knows about poisoned pages and handles them:
> 
> static int __init crash_save_vmcoreinfo_init(void)
> {
>   ...
> #ifdef CONFIG_MEMORY_FAILURE
> VMCOREINFO_NUMBER(PG_hwpoison);
> #endif
> 
> so if that works, the kexeced kernel should know about that list.

Oh good ... it is smarter than I thought.

> Doesn't matter, right? The new copy is as clueless as the old one about
> those MCEs.

If things are well enough initialized that we don't reset, and
get to do_machine_check(), then this code from Ashok:

/* If this CPU is offline, just bail out. */
if (cpu_is_offline(smp_processor_id())) {
u64 mcgstatus;

mcgstatus = mce_rdmsrl(MSR_IA32_MCG_STATUS);
if (mcgstatus & MCG_STATUS_RIPV) {
mce_wrmsrl(MSR_IA32_MCG_STATUS, 0);
return;
}
}

will ignore the machine check on the other cpus ... assuming
that "cpu_is_offline(smp_processor_id())" does the right thing
in the kexec case where this is an "old" cpu that isn't online
in the new kernel.

-Tony

Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic

[Luck, Tony]

On Mon, Jan 23, 2017 at 06:51:30PM +0100, Borislav Petkov wrote:
> Hey Tony,
> 
> a "welcome back" is in order? :-)

Yes - first day back today. Lots of catching up to do.

> And apparently crash knows about poisoned pages and handles them:
> 
> static int __init crash_save_vmcoreinfo_init(void)
> {
>   ...
> #ifdef CONFIG_MEMORY_FAILURE
> VMCOREINFO_NUMBER(PG_hwpoison);
> #endif
> 
> so if that works, the kexeced kernel should know about that list.

Oh good ... it is smarter than I thought.

> Doesn't matter, right? The new copy is as clueless as the old one about
> those MCEs.

If things are well enough initialized that we don't reset, and
get to do_machine_check(), then this code from Ashok:

/* If this CPU is offline, just bail out. */
if (cpu_is_offline(smp_processor_id())) {
u64 mcgstatus;

mcgstatus = mce_rdmsrl(MSR_IA32_MCG_STATUS);
if (mcgstatus & MCG_STATUS_RIPV) {
mce_wrmsrl(MSR_IA32_MCG_STATUS, 0);
return;
}
}

will ignore the machine check on the other cpus ... assuming
that "cpu_is_offline(smp_processor_id())" does the right thing
in the kexec case where this is an "old" cpu that isn't online
in the new kernel.

-Tony

Re: [PATCH v4 0/9] Implement clocksource for rockchip SoC using rockchip timer

[Daniel Lezcano]

On Mon, Jan 23, 2017 at 08:24:47PM +0300, Alexander Kochetkov wrote:
> Heiko, Daniel, thanks a lot for review!
> I’ll send v5 series this week.
> 
> Heiko, Daniel, may I add 'Reviewed-by:’ to patch series?
> 
> Reviewed-by: Heiko Stübner  ?
> Reviewed-by: Daniel Lezcano  ?
> 

I will answer with the corresponding tag myself when you send the v5.

Thanks.

  -- Daniel

-- 

  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH v4 0/9] Implement clocksource for rockchip SoC using rockchip timer

[Daniel Lezcano]

On Mon, Jan 23, 2017 at 08:24:47PM +0300, Alexander Kochetkov wrote:
> Heiko, Daniel, thanks a lot for review!
> I’ll send v5 series this week.
> 
> Heiko, Daniel, may I add 'Reviewed-by:’ to patch series?
> 
> Reviewed-by: Heiko Stübner  ?
> Reviewed-by: Daniel Lezcano  ?
> 

I will answer with the corresponding tag myself when you send the v5.

Thanks.

  -- Daniel

-- 

  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

[PATCH 1/1 linux-next] ext4: atomically read inode size

[Fabian Frederick]

See i_size_read() comments in include/linux/fs.h

Signed-off-by: Fabian Frederick 
---
 fs/ext4/super.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 9d15a62..3746f77 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3798,7 +3798,8 @@ static int ext4_fill_super(struct super_block *sb, void 
*data, int silent)
goto cantfind_ext4;
 
/* check blocks count against device size */
-   blocks_count = sb->s_bdev->bd_inode->i_size >> sb->s_blocksize_bits;
+   blocks_count = i_size_read(sb->s_bdev->bd_inode) >>
+  sb->s_blocksize_bits;
if (blocks_count && ext4_blocks_count(es) > blocks_count) {
ext4_msg(sb, KERN_WARNING, "bad geometry: block count %llu "
   "exceeds size of device (%llu blocks)",
-- 
2.9.3

[PATCH 1/1 linux-next] ext4: atomically read inode size

[Fabian Frederick]

See i_size_read() comments in include/linux/fs.h

Signed-off-by: Fabian Frederick 
---
 fs/ext4/super.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 9d15a62..3746f77 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3798,7 +3798,8 @@ static int ext4_fill_super(struct super_block *sb, void 
*data, int silent)
goto cantfind_ext4;
 
/* check blocks count against device size */
-   blocks_count = sb->s_bdev->bd_inode->i_size >> sb->s_blocksize_bits;
+   blocks_count = i_size_read(sb->s_bdev->bd_inode) >>
+  sb->s_blocksize_bits;
if (blocks_count && ext4_blocks_count(es) > blocks_count) {
ext4_msg(sb, KERN_WARNING, "bad geometry: block count %llu "
   "exceeds size of device (%llu blocks)",
-- 
2.9.3

[PATCH 1/1 linux-next] hfsplus: atomically read inode size

[Fabian Frederick]

See i_size_read() comments in include/linux/fs.h

Signed-off-by: Fabian Frederick 
---
 fs/hfsplus/wrapper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/hfsplus/wrapper.c b/fs/hfsplus/wrapper.c
index ebb85e5..e254fa0 100644
--- a/fs/hfsplus/wrapper.c
+++ b/fs/hfsplus/wrapper.c
@@ -132,7 +132,7 @@ static int hfsplus_get_last_session(struct super_block *sb,
 
/* default values */
*start = 0;
-   *size = sb->s_bdev->bd_inode->i_size >> 9;
+   *size = i_size_read(sb->s_bdev->bd_inode) >> 9;
 
if (HFSPLUS_SB(sb)->session >= 0) {
te.cdte_track = HFSPLUS_SB(sb)->session;
-- 
2.9.3

[PATCH 1/1 linux-next] hfsplus: atomically read inode size

[Fabian Frederick]

See i_size_read() comments in include/linux/fs.h

Signed-off-by: Fabian Frederick 
---
 fs/hfsplus/wrapper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/hfsplus/wrapper.c b/fs/hfsplus/wrapper.c
index ebb85e5..e254fa0 100644
--- a/fs/hfsplus/wrapper.c
+++ b/fs/hfsplus/wrapper.c
@@ -132,7 +132,7 @@ static int hfsplus_get_last_session(struct super_block *sb,
 
/* default values */
*start = 0;
-   *size = sb->s_bdev->bd_inode->i_size >> 9;
+   *size = i_size_read(sb->s_bdev->bd_inode) >> 9;
 
if (HFSPLUS_SB(sb)->session >= 0) {
te.cdte_track = HFSPLUS_SB(sb)->session;
-- 
2.9.3

Re: [PATCH] net: adaptec: starfire: add checks for dma mapping errors

[David Miller]

From: Alexey Khoroshilov 
Date: Sat, 21 Jan 2017 01:52:24 +0300

> init_ring() and refill_rx_ring() don't check if mapping dma memory succeed.
> The patch adds the checks and failure handling.
> 
> Found by Linux Driver Verification project (linuxtesting.org).
> 
> Signed-off-by: Alexey Khoroshilov 

The transmit side has the same exact problem, can you take care of both
of them at the same time?

Thanks.

Re: [PATCH] net: adaptec: starfire: add checks for dma mapping errors

[David Miller]

From: Alexey Khoroshilov 
Date: Sat, 21 Jan 2017 01:52:24 +0300

> init_ring() and refill_rx_ring() don't check if mapping dma memory succeed.
> The patch adds the checks and failure handling.
> 
> Found by Linux Driver Verification project (linuxtesting.org).
> 
> Signed-off-by: Alexey Khoroshilov 

The transmit side has the same exact problem, can you take care of both
of them at the same time?

Thanks.

[PATCH 1/1 linux-next] hfs: atomically read inode size

[Fabian Frederick]

See i_size_read() comments in include/linux/fs.h

Signed-off-by: Fabian Frederick 
---
 fs/hfs/mdb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/hfs/mdb.c b/fs/hfs/mdb.c
index a3ec3ae..482081b 100644
--- a/fs/hfs/mdb.c
+++ b/fs/hfs/mdb.c
@@ -38,7 +38,7 @@ static int hfs_get_last_session(struct super_block *sb,
 
/* default values */
*start = 0;
-   *size = sb->s_bdev->bd_inode->i_size >> 9;
+   *size = i_size_read(sb->s_bdev->bd_inode) >> 9;
 
if (HFS_SB(sb)->session >= 0) {
te.cdte_track = HFS_SB(sb)->session;
-- 
2.9.3

[PATCH 1/1 linux-next] hfs: atomically read inode size

[Fabian Frederick]

See i_size_read() comments in include/linux/fs.h

Signed-off-by: Fabian Frederick 
---
 fs/hfs/mdb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/hfs/mdb.c b/fs/hfs/mdb.c
index a3ec3ae..482081b 100644
--- a/fs/hfs/mdb.c
+++ b/fs/hfs/mdb.c
@@ -38,7 +38,7 @@ static int hfs_get_last_session(struct super_block *sb,
 
/* default values */
*start = 0;
-   *size = sb->s_bdev->bd_inode->i_size >> 9;
+   *size = i_size_read(sb->s_bdev->bd_inode) >> 9;
 
if (HFS_SB(sb)->session >= 0) {
te.cdte_track = HFS_SB(sb)->session;
-- 
2.9.3

Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic

[Borislav Petkov]

Hey Tony,

a "welcome back" is in order? :-)

On Mon, Jan 23, 2017 at 09:40:09AM -0800, Luck, Tony wrote:
> If the system had experienced some memory corruption, but
> recovered ... then there would be some pages sitting around
> that the old kernel had marked as POISON and stopped using.
> The kexec'd kernel doesn't know about these, so may touch that
> memory while taking a crash dump ...

Hmm, pass a list of poisoned pages to the kdump kernel so as not to
touch. Looks like there's already functionality for that:

"makedumpfile can exclude the following types of pages while copying
VMCORE to DUMPFILE, and a user can choose which type of pages will be
excluded.

- Pages filled with zero
- Cache pages
- User process data pages
- Free pages"

 (there is a makedumpfile manpage somewhere)

And apparently crash knows about poisoned pages and handles them:

static int __init crash_save_vmcoreinfo_init(void)
{
...
#ifdef CONFIG_MEMORY_FAILURE
VMCOREINFO_NUMBER(PG_hwpoison);
#endif

so if that works, the kexeced kernel should know about that list.

> and then you have a broadcast machine check (on older[1] Intel CPUs
> that don't support local machine check).

Right.

> This is hard to work around. You really need all the CPUs to have set
> CR4.MCE=1 (if any didn't, then they will force a reset when they see
> the machine check). Also you need to make sure that they jump to the
> copy of do_machine_check() in the new kernel, not the old kernel.

Doesn't matter, right? The new copy is as clueless as the old one about
those MCEs.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic

[Borislav Petkov]

Hey Tony,

a "welcome back" is in order? :-)

On Mon, Jan 23, 2017 at 09:40:09AM -0800, Luck, Tony wrote:
> If the system had experienced some memory corruption, but
> recovered ... then there would be some pages sitting around
> that the old kernel had marked as POISON and stopped using.
> The kexec'd kernel doesn't know about these, so may touch that
> memory while taking a crash dump ...

Hmm, pass a list of poisoned pages to the kdump kernel so as not to
touch. Looks like there's already functionality for that:

"makedumpfile can exclude the following types of pages while copying
VMCORE to DUMPFILE, and a user can choose which type of pages will be
excluded.

- Pages filled with zero
- Cache pages
- User process data pages
- Free pages"

 (there is a makedumpfile manpage somewhere)

And apparently crash knows about poisoned pages and handles them:

static int __init crash_save_vmcoreinfo_init(void)
{
...
#ifdef CONFIG_MEMORY_FAILURE
VMCOREINFO_NUMBER(PG_hwpoison);
#endif

so if that works, the kexeced kernel should know about that list.

> and then you have a broadcast machine check (on older[1] Intel CPUs
> that don't support local machine check).

Right.

> This is hard to work around. You really need all the CPUs to have set
> CR4.MCE=1 (if any didn't, then they will force a reset when they see
> the machine check). Also you need to make sure that they jump to the
> copy of do_machine_check() in the new kernel, not the old kernel.

Doesn't matter, right? The new copy is as clueless as the old one about
those MCEs.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[PATCH] frv: add missing atomic64 operations

[Sudip Mukherjee]

From: Sudip Mukherjee 

Some more atomic64 operations were missing and as a result
frv allmodconfig was failing. Add the missing operations.

Signed-off-by: Sudip Mukherjee 
---
 arch/frv/include/asm/atomic.h | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/frv/include/asm/atomic.h b/arch/frv/include/asm/atomic.h
index 994ed3d..e93c949 100644
--- a/arch/frv/include/asm/atomic.h
+++ b/arch/frv/include/asm/atomic.h
@@ -139,7 +139,7 @@ static inline void atomic64_dec(atomic64_t *v)
 #define atomic64_sub_and_test(i,v) (atomic64_sub_return((i), (v)) == 0)
 #define atomic64_dec_and_test(v)   (atomic64_dec_return((v)) == 0)
 #define atomic64_inc_and_test(v)   (atomic64_inc_return((v)) == 0)
-
+#define atomic64_inc_not_zero(v)   atomic64_add_unless((v), 1, 0)
 
 #define atomic_cmpxchg(v, old, new)(cmpxchg(&(v)->counter, old, new))
 #define atomic_xchg(v, new)(xchg(&(v)->counter, new))
@@ -177,6 +177,23 @@ static inline int atomic64_add_unless(atomic64_t *v, long 
long i, long long u)
return c != u;
 }
 
+static inline long long atomic64_dec_if_positive(atomic64_t *v)
+{
+   long long c, old, dec;
+
+   c = atomic64_read(v);
+   for (;;) {
+   dec = c - 1;
+   if (unlikely(dec < 0))
+   break;
+   old = atomic64_cmpxchg((v), c, dec);
+   if (likely(old == c))
+   break;
+   c = old;
+   }
+   return dec;
+}
+
 #define ATOMIC_OP(op)  \
 static inline int atomic_fetch_##op(int i, atomic_t *v)
\
 {  \
-- 
2.7.4

[PATCH] frv: add missing atomic64 operations

[Sudip Mukherjee]

From: Sudip Mukherjee 

Some more atomic64 operations were missing and as a result
frv allmodconfig was failing. Add the missing operations.

Signed-off-by: Sudip Mukherjee 
---
 arch/frv/include/asm/atomic.h | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/frv/include/asm/atomic.h b/arch/frv/include/asm/atomic.h
index 994ed3d..e93c949 100644
--- a/arch/frv/include/asm/atomic.h
+++ b/arch/frv/include/asm/atomic.h
@@ -139,7 +139,7 @@ static inline void atomic64_dec(atomic64_t *v)
 #define atomic64_sub_and_test(i,v) (atomic64_sub_return((i), (v)) == 0)
 #define atomic64_dec_and_test(v)   (atomic64_dec_return((v)) == 0)
 #define atomic64_inc_and_test(v)   (atomic64_inc_return((v)) == 0)
-
+#define atomic64_inc_not_zero(v)   atomic64_add_unless((v), 1, 0)
 
 #define atomic_cmpxchg(v, old, new)(cmpxchg(&(v)->counter, old, new))
 #define atomic_xchg(v, new)(xchg(&(v)->counter, new))
@@ -177,6 +177,23 @@ static inline int atomic64_add_unless(atomic64_t *v, long 
long i, long long u)
return c != u;
 }
 
+static inline long long atomic64_dec_if_positive(atomic64_t *v)
+{
+   long long c, old, dec;
+
+   c = atomic64_read(v);
+   for (;;) {
+   dec = c - 1;
+   if (unlikely(dec < 0))
+   break;
+   old = atomic64_cmpxchg((v), c, dec);
+   if (likely(old == c))
+   break;
+   c = old;
+   }
+   return dec;
+}
+
 #define ATOMIC_OP(op)  \
 static inline int atomic_fetch_##op(int i, atomic_t *v)
\
 {  \
-- 
2.7.4

[PATCH 1/1 linux-next] jfs: atomically read inode size

[Fabian Frederick]

See i_size_read() comments in include/linux/fs.h

Signed-off-by: Fabian Frederick 
---
 fs/jfs/resize.c | 4 ++--
 fs/jfs/super.c  | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/jfs/resize.c b/fs/jfs/resize.c
index bd9b641..7ddcb44 100644
--- a/fs/jfs/resize.c
+++ b/fs/jfs/resize.c
@@ -98,7 +98,7 @@ int jfs_extendfs(struct super_block *sb, s64 newLVSize, int 
newLogSize)
goto out;
}
 
-   VolumeSize = sb->s_bdev->bd_inode->i_size >> sb->s_blocksize_bits;
+   VolumeSize = i_size_read(sb->s_bdev->bd_inode) >> sb->s_blocksize_bits;
 
if (VolumeSize) {
if (newLVSize > VolumeSize) {
@@ -211,7 +211,7 @@ int jfs_extendfs(struct super_block *sb, s64 newLVSize, int 
newLogSize)
txQuiesce(sb);
 
/* Reset size of direct inode */
-   sbi->direct_inode->i_size =  sb->s_bdev->bd_inode->i_size;
+   sbi->direct_inode->i_size =  i_size_read(sb->s_bdev->bd_inode);
 
if (sbi->mntflag & JFS_INLINELOG) {
/*
diff --git a/fs/jfs/super.c b/fs/jfs/super.c
index c64c257..ad02f00 100644
--- a/fs/jfs/super.c
+++ b/fs/jfs/super.c
@@ -283,7 +283,7 @@ static int parse_options(char *options, struct super_block 
*sb, s64 *newLVSize,
}
case Opt_resize_nosize:
{
-   *newLVSize = sb->s_bdev->bd_inode->i_size >>
+   *newLVSize = i_size_read(sb->s_bdev->bd_inode) >>
sb->s_blocksize_bits;
if (*newLVSize == 0)
pr_err("JFS: Cannot determine volume size\n");
@@ -549,7 +549,7 @@ static int jfs_fill_super(struct super_block *sb, void 
*data, int silent)
goto out_unload;
}
inode->i_ino = 0;
-   inode->i_size = sb->s_bdev->bd_inode->i_size;
+   inode->i_size = i_size_read(sb->s_bdev->bd_inode);
inode->i_mapping->a_ops = _metapage_aops;
hlist_add_fake(>i_hash);
mapping_set_gfp_mask(inode->i_mapping, GFP_NOFS);
-- 
2.9.3

[PATCH 1/1 linux-next] jfs: atomically read inode size

[Fabian Frederick]

See i_size_read() comments in include/linux/fs.h

Signed-off-by: Fabian Frederick 
---
 fs/jfs/resize.c | 4 ++--
 fs/jfs/super.c  | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/jfs/resize.c b/fs/jfs/resize.c
index bd9b641..7ddcb44 100644
--- a/fs/jfs/resize.c
+++ b/fs/jfs/resize.c
@@ -98,7 +98,7 @@ int jfs_extendfs(struct super_block *sb, s64 newLVSize, int 
newLogSize)
goto out;
}
 
-   VolumeSize = sb->s_bdev->bd_inode->i_size >> sb->s_blocksize_bits;
+   VolumeSize = i_size_read(sb->s_bdev->bd_inode) >> sb->s_blocksize_bits;
 
if (VolumeSize) {
if (newLVSize > VolumeSize) {
@@ -211,7 +211,7 @@ int jfs_extendfs(struct super_block *sb, s64 newLVSize, int 
newLogSize)
txQuiesce(sb);
 
/* Reset size of direct inode */
-   sbi->direct_inode->i_size =  sb->s_bdev->bd_inode->i_size;
+   sbi->direct_inode->i_size =  i_size_read(sb->s_bdev->bd_inode);
 
if (sbi->mntflag & JFS_INLINELOG) {
/*
diff --git a/fs/jfs/super.c b/fs/jfs/super.c
index c64c257..ad02f00 100644
--- a/fs/jfs/super.c
+++ b/fs/jfs/super.c
@@ -283,7 +283,7 @@ static int parse_options(char *options, struct super_block 
*sb, s64 *newLVSize,
}
case Opt_resize_nosize:
{
-   *newLVSize = sb->s_bdev->bd_inode->i_size >>
+   *newLVSize = i_size_read(sb->s_bdev->bd_inode) >>
sb->s_blocksize_bits;
if (*newLVSize == 0)
pr_err("JFS: Cannot determine volume size\n");
@@ -549,7 +549,7 @@ static int jfs_fill_super(struct super_block *sb, void 
*data, int silent)
goto out_unload;
}
inode->i_ino = 0;
-   inode->i_size = sb->s_bdev->bd_inode->i_size;
+   inode->i_size = i_size_read(sb->s_bdev->bd_inode);
inode->i_mapping->a_ops = _metapage_aops;
hlist_add_fake(>i_hash);
mapping_set_gfp_mask(inode->i_mapping, GFP_NOFS);
-- 
2.9.3

Re: [PATCH v3 3/5] drm/rockchip/dsi: remove mode_valid function

[Sean Paul]

On Fri, Jan 20, 2017 at 06:10:49PM +0800, Chris Zhong wrote:
> The MIPI DSI do not need check the validity of resolution, the max
> resolution should depend VOP. Hence, remove rk3288_mipi_dsi_mode_valid
> here.

Does vop actually enforce this, though? I see that mode_config.max_width is
4096, but there is no bounds checking in mode_fixup().

The connector is currently rejecting everything greater than 2047. So I think
you're going to regress behavior here.

Sean


> 
> Signed-off-by: Chris Zhong 
> ---
> 
> Changes in v3: None
> 
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 39 
> --
>  1 file changed, 39 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index a93ce97..6f0e252 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -278,8 +278,6 @@ struct dw_mipi_dsi_plat_data {
>   u32 grf_dsi0_mode;
>   u32 grf_dsi0_mode_reg;
>   unsigned int max_data_lanes;
> - enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
> -struct drm_display_mode *mode);
>  };
>  
>  struct dw_mipi_dsi {
> @@ -1081,23 +1079,8 @@ static int dw_mipi_dsi_connector_get_modes(struct 
> drm_connector *connector)
>   return drm_panel_get_modes(dsi->panel);
>  }
>  
> -static enum drm_mode_status dw_mipi_dsi_mode_valid(
> - struct drm_connector *connector,
> - struct drm_display_mode *mode)
> -{
> - struct dw_mipi_dsi *dsi = con_to_dsi(connector);
> -
> - enum drm_mode_status mode_status = MODE_OK;
> -
> - if (dsi->pdata->mode_valid)
> - mode_status = dsi->pdata->mode_valid(connector, mode);
> -
> - return mode_status;
> -}
> -
>  static struct drm_connector_helper_funcs dw_mipi_dsi_connector_helper_funcs 
> = {
>   .get_modes = dw_mipi_dsi_connector_get_modes,
> - .mode_valid = dw_mipi_dsi_mode_valid,
>  };
>  
>  static void dw_mipi_dsi_drm_connector_destroy(struct drm_connector 
> *connector)
> @@ -1168,33 +1151,11 @@ static int rockchip_mipi_parse_dt(struct dw_mipi_dsi 
> *dsi)
>   return 0;
>  }
>  
> -static enum drm_mode_status rk3288_mipi_dsi_mode_valid(
> - struct drm_connector *connector,
> - struct drm_display_mode *mode)
> -{
> - /*
> -  * The VID_PKT_SIZE field in the DSI_VID_PKT_CFG
> -  * register is 11-bit.
> -  */
> - if (mode->hdisplay > 0x7ff)
> - return MODE_BAD_HVALUE;
> -
> - /*
> -  * The V_ACTIVE_LINES field in the DSI_VTIMING_CFG
> -  * register is 11-bit.
> -  */
> - if (mode->vdisplay > 0x7ff)
> - return MODE_BAD_VVALUE;
> -
> - return MODE_OK;
> -}
> -
>  static struct dw_mipi_dsi_plat_data rk3288_mipi_dsi_drv_data = {
>   .dsi0_en_bit = RK3288_DSI0_SEL_VOP_LIT,
>   .dsi1_en_bit = RK3288_DSI1_SEL_VOP_LIT,
>   .grf_switch_reg = RK3288_GRF_SOC_CON6,
>   .max_data_lanes = 4,
> - .mode_valid = rk3288_mipi_dsi_mode_valid,
>  };
>  
>  static struct dw_mipi_dsi_plat_data rk3399_mipi_dsi_drv_data = {
> -- 
> 2.6.3
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS

Re: [PATCH v3 3/5] drm/rockchip/dsi: remove mode_valid function

[Sean Paul]

On Fri, Jan 20, 2017 at 06:10:49PM +0800, Chris Zhong wrote:
> The MIPI DSI do not need check the validity of resolution, the max
> resolution should depend VOP. Hence, remove rk3288_mipi_dsi_mode_valid
> here.

Does vop actually enforce this, though? I see that mode_config.max_width is
4096, but there is no bounds checking in mode_fixup().

The connector is currently rejecting everything greater than 2047. So I think
you're going to regress behavior here.

Sean


> 
> Signed-off-by: Chris Zhong 
> ---
> 
> Changes in v3: None
> 
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 39 
> --
>  1 file changed, 39 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index a93ce97..6f0e252 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -278,8 +278,6 @@ struct dw_mipi_dsi_plat_data {
>   u32 grf_dsi0_mode;
>   u32 grf_dsi0_mode_reg;
>   unsigned int max_data_lanes;
> - enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
> -struct drm_display_mode *mode);
>  };
>  
>  struct dw_mipi_dsi {
> @@ -1081,23 +1079,8 @@ static int dw_mipi_dsi_connector_get_modes(struct 
> drm_connector *connector)
>   return drm_panel_get_modes(dsi->panel);
>  }
>  
> -static enum drm_mode_status dw_mipi_dsi_mode_valid(
> - struct drm_connector *connector,
> - struct drm_display_mode *mode)
> -{
> - struct dw_mipi_dsi *dsi = con_to_dsi(connector);
> -
> - enum drm_mode_status mode_status = MODE_OK;
> -
> - if (dsi->pdata->mode_valid)
> - mode_status = dsi->pdata->mode_valid(connector, mode);
> -
> - return mode_status;
> -}
> -
>  static struct drm_connector_helper_funcs dw_mipi_dsi_connector_helper_funcs 
> = {
>   .get_modes = dw_mipi_dsi_connector_get_modes,
> - .mode_valid = dw_mipi_dsi_mode_valid,
>  };
>  
>  static void dw_mipi_dsi_drm_connector_destroy(struct drm_connector 
> *connector)
> @@ -1168,33 +1151,11 @@ static int rockchip_mipi_parse_dt(struct dw_mipi_dsi 
> *dsi)
>   return 0;
>  }
>  
> -static enum drm_mode_status rk3288_mipi_dsi_mode_valid(
> - struct drm_connector *connector,
> - struct drm_display_mode *mode)
> -{
> - /*
> -  * The VID_PKT_SIZE field in the DSI_VID_PKT_CFG
> -  * register is 11-bit.
> -  */
> - if (mode->hdisplay > 0x7ff)
> - return MODE_BAD_HVALUE;
> -
> - /*
> -  * The V_ACTIVE_LINES field in the DSI_VTIMING_CFG
> -  * register is 11-bit.
> -  */
> - if (mode->vdisplay > 0x7ff)
> - return MODE_BAD_VVALUE;
> -
> - return MODE_OK;
> -}
> -
>  static struct dw_mipi_dsi_plat_data rk3288_mipi_dsi_drv_data = {
>   .dsi0_en_bit = RK3288_DSI0_SEL_VOP_LIT,
>   .dsi1_en_bit = RK3288_DSI1_SEL_VOP_LIT,
>   .grf_switch_reg = RK3288_GRF_SOC_CON6,
>   .max_data_lanes = 4,
> - .mode_valid = rk3288_mipi_dsi_mode_valid,
>  };
>  
>  static struct dw_mipi_dsi_plat_data rk3399_mipi_dsi_drv_data = {
> -- 
> 2.6.3
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS

[PATCH 1/1 linux-next] fs/reiserfs: atomically read inode size

[Fabian Frederick]

See i_size_read() comments in include/linux/fs.h

Signed-off-by: Fabian Frederick 
---
 fs/reiserfs/super.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/reiserfs/super.c b/fs/reiserfs/super.c
index e314cb3..feabcde 100644
--- a/fs/reiserfs/super.c
+++ b/fs/reiserfs/super.c
@@ -1166,7 +1166,7 @@ static int reiserfs_parse_options(struct super_block *s,
if (!strcmp(arg, "auto")) {
/* From JFS code, to auto-get the size. */
*blocks =
-   s->s_bdev->bd_inode->i_size >> s->
+   i_size_read(s->s_bdev->bd_inode) >> s->
s_blocksize_bits;
} else {
*blocks = simple_strtoul(arg, , 0);
-- 
2.9.3

[PATCH 1/1 linux-next] fs/reiserfs: atomically read inode size

[Fabian Frederick]

See i_size_read() comments in include/linux/fs.h

Signed-off-by: Fabian Frederick 
---
 fs/reiserfs/super.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/reiserfs/super.c b/fs/reiserfs/super.c
index e314cb3..feabcde 100644
--- a/fs/reiserfs/super.c
+++ b/fs/reiserfs/super.c
@@ -1166,7 +1166,7 @@ static int reiserfs_parse_options(struct super_block *s,
if (!strcmp(arg, "auto")) {
/* From JFS code, to auto-get the size. */
*blocks =
-   s->s_bdev->bd_inode->i_size >> s->
+   i_size_read(s->s_bdev->bd_inode) >> s->
s_blocksize_bits;
} else {
*blocks = simple_strtoul(arg, , 0);
-- 
2.9.3

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[kbuild test robot]

Hi Nicolas,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc5 next-20170123]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Nicolas-Dichtel/uapi-export-all-headers-under-uapi-directories/20170124-011935
config: i386-tinyconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   In file included from arch/x86/include/asm/processor.h:20:0,
from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:25,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/mmzone.h:7,
from include/linux/gfp.h:5,
from include/linux/slab.h:14,
from include/linux/crypto.h:24,
from arch/x86/kernel/asm-offsets.c:8:
>> arch/x86/include/asm/msr.h:4:23: fatal error: msr-index.h: No such file or 
>> directory
#include "msr-index.h"
  ^
   compilation terminated.
   make[2]: *** [arch/x86/kernel/asm-offsets.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +4 arch/x86/include/asm/msr.h

1965aae3 arch/x86/include/asm/msr.h H. Peter Anvin2008-10-22   1  
#ifndef _ASM_X86_MSR_H
1965aae3 arch/x86/include/asm/msr.h H. Peter Anvin2008-10-22   2  
#define _ASM_X86_MSR_H
be7baf80 include/asm-x86/msr.h  Thomas Gleixner   2007-10-23   3  
b72e7464 arch/x86/include/asm/msr.h Borislav Petkov   2015-06-04  @4  
#include "msr-index.h"
be7baf80 include/asm-x86/msr.h  Thomas Gleixner   2007-10-23   5  
8f12dea6 include/asm-x86/msr.h  Glauber de Oliveira Costa 2008-01-30   6  
#ifndef __ASSEMBLY__
c210d249 include/asm-x86/msr.h  Glauber de Oliveira Costa 2008-01-30   7  
c210d249 include/asm-x86/msr.h  Glauber de Oliveira Costa 2008-01-30   8  
#include 
c210d249 include/asm-x86/msr.h  Glauber de Oliveira Costa 2008-01-30   9  
#include 
6bc1096d arch/x86/include/asm/msr.h Borislav Petkov   2009-05-22  10  
#include 
b72e7464 arch/x86/include/asm/msr.h Borislav Petkov   2015-06-04  11  
#include 
6bc1096d arch/x86/include/asm/msr.h Borislav Petkov   2009-05-22  12  

:: The code at line 4 was first introduced by commit
:: b72e7464e4cf80117938e6adb8c22fdc1ca46d42 x86/uapi: Do not export 
 as part of the user API headers

:: TO: Borislav Petkov <b...@suse.de>
:: CC: Ingo Molnar <mi...@kernel.org>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[kbuild test robot]

Hi Nicolas,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc5 next-20170123]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Nicolas-Dichtel/uapi-export-all-headers-under-uapi-directories/20170124-011935
config: i386-tinyconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   In file included from arch/x86/include/asm/processor.h:20:0,
from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:25,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/mmzone.h:7,
from include/linux/gfp.h:5,
from include/linux/slab.h:14,
from include/linux/crypto.h:24,
from arch/x86/kernel/asm-offsets.c:8:
>> arch/x86/include/asm/msr.h:4:23: fatal error: msr-index.h: No such file or 
>> directory
#include "msr-index.h"
  ^
   compilation terminated.
   make[2]: *** [arch/x86/kernel/asm-offsets.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +4 arch/x86/include/asm/msr.h

1965aae3 arch/x86/include/asm/msr.h H. Peter Anvin2008-10-22   1  
#ifndef _ASM_X86_MSR_H
1965aae3 arch/x86/include/asm/msr.h H. Peter Anvin2008-10-22   2  
#define _ASM_X86_MSR_H
be7baf80 include/asm-x86/msr.h  Thomas Gleixner   2007-10-23   3  
b72e7464 arch/x86/include/asm/msr.h Borislav Petkov   2015-06-04  @4  
#include "msr-index.h"
be7baf80 include/asm-x86/msr.h  Thomas Gleixner   2007-10-23   5  
8f12dea6 include/asm-x86/msr.h  Glauber de Oliveira Costa 2008-01-30   6  
#ifndef __ASSEMBLY__
c210d249 include/asm-x86/msr.h  Glauber de Oliveira Costa 2008-01-30   7  
c210d249 include/asm-x86/msr.h  Glauber de Oliveira Costa 2008-01-30   8  
#include 
c210d249 include/asm-x86/msr.h  Glauber de Oliveira Costa 2008-01-30   9  
#include 
6bc1096d arch/x86/include/asm/msr.h Borislav Petkov   2009-05-22  10  
#include 
b72e7464 arch/x86/include/asm/msr.h Borislav Petkov   2015-06-04  11  
#include 
6bc1096d arch/x86/include/asm/msr.h Borislav Petkov   2009-05-22  12  

:: The code at line 4 was first introduced by commit
:: b72e7464e4cf80117938e6adb8c22fdc1ca46d42 x86/uapi: Do not export 
 as part of the user API headers

:: TO: Borislav Petkov 
:: CC: Ingo Molnar 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCHSET v4] blk-mq-scheduling framework

[Jens Axboe]

On 01/23/2017 10:04 AM, Paolo Valente wrote:
> 
>> Il giorno 18 gen 2017, alle ore 17:21, Jens Axboe  ha scritto:
>>
>> On 01/18/2017 08:14 AM, Paolo Valente wrote:
>>> according to the function blk_mq_sched_put_request, the
>>> mq.completed_request hook seems to always be invoked (if set) for a
>>> request for which the mq.put_rq_priv is invoked (if set).
>>
>> Correct, any request that came out of blk_mq_sched_get_request()
>> will always have completed called on it, regardless of whether it
>> had IO started on it or not.
>>
> 
> It seems that some request, after being dispatched, happens to have no
> mq.put_rq_priv invoked on it now or then.  Is it expected?  If it is,
> could you point me to the path through which the end of the life of
> such a request is handled?

I'm guessing that's a flush request. I added RQF_QUEUED to check for
that, if RQF_QUEUED is set, you know it has come from your get_request
handler.

I'm assuming that is it, let me know.

-- 
Jens Axboe

Re: [PATCHSET v4] blk-mq-scheduling framework

[Jens Axboe]

On 01/23/2017 10:04 AM, Paolo Valente wrote:
> 
>> Il giorno 18 gen 2017, alle ore 17:21, Jens Axboe  ha scritto:
>>
>> On 01/18/2017 08:14 AM, Paolo Valente wrote:
>>> according to the function blk_mq_sched_put_request, the
>>> mq.completed_request hook seems to always be invoked (if set) for a
>>> request for which the mq.put_rq_priv is invoked (if set).
>>
>> Correct, any request that came out of blk_mq_sched_get_request()
>> will always have completed called on it, regardless of whether it
>> had IO started on it or not.
>>
> 
> It seems that some request, after being dispatched, happens to have no
> mq.put_rq_priv invoked on it now or then.  Is it expected?  If it is,
> could you point me to the path through which the end of the life of
> such a request is handled?

I'm guessing that's a flush request. I added RQF_QUEUED to check for
that, if RQF_QUEUED is set, you know it has come from your get_request
handler.

I'm assuming that is it, let me know.

-- 
Jens Axboe

[PATCH 1/3] coresight: fix kernel panic caused by invalid CPU

[Mathieu Poirier]

From: Wang Nan 

Commit d52c9750f150 ("coresight: reset "enable_sink" flag when need be")
caused a kernel panic because of the using of an invalid value: after
'for_each_cpu(cpu, mask)', value of local variable 'cpu' become invalid,
causes following 'cpu_to_node' access invalid memory area.

This patch brings the deleted 'cpu = cpumask_first(mask)' back.

Panic log:

 $ perf record -e cs_etm// ls

 Unable to handle kernel paging request at virtual address fffe801804af4f10
 pgd = 8017ce031600
 [fffe801804af4f10] *pgd=, *pud=
 Internal error: Oops: 9604 [#1] SMP
 Modules linked in:
 CPU: 33 PID: 1619 Comm: perf Not tainted 4.7.1+ #16
 Hardware name: Huawei Taishan 2280 /CH05TEVBA, BIOS 1.10 11/24/2016
 task: 8017cb0c8400 ti: 8017cb154000 task.ti: 8017cb154000
 PC is at tmc_alloc_etf_buffer+0x60/0xd4
 LR is at tmc_alloc_etf_buffer+0x44/0xd4
 pc : [] lr : [] pstate: 6145
 sp : 8017cb157b40
 x29: 8017cb157b40 x28: 
 ...skip...
 7a60: 08c64dc8 0006 0253 
 7a80:   080872cc 0001
 [] tmc_alloc_etf_buffer+0x60/0xd4
 [] etm_setup_aux+0x1dc/0x1e8
 [] rb_alloc_aux+0x2b0/0x338
 [] perf_mmap+0x414/0x568
 [] mmap_region+0x324/0x544
 [] do_mmap+0x334/0x3e0
 [] vm_mmap_pgoff+0xa4/0xc8
 [] SyS_mmap_pgoff+0xb0/0x22c
 [] sys_mmap+0x18/0x28
 [] el0_svc_naked+0x24/0x28
 Code: 912040a5 d0001c00 f873d821 911c6000 (b8656822)
 ---[ end trace 98933da8f92b0c9a ]---

Signed-off-by: Wang Nan 
Cc: Xia Kaixu 
Cc: Li Zefan 
Cc: Mathieu Poirier 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Mathieu Poirier 
---
 drivers/hwtracing/coresight/coresight-etm-perf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c 
b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 17741969026e..26cfac3e6de7 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -242,6 +242,7 @@ static void *etm_setup_aux(int event_cpu, void **pages,
if (!sink_ops(sink)->alloc_buffer)
goto err;
 
+   cpu = cpumask_first(mask);
/* Get the AUX specific data from the sink buffer */
event_data->snk_config =
sink_ops(sink)->alloc_buffer(sink, cpu, pages,
-- 
2.7.4

[PATCH 1/3] coresight: fix kernel panic caused by invalid CPU

[Mathieu Poirier]

From: Wang Nan 

Commit d52c9750f150 ("coresight: reset "enable_sink" flag when need be")
caused a kernel panic because of the using of an invalid value: after
'for_each_cpu(cpu, mask)', value of local variable 'cpu' become invalid,
causes following 'cpu_to_node' access invalid memory area.

This patch brings the deleted 'cpu = cpumask_first(mask)' back.

Panic log:

 $ perf record -e cs_etm// ls

 Unable to handle kernel paging request at virtual address fffe801804af4f10
 pgd = 8017ce031600
 [fffe801804af4f10] *pgd=, *pud=
 Internal error: Oops: 9604 [#1] SMP
 Modules linked in:
 CPU: 33 PID: 1619 Comm: perf Not tainted 4.7.1+ #16
 Hardware name: Huawei Taishan 2280 /CH05TEVBA, BIOS 1.10 11/24/2016
 task: 8017cb0c8400 ti: 8017cb154000 task.ti: 8017cb154000
 PC is at tmc_alloc_etf_buffer+0x60/0xd4
 LR is at tmc_alloc_etf_buffer+0x44/0xd4
 pc : [] lr : [] pstate: 6145
 sp : 8017cb157b40
 x29: 8017cb157b40 x28: 
 ...skip...
 7a60: 08c64dc8 0006 0253 
 7a80:   080872cc 0001
 [] tmc_alloc_etf_buffer+0x60/0xd4
 [] etm_setup_aux+0x1dc/0x1e8
 [] rb_alloc_aux+0x2b0/0x338
 [] perf_mmap+0x414/0x568
 [] mmap_region+0x324/0x544
 [] do_mmap+0x334/0x3e0
 [] vm_mmap_pgoff+0xa4/0xc8
 [] SyS_mmap_pgoff+0xb0/0x22c
 [] sys_mmap+0x18/0x28
 [] el0_svc_naked+0x24/0x28
 Code: 912040a5 d0001c00 f873d821 911c6000 (b8656822)
 ---[ end trace 98933da8f92b0c9a ]---

Signed-off-by: Wang Nan 
Cc: Xia Kaixu 
Cc: Li Zefan 
Cc: Mathieu Poirier 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Mathieu Poirier 
---
 drivers/hwtracing/coresight/coresight-etm-perf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c 
b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 17741969026e..26cfac3e6de7 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -242,6 +242,7 @@ static void *etm_setup_aux(int event_cpu, void **pages,
if (!sink_ops(sink)->alloc_buffer)
goto err;
 
+   cpu = cpumask_first(mask);
/* Get the AUX specific data from the sink buffer */
event_data->snk_config =
sink_ops(sink)->alloc_buffer(sink, cpu, pages,
-- 
2.7.4

[PATCH 0/3] coresight: next v4.10-rc5

[Mathieu Poirier]

Hello,

These are the patches to be queued for the 4.11 cycle.  Please have
a look when you have the opportunity.  The set applies on your
'char-misc-next' branch (8e27a236312c).

Regards,
Mathieu

Mathieu Poirier (1):
  coresight: etm4x: Fix timestamp configuration when working from perf

Mike Leach (1):
  coresight: etm4x: Fix enabling of cycle accurate tracing in perf.

Wang Nan (1):
  coresight: fix kernel panic caused by invalid CPU

 drivers/hwtracing/coresight/coresight-etm-perf.c |  1 +
 drivers/hwtracing/coresight/coresight-etm4x.c| 10 +++---
 drivers/hwtracing/coresight/coresight-etm4x.h|  1 +
 3 files changed, 9 insertions(+), 3 deletions(-)

-- 
2.7.4

[PATCH 0/3] coresight: next v4.10-rc5

[Mathieu Poirier]

Hello,

These are the patches to be queued for the 4.11 cycle.  Please have
a look when you have the opportunity.  The set applies on your
'char-misc-next' branch (8e27a236312c).

Regards,
Mathieu

Mathieu Poirier (1):
  coresight: etm4x: Fix timestamp configuration when working from perf

Mike Leach (1):
  coresight: etm4x: Fix enabling of cycle accurate tracing in perf.

Wang Nan (1):
  coresight: fix kernel panic caused by invalid CPU

 drivers/hwtracing/coresight/coresight-etm-perf.c |  1 +
 drivers/hwtracing/coresight/coresight-etm4x.c| 10 +++---
 drivers/hwtracing/coresight/coresight-etm4x.h|  1 +
 3 files changed, 9 insertions(+), 3 deletions(-)

-- 
2.7.4

[PATCH 2/3] coresight: etm4x: Fix enabling of cycle accurate tracing in perf.

[Mathieu Poirier]

From: Mike Leach 

Using perf record 'cyclacc' option in cs_etm event was not setting up cycle
accurate trace correctly.

Corrects bit set in TRCCONFIGR to enable cycle accurate trace.
Programs TRTLR with a valid threshold value as required by ETMv4 spec.

Signed-off-by: Mike Leach 
Signed-off-by: Mathieu Poirier 
---
 drivers/hwtracing/coresight/coresight-etm4x.c | 7 +--
 drivers/hwtracing/coresight/coresight-etm4x.h | 1 +
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c 
b/drivers/hwtracing/coresight/coresight-etm4x.c
index 031480f2c34d..f432febdda49 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -216,8 +216,11 @@ static int etm4_parse_event_config(struct etmv4_drvdata 
*drvdata,
goto out;
 
/* Go from generic option to ETMv4 specifics */
-   if (attr->config & BIT(ETM_OPT_CYCACC))
-   config->cfg |= ETMv4_MODE_CYCACC;
+   if (attr->config & BIT(ETM_OPT_CYCACC)) {
+   config->cfg |= BIT(4);
+   /* TRM: Must program this for cycacc to work */
+   config->ccctlr = ETM_CYC_THRESHOLD_DEFAULT;
+   }
if (attr->config & BIT(ETM_OPT_TS))
config->cfg |= ETMv4_MODE_TIMESTAMP;
 
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h 
b/drivers/hwtracing/coresight/coresight-etm4x.h
index ba8d3f86de21..b3b5ea7b7fb3 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.h
+++ b/drivers/hwtracing/coresight/coresight-etm4x.h
@@ -146,6 +146,7 @@
 #define ETM_ARCH_V40x40
 #define ETMv4_SYNC_MASK0x1F
 #define ETM_CYC_THRESHOLD_MASK 0xFFF
+#define ETM_CYC_THRESHOLD_DEFAULT   0x100
 #define ETMv4_EVENT_MASK   0xFF
 #define ETM_CNTR_MAX_VAL   0x
 #define ETM_TRACEID_MASK   0x3f
-- 
2.7.4

[PATCH 3/3] coresight: etm4x: Fix timestamp configuration when working from perf

[Mathieu Poirier]

When using the ETM4x tracers from the perf interface two trace options are
available: cycle accurate and timestamp.

Enabling the timestamp feature is done by setting TRCCONFIGR.TS (bit 11).
The position of the timestamp bit in that register coincidentally happens
to be the same as what was chosen to enable timestamping from the 'mode'
sysFS entry.  The code does the right thing but the semantic is wrong.

This patch sets TRCCONFIGR.TS explicitly, as it is done from the sysFS
interface.  That way timestamps are set the same way from both perf and
sysFS and there is no misunderstanding as to what is intended.

Signed-off-by: Mathieu Poirier 
---
 drivers/hwtracing/coresight/coresight-etm4x.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c 
b/drivers/hwtracing/coresight/coresight-etm4x.c
index f432febdda49..d1340fb4e457 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -222,7 +222,8 @@ static int etm4_parse_event_config(struct etmv4_drvdata 
*drvdata,
config->ccctlr = ETM_CYC_THRESHOLD_DEFAULT;
}
if (attr->config & BIT(ETM_OPT_TS))
-   config->cfg |= ETMv4_MODE_TIMESTAMP;
+   /* bit[11], Global timestamp tracing bit */
+   config->cfg |= BIT(11);
 
 out:
return ret;
-- 
2.7.4

[PATCH 2/3] coresight: etm4x: Fix enabling of cycle accurate tracing in perf.

[Mathieu Poirier]

From: Mike Leach 

Using perf record 'cyclacc' option in cs_etm event was not setting up cycle
accurate trace correctly.

Corrects bit set in TRCCONFIGR to enable cycle accurate trace.
Programs TRTLR with a valid threshold value as required by ETMv4 spec.

Signed-off-by: Mike Leach 
Signed-off-by: Mathieu Poirier 
---
 drivers/hwtracing/coresight/coresight-etm4x.c | 7 +--
 drivers/hwtracing/coresight/coresight-etm4x.h | 1 +
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c 
b/drivers/hwtracing/coresight/coresight-etm4x.c
index 031480f2c34d..f432febdda49 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -216,8 +216,11 @@ static int etm4_parse_event_config(struct etmv4_drvdata 
*drvdata,
goto out;
 
/* Go from generic option to ETMv4 specifics */
-   if (attr->config & BIT(ETM_OPT_CYCACC))
-   config->cfg |= ETMv4_MODE_CYCACC;
+   if (attr->config & BIT(ETM_OPT_CYCACC)) {
+   config->cfg |= BIT(4);
+   /* TRM: Must program this for cycacc to work */
+   config->ccctlr = ETM_CYC_THRESHOLD_DEFAULT;
+   }
if (attr->config & BIT(ETM_OPT_TS))
config->cfg |= ETMv4_MODE_TIMESTAMP;
 
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h 
b/drivers/hwtracing/coresight/coresight-etm4x.h
index ba8d3f86de21..b3b5ea7b7fb3 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.h
+++ b/drivers/hwtracing/coresight/coresight-etm4x.h
@@ -146,6 +146,7 @@
 #define ETM_ARCH_V40x40
 #define ETMv4_SYNC_MASK0x1F
 #define ETM_CYC_THRESHOLD_MASK 0xFFF
+#define ETM_CYC_THRESHOLD_DEFAULT   0x100
 #define ETMv4_EVENT_MASK   0xFF
 #define ETM_CNTR_MAX_VAL   0x
 #define ETM_TRACEID_MASK   0x3f
-- 
2.7.4

[PATCH 3/3] coresight: etm4x: Fix timestamp configuration when working from perf

[Mathieu Poirier]

When using the ETM4x tracers from the perf interface two trace options are
available: cycle accurate and timestamp.

Enabling the timestamp feature is done by setting TRCCONFIGR.TS (bit 11).
The position of the timestamp bit in that register coincidentally happens
to be the same as what was chosen to enable timestamping from the 'mode'
sysFS entry.  The code does the right thing but the semantic is wrong.

This patch sets TRCCONFIGR.TS explicitly, as it is done from the sysFS
interface.  That way timestamps are set the same way from both perf and
sysFS and there is no misunderstanding as to what is intended.

Signed-off-by: Mathieu Poirier 
---
 drivers/hwtracing/coresight/coresight-etm4x.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c 
b/drivers/hwtracing/coresight/coresight-etm4x.c
index f432febdda49..d1340fb4e457 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -222,7 +222,8 @@ static int etm4_parse_event_config(struct etmv4_drvdata 
*drvdata,
config->ccctlr = ETM_CYC_THRESHOLD_DEFAULT;
}
if (attr->config & BIT(ETM_OPT_TS))
-   config->cfg |= ETMv4_MODE_TIMESTAMP;
+   /* bit[11], Global timestamp tracing bit */
+   config->cfg |= BIT(11);
 
 out:
return ret;
-- 
2.7.4

Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic

[Luck, Tony]

On Mon, Jan 23, 2017 at 03:50:56PM +0100, Borislav Petkov wrote:
> On Mon, Jan 23, 2017 at 09:35:53PM +0800, Xunlei Pang wrote:
> > One possible timing sequence would be:
> > 1st kernel running on multiple cpus panicked
> > then the crash dump code starts
> > the crash dump code stops the others cpus except the crashing one
> > 2nd kernel boots up on the crash cpu with "nr_cpus=1"
> > some broadcasted mce comes on some cpu amongst the other cpus(not the 
> > crashing cpu)
> 
> Where does this broadcasted MCE come from?
> 
> The crash dump code triggered it? Or it happened before the panic()?
> 
> Are you talking about an *actual* sequence which you're experiencing on
> real hw or is this something hypothetical?

If the system had experienced some memory corruption, but
recovered ... then there would be some pages sitting around
that the old kernel had marked as POISON and stopped using.
The kexec'd kernel doesn't know about these, so may touch that
memory while taking a crash dump ... and then you have a
broadcast machine check (on older[1] Intel CPUs that don't support
local machine check).

This is hard to work around.  You really need all the CPUs to
have set CR4.MCE=1 (if any didn't, then they will force a reset
when they see the machine check). Also you need to make sure that
they jump to the copy of do_machine_check() in the new kernel, not
the old kernel.

A while ago I played with the nr_cpus=N code to have it bring
all the CPUs far enough online to get the machine check initialization
done, then any extras above "N" just go back offline again.
But I never got this to work reliably.

-Tony

[1] older == all released ones, at the moment.

Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic

[Luck, Tony]

On Mon, Jan 23, 2017 at 03:50:56PM +0100, Borislav Petkov wrote:
> On Mon, Jan 23, 2017 at 09:35:53PM +0800, Xunlei Pang wrote:
> > One possible timing sequence would be:
> > 1st kernel running on multiple cpus panicked
> > then the crash dump code starts
> > the crash dump code stops the others cpus except the crashing one
> > 2nd kernel boots up on the crash cpu with "nr_cpus=1"
> > some broadcasted mce comes on some cpu amongst the other cpus(not the 
> > crashing cpu)
> 
> Where does this broadcasted MCE come from?
> 
> The crash dump code triggered it? Or it happened before the panic()?
> 
> Are you talking about an *actual* sequence which you're experiencing on
> real hw or is this something hypothetical?

If the system had experienced some memory corruption, but
recovered ... then there would be some pages sitting around
that the old kernel had marked as POISON and stopped using.
The kexec'd kernel doesn't know about these, so may touch that
memory while taking a crash dump ... and then you have a
broadcast machine check (on older[1] Intel CPUs that don't support
local machine check).

This is hard to work around.  You really need all the CPUs to
have set CR4.MCE=1 (if any didn't, then they will force a reset
when they see the machine check). Also you need to make sure that
they jump to the copy of do_machine_check() in the new kernel, not
the old kernel.

A while ago I played with the nr_cpus=N code to have it bring
all the CPUs far enough online to get the machine check initialization
done, then any extras above "N" just go back offline again.
But I never got this to work reliably.

-Tony

[1] older == all released ones, at the moment.

[PATCH] usb: gadget: udc: constify usb_ep_ops structures

[Bhumika Goyal]

Declare usb_ep_ops structures as const as they are only stored in the
ops field of an usb_ep structure. This field is of type const, so
usb_ep_ops structures having this property can be made const too.
Done using Coccinelle( A smaller version of the script)

@r disable optional_qualifier@
identifier i;
position p;
@@
static struct usb_ep_ops i@p={...};

@ok@
identifier r.i;
position p;
struct mv_ep a;
struct mv_u3d_ep b;
struct omap_ep c;

@@
(
a.ep.ops=@p;
|
b.ep.ops=@p;
|
c.ep.ops=@p;

)

@bad@
position p!={r.p,ok.p};
identifier r.i;
@@
i@p

@depends on !bad disable optional_qualifier@
identifier r.i;
@@
+const
struct usb_ep_ops i;

File size details before and after applying  the patch.
First line of every .o file shows the file size before patching and
second line shows the file size after patching.

  text data bss dec hex filename

   7782 384   881741fee usb/gadget/udc/fotg210-udc.o
   7878 296   881821ff6 usb/gadget/udc/fotg210-udc.o

  17866 992  40   1889849d2 usb/gadget/udc/fsl_udc_core.o
  17954 896  40   1889049ca usb/gadget/udc/fsl_udc_core.o

   9646 288   8994226d6 usb/gadget/udc/fusb300_udc.o
   9742 192   8994226d6 usb/gadget/udc/fusb300_udc.o

  12752 416   8   131763378 drivers/usb/gadget/udc/goku_udc.o
  12832 328   8   131683370 drivers/usb/gadget/udc/goku_udc.o

  165411696   8   182454745 drivers/usb/gadget/udc/gr_udc.o
  166371600   8   182454745 drivers/usb/gadget/udc/gr_udc.o

  15798 288  16   161023ee6 drivers/usb/gadget/udc/m66592-udc.o
  15894 192  16   161023ee6 drivers/usb/gadget/udc/m66592-udc.o

  177513808  16   215755447 usb/gadget/udc/mv_u3d_core.o
  178393712  16   21567543f usb/gadget/udc/mv_u3d_core.o

  173481112  24   184844834 usb/gadget/udc/mv_udc_core.o
  174361016  24   18476482c usb/gadget/udc/mv_udc_core.o

  259902620  13   286236fcf drivers/usb/gadget/udc/net2272.o
  260862524  13   286236fcf drivers/usb/gadget/udc/net2272.o

  184097312   8   257296481 drivers/usb/gadget/udc/pxa27x_udc.o
  185057208   8   257216479 drivers/usb/gadget/udc/pxa27x_udc.o

  18644 288  16   189484a04 usb/gadget/udc/r8a66597-udc.o
  18740 192  16   189484a04 usb/gadget/udc/r8a66597-udc.o

Files: drivers/usb/gadget/udc/{s3c-hsudc.o/omap_udc.o/fsl_qe_udc.o} did
not complie.

Signed-off-by: Bhumika Goyal 
---
 drivers/usb/gadget/udc/fotg210-udc.c  | 2 +-
 drivers/usb/gadget/udc/fsl_qe_udc.c   | 2 +-
 drivers/usb/gadget/udc/fsl_udc_core.c | 2 +-
 drivers/usb/gadget/udc/fusb300_udc.c  | 2 +-
 drivers/usb/gadget/udc/goku_udc.c | 2 +-
 drivers/usb/gadget/udc/gr_udc.c   | 2 +-
 drivers/usb/gadget/udc/m66592-udc.c   | 2 +-
 drivers/usb/gadget/udc/mv_u3d_core.c  | 2 +-
 drivers/usb/gadget/udc/mv_udc_core.c  | 2 +-
 drivers/usb/gadget/udc/net2272.c  | 4 ++--
 drivers/usb/gadget/udc/omap_udc.c | 2 +-
 drivers/usb/gadget/udc/pxa27x_udc.c   | 2 +-
 drivers/usb/gadget/udc/r8a66597-udc.c | 2 +-
 drivers/usb/gadget/udc/s3c-hsudc.c| 2 +-
 14 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/gadget/udc/fotg210-udc.c 
b/drivers/usb/gadget/udc/fotg210-udc.c
index 6ba122c..966637d 100644
--- a/drivers/usb/gadget/udc/fotg210-udc.c
+++ b/drivers/usb/gadget/udc/fotg210-udc.c
@@ -527,7 +527,7 @@ static void fotg210_ep_fifo_flush(struct usb_ep *_ep)
 {
 }
 
-static struct usb_ep_ops fotg210_ep_ops = {
+static const struct usb_ep_ops fotg210_ep_ops = {
.enable = fotg210_ep_enable,
.disable= fotg210_ep_disable,
 
diff --git a/drivers/usb/gadget/udc/fsl_qe_udc.c 
b/drivers/usb/gadget/udc/fsl_qe_udc.c
index 4fff51b..303328ce 100644
--- a/drivers/usb/gadget/udc/fsl_qe_udc.c
+++ b/drivers/usb/gadget/udc/fsl_qe_udc.c
@@ -1847,7 +1847,7 @@ static int qe_ep_set_halt(struct usb_ep *_ep, int value)
return status;
 }
 
-static struct usb_ep_ops qe_ep_ops = {
+static const struct usb_ep_ops qe_ep_ops = {
.enable = qe_ep_enable,
.disable = qe_ep_disable,
 
diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c 
b/drivers/usb/gadget/udc/fsl_udc_core.c
index 71094e4..f518727 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -1118,7 +1118,7 @@ static void fsl_ep_fifo_flush(struct usb_ep *_ep)
} while (fsl_readl(_regs->endptstatus) & bits);
 }
 
-static struct usb_ep_ops fsl_ep_ops = {
+static const struct usb_ep_ops fsl_ep_ops = {
.enable = fsl_ep_enable,
.disable = fsl_ep_disable,
 
diff --git a/drivers/usb/gadget/udc/fusb300_udc.c 
b/drivers/usb/gadget/udc/fusb300_udc.c
index 42ff308..e0c1b00 100644
--- a/drivers/usb/gadget/udc/fusb300_udc.c
+++ b/drivers/usb/gadget/udc/fusb300_udc.c
@@ -518,7 +518,7 @@ static void fusb300_fifo_flush(struct 

[PATCH] usb: gadget: udc: constify usb_ep_ops structures

[Bhumika Goyal]

Declare usb_ep_ops structures as const as they are only stored in the
ops field of an usb_ep structure. This field is of type const, so
usb_ep_ops structures having this property can be made const too.
Done using Coccinelle( A smaller version of the script)

@r disable optional_qualifier@
identifier i;
position p;
@@
static struct usb_ep_ops i@p={...};

@ok@
identifier r.i;
position p;
struct mv_ep a;
struct mv_u3d_ep b;
struct omap_ep c;

@@
(
a.ep.ops=@p;
|
b.ep.ops=@p;
|
c.ep.ops=@p;

)

@bad@
position p!={r.p,ok.p};
identifier r.i;
@@
i@p

@depends on !bad disable optional_qualifier@
identifier r.i;
@@
+const
struct usb_ep_ops i;

File size details before and after applying  the patch.
First line of every .o file shows the file size before patching and
second line shows the file size after patching.

  text data bss dec hex filename

   7782 384   881741fee usb/gadget/udc/fotg210-udc.o
   7878 296   881821ff6 usb/gadget/udc/fotg210-udc.o

  17866 992  40   1889849d2 usb/gadget/udc/fsl_udc_core.o
  17954 896  40   1889049ca usb/gadget/udc/fsl_udc_core.o

   9646 288   8994226d6 usb/gadget/udc/fusb300_udc.o
   9742 192   8994226d6 usb/gadget/udc/fusb300_udc.o

  12752 416   8   131763378 drivers/usb/gadget/udc/goku_udc.o
  12832 328   8   131683370 drivers/usb/gadget/udc/goku_udc.o

  165411696   8   182454745 drivers/usb/gadget/udc/gr_udc.o
  166371600   8   182454745 drivers/usb/gadget/udc/gr_udc.o

  15798 288  16   161023ee6 drivers/usb/gadget/udc/m66592-udc.o
  15894 192  16   161023ee6 drivers/usb/gadget/udc/m66592-udc.o

  177513808  16   215755447 usb/gadget/udc/mv_u3d_core.o
  178393712  16   21567543f usb/gadget/udc/mv_u3d_core.o

  173481112  24   184844834 usb/gadget/udc/mv_udc_core.o
  174361016  24   18476482c usb/gadget/udc/mv_udc_core.o

  259902620  13   286236fcf drivers/usb/gadget/udc/net2272.o
  260862524  13   286236fcf drivers/usb/gadget/udc/net2272.o

  184097312   8   257296481 drivers/usb/gadget/udc/pxa27x_udc.o
  185057208   8   257216479 drivers/usb/gadget/udc/pxa27x_udc.o

  18644 288  16   189484a04 usb/gadget/udc/r8a66597-udc.o
  18740 192  16   189484a04 usb/gadget/udc/r8a66597-udc.o

Files: drivers/usb/gadget/udc/{s3c-hsudc.o/omap_udc.o/fsl_qe_udc.o} did
not complie.

Signed-off-by: Bhumika Goyal 
---
 drivers/usb/gadget/udc/fotg210-udc.c  | 2 +-
 drivers/usb/gadget/udc/fsl_qe_udc.c   | 2 +-
 drivers/usb/gadget/udc/fsl_udc_core.c | 2 +-
 drivers/usb/gadget/udc/fusb300_udc.c  | 2 +-
 drivers/usb/gadget/udc/goku_udc.c | 2 +-
 drivers/usb/gadget/udc/gr_udc.c   | 2 +-
 drivers/usb/gadget/udc/m66592-udc.c   | 2 +-
 drivers/usb/gadget/udc/mv_u3d_core.c  | 2 +-
 drivers/usb/gadget/udc/mv_udc_core.c  | 2 +-
 drivers/usb/gadget/udc/net2272.c  | 4 ++--
 drivers/usb/gadget/udc/omap_udc.c | 2 +-
 drivers/usb/gadget/udc/pxa27x_udc.c   | 2 +-
 drivers/usb/gadget/udc/r8a66597-udc.c | 2 +-
 drivers/usb/gadget/udc/s3c-hsudc.c| 2 +-
 14 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/gadget/udc/fotg210-udc.c 
b/drivers/usb/gadget/udc/fotg210-udc.c
index 6ba122c..966637d 100644
--- a/drivers/usb/gadget/udc/fotg210-udc.c
+++ b/drivers/usb/gadget/udc/fotg210-udc.c
@@ -527,7 +527,7 @@ static void fotg210_ep_fifo_flush(struct usb_ep *_ep)
 {
 }
 
-static struct usb_ep_ops fotg210_ep_ops = {
+static const struct usb_ep_ops fotg210_ep_ops = {
.enable = fotg210_ep_enable,
.disable= fotg210_ep_disable,
 
diff --git a/drivers/usb/gadget/udc/fsl_qe_udc.c 
b/drivers/usb/gadget/udc/fsl_qe_udc.c
index 4fff51b..303328ce 100644
--- a/drivers/usb/gadget/udc/fsl_qe_udc.c
+++ b/drivers/usb/gadget/udc/fsl_qe_udc.c
@@ -1847,7 +1847,7 @@ static int qe_ep_set_halt(struct usb_ep *_ep, int value)
return status;
 }
 
-static struct usb_ep_ops qe_ep_ops = {
+static const struct usb_ep_ops qe_ep_ops = {
.enable = qe_ep_enable,
.disable = qe_ep_disable,
 
diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c 
b/drivers/usb/gadget/udc/fsl_udc_core.c
index 71094e4..f518727 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -1118,7 +1118,7 @@ static void fsl_ep_fifo_flush(struct usb_ep *_ep)
} while (fsl_readl(_regs->endptstatus) & bits);
 }
 
-static struct usb_ep_ops fsl_ep_ops = {
+static const struct usb_ep_ops fsl_ep_ops = {
.enable = fsl_ep_enable,
.disable = fsl_ep_disable,
 
diff --git a/drivers/usb/gadget/udc/fusb300_udc.c 
b/drivers/usb/gadget/udc/fusb300_udc.c
index 42ff308..e0c1b00 100644
--- a/drivers/usb/gadget/udc/fusb300_udc.c
+++ b/drivers/usb/gadget/udc/fusb300_udc.c
@@ -518,7 +518,7 @@ static void fusb300_fifo_flush(struct usb_ep *_ep)
 {
 }
 

Re: [PATCH v4 0/9] Implement clocksource for rockchip SoC using rockchip timer

[Alexander Kochetkov]

Heiko, Daniel, thanks a lot for review!
I’ll send v5 series this week.

Heiko, Daniel, may I add 'Reviewed-by:’ to patch series?

Reviewed-by: Heiko Stübner  ?
Reviewed-by: Daniel Lezcano  ?

Regards,
Alexander.

> 23 янв. 2017 г., в 20:12, Heiko Stübner  написал(а):
> 
> Am Montag, 23. Januar 2017, 15:47:44 CET schrieb Daniel Lezcano:
>> On Wed, Dec 21, 2016 at 05:21:05PM +0300, Alexander Kochetkov wrote:
>>> Hello Heiko, Daniel!
>>> 
>>> Are there any reasons why the patches [1][2] are not applied yet into
>>> kernel? How can I help in applying patches?
>> 
>> Hi Alexander,
>> 
>> sorry for the delay. Let me review them before taking the patchset.
>> 
>> Heiko, can you have a look to them also ?
> 
> somehow this series moved down to much in my inbox, sorry.
> 
> Devicetree changes look good, except where I commented.
> I guess it would be best (least intrusive) if I queue up the (then fixed) 
> devicetree changes after you are satisfied with the code parts.
> 
> I've also looked over the code changes again, test-build them and found the 
> build error mentioned separately. Overall they look good though.
> 
> 
> Heiko

Re: [PATCH v4 0/9] Implement clocksource for rockchip SoC using rockchip timer

[Alexander Kochetkov]

Heiko, Daniel, thanks a lot for review!
I’ll send v5 series this week.

Heiko, Daniel, may I add 'Reviewed-by:’ to patch series?

Reviewed-by: Heiko Stübner  ?
Reviewed-by: Daniel Lezcano  ?

Regards,
Alexander.

> 23 янв. 2017 г., в 20:12, Heiko Stübner  написал(а):
> 
> Am Montag, 23. Januar 2017, 15:47:44 CET schrieb Daniel Lezcano:
>> On Wed, Dec 21, 2016 at 05:21:05PM +0300, Alexander Kochetkov wrote:
>>> Hello Heiko, Daniel!
>>> 
>>> Are there any reasons why the patches [1][2] are not applied yet into
>>> kernel? How can I help in applying patches?
>> 
>> Hi Alexander,
>> 
>> sorry for the delay. Let me review them before taking the patchset.
>> 
>> Heiko, can you have a look to them also ?
> 
> somehow this series moved down to much in my inbox, sorry.
> 
> Devicetree changes look good, except where I commented.
> I guess it would be best (least intrusive) if I queue up the (then fixed) 
> devicetree changes after you are satisfied with the code parts.
> 
> I've also looked over the code changes again, test-build them and found the 
> build error mentioned separately. Overall they look good though.
> 
> 
> Heiko

Re: [PATCH v3 2/5] drm/rockchip/dsi: dw-mipi: support RK3399 mipi dsi

[Sean Paul]

On Fri, Jan 20, 2017 at 06:10:48PM +0800, Chris Zhong wrote:
> The vopb/vopl switch register of RK3399 mipi is different from RK3288,
> the default setting for mipi dsi mode is different too, so add a
> of_device_id structure to distinguish them, and make sure set the
> correct mode before mipi phy init.
> 

Hi Chris,
There are a bunch of unrelated changes in this patch. Can you please split out
the whitespace/const changes into a separate clean-up patch so it's easier to
see the meaningful changes?

More comments below.

> Signed-off-by: Chris Zhong 
> Signed-off-by: Mark Yao 
> ---
> 
> Changes in v3:
> - base on John Keeping's patch series
> 
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 101 
> -
>  1 file changed, 74 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index 45af890..a93ce97 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -29,9 +29,17 @@
>  
>  #define DRIVER_NAME"dw-mipi-dsi"
>  
> -#define GRF_SOC_CON60x025c
> -#define DSI0_SEL_VOP_LIT(1 << 6)
> -#define DSI1_SEL_VOP_LIT(1 << 9)
> +#define RK3288_GRF_SOC_CON6  0x025c
> +#define RK3288_DSI0_SEL_VOP_LIT  BIT(6)
> +#define RK3288_DSI1_SEL_VOP_LIT  BIT(9)
> +
> +#define RK3399_GRF_SOC_CON19 0x6250
> +#define RK3399_DSI0_SEL_VOP_LIT  BIT(0)
> +#define RK3399_DSI1_SEL_VOP_LIT  BIT(4)
> +
> +/* disable turnrequest, turndisable, forcetxstopmode, forcerxmode */
> +#define RK3399_GRF_SOC_CON22 0x6258
> +#define RK3399_GRF_DSI_MODE  0x
>  
>  #define DSI_VERSION  0x00
>  #define DSI_PWR_UP   0x04
> @@ -149,7 +157,6 @@
>  #define LPRX_TO_CNT(p)   ((p) & 0x)
>  
>  #define DSI_BTA_TO_CNT   0x8c
> -

Unrelated whitespace change

>  #define DSI_LPCLK_CTRL   0x94
>  #define AUTO_CLKLANE_CTRLBIT(1)
>  #define PHY_TXREQUESTCLKHS   BIT(0)
> @@ -215,11 +222,11 @@
>  
>  #define HSFREQRANGE_SEL(val) (((val) & 0x3f) << 1)
>  
> -#define INPUT_DIVIDER(val)   ((val - 1) & 0x7f)
> +#define INPUT_DIVIDER(val)   (((val) - 1) & 0x7f)

Unrelated change

>  #define LOW_PROGRAM_EN   0
>  #define HIGH_PROGRAM_EN  BIT(7)
> -#define LOOP_DIV_LOW_SEL(val)((val - 1) & 0x1f)
> -#define LOOP_DIV_HIGH_SEL(val)   (((val - 1) >> 5) & 0x1f)
> +#define LOOP_DIV_LOW_SEL(val)(((val) - 1) & 0x1f)
> +#define LOOP_DIV_HIGH_SEL(val)   val) - 1) >> 5) & 0x1f)

This change doesn't adversely affect other platforms?

>  #define PLL_LOOP_DIV_EN  BIT(5)
>  #define PLL_INPUT_DIV_EN BIT(4)
>  
> @@ -265,6 +272,11 @@ enum {
>  };
>  
>  struct dw_mipi_dsi_plat_data {
> + u32 dsi0_en_bit;
> + u32 dsi1_en_bit;
> + u32 grf_switch_reg;
> + u32 grf_dsi0_mode;
> + u32 grf_dsi0_mode_reg;
>   unsigned int max_data_lanes;
>   enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
>  struct drm_display_mode *mode);
> @@ -281,6 +293,7 @@ struct dw_mipi_dsi {
>  
>   struct clk *pllref_clk;
>   struct clk *pclk;
> + struct clk *phy_cfg_clk;
>  
>   unsigned int lane_mbps; /* per lane */
>   u32 channel;
> @@ -356,6 +369,7 @@ static inline struct dw_mipi_dsi *encoder_to_dsi(struct 
> drm_encoder *encoder)
>  {
>   return container_of(encoder, struct dw_mipi_dsi, encoder);
>  }
> +
>  static inline void dsi_write(struct dw_mipi_dsi *dsi, u32 reg, u32 val)
>  {
>   writel(val, dsi->base + reg);
> @@ -367,7 +381,7 @@ static inline u32 dsi_read(struct dw_mipi_dsi *dsi, u32 
> reg)
>  }
>  
>  static void dw_mipi_dsi_phy_write(struct dw_mipi_dsi *dsi, u8 test_code,
> -  u8 test_data)
> +   u8 test_data)

Unrelated whitespace change

>  {
>   /*
>* With the falling edge on TESTCLK, the TESTDIN[7:0] signal content
> @@ -426,6 +440,14 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
>   dsi_write(dsi, DSI_PHY_TST_CTRL0, PHY_TESTCLR);
>   dsi_write(dsi, DSI_PHY_TST_CTRL0, PHY_UNTESTCLR);
>  
> + if (!IS_ERR(dsi->phy_cfg_clk)) {
> + ret = clk_prepare_enable(dsi->phy_cfg_clk);
> + if (ret) {
> + dev_err(dsi->dev, "Failed to enable phy_cfg_clk\n");
> + return ret;
> + }
> + }
> +
>   dw_mipi_dsi_phy_write(dsi, 0x10, BYPASS_VCO_RANGE |
>VCO_RANGE_CON_SEL(vco) |
>VCO_IN_CAP_CON_LOW |
> @@ -474,22 +496,23 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
>   dsi_write(dsi, DSI_PHY_RSTZ, PHY_ENFORCEPLL | 

Re: [PATCH v3 2/5] drm/rockchip/dsi: dw-mipi: support RK3399 mipi dsi

[Sean Paul]

On Fri, Jan 20, 2017 at 06:10:48PM +0800, Chris Zhong wrote:
> The vopb/vopl switch register of RK3399 mipi is different from RK3288,
> the default setting for mipi dsi mode is different too, so add a
> of_device_id structure to distinguish them, and make sure set the
> correct mode before mipi phy init.
> 

Hi Chris,
There are a bunch of unrelated changes in this patch. Can you please split out
the whitespace/const changes into a separate clean-up patch so it's easier to
see the meaningful changes?

More comments below.

> Signed-off-by: Chris Zhong 
> Signed-off-by: Mark Yao 
> ---
> 
> Changes in v3:
> - base on John Keeping's patch series
> 
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 101 
> -
>  1 file changed, 74 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index 45af890..a93ce97 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -29,9 +29,17 @@
>  
>  #define DRIVER_NAME"dw-mipi-dsi"
>  
> -#define GRF_SOC_CON60x025c
> -#define DSI0_SEL_VOP_LIT(1 << 6)
> -#define DSI1_SEL_VOP_LIT(1 << 9)
> +#define RK3288_GRF_SOC_CON6  0x025c
> +#define RK3288_DSI0_SEL_VOP_LIT  BIT(6)
> +#define RK3288_DSI1_SEL_VOP_LIT  BIT(9)
> +
> +#define RK3399_GRF_SOC_CON19 0x6250
> +#define RK3399_DSI0_SEL_VOP_LIT  BIT(0)
> +#define RK3399_DSI1_SEL_VOP_LIT  BIT(4)
> +
> +/* disable turnrequest, turndisable, forcetxstopmode, forcerxmode */
> +#define RK3399_GRF_SOC_CON22 0x6258
> +#define RK3399_GRF_DSI_MODE  0x
>  
>  #define DSI_VERSION  0x00
>  #define DSI_PWR_UP   0x04
> @@ -149,7 +157,6 @@
>  #define LPRX_TO_CNT(p)   ((p) & 0x)
>  
>  #define DSI_BTA_TO_CNT   0x8c
> -

Unrelated whitespace change

>  #define DSI_LPCLK_CTRL   0x94
>  #define AUTO_CLKLANE_CTRLBIT(1)
>  #define PHY_TXREQUESTCLKHS   BIT(0)
> @@ -215,11 +222,11 @@
>  
>  #define HSFREQRANGE_SEL(val) (((val) & 0x3f) << 1)
>  
> -#define INPUT_DIVIDER(val)   ((val - 1) & 0x7f)
> +#define INPUT_DIVIDER(val)   (((val) - 1) & 0x7f)

Unrelated change

>  #define LOW_PROGRAM_EN   0
>  #define HIGH_PROGRAM_EN  BIT(7)
> -#define LOOP_DIV_LOW_SEL(val)((val - 1) & 0x1f)
> -#define LOOP_DIV_HIGH_SEL(val)   (((val - 1) >> 5) & 0x1f)
> +#define LOOP_DIV_LOW_SEL(val)(((val) - 1) & 0x1f)
> +#define LOOP_DIV_HIGH_SEL(val)   val) - 1) >> 5) & 0x1f)

This change doesn't adversely affect other platforms?

>  #define PLL_LOOP_DIV_EN  BIT(5)
>  #define PLL_INPUT_DIV_EN BIT(4)
>  
> @@ -265,6 +272,11 @@ enum {
>  };
>  
>  struct dw_mipi_dsi_plat_data {
> + u32 dsi0_en_bit;
> + u32 dsi1_en_bit;
> + u32 grf_switch_reg;
> + u32 grf_dsi0_mode;
> + u32 grf_dsi0_mode_reg;
>   unsigned int max_data_lanes;
>   enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
>  struct drm_display_mode *mode);
> @@ -281,6 +293,7 @@ struct dw_mipi_dsi {
>  
>   struct clk *pllref_clk;
>   struct clk *pclk;
> + struct clk *phy_cfg_clk;
>  
>   unsigned int lane_mbps; /* per lane */
>   u32 channel;
> @@ -356,6 +369,7 @@ static inline struct dw_mipi_dsi *encoder_to_dsi(struct 
> drm_encoder *encoder)
>  {
>   return container_of(encoder, struct dw_mipi_dsi, encoder);
>  }
> +
>  static inline void dsi_write(struct dw_mipi_dsi *dsi, u32 reg, u32 val)
>  {
>   writel(val, dsi->base + reg);
> @@ -367,7 +381,7 @@ static inline u32 dsi_read(struct dw_mipi_dsi *dsi, u32 
> reg)
>  }
>  
>  static void dw_mipi_dsi_phy_write(struct dw_mipi_dsi *dsi, u8 test_code,
> -  u8 test_data)
> +   u8 test_data)

Unrelated whitespace change

>  {
>   /*
>* With the falling edge on TESTCLK, the TESTDIN[7:0] signal content
> @@ -426,6 +440,14 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
>   dsi_write(dsi, DSI_PHY_TST_CTRL0, PHY_TESTCLR);
>   dsi_write(dsi, DSI_PHY_TST_CTRL0, PHY_UNTESTCLR);
>  
> + if (!IS_ERR(dsi->phy_cfg_clk)) {
> + ret = clk_prepare_enable(dsi->phy_cfg_clk);
> + if (ret) {
> + dev_err(dsi->dev, "Failed to enable phy_cfg_clk\n");
> + return ret;
> + }
> + }
> +
>   dw_mipi_dsi_phy_write(dsi, 0x10, BYPASS_VCO_RANGE |
>VCO_RANGE_CON_SEL(vco) |
>VCO_IN_CAP_CON_LOW |
> @@ -474,22 +496,23 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
>   dsi_write(dsi, DSI_PHY_RSTZ, PHY_ENFORCEPLL | PHY_ENABLECLK |
>

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Borislav Petkov]

On Mon, Jan 23, 2017 at 09:21:03AM -0800, Christoph Hellwig wrote:
> Or keep the exported version as-is and never changed it, and use
> a different copy for the kernel itself.

Yeah, that's a good idea, thanks Christoph.

I guess we'll have to do that if something in userspace has put its
sticky fingers on that file and cannot be fixed. Which I hardly doubt
but we can't break that damn userspace.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Borislav Petkov]

On Mon, Jan 23, 2017 at 09:21:03AM -0800, Christoph Hellwig wrote:
> Or keep the exported version as-is and never changed it, and use
> a different copy for the kernel itself.

Yeah, that's a good idea, thanks Christoph.

I guess we'll have to do that if something in userspace has put its
sticky fingers on that file and cannot be fixed. Which I hardly doubt
but we can't break that damn userspace.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH] tpm_tis: use default timeout value if chip reports it as zero

[Maciej S. Szmigiero]

On 16.01.2017 17:39, Jarkko Sakkinen wrote:
> On Mon, Jan 16, 2017 at 03:58:26PM +0100, Maciej S. Szmigiero wrote:
>> On 16.01.2017 14:55, Jarkko Sakkinen wrote:
>>> On Mon, Jan 16, 2017 at 03:46:12PM +0200, Jarkko Sakkinen wrote:
 On Mon, Jan 16, 2017 at 11:42:02AM +0200, Jarkko Sakkinen wrote:
> On Fri, Jan 13, 2017 at 10:37:00PM +0100, Maciej S. Szmigiero wrote:
>> Since commit 1107d065fdf1 ("tpm_tis: Introduce intermediate layer for TPM
>> access") Atmel 3203 TPM on ThinkPad X61S (TPM firmware version 13.9) no
>> longer works.
>> The initialization proceeds fine until we get and start using 
>> chip-reported
>> timeouts - and the chip reports C and D timeouts of zero.
>>
>> It turns out that until commit 8e54caf407b98e ("tpm: Provide a generic
>> means to override the chip returned timeouts") we had actually let 
>> default
>> timeout values remain in this case, so let's bring back this behavior to
>> make chips like Atmel 3203 work again.
>>
>> Use a common code that was introduced by that commit so a warning is
>> printed in this case and /sys/class/tpm/tpm*/timeouts correctly says the
>> timeouts aren't chip-original.
>>
>> Signed-off-by: Maciej S. Szmigiero 
>>
>> Fixes: 1107d065fdf1 ("tpm_tis: Introduce intermediate layer for TPM 
>> access")
>> Cc: sta...@vger.kernel.org
>
> Reviewed-by: Jarkko Sakkinen 

 It's now applied to my master branch so if someone wants to
 test it, it should be fairly easy.
>>>
>>> And I decided to squash the rename commit to it.
>>
>> Wouldn't it be better to squash the rename commit into "fix iTPM probe via
>> probe_itpm() function" patch (if it isn't too late), since they touch the
>> same functionality?
> 
> It can be renamed, modified and even dropped as long as it is in my
> master branch and I haven't sent pull request to James Morris.

I see that "fix iTPM probe via probe_itpm() function" patch isn't present
in your pull request for 4.11.

What I meant in previous message was that you squashed and "rename
TPM_TIS_ITPM_POSSIBLE to TPM_TIS_ITPM_WORKAROUND" patch into "use default 
timeout
value if chip reports it as zero" patch while it was logically connected with
"fix iTPM probe via probe_itpm() function" patch instead (which now isn't 
present
at all in the tree).
Sorry if it wasn't 100% clear.

> /Jarkkok

Maciej

Re: [PATCH] tpm_tis: use default timeout value if chip reports it as zero

[Maciej S. Szmigiero]

On 16.01.2017 17:39, Jarkko Sakkinen wrote:
> On Mon, Jan 16, 2017 at 03:58:26PM +0100, Maciej S. Szmigiero wrote:
>> On 16.01.2017 14:55, Jarkko Sakkinen wrote:
>>> On Mon, Jan 16, 2017 at 03:46:12PM +0200, Jarkko Sakkinen wrote:
 On Mon, Jan 16, 2017 at 11:42:02AM +0200, Jarkko Sakkinen wrote:
> On Fri, Jan 13, 2017 at 10:37:00PM +0100, Maciej S. Szmigiero wrote:
>> Since commit 1107d065fdf1 ("tpm_tis: Introduce intermediate layer for TPM
>> access") Atmel 3203 TPM on ThinkPad X61S (TPM firmware version 13.9) no
>> longer works.
>> The initialization proceeds fine until we get and start using 
>> chip-reported
>> timeouts - and the chip reports C and D timeouts of zero.
>>
>> It turns out that until commit 8e54caf407b98e ("tpm: Provide a generic
>> means to override the chip returned timeouts") we had actually let 
>> default
>> timeout values remain in this case, so let's bring back this behavior to
>> make chips like Atmel 3203 work again.
>>
>> Use a common code that was introduced by that commit so a warning is
>> printed in this case and /sys/class/tpm/tpm*/timeouts correctly says the
>> timeouts aren't chip-original.
>>
>> Signed-off-by: Maciej S. Szmigiero 
>>
>> Fixes: 1107d065fdf1 ("tpm_tis: Introduce intermediate layer for TPM 
>> access")
>> Cc: sta...@vger.kernel.org
>
> Reviewed-by: Jarkko Sakkinen 

 It's now applied to my master branch so if someone wants to
 test it, it should be fairly easy.
>>>
>>> And I decided to squash the rename commit to it.
>>
>> Wouldn't it be better to squash the rename commit into "fix iTPM probe via
>> probe_itpm() function" patch (if it isn't too late), since they touch the
>> same functionality?
> 
> It can be renamed, modified and even dropped as long as it is in my
> master branch and I haven't sent pull request to James Morris.

I see that "fix iTPM probe via probe_itpm() function" patch isn't present
in your pull request for 4.11.

What I meant in previous message was that you squashed and "rename
TPM_TIS_ITPM_POSSIBLE to TPM_TIS_ITPM_WORKAROUND" patch into "use default 
timeout
value if chip reports it as zero" patch while it was logically connected with
"fix iTPM probe via probe_itpm() function" patch instead (which now isn't 
present
at all in the tree).
Sorry if it wasn't 100% clear.

> /Jarkkok

Maciej

Re: [tip:x86/urgent] x86/fpu: Set the xcomp_bv when we fake up a XSAVES area

[Dave Hansen]

On 01/23/2017 08:55 AM, Yu-cheng Yu wrote:
> On Mon, Jan 23, 2017 at 07:36:20AM -0800, Dave Hansen wrote:
>> The kernel xsave buffer should *ALWAYS* have the
>> XCOMP_BV_COMPACTED_FORMAT bit set.  It should have been set before the
>> copyin and it should be set when it's finished.
>>
>> The best fix here would be not to paper over the issue in the copy
>> function but find where it got clobbered, or where some initialization
>> code failed to set it.
> 
> Someone else reported different issues from the same bug and a different
> patch was just tested OK this morning.  I think that adding xfeatures bits
> to xcomp_bv should have been done in fpstate_init().

Right.  So where did it get cleared out?

> Also, in copy_init_fpstate_to_fpregs(), we do:
> 
>   copy_kernel_to_xregs(_fpstate.xsave, -1).
> 
> That (-1) could mean (0) because the parameters are declared as:
> 
>   copy_kernel_to_xregs(struct xregs_state *, u64)

I'm not sure what you're saying.  -1 just means "all 1's" when cast to
an unsigned type.  This shouldn't case any problems.

Re: [tip:x86/urgent] x86/fpu: Set the xcomp_bv when we fake up a XSAVES area

[Dave Hansen]

On 01/23/2017 08:55 AM, Yu-cheng Yu wrote:
> On Mon, Jan 23, 2017 at 07:36:20AM -0800, Dave Hansen wrote:
>> The kernel xsave buffer should *ALWAYS* have the
>> XCOMP_BV_COMPACTED_FORMAT bit set.  It should have been set before the
>> copyin and it should be set when it's finished.
>>
>> The best fix here would be not to paper over the issue in the copy
>> function but find where it got clobbered, or where some initialization
>> code failed to set it.
> 
> Someone else reported different issues from the same bug and a different
> patch was just tested OK this morning.  I think that adding xfeatures bits
> to xcomp_bv should have been done in fpstate_init().

Right.  So where did it get cleared out?

> Also, in copy_init_fpstate_to_fpregs(), we do:
> 
>   copy_kernel_to_xregs(_fpstate.xsave, -1).
> 
> That (-1) could mean (0) because the parameters are declared as:
> 
>   copy_kernel_to_xregs(struct xregs_state *, u64)

I'm not sure what you're saying.  -1 just means "all 1's" when cast to
an unsigned type.  This shouldn't case any problems.

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Christoph Hellwig]

On Mon, Jan 23, 2017 at 06:17:32PM +0100, Borislav Petkov wrote:
> I know, we should not ever break userspace but if it were me, I'd remove
> that export and see what breaks. If at all.

Or keep the exported version as-is and never changed it, and use
a different copy for the kernel itself.

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Christoph Hellwig]

On Mon, Jan 23, 2017 at 06:17:32PM +0100, Borislav Petkov wrote:
> I know, we should not ever break userspace but if it were me, I'd remove
> that export and see what breaks. If at all.

Or keep the exported version as-is and never changed it, and use
a different copy for the kernel itself.

Re: BUG: KASAN: Use-after-free

[Christoph Hellwig]

On Mon, Jan 23, 2017 at 05:07:52PM +0100, Matias Bjørling wrote:
> Hi,
> 
> I could use some help verifying an use-after-free bug that I am seeing
> after the new direct I/O work went in.
> 
> When issuing a direct write io using libaio, a bio is referenced in the
> blkdev_direct_IO path, and then put again in the blkdev_bio_end_io path.
> However, there is a case where the bio is put twice, which leads to
> modules that rely on the bio after biodev_bio_end_io() to access it
> prematurely.

Can you reproduce anything like this with a normal block device?

> 
> The KASAN error report:
> 
> [   14.645916]
> ==
> [   14.648027] BUG: KASAN: use-after-free in
> blkdev_direct_IO+0x50c/0x600 at addr 8801ef30ea14

Can you resolve that address for me, please?

> Which boils down to the bio already being freed, when we hit the
> module's endio function.
> 
> The double bio_put() occurs when dio->should_dirty = 0, and dio->is_sync
> = 0. The flow follows:
> 
> Issuing:
>   blkdev_direct_IO
>  get_bio(bio)

bio refcounting in __blkdev_direct_IO is the following

first bio is allocated using bio_alloc_bioset to embedd the dio structure
into it.  We then grab a second reference to that bio and only that one.
Each other new bio just gets it's single reference from bio_alloc.

blkdev_bio_end_io then checks if we hit the last reference on the dio, in
which case it then drops the additional reference on the first bio after
calling the aio completion handler.  Once that is done it always drops the
reference for the current bio - either explicitly or through
bio_check_pages_dirty in the should_dirty case.

>  submit_io()
>rrpc make_request(bio)
>  get_bio(bio)
> Completion:
>   blkdev_bio_end_io
> bio_put(bio)
> bio_put(bio) - bio is freed

Yes, and that's how it's intended.

>   rrpc_end_io
> bio_put(bio) (use-after-free access)

Can you check this is the same bio that got submitted and it didn't
get bounced somewhere?

Re: BUG: KASAN: Use-after-free

[Christoph Hellwig]

On Mon, Jan 23, 2017 at 05:07:52PM +0100, Matias Bjørling wrote:
> Hi,
> 
> I could use some help verifying an use-after-free bug that I am seeing
> after the new direct I/O work went in.
> 
> When issuing a direct write io using libaio, a bio is referenced in the
> blkdev_direct_IO path, and then put again in the blkdev_bio_end_io path.
> However, there is a case where the bio is put twice, which leads to
> modules that rely on the bio after biodev_bio_end_io() to access it
> prematurely.

Can you reproduce anything like this with a normal block device?

> 
> The KASAN error report:
> 
> [   14.645916]
> ==
> [   14.648027] BUG: KASAN: use-after-free in
> blkdev_direct_IO+0x50c/0x600 at addr 8801ef30ea14

Can you resolve that address for me, please?

> Which boils down to the bio already being freed, when we hit the
> module's endio function.
> 
> The double bio_put() occurs when dio->should_dirty = 0, and dio->is_sync
> = 0. The flow follows:
> 
> Issuing:
>   blkdev_direct_IO
>  get_bio(bio)

bio refcounting in __blkdev_direct_IO is the following

first bio is allocated using bio_alloc_bioset to embedd the dio structure
into it.  We then grab a second reference to that bio and only that one.
Each other new bio just gets it's single reference from bio_alloc.

blkdev_bio_end_io then checks if we hit the last reference on the dio, in
which case it then drops the additional reference on the first bio after
calling the aio completion handler.  Once that is done it always drops the
reference for the current bio - either explicitly or through
bio_check_pages_dirty in the should_dirty case.

>  submit_io()
>rrpc make_request(bio)
>  get_bio(bio)
> Completion:
>   blkdev_bio_end_io
> bio_put(bio)
> bio_put(bio) - bio is freed

Yes, and that's how it's intended.

>   rrpc_end_io
> bio_put(bio) (use-after-free access)

Can you check this is the same bio that got submitted and it didn't
get bounced somewhere?

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Borislav Petkov]

On Mon, Jan 23, 2017 at 06:06:52PM +0100, Nicolas Dichtel wrote:
> After digging a bit, it seems you have already tried to remove it in commit
> b72e7464e4cf ("x86/uapi: Do not export  as part of the user 
> API
> headers"), but because this file is still listed in the Kbuild file, it is 
> still
> exported.

Oh great. :-\

> It would be great if we could find a consensus about what to do with
> this file because it blocks patch #4 and the rest of the series.

The reasoning in b72e7464e4cf was valid then and is valid now. This
thing should not have been exported in the first place. And it's not
like I didn't try then. Dammit!

I know, we should not ever break userspace but if it were me, I'd remove
that export and see what breaks. If at all.

But let's see what the others think first.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Borislav Petkov]

On Mon, Jan 23, 2017 at 06:06:52PM +0100, Nicolas Dichtel wrote:
> After digging a bit, it seems you have already tried to remove it in commit
> b72e7464e4cf ("x86/uapi: Do not export  as part of the user 
> API
> headers"), but because this file is still listed in the Kbuild file, it is 
> still
> exported.

Oh great. :-\

> It would be great if we could find a consensus about what to do with
> this file because it blocks patch #4 and the rest of the series.

The reasoning in b72e7464e4cf was valid then and is valid now. This
thing should not have been exported in the first place. And it's not
like I didn't try then. Dammit!

I know, we should not ever break userspace but if it were me, I'd remove
that export and see what breaks. If at all.

But let's see what the others think first.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm

[Dan Williams]

On Mon, Jan 23, 2017 at 8:00 AM, Christoph Hellwig  wrote:
> On Sun, Jan 22, 2017 at 11:10:04PM -0800, Dan Williams wrote:
>> How about we solve the copy_from_user() abuse first before we hijack
>> this thread for some future feature that afaics has no patches posted
>> yet.
>
> Solving copy_from_user abuse first sounds perfectly fine to me.  But
> please do so without abusing the block layer for persistent memory
> access.  Given that we don't have use cases for different pmem access
> methods in a single OS image yet let's avoid introducing new ops
> for now and just remove the copy_from_user abuse.

The use case that we have now is distinguishing volatile vs persistent
memory (brd vs pmem).

I took a look at mtd layering approach and the main difference is that
layers above the block layer do not appear to know anything about mtd
specifics. For fs/dax.c we currently need some path to retrieve a dax
anchor object through the block device.

> In the longer run I like your dax_operations, but they need to be
> separate from the block layer.

I'll move them from block_device_operations to dax data hanging off of
the bdev_inode, or is there a better way to go from bdev-to-dax?

Re: [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm

[Dan Williams]

On Mon, Jan 23, 2017 at 8:00 AM, Christoph Hellwig  wrote:
> On Sun, Jan 22, 2017 at 11:10:04PM -0800, Dan Williams wrote:
>> How about we solve the copy_from_user() abuse first before we hijack
>> this thread for some future feature that afaics has no patches posted
>> yet.
>
> Solving copy_from_user abuse first sounds perfectly fine to me.  But
> please do so without abusing the block layer for persistent memory
> access.  Given that we don't have use cases for different pmem access
> methods in a single OS image yet let's avoid introducing new ops
> for now and just remove the copy_from_user abuse.

The use case that we have now is distinguishing volatile vs persistent
memory (brd vs pmem).

I took a look at mtd layering approach and the main difference is that
layers above the block layer do not appear to know anything about mtd
specifics. For fs/dax.c we currently need some path to retrieve a dax
anchor object through the block device.

> In the longer run I like your dax_operations, but they need to be
> separate from the block layer.

I'll move them from block_device_operations to dax data hanging off of
the bdev_inode, or is there a better way to go from bdev-to-dax?

Re: [PATCH v3 0/3] Init device ids from ACPI of_compatible

[Andy Shevchenko]

On Mon, Jan 23, 2017 at 6:08 PM, Dan O'Donovan  wrote:
> (Re-submitting this patch set originally created by Leonard Crestez,
> possibly abandoned by Leonard due to a change in employment)
>
> When using devicetree, stuff like i2c_client.name or spi_device.modalias
> is initialized to the first DT compatible id with the vendor prefix
> stripped. Since some drivers rely on this in order to differentiate between
> hardware variants try to replicate it when using ACPI with DT ids.
>
> This also makes it so that the i2c_device_id parameter passed to probe is
> non-NULL when matching with ACPI and DT ids.
>
> Tested using ACPI overlays but there is no actual dependency. This series
> just extends the PRP0001 feature to be more useful for I2C/SPI.
>
> The patches only touches the ACPI-specific parts of the i2c and spi core.

The series looks good. Few nitpicks in the comments of corresponding
patches though.
FWIW:
Reviewed-by: Andy Shevchenko 

>
> Here is an example .dsl for an SPI accelerometer connected to minnowboard max:
>
> Device (ACCL)
> {
> Name (_ADR, Zero)
> Name (_HID, "PRP0001")
> Name (_UID, One)
>
> Method (_CRS, 0, Serialized)
> {
> Name (RBUF, ResourceTemplate ()
> {
> SPISerialBus(1, PolarityLow, FourWireMode, 16,
> ControllerInitiated, 100, ClockPolarityLow,
> ClockPhaseFirst, "\\_SB.SPI1",)
> GpioInt (Edge, ActiveHigh, Exclusive, PullDown, 0x,
>  "\\_SB.GPO2", 0x00, ResourceConsumer, , )
> { // Pin list
> 1
> }
> })
> Return (RBUF)
> }
> Name (_DSD, Package ()
> {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package ()
> {
> Package () {"compatible", "st,lis3dh"},
> }
> })
> }
>
> Link to v2: https://lkml.org/lkml/2016/7/13/392
> Changes:
>  * Use appropriate subject prefix for each subsystem (Mark Brown)
>  * Use ACPI info as before if getting OF info fails (Mark Brown)
>  * Minor cosmetic/readability improvements (Rafael J. Wysocki)
>
> Link to v1: https://www.spinics.net/lists/linux-acpi/msg66469.html
> Changes:
>  * Rebase on after acpi overlays got it.
>  * Change acpi_of_modalias outlen param to size_t
>  * Use {} after else
>
> Crestez Dan Leonard (3):
>   ACPI / bus: Export acpi_of_modalias equiv of of_modalias_node
>   i2c: acpi: Initialize info.type from of_compatible
>   spi: acpi: Initialize modalias from of_compatible
>
>  drivers/acpi/bus.c  | 35 +++
>  drivers/i2c/i2c-core.c  |  8 +++-
>  drivers/spi/spi.c   | 10 +-
>  include/acpi/acpi_bus.h |  1 +
>  4 files changed, 52 insertions(+), 2 deletions(-)
>
> --
> 2.7.4
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 0/3] Init device ids from ACPI of_compatible

[Andy Shevchenko]

On Mon, Jan 23, 2017 at 6:08 PM, Dan O'Donovan  wrote:
> (Re-submitting this patch set originally created by Leonard Crestez,
> possibly abandoned by Leonard due to a change in employment)
>
> When using devicetree, stuff like i2c_client.name or spi_device.modalias
> is initialized to the first DT compatible id with the vendor prefix
> stripped. Since some drivers rely on this in order to differentiate between
> hardware variants try to replicate it when using ACPI with DT ids.
>
> This also makes it so that the i2c_device_id parameter passed to probe is
> non-NULL when matching with ACPI and DT ids.
>
> Tested using ACPI overlays but there is no actual dependency. This series
> just extends the PRP0001 feature to be more useful for I2C/SPI.
>
> The patches only touches the ACPI-specific parts of the i2c and spi core.

The series looks good. Few nitpicks in the comments of corresponding
patches though.
FWIW:
Reviewed-by: Andy Shevchenko 

>
> Here is an example .dsl for an SPI accelerometer connected to minnowboard max:
>
> Device (ACCL)
> {
> Name (_ADR, Zero)
> Name (_HID, "PRP0001")
> Name (_UID, One)
>
> Method (_CRS, 0, Serialized)
> {
> Name (RBUF, ResourceTemplate ()
> {
> SPISerialBus(1, PolarityLow, FourWireMode, 16,
> ControllerInitiated, 100, ClockPolarityLow,
> ClockPhaseFirst, "\\_SB.SPI1",)
> GpioInt (Edge, ActiveHigh, Exclusive, PullDown, 0x,
>  "\\_SB.GPO2", 0x00, ResourceConsumer, , )
> { // Pin list
> 1
> }
> })
> Return (RBUF)
> }
> Name (_DSD, Package ()
> {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package ()
> {
> Package () {"compatible", "st,lis3dh"},
> }
> })
> }
>
> Link to v2: https://lkml.org/lkml/2016/7/13/392
> Changes:
>  * Use appropriate subject prefix for each subsystem (Mark Brown)
>  * Use ACPI info as before if getting OF info fails (Mark Brown)
>  * Minor cosmetic/readability improvements (Rafael J. Wysocki)
>
> Link to v1: https://www.spinics.net/lists/linux-acpi/msg66469.html
> Changes:
>  * Rebase on after acpi overlays got it.
>  * Change acpi_of_modalias outlen param to size_t
>  * Use {} after else
>
> Crestez Dan Leonard (3):
>   ACPI / bus: Export acpi_of_modalias equiv of of_modalias_node
>   i2c: acpi: Initialize info.type from of_compatible
>   spi: acpi: Initialize modalias from of_compatible
>
>  drivers/acpi/bus.c  | 35 +++
>  drivers/i2c/i2c-core.c  |  8 +++-
>  drivers/spi/spi.c   | 10 +-
>  include/acpi/acpi_bus.h |  1 +
>  4 files changed, 52 insertions(+), 2 deletions(-)
>
> --
> 2.7.4
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 0/9] Implement clocksource for rockchip SoC using rockchip timer

[Heiko Stübner]

Am Montag, 23. Januar 2017, 15:47:44 CET schrieb Daniel Lezcano:
> On Wed, Dec 21, 2016 at 05:21:05PM +0300, Alexander Kochetkov wrote:
> > Hello Heiko, Daniel!
> > 
> > Are there any reasons why the patches [1][2] are not applied yet into
> > kernel? How can I help in applying patches?
> 
> Hi Alexander,
> 
> sorry for the delay. Let me review them before taking the patchset.
> 
> Heiko, can you have a look to them also ?

somehow this series moved down to much in my inbox, sorry.

Devicetree changes look good, except where I commented.
I guess it would be best (least intrusive) if I queue up the (then fixed) 
devicetree changes after you are satisfied with the code parts.

I've also looked over the code changes again, test-build them and found the 
build error mentioned separately. Overall they look good though.


Heiko

Re: [PATCH v4 0/9] Implement clocksource for rockchip SoC using rockchip timer

[Heiko Stübner]

Am Montag, 23. Januar 2017, 15:47:44 CET schrieb Daniel Lezcano:
> On Wed, Dec 21, 2016 at 05:21:05PM +0300, Alexander Kochetkov wrote:
> > Hello Heiko, Daniel!
> > 
> > Are there any reasons why the patches [1][2] are not applied yet into
> > kernel? How can I help in applying patches?
> 
> Hi Alexander,
> 
> sorry for the delay. Let me review them before taking the patchset.
> 
> Heiko, can you have a look to them also ?

somehow this series moved down to much in my inbox, sorry.

Devicetree changes look good, except where I commented.
I guess it would be best (least intrusive) if I queue up the (then fixed) 
devicetree changes after you are satisfied with the code parts.

I've also looked over the code changes again, test-build them and found the 
build error mentioned separately. Overall they look good though.


Heiko

[PATCH v6 14/14] ARM: dts: da850-lcdk: enable the SATA node

[Bartosz Golaszewski]

Enable the SATA node for da850-lcdk. We omit the pinctrl property on
purpose - the muxed SATA pins are not hooked up to anything
SATA-related on the lcdk.

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/boot/dts/da850-lcdk.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index afcb482..fbeee3c 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -105,6 +105,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
-- 
2.9.3

[PATCH v6 10/14] sata: ahci-da850: add a workaround for controller instability

[Bartosz Golaszewski]

We have a use case with the da850 SATA controller where at PLL0
frequency of 456MHz (needed to properly service the LCD controller)
the chip becomes unstable and the hardreset operation is ignored the
first time 50% of times.

The sata core driver already retries to resume the link because some
controllers ignore writes to the SControl register, but just retrying
the resume operation doesn't work - we need to issue he phy/wake reset
again to make it work.

Reimplement ahci_hardreset() in the driver and poke the controller a
couple times before really giving up.

Signed-off-by: Bartosz Golaszewski 
Acked-by: Tejun Heo 
---
 drivers/ata/ahci_da850.c | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/ahci_da850.c b/drivers/ata/ahci_da850.c
index 11dd87e..0b2b1a4 100644
--- a/drivers/ata/ahci_da850.c
+++ b/drivers/ata/ahci_da850.c
@@ -16,7 +16,8 @@
 #include 
 #include "ahci.h"
 
-#define DRV_NAME "ahci_da850"
+#define DRV_NAME   "ahci_da850"
+#define HARDRESET_RETRIES  5
 
 /* SATA PHY Control Register offset from AHCI base */
 #define SATA_P0PHYCR_REG   0x178
@@ -76,6 +77,29 @@ static int ahci_da850_softreset(struct ata_link *link,
return ret;
 }
 
+static int ahci_da850_hardreset(struct ata_link *link,
+   unsigned int *class, unsigned long deadline)
+{
+   int ret, retry = HARDRESET_RETRIES;
+   bool online;
+
+   /*
+* In order to correctly service the LCD controller of the da850 SoC,
+* we increased the PLL0 frequency to 456MHz from the default 300MHz.
+*
+* This made the SATA controller unstable and the hardreset operation
+* does not always succeed the first time. Before really giving up to
+* bring up the link, retry the reset a couple times.
+*/
+   do {
+   ret = ahci_do_hardreset(link, class, deadline, );
+   if (online)
+   return ret;
+   } while (retry--);
+
+   return ret;
+}
+
 static struct ata_port_operations ahci_da850_port_ops = {
.inherits = _platform_ops,
.softreset = ahci_da850_softreset,
@@ -83,6 +107,8 @@ static struct ata_port_operations ahci_da850_port_ops = {
 * No need to override .pmp_softreset - it's only used for actual
 * PMP-enabled ports.
 */
+   .hardreset = ahci_da850_hardreset,
+   .pmp_hardreset = ahci_da850_hardreset,
 };
 
 static const struct ata_port_info ahci_da850_port_info = {
-- 
2.9.3

[PATCH v6 14/14] ARM: dts: da850-lcdk: enable the SATA node

[Bartosz Golaszewski]

Enable the SATA node for da850-lcdk. We omit the pinctrl property on
purpose - the muxed SATA pins are not hooked up to anything
SATA-related on the lcdk.

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/boot/dts/da850-lcdk.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index afcb482..fbeee3c 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -105,6 +105,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
-- 
2.9.3

[PATCH v6 10/14] sata: ahci-da850: add a workaround for controller instability

[Bartosz Golaszewski]

We have a use case with the da850 SATA controller where at PLL0
frequency of 456MHz (needed to properly service the LCD controller)
the chip becomes unstable and the hardreset operation is ignored the
first time 50% of times.

The sata core driver already retries to resume the link because some
controllers ignore writes to the SControl register, but just retrying
the resume operation doesn't work - we need to issue he phy/wake reset
again to make it work.

Reimplement ahci_hardreset() in the driver and poke the controller a
couple times before really giving up.

Signed-off-by: Bartosz Golaszewski 
Acked-by: Tejun Heo 
---
 drivers/ata/ahci_da850.c | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/ahci_da850.c b/drivers/ata/ahci_da850.c
index 11dd87e..0b2b1a4 100644
--- a/drivers/ata/ahci_da850.c
+++ b/drivers/ata/ahci_da850.c
@@ -16,7 +16,8 @@
 #include 
 #include "ahci.h"
 
-#define DRV_NAME "ahci_da850"
+#define DRV_NAME   "ahci_da850"
+#define HARDRESET_RETRIES  5
 
 /* SATA PHY Control Register offset from AHCI base */
 #define SATA_P0PHYCR_REG   0x178
@@ -76,6 +77,29 @@ static int ahci_da850_softreset(struct ata_link *link,
return ret;
 }
 
+static int ahci_da850_hardreset(struct ata_link *link,
+   unsigned int *class, unsigned long deadline)
+{
+   int ret, retry = HARDRESET_RETRIES;
+   bool online;
+
+   /*
+* In order to correctly service the LCD controller of the da850 SoC,
+* we increased the PLL0 frequency to 456MHz from the default 300MHz.
+*
+* This made the SATA controller unstable and the hardreset operation
+* does not always succeed the first time. Before really giving up to
+* bring up the link, retry the reset a couple times.
+*/
+   do {
+   ret = ahci_do_hardreset(link, class, deadline, );
+   if (online)
+   return ret;
+   } while (retry--);
+
+   return ret;
+}
+
 static struct ata_port_operations ahci_da850_port_ops = {
.inherits = _platform_ops,
.softreset = ahci_da850_softreset,
@@ -83,6 +107,8 @@ static struct ata_port_operations ahci_da850_port_ops = {
 * No need to override .pmp_softreset - it's only used for actual
 * PMP-enabled ports.
 */
+   .hardreset = ahci_da850_hardreset,
+   .pmp_hardreset = ahci_da850_hardreset,
 };
 
 static const struct ata_port_info ahci_da850_port_info = {
-- 
2.9.3

[PATCH v6 08/14] sata: ahci-da850: implement a workaround for the softreset quirk

[Bartosz Golaszewski]

There's an issue with the da850 SATA controller: if port multiplier
support is compiled in, but we're connecting the drive directly to
the SATA port on the board, the drive can't be detected.

To make SATA work on the da850-lcdk board: first try to softreset
with pmp - if the operation fails with -EBUSY, retry without pmp.

Signed-off-by: Bartosz Golaszewski 
Acked-by: Tejun Heo 
---
 drivers/ata/ahci_da850.c | 33 -
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/ahci_da850.c b/drivers/ata/ahci_da850.c
index 7f5328f..11dd87e 100644
--- a/drivers/ata/ahci_da850.c
+++ b/drivers/ata/ahci_da850.c
@@ -54,11 +54,42 @@ static void da850_sata_init(struct device *dev, void 
__iomem *pwrdn_reg,
writel(val, ahci_base + SATA_P0PHYCR_REG);
 }
 
+static int ahci_da850_softreset(struct ata_link *link,
+   unsigned int *class, unsigned long deadline)
+{
+   int pmp, ret;
+
+   pmp = sata_srst_pmp(link);
+
+   /*
+* There's an issue with the SATA controller on da850 SoCs: if we
+* enable Port Multiplier support, but the drive is connected directly
+* to the board, it can't be detected. As a workaround: if PMP is
+* enabled, we first call ahci_do_softreset() and pass it the result of
+* sata_srst_pmp(). If this call fails, we retry with pmp = 0.
+*/
+   ret = ahci_do_softreset(link, class, pmp, deadline, ahci_check_ready);
+   if (pmp && ret == -EBUSY)
+   return ahci_do_softreset(link, class, 0,
+deadline, ahci_check_ready);
+
+   return ret;
+}
+
+static struct ata_port_operations ahci_da850_port_ops = {
+   .inherits = _platform_ops,
+   .softreset = ahci_da850_softreset,
+   /*
+* No need to override .pmp_softreset - it's only used for actual
+* PMP-enabled ports.
+*/
+};
+
 static const struct ata_port_info ahci_da850_port_info = {
.flags  = AHCI_FLAG_COMMON,
.pio_mask   = ATA_PIO4,
.udma_mask  = ATA_UDMA6,
-   .port_ops   = _platform_ops,
+   .port_ops   = _da850_port_ops,
 };
 
 static struct scsi_host_template ahci_platform_sht = {
-- 
2.9.3

[PATCH v6 08/14] sata: ahci-da850: implement a workaround for the softreset quirk

[Bartosz Golaszewski]

There's an issue with the da850 SATA controller: if port multiplier
support is compiled in, but we're connecting the drive directly to
the SATA port on the board, the drive can't be detected.

To make SATA work on the da850-lcdk board: first try to softreset
with pmp - if the operation fails with -EBUSY, retry without pmp.

Signed-off-by: Bartosz Golaszewski 
Acked-by: Tejun Heo 
---
 drivers/ata/ahci_da850.c | 33 -
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/ahci_da850.c b/drivers/ata/ahci_da850.c
index 7f5328f..11dd87e 100644
--- a/drivers/ata/ahci_da850.c
+++ b/drivers/ata/ahci_da850.c
@@ -54,11 +54,42 @@ static void da850_sata_init(struct device *dev, void 
__iomem *pwrdn_reg,
writel(val, ahci_base + SATA_P0PHYCR_REG);
 }
 
+static int ahci_da850_softreset(struct ata_link *link,
+   unsigned int *class, unsigned long deadline)
+{
+   int pmp, ret;
+
+   pmp = sata_srst_pmp(link);
+
+   /*
+* There's an issue with the SATA controller on da850 SoCs: if we
+* enable Port Multiplier support, but the drive is connected directly
+* to the board, it can't be detected. As a workaround: if PMP is
+* enabled, we first call ahci_do_softreset() and pass it the result of
+* sata_srst_pmp(). If this call fails, we retry with pmp = 0.
+*/
+   ret = ahci_do_softreset(link, class, pmp, deadline, ahci_check_ready);
+   if (pmp && ret == -EBUSY)
+   return ahci_do_softreset(link, class, 0,
+deadline, ahci_check_ready);
+
+   return ret;
+}
+
+static struct ata_port_operations ahci_da850_port_ops = {
+   .inherits = _platform_ops,
+   .softreset = ahci_da850_softreset,
+   /*
+* No need to override .pmp_softreset - it's only used for actual
+* PMP-enabled ports.
+*/
+};
+
 static const struct ata_port_info ahci_da850_port_info = {
.flags  = AHCI_FLAG_COMMON,
.pio_mask   = ATA_PIO4,
.udma_mask  = ATA_UDMA6,
-   .port_ops   = _platform_ops,
+   .port_ops   = _da850_port_ops,
 };
 
 static struct scsi_host_template ahci_platform_sht = {
-- 
2.9.3

Re: [PATCH v3 3/3] spi: acpi: Initialize modalias from of_compatible

[Andy Shevchenko]

On Mon, Jan 23, 2017 at 6:08 PM, Dan O'Donovan  wrote:
> From: Crestez Dan Leonard 
>
> When using devicetree spi_device.modalias is set to the compatible
> string with the vendor prefix removed. For SPI devices described via
> ACPI the spi_device.modalias string is initialized by acpi_device_hid.
> When using ACPI and DT ids this string ends up something like "PRP0001".
>
> Change acpi_register_spi_device to use the of_compatible property if
> present. This makes it easier to instantiate spi drivers through ACPI
> with DT ids.

> +   /*
> +* Populate modalias from compatible property if available,
> +* otherwise use native ACPI information
> +*/
> +   if ((!adev->data.of_compatible) ||
> +   acpi_of_modalias(adev, spi->modalias, sizeof(spi->modalias)))

Same comment as in patch 2.

> +   strlcpy(spi->modalias, acpi_device_hid(adev),
> +   sizeof(spi->modalias));

Could this be one line?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 3/3] spi: acpi: Initialize modalias from of_compatible

[Andy Shevchenko]

On Mon, Jan 23, 2017 at 6:08 PM, Dan O'Donovan  wrote:
> From: Crestez Dan Leonard 
>
> When using devicetree spi_device.modalias is set to the compatible
> string with the vendor prefix removed. For SPI devices described via
> ACPI the spi_device.modalias string is initialized by acpi_device_hid.
> When using ACPI and DT ids this string ends up something like "PRP0001".
>
> Change acpi_register_spi_device to use the of_compatible property if
> present. This makes it easier to instantiate spi drivers through ACPI
> with DT ids.

> +   /*
> +* Populate modalias from compatible property if available,
> +* otherwise use native ACPI information
> +*/
> +   if ((!adev->data.of_compatible) ||
> +   acpi_of_modalias(adev, spi->modalias, sizeof(spi->modalias)))

Same comment as in patch 2.

> +   strlcpy(spi->modalias, acpi_device_hid(adev),
> +   sizeof(spi->modalias));

Could this be one line?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 3/3] pinctrl / gpio: Introduce .set_config() callback for GPIO chips

[Johan Hovold]

On Mon, Jan 23, 2017 at 03:34:34PM +0300, Mika Westerberg wrote:
> Currently we already have two pin configuration related callbacks
> available for GPIO chips .set_single_ended() and .set_debounce(). In
> future we expect to have even more, which does not scale well if we need
> to add yet another callback to the GPIO chip structure for each possible
> configuration parameter.
> 
> Better solution is to reuse what we already have available in the
> generic pinconf.
> 
> To support this, we introduce a new .set_config() callback for GPIO
> chips. The callback takes a single packed pin configuration value as
> parameter. This can then be extended easily beyond what is currently
> supported by just adding new types to the generic pinconf enum.
> 
> If the GPIO driver is backed up by a pinctrl driver the GPIO driver can
> just assign gpiochip_generic_config() (introduced in this patch) to
> .set_config and that will take care configuration requests are directed
> to the pinctrl driver.
> 
> We then convert the existing drivers over .set_config() and finally
> remove the .set_single_ended() and .set_debounce() callbacks.
> 
> Suggested-by: Linus Walleij 
> Signed-off-by: Mika Westerberg 
> ---
>  Documentation/gpio/driver.txt |  9 +++--
>  drivers/gpio/gpio-bcm-kona.c  | 14 ++-
>  drivers/gpio/gpio-dln2.c  | 12 --
>  drivers/gpio/gpio-dwapb.c | 14 ++-
>  drivers/gpio/gpio-ep93xx.c| 11 --
>  drivers/gpio/gpio-f7188x.c| 19 +
>  drivers/gpio/gpio-lp873x.c| 14 +++
>  drivers/gpio/gpio-max77620.c  | 20 +-
>  drivers/gpio/gpio-menz127.c   | 34 +++-
>  drivers/gpio/gpio-merrifield.c| 14 ++-
>  drivers/gpio/gpio-omap.c  | 14 ++-
>  drivers/gpio/gpio-tc3589x.c   | 15 ---
>  drivers/gpio/gpio-tegra.c | 14 ++-
>  drivers/gpio/gpio-tps65218.c  | 14 +++
>  drivers/gpio/gpio-vx855.c | 13 ---
>  drivers/gpio/gpio-wcove.c | 13 +++
>  drivers/gpio/gpio-wm831x.c| 21 +-
>  drivers/gpio/gpio-wm8994.c| 13 +++
>  drivers/gpio/gpiolib.c| 56 
> +--
>  drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 14 ++-
>  drivers/pinctrl/pinctrl-amd.c | 14 ++-
>  drivers/pinctrl/pinctrl-sx150x.c  | 55 +++---
>  drivers/staging/greybus/gpio.c| 15 ---
>  drivers/usb/serial/cp210x.c   | 13 ---

For greybus and USB serial:

Acked-by: Johan Hovold 

Note however that this patch fails to apply to linux-next (conflicts in
pinctrl as well as staging).

Thanks,
Johan

[PATCH v6 07/14] sata: ahci-da850: add device tree match table

[Bartosz Golaszewski]

We're using device tree for da850-lcdk. Add the match table to allow
to probe the driver.

Signed-off-by: Bartosz Golaszewski 
Acked-by: Tejun Heo 
---
 drivers/ata/ahci_da850.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/ata/ahci_da850.c b/drivers/ata/ahci_da850.c
index 8cfdc86..7f5328f 100644
--- a/drivers/ata/ahci_da850.c
+++ b/drivers/ata/ahci_da850.c
@@ -121,11 +121,18 @@ static int ahci_da850_probe(struct platform_device *pdev)
 static SIMPLE_DEV_PM_OPS(ahci_da850_pm_ops, ahci_platform_suspend,
 ahci_platform_resume);
 
+static const struct of_device_id ahci_da850_of_match[] = {
+   { .compatible = "ti,da850-ahci", },
+   { },
+};
+MODULE_DEVICE_TABLE(of, ahci_da850_of_match);
+
 static struct platform_driver ahci_da850_driver = {
.probe = ahci_da850_probe,
.remove = ata_platform_remove_one,
.driver = {
.name = DRV_NAME,
+   .of_match_table = ahci_da850_of_match,
.pm = _da850_pm_ops,
},
 };
-- 
2.9.3

Re: [PATCH v2 3/3] pinctrl / gpio: Introduce .set_config() callback for GPIO chips

[Johan Hovold]

On Mon, Jan 23, 2017 at 03:34:34PM +0300, Mika Westerberg wrote:
> Currently we already have two pin configuration related callbacks
> available for GPIO chips .set_single_ended() and .set_debounce(). In
> future we expect to have even more, which does not scale well if we need
> to add yet another callback to the GPIO chip structure for each possible
> configuration parameter.
> 
> Better solution is to reuse what we already have available in the
> generic pinconf.
> 
> To support this, we introduce a new .set_config() callback for GPIO
> chips. The callback takes a single packed pin configuration value as
> parameter. This can then be extended easily beyond what is currently
> supported by just adding new types to the generic pinconf enum.
> 
> If the GPIO driver is backed up by a pinctrl driver the GPIO driver can
> just assign gpiochip_generic_config() (introduced in this patch) to
> .set_config and that will take care configuration requests are directed
> to the pinctrl driver.
> 
> We then convert the existing drivers over .set_config() and finally
> remove the .set_single_ended() and .set_debounce() callbacks.
> 
> Suggested-by: Linus Walleij 
> Signed-off-by: Mika Westerberg 
> ---
>  Documentation/gpio/driver.txt |  9 +++--
>  drivers/gpio/gpio-bcm-kona.c  | 14 ++-
>  drivers/gpio/gpio-dln2.c  | 12 --
>  drivers/gpio/gpio-dwapb.c | 14 ++-
>  drivers/gpio/gpio-ep93xx.c| 11 --
>  drivers/gpio/gpio-f7188x.c| 19 +
>  drivers/gpio/gpio-lp873x.c| 14 +++
>  drivers/gpio/gpio-max77620.c  | 20 +-
>  drivers/gpio/gpio-menz127.c   | 34 +++-
>  drivers/gpio/gpio-merrifield.c| 14 ++-
>  drivers/gpio/gpio-omap.c  | 14 ++-
>  drivers/gpio/gpio-tc3589x.c   | 15 ---
>  drivers/gpio/gpio-tegra.c | 14 ++-
>  drivers/gpio/gpio-tps65218.c  | 14 +++
>  drivers/gpio/gpio-vx855.c | 13 ---
>  drivers/gpio/gpio-wcove.c | 13 +++
>  drivers/gpio/gpio-wm831x.c| 21 +-
>  drivers/gpio/gpio-wm8994.c| 13 +++
>  drivers/gpio/gpiolib.c| 56 
> +--
>  drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 14 ++-
>  drivers/pinctrl/pinctrl-amd.c | 14 ++-
>  drivers/pinctrl/pinctrl-sx150x.c  | 55 +++---
>  drivers/staging/greybus/gpio.c| 15 ---
>  drivers/usb/serial/cp210x.c   | 13 ---

For greybus and USB serial:

Acked-by: Johan Hovold 

Note however that this patch fails to apply to linux-next (conflicts in
pinctrl as well as staging).

Thanks,
Johan

[PATCH v6 07/14] sata: ahci-da850: add device tree match table

[Bartosz Golaszewski]

We're using device tree for da850-lcdk. Add the match table to allow
to probe the driver.

Signed-off-by: Bartosz Golaszewski 
Acked-by: Tejun Heo 
---
 drivers/ata/ahci_da850.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/ata/ahci_da850.c b/drivers/ata/ahci_da850.c
index 8cfdc86..7f5328f 100644
--- a/drivers/ata/ahci_da850.c
+++ b/drivers/ata/ahci_da850.c
@@ -121,11 +121,18 @@ static int ahci_da850_probe(struct platform_device *pdev)
 static SIMPLE_DEV_PM_OPS(ahci_da850_pm_ops, ahci_platform_suspend,
 ahci_platform_resume);
 
+static const struct of_device_id ahci_da850_of_match[] = {
+   { .compatible = "ti,da850-ahci", },
+   { },
+};
+MODULE_DEVICE_TABLE(of, ahci_da850_of_match);
+
 static struct platform_driver ahci_da850_driver = {
.probe = ahci_da850_probe,
.remove = ata_platform_remove_one,
.driver = {
.name = DRV_NAME,
+   .of_match_table = ahci_da850_of_match,
.pm = _da850_pm_ops,
},
 };
-- 
2.9.3

[PATCH v6 06/14] ARM: davinci: da850: model the SATA refclk

[Bartosz Golaszewski]

Register a fixed rate clock modelling the external SATA oscillator
for da850 (both DT and board file mode).

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/da8xx-dt.c   |  8 
 arch/arm/mach-davinci/devices-da8xx.c  | 29 +
 arch/arm/mach-davinci/include/mach/da8xx.h |  1 +
 3 files changed, 38 insertions(+)

diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index b83e5d1..55342ca 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -50,6 +50,9 @@ static struct of_dev_auxdata da850_auxdata_lookup[] 
__initdata = {
 
 static void __init da850_init_machine(void)
 {
+   /* All existing boards use 100MHz SATA refclkpn */
+   static const unsigned long sata_refclkpn = 100 * 1000 * 1000;
+
int ret;
 
ret = da8xx_register_usb20_phy_clk(false);
@@ -61,6 +64,11 @@ static void __init da850_init_machine(void)
pr_warn("%s: registering USB 1.1 PHY clock failed: %d",
__func__, ret);
 
+   ret = da850_register_sata_refclk(sata_refclkpn);
+   if (ret)
+   pr_warn("%s: registering SATA REFCLK failed: %d",
+   __func__, ret);
+
of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
davinci_pm_init();
 }
diff --git a/arch/arm/mach-davinci/devices-da8xx.c 
b/arch/arm/mach-davinci/devices-da8xx.c
index c2457b3..cfceb32 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "cpuidle.h"
 #include "sram.h"
 
@@ -1023,6 +1024,28 @@ int __init da8xx_register_spi_bus(int instance, unsigned 
num_chipselect)
 }
 
 #ifdef CONFIG_ARCH_DAVINCI_DA850
+static struct clk sata_refclk = {
+   .name   = "sata_refclk",
+   .set_rate   = davinci_simple_set_rate,
+};
+
+static struct clk_lookup sata_refclk_lookup =
+   CLK("ahci_da850", "refclk", _refclk);
+
+int __init da850_register_sata_refclk(int rate)
+{
+   int ret;
+
+   sata_refclk.rate = rate;
+   ret = clk_register(_refclk);
+   if (ret)
+   return ret;
+
+   clkdev_add(_refclk_lookup);
+
+   return 0;
+}
+
 static struct resource da850_sata_resources[] = {
{
.start  = DA850_SATA_BASE,
@@ -1055,9 +1078,15 @@ static struct platform_device da850_sata_device = {
 
 int __init da850_register_sata(unsigned long refclkpn)
 {
+   int ret;
+
/* please see comment in drivers/ata/ahci_da850.c */
BUG_ON(refclkpn != 100 * 1000 * 1000);
 
+   ret = da850_register_sata_refclk(refclkpn);
+   if (ret)
+   return ret;
+
return platform_device_register(_sata_device);
 }
 #endif
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h 
b/arch/arm/mach-davinci/include/mach/da8xx.h
index 85ff218..7e46422 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -95,6 +95,7 @@ int da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata);
 int da8xx_register_usb_refclkin(int rate);
 int da8xx_register_usb20_phy_clk(bool use_usb_refclkin);
 int da8xx_register_usb11_phy_clk(bool use_usb_refclkin);
+int da850_register_sata_refclk(int rate);
 int da8xx_register_emac(void);
 int da8xx_register_uio_pruss(void);
 int da8xx_register_lcdc(struct da8xx_lcdc_platform_data *pdata);
-- 
2.9.3

[PATCH v6 06/14] ARM: davinci: da850: model the SATA refclk

[Bartosz Golaszewski]

Register a fixed rate clock modelling the external SATA oscillator
for da850 (both DT and board file mode).

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/da8xx-dt.c   |  8 
 arch/arm/mach-davinci/devices-da8xx.c  | 29 +
 arch/arm/mach-davinci/include/mach/da8xx.h |  1 +
 3 files changed, 38 insertions(+)

diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index b83e5d1..55342ca 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -50,6 +50,9 @@ static struct of_dev_auxdata da850_auxdata_lookup[] 
__initdata = {
 
 static void __init da850_init_machine(void)
 {
+   /* All existing boards use 100MHz SATA refclkpn */
+   static const unsigned long sata_refclkpn = 100 * 1000 * 1000;
+
int ret;
 
ret = da8xx_register_usb20_phy_clk(false);
@@ -61,6 +64,11 @@ static void __init da850_init_machine(void)
pr_warn("%s: registering USB 1.1 PHY clock failed: %d",
__func__, ret);
 
+   ret = da850_register_sata_refclk(sata_refclkpn);
+   if (ret)
+   pr_warn("%s: registering SATA REFCLK failed: %d",
+   __func__, ret);
+
of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
davinci_pm_init();
 }
diff --git a/arch/arm/mach-davinci/devices-da8xx.c 
b/arch/arm/mach-davinci/devices-da8xx.c
index c2457b3..cfceb32 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "cpuidle.h"
 #include "sram.h"
 
@@ -1023,6 +1024,28 @@ int __init da8xx_register_spi_bus(int instance, unsigned 
num_chipselect)
 }
 
 #ifdef CONFIG_ARCH_DAVINCI_DA850
+static struct clk sata_refclk = {
+   .name   = "sata_refclk",
+   .set_rate   = davinci_simple_set_rate,
+};
+
+static struct clk_lookup sata_refclk_lookup =
+   CLK("ahci_da850", "refclk", _refclk);
+
+int __init da850_register_sata_refclk(int rate)
+{
+   int ret;
+
+   sata_refclk.rate = rate;
+   ret = clk_register(_refclk);
+   if (ret)
+   return ret;
+
+   clkdev_add(_refclk_lookup);
+
+   return 0;
+}
+
 static struct resource da850_sata_resources[] = {
{
.start  = DA850_SATA_BASE,
@@ -1055,9 +1078,15 @@ static struct platform_device da850_sata_device = {
 
 int __init da850_register_sata(unsigned long refclkpn)
 {
+   int ret;
+
/* please see comment in drivers/ata/ahci_da850.c */
BUG_ON(refclkpn != 100 * 1000 * 1000);
 
+   ret = da850_register_sata_refclk(refclkpn);
+   if (ret)
+   return ret;
+
return platform_device_register(_sata_device);
 }
 #endif
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h 
b/arch/arm/mach-davinci/include/mach/da8xx.h
index 85ff218..7e46422 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -95,6 +95,7 @@ int da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata);
 int da8xx_register_usb_refclkin(int rate);
 int da8xx_register_usb20_phy_clk(bool use_usb_refclkin);
 int da8xx_register_usb11_phy_clk(bool use_usb_refclkin);
+int da850_register_sata_refclk(int rate);
 int da8xx_register_emac(void);
 int da8xx_register_uio_pruss(void);
 int da8xx_register_lcdc(struct da8xx_lcdc_platform_data *pdata);
-- 
2.9.3

Re: [PATCH v3 2/3] i2c: acpi: Initialize info.type from of_compatible

[Andy Shevchenko]

On Mon, Jan 23, 2017 at 6:08 PM, Dan O'Donovan  wrote:
> From: Crestez Dan Leonard 
>
> When using devicetree i2c_board_info.type is set to the compatible
> string with the vendor prefix removed. For I2C devices described via
> ACPI the i2c_board_info.type string is set to the ACPI device name. When
> using ACPI and DT ids this string ends up something like "PRP0001:00".
>
> If the of_compatible property is present try to use that instead. This
> makes it easier to instantiate i2c drivers through ACPI with DT ids.

> -   strlcpy(info->type, dev_name(>dev), sizeof(info->type));
> +   /*
> +* Populate modalias from compatible property if available,
> +* otherwise use native ACPI information
> +*/
> +   if ((!adev->data.of_compatible) ||
> +   acpi_of_modalias(adev, info->type, sizeof(info->type)))

Redundant parens in lvalue. After removing them is it possible to use
one line for it?

> +   strlcpy(info->type, dev_name(>dev), sizeof(info->type));

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 2/3] i2c: acpi: Initialize info.type from of_compatible

[Andy Shevchenko]

On Mon, Jan 23, 2017 at 6:08 PM, Dan O'Donovan  wrote:
> From: Crestez Dan Leonard 
>
> When using devicetree i2c_board_info.type is set to the compatible
> string with the vendor prefix removed. For I2C devices described via
> ACPI the i2c_board_info.type string is set to the ACPI device name. When
> using ACPI and DT ids this string ends up something like "PRP0001:00".
>
> If the of_compatible property is present try to use that instead. This
> makes it easier to instantiate i2c drivers through ACPI with DT ids.

> -   strlcpy(info->type, dev_name(>dev), sizeof(info->type));
> +   /*
> +* Populate modalias from compatible property if available,
> +* otherwise use native ACPI information
> +*/
> +   if ((!adev->data.of_compatible) ||
> +   acpi_of_modalias(adev, info->type, sizeof(info->type)))

Redundant parens in lvalue. After removing them is it possible to use
one line for it?

> +   strlcpy(info->type, dev_name(>dev), sizeof(info->type));

-- 
With Best Regards,
Andy Shevchenko

Re: v4.10-rc4 to v4.10-rc5: battery regression on Nokia N900

[Guenter Roeck]

On Mon, Jan 23, 2017 at 03:40:31PM +0100, Pavel Machek wrote:
> On Mon 2017-01-23 06:31:31, Guenter Roeck wrote:
> > On 01/23/2017 06:19 AM, Pavel Machek wrote:
> > >Hi!
> > >
> > >>It seems that battery driver stopped working on N900 between -rc4 and
> > >>-rc5.
> > >
> > >pavel@amd:/data/l/linux-n900$ git bisect log
> > ># bad: [41f283973653dc44af47585fa79fb6da6ffdc2e2] Merge
> > >/data//l/clean-cg into mini-v4.10
> > ># good: [4f8d9925eb1de1ec1c4183164f1bc7b01f5ae185] It seems mainline
> > >-rc4 did have a fix for the sound issue. Use that one.
> > >git bisect start 'mini-v4.10'
> > >'4f8d9925eb1de1ec1c4183164f1bc7b01f5ae185'
> > ># good: [e90665a5d38b17fdbe484a85fbba917a7006522d] Merge tag
> > >'ceph-for-4.10-rc5' of git://github.com/ceph/ceph-client
> > >git bisect good e90665a5d38b17fdbe484a85fbba917a7006522d
> > ># good: [83fd57a740bb19286959b3085eb93532f3e7ef2c] Merge tag
> > >'powerpc-4.10-2' of
> > >git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
> > >git bisect good 83fd57a740bb19286959b3085eb93532f3e7ef2c
> > ># good: [c497f8d17246720afe680ea1a8fa6e48e75af852] Merge tag
> > >'usb-4.10-rc5' of
> > >git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
> > >git bisect good c497f8d17246720afe680ea1a8fa6e48e75af852
> > ># bad: [bb6c01c2dde67b165cf7c808b0f00677b6f94b96] Merge branch
> > >'for-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux
> > >git bisect bad bb6c01c2dde67b165cf7c808b0f00677b6f94b96
> > ># good: [18591add41ec9558ce0e32ef88626c18cc70c686] thermal: rockchip:
> > >handle set_trips without the trip points
> > >git bisect good 18591add41ec9558ce0e32ef88626c18cc70c686
> > ># bad: [f53345e8cf027d03187b9417f1f8883c516e1a5b] thermal: core: move
> > >tz->device.groups cleanup to thermal_release
> > >git bisect bad f53345e8cf027d03187b9417f1f8883c516e1a5b
> > ># bad: [7611fb68062f8d7f416f3272894d1edf7bbff29c] thermal:
> > >thermal_hwmon: Convert to hwmon_device_register_with_info()
> > >git bisect bad 7611fb68062f8d7f416f3272894d1edf7bbff29c
> > ># first bad commit: [7611fb68062f8d7f416f3272894d1edf7bbff29c]
> > >thermal: thermal_hwmon: Convert to hwmon_device_register_with_info()
> > >pavel@amd:/data/l/linux-n900$
> > >
> > >pavel@amd:/data/l/linux-n900$ git bisect log
> > ># bad: [41f283973653dc44af47585fa79fb6da6ffdc2e2] Merge
> > >/data//l/clean-cg into mini-v4.10
> > ># good: [4f8d9925eb1de1ec1c4183164f1bc7b01f5ae185] It seems mainline
> > >-rc4 did have a fix for the sound issue. Use that one.
> > >git bisect start 'mini-v4.10'
> > >'4f8d9925eb1de1ec1c4183164f1bc7b01f5ae185'
> > ># good: [e90665a5d38b17fdbe484a85fbba917a7006522d] Merge tag
> > >'ceph-for-4.10-rc5' of git://github.com/ceph/ceph-client
> > >git bisect good e90665a5d38b17fdbe484a85fbba917a7006522d
> > ># good: [83fd57a740bb19286959b3085eb93532f3e7ef2c] Merge tag
> > >'powerpc-4.10-2' of
> > >git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
> > >git bisect good 83fd57a740bb19286959b3085eb93532f3e7ef2c
> > ># good: [c497f8d17246720afe680ea1a8fa6e48e75af852] Merge tag
> > >'usb-4.10-rc5' of
> > >git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
> > >git bisect good c497f8d17246720afe680ea1a8fa6e48e75af852
> > ># bad: [bb6c01c2dde67b165cf7c808b0f00677b6f94b96] Merge branch
> > >'for-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux
> > >git bisect bad bb6c01c2dde67b165cf7c808b0f00677b6f94b96
> > ># good: [18591add41ec9558ce0e32ef88626c18cc70c686] thermal: rockchip:
> > >handle set_trips without the trip points
> > >git bisect good 18591add41ec9558ce0e32ef88626c18cc70c686
> > ># bad: [f53345e8cf027d03187b9417f1f8883c516e1a5b] thermal: core: move
> > >tz->device.groups cleanup to thermal_release
> > >git bisect bad f53345e8cf027d03187b9417f1f8883c516e1a5b
> > ># bad: [7611fb68062f8d7f416f3272894d1edf7bbff29c] thermal:
> > >thermal_hwmon: Convert to hwmon_device_register_with_info()
> > >git bisect bad 7611fb68062f8d7f416f3272894d1edf7bbff29c
> > ># first bad commit: [7611fb68062f8d7f416f3272894d1edf7bbff29c]
> > >thermal: thermal_hwmon: Convert to hwmon_device_register_with_info()
> > >pavel@amd:/data/l/linux-n900$
> > >
> > >7611fb68062f8d7f416f3272894d1edf7bbff29c is the first bad commit
> > >commit 7611fb68062f8d7f416f3272894d1edf7bbff29c
> > >Author: Fabio Estevam 
> > >Date:   Tue Dec 27 15:31:49 2016 -0200
> > >
> > >thermal: thermal_hwmon: Convert to
> > >hwmon_device_register_with_info()
> > >
> > >Booting Linux on a mx6q based board leads to the following
> > >warning:
> > >
> > >(NULL device *): hwmon_device_register() is deprecated. Please
> > >convert the
> > >driver to use hwmon_device_register_with_info().
> > >
> > >,so do as suggested.
> > >
> > >Also, this results in the core taking care of creating the 'name'
> > >attribute, so drop the code doing that from the thermal
> > >driver.
> > >
> > > Suggested-by: Guenter Roeck 
> > > Signed-off-by: Fabio 

Re: v4.10-rc4 to v4.10-rc5: battery regression on Nokia N900

[Guenter Roeck]

On Mon, Jan 23, 2017 at 03:40:31PM +0100, Pavel Machek wrote:
> On Mon 2017-01-23 06:31:31, Guenter Roeck wrote:
> > On 01/23/2017 06:19 AM, Pavel Machek wrote:
> > >Hi!
> > >
> > >>It seems that battery driver stopped working on N900 between -rc4 and
> > >>-rc5.
> > >
> > >pavel@amd:/data/l/linux-n900$ git bisect log
> > ># bad: [41f283973653dc44af47585fa79fb6da6ffdc2e2] Merge
> > >/data//l/clean-cg into mini-v4.10
> > ># good: [4f8d9925eb1de1ec1c4183164f1bc7b01f5ae185] It seems mainline
> > >-rc4 did have a fix for the sound issue. Use that one.
> > >git bisect start 'mini-v4.10'
> > >'4f8d9925eb1de1ec1c4183164f1bc7b01f5ae185'
> > ># good: [e90665a5d38b17fdbe484a85fbba917a7006522d] Merge tag
> > >'ceph-for-4.10-rc5' of git://github.com/ceph/ceph-client
> > >git bisect good e90665a5d38b17fdbe484a85fbba917a7006522d
> > ># good: [83fd57a740bb19286959b3085eb93532f3e7ef2c] Merge tag
> > >'powerpc-4.10-2' of
> > >git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
> > >git bisect good 83fd57a740bb19286959b3085eb93532f3e7ef2c
> > ># good: [c497f8d17246720afe680ea1a8fa6e48e75af852] Merge tag
> > >'usb-4.10-rc5' of
> > >git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
> > >git bisect good c497f8d17246720afe680ea1a8fa6e48e75af852
> > ># bad: [bb6c01c2dde67b165cf7c808b0f00677b6f94b96] Merge branch
> > >'for-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux
> > >git bisect bad bb6c01c2dde67b165cf7c808b0f00677b6f94b96
> > ># good: [18591add41ec9558ce0e32ef88626c18cc70c686] thermal: rockchip:
> > >handle set_trips without the trip points
> > >git bisect good 18591add41ec9558ce0e32ef88626c18cc70c686
> > ># bad: [f53345e8cf027d03187b9417f1f8883c516e1a5b] thermal: core: move
> > >tz->device.groups cleanup to thermal_release
> > >git bisect bad f53345e8cf027d03187b9417f1f8883c516e1a5b
> > ># bad: [7611fb68062f8d7f416f3272894d1edf7bbff29c] thermal:
> > >thermal_hwmon: Convert to hwmon_device_register_with_info()
> > >git bisect bad 7611fb68062f8d7f416f3272894d1edf7bbff29c
> > ># first bad commit: [7611fb68062f8d7f416f3272894d1edf7bbff29c]
> > >thermal: thermal_hwmon: Convert to hwmon_device_register_with_info()
> > >pavel@amd:/data/l/linux-n900$
> > >
> > >pavel@amd:/data/l/linux-n900$ git bisect log
> > ># bad: [41f283973653dc44af47585fa79fb6da6ffdc2e2] Merge
> > >/data//l/clean-cg into mini-v4.10
> > ># good: [4f8d9925eb1de1ec1c4183164f1bc7b01f5ae185] It seems mainline
> > >-rc4 did have a fix for the sound issue. Use that one.
> > >git bisect start 'mini-v4.10'
> > >'4f8d9925eb1de1ec1c4183164f1bc7b01f5ae185'
> > ># good: [e90665a5d38b17fdbe484a85fbba917a7006522d] Merge tag
> > >'ceph-for-4.10-rc5' of git://github.com/ceph/ceph-client
> > >git bisect good e90665a5d38b17fdbe484a85fbba917a7006522d
> > ># good: [83fd57a740bb19286959b3085eb93532f3e7ef2c] Merge tag
> > >'powerpc-4.10-2' of
> > >git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
> > >git bisect good 83fd57a740bb19286959b3085eb93532f3e7ef2c
> > ># good: [c497f8d17246720afe680ea1a8fa6e48e75af852] Merge tag
> > >'usb-4.10-rc5' of
> > >git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
> > >git bisect good c497f8d17246720afe680ea1a8fa6e48e75af852
> > ># bad: [bb6c01c2dde67b165cf7c808b0f00677b6f94b96] Merge branch
> > >'for-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux
> > >git bisect bad bb6c01c2dde67b165cf7c808b0f00677b6f94b96
> > ># good: [18591add41ec9558ce0e32ef88626c18cc70c686] thermal: rockchip:
> > >handle set_trips without the trip points
> > >git bisect good 18591add41ec9558ce0e32ef88626c18cc70c686
> > ># bad: [f53345e8cf027d03187b9417f1f8883c516e1a5b] thermal: core: move
> > >tz->device.groups cleanup to thermal_release
> > >git bisect bad f53345e8cf027d03187b9417f1f8883c516e1a5b
> > ># bad: [7611fb68062f8d7f416f3272894d1edf7bbff29c] thermal:
> > >thermal_hwmon: Convert to hwmon_device_register_with_info()
> > >git bisect bad 7611fb68062f8d7f416f3272894d1edf7bbff29c
> > ># first bad commit: [7611fb68062f8d7f416f3272894d1edf7bbff29c]
> > >thermal: thermal_hwmon: Convert to hwmon_device_register_with_info()
> > >pavel@amd:/data/l/linux-n900$
> > >
> > >7611fb68062f8d7f416f3272894d1edf7bbff29c is the first bad commit
> > >commit 7611fb68062f8d7f416f3272894d1edf7bbff29c
> > >Author: Fabio Estevam 
> > >Date:   Tue Dec 27 15:31:49 2016 -0200
> > >
> > >thermal: thermal_hwmon: Convert to
> > >hwmon_device_register_with_info()
> > >
> > >Booting Linux on a mx6q based board leads to the following
> > >warning:
> > >
> > >(NULL device *): hwmon_device_register() is deprecated. Please
> > >convert the
> > >driver to use hwmon_device_register_with_info().
> > >
> > >,so do as suggested.
> > >
> > >Also, this results in the core taking care of creating the 'name'
> > >attribute, so drop the code doing that from the thermal
> > >driver.
> > >
> > > Suggested-by: Guenter Roeck 
> > > Signed-off-by: Fabio Estevam 
> > > Signed-off-by: Zhang Rui 
> 

[PATCH v6 01/14] devicetree: bindings: add bindings for ahci-da850

[Bartosz Golaszewski]

Add DT bindings for the TI DA850 AHCI SATA controller.

Signed-off-by: Bartosz Golaszewski 
---
 Documentation/devicetree/bindings/ata/ahci-da850.txt | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ata/ahci-da850.txt

diff --git a/Documentation/devicetree/bindings/ata/ahci-da850.txt 
b/Documentation/devicetree/bindings/ata/ahci-da850.txt
new file mode 100644
index 000..5f81934
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/ahci-da850.txt
@@ -0,0 +1,18 @@
+Device tree binding for the TI DA850 AHCI SATA Controller
+-
+
+Required properties:
+  - compatible: must be "ti,da850-ahci"
+  - reg: physical base addresses and sizes of the two register regions
+ used by the controller: the register map as defined by the
+ AHCI 1.1 standard and the Power Down Control Register (PWRDN)
+ for enabling/disabling the SATA clock receiver
+  - interrupts: interrupt specifier (refer to the interrupt binding)
+
+Example:
+
+   sata: sata@218000 {
+   compatible = "ti,da850-ahci";
+   reg = <0x218000 0x2000>, <0x22c018 0x4>;
+   interrupts = <67>;
+   };
-- 
2.9.3

[PATCH v6 01/14] devicetree: bindings: add bindings for ahci-da850

[Bartosz Golaszewski]

Add DT bindings for the TI DA850 AHCI SATA controller.

Signed-off-by: Bartosz Golaszewski 
---
 Documentation/devicetree/bindings/ata/ahci-da850.txt | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ata/ahci-da850.txt

diff --git a/Documentation/devicetree/bindings/ata/ahci-da850.txt 
b/Documentation/devicetree/bindings/ata/ahci-da850.txt
new file mode 100644
index 000..5f81934
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/ahci-da850.txt
@@ -0,0 +1,18 @@
+Device tree binding for the TI DA850 AHCI SATA Controller
+-
+
+Required properties:
+  - compatible: must be "ti,da850-ahci"
+  - reg: physical base addresses and sizes of the two register regions
+ used by the controller: the register map as defined by the
+ AHCI 1.1 standard and the Power Down Control Register (PWRDN)
+ for enabling/disabling the SATA clock receiver
+  - interrupts: interrupt specifier (refer to the interrupt binding)
+
+Example:
+
+   sata: sata@218000 {
+   compatible = "ti,da850-ahci";
+   reg = <0x218000 0x2000>, <0x22c018 0x4>;
+   interrupts = <67>;
+   };
-- 
2.9.3

[PATCH v6 00/14] ARM: da850-lcdk: add SATA support

[Bartosz Golaszewski]

This series contains all the changes necessary to make SATA work on
the da850-lcdk board.

The first patch adds DT bindings for the ahci-da850 driver.

The second enables relevant modules in davinci_all_defconfig.

Patches 03/14-06/14 modify the way the clocks are handled regarding
SATA on the da850 platform. We modify the ahci driver to retrieve
the clock via con_id and model the external SATA oscillator as
a real clock.

Patches 07/14-11/14 extend the ahci-da850 driver. Add DT support,
implement workarounds necessary to make SATA work on the da850-lcdk
board and un-hardcode the external clock multiplier.

Patch 12/14 removes a no longer needed BUG_ON.

Last two patches add device tree changes required to probe the
driver.

v1 -> v2:
- dropped patch 04/10 - replaced with local changes in the
  ahci-da850 driver
- added comments explaining the workaround in ahci softreset
- s/0x218000/218000 in the sata DT node label
- added patches chaning the way clocks are handled in the da850 SATA
  code both in arch/ and in the ahci driver
- dropped the clock multiplier property in the DT bindings in favor
  of using struct clk to pass the refclk rate to the driver
- minor tweaks in commit messages

v2 -> v3:
- dropped the clocks property from the ahci-da850 DT binding
- dropped patch 12/14 (SATA pinmux settings)
- dropped an outdated fragment from the commit message in patch 14/14
- s/get_clk()/clk_get()/
- s/connector id/connection id/
- stopped using __div64_32() after noticing that it sometimes produces
  invalid results
- removed the default MPY value from ahci-da850
- registered SATA refclk for board file boot mode as well

v3 -> v4:
- added a patch removing the no longer needed BUG_ON() from
  da850_register_sata()
- fixed indents

v4 -> v5:
- renamed the DT node for the SATA controller from 'ahci' to 'sata',
  while keeping the label as 'sata'
- renamed the SATA node in the DT example as well
- instead of calling the refclk clock 'dummy', called it 'fixed rate'

v5 -> v6:
- specified what the required register regions are in the device
  tree bindings

Bartosz Golaszewski (14):
  devicetree: bindings: add bindings for ahci-da850
  ARM: davinci_all_defconfig: enable SATA modules
  ARM: davinci: add a clock lookup entry for the SATA clock
  sata: ahci-da850: get the sata clock using a connection id
  ARM: davinci: da850: add con_id for the SATA clock
  ARM: davinci: da850: model the SATA refclk
  sata: ahci-da850: add device tree match table
  sata: ahci-da850: implement a workaround for the softreset quirk
  sata: ahci: export ahci_do_hardreset() locally
  sata: ahci-da850: add a workaround for controller instability
  sata: ahci-da850: un-hardcode the MPY bits
  ARM: davinci: remove BUG_ON() from da850_register_sata()
  ARM: dts: da850: add the SATA node
  ARM: dts: da850-lcdk: enable the SATA node

 .../devicetree/bindings/ata/ahci-da850.txt |  18 +++
 arch/arm/boot/dts/da850-lcdk.dts   |   4 +
 arch/arm/boot/dts/da850.dtsi   |   6 +
 arch/arm/configs/davinci_all_defconfig |   2 +
 arch/arm/mach-davinci/da850.c  |   2 +-
 arch/arm/mach-davinci/da8xx-dt.c   |   9 ++
 arch/arm/mach-davinci/devices-da8xx.c  |  30 +++-
 arch/arm/mach-davinci/include/mach/da8xx.h |   1 +
 drivers/ata/ahci.h |   3 +
 drivers/ata/ahci_da850.c   | 175 +++--
 drivers/ata/libahci.c  |  18 ++-
 11 files changed, 243 insertions(+), 25 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ata/ahci-da850.txt

-- 
2.9.3

[PATCH v6 00/14] ARM: da850-lcdk: add SATA support

[Bartosz Golaszewski]

This series contains all the changes necessary to make SATA work on
the da850-lcdk board.

The first patch adds DT bindings for the ahci-da850 driver.

The second enables relevant modules in davinci_all_defconfig.

Patches 03/14-06/14 modify the way the clocks are handled regarding
SATA on the da850 platform. We modify the ahci driver to retrieve
the clock via con_id and model the external SATA oscillator as
a real clock.

Patches 07/14-11/14 extend the ahci-da850 driver. Add DT support,
implement workarounds necessary to make SATA work on the da850-lcdk
board and un-hardcode the external clock multiplier.

Patch 12/14 removes a no longer needed BUG_ON.

Last two patches add device tree changes required to probe the
driver.

v1 -> v2:
- dropped patch 04/10 - replaced with local changes in the
  ahci-da850 driver
- added comments explaining the workaround in ahci softreset
- s/0x218000/218000 in the sata DT node label
- added patches chaning the way clocks are handled in the da850 SATA
  code both in arch/ and in the ahci driver
- dropped the clock multiplier property in the DT bindings in favor
  of using struct clk to pass the refclk rate to the driver
- minor tweaks in commit messages

v2 -> v3:
- dropped the clocks property from the ahci-da850 DT binding
- dropped patch 12/14 (SATA pinmux settings)
- dropped an outdated fragment from the commit message in patch 14/14
- s/get_clk()/clk_get()/
- s/connector id/connection id/
- stopped using __div64_32() after noticing that it sometimes produces
  invalid results
- removed the default MPY value from ahci-da850
- registered SATA refclk for board file boot mode as well

v3 -> v4:
- added a patch removing the no longer needed BUG_ON() from
  da850_register_sata()
- fixed indents

v4 -> v5:
- renamed the DT node for the SATA controller from 'ahci' to 'sata',
  while keeping the label as 'sata'
- renamed the SATA node in the DT example as well
- instead of calling the refclk clock 'dummy', called it 'fixed rate'

v5 -> v6:
- specified what the required register regions are in the device
  tree bindings

Bartosz Golaszewski (14):
  devicetree: bindings: add bindings for ahci-da850
  ARM: davinci_all_defconfig: enable SATA modules
  ARM: davinci: add a clock lookup entry for the SATA clock
  sata: ahci-da850: get the sata clock using a connection id
  ARM: davinci: da850: add con_id for the SATA clock
  ARM: davinci: da850: model the SATA refclk
  sata: ahci-da850: add device tree match table
  sata: ahci-da850: implement a workaround for the softreset quirk
  sata: ahci: export ahci_do_hardreset() locally
  sata: ahci-da850: add a workaround for controller instability
  sata: ahci-da850: un-hardcode the MPY bits
  ARM: davinci: remove BUG_ON() from da850_register_sata()
  ARM: dts: da850: add the SATA node
  ARM: dts: da850-lcdk: enable the SATA node

 .../devicetree/bindings/ata/ahci-da850.txt |  18 +++
 arch/arm/boot/dts/da850-lcdk.dts   |   4 +
 arch/arm/boot/dts/da850.dtsi   |   6 +
 arch/arm/configs/davinci_all_defconfig |   2 +
 arch/arm/mach-davinci/da850.c  |   2 +-
 arch/arm/mach-davinci/da8xx-dt.c   |   9 ++
 arch/arm/mach-davinci/devices-da8xx.c  |  30 +++-
 arch/arm/mach-davinci/include/mach/da8xx.h |   1 +
 drivers/ata/ahci.h |   3 +
 drivers/ata/ahci_da850.c   | 175 +++--
 drivers/ata/libahci.c  |  18 ++-
 11 files changed, 243 insertions(+), 25 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ata/ahci-da850.txt

-- 
2.9.3

Re: [PATCH v4 9/9] clocksource/drivers/rockchip_timer: implement clocksource timer

[Heiko Stübner]

Am Dienstag, 29. November 2016, 19:14:52 CET schrieb Alexander Kochetkov:
> The clock supplying the arm-global-timer on the rk3188 is coming from the
> the cpu clock itself and thus changes its rate everytime cpufreq adjusts
> the cpu frequency making this timer unsuitable as a stable clocksource
> and sched clock.
> 
> The rk3188, rk3288 and following socs share a separate timer block already
> handled by the rockchip-timer driver. Therefore adapt this driver to also
> be able to act as clocksource and sched clock on rk3188.
> 
> In order to test clocksource you can run following commands and check
> how much time it take in real. On rk3188 it take about ~45 seconds.
> 
> cpufreq-set -f 1.6GHZ
> date; sleep 60; date
> 
> In order to use the patch you need to declare two timers in the dts
> file. The first timer will be initialized as clockevent provider
> and the second one as clocksource. The clockevent must be from
> alive subsystem as it used as backup for the local timers at sleep
> time.
> 
> The patch does not break compatibility with older device tree files.
> The older device tree files contain only one timer. The timer
> will be initialized as clockevent, as expected.
> 
> rk3288 (and probably anything newer) is irrelevant to this patch,
> as it has the arch timer interface. This patch may be usefull
> for Cortex-A9/A5 based parts.
> 
> Signed-off-by: Alexander Kochetkov 

[...]

> @@ -120,13 +161,46 @@ static irqreturn_t rk_timer_interrupt(int irq, void
> *dev_id) return IRQ_HANDLED;
>  }
> 
> +static cycle_t rk_timer_clocksource_read(struct clocksource *cs)
^^
../drivers/clocksource/rockchip_timer.c:164:8: error: unknown type name 
‘cycle_t’
 static cycle_t rk_timer_clocksource_read(struct clocksource *cs)

looks like something in clocksources changed since november

Re: [PATCH v4 9/9] clocksource/drivers/rockchip_timer: implement clocksource timer

[Heiko Stübner]

Am Dienstag, 29. November 2016, 19:14:52 CET schrieb Alexander Kochetkov:
> The clock supplying the arm-global-timer on the rk3188 is coming from the
> the cpu clock itself and thus changes its rate everytime cpufreq adjusts
> the cpu frequency making this timer unsuitable as a stable clocksource
> and sched clock.
> 
> The rk3188, rk3288 and following socs share a separate timer block already
> handled by the rockchip-timer driver. Therefore adapt this driver to also
> be able to act as clocksource and sched clock on rk3188.
> 
> In order to test clocksource you can run following commands and check
> how much time it take in real. On rk3188 it take about ~45 seconds.
> 
> cpufreq-set -f 1.6GHZ
> date; sleep 60; date
> 
> In order to use the patch you need to declare two timers in the dts
> file. The first timer will be initialized as clockevent provider
> and the second one as clocksource. The clockevent must be from
> alive subsystem as it used as backup for the local timers at sleep
> time.
> 
> The patch does not break compatibility with older device tree files.
> The older device tree files contain only one timer. The timer
> will be initialized as clockevent, as expected.
> 
> rk3288 (and probably anything newer) is irrelevant to this patch,
> as it has the arch timer interface. This patch may be usefull
> for Cortex-A9/A5 based parts.
> 
> Signed-off-by: Alexander Kochetkov 

[...]

> @@ -120,13 +161,46 @@ static irqreturn_t rk_timer_interrupt(int irq, void
> *dev_id) return IRQ_HANDLED;
>  }
> 
> +static cycle_t rk_timer_clocksource_read(struct clocksource *cs)
^^
../drivers/clocksource/rockchip_timer.c:164:8: error: unknown type name 
‘cycle_t’
 static cycle_t rk_timer_clocksource_read(struct clocksource *cs)

looks like something in clocksources changed since november

[PATCH v6 12/14] ARM: davinci: remove BUG_ON() from da850_register_sata()

[Bartosz Golaszewski]

The ahci driver now supports other refclk clock rates.

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/devices-da8xx.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/mach-davinci/devices-da8xx.c 
b/arch/arm/mach-davinci/devices-da8xx.c
index cfceb32..7cf529f 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -1080,9 +1080,6 @@ int __init da850_register_sata(unsigned long refclkpn)
 {
int ret;
 
-   /* please see comment in drivers/ata/ahci_da850.c */
-   BUG_ON(refclkpn != 100 * 1000 * 1000);
-
ret = da850_register_sata_refclk(refclkpn);
if (ret)
return ret;
-- 
2.9.3

[PATCH v6 13/14] ARM: dts: da850: add the SATA node

[Bartosz Golaszewski]

Add the SATA node to the da850 device tree.

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/boot/dts/da850.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 104155d..3b5fd41e 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -403,6 +403,12 @@
phy-names = "usb-phy";
status = "disabled";
};
+   sata: sata@218000 {
+   compatible = "ti,da850-ahci";
+   reg = <0x218000 0x2000>, <0x22c018 0x4>;
+   interrupts = <67>;
+   status = "disabled";
+   };
mdio: mdio@224000 {
compatible = "ti,davinci_mdio";
#address-cells = <1>;
-- 
2.9.3

[PATCH v6 12/14] ARM: davinci: remove BUG_ON() from da850_register_sata()

[Bartosz Golaszewski]

The ahci driver now supports other refclk clock rates.

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/devices-da8xx.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/mach-davinci/devices-da8xx.c 
b/arch/arm/mach-davinci/devices-da8xx.c
index cfceb32..7cf529f 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -1080,9 +1080,6 @@ int __init da850_register_sata(unsigned long refclkpn)
 {
int ret;
 
-   /* please see comment in drivers/ata/ahci_da850.c */
-   BUG_ON(refclkpn != 100 * 1000 * 1000);
-
ret = da850_register_sata_refclk(refclkpn);
if (ret)
return ret;
-- 
2.9.3

[PATCH v6 13/14] ARM: dts: da850: add the SATA node

[Bartosz Golaszewski]

Add the SATA node to the da850 device tree.

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/boot/dts/da850.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 104155d..3b5fd41e 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -403,6 +403,12 @@
phy-names = "usb-phy";
status = "disabled";
};
+   sata: sata@218000 {
+   compatible = "ti,da850-ahci";
+   reg = <0x218000 0x2000>, <0x22c018 0x4>;
+   interrupts = <67>;
+   status = "disabled";
+   };
mdio: mdio@224000 {
compatible = "ti,davinci_mdio";
#address-cells = <1>;
-- 
2.9.3

[PATCH v6 11/14] sata: ahci-da850: un-hardcode the MPY bits

[Bartosz Golaszewski]

All platforms using this driver now register the SATA refclk. Remove
the hardcoded default value from the driver and instead read the rate
of the external clock and calculate the required MPY value from it.

Signed-off-by: Bartosz Golaszewski 
Acked-by: Tejun Heo 
---
 drivers/ata/ahci_da850.c | 91 
 1 file changed, 76 insertions(+), 15 deletions(-)

diff --git a/drivers/ata/ahci_da850.c b/drivers/ata/ahci_da850.c
index 0b2b1a4..9ed404d 100644
--- a/drivers/ata/ahci_da850.c
+++ b/drivers/ata/ahci_da850.c
@@ -29,17 +29,8 @@
 #define SATA_PHY_TXSWING(x)((x) << 19)
 #define SATA_PHY_ENPLL(x)  ((x) << 31)
 
-/*
- * The multiplier needed for 1.5GHz PLL output.
- *
- * NOTE: This is currently hardcoded to be suitable for 100MHz crystal
- * frequency (which is used by DA850 EVM board) and may need to be changed
- * if you would like to use this driver on some other board.
- */
-#define DA850_SATA_CLK_MULTIPLIER  7
-
 static void da850_sata_init(struct device *dev, void __iomem *pwrdn_reg,
-   void __iomem *ahci_base)
+   void __iomem *ahci_base, u32 mpy)
 {
unsigned int val;
 
@@ -48,13 +39,61 @@ static void da850_sata_init(struct device *dev, void 
__iomem *pwrdn_reg,
val &= ~BIT(0);
writel(val, pwrdn_reg);
 
-   val = SATA_PHY_MPY(DA850_SATA_CLK_MULTIPLIER + 1) | SATA_PHY_LOS(1) |
- SATA_PHY_RXCDR(4) | SATA_PHY_RXEQ(1) | SATA_PHY_TXSWING(3) |
- SATA_PHY_ENPLL(1);
+   val = SATA_PHY_MPY(mpy) | SATA_PHY_LOS(1) | SATA_PHY_RXCDR(4) |
+ SATA_PHY_RXEQ(1) | SATA_PHY_TXSWING(3) | SATA_PHY_ENPLL(1);
 
writel(val, ahci_base + SATA_P0PHYCR_REG);
 }
 
+static u32 ahci_da850_calculate_mpy(unsigned long refclk_rate)
+{
+   u32 pll_output = 15, needed;
+
+   /*
+* We need to determine the value of the multiplier (MPY) bits.
+* In order to include the 12.5 multiplier we need to first divide
+* the refclk rate by ten.
+*
+* __div64_32() turned out to be unreliable, sometimes returning
+* false results.
+*/
+   WARN((refclk_rate % 10) != 0, "refclk must be divisible by 10");
+   needed = pll_output / (refclk_rate / 10);
+
+   /*
+* What we have now is (multiplier * 10).
+*
+* Let's determine the actual register value we need to write.
+*/
+
+   switch (needed) {
+   case 50:
+   return 0x1;
+   case 60:
+   return 0x2;
+   case 80:
+   return 0x4;
+   case 100:
+   return 0x5;
+   case 120:
+   return 0x6;
+   case 125:
+   return 0x7;
+   case 150:
+   return 0x8;
+   case 200:
+   return 0x9;
+   case 250:
+   return 0xa;
+   default:
+   /*
+* We should have divided evenly - if not, return an invalid
+* value.
+*/
+   return 0;
+   }
+}
+
 static int ahci_da850_softreset(struct ata_link *link,
unsigned int *class, unsigned long deadline)
 {
@@ -126,9 +165,10 @@ static int ahci_da850_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
struct ahci_host_priv *hpriv;
-   struct resource *res;
void __iomem *pwrdn_reg;
+   struct resource *res;
struct clk *clk;
+   u32 mpy;
int rc;
 
hpriv = ahci_platform_get_resources(pdev);
@@ -150,6 +190,27 @@ static int ahci_da850_probe(struct platform_device *pdev)
hpriv->clks[0] = clk;
}
 
+   /*
+* The second clock used by ahci-da850 is the external REFCLK. If we
+* didn't get it from ahci_platform_get_resources(), let's try to
+* specify the con_id in clk_get().
+*/
+   if (!hpriv->clks[1]) {
+   clk = clk_get(dev, "refclk");
+   if (IS_ERR(clk)) {
+   dev_err(dev, "unable to obtain the reference clock");
+   return -ENODEV;
+   } else {
+   hpriv->clks[1] = clk;
+   }
+   }
+
+   mpy = ahci_da850_calculate_mpy(clk_get_rate(hpriv->clks[1]));
+   if (mpy == 0) {
+   dev_err(dev, "invalid REFCLK multiplier value: 0x%x", mpy);
+   return -EINVAL;
+   }
+
rc = ahci_platform_enable_resources(hpriv);
if (rc)
return rc;
@@ -162,7 +223,7 @@ static int ahci_da850_probe(struct platform_device *pdev)
if (!pwrdn_reg)
goto disable_resources;
 
-   da850_sata_init(dev, pwrdn_reg, hpriv->mmio);
+   da850_sata_init(dev, pwrdn_reg, hpriv->mmio, mpy);
 
rc = ahci_platform_init_host(pdev, hpriv, _da850_port_info,
 _platform_sht);

[PATCH v6 11/14] sata: ahci-da850: un-hardcode the MPY bits

[Bartosz Golaszewski]

All platforms using this driver now register the SATA refclk. Remove
the hardcoded default value from the driver and instead read the rate
of the external clock and calculate the required MPY value from it.

Signed-off-by: Bartosz Golaszewski 
Acked-by: Tejun Heo 
---
 drivers/ata/ahci_da850.c | 91 
 1 file changed, 76 insertions(+), 15 deletions(-)

diff --git a/drivers/ata/ahci_da850.c b/drivers/ata/ahci_da850.c
index 0b2b1a4..9ed404d 100644
--- a/drivers/ata/ahci_da850.c
+++ b/drivers/ata/ahci_da850.c
@@ -29,17 +29,8 @@
 #define SATA_PHY_TXSWING(x)((x) << 19)
 #define SATA_PHY_ENPLL(x)  ((x) << 31)
 
-/*
- * The multiplier needed for 1.5GHz PLL output.
- *
- * NOTE: This is currently hardcoded to be suitable for 100MHz crystal
- * frequency (which is used by DA850 EVM board) and may need to be changed
- * if you would like to use this driver on some other board.
- */
-#define DA850_SATA_CLK_MULTIPLIER  7
-
 static void da850_sata_init(struct device *dev, void __iomem *pwrdn_reg,
-   void __iomem *ahci_base)
+   void __iomem *ahci_base, u32 mpy)
 {
unsigned int val;
 
@@ -48,13 +39,61 @@ static void da850_sata_init(struct device *dev, void 
__iomem *pwrdn_reg,
val &= ~BIT(0);
writel(val, pwrdn_reg);
 
-   val = SATA_PHY_MPY(DA850_SATA_CLK_MULTIPLIER + 1) | SATA_PHY_LOS(1) |
- SATA_PHY_RXCDR(4) | SATA_PHY_RXEQ(1) | SATA_PHY_TXSWING(3) |
- SATA_PHY_ENPLL(1);
+   val = SATA_PHY_MPY(mpy) | SATA_PHY_LOS(1) | SATA_PHY_RXCDR(4) |
+ SATA_PHY_RXEQ(1) | SATA_PHY_TXSWING(3) | SATA_PHY_ENPLL(1);
 
writel(val, ahci_base + SATA_P0PHYCR_REG);
 }
 
+static u32 ahci_da850_calculate_mpy(unsigned long refclk_rate)
+{
+   u32 pll_output = 15, needed;
+
+   /*
+* We need to determine the value of the multiplier (MPY) bits.
+* In order to include the 12.5 multiplier we need to first divide
+* the refclk rate by ten.
+*
+* __div64_32() turned out to be unreliable, sometimes returning
+* false results.
+*/
+   WARN((refclk_rate % 10) != 0, "refclk must be divisible by 10");
+   needed = pll_output / (refclk_rate / 10);
+
+   /*
+* What we have now is (multiplier * 10).
+*
+* Let's determine the actual register value we need to write.
+*/
+
+   switch (needed) {
+   case 50:
+   return 0x1;
+   case 60:
+   return 0x2;
+   case 80:
+   return 0x4;
+   case 100:
+   return 0x5;
+   case 120:
+   return 0x6;
+   case 125:
+   return 0x7;
+   case 150:
+   return 0x8;
+   case 200:
+   return 0x9;
+   case 250:
+   return 0xa;
+   default:
+   /*
+* We should have divided evenly - if not, return an invalid
+* value.
+*/
+   return 0;
+   }
+}
+
 static int ahci_da850_softreset(struct ata_link *link,
unsigned int *class, unsigned long deadline)
 {
@@ -126,9 +165,10 @@ static int ahci_da850_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
struct ahci_host_priv *hpriv;
-   struct resource *res;
void __iomem *pwrdn_reg;
+   struct resource *res;
struct clk *clk;
+   u32 mpy;
int rc;
 
hpriv = ahci_platform_get_resources(pdev);
@@ -150,6 +190,27 @@ static int ahci_da850_probe(struct platform_device *pdev)
hpriv->clks[0] = clk;
}
 
+   /*
+* The second clock used by ahci-da850 is the external REFCLK. If we
+* didn't get it from ahci_platform_get_resources(), let's try to
+* specify the con_id in clk_get().
+*/
+   if (!hpriv->clks[1]) {
+   clk = clk_get(dev, "refclk");
+   if (IS_ERR(clk)) {
+   dev_err(dev, "unable to obtain the reference clock");
+   return -ENODEV;
+   } else {
+   hpriv->clks[1] = clk;
+   }
+   }
+
+   mpy = ahci_da850_calculate_mpy(clk_get_rate(hpriv->clks[1]));
+   if (mpy == 0) {
+   dev_err(dev, "invalid REFCLK multiplier value: 0x%x", mpy);
+   return -EINVAL;
+   }
+
rc = ahci_platform_enable_resources(hpriv);
if (rc)
return rc;
@@ -162,7 +223,7 @@ static int ahci_da850_probe(struct platform_device *pdev)
if (!pwrdn_reg)
goto disable_resources;
 
-   da850_sata_init(dev, pwrdn_reg, hpriv->mmio);
+   da850_sata_init(dev, pwrdn_reg, hpriv->mmio, mpy);
 
rc = ahci_platform_init_host(pdev, hpriv, _da850_port_info,
 _platform_sht);
-- 
2.9.3

[PATCH v6 04/14] sata: ahci-da850: get the sata clock using a connection id

[Bartosz Golaszewski]

In preparation for using two clocks in the driver (the sysclk2-based
clock and the external REFCLK), check if we got a functional clock
after calling ahci_platform_get_resources(). If not, retry calling
clk_get() with con_id specified.

Signed-off-by: Bartosz Golaszewski 
Acked-by: Tejun Heo 
---
 drivers/ata/ahci_da850.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/ata/ahci_da850.c b/drivers/ata/ahci_da850.c
index 267a3d3..8cfdc86 100644
--- a/drivers/ata/ahci_da850.c
+++ b/drivers/ata/ahci_da850.c
@@ -71,12 +71,28 @@ static int ahci_da850_probe(struct platform_device *pdev)
struct ahci_host_priv *hpriv;
struct resource *res;
void __iomem *pwrdn_reg;
+   struct clk *clk;
int rc;
 
hpriv = ahci_platform_get_resources(pdev);
if (IS_ERR(hpriv))
return PTR_ERR(hpriv);
 
+   /*
+* Internally ahci_platform_get_resources() calls clk_get(dev, NULL)
+* when trying to obtain the first clock. This SATA controller uses
+* two clocks for which we specify two connection ids. If we don't
+* have a clock at this point - call clk_get() again with
+* con_id = "sata".
+*/
+   if (!hpriv->clks[0]) {
+   clk = clk_get(dev, "sata");
+   if (IS_ERR(clk))
+   return PTR_ERR(clk);
+
+   hpriv->clks[0] = clk;
+   }
+
rc = ahci_platform_enable_resources(hpriv);
if (rc)
return rc;
-- 
2.9.3

[PATCH v6 04/14] sata: ahci-da850: get the sata clock using a connection id

[Bartosz Golaszewski]

In preparation for using two clocks in the driver (the sysclk2-based
clock and the external REFCLK), check if we got a functional clock
after calling ahci_platform_get_resources(). If not, retry calling
clk_get() with con_id specified.

Signed-off-by: Bartosz Golaszewski 
Acked-by: Tejun Heo 
---
 drivers/ata/ahci_da850.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/ata/ahci_da850.c b/drivers/ata/ahci_da850.c
index 267a3d3..8cfdc86 100644
--- a/drivers/ata/ahci_da850.c
+++ b/drivers/ata/ahci_da850.c
@@ -71,12 +71,28 @@ static int ahci_da850_probe(struct platform_device *pdev)
struct ahci_host_priv *hpriv;
struct resource *res;
void __iomem *pwrdn_reg;
+   struct clk *clk;
int rc;
 
hpriv = ahci_platform_get_resources(pdev);
if (IS_ERR(hpriv))
return PTR_ERR(hpriv);
 
+   /*
+* Internally ahci_platform_get_resources() calls clk_get(dev, NULL)
+* when trying to obtain the first clock. This SATA controller uses
+* two clocks for which we specify two connection ids. If we don't
+* have a clock at this point - call clk_get() again with
+* con_id = "sata".
+*/
+   if (!hpriv->clks[0]) {
+   clk = clk_get(dev, "sata");
+   if (IS_ERR(clk))
+   return PTR_ERR(clk);
+
+   hpriv->clks[0] = clk;
+   }
+
rc = ahci_platform_enable_resources(hpriv);
if (rc)
return rc;
-- 
2.9.3

[PATCH v6 02/14] ARM: davinci_all_defconfig: enable SATA modules

[Bartosz Golaszewski]

Add the da850-ahci driver to davinci defconfig.

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/configs/davinci_all_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/davinci_all_defconfig 
b/arch/arm/configs/davinci_all_defconfig
index 8806754..a1b9c58 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -78,6 +78,8 @@ CONFIG_IDE=m
 CONFIG_BLK_DEV_PALMCHIP_BK3710=m
 CONFIG_SCSI=m
 CONFIG_BLK_DEV_SD=m
+CONFIG_ATA=m
+CONFIG_AHCI_DA850=m
 CONFIG_NETDEVICES=y
 CONFIG_NETCONSOLE=y
 CONFIG_TUN=m
-- 
2.9.3

[PATCH v6 02/14] ARM: davinci_all_defconfig: enable SATA modules

[Bartosz Golaszewski]

Add the da850-ahci driver to davinci defconfig.

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/configs/davinci_all_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/davinci_all_defconfig 
b/arch/arm/configs/davinci_all_defconfig
index 8806754..a1b9c58 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -78,6 +78,8 @@ CONFIG_IDE=m
 CONFIG_BLK_DEV_PALMCHIP_BK3710=m
 CONFIG_SCSI=m
 CONFIG_BLK_DEV_SD=m
+CONFIG_ATA=m
+CONFIG_AHCI_DA850=m
 CONFIG_NETDEVICES=y
 CONFIG_NETCONSOLE=y
 CONFIG_TUN=m
-- 
2.9.3

[PATCH v6 03/14] ARM: davinci: add a clock lookup entry for the SATA clock

[Bartosz Golaszewski]

This entry is needed for the ahci driver to get a functional clock.

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/da8xx-dt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 9ee44da..b83e5d1 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -42,6 +42,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] 
__initdata = {
OF_DEV_AUXDATA("ti,da830-ohci", 0x01e25000, "ohci-da8xx", NULL),
OF_DEV_AUXDATA("ti,da830-musb", 0x01e0, "musb-da8xx", NULL),
OF_DEV_AUXDATA("ti,da830-usb-phy", 0x01c1417c, "da8xx-usb-phy", NULL),
+   OF_DEV_AUXDATA("ti,da850-ahci", 0x01e18000, "ahci_da850", NULL),
{}
 };
 
-- 
2.9.3

[PATCH v6 03/14] ARM: davinci: add a clock lookup entry for the SATA clock

[Bartosz Golaszewski]

This entry is needed for the ahci driver to get a functional clock.

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/da8xx-dt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 9ee44da..b83e5d1 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -42,6 +42,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] 
__initdata = {
OF_DEV_AUXDATA("ti,da830-ohci", 0x01e25000, "ohci-da8xx", NULL),
OF_DEV_AUXDATA("ti,da830-musb", 0x01e0, "musb-da8xx", NULL),
OF_DEV_AUXDATA("ti,da830-usb-phy", 0x01c1417c, "da8xx-usb-phy", NULL),
+   OF_DEV_AUXDATA("ti,da850-ahci", 0x01e18000, "ahci_da850", NULL),
{}
 };
 
-- 
2.9.3

[PATCH v6 05/14] ARM: davinci: da850: add con_id for the SATA clock

[Bartosz Golaszewski]

The ahci-da850 SATA driver is now capable of retrieving clocks by
con_id. Add the connection id for the sysclk2-derived SATA clock.

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/da850.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 1d873d1..dbf1daa 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -571,7 +571,7 @@ static struct clk_lookup da850_clks[] = {
CLK("spi_davinci.0",NULL,   _clk),
CLK("spi_davinci.1",NULL,   _clk),
CLK("vpif", NULL,   _clk),
-   CLK("ahci_da850",   NULL,   _clk),
+   CLK("ahci_da850",   "sata", _clk),
CLK("davinci-rproc.0",  NULL,   _clk),
CLK(NULL,   NULL,   _clk),
CLK("ehrpwm.0", "fck",  _clk),
-- 
2.9.3

[PATCH v6 05/14] ARM: davinci: da850: add con_id for the SATA clock

[Bartosz Golaszewski]

The ahci-da850 SATA driver is now capable of retrieving clocks by
con_id. Add the connection id for the sysclk2-derived SATA clock.

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/da850.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 1d873d1..dbf1daa 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -571,7 +571,7 @@ static struct clk_lookup da850_clks[] = {
CLK("spi_davinci.0",NULL,   _clk),
CLK("spi_davinci.1",NULL,   _clk),
CLK("vpif", NULL,   _clk),
-   CLK("ahci_da850",   NULL,   _clk),
+   CLK("ahci_da850",   "sata", _clk),
CLK("davinci-rproc.0",  NULL,   _clk),
CLK(NULL,   NULL,   _clk),
CLK("ehrpwm.0", "fck",  _clk),
-- 
2.9.3