Re: RFC: Revert move default dialect from CIFS to to SMB3

2017-09-01 Thread Andrew Bartlett
On Fri, 2017-09-01 at 20:56 -0700, Linus Torvalds wrote:
> On Fri, Sep 1, 2017 at 7:16 PM, Steve French  wrote:
> > 
> > The default was SMB1 (CIFS) and was recently changed to SMB3.
> > The dialect still can be overridden by specifying "vers=1.0" or "vers=2.1"
> > etc. on mount.
> > 
> > We just put together a patch to better explain the default changes
> > (with additional warning messages) as suggested.
> > 
> > SMB3 is significantly better than SMB2.1 (supporting encrypted shares
> > and sessions for example, and requiring support for "secure negotiate")
> > and some servers require SMB3 minimum as a result,
> 
> The default shouldn't be about "best and most secure", but "most
> convenient, while still not actively *IN*secure"
> 
> So "some servers require 3.0" may be true, but if it's also the case
> that "most servers still don't do 3.0 at all", then it's a "some" vs
> "most".
> 
> Which is the most common one? That should be the default.
> 
> I realize that eventually we'll have auto-negotiation, but that's
> clearly not for 4.13. So in the meantime the only issue is what the
> right default should be without auto-negotiation.
> 
> So it should be about what the failure rate is. If trying for smb3 has
> a high failure rate because people simply don't have that yet, then
> making that the default was clearly the wrong choice.
> 
> Because being "better" is immaterial if it doesn't work.

My quick research shows:

SMB 2.1 but not SMB3 is on:
 Windows 7
 Windows 8
 Windows 2008
 Windows 2012
 Samba 3.6 and earlier (SMB1 only by default)

SMB3 is on:
 Windows 8.1
 Windows 2012 R2
 Windows 10
 Windows 2016 
 Samba 4.0 and above (released 2012)

I'm not sure exactly which Mac versions.  

Some breakage will be old (and quite recent) NAS and routers that use
SMB1 and often very old Samba, but most of those only do SMB1. 

In terms of 'actively *IN*secure', it really depends what you mean by
that.  

That is, like all big changes, the movement against SMB1 has had
multiple motivations:
 - a desire no longer to expose really old code in Windows (recently
exploited)
 - a desire to retire an old and complex protocol
 - SMB3 having proper secure negotiation (I'll leave it to Steve to
explain the difference between SMB2 and 3 in that respect, I'm not so
current on the details). 

I hope this help,

Andrew Bartlett

-- 
Andrew Bartlett   http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT  http://catalyst.net.nz/services/samba



Re: RFC: Revert move default dialect from CIFS to to SMB3

2017-09-01 Thread Andrew Bartlett
On Fri, 2017-09-01 at 20:56 -0700, Linus Torvalds wrote:
> On Fri, Sep 1, 2017 at 7:16 PM, Steve French  wrote:
> > 
> > The default was SMB1 (CIFS) and was recently changed to SMB3.
> > The dialect still can be overridden by specifying "vers=1.0" or "vers=2.1"
> > etc. on mount.
> > 
> > We just put together a patch to better explain the default changes
> > (with additional warning messages) as suggested.
> > 
> > SMB3 is significantly better than SMB2.1 (supporting encrypted shares
> > and sessions for example, and requiring support for "secure negotiate")
> > and some servers require SMB3 minimum as a result,
> 
> The default shouldn't be about "best and most secure", but "most
> convenient, while still not actively *IN*secure"
> 
> So "some servers require 3.0" may be true, but if it's also the case
> that "most servers still don't do 3.0 at all", then it's a "some" vs
> "most".
> 
> Which is the most common one? That should be the default.
> 
> I realize that eventually we'll have auto-negotiation, but that's
> clearly not for 4.13. So in the meantime the only issue is what the
> right default should be without auto-negotiation.
> 
> So it should be about what the failure rate is. If trying for smb3 has
> a high failure rate because people simply don't have that yet, then
> making that the default was clearly the wrong choice.
> 
> Because being "better" is immaterial if it doesn't work.

My quick research shows:

SMB 2.1 but not SMB3 is on:
 Windows 7
 Windows 8
 Windows 2008
 Windows 2012
 Samba 3.6 and earlier (SMB1 only by default)

SMB3 is on:
 Windows 8.1
 Windows 2012 R2
 Windows 10
 Windows 2016 
 Samba 4.0 and above (released 2012)

I'm not sure exactly which Mac versions.  

Some breakage will be old (and quite recent) NAS and routers that use
SMB1 and often very old Samba, but most of those only do SMB1. 

In terms of 'actively *IN*secure', it really depends what you mean by
that.  

That is, like all big changes, the movement against SMB1 has had
multiple motivations:
 - a desire no longer to expose really old code in Windows (recently
exploited)
 - a desire to retire an old and complex protocol
 - SMB3 having proper secure negotiation (I'll leave it to Steve to
explain the difference between SMB2 and 3 in that respect, I'm not so
current on the details). 

I hope this help,

Andrew Bartlett

-- 
Andrew Bartlett   http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT  http://catalyst.net.nz/services/samba



Linux 4.9.47

2017-09-01 Thread Greg KH
I'm announcing the release of the 4.9.47 kernel.

All users of the 4.9 kernel series must upgrade.

The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile |2 
 arch/arm/kvm/mmu.c   |   16 ++---
 arch/arm64/kernel/fpsimd.c   |2 
 arch/arm64/mm/fault.c|5 +
 arch/x86/include/asm/io.h|4 -
 drivers/net/wireless/intersil/p54/fwio.c |2 
 drivers/scsi/isci/remote_node_context.c  |3 +
 drivers/scsi/sg.c|   49 ++---
 drivers/staging/wilc1000/linux_wlan.c|   34 +++-
 kernel/gcov/base.c   |6 ++
 kernel/gcov/gcc_4_7.c|4 +
 kernel/locking/spinlock_debug.c  |   86 +--
 lib/lz4/lz4hc_compress.c |2 
 13 files changed, 73 insertions(+), 142 deletions(-)

Arnd Bergmann (3):
  scsi: isci: avoid array subscript warning
  staging: wilc1000: simplify vif[i]->ndev accesses
  x86/io: Add "memory" clobber to insb/insw/insl/outsb/outsw/outsl

Dave Martin (1):
  arm64: fpsimd: Prevent registers leaking across exec

Greg Kroah-Hartman (2):
  lz4: fix bogus gcc warning
  Linux 4.9.47

Hannes Reinecke (2):
  scsi: sg: protect accesses to 'reserved' page array
  scsi: sg: reset 'res_in_use' after unlinking reserved array

Jiri Slaby (1):
  p54: memset(0) whole array

Mark Rutland (1):
  arm64: mm: abort uaccess retries upon fatal signal

Martin Liska (1):
  gcov: support GCC 7.1

Suzuki K Poulose (1):
  kvm: arm/arm64: Fix race in resetting stage2 PGD

Waiman Long (1):
  locking/spinlock/debug: Remove spinlock lockup detection code



signature.asc
Description: PGP signature


Linux 4.9.47

2017-09-01 Thread Greg KH
I'm announcing the release of the 4.9.47 kernel.

All users of the 4.9 kernel series must upgrade.

The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile |2 
 arch/arm/kvm/mmu.c   |   16 ++---
 arch/arm64/kernel/fpsimd.c   |2 
 arch/arm64/mm/fault.c|5 +
 arch/x86/include/asm/io.h|4 -
 drivers/net/wireless/intersil/p54/fwio.c |2 
 drivers/scsi/isci/remote_node_context.c  |3 +
 drivers/scsi/sg.c|   49 ++---
 drivers/staging/wilc1000/linux_wlan.c|   34 +++-
 kernel/gcov/base.c   |6 ++
 kernel/gcov/gcc_4_7.c|4 +
 kernel/locking/spinlock_debug.c  |   86 +--
 lib/lz4/lz4hc_compress.c |2 
 13 files changed, 73 insertions(+), 142 deletions(-)

Arnd Bergmann (3):
  scsi: isci: avoid array subscript warning
  staging: wilc1000: simplify vif[i]->ndev accesses
  x86/io: Add "memory" clobber to insb/insw/insl/outsb/outsw/outsl

Dave Martin (1):
  arm64: fpsimd: Prevent registers leaking across exec

Greg Kroah-Hartman (2):
  lz4: fix bogus gcc warning
  Linux 4.9.47

Hannes Reinecke (2):
  scsi: sg: protect accesses to 'reserved' page array
  scsi: sg: reset 'res_in_use' after unlinking reserved array

Jiri Slaby (1):
  p54: memset(0) whole array

Mark Rutland (1):
  arm64: mm: abort uaccess retries upon fatal signal

Martin Liska (1):
  gcov: support GCC 7.1

Suzuki K Poulose (1):
  kvm: arm/arm64: Fix race in resetting stage2 PGD

Waiman Long (1):
  locking/spinlock/debug: Remove spinlock lockup detection code



signature.asc
Description: PGP signature


Re: Linux 4.9.47

2017-09-01 Thread Greg KH
diff --git a/Makefile b/Makefile
index 846ef1b57a02..a0abbfc15a49 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 9
-SUBLEVEL = 46
+SUBLEVEL = 47
 EXTRAVERSION =
 NAME = Roaring Lionus
 
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 710511cadd50..0c060c5e844a 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -829,22 +829,22 @@ void stage2_unmap_vm(struct kvm *kvm)
  * Walks the level-1 page table pointed to by kvm->arch.pgd and frees all
  * underlying level-2 and level-3 tables before freeing the actual level-1 
table
  * and setting the struct pointer to NULL.
- *
- * Note we don't need locking here as this is only called when the VM is
- * destroyed, which can only be done once.
  */
 void kvm_free_stage2_pgd(struct kvm *kvm)
 {
-   if (kvm->arch.pgd == NULL)
-   return;
+   void *pgd = NULL;
 
spin_lock(>mmu_lock);
-   unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
+   if (kvm->arch.pgd) {
+   unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
+   pgd = kvm->arch.pgd;
+   kvm->arch.pgd = NULL;
+   }
spin_unlock(>mmu_lock);
 
/* Free the HW pgd, one page at a time */
-   free_pages_exact(kvm->arch.pgd, S2_PGD_SIZE);
-   kvm->arch.pgd = NULL;
+   if (pgd)
+   free_pages_exact(pgd, S2_PGD_SIZE);
 }
 
 static pud_t *stage2_get_pud(struct kvm *kvm, struct kvm_mmu_memory_cache 
*cache,
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 394c61db5566..1d5890f19ca3 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -157,9 +157,11 @@ void fpsimd_thread_switch(struct task_struct *next)
 
 void fpsimd_flush_thread(void)
 {
+   preempt_disable();
memset(>thread.fpsimd_state, 0, sizeof(struct fpsimd_state));
fpsimd_flush_task_state(current);
set_thread_flag(TIF_FOREIGN_FPSTATE);
+   preempt_enable();
 }
 
 /*
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 0e90c7e0279c..fec5b1ce97f8 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -373,8 +373,11 @@ static int __kprobes do_page_fault(unsigned long addr, 
unsigned int esr,
 * signal first. We do not need to release the mmap_sem because it
 * would already be released in __lock_page_or_retry in mm/filemap.c.
 */
-   if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+   if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) {
+   if (!user_mode(regs))
+   goto no_context;
return 0;
+   }
 
/*
 * Major/minor page fault accounting is only done on the initial
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index d34bd370074b..6c5020163db0 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -304,13 +304,13 @@ static inline unsigned type in##bwl##_p(int port) 
\
 static inline void outs##bwl(int port, const void *addr, unsigned long count) \
 {  \
asm volatile("rep; outs" #bwl   \
-: "+S"(addr), "+c"(count) : "d"(port));\
+: "+S"(addr), "+c"(count) : "d"(port) : "memory"); \
 }  \
\
 static inline void ins##bwl(int port, void *addr, unsigned long count) \
 {  \
asm volatile("rep; ins" #bwl\
-: "+D"(addr), "+c"(count) : "d"(port));\
+: "+D"(addr), "+c"(count) : "d"(port) : "memory"); \
 }
 
 BUILDIO(b, b, char)
diff --git a/drivers/net/wireless/intersil/p54/fwio.c 
b/drivers/net/wireless/intersil/p54/fwio.c
index 257a9eadd595..4ac6764f4897 100644
--- a/drivers/net/wireless/intersil/p54/fwio.c
+++ b/drivers/net/wireless/intersil/p54/fwio.c
@@ -488,7 +488,7 @@ int p54_scan(struct p54_common *priv, u16 mode, u16 dwell)
 
entry += sizeof(__le16);
chan->pa_points_per_curve = 8;
-   memset(chan->curve_data, 0, sizeof(*chan->curve_data));
+   memset(chan->curve_data, 0, sizeof(chan->curve_data));
memcpy(chan->curve_data, entry,
   sizeof(struct p54_pa_curve_data_sample) *
   min((u8)8, curve_data->points_per_channel));
diff --git a/drivers/scsi/isci/remote_node_context.c 
b/drivers/scsi/isci/remote_node_context.c
index 1910100638a2..00602abec0ea 100644
--- a/drivers/scsi/isci/remote_node_context.c
+++ b/drivers/scsi/isci/remote_node_context.c
@@ -66,6 +66,9 @@ const char *rnc_state_name(enum 

Re: Linux 4.9.47

2017-09-01 Thread Greg KH
diff --git a/Makefile b/Makefile
index 846ef1b57a02..a0abbfc15a49 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 9
-SUBLEVEL = 46
+SUBLEVEL = 47
 EXTRAVERSION =
 NAME = Roaring Lionus
 
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 710511cadd50..0c060c5e844a 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -829,22 +829,22 @@ void stage2_unmap_vm(struct kvm *kvm)
  * Walks the level-1 page table pointed to by kvm->arch.pgd and frees all
  * underlying level-2 and level-3 tables before freeing the actual level-1 
table
  * and setting the struct pointer to NULL.
- *
- * Note we don't need locking here as this is only called when the VM is
- * destroyed, which can only be done once.
  */
 void kvm_free_stage2_pgd(struct kvm *kvm)
 {
-   if (kvm->arch.pgd == NULL)
-   return;
+   void *pgd = NULL;
 
spin_lock(>mmu_lock);
-   unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
+   if (kvm->arch.pgd) {
+   unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
+   pgd = kvm->arch.pgd;
+   kvm->arch.pgd = NULL;
+   }
spin_unlock(>mmu_lock);
 
/* Free the HW pgd, one page at a time */
-   free_pages_exact(kvm->arch.pgd, S2_PGD_SIZE);
-   kvm->arch.pgd = NULL;
+   if (pgd)
+   free_pages_exact(pgd, S2_PGD_SIZE);
 }
 
 static pud_t *stage2_get_pud(struct kvm *kvm, struct kvm_mmu_memory_cache 
*cache,
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 394c61db5566..1d5890f19ca3 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -157,9 +157,11 @@ void fpsimd_thread_switch(struct task_struct *next)
 
 void fpsimd_flush_thread(void)
 {
+   preempt_disable();
memset(>thread.fpsimd_state, 0, sizeof(struct fpsimd_state));
fpsimd_flush_task_state(current);
set_thread_flag(TIF_FOREIGN_FPSTATE);
+   preempt_enable();
 }
 
 /*
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 0e90c7e0279c..fec5b1ce97f8 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -373,8 +373,11 @@ static int __kprobes do_page_fault(unsigned long addr, 
unsigned int esr,
 * signal first. We do not need to release the mmap_sem because it
 * would already be released in __lock_page_or_retry in mm/filemap.c.
 */
-   if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+   if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) {
+   if (!user_mode(regs))
+   goto no_context;
return 0;
+   }
 
/*
 * Major/minor page fault accounting is only done on the initial
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index d34bd370074b..6c5020163db0 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -304,13 +304,13 @@ static inline unsigned type in##bwl##_p(int port) 
\
 static inline void outs##bwl(int port, const void *addr, unsigned long count) \
 {  \
asm volatile("rep; outs" #bwl   \
-: "+S"(addr), "+c"(count) : "d"(port));\
+: "+S"(addr), "+c"(count) : "d"(port) : "memory"); \
 }  \
\
 static inline void ins##bwl(int port, void *addr, unsigned long count) \
 {  \
asm volatile("rep; ins" #bwl\
-: "+D"(addr), "+c"(count) : "d"(port));\
+: "+D"(addr), "+c"(count) : "d"(port) : "memory"); \
 }
 
 BUILDIO(b, b, char)
diff --git a/drivers/net/wireless/intersil/p54/fwio.c 
b/drivers/net/wireless/intersil/p54/fwio.c
index 257a9eadd595..4ac6764f4897 100644
--- a/drivers/net/wireless/intersil/p54/fwio.c
+++ b/drivers/net/wireless/intersil/p54/fwio.c
@@ -488,7 +488,7 @@ int p54_scan(struct p54_common *priv, u16 mode, u16 dwell)
 
entry += sizeof(__le16);
chan->pa_points_per_curve = 8;
-   memset(chan->curve_data, 0, sizeof(*chan->curve_data));
+   memset(chan->curve_data, 0, sizeof(chan->curve_data));
memcpy(chan->curve_data, entry,
   sizeof(struct p54_pa_curve_data_sample) *
   min((u8)8, curve_data->points_per_channel));
diff --git a/drivers/scsi/isci/remote_node_context.c 
b/drivers/scsi/isci/remote_node_context.c
index 1910100638a2..00602abec0ea 100644
--- a/drivers/scsi/isci/remote_node_context.c
+++ b/drivers/scsi/isci/remote_node_context.c
@@ -66,6 +66,9 @@ const char *rnc_state_name(enum 

Re: Linux 4.4.86

2017-09-01 Thread Greg KH
diff --git a/Makefile b/Makefile
index 0f3d843f42a7..1207bf6a0e7a 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 4
-SUBLEVEL = 85
+SUBLEVEL = 86
 EXTRAVERSION =
 NAME = Blurry Fish Butt
 
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 4c46c54a3ad7..6638903f0cb9 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -157,9 +157,11 @@ void fpsimd_thread_switch(struct task_struct *next)
 
 void fpsimd_flush_thread(void)
 {
+   preempt_disable();
memset(>thread.fpsimd_state, 0, sizeof(struct fpsimd_state));
fpsimd_flush_task_state(current);
set_thread_flag(TIF_FOREIGN_FPSTATE);
+   preempt_enable();
 }
 
 /*
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index a4b466424a32..7fabf49f2aeb 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -313,8 +313,11 @@ retry:
 * signal first. We do not need to release the mmap_sem because it
 * would already be released in __lock_page_or_retry in mm/filemap.c.
 */
-   if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+   if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) {
+   if (!user_mode(regs))
+   goto no_context;
return 0;
+   }
 
/*
 * Major/minor page fault accounting is only done on the initial
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index de25aad07853..9016b4b70375 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -304,13 +304,13 @@ static inline unsigned type in##bwl##_p(int port) 
\
 static inline void outs##bwl(int port, const void *addr, unsigned long count) \
 {  \
asm volatile("rep; outs" #bwl   \
-: "+S"(addr), "+c"(count) : "d"(port));\
+: "+S"(addr), "+c"(count) : "d"(port) : "memory"); \
 }  \
\
 static inline void ins##bwl(int port, void *addr, unsigned long count) \
 {  \
asm volatile("rep; ins" #bwl\
-: "+D"(addr), "+c"(count) : "d"(port));\
+: "+D"(addr), "+c"(count) : "d"(port) : "memory"); \
 }
 
 BUILDIO(b, b, char)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index cc91ae832ffb..6fd7b50c5747 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -635,7 +635,8 @@ hsw_unclaimed_reg_detect(struct drm_i915_private *dev_priv)
  "enabling oneshot unclaimed register reporting. "
  "Please use i915.mmio_debug=N for more 
information.\n");
__raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
-   i915.mmio_debug = mmio_debug_once--;
+   i915.mmio_debug = mmio_debug_once;
+   mmio_debug_once = false;
}
 }
 
diff --git a/drivers/i2c/busses/i2c-jz4780.c b/drivers/i2c/busses/i2c-jz4780.c
index f325663c27c5..4b58e8aaf5c5 100644
--- a/drivers/i2c/busses/i2c-jz4780.c
+++ b/drivers/i2c/busses/i2c-jz4780.c
@@ -786,10 +786,6 @@ static int jz4780_i2c_probe(struct platform_device *pdev)
 
jz4780_i2c_writew(i2c, JZ4780_I2C_INTM, 0x0);
 
-   i2c->cmd = 0;
-   memset(i2c->cmd_buf, 0, BUFSIZE);
-   memset(i2c->data_buf, 0, BUFSIZE);
-
i2c->irq = platform_get_irq(pdev, 0);
ret = devm_request_irq(>dev, i2c->irq, jz4780_i2c_irq, 0,
   dev_name(>dev), i2c);
diff --git a/drivers/net/wireless/p54/fwio.c b/drivers/net/wireless/p54/fwio.c
index 257a9eadd595..4ac6764f4897 100644
--- a/drivers/net/wireless/p54/fwio.c
+++ b/drivers/net/wireless/p54/fwio.c
@@ -488,7 +488,7 @@ int p54_scan(struct p54_common *priv, u16 mode, u16 dwell)
 
entry += sizeof(__le16);
chan->pa_points_per_curve = 8;
-   memset(chan->curve_data, 0, sizeof(*chan->curve_data));
+   memset(chan->curve_data, 0, sizeof(chan->curve_data));
memcpy(chan->curve_data, entry,
   sizeof(struct p54_pa_curve_data_sample) *
   min((u8)8, curve_data->points_per_channel));
diff --git a/drivers/scsi/isci/remote_node_context.c 
b/drivers/scsi/isci/remote_node_context.c
index 1910100638a2..00602abec0ea 100644
--- a/drivers/scsi/isci/remote_node_context.c
+++ b/drivers/scsi/isci/remote_node_context.c
@@ -66,6 +66,9 @@ const char *rnc_state_name(enum 
scis_sds_remote_node_context_states state)
 {
static const char * 

Linux 4.4.86

2017-09-01 Thread Greg KH
I'm announcing the release of the 4.4.86 kernel.

All users of the 4.4 kernel series must upgrade.

The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile|2 -
 arch/arm64/kernel/fpsimd.c  |2 +
 arch/arm64/mm/fault.c   |5 ++-
 arch/x86/include/asm/io.h   |4 +-
 drivers/gpu/drm/i915/intel_uncore.c |3 +
 drivers/i2c/busses/i2c-jz4780.c |4 --
 drivers/net/wireless/p54/fwio.c |2 -
 drivers/scsi/isci/remote_node_context.c |3 +
 drivers/scsi/lpfc/lpfc_els.c|5 ++-
 drivers/scsi/sg.c   |   49 ++--
 fs/btrfs/volumes.c  |2 -
 include/linux/lightnvm.h|1 
 kernel/gcov/base.c  |6 +++
 kernel/gcov/gcc_4_7.c   |4 +-
 sound/pci/au88x0/au88x0_core.c  |   14 +++--
 15 files changed, 63 insertions(+), 43 deletions(-)

Arnd Bergmann (2):
  scsi: isci: avoid array subscript warning
  x86/io: Add "memory" clobber to insb/insw/insl/outsb/outsw/outsl

Colin Ian King (1):
  btrfs: remove duplicate const specifier

Dave Martin (1):
  arm64: fpsimd: Prevent registers leaking across exec

Florian Meier (1):
  gcov: add support for gcc version >= 6

Greg Kroah-Hartman (2):
  drm/i915: fix compiler warning in drivers/gpu/drm/i915/intel_uncore.c
  Linux 4.4.86

Hannes Reinecke (2):
  scsi: sg: protect accesses to 'reserved' page array
  scsi: sg: reset 'res_in_use' after unlinking reserved array

James Smart (1):
  lpfc: Fix Device discovery failures during switch reboot test.

Javier González (1):
  lightnvm: initialize ppa_addr in dev_to_generic_addr()

Jiri Slaby (1):
  p54: memset(0) whole array

Mark Rutland (1):
  arm64: mm: abort uaccess retries upon fatal signal

Martin Liska (1):
  gcov: support GCC 7.1

Takashi Iwai (1):
  ALSA: au88x0: Fix zero clear of stream->resources

Wolfram Sang (1):
  i2c: jz4780: drop superfluous init



signature.asc
Description: PGP signature


Re: Linux 4.4.86

2017-09-01 Thread Greg KH
diff --git a/Makefile b/Makefile
index 0f3d843f42a7..1207bf6a0e7a 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 4
-SUBLEVEL = 85
+SUBLEVEL = 86
 EXTRAVERSION =
 NAME = Blurry Fish Butt
 
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 4c46c54a3ad7..6638903f0cb9 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -157,9 +157,11 @@ void fpsimd_thread_switch(struct task_struct *next)
 
 void fpsimd_flush_thread(void)
 {
+   preempt_disable();
memset(>thread.fpsimd_state, 0, sizeof(struct fpsimd_state));
fpsimd_flush_task_state(current);
set_thread_flag(TIF_FOREIGN_FPSTATE);
+   preempt_enable();
 }
 
 /*
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index a4b466424a32..7fabf49f2aeb 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -313,8 +313,11 @@ retry:
 * signal first. We do not need to release the mmap_sem because it
 * would already be released in __lock_page_or_retry in mm/filemap.c.
 */
-   if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+   if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) {
+   if (!user_mode(regs))
+   goto no_context;
return 0;
+   }
 
