date:20170218

On Tue, Jan 31, 2017 at 07:41:51AM -0800, James Bottomley wrote:

> > Please-please-please, let's not use WARN for something that is not a
> > kernel bug and is user-triggerable.
> 
> It is a kernel bug and it should not be user triggerable, so it should
> have a warn_on or bug_on.  It means something called a data setup
> function with no data.  There's actually a root cause that patches like
> this won't fix, can we find it?

The root cause is unfixable without access to TARDIS and dose of
antipsychotics sufficient to prevent /dev/sg API creation.

What happens is that write to /dev/sg is given a request with non-zero
->iovec_count combined with zero ->dxfer_len.  Or with ->dxferp pointing
to an array full of empty iovecs.

AFAICS, the minimal fix would be something like this:

YAMissingSanityCheck in /dev/sg

write permission to /dev/sg shouldn't be equivalent to the ability to trigger
BUG_ON() while holding spinlocks...

Cc: sta...@vger.kernel.org
Signed-off-by: Al Viro 
---

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index dbe5b4b95df0..121de0aaa6ad 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -1753,6 +1753,10 @@ sg_start_req(Sg_request *srp, unsigned char *cmd)
return res;
 
iov_iter_truncate(, hp->dxfer_len);
+   if (!iov_iter_count()) {
+   kfree(iov);
+   return -EINVAL;
+   }
 
res = blk_rq_map_user_iov(q, rq, md, , GFP_ATOMIC);
kfree(iov);

Re: scsi: BUG in scsi_init_io

On Tue, Jan 31, 2017 at 07:41:51AM -0800, James Bottomley wrote:

> > Please-please-please, let's not use WARN for something that is not a
> > kernel bug and is user-triggerable.
> 
> It is a kernel bug and it should not be user triggerable, so it should
> have a warn_on or bug_on.  It means something called a data setup
> function with no data.  There's actually a root cause that patches like
> this won't fix, can we find it?

The root cause is unfixable without access to TARDIS and dose of
antipsychotics sufficient to prevent /dev/sg API creation.

What happens is that write to /dev/sg is given a request with non-zero
->iovec_count combined with zero ->dxfer_len.  Or with ->dxferp pointing
to an array full of empty iovecs.

AFAICS, the minimal fix would be something like this:

YAMissingSanityCheck in /dev/sg

write permission to /dev/sg shouldn't be equivalent to the ability to trigger
BUG_ON() while holding spinlocks...

Cc: sta...@vger.kernel.org
Signed-off-by: Al Viro 
---

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index dbe5b4b95df0..121de0aaa6ad 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -1753,6 +1753,10 @@ sg_start_req(Sg_request *srp, unsigned char *cmd)
return res;
 
iov_iter_truncate(, hp->dxfer_len);
+   if (!iov_iter_count()) {
+   kfree(iov);
+   return -EINVAL;
+   }
 
res = blk_rq_map_user_iov(q, rq, md, , GFP_ATOMIC);
kfree(iov);

Re: [PATCH v3 4/5] vfs: Add timestamp_truncate() api

Hi Deepa,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.10-rc8 next-20170217]
[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/Deepa-Dinamani/vfs-Add-timestamp-range-check-support/20170219-073734
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   fs/inode.c:1679: warning: No description found for parameter 'rcu'
   fs/inode.c:2125: warning: No description found for parameter 'inode'
>> fs/inode.c:2125: warning: Excess function parameter 'gran' description in 
>> 'timestamp_truncate'
   include/linux/jbd2.h:442: warning: No description found for parameter 
'i_transaction'
   include/linux/jbd2.h:442: warning: No description found for parameter 
'i_next_transaction'
   include/linux/jbd2.h:442: warning: No description found for parameter 
'i_list'
   include/linux/jbd2.h:442: warning: No description found for parameter 
'i_vfs_inode'
   include/linux/jbd2.h:442: warning: No description found for parameter 
'i_flags'
   include/linux/jbd2.h:494: warning: No description found for parameter 
'h_rsv_handle'
   include/linux/jbd2.h:494: warning: No description found for parameter 
'h_reserved'
   include/linux/jbd2.h:494: warning: No description found for parameter 
'h_type'
   include/linux/jbd2.h:494: warning: No description found for parameter 
'h_line_no'
   include/linux/jbd2.h:494: warning: No description found for parameter 
'h_start_jiffies'
   include/linux/jbd2.h:494: warning: No description found for parameter 
'h_requested_credits'
   include/linux/jbd2.h:1047: warning: No description found for parameter 
'j_chkpt_bhs[JBD2_NR_BATCH]'
   include/linux/jbd2.h:1047: warning: No description found for parameter 
'j_devname[BDEVNAME_SIZE+24]'
   include/linux/jbd2.h:1047: warning: No description found for parameter 
'j_average_commit_time'
   include/linux/jbd2.h:1047: warning: No description found for parameter 
'j_min_batch_time'
   include/linux/jbd2.h:1047: warning: No description found for parameter 
'j_max_batch_time'
   include/linux/jbd2.h:1047: warning: No description found for parameter 
'j_commit_callback'
   include/linux/jbd2.h:1047: warning: No description found for parameter 
'j_failed_commit'
   include/linux/jbd2.h:1047: warning: No description found for parameter 
'j_chksum_driver'
   include/linux/jbd2.h:1047: warning: No description found for parameter 
'j_csum_seed'
   fs/jbd2/transaction.c:428: warning: No description found for parameter 
'rsv_blocks'
   fs/jbd2/transaction.c:428: warning: No description found for parameter 
'gfp_mask'
   fs/jbd2/transaction.c:428: warning: No description found for parameter 'type'
   fs/jbd2/transaction.c:428: warning: No description found for parameter 
'line_no'
   fs/jbd2/transaction.c:504: warning: No description found for parameter 'type'
   fs/jbd2/transaction.c:504: warning: No description found for parameter 
'line_no'
   fs/jbd2/transaction.c:634: warning: No description found for parameter 
'gfp_mask'

vim +2125 fs/inode.c

  2109  
  2110  void inode_nohighmem(struct inode *inode)
  2111  {
  2112  mapping_set_gfp_mask(inode->i_mapping, GFP_USER);
  2113  }
  2114  EXPORT_SYMBOL(inode_nohighmem);
  2115  
  2116  /**
  2117   * fs_timespec_trunc - Truncate timespec to a granularity
  2118   * @t: Timespec
  2119   * @gran: Granularity in ns.
  2120   *
  2121   * Truncate a timespec to a granularity. Always rounds down. gran must
  2122   * not be 0 nor greater than a second (NSEC_PER_SEC, or 10^9 ns).
  2123   */
  2124  struct timespec timestamp_truncate(struct timespec t, struct inode 
*inode)
> 2125  {
  2126  struct super_block *sb = inode->i_sb;
  2127  unsigned int gran = sb->s_time_gran;
  2128  
  2129  t.tv_sec = clamp_t(time64_t, t.tv_sec, sb->s_time_min, 
sb->s_time_max);
  2130  
  2131  /* Avoid division in the common cases 1 ns and 1 s. */
  2132  if (gran == 1) {
  2133  /* nothing */

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


.config.gz
Description: application/gzip

Re: [PATCH v3 4/5] vfs: Add timestamp_truncate() api

Hi Deepa,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.10-rc8 next-20170217]
[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/Deepa-Dinamani/vfs-Add-timestamp-range-check-support/20170219-073734
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   fs/inode.c:1679: warning: No description found for parameter 'rcu'
   fs/inode.c:2125: warning: No description found for parameter 'inode'
>> fs/inode.c:2125: warning: Excess function parameter 'gran' description in 
>> 'timestamp_truncate'
   include/linux/jbd2.h:442: warning: No description found for parameter 
'i_transaction'
   include/linux/jbd2.h:442: warning: No description found for parameter 
'i_next_transaction'
   include/linux/jbd2.h:442: warning: No description found for parameter 
'i_list'
   include/linux/jbd2.h:442: warning: No description found for parameter 
'i_vfs_inode'
   include/linux/jbd2.h:442: warning: No description found for parameter 
'i_flags'
   include/linux/jbd2.h:494: warning: No description found for parameter 
'h_rsv_handle'
   include/linux/jbd2.h:494: warning: No description found for parameter 
'h_reserved'
   include/linux/jbd2.h:494: warning: No description found for parameter 
'h_type'
   include/linux/jbd2.h:494: warning: No description found for parameter 
'h_line_no'
   include/linux/jbd2.h:494: warning: No description found for parameter 
'h_start_jiffies'
   include/linux/jbd2.h:494: warning: No description found for parameter 
'h_requested_credits'
   include/linux/jbd2.h:1047: warning: No description found for parameter 
'j_chkpt_bhs[JBD2_NR_BATCH]'
   include/linux/jbd2.h:1047: warning: No description found for parameter 
'j_devname[BDEVNAME_SIZE+24]'
   include/linux/jbd2.h:1047: warning: No description found for parameter 
'j_average_commit_time'
   include/linux/jbd2.h:1047: warning: No description found for parameter 
'j_min_batch_time'
   include/linux/jbd2.h:1047: warning: No description found for parameter 
'j_max_batch_time'
   include/linux/jbd2.h:1047: warning: No description found for parameter 
'j_commit_callback'
   include/linux/jbd2.h:1047: warning: No description found for parameter 
'j_failed_commit'
   include/linux/jbd2.h:1047: warning: No description found for parameter 
'j_chksum_driver'
   include/linux/jbd2.h:1047: warning: No description found for parameter 
'j_csum_seed'
   fs/jbd2/transaction.c:428: warning: No description found for parameter 
'rsv_blocks'
   fs/jbd2/transaction.c:428: warning: No description found for parameter 
'gfp_mask'
   fs/jbd2/transaction.c:428: warning: No description found for parameter 'type'
   fs/jbd2/transaction.c:428: warning: No description found for parameter 
'line_no'
   fs/jbd2/transaction.c:504: warning: No description found for parameter 'type'
   fs/jbd2/transaction.c:504: warning: No description found for parameter 
'line_no'
   fs/jbd2/transaction.c:634: warning: No description found for parameter 
'gfp_mask'

vim +2125 fs/inode.c

  2109  
  2110  void inode_nohighmem(struct inode *inode)
  2111  {
  2112  mapping_set_gfp_mask(inode->i_mapping, GFP_USER);
  2113  }
  2114  EXPORT_SYMBOL(inode_nohighmem);
  2115  
  2116  /**
  2117   * fs_timespec_trunc - Truncate timespec to a granularity
  2118   * @t: Timespec
  2119   * @gran: Granularity in ns.
  2120   *
  2121   * Truncate a timespec to a granularity. Always rounds down. gran must
  2122   * not be 0 nor greater than a second (NSEC_PER_SEC, or 10^9 ns).
  2123   */
  2124  struct timespec timestamp_truncate(struct timespec t, struct inode 
*inode)
> 2125  {
  2126  struct super_block *sb = inode->i_sb;
  2127  unsigned int gran = sb->s_time_gran;
  2128  
  2129  t.tv_sec = clamp_t(time64_t, t.tv_sec, sb->s_time_min, 
sb->s_time_max);
  2130  
  2131  /* Avoid division in the common cases 1 ns and 1 s. */
  2132  if (gran == 1) {
  2133  /* nothing */

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


.config.gz
Description: application/gzip

Re: [PATCH repost] ptr_ring: fix race conditions when resizing

From: "Michael S. Tsirkin" 
Date: Sun, 19 Feb 2017 07:17:17 +0200

> Dave, could you merge this before 4.10? If not - I can try.

I just sent my last pull request to Linus, please merge it to
him directly.

Thanks.

Re: [PATCH repost] ptr_ring: fix race conditions when resizing

From: "Michael S. Tsirkin" 
Date: Sun, 19 Feb 2017 07:17:17 +0200

> Dave, could you merge this before 4.10? If not - I can try.

I just sent my last pull request to Linus, please merge it to
him directly.

Thanks.

Re: [PATCH v3 4/9] vhost/scsi: Don't reinvent the wheel but use existing llist API

Hi Byungchul,

On Tue, 2017-02-14 at 16:26 +0900, Byungchul Park wrote:
> Although llist provides proper APIs, they are not used. Make them used.
> 
> Signed-off-by: Byungchul Park 
> ---
>  drivers/vhost/scsi.c | 11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)

Acked-by: Nicholas Bellinger

Re: [PATCH v3 4/9] vhost/scsi: Don't reinvent the wheel but use existing llist API

Hi Byungchul,

On Tue, 2017-02-14 at 16:26 +0900, Byungchul Park wrote:
> Although llist provides proper APIs, they are not used. Make them used.
> 
> Signed-off-by: Byungchul Park 
> ---
>  drivers/vhost/scsi.c | 11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)

Acked-by: Nicholas Bellinger

[PATCH] tools/vm: Fix possible resource leak in page_owner_sort.c

2017-02-18 Thread Saurabh Badhwar

Fix possible resource leak in tools/vm/page_owner_sort.c
Signed-off-by: Saurabh Badhwar 
---
 tools/vm/page_owner_sort.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/vm/page_owner_sort.c b/tools/vm/page_owner_sort.c
index f1c055f..8346261 100644
--- a/tools/vm/page_owner_sort.c
+++ b/tools/vm/page_owner_sort.c
@@ -110,6 +110,8 @@ int main(int argc, char **argv)
buf = malloc(BUF_SIZE);
if (!list || !buf) {
printf("Out of memory\n");
+   fclose(fin);
+   fclose(fout);
exit(1);
}
 
@@ -144,6 +146,7 @@ int main(int argc, char **argv)
 
for (i = 0; i < count; i++)
fprintf(fout, "%d times:\n%s\n", list2[i].num, list2[i].txt);
-
+   
+   fclose(fout);
return 0;
 }
-- 
2.9.3

[PATCH] tools/vm: Fix possible resource leak in page_owner_sort.c

2017-02-18 Thread Saurabh Badhwar

Fix possible resource leak in tools/vm/page_owner_sort.c
Signed-off-by: Saurabh Badhwar 
---
 tools/vm/page_owner_sort.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/vm/page_owner_sort.c b/tools/vm/page_owner_sort.c
index f1c055f..8346261 100644
--- a/tools/vm/page_owner_sort.c
+++ b/tools/vm/page_owner_sort.c
@@ -110,6 +110,8 @@ int main(int argc, char **argv)
buf = malloc(BUF_SIZE);
if (!list || !buf) {
printf("Out of memory\n");
+   fclose(fin);
+   fclose(fout);
exit(1);
}
 
@@ -144,6 +146,7 @@ int main(int argc, char **argv)
 
for (i = 0; i < count; i++)
fprintf(fout, "%d times:\n%s\n", list2[i].num, list2[i].txt);
-
+   
+   fclose(fout);
return 0;
 }
-- 
2.9.3

Re: [PATCH] uapi: fix linux/target_core_user.h userspace compilation errors

Hi Dmitry,

On Wed, 2017-02-15 at 23:04 +0300, Dmitry V. Levin wrote:
> Consistently use types from linux/types.h to fix the following
> linux/target_core_user.h userspace compilation errors:
> 
> /usr/include/linux/target_core_user.h:108:4: error: unknown type name 
> 'uint32_t'
> uint32_t iov_cnt;
> /usr/include/linux/target_core_user.h:109:4: error: unknown type name 
> 'uint32_t'
> uint32_t iov_bidi_cnt;
> /usr/include/linux/target_core_user.h:110:4: error: unknown type name 
> 'uint32_t'
> uint32_t iov_dif_cnt;
> /usr/include/linux/target_core_user.h:111:4: error: unknown type name 
> 'uint64_t'
> uint64_t cdb_off;
> /usr/include/linux/target_core_user.h:112:4: error: unknown type name 
> 'uint64_t'
> uint64_t __pad1;
> /usr/include/linux/target_core_user.h:113:4: error: unknown type name 
> 'uint64_t'
> uint64_t __pad2;
> /usr/include/linux/target_core_user.h:117:4: error: unknown type name 
> 'uint8_t'
> uint8_t scsi_status;
> /usr/include/linux/target_core_user.h:118:4: error: unknown type name 
> 'uint8_t'
> uint8_t __pad1;
> /usr/include/linux/target_core_user.h:119:4: error: unknown type name 
> 'uint16_t'
> uint16_t __pad2;
> /usr/include/linux/target_core_user.h:120:4: error: unknown type name 
> 'uint32_t'
> uint32_t __pad3;
> 
> Signed-off-by: Dmitry V. Levin 
> ---
>  include/uapi/linux/target_core_user.h | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)

Applied to target-pending/for-next.

Thank you.

Re: [PATCH] uapi: fix linux/target_core_user.h userspace compilation errors

Hi Dmitry,

On Wed, 2017-02-15 at 23:04 +0300, Dmitry V. Levin wrote:
> Consistently use types from linux/types.h to fix the following
> linux/target_core_user.h userspace compilation errors:
> 
> /usr/include/linux/target_core_user.h:108:4: error: unknown type name 
> 'uint32_t'
> uint32_t iov_cnt;
> /usr/include/linux/target_core_user.h:109:4: error: unknown type name 
> 'uint32_t'
> uint32_t iov_bidi_cnt;
> /usr/include/linux/target_core_user.h:110:4: error: unknown type name 
> 'uint32_t'
> uint32_t iov_dif_cnt;
> /usr/include/linux/target_core_user.h:111:4: error: unknown type name 
> 'uint64_t'
> uint64_t cdb_off;
> /usr/include/linux/target_core_user.h:112:4: error: unknown type name 
> 'uint64_t'
> uint64_t __pad1;
> /usr/include/linux/target_core_user.h:113:4: error: unknown type name 
> 'uint64_t'
> uint64_t __pad2;
> /usr/include/linux/target_core_user.h:117:4: error: unknown type name 
> 'uint8_t'
> uint8_t scsi_status;
> /usr/include/linux/target_core_user.h:118:4: error: unknown type name 
> 'uint8_t'
> uint8_t __pad1;
> /usr/include/linux/target_core_user.h:119:4: error: unknown type name 
> 'uint16_t'
> uint16_t __pad2;
> /usr/include/linux/target_core_user.h:120:4: error: unknown type name 
> 'uint32_t'
> uint32_t __pad3;
> 
> Signed-off-by: Dmitry V. Levin 
> ---
>  include/uapi/linux/target_core_user.h | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)

Applied to target-pending/for-next.

Thank you.

Re: net: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected in skb_array_produce

On Sat, Feb 18, 2017 at 06:28:39PM +0100, Dmitry Vyukov wrote:
> On Fri, Feb 10, 2017 at 6:17 AM, Jason Wang  wrote:
> >
> >
> > On 2017年02月10日 02:10, Michael S. Tsirkin wrote:
> >>
> >> On Thu, Feb 09, 2017 at 05:02:31AM -0500, Jason Wang wrote:
> >>>
> >>> - Original Message -
> 
>  Hello,
> 
>  I've got the following report while running syzkaller fuzzer on mmotm
>  (git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git)
>  remotes/mmotm/auto-latest ee4ba7533626ba7bf2f8b992266467ac9fdc045e:
> 
> >>> [...]
> >>>
>  other info that might help us debug this:
> 
>    Possible interrupt unsafe locking scenario:
> 
>  CPU0CPU1
>  
> lock(&(>consumer_lock)->rlock);
>  local_irq_disable();
>  lock(&(>producer_lock)->rlock);
>  lock(&(>consumer_lock)->rlock);
> 
>   lock(&(>producer_lock)->rlock);
> 
> >>> Thanks a lot for the testing.
> >>>
> >>> Looks like we could address this by using skb_array_consume_bh() instead.
> >>>
> >>> Could you pls verify if the following patch works?
> >>
> >> I think we should use _bh for the produce call as well,
> >> since resizing takes the producer lock.
> >
> > Looks not since irq was disabled during resizing?
> 
> 
> Hello,
> 
> Is there a fix for this that we can pick up?
> This killed 10'000 VMs on our testing infra over the last day. Still
> happening on linux-next.
> 
> Thanks

I posted a fix.  ptr_ring: fix race conditions when resizing
Just reposted.  I'll push into linux-next ASAP.

-- 
MST

Re: net: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected in skb_array_produce

On Sat, Feb 18, 2017 at 06:28:39PM +0100, Dmitry Vyukov wrote:
> On Fri, Feb 10, 2017 at 6:17 AM, Jason Wang  wrote:
> >
> >
> > On 2017年02月10日 02:10, Michael S. Tsirkin wrote:
> >>
> >> On Thu, Feb 09, 2017 at 05:02:31AM -0500, Jason Wang wrote:
> >>>
> >>> - Original Message -
> 
>  Hello,
> 
>  I've got the following report while running syzkaller fuzzer on mmotm
>  (git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git)
>  remotes/mmotm/auto-latest ee4ba7533626ba7bf2f8b992266467ac9fdc045e:
> 
> >>> [...]
> >>>
>  other info that might help us debug this:
> 
>    Possible interrupt unsafe locking scenario:
> 
>  CPU0CPU1
>  
> lock(&(>consumer_lock)->rlock);
>  local_irq_disable();
>  lock(&(>producer_lock)->rlock);
>  lock(&(>consumer_lock)->rlock);
> 
>   lock(&(>producer_lock)->rlock);
> 
> >>> Thanks a lot for the testing.
> >>>
> >>> Looks like we could address this by using skb_array_consume_bh() instead.
> >>>
> >>> Could you pls verify if the following patch works?
> >>
> >> I think we should use _bh for the produce call as well,
> >> since resizing takes the producer lock.
> >
> > Looks not since irq was disabled during resizing?
> 
> 
> Hello,
> 
> Is there a fix for this that we can pick up?
> This killed 10'000 VMs on our testing infra over the last day. Still
> happening on linux-next.
> 
> Thanks

I posted a fix.  ptr_ring: fix race conditions when resizing
Just reposted.  I'll push into linux-next ASAP.

-- 
MST

[PATCH repost] ptr_ring: fix race conditions when resizing

Resizing currently drops consumer lock.  This can cause entries to be
reordered, which isn't good in itself.  More importantly, consumer can
detect a false ring empty condition and block forever.

Further, nesting of consumer within producer lock is problematic for
tun, since it produces entries in a BH, which causes a lock order
reversal:

   CPU0CPU1
   
  consume:
  lock(&(>consumer_lock)->rlock);
   resize:
   local_irq_disable();
   lock(&(>producer_lock)->rlock);
   lock(&(>consumer_lock)->rlock);
  
  produce:
  lock(&(>producer_lock)->rlock);

To fix, nest producer lock within consumer lock during resize,
and keep consumer lock during the whole swap operation.

Reported-by: Dmitry Vyukov 
Cc: sta...@vger.kernel.org
Cc: "David S. Miller" 
Acked-by: Jason Wang 
Signed-off-by: Michael S. Tsirkin 
---

Dave, could you merge this before 4.10? If not - I can try.

 include/linux/ptr_ring.h | 36 +++-
 1 file changed, 31 insertions(+), 5 deletions(-)

diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
index 2052011..6c70444 100644
--- a/include/linux/ptr_ring.h
+++ b/include/linux/ptr_ring.h
@@ -111,6 +111,11 @@ static inline int __ptr_ring_produce(struct ptr_ring *r, 
void *ptr)
return 0;
 }
 
+/*
+ * Note: resize (below) nests producer lock within consumer lock, so if you
+ * consume in interrupt or BH context, you must disable interrupts/BH when
+ * calling this.
+ */
 static inline int ptr_ring_produce(struct ptr_ring *r, void *ptr)
 {
int ret;
@@ -242,6 +247,11 @@ static inline void *__ptr_ring_consume(struct ptr_ring *r)
return ptr;
 }
 
