[PATCH v4 2/3] KVM: add converters between pfn_t and kvm_pfn_t

[Haozhong Zhang]

Signed-off-by: Haozhong Zhang 
---
 include/linux/kvm_host.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 6882538eda32..caf6f7a6bdb2 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -67,6 +68,9 @@
 #define KVM_PFN_ERR_HWPOISON   (KVM_PFN_ERR_MASK + 1)
 #define KVM_PFN_ERR_RO_FAULT   (KVM_PFN_ERR_MASK + 2)
 
+#define pfn_t_to_kvm_pfn_t(x)  pfn_t_to_pfn(x)
+#define kvm_pfn_t_to_pfn_t(x)  pfn_to_pfn_t((x) & ~KVM_PFN_ERR_NOSLOT_MASK)
+
 /*
  * error pfns indicate that the gfn is in slot but faild to
  * translate it to pfn on host.
-- 
2.14.1

[PATCH v4 3/3] KVM: MMU: consider host cache mode in MMIO page check

[Haozhong Zhang]

Some reserved pages, such as those from NVDIMM DAX devices, are
not for MMIO, and can be mapped with cached memory type for better
performance. However, the above check misconceives those pages as
MMIO.  Because KVM maps MMIO pages with UC memory type, the
performance of guest accesses to those pages would be harmed.
Therefore, we check the host memory type by lookup_memtype() in
addition and only treat UC/UC- pages as MMIO.

Signed-off-by: Haozhong Zhang 
Reported-by: Cuevas Escareno, Ivan D 
Reported-by: Kumar, Karthik 
---
 arch/x86/kvm/mmu.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 0b481cc9c725..e9ed0e666a83 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2708,7 +2708,24 @@ static bool mmu_need_write_protect(struct kvm_vcpu 
*vcpu, gfn_t gfn,
 static bool kvm_is_mmio_pfn(kvm_pfn_t pfn)
 {
if (pfn_valid(pfn))
-   return !is_zero_pfn(pfn) && PageReserved(pfn_to_page(pfn));
+   return !is_zero_pfn(pfn) && PageReserved(pfn_to_page(pfn)) &&
+   /*
+* Some reserved pages, such as those from
+* NVDIMM DAX devices, are not for MMIO, and
+* can be mapped with cached memory type for
+* better performance. However, the above
+* check misconceives those pages as MMIO.
+* Because KVM maps MMIO pages with UC memory
+* type, the performance of guest accesses to
+* those pages would be harmed. Therefore, we
+* check the host memory type in addition and
+* only treat UC/UC- pages as MMIO.
+*
+* pat_pfn_is_uc() works only when PAT is enabled,
+* so check pat_enabled() as well.
+*/
+   (!pat_enabled() ||
+pat_pfn_is_uc(kvm_pfn_t_to_pfn_t(pfn)));
 
return true;
 }
-- 
2.14.1

[PATCH v4 2/3] KVM: add converters between pfn_t and kvm_pfn_t

[Haozhong Zhang]

Signed-off-by: Haozhong Zhang 
---
 include/linux/kvm_host.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 6882538eda32..caf6f7a6bdb2 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -67,6 +68,9 @@
 #define KVM_PFN_ERR_HWPOISON   (KVM_PFN_ERR_MASK + 1)
 #define KVM_PFN_ERR_RO_FAULT   (KVM_PFN_ERR_MASK + 2)
 
+#define pfn_t_to_kvm_pfn_t(x)  pfn_t_to_pfn(x)
+#define kvm_pfn_t_to_pfn_t(x)  pfn_to_pfn_t((x) & ~KVM_PFN_ERR_NOSLOT_MASK)
+
 /*
  * error pfns indicate that the gfn is in slot but faild to
  * translate it to pfn on host.
-- 
2.14.1

[PATCH v4 3/3] KVM: MMU: consider host cache mode in MMIO page check

[Haozhong Zhang]

Some reserved pages, such as those from NVDIMM DAX devices, are
not for MMIO, and can be mapped with cached memory type for better
performance. However, the above check misconceives those pages as
MMIO.  Because KVM maps MMIO pages with UC memory type, the
performance of guest accesses to those pages would be harmed.
Therefore, we check the host memory type by lookup_memtype() in
addition and only treat UC/UC- pages as MMIO.

Signed-off-by: Haozhong Zhang 
Reported-by: Cuevas Escareno, Ivan D 
Reported-by: Kumar, Karthik 
---
 arch/x86/kvm/mmu.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 0b481cc9c725..e9ed0e666a83 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2708,7 +2708,24 @@ static bool mmu_need_write_protect(struct kvm_vcpu 
*vcpu, gfn_t gfn,
 static bool kvm_is_mmio_pfn(kvm_pfn_t pfn)
 {
if (pfn_valid(pfn))
-   return !is_zero_pfn(pfn) && PageReserved(pfn_to_page(pfn));
+   return !is_zero_pfn(pfn) && PageReserved(pfn_to_page(pfn)) &&
+   /*
+* Some reserved pages, such as those from
+* NVDIMM DAX devices, are not for MMIO, and
+* can be mapped with cached memory type for
+* better performance. However, the above
+* check misconceives those pages as MMIO.
+* Because KVM maps MMIO pages with UC memory
+* type, the performance of guest accesses to
+* those pages would be harmed. Therefore, we
+* check the host memory type in addition and
+* only treat UC/UC- pages as MMIO.
+*
+* pat_pfn_is_uc() works only when PAT is enabled,
+* so check pat_enabled() as well.
+*/
+   (!pat_enabled() ||
+pat_pfn_is_uc(kvm_pfn_t_to_pfn_t(pfn)));
 
return true;
 }
-- 
2.14.1

[PATCH v4 1/3] x86/mm: add function to check if a pfn is UC/UC-

[Haozhong Zhang]

pat_pfn_is_uc(pfn) is added and will be used by KVM to check whether
the memory type of a host pfn is UC/UC-.

Signed-off-by: Haozhong Zhang 
---
 arch/x86/include/asm/pat.h |  2 ++
 arch/x86/mm/pat.c  | 14 ++
 2 files changed, 16 insertions(+)

diff --git a/arch/x86/include/asm/pat.h b/arch/x86/include/asm/pat.h
index fffb2794dd89..4027d9fb10a8 100644
--- a/arch/x86/include/asm/pat.h
+++ b/arch/x86/include/asm/pat.h
@@ -21,4 +21,6 @@ int io_reserve_memtype(resource_size_t start, resource_size_t 
end,
 
 void io_free_memtype(resource_size_t start, resource_size_t end);
 
+bool pat_pfn_is_uc(pfn_t pfn);
+
 #endif /* _ASM_X86_PAT_H */
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index fe7d57a8fb60..71fe9c29727e 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -677,6 +677,20 @@ static enum page_cache_mode lookup_memtype(u64 paddr)
return rettype;
 }
 
+/**
+ * Check whether the memory type of a pfn is UC or UC-. The result is
+ * valid only when PAT is enabled.
+ *
+ * Returns true if it is; otherwise, returns false.
+ */
+bool pat_pfn_is_uc(pfn_t pfn)
+{
+   enum page_cache_mode cm = lookup_memtype(pfn_t_to_phys(pfn));
+
+   return cm == _PAGE_CACHE_MODE_UC || cm == _PAGE_CACHE_MODE_UC_MINUS;
+}
+EXPORT_SYMBOL_GPL(pat_pfn_is_uc);
+
 /**
  * io_reserve_memtype - Request a memory type mapping for a region of memory
  * @start: start (physical address) of the region
-- 
2.14.1

[PATCH v4 0/3] KVM: MMU: fix kvm_is_mmio_pfn()

[Haozhong Zhang]

Some reserved pages, such as those from NVDIMM DAX devices, are
not for MMIO, and can be mapped with cached memory type for better
performance. However, the above check misconceives those pages as
MMIO.  Because KVM maps MMIO pages with UC memory type, the
performance of guest accesses to those pages would be harmed.
Therefore, we check the host memory type by lookup_memtype() in
addition and only treat UC/UC- pages as MMIO.


Changes in v4:
 * Mask pfn_t and kvm_pfn_t specific flags in conversion.

Changes in v3:
 * Move cache mode check to pat.c as pat_pfn_is_uc()
 * Reintroduce converters between kvm_pfn_t and pfn_t.

Changes in v2:
 * Switch to lookup_memtype() to get host memory type.
 * Rewrite the comment in KVM MMU patch.
 * Remove v1 patch 2, which is not necessary in v2.


Haozhong Zhang (3):
  x86/mm: add function to check if a pfn is UC/UC-
  KVM: add converters between pfn_t and kvm_pfn_t
  KVM: MMU: consider host cache mode in MMIO page check

 arch/x86/include/asm/pat.h |  2 ++
 arch/x86/kvm/mmu.c | 19 ++-
 arch/x86/mm/pat.c  | 14 ++
 include/linux/kvm_host.h   |  4 
 4 files changed, 38 insertions(+), 1 deletion(-)

-- 
2.14.1

[PATCH v4 1/3] x86/mm: add function to check if a pfn is UC/UC-

[Haozhong Zhang]

pat_pfn_is_uc(pfn) is added and will be used by KVM to check whether
the memory type of a host pfn is UC/UC-.

Signed-off-by: Haozhong Zhang 
---
 arch/x86/include/asm/pat.h |  2 ++
 arch/x86/mm/pat.c  | 14 ++
 2 files changed, 16 insertions(+)

diff --git a/arch/x86/include/asm/pat.h b/arch/x86/include/asm/pat.h
index fffb2794dd89..4027d9fb10a8 100644
--- a/arch/x86/include/asm/pat.h
+++ b/arch/x86/include/asm/pat.h
@@ -21,4 +21,6 @@ int io_reserve_memtype(resource_size_t start, resource_size_t 
end,
 
 void io_free_memtype(resource_size_t start, resource_size_t end);
 
+bool pat_pfn_is_uc(pfn_t pfn);
+
 #endif /* _ASM_X86_PAT_H */
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index fe7d57a8fb60..71fe9c29727e 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -677,6 +677,20 @@ static enum page_cache_mode lookup_memtype(u64 paddr)
return rettype;
 }
 
+/**
+ * Check whether the memory type of a pfn is UC or UC-. The result is
+ * valid only when PAT is enabled.
+ *
+ * Returns true if it is; otherwise, returns false.
+ */
+bool pat_pfn_is_uc(pfn_t pfn)
+{
+   enum page_cache_mode cm = lookup_memtype(pfn_t_to_phys(pfn));
+
+   return cm == _PAGE_CACHE_MODE_UC || cm == _PAGE_CACHE_MODE_UC_MINUS;
+}
+EXPORT_SYMBOL_GPL(pat_pfn_is_uc);
+
 /**
  * io_reserve_memtype - Request a memory type mapping for a region of memory
  * @start: start (physical address) of the region
-- 
2.14.1

[PATCH v4 0/3] KVM: MMU: fix kvm_is_mmio_pfn()

[Haozhong Zhang]

Some reserved pages, such as those from NVDIMM DAX devices, are
not for MMIO, and can be mapped with cached memory type for better
performance. However, the above check misconceives those pages as
MMIO.  Because KVM maps MMIO pages with UC memory type, the
performance of guest accesses to those pages would be harmed.
Therefore, we check the host memory type by lookup_memtype() in
addition and only treat UC/UC- pages as MMIO.


Changes in v4:
 * Mask pfn_t and kvm_pfn_t specific flags in conversion.

Changes in v3:
 * Move cache mode check to pat.c as pat_pfn_is_uc()
 * Reintroduce converters between kvm_pfn_t and pfn_t.

Changes in v2:
 * Switch to lookup_memtype() to get host memory type.
 * Rewrite the comment in KVM MMU patch.
 * Remove v1 patch 2, which is not necessary in v2.


Haozhong Zhang (3):
  x86/mm: add function to check if a pfn is UC/UC-
  KVM: add converters between pfn_t and kvm_pfn_t
  KVM: MMU: consider host cache mode in MMIO page check

 arch/x86/include/asm/pat.h |  2 ++
 arch/x86/kvm/mmu.c | 19 ++-
 arch/x86/mm/pat.c  | 14 ++
 include/linux/kvm_host.h   |  4 
 4 files changed, 38 insertions(+), 1 deletion(-)

-- 
2.14.1

Re: [f2fs-dev] [PATCH 2/2] f2fs: support quota sys files

[Chao Yu]

On 2017/11/3 11:37, Jaegeuk Kim wrote:
> On 11/02, Chao Yu wrote:
>> On 2017/10/31 11:40, Jaegeuk Kim wrote:
>>> This patch supports hidden quota files in the system, which will be used for
>>> Android. It requires up-to-date f2fs-tools later than v1.9.0.
>>>
>>> Signed-off-by: Jaegeuk Kim 
>>> ---
>>>  fs/f2fs/checkpoint.c |   9 +++-
>>>  fs/f2fs/f2fs.h   |   9 +++-
>>>  fs/f2fs/recovery.c   |   8 ++-
>>>  fs/f2fs/super.c  | 145 
>>> ++-
>>>  4 files changed, 153 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
>>> index 6b52d4b66c7b..78e1b2998bbd 100644
>>> --- a/fs/f2fs/checkpoint.c
>>> +++ b/fs/f2fs/checkpoint.c
>>> @@ -615,6 +615,9 @@ int recover_orphan_inodes(struct f2fs_sb_info *sbi)
>>> block_t start_blk, orphan_blocks, i, j;
>>> unsigned int s_flags = sbi->sb->s_flags;
>>> int err = 0;
>>> +#ifdef CONFIG_QUOTA
>>> +   int quota_enabled;
>>> +#endif
>>>  
>>> if (!is_set_ckpt_flags(sbi, CP_ORPHAN_PRESENT_FLAG))
>>> return 0;
>>> @@ -627,8 +630,9 @@ int recover_orphan_inodes(struct f2fs_sb_info *sbi)
>>>  #ifdef CONFIG_QUOTA
>>> /* Needed for iput() to work correctly and not trash data */
>>> sbi->sb->s_flags |= MS_ACTIVE;
>>> +
>>> /* Turn on quotas so that they are updated correctly */
>>> -   f2fs_enable_quota_files(sbi);
>>> +   quota_enabled = f2fs_enable_quota_files(sbi, s_flags & MS_RDONLY);
>>>  #endif
>>>  
>>> start_blk = __start_cp_addr(sbi) + 1 + __cp_payload(sbi);
>>> @@ -656,7 +660,8 @@ int recover_orphan_inodes(struct f2fs_sb_info *sbi)
>>>  out:
>>>  #ifdef CONFIG_QUOTA
>>> /* Turn quotas off */
>>> -   f2fs_quota_off_umount(sbi->sb);
>>> +   if (quota_enabled)
>>> +   f2fs_quota_off_umount(sbi->sb);
>>>  #endif
>>> sbi->sb->s_flags = s_flags; /* Restore MS_RDONLY status */
>>>  
>>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
>>> index 9a1c7ffa6845..e1d3a940d9f8 100644
>>> --- a/fs/f2fs/f2fs.h
>>> +++ b/fs/f2fs/f2fs.h
>>> @@ -1384,6 +1384,13 @@ static inline unsigned long long 
>>> cur_cp_version(struct f2fs_checkpoint *cp)
>>> return le64_to_cpu(cp->checkpoint_ver);
>>>  }
>>>  
>>> +static inline unsigned long f2fs_qf_ino(struct super_block *sb, int type)
>>> +{
>>> +   if (type < F2FS_QUOTA_INO)
>>
>> Why not just use F2FS_MAX_QUOTAS instead of F2FS_QUOTA_INO? since in patch 
>> 1/2
>> we have defined qf_ino array with upper-boundary F2FS_MAX_QUOTAS.
> 
> It was intended to indicate # of enabled quotas. ;)

Alright, so how about renaming it to F2FS_ENABLED_QUOTA_INO... :)

Thanks,

> 
>>
>>  __le32 qf_ino[F2FS_MAX_QUOTAS]; /* quota inode numbers */
>>
>> Other part looks good to me. ;)
>>
>> Reviewed-by: Chao Yu 
>>
>> Thanks,
>>
>>> +   return le32_to_cpu(F2FS_SB(sb)->raw_super->qf_ino[type]);
>>> +   return 0;
>>> +}
>>> +
>>>  static inline __u64 cur_cp_crc(struct f2fs_checkpoint *cp)
>>>  {
>>> size_t crc_offset = le32_to_cpu(cp->checksum_offset);
>>> @@ -2526,7 +2533,7 @@ static inline int f2fs_add_link(struct dentry 
>>> *dentry, struct inode *inode)
>>>   */
>>>  int f2fs_inode_dirtied(struct inode *inode, bool sync);
>>>  void f2fs_inode_synced(struct inode *inode);
>>> -void f2fs_enable_quota_files(struct f2fs_sb_info *sbi);
>>> +int f2fs_enable_quota_files(struct f2fs_sb_info *sbi, bool rdonly);
>>>  void f2fs_quota_off_umount(struct super_block *sb);
>>>  int f2fs_commit_super(struct f2fs_sb_info *sbi, bool recover);
>>>  int f2fs_sync_fs(struct super_block *sb, int sync);
>>> diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
>>> index 9626758bc762..92c57ace1939 100644
>>> --- a/fs/f2fs/recovery.c
>>> +++ b/fs/f2fs/recovery.c
>>> @@ -594,6 +594,9 @@ int recover_fsync_data(struct f2fs_sb_info *sbi, bool 
>>> check_only)
>>> int ret = 0;
>>> unsigned long s_flags = sbi->sb->s_flags;
>>> bool need_writecp = false;
>>> +#ifdef CONFIG_QUOTA
>>> +   int quota_enabled;
>>> +#endif
>>>  
>>> if (s_flags & MS_RDONLY) {
>>> f2fs_msg(sbi->sb, KERN_INFO, "orphan cleanup on readonly fs");
>>> @@ -604,7 +607,7 @@ int recover_fsync_data(struct f2fs_sb_info *sbi, bool 
>>> check_only)
>>> /* Needed for iput() to work correctly and not trash data */
>>> sbi->sb->s_flags |= MS_ACTIVE;
>>> /* Turn on quotas so that they are updated correctly */
>>> -   f2fs_enable_quota_files(sbi);
>>> +   quota_enabled = f2fs_enable_quota_files(sbi, s_flags & MS_RDONLY);
>>>  #endif
>>>  
>>> fsync_entry_slab = f2fs_kmem_cache_create("f2fs_fsync_inode_entry",
>>> @@ -665,7 +668,8 @@ int recover_fsync_data(struct f2fs_sb_info *sbi, bool 
>>> check_only)
>>>  out:
>>>  #ifdef CONFIG_QUOTA
>>> /* Turn quotas off */
>>> -   f2fs_quota_off_umount(sbi->sb);
>>> +   if (quota_enabled)
>>> +   f2fs_quota_off_umount(sbi->sb);
>>>  #endif
>>> sbi->sb->s_flags = s_flags; /* Restore MS_RDONLY status */
>>>  
>>> diff --git 

Re: [f2fs-dev] [PATCH 2/2] f2fs: support quota sys files

[Chao Yu]

On 2017/11/3 11:37, Jaegeuk Kim wrote:
> On 11/02, Chao Yu wrote:
>> On 2017/10/31 11:40, Jaegeuk Kim wrote:
>>> This patch supports hidden quota files in the system, which will be used for
>>> Android. It requires up-to-date f2fs-tools later than v1.9.0.
>>>
>>> Signed-off-by: Jaegeuk Kim 
>>> ---
>>>  fs/f2fs/checkpoint.c |   9 +++-
>>>  fs/f2fs/f2fs.h   |   9 +++-
>>>  fs/f2fs/recovery.c   |   8 ++-
>>>  fs/f2fs/super.c  | 145 
>>> ++-
>>>  4 files changed, 153 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
>>> index 6b52d4b66c7b..78e1b2998bbd 100644
>>> --- a/fs/f2fs/checkpoint.c
>>> +++ b/fs/f2fs/checkpoint.c
>>> @@ -615,6 +615,9 @@ int recover_orphan_inodes(struct f2fs_sb_info *sbi)
>>> block_t start_blk, orphan_blocks, i, j;
>>> unsigned int s_flags = sbi->sb->s_flags;
>>> int err = 0;
>>> +#ifdef CONFIG_QUOTA
>>> +   int quota_enabled;
>>> +#endif
>>>  
>>> if (!is_set_ckpt_flags(sbi, CP_ORPHAN_PRESENT_FLAG))
>>> return 0;
>>> @@ -627,8 +630,9 @@ int recover_orphan_inodes(struct f2fs_sb_info *sbi)
>>>  #ifdef CONFIG_QUOTA
>>> /* Needed for iput() to work correctly and not trash data */
>>> sbi->sb->s_flags |= MS_ACTIVE;
>>> +
>>> /* Turn on quotas so that they are updated correctly */
>>> -   f2fs_enable_quota_files(sbi);
>>> +   quota_enabled = f2fs_enable_quota_files(sbi, s_flags & MS_RDONLY);
>>>  #endif
>>>  
>>> start_blk = __start_cp_addr(sbi) + 1 + __cp_payload(sbi);
>>> @@ -656,7 +660,8 @@ int recover_orphan_inodes(struct f2fs_sb_info *sbi)
>>>  out:
>>>  #ifdef CONFIG_QUOTA
>>> /* Turn quotas off */
>>> -   f2fs_quota_off_umount(sbi->sb);
>>> +   if (quota_enabled)
>>> +   f2fs_quota_off_umount(sbi->sb);
>>>  #endif
>>> sbi->sb->s_flags = s_flags; /* Restore MS_RDONLY status */
>>>  
>>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
>>> index 9a1c7ffa6845..e1d3a940d9f8 100644
>>> --- a/fs/f2fs/f2fs.h
>>> +++ b/fs/f2fs/f2fs.h
>>> @@ -1384,6 +1384,13 @@ static inline unsigned long long 
>>> cur_cp_version(struct f2fs_checkpoint *cp)
>>> return le64_to_cpu(cp->checkpoint_ver);
>>>  }
>>>  
>>> +static inline unsigned long f2fs_qf_ino(struct super_block *sb, int type)
>>> +{
>>> +   if (type < F2FS_QUOTA_INO)
>>
>> Why not just use F2FS_MAX_QUOTAS instead of F2FS_QUOTA_INO? since in patch 
>> 1/2
>> we have defined qf_ino array with upper-boundary F2FS_MAX_QUOTAS.
> 
> It was intended to indicate # of enabled quotas. ;)

Alright, so how about renaming it to F2FS_ENABLED_QUOTA_INO... :)

Thanks,

> 
>>
>>  __le32 qf_ino[F2FS_MAX_QUOTAS]; /* quota inode numbers */
>>
>> Other part looks good to me. ;)
>>
>> Reviewed-by: Chao Yu 
>>
>> Thanks,
>>
>>> +   return le32_to_cpu(F2FS_SB(sb)->raw_super->qf_ino[type]);
>>> +   return 0;
>>> +}
>>> +
>>>  static inline __u64 cur_cp_crc(struct f2fs_checkpoint *cp)
>>>  {
>>> size_t crc_offset = le32_to_cpu(cp->checksum_offset);
>>> @@ -2526,7 +2533,7 @@ static inline int f2fs_add_link(struct dentry 
>>> *dentry, struct inode *inode)
>>>   */
>>>  int f2fs_inode_dirtied(struct inode *inode, bool sync);
>>>  void f2fs_inode_synced(struct inode *inode);
>>> -void f2fs_enable_quota_files(struct f2fs_sb_info *sbi);
>>> +int f2fs_enable_quota_files(struct f2fs_sb_info *sbi, bool rdonly);
>>>  void f2fs_quota_off_umount(struct super_block *sb);
>>>  int f2fs_commit_super(struct f2fs_sb_info *sbi, bool recover);
>>>  int f2fs_sync_fs(struct super_block *sb, int sync);
>>> diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
>>> index 9626758bc762..92c57ace1939 100644
>>> --- a/fs/f2fs/recovery.c
>>> +++ b/fs/f2fs/recovery.c
>>> @@ -594,6 +594,9 @@ int recover_fsync_data(struct f2fs_sb_info *sbi, bool 
>>> check_only)
>>> int ret = 0;
>>> unsigned long s_flags = sbi->sb->s_flags;
>>> bool need_writecp = false;
>>> +#ifdef CONFIG_QUOTA
>>> +   int quota_enabled;
>>> +#endif
>>>  
>>> if (s_flags & MS_RDONLY) {
>>> f2fs_msg(sbi->sb, KERN_INFO, "orphan cleanup on readonly fs");
>>> @@ -604,7 +607,7 @@ int recover_fsync_data(struct f2fs_sb_info *sbi, bool 
>>> check_only)
>>> /* Needed for iput() to work correctly and not trash data */
>>> sbi->sb->s_flags |= MS_ACTIVE;
>>> /* Turn on quotas so that they are updated correctly */
>>> -   f2fs_enable_quota_files(sbi);
>>> +   quota_enabled = f2fs_enable_quota_files(sbi, s_flags & MS_RDONLY);
>>>  #endif
>>>  
>>> fsync_entry_slab = f2fs_kmem_cache_create("f2fs_fsync_inode_entry",
>>> @@ -665,7 +668,8 @@ int recover_fsync_data(struct f2fs_sb_info *sbi, bool 
>>> check_only)
>>>  out:
>>>  #ifdef CONFIG_QUOTA
>>> /* Turn quotas off */
>>> -   f2fs_quota_off_umount(sbi->sb);
>>> +   if (quota_enabled)
>>> +   f2fs_quota_off_umount(sbi->sb);
>>>  #endif
>>> sbi->sb->s_flags = s_flags; /* Restore MS_RDONLY status */
>>>  
>>> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
>>> index 

[GIT] Networking

[David Miller]

Hopefully this is the last batch of networking fixes for 4.14

Fingers crossed...

1) Fix stmmac to use the proper sized OF property read, from Bhadram
   Varka.

2) Fix use after free in net scheduler tc action code, from Cong
   Wang.

3) Fix SKB control block mangling in tcp_make_synack().

4) Use proper locking in fib_dump_info(), from Florian Westphal.

5) Fix IPG encodings in systemport driver, from Florian Fainelli.

6) Fix division by zero in NV TCP congestion control module, from
   Konstantin Khlebnikov.

7) Fix use after free in nf_reject_ipv4, from Tejaswi Tanikella.

Please pull, thanks a lot!

The following changes since commit 3a99df9a3d14cd866b5516f8cba515a3bfd554ab:

  Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace 
(2017-11-01 16:04:27 -0700)

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 93824c80bf47ebe087414b3a40ca0ff9aab7d1fb:

  net: systemport: Correct IPG length settings (2017-11-03 14:30:02 +0900)


Anatole Denis (1):
  netfilter: nft_set_hash: disable fast_ops for 2-len keys

Bhadram Varka (1):
  stmmac: use of_property_read_u32 instead of read_u8

Cong Wang (2):
  net_sched: acquire RTNL in tc_action_net_exit()
  net_sched: hold netns refcnt for each action

David S. Miller (2):
  Merge git://git.kernel.org/.../pablo/nf
  Merge branch 'net-sched-use-after-free'

Eric Dumazet (1):
  tcp: do not mangle skb->cb[] in tcp_make_synack()

Florian Fainelli (1):
  net: systemport: Correct IPG length settings

Florian Westphal (1):
  fib: fib_dump_info can no longer use __in_dev_get_rtnl

Jeff Barnhill (1):
  net: vrf: correct FRA_L3MDEV encode type

Konstantin Khlebnikov (1):
  tcp_nv: fix division by zero in tcpnv_acked()

Tejaswi Tanikella (1):
  netfilter: nf_reject_ipv4: Fix use-after-free in send_reset

 drivers/net/ethernet/broadcom/bcmsysport.c| 10 ++
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 16 
 drivers/net/vrf.c |  2 +-
 include/linux/stmmac.h|  8 
 include/net/act_api.h |  6 +-
 net/ipv4/fib_semantics.c  | 16 ++--
 net/ipv4/netfilter/nf_reject_ipv4.c   |  2 ++
 net/ipv4/tcp_nv.c |  2 +-
 net/ipv4/tcp_output.c |  9 ++---
 net/netfilter/nft_set_hash.c  |  1 -
 net/sched/act_api.c   |  4 
 net/sched/act_bpf.c   |  2 +-
 net/sched/act_connmark.c  |  2 +-
 net/sched/act_csum.c  |  2 +-
 net/sched/act_gact.c  |  2 +-
 net/sched/act_ife.c   |  2 +-
 net/sched/act_ipt.c   |  4 ++--
 net/sched/act_mirred.c|  2 +-
 net/sched/act_nat.c   |  2 +-
 net/sched/act_pedit.c |  2 +-
 net/sched/act_police.c|  2 +-
 net/sched/act_sample.c|  2 +-
 net/sched/act_simple.c|  2 +-
 net/sched/act_skbedit.c   |  2 +-
 net/sched/act_skbmod.c|  2 +-
 net/sched/act_tunnel_key.c|  2 +-
 net/sched/act_vlan.c  |  2 +-
 27 files changed, 60 insertions(+), 50 deletions(-)

[GIT] Networking

[David Miller]

Hopefully this is the last batch of networking fixes for 4.14

Fingers crossed...

1) Fix stmmac to use the proper sized OF property read, from Bhadram
   Varka.

2) Fix use after free in net scheduler tc action code, from Cong
   Wang.

3) Fix SKB control block mangling in tcp_make_synack().

4) Use proper locking in fib_dump_info(), from Florian Westphal.

5) Fix IPG encodings in systemport driver, from Florian Fainelli.

6) Fix division by zero in NV TCP congestion control module, from
   Konstantin Khlebnikov.

7) Fix use after free in nf_reject_ipv4, from Tejaswi Tanikella.

Please pull, thanks a lot!

The following changes since commit 3a99df9a3d14cd866b5516f8cba515a3bfd554ab:

  Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace 
(2017-11-01 16:04:27 -0700)

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 93824c80bf47ebe087414b3a40ca0ff9aab7d1fb:

  net: systemport: Correct IPG length settings (2017-11-03 14:30:02 +0900)


Anatole Denis (1):
  netfilter: nft_set_hash: disable fast_ops for 2-len keys

Bhadram Varka (1):
  stmmac: use of_property_read_u32 instead of read_u8

Cong Wang (2):
  net_sched: acquire RTNL in tc_action_net_exit()
  net_sched: hold netns refcnt for each action

David S. Miller (2):
  Merge git://git.kernel.org/.../pablo/nf
  Merge branch 'net-sched-use-after-free'

Eric Dumazet (1):
  tcp: do not mangle skb->cb[] in tcp_make_synack()

Florian Fainelli (1):
  net: systemport: Correct IPG length settings

Florian Westphal (1):
  fib: fib_dump_info can no longer use __in_dev_get_rtnl

Jeff Barnhill (1):
  net: vrf: correct FRA_L3MDEV encode type

Konstantin Khlebnikov (1):
  tcp_nv: fix division by zero in tcpnv_acked()

Tejaswi Tanikella (1):
  netfilter: nf_reject_ipv4: Fix use-after-free in send_reset

 drivers/net/ethernet/broadcom/bcmsysport.c| 10 ++
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 16 
 drivers/net/vrf.c |  2 +-
 include/linux/stmmac.h|  8 
 include/net/act_api.h |  6 +-
 net/ipv4/fib_semantics.c  | 16 ++--
 net/ipv4/netfilter/nf_reject_ipv4.c   |  2 ++
 net/ipv4/tcp_nv.c |  2 +-
 net/ipv4/tcp_output.c |  9 ++---
 net/netfilter/nft_set_hash.c  |  1 -
 net/sched/act_api.c   |  4 
 net/sched/act_bpf.c   |  2 +-
 net/sched/act_connmark.c  |  2 +-
 net/sched/act_csum.c  |  2 +-
 net/sched/act_gact.c  |  2 +-
 net/sched/act_ife.c   |  2 +-
 net/sched/act_ipt.c   |  4 ++--
 net/sched/act_mirred.c|  2 +-
 net/sched/act_nat.c   |  2 +-
 net/sched/act_pedit.c |  2 +-
 net/sched/act_police.c|  2 +-
 net/sched/act_sample.c|  2 +-
 net/sched/act_simple.c|  2 +-
 net/sched/act_skbedit.c   |  2 +-
 net/sched/act_skbmod.c|  2 +-
 net/sched/act_tunnel_key.c|  2 +-
 net/sched/act_vlan.c  |  2 +-
 27 files changed, 60 insertions(+), 50 deletions(-)

linux-next: build warnings after merge of the gpio tree

[Stephen Rothwell]

Hi Linus,

After merging the gpio tree, yesterday's linux-next build (arm
multi_v7_defconfig) produced these warnings:

arch/arm/boot/dts/bcm2835-rpi-b.dtb: Warning (phys_property): Missing property 
'#phy-cells' in node /phy or bad phandle (referred from 
/soc/usb@7e98:phys[0])
arch/arm/boot/dts/bcm2835-rpi-b-rev2.dtb: Warning (phys_property): Missing 
property '#phy-cells' in node /phy or bad phandle (referred from 
/soc/usb@7e98:phys[0])
arch/arm/boot/dts/bcm2835-rpi-a.dtb: Warning (phys_property): Missing property 
'#phy-cells' in node /phy or bad phandle (referred from 
/soc/usb@7e98:phys[0])
arch/arm/boot/dts/bcm2835-rpi-b-plus.dtb: Warning (phys_property): Missing 
property '#phy-cells' in node /phy or bad phandle (referred from 
/soc/usb@7e98:phys[0])
arch/arm/boot/dts/bcm2835-rpi-a-plus.dtb: Warning (phys_property): Missing 
property '#phy-cells' in node /phy or bad phandle (referred from 
/soc/usb@7e98:phys[0])
arch/arm/boot/dts/bcm2836-rpi-2-b.dtb: Warning (phys_property): Missing 
property '#phy-cells' in node /phy or bad phandle (referred from 
/soc/usb@7e98:phys[0])
arch/arm/boot/dts/bcm2837-rpi-3-b.dtb: Warning (phys_property): Missing 
property '#phy-cells' in node /phy or bad phandle (referred from 
/soc/usb@7e98:phys[0])
arch/arm/boot/dts/bcm2835-rpi-zero.dtb: Warning (phys_property): Missing 
property '#phy-cells' in node /phy or bad phandle (referred from 
/soc/usb@7e98:phys[0])
arch/arm/boot/dts/bcm2835-rpi-zero-w.dtb: Warning (phys_property): Missing 
property '#phy-cells' in node /phy or bad phandle (referred from 
/soc/usb@7e98:phys[0])
arch/arm/boot/dts/exynos5410-odroidxu.dtb: Warning (interrupts_property): 
Missing interrupt-controller or interrupt-map property in 
/soc/system-controller@1004