/*
 * Major/minor page fault accounting is only done on the initial
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index de25aad07853..9016b4b70375 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -304,13 +304,13 @@ static inline unsigned type in##bwl##_p(int port) 
\
 static inline void outs##bwl(int port, const void *addr, unsigned long count) \
 {  \
asm volatile("rep; outs" #bwl   \
-: "+S"(addr), "+c"(count) : "d"(port));\
+: "+S"(addr), "+c"(count) : "d"(port) : "memory"); \
 }  \
\
 static inline void ins##bwl(int port, void *addr, unsigned long count) \
 {  \
asm volatile("rep; ins" #bwl\
-: "+D"(addr), "+c"(count) : "d"(port));\
+: "+D"(addr), "+c"(count) : "d"(port) : "memory"); \
 }
 
 BUILDIO(b, b, char)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index cc91ae832ffb..6fd7b50c5747 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -635,7 +635,8 @@ hsw_unclaimed_reg_detect(struct drm_i915_private *dev_priv)
  "enabling oneshot unclaimed register reporting. "
  "Please use i915.mmio_debug=N for more 
information.\n");
__raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
-   i915.mmio_debug = mmio_debug_once--;
+   i915.mmio_debug = mmio_debug_once;
+   mmio_debug_once = false;
}
 }
 
diff --git a/drivers/i2c/busses/i2c-jz4780.c b/drivers/i2c/busses/i2c-jz4780.c
index f325663c27c5..4b58e8aaf5c5 100644
--- a/drivers/i2c/busses/i2c-jz4780.c
+++ b/drivers/i2c/busses/i2c-jz4780.c
@@ -786,10 +786,6 @@ static int jz4780_i2c_probe(struct platform_device *pdev)
 
jz4780_i2c_writew(i2c, JZ4780_I2C_INTM, 0x0);
 
-   i2c->cmd = 0;
-   memset(i2c->cmd_buf, 0, BUFSIZE);
-   memset(i2c->data_buf, 0, BUFSIZE);
-
i2c->irq = platform_get_irq(pdev, 0);
ret = devm_request_irq(>dev, i2c->irq, jz4780_i2c_irq, 0,
   dev_name(>dev), i2c);
diff --git a/drivers/net/wireless/p54/fwio.c b/drivers/net/wireless/p54/fwio.c
index 257a9eadd595..4ac6764f4897 100644
--- a/drivers/net/wireless/p54/fwio.c
+++ b/drivers/net/wireless/p54/fwio.c
@@ -488,7 +488,7 @@ int p54_scan(struct p54_common *priv, u16 mode, u16 dwell)
 
entry += sizeof(__le16);
chan->pa_points_per_curve = 8;
-   memset(chan->curve_data, 0, sizeof(*chan->curve_data));
+   memset(chan->curve_data, 0, sizeof(chan->curve_data));
memcpy(chan->curve_data, entry,
   sizeof(struct p54_pa_curve_data_sample) *
   min((u8)8, curve_data->points_per_channel));
diff --git a/drivers/scsi/isci/remote_node_context.c 
b/drivers/scsi/isci/remote_node_context.c
index 1910100638a2..00602abec0ea 100644
--- a/drivers/scsi/isci/remote_node_context.c
+++ b/drivers/scsi/isci/remote_node_context.c
@@ -66,6 +66,9 @@ const char *rnc_state_name(enum 
scis_sds_remote_node_context_states state)
 {
static const char * 

Linux 4.4.86

2017-09-01 Thread Greg KH
I'm announcing the release of the 4.4.86 kernel.

All users of the 4.4 kernel series must upgrade.

The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile|2 -
 arch/arm64/kernel/fpsimd.c  |2 +
 arch/arm64/mm/fault.c   |5 ++-
 arch/x86/include/asm/io.h   |4 +-
 drivers/gpu/drm/i915/intel_uncore.c |3 +
 drivers/i2c/busses/i2c-jz4780.c |4 --
 drivers/net/wireless/p54/fwio.c |2 -
 drivers/scsi/isci/remote_node_context.c |3 +
 drivers/scsi/lpfc/lpfc_els.c|5 ++-
 drivers/scsi/sg.c   |   49 ++--
 fs/btrfs/volumes.c  |2 -
 include/linux/lightnvm.h|1 
 kernel/gcov/base.c  |6 +++
 kernel/gcov/gcc_4_7.c   |4 +-
 sound/pci/au88x0/au88x0_core.c  |   14 +++--
 15 files changed, 63 insertions(+), 43 deletions(-)

Arnd Bergmann (2):
  scsi: isci: avoid array subscript warning
  x86/io: Add "memory" clobber to insb/insw/insl/outsb/outsw/outsl

Colin Ian King (1):
  btrfs: remove duplicate const specifier

Dave Martin (1):
  arm64: fpsimd: Prevent registers leaking across exec

Florian Meier (1):
  gcov: add support for gcc version >= 6

Greg Kroah-Hartman (2):
  drm/i915: fix compiler warning in drivers/gpu/drm/i915/intel_uncore.c
  Linux 4.4.86

Hannes Reinecke (2):
  scsi: sg: protect accesses to 'reserved' page array
  scsi: sg: reset 'res_in_use' after unlinking reserved array

James Smart (1):
  lpfc: Fix Device discovery failures during switch reboot test.

Javier González (1):
  lightnvm: initialize ppa_addr in dev_to_generic_addr()

Jiri Slaby (1):
  p54: memset(0) whole array

Mark Rutland (1):
  arm64: mm: abort uaccess retries upon fatal signal

Martin Liska (1):
  gcov: support GCC 7.1

Takashi Iwai (1):
  ALSA: au88x0: Fix zero clear of stream->resources

Wolfram Sang (1):
  i2c: jz4780: drop superfluous init



signature.asc
Description: PGP signature


Re: Linux 3.18.69

2017-09-01 Thread Greg KH
diff --git a/Makefile b/Makefile
index 0d7f1e91e910..49237a0442cd 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 18
-SUBLEVEL = 68
+SUBLEVEL = 69
 EXTRAVERSION =
 NAME = Diseased Newt
 
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 3dca15634e69..7b4e9ea0b1a4 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -156,8 +156,11 @@ void fpsimd_thread_switch(struct task_struct *next)
 
 void fpsimd_flush_thread(void)
 {
+   preempt_disable();
memset(>thread.fpsimd_state, 0, sizeof(struct fpsimd_state));
+   fpsimd_flush_task_state(current);
set_thread_flag(TIF_FOREIGN_FPSTATE);
+   preempt_enable();
 }
 
 /*
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 6094c64b3380..df0f5347029f 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -253,8 +253,11 @@ retry:
 * signal first. We do not need to release the mmap_sem because it
 * would already be released in __lock_page_or_retry in mm/filemap.c.
 */
-   if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+   if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) {
+   if (!user_mode(regs))
+   goto no_context;
return 0;
+   }
 
/*
 * Major/minor page fault accounting is only done on the initial
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 0c33a7c67ea5..a950864a64da 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -260,7 +260,7 @@ static void handle_relocations(void *output, unsigned long 
output_len)
 
/*
 * Process relocations: 32 bit relocations first then 64 bit after.
-* Two sets of binary relocations are added to the end of the kernel
+* Three sets of binary relocations are added to the end of the kernel
 * before compression. Each relocation table entry is the kernel
 * address of the location which needs to be updated stored as a
 * 32-bit value which is sign extended to 64 bits.
@@ -270,6 +270,8 @@ static void handle_relocations(void *output, unsigned long 
output_len)
 * kernel bits...
 * 0 - zero terminator for 64 bit relocations
 * 64 bit relocation repeated
+* 0 - zero terminator for inverse 32 bit relocations
+* 32 bit inverse relocation repeated
 * 0 - zero terminator for 32 bit relocations
 * 32 bit relocation repeated
 *
@@ -286,6 +288,16 @@ static void handle_relocations(void *output, unsigned long 
output_len)
*(uint32_t *)ptr += delta;
}
 #ifdef CONFIG_X86_64
+   while (*--reloc) {
+   long extended = *reloc;
+   extended += map;
+
+   ptr = (unsigned long)extended;
+   if (ptr < min_addr || ptr > max_addr)
+   error("inverse 32-bit relocation outside of kernel!\n");
+
+   *(int32_t *)ptr -= delta;
+   }
for (reloc--; *reloc; reloc--) {
long extended = *reloc;
extended += map;
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index b8237d8a1e0c..a882087d34f2 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -297,13 +297,13 @@ static inline unsigned type in##bwl##_p(int port) 
\
 static inline void outs##bwl(int port, const void *addr, unsigned long count) \
 {  \
asm volatile("rep; outs" #bwl   \
-: "+S"(addr), "+c"(count) : "d"(port));\
+: "+S"(addr), "+c"(count) : "d"(port) : "memory"); \
 }  \
\
 static inline void ins##bwl(int port, void *addr, unsigned long count) \
 {  \
asm volatile("rep; ins" #bwl\
-: "+D"(addr), "+c"(count) : "d"(port));\
+: "+D"(addr), "+c"(count) : "d"(port) : "memory"); \
 }
 
 BUILDIO(b, b, char)
diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index a5efb21d5228..73eb7fd4aec4 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -20,7 +20,10 @@ struct relocs {
 
 static struct relocs relocs16;
 static struct relocs relocs32;
+#if ELF_BITS == 64
+static struct relocs relocs32neg;
 static struct relocs relocs64;
+#endif
 
 struct section {
Elf_Shdr   shdr;
@@ -762,11 +765,16 @@ static int do_reloc64(struct section *sec, Elf_Rel *rel, 
ElfW(Sym) *sym,
 
switch (r_type) {
case R_X86_64_NONE:
+   /* NONE can be ignored. */
+   

Linux 3.18.69

2017-09-01 Thread Greg KH
I'm announcing the release of the 3.18.69 kernel.

All users of the 3.18 kernel series must upgrade.

The updated 3.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.18.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile|2 -
 arch/arm64/kernel/fpsimd.c  |3 +
 arch/arm64/mm/fault.c   |5 ++-
 arch/x86/boot/compressed/misc.c |   14 
 arch/x86/include/asm/io.h   |4 +-
 arch/x86/tools/relocs.c |   39 +---
 drivers/base/dma-contiguous.c   |2 -
 drivers/clk/clk-si5351.c|   10 +++---
 drivers/net/wireless/p54/fwio.c |2 -
 drivers/scsi/isci/remote_node_context.c |3 +
 drivers/scsi/sg.c   |   49 +-
 include/linux/bitmap.h  |   36 +++---
 include/linux/cma.h |   13 
 include/linux/dma-contiguous.h  |4 +-
 kernel/gcov/base.c  |   12 +++
 kernel/gcov/gcc_4_7.c   |6 +++
 lib/bitmap.c|   24 --
 mm/cma.c|   52 
 mm/page_alloc.c |6 ++-
 sound/pci/au88x0/au88x0_core.c  |   14 +++-
 20 files changed, 208 insertions(+), 92 deletions(-)

Ard Biesheuvel (1):
  arm64: flush FP/SIMD state correctly after execve()

Arnd Bergmann (2):
  scsi: isci: avoid array subscript warning
  x86/io: Add "memory" clobber to insb/insw/insl/outsb/outsw/outsl

Danesh Petigara (1):
  mm: cma: fix CMA aligned offset calculation

Dave Martin (1):
  arm64: fpsimd: Prevent registers leaking across exec

Florian Meier (1):
  gcov: add support for gcc version >= 6

George G. Davis (1):
  mm: cma: fix totalcma_pages to include DT defined CMA regions

Greg Kroah-Hartman (1):
  Linux 3.18.69

Gregory Fong (1):
  mm: cma: align to physical address, not CMA region position

Hannes Reinecke (2):
  scsi: sg: protect accesses to 'reserved' page array
  scsi: sg: reset 'res_in_use' after unlinking reserved array

Jan Beulich (1):
  x86-64: Handle PC-relative relocations on per-CPU data

Jiri Slaby (1):
  p54: memset(0) whole array

Krzysztof Kozlowski (1):
  clk: si5351: Constify clock names and struct regmap_config

Lorenzo Stoakes (1):
  gcov: add support for GCC 5.1

Mark Rutland (1):
  arm64: mm: abort uaccess retries upon fatal signal

Markus Trippelsdorf (1):
  x86/tools: Fix gcc-7 warning in relocs.c

Martin Liska (1):
  gcov: support GCC 7.1

Michal Nazarewicz (1):
  lib: bitmap: add alignment offset for bitmap_find_next_zero_area()

Pintu Kumar (1):
  mm: cma: split cma-reserved in dmesg log

Rohit Vaswani (1):
  mm: cma: fix incorrect type conversion for size during dma allocation

Sasha Levin (1):
  mm: cma: constify and use correct signness in mm/cma.c

Takashi Iwai (1):
  ALSA: au88x0: Fix zero clear of stream->resources

Thierry Reding (1):
  mm/cma: make kmemleak ignore CMA regions



signature.asc
Description: PGP signature


Linux 3.18.69

2017-09-01 Thread Greg KH
I'm announcing the release of the 3.18.69 kernel.

All users of the 3.18 kernel series must upgrade.

The updated 3.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.18.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile|2 -
 arch/arm64/kernel/fpsimd.c  |3 +
 arch/arm64/mm/fault.c   |5 ++-
 arch/x86/boot/compressed/misc.c |   14 
 arch/x86/include/asm/io.h   |4 +-
 arch/x86/tools/relocs.c |   39 +---
 drivers/base/dma-contiguous.c   |2 -
 drivers/clk/clk-si5351.c|   10 +++---
 drivers/net/wireless/p54/fwio.c |2 -
 drivers/scsi/isci/remote_node_context.c |3 +
 drivers/scsi/sg.c   |   49 +-
 include/linux/bitmap.h  |   36 +++---
 include/linux/cma.h |   13 
 include/linux/dma-contiguous.h  |4 +-
 kernel/gcov/base.c  |   12 +++
 kernel/gcov/gcc_4_7.c   |6 +++
 lib/bitmap.c|   24 --
 mm/cma.c|   52 
 mm/page_alloc.c |6 ++-
 sound/pci/au88x0/au88x0_core.c  |   14 +++-
 20 files changed, 208 insertions(+), 92 deletions(-)

Ard Biesheuvel (1):
  arm64: flush FP/SIMD state correctly after execve()

Arnd Bergmann (2):
  scsi: isci: avoid array subscript warning
  x86/io: Add "memory" clobber to insb/insw/insl/outsb/outsw/outsl

Danesh Petigara (1):
  mm: cma: fix CMA aligned offset calculation

Dave Martin (1):
  arm64: fpsimd: Prevent registers leaking across exec

Florian Meier (1):
  gcov: add support for gcc version >= 6

George G. Davis (1):
  mm: cma: fix totalcma_pages to include DT defined CMA regions

Greg Kroah-Hartman (1):
  Linux 3.18.69

Gregory Fong (1):
  mm: cma: align to physical address, not CMA region position

Hannes Reinecke (2):
  scsi: sg: protect accesses to 'reserved' page array
  scsi: sg: reset 'res_in_use' after unlinking reserved array

Jan Beulich (1):
  x86-64: Handle PC-relative relocations on per-CPU data

Jiri Slaby (1):
  p54: memset(0) whole array

Krzysztof Kozlowski (1):
  clk: si5351: Constify clock names and struct regmap_config

Lorenzo Stoakes (1):
  gcov: add support for GCC 5.1

Mark Rutland (1):
  arm64: mm: abort uaccess retries upon fatal signal

Markus Trippelsdorf (1):
  x86/tools: Fix gcc-7 warning in relocs.c

Martin Liska (1):
  gcov: support GCC 7.1

Michal Nazarewicz (1):
  lib: bitmap: add alignment offset for bitmap_find_next_zero_area()

Pintu Kumar (1):
  mm: cma: split cma-reserved in dmesg log

Rohit Vaswani (1):
  mm: cma: fix incorrect type conversion for size during dma allocation

Sasha Levin (1):
  mm: cma: constify and use correct signness in mm/cma.c

Takashi Iwai (1):
  ALSA: au88x0: Fix zero clear of stream->resources

Thierry Reding (1):
  mm/cma: make kmemleak ignore CMA regions



signature.asc
Description: PGP signature


Re: Linux 3.18.69

2017-09-01 Thread Greg KH
diff --git a/Makefile b/Makefile
index 0d7f1e91e910..49237a0442cd 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 18
-SUBLEVEL = 68
+SUBLEVEL = 69
 EXTRAVERSION =
 NAME = Diseased Newt
 
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 3dca15634e69..7b4e9ea0b1a4 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -156,8 +156,11 @@ void fpsimd_thread_switch(struct task_struct *next)
 
 void fpsimd_flush_thread(void)
 {
+   preempt_disable();
memset(>thread.fpsimd_state, 0, sizeof(struct fpsimd_state));
+   fpsimd_flush_task_state(current);
set_thread_flag(TIF_FOREIGN_FPSTATE);
+   preempt_enable();
 }
 
 /*
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 6094c64b3380..df0f5347029f 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -253,8 +253,11 @@ retry:
 * signal first. We do not need to release the mmap_sem because it
 * would already be released in __lock_page_or_retry in mm/filemap.c.
 */
-   if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+   if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) {
+   if (!user_mode(regs))
+   goto no_context;
return 0;
+   }
 
/*
 * Major/minor page fault accounting is only done on the initial
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 0c33a7c67ea5..a950864a64da 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -260,7 +260,7 @@ static void handle_relocations(void *output, unsigned long 
output_len)
 
/*
 * Process relocations: 32 bit relocations first then 64 bit after.
-* Two sets of binary relocations are added to the end of the kernel
+* Three sets of binary relocations are added to the end of the kernel
 * before compression. Each relocation table entry is the kernel
 * address of the location which needs to be updated stored as a
 * 32-bit value which is sign extended to 64 bits.
@@ -270,6 +270,8 @@ static void handle_relocations(void *output, unsigned long 
output_len)
 * kernel bits...
 * 0 - zero terminator for 64 bit relocations
 * 64 bit relocation repeated
+* 0 - zero terminator for inverse 32 bit relocations
+* 32 bit inverse relocation repeated
 * 0 - zero terminator for 32 bit relocations
 * 32 bit relocation repeated
 *
@@ -286,6 +288,16 @@ static void handle_relocations(void *output, unsigned long 
output_len)
*(uint32_t *)ptr += delta;
}
 #ifdef CONFIG_X86_64
+   while (*--reloc) {
+   long extended = *reloc;
+   extended += map;
+
+   ptr = (unsigned long)extended;
+   if (ptr < min_addr || ptr > max_addr)
+   error("inverse 32-bit relocation outside of kernel!\n");
+
+   *(int32_t *)ptr -= delta;
+   }
for (reloc--; *reloc; reloc--) {
long extended = *reloc;
extended += map;
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index b8237d8a1e0c..a882087d34f2 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -297,13 +297,13 @@ static inline unsigned type in##bwl##_p(int port) 
\
 static inline void outs##bwl(int port, const void *addr, unsigned long count) \
 {  \
asm volatile("rep; outs" #bwl   \
-: "+S"(addr), "+c"(count) : "d"(port));\
+: "+S"(addr), "+c"(count) : "d"(port) : "memory"); \
 }  \
\
 static inline void ins##bwl(int port, void *addr, unsigned long count) \
 {  \
asm volatile("rep; ins" #bwl\
-: "+D"(addr), "+c"(count) : "d"(port));\
+: "+D"(addr), "+c"(count) : "d"(port) : "memory"); \
 }
 
 BUILDIO(b, b, char)
diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index a5efb21d5228..73eb7fd4aec4 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -20,7 +20,10 @@ struct relocs {
 
 static struct relocs relocs16;
 static struct relocs relocs32;
+#if ELF_BITS == 64
+static struct relocs relocs32neg;
 static struct relocs relocs64;
+#endif
 
 struct section {
Elf_Shdr   shdr;
@@ -762,11 +765,16 @@ static int do_reloc64(struct section *sec, Elf_Rel *rel, 
ElfW(Sym) *sym,
 
switch (r_type) {
case R_X86_64_NONE:
+   /* NONE can be ignored. */
+   

Re: [RFC 0/4] mmc: sdhci-msm: Add CQE support for sdhci-msm

2017-09-01 Thread Ritesh Harjani


On 8/31/2017 2:09 PM, Adrian Hunter wrote:

On 30/08/17 16:04, Ritesh Harjani wrote:

Hi All,

Please ignore the previous patch series from a wrong email
address. Stupid gitconfig issue. Apologies for the spam.

This is RFC patch series based on top of ulfh_mmc/cmdq branch
which is based upon Adrian's CMDQ patch series.

Below patch series enables CQE for sdhci-msm platform.
This has been tested on internal 8996 MTP which has CMDQ support.

Fixes w.r.t. CMDQ:-
There are some patches identified which were required atleast on
MSM platform. I am not sure if these are required for any other
CQE platform or not. Patchset 1, 3 & 4 commit text describes
the problems.

Performance related:-
I gave one small shot for performance and the numbers were not looking good.
So, unless I have tested for performance completely, I should not discuss
on performance numbers as of now with this patchset.
I can try doing some more performance testing and post the results -
though this may take some while.


You might also need custom Send Status Configuration.


Yes, I will check that once.
I think for the single job I/O this may not would have matter much.
But sure, I will check on this, if re-configuring is needed.





I used below test script for random read/write test.

*randwrite-test-script*
[global]
bs=32k
size=1g
rw=randwrite
direct=1
directory=/data/fiotest


Random write results can vary a lot.  It is important to know if the eMMC
has lots of un-mapped blocks or not. e.g. for ext4 is the "-o discard"
option being used.  I find I get more consistent results if I always have
discards enabled.



[file1]
filename=singlefile1

*randread-test-script*
[global]
bs=32k
size=1g
rw=randread
directory=/data/fiotest


If you don't set numjobs > 1 then there is little benefit of the queue.
Also still need direct=1


Yes, silly me. But still I got lower results with single job then.
But anyways let me again check this out. Thanks.





[file1]
filename=singlefile1

@Adrian,
Thanks a lot for pursuing and bringing CMDQ patch series to it's final stages :)


Ritesh Harjani (4):
   mmc: cqhci: Move CQHCI_ENABLE before setting TDLBA/TDLBAU
   mmc: sdhci-msm: Add CQHCI support for sdhci-msm
   mmc: sdhci-msm: Change the desc_sz on cqe_enable/disable.
   mmc: sdhci-msm: Handle unexpected interrupt case on enabling legacy
 IRQs on CQE halt

  .../devicetree/bindings/mmc/sdhci-msm.txt  |   1 +
  drivers/mmc/host/Kconfig   |   1 +
  drivers/mmc/host/cqhci.c   |   7 +-
  drivers/mmc/host/sdhci-msm.c   | 121 -
  4 files changed, 125 insertions(+), 5 deletions(-)





--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, 
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project.


Re: [RFC 0/4] mmc: sdhci-msm: Add CQE support for sdhci-msm

2017-09-01 Thread Ritesh Harjani


On 8/31/2017 2:09 PM, Adrian Hunter wrote:

On 30/08/17 16:04, Ritesh Harjani wrote:

Hi All,

Please ignore the previous patch series from a wrong email
address. Stupid gitconfig issue. Apologies for the spam.

This is RFC patch series based on top of ulfh_mmc/cmdq branch
which is based upon Adrian's CMDQ patch series.

Below patch series enables CQE for sdhci-msm platform.
This has been tested on internal 8996 MTP which has CMDQ support.

Fixes w.r.t. CMDQ:-
There are some patches identified which were required atleast on
MSM platform. I am not sure if these are required for any other
CQE platform or not. Patchset 1, 3 & 4 commit text describes
the problems.

Performance related:-
I gave one small shot for performance and the numbers were not looking good.
So, unless I have tested for performance completely, I should not discuss
on performance numbers as of now with this patchset.
I can try doing some more performance testing and post the results -
though this may take some while.


You might also need custom Send Status Configuration.


Yes, I will check that once.
I think for the single job I/O this may not would have matter much.
But sure, I will check on this, if re-configuring is needed.





I used below test script for random read/write test.

*randwrite-test-script*
[global]
bs=32k
size=1g
rw=randwrite
direct=1
directory=/data/fiotest


Random write results can vary a lot.  It is important to know if the eMMC
has lots of un-mapped blocks or not. e.g. for ext4 is the "-o discard"
option being used.  I find I get more consistent results if I always have
discards enabled.



[file1]
filename=singlefile1

*randread-test-script*
[global]
bs=32k
size=1g
rw=randread
directory=/data/fiotest


If you don't set numjobs > 1 then there is little benefit of the queue.
Also still need direct=1


Yes, silly me. But still I got lower results with single job then.
But anyways let me again check this out. Thanks.





[file1]
filename=singlefile1

@Adrian,
Thanks a lot for pursuing and bringing CMDQ patch series to it's final stages :)


Ritesh Harjani (4):
   mmc: cqhci: Move CQHCI_ENABLE before setting TDLBA/TDLBAU
   mmc: sdhci-msm: Add CQHCI support for sdhci-msm
   mmc: sdhci-msm: Change the desc_sz on cqe_enable/disable.
   mmc: sdhci-msm: Handle unexpected interrupt case on enabling legacy
 IRQs on CQE halt

  .../devicetree/bindings/mmc/sdhci-msm.txt  |   1 +
  drivers/mmc/host/Kconfig   |   1 +
  drivers/mmc/host/cqhci.c   |   7 +-
  drivers/mmc/host/sdhci-msm.c   | 121 -
  4 files changed, 125 insertions(+), 5 deletions(-)





--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, 
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project.


Re: [RFC 4/4] mmc: sdhci-msm: Handle unexpected interrupt case on enabling legacy IRQs on CQE halt

2017-09-01 Thread Ritesh Harjani


On 8/31/2017 1:05 PM, Adrian Hunter wrote:

On 30/08/17 16:04, Ritesh Harjani wrote:

There is a case when enabling the legacy IRQs and halting CQE is
resuling into a command response interrupt without any command in
progress. This patch handles such case here.

Error signature without this patch:-
mmc0: Got command interrupt 0x0001 even though no command operation
was in progress.

Signed-off-by: Ritesh Harjani 


Seems fine, but this is a necessary part of enabling i.e. put all the
sdhci-msm changes into one patch.


Yes, sure.




---
  drivers/mmc/host/sdhci-msm.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index baa3409..8fdc2c0 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -1124,10 +1124,21 @@ void sdhci_msm_cqe_enable(struct mmc_host *mmc)
  void sdhci_msm_cqe_disable(struct mmc_host *mmc, bool recovery)
  {
struct sdhci_host *host = mmc_priv(mmc);
+   unsigned long flags;
+   u32 ctrl;
  
  	if (host->flags & SDHCI_USE_64_BIT_DMA)

host->desc_sz = 16;
  
+	spin_lock_irqsave(>lock, flags);

+


Could use a comment here.


Ok. Thanks.




+   ctrl = sdhci_readl(host, SDHCI_INT_ENABLE);
+   ctrl |= SDHCI_INT_RESPONSE;
+   sdhci_writel(host,  ctrl, SDHCI_INT_ENABLE);
+   sdhci_writel(host, SDHCI_INT_RESPONSE, SDHCI_INT_STATUS);
+
+   spin_unlock_irqrestore(>lock, flags);
+
sdhci_cqe_disable(mmc, recovery);
  }
  





--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, 
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project.


Re: [RFC 4/4] mmc: sdhci-msm: Handle unexpected interrupt case on enabling legacy IRQs on CQE halt

2017-09-01 Thread Ritesh Harjani


On 8/31/2017 1:05 PM, Adrian Hunter wrote:

On 30/08/17 16:04, Ritesh Harjani wrote:

There is a case when enabling the legacy IRQs and halting CQE is
resuling into a command response interrupt without any command in
progress. This patch handles such case here.

Error signature without this patch:-
mmc0: Got command interrupt 0x0001 even though no command operation
was in progress.

Signed-off-by: Ritesh Harjani 


Seems fine, but this is a necessary part of enabling i.e. put all the
sdhci-msm changes into one patch.


Yes, sure.




---
  drivers/mmc/host/sdhci-msm.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index baa3409..8fdc2c0 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -1124,10 +1124,21 @@ void sdhci_msm_cqe_enable(struct mmc_host *mmc)
  void sdhci_msm_cqe_disable(struct mmc_host *mmc, bool recovery)
  {
struct sdhci_host *host = mmc_priv(mmc);
+   unsigned long flags;
+   u32 ctrl;
  
  	if (host->flags & SDHCI_USE_64_BIT_DMA)

host->desc_sz = 16;
  
+	spin_lock_irqsave(>lock, flags);

+


Could use a comment here.


Ok. Thanks.




+   ctrl = sdhci_readl(host, SDHCI_INT_ENABLE);
+   ctrl |= SDHCI_INT_RESPONSE;
+   sdhci_writel(host,  ctrl, SDHCI_INT_ENABLE);
+   sdhci_writel(host, SDHCI_INT_RESPONSE, SDHCI_INT_STATUS);
+
+   spin_unlock_irqrestore(>lock, flags);
+
sdhci_cqe_disable(mmc, recovery);
  }
  





--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, 
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project.


Re: [RFC 3/4] mmc: sdhci-msm: Change the desc_sz on cqe_enable/disable.

2017-09-01 Thread Ritesh Harjani



On 8/31/2017 12:12 PM, Adrian Hunter wrote:

On 30/08/17 16:04, Ritesh Harjani wrote:

When CMDQ is halted the HW expects descriptor size to
be same which is using in CMDQ mode.
Thus adjust the desc_sz of sdhci accordingly.

Without this patch below command gives ADMA error
when CQE is enabled.
cat /sys/kernel/debug/mmc0/mmc0:0001/ext_csd

Signed-off-by: Ritesh Harjani 
---
  drivers/mmc/host/sdhci-msm.c | 24 ++--
  1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 346cdfb..baa3409 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -,9 +,29 @@ static u32 sdhci_msm_cqe_irq(struct sdhci_host *host, 
u32 intmask)
return 0;
  }
  
+void sdhci_msm_cqe_enable(struct mmc_host *mmc)

+{
+   struct sdhci_host *host = mmc_priv(mmc);
+
+   if (host->flags & SDHCI_USE_64_BIT_DMA)
+   host->desc_sz = 12;


This has no effect.


Yes, I added it for the sake of completion.
Sure I will check on this.




+
+   sdhci_cqe_enable(mmc);
+}
+
+void sdhci_msm_cqe_disable(struct mmc_host *mmc, bool recovery)
+{
+   struct sdhci_host *host = mmc_priv(mmc);
+
+   if (host->flags & SDHCI_USE_64_BIT_DMA)
+   host->desc_sz = 16;


You can't change the descriptor size this way.  If you need 128-bit ADMA
descriptors it must be done in sdhci_setup_host().


Let me again check on this once. I will get back then.
Thanks.




+
+   sdhci_cqe_disable(mmc, recovery);
+}
+
  static const struct cqhci_host_ops sdhci_msm_cqhci_ops = {
-   .enable = sdhci_cqe_enable,
-   .disable= sdhci_cqe_disable,
+   .enable = sdhci_msm_cqe_enable,
+   .disable= sdhci_msm_cqe_disable,
  };
  
  #ifdef CONFIG_MMC_CQHCI






--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, 
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project.


Re: [RFC 3/4] mmc: sdhci-msm: Change the desc_sz on cqe_enable/disable.

2017-09-01 Thread Ritesh Harjani



On 8/31/2017 12:12 PM, Adrian Hunter wrote:

On 30/08/17 16:04, Ritesh Harjani wrote:

When CMDQ is halted the HW expects descriptor size to
be same which is using in CMDQ mode.
Thus adjust the desc_sz of sdhci accordingly.

