[PATCH] drm: amdgpu: mark symbols static where possible

[Baoyou Xie]

We get a few warnings when building kernel with W=1:
drivers/gpu/drm/amd/amdgpu/cz_smc.c:51:5: warning: no previous prototype for 
'cz_send_msg_to_smc_async' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/cz_smc.c:143:5: warning: no previous prototype for 
'cz_write_smc_sram_dword' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/iceland_smc.c:124:6: warning: no previous prototype 
for 'iceland_start_smc' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:3926:6: warning: no previous prototype 
for 'gfx_v8_0_rlc_stop' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c:94:6: warning: no previous prototype 
for 'amdgpu_job_free_cb' [-Wmissing-prototypes]


In fact, these functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c  | 4 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c   | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c  | 2 +-
 drivers/gpu/drm/amd/amdgpu/cz_smc.c  | 4 ++--
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 2 +-
 drivers/gpu/drm/amd/amdgpu/iceland_smc.c | 8 
 6 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
index bc0440f..a831218 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
@@ -616,7 +616,7 @@ static int amdgpu_cgs_irq_put(struct cgs_device 
*cgs_device, unsigned src_id, un
return amdgpu_irq_put(adev, adev->irq.sources[src_id], type);
 }
 
-int amdgpu_cgs_set_clockgating_state(struct cgs_device *cgs_device,
+static int amdgpu_cgs_set_clockgating_state(struct cgs_device *cgs_device,
  enum amd_ip_block_type block_type,
  enum amd_clockgating_state state)
 {
@@ -637,7 +637,7 @@ int amdgpu_cgs_set_clockgating_state(struct cgs_device 
*cgs_device,
return r;
 }
 
-int amdgpu_cgs_set_powergating_state(struct cgs_device *cgs_device,
+static int amdgpu_cgs_set_powergating_state(struct cgs_device *cgs_device,
  enum amd_ip_block_type block_type,
  enum amd_powergating_state state)
 {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 0307ff5..f65bdaf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -287,7 +287,7 @@ static u64 amdgpu_cs_get_threshold_for_moves(struct 
amdgpu_device *adev)
return max(bytes_moved_threshold, 1024*1024ull);
 }
 
-int amdgpu_cs_list_validate(struct amdgpu_cs_parser *p,
+static int amdgpu_cs_list_validate(struct amdgpu_cs_parser *p,
struct list_head *validated)
 {
struct amdgpu_bo_list_entry *lobj;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index 6674d40..31bfe3a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -91,7 +91,7 @@ void amdgpu_job_free_resources(struct amdgpu_job *job)
amdgpu_ib_free(job->adev, >ibs[i], f);
 }
 
-void amdgpu_job_free_cb(struct amd_sched_job *s_job)
+static void amdgpu_job_free_cb(struct amd_sched_job *s_job)
 {
struct amdgpu_job *job = container_of(s_job, struct amdgpu_job, base);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/cz_smc.c 
b/drivers/gpu/drm/amd/amdgpu/cz_smc.c
index ac7fee7..c80c2e9 100644
--- a/drivers/gpu/drm/amd/amdgpu/cz_smc.c
+++ b/drivers/gpu/drm/amd/amdgpu/cz_smc.c
@@ -48,7 +48,7 @@ static struct cz_smu_private_data *cz_smu_get_priv(struct 
amdgpu_device *adev)
return priv;
 }
 
-int cz_send_msg_to_smc_async(struct amdgpu_device *adev, u16 msg)
+static int cz_send_msg_to_smc_async(struct amdgpu_device *adev, u16 msg)
 {
int i;
u32 content = 0, tmp;
@@ -140,7 +140,7 @@ int cz_read_smc_sram_dword(struct amdgpu_device *adev, u32 
smc_address,
return 0;
 }
 
-int cz_write_smc_sram_dword(struct amdgpu_device *adev, u32 smc_address,
+static int cz_write_smc_sram_dword(struct amdgpu_device *adev, u32 smc_address,
u32 value, u32 limit)
 {
int ret;
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index bff8668..6997f7c 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -3923,7 +3923,7 @@ static void gfx_v8_0_init_pg(struct amdgpu_device *adev)
}
 }
 
-void gfx_v8_0_rlc_stop(struct amdgpu_device *adev)
+static void gfx_v8_0_rlc_stop(struct amdgpu_device *adev)
 {
u32 tmp = RREG32(mmRLC_CNTL);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/iceland_smc.c 
b/drivers/gpu/drm/amd/amdgpu/iceland_smc.c
index 2118399..ef7c27d 100644
--- 

[PATCH] drm: amdgpu: mark symbols static where possible

[Baoyou Xie]

We get a few warnings when building kernel with W=1:
drivers/gpu/drm/amd/amdgpu/cz_smc.c:51:5: warning: no previous prototype for 
'cz_send_msg_to_smc_async' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/cz_smc.c:143:5: warning: no previous prototype for 
'cz_write_smc_sram_dword' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/iceland_smc.c:124:6: warning: no previous prototype 
for 'iceland_start_smc' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:3926:6: warning: no previous prototype 
for 'gfx_v8_0_rlc_stop' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c:94:6: warning: no previous prototype 
for 'amdgpu_job_free_cb' [-Wmissing-prototypes]


In fact, these functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c  | 4 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c   | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c  | 2 +-
 drivers/gpu/drm/amd/amdgpu/cz_smc.c  | 4 ++--
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 2 +-
 drivers/gpu/drm/amd/amdgpu/iceland_smc.c | 8 
 6 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
index bc0440f..a831218 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
@@ -616,7 +616,7 @@ static int amdgpu_cgs_irq_put(struct cgs_device 
*cgs_device, unsigned src_id, un
return amdgpu_irq_put(adev, adev->irq.sources[src_id], type);
 }
 
-int amdgpu_cgs_set_clockgating_state(struct cgs_device *cgs_device,
+static int amdgpu_cgs_set_clockgating_state(struct cgs_device *cgs_device,
  enum amd_ip_block_type block_type,
  enum amd_clockgating_state state)
 {
@@ -637,7 +637,7 @@ int amdgpu_cgs_set_clockgating_state(struct cgs_device 
*cgs_device,
return r;
 }
 
-int amdgpu_cgs_set_powergating_state(struct cgs_device *cgs_device,
+static int amdgpu_cgs_set_powergating_state(struct cgs_device *cgs_device,
  enum amd_ip_block_type block_type,
  enum amd_powergating_state state)
 {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 0307ff5..f65bdaf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -287,7 +287,7 @@ static u64 amdgpu_cs_get_threshold_for_moves(struct 
amdgpu_device *adev)
return max(bytes_moved_threshold, 1024*1024ull);
 }
 
-int amdgpu_cs_list_validate(struct amdgpu_cs_parser *p,
+static int amdgpu_cs_list_validate(struct amdgpu_cs_parser *p,
struct list_head *validated)
 {
struct amdgpu_bo_list_entry *lobj;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index 6674d40..31bfe3a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -91,7 +91,7 @@ void amdgpu_job_free_resources(struct amdgpu_job *job)
amdgpu_ib_free(job->adev, >ibs[i], f);
 }
 
-void amdgpu_job_free_cb(struct amd_sched_job *s_job)
+static void amdgpu_job_free_cb(struct amd_sched_job *s_job)
 {
struct amdgpu_job *job = container_of(s_job, struct amdgpu_job, base);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/cz_smc.c 
b/drivers/gpu/drm/amd/amdgpu/cz_smc.c
index ac7fee7..c80c2e9 100644
--- a/drivers/gpu/drm/amd/amdgpu/cz_smc.c
+++ b/drivers/gpu/drm/amd/amdgpu/cz_smc.c
@@ -48,7 +48,7 @@ static struct cz_smu_private_data *cz_smu_get_priv(struct 
amdgpu_device *adev)
return priv;
 }
 
-int cz_send_msg_to_smc_async(struct amdgpu_device *adev, u16 msg)
+static int cz_send_msg_to_smc_async(struct amdgpu_device *adev, u16 msg)
 {
int i;
u32 content = 0, tmp;
@@ -140,7 +140,7 @@ int cz_read_smc_sram_dword(struct amdgpu_device *adev, u32 
smc_address,
return 0;
 }
 
-int cz_write_smc_sram_dword(struct amdgpu_device *adev, u32 smc_address,
+static int cz_write_smc_sram_dword(struct amdgpu_device *adev, u32 smc_address,
u32 value, u32 limit)
 {
int ret;
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index bff8668..6997f7c 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -3923,7 +3923,7 @@ static void gfx_v8_0_init_pg(struct amdgpu_device *adev)
}
 }
 
-void gfx_v8_0_rlc_stop(struct amdgpu_device *adev)
+static void gfx_v8_0_rlc_stop(struct amdgpu_device *adev)
 {
u32 tmp = RREG32(mmRLC_CNTL);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/iceland_smc.c 
b/drivers/gpu/drm/amd/amdgpu/iceland_smc.c
index 2118399..ef7c27d 100644
--- a/drivers/gpu/drm/amd/amdgpu/iceland_smc.c
+++ 

Re: [PATCH] asus-laptop: get rid of parse_arg()

[Giedrius Statkevičius]

On Wed, Aug 17, 2016 at 11:23:15AM -0700, Darren Hart wrote:
> On Tue, Aug 16, 2016 at 12:49:50PM +0300, Giedrius Statkevičius wrote:
> > On Fri, Aug 12, 2016 at 02:40:02PM -0700, Darren Hart wrote:
> > > On Sat, Aug 06, 2016 at 08:00:26PM +0300, Giedrius Statkevičius wrote:
> > > > On Fri, Aug 05, 2016 at 04:15:07PM -0700, Darren Hart wrote:
> > > > > On Fri, Aug 05, 2016 at 11:57:10PM +0300, Giedrius Statkevičius wrote:
> > > > > > parse_arg() duplicates the funcionality of kstrtoint() so use the 
> > > > > > latter
> > > > > > function instead. There is no funcionality change except that in the
> > > > > > case of input being too big -ERANGE will be returned instead of 
> > > > > > -EINVAL
> > > > > > which is not bad because -ERANGE makes more sense here. The check 
> > > > > > for
> > > > > > !count is already done by the sysfs core so no need to duplicate it
> > > > > > again. Also, add some minor corrections to error handling to 
> > > > > > accommodate
> > > > > > the change in return values (parse_arg returned count if everything
> > > > > > succeeded whereas kstrtoint returns 0 in the same situation)
> > > > > > 
> > > > > > As a result of this patch asus-laptop.ko size is reduced by almost 
> > > > > > 1%:
> > > > > > add/remove: 0/1 grow/shrink: 1/6 up/down: 1/-149 (-148)
> > > > > > function old new   delta
> > > > > > __UNIQUE_ID_vermagic0 69  70  +1
> > > > > > ls_switch_store  133 117 -16
> > > > > > ledd_store   175 159 -16
> > > > > > display_store157 141 -16
> > > > > > ls_level_store   193 176 -17
> > > > > > gps_store200 178 -22
> > > > > > sysfs_acpi_set.isra  148 125 -23
> > > > > > parse_arg.part39   - -39
> > > > > > Total: Before=19160, After=19012, chg -0.77%
> > > > > > 
> > > > > > Signed-off-by: Giedrius Statkevičius 
> > > > > > 
> > > > > > ---
> > > > > >  drivers/platform/x86/asus-laptop.c | 77 
> > > > > > ++
> > > > > >  1 file changed, 36 insertions(+), 41 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/platform/x86/asus-laptop.c 
> > > > > > b/drivers/platform/x86/asus-laptop.c
> > > > > > index 15f1311..28551f5 100644
> > > > > > --- a/drivers/platform/x86/asus-laptop.c
> > > > > > +++ b/drivers/platform/x86/asus-laptop.c
> > > > > > @@ -932,30 +932,19 @@ static ssize_t infos_show(struct device *dev, 
> > > > > > struct device_attribute *attr,
> > > > > >  }
> > > > > >  static DEVICE_ATTR_RO(infos);
> > > > > >  
> > > > > > -static int parse_arg(const char *buf, unsigned long count, int 
> > > > > > *val)
> > > > > > -{
> > > > > > -   if (!count)
> > > > > > -   return 0;
> > > > > > -   if (count > 31)
> > > > > > -   return -EINVAL;
> > > > > > -   if (sscanf(buf, "%i", val) != 1)
> > > > > > -   return -EINVAL;
> > > > > > -   return count;
> > > > > > -}
> > > > > > -
> > > > > >  static ssize_t sysfs_acpi_set(struct asus_laptop *asus,
> > > > > >   const char *buf, size_t count,
> > > > > >   const char *method)
> > > > > >  {
> > > > > > int rv, value;
> > > > > >  
> > > > > > -   rv = parse_arg(buf, count, );
> > > > > > -   if (rv <= 0)
> > > > > > +   rv = kstrtoint(buf, 0, );
> > > > > > +   if (rv < 0)
> > > > > > return rv;
> > > > > >  
> > > > > > if (write_acpi_int(asus->handle, method, value))
> > > > > > return -ENODEV;
> > > > > > -   return rv;
> > > > > > +   return count;
> > > > > 
> > > > > This makes explicit what was hidden before - count is merely a range 
> > > > > check, it
> > > > > isn't used in parsing the string... I'm not sure if this is a 
> > > > > problem, but it
> > > > > caught my interest. If count is passed as 12, but buf only contains 3 
> > > > > character,
> > > > > it may succeed and return 12. I suppose this is a failure in the 
> > > > > caller, and
> > > > > doesn't impact this function - unless the caller isn't expected to 
> > > > > properly
> > > > > terminate the string... but if that were the case, it would have 
> > > > > failed
> > > > > previously as we didn't check for that in parse_arg either this 
> > > > > is fine as
> > > > > is I suppose - can be addressed separately if need be.
> > > > > 
> > > 
> > > OK, good - thanks for the context.
> > > 
> > > > According to Documentation/filesystems/sysfs.txt:
> > > > "On write(2), ... A terminating null is added after the data on stores. 
> > > > This
> > > > makes functions like sysfs_streq() safe to use."
> > > > So it should be guaranteed that the buffer is a proper C string. Also, 
> > > > we could
> > > > say kstrtoint() or sscanf() uses 

Re: [PATCH] asus-laptop: get rid of parse_arg()

[Giedrius Statkevičius]

On Wed, Aug 17, 2016 at 11:23:15AM -0700, Darren Hart wrote:
> On Tue, Aug 16, 2016 at 12:49:50PM +0300, Giedrius Statkevičius wrote:
> > On Fri, Aug 12, 2016 at 02:40:02PM -0700, Darren Hart wrote:
> > > On Sat, Aug 06, 2016 at 08:00:26PM +0300, Giedrius Statkevičius wrote:
> > > > On Fri, Aug 05, 2016 at 04:15:07PM -0700, Darren Hart wrote:
> > > > > On Fri, Aug 05, 2016 at 11:57:10PM +0300, Giedrius Statkevičius wrote:
> > > > > > parse_arg() duplicates the funcionality of kstrtoint() so use the 
> > > > > > latter
> > > > > > function instead. There is no funcionality change except that in the
> > > > > > case of input being too big -ERANGE will be returned instead of 
> > > > > > -EINVAL
> > > > > > which is not bad because -ERANGE makes more sense here. The check 
> > > > > > for
> > > > > > !count is already done by the sysfs core so no need to duplicate it
> > > > > > again. Also, add some minor corrections to error handling to 
> > > > > > accommodate
> > > > > > the change in return values (parse_arg returned count if everything
> > > > > > succeeded whereas kstrtoint returns 0 in the same situation)
> > > > > > 
> > > > > > As a result of this patch asus-laptop.ko size is reduced by almost 
> > > > > > 1%:
> > > > > > add/remove: 0/1 grow/shrink: 1/6 up/down: 1/-149 (-148)
> > > > > > function old new   delta
> > > > > > __UNIQUE_ID_vermagic0 69  70  +1
> > > > > > ls_switch_store  133 117 -16
> > > > > > ledd_store   175 159 -16
> > > > > > display_store157 141 -16
> > > > > > ls_level_store   193 176 -17
> > > > > > gps_store200 178 -22
> > > > > > sysfs_acpi_set.isra  148 125 -23
> > > > > > parse_arg.part39   - -39
> > > > > > Total: Before=19160, After=19012, chg -0.77%
> > > > > > 
> > > > > > Signed-off-by: Giedrius Statkevičius 
> > > > > > 
> > > > > > ---
> > > > > >  drivers/platform/x86/asus-laptop.c | 77 
> > > > > > ++
> > > > > >  1 file changed, 36 insertions(+), 41 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/platform/x86/asus-laptop.c 
> > > > > > b/drivers/platform/x86/asus-laptop.c
> > > > > > index 15f1311..28551f5 100644
> > > > > > --- a/drivers/platform/x86/asus-laptop.c
> > > > > > +++ b/drivers/platform/x86/asus-laptop.c
> > > > > > @@ -932,30 +932,19 @@ static ssize_t infos_show(struct device *dev, 
> > > > > > struct device_attribute *attr,
> > > > > >  }
> > > > > >  static DEVICE_ATTR_RO(infos);
> > > > > >  
> > > > > > -static int parse_arg(const char *buf, unsigned long count, int 
> > > > > > *val)
> > > > > > -{
> > > > > > -   if (!count)
> > > > > > -   return 0;
> > > > > > -   if (count > 31)
> > > > > > -   return -EINVAL;
> > > > > > -   if (sscanf(buf, "%i", val) != 1)
> > > > > > -   return -EINVAL;
> > > > > > -   return count;
> > > > > > -}
> > > > > > -
> > > > > >  static ssize_t sysfs_acpi_set(struct asus_laptop *asus,
> > > > > >   const char *buf, size_t count,
> > > > > >   const char *method)
> > > > > >  {
> > > > > > int rv, value;
> > > > > >  
> > > > > > -   rv = parse_arg(buf, count, );
> > > > > > -   if (rv <= 0)
> > > > > > +   rv = kstrtoint(buf, 0, );
> > > > > > +   if (rv < 0)
> > > > > > return rv;
> > > > > >  
> > > > > > if (write_acpi_int(asus->handle, method, value))
> > > > > > return -ENODEV;
> > > > > > -   return rv;
> > > > > > +   return count;
> > > > > 
> > > > > This makes explicit what was hidden before - count is merely a range 
> > > > > check, it
> > > > > isn't used in parsing the string... I'm not sure if this is a 
> > > > > problem, but it
> > > > > caught my interest. If count is passed as 12, but buf only contains 3 
> > > > > character,
> > > > > it may succeed and return 12. I suppose this is a failure in the 
> > > > > caller, and
> > > > > doesn't impact this function - unless the caller isn't expected to 
> > > > > properly
> > > > > terminate the string... but if that were the case, it would have 
> > > > > failed
> > > > > previously as we didn't check for that in parse_arg either this 
> > > > > is fine as
> > > > > is I suppose - can be addressed separately if need be.
> > > > > 
> > > 
> > > OK, good - thanks for the context.
> > > 
> > > > According to Documentation/filesystems/sysfs.txt:
> > > > "On write(2), ... A terminating null is added after the data on stores. 
> > > > This
> > > > makes functions like sysfs_streq() safe to use."
> > > > So it should be guaranteed that the buffer is a proper C string. Also, 
> > > > we could
> > > > say kstrtoint() or sscanf() uses all of the buffer so it is safe to 

[PATCH] jfs: Simplify code

[Christophe JAILLET]

Calling 'list_splice' followed by 'INIT_LIST_HEAD' is equivalent to
'list_splice_init'.

This has been spotted with the following coccinelle script:
/
@@
expression y,z;
@@

-   list_splice(y,z);
-   INIT_LIST_HEAD(y);
+   list_splice_init(y,z);

Signed-off-by: Christophe JAILLET 
---
 fs/jfs/jfs_txnmgr.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/jfs/jfs_txnmgr.c b/fs/jfs/jfs_txnmgr.c
index 2e58978d6f45..4d973524c887 100644
--- a/fs/jfs/jfs_txnmgr.c
+++ b/fs/jfs/jfs_txnmgr.c
@@ -2893,8 +2893,7 @@ restart:
 * on anon_list2.  Let's check.
 */
if (!list_empty(_list2)) {
-   list_splice(_list2, _list);
-   INIT_LIST_HEAD(_list2);
+   list_splice_init(_list2, _list);
goto restart;
}
TXN_UNLOCK();
-- 
2.7.4

[PATCH] jfs: Simplify code

[Christophe JAILLET]

Calling 'list_splice' followed by 'INIT_LIST_HEAD' is equivalent to
'list_splice_init'.

This has been spotted with the following coccinelle script:
/
@@
expression y,z;
@@

-   list_splice(y,z);
-   INIT_LIST_HEAD(y);
+   list_splice_init(y,z);

Signed-off-by: Christophe JAILLET 
---
 fs/jfs/jfs_txnmgr.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/jfs/jfs_txnmgr.c b/fs/jfs/jfs_txnmgr.c
index 2e58978d6f45..4d973524c887 100644
--- a/fs/jfs/jfs_txnmgr.c
+++ b/fs/jfs/jfs_txnmgr.c
@@ -2893,8 +2893,7 @@ restart:
 * on anon_list2.  Let's check.
 */
if (!list_empty(_list2)) {
-   list_splice(_list2, _list);
-   INIT_LIST_HEAD(_list2);
+   list_splice_init(_list2, _list);
goto restart;
}
TXN_UNLOCK();
-- 
2.7.4

[PATCH] fs/pnode.c: Simplify code

[Christophe JAILLET]

Calling 'list_splice' followed by 'INIT_LIST_HEAD' is equivalent to
'list_splice_init'.

This has been spotted with the following coccinelle script:
/
@@
expression y,z;
@@

-   list_splice(y,z);
-   INIT_LIST_HEAD(y);
+   list_splice_init(y,z);

Signed-off-by: Christophe JAILLET 
---
 fs/pnode.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/pnode.c b/fs/pnode.c
index 99899705b105..3d3513ee4380 100644
--- a/fs/pnode.c
+++ b/fs/pnode.c
@@ -97,8 +97,8 @@ static int do_make_slave(struct mount *mnt)
list_for_each_entry(slave_mnt, >mnt_slave_list, mnt_slave)
slave_mnt->mnt_master = master;
list_move(>mnt_slave, >mnt_slave_list);
-   list_splice(>mnt_slave_list, master->mnt_slave_list.prev);
-   INIT_LIST_HEAD(>mnt_slave_list);
+   list_splice_init(>mnt_slave_list,
+master->mnt_slave_list.prev);
} else {
struct list_head *p = >mnt_slave_list;
while (!list_empty(p)) {
-- 
2.7.4

Re: [PATCH 8/7] net/netfilter/nf_conntrack_core: Remove another memory barrier

[Manfred Spraul]

On 09/02/2016 09:22 PM, Peter Zijlstra wrote:

On Fri, Sep 02, 2016 at 08:35:55AM +0200, Manfred Spraul wrote:

On 09/01/2016 06:41 PM, Peter Zijlstra wrote:

On Thu, Sep 01, 2016 at 04:30:39PM +0100, Will Deacon wrote:

On Thu, Sep 01, 2016 at 05:27:52PM +0200, Manfred Spraul wrote:

Since spin_unlock_wait() is defined as equivalent to spin_lock();
spin_unlock(), the memory barrier before spin_unlock_wait() is
also not required.

Note that ACQUIRE+RELEASE isn't a barrier.

Both are semi-permeable and things can cross in the middle, like:


x = 1;
LOCK
UNLOCK
r = y;

can (validly) get re-ordered like:

LOCK
r = y;
x = 1;
UNLOCK

So if you want things ordered, as I think you do, I think the smp_mb()
is still needed.

CPU1:
x=1; /* without WRITE_ONCE */
LOCK(l);
UNLOCK(l);

smp_store_release(x,0)


CPU2;
LOCK(l)
if (smp_load_acquire(x)==1) goto slow_path

UNLOCK(l)

Ordering is enforced because both CPUs access the same lock.

x=1 can't be reordered past the UNLOCK(l), I don't see that further
guarantees are necessary.

Correct?

Correct, sadly implementations do not comply :/ In fact, even x86 is
broken here.

I spoke to Will earlier today and he suggests either making
spin_unlock_wait() stronger to avoids any and all such surprises or just
getting rid of the thing.

I'm not sure which way we should go, but please hold off on these two
patches until I've had a chance to audit all of those implementations
again.

For me, it doesn't really matter.
spin_unlock_wait() as "R", as "RAcq" or as "spin_lock(); spin_lock();" - 
I just want a usable definition for ipc/sem.c


So (just to keep Andrew updated):
Ready for merging is: (Bugfixes, safe just with spin_unlock_wait() as "R"):

- 45a449340cd1 ("ipc/sem.c: fix complex_count vs. simple op race")
  Cc stable, back to 3.10 ...
- 7fd5653d9986 ("net/netfilter/nf_conntrack_core: Fix memory barriers.")
  Cc stable, back to ~4.5

--
Manfred

[PATCH] fs/pnode.c: Simplify code

[Christophe JAILLET]

Calling 'list_splice' followed by 'INIT_LIST_HEAD' is equivalent to
'list_splice_init'.

This has been spotted with the following coccinelle script:
/
@@
expression y,z;
@@

-   list_splice(y,z);
-   INIT_LIST_HEAD(y);
+   list_splice_init(y,z);

Signed-off-by: Christophe JAILLET 
---
 fs/pnode.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/pnode.c b/fs/pnode.c
index 99899705b105..3d3513ee4380 100644
--- a/fs/pnode.c
+++ b/fs/pnode.c
@@ -97,8 +97,8 @@ static int do_make_slave(struct mount *mnt)
list_for_each_entry(slave_mnt, >mnt_slave_list, mnt_slave)
slave_mnt->mnt_master = master;
list_move(>mnt_slave, >mnt_slave_list);
-   list_splice(>mnt_slave_list, master->mnt_slave_list.prev);
-   INIT_LIST_HEAD(>mnt_slave_list);
+   list_splice_init(>mnt_slave_list,
+master->mnt_slave_list.prev);
} else {
struct list_head *p = >mnt_slave_list;
while (!list_empty(p)) {
-- 
2.7.4

Re: [PATCH 8/7] net/netfilter/nf_conntrack_core: Remove another memory barrier

[Manfred Spraul]

On 09/02/2016 09:22 PM, Peter Zijlstra wrote:

On Fri, Sep 02, 2016 at 08:35:55AM +0200, Manfred Spraul wrote:

On 09/01/2016 06:41 PM, Peter Zijlstra wrote:

On Thu, Sep 01, 2016 at 04:30:39PM +0100, Will Deacon wrote:

On Thu, Sep 01, 2016 at 05:27:52PM +0200, Manfred Spraul wrote:

Since spin_unlock_wait() is defined as equivalent to spin_lock();
spin_unlock(), the memory barrier before spin_unlock_wait() is
also not required.

Note that ACQUIRE+RELEASE isn't a barrier.

Both are semi-permeable and things can cross in the middle, like:


x = 1;
LOCK
UNLOCK
r = y;

can (validly) get re-ordered like:

LOCK
r = y;
x = 1;
UNLOCK

So if you want things ordered, as I think you do, I think the smp_mb()
is still needed.

CPU1:
x=1; /* without WRITE_ONCE */
LOCK(l);
UNLOCK(l);

smp_store_release(x,0)


CPU2;
LOCK(l)
if (smp_load_acquire(x)==1) goto slow_path

UNLOCK(l)

Ordering is enforced because both CPUs access the same lock.

x=1 can't be reordered past the UNLOCK(l), I don't see that further
guarantees are necessary.

Correct?

Correct, sadly implementations do not comply :/ In fact, even x86 is
broken here.

I spoke to Will earlier today and he suggests either making
spin_unlock_wait() stronger to avoids any and all such surprises or just
getting rid of the thing.

I'm not sure which way we should go, but please hold off on these two
patches until I've had a chance to audit all of those implementations
again.

For me, it doesn't really matter.
spin_unlock_wait() as "R", as "RAcq" or as "spin_lock(); spin_lock();" - 
I just want a usable definition for ipc/sem.c


So (just to keep Andrew updated):
Ready for merging is: (Bugfixes, safe just with spin_unlock_wait() as "R"):

- 45a449340cd1 ("ipc/sem.c: fix complex_count vs. simple op race")
  Cc stable, back to 3.10 ...
- 7fd5653d9986 ("net/netfilter/nf_conntrack_core: Fix memory barriers.")
  Cc stable, back to ~4.5

--
Manfred

[PATCH] RDS: Simplify code

[Christophe JAILLET]

Calling 'list_splice' followed by 'INIT_LIST_HEAD' is equivalent to
'list_splice_init'.

This has been spotted with the following coccinelle script:
/
@@
expression y,z;
@@

-   list_splice(y,z);
-   INIT_LIST_HEAD(y);
+   list_splice_init(y,z);

Signed-off-by: Christophe JAILLET 
---
 net/rds/loop.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/net/rds/loop.c b/net/rds/loop.c
index f2bf78de5688..c3e6da4fdf97 100644
--- a/net/rds/loop.c
+++ b/net/rds/loop.c
@@ -167,8 +167,7 @@ void rds_loop_exit(void)
 
/* avoid calling conn_destroy with irqs off */
spin_lock_irq(_conns_lock);
-   list_splice(_conns, _list);
-   INIT_LIST_HEAD(_conns);
+   list_splice_init(_conns, _list);
spin_unlock_irq(_conns_lock);
 
list_for_each_entry_safe(lc, _lc, _list, loop_node) {
-- 
2.7.4

Re: [PATCH v2 0/3] Add Platform MHU mailbox driver for Amlogic GXBB

[Jassi Brar]

On Sat, Sep 3, 2016 at 5:04 AM, Kevin Hilman  wrote:
> Hi Jassi,
>
> Neil Armstrong  writes:
>
>> In order to support Mailbox links for the Amlogic GXBB SoC, add a generic
>> platform MHU driver based on arm_mhu.c.
>>
>> This patchset follows a RFC thread along the GXBB SCPI support at :
>> http://lkml.kernel.org/r/1466503374-28841-1-git-send-email-narmstr...@baylibre.com
>> And specific MHU discussions at :
>> http://lkml.kernel.org/r/CABb+yY3HqJG2+GMWCWF9PomxobrwWGZ=tze5nvxpchmddlh...@mail.gmail.com
>>
>> Changes since v1 at 
>> http://lkml.kernel.org/r/1470732737-18391-1-git-send-email-narmstr...@baylibre.com
>>  :
>>  - Fix irq to signed to detect platform_get_irq() failures
>>  - Introduced back the secure channel
>>  - Fixed indexes
>
> How is this version looking to you?
>
> With your review/ack on the driver, I'd be happy to take it via the
> amlogic tree as there shouldn't be any conflicts with your tree.
>
I am ok with the driver, but I don't understand how it helps going via
amlogic tree. I would like to send a pull request every release ;)

cheers.

[PATCH] RDS: Simplify code

[Christophe JAILLET]

Calling 'list_splice' followed by 'INIT_LIST_HEAD' is equivalent to
'list_splice_init'.

This has been spotted with the following coccinelle script:
/
@@
expression y,z;
@@

-   list_splice(y,z);
-   INIT_LIST_HEAD(y);
+   list_splice_init(y,z);

Signed-off-by: Christophe JAILLET 
---
 net/rds/loop.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/net/rds/loop.c b/net/rds/loop.c
index f2bf78de5688..c3e6da4fdf97 100644
--- a/net/rds/loop.c
+++ b/net/rds/loop.c
@@ -167,8 +167,7 @@ void rds_loop_exit(void)
 
/* avoid calling conn_destroy with irqs off */
spin_lock_irq(_conns_lock);
-   list_splice(_conns, _list);
-   INIT_LIST_HEAD(_conns);
+   list_splice_init(_conns, _list);
spin_unlock_irq(_conns_lock);
 
list_for_each_entry_safe(lc, _lc, _list, loop_node) {
-- 
2.7.4

Re: [PATCH v2 0/3] Add Platform MHU mailbox driver for Amlogic GXBB

[Jassi Brar]

On Sat, Sep 3, 2016 at 5:04 AM, Kevin Hilman  wrote:
> Hi Jassi,
>
> Neil Armstrong  writes:
>
>> In order to support Mailbox links for the Amlogic GXBB SoC, add a generic
>> platform MHU driver based on arm_mhu.c.
>>
>> This patchset follows a RFC thread along the GXBB SCPI support at :
>> http://lkml.kernel.org/r/1466503374-28841-1-git-send-email-narmstr...@baylibre.com
>> And specific MHU discussions at :
>> http://lkml.kernel.org/r/CABb+yY3HqJG2+GMWCWF9PomxobrwWGZ=tze5nvxpchmddlh...@mail.gmail.com
>>
>> Changes since v1 at 
>> http://lkml.kernel.org/r/1470732737-18391-1-git-send-email-narmstr...@baylibre.com
>>  :
>>  - Fix irq to signed to detect platform_get_irq() failures
>>  - Introduced back the secure channel
>>  - Fixed indexes
>
> How is this version looking to you?
>
> With your review/ack on the driver, I'd be happy to take it via the
> amlogic tree as there shouldn't be any conflicts with your tree.
>
I am ok with the driver, but I don't understand how it helps going via
amlogic tree. I would like to send a pull request every release ;)

cheers.

[PATCH 5/5 v2] arm64: defconfig: Enable R-Car Gen3 thermal support

[Khiem Nguyen]

Signed-off-by: Khiem Nguyen 
---

v2:
 * No change
 
 arch/arm64/configs/defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 07cd615..cdb7b40 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -251,8 +251,10 @@ CONFIG_SENSORS_LM90=m
 CONFIG_SENSORS_INA2XX=m
 CONFIG_SENSORS_ARM_SCPI=y
 CONFIG_THERMAL=y
+CONFIG_THERMAL_OF=y
 CONFIG_THERMAL_EMULATION=y
 CONFIG_EXYNOS_THERMAL=y
+CONFIG_RCAR_GEN3_THERMAL=y
 CONFIG_WATCHDOG=y
 CONFIG_RENESAS_WDT=y
 CONFIG_S3C2410_WATCHDOG=y
-- 
1.9.1

[PATCH 5/5 v2] arm64: defconfig: Enable R-Car Gen3 thermal support

[Khiem Nguyen]

Signed-off-by: Khiem Nguyen 
---

v2:
 * No change
 
 arch/arm64/configs/defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 07cd615..cdb7b40 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -251,8 +251,10 @@ CONFIG_SENSORS_LM90=m
 CONFIG_SENSORS_INA2XX=m
 CONFIG_SENSORS_ARM_SCPI=y
 CONFIG_THERMAL=y
+CONFIG_THERMAL_OF=y
 CONFIG_THERMAL_EMULATION=y
 CONFIG_EXYNOS_THERMAL=y
+CONFIG_RCAR_GEN3_THERMAL=y
 CONFIG_WATCHDOG=y
 CONFIG_RENESAS_WDT=y
 CONFIG_S3C2410_WATCHDOG=y
-- 
1.9.1

[PATCH 4/5 v2] arm64: dts: r8a7796: Add R-Car Gen3 thermal support

[Khiem Nguyen]

Signed-off-by: Khiem Nguyen 
---

v2:
 * Add newly.
 
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 83 
 1 file changed, 83 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 3aae29f..c7491b0 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -293,5 +293,88 @@
cap-mmc-highspeed;
status = "disabled";
};
+
+   tsc1: thermal@e6198000 {
+   compatible = "renesas,r8a7796-thermal";
+   reg = <0 0xe6198000 0 0x5c>;
+   interrupts = ,
+;
+   clocks = < CPG_MOD 522>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   #thermal-sensor-cells = <0>;
+   status = "okay";
+   };
+
+   tsc2: thermal@e61a {
+   compatible = "renesas,r8a7796-thermal";
+   reg = <0 0xe61a 0 0x5c>;
+   interrupts = ,
+;
+   clocks = < CPG_MOD 522>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   #thermal-sensor-cells = <0>;
+   status = "okay";
+   };
+
+   tsc3: thermal@e61a8000 {
+   compatible = "renesas,r8a7796-thermal";
+   reg = <0 0xe61a8000 0 0x5c>;
+   interrupts = ,
+;
+   clocks = < CPG_MOD 522>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   #thermal-sensor-cells = <0>;
+   status = "okay";
+   };
+
+   thermal-zones {
+   sensor_thermal1: sensor-thermal1 {
+   polling-delay-passive = <250>;
+   polling-delay = <1000>;
+
+   /* sensor ID */
+   thermal-sensors = <>;
+
+   trips {
+   sensor1_crit: sensor1-crit {
+   temperature = <9>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+   };
+
+   sensor_thermal2: sensor-thermal2 {
+   polling-delay-passive = <250>;
+   polling-delay = <1000>;
+
+   /* sensor ID */
+   thermal-sensors = <>;
+
+   trips {
+   sensor2_crit: sensor2-crit {
+   temperature = <9>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+   };
+
+   sensor_thermal3: sensor-thermal3 {
+   polling-delay-passive = <250>;
+   polling-delay = <1000>;
+
+   /* sensor ID */
+   thermal-sensors = <>;
+
+   trips {
+   sensor3_crit: sensor3-crit {
+   temperature = <9>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+   };
+   };
};
 };
-- 
1.9.1

[PATCH 4/5 v2] arm64: dts: r8a7796: Add R-Car Gen3 thermal support

[Khiem Nguyen]

Signed-off-by: Khiem Nguyen 
---

v2:
 * Add newly.
 
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 83 
 1 file changed, 83 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 3aae29f..c7491b0 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -293,5 +293,88 @@
cap-mmc-highspeed;
status = "disabled";
};
+
+   tsc1: thermal@e6198000 {
+   compatible = "renesas,r8a7796-thermal";
+   reg = <0 0xe6198000 0 0x5c>;
+   interrupts = ,
+;
+   clocks = < CPG_MOD 522>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   #thermal-sensor-cells = <0>;
+   status = "okay";
+   };
+
+   tsc2: thermal@e61a {
+   compatible = "renesas,r8a7796-thermal";
+   reg = <0 0xe61a 0 0x5c>;
+   interrupts = ,
+;
+   clocks = < CPG_MOD 522>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   #thermal-sensor-cells = <0>;
+   status = "okay";
+   };
+
+   tsc3: thermal@e61a8000 {
+   compatible = "renesas,r8a7796-thermal";
+   reg = <0 0xe61a8000 0 0x5c>;
+   interrupts = ,
+;
+   clocks = < CPG_MOD 522>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   #thermal-sensor-cells = <0>;
+   status = "okay";
+   };
+
+   thermal-zones {
+   sensor_thermal1: sensor-thermal1 {
+   polling-delay-passive = <250>;
+   polling-delay = <1000>;
+
+   /* sensor ID */
+   thermal-sensors = <>;
+
+   trips {
+   sensor1_crit: sensor1-crit {
+   temperature = <9>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+   };
+
+   sensor_thermal2: sensor-thermal2 {
+   polling-delay-passive = <250>;
+   polling-delay = <1000>;
+
+   /* sensor ID */
+   thermal-sensors = <>;
+
+   trips {
+   sensor2_crit: sensor2-crit {
+   temperature = <9>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+   };
+
+   sensor_thermal3: sensor-thermal3 {
+   polling-delay-passive = <250>;
+   polling-delay = <1000>;
+
+   /* sensor ID */
+   thermal-sensors = <>;
+
+   trips {
+   sensor3_crit: sensor3-crit {
+   temperature = <9>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+   };
+   };
};
 };
-- 
1.9.1

[PATCH 3/5 v2] arm64: dts: r8a7795: Add R-Car Gen3 thermal support

[Khiem Nguyen]

Signed-off-by: Hien Dang 
Signed-off-by: Thao Nguyen 
Signed-off-by: Khiem Nguyen 
---

v2:
 * Update the compatible string following new format.
 
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 83 
 1 file changed, 83 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 4718683..b9bc6a3 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -25,6 +25,9 @@
i2c4 = 
i2c5 = 
i2c6 = 
+   tsc0 = 
+   tsc1 = 
+   tsc2 = 
};
 
psci {
@@ -1692,5 +1695,85 @@
};
};
};
+
+   tsc1: thermal@e6198000 {
+   compatible = "renesas,r8a7795-thermal";
+   reg = <0 0xe6198000 0 0x5c>;
+   interrupts = ;
+   clocks = < CPG_MOD 522>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   #thermal-sensor-cells = <0>;
+   status = "okay";
+   };
+
+   tsc2: thermal@e61a {
+   compatible = "renesas,r8a7795-thermal";
+   reg = <0 0xe61a 0 0x5c>;
+   interrupts = ;
+   clocks = < CPG_MOD 522>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   #thermal-sensor-cells = <0>;
+   status = "okay";
+   };
+
+   tsc3: thermal@e61a8000 {
+   compatible = "renesas,r8a7795-thermal";
+   reg = <0 0xe61a8000 0 0x5c>;
+   interrupts = ;
+   clocks = < CPG_MOD 522>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   #thermal-sensor-cells = <0>;
+   status = "okay";
+   };
+
+   thermal-zones {
+   sensor_thermal1: sensor-thermal1 {
+   polling-delay-passive = <250>;
+   polling-delay = <0>;
+
+   /* sensor ID */
+   thermal-sensors = <>;
+
+   trips {
+   sensor1_crit: sensor1-crit {
+   temperature = <9>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+   };
+
+   sensor_thermal2: sensor-thermal2 {
+   polling-delay-passive = <250>;
+   polling-delay = <0>;
+
+   /* sensor ID */
+   thermal-sensors = <>;
+
+   trips {
+   sensor2_crit: sensor2-crit {
+   temperature = <9>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+   };
+
+   sensor_thermal3: sensor-thermal3 {
+   polling-delay-passive = <250>;
+   polling-delay = <0>;
+
+   /* sensor ID */
+   thermal-sensors = <>;
+
+   trips {
+   sensor3_crit: sensor3-crit {
+   temperature = <9>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+   };
+   };
};
 };
-- 
1.9.1

[PATCH 3/5 v2] arm64: dts: r8a7795: Add R-Car Gen3 thermal support

[Khiem Nguyen]

Signed-off-by: Hien Dang 
Signed-off-by: Thao Nguyen 
Signed-off-by: Khiem Nguyen 
---

v2:
 * Update the compatible string following new format.
 
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 83 
 1 file changed, 83 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 4718683..b9bc6a3 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -25,6 +25,9 @@
i2c4 = 
i2c5 = 
i2c6 = 
+   tsc0 = 
+   tsc1 = 
+   tsc2 = 
};
 
psci {
@@ -1692,5 +1695,85 @@
};
};
};
+
+   tsc1: thermal@e6198000 {
+   compatible = "renesas,r8a7795-thermal";
+   reg = <0 0xe6198000 0 0x5c>;
+   interrupts = ;
+   clocks = < CPG_MOD 522>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   #thermal-sensor-cells = <0>;
+   status = "okay";
+   };
+
+   tsc2: thermal@e61a {
+   compatible = "renesas,r8a7795-thermal";
+   reg = <0 0xe61a 0 0x5c>;
+   interrupts = ;
+   clocks = < CPG_MOD 522>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   #thermal-sensor-cells = <0>;
+   status = "okay";
+   };
+
+   tsc3: thermal@e61a8000 {
+   compatible = "renesas,r8a7795-thermal";
+   reg = <0 0xe61a8000 0 0x5c>;
+   interrupts = ;
+   clocks = < CPG_MOD 522>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   #thermal-sensor-cells = <0>;
+   status = "okay";
+   };
+
+   thermal-zones {
+   sensor_thermal1: sensor-thermal1 {
+   polling-delay-passive = <250>;
+   polling-delay = <0>;
+
+   /* sensor ID */
+   thermal-sensors = <>;
+
+   trips {
+   sensor1_crit: sensor1-crit {
+   temperature = <9>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+   };
+
+   sensor_thermal2: sensor-thermal2 {
+   polling-delay-passive = <250>;
+   polling-delay = <0>;
+
+   /* sensor ID */
+   thermal-sensors = <>;
+
+   trips {
+   sensor2_crit: sensor2-crit {
+   temperature = <9>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+   };
+
+   sensor_thermal3: sensor-thermal3 {
+   polling-delay-passive = <250>;
+   polling-delay = <0>;
+
+   /* sensor ID */
+   thermal-sensors = <>;
+
+   trips {
+   sensor3_crit: sensor3-crit {
+   temperature = <9>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+   };
+   };
};
 };
-- 
1.9.1

[PATCH 1/5 v2] thermal: rcar_gen3_thermal: Document the R-Car Gen3

[Khiem Nguyen]

Signed-off-by: Hien Dang 
Signed-off-by: Khiem Nguyen 
---

v2:
 * Update the format of compatible string.
 * Add explanation for keyword tsc.
 
 .../bindings/thermal/rcar-gen3-thermal.txt | 79 ++
 1 file changed, 79 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt

diff --git a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt 
b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
new file mode 100644
index 000..163f794
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
@@ -0,0 +1,79 @@
+* DT bindings for Renesas R-Car Gen3 Thermal Sensor driver
+
+On R-Car Gen3 SoCs, the thermal sensor controllers (TSC) control the thermal 
sensors (THS)
+which are the analog circuits for measuring temperature (Tj) inside the LSI.
+
+Required properties:
+- compatible   : "renesas,-thermal",
+ Examples with soctypes are:
+   - "renesas,r8a7795-thermal" (R-Car H3)
+   - "renesas,r8a7796-thermal" (R-Car M3)
+- reg  : Address range of the thermal registers.
+- clocks   : Must contain a reference to the functional clock.
+- #thermal-sensor-cells : Please see ./thermal.txt
+
+Option properties:
+
+- interrupts   : Use interrupt
+- power-domain : Must contain a reference to the power domain. This 
property is
+ mandatory if the thermal sensor instance is part of a 
controllable power
+ domain.
+
+Example (non interrupt support):
+
+   tsc1: thermal@e6198000 {
+   compatible = "renesas,r8a7795-thermal";
+   reg = <0 0xe6198000 0 0x5c>;
+   clocks = < CPG_MOD 522>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   #thermal-sensor-cells = <0>;
+   status = "okay";
+   };
+
+   thermal-zones {
+   sensor_thermal1: sensor-thermal1 {
+   polling-delay-passive = <250>;
+   polling-delay = <1000>;
+
+   /* sensor ID */
+   thermal-sensors = <>;
+
+   trips {
+   sensor1_crit: sensor1-crit {
+   temperature = <9>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+   };
+   };
+
+Example (interrupt support):
+
+   tsc1: thermal@e6198000 {
+   compatible = "renesas,r8a7795-thermal";
+   reg = <0 0xe6198000 0 0x5c>;
+   interrupts = ;
+   clocks = < CPG_MOD 522>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   #thermal-sensor-cells = <0>;
+   status = "okay";
+   };
+
+   thermal-zones {
+   sensor_thermal1: sensor-thermal1 {
+   polling-delay-passive = <250>;
+   polling-delay = <0>;
+
+   /* sensor ID */
+   thermal-sensors = <>;
+
+   trips {
+   sensor1_crit: sensor1-crit {
+   temperature = <9>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+   };
+   };
-- 
1.9.1

[PATCH 2/5 v2] thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver

[Khiem Nguyen]

Signed-off-by: Hien Dang 
Signed-off-by: Thao Nguyen 
Signed-off-by: Khiem Nguyen 
---

v2:
 * Set static function for _linear_temp_converter().
 * Update the compatible string following new format.
 * Add newline to improve readability.
 * Change thermal_init callbacks to void functions.
 * Improve the processing to register thermal_zones.
 
 drivers/thermal/Kconfig |   9 +
 drivers/thermal/Makefile|   1 +
 drivers/thermal/rcar_gen3_thermal.c | 539 
 3 files changed, 549 insertions(+)
 create mode 100644 drivers/thermal/rcar_gen3_thermal.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 900d505..8500a0a 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -233,6 +233,15 @@ config RCAR_THERMAL
  Enable this to plug the R-Car thermal sensor driver into the Linux
  thermal framework.
 
+config RCAR_GEN3_THERMAL
+   tristate "Renesas R-Car Gen3 thermal driver"
+   depends on ARCH_RENESAS || COMPILE_TEST
+   depends on HAS_IOMEM
+   depends on OF
+   help
+ Enable this to plug the R-Car Gen3 thermal sensor driver into the 
Linux
+ thermal framework.
+
 config KIRKWOOD_THERMAL
tristate "Temperature sensor on Marvell Kirkwood SoCs"
depends on MACH_KIRKWOOD || COMPILE_TEST
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index d091134..b7e7082 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_QCOM_SPMI_TEMP_ALARM)+= 
qcom-spmi-temp-alarm.o
 obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
 obj-$(CONFIG_ROCKCHIP_THERMAL) += rockchip_thermal.o
 obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
+obj-$(CONFIG_RCAR_GEN3_THERMAL)+= rcar_gen3_thermal.o
 obj-$(CONFIG_KIRKWOOD_THERMAL)  += kirkwood_thermal.o
 obj-y  += samsung/
 obj-$(CONFIG_DOVE_THERMAL) += dove_thermal.o
diff --git a/drivers/thermal/rcar_gen3_thermal.c 
b/drivers/thermal/rcar_gen3_thermal.c
new file mode 100644
index 000..cdaaa75
--- /dev/null
+++ b/drivers/thermal/rcar_gen3_thermal.c
@@ -0,0 +1,539 @@
+/*
+ *  R-Car Gen3 THS thermal sensor driver
+ *  Based on drivers/thermal/rcar_thermal.c
+ *
+ * Copyright (C) 2016 Renesas Electronics Corporation.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; version 2 of the License.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Register offset */
+#define REG_GEN3_CTSR  0x20
+#define REG_GEN3_THCTR 0x20
+#define REG_GEN3_IRQSTR0x04
+#define REG_GEN3_IRQMSK0x08
+#define REG_GEN3_IRQCTL0x0C
+#define REG_GEN3_IRQEN 0x10
+#define REG_GEN3_IRQTEMP1  0x14
+#define REG_GEN3_IRQTEMP2  0x18
+#define REG_GEN3_IRQTEMP3  0x1C
+#define REG_GEN3_TEMP  0x28
+#define REG_GEN3_THCODE1   0x50
+#define REG_GEN3_THCODE2   0x54
+#define REG_GEN3_THCODE3   0x58
+
+#define PTAT_BASE  0xE6198000
+#define REG_GEN3_PTAT1 0x5C
+#define REG_GEN3_PTAT2 0x60
+#define REG_GEN3_PTAT3 0x64
+#define PTAT_SIZE  REG_GEN3_PTAT3
+
+/* CTSR bit */
+#define PONM(0x1 << 8)
+#define AOUT(0x1 << 7)
+#define THBGR   (0x1 << 5)
+#define VMEN(0x1 << 4)
+#define VMST(0x1 << 1)
+#define THSST   (0x1 << 0)
+
+/* THCTR bit */
+#define CTCTL  (0x1 << 24)
+#define THCNTSEN(x)(x << 16)
+
+#define BIT_LEN_12 0x1
+
+#define CTEMP_MASK 0xFFF
+
+#define MCELSIUS(temp) ((temp) * 1000)
+#define TEMP_IRQ_SHIFT(tsc_id) (0x1 << tsc_id)
+#define TEMPD_IRQ_SHIFT(tsc_id)(0x1 << (tsc_id + 3))
+#define GEN3_FUSE_MASK 0xFFF
+
+/* Structure for thermal temperature calculation */
+struct equation_coefs {
+   long a1;
+   long b1;
+   long a2;
+   long b2;
+};
+
+struct fuse_factors {
+   int thcode_1;
+   int thcode_2;
+   int thcode_3;
+   int ptat_1;
+   int ptat_2;
+   int ptat_3;
+};
+
+struct rcar_gen3_thermal_priv {
+   void __iomem *base;
+   struct device *dev;
+   struct thermal_zone_device *zone;
+   struct delayed_work work;
+   struct fuse_factors factor;
+   struct equation_coefs coef;
+   spinlock_t lock;
+   int id;
+   int irq;
+   u32 ctemp;
+   const struct rcar_gen3_thermal_data *data;
+};

[PATCH 1/5 v2] thermal: rcar_gen3_thermal: Document the R-Car Gen3

[Khiem Nguyen]

Signed-off-by: Hien Dang 
Signed-off-by: Khiem Nguyen 
---

v2:
 * Update the format of compatible string.
 * Add explanation for keyword tsc.
 
 .../bindings/thermal/rcar-gen3-thermal.txt | 79 ++
 1 file changed, 79 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt

diff --git a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt 
b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
new file mode 100644
index 000..163f794
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
@@ -0,0 +1,79 @@
+* DT bindings for Renesas R-Car Gen3 Thermal Sensor driver
+
+On R-Car Gen3 SoCs, the thermal sensor controllers (TSC) control the thermal 
sensors (THS)
+which are the analog circuits for measuring temperature (Tj) inside the LSI.
+
+Required properties:
+- compatible   : "renesas,-thermal",
+ Examples with soctypes are:
+   - "renesas,r8a7795-thermal" (R-Car H3)
+   - "renesas,r8a7796-thermal" (R-Car M3)
+- reg  : Address range of the thermal registers.
+- clocks   : Must contain a reference to the functional clock.
+- #thermal-sensor-cells : Please see ./thermal.txt
+
+Option properties:
+
+- interrupts   : Use interrupt
+- power-domain : Must contain a reference to the power domain. This 
property is
+ mandatory if the thermal sensor instance is part of a 
controllable power
+ domain.
+
+Example (non interrupt support):
+
+   tsc1: thermal@e6198000 {
+   compatible = "renesas,r8a7795-thermal";
+   reg = <0 0xe6198000 0 0x5c>;
+   clocks = < CPG_MOD 522>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   #thermal-sensor-cells = <0>;
+   status = "okay";
+   };
+
+   thermal-zones {
+   sensor_thermal1: sensor-thermal1 {
+   polling-delay-passive = <250>;
+   polling-delay = <1000>;
+
+   /* sensor ID */
+   thermal-sensors = <>;
+
+   trips {
+   sensor1_crit: sensor1-crit {
+   temperature = <9>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+   };
+   };
+
+Example (interrupt support):
+
+   tsc1: thermal@e6198000 {
+   compatible = "renesas,r8a7795-thermal";
+   reg = <0 0xe6198000 0 0x5c>;
+   interrupts = ;
+   clocks = < CPG_MOD 522>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   #thermal-sensor-cells = <0>;
+   status = "okay";
+   };
+
+   thermal-zones {
+   sensor_thermal1: sensor-thermal1 {
+   polling-delay-passive = <250>;
+   polling-delay = <0>;
+
+   /* sensor ID */
+   thermal-sensors = <>;
+
+   trips {
+   sensor1_crit: sensor1-crit {
+   temperature = <9>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+   };
+   };
-- 
1.9.1

[PATCH 2/5 v2] thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver

[Khiem Nguyen]

Signed-off-by: Hien Dang 
Signed-off-by: Thao Nguyen 
Signed-off-by: Khiem Nguyen 
---

v2:
 * Set static function for _linear_temp_converter().
 * Update the compatible string following new format.
 * Add newline to improve readability.
 * Change thermal_init callbacks to void functions.
 * Improve the processing to register thermal_zones.
 
 drivers/thermal/Kconfig |   9 +
 drivers/thermal/Makefile|   1 +
 drivers/thermal/rcar_gen3_thermal.c | 539 
 3 files changed, 549 insertions(+)
 create mode 100644 drivers/thermal/rcar_gen3_thermal.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 900d505..8500a0a 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -233,6 +233,15 @@ config RCAR_THERMAL
  Enable this to plug the R-Car thermal sensor driver into the Linux
  thermal framework.
 
+config RCAR_GEN3_THERMAL
+   tristate "Renesas R-Car Gen3 thermal driver"
+   depends on ARCH_RENESAS || COMPILE_TEST
+   depends on HAS_IOMEM
+   depends on OF
+   help
+ Enable this to plug the R-Car Gen3 thermal sensor driver into the 
Linux
+ thermal framework.
+
 config KIRKWOOD_THERMAL
tristate "Temperature sensor on Marvell Kirkwood SoCs"
depends on MACH_KIRKWOOD || COMPILE_TEST
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index d091134..b7e7082 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_QCOM_SPMI_TEMP_ALARM)+= 
qcom-spmi-temp-alarm.o
 obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
 obj-$(CONFIG_ROCKCHIP_THERMAL) += rockchip_thermal.o
 obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
+obj-$(CONFIG_RCAR_GEN3_THERMAL)+= rcar_gen3_thermal.o
 obj-$(CONFIG_KIRKWOOD_THERMAL)  += kirkwood_thermal.o
 obj-y  += samsung/
 obj-$(CONFIG_DOVE_THERMAL) += dove_thermal.o
diff --git a/drivers/thermal/rcar_gen3_thermal.c 
b/drivers/thermal/rcar_gen3_thermal.c
new file mode 100644
index 000..cdaaa75
--- /dev/null
+++ b/drivers/thermal/rcar_gen3_thermal.c
@@ -0,0 +1,539 @@
+/*
+ *  R-Car Gen3 THS thermal sensor driver
+ *  Based on drivers/thermal/rcar_thermal.c
+ *
+ * Copyright (C) 2016 Renesas Electronics Corporation.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; version 2 of the License.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Register offset */
+#define REG_GEN3_CTSR  0x20
+#define REG_GEN3_THCTR 0x20
+#define REG_GEN3_IRQSTR0x04
+#define REG_GEN3_IRQMSK0x08
+#define REG_GEN3_IRQCTL0x0C
+#define REG_GEN3_IRQEN 0x10
+#define REG_GEN3_IRQTEMP1  0x14
+#define REG_GEN3_IRQTEMP2  0x18
+#define REG_GEN3_IRQTEMP3  0x1C
+#define REG_GEN3_TEMP  0x28
+#define REG_GEN3_THCODE1   0x50
+#define REG_GEN3_THCODE2   0x54
+#define REG_GEN3_THCODE3   0x58
+
+#define PTAT_BASE  0xE6198000
+#define REG_GEN3_PTAT1 0x5C
+#define REG_GEN3_PTAT2 0x60
+#define REG_GEN3_PTAT3 0x64
+#define PTAT_SIZE  REG_GEN3_PTAT3
+
+/* CTSR bit */
+#define PONM(0x1 << 8)
+#define AOUT(0x1 << 7)
+#define THBGR   (0x1 << 5)
+#define VMEN(0x1 << 4)
+#define VMST(0x1 << 1)
+#define THSST   (0x1 << 0)
+
+/* THCTR bit */
+#define CTCTL  (0x1 << 24)
+#define THCNTSEN(x)(x << 16)
+
+#define BIT_LEN_12 0x1
+
+#define CTEMP_MASK 0xFFF
+
+#define MCELSIUS(temp) ((temp) * 1000)
+#define TEMP_IRQ_SHIFT(tsc_id) (0x1 << tsc_id)
+#define TEMPD_IRQ_SHIFT(tsc_id)(0x1 << (tsc_id + 3))
+#define GEN3_FUSE_MASK 0xFFF
+
+/* Structure for thermal temperature calculation */
+struct equation_coefs {
+   long a1;
+   long b1;
+   long a2;
+   long b2;
+};
+
+struct fuse_factors {
+   int thcode_1;
+   int thcode_2;
+   int thcode_3;
+   int ptat_1;
+   int ptat_2;
+   int ptat_3;
+};
+
+struct rcar_gen3_thermal_priv {
+   void __iomem *base;
+   struct device *dev;
+   struct thermal_zone_device *zone;
+   struct delayed_work work;
+   struct fuse_factors factor;
+   struct equation_coefs coef;
+   spinlock_t lock;
+   int id;
+   int irq;
+   u32 ctemp;
+   const struct rcar_gen3_thermal_data *data;
+};
+
+struct rcar_gen3_thermal_data {
+   void (*thermal_init)(struct 

[PATCH 0/5 v2] thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal support

[Khiem Nguyen]

This patchset adds new thermal sensor driver to support 3 sensors found in 
R-Car Gen3 series.

It has been decided to create new driver, instead of using the existing thermal 
driver
due to many differences in HW setting flows, the method to calculate 
temperatures value
and some newly supported features.

The new driver can support both polling mode and interrupt mode.
It has been tested with R-Car H3. I expect same result on R-Car M3.

This driver is developed based on early work of Hien Dang and Thao Nguyen.
All comments are welcome.

Khiem Nguyen (5):
  thermal: rcar_gen3_thermal: Document the R-Car Gen3 thermal bindings
  thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver support
  arm64: dts: r8a7795: Add R-Car Gen3 thermal support
  arm64: dts: r8a7796: Add R-Car Gen3 thermal support
  arm64: defconfig: Enable R-Car Gen3 thermal support

 .../bindings/thermal/rcar-gen3-thermal.txt |  79 +++
 arch/arm64/boot/dts/renesas/r8a7795.dtsi   |  83 
 arch/arm64/boot/dts/renesas/r8a7796.dtsi   |  83 
 arch/arm64/configs/defconfig   |   2 +
 drivers/thermal/Kconfig|   9 +
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/rcar_gen3_thermal.c| 539 +
 7 files changed, 796 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
 create mode 100644 drivers/thermal/rcar_gen3_thermal.c

-- 
1.9.1

[PATCH 0/5 v2] thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal support

[Khiem Nguyen]

This patchset adds new thermal sensor driver to support 3 sensors found in 
R-Car Gen3 series.

It has been decided to create new driver, instead of using the existing thermal 
driver
due to many differences in HW setting flows, the method to calculate 
temperatures value
and some newly supported features.

The new driver can support both polling mode and interrupt mode.
It has been tested with R-Car H3. I expect same result on R-Car M3.

This driver is developed based on early work of Hien Dang and Thao Nguyen.
All comments are welcome.

Khiem Nguyen (5):
  thermal: rcar_gen3_thermal: Document the R-Car Gen3 thermal bindings
  thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver support
  arm64: dts: r8a7795: Add R-Car Gen3 thermal support
  arm64: dts: r8a7796: Add R-Car Gen3 thermal support
  arm64: defconfig: Enable R-Car Gen3 thermal support

 .../bindings/thermal/rcar-gen3-thermal.txt |  79 +++
 arch/arm64/boot/dts/renesas/r8a7795.dtsi   |  83 
 arch/arm64/boot/dts/renesas/r8a7796.dtsi   |  83 
 arch/arm64/configs/defconfig   |   2 +
 drivers/thermal/Kconfig|   9 +
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/rcar_gen3_thermal.c| 539 +
 7 files changed, 796 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
 create mode 100644 drivers/thermal/rcar_gen3_thermal.c

-- 
1.9.1

Re: [PATCH RFC 1/4] lib/radix: add universal radix_tree_fill_range

[Konstantin Khlebnikov]

On Fri, Sep 2, 2016 at 8:59 PM, Matthew Wilcox  wrote:
> I have a rewrite of the iterators; would you like to take a look?
>
> http://git.infradead.org/users/willy/linux-dax.git/shortlog/refs/heads/idr-2016-09-02
>
> There's five distinct sets of changes in that tree:
>
> 1. Test suite enhancements (first 8 patches)
> 2. Split/Join (patches 9-11)
> 3. Misc cleanups (patches 12-16)
> 4. Iterator rewrite (patches 17-19)

Have you compared performance?
There is simple benchmark in my patchset.

> 5. IDR rewrite (patches 20-25)

Why? I don't see reason for that.

>
> I could rebase the cleanups & iterator rewrite on top of Linus' tree if we 
> don't want to get the split/join functionality into 4.9.
>
> -Original Message-
> From: Konstantin Khlebnikov [mailto:koc...@gmail.com]
> Sent: Thursday, September 1, 2016 2:12 AM
> To: Ross Zwisler 
> Cc: Dan Williams ; Matthew Wilcox 
> ; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH RFC 1/4] lib/radix: add universal radix_tree_fill_range
>
> On Wed, Aug 31, 2016 at 1:53 AM, Ross Zwisler  
> wrote:
>> On Tue, Aug 30, 2016 at 03:21:24PM -0700, Dan Williams wrote:
>>> On Tue, Aug 30, 2016 at 3:03 PM, Ross Zwisler
>>>  wrote:
>>> > On Tue, Aug 30, 2016 at 02:56:17PM -0700, Dan Williams wrote:
>>> >> On Mon, Aug 29, 2016 at 11:52 AM, Matthew Wilcox 
>>> >>  wrote:
>>> >> > It may be protected by the mapping lock in the current code, but I 
>>> >> > would it expect it to become an RCU lookup + lock eventually.  No 
>>> >> > mapping lock, just like the page cache.
>>> >> >
>>> >> > Even if we can work around it, why do we want to?  What's the 
>>> >> > compelling reason to change from the current radix tree representation 
>>> >> > of order-N entries to an arbitrary range?  There are no in-kernel 
>>> >> > users right now; is there a performance reason to change?  We don't 
>>> >> > usually change an API in anticipation of future users appearing, 
>>> >> > particularly when the API makes it harder for the existing users to 
>>> >> > use it.
>>> >>
>>> >> I'd use a fill range api for the radix backing get_dev_pagemap()
>>> >> and potentially another use in device-dax.  It centralizes the
>>> >> common routine of breaking down a range into its constituent
>>> >> power-of-2 ranges.
>>> >
>>> > Does your usage not work with the current sibling & canonical entry model?
>>>
>>> It does, but I find myself writing code to walk a range and determine
>>> the order of each entry as I insert them.  I can see other users
>>> needing the same sort of insert helper and the aspect I like of
>>> Konstantin's proposed change is that the functionality is part of the
>>> core implementation rather than left to be duplicated in each user.
>>
>> Perhaps the answer is to have them both?  Matthew's multi-order radix
>> functionality with siblings for those of us that really *want* a single
>> canonical entry that we can look up, use tags on, etc.   And Konstantin's
>> method where we insert a bunch of duplicate entries that don't have
>> sibling pointers?  Is there a reason why they can't coexist?
>
> I'm not all against "sibling" entries, I just don't want to mess them into 
> iterator and common lookup routines. This is redundant.
>
> Actually it's very easy to integrate similar "sibling" entries into my 
> filling function.
>
> That will be yet another flag which tells to assign given entry only to the 
> first slot and fill following tail with reference to that first slot. Just a 
> pointer with both lower bits set to distinguish it from exceptional and 
> internal pointers.
>
> I think it's better to call them "indirect" entries because this will work 
> for arbitrary ranges too where they are not siblings at all and may be 
> located in several nodes.

Re: [PATCH RFC 1/4] lib/radix: add universal radix_tree_fill_range

[Konstantin Khlebnikov]

On Fri, Sep 2, 2016 at 8:59 PM, Matthew Wilcox  wrote:
> I have a rewrite of the iterators; would you like to take a look?
>
> http://git.infradead.org/users/willy/linux-dax.git/shortlog/refs/heads/idr-2016-09-02
>
> There's five distinct sets of changes in that tree:
>
> 1. Test suite enhancements (first 8 patches)
> 2. Split/Join (patches 9-11)
> 3. Misc cleanups (patches 12-16)
> 4. Iterator rewrite (patches 17-19)

Have you compared performance?
There is simple benchmark in my patchset.

> 5. IDR rewrite (patches 20-25)

Why? I don't see reason for that.

>
> I could rebase the cleanups & iterator rewrite on top of Linus' tree if we 
> don't want to get the split/join functionality into 4.9.
>
> -Original Message-
> From: Konstantin Khlebnikov [mailto:koc...@gmail.com]
> Sent: Thursday, September 1, 2016 2:12 AM
> To: Ross Zwisler 
> Cc: Dan Williams ; Matthew Wilcox 
> ; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH RFC 1/4] lib/radix: add universal radix_tree_fill_range
>
> On Wed, Aug 31, 2016 at 1:53 AM, Ross Zwisler  
> wrote:
>> On Tue, Aug 30, 2016 at 03:21:24PM -0700, Dan Williams wrote:
>>> On Tue, Aug 30, 2016 at 3:03 PM, Ross Zwisler
>>>  wrote:
>>> > On Tue, Aug 30, 2016 at 02:56:17PM -0700, Dan Williams wrote:
>>> >> On Mon, Aug 29, 2016 at 11:52 AM, Matthew Wilcox 
>>> >>  wrote:
>>> >> > It may be protected by the mapping lock in the current code, but I 
>>> >> > would it expect it to become an RCU lookup + lock eventually.  No 
>>> >> > mapping lock, just like the page cache.
>>> >> >
>>> >> > Even if we can work around it, why do we want to?  What's the 
>>> >> > compelling reason to change from the current radix tree representation 
>>> >> > of order-N entries to an arbitrary range?  There are no in-kernel 
>>> >> > users right now; is there a performance reason to change?  We don't 
>>> >> > usually change an API in anticipation of future users appearing, 
>>> >> > particularly when the API makes it harder for the existing users to 
>>> >> > use it.
>>> >>
>>> >> I'd use a fill range api for the radix backing get_dev_pagemap()
>>> >> and potentially another use in device-dax.  It centralizes the
>>> >> common routine of breaking down a range into its constituent
>>> >> power-of-2 ranges.
>>> >
>>> > Does your usage not work with the current sibling & canonical entry model?
>>>
>>> It does, but I find myself writing code to walk a range and determine
>>> the order of each entry as I insert them.  I can see other users
>>> needing the same sort of insert helper and the aspect I like of
>>> Konstantin's proposed change is that the functionality is part of the
>>> core implementation rather than left to be duplicated in each user.
>>
>> Perhaps the answer is to have them both?  Matthew's multi-order radix
>> functionality with siblings for those of us that really *want* a single
>> canonical entry that we can look up, use tags on, etc.   And Konstantin's
>> method where we insert a bunch of duplicate entries that don't have
>> sibling pointers?  Is there a reason why they can't coexist?
>
> I'm not all against "sibling" entries, I just don't want to mess them into 
> iterator and common lookup routines. This is redundant.
>
> Actually it's very easy to integrate similar "sibling" entries into my 
> filling function.
>
> That will be yet another flag which tells to assign given entry only to the 
> first slot and fill following tail with reference to that first slot. Just a 
> pointer with both lower bits set to distinguish it from exceptional and 
> internal pointers.
>
> I think it's better to call them "indirect" entries because this will work 
> for arbitrary ranges too where they are not siblings at all and may be 
> located in several nodes.

Hello Beautiful

[Jones]

How you doing today? I hope you are doing well. My name is Jones, from the US. 
I'm in Syria right now fighting ISIS. I want to get to know you better, if I 
may be so bold. I consider myself an easy-going man, and I am currently looking 
for a relationship in which I feel loved. Please tell me more about yourself, 
if you don't mind.

Hope to hear from you soon.

Regards,
Jones

Hello Beautiful

[Jones]

How you doing today? I hope you are doing well. My name is Jones, from the US. 
I'm in Syria right now fighting ISIS. I want to get to know you better, if I 
may be so bold. I consider myself an easy-going man, and I am currently looking 
for a relationship in which I feel loved. Please tell me more about yourself, 
if you don't mind.

Hope to hear from you soon.

Regards,
Jones

Re: [RFC] fs: add userspace critical mounts event support

[Dmitry Torokhov]

On Fri, Sep 2, 2016 at 9:11 PM, Linus Torvalds
 wrote:
> On Fri, Sep 2, 2016 at 5:20 PM, Luis R. Rodriguez  wrote:
>>
>> Thoughts ?
>
> I really think this is a horrible hack.
>
> It's basically the kernel giving up, and relying on user space to give
> a single flag, and it's broken nasty crap.  Worse, it's broken nasty
> crap with a user interface, so we'll be stuck with it forever. Please
> no.

I agree that interface is bad, but I do believe we need something like this...

>
> What are the drivers that need this, and why can't those drivers just
> be fixed to not do braindead things?

Like what? Some devices do need to have firmware loaded so we know
their capabilities, so we really can't push the firmware loading into
"open". If your touch controller for some reason decided to crap over
it's nvram and comes in bootloader mode it is nice for it to slurp in
config data or firmware so use does not have to trigger update
manually. And while the controller is in bootloader mode we can't
create input device because we do not know what capabilities to
declare.

These devices we want to probe asynchronously and simply tell firmware
loader to wait for firmware to become available. The problem we do not
know when to give up, since we do not know where the firmware might
be. But userspace knows and can tel us.

Thanks.

-- 
Dmitry

Re: [RFC] fs: add userspace critical mounts event support

[Dmitry Torokhov]

On Fri, Sep 2, 2016 at 9:11 PM, Linus Torvalds
 wrote:
> On Fri, Sep 2, 2016 at 5:20 PM, Luis R. Rodriguez  wrote:
>>
>> Thoughts ?
>
> I really think this is a horrible hack.
>
> It's basically the kernel giving up, and relying on user space to give
> a single flag, and it's broken nasty crap.  Worse, it's broken nasty
> crap with a user interface, so we'll be stuck with it forever. Please
> no.

I agree that interface is bad, but I do believe we need something like this...

>
> What are the drivers that need this, and why can't those drivers just
> be fixed to not do braindead things?

Like what? Some devices do need to have firmware loaded so we know
their capabilities, so we really can't push the firmware loading into
"open". If your touch controller for some reason decided to crap over
it's nvram and comes in bootloader mode it is nice for it to slurp in
config data or firmware so use does not have to trigger update
manually. And while the controller is in bootloader mode we can't
create input device because we do not know what capabilities to
declare.

These devices we want to probe asynchronously and simply tell firmware
loader to wait for firmware to become available. The problem we do not
know when to give up, since we do not know where the firmware might
be. But userspace knows and can tel us.

Thanks.

-- 
Dmitry

Re: [RFC] fs: add userspace critical mounts event support

[Linus Torvalds]

On Fri, Sep 2, 2016 at 5:20 PM, Luis R. Rodriguez  wrote:
>
> Thoughts ?

I really think this is a horrible hack.

It's basically the kernel giving up, and relying on user space to give
a single flag, and it's broken nasty crap.  Worse, it's broken nasty
crap with a user interface, so we'll be stuck with it forever. Please
no.

What are the drivers that need this, and why can't those drivers just
be fixed to not do braindead things?

Linus

Re: [PATCH 4/4] kvm: x86: export TSC offset to user-space

[Masami Hiramatsu]

On Fri, 2 Sep 2016 21:23:11 -0300
Marcelo Tosatti  wrote:

> On Fri, Sep 02, 2016 at 10:15:41AM -0400, Steven Rostedt wrote:
> > On Fri, 2 Sep 2016 09:43:01 -0400
> > Stefan Hajnoczi  wrote:
> > 
> > > Can TSC offset changes occur at runtime?
> 
> Yes, but Linux guests don't write to the TSC offset
> after booting and unless user does manual TSC writes.
> 
> > > One example is vcpu hotplug where the tracing tool would need to fetch
> > > the new vcpu's TSC offset after tracing has already started.
> > > 
> > > Another example is if QEMU or the guest change the TSC offset while
> > > running.  If the tracing tool doesn't notice this then trace events will 
> > > have
> > > incorrect timestamps.
> 
> So what happens is this:
> 
> HostTSC (a variable). 
> GuestTSC (variable) = GuestTSCOffset (fixed) + HostTSC (variable)

The same idea has been done by Yoshihiro
http://events.linuxfoundation.org/sites/events/files/cojp13_yunomae.pdf

 
> Then the algorithm processes the trace as follows:
> line = for each line(guest_trace)
> line = line - GuestTSCOffset (only the timestamp of course)
> 
> So from the moment the guest writes a new TSC offset, the host 
> should use the new TSC offset to subtract from the trace entries.
> The trace entries are in fact:
> 
> HostTSC + GuestTSCOffset
> 
> So the guest trace should contain entries for "USE NEW TSC OFFSET,
> VALUE: xxx", which can be done (hum not sure if guest entries
> or host entries).
> 
> However, correct me if i am wrong, the usecase seems to be:
> 
> 1) Boot guest.
> 2) run trace-cmd
> 3) run workload
> 4) read traces on host.

IIRC, previous (current?) method is to run trace-cmd at first (before
boot the guest) so that it can get tsc-offset event and
can wait on a special unix domain socket.

For above usecase, we have to have an interface to get the current
tsc offset like Luis suggested.

> 
> Another option is to have notifications as follows: record on a buffer 
> the following:
> 
> [ EVENT: TSC offset write, VAL: [ host tsc value, guest tsc offset ] ]
> [ EVENT: TSC offset write, VAL: [ host tsc value, guest tsc offset ] ]
> 
> Then when merging the trace entries, you do:
> 
> line = for each line(host trace)
> write_to_merged_trace(line)
> if (contains_tsc_offset_event(line)) {
> GuestTSCOffset = line.GuestTSCOffset
> if (!guest_tsc_offset_initialized) {
> process_all_guest_lines(
> line = line - GuestTSCOffset (only the timestamp of course)
> }
> }
> 
> Aha, fail: the traces on the host are not sufficient to know when 
> to use which offset to subtract on the guest trace.
> 
> So the only possibility is to have the guest inform the occurrence
> of the events: however the guest does not have access to the TSC offset.
> 
> So the host needs to inform the new tsc offset value and the guest needs
> to inform when the event occurred on its side. So the algorithm can use
> information on both traces to know which value to subtract on the
> algorithm above.
> 
> Is this necessary? Or people do:
> 1) Boot guest.
> 2) run trace-cmd
> 3) run workload
> 4) read traces on host.
> 
> > I believe there are tracepoints for these events. They would obviously
> > need to be enabled for the tracer to catch them.

Yes, Yoshihiro introduced a tracepoint for that.
http://lkml.iu.edu/hypermail/linux/kernel/1306.1/01741.html

So, we have to trace this event in host side.

> > 
> > I would also recommend that they go into their own instance to make
> > sure other events do not overwrite them.
> > 
> > -- Steve

Thanks,

-- 
Masami Hiramatsu 

Re: [RFC] fs: add userspace critical mounts event support

[Linus Torvalds]

On Fri, Sep 2, 2016 at 5:20 PM, Luis R. Rodriguez  wrote:
>
> Thoughts ?

I really think this is a horrible hack.

It's basically the kernel giving up, and relying on user space to give
a single flag, and it's broken nasty crap.  Worse, it's broken nasty
crap with a user interface, so we'll be stuck with it forever. Please
no.

What are the drivers that need this, and why can't those drivers just
be fixed to not do braindead things?

Linus

Re: [PATCH 4/4] kvm: x86: export TSC offset to user-space

[Masami Hiramatsu]

On Fri, 2 Sep 2016 21:23:11 -0300
Marcelo Tosatti  wrote:

> On Fri, Sep 02, 2016 at 10:15:41AM -0400, Steven Rostedt wrote:
> > On Fri, 2 Sep 2016 09:43:01 -0400
> > Stefan Hajnoczi  wrote:
> > 
> > > Can TSC offset changes occur at runtime?
> 
> Yes, but Linux guests don't write to the TSC offset
> after booting and unless user does manual TSC writes.
> 
> > > One example is vcpu hotplug where the tracing tool would need to fetch
> > > the new vcpu's TSC offset after tracing has already started.
> > > 
> > > Another example is if QEMU or the guest change the TSC offset while
> > > running.  If the tracing tool doesn't notice this then trace events will 
> > > have
> > > incorrect timestamps.
> 
> So what happens is this:
> 
> HostTSC (a variable). 
> GuestTSC (variable) = GuestTSCOffset (fixed) + HostTSC (variable)

The same idea has been done by Yoshihiro
http://events.linuxfoundation.org/sites/events/files/cojp13_yunomae.pdf

 
> Then the algorithm processes the trace as follows:
> line = for each line(guest_trace)
> line = line - GuestTSCOffset (only the timestamp of course)
> 
> So from the moment the guest writes a new TSC offset, the host 
> should use the new TSC offset to subtract from the trace entries.
> The trace entries are in fact:
> 
> HostTSC + GuestTSCOffset
> 
> So the guest trace should contain entries for "USE NEW TSC OFFSET,
> VALUE: xxx", which can be done (hum not sure if guest entries
> or host entries).
> 
> However, correct me if i am wrong, the usecase seems to be:
> 
> 1) Boot guest.
> 2) run trace-cmd
> 3) run workload
> 4) read traces on host.

IIRC, previous (current?) method is to run trace-cmd at first (before
boot the guest) so that it can get tsc-offset event and
can wait on a special unix domain socket.

For above usecase, we have to have an interface to get the current
tsc offset like Luis suggested.

> 
> Another option is to have notifications as follows: record on a buffer 
> the following:
> 
> [ EVENT: TSC offset write, VAL: [ host tsc value, guest tsc offset ] ]
> [ EVENT: TSC offset write, VAL: [ host tsc value, guest tsc offset ] ]
> 
> Then when merging the trace entries, you do:
> 
> line = for each line(host trace)
> write_to_merged_trace(line)
> if (contains_tsc_offset_event(line)) {
> GuestTSCOffset = line.GuestTSCOffset
> if (!guest_tsc_offset_initialized) {
> process_all_guest_lines(
> line = line - GuestTSCOffset (only the timestamp of course)
> }
> }
> 
> Aha, fail: the traces on the host are not sufficient to know when 
> to use which offset to subtract on the guest trace.
> 
> So the only possibility is to have the guest inform the occurrence
> of the events: however the guest does not have access to the TSC offset.
> 
> So the host needs to inform the new tsc offset value and the guest needs
> to inform when the event occurred on its side. So the algorithm can use
> information on both traces to know which value to subtract on the
> algorithm above.
> 
> Is this necessary? Or people do:
> 1) Boot guest.
> 2) run trace-cmd
> 3) run workload
> 4) read traces on host.
> 
> > I believe there are tracepoints for these events. They would obviously
> > need to be enabled for the tracer to catch them.

Yes, Yoshihiro introduced a tracepoint for that.
http://lkml.iu.edu/hypermail/linux/kernel/1306.1/01741.html

So, we have to trace this event in host side.

> > 
> > I would also recommend that they go into their own instance to make
> > sure other events do not overwrite them.
> > 
> > -- Steve

Thanks,

-- 
Masami Hiramatsu 

Re: [PATCH 3/4] kvm: add stub for arch specific debugfs support

[Masami Hiramatsu]

On Wed, 31 Aug 2016 13:05:44 -0400
Luiz Capitulino  wrote:

> kvm_arch_create_vm_debugfs() allows arch specific code to
> create entries in the VM's directory in debugfs. x86 will
> implement support for this in the next commit.

I think we can use __weak symbol for other arch.

Thank  you,

> 
> Signed-off-by: Luiz Capitulino 
> ---
>  arch/arm/kvm/arm.c | 5 +
>  arch/mips/kvm/mips.c   | 5 +
>  arch/powerpc/kvm/powerpc.c | 5 +
>  arch/s390/kvm/kvm-s390.c   | 5 +
>  arch/x86/kvm/x86.c | 5 +
>  include/linux/kvm_host.h   | 2 ++
>  virt/kvm/kvm_main.c| 4 
>  7 files changed, 31 insertions(+)
> 
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 75f130e..491211f 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -144,6 +144,11 @@ out_fail_alloc:
>   return ret;
>  }
>  
> +int kvm_arch_create_vm_debugfs(struct kvm *kvm)
> +{
> + return 0;
> +}
> +
>  int kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct vm_fault *vmf)
>  {
>   return VM_FAULT_SIGBUS;
> diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
> index a6ea084..a854b8b 100644
> --- a/arch/mips/kvm/mips.c
> +++ b/arch/mips/kvm/mips.c
> @@ -140,6 +140,11 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
>   return 0;
>  }
>  
> +int kvm_arch_create_vm_debugfs(struct kvm *kvm)
> +{
> + return 0;
> +}
> +
>  void kvm_mips_free_vcpus(struct kvm *kvm)
>  {
>   unsigned int i;
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 6ce40dd..d8867e5 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -436,6 +436,11 @@ err_out:
>   return -EINVAL;
>  }
>  
> +int kvm_arch_create_vm_debugfs(struct kvm *kvm)
> +{
> + return 0;
> +}
> +
>  void kvm_arch_destroy_vm(struct kvm *kvm)
>  {
>   unsigned int i;
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index f142215..406324c 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -1490,6 +1490,11 @@ out_err:
>   return rc;
>  }
>  
> +int kvm_arch_create_vm_debugfs(struct kvm *kvm)
> +{
> + return 0;
> +}
> +
>  void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu)
>  {
>   VCPU_EVENT(vcpu, 3, "%s", "free cpu");
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 19f9f9e..18dfbac 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -7779,6 +7779,11 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long 
> type)
>   return 0;
>  }
>  
> +int kvm_arch_create_vm_debugfs(struct kvm *kvm)
> +{
> + return 0;
> +}
> +
>  static void kvm_unload_vcpu_mmu(struct kvm_vcpu *vcpu)
>  {
>   int r;
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 9c28b4d..d3810bf 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -835,6 +835,8 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type);
>  void kvm_arch_destroy_vm(struct kvm *kvm);
>  void kvm_arch_sync_events(struct kvm *kvm);
>  
> +int kvm_arch_create_vm_debugfs(struct kvm *kvm);
> +
>  int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu);
>  void kvm_vcpu_kick(struct kvm_vcpu *vcpu);
>  
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 9293285..2db53a8 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -601,6 +601,10 @@ static int kvm_create_vm_debugfs(struct kvm *kvm, int fd)
>stat_fops_per_vm[p->kind]))
>   goto out_err;
>   }
> +
> + if (kvm_arch_create_vm_debugfs(kvm) < 0)
> + goto out_err;
> +
>   return 0;
>  
>  out_err:
> -- 
> 2.5.5
> 


-- 
Masami Hiramatsu 

Re: [PATCH 3/4] kvm: add stub for arch specific debugfs support

[Masami Hiramatsu]

On Wed, 31 Aug 2016 13:05:44 -0400
Luiz Capitulino  wrote:

> kvm_arch_create_vm_debugfs() allows arch specific code to
> create entries in the VM's directory in debugfs. x86 will
> implement support for this in the next commit.

I think we can use __weak symbol for other arch.

Thank  you,

> 
> Signed-off-by: Luiz Capitulino 
> ---
>  arch/arm/kvm/arm.c | 5 +
>  arch/mips/kvm/mips.c   | 5 +
>  arch/powerpc/kvm/powerpc.c | 5 +
>  arch/s390/kvm/kvm-s390.c   | 5 +
>  arch/x86/kvm/x86.c | 5 +
>  include/linux/kvm_host.h   | 2 ++
>  virt/kvm/kvm_main.c| 4 
>  7 files changed, 31 insertions(+)
> 
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 75f130e..491211f 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -144,6 +144,11 @@ out_fail_alloc:
>   return ret;
>  }
>  
> +int kvm_arch_create_vm_debugfs(struct kvm *kvm)
> +{
> + return 0;
> +}
> +
>  int kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct vm_fault *vmf)
>  {
>   return VM_FAULT_SIGBUS;
> diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
> index a6ea084..a854b8b 100644
> --- a/arch/mips/kvm/mips.c
> +++ b/arch/mips/kvm/mips.c
> @@ -140,6 +140,11 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
>   return 0;
>  }
>  
> +int kvm_arch_create_vm_debugfs(struct kvm *kvm)
> +{
> + return 0;
> +}
> +
>  void kvm_mips_free_vcpus(struct kvm *kvm)
>  {
>   unsigned int i;
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 6ce40dd..d8867e5 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -436,6 +436,11 @@ err_out:
>   return -EINVAL;
>  }
>  
> +int kvm_arch_create_vm_debugfs(struct kvm *kvm)
> +{
> + return 0;
> +}
> +
>  void kvm_arch_destroy_vm(struct kvm *kvm)
>  {
>   unsigned int i;
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index f142215..406324c 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -1490,6 +1490,11 @@ out_err:
>   return rc;
>  }
>  
> +int kvm_arch_create_vm_debugfs(struct kvm *kvm)
> +{
> + return 0;
> +}
> +
>  void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu)
>  {
>   VCPU_EVENT(vcpu, 3, "%s", "free cpu");
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 19f9f9e..18dfbac 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -7779,6 +7779,11 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long 
> type)
>   return 0;
>  }
>  
> +int kvm_arch_create_vm_debugfs(struct kvm *kvm)
> +{
> + return 0;
> +}
> +
>  static void kvm_unload_vcpu_mmu(struct kvm_vcpu *vcpu)
>  {
>   int r;
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 9c28b4d..d3810bf 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -835,6 +835,8 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type);
>  void kvm_arch_destroy_vm(struct kvm *kvm);
>  void kvm_arch_sync_events(struct kvm *kvm);
>  
> +int kvm_arch_create_vm_debugfs(struct kvm *kvm);
> +
>  int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu);
>  void kvm_vcpu_kick(struct kvm_vcpu *vcpu);
>  
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 9293285..2db53a8 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -601,6 +601,10 @@ static int kvm_create_vm_debugfs(struct kvm *kvm, int fd)
>stat_fops_per_vm[p->kind]))
>   goto out_err;
>   }
> +
> + if (kvm_arch_create_vm_debugfs(kvm) < 0)
> + goto out_err;
> +
>   return 0;
>  
>  out_err:
> -- 
> 2.5.5
> 