and many, many more.

I have no idea what caused this.

-- 
Cheers,
Stephen Rothwell

linux-next: build warnings after merge of the gpio tree

[Stephen Rothwell]

Hi Linus,

After merging the gpio tree, yesterday's linux-next build (arm
multi_v7_defconfig) produced these warnings:

arch/arm/boot/dts/bcm2835-rpi-b.dtb: Warning (phys_property): Missing property 
'#phy-cells' in node /phy or bad phandle (referred from 
/soc/usb@7e98:phys[0])
arch/arm/boot/dts/bcm2835-rpi-b-rev2.dtb: Warning (phys_property): Missing 
property '#phy-cells' in node /phy or bad phandle (referred from 
/soc/usb@7e98:phys[0])
arch/arm/boot/dts/bcm2835-rpi-a.dtb: Warning (phys_property): Missing property 
'#phy-cells' in node /phy or bad phandle (referred from 
/soc/usb@7e98:phys[0])
arch/arm/boot/dts/bcm2835-rpi-b-plus.dtb: Warning (phys_property): Missing 
property '#phy-cells' in node /phy or bad phandle (referred from 
/soc/usb@7e98:phys[0])
arch/arm/boot/dts/bcm2835-rpi-a-plus.dtb: Warning (phys_property): Missing 
property '#phy-cells' in node /phy or bad phandle (referred from 
/soc/usb@7e98:phys[0])
arch/arm/boot/dts/bcm2836-rpi-2-b.dtb: Warning (phys_property): Missing 
property '#phy-cells' in node /phy or bad phandle (referred from 
/soc/usb@7e98:phys[0])
arch/arm/boot/dts/bcm2837-rpi-3-b.dtb: Warning (phys_property): Missing 
property '#phy-cells' in node /phy or bad phandle (referred from 
/soc/usb@7e98:phys[0])
arch/arm/boot/dts/bcm2835-rpi-zero.dtb: Warning (phys_property): Missing 
property '#phy-cells' in node /phy or bad phandle (referred from 
/soc/usb@7e98:phys[0])
arch/arm/boot/dts/bcm2835-rpi-zero-w.dtb: Warning (phys_property): Missing 
property '#phy-cells' in node /phy or bad phandle (referred from 
/soc/usb@7e98:phys[0])
arch/arm/boot/dts/exynos5410-odroidxu.dtb: Warning (interrupts_property): 
Missing interrupt-controller or interrupt-map property in 
/soc/system-controller@1004

and many, many more.

I have no idea what caused this.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH net-next] net: Define eth_stp_addr in linux/etherdevice.h

[David Miller]

From: Egil Hjelmeland 
Date: Thu,  2 Nov 2017 10:36:48 +0100

> The lan9303 driver defines eth_stp_addr as a synonym to
> eth_reserved_addr_base to get the STP ethernet address 01:80:c2:00:00:00.
> 
> eth_reserved_addr_base is also used to define the start of Bridge Reserved
> ethernet address range, which happen to be the STP address.
> 
> br_dev_setup refer to eth_reserved_addr_base as a definition of STP
> address.
> 
> Clean up by:
>  - Move the eth_stp_addr definition to linux/etherdevice.h
>  - Use eth_stp_addr instead of eth_reserved_addr_base in br_dev_setup.
> 
> Signed-off-by: Egil Hjelmeland 

Applied, thank you.

Re: [PATCH net-next] net: Define eth_stp_addr in linux/etherdevice.h

[David Miller]

From: Egil Hjelmeland 
Date: Thu,  2 Nov 2017 10:36:48 +0100

> The lan9303 driver defines eth_stp_addr as a synonym to
> eth_reserved_addr_base to get the STP ethernet address 01:80:c2:00:00:00.
> 
> eth_reserved_addr_base is also used to define the start of Bridge Reserved
> ethernet address range, which happen to be the STP address.
> 
> br_dev_setup refer to eth_reserved_addr_base as a definition of STP
> address.
> 
> Clean up by:
>  - Move the eth_stp_addr definition to linux/etherdevice.h
>  - Use eth_stp_addr instead of eth_reserved_addr_base in br_dev_setup.
> 
> Signed-off-by: Egil Hjelmeland 

Applied, thank you.

Re: [PATCH 1/2] [net-next] bpf: fix link error without CONFIG_NET

[David Miller]

From: Arnd Bergmann 
Date: Thu,  2 Nov 2017 12:05:51 +0100