Without this patch below command gives ADMA error
when CQE is enabled.
cat /sys/kernel/debug/mmc0/mmc0:0001/ext_csd

Signed-off-by: Ritesh Harjani 
---
  drivers/mmc/host/sdhci-msm.c | 24 ++--
  1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 346cdfb..baa3409 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -,9 +,29 @@ static u32 sdhci_msm_cqe_irq(struct sdhci_host *host, 
u32 intmask)
return 0;
  }
  
+void sdhci_msm_cqe_enable(struct mmc_host *mmc)

+{
+   struct sdhci_host *host = mmc_priv(mmc);
+
+   if (host->flags & SDHCI_USE_64_BIT_DMA)
+   host->desc_sz = 12;


This has no effect.


Yes, I added it for the sake of completion.
Sure I will check on this.




+
+   sdhci_cqe_enable(mmc);
+}
+
+void sdhci_msm_cqe_disable(struct mmc_host *mmc, bool recovery)
+{
+   struct sdhci_host *host = mmc_priv(mmc);
+
+   if (host->flags & SDHCI_USE_64_BIT_DMA)
+   host->desc_sz = 16;


You can't change the descriptor size this way.  If you need 128-bit ADMA
descriptors it must be done in sdhci_setup_host().


Let me again check on this once. I will get back then.
Thanks.




+
+   sdhci_cqe_disable(mmc, recovery);
+}
+
  static const struct cqhci_host_ops sdhci_msm_cqhci_ops = {
-   .enable = sdhci_cqe_enable,
-   .disable= sdhci_cqe_disable,
+   .enable = sdhci_msm_cqe_enable,
+   .disable= sdhci_msm_cqe_disable,
  };
  
  #ifdef CONFIG_MMC_CQHCI






--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, 
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project.


Re: [RFC 2/4] mmc: sdhci-msm: Add CQHCI support for sdhci-msm

2017-09-01 Thread Ritesh Harjani



On 8/31/2017 12:55 PM, Adrian Hunter wrote:

On 30/08/17 16:04, Ritesh Harjani wrote:

This adds CQHCI support for sdhci-msm platforms.

Signed-off-by: Ritesh Harjani 
---
  .../devicetree/bindings/mmc/sdhci-msm.txt  |  1 +
  drivers/mmc/host/Kconfig   |  1 +
  drivers/mmc/host/sdhci-msm.c   | 90 +-
  3 files changed, 91 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt 
b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
index 0576264..897294f 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
@@ -5,6 +5,7 @@ and the properties used by the sdhci-msm driver.
  
  Required properties:

  - compatible: Should contain "qcom,sdhci-msm-v4".
+- compatible: "qcom,sdhci-msm-cqe" - Optional in case the controller support 
CQE.
  - reg: Base address and length of the register in the following order:
- Host controller register map (required)
- SD Core register map (required)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index b8c9ea5..a2524c7 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -430,6 +430,7 @@ config MMC_SDHCI_MSM
tristate "Qualcomm SDHCI Controller Support"
depends on ARCH_QCOM || (ARM && COMPILE_TEST)
depends on MMC_SDHCI_PLTFM
+   select MMC_CQHCI
help
  This selects the Secure Digital Host Controller Interface (SDHCI)
  support present in Qualcomm SOCs. The controller supports
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index df66724..346cdfb 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -23,6 +23,7 @@
  #include 
  
  #include "sdhci-pltfm.h"

+#include "cqhci.h"
  
  #define CORE_MCI_VERSION		0x50

  #define CORE_VERSION_MAJOR_SHIFT  28
@@ -1092,8 +1093,87 @@ static void sdhci_msm_set_clock(struct sdhci_host *host, 
unsigned int clock)
__sdhci_msm_set_clock(host, clock);
  }
  
+/*\

+ *   *
+ * MSM Command Queue Engine (CQE)*
+ *   *
+\*/
+
+static u32 sdhci_msm_cqe_irq(struct sdhci_host *host, u32 intmask)
+{
+   int cmd_error = 0;
+   int data_error = 0;
+
+   if (!sdhci_cqe_irq(host, intmask, _error, _error))
+   return intmask;
+
+   cqhci_irq(host->mmc, intmask, cmd_error, data_error);
+   return 0;
+}
+
+static const struct cqhci_host_ops sdhci_msm_cqhci_ops = {
+   .enable = sdhci_cqe_enable,
+   .disable= sdhci_cqe_disable,
+};
+
+#ifdef CONFIG_MMC_CQHCI


If you select MMC_CQHCI then this #ifdef is not needed


Yes. Thanks.





+static int sdhci_msm_cqe_add_host(struct sdhci_host *host,
+   struct platform_device *pdev)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
+   struct cqhci_host *cq_host;
+   bool dma64;
+   int ret;
+
+   ret = sdhci_setup_host(host);
+   if (ret)
+   return ret;
+
+   cq_host = cqhci_pltfm_init(pdev);
+   if (IS_ERR(cq_host)) {
+   ret = PTR_ERR(cq_host);
+   dev_err(>dev, "cqhci-pltfm init: failed: %d\n", ret);
+   goto cleanup;
+   }
+
+   msm_host->mmc->caps2 |= MMC_CAP2_CQE;


If DCMD works you need MMC_CAP2_CQE_DCMD also


Yes, I could not test DCMD. Sure I will check it once.




+   cq_host->ops = _msm_cqhci_ops;
+
+   dma64 = host->flags & SDHCI_USE_64_BIT_DMA;
+   if (dma64)
+   cq_host->caps |= CQHCI_TASK_DESC_SZ_128;
+
+   ret = cqhci_init(cq_host, host->mmc, dma64);
+   if (ret) {
+   dev_err(>dev, "%s: CQE init: failed (%d)\n", 
mmc_hostname(host->mmc),
+   ret);
+   goto cleanup;
+   }
+
+   ret = __sdhci_add_host(host);
+   if (ret)
+   goto cleanup;
+
+   dev_info(>dev, "%s: CQE init: success\n", 
mmc_hostname(host->mmc));
+   return ret;
+
+cleanup:
+   sdhci_cleanup_host(host);
+   return ret;
+}
+#else
+static void sdhci_msm_cqe_add_host(struct sdhci_host *host,
+   struct platform_device *pdev)
+{
+   dev_warn(>dev, "CQE config not enabled, defaulting to sdhci\n");
+   return sdhci_add_host(host);
+}
+#endif /* CONFIG_MMC_CQHCI */
+
  static const struct of_device_id sdhci_msm_dt_match[] = {
{ .compatible = "qcom,sdhci-msm-v4" },
+   { .compatible = "qcom,sdhci-msm-cqe" },
{},
  

Re: [RFC 2/4] mmc: sdhci-msm: Add CQHCI support for sdhci-msm

2017-09-01 Thread Ritesh Harjani



On 8/31/2017 12:55 PM, Adrian Hunter wrote:

On 30/08/17 16:04, Ritesh Harjani wrote:

This adds CQHCI support for sdhci-msm platforms.

Signed-off-by: Ritesh Harjani 
---
  .../devicetree/bindings/mmc/sdhci-msm.txt  |  1 +
  drivers/mmc/host/Kconfig   |  1 +
  drivers/mmc/host/sdhci-msm.c   | 90 +-
  3 files changed, 91 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt 
b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
index 0576264..897294f 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
@@ -5,6 +5,7 @@ and the properties used by the sdhci-msm driver.
  
  Required properties:

  - compatible: Should contain "qcom,sdhci-msm-v4".
+- compatible: "qcom,sdhci-msm-cqe" - Optional in case the controller support 
CQE.
  - reg: Base address and length of the register in the following order:
- Host controller register map (required)
- SD Core register map (required)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index b8c9ea5..a2524c7 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -430,6 +430,7 @@ config MMC_SDHCI_MSM
tristate "Qualcomm SDHCI Controller Support"
depends on ARCH_QCOM || (ARM && COMPILE_TEST)
depends on MMC_SDHCI_PLTFM
+   select MMC_CQHCI
help
  This selects the Secure Digital Host Controller Interface (SDHCI)
  support present in Qualcomm SOCs. The controller supports
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index df66724..346cdfb 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -23,6 +23,7 @@
  #include 
  
  #include "sdhci-pltfm.h"

+#include "cqhci.h"
  
  #define CORE_MCI_VERSION		0x50

  #define CORE_VERSION_MAJOR_SHIFT  28
@@ -1092,8 +1093,87 @@ static void sdhci_msm_set_clock(struct sdhci_host *host, 
unsigned int clock)
__sdhci_msm_set_clock(host, clock);
  }
  
+/*\

+ *   *
+ * MSM Command Queue Engine (CQE)*
+ *   *
+\*/
+
+static u32 sdhci_msm_cqe_irq(struct sdhci_host *host, u32 intmask)
+{
+   int cmd_error = 0;
+   int data_error = 0;
+
+   if (!sdhci_cqe_irq(host, intmask, _error, _error))
+   return intmask;
+
+   cqhci_irq(host->mmc, intmask, cmd_error, data_error);
+   return 0;
+}
+
+static const struct cqhci_host_ops sdhci_msm_cqhci_ops = {
+   .enable = sdhci_cqe_enable,
+   .disable= sdhci_cqe_disable,
+};
+
+#ifdef CONFIG_MMC_CQHCI


If you select MMC_CQHCI then this #ifdef is not needed


Yes. Thanks.





+static int sdhci_msm_cqe_add_host(struct sdhci_host *host,
+   struct platform_device *pdev)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
+   struct cqhci_host *cq_host;
+   bool dma64;
+   int ret;
+
+   ret = sdhci_setup_host(host);
+   if (ret)
+   return ret;
+
+   cq_host = cqhci_pltfm_init(pdev);
+   if (IS_ERR(cq_host)) {
+   ret = PTR_ERR(cq_host);
+   dev_err(>dev, "cqhci-pltfm init: failed: %d\n", ret);
+   goto cleanup;
+   }
+
+   msm_host->mmc->caps2 |= MMC_CAP2_CQE;


If DCMD works you need MMC_CAP2_CQE_DCMD also


Yes, I could not test DCMD. Sure I will check it once.




+   cq_host->ops = _msm_cqhci_ops;
+
+   dma64 = host->flags & SDHCI_USE_64_BIT_DMA;
+   if (dma64)
+   cq_host->caps |= CQHCI_TASK_DESC_SZ_128;
+
+   ret = cqhci_init(cq_host, host->mmc, dma64);
+   if (ret) {
+   dev_err(>dev, "%s: CQE init: failed (%d)\n", 
mmc_hostname(host->mmc),
+   ret);
+   goto cleanup;
+   }
+
+   ret = __sdhci_add_host(host);
+   if (ret)
+   goto cleanup;
+
+   dev_info(>dev, "%s: CQE init: success\n", 
mmc_hostname(host->mmc));
+   return ret;
+
+cleanup:
+   sdhci_cleanup_host(host);
+   return ret;
+}
+#else
+static void sdhci_msm_cqe_add_host(struct sdhci_host *host,
+   struct platform_device *pdev)
+{
+   dev_warn(>dev, "CQE config not enabled, defaulting to sdhci\n");
+   return sdhci_add_host(host);
+}
+#endif /* CONFIG_MMC_CQHCI */
+
  static const struct of_device_id sdhci_msm_dt_match[] = {
{ .compatible = "qcom,sdhci-msm-v4" },
+   { .compatible = "qcom,sdhci-msm-cqe" },
{},
  };
  
@@ -1107,6 

Re: [RFC 1/4] mmc: cqhci: Move CQHCI_ENABLE before setting TDLBA/TDLBAU

2017-09-01 Thread Ritesh Harjani



On 8/31/2017 11:31 AM, Adrian Hunter wrote:

On 30/08/17 16:04, Ritesh Harjani wrote:

Without this patch the CQHCI registers are getting reset
again.

Signed-off-by: Ritesh Harjani 
---
  drivers/mmc/host/cqhci.c | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/cqhci.c b/drivers/mmc/host/cqhci.c
index 8650a13..2a7351c 100644
--- a/drivers/mmc/host/cqhci.c
+++ b/drivers/mmc/host/cqhci.c
@@ -262,6 +262,9 @@ static void __cqhci_enable(struct cqhci_host *cq_host)
  
  	cqhci_writel(cq_host, cqcfg, CQHCI_CFG);
  
+	cqcfg |= CQHCI_ENABLE;

+   cqhci_writel(cq_host, cqcfg, CQHCI_CFG);

That doesn't follow the flow in the specification B.6.1. Command Queuing
Initialization Sequence.  Also in B.3.5 Task List, the spec. says "Changing
the value of TDLBA is not allowed when command queue mode is enabled."

So you will need to add a quirk for this.


Sure. thanks.




+
cqhci_writel(cq_host, lower_32_bits(cq_host->desc_dma_base),
 CQHCI_TDLBA);