-- 
Masami Hiramatsu 

[PATCH] crypto: caam: add missing header dependencies

[Baoyou Xie]

We get 1 warning when building kernel with W=1:
drivers/crypto/caam/ctrl.c:398:5: warning: no previous prototype for 
'caam_get_era' [-Wmissing-prototypes]

In fact, this function is declared in drivers/crypto/caam/ctrl.h
and be exported, thus can be refrenced by modules, so this patch 
adds missing header dependencies.

Signed-off-by: Baoyou Xie 
---
 drivers/crypto/caam/ctrl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index 0ec112e..46e72ed 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -14,6 +14,7 @@
 #include "jr.h"
 #include "desc_constr.h"
 #include "error.h"
+#include "ctrl.h"
 
 bool caam_little_end;
 EXPORT_SYMBOL(caam_little_end);
-- 
2.7.4

[PATCH] crypto: caam: add missing header dependencies

[Baoyou Xie]

We get 1 warning when building kernel with W=1:
drivers/crypto/caam/ctrl.c:398:5: warning: no previous prototype for 
'caam_get_era' [-Wmissing-prototypes]

In fact, this function is declared in drivers/crypto/caam/ctrl.h
and be exported, thus can be refrenced by modules, so this patch 
adds missing header dependencies.

Signed-off-by: Baoyou Xie 
---
 drivers/crypto/caam/ctrl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index 0ec112e..46e72ed 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -14,6 +14,7 @@
 #include "jr.h"
 #include "desc_constr.h"
 #include "error.h"