> I ran into this link error with the latest net-next plus linux-next
> trees when networking is disabled:
> 
> kernel/bpf/verifier.o:(.rodata+0x2958): undefined reference to 
> `tc_cls_act_analyzer_ops'
> kernel/bpf/verifier.o:(.rodata+0x2970): undefined reference to 
> `xdp_analyzer_ops'
> 
> It seems that the code was written to deal with varying contents of
> the arrray, but the actual #ifdef was missing. Both tc_cls_act_analyzer_ops
> and xdp_analyzer_ops are defined in the core networking code, so adding
> a check for CONFIG_NET seems appropriate here, and I've verified this with
> many randconfig builds
> 
> Fixes: 4f9218aaf8a4 ("bpf: move knowledge about post-translation offsets out 
> of verifier")
> Signed-off-by: Arnd Bergmann 

Applied.

Re: [PATCH 1/2] [net-next] bpf: fix link error without CONFIG_NET

[David Miller]

From: Arnd Bergmann 
Date: Thu,  2 Nov 2017 12:05:51 +0100

> I ran into this link error with the latest net-next plus linux-next
> trees when networking is disabled:
> 
> kernel/bpf/verifier.o:(.rodata+0x2958): undefined reference to 
> `tc_cls_act_analyzer_ops'
> kernel/bpf/verifier.o:(.rodata+0x2970): undefined reference to 
> `xdp_analyzer_ops'
> 
> It seems that the code was written to deal with varying contents of
> the arrray, but the actual #ifdef was missing. Both tc_cls_act_analyzer_ops
> and xdp_analyzer_ops are defined in the core networking code, so adding
> a check for CONFIG_NET seems appropriate here, and I've verified this with
> many randconfig builds
> 
> Fixes: 4f9218aaf8a4 ("bpf: move knowledge about post-translation offsets out 
> of verifier")
> Signed-off-by: Arnd Bergmann 

Applied.

Re: [PATCH 2/2] [net-next] bpf: fix out-of-bounds access warning in bpf_check

[David Miller]

From: Arnd Bergmann 
Date: Thu,  2 Nov 2017 12:05:52 +0100

> The bpf_verifer_ops array is generated dynamically and may be
> empty depending on configuration, which then causes an out
> of bounds access:
> 
> kernel/bpf/verifier.c: In function 'bpf_check':
> kernel/bpf/verifier.c:4320:29: error: array subscript is above array bounds 
> [-Werror=array-bounds]
> 
> This adds a check to the start of the function as a workaround.
> I would assume that the function is never called in that configuration,
> so the warning is probably harmless.
> 
> Fixes: 00176a34d9e2 ("bpf: remove the verifier ops from program structure")
> Signed-off-by: Arnd Bergmann 

Applied.

Re: [PATCH 2/2] [net-next] bpf: fix out-of-bounds access warning in bpf_check

[David Miller]

From: Arnd Bergmann 
Date: Thu,  2 Nov 2017 12:05:52 +0100

> The bpf_verifer_ops array is generated dynamically and may be
> empty depending on configuration, which then causes an out
> of bounds access:
> 
> kernel/bpf/verifier.c: In function 'bpf_check':
> kernel/bpf/verifier.c:4320:29: error: array subscript is above array bounds 
> [-Werror=array-bounds]
> 
> This adds a check to the start of the function as a workaround.
> I would assume that the function is never called in that configuration,
> so the warning is probably harmless.
> 
> Fixes: 00176a34d9e2 ("bpf: remove the verifier ops from program structure")
> Signed-off-by: Arnd Bergmann 

Applied.

Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()

[Christoph Hellwig]

I can queue 1 up in the dma-mapping tree, and if I get reviews for
the mips and scsi bits I'd be happy to queue those up as well.

But I think you'd be better off moving patches 3 and 4 to the front
without the dma_get_cache_alignment prototype change so that they can be
merged to stable.

Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()

[Christoph Hellwig]

I can queue 1 up in the dma-mapping tree, and if I get reviews for
the mips and scsi bits I'd be happy to queue those up as well.

But I think you'd be better off moving patches 3 and 4 to the front
without the dma_get_cache_alignment prototype change so that they can be
merged to stable.

Re: [PATCH] ARM: multi_v7_defconfig: Select RPMSG_VIRTIO as module

[Bjorn Andersson]

On Thu 05 Oct 09:49 PDT 2017, Anup Patel wrote:

> The RPMSG_VIRTIO is now user selectable option so we explicitly
> select it in multi_v7_defconfig. Till now RPMSG_VIRTIO was
> selected by ST_REMOTEPROC=m in multi_v7_defconfig.
> 

Acked-by: Bjorn Andersson 

> Signed-off-by: Anup Patel 

Regards,
Bjorn

> ---
>  arch/arm/configs/multi_v7_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/configs/multi_v7_defconfig 
> b/arch/arm/configs/multi_v7_defconfig
> index 0cacdbf..5e689e0 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -849,6 +849,7 @@ CONFIG_TEGRA_IOMMU_GART=y
>  CONFIG_TEGRA_IOMMU_SMMU=y
>  CONFIG_REMOTEPROC=m
>  CONFIG_ST_REMOTEPROC=m
> +CONFIG_RPMSG_VIRTIO=m
>  CONFIG_PM_DEVFREQ=y
>  CONFIG_ARM_TEGRA_DEVFREQ=m
>  CONFIG_MEMORY=y
> -- 
> 2.7.4
> 

Re: [PATCH] ARM: multi_v7_defconfig: Select RPMSG_VIRTIO as module

[Bjorn Andersson]

On Thu 05 Oct 09:49 PDT 2017, Anup Patel wrote:

> The RPMSG_VIRTIO is now user selectable option so we explicitly
> select it in multi_v7_defconfig. Till now RPMSG_VIRTIO was
> selected by ST_REMOTEPROC=m in multi_v7_defconfig.
> 

Acked-by: Bjorn Andersson 

> Signed-off-by: Anup Patel 

Regards,
Bjorn

> ---
>  arch/arm/configs/multi_v7_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/configs/multi_v7_defconfig 
> b/arch/arm/configs/multi_v7_defconfig
> index 0cacdbf..5e689e0 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -849,6 +849,7 @@ CONFIG_TEGRA_IOMMU_GART=y
>  CONFIG_TEGRA_IOMMU_SMMU=y
>  CONFIG_REMOTEPROC=m
>  CONFIG_ST_REMOTEPROC=m
> +CONFIG_RPMSG_VIRTIO=m
>  CONFIG_PM_DEVFREQ=y
>  CONFIG_ARM_TEGRA_DEVFREQ=m
>  CONFIG_MEMORY=y
> -- 
> 2.7.4
> 

Re: [PATCH V8 0/2] printk: hash addresses printed with %p

[Vinod Koul]

On Tue, Oct 31, 2017 at 04:33:13PM -0700, Joe Perches wrote:
> On Wed, 2017-11-01 at 10:16 +1100, Tobin C. Harding wrote:

> > Cool, thanks Joe I'll keep this in mind for when we get to %pa.
> 
> fyi:  There are more of these misuses of 0x%pa now:
> 
> $ git grep -E -n "0[xX]%pa[dp]?\b"
> drivers/dma/at_hdmac_regs.h:388: "  desc: s%pad d%pad 
> ctrl0x%x:0x%x l0x%pad\n",
> drivers/dma/coh901318.c:1322:   dev_vdbg(COHC_2_DEV(cohc), "i %d, lli 
> %p, ctrl 0x%x, src 0x%pad"
> drivers/dma/coh901318.c:1323:", dst 0x%pad, link 0x%pad 
> virt_link_addr 0x%p\n",
> drivers/dma/coh901318.c:2234:"[%s] channel %d src 0x%pad dest 
> 0x%pad size %zu\n",

Fixed and sent patches for these two.

-- 
~Vinod

Re: [PATCH V8 0/2] printk: hash addresses printed with %p

[Vinod Koul]

On Tue, Oct 31, 2017 at 04:33:13PM -0700, Joe Perches wrote:
> On Wed, 2017-11-01 at 10:16 +1100, Tobin C. Harding wrote:

> > Cool, thanks Joe I'll keep this in mind for when we get to %pa.
> 
> fyi:  There are more of these misuses of 0x%pa now:
> 
> $ git grep -E -n "0[xX]%pa[dp]?\b"
> drivers/dma/at_hdmac_regs.h:388: "  desc: s%pad d%pad 
> ctrl0x%x:0x%x l0x%pad\n",
> drivers/dma/coh901318.c:1322:   dev_vdbg(COHC_2_DEV(cohc), "i %d, lli 
> %p, ctrl 0x%x, src 0x%pad"
> drivers/dma/coh901318.c:1323:", dst 0x%pad, link 0x%pad 
> virt_link_addr 0x%p\n",
> drivers/dma/coh901318.c:2234:"[%s] channel %d src 0x%pad dest 
> 0x%pad size %zu\n",

Fixed and sent patches for these two.

-- 
~Vinod

Re: [PATCH] ARM: multi_v7_defconfig: Select RPMSG_VIRTIO as module

[Anup Patel]

On Thu, Oct 26, 2017 at 9:33 PM, Anup Patel  wrote:
> On Thu, Oct 5, 2017 at 10:19 PM, Anup Patel  wrote:
>> The RPMSG_VIRTIO is now user selectable option so we explicitly
>> select it in multi_v7_defconfig. Till now RPMSG_VIRTIO was
>> selected by ST_REMOTEPROC=m in multi_v7_defconfig.
>>
>> Signed-off-by: Anup Patel 
>> ---
>>  arch/arm/configs/multi_v7_defconfig | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/configs/multi_v7_defconfig 
>> b/arch/arm/configs/multi_v7_defconfig
>> index 0cacdbf..5e689e0 100644
>> --- a/arch/arm/configs/multi_v7_defconfig
>> +++ b/arch/arm/configs/multi_v7_defconfig
>> @@ -849,6 +849,7 @@ CONFIG_TEGRA_IOMMU_GART=y
>>  CONFIG_TEGRA_IOMMU_SMMU=y
>>  CONFIG_REMOTEPROC=m
>>  CONFIG_ST_REMOTEPROC=m
>> +CONFIG_RPMSG_VIRTIO=m
>>  CONFIG_PM_DEVFREQ=y
>>  CONFIG_ARM_TEGRA_DEVFREQ=m
>>  CONFIG_MEMORY=y
>> --
>> 2.7.4
>>
>
> Hi Arnd/Olof,
>
> Please have a look at this patch.
>
> This is a follow-up patch for https://patchwork.kernel.org/patch/9987567/
>
> Regards,
> Anup

Hi All,

Ping  ???

Regards,
Anup

Re: [PATCH] ARM: multi_v7_defconfig: Select RPMSG_VIRTIO as module

[Anup Patel]

On Thu, Oct 26, 2017 at 9:33 PM, Anup Patel  wrote:
> On Thu, Oct 5, 2017 at 10:19 PM, Anup Patel  wrote:
>> The RPMSG_VIRTIO is now user selectable option so we explicitly
>> select it in multi_v7_defconfig. Till now RPMSG_VIRTIO was
>> selected by ST_REMOTEPROC=m in multi_v7_defconfig.
>>
>> Signed-off-by: Anup Patel 
>> ---
>>  arch/arm/configs/multi_v7_defconfig | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/configs/multi_v7_defconfig 
>> b/arch/arm/configs/multi_v7_defconfig
>> index 0cacdbf..5e689e0 100644
>> --- a/arch/arm/configs/multi_v7_defconfig
>> +++ b/arch/arm/configs/multi_v7_defconfig
>> @@ -849,6 +849,7 @@ CONFIG_TEGRA_IOMMU_GART=y
>>  CONFIG_TEGRA_IOMMU_SMMU=y
>>  CONFIG_REMOTEPROC=m
>>  CONFIG_ST_REMOTEPROC=m
>> +CONFIG_RPMSG_VIRTIO=m
>>  CONFIG_PM_DEVFREQ=y
>>  CONFIG_ARM_TEGRA_DEVFREQ=m
>>  CONFIG_MEMORY=y
>> --
>> 2.7.4
>>
>
> Hi Arnd/Olof,
>
> Please have a look at this patch.
>
> This is a follow-up patch for https://patchwork.kernel.org/patch/9987567/
>
> Regards,
> Anup

Hi All,

Ping  ???

Regards,
Anup

Re: [PATCH 3/3] openrisc: dts: Add OpenRISC platform SoC

[Stafford Horne]

On Sun, Oct 22, 2017 at 11:46:41AM +0900, Stafford Horne wrote:
> Add devicetree binding documentation for the OpenRISC platform
> opencores,or1ksim.  This is the main OpenRISC reference platform
> supporting multiple FPGA SoC's.
> 
> This format is based on some of the mips binding docs as we have
> similar requirements.
> 
> Also, update maintainers so openrisc related binding changes are visible
> to the openrisc team.
> 

[..]

> diff --git a/MAINTAINERS b/MAINTAINERS
> index a57d13cb414d..71e4f6762196 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10008,6 +10008,7 @@ T:git git://github.com/openrisc/linux.git
>  L:   openr...@lists.librecores.org
>  W:   http://openrisc.io
>  S:   Maintained
> +F;   Documentation/devicetree/bindings/openrisc/

FYI, I found this typo (; vs :) which I have fixed and am pushing to next.

>  F:   Documentation/openrisc/
>  F:   arch/openrisc/
>  F:   drivers/irqchip/irq-or1k-*
> -- 
> 2.13.6
> 

Re: [PATCH 3/3] openrisc: dts: Add OpenRISC platform SoC

[Stafford Horne]

On Sun, Oct 22, 2017 at 11:46:41AM +0900, Stafford Horne wrote:
> Add devicetree binding documentation for the OpenRISC platform
> opencores,or1ksim.  This is the main OpenRISC reference platform
> supporting multiple FPGA SoC's.
> 
> This format is based on some of the mips binding docs as we have
> similar requirements.
> 
> Also, update maintainers so openrisc related binding changes are visible
> to the openrisc team.
> 

[..]

> diff --git a/MAINTAINERS b/MAINTAINERS
> index a57d13cb414d..71e4f6762196 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10008,6 +10008,7 @@ T:git git://github.com/openrisc/linux.git
>  L:   openr...@lists.librecores.org
>  W:   http://openrisc.io
>  S:   Maintained
> +F;   Documentation/devicetree/bindings/openrisc/

FYI, I found this typo (; vs :) which I have fixed and am pushing to next.

>  F:   Documentation/openrisc/
>  F:   arch/openrisc/
>  F:   drivers/irqchip/irq-or1k-*
> -- 
> 2.13.6
> 

[lkp-robot] [kprobes/x86] b664d57f39: BUG:using_smp_processor_id()in_preemptible

[kernel test robot]

FYI, we noticed the following commit (built with gcc-4.9):

commit: b664d57f39d01e775204d4f1a7e2f8bda77bc549 ("kprobes/x86: Remove IRQ 
disabling from jprobe handlers")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -smp 2 -m 512M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


++++
|| ee213fc72f | b664d57f39 |
++++
| boot_successes | 82 | 2  |
| boot_failures  | 0  | 80 |
| BUG:using_smp_processor_id()in_preemptible | 0  | 80 |
| int3:#[##] | 0  | 17 |
| RIP:jprobe_return_end  | 0  | 17 |
| Kernel_panic-not_syncing:Fatal_exception   | 0  | 17 |
++++



[   43.572944] BUG: using smp_processor_id() in preemptible [] code: 
swapper/0/1
[   43.589378] caller is debug_smp_processor_id+0x1c/0x1e
[   43.603335] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.14.0-rc3-2-gb664d57 #2
[   43.604188] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[   43.604188] Call Trace:
[   43.604188]  dump_stack+0x85/0xb0
[   43.604188]  check_preemption_disabled+0x11e/0x13a
[   43.604188]  debug_smp_processor_id+0x1c/0x1e
[   43.604188]  jprobe_return+0x1b/0x2e
[   43.604188]  j_kprobe_target+0x48/0x4d
[   43.604188]  init_test_probes+0x29a/0x5c3
[   43.604188]  init_kprobes+0x262/0x272
[   43.604188]  ? debugfs_kprobe_init+0xd6/0xd6
[   43.604188]  do_one_initcall+0xaa/0x1ae
[   43.604188]  kernel_init_freeable+0x20d/0x2b5
[   43.604188]  ? rest_init+0x157/0x157
[   43.604188]  kernel_init+0x14/0x15d
[   43.604188]  ? rest_init+0x157/0x157
[   43.604188]  ret_from_fork+0x25/0x30
[   43.769768] tsc: Refined TSC clocksource calibration: 2693.508 MHz
[   43.774901] clocksource: tsc: mask: 0x max_cycles: 
0x26d349e8249, max_idle_ns: 440795288087 ns
[   44.108271] BUG: using smp_processor_id() in preemptible [] code: 
swapper/0/1
[   44.115706] caller is debug_smp_processor_id+0x1c/0x1e
[   44.123287] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.14.0-rc3-2-gb664d57 #2
[   44.136256] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[   44.152148] Call Trace:
[   44.160150]  dump_stack+0x85/0xb0
[   44.168150]  check_preemption_disabled+0x11e/0x13a
[   44.176132]  debug_smp_processor_id+0x1c/0x1e
[   44.184148]  jprobe_return+0x1b/0x2e
[   44.192157]  j_kprobe_target+0x48/0x4d
[   44.200144]  init_test_probes+0x341/0x5c3
[   44.216147]  init_kprobes+0x262/0x272
[   44.220151]  ? debugfs_kprobe_init+0xd6/0xd6
[   44.236135]  do_one_initcall+0xaa/0x1ae
[   44.244151]  kernel_init_freeable+0x20d/0x2b5
[   44.252152]  ? rest_init+0x157/0x157
[   44.260151]  kernel_init+0x14/0x15d
[   44.268149]  ? rest_init+0x157/0x157
[   44.276148]  ret_from_fork+0x25/0x30
[   44.293463] BUG: using smp_processor_id() in preemptible [] code: 
swapper/0/1
[   44.309634] caller is debug_smp_processor_id+0x1c/0x1e
[   44.318450] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 
4.14.0-rc3-2-gb664d57 #2
[   44.319354] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[   44.319354] Call Trace:
[   44.319354]  dump_stack+0x85/0xb0
[   44.319354]  check_preemption_disabled+0x11e/0x13a
[   44.319354]  debug_smp_processor_id+0x1c/0x1e
[   44.319354]  jprobe_return+0x1b/0x2e
[   44.319354]  j_kprobe_target+0x48/0x4d
[   44.319354]  init_test_probes+0x37e/0x5c3
[   44.319354]  init_kprobes+0x262/0x272
[   44.319354]  ? debugfs_kprobe_init+0xd6/0xd6
[   44.319354]  do_one_initcall+0xaa/0x1ae
[   44.319354]  kernel_init_freeable+0x20d/0x2b5
[   44.319354]  ? rest_init+0x157/0x157
[   44.319354]  kernel_init+0x14/0x15d
[   44.319354]  ? rest_init+0x157/0x157
[   44.319354]  ret_from_fork+0x25/0x30
[   44.479432] int3:  [#1] PREEMPT SMP
[   44.480285] Modules linked in:
[   44.480285] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 
4.14.0-rc3-2-gb664d57 #2
[   44.480285] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[   44.480285] task: 8c661c63 task.stack: 8c661c638000
[   44.480285] RIP: 0010:jprobe_return_end+0x0/0x4
[   44.480285] RSP: : EFLAGS: 0296
[   44.480285] RAX: 8c661ca0 RBX: 8c661c63bd90 RCX: 8c661c63
[   44.480285] RDX:  RSI: 0001 RDI: 0296
[   44.480285] RBP: 8c661c63bd98 R08:  R09: 8c661c630c10
[   44.480285] R10: fff5c8d7 R11:  R12: 0001
[   

[lkp-robot] [kprobes/x86] b664d57f39: BUG:using_smp_processor_id()in_preemptible

[kernel test robot]

FYI, we noticed the following commit (built with gcc-4.9):

commit: b664d57f39d01e775204d4f1a7e2f8bda77bc549 ("kprobes/x86: Remove IRQ 
disabling from jprobe handlers")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -smp 2 -m 512M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


++++
|| ee213fc72f | b664d57f39 |
++++
| boot_successes | 82 | 2  |
| boot_failures  | 0  | 80 |
| BUG:using_smp_processor_id()in_preemptible | 0  | 80 |
| int3:#[##] | 0  | 17 |
| RIP:jprobe_return_end  | 0  | 17 |
| Kernel_panic-not_syncing:Fatal_exception   | 0  | 17 |
++++



[   43.572944] BUG: using smp_processor_id() in preemptible [] code: 
swapper/0/1
[   43.589378] caller is debug_smp_processor_id+0x1c/0x1e
[   43.603335] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.14.0-rc3-2-gb664d57 #2
[   43.604188] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[   43.604188] Call Trace:
[   43.604188]  dump_stack+0x85/0xb0
[   43.604188]  check_preemption_disabled+0x11e/0x13a
[   43.604188]  debug_smp_processor_id+0x1c/0x1e
[   43.604188]  jprobe_return+0x1b/0x2e
[   43.604188]  j_kprobe_target+0x48/0x4d
[   43.604188]  init_test_probes+0x29a/0x5c3
[   43.604188]  init_kprobes+0x262/0x272
[   43.604188]  ? debugfs_kprobe_init+0xd6/0xd6
[   43.604188]  do_one_initcall+0xaa/0x1ae
[   43.604188]  kernel_init_freeable+0x20d/0x2b5
[   43.604188]  ? rest_init+0x157/0x157
[   43.604188]  kernel_init+0x14/0x15d
[   43.604188]  ? rest_init+0x157/0x157
[   43.604188]  ret_from_fork+0x25/0x30
[   43.769768] tsc: Refined TSC clocksource calibration: 2693.508 MHz
[   43.774901] clocksource: tsc: mask: 0x max_cycles: 
0x26d349e8249, max_idle_ns: 440795288087 ns
[   44.108271] BUG: using smp_processor_id() in preemptible [] code: 
swapper/0/1
[   44.115706] caller is debug_smp_processor_id+0x1c/0x1e
[   44.123287] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.14.0-rc3-2-gb664d57 #2
[   44.136256] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[   44.152148] Call Trace:
[   44.160150]  dump_stack+0x85/0xb0
[   44.168150]  check_preemption_disabled+0x11e/0x13a
[   44.176132]  debug_smp_processor_id+0x1c/0x1e
[   44.184148]  jprobe_return+0x1b/0x2e
[   44.192157]  j_kprobe_target+0x48/0x4d
[   44.200144]  init_test_probes+0x341/0x5c3
[   44.216147]  init_kprobes+0x262/0x272
[   44.220151]  ? debugfs_kprobe_init+0xd6/0xd6
[   44.236135]  do_one_initcall+0xaa/0x1ae
[   44.244151]  kernel_init_freeable+0x20d/0x2b5
[   44.252152]  ? rest_init+0x157/0x157
[   44.260151]  kernel_init+0x14/0x15d
[   44.268149]  ? rest_init+0x157/0x157
[   44.276148]  ret_from_fork+0x25/0x30
[   44.293463] BUG: using smp_processor_id() in preemptible [] code: 
swapper/0/1
[   44.309634] caller is debug_smp_processor_id+0x1c/0x1e
[   44.318450] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 
4.14.0-rc3-2-gb664d57 #2
[   44.319354] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[   44.319354] Call Trace:
[   44.319354]  dump_stack+0x85/0xb0
[   44.319354]  check_preemption_disabled+0x11e/0x13a
[   44.319354]  debug_smp_processor_id+0x1c/0x1e
[   44.319354]  jprobe_return+0x1b/0x2e
[   44.319354]  j_kprobe_target+0x48/0x4d
[   44.319354]  init_test_probes+0x37e/0x5c3
[   44.319354]  init_kprobes+0x262/0x272
[   44.319354]  ? debugfs_kprobe_init+0xd6/0xd6
[   44.319354]  do_one_initcall+0xaa/0x1ae
[   44.319354]  kernel_init_freeable+0x20d/0x2b5
[   44.319354]  ? rest_init+0x157/0x157
[   44.319354]  kernel_init+0x14/0x15d
[   44.319354]  ? rest_init+0x157/0x157
[   44.319354]  ret_from_fork+0x25/0x30
[   44.479432] int3:  [#1] PREEMPT SMP
[   44.480285] Modules linked in:
[   44.480285] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 
4.14.0-rc3-2-gb664d57 #2
[   44.480285] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[   44.480285] task: 8c661c63 task.stack: 8c661c638000
[   44.480285] RIP: 0010:jprobe_return_end+0x0/0x4
[   44.480285] RSP: : EFLAGS: 0296
[   44.480285] RAX: 8c661ca0 RBX: 8c661c63bd90 RCX: 8c661c63
[   44.480285] RDX:  RSI: 0001 RDI: 0296
[   44.480285] RBP: 8c661c63bd98 R08:  R09: 8c661c630c10
[   44.480285] R10: fff5c8d7 R11:  R12: 0001
[   

[PATCH v4 6/6] pmbus: max31785: Add dual tachometer support

[Andrew Jeffery]

The dual tachometer feature is implemented in hardware with a TACHSEL
input to indicate the rotor under measurement, and exposed on the device
by extending the READ_FAN_SPEED_1 word with two extra bytes*. The need
to read the non-standard four-byte response leads to a cut-down
implementation of i2c_smbus_xfer_emulated() included in the driver.
Further, to expose the second rotor tachometer value to userspace the
values are exposed through virtual pages. We re-route accesses to
FAN_CONFIG_1_2 and READ_FAN_SPEED_1 on undefined (in hardware) pages
23-28 to the same registers on pages 0-5, and with the latter command we
extract the value from the second word of the four-byte response.

* The documentation recommends the slower rotor be associated with
TACHSEL=0, which provides the first word of the response. The TACHSEL=0
measurement is used by the controller's closed-loop fan management.

Signed-off-by: Andrew Jeffery 
---
 Documentation/hwmon/max31785   |   8 ++-
 drivers/hwmon/pmbus/max31785.c | 159 -
 2 files changed, 163 insertions(+), 4 deletions(-)

diff --git a/Documentation/hwmon/max31785 b/Documentation/hwmon/max31785
index e9edbf11948f..8e75efc5e4b9 100644
--- a/Documentation/hwmon/max31785
+++ b/Documentation/hwmon/max31785
@@ -17,8 +17,9 @@ management with temperature and remote voltage sensing. 
Various fan control
 features are provided, including PWM frequency control, temperature hysteresis,
 dual tachometer measurements, and fan health monitoring.
 
-For dual rotor fan configuration, the MAX31785 exposes the slowest rotor of the
-two in the fan[1-4]_input attributes.
+For dual-rotor configurations the MAX31785A exposes the second rotor tachometer
+readings in attributes fan[5-8]_input. By contrast the MAX31785 only exposes
+the slowest rotor measurement, and does so in the fan[1-4]_input attributes.
 
 Usage Notes
 ---
@@ -31,7 +32,8 @@ Sysfs attributes
 
 fan[1-4]_alarm Fan alarm.
 fan[1-4]_fault Fan fault.
-fan[1-4]_input Fan RPM.
+fan[1-8]_input Fan RPM. On the MAX31785A, inputs 5-8 correspond to the
+   second rotor of fans 1-4
 fan[1-4]_targetFan input target
 
 in[1-6]_crit   Critical maximum output voltage
diff --git a/drivers/hwmon/pmbus/max31785.c b/drivers/hwmon/pmbus/max31785.c
index 0d97ddf67079..2ca7febb2843 100644
--- a/drivers/hwmon/pmbus/max31785.c
+++ b/drivers/hwmon/pmbus/max31785.c
@@ -16,10 +16,82 @@
 
 enum max31785_regs {
MFR_REVISION= 0x9b,
+   MFR_FAN_CONFIG  = 0xf1,
 };
 
+#define MAX31785   0x3030
+#define MAX31785A  0x3040
+
+#define MFR_FAN_CONFIG_DUAL_TACH   BIT(12)
+
 #define MAX31785_NR_PAGES  23
 
+static int max31785_read_byte_data(struct i2c_client *client, int page,
+  int reg)
+{
+   switch (reg) {
+   case PMBUS_VOUT_MODE:
+   if (page < MAX31785_NR_PAGES)
+   return -ENODATA;
+
+   return -ENOTSUPP;
+   case PMBUS_FAN_CONFIG_12:
+   if (page < MAX31785_NR_PAGES)
+   return -ENODATA;
+
+   return pmbus_read_byte_data(client, page - MAX31785_NR_PAGES,
+   reg);
+   }
+
+   return -ENODATA;
+}
+
+static int max31785_write_byte(struct i2c_client *client, int page, u8 value)
+{
+   if (page < MAX31785_NR_PAGES)
+   return -ENODATA;
+
+   return -ENOTSUPP;
+}
+
+static int max31785_read_long_data(struct i2c_client *client, int page,
+  int reg, u32 *data)
+{
+   unsigned char cmdbuf[1];
+   unsigned char rspbuf[4];
+   int rc;
+
+   struct i2c_msg msg[2] = {
+   {
+   .addr = client->addr,
+   .flags = 0,
+   .len = sizeof(cmdbuf),
+   .buf = cmdbuf,
+   },
+   {
+   .addr = client->addr,
+   .flags = I2C_M_RD,
+   .len = sizeof(rspbuf),
+   .buf = rspbuf,
+   },
+   };
+
+   cmdbuf[0] = reg;
+
+   rc = pmbus_set_page(client, page);
+   if (rc < 0)
+   return rc;
+
+   rc = i2c_transfer(client->adapter, msg, ARRAY_SIZE(msg));
+   if (rc < 0)
+   return rc;
+
+   *data = (rspbuf[0] << (0 * 8)) | (rspbuf[1] << (1 * 8)) |
+   (rspbuf[2] << (2 * 8)) | (rspbuf[3] << (3 * 8));
+
+   return rc;
+}
+
 static int max31785_get_pwm(struct i2c_client *client, int page)
 {
int config;
@@ -76,7 +148,25 @@ static int max31785_read_word_data(struct i2c_client 
*client, int page,
int rv;
 
switch (reg) {
+   case PMBUS_READ_FAN_SPEED_1:
+   {
+   u32 val;
+
+   if (page < 

[PATCH v4 6/6] pmbus: max31785: Add dual tachometer support

[Andrew Jeffery]

The dual tachometer feature is implemented in hardware with a TACHSEL
input to indicate the rotor under measurement, and exposed on the device
by extending the READ_FAN_SPEED_1 word with two extra bytes*. The need
to read the non-standard four-byte response leads to a cut-down
implementation of i2c_smbus_xfer_emulated() included in the driver.
Further, to expose the second rotor tachometer value to userspace the
values are exposed through virtual pages. We re-route accesses to
FAN_CONFIG_1_2 and READ_FAN_SPEED_1 on undefined (in hardware) pages
23-28 to the same registers on pages 0-5, and with the latter command we
extract the value from the second word of the four-byte response.

* The documentation recommends the slower rotor be associated with
TACHSEL=0, which provides the first word of the response. The TACHSEL=0
measurement is used by the controller's closed-loop fan management.

Signed-off-by: Andrew Jeffery 
---
 Documentation/hwmon/max31785   |   8 ++-
 drivers/hwmon/pmbus/max31785.c | 159 -
 2 files changed, 163 insertions(+), 4 deletions(-)

diff --git a/Documentation/hwmon/max31785 b/Documentation/hwmon/max31785
index e9edbf11948f..8e75efc5e4b9 100644
--- a/Documentation/hwmon/max31785
+++ b/Documentation/hwmon/max31785
@@ -17,8 +17,9 @@ management with temperature and remote voltage sensing. 
Various fan control
 features are provided, including PWM frequency control, temperature hysteresis,
 dual tachometer measurements, and fan health monitoring.
 
-For dual rotor fan configuration, the MAX31785 exposes the slowest rotor of the
-two in the fan[1-4]_input attributes.
+For dual-rotor configurations the MAX31785A exposes the second rotor tachometer
+readings in attributes fan[5-8]_input. By contrast the MAX31785 only exposes
+the slowest rotor measurement, and does so in the fan[1-4]_input attributes.
 
 Usage Notes
 ---
@@ -31,7 +32,8 @@ Sysfs attributes
 
 fan[1-4]_alarm Fan alarm.
 fan[1-4]_fault Fan fault.
-fan[1-4]_input Fan RPM.
+fan[1-8]_input Fan RPM. On the MAX31785A, inputs 5-8 correspond to the
+   second rotor of fans 1-4
 fan[1-4]_targetFan input target
 
 in[1-6]_crit   Critical maximum output voltage
diff --git a/drivers/hwmon/pmbus/max31785.c b/drivers/hwmon/pmbus/max31785.c
index 0d97ddf67079..2ca7febb2843 100644
--- a/drivers/hwmon/pmbus/max31785.c
+++ b/drivers/hwmon/pmbus/max31785.c
@@ -16,10 +16,82 @@
 
 enum max31785_regs {
MFR_REVISION= 0x9b,
+   MFR_FAN_CONFIG  = 0xf1,
 };
 
+#define MAX31785   0x3030
+#define MAX31785A  0x3040
+
+#define MFR_FAN_CONFIG_DUAL_TACH   BIT(12)
+
 #define MAX31785_NR_PAGES  23
 
+static int max31785_read_byte_data(struct i2c_client *client, int page,
+  int reg)
+{
+   switch (reg) {
+   case PMBUS_VOUT_MODE:
+   if (page < MAX31785_NR_PAGES)
+   return -ENODATA;
+
+   return -ENOTSUPP;
+   case PMBUS_FAN_CONFIG_12:
+   if (page < MAX31785_NR_PAGES)
+   return -ENODATA;
+
+   return pmbus_read_byte_data(client, page - MAX31785_NR_PAGES,
+   reg);
+   }
+
+   return -ENODATA;
+}
+
+static int max31785_write_byte(struct i2c_client *client, int page, u8 value)
+{
+   if (page < MAX31785_NR_PAGES)
+   return -ENODATA;
+
+   return -ENOTSUPP;
+}
+
+static int max31785_read_long_data(struct i2c_client *client, int page,
+  int reg, u32 *data)
+{
+   unsigned char cmdbuf[1];
+   unsigned char rspbuf[4];
+   int rc;
+
+   struct i2c_msg msg[2] = {
+   {
+   .addr = client->addr,
+   .flags = 0,
+   .len = sizeof(cmdbuf),
+   .buf = cmdbuf,
+   },
+   {
+   .addr = client->addr,
+   .flags = I2C_M_RD,
+   .len = sizeof(rspbuf),
+   .buf = rspbuf,
+   },
+   };
+
+   cmdbuf[0] = reg;
+
+   rc = pmbus_set_page(client, page);
+   if (rc < 0)
+   return rc;
+
+   rc = i2c_transfer(client->adapter, msg, ARRAY_SIZE(msg));
+   if (rc < 0)
+   return rc;
+
+   *data = (rspbuf[0] << (0 * 8)) | (rspbuf[1] << (1 * 8)) |
+   (rspbuf[2] << (2 * 8)) | (rspbuf[3] << (3 * 8));
+
+   return rc;
+}
+
 static int max31785_get_pwm(struct i2c_client *client, int page)
 {
int config;
@@ -76,7 +148,25 @@ static int max31785_read_word_data(struct i2c_client 
*client, int page,
int rv;
 
switch (reg) {
+   case PMBUS_READ_FAN_SPEED_1:
+   {
+   u32 val;
+
+   if (page < MAX31785_NR_PAGES)
+ 

[PATCH v4 5/6] pmbus: core: Add virtual page config bit

[Andrew Jeffery]

Some circumstances call for virtual pages to expose multiple values
packed into an extended PMBus register in a manner non-compliant with
the PMBus standard. We should not try to set virtual pages on the
device; add a flag so we can avoid doing so.

Signed-off-by: Andrew Jeffery 
---
 drivers/hwmon/pmbus/pmbus.h  |  2 ++
 drivers/hwmon/pmbus/pmbus_core.c | 12 
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
index cdf3e288e626..0560a8dbcee0 100644
--- a/drivers/hwmon/pmbus/pmbus.h
+++ b/drivers/hwmon/pmbus/pmbus.h
@@ -367,6 +367,8 @@ enum pmbus_sensor_classes {
 #define PMBUS_HAVE_PWM12   BIT(20)
 #define PMBUS_HAVE_PWM34   BIT(21)
 
+#define PMBUS_PAGE_VIRTUAL BIT(31)
+
 enum pmbus_data_format { linear = 0, direct, vid };
 enum vrm_version { vr11 = 0, vr12, vr13 };
 
diff --git a/drivers/hwmon/pmbus/pmbus_core.c b/drivers/hwmon/pmbus/pmbus_core.c
index 55838b69e99a..af7362de405d 100644
--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -164,14 +164,18 @@ int pmbus_set_page(struct i2c_client *client, u8 page)
int rv = 0;
int newpage;
 
-   if (page != data->currpage) {
+   if (page == data->currpage)
+   return 0;
+
+   if (!(data->info->func[page] & PMBUS_PAGE_VIRTUAL)) {
rv = i2c_smbus_write_byte_data(client, PMBUS_PAGE, page);
newpage = i2c_smbus_read_byte_data(client, PMBUS_PAGE);
if (newpage != page)
-   rv = -EIO;
-   else
-   data->currpage = page;
+   return -EIO;
}
+
+   data->currpage = page;
+
return rv;
 }
 EXPORT_SYMBOL_GPL(pmbus_set_page);
-- 
2.11.0

[PATCH v4 5/6] pmbus: core: Add virtual page config bit

[Andrew Jeffery]

Some circumstances call for virtual pages to expose multiple values
packed into an extended PMBus register in a manner non-compliant with
the PMBus standard. We should not try to set virtual pages on the
device; add a flag so we can avoid doing so.

Signed-off-by: Andrew Jeffery 
---
 drivers/hwmon/pmbus/pmbus.h  |  2 ++
 drivers/hwmon/pmbus/pmbus_core.c | 12 
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
index cdf3e288e626..0560a8dbcee0 100644
--- a/drivers/hwmon/pmbus/pmbus.h
+++ b/drivers/hwmon/pmbus/pmbus.h
@@ -367,6 +367,8 @@ enum pmbus_sensor_classes {
 #define PMBUS_HAVE_PWM12   BIT(20)
 #define PMBUS_HAVE_PWM34   BIT(21)
 
+#define PMBUS_PAGE_VIRTUAL BIT(31)
+
 enum pmbus_data_format { linear = 0, direct, vid };
 enum vrm_version { vr11 = 0, vr12, vr13 };
 
diff --git a/drivers/hwmon/pmbus/pmbus_core.c b/drivers/hwmon/pmbus/pmbus_core.c
index 55838b69e99a..af7362de405d 100644
--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -164,14 +164,18 @@ int pmbus_set_page(struct i2c_client *client, u8 page)
int rv = 0;
int newpage;
 
-   if (page != data->currpage) {
+   if (page == data->currpage)
+   return 0;
+
+   if (!(data->info->func[page] & PMBUS_PAGE_VIRTUAL)) {
rv = i2c_smbus_write_byte_data(client, PMBUS_PAGE, page);
newpage = i2c_smbus_read_byte_data(client, PMBUS_PAGE);
if (newpage != page)
-   rv = -EIO;
-   else
-   data->currpage = page;
+   return -EIO;
}
+
+   data->currpage = page;
+
return rv;
 }
 EXPORT_SYMBOL_GPL(pmbus_set_page);
-- 
2.11.0

[PATCH v4 3/6] pmbus: core: Add fan control support

[Andrew Jeffery]

Expose fanX_target, pwmX and pwmX_enable hwmon sysfs attributes.

Fans in a PMBus device are driven by the configuration of two registers:
FAN_CONFIG_x_y and FAN_COMMAND_x: FAN_CONFIG_x_y dictates how the fan
and the tacho operate (if installed), while FAN_COMMAND_x sets the
desired fan rate. The unit of FAN_COMMAND_x is dependent on the
operational fan mode, RPM or PWM percent duty, as determined by the
corresponding FAN_CONFIG_x_y.

The mapping of fanX_target, pwmX and pwmX_enable onto FAN_CONFIG_x_y and
FAN_COMMAND_x is implemented with the addition of virtual registers and
generic implementations in the core:

1. PMBUS_VIRT_FAN_TARGET_x
2. PMBUS_VIRT_PWM_x
3. PMBUS_VIRT_PWM_ENABLE_x

The virtual registers facilitate the necessary side-effects of each
access. Examples of the read case, assuming m = 1, b = 0, R = 0:

 Read |  With  || Gives
 ---
   Attribute  | FAN_CONFIG_x_y | FAN_COMMAND_y || Value
 --++---
  fanX_target | ~PB_FAN_z_RPM  | 0x0001|| 1
  pwm1| ~PB_FAN_z_RPM  | 0x0064|| 255
  pwmX_enable | ~PB_FAN_z_RPM  | 0x0001|| 1
  fanX_target |  PB_FAN_z_RPM  | 0x0001|| 1
  pwm1|  PB_FAN_z_RPM  | 0x0064|| 0
  pwmX_enable |  PB_FAN_z_RPM  | 0x0001|| 1

And the write case:

 Write| With  ||   Sets
 -+---+++---
   Attribute  | Value || FAN_CONFIG_x_y | FAN_COMMAND_x
 -+---+++---
  fanX_target | 1 ||  PB_FAN_z_RPM  | 0x0001
  pwmX| 255   || ~PB_FAN_z_RPM  | 0x0064
  pwmX_enable | 1 || ~PB_FAN_z_RPM  | 0x0064

Also, the DIRECT mode scaling of some controllers is different between
RPM and PWM percent duty control modes, so PSC_PWM is introduced to
capture the necessary coefficients.

Signed-off-by: Andrew Jeffery 
---
 drivers/hwmon/pmbus/pmbus.h  |  29 +
 drivers/hwmon/pmbus/pmbus_core.c | 224 ---
 2 files changed, 238 insertions(+), 15 deletions(-)

diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
index 4efa2bd4f6d8..cdf3e288e626 100644
--- a/drivers/hwmon/pmbus/pmbus.h
+++ b/drivers/hwmon/pmbus/pmbus.h
@@ -190,6 +190,28 @@ enum pmbus_regs {
PMBUS_VIRT_VMON_UV_FAULT_LIMIT,
PMBUS_VIRT_VMON_OV_FAULT_LIMIT,
PMBUS_VIRT_STATUS_VMON,
+
+   /*
+* RPM and PWM Fan control
+*
+* Drivers wanting to expose PWM control must define the behaviour of
+* PMBUS_VIRT_PWM_ENABLE_[1-4] in the {read,write}_word_data callback.
+*
+* pmbus core provides default implementations for
+* PMBUS_VIRT_FAN_TARGET_[1-4] and PMBUS_VIRT_PWM_[1-4].
+*/
+   PMBUS_VIRT_FAN_TARGET_1,
+   PMBUS_VIRT_FAN_TARGET_2,
+   PMBUS_VIRT_FAN_TARGET_3,
+   PMBUS_VIRT_FAN_TARGET_4,
+   PMBUS_VIRT_PWM_1,
+   PMBUS_VIRT_PWM_2,
+   PMBUS_VIRT_PWM_3,
+   PMBUS_VIRT_PWM_4,
+   PMBUS_VIRT_PWM_ENABLE_1,
+   PMBUS_VIRT_PWM_ENABLE_2,
+   PMBUS_VIRT_PWM_ENABLE_3,
+   PMBUS_VIRT_PWM_ENABLE_4,
 };
 
 /*
@@ -223,6 +245,8 @@ enum pmbus_regs {
 #define PB_FAN_1_RPM   BIT(6)
 #define PB_FAN_1_INSTALLED BIT(7)
 
+enum pmbus_fan_mode { percent = 0, rpm };
+
 /*
  * STATUS_BYTE, STATUS_WORD (lower)
  */
@@ -313,6 +337,7 @@ enum pmbus_sensor_classes {
PSC_POWER,
PSC_TEMPERATURE,
PSC_FAN,
+   PSC_PWM,
PSC_NUM_CLASSES /* Number of power sensor classes */
 };
 
@@ -339,6 +364,8 @@ enum pmbus_sensor_classes {
 #define PMBUS_HAVE_STATUS_FAN34BIT(17)
 #define PMBUS_HAVE_VMONBIT(18)
 #define PMBUS_HAVE_STATUS_VMON BIT(19)
+#define PMBUS_HAVE_PWM12   BIT(20)
+#define PMBUS_HAVE_PWM34   BIT(21)
 
 enum pmbus_data_format { linear = 0, direct, vid };
 enum vrm_version { vr11 = 0, vr12, vr13 };
@@ -413,6 +440,8 @@ int pmbus_write_byte_data(struct i2c_client *client, int 
page, u8 reg,
  u8 value);
 int pmbus_update_byte_data(struct i2c_client *client, int page, u8 reg,
   u8 mask, u8 value);
+int pmbus_update_fan(struct i2c_client *client, int page, int id,
+u8 config, u8 mask, u16 command);
 void pmbus_clear_faults(struct i2c_client *client);
 bool pmbus_check_byte_register(struct i2c_client *client, int page, int reg);
 bool pmbus_check_word_register(struct i2c_client *client, int page, int reg);
diff --git a/drivers/hwmon/pmbus/pmbus_core.c b/drivers/hwmon/pmbus/pmbus_core.c
index 302f0aef59de..55838b69e99a 100644
--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -64,6 +64,7 @@ struct pmbus_sensor {
u16 reg;   

[PATCH v4 3/6] pmbus: core: Add fan control support

[Andrew Jeffery]

Expose fanX_target, pwmX and pwmX_enable hwmon sysfs attributes.

Fans in a PMBus device are driven by the configuration of two registers:
FAN_CONFIG_x_y and FAN_COMMAND_x: FAN_CONFIG_x_y dictates how the fan
and the tacho operate (if installed), while FAN_COMMAND_x sets the
desired fan rate. The unit of FAN_COMMAND_x is dependent on the
operational fan mode, RPM or PWM percent duty, as determined by the
corresponding FAN_CONFIG_x_y.

The mapping of fanX_target, pwmX and pwmX_enable onto FAN_CONFIG_x_y and
FAN_COMMAND_x is implemented with the addition of virtual registers and
generic implementations in the core:

1. PMBUS_VIRT_FAN_TARGET_x
2. PMBUS_VIRT_PWM_x
3. PMBUS_VIRT_PWM_ENABLE_x

The virtual registers facilitate the necessary side-effects of each
access. Examples of the read case, assuming m = 1, b = 0, R = 0:

 Read |  With  || Gives
 ---
   Attribute  | FAN_CONFIG_x_y | FAN_COMMAND_y || Value
 --++---
  fanX_target | ~PB_FAN_z_RPM  | 0x0001|| 1
  pwm1| ~PB_FAN_z_RPM  | 0x0064|| 255
  pwmX_enable | ~PB_FAN_z_RPM  | 0x0001|| 1
  fanX_target |  PB_FAN_z_RPM  | 0x0001|| 1
  pwm1|  PB_FAN_z_RPM  | 0x0064|| 0
  pwmX_enable |  PB_FAN_z_RPM  | 0x0001|| 1

And the write case:

 Write| With  ||   Sets
 -+---+++---
   Attribute  | Value || FAN_CONFIG_x_y | FAN_COMMAND_x
 -+---+++---
  fanX_target | 1 ||  PB_FAN_z_RPM  | 0x0001
  pwmX| 255   || ~PB_FAN_z_RPM  | 0x0064
  pwmX_enable | 1 || ~PB_FAN_z_RPM  | 0x0064

Also, the DIRECT mode scaling of some controllers is different between
RPM and PWM percent duty control modes, so PSC_PWM is introduced to
capture the necessary coefficients.

Signed-off-by: Andrew Jeffery 
---
 drivers/hwmon/pmbus/pmbus.h  |  29 +
 drivers/hwmon/pmbus/pmbus_core.c | 224 ---
 2 files changed, 238 insertions(+), 15 deletions(-)

diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
index 4efa2bd4f6d8..cdf3e288e626 100644
--- a/drivers/hwmon/pmbus/pmbus.h
+++ b/drivers/hwmon/pmbus/pmbus.h
@@ -190,6 +190,28 @@ enum pmbus_regs {
PMBUS_VIRT_VMON_UV_FAULT_LIMIT,
PMBUS_VIRT_VMON_OV_FAULT_LIMIT,
PMBUS_VIRT_STATUS_VMON,
+
+   /*
+* RPM and PWM Fan control
+*
+* Drivers wanting to expose PWM control must define the behaviour of
+* PMBUS_VIRT_PWM_ENABLE_[1-4] in the {read,write}_word_data callback.
+*
+* pmbus core provides default implementations for
+* PMBUS_VIRT_FAN_TARGET_[1-4] and PMBUS_VIRT_PWM_[1-4].
+*/
+   PMBUS_VIRT_FAN_TARGET_1,
+   PMBUS_VIRT_FAN_TARGET_2,
+   PMBUS_VIRT_FAN_TARGET_3,
+   PMBUS_VIRT_FAN_TARGET_4,
+   PMBUS_VIRT_PWM_1,
+   PMBUS_VIRT_PWM_2,
+   PMBUS_VIRT_PWM_3,
+   PMBUS_VIRT_PWM_4,
+   PMBUS_VIRT_PWM_ENABLE_1,
+   PMBUS_VIRT_PWM_ENABLE_2,
+   PMBUS_VIRT_PWM_ENABLE_3,
+   PMBUS_VIRT_PWM_ENABLE_4,
 };
 
 /*
@@ -223,6 +245,8 @@ enum pmbus_regs {
 #define PB_FAN_1_RPM   BIT(6)
 #define PB_FAN_1_INSTALLED BIT(7)
 
+enum pmbus_fan_mode { percent = 0, rpm };
+
 /*
  * STATUS_BYTE, STATUS_WORD (lower)
  */
@@ -313,6 +337,7 @@ enum pmbus_sensor_classes {
PSC_POWER,
PSC_TEMPERATURE,
PSC_FAN,
+   PSC_PWM,
PSC_NUM_CLASSES /* Number of power sensor classes */
 };
 
@@ -339,6 +364,8 @@ enum pmbus_sensor_classes {
 #define PMBUS_HAVE_STATUS_FAN34BIT(17)
 #define PMBUS_HAVE_VMONBIT(18)
 #define PMBUS_HAVE_STATUS_VMON BIT(19)
+#define PMBUS_HAVE_PWM12   BIT(20)
+#define PMBUS_HAVE_PWM34   BIT(21)
 
 enum pmbus_data_format { linear = 0, direct, vid };
 enum vrm_version { vr11 = 0, vr12, vr13 };
@@ -413,6 +440,8 @@ int pmbus_write_byte_data(struct i2c_client *client, int 
page, u8 reg,
  u8 value);
 int pmbus_update_byte_data(struct i2c_client *client, int page, u8 reg,
   u8 mask, u8 value);
+int pmbus_update_fan(struct i2c_client *client, int page, int id,
+u8 config, u8 mask, u16 command);
 void pmbus_clear_faults(struct i2c_client *client);
 bool pmbus_check_byte_register(struct i2c_client *client, int page, int reg);
 bool pmbus_check_word_register(struct i2c_client *client, int page, int reg);
diff --git a/drivers/hwmon/pmbus/pmbus_core.c b/drivers/hwmon/pmbus/pmbus_core.c
index 302f0aef59de..55838b69e99a 100644
--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -64,6 +64,7 @@ struct pmbus_sensor {
u16 reg;/* 

[PATCH v4 2/6] pmbus: Add driver for Maxim MAX31785 Intelligent Fan Controller

[Andrew Jeffery]

The Maxim MAX31785 is a PMBus device providing closed-loop, multi-channel fan
management with temperature and remote voltage sensing. Various fan control
features are provided, including PWM frequency control, temperature hysteresis,
dual tachometer measurements, and fan health monitoring.

This patch presents a basic driver using only the existing features of the
PMBus subsystem.

Signed-off-by: Andrew Jeffery 
---
 Documentation/hwmon/max31785   |  51 ++
 drivers/hwmon/pmbus/Kconfig|  10 
 drivers/hwmon/pmbus/Makefile   |   1 +
 drivers/hwmon/pmbus/max31785.c | 116 +
 4 files changed, 178 insertions(+)
 create mode 100644 Documentation/hwmon/max31785
 create mode 100644 drivers/hwmon/pmbus/max31785.c

diff --git a/Documentation/hwmon/max31785 b/Documentation/hwmon/max31785
new file mode 100644
index ..45fb6093dec2
--- /dev/null
+++ b/Documentation/hwmon/max31785
@@ -0,0 +1,51 @@
+Kernel driver max31785
+==
+
+Supported chips:
+  * Maxim MAX31785, MAX31785A
+Prefix: 'max31785' or 'max31785a'
+Addresses scanned: -
+Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX31785.pdf
+
+Author: Andrew Jeffery 
+
+Description
+---
+
+The Maxim MAX31785 is a PMBus device providing closed-loop, multi-channel fan
+management with temperature and remote voltage sensing. Various fan control
+features are provided, including PWM frequency control, temperature hysteresis,
+dual tachometer measurements, and fan health monitoring.
+
+For dual rotor fan configuration, the MAX31785 exposes the slowest rotor of the
+two in the fan[1-4]_input attributes.
+
+Usage Notes
+---
+
+This driver does not probe for PMBus devices. You will have to instantiate
+devices explicitly.
+
+Sysfs attributes
+
+
+fan[1-4]_alarm Fan alarm.
+fan[1-4]_fault Fan fault.
+fan[1-4]_input Fan RPM.
+
+in[1-6]_crit   Critical maximum output voltage
+in[1-6]_crit_alarm Output voltage critical high alarm
+in[1-6]_input  Measured output voltage
+in[1-6]_label  "vout[18-23]"
+in[1-6]_lcrit  Critical minimum output voltage
+in[1-6]_lcrit_alarmOutput voltage critical low alarm
+in[1-6]_maxMaximum output voltage
+in[1-6]_max_alarm  Output voltage high alarm
+in[1-6]_minMinimum output voltage
+in[1-6]_min_alarm  Output voltage low alarm
+
+temp[1-11]_critCritical high temperature
+temp[1-11]_crit_alarm  Chip temperature critical high alarm
+temp[1-11]_input   Measured temperature
+temp[1-11]_max Maximum temperature
+temp[1-11]_max_alarm   Chip temperature high alarm
diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index 40019325b517..08479006c7f9 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -114,6 +114,16 @@ config SENSORS_MAX20751
  This driver can also be built as a module. If so, the module will
  be called max20751.
 
+config SENSORS_MAX31785
+   tristate "Maxim MAX31785 and compatibles"
+   default n
+   help
+ If you say yes here you get hardware monitoring support for Maxim
+ MAX31785.
+
+ This driver can also be built as a module. If so, the module will
+ be called max31785.
+
 config SENSORS_MAX34440
tristate "Maxim MAX34440 and compatibles"
default n
diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
index 459a6be3390e..a8bf0e490db9 100644
--- a/drivers/hwmon/pmbus/Makefile
+++ b/drivers/hwmon/pmbus/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_SENSORS_LTC2978) += ltc2978.o
 obj-$(CONFIG_SENSORS_LTC3815)  += ltc3815.o
 obj-$(CONFIG_SENSORS_MAX16064) += max16064.o
 obj-$(CONFIG_SENSORS_MAX20751) += max20751.o
+obj-$(CONFIG_SENSORS_MAX31785) += max31785.o
 obj-$(CONFIG_SENSORS_MAX34440) += max34440.o
 obj-$(CONFIG_SENSORS_MAX8688)  += max8688.o
 obj-$(CONFIG_SENSORS_TPS40422) += tps40422.o
diff --git a/drivers/hwmon/pmbus/max31785.c b/drivers/hwmon/pmbus/max31785.c
new file mode 100644
index ..9313849d5160
--- /dev/null
+++ b/drivers/hwmon/pmbus/max31785.c
@@ -0,0 +1,116 @@
+/*
+ * Copyright (C) 2017 IBM Corp.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "pmbus.h"
+
+enum max31785_regs {
+   MFR_REVISION= 0x9b,
+};
+
+#define MAX31785_NR_PAGES  23
+
+#define MAX31785_FAN_FUNCS \
+   (PMBUS_HAVE_FAN12 | PMBUS_HAVE_STATUS_FAN12)
+
+#define MAX31785_TEMP_FUNCS \
+   (PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP)
+
+#define MAX31785_VOUT_FUNCS \
+   (PMBUS_HAVE_VOUT | 

[PATCH v4 2/6] pmbus: Add driver for Maxim MAX31785 Intelligent Fan Controller

[Andrew Jeffery]

The Maxim MAX31785 is a PMBus device providing closed-loop, multi-channel fan
management with temperature and remote voltage sensing. Various fan control
features are provided, including PWM frequency control, temperature hysteresis,
dual tachometer measurements, and fan health monitoring.

This patch presents a basic driver using only the existing features of the
PMBus subsystem.

Signed-off-by: Andrew Jeffery 
---
 Documentation/hwmon/max31785   |  51 ++
 drivers/hwmon/pmbus/Kconfig|  10 
 drivers/hwmon/pmbus/Makefile   |   1 +
 drivers/hwmon/pmbus/max31785.c | 116 +
 4 files changed, 178 insertions(+)
 create mode 100644 Documentation/hwmon/max31785
 create mode 100644 drivers/hwmon/pmbus/max31785.c

diff --git a/Documentation/hwmon/max31785 b/Documentation/hwmon/max31785
new file mode 100644
index ..45fb6093dec2
--- /dev/null
+++ b/Documentation/hwmon/max31785
@@ -0,0 +1,51 @@
+Kernel driver max31785
+==
+
+Supported chips:
+  * Maxim MAX31785, MAX31785A
+Prefix: 'max31785' or 'max31785a'
+Addresses scanned: -
+Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX31785.pdf
+
+Author: Andrew Jeffery 
+
+Description
+---
+
+The Maxim MAX31785 is a PMBus device providing closed-loop, multi-channel fan
+management with temperature and remote voltage sensing. Various fan control
+features are provided, including PWM frequency control, temperature hysteresis,
+dual tachometer measurements, and fan health monitoring.
+
+For dual rotor fan configuration, the MAX31785 exposes the slowest rotor of the
+two in the fan[1-4]_input attributes.
+
+Usage Notes
+---
+
+This driver does not probe for PMBus devices. You will have to instantiate
+devices explicitly.
+
+Sysfs attributes
+
+
+fan[1-4]_alarm Fan alarm.
+fan[1-4]_fault Fan fault.
+fan[1-4]_input Fan RPM.
+
+in[1-6]_crit   Critical maximum output voltage
+in[1-6]_crit_alarm Output voltage critical high alarm
+in[1-6]_input  Measured output voltage
+in[1-6]_label  "vout[18-23]"
+in[1-6]_lcrit  Critical minimum output voltage
+in[1-6]_lcrit_alarmOutput voltage critical low alarm
+in[1-6]_maxMaximum output voltage
+in[1-6]_max_alarm  Output voltage high alarm
+in[1-6]_minMinimum output voltage
+in[1-6]_min_alarm  Output voltage low alarm
+
+temp[1-11]_critCritical high temperature
+temp[1-11]_crit_alarm  Chip temperature critical high alarm
+temp[1-11]_input   Measured temperature
+temp[1-11]_max Maximum temperature
+temp[1-11]_max_alarm   Chip temperature high alarm
diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index 40019325b517..08479006c7f9 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -114,6 +114,16 @@ config SENSORS_MAX20751
  This driver can also be built as a module. If so, the module will
  be called max20751.
 
+config SENSORS_MAX31785
+   tristate "Maxim MAX31785 and compatibles"
+   default n
+   help
+ If you say yes here you get hardware monitoring support for Maxim
+ MAX31785.
+
+ This driver can also be built as a module. If so, the module will
+ be called max31785.
+
 config SENSORS_MAX34440
tristate "Maxim MAX34440 and compatibles"
default n
diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
index 459a6be3390e..a8bf0e490db9 100644
--- a/drivers/hwmon/pmbus/Makefile
+++ b/drivers/hwmon/pmbus/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_SENSORS_LTC2978) += ltc2978.o
 obj-$(CONFIG_SENSORS_LTC3815)  += ltc3815.o
 obj-$(CONFIG_SENSORS_MAX16064) += max16064.o
 obj-$(CONFIG_SENSORS_MAX20751) += max20751.o
+obj-$(CONFIG_SENSORS_MAX31785) += max31785.o
 obj-$(CONFIG_SENSORS_MAX34440) += max34440.o
 obj-$(CONFIG_SENSORS_MAX8688)  += max8688.o
 obj-$(CONFIG_SENSORS_TPS40422) += tps40422.o
diff --git a/drivers/hwmon/pmbus/max31785.c b/drivers/hwmon/pmbus/max31785.c
new file mode 100644
index ..9313849d5160
--- /dev/null
+++ b/drivers/hwmon/pmbus/max31785.c
@@ -0,0 +1,116 @@
+/*
+ * Copyright (C) 2017 IBM Corp.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "pmbus.h"
+
+enum max31785_regs {
+   MFR_REVISION= 0x9b,
+};
+
+#define MAX31785_NR_PAGES  23
+
+#define MAX31785_FAN_FUNCS \
+   (PMBUS_HAVE_FAN12 | PMBUS_HAVE_STATUS_FAN12)
+
+#define MAX31785_TEMP_FUNCS \
+   (PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP)
+
+#define MAX31785_VOUT_FUNCS \
+   (PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT)
+
+static const struct 

[PATCH v4 4/6] pmbus: max31785: Add fan control

[Andrew Jeffery]

The implementation makes use of the new fan control virtual registers
exposed by the pmbus core. It mixes use of the default implementations
with some overrides via the read/write handlers to handle FAN_COMMAND_1
on the MAX31785, whose definition breaks the value range into various
control bands dependent on RPM or PWM mode.

Signed-off-by: Andrew Jeffery 
---
 Documentation/hwmon/max31785   |   4 ++
 drivers/hwmon/pmbus/max31785.c | 104 -
 2 files changed, 107 insertions(+), 1 deletion(-)

diff --git a/Documentation/hwmon/max31785 b/Documentation/hwmon/max31785
index 45fb6093dec2..e9edbf11948f 100644
--- a/Documentation/hwmon/max31785
+++ b/Documentation/hwmon/max31785
@@ -32,6 +32,7 @@ Sysfs attributes
 fan[1-4]_alarm Fan alarm.
 fan[1-4]_fault Fan fault.
 fan[1-4]_input Fan RPM.
+fan[1-4]_targetFan input target
 
 in[1-6]_crit   Critical maximum output voltage
 in[1-6]_crit_alarm Output voltage critical high alarm
@@ -44,6 +45,9 @@ in[1-6]_max_alarm Output voltage high alarm
 in[1-6]_minMinimum output voltage
 in[1-6]_min_alarm  Output voltage low alarm
 
+pwm[1-4]   Fan target duty cycle (0..255)
+pwm[1-4]_enable0: full-speed, 1: manual control, 2: automatic
+
 temp[1-11]_critCritical high temperature
 temp[1-11]_crit_alarm  Chip temperature critical high alarm
 temp[1-11]_input   Measured temperature
diff --git a/drivers/hwmon/pmbus/max31785.c b/drivers/hwmon/pmbus/max31785.c
index 9313849d5160..0d97ddf67079 100644
--- a/drivers/hwmon/pmbus/max31785.c
+++ b/drivers/hwmon/pmbus/max31785.c
@@ -20,8 +20,102 @@ enum max31785_regs {
 
 #define MAX31785_NR_PAGES  23
 
+static int max31785_get_pwm(struct i2c_client *client, int page)
+{
+   int config;
+   int command;
+
+   config = pmbus_read_byte_data(client, page, PMBUS_FAN_CONFIG_12);
+   if (config < 0)
+   return config;
+
+   command = pmbus_read_word_data(client, page, PMBUS_FAN_COMMAND_1);
+   if (command < 0)
+   return command;
+
+   if (!(config & PB_FAN_1_RPM)) {
+   if (command >= 0x8000)
+   return 0;
+   else if (command >= 0x2711)
+   return 0x2710;
+
+   return command;
+   }
+
+   return 0;
+}
+
+static int max31785_get_pwm_mode(struct i2c_client *client, int page)
+{
+   int config;
+   int command;
+
+   config = pmbus_read_byte_data(client, page, PMBUS_FAN_CONFIG_12);
+   if (config < 0)
+   return config;
+
+   command = pmbus_read_word_data(client, page, PMBUS_FAN_COMMAND_1);
+   if (command < 0)
+   return command;
+
+   if (!(config & PB_FAN_1_RPM)) {
+   if (command >= 0x8000)
+   return 2;
+   else if (command >= 0x2711)
+   return 0;
+
+   return 1;
+   }
+
+   return (command >= 0x8000) ? 2 : 1;
+}
+
+static int max31785_read_word_data(struct i2c_client *client, int page,
+  int reg)
+{
+   int rv;
+
+   switch (reg) {
+   case PMBUS_VIRT_PWM_1:
+   rv = max31785_get_pwm(client, page);
+   if (rv < 0)
+   return rv;
+
+   rv *= 255;
+   rv /= 100;
+   break;
+   case PMBUS_VIRT_PWM_ENABLE_1:
+   rv = max31785_get_pwm_mode(client, page);
+   break;
+   default:
+   rv = -ENODATA;
+   break;
+   }
+
+   return rv;
+}
+
+static const int max31785_pwm_modes[] = { 0x7fff, 0x2710, 0x };
+
+static int max31785_write_word_data(struct i2c_client *client, int page,
+   int reg, u16 word)
+{
+   switch (reg) {
+   case PMBUS_VIRT_PWM_ENABLE_1:
+   if (word >= ARRAY_SIZE(max31785_pwm_modes))
+   return -EINVAL;
+
+   return pmbus_update_fan(client, page, 0, 0, PB_FAN_1_RPM,
+   max31785_pwm_modes[word]);
+   default:
+   break;
+   }
+
+   return -ENODATA;
+}
+
 #define MAX31785_FAN_FUNCS \
-   (PMBUS_HAVE_FAN12 | PMBUS_HAVE_STATUS_FAN12)
+   (PMBUS_HAVE_FAN12 | PMBUS_HAVE_STATUS_FAN12 | PMBUS_HAVE_PWM12)
 
 #define MAX31785_TEMP_FUNCS \
(PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP)
@@ -32,11 +126,19 @@ enum max31785_regs {
 static const struct pmbus_driver_info max31785_info = {
.pages = MAX31785_NR_PAGES,
 
+   .write_word_data = max31785_write_word_data,
+   .read_word_data = max31785_read_word_data,
+
/* RPM */
.format[PSC_FAN] = direct,
.m[PSC_FAN] = 1,
.b[PSC_FAN] = 0,
.R[PSC_FAN] = 0,
+   /* PWM */
+   .format[PSC_PWM] = direct,
+   .m[PSC_PWM] = 1,
+   .b[PSC_PWM] = 

[PATCH v4 4/6] pmbus: max31785: Add fan control

[Andrew Jeffery]

The implementation makes use of the new fan control virtual registers
exposed by the pmbus core. It mixes use of the default implementations
with some overrides via the read/write handlers to handle FAN_COMMAND_1
on the MAX31785, whose definition breaks the value range into various
control bands dependent on RPM or PWM mode.

Signed-off-by: Andrew Jeffery 
---
 Documentation/hwmon/max31785   |   4 ++
 drivers/hwmon/pmbus/max31785.c | 104 -
 2 files changed, 107 insertions(+), 1 deletion(-)

diff --git a/Documentation/hwmon/max31785 b/Documentation/hwmon/max31785
index 45fb6093dec2..e9edbf11948f 100644
--- a/Documentation/hwmon/max31785
+++ b/Documentation/hwmon/max31785
@@ -32,6 +32,7 @@ Sysfs attributes
 fan[1-4]_alarm Fan alarm.
 fan[1-4]_fault Fan fault.
 fan[1-4]_input Fan RPM.
+fan[1-4]_targetFan input target
 
 in[1-6]_crit   Critical maximum output voltage
 in[1-6]_crit_alarm Output voltage critical high alarm
@@ -44,6 +45,9 @@ in[1-6]_max_alarm Output voltage high alarm
 in[1-6]_minMinimum output voltage
 in[1-6]_min_alarm  Output voltage low alarm
 
+pwm[1-4]   Fan target duty cycle (0..255)
+pwm[1-4]_enable0: full-speed, 1: manual control, 2: automatic
+
 temp[1-11]_critCritical high temperature
 temp[1-11]_crit_alarm  Chip temperature critical high alarm
 temp[1-11]_input   Measured temperature
diff --git a/drivers/hwmon/pmbus/max31785.c b/drivers/hwmon/pmbus/max31785.c
index 9313849d5160..0d97ddf67079 100644
--- a/drivers/hwmon/pmbus/max31785.c
+++ b/drivers/hwmon/pmbus/max31785.c
@@ -20,8 +20,102 @@ enum max31785_regs {
 
 #define MAX31785_NR_PAGES  23
 
+static int max31785_get_pwm(struct i2c_client *client, int page)
+{
+   int config;
+   int command;
+
+   config = pmbus_read_byte_data(client, page, PMBUS_FAN_CONFIG_12);
+   if (config < 0)
+   return config;
+
+   command = pmbus_read_word_data(client, page, PMBUS_FAN_COMMAND_1);
+   if (command < 0)
+   return command;
+
+   if (!(config & PB_FAN_1_RPM)) {
+   if (command >= 0x8000)
+   return 0;
+   else if (command >= 0x2711)
+   return 0x2710;
+
+   return command;
+   }
+
+   return 0;
+}
+
+static int max31785_get_pwm_mode(struct i2c_client *client, int page)
+{
+   int config;
+   int command;
+
+   config = pmbus_read_byte_data(client, page, PMBUS_FAN_CONFIG_12);
+   if (config < 0)
+   return config;
+
+   command = pmbus_read_word_data(client, page, PMBUS_FAN_COMMAND_1);
+   if (command < 0)
+   return command;
+
+   if (!(config & PB_FAN_1_RPM)) {
+   if (command >= 0x8000)
+   return 2;
+   else if (command >= 0x2711)
+   return 0;
+
+   return 1;
+   }
+
+   return (command >= 0x8000) ? 2 : 1;
+}
+
+static int max31785_read_word_data(struct i2c_client *client, int page,
+  int reg)
+{
+   int rv;
+
+   switch (reg) {
+   case PMBUS_VIRT_PWM_1:
+   rv = max31785_get_pwm(client, page);
+   if (rv < 0)
+   return rv;
+
+   rv *= 255;
+   rv /= 100;
+   break;
+   case PMBUS_VIRT_PWM_ENABLE_1:
+   rv = max31785_get_pwm_mode(client, page);
+   break;
+   default:
+   rv = -ENODATA;
+   break;
+   }
+
+   return rv;
+}
+
+static const int max31785_pwm_modes[] = { 0x7fff, 0x2710, 0x };
+
+static int max31785_write_word_data(struct i2c_client *client, int page,
+   int reg, u16 word)
+{
+   switch (reg) {
+   case PMBUS_VIRT_PWM_ENABLE_1:
+   if (word >= ARRAY_SIZE(max31785_pwm_modes))
+   return -EINVAL;
+
+   return pmbus_update_fan(client, page, 0, 0, PB_FAN_1_RPM,
+   max31785_pwm_modes[word]);
+   default:
+   break;
+   }
+
+   return -ENODATA;
+}
+
 #define MAX31785_FAN_FUNCS \
-   (PMBUS_HAVE_FAN12 | PMBUS_HAVE_STATUS_FAN12)
+   (PMBUS_HAVE_FAN12 | PMBUS_HAVE_STATUS_FAN12 | PMBUS_HAVE_PWM12)
 
 #define MAX31785_TEMP_FUNCS \
(PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP)
@@ -32,11 +126,19 @@ enum max31785_regs {
 static const struct pmbus_driver_info max31785_info = {
.pages = MAX31785_NR_PAGES,
 
+   .write_word_data = max31785_write_word_data,
+   .read_word_data = max31785_read_word_data,
+
/* RPM */
.format[PSC_FAN] = direct,
.m[PSC_FAN] = 1,
.b[PSC_FAN] = 0,
.R[PSC_FAN] = 0,
+   /* PWM */
+   .format[PSC_PWM] = direct,
+   .m[PSC_PWM] = 1,
+   .b[PSC_PWM] = 0,
+   

Re: [PATCH v2] f2fs: fix out-of-free problem caused by atomic write

[Yunlong Song]

Because I found that it will still lead to out-of-free problem with out 
that check.
I trace and find that it is possible that the committing date pages of 
the atomic
file is bigger than the sbi->user_block_count - valid_user_blocks(sbi), 
so I add

this check.

On 2017/11/3 11:46, Jaegeuk Kim wrote:

On 10/30, Yunlong Song wrote:

f2fs_balance_fs only actives once in the commit_inmem_pages, but there
are more than one page to commit, so all the other pages will miss the
check. This will lead to out-of-free problem when commit a very large
file. However, we cannot do f2fs_balance_fs for each inmem page, since
this will break atomicity. As a result, we should collect prefree
segments if needed and stop atomic commit when there are not enough
available blocks to write atomic pages.

Signed-off-by: Yunlong Song 
---
  fs/f2fs/f2fs.h|  1 +
  fs/f2fs/segment.c | 29 -
  2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 13a96b8..04ce48f 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -610,6 +610,7 @@ struct f2fs_inode_info {
struct list_head inmem_pages;   /* inmemory pages managed by f2fs */
struct task_struct *inmem_task; /* store inmemory task */
struct mutex inmem_lock;/* lock for inmemory pages */
+   unsigned long inmem_blocks; /* inmemory blocks */
struct extent_tree *extent_tree;/* cached extent_tree entry */
struct rw_semaphore dio_rwsem[2];/* avoid racing between dio and gc */
struct rw_semaphore i_mmap_sem;
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 46dfbca..813c110 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -210,6 +210,7 @@ void register_inmem_page(struct inode *inode, struct page 
*page)
list_add_tail(>inmem_ilist, >inode_list[ATOMIC_FILE]);
spin_unlock(>inode_lock[ATOMIC_FILE]);
inc_page_count(F2FS_I_SB(inode), F2FS_INMEM_PAGES);
+   fi->inmem_blocks++;
mutex_unlock(>inmem_lock);
  
  	trace_f2fs_register_inmem_page(page, INMEM);

@@ -221,6 +222,7 @@ static int __revoke_inmem_pages(struct inode *inode,
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
struct inmem_pages *cur, *tmp;
int err = 0;
+   struct f2fs_inode_info *fi = F2FS_I(inode);
  
  	list_for_each_entry_safe(cur, tmp, head, list) {

struct page *page = cur->page;
@@ -263,6 +265,7 @@ static int __revoke_inmem_pages(struct inode *inode,
list_del(>list);
kmem_cache_free(inmem_entry_slab, cur);
dec_page_count(F2FS_I_SB(inode), F2FS_INMEM_PAGES);
+   fi->inmem_blocks--;
}
return err;
  }
@@ -302,6 +305,10 @@ void drop_inmem_pages(struct inode *inode)
if (!list_empty(>inmem_ilist))
list_del_init(>inmem_ilist);
spin_unlock(>inode_lock[ATOMIC_FILE]);
+   if (fi->inmem_blocks) {
+   f2fs_bug_on(sbi, 1);
+   fi->inmem_blocks = 0;
+   }
mutex_unlock(>inmem_lock);
  
  	clear_inode_flag(inode, FI_ATOMIC_FILE);

@@ -326,6 +333,7 @@ void drop_inmem_page(struct inode *inode, struct page *page)
  
  	f2fs_bug_on(sbi, !cur || cur->page != page);

list_del(>list);
+   fi->inmem_blocks--;
mutex_unlock(>inmem_lock);
  
  	dec_page_count(sbi, F2FS_INMEM_PAGES);

@@ -410,11 +418,26 @@ int commit_inmem_pages(struct inode *inode)
  
  	INIT_LIST_HEAD(_list);

f2fs_balance_fs(sbi, true);
+   if (prefree_segments(sbi)
+   && has_not_enough_free_secs(sbi, 0,
+   fi->inmem_blocks / BLKS_PER_SEC(sbi))) {
+   struct cp_control cpc;
+
+   cpc.reason = __get_cp_reason(sbi);
+   err = write_checkpoint(sbi, );
+   if (err)
+   goto drop;
+   }
f2fs_lock_op(sbi);
  
  	set_inode_flag(inode, FI_ATOMIC_COMMIT);
  
  	mutex_lock(>inmem_lock);

+   if ((sbi->user_block_count - valid_user_blocks(sbi)) <

What does this mean? We already allocated blocks successfully?


+   fi->inmem_blocks) {
+   err = -ENOSPC;
+   goto drop;
+   }
err = __commit_inmem_pages(inode, _list);
if (err) {
int ret;
@@ -429,7 +452,7 @@ int commit_inmem_pages(struct inode *inode)
ret = __revoke_inmem_pages(inode, _list, false, true);
if (ret)
err = ret;
-
+drop:
/* drop all uncommitted pages */
__revoke_inmem_pages(inode, >inmem_pages, true, false);
}
@@ -437,6 +460,10 @@ int commit_inmem_pages(struct inode *inode)
if (!list_empty(>inmem_ilist))
list_del_init(>inmem_ilist);
spin_unlock(>inode_lock[ATOMIC_FILE]);
+   if (fi->inmem_blocks) {
+   f2fs_bug_on(sbi, 1);
+   fi->inmem_blocks = 0;
+   }
   

Re: [PATCH v2] f2fs: fix out-of-free problem caused by atomic write

[Yunlong Song]

Because I found that it will still lead to out-of-free problem with out 
that check.
I trace and find that it is possible that the committing date pages of 
the atomic
file is bigger than the sbi->user_block_count - valid_user_blocks(sbi), 
so I add

this check.

On 2017/11/3 11:46, Jaegeuk Kim wrote:

On 10/30, Yunlong Song wrote:

f2fs_balance_fs only actives once in the commit_inmem_pages, but there
are more than one page to commit, so all the other pages will miss the
check. This will lead to out-of-free problem when commit a very large
file. However, we cannot do f2fs_balance_fs for each inmem page, since
this will break atomicity. As a result, we should collect prefree
segments if needed and stop atomic commit when there are not enough
available blocks to write atomic pages.

Signed-off-by: Yunlong Song 
---
  fs/f2fs/f2fs.h|  1 +
  fs/f2fs/segment.c | 29 -
  2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 13a96b8..04ce48f 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -610,6 +610,7 @@ struct f2fs_inode_info {
struct list_head inmem_pages;   /* inmemory pages managed by f2fs */
struct task_struct *inmem_task; /* store inmemory task */
struct mutex inmem_lock;/* lock for inmemory pages */
+   unsigned long inmem_blocks; /* inmemory blocks */
struct extent_tree *extent_tree;/* cached extent_tree entry */
struct rw_semaphore dio_rwsem[2];/* avoid racing between dio and gc */
struct rw_semaphore i_mmap_sem;
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 46dfbca..813c110 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -210,6 +210,7 @@ void register_inmem_page(struct inode *inode, struct page 
*page)
list_add_tail(>inmem_ilist, >inode_list[ATOMIC_FILE]);
spin_unlock(>inode_lock[ATOMIC_FILE]);
inc_page_count(F2FS_I_SB(inode), F2FS_INMEM_PAGES);
+   fi->inmem_blocks++;
mutex_unlock(>inmem_lock);
  
  	trace_f2fs_register_inmem_page(page, INMEM);

@@ -221,6 +222,7 @@ static int __revoke_inmem_pages(struct inode *inode,
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
struct inmem_pages *cur, *tmp;
int err = 0;
+   struct f2fs_inode_info *fi = F2FS_I(inode);
  
  	list_for_each_entry_safe(cur, tmp, head, list) {

struct page *page = cur->page;
@@ -263,6 +265,7 @@ static int __revoke_inmem_pages(struct inode *inode,
list_del(>list);
kmem_cache_free(inmem_entry_slab, cur);
dec_page_count(F2FS_I_SB(inode), F2FS_INMEM_PAGES);
+   fi->inmem_blocks--;
}
return err;
  }
@@ -302,6 +305,10 @@ void drop_inmem_pages(struct inode *inode)
if (!list_empty(>inmem_ilist))
list_del_init(>inmem_ilist);
spin_unlock(>inode_lock[ATOMIC_FILE]);
+   if (fi->inmem_blocks) {
+   f2fs_bug_on(sbi, 1);
+   fi->inmem_blocks = 0;
+   }
mutex_unlock(>inmem_lock);
  
  	clear_inode_flag(inode, FI_ATOMIC_FILE);

@@ -326,6 +333,7 @@ void drop_inmem_page(struct inode *inode, struct page *page)
  
  	f2fs_bug_on(sbi, !cur || cur->page != page);

list_del(>list);
+   fi->inmem_blocks--;
mutex_unlock(>inmem_lock);
  
  	dec_page_count(sbi, F2FS_INMEM_PAGES);

@@ -410,11 +418,26 @@ int commit_inmem_pages(struct inode *inode)
  
  	INIT_LIST_HEAD(_list);

f2fs_balance_fs(sbi, true);
+   if (prefree_segments(sbi)
+   && has_not_enough_free_secs(sbi, 0,
+   fi->inmem_blocks / BLKS_PER_SEC(sbi))) {
+   struct cp_control cpc;
+
+   cpc.reason = __get_cp_reason(sbi);
+   err = write_checkpoint(sbi, );
+   if (err)
+   goto drop;
+   }
f2fs_lock_op(sbi);
  
  	set_inode_flag(inode, FI_ATOMIC_COMMIT);
  
  	mutex_lock(>inmem_lock);

+   if ((sbi->user_block_count - valid_user_blocks(sbi)) <

What does this mean? We already allocated blocks successfully?


+   fi->inmem_blocks) {
+   err = -ENOSPC;
+   goto drop;
+   }
err = __commit_inmem_pages(inode, _list);
if (err) {
int ret;
@@ -429,7 +452,7 @@ int commit_inmem_pages(struct inode *inode)
ret = __revoke_inmem_pages(inode, _list, false, true);
if (ret)
err = ret;
-
+drop:
/* drop all uncommitted pages */
__revoke_inmem_pages(inode, >inmem_pages, true, false);
}
@@ -437,6 +460,10 @@ int commit_inmem_pages(struct inode *inode)
if (!list_empty(>inmem_ilist))
list_del_init(>inmem_ilist);
spin_unlock(>inode_lock[ATOMIC_FILE]);
+   if (fi->inmem_blocks) {
+   f2fs_bug_on(sbi, 1);
+   fi->inmem_blocks = 0;
+   }

[PATCH v4 1/6] dt-bindings: pmbus: Add Maxim MAX31785 documentation

[Andrew Jeffery]

Signed-off-by: Andrew Jeffery 
---
 .../devicetree/bindings/hwmon/max31785.txt | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/max31785.txt

diff --git a/Documentation/devicetree/bindings/hwmon/max31785.txt 
b/Documentation/devicetree/bindings/hwmon/max31785.txt
new file mode 100644
index ..106e08c56aaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/max31785.txt
@@ -0,0 +1,22 @@
+Bindings for the Maxim MAX31785 Intelligent Fan Controller
+==
+
+Reference:
+
+https://datasheets.maximintegrated.com/en/ds/MAX31785.pdf
+
+The Maxim MAX31785 is a PMBus device providing closed-loop, multi-channel fan
+management with temperature and remote voltage sensing. Various fan control
+features are provided, including PWM frequency control, temperature hysteresis,
+dual tachometer measurements, and fan health monitoring.
+
+Required properties:
+- compatible : One of "maxim,max31785" or "maxim,max31785a"
+- reg: I2C address, one of 0x52, 0x53, 0x54, 0x55.
+
+Example:
+
+fans@52 {
+compatible = "maxim,max31785";
+reg = <0x52>;
+};
-- 
2.11.0

[PATCH v4 1/6] dt-bindings: pmbus: Add Maxim MAX31785 documentation

[Andrew Jeffery]

Signed-off-by: Andrew Jeffery 
---
 .../devicetree/bindings/hwmon/max31785.txt | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/max31785.txt

diff --git a/Documentation/devicetree/bindings/hwmon/max31785.txt 
b/Documentation/devicetree/bindings/hwmon/max31785.txt
new file mode 100644
index ..106e08c56aaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/max31785.txt
@@ -0,0 +1,22 @@
+Bindings for the Maxim MAX31785 Intelligent Fan Controller
+==
+
+Reference:
+
+https://datasheets.maximintegrated.com/en/ds/MAX31785.pdf
+
+The Maxim MAX31785 is a PMBus device providing closed-loop, multi-channel fan
+management with temperature and remote voltage sensing. Various fan control
+features are provided, including PWM frequency control, temperature hysteresis,
+dual tachometer measurements, and fan health monitoring.
+
+Required properties:
+- compatible : One of "maxim,max31785" or "maxim,max31785a"
+- reg: I2C address, one of 0x52, 0x53, 0x54, 0x55.
+
+Example:
+
+fans@52 {
+compatible = "maxim,max31785";
+reg = <0x52>;
+};
-- 
2.11.0

[PATCH v4 0/6] pmbus: Expand fan support and add MAX31785 driver

[Andrew Jeffery]

Hello,

This series introduces support for the MAX31785 intelligent fan controller, a
PMBus device providing closed-loop fan control among a number of other
features. Along the way the series adds support to control fans and create
virtual pages to the PMBus core, the latter to support some of the more
annoying design decisions found in the 'A' variant of the chip.

This is the fourth spin of the series, v3 can be found here[1].

I've been running aground with the described devicetree bindings in the
previous iterations, so in order to get *some* support upstream I've gutted the
documentation and removed the corresponding support from the driver. I'll save
posting that for a later date once Guenter and I have some input from Rob about
what direction to take with respect to describing PMBus devices.

As mentioned, adding full support for the features of the MAX31785 requires
modifications to the PMBus core, so I've split the addition of features into
separate patches, in the hope that some can be incrementally applied while we
iterate on the details of any suboptimal parts.

Please review!

Andrew

[1] https://lkml.org/lkml/2017/9/8/4

Andrew Jeffery (6):
  dt-bindings: pmbus: Add Maxim MAX31785 documentation
  pmbus: Add driver for Maxim MAX31785 Intelligent Fan Controller
  pmbus: core: Add fan control support
  pmbus: max31785: Add fan control
  pmbus: core: Add virtual page config bit
  pmbus: max31785: Add dual tachometer support

 .../devicetree/bindings/hwmon/max31785.txt |  22 ++
 Documentation/hwmon/max31785   |  57 
 drivers/hwmon/pmbus/Kconfig|  10 +
 drivers/hwmon/pmbus/Makefile   |   1 +
 drivers/hwmon/pmbus/max31785.c | 375 +
 drivers/hwmon/pmbus/pmbus.h|  31 ++
 drivers/hwmon/pmbus/pmbus_core.c   | 236 +++--
 7 files changed, 713 insertions(+), 19 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/hwmon/max31785.txt
 create mode 100644 Documentation/hwmon/max31785
 create mode 100644 drivers/hwmon/pmbus/max31785.c

-- 
2.11.0

[PATCH v4 0/6] pmbus: Expand fan support and add MAX31785 driver

[Andrew Jeffery]

Hello,

This series introduces support for the MAX31785 intelligent fan controller, a
PMBus device providing closed-loop fan control among a number of other
features. Along the way the series adds support to control fans and create
virtual pages to the PMBus core, the latter to support some of the more
annoying design decisions found in the 'A' variant of the chip.

This is the fourth spin of the series, v3 can be found here[1].

I've been running aground with the described devicetree bindings in the
previous iterations, so in order to get *some* support upstream I've gutted the
documentation and removed the corresponding support from the driver. I'll save
posting that for a later date once Guenter and I have some input from Rob about
what direction to take with respect to describing PMBus devices.

As mentioned, adding full support for the features of the MAX31785 requires
modifications to the PMBus core, so I've split the addition of features into
separate patches, in the hope that some can be incrementally applied while we
iterate on the details of any suboptimal parts.

Please review!

Andrew

[1] https://lkml.org/lkml/2017/9/8/4

Andrew Jeffery (6):
  dt-bindings: pmbus: Add Maxim MAX31785 documentation
  pmbus: Add driver for Maxim MAX31785 Intelligent Fan Controller
  pmbus: core: Add fan control support
  pmbus: max31785: Add fan control
  pmbus: core: Add virtual page config bit
  pmbus: max31785: Add dual tachometer support

 .../devicetree/bindings/hwmon/max31785.txt |  22 ++
 Documentation/hwmon/max31785   |  57 
 drivers/hwmon/pmbus/Kconfig|  10 +
 drivers/hwmon/pmbus/Makefile   |   1 +
 drivers/hwmon/pmbus/max31785.c | 375 +
 drivers/hwmon/pmbus/pmbus.h|  31 ++
 drivers/hwmon/pmbus/pmbus_core.c   | 236 +++--
 7 files changed, 713 insertions(+), 19 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/hwmon/max31785.txt
 create mode 100644 Documentation/hwmon/max31785
 create mode 100644 drivers/hwmon/pmbus/max31785.c

-- 
2.11.0

[git pull] drm fixes for v4.14-rc8

[Dave Airlie]

Hi Linus,

One nouveau regression fix,
Some amdgpu fixes for stable to fix hangs on some harvested Polaris GPUs
A set of KASAN and regression fixes for i915, their CI system seems to
be working pretty well now.

Dave.


The following changes since commit 0b07194bb55ed836c2cc7c22e866b87a14681984:

  Linux 4.14-rc7 (2017-10-29 13:58:38 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.14-rc8

for you to fetch changes up to 9cc06965fc8b7c5592b6a1355dff2623611bfeb3:

  Merge branch 'drm-fixes-4.14' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2017-11-02
14:40:12 +1000)


i915, amdgpu and nouveau fixes


Ben Skeggs (1):
  drm/nouveau/kms/nv50: use the correct state for base channel
notifier setup

Chris Wilson (3):
  drm/i915: Hold rcu_read_lock when iterating over the radixtree (objects)
  drm/i915: Hold rcu_read_lock when iterating over the radixtree (vma idr)
  drm/i915: Check incoming alignment for unfenced buffers (on i915gm)

Dave Airlie (3):
  Merge branch 'linux-4.14' of git://github.com/skeggsb/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2017-11-01' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge branch 'drm-fixes-4.14' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes

Jani Nikula (1):
  drm/i915/edp: read edp display control registers unconditionally

Leo Liu (2):
  drm/amdgpu: return -ENOENT from uvd 6.0 early init for harvesting
  drm/amdgpu: allow harvesting check for Polaris VCE

Maarten Lankhorst (1):
  drm/i915: Do not rely on wm preservation for ILK watermarks

Manasi Navare (1):
  drm/i915: Cancel the modeset retry work during modeset cleanup

 drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  |  4 +++
 drivers/gpu/drm/amd/amdgpu/vce_v3_0.c  | 12 +++
 drivers/gpu/drm/i915/i915_gem.c|  2 ++
 drivers/gpu/drm/i915/i915_gem_context.c|  2 ++
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  4 +++
 drivers/gpu/drm/i915/intel_display.c   | 19 ++-
 drivers/gpu/drm/i915/intel_dp.c| 13 ++--
 drivers/gpu/drm/i915/intel_drv.h   |  1 -
 drivers/gpu/drm/i915/intel_pm.c| 51 --
 drivers/gpu/drm/nouveau/nv50_display.c |  6 ++--
 10 files changed, 70 insertions(+), 44 deletions(-)

[git pull] drm fixes for v4.14-rc8

[Dave Airlie]

Hi Linus,

One nouveau regression fix,
Some amdgpu fixes for stable to fix hangs on some harvested Polaris GPUs
A set of KASAN and regression fixes for i915, their CI system seems to
be working pretty well now.

Dave.


The following changes since commit 0b07194bb55ed836c2cc7c22e866b87a14681984:

  Linux 4.14-rc7 (2017-10-29 13:58:38 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.14-rc8

for you to fetch changes up to 9cc06965fc8b7c5592b6a1355dff2623611bfeb3:

  Merge branch 'drm-fixes-4.14' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2017-11-02
14:40:12 +1000)


i915, amdgpu and nouveau fixes


Ben Skeggs (1):
  drm/nouveau/kms/nv50: use the correct state for base channel
notifier setup

Chris Wilson (3):
  drm/i915: Hold rcu_read_lock when iterating over the radixtree (objects)
  drm/i915: Hold rcu_read_lock when iterating over the radixtree (vma idr)
  drm/i915: Check incoming alignment for unfenced buffers (on i915gm)

Dave Airlie (3):
  Merge branch 'linux-4.14' of git://github.com/skeggsb/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2017-11-01' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge branch 'drm-fixes-4.14' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes

Jani Nikula (1):
  drm/i915/edp: read edp display control registers unconditionally

Leo Liu (2):
  drm/amdgpu: return -ENOENT from uvd 6.0 early init for harvesting
  drm/amdgpu: allow harvesting check for Polaris VCE

Maarten Lankhorst (1):
  drm/i915: Do not rely on wm preservation for ILK watermarks

Manasi Navare (1):
  drm/i915: Cancel the modeset retry work during modeset cleanup

 drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  |  4 +++
 drivers/gpu/drm/amd/amdgpu/vce_v3_0.c  | 12 +++
 drivers/gpu/drm/i915/i915_gem.c|  2 ++
 drivers/gpu/drm/i915/i915_gem_context.c|  2 ++
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  4 +++
 drivers/gpu/drm/i915/intel_display.c   | 19 ++-
 drivers/gpu/drm/i915/intel_dp.c| 13 ++--
 drivers/gpu/drm/i915/intel_drv.h   |  1 -
 drivers/gpu/drm/i915/intel_pm.c| 51 --
 drivers/gpu/drm/nouveau/nv50_display.c |  6 ++--
 10 files changed, 70 insertions(+), 44 deletions(-)

Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()

[陈华才]

Why this is still un-merged? Should I remove the cc-stable and resend this 
series?

Huacai
 
 
-- Original --
From:  "陈华才";
Date:  Thu, Oct 26, 2017 02:33 PM
To:  "Marek Szyprowski"; "Christoph 
Hellwig"; 
Cc:  "Robin Murphy"; "Andrew 
Morton"; "Fuxin Zhang"; 
"linux-kernel"; "Ralf 
Baechle"; "JamesHogan"; 
"linux-mips"; "James E . J 
.Bottomley"; "Martin K . 
Petersen"; 
"linux-scsi"; "stable"; 
"Michael S . Tsirkin"; "Pawel Osciak"; 
"Kyungmin Park"; "Michael 
Chan"; "Benjamin 
Herrenschmidt"; "Ivan Mikhaylov"; 
"Tariq Toukan"; "Andy Gross"; "Mark 
A . Greer"; "RobertBaldyga"; 
Subject:  Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()

 
Maybe my first version is suitable for stable.

Huacai
 
 
-- Original --
From:  "Marek Szyprowski";
Date:  Wed, Oct 25, 2017 03:21 PM
To:  "陈华才"; "Christoph Hellwig"; 
Cc:  "Robin Murphy"; "Andrew 
Morton"; "Fuxin Zhang"; 
"linux-kernel"; "Ralf 
Baechle"; "JamesHogan"; 
"linux-mips"; "James E . J 
.Bottomley"; "Martin K . 
Petersen"; 
"linux-scsi"; "stable"; 
"Michael S . Tsirkin"; "Pawel Osciak"; 
"Kyungmin Park"; "Michael 
Chan"; "Benjamin 
Herrenschmidt"; "Ivan Mikhaylov"; 
"Tariq Toukan"; "Andy Gross"; "Mark 
A . Greer"; "RobertBaldyga"; 
Subject:  Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()

 
Hi Huacai,

On 2017-10-25 03:22, 陈华才 wrote:
> Hi, Marek
>
> Patch3 is needed for stable, but Patch3 depend on Patch1 and Patch2.

Then patch #3 has to be reworked. First change scsi to align the block 
queue to dma_get_cache_alignment(). This will be safe in all cases and 
it will not hurt memory usage that much. Such version can be applied 
first and sent to stable without any dependencies. Please also describe 
deeply why such change is needed and what issues can be observed without 
it, on which systems.

Then as an optimization add support for per-device cache_alignment 
(patches #1 and #2). I'm still not convinced that it makes sense to 
align DMA structures to values less than L1 cache line size. It might 
hurt performance, because cache coherency has its cost and it is also 
relevant to multi-core/smp access to any objects that are in the same l1 
cache line. Memory savings that might be the results of such lower 
alignment are probably negligible.

>
> Huacai
>   
>   
> -- Original --
> From:  "Marek Szyprowski";
> Date:  Tue, Oct 24, 2017 09:30 PM
> To:  "Huacai Chen"; "Christoph Hellwig";
> Cc:  "Robin Murphy"; "Andrew 
> Morton"; "Fuxin Zhang"; 
> "linux-kernel"; "Ralf 
> Baechle"; "JamesHogan"; 
> "linux-mips"; "James E . J 
> .Bottomley"; "Martin K . 
> Petersen"; 
> "linux-scsi"; "stable"; 
> "Michael S . Tsirkin"; "Pawel Osciak"; 
> "Kyungmin Park"; "Michael 
> Chan"; "Benjamin 
> Herrenschmidt"; "Ivan Mikhaylov"; 
> "Tariq Toukan"; "Andy Gross"; 
> "Mark A . Greer"; "Robert 
> Baldyga";
> Subject:  Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()
>
>   
> Hi Huacai,
>
> On 2017-10-23 09:12, Huacai Chen wrote:
>> Make dma_get_cache_alignment() to accept a 'dev' argument. As a result,
>> it can return different alignments due to different devices' I/O cache
>> coherency.
>>
>> Currently, ARM/ARM64 and MIPS support coherent & noncoherent devices
>> co-exist. This may 

Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()

[陈华才]

Why this is still un-merged? Should I remove the cc-stable and resend this 
series?

Huacai
 
 
-- Original --
From:  "陈华才";
Date:  Thu, Oct 26, 2017 02:33 PM
To:  "Marek Szyprowski"; "Christoph 
Hellwig"; 
Cc:  "Robin Murphy"; "Andrew 
Morton"; "Fuxin Zhang"; 
"linux-kernel"; "Ralf 
Baechle"; "JamesHogan"; 
"linux-mips"; "James E . J 
.Bottomley"; "Martin K . 
Petersen"; 
"linux-scsi"; "stable"; 
"Michael S . Tsirkin"; "Pawel Osciak"; 
"Kyungmin Park"; "Michael 
Chan"; "Benjamin 
Herrenschmidt"; "Ivan Mikhaylov"; 
"Tariq Toukan"; "Andy Gross"; "Mark 
A . Greer"; "RobertBaldyga"; 
Subject:  Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()

 
Maybe my first version is suitable for stable.

Huacai
 
 
-- Original --
From:  "Marek Szyprowski";
Date:  Wed, Oct 25, 2017 03:21 PM
To:  "陈华才"; "Christoph Hellwig"; 
Cc:  "Robin Murphy"; "Andrew 
Morton"; "Fuxin Zhang"; 
"linux-kernel"; "Ralf 
Baechle"; "JamesHogan"; 
"linux-mips"; "James E . J 
.Bottomley"; "Martin K . 
Petersen"; 
"linux-scsi"; "stable"; 
"Michael S . Tsirkin"; "Pawel Osciak"; 
"Kyungmin Park"; "Michael 
Chan"; "Benjamin 
Herrenschmidt"; "Ivan Mikhaylov"; 
"Tariq Toukan"; "Andy Gross"; "Mark 
A . Greer"; "RobertBaldyga"; 
Subject:  Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()

 
Hi Huacai,

On 2017-10-25 03:22, 陈华才 wrote:
> Hi, Marek
>
> Patch3 is needed for stable, but Patch3 depend on Patch1 and Patch2.

Then patch #3 has to be reworked. First change scsi to align the block 
queue to dma_get_cache_alignment(). This will be safe in all cases and 
it will not hurt memory usage that much. Such version can be applied 
first and sent to stable without any dependencies. Please also describe 
deeply why such change is needed and what issues can be observed without 
it, on which systems.

Then as an optimization add support for per-device cache_alignment 
(patches #1 and #2). I'm still not convinced that it makes sense to 
align DMA structures to values less than L1 cache line size. It might 
hurt performance, because cache coherency has its cost and it is also 
relevant to multi-core/smp access to any objects that are in the same l1 
cache line. Memory savings that might be the results of such lower 
alignment are probably negligible.

>
> Huacai
>   
>   
> -- Original --
> From:  "Marek Szyprowski";
> Date:  Tue, Oct 24, 2017 09:30 PM
> To:  "Huacai Chen"; "Christoph Hellwig";
> Cc:  "Robin Murphy"; "Andrew 
> Morton"; "Fuxin Zhang"; 
> "linux-kernel"; "Ralf 
> Baechle"; "JamesHogan"; 
> "linux-mips"; "James E . J 
> .Bottomley"; "Martin K . 
> Petersen"; 
> "linux-scsi"; "stable"; 
> "Michael S . Tsirkin"; "Pawel Osciak"; 
> "Kyungmin Park"; "Michael 
> Chan"; "Benjamin 
> Herrenschmidt"; "Ivan Mikhaylov"; 
> "Tariq Toukan"; "Andy Gross"; 
> "Mark A . Greer"; "Robert 
> Baldyga";
> Subject:  Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()
>
>   
> Hi Huacai,
>
> On 2017-10-23 09:12, Huacai Chen wrote:
>> Make dma_get_cache_alignment() to accept a 'dev' argument. As a result,
>> it can return different alignments due to different devices' I/O cache
>> coherency.
>>
>> Currently, ARM/ARM64 and MIPS support coherent & noncoherent devices
>> co-exist. This may be extended in the future, so add a new function
>> pointer (i.e, get_cache_alignment) in 'struct dma_map_ops' as a generic
>> solution.
>>
>> Cc: sta...@vger.kernel.org
> I don't think this change should go to stable.
>
>> Cc: Michael S. Tsirkin 
>> Cc: Pawel Osciak 
>> Cc: Marek Szyprowski 
>> Cc: Kyungmin Park 
>> Cc: Michael Chan 
>> Cc: Benjamin Herrenschmidt 
>> Cc: Ivan Mikhaylov 
>> Cc: Tariq Toukan 
>> Cc: Andy Gross 
>> Cc: Mark A. Greer 
>> Cc: Robert Baldyga 
>> Cc: Marek Szyprowski 
>> Signed-off-by: Huacai Chen 
>> ---
>>drivers/infiniband/hw/mthca/mthca_main.c   |   2 +-
>>drivers/media/v4l2-core/videobuf2-dma-contig.c |   2 +-
>>drivers/net/ethernet/broadcom/b44.c|   8 +-
>>drivers/net/ethernet/ibm/emac/core.c   |  32 +++--
>>drivers/net/ethernet/ibm/emac/core.h   |  14 +-
>>drivers/net/ethernet/mellanox/mlx4/main.c  |   2 +-
>>drivers/spi/spi-qup.c  |   4 +-
>>drivers/tty/serial/mpsc.c  | 179 
>> +
>>drivers/tty/serial/samsung.c   |  14 +-
>>include/linux/dma-mapping.h|  17 ++-
> For videobuf2-dma-contig, serial/samsung and dma-mapping.h:
>
> Acked-by: Marek Szyprowski 
>
>
>>10 files changed, 150 insertions(+), 124 deletions(-)
>>
>> diff --git a/drivers/infiniband/hw/mthca/mthca_main.c 
>> b/drivers/infiniband/hw/mthca/mthca_main.c
>> index e36a9bc..078fe8d 100644
>> --- a/drivers/infiniband/hw/mthca/mthca_main.c
>> +++ b/drivers/infiniband/hw/mthca/mthca_main.c
>> @@ -416,7 +416,7 @@ static int mthca_init_icm(struct mthca_dev *mdev,
>>
>>  /* 

Re: [PATCHv5 1/1] [tools/selftests]: android/ion: userspace test utility for ion buffer sharing

[Pintu Kumar]

On Fri, Nov 3, 2017 at 6:02 AM, Shuah Khan  wrote:
> On 11/02/2017 05:54 PM, Laura Abbott wrote:
>> On 11/02/2017 10:53 AM, Shuah Khan wrote:
>>> On 11/02/2017 10:19 AM, Shuah Khan wrote:
 On 11/02/2017 10:15 AM, Pintu Kumar wrote:
> On Thu, Nov 2, 2017 at 8:37 PM, Shuah Khan  wrote:
>> Hi Pintu,
>>
>> On 11/01/2017 11:00 AM, Pintu Agarwal wrote:
>>> This is a test utility to verify ION buffer sharing in user space
>>> between 2 independent processes.
>>> It uses unix domain socket (with SCM_RIGHTS) as IPC to transfer an FD to
>>> another process to share the same buffer.
>>> This utility demonstrates how ION buffer sharing can be implemented 
>>> between
>>> two user space processes, using various heap types.
>>>
>>> This utility is made to be run as part of kselftest framework in kernel.
>>> The utility is verified on Ubuntu-32 bit system with Linux Kernel 4.14,
>>> using ION system heap.
>>>
>>> For more information about the utility please check the README file.
>>>
>>> Signed-off-by: Pintu Agarwal 
>>> ---
>>>  tools/testing/selftests/Makefile   |   3 +-
>>>  tools/testing/selftests/android/Makefile   |  46 
>>>  tools/testing/selftests/android/ion/.gitignore |   2 +
>>>  tools/testing/selftests/android/ion/Makefile   |  16 ++
>>>  tools/testing/selftests/android/ion/README | 101 
>>>  tools/testing/selftests/android/ion/config |   4 +
>>>  tools/testing/selftests/android/ion/ion.h  | 143 
>>>  tools/testing/selftests/android/ion/ion_test.sh|  55 +
>>>  .../testing/selftests/android/ion/ionapp_export.c  | 135 +++
>>>  .../testing/selftests/android/ion/ionapp_import.c  |  88 +++
>>>  tools/testing/selftests/android/ion/ionutils.c | 259 
>>> +
>>>  tools/testing/selftests/android/ion/ionutils.h |  55 +
>>>  tools/testing/selftests/android/ion/ipcsocket.c| 227 
>>> ++
>>>  tools/testing/selftests/android/ion/ipcsocket.h|  35 +++
>>>  tools/testing/selftests/android/run.sh |   3 +
>>>  15 files changed, 1171 insertions(+), 1 deletion(-)
>>>  create mode 100644 tools/testing/selftests/android/Makefile
>>>  create mode 100644 tools/testing/selftests/android/ion/.gitignore
>>>  create mode 100644 tools/testing/selftests/android/ion/Makefile
>>>  create mode 100644 tools/testing/selftests/android/ion/README
>>>  create mode 100644 tools/testing/selftests/android/ion/config
>>>  create mode 100644 tools/testing/selftests/android/ion/ion.h
>>>  create mode 100755 tools/testing/selftests/android/ion/ion_test.sh
>>>  create mode 100644 tools/testing/selftests/android/ion/ionapp_export.c
>>>  create mode 100644 tools/testing/selftests/android/ion/ionapp_import.c
>>>  create mode 100644 tools/testing/selftests/android/ion/ionutils.c
>>>  create mode 100644 tools/testing/selftests/android/ion/ionutils.h
>>>  create mode 100644 tools/testing/selftests/android/ion/ipcsocket.c
>>>  create mode 100644 tools/testing/selftests/android/ion/ipcsocket.h
>>>  create mode 100755 tools/testing/selftests/android/run.sh
>>>
>>> diff --git a/tools/testing/selftests/Makefile 
>>> b/tools/testing/selftests/Makefile
>>> index ff80564..61bc77b 100644
>>> --- a/tools/testing/selftests/Makefile
>>> +++ b/tools/testing/selftests/Makefile
>>> @@ -1,4 +1,5 @@
>>> -TARGETS =  bpf
>>> +TARGETS = android
>>
>> Based on our discussion on dependency on staging headers, let's not add
>> this test to kselftest run. Remove it from here and users can run it
>> as needed.
>>
>>> +TARGETS += bpf
>>>  TARGETS += breakpoints
>>>  TARGETS += capabilities
>>>  TARGETS += cpufreq
>>> diff --git a/tools/testing/selftests/android/Makefile 
>>> b/tools/testing/selftests/android/Makefil> new file mode 100644
>>> index 000..1a74922
>>> --- /dev/null
>>> +++ b/tools/testing/selftests/android/Makefile
>>> @@ -0,0 +1,46 @@
>>> +SUBDIRS := ion
>>> +
>>> +TEST_PROGS := run.sh
>>> +
>>> +.PHONY: all clean
>>> +
>>> +include ../lib.mk
>>> +
>>> +all:
>>> + @for DIR in $(SUBDIRS); do  \
>>> + BUILD_TARGET=$(OUTPUT)/$$DIR;   \
>>> + mkdir $$BUILD_TARGET  -p;   \
>>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@;\
>>> + #SUBDIR test prog name should be in the form: 
>>> SUBDIR_test.sh
>>> + TEST=$$DIR"_test.sh"; \
>>> + if [ -e $$DIR/$$TEST ]; then
>>> + rsync -a $$DIR/$$TEST $$BUILD_TARGET/;
>>> + fi
>>> + done
>>> +
>>> 

Re: [PATCHv5 1/1] [tools/selftests]: android/ion: userspace test utility for ion buffer sharing

[Pintu Kumar]

On Fri, Nov 3, 2017 at 6:02 AM, Shuah Khan  wrote:
> On 11/02/2017 05:54 PM, Laura Abbott wrote:
>> On 11/02/2017 10:53 AM, Shuah Khan wrote:
>>> On 11/02/2017 10:19 AM, Shuah Khan wrote:
 On 11/02/2017 10:15 AM, Pintu Kumar wrote:
> On Thu, Nov 2, 2017 at 8:37 PM, Shuah Khan  wrote:
>> Hi Pintu,
>>
>> On 11/01/2017 11:00 AM, Pintu Agarwal wrote:
>>> This is a test utility to verify ION buffer sharing in user space
>>> between 2 independent processes.
>>> It uses unix domain socket (with SCM_RIGHTS) as IPC to transfer an FD to
>>> another process to share the same buffer.
>>> This utility demonstrates how ION buffer sharing can be implemented 
>>> between
>>> two user space processes, using various heap types.
>>>
>>> This utility is made to be run as part of kselftest framework in kernel.
>>> The utility is verified on Ubuntu-32 bit system with Linux Kernel 4.14,
>>> using ION system heap.
>>>
>>> For more information about the utility please check the README file.
>>>
>>> Signed-off-by: Pintu Agarwal 
>>> ---
>>>  tools/testing/selftests/Makefile   |   3 +-
>>>  tools/testing/selftests/android/Makefile   |  46 
>>>  tools/testing/selftests/android/ion/.gitignore |   2 +
>>>  tools/testing/selftests/android/ion/Makefile   |  16 ++
>>>  tools/testing/selftests/android/ion/README | 101 
>>>  tools/testing/selftests/android/ion/config |   4 +
>>>  tools/testing/selftests/android/ion/ion.h  | 143 
>>>  tools/testing/selftests/android/ion/ion_test.sh|  55 +
>>>  .../testing/selftests/android/ion/ionapp_export.c  | 135 +++
>>>  .../testing/selftests/android/ion/ionapp_import.c  |  88 +++
>>>  tools/testing/selftests/android/ion/ionutils.c | 259 
>>> +
>>>  tools/testing/selftests/android/ion/ionutils.h |  55 +
>>>  tools/testing/selftests/android/ion/ipcsocket.c| 227 
>>> ++
>>>  tools/testing/selftests/android/ion/ipcsocket.h|  35 +++
>>>  tools/testing/selftests/android/run.sh |   3 +
>>>  15 files changed, 1171 insertions(+), 1 deletion(-)
>>>  create mode 100644 tools/testing/selftests/android/Makefile
>>>  create mode 100644 tools/testing/selftests/android/ion/.gitignore
>>>  create mode 100644 tools/testing/selftests/android/ion/Makefile
>>>  create mode 100644 tools/testing/selftests/android/ion/README
>>>  create mode 100644 tools/testing/selftests/android/ion/config
>>>  create mode 100644 tools/testing/selftests/android/ion/ion.h
>>>  create mode 100755 tools/testing/selftests/android/ion/ion_test.sh
>>>  create mode 100644 tools/testing/selftests/android/ion/ionapp_export.c
>>>  create mode 100644 tools/testing/selftests/android/ion/ionapp_import.c
>>>  create mode 100644 tools/testing/selftests/android/ion/ionutils.c
>>>  create mode 100644 tools/testing/selftests/android/ion/ionutils.h
>>>  create mode 100644 tools/testing/selftests/android/ion/ipcsocket.c
>>>  create mode 100644 tools/testing/selftests/android/ion/ipcsocket.h
>>>  create mode 100755 tools/testing/selftests/android/run.sh
>>>
>>> diff --git a/tools/testing/selftests/Makefile 
>>> b/tools/testing/selftests/Makefile
>>> index ff80564..61bc77b 100644
>>> --- a/tools/testing/selftests/Makefile
>>> +++ b/tools/testing/selftests/Makefile
>>> @@ -1,4 +1,5 @@
>>> -TARGETS =  bpf
>>> +TARGETS = android
>>
>> Based on our discussion on dependency on staging headers, let's not add
>> this test to kselftest run. Remove it from here and users can run it
>> as needed.
>>
>>> +TARGETS += bpf
>>>  TARGETS += breakpoints
>>>  TARGETS += capabilities
>>>  TARGETS += cpufreq
>>> diff --git a/tools/testing/selftests/android/Makefile 
>>> b/tools/testing/selftests/android/Makefil> new file mode 100644
>>> index 000..1a74922
>>> --- /dev/null
>>> +++ b/tools/testing/selftests/android/Makefile
>>> @@ -0,0 +1,46 @@
>>> +SUBDIRS := ion
>>> +
>>> +TEST_PROGS := run.sh
>>> +
>>> +.PHONY: all clean
>>> +
>>> +include ../lib.mk
>>> +
>>> +all:
>>> + @for DIR in $(SUBDIRS); do  \
>>> + BUILD_TARGET=$(OUTPUT)/$$DIR;   \
>>> + mkdir $$BUILD_TARGET  -p;   \
>>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@;\
>>> + #SUBDIR test prog name should be in the form: 
>>> SUBDIR_test.sh
>>> + TEST=$$DIR"_test.sh"; \
>>> + if [ -e $$DIR/$$TEST ]; then
>>> + rsync -a $$DIR/$$TEST $$BUILD_TARGET/;
>>> + fi
>>> + done
>>> +
>>> +override define RUN_TESTS
>>> + @cd $(OUTPUT); ./run.sh

RE: [PATCH v9 2/2] media:imx274 V4l2 driver for Sony imx274 CMOS sensor

[Vishal Sagar]

Hi Leon,

I understand this fixes correctly freeing the v4l control handlers in probe().

But if there is a scenario where the sensor is mounted on a removable daughter 
card,
shouldn't the probe fail if the daughter card is not connected? 
A sample read/write to an IMX274 register should be sufficient to confirm this 
in the probe() and fail.

Does it make sense to add this in the probe()?

Regards
Vishal Sagar 

> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Leon Luo
> Sent: Thursday, October 26, 2017 12:21 PM
> To: mche...@kernel.org; robh...@kernel.org; mark.rutl...@arm.com;
> hans.verk...@cisco.com; sakari.ai...@linux.intel.com
> Cc: linux-me...@vger.kernel.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; le...@leopardimaging.com; Soren Brinkmann
> 
> Subject: [PATCH v9 2/2] media:imx274 V4l2 driver for Sony imx274 CMOS sensor
> 
> The imx274 is a Sony CMOS image sensor that has 1/2.5 image size.
> It supports up to 3840x2160 (4K) 60fps, 1080p 120fps. The interface
> is 4-lane MIPI CSI-2 running at 1.44Gbps each.
> 
> This driver has been tested on Xilinx ZCU102 platform with a Leopard
> LI-IMX274MIPI-FMC camera board.
> 
> Support for the following features:
> -Resolutions: 3840x2160, 1920x1080, 1280x720
> -Frame rate: 3840x2160 : 5 – 60fps
> 1920x1080 : 5 – 120fps
> 1280x720 : 5 – 120fps
> -Exposure time: 16 – (frame interval) micro-seconds
> -Gain: 1x - 180x
> -VFLIP: enable/disabledrivers/media/i2c/imx274.c
> -Test pattern: 12 test patterns
> 
> Signed-off-by: Leon Luo 
> Tested-by: Sören Brinkmann 
> Acked-by: Sakari Ailus 
> Acked-by: Chris Kohn 
> ---
> v9:
>  - remove v4l2_async_unregister_subdev from probe error
> v8:
>  - check division by zero error
> v7:
>  - use __v4l2_ctrl_s_ctrl instead of v4l2_ctrl_s_ctrl to have
>clean mutex_lock/mutex_unlock in imx274_s_stream()
>  - define imx274_tp_regs[] as static, move the test pattern reg
>out of imx274_tp_regs[], and define it as a macro
>IMX274_TEST_PATTERN_REG
> v6:
>  - remove media/v4l2-image-sizes.h from include header
>  - make the header file alphabetical order
>  - remove fmt->pad check in imx274_get_fmt,
>the V4L2 subdev framework does it already
>  - change 'struct reg_8 *regs' to 'struct reg_8 regs[n]',
>where n is the exact numbers needed for this function
>  - move MODULE_DEVICE_TABLE(of, imx274_of_id_table); closer
>to imx274_of_id_table definition
>  - remove return check of imx274_write_table in imx274_remove,
>because it should remove all resources even i2c fails here
>  - move imx274_load_default before v4l2_async_register_subdev
> v5:
>  - no changes
> v4:
>  - use 32-bit data type to avoid __divdi3 compile error for i386
>  - clean up OR together error codesdrivers/media/i2c/imx274.c
> v3:
>  - clean up header files
>  - use struct directly instead of alias #define
>  - use v4l2_ctrl_s_ctrl instead of v4l2_s_ctrl
>  - revise debug output
>  - move static helpers closer to their call site
>  - don't OR toegether error codes
>  - use closest valid gain value instead of erroring out
>  - assigne lock to the control handler and omit explicit locking
>  - acquire mutex lock for imx274_get_fmt
>  - remove format->pad check in imx274_set_fmt since the pad is always 0
>  - pass struct v4l2_ctrl pointer in gain/exposure/vlip/test pattern controls
>  - remove priv->ctrls.vflip->val = val in imx274_set_vflip()
>  - remove priv->ctrls.test_pattern->val = val in imx274_set_test_pattern()
>  - remove empty open/close callbacks
>  - remove empty core ops
>  - add more error labels in probe
>  - use v4l2_async_unregister_subdev instead of v4l2_device_unregister_subdev
>  - use dynamic debug
>  - split start_stream to two steps: imx274_mode_regs() and
> imx274_start_stream()
>frame rate & exposure can be updated
>between imx274_mode_regs() & imx274_start_stream()
> 
> v2:
>  - Fix Kconfig to not remove existing options
> ---
>  drivers/media/i2c/Kconfig  |7 +
>  drivers/media/i2c/Makefile |1 +
>  drivers/media/i2c/imx274.c | 1810
> 
>  3 files changed, 1818 insertions(+)
>  create mode 100644 drivers/media/i2c/imx274.c
> 
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 47113774a297..9659849e33a0 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -555,6 +555,13 @@ config VIDEO_APTINA_PLL
>  config VIDEO_SMIAPP_PLL
>   tristate
> 
> +config VIDEO_IMX274
> + tristate "Sony IMX274 sensor support"
> + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> + ---help---
> +   This is a V4L2 sensor-level driver for the Sony IMX274
> +   CMOS image sensor.
> +
>  config VIDEO_OV2640
>   tristate "OmniVision OV2640 sensor support"
>   

RE: [PATCH v9 2/2] media:imx274 V4l2 driver for Sony imx274 CMOS sensor

[Vishal Sagar]

Hi Leon,

I understand this fixes correctly freeing the v4l control handlers in probe().

But if there is a scenario where the sensor is mounted on a removable daughter 
card,
shouldn't the probe fail if the daughter card is not connected? 
A sample read/write to an IMX274 register should be sufficient to confirm this 
in the probe() and fail.

Does it make sense to add this in the probe()?

Regards
Vishal Sagar 

> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Leon Luo
> Sent: Thursday, October 26, 2017 12:21 PM
> To: mche...@kernel.org; robh...@kernel.org; mark.rutl...@arm.com;
> hans.verk...@cisco.com; sakari.ai...@linux.intel.com
> Cc: linux-me...@vger.kernel.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; le...@leopardimaging.com; Soren Brinkmann
> 
> Subject: [PATCH v9 2/2] media:imx274 V4l2 driver for Sony imx274 CMOS sensor
> 
> The imx274 is a Sony CMOS image sensor that has 1/2.5 image size.
> It supports up to 3840x2160 (4K) 60fps, 1080p 120fps. The interface
> is 4-lane MIPI CSI-2 running at 1.44Gbps each.
> 
> This driver has been tested on Xilinx ZCU102 platform with a Leopard
> LI-IMX274MIPI-FMC camera board.
> 
> Support for the following features:
> -Resolutions: 3840x2160, 1920x1080, 1280x720
> -Frame rate: 3840x2160 : 5 – 60fps
> 1920x1080 : 5 – 120fps
> 1280x720 : 5 – 120fps
> -Exposure time: 16 – (frame interval) micro-seconds
> -Gain: 1x - 180x
> -VFLIP: enable/disabledrivers/media/i2c/imx274.c
> -Test pattern: 12 test patterns
> 
> Signed-off-by: Leon Luo 
> Tested-by: Sören Brinkmann 
> Acked-by: Sakari Ailus 
> Acked-by: Chris Kohn 
> ---
> v9:
>  - remove v4l2_async_unregister_subdev from probe error
> v8:
>  - check division by zero error
> v7:
>  - use __v4l2_ctrl_s_ctrl instead of v4l2_ctrl_s_ctrl to have
>clean mutex_lock/mutex_unlock in imx274_s_stream()
>  - define imx274_tp_regs[] as static, move the test pattern reg
>out of imx274_tp_regs[], and define it as a macro
>IMX274_TEST_PATTERN_REG
> v6:
>  - remove media/v4l2-image-sizes.h from include header
>  - make the header file alphabetical order
>  - remove fmt->pad check in imx274_get_fmt,
>the V4L2 subdev framework does it already
>  - change 'struct reg_8 *regs' to 'struct reg_8 regs[n]',
>where n is the exact numbers needed for this function
>  - move MODULE_DEVICE_TABLE(of, imx274_of_id_table); closer
>to imx274_of_id_table definition
>  - remove return check of imx274_write_table in imx274_remove,
>because it should remove all resources even i2c fails here
>  - move imx274_load_default before v4l2_async_register_subdev
> v5:
>  - no changes
> v4:
>  - use 32-bit data type to avoid __divdi3 compile error for i386
>  - clean up OR together error codesdrivers/media/i2c/imx274.c
> v3:
>  - clean up header files
>  - use struct directly instead of alias #define
>  - use v4l2_ctrl_s_ctrl instead of v4l2_s_ctrl
>  - revise debug output
>  - move static helpers closer to their call site
>  - don't OR toegether error codes
>  - use closest valid gain value instead of erroring out
>  - assigne lock to the control handler and omit explicit locking
>  - acquire mutex lock for imx274_get_fmt
>  - remove format->pad check in imx274_set_fmt since the pad is always 0
>  - pass struct v4l2_ctrl pointer in gain/exposure/vlip/test pattern controls
>  - remove priv->ctrls.vflip->val = val in imx274_set_vflip()
>  - remove priv->ctrls.test_pattern->val = val in imx274_set_test_pattern()
>  - remove empty open/close callbacks
>  - remove empty core ops
>  - add more error labels in probe
>  - use v4l2_async_unregister_subdev instead of v4l2_device_unregister_subdev
>  - use dynamic debug
>  - split start_stream to two steps: imx274_mode_regs() and
> imx274_start_stream()
>frame rate & exposure can be updated
>between imx274_mode_regs() & imx274_start_stream()
> 
> v2:
>  - Fix Kconfig to not remove existing options
> ---
>  drivers/media/i2c/Kconfig  |7 +
>  drivers/media/i2c/Makefile |1 +
>  drivers/media/i2c/imx274.c | 1810
> 
>  3 files changed, 1818 insertions(+)
>  create mode 100644 drivers/media/i2c/imx274.c
> 
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 47113774a297..9659849e33a0 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -555,6 +555,13 @@ config VIDEO_APTINA_PLL
>  config VIDEO_SMIAPP_PLL
>   tristate
> 
> +config VIDEO_IMX274
> + tristate "Sony IMX274 sensor support"
> + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> + ---help---
> +   This is a V4L2 sensor-level driver for the Sony IMX274
> +   CMOS image sensor.
> +
>  config VIDEO_OV2640
>   tristate "OmniVision OV2640 sensor support"
>   depends on VIDEO_V4L2 && I2C
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index 

[PATCH for-next] openrisc: fix possible deadlock scenario during timer sync

[Stafford Horne]

OpenRISC borrows its timer sync logic from MIPS, Matt helped to review
the OpenRISC implementation and noted that we may suffer the same
deadlock case that MIPS has faced. The case being:

  "the MIPS timer synchronization code contained the possibility of
  deadlock. If you mark a CPU online before it goes into the synchronize
  loop, then the boot CPU can schedule a different thread and send IPIs to
  all "online" CPUs. It gets stuck waiting for the secondary to ack it's
  IPI, since this secondary CPU has not enabled IRQs yet, and is stuck
  waiting for the master to synchronise with it.  The system then
  deadlocks."

Fix this by moving set_cpu_online() to after timer sync.

Reported-by: Matt Redfearn 
Signed-off-by: Stafford Horne 
---
 arch/openrisc/kernel/smp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/openrisc/kernel/smp.c b/arch/openrisc/kernel/smp.c
index 4d80ce6fa045..7d518ee8bddc 100644
--- a/arch/openrisc/kernel/smp.c
+++ b/arch/openrisc/kernel/smp.c
@@ -127,10 +127,10 @@ asmlinkage __init void secondary_start_kernel(void)
/*
 * OK, now it's safe to let the boot CPU continue
 */
-   set_cpu_online(cpu, true);
complete(_running);
 
synchronise_count_slave(cpu);
+   set_cpu_online(cpu, true);
 
local_irq_enable();
 
-- 
2.13.6

[PATCH for-next] openrisc: fix possible deadlock scenario during timer sync

[Stafford Horne]

OpenRISC borrows its timer sync logic from MIPS, Matt helped to review
the OpenRISC implementation and noted that we may suffer the same
deadlock case that MIPS has faced. The case being:

  "the MIPS timer synchronization code contained the possibility of
  deadlock. If you mark a CPU online before it goes into the synchronize
  loop, then the boot CPU can schedule a different thread and send IPIs to
  all "online" CPUs. It gets stuck waiting for the secondary to ack it's
  IPI, since this secondary CPU has not enabled IRQs yet, and is stuck
  waiting for the master to synchronise with it.  The system then
  deadlocks."

Fix this by moving set_cpu_online() to after timer sync.

Reported-by: Matt Redfearn 
Signed-off-by: Stafford Horne 
---
 arch/openrisc/kernel/smp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/openrisc/kernel/smp.c b/arch/openrisc/kernel/smp.c
index 4d80ce6fa045..7d518ee8bddc 100644
--- a/arch/openrisc/kernel/smp.c
+++ b/arch/openrisc/kernel/smp.c
@@ -127,10 +127,10 @@ asmlinkage __init void secondary_start_kernel(void)
/*
 * OK, now it's safe to let the boot CPU continue
 */
-   set_cpu_online(cpu, true);
complete(_running);
 
synchronise_count_slave(cpu);
+   set_cpu_online(cpu, true);
 
local_irq_enable();
 
-- 
2.13.6

next-20171102: ARM64 dies on boot

[Yury Norov]

Hi all,

I reproduce it with qemu. The exact reason of panic is the NULL-dereference
in memory_present:
(gdb) bt
#0  0x08dd8c6c in sparse_index_init (nid=, 
section_nr=)
at mm/sparse.c:80
#1  memory_present (nid=0, start=18446462598881083392, end=0) at mm/sparse.c:215
#2  0x08dc518c in arm64_memory_present () at arch/arm64/mm/init.c:307
#3  bootmem_init () at arch/arm64/mm/init.c:500
#4  0x08dc28fc in setup_arch (cmdline_p=) at 
arch/arm64/kernel/setup.c:287
#5  0x08dc083c in start_kernel () at init/main.c:530
#6  0x in ?? ()

B+ │0x08dd8c10  stpx29, x30, [sp, #-80]!
  │
   │0x08dd8c14    andx1, x1, #0xfffc  
  │
   │0x08dd8c18    movx29, sp  
  │
   │0x08dd8c1c   stpx23, x24, [sp, #48]  
  │
   │0x08dd8c20   movw23, w0  
  │
   │0x08dd8c24   stpx19, x20, [sp, #16]  
  │
   │0x08dd8c28   lslw20, w23, #3 
  │
   │0x08dd8c2c   stpx21, x22, [sp, #32]  
  │
   │0x08dd8c30   addx0, x29, #0x48   
  │
   │0x08dd8c34   stpx2, x1, [x29, #64]   
  │
   │0x08dd8c38   orrw20, w20, #0x4   
  │
   │0x08dd8c3c   addx1, x29, #0x40   
  │
   │0x08dd8c40   bl 0x08e16a1c 
  ldrx21, [x29, #72]  
  │
   │0x08dd8c48   adrp   x22, 0x09023000 
  │
   │0x08dd8c4c   sxtw   x20, w20 
  │
   │0x08dd8c50   movx24, x22 
  │
   │0x08dd8c54   ldrx0, [x29, #64]   
  │
   │0x08dd8c58   cmpx0, x21  
  │
   │0x08dd8c5c   b.ls   0x08dd8ce4 
  // b.plast│
   │0x08dd8c60   lsrx19, x21, #26
  │
   │0x08dd8c64   ldrx0, [x22, #96]   
  │
   │0x08dd8c68   lslx19, x19, #3 
  │
  >│0x08dd8c6c   ldrx0, [x0, x19]
  | << HERE
   │0x08dd8c70   cbnz   x0, 0x08dd8c88 
│
   │0x08dd8c74  movw0, w23  
  │
   │0x08dd8c78  bl 0x089824e4 
│
   │0x08dd8c7c  cbzx0, 0x08dd8c88 
│
   │0x08dd8c80  ldrx1, [x22, #96]   
  │
   │0x08dd8c84  strx0, [x1, x19]
  │
   │0x08dd8c88  ldrx0, [x24, #96]   
  │
   │0x08dd8c8c  cbzx0, 0x08dd8ca4 
│
   │0x08dd8c90  ldrx5, [x0, x19]
  │
   │0x08dd8c94  cbzx5, 0x08dd8ca8 
│
   │0x08dd8c98  ubfx   x0, x21, #18, #8 
  │
   │0x08dd8c9c  addx5, x5, x0, lsl #4   
  │
   │0x08dd8ca0  b  0x08dd8ca8 
│
   │0x08dd8ca4  movx5, #0x0 
   // #0  │
   │0x08dd8ca8  ldrx0, [x5] 
  │
   │0x08dd8cac  cbnz   x0, 0x08dd8cdc 
│
   │0x08dd8cb0  strx20, [x5]
  │
   │0x08dd8cb4  movx0, x5   
  │
   │0x08dd8cb8 

next-20171102: ARM64 dies on boot

[Yury Norov]

Hi all,

I reproduce it with qemu. The exact reason of panic is the NULL-dereference
in memory_present:
(gdb) bt
#0  0x08dd8c6c in sparse_index_init (nid=, 
section_nr=)
at mm/sparse.c:80
#1  memory_present (nid=0, start=18446462598881083392, end=0) at mm/sparse.c:215
#2  0x08dc518c in arm64_memory_present () at arch/arm64/mm/init.c:307
#3  bootmem_init () at arch/arm64/mm/init.c:500
#4  0x08dc28fc in setup_arch (cmdline_p=) at 
arch/arm64/kernel/setup.c:287
#5  0x08dc083c in start_kernel () at init/main.c:530
#6  0x in ?? ()

B+ │0x08dd8c10  stpx29, x30, [sp, #-80]!
  │
   │0x08dd8c14andx1, x1, #0xfffc  
  │
   │0x08dd8c18movx29, sp  
  │
   │0x08dd8c1c   stpx23, x24, [sp, #48]  
  │
   │0x08dd8c20   movw23, w0  
  │
   │0x08dd8c24   stpx19, x20, [sp, #16]  
  │
   │0x08dd8c28   lslw20, w23, #3 
  │
   │0x08dd8c2c   stpx21, x22, [sp, #32]  
  │
   │0x08dd8c30   addx0, x29, #0x48   
  │
   │0x08dd8c34   stpx2, x1, [x29, #64]   
  │
   │0x08dd8c38   orrw20, w20, #0x4   
  │
   │0x08dd8c3c   addx1, x29, #0x40   
  │
   │0x08dd8c40   bl 0x08e16a1c 
  ldrx21, [x29, #72]  
  │
   │0x08dd8c48   adrp   x22, 0x09023000 
  │
   │0x08dd8c4c   sxtw   x20, w20 
  │
   │0x08dd8c50   movx24, x22 
  │
   │0x08dd8c54   ldrx0, [x29, #64]   
  │
   │0x08dd8c58   cmpx0, x21  
  │
   │0x08dd8c5c   b.ls   0x08dd8ce4 
  // b.plast│
   │0x08dd8c60   lsrx19, x21, #26
  │
   │0x08dd8c64   ldrx0, [x22, #96]   
  │
   │0x08dd8c68   lslx19, x19, #3 
  │
  >│0x08dd8c6c   ldrx0, [x0, x19]
  | << HERE
   │0x08dd8c70   cbnz   x0, 0x08dd8c88 
│
   │0x08dd8c74  movw0, w23  
  │
   │0x08dd8c78  bl 0x089824e4 
│
   │0x08dd8c7c  cbzx0, 0x08dd8c88 
│
   │0x08dd8c80  ldrx1, [x22, #96]   
  │
   │0x08dd8c84  strx0, [x1, x19]
  │
   │0x08dd8c88  ldrx0, [x24, #96]   
  │
   │0x08dd8c8c  cbzx0, 0x08dd8ca4 
│
   │0x08dd8c90  ldrx5, [x0, x19]
  │
   │0x08dd8c94  cbzx5, 0x08dd8ca8 
│
   │0x08dd8c98  ubfx   x0, x21, #18, #8 
  │
   │0x08dd8c9c  addx5, x5, x0, lsl #4   
  │
   │0x08dd8ca0  b  0x08dd8ca8 
│
   │0x08dd8ca4  movx5, #0x0 
   // #0  │
   │0x08dd8ca8  ldrx0, [x5] 
  │
   │0x08dd8cac  cbnz   x0, 0x08dd8cdc 
│
   │0x08dd8cb0  strx20, [x5]
  │
   │0x08dd8cb4  movx0, x5   
  │
   │0x08dd8cb8  bl 0x081e4670 
<__section_nr>  │
   │0x08dd8cbc  addx1, x24, #0x60   
  │
   │0x08dd8cc0  ldrw2, [x1, #8] 
  │
   │0x08dd8cc4  cmpw0, w2   
  │
   │0x08dd8cc8  b.le   0x08dd8cd0 
│
   │0x08dd8ccc  strw0, [x1, #8] 
  │
   │0x08dd8cd0  ldrx0, [x5] 
  │
   │0x08dd8cd4  orrx0, x0, #0x1 
  │
   │0x08dd8cd8  strx0, [x5] 
  │
   │0x08dd8cdc  addx21, x21, #0x40, lsl #12 
  │
   │0x08dd8ce0  b  0x08dd8c54 
 │
   │0x08dd8ce4  ldpx19, x20, [sp, #16]  
  │
   │0x08dd8ce8  ldpx21, x22, [sp, #32]  
  

Re: [PATCH v2] f2fs: fix out-of-free problem caused by atomic write

[Yunlong Song]

ping...

On 2017/10/30 21:04, Yunlong Song wrote:

f2fs_balance_fs only actives once in the commit_inmem_pages, but there
are more than one page to commit, so all the other pages will miss the
check. This will lead to out-of-free problem when commit a very large
file. However, we cannot do f2fs_balance_fs for each inmem page, since
this will break atomicity. As a result, we should collect prefree
segments if needed and stop atomic commit when there are not enough
available blocks to write atomic pages.

Signed-off-by: Yunlong Song 
---
  fs/f2fs/f2fs.h|  1 +
  fs/f2fs/segment.c | 29 -
  2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 13a96b8..04ce48f 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -610,6 +610,7 @@ struct f2fs_inode_info {
struct list_head inmem_pages;   /* inmemory pages managed by f2fs */
struct task_struct *inmem_task; /* store inmemory task */
struct mutex inmem_lock;/* lock for inmemory pages */
+   unsigned long inmem_blocks; /* inmemory blocks */
struct extent_tree *extent_tree;/* cached extent_tree entry */
struct rw_semaphore dio_rwsem[2];/* avoid racing between dio and gc */
struct rw_semaphore i_mmap_sem;
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 46dfbca..813c110 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -210,6 +210,7 @@ void register_inmem_page(struct inode *inode, struct page 
*page)
list_add_tail(>inmem_ilist, >inode_list[ATOMIC_FILE]);
spin_unlock(>inode_lock[ATOMIC_FILE]);
inc_page_count(F2FS_I_SB(inode), F2FS_INMEM_PAGES);
+   fi->inmem_blocks++;
mutex_unlock(>inmem_lock);
  
  	trace_f2fs_register_inmem_page(page, INMEM);

@@ -221,6 +222,7 @@ static int __revoke_inmem_pages(struct inode *inode,
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
struct inmem_pages *cur, *tmp;
int err = 0;
+   struct f2fs_inode_info *fi = F2FS_I(inode);
  
  	list_for_each_entry_safe(cur, tmp, head, list) {

struct page *page = cur->page;
@@ -263,6 +265,7 @@ static int __revoke_inmem_pages(struct inode *inode,
list_del(>list);
kmem_cache_free(inmem_entry_slab, cur);
dec_page_count(F2FS_I_SB(inode), F2FS_INMEM_PAGES);
+   fi->inmem_blocks--;
}
return err;
  }
@@ -302,6 +305,10 @@ void drop_inmem_pages(struct inode *inode)
if (!list_empty(>inmem_ilist))
list_del_init(>inmem_ilist);
spin_unlock(>inode_lock[ATOMIC_FILE]);
+   if (fi->inmem_blocks) {
+   f2fs_bug_on(sbi, 1);
+   fi->inmem_blocks = 0;
+   }
mutex_unlock(>inmem_lock);
  
  	clear_inode_flag(inode, FI_ATOMIC_FILE);

@@ -326,6 +333,7 @@ void drop_inmem_page(struct inode *inode, struct page *page)
  
  	f2fs_bug_on(sbi, !cur || cur->page != page);

list_del(>list);
+   fi->inmem_blocks--;
mutex_unlock(>inmem_lock);
  
  	dec_page_count(sbi, F2FS_INMEM_PAGES);

@@ -410,11 +418,26 @@ int commit_inmem_pages(struct inode *inode)
  
  	INIT_LIST_HEAD(_list);

f2fs_balance_fs(sbi, true);
+   if (prefree_segments(sbi)
+   && has_not_enough_free_secs(sbi, 0,
+   fi->inmem_blocks / BLKS_PER_SEC(sbi))) {
+   struct cp_control cpc;
+
+   cpc.reason = __get_cp_reason(sbi);
+   err = write_checkpoint(sbi, );
+   if (err)
+   goto drop;
+   }
f2fs_lock_op(sbi);
  
  	set_inode_flag(inode, FI_ATOMIC_COMMIT);
  
  	mutex_lock(>inmem_lock);

+   if ((sbi->user_block_count - valid_user_blocks(sbi)) <
+   fi->inmem_blocks) {
+   err = -ENOSPC;
+   goto drop;
+   }
err = __commit_inmem_pages(inode, _list);
if (err) {
int ret;
@@ -429,7 +452,7 @@ int commit_inmem_pages(struct inode *inode)
ret = __revoke_inmem_pages(inode, _list, false, true);
if (ret)
err = ret;
-
+drop:
/* drop all uncommitted pages */
__revoke_inmem_pages(inode, >inmem_pages, true, false);
}
@@ -437,6 +460,10 @@ int commit_inmem_pages(struct inode *inode)
if (!list_empty(>inmem_ilist))
list_del_init(>inmem_ilist);
spin_unlock(>inode_lock[ATOMIC_FILE]);
+   if (fi->inmem_blocks) {
+   f2fs_bug_on(sbi, 1);
+   fi->inmem_blocks = 0;
+   }
mutex_unlock(>inmem_lock);
  
  	clear_inode_flag(inode, FI_ATOMIC_COMMIT);


--
Thanks,
Yunlong Song

Re: [PATCH v2] f2fs: fix out-of-free problem caused by atomic write

[Yunlong Song]

ping...

On 2017/10/30 21:04, Yunlong Song wrote:

f2fs_balance_fs only actives once in the commit_inmem_pages, but there
are more than one page to commit, so all the other pages will miss the
check. This will lead to out-of-free problem when commit a very large
file. However, we cannot do f2fs_balance_fs for each inmem page, since
this will break atomicity. As a result, we should collect prefree
segments if needed and stop atomic commit when there are not enough
available blocks to write atomic pages.

Signed-off-by: Yunlong Song 
---
  fs/f2fs/f2fs.h|  1 +
  fs/f2fs/segment.c | 29 -
  2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 13a96b8..04ce48f 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -610,6 +610,7 @@ struct f2fs_inode_info {
struct list_head inmem_pages;   /* inmemory pages managed by f2fs */
struct task_struct *inmem_task; /* store inmemory task */
struct mutex inmem_lock;/* lock for inmemory pages */
+   unsigned long inmem_blocks; /* inmemory blocks */
struct extent_tree *extent_tree;/* cached extent_tree entry */
struct rw_semaphore dio_rwsem[2];/* avoid racing between dio and gc */
struct rw_semaphore i_mmap_sem;
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 46dfbca..813c110 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -210,6 +210,7 @@ void register_inmem_page(struct inode *inode, struct page 
*page)
list_add_tail(>inmem_ilist, >inode_list[ATOMIC_FILE]);
spin_unlock(>inode_lock[ATOMIC_FILE]);
inc_page_count(F2FS_I_SB(inode), F2FS_INMEM_PAGES);
+   fi->inmem_blocks++;
mutex_unlock(>inmem_lock);
  
  	trace_f2fs_register_inmem_page(page, INMEM);

@@ -221,6 +222,7 @@ static int __revoke_inmem_pages(struct inode *inode,
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
struct inmem_pages *cur, *tmp;
int err = 0;
+   struct f2fs_inode_info *fi = F2FS_I(inode);
  
  	list_for_each_entry_safe(cur, tmp, head, list) {

struct page *page = cur->page;
@@ -263,6 +265,7 @@ static int __revoke_inmem_pages(struct inode *inode,
list_del(>list);
kmem_cache_free(inmem_entry_slab, cur);
dec_page_count(F2FS_I_SB(inode), F2FS_INMEM_PAGES);
+   fi->inmem_blocks--;
}
return err;
  }
@@ -302,6 +305,10 @@ void drop_inmem_pages(struct inode *inode)
if (!list_empty(>inmem_ilist))
list_del_init(>inmem_ilist);
spin_unlock(>inode_lock[ATOMIC_FILE]);
+   if (fi->inmem_blocks) {
+   f2fs_bug_on(sbi, 1);
+   fi->inmem_blocks = 0;
+   }
mutex_unlock(>inmem_lock);
  
  	clear_inode_flag(inode, FI_ATOMIC_FILE);

@@ -326,6 +333,7 @@ void drop_inmem_page(struct inode *inode, struct page *page)
  
  	f2fs_bug_on(sbi, !cur || cur->page != page);

list_del(>list);
+   fi->inmem_blocks--;
mutex_unlock(>inmem_lock);
  
  	dec_page_count(sbi, F2FS_INMEM_PAGES);

@@ -410,11 +418,26 @@ int commit_inmem_pages(struct inode *inode)
  
  	INIT_LIST_HEAD(_list);

f2fs_balance_fs(sbi, true);
+   if (prefree_segments(sbi)
+   && has_not_enough_free_secs(sbi, 0,
+   fi->inmem_blocks / BLKS_PER_SEC(sbi))) {
+   struct cp_control cpc;
+
+   cpc.reason = __get_cp_reason(sbi);
+   err = write_checkpoint(sbi, );
+   if (err)
+   goto drop;
+   }
f2fs_lock_op(sbi);
  
  	set_inode_flag(inode, FI_ATOMIC_COMMIT);
  
  	mutex_lock(>inmem_lock);

+   if ((sbi->user_block_count - valid_user_blocks(sbi)) <
+   fi->inmem_blocks) {
+   err = -ENOSPC;
+   goto drop;
+   }
err = __commit_inmem_pages(inode, _list);
if (err) {
int ret;
@@ -429,7 +452,7 @@ int commit_inmem_pages(struct inode *inode)
ret = __revoke_inmem_pages(inode, _list, false, true);
if (ret)
err = ret;
-
+drop:
/* drop all uncommitted pages */
__revoke_inmem_pages(inode, >inmem_pages, true, false);
}
@@ -437,6 +460,10 @@ int commit_inmem_pages(struct inode *inode)
if (!list_empty(>inmem_ilist))
list_del_init(>inmem_ilist);
spin_unlock(>inode_lock[ATOMIC_FILE]);
+   if (fi->inmem_blocks) {
+   f2fs_bug_on(sbi, 1);
+   fi->inmem_blocks = 0;
+   }
mutex_unlock(>inmem_lock);
  
  	clear_inode_flag(inode, FI_ATOMIC_COMMIT);


--
Thanks,
Yunlong Song

[PATCH 1/3] arm64: Define cputype macros for Falkor CPU

[Shanker Donthineni]

Add cputype definition macros for Qualcomm Datacenter Technologies
Falkor CPU in cputype.h. It's unfortunate that the first revision
of the Falkor CPU used the wrong part number 0x800, got fixed in v2
chip with part number 0xC00, and would be used the same value for
future revisions.

Signed-off-by: Shanker Donthineni 
Signed-off-by: Neil Leeder 
---
 arch/arm64/include/asm/cputype.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 235e77d..cbf08d7 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -91,6 +91,7 @@
 #define BRCM_CPU_PART_VULCAN   0x516
 
 #define QCOM_CPU_PART_FALKOR_V10x800
+#define QCOM_CPU_PART_FALKOR   0xC00
 
 #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A53)
 #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A57)
@@ -99,6 +100,7 @@
 #define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
CAVIUM_CPU_PART_THUNDERX_81XX)
 #define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
CAVIUM_CPU_PART_THUNDERX_83XX)
 #define MIDR_QCOM_FALKOR_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, 
QCOM_CPU_PART_FALKOR_V1)
+#define MIDR_QCOM_FALKOR MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR)
 
 #ifndef __ASSEMBLY__
 
-- 
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, 
Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [PATCH v2] f2fs: add bug_on when f2fs_gc even fails to get one victim

[Yunlong Song]

ping...

On 2017/10/13 21:31, Yunlong Song wrote:

This can help us to debug on some corner case.

Signed-off-by: Yunlong Song 
Signed-off-by: Chao Yu 
---
  fs/f2fs/gc.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 197ebf4..2b03202 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -986,6 +986,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
.ilist = LIST_HEAD_INIT(gc_list.ilist),
.iroot = RADIX_TREE_INIT(GFP_NOFS),
};
+   bool need_fggc = false;
  
  	trace_f2fs_gc_begin(sbi->sb, sync, background,

get_pages(sbi, F2FS_DIRTY_NODES),
@@ -1018,8 +1019,10 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
if (ret)
goto stop;
}
-   if (has_not_enough_free_secs(sbi, 0, 0))
+   if (has_not_enough_free_secs(sbi, 0, 0)) {
gc_type = FG_GC;
+   need_fggc = true;
+   }
}
  
  	/* f2fs_balance_fs doesn't need to do BG_GC in critical path. */

@@ -1028,6 +1031,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
goto stop;
}
if (!__get_victim(sbi, , gc_type)) {
+   f2fs_bug_on(sbi, !total_freed && need_fggc);
ret = -ENODATA;
goto stop;
}


--
Thanks,
Yunlong Song

Re: mptsas driver cannot detect hotplugging disk with the LSI SCSI SAS1068 controller in Ubuntu guest on VMware

[Gavin Guo]

On Sat, Oct 28, 2017 at 11:35 AM, Gavin Guo  wrote:
> On Fri, Oct 27, 2017 at 10:53 PM, Hannes Reinecke  wrote:
>> On 10/27/2017 04:02 PM, Gavin Guo wrote:
>>> Hi Hannes,
>>>
>>> Thank you for looking into the issue. If there is anything I can help
>>> to test the patch? I appreciate your help. Thank you.
>>>
>> If you had checked linux-scsi you would have found this patch:
>> '[PATCH] mptsas: Fixup device hotplug for VMWare ESXi', which I guess is
>> already scheduled for inclusion in 4.14.
>> Anything else I could help you with?
>>
>> Cheers,
>>
>> Hannes
>> --
>> Dr. Hannes ReineckeTeamlead Storage & Networking
>> h...@suse.de   +49 911 74053 688
>> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
>> GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
>> HRB 21284 (AG Nürnberg)
>
> Really appreciate your help. I will proceed the testing and keep you posted.

Hello Hannes,

I've tested the MPT SAS device controller, the patch works perfectly.
However, the MPT SPI still cannot work with the hotplugging. The lspci
of the LSI SPI device is listed:

00:10.0 SCSI storage controller [0100]: LSI Logic / Symbios Logic
53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI [1000:0030] (rev 01)
Subsystem: VMware LSI Logic Parallel SCSI Controller [15ad:1976]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- SERR- 

[tip:x86/asm 24/32] mm/migrate.o: warning: objtool: migrate_misplaced_transhuge_page()+0x71: unreachable instruction

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/asm
head:   1e4c4f610f774df6088d7c065b2dd4d22adba698
commit: da51da189a24bb9b7e2d5a123be096e51a4695a5 [24/32] x86/entry/64: Pass SP0 
directly to load_sp0()
config: x86_64-randconfig-in0-11031034 (attached as .config)
compiler: gcc-4.6 (Debian 4.6.4-7) 4.6.4
reproduce:
git checkout da51da189a24bb9b7e2d5a123be096e51a4695a5
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

>> mm/migrate.o: warning: objtool: migrate_misplaced_transhuge_page()+0x71: 
>> unreachable instruction

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


.config.gz
Description: application/gzip

[PATCH 1/3] arm64: Define cputype macros for Falkor CPU

[Shanker Donthineni]

Add cputype definition macros for Qualcomm Datacenter Technologies
Falkor CPU in cputype.h. It's unfortunate that the first revision
of the Falkor CPU used the wrong part number 0x800, got fixed in v2
chip with part number 0xC00, and would be used the same value for
future revisions.

Signed-off-by: Shanker Donthineni 
Signed-off-by: Neil Leeder 
---
 arch/arm64/include/asm/cputype.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 235e77d..cbf08d7 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -91,6 +91,7 @@
 #define BRCM_CPU_PART_VULCAN   0x516
 
 #define QCOM_CPU_PART_FALKOR_V10x800
+#define QCOM_CPU_PART_FALKOR   0xC00
 
 #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A53)
 #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A57)
@@ -99,6 +100,7 @@
 #define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
CAVIUM_CPU_PART_THUNDERX_81XX)
 #define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
CAVIUM_CPU_PART_THUNDERX_83XX)
 #define MIDR_QCOM_FALKOR_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, 
QCOM_CPU_PART_FALKOR_V1)
+#define MIDR_QCOM_FALKOR MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR)
 
 #ifndef __ASSEMBLY__
 
-- 
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, 
Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [PATCH v2] f2fs: add bug_on when f2fs_gc even fails to get one victim

[Yunlong Song]

ping...

On 2017/10/13 21:31, Yunlong Song wrote:

This can help us to debug on some corner case.

Signed-off-by: Yunlong Song 
Signed-off-by: Chao Yu 
---
  fs/f2fs/gc.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 197ebf4..2b03202 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -986,6 +986,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
.ilist = LIST_HEAD_INIT(gc_list.ilist),
.iroot = RADIX_TREE_INIT(GFP_NOFS),
};
+   bool need_fggc = false;
  
  	trace_f2fs_gc_begin(sbi->sb, sync, background,

get_pages(sbi, F2FS_DIRTY_NODES),
@@ -1018,8 +1019,10 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
if (ret)
goto stop;
}
-   if (has_not_enough_free_secs(sbi, 0, 0))
+   if (has_not_enough_free_secs(sbi, 0, 0)) {
gc_type = FG_GC;
+   need_fggc = true;
+   }
}
  
  	/* f2fs_balance_fs doesn't need to do BG_GC in critical path. */

@@ -1028,6 +1031,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
goto stop;
}
if (!__get_victim(sbi, , gc_type)) {
+   f2fs_bug_on(sbi, !total_freed && need_fggc);
ret = -ENODATA;
goto stop;
}


--
Thanks,
Yunlong Song

Re: mptsas driver cannot detect hotplugging disk with the LSI SCSI SAS1068 controller in Ubuntu guest on VMware

[Gavin Guo]

On Sat, Oct 28, 2017 at 11:35 AM, Gavin Guo  wrote:
> On Fri, Oct 27, 2017 at 10:53 PM, Hannes Reinecke  wrote:
>> On 10/27/2017 04:02 PM, Gavin Guo wrote:
>>> Hi Hannes,
>>>
>>> Thank you for looking into the issue. If there is anything I can help
>>> to test the patch? I appreciate your help. Thank you.
>>>
>> If you had checked linux-scsi you would have found this patch:
>> '[PATCH] mptsas: Fixup device hotplug for VMWare ESXi', which I guess is
>> already scheduled for inclusion in 4.14.
>> Anything else I could help you with?
>>
>> Cheers,
>>
>> Hannes
>> --
>> Dr. Hannes ReineckeTeamlead Storage & Networking
>> h...@suse.de   +49 911 74053 688
>> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
>> GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
>> HRB 21284 (AG Nürnberg)
>
> Really appreciate your help. I will proceed the testing and keep you posted.

Hello Hannes,

I've tested the MPT SAS device controller, the patch works perfectly.
However, the MPT SPI still cannot work with the hotplugging. The lspci
of the LSI SPI device is listed:

00:10.0 SCSI storage controller [0100]: LSI Logic / Symbios Logic
53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI [1000:0030] (rev 01)
Subsystem: VMware LSI Logic Parallel SCSI Controller [15ad:1976]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- SERR- 

[tip:x86/asm 24/32] mm/migrate.o: warning: objtool: migrate_misplaced_transhuge_page()+0x71: unreachable instruction

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/asm
head:   1e4c4f610f774df6088d7c065b2dd4d22adba698
commit: da51da189a24bb9b7e2d5a123be096e51a4695a5 [24/32] x86/entry/64: Pass SP0 
directly to load_sp0()
config: x86_64-randconfig-in0-11031034 (attached as .config)
compiler: gcc-4.6 (Debian 4.6.4-7) 4.6.4
reproduce:
git checkout da51da189a24bb9b7e2d5a123be096e51a4695a5
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

>> mm/migrate.o: warning: objtool: migrate_misplaced_transhuge_page()+0x71: 
>> unreachable instruction

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


.config.gz
Description: application/gzip

[PATCH 2/3] arm64: Prepare SCTLR_ELn accesses to handle Falkor erratum 1041

[Shanker Donthineni]

This patch introduces two helper macros read_sctlr and write_sctlr
to access system register SCTLR_ELn. Replace all MSR/MRS references
to sctlr_el1{el2} with macros.

This should cause no behavioral change.

Signed-off-by: Shanker Donthineni 
---
 arch/arm64/include/asm/assembler.h  | 18 ++
 arch/arm64/kernel/cpu-reset.S   |  4 ++--
 arch/arm64/kernel/efi-entry.S   |  8 
 arch/arm64/kernel/head.S| 18 +-
 arch/arm64/kernel/relocate_kernel.S |  4 ++--
 arch/arm64/kvm/hyp-init.S   |  6 +++---
 arch/arm64/mm/proc.S|  6 +++---
 7 files changed, 41 insertions(+), 23 deletions(-)

diff --git a/arch/arm64/include/asm/assembler.h 
b/arch/arm64/include/asm/assembler.h
index d58a625..b6dfb4f 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -499,4 +499,22 @@
 #endif
.endm
 
+/**
+ * Read value of the system control register SCTLR_ELn.
+ *   eln: which system control register.
+ *   reg: contents of the SCTLR_ELn.
+ */
+   .macro  read_sctlr, eln, reg
+   mrs \reg, sctlr_\eln
+   .endm
+
+/**
+ * Write the value to the system control register SCTLR_ELn.
+ *   eln: which system control register.
+ *   reg: the value to be written.
+ */
+   .macro  write_sctlr, eln, reg
+   msr sctlr_\eln, \reg
+   .endm
+
 #endif /* __ASM_ASSEMBLER_H */
diff --git a/arch/arm64/kernel/cpu-reset.S b/arch/arm64/kernel/cpu-reset.S
index 65f42d2..9224abd 100644
--- a/arch/arm64/kernel/cpu-reset.S
+++ b/arch/arm64/kernel/cpu-reset.S
@@ -34,10 +34,10 @@
  */
 ENTRY(__cpu_soft_restart)
/* Clear sctlr_el1 flags. */
-   mrs x12, sctlr_el1
+   read_sctlr el1, x12
ldr x13, =SCTLR_ELx_FLAGS
bic x12, x12, x13
-   msr sctlr_el1, x12
+   write_sctlr el1, x12
isb
 
cbz x0, 1f  // el2_switch?
diff --git a/arch/arm64/kernel/efi-entry.S b/arch/arm64/kernel/efi-entry.S
index 4e6ad35..acae627 100644
--- a/arch/arm64/kernel/efi-entry.S
+++ b/arch/arm64/kernel/efi-entry.S
@@ -93,17 +93,17 @@ ENTRY(entry)
mrs x0, CurrentEL
cmp x0, #CurrentEL_EL2
b.ne1f
-   mrs x0, sctlr_el2
+   read_sctlr el2, x0
bic x0, x0, #1 << 0 // clear SCTLR.M
bic x0, x0, #1 << 2 // clear SCTLR.C
-   msr sctlr_el2, x0
+   write_sctlr el2, x0
isb
b   2f
 1:
-   mrs x0, sctlr_el1
+   read_sctlr el1, x0
bic x0, x0, #1 << 0 // clear SCTLR.M
bic x0, x0, #1 << 2 // clear SCTLR.C
-   msr sctlr_el1, x0
+   write_sctlr el1, x0
isb
 2:
/* Jump to kernel entry point */
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 0b243ec..b8d5b73 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -388,18 +388,18 @@ ENTRY(el2_setup)
mrs x0, CurrentEL
cmp x0, #CurrentEL_EL2
b.eq1f
-   mrs x0, sctlr_el1
+   read_sctlr el1, x0
 CPU_BE(orr x0, x0, #(3 << 24)  )   // Set the EE and E0E 
bits for EL1
 CPU_LE(bic x0, x0, #(3 << 24)  )   // Clear the EE and E0E 
bits for EL1
-   msr sctlr_el1, x0
+   write_sctlr el1, x0
mov w0, #BOOT_CPU_MODE_EL1  // This cpu booted in EL1
isb
ret
 
-1: mrs x0, sctlr_el2
+1: read_sctlr el2, x0
 CPU_BE(orr x0, x0, #(1 << 25)  )   // Set the EE bit for 
EL2
 CPU_LE(bic x0, x0, #(1 << 25)  )   // Clear the EE bit for 
EL2
-   msr sctlr_el2, x0
+   write_sctlr el2, x0
 
 #ifdef CONFIG_ARM64_VHE
/*
@@ -511,7 +511,7 @@ install_el2_stub:
mov x0, #0x0800 // Set/clear RES{1,0} bits
 CPU_BE(movkx0, #0x33d0, lsl #16)   // Set EE and E0E on BE 
systems
 CPU_LE(movkx0, #0x30d0, lsl #16)   // Clear EE and E0E on 
LE systems
-   msr sctlr_el1, x0
+   write_sctlr el1, x0
 
/* Coprocessor traps. */
mov x0, #0x33ff
@@ -664,7 +664,7 @@ ENTRY(__enable_mmu)
msr ttbr0_el1, x1   // load TTBR0
msr ttbr1_el1, x2   // load TTBR1
isb
-   msr sctlr_el1, x0
+   write_sctlr el1, x0
isb
/*
 * Invalidate the local I-cache so that any instructions fetched
@@ -716,7 +716,7 @@ ENDPROC(__relocate_kernel)
 __primary_switch:
 #ifdef CONFIG_RANDOMIZE_BASE
mov x19, x0 // preserve new SCTLR_EL1 value
-   mrs x20, sctlr_el1  // preserve old SCTLR_EL1 value
+   read_sctlr el1, x20 // preserve old SCTLR_EL1 value
 #endif
 
bl  __enable_mmu
@@ -732,14 +732,14 @@ __primary_switch:
 * to take into account by discarding the current 

[PATCH 2/3] arm64: Prepare SCTLR_ELn accesses to handle Falkor erratum 1041

[Shanker Donthineni]

This patch introduces two helper macros read_sctlr and write_sctlr
to access system register SCTLR_ELn. Replace all MSR/MRS references
to sctlr_el1{el2} with macros.

This should cause no behavioral change.

Signed-off-by: Shanker Donthineni 
---
 arch/arm64/include/asm/assembler.h  | 18 ++
 arch/arm64/kernel/cpu-reset.S   |  4 ++--
 arch/arm64/kernel/efi-entry.S   |  8 
 arch/arm64/kernel/head.S| 18 +-
 arch/arm64/kernel/relocate_kernel.S |  4 ++--
 arch/arm64/kvm/hyp-init.S   |  6 +++---
 arch/arm64/mm/proc.S|  6 +++---
 7 files changed, 41 insertions(+), 23 deletions(-)

diff --git a/arch/arm64/include/asm/assembler.h 
b/arch/arm64/include/asm/assembler.h
index d58a625..b6dfb4f 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -499,4 +499,22 @@
 #endif
.endm
 
+/**
+ * Read value of the system control register SCTLR_ELn.
+ *   eln: which system control register.
+ *   reg: contents of the SCTLR_ELn.
+ */
+   .macro  read_sctlr, eln, reg
+   mrs \reg, sctlr_\eln
+   .endm
+
+/**
+ * Write the value to the system control register SCTLR_ELn.
+ *   eln: which system control register.
+ *   reg: the value to be written.
+ */
+   .macro  write_sctlr, eln, reg
+   msr sctlr_\eln, \reg
+   .endm
+
 #endif /* __ASM_ASSEMBLER_H */
diff --git a/arch/arm64/kernel/cpu-reset.S b/arch/arm64/kernel/cpu-reset.S
index 65f42d2..9224abd 100644
--- a/arch/arm64/kernel/cpu-reset.S
+++ b/arch/arm64/kernel/cpu-reset.S
@@ -34,10 +34,10 @@
  */
 ENTRY(__cpu_soft_restart)
/* Clear sctlr_el1 flags. */
-   mrs x12, sctlr_el1
+   read_sctlr el1, x12
ldr x13, =SCTLR_ELx_FLAGS
bic x12, x12, x13
-   msr sctlr_el1, x12
+   write_sctlr el1, x12
isb
 
cbz x0, 1f  // el2_switch?
diff --git a/arch/arm64/kernel/efi-entry.S b/arch/arm64/kernel/efi-entry.S
index 4e6ad35..acae627 100644
--- a/arch/arm64/kernel/efi-entry.S
+++ b/arch/arm64/kernel/efi-entry.S
@@ -93,17 +93,17 @@ ENTRY(entry)
mrs x0, CurrentEL
cmp x0, #CurrentEL_EL2
b.ne1f
-   mrs x0, sctlr_el2
+   read_sctlr el2, x0
bic x0, x0, #1 << 0 // clear SCTLR.M
bic x0, x0, #1 << 2 // clear SCTLR.C
-   msr sctlr_el2, x0
+   write_sctlr el2, x0
isb
b   2f
 1:
-   mrs x0, sctlr_el1
+   read_sctlr el1, x0
bic x0, x0, #1 << 0 // clear SCTLR.M
bic x0, x0, #1 << 2 // clear SCTLR.C
-   msr sctlr_el1, x0
+   write_sctlr el1, x0
isb
 2:
/* Jump to kernel entry point */
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 0b243ec..b8d5b73 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -388,18 +388,18 @@ ENTRY(el2_setup)
mrs x0, CurrentEL
cmp x0, #CurrentEL_EL2
b.eq1f
-   mrs x0, sctlr_el1
+   read_sctlr el1, x0
 CPU_BE(orr x0, x0, #(3 << 24)  )   // Set the EE and E0E 
bits for EL1
 CPU_LE(bic x0, x0, #(3 << 24)  )   // Clear the EE and E0E 
bits for EL1
-   msr sctlr_el1, x0
+   write_sctlr el1, x0
mov w0, #BOOT_CPU_MODE_EL1  // This cpu booted in EL1
isb
ret
 
-1: mrs x0, sctlr_el2
+1: read_sctlr el2, x0
 CPU_BE(orr x0, x0, #(1 << 25)  )   // Set the EE bit for 
EL2
 CPU_LE(bic x0, x0, #(1 << 25)  )   // Clear the EE bit for 
EL2
-   msr sctlr_el2, x0
+   write_sctlr el2, x0
 
 #ifdef CONFIG_ARM64_VHE
/*
@@ -511,7 +511,7 @@ install_el2_stub:
mov x0, #0x0800 // Set/clear RES{1,0} bits
 CPU_BE(movkx0, #0x33d0, lsl #16)   // Set EE and E0E on BE 
systems
 CPU_LE(movkx0, #0x30d0, lsl #16)   // Clear EE and E0E on 
LE systems
-   msr sctlr_el1, x0
+   write_sctlr el1, x0
 
/* Coprocessor traps. */
mov x0, #0x33ff
@@ -664,7 +664,7 @@ ENTRY(__enable_mmu)
msr ttbr0_el1, x1   // load TTBR0
msr ttbr1_el1, x2   // load TTBR1
isb
-   msr sctlr_el1, x0
+   write_sctlr el1, x0
isb
/*
 * Invalidate the local I-cache so that any instructions fetched
@@ -716,7 +716,7 @@ ENDPROC(__relocate_kernel)
 __primary_switch:
 #ifdef CONFIG_RANDOMIZE_BASE
mov x19, x0 // preserve new SCTLR_EL1 value
-   mrs x20, sctlr_el1  // preserve old SCTLR_EL1 value
+   read_sctlr el1, x20 // preserve old SCTLR_EL1 value
 #endif
 
bl  __enable_mmu
@@ -732,14 +732,14 @@ __primary_switch:
 * to take into account by discarding the current kernel mapping and
 

[PATCH 3/3] arm64: Add software workaround for Falkor erratum 1041

[Shanker Donthineni]

The ARM architecture defines the memory locations that are permitted
to be accessed as the result of a speculative instruction fetch from
an exception level for which all stages of translation are disabled.
Specifically, the core is permitted to speculatively fetch from the
4KB region containing the current program counter and next 4KB.

When translation is changed from enabled to disabled for the running
exception level (SCTLR_ELn[M] changed from a value of 1 to 0), the
Falkor core may errantly speculatively access memory locations outside
of the 4KB region permitted by the architecture. The errant memory
access may lead to one of the following unexpected behaviors.

1) A System Error Interrupt (SEI) being raised by the Falkor core due
   to the errant memory access attempting to access a region of memory
   that is protected by a slave-side memory protection unit.
2) Unpredictable device behavior due to a speculative read from device
   memory. This behavior may only occur if the instruction cache is
   disabled prior to or coincident with translation being changed from
   enabled to disabled.

To avoid the errant behavior, software must execute an ISB immediately
prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0.

Signed-off-by: Shanker Donthineni 
---
 Documentation/arm64/silicon-errata.txt |  1 +
 arch/arm64/Kconfig | 10 ++
 arch/arm64/include/asm/assembler.h | 17 +
 arch/arm64/include/asm/cpucaps.h   |  3 ++-
 arch/arm64/kernel/cpu_errata.c | 16 
 arch/arm64/kernel/efi-entry.S  |  4 ++--
 arch/arm64/kernel/head.S   |  4 ++--
 7 files changed, 50 insertions(+), 5 deletions(-)

diff --git a/Documentation/arm64/silicon-errata.txt 
b/Documentation/arm64/silicon-errata.txt
index 66e8ce1..704770c0 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -74,3 +74,4 @@ stable kernels.
 | Qualcomm Tech. | Falkor v1   | E1003   | 
QCOM_FALKOR_ERRATUM_1003|
 | Qualcomm Tech. | Falkor v1   | E1009   | 
QCOM_FALKOR_ERRATUM_1009|
 | Qualcomm Tech. | QDF2400 ITS | E0065   | 
QCOM_QDF2400_ERRATUM_0065   |
+| Qualcomm Tech. | Falkor v{1,2}   | E1041   | 
QCOM_FALKOR_ERRATUM_1041|
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 0df64a6..7e933fb 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -539,6 +539,16 @@ config QCOM_QDF2400_ERRATUM_0065
 
  If unsure, say Y.
 
+config QCOM_FALKOR_ERRATUM_1041
+   bool "Falkor E1041: Speculative instruction fetches might cause errant 
memory access"
+   default y
+   help
+ Falkor CPU may speculatively fetch instructions from an improper
+ memory location when MMU translation is changed from SCTLR_ELn[M]=1
+ to SCTLR_ELn[M]=0. Prefix an ISB instruction to fix the problem.
+
+ If unsure, say Y.
+
 endmenu
 
 
diff --git a/arch/arm64/include/asm/assembler.h 
b/arch/arm64/include/asm/assembler.h
index b6dfb4f..4c91efb 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Enable and disable interrupts.
@@ -514,6 +515,22 @@
  *   reg: the value to be written.
  */
.macro  write_sctlr, eln, reg
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1041
+alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1041
+   tbnz\reg, #0, 8000f  // enable MMU?
+   isb
+8000:
+alternative_else_nop_endif
+#endif
+   msr sctlr_\eln, \reg
+   .endm
+
+   .macro  early_write_sctlr, eln, reg
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1041
+   tbnz\reg, #0, 8000f  // enable MMU?
+   isb
+8000:
+#endif
msr sctlr_\eln, \reg
.endm
 
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 8da6216..7f7a59d 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -40,7 +40,8 @@
 #define ARM64_WORKAROUND_85892119
 #define ARM64_WORKAROUND_CAVIUM_30115  20
 #define ARM64_HAS_DCPOP21
+#define ARM64_WORKAROUND_QCOM_FALKOR_E1041 22
 
-#define ARM64_NCAPS22
+#define ARM64_NCAPS23
 
 #endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 0e27f86..27f9a45 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -179,6 +179,22 @@ static int cpu_enable_trap_ctr_access(void *__unused)
   MIDR_CPU_VAR_REV(0, 0)),
},
 #endif
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1041
+   {
+   .desc = "Qualcomm Technologies Falkor erratum 1041",
+   .capability = ARM64_WORKAROUND_QCOM_FALKOR_E1041,
+   MIDR_RANGE(MIDR_QCOM_FALKOR_V1,
+  

[PATCH 3/3] arm64: Add software workaround for Falkor erratum 1041

[Shanker Donthineni]

The ARM architecture defines the memory locations that are permitted
to be accessed as the result of a speculative instruction fetch from
an exception level for which all stages of translation are disabled.
Specifically, the core is permitted to speculatively fetch from the
4KB region containing the current program counter and next 4KB.

When translation is changed from enabled to disabled for the running
exception level (SCTLR_ELn[M] changed from a value of 1 to 0), the
Falkor core may errantly speculatively access memory locations outside
of the 4KB region permitted by the architecture. The errant memory
access may lead to one of the following unexpected behaviors.

1) A System Error Interrupt (SEI) being raised by the Falkor core due
   to the errant memory access attempting to access a region of memory
   that is protected by a slave-side memory protection unit.
2) Unpredictable device behavior due to a speculative read from device
   memory. This behavior may only occur if the instruction cache is
   disabled prior to or coincident with translation being changed from
   enabled to disabled.

To avoid the errant behavior, software must execute an ISB immediately
prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0.

Signed-off-by: Shanker Donthineni 
---
 Documentation/arm64/silicon-errata.txt |  1 +
 arch/arm64/Kconfig | 10 ++
 arch/arm64/include/asm/assembler.h | 17 +
 arch/arm64/include/asm/cpucaps.h   |  3 ++-
 arch/arm64/kernel/cpu_errata.c | 16 
 arch/arm64/kernel/efi-entry.S  |  4 ++--
 arch/arm64/kernel/head.S   |  4 ++--
 7 files changed, 50 insertions(+), 5 deletions(-)

diff --git a/Documentation/arm64/silicon-errata.txt 
b/Documentation/arm64/silicon-errata.txt
index 66e8ce1..704770c0 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -74,3 +74,4 @@ stable kernels.
 | Qualcomm Tech. | Falkor v1   | E1003   | 
QCOM_FALKOR_ERRATUM_1003|
 | Qualcomm Tech. | Falkor v1   | E1009   | 
QCOM_FALKOR_ERRATUM_1009|
 | Qualcomm Tech. | QDF2400 ITS | E0065   | 
QCOM_QDF2400_ERRATUM_0065   |
+| Qualcomm Tech. | Falkor v{1,2}   | E1041   | 
QCOM_FALKOR_ERRATUM_1041|
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 0df64a6..7e933fb 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -539,6 +539,16 @@ config QCOM_QDF2400_ERRATUM_0065
 
  If unsure, say Y.
 
+config QCOM_FALKOR_ERRATUM_1041
+   bool "Falkor E1041: Speculative instruction fetches might cause errant 
memory access"
+   default y
+   help
+ Falkor CPU may speculatively fetch instructions from an improper
+ memory location when MMU translation is changed from SCTLR_ELn[M]=1
+ to SCTLR_ELn[M]=0. Prefix an ISB instruction to fix the problem.
+
+ If unsure, say Y.
+
 endmenu
 
 
diff --git a/arch/arm64/include/asm/assembler.h 
b/arch/arm64/include/asm/assembler.h
index b6dfb4f..4c91efb 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Enable and disable interrupts.
@@ -514,6 +515,22 @@
  *   reg: the value to be written.
  */
.macro  write_sctlr, eln, reg
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1041
+alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1041
+   tbnz\reg, #0, 8000f  // enable MMU?
+   isb
+8000:
+alternative_else_nop_endif
+#endif
+   msr sctlr_\eln, \reg
+   .endm
+
+   .macro  early_write_sctlr, eln, reg
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1041
+   tbnz\reg, #0, 8000f  // enable MMU?
+   isb
+8000:
+#endif
msr sctlr_\eln, \reg
.endm
 
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 8da6216..7f7a59d 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -40,7 +40,8 @@
 #define ARM64_WORKAROUND_85892119
 #define ARM64_WORKAROUND_CAVIUM_30115  20
 #define ARM64_HAS_DCPOP21
+#define ARM64_WORKAROUND_QCOM_FALKOR_E1041 22
 
-#define ARM64_NCAPS22
+#define ARM64_NCAPS23
 
 #endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 0e27f86..27f9a45 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -179,6 +179,22 @@ static int cpu_enable_trap_ctr_access(void *__unused)
   MIDR_CPU_VAR_REV(0, 0)),
},
 #endif
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1041
+   {
+   .desc = "Qualcomm Technologies Falkor erratum 1041",
+   .capability = ARM64_WORKAROUND_QCOM_FALKOR_E1041,
+   MIDR_RANGE(MIDR_QCOM_FALKOR_V1,
+   

[PATCH 0/3] Implement a software workaround for Falkor erratum 1041

[Shanker Donthineni]

On Falkor CPU, we’ve discovered a hardware issue which might lead to a
kernel crash or the unexpected behavior. The Falkor core may errantly
access memory locations on speculative instruction fetches. This may
happen whenever MMU translation state, SCTLR_ELn[M] bit is being changed
from enabled to disabled for the currently running exception level. To
prevent the errant hardware behavior, software must execute an ISB
immediately prior to executing the MSR that changes SCTLR_ELn[M] from a
value of 1 to 0. To simplify the complexity of a workaround, this patch
series issues an ISB whenever SCTLR_ELn[M] is changed to 0 to fix the
Falkor erratum 1041.

Patch1:
  - CPUTYPE definitions for Falkor CPU.

Patch2:
  - Define two ASM helper macros to read/write SCTLR_ELn register.

Patch3:
  - Actual workaround changes for erratum E1041.

Shanker Donthineni (3):
  arm64: Define cputype macros for Falkor CPU
  arm64: Prepare SCTLR_ELn accesses to handle Falkor erratum 1041
  arm64: Add software workaround for Falkor erratum 1041

 Documentation/arm64/silicon-errata.txt |  1 +
 arch/arm64/Kconfig | 10 ++
 arch/arm64/include/asm/assembler.h | 35 ++
 arch/arm64/include/asm/cpucaps.h   |  3 ++-
 arch/arm64/include/asm/cputype.h   |  2 ++
 arch/arm64/kernel/cpu-reset.S  |  4 ++--
 arch/arm64/kernel/cpu_errata.c | 16 
 arch/arm64/kernel/efi-entry.S  |  8 
 arch/arm64/kernel/head.S   | 18 -
 arch/arm64/kernel/relocate_kernel.S|  4 ++--
 arch/arm64/kvm/hyp-init.S  |  6 +++---
 arch/arm64/mm/proc.S   |  6 +++---
 12 files changed, 89 insertions(+), 24 deletions(-)

-- 
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, 
Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH 0/3] Implement a software workaround for Falkor erratum 1041

[Shanker Donthineni]

On Falkor CPU, we’ve discovered a hardware issue which might lead to a
kernel crash or the unexpected behavior. The Falkor core may errantly
access memory locations on speculative instruction fetches. This may
happen whenever MMU translation state, SCTLR_ELn[M] bit is being changed
from enabled to disabled for the currently running exception level. To
prevent the errant hardware behavior, software must execute an ISB
immediately prior to executing the MSR that changes SCTLR_ELn[M] from a
value of 1 to 0. To simplify the complexity of a workaround, this patch
series issues an ISB whenever SCTLR_ELn[M] is changed to 0 to fix the
Falkor erratum 1041.

Patch1:
  - CPUTYPE definitions for Falkor CPU.

Patch2:
  - Define two ASM helper macros to read/write SCTLR_ELn register.

Patch3:
  - Actual workaround changes for erratum E1041.

Shanker Donthineni (3):
  arm64: Define cputype macros for Falkor CPU
  arm64: Prepare SCTLR_ELn accesses to handle Falkor erratum 1041
  arm64: Add software workaround for Falkor erratum 1041

 Documentation/arm64/silicon-errata.txt |  1 +
 arch/arm64/Kconfig | 10 ++
 arch/arm64/include/asm/assembler.h | 35 ++
 arch/arm64/include/asm/cpucaps.h   |  3 ++-
 arch/arm64/include/asm/cputype.h   |  2 ++
 arch/arm64/kernel/cpu-reset.S  |  4 ++--
 arch/arm64/kernel/cpu_errata.c | 16 
 arch/arm64/kernel/efi-entry.S  |  8 
 arch/arm64/kernel/head.S   | 18 -
 arch/arm64/kernel/relocate_kernel.S|  4 ++--
 arch/arm64/kvm/hyp-init.S  |  6 +++---
 arch/arm64/mm/proc.S   |  6 +++---
 12 files changed, 89 insertions(+), 24 deletions(-)

-- 
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, 
Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

MAP_SYNC in libnvdimm-for-next and collision fixups

[Williams, Dan J]

Hi Stephen,

I've pushed a new libnvdimm-for-next branch that includes the libnvdimm
update for 4.15 as well as the MAP_SYNC patch set for -next exposure.
It has some collisions with code already pending in -next. My proposed
merge resolution is here:

https://git.kernel.org/pub/scm/linux/kernel/git/djbw/nvdimm.git/log/?h=
libnvdimm-vs-next-20171102

---
commit 2adeca04276acb4e747dbe7a5668efe03b164566
Merge: fa8785e862ef c29c91a9daa3
Author: Dan Williams <dan.j.willi...@intel.com>
Date:   Thu Nov 2 19:20:59 2017 -0700

Merge branch 'libnvdimm-for-next' into test

diff --cc fs/dax.c
index 3652b26a0048,78233c716757..f3a7fb804a50
--- a/fs/dax.c
+++ b/fs/dax.c
@@@ -825,38 -820,42 +825,42 @@@ out
  }
  EXPORT_SYMBOL_GPL(dax_writeback_mapping_range);
  
- static int dax_insert_mapping(struct address_space *mapping,
-   struct block_device *bdev, struct dax_device *dax_dev,
-   sector_t sector, size_t size, void *entry,
-   struct vm_area_struct *vma, struct vm_fault *vmf)
+ static sector_t dax_iomap_sector(struct iomap *iomap, loff_t pos)
  {
-   unsigned long vaddr = vmf->address;
-   void *ret, *kaddr;
 -  return iomap->blkno + (((pos & PAGE_MASK) - iomap->offset) >> 9);
++  return (iomap->addr + (pos & PAGE_MASK) - iomap->offset) >> 9;
+ }
+ 
+ static int dax_iomap_pfn(struct iomap *iomap, loff_t pos, size_t size,
+pfn_t *pfnp)
+ {
+   const sector_t sector = dax_iomap_sector(iomap, pos);
pgoff_t pgoff;
+   void *kaddr;
int id, rc;
-   pfn_t pfn;
+   long length;
  
-   rc = bdev_dax_pgoff(bdev, sector, size, );
+   rc = bdev_dax_pgoff(iomap->bdev, sector, size, );
if (rc)
return rc;
- 
id = dax_read_lock();
-   rc = dax_direct_access(dax_dev, pgoff, PHYS_PFN(size), , );
-   if (rc < 0) {
-   dax_read_unlock(id);
-   return rc;
+   length = dax_direct_access(iomap->dax_dev, pgoff, PHYS_PFN(size),
+  , pfnp);
+   if (length < 0) {
+   rc = length;
+   goto out;
}
+   rc = -EINVAL;
+   if (PFN_PHYS(length) < size)
+   goto out;
+   if (pfn_t_to_pfn(*pfnp) & (PHYS_PFN(size)-1))
+   goto out;
+   /* For larger pages we need devmap */
+   if (length > 1 && !pfn_t_devmap(*pfnp))
+   goto out;
+   rc = 0;
+ out:
dax_read_unlock(id);
- 
-   ret = dax_insert_mapping_entry(mapping, vmf, entry, sector, 0);
-   if (IS_ERR(ret))
-   return PTR_ERR(ret);
- 
-   trace_dax_insert_mapping(mapping->host, vmf, ret);
-   if (vmf->flags & FAULT_FLAG_WRITE)
-   return vm_insert_mixed_mkwrite(vma, vaddr, pfn);
-   else
-   return vm_insert_mixed(vma, vaddr, pfn);
+   return rc;
  }
  
  /*
diff --cc fs/ext4/inode.c
index 59d31fec67ae,13a198924a0f..7250861f0f7b
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@@ -3383,6 -3393,20 +3383,19 @@@ static int ext4_releasepage(struct pag
return try_to_free_buffers(page);
  }
  
 -#ifdef CONFIG_FS_DAX
+ static bool ext4_inode_datasync_dirty(struct inode *inode)
+ {
+   journal_t *journal = EXT4_SB(inode->i_sb)->s_journal;
+ 
+   if (journal)
+   return !jbd2_transaction_committed(journal,
+   EXT4_I(inode)->i_datasync_tid);
+   /* Any metadata buffers to write? */
+   if (!list_empty(>i_mapping->private_list))
+   return true;
+   return inode->i_state & I_DIRTY_DATASYNC;
+ }
+ 
  static int ext4_iomap_begin(struct inode *inode, loff_t offset, loff_t length,
unsigned flags, struct iomap *iomap)
  {
diff --cc include/linux/iomap.h
index a61be86710b5,73e3b7085dbe..a309d611d380
--- a/include/linux/iomap.h
+++ b/include/linux/iomap.h
@@@ -21,8 -21,12 +21,13 @@@ struct vm_fault
  /*
   * Flags for all iomap mappings:
   */
 -#define IOMAP_F_NEW   0x01/* blocks have been newly allocated */
 +#define IOMAP_F_NEW   0x01/* blocks have been newly allocated */
 +#define IOMAP_F_BOUNDARY  0x02/* mapping ends at metadata boundary */
+ /*
+  * IOMAP_F_DIRTY indicates the inode has uncommitted metadata needed to access
+  * written data and requires fdatasync to commit them to persistent storage.
+  */
 -#define IOMAP_F_DIRTY 0x02
++#define IOMAP_F_DIRTY 0x04
  
  /*
   * Flags that only need to be reported for IOMAP_REPORT requests:

MAP_SYNC in libnvdimm-for-next and collision fixups

[Williams, Dan J]

Hi Stephen,

I've pushed a new libnvdimm-for-next branch that includes the libnvdimm
update for 4.15 as well as the MAP_SYNC patch set for -next exposure.
It has some collisions with code already pending in -next. My proposed
merge resolution is here:

https://git.kernel.org/pub/scm/linux/kernel/git/djbw/nvdimm.git/log/?h=
libnvdimm-vs-next-20171102

---
commit 2adeca04276acb4e747dbe7a5668efe03b164566
Merge: fa8785e862ef c29c91a9daa3
Author: Dan Williams 
Date:   Thu Nov 2 19:20:59 2017 -0700

Merge branch 'libnvdimm-for-next' into test

diff --cc fs/dax.c
index 3652b26a0048,78233c716757..f3a7fb804a50
--- a/fs/dax.c
+++ b/fs/dax.c
@@@ -825,38 -820,42 +825,42 @@@ out
  }
  EXPORT_SYMBOL_GPL(dax_writeback_mapping_range);
  
- static int dax_insert_mapping(struct address_space *mapping,
-   struct block_device *bdev, struct dax_device *dax_dev,
-   sector_t sector, size_t size, void *entry,
-   struct vm_area_struct *vma, struct vm_fault *vmf)
+ static sector_t dax_iomap_sector(struct iomap *iomap, loff_t pos)
  {
-   unsigned long vaddr = vmf->address;
-   void *ret, *kaddr;
 -  return iomap->blkno + (((pos & PAGE_MASK) - iomap->offset) >> 9);
++  return (iomap->addr + (pos & PAGE_MASK) - iomap->offset) >> 9;
+ }
+ 
+ static int dax_iomap_pfn(struct iomap *iomap, loff_t pos, size_t size,
+pfn_t *pfnp)
+ {
+   const sector_t sector = dax_iomap_sector(iomap, pos);
pgoff_t pgoff;
+   void *kaddr;
int id, rc;
-   pfn_t pfn;
+   long length;
  
-   rc = bdev_dax_pgoff(bdev, sector, size, );
+   rc = bdev_dax_pgoff(iomap->bdev, sector, size, );
if (rc)
return rc;
- 
id = dax_read_lock();
-   rc = dax_direct_access(dax_dev, pgoff, PHYS_PFN(size), , );
-   if (rc < 0) {
-   dax_read_unlock(id);
-   return rc;
+   length = dax_direct_access(iomap->dax_dev, pgoff, PHYS_PFN(size),
+  , pfnp);
+   if (length < 0) {
+   rc = length;
+   goto out;
}
+   rc = -EINVAL;
+   if (PFN_PHYS(length) < size)
+   goto out;
+   if (pfn_t_to_pfn(*pfnp) & (PHYS_PFN(size)-1))
+   goto out;
+   /* For larger pages we need devmap */
+   if (length > 1 && !pfn_t_devmap(*pfnp))
+   goto out;
+   rc = 0;
+ out:
dax_read_unlock(id);
- 
-   ret = dax_insert_mapping_entry(mapping, vmf, entry, sector, 0);
-   if (IS_ERR(ret))
-   return PTR_ERR(ret);
- 
-   trace_dax_insert_mapping(mapping->host, vmf, ret);
-   if (vmf->flags & FAULT_FLAG_WRITE)
-   return vm_insert_mixed_mkwrite(vma, vaddr, pfn);
-   else
-   return vm_insert_mixed(vma, vaddr, pfn);
+   return rc;
  }
  
  /*
diff --cc fs/ext4/inode.c
index 59d31fec67ae,13a198924a0f..7250861f0f7b
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@@ -3383,6 -3393,20 +3383,19 @@@ static int ext4_releasepage(struct pag
return try_to_free_buffers(page);
  }
  
 -#ifdef CONFIG_FS_DAX
+ static bool ext4_inode_datasync_dirty(struct inode *inode)
+ {
+   journal_t *journal = EXT4_SB(inode->i_sb)->s_journal;
+ 
+   if (journal)
+   return !jbd2_transaction_committed(journal,
+   EXT4_I(inode)->i_datasync_tid);
+   /* Any metadata buffers to write? */
+   if (!list_empty(>i_mapping->private_list))
+   return true;
+   return inode->i_state & I_DIRTY_DATASYNC;
+ }
+ 
  static int ext4_iomap_begin(struct inode *inode, loff_t offset, loff_t length,
unsigned flags, struct iomap *iomap)
  {
diff --cc include/linux/iomap.h
index a61be86710b5,73e3b7085dbe..a309d611d380
--- a/include/linux/iomap.h
+++ b/include/linux/iomap.h
@@@ -21,8 -21,12 +21,13 @@@ struct vm_fault
  /*
   * Flags for all iomap mappings:
   */
 -#define IOMAP_F_NEW   0x01/* blocks have been newly allocated */
 +#define IOMAP_F_NEW   0x01/* blocks have been newly allocated */
 +#define IOMAP_F_BOUNDARY  0x02/* mapping ends at metadata boundary */
+ /*
+  * IOMAP_F_DIRTY indicates the inode has uncommitted metadata needed to access
+  * written data and requires fdatasync to commit them to persistent storage.
+  */
 -#define IOMAP_F_DIRTY 0x02
++#define IOMAP_F_DIRTY 0x04
  
  /*
   * Flags that only need to be reported for IOMAP_REPORT requests:

Re: [PATCH] selftests: breakpoints: fix compile error on breakpoint_test_arm64

[Sumit Semwal]

Hi Shuah,

On 2 November 2017 at 02:22, Shuah Khan  wrote:
> On 10/23/2017 01:42 AM, Sumit Semwal wrote:
>> The current mainline breakpoints test for arm64 fails to compile with
>>
>> breakpoint_test_arm64.c: In function ‘set_watchpoint’:
>> breakpoint_test_arm64.c:97:28: error: storage size of ‘dreg_state’ isn’t 
>> known
>>   struct user_hwdebug_state dreg_state;
>>
>> Adding a direct include for asm/ptrace.h helps it to build, and passes
>> the test on mainline on hikey.
>>
>> Signed-off-by: Sumit Semwal 
>> ---
>>  tools/testing/selftests/breakpoints/breakpoint_test_arm64.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c 
>> b/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c
>> index 960d02100c26..2d95e5adde72 100644
>> --- a/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c
>> +++ b/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c
>> @@ -19,6 +19,7 @@
>>
>>  #define _GNU_SOURCE
>>
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>>
>
> Sumit,
>
> Thanks for the patch. I will queue this up for 4.15-rc1.
> This can be marked for stable I would assume?
Thank you; yes, it would need to be marked for 4.10+ kernels. Once you
add it to your tree, I can send a separate request to stable.
>
> thanks,
> -- Shuah

Best,
Sumit.

Re: [PATCH] selftests: breakpoints: fix compile error on breakpoint_test_arm64

[Sumit Semwal]

Hi Shuah,

On 2 November 2017 at 02:22, Shuah Khan  wrote:
> On 10/23/2017 01:42 AM, Sumit Semwal wrote:
>> The current mainline breakpoints test for arm64 fails to compile with
>>
>> breakpoint_test_arm64.c: In function ‘set_watchpoint’:
>> breakpoint_test_arm64.c:97:28: error: storage size of ‘dreg_state’ isn’t 
>> known
>>   struct user_hwdebug_state dreg_state;
>>
>> Adding a direct include for asm/ptrace.h helps it to build, and passes
>> the test on mainline on hikey.
>>
>> Signed-off-by: Sumit Semwal 
>> ---
>>  tools/testing/selftests/breakpoints/breakpoint_test_arm64.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c 
>> b/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c
>> index 960d02100c26..2d95e5adde72 100644
>> --- a/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c
>> +++ b/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c
>> @@ -19,6 +19,7 @@
>>
>>  #define _GNU_SOURCE
>>
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>>
>
> Sumit,
>
> Thanks for the patch. I will queue this up for 4.15-rc1.
> This can be marked for stable I would assume?
Thank you; yes, it would need to be marked for 4.10+ kernels. Once you
add it to your tree, I can send a separate request to stable.
>
> thanks,
> -- Shuah

Best,
Sumit.

Re: [PATCH] powerpc/perf: Fix core-imc hotplug callback failure during imc initialization

[Madhavan Srinivasan]

On Friday 03 November 2017 05:49 AM, Michael Ellerman wrote:

Madhavan Srinivasan  writes:


On Wednesday 01 November 2017 06:22 AM, Michael Ellerman wrote:

Anju T Sudhakar  writes:


Call trace observed during boot:

What's the actual oops?

I could recreate this in mambo with CPUS=2 and THREAD=2

That boots fine for me.

Presumably you've also done something to cause the CPU online to fail
and trigger the bug.


My bad. Yes, in the mem_init code for the second core,
i forced a fail in mambo with below hack.

diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
index 38fdaee5c61f..11fac5d78324 100644
--- a/arch/powerpc/perf/imc-pmu.c
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -548,6 +548,9 @@ static int core_imc_mem_init(int cpu, int size)
    rc = opal_imc_counters_init(OPAL_IMC_COUNTERS_CORE,
    __pa((void *)mem_info->vbase),
    get_hard_smp_processor_id(cpu));
+   if (cpu == 2)
+   rc = -1;
+
    if (rc) {
    free_pages((u64)mem_info->vbase, get_order(size));
    mem_info->vbase = NULL;


Sorry for missed this detail.

Maddy




Here is the complete stack trace.

[    0.045367] core_imc memory allocation for cpu 2 failed
[    0.045408] Unable to handle kernel paging request for data at
address 0x7d20e2a6f92d03b8
[    0.045443] Faulting instruction address: 0xc00dde18
cpu 0x0: Vector: 380 (Data Access Out of Range) at [c000fd1cb890]
      pc: c00dde18: event_function_call+0x28/0x14c
      lr: c00dde00: event_function_call+0x10/0x14c
      sp: c000fd1cbb10
     msr: 90009033
     dar: 7d20e2a6f92d03b8
    current = 0xc000fd15da00
    paca    = 0xcfff   softe: 0    irq_happened: 0x01
      pid   = 11, comm = cpuhp/0
Linux version 4.14.0-rc7-00014-g0a08377b127b (maddy@SrihariSrinidhi)
(gcc version 5.4.0 20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.1)) #5 SMP
Wed Nov 1 14:12:27 IST 2017
enter ? for help
[c000fd1cbb10]  (unreliable)
[c000fd1cbba0] c00de180 perf_remove_from_context+0x30/0x9c
[c000fd1cbbe0] c00e9108 perf_pmu_migrate_context+0x9c/0x224
[c000fd1cbc60] c00682e0 ppc_core_imc_cpu_offline+0xdc/0x144
[c000fd1cbcb0] c0070568 cpuhp_invoke_callback+0xe4/0x244
[c000fd1cbd10] c0070824 cpuhp_thread_fun+0x15c/0x1b0
[c000fd1cbd60] c008e8cc smpboot_thread_fn+0x1e0/0x200
[c000fd1cbdc0] c008ae58 kthread+0x150/0x158
[c000fd1cbe30] c000b464 ret_from_kernel_thread+0x5c/0x78



[c00ff38ffb80] c02ddfac perf_pmu_migrate_context+0xac/0x470
[c00ff38ffc40] c011385c ppc_core_imc_cpu_offline+0x1ac/0x1e0
[c00ff38ffc90] c0125758 cpuhp_invoke_callback+0x198/0x5d0
[c00ff38ffd00] c012782c cpuhp_thread_fun+0x8c/0x3d0
[c00ff38ffd60] c01678d0 smpboot_thread_fn+0x290/0x2a0
[c00ff38ffdc0] c015ee78 kthread+0x168/0x1b0
[c00ff38ffe30] c000b368 ret_from_kernel_thread+0x5c/0x74

While registering the cpuhoplug callbacks for core-imc, if we fails
in the cpuhotplug online path for any random core (either because opal call to
initialize the core-imc counters fails or because memory allocation fails for
that core), ppc_core_imc_cpu_offline() will get invoked for other cpus who
successfully returned from cpuhotplug online path.

But in the ppc_core_imc_cpu_offline() path we are trying to migrate the event
context, when core-imc counters are not even initialized. Thus creating the
above stack dump.

Add a check to see if core-imc counters are enabled or not in the cpuhotplug
offline path before migrating the context to handle this failing scenario.

Why do we need a bool to track this? Can't we just check the data
structure we're deinitialising has been initialised?

My bad. yes we could do that. Something like this will work?

@@ -606,6 +608,20 @@ static int ppc_core_imc_cpu_offline(unsigned int cpu)
      if (!cpumask_test_and_clear_cpu(cpu, _imc_cpumask))
      return 0;

+   /*
+    * Check whether core_imc is registered. We could end up here
+    * if the cpuhotplug callback registration fails. i.e, callback
+    * invokes the offline path for all sucessfully registered cpus.
+    * At this stage, core_imc pmu will not be registered and we
+    * should return here.
+    *
+    * We return with a zero since this is not a offline failure.
+    * And cpuhp_setup_state() returns the actual failure reason
+    * to the caller, which inturn will call the cleanup routine.
+    */
+   if (!core_imc_pmu->pmu.event_init)
+   return 0;
+
      /* Find any online cpu in that core except the current "cpu" */
      ncpu = cpumask_any_but(cpu_sibling_mask(cpu), cpu);


That's not ideal, because you're grovelling into the details of the pmu

Re: [PATCH] powerpc/perf: Fix core-imc hotplug callback failure during imc initialization

[Madhavan Srinivasan]

On Friday 03 November 2017 05:49 AM, Michael Ellerman wrote:

Madhavan Srinivasan  writes:


On Wednesday 01 November 2017 06:22 AM, Michael Ellerman wrote:

Anju T Sudhakar  writes:


Call trace observed during boot:

What's the actual oops?

I could recreate this in mambo with CPUS=2 and THREAD=2

That boots fine for me.

Presumably you've also done something to cause the CPU online to fail
and trigger the bug.


My bad. Yes, in the mem_init code for the second core,
i forced a fail in mambo with below hack.

diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
index 38fdaee5c61f..11fac5d78324 100644
--- a/arch/powerpc/perf/imc-pmu.c
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -548,6 +548,9 @@ static int core_imc_mem_init(int cpu, int size)
    rc = opal_imc_counters_init(OPAL_IMC_COUNTERS_CORE,
    __pa((void *)mem_info->vbase),
    get_hard_smp_processor_id(cpu));
+   if (cpu == 2)
+   rc = -1;
+
    if (rc) {
    free_pages((u64)mem_info->vbase, get_order(size));
    mem_info->vbase = NULL;


Sorry for missed this detail.

Maddy




Here is the complete stack trace.

[    0.045367] core_imc memory allocation for cpu 2 failed
[    0.045408] Unable to handle kernel paging request for data at
address 0x7d20e2a6f92d03b8
[    0.045443] Faulting instruction address: 0xc00dde18
cpu 0x0: Vector: 380 (Data Access Out of Range) at [c000fd1cb890]
      pc: c00dde18: event_function_call+0x28/0x14c
      lr: c00dde00: event_function_call+0x10/0x14c
      sp: c000fd1cbb10
     msr: 90009033
     dar: 7d20e2a6f92d03b8
    current = 0xc000fd15da00
    paca    = 0xcfff   softe: 0    irq_happened: 0x01
      pid   = 11, comm = cpuhp/0
Linux version 4.14.0-rc7-00014-g0a08377b127b (maddy@SrihariSrinidhi)
(gcc version 5.4.0 20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.1)) #5 SMP
Wed Nov 1 14:12:27 IST 2017
enter ? for help
[c000fd1cbb10]  (unreliable)
[c000fd1cbba0] c00de180 perf_remove_from_context+0x30/0x9c
[c000fd1cbbe0] c00e9108 perf_pmu_migrate_context+0x9c/0x224
[c000fd1cbc60] c00682e0 ppc_core_imc_cpu_offline+0xdc/0x144
[c000fd1cbcb0] c0070568 cpuhp_invoke_callback+0xe4/0x244
[c000fd1cbd10] c0070824 cpuhp_thread_fun+0x15c/0x1b0
[c000fd1cbd60] c008e8cc smpboot_thread_fn+0x1e0/0x200
[c000fd1cbdc0] c008ae58 kthread+0x150/0x158
[c000fd1cbe30] c000b464 ret_from_kernel_thread+0x5c/0x78



[c00ff38ffb80] c02ddfac perf_pmu_migrate_context+0xac/0x470
[c00ff38ffc40] c011385c ppc_core_imc_cpu_offline+0x1ac/0x1e0
[c00ff38ffc90] c0125758 cpuhp_invoke_callback+0x198/0x5d0
[c00ff38ffd00] c012782c cpuhp_thread_fun+0x8c/0x3d0
[c00ff38ffd60] c01678d0 smpboot_thread_fn+0x290/0x2a0
[c00ff38ffdc0] c015ee78 kthread+0x168/0x1b0
[c00ff38ffe30] c000b368 ret_from_kernel_thread+0x5c/0x74

While registering the cpuhoplug callbacks for core-imc, if we fails
in the cpuhotplug online path for any random core (either because opal call to
initialize the core-imc counters fails or because memory allocation fails for
that core), ppc_core_imc_cpu_offline() will get invoked for other cpus who
successfully returned from cpuhotplug online path.

But in the ppc_core_imc_cpu_offline() path we are trying to migrate the event
context, when core-imc counters are not even initialized. Thus creating the
above stack dump.

Add a check to see if core-imc counters are enabled or not in the cpuhotplug
offline path before migrating the context to handle this failing scenario.

Why do we need a bool to track this? Can't we just check the data
structure we're deinitialising has been initialised?

My bad. yes we could do that. Something like this will work?

@@ -606,6 +608,20 @@ static int ppc_core_imc_cpu_offline(unsigned int cpu)
      if (!cpumask_test_and_clear_cpu(cpu, _imc_cpumask))
      return 0;

+   /*
+    * Check whether core_imc is registered. We could end up here
+    * if the cpuhotplug callback registration fails. i.e, callback
+    * invokes the offline path for all sucessfully registered cpus.
+    * At this stage, core_imc pmu will not be registered and we
+    * should return here.
+    *
+    * We return with a zero since this is not a offline failure.
+    * And cpuhp_setup_state() returns the actual failure reason
+    * to the caller, which inturn will call the cleanup routine.
+    */
+   if (!core_imc_pmu->pmu.event_init)
+   return 0;
+
      /* Find any online cpu in that core except the current "cpu" */
      ncpu = cpumask_any_but(cpu_sibling_mask(cpu), cpu);


That's not ideal, because you're grovelling into the details of the pmu
struct. But I guess it's OK for now.

cheers

Re: [PATCH] selftests: remove obsolete kconfig fragment for cpu-hotplug

[Sumit Semwal]

Hello Lei,

On 2 November 2017 at 07:43, lyang0  wrote:
>
>
> On 2017年11月02日 06:59, Shuah Khan wrote:
>>
>> On 11/01/2017 04:52 PM, Thomas Gleixner wrote:
>>>
>>> On Wed, 1 Nov 2017, Shuah Khan wrote:

 On 10/17/2017 08:10 PM, lei.y...@windriver.com wrote:
>
> From: Lei Yang 
>
> Kconfig CONFIG_CPU_NOTIFIER_ERROR_INJECT has been removed since kernel
> 4.10
> check commit:
>  commit 530e9b76ae8f863dfdef4a6ad0b38613d32e8c3f
>  Author: Thomas Gleixner 
>  Date:   Wed Dec 21 20:19:53 2016 +0100
>
>  cpu/hotplug: Remove obsolete cpu hotplug register/unregister
> functions
>
>  hotcpu_notifier(), cpu_notifier(), __hotcpu_notifier(),
> __cpu_notifier(),
>  register_hotcpu_notifier(), register_cpu_notifier(),
>  __register_hotcpu_notifier(), __register_cpu_notifier(),
>  unregister_hotcpu_notifier(), unregister_cpu_notifier(),
>  __unregister_hotcpu_notifier(), __unregister_cpu_notifier()
>   
>
> Signed-off-by: Lei Yang 
> ---
>   tools/testing/selftests/cpu-hotplug/config | 1 -
>   1 file changed, 1 deletion(-)
>
> diff --git a/tools/testing/selftests/cpu-hotplug/config
> b/tools/testing/selftests/cpu-hotplug/config
> index e6ab090..d4aca2a 100644
> --- a/tools/testing/selftests/cpu-hotplug/config
> +++ b/tools/testing/selftests/cpu-hotplug/config
> @@ -1,2 +1 @@
>   CONFIG_NOTIFIER_ERROR_INJECTION=y
> -CONFIG_CPU_NOTIFIER_ERROR_INJECT=m
>
 Yes. It is removed from the kernel. However, selftests from the latest
 release do get run routinely on older stable releases. Dropping the
 config will impact coverage on older releases.

 Thomas/Greg,

 Any ideas on what we should do about this. On one hand it is a good idea
 to remove it, however my concern is coverage on older releases.
>>>
>>> Can you check the kernel version on which you are running and do it
>>> runtime
>>> conditionally?
>>>
>> I have been avoiding adding kernel version checks to tests. Maybe this is
>> one exception since the functionality is obsoleted.
>
>
>
> I think the baseline is that we only assure kselftest  works on the release
> it belongs to, for example, removing this config for the
> version above 4.10, keep it in old release.  but looks it doesn't work like
> this way.
>
> I think We can't  assure latest kselftest works still well on a very older
> releases
> yes, for some features it's common for each release. but we have some
> features that are only available in newer
> release.   even for the common features, it's difficult to make sure it
> still works well for each
> release. maintenance is a big effort if we use something like version check.
> you never know what changes will make
> for general feature in the future release although it's common right now.

As Greg and several others have reiterated - the tests should be able
to check for presence of a feature, run it if it's applicable, and
skip if it's not. It really isn't about kernel version check, but
writing code and test in such a way that tests can 'degrade
gracefully', rather than fail. There are several good examples for the
same.

The idea of running newer tests is to gain coverage on older kernels
for features still present in them, but tests weren't available at the
time of the kernel tagging.

Hope this helps clear the doubt?
>
> Lei
>
>
>> In any case, just removing the config isn't the complete solution. I will
>> have to think about this some.
>>
>> thanks,
>> -- Shuah
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kselftest"
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
Best,
Sumit.

Re: [greybus-dev] [PATCH 2/2] staging: greybus/loopback: use ktime_get() for time intervals

[Viresh Kumar]

On 02-11-17, 15:32, Arnd Bergmann wrote:
> This driver is the only one using the deprecated timeval_to_ns()
> helper. Changing it from do_gettimeofday() to ktime_get() makes
> the code more efficient, more robust against concurrent
> settimeofday(), more accurate and lets us get rid of that helper
> in the future.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/staging/greybus/loopback.c | 42 
> --
>  1 file changed, 18 insertions(+), 24 deletions(-)

Reviewed-by: Viresh Kumar 

-- 
viresh

Re: [PATCH] selftests: remove obsolete kconfig fragment for cpu-hotplug

[Sumit Semwal]

Hello Lei,

On 2 November 2017 at 07:43, lyang0  wrote:
>
>
> On 2017年11月02日 06:59, Shuah Khan wrote:
>>
>> On 11/01/2017 04:52 PM, Thomas Gleixner wrote:
>>>
>>> On Wed, 1 Nov 2017, Shuah Khan wrote:

 On 10/17/2017 08:10 PM, lei.y...@windriver.com wrote:
>
> From: Lei Yang 
>
> Kconfig CONFIG_CPU_NOTIFIER_ERROR_INJECT has been removed since kernel
> 4.10
> check commit:
>  commit 530e9b76ae8f863dfdef4a6ad0b38613d32e8c3f
>  Author: Thomas Gleixner 
>  Date:   Wed Dec 21 20:19:53 2016 +0100
>
>  cpu/hotplug: Remove obsolete cpu hotplug register/unregister
> functions
>
>  hotcpu_notifier(), cpu_notifier(), __hotcpu_notifier(),
> __cpu_notifier(),
>  register_hotcpu_notifier(), register_cpu_notifier(),
>  __register_hotcpu_notifier(), __register_cpu_notifier(),
>  unregister_hotcpu_notifier(), unregister_cpu_notifier(),
>  __unregister_hotcpu_notifier(), __unregister_cpu_notifier()
>   
>
> Signed-off-by: Lei Yang 
> ---
>   tools/testing/selftests/cpu-hotplug/config | 1 -
>   1 file changed, 1 deletion(-)
>
> diff --git a/tools/testing/selftests/cpu-hotplug/config
> b/tools/testing/selftests/cpu-hotplug/config
> index e6ab090..d4aca2a 100644
> --- a/tools/testing/selftests/cpu-hotplug/config
> +++ b/tools/testing/selftests/cpu-hotplug/config
> @@ -1,2 +1 @@
>   CONFIG_NOTIFIER_ERROR_INJECTION=y
> -CONFIG_CPU_NOTIFIER_ERROR_INJECT=m
>
 Yes. It is removed from the kernel. However, selftests from the latest
 release do get run routinely on older stable releases. Dropping the
 config will impact coverage on older releases.

 Thomas/Greg,

 Any ideas on what we should do about this. On one hand it is a good idea
 to remove it, however my concern is coverage on older releases.
>>>
>>> Can you check the kernel version on which you are running and do it
>>> runtime
>>> conditionally?
>>>
>> I have been avoiding adding kernel version checks to tests. Maybe this is
>> one exception since the functionality is obsoleted.
>
>
>
> I think the baseline is that we only assure kselftest  works on the release
> it belongs to, for example, removing this config for the
> version above 4.10, keep it in old release.  but looks it doesn't work like
> this way.
>
> I think We can't  assure latest kselftest works still well on a very older
> releases
> yes, for some features it's common for each release. but we have some
> features that are only available in newer
> release.   even for the common features, it's difficult to make sure it
> still works well for each
> release. maintenance is a big effort if we use something like version check.
> you never know what changes will make
> for general feature in the future release although it's common right now.

As Greg and several others have reiterated - the tests should be able
to check for presence of a feature, run it if it's applicable, and
skip if it's not. It really isn't about kernel version check, but
writing code and test in such a way that tests can 'degrade
gracefully', rather than fail. There are several good examples for the
same.

The idea of running newer tests is to gain coverage on older kernels
for features still present in them, but tests weren't available at the
time of the kernel tagging.

Hope this helps clear the doubt?
>
> Lei
>
>
>> In any case, just removing the config isn't the complete solution. I will
>> have to think about this some.
>>
>> thanks,
>> -- Shuah
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kselftest"
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
Best,
Sumit.

Re: [greybus-dev] [PATCH 2/2] staging: greybus/loopback: use ktime_get() for time intervals

[Viresh Kumar]

On 02-11-17, 15:32, Arnd Bergmann wrote:
> This driver is the only one using the deprecated timeval_to_ns()
> helper. Changing it from do_gettimeofday() to ktime_get() makes
> the code more efficient, more robust against concurrent
> settimeofday(), more accurate and lets us get rid of that helper
> in the future.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/staging/greybus/loopback.c | 42 
> --
>  1 file changed, 18 insertions(+), 24 deletions(-)

Reviewed-by: Viresh Kumar 

-- 
viresh

[PATCH net-next 4/6] net: hns3: add support for set_link_ksettings

[Lipeng]

From: Fuyun Liang 

This patch adds set_link_ksettings support for ethtool cmd.

Signed-off-by: Fuyun Liang 
Signed-off-by: Lipeng 
---
 drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c
index c7b8ebd..7fe193b 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c
@@ -653,6 +653,16 @@ static int hns3_get_link_ksettings(struct net_device 
*netdev,
return 0;
 }
 
+static int hns3_set_link_ksettings(struct net_device *netdev,
+  const struct ethtool_link_ksettings *cmd)
+{
+   /* Only support ksettings_set for netdev with phy attached for now */
+   if (netdev->phydev)
+   return phy_ethtool_ksettings_set(netdev->phydev, cmd);
+
+   return -EOPNOTSUPP;
+}
+
 static u32 hns3_get_rss_key_size(struct net_device *netdev)
 {
struct hnae3_handle *h = hns3_get_handle(netdev);
@@ -839,6 +849,7 @@ static int hns3_set_rxnfc(struct net_device *netdev, struct 
ethtool_rxnfc *cmd)
.get_rxfh = hns3_get_rss,
.set_rxfh = hns3_set_rss,
.get_link_ksettings = hns3_get_link_ksettings,
+   .set_link_ksettings = hns3_set_link_ksettings,
 };
 
 void hns3_ethtool_set_ops(struct net_device *netdev)
-- 
1.9.1

[PATCH net-next 4/6] net: hns3: add support for set_link_ksettings

[Lipeng]

From: Fuyun Liang 

This patch adds set_link_ksettings support for ethtool cmd.

Signed-off-by: Fuyun Liang 
Signed-off-by: Lipeng 
---
 drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c
index c7b8ebd..7fe193b 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c
@@ -653,6 +653,16 @@ static int hns3_get_link_ksettings(struct net_device 
*netdev,
return 0;
 }
 
+static int hns3_set_link_ksettings(struct net_device *netdev,
+  const struct ethtool_link_ksettings *cmd)
+{
+   /* Only support ksettings_set for netdev with phy attached for now */
+   if (netdev->phydev)
+   return phy_ethtool_ksettings_set(netdev->phydev, cmd);
+
+   return -EOPNOTSUPP;
+}
+
 static u32 hns3_get_rss_key_size(struct net_device *netdev)
 {
struct hnae3_handle *h = hns3_get_handle(netdev);
@@ -839,6 +849,7 @@ static int hns3_set_rxnfc(struct net_device *netdev, struct 
ethtool_rxnfc *cmd)
.get_rxfh = hns3_get_rss,
.set_rxfh = hns3_set_rss,
.get_link_ksettings = hns3_get_link_ksettings,
+   .set_link_ksettings = hns3_set_link_ksettings,
 };
 
 void hns3_ethtool_set_ops(struct net_device *netdev)
-- 
1.9.1

[PATCH net-next 3/6] net: hns3: fix a bug in hns3_driv_to_eth_caps

[Lipeng]

From: Fuyun Liang 

The value of link_modes.advertising and the value of link_modes.supported
is initialized to zero every time in for loop in hns3_driv_to_eth_caps().
But we just want to set specified bit for them. Initialization is
unnecessary. This patch fixes it.

Fixes: 496d03e (net: hns3: Add Ethtool support to HNS3 driver)
Signed-off-by: Fuyun Liang 
Signed-off-by: Lipeng 
---
 drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c
index 0e10a43..c7b8ebd 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c
@@ -359,17 +359,12 @@ static void hns3_driv_to_eth_caps(u32 caps, struct 
ethtool_link_ksettings *cmd,
if (!(caps & hns3_lm_map[i].hns3_link_mode))
continue;
 
-   if (is_advertised) {
-   ethtool_link_ksettings_zero_link_mode(cmd,
- advertising);
+   if (is_advertised)
__set_bit(hns3_lm_map[i].ethtool_link_mode,
  cmd->link_modes.advertising);
-   } else {
-   ethtool_link_ksettings_zero_link_mode(cmd,
- supported);
+   else
__set_bit(hns3_lm_map[i].ethtool_link_mode,
  cmd->link_modes.supported);
-   }
}
 }
 
-- 
1.9.1

[PATCH net-next 3/6] net: hns3: fix a bug in hns3_driv_to_eth_caps

[Lipeng]

From: Fuyun Liang 

The value of link_modes.advertising and the value of link_modes.supported
is initialized to zero every time in for loop in hns3_driv_to_eth_caps().
But we just want to set specified bit for them. Initialization is
unnecessary. This patch fixes it.

Fixes: 496d03e (net: hns3: Add Ethtool support to HNS3 driver)
Signed-off-by: Fuyun Liang 
Signed-off-by: Lipeng 
---
 drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c
index 0e10a43..c7b8ebd 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c
@@ -359,17 +359,12 @@ static void hns3_driv_to_eth_caps(u32 caps, struct 
ethtool_link_ksettings *cmd,
if (!(caps & hns3_lm_map[i].hns3_link_mode))
continue;
 
-   if (is_advertised) {
-   ethtool_link_ksettings_zero_link_mode(cmd,
- advertising);
+   if (is_advertised)
__set_bit(hns3_lm_map[i].ethtool_link_mode,
  cmd->link_modes.advertising);
-   } else {
-   ethtool_link_ksettings_zero_link_mode(cmd,
- supported);
+   else
__set_bit(hns3_lm_map[i].ethtool_link_mode,
  cmd->link_modes.supported);
-   }
}
 }
 
-- 
1.9.1

Re: [PATCH v2] f2fs: add bug_on when f2fs_gc even fails to get one victim

[Jaegeuk Kim]

On 10/13, Yunlong Song wrote:
> This can help us to debug on some corner case.
> 
> Signed-off-by: Yunlong Song 
> Signed-off-by: Chao Yu 
> ---
>  fs/f2fs/gc.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> index 197ebf4..2b03202 100644
> --- a/fs/f2fs/gc.c
> +++ b/fs/f2fs/gc.c
> @@ -986,6 +986,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
>   .ilist = LIST_HEAD_INIT(gc_list.ilist),
>   .iroot = RADIX_TREE_INIT(GFP_NOFS),
>   };
> + bool need_fggc = false;
>  
>   trace_f2fs_gc_begin(sbi->sb, sync, background,
>   get_pages(sbi, F2FS_DIRTY_NODES),
> @@ -1018,8 +1019,10 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
>   if (ret)
>   goto stop;
>   }
> - if (has_not_enough_free_secs(sbi, 0, 0))
> + if (has_not_enough_free_secs(sbi, 0, 0)) {
>   gc_type = FG_GC;
> + need_fggc = true;
> + }
>   }
>  
>   /* f2fs_balance_fs doesn't need to do BG_GC in critical path. */
> @@ -1028,6 +1031,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
>   goto stop;
>   }
>   if (!__get_victim(sbi, , gc_type)) {
> + f2fs_bug_on(sbi, !total_freed && need_fggc);

Just like this?

f2fs_bug_on(sbi, !total_freed && !sync && gc_type == FG_GC);

>   ret = -ENODATA;
>   goto stop;
>   }
> -- 
> 1.8.5.2

Re: [PATCH v2] f2fs: add bug_on when f2fs_gc even fails to get one victim

[Jaegeuk Kim]

On 10/13, Yunlong Song wrote:
> This can help us to debug on some corner case.
> 
> Signed-off-by: Yunlong Song 
> Signed-off-by: Chao Yu 
> ---
>  fs/f2fs/gc.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> index 197ebf4..2b03202 100644
> --- a/fs/f2fs/gc.c
> +++ b/fs/f2fs/gc.c
> @@ -986,6 +986,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
>   .ilist = LIST_HEAD_INIT(gc_list.ilist),
>   .iroot = RADIX_TREE_INIT(GFP_NOFS),
>   };
> + bool need_fggc = false;
>  
>   trace_f2fs_gc_begin(sbi->sb, sync, background,
>   get_pages(sbi, F2FS_DIRTY_NODES),
> @@ -1018,8 +1019,10 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
>   if (ret)
>   goto stop;
>   }
> - if (has_not_enough_free_secs(sbi, 0, 0))
> + if (has_not_enough_free_secs(sbi, 0, 0)) {
>   gc_type = FG_GC;
> + need_fggc = true;
> + }
>   }
>  
>   /* f2fs_balance_fs doesn't need to do BG_GC in critical path. */
> @@ -1028,6 +1031,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
>   goto stop;
>   }
>   if (!__get_victim(sbi, , gc_type)) {
> + f2fs_bug_on(sbi, !total_freed && need_fggc);

Just like this?

f2fs_bug_on(sbi, !total_freed && !sync && gc_type == FG_GC);

>   ret = -ENODATA;
>   goto stop;
>   }
> -- 
> 1.8.5.2

Re: [PATCH v4 2/2] watchdog: Add Spreadtrum watchdog driver

[Eric Long]

On Wed, Nov 01, 2017 at 01:46:36PM +, Guenter Roeck wrote:
> On 10/31/2017 01:16 AM, Eric Long wrote:
> > This patch adds the watchdog driver for Spreadtrum SC9860 platform.
> > 
> > Signed-off-by: Eric Long 
> > ---
> > Changes since v3:
> >   - Update Kconfig SPRD_WATCHDOG help messages.
> >   - Correct the wrong spell words.
> >   - Rename SPRD_WDT_CNT_HIGH_VALUE as SPRD_WDT_CNT_HIGH_SHIFT.
> >   - Remove unused macor.
> >   - Update sprd_wdt_set_pretimeout() api.
> >   - Add wdt->wdd.timeout default value.
> >   - Use devm_watchdog_register_device() to register wdt device.
> >   - If module does not support NOWAYOUT, disable wdt when remove this 
> > driver.
> >   - Call sprd_wdt_disable() every wdt suspend.
> > 
> > Changes since v2:
> >   - Rename all the macors, add SPRD tag at the head of the macro names.
> >   - Rename SPRD_WDT_CLK as SPRD_WTC_CNT_STEP.
> >   - Remove the code which check timeout value at the wrong place.
> >   - Add min/max timeout value limit.
> >   - Remove set WDOG_HW_RUNNING status at sprd_wdt_enable().
> >   - Add timeout/pretimeout judgment when set them.
> >   - Support WATCHDOG_NOWAYOUT status.
> > 
> > Changes since v1:
> >   - Use pretimeout instead of own implementation.
> >   - Fix timeout loop when loading timeout values.
> >   - use the infrastructure to read and set "timeout-sec" property.
> >   - Add conditions when start or stop watchdog.
> >   - Change the position of enabling watchdog.
> >   - Other optimization.
> > ---
> >   drivers/watchdog/Kconfig|   8 +
> >   drivers/watchdog/Makefile   |   1 +
> >   drivers/watchdog/sprd_wdt.c | 420 
> > 
> >   3 files changed, 429 insertions(+)
> >   create mode 100644 drivers/watchdog/sprd_wdt.c
> > 
> > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> > index c722cbf..3367a8c 100644
> > --- a/drivers/watchdog/Kconfig
> > +++ b/drivers/watchdog/Kconfig
> > @@ -787,6 +787,14 @@ config UNIPHIER_WATCHDOG
> >   To compile this driver as a module, choose M here: the
> >   module will be called uniphier_wdt.
> >   
> > +config SPRD_WATCHDOG
> > +   tristate "Spreadtrum watchdog support"
> > +   depends on ARCH_SPRD || COMPILE_TEST
> > +   select WATCHDOG_CORE
> > +   help
> > + Say Y here to include watchdog timer supported
> > + by Spreadtrum system.
> > +
> >   # AVR32 Architecture
> >   
> >   config AT32AP700X_WDT
> > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> > index 56adf9f..187cca2 100644
> > --- a/drivers/watchdog/Makefile
> > +++ b/drivers/watchdog/Makefile
> > @@ -87,6 +87,7 @@ obj-$(CONFIG_ASPEED_WATCHDOG) += aspeed_wdt.o
> >   obj-$(CONFIG_ZX2967_WATCHDOG) += zx2967_wdt.o
> >   obj-$(CONFIG_STM32_WATCHDOG) += stm32_iwdg.o
> >   obj-$(CONFIG_UNIPHIER_WATCHDOG) += uniphier_wdt.o
> > +obj-$(CONFIG_SPRD_WATCHDOG) += sprd_wdt.o
> >   
> >   # AVR32 Architecture
> >   obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
> > diff --git a/drivers/watchdog/sprd_wdt.c b/drivers/watchdog/sprd_wdt.c
> > new file mode 100644
> > index 000..f760a98
> > --- /dev/null
> > +++ b/drivers/watchdog/sprd_wdt.c
> > @@ -0,0 +1,420 @@
> > +/*
> > + * Spreadtrum watchdog driver
> > + * Copyright (C) 2017 Spreadtrum - http://www.spreadtrum.com
> > + *
> > + * 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.
> > + *
> > + * 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.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define SPRD_WDT_LOAD_LOW  0x0
> > +#define SPRD_WDT_LOAD_HIGH 0x4
> > +#define SPRD_WDT_CTRL  0x8
> > +#define SPRD_WDT_INT_CLR   0xc
> > +#define SPRD_WDT_INT_RAW   0x10
> > +#define SPRD_WDT_INT_MSK   0x14
> > +#define SPRD_WDT_CNT_LOW   0x18
> > +#define SPRD_WDT_CNT_HIGH  0x1c
> > +#define SPRD_WDT_LOCK  0x20
> > +#define SPRD_WDT_IRQ_LOAD_LOW  0x2c
> > +#define SPRD_WDT_IRQ_LOAD_HIGH 0x30
> > +
> > +/* WDT_CTRL */
> > +#define SPRD_WDT_INT_EN_BITBIT(0)
> > +#define SPRD_WDT_CNT_EN_BITBIT(1)
> > +#define SPRD_WDT_NEW_VER_ENBIT(2)
> > +#define SPRD_WDT_RST_EN_BITBIT(3)
> > +
> > +/* WDT_INT_CLR */
> > +#define SPRD_WDT_INT_CLEAR_BIT BIT(0)
> > +#define SPRD_WDT_RST_CLEAR_BIT BIT(3)
> > +
> > +/* WDT_INT_RAW */
> > +#define SPRD_WDT_INT_RAW_BIT   BIT(0)
> > +#define 

Re: [PATCH v4 2/2] watchdog: Add Spreadtrum watchdog driver

[Eric Long]

On Wed, Nov 01, 2017 at 01:46:36PM +, Guenter Roeck wrote:
> On 10/31/2017 01:16 AM, Eric Long wrote:
> > This patch adds the watchdog driver for Spreadtrum SC9860 platform.
> > 
> > Signed-off-by: Eric Long 
> > ---
> > Changes since v3:
> >   - Update Kconfig SPRD_WATCHDOG help messages.
> >   - Correct the wrong spell words.
> >   - Rename SPRD_WDT_CNT_HIGH_VALUE as SPRD_WDT_CNT_HIGH_SHIFT.
> >   - Remove unused macor.
> >   - Update sprd_wdt_set_pretimeout() api.
> >   - Add wdt->wdd.timeout default value.
> >   - Use devm_watchdog_register_device() to register wdt device.
> >   - If module does not support NOWAYOUT, disable wdt when remove this 
> > driver.
> >   - Call sprd_wdt_disable() every wdt suspend.
> > 
> > Changes since v2:
> >   - Rename all the macors, add SPRD tag at the head of the macro names.
> >   - Rename SPRD_WDT_CLK as SPRD_WTC_CNT_STEP.
> >   - Remove the code which check timeout value at the wrong place.
> >   - Add min/max timeout value limit.
> >   - Remove set WDOG_HW_RUNNING status at sprd_wdt_enable().
> >   - Add timeout/pretimeout judgment when set them.
> >   - Support WATCHDOG_NOWAYOUT status.
> > 
> > Changes since v1:
> >   - Use pretimeout instead of own implementation.
> >   - Fix timeout loop when loading timeout values.
> >   - use the infrastructure to read and set "timeout-sec" property.
> >   - Add conditions when start or stop watchdog.
> >   - Change the position of enabling watchdog.
> >   - Other optimization.
> > ---
> >   drivers/watchdog/Kconfig|   8 +
> >   drivers/watchdog/Makefile   |   1 +
> >   drivers/watchdog/sprd_wdt.c | 420 
> > 
> >   3 files changed, 429 insertions(+)
> >   create mode 100644 drivers/watchdog/sprd_wdt.c
> > 
> > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> > index c722cbf..3367a8c 100644
> > --- a/drivers/watchdog/Kconfig
> > +++ b/drivers/watchdog/Kconfig
> > @@ -787,6 +787,14 @@ config UNIPHIER_WATCHDOG
> >   To compile this driver as a module, choose M here: the
> >   module will be called uniphier_wdt.
> >   
> > +config SPRD_WATCHDOG
> > +   tristate "Spreadtrum watchdog support"
> > +   depends on ARCH_SPRD || COMPILE_TEST
> > +   select WATCHDOG_CORE
> > +   help
> > + Say Y here to include watchdog timer supported
> > + by Spreadtrum system.
> > +
> >   # AVR32 Architecture
> >   
> >   config AT32AP700X_WDT
> > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> > index 56adf9f..187cca2 100644
> > --- a/drivers/watchdog/Makefile
> > +++ b/drivers/watchdog/Makefile
> > @@ -87,6 +87,7 @@ obj-$(CONFIG_ASPEED_WATCHDOG) += aspeed_wdt.o
> >   obj-$(CONFIG_ZX2967_WATCHDOG) += zx2967_wdt.o
> >   obj-$(CONFIG_STM32_WATCHDOG) += stm32_iwdg.o
> >   obj-$(CONFIG_UNIPHIER_WATCHDOG) += uniphier_wdt.o
> > +obj-$(CONFIG_SPRD_WATCHDOG) += sprd_wdt.o
> >   
> >   # AVR32 Architecture
> >   obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
> > diff --git a/drivers/watchdog/sprd_wdt.c b/drivers/watchdog/sprd_wdt.c
> > new file mode 100644
> > index 000..f760a98
> > --- /dev/null
> > +++ b/drivers/watchdog/sprd_wdt.c
> > @@ -0,0 +1,420 @@
> > +/*
> > + * Spreadtrum watchdog driver
> > + * Copyright (C) 2017 Spreadtrum - http://www.spreadtrum.com
> > + *
> > + * 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.
> > + *
> > + * 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.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define SPRD_WDT_LOAD_LOW  0x0
> > +#define SPRD_WDT_LOAD_HIGH 0x4
> > +#define SPRD_WDT_CTRL  0x8
> > +#define SPRD_WDT_INT_CLR   0xc
> > +#define SPRD_WDT_INT_RAW   0x10
> > +#define SPRD_WDT_INT_MSK   0x14
> > +#define SPRD_WDT_CNT_LOW   0x18
> > +#define SPRD_WDT_CNT_HIGH  0x1c
> > +#define SPRD_WDT_LOCK  0x20
> > +#define SPRD_WDT_IRQ_LOAD_LOW  0x2c
> > +#define SPRD_WDT_IRQ_LOAD_HIGH 0x30
> > +
> > +/* WDT_CTRL */
> > +#define SPRD_WDT_INT_EN_BITBIT(0)
> > +#define SPRD_WDT_CNT_EN_BITBIT(1)
> > +#define SPRD_WDT_NEW_VER_ENBIT(2)
> > +#define SPRD_WDT_RST_EN_BITBIT(3)
> > +
> > +/* WDT_INT_CLR */
> > +#define SPRD_WDT_INT_CLEAR_BIT BIT(0)
> > +#define SPRD_WDT_RST_CLEAR_BIT BIT(3)
> > +
> > +/* WDT_INT_RAW */
> > +#define SPRD_WDT_INT_RAW_BIT   BIT(0)
> > +#define SPRD_WDT_RST_RAW_BIT   BIT(3)
> 

Re: [PATCH V2] of: platform: Create dummy routines for !CONFIG_OF_ADDRESS

[Viresh Kumar]

On 02-11-17, 07:40, Rob Herring wrote:
> No. As an example, ideally of_device_alloc would be an internal
> function. But we have one user in ibmebus.

Okay. Lets abandon this change then.

-- 
viresh

Re: [PATCH V2] of: platform: Create dummy routines for !CONFIG_OF_ADDRESS

[Viresh Kumar]

On 02-11-17, 07:40, Rob Herring wrote:
> No. As an example, ideally of_device_alloc would be an internal
> function. But we have one user in ibmebus.

Okay. Lets abandon this change then.

-- 
viresh

[PATCH net-next 5/6] net: hns3: add support for nway_reset

[Lipeng]

From: Fuyun Liang 

This patch adds nway_reset support for ethtool cmd.

Signed-off-by: Fuyun Liang 
Signed-off-by: Lipeng 
---
 .../net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c  | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c
index 7fe193b..a21470c 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c
@@ -832,6 +832,23 @@ static int hns3_set_rxnfc(struct net_device *netdev, 
struct ethtool_rxnfc *cmd)
}
 }
 
+static int hns3_nway_reset(struct net_device *netdev)
+{
+   struct phy_device *phy = netdev->phydev;
+
+   if (!netif_running(netdev))
+   return 0;
+
+   /* Only support nway_reset for netdev with phy attached for now */
+   if (!phy)
+   return -EOPNOTSUPP;
+
+   if (phy->autoneg != AUTONEG_ENABLE)
+   return -EINVAL;
+
+   return genphy_restart_aneg(phy);
+}
+
 static const struct ethtool_ops hns3_ethtool_ops = {
.self_test = hns3_self_test,
.get_drvinfo = hns3_get_drvinfo,
@@ -850,6 +867,7 @@ static int hns3_set_rxnfc(struct net_device *netdev, struct 
ethtool_rxnfc *cmd)
.set_rxfh = hns3_set_rss,
.get_link_ksettings = hns3_get_link_ksettings,
.set_link_ksettings = hns3_set_link_ksettings,
+   .nway_reset = hns3_nway_reset,
 };
 
 void hns3_ethtool_set_ops(struct net_device *netdev)
-- 
1.9.1

[PATCH net-next 5/6] net: hns3: add support for nway_reset

[Lipeng]

From: Fuyun Liang 

This patch adds nway_reset support for ethtool cmd.

Signed-off-by: Fuyun Liang 
Signed-off-by: Lipeng 
---
 .../net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c  | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c
index 7fe193b..a21470c 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c
@@ -832,6 +832,23 @@ static int hns3_set_rxnfc(struct net_device *netdev, 
struct ethtool_rxnfc *cmd)
}
 }
 
+static int hns3_nway_reset(struct net_device *netdev)
+{
+   struct phy_device *phy = netdev->phydev;
+
+   if (!netif_running(netdev))
+   return 0;
+
+   /* Only support nway_reset for netdev with phy attached for now */
+   if (!phy)
+   return -EOPNOTSUPP;
+
+   if (phy->autoneg != AUTONEG_ENABLE)
+   return -EINVAL;
+
+   return genphy_restart_aneg(phy);
+}
+
 static const struct ethtool_ops hns3_ethtool_ops = {
.self_test = hns3_self_test,
.get_drvinfo = hns3_get_drvinfo,
@@ -850,6 +867,7 @@ static int hns3_set_rxnfc(struct net_device *netdev, struct 
ethtool_rxnfc *cmd)
.set_rxfh = hns3_set_rss,
.get_link_ksettings = hns3_get_link_ksettings,
.set_link_ksettings = hns3_set_link_ksettings,
+   .nway_reset = hns3_nway_reset,
 };
 
 void hns3_ethtool_set_ops(struct net_device *netdev)
-- 
1.9.1

Re: [PATCH v2] cpufreq: schedutil: Examine the correct CPU when we update util

[Viresh Kumar]

On 02-11-17, 12:06, Chris Redpath wrote:
> According to my diff, this was the commit which switched from assigning
> the values directly (and not overwriting the cpu member, which was
> introduced in the other commit you reference) to using a memset and
> clearing the whole struct.

I understand what you want to convey here but the log says something
else according to me. It says:

"Since: 4296f23ed cpufreq: schedutil: Fix per-CPU structure
initialization in sugov_start(), We lost the value of sg_cpu->cpu
which is assigned during sugov_register."

Reading this line it looks like sg_cpu->cpu was screwed up by
4296f23ed, which happened in 4.9. But the sg_cpu->cpu field itself got
added in 4.14 and so I think we should write it differently.

If I were you, I wouldn't mention 4296f23ed here at all but just say
that memset() is clearing the value of sg_cpu->cpu, fix that.

Thanks.

-- 
viresh

Re: [PATCH v2] cpufreq: schedutil: Examine the correct CPU when we update util

[Viresh Kumar]

On 02-11-17, 12:06, Chris Redpath wrote:
> According to my diff, this was the commit which switched from assigning
> the values directly (and not overwriting the cpu member, which was
> introduced in the other commit you reference) to using a memset and
> clearing the whole struct.

I understand what you want to convey here but the log says something
else according to me. It says:

"Since: 4296f23ed cpufreq: schedutil: Fix per-CPU structure
initialization in sugov_start(), We lost the value of sg_cpu->cpu
which is assigned during sugov_register."

Reading this line it looks like sg_cpu->cpu was screwed up by
4296f23ed, which happened in 4.9. But the sg_cpu->cpu field itself got
added in 4.14 and so I think we should write it differently.

If I were you, I wouldn't mention 4296f23ed here at all but just say
that memset() is clearing the value of sg_cpu->cpu, fix that.

Thanks.

-- 
viresh