cqhci_writel(cq_host, upper_32_bits(cq_host->desc_dma_base),
@@ -271,10 +274,6 @@ static void __cqhci_enable(struct cqhci_host *cq_host)
  
  	cqhci_set_irqs(cq_host, 0);
  
-	cqcfg |= CQHCI_ENABLE;

-
-   cqhci_writel(cq_host, cqcfg, CQHCI_CFG);
-
mmc->cqe_on = true;
  
  	if (cq_host->ops->enable)






--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, 
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project.


Re: [RFC 1/4] mmc: cqhci: Move CQHCI_ENABLE before setting TDLBA/TDLBAU

2017-09-01 Thread Ritesh Harjani



On 8/31/2017 11:31 AM, Adrian Hunter wrote:

On 30/08/17 16:04, Ritesh Harjani wrote:

Without this patch the CQHCI registers are getting reset
again.

Signed-off-by: Ritesh Harjani 
---
  drivers/mmc/host/cqhci.c | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/cqhci.c b/drivers/mmc/host/cqhci.c
index 8650a13..2a7351c 100644
--- a/drivers/mmc/host/cqhci.c
+++ b/drivers/mmc/host/cqhci.c
@@ -262,6 +262,9 @@ static void __cqhci_enable(struct cqhci_host *cq_host)
  
  	cqhci_writel(cq_host, cqcfg, CQHCI_CFG);
  
+	cqcfg |= CQHCI_ENABLE;

+   cqhci_writel(cq_host, cqcfg, CQHCI_CFG);

That doesn't follow the flow in the specification B.6.1. Command Queuing
Initialization Sequence.  Also in B.3.5 Task List, the spec. says "Changing
the value of TDLBA is not allowed when command queue mode is enabled."

So you will need to add a quirk for this.


Sure. thanks.




+
cqhci_writel(cq_host, lower_32_bits(cq_host->desc_dma_base),
 CQHCI_TDLBA);
cqhci_writel(cq_host, upper_32_bits(cq_host->desc_dma_base),
@@ -271,10 +274,6 @@ static void __cqhci_enable(struct cqhci_host *cq_host)
  
  	cqhci_set_irqs(cq_host, 0);
  
-	cqcfg |= CQHCI_ENABLE;

-
-   cqhci_writel(cq_host, cqcfg, CQHCI_CFG);
-
mmc->cqe_on = true;
  
  	if (cq_host->ops->enable)






--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, 
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project.


Warnings from include/linux/gpio/consumer.h with CONFIG_GPIOLIB=n

2017-09-01 Thread Florian Fainelli
Hi Linus,

I think Sergei or someone else was mentioning that before a while ago,
but when CONFIG_GPIOLIB=n most gpiod_* inline stubs have WARN_ON() that
will scare people.

What do you recommend doing for code that might be built with or without
CONFIG_GPIOLIB, should we just encapsulate the part that deals with
GPIOs under an #if IS_ENABLED(CONFIG_GPIOLIB) or something? The
particular piece of code that I just saw this with is
drivers/net/phy/mdio_bus.c.

Thanks!
-- 
Florian


Warnings from include/linux/gpio/consumer.h with CONFIG_GPIOLIB=n

2017-09-01 Thread Florian Fainelli
Hi Linus,

I think Sergei or someone else was mentioning that before a while ago,
but when CONFIG_GPIOLIB=n most gpiod_* inline stubs have WARN_ON() that
will scare people.

What do you recommend doing for code that might be built with or without
CONFIG_GPIOLIB, should we just encapsulate the part that deals with
GPIOs under an #if IS_ENABLED(CONFIG_GPIOLIB) or something? The
particular piece of code that I just saw this with is
drivers/net/phy/mdio_bus.c.

Thanks!
-- 
Florian


Re: [PATCH 13/13] thermal/drivers/hisi: Remove mutex_lock in the code

2017-09-01 Thread Leo Yan
On Wed, Aug 30, 2017 at 10:47:37AM +0200, Daniel Lezcano wrote:
> The mutex is used to protect against writes in the configuration register.
> 
> That happens at probe time, with no possible race yet.
> 
> Then when the module is unloaded and at suspend/resume.
> 
> When the module is unloaded, it is an userspace operation, thus via a process.
> Suspending the system goes through the freezer to suspend all the tasks
> synchronously before continuing. So it is not possible to hit the suspend ops
> in this driver while we are unloading it.
> 
> The resume is the same situation than the probe.
> 
> In other words, even if there are several places where we write the
> configuration register, there is no situation where we can write it at the 
> same
> time, so far as I can judge

After applied your previous patches, configuration reigster accessing
only happens in the probe and resume functions. So shouldn't have
chance to access it at the same time.

BTW, I verified this patch with system suspend/resume, so far it works
well after system resume back.

> Signed-off-by: Daniel Lezcano 

Reviewed-by: Leo Yan 
Tested-by: Leo Yan 

> ---
>  drivers/thermal/hisi_thermal.c | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index b1b086ab..b9e8ee2 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -51,7 +51,6 @@ struct hisi_thermal_sensor {
>  };
>  
>  struct hisi_thermal_data {
> - struct mutex thermal_lock;/* protects register data */
>   struct platform_device *pdev;
>   struct clk *clk;
>   struct hisi_thermal_sensor sensor;
> @@ -196,14 +195,10 @@ static inline void hisi_thermal_hdak_set(void __iomem 
> *addr, int value)
>  
>  static void hisi_thermal_disable_sensor(struct hisi_thermal_data *data)
>  {
> - mutex_lock(>thermal_lock);
> -
>   /* disable sensor module */
>   hisi_thermal_enable(data->regs, 0);
>   hisi_thermal_alarm_enable(data->regs, 0);
>   hisi_thermal_reset_enable(data->regs, 0);
> - 
> - mutex_unlock(>thermal_lock);
>  }
>  
>  static int hisi_thermal_get_temp(void *__data, int *temp)
> @@ -340,7 +335,6 @@ static int hisi_thermal_probe(struct platform_device 
> *pdev)
>   if (!data)
>   return -ENOMEM;
>  
> - mutex_init(>thermal_lock);
>   data->pdev = pdev;
>  
>   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -- 
> 2.7.4
> 


Re: [PATCH 13/13] thermal/drivers/hisi: Remove mutex_lock in the code

2017-09-01 Thread Leo Yan
On Wed, Aug 30, 2017 at 10:47:37AM +0200, Daniel Lezcano wrote:
> The mutex is used to protect against writes in the configuration register.
> 
> That happens at probe time, with no possible race yet.
> 
> Then when the module is unloaded and at suspend/resume.
> 
> When the module is unloaded, it is an userspace operation, thus via a process.
> Suspending the system goes through the freezer to suspend all the tasks
> synchronously before continuing. So it is not possible to hit the suspend ops
> in this driver while we are unloading it.
> 
> The resume is the same situation than the probe.
> 
> In other words, even if there are several places where we write the
> configuration register, there is no situation where we can write it at the 
> same
> time, so far as I can judge

After applied your previous patches, configuration reigster accessing
only happens in the probe and resume functions. So shouldn't have
chance to access it at the same time.

BTW, I verified this patch with system suspend/resume, so far it works
well after system resume back.

> Signed-off-by: Daniel Lezcano 

Reviewed-by: Leo Yan 
Tested-by: Leo Yan 

> ---
>  drivers/thermal/hisi_thermal.c | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index b1b086ab..b9e8ee2 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -51,7 +51,6 @@ struct hisi_thermal_sensor {
>  };
>  
>  struct hisi_thermal_data {
> - struct mutex thermal_lock;/* protects register data */
>   struct platform_device *pdev;
>   struct clk *clk;
>   struct hisi_thermal_sensor sensor;
> @@ -196,14 +195,10 @@ static inline void hisi_thermal_hdak_set(void __iomem 
> *addr, int value)
>  
>  static void hisi_thermal_disable_sensor(struct hisi_thermal_data *data)
>  {
> - mutex_lock(>thermal_lock);
> -
>   /* disable sensor module */
>   hisi_thermal_enable(data->regs, 0);
>   hisi_thermal_alarm_enable(data->regs, 0);
>   hisi_thermal_reset_enable(data->regs, 0);
> - 
> - mutex_unlock(>thermal_lock);
>  }
>  
>  static int hisi_thermal_get_temp(void *__data, int *temp)
> @@ -340,7 +335,6 @@ static int hisi_thermal_probe(struct platform_device 
> *pdev)
>   if (!data)
>   return -ENOMEM;
>  
> - mutex_init(>thermal_lock);
>   data->pdev = pdev;
>  
>   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -- 
> 2.7.4
> 


Re: [PATCH] locking/refcounts, x86/asm: Use unique .text section for refcount exceptions

2017-09-01 Thread Mike Galbraith
On Fri, 2017-09-01 at 13:22 -0700, Kees Cook wrote:
> Using .text.unlikely for refcount exceptions isn't safe because gcc may
> move entire functions into .text.unlikely (e.g. in6_dev_get()), which
> would cause any uses of a protected refcount_t function to stay inline
> with the function, triggering the protection unconditionally:
> 
> .section.text.unlikely,"ax",@progbits
> .type   in6_dev_get, @function
> in6_dev_getx:
> .LFB4673:
> .loc 2 4128 0
> .cfi_startproc
> ...
> lock; incl 480(%rbx)
> js 111f
> .pushsection .text.unlikely
> 111:lea 480(%rbx), %rcx
> 112:.byte 0x0f, 0xff
> .popsection
> 113:
> 
> This creates a unique .text section and adds an additional test to the
> exception handler to WARN in the case of having none of OF, SF, nor ZF
> set so we can see things like this more easily in the future.

Closure: gcc-4.8.5 now builds a functional kernel as well, so that
aspect of this bug was just a larger a dose of the same toxin.

Question below.

diff --git a/arch/x86/include/asm/refcount.h
b/arch/x86/include/asm/refcount.h
> index ff871210b9f2..4e44250e7d0d 100644
> --- a/arch/x86/include/asm/refcount.h
> +++ b/arch/x86/include/asm/refcount.h
> @@ -15,7 +15,7 @@
>   * back to the regular execution flow in .text.
>   */
>  #define _REFCOUNT_EXCEPTION  \
> - ".pushsection .text.unlikely\n" \
> + ".pushsection .text..refcount\n"\

Why two dots? (.text.refcount_ex?)

-Mike


Re: [PATCH] locking/refcounts, x86/asm: Use unique .text section for refcount exceptions

2017-09-01 Thread Mike Galbraith
On Fri, 2017-09-01 at 13:22 -0700, Kees Cook wrote:
> Using .text.unlikely for refcount exceptions isn't safe because gcc may
> move entire functions into .text.unlikely (e.g. in6_dev_get()), which
> would cause any uses of a protected refcount_t function to stay inline
> with the function, triggering the protection unconditionally:
> 
> .section.text.unlikely,"ax",@progbits
> .type   in6_dev_get, @function
> in6_dev_getx:
> .LFB4673:
> .loc 2 4128 0
> .cfi_startproc
> ...
> lock; incl 480(%rbx)
> js 111f
> .pushsection .text.unlikely
> 111:lea 480(%rbx), %rcx
> 112:.byte 0x0f, 0xff
> .popsection
> 113:
> 
> This creates a unique .text section and adds an additional test to the
> exception handler to WARN in the case of having none of OF, SF, nor ZF
> set so we can see things like this more easily in the future.

Closure: gcc-4.8.5 now builds a functional kernel as well, so that
aspect of this bug was just a larger a dose of the same toxin.

Question below.

diff --git a/arch/x86/include/asm/refcount.h
b/arch/x86/include/asm/refcount.h
> index ff871210b9f2..4e44250e7d0d 100644
> --- a/arch/x86/include/asm/refcount.h
> +++ b/arch/x86/include/asm/refcount.h
> @@ -15,7 +15,7 @@
>   * back to the regular execution flow in .text.
>   */
>  #define _REFCOUNT_EXCEPTION  \
> - ".pushsection .text.unlikely\n" \
> + ".pushsection .text..refcount\n"\

Why two dots? (.text.refcount_ex?)

-Mike


Re: RFC: Revert move default dialect from CIFS to to SMB3

2017-09-01 Thread Linus Torvalds
On Fri, Sep 1, 2017 at 7:16 PM, Steve French  wrote:
>
> The default was SMB1 (CIFS) and was recently changed to SMB3.
> The dialect still can be overridden by specifying "vers=1.0" or "vers=2.1"
> etc. on mount.
>
> We just put together a patch to better explain the default changes
> (with additional warning messages) as suggested.
>
> SMB3 is significantly better than SMB2.1 (supporting encrypted shares
> and sessions for example, and requiring support for "secure negotiate")
> and some servers require SMB3 minimum as a result,

The default shouldn't be about "best and most secure", but "most
convenient, while still not actively *IN*secure"

So "some servers require 3.0" may be true, but if it's also the case
that "most servers still don't do 3.0 at all", then it's a "some" vs
"most".

Which is the most common one? That should be the default.

I realize that eventually we'll have auto-negotiation, but that's
clearly not for 4.13. So in the meantime the only issue is what the
right default should be without auto-negotiation.

So it should be about what the failure rate is. If trying for smb3 has
a high failure rate because people simply don't have that yet, then
making that the default was clearly the wrong choice.

Because being "better" is immaterial if it doesn't work.

  Linus


Re: RFC: Revert move default dialect from CIFS to to SMB3

2017-09-01 Thread Linus Torvalds
On Fri, Sep 1, 2017 at 7:16 PM, Steve French  wrote:
>
> The default was SMB1 (CIFS) and was recently changed to SMB3.
> The dialect still can be overridden by specifying "vers=1.0" or "vers=2.1"
> etc. on mount.
>
> We just put together a patch to better explain the default changes
> (with additional warning messages) as suggested.
>
> SMB3 is significantly better than SMB2.1 (supporting encrypted shares
> and sessions for example, and requiring support for "secure negotiate")
> and some servers require SMB3 minimum as a result,

The default shouldn't be about "best and most secure", but "most
convenient, while still not actively *IN*secure"

So "some servers require 3.0" may be true, but if it's also the case
that "most servers still don't do 3.0 at all", then it's a "some" vs
"most".

Which is the most common one? That should be the default.

I realize that eventually we'll have auto-negotiation, but that's
clearly not for 4.13. So in the meantime the only issue is what the
right default should be without auto-negotiation.

So it should be about what the failure rate is. If trying for smb3 has
a high failure rate because people simply don't have that yet, then
making that the default was clearly the wrong choice.

Because being "better" is immaterial if it doesn't work.

  Linus


Re: [PATCH] ipv6: sr: Use ARRAY_SIZE macro

2017-09-01 Thread Joe Perches
On Fri, 2017-09-01 at 18:35 -0700, David Miller wrote:
> From: Thomas Meyer 
> Date: Thu, 31 Aug 2017 16:18:15 +0200
> 
> > Grepping for "sizeof\(.+\) / sizeof\(" found this as one of the first
> > candidates.
> > Maybe a coccinelle can catch all of those.

Umm: try scripts/coccinelle/misc/array_size.cocci

Until then, maybe a perl script?

$ git grep --name-only sizeof.*/.*sizeof drivers/net | \
  xargs perl -p -i -e 
's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\/\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)/ARRAY_SIZE(\1)/g'

gives:

$ git diff --stat drivers/net
 drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c   |   2 +-
 drivers/net/ethernet/mellanox/mlx4/fw.c |   4 +--
 drivers/net/ethernet/mellanox/mlx4/main.c   |   8 +++---
 drivers/net/wireless/ath/ath9k/ar9003_eeprom.c  |   2 +-
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phytbl_n.c | 186 
+++---
 5 files changed, 101 insertions(+), 101 deletions(-)



Re: [PATCH] ipv6: sr: Use ARRAY_SIZE macro

2017-09-01 Thread Joe Perches
On Fri, 2017-09-01 at 18:35 -0700, David Miller wrote:
> From: Thomas Meyer 
> Date: Thu, 31 Aug 2017 16:18:15 +0200
> 
> > Grepping for "sizeof\(.+\) / sizeof\(" found this as one of the first
> > candidates.
> > Maybe a coccinelle can catch all of those.

Umm: try scripts/coccinelle/misc/array_size.cocci

Until then, maybe a perl script?

$ git grep --name-only sizeof.*/.*sizeof drivers/net | \
  xargs perl -p -i -e 
's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\/\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)/ARRAY_SIZE(\1)/g'

gives:

$ git diff --stat drivers/net
 drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c   |   2 +-
 drivers/net/ethernet/mellanox/mlx4/fw.c |   4 +--
 drivers/net/ethernet/mellanox/mlx4/main.c   |   8 +++---
 drivers/net/wireless/ath/ath9k/ar9003_eeprom.c  |   2 +-
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phytbl_n.c | 186 
+++---
 5 files changed, 101 insertions(+), 101 deletions(-)



Re: [PATCH 11/13] thermal/drivers/hisi: Convert long to int

2017-09-01 Thread Leo Yan
On Wed, Aug 30, 2017 at 10:47:35AM +0200, Daniel Lezcano wrote:
> There is no point to specify the temperature as long variable, the int is
> enough.
> 
> Replace all long variables to int, so making the code consistent.
> 
> Signed-off-by: Daniel Lezcano 

Reviewed-by: Leo Yan 

> ---
>  drivers/thermal/hisi_thermal.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index 68b625c..9eee82b 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -83,12 +83,12 @@ static inline int hisi_thermal_step_to_temp(int step)
>   return HISI_TEMP_BASE + (step * HISI_TEMP_STEP);
>  }
>  
> -static inline long hisi_thermal_temp_to_step(long temp)
> +static inline int hisi_thermal_temp_to_step(int temp)
>  {
>   return (temp - HISI_TEMP_BASE) / HISI_TEMP_STEP;
>  }
>  
> -static inline long hisi_thermal_round_temp(int temp)
> +static inline int hisi_thermal_round_temp(int temp)
>  {
>   return hisi_thermal_step_to_temp(
>   hisi_thermal_temp_to_step(temp));
> -- 
> 2.7.4
> 


Re: [PATCH 11/13] thermal/drivers/hisi: Convert long to int

2017-09-01 Thread Leo Yan
On Wed, Aug 30, 2017 at 10:47:35AM +0200, Daniel Lezcano wrote:
> There is no point to specify the temperature as long variable, the int is
> enough.
> 
> Replace all long variables to int, so making the code consistent.
> 
> Signed-off-by: Daniel Lezcano 

Reviewed-by: Leo Yan 

> ---
>  drivers/thermal/hisi_thermal.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index 68b625c..9eee82b 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -83,12 +83,12 @@ static inline int hisi_thermal_step_to_temp(int step)
>   return HISI_TEMP_BASE + (step * HISI_TEMP_STEP);
>  }
>  
> -static inline long hisi_thermal_temp_to_step(long temp)
> +static inline int hisi_thermal_temp_to_step(int temp)
>  {
>   return (temp - HISI_TEMP_BASE) / HISI_TEMP_STEP;
>  }
>  
> -static inline long hisi_thermal_round_temp(int temp)
> +static inline int hisi_thermal_round_temp(int temp)
>  {
>   return hisi_thermal_step_to_temp(
>   hisi_thermal_temp_to_step(temp));
> -- 
> 2.7.4
> 


Re: tunnels: Don't apply GRO to multiple layers of encapsulation.

2017-09-01 Thread Jesse Gross
On Thu, Aug 31, 2017 at 6:58 AM,   wrote:
> [ resend due to mail problems at my end ]
>
> Hi Jesse,
>
> The backport of fac8e0f579695a3ecbc4d3cac369139d7f819971,
> "tunnels: Don't apply GRO to multiple layers of encapsulation",
> to linux-4.1.y seems to have missed a line.
>
> The 4.1 commit is 066b300e5be43cb61697539e2a3a9aac5afb422f.
>
> The potentially missing line is:
>
> -   .gro_receive= ipv6_gro_receive,
> +   .gro_receive= sit_gro_receive,
>
>
> I am not experiencing any bad symptoms.  I simply noticed
> that the patch introduced a new function, sit_gro_receive,
> without introducing any users, and that same patch in
> linux-4.4.y does have a user.

Thanks for pointing that out. The line you mentioned should indeed be
there and seems to have been missed in the backport.

The backport was actually done by Sasha, not by me - would you mind
sending a patch to him or working with him to fix it?


Re: tunnels: Don't apply GRO to multiple layers of encapsulation.

2017-09-01 Thread Jesse Gross
On Thu, Aug 31, 2017 at 6:58 AM,   wrote:
> [ resend due to mail problems at my end ]
>
> Hi Jesse,
>
> The backport of fac8e0f579695a3ecbc4d3cac369139d7f819971,
> "tunnels: Don't apply GRO to multiple layers of encapsulation",
> to linux-4.1.y seems to have missed a line.
>
> The 4.1 commit is 066b300e5be43cb61697539e2a3a9aac5afb422f.
>
> The potentially missing line is:
>
> -   .gro_receive= ipv6_gro_receive,
> +   .gro_receive= sit_gro_receive,
>
>
> I am not experiencing any bad symptoms.  I simply noticed
> that the patch introduced a new function, sit_gro_receive,
> without introducing any users, and that same patch in
> linux-4.4.y does have a user.

Thanks for pointing that out. The line you mentioned should indeed be
there and seems to have been missed in the backport.

The backport was actually done by Sasha, not by me - would you mind
sending a patch to him or working with him to fix it?


Re: [PATCH net-next, 0/4] cleanups and fixes of channel settings

2017-09-01 Thread David Miller
From: Haiyang Zhang 
Date: Fri,  1 Sep 2017 14:30:03 -0700

> This patch set cleans up some unused variables, unnecessary checks.
> Also fixed some limit checking of channel number.

Series applied.


Re: [PATCH net-next, 0/4] cleanups and fixes of channel settings

2017-09-01 Thread David Miller
From: Haiyang Zhang 
Date: Fri,  1 Sep 2017 14:30:03 -0700

> This patch set cleans up some unused variables, unnecessary checks.
> Also fixed some limit checking of channel number.

Series applied.


Re: [PATCH 10/13] thermal/drivers/hisi: Rename and remove unused field

2017-09-01 Thread Leo Yan
On Wed, Aug 30, 2017 at 10:47:34AM +0200, Daniel Lezcano wrote:
> Rename the 'sensors' field to 'sensor' as we describe only one sensor.
> Remove the 'sensor_temp' as it is no longer used.
> 
> Signed-off-by: Daniel Lezcano 

Reviewed-by: Leo Yan 
Tested-by: Leo Yan 

> ---
>  drivers/thermal/hisi_thermal.c | 18 --
>  1 file changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index b038d8a..68b625c 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -47,8 +47,6 @@
>  struct hisi_thermal_sensor {
>   struct hisi_thermal_data *thermal;
>   struct thermal_zone_device *tzd;
> -
> - long sensor_temp;
>   uint32_t id;
>   uint32_t thres_temp;
>  };
> @@ -57,9 +55,9 @@ struct hisi_thermal_data {
>   struct mutex thermal_lock;/* protects register data */
>   struct platform_device *pdev;
>   struct clk *clk;
> - struct hisi_thermal_sensor sensors;
> - int irq;
> + struct hisi_thermal_sensor sensor;
>   void __iomem *regs;
> + int irq;
>  };
>  
>  /*
> @@ -229,7 +227,7 @@ static const struct thermal_zone_of_device_ops 
> hisi_of_thermal_ops = {
>  static irqreturn_t hisi_thermal_alarm_irq_thread(int irq, void *dev)
>  {
>   struct hisi_thermal_data *data = dev;
> - struct hisi_thermal_sensor *sensor = >sensors;
> + struct hisi_thermal_sensor *sensor = >sensor;
>   int temp;
>  
>   hisi_thermal_alarm_clear(data->regs, 1);
> @@ -240,7 +238,7 @@ static irqreturn_t hisi_thermal_alarm_irq_thread(int irq, 
> void *dev)
>   dev_crit(>pdev->dev, "THERMAL ALARM: %d > %d\n",
>temp, sensor->thres_temp);
>  
> - thermal_zone_device_update(data->sensors.tzd,
> + thermal_zone_device_update(data->sensor.tzd,
>  THERMAL_EVENT_UNSPECIFIED);
>  
>   } else if (temp < sensor->thres_temp) {
> @@ -303,7 +301,7 @@ static int hisi_thermal_setup(struct hisi_thermal_data 
> *data)
>  {
>   struct hisi_thermal_sensor *sensor;
>  
> - sensor = >sensors;
> + sensor = >sensor;
>  
>   /* disable module firstly */
>   hisi_thermal_reset_enable(data->regs, 0);
> @@ -376,7 +374,7 @@ static int hisi_thermal_probe(struct platform_device 
> *pdev)
>   }
>  
>   ret = hisi_thermal_register_sensor(pdev, data,
> ->sensors,
> +>sensor,
>  HISI_DEFAULT_SENSOR);
>   if (ret) {
>   dev_err(>dev, "failed to register thermal sensor: %d\n",
> @@ -398,7 +396,7 @@ static int hisi_thermal_probe(struct platform_device 
> *pdev)
>   return ret;
>   }
>  
> - hisi_thermal_toggle_sensor(>sensors, true);
> + hisi_thermal_toggle_sensor(>sensor, true);
>  
>   return 0;
>  }
> @@ -406,7 +404,7 @@ static int hisi_thermal_probe(struct platform_device 
> *pdev)
>  static int hisi_thermal_remove(struct platform_device *pdev)
>  {
>   struct hisi_thermal_data *data = platform_get_drvdata(pdev);
> - struct hisi_thermal_sensor *sensor = >sensors;
> + struct hisi_thermal_sensor *sensor = >sensor;
>  
>   hisi_thermal_toggle_sensor(sensor, false);
>   hisi_thermal_disable_sensor(data);
> -- 
> 2.7.4
> 


Re: [PATCH 10/13] thermal/drivers/hisi: Rename and remove unused field

2017-09-01 Thread Leo Yan
On Wed, Aug 30, 2017 at 10:47:34AM +0200, Daniel Lezcano wrote:
> Rename the 'sensors' field to 'sensor' as we describe only one sensor.
> Remove the 'sensor_temp' as it is no longer used.
> 
> Signed-off-by: Daniel Lezcano 

Reviewed-by: Leo Yan 
Tested-by: Leo Yan 

> ---
>  drivers/thermal/hisi_thermal.c | 18 --
>  1 file changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index b038d8a..68b625c 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -47,8 +47,6 @@
>  struct hisi_thermal_sensor {
>   struct hisi_thermal_data *thermal;
>   struct thermal_zone_device *tzd;
> -
> - long sensor_temp;
>   uint32_t id;
>   uint32_t thres_temp;
>  };
> @@ -57,9 +55,9 @@ struct hisi_thermal_data {
>   struct mutex thermal_lock;/* protects register data */
>   struct platform_device *pdev;
>   struct clk *clk;
> - struct hisi_thermal_sensor sensors;
> - int irq;
> + struct hisi_thermal_sensor sensor;
>   void __iomem *regs;
> + int irq;
>  };
>  
>  /*
> @@ -229,7 +227,7 @@ static const struct thermal_zone_of_device_ops 
> hisi_of_thermal_ops = {
>  static irqreturn_t hisi_thermal_alarm_irq_thread(int irq, void *dev)
>  {
>   struct hisi_thermal_data *data = dev;
> - struct hisi_thermal_sensor *sensor = >sensors;
> + struct hisi_thermal_sensor *sensor = >sensor;
>   int temp;
>  
>   hisi_thermal_alarm_clear(data->regs, 1);
> @@ -240,7 +238,7 @@ static irqreturn_t hisi_thermal_alarm_irq_thread(int irq, 
> void *dev)
>   dev_crit(>pdev->dev, "THERMAL ALARM: %d > %d\n",
>temp, sensor->thres_temp);
>  
> - thermal_zone_device_update(data->sensors.tzd,
> + thermal_zone_device_update(data->sensor.tzd,
>  THERMAL_EVENT_UNSPECIFIED);
>  
>   } else if (temp < sensor->thres_temp) {
> @@ -303,7 +301,7 @@ static int hisi_thermal_setup(struct hisi_thermal_data 
> *data)
>  {
>   struct hisi_thermal_sensor *sensor;
>  
> - sensor = >sensors;
> + sensor = >sensor;
>  
>   /* disable module firstly */
>   hisi_thermal_reset_enable(data->regs, 0);
> @@ -376,7 +374,7 @@ static int hisi_thermal_probe(struct platform_device 
> *pdev)
>   }
>  
>   ret = hisi_thermal_register_sensor(pdev, data,
> ->sensors,
> +>sensor,
>  HISI_DEFAULT_SENSOR);
>   if (ret) {
>   dev_err(>dev, "failed to register thermal sensor: %d\n",
> @@ -398,7 +396,7 @@ static int hisi_thermal_probe(struct platform_device 
> *pdev)
>   return ret;
>   }
>  
> - hisi_thermal_toggle_sensor(>sensors, true);
> + hisi_thermal_toggle_sensor(>sensor, true);
>  
>   return 0;
>  }
> @@ -406,7 +404,7 @@ static int hisi_thermal_probe(struct platform_device 
> *pdev)
>  static int hisi_thermal_remove(struct platform_device *pdev)
>  {
>   struct hisi_thermal_data *data = platform_get_drvdata(pdev);
> - struct hisi_thermal_sensor *sensor = >sensors;
> + struct hisi_thermal_sensor *sensor = >sensor;
>  
>   hisi_thermal_toggle_sensor(sensor, false);
>   hisi_thermal_disable_sensor(data);
> -- 
> 2.7.4
> 


Re: [PATCH 09/13] thermal/drivers/hisi: Remove costly sensor inspection

2017-09-01 Thread Leo Yan
On Wed, Aug 30, 2017 at 10:47:33AM +0200, Daniel Lezcano wrote:
> The sensor is all setup, bind, resetted, acked, etc... every single second.
> 
> That was the way to workaround a problem with the interrupt bouncing again and
> again.
> 
> With the following changes, we fix all in one:
> 
>  - Do the setup, one time, at probe time
> 
>  - Add the IRQF_ONESHOT, ack the interrupt in the threaded handler
> 
>  - Remove the interrupt handler
> 
>  - Set the correct value for the LAG register
> 
>  - Remove all the irq_enabled stuff in the code as the interruption
>handling is fixed
> 
>  - Remove the 3ms delay
> 
>  - Reorder the initialization routine to be in the right order
> 
> It ends up to a nicer code and more efficient, the 3-5ms delay is removed from
> the get_temp() path.
> 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/thermal/hisi_thermal.c | 203 
> +++--
>  1 file changed, 93 insertions(+), 110 deletions(-)
> 
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index 3e03908..b038d8a 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -39,6 +39,7 @@
>  #define HISI_TEMP_BASE   (-6)
>  #define HISI_TEMP_RESET  (10)
>  #define HISI_TEMP_STEP   (784)
> +#define HISI_TEMP_LAG(3500)

So I am curious what's the reason to select 3.5'c for lag value? Is
this a heuristics result?

>  #define HISI_MAX_SENSORS 4
>  #define HISI_DEFAULT_SENSOR  2
> @@ -58,8 +59,6 @@ struct hisi_thermal_data {
>   struct clk *clk;
>   struct hisi_thermal_sensor sensors;
>   int irq;
> - bool irq_enabled;
> - 
>   void __iomem *regs;
>  };
>  
> @@ -97,9 +96,40 @@ static inline long hisi_thermal_round_temp(int temp)
>   hisi_thermal_temp_to_step(temp));
>  }
>  
> +/*
> + * The lag register contains 5 bits encoding the temperature in steps.
> + *
> + * Each time the temperature crosses the threshold boundary, an
> + * interrupt is raised. It could be when the temperature is going
> + * above the threshold or below. However, if the temperature is
> + * fluctuating around this value due to the load, we can receive
> + * several interrupts which may not desired.
> + *
> + * We can setup a temperature representing the delta between the
> + * threshold and the current temperature when the temperature is
> + * decreasing.
> + *
> + * For instance: the lag register is 5°C, the threshold is 65°C, when
> + * the temperature reaches 65°C an interrupt is raised and when the
> + * temperature decrease to 65°C - 5°C another interrupt is raised.
> + *
> + * A very short lag can lead to an interrupt storm, a long lag
> + * increase the latency to react to the temperature changes.  In our
> + * case, that is not really a problem as we are polling the
> + * temperature.

So here means if we set a long lag value and the interrupt is delayed,
sometimes we even don't receive the interrupt; but this is acceptable
due we are polling the temperature so we still can get the updated
temperature value, right?

> + *
> + * [0:4] : lag register
> + *
> + * The temperature is coded in steps, cf. HISI_TEMP_STEP.
> + *
> + * Min : 0x00 :  0.0 °C
> + * Max : 0x1F : 24.3 °C
> + *
> + * The 'value' parameter is in milliCelsius.
> + */
>  static inline void hisi_thermal_set_lag(void __iomem *addr, int value)
>  {
> - writel(value, addr + TEMP0_LAG);
> + writel((value / HISI_TEMP_STEP) & 0x1F, addr + TEMP0_LAG);
>  }
>  
>  static inline void hisi_thermal_alarm_clear(void __iomem *addr, int value)
> @@ -167,71 +197,6 @@ static inline void hisi_thermal_hdak_set(void __iomem 
> *addr, int value)
>   writel(readl(addr + TEMP0_CFG) | (value << 4), addr + TEMP0_CFG);
>  }
>  
> -static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data *data,
> -  struct hisi_thermal_sensor *sensor)
> -{
> - long val;
> -
> - mutex_lock(>thermal_lock);
> -
> - /* disable interrupt */
> - hisi_thermal_alarm_enable(data->regs, 0);
> - hisi_thermal_alarm_clear(data->regs, 1);
> -
> - /* disable module firstly */
> - hisi_thermal_enable(data->regs, 0);
> -
> - /* select sensor id */
> - hisi_thermal_sensor_select(data->regs, sensor->id);
> -
> - /* enable module */
> - hisi_thermal_enable(data->regs, 1);
> -
> - usleep_range(3000, 5000);
> -
> - val = hisi_thermal_get_temperature(data->regs);
> -
> - mutex_unlock(>thermal_lock);
> -
> - return val;
> -}
> -
> -static void hisi_thermal_enable_bind_irq_sensor
> - (struct hisi_thermal_data *data)
> -{
> - struct hisi_thermal_sensor *sensor;
> -
> - mutex_lock(>thermal_lock);
> -
> - sensor = >sensors;
> -
> - /* setting the hdak time */
> - hisi_thermal_hdak_set(data->regs, 0);
> -
> - /* disable module 

Re: [PATCH 09/13] thermal/drivers/hisi: Remove costly sensor inspection

2017-09-01 Thread Leo Yan
On Wed, Aug 30, 2017 at 10:47:33AM +0200, Daniel Lezcano wrote:
> The sensor is all setup, bind, resetted, acked, etc... every single second.
> 
> That was the way to workaround a problem with the interrupt bouncing again and
> again.
> 
> With the following changes, we fix all in one:
> 
>  - Do the setup, one time, at probe time
> 
>  - Add the IRQF_ONESHOT, ack the interrupt in the threaded handler
> 
>  - Remove the interrupt handler
> 
>  - Set the correct value for the LAG register
> 
>  - Remove all the irq_enabled stuff in the code as the interruption
>handling is fixed
> 
>  - Remove the 3ms delay
> 
>  - Reorder the initialization routine to be in the right order
> 
> It ends up to a nicer code and more efficient, the 3-5ms delay is removed from
> the get_temp() path.
> 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/thermal/hisi_thermal.c | 203 
> +++--
>  1 file changed, 93 insertions(+), 110 deletions(-)
> 
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index 3e03908..b038d8a 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -39,6 +39,7 @@
>  #define HISI_TEMP_BASE   (-6)
>  #define HISI_TEMP_RESET  (10)
>  #define HISI_TEMP_STEP   (784)
> +#define HISI_TEMP_LAG(3500)

So I am curious what's the reason to select 3.5'c for lag value? Is
this a heuristics result?

>  #define HISI_MAX_SENSORS 4
>  #define HISI_DEFAULT_SENSOR  2
> @@ -58,8 +59,6 @@ struct hisi_thermal_data {
>   struct clk *clk;
>   struct hisi_thermal_sensor sensors;
>   int irq;
> - bool irq_enabled;
> - 
>   void __iomem *regs;
>  };
>  
> @@ -97,9 +96,40 @@ static inline long hisi_thermal_round_temp(int temp)
>   hisi_thermal_temp_to_step(temp));
>  }
>  
> +/*
> + * The lag register contains 5 bits encoding the temperature in steps.
> + *
> + * Each time the temperature crosses the threshold boundary, an
> + * interrupt is raised. It could be when the temperature is going
> + * above the threshold or below. However, if the temperature is
> + * fluctuating around this value due to the load, we can receive
> + * several interrupts which may not desired.
> + *
> + * We can setup a temperature representing the delta between the
> + * threshold and the current temperature when the temperature is
> + * decreasing.
> + *
> + * For instance: the lag register is 5°C, the threshold is 65°C, when
> + * the temperature reaches 65°C an interrupt is raised and when the
> + * temperature decrease to 65°C - 5°C another interrupt is raised.
> + *
> + * A very short lag can lead to an interrupt storm, a long lag
> + * increase the latency to react to the temperature changes.  In our
> + * case, that is not really a problem as we are polling the
> + * temperature.

So here means if we set a long lag value and the interrupt is delayed,
sometimes we even don't receive the interrupt; but this is acceptable
due we are polling the temperature so we still can get the updated
temperature value, right?

> + *
> + * [0:4] : lag register
> + *
> + * The temperature is coded in steps, cf. HISI_TEMP_STEP.
> + *
> + * Min : 0x00 :  0.0 °C
> + * Max : 0x1F : 24.3 °C
> + *
> + * The 'value' parameter is in milliCelsius.
> + */
>  static inline void hisi_thermal_set_lag(void __iomem *addr, int value)
>  {
> - writel(value, addr + TEMP0_LAG);
> + writel((value / HISI_TEMP_STEP) & 0x1F, addr + TEMP0_LAG);
>  }
>  
>  static inline void hisi_thermal_alarm_clear(void __iomem *addr, int value)
> @@ -167,71 +197,6 @@ static inline void hisi_thermal_hdak_set(void __iomem 
> *addr, int value)
>   writel(readl(addr + TEMP0_CFG) | (value << 4), addr + TEMP0_CFG);
>  }
>  
> -static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data *data,
> -  struct hisi_thermal_sensor *sensor)
> -{
> - long val;
> -
> - mutex_lock(>thermal_lock);
> -
> - /* disable interrupt */
> - hisi_thermal_alarm_enable(data->regs, 0);
> - hisi_thermal_alarm_clear(data->regs, 1);
> -
> - /* disable module firstly */
> - hisi_thermal_enable(data->regs, 0);
> -
> - /* select sensor id */
> - hisi_thermal_sensor_select(data->regs, sensor->id);
> -
> - /* enable module */
> - hisi_thermal_enable(data->regs, 1);
> -
> - usleep_range(3000, 5000);
> -
> - val = hisi_thermal_get_temperature(data->regs);
> -
> - mutex_unlock(>thermal_lock);
> -
> - return val;
> -}
> -
> -static void hisi_thermal_enable_bind_irq_sensor
> - (struct hisi_thermal_data *data)
> -{
> - struct hisi_thermal_sensor *sensor;
> -
> - mutex_lock(>thermal_lock);
> -
> - sensor = >sensors;
> -
> - /* setting the hdak time */
> - hisi_thermal_hdak_set(data->regs, 0);
> -
> - /* disable module firstly */
> - 

Re: [RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables

2017-09-01 Thread Andy Lutomirski
On Fri, Sep 1, 2017 at 3:52 PM, Brijesh Singh  wrote:
> Hi Boris,
>
> On 08/30/2017 12:46 PM, Borislav Petkov wrote:
>>
>> On Wed, Aug 30, 2017 at 11:18:42AM -0500, Brijesh Singh wrote:
>>>
>>> I was trying to avoid mixing early and no-early set_memory_decrypted()
>>> but if
>>> feedback is: use early_set_memory_decrypted() only if its required
>>> otherwise
>>> use set_memory_decrypted() then I can improve the logic in next rev.
>>> thanks
>>
>>
>> Yes, I think you should use the early versions when you're, well,
>> *early* :-) But get rid of that for_each_possible_cpu() and do it only
>> on the current CPU, as this is a per-CPU path anyway. If you need to
>> do it on *every* CPU and very early, then you need a separate function
>> which is called in kvm_smp_prepare_boot_cpu() as there you're pre-SMP.
>>
>
> I am trying to implement your feedback and now remember why I choose to
> use early_set_memory_decrypted() and for_each_possible_cpu loop. These
> percpu variables are static. Hence before clearing the C-bit we must
> perform the in-place decryption so that original assignment is preserved
> after we change the C-bit. Tom's SME patch [1] added sme_early_decrypt()
> -- which can be used to perform the in-place decryption but we do not have
> similar routine for non-early cases. In order to address your feedback,
> we have to add similar functions. So far, we have not seen the need for
> having such functions except this cases. The approach we have right now
> works just fine and not sure if its worth adding new functions.
>
> Thoughts ?
>
> [1] Commit :7f8b7e7 x86/mm: Add support for early encryption/decryption of
> memory

Shouldn't this be called DEFINE_PER_CPU_UNENCRYPTED?  ISTM the "HV
shared" bit is incidental.


Re: [RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables

2017-09-01 Thread Andy Lutomirski
On Fri, Sep 1, 2017 at 3:52 PM, Brijesh Singh  wrote:
> Hi Boris,
>
> On 08/30/2017 12:46 PM, Borislav Petkov wrote:
>>
>> On Wed, Aug 30, 2017 at 11:18:42AM -0500, Brijesh Singh wrote:
>>>
>>> I was trying to avoid mixing early and no-early set_memory_decrypted()
>>> but if
>>> feedback is: use early_set_memory_decrypted() only if its required
>>> otherwise
>>> use set_memory_decrypted() then I can improve the logic in next rev.
>>> thanks
>>
>>
>> Yes, I think you should use the early versions when you're, well,
>> *early* :-) But get rid of that for_each_possible_cpu() and do it only
>> on the current CPU, as this is a per-CPU path anyway. If you need to
>> do it on *every* CPU and very early, then you need a separate function
>> which is called in kvm_smp_prepare_boot_cpu() as there you're pre-SMP.
>>
>
> I am trying to implement your feedback and now remember why I choose to
> use early_set_memory_decrypted() and for_each_possible_cpu loop. These
> percpu variables are static. Hence before clearing the C-bit we must
> perform the in-place decryption so that original assignment is preserved
> after we change the C-bit. Tom's SME patch [1] added sme_early_decrypt()
> -- which can be used to perform the in-place decryption but we do not have
> similar routine for non-early cases. In order to address your feedback,
> we have to add similar functions. So far, we have not seen the need for
> having such functions except this cases. The approach we have right now
> works just fine and not sure if its worth adding new functions.
>
> Thoughts ?
>
> [1] Commit :7f8b7e7 x86/mm: Add support for early encryption/decryption of
> memory

Shouldn't this be called DEFINE_PER_CPU_UNENCRYPTED?  ISTM the "HV
shared" bit is incidental.


Re: [PATCH] locking/refcounts, x86/asm: Use unique .text section for refcount exceptions

2017-09-01 Thread Kees Cook
On Fri, Sep 1, 2017 at 2:43 PM, Ard Biesheuvel
 wrote:
> On 1 September 2017 at 21:22, Kees Cook  wrote:
>> Using .text.unlikely for refcount exceptions isn't safe because gcc may
>> move entire functions into .text.unlikely (e.g. in6_dev_get()), which
>> would cause any uses of a protected refcount_t function to stay inline
>> with the function, triggering the protection unconditionally:
>>
>> .section.text.unlikely,"ax",@progbits
>> .type   in6_dev_get, @function
>> in6_dev_getx:
>> .LFB4673:
>> .loc 2 4128 0
>> .cfi_startproc
>> ...
>> lock; incl 480(%rbx)
>> js 111f
>> .pushsection .text.unlikely
>> 111:lea 480(%rbx), %rcx
>> 112:.byte 0x0f, 0xff
>> .popsection
>> 113:
>>
>> This creates a unique .text section and adds an additional test to the
>> exception handler to WARN in the case of having none of OF, SF, nor ZF
>> set so we can see things like this more easily in the future.
>>
>> Reported-by: Mike Galbraith 
>> Fixes: 7a46ec0e2f48 ("locking/refcounts, x86/asm: Implement fast refcount 
>> overflow protection")
>> Signed-off-by: Kees Cook 
>> ---
>>  arch/x86/Kconfig  | 2 +-
>>  arch/x86/include/asm/refcount.h   | 2 +-
>>  arch/x86/mm/extable.c | 7 ++-
>>  include/asm-generic/vmlinux.lds.h | 1 +
>>  4 files changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index eaa8ff41f424..c6acdcdb3fc6 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -56,7 +56,7 @@ config X86
>> select ARCH_HAS_MMIO_FLUSH
>> select ARCH_HAS_PMEM_APIif X86_64
>> # Causing hangs/crashes, see the commit that added this change for 
>> details.
>> -   select ARCH_HAS_REFCOUNTif BROKEN
>> +   select ARCH_HAS_REFCOUNT
>> select ARCH_HAS_UACCESS_FLUSHCACHE  if X86_64
>> select ARCH_HAS_SET_MEMORY
>> select ARCH_HAS_SG_CHAIN
>> diff --git a/arch/x86/include/asm/refcount.h 
>> b/arch/x86/include/asm/refcount.h
>> index ff871210b9f2..4e44250e7d0d 100644
>> --- a/arch/x86/include/asm/refcount.h
>> +++ b/arch/x86/include/asm/refcount.h
>> @@ -15,7 +15,7 @@
>>   * back to the regular execution flow in .text.
>>   */
>>  #define _REFCOUNT_EXCEPTION\
>> -   ".pushsection .text.unlikely\n" \
>> +   ".pushsection .text..refcount\n"\
>
> You could also use a .subsection here: those are always emitted out of
> line, but into the same section.

I considered it (especially after looking to see how you handled it in
the arm64 port) but decided against it in favor of collecting them all
at the end with .text.unlikely.

-Kees

-- 
Kees Cook
Pixel Security


Re: [PATCH] locking/refcounts, x86/asm: Use unique .text section for refcount exceptions

2017-09-01 Thread Kees Cook
On Fri, Sep 1, 2017 at 2:43 PM, Ard Biesheuvel
 wrote:
> On 1 September 2017 at 21:22, Kees Cook  wrote:
>> Using .text.unlikely for refcount exceptions isn't safe because gcc may
>> move entire functions into .text.unlikely (e.g. in6_dev_get()), which
>> would cause any uses of a protected refcount_t function to stay inline
>> with the function, triggering the protection unconditionally:
>>
>> .section.text.unlikely,"ax",@progbits
>> .type   in6_dev_get, @function
>> in6_dev_getx:
>> .LFB4673:
>> .loc 2 4128 0
>> .cfi_startproc
>> ...
>> lock; incl 480(%rbx)
>> js 111f
>> .pushsection .text.unlikely
>> 111:lea 480(%rbx), %rcx
>> 112:.byte 0x0f, 0xff
>> .popsection
>> 113:
>>
>> This creates a unique .text section and adds an additional test to the
>> exception handler to WARN in the case of having none of OF, SF, nor ZF
>> set so we can see things like this more easily in the future.
>>
>> Reported-by: Mike Galbraith 
>> Fixes: 7a46ec0e2f48 ("locking/refcounts, x86/asm: Implement fast refcount 
>> overflow protection")
>> Signed-off-by: Kees Cook 
>> ---
>>  arch/x86/Kconfig  | 2 +-
>>  arch/x86/include/asm/refcount.h   | 2 +-
>>  arch/x86/mm/extable.c | 7 ++-
>>  include/asm-generic/vmlinux.lds.h | 1 +
>>  4 files changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index eaa8ff41f424..c6acdcdb3fc6 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -56,7 +56,7 @@ config X86
>> select ARCH_HAS_MMIO_FLUSH
>> select ARCH_HAS_PMEM_APIif X86_64
>> # Causing hangs/crashes, see the commit that added this change for 
>> details.
>> -   select ARCH_HAS_REFCOUNTif BROKEN
>> +   select ARCH_HAS_REFCOUNT
>> select ARCH_HAS_UACCESS_FLUSHCACHE  if X86_64
>> select ARCH_HAS_SET_MEMORY
>> select ARCH_HAS_SG_CHAIN
>> diff --git a/arch/x86/include/asm/refcount.h 
>> b/arch/x86/include/asm/refcount.h
>> index ff871210b9f2..4e44250e7d0d 100644
>> --- a/arch/x86/include/asm/refcount.h
>> +++ b/arch/x86/include/asm/refcount.h
>> @@ -15,7 +15,7 @@
>>   * back to the regular execution flow in .text.
>>   */
>>  #define _REFCOUNT_EXCEPTION\
>> -   ".pushsection .text.unlikely\n" \
>> +   ".pushsection .text..refcount\n"\
>
> You could also use a .subsection here: those are always emitted out of
> line, but into the same section.

I considered it (especially after looking to see how you handled it in
the arm64 port) but decided against it in favor of collecting them all
at the end with .text.unlikely.

-Kees

-- 
Kees Cook
Pixel Security


Re: [PATCH 08/13] thermal/drivers/hisi: Fix configuration register setting

2017-09-01 Thread Leo Yan
On Wed, Aug 30, 2017 at 10:47:32AM +0200, Daniel Lezcano wrote:
> The TEMP0_CFG configuration register contains different field to set up the
> temperature controller. However in the code, nothing prevents a setup to
> overwrite the previous one: eg. writing the hdak value overwrites the sensor
> selection, the sensor selection overwrites the hdak value.
> 
> In order to prevent such thing, use a regmap-like mechanism by reading the
> value before, set the corresponding bits and write the result.
> 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/thermal/hisi_thermal.c | 30 +-
>  1 file changed, 25 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index d77a938..3e03908 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -132,19 +132,39 @@ static inline void hisi_thermal_enable(void __iomem 
> *addr, int value)
>   writel(value, addr + TEMP0_EN);
>  }
>  
> -static inline void hisi_thermal_sensor_select(void __iomem *addr, int sensor)
> +static inline int hisi_thermal_get_temperature(void __iomem *addr)
>  {
> - writel((sensor << 12), addr + TEMP0_CFG);
> + return hisi_thermal_step_to_temp(readl(addr + TEMP0_VALUE));
>  }
>  
> -static inline int hisi_thermal_get_temperature(void __iomem *addr)
> +/*
> + * Temperature configuration register - Sensor selection
> + *
> + * Bits [19:12]
> + *
> + * 0x0: local sensor (default)
> + * 0x1: remote sensor 1 (ACPU cluster 1)
> + * 0x2: remote sensor 2 (ACPU cluster 0)
> + * 0x3: remote sensor 3 (G3D)
> + */
> +static inline void hisi_thermal_sensor_select(void __iomem *addr, int sensor)
>  {
> - return hisi_thermal_step_to_temp(readl(addr + TEMP0_VALUE));
> + writel(readl(addr + TEMP0_CFG) | (sensor << 12), addr + TEMP0_CFG);

nitpick: maybe it's better to firstly clear related bits and then set
value?

>  }
>  
> +/*
> + * Temperature configuration register - Hdak conversion polling interval
> + *
> + * Bits [5:4]
> + *
> + * 0x0 :   0.768 ms
> + * 0x1 :   6.144 ms
> + * 0x2 :  49.152 ms
> + * 0x3 : 393.216 ms
> + */
>  static inline void hisi_thermal_hdak_set(void __iomem *addr, int value)
>  {
> - writel(value, addr + TEMP0_CFG);
> + writel(readl(addr + TEMP0_CFG) | (value << 4), addr + TEMP0_CFG);

Ditto.

>  }
>  
>  static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data *data,
> -- 
> 2.7.4
> 


Re: [PATCH 08/13] thermal/drivers/hisi: Fix configuration register setting

2017-09-01 Thread Leo Yan
On Wed, Aug 30, 2017 at 10:47:32AM +0200, Daniel Lezcano wrote:
> The TEMP0_CFG configuration register contains different field to set up the
> temperature controller. However in the code, nothing prevents a setup to
> overwrite the previous one: eg. writing the hdak value overwrites the sensor
> selection, the sensor selection overwrites the hdak value.
> 
> In order to prevent such thing, use a regmap-like mechanism by reading the
> value before, set the corresponding bits and write the result.
> 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/thermal/hisi_thermal.c | 30 +-
>  1 file changed, 25 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index d77a938..3e03908 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -132,19 +132,39 @@ static inline void hisi_thermal_enable(void __iomem 
> *addr, int value)
>   writel(value, addr + TEMP0_EN);
>  }
>  
> -static inline void hisi_thermal_sensor_select(void __iomem *addr, int sensor)
> +static inline int hisi_thermal_get_temperature(void __iomem *addr)
>  {
> - writel((sensor << 12), addr + TEMP0_CFG);
> + return hisi_thermal_step_to_temp(readl(addr + TEMP0_VALUE));
>  }
>  
> -static inline int hisi_thermal_get_temperature(void __iomem *addr)
> +/*
> + * Temperature configuration register - Sensor selection
> + *
> + * Bits [19:12]
> + *
> + * 0x0: local sensor (default)
> + * 0x1: remote sensor 1 (ACPU cluster 1)
> + * 0x2: remote sensor 2 (ACPU cluster 0)
> + * 0x3: remote sensor 3 (G3D)
> + */
> +static inline void hisi_thermal_sensor_select(void __iomem *addr, int sensor)
>  {
> - return hisi_thermal_step_to_temp(readl(addr + TEMP0_VALUE));
> + writel(readl(addr + TEMP0_CFG) | (sensor << 12), addr + TEMP0_CFG);

nitpick: maybe it's better to firstly clear related bits and then set
value?

>  }
>  
> +/*
> + * Temperature configuration register - Hdak conversion polling interval
> + *
> + * Bits [5:4]
> + *
> + * 0x0 :   0.768 ms
> + * 0x1 :   6.144 ms
> + * 0x2 :  49.152 ms
> + * 0x3 : 393.216 ms
> + */
>  static inline void hisi_thermal_hdak_set(void __iomem *addr, int value)
>  {
> - writel(value, addr + TEMP0_CFG);
> + writel(readl(addr + TEMP0_CFG) | (value << 4), addr + TEMP0_CFG);

Ditto.

>  }
>  
>  static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data *data,
> -- 
> 2.7.4
> 


Re: [PATCH 07/13] thermal/drivers/hisi: Encapsulate register writes into helpers

2017-09-01 Thread Leo Yan
On Sat, Sep 02, 2017 at 10:09:15AM +0800, Leo Yan wrote:
> On Wed, Aug 30, 2017 at 10:47:31AM +0200, Daniel Lezcano wrote:
> > Hopefully, the function name can help to clarify the semantic of the 
> > operations
> > when writing in the register.
> > 
> > Signed-off-by: Daniel Lezcano 
> > ---
> >  drivers/thermal/hisi_thermal.c | 96 
> > +++---
> >  1 file changed, 72 insertions(+), 24 deletions(-)
> > 
> > diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> > index 6f0dab1..d77a938 100644
> > --- a/drivers/thermal/hisi_thermal.c
> > +++ b/drivers/thermal/hisi_thermal.c
> > @@ -26,6 +26,7 @@
> >  
> >  #include "thermal_core.h"
> >  
> > +#define TEMP0_LAG  (0x0)
> >  #define TEMP0_TH   (0x4)
> >  #define TEMP0_RST_TH   (0x8)
> >  #define TEMP0_CFG  (0xC)
> > @@ -96,6 +97,56 @@ static inline long hisi_thermal_round_temp(int temp)
> > hisi_thermal_temp_to_step(temp));
> >  }
> >  
> > +static inline void hisi_thermal_set_lag(void __iomem *addr, int value)
> > +{
> > +   writel(value, addr + TEMP0_LAG);
> > +}
> > +
> > +static inline void hisi_thermal_alarm_clear(void __iomem *addr, int value)
> > +{
> > +   writel(value, addr + TEMP0_INT_CLR);
> > +}
> > +
> > +static inline void hisi_thermal_alarm_enable(void __iomem *addr, int value)
> > +{
> > +   writel(value, addr + TEMP0_INT_EN);
> > +}
> > +
> > +static inline void hisi_thermal_alarm_set(void __iomem *addr, int temp)
> > +{
> > +   writel(hisi_thermal_temp_to_step(temp) | 0x0FF00, addr + TEMP0_TH);
> > +}
> > +
> > +static inline void hisi_thermal_reset_set(void __iomem *addr, int temp)
> > +{
> > +writel(hisi_thermal_temp_to_step(temp), addr + TEMP0_RST_TH);
> > +}
> > +
> > +static inline void hisi_thermal_reset_enable(void __iomem *addr, int value)
> > +{
> > +writel(value, addr + TEMP0_RST_MSK);
> > +}
> > +
> > +static inline void hisi_thermal_enable(void __iomem *addr, int value)
> > +{
> > +   writel(value, addr + TEMP0_EN);
> > +}
> > +
> > +static inline void hisi_thermal_sensor_select(void __iomem *addr, int 
> > sensor)
> > +{
> > +   writel((sensor << 12), addr + TEMP0_CFG);
> > +}
> > +
> > +static inline int hisi_thermal_get_temperature(void __iomem *addr)
> > +{
> > +   return hisi_thermal_step_to_temp(readl(addr + TEMP0_VALUE));
> > +}
> > +
> > +static inline void hisi_thermal_hdak_set(void __iomem *addr, int value)
> > +{
> > +   writel(value, addr + TEMP0_CFG);
> > +}
> 
> hdak and sensor id setting share the same one register, so it's
> possible to overwrite their value with each other. And for hdak
> setting, it should offset 4 bits.
> 
> The issues are exists in old code yet but not introduce by this
> patch. Could fix these issues as well in this patch?