+#include "ctrl.h"
 
 bool caam_little_end;
 EXPORT_SYMBOL(caam_little_end);
-- 
2.7.4

[PATCH] clocksource: pxa_timer: add missing header dependencies

[Baoyou Xie]

We get 1 warning when building kernel with W=1:
drivers/clocksource/pxa_timer.c:221:13: warning: no previous prototype for 
'pxa_timer_nodt_init' [-Wmissing-prototypes]

In fact, this function is declared in include/clocksource/pxa.h,
although it's not referenced anywhere now, it can be referenced 
by someone out of nowhere in future, so this patch adds missing
header dependencies.

Signed-off-by: Baoyou Xie 
---
 drivers/clocksource/pxa_timer.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clocksource/pxa_timer.c b/drivers/clocksource/pxa_timer.c
index 937e10b..3e1cb51 100644
--- a/drivers/clocksource/pxa_timer.c
+++ b/drivers/clocksource/pxa_timer.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 
+#include 
+
 #include 
 
 #define OSMR0  0x00/* OS Timer 0 Match Register */
-- 
2.7.4

[PATCH] clocksource: pxa_timer: add missing header dependencies

[Baoyou Xie]

We get 1 warning when building kernel with W=1:
drivers/clocksource/pxa_timer.c:221:13: warning: no previous prototype for 
'pxa_timer_nodt_init' [-Wmissing-prototypes]

In fact, this function is declared in include/clocksource/pxa.h,
although it's not referenced anywhere now, it can be referenced 
by someone out of nowhere in future, so this patch adds missing
header dependencies.

Signed-off-by: Baoyou Xie 
---
 drivers/clocksource/pxa_timer.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clocksource/pxa_timer.c b/drivers/clocksource/pxa_timer.c
index 937e10b..3e1cb51 100644
--- a/drivers/clocksource/pxa_timer.c
+++ b/drivers/clocksource/pxa_timer.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 
+#include 
+
 #include 
 
 #define OSMR0  0x00/* OS Timer 0 Match Register */
-- 
2.7.4

[PATCH] iio: adc: ina2xx: remove unused debug field from chip global data

[Alison Schofield]

commit 1961bce76452 "iio: ina2xx: Remove trace_printk debug
statements" removed the code that used the chip->prev_ns field.
This patch cleans it up further by removing the unused field
and assignments.

Signed-off-by: Alison Schofield 
Cc: Daniel Baluta 
---
 drivers/iio/adc/ina2xx-adc.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/iio/adc/ina2xx-adc.c b/drivers/iio/adc/ina2xx-adc.c
index 955f3fd..59b7d76 100644
--- a/drivers/iio/adc/ina2xx-adc.c
+++ b/drivers/iio/adc/ina2xx-adc.c
@@ -114,7 +114,6 @@ struct ina2xx_chip_info {
struct mutex state_lock;
unsigned int shunt_resistor;
int avg;
-   s64 prev_ns; /* track buffer capture time, check for underruns */
int int_time_vbus; /* Bus voltage integration time uS */
int int_time_vshunt; /* Shunt voltage integration time uS */
bool allow_async_readout;
@@ -509,8 +508,6 @@ static int ina2xx_work_buffer(struct iio_dev *indio_dev)
iio_push_to_buffers_with_timestamp(indio_dev,
   (unsigned int *)data, time_a);
 
-   chip->prev_ns = time_a;
-
return (unsigned long)(time_b - time_a) / 1000;
 };
 