+/*
+ * Note: resize (below) nests producer lock within consumer lock, so if you
+ * call this in interrupt or BH context, you must disable interrupts/BH when
+ * producing.
+ */
 static inline void *ptr_ring_consume(struct ptr_ring *r)
 {
void *ptr;
@@ -357,7 +367,7 @@ static inline void **__ptr_ring_swap_queue(struct ptr_ring 
*r, void **queue,
void **old;
void *ptr;
 
-   while ((ptr = ptr_ring_consume(r)))
+   while ((ptr = __ptr_ring_consume(r)))
if (producer < size)
queue[producer++] = ptr;
else if (destroy)
@@ -372,6 +382,12 @@ static inline void **__ptr_ring_swap_queue(struct ptr_ring 
*r, void **queue,
return old;
 }
 
+/*
+ * Note: producer lock is nested within consumer lock, so if you
+ * resize you must make sure all uses nest correctly.
+ * In particular if you consume ring in interrupt or BH context, you must
+ * disable interrupts/BH when doing so.
+ */
 static inline int ptr_ring_resize(struct ptr_ring *r, int size, gfp_t gfp,
  void (*destroy)(void *))
 {
@@ -382,17 +398,25 @@ static inline int ptr_ring_resize(struct ptr_ring *r, int 
size, gfp_t gfp,
if (!queue)
return -ENOMEM;
 
-   spin_lock_irqsave(&(r)->producer_lock, flags);
+   spin_lock_irqsave(&(r)->consumer_lock, flags);
+   spin_lock(&(r)->producer_lock);
 
old = __ptr_ring_swap_queue(r, queue, size, gfp, destroy);
 
-   spin_unlock_irqrestore(&(r)->producer_lock, flags);
+   spin_unlock(&(r)->producer_lock);
+   spin_unlock_irqrestore(&(r)->consumer_lock, flags);
 
kfree(old);
 
return 0;
 }
 
+/*
+ * Note: producer lock is nested within consumer lock, so if you
+ * resize you must make sure all uses nest correctly.
+ * In particular if you consume ring in interrupt or BH context, you must
+ * disable interrupts/BH when doing so.
+ */
 static inline int ptr_ring_resize_multiple(struct ptr_ring **rings, int nrings,
   int size,
   gfp_t gfp, void (*destroy)(void *))
@@ -412,10 +436,12 @@ static inline int ptr_ring_resize_multiple(struct 
ptr_ring **rings, int nrings,
}
 
for (i = 0; i < nrings; ++i) {
-   spin_lock_irqsave(&(rings[i])->producer_lock, flags);
+   spin_lock_irqsave(&(rings[i])->consumer_lock, flags);
+   spin_lock(&(rings[i])->producer_lock);
queues[i] = __ptr_ring_swap_queue(rings[i], queues[i],
  size, gfp, destroy);
-   spin_unlock_irqrestore(&(rings[i])->producer_lock, flags);
+   spin_unlock(&(rings[i])->producer_lock);
+   spin_unlock_irqrestore(&(rings[i])->consumer_lock, flags);
}
 
for (i = 0; i < nrings; ++i)
-- 
MST

Re: [PATCH net-next] virito-net: set queues after reset during xdp_set

On Fri, Feb 17, 2017 at 01:10:08PM +0800, Jason Wang wrote:
> 
> 
> On 2017年02月17日 12:53, John Fastabend wrote:
> > On 17-02-15 01:08 AM, Jason Wang wrote:
> > > We set queues before reset which will cause a crash[1]. This is
> > > because is_xdp_raw_buffer_queue() depends on the old xdp queue pairs
> > > number to do the correct detection. So fix this by:
> > > 
> > > - set queues after reset, to keep the old vi->curr_queue_pairs. (in
> > >fact setting queues before reset does not works since after feature
> > >set, all queue pairs were enabled by default during reset).
> > > - change xdp_queue_pairs only after virtnet_reset() is succeed.
> > > 
> > > [1]
> > I'm guessing this occurs when enabling XDP while receiving lots of traffic?
> 
> I hit this then disabling XDP while receiving lots of traffic.
> 
> > 
> > > [   74.328168] general protection fault:  [#1] SMP
> > > [   74.328625] Modules linked in: nfsd xfs libcrc32c virtio_net virtio_pci
> > > [   74.329117] CPU: 0 PID: 2849 Comm: xdp2 Not tainted 4.10.0-rc7+ #499
> > > [   74.329577] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), 
> > > BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
> > > [   74.330424] task: 88007a894000 task.stack: c90004388000
> > > [   74.330844] RIP: 0010:skb_release_head_state+0x28/0x80
> > > [   74.331298] RSP: 0018:c9000438b8d0 EFLAGS: 00010206
> > > [   74.331676] RAX:  RBX: 88007ad96300 RCX: 
> > > 
> > > [   74.332217] RDX: 88007fc137a8 RSI: 88007fc0db28 RDI: 
> > > 0001bf0001be
> > > [   74.332758] RBP: c9000438b8d8 R08: 0005008f R09: 
> > > 05f9
> > > [   74.333274] R10: 88007d001700 R11: 820a8a4d R12: 
> > > 88007ad96300
> > > [   74.333787] R13: 0002 R14: 880036604000 R15: 
> > > 77ff8000
> > > [   74.334308] FS:  7fc70d8a7b40() GS:88007fc0() 
> > > knlGS:
> > > [   74.334891] CS:  0010 DS:  ES:  CR0: 80050033
> > > [   74.335314] CR2: 7fff4144a710 CR3: 7ab56000 CR4: 
> > > 003406f0
> > > [   74.335830] DR0:  DR1:  DR2: 
> > > 
> > > [   74.336373] DR3:  DR6: fffe0ff0 DR7: 
> > > 0400
> > > [   74.336895] Call Trace:
> > > [   74.337086]  skb_release_all+0xd/0x30
> > > [   74.337356]  consume_skb+0x2c/0x90
> > > [   74.337607]  free_unused_bufs+0x1ff/0x270 [virtio_net]
> > > [   74.337988]  ? vp_synchronize_vectors+0x3b/0x60 [virtio_pci]
> > > [   74.338398]  virtnet_xdp+0x21e/0x440 [virtio_net]
> > > [   74.338741]  dev_change_xdp_fd+0x101/0x140
> > > [   74.339048]  do_setlink+0xcf4/0xd20
> > > [   74.339304]  ? symcmp+0xf/0x20
> > > [   74.339529]  ? mls_level_isvalid+0x52/0x60
> > > [   74.339828]  ? mls_range_isvalid+0x43/0x50
> > > [   74.340135]  ? nla_parse+0xa0/0x100
> > > [   74.340400]  rtnl_setlink+0xd4/0x120
> > > [   74.340664]  ? cpumask_next_and+0x30/0x50
> > > [   74.340966]  rtnetlink_rcv_msg+0x7f/0x1f0
> > > [   74.341259]  ? sock_has_perm+0x59/0x60
> > > [   74.341586]  ? napi_consume_skb+0xe2/0x100
> > > [   74.342010]  ? rtnl_newlink+0x890/0x890
> > > [   74.342435]  netlink_rcv_skb+0x92/0xb0
> > > [   74.342846]  rtnetlink_rcv+0x23/0x30
> > > [   74.343277]  netlink_unicast+0x162/0x210
> > > [   74.343677]  netlink_sendmsg+0x2db/0x390
> > > [   74.343968]  sock_sendmsg+0x33/0x40
> > > [   74.344233]  SYSC_sendto+0xee/0x160
> > > [   74.344482]  ? SYSC_bind+0xb0/0xe0
> > > [   74.344806]  ? sock_alloc_file+0x92/0x110
> > > [   74.345106]  ? fd_install+0x20/0x30
> > > [   74.345360]  ? sock_map_fd+0x3f/0x60
> > > [   74.345586]  SyS_sendto+0x9/0x10
> > > [   74.345790]  entry_SYSCALL_64_fastpath+0x1a/0xa9
> > > [   74.346086] RIP: 0033:0x7fc70d1b8f6d
> > > [   74.346312] RSP: 002b:7fff4144a708 EFLAGS: 0246 ORIG_RAX: 
> > > 002c
> > > [   74.346785] RAX: ffda RBX:  RCX: 
> > > 7fc70d1b8f6d
> > > [   74.347244] RDX: 002c RSI: 7fff4144a720 RDI: 
> > > 0003
> > > [   74.347683] RBP: 0003 R08:  R09: 
> > > 
> > > [   74.348544] R10:  R11: 0246 R12: 
> > > 7fff4144bd90
> > > [   74.349082] R13: 0002 R14: 0002 R15: 
> > > 7fff4144cda0
> > > [   74.349607] Code: 00 00 00 55 48 89 e5 53 48 89 fb 48 8b 7f 58 48 85 
> > > ff 74 0e 40 f6 c7 01 74 3d 48 c7 43 58 00 00 00 00 48 8b 7b 68 48 85 ff 
> > > 74 05  ff 0f 74 20 48 8b 43 60 48 85 c0 74 14 65 8b 15 f3 ab 8d 7e
> > > [   74.351008] RIP: skb_release_head_state+0x28/0x80 RSP: c9000438b8d0
> > > [   74.351625] ---[ end trace fe6e19fd11cfc80b ]---
> > > 
> > > Fixes: 2de2f7f40ef9 ("virtio_net: XDP support for adjust_head")
> > > Cc: John Fastabend 
> > > Signed-off-by: Jason Wang 
> > > ---
> > >

[PATCH repost] ptr_ring: fix race conditions when resizing

Resizing currently drops consumer lock.  This can cause entries to be
reordered, which isn't good in itself.  More importantly, consumer can
detect a false ring empty condition and block forever.

Further, nesting of consumer within producer lock is problematic for
tun, since it produces entries in a BH, which causes a lock order
reversal:

   CPU0CPU1
   
  consume:
  lock(&(>consumer_lock)->rlock);
   resize:
   local_irq_disable();
   lock(&(>producer_lock)->rlock);
   lock(&(>consumer_lock)->rlock);
  
  produce:
  lock(&(>producer_lock)->rlock);

To fix, nest producer lock within consumer lock during resize,
and keep consumer lock during the whole swap operation.

Reported-by: Dmitry Vyukov 
Cc: sta...@vger.kernel.org
Cc: "David S. Miller" 
Acked-by: Jason Wang 
Signed-off-by: Michael S. Tsirkin 
---

Dave, could you merge this before 4.10? If not - I can try.

 include/linux/ptr_ring.h | 36 +++-
 1 file changed, 31 insertions(+), 5 deletions(-)

diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
index 2052011..6c70444 100644
--- a/include/linux/ptr_ring.h
+++ b/include/linux/ptr_ring.h
@@ -111,6 +111,11 @@ static inline int __ptr_ring_produce(struct ptr_ring *r, 
void *ptr)
return 0;
 }
 
+/*
+ * Note: resize (below) nests producer lock within consumer lock, so if you
+ * consume in interrupt or BH context, you must disable interrupts/BH when
+ * calling this.
+ */
 static inline int ptr_ring_produce(struct ptr_ring *r, void *ptr)
 {
int ret;
@@ -242,6 +247,11 @@ static inline void *__ptr_ring_consume(struct ptr_ring *r)
return ptr;
 }
 
+/*
+ * Note: resize (below) nests producer lock within consumer lock, so if you
+ * call this in interrupt or BH context, you must disable interrupts/BH when
+ * producing.
+ */
 static inline void *ptr_ring_consume(struct ptr_ring *r)
 {
void *ptr;
@@ -357,7 +367,7 @@ static inline void **__ptr_ring_swap_queue(struct ptr_ring 
*r, void **queue,
void **old;
void *ptr;
 
-   while ((ptr = ptr_ring_consume(r)))
+   while ((ptr = __ptr_ring_consume(r)))
if (producer < size)
queue[producer++] = ptr;
else if (destroy)
@@ -372,6 +382,12 @@ static inline void **__ptr_ring_swap_queue(struct ptr_ring 
*r, void **queue,
return old;
 }
 
+/*
+ * Note: producer lock is nested within consumer lock, so if you
+ * resize you must make sure all uses nest correctly.
+ * In particular if you consume ring in interrupt or BH context, you must
+ * disable interrupts/BH when doing so.
+ */
 static inline int ptr_ring_resize(struct ptr_ring *r, int size, gfp_t gfp,
  void (*destroy)(void *))
 {
@@ -382,17 +398,25 @@ static inline int ptr_ring_resize(struct ptr_ring *r, int 
size, gfp_t gfp,
if (!queue)
return -ENOMEM;
 
-   spin_lock_irqsave(&(r)->producer_lock, flags);
+   spin_lock_irqsave(&(r)->consumer_lock, flags);
+   spin_lock(&(r)->producer_lock);
 
old = __ptr_ring_swap_queue(r, queue, size, gfp, destroy);
 
-   spin_unlock_irqrestore(&(r)->producer_lock, flags);
+   spin_unlock(&(r)->producer_lock);
+   spin_unlock_irqrestore(&(r)->consumer_lock, flags);
 
kfree(old);
 
return 0;
 }
 
+/*
+ * Note: producer lock is nested within consumer lock, so if you
+ * resize you must make sure all uses nest correctly.
+ * In particular if you consume ring in interrupt or BH context, you must
+ * disable interrupts/BH when doing so.
+ */
 static inline int ptr_ring_resize_multiple(struct ptr_ring **rings, int nrings,
   int size,
   gfp_t gfp, void (*destroy)(void *))
@@ -412,10 +436,12 @@ static inline int ptr_ring_resize_multiple(struct 
ptr_ring **rings, int nrings,
}
 
for (i = 0; i < nrings; ++i) {
-   spin_lock_irqsave(&(rings[i])->producer_lock, flags);
+   spin_lock_irqsave(&(rings[i])->consumer_lock, flags);
+   spin_lock(&(rings[i])->producer_lock);
queues[i] = __ptr_ring_swap_queue(rings[i], queues[i],
  size, gfp, destroy);
-   spin_unlock_irqrestore(&(rings[i])->producer_lock, flags);
+   spin_unlock(&(rings[i])->producer_lock);
+   spin_unlock_irqrestore(&(rings[i])->consumer_lock, flags);
}
 
for (i = 0; i < nrings; ++i)
-- 
MST

Re: [PATCH net-next] virito-net: set queues after reset during xdp_set

On Fri, Feb 17, 2017 at 01:10:08PM +0800, Jason Wang wrote:
> 
> 
> On 2017年02月17日 12:53, John Fastabend wrote:
> > On 17-02-15 01:08 AM, Jason Wang wrote:
> > > We set queues before reset which will cause a crash[1]. This is
> > > because is_xdp_raw_buffer_queue() depends on the old xdp queue pairs
> > > number to do the correct detection. So fix this by:
> > > 
> > > - set queues after reset, to keep the old vi->curr_queue_pairs. (in
> > >fact setting queues before reset does not works since after feature
> > >set, all queue pairs were enabled by default during reset).
> > > - change xdp_queue_pairs only after virtnet_reset() is succeed.
> > > 
> > > [1]
> > I'm guessing this occurs when enabling XDP while receiving lots of traffic?
> 
> I hit this then disabling XDP while receiving lots of traffic.
> 
> > 
> > > [   74.328168] general protection fault:  [#1] SMP
> > > [   74.328625] Modules linked in: nfsd xfs libcrc32c virtio_net virtio_pci
> > > [   74.329117] CPU: 0 PID: 2849 Comm: xdp2 Not tainted 4.10.0-rc7+ #499
> > > [   74.329577] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), 
> > > BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
> > > [   74.330424] task: 88007a894000 task.stack: c90004388000
> > > [   74.330844] RIP: 0010:skb_release_head_state+0x28/0x80
> > > [   74.331298] RSP: 0018:c9000438b8d0 EFLAGS: 00010206
> > > [   74.331676] RAX:  RBX: 88007ad96300 RCX: 
> > > 
> > > [   74.332217] RDX: 88007fc137a8 RSI: 88007fc0db28 RDI: 
> > > 0001bf0001be
> > > [   74.332758] RBP: c9000438b8d8 R08: 0005008f R09: 
> > > 05f9
> > > [   74.333274] R10: 88007d001700 R11: 820a8a4d R12: 
> > > 88007ad96300
> > > [   74.333787] R13: 0002 R14: 880036604000 R15: 
> > > 77ff8000
> > > [   74.334308] FS:  7fc70d8a7b40() GS:88007fc0() 
> > > knlGS:
> > > [   74.334891] CS:  0010 DS:  ES:  CR0: 80050033
> > > [   74.335314] CR2: 7fff4144a710 CR3: 7ab56000 CR4: 
> > > 003406f0
> > > [   74.335830] DR0:  DR1:  DR2: 
> > > 
> > > [   74.336373] DR3:  DR6: fffe0ff0 DR7: 
> > > 0400
> > > [   74.336895] Call Trace:
> > > [   74.337086]  skb_release_all+0xd/0x30
> > > [   74.337356]  consume_skb+0x2c/0x90
> > > [   74.337607]  free_unused_bufs+0x1ff/0x270 [virtio_net]
> > > [   74.337988]  ? vp_synchronize_vectors+0x3b/0x60 [virtio_pci]
> > > [   74.338398]  virtnet_xdp+0x21e/0x440 [virtio_net]
> > > [   74.338741]  dev_change_xdp_fd+0x101/0x140
> > > [   74.339048]  do_setlink+0xcf4/0xd20
> > > [   74.339304]  ? symcmp+0xf/0x20
> > > [   74.339529]  ? mls_level_isvalid+0x52/0x60
> > > [   74.339828]  ? mls_range_isvalid+0x43/0x50
> > > [   74.340135]  ? nla_parse+0xa0/0x100
> > > [   74.340400]  rtnl_setlink+0xd4/0x120
> > > [   74.340664]  ? cpumask_next_and+0x30/0x50
> > > [   74.340966]  rtnetlink_rcv_msg+0x7f/0x1f0
> > > [   74.341259]  ? sock_has_perm+0x59/0x60
> > > [   74.341586]  ? napi_consume_skb+0xe2/0x100
> > > [   74.342010]  ? rtnl_newlink+0x890/0x890
> > > [   74.342435]  netlink_rcv_skb+0x92/0xb0
> > > [   74.342846]  rtnetlink_rcv+0x23/0x30
> > > [   74.343277]  netlink_unicast+0x162/0x210
> > > [   74.343677]  netlink_sendmsg+0x2db/0x390
> > > [   74.343968]  sock_sendmsg+0x33/0x40
> > > [   74.344233]  SYSC_sendto+0xee/0x160
> > > [   74.344482]  ? SYSC_bind+0xb0/0xe0
> > > [   74.344806]  ? sock_alloc_file+0x92/0x110
> > > [   74.345106]  ? fd_install+0x20/0x30
> > > [   74.345360]  ? sock_map_fd+0x3f/0x60
> > > [   74.345586]  SyS_sendto+0x9/0x10
> > > [   74.345790]  entry_SYSCALL_64_fastpath+0x1a/0xa9
> > > [   74.346086] RIP: 0033:0x7fc70d1b8f6d
> > > [   74.346312] RSP: 002b:7fff4144a708 EFLAGS: 0246 ORIG_RAX: 
> > > 002c
> > > [   74.346785] RAX: ffda RBX:  RCX: 
> > > 7fc70d1b8f6d
> > > [   74.347244] RDX: 002c RSI: 7fff4144a720 RDI: 
> > > 0003
> > > [   74.347683] RBP: 0003 R08:  R09: 
> > > 
> > > [   74.348544] R10:  R11: 0246 R12: 
> > > 7fff4144bd90
> > > [   74.349082] R13: 0002 R14: 0002 R15: 
> > > 7fff4144cda0
> > > [   74.349607] Code: 00 00 00 55 48 89 e5 53 48 89 fb 48 8b 7f 58 48 85 
> > > ff 74 0e 40 f6 c7 01 74 3d 48 c7 43 58 00 00 00 00 48 8b 7b 68 48 85 ff 
> > > 74 05  ff 0f 74 20 48 8b 43 60 48 85 c0 74 14 65 8b 15 f3 ab 8d 7e
> > > [   74.351008] RIP: skb_release_head_state+0x28/0x80 RSP: c9000438b8d0
> > > [   74.351625] ---[ end trace fe6e19fd11cfc80b ]---
> > > 
> > > Fixes: 2de2f7f40ef9 ("virtio_net: XDP support for adjust_head")
> > > Cc: John Fastabend 
> > > Signed-off-by: Jason Wang 
> > > ---
> > >   drivers/net/virtio_net.c | 35

Re: [PATCH 0/2] powerpc: kretprobe updates

2017-02-18 Thread Masami Hiramatsu

On Fri, 17 Feb 2017 17:42:54 -0300
Arnaldo Carvalho de Melo  wrote:

> Em Fri, Feb 17, 2017 at 07:44:33PM +0900, Masami Hiramatsu escreveu:
> > On Thu, 16 Feb 2017 13:47:37 +0530
> > "Naveen N. Rao"  wrote:
> > 
> > > I am posting the powerpc bits in the same thread so as to keep these
> > > changes together. I am not sure how this should be taken upstream as
> > > there are atleast three different trees involved: one for the core
> > > kprobes infrastructure, one for powerpc and one for perf.
> 
> > Hmm, could you make these (and other related) patches and
> > other series in one series? Or wait for the other series
> > are merged correctly.
> 
> Well, patches like these should be done in a way that the tooling parts
> can deal with kernels with or without the kernel changes, so that older
> tools work with new kernels and new tools work with older kernels.
> 
> "work" as in the previous behaviour is kept when a new tool deals with
> an older kernel and an older tool would warn the user that what it needs
> is not present in that kernel.
> 
> Is this the case? I just looked briefly at the patch commit logs.

Thanks Arnaldo,

Naveen, I think this one and your previous series are incompatible
with older kernel. So those should be merged in one series and
at least (1) update ftrace's README special file to show explicitly
which can accept text+offset style for kretprobes, and (2) update
perf probe side to ensure that (and fallback to previous logic if not).

Thank you,

> 
> If it is, then I can pick the tool ones, and the others can be submitted
> to the relevant trees, at some point all will be in, kernels eventually
> gets updated everywhere, ditto for the tooling, all gets well.
> 
> Regards,
> 
> - Arnaldo
> 
> 
>  
> > Thank you,
> > 
> > > 
> > > Thanks,
> > > Naveen
> > > 
> > > Naveen N. Rao (2):
> > >   powerpc: kretprobes: override default function entry offset
> > >   perf: powerpc: choose LEP with kretprobes
> > > 
> > >  arch/powerpc/kernel/kprobes.c   | 9 +
> > >  tools/perf/arch/powerpc/util/sym-handling.c | 5 +
> > >  2 files changed, 10 insertions(+), 4 deletions(-)
> > > 
> > > -- 
> > > 2.11.0
> > > 
> > 
> > 
> > -- 
> > Masami Hiramatsu 


-- 
Masami Hiramatsu

Re: [PATCH 0/2] powerpc: kretprobe updates

2017-02-18 Thread Masami Hiramatsu

On Fri, 17 Feb 2017 17:42:54 -0300
Arnaldo Carvalho de Melo  wrote:

> Em Fri, Feb 17, 2017 at 07:44:33PM +0900, Masami Hiramatsu escreveu:
> > On Thu, 16 Feb 2017 13:47:37 +0530
> > "Naveen N. Rao"  wrote:
> > 
> > > I am posting the powerpc bits in the same thread so as to keep these
> > > changes together. I am not sure how this should be taken upstream as
> > > there are atleast three different trees involved: one for the core
> > > kprobes infrastructure, one for powerpc and one for perf.
> 
> > Hmm, could you make these (and other related) patches and
> > other series in one series? Or wait for the other series
> > are merged correctly.
> 
> Well, patches like these should be done in a way that the tooling parts
> can deal with kernels with or without the kernel changes, so that older
> tools work with new kernels and new tools work with older kernels.
> 
> "work" as in the previous behaviour is kept when a new tool deals with
> an older kernel and an older tool would warn the user that what it needs
> is not present in that kernel.
> 
> Is this the case? I just looked briefly at the patch commit logs.

Thanks Arnaldo,

Naveen, I think this one and your previous series are incompatible
with older kernel. So those should be merged in one series and
at least (1) update ftrace's README special file to show explicitly
which can accept text+offset style for kretprobes, and (2) update
perf probe side to ensure that (and fallback to previous logic if not).

Thank you,

> 
> If it is, then I can pick the tool ones, and the others can be submitted
> to the relevant trees, at some point all will be in, kernels eventually
> gets updated everywhere, ditto for the tooling, all gets well.
> 
> Regards,
> 
> - Arnaldo
> 
> 
>  
> > Thank you,
> > 
> > > 
> > > Thanks,
> > > Naveen
> > > 
> > > Naveen N. Rao (2):
> > >   powerpc: kretprobes: override default function entry offset
> > >   perf: powerpc: choose LEP with kretprobes
> > > 
> > >  arch/powerpc/kernel/kprobes.c   | 9 +
> > >  tools/perf/arch/powerpc/util/sym-handling.c | 5 +
> > >  2 files changed, 10 insertions(+), 4 deletions(-)
> > > 
> > > -- 
> > > 2.11.0
> > > 
> > 
> > 
> > -- 
> > Masami Hiramatsu 


-- 
Masami Hiramatsu

Re: [PATCH][RFC v4] ACPI throttling: Disable the MSR T-state if enabled after resumed

2017-02-18 Thread Chen Yu

Hi,
On Sat, Feb 18, 2017 at 10:02:07AM +0100, Pavel Machek wrote:
> On Fri 2017-02-17 16:27:30, Chen Yu wrote:
> > Previously a bug was reported that on certain Broadwell
> > platform, after resumed from S3, the CPU is running at
> > an anomalously low speed, due to the BIOS has enabled the
> > MSR throttling across S3. The solution to this was to introduce
> > a quirk framework to save/restore tstate MSR register around
> > suspend/resume, in Commit 7a9c2dd08ead ("x86/pm:
> > Introduce quirk framework to save/restore extra MSR
> > registers around suspend/resume").
> > 
> > However there are still three problems left:
> > 1. More and more reports show that other platforms also
> >encountered the same issue, so the quirk list might
> >be endless.
> > 2. Each CPUs should take the save/restore operation into
> >consideration, rather than the boot CPU alone.
> > 3. Normally ACPI T-state re-evaluation is done on resume,
> >however there is no _TSS on the bogus platform, thus
> >above re-evaluation code does not run on that machine.
> > 
> > Solution:
> > This patch is based on the fact that, we generally should not
> > expect the system to come back from resume with throttling
> > enabled, but leverage the OS components to deal with it,
> > such as thermal event. So we simply clear the MSR T-state
> > and print the warning if it is found to be enabled after
> > resumed back. Besides, we can remove the quirk in previous patch
> > later.
> 
> What if the machine _is_ hot? 
> 
Later the linux has a chance to adjust the tstate if the system is too hot,
with the help of thermal framework.
But if the cpu is not inside any thermal zone, then there is no way for the
OS to adjust the tstate after resume, however in this case I think it is up
to the user space to adjust the tstate msr, for example, by using thermald
daemon to bind the cpu to the thermal zone.

> > +static int acpi_throttling_init_ops(void)
> > +{
> > +   /*
> > +* Reevaluate on boot CPU. Since it is not always CPU0,
> > +* we can not invoke throttling_msr_reevaluate(0) directly.
> > +*/
> 
> Boot cpu is not cpu#0? How can that be?
> 
In disable_nonboot_cpus, it first tries to disable cpus other than cpu#0,
but if cpu#0 is found to be offline, it will try to bypass it and use another
cpu as the boot/primary cpu:

if (!cpu_online(primary))
primary = cpumask_first(cpu_online_mask);

> Should we introduce generic framework to "fix" all the cpus? Actually,
> should this be done right on cpu hotplug?
Do you mean, fix other MSR-inconsistent issues, not only the tstate MSR?
Currently the tstate re-adjusting is invoked in cpuhotplug notifier
after each nonboot cpus are brought up:
acpi_soft_cpu_online -> acpi_processor_reevaluate_tstate -> adjust_tstate_msr

Thanks,
Yu
> 
>   Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH][RFC v4] ACPI throttling: Disable the MSR T-state if enabled after resumed

2017-02-18 Thread Chen Yu

Hi,
On Sat, Feb 18, 2017 at 10:02:07AM +0100, Pavel Machek wrote:
> On Fri 2017-02-17 16:27:30, Chen Yu wrote:
> > Previously a bug was reported that on certain Broadwell
> > platform, after resumed from S3, the CPU is running at
> > an anomalously low speed, due to the BIOS has enabled the
> > MSR throttling across S3. The solution to this was to introduce
> > a quirk framework to save/restore tstate MSR register around
> > suspend/resume, in Commit 7a9c2dd08ead ("x86/pm:
> > Introduce quirk framework to save/restore extra MSR
> > registers around suspend/resume").
> > 
> > However there are still three problems left:
> > 1. More and more reports show that other platforms also
> >encountered the same issue, so the quirk list might
> >be endless.
> > 2. Each CPUs should take the save/restore operation into
> >consideration, rather than the boot CPU alone.
> > 3. Normally ACPI T-state re-evaluation is done on resume,
> >however there is no _TSS on the bogus platform, thus
> >above re-evaluation code does not run on that machine.
> > 
> > Solution:
> > This patch is based on the fact that, we generally should not
> > expect the system to come back from resume with throttling
> > enabled, but leverage the OS components to deal with it,
> > such as thermal event. So we simply clear the MSR T-state
> > and print the warning if it is found to be enabled after
> > resumed back. Besides, we can remove the quirk in previous patch
> > later.
> 
> What if the machine _is_ hot? 
> 
Later the linux has a chance to adjust the tstate if the system is too hot,
with the help of thermal framework.
But if the cpu is not inside any thermal zone, then there is no way for the
OS to adjust the tstate after resume, however in this case I think it is up
to the user space to adjust the tstate msr, for example, by using thermald
daemon to bind the cpu to the thermal zone.

> > +static int acpi_throttling_init_ops(void)
> > +{
> > +   /*
> > +* Reevaluate on boot CPU. Since it is not always CPU0,
> > +* we can not invoke throttling_msr_reevaluate(0) directly.
> > +*/
> 
> Boot cpu is not cpu#0? How can that be?
> 
In disable_nonboot_cpus, it first tries to disable cpus other than cpu#0,
but if cpu#0 is found to be offline, it will try to bypass it and use another
cpu as the boot/primary cpu:

if (!cpu_online(primary))
primary = cpumask_first(cpu_online_mask);

> Should we introduce generic framework to "fix" all the cpus? Actually,
> should this be done right on cpu hotplug?
Do you mean, fix other MSR-inconsistent issues, not only the tstate MSR?
Currently the tstate re-adjusting is invoked in cpuhotplug notifier
after each nonboot cpus are brought up:
acpi_soft_cpu_online -> acpi_processor_reevaluate_tstate -> adjust_tstate_msr

Thanks,
Yu
> 
>   Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[GIT] Networking


One last brown-paper-bag fix for the release.  If we fail the ipv4
mapped source address check, we have to release the route.  From
Willem de Bruijn.

Please pull, thanks a lot!

The following changes since commit 2763f92f858f7c4c3198335c0542726eaed07ba3:

  Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2017-02-18 17:38:09 
-0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git 

for you to fetch changes up to 00ea1ceebe0d9f2dc1cc2b7bd575a00100c27869:

  ipv6: release dst on error in ip6_dst_lookup_tail (2017-02-18 22:55:13 -0500)


Willem de Bruijn (1):
  ipv6: release dst on error in ip6_dst_lookup_tail

 net/ipv6/ip6_output.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

[GIT] Networking


One last brown-paper-bag fix for the release.  If we fail the ipv4
mapped source address check, we have to release the route.  From
Willem de Bruijn.

Please pull, thanks a lot!

The following changes since commit 2763f92f858f7c4c3198335c0542726eaed07ba3:

  Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2017-02-18 17:38:09 
-0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git 

for you to fetch changes up to 00ea1ceebe0d9f2dc1cc2b7bd575a00100c27869:

  ipv6: release dst on error in ip6_dst_lookup_tail (2017-02-18 22:55:13 -0500)


Willem de Bruijn (1):
  ipv6: release dst on error in ip6_dst_lookup_tail

 net/ipv6/ip6_output.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

2017-02-18 Thread James Bottomley

On Fri, 2017-02-17 at 15:35 -0500, Vivek Goyal wrote:
> On Fri, Feb 17, 2017 at 09:34:07AM -0800, James Bottomley wrote:
> > On Fri, 2017-02-17 at 02:55 +, Al Viro wrote:
> > > On Thu, Feb 16, 2017 at 07:56:30AM -0800, James Bottomley wrote:
> > > 
> > > > > Hi James,
> > > > > 
> > > > > Should it be "return d_splice_alias()" so that if we find an 
> > > > > alias it is returned back to caller and passed in dentry can 
> > > > > be freed. Though I don't know in what cases alias can be 
> > > > > found. And if alias is found how do we make sure alias_dentry
> > > > > ->d_fsdata is pointing to new (real dentry).
> > > > 
> > > > It probably should be for the sake of the pattern.  In our case 
> > > > I don't think we can have any root aliases because the root
> > > > dentry is always pinned in the cache, so cache lookup should 
> > > > always find it.
> > > 
> > > What does that have to do with root dentry?  The real reason why 
> > > that code works (FVerySVO) is that the damn thing allocates a new
> > > inode every time. Including the hardlinks, BTW.
> > 
> > Yes, this is a known characteristic of stacked filesystems.  Is 
> > there some magic I don't know about that would make it easier to 
> > reflect hard links as aliases?
> 
> I think overlayfs had the same issue in the beginning and miklos
> fixed it.
> 
> commit 51f7e52dc943468c6929fa0a82d4afac3c8e9636
> Author: Miklos Szeredi 
> Date:   Fri Jul 29 12:05:24 2016 +0200
> 
> ovl: share inode for hard link

That's rather complex, but the principle is simple: use the inode hash
for all upper inodes that may have aliases.  Aliasable means the
underlying inode isn't a directory and has i_nlink > 1, so all I have
to do is perform a lookup through the hash if the underlying is
aliasable, invalidate the dentry in d_revalidate if the aliasing
conditions to the underlying change and manually handle hard links and
it should all work.

Like this?

James

---

diff --git a/fs/shiftfs.c b/fs/shiftfs.c
index 5b50447..c659812 100644
--- a/fs/shiftfs.c
+++ b/fs/shiftfs.c
@@ -134,6 +134,7 @@ static int shiftfs_d_weak_revalidate(struct dentry *dentry, 
unsigned int flags)
 static int shiftfs_d_revalidate(struct dentry *dentry, unsigned int flags)
 {
struct dentry *real = dentry->d_fsdata;
+   struct inode *reali = d_inode(real), *inode = d_inode(dentry);
int ret;
 
if (d_unhashed(real))
@@ -146,6 +147,15 @@ static int shiftfs_d_revalidate(struct dentry *dentry, 
unsigned int flags)
if (d_is_negative(real) != d_is_negative(dentry))
return 0;
 
+   /*
+* non dir link count is > 1 and our inode is currently not in
+* the inode hash => need to drop and reget our dentry to make
+* sure we're aliasing it correctly.
+*/
+   if (reali &&!S_ISDIR(reali->i_mode) && reali->i_nlink > 1 &&
+   (!inode || inode_unhashed(inode)))
+   return 0;
+
if (!(real->d_flags & DCACHE_OP_REVALIDATE))
return 1;
 
@@ -285,7 +295,8 @@ static int shiftfs_make_object(struct inode *dir, struct 
dentry *dentry,
   umode_t mode, const char *symlink,
   struct dentry *hardlink, bool excl)
 {
-   struct dentry *real = dir->i_private, *new = dentry->d_fsdata;
+   struct dentry *real = dir->i_private, *new = dentry->d_fsdata,
+   *realhardlink = NULL;
struct inode *reali = real->d_inode, *newi;
const struct inode_operations *iop = reali->i_op;
int err;
@@ -293,6 +304,7 @@ static int shiftfs_make_object(struct inode *dir, struct 
dentry *dentry,
bool op_ok = false;
 
if (hardlink) {
+   realhardlink = hardlink->d_fsdata;
op_ok = iop->link;
} else {
switch (mode & S_IFMT) {
@@ -310,7 +322,7 @@ static int shiftfs_make_object(struct inode *dir, struct 
dentry *dentry,
return -EINVAL;
 
 
-   newi = shiftfs_new_inode(dentry->d_sb, mode, NULL);
+   newi = shiftfs_new_inode(dentry->d_sb, mode, realhardlink);
if (!newi)
return -ENOMEM;
 
@@ -320,8 +332,6 @@ static int shiftfs_make_object(struct inode *dir, struct 
dentry *dentry,
 
err = -EINVAL;  /* shut gcc up about uninit var */
if (hardlink) {
-   struct dentry *realhardlink = hardlink->d_fsdata;
-
err = vfs_link(realhardlink, reali, new, NULL);
} else {
switch (mode & S_IFMT) {
@@ -341,7 +351,16 @@ static int shiftfs_make_object(struct inode *dir, struct 
dentry *dentry,
if (err)
goto out_dput;
 
-   shiftfs_fill_inode(newi, new);
+   if (!hardlink)
+   shiftfs_fill_inode(newi, new);
+   else if (inode_unhashed(newi) && !S_ISDIR(newi->i_mode))
+   /*
+* although dentry and hardlink now each point to
+* newi, the link

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

2017-02-18 Thread James Bottomley

On Fri, 2017-02-17 at 15:35 -0500, Vivek Goyal wrote:
> On Fri, Feb 17, 2017 at 09:34:07AM -0800, James Bottomley wrote:
> > On Fri, 2017-02-17 at 02:55 +, Al Viro wrote:
> > > On Thu, Feb 16, 2017 at 07:56:30AM -0800, James Bottomley wrote:
> > > 
> > > > > Hi James,
> > > > > 
> > > > > Should it be "return d_splice_alias()" so that if we find an 
> > > > > alias it is returned back to caller and passed in dentry can 
> > > > > be freed. Though I don't know in what cases alias can be 
> > > > > found. And if alias is found how do we make sure alias_dentry
> > > > > ->d_fsdata is pointing to new (real dentry).
> > > > 
> > > > It probably should be for the sake of the pattern.  In our case 
> > > > I don't think we can have any root aliases because the root
> > > > dentry is always pinned in the cache, so cache lookup should 
> > > > always find it.
> > > 
> > > What does that have to do with root dentry?  The real reason why 
> > > that code works (FVerySVO) is that the damn thing allocates a new
> > > inode every time. Including the hardlinks, BTW.
> > 
> > Yes, this is a known characteristic of stacked filesystems.  Is 
> > there some magic I don't know about that would make it easier to 
> > reflect hard links as aliases?
> 
> I think overlayfs had the same issue in the beginning and miklos
> fixed it.
> 
> commit 51f7e52dc943468c6929fa0a82d4afac3c8e9636
> Author: Miklos Szeredi 
> Date:   Fri Jul 29 12:05:24 2016 +0200
> 
> ovl: share inode for hard link

That's rather complex, but the principle is simple: use the inode hash
for all upper inodes that may have aliases.  Aliasable means the
underlying inode isn't a directory and has i_nlink > 1, so all I have
to do is perform a lookup through the hash if the underlying is
aliasable, invalidate the dentry in d_revalidate if the aliasing
conditions to the underlying change and manually handle hard links and
it should all work.

Like this?

James

---

diff --git a/fs/shiftfs.c b/fs/shiftfs.c
index 5b50447..c659812 100644
--- a/fs/shiftfs.c
+++ b/fs/shiftfs.c
@@ -134,6 +134,7 @@ static int shiftfs_d_weak_revalidate(struct dentry *dentry, 
unsigned int flags)
 static int shiftfs_d_revalidate(struct dentry *dentry, unsigned int flags)
 {
struct dentry *real = dentry->d_fsdata;
+   struct inode *reali = d_inode(real), *inode = d_inode(dentry);
int ret;
 
if (d_unhashed(real))
@@ -146,6 +147,15 @@ static int shiftfs_d_revalidate(struct dentry *dentry, 
unsigned int flags)
if (d_is_negative(real) != d_is_negative(dentry))
return 0;
 
+   /*
+* non dir link count is > 1 and our inode is currently not in
+* the inode hash => need to drop and reget our dentry to make
+* sure we're aliasing it correctly.
+*/
+   if (reali &&!S_ISDIR(reali->i_mode) && reali->i_nlink > 1 &&
+   (!inode || inode_unhashed(inode)))
+   return 0;
+
if (!(real->d_flags & DCACHE_OP_REVALIDATE))
return 1;
 
@@ -285,7 +295,8 @@ static int shiftfs_make_object(struct inode *dir, struct 
dentry *dentry,
   umode_t mode, const char *symlink,
   struct dentry *hardlink, bool excl)
 {
-   struct dentry *real = dir->i_private, *new = dentry->d_fsdata;
+   struct dentry *real = dir->i_private, *new = dentry->d_fsdata,
+   *realhardlink = NULL;
struct inode *reali = real->d_inode, *newi;
const struct inode_operations *iop = reali->i_op;
int err;
@@ -293,6 +304,7 @@ static int shiftfs_make_object(struct inode *dir, struct 
dentry *dentry,
bool op_ok = false;
 
if (hardlink) {
+   realhardlink = hardlink->d_fsdata;
op_ok = iop->link;
} else {
switch (mode & S_IFMT) {
@@ -310,7 +322,7 @@ static int shiftfs_make_object(struct inode *dir, struct 
dentry *dentry,
return -EINVAL;
 
 
-   newi = shiftfs_new_inode(dentry->d_sb, mode, NULL);
+   newi = shiftfs_new_inode(dentry->d_sb, mode, realhardlink);
if (!newi)
return -ENOMEM;
 
@@ -320,8 +332,6 @@ static int shiftfs_make_object(struct inode *dir, struct 
dentry *dentry,
 
err = -EINVAL;  /* shut gcc up about uninit var */
if (hardlink) {
-   struct dentry *realhardlink = hardlink->d_fsdata;
-
err = vfs_link(realhardlink, reali, new, NULL);
} else {
switch (mode & S_IFMT) {
@@ -341,7 +351,16 @@ static int shiftfs_make_object(struct inode *dir, struct 
dentry *dentry,
if (err)
goto out_dput;
 
-   shiftfs_fill_inode(newi, new);
+   if (!hardlink)
+   shiftfs_fill_inode(newi, new);
+   else if (inode_unhashed(newi) && !S_ISDIR(newi->i_mode))
+   /*
+* although dentry and hardlink now each point to
+* newi, the link count was 1 when they

[PATCH 1/4] ARM64: Prepare Marvell IAP140 aka PXA1908

Suppress COMMON_CLK_PXA and MMC_PXA for now as they don't build on arm64.
Also suppress the deprecated SERIAL_PXA in favor of SERIAL_8250_PXA.

Signed-off-by: Andreas Färber 
---
 arch/arm64/Kconfig.platforms | 5 +
 drivers/clk/Kconfig  | 2 +-
 drivers/mmc/host/Kconfig | 2 +-
 drivers/tty/serial/Kconfig   | 2 +-
 4 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 129cc5a..841b6c8 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -111,6 +111,11 @@ config ARCH_MVEBU
   - Armada 7K SoC Family
   - Armada 8K SoC Family
 
+config ARCH_PXA
+   bool "Marvell PXA SoC Family"
+   help
+ This enables support for the Marvell PXA family.
+
 config ARCH_QCOM
bool "Qualcomm Platforms"
select GPIOLIB
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 9356ab4..3d25f20 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -185,7 +185,7 @@ config COMMON_CLK_PWM
  at 50% duty cycle.
 
 config COMMON_CLK_PXA
-   def_bool COMMON_CLK && ARCH_PXA
+   def_bool COMMON_CLK && ARCH_PXA && ARM
---help---
  Support for the Marvell PXA SoC.
 
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index f08691a..a650eca 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -27,7 +27,7 @@ config MMC_QCOM_DML
 
 config MMC_PXA
tristate "Intel PXA25x/26x/27x Multimedia Card Interface support"
-   depends on ARCH_PXA
+   depends on ARCH_PXA && ARM
help
  This selects the Intel(R) PXA(R) Multimedia card Interface.
  If you have a PXA(R) platform with a Multimedia Card slot,
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 6117ac8..0713a05 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -439,7 +439,7 @@ config SERIAL_MPSC_CONSOLE
 
 config SERIAL_PXA
bool "PXA serial port support (DEPRECATED)"
-   depends on ARCH_PXA || ARCH_MMP
+   depends on (ARCH_PXA && ARM) || ARCH_MMP
select SERIAL_CORE
select SERIAL_8250_PXA if SERIAL_8250=y
select SERIAL_PXA_NON8250 if !SERIAL_8250=y
-- 
2.10.2

[PATCH 4/4] ARM64: dts: marvell: iap140-andromeda-box-edge: Add uart0 clock

Use a fixed clock to enable ttyS0 output.

Signed-off-by: Andreas Färber 
---
 arch/arm64/boot/dts/marvell/iap140-andromeda-box-edge.dts | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/iap140-andromeda-box-edge.dts 
b/arch/arm64/boot/dts/marvell/iap140-andromeda-box-edge.dts
index de01d93..dceab69 100644
--- a/arch/arm64/boot/dts/marvell/iap140-andromeda-box-edge.dts
+++ b/arch/arm64/boot/dts/marvell/iap140-andromeda-box-edge.dts
@@ -63,8 +63,15 @@
device_type = "memory";
reg = <0x0 0x0 0x0 0x4000>;
};
+
+   uart0_clk: uart0-clk {
+   compatible = "fixed-clock";
+   clock-frequency = <1474>;
+   #clock-cells = <0>;
+   };
 };
 
  {
status = "okay";
+   clocks = <_clk>;
 };
-- 
2.10.2

[PATCH 2/4] Documentation: devicetree: arm: Document Marvell IAP140

Signed-off-by: Andreas Färber 
---
 Documentation/devicetree/bindings/arm/marvell/iap140.txt | 7 +++
 1 file changed, 7 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/iap140.txt

diff --git a/Documentation/devicetree/bindings/arm/marvell/iap140.txt 
b/Documentation/devicetree/bindings/arm/marvell/iap140.txt
new file mode 100644
index 000..25d307c
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/iap140.txt
@@ -0,0 +1,7 @@
+Marvell IAP140 Device Tree Bindings
+---
+
+Boards using a SoC of the Marvell IAP140 family must carry the following
+root node property:
+
+ - compatible :  must contain "mrvl,iap140"
-- 
2.10.2

[PATCH 4/4] ARM64: dts: marvell: iap140-andromeda-box-edge: Add uart0 clock

Use a fixed clock to enable ttyS0 output.

Signed-off-by: Andreas Färber 
---
 arch/arm64/boot/dts/marvell/iap140-andromeda-box-edge.dts | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/iap140-andromeda-box-edge.dts 
b/arch/arm64/boot/dts/marvell/iap140-andromeda-box-edge.dts
index de01d93..dceab69 100644
--- a/arch/arm64/boot/dts/marvell/iap140-andromeda-box-edge.dts
+++ b/arch/arm64/boot/dts/marvell/iap140-andromeda-box-edge.dts
@@ -63,8 +63,15 @@
device_type = "memory";
reg = <0x0 0x0 0x0 0x4000>;
};
+
+   uart0_clk: uart0-clk {
+   compatible = "fixed-clock";
+   clock-frequency = <1474>;
+   #clock-cells = <0>;
+   };
 };
 
  {
status = "okay";
+   clocks = <_clk>;
 };
-- 
2.10.2

[PATCH 2/4] Documentation: devicetree: arm: Document Marvell IAP140

Signed-off-by: Andreas Färber 
---
 Documentation/devicetree/bindings/arm/marvell/iap140.txt | 7 +++
 1 file changed, 7 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/iap140.txt

diff --git a/Documentation/devicetree/bindings/arm/marvell/iap140.txt 
b/Documentation/devicetree/bindings/arm/marvell/iap140.txt
new file mode 100644
index 000..25d307c
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/iap140.txt
@@ -0,0 +1,7 @@
+Marvell IAP140 Device Tree Bindings
+---
+
+Boards using a SoC of the Marvell IAP140 family must carry the following
+root node property:
+
+ - compatible :  must contain "mrvl,iap140"
-- 
2.10.2

[PATCH 1/4] ARM64: Prepare Marvell IAP140 aka PXA1908

Suppress COMMON_CLK_PXA and MMC_PXA for now as they don't build on arm64.
Also suppress the deprecated SERIAL_PXA in favor of SERIAL_8250_PXA.

Signed-off-by: Andreas Färber 
---
 arch/arm64/Kconfig.platforms | 5 +
 drivers/clk/Kconfig  | 2 +-
 drivers/mmc/host/Kconfig | 2 +-
 drivers/tty/serial/Kconfig   | 2 +-
 4 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 129cc5a..841b6c8 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -111,6 +111,11 @@ config ARCH_MVEBU
   - Armada 7K SoC Family
   - Armada 8K SoC Family
 
+config ARCH_PXA
+   bool "Marvell PXA SoC Family"
+   help
+ This enables support for the Marvell PXA family.
+
 config ARCH_QCOM
bool "Qualcomm Platforms"
select GPIOLIB
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 9356ab4..3d25f20 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -185,7 +185,7 @@ config COMMON_CLK_PWM
  at 50% duty cycle.
 
 config COMMON_CLK_PXA
-   def_bool COMMON_CLK && ARCH_PXA
+   def_bool COMMON_CLK && ARCH_PXA && ARM
---help---
  Support for the Marvell PXA SoC.
 
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index f08691a..a650eca 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -27,7 +27,7 @@ config MMC_QCOM_DML
 
 config MMC_PXA
tristate "Intel PXA25x/26x/27x Multimedia Card Interface support"
-   depends on ARCH_PXA
+   depends on ARCH_PXA && ARM
help
  This selects the Intel(R) PXA(R) Multimedia card Interface.
  If you have a PXA(R) platform with a Multimedia Card slot,
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 6117ac8..0713a05 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -439,7 +439,7 @@ config SERIAL_MPSC_CONSOLE
 
 config SERIAL_PXA
bool "PXA serial port support (DEPRECATED)"
-   depends on ARCH_PXA || ARCH_MMP
+   depends on (ARCH_PXA && ARM) || ARCH_MMP
select SERIAL_CORE
select SERIAL_8250_PXA if SERIAL_8250=y
select SERIAL_PXA_NON8250 if !SERIAL_8250=y
-- 
2.10.2

[PATCH 3/4] ARM64: dts: marvell: Add IAP140 and Andromeda Box Edge

PPI interrupts 11, 10, 9 are guesses, and so are the second two memory
regions of the GIC.

Signed-off-by: Andreas Färber 
---
 arch/arm64/boot/dts/marvell/Makefile   |   2 +
 .../boot/dts/marvell/iap140-andromeda-box-edge.dts |  70 
 arch/arm64/boot/dts/marvell/iap140.dtsi| 195 +
 3 files changed, 267 insertions(+)
 create mode 100644 arch/arm64/boot/dts/marvell/iap140-andromeda-box-edge.dts
 create mode 100644 arch/arm64/boot/dts/marvell/iap140.dtsi

diff --git a/arch/arm64/boot/dts/marvell/Makefile 
b/arch/arm64/boot/dts/marvell/Makefile
index 3e6ce6c..d2046be 100644
--- a/arch/arm64/boot/dts/marvell/Makefile
+++ b/arch/arm64/boot/dts/marvell/Makefile
@@ -9,6 +9,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += armada-7040-db.dtb
 dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-db.dtb
 dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-mcbin.dtb
 
+dtb-$(CONFIG_ARCH_PXA) += iap140-andromeda-box-edge.dtb
+
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
 clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/marvell/iap140-andromeda-box-edge.dts 
b/arch/arm64/boot/dts/marvell/iap140-andromeda-box-edge.dts
new file mode 100644
index 000..de01d93
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/iap140-andromeda-box-edge.dts
@@ -0,0 +1,70 @@
+/*
+ * Copyright (c) 2016-2017 Andreas Färber
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+/memreserve/ 0x0900 0x0100;
+/memreserve/ 0x0a00 0x0008;
+
+#include "iap140.dtsi"
+
+/ {
+   compatible = "mrvl,andromeda-box-edge", "mrvl,iap140";
+   model = "Andromeda Box Edge";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x0 0x0 0x4000>;
+   };
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/marvell/iap140.dtsi 
b/arch/arm64/boot/dts/marvell/iap140.dtsi
new file mode 100644
index 000..38acb14
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/iap140.dtsi
@@ -0,0 +1,195 @@
+/*
+ * Copyright (c) 2016-2017 Andreas Färber
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *

[PATCH 0/4] ARM64: Initial Marvell IAP140 enablement

Hello,

This mini-series adds initial support for the Marvell IAP140 SoC (aka PXA1908)
and the Andromeda Box Edge development board.

In order to enable the 8250 UART driver, it reuses ARCH_PXA; but some drivers
enabled with ARCH_PXA don't build due to arm assembly or arm64's lack of mach-,
so their dependencies need to be limited to ARM alongside (blacklisted). The
alternative would of course be to choose a new ARCH_ symbol and to selectively
add it to drivers known working (whitelisting). The latter would require
finding a suitable name.

Both earlycon and serial are working, but an explicit console=ttyS0,115200n8
is needed; with just "earlycon" and stdout-path the earlycon stops early and
switches to a tty0, long before disabling the bootconsole...

All four CPUs come up, and an initrd can be reached.

However, there are errors about CPUs 1-3 having a zero SYS_CNTFRQ_EL0:

[0.095812] smp: Bringing up secondary CPUs ...
==pxa1908_pmu_core_pwr_on: mpidr = 0x1
==pxa1908_pmu_core_pwr_on: mpidr = 0x2
==pxa1908_pmu_core_pwr_on: mpidr = 0x3
[0.133419] Detected VIPT I-cache on CPU1
[0.133430] CPU features: SANITY CHECK: Unexpected variation in 
SYS_CNTFRQ_EL0. Boot CPU: 0x00018cba80, CPU1: 0x00
[0.133447] Unsupported CPU feature variation.
...
[0.133748] CPU1: Booted secondary processor [410fd032]
[0.165465] Detected VIPT I-cache on CPU2
[0.165474] CPU features: SANITY CHECK: Unexpected variation in 
SYS_CNTFRQ_EL0. Boot CPU: 0x00018cba80, CPU2: 0x00
[0.165505] CPU2: Booted secondary processor [410fd032]
[0.197539] Detected VIPT I-cache on CPU3
[0.197546] CPU features: SANITY CHECK: Unexpected variation in 
SYS_CNTFRQ_EL0. Boot CPU: 0x00018cba80, CPU3: 0x00
[0.197573] CPU3: Booted secondary processor [410fd032]
[0.197625] smp: Brought up 1 node, 4 CPUs
[0.522514] SMP: Total of 4 processors activated.
[0.527212] CPU features: detected feature: 32-bit EL0 Support
[0.533105] CPU: All CPU(s) started at EL2

KVM appears to initialize okay, but was not yet tested with guests.

[0.865255] kvm [1]: 8-bit VMID
[0.868401] kvm [1]: IDMAP page: d23000
[0.872233] kvm [1]: HYP VA range: 8000:
[0.878262] kvm [1]: Hyp mode initialized successfully
[0.883429] kvm [1]: vgic-v2@d1dfc000
[0.887179] kvm [1]: vgic interrupt IRQ1
[0.891120] kvm [1]: virtual timer IRQ4

More Marvell drivers may be available in-tree for reuse - besides build errors
the limitation is currently the lack of an IAP140 clk driver though. Patch 4/4
works around that for UART0 with a fixed-clock.

A 3.14 based tree is available on GitHub acorn-marvell/brillo_pxa_kernel. No
driver comparisons to mainline have been attempted yet.

Booting required changes to the vendor U-Boot,
cf. https://en.opensuse.org/HCL:AndromedaBoxEdge

https://github.com/afaerber/linux/commits/edge-next

Have a lot of fun!

Cheers,
Andreas

Cc: i...@andromedabox.org
Cc: devicet...@vger.kernel.org

Andreas Färber (4):
  ARM64: Prepare Marvell IAP140 aka PXA1908
  Documentation: devicetree: arm: Document Marvell IAP140
  ARM64: dts: marvell: Add IAP140 and Andromeda Box Edge
  ARM64: dts: marvell: iap140-andromeda-box-edge: Add uart0 clock

 .../devicetree/bindings/arm/marvell/iap140.txt |   7 +
 arch/arm64/Kconfig.platforms   |   5 +
 arch/arm64/boot/dts/marvell/Makefile   |   2 +
 .../boot/dts/marvell/iap140-andromeda-box-edge.dts |  77 
 arch/arm64/boot/dts/marvell/iap140.dtsi| 195 +
 drivers/clk/Kconfig|   2 +-
 drivers/mmc/host/Kconfig   |   2 +-
 drivers/tty/serial/Kconfig |   2 +-
 8 files changed, 289 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/iap140.txt
 create mode 100644 arch/arm64/boot/dts/marvell/iap140-andromeda-box-edge.dts
 create mode 100644 arch/arm64/boot/dts/marvell/iap140.dtsi

-- 
2.10.2

[PATCH 3/4] ARM64: dts: marvell: Add IAP140 and Andromeda Box Edge

PPI interrupts 11, 10, 9 are guesses, and so are the second two memory
regions of the GIC.

Signed-off-by: Andreas Färber 
---
 arch/arm64/boot/dts/marvell/Makefile   |   2 +
 .../boot/dts/marvell/iap140-andromeda-box-edge.dts |  70 
 arch/arm64/boot/dts/marvell/iap140.dtsi| 195 +
 3 files changed, 267 insertions(+)
 create mode 100644 arch/arm64/boot/dts/marvell/iap140-andromeda-box-edge.dts
 create mode 100644 arch/arm64/boot/dts/marvell/iap140.dtsi

diff --git a/arch/arm64/boot/dts/marvell/Makefile 
b/arch/arm64/boot/dts/marvell/Makefile
index 3e6ce6c..d2046be 100644
--- a/arch/arm64/boot/dts/marvell/Makefile
+++ b/arch/arm64/boot/dts/marvell/Makefile
@@ -9,6 +9,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += armada-7040-db.dtb
 dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-db.dtb
 dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-mcbin.dtb
 
+dtb-$(CONFIG_ARCH_PXA) += iap140-andromeda-box-edge.dtb
+
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
 clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/marvell/iap140-andromeda-box-edge.dts 
b/arch/arm64/boot/dts/marvell/iap140-andromeda-box-edge.dts
new file mode 100644
index 000..de01d93
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/iap140-andromeda-box-edge.dts
@@ -0,0 +1,70 @@
+/*
+ * Copyright (c) 2016-2017 Andreas Färber
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+/memreserve/ 0x0900 0x0100;
+/memreserve/ 0x0a00 0x0008;
+
+#include "iap140.dtsi"
+
+/ {
+   compatible = "mrvl,andromeda-box-edge", "mrvl,iap140";
+   model = "Andromeda Box Edge";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x0 0x0 0x4000>;
+   };
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/marvell/iap140.dtsi 
b/arch/arm64/boot/dts/marvell/iap140.dtsi
new file mode 100644
index 000..38acb14
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/iap140.dtsi
@@ -0,0 +1,195 @@
+/*
+ * Copyright (c) 2016-2017 Andreas Färber
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of

[PATCH 0/4] ARM64: Initial Marvell IAP140 enablement

Hello,

This mini-series adds initial support for the Marvell IAP140 SoC (aka PXA1908)
and the Andromeda Box Edge development board.

In order to enable the 8250 UART driver, it reuses ARCH_PXA; but some drivers
enabled with ARCH_PXA don't build due to arm assembly or arm64's lack of mach-,
so their dependencies need to be limited to ARM alongside (blacklisted). The
alternative would of course be to choose a new ARCH_ symbol and to selectively
add it to drivers known working (whitelisting). The latter would require
finding a suitable name.

Both earlycon and serial are working, but an explicit console=ttyS0,115200n8
is needed; with just "earlycon" and stdout-path the earlycon stops early and
switches to a tty0, long before disabling the bootconsole...

All four CPUs come up, and an initrd can be reached.

However, there are errors about CPUs 1-3 having a zero SYS_CNTFRQ_EL0:

[0.095812] smp: Bringing up secondary CPUs ...
==pxa1908_pmu_core_pwr_on: mpidr = 0x1
==pxa1908_pmu_core_pwr_on: mpidr = 0x2
==pxa1908_pmu_core_pwr_on: mpidr = 0x3
[0.133419] Detected VIPT I-cache on CPU1
[0.133430] CPU features: SANITY CHECK: Unexpected variation in 
SYS_CNTFRQ_EL0. Boot CPU: 0x00018cba80, CPU1: 0x00
[0.133447] Unsupported CPU feature variation.
...
[0.133748] CPU1: Booted secondary processor [410fd032]
[0.165465] Detected VIPT I-cache on CPU2
[0.165474] CPU features: SANITY CHECK: Unexpected variation in 
SYS_CNTFRQ_EL0. Boot CPU: 0x00018cba80, CPU2: 0x00
[0.165505] CPU2: Booted secondary processor [410fd032]
[0.197539] Detected VIPT I-cache on CPU3
[0.197546] CPU features: SANITY CHECK: Unexpected variation in 
SYS_CNTFRQ_EL0. Boot CPU: 0x00018cba80, CPU3: 0x00
[0.197573] CPU3: Booted secondary processor [410fd032]
[0.197625] smp: Brought up 1 node, 4 CPUs
[0.522514] SMP: Total of 4 processors activated.
[0.527212] CPU features: detected feature: 32-bit EL0 Support
[0.533105] CPU: All CPU(s) started at EL2

KVM appears to initialize okay, but was not yet tested with guests.

[0.865255] kvm [1]: 8-bit VMID
[0.868401] kvm [1]: IDMAP page: d23000
[0.872233] kvm [1]: HYP VA range: 8000:
[0.878262] kvm [1]: Hyp mode initialized successfully
[0.883429] kvm [1]: vgic-v2@d1dfc000
[0.887179] kvm [1]: vgic interrupt IRQ1
[0.891120] kvm [1]: virtual timer IRQ4

More Marvell drivers may be available in-tree for reuse - besides build errors
the limitation is currently the lack of an IAP140 clk driver though. Patch 4/4
works around that for UART0 with a fixed-clock.

A 3.14 based tree is available on GitHub acorn-marvell/brillo_pxa_kernel. No
driver comparisons to mainline have been attempted yet.

Booting required changes to the vendor U-Boot,
cf. https://en.opensuse.org/HCL:AndromedaBoxEdge

https://github.com/afaerber/linux/commits/edge-next

Have a lot of fun!

Cheers,
Andreas

Cc: i...@andromedabox.org
Cc: devicet...@vger.kernel.org

Andreas Färber (4):
  ARM64: Prepare Marvell IAP140 aka PXA1908
  Documentation: devicetree: arm: Document Marvell IAP140
  ARM64: dts: marvell: Add IAP140 and Andromeda Box Edge
  ARM64: dts: marvell: iap140-andromeda-box-edge: Add uart0 clock

 .../devicetree/bindings/arm/marvell/iap140.txt |   7 +
 arch/arm64/Kconfig.platforms   |   5 +
 arch/arm64/boot/dts/marvell/Makefile   |   2 +
 .../boot/dts/marvell/iap140-andromeda-box-edge.dts |  77 
 arch/arm64/boot/dts/marvell/iap140.dtsi| 195 +
 drivers/clk/Kconfig|   2 +-
 drivers/mmc/host/Kconfig   |   2 +-
 drivers/tty/serial/Kconfig |   2 +-
 8 files changed, 289 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/iap140.txt
 create mode 100644 arch/arm64/boot/dts/marvell/iap140-andromeda-box-edge.dts
 create mode 100644 arch/arm64/boot/dts/marvell/iap140.dtsi

-- 
2.10.2

[PATCH: KS7010 Update complex macros] Wrapping complex macros with parentheses. Formatting changes to comply with checkpatch.

2017-02-18 Thread Matthew Giassa

Signed-off-by: Matthew Giassa 
---
 drivers/staging/ks7010/ks_wlan_ioctl.h | 80 +-
 1 file changed, 41 insertions(+), 39 deletions(-)

diff --git a/drivers/staging/ks7010/ks_wlan_ioctl.h 
b/drivers/staging/ks7010/ks_wlan_ioctl.h
index 84554b6..00eec18 100644
--- a/drivers/staging/ks7010/ks_wlan_ioctl.h
+++ b/drivers/staging/ks7010/ks_wlan_ioctl.h
@@ -1,6 +1,6 @@
 /*
  *   Driver for KeyStream 11b/g wireless LAN
- *   
+ *
  *   Copyright (c) 2005-2008 KeyStream Corp.
  *   Copyright (C) 2009 Renesas Technology Corp.
  *
@@ -8,60 +8,62 @@
  *   it under the terms of the GNU General Public License version 2 as
  *   published by the Free Software Foundation.
  */
-
 #ifndef _KS_WLAN_IOCTL_H
 #define _KS_WLAN_IOCTL_H
 
 #include 
-/* The low order bit identify a SET (0) or a GET (1) ioctl.  */
+/* The low order bit identify a SET (0) or a GET (1) ioctl. */
 
-/* SIOCIWFIRSTPRIV+0 */
-/* former KS_WLAN_GET_DRIVER_VERSION   SIOCIWFIRSTPRIV+1 */
-/* SIOCIWFIRSTPRIV+2 */
-#define KS_WLAN_GET_FIRM_VERSION   SIOCIWFIRSTPRIV+3
+/* (SIOCIWFIRSTPRIV + 0) */
+/* Former KS_WLAN_GET_DRIVER_VERSION   (SIOCIWFIRSTPRIV + 1) */
+/* (SIOCIWFIRSTPRIV + 2) */
+#define KS_WLAN_GET_FIRM_VERSION   (SIOCIWFIRSTPRIV + 3)
 #ifdef WPS
-#define KS_WLAN_SET_WPS_ENABLE SIOCIWFIRSTPRIV+4
-#define KS_WLAN_GET_WPS_ENABLE SIOCIWFIRSTPRIV+5
-#define KS_WLAN_SET_WPS_PROBE_REQ  SIOCIWFIRSTPRIV+6
+#define KS_WLAN_SET_WPS_ENABLE (SIOCIWFIRSTPRIV + 4)
+#define KS_WLAN_GET_WPS_ENABLE (SIOCIWFIRSTPRIV + 5)
+#define KS_WLAN_SET_WPS_PROBE_REQ  (SIOCIWFIRSTPRIV + 6)
 #endif
-#define KS_WLAN_GET_EEPROM_CKSUM   SIOCIWFIRSTPRIV+7
-#define KS_WLAN_SET_PREAMBLE   SIOCIWFIRSTPRIV+8
-#define KS_WLAN_GET_PREAMBLE   SIOCIWFIRSTPRIV+9
-#define KS_WLAN_SET_POWER_SAVE SIOCIWFIRSTPRIV+10
-#define KS_WLAN_GET_POWER_SAVE SIOCIWFIRSTPRIV+11
-#define KS_WLAN_SET_SCAN_TYPE  SIOCIWFIRSTPRIV+12
-#define KS_WLAN_GET_SCAN_TYPE  SIOCIWFIRSTPRIV+13
-#define KS_WLAN_SET_RX_GAINSIOCIWFIRSTPRIV+14
-#define KS_WLAN_GET_RX_GAINSIOCIWFIRSTPRIV+15
-#define KS_WLAN_HOSTT  SIOCIWFIRSTPRIV+16  /* unused */
-//#define KS_WLAN_SET_REGIONSIOCIWFIRSTPRIV+17
-#define KS_WLAN_SET_BEACON_LOSTSIOCIWFIRSTPRIV+18
-#define KS_WLAN_GET_BEACON_LOSTSIOCIWFIRSTPRIV+19
+#define KS_WLAN_GET_EEPROM_CKSUM   (SIOCIWFIRSTPRIV + 7)
+#define KS_WLAN_SET_PREAMBLE   (SIOCIWFIRSTPRIV + 8)
+#define KS_WLAN_GET_PREAMBLE   (SIOCIWFIRSTPRIV + 9)
+#define KS_WLAN_SET_POWER_SAVE (SIOCIWFIRSTPRIV + 10)
+#define KS_WLAN_GET_POWER_SAVE (SIOCIWFIRSTPRIV + 11)
+#define KS_WLAN_SET_SCAN_TYPE  (SIOCIWFIRSTPRIV + 12)
+#define KS_WLAN_GET_SCAN_TYPE  (SIOCIWFIRSTPRIV + 13)
+#define KS_WLAN_SET_RX_GAIN(SIOCIWFIRSTPRIV + 14)
+#define KS_WLAN_GET_RX_GAIN(SIOCIWFIRSTPRIV + 15)
+#define KS_WLAN_HOSTT  (SIOCIWFIRSTPRIV + 16)  /* unused */
+/*#define KS_WLAN_SET_REGION(SIOCIWFIRSTPRIV + 17) */
+#define KS_WLAN_SET_BEACON_LOST(SIOCIWFIRSTPRIV + 18)
+#define KS_WLAN_GET_BEACON_LOST(SIOCIWFIRSTPRIV + 19)
 
-#define KS_WLAN_SET_TX_GAINSIOCIWFIRSTPRIV+20
-#define KS_WLAN_GET_TX_GAINSIOCIWFIRSTPRIV+21
+#define KS_WLAN_SET_TX_GAIN(SIOCIWFIRSTPRIV + 20)
+#define KS_WLAN_GET_TX_GAIN(SIOCIWFIRSTPRIV + 21)
 
-/* for KS7010 */
-#define KS_WLAN_SET_PHY_TYPE   SIOCIWFIRSTPRIV+22
-#define KS_WLAN_GET_PHY_TYPE   SIOCIWFIRSTPRIV+23
-#define KS_WLAN_SET_CTS_MODE   SIOCIWFIRSTPRIV+24
-#define KS_WLAN_GET_CTS_MODE   SIOCIWFIRSTPRIV+25
-/* SIOCIWFIRSTPRIV+26 */
-/* SIOCIWFIRSTPRIV+27 */
-#define KS_WLAN_SET_SLEEP_MODE SIOCIWFIRSTPRIV+28  /* sleep mode */
-#define KS_WLAN_GET_SLEEP_MODE SIOCIWFIRSTPRIV+29  /* sleep mode */
-/* SIOCIWFIRSTPRIV+30 */
-/* SIOCIWFIRSTPRIV+31 */
+/* For KS7010. */
+#define KS_WLAN_SET_PHY_TYPE   (SIOCIWFIRSTPRIV + 22)
+#define KS_WLAN_GET_PHY_TYPE   (SIOCIWFIRSTPRIV + 23)
+#define KS_WLAN_SET_CTS_MODE   (SIOCIWFIRSTPRIV + 24)
+#define KS_WLAN_GET_CTS_MODE   (SIOCIWFIRSTPRIV + 25)
+/* (SIOCIWFIRSTPRIV + 26) */
+/* (SIOCIWFIRSTPRIV + 27) */
+#define KS_WLAN_SET_SLEEP_MODE (SIOCIWFIRSTPRIV + 28)  /* sleep mode */
+#define KS_WLAN_GET_SLEEP_MODE (SIOCIWFIRSTPRIV + 29)  /* sleep mode */
+/* (SIOCIWFIRSTPRIV +

[PATCH: KS7010 Update complex macros] Wrapping complex macros with parentheses. Formatting changes to comply with checkpatch.

2017-02-18 Thread Matthew Giassa

Signed-off-by: Matthew Giassa 
---
 drivers/staging/ks7010/ks_wlan_ioctl.h | 80 +-
 1 file changed, 41 insertions(+), 39 deletions(-)

diff --git a/drivers/staging/ks7010/ks_wlan_ioctl.h 
b/drivers/staging/ks7010/ks_wlan_ioctl.h
index 84554b6..00eec18 100644
--- a/drivers/staging/ks7010/ks_wlan_ioctl.h
+++ b/drivers/staging/ks7010/ks_wlan_ioctl.h
@@ -1,6 +1,6 @@
 /*
  *   Driver for KeyStream 11b/g wireless LAN
- *   
+ *
  *   Copyright (c) 2005-2008 KeyStream Corp.
  *   Copyright (C) 2009 Renesas Technology Corp.
  *
@@ -8,60 +8,62 @@
  *   it under the terms of the GNU General Public License version 2 as
  *   published by the Free Software Foundation.
  */
-
 #ifndef _KS_WLAN_IOCTL_H
 #define _KS_WLAN_IOCTL_H
 
 #include 
-/* The low order bit identify a SET (0) or a GET (1) ioctl.  */
+/* The low order bit identify a SET (0) or a GET (1) ioctl. */
 
-/* SIOCIWFIRSTPRIV+0 */
-/* former KS_WLAN_GET_DRIVER_VERSION   SIOCIWFIRSTPRIV+1 */
-/* SIOCIWFIRSTPRIV+2 */
-#define KS_WLAN_GET_FIRM_VERSION   SIOCIWFIRSTPRIV+3
+/* (SIOCIWFIRSTPRIV + 0) */
+/* Former KS_WLAN_GET_DRIVER_VERSION   (SIOCIWFIRSTPRIV + 1) */
+/* (SIOCIWFIRSTPRIV + 2) */
+#define KS_WLAN_GET_FIRM_VERSION   (SIOCIWFIRSTPRIV + 3)
 #ifdef WPS
-#define KS_WLAN_SET_WPS_ENABLE SIOCIWFIRSTPRIV+4
-#define KS_WLAN_GET_WPS_ENABLE SIOCIWFIRSTPRIV+5
-#define KS_WLAN_SET_WPS_PROBE_REQ  SIOCIWFIRSTPRIV+6
+#define KS_WLAN_SET_WPS_ENABLE (SIOCIWFIRSTPRIV + 4)
+#define KS_WLAN_GET_WPS_ENABLE (SIOCIWFIRSTPRIV + 5)
+#define KS_WLAN_SET_WPS_PROBE_REQ  (SIOCIWFIRSTPRIV + 6)
 #endif
-#define KS_WLAN_GET_EEPROM_CKSUM   SIOCIWFIRSTPRIV+7
-#define KS_WLAN_SET_PREAMBLE   SIOCIWFIRSTPRIV+8
-#define KS_WLAN_GET_PREAMBLE   SIOCIWFIRSTPRIV+9
-#define KS_WLAN_SET_POWER_SAVE SIOCIWFIRSTPRIV+10
-#define KS_WLAN_GET_POWER_SAVE SIOCIWFIRSTPRIV+11
-#define KS_WLAN_SET_SCAN_TYPE  SIOCIWFIRSTPRIV+12
-#define KS_WLAN_GET_SCAN_TYPE  SIOCIWFIRSTPRIV+13
-#define KS_WLAN_SET_RX_GAINSIOCIWFIRSTPRIV+14
-#define KS_WLAN_GET_RX_GAINSIOCIWFIRSTPRIV+15
-#define KS_WLAN_HOSTT  SIOCIWFIRSTPRIV+16  /* unused */
-//#define KS_WLAN_SET_REGIONSIOCIWFIRSTPRIV+17
-#define KS_WLAN_SET_BEACON_LOSTSIOCIWFIRSTPRIV+18
-#define KS_WLAN_GET_BEACON_LOSTSIOCIWFIRSTPRIV+19
+#define KS_WLAN_GET_EEPROM_CKSUM   (SIOCIWFIRSTPRIV + 7)
+#define KS_WLAN_SET_PREAMBLE   (SIOCIWFIRSTPRIV + 8)
+#define KS_WLAN_GET_PREAMBLE   (SIOCIWFIRSTPRIV + 9)
+#define KS_WLAN_SET_POWER_SAVE (SIOCIWFIRSTPRIV + 10)
+#define KS_WLAN_GET_POWER_SAVE (SIOCIWFIRSTPRIV + 11)
+#define KS_WLAN_SET_SCAN_TYPE  (SIOCIWFIRSTPRIV + 12)
+#define KS_WLAN_GET_SCAN_TYPE  (SIOCIWFIRSTPRIV + 13)
+#define KS_WLAN_SET_RX_GAIN(SIOCIWFIRSTPRIV + 14)
+#define KS_WLAN_GET_RX_GAIN(SIOCIWFIRSTPRIV + 15)
+#define KS_WLAN_HOSTT  (SIOCIWFIRSTPRIV + 16)  /* unused */
+/*#define KS_WLAN_SET_REGION(SIOCIWFIRSTPRIV + 17) */
+#define KS_WLAN_SET_BEACON_LOST(SIOCIWFIRSTPRIV + 18)
+#define KS_WLAN_GET_BEACON_LOST(SIOCIWFIRSTPRIV + 19)
 
-#define KS_WLAN_SET_TX_GAINSIOCIWFIRSTPRIV+20
-#define KS_WLAN_GET_TX_GAINSIOCIWFIRSTPRIV+21
+#define KS_WLAN_SET_TX_GAIN(SIOCIWFIRSTPRIV + 20)
+#define KS_WLAN_GET_TX_GAIN(SIOCIWFIRSTPRIV + 21)
 
-/* for KS7010 */
-#define KS_WLAN_SET_PHY_TYPE   SIOCIWFIRSTPRIV+22
-#define KS_WLAN_GET_PHY_TYPE   SIOCIWFIRSTPRIV+23
-#define KS_WLAN_SET_CTS_MODE   SIOCIWFIRSTPRIV+24
-#define KS_WLAN_GET_CTS_MODE   SIOCIWFIRSTPRIV+25
-/* SIOCIWFIRSTPRIV+26 */
-/* SIOCIWFIRSTPRIV+27 */
-#define KS_WLAN_SET_SLEEP_MODE SIOCIWFIRSTPRIV+28  /* sleep mode */
-#define KS_WLAN_GET_SLEEP_MODE SIOCIWFIRSTPRIV+29  /* sleep mode */
-/* SIOCIWFIRSTPRIV+30 */
-/* SIOCIWFIRSTPRIV+31 */
+/* For KS7010. */
+#define KS_WLAN_SET_PHY_TYPE   (SIOCIWFIRSTPRIV + 22)
+#define KS_WLAN_GET_PHY_TYPE   (SIOCIWFIRSTPRIV + 23)
+#define KS_WLAN_SET_CTS_MODE   (SIOCIWFIRSTPRIV + 24)
+#define KS_WLAN_GET_CTS_MODE   (SIOCIWFIRSTPRIV + 25)
+/* (SIOCIWFIRSTPRIV + 26) */
+/* (SIOCIWFIRSTPRIV + 27) */
+#define KS_WLAN_SET_SLEEP_MODE (SIOCIWFIRSTPRIV + 28)  /* sleep mode */
+#define KS_WLAN_GET_SLEEP_MODE (SIOCIWFIRSTPRIV + 29)  /* sleep mode */
+/* (SIOCIWFIRSTPRIV + 30) */
+/*

Re: [PATCH] arm64: traps: Mark le16, le32, __user variables properly

2017-02-18 Thread Luc Van Oostenryck

On Fri, Feb 17, 2017 at 08:51:12AM -0800, Stephen Boyd wrote:
> Sparse complains a bit on this file about endian issues and
> __user casting:
> 
> arch/arm64/kernel/traps.c:87:37: warning: incorrect type in argument 1 
> (different address spaces)
> arch/arm64/kernel/traps.c:87:37:expected void const volatile [noderef] 
> *
> arch/arm64/kernel/traps.c:87:37:got unsigned long *
> arch/arm64/kernel/traps.c:116:23: warning: incorrect type in argument 1 
> (different address spaces)
> arch/arm64/kernel/traps.c:116:23:expected void const volatile [noderef] 
> *
> arch/arm64/kernel/traps.c:116:23:got unsigned int [usertype] *

The fact that __get_user() can and is used for both __kernel & __user pointers
defeat any sensible annotation. The proper way would be to have a special
version of __get_user() which would ignore the __user part of the pointer,
something like "__get_user_but_accept_any_pointer()" ...


> arch/arm64/kernel/traps.c:346:25: warning: cast to restricted __le16
> arch/arm64/kernel/traps.c:352:34: warning: cast to restricted __le16
> arch/arm64/kernel/traps.c:359:25: warning: cast to restricted __le32

Your patch looked correct to me for those.
 
> Mark the types appropriately, and force the cast in get_user()
> when assigning to 0 so sparse doesn't complain.
I didn't looked deeply at this one but I don't think it is needed.
Care to give more details?


> Noticed while making other changes to this file. There are other issues still
> about marking symbols static, but I'm not sure we want to introduce another
> header file for the asmlinkage functions?
Probably not, indeed.

> arch/arm64/kernel/traps.c:567:10: warning: Initializer entry defined twice
> arch/arm64/kernel/traps.c:568:10:   also defined here
This one I find strange. Can you tell which are those two entries?

 
> diff --git a/arch/arm64/include/asm/uaccess.h 
> b/arch/arm64/include/asm/uaccess.h
> index 46da3ea638bb..2f5b4ae98ee0 100644
> --- a/arch/arm64/include/asm/uaccess.h
> +++ b/arch/arm64/include/asm/uaccess.h
> @@ -287,7 +287,7 @@ do {  
> \
>   might_fault();  \
>   access_ok(VERIFY_READ, __p, sizeof(*__p)) ? \
>   __get_user((x), __p) :  \
> - ((x) = 0, -EFAULT); \
> + ((x) = (__force __typeof__(*(ptr)))0, -EFAULT); \
>  })

As said above, this one is dubious.


Luc Van Oostenryck

Re: [PATCH] arm64: traps: Mark le16, le32, __user variables properly

2017-02-18 Thread Luc Van Oostenryck

On Fri, Feb 17, 2017 at 08:51:12AM -0800, Stephen Boyd wrote:
> Sparse complains a bit on this file about endian issues and
> __user casting:
> 
> arch/arm64/kernel/traps.c:87:37: warning: incorrect type in argument 1 
> (different address spaces)
> arch/arm64/kernel/traps.c:87:37:expected void const volatile [noderef] 
> *
> arch/arm64/kernel/traps.c:87:37:got unsigned long *
> arch/arm64/kernel/traps.c:116:23: warning: incorrect type in argument 1 
> (different address spaces)
> arch/arm64/kernel/traps.c:116:23:expected void const volatile [noderef] 
> *
> arch/arm64/kernel/traps.c:116:23:got unsigned int [usertype] *

The fact that __get_user() can and is used for both __kernel & __user pointers
defeat any sensible annotation. The proper way would be to have a special
version of __get_user() which would ignore the __user part of the pointer,
something like "__get_user_but_accept_any_pointer()" ...


> arch/arm64/kernel/traps.c:346:25: warning: cast to restricted __le16
> arch/arm64/kernel/traps.c:352:34: warning: cast to restricted __le16
> arch/arm64/kernel/traps.c:359:25: warning: cast to restricted __le32

Your patch looked correct to me for those.
 
> Mark the types appropriately, and force the cast in get_user()
> when assigning to 0 so sparse doesn't complain.
I didn't looked deeply at this one but I don't think it is needed.
Care to give more details?


> Noticed while making other changes to this file. There are other issues still
> about marking symbols static, but I'm not sure we want to introduce another
> header file for the asmlinkage functions?
Probably not, indeed.

> arch/arm64/kernel/traps.c:567:10: warning: Initializer entry defined twice
> arch/arm64/kernel/traps.c:568:10:   also defined here
This one I find strange. Can you tell which are those two entries?

 
> diff --git a/arch/arm64/include/asm/uaccess.h 
> b/arch/arm64/include/asm/uaccess.h
> index 46da3ea638bb..2f5b4ae98ee0 100644
> --- a/arch/arm64/include/asm/uaccess.h
> +++ b/arch/arm64/include/asm/uaccess.h
> @@ -287,7 +287,7 @@ do {  
> \
>   might_fault();  \
>   access_ok(VERIFY_READ, __p, sizeof(*__p)) ? \
>   __get_user((x), __p) :  \
> - ((x) = 0, -EFAULT); \
> + ((x) = (__force __typeof__(*(ptr)))0, -EFAULT); \
>  })

As said above, this one is dubious.


Luc Van Oostenryck

Re: [PATCH v3 1/5] vfs: Add file timestamp range support

On Sat, Feb 18, 2017 at 03:30:04PM -0800, Deepa Dinamani wrote:
> Add fields to the superblock to track the min and max
> timestamps supported by filesystems.
> 
> Initially, when a superblock is allocated, initialize
> it to the max and min values the fields can hold.
> Individual filesystems override these to match their
> actual limits.
> 
> Pseudo filesystems are assumed to always support the
> min and max allowable values for the fields.

> @@ -257,6 +257,8 @@ struct dentry *mount_pseudo_xattr(struct file_system_type 
> *fs_type, char *name,
> + s->s_time_min = TIME64_MIN;
> + s->s_time_max = TIME64_MAX;
> @@ -518,6 +520,8 @@ int simple_fill_super(struct super_block *s, unsigned 
> long magic,
> + s->s_time_min = TIME64_MIN;
> + s->s_time_max = TIME64_MAX;
> @@ -247,6 +247,8 @@ static struct super_block *alloc_super(struct 
> file_system_type *type, int flags,
> + s->s_time_min = TIME64_MIN;
> + s->s_time_max = TIME64_MAX;

If we always initialize them that way, why does libfs.c code bother
reassign the same values?

Re: [PATCH v3 1/5] vfs: Add file timestamp range support

On Sat, Feb 18, 2017 at 03:30:04PM -0800, Deepa Dinamani wrote:
> Add fields to the superblock to track the min and max
> timestamps supported by filesystems.
> 
> Initially, when a superblock is allocated, initialize
> it to the max and min values the fields can hold.
> Individual filesystems override these to match their
> actual limits.
> 
> Pseudo filesystems are assumed to always support the
> min and max allowable values for the fields.

> @@ -257,6 +257,8 @@ struct dentry *mount_pseudo_xattr(struct file_system_type 
> *fs_type, char *name,
> + s->s_time_min = TIME64_MIN;
> + s->s_time_max = TIME64_MAX;
> @@ -518,6 +520,8 @@ int simple_fill_super(struct super_block *s, unsigned 
> long magic,
> + s->s_time_min = TIME64_MIN;
> + s->s_time_max = TIME64_MAX;
> @@ -247,6 +247,8 @@ static struct super_block *alloc_super(struct 
> file_system_type *type, int flags,
> + s->s_time_min = TIME64_MIN;
> + s->s_time_max = TIME64_MAX;

If we always initialize them that way, why does libfs.c code bother
reassign the same values?

[GIT PULL] Thermal SoC management updates for v4.11-rc1 #1

Hello Rui,

Please pull the following changes to get the Thermal SoC updates
for 4.11-rc1. Here we have:
- thermal support for zx2967. thanks to Baoyou Xie.
- new driver support for rcar-gen3.
- a couple of fixes on TI, exynos, and IMX drivers.

I might also send a second pull, depending if we get new versions
of other two drivers that have been on review for some time.

BR,

The following changes since commit cdb98c2698b4af287925abcba4d77d92af82a0c3:

  Revert "nvme: add support for the Write Zeroes command" (2016-12-13 19:53:37 
-0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal linus

for you to fetch changes up to 992edf395b8a8411c506f4345bc04451eba95976:

  thermal: mtk_thermal: Staticise a number of data variables (2017-02-18 
17:44:29 -0800)


Baoyou Xie (2):
  dt: bindings: add documentation for zx2967 family thermal sensor
  thermal: zx2967: add thermal driver for ZTE's zx2967 family

Keerthy (3):
  thermal: ti-soc-thermal: Remove CPU_THERMAL Dependency from TI_THERMAL
  thermal: arm: dra752: Remove TSHUT configuration
  thermal: arm: dra752: Remove all TSHUT related definitions

Krzysztof Kozlowski (1):
  thermal: exynos: Remove parsing unused samsung,tmu_cal_mode property

Shailendra Verma (1):
  thermal: imx: Fix possible NULL dereference.

Vivek Gautam (1):
  thermal: mtk_thermal: Staticise a number of data variables

Wolfram Sang (2):
  thermal: rcar_gen3_thermal: Document the R-Car Gen3
  thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver

 .../bindings/thermal/rcar-gen3-thermal.txt |  56 
 .../devicetree/bindings/thermal/zx2967-thermal.txt | 116 +++
 drivers/thermal/Kconfig|  17 ++
 drivers/thermal/Makefile   |   2 +
 drivers/thermal/imx_thermal.c  |   4 +
 drivers/thermal/mtk_thermal.c  |  16 +-
 drivers/thermal/rcar_gen3_thermal.c| 335 +
 drivers/thermal/samsung/exynos_tmu.c   |   1 -
 drivers/thermal/samsung/exynos_tmu.h   |   1 -
 drivers/thermal/ti-soc-thermal/Kconfig |   1 -
 drivers/thermal/ti-soc-thermal/dra752-bandgap.h|  19 --
 .../thermal/ti-soc-thermal/dra752-thermal-data.c   |  28 +-
 drivers/thermal/zx2967_thermal.c   | 258 
 13 files changed, 797 insertions(+), 57 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
 create mode 100644 Documentation/devicetree/bindings/thermal/zx2967-thermal.txt
 create mode 100644 drivers/thermal/rcar_gen3_thermal.c
 create mode 100644 drivers/thermal/zx2967_thermal.c

[GIT PULL] Thermal SoC management updates for v4.11-rc1 #1

Hello Rui,

Please pull the following changes to get the Thermal SoC updates
for 4.11-rc1. Here we have:
- thermal support for zx2967. thanks to Baoyou Xie.
- new driver support for rcar-gen3.
- a couple of fixes on TI, exynos, and IMX drivers.

I might also send a second pull, depending if we get new versions
of other two drivers that have been on review for some time.

BR,

The following changes since commit cdb98c2698b4af287925abcba4d77d92af82a0c3:

  Revert "nvme: add support for the Write Zeroes command" (2016-12-13 19:53:37 
-0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal linus

for you to fetch changes up to 992edf395b8a8411c506f4345bc04451eba95976:

  thermal: mtk_thermal: Staticise a number of data variables (2017-02-18 
17:44:29 -0800)


Baoyou Xie (2):
  dt: bindings: add documentation for zx2967 family thermal sensor
  thermal: zx2967: add thermal driver for ZTE's zx2967 family

Keerthy (3):
  thermal: ti-soc-thermal: Remove CPU_THERMAL Dependency from TI_THERMAL
  thermal: arm: dra752: Remove TSHUT configuration
  thermal: arm: dra752: Remove all TSHUT related definitions

Krzysztof Kozlowski (1):
  thermal: exynos: Remove parsing unused samsung,tmu_cal_mode property

Shailendra Verma (1):
  thermal: imx: Fix possible NULL dereference.

Vivek Gautam (1):
  thermal: mtk_thermal: Staticise a number of data variables

Wolfram Sang (2):
  thermal: rcar_gen3_thermal: Document the R-Car Gen3
  thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver

 .../bindings/thermal/rcar-gen3-thermal.txt |  56 
 .../devicetree/bindings/thermal/zx2967-thermal.txt | 116 +++
 drivers/thermal/Kconfig|  17 ++
 drivers/thermal/Makefile   |   2 +
 drivers/thermal/imx_thermal.c  |   4 +
 drivers/thermal/mtk_thermal.c  |  16 +-
 drivers/thermal/rcar_gen3_thermal.c| 335 +
 drivers/thermal/samsung/exynos_tmu.c   |   1 -
 drivers/thermal/samsung/exynos_tmu.h   |   1 -
 drivers/thermal/ti-soc-thermal/Kconfig |   1 -
 drivers/thermal/ti-soc-thermal/dra752-bandgap.h|  19 --
 .../thermal/ti-soc-thermal/dra752-thermal-data.c   |  28 +-
 drivers/thermal/zx2967_thermal.c   | 258 
 13 files changed, 797 insertions(+), 57 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
 create mode 100644 Documentation/devicetree/bindings/thermal/zx2967-thermal.txt
 create mode 100644 drivers/thermal/rcar_gen3_thermal.c
 create mode 100644 drivers/thermal/zx2967_thermal.c

Re: [RESEND PATCH V5 7/8] thermal: da9062/61: Thermal junction temperature monitoring driver

Steve,

On Thu, Feb 02, 2017 at 09:03:47AM +, Steve Twiss wrote:
> From: Steve Twiss 
> 
> Add junction temperature monitoring supervisor device driver, compatible
> with the DA9062 and DA9061 PMICs. A MODULE_DEVICE_TABLE() macro is added.
> 
> If the PMIC's internal junction temperature rises above T_WARN (125 degC)
> an interrupt is issued. This T_WARN level is defined as the
> THERMAL_TRIP_HOT trip-wire inside the device driver.
> 
> The thermal triggering mechanism is interrupt based and happens when the
> temperature rises above a given threshold level. The component cannot
> return an exact temperature, it only has knowledge if the temperature is
> above or below a given threshold value. A status bit must be polled to
> detect when the temperature falls below that threshold level again. A
> kernel work queue is configured to repeatedly poll and detect when the
> temperature falls below this trip-wire, between 1 and 10 second intervals
> (defaulting at 3 seconds).
> 
> This scheme is provided as an example. It would be expected that any
> final implementation will also include a notify() function and any of these
> settings could be altered to match the application where appropriate.
> 
> When over-temperature is reached, the interrupt from the DA9061/2 will be
> repeatedly triggered. The IRQ is therefore disabled when the first
> over-temperature event happens and the status bit is polled using a
> work-queue until it becomes false.
> 
> This strategy is designed to allow the periodic transmission of uevents
> (HOT trip point) as the first level of temperature supervision method. It
> is intended for non-invasive temperature control, where the necessary
> measures for cooling the system down are left to the host software. Once
> the temperature falls again, the IRQ is re-enabled so a new critical
> over-temperature event can be detected.
> 
> Reviewed-by: Lukasz Luba 
> Signed-off-by: Steve Twiss 
> 

Apologize for the very late answer on your driver. I still have few
minor requests, please check then:


> ---
> This patch applies against linux-next and v4.9
> 
> v4 -> v5
>  - Rebased from v4.8 to v4.9
>  - Updates from comments by Eduardo Valentin
>  - Replace vendor defined dlg,tjunc-temp-polling-period-ms with standard
>thermal core polling-delay-passive as part of the device tree
>initialisation
>  - Change to the commit message content and device driver source code to
>include an explanation of the repeated uevent strategy for monitoring
>over-temperature
>  - Rename warning threshold name from TEMP_WARN to T_WARN to match the
>latest datasheet naming convention
>  - Added reviewed-by Lukasz Luba to commit message
> 
> v3 -> v4
>  - Patch renamed from [PATCH V3 8/9] to [PATCH V4 7/8]
>  - Reordering of cancel_delayed_work_sync() in remove function
>  - dev_warn() message for out-of-range polling period requests
>  - Explanatory comment for expected values defined for
>DEFAULT_POLLING_MS_PERIOD, MAX_POLLING_MS_PERIOD and
>MIN_POLLING_MS_PERIOD
> 
> v2 -> v3
>  - Patch renamed from [PATCH V2 09/10] to [PATCH V3 8/9]
>  - Addition of MODULE_DEVICE_TABLE macro to allow modinfo additions
> 
> v1 -> v2
>  - Patch renamed from [PATCH V1 05/10] to [PATCH V2 09/10] -- these
>changes were made to fix checkpatch warnings caused by the patch
>set dependency order
>  - List the header files in alphabetical order
>  - Remove "GPL v2" and replace with MODULE_LICENSE("GPL") to match the
>copyright "GNU Public License v2 or later" option in the header
>comment for this file. See the allowed identifiers in the file
>include/linux/module.h +170
>  - Remove notify function "da9062_thermal_notify" function.
>  - MODULE_AUTHOR() macros removes Company Name and just gives Name in
>accordance with include/linux/module.h +200
>  - Remove the compatible "dlg,da9061-thermal" option in the of_device_id
>struct table. This patch now assumes the use of a DA9062 fallback
>compatible string in the DTS when using the DA9061 thermal component
>of the DA9061 device.
>  - Re-ordered some assignments earlier in the probe() for thermal->hw,
>thermal->polling_period, thermal->mode, thermal->dev
>  - Added further information in the patch description to explain the use
>of the device driver's built-in work-queue.
> 
> Regards,
> Steve Twiss, Dialog Semiconductor Ltd.
> 
> 
>  drivers/thermal/Kconfig  |  10 ++
>  drivers/thermal/Makefile |   1 +
>  drivers/thermal/da9062-thermal.c | 314 
> +++
>  3 files changed, 325 insertions(+)
>  create mode 100644 drivers/thermal/da9062-thermal.c
> 
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index a13541b..400d15c 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -292,6 +292,16 @@ config DB8500_CPUFREQ_COOLING
> bound cpufreq

Re: [RESEND PATCH V5 7/8] thermal: da9062/61: Thermal junction temperature monitoring driver

Steve,

On Thu, Feb 02, 2017 at 09:03:47AM +, Steve Twiss wrote:
> From: Steve Twiss 
> 
> Add junction temperature monitoring supervisor device driver, compatible
> with the DA9062 and DA9061 PMICs. A MODULE_DEVICE_TABLE() macro is added.
> 
> If the PMIC's internal junction temperature rises above T_WARN (125 degC)
> an interrupt is issued. This T_WARN level is defined as the
> THERMAL_TRIP_HOT trip-wire inside the device driver.
> 
> The thermal triggering mechanism is interrupt based and happens when the
> temperature rises above a given threshold level. The component cannot
> return an exact temperature, it only has knowledge if the temperature is
> above or below a given threshold value. A status bit must be polled to
> detect when the temperature falls below that threshold level again. A
> kernel work queue is configured to repeatedly poll and detect when the
> temperature falls below this trip-wire, between 1 and 10 second intervals
> (defaulting at 3 seconds).
> 
> This scheme is provided as an example. It would be expected that any
> final implementation will also include a notify() function and any of these
> settings could be altered to match the application where appropriate.
> 
> When over-temperature is reached, the interrupt from the DA9061/2 will be
> repeatedly triggered. The IRQ is therefore disabled when the first
> over-temperature event happens and the status bit is polled using a
> work-queue until it becomes false.
> 
> This strategy is designed to allow the periodic transmission of uevents
> (HOT trip point) as the first level of temperature supervision method. It
> is intended for non-invasive temperature control, where the necessary
> measures for cooling the system down are left to the host software. Once
> the temperature falls again, the IRQ is re-enabled so a new critical
> over-temperature event can be detected.
> 
> Reviewed-by: Lukasz Luba 
> Signed-off-by: Steve Twiss 
> 

Apologize for the very late answer on your driver. I still have few
minor requests, please check then:


> ---
> This patch applies against linux-next and v4.9
> 
> v4 -> v5
>  - Rebased from v4.8 to v4.9
>  - Updates from comments by Eduardo Valentin
>  - Replace vendor defined dlg,tjunc-temp-polling-period-ms with standard
>thermal core polling-delay-passive as part of the device tree
>initialisation
>  - Change to the commit message content and device driver source code to
>include an explanation of the repeated uevent strategy for monitoring
>over-temperature
>  - Rename warning threshold name from TEMP_WARN to T_WARN to match the
>latest datasheet naming convention
>  - Added reviewed-by Lukasz Luba to commit message
> 
> v3 -> v4
>  - Patch renamed from [PATCH V3 8/9] to [PATCH V4 7/8]
>  - Reordering of cancel_delayed_work_sync() in remove function
>  - dev_warn() message for out-of-range polling period requests
>  - Explanatory comment for expected values defined for
>DEFAULT_POLLING_MS_PERIOD, MAX_POLLING_MS_PERIOD and
>MIN_POLLING_MS_PERIOD
> 
> v2 -> v3
>  - Patch renamed from [PATCH V2 09/10] to [PATCH V3 8/9]
>  - Addition of MODULE_DEVICE_TABLE macro to allow modinfo additions
> 
> v1 -> v2
>  - Patch renamed from [PATCH V1 05/10] to [PATCH V2 09/10] -- these
>changes were made to fix checkpatch warnings caused by the patch
>set dependency order
>  - List the header files in alphabetical order
>  - Remove "GPL v2" and replace with MODULE_LICENSE("GPL") to match the
>copyright "GNU Public License v2 or later" option in the header
>comment for this file. See the allowed identifiers in the file
>include/linux/module.h +170
>  - Remove notify function "da9062_thermal_notify" function.
>  - MODULE_AUTHOR() macros removes Company Name and just gives Name in
>accordance with include/linux/module.h +200
>  - Remove the compatible "dlg,da9061-thermal" option in the of_device_id
>struct table. This patch now assumes the use of a DA9062 fallback
>compatible string in the DTS when using the DA9061 thermal component
>of the DA9061 device.
>  - Re-ordered some assignments earlier in the probe() for thermal->hw,
>thermal->polling_period, thermal->mode, thermal->dev
>  - Added further information in the patch description to explain the use
>of the device driver's built-in work-queue.
> 
> Regards,
> Steve Twiss, Dialog Semiconductor Ltd.
> 
> 
>  drivers/thermal/Kconfig  |  10 ++
>  drivers/thermal/Makefile |   1 +
>  drivers/thermal/da9062-thermal.c | 314 
> +++
>  3 files changed, 325 insertions(+)
>  create mode 100644 drivers/thermal/da9062-thermal.c
> 
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index a13541b..400d15c 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -292,6 +292,16 @@ config DB8500_CPUFREQ_COOLING
> bound cpufreq cooling device turns active to set CPU frequency low to
> cool down the CPU.
>

Re: [PATCH] Thermal - Fix possible NULL derefrence.

On Tue, Feb 07, 2017 at 11:30:13AM +0800, Zhang Rui wrote:
> Just one comment,
> the subject should be 
> [PATCH] Thermal: imx_thermal : Fix possible NULL derefrence

I fixed the commit title, but I am taking this one

Re: [PATCH] Thermal - Fix possible NULL derefrence.

On Tue, Feb 07, 2017 at 11:30:13AM +0800, Zhang Rui wrote:
> Just one comment,
> the subject should be 
> [PATCH] Thermal: imx_thermal : Fix possible NULL derefrence

I fixed the commit title, but I am taking this one

Re: [PATCH] thermal: mt8173: minor mtk_thermal.c cleanups

On Mon, Feb 13, 2017 at 05:01:58PM +0800, Dawei Chien wrote:
> Hi, Matthias,
> 
> On Thu, 2017-02-09 at 22:25 +0100, Matthias Brugger wrote:
> > 
> > On 02/08/2017 06:31 AM, Dawei Chien wrote:
> > > Thermal driver should read TEMP_MSR3 if thermal bank with 4 sensors.
> > > However, Currently thermal driver don't need read TEMP_MSR3 since
> > > thermal controller only use 3 sensors for each thermal bank.
> > >
> > > Signed-off-by: Dawei Chien 
> > > ---
> > 
> > Actually the commit message should state:
> > Fixes: b7cf0053738c ("thermal: Add Mediatek thermal driver for mt2701.")
> > 
> > ...and get backported to v4.9 and v4.10.
> > 
> > Reviewed-by: Matthias Brugger 
> > 
> > Regards,
> > Matthias
> 
> Thank you for your review. I would add below commit message on next
> version. However, currently 8173 thermal driver would not read TEMP_MSR3
> since thermal driver only use 3 sensors on each bank, this patch would
> not effect temperature.
> Only if thermal driver use 4 sensors on any thermal bank, would read
> third sensor two times, and lose fourth sensor of vale.
> Fixes: b7cf0053738c ("thermal: Add Mediatek thermal driver for mt2701.")
> 

Please send a new version with the tag in the commit message.

Re: [PATCH] thermal: mt8173: minor mtk_thermal.c cleanups

On Mon, Feb 13, 2017 at 05:01:58PM +0800, Dawei Chien wrote:
> Hi, Matthias,
> 
> On Thu, 2017-02-09 at 22:25 +0100, Matthias Brugger wrote:
> > 
> > On 02/08/2017 06:31 AM, Dawei Chien wrote:
> > > Thermal driver should read TEMP_MSR3 if thermal bank with 4 sensors.
> > > However, Currently thermal driver don't need read TEMP_MSR3 since
> > > thermal controller only use 3 sensors for each thermal bank.
> > >
> > > Signed-off-by: Dawei Chien 
> > > ---
> > 
> > Actually the commit message should state:
> > Fixes: b7cf0053738c ("thermal: Add Mediatek thermal driver for mt2701.")
> > 
> > ...and get backported to v4.9 and v4.10.
> > 
> > Reviewed-by: Matthias Brugger 
> > 
> > Regards,
> > Matthias
> 
> Thank you for your review. I would add below commit message on next
> version. However, currently 8173 thermal driver would not read TEMP_MSR3
> since thermal driver only use 3 sensors on each bank, this patch would
> not effect temperature.
> Only if thermal driver use 4 sensors on any thermal bank, would read
> third sensor two times, and lose fourth sensor of vale.
> Fixes: b7cf0053738c ("thermal: Add Mediatek thermal driver for mt2701.")
> 

Please send a new version with the tag in the commit message.

Re: [clear_page] 0ad07c8104 BUG: unable to handle kernel NULL pointer dereference at 0000000000000040

On Sun, Feb 19, 2017 at 01:10:47AM +0100, Borislav Petkov wrote:

Hey Fengguang,

On Sun, Feb 19, 2017 at 07:29:50AM +0800, Fengguang Wu wrote:

Good point! I noticed it too while sending out the report. It'll be
showed as this in future:

https://github.com/0day-ci/linux/commits/Borislav-Petkov/x86-Optimize-clear_page/20170210-053052

How about pointing to the patch directly?

https://github.com/0day-ci/linux/commit/0ad07c8104eb5c12dfcb86581c1cc657183496cc

Yes if we add it as a line below the branch URL, it could be a time saver.

Sorry the 2nd report was send out manually and I only checked the
emails in my _current_ mbox. Since the previous report email has been
archived, it slipped through the duplication check.

No worries - this was all a prelude to me hinting at the email-based
talking to the bot :-)

CC Xiaolong. It's possible to automate the test-of-fixup-patches.
Firstly find out the original email report by the Message-ID being
replied to. Then fetch all the information required for deciding where
the patch should be applied to, parameters to auto-testing the patch.

Sounds like a plan.

It would probably even be easier for the bot if the reply-mail contained
specially-formatted hints like:

TEST-WITH-BELOW-PATCH: ...

or so.

Since it's hard to teach ALL people about the rule, it'd be best if we
can work w/o any rules -- unless you want to be accurate or to
customize test behaviors.

Since we already tested the original patch/commit (hence the report),
we should know where the fixup should be applied to. And it'd be
reasonably easy to tell whether the fix is incremental or a
replacement -- just try git-am onto the original commit first, if
failed, continue to try the parent commit. For old bugs the fix could
be against linus/master or linux-next/master, which could be tried too.

Btw, another nice aspect of this talking back to the bot is that before
I, as a recipient of the bug report, go and try to prepare a guest or
find a machine to reproduce properly, I can send a quick diff to the bot
in the meantime and say, "try this on the guest. I have a hunch it might
fix it."

Yes, that'd be most convenient. In general the email interface could
be something like this:

# "key: value" fields; if you Re: to an earlier bug report, they can be
auto retrieved
compiler: gcc-6 # optional
base-commit: v4.10-rc8 # the robot knows kernel commits from hundreds of
public git trees
---
the patch
---
attach kconfig files

Yeah we have a TODO to do email based on-demand service, which looks
close to your proposal.

Cool. Ping me if you need testers.

Thanks!

Thanks,
Fengguang

Re: [clear_page] 0ad07c8104 BUG: unable to handle kernel NULL pointer dereference at 0000000000000040

On Sun, Feb 19, 2017 at 01:10:47AM +0100, Borislav Petkov wrote:

Hey Fengguang,

On Sun, Feb 19, 2017 at 07:29:50AM +0800, Fengguang Wu wrote:

Good point! I noticed it too while sending out the report. It'll be
showed as this in future:

https://github.com/0day-ci/linux/commits/Borislav-Petkov/x86-Optimize-clear_page/20170210-053052

How about pointing to the patch directly?

https://github.com/0day-ci/linux/commit/0ad07c8104eb5c12dfcb86581c1cc657183496cc

Yes if we add it as a line below the branch URL, it could be a time saver.

Sorry the 2nd report was send out manually and I only checked the
emails in my _current_ mbox. Since the previous report email has been
archived, it slipped through the duplication check.

No worries - this was all a prelude to me hinting at the email-based
talking to the bot :-)

Sounds like a plan.

It would probably even be easier for the bot if the reply-mail contained
specially-formatted hints like:

TEST-WITH-BELOW-PATCH: ...

or so.

Since it's hard to teach ALL people about the rule, it'd be best if we
can work w/o any rules -- unless you want to be accurate or to
customize test behaviors.

Yes, that'd be most convenient. In general the email interface could
be something like this:

Yeah we have a TODO to do email based on-demand service, which looks
close to your proposal.

Cool. Ping me if you need testers.

Thanks!

Thanks,
Fengguang

Re: [PATCH] ARM: dts: exynos: Use thermal fuse value for thermal zone 0 on Exynos5420

On Sat, Feb 11, 2017 at 10:14:56PM +0200, Krzysztof Kozlowski wrote:
> In Odroid XU3 Lite board, the temperature levels reported for thermal
> zone 0 were weird. In warm room:
>   /sys/class/thermal/thermal_zone0/temp:32000
>   /sys/class/thermal/thermal_zone1/temp:51000
>   /sys/class/thermal/thermal_zone2/temp:55000
>   /sys/class/thermal/thermal_zone3/temp:54000
>   /sys/class/thermal/thermal_zone4/temp:51000
> 
> Sometimes after booting the value was even equal to ambient temperature
> which is highly unlikely to be a real temperature of sensor in SoC.
> 
> The thermal sensor's calibration (trimming) is based on fused values.
> In case of the board above, the fused values are: 35, 52, 43, 58 and 43
> (corresponding to each TMU device).  However driver defined a minimum value
> for fused data as 40 and for smaller values it was using a hard-coded 55
> instead.  This lead to mapping data from sensor to wrong temperatures
> for thermal zone 0.
> 
> Various vendor 3.10 trees (Hardkernel's based on Samsung LSI, Artik 10)
> do not impose any limits on fused values.  Since we do not have any
> knowledge about these limits, use 0 as a minimum accepted fused value.
> This should essentially allow accepting any reasonable fused value thus
> behaving like vendor driver.
> 
> The exynos5420-tmu-sensor-conf.dtsi is copied directly from existing
> exynso4412 with one change - the samsung,tmu_min_efuse_value.
> 
> Signed-off-by: Krzysztof Kozlowski 

Acked-by: Eduardo Valentin 

> 
> ---
> 
> Testing on other Exynos542x boards is much appreciated. Especially I
> wonder what efuse values are there.
> ---
>  arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi | 25 
> +++
>  arch/arm/boot/dts/exynos5420.dtsi | 10 -
>  2 files changed, 30 insertions(+), 5 deletions(-)
>  create mode 100644 arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi
> 
> diff --git a/arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi 
> b/arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi
> new file mode 100644
> index ..c8771c660550
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi
> @@ -0,0 +1,25 @@
> +/*
> + * Device tree sources for Exynos5420 TMU sensor configuration
> + *
> + * Copyright (c) 2014 Lukasz Majewski 
> + * Copyright (c) 2017 Krzysztof Kozlowski 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#include 
> +
> +#thermal-sensor-cells = <0>;
> +samsung,tmu_gain = <8>;
> +samsung,tmu_reference_voltage = <16>;
> +samsung,tmu_noise_cancel_mode = <4>;
> +samsung,tmu_efuse_value = <55>;
> +samsung,tmu_min_efuse_value = <0>;
> +samsung,tmu_max_efuse_value = <100>;
> +samsung,tmu_first_point_trim = <25>;
> +samsung,tmu_second_point_trim = <85>;
> +samsung,tmu_default_temp_offset = <50>;
> +samsung,tmu_cal_type = ;
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
> b/arch/arm/boot/dts/exynos5420.dtsi
> index 7dc9dc82afd8..83b3899d228d 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -699,7 +699,7 @@
>   interrupts = <0 65 IRQ_TYPE_LEVEL_HIGH>;
>   clocks = < CLK_TMU>;
>   clock-names = "tmu_apbif";
> - #include "exynos4412-tmu-sensor-conf.dtsi"
> + #include "exynos5420-tmu-sensor-conf.dtsi"
>   };
>  
>   tmu_cpu1: tmu@10064000 {
> @@ -708,7 +708,7 @@
>   interrupts = <0 183 IRQ_TYPE_LEVEL_HIGH>;
>   clocks = < CLK_TMU>;
>   clock-names = "tmu_apbif";
> - #include "exynos4412-tmu-sensor-conf.dtsi"
> + #include "exynos5420-tmu-sensor-conf.dtsi"
>   };
>  
>   tmu_cpu2: tmu@10068000 {
> @@ -717,7 +717,7 @@
>   interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
>   clocks = < CLK_TMU>, < CLK_TMU>;
>   clock-names = "tmu_apbif", "tmu_triminfo_apbif";
> - #include "exynos4412-tmu-sensor-conf.dtsi"
> + #include "exynos5420-tmu-sensor-conf.dtsi"
>   };
>  
>   tmu_cpu3: tmu@1006c000 {
> @@ -726,7 +726,7 @@
>   interrupts = <0 185 IRQ_TYPE_LEVEL_HIGH>;
>   clocks = < CLK_TMU>, < CLK_TMU_GPU>;
>   clock-names = "tmu_apbif", "tmu_triminfo_apbif";
> - #include "exynos4412-tmu-sensor-conf.dtsi"
> + #include "exynos5420-tmu-sensor-conf.dtsi"
>   };
>  
>   tmu_gpu: tmu@100a {
> @@ -735,7 +735,7 @@
>   interrupts = <0 215 IRQ_TYPE_LEVEL_HIGH>;
>

Re: [PATCH] ARM: dts: exynos: Use thermal fuse value for thermal zone 0 on Exynos5420

On Sat, Feb 11, 2017 at 10:14:56PM +0200, Krzysztof Kozlowski wrote:
> In Odroid XU3 Lite board, the temperature levels reported for thermal
> zone 0 were weird. In warm room:
>   /sys/class/thermal/thermal_zone0/temp:32000
>   /sys/class/thermal/thermal_zone1/temp:51000
>   /sys/class/thermal/thermal_zone2/temp:55000
>   /sys/class/thermal/thermal_zone3/temp:54000
>   /sys/class/thermal/thermal_zone4/temp:51000
> 
> Sometimes after booting the value was even equal to ambient temperature
> which is highly unlikely to be a real temperature of sensor in SoC.
> 
> The thermal sensor's calibration (trimming) is based on fused values.
> In case of the board above, the fused values are: 35, 52, 43, 58 and 43
> (corresponding to each TMU device).  However driver defined a minimum value
> for fused data as 40 and for smaller values it was using a hard-coded 55
> instead.  This lead to mapping data from sensor to wrong temperatures
> for thermal zone 0.
> 
> Various vendor 3.10 trees (Hardkernel's based on Samsung LSI, Artik 10)
> do not impose any limits on fused values.  Since we do not have any
> knowledge about these limits, use 0 as a minimum accepted fused value.
> This should essentially allow accepting any reasonable fused value thus
> behaving like vendor driver.
> 
> The exynos5420-tmu-sensor-conf.dtsi is copied directly from existing
> exynso4412 with one change - the samsung,tmu_min_efuse_value.
> 
> Signed-off-by: Krzysztof Kozlowski 

Acked-by: Eduardo Valentin 

> 
> ---
> 
> Testing on other Exynos542x boards is much appreciated. Especially I
> wonder what efuse values are there.
> ---
>  arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi | 25 
> +++
>  arch/arm/boot/dts/exynos5420.dtsi | 10 -
>  2 files changed, 30 insertions(+), 5 deletions(-)
>  create mode 100644 arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi
> 
> diff --git a/arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi 
> b/arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi
> new file mode 100644
> index ..c8771c660550
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi
> @@ -0,0 +1,25 @@
> +/*
> + * Device tree sources for Exynos5420 TMU sensor configuration
> + *
> + * Copyright (c) 2014 Lukasz Majewski 
> + * Copyright (c) 2017 Krzysztof Kozlowski 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#include 
> +
> +#thermal-sensor-cells = <0>;
> +samsung,tmu_gain = <8>;
> +samsung,tmu_reference_voltage = <16>;
> +samsung,tmu_noise_cancel_mode = <4>;
> +samsung,tmu_efuse_value = <55>;
> +samsung,tmu_min_efuse_value = <0>;
> +samsung,tmu_max_efuse_value = <100>;
> +samsung,tmu_first_point_trim = <25>;
> +samsung,tmu_second_point_trim = <85>;
> +samsung,tmu_default_temp_offset = <50>;
> +samsung,tmu_cal_type = ;
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
> b/arch/arm/boot/dts/exynos5420.dtsi
> index 7dc9dc82afd8..83b3899d228d 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -699,7 +699,7 @@
>   interrupts = <0 65 IRQ_TYPE_LEVEL_HIGH>;
>   clocks = < CLK_TMU>;
>   clock-names = "tmu_apbif";
> - #include "exynos4412-tmu-sensor-conf.dtsi"
> + #include "exynos5420-tmu-sensor-conf.dtsi"
>   };
>  
>   tmu_cpu1: tmu@10064000 {
> @@ -708,7 +708,7 @@
>   interrupts = <0 183 IRQ_TYPE_LEVEL_HIGH>;
>   clocks = < CLK_TMU>;
>   clock-names = "tmu_apbif";
> - #include "exynos4412-tmu-sensor-conf.dtsi"
> + #include "exynos5420-tmu-sensor-conf.dtsi"
>   };
>  
>   tmu_cpu2: tmu@10068000 {
> @@ -717,7 +717,7 @@
>   interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
>   clocks = < CLK_TMU>, < CLK_TMU>;
>   clock-names = "tmu_apbif", "tmu_triminfo_apbif";
> - #include "exynos4412-tmu-sensor-conf.dtsi"
> + #include "exynos5420-tmu-sensor-conf.dtsi"
>   };
>  
>   tmu_cpu3: tmu@1006c000 {
> @@ -726,7 +726,7 @@
>   interrupts = <0 185 IRQ_TYPE_LEVEL_HIGH>;
>   clocks = < CLK_TMU>, < CLK_TMU_GPU>;
>   clock-names = "tmu_apbif", "tmu_triminfo_apbif";
> - #include "exynos4412-tmu-sensor-conf.dtsi"
> + #include "exynos5420-tmu-sensor-conf.dtsi"
>   };
>  
>   tmu_gpu: tmu@100a {
> @@ -735,7 +735,7 @@
>   interrupts = <0 215 IRQ_TYPE_LEVEL_HIGH>;
>   clocks = < CLK_TMU_GPU>, < CLK_TMU>;
>   clock-names =

[PATCH] arch/x86/kernel/tsc.c : set X86_FEATURE_ART for TSC on CPUs like i7-4910MQ : bug #194609

2017-02-18 Thread Jason Vas Dias

I originally reported this issue on bugzilla.kernel.org : bug # 194609 :
https://bugzilla.kernel.org/show_bug.cgi?id=194609
, but it was not posted to the list .

My CPU reports 'model name' as
"Intel(R) Core(TM) i7-4910MQ CPU @ 2.90GHz" ,
has 4 physical & 8 hyperthreading cores with a frequency scalable from 80
to 390 (/sys/devices/system/cpu/cpu0/cpufreq/scaling_{min,max}_freq) , and
flags :
fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor
ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1
sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c
rdrand lahf_lm abm epb tpr_shadow vnmi flexpriority ept vpid fsgsbase
tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm xsaveopt dtherm
ida arat pln pts

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
$

CPUID:15H is available in user-space, returning the integers : ( 7,
832, 832 ) in EAX:EBX:ECX , yet boot_cpu_data.cpuid_level is 13 , so
in detect_art() in tsc.c,
Linux does not think ART is enabled, and does not set the synthesized CPUID +
((3*32)+10) bit, so a program looking at /dev/cpu/0/cpuid would not
see this bit set .
if an e1000 NIC card had been installed, PTP would not be available.
Also, if the MSR TSC_ADJUST has not yet been written, as it seems to be
nowhere else in Linux,  the code will always think X86_FEATURE_ART is 0
because the CPU will always get a fault reading the MSR since it has
never been written.

So the attached patch makes tsc.c set X86_FEATURE_ART correctly in tsc.c ,
and set the TSC_ADJUST to 0 if the rdmsr gets an error .
Please consider applying it to a future linux version.

It would be nice for user-space programs that want to use the TSC with
rdtsc / rdtscp instructions, such as the demo program attached to the
bug report,
could have confidence that Linux is actually generating the results of
clock_gettime(CLOCK_MONOTONIC_RAW, )
in a predictable way from the TSC by looking at the
 /dev/cpu/0/cpuid[bit(((3*32)+10)] value before enabling user-space
use of TSC values, so that they can correlate TSC values with linux
clock_gettime() values.

The patch applies to linux kernels v4.8 & v4.9.10 GIT tags  and the
kernels build
and run & the demo program produces results like :
 $ ./ttsc1
has tsc: 1 constant: 1
832 / 7 = 118 : 832 - 9.888914286E+04hz : OK:1
Hooray! TSC is enabled with KHz: 2893300
ts2 - ts1: 261 ts3 - ts2: 211 ns1: 0.00146 ns2: 0.01629
ts3 - ts2: 27 ns1: 0.00168
ts3 - ts2: 20 ns1: 0.00147
ts3 - ts2: 14 ns1: 0.00152
ts3 - ts2: 15 ns1: 0.00151
ts3 - ts2: 15 ns1: 0.00153
ts3 - ts2: 15 ns1: 0.00150
ts3 - ts2: 20 ns1: 0.00148
ts3 - ts2: 19 ns1: 0.00164
ts3 - ts2: 19 ns1: 0.00164
ts3 - ts2: 19 ns1: 0.00160
t1 - t0: 52901 - ns2: 0.53951

The value 'ts3 - ts2' is the number of nanoseconds measured by
successive calls to
'rdtscp'; the 'ns1' value is the number of nanoseconds (shown as
decimal seconds)
measured by
  clock_gettime(CLOCK_MONOTONIC_RAW, ) -
  clock_gettime(CLOCK_MONOTONIC_RAW, )
when casting each {ts.tv_sec, ts.tv_nsec} to a 128 bit long long integer .
It shows a user-space program can read the TSC with a latency of @20ns
but can only measure times >= @ 140ns using Linux clock_gettime()  on this CPU.


x86_kernel_tsc-bz194609.patch
Description: Binary data

Re: [PATCH 3/6] perf report: Add -q/--quiet option

2017-02-18 Thread Namhyung Kim

Hi Jiri,

On Fri, Feb 17, 2017 at 12:09:35PM +0100, Jiri Olsa wrote:
> On Fri, Feb 17, 2017 at 05:17:39PM +0900, Namhyung Kim wrote:
> > The -q/--quiet option is to suppress any message.  Sometimes users just
> > want to see the numbers and it can be used for that case.
> 
> could you put in some example of the new output?

Sure.


>From bb28410a27be6d6fb15ec4498094301693115f1d Mon Sep 17 00:00:00 2001
From: Namhyung Kim 
Date: Fri, 17 Feb 2017 16:38:28 +0900
Subject: [PATCH] perf report: Add -q/--quiet option

The -q/--quiet option is to suppress any message.  Sometimes users just
want to see the numbers and it can be used for that case.

Before:

  $ perf report | head -15
  Failed to open /lib/modules/3.19.3-3-ARCH/kernel/fs/ext4/ext4.ko.gz, 
continuing without symbols
  Failed to open /lib/modules/3.19.3-3-ARCH/kernel/fs/jbd2/jbd2.ko.gz, 
continuing without symbols
  Failed to open /tmp/perf-14507.map, continuing without symbols
  ...
  # To display the perf.data header info, please use --header/--header-only 
options.
  #
  #
  # Total Lost Samples: 0
  #
  # Samples: 39K of event 'cycles'
  # Event count (approx.): 30444796573
  #
  # Overhead  Command  Shared ObjectSymbol
  #   ...  ...  .
  #
   9.28%  swapper  [kernel.vmlinux] [k] intel_idle
   5.64%  swapper  [kernel.vmlinux] [k] native_write_msr_safe
   1.93%  swapper  [kernel.vmlinux] [k] __switch_to
   1.89%  swapper  [kernel.vmlinux] [k] menu_select
   1.75%  sched-pipe   [kernel.vmlinux] [k] __switch_to

After:

  $ perf report -q | head
   9.28%  swapper  [kernel.vmlinux] [k] intel_idle
   5.64%  swapper  [kernel.vmlinux] [k] native_write_msr_safe
   1.93%  swapper  [kernel.vmlinux] [k] __switch_to
   1.89%  swapper  [kernel.vmlinux] [k] menu_select
   1.75%  sched-pipe   [kernel.vmlinux] [k] __switch_to
   1.67%  swapper  [kernel.vmlinux] [k] cpu_startup_entry
   1.48%  sched-pipe   [kernel.vmlinux] [k] enqueue_entity
   1.46%  swapper  [kernel.vmlinux] [k] __schedule
   1.36%  swapper  [kernel.vmlinux] [k] native_read_tsc
   1.34%  sched-pipe   [kernel.vmlinux] [k] __schedule

Signed-off-by: Namhyung Kim 
---
 tools/perf/Documentation/perf-report.txt |  4 
 tools/perf/builtin-report.c  | 21 -
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/tools/perf/Documentation/perf-report.txt 
b/tools/perf/Documentation/perf-report.txt
index f2914f03ae7b..c04cc0647c16 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -25,6 +25,10 @@ OPTIONS
 --verbose::
 Be more verbose. (show symbol address, etc)
 
+-q::
+--quiet::
+   Do not show any message.  (Suppress -v)
+
 -n::
 --show-nr-samples::
Show the number of samples for each symbol
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index dbd7fa028861..0a88670e56f3 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -320,6 +320,9 @@ static size_t hists__fprintf_nr_sample_events(struct hists 
*hists, struct report
size_t size = sizeof(buf);
int socked_id = hists->socket_filter;
 
+   if (quiet)
+   return 0;
+
if (symbol_conf.filter_relative) {
nr_samples = hists->stats.nr_non_filtered_samples;
nr_events = hists->stats.total_non_filtered_period;
@@ -372,7 +375,11 @@ static int perf_evlist__tty_browse_hists(struct 
perf_evlist *evlist,
 {
struct perf_evsel *pos;
 
-   fprintf(stdout, "#\n# Total Lost Samples: %" PRIu64 "\n#\n", 
evlist->stats.total_lost_samples);
+   if (!quiet) {
+   fprintf(stdout, "#\n# Total Lost Samples: %" PRIu64 "\n#\n",
+   evlist->stats.total_lost_samples);
+   }
+
evlist__for_each_entry(evlist, pos) {
struct hists *hists = evsel__hists(pos);
const char *evname = perf_evsel__name(pos);
@@ -382,7 +389,7 @@ static int perf_evlist__tty_browse_hists(struct perf_evlist 
*evlist,
continue;
 
hists__fprintf_nr_sample_events(hists, rep, evname, stdout);
-   hists__fprintf(hists, true, 0, 0, rep->min_percent, stdout,
+   hists__fprintf(hists, !quiet, 0, 0, rep->min_percent, stdout,
   symbol_conf.use_callchain);
fprintf(stdout, "\n\n");
}
@@ -716,6 +723,7 @@ int cmd_report(int argc, const char **argv, const char 
*prefix __maybe_unused)
"input file name"),
OPT_INCR('v', "verbose", ,
"be more verbose (show symbol address, etc)"),
+   OPT_BOOLEAN('q', "quiet", , "Do not show any message"),
OPT_BOOLEAN('D',

[PATCH] arch/x86/kernel/tsc.c : set X86_FEATURE_ART for TSC on CPUs like i7-4910MQ : bug #194609

2017-02-18 Thread Jason Vas Dias

I originally reported this issue on bugzilla.kernel.org : bug # 194609 :
https://bugzilla.kernel.org/show_bug.cgi?id=194609
, but it was not posted to the list .

My CPU reports 'model name' as
"Intel(R) Core(TM) i7-4910MQ CPU @ 2.90GHz" ,
has 4 physical & 8 hyperthreading cores with a frequency scalable from 80
to 390 (/sys/devices/system/cpu/cpu0/cpufreq/scaling_{min,max}_freq) , and
flags :
fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor
ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1
sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c
rdrand lahf_lm abm epb tpr_shadow vnmi flexpriority ept vpid fsgsbase
tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm xsaveopt dtherm
ida arat pln pts

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
$

CPUID:15H is available in user-space, returning the integers : ( 7,
832, 832 ) in EAX:EBX:ECX , yet boot_cpu_data.cpuid_level is 13 , so
in detect_art() in tsc.c,
Linux does not think ART is enabled, and does not set the synthesized CPUID +
((3*32)+10) bit, so a program looking at /dev/cpu/0/cpuid would not
see this bit set .
if an e1000 NIC card had been installed, PTP would not be available.
Also, if the MSR TSC_ADJUST has not yet been written, as it seems to be
nowhere else in Linux,  the code will always think X86_FEATURE_ART is 0
because the CPU will always get a fault reading the MSR since it has
never been written.

So the attached patch makes tsc.c set X86_FEATURE_ART correctly in tsc.c ,
and set the TSC_ADJUST to 0 if the rdmsr gets an error .
Please consider applying it to a future linux version.

It would be nice for user-space programs that want to use the TSC with
rdtsc / rdtscp instructions, such as the demo program attached to the
bug report,
could have confidence that Linux is actually generating the results of
clock_gettime(CLOCK_MONOTONIC_RAW, )
in a predictable way from the TSC by looking at the
 /dev/cpu/0/cpuid[bit(((3*32)+10)] value before enabling user-space
use of TSC values, so that they can correlate TSC values with linux
clock_gettime() values.

The patch applies to linux kernels v4.8 & v4.9.10 GIT tags  and the
kernels build
and run & the demo program produces results like :
 $ ./ttsc1
has tsc: 1 constant: 1
832 / 7 = 118 : 832 - 9.888914286E+04hz : OK:1
Hooray! TSC is enabled with KHz: 2893300
ts2 - ts1: 261 ts3 - ts2: 211 ns1: 0.00146 ns2: 0.01629
ts3 - ts2: 27 ns1: 0.00168
ts3 - ts2: 20 ns1: 0.00147
ts3 - ts2: 14 ns1: 0.00152
ts3 - ts2: 15 ns1: 0.00151
ts3 - ts2: 15 ns1: 0.00153
ts3 - ts2: 15 ns1: 0.00150
ts3 - ts2: 20 ns1: 0.00148
ts3 - ts2: 19 ns1: 0.00164
ts3 - ts2: 19 ns1: 0.00164
ts3 - ts2: 19 ns1: 0.00160
t1 - t0: 52901 - ns2: 0.53951

The value 'ts3 - ts2' is the number of nanoseconds measured by
successive calls to
'rdtscp'; the 'ns1' value is the number of nanoseconds (shown as
decimal seconds)
measured by
  clock_gettime(CLOCK_MONOTONIC_RAW, ) -
  clock_gettime(CLOCK_MONOTONIC_RAW, )
when casting each {ts.tv_sec, ts.tv_nsec} to a 128 bit long long integer .
It shows a user-space program can read the TSC with a latency of @20ns
but can only measure times >= @ 140ns using Linux clock_gettime()  on this CPU.


x86_kernel_tsc-bz194609.patch
Description: Binary data

Re: [PATCH 3/6] perf report: Add -q/--quiet option

2017-02-18 Thread Namhyung Kim

Hi Jiri,

On Fri, Feb 17, 2017 at 12:09:35PM +0100, Jiri Olsa wrote:
> On Fri, Feb 17, 2017 at 05:17:39PM +0900, Namhyung Kim wrote:
> > The -q/--quiet option is to suppress any message.  Sometimes users just
> > want to see the numbers and it can be used for that case.
> 
> could you put in some example of the new output?

Sure.


>From bb28410a27be6d6fb15ec4498094301693115f1d Mon Sep 17 00:00:00 2001
From: Namhyung Kim 
Date: Fri, 17 Feb 2017 16:38:28 +0900
Subject: [PATCH] perf report: Add -q/--quiet option

The -q/--quiet option is to suppress any message.  Sometimes users just
want to see the numbers and it can be used for that case.

Before:

  $ perf report | head -15
  Failed to open /lib/modules/3.19.3-3-ARCH/kernel/fs/ext4/ext4.ko.gz, 
continuing without symbols
  Failed to open /lib/modules/3.19.3-3-ARCH/kernel/fs/jbd2/jbd2.ko.gz, 
continuing without symbols
  Failed to open /tmp/perf-14507.map, continuing without symbols
  ...
  # To display the perf.data header info, please use --header/--header-only 
options.
  #
  #
  # Total Lost Samples: 0
  #
  # Samples: 39K of event 'cycles'
  # Event count (approx.): 30444796573
  #
  # Overhead  Command  Shared ObjectSymbol
  #   ...  ...  .
  #
   9.28%  swapper  [kernel.vmlinux] [k] intel_idle
   5.64%  swapper  [kernel.vmlinux] [k] native_write_msr_safe
   1.93%  swapper  [kernel.vmlinux] [k] __switch_to
   1.89%  swapper  [kernel.vmlinux] [k] menu_select
   1.75%  sched-pipe   [kernel.vmlinux] [k] __switch_to

After:

  $ perf report -q | head
   9.28%  swapper  [kernel.vmlinux] [k] intel_idle
   5.64%  swapper  [kernel.vmlinux] [k] native_write_msr_safe
   1.93%  swapper  [kernel.vmlinux] [k] __switch_to
   1.89%  swapper  [kernel.vmlinux] [k] menu_select
   1.75%  sched-pipe   [kernel.vmlinux] [k] __switch_to
   1.67%  swapper  [kernel.vmlinux] [k] cpu_startup_entry
   1.48%  sched-pipe   [kernel.vmlinux] [k] enqueue_entity
   1.46%  swapper  [kernel.vmlinux] [k] __schedule
   1.36%  swapper  [kernel.vmlinux] [k] native_read_tsc
   1.34%  sched-pipe   [kernel.vmlinux] [k] __schedule

Signed-off-by: Namhyung Kim 
---
 tools/perf/Documentation/perf-report.txt |  4 
 tools/perf/builtin-report.c  | 21 -
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/tools/perf/Documentation/perf-report.txt 
b/tools/perf/Documentation/perf-report.txt
index f2914f03ae7b..c04cc0647c16 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -25,6 +25,10 @@ OPTIONS
 --verbose::
 Be more verbose. (show symbol address, etc)
 
+-q::
+--quiet::
+   Do not show any message.  (Suppress -v)
+
 -n::
 --show-nr-samples::
Show the number of samples for each symbol
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index dbd7fa028861..0a88670e56f3 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -320,6 +320,9 @@ static size_t hists__fprintf_nr_sample_events(struct hists 
*hists, struct report
size_t size = sizeof(buf);
int socked_id = hists->socket_filter;
 
+   if (quiet)
+   return 0;
+
if (symbol_conf.filter_relative) {
nr_samples = hists->stats.nr_non_filtered_samples;
nr_events = hists->stats.total_non_filtered_period;
@@ -372,7 +375,11 @@ static int perf_evlist__tty_browse_hists(struct 
perf_evlist *evlist,
 {
struct perf_evsel *pos;
 
-   fprintf(stdout, "#\n# Total Lost Samples: %" PRIu64 "\n#\n", 
evlist->stats.total_lost_samples);
+   if (!quiet) {
+   fprintf(stdout, "#\n# Total Lost Samples: %" PRIu64 "\n#\n",
+   evlist->stats.total_lost_samples);
+   }
+
evlist__for_each_entry(evlist, pos) {
struct hists *hists = evsel__hists(pos);
const char *evname = perf_evsel__name(pos);
@@ -382,7 +389,7 @@ static int perf_evlist__tty_browse_hists(struct perf_evlist 
*evlist,
continue;
 
hists__fprintf_nr_sample_events(hists, rep, evname, stdout);
-   hists__fprintf(hists, true, 0, 0, rep->min_percent, stdout,
+   hists__fprintf(hists, !quiet, 0, 0, rep->min_percent, stdout,
   symbol_conf.use_callchain);
fprintf(stdout, "\n\n");
}
@@ -716,6 +723,7 @@ int cmd_report(int argc, const char **argv, const char 
*prefix __maybe_unused)
"input file name"),
OPT_INCR('v', "verbose", ,
"be more verbose (show symbol address, etc)"),
+   OPT_BOOLEAN('q', "quiet", , "Do not show any message"),
OPT_BOOLEAN('D', "dump-raw-trace", _trace,
"dump

Re: [clear_page] 0ad07c8104 BUG: unable to handle kernel NULL pointer dereference at 0000000000000040

2017-02-18 Thread Borislav Petkov

Hey Fengguang,

On Sun, Feb 19, 2017 at 07:29:50AM +0800, Fengguang Wu wrote:
> Good point! I noticed it too while sending out the report. It'll be
> showed as this in future:
> 
>
> https://github.com/0day-ci/linux/commits/Borislav-Petkov/x86-Optimize-clear_page/20170210-053052

How about pointing to the patch directly?

https://github.com/0day-ci/linux/commit/0ad07c8104eb5c12dfcb86581c1cc657183496cc

> Sorry the 2nd report was send out manually and I only checked the
> emails in my _current_ mbox. Since the previous report email has been
> archived, it slipped through the duplication check.

No worries - this was all a prelude to me hinting at the email-based
talking to the bot :-)

> CC Xiaolong. It's possible to automate the test-of-fixup-patches.
> Firstly find out the original email report by the Message-ID being
> replied to. Then fetch all the information required for deciding where
> the patch should be applied to, parameters to auto-testing the patch.

Sounds like a plan.

It would probably even be easier for the bot if the reply-mail contained
specially-formatted hints like:

TEST-WITH-BELOW-PATCH: ...

or so.

Btw, another nice aspect of this talking back to the bot is that before
I, as a recipient of the bug report, go and try to prepare a guest or
find a machine to reproduce properly, I can send a quick diff to the bot
in the meantime and say, "try this on the guest. I have a hunch it might
fix it."

> Yeah we have a TODO to do email based on-demand service, which looks
> close to your proposal.

Cool. Ping me if you need testers.

Thanks!

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--

Re: [clear_page] 0ad07c8104 BUG: unable to handle kernel NULL pointer dereference at 0000000000000040

2017-02-18 Thread Borislav Petkov

Hey Fengguang,

On Sun, Feb 19, 2017 at 07:29:50AM +0800, Fengguang Wu wrote:
> Good point! I noticed it too while sending out the report. It'll be
> showed as this in future:
> 
>
> https://github.com/0day-ci/linux/commits/Borislav-Petkov/x86-Optimize-clear_page/20170210-053052

How about pointing to the patch directly?

https://github.com/0day-ci/linux/commit/0ad07c8104eb5c12dfcb86581c1cc657183496cc

> Sorry the 2nd report was send out manually and I only checked the
> emails in my _current_ mbox. Since the previous report email has been
> archived, it slipped through the duplication check.

No worries - this was all a prelude to me hinting at the email-based
talking to the bot :-)

> CC Xiaolong. It's possible to automate the test-of-fixup-patches.
> Firstly find out the original email report by the Message-ID being
> replied to. Then fetch all the information required for deciding where
> the patch should be applied to, parameters to auto-testing the patch.

Sounds like a plan.

It would probably even be easier for the bot if the reply-mail contained
specially-formatted hints like:

TEST-WITH-BELOW-PATCH: ...

or so.

Btw, another nice aspect of this talking back to the bot is that before
I, as a recipient of the bug report, go and try to prepare a guest or
find a machine to reproduce properly, I can send a quick diff to the bot
in the meantime and say, "try this on the guest. I have a hunch it might
fix it."

> Yeah we have a TODO to do email based on-demand service, which looks
> close to your proposal.

Cool. Ping me if you need testers.

Thanks!

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--

Re: [PATCH] DTS: Linksys Board: Add default trigger for sata led

Hi,

Am 18.02.2017 um 15:12 schrieb Jason Cooper:
> On Fri, Feb 17, 2017 at 09:42:17PM +0100, Ansuel Smith wrote:
>> In others board we have the sata led set to funcion with the sata led 
>> trigger by default.
>> This patch makes the same for these board that have sata led but disabled by 
>> not associating it to any trigger
> 
> Please line wrap the commit message.

The subject could also use some love, like mentioning "ARM:" and
"armada" and dropping "Board". Compare git log --oneline.

Regards,
Andreas

>  Other than that,
> 
>>
>> Signed-off-by: Ansuel Smith 
> 
> Acked-by: Jason Cooper 
> 
> thx,
> 
> Jason.
> 
>> ---
>>  arch/arm/boot/dts/armada-385-linksys-caiman.dts | 1 +
>>  arch/arm/boot/dts/armada-385-linksys-cobra.dts  | 1 +
>>  arch/arm/boot/dts/armada-xp-linksys-mamba.dts   | 1 +
>>  3 files changed, 3 insertions(+)

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH] DTS: Linksys Board: Add default trigger for sata led

Hi,

Am 18.02.2017 um 15:12 schrieb Jason Cooper:
> On Fri, Feb 17, 2017 at 09:42:17PM +0100, Ansuel Smith wrote:
>> In others board we have the sata led set to funcion with the sata led 
>> trigger by default.
>> This patch makes the same for these board that have sata led but disabled by 
>> not associating it to any trigger
> 
> Please line wrap the commit message.

The subject could also use some love, like mentioning "ARM:" and
"armada" and dropping "Board". Compare git log --oneline.

Regards,
Andreas

>  Other than that,
> 
>>
>> Signed-off-by: Ansuel Smith 
> 
> Acked-by: Jason Cooper 
> 
> thx,
> 
> Jason.
> 
>> ---
>>  arch/arm/boot/dts/armada-385-linksys-caiman.dts | 1 +
>>  arch/arm/boot/dts/armada-385-linksys-cobra.dts  | 1 +
>>  arch/arm/boot/dts/armada-xp-linksys-mamba.dts   | 1 +
>>  3 files changed, 3 insertions(+)

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH v2 3/3] Make vmbus register arguments read-only (fwd)

2017-02-18 Thread Eddie Kovsky

On 02/18/17, Julia Lawall wrote:
> It looks like brace are missing on the if on lines 1057-1059.
> 
> julia
> 
> 
Well that is embarrassing. I should have caught that on my own test
build before submitting this. But I do think I've found the error in my
build script.

Sorry for all the noise.

Eddie

> 
> -- Forwarded message --
> Date: Sat, 18 Feb 2017 15:46:30 +0800
> From: kbuild test robot <fengguang...@intel.com>
> To: kbu...@01.org
> Cc: Julia Lawall <julia.law...@lip6.fr>
> Subject: Re: [PATCH v2 3/3] Make vmbus register arguments read-only
> 
> CC: kbuild-...@01.org
> In-Reply-To: <20170218055844.1457-4-...@edkovsky.org>
> 
> Hi Eddie,
> 
> [auto build test WARNING on linus/master]
> [also build test WARNING on v4.10-rc8 next-20170217]
> [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/Eddie-Kovsky/provide-check-for-ro_after_init-memory-sections/20170218-141040
> :: branch date: 2 hours ago
> :: commit date: 2 hours ago
> 
> >> drivers/hv/vmbus_drv.c:1058:2-45: code aligned with following code on line 
> >> 1059
>drivers/hv/vmbus_drv.c:1129:2-45: code aligned with following code on line 
> 1130
> 
> git remote add linux-review https://github.com/0day-ci/linux
> git remote update linux-review
> git checkout 1fed72d7adca008d13119f00c095e1e379f319a1
> vim +1058 drivers/hv/vmbus_drv.c
> 
> cf6a2eac drivers/hv/vmbus_drv.c K. Y. Srinivasan   2011-12-01  1052   
> ret = vmbus_exists();
> cf6a2eac drivers/hv/vmbus_drv.c K. Y. Srinivasan   2011-12-01  1053   
> if (ret < 0)
> cf6a2eac drivers/hv/vmbus_drv.c K. Y. Srinivasan   2011-12-01  1054   
> return ret;
> cf6a2eac drivers/hv/vmbus_drv.c K. Y. Srinivasan   2011-12-01  1055
> 1fed72d7 drivers/hv/vmbus_drv.c Eddie Kovsky   2017-02-17  1056   
> ret = kernel_ro_address(_driver);
> 1fed72d7 drivers/hv/vmbus_drv.c Eddie Kovsky   2017-02-17  1057   
> if (ret < 1)
> 1fed72d7 drivers/hv/vmbus_drv.c Eddie Kovsky   2017-02-17 @1058   
> pr_err("Module address is not read-only.");
> 1fed72d7 drivers/hv/vmbus_drv.c Eddie Kovsky   2017-02-17 @1059   
> return ret;
> 1fed72d7 drivers/hv/vmbus_drv.c Eddie Kovsky   2017-02-17  1060
> 768fa219 drivers/staging/hv/vmbus_drv.c Greg Kroah-Hartman 2011-08-25  1061   
> hv_driver->driver.name = hv_driver->name;
> 768fa219 drivers/staging/hv/vmbus_drv.c Greg Kroah-Hartman 2011-08-25  1062   
> hv_driver->driver.owner = owner;
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH v2 3/3] Make vmbus register arguments read-only (fwd)

2017-02-18 Thread Eddie Kovsky

On 02/18/17, Julia Lawall wrote:
> It looks like brace are missing on the if on lines 1057-1059.
> 
> julia
> 
> 
Well that is embarrassing. I should have caught that on my own test
build before submitting this. But I do think I've found the error in my
build script.

Sorry for all the noise.

Eddie

> 
> -- Forwarded message --
> Date: Sat, 18 Feb 2017 15:46:30 +0800
> From: kbuild test robot 
> To: kbu...@01.org
> Cc: Julia Lawall 
> Subject: Re: [PATCH v2 3/3] Make vmbus register arguments read-only
> 
> CC: kbuild-...@01.org
> In-Reply-To: <20170218055844.1457-4-...@edkovsky.org>
> 
> Hi Eddie,
> 
> [auto build test WARNING on linus/master]
> [also build test WARNING on v4.10-rc8 next-20170217]
> [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/Eddie-Kovsky/provide-check-for-ro_after_init-memory-sections/20170218-141040
> :: branch date: 2 hours ago
> :: commit date: 2 hours ago
> 
> >> drivers/hv/vmbus_drv.c:1058:2-45: code aligned with following code on line 
> >> 1059
>drivers/hv/vmbus_drv.c:1129:2-45: code aligned with following code on line 
> 1130
> 
> git remote add linux-review https://github.com/0day-ci/linux
> git remote update linux-review
> git checkout 1fed72d7adca008d13119f00c095e1e379f319a1
> vim +1058 drivers/hv/vmbus_drv.c
> 
> cf6a2eac drivers/hv/vmbus_drv.c K. Y. Srinivasan   2011-12-01  1052   
> ret = vmbus_exists();
> cf6a2eac drivers/hv/vmbus_drv.c K. Y. Srinivasan   2011-12-01  1053   
> if (ret < 0)
> cf6a2eac drivers/hv/vmbus_drv.c K. Y. Srinivasan   2011-12-01  1054   
> return ret;
> cf6a2eac drivers/hv/vmbus_drv.c K. Y. Srinivasan   2011-12-01  1055
> 1fed72d7 drivers/hv/vmbus_drv.c Eddie Kovsky   2017-02-17  1056   
> ret = kernel_ro_address(_driver);
> 1fed72d7 drivers/hv/vmbus_drv.c Eddie Kovsky   2017-02-17  1057   
> if (ret < 1)
> 1fed72d7 drivers/hv/vmbus_drv.c Eddie Kovsky   2017-02-17 @1058   
> pr_err("Module address is not read-only.");
> 1fed72d7 drivers/hv/vmbus_drv.c Eddie Kovsky   2017-02-17 @1059   
> return ret;
> 1fed72d7 drivers/hv/vmbus_drv.c Eddie Kovsky   2017-02-17  1060
> 768fa219 drivers/staging/hv/vmbus_drv.c Greg Kroah-Hartman 2011-08-25  1061   
> hv_driver->driver.name = hv_driver->name;
> 768fa219 drivers/staging/hv/vmbus_drv.c Greg Kroah-Hartman 2011-08-25  1062   
> hv_driver->driver.owner = owner;
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

[PATCH] gcc-plugins: fix spelling mistake: "unkown" -> "unknown"

From: Colin Ian King 

trivial fix to spelling mistake in error message

Signed-off-by: Colin Ian King 
---
 scripts/gcc-plugins/initify_plugin.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/gcc-plugins/initify_plugin.c 
b/scripts/gcc-plugins/initify_plugin.c
index 56ed878..2ed998a 100644
--- a/scripts/gcc-plugins/initify_plugin.c
+++ b/scripts/gcc-plugins/initify_plugin.c
@@ -1846,7 +1846,7 @@ __visible int plugin_init(struct plugin_name_args 
*plugin_info, struct plugin_gc
continue;
}
 
-   error(G_("unkown option '-fplugin-arg-%s-%s'"), plugin_name, 
argv[i].key);
+   error(G_("unknown option '-fplugin-arg-%s-%s'"), plugin_name, 
argv[i].key);
}
 
register_callback(plugin_name, PLUGIN_INFO, NULL, _plugin_info);
-- 
2.10.2

[PATCH] gcc-plugins: fix spelling mistake: "unkown" -> "unknown"

From: Colin Ian King 

trivial fix to spelling mistake in error message

Signed-off-by: Colin Ian King 
---
 scripts/gcc-plugins/initify_plugin.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/gcc-plugins/initify_plugin.c 
b/scripts/gcc-plugins/initify_plugin.c
index 56ed878..2ed998a 100644
--- a/scripts/gcc-plugins/initify_plugin.c
+++ b/scripts/gcc-plugins/initify_plugin.c
@@ -1846,7 +1846,7 @@ __visible int plugin_init(struct plugin_name_args 
*plugin_info, struct plugin_gc
continue;
}
 
-   error(G_("unkown option '-fplugin-arg-%s-%s'"), plugin_name, 
argv[i].key);
+   error(G_("unknown option '-fplugin-arg-%s-%s'"), plugin_name, 
argv[i].key);
}
 
register_callback(plugin_name, PLUGIN_INFO, NULL, _plugin_info);
-- 
2.10.2

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

2017-02-18 Thread Sebastian Reichel

Hi,

On Sat, Feb 18, 2017 at 12:33:34PM +0100, H. Nikolaus Schaller wrote:
> Hi Sebastian,
> 
> > Am 18.02.2017 um 04:22 schrieb Sebastian Reichel :
> > 
> > Hi,
> > 
> > On Fri, Feb 17, 2017 at 12:40:41PM -0800, Dmitry Torokhov wrote:
> >>> AFAIK there is no mainline board using the DT except ours (and the 
> >>> upcoming
> >>> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove 
> >>> this
> >>> compatibility property. We don't need it for our devices.
> > 
> > $ cd linux.git/arch
> > $ git grep -l tsc2004
> > arm/boot/dts/imx6qdl-nit6xlite.dtsi
> > arm/boot/dts/imx7d-nitrogen7.dts
> > arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
> > arm/boot/dts/omap4-var-som-om44.dtsi
> > $ git grep -l tsc2005
> > arm/boot/dts/omap3-n900.dts
> 
> Those are not relevant since tsc2004/5 and tsc2007 are independent drivers 
> and don't
> share code.

Yes, I'm aware.

> Hence the N900 is not influenced by this patch series.
> If it has a similar issue, it should be fixed of course.

Right. I added them to see every board affect by the patch suggested
by me in my last paragraph.

> > $ git grep -l tsc2007
> > arm/boot/dts/imx28-tx28.dts
> > arm/boot/dts/imx35-eukrea-cpuimx35.dtsi
> > arm/boot/dts/imx51-eukrea-cpuimx51.dtsi
> > arm/boot/dts/imx53-tx53-x03x.dts
> > arm/boot/dts/imx6qdl-tx6.dtsi
> > arm/boot/dts/imx6ul-tx6ul.dtsi
> > arm/boot/dts/omap3-gta04.dtsi
> > sh/boards/mach-ecovec24/setup.c
> 
> Sorry, I was a little imprecise here, because I looked for the min/max 
> properties.
> Of course, the imx devices use the tsc2007 as well.
>
> Maybe we should edit all these DTS and set the "ti,report-resistance" property
> by default. Then, no user should notice a difference.

I suggest to create a patch without the report-reistance stuff and
add it early after the merge window and see what happens. If no
users notices anything the change is not an ABI break from kernel's
PoV.

> Is any user/maintainer of these devices following this discussion and can 
> comment?
>
> > 
> >> You seem to be treating DT data as something very fluid, which is wrong.
> >> You need to treat it as a firmware, unlikely to change once device is
> >> shipped. Unlike legacy platform data, the fact that DTS files are not
> >> present in mainline does not mean that we can ignore such users and
> >> change behavior at will.
> >> 
> >> That said, if driver behavior is out of line from the subsystem
> >> expectations, we need to fix it.
> >> 
> >> 
> >>> That the function name is wrong is a second issue and this double 
> >>> negation might
> >>> confuse a litte.
> >>> 
> >>> Please test on a real device if the patched driver reports pressure now 
> >>> (unless
> >>> ti,report-resistance is specified).
> >> 
> >> I unfortunately can not test this driver as I do not have the hardware.
> >> So all my observations are from code and data sheets.
> >> 
> >> That said, what is the values emitted as ABS_PRESSURE when finger is not
> >> touching the device, barely touching the device, or pressing firmly?
> >> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
> >> confusion as to what is being reported.
> > 
> > As far as I can see all calculate Rtouch and ADS7846 reports
> > (Rmax - Rtouch), which looks sensible.
> 
> I don't see where this subtraction from Rmax takes place for the tsc2007:
> 
> http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc2007.c#L131

sorry if I wrote this ambiguous, let me split my sentence

1. tsc200x & ads7846 calculate Rtouch
2. ads7846 reports Rmax - Rtouch
(3. tsc200x does not, it reports Rtouch instead)
4. ads7846 behaviour looks sensible to me

> >> I am adding a few more folks to the CC so we can try and soft this out.
> >> Sebastian, Pali, Pavel, any input here?
> > 
> > I think tsc200x works, since usually userspace is Xorg and I think
> > it only cares for x/y coordinates + boolean pressure. Since
> > no-pressure is correctly reported as 0, everything works as
> > expected.
> 
> No pressure is usually treated as a special case in these drivers,
> so reduction to "boolean" in user-space works well by accident and
> might still hide a bug.

That's what I assumed.

Btw. how did you notice that tsc2007 sends "inverted" pressure values?
Just in evtest or in some non-development application? (Just asking because
the behavour obviously changes at least for that usecase)

> > I currently don't have X running on my N900 due some
> > omapdrm bug, so I can't test this, sorry.
> 
> I usually look with evtest if ABS_PRESSURE is monotonic.

That would not have helped to check if X handles the touchscreen in
a boolean way. I can provide some N900 evtest data, though (tomorrow,
I don't have my dev N900 with me at the moment).

> > I suggest to put the resistance vs pressure thing in its own patch,
> > that also fixes tsc200x-core and merge it to linux-next after the
> > merge window.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

2017-02-18 Thread Sebastian Reichel

Hi,

On Sat, Feb 18, 2017 at 12:33:34PM +0100, H. Nikolaus Schaller wrote:
> Hi Sebastian,
> 
> > Am 18.02.2017 um 04:22 schrieb Sebastian Reichel :
> > 
> > Hi,
> > 
> > On Fri, Feb 17, 2017 at 12:40:41PM -0800, Dmitry Torokhov wrote:
> >>> AFAIK there is no mainline board using the DT except ours (and the 
> >>> upcoming
> >>> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove 
> >>> this
> >>> compatibility property. We don't need it for our devices.
> > 
> > $ cd linux.git/arch
> > $ git grep -l tsc2004
> > arm/boot/dts/imx6qdl-nit6xlite.dtsi
> > arm/boot/dts/imx7d-nitrogen7.dts
> > arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
> > arm/boot/dts/omap4-var-som-om44.dtsi
> > $ git grep -l tsc2005
> > arm/boot/dts/omap3-n900.dts
> 
> Those are not relevant since tsc2004/5 and tsc2007 are independent drivers 
> and don't
> share code.

Yes, I'm aware.

> Hence the N900 is not influenced by this patch series.
> If it has a similar issue, it should be fixed of course.

Right. I added them to see every board affect by the patch suggested
by me in my last paragraph.

> > $ git grep -l tsc2007
> > arm/boot/dts/imx28-tx28.dts
> > arm/boot/dts/imx35-eukrea-cpuimx35.dtsi
> > arm/boot/dts/imx51-eukrea-cpuimx51.dtsi
> > arm/boot/dts/imx53-tx53-x03x.dts
> > arm/boot/dts/imx6qdl-tx6.dtsi
> > arm/boot/dts/imx6ul-tx6ul.dtsi
> > arm/boot/dts/omap3-gta04.dtsi
> > sh/boards/mach-ecovec24/setup.c
> 
> Sorry, I was a little imprecise here, because I looked for the min/max 
> properties.
> Of course, the imx devices use the tsc2007 as well.
>
> Maybe we should edit all these DTS and set the "ti,report-resistance" property
> by default. Then, no user should notice a difference.

I suggest to create a patch without the report-reistance stuff and
add it early after the merge window and see what happens. If no
users notices anything the change is not an ABI break from kernel's
PoV.

> Is any user/maintainer of these devices following this discussion and can 
> comment?
>
> > 
> >> You seem to be treating DT data as something very fluid, which is wrong.
> >> You need to treat it as a firmware, unlikely to change once device is
> >> shipped. Unlike legacy platform data, the fact that DTS files are not
> >> present in mainline does not mean that we can ignore such users and
> >> change behavior at will.
> >> 
> >> That said, if driver behavior is out of line from the subsystem
> >> expectations, we need to fix it.
> >> 
> >> 
> >>> That the function name is wrong is a second issue and this double 
> >>> negation might
> >>> confuse a litte.
> >>> 
> >>> Please test on a real device if the patched driver reports pressure now 
> >>> (unless
> >>> ti,report-resistance is specified).
> >> 
> >> I unfortunately can not test this driver as I do not have the hardware.
> >> So all my observations are from code and data sheets.
> >> 
> >> That said, what is the values emitted as ABS_PRESSURE when finger is not
> >> touching the device, barely touching the device, or pressing firmly?
> >> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
> >> confusion as to what is being reported.
> > 
> > As far as I can see all calculate Rtouch and ADS7846 reports
> > (Rmax - Rtouch), which looks sensible.
> 
> I don't see where this subtraction from Rmax takes place for the tsc2007:
> 
> http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc2007.c#L131

sorry if I wrote this ambiguous, let me split my sentence

1. tsc200x & ads7846 calculate Rtouch
2. ads7846 reports Rmax - Rtouch
(3. tsc200x does not, it reports Rtouch instead)
4. ads7846 behaviour looks sensible to me

> >> I am adding a few more folks to the CC so we can try and soft this out.
> >> Sebastian, Pali, Pavel, any input here?
> > 
> > I think tsc200x works, since usually userspace is Xorg and I think
> > it only cares for x/y coordinates + boolean pressure. Since
> > no-pressure is correctly reported as 0, everything works as
> > expected.
> 
> No pressure is usually treated as a special case in these drivers,
> so reduction to "boolean" in user-space works well by accident and
> might still hide a bug.

That's what I assumed.

Btw. how did you notice that tsc2007 sends "inverted" pressure values?
Just in evtest or in some non-development application? (Just asking because
the behavour obviously changes at least for that usecase)

> > I currently don't have X running on my N900 due some
> > omapdrm bug, so I can't test this, sorry.
> 
> I usually look with evtest if ABS_PRESSURE is monotonic.

That would not have helped to check if X handles the touchscreen in
a boolean way. I can provide some N900 evtest data, though (tomorrow,
I don't have my dev N900 with me at the moment).

> > I suggest to put the resistance vs pressure thing in its own patch,
> > that also fixes tsc200x-core and merge it to linux-next after the
> > merge window.

-- Sebastian


signature.asc
Description: PGP signature

[PATCH] fsl/fman: fix spelling mistake in variable name en_tsu_err_exeption

From: Colin Ian King 

trivial fix to spelling mistake, en_tsu_err_exeption should
be en_tsu_err_exception

Signed-off-by: Colin Ian King 
---
 drivers/net/ethernet/freescale/fman/fman_dtsec.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fman/fman_dtsec.c 
b/drivers/net/ethernet/freescale/fman/fman_dtsec.c
index c88918c..84ea130 100644
--- a/drivers/net/ethernet/freescale/fman/fman_dtsec.c
+++ b/drivers/net/ethernet/freescale/fman/fman_dtsec.c
@@ -337,7 +337,7 @@ struct fman_mac {
u8 mac_id;
u32 exceptions;
bool ptp_tsu_enabled;
-   bool en_tsu_err_exeption;
+   bool en_tsu_err_exception;
struct dtsec_cfg *dtsec_drv_param;
void *fm;
struct fman_rev_info fm_rev_info;
@@ -1247,12 +1247,12 @@ int dtsec_set_exception(struct fman_mac *dtsec,
switch (exception) {
case FM_MAC_EX_1G_1588_TS_RX_ERR:
if (enable) {
-   dtsec->en_tsu_err_exeption = true;
+   dtsec->en_tsu_err_exception = true;
iowrite32be(ioread32be(>tmr_pemask) |
TMR_PEMASK_TSREEN,
>tmr_pemask);
} else {
-   dtsec->en_tsu_err_exeption = false;
+   dtsec->en_tsu_err_exception = false;
iowrite32be(ioread32be(>tmr_pemask) &
~TMR_PEMASK_TSREEN,
>tmr_pemask);
@@ -1420,7 +1420,7 @@ struct fman_mac *dtsec_config(struct fman_mac_params 
*params)
dtsec->event_cb = params->event_cb;
dtsec->dev_id = params->dev_id;
dtsec->ptp_tsu_enabled = dtsec->dtsec_drv_param->ptp_tsu_en;
-   dtsec->en_tsu_err_exeption = dtsec->dtsec_drv_param->ptp_exception_en;
+   dtsec->en_tsu_err_exception = dtsec->dtsec_drv_param->ptp_exception_en;
 
dtsec->fm = params->fm;
dtsec->basex_if = params->basex_if;
-- 
2.10.2

[PATCH] fsl/fman: fix spelling mistake in variable name en_tsu_err_exeption

From: Colin Ian King 

trivial fix to spelling mistake, en_tsu_err_exeption should
be en_tsu_err_exception

Signed-off-by: Colin Ian King 
---
 drivers/net/ethernet/freescale/fman/fman_dtsec.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fman/fman_dtsec.c 
b/drivers/net/ethernet/freescale/fman/fman_dtsec.c
index c88918c..84ea130 100644
--- a/drivers/net/ethernet/freescale/fman/fman_dtsec.c
+++ b/drivers/net/ethernet/freescale/fman/fman_dtsec.c
@@ -337,7 +337,7 @@ struct fman_mac {
u8 mac_id;
u32 exceptions;
bool ptp_tsu_enabled;
-   bool en_tsu_err_exeption;
+   bool en_tsu_err_exception;
struct dtsec_cfg *dtsec_drv_param;
void *fm;
struct fman_rev_info fm_rev_info;
@@ -1247,12 +1247,12 @@ int dtsec_set_exception(struct fman_mac *dtsec,
switch (exception) {
case FM_MAC_EX_1G_1588_TS_RX_ERR:
if (enable) {
-   dtsec->en_tsu_err_exeption = true;
+   dtsec->en_tsu_err_exception = true;
iowrite32be(ioread32be(>tmr_pemask) |
TMR_PEMASK_TSREEN,
>tmr_pemask);
} else {
-   dtsec->en_tsu_err_exeption = false;
+   dtsec->en_tsu_err_exception = false;
iowrite32be(ioread32be(>tmr_pemask) &
~TMR_PEMASK_TSREEN,
>tmr_pemask);
@@ -1420,7 +1420,7 @@ struct fman_mac *dtsec_config(struct fman_mac_params 
*params)
dtsec->event_cb = params->event_cb;
dtsec->dev_id = params->dev_id;
dtsec->ptp_tsu_enabled = dtsec->dtsec_drv_param->ptp_tsu_en;
-   dtsec->en_tsu_err_exeption = dtsec->dtsec_drv_param->ptp_exception_en;
+   dtsec->en_tsu_err_exception = dtsec->dtsec_drv_param->ptp_exception_en;
 
dtsec->fm = params->fm;
dtsec->basex_if = params->basex_if;
-- 
2.10.2

Re: [PATCH] Add pidfs filesystem

Hi Alexey,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.10-rc8 next-20170217]
[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/Alexey-Gladkov/Add-pidfs-filesystem/20170219-070129
config: x86_64-randconfig-x003-201708 (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=x86_64 

All warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/uapi/linux/capability.h:16,
from include/linux/capability.h:15,
from include/linux/sched.h:15,
from include/linux/uaccess.h:4,
from fs/proc/root.c:9:
   fs/proc/root.c: In function 'proc_kill_sb':
   fs/proc/root.c:107:9: error: 'struct pid_namespace' has no member named 
'pidfs_self'; did you mean 'proc_self'?
  if (ns->pidfs_self)
^
   include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> fs/proc/root.c:107:3: note: in expansion of macro 'if'
  if (ns->pidfs_self)
  ^~
   fs/proc/root.c:107:9: error: 'struct pid_namespace' has no member named 
'pidfs_self'; did you mean 'proc_self'?
  if (ns->pidfs_self)
^
   include/linux/compiler.h:149:42: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> fs/proc/root.c:107:3: note: in expansion of macro 'if'
  if (ns->pidfs_self)
  ^~
   fs/proc/root.c:107:9: error: 'struct pid_namespace' has no member named 
'pidfs_self'; did you mean 'proc_self'?
  if (ns->pidfs_self)
^
   include/linux/compiler.h:160:16: note: in definition of macro '__trace_if'
  __r = !!(cond); \
   ^~~~
>> fs/proc/root.c:107:3: note: in expansion of macro 'if'
  if (ns->pidfs_self)
  ^~
   fs/proc/root.c:108:11: error: 'struct pid_namespace' has no member named 
'pidfs_self'; did you mean 'proc_self'?
   dput(ns->pidfs_self);
  ^~
   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/uapi/linux/capability.h:16,
from include/linux/capability.h:15,
from include/linux/sched.h:15,
from include/linux/uaccess.h:4,
from fs/proc/root.c:9:
   fs/proc/root.c:110:9: error: 'struct pid_namespace' has no member named 
'pidfs_thread_self'; did you mean 'proc_thread_self'?
  if (ns->pidfs_thread_self)
^
   include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
   fs/proc/root.c:110:3: note: in expansion of macro 'if'
  if (ns->pidfs_thread_self)
  ^~
   fs/proc/root.c:110:9: error: 'struct pid_namespace' has no member named 
'pidfs_thread_self'; did you mean 'proc_thread_self'?
  if (ns->pidfs_thread_self)
^
   include/linux/compiler.h:149:42: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
   fs/proc/root.c:110:3: note: in expansion of macro 'if'
  if (ns->pidfs_thread_self)
  ^~
   fs/proc/root.c:110:9: error: 'struct pid_namespace' has no member named 
'pidfs_thread_self'; did you mean 'proc_thread_self'?
  if (ns->pidfs_thread_self)
^
   include/linux/compiler.h:160:16: note: in definition of macro '__trace_if'
  __r = !!(cond); \
   ^~~~
   fs/proc/root.c:110:3: note: in expansion of macro 'if'
  if (ns->pidfs_thread_self)
  ^~
   fs/proc/root.c:111:11: error: 'struct pid_namespace' has no member named 
'pidfs_thread_self'; did you mean 'proc_thread_self'?
   dput(ns->pidfs_thread_self);
  ^~
   fs/proc/root.c: In function 'pid_ns_prepare_proc':
   fs/proc/root.c:282:5: error: 'struct pid_namespace' has no member named 
'pidfs_mnt'; did you mean 'proc_mnt'?
  ns->pidfs_mnt = mnt;
^~
   fs/proc/root.c: In function 'pid_ns_release_proc':
   fs/proc/root.c:292:18: error: 'struct pid_namespace' has no member named 
'pidfs_mnt'; did you mean 'proc_mnt'?
  kern_unmount(ns->pidfs_mnt);

Re: [PATCH] Add pidfs filesystem

Hi Alexey,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.10-rc8 next-20170217]
[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/Alexey-Gladkov/Add-pidfs-filesystem/20170219-070129
config: x86_64-randconfig-x003-201708 (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=x86_64 

All warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/uapi/linux/capability.h:16,
from include/linux/capability.h:15,
from include/linux/sched.h:15,
from include/linux/uaccess.h:4,
from fs/proc/root.c:9:
   fs/proc/root.c: In function 'proc_kill_sb':
   fs/proc/root.c:107:9: error: 'struct pid_namespace' has no member named 
'pidfs_self'; did you mean 'proc_self'?
  if (ns->pidfs_self)
^
   include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> fs/proc/root.c:107:3: note: in expansion of macro 'if'
  if (ns->pidfs_self)
  ^~
   fs/proc/root.c:107:9: error: 'struct pid_namespace' has no member named 
'pidfs_self'; did you mean 'proc_self'?
  if (ns->pidfs_self)
^
   include/linux/compiler.h:149:42: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> fs/proc/root.c:107:3: note: in expansion of macro 'if'
  if (ns->pidfs_self)
  ^~
   fs/proc/root.c:107:9: error: 'struct pid_namespace' has no member named 
'pidfs_self'; did you mean 'proc_self'?
  if (ns->pidfs_self)
^
   include/linux/compiler.h:160:16: note: in definition of macro '__trace_if'
  __r = !!(cond); \
   ^~~~
>> fs/proc/root.c:107:3: note: in expansion of macro 'if'
  if (ns->pidfs_self)
  ^~
   fs/proc/root.c:108:11: error: 'struct pid_namespace' has no member named 
'pidfs_self'; did you mean 'proc_self'?
   dput(ns->pidfs_self);
  ^~
   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/uapi/linux/capability.h:16,
from include/linux/capability.h:15,
from include/linux/sched.h:15,
from include/linux/uaccess.h:4,
from fs/proc/root.c:9:
   fs/proc/root.c:110:9: error: 'struct pid_namespace' has no member named 
'pidfs_thread_self'; did you mean 'proc_thread_self'?
  if (ns->pidfs_thread_self)
^
   include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
   fs/proc/root.c:110:3: note: in expansion of macro 'if'
  if (ns->pidfs_thread_self)
  ^~
   fs/proc/root.c:110:9: error: 'struct pid_namespace' has no member named 
'pidfs_thread_self'; did you mean 'proc_thread_self'?
  if (ns->pidfs_thread_self)
^
   include/linux/compiler.h:149:42: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
   fs/proc/root.c:110:3: note: in expansion of macro 'if'
  if (ns->pidfs_thread_self)
  ^~
   fs/proc/root.c:110:9: error: 'struct pid_namespace' has no member named 
'pidfs_thread_self'; did you mean 'proc_thread_self'?
  if (ns->pidfs_thread_self)
^
   include/linux/compiler.h:160:16: note: in definition of macro '__trace_if'
  __r = !!(cond); \
   ^~~~
   fs/proc/root.c:110:3: note: in expansion of macro 'if'
  if (ns->pidfs_thread_self)
  ^~
   fs/proc/root.c:111:11: error: 'struct pid_namespace' has no member named 
'pidfs_thread_self'; did you mean 'proc_thread_self'?
   dput(ns->pidfs_thread_self);
  ^~
   fs/proc/root.c: In function 'pid_ns_prepare_proc':
   fs/proc/root.c:282:5: error: 'struct pid_namespace' has no member named 
'pidfs_mnt'; did you mean 'proc_mnt'?
  ns->pidfs_mnt = mnt;
^~
   fs/proc/root.c: In function 'pid_ns_release_proc':
   fs/proc/root.c:292:18: error: 'struct pid_namespace' has no member named 
'pidfs_mnt'; did you mean 'proc_mnt'?
  kern_unmount(ns->pidfs_mnt);

Re: [PATCH] Add pidfs filesystem

Hi Alexey,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc8 next-20170217]
[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/Alexey-Gladkov/Add-pidfs-filesystem/20170219-070129
config: x86_64-randconfig-x001-201708 (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=x86_64 

All errors (new ones prefixed by >>):

   fs/proc/root.c: In function 'proc_kill_sb':
>> fs/proc/root.c:107:9: error: 'struct pid_namespace' has no member named 
>> 'pidfs_self'; did you mean 'proc_self'?
  if (ns->pidfs_self)
^~
   fs/proc/root.c:108:11: error: 'struct pid_namespace' has no member named 
'pidfs_self'; did you mean 'proc_self'?
   dput(ns->pidfs_self);
  ^~
>> fs/proc/root.c:110:9: error: 'struct pid_namespace' has no member named 
>> 'pidfs_thread_self'; did you mean 'proc_thread_self'?
  if (ns->pidfs_thread_self)
^~
   fs/proc/root.c:111:11: error: 'struct pid_namespace' has no member named 
'pidfs_thread_self'; did you mean 'proc_thread_self'?
   dput(ns->pidfs_thread_self);
  ^~
   fs/proc/root.c: In function 'pid_ns_prepare_proc':
>> fs/proc/root.c:282:5: error: 'struct pid_namespace' has no member named 
>> 'pidfs_mnt'; did you mean 'proc_mnt'?
  ns->pidfs_mnt = mnt;
^~
   fs/proc/root.c: In function 'pid_ns_release_proc':
   fs/proc/root.c:292:18: error: 'struct pid_namespace' has no member named 
'pidfs_mnt'; did you mean 'proc_mnt'?
  kern_unmount(ns->pidfs_mnt);
 ^~
--
   fs/proc/self.c: In function 'proc_setup_self':
>> fs/proc/self.c:66:5: error: 'struct pid_namespace' has no member named 
>> 'pidfs_self'; did you mean 'proc_self'?
  ns->pidfs_self = self;
^~
--
   fs/proc/thread_self.c: In function 'proc_setup_thread_self':
>> fs/proc/thread_self.c:67:5: error: 'struct pid_namespace' has no member 
>> named 'pidfs_thread_self'; did you mean 'proc_thread_self'?
  ns->pidfs_thread_self = thread_self;
^~

vim +107 fs/proc/root.c

   101  {
   102  struct pid_namespace *ns;
   103  
   104  ns = (struct pid_namespace *)sb->s_fs_info;
   105  
   106  if (IS_ENABLED(CONFIG_PROC_PIDFS) && sb->s_type == 
_fs_type) {
 > 107  if (ns->pidfs_self)
   108  dput(ns->pidfs_self);
   109  
 > 110  if (ns->pidfs_thread_self)
   111  dput(ns->pidfs_thread_self);
   112  } else {
   113  if (ns->proc_self)
   114  dput(ns->proc_self);
   115  
   116  if (ns->proc_thread_self)
   117  dput(ns->proc_thread_self);
   118  }
   119  
   120  kill_anon_super(sb);
   121  put_pid_ns(ns);
   122  }
   123  
   124  static struct file_system_type proc_fs_type = {
   125  .name   = "proc",
   126  .mount  = proc_mount,
   127  .kill_sb= proc_kill_sb,
   128  .fs_flags   = FS_USERNS_MOUNT,
   129  };
   130  
   131  struct file_system_type pidfs_fs_type = {
   132  .name   = "pidfs",
   133  .mount  = proc_mount,
   134  .kill_sb= proc_kill_sb,
   135  .fs_flags   = FS_USERNS_MOUNT,
   136  };
   137  
   138  void __init proc_root_init(void)
   139  {
   140  int err;
   141  
   142  proc_init_inodecache();
   143  set_proc_pid_nlink();
   144  err = register_filesystem(_fs_type);
   145  if (err)
   146  return;
   147  
   148  err = register_filesystem(_fs_type);
   149  if (err)
   150  return;
   151  
   152  proc_self_init();
   153  proc_thread_self_init();
   154  proc_symlink("mounts", NULL, "self/mounts");
   155  
   156  proc_net_init();
   157  
   158  #ifdef CONFIG_SYSVIPC
   159  proc_mkdir("sysvipc", NULL);
   160  #endif
   161  proc_mkdir("fs", NULL);
   162  proc_mkdir("driver", NULL);
   163  proc_create_mount_point("fs/nfsd"); /* somewhere for the nfsd 
filesystem to be mounted */
   164  #if defined(CONFIG_SUN_OPENPROMFS) || 
defined(CONFIG_SUN_OPENPROMFS_MODULE)
   165  /* just give it a mountpoint */
   166  proc_create_mount_point("openprom");
   167  #endif
   168  proc_tty_init();
   169  proc_mkdir("bus", NULL);
   170  proc_sys_init();
   171  }
   172  
   173  static int proc_root_getattr(struct vfsmount *mnt, struct dentry 
*dentry, struct kstat *stat)
   174  {
   175  generic_fillattr(d_inode(dentry), stat);
   176  stat->nlink = proc_root.nlink + nr_processes();
   177  return 0;
   178  }
   179

Re: [PATCH] Add pidfs filesystem

Hi Alexey,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc8 next-20170217]
[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/Alexey-Gladkov/Add-pidfs-filesystem/20170219-070129
config: x86_64-randconfig-x001-201708 (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=x86_64 

All errors (new ones prefixed by >>):

   fs/proc/root.c: In function 'proc_kill_sb':
>> fs/proc/root.c:107:9: error: 'struct pid_namespace' has no member named 
>> 'pidfs_self'; did you mean 'proc_self'?
  if (ns->pidfs_self)
^~
   fs/proc/root.c:108:11: error: 'struct pid_namespace' has no member named 
'pidfs_self'; did you mean 'proc_self'?
   dput(ns->pidfs_self);
  ^~
>> fs/proc/root.c:110:9: error: 'struct pid_namespace' has no member named 
>> 'pidfs_thread_self'; did you mean 'proc_thread_self'?
  if (ns->pidfs_thread_self)
^~
   fs/proc/root.c:111:11: error: 'struct pid_namespace' has no member named 
'pidfs_thread_self'; did you mean 'proc_thread_self'?
   dput(ns->pidfs_thread_self);
  ^~
   fs/proc/root.c: In function 'pid_ns_prepare_proc':
>> fs/proc/root.c:282:5: error: 'struct pid_namespace' has no member named 
>> 'pidfs_mnt'; did you mean 'proc_mnt'?
  ns->pidfs_mnt = mnt;
^~
   fs/proc/root.c: In function 'pid_ns_release_proc':
   fs/proc/root.c:292:18: error: 'struct pid_namespace' has no member named 
'pidfs_mnt'; did you mean 'proc_mnt'?
  kern_unmount(ns->pidfs_mnt);
 ^~
--
   fs/proc/self.c: In function 'proc_setup_self':
>> fs/proc/self.c:66:5: error: 'struct pid_namespace' has no member named 
>> 'pidfs_self'; did you mean 'proc_self'?
  ns->pidfs_self = self;
^~
--
   fs/proc/thread_self.c: In function 'proc_setup_thread_self':
>> fs/proc/thread_self.c:67:5: error: 'struct pid_namespace' has no member 
>> named 'pidfs_thread_self'; did you mean 'proc_thread_self'?
  ns->pidfs_thread_self = thread_self;
^~

vim +107 fs/proc/root.c

   101  {
   102  struct pid_namespace *ns;
   103  
   104  ns = (struct pid_namespace *)sb->s_fs_info;
   105  
   106  if (IS_ENABLED(CONFIG_PROC_PIDFS) && sb->s_type == 
_fs_type) {
 > 107  if (ns->pidfs_self)
   108  dput(ns->pidfs_self);
   109  
 > 110  if (ns->pidfs_thread_self)
   111  dput(ns->pidfs_thread_self);
   112  } else {
   113  if (ns->proc_self)
   114  dput(ns->proc_self);
   115  
   116  if (ns->proc_thread_self)
   117  dput(ns->proc_thread_self);
   118  }
   119  
   120  kill_anon_super(sb);
   121  put_pid_ns(ns);
   122  }
   123  
   124  static struct file_system_type proc_fs_type = {
   125  .name   = "proc",
   126  .mount  = proc_mount,
   127  .kill_sb= proc_kill_sb,
   128  .fs_flags   = FS_USERNS_MOUNT,
   129  };
   130  
   131  struct file_system_type pidfs_fs_type = {
   132  .name   = "pidfs",
   133  .mount  = proc_mount,
   134  .kill_sb= proc_kill_sb,
   135  .fs_flags   = FS_USERNS_MOUNT,
   136  };
   137  
   138  void __init proc_root_init(void)
   139  {
   140  int err;
   141  
   142  proc_init_inodecache();
   143  set_proc_pid_nlink();
   144  err = register_filesystem(_fs_type);
   145  if (err)
   146  return;
   147  
   148  err = register_filesystem(_fs_type);
   149  if (err)
   150  return;
   151  
   152  proc_self_init();
   153  proc_thread_self_init();
   154  proc_symlink("mounts", NULL, "self/mounts");
   155  
   156  proc_net_init();
   157  
   158  #ifdef CONFIG_SYSVIPC
   159  proc_mkdir("sysvipc", NULL);
   160  #endif
   161  proc_mkdir("fs", NULL);
   162  proc_mkdir("driver", NULL);
   163  proc_create_mount_point("fs/nfsd"); /* somewhere for the nfsd 
filesystem to be mounted */
   164  #if defined(CONFIG_SUN_OPENPROMFS) || 
defined(CONFIG_SUN_OPENPROMFS_MODULE)
   165  /* just give it a mountpoint */
   166  proc_create_mount_point("openprom");
   167  #endif
   168  proc_tty_init();
   169  proc_mkdir("bus", NULL);
   170  proc_sys_init();
   171  }
   172  
   173  static int proc_root_getattr(struct vfsmount *mnt, struct dentry 
*dentry, struct kstat *stat)
   174  {
   175  generic_fillattr(d_inode(dentry), stat);
   176  stat->nlink = proc_root.nlink + nr_processes();
   177  return 0;
   178  }
   179

[PATCH v3 2/5] vfs: Add checks for filesystem timestamp limits

Allow read only mounts for filesystems that do not
have maximum timestamps beyond the y2038 expiry
timestamp.

Also, allow a sysctl override to all such filesystems
to be mounted with write permissions.
A boot param supports initial override of these
checks from the early boot without recompilation.

Suggested-by: Arnd Bergmann 
Signed-off-by: Deepa Dinamani 
---
 fs/inode.c  | 13 +
 fs/internal.h   |  2 ++
 fs/namespace.c  | 12 
 fs/super.c  |  7 +++
 include/linux/fs.h  |  1 +
 include/linux/time64.h  |  4 
 include/uapi/linux/fs.h |  6 +-
 kernel/sysctl.c |  7 +++
 8 files changed, 51 insertions(+), 1 deletion(-)

diff --git a/fs/inode.c b/fs/inode.c
index 0b3ee89..0573a3e 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -75,6 +75,19 @@ static DEFINE_PER_CPU(unsigned long, nr_unused);
 
 static struct kmem_cache *inode_cachep __read_mostly;
 
+struct vfs_max_timestamp_check timestamp_check = {
+   .timestamp_supported = Y2038_EXPIRY_TIMESTAMP,
+   .check_on = 0,
+};
+
+static int __init setup_timestamp_check(char *str)
+{
+   timestamp_check.check_on = 1;
+return 0;
+}
+
+early_param("fstimestampcheck", setup_timestamp_check);
+
 static long get_nr_inodes(void)
 {
int i;
diff --git a/fs/internal.h b/fs/internal.h
index 11c6d89..4b3cb9e 100644
--- a/fs/internal.h
+++ b/fs/internal.h
@@ -67,6 +67,8 @@ extern int finish_automount(struct vfsmount *, struct path *);
 
 extern int sb_prepare_remount_readonly(struct super_block *);
 
+extern bool sb_file_times_updatable(struct super_block *sb);
+
 extern void __init mnt_init(void);
 
 extern int __mnt_want_write(struct vfsmount *);
diff --git a/fs/namespace.c b/fs/namespace.c
index 8bfad42..dbf3f1c 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -538,6 +538,18 @@ static void __mnt_unmake_readonly(struct mount *mnt)
unlock_mount_hash();
 }
 
+bool sb_file_times_updatable(struct super_block *sb)
+{
+
+   if (!timestamp_check.check_on)
+   return true;
+
+   if (sb->s_time_max > timestamp_check.timestamp_supported)
+   return true;
+
+   return false;
+}
+
 int sb_prepare_remount_readonly(struct super_block *sb)
 {
struct mount *mnt;
diff --git a/fs/super.c b/fs/super.c
index f9c2241..4e7577b 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -1245,6 +1245,13 @@ mount_fs(struct file_system_type *type, int flags, const 
char *name, void *data)
WARN((sb->s_maxbytes < 0), "%s set sb->s_maxbytes to "
"negative value (%lld)\n", type->name, sb->s_maxbytes);
 
+   if (!(sb->s_flags & MS_RDONLY) && !sb_file_times_updatable(sb)) {
+   WARN(1, "File times cannot be updated on the filesystem.\n");
+   WARN(1, "Retry mounting the filesystem readonly.\n");
+   error = -EROFS;
+   goto out_sb;
+   }
+
up_write(>s_umount);
free_secdata(secdata);
return root;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index ef55dfb..e12a32d 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -68,6 +68,7 @@ extern struct inodes_stat_t inodes_stat;
 extern int leases_enable, lease_break_time;
 extern int sysctl_protected_symlinks;
 extern int sysctl_protected_hardlinks;
+extern struct vfs_max_timestamp_check timestamp_check;
 
 struct buffer_head;
 typedef int (get_block_t)(struct inode *inode, sector_t iblock,
diff --git a/include/linux/time64.h b/include/linux/time64.h
index 25433b18..906e0b3 100644
--- a/include/linux/time64.h
+++ b/include/linux/time64.h
@@ -43,6 +43,10 @@ struct itimerspec64 {
 #define KTIME_MAX  ((s64)~((u64)1 << 63))
 #define KTIME_SEC_MAX  (KTIME_MAX / NSEC_PER_SEC)
 
+/* Timestamps on boundary */
+#define Y2038_EXPIRY_TIMESTAMP S32_MAX /* 2147483647 */
+#define Y2106_EXPIRY_TIMESTAMP U32_MAX /* 4294967295 */
+
 #if __BITS_PER_LONG == 64
 
 static inline struct timespec timespec64_to_timespec(const struct timespec64 
ts64)
diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index 048a85e..125e4ae 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -91,6 +91,11 @@ struct files_stat_struct {
unsigned long max_files;/* tunable */
 };
 
+struct vfs_max_timestamp_check {
+   time64_t timestamp_supported;
+   int check_on;
+};
+
 struct inodes_stat_t {
long nr_inodes;
long nr_unused;
@@ -100,7 +105,6 @@ struct inodes_stat_t {
 
 #define NR_FILE  8192  /* this can well be larger on a larger system */
 
-
 /*
  * These are the fs-independent mount-flags: up to 32 flags are supported
  */
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index bb260ce..eda60d9 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1667,6 +1667,13 @@ static struct ctl_table fs_table[] = {
.proc_handler   = proc_doulongvec_minmax,
},

[PATCH v3 1/5] vfs: Add file timestamp range support

Add fields to the superblock to track the min and max
timestamps supported by filesystems.

Initially, when a superblock is allocated, initialize
it to the max and min values the fields can hold.
Individual filesystems override these to match their
actual limits.

Pseudo filesystems are assumed to always support the
min and max allowable values for the fields.

Note that the time ranges are saved in type time64_t
rather than time_t.
This is required because if we save ranges in time_t
then we would not be able to save timestamp ranges
for files that support timestamps beyond y2038.

Signed-off-by: Deepa Dinamani 
---
 fs/libfs.c | 4 
 fs/super.c | 2 ++
 include/linux/fs.h | 3 +++
 include/linux/time64.h | 2 ++
 4 files changed, 11 insertions(+)

diff --git a/fs/libfs.c b/fs/libfs.c
index 28d6f35..90ee803 100644
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -257,6 +257,8 @@ struct dentry *mount_pseudo_xattr(struct file_system_type 
*fs_type, char *name,
s->s_op = ops ? ops : _super_operations;
s->s_xattr = xattr;
s->s_time_gran = 1;
+   s->s_time_min = TIME64_MIN;
+   s->s_time_max = TIME64_MAX;
root = new_inode(s);
if (!root)
goto Enomem;
@@ -518,6 +520,8 @@ int simple_fill_super(struct super_block *s, unsigned long 
magic,
s->s_magic = magic;
s->s_op = _super_operations;
s->s_time_gran = 1;
+   s->s_time_min = TIME64_MIN;
+   s->s_time_max = TIME64_MAX;
 
inode = new_inode(s);
if (!inode)
diff --git a/fs/super.c b/fs/super.c
index b8b6a08..f9c2241 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -247,6 +247,8 @@ static struct super_block *alloc_super(struct 
file_system_type *type, int flags,
s->s_maxbytes = MAX_NON_LFS;
s->s_op = _op;
s->s_time_gran = 10;
+   s->s_time_min = TIME64_MIN;
+   s->s_time_max = TIME64_MAX;
s->cleancache_poolid = CLEANCACHE_NO_POOL;
 
s->s_shrink.seeks = DEFAULT_SEEKS;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index de8ed0b..ef55dfb 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1337,6 +1337,9 @@ struct super_block {
/* Granularity of c/m/atime in ns.
   Cannot be worse than a second */
u32s_time_gran;
+   /* Time limits for c/m/atime in seconds. */
+   time64_t   s_time_min;
+   time64_t   s_time_max;
 
/*
 * The next field is for VFS *only*. No filesystems have any business
diff --git a/include/linux/time64.h b/include/linux/time64.h
index 980c71b..25433b18 100644
--- a/include/linux/time64.h
+++ b/include/linux/time64.h
@@ -38,6 +38,8 @@ struct itimerspec64 {
 
 /* Located here for timespec[64]_valid_strict */
 #define TIME64_MAX ((s64)~((u64)1 << 63))
+#define TIME64_MIN (-TIME64_MAX - 1)
+
 #define KTIME_MAX  ((s64)~((u64)1 << 63))
 #define KTIME_SEC_MAX  (KTIME_MAX / NSEC_PER_SEC)
 
-- 
2.7.4

[PATCH v3 2/5] vfs: Add checks for filesystem timestamp limits

Allow read only mounts for filesystems that do not
have maximum timestamps beyond the y2038 expiry
timestamp.

Also, allow a sysctl override to all such filesystems
to be mounted with write permissions.
A boot param supports initial override of these
checks from the early boot without recompilation.

Suggested-by: Arnd Bergmann 
Signed-off-by: Deepa Dinamani 
---
 fs/inode.c  | 13 +
 fs/internal.h   |  2 ++
 fs/namespace.c  | 12 
 fs/super.c  |  7 +++
 include/linux/fs.h  |  1 +
 include/linux/time64.h  |  4 
 include/uapi/linux/fs.h |  6 +-
 kernel/sysctl.c |  7 +++
 8 files changed, 51 insertions(+), 1 deletion(-)

diff --git a/fs/inode.c b/fs/inode.c
index 0b3ee89..0573a3e 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -75,6 +75,19 @@ static DEFINE_PER_CPU(unsigned long, nr_unused);
 
 static struct kmem_cache *inode_cachep __read_mostly;
 
+struct vfs_max_timestamp_check timestamp_check = {
+   .timestamp_supported = Y2038_EXPIRY_TIMESTAMP,
+   .check_on = 0,
+};
+
+static int __init setup_timestamp_check(char *str)
+{
+   timestamp_check.check_on = 1;
+return 0;
+}
+
+early_param("fstimestampcheck", setup_timestamp_check);
+
 static long get_nr_inodes(void)
 {
int i;
diff --git a/fs/internal.h b/fs/internal.h
index 11c6d89..4b3cb9e 100644
--- a/fs/internal.h
+++ b/fs/internal.h
@@ -67,6 +67,8 @@ extern int finish_automount(struct vfsmount *, struct path *);
 
 extern int sb_prepare_remount_readonly(struct super_block *);
 
+extern bool sb_file_times_updatable(struct super_block *sb);
+
 extern void __init mnt_init(void);
 
 extern int __mnt_want_write(struct vfsmount *);
diff --git a/fs/namespace.c b/fs/namespace.c
index 8bfad42..dbf3f1c 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -538,6 +538,18 @@ static void __mnt_unmake_readonly(struct mount *mnt)
unlock_mount_hash();
 }
 
+bool sb_file_times_updatable(struct super_block *sb)
+{
+
+   if (!timestamp_check.check_on)
+   return true;
+
+   if (sb->s_time_max > timestamp_check.timestamp_supported)
+   return true;
+
+   return false;
+}
+
 int sb_prepare_remount_readonly(struct super_block *sb)
 {
struct mount *mnt;
diff --git a/fs/super.c b/fs/super.c
index f9c2241..4e7577b 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -1245,6 +1245,13 @@ mount_fs(struct file_system_type *type, int flags, const 
char *name, void *data)
WARN((sb->s_maxbytes < 0), "%s set sb->s_maxbytes to "
"negative value (%lld)\n", type->name, sb->s_maxbytes);
 
+   if (!(sb->s_flags & MS_RDONLY) && !sb_file_times_updatable(sb)) {
+   WARN(1, "File times cannot be updated on the filesystem.\n");
+   WARN(1, "Retry mounting the filesystem readonly.\n");
+   error = -EROFS;
+   goto out_sb;
+   }
+
up_write(>s_umount);
free_secdata(secdata);
return root;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index ef55dfb..e12a32d 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -68,6 +68,7 @@ extern struct inodes_stat_t inodes_stat;
 extern int leases_enable, lease_break_time;
 extern int sysctl_protected_symlinks;
 extern int sysctl_protected_hardlinks;
+extern struct vfs_max_timestamp_check timestamp_check;
 
 struct buffer_head;
 typedef int (get_block_t)(struct inode *inode, sector_t iblock,
diff --git a/include/linux/time64.h b/include/linux/time64.h
index 25433b18..906e0b3 100644
--- a/include/linux/time64.h
+++ b/include/linux/time64.h
@@ -43,6 +43,10 @@ struct itimerspec64 {
 #define KTIME_MAX  ((s64)~((u64)1 << 63))
 #define KTIME_SEC_MAX  (KTIME_MAX / NSEC_PER_SEC)
 
+/* Timestamps on boundary */
+#define Y2038_EXPIRY_TIMESTAMP S32_MAX /* 2147483647 */
+#define Y2106_EXPIRY_TIMESTAMP U32_MAX /* 4294967295 */
+
 #if __BITS_PER_LONG == 64
 
 static inline struct timespec timespec64_to_timespec(const struct timespec64 
ts64)
diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index 048a85e..125e4ae 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -91,6 +91,11 @@ struct files_stat_struct {
unsigned long max_files;/* tunable */
 };
 
+struct vfs_max_timestamp_check {
+   time64_t timestamp_supported;
+   int check_on;
+};
+
 struct inodes_stat_t {
long nr_inodes;
long nr_unused;
@@ -100,7 +105,6 @@ struct inodes_stat_t {
 
 #define NR_FILE  8192  /* this can well be larger on a larger system */
 
-
 /*
  * These are the fs-independent mount-flags: up to 32 flags are supported
  */
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index bb260ce..eda60d9 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1667,6 +1667,13 @@ static struct ctl_table fs_table[] = {
.proc_handler   = proc_doulongvec_minmax,
},
{
+   .procname

[PATCH v3 1/5] vfs: Add file timestamp range support

Add fields to the superblock to track the min and max
timestamps supported by filesystems.

Initially, when a superblock is allocated, initialize
it to the max and min values the fields can hold.
Individual filesystems override these to match their
actual limits.

Pseudo filesystems are assumed to always support the
min and max allowable values for the fields.

Note that the time ranges are saved in type time64_t
rather than time_t.
This is required because if we save ranges in time_t
then we would not be able to save timestamp ranges
for files that support timestamps beyond y2038.

Signed-off-by: Deepa Dinamani 
---
 fs/libfs.c | 4 
 fs/super.c | 2 ++
 include/linux/fs.h | 3 +++
 include/linux/time64.h | 2 ++
 4 files changed, 11 insertions(+)

diff --git a/fs/libfs.c b/fs/libfs.c
index 28d6f35..90ee803 100644
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -257,6 +257,8 @@ struct dentry *mount_pseudo_xattr(struct file_system_type 
*fs_type, char *name,
s->s_op = ops ? ops : _super_operations;
s->s_xattr = xattr;
s->s_time_gran = 1;
+   s->s_time_min = TIME64_MIN;
+   s->s_time_max = TIME64_MAX;
root = new_inode(s);
if (!root)
goto Enomem;
@@ -518,6 +520,8 @@ int simple_fill_super(struct super_block *s, unsigned long 
magic,
s->s_magic = magic;
s->s_op = _super_operations;
s->s_time_gran = 1;
+   s->s_time_min = TIME64_MIN;
+   s->s_time_max = TIME64_MAX;
 
inode = new_inode(s);
if (!inode)
diff --git a/fs/super.c b/fs/super.c
index b8b6a08..f9c2241 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -247,6 +247,8 @@ static struct super_block *alloc_super(struct 
file_system_type *type, int flags,
s->s_maxbytes = MAX_NON_LFS;
s->s_op = _op;
s->s_time_gran = 10;
+   s->s_time_min = TIME64_MIN;
+   s->s_time_max = TIME64_MAX;
s->cleancache_poolid = CLEANCACHE_NO_POOL;
 
s->s_shrink.seeks = DEFAULT_SEEKS;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index de8ed0b..ef55dfb 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1337,6 +1337,9 @@ struct super_block {
/* Granularity of c/m/atime in ns.
   Cannot be worse than a second */
u32s_time_gran;
+   /* Time limits for c/m/atime in seconds. */
+   time64_t   s_time_min;
+   time64_t   s_time_max;
 
/*
 * The next field is for VFS *only*. No filesystems have any business
diff --git a/include/linux/time64.h b/include/linux/time64.h
index 980c71b..25433b18 100644
--- a/include/linux/time64.h
+++ b/include/linux/time64.h
@@ -38,6 +38,8 @@ struct itimerspec64 {
 
 /* Located here for timespec[64]_valid_strict */
 #define TIME64_MAX ((s64)~((u64)1 << 63))
+#define TIME64_MIN (-TIME64_MAX - 1)
+
 #define KTIME_MAX  ((s64)~((u64)1 << 63))
 #define KTIME_SEC_MAX  (KTIME_MAX / NSEC_PER_SEC)
 
-- 
2.7.4

[PATCH v3 3/5] ext4: Initialize timestamps limits

ext4 has different overflow limits for max filesystem
timestamps based on the extra bytes available.

Signed-off-by: Deepa Dinamani 
---
 fs/ext4/ext4.h  | 4 
 fs/ext4/super.c | 7 ++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 2bef0bd..7bac2cd 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -1639,6 +1639,10 @@ static inline void ext4_clear_state_flags(struct 
ext4_inode_info *ei)
 
 #define EXT4_GOOD_OLD_INODE_SIZE 128
 
+#define EXT4_EXTRA_TIMESTAMP_MAX   (((s64)1 << 34) - 1  + S32_MIN)
+#define EXT4_NON_EXTRA_TIMESTAMP_MAX   Y2038_EXPIRY_TIMESTAMP
+#define EXT4_TIMESTAMP_MIN S32_MIN
+
 /*
  * Feature set definitions
  */
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index a673558..a77e11c 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3689,8 +3689,13 @@ static int ext4_fill_super(struct super_block *sb, void 
*data, int silent)
   sbi->s_inode_size);
goto failed_mount;
}
-   if (sbi->s_inode_size > EXT4_GOOD_OLD_INODE_SIZE)
+   if (sbi->s_inode_size > EXT4_GOOD_OLD_INODE_SIZE) {
sb->s_time_gran = 1 << (EXT4_EPOCH_BITS - 2);
+   sb->s_time_max = EXT4_EXTRA_TIMESTAMP_MAX;
+   } else
+   sb->s_time_max = EXT4_NON_EXTRA_TIMESTAMP_MAX;
+
+   sb->s_time_min = EXT4_TIMESTAMP_MIN;
}
 
sbi->s_desc_size = le16_to_cpu(es->s_desc_size);
-- 
2.7.4

[PATCH v3 3/5] ext4: Initialize timestamps limits

ext4 has different overflow limits for max filesystem
timestamps based on the extra bytes available.

Signed-off-by: Deepa Dinamani 
---
 fs/ext4/ext4.h  | 4 
 fs/ext4/super.c | 7 ++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 2bef0bd..7bac2cd 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -1639,6 +1639,10 @@ static inline void ext4_clear_state_flags(struct 
ext4_inode_info *ei)
 
 #define EXT4_GOOD_OLD_INODE_SIZE 128
 
+#define EXT4_EXTRA_TIMESTAMP_MAX   (((s64)1 << 34) - 1  + S32_MIN)
+#define EXT4_NON_EXTRA_TIMESTAMP_MAX   Y2038_EXPIRY_TIMESTAMP
+#define EXT4_TIMESTAMP_MIN S32_MIN
+
 /*
  * Feature set definitions
  */
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index a673558..a77e11c 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3689,8 +3689,13 @@ static int ext4_fill_super(struct super_block *sb, void 
*data, int silent)
   sbi->s_inode_size);
goto failed_mount;
}
-   if (sbi->s_inode_size > EXT4_GOOD_OLD_INODE_SIZE)
+   if (sbi->s_inode_size > EXT4_GOOD_OLD_INODE_SIZE) {
sb->s_time_gran = 1 << (EXT4_EPOCH_BITS - 2);
+   sb->s_time_max = EXT4_EXTRA_TIMESTAMP_MAX;
+   } else
+   sb->s_time_max = EXT4_NON_EXTRA_TIMESTAMP_MAX;
+
+   sb->s_time_min = EXT4_TIMESTAMP_MIN;
}
 
sbi->s_desc_size = le16_to_cpu(es->s_desc_size);
-- 
2.7.4

[PATCH v3 5/5] utimes: Clamp the timestamps before update

POSIX.1 section for futimens, utimensat and utimes says:
The file's relevant timestamp shall be set to the
greatest value supported by the file system that is
not greater than the specified time.

Clamp the timestamps accordingly before assignment.

Note that the clamp_t macro is used for clamping here as vfs
is not yet using struct timespec64 internally. This is
required for compilation purposes.
Also note that clamp won't do the right thing for timestamps
beyond 2038 on 32-bit machines until the vfs uses timespec64.
After the vfs is transitioned to use timespec64 for timestamps,
clamp_t() can be replaced by clamp().

Signed-off-by: Deepa Dinamani 
---
 fs/utimes.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/fs/utimes.c b/fs/utimes.c
index 32b15b3..052fe5d 100644
--- a/fs/utimes.c
+++ b/fs/utimes.c
@@ -53,6 +53,7 @@ static int utimes_common(const struct path *path, struct 
timespec *times)
int error;
struct iattr newattrs;
struct inode *inode = path->dentry->d_inode;
+   struct super_block *sb = inode->i_sb;
struct inode *delegated_inode = NULL;
 
error = mnt_want_write(path->mnt);
@@ -68,16 +69,24 @@ static int utimes_common(const struct path *path, struct 
timespec *times)
if (times[0].tv_nsec == UTIME_OMIT)
newattrs.ia_valid &= ~ATTR_ATIME;
else if (times[0].tv_nsec != UTIME_NOW) {
-   newattrs.ia_atime.tv_sec = times[0].tv_sec;
-   newattrs.ia_atime.tv_nsec = times[0].tv_nsec;
+   newattrs.ia_atime.tv_sec =
+   clamp_t(time64_t, times[0].tv_sec, 
sb->s_time_min, sb->s_time_max);
+   if (times[0].tv_sec >= sb->s_time_max)
+   newattrs.ia_atime.tv_nsec = 0;
+   else
+   newattrs.ia_atime.tv_nsec = times[0].tv_nsec;
newattrs.ia_valid |= ATTR_ATIME_SET;
}
 
if (times[1].tv_nsec == UTIME_OMIT)
newattrs.ia_valid &= ~ATTR_MTIME;
else if (times[1].tv_nsec != UTIME_NOW) {
-   newattrs.ia_mtime.tv_sec = times[1].tv_sec;
-   newattrs.ia_mtime.tv_nsec = times[1].tv_nsec;
+   newattrs.ia_mtime.tv_sec =
+   clamp_t(time64_t, times[1].tv_sec, 
sb->s_time_min, sb->s_time_max);
+   if (times[1].tv_sec >= sb->s_time_max)
+   newattrs.ia_mtime.tv_nsec = 0;
+   else
+   newattrs.ia_mtime.tv_nsec = times[1].tv_nsec;
newattrs.ia_valid |= ATTR_MTIME_SET;
}
/*
-- 
2.7.4

[PATCH v3 5/5] utimes: Clamp the timestamps before update

POSIX.1 section for futimens, utimensat and utimes says:
The file's relevant timestamp shall be set to the
greatest value supported by the file system that is
not greater than the specified time.

Clamp the timestamps accordingly before assignment.

Note that the clamp_t macro is used for clamping here as vfs
is not yet using struct timespec64 internally. This is
required for compilation purposes.
Also note that clamp won't do the right thing for timestamps
beyond 2038 on 32-bit machines until the vfs uses timespec64.
After the vfs is transitioned to use timespec64 for timestamps,
clamp_t() can be replaced by clamp().

Signed-off-by: Deepa Dinamani 
---
 fs/utimes.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/fs/utimes.c b/fs/utimes.c
index 32b15b3..052fe5d 100644
--- a/fs/utimes.c
+++ b/fs/utimes.c
@@ -53,6 +53,7 @@ static int utimes_common(const struct path *path, struct 
timespec *times)
int error;
struct iattr newattrs;
struct inode *inode = path->dentry->d_inode;
+   struct super_block *sb = inode->i_sb;
struct inode *delegated_inode = NULL;
 
error = mnt_want_write(path->mnt);
@@ -68,16 +69,24 @@ static int utimes_common(const struct path *path, struct 
timespec *times)
if (times[0].tv_nsec == UTIME_OMIT)
newattrs.ia_valid &= ~ATTR_ATIME;
else if (times[0].tv_nsec != UTIME_NOW) {
-   newattrs.ia_atime.tv_sec = times[0].tv_sec;
-   newattrs.ia_atime.tv_nsec = times[0].tv_nsec;
+   newattrs.ia_atime.tv_sec =
+   clamp_t(time64_t, times[0].tv_sec, 
sb->s_time_min, sb->s_time_max);
+   if (times[0].tv_sec >= sb->s_time_max)
+   newattrs.ia_atime.tv_nsec = 0;
+   else
+   newattrs.ia_atime.tv_nsec = times[0].tv_nsec;
newattrs.ia_valid |= ATTR_ATIME_SET;
}
 
if (times[1].tv_nsec == UTIME_OMIT)
newattrs.ia_valid &= ~ATTR_MTIME;
else if (times[1].tv_nsec != UTIME_NOW) {
-   newattrs.ia_mtime.tv_sec = times[1].tv_sec;
-   newattrs.ia_mtime.tv_nsec = times[1].tv_nsec;
+   newattrs.ia_mtime.tv_sec =
+   clamp_t(time64_t, times[1].tv_sec, 
sb->s_time_min, sb->s_time_max);
+   if (times[1].tv_sec >= sb->s_time_max)
+   newattrs.ia_mtime.tv_nsec = 0;
+   else
+   newattrs.ia_mtime.tv_nsec = times[1].tv_nsec;
newattrs.ia_valid |= ATTR_MTIME_SET;
}
/*
-- 
2.7.4

[PATCH v3 0/5] vfs: Add timestamp range check support

The series is aimed at adding timestamp checking and policy
related to it to vfs.

The series was developed with discussions and guidance from
Arnd Bergmann.

The original thread is at https://lkml.org/lkml/2016/11/2/294

Associated test: xfstests generic/402
Note that the above test will be run and will fail all filesystems that
do not have correct limits specified in the xfstests or the kernel or
that don't support times beyond the test dates. I will be submitting a
follow up xfstest and kernel patches to update all filesystems.
Currently ext4 is the only filesystem that reflects correct limits.

The branch is available at
https://github.com/deepa-hub/vfs.git refs/heads/vfs_timestamp_policy

Changes since v2:
* Introduce early boot param override for checks.
* Drop afs patch for timestamp limits.
Changes since v1:
* return EROFS on mount errors
* fix mtime copy/paste error in utimes

Deepa Dinamani (5):
  vfs: Add file timestamp range support
  vfs: Add checks for filesystem timestamp limits
  ext4: Initialize timestamps limits
  vfs: Add timestamp_truncate() api
  utimes: Clamp the timestamps before update

 fs/ext4/ext4.h  |  4 
 fs/ext4/super.c |  7 ++-
 fs/inode.c  | 45 -
 fs/internal.h   |  2 ++
 fs/libfs.c  |  4 
 fs/namespace.c  | 12 
 fs/super.c  |  9 +
 fs/utimes.c | 17 +
 include/linux/fs.h  |  4 
 include/linux/time64.h  |  6 ++
 include/uapi/linux/fs.h |  6 +-
 kernel/sysctl.c |  7 +++
 12 files changed, 116 insertions(+), 7 deletions(-)

-- 
2.7.4

Cc: "Theodore Ts'o" 
Cc: Andreas Dilger 
Cc: linux-e...@vger.kernel.org

[PATCH v3 0/5] vfs: Add timestamp range check support

The series is aimed at adding timestamp checking and policy
related to it to vfs.

The series was developed with discussions and guidance from
Arnd Bergmann.

The original thread is at https://lkml.org/lkml/2016/11/2/294

Associated test: xfstests generic/402
Note that the above test will be run and will fail all filesystems that
do not have correct limits specified in the xfstests or the kernel or
that don't support times beyond the test dates. I will be submitting a
follow up xfstest and kernel patches to update all filesystems.
Currently ext4 is the only filesystem that reflects correct limits.

The branch is available at
https://github.com/deepa-hub/vfs.git refs/heads/vfs_timestamp_policy

Changes since v2:
* Introduce early boot param override for checks.
* Drop afs patch for timestamp limits.
Changes since v1:
* return EROFS on mount errors
* fix mtime copy/paste error in utimes

Deepa Dinamani (5):
  vfs: Add file timestamp range support
  vfs: Add checks for filesystem timestamp limits
  ext4: Initialize timestamps limits
  vfs: Add timestamp_truncate() api
  utimes: Clamp the timestamps before update

 fs/ext4/ext4.h  |  4 
 fs/ext4/super.c |  7 ++-
 fs/inode.c  | 45 -
 fs/internal.h   |  2 ++
 fs/libfs.c  |  4 
 fs/namespace.c  | 12 
 fs/super.c  |  9 +
 fs/utimes.c | 17 +
 include/linux/fs.h  |  4 
 include/linux/time64.h  |  6 ++
 include/uapi/linux/fs.h |  6 +-
 kernel/sysctl.c |  7 +++
 12 files changed, 116 insertions(+), 7 deletions(-)

-- 
2.7.4

Cc: "Theodore Ts'o" 
Cc: Andreas Dilger 
Cc: linux-e...@vger.kernel.org

Re: [clear_page] 0ad07c8104 BUG: unable to handle kernel NULL pointer dereference at 0000000000000040

Hi Borislav,

On Sat, Feb 18, 2017 at 03:48:00PM +0100, Borislav Petkov wrote:

Guys,

please fix the 0day bot reporting. See below for more info.

On Sat, Feb 18, 2017 at 01:01:53PM +0800, Fengguang Wu wrote:

Greetings,

0day kernel testing robot got the below dmesg and the first bad commit is

https://github.com/0day-ci/linux
Borislav-Petkov/x86-Optimize-clear_page/20170210-053052

Can you make this point to the actual commit on github?

Your tree there has currently 47K branches and navigating through the
web interface takes forever.

Good point! I noticed it too while sending out the report. It'll be
showed as this in future:

https://github.com/0day-ci/linux/commits/Borislav-Petkov/x86-Optimize-clear_page/20170210-053052

commit 0ad07c8104eb5c12dfcb86581c1cc657183496cc
Author: Borislav Petkov
AuthorDate: Thu Feb 9 20:51:25 2017 +0100
Commit: 0day robot
CommitDate: Fri Feb 10 05:30:58 2017 +0800

x86: Optimize clear_page()

Currently, we CALL clear_page() which then JMPs to the proper function
chosen by the alternatives.

What we should do instead is CALL the proper function directly. (This
was something Ingo suggested a while ago). So let's do that.

Measuring our favourite kernel build workload shows that there are no
significant changes in performance.

...

Signed-off-by: Borislav Petkov

Then, this is an old patch. You already sent me a bug report, I replied
with a fix but you didn't test the fix. Instead you're sending the same
old report.

Sorry the 2nd report was send out manually and I only checked the
emails in my _current_ mbox. Since the previous report email has been
archived, it slipped through the duplication check.

Here's the fix: https://lists.01.org/pipermail/lkp/2017-February/005573.html

And the upstream submission of the new version:

https://lkml.kernel.org/r/20170215111927.emdgxf2pide3k...@pd.tnic

Please fix the bot to pay attention to replies. If there is a special
way I should reply with a fix so that the bot retests with the same
config, please let me know.

In general, I think it would be a very cool idea to be able to reply to
the bot and say, "Dear bot, can you test this fix ontop with the exact
same guest, vm, kernel .config etc.

That would be lovely.

Yeah we have a TODO to do email based on-demand service, which looks
close to your proposal.

Thanks and keep up the good work!

Thanks,
Fengguang

Re: [clear_page] 0ad07c8104 BUG: unable to handle kernel NULL pointer dereference at 0000000000000040

Hi Borislav,

On Sat, Feb 18, 2017 at 03:48:00PM +0100, Borislav Petkov wrote:

Guys,

please fix the 0day bot reporting. See below for more info.

On Sat, Feb 18, 2017 at 01:01:53PM +0800, Fengguang Wu wrote:

Greetings,

0day kernel testing robot got the below dmesg and the first bad commit is

https://github.com/0day-ci/linux
Borislav-Petkov/x86-Optimize-clear_page/20170210-053052

Can you make this point to the actual commit on github?

Your tree there has currently 47K branches and navigating through the
web interface takes forever.

Good point! I noticed it too while sending out the report. It'll be
showed as this in future:

https://github.com/0day-ci/linux/commits/Borislav-Petkov/x86-Optimize-clear_page/20170210-053052

commit 0ad07c8104eb5c12dfcb86581c1cc657183496cc
Author: Borislav Petkov
AuthorDate: Thu Feb 9 20:51:25 2017 +0100
Commit: 0day robot
CommitDate: Fri Feb 10 05:30:58 2017 +0800

x86: Optimize clear_page()

Currently, we CALL clear_page() which then JMPs to the proper function
chosen by the alternatives.

What we should do instead is CALL the proper function directly. (This
was something Ingo suggested a while ago). So let's do that.

Measuring our favourite kernel build workload shows that there are no
significant changes in performance.

...

Signed-off-by: Borislav Petkov

Then, this is an old patch. You already sent me a bug report, I replied
with a fix but you didn't test the fix. Instead you're sending the same
old report.

Sorry the 2nd report was send out manually and I only checked the
emails in my _current_ mbox. Since the previous report email has been
archived, it slipped through the duplication check.

Here's the fix: https://lists.01.org/pipermail/lkp/2017-February/005573.html

And the upstream submission of the new version:

https://lkml.kernel.org/r/20170215111927.emdgxf2pide3k...@pd.tnic

Please fix the bot to pay attention to replies. If there is a special
way I should reply with a fix so that the bot retests with the same
config, please let me know.

In general, I think it would be a very cool idea to be able to reply to
the bot and say, "Dear bot, can you test this fix ontop with the exact
same guest, vm, kernel .config etc.

That would be lovely.

Yeah we have a TODO to do email based on-demand service, which looks
close to your proposal.

Thanks and keep up the good work!

Thanks,
Fengguang

[PATCH v3 4/5] vfs: Add timestamp_truncate() api

timespec_trunc() function is used to truncate a
filesystem timestamp to the right granularity.
But, the function does not clamp tv_sec part of the
timestamps according to the filesystem timestamp limits.

Also, timespec_trunc() is exclusively used for filesystem
timestamps. Move the api to be part of vfs.

The replacement api: timestamp_truncate() also alters the
signature of the function to accommodate filesystem
timestamp clamping according to flesystem limits.

Note that the clamp_t macro is used for clamping here as vfs
is not yet using struct timespec64 internally. This is
required for compilation purposes.
Also note that clamp won't do the right thing for timestamps
beyond 2038 on 32-bit machines until the vfs uses timespec64.
After the vfs is transitioned to use timespec64 for timestamps,
clamp_t() can be replaced by clamp().

Signed-off-by: Deepa Dinamani 
---
 fs/inode.c | 32 +++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/fs/inode.c b/fs/inode.c
index 0573a3e..6a1bc12 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -2114,6 +2114,36 @@ void inode_nohighmem(struct inode *inode)
 EXPORT_SYMBOL(inode_nohighmem);
 
 /**
+ * fs_timespec_trunc - Truncate timespec to a granularity
+ * @t: Timespec
+ * @gran: Granularity in ns.
+ *
+ * Truncate a timespec to a granularity. Always rounds down. gran must
+ * not be 0 nor greater than a second (NSEC_PER_SEC, or 10^9 ns).
+ */
+struct timespec timestamp_truncate(struct timespec t, struct inode *inode)
+{
+   struct super_block *sb = inode->i_sb;
+   unsigned int gran = sb->s_time_gran;
+
+   t.tv_sec = clamp_t(time64_t, t.tv_sec, sb->s_time_min, sb->s_time_max);
+
+   /* Avoid division in the common cases 1 ns and 1 s. */
+   if (gran == 1) {
+   /* nothing */
+   } else if (gran == NSEC_PER_SEC) {
+   t.tv_nsec = 0;
+   } else if (gran > 1 && gran < NSEC_PER_SEC) {
+   t.tv_nsec -= t.tv_nsec % gran;
+   } else {
+   WARN(1, "illegal file time granularity: %u", gran);
+   }
+   return t;
+}
+EXPORT_SYMBOL(timestamp_truncate);
+
+
+/**
  * current_time - Return FS time
  * @inode: inode.
  *
@@ -2132,6 +2162,6 @@ struct timespec current_time(struct inode *inode)
return now;
}
 
-   return timespec_trunc(now, inode->i_sb->s_time_gran);
+   return timestamp_truncate(now, inode);
 }
 EXPORT_SYMBOL(current_time);
-- 
2.7.4

[PATCH v3 4/5] vfs: Add timestamp_truncate() api

timespec_trunc() function is used to truncate a
filesystem timestamp to the right granularity.
But, the function does not clamp tv_sec part of the
timestamps according to the filesystem timestamp limits.

Also, timespec_trunc() is exclusively used for filesystem
timestamps. Move the api to be part of vfs.

The replacement api: timestamp_truncate() also alters the
signature of the function to accommodate filesystem
timestamp clamping according to flesystem limits.

Note that the clamp_t macro is used for clamping here as vfs
is not yet using struct timespec64 internally. This is
required for compilation purposes.
Also note that clamp won't do the right thing for timestamps
beyond 2038 on 32-bit machines until the vfs uses timespec64.
After the vfs is transitioned to use timespec64 for timestamps,
clamp_t() can be replaced by clamp().

Signed-off-by: Deepa Dinamani 
---
 fs/inode.c | 32 +++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/fs/inode.c b/fs/inode.c
index 0573a3e..6a1bc12 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -2114,6 +2114,36 @@ void inode_nohighmem(struct inode *inode)
 EXPORT_SYMBOL(inode_nohighmem);
 
 /**
+ * fs_timespec_trunc - Truncate timespec to a granularity
+ * @t: Timespec
+ * @gran: Granularity in ns.
+ *
+ * Truncate a timespec to a granularity. Always rounds down. gran must
+ * not be 0 nor greater than a second (NSEC_PER_SEC, or 10^9 ns).
+ */
+struct timespec timestamp_truncate(struct timespec t, struct inode *inode)
+{
+   struct super_block *sb = inode->i_sb;
+   unsigned int gran = sb->s_time_gran;
+
+   t.tv_sec = clamp_t(time64_t, t.tv_sec, sb->s_time_min, sb->s_time_max);
+
+   /* Avoid division in the common cases 1 ns and 1 s. */
+   if (gran == 1) {
+   /* nothing */
+   } else if (gran == NSEC_PER_SEC) {
+   t.tv_nsec = 0;
+   } else if (gran > 1 && gran < NSEC_PER_SEC) {
+   t.tv_nsec -= t.tv_nsec % gran;
+   } else {
+   WARN(1, "illegal file time granularity: %u", gran);
+   }
+   return t;
+}
+EXPORT_SYMBOL(timestamp_truncate);
+
+
+/**
  * current_time - Return FS time
  * @inode: inode.
  *
@@ -2132,6 +2162,6 @@ struct timespec current_time(struct inode *inode)
return now;
}
 
-   return timespec_trunc(now, inode->i_sb->s_time_gran);
+   return timestamp_truncate(now, inode);
 }
 EXPORT_SYMBOL(current_time);
-- 
2.7.4

Re: [PATCH] btmrvl: fix spelling mistake: "actived" -> "activated"

2017-02-18 Thread Marcel Holtmann

Hi Colin,

> trivial fix to spelling mistake in error message
> 
> Signed-off-by: Colin Ian King 
> ---
> drivers/bluetooth/btmrvl_sdio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)

patch has been applied to bluetooth-next tree.

Regards

Marcel

Re: [PATCH] btmrvl: fix spelling mistake: "actived" -> "activated"

2017-02-18 Thread Marcel Holtmann

Hi Colin,

> trivial fix to spelling mistake in error message
> 
> Signed-off-by: Colin Ian King 
> ---
> drivers/bluetooth/btmrvl_sdio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)

patch has been applied to bluetooth-next tree.

Regards

Marcel

Re: g_NCR5380 PDMA, was Re: [PATCH 0/6] ncr5380: Miscellaneous minor patches

2017-02-18 Thread Finn Thain


On Sat, 18 Feb 2017, Ondrej Zary wrote:

> On Friday 17 February 2017 23:38:12 Finn Thain wrote:
> > On Thu, 16 Feb 2017, Ondrej Zary wrote:
> > > On Tuesday 31 January 2017 02:31:45 Finn Thain wrote:
> > > [...]
> > >
> > > > Are you trying to figure out which commands are going to 
> > > > disconnect during a transfer? This is really a function of the 
> > > > firmware in the target; there are no good heuristics AFAICT, so 
> > > > the PDMA algorithm has to be robust. mac_scsi has to cope with 
> > > > this too.
> > > >
> > > > Does the problem go away when you assign no IRQ? When 
> > > > instance->irq == NO_IRQ, the core driver will inhibit disconnect 
> > > > privileges.
> > >
> > > Yes, it seems to run fine with IRQ/disconnect disabled. With IRQ 
> > > enabled, "dd if=/dev/sr0 of=anything" stops after a while.
> >
> > When you say "stops", do you mean an infinite loop in 
> > generic_NCR5380_pread or does the loop complete (which would 
> > presumably leave the target stuck in DATA IN phase, and a scsi command 
> > timeout would probably follow after 30 seconds...)
> 
> I've added timeouts to the possibly-infinite loops. It times out waiting 
> for the host buffer to become ready.

In mac_scsi you'll find that the PDMA loop exploits the 15ms poll_politely 
time limit to give the target device time to catch up. You might want to 
do something similar.

> Then everything breaks. Now I found why: pread() returns without waiting 
> for the 53C80 registers to be ready.

Ouch! You can't return control to the core driver when the 53C80 core is 
unavailable. That would need special handling: the core driver would have 
to fail the scsi command and reset the device (and bus), based on the 
result you return from NCR5380_dma_recv_setup/NCR5380_dma_send_setup.

> Adding the wait allows to continue in PIO mode with "tag#0 switching to 
> slow handshake".
> 

I don't think this is the code path you want. The target isn't really 
broken. But yes, we could use PIO as a slow workaround for fragile PDMA 
logic.

> > > I get gated 53C80 IRQ, BASR=0x10, MODE=0x0e, STATUS=0x7c.
> >
> > You can use NCR5380_print() to get a decoded register dump.
> >
> > When I decode the above values I get,
> >
> > BASR   = 0x10 = BASR_IRQ
> > MODE   = 0x0e = MR_ENABLE_EOP_INTR | MR_MONITOR_BSY | MR_DMA_MODE
> > STATUS = 0x7c = SR_BSY | SR_REQ | SR_MSG | SR_CD | SR_IO
> >
> > Since BASR_PHASE_MATCH is not set, the interrupt is almost certainly a 
> > phase mismatch. The new phase is SR_MSG | SR_CD | SR_IO = PHASE_MSGIN, 
> > which shows that the target has given up on the DATA IN phase and is 
> > presumably trying to send a DISCONNECT message.
> 
> Looks you're right. The transfersize is 4096, i.e. 2 CD-ROM sectors. 
> When the 2nd sector is not ready in the drive internal buffer, the drive 
> probably disconnects which breaks the fragile pdma transfer. When the 
> transfersize is limited to 2048 bytes, the problem goes away.
> 

OK.

> The problem also went away with enabled interrupts because I had some 
> debug printks added which were slowing down the transfer enough for the 
> drive (SONY CDU-55S) to keep up and not disconnect. Got the same result 
> by inserting udelay(100) after each 128 byte block trasnferred in 
> pread().
> 

Well, yeah, if you change the timing and omit to mention that, as well as 
changing the spinlock_irq_save/restore pairs, then it's going to be 
difficult for me to make sense of your results. Anyway, I'm glad that you 
got to the bottom of this mystery.

> > > When I enable interrupts during PDMA (like the removed UNSAFE macro 
> > > did), the problems go away. I see an IRQ after each pread call.
> >

--

Re: g_NCR5380 PDMA, was Re: [PATCH 0/6] ncr5380: Miscellaneous minor patches

2017-02-18 Thread Finn Thain


On Sat, 18 Feb 2017, Ondrej Zary wrote:

> On Friday 17 February 2017 23:38:12 Finn Thain wrote:
> > On Thu, 16 Feb 2017, Ondrej Zary wrote:
> > > On Tuesday 31 January 2017 02:31:45 Finn Thain wrote:
> > > [...]
> > >
> > > > Are you trying to figure out which commands are going to 
> > > > disconnect during a transfer? This is really a function of the 
> > > > firmware in the target; there are no good heuristics AFAICT, so 
> > > > the PDMA algorithm has to be robust. mac_scsi has to cope with 
> > > > this too.
> > > >
> > > > Does the problem go away when you assign no IRQ? When 
> > > > instance->irq == NO_IRQ, the core driver will inhibit disconnect 
> > > > privileges.
> > >
> > > Yes, it seems to run fine with IRQ/disconnect disabled. With IRQ 
> > > enabled, "dd if=/dev/sr0 of=anything" stops after a while.
> >
> > When you say "stops", do you mean an infinite loop in 
> > generic_NCR5380_pread or does the loop complete (which would 
> > presumably leave the target stuck in DATA IN phase, and a scsi command 
> > timeout would probably follow after 30 seconds...)
> 
> I've added timeouts to the possibly-infinite loops. It times out waiting 
> for the host buffer to become ready.

In mac_scsi you'll find that the PDMA loop exploits the 15ms poll_politely 
time limit to give the target device time to catch up. You might want to 
do something similar.

> Then everything breaks. Now I found why: pread() returns without waiting 
> for the 53C80 registers to be ready.

Ouch! You can't return control to the core driver when the 53C80 core is 
unavailable. That would need special handling: the core driver would have 
to fail the scsi command and reset the device (and bus), based on the 
result you return from NCR5380_dma_recv_setup/NCR5380_dma_send_setup.

> Adding the wait allows to continue in PIO mode with "tag#0 switching to 
> slow handshake".
> 

I don't think this is the code path you want. The target isn't really 
broken. But yes, we could use PIO as a slow workaround for fragile PDMA 
logic.

> > > I get gated 53C80 IRQ, BASR=0x10, MODE=0x0e, STATUS=0x7c.
> >
> > You can use NCR5380_print() to get a decoded register dump.
> >
> > When I decode the above values I get,
> >
> > BASR   = 0x10 = BASR_IRQ
> > MODE   = 0x0e = MR_ENABLE_EOP_INTR | MR_MONITOR_BSY | MR_DMA_MODE
> > STATUS = 0x7c = SR_BSY | SR_REQ | SR_MSG | SR_CD | SR_IO
> >
> > Since BASR_PHASE_MATCH is not set, the interrupt is almost certainly a 
> > phase mismatch. The new phase is SR_MSG | SR_CD | SR_IO = PHASE_MSGIN, 
> > which shows that the target has given up on the DATA IN phase and is 
> > presumably trying to send a DISCONNECT message.
> 
> Looks you're right. The transfersize is 4096, i.e. 2 CD-ROM sectors. 
> When the 2nd sector is not ready in the drive internal buffer, the drive 
> probably disconnects which breaks the fragile pdma transfer. When the 
> transfersize is limited to 2048 bytes, the problem goes away.
> 

OK.

> The problem also went away with enabled interrupts because I had some 
> debug printks added which were slowing down the transfer enough for the 
> drive (SONY CDU-55S) to keep up and not disconnect. Got the same result 
> by inserting udelay(100) after each 128 byte block trasnferred in 
> pread().
> 

Well, yeah, if you change the timing and omit to mention that, as well as 
changing the spinlock_irq_save/restore pairs, then it's going to be 
difficult for me to make sense of your results. Anyway, I'm glad that you 
got to the bottom of this mystery.

> > > When I enable interrupts during PDMA (like the removed UNSAFE macro 
> > > did), the problems go away. I see an IRQ after each pread call.
> >

--

Re: [PATCH] arm64: dts: hisilicon: add dts files for hi3798cv200-poplar board

Hi Jiancheng,

Am 09.02.2017 um 08:07 schrieb Jiancheng Xue:
> Add basic dts files for hi3798cv200-poplar board. Poplar is the
> first development board compliant with the 96Boards Enterprise
> Edition TV Platform specification. The board features the
> Hi3798CV200 with an integrated quad-core 64-bit ARM Cortex A53
> processor and high performance Mali T720 GPU.
> 
> Signed-off-by: Jiancheng Xue 
> Reviewed-by: Alex Elder 

Thanks for this patch! Some comments below. Do you have instructions for
how to test? In my tries I so far only got resets like for example:

fastboot# bootm 0x0100 - 0x2000
## Booting kernel from Legacy Image at 0100 ...
   Image Name:   linux-next
   Image Type:   AArch64 Linux Kernel Image (uncompressed)
   Data Size:8741376 Bytes = 8.3 MiB
   Load Address: 0200
   Entry Point:  0200
## Flattened Device Tree blob at 2000
   Booting using the fdt blob at 0x2000
   Loading Kernel Image from 0x16777280 to 0x33554432 ... OK
OK

Starting kernel ...


*** irq: undefined instruction
undefined instruction
pc : [<61d3>]  lr : [<00c661ec>]
sp : 00bfffb8  ip : 0036 fp : 
r10:   r9 :  r8 : 
r7 : 0080  r6 : 005fffc4 r5 : f36e6f75  r4 : 
r3 : 001e  r2 : 0100 r1 :   r0 : 
Flags: nzcv  IRQs off  FIQs off  Mode UK12_32
Resetting CPU ...

resetting ...

Does U-Boot need to be updated for this to work?

> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt 
> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
> index 7df79a7..7d90bf1 100644
> --- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
> @@ -1,5 +1,9 @@
>  Hisilicon Platforms Device Tree Bindings
>  
> +Hi3798cv200 Poplar Board
> +Required root node properties:
> + - compatible = "hisilicon,hi3798cv200-poplar", "hisilicon,hi3798cv200";
> +

Shouldn't this rather be "tocoding,poplar", "hisilicon,hi3798cv200"?

linux-next.git already has Hi3660 here, so you'll need to rebase.

Also, theoretically bindings documentation should be in a separate,
preceding patch.

>  Hi4511 Board
>  Required root node properties:
>   - compatible = "hisilicon,hi3620-hi4511";
> diff --git a/arch/arm64/boot/dts/hisilicon/Makefile 
> b/arch/arm64/boot/dts/hisilicon/Makefile
> index c8b8f80..96202fe 100644
> --- a/arch/arm64/boot/dts/hisilicon/Makefile
> +++ b/arch/arm64/boot/dts/hisilicon/Makefile
> @@ -2,6 +2,7 @@ dtb-$(CONFIG_ARCH_HISI) += hi6220-hikey.dtb
>  dtb-$(CONFIG_ARCH_HISI) += hip05-d02.dtb
>  dtb-$(CONFIG_ARCH_HISI) += hip06-d03.dtb
>  dtb-$(CONFIG_ARCH_HISI) += hip07-d05.dtb
> +dtb-$(CONFIG_ARCH_HISI) += hi3798cv200-poplar.dtb

Please keep this sorted alphabetically.

>  
>  always   := $(dtb-y)
>  subdir-y := $(dts-dirs)
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts 
> b/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
> new file mode 100644
> index 000..4e2b1d1
> --- /dev/null
> +++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
> @@ -0,0 +1,169 @@
> +/*
> + * DTS File for HiSilicon Poplar Development Board
> + *
> + * Copyright (c) 2016-2017 HiSilicon Technologies Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see .
> + */
> +
> +/dts-v1/;
> +
> +#include 
> +#include "hi3798cv200.dtsi"
> +
> +/ {
> + model = "HiSilicon Poplar Development Board";

Ditto: HiSilicon?

> + compatible = "hisilicon,hi3798cv200-poplar", "hisilicon,hi3798cv200";
> +
> + aliases {
> + serial0 = 
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x0 0x 0x 0x8000>;

First one has one zero too much.

> + };
> +
> + soc {
[...]
> + };
> +};
> +
> + {
> + status = "ok";

I believe the canonical form is "okay".

> +};
> +
> + {
> + status = "ok";
> + label = "LS-UART0";
> +};
> +/* No optional LS-UART1 on Low Speed Expansion Connector. */
> +
> + {
> + status = "ok";
> + label = "LS-I2C0";
> +};
> +
> + {
> + status = "ok";
> +

Re: [PATCH] arm64: dts: hisilicon: add dts files for hi3798cv200-poplar board