Have seen the mentioned issues have been fixed in patch 0008. So have
no more question at here.

[...]

Thanks,
Leo Yan


Re: [PATCH 07/13] thermal/drivers/hisi: Encapsulate register writes into helpers

2017-09-01 Thread Leo Yan
On Sat, Sep 02, 2017 at 10:09:15AM +0800, Leo Yan wrote:
> On Wed, Aug 30, 2017 at 10:47:31AM +0200, Daniel Lezcano wrote:
> > Hopefully, the function name can help to clarify the semantic of the 
> > operations
> > when writing in the register.
> > 
> > Signed-off-by: Daniel Lezcano 
> > ---
> >  drivers/thermal/hisi_thermal.c | 96 
> > +++---
> >  1 file changed, 72 insertions(+), 24 deletions(-)
> > 
> > diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> > index 6f0dab1..d77a938 100644
> > --- a/drivers/thermal/hisi_thermal.c
> > +++ b/drivers/thermal/hisi_thermal.c
> > @@ -26,6 +26,7 @@
> >  
> >  #include "thermal_core.h"
> >  
> > +#define TEMP0_LAG  (0x0)
> >  #define TEMP0_TH   (0x4)
> >  #define TEMP0_RST_TH   (0x8)
> >  #define TEMP0_CFG  (0xC)
> > @@ -96,6 +97,56 @@ static inline long hisi_thermal_round_temp(int temp)
> > hisi_thermal_temp_to_step(temp));
> >  }
> >  
> > +static inline void hisi_thermal_set_lag(void __iomem *addr, int value)
> > +{
> > +   writel(value, addr + TEMP0_LAG);
> > +}
> > +
> > +static inline void hisi_thermal_alarm_clear(void __iomem *addr, int value)
> > +{
> > +   writel(value, addr + TEMP0_INT_CLR);
> > +}
> > +
> > +static inline void hisi_thermal_alarm_enable(void __iomem *addr, int value)
> > +{
> > +   writel(value, addr + TEMP0_INT_EN);
> > +}
> > +
> > +static inline void hisi_thermal_alarm_set(void __iomem *addr, int temp)
> > +{
> > +   writel(hisi_thermal_temp_to_step(temp) | 0x0FF00, addr + TEMP0_TH);
> > +}
> > +
> > +static inline void hisi_thermal_reset_set(void __iomem *addr, int temp)
> > +{
> > +writel(hisi_thermal_temp_to_step(temp), addr + TEMP0_RST_TH);
> > +}
> > +
> > +static inline void hisi_thermal_reset_enable(void __iomem *addr, int value)
> > +{
> > +writel(value, addr + TEMP0_RST_MSK);
> > +}
> > +
> > +static inline void hisi_thermal_enable(void __iomem *addr, int value)
> > +{
> > +   writel(value, addr + TEMP0_EN);
> > +}
> > +
> > +static inline void hisi_thermal_sensor_select(void __iomem *addr, int 
> > sensor)
> > +{
> > +   writel((sensor << 12), addr + TEMP0_CFG);
> > +}
> > +
> > +static inline int hisi_thermal_get_temperature(void __iomem *addr)
> > +{
> > +   return hisi_thermal_step_to_temp(readl(addr + TEMP0_VALUE));
> > +}
> > +
> > +static inline void hisi_thermal_hdak_set(void __iomem *addr, int value)
> > +{
> > +   writel(value, addr + TEMP0_CFG);
> > +}
> 
> hdak and sensor id setting share the same one register, so it's
> possible to overwrite their value with each other. And for hdak
> setting, it should offset 4 bits.
> 
> The issues are exists in old code yet but not introduce by this
> patch. Could fix these issues as well in this patch?

Have seen the mentioned issues have been fixed in patch 0008. So have
no more question at here.

[...]

Thanks,
Leo Yan


Re: RFC: Revert move default dialect from CIFS to to SMB3

2017-09-01 Thread Steve French
On Fri, Sep 1, 2017 at 2:45 PM, Linus Torvalds
 wrote:
> On Fri, Sep 1, 2017 at 11:23 AM, L. A. Walsh  wrote:
>>Why be incompatible with the majority of Windows installations?
>> I.e.  If you really want to up security from 1.0 (not adverse to that),
>> then why not go to 2.1 as used by Win7?  Win7 is still in support
>> from MS -- and they haven't indicated a need to upgrade to 3.x for
>> security reasons.  3.x may have new security features, no argument, but
>> that doesn't mean 2.1, is insecure.
>
> I'm certainly ok with changing the default to 2.1 if that helps people.
>
> Is that actually likely to help the people who now see problems with
> the existing 3.0 default?
>
> I don't know the exact security issue details with cifs, but I _think_
> it was explicitly _only_ smb-1.0, right?

The default was SMB1 (CIFS) and was recently changed to SMB3.
The dialect still can be overridden by specifying "vers=1.0" or "vers=2.1"
etc. on mount.

We just put together a patch to better explain the default changes
(with additional warning messages) as suggested.

SMB3 is significantly better than SMB2.1 (supporting encrypted shares
and sessions for example, and requiring support for "secure negotiate")
and some servers require SMB3 minimum as a result, but it was agreed
at the last test event to eventually support multi-dialect negotiation (for
which SMB2.1 e.g. Windows 7, would be the oldest and least secure
dialect we would support) but in this interim stage we had to pick one,
and the improvements in SMB3 (over SMB2.1) tipped the balance.

In 4.14 we will likely have the ability to more securely do multi-dialect
negotiation, and this issue of SMB2.1 vs. SMB3 will be moot as the
server will choose its most recent dialect.


-- 
Thanks,

Steve


Re: RFC: Revert move default dialect from CIFS to to SMB3

2017-09-01 Thread Steve French
On Fri, Sep 1, 2017 at 2:45 PM, Linus Torvalds
 wrote:
> On Fri, Sep 1, 2017 at 11:23 AM, L. A. Walsh  wrote:
>>Why be incompatible with the majority of Windows installations?
>> I.e.  If you really want to up security from 1.0 (not adverse to that),
>> then why not go to 2.1 as used by Win7?  Win7 is still in support
>> from MS -- and they haven't indicated a need to upgrade to 3.x for
>> security reasons.  3.x may have new security features, no argument, but
>> that doesn't mean 2.1, is insecure.
>
> I'm certainly ok with changing the default to 2.1 if that helps people.
>
> Is that actually likely to help the people who now see problems with
> the existing 3.0 default?
>
> I don't know the exact security issue details with cifs, but I _think_
> it was explicitly _only_ smb-1.0, right?

The default was SMB1 (CIFS) and was recently changed to SMB3.
The dialect still can be overridden by specifying "vers=1.0" or "vers=2.1"
etc. on mount.

We just put together a patch to better explain the default changes
(with additional warning messages) as suggested.

SMB3 is significantly better than SMB2.1 (supporting encrypted shares
and sessions for example, and requiring support for "secure negotiate")
and some servers require SMB3 minimum as a result, but it was agreed
at the last test event to eventually support multi-dialect negotiation (for
which SMB2.1 e.g. Windows 7, would be the oldest and least secure
dialect we would support) but in this interim stage we had to pick one,
and the improvements in SMB3 (over SMB2.1) tipped the balance.

In 4.14 we will likely have the ability to more securely do multi-dialect
negotiation, and this issue of SMB2.1 vs. SMB3 will be moot as the
server will choose its most recent dialect.


-- 
Thanks,

Steve


Re: [PATCH v3 2/5] dt-bindings: input: Add document bindings for mtk-pmic-keys

2017-09-01 Thread Chen Zhong
On Thu, 2017-08-31 at 14:52 -0500, Rob Herring wrote:
> On Fri, Aug 25, 2017 at 02:32:30PM +0800, Chen Zhong wrote:
> > This patch adds the device tree binding documentation for the MediaTek
> > pmic keys found on PMIC MT6397/MT6323.
> > 
> > Signed-off-by: Chen Zhong 
> > ---
> >  .../devicetree/bindings/input/mtk-pmic-keys.txt|   38 
> > 
> >  1 file changed, 38 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/input/mtk-pmic-keys.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt 
> > b/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt
> > new file mode 100644
> > index 000..100ec44
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt
> > @@ -0,0 +1,38 @@
> > +MediaTek MT6397/MT6323 PMIC Keys Device Driver
> > +
> > +There are two key functions provided by MT6397/MT6323 PMIC, pwrkey
> > +and homekey. The key functions are defined as the subnode of the function
> > +node provided by MT6397/MT6323 PMIC that is being defined as one kind
> > +of Muti-Function Device (MFD)
> > +
> > +For MT6397/MT6323 MFD bindings see:
> > +Documentation/devicetree/bindings/mfd/mt6397.txt
> > +
> > +Required properties:
> > +- compatible: "mediatek,mt6397-keys" or "mediatek,mt6323-keys"
> > +- linux,keycodes: Specifies the numeric keycode values to
> > +   be used for reporting keys presses. The array can
> > +   contain up to 2 entries.
> > +
> > +Optional Properties:
> > +- wakeup-source: each key can be used as a wakeup source.
> 
> wakeup-source is defined as a boolean.

Hi Rob,

Could I modify it as this?

mediatek,wakeup-keys = <1>, <0>;
wakeup-source;

Thanks.
> 
> > +- mediatek,long-press-mode: Long press key shutdown setting, 1 for
> > +   pwrkey only, 2 for pwrkey/homekey together, others for disabled.
> > +- debounce-interval: Long press key shutdown debouncing interval time
> > +   in seconds. 0/1/2/3 for 8/11/14/5 seconds. If not specified defaults to 
> > 0.
> > +
> > +Example:
> > +
> > +   pmic: mt6397 {
> > +   compatible = "mediatek,mt6397";
> > +
> > +   ...
> > +
> > +   mt6397keys: mt6397keys {
> > +   compatible = "mediatek,mt6397-keys";
> > +   linux,keycodes = , ;
> > +   wakeup-source = <1>, <0>;
> > +   mediatek,long-press-mode = <1>;
> > +   debounce-interval = <0>;
> > +   };
> > +   };
> > -- 
> > 1.7.9.5
> > 




Re: [PATCH V5 0/4] Add Broadcom STB USB phy driver

2017-09-01 Thread Florian Fainelli


On 08/25/2017 10:51 AM, Al Cooper wrote:
> Add a new USB Phy driver for Broadcom STB SoCs. This driver
> supports Broadcom STB ARM SoCs. This driver in
> combination with the Broadcom STB ohci, ehci and xhci
> drivers will enable USB1.1, USB2.0 and USB3.0 support.
> This Phy driver also supports the Broadcom BDC gadget
> driver.

Thanks Al! Kishon, feel free to merge everything through your tree there
should not be any conflicts with drivers/soc/bcm/brcmstb/common.c and
include/linux/soc/brcmstb/brcmstb.h.

> 
> Changes since v4:
> - MIPS support was dropped, so remove MIPS specific code
>   in the brcmusb_readl/brcmusb_writel routines.
> - Use readl/writel instead of readl_relaxed/writel_relaxed.
> - Remove double blank lines between some functions.
> - Remove support for obselete phy phandle argument.
> 
> Changes since v3:
> - Removed MIPS support because there is such a small
>   amount of code that is common to both ARM and MIPS.
>   I'll create a separate MIPS driver in the future.
> - Have the Kconfig selection for this driver also select
>   "CONFIG_SOC_BRCMSTB" which contains needed functions.
> - Change device tree properties to use "brcm,has_xhci" and
>   "brcm,has_eohci" to determine if the phy contains
>   a xhci phy, and e/ohci phy or both.
> - Change the phy xlate routine to return an error instead
>   of NULL for a requested phy that doesn't exist.
> - Moved some probe functionality into it's own funtion to
>   simplify the many "if (has_xhci)" statements.
> 
> Changes since v2:
> - Fix kbuild errors by changing Kconfig so the driver
>   only builds for ARCH_BRCMSTB || BMIPS_GENERIC systems
> 
> Changes since v1:
> - Rebased to next
> - Add Kconfig entry to build the driver
> - Commented all delays
> - Split out sysfs functionality in separate patch
> - Removed parsing of old obselete device tree properties
> - Changed device property "device" to "dr_mode" using
>   standard values "host" and "peripheral" along with new
>   values "drd" and "typec-pd"
> - Add ability to handle the standard PHY_TYPE_USB2 and
>   PHY_TYPE_USB3 arguments passed in by phy consumers.
> - Moved phy_provider_register() to end of probe routine
> 
> Al Cooper (4):
>   soc: brcmstb: Add Product ID and Family ID helper functions
>   dt-bindings: Add Broadcom STB USB PHY binding document
>   phy: usb: phy-brcm-usb: Add Broadcom STB USB phy driver
>   phy: usb: phy-brcm-usb: Add ability to force DRD mode to host or
> device
> 
>  .../bindings/phy/brcm,brcmstb-usb-phy.txt  |   43 +
>  MAINTAINERS|7 +
>  drivers/phy/broadcom/Kconfig   |   13 +
>  drivers/phy/broadcom/Makefile  |3 +
>  drivers/phy/broadcom/phy-brcm-usb-init.c   | 1007 
> 
>  drivers/phy/broadcom/phy-brcm-usb-init.h   |   50 +
>  drivers/phy/broadcom/phy-brcm-usb.c|  458 +
>  drivers/soc/bcm/brcmstb/common.c   |   12 +
>  include/linux/soc/brcmstb/brcmstb.h|   10 +
>  9 files changed, 1603 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
>  create mode 100644 drivers/phy/broadcom/phy-brcm-usb-init.c
>  create mode 100644 drivers/phy/broadcom/phy-brcm-usb-init.h
>  create mode 100644 drivers/phy/broadcom/phy-brcm-usb.c
> 

-- 
Florian


Re: [PATCH v3 2/5] dt-bindings: input: Add document bindings for mtk-pmic-keys

2017-09-01 Thread Chen Zhong
On Thu, 2017-08-31 at 14:52 -0500, Rob Herring wrote:
> On Fri, Aug 25, 2017 at 02:32:30PM +0800, Chen Zhong wrote:
> > This patch adds the device tree binding documentation for the MediaTek
> > pmic keys found on PMIC MT6397/MT6323.
> > 
> > Signed-off-by: Chen Zhong 
> > ---
> >  .../devicetree/bindings/input/mtk-pmic-keys.txt|   38 
> > 
> >  1 file changed, 38 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/input/mtk-pmic-keys.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt 
> > b/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt
> > new file mode 100644
> > index 000..100ec44
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt
> > @@ -0,0 +1,38 @@
> > +MediaTek MT6397/MT6323 PMIC Keys Device Driver
> > +
> > +There are two key functions provided by MT6397/MT6323 PMIC, pwrkey
> > +and homekey. The key functions are defined as the subnode of the function
> > +node provided by MT6397/MT6323 PMIC that is being defined as one kind
> > +of Muti-Function Device (MFD)
> > +
> > +For MT6397/MT6323 MFD bindings see:
> > +Documentation/devicetree/bindings/mfd/mt6397.txt
> > +
> > +Required properties:
> > +- compatible: "mediatek,mt6397-keys" or "mediatek,mt6323-keys"
> > +- linux,keycodes: Specifies the numeric keycode values to
> > +   be used for reporting keys presses. The array can
> > +   contain up to 2 entries.
> > +
> > +Optional Properties:
> > +- wakeup-source: each key can be used as a wakeup source.
> 
> wakeup-source is defined as a boolean.