@@ -554,8 +551,6 @@ static int ina2xx_buffer_enable(struct iio_dev *indio_dev)
dev_dbg(_dev->dev, "Async readout mode: %d\n",
chip->allow_async_readout);
 
-   chip->prev_ns = iio_get_time_ns(indio_dev);
-
chip->task = kthread_run(ina2xx_capture_thread, (void *)indio_dev,
 "%s:%d-%uus", indio_dev->name, indio_dev->id,
 sampling_us);
-- 
2.1.4

[PATCH] iio: adc: ina2xx: remove unused debug field from chip global data

[Alison Schofield]

commit 1961bce76452 "iio: ina2xx: Remove trace_printk debug
statements" removed the code that used the chip->prev_ns field.
This patch cleans it up further by removing the unused field
and assignments.

Signed-off-by: Alison Schofield 
Cc: Daniel Baluta 
---
 drivers/iio/adc/ina2xx-adc.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/iio/adc/ina2xx-adc.c b/drivers/iio/adc/ina2xx-adc.c
index 955f3fd..59b7d76 100644
--- a/drivers/iio/adc/ina2xx-adc.c
+++ b/drivers/iio/adc/ina2xx-adc.c
@@ -114,7 +114,6 @@ struct ina2xx_chip_info {
struct mutex state_lock;
unsigned int shunt_resistor;
int avg;
-   s64 prev_ns; /* track buffer capture time, check for underruns */
int int_time_vbus; /* Bus voltage integration time uS */
int int_time_vshunt; /* Shunt voltage integration time uS */
bool allow_async_readout;
@@ -509,8 +508,6 @@ static int ina2xx_work_buffer(struct iio_dev *indio_dev)
iio_push_to_buffers_with_timestamp(indio_dev,
   (unsigned int *)data, time_a);
 
-   chip->prev_ns = time_a;
-
return (unsigned long)(time_b - time_a) / 1000;
 };
 
@@ -554,8 +551,6 @@ static int ina2xx_buffer_enable(struct iio_dev *indio_dev)
dev_dbg(_dev->dev, "Async readout mode: %d\n",
chip->allow_async_readout);
 
-   chip->prev_ns = iio_get_time_ns(indio_dev);
-
chip->task = kthread_run(ina2xx_capture_thread, (void *)indio_dev,
 "%s:%d-%uus", indio_dev->name, indio_dev->id,
 sampling_us);
-- 
2.1.4

Re: [PATCH v2 00/15] PCI: rockchip: Cleanups against v10

[Shawn Lin]

Hi Bjorn,

On 2016/9/2 23:53, Bjorn Helgaas wrote:

These are cleanups against 2098142ae87d, the current pci/host-rockchip
head in my tree.



Thanks so much for you to help clean up this driver, since I think
it should be my duty to take over this.  Hope not too late for me to 
help your cleanup. I think the v2 cannot compile gracefully without the

appended patch. After fixing these compile errors, I backported this
driver entirely to my downstream 4.4 tree and it worked fine without
regression.

Once again, thanks for doing this. :)


Changes from v1:

  - Rework HIWORD_UPDATE
  - Remove duplicate CSR definitions
  - Move CSR block offset from read/write caller to CSR definition
  - Organize CSRs into logical blocks
  - Fix some inconsistent CSR names
  - Add names for registers at the base of CSR blocks

I was disappointed to find how disorganized the v10 CSR definitions were.
It was quite a hodgepodge.  I should have noticed that earlier, but as
penance, I tried to clean it up myself.

These are in git as pci/host-rockchip-wip.  Again, I intend to squash these
all into the single commit that adds the driver when I finally merge it.

---

Bjorn Helgaas (15):
  Remove unused symbols, unnecessary parens, other minor comments from
  Rename pcie_read() and pcie_write() to rockchip_pcie_read() and
  Always use "rockchip" as the pointer to per-device struct.
  Rename struct rockchip_pcie_port to struct rockchip_pcie.
  Use a local "dev" to avoid repetition of "rockchip->dev".
  Add comment about why 32-bit read/modify/write isn't safe.
  Simplify the confusing HIWORD_UPDATE scheme.
  Remove duplicate CSR definition.
  Move CSR bases into definition.
  Group related CSR definitions together.
  Rename PCIE_CORE_RC_CONF_SCC_SHIFT to match similar definitions.
  Rename ROCKCHIP_PCIE_RPIFR1_INTR_MASK and ROCKCHIP_PCIE_RPIFR1_INTR_SHIFT
  The register at PCIE_CLIENT_BASE presumably has a name of its own.  Add a
  Simplify testing of link status and speed testing.
  Move msleeps to address Guenter's comments.


 drivers/pci/host/pcie-rockchip.c |  842 ++
 1 file changed, 391 insertions(+), 451 deletions(-)