Hi Rob,

Could I modify it as this?

mediatek,wakeup-keys = <1>, <0>;
wakeup-source;

Thanks.
> 
> > +- mediatek,long-press-mode: Long press key shutdown setting, 1 for
> > +   pwrkey only, 2 for pwrkey/homekey together, others for disabled.
> > +- debounce-interval: Long press key shutdown debouncing interval time
> > +   in seconds. 0/1/2/3 for 8/11/14/5 seconds. If not specified defaults to 
> > 0.
> > +
> > +Example:
> > +
> > +   pmic: mt6397 {
> > +   compatible = "mediatek,mt6397";
> > +
> > +   ...
> > +
> > +   mt6397keys: mt6397keys {
> > +   compatible = "mediatek,mt6397-keys";
> > +   linux,keycodes = , ;
> > +   wakeup-source = <1>, <0>;
> > +   mediatek,long-press-mode = <1>;
> > +   debounce-interval = <0>;
> > +   };
> > +   };
> > -- 
> > 1.7.9.5
> > 




Re: [PATCH V5 0/4] Add Broadcom STB USB phy driver

2017-09-01 Thread Florian Fainelli


On 08/25/2017 10:51 AM, Al Cooper wrote:
> Add a new USB Phy driver for Broadcom STB SoCs. This driver
> supports Broadcom STB ARM SoCs. This driver in
> combination with the Broadcom STB ohci, ehci and xhci
> drivers will enable USB1.1, USB2.0 and USB3.0 support.
> This Phy driver also supports the Broadcom BDC gadget
> driver.

Thanks Al! Kishon, feel free to merge everything through your tree there
should not be any conflicts with drivers/soc/bcm/brcmstb/common.c and
include/linux/soc/brcmstb/brcmstb.h.

> 
> Changes since v4:
> - MIPS support was dropped, so remove MIPS specific code
>   in the brcmusb_readl/brcmusb_writel routines.
> - Use readl/writel instead of readl_relaxed/writel_relaxed.
> - Remove double blank lines between some functions.
> - Remove support for obselete phy phandle argument.
> 
> Changes since v3:
> - Removed MIPS support because there is such a small
>   amount of code that is common to both ARM and MIPS.
>   I'll create a separate MIPS driver in the future.
> - Have the Kconfig selection for this driver also select
>   "CONFIG_SOC_BRCMSTB" which contains needed functions.
> - Change device tree properties to use "brcm,has_xhci" and
>   "brcm,has_eohci" to determine if the phy contains
>   a xhci phy, and e/ohci phy or both.
> - Change the phy xlate routine to return an error instead
>   of NULL for a requested phy that doesn't exist.
> - Moved some probe functionality into it's own funtion to
>   simplify the many "if (has_xhci)" statements.
> 
> Changes since v2:
> - Fix kbuild errors by changing Kconfig so the driver
>   only builds for ARCH_BRCMSTB || BMIPS_GENERIC systems
> 
> Changes since v1:
> - Rebased to next
> - Add Kconfig entry to build the driver
> - Commented all delays
> - Split out sysfs functionality in separate patch
> - Removed parsing of old obselete device tree properties
> - Changed device property "device" to "dr_mode" using
>   standard values "host" and "peripheral" along with new
>   values "drd" and "typec-pd"
> - Add ability to handle the standard PHY_TYPE_USB2 and
>   PHY_TYPE_USB3 arguments passed in by phy consumers.
> - Moved phy_provider_register() to end of probe routine
> 
> Al Cooper (4):
>   soc: brcmstb: Add Product ID and Family ID helper functions
>   dt-bindings: Add Broadcom STB USB PHY binding document
>   phy: usb: phy-brcm-usb: Add Broadcom STB USB phy driver
>   phy: usb: phy-brcm-usb: Add ability to force DRD mode to host or
> device
> 
>  .../bindings/phy/brcm,brcmstb-usb-phy.txt  |   43 +
>  MAINTAINERS|7 +
>  drivers/phy/broadcom/Kconfig   |   13 +
>  drivers/phy/broadcom/Makefile  |3 +
>  drivers/phy/broadcom/phy-brcm-usb-init.c   | 1007 
> 
>  drivers/phy/broadcom/phy-brcm-usb-init.h   |   50 +
>  drivers/phy/broadcom/phy-brcm-usb.c|  458 +
>  drivers/soc/bcm/brcmstb/common.c   |   12 +
>  include/linux/soc/brcmstb/brcmstb.h|   10 +
>  9 files changed, 1603 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
>  create mode 100644 drivers/phy/broadcom/phy-brcm-usb-init.c
>  create mode 100644 drivers/phy/broadcom/phy-brcm-usb-init.h
>  create mode 100644 drivers/phy/broadcom/phy-brcm-usb.c
> 

-- 
Florian


Re: [PATCH V5 1/4] soc: brcmstb: Add Product ID and Family ID helper functions

2017-09-01 Thread Florian Fainelli


On 08/25/2017 10:51 AM, Al Cooper wrote:
> Signed-off-by: Al Cooper 

Acked-by: Florian Fainelli 

> ---
>  drivers/soc/bcm/brcmstb/common.c| 12 
>  include/linux/soc/brcmstb/brcmstb.h | 10 ++
>  2 files changed, 22 insertions(+)
> 
> diff --git a/drivers/soc/bcm/brcmstb/common.c 
> b/drivers/soc/bcm/brcmstb/common.c
> index b6195fd..184dbf5 100644
> --- a/drivers/soc/bcm/brcmstb/common.c
> +++ b/drivers/soc/bcm/brcmstb/common.c
> @@ -40,6 +40,18 @@ bool soc_is_brcmstb(void)
>   return of_match_node(brcmstb_machine_match, root) != NULL;
>  }
>  
> +u32 brcmstb_get_family_id(void)
> +{
> + return family_id;
> +}
> +EXPORT_SYMBOL(brcmstb_get_family_id);
> +
> +u32 brcmstb_get_product_id(void)
> +{
> + return product_id;
> +}
> +EXPORT_SYMBOL(brcmstb_get_product_id);
> +
>  static const struct of_device_id sun_top_ctrl_match[] = {
>   { .compatible = "brcm,bcm7125-sun-top-ctrl", },
>   { .compatible = "brcm,bcm7346-sun-top-ctrl", },
> diff --git a/include/linux/soc/brcmstb/brcmstb.h 
> b/include/linux/soc/brcmstb/brcmstb.h
> index 337ce41..23e4dc9 100644
> --- a/include/linux/soc/brcmstb/brcmstb.h
> +++ b/include/linux/soc/brcmstb/brcmstb.h
> @@ -1,10 +1,20 @@
>  #ifndef __BRCMSTB_SOC_H
>  #define __BRCMSTB_SOC_H
>  
> +#define BRCM_ID(reg) ((u32)reg >> 28 ? (u32)reg >> 16 : (u32)reg >> 8)
> +#define BRCM_REV(reg)((u32)reg & 0xff)
> +
>  /*
>   * Bus Interface Unit control register setup, must happen early during boot,
>   * before SMP is brought up, called by machine entry point.
>   */
>  void brcmstb_biuctrl_init(void);
>  
> +/*
> + * Helper functions for getting family or product id from the
> + * SoC driver.
> + */
> +u32 brcmstb_get_family_id(void);
> +u32 brcmstb_get_product_id(void);
> +
>  #endif /* __BRCMSTB_SOC_H */
> 

-- 
Florian


Re: [PATCH V5 1/4] soc: brcmstb: Add Product ID and Family ID helper functions

2017-09-01 Thread Florian Fainelli


On 08/25/2017 10:51 AM, Al Cooper wrote:
> Signed-off-by: Al Cooper 

Acked-by: Florian Fainelli 

> ---
>  drivers/soc/bcm/brcmstb/common.c| 12 
>  include/linux/soc/brcmstb/brcmstb.h | 10 ++
>  2 files changed, 22 insertions(+)
> 
> diff --git a/drivers/soc/bcm/brcmstb/common.c 
> b/drivers/soc/bcm/brcmstb/common.c
> index b6195fd..184dbf5 100644
> --- a/drivers/soc/bcm/brcmstb/common.c
> +++ b/drivers/soc/bcm/brcmstb/common.c
> @@ -40,6 +40,18 @@ bool soc_is_brcmstb(void)
>   return of_match_node(brcmstb_machine_match, root) != NULL;
>  }
>  
> +u32 brcmstb_get_family_id(void)
> +{
> + return family_id;
> +}
> +EXPORT_SYMBOL(brcmstb_get_family_id);
> +
> +u32 brcmstb_get_product_id(void)
> +{
> + return product_id;
> +}
> +EXPORT_SYMBOL(brcmstb_get_product_id);
> +
>  static const struct of_device_id sun_top_ctrl_match[] = {
>   { .compatible = "brcm,bcm7125-sun-top-ctrl", },
>   { .compatible = "brcm,bcm7346-sun-top-ctrl", },
> diff --git a/include/linux/soc/brcmstb/brcmstb.h 
> b/include/linux/soc/brcmstb/brcmstb.h
> index 337ce41..23e4dc9 100644
> --- a/include/linux/soc/brcmstb/brcmstb.h
> +++ b/include/linux/soc/brcmstb/brcmstb.h
> @@ -1,10 +1,20 @@
>  #ifndef __BRCMSTB_SOC_H
>  #define __BRCMSTB_SOC_H
>  
> +#define BRCM_ID(reg) ((u32)reg >> 28 ? (u32)reg >> 16 : (u32)reg >> 8)
> +#define BRCM_REV(reg)((u32)reg & 0xff)
> +
>  /*
>   * Bus Interface Unit control register setup, must happen early during boot,
>   * before SMP is brought up, called by machine entry point.
>   */
>  void brcmstb_biuctrl_init(void);
>  
> +/*
> + * Helper functions for getting family or product id from the
> + * SoC driver.
> + */
> +u32 brcmstb_get_family_id(void);
> +u32 brcmstb_get_product_id(void);
> +
>  #endif /* __BRCMSTB_SOC_H */
> 

-- 
Florian


Re: [PATCH 2/2] ARM: dts: Add the PWM node to Cygnus

2017-09-01 Thread Florian Fainelli


On 08/31/2017 01:10 PM, Scott Branden wrote:
> pwm node is correct.
> 
> 
> On 17-08-31 11:54 AM, Eric Anholt wrote:
>> This is connected up to the backlight on 911360_entphn, which we'll
>> need for a panel driver.  For now, leave the node disabled in the
>> shared dtsi.
>>
>> Signed-off-by: Eric Anholt 
> Acked-by: Scott Branden 

Applied to devicetree/next:

https://github.com/Broadcom/stblinux/commit/31807d46f85c4d86ef3b6df9c5a4e69d35f75bc0

>> ---
>>   arch/arm/boot/dts/bcm-cygnus.dtsi | 8 
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
>> b/arch/arm/boot/dts/bcm-cygnus.dtsi
>> index 74f73ff24aec..b9a654d733ae 100644
>> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
>> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
>> @@ -585,6 +585,14 @@
>>   status = "disabled";
>>   };
>>   +pwm: pwm@180aa500 {
>> +compatible = "brcm,kona-pwm";
>> +reg = <0x180aa500 0xc4>;
>> +#pwm-cells = <3>;
>> +clocks = <_clks BCM_CYGNUS_ASIU_PWM_CLK>;
>> +status = "disabled";
>> +};
>> +
>>   keypad: keypad@180ac000 {
>>   compatible = "brcm,bcm-keypad";
>>   reg = <0x180ac000 0x14c>;
> 

-- 
Florian


Re: [PATCH 2/2] ARM: dts: Add the PWM node to Cygnus

2017-09-01 Thread Florian Fainelli


On 08/31/2017 01:10 PM, Scott Branden wrote:
> pwm node is correct.
> 
> 
> On 17-08-31 11:54 AM, Eric Anholt wrote:
>> This is connected up to the backlight on 911360_entphn, which we'll
>> need for a panel driver.  For now, leave the node disabled in the
>> shared dtsi.
>>
>> Signed-off-by: Eric Anholt 
> Acked-by: Scott Branden 

Applied to devicetree/next:

https://github.com/Broadcom/stblinux/commit/31807d46f85c4d86ef3b6df9c5a4e69d35f75bc0

>> ---
>>   arch/arm/boot/dts/bcm-cygnus.dtsi | 8 
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
>> b/arch/arm/boot/dts/bcm-cygnus.dtsi
>> index 74f73ff24aec..b9a654d733ae 100644
>> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
>> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
>> @@ -585,6 +585,14 @@
>>   status = "disabled";
>>   };
>>   +pwm: pwm@180aa500 {
>> +compatible = "brcm,kona-pwm";
>> +reg = <0x180aa500 0xc4>;
>> +#pwm-cells = <3>;
>> +clocks = <_clks BCM_CYGNUS_ASIU_PWM_CLK>;
>> +status = "disabled";
>> +};
>> +
>>   keypad: keypad@180ac000 {
>>   compatible = "brcm,bcm-keypad";
>>   reg = <0x180ac000 0x14c>;
> 

-- 
Florian


Re: [PATCH 1/2] ARM: dts: Add the CLCD controller to Cygnus.

2017-09-01 Thread Florian Fainelli


On 08/31/2017 01:16 PM, Scott Branden wrote:
> Hi Eric,
> 
> mode is correct, location in file needs to be moved.
> 
> 
> On 17-08-31 11:54 AM, Eric Anholt wrote:
>> This doesn't yet enable it on any particular platform, as we still
>> need a panel driver for bcm911360_entphn.
>>
>> Signed-off-by: Eric Anholt 
>> ---
>>
>> These bits are just carving off a little bit of my 911360_entphn panel
>> series, to reduce conflicts when rebasing (which I just did for
>> testing pl111 changes for cygnus regressions).  I'm waiting to get my
>> current RPi panel driver in before working on the 911360 panel again.
>>
>>   arch/arm/boot/dts/bcm-cygnus.dtsi | 10 ++
>>   1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
>> b/arch/arm/boot/dts/bcm-cygnus.dtsi
>> index 7c957ea06c66..74f73ff24aec 100644
>> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
>> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
>> @@ -575,6 +575,16 @@
>>   status = "disabled";
>>   };
>>   +clcd: clcd@180a {
> please place in correct address ordered location in file

I moved it right above the v3d node to keep the nodes ordered by unit
address, please check the result here:

https://github.com/Broadcom/stblinux/commit/4d1e42c6b9d28ce7b74d92258435f9d16834ae75

>> +compatible = "arm,pl111", "arm,primecell";
>> +reg = <0x180a 0x1000>;
>> +interrupts = ;
>> +interrupt-names = "combined";
>> +clocks = <_clk>, <_clk>;
>> +clock-names = "clcdclk", "apb_pclk";
>> +status = "disabled";
>> +};
>> +
>>   keypad: keypad@180ac000 {
>>   compatible = "brcm,bcm-keypad";
>>   reg = <0x180ac000 0x14c>;
> 

-- 
Florian


Re: [PATCH 1/2] ARM: dts: Add the CLCD controller to Cygnus.

2017-09-01 Thread Florian Fainelli


On 08/31/2017 01:16 PM, Scott Branden wrote:
> Hi Eric,
> 
> mode is correct, location in file needs to be moved.
> 
> 
> On 17-08-31 11:54 AM, Eric Anholt wrote:
>> This doesn't yet enable it on any particular platform, as we still
>> need a panel driver for bcm911360_entphn.
>>
>> Signed-off-by: Eric Anholt 
>> ---
>>
>> These bits are just carving off a little bit of my 911360_entphn panel
>> series, to reduce conflicts when rebasing (which I just did for
>> testing pl111 changes for cygnus regressions).  I'm waiting to get my
>> current RPi panel driver in before working on the 911360 panel again.
>>
>>   arch/arm/boot/dts/bcm-cygnus.dtsi | 10 ++
>>   1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
>> b/arch/arm/boot/dts/bcm-cygnus.dtsi
>> index 7c957ea06c66..74f73ff24aec 100644
>> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
>> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
>> @@ -575,6 +575,16 @@
>>   status = "disabled";
>>   };
>>   +clcd: clcd@180a {
> please place in correct address ordered location in file

I moved it right above the v3d node to keep the nodes ordered by unit
address, please check the result here:

https://github.com/Broadcom/stblinux/commit/4d1e42c6b9d28ce7b74d92258435f9d16834ae75

>> +compatible = "arm,pl111", "arm,primecell";
>> +reg = <0x180a 0x1000>;
>> +interrupts = ;
>> +interrupt-names = "combined";
>> +clocks = <_clk>, <_clk>;
>> +clock-names = "clcdclk", "apb_pclk";
>> +status = "disabled";
>> +};
>> +
>>   keypad: keypad@180ac000 {
>>   compatible = "brcm,bcm-keypad";
>>   reg = <0x180ac000 0x14c>;
> 

-- 
Florian


Re: [PATCH 07/13] thermal/drivers/hisi: Encapsulate register writes into helpers

2017-09-01 Thread Leo Yan
On Wed, Aug 30, 2017 at 10:47:31AM +0200, Daniel Lezcano wrote:
> Hopefully, the function name can help to clarify the semantic of the 
> operations
> when writing in the register.
> 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/thermal/hisi_thermal.c | 96 
> +++---
>  1 file changed, 72 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index 6f0dab1..d77a938 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -26,6 +26,7 @@
>  
>  #include "thermal_core.h"
>  
> +#define TEMP0_LAG(0x0)
>  #define TEMP0_TH (0x4)
>  #define TEMP0_RST_TH (0x8)
>  #define TEMP0_CFG(0xC)
> @@ -96,6 +97,56 @@ static inline long hisi_thermal_round_temp(int temp)
>   hisi_thermal_temp_to_step(temp));
>  }
>  
> +static inline void hisi_thermal_set_lag(void __iomem *addr, int value)
> +{
> + writel(value, addr + TEMP0_LAG);
> +}
> +
> +static inline void hisi_thermal_alarm_clear(void __iomem *addr, int value)
> +{
> + writel(value, addr + TEMP0_INT_CLR);
> +}
> +
> +static inline void hisi_thermal_alarm_enable(void __iomem *addr, int value)
> +{
> + writel(value, addr + TEMP0_INT_EN);
> +}
> +
> +static inline void hisi_thermal_alarm_set(void __iomem *addr, int temp)
> +{
> + writel(hisi_thermal_temp_to_step(temp) | 0x0FF00, addr + TEMP0_TH);
> +}
> +
> +static inline void hisi_thermal_reset_set(void __iomem *addr, int temp)
> +{
> +writel(hisi_thermal_temp_to_step(temp), addr + TEMP0_RST_TH);
> +}
> +
> +static inline void hisi_thermal_reset_enable(void __iomem *addr, int value)
> +{
> +writel(value, addr + TEMP0_RST_MSK);
> +}
> +
> +static inline void hisi_thermal_enable(void __iomem *addr, int value)
> +{
> + writel(value, addr + TEMP0_EN);
> +}
> +
> +static inline void hisi_thermal_sensor_select(void __iomem *addr, int sensor)
> +{
> + writel((sensor << 12), addr + TEMP0_CFG);
> +}
> +
> +static inline int hisi_thermal_get_temperature(void __iomem *addr)
> +{
> + return hisi_thermal_step_to_temp(readl(addr + TEMP0_VALUE));
> +}
> +
> +static inline void hisi_thermal_hdak_set(void __iomem *addr, int value)
> +{
> + writel(value, addr + TEMP0_CFG);
> +}

hdak and sensor id setting share the same one register, so it's
possible to overwrite their value with each other. And for hdak
setting, it should offset 4 bits.

The issues are exists in old code yet but not introduce by this
patch. Could fix these issues as well in this patch?