--
Best Regards
Shawn Lin
diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index 754d24b..2bc1c35 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -931,7 +931,7 @@ static int rockchip_pcie_prog_ob_atu(struct rockchip_pcie 
*rockchip,
u32 ob_addr_0;
u32 ob_addr_1;
u32 ob_desc_0;
-   void __iomem *aw_offset;
+   u32 aw_offset;
 
if (region_no >= MAX_AXI_WRAPPER_REGION_NUM)
return -EINVAL;
@@ -955,13 +955,13 @@ static int rockchip_pcie_prog_ob_atu(struct rockchip_pcie 
*rockchip,
ob_addr_1 = upper_addr;
ob_desc_0 = (1 << 23 | type);
 
-   rockchip_pcie_writel(rockchip, ob_addr_0,
+   rockchip_pcie_write(rockchip, ob_addr_0,
 PCIE_CORE_OB_REGION_ADDR0 + aw_offset);
-   rockchip_pcie_writel(rockchip, ob_addr_1,
+   rockchip_pcie_write(rockchip, ob_addr_1,
 PCIE_CORE_OB_REGION_ADDR1 + aw_offset);
-   rockchip_pcie_writel(rockchip, ob_desc_0,
+   rockchip_pcie_write(rockchip, ob_desc_0,
 PCIE_CORE_OB_REGION_DESC0 + aw_offset);
-   rockchip_pcie_writel(rockchip, 0,
+   rockchip_pcie_write(rockchip, 0,
 PCIE_CORE_OB_REGION_DESC1 + aw_offset);
 
return 0;
@@ -973,7 +973,7 @@ static int rockchip_pcie_prog_ib_atu(struct rockchip_pcie 
*rockchip,
 {
u32 ib_addr_0;
u32 ib_addr_1;
-   void __iomem *aw_offset;
+   u32 aw_offset;
 
if (region_no > MAX_AXI_IB_ROOTPORT_REGION_NUM)
return -EINVAL;
@@ -988,8 +988,8 @@ static int rockchip_pcie_prog_ib_atu(struct rockchip_pcie 
*rockchip,
ib_addr_0 |= (lower_addr << 8) & PCIE_CORE_IB_REGION_ADDR0_LO_ADDR;
ib_addr_1 = upper_addr;
 
-   rockchip_pcie_writel(rockchip, ib_addr_0, PCIE_RP_IB_ADDR0 + aw_offset);
-   rockchip_pcie_writel(rockchip, ib_addr_1, PCIE_RP_IB_ADDR1 + aw_offset);
+   rockchip_pcie_write(rockchip, ib_addr_0, PCIE_RP_IB_ADDR0 + aw_offset);
+   rockchip_pcie_write(rockchip, ib_addr_1, PCIE_RP_IB_ADDR1 + aw_offset);
 
return 0;
 }

Re: [PATCH v2 00/15] PCI: rockchip: Cleanups against v10

[Shawn Lin]

Hi Bjorn,

On 2016/9/2 23:53, Bjorn Helgaas wrote:

These are cleanups against 2098142ae87d, the current pci/host-rockchip
head in my tree.



Thanks so much for you to help clean up this driver, since I think
it should be my duty to take over this.  Hope not too late for me to 
help your cleanup. I think the v2 cannot compile gracefully without the

appended patch. After fixing these compile errors, I backported this
driver entirely to my downstream 4.4 tree and it worked fine without
regression.

Once again, thanks for doing this. :)


Changes from v1:

  - Rework HIWORD_UPDATE
  - Remove duplicate CSR definitions
  - Move CSR block offset from read/write caller to CSR definition
  - Organize CSRs into logical blocks
  - Fix some inconsistent CSR names
  - Add names for registers at the base of CSR blocks

I was disappointed to find how disorganized the v10 CSR definitions were.
It was quite a hodgepodge.  I should have noticed that earlier, but as
penance, I tried to clean it up myself.

These are in git as pci/host-rockchip-wip.  Again, I intend to squash these
all into the single commit that adds the driver when I finally merge it.

---

Bjorn Helgaas (15):
  Remove unused symbols, unnecessary parens, other minor comments from
  Rename pcie_read() and pcie_write() to rockchip_pcie_read() and
  Always use "rockchip" as the pointer to per-device struct.
  Rename struct rockchip_pcie_port to struct rockchip_pcie.
  Use a local "dev" to avoid repetition of "rockchip->dev".
  Add comment about why 32-bit read/modify/write isn't safe.
  Simplify the confusing HIWORD_UPDATE scheme.
  Remove duplicate CSR definition.
  Move CSR bases into definition.
  Group related CSR definitions together.
  Rename PCIE_CORE_RC_CONF_SCC_SHIFT to match similar definitions.
  Rename ROCKCHIP_PCIE_RPIFR1_INTR_MASK and ROCKCHIP_PCIE_RPIFR1_INTR_SHIFT
  The register at PCIE_CLIENT_BASE presumably has a name of its own.  Add a
  Simplify testing of link status and speed testing.
  Move msleeps to address Guenter's comments.


 drivers/pci/host/pcie-rockchip.c |  842 ++
 1 file changed, 391 insertions(+), 451 deletions(-)






--
Best Regards
Shawn Lin
diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index 754d24b..2bc1c35 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -931,7 +931,7 @@ static int rockchip_pcie_prog_ob_atu(struct rockchip_pcie 
*rockchip,
u32 ob_addr_0;
u32 ob_addr_1;
u32 ob_desc_0;
-   void __iomem *aw_offset;
+   u32 aw_offset;
 
if (region_no >= MAX_AXI_WRAPPER_REGION_NUM)
return -EINVAL;
@@ -955,13 +955,13 @@ static int rockchip_pcie_prog_ob_atu(struct rockchip_pcie 
*rockchip,
ob_addr_1 = upper_addr;
ob_desc_0 = (1 << 23 | type);
 
-   rockchip_pcie_writel(rockchip, ob_addr_0,
+   rockchip_pcie_write(rockchip, ob_addr_0,
 PCIE_CORE_OB_REGION_ADDR0 + aw_offset);
-   rockchip_pcie_writel(rockchip, ob_addr_1,
+   rockchip_pcie_write(rockchip, ob_addr_1,
 PCIE_CORE_OB_REGION_ADDR1 + aw_offset);
-   rockchip_pcie_writel(rockchip, ob_desc_0,
+   rockchip_pcie_write(rockchip, ob_desc_0,
 PCIE_CORE_OB_REGION_DESC0 + aw_offset);
-   rockchip_pcie_writel(rockchip, 0,
+   rockchip_pcie_write(rockchip, 0,
 PCIE_CORE_OB_REGION_DESC1 + aw_offset);
 
return 0;
@@ -973,7 +973,7 @@ static int rockchip_pcie_prog_ib_atu(struct rockchip_pcie 
*rockchip,
 {
u32 ib_addr_0;
u32 ib_addr_1;
-   void __iomem *aw_offset;
+   u32 aw_offset;
 
if (region_no > MAX_AXI_IB_ROOTPORT_REGION_NUM)
return -EINVAL;
@@ -988,8 +988,8 @@ static int rockchip_pcie_prog_ib_atu(struct rockchip_pcie 
*rockchip,
ib_addr_0 |= (lower_addr << 8) & PCIE_CORE_IB_REGION_ADDR0_LO_ADDR;
ib_addr_1 = upper_addr;
 
-   rockchip_pcie_writel(rockchip, ib_addr_0, PCIE_RP_IB_ADDR0 + aw_offset);
-   rockchip_pcie_writel(rockchip, ib_addr_1, PCIE_RP_IB_ADDR1 + aw_offset);
+   rockchip_pcie_write(rockchip, ib_addr_0, PCIE_RP_IB_ADDR0 + aw_offset);
+   rockchip_pcie_write(rockchip, ib_addr_1, PCIE_RP_IB_ADDR1 + aw_offset);
 
return 0;
 }

[ANNOUNCE] Git v2.10.0

[Junio C Hamano]

The latest feature release Git v2.10.0 is now available at the
usual places.  It is comprised of 639 non-merge commits since
v2.9.0, contributed by 76 people, 22 of which are new faces.

The tarballs are found at:

https://www.kernel.org/pub/software/scm/git/

The following public repositories all have a copy of the 'v2.10.0'
tag and the 'master' branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git

New contributors whose contributions weren't in v2.9.0 are as follows.
Welcome to the Git development community!

  Alexander Hirsch, Andreas Brauchli, Andrew Oakley, Antoine Queru,
  Ben Wijen, Christopher Layne, Dave Nicolson, David Glasser, Ed
  Maste, Heiko Becker, Ingo Brückl, Jonathan Tan, Jordan DE GEA,
  Josef Kufner, Keith McGuigan, Kevin Willford, LE Manh Cuong,
  Michael Stahl, Parker Moore, Peter Colberg, Tom Russello,
  and William Duclot.

Returning contributors who helped this release are as follows.
Thanks for your continued support.

  Alex Henrie, Alfred Perlstein, Armin Kunaschik, brian m. carlson,
  Changwoo Ryu, Charles Bailey, Chris Packham, Christian Couder,
  David A. Greene, David Aguilar, David Kastrup, David Turner,
  Edward Thomson, Elia Pinto, Eric Sunshine, Eric Wong, Heiko
  Voigt, Jacob Keller, Jean-Noel Avila, Jeff King, Jiang Xin,
  Joey Hess, Johannes Schindelin, Johannes Sixt, John Keeping,
  Jonathan Nieder, Josh Triplett, Junio C Hamano, Lars Schneider,
  Lars Vogel, Linus Torvalds, Lukas Fleischer, Matthieu Moy,
  Mehul Jain, Michael Haggerty, Michael J Gruber, Mike Hommey,
  Nguyễn Thái Ngọc Duy, Nicolas Pitre, Orgad Shaneh, Patrick
  Steinhardt, Peter Krefting, Pranit Bauva, Ramsay Jones, René
  Scharfe, Ronald Wampler, Stefan Beller, SZEDER Gábor, Thomas
  Braun, Thomas Gummerer, Torsten Bögershausen, Trần Ngọc
  Quân, Vasco Almeida, and Ville Skyttä.



Git 2.10 Release Notes
==

Backward compatibility notes


Updates since v2.9
--

UI, Workflows & Features

 * "git pull --rebase --verify-signature" learned to warn the user
   that "--verify-signature" is a no-op when rebasing.

 * An upstream project can make a recommendation to shallowly clone
   some submodules in the .gitmodules file it ships.

 * "git worktree add" learned that '-' can be used as a short-hand for
   "@{-1}", the previous branch.

 * Update the funcname definition to support css files.

 * The completion script (in contrib/) learned to complete "git
   status" options.

 * Messages that are generated by auto gc during "git push" on the
   receiving end are now passed back to the sending end in such a way
   that they are shown with "remote: " prefix to avoid confusing the
   users.

 * "git add -i/-p" learned to honor diff.compactionHeuristic
   experimental knob, so that the user can work on the same hunk split
   as "git diff" output.

 * "upload-pack" allows a custom "git pack-objects" replacement when
   responding to "fetch/clone" via the uploadpack.packObjectsHook.
   (merge b738396 jk/upload-pack-hook later to maint).

 * Teach format-patch and mailsplit (hence "am") how a line that
   happens to begin with "From " in the e-mail message is quoted with
   ">", so that these lines can be restored to their original shape.
   (merge d9925d1 ew/mboxrd-format-am later to maint).

 * "git repack" learned the "--keep-unreachable" option, which sends
   loose unreachable objects to a pack instead of leaving them loose.
   This helps heuristics based on the number of loose objects
   (e.g. "gc --auto").
   (merge e26a8c4 jk/repack-keep-unreachable later to maint).

 * "log --graph --format=" learned that "%>|(N)" specifies the width
   relative to the terminal's left edge, not relative to the area to
   draw text that is to the right of the ancestry-graph section.  It
   also now accepts negative N that means the column limit is relative
   to the right border.

 * A careless invocation of "git send-email directory/" after editing
   0001-change.patch with an editor often ends up sending both
   0001-change.patch and its backup file, 0001-change.patch~, causing
   embarrassment and a minor confusion.  Detect such an input and
   offer to skip the backup files when sending the patches out.
   (merge 531220b jc/send-email-skip-backup later to maint).

 * "git submodule update" that drives many "git clone" could
   eventually hit flaky servers/network conditions on one of the
   submodules; the command learned to retry the attempt.

 * The output coloring scheme learned two new attributes, italic and
   strike, in addition to existing bold, reverse, etc.

 * "git log" learns log.showSignature configuration variable, and a
   command line 

[ANNOUNCE] Git v2.10.0

[Junio C Hamano]

The latest feature release Git v2.10.0 is now available at the
usual places.  It is comprised of 639 non-merge commits since
v2.9.0, contributed by 76 people, 22 of which are new faces.

The tarballs are found at:

https://www.kernel.org/pub/software/scm/git/

The following public repositories all have a copy of the 'v2.10.0'
tag and the 'master' branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git

New contributors whose contributions weren't in v2.9.0 are as follows.
Welcome to the Git development community!

  Alexander Hirsch, Andreas Brauchli, Andrew Oakley, Antoine Queru,
  Ben Wijen, Christopher Layne, Dave Nicolson, David Glasser, Ed
  Maste, Heiko Becker, Ingo Brückl, Jonathan Tan, Jordan DE GEA,
  Josef Kufner, Keith McGuigan, Kevin Willford, LE Manh Cuong,
  Michael Stahl, Parker Moore, Peter Colberg, Tom Russello,
  and William Duclot.

Returning contributors who helped this release are as follows.
Thanks for your continued support.

  Alex Henrie, Alfred Perlstein, Armin Kunaschik, brian m. carlson,
  Changwoo Ryu, Charles Bailey, Chris Packham, Christian Couder,
  David A. Greene, David Aguilar, David Kastrup, David Turner,
  Edward Thomson, Elia Pinto, Eric Sunshine, Eric Wong, Heiko
  Voigt, Jacob Keller, Jean-Noel Avila, Jeff King, Jiang Xin,
  Joey Hess, Johannes Schindelin, Johannes Sixt, John Keeping,
  Jonathan Nieder, Josh Triplett, Junio C Hamano, Lars Schneider,
  Lars Vogel, Linus Torvalds, Lukas Fleischer, Matthieu Moy,
  Mehul Jain, Michael Haggerty, Michael J Gruber, Mike Hommey,
  Nguyễn Thái Ngọc Duy, Nicolas Pitre, Orgad Shaneh, Patrick
  Steinhardt, Peter Krefting, Pranit Bauva, Ramsay Jones, René
  Scharfe, Ronald Wampler, Stefan Beller, SZEDER Gábor, Thomas
  Braun, Thomas Gummerer, Torsten Bögershausen, Trần Ngọc
  Quân, Vasco Almeida, and Ville Skyttä.



Git 2.10 Release Notes
==

Backward compatibility notes


Updates since v2.9
--

UI, Workflows & Features

 * "git pull --rebase --verify-signature" learned to warn the user
   that "--verify-signature" is a no-op when rebasing.

 * An upstream project can make a recommendation to shallowly clone
   some submodules in the .gitmodules file it ships.

 * "git worktree add" learned that '-' can be used as a short-hand for
   "@{-1}", the previous branch.

 * Update the funcname definition to support css files.

 * The completion script (in contrib/) learned to complete "git
   status" options.

 * Messages that are generated by auto gc during "git push" on the
   receiving end are now passed back to the sending end in such a way
   that they are shown with "remote: " prefix to avoid confusing the
   users.

 * "git add -i/-p" learned to honor diff.compactionHeuristic
   experimental knob, so that the user can work on the same hunk split
   as "git diff" output.

 * "upload-pack" allows a custom "git pack-objects" replacement when
   responding to "fetch/clone" via the uploadpack.packObjectsHook.
   (merge b738396 jk/upload-pack-hook later to maint).

 * Teach format-patch and mailsplit (hence "am") how a line that
   happens to begin with "From " in the e-mail message is quoted with
   ">", so that these lines can be restored to their original shape.
   (merge d9925d1 ew/mboxrd-format-am later to maint).

 * "git repack" learned the "--keep-unreachable" option, which sends
   loose unreachable objects to a pack instead of leaving them loose.
   This helps heuristics based on the number of loose objects
   (e.g. "gc --auto").
   (merge e26a8c4 jk/repack-keep-unreachable later to maint).

 * "log --graph --format=" learned that "%>|(N)" specifies the width
   relative to the terminal's left edge, not relative to the area to
   draw text that is to the right of the ancestry-graph section.  It
   also now accepts negative N that means the column limit is relative
   to the right border.

 * A careless invocation of "git send-email directory/" after editing
   0001-change.patch with an editor often ends up sending both
   0001-change.patch and its backup file, 0001-change.patch~, causing
   embarrassment and a minor confusion.  Detect such an input and
   offer to skip the backup files when sending the patches out.
   (merge 531220b jc/send-email-skip-backup later to maint).

 * "git submodule update" that drives many "git clone" could
   eventually hit flaky servers/network conditions on one of the
   submodules; the command learned to retry the attempt.

 * The output coloring scheme learned two new attributes, italic and
   strike, in addition to existing bold, reverse, etc.

 * "git log" learns log.showSignature configuration variable, and a
   command line 

[GIT PULL] Block fixes for 4.8-rc

[Jens Axboe]

Hi Linus,

Collection of fixes for the nvme over fabrics code. The shortlog is
below, probably no need to further detail it.

Please pull, thanks!


  git://git.kernel.dk/linux-block.git for-linus



Christoph Hellwig (2):
  nvme-fabrics: get a reference when reusing a nvme_host structure
  nvme: fabrics drivers don't need the nvme-pci driver

Colin Ian King (1):
  nvme-rdma: initialize ret to zero to avoid returning garbage

Daniel Verkamp (1):
  nvme-fabrics: change NQN UUID to big-endian format

Jay Freyensee (4):
  nvmet-rdma: +1 to *queue_size from hsqsize/hrqsize
  fabrics: define admin sqsize min default, per spec
  nvme-rdma: fix sqsize/hsqsize per spec
  nvme-loop: set sqsize to 0-based value, per spec

Jens Axboe (1):
  Merge branch 'nvmf-4.8-rc' of 
git://git.infradead.org/nvme-fabrics into for-linus


Sagi Grimberg (2):
  nvme-rdma: Get rid of duplicate variable
  nvme-rdma: Get rid of redundant defines

Vincent Stehlé (1):
  nvmet-rdma: Fix use after free

 drivers/nvme/host/Kconfig   |  2 +-
 drivers/nvme/host/fabrics.c | 23 ---
 drivers/nvme/host/fabrics.h |  2 +-
 drivers/nvme/host/rdma.c| 46 
+++--

 drivers/nvme/target/Kconfig |  2 +-
 drivers/nvme/target/loop.c  |  4 ++--
 drivers/nvme/target/rdma.c  |  7 ---
 include/linux/nvme.h|  2 +-
 8 files changed, 54 insertions(+), 34 deletions(-)

--
Jens Axboe

[GIT PULL] Block fixes for 4.8-rc

[Jens Axboe]

Hi Linus,

Collection of fixes for the nvme over fabrics code. The shortlog is
below, probably no need to further detail it.

Please pull, thanks!


  git://git.kernel.dk/linux-block.git for-linus



Christoph Hellwig (2):
  nvme-fabrics: get a reference when reusing a nvme_host structure
  nvme: fabrics drivers don't need the nvme-pci driver

Colin Ian King (1):
  nvme-rdma: initialize ret to zero to avoid returning garbage

Daniel Verkamp (1):
  nvme-fabrics: change NQN UUID to big-endian format

Jay Freyensee (4):
  nvmet-rdma: +1 to *queue_size from hsqsize/hrqsize
  fabrics: define admin sqsize min default, per spec
  nvme-rdma: fix sqsize/hsqsize per spec
  nvme-loop: set sqsize to 0-based value, per spec

Jens Axboe (1):
  Merge branch 'nvmf-4.8-rc' of 
git://git.infradead.org/nvme-fabrics into for-linus


Sagi Grimberg (2):
  nvme-rdma: Get rid of duplicate variable
  nvme-rdma: Get rid of redundant defines

Vincent Stehlé (1):
  nvmet-rdma: Fix use after free

 drivers/nvme/host/Kconfig   |  2 +-
 drivers/nvme/host/fabrics.c | 23 ---
 drivers/nvme/host/fabrics.h |  2 +-
 drivers/nvme/host/rdma.c| 46 
+++--

 drivers/nvme/target/Kconfig |  2 +-
 drivers/nvme/target/loop.c  |  4 ++--
 drivers/nvme/target/rdma.c  |  7 ---
 include/linux/nvme.h|  2 +-
 8 files changed, 54 insertions(+), 34 deletions(-)

--
Jens Axboe

RE: [PATCH 2/4] thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver support

[Khiem Nguyen]

Hi Morimoto-san,
 
Thanks for your comments.

> > +int _linear_temp_converter(struct equation_coefs coef,
> > +   int temp_code)
> > +{
> > +   int temp, temp1, temp2;
> > +
> > +   temp1 = MCELSIUS((CODETSD(temp_code) - coef.b1)) / coef.a1;
> > +   temp2 = MCELSIUS((CODETSD(temp_code) - coef.b2)) / coef.a2;
> > +   temp = (temp1 + temp2) / 2;
> > +
> > +   return _round_temp(temp);
> > +}
> 
> You want to have "static" function here ?

Sound good. Will update in v2.

> > +static int rcar_gen3_thermal_get_temp(void *devdata, int *temp) {
> > +   struct rcar_gen3_thermal_priv *priv = devdata;
> > +   int ctemp;
> > +   unsigned long flags;
> > +
> > +   rcar_gen3_thermal_update_temp(priv);
> > +
> > +   spin_lock_irqsave(>lock, flags);
> > +   ctemp = _linear_temp_converter(priv->coef, priv->ctemp);
> > +   spin_unlock_irqrestore(>lock, flags);
> 
> using pointer on _linear_temp_converter() is reasonable ?
> especially for struct equation_coefs coef
 
I failed to see the benefit of the change.
Could you elaborate the points ?
e.g better memory protection, faster byte-code execution, readability, etc


> > +static const struct rcar_gen3_thermal_data r8a7795_data = {
> > +   .thermal_init = r8a7795_thermal_init, };
> > +
> > +static const struct rcar_gen3_thermal_data r8a7796_data = {
> > +   .thermal_init = r8a7796_thermal_init, };
> > +
> > +static const struct of_device_id rcar_gen3_thermal_dt_ids[] = {
> > +   { .compatible = "renesas,thermal-r8a7795", .data = _data},
> > +   { .compatible = "renesas,thermal-r8a7796", .data = _data},
> > +   { .compatible = "renesas,rcar-gen3-thermal", .data = _data},
> > +   {},
> > +};
> > +MODULE_DEVICE_TABLE(of, rcar_gen3_thermal_dt_ids);
> 
> We can't have general case in this case ?
> "renesas,rcar-gen3-thermal" is not needed IMO.
> Especially this driver doesn't need to care about back compatibility yet.

OK. I see your point. Will update in V2.

> > +static int rcar_gen3_thermal_probe(struct platform_device *pdev) {
> > +   struct rcar_gen3_thermal_priv *priv;
> > +   struct device *dev = >dev;
> > +   struct resource *res, *irq;
> > +   int ret = -ENODEV;
> > +   int idle;
> > +   struct device_node *tz_nd, *tmp_nd;
> > +
> > +   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > +   if (!priv)
> > +   return -ENOMEM;
> > +
> > +   platform_set_drvdata(pdev, priv);
> > +
> > +   priv->dev = dev;
> > +
> > +   pm_runtime_enable(dev);
> > +   pm_runtime_get_sync(dev);
> > +
> > +   priv->data = of_device_get_match_data(dev);
> > +   if (!priv->data)
> > +   goto error_unregister;
> > +
> > +   irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> > +   priv->irq = 0;
> > +   if (irq) {
> > +   priv->irq = 1;
> > +   for_each_node_with_property(tz_nd, "polling-delay") {
> > +   tmp_nd = of_parse_phandle(tz_nd,
> > +   "thermal-sensors", 0);
> > +   if (tmp_nd && !strcmp(tmp_nd->full_name,
> > +   dev->of_node->full_name)) {
> > +   of_property_read_u32(tz_nd, "polling-delay",
> > +   );
> > +   (idle > 0) ? (priv->irq = 0) :
> > +   (priv->irq = 1);
> > +   break;
> > +   }
> 
> it is not readable for me.
> 
>   if (idle > 0)
>   priv->irq = 0;
>   break;
> 
> is enough ?

Unfortunately, it's not.
The code tries to check "polling-delay" in order to select polling mode and get 
polling duration from DT.
So, your proposal just do 1st part.

> 
> > +   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +   if (!res)
> > +   goto error_unregister;
> > +
> > +   priv->base = devm_ioremap_resource(dev, res);
> > +   if (IS_ERR(priv->base)) {
> > +   ret = PTR_ERR(priv->base);
> > +   goto error_unregister;
> > +   }
> > +
> > +   spin_lock_init(>lock);
> > +   INIT_DELAYED_WORK(>work, rcar_gen3_thermal_work);
> > +
> > +   priv->id = of_alias_get_id(dev->of_node, "tsc");
> 
> Do we really need alias ?
> is "tsc" good naming ?

It's the abbreviation of Thermal sensor controller.
The term has been described in HW manual. Therefore, I think it's 'reasonable' 
name.

> Having this explanation on [1/4] patch document is useful.
> of_alias_get_id() can return -ENODEV, but no error check ?

Good point. Will fix in v2.

> > +   priv->zone = devm_thermal_zone_of_sensor_register(dev, 0, priv,
> > +   _gen3_tz_of_ops);
> > +
> > +   if (IS_ERR(priv->zone)) {
> > +   dev_err(dev, "Can't register thermal zone\n");
> > +   ret = PTR_ERR(priv->zone);
> > +   priv->zone = NULL;
> > +   goto error_unregister;
> > +   }
> 
> It is not bad operation, but not readable.
> How about to have local struct thermal_zone_device *zone, like this ?

It's good point.
I saw 

RE: [PATCH 2/4] thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver support

[Khiem Nguyen]

Hi Morimoto-san,
 
Thanks for your comments.

> > +int _linear_temp_converter(struct equation_coefs coef,
> > +   int temp_code)
> > +{
> > +   int temp, temp1, temp2;
> > +
> > +   temp1 = MCELSIUS((CODETSD(temp_code) - coef.b1)) / coef.a1;
> > +   temp2 = MCELSIUS((CODETSD(temp_code) - coef.b2)) / coef.a2;
> > +   temp = (temp1 + temp2) / 2;
> > +
> > +   return _round_temp(temp);
> > +}
> 
> You want to have "static" function here ?

Sound good. Will update in v2.

> > +static int rcar_gen3_thermal_get_temp(void *devdata, int *temp) {
> > +   struct rcar_gen3_thermal_priv *priv = devdata;
> > +   int ctemp;
> > +   unsigned long flags;
> > +
> > +   rcar_gen3_thermal_update_temp(priv);
> > +
> > +   spin_lock_irqsave(>lock, flags);
> > +   ctemp = _linear_temp_converter(priv->coef, priv->ctemp);
> > +   spin_unlock_irqrestore(>lock, flags);
> 
> using pointer on _linear_temp_converter() is reasonable ?
> especially for struct equation_coefs coef
 
I failed to see the benefit of the change.
Could you elaborate the points ?
e.g better memory protection, faster byte-code execution, readability, etc


> > +static const struct rcar_gen3_thermal_data r8a7795_data = {
> > +   .thermal_init = r8a7795_thermal_init, };
> > +
> > +static const struct rcar_gen3_thermal_data r8a7796_data = {
> > +   .thermal_init = r8a7796_thermal_init, };
> > +
> > +static const struct of_device_id rcar_gen3_thermal_dt_ids[] = {
> > +   { .compatible = "renesas,thermal-r8a7795", .data = _data},
> > +   { .compatible = "renesas,thermal-r8a7796", .data = _data},
> > +   { .compatible = "renesas,rcar-gen3-thermal", .data = _data},
> > +   {},
> > +};
> > +MODULE_DEVICE_TABLE(of, rcar_gen3_thermal_dt_ids);
> 
> We can't have general case in this case ?
> "renesas,rcar-gen3-thermal" is not needed IMO.
> Especially this driver doesn't need to care about back compatibility yet.

OK. I see your point. Will update in V2.

> > +static int rcar_gen3_thermal_probe(struct platform_device *pdev) {
> > +   struct rcar_gen3_thermal_priv *priv;
> > +   struct device *dev = >dev;
> > +   struct resource *res, *irq;
> > +   int ret = -ENODEV;
> > +   int idle;
> > +   struct device_node *tz_nd, *tmp_nd;
> > +
> > +   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > +   if (!priv)
> > +   return -ENOMEM;
> > +
> > +   platform_set_drvdata(pdev, priv);
> > +
> > +   priv->dev = dev;
> > +
> > +   pm_runtime_enable(dev);
> > +   pm_runtime_get_sync(dev);
> > +
> > +   priv->data = of_device_get_match_data(dev);
> > +   if (!priv->data)
> > +   goto error_unregister;
> > +
> > +   irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> > +   priv->irq = 0;
> > +   if (irq) {
> > +   priv->irq = 1;
> > +   for_each_node_with_property(tz_nd, "polling-delay") {
> > +   tmp_nd = of_parse_phandle(tz_nd,
> > +   "thermal-sensors", 0);
> > +   if (tmp_nd && !strcmp(tmp_nd->full_name,
> > +   dev->of_node->full_name)) {
> > +   of_property_read_u32(tz_nd, "polling-delay",
> > +   );
> > +   (idle > 0) ? (priv->irq = 0) :
> > +   (priv->irq = 1);
> > +   break;
> > +   }
> 
> it is not readable for me.
> 
>   if (idle > 0)
>   priv->irq = 0;
>   break;
> 
> is enough ?

Unfortunately, it's not.
The code tries to check "polling-delay" in order to select polling mode and get 
polling duration from DT.
So, your proposal just do 1st part.

> 
> > +   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +   if (!res)
> > +   goto error_unregister;
> > +
> > +   priv->base = devm_ioremap_resource(dev, res);
> > +   if (IS_ERR(priv->base)) {
> > +   ret = PTR_ERR(priv->base);
> > +   goto error_unregister;
> > +   }
> > +
> > +   spin_lock_init(>lock);
> > +   INIT_DELAYED_WORK(>work, rcar_gen3_thermal_work);
> > +
> > +   priv->id = of_alias_get_id(dev->of_node, "tsc");
> 
> Do we really need alias ?
> is "tsc" good naming ?

It's the abbreviation of Thermal sensor controller.
The term has been described in HW manual. Therefore, I think it's 'reasonable' 
name.

> Having this explanation on [1/4] patch document is useful.
> of_alias_get_id() can return -ENODEV, but no error check ?

Good point. Will fix in v2.

> > +   priv->zone = devm_thermal_zone_of_sensor_register(dev, 0, priv,
> > +   _gen3_tz_of_ops);
> > +
> > +   if (IS_ERR(priv->zone)) {
> > +   dev_err(dev, "Can't register thermal zone\n");
> > +   ret = PTR_ERR(priv->zone);
> > +   priv->zone = NULL;
> > +   goto error_unregister;
> > +   }
> 
> It is not bad operation, but not readable.
> How about to have local struct thermal_zone_device *zone, like this ?

It's good point.
I saw 

[ima] 529aa19519: BUG: spinlock bad magic on CPU#1, swapper/0/1

[kernel test robot]

FYI, we noticed the following commit:

https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git 
next-restore-kexec
commit 529aa195198645e2a8e97872e5d57a929883a910 ("ima: store the builtin/custom 
template definitions in a list")

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 1G

caused below changes:


+---+++
|   | ae1b8f8c4d | 529aa19519 |
+---+++
| boot_successes| 6  | 0  |
| boot_failures | 0  | 6  |
| BUG:spinlock_bad_magic_on_CPU | 0  | 6  |
| calltrace:init_ima| 0  | 6  |
+---+++



[   17.388687] cryptomgr_probe (157) used greatest stack depth: 13872 bytes left
[   17.391265] Key type trusted registered
[   17.393763] Key type encrypted registered
[   17.394912] BUG: spinlock bad magic on CPU#1, swapper/0/1
[   17.396088]  lock: template_list+0x0/0x48, .magic: , .owner: 
swapper/0/1, .owner_cpu: 1
[   17.397731] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 
4.8.0-rc1-00027-g529aa19 #1
[   17.399271] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[   17.401114]   8800364fbdf0 814a5e6c 
8800364f1780
[   17.402879]  82521865 8800364fbe10 810fbfd8 
83109280
[   17.404520]  8225c200 8800364fbe30 810fc003 
83109280
[   17.406024] Call Trace:
[   17.406539]  [] dump_stack+0x61/0x7e
[   17.407534]  [] ? set_debug_rodata+0x12/0x12
[   17.408658]  [] spin_dump+0x85/0x8a
[   17.409731]  [] spin_bug+0x26/0x28
[   17.410855]  [] do_raw_spin_unlock+0x1d/0x7c
[   17.412212]  [] _raw_spin_unlock+0x22/0x3f
[   17.413480]  [] ima_init_template_list+0x4b/0x55
[   17.414837]  [] ? hash_setup+0xb3/0xb3
[   17.415982]  [] init_ima+0xa/0x36
[   17.417113]  [] do_one_initcall+0x8b/0x119
[   17.418377]  [] ? set_debug_rodata+0x12/0x12
[   17.419643]  [] kernel_init_freeable+0x119/0x1a6
[   17.420936]  [] kernel_init+0x9/0xeb
[   17.421988]  [] ret_from_fork+0x1f/0x40
[   17.423244]  [] ? rest_init+0xb9/0xb9
[   17.451107] ima: No TPM chip found, activating TPM-bypass!
[   17.452384] evm: HMAC attrs: 0x0






Thanks,
Kernel Test Robot
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.8.0-rc1 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
CONFIG_KERNEL_LZO=y
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
# CONFIG_SYSVIPC is not set
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y

[ima] 529aa19519: BUG: spinlock bad magic on CPU#1, swapper/0/1

[kernel test robot]

FYI, we noticed the following commit:

https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git 
next-restore-kexec
commit 529aa195198645e2a8e97872e5d57a929883a910 ("ima: store the builtin/custom 
template definitions in a list")

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 1G

caused below changes:


+---+++
|   | ae1b8f8c4d | 529aa19519 |
+---+++
| boot_successes| 6  | 0  |
| boot_failures | 0  | 6  |
| BUG:spinlock_bad_magic_on_CPU | 0  | 6  |
| calltrace:init_ima| 0  | 6  |
+---+++



[   17.388687] cryptomgr_probe (157) used greatest stack depth: 13872 bytes left
[   17.391265] Key type trusted registered
[   17.393763] Key type encrypted registered
[   17.394912] BUG: spinlock bad magic on CPU#1, swapper/0/1
[   17.396088]  lock: template_list+0x0/0x48, .magic: , .owner: 
swapper/0/1, .owner_cpu: 1
[   17.397731] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 
4.8.0-rc1-00027-g529aa19 #1
[   17.399271] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[   17.401114]   8800364fbdf0 814a5e6c 
8800364f1780
[   17.402879]  82521865 8800364fbe10 810fbfd8 
83109280
[   17.404520]  8225c200 8800364fbe30 810fc003 
83109280
[   17.406024] Call Trace:
[   17.406539]  [] dump_stack+0x61/0x7e
[   17.407534]  [] ? set_debug_rodata+0x12/0x12
[   17.408658]  [] spin_dump+0x85/0x8a
[   17.409731]  [] spin_bug+0x26/0x28
[   17.410855]  [] do_raw_spin_unlock+0x1d/0x7c
[   17.412212]  [] _raw_spin_unlock+0x22/0x3f
[   17.413480]  [] ima_init_template_list+0x4b/0x55
[   17.414837]  [] ? hash_setup+0xb3/0xb3
[   17.415982]  [] init_ima+0xa/0x36
[   17.417113]  [] do_one_initcall+0x8b/0x119
[   17.418377]  [] ? set_debug_rodata+0x12/0x12
[   17.419643]  [] kernel_init_freeable+0x119/0x1a6
[   17.420936]  [] kernel_init+0x9/0xeb
[   17.421988]  [] ret_from_fork+0x1f/0x40
[   17.423244]  [] ? rest_init+0xb9/0xb9
[   17.451107] ima: No TPM chip found, activating TPM-bypass!
[   17.452384] evm: HMAC attrs: 0x0






Thanks,
Kernel Test Robot
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.8.0-rc1 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
CONFIG_KERNEL_LZO=y
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
# CONFIG_SYSVIPC is not set
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y

[PATCH v2] x86/AMD: Fix Socket ID for LLC topology for AMD Fam17h systems

[Yazen Ghannam]

Socket ID is an unsigned value and starts at 0. Subtracting 1
from it is incorrect and the result will underflow if
socket_id=0.

Remove substraction when extracting socket_id from c->apicid.

Signed-off-by: Yazen Ghannam 
---
Link:
http://lkml.kernel.org/r/1472674900-60688-1-git-send-email-yazen.ghan...@amd.com

v1->v2:
* Don't do logical AND so as to not restrict # of sockets to 2.

 arch/x86/kernel/cpu/amd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index f3d8a92..793bc23 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -365,7 +365,7 @@ static void amd_detect_cmp(struct cpuinfo_x86 *c)
 if (c->x86 != 0x17 || !cpuid_edx(0x8006))
return;
 
-   socket_id   = (c->apicid >> bits) - 1;
+   socket_id   = c->apicid >> bits;
core_complex_id = (c->apicid & ((1 << bits) - 1)) >> 3;
 
per_cpu(cpu_llc_id, cpu) = (socket_id << 3) | core_complex_id;
-- 
1.9.1

[PATCH v2] x86/AMD: Fix Socket ID for LLC topology for AMD Fam17h systems

[Yazen Ghannam]

Socket ID is an unsigned value and starts at 0. Subtracting 1
from it is incorrect and the result will underflow if
socket_id=0.

Remove substraction when extracting socket_id from c->apicid.

Signed-off-by: Yazen Ghannam 
---
Link:
http://lkml.kernel.org/r/1472674900-60688-1-git-send-email-yazen.ghan...@amd.com

v1->v2:
* Don't do logical AND so as to not restrict # of sockets to 2.

 arch/x86/kernel/cpu/amd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index f3d8a92..793bc23 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -365,7 +365,7 @@ static void amd_detect_cmp(struct cpuinfo_x86 *c)
 if (c->x86 != 0x17 || !cpuid_edx(0x8006))
return;
 
-   socket_id   = (c->apicid >> bits) - 1;
+   socket_id   = c->apicid >> bits;
core_complex_id = (c->apicid & ((1 << bits) - 1)) >> 3;
 
per_cpu(cpu_llc_id, cpu) = (socket_id << 3) | core_complex_id;
-- 
1.9.1

Re: [PATCH 0/7] drm/sun4i: Introduce A33 display driver

[Chen-Yu Tsai]

On Sat, Sep 3, 2016 at 3:06 AM, Maxime Ripard
 wrote:
> Hi Icenowy,
>
> On Fri, Sep 02, 2016 at 09:30:05AM +0800, Icenowy Zheng wrote:
>>
>>
>> 01.09.2016, 23:40, "Maxime Ripard" :
>> > Hi everyone,
>> >
>> > This serie introduces the support in the sun4i-drm driver for the A33.
>> >
>> > Beside the new IPs and special cases for the A33 new IPs, there's
>> > nothing really outstanding, and is now at feature parity with the A13.
>>
>> How can the driver be modified to support LVDS screen?
>>
>> I have an A33 tablet with a 1024x768 LVDS panel. (iNet D978 Rev2 board,
>> which I pushed a dt a few days ago)
>
> Awesome, I don't have such a screen myself, so feel free to work on
> it.
>
> I haven't looked into the details of LVDS, but it should be something
> along the lines of commit 29e57fab97fc ("drm: sun4i: Add RGB output").

The implementation might be along the lines of

  1. having multiple output ports, each for a different interface type.
 (Some platforms go this route)

Or

  2. having a DT property describe what the output interface is.

The RGB/TCON driver would then setup the registers accordingly.


ChenYu

Re: [PATCH 0/7] drm/sun4i: Introduce A33 display driver

[Chen-Yu Tsai]

On Sat, Sep 3, 2016 at 3:06 AM, Maxime Ripard
 wrote:
> Hi Icenowy,
>
> On Fri, Sep 02, 2016 at 09:30:05AM +0800, Icenowy Zheng wrote:
>>
>>
>> 01.09.2016, 23:40, "Maxime Ripard" :
>> > Hi everyone,
>> >
>> > This serie introduces the support in the sun4i-drm driver for the A33.
>> >
>> > Beside the new IPs and special cases for the A33 new IPs, there's
>> > nothing really outstanding, and is now at feature parity with the A13.
>>
>> How can the driver be modified to support LVDS screen?
>>
>> I have an A33 tablet with a 1024x768 LVDS panel. (iNet D978 Rev2 board,
>> which I pushed a dt a few days ago)
>
> Awesome, I don't have such a screen myself, so feel free to work on
> it.
>
> I haven't looked into the details of LVDS, but it should be something
> along the lines of commit 29e57fab97fc ("drm: sun4i: Add RGB output").

The implementation might be along the lines of

  1. having multiple output ports, each for a different interface type.
 (Some platforms go this route)

Or

  2. having a DT property describe what the output interface is.

The RGB/TCON driver would then setup the registers accordingly.


ChenYu

Re: [PATCH 4/4] kvm: x86: export TSC offset to user-space

[Luiz Capitulino]

On Fri, 2 Sep 2016 20:49:37 -0300
Marcelo Tosatti  wrote:

> On Fri, Sep 02, 2016 at 09:43:01AM -0400, Stefan Hajnoczi wrote:
> > On Wed, Aug 31, 2016 at 01:05:45PM -0400, Luiz Capitulino wrote:  
> > > We need to retrieve a VM's TSC offset in order to use
> > > the host's TSC to merge host and guest traces. This is
> > > explained in detail in this thread:
> > > 
> > >   [Qemu-devel] [RFC] host and guest kernel trace merging
> > >   https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg00887.html
> > > 
> > > Today, the only way to retrieve a VM's TSC offset is
> > > by using the kvm_write_tsc_offset tracepoint. This has
> > > a few problems. First, the tracepoint is only emitted
> > > when the VM boots, which requires a reboot to get it if
> > > the VM is already running. Second, tracepoints are not
> > > supposed to be ABIs in case they need to be consumed by
> > > user-space tools.
> > > 
> > > This commit exports a VM's TSC offset to user-space via
> > > debugfs. A new file called "tsc-offset" is created in
> > > the VM's debugfs directory. For example:
> > > 
> > >   /sys/kernel/debug/kvm/51696-10/tsc-offset
> > > 
> > > This file contains one TSC offset per line, for each
> > > vCPU. For example:
> > > 
> > >   vcpu0: 18446742405270834952
> > >   vcpu1: 18446742405270834952
> > >   vcpu2: 18446742405270834952
> > >   vcpu3: 18446742405270834952
> > > 
> > > There are some important observations about this
> > > solution:
> > > 
> > >  - While all vCPUs TSC offsets should be equal for the
> > >cases we care about (ie. stable TSC and no write to
> > >the TSC MSR), I chose to follow the spec and export
> > >each vCPU's TSC offset (might also be helpful for
> > >debugging)
> > > 
> > >  - The TSC offset is only useful after the VM has booted
> > > 
> > >  - We'll probably need to export the TSC multiplier too.
> > >However, I've been using only the TSC offset for now.
> > >So, let's get this merged first and do the TSC multiplier
> > >as a second step  
> > 
> > Can TSC offset changes occur at runtime?
> > 
> > One example is vcpu hotplug where the tracing tool would need to fetch
> > the new vcpu's TSC offset after tracing has already started.
> > 
> > Another example is if QEMU or the guest change the TSC offset while
> > running.  If the tracing tool doesn't notice this then trace events will 
> > have
> > incorrect timestamps.
> > 
> > Stefan  
> 
> Yes they can, and the interface should mention that "the user is
> responsible for handling races of execution" (IMO).
> 
> So the workflow is:
> 
> 1) User boots VM and knows the state of the VM.
> 2) User runs trace-cmd on the host.
> 
> Is there a need to automate gathering of traces? (that is to know the
> state of reboots and so forth). I don't see one. In that case, the above
> workflow is functional.
> 
> Can you add such comments to the interface Luiz (that the value
> read is potentially stale).

Sure, no problem.

Re: [PATCH 4/4] kvm: x86: export TSC offset to user-space

[Luiz Capitulino]

On Fri, 2 Sep 2016 20:49:37 -0300
Marcelo Tosatti  wrote:

> On Fri, Sep 02, 2016 at 09:43:01AM -0400, Stefan Hajnoczi wrote:
> > On Wed, Aug 31, 2016 at 01:05:45PM -0400, Luiz Capitulino wrote:  
> > > We need to retrieve a VM's TSC offset in order to use
> > > the host's TSC to merge host and guest traces. This is
> > > explained in detail in this thread:
> > > 
> > >   [Qemu-devel] [RFC] host and guest kernel trace merging
> > >   https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg00887.html
> > > 
> > > Today, the only way to retrieve a VM's TSC offset is
> > > by using the kvm_write_tsc_offset tracepoint. This has
> > > a few problems. First, the tracepoint is only emitted
> > > when the VM boots, which requires a reboot to get it if
> > > the VM is already running. Second, tracepoints are not
> > > supposed to be ABIs in case they need to be consumed by
> > > user-space tools.
> > > 
> > > This commit exports a VM's TSC offset to user-space via
> > > debugfs. A new file called "tsc-offset" is created in
> > > the VM's debugfs directory. For example:
> > > 
> > >   /sys/kernel/debug/kvm/51696-10/tsc-offset
> > > 
> > > This file contains one TSC offset per line, for each
> > > vCPU. For example:
> > > 
> > >   vcpu0: 18446742405270834952
> > >   vcpu1: 18446742405270834952
> > >   vcpu2: 18446742405270834952
> > >   vcpu3: 18446742405270834952
> > > 
> > > There are some important observations about this
> > > solution:
> > > 
> > >  - While all vCPUs TSC offsets should be equal for the
> > >cases we care about (ie. stable TSC and no write to
> > >the TSC MSR), I chose to follow the spec and export
> > >each vCPU's TSC offset (might also be helpful for
> > >debugging)
> > > 
> > >  - The TSC offset is only useful after the VM has booted
> > > 
> > >  - We'll probably need to export the TSC multiplier too.
> > >However, I've been using only the TSC offset for now.
> > >So, let's get this merged first and do the TSC multiplier
> > >as a second step  
> > 
> > Can TSC offset changes occur at runtime?
> > 
> > One example is vcpu hotplug where the tracing tool would need to fetch
> > the new vcpu's TSC offset after tracing has already started.
> > 
> > Another example is if QEMU or the guest change the TSC offset while
> > running.  If the tracing tool doesn't notice this then trace events will 
> > have
> > incorrect timestamps.
> > 
> > Stefan  
> 
> Yes they can, and the interface should mention that "the user is
> responsible for handling races of execution" (IMO).
> 
> So the workflow is:
> 
> 1) User boots VM and knows the state of the VM.
> 2) User runs trace-cmd on the host.
> 
> Is there a need to automate gathering of traces? (that is to know the
> state of reboots and so forth). I don't see one. In that case, the above
> workflow is functional.
> 
> Can you add such comments to the interface Luiz (that the value
> read is potentially stale).

Sure, no problem.

Ahoj....

[Xiao]

Ahoj,

Jsem zastupující investicní zájem ze strany Thajska mají zájem
zahranicních investic zahrnující velký objem finanních
prostredk, pro které se snazíme svou úcast jako v zámoí
zástupce zvládnout investice. Muj klient, který je rodák z Thajska, má
nejaké peníze ze svých obchodních úspor chce investovat na základ
kvalifikovaných zahranicních partnerství. Pokud máte pocit naklonni
vyzádaná roli, uvedte o rychlou odezvu, takze já vám muze poskytnout dalsi
podrobnosti spolupráce.

Mejte vsak na pameti, ze se jedná o legitimní transakce a tesím se na vase
rychlé odpovedi na muj soukromý e-mail níze:

Pozdravy,
dngsn...@gmail.com
Barr. Xiaodong Su

Ahoj....

[Xiao]

Ahoj,

Jsem zastupující investicní zájem ze strany Thajska mají zájem
zahranicních investic zahrnující velký objem finanních
prostredk, pro které se snazíme svou úcast jako v zámoí
zástupce zvládnout investice. Muj klient, který je rodák z Thajska, má
nejaké peníze ze svých obchodních úspor chce investovat na základ
kvalifikovaných zahranicních partnerství. Pokud máte pocit naklonni
vyzádaná roli, uvedte o rychlou odezvu, takze já vám muze poskytnout dalsi
podrobnosti spolupráce.

Mejte vsak na pameti, ze se jedná o legitimní transakce a tesím se na vase
rychlé odpovedi na muj soukromý e-mail níze:

Pozdravy,
dngsn...@gmail.com
Barr. Xiaodong Su

Re: [PATCH v3 03/22] usb: ulpi: Support device discovery via device properties

[Stephen Boyd]

On Fri, Sep 2, 2016 at 7:09 AM, Heikki Krogerus
 wrote:
> Hi,
>
> On Wed, Aug 31, 2016 at 05:40:17PM -0700, Stephen Boyd wrote:
>> @@ -174,14 +219,37 @@ static int ulpi_register(struct device *dev, struct 
>> ulpi *ulpi)
>>   ulpi->id.product = ulpi_read(ulpi, ULPI_PRODUCT_ID_LOW);
>>   ulpi->id.product |= ulpi_read(ulpi, ULPI_PRODUCT_ID_HIGH) << 8;
>>
>> + return 0;
>> +}
>> +
>> +static int ulpi_register(struct device *dev, struct ulpi *ulpi)
>> +{
>> + int ret;
>> +
>>   ulpi->dev.parent = dev;
>>   ulpi->dev.bus = _bus;
>>   ulpi->dev.type = _dev_type;
>>   dev_set_name(>dev, "%s.ulpi", dev_name(dev));
>>
>> + if (IS_ENABLED(CONFIG_OF)) {
>
> I don't think you need to check that in this case.
>
>> + ret = ulpi_of_register(ulpi);
>> + if (ret)
>> + return ret;
>> + }
>> +
>>   ACPI_COMPANION_SET(>dev, ACPI_COMPANION(dev));
>
> ACPI_COMPANION_SET will overwrite the primary fwnode unconditionally,
> so just to play it safe, do this before you call ulpi_of_register().

Ok.

>
>> - request_module("ulpi:v%04xp%04x", ulpi->id.vendor, ulpi->id.product);
>> + ret = ulpi_read_id(ulpi);
>> + /*
>> +  * Ignore failure in case of DT node because the device may
>> +  * not be powered up yet but we can still match by compatible
>> +  */
>> + if (ret && !ulpi->dev.of_node)
>> + return ret;
>> +
>> + if (of_device_request_module(>dev))
>> + request_module("ulpi:v%04xp%04x", ulpi->id.vendor,
>> +ulpi->id.product);
>
> I don't think this works in all cases. If of_device_request_module()
> fails and we don't have the id.vendor/product set, we should not
> register the device. It also looks a bit messy.
>
> How about just using of_device_request_module() call as fallback in
> ulpi_read_id() and moving also request_module() call there:

Sure I'll fold it in and test. Should we "goto err" if we can't read
the scratch register though? I would think that's a "real" failure and
we shouldn't try to support DT in that case.

Re: [PATCH v3 03/22] usb: ulpi: Support device discovery via device properties

[Stephen Boyd]

On Fri, Sep 2, 2016 at 7:09 AM, Heikki Krogerus
 wrote:
> Hi,
>
> On Wed, Aug 31, 2016 at 05:40:17PM -0700, Stephen Boyd wrote:
>> @@ -174,14 +219,37 @@ static int ulpi_register(struct device *dev, struct 
>> ulpi *ulpi)
>>   ulpi->id.product = ulpi_read(ulpi, ULPI_PRODUCT_ID_LOW);
>>   ulpi->id.product |= ulpi_read(ulpi, ULPI_PRODUCT_ID_HIGH) << 8;
>>
>> + return 0;
>> +}
>> +
>> +static int ulpi_register(struct device *dev, struct ulpi *ulpi)
>> +{
>> + int ret;
>> +
>>   ulpi->dev.parent = dev;
>>   ulpi->dev.bus = _bus;
>>   ulpi->dev.type = _dev_type;
>>   dev_set_name(>dev, "%s.ulpi", dev_name(dev));
>>
>> + if (IS_ENABLED(CONFIG_OF)) {
>
> I don't think you need to check that in this case.
>
>> + ret = ulpi_of_register(ulpi);
>> + if (ret)
>> + return ret;
>> + }
>> +
>>   ACPI_COMPANION_SET(>dev, ACPI_COMPANION(dev));
>
> ACPI_COMPANION_SET will overwrite the primary fwnode unconditionally,
> so just to play it safe, do this before you call ulpi_of_register().

Ok.

>
>> - request_module("ulpi:v%04xp%04x", ulpi->id.vendor, ulpi->id.product);
>> + ret = ulpi_read_id(ulpi);
>> + /*
>> +  * Ignore failure in case of DT node because the device may
>> +  * not be powered up yet but we can still match by compatible
>> +  */
>> + if (ret && !ulpi->dev.of_node)
>> + return ret;
>> +
>> + if (of_device_request_module(>dev))
>> + request_module("ulpi:v%04xp%04x", ulpi->id.vendor,
>> +ulpi->id.product);
>
> I don't think this works in all cases. If of_device_request_module()
> fails and we don't have the id.vendor/product set, we should not
> register the device. It also looks a bit messy.
>
> How about just using of_device_request_module() call as fallback in
> ulpi_read_id() and moving also request_module() call there:

Sure I'll fold it in and test. Should we "goto err" if we can't read
the scratch register though? I would think that's a "real" failure and
we shouldn't try to support DT in that case.

Re: [PATCH v3 10/22] usb: chipidea: Consolidate extcon notifiers

[Stephen Boyd]

On Thu, Sep 1, 2016 at 8:17 PM, Peter Chen  wrote:
> On Wed, Aug 31, 2016 at 05:40:24PM -0700, Stephen Boyd wrote:
>>
>>
>>   if (cable->state)
>> - val |= OTGSC_ID;
>> + val &= ~OTGSC_ID; /* A device */
>>   else
>> - val &= ~OTGSC_ID;
>> + val |= OTGSC_ID; /* B device */
>>
>>   if (cable->enabled)
>>   val |= OTGSC_IDIE;
>
> /**
>  * struct ci_hdrc_cable - structure for external connector cable state 
> tracking
>  * @state: current state of the line
>
> You may change the name of variable "state" to "connected", per I
> understand, it has changed to the meaning of connected status for your patch.
>

Ok sure.

Re: [PATCH v3 10/22] usb: chipidea: Consolidate extcon notifiers

[Stephen Boyd]

On Thu, Sep 1, 2016 at 8:17 PM, Peter Chen  wrote:
> On Wed, Aug 31, 2016 at 05:40:24PM -0700, Stephen Boyd wrote:
>>
>>
>>   if (cable->state)
>> - val |= OTGSC_ID;
>> + val &= ~OTGSC_ID; /* A device */
>>   else
>> - val &= ~OTGSC_ID;
>> + val |= OTGSC_ID; /* B device */
>>
>>   if (cable->enabled)
>>   val |= OTGSC_IDIE;
>
> /**
>  * struct ci_hdrc_cable - structure for external connector cable state 
> tracking
>  * @state: current state of the line
>
> You may change the name of variable "state" to "connected", per I
> understand, it has changed to the meaning of connected status for your patch.
>

Ok sure.

[RFC/RFT][PATCH 4/4] cpufreq: schedutil: Add iowait boosting

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Modify the schedutil cpufreq governor to boost the CPU
frequency if the SCHED_CPUFREQ_IOWAIT flag is passed to
it via cpufreq_update_util().

If that happens, the frequency is set to the maximum during
the first update after receiving the SCHED_CPUFREQ_IOWAIT flag
and then the boost is reduced by half during each following update.

Signed-off-by: Rafael J. Wysocki 
---
 kernel/sched/cpufreq_schedutil.c |   53 ---
 1 file changed, 49 insertions(+), 4 deletions(-)

Index: linux-pm/kernel/sched/cpufreq_schedutil.c
===
--- linux-pm.orig/kernel/sched/cpufreq_schedutil.c
+++ linux-pm/kernel/sched/cpufreq_schedutil.c
@@ -47,11 +47,13 @@ struct sugov_cpu {
struct sugov_policy *sg_policy;
 
unsigned int cached_raw_freq;
+   unsigned long iowait_boost;
+   unsigned long iowait_boost_max;
+   u64 last_update;
 
/* The fields below are only needed when sharing a policy. */
unsigned long util;
unsigned long max;
-   u64 last_update;
unsigned int flags;
 };
 
@@ -153,6 +155,36 @@ static void sugov_get_util(unsigned long
*max = cfs_max;
 }
 
+static void sugov_set_iowait_boost(struct sugov_cpu *sg_cpu, u64 time,
+  unsigned int flags)
+{
+   if (flags & SCHED_CPUFREQ_IOWAIT) {
+   sg_cpu->iowait_boost = sg_cpu->iowait_boost_max;
+   } else if (sg_cpu->iowait_boost) {
+   s64 delta_ns = time - sg_cpu->last_update;
+
+   /* Clear iowait_boost if the CPU apprears to have been idle. */
+   if (delta_ns > TICK_NSEC)
+   sg_cpu->iowait_boost = 0;
+   }
+}
+
+static void sugov_iowait_boost(struct sugov_cpu *sg_cpu, unsigned long *util,
+  unsigned long *max)
+{
+   unsigned long boost_util = sg_cpu->iowait_boost;
+   unsigned long boost_max = sg_cpu->iowait_boost_max;
+
+   if (!boost_util)
+   return;
+
+   if (*util * boost_max < *max * boost_util) {
+   *util = boost_util;
+   *max = boost_max;
+   }
+   sg_cpu->iowait_boost >>= 1;
+}
+
 static void sugov_update_single(struct update_util_data *hook, u64 time,
unsigned int flags)
 {
@@ -162,6 +194,9 @@ static void sugov_update_single(struct u
unsigned long util, max;
unsigned int next_f;
 
+   sugov_set_iowait_boost(sg_cpu, time, flags);
+   sg_cpu->last_update = time;
+
if (!sugov_should_update_freq(sg_policy, time))
return;
 
@@ -169,6 +204,7 @@ static void sugov_update_single(struct u
next_f = policy->cpuinfo.max_freq;
} else {
sugov_get_util(, );
+   sugov_iowait_boost(sg_cpu, , );
next_f = get_next_freq(sg_cpu, util, max);
}
sugov_update_commit(sg_policy, time, next_f);
@@ -187,6 +223,8 @@ static unsigned int sugov_next_freq_shar
if (flags & SCHED_CPUFREQ_RT_DL)
return max_f;
 
+   sugov_iowait_boost(sg_cpu, , );
+
for_each_cpu(j, policy->cpus) {
struct sugov_cpu *j_sg_cpu;
unsigned long j_util, j_max;
@@ -201,12 +239,13 @@ static unsigned int sugov_next_freq_shar
 * frequency update and the time elapsed between the last update
 * of the CPU utilization and the last frequency update is long
 * enough, don't take the CPU into account as it probably is
-* idle now.
+* idle now (and clear iowait_boost for it).
 */
delta_ns = last_freq_update_time - j_sg_cpu->last_update;
-   if (delta_ns > TICK_NSEC)
+   if (delta_ns > TICK_NSEC) {
+   j_sg_cpu->iowait_boost = 0;
continue;
-
+   }
if (j_sg_cpu->flags & SCHED_CPUFREQ_RT_DL)
return max_f;
 
@@ -216,6 +255,8 @@ static unsigned int sugov_next_freq_shar
util = j_util;
max = j_max;
}
+
+   sugov_iowait_boost(j_sg_cpu, , );
}
 
return get_next_freq(sg_cpu, util, max);
@@ -236,6 +277,8 @@ static void sugov_update_shared(struct u
sg_cpu->util = util;
sg_cpu->max = max;
sg_cpu->flags = flags;
+
+   sugov_set_iowait_boost(sg_cpu, time, flags);
sg_cpu->last_update = time;
 
if (sugov_should_update_freq(sg_policy, time)) {
@@ -468,6 +511,8 @@ static int sugov_start(struct cpufreq_po
sg_cpu->flags = SCHED_CPUFREQ_RT;
sg_cpu->last_update = 0;
sg_cpu->cached_raw_freq = 0;
+   sg_cpu->iowait_boost = 0;
+ 

[RFC/RFT][PATCH 2/4] cpufreq: intel_pstate: Change P-state selection algorithm for Core

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

The PID-base P-state selection algorithm used by intel_pstate for
Core processors is based on very weak foundations.  Namely, its
decisions are mostly based on the values of the APERF and MPERF
feedback registers and it only estimates the actual utilization to
check if it is not extremely low (in order to avoid getting stuck
in the highest P-state in that case).

Since it generally causes the CPU P-state to ramp up quickly, it
leads to satisfactory performance, but the metric used by it is only
really valid when the CPU changes P-states by itself (ie. in the turbo
range) and if the P-state value set by the driver is treated by the
CPU as the upper limit on turbo P-states selected by it.

As a result, the only case when P-states are reduced by that
algorithm is when the CPU has just come out of idle, but in that
particular case it would have been better to bump up the P-state
instead.  That causes some benchmarks to behave erratically and
attempts to improve the situation lead to excessive energy
consumption, because they make the CPU stay in very high P-states
almost all the time.

Consequently, the only viable way to fix that is to replace the
erroneous algorithm entirely with a new one.

To that end, notice that setting the P-state proportional to the
actual CPU utilization (measured with the help of MPERF and TSC)
generally leads to reasonable behavior, but it does not reflect
the "performance boosting" nature of the current P-state
selection algorithm.  It may be made more similar to that
algorithm, though, by adding iowait boosting to it.

Specifically, if the P-state is bumped up to the maximum after
receiving the SCHED_CPUFREQ_IOWAIT flag via cpufreq_update_util(),
it will allow tasks that were previously waiting on I/O to get the
full capacity of the CPU when they are ready to process data again
and that should lead to the desired performance increase overall
without sacrificing too much energy.

However, the utilization-based method of target P-state selection
may cause the resultant target P-state to oscillate which generally
leads to excessive consumption of energy, so apply an Infinite
Impulse Response filter on top of it to dampen those osciallations
and make it more energy-efficient (thanks to Doug Smythies for this
idea).

Use the approach as described in intel_pstate for Core processors.

Original-by: Srinivas Pandruvada 
Suggested-by: Doug Smythies 
Signed-off-by: Rafael J. Wysocki 
---

This includes an IIR filter on top of the load-based P-state selection,
but the filter is applied to the non-boosted case only (otherwise it
defeats the point of the boost) and I used a slightly different raw gain
value.

Thanks,
Rafael

---
 drivers/cpufreq/intel_pstate.c |   81 +++--
 1 file changed, 79 insertions(+), 2 deletions(-)

Index: linux-pm/drivers/cpufreq/intel_pstate.c
===
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -98,6 +98,7 @@ static inline u64 div_ext_fp(u64 x, u64
  * @tsc:   Difference of time stamp counter between last and
  * current sample
  * @time:  Current time from scheduler
+ * @target:Target P-state
  *
  * This structure is used in the cpudata structure to store performance sample
  * data for choosing next P State.
@@ -109,6 +110,7 @@ struct sample {
u64 mperf;
u64 tsc;
u64 time;
+   int target;
 };
 
 /**
@@ -181,6 +183,8 @@ struct _pid {
  * @cpu:   CPU number for this instance data
  * @update_util:   CPUFreq utility callback information
  * @update_util_set:   CPUFreq utility callback is set
+ * @iowait_boost:  iowait-related boost fraction
+ * @last_update:   Time of the last update.
  * @pstate:Stores P state limits for this CPU
  * @vid:   Stores VID limits for this CPU
  * @pid:   Stores PID parameters for this CPU
@@ -206,6 +210,7 @@ struct cpudata {
struct vid_data vid;
struct _pid pid;
 
+   u64 last_update;
u64 last_sample_time;
u64 prev_aperf;
u64 prev_mperf;
@@ -216,6 +221,7 @@ struct cpudata {
struct acpi_processor_performance acpi_perf_data;
bool valid_pss_table;
 #endif
+   unsigned int iowait_boost;
 };
 
 static struct cpudata **all_cpu_data;
@@ -229,6 +235,7 @@ static struct cpudata **all_cpu_data;
  * @p_gain_pct:PID proportional gain
  * @i_gain_pct:PID integral gain
  * @d_gain_pct:PID derivative gain
+ * @boost_iowait:  Whether or not to use iowait boosting.
  *
  * Stores per CPU model static PID configuration data.
  */
@@ -240,6 +247,7 @@ struct pstate_adjust_policy {
int p_gain_pct;

[RFC/RFT][PATCH 4/4] cpufreq: schedutil: Add iowait boosting

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Modify the schedutil cpufreq governor to boost the CPU
frequency if the SCHED_CPUFREQ_IOWAIT flag is passed to
it via cpufreq_update_util().

If that happens, the frequency is set to the maximum during
the first update after receiving the SCHED_CPUFREQ_IOWAIT flag
and then the boost is reduced by half during each following update.

Signed-off-by: Rafael J. Wysocki 
---
 kernel/sched/cpufreq_schedutil.c |   53 ---
 1 file changed, 49 insertions(+), 4 deletions(-)

Index: linux-pm/kernel/sched/cpufreq_schedutil.c
===
--- linux-pm.orig/kernel/sched/cpufreq_schedutil.c
+++ linux-pm/kernel/sched/cpufreq_schedutil.c
@@ -47,11 +47,13 @@ struct sugov_cpu {
struct sugov_policy *sg_policy;
 
unsigned int cached_raw_freq;
+   unsigned long iowait_boost;
+   unsigned long iowait_boost_max;
+   u64 last_update;
 
/* The fields below are only needed when sharing a policy. */
unsigned long util;
unsigned long max;
-   u64 last_update;
unsigned int flags;
 };
 
@@ -153,6 +155,36 @@ static void sugov_get_util(unsigned long
*max = cfs_max;
 }
 
+static void sugov_set_iowait_boost(struct sugov_cpu *sg_cpu, u64 time,
+  unsigned int flags)
+{
+   if (flags & SCHED_CPUFREQ_IOWAIT) {
+   sg_cpu->iowait_boost = sg_cpu->iowait_boost_max;
+   } else if (sg_cpu->iowait_boost) {
+   s64 delta_ns = time - sg_cpu->last_update;
+
+   /* Clear iowait_boost if the CPU apprears to have been idle. */
+   if (delta_ns > TICK_NSEC)
+   sg_cpu->iowait_boost = 0;
+   }
+}
+
+static void sugov_iowait_boost(struct sugov_cpu *sg_cpu, unsigned long *util,
+  unsigned long *max)
+{
+   unsigned long boost_util = sg_cpu->iowait_boost;
+   unsigned long boost_max = sg_cpu->iowait_boost_max;
+
+   if (!boost_util)
+   return;
+
+   if (*util * boost_max < *max * boost_util) {
+   *util = boost_util;
+   *max = boost_max;
+   }
+   sg_cpu->iowait_boost >>= 1;
+}
+
 static void sugov_update_single(struct update_util_data *hook, u64 time,
unsigned int flags)
 {
@@ -162,6 +194,9 @@ static void sugov_update_single(struct u
unsigned long util, max;
unsigned int next_f;
 
+   sugov_set_iowait_boost(sg_cpu, time, flags);
+   sg_cpu->last_update = time;
+
if (!sugov_should_update_freq(sg_policy, time))
return;
 
@@ -169,6 +204,7 @@ static void sugov_update_single(struct u
next_f = policy->cpuinfo.max_freq;
} else {
sugov_get_util(, );
+   sugov_iowait_boost(sg_cpu, , );
next_f = get_next_freq(sg_cpu, util, max);
}
sugov_update_commit(sg_policy, time, next_f);
@@ -187,6 +223,8 @@ static unsigned int sugov_next_freq_shar
if (flags & SCHED_CPUFREQ_RT_DL)
return max_f;
 
+   sugov_iowait_boost(sg_cpu, , );
+
for_each_cpu(j, policy->cpus) {
struct sugov_cpu *j_sg_cpu;
unsigned long j_util, j_max;
@@ -201,12 +239,13 @@ static unsigned int sugov_next_freq_shar
 * frequency update and the time elapsed between the last update
 * of the CPU utilization and the last frequency update is long
 * enough, don't take the CPU into account as it probably is
-* idle now.
+* idle now (and clear iowait_boost for it).
 */
delta_ns = last_freq_update_time - j_sg_cpu->last_update;
-   if (delta_ns > TICK_NSEC)
+   if (delta_ns > TICK_NSEC) {
+   j_sg_cpu->iowait_boost = 0;
continue;
-
+   }
if (j_sg_cpu->flags & SCHED_CPUFREQ_RT_DL)
return max_f;
 
@@ -216,6 +255,8 @@ static unsigned int sugov_next_freq_shar
util = j_util;
max = j_max;
}
+
+   sugov_iowait_boost(j_sg_cpu, , );
}
 
return get_next_freq(sg_cpu, util, max);
@@ -236,6 +277,8 @@ static void sugov_update_shared(struct u
sg_cpu->util = util;
sg_cpu->max = max;
sg_cpu->flags = flags;
+
+   sugov_set_iowait_boost(sg_cpu, time, flags);
sg_cpu->last_update = time;
 
if (sugov_should_update_freq(sg_policy, time)) {
@@ -468,6 +511,8 @@ static int sugov_start(struct cpufreq_po
sg_cpu->flags = SCHED_CPUFREQ_RT;
sg_cpu->last_update = 0;
sg_cpu->cached_raw_freq = 0;
+   sg_cpu->iowait_boost = 0;
+   sg_cpu->iowait_boost_max = 

[RFC/RFT][PATCH 2/4] cpufreq: intel_pstate: Change P-state selection algorithm for Core

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

The PID-base P-state selection algorithm used by intel_pstate for
Core processors is based on very weak foundations.  Namely, its
decisions are mostly based on the values of the APERF and MPERF
feedback registers and it only estimates the actual utilization to
check if it is not extremely low (in order to avoid getting stuck
in the highest P-state in that case).

Since it generally causes the CPU P-state to ramp up quickly, it
leads to satisfactory performance, but the metric used by it is only
really valid when the CPU changes P-states by itself (ie. in the turbo
range) and if the P-state value set by the driver is treated by the
CPU as the upper limit on turbo P-states selected by it.

As a result, the only case when P-states are reduced by that
algorithm is when the CPU has just come out of idle, but in that
particular case it would have been better to bump up the P-state
instead.  That causes some benchmarks to behave erratically and
attempts to improve the situation lead to excessive energy
consumption, because they make the CPU stay in very high P-states
almost all the time.

Consequently, the only viable way to fix that is to replace the
erroneous algorithm entirely with a new one.

To that end, notice that setting the P-state proportional to the
actual CPU utilization (measured with the help of MPERF and TSC)
generally leads to reasonable behavior, but it does not reflect
the "performance boosting" nature of the current P-state
selection algorithm.  It may be made more similar to that
algorithm, though, by adding iowait boosting to it.

Specifically, if the P-state is bumped up to the maximum after
receiving the SCHED_CPUFREQ_IOWAIT flag via cpufreq_update_util(),
it will allow tasks that were previously waiting on I/O to get the
full capacity of the CPU when they are ready to process data again
and that should lead to the desired performance increase overall
without sacrificing too much energy.

However, the utilization-based method of target P-state selection
may cause the resultant target P-state to oscillate which generally
leads to excessive consumption of energy, so apply an Infinite
Impulse Response filter on top of it to dampen those osciallations
and make it more energy-efficient (thanks to Doug Smythies for this
idea).

Use the approach as described in intel_pstate for Core processors.

Original-by: Srinivas Pandruvada 
Suggested-by: Doug Smythies 
Signed-off-by: Rafael J. Wysocki 
---

This includes an IIR filter on top of the load-based P-state selection,
but the filter is applied to the non-boosted case only (otherwise it
defeats the point of the boost) and I used a slightly different raw gain
value.

Thanks,
Rafael

---
 drivers/cpufreq/intel_pstate.c |   81 +++--
 1 file changed, 79 insertions(+), 2 deletions(-)

Index: linux-pm/drivers/cpufreq/intel_pstate.c
===
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -98,6 +98,7 @@ static inline u64 div_ext_fp(u64 x, u64
  * @tsc:   Difference of time stamp counter between last and
  * current sample
  * @time:  Current time from scheduler
+ * @target:Target P-state
  *
  * This structure is used in the cpudata structure to store performance sample
  * data for choosing next P State.
@@ -109,6 +110,7 @@ struct sample {
u64 mperf;
u64 tsc;
u64 time;
+   int target;
 };
 
 /**
@@ -181,6 +183,8 @@ struct _pid {
  * @cpu:   CPU number for this instance data
  * @update_util:   CPUFreq utility callback information
  * @update_util_set:   CPUFreq utility callback is set
+ * @iowait_boost:  iowait-related boost fraction
+ * @last_update:   Time of the last update.
  * @pstate:Stores P state limits for this CPU
  * @vid:   Stores VID limits for this CPU
  * @pid:   Stores PID parameters for this CPU
@@ -206,6 +210,7 @@ struct cpudata {
struct vid_data vid;
struct _pid pid;
 
+   u64 last_update;
u64 last_sample_time;
u64 prev_aperf;
u64 prev_mperf;
@@ -216,6 +221,7 @@ struct cpudata {
struct acpi_processor_performance acpi_perf_data;
bool valid_pss_table;
 #endif
+   unsigned int iowait_boost;
 };
 
 static struct cpudata **all_cpu_data;
@@ -229,6 +235,7 @@ static struct cpudata **all_cpu_data;
  * @p_gain_pct:PID proportional gain
  * @i_gain_pct:PID integral gain
  * @d_gain_pct:PID derivative gain
+ * @boost_iowait:  Whether or not to use iowait boosting.
  *
  * Stores per CPU model static PID configuration data.
  */
@@ -240,6 +247,7 @@ struct pstate_adjust_policy {
int p_gain_pct;
int d_gain_pct;
int i_gain_pct;
+   bool boost_iowait;
 };
 
 /**
@@ -277,6 +285,7 @@ struct 

[RFC/RFT][PATCH 1/4] cpufreq / sched: SCHED_CPUFREQ_IOWAIT flag to indicate iowait condition

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Testing indicates that it is possible to improve performace
significantly without increasing energy consumption too much by
teaching cpufreq governors to bump up the CPU performance level if
the in_iowait flag is set for the task in enqueue_task_fair().

For this purpose, define a new cpufreq_update_util() flag
SCHED_CPUFREQ_IOWAIT and modify enqueue_task_fair() to pass that
flag to cpufreq_update_util() in the in_iowait case.  That generally
requires cpufreq_update_util() to be called directly from there,
because update_load_avg() may not be invoked in that case.

Signed-off-by: Rafael J. Wysocki 
---
 include/linux/sched.h |1 +
 kernel/sched/fair.c   |8 
 2 files changed, 9 insertions(+)

Index: linux-pm/kernel/sched/fair.c
===
--- linux-pm.orig/kernel/sched/fair.c
+++ linux-pm/kernel/sched/fair.c
@@ -4500,6 +4500,14 @@ enqueue_task_fair(struct rq *rq, struct
struct cfs_rq *cfs_rq;
struct sched_entity *se = >se;
 
+   /*
+* If in_iowait is set, the code below may not trigger any cpufreq
+* utilization updates, so do it here explicitly with the IOWAIT flag
+* passed.
+*/
+   if (p->in_iowait)
+   cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_IOWAIT);
+
for_each_sched_entity(se) {
if (se->on_rq)
break;
Index: linux-pm/include/linux/sched.h
===
--- linux-pm.orig/include/linux/sched.h
+++ linux-pm/include/linux/sched.h
@@ -3471,6 +3471,7 @@ static inline unsigned long rlimit_max(u
 
 #define SCHED_CPUFREQ_RT   (1U << 0)
 #define SCHED_CPUFREQ_DL   (1U << 1)
+#define SCHED_CPUFREQ_IOWAIT   (1U << 2)
 
 #define SCHED_CPUFREQ_RT_DL(SCHED_CPUFREQ_RT | SCHED_CPUFREQ_DL)
 

[RFC/RFT][PATCH 1/4] cpufreq / sched: SCHED_CPUFREQ_IOWAIT flag to indicate iowait condition

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Testing indicates that it is possible to improve performace
significantly without increasing energy consumption too much by
teaching cpufreq governors to bump up the CPU performance level if
the in_iowait flag is set for the task in enqueue_task_fair().

For this purpose, define a new cpufreq_update_util() flag
SCHED_CPUFREQ_IOWAIT and modify enqueue_task_fair() to pass that
flag to cpufreq_update_util() in the in_iowait case.  That generally
requires cpufreq_update_util() to be called directly from there,
because update_load_avg() may not be invoked in that case.

Signed-off-by: Rafael J. Wysocki 
---
 include/linux/sched.h |1 +
 kernel/sched/fair.c   |8 
 2 files changed, 9 insertions(+)

Index: linux-pm/kernel/sched/fair.c
===
--- linux-pm.orig/kernel/sched/fair.c
+++ linux-pm/kernel/sched/fair.c
@@ -4500,6 +4500,14 @@ enqueue_task_fair(struct rq *rq, struct
struct cfs_rq *cfs_rq;
struct sched_entity *se = >se;
 
+   /*
+* If in_iowait is set, the code below may not trigger any cpufreq
+* utilization updates, so do it here explicitly with the IOWAIT flag
+* passed.
+*/
+   if (p->in_iowait)
+   cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_IOWAIT);
+
for_each_sched_entity(se) {
if (se->on_rq)
break;
Index: linux-pm/include/linux/sched.h
===
--- linux-pm.orig/include/linux/sched.h
+++ linux-pm/include/linux/sched.h
@@ -3471,6 +3471,7 @@ static inline unsigned long rlimit_max(u
 
 #define SCHED_CPUFREQ_RT   (1U << 0)
 #define SCHED_CPUFREQ_DL   (1U << 1)
+#define SCHED_CPUFREQ_IOWAIT   (1U << 2)
 
 #define SCHED_CPUFREQ_RT_DL(SCHED_CPUFREQ_RT | SCHED_CPUFREQ_DL)
 

[RFC/RFT][PATCH 0/4] cpufreq / sched: iowait boost in intel_pstate and schedutil

[Rafael J. Wysocki]

Hi Everyone,

This is a new version of the "iowait boost" series I posted a few weeks
ago.  Since the first two patches from that series have been reworked and
are in linux-next now, I've rebased this series on top of my linux-next
branch.

In addition to that I took the Doug's feedback into account in the
intel_pstate patches [2-3/4].

Please let me know what you think and if you can run some benchmarks you
care about and see if the changes make any difference (this way or another),
please do that and let me know what you've found.

Thanks,
Rafael

[RFC/RFT][PATCH 3/4] cpufreq: intel_pstate: Use average P-state in get_target_pstate_default()

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Adjust the next P-state formula in get_target_pstate_default()
(in the filtered case) to use the average P-state as given by
the APERF and MPERF feedback registers instead of the exact
P-state requested previously, as that request might not be
granted.

Suggested-by: Doug Smythies 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/cpufreq/intel_pstate.c |   18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

Index: linux-pm/drivers/cpufreq/intel_pstate.c
===
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -98,7 +98,6 @@ static inline u64 div_ext_fp(u64 x, u64
  * @tsc:   Difference of time stamp counter between last and
  * current sample
  * @time:  Current time from scheduler
- * @target:Target P-state
  *
  * This structure is used in the cpudata structure to store performance sample
  * data for choosing next P State.
@@ -110,7 +109,6 @@ struct sample {
u64 mperf;
u64 tsc;
u64 time;
-   int target;
 };
 
 /**
@@ -1149,7 +1147,6 @@ static void intel_pstate_set_min_pstate(
 
trace_cpu_frequency(pstate * cpu->pstate.scaling, cpu->cpu);
cpu->pstate.current_pstate = pstate;
-   cpu->sample.target = pstate;
/*
 * Generally, there is no guarantee that this code will always run on
 * the CPU being updated, so force the register update to run on the
@@ -1305,8 +1302,8 @@ static inline int32_t get_target_pstate_
 {
struct sample *sample = >sample;
int32_t busy_frac, boost;
-   int pstate, max_perf, min_perf;
int64_t target;
+   int pstate;
 
pstate = limits->no_turbo || limits->turbo_disabled ?
cpu->pstate.max_pstate : cpu->pstate.turbo_pstate;
@@ -1341,17 +1338,20 @@ static inline int32_t get_target_pstate_
 * Take the raw gain as 1/8 and compute the effective gain as
 *
 *  iir_gain = 1/8 * delta_t / sampling_interval
+*
+* Moreover, since the output is a request that may or may not
+* be granted (depending on what the other CPUs are doing, for
+* example), instead of using the output value obtained
+* previously in the computation, use the effective average
+* P-state since the last pass as given by APERF and MPERF.
 */
iir_gain = div_fp(sample->time - cpu->last_sample_time,
  pid_params.sample_rate_ns << 3);
if (iir_gain < int_tofp(1))
-   target = sample->target * (int_tofp(1) - iir_gain) +
+   target = get_avg_pstate(cpu) * (int_tofp(1) - iir_gain) 
+
mul_fp(target, iir_gain);
}
-   intel_pstate_get_min_max(cpu, _perf, _perf);
-   target = clamp_val(target, int_tofp(min_perf), int_tofp(max_perf));
-   sample->target = fp_toint(target + (1 << (FRAC_BITS-1)));
-   return sample->target;
+   return fp_toint(target + (1 << (FRAC_BITS-1)));
 }
 
 static inline void intel_pstate_update_pstate(struct cpudata *cpu, int pstate)

[RFC/RFT][PATCH 0/4] cpufreq / sched: iowait boost in intel_pstate and schedutil

[Rafael J. Wysocki]

Hi Everyone,

This is a new version of the "iowait boost" series I posted a few weeks
ago.  Since the first two patches from that series have been reworked and
are in linux-next now, I've rebased this series on top of my linux-next
branch.

In addition to that I took the Doug's feedback into account in the
intel_pstate patches [2-3/4].

Please let me know what you think and if you can run some benchmarks you
care about and see if the changes make any difference (this way or another),
please do that and let me know what you've found.

Thanks,
Rafael

[RFC/RFT][PATCH 3/4] cpufreq: intel_pstate: Use average P-state in get_target_pstate_default()

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Adjust the next P-state formula in get_target_pstate_default()
(in the filtered case) to use the average P-state as given by
the APERF and MPERF feedback registers instead of the exact
P-state requested previously, as that request might not be
granted.

Suggested-by: Doug Smythies 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/cpufreq/intel_pstate.c |   18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

Index: linux-pm/drivers/cpufreq/intel_pstate.c
===
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -98,7 +98,6 @@ static inline u64 div_ext_fp(u64 x, u64
  * @tsc:   Difference of time stamp counter between last and
  * current sample
  * @time:  Current time from scheduler
- * @target:Target P-state
  *
  * This structure is used in the cpudata structure to store performance sample
  * data for choosing next P State.
@@ -110,7 +109,6 @@ struct sample {
u64 mperf;
u64 tsc;
u64 time;
-   int target;
 };
 
 /**
@@ -1149,7 +1147,6 @@ static void intel_pstate_set_min_pstate(
 
trace_cpu_frequency(pstate * cpu->pstate.scaling, cpu->cpu);
cpu->pstate.current_pstate = pstate;
-   cpu->sample.target = pstate;
/*
 * Generally, there is no guarantee that this code will always run on
 * the CPU being updated, so force the register update to run on the
@@ -1305,8 +1302,8 @@ static inline int32_t get_target_pstate_
 {
struct sample *sample = >sample;
int32_t busy_frac, boost;
-   int pstate, max_perf, min_perf;
int64_t target;
+   int pstate;
 
pstate = limits->no_turbo || limits->turbo_disabled ?
cpu->pstate.max_pstate : cpu->pstate.turbo_pstate;
@@ -1341,17 +1338,20 @@ static inline int32_t get_target_pstate_
 * Take the raw gain as 1/8 and compute the effective gain as
 *
 *  iir_gain = 1/8 * delta_t / sampling_interval
+*
+* Moreover, since the output is a request that may or may not
+* be granted (depending on what the other CPUs are doing, for
+* example), instead of using the output value obtained
+* previously in the computation, use the effective average
+* P-state since the last pass as given by APERF and MPERF.
 */
iir_gain = div_fp(sample->time - cpu->last_sample_time,
  pid_params.sample_rate_ns << 3);
if (iir_gain < int_tofp(1))
-   target = sample->target * (int_tofp(1) - iir_gain) +
+   target = get_avg_pstate(cpu) * (int_tofp(1) - iir_gain) 
+
mul_fp(target, iir_gain);
}
-   intel_pstate_get_min_max(cpu, _perf, _perf);
-   target = clamp_val(target, int_tofp(min_perf), int_tofp(max_perf));
-   sample->target = fp_toint(target + (1 << (FRAC_BITS-1)));
-   return sample->target;
+   return fp_toint(target + (1 << (FRAC_BITS-1)));
 }
 
 static inline void intel_pstate_update_pstate(struct cpudata *cpu, int pstate)

[PATCH v2 0/3] clk: xgene: Add PMD clock support

[Hoan Tran]

Add X-Gene PMD clock support.

PMD clock is implemented for a single register field.
  Output rate = parent_rate * (denominator - scale) / denominator
with
  - denominator = bitmask of register field + 1
  - scale = value of register field

For example, for bitmask is 0x7, denominator will be 8 and scale
will be computed and programmed accordingly.

v2
 * Imply clock shift and width by the compatible string as Rob's comments

v1
 * Initial

Hoan Tran (3):
  Documentation: dtb: xgene: Add PMD clock binding
  clk: xgene: Add PMD clock
  arm64: dts: xgene: Add DT node for APM X-Gene 2 CPU clocks

 Documentation/devicetree/bindings/clock/xgene.txt |  18 ++
 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi|  56 ++
 drivers/clk/clk-xgene.c   | 221 ++
 3 files changed, 295 insertions(+)

-- 
1.9.1

[PATCH v2 2/3] clk: xgene: Add PMD clock

[Hoan Tran]

Add X-Gene PMD clock support.

PMD clock is implemented for a single register field.
  Output rate = parent_rate * (denominator - scale) / denominator
with
  - denominator = bitmask of register field + 1
  - scale = values of register field

For example, for bitmask is 0x7, denominator will be 8 and scale
will be computed and programmed accordingly.

Signed-off-by: Hoan Tran 
---
 drivers/clk/clk-xgene.c | 221 
 1 file changed, 221 insertions(+)

diff --git a/drivers/clk/clk-xgene.c b/drivers/clk/clk-xgene.c
index 3433132..5daddf5 100644
--- a/drivers/clk/clk-xgene.c
+++ b/drivers/clk/clk-xgene.c
@@ -217,6 +217,226 @@ static void xgene_pcppllclk_init(struct device_node *np)
xgene_pllclk_init(np, PLL_TYPE_PCP);
 }
 
+/**
+ * struct xgene_clk_pmd - PMD clock
+ *
+ * @hw:handle between common and hardware-specific interfaces
+ * @reg:   register containing the fractional scale multiplier (scaler)
+ * @shift: shift to the unit bit field
+ * @denom: 1/denominator unit
+ * @lock:  register lock
+ * Flags:
+ * XGENE_CLK_PMD_SCALE_INVERTED - By default the scaler is the value read
+ * from the register plus one. For example,
+ * 0 for (0 + 1) / denom,
+ * 1 for (1 + 1) / denom and etc.
+ * If this flag is set, it is
+ * 0 for (denom - 0) / denom,
+ * 1 for (denom - 1) / denom and etc.
+ *
+ */
+struct xgene_clk_pmd {
+   struct clk_hw   hw;
+   void __iomem*reg;
+   u8  shift;
+   u32 mask;
+   u64 denom;
+   u32 flags;
+   spinlock_t  *lock;
+};
+
+#define to_xgene_clk_pmd(_hw) container_of(_hw, struct xgene_clk_pmd, hw)
+
+#define XGENE_CLK_PMD_SCALE_INVERTED   BIT(0)
+#define XGENE_CLK_PMD_SHIFT8
+#define XGENE_CLK_PMD_WIDTH3
+
+static unsigned long xgene_clk_pmd_recalc_rate(struct clk_hw *hw,
+  unsigned long parent_rate)
+{
+   struct xgene_clk_pmd *fd = to_xgene_clk_pmd(hw);
+   unsigned long flags = 0;
+   u64 ret, scale;
+   u32 val;
+
+   if (fd->lock)
+   spin_lock_irqsave(fd->lock, flags);
+   else
+   __acquire(fd->lock);
+
+   val = clk_readl(fd->reg);
+
+   if (fd->lock)
+   spin_unlock_irqrestore(fd->lock, flags);
+   else
+   __release(fd->lock);
+
+   ret = (u64)parent_rate;
+
+   scale = (val & fd->mask) >> fd->shift;
+   if (fd->flags & XGENE_CLK_PMD_SCALE_INVERTED)
+   scale = fd->denom - scale;
+   else
+   scale++;
+
+   /* freq = parent_rate * scaler / denom */
+   do_div(ret, fd->denom);
+   ret *= scale;
+   if (ret == 0)
+   ret = (u64)parent_rate;
+
+   return ret;
+}
+
+static long xgene_clk_pmd_round_rate(struct clk_hw *hw, unsigned long rate,
+unsigned long *parent_rate)
+{
+   struct xgene_clk_pmd *fd = to_xgene_clk_pmd(hw);
+   u64 ret, scale;
+
+   if (!rate || rate >= *parent_rate)
+   return *parent_rate;
+
+   /* freq = parent_rate * scaler / denom */
+   ret = rate * fd->denom;
+   scale = DIV_ROUND_UP_ULL(ret, *parent_rate);
+
+   ret = (u64)*parent_rate * scale;
+   do_div(ret, fd->denom);
+
+   return ret;
+}
+
+static int xgene_clk_pmd_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+   struct xgene_clk_pmd *fd = to_xgene_clk_pmd(hw);
+   unsigned long flags = 0;
+   u64 scale, ret;
+   u32 val;
+
+   /*
+* Compute the scaler:
+*
+* freq = parent_rate * scaler / denom, or
+* scaler = freq * denom / parent_rate
+*/
+   ret = rate * fd->denom;
+   scale = DIV_ROUND_UP_ULL(ret, (u64)parent_rate);
+
+   /* Check if inverted */
+   if (fd->flags & XGENE_CLK_PMD_SCALE_INVERTED)
+   scale = fd->denom - scale;
+   else
+   scale--;
+
+   if (fd->lock)
+   spin_lock_irqsave(fd->lock, flags);
+   else
+   __acquire(fd->lock);
+
+   val = clk_readl(fd->reg);
+   val &= ~fd->mask;
+   val |= (scale << fd->shift);
+   clk_writel(val, fd->reg);
+
+   if (fd->lock)
+   spin_unlock_irqrestore(fd->lock, flags);
+   else
+   __release(fd->lock);
+
+   return 0;
+}
+
+static const struct clk_ops xgene_clk_pmd_ops = {
+   .recalc_rate = xgene_clk_pmd_recalc_rate,
+   .round_rate = xgene_clk_pmd_round_rate,
+   .set_rate = xgene_clk_pmd_set_rate,
+};
+
+static struct clk *
+xgene_register_clk_pmd(struct device *dev,
+  const char *name, const char *parent_name,
+  unsigned long flags, void __iomem *reg, u8 shift,
+  u8 width, u64 

[PATCH v2 0/3] clk: xgene: Add PMD clock support

[Hoan Tran]

Add X-Gene PMD clock support.

PMD clock is implemented for a single register field.
  Output rate = parent_rate * (denominator - scale) / denominator
with
  - denominator = bitmask of register field + 1
  - scale = value of register field

For example, for bitmask is 0x7, denominator will be 8 and scale
will be computed and programmed accordingly.

v2
 * Imply clock shift and width by the compatible string as Rob's comments

v1
 * Initial

Hoan Tran (3):
  Documentation: dtb: xgene: Add PMD clock binding
  clk: xgene: Add PMD clock
  arm64: dts: xgene: Add DT node for APM X-Gene 2 CPU clocks

 Documentation/devicetree/bindings/clock/xgene.txt |  18 ++
 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi|  56 ++
 drivers/clk/clk-xgene.c   | 221 ++
 3 files changed, 295 insertions(+)

-- 
1.9.1

[PATCH v2 2/3] clk: xgene: Add PMD clock

[Hoan Tran]

Add X-Gene PMD clock support.

PMD clock is implemented for a single register field.
  Output rate = parent_rate * (denominator - scale) / denominator
with
  - denominator = bitmask of register field + 1
  - scale = values of register field

For example, for bitmask is 0x7, denominator will be 8 and scale
will be computed and programmed accordingly.

Signed-off-by: Hoan Tran 
---
 drivers/clk/clk-xgene.c | 221 
 1 file changed, 221 insertions(+)

diff --git a/drivers/clk/clk-xgene.c b/drivers/clk/clk-xgene.c
index 3433132..5daddf5 100644
--- a/drivers/clk/clk-xgene.c
+++ b/drivers/clk/clk-xgene.c
@@ -217,6 +217,226 @@ static void xgene_pcppllclk_init(struct device_node *np)
xgene_pllclk_init(np, PLL_TYPE_PCP);
 }
 
+/**
+ * struct xgene_clk_pmd - PMD clock
+ *
+ * @hw:handle between common and hardware-specific interfaces
+ * @reg:   register containing the fractional scale multiplier (scaler)
+ * @shift: shift to the unit bit field
+ * @denom: 1/denominator unit
+ * @lock:  register lock
+ * Flags:
+ * XGENE_CLK_PMD_SCALE_INVERTED - By default the scaler is the value read
+ * from the register plus one. For example,
+ * 0 for (0 + 1) / denom,
+ * 1 for (1 + 1) / denom and etc.
+ * If this flag is set, it is
+ * 0 for (denom - 0) / denom,
+ * 1 for (denom - 1) / denom and etc.
+ *
+ */
+struct xgene_clk_pmd {
+   struct clk_hw   hw;
+   void __iomem*reg;
+   u8  shift;
+   u32 mask;
+   u64 denom;
+   u32 flags;
+   spinlock_t  *lock;
+};
+
+#define to_xgene_clk_pmd(_hw) container_of(_hw, struct xgene_clk_pmd, hw)
+
+#define XGENE_CLK_PMD_SCALE_INVERTED   BIT(0)
+#define XGENE_CLK_PMD_SHIFT8
+#define XGENE_CLK_PMD_WIDTH3
+
+static unsigned long xgene_clk_pmd_recalc_rate(struct clk_hw *hw,
+  unsigned long parent_rate)
+{
+   struct xgene_clk_pmd *fd = to_xgene_clk_pmd(hw);
+   unsigned long flags = 0;
+   u64 ret, scale;
+   u32 val;
+
+   if (fd->lock)
+   spin_lock_irqsave(fd->lock, flags);
+   else
+   __acquire(fd->lock);
+
+   val = clk_readl(fd->reg);
+
+   if (fd->lock)
+   spin_unlock_irqrestore(fd->lock, flags);
+   else
+   __release(fd->lock);
+
+   ret = (u64)parent_rate;
+
+   scale = (val & fd->mask) >> fd->shift;
+   if (fd->flags & XGENE_CLK_PMD_SCALE_INVERTED)
+   scale = fd->denom - scale;
+   else
+   scale++;
+
+   /* freq = parent_rate * scaler / denom */
+   do_div(ret, fd->denom);
+   ret *= scale;
+   if (ret == 0)
+   ret = (u64)parent_rate;
+
+   return ret;
+}
+
+static long xgene_clk_pmd_round_rate(struct clk_hw *hw, unsigned long rate,
+unsigned long *parent_rate)
+{
+   struct xgene_clk_pmd *fd = to_xgene_clk_pmd(hw);
+   u64 ret, scale;
+
+   if (!rate || rate >= *parent_rate)
+   return *parent_rate;
+
+   /* freq = parent_rate * scaler / denom */
+   ret = rate * fd->denom;
+   scale = DIV_ROUND_UP_ULL(ret, *parent_rate);
+
+   ret = (u64)*parent_rate * scale;
+   do_div(ret, fd->denom);
+
+   return ret;
+}
+
+static int xgene_clk_pmd_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+   struct xgene_clk_pmd *fd = to_xgene_clk_pmd(hw);
+   unsigned long flags = 0;
+   u64 scale, ret;
+   u32 val;
+
+   /*
+* Compute the scaler:
+*
+* freq = parent_rate * scaler / denom, or
+* scaler = freq * denom / parent_rate
+*/
+   ret = rate * fd->denom;
+   scale = DIV_ROUND_UP_ULL(ret, (u64)parent_rate);
+
+   /* Check if inverted */
+   if (fd->flags & XGENE_CLK_PMD_SCALE_INVERTED)
+   scale = fd->denom - scale;
+   else
+   scale--;
+
+   if (fd->lock)
+   spin_lock_irqsave(fd->lock, flags);
+   else
+   __acquire(fd->lock);
+
+   val = clk_readl(fd->reg);
+   val &= ~fd->mask;
+   val |= (scale << fd->shift);
+   clk_writel(val, fd->reg);
+
+   if (fd->lock)
+   spin_unlock_irqrestore(fd->lock, flags);
+   else
+   __release(fd->lock);
+
+   return 0;
+}
+
+static const struct clk_ops xgene_clk_pmd_ops = {
+   .recalc_rate = xgene_clk_pmd_recalc_rate,
+   .round_rate = xgene_clk_pmd_round_rate,
+   .set_rate = xgene_clk_pmd_set_rate,
+};
+
+static struct clk *
+xgene_register_clk_pmd(struct device *dev,
+  const char *name, const char *parent_name,
+  unsigned long flags, void __iomem *reg, u8 shift,
+  u8 width, u64 denom, u32 

[PATCH v2 3/3] arm64: dts: xgene: Add DT node for APM X-Gene 2 CPU clocks

[Hoan Tran]

Add DT nodes to enable APM X-Gene 2 CPU clocks.

Signed-off-by: Hoan Tran 
---
 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 56 ++
 1 file changed, 56 insertions(+)

diff --git a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi 
b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
index 1425ed4..7b31895 100644
--- a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
@@ -26,6 +26,8 @@
enable-method = "spin-table";
cpu-release-addr = <0x1 0xfff8>;
next-level-cache = <_L2_0>;
+   #clock-cells = <1>;
+   clocks = < 0>;
};
cpu@001 {
device_type = "cpu";
@@ -34,6 +36,8 @@
enable-method = "spin-table";
cpu-release-addr = <0x1 0xfff8>;
next-level-cache = <_L2_0>;
+   #clock-cells = <1>;
+   clocks = < 0>;
};
cpu@100 {
device_type = "cpu";
@@ -42,6 +46,8 @@
enable-method = "spin-table";
cpu-release-addr = <0x1 0xfff8>;
next-level-cache = <_L2_1>;
+   #clock-cells = <1>;
+   clocks = < 0>;
};
cpu@101 {
device_type = "cpu";
@@ -50,6 +56,8 @@
enable-method = "spin-table";
cpu-release-addr = <0x1 0xfff8>;
next-level-cache = <_L2_1>;
+   #clock-cells = <1>;
+   clocks = < 0>;
};
cpu@200 {
device_type = "cpu";
@@ -58,6 +66,8 @@
enable-method = "spin-table";
cpu-release-addr = <0x1 0xfff8>;
next-level-cache = <_L2_2>;
+   #clock-cells = <1>;
+   clocks = < 0>;
};
cpu@201 {
device_type = "cpu";
@@ -66,6 +76,8 @@
enable-method = "spin-table";
cpu-release-addr = <0x1 0xfff8>;
next-level-cache = <_L2_2>;
+   #clock-cells = <1>;
+   clocks = < 0>;
};
cpu@300 {
device_type = "cpu";
@@ -74,6 +86,8 @@
enable-method = "spin-table";
cpu-release-addr = <0x1 0xfff8>;
next-level-cache = <_L2_3>;
+   #clock-cells = <1>;
+   clocks = < 0>;
};
cpu@301 {
device_type = "cpu";
@@ -82,6 +96,8 @@
enable-method = "spin-table";
cpu-release-addr = <0x1 0xfff8>;
next-level-cache = <_L2_3>;
+   #clock-cells = <1>;
+   clocks = < 0>;
};
xgene_L2_0: l2-cache-0 {
compatible = "cache";
@@ -223,6 +239,46 @@
clock-output-names = "refclk";
};
 
+   pmdpll: pmdpll@17f0 {
+   compatible = "apm,xgene-pcppll-v2-clock";
+   #clock-cells = <1>;
+   clocks = < 0>;
+   reg = <0x0 0x17f0 0x0 0x10>;
+   clock-output-names = "pmdpll";
+   };
+
+   pmd0clk: pmd0clk@7e200200 {
+   compatible = "apm,xgene-pmd-clock";
+   #clock-cells = <1>;
+   clocks = < 0>;
+   reg = <0x0 0x7e200200 0x0 0x10>;
+   clock-output-names = "pmd0clk";
+   };
+
+   pmd1clk: pmd1clk@7e200210 {
+   compatible = "apm,xgene-pmd-clock";
+   #clock-cells = <1>;
+   clocks = < 0>;
+   reg = <0x0 0x7e200210 0x0 0x10>;
+   clock-output-names = "pmd1clk";
+   };
+
+   pmd2clk: pmd2clk@7e200220 {
+   compatible = "apm,xgene-pmd-clock";
+   #clock-cells = <1>;
+   clocks = < 0>;
+   reg = <0x0 0x7e200220 0x0 0x10>;
+   clock-output-names = "pmd2clk";
+   };
+
+   pmd3clk: pmd3clk@7e200230 {
+  

[PATCH v2 1/3] Documentation: dtb: xgene: Add PMD clock binding

[Hoan Tran]

Add APM X-Gene clock binding documentation for PMD clock.

Signed-off-by: Hoan Tran 
---
 Documentation/devicetree/bindings/clock/xgene.txt | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/xgene.txt 
b/Documentation/devicetree/bindings/clock/xgene.txt
index 82f9638..e6e12ae 100644
--- a/Documentation/devicetree/bindings/clock/xgene.txt
+++ b/Documentation/devicetree/bindings/clock/xgene.txt
@@ -8,6 +8,7 @@ Required properties:
 - compatible : shall be one of the following:
"apm,xgene-socpll-clock" - for a X-Gene SoC PLL clock
"apm,xgene-pcppll-clock" - for a X-Gene PCP PLL clock
+   "apm,xgene-pmd-clock" - for a X-Gene PMD clock
"apm,xgene-device-clock" - for a X-Gene device clock
"apm,xgene-socpll-v2-clock" - for a X-Gene SoC PLL v2 clock
"apm,xgene-pcppll-v2-clock" - for a X-Gene PCP PLL v2 clock
@@ -22,6 +23,15 @@ Required properties for SoC or PCP PLL clocks:
 Optional properties for PLL clocks:
 - clock-names : shall be the name of the PLL. If missing, use the device name.
 
+Required properties for PMD clocks:
+- reg : shall be the physical register address for the pmd clock.
+- clocks : shall be the input parent clock phandle for the clock.
+- #clock-cells : shall be set to 1.
+- clock-output-names : shall be the name of the clock referenced by derive
+  clock.
+Optional properties for PLL clocks:
+- clock-names : shall be the name of the clock. If missing, use the device 
name.
+
 Required properties for device clocks:
 - reg : shall be a list of address and length pairs describing the CSR
  reset and/or the divider. Either may be omitted, but at least
@@ -59,6 +69,14 @@ For example:
type = <0>;
};
 
+   pmd0clk: pmd0clk {
+   compatible = "apm,xgene-pmd-clock";
+   #clock-cells = <1>;
+   clocks = < 0>;
+   reg = <0x0 0x7E200200 0x0 0x10>;
+   clock-output-names = "pmd0clk";
+   };
+
socpll: socpll@17000120 {
compatible = "apm,xgene-socpll-clock";
#clock-cells = <1>;
-- 
1.9.1

[PATCH v2 3/3] arm64: dts: xgene: Add DT node for APM X-Gene 2 CPU clocks

[Hoan Tran]

Add DT nodes to enable APM X-Gene 2 CPU clocks.

Signed-off-by: Hoan Tran 
---
 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 56 ++
 1 file changed, 56 insertions(+)

diff --git a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi 
b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
index 1425ed4..7b31895 100644
--- a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
@@ -26,6 +26,8 @@
enable-method = "spin-table";
cpu-release-addr = <0x1 0xfff8>;
next-level-cache = <_L2_0>;
+   #clock-cells = <1>;
+   clocks = < 0>;
};
cpu@001 {
device_type = "cpu";
@@ -34,6 +36,8 @@
enable-method = "spin-table";
cpu-release-addr = <0x1 0xfff8>;
next-level-cache = <_L2_0>;
+   #clock-cells = <1>;
+   clocks = < 0>;
};
cpu@100 {
device_type = "cpu";
@@ -42,6 +46,8 @@
enable-method = "spin-table";
cpu-release-addr = <0x1 0xfff8>;
next-level-cache = <_L2_1>;
+   #clock-cells = <1>;
+   clocks = < 0>;
};
cpu@101 {
device_type = "cpu";
@@ -50,6 +56,8 @@
enable-method = "spin-table";
cpu-release-addr = <0x1 0xfff8>;
next-level-cache = <_L2_1>;
+   #clock-cells = <1>;
+   clocks = < 0>;
};
cpu@200 {
device_type = "cpu";
@@ -58,6 +66,8 @@
enable-method = "spin-table";
cpu-release-addr = <0x1 0xfff8>;
next-level-cache = <_L2_2>;
+   #clock-cells = <1>;
+   clocks = < 0>;
};
cpu@201 {
device_type = "cpu";
@@ -66,6 +76,8 @@
enable-method = "spin-table";
cpu-release-addr = <0x1 0xfff8>;
next-level-cache = <_L2_2>;
+   #clock-cells = <1>;
+   clocks = < 0>;
};
cpu@300 {
device_type = "cpu";
@@ -74,6 +86,8 @@
enable-method = "spin-table";
cpu-release-addr = <0x1 0xfff8>;
next-level-cache = <_L2_3>;
+   #clock-cells = <1>;
+   clocks = < 0>;
};
cpu@301 {
device_type = "cpu";
@@ -82,6 +96,8 @@
enable-method = "spin-table";
cpu-release-addr = <0x1 0xfff8>;
next-level-cache = <_L2_3>;
+   #clock-cells = <1>;
+   clocks = < 0>;
};
xgene_L2_0: l2-cache-0 {
compatible = "cache";
@@ -223,6 +239,46 @@
clock-output-names = "refclk";
};
 
+   pmdpll: pmdpll@17f0 {
+   compatible = "apm,xgene-pcppll-v2-clock";
+   #clock-cells = <1>;
+   clocks = < 0>;
+   reg = <0x0 0x17f0 0x0 0x10>;
+   clock-output-names = "pmdpll";
+   };
+
+   pmd0clk: pmd0clk@7e200200 {
+   compatible = "apm,xgene-pmd-clock";
+   #clock-cells = <1>;
+   clocks = < 0>;
+   reg = <0x0 0x7e200200 0x0 0x10>;
+   clock-output-names = "pmd0clk";
+   };
+
+   pmd1clk: pmd1clk@7e200210 {
+   compatible = "apm,xgene-pmd-clock";
+   #clock-cells = <1>;
+   clocks = < 0>;
+   reg = <0x0 0x7e200210 0x0 0x10>;
+   clock-output-names = "pmd1clk";
+   };
+
+   pmd2clk: pmd2clk@7e200220 {
+   compatible = "apm,xgene-pmd-clock";
+   #clock-cells = <1>;
+   clocks = < 0>;
+   reg = <0x0 0x7e200220 0x0 0x10>;
+   clock-output-names = "pmd2clk";
+   };
+
+   pmd3clk: pmd3clk@7e200230 {
+  

[PATCH v2 1/3] Documentation: dtb: xgene: Add PMD clock binding

[Hoan Tran]

Add APM X-Gene clock binding documentation for PMD clock.

Signed-off-by: Hoan Tran 
---
 Documentation/devicetree/bindings/clock/xgene.txt | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/xgene.txt 
b/Documentation/devicetree/bindings/clock/xgene.txt
index 82f9638..e6e12ae 100644
--- a/Documentation/devicetree/bindings/clock/xgene.txt
+++ b/Documentation/devicetree/bindings/clock/xgene.txt
@@ -8,6 +8,7 @@ Required properties:
 - compatible : shall be one of the following:
"apm,xgene-socpll-clock" - for a X-Gene SoC PLL clock
"apm,xgene-pcppll-clock" - for a X-Gene PCP PLL clock
+   "apm,xgene-pmd-clock" - for a X-Gene PMD clock
"apm,xgene-device-clock" - for a X-Gene device clock
"apm,xgene-socpll-v2-clock" - for a X-Gene SoC PLL v2 clock
"apm,xgene-pcppll-v2-clock" - for a X-Gene PCP PLL v2 clock
@@ -22,6 +23,15 @@ Required properties for SoC or PCP PLL clocks:
 Optional properties for PLL clocks:
 - clock-names : shall be the name of the PLL. If missing, use the device name.
 
+Required properties for PMD clocks:
+- reg : shall be the physical register address for the pmd clock.
+- clocks : shall be the input parent clock phandle for the clock.
+- #clock-cells : shall be set to 1.
+- clock-output-names : shall be the name of the clock referenced by derive
+  clock.
+Optional properties for PLL clocks:
+- clock-names : shall be the name of the clock. If missing, use the device 
name.
+
 Required properties for device clocks:
 - reg : shall be a list of address and length pairs describing the CSR
  reset and/or the divider. Either may be omitted, but at least
@@ -59,6 +69,14 @@ For example:
type = <0>;
};
 
+   pmd0clk: pmd0clk {
+   compatible = "apm,xgene-pmd-clock";
+   #clock-cells = <1>;
+   clocks = < 0>;
+   reg = <0x0 0x7E200200 0x0 0x10>;
+   clock-output-names = "pmd0clk";
+   };
+
socpll: socpll@17000120 {
compatible = "apm,xgene-socpll-clock";
#clock-cells = <1>;
-- 
1.9.1

[PATCH v2 0/2] Add memcpy support for tegra210-adma

[Nicolin Chen]

This series of patches add memcpy support for tegra210 ADMA engine.

Changlog
v1->v2 (Suggested by Vinod)
 * PATCH-1: Split the cyclic pre-check to a separate patch
 * PATCH-2: Add ADMA_CH_CTRL_MODE to unify the marcos
 * PATCH-2: Set operation mode depending on cyclic
 * PATCH-2: Add TODO comment at period_len
 * PATCH-2: Revise the commit log

Nicolin Chen (2):
  dmaengine: tegra210-adma: Add pre-check for cyclic callback
  dmaengine: tegra210-adma: Add memcpy support

 drivers/dma/tegra210-adma.c | 98 +++--
 1 file changed, 86 insertions(+), 12 deletions(-)

-- 
2.1.4

[PATCH v2 0/2] Add memcpy support for tegra210-adma

[Nicolin Chen]

This series of patches add memcpy support for tegra210 ADMA engine.

Changlog
v1->v2 (Suggested by Vinod)
 * PATCH-1: Split the cyclic pre-check to a separate patch
 * PATCH-2: Add ADMA_CH_CTRL_MODE to unify the marcos
 * PATCH-2: Set operation mode depending on cyclic
 * PATCH-2: Add TODO comment at period_len
 * PATCH-2: Revise the commit log

Nicolin Chen (2):
  dmaengine: tegra210-adma: Add pre-check for cyclic callback
  dmaengine: tegra210-adma: Add memcpy support

 drivers/dma/tegra210-adma.c | 98 +++--
 1 file changed, 86 insertions(+), 12 deletions(-)

-- 
2.1.4

[PATCH v2 2/2] dmaengine: tegra210-adma: Add memcpy support

[Nicolin Chen]

ADMA supports non-flow controlled Memory-to-Memory direction
transactions. So this patch just adds an initial support for
that. It passed a simple dmatest:
echo dma1chan0 > /sys/module/dmatest/parameters/channel
echo 1024 > /sys/module/dmatest/parameters/iterations
echo 0 > /sys/module/dmatest/parameters/dmatest
echo 1 > /sys/module/dmatest/parameters/run
dmesg | grep dmatest
Started 1 threads using dma1chan0
dma1chan0-copy0: summary 1024 tests, 0 failures 2054 iops 16520 KB/s (0)

Signed-off-by: Nicolin Chen 
---
 drivers/dma/tegra210-adma.c | 95 +++--
 1 file changed, 83 insertions(+), 12 deletions(-)

diff --git a/drivers/dma/tegra210-adma.c b/drivers/dma/tegra210-adma.c
index 5b5d298..d62b373 100644
--- a/drivers/dma/tegra210-adma.c
+++ b/drivers/dma/tegra210-adma.c
@@ -42,9 +42,14 @@
 #define ADMA_CH_CTRL_RX_REQ(val)   (((val) & 0xf) << 24)
 #define ADMA_CH_CTRL_RX_REQ_MAX10
 #define ADMA_CH_CTRL_DIR(val)  (((val) & 0xf) << 12)
+#define ADMA_CH_CTRL_DIR_MEM2MEM   1
 #define ADMA_CH_CTRL_DIR_AHUB2MEM  2
 #define ADMA_CH_CTRL_DIR_MEM2AHUB  4
-#define ADMA_CH_CTRL_MODE_CONTINUOUS   (2 << 8)
+#define ADMA_CH_CTRL_DIR_AHUB2AHUB 8
+#define ADMA_CH_CTRL_MODE(val) (((val) & 0x7) << 8)
+#define ADMA_CH_CTRL_MODE_ONCE 1
+#define ADMA_CH_CTRL_MODE_CONTINUOUS   2
+#define ADMA_CH_CTRL_MODE_LINKED_LIST  4
 #define ADMA_CH_CTRL_FLOWCTRL_EN   BIT(1)
 
 #define ADMA_CH_CONFIG 0x28
@@ -264,6 +269,9 @@ static int tegra_adma_request_alloc(struct tegra_adma_chan 
*tdc,
}
break;
 
+   case DMA_MEM_TO_MEM:
+   break;
+
default:
dev_WARN(tdma->dev, "channel %s has invalid transfer type\n",
 dma_chan_name(>vc.chan));
@@ -292,6 +300,9 @@ static void tegra_adma_request_free(struct tegra_adma_chan 
*tdc)
clear_bit(tdc->sreq_index, >rx_requests_reserved);
break;
 
+   case DMA_MEM_TO_MEM:
+   break;
+
default:
dev_WARN(tdma->dev, "channel %s has invalid transfer type\n",
 dma_chan_name(>vc.chan));
@@ -409,8 +420,14 @@ static irqreturn_t tegra_adma_isr(int irq, void *dev_id)
return IRQ_NONE;
}
 
-   if (tdc->desc->cyclic)
+   if (tdc->desc->cyclic) {
vchan_cyclic_callback(>desc->vd);
+   } else {
+   /* Disable the channel */
+   tdma_ch_write(tdc, ADMA_CH_CMD, 0);
+   vchan_cookie_complete(>desc->vd);
+   tdc->desc = NULL;
+   }
 
spin_unlock_irqrestore(>vc.lock, flags);
 
@@ -488,42 +505,59 @@ static enum dma_status tegra_adma_tx_status(struct 
dma_chan *dc,
 static int tegra_adma_set_xfer_params(struct tegra_adma_chan *tdc,
  struct tegra_adma_desc *desc,
  dma_addr_t buf_addr,
+ dma_addr_t buf_addr2,
  enum dma_transfer_direction direction)
 {
struct tegra_adma_chan_regs *ch_regs = >ch_regs;
-   unsigned int burst_size, adma_dir;
+   unsigned int num_periods = desc->num_periods;
+   unsigned int burst_size, adma_dir, adma_mode;
 
-   if (desc->num_periods > ADMA_CH_CONFIG_MAX_BUFS)
+   if (num_periods > ADMA_CH_CONFIG_MAX_BUFS)
return -EINVAL;
 
switch (direction) {
case DMA_MEM_TO_DEV:
adma_dir = ADMA_CH_CTRL_DIR_MEM2AHUB;
burst_size = fls(tdc->sconfig.dst_maxburst);
-   ch_regs->config = ADMA_CH_CONFIG_SRC_BUF(desc->num_periods - 1);
-   ch_regs->ctrl = ADMA_CH_CTRL_TX_REQ(tdc->sreq_index);
+   ch_regs->config = ADMA_CH_CONFIG_SRC_BUF(num_periods - 1);
+   ch_regs->ctrl = ADMA_CH_CTRL_TX_REQ(tdc->sreq_index) |
+   ADMA_CH_CTRL_FLOWCTRL_EN;
ch_regs->src_addr = buf_addr;
break;
 
case DMA_DEV_TO_MEM:
adma_dir = ADMA_CH_CTRL_DIR_AHUB2MEM;
burst_size = fls(tdc->sconfig.src_maxburst);
-   ch_regs->config = ADMA_CH_CONFIG_TRG_BUF(desc->num_periods - 1);
-   ch_regs->ctrl = ADMA_CH_CTRL_RX_REQ(tdc->sreq_index);
+   ch_regs->config = ADMA_CH_CONFIG_TRG_BUF(num_periods - 1);
+   ch_regs->ctrl = ADMA_CH_CTRL_RX_REQ(tdc->sreq_index) |
+   ADMA_CH_CTRL_FLOWCTRL_EN;
ch_regs->trg_addr = buf_addr;
break;
 
+   case DMA_MEM_TO_MEM:
+   

[PATCH v2 1/2] dmaengine: tegra210-adma: Add pre-check for cyclic callback

[Nicolin Chen]

ADMA driver will support more than cyclic type of transaction.
So this patch limits the cyclic callback for the cyclic type
only in order to support other types.

Signed-off-by: Nicolin Chen 
---
 drivers/dma/tegra210-adma.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/tegra210-adma.c b/drivers/dma/tegra210-adma.c
index 09b46f7..5b5d298 100644
--- a/drivers/dma/tegra210-adma.c
+++ b/drivers/dma/tegra210-adma.c
@@ -111,6 +111,7 @@ struct tegra_adma_desc {
size_t  buf_len;
size_t  period_len;
size_t  num_periods;
+   boolcyclic;
 };
 
 /*
@@ -408,7 +409,8 @@ static irqreturn_t tegra_adma_isr(int irq, void *dev_id)
return IRQ_NONE;
}
 
-   vchan_cyclic_callback(>desc->vd);
+   if (tdc->desc->cyclic)
+   vchan_cyclic_callback(>desc->vd);
 
spin_unlock_irqrestore(>vc.lock, flags);
 
@@ -557,6 +559,7 @@ static struct dma_async_tx_descriptor 
*tegra_adma_prep_dma_cyclic(
if (!desc)
return NULL;
 
+   desc->cyclic = true;
desc->buf_len = buf_len;
desc->period_len = period_len;
desc->num_periods = buf_len / period_len;
-- 
2.1.4

[PATCH v2 2/2] dmaengine: tegra210-adma: Add memcpy support

[Nicolin Chen]

ADMA supports non-flow controlled Memory-to-Memory direction
transactions. So this patch just adds an initial support for
that. It passed a simple dmatest:
echo dma1chan0 > /sys/module/dmatest/parameters/channel
echo 1024 > /sys/module/dmatest/parameters/iterations
echo 0 > /sys/module/dmatest/parameters/dmatest
echo 1 > /sys/module/dmatest/parameters/run
dmesg | grep dmatest
Started 1 threads using dma1chan0
dma1chan0-copy0: summary 1024 tests, 0 failures 2054 iops 16520 KB/s (0)

Signed-off-by: Nicolin Chen 
---
 drivers/dma/tegra210-adma.c | 95 +++--
 1 file changed, 83 insertions(+), 12 deletions(-)

diff --git a/drivers/dma/tegra210-adma.c b/drivers/dma/tegra210-adma.c
index 5b5d298..d62b373 100644
--- a/drivers/dma/tegra210-adma.c
+++ b/drivers/dma/tegra210-adma.c
@@ -42,9 +42,14 @@
 #define ADMA_CH_CTRL_RX_REQ(val)   (((val) & 0xf) << 24)
 #define ADMA_CH_CTRL_RX_REQ_MAX10
 #define ADMA_CH_CTRL_DIR(val)  (((val) & 0xf) << 12)
+#define ADMA_CH_CTRL_DIR_MEM2MEM   1
 #define ADMA_CH_CTRL_DIR_AHUB2MEM  2
 #define ADMA_CH_CTRL_DIR_MEM2AHUB  4
-#define ADMA_CH_CTRL_MODE_CONTINUOUS   (2 << 8)
+#define ADMA_CH_CTRL_DIR_AHUB2AHUB 8
+#define ADMA_CH_CTRL_MODE(val) (((val) & 0x7) << 8)
+#define ADMA_CH_CTRL_MODE_ONCE 1
+#define ADMA_CH_CTRL_MODE_CONTINUOUS   2
+#define ADMA_CH_CTRL_MODE_LINKED_LIST  4
 #define ADMA_CH_CTRL_FLOWCTRL_EN   BIT(1)
 
 #define ADMA_CH_CONFIG 0x28
@@ -264,6 +269,9 @@ static int tegra_adma_request_alloc(struct tegra_adma_chan 
*tdc,
}
break;
 
+   case DMA_MEM_TO_MEM:
+   break;
+
default:
dev_WARN(tdma->dev, "channel %s has invalid transfer type\n",
 dma_chan_name(>vc.chan));
@@ -292,6 +300,9 @@ static void tegra_adma_request_free(struct tegra_adma_chan 
*tdc)
clear_bit(tdc->sreq_index, >rx_requests_reserved);
break;
 
+   case DMA_MEM_TO_MEM:
+   break;
+
default:
dev_WARN(tdma->dev, "channel %s has invalid transfer type\n",
 dma_chan_name(>vc.chan));
@@ -409,8 +420,14 @@ static irqreturn_t tegra_adma_isr(int irq, void *dev_id)
return IRQ_NONE;
}
 
-   if (tdc->desc->cyclic)
+   if (tdc->desc->cyclic) {
vchan_cyclic_callback(>desc->vd);
+   } else {
+   /* Disable the channel */
+   tdma_ch_write(tdc, ADMA_CH_CMD, 0);
+   vchan_cookie_complete(>desc->vd);
+   tdc->desc = NULL;
+   }
 
spin_unlock_irqrestore(>vc.lock, flags);
 
@@ -488,42 +505,59 @@ static enum dma_status tegra_adma_tx_status(struct 
dma_chan *dc,
 static int tegra_adma_set_xfer_params(struct tegra_adma_chan *tdc,
  struct tegra_adma_desc *desc,
  dma_addr_t buf_addr,
+ dma_addr_t buf_addr2,
  enum dma_transfer_direction direction)
 {
struct tegra_adma_chan_regs *ch_regs = >ch_regs;
-   unsigned int burst_size, adma_dir;
+   unsigned int num_periods = desc->num_periods;
+   unsigned int burst_size, adma_dir, adma_mode;
 
-   if (desc->num_periods > ADMA_CH_CONFIG_MAX_BUFS)
+   if (num_periods > ADMA_CH_CONFIG_MAX_BUFS)
return -EINVAL;
 
switch (direction) {
case DMA_MEM_TO_DEV:
adma_dir = ADMA_CH_CTRL_DIR_MEM2AHUB;
burst_size = fls(tdc->sconfig.dst_maxburst);
-   ch_regs->config = ADMA_CH_CONFIG_SRC_BUF(desc->num_periods - 1);
-   ch_regs->ctrl = ADMA_CH_CTRL_TX_REQ(tdc->sreq_index);
+   ch_regs->config = ADMA_CH_CONFIG_SRC_BUF(num_periods - 1);
+   ch_regs->ctrl = ADMA_CH_CTRL_TX_REQ(tdc->sreq_index) |
+   ADMA_CH_CTRL_FLOWCTRL_EN;
ch_regs->src_addr = buf_addr;
break;
 
case DMA_DEV_TO_MEM:
adma_dir = ADMA_CH_CTRL_DIR_AHUB2MEM;
burst_size = fls(tdc->sconfig.src_maxburst);
-   ch_regs->config = ADMA_CH_CONFIG_TRG_BUF(desc->num_periods - 1);
-   ch_regs->ctrl = ADMA_CH_CTRL_RX_REQ(tdc->sreq_index);
+   ch_regs->config = ADMA_CH_CONFIG_TRG_BUF(num_periods - 1);
+   ch_regs->ctrl = ADMA_CH_CTRL_RX_REQ(tdc->sreq_index) |
+   ADMA_CH_CTRL_FLOWCTRL_EN;
ch_regs->trg_addr = buf_addr;
break;
 
+   case DMA_MEM_TO_MEM:
+   adma_dir = 

[PATCH v2 1/2] dmaengine: tegra210-adma: Add pre-check for cyclic callback

[Nicolin Chen]

ADMA driver will support more than cyclic type of transaction.
So this patch limits the cyclic callback for the cyclic type
only in order to support other types.

Signed-off-by: Nicolin Chen 
---
 drivers/dma/tegra210-adma.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/tegra210-adma.c b/drivers/dma/tegra210-adma.c
index 09b46f7..5b5d298 100644
--- a/drivers/dma/tegra210-adma.c
+++ b/drivers/dma/tegra210-adma.c
@@ -111,6 +111,7 @@ struct tegra_adma_desc {
size_t  buf_len;
size_t  period_len;
size_t  num_periods;
+   boolcyclic;
 };
 
 /*
@@ -408,7 +409,8 @@ static irqreturn_t tegra_adma_isr(int irq, void *dev_id)
return IRQ_NONE;
}
 
-   vchan_cyclic_callback(>desc->vd);
+   if (tdc->desc->cyclic)
+   vchan_cyclic_callback(>desc->vd);
 
spin_unlock_irqrestore(>vc.lock, flags);
 
@@ -557,6 +559,7 @@ static struct dma_async_tx_descriptor 
*tegra_adma_prep_dma_cyclic(
if (!desc)
return NULL;
 
+   desc->cyclic = true;
desc->buf_len = buf_len;
desc->period_len = period_len;
desc->num_periods = buf_len / period_len;
-- 
2.1.4

Re: [PATCH 4/4] kvm: x86: export TSC offset to user-space

[Marcelo Tosatti]

On Fri, Sep 02, 2016 at 10:15:41AM -0400, Steven Rostedt wrote:
> On Fri, 2 Sep 2016 09:43:01 -0400
> Stefan Hajnoczi  wrote:
> 
> > Can TSC offset changes occur at runtime?

Yes, but Linux guests don't write to the TSC offset
after booting and unless user does manual TSC writes.

> > One example is vcpu hotplug where the tracing tool would need to fetch
> > the new vcpu's TSC offset after tracing has already started.
> > 
> > Another example is if QEMU or the guest change the TSC offset while
> > running.  If the tracing tool doesn't notice this then trace events will 
> > have
> > incorrect timestamps.

So what happens is this:

HostTSC (a variable). 
GuestTSC (variable) = GuestTSCOffset (fixed) + HostTSC (variable)

Then the algorithm processes the trace as follows:
line = for each line(guest_trace)
line = line - GuestTSCOffset (only the timestamp of course)

So from the moment the guest writes a new TSC offset, the host 
should use the new TSC offset to subtract from the trace entries.
The trace entries are in fact:

HostTSC + GuestTSCOffset

So the guest trace should contain entries for "USE NEW TSC OFFSET,
VALUE: xxx", which can be done (hum not sure if guest entries
or host entries).

However, correct me if i am wrong, the usecase seems to be:

1) Boot guest.
2) run trace-cmd
3) run workload
4) read traces on host.

Another option is to have notifications as follows: record on a buffer 
the following:

[ EVENT: TSC offset write, VAL: [ host tsc value, guest tsc offset ] ]
[ EVENT: TSC offset write, VAL: [ host tsc value, guest tsc offset ] ]

Then when merging the trace entries, you do:

line = for each line(host trace)
write_to_merged_trace(line)
if (contains_tsc_offset_event(line)) {
GuestTSCOffset = line.GuestTSCOffset
if (!guest_tsc_offset_initialized) {
process_all_guest_lines(
line = line - GuestTSCOffset (only the timestamp of course)
}
}

Aha, fail: the traces on the host are not sufficient to know when 
to use which offset to subtract on the guest trace.

So the only possibility is to have the guest inform the occurrence
of the events: however the guest does not have access to the TSC offset.

So the host needs to inform the new tsc offset value and the guest needs
to inform when the event occurred on its side. So the algorithm can use
information on both traces to know which value to subtract on the
algorithm above.

Is this necessary? Or people do:
1) Boot guest.
2) run trace-cmd
3) run workload
4) read traces on host.

> I believe there are tracepoints for these events. They would obviously
> need to be enabled for the tracer to catch them.
> 
> I would also recommend that they go into their own instance to make
> sure other events do not overwrite them.
> 
> -- Steve

Re: [PATCH 4/4] kvm: x86: export TSC offset to user-space

[Marcelo Tosatti]

On Fri, Sep 02, 2016 at 10:15:41AM -0400, Steven Rostedt wrote:
> On Fri, 2 Sep 2016 09:43:01 -0400
> Stefan Hajnoczi  wrote:
> 
> > Can TSC offset changes occur at runtime?

Yes, but Linux guests don't write to the TSC offset
after booting and unless user does manual TSC writes.

> > One example is vcpu hotplug where the tracing tool would need to fetch
> > the new vcpu's TSC offset after tracing has already started.
> > 
> > Another example is if QEMU or the guest change the TSC offset while
> > running.  If the tracing tool doesn't notice this then trace events will 
> > have
> > incorrect timestamps.

So what happens is this:

HostTSC (a variable). 
GuestTSC (variable) = GuestTSCOffset (fixed) + HostTSC (variable)

Then the algorithm processes the trace as follows:
line = for each line(guest_trace)
line = line - GuestTSCOffset (only the timestamp of course)

So from the moment the guest writes a new TSC offset, the host 
should use the new TSC offset to subtract from the trace entries.
The trace entries are in fact:

HostTSC + GuestTSCOffset

So the guest trace should contain entries for "USE NEW TSC OFFSET,
VALUE: xxx", which can be done (hum not sure if guest entries
or host entries).

However, correct me if i am wrong, the usecase seems to be:

1) Boot guest.
2) run trace-cmd
3) run workload
4) read traces on host.

Another option is to have notifications as follows: record on a buffer 
the following:

[ EVENT: TSC offset write, VAL: [ host tsc value, guest tsc offset ] ]
[ EVENT: TSC offset write, VAL: [ host tsc value, guest tsc offset ] ]

Then when merging the trace entries, you do:

line = for each line(host trace)
write_to_merged_trace(line)
if (contains_tsc_offset_event(line)) {
GuestTSCOffset = line.GuestTSCOffset
if (!guest_tsc_offset_initialized) {
process_all_guest_lines(
line = line - GuestTSCOffset (only the timestamp of course)
}
}

Aha, fail: the traces on the host are not sufficient to know when 
to use which offset to subtract on the guest trace.

So the only possibility is to have the guest inform the occurrence
of the events: however the guest does not have access to the TSC offset.

So the host needs to inform the new tsc offset value and the guest needs
to inform when the event occurred on its side. So the algorithm can use
information on both traces to know which value to subtract on the
algorithm above.

Is this necessary? Or people do:
1) Boot guest.
2) run trace-cmd
3) run workload
4) read traces on host.

> I believe there are tracepoints for these events. They would obviously
> need to be enabled for the tracer to catch them.
> 
> I would also recommend that they go into their own instance to make
> sure other events do not overwrite them.
> 
> -- Steve

[RFC] fs: add userspace critical mounts event support

[Luis R. Rodriguez]

kernel_read_file_from_path() can try to read a file from
the system's filesystem. This is typically done for firmware
for instance, which lives in /lib/firmware. One issue with
this is that the kernel cannot know for sure when the real
final /lib/firmare/ is ready, and even if you use initramfs
drivers are currently initialized *first* prior to the initramfs
kicking off. During init we run through all init calls first
(do_initcalls()) and finally the initramfs is processed via
prepare_namespace():

do_basic_setup() {
   ...
   driver_init();
   ...
   do_initcalls();
   ...
}

kernel_init_freeable() {
   ...
   do_basic_setup();
   ...
   if (sys_access((const char __user *) ramdisk_execute_command, 0) != 0) {
  ramdisk_execute_command = NULL;
  prepare_namespace();
   }
}

This leaves a possible race between loading drivers and any uses
of kernel_read_file_from_path(). Because pivot_root() can be used,
this allows userspace further possibilities in terms of defining
when a kernel critical filesystem should be ready by.

We define kernel critical filesystems as filesystems which the
kernel needs for kernel_read_file_from_path(). Since only userspace
can know when kernel critical filesystems are mounted and ready,
let userspace notify the kernel of this, and enable a new kernel
configuration which lets the kernel wait for this event before
enabling reads from kernel_read_file_from_path().

A default timeout of 10s is used for now. You can override this
through the kernel-parameters using critical_mounts_timeout_ms=T
where T is in ms. cat /sys/kernel/critical_mounts_timeout_ms the
current system value.

When userspace is ready it can simply:

  echo 1 > /sys/kernel/critical_mounts_ready

Signed-off-by: Luis R. Rodriguez 
---

Note, this still leaves the puzzle of the fact that initramfs may carry
some firmware, and some drivers may be OK in using firmware from there,
the wait stuff would just get in the way. To address this I think can
perhaps instead check *one* for the file, and if its present immediately
give it back, we'd only resort to the wait in cases of failure.

Another thing -- other than firmware we have:

security/integrity/ima/ima_fs.c:rc = kernel_read_file_from_path(path, 
, , 0, READING_POLICY);
sound/oss/sound_firmware.h: err = kernel_read_file_from_path((char *)fn, 
(void **)fp, ,

What paths are these? So we can document the current uses in the Kconfig
at least.

Thoughts ?

 Documentation/kernel-parameters.txt |  6 +++
 drivers/base/Kconfig| 48 +++
 fs/exec.c   |  3 ++
 include/linux/fs.h  |  8 
 kernel/ksysfs.c | 77 +
 5 files changed, 142 insertions(+)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 8ccacc44622a..1af89faa9fc9 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -849,6 +849,12 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
It will be ignored when crashkernel=X,high is not used
or memory reserved is below 4G.
 
+   critical_mounts_timeout_ms=T[KNL] timeout in ms
+   Format: 
+   Use this to override the kernel's default timeout for
+   waiting for critical system mount points to become
+   available.
+
cryptomgr.notests
 [KNL] Disable crypto self-tests
 
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 12b4f5551501..21576c0a4898 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -25,6 +25,54 @@ config UEVENT_HELPER_PATH
  via /proc/sys/kernel/hotplug or via /sys/kernel/uevent_helper
  later at runtime.
 
+config CRITICAL_MOUNTS_WAIT
+   bool "Enable waiting for critical-filesystems-ready notification"
+   default n
+   help
+ Kernel subsystems and device drivers often need to read files
+ from the filesystem, however in doing this races are possible at
+ bootup -- the subsystem requesting the file might look for it in /
+ early in boot, but if we haven't yet mounted the real root
+ filesystem we'll just tell the subsystem the file is not present and
+ it will fail. Furthermore what path to the filesystem is used varies
+ depending on the subsystem. To help the kernel we provide the option
+ to let the kernel wait for all critical filesystems to mounted and
+ ready before letting the kernel start trying to read files from the
+ systems' filesystem. Since pivot_root() can be used and therefore a
+ system might be configured to change its / filesystem at bootup as
+ many times as it wishes, only userspace can realy know exactly when
+ all critical filesystems are 

[RFC] fs: add userspace critical mounts event support

[Luis R. Rodriguez]

kernel_read_file_from_path() can try to read a file from
the system's filesystem. This is typically done for firmware
for instance, which lives in /lib/firmware. One issue with
this is that the kernel cannot know for sure when the real
final /lib/firmare/ is ready, and even if you use initramfs
drivers are currently initialized *first* prior to the initramfs
kicking off. During init we run through all init calls first
(do_initcalls()) and finally the initramfs is processed via
prepare_namespace():

do_basic_setup() {
   ...
   driver_init();
   ...
   do_initcalls();
   ...
}

kernel_init_freeable() {
   ...
   do_basic_setup();
   ...
   if (sys_access((const char __user *) ramdisk_execute_command, 0) != 0) {
  ramdisk_execute_command = NULL;
  prepare_namespace();
   }
}

This leaves a possible race between loading drivers and any uses
of kernel_read_file_from_path(). Because pivot_root() can be used,
this allows userspace further possibilities in terms of defining
when a kernel critical filesystem should be ready by.

We define kernel critical filesystems as filesystems which the
kernel needs for kernel_read_file_from_path(). Since only userspace
can know when kernel critical filesystems are mounted and ready,
let userspace notify the kernel of this, and enable a new kernel
configuration which lets the kernel wait for this event before
enabling reads from kernel_read_file_from_path().

A default timeout of 10s is used for now. You can override this
through the kernel-parameters using critical_mounts_timeout_ms=T
where T is in ms. cat /sys/kernel/critical_mounts_timeout_ms the
current system value.

When userspace is ready it can simply:

  echo 1 > /sys/kernel/critical_mounts_ready

Signed-off-by: Luis R. Rodriguez 
---

Note, this still leaves the puzzle of the fact that initramfs may carry
some firmware, and some drivers may be OK in using firmware from there,
the wait stuff would just get in the way. To address this I think can
perhaps instead check *one* for the file, and if its present immediately
give it back, we'd only resort to the wait in cases of failure.

Another thing -- other than firmware we have:

security/integrity/ima/ima_fs.c:rc = kernel_read_file_from_path(path, 
, , 0, READING_POLICY);
sound/oss/sound_firmware.h: err = kernel_read_file_from_path((char *)fn, 
(void **)fp, ,

What paths are these? So we can document the current uses in the Kconfig
at least.

Thoughts ?

 Documentation/kernel-parameters.txt |  6 +++
 drivers/base/Kconfig| 48 +++
 fs/exec.c   |  3 ++
 include/linux/fs.h  |  8 
 kernel/ksysfs.c | 77 +
 5 files changed, 142 insertions(+)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 8ccacc44622a..1af89faa9fc9 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -849,6 +849,12 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
It will be ignored when crashkernel=X,high is not used
or memory reserved is below 4G.
 
+   critical_mounts_timeout_ms=T[KNL] timeout in ms
+   Format: 
+   Use this to override the kernel's default timeout for
+   waiting for critical system mount points to become
+   available.
+
cryptomgr.notests
 [KNL] Disable crypto self-tests
 
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 12b4f5551501..21576c0a4898 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -25,6 +25,54 @@ config UEVENT_HELPER_PATH
  via /proc/sys/kernel/hotplug or via /sys/kernel/uevent_helper
  later at runtime.
 
+config CRITICAL_MOUNTS_WAIT
+   bool "Enable waiting for critical-filesystems-ready notification"
+   default n
+   help
+ Kernel subsystems and device drivers often need to read files
+ from the filesystem, however in doing this races are possible at
+ bootup -- the subsystem requesting the file might look for it in /
+ early in boot, but if we haven't yet mounted the real root
+ filesystem we'll just tell the subsystem the file is not present and
+ it will fail. Furthermore what path to the filesystem is used varies
+ depending on the subsystem. To help the kernel we provide the option
+ to let the kernel wait for all critical filesystems to mounted and
+ ready before letting the kernel start trying to read files from the
+ systems' filesystem. Since pivot_root() can be used and therefore a
+ system might be configured to change its / filesystem at bootup as
+ many times as it wishes, only userspace can realy know exactly when
+ all critical filesystems are ready. Enabling this 

Re: [PATCH 4/4] kvm: x86: export TSC offset to user-space

[Marcelo Tosatti]

On Fri, Sep 02, 2016 at 09:43:01AM -0400, Stefan Hajnoczi wrote:
> On Wed, Aug 31, 2016 at 01:05:45PM -0400, Luiz Capitulino wrote:
> > We need to retrieve a VM's TSC offset in order to use
> > the host's TSC to merge host and guest traces. This is
> > explained in detail in this thread:
> > 
> >   [Qemu-devel] [RFC] host and guest kernel trace merging
> >   https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg00887.html
> > 
> > Today, the only way to retrieve a VM's TSC offset is
> > by using the kvm_write_tsc_offset tracepoint. This has
> > a few problems. First, the tracepoint is only emitted
> > when the VM boots, which requires a reboot to get it if
> > the VM is already running. Second, tracepoints are not
> > supposed to be ABIs in case they need to be consumed by
> > user-space tools.
> > 
> > This commit exports a VM's TSC offset to user-space via
> > debugfs. A new file called "tsc-offset" is created in
> > the VM's debugfs directory. For example:
> > 
> >   /sys/kernel/debug/kvm/51696-10/tsc-offset
> > 
> > This file contains one TSC offset per line, for each
> > vCPU. For example:
> > 
> >   vcpu0: 18446742405270834952
> >   vcpu1: 18446742405270834952
> >   vcpu2: 18446742405270834952
> >   vcpu3: 18446742405270834952
> > 
> > There are some important observations about this
> > solution:
> > 
> >  - While all vCPUs TSC offsets should be equal for the
> >cases we care about (ie. stable TSC and no write to
> >the TSC MSR), I chose to follow the spec and export
> >each vCPU's TSC offset (might also be helpful for
> >debugging)
> > 
> >  - The TSC offset is only useful after the VM has booted
> > 
> >  - We'll probably need to export the TSC multiplier too.
> >However, I've been using only the TSC offset for now.
> >So, let's get this merged first and do the TSC multiplier
> >as a second step
> 
> Can TSC offset changes occur at runtime?
> 
> One example is vcpu hotplug where the tracing tool would need to fetch
> the new vcpu's TSC offset after tracing has already started.
> 
> Another example is if QEMU or the guest change the TSC offset while
> running.  If the tracing tool doesn't notice this then trace events will have
> incorrect timestamps.
> 
> Stefan

Yes they can, and the interface should mention that "the user is
responsible for handling races of execution" (IMO).

So the workflow is:

1) User boots VM and knows the state of the VM.
2) User runs trace-cmd on the host.

Is there a need to automate gathering of traces? (that is to know the
state of reboots and so forth). I don't see one. In that case, the above
workflow is functional.

Can you add such comments to the interface Luiz (that the value
read is potentially stale).

Re: [PATCH 4/4] kvm: x86: export TSC offset to user-space

[Marcelo Tosatti]

On Fri, Sep 02, 2016 at 09:43:01AM -0400, Stefan Hajnoczi wrote:
> On Wed, Aug 31, 2016 at 01:05:45PM -0400, Luiz Capitulino wrote:
> > We need to retrieve a VM's TSC offset in order to use
> > the host's TSC to merge host and guest traces. This is
> > explained in detail in this thread:
> > 
> >   [Qemu-devel] [RFC] host and guest kernel trace merging
> >   https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg00887.html
> > 
> > Today, the only way to retrieve a VM's TSC offset is
> > by using the kvm_write_tsc_offset tracepoint. This has
> > a few problems. First, the tracepoint is only emitted
> > when the VM boots, which requires a reboot to get it if
> > the VM is already running. Second, tracepoints are not
> > supposed to be ABIs in case they need to be consumed by
> > user-space tools.
> > 
> > This commit exports a VM's TSC offset to user-space via
> > debugfs. A new file called "tsc-offset" is created in
> > the VM's debugfs directory. For example:
> > 
> >   /sys/kernel/debug/kvm/51696-10/tsc-offset
> > 
> > This file contains one TSC offset per line, for each
> > vCPU. For example:
> > 
> >   vcpu0: 18446742405270834952
> >   vcpu1: 18446742405270834952
> >   vcpu2: 18446742405270834952
> >   vcpu3: 18446742405270834952
> > 
> > There are some important observations about this
> > solution:
> > 
> >  - While all vCPUs TSC offsets should be equal for the
> >cases we care about (ie. stable TSC and no write to
> >the TSC MSR), I chose to follow the spec and export
> >each vCPU's TSC offset (might also be helpful for
> >debugging)
> > 
> >  - The TSC offset is only useful after the VM has booted
> > 
> >  - We'll probably need to export the TSC multiplier too.
> >However, I've been using only the TSC offset for now.
> >So, let's get this merged first and do the TSC multiplier
> >as a second step
> 
> Can TSC offset changes occur at runtime?
> 
> One example is vcpu hotplug where the tracing tool would need to fetch
> the new vcpu's TSC offset after tracing has already started.
> 
> Another example is if QEMU or the guest change the TSC offset while
> running.  If the tracing tool doesn't notice this then trace events will have
> incorrect timestamps.
> 
> Stefan

Yes they can, and the interface should mention that "the user is
responsible for handling races of execution" (IMO).

So the workflow is:

1) User boots VM and knows the state of the VM.
2) User runs trace-cmd on the host.

Is there a need to automate gathering of traces? (that is to know the
state of reboots and so forth). I don't see one. In that case, the above
workflow is functional.

Can you add such comments to the interface Luiz (that the value
read is potentially stale).

Re: [RFC 1/3] x86/vdso: create vdso file, use it for mapping

[Al Viro]

On Thu, Aug 25, 2016 at 06:21:08PM +0300, Dmitry Safonov wrote:
> + unsigned long n_addr = mmap_region(vdso_file_64, text_start,
> + image->size, VM_READ|VM_EXEC|
> + VM_DONTEXPAND|VM_SOFTDIRTY|
> + VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC, 0);
> + if (text_start != n_addr) {
> + pr_err("Failed to mmap vdso file at %lx, mmap_region 
> returned %lx\n",
> + text_start, n_addr);
> + goto old_way;
> + }
> + vma = find_vma(mm, text_start);
> + if (IS_ERR(vma) || vma->vm_start != text_start) {
> + pr_err("Failed to find vdso mapped vma at %lx\n",
> + text_start);
> + goto old_way;

Umm...  Since when can find_vma() return ERR_PTR()?

> + d_set_d_op(path.dentry, _dops);

Nope.  Set ->s_d_op to _dops and be done with that.

> +static struct file_system_type vdso_fs_type = {
> + .name   = "vdsofs",
> + .mount  = ramfs_mount,

Probably the wrong thing here.  Just use a simple wrapper using mount_pseudo()
for all work; see fs/aio.c:aio_mount().

> + ret = register_filesystem(_fs_type);

Do you really want it user-mountable?  If not, no need to register...

Re: [RFC 1/3] x86/vdso: create vdso file, use it for mapping

[Al Viro]

On Thu, Aug 25, 2016 at 06:21:08PM +0300, Dmitry Safonov wrote:
> + unsigned long n_addr = mmap_region(vdso_file_64, text_start,
> + image->size, VM_READ|VM_EXEC|
> + VM_DONTEXPAND|VM_SOFTDIRTY|
> + VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC, 0);
> + if (text_start != n_addr) {
> + pr_err("Failed to mmap vdso file at %lx, mmap_region 
> returned %lx\n",
> + text_start, n_addr);
> + goto old_way;
> + }
> + vma = find_vma(mm, text_start);
> + if (IS_ERR(vma) || vma->vm_start != text_start) {
> + pr_err("Failed to find vdso mapped vma at %lx\n",
> + text_start);
> + goto old_way;

Umm...  Since when can find_vma() return ERR_PTR()?

> + d_set_d_op(path.dentry, _dops);

Nope.  Set ->s_d_op to _dops and be done with that.

> +static struct file_system_type vdso_fs_type = {
> + .name   = "vdsofs",
> + .mount  = ramfs_mount,

Probably the wrong thing here.  Just use a simple wrapper using mount_pseudo()
for all work; see fs/aio.c:aio_mount().

> + ret = register_filesystem(_fs_type);

Do you really want it user-mountable?  If not, no need to register...

Re: [RFC 1/3] x86/vdso: create vdso file, use it for mapping

[Al Viro]

On Tue, Aug 30, 2016 at 04:33:12PM +0200, Oleg Nesterov wrote:
> > +   inode = ramfs_get_inode(sb, NULL, S_IFREG | S_IRUGO | S_IXUGO, 0);

> Not sure... I think alloc_anon_inode() makes more sense.

Compared to this, you mean?  It's going to give you the wrong
permissions/i_op/a_ops, and you'll have to assign them manually.  ramfs
already gives the right ones for what's wanted, AFAICS.

Re: [PATCH v2 0/2] arm64: dts: rockchip: Support PMU for rk3399 SoCs

[Caesar Wang]

Heiko,

What do you think of it?
Maybe I need re-update these patches on next kernel, and re-test them.

On 2016年07月06日 16:05, Caesar Wang wrote:

Hello Heiko, Marc & ARM guys

When Jay first submitted the rk3399.dtsi upstream
 he had the PMU node in there,
but then took it out because the upstream binding wasn't done yet.
It looks as if the upstream stuff has landed, since in linux/master I see:
287e9357abcc DT/arm,gic-v3: Documment PPI partition support
e3825ba1af3a irqchip/gic-v3: Add support for partitioned PPIs
9e2c986cb460 irqchip: Add per-cpu interrupt partitioning library
222df54fd8b7 genirq: Allow the affinity of a percpu interrupt to be 
set/retrieved
651e8b54abde irqdomain: Allow domain matching on irq_fwspec

This series patches add to support the rk3399 SoCs PMU.
I pick up the https://patchwork.kernel.org/patch/9209369/.

As do some tests with ChromeOs for my rk3399 board.
Tested with linus master 4.7-rc6 kernel on rk3399 board.
https://github.com/Caesar-github/rockchip/tree/rk3399/pmu-upstream

localhost / # perf list

List of pre-defined events (to be used in -e):
cpu-cycles OR cycles [Hardware event]
instructions [Hardware event]
cache-references [Hardware event]
cache-misses [Hardware event]
branch-instructions OR branches [Hardware event]
branch-misses [Hardware event]
bus-cycles [Hardware event]
...

perf stat --cpu 0/1/2/3. to minitor
e.g. cpu0;

localhost / # perf stat --cpu 0

Performance counter stats for 'CPU(s) 0':

3374.917571 task-clock (msec) # 1.001 CPUs utilized [100.00%]
20 context-switches # 0.006 K/sec [100.00%]
2 cpu-migrations # 0.001 K/sec [100.00%]
55 page-faults # 0.016 K/sec
7151843 cycles # 0.002 GHz [100.00%]
 stalled-cycles-frontend
 stalled-cycles-backend
4272536 instructions # 0.60 insns per cycle [100.00%]
568406 branches # 0.168 M/sec [100.00%]
65652 branch-misses # 11.55% of all branches

Also, 'perf top' to monitor the PMU interrupts from cpus

-Caesar


Changes in v2:
- AS Mark comments on https://patchwork.kernel.org/patch/9209369/
   remove the interrupt-affinity property, we need depend on Marc' perf
   code on https://patchwork.kernel.org/patch/9209369/.

Caesar Wang (2):
   arm64: dts: rockchip: change all interrupts cells for 4 on rk3399 SoCs
   arm64: dts: rockchip: support the pmu node for rk3399

  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 118 ++-
  1 file changed, 69 insertions(+), 49 deletions(-)




--
caesar wang | software engineer | w...@rock-chip.com