> +
>  static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data *data,
>struct hisi_thermal_sensor *sensor)
>  {
> @@ -104,22 +155,21 @@ static long hisi_thermal_get_sensor_temp(struct 
> hisi_thermal_data *data,
>   mutex_lock(>thermal_lock);
>  
>   /* disable interrupt */
> - writel(0x0, data->regs + TEMP0_INT_EN);
> - writel(0x1, data->regs + TEMP0_INT_CLR);
> + hisi_thermal_alarm_enable(data->regs, 0);
> + hisi_thermal_alarm_clear(data->regs, 1);
>  
>   /* disable module firstly */
> - writel(0x0, data->regs + TEMP0_EN);
> + hisi_thermal_enable(data->regs, 0);
>  
>   /* select sensor id */
> - writel((sensor->id << 12), data->regs + TEMP0_CFG);
> + hisi_thermal_sensor_select(data->regs, sensor->id);
>  
>   /* enable module */
> - writel(0x1, data->regs + TEMP0_EN);
> + hisi_thermal_enable(data->regs, 1);
>  
>   usleep_range(3000, 5000);
>  
> - val = readl(data->regs + TEMP0_VALUE);
> - val = hisi_thermal_step_to_temp(val);
> + val = hisi_thermal_get_temperature(data->regs);
>  
>   mutex_unlock(>thermal_lock);
>  
> @@ -136,29 +186,27 @@ static void hisi_thermal_enable_bind_irq_sensor
>   sensor = >sensors;
>  
>   /* setting the hdak time */
> - writel(0x0, data->regs + TEMP0_CFG);
> + hisi_thermal_hdak_set(data->regs, 0);
>  
>   /* disable module firstly */
> - writel(0x0, data->regs + TEMP0_RST_MSK);
> - writel(0x0, data->regs + TEMP0_EN);
> + hisi_thermal_reset_enable(data->regs, 0);
> + hisi_thermal_enable(data->regs, 0);
>  
>   /* select sensor id */
> - writel((sensor->id << 12), data->regs + TEMP0_CFG);
> + hisi_thermal_sensor_select(data->regs, sensor->id);
>  
>   /* enable for interrupt */
> - writel(hisi_thermal_temp_to_step(sensor->thres_temp) | 0x0FF00,
> -data->regs + TEMP0_TH);
> + hisi_thermal_alarm_set(data->regs, sensor->thres_temp);
>  
> - writel(hisi_thermal_temp_to_step(HISI_TEMP_RESET),
> -data->regs + TEMP0_RST_TH);
> + hisi_thermal_reset_set(data->regs, HISI_TEMP_RESET);
>  
>   /* enable module */
> - writel(0x1, data->regs + TEMP0_RST_MSK);
> - writel(0x1, data->regs + TEMP0_EN);
> -
> - writel(0x0, data->regs + 

Re: [PATCH 07/13] thermal/drivers/hisi: Encapsulate register writes into helpers

2017-09-01 Thread Leo Yan
On Wed, Aug 30, 2017 at 10:47:31AM +0200, Daniel Lezcano wrote:
> Hopefully, the function name can help to clarify the semantic of the 
> operations
> when writing in the register.
> 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/thermal/hisi_thermal.c | 96 
> +++---
>  1 file changed, 72 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index 6f0dab1..d77a938 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -26,6 +26,7 @@
>  
>  #include "thermal_core.h"
>  
> +#define TEMP0_LAG(0x0)
>  #define TEMP0_TH (0x4)
>  #define TEMP0_RST_TH (0x8)
>  #define TEMP0_CFG(0xC)
> @@ -96,6 +97,56 @@ static inline long hisi_thermal_round_temp(int temp)
>   hisi_thermal_temp_to_step(temp));
>  }
>  
> +static inline void hisi_thermal_set_lag(void __iomem *addr, int value)
> +{
> + writel(value, addr + TEMP0_LAG);
> +}
> +
> +static inline void hisi_thermal_alarm_clear(void __iomem *addr, int value)
> +{
> + writel(value, addr + TEMP0_INT_CLR);
> +}
> +
> +static inline void hisi_thermal_alarm_enable(void __iomem *addr, int value)
> +{
> + writel(value, addr + TEMP0_INT_EN);
> +}
> +
> +static inline void hisi_thermal_alarm_set(void __iomem *addr, int temp)
> +{
> + writel(hisi_thermal_temp_to_step(temp) | 0x0FF00, addr + TEMP0_TH);
> +}
> +
> +static inline void hisi_thermal_reset_set(void __iomem *addr, int temp)
> +{
> +writel(hisi_thermal_temp_to_step(temp), addr + TEMP0_RST_TH);
> +}
> +
> +static inline void hisi_thermal_reset_enable(void __iomem *addr, int value)
> +{
> +writel(value, addr + TEMP0_RST_MSK);
> +}
> +
> +static inline void hisi_thermal_enable(void __iomem *addr, int value)
> +{
> + writel(value, addr + TEMP0_EN);
> +}
> +
> +static inline void hisi_thermal_sensor_select(void __iomem *addr, int sensor)
> +{
> + writel((sensor << 12), addr + TEMP0_CFG);
> +}
> +
> +static inline int hisi_thermal_get_temperature(void __iomem *addr)
> +{
> + return hisi_thermal_step_to_temp(readl(addr + TEMP0_VALUE));
> +}
> +
> +static inline void hisi_thermal_hdak_set(void __iomem *addr, int value)
> +{
> + writel(value, addr + TEMP0_CFG);
> +}

hdak and sensor id setting share the same one register, so it's
possible to overwrite their value with each other. And for hdak
setting, it should offset 4 bits.

The issues are exists in old code yet but not introduce by this
patch. Could fix these issues as well in this patch?

> +
>  static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data *data,
>struct hisi_thermal_sensor *sensor)
>  {
> @@ -104,22 +155,21 @@ static long hisi_thermal_get_sensor_temp(struct 
> hisi_thermal_data *data,
>   mutex_lock(>thermal_lock);
>  
>   /* disable interrupt */
> - writel(0x0, data->regs + TEMP0_INT_EN);
> - writel(0x1, data->regs + TEMP0_INT_CLR);
> + hisi_thermal_alarm_enable(data->regs, 0);
> + hisi_thermal_alarm_clear(data->regs, 1);
>  
>   /* disable module firstly */
> - writel(0x0, data->regs + TEMP0_EN);
> + hisi_thermal_enable(data->regs, 0);
>  
>   /* select sensor id */
> - writel((sensor->id << 12), data->regs + TEMP0_CFG);
> + hisi_thermal_sensor_select(data->regs, sensor->id);
>  
>   /* enable module */
> - writel(0x1, data->regs + TEMP0_EN);
> + hisi_thermal_enable(data->regs, 1);
>  
>   usleep_range(3000, 5000);
>  
> - val = readl(data->regs + TEMP0_VALUE);
> - val = hisi_thermal_step_to_temp(val);
> + val = hisi_thermal_get_temperature(data->regs);
>  
>   mutex_unlock(>thermal_lock);
>  
> @@ -136,29 +186,27 @@ static void hisi_thermal_enable_bind_irq_sensor
>   sensor = >sensors;
>  
>   /* setting the hdak time */
> - writel(0x0, data->regs + TEMP0_CFG);
> + hisi_thermal_hdak_set(data->regs, 0);
>  
>   /* disable module firstly */
> - writel(0x0, data->regs + TEMP0_RST_MSK);
> - writel(0x0, data->regs + TEMP0_EN);
> + hisi_thermal_reset_enable(data->regs, 0);
> + hisi_thermal_enable(data->regs, 0);
>  
>   /* select sensor id */
> - writel((sensor->id << 12), data->regs + TEMP0_CFG);
> + hisi_thermal_sensor_select(data->regs, sensor->id);
>  
>   /* enable for interrupt */
> - writel(hisi_thermal_temp_to_step(sensor->thres_temp) | 0x0FF00,
> -data->regs + TEMP0_TH);
> + hisi_thermal_alarm_set(data->regs, sensor->thres_temp);
>  
> - writel(hisi_thermal_temp_to_step(HISI_TEMP_RESET),
> -data->regs + TEMP0_RST_TH);
> + hisi_thermal_reset_set(data->regs, HISI_TEMP_RESET);
>  
>   /* enable module */
> - writel(0x1, data->regs + TEMP0_RST_MSK);
> - writel(0x1, data->regs + TEMP0_EN);
> -
> - writel(0x0, data->regs + TEMP0_INT_CLR);
> - 

Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64

2017-09-01 Thread Stefan Bruens
On Samstag, 2. September 2017 00:32:50 CEST André Przywara wrote:
> Hi,
> 
> On 01/09/17 02:19, Stefan Bruens wrote:
> > On Freitag, 1. September 2017 02:31:35 CEST Andre Przywara wrote:
> >> Hi,
> >> 
> >> On 31/08/17 00:36, Stefan Brüns wrote:
> >>> The A64 SoC has the same dma engine as the H3 (sun8i), with a
> >>> reduced amount of physical channels. Add the proper config data
> >>> and compatible string to support it.
> >> 
> >> ...
> >> 
> >>> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> >>> index 5f4eee4513e5..6a17c5d63582 100644
> >>> --- a/drivers/dma/sun6i-dma.c
> >>> +++ b/drivers/dma/sun6i-dma.c
> >>> @@ -1068,6 +1068,12 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg =
> >>> {
> >>> 
> >>>   .nr_max_vchans   = 34,
> >>>   .dmac_variant= DMAC_VARIANT_H3,
> >>>  
> >>>  };
> >>> 
> >>> +
> >>> +static struct sun6i_dma_config sun50i_a64_dma_cfg = {
> >>> + .nr_max_channels = 8,
> >>> + .nr_max_requests = 27,
> >>> + .nr_max_vchans   = 38,
> >>> + .dmac_variant= DMAC_VARIANT_H3,
> >>> 
> >>>  };
> >>>  
[...]
> > There are also the incompatibilities in the "DMA channel configuration
> > register" (burst length; burst width; burst length field offset).
> > 
> > We can either have 3 different compatible strings, or another property for
> > the register model.
> 
> The latter is usually frowned upon, using separate compatible strings
> for each group of SoCs is the way to go here.

Just for clarification, I was not talking about a property in the devicetree, 
but about a struct member in the config data, i.e. the .dmac_variant above.

Kind regards,

Stefan

-- 
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019


Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64

2017-09-01 Thread Stefan Bruens
On Samstag, 2. September 2017 00:32:50 CEST André Przywara wrote:
> Hi,
> 
> On 01/09/17 02:19, Stefan Bruens wrote:
> > On Freitag, 1. September 2017 02:31:35 CEST Andre Przywara wrote:
> >> Hi,
> >> 
> >> On 31/08/17 00:36, Stefan Brüns wrote:
> >>> The A64 SoC has the same dma engine as the H3 (sun8i), with a
> >>> reduced amount of physical channels. Add the proper config data
> >>> and compatible string to support it.
> >> 
> >> ...
> >> 
> >>> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> >>> index 5f4eee4513e5..6a17c5d63582 100644
> >>> --- a/drivers/dma/sun6i-dma.c
> >>> +++ b/drivers/dma/sun6i-dma.c
> >>> @@ -1068,6 +1068,12 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg =
> >>> {
> >>> 
> >>>   .nr_max_vchans   = 34,
> >>>   .dmac_variant= DMAC_VARIANT_H3,
> >>>  
> >>>  };
> >>> 
> >>> +
> >>> +static struct sun6i_dma_config sun50i_a64_dma_cfg = {
> >>> + .nr_max_channels = 8,
> >>> + .nr_max_requests = 27,
> >>> + .nr_max_vchans   = 38,
> >>> + .dmac_variant= DMAC_VARIANT_H3,
> >>> 
> >>>  };
> >>>  
[...]
> > There are also the incompatibilities in the "DMA channel configuration
> > register" (burst length; burst width; burst length field offset).
> > 
> > We can either have 3 different compatible strings, or another property for
> > the register model.
> 
> The latter is usually frowned upon, using separate compatible strings
> for each group of SoCs is the way to go here.

Just for clarification, I was not talking about a property in the devicetree, 
but about a struct member in the config data, i.e. the .dmac_variant above.

Kind regards,

Stefan

-- 
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019


Re: [PATCH] CHROMIUM: devfreq: rk3399: Clear edev->dev drvdata before enabling dfi

2017-09-01 Thread jeffy

hi brian,
On 09/02/2017 08:47 AM, Brian Norris wrote:

On Sat, Sep 02, 2017 at 07:52:37AM +0800, Jeffy Chen wrote:

Currently we are using edev->dev drvdata to get rk3399-dmc data, but
it would be inited to edev in devfreq_event_add_edev.

So we need to clear the edev->dev drvdata before enabling dfi, to
prevent dfi from getting the wrong rk3399-dmc data when the irq
triggered too early.


Your description doesn't match your code. You say you're clearing
evdev->dev driver data but...


Signed-off-by: Jeffy Chen 
---

  drivers/devfreq/rk3399_dmc.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
index 1b89ebbad02c..12f9f03f349f 100644
--- a/drivers/devfreq/rk3399_dmc.c
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -429,6 +429,7 @@ static int rk3399_dmcfreq_probe(struct platform_device 
*pdev)

rk3399_devfreq_dmc_profile.initial_freq = data->rate;

+   platform_set_drvdata(pdev, NULL);


...here you're only clearing the drvdata for the platform device. Is
that a mistake? (Hint: that's not what you uploaded on the Chromium OS
instance, where you presumably tested this.)

And if you're really trying to do what your commit message says:

We're having two different files fight over who owns the edev drvdata?
That seems like a big no-no.

We should work out who's the real owner of 'drvdata', and find some
other solution for the others.


sorry, indeed...it turns out the upstream dmc driver is not using 
dfi(it's simple_onfemand below ;)...


so we don't need thus patch for upstream kernel...or maybe we should 
submit other cros patches(contains the one causes this issue, and this 
patch)


Brian


data->devfreq = devm_devfreq_add_device(dev,
   _devfreq_dmc_profile,
   "simple_ondemand",
--
2.11.0











Re: [PATCH] CHROMIUM: devfreq: rk3399: Clear edev->dev drvdata before enabling dfi

2017-09-01 Thread jeffy

hi brian,
On 09/02/2017 08:47 AM, Brian Norris wrote:

On Sat, Sep 02, 2017 at 07:52:37AM +0800, Jeffy Chen wrote:

Currently we are using edev->dev drvdata to get rk3399-dmc data, but
it would be inited to edev in devfreq_event_add_edev.

So we need to clear the edev->dev drvdata before enabling dfi, to
prevent dfi from getting the wrong rk3399-dmc data when the irq
triggered too early.


Your description doesn't match your code. You say you're clearing
evdev->dev driver data but...


Signed-off-by: Jeffy Chen 
---

  drivers/devfreq/rk3399_dmc.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
index 1b89ebbad02c..12f9f03f349f 100644
--- a/drivers/devfreq/rk3399_dmc.c
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -429,6 +429,7 @@ static int rk3399_dmcfreq_probe(struct platform_device 
*pdev)

rk3399_devfreq_dmc_profile.initial_freq = data->rate;

+   platform_set_drvdata(pdev, NULL);


...here you're only clearing the drvdata for the platform device. Is
that a mistake? (Hint: that's not what you uploaded on the Chromium OS
instance, where you presumably tested this.)

And if you're really trying to do what your commit message says:

We're having two different files fight over who owns the edev drvdata?
That seems like a big no-no.

We should work out who's the real owner of 'drvdata', and find some
other solution for the others.


sorry, indeed...it turns out the upstream dmc driver is not using 
dfi(it's simple_onfemand below ;)...


so we don't need thus patch for upstream kernel...or maybe we should 
submit other cros patches(contains the one causes this issue, and this 
patch)


Brian


data->devfreq = devm_devfreq_add_device(dev,
   _devfreq_dmc_profile,
   "simple_ondemand",
--
2.11.0











Re: [PATCH] ipv6: sr: Use ARRAY_SIZE macro

2017-09-01 Thread David Miller
From: Thomas Meyer 
Date: Thu, 31 Aug 2017 16:18:15 +0200

> Grepping for "sizeof\(.+\) / sizeof\(" found this as one of the first
> candidates.
> Maybe a coccinelle can catch all of those.
> 
> Signed-off-by: Thomas Meyer 

Applied, thanks.


Re: [PATCH] ipv6: sr: Use ARRAY_SIZE macro

2017-09-01 Thread David Miller
From: Thomas Meyer 
Date: Thu, 31 Aug 2017 16:18:15 +0200

> Grepping for "sizeof\(.+\) / sizeof\(" found this as one of the first
> candidates.
> Maybe a coccinelle can catch all of those.
> 
> Signed-off-by: Thomas Meyer 

Applied, thanks.


Re: [PATCH][net-next] net: qualcomm: rmnet: remove unused variable priv

2017-09-01 Thread David Miller
From: Colin King 
Date: Thu, 31 Aug 2017 15:07:27 +0100

> From: Colin Ian King 
> 
> priv is being assigned but is never used, so remove it.
> 
> Cleans up clang build warning:
> "warning: Value stored to 'priv' is never read"
> 
> Fixes: ceed73a2cf4a ("drivers: net: ethernet: qualcomm: rmnet: Initial 
> implementation")
> Signed-off-by: Colin Ian King 

Applied.


Re: [PATCH][net-next] net: qualcomm: rmnet: remove unused variable priv

2017-09-01 Thread David Miller
From: Colin King 
Date: Thu, 31 Aug 2017 15:07:27 +0100

> From: Colin Ian King 
> 
> priv is being assigned but is never used, so remove it.
> 
> Cleans up clang build warning:
> "warning: Value stored to 'priv' is never read"
> 
> Fixes: ceed73a2cf4a ("drivers: net: ethernet: qualcomm: rmnet: Initial 
> implementation")
> Signed-off-by: Colin Ian King 

Applied.


Re: [PATCH] net: phy: bcm7xxx: make array bcm7xxx_suspend_cfg static, reduces object code size

2017-09-01 Thread David Miller
From: Colin King 
Date: Thu, 31 Aug 2017 14:57:15 +0100

> From: Colin Ian King 
> 
> Don't populate the array bcm7xxx_suspend_cfg A on the stack, instead
> make it static.  Makes the object code smaller by over 300 bytes:
> 
> Before:
>text  data bss dec hex filename
>6351  8146   0   1449738a1 drivers/net/phy/bcm7xxx.o
> 
> After:
>text  data bss dec hex filename
>5986  8210   0   141963774 drivers/net/phy/bcm7xxx.o
> 
> Signed-off-by: Colin Ian King 

Applied.


Re: [PATCH] net: phy: bcm7xxx: make array bcm7xxx_suspend_cfg static, reduces object code size

2017-09-01 Thread David Miller
From: Colin King 
Date: Thu, 31 Aug 2017 14:57:15 +0100

> From: Colin Ian King 
> 
> Don't populate the array bcm7xxx_suspend_cfg A on the stack, instead
> make it static.  Makes the object code smaller by over 300 bytes:
> 
> Before:
>text  data bss dec hex filename
>6351  8146   0   1449738a1 drivers/net/phy/bcm7xxx.o
> 
> After:
>text  data bss dec hex filename
>5986  8210   0   141963774 drivers/net/phy/bcm7xxx.o
> 
> Signed-off-by: Colin Ian King 

Applied.


Re: [PATCH net-next v6] net: stmmac: Delete dead code for MDIO registration

2017-09-01 Thread David Miller
From: Romain Perier 
Date: Thu, 31 Aug 2017 15:53:03 +0200

> This code is no longer used, the logging function was changed by commit
> fbca164776e4 ("net: stmmac: Use the right logging function in 
> stmmac_mdio_register").
> It was previously showing information about the type of the IRQ, if it's
> polled, ignored or a normal interrupt. As we don't want information loss,
> I have moved this code to phy_attached_print().
> 
> Fixes: fbca164776e4 ("net: stmmac: Use the right logging function in 
> stmmac_mdio_register")
> Signed-off-by: Romain Perier 

You'll need to respin this against net-next as phy_attached_print() has had
some changes recently.

Thanks.


Re: [PATCH net-next v6] net: stmmac: Delete dead code for MDIO registration

2017-09-01 Thread David Miller
From: Romain Perier 
Date: Thu, 31 Aug 2017 15:53:03 +0200

> This code is no longer used, the logging function was changed by commit
> fbca164776e4 ("net: stmmac: Use the right logging function in 
> stmmac_mdio_register").
> It was previously showing information about the type of the IRQ, if it's
> polled, ignored or a normal interrupt. As we don't want information loss,
> I have moved this code to phy_attached_print().
> 
> Fixes: fbca164776e4 ("net: stmmac: Use the right logging function in 
> stmmac_mdio_register")
> Signed-off-by: Romain Perier 

You'll need to respin this against net-next as phy_attached_print() has had
some changes recently.

Thanks.


Re: [PATCH 23/25] ALSA/dummy: Replace tasklet with softirq hrtimer

2017-09-01 Thread Takashi Sakamoto

On p 1 2017 20:58, Takashi Iwai wrote:

>From 07d61ba2a1c0e06e914443225e194d99f2d8c58d Mon Sep 17 00:00:00 2001
From: Takashi Sakamoto 
Date: Fri, 1 Sep 2017 19:10:18 +0900
Subject: [PATCH] ALSA: dummy: avoid stall due to a call of hrtimer_cancel() on
  a callback of hrtimer

A call of 'htrimer_cancel()' on a callback of hrtimer brings endless loop
because 'struct hrtimer_clock_base.running' is not NULL on the callback.
In hrtimer subsystem, this member is used to indicate the instance of
hrtimer gets callbacks and there's a helper function,
'hrtimer_callback_running()' to check it.

ALSA dummy driver uses hrtimer to emulate hardware interrupt per period
of PCM buffer. When XRUN occurs on PCM substream, in a call of
'snd_pcm_period_elapsed()', 'struct snd_pcm_ops.stop()' is called to
stop the substream. In current implementation, 'hrtimer_cancel()' is
used to wait for cancellation of hrtimer. However, as described, this
brings endless loop.


It's not only about XRUN.  When the stream finishes the draining, it
stops the stream gracefully -- that is the very normal operation.


I overlooked it. Thanks for your indication.


For this problem, this commit uses 'hrtimer_callback_running()' to
detect whether to be on a callback of hrtimer or not, then skip
cancellation of hrtimer in hrtimer callbacks. Furthermore, at a case of
XRUN, hrtimer callback returns HRTIMER_NORESTART after a call of
'snd_pcm_period_elapsed()' to discontinue hrtimr because cancellation is
skipped.

Signed-off-by: Takashi Sakamoto 


It's better to fold the fix into the original patch instead of
introducing a bug and fixing it.


Yep. I request the authors to include this fix.


Well, in sound subsystem, there're a few drivers which uses hrtimer:
 - snd-pcsp
 - snd-sh-dac-audio
 - snd-soc-imx-pcm-fiq

As a quick glance, 'snd-sh-dac-audio' includes the same bug, too. 
Additionally, 'snd-soc-imx-pcm-fiq' maintains hrtimer with loose manner 
in a point of state of PCM substream and it shall gain the same bug if 
improved. Later, I posted some patches for them.



Thanks

Takashi Sakamoto


Re: [PATCH 23/25] ALSA/dummy: Replace tasklet with softirq hrtimer

2017-09-01 Thread Takashi Sakamoto

On p 1 2017 20:58, Takashi Iwai wrote:

>From 07d61ba2a1c0e06e914443225e194d99f2d8c58d Mon Sep 17 00:00:00 2001
From: Takashi Sakamoto 
Date: Fri, 1 Sep 2017 19:10:18 +0900
Subject: [PATCH] ALSA: dummy: avoid stall due to a call of hrtimer_cancel() on
  a callback of hrtimer

A call of 'htrimer_cancel()' on a callback of hrtimer brings endless loop
because 'struct hrtimer_clock_base.running' is not NULL on the callback.
In hrtimer subsystem, this member is used to indicate the instance of
hrtimer gets callbacks and there's a helper function,
'hrtimer_callback_running()' to check it.

ALSA dummy driver uses hrtimer to emulate hardware interrupt per period
of PCM buffer. When XRUN occurs on PCM substream, in a call of
'snd_pcm_period_elapsed()', 'struct snd_pcm_ops.stop()' is called to
stop the substream. In current implementation, 'hrtimer_cancel()' is
used to wait for cancellation of hrtimer. However, as described, this
brings endless loop.


It's not only about XRUN.  When the stream finishes the draining, it
stops the stream gracefully -- that is the very normal operation.


I overlooked it. Thanks for your indication.


For this problem, this commit uses 'hrtimer_callback_running()' to
detect whether to be on a callback of hrtimer or not, then skip
cancellation of hrtimer in hrtimer callbacks. Furthermore, at a case of
XRUN, hrtimer callback returns HRTIMER_NORESTART after a call of
'snd_pcm_period_elapsed()' to discontinue hrtimr because cancellation is
skipped.

Signed-off-by: Takashi Sakamoto 


It's better to fold the fix into the original patch instead of
introducing a bug and fixing it.


Yep. I request the authors to include this fix.


Well, in sound subsystem, there're a few drivers which uses hrtimer:
 - snd-pcsp
 - snd-sh-dac-audio
 - snd-soc-imx-pcm-fiq

As a quick glance, 'snd-sh-dac-audio' includes the same bug, too. 
Additionally, 'snd-soc-imx-pcm-fiq' maintains hrtimer with loose manner 
in a point of state of PCM substream and it shall gain the same bug if 
improved. Later, I posted some patches for them.



Thanks

Takashi Sakamoto


Re: [PATCH] f2fs: avoid needless inode updates

2017-09-01 Thread Jaegeuk Kim
Please ignore this patch.

Thanks,

On 09/01, Jaegeuk Kim wrote:
> If i_size wan't change at all, we don't need to write inode during fsync.
> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/f2fs.h | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 4b993961d81d..0d76b572484a 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -2267,11 +2267,11 @@ static inline bool f2fs_skip_inode_update(struct 
> inode *inode, int dsync)
>   spin_unlock(>inode_lock[DIRTY_META]);
>   return ret;
>   }
> - if (!is_inode_flag_set(inode, FI_AUTO_RECOVER) ||
> - file_keep_isize(inode) ||
> - i_size_read(inode) & PAGE_MASK)
> - return false;
> - return F2FS_I(inode)->last_disk_size == i_size_read(inode);
> + if (F2FS_I(inode)->last_disk_size == i_size_read(inode))
> + return true;
> +
> + return is_inode_flag_set(inode, FI_AUTO_RECOVER) &&
> + !file_keep_isize(inode) && !(i_size_read(inode) & PAGE_MASK);
>  }
>  
>  static inline int f2fs_readonly(struct super_block *sb)
> -- 
> 2.14.0.rc1.383.gd1ce394fe2-goog


Re: [PATCH] f2fs: avoid needless inode updates

2017-09-01 Thread Jaegeuk Kim
Please ignore this patch.

Thanks,

On 09/01, Jaegeuk Kim wrote:
> If i_size wan't change at all, we don't need to write inode during fsync.
> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/f2fs.h | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 4b993961d81d..0d76b572484a 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -2267,11 +2267,11 @@ static inline bool f2fs_skip_inode_update(struct 
> inode *inode, int dsync)
>   spin_unlock(>inode_lock[DIRTY_META]);
>   return ret;
>   }
> - if (!is_inode_flag_set(inode, FI_AUTO_RECOVER) ||
> - file_keep_isize(inode) ||
> - i_size_read(inode) & PAGE_MASK)
> - return false;
> - return F2FS_I(inode)->last_disk_size == i_size_read(inode);
> + if (F2FS_I(inode)->last_disk_size == i_size_read(inode))
> + return true;
> +
> + return is_inode_flag_set(inode, FI_AUTO_RECOVER) &&
> + !file_keep_isize(inode) && !(i_size_read(inode) & PAGE_MASK);
>  }
>  
>  static inline int f2fs_readonly(struct super_block *sb)
> -- 
> 2.14.0.rc1.383.gd1ce394fe2-goog


Re: [PATCH] CHROMIUM: devfreq: rk3399: Clear edev->dev drvdata before enabling dfi

2017-09-01 Thread Brian Norris
On Sat, Sep 02, 2017 at 07:52:37AM +0800, Jeffy Chen wrote:
> Currently we are using edev->dev drvdata to get rk3399-dmc data, but
> it would be inited to edev in devfreq_event_add_edev.
> 
> So we need to clear the edev->dev drvdata before enabling dfi, to
> prevent dfi from getting the wrong rk3399-dmc data when the irq
> triggered too early.

Your description doesn't match your code. You say you're clearing
evdev->dev driver data but...

> Signed-off-by: Jeffy Chen 
> ---
> 
>  drivers/devfreq/rk3399_dmc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
> index 1b89ebbad02c..12f9f03f349f 100644
> --- a/drivers/devfreq/rk3399_dmc.c
> +++ b/drivers/devfreq/rk3399_dmc.c
> @@ -429,6 +429,7 @@ static int rk3399_dmcfreq_probe(struct platform_device 
> *pdev)
>  
>   rk3399_devfreq_dmc_profile.initial_freq = data->rate;
>  
> + platform_set_drvdata(pdev, NULL);

...here you're only clearing the drvdata for the platform device. Is
that a mistake? (Hint: that's not what you uploaded on the Chromium OS
instance, where you presumably tested this.)

And if you're really trying to do what your commit message says:

We're having two different files fight over who owns the edev drvdata?
That seems like a big no-no.

We should work out who's the real owner of 'drvdata', and find some
other solution for the others.

Brian

>   data->devfreq = devm_devfreq_add_device(dev,
>  _devfreq_dmc_profile,
>  "simple_ondemand",
> -- 
> 2.11.0
> 
> 


Re: [PATCH] CHROMIUM: devfreq: rk3399: Clear edev->dev drvdata before enabling dfi

2017-09-01 Thread Brian Norris
On Sat, Sep 02, 2017 at 07:52:37AM +0800, Jeffy Chen wrote:
> Currently we are using edev->dev drvdata to get rk3399-dmc data, but
> it would be inited to edev in devfreq_event_add_edev.
> 
> So we need to clear the edev->dev drvdata before enabling dfi, to
> prevent dfi from getting the wrong rk3399-dmc data when the irq
> triggered too early.

Your description doesn't match your code. You say you're clearing
evdev->dev driver data but...

> Signed-off-by: Jeffy Chen 
> ---
> 
>  drivers/devfreq/rk3399_dmc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
> index 1b89ebbad02c..12f9f03f349f 100644
> --- a/drivers/devfreq/rk3399_dmc.c
> +++ b/drivers/devfreq/rk3399_dmc.c
> @@ -429,6 +429,7 @@ static int rk3399_dmcfreq_probe(struct platform_device 
> *pdev)
>  
>   rk3399_devfreq_dmc_profile.initial_freq = data->rate;
>  
> + platform_set_drvdata(pdev, NULL);

...here you're only clearing the drvdata for the platform device. Is
that a mistake? (Hint: that's not what you uploaded on the Chromium OS
instance, where you presumably tested this.)

And if you're really trying to do what your commit message says:

We're having two different files fight over who owns the edev drvdata?
That seems like a big no-no.

We should work out who's the real owner of 'drvdata', and find some
other solution for the others.

Brian

>   data->devfreq = devm_devfreq_add_device(dev,
>  _devfreq_dmc_profile,
>  "simple_ondemand",
> -- 
> 2.11.0
> 
> 


Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64

2017-09-01 Thread Stefan Bruens
On Samstag, 2. September 2017 00:32:50 CEST André Przywara wrote:
> Hi,
> 
> On 01/09/17 02:19, Stefan Bruens wrote:
> > On Freitag, 1. September 2017 02:31:35 CEST Andre Przywara wrote:
> >> Hi,
> >> 
> >> On 31/08/17 00:36, Stefan Brüns wrote:
[...]
> > 
> > For these 3 properties it likely is a good idea, but we would IMHO still
> > have to care for the differences in the register settings:
> > 
> > - A31 does not have a clock autogating register
> > - A23 and A83t does have one at offset 0x20
> > - A64, H3, H5 and R40 have it at offset 0x28
> 
> Fair enough - I didn't look too closely at your new changes, especially
> why it apparently worked before.
> But as your list shows, we would only need one compatible string per
> line - in the driver - to cover all SoCs (and possibly future SoCs!),
> and do the rest via the properties.
> We can't use the existing h3 compatible string or touch the already
> existing SoCs and compatible strings, of course, but I guess
> the A64, R40 and future SoCs could make use of a new (generic?) string.
> 
> > There are also the incompatibilities in the "DMA channel configuration
> > register" (burst length; burst width; burst length field offset).
> > 
> > We can either have 3 different compatible strings, or another property for
> > the register model.
> 
> The latter is usually frowned upon, using separate compatible strings
> for each group of SoCs is the way to go here.
> 
> > For the aw,max_requests and aw,max_vchans, maybe a bitmask per direction
> > is a better option - it can encode the allowed DRQ numbers much better
> > (e.g. for H3, the highest source DRQ is 24). The DRQ field in the channel
> > configuration register is 5 bits, so the hightest port/DRQ number is 31.
> 
> So looking more closely at the manual and the code my understanding is
> that nr_max_requests is more or less some rough molly guard to prevent
> wrong settings? Derived from the DRQ table in the manual?
> So that trying to program port 28 on an H3 would fail?
> But source port 25 or dest port 26 wouldn't be caught by this check,
> though they would still be "illegal" according to the manual. (Which we
> are not sure of, I guess, it may just not be documented)
> So I wonder if this nr_max_requests is useful at all, and we should just
> check that it fits into 5 bits and assume that the DT has superior
> knowledge of what's allowed and what not.
> Now I see what you mean with the bitmask (to cover those gaps), but I am
> bit sceptical if that is actually useful. After all the DRQ number would
> be coming from the DT, which we can surely trust.
> 
> And nr_max_vchans seems to describe the sum of documented DRQs, to just
> limit the memory allocation? So this could become just 64 to cover all
> possible cases without SoC specific configuration at all?

Yes, thats my understanding as well. Allocating a few excess channels would 
waste a few kBytes (AFAICS 304 bytes per channel on 64bit).
 
> > For aw,max_channels my first thought is - why max? is it variable? is
> > there a min_channels? My suggestion would be (in order of preference):
> > "aw,channels", "aw,dma_channels", "aw,available_channels".
> 
> Sure, actually looking at Documentation/devicetree/bindings/dma/dma.txt
> I think we can even use the generic "dma-channels" property described
> there. And possibly the same with "dma-requests", should we keep this.
> 
> So summarizing this:
> - We create a new compatible string, which drives an H3 compatible DMA
> (clock autogating at 0x28, 64-bit data width capable). This name could
> either be generic, or actually "allwinner,sun50i-a64-dma".
> - This one sets nr_max_requests to 31 and nr_max_vchans to 64.
> - Alternatively we expose those values in the DT as properties.
> - We take the number of DMA channels from the (now required)
> "dma-channels" property.
> - We let the A64 (and R40?) use this new binding.
> - Any future SoC which is close enough can then just piggy-back on this.
> - Any future *changes* in the Allwinner DMA device which require driver
> changes create a new compatible string, but still keep the above
> semantics. Chances are that there are more than one SoC using this kind
> of new DMA device, so they would work out of the box.
> 
> Does that make sense?
> I am happy to provide the code for that, based on your H3 rework.

Sounds good for me. I will send a cleaned up series later.

Kind regards,

Stefan

-- 
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019


Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64

2017-09-01 Thread Stefan Bruens
On Samstag, 2. September 2017 00:32:50 CEST André Przywara wrote:
> Hi,
> 
> On 01/09/17 02:19, Stefan Bruens wrote:
> > On Freitag, 1. September 2017 02:31:35 CEST Andre Przywara wrote:
> >> Hi,
> >> 
> >> On 31/08/17 00:36, Stefan Brüns wrote:
[...]
> > 
> > For these 3 properties it likely is a good idea, but we would IMHO still
> > have to care for the differences in the register settings:
> > 
> > - A31 does not have a clock autogating register
> > - A23 and A83t does have one at offset 0x20
> > - A64, H3, H5 and R40 have it at offset 0x28
> 
> Fair enough - I didn't look too closely at your new changes, especially
> why it apparently worked before.
> But as your list shows, we would only need one compatible string per
> line - in the driver - to cover all SoCs (and possibly future SoCs!),
> and do the rest via the properties.
> We can't use the existing h3 compatible string or touch the already
> existing SoCs and compatible strings, of course, but I guess
> the A64, R40 and future SoCs could make use of a new (generic?) string.
> 
> > There are also the incompatibilities in the "DMA channel configuration
> > register" (burst length; burst width; burst length field offset).
> > 
> > We can either have 3 different compatible strings, or another property for
> > the register model.
> 
> The latter is usually frowned upon, using separate compatible strings
> for each group of SoCs is the way to go here.
> 
> > For the aw,max_requests and aw,max_vchans, maybe a bitmask per direction
> > is a better option - it can encode the allowed DRQ numbers much better
> > (e.g. for H3, the highest source DRQ is 24). The DRQ field in the channel
> > configuration register is 5 bits, so the hightest port/DRQ number is 31.
> 
> So looking more closely at the manual and the code my understanding is
> that nr_max_requests is more or less some rough molly guard to prevent
> wrong settings? Derived from the DRQ table in the manual?
> So that trying to program port 28 on an H3 would fail?
> But source port 25 or dest port 26 wouldn't be caught by this check,
> though they would still be "illegal" according to the manual. (Which we
> are not sure of, I guess, it may just not be documented)
> So I wonder if this nr_max_requests is useful at all, and we should just
> check that it fits into 5 bits and assume that the DT has superior
> knowledge of what's allowed and what not.
> Now I see what you mean with the bitmask (to cover those gaps), but I am
> bit sceptical if that is actually useful. After all the DRQ number would
> be coming from the DT, which we can surely trust.
> 
> And nr_max_vchans seems to describe the sum of documented DRQs, to just
> limit the memory allocation? So this could become just 64 to cover all
> possible cases without SoC specific configuration at all?

Yes, thats my understanding as well. Allocating a few excess channels would 
waste a few kBytes (AFAICS 304 bytes per channel on 64bit).
 
> > For aw,max_channels my first thought is - why max? is it variable? is
> > there a min_channels? My suggestion would be (in order of preference):
> > "aw,channels", "aw,dma_channels", "aw,available_channels".
> 
> Sure, actually looking at Documentation/devicetree/bindings/dma/dma.txt
> I think we can even use the generic "dma-channels" property described
> there. And possibly the same with "dma-requests", should we keep this.
> 
> So summarizing this:
> - We create a new compatible string, which drives an H3 compatible DMA
> (clock autogating at 0x28, 64-bit data width capable). This name could
> either be generic, or actually "allwinner,sun50i-a64-dma".
> - This one sets nr_max_requests to 31 and nr_max_vchans to 64.
> - Alternatively we expose those values in the DT as properties.
> - We take the number of DMA channels from the (now required)
> "dma-channels" property.
> - We let the A64 (and R40?) use this new binding.
> - Any future SoC which is close enough can then just piggy-back on this.
> - Any future *changes* in the Allwinner DMA device which require driver
> changes create a new compatible string, but still keep the above
> semantics. Chances are that there are more than one SoC using this kind
> of new DMA device, so they would work out of the box.
> 
> Does that make sense?
> I am happy to provide the code for that, based on your H3 rework.

Sounds good for me. I will send a cleaned up series later.

Kind regards,

Stefan

-- 
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019


Re: [PATCH] sched: reset sysctl_sched_time_avg to default when

2017-09-01 Thread Ethan Zhao
Yep, that is the first place I considered to set the limit, but that would
break KABI ?

Thanks,
Ethan

On Fri, Sep 1, 2017 at 8:32 PM, Peter Zijlstra  wrote:
> On Fri, Sep 01, 2017 at 07:31:54PM +0800, Ethan Zhao wrote:
>> System will hang if user set sysctl_sched_time_avg to 0 by
>>
>> [root@XXX ~]# sysctl kernel.sched_time_avg_ms=0
>>
>> Stack traceback for pid 0
>> 0x883f6406c600 0 0 1 3 R 0x883f6406cf50 *swapper/3
>> 883f7ccc3ae8 0018 810c4dd0 
>> 00017800 883f7ccc3d78 0003 883f7ccc3bf8
>> 810c4fc9 883f7ccc3c08 810c5043 883f7ccc3c08
>> Call Trace:
>>  [] ? update_group_capacity+0x110/0x200
>> [] ? update_sd_lb_stats+0x109/0x600
>> [] ? find_busiest_group+0x47/0x530
>> [] ? load_balance+0x194/0x900
>> [] ? update_rq_clock.part.83+0x1a/0xe0
>> [] ? rebalance_domains+0x152/0x290
>> [] ? run_rebalance_domains+0xdc/0x1d0
>> [] ? __do_softirq+0xfb/0x320
>> [] ? irq_exit+0x125/0x130
>> [] ? scheduler_ipi+0x97/0x160
>> [] ? smp_reschedule_interrupt+0x29/0x30
>> [] ? reschedule_interrupt+0x6e/0x80
>>  [] ? cpuidle_enter_state+0xcc/0x230
>> [] ? cpuidle_enter_state+0x9c/0x230
>> [] ? cpuidle_enter+0x17/0x20
>> [] ? cpu_startup_entry+0x38c/0x420
>> [] ? start_secondary+0x173/0x1e0
>>
>> Because divide-by-zero error happens in function
>>
>> update_group_capacity()
>>   update_cpu_capacity()
>> scale_rt_capacity()
>>   {
>>   ...
>>   total = sched_avg_period() + delta;
>>   used = div_u64(avg, total);
>>   ...
>>   }
>>
>> Seems this issue could be reproduced on all I tried stable 4.1 - last
>> kernel.
>>
>> To fix this issue, reset sysctl_sched_time_avg to default value
>> MSEC_PER_SEC if user input invalid value in function
>>
>> sched_avg_period()
>>
>> Reported-by: James Puthukattukaran 
>> Signed-off-by: Ethan Zhao 
>> ---
>>  Tested on stable 4.1, compiled on stable 4.13-rc5
>>  kernel/sched/sched.h | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
>> index eeef1a3..b398560 100644
>> --- a/kernel/sched/sched.h
>> +++ b/kernel/sched/sched.h
>> @@ -1620,6 +1620,9 @@ static inline void rq_last_tick_reset(struct rq *rq)
>>
>>  static inline u64 sched_avg_period(void)
>>  {
>> + if (unlikely(sysctl_sched_time_avg <= 0))
>> + sysctl_sched_time_avg = MSEC_PER_SEC;
>> +
>
> Sight, no.. you can set limits in the sysctl table.


Re: [PATCH] sched: reset sysctl_sched_time_avg to default when

2017-09-01 Thread Ethan Zhao
Yep, that is the first place I considered to set the limit, but that would
break KABI ?

Thanks,
Ethan

On Fri, Sep 1, 2017 at 8:32 PM, Peter Zijlstra  wrote:
> On Fri, Sep 01, 2017 at 07:31:54PM +0800, Ethan Zhao wrote:
>> System will hang if user set sysctl_sched_time_avg to 0 by
>>
>> [root@XXX ~]# sysctl kernel.sched_time_avg_ms=0
>>
>> Stack traceback for pid 0
>> 0x883f6406c600 0 0 1 3 R 0x883f6406cf50 *swapper/3
>> 883f7ccc3ae8 0018 810c4dd0 
>> 00017800 883f7ccc3d78 0003 883f7ccc3bf8
>> 810c4fc9 883f7ccc3c08 810c5043 883f7ccc3c08
>> Call Trace:
>>  [] ? update_group_capacity+0x110/0x200
>> [] ? update_sd_lb_stats+0x109/0x600
>> [] ? find_busiest_group+0x47/0x530
>> [] ? load_balance+0x194/0x900
>> [] ? update_rq_clock.part.83+0x1a/0xe0
>> [] ? rebalance_domains+0x152/0x290
>> [] ? run_rebalance_domains+0xdc/0x1d0
>> [] ? __do_softirq+0xfb/0x320
>> [] ? irq_exit+0x125/0x130
>> [] ? scheduler_ipi+0x97/0x160
>> [] ? smp_reschedule_interrupt+0x29/0x30
>> [] ? reschedule_interrupt+0x6e/0x80
>>  [] ? cpuidle_enter_state+0xcc/0x230
>> [] ? cpuidle_enter_state+0x9c/0x230
>> [] ? cpuidle_enter+0x17/0x20
>> [] ? cpu_startup_entry+0x38c/0x420
>> [] ? start_secondary+0x173/0x1e0
>>
>> Because divide-by-zero error happens in function
>>
>> update_group_capacity()
>>   update_cpu_capacity()
>> scale_rt_capacity()
>>   {
>>   ...
>>   total = sched_avg_period() + delta;
>>   used = div_u64(avg, total);
>>   ...
>>   }
>>
>> Seems this issue could be reproduced on all I tried stable 4.1 - last
>> kernel.
>>
>> To fix this issue, reset sysctl_sched_time_avg to default value
>> MSEC_PER_SEC if user input invalid value in function
>>
>> sched_avg_period()
>>
>> Reported-by: James Puthukattukaran 
>> Signed-off-by: Ethan Zhao 
>> ---
>>  Tested on stable 4.1, compiled on stable 4.13-rc5
>>  kernel/sched/sched.h | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
>> index eeef1a3..b398560 100644
>> --- a/kernel/sched/sched.h
>> +++ b/kernel/sched/sched.h
>> @@ -1620,6 +1620,9 @@ static inline void rq_last_tick_reset(struct rq *rq)
>>
>>  static inline u64 sched_avg_period(void)
>>  {
>> + if (unlikely(sysctl_sched_time_avg <= 0))
>> + sysctl_sched_time_avg = MSEC_PER_SEC;
>> +
>
> Sight, no.. you can set limits in the sysctl table.


Re: [PATCH 00/12] x86/crypto: Fix RBP usage in several crypto .S files

2017-09-01 Thread Eric Biggers
Hi Josh,

On Tue, Aug 29, 2017 at 01:05:33PM -0500, Josh Poimboeuf wrote:
> Many of the x86 crypto functions use RBP as a temporary register.  This
> breaks frame pointer convention, and breaks stack traces when unwinding
> from an interrupt in the crypto code.
> 
> Convert most* of them to leave RBP alone.
> 
> These pass the crypto boot tests for me.  Any further testing would be
> appreciated!
> 
> [*] There are still a few crypto files left that need fixing, but the
> fixes weren't trivial and nobody reported unwinder warnings about
> them yet, so I'm skipping them for now.
> 
> Josh Poimboeuf (12):
>   x86/crypto: Fix RBP usage in blowfish-x86_64-asm_64.S
>   x86/crypto: Fix RBP usage in camellia-x86_64-asm_64.S
>   x86/crypto: Fix RBP usage in cast5-avx-x86_64-asm_64.S
>   x86/crypto: Fix RBP usage in cast6-avx-x86_64-asm_64.S
>   x86/crypto: Fix RBP usage in des3_ede-asm_64.S
>   x86/crypto: Fix RBP usage in sha1_avx2_x86_64_asm.S
>   x86/crypto: Fix RBP usage in sha1_ssse3_asm.S
>   x86/crypto: Fix RBP usage in sha256-avx-asm.S
>   x86/crypto: Fix RBP usage in sha256-avx2-asm.S
>   x86/crypto: Fix RBP usage in sha256-ssse3-asm.S
>   x86/crypto: Fix RBP usage in sha512-avx2-asm.S
>   x86/crypto: Fix RBP usage in twofish-avx-x86_64-asm_64.S
> 

Thanks for fixing these!  I don't have time to review these in detail, but I ran
the crypto self-tests on the affected algorithms, and they all pass.  I also
benchmarked them before and after; the only noticable performance difference was
that sha256-avx2 and sha512-avx2 became a few percent slower.  I don't suppose
there is a way around that?  Otherwise it's probably not a big deal.

For reference, this was the list of affected algorithms I used:

shash: sha1-ssse3, sha1-avx, sha1-avx2, sha256-ssse3, sha256-avx, sha256-avx2,
sha512-ssse3, sha512-avx, sha512-avx2

cipher: blowfish-asm, camellia-asm, des3_ede-asm

skcipher: ecb-blowfish-asm, cbc-blowfish-asm, ctr-blowfish-asm, ecb-cast5-avx,
cbc-cast5-avx, ctr-cast5-avx, ecb-cast6-avx, cbc-cast6-avx, 
ctr-cast6-avx,
lrw-cast6-avx, xts-cast6-avx, ecb-camellia-asm, cbc-camellia-asm,
ctr-camellia-asm, lrw-camellia-asm, xts-camellia-asm, ecb-des3_ede-asm,
cbc-des3_ede-asm, ctr-des3_ede-asm, ecb-twofish-avx, cbc-twofish-avx,
ctr-twofish-avx, lrw-twofish-avx, xts-twofish-avx

Eric


Re: [PATCH 00/12] x86/crypto: Fix RBP usage in several crypto .S files

2017-09-01 Thread Eric Biggers
Hi Josh,

On Tue, Aug 29, 2017 at 01:05:33PM -0500, Josh Poimboeuf wrote:
> Many of the x86 crypto functions use RBP as a temporary register.  This
> breaks frame pointer convention, and breaks stack traces when unwinding
> from an interrupt in the crypto code.
> 
> Convert most* of them to leave RBP alone.
> 
> These pass the crypto boot tests for me.  Any further testing would be
> appreciated!
> 
> [*] There are still a few crypto files left that need fixing, but the
> fixes weren't trivial and nobody reported unwinder warnings about
> them yet, so I'm skipping them for now.
> 
> Josh Poimboeuf (12):
>   x86/crypto: Fix RBP usage in blowfish-x86_64-asm_64.S
>   x86/crypto: Fix RBP usage in camellia-x86_64-asm_64.S
>   x86/crypto: Fix RBP usage in cast5-avx-x86_64-asm_64.S
>   x86/crypto: Fix RBP usage in cast6-avx-x86_64-asm_64.S
>   x86/crypto: Fix RBP usage in des3_ede-asm_64.S
>   x86/crypto: Fix RBP usage in sha1_avx2_x86_64_asm.S
>   x86/crypto: Fix RBP usage in sha1_ssse3_asm.S
>   x86/crypto: Fix RBP usage in sha256-avx-asm.S
>   x86/crypto: Fix RBP usage in sha256-avx2-asm.S
>   x86/crypto: Fix RBP usage in sha256-ssse3-asm.S
>   x86/crypto: Fix RBP usage in sha512-avx2-asm.S
>   x86/crypto: Fix RBP usage in twofish-avx-x86_64-asm_64.S
> 

Thanks for fixing these!  I don't have time to review these in detail, but I ran
the crypto self-tests on the affected algorithms, and they all pass.  I also
benchmarked them before and after; the only noticable performance difference was
that sha256-avx2 and sha512-avx2 became a few percent slower.  I don't suppose
there is a way around that?  Otherwise it's probably not a big deal.

For reference, this was the list of affected algorithms I used:

shash: sha1-ssse3, sha1-avx, sha1-avx2, sha256-ssse3, sha256-avx, sha256-avx2,
sha512-ssse3, sha512-avx, sha512-avx2

cipher: blowfish-asm, camellia-asm, des3_ede-asm

skcipher: ecb-blowfish-asm, cbc-blowfish-asm, ctr-blowfish-asm, ecb-cast5-avx,
cbc-cast5-avx, ctr-cast5-avx, ecb-cast6-avx, cbc-cast6-avx, 
ctr-cast6-avx,
lrw-cast6-avx, xts-cast6-avx, ecb-camellia-asm, cbc-camellia-asm,
ctr-camellia-asm, lrw-camellia-asm, xts-camellia-asm, ecb-des3_ede-asm,
cbc-des3_ede-asm, ctr-des3_ede-asm, ecb-twofish-avx, cbc-twofish-avx,
ctr-twofish-avx, lrw-twofish-avx, xts-twofish-avx

Eric


[PATCH] f2fs: avoid needless inode updates

2017-09-01 Thread Jaegeuk Kim
If i_size wan't change at all, we don't need to write inode during fsync.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/f2fs.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 4b993961d81d..0d76b572484a 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -2267,11 +2267,11 @@ static inline bool f2fs_skip_inode_update(struct inode 
*inode, int dsync)
spin_unlock(>inode_lock[DIRTY_META]);
return ret;
}
-   if (!is_inode_flag_set(inode, FI_AUTO_RECOVER) ||
-   file_keep_isize(inode) ||
-   i_size_read(inode) & PAGE_MASK)
-   return false;
-   return F2FS_I(inode)->last_disk_size == i_size_read(inode);
+   if (F2FS_I(inode)->last_disk_size == i_size_read(inode))
+   return true;
+
+   return is_inode_flag_set(inode, FI_AUTO_RECOVER) &&
+   !file_keep_isize(inode) && !(i_size_read(inode) & PAGE_MASK);
 }
 
 static inline int f2fs_readonly(struct super_block *sb)
-- 
2.14.0.rc1.383.gd1ce394fe2-goog



[PATCH] f2fs: avoid needless inode updates

2017-09-01 Thread Jaegeuk Kim
If i_size wan't change at all, we don't need to write inode during fsync.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/f2fs.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 4b993961d81d..0d76b572484a 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -2267,11 +2267,11 @@ static inline bool f2fs_skip_inode_update(struct inode 
*inode, int dsync)
spin_unlock(>inode_lock[DIRTY_META]);
return ret;
}
-   if (!is_inode_flag_set(inode, FI_AUTO_RECOVER) ||
-   file_keep_isize(inode) ||
-   i_size_read(inode) & PAGE_MASK)
-   return false;
-   return F2FS_I(inode)->last_disk_size == i_size_read(inode);
+   if (F2FS_I(inode)->last_disk_size == i_size_read(inode))
+   return true;
+
+   return is_inode_flag_set(inode, FI_AUTO_RECOVER) &&
+   !file_keep_isize(inode) && !(i_size_read(inode) & PAGE_MASK);
 }
 
 static inline int f2fs_readonly(struct super_block *sb)
-- 
2.14.0.rc1.383.gd1ce394fe2-goog



[GIT PULL] ARM: SoC fixes for 4.13

2017-09-01 Thread Olof Johansson
Hi Linus,

Just a few final fixes for 4.13. See below for description. Please merge.


Thanks,

-Olof


The following changes since commit 93a4c8355e0e448d83f31801b4c72f66e4360975:

  ARM: dts: exynos: add needs-hpd for Odroid-XU3/4 (2017-08-23 21:43:29 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git armsoc-fixes

for you to fetch changes up to 6f71a925761e7843965a704eb6682ea337abb4a5:

  Merge tag 'mvebu-fixes-4.13-3' of git://git.infradead.org/linux-mvebu into 
fixes (2017-09-01 16:37:02 -0700)


ARM: SoC fixes for 4.13

A couple of late-arriving fixes before final 4.13:

 - A few reverts of DT bindings on Allwinner for their ethernet
   driver. Discussion didn't converge, and since bindings are considered
   ABI it makes sense to revert instead of having to support two bindings
   long-term.
 - A fix to enumerate GPIOs properly on Marvell Armada AP806


Maxime Ripard (3):
  dt-bindings: net: Revert sun8i dwmac binding
  arm64: dts: allwinner: Revert EMAC changes
  arm: dts: sunxi: Revert EMAC changes

Olof Johansson (2):
  Merge tag 'sunxi-fixes-for-4.13-3' of 
https://git.kernel.org/.../sunxi/linux into fixes
  Merge tag 'mvebu-fixes-4.13-3' of git://git.infradead.org/linux-mvebu 
into fixes

Thomas Petazzoni (1):
  arm64: dts: marvell: fix number of GPIOs in Armada AP806 description

 .../devicetree/bindings/net/dwmac-sun8i.txt| 84 --
 arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts  |  9 ---
 arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts| 19 -
 arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts  |  7 --
 arch/arm/boot/dts/sun8i-h3-orangepi-2.dts  |  8 ---
 arch/arm/boot/dts/sun8i-h3-orangepi-one.dts|  8 ---
 arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts|  5 --
 arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts |  8 ---
 arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts   | 22 --
 arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts | 16 -
 arch/arm/boot/dts/sunxi-h3-h5.dtsi | 26 ---
 .../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 16 -
 .../boot/dts/allwinner/sun50i-a64-pine64-plus.dts  | 15 
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 17 -
 .../dts/allwinner/sun50i-a64-sopine-baseboard.dts  | 16 -
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi  | 20 --
 .../boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts   | 17 -
 .../boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts  | 17 -
 .../dts/allwinner/sun50i-h5-orangepi-prime.dts | 17 -
 arch/arm64/boot/dts/marvell/armada-ap806.dtsi  |  4 +-
 20 files changed, 2 insertions(+), 349 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/net/dwmac-sun8i.txt


Re: [GIT PULL] ARM: at91: DT for 4.14#2

2017-09-01 Thread Olof Johansson
On Wed, Aug 30, 2017 at 06:39:05PM +0200, Alexandre Belloni wrote:
> Hi Olof,
> 
> As discussed, this replaces the previous pull request. The only change
> is the fixed up SoB.
> 
> The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877:
> 
>   Linux v4.13-rc1 (2017-07-15 15:22:10 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git 
> tags/at91-ab-4.14-dt2

Merged now, thanks.


-Olof


Re: [GIT PULL] ARM: at91: DT for 4.14#2

2017-09-01 Thread Olof Johansson
On Wed, Aug 30, 2017 at 06:39:05PM +0200, Alexandre Belloni wrote:
> Hi Olof,
> 
> As discussed, this replaces the previous pull request. The only change
> is the fixed up SoB.
> 
> The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877:
> 
>   Linux v4.13-rc1 (2017-07-15 15:22:10 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git 
> tags/at91-ab-4.14-dt2

Merged now, thanks.


-Olof


[GIT PULL] ARM: SoC fixes for 4.13

2017-09-01 Thread Olof Johansson
Hi Linus,

Just a few final fixes for 4.13. See below for description. Please merge.


Thanks,

-Olof


The following changes since commit 93a4c8355e0e448d83f31801b4c72f66e4360975:

  ARM: dts: exynos: add needs-hpd for Odroid-XU3/4 (2017-08-23 21:43:29 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git armsoc-fixes

for you to fetch changes up to 6f71a925761e7843965a704eb6682ea337abb4a5:

  Merge tag 'mvebu-fixes-4.13-3' of git://git.infradead.org/linux-mvebu into 
fixes (2017-09-01 16:37:02 -0700)


ARM: SoC fixes for 4.13

A couple of late-arriving fixes before final 4.13:

 - A few reverts of DT bindings on Allwinner for their ethernet
   driver. Discussion didn't converge, and since bindings are considered
   ABI it makes sense to revert instead of having to support two bindings
   long-term.
 - A fix to enumerate GPIOs properly on Marvell Armada AP806


Maxime Ripard (3):
  dt-bindings: net: Revert sun8i dwmac binding
  arm64: dts: allwinner: Revert EMAC changes
  arm: dts: sunxi: Revert EMAC changes

Olof Johansson (2):
  Merge tag 'sunxi-fixes-for-4.13-3' of 
https://git.kernel.org/.../sunxi/linux into fixes
  Merge tag 'mvebu-fixes-4.13-3' of git://git.infradead.org/linux-mvebu 
into fixes

Thomas Petazzoni (1):
  arm64: dts: marvell: fix number of GPIOs in Armada AP806 description

 .../devicetree/bindings/net/dwmac-sun8i.txt| 84 --
 arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts  |  9 ---
 arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts| 19 -
 arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts  |  7 --
 arch/arm/boot/dts/sun8i-h3-orangepi-2.dts  |  8 ---
 arch/arm/boot/dts/sun8i-h3-orangepi-one.dts|  8 ---
 arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts|  5 --
 arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts |  8 ---
 arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts   | 22 --
 arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts | 16 -
 arch/arm/boot/dts/sunxi-h3-h5.dtsi | 26 ---
 .../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 16 -
 .../boot/dts/allwinner/sun50i-a64-pine64-plus.dts  | 15 
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 17 -
 .../dts/allwinner/sun50i-a64-sopine-baseboard.dts  | 16 -
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi  | 20 --
 .../boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts   | 17 -
 .../boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts  | 17 -
 .../dts/allwinner/sun50i-h5-orangepi-prime.dts | 17 -
 arch/arm64/boot/dts/marvell/armada-ap806.dtsi  |  4 +-
 20 files changed, 2 insertions(+), 349 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/net/dwmac-sun8i.txt


[PATCH] CHROMIUM: devfreq: rk3399: Clear edev->dev drvdata before enabling dfi

2017-09-01 Thread Jeffy Chen
Currently we are using edev->dev drvdata to get rk3399-dmc data, but
it would be inited to edev in devfreq_event_add_edev.

So we need to clear the edev->dev drvdata before enabling dfi, to
prevent dfi from getting the wrong rk3399-dmc data when the irq
triggered too early.

Signed-off-by: Jeffy Chen 
---

 drivers/devfreq/rk3399_dmc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
index 1b89ebbad02c..12f9f03f349f 100644
--- a/drivers/devfreq/rk3399_dmc.c
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -429,6 +429,7 @@ static int rk3399_dmcfreq_probe(struct platform_device 
*pdev)
 
rk3399_devfreq_dmc_profile.initial_freq = data->rate;
 
+   platform_set_drvdata(pdev, NULL);
data->devfreq = devm_devfreq_add_device(dev,
   _devfreq_dmc_profile,
   "simple_ondemand",
-- 
2.11.0




[PATCH] CHROMIUM: devfreq: rk3399: Clear edev->dev drvdata before enabling dfi

2017-09-01 Thread Jeffy Chen
Currently we are using edev->dev drvdata to get rk3399-dmc data, but
it would be inited to edev in devfreq_event_add_edev.

So we need to clear the edev->dev drvdata before enabling dfi, to
prevent dfi from getting the wrong rk3399-dmc data when the irq
triggered too early.

Signed-off-by: Jeffy Chen 
---

 drivers/devfreq/rk3399_dmc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
index 1b89ebbad02c..12f9f03f349f 100644
--- a/drivers/devfreq/rk3399_dmc.c
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -429,6 +429,7 @@ static int rk3399_dmcfreq_probe(struct platform_device 
*pdev)
 
rk3399_devfreq_dmc_profile.initial_freq = data->rate;
 
+   platform_set_drvdata(pdev, NULL);
data->devfreq = devm_devfreq_add_device(dev,
   _devfreq_dmc_profile,
   "simple_ondemand",
-- 
2.11.0




Re: [RFC/PATCH] drivers/of/platform: Add powerpc 4xx embedded busses to default list

2017-09-01 Thread Benjamin Herrenschmidt
On Fri, 2017-09-01 at 10:24 -0500, Rob Herring wrote:
> On Thu, Aug 31, 2017 at 10:51 PM, Benjamin Herrenschmidt
>  wrote:
> > This allow to (slowly) migrate those embedded platforms
> > to of_platform_default_populate()
> > 
> > Signed-off-by: Benjamin Herrenschmidt 
> > ---
> > 
> > I'm here to collect acks (or comments :-) I'd like this to go via
> > the powerpc tree along with the patches converting some of the
> > platforms. I'll be adding more bus types if/when I start tackling
> > other powerpc embedded families but for now I'm dealing with 4xx.
> 
> Glad to see it.

So my end game is to remove the #ifndef CONFIG_PPC around
of_platform_default_populate_init(void). However, for that
to work, I need to add a way to disable that on some platforms.

However, it might take time, especially when it comes to dealing
with the old Macs or some more obscure embedded platforms.

So in the meantime, I'm thinking adding some kind of runtime way
of disabling this default populate. Would you be ok with that ?

Something like:

bool arch_wants_of_platform_defaults(void)

With a weak implementation returning true.

Cheers,
Ben.



Re: [RFC/PATCH] drivers/of/platform: Add powerpc 4xx embedded busses to default list

2017-09-01 Thread Benjamin Herrenschmidt
On Fri, 2017-09-01 at 10:24 -0500, Rob Herring wrote:
> On Thu, Aug 31, 2017 at 10:51 PM, Benjamin Herrenschmidt
>  wrote:
> > This allow to (slowly) migrate those embedded platforms
> > to of_platform_default_populate()
> > 
> > Signed-off-by: Benjamin Herrenschmidt 
> > ---
> > 
> > I'm here to collect acks (or comments :-) I'd like this to go via
> > the powerpc tree along with the patches converting some of the
> > platforms. I'll be adding more bus types if/when I start tackling
> > other powerpc embedded families but for now I'm dealing with 4xx.
> 
> Glad to see it.

So my end game is to remove the #ifndef CONFIG_PPC around
of_platform_default_populate_init(void). However, for that
to work, I need to add a way to disable that on some platforms.

However, it might take time, especially when it comes to dealing
with the old Macs or some more obscure embedded platforms.

So in the meantime, I'm thinking adding some kind of runtime way
of disabling this default populate. Would you be ok with that ?

Something like:

bool arch_wants_of_platform_defaults(void)

With a weak implementation returning true.

Cheers,
Ben.



  1   2   3   4   5   6   7   8   9   10   >