Re: [PATCH 4/9] drm/i915: Delete unnecessary braces in three functions

[Jani Nikula]

On Thu, 04 May 2017, SF Markus Elfring  wrote:
> From: Markus Elfring 
> Date: Thu, 4 May 2017 13:40:53 +0200
>
> Do not use curly brackets at some source code places
> where a single statement should be sufficient.

We only tend to do this kind of changes when we're changing the
surrounding code anyway. I'm sure there are plenty of places where you
could add or remove braces, but it's not productive to go around
changing just them.

BR,
Jani.


>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 19 ---
>  1 file changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 296108464f2b..bf9a2e8d8c16 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -565,13 +565,13 @@ static int i915_gem_pageflip_info(struct seq_file *m, 
> void *data)
>   u32 addr;
>  
>   pending = atomic_read(>pending);
> - if (pending) {
> + if (pending)
>   seq_printf(m, "Flip ioctl preparing on pipe %c 
> (plane %c)\n",
>  pipe, plane);
> - } else {
> + else
>   seq_printf(m, "Flip pending (waiting for vsync) 
> on pipe %c (plane %c)\n",
>  pipe, plane);
> - }
> +
>   if (work->flip_queued_req) {
>   struct intel_engine_cs *engine = 
> work->flip_queued_req->engine;
>  
> @@ -3130,13 +3130,11 @@ static void intel_plane_info(struct seq_file *m, 
> struct intel_crtc *intel_crtc)
>   }
>  
>   state = plane->state;
> -
> - if (state->fb) {
> + if (state->fb)
>   drm_get_format_name(state->fb->format->format,
>   _name);
> - } else {
> + else
>   sprintf(format_name.str, "N/A");
> - }
>  
>   seq_printf(m, "\t--Plane id %d: type=%s, crtc_pos=%4dx%4d, 
> crtc_size=%4dx%4d, src_pos=%d.%04ux%d.%04u, src_size=%d.%04ux%d.%04u, 
> format=%s, rotation=%s\n",
>  plane->base.id,
> @@ -4636,13 +4634,12 @@ static int i915_sseu_status(struct seq_file *m, void 
> *unused)
>  
>   intel_runtime_pm_get(dev_priv);
>  
> - if (IS_CHERRYVIEW(dev_priv)) {
> + if (IS_CHERRYVIEW(dev_priv))
>   cherryview_sseu_device_status(dev_priv, );
> - } else if (IS_BROADWELL(dev_priv)) {
> + else if (IS_BROADWELL(dev_priv))
>   broadwell_sseu_device_status(dev_priv, );
> - } else if (INTEL_GEN(dev_priv) >= 9) {
> + else if (INTEL_GEN(dev_priv) >= 9)
>   gen9_sseu_device_status(dev_priv, );
> - }
>  
>   intel_runtime_pm_put(dev_priv);

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 4/9] drm/i915: Delete unnecessary braces in three functions

[Jani Nikula]

On Thu, 04 May 2017, SF Markus Elfring  wrote:
> From: Markus Elfring 
> Date: Thu, 4 May 2017 13:40:53 +0200
>
> Do not use curly brackets at some source code places
> where a single statement should be sufficient.

We only tend to do this kind of changes when we're changing the
surrounding code anyway. I'm sure there are plenty of places where you
could add or remove braces, but it's not productive to go around
changing just them.

BR,
Jani.


>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 19 ---
>  1 file changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 296108464f2b..bf9a2e8d8c16 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -565,13 +565,13 @@ static int i915_gem_pageflip_info(struct seq_file *m, 
> void *data)
>   u32 addr;
>  
>   pending = atomic_read(>pending);
> - if (pending) {
> + if (pending)
>   seq_printf(m, "Flip ioctl preparing on pipe %c 
> (plane %c)\n",
>  pipe, plane);
> - } else {
> + else
>   seq_printf(m, "Flip pending (waiting for vsync) 
> on pipe %c (plane %c)\n",
>  pipe, plane);
> - }
> +
>   if (work->flip_queued_req) {
>   struct intel_engine_cs *engine = 
> work->flip_queued_req->engine;
>  
> @@ -3130,13 +3130,11 @@ static void intel_plane_info(struct seq_file *m, 
> struct intel_crtc *intel_crtc)
>   }
>  
>   state = plane->state;
> -
> - if (state->fb) {
> + if (state->fb)
>   drm_get_format_name(state->fb->format->format,
>   _name);
> - } else {
> + else
>   sprintf(format_name.str, "N/A");
> - }
>  
>   seq_printf(m, "\t--Plane id %d: type=%s, crtc_pos=%4dx%4d, 
> crtc_size=%4dx%4d, src_pos=%d.%04ux%d.%04u, src_size=%d.%04ux%d.%04u, 
> format=%s, rotation=%s\n",
>  plane->base.id,
> @@ -4636,13 +4634,12 @@ static int i915_sseu_status(struct seq_file *m, void 
> *unused)
>  
>   intel_runtime_pm_get(dev_priv);
>  
> - if (IS_CHERRYVIEW(dev_priv)) {
> + if (IS_CHERRYVIEW(dev_priv))
>   cherryview_sseu_device_status(dev_priv, );
> - } else if (IS_BROADWELL(dev_priv)) {
> + else if (IS_BROADWELL(dev_priv))
>   broadwell_sseu_device_status(dev_priv, );
> - } else if (INTEL_GEN(dev_priv) >= 9) {
> + else if (INTEL_GEN(dev_priv) >= 9)
>   gen9_sseu_device_status(dev_priv, );
> - }
>  
>   intel_runtime_pm_put(dev_priv);

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 3/9] drm/i915: Replace 14 seq_printf() calls by seq_puts()

[Jani Nikula]

On Thu, 04 May 2017, Chris Wilson  wrote:
> On Thu, May 04, 2017 at 06:54:16PM +0200, SF Markus Elfring wrote:
>> From: Markus Elfring 
>> Date: Thu, 4 May 2017 13:20:47 +0200
>> 
>> Some strings which did not contain data format specifications should be put
>> into a sequence. Thus use the corresponding function "seq_puts".
>
> debugfs / seq_file is not performance critical. Familiar idiomatic code is
> much preferred over continually switching between seq_printf and seq_puts.
>
> And don't even start on converting seq_printf / seq_puts to seq_putc...

Agreed. I don't want any of the seq_* changes in this series.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 3/9] drm/i915: Replace 14 seq_printf() calls by seq_puts()

[Jani Nikula]

On Thu, 04 May 2017, Chris Wilson  wrote:
> On Thu, May 04, 2017 at 06:54:16PM +0200, SF Markus Elfring wrote:
>> From: Markus Elfring 
>> Date: Thu, 4 May 2017 13:20:47 +0200
>> 
>> Some strings which did not contain data format specifications should be put
>> into a sequence. Thus use the corresponding function "seq_puts".
>
> debugfs / seq_file is not performance critical. Familiar idiomatic code is
> much preferred over continually switching between seq_printf and seq_puts.
>
> And don't even start on converting seq_printf / seq_puts to seq_putc...

Agreed. I don't want any of the seq_* changes in this series.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 6/9] drm/i915: Add spaces for better code readability

[Jani Nikula]

On Thu, 04 May 2017, SF Markus Elfring  wrote:
> From: Markus Elfring 
> Date: Thu, 4 May 2017 14:04:38 +0200
>
> Use space characters at some source code places according to
> the Linux coding style convention.

LGTM. Frankly the only concern I have with accepting this patch is that
it encourages you and others to submit more patches like
this. Generally, we do this kind of changes only when touching the
nearby code for some real changes.

BR,
Jani.

>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index d9c699d7245e..6f3119d40c50 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2358,7 +2358,7 @@ static int i915_llc(struct seq_file *m, void *data)
>  
>   seq_printf(m, "LLC: %s\n", yesno(HAS_LLC(dev_priv)));
>   seq_printf(m, "%s: %lluMB\n", edram ? "eDRAM" : "eLLC",
> -intel_uncore_edram_size(dev_priv)/1024/1024);
> +intel_uncore_edram_size(dev_priv) / 1024 / 1024);
>  
>   return 0;
>  }
> @@ -4502,7 +4502,7 @@ static void gen9_sseu_device_status(struct 
> drm_i915_private *dev_priv,
>  {
>   int s_max = 3, ss_max = 4;
>   int s, ss;
> - u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
> + u32 s_reg[s_max], eu_reg[2 * s_max], eu_mask[2];
>  
>   /* BXT has a single slice and at most 3 subslices. */
>   if (IS_GEN9_LP(dev_priv)) {
> @@ -4512,8 +4512,8 @@ static void gen9_sseu_device_status(struct 
> drm_i915_private *dev_priv,
>  
>   for (s = 0; s < s_max; s++) {
>   s_reg[s] = I915_READ(GEN9_SLICE_PGCTL_ACK(s));
> - eu_reg[2*s] = I915_READ(GEN9_SS01_EU_PGCTL_ACK(s));
> - eu_reg[2*s + 1] = I915_READ(GEN9_SS23_EU_PGCTL_ACK(s));
> + eu_reg[2 * s] = I915_READ(GEN9_SS01_EU_PGCTL_ACK(s));
> + eu_reg[2 * s + 1] = I915_READ(GEN9_SS23_EU_PGCTL_ACK(s));
>   }
>  
>   eu_mask[0] = GEN9_PGCTL_SSA_EU08_ACK |
> @@ -4547,8 +4547,8 @@ static void gen9_sseu_device_status(struct 
> drm_i915_private *dev_priv,
>   sseu->subslice_mask |= BIT(ss);
>   }
>  
> - eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] &
> -eu_mask[ss%2]);
> + eu_cnt = 2 * hweight32(eu_reg[2 * s + ss / 2] &
> +eu_mask[ss % 2]);
>   sseu->eu_total += eu_cnt;
>   sseu->eu_per_subslice = max_t(unsigned int,
> sseu->eu_per_subslice,

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 6/9] drm/i915: Add spaces for better code readability

[Jani Nikula]

On Thu, 04 May 2017, SF Markus Elfring  wrote:
> From: Markus Elfring 
> Date: Thu, 4 May 2017 14:04:38 +0200
>
> Use space characters at some source code places according to
> the Linux coding style convention.

LGTM. Frankly the only concern I have with accepting this patch is that
it encourages you and others to submit more patches like
this. Generally, we do this kind of changes only when touching the
nearby code for some real changes.

BR,
Jani.

>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index d9c699d7245e..6f3119d40c50 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2358,7 +2358,7 @@ static int i915_llc(struct seq_file *m, void *data)
>  
>   seq_printf(m, "LLC: %s\n", yesno(HAS_LLC(dev_priv)));
>   seq_printf(m, "%s: %lluMB\n", edram ? "eDRAM" : "eLLC",
> -intel_uncore_edram_size(dev_priv)/1024/1024);
> +intel_uncore_edram_size(dev_priv) / 1024 / 1024);
>  
>   return 0;
>  }
> @@ -4502,7 +4502,7 @@ static void gen9_sseu_device_status(struct 
> drm_i915_private *dev_priv,
>  {
>   int s_max = 3, ss_max = 4;
>   int s, ss;
> - u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
> + u32 s_reg[s_max], eu_reg[2 * s_max], eu_mask[2];
>  
>   /* BXT has a single slice and at most 3 subslices. */
>   if (IS_GEN9_LP(dev_priv)) {
> @@ -4512,8 +4512,8 @@ static void gen9_sseu_device_status(struct 
> drm_i915_private *dev_priv,
>  
>   for (s = 0; s < s_max; s++) {
>   s_reg[s] = I915_READ(GEN9_SLICE_PGCTL_ACK(s));
> - eu_reg[2*s] = I915_READ(GEN9_SS01_EU_PGCTL_ACK(s));
> - eu_reg[2*s + 1] = I915_READ(GEN9_SS23_EU_PGCTL_ACK(s));
> + eu_reg[2 * s] = I915_READ(GEN9_SS01_EU_PGCTL_ACK(s));
> + eu_reg[2 * s + 1] = I915_READ(GEN9_SS23_EU_PGCTL_ACK(s));
>   }
>  
>   eu_mask[0] = GEN9_PGCTL_SSA_EU08_ACK |
> @@ -4547,8 +4547,8 @@ static void gen9_sseu_device_status(struct 
> drm_i915_private *dev_priv,
>   sseu->subslice_mask |= BIT(ss);
>   }
>  
> - eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] &
> -eu_mask[ss%2]);
> + eu_cnt = 2 * hweight32(eu_reg[2 * s + ss / 2] &
> +eu_mask[ss % 2]);
>   sseu->eu_total += eu_cnt;
>   sseu->eu_per_subslice = max_t(unsigned int,
> sseu->eu_per_subslice,

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 5/9] drm/i915: Adjust seven checks for null pointers

[Jani Nikula]

On Thu, 04 May 2017, SF Markus Elfring  wrote:
> From: Markus Elfring 
> Date: Thu, 4 May 2017 13:52:19 +0200
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> The script “checkpatch.pl” pointed information out like the following.
>
> Comparison to NULL could be written …

Could be written one way or the other. We have and accept
both. Sometimes explicit comparison with NULL is preferred, depending on
judgement, not based on what a tool says.

BR,
Jani.


>
> Thus fix affected source code places.
>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index bf9a2e8d8c16..d9c699d7245e 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -242,7 +242,7 @@ static int i915_gem_stolen_list_info(struct seq_file *m, 
> void *data)
>   if (count == total)
>   break;
>  
> - if (obj->stolen == NULL)
> + if (!obj->stolen)
>   continue;
>  
>   objects[count++] = obj;
> @@ -254,7 +254,7 @@ static int i915_gem_stolen_list_info(struct seq_file *m, 
> void *data)
>   if (count == total)
>   break;
>  
> - if (obj->stolen == NULL)
> + if (!obj->stolen)
>   continue;
>  
>   objects[count++] = obj;
> @@ -557,7 +557,7 @@ static int i915_gem_pageflip_info(struct seq_file *m, 
> void *data)
>  
>   spin_lock_irq(>event_lock);
>   work = crtc->flip_work;
> - if (work == NULL) {
> + if (!work) {
>   seq_printf(m, "No flip due on pipe %c (plane %c)\n",
>  pipe, plane);
>   } else {
> @@ -3717,7 +3717,7 @@ static ssize_t 
> i915_displayport_test_active_write(struct file *file,
>   continue;
>  
>   if (connector->status == connector_status_connected &&
> - connector->encoder != NULL) {
> + connector->encoder) {
>   intel_dp = enc_to_intel_dp(connector->encoder);
>   status = kstrtoint(input_buffer, 10, );
>   if (status < 0)
> @@ -3756,7 +3756,7 @@ static int i915_displayport_test_active_show(struct 
> seq_file *m, void *data)
>   continue;
>  
>   if (connector->status == connector_status_connected &&
> - connector->encoder != NULL) {
> + connector->encoder) {
>   intel_dp = enc_to_intel_dp(connector->encoder);
>   seq_putc(m,
>intel_dp->compliance.test_active ? '1' : '0');
> @@ -3801,7 +3801,7 @@ static int i915_displayport_test_data_show(struct 
> seq_file *m, void *data)
>   continue;
>  
>   if (connector->status == connector_status_connected &&
> - connector->encoder != NULL) {
> + connector->encoder) {
>   intel_dp = enc_to_intel_dp(connector->encoder);
>   if (intel_dp->compliance.test_type ==
>   DP_TEST_LINK_EDID_READ)
> @@ -3855,7 +3855,7 @@ static int i915_displayport_test_type_show(struct 
> seq_file *m, void *data)
>   continue;
>  
>   if (connector->status == connector_status_connected &&
> - connector->encoder != NULL) {
> + connector->encoder) {
>   intel_dp = enc_to_intel_dp(connector->encoder);
>   seq_printf(m, "%02lx", intel_dp->compliance.test_type);
>   } else {

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 5/9] drm/i915: Adjust seven checks for null pointers

[Jani Nikula]

On Thu, 04 May 2017, SF Markus Elfring  wrote:
> From: Markus Elfring 
> Date: Thu, 4 May 2017 13:52:19 +0200
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> The script “checkpatch.pl” pointed information out like the following.
>
> Comparison to NULL could be written …

Could be written one way or the other. We have and accept
both. Sometimes explicit comparison with NULL is preferred, depending on
judgement, not based on what a tool says.

BR,
Jani.


>
> Thus fix affected source code places.
>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index bf9a2e8d8c16..d9c699d7245e 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -242,7 +242,7 @@ static int i915_gem_stolen_list_info(struct seq_file *m, 
> void *data)
>   if (count == total)
>   break;
>  
> - if (obj->stolen == NULL)
> + if (!obj->stolen)
>   continue;
>  
>   objects[count++] = obj;
> @@ -254,7 +254,7 @@ static int i915_gem_stolen_list_info(struct seq_file *m, 
> void *data)
>   if (count == total)
>   break;
>  
> - if (obj->stolen == NULL)
> + if (!obj->stolen)
>   continue;
>  
>   objects[count++] = obj;
> @@ -557,7 +557,7 @@ static int i915_gem_pageflip_info(struct seq_file *m, 
> void *data)
>  
>   spin_lock_irq(>event_lock);
>   work = crtc->flip_work;
> - if (work == NULL) {
> + if (!work) {
>   seq_printf(m, "No flip due on pipe %c (plane %c)\n",
>  pipe, plane);
>   } else {
> @@ -3717,7 +3717,7 @@ static ssize_t 
> i915_displayport_test_active_write(struct file *file,
>   continue;
>  
>   if (connector->status == connector_status_connected &&
> - connector->encoder != NULL) {
> + connector->encoder) {
>   intel_dp = enc_to_intel_dp(connector->encoder);
>   status = kstrtoint(input_buffer, 10, );
>   if (status < 0)
> @@ -3756,7 +3756,7 @@ static int i915_displayport_test_active_show(struct 
> seq_file *m, void *data)
>   continue;
>  
>   if (connector->status == connector_status_connected &&
> - connector->encoder != NULL) {
> + connector->encoder) {
>   intel_dp = enc_to_intel_dp(connector->encoder);
>   seq_putc(m,
>intel_dp->compliance.test_active ? '1' : '0');
> @@ -3801,7 +3801,7 @@ static int i915_displayport_test_data_show(struct 
> seq_file *m, void *data)
>   continue;
>  
>   if (connector->status == connector_status_connected &&
> - connector->encoder != NULL) {
> + connector->encoder) {
>   intel_dp = enc_to_intel_dp(connector->encoder);
>   if (intel_dp->compliance.test_type ==
>   DP_TEST_LINK_EDID_READ)
> @@ -3855,7 +3855,7 @@ static int i915_displayport_test_type_show(struct 
> seq_file *m, void *data)
>   continue;
>  
>   if (connector->status == connector_status_connected &&
> - connector->encoder != NULL) {
> + connector->encoder) {
>   intel_dp = enc_to_intel_dp(connector->encoder);
>   seq_printf(m, "%02lx", intel_dp->compliance.test_type);
>   } else {

-- 
Jani Nikula, Intel Open Source Technology Center

RE: [PATCH v3] drivers:soc:fsl:qbman:qman.c: Sleep instead of stuck hacking jiffies.

[Karim Eshapa]

Use msleep() instead of stucking with
long delay will be more efficient.

Signed-off-by: Karim Eshapa 
---
 drivers/soc/fsl/qbman/qman.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
index 3d891db..18d391e 100644
--- a/drivers/soc/fsl/qbman/qman.c
+++ b/drivers/soc/fsl/qbman/qman.c
@@ -1084,11 +1084,7 @@ static int drain_mr_fqrni(struct qm_portal *p)
 * entries well before the ring has been fully consumed, so
 * we're being *really* paranoid here.
 */
-   u64 now, then = jiffies;
-
-   do {
-   now = jiffies;
-   } while ((then + 1) > now);
+   msleep(1);
msg = qm_mr_current(p);
if (!msg)
return 0;
-- 
2.7.4

RE: [PATCH v3] drivers:soc:fsl:qbman:qman.c: Sleep instead of stuck hacking jiffies.

[Karim Eshapa]

Use msleep() instead of stucking with
long delay will be more efficient.

Signed-off-by: Karim Eshapa 
---
 drivers/soc/fsl/qbman/qman.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
index 3d891db..18d391e 100644
--- a/drivers/soc/fsl/qbman/qman.c
+++ b/drivers/soc/fsl/qbman/qman.c
@@ -1084,11 +1084,7 @@ static int drain_mr_fqrni(struct qm_portal *p)
 * entries well before the ring has been fully consumed, so
 * we're being *really* paranoid here.
 */
-   u64 now, then = jiffies;
-
-   do {
-   now = jiffies;
-   } while ((then + 1) > now);
+   msleep(1);
msg = qm_mr_current(p);
if (!msg)
return 0;
-- 
2.7.4

Re: [PATCH v8 1/5] x86: add simple udelay calibration

[Lu Baolu]

Hi,

On 05/03/2017 06:38 AM, Boris Ostrovsky wrote:
> On 03/21/2017 04:01 AM, Lu Baolu wrote:
>> Add a simple udelay calibration in x86 architecture-specific
>> boot-time initializations. This will get a workable estimate
>> for loops_per_jiffy. Hence, udelay() could be used after this
>> initialization.
> This breaks Xen PV guests since at this point, and until
> x86_init.paging.pagetable_init() which is when pvclock_vcpu_time_info is
> mapped, they cannot access pvclock.
>
> Is it reasonable to do this before tsc_init() is called? (The failure
> has nothing to do with tsc_init(), really --- it's just that it is
> called late enough that Xen PV guests get properly initialized.) If it
> is, would it be possible to move simple_udelay_calibration() after
> x86_init.paging.pagetable_init()?

This is currently only used for bare metal. How about by-pass it
for Xen PV guests?

Best regards,
Lu Baolu

>
> -boris
>
>
>> Cc: Ingo Molnar 
>> Cc: x...@kernel.org
>> Signed-off-by: Lu Baolu 
>> ---
>>  arch/x86/kernel/setup.c | 22 ++
>>  1 file changed, 22 insertions(+)
>>
>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>> index 4bf0c89..e70204e 100644
>> --- a/arch/x86/kernel/setup.c
>> +++ b/arch/x86/kernel/setup.c
>> @@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self, 
>> unsigned long v, void *p)
>>  return 0;
>>  }
>>  
>> +static void __init simple_udelay_calibration(void)
>> +{
>> +unsigned int tsc_khz, cpu_khz;
>> +unsigned long lpj;
>> +
>> +if (!boot_cpu_has(X86_FEATURE_TSC))
>> +return;
>> +
>> +cpu_khz = x86_platform.calibrate_cpu();
>> +tsc_khz = x86_platform.calibrate_tsc();
>> +
>> +tsc_khz = tsc_khz ? : cpu_khz;
>> +if (!tsc_khz)
>> +return;
>> +
>> +lpj = tsc_khz * 1000;
>> +do_div(lpj, HZ);
>> +loops_per_jiffy = lpj;
>> +}
>> +
>>  /*
>>   * Determine if we were loaded by an EFI loader.  If so, then we have also 
>> been
>>   * passed the efi memmap, systab, etc., so we should use these data 
>> structures
>> @@ -985,6 +1005,8 @@ void __init setup_arch(char **cmdline_p)
>>   */
>>  x86_configure_nx();
>>  
>> +simple_udelay_calibration();
>> +
>>  parse_early_param();
>>  
>>  #ifdef CONFIG_MEMORY_HOTPLUG
>

Re: [PATCH v8 1/5] x86: add simple udelay calibration

[Lu Baolu]

Hi,

On 05/03/2017 06:38 AM, Boris Ostrovsky wrote:
> On 03/21/2017 04:01 AM, Lu Baolu wrote:
>> Add a simple udelay calibration in x86 architecture-specific
>> boot-time initializations. This will get a workable estimate
>> for loops_per_jiffy. Hence, udelay() could be used after this
>> initialization.
> This breaks Xen PV guests since at this point, and until
> x86_init.paging.pagetable_init() which is when pvclock_vcpu_time_info is
> mapped, they cannot access pvclock.
>
> Is it reasonable to do this before tsc_init() is called? (The failure
> has nothing to do with tsc_init(), really --- it's just that it is
> called late enough that Xen PV guests get properly initialized.) If it
> is, would it be possible to move simple_udelay_calibration() after
> x86_init.paging.pagetable_init()?

This is currently only used for bare metal. How about by-pass it
for Xen PV guests?

Best regards,
Lu Baolu

>
> -boris
>
>
>> Cc: Ingo Molnar 
>> Cc: x...@kernel.org
>> Signed-off-by: Lu Baolu 
>> ---
>>  arch/x86/kernel/setup.c | 22 ++
>>  1 file changed, 22 insertions(+)
>>
>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>> index 4bf0c89..e70204e 100644
>> --- a/arch/x86/kernel/setup.c
>> +++ b/arch/x86/kernel/setup.c
>> @@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self, 
>> unsigned long v, void *p)
>>  return 0;
>>  }
>>  
>> +static void __init simple_udelay_calibration(void)
>> +{
>> +unsigned int tsc_khz, cpu_khz;
>> +unsigned long lpj;
>> +
>> +if (!boot_cpu_has(X86_FEATURE_TSC))
>> +return;
>> +
>> +cpu_khz = x86_platform.calibrate_cpu();
>> +tsc_khz = x86_platform.calibrate_tsc();
>> +
>> +tsc_khz = tsc_khz ? : cpu_khz;
>> +if (!tsc_khz)
>> +return;
>> +
>> +lpj = tsc_khz * 1000;
>> +do_div(lpj, HZ);
>> +loops_per_jiffy = lpj;
>> +}
>> +
>>  /*
>>   * Determine if we were loaded by an EFI loader.  If so, then we have also 
>> been
>>   * passed the efi memmap, systab, etc., so we should use these data 
>> structures
>> @@ -985,6 +1005,8 @@ void __init setup_arch(char **cmdline_p)
>>   */
>>  x86_configure_nx();
>>  
>> +simple_udelay_calibration();
>> +
>>  parse_early_param();
>>  
>>  #ifdef CONFIG_MEMORY_HOTPLUG
>

[PATCH v2] staging: lustre: cleanup le32 assignment to ldp_flags

[Valentin Vidic]

Introduces a local var to collect flags and convert
them to le32.

Fixes the following sparse warnings:

drivers/staging/lustre/lustre/lmv/lmv_obd.c:2305:23: warning: invalid 
assignment: |=
drivers/staging/lustre/lustre/lmv/lmv_obd.c:2305:23:left side has type 
restricted __le32
drivers/staging/lustre/lustre/lmv/lmv_obd.c:2305:23:right side has type int
drivers/staging/lustre/lustre/lmv/lmv_obd.c:2383:39: warning: invalid 
assignment: |=
drivers/staging/lustre/lustre/lmv/lmv_obd.c:2383:39:left side has type 
restricted __le32
drivers/staging/lustre/lustre/lmv/lmv_obd.c:2383:39:right side has type int

Signed-off-by: Valentin Vidic 
---
Changes in v2: use a local var to collect flags

 drivers/staging/lustre/lustre/lmv/lmv_obd.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/lustre/lustre/lmv/lmv_obd.c 
b/drivers/staging/lustre/lustre/lmv/lmv_obd.c
index 09b469243d73..bec8c1948fa0 100644
--- a/drivers/staging/lustre/lustre/lmv/lmv_obd.c
+++ b/drivers/staging/lustre/lustre/lmv/lmv_obd.c
@@ -2275,6 +2275,7 @@ static int lmv_read_striped_page(struct obd_export *exp,
struct lu_fid master_fid = op_data->op_fid1;
struct obd_device *obd = exp->exp_obd;
__u64 hash_offset = offset;
+   __u32 ldp_flags;
struct page *min_ent_page = NULL;
struct page *ent_page = NULL;
struct lu_dirent *min_ent = NULL;
@@ -2302,7 +2303,7 @@ static int lmv_read_striped_page(struct obd_export *exp,
dp = kmap(ent_page);
memset(dp, 0, sizeof(*dp));
dp->ldp_hash_start = cpu_to_le64(offset);
-   dp->ldp_flags |= LDF_COLLIDE;
+   ldp_flags = LDF_COLLIDE;
 
area = dp + 1;
left_bytes = PAGE_SIZE - sizeof(*dp);
@@ -2380,8 +2381,8 @@ static int lmv_read_striped_page(struct obd_export *exp,
ent_page = NULL;
} else {
if (ent == area)
-   dp->ldp_flags |= LDF_EMPTY;
-   dp->ldp_flags = cpu_to_le32(dp->ldp_flags);
+   ldp_flags |= LDF_EMPTY;
+   dp->ldp_flags |= cpu_to_le32(ldp_flags);
dp->ldp_hash_end = cpu_to_le64(hash_offset);
}
 
-- 
2.11.0

[PATCH v2] staging: lustre: cleanup le32 assignment to ldp_flags

[Valentin Vidic]

Introduces a local var to collect flags and convert
them to le32.

Fixes the following sparse warnings:

drivers/staging/lustre/lustre/lmv/lmv_obd.c:2305:23: warning: invalid 
assignment: |=
drivers/staging/lustre/lustre/lmv/lmv_obd.c:2305:23:left side has type 
restricted __le32
drivers/staging/lustre/lustre/lmv/lmv_obd.c:2305:23:right side has type int
drivers/staging/lustre/lustre/lmv/lmv_obd.c:2383:39: warning: invalid 
assignment: |=
drivers/staging/lustre/lustre/lmv/lmv_obd.c:2383:39:left side has type 
restricted __le32
drivers/staging/lustre/lustre/lmv/lmv_obd.c:2383:39:right side has type int

Signed-off-by: Valentin Vidic 
---
Changes in v2: use a local var to collect flags

 drivers/staging/lustre/lustre/lmv/lmv_obd.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/lustre/lustre/lmv/lmv_obd.c 
b/drivers/staging/lustre/lustre/lmv/lmv_obd.c
index 09b469243d73..bec8c1948fa0 100644
--- a/drivers/staging/lustre/lustre/lmv/lmv_obd.c
+++ b/drivers/staging/lustre/lustre/lmv/lmv_obd.c
@@ -2275,6 +2275,7 @@ static int lmv_read_striped_page(struct obd_export *exp,
struct lu_fid master_fid = op_data->op_fid1;
struct obd_device *obd = exp->exp_obd;
__u64 hash_offset = offset;
+   __u32 ldp_flags;
struct page *min_ent_page = NULL;
struct page *ent_page = NULL;
struct lu_dirent *min_ent = NULL;
@@ -2302,7 +2303,7 @@ static int lmv_read_striped_page(struct obd_export *exp,
dp = kmap(ent_page);
memset(dp, 0, sizeof(*dp));
dp->ldp_hash_start = cpu_to_le64(offset);
-   dp->ldp_flags |= LDF_COLLIDE;
+   ldp_flags = LDF_COLLIDE;
 
area = dp + 1;
left_bytes = PAGE_SIZE - sizeof(*dp);
@@ -2380,8 +2381,8 @@ static int lmv_read_striped_page(struct obd_export *exp,
ent_page = NULL;
} else {
if (ent == area)
-   dp->ldp_flags |= LDF_EMPTY;
-   dp->ldp_flags = cpu_to_le32(dp->ldp_flags);
+   ldp_flags |= LDF_EMPTY;
+   dp->ldp_flags |= cpu_to_le32(ldp_flags);
dp->ldp_hash_end = cpu_to_le64(hash_offset);
}
 
-- 
2.11.0

Question about SOCK_SEQPACKET

[Sam Kumar]

Hello,
I have recently had occasion to use SOCK_SEQPACKET sockets on Linux,
and noticed some odd behavior. When using sendmsg and recvmsg with
these sockets, it seems that the "end-of-record" flag (MSG_EOR) is not
being propagated correctly.

The man page for recvmsg(2) states:
> The  msg_flags  field  in the msghdr is set on return of recvmsg().  It
>can contain several flags:
>
>MSG_EOR
>   indicates end-of-record; the data returned  completed  a  record
>   (generally used with sockets of type SOCK_SEQPACKET).
>

The man page for recvmsg(3) states:
> For
>   message-based  sockets,  such as SOCK_DGRAM and SOCK_SEQPACKET, the 
> entire
>   message shall be read in a single operation.



This leads me to believe that MSG_EOR should be set in the msghdr
struct whenever recvmsg() returns data. However, I am not observing
this flag ever being set, whether or not I set the MSG_EOR when
sending the messages.

If it helps you can take a look at the code I'm using. It is at
https://github.com/samkumar/seqpacket-test/, commit
2a7dbc1f94bafce6950ee726bdd54da96945d083 (HEAD of master at the time
of writing). Look at server.c and client.c (don't bother with
goclient.go).

The reason that I need to check MSG_EOR is that I need to distinguish
between EOF and messages of length 0. For SOCK_STREAM sockets, a
return value of 0 unambiguously means EOF, and for SOCK_DGRAM sockets
a return value of 0 unambiguously means that a datagram of length 0
was received.

Because SOCK_SEQPACKET is both connection-based and message-oriented,
a return value of 0 is ambiguous. Based on my reading of the man
pages, reading the MSG_EOR bit would let me disambiguate between EOF
and a zero-length datagram, because MSG_EOR would be set for a
zero-length datagram, but would not be set for EOF.

If someone could please help me understand MSG_EOR, and how to
distinguish between EOF and zero-length messages in a SOCK_SEQPACKET
connection, I would definitely appreciate it!

Thanks,
Sam Kumar

Question about SOCK_SEQPACKET

[Sam Kumar]

Hello,
I have recently had occasion to use SOCK_SEQPACKET sockets on Linux,
and noticed some odd behavior. When using sendmsg and recvmsg with
these sockets, it seems that the "end-of-record" flag (MSG_EOR) is not
being propagated correctly.

The man page for recvmsg(2) states:
> The  msg_flags  field  in the msghdr is set on return of recvmsg().  It
>can contain several flags:
>
>MSG_EOR
>   indicates end-of-record; the data returned  completed  a  record
>   (generally used with sockets of type SOCK_SEQPACKET).
>

The man page for recvmsg(3) states:
> For
>   message-based  sockets,  such as SOCK_DGRAM and SOCK_SEQPACKET, the 
> entire
>   message shall be read in a single operation.



This leads me to believe that MSG_EOR should be set in the msghdr
struct whenever recvmsg() returns data. However, I am not observing
this flag ever being set, whether or not I set the MSG_EOR when
sending the messages.

If it helps you can take a look at the code I'm using. It is at
https://github.com/samkumar/seqpacket-test/, commit
2a7dbc1f94bafce6950ee726bdd54da96945d083 (HEAD of master at the time
of writing). Look at server.c and client.c (don't bother with
goclient.go).

The reason that I need to check MSG_EOR is that I need to distinguish
between EOF and messages of length 0. For SOCK_STREAM sockets, a
return value of 0 unambiguously means EOF, and for SOCK_DGRAM sockets
a return value of 0 unambiguously means that a datagram of length 0
was received.

Because SOCK_SEQPACKET is both connection-based and message-oriented,
a return value of 0 is ambiguous. Based on my reading of the man
pages, reading the MSG_EOR bit would let me disambiguate between EOF
and a zero-length datagram, because MSG_EOR would be set for a
zero-length datagram, but would not be set for EOF.

If someone could please help me understand MSG_EOR, and how to
distinguish between EOF and zero-length messages in a SOCK_SEQPACKET
connection, I would definitely appreciate it!

Thanks,
Sam Kumar

Re: [PATCH tip/sched/core v2] sched/rt: Simplify the IPI rt balancing logic

[Mike Galbraith]

On Fri, 2017-05-05 at 06:26 +0200, Mike Galbraith wrote:
> > To get rteval:
> > 
> >  $ git clone
> > git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rteval.git
> >  $ cd rteval
> >  $ git checkout origin/v2/master
> 
> ImportError: No module named ethtool
> 
> Where does one find the ethtool bits it seems to depend upon?

Nevermind, google found a tarball.

-Mike

Re: [PATCH tip/sched/core v2] sched/rt: Simplify the IPI rt balancing logic

[Mike Galbraith]

On Fri, 2017-05-05 at 06:26 +0200, Mike Galbraith wrote:
> > To get rteval:
> > 
> >  $ git clone
> > git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rteval.git
> >  $ cd rteval
> >  $ git checkout origin/v2/master
> 
> ImportError: No module named ethtool
> 
> Where does one find the ethtool bits it seems to depend upon?

Nevermind, google found a tarball.

-Mike

Re: [PATCH 3/3] of: fix sparse warnings in fdt, irq, and resolver code

[Frank Rowand]

On 05/04/17 11:00, Rob Herring wrote:
> sparse generates the following warnings in drivers/of/:
> 
> ../drivers/of/fdt.c:63:36: warning: cast to restricted __be32
> ../drivers/of/fdt.c:68:33: warning: cast to restricted __be32
> ../drivers/of/irq.c:105:88: warning: incorrect type in initializer (different 
> base types)
> ../drivers/of/irq.c:105:88:expected restricted __be32
> ../drivers/of/irq.c:105:88:got int
> ../drivers/of/irq.c:526:35: warning: incorrect type in assignment (different 
> modifiers)
> ../drivers/of/irq.c:526:35:expected int ( *const [usertype] irq_init_cb 
> )( ... )
> ../drivers/of/irq.c:526:35:got void const *const data
> ../drivers/of/resolver.c:95:42: warning: incorrect type in assignment 
> (different base types)
> ../drivers/of/resolver.c:95:42:expected unsigned int [unsigned] 
> [usertype] 
> ../drivers/of/resolver.c:95:42:got restricted __be32 [usertype] 
> 
> All these are harmless type mismatches fixed by adjusting the types.
> 
> Signed-off-by: Rob Herring 
> ---
>  drivers/of/fdt.c   | 4 ++--
>  drivers/of/irq.c   | 2 +-
>  drivers/of/resolver.c  | 2 +-
>  include/linux/of_irq.h | 2 +-
>  4 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index e33f7818bc6c..a0972219ccfc 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -48,8 +48,8 @@ void of_fdt_limit_memory(int limit)
>   const void *val;
>   int nr_address_cells = OF_ROOT_NODE_ADDR_CELLS_DEFAULT;
>   int nr_size_cells = OF_ROOT_NODE_SIZE_CELLS_DEFAULT;
> - const uint32_t *addr_prop;
> - const uint32_t *size_prop;
> + const __be32 *addr_prop;
> + const __be32 *size_prop;
>   int root_offset;
>   int cell_size;
>  
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 7c56b72d1dc6..d11437cb1187 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -102,7 +102,7 @@ int of_irq_parse_raw(const __be32 *addr, struct 
> of_phandle_args *out_irq)
>   struct device_node *ipar, *tnode, *old = NULL, *newpar = NULL;
>   __be32 initial_match_array[MAX_PHANDLE_ARGS];
>   const __be32 *match_array = initial_match_array;
> - const __be32 *tmp, *imap, *imask, dummy_imask[] = { [0 ... 
> MAX_PHANDLE_ARGS] = ~0 };
> + const __be32 *tmp, *imap, *imask, dummy_imask[] = { [0 ... 
> MAX_PHANDLE_ARGS] = cpu_to_be32(~0) };
>   u32 intsize = 1, addrsize, newintsize = 0, newaddrsize = 0;
>   int imaplen, match, i, rc = -EINVAL;
>  
> diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
> index 7ae9863cb0a4..771f4844c781 100644
> --- a/drivers/of/resolver.c
> +++ b/drivers/of/resolver.c
> @@ -92,7 +92,7 @@ static void adjust_overlay_phandles(struct device_node 
> *overlay,
>   if (phandle == OF_PHANDLE_ILLEGAL)
>   continue;
>  
> - *(uint32_t *)prop->value = cpu_to_be32(overlay->phandle);
> + *(__be32 *)prop->value = cpu_to_be32(overlay->phandle);
>   }
>  
>   for_each_child_of_node(overlay, child)
> diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
> index 1e0deb8e8494..ec6b11deb773 100644
> --- a/include/linux/of_irq.h
> +++ b/include/linux/of_irq.h
> @@ -8,7 +8,7 @@
>  #include 
>  #include 
>  
> -typedef int (*of_irq_init_cb_t)(struct device_node *, struct device_node *);
> +typedef int const (*of_irq_init_cb_t)(struct device_node *, struct 
> device_node *);
>  
>  /*
>   * Workarounds only applied to 32bit powermac machines
> 

Reviewed-by: Frank Rowand 

Re: [PATCH 3/3] of: fix sparse warnings in fdt, irq, and resolver code

[Frank Rowand]

On 05/04/17 11:00, Rob Herring wrote:
> sparse generates the following warnings in drivers/of/:
> 
> ../drivers/of/fdt.c:63:36: warning: cast to restricted __be32
> ../drivers/of/fdt.c:68:33: warning: cast to restricted __be32
> ../drivers/of/irq.c:105:88: warning: incorrect type in initializer (different 
> base types)
> ../drivers/of/irq.c:105:88:expected restricted __be32
> ../drivers/of/irq.c:105:88:got int
> ../drivers/of/irq.c:526:35: warning: incorrect type in assignment (different 
> modifiers)
> ../drivers/of/irq.c:526:35:expected int ( *const [usertype] irq_init_cb 
> )( ... )
> ../drivers/of/irq.c:526:35:got void const *const data
> ../drivers/of/resolver.c:95:42: warning: incorrect type in assignment 
> (different base types)
> ../drivers/of/resolver.c:95:42:expected unsigned int [unsigned] 
> [usertype] 
> ../drivers/of/resolver.c:95:42:got restricted __be32 [usertype] 
> 
> All these are harmless type mismatches fixed by adjusting the types.
> 
> Signed-off-by: Rob Herring 
> ---
>  drivers/of/fdt.c   | 4 ++--
>  drivers/of/irq.c   | 2 +-
>  drivers/of/resolver.c  | 2 +-
>  include/linux/of_irq.h | 2 +-
>  4 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index e33f7818bc6c..a0972219ccfc 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -48,8 +48,8 @@ void of_fdt_limit_memory(int limit)
>   const void *val;
>   int nr_address_cells = OF_ROOT_NODE_ADDR_CELLS_DEFAULT;
>   int nr_size_cells = OF_ROOT_NODE_SIZE_CELLS_DEFAULT;
> - const uint32_t *addr_prop;
> - const uint32_t *size_prop;
> + const __be32 *addr_prop;
> + const __be32 *size_prop;
>   int root_offset;
>   int cell_size;
>  
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 7c56b72d1dc6..d11437cb1187 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -102,7 +102,7 @@ int of_irq_parse_raw(const __be32 *addr, struct 
> of_phandle_args *out_irq)
>   struct device_node *ipar, *tnode, *old = NULL, *newpar = NULL;
>   __be32 initial_match_array[MAX_PHANDLE_ARGS];
>   const __be32 *match_array = initial_match_array;
> - const __be32 *tmp, *imap, *imask, dummy_imask[] = { [0 ... 
> MAX_PHANDLE_ARGS] = ~0 };
> + const __be32 *tmp, *imap, *imask, dummy_imask[] = { [0 ... 
> MAX_PHANDLE_ARGS] = cpu_to_be32(~0) };
>   u32 intsize = 1, addrsize, newintsize = 0, newaddrsize = 0;
>   int imaplen, match, i, rc = -EINVAL;
>  
> diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
> index 7ae9863cb0a4..771f4844c781 100644
> --- a/drivers/of/resolver.c
> +++ b/drivers/of/resolver.c
> @@ -92,7 +92,7 @@ static void adjust_overlay_phandles(struct device_node 
> *overlay,
>   if (phandle == OF_PHANDLE_ILLEGAL)
>   continue;
>  
> - *(uint32_t *)prop->value = cpu_to_be32(overlay->phandle);
> + *(__be32 *)prop->value = cpu_to_be32(overlay->phandle);
>   }
>  
>   for_each_child_of_node(overlay, child)
> diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
> index 1e0deb8e8494..ec6b11deb773 100644
> --- a/include/linux/of_irq.h
> +++ b/include/linux/of_irq.h
> @@ -8,7 +8,7 @@
>  #include 
>  #include 
>  
> -typedef int (*of_irq_init_cb_t)(struct device_node *, struct device_node *);
> +typedef int const (*of_irq_init_cb_t)(struct device_node *, struct 
> device_node *);
>  
>  /*
>   * Workarounds only applied to 32bit powermac machines
> 

Reviewed-by: Frank Rowand 

Re: [PATCH 2/3] of: fix sparse warning in of_pci_range_parser_one

[Frank Rowand]

On 05/04/17 11:00, Rob Herring wrote:
> sparse gives the following warning for 'pci_space':
> 
> ../drivers/of/address.c:266:26: warning: incorrect type in assignment 
> (different base types)
> ../drivers/of/address.c:266:26:expected unsigned int [unsigned] 
> [usertype] pci_space
> ../drivers/of/address.c:266:26:got restricted __be32 const [usertype] 
> 
> 
> It appears that pci_space is only ever accessed on powerpc, so the endian
> swap is often not needed.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  drivers/of/address.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 02b2903fe9d2..72914cdfce2a 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -263,7 +263,7 @@ struct of_pci_range *of_pci_range_parser_one(struct 
> of_pci_range_parser *parser,
>   if (!parser->range || parser->range + parser->np > parser->end)
>   return NULL;
>  
> - range->pci_space = parser->range[0];
> + range->pci_space = be32_to_cpup(parser->range);
>   range->flags = of_bus_pci_get_flags(parser->range);
>   range->pci_addr = of_read_number(parser->range + 1, ns);
>   range->cpu_addr = of_translate_address(parser->node,
> 

Reviewed-by: Frank Rowand 

Re: [PATCH 2/3] of: fix sparse warning in of_pci_range_parser_one

[Frank Rowand]

On 05/04/17 11:00, Rob Herring wrote:
> sparse gives the following warning for 'pci_space':
> 
> ../drivers/of/address.c:266:26: warning: incorrect type in assignment 
> (different base types)
> ../drivers/of/address.c:266:26:expected unsigned int [unsigned] 
> [usertype] pci_space
> ../drivers/of/address.c:266:26:got restricted __be32 const [usertype] 
> 
> 
> It appears that pci_space is only ever accessed on powerpc, so the endian
> swap is often not needed.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  drivers/of/address.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 02b2903fe9d2..72914cdfce2a 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -263,7 +263,7 @@ struct of_pci_range *of_pci_range_parser_one(struct 
> of_pci_range_parser *parser,
>   if (!parser->range || parser->range + parser->np > parser->end)
>   return NULL;
>  
> - range->pci_space = parser->range[0];
> + range->pci_space = be32_to_cpup(parser->range);
>   range->flags = of_bus_pci_get_flags(parser->range);
>   range->pci_addr = of_read_number(parser->range + 1, ns);
>   range->cpu_addr = of_translate_address(parser->node,
> 

Reviewed-by: Frank Rowand 

Re: [PATCH 1/3] of: fix sparse warnings in of_find_next_cache_node

[Frank Rowand]

On 05/04/17 11:00, Rob Herring wrote:
> sparse gives a warning that 'handle' is not a __be32:
> 
> ../drivers/of/base.c:2261:61: warning: incorrect type in argument 1 
> (different base types)
> ../drivers/of/base.c:2261:61:expected restricted __be32 const [usertype] 
> *p
> ../drivers/of/base.c:2261:61:got unsigned int const [usertype] 
> *[assigned] handle
> 
> We could just change the type, but the code can be improved by using
> of_parse_phandle instead of open coding it with of_get_property and
> of_find_node_by_phandle.
> 
> Signed-off-by: Rob Herring 
> ---
>  drivers/of/base.c | 13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index d7c4629a3a2d..016f9d77d64d 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -2250,15 +2250,14 @@ EXPORT_SYMBOL_GPL(of_console_check);
>   */
>  struct device_node *of_find_next_cache_node(const struct device_node *np)
>  {
> - struct device_node *child;
> - const phandle *handle;
> + struct device_node *child, *cache_node;
>  
> - handle = of_get_property(np, "l2-cache", NULL);
> - if (!handle)
> - handle = of_get_property(np, "next-level-cache", NULL);
> + cache_node = of_parse_phandle(np, "l2-cache", 0);
> + if (!cache_node)
> + cache_node = of_parse_phandle(np, "next-level-cache", 0);
>  
> - if (handle)
> - return of_find_node_by_phandle(be32_to_cpup(handle));
> + if (cache_node)
> + return cache_node;
>  
>   /* OF on pmac has nodes instead of properties named "l2-cache"
>* beneath CPU nodes.
> 

Reviewed-by: Frank Rowand 

Re: [PATCH 1/3] of: fix sparse warnings in of_find_next_cache_node

[Frank Rowand]

On 05/04/17 11:00, Rob Herring wrote:
> sparse gives a warning that 'handle' is not a __be32:
> 
> ../drivers/of/base.c:2261:61: warning: incorrect type in argument 1 
> (different base types)
> ../drivers/of/base.c:2261:61:expected restricted __be32 const [usertype] 
> *p
> ../drivers/of/base.c:2261:61:got unsigned int const [usertype] 
> *[assigned] handle
> 
> We could just change the type, but the code can be improved by using
> of_parse_phandle instead of open coding it with of_get_property and
> of_find_node_by_phandle.
> 
> Signed-off-by: Rob Herring 
> ---
>  drivers/of/base.c | 13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index d7c4629a3a2d..016f9d77d64d 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -2250,15 +2250,14 @@ EXPORT_SYMBOL_GPL(of_console_check);
>   */
>  struct device_node *of_find_next_cache_node(const struct device_node *np)
>  {
> - struct device_node *child;
> - const phandle *handle;
> + struct device_node *child, *cache_node;
>  
> - handle = of_get_property(np, "l2-cache", NULL);
> - if (!handle)
> - handle = of_get_property(np, "next-level-cache", NULL);
> + cache_node = of_parse_phandle(np, "l2-cache", 0);
> + if (!cache_node)
> + cache_node = of_parse_phandle(np, "next-level-cache", 0);
>  
> - if (handle)
> - return of_find_node_by_phandle(be32_to_cpup(handle));
> + if (cache_node)
> + return cache_node;
>  
>   /* OF on pmac has nodes instead of properties named "l2-cache"
>* beneath CPU nodes.
> 

Reviewed-by: Frank Rowand 

[rcu:dev.2017.05.02c 78/90] arch/arm/include/asm/irq.h:39:50: error: unknown type name 'cpumask_t'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
dev.2017.05.02c
head:   b69fe94f46adfa1b76504b0cd1b9604ea04db87d
commit: 37b235df7033c20b00702b8aa30f7424fc0fb556 [78/90] rcu: Remove 
linux/cpumask.h from rcupdate.h
config: arm-imx_v6_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 37b235df7033c20b00702b8aa30f7424fc0fb556
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   In file included from arch/arm/mach-imx/devices/../mx3x.h:146:0,
from arch/arm/mach-imx/devices/../hardware.h:109,
from arch/arm/mach-imx/devices/platform-flexcan.c:8:
>> arch/arm/include/asm/irq.h:39:50: error: unknown type name 'cpumask_t'
extern void arch_trigger_cpumask_backtrace(const cpumask_t *mask,
 ^

vim +/cpumask_t +39 arch/arm/include/asm/irq.h

^1da177e4 include/asm-arm/irq.h  Linus Torvalds   2005-04-16  23  
431d2cd99 include/asm-arm/irq.h  Arnaud Patard2006-12-27  24  
#ifndef __ASSEMBLY__
431d2cd99 include/asm-arm/irq.h  Arnaud Patard2006-12-27  25  
struct irqaction;
aedceb2a4 arch/arm/include/asm/irq.h Viresh Kumar 2010-03-29  26  
struct pt_regs;
a054a8115 include/asm-arm/irq.h  Russell King 2005-11-02  27  
extern void migrate_irqs(void);
446616dbb arch/arm/include/asm/irq.h Russell King 2008-09-06  28  
446616dbb arch/arm/include/asm/irq.h Russell King 2008-09-06  29  
extern void asm_do_IRQ(unsigned int, struct pt_regs *);
a4841e39f arch/arm/include/asm/irq.h Russell King - ARM Linux 2011-07-11  30  
void handle_IRQ(unsigned int, struct pt_regs *);
446616dbb arch/arm/include/asm/irq.h Russell King 2008-09-06  31  
void init_IRQ(void);
446616dbb arch/arm/include/asm/irq.h Russell King 2008-09-06  32  
f36a3bb1a arch/arm/include/asm/irq.h Catalin Marinas  2013-01-18  33  
#ifdef CONFIG_MULTI_IRQ_HANDLER
f36a3bb1a arch/arm/include/asm/irq.h Catalin Marinas  2013-01-18  34  
extern void (*handle_arch_irq)(struct pt_regs *);
f36a3bb1a arch/arm/include/asm/irq.h Catalin Marinas  2013-01-18  35  
extern void set_handle_irq(void (*handle_irq)(struct pt_regs *));
f36a3bb1a arch/arm/include/asm/irq.h Catalin Marinas  2013-01-18  36  
#endif
f36a3bb1a arch/arm/include/asm/irq.h Catalin Marinas  2013-01-18  37  
96f0e0037 arch/arm/include/asm/irq.h Russell King 2014-09-03  38  
#ifdef CONFIG_SMP
9a01c3ed5 arch/arm/include/asm/irq.h Chris Metcalf2016-10-07 @39  
extern void arch_trigger_cpumask_backtrace(const cpumask_t *mask,
9a01c3ed5 arch/arm/include/asm/irq.h Chris Metcalf2016-10-07  40
   bool exclude_self);
9a01c3ed5 arch/arm/include/asm/irq.h Chris Metcalf2016-10-07  41  
#define arch_trigger_cpumask_backtrace arch_trigger_cpumask_backtrace
96f0e0037 arch/arm/include/asm/irq.h Russell King 2014-09-03  42  
#endif
96f0e0037 arch/arm/include/asm/irq.h Russell King 2014-09-03  43  
b4ff8389e arch/arm/include/asm/irq.h Boris Ostrovsky  2015-11-20  44  
static inline int nr_legacy_irqs(void)
b4ff8389e arch/arm/include/asm/irq.h Boris Ostrovsky  2015-11-20  45  {
b4ff8389e arch/arm/include/asm/irq.h Boris Ostrovsky  2015-11-20  46
return NR_IRQS_LEGACY;
b4ff8389e arch/arm/include/asm/irq.h Boris Ostrovsky  2015-11-20  47  }

:: The code at line 39 was first introduced by commit
:: 9a01c3ed5cdb35d9004eb92510ee6ea11b4a5f16 nmi_backtrace: add more 
trigger_*_cpu_backtrace() methods

:: TO: Chris Metcalf 
:: CC: Linus Torvalds 

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


.config.gz
Description: application/gzip

[rcu:dev.2017.05.02c 78/90] arch/arm/include/asm/irq.h:39:50: error: unknown type name 'cpumask_t'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
dev.2017.05.02c
head:   b69fe94f46adfa1b76504b0cd1b9604ea04db87d
commit: 37b235df7033c20b00702b8aa30f7424fc0fb556 [78/90] rcu: Remove 
linux/cpumask.h from rcupdate.h
config: arm-imx_v6_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 37b235df7033c20b00702b8aa30f7424fc0fb556
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   In file included from arch/arm/mach-imx/devices/../mx3x.h:146:0,
from arch/arm/mach-imx/devices/../hardware.h:109,
from arch/arm/mach-imx/devices/platform-flexcan.c:8:
>> arch/arm/include/asm/irq.h:39:50: error: unknown type name 'cpumask_t'
extern void arch_trigger_cpumask_backtrace(const cpumask_t *mask,
 ^

vim +/cpumask_t +39 arch/arm/include/asm/irq.h

^1da177e4 include/asm-arm/irq.h  Linus Torvalds   2005-04-16  23  
431d2cd99 include/asm-arm/irq.h  Arnaud Patard2006-12-27  24  
#ifndef __ASSEMBLY__
431d2cd99 include/asm-arm/irq.h  Arnaud Patard2006-12-27  25  
struct irqaction;
aedceb2a4 arch/arm/include/asm/irq.h Viresh Kumar 2010-03-29  26  
struct pt_regs;
a054a8115 include/asm-arm/irq.h  Russell King 2005-11-02  27  
extern void migrate_irqs(void);
446616dbb arch/arm/include/asm/irq.h Russell King 2008-09-06  28  
446616dbb arch/arm/include/asm/irq.h Russell King 2008-09-06  29  
extern void asm_do_IRQ(unsigned int, struct pt_regs *);
a4841e39f arch/arm/include/asm/irq.h Russell King - ARM Linux 2011-07-11  30  
void handle_IRQ(unsigned int, struct pt_regs *);
446616dbb arch/arm/include/asm/irq.h Russell King 2008-09-06  31  
void init_IRQ(void);
446616dbb arch/arm/include/asm/irq.h Russell King 2008-09-06  32  
f36a3bb1a arch/arm/include/asm/irq.h Catalin Marinas  2013-01-18  33  
#ifdef CONFIG_MULTI_IRQ_HANDLER
f36a3bb1a arch/arm/include/asm/irq.h Catalin Marinas  2013-01-18  34  
extern void (*handle_arch_irq)(struct pt_regs *);
f36a3bb1a arch/arm/include/asm/irq.h Catalin Marinas  2013-01-18  35  
extern void set_handle_irq(void (*handle_irq)(struct pt_regs *));
f36a3bb1a arch/arm/include/asm/irq.h Catalin Marinas  2013-01-18  36  
#endif
f36a3bb1a arch/arm/include/asm/irq.h Catalin Marinas  2013-01-18  37  
96f0e0037 arch/arm/include/asm/irq.h Russell King 2014-09-03  38  
#ifdef CONFIG_SMP
9a01c3ed5 arch/arm/include/asm/irq.h Chris Metcalf2016-10-07 @39  
extern void arch_trigger_cpumask_backtrace(const cpumask_t *mask,
9a01c3ed5 arch/arm/include/asm/irq.h Chris Metcalf2016-10-07  40
   bool exclude_self);
9a01c3ed5 arch/arm/include/asm/irq.h Chris Metcalf2016-10-07  41  
#define arch_trigger_cpumask_backtrace arch_trigger_cpumask_backtrace
96f0e0037 arch/arm/include/asm/irq.h Russell King 2014-09-03  42  
#endif
96f0e0037 arch/arm/include/asm/irq.h Russell King 2014-09-03  43  
b4ff8389e arch/arm/include/asm/irq.h Boris Ostrovsky  2015-11-20  44  
static inline int nr_legacy_irqs(void)
b4ff8389e arch/arm/include/asm/irq.h Boris Ostrovsky  2015-11-20  45  {
b4ff8389e arch/arm/include/asm/irq.h Boris Ostrovsky  2015-11-20  46
return NR_IRQS_LEGACY;
b4ff8389e arch/arm/include/asm/irq.h Boris Ostrovsky  2015-11-20  47  }

:: The code at line 39 was first introduced by commit
:: 9a01c3ed5cdb35d9004eb92510ee6ea11b4a5f16 nmi_backtrace: add more 
trigger_*_cpu_backtrace() methods

:: TO: Chris Metcalf 
:: CC: Linus Torvalds 

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


.config.gz
Description: application/gzip

Re: [PATCH v3] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS when running under Xen

[Juergen Gross]

Any comments?


Juergen

On 27/04/17 07:01, Juergen Gross wrote:
> When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set
> on AMD cpus.
> 
> This bug/feature bit is kind of special as it will be used very early
> when switching threads. Setting the bit and clearing it a little bit
> later leaves a critical window where things can go wrong. This time
> window has enlarged a little bit by using setup_clear_cpu_cap() instead
> of the hypervisor's set_cpu_features callback. It seems this larger
> window now makes it rather easy to hit the problem.
> 
> The proper solution is to never set the bit in case of Xen.
> 
> Signed-off-by: Juergen Gross 
> ---
>  arch/x86/kernel/cpu/amd.c   | 5 +++--
>  arch/x86/xen/enlighten_pv.c | 1 -
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index c36140d788fe..b6da6e75e3a8 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -799,8 +799,9 @@ static void init_amd(struct cpuinfo_x86 *c)
>   if (cpu_has(c, X86_FEATURE_3DNOW) || cpu_has(c, X86_FEATURE_LM))
>   set_cpu_cap(c, X86_FEATURE_3DNOWPREFETCH);
>  
> - /* AMD CPUs don't reset SS attributes on SYSRET */
> - set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
> + /* AMD CPUs don't reset SS attributes on SYSRET, Xen does. */
> + if (!cpu_has(c, X86_FEATURE_XENPV))
> + set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
>  }
>  
>  #ifdef CONFIG_X86_32
> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> index a1af4f68278f..dcfd07faf1c3 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -290,7 +290,6 @@ static bool __init xen_check_xsave(void)
>  
>  static void __init xen_init_capabilities(void)
>  {
> - setup_clear_cpu_cap(X86_BUG_SYSRET_SS_ATTRS);
>   setup_force_cpu_cap(X86_FEATURE_XENPV);
>   setup_clear_cpu_cap(X86_FEATURE_DCA);
>   setup_clear_cpu_cap(X86_FEATURE_APERFMPERF);
> 

Re: [PATCH v3] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS when running under Xen

[Juergen Gross]

Any comments?


Juergen

On 27/04/17 07:01, Juergen Gross wrote:
> When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set
> on AMD cpus.
> 
> This bug/feature bit is kind of special as it will be used very early
> when switching threads. Setting the bit and clearing it a little bit
> later leaves a critical window where things can go wrong. This time
> window has enlarged a little bit by using setup_clear_cpu_cap() instead
> of the hypervisor's set_cpu_features callback. It seems this larger
> window now makes it rather easy to hit the problem.
> 
> The proper solution is to never set the bit in case of Xen.
> 
> Signed-off-by: Juergen Gross 
> ---
>  arch/x86/kernel/cpu/amd.c   | 5 +++--
>  arch/x86/xen/enlighten_pv.c | 1 -
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index c36140d788fe..b6da6e75e3a8 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -799,8 +799,9 @@ static void init_amd(struct cpuinfo_x86 *c)
>   if (cpu_has(c, X86_FEATURE_3DNOW) || cpu_has(c, X86_FEATURE_LM))
>   set_cpu_cap(c, X86_FEATURE_3DNOWPREFETCH);
>  
> - /* AMD CPUs don't reset SS attributes on SYSRET */
> - set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
> + /* AMD CPUs don't reset SS attributes on SYSRET, Xen does. */
> + if (!cpu_has(c, X86_FEATURE_XENPV))
> + set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
>  }
>  
>  #ifdef CONFIG_X86_32
> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> index a1af4f68278f..dcfd07faf1c3 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -290,7 +290,6 @@ static bool __init xen_check_xsave(void)
>  
>  static void __init xen_init_capabilities(void)
>  {
> - setup_clear_cpu_cap(X86_BUG_SYSRET_SS_ATTRS);
>   setup_force_cpu_cap(X86_FEATURE_XENPV);
>   setup_clear_cpu_cap(X86_FEATURE_DCA);
>   setup_clear_cpu_cap(X86_FEATURE_APERFMPERF);
> 

[PATCH 1/1] selftests: sync: add config fragment for testing sync framework

[Fathi Boudra]

Unless the software synchronization objects (CONFIG_SW_SYNC) is enabled,
the sync test will fail:

Additional Information:
Running tests in sync

[RUN]   Testing sync framework
[RUN]   Executing test_alloc_timeline
[ERROR] Failure allocating timeline
[RUN]   Executing test_alloc_fence
[ERROR] Failure allocating timeline
[RUN]   Executing test_alloc_fence_negative
[ERROR] Failure allocating timeline
[RUN]   Executing test_fence_one_timeline_wait
[ERROR] Failure allocating timeline
[RUN]   Executing test_fence_one_timeline_merge
[ERROR] Failure allocating fences
[RUN]   Executing test_fence_merge_same_fence
[ERROR] Failure allocating timeline
[RUN]   Executing test_fence_multi_timeline_wait
[ERROR] Failure merging fence from various timelines
[RUN]   Executing test_stress_two_threads_shared_timeline
[ERROR] Failure allocating timeline
[RUN]   Executing test_consumer_stress_multi_producer_single_consumer
[ERROR] Failure merging fences
[ERROR] Failure creating fence
[ERROR] Failure creating fence
[ERROR] Failure creating fence
[ERROR] Failure creating fence
[ERROR] Failure creating fence
[RUN]   Executing test_merge_stress_random_merge
[ERROR] Failure creating fence
[FAIL]  sync errors: 10
selftests: sync_test [FAIL]

Add a config fragment with the relevant configuration required in order to
run the sync test.

Signed-off-by: Fathi Boudra 
---
 tools/testing/selftests/sync/config | 4 
 1 file changed, 4 insertions(+)
 create mode 100644 tools/testing/selftests/sync/config

diff --git a/tools/testing/selftests/sync/config 
b/tools/testing/selftests/sync/config
new file mode 100644
index ..1ab7e8130db2
--- /dev/null
+++ b/tools/testing/selftests/sync/config
@@ -0,0 +1,4 @@
+CONFIG_STAGING=y
+CONFIG_ANDROID=y
+CONFIG_SYNC=y
+CONFIG_SW_SYNC=y
-- 
2.11.0

[PATCH 1/1] selftests: sync: add config fragment for testing sync framework

[Fathi Boudra]

Unless the software synchronization objects (CONFIG_SW_SYNC) is enabled,
the sync test will fail:

Additional Information:
Running tests in sync

[RUN]   Testing sync framework
[RUN]   Executing test_alloc_timeline
[ERROR] Failure allocating timeline
[RUN]   Executing test_alloc_fence
[ERROR] Failure allocating timeline
[RUN]   Executing test_alloc_fence_negative
[ERROR] Failure allocating timeline
[RUN]   Executing test_fence_one_timeline_wait
[ERROR] Failure allocating timeline
[RUN]   Executing test_fence_one_timeline_merge
[ERROR] Failure allocating fences
[RUN]   Executing test_fence_merge_same_fence
[ERROR] Failure allocating timeline
[RUN]   Executing test_fence_multi_timeline_wait
[ERROR] Failure merging fence from various timelines
[RUN]   Executing test_stress_two_threads_shared_timeline
[ERROR] Failure allocating timeline
[RUN]   Executing test_consumer_stress_multi_producer_single_consumer
[ERROR] Failure merging fences
[ERROR] Failure creating fence
[ERROR] Failure creating fence
[ERROR] Failure creating fence
[ERROR] Failure creating fence
[ERROR] Failure creating fence
[RUN]   Executing test_merge_stress_random_merge
[ERROR] Failure creating fence
[FAIL]  sync errors: 10
selftests: sync_test [FAIL]

Add a config fragment with the relevant configuration required in order to
run the sync test.

Signed-off-by: Fathi Boudra 
---
 tools/testing/selftests/sync/config | 4 
 1 file changed, 4 insertions(+)
 create mode 100644 tools/testing/selftests/sync/config

diff --git a/tools/testing/selftests/sync/config 
b/tools/testing/selftests/sync/config
new file mode 100644
index ..1ab7e8130db2
--- /dev/null
+++ b/tools/testing/selftests/sync/config
@@ -0,0 +1,4 @@
+CONFIG_STAGING=y
+CONFIG_ANDROID=y
+CONFIG_SYNC=y
+CONFIG_SW_SYNC=y
-- 
2.11.0

Re: [PATCH 7/9] drm/i915: Combine substrings for a message in gen6_drpc_info()

[Dan Carpenter]

On Thu, May 04, 2017 at 09:12:32PM +0100, Chris Wilson wrote:
> On Thu, May 04, 2017 at 06:59:23PM +0200, SF Markus Elfring wrote:
> > From: Markus Elfring 
> > Date: Thu, 4 May 2017 14:15:00 +0200
> > 
> > The script "checkpatch.pl" pointed information out like the following.
> > 
> > WARNING: quoted string split across lines
> > 
> > Thus fix the affected source code place.
> > 
> > Signed-off-by: Markus Elfring 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 6f3119d40c50..dbd52ea89fb4 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -1529,8 +1529,8 @@ static int gen6_drpc_info(struct seq_file *m)
> >  
> > forcewake_count = 
> > READ_ONCE(dev_priv->uncore.fw_domain[FW_DOMAIN_ID_RENDER].wake_count);
> > if (forcewake_count) {
> > -   seq_puts(m, "RC information inaccurate because somebody "
> > -   "holds a forcewake reference \n");
> > +   seq_puts(m,
> > +"RC information inaccurate because somebody holds a 
> > forcewake reference.\n");
> 
> And now you break the 80col rule. Blind adherence to checkpatch is
> impossible.
> -Chris

No.  Checkpatch allows you to go over 80 characters to avoid splitting a
string.

regards,
dan carpenter

Re: [PATCH 7/9] drm/i915: Combine substrings for a message in gen6_drpc_info()

[Dan Carpenter]

On Thu, May 04, 2017 at 09:12:32PM +0100, Chris Wilson wrote:
> On Thu, May 04, 2017 at 06:59:23PM +0200, SF Markus Elfring wrote:
> > From: Markus Elfring 
> > Date: Thu, 4 May 2017 14:15:00 +0200
> > 
> > The script "checkpatch.pl" pointed information out like the following.
> > 
> > WARNING: quoted string split across lines
> > 
> > Thus fix the affected source code place.
> > 
> > Signed-off-by: Markus Elfring 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 6f3119d40c50..dbd52ea89fb4 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -1529,8 +1529,8 @@ static int gen6_drpc_info(struct seq_file *m)
> >  
> > forcewake_count = 
> > READ_ONCE(dev_priv->uncore.fw_domain[FW_DOMAIN_ID_RENDER].wake_count);
> > if (forcewake_count) {
> > -   seq_puts(m, "RC information inaccurate because somebody "
> > -   "holds a forcewake reference \n");
> > +   seq_puts(m,
> > +"RC information inaccurate because somebody holds a 
> > forcewake reference.\n");
> 
> And now you break the 80col rule. Blind adherence to checkpatch is
> impossible.
> -Chris

No.  Checkpatch allows you to go over 80 characters to avoid splitting a
string.

regards,
dan carpenter

Re: [PATCH 2/2] xen/input: add multi-touch support

[Oleksandr Andrushchenko]

Hi, Dmitry!

On 04/21/2017 09:40 AM, Oleksandr Andrushchenko wrote:

Hi, Dmitry!

On 04/21/2017 05:10 AM, Dmitry Torokhov wrote:

Hi Oleksandr,

On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Extend xen_kbdfront to provide multi-touch support
to unprivileged domains.

Signed-off-by: Oleksandr Andrushchenko 


---
  drivers/input/misc/xen-kbdfront.c | 142 
+-

  1 file changed, 140 insertions(+), 2 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c

index 01c27b4c3288..e5d064aaa237 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -17,6 +17,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
#include 
@@ -34,11 +35,14 @@
  struct xenkbd_info {
  struct input_dev *kbd;
  struct input_dev *ptr;
+struct input_dev *mtouch;
  struct xenkbd_page *page;
  int gref;
  int irq;
  struct xenbus_device *xbdev;
  char phys[32];
+/* current MT slot/contact ID we are injecting events in */
+int mtouch_cur_contact_id;
  };
enum { KPARAM_X, KPARAM_Y, KPARAM_CNT };
@@ -47,6 +51,12 @@ module_param_array(ptr_size, int, NULL, 0444);
  MODULE_PARM_DESC(ptr_size,
  "Pointing device width, height in pixels (default 800,600)");
  +enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
+static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
+module_param_array(mtouch_size, int, NULL, 0444);
+MODULE_PARM_DESC(ptr_size,
+"Multi-touch device width, height in pixels (default 800,600)");
+

Why do you need separate module parameters for multi-touch device?

please see below



  static int xenkbd_remove(struct xenbus_device *);
  static int xenkbd_connect_backend(struct xenbus_device *, struct 
xenkbd_info *);

  static void xenkbd_disconnect_backend(struct xenkbd_info *);
@@ -100,6 +110,60 @@ static irqreturn_t input_handler(int rq, void 
*dev_id)

  input_report_rel(dev, REL_WHEEL,
   -event->pos.rel_z);
  break;
+case XENKBD_TYPE_MTOUCH:
+dev = info->mtouch;
+if (unlikely(!dev))
+break;
+if (unlikely(event->mtouch.contact_id !=
+info->mtouch_cur_contact_id)) {

Why is this unlikely? Does contact ID changes once in 1000 packets or
even less?

Mu assumption was that regardless of the fact that we are multi-touch
device still single touches will come in more frequently
But I can remove *unlikely* if my assumption is not correct

+ info->mtouch_cur_contact_id =
+event->mtouch.contact_id;
+input_mt_slot(dev, event->mtouch.contact_id);
+}
+switch (event->mtouch.event_type) {
+case XENKBD_MT_EV_DOWN:
+input_mt_report_slot_state(dev, MT_TOOL_FINGER,
+   true);
+input_event(dev, EV_ABS, ABS_MT_POSITION_X,
+event->mtouch.u.pos.abs_x);
+input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
+event->mtouch.u.pos.abs_y);
+input_event(dev, EV_ABS, ABS_X,
+event->mtouch.u.pos.abs_x);
+input_event(dev, EV_ABS, ABS_Y,
+event->mtouch.u.pos.abs_y);
+break;
+case XENKBD_MT_EV_UP:
+input_mt_report_slot_state(dev, MT_TOOL_FINGER,
+   false);
+break;
+case XENKBD_MT_EV_MOTION:
+input_event(dev, EV_ABS, ABS_MT_POSITION_X,
+event->mtouch.u.pos.abs_x);
+input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
+event->mtouch.u.pos.abs_y);
+input_event(dev, EV_ABS, ABS_X,
+event->mtouch.u.pos.abs_x);
+input_event(dev, EV_ABS, ABS_Y,
+event->mtouch.u.pos.abs_y);
+break;
+case XENKBD_MT_EV_SYN:
+input_mt_sync_frame(dev);
+break;
+case XENKBD_MT_EV_SHAPE:
+input_event(dev, EV_ABS, ABS_MT_TOUCH_MAJOR,
+event->mtouch.u.shape.major);
+input_event(dev, EV_ABS, ABS_MT_TOUCH_MINOR,
+event->mtouch.u.shape.minor);
+break;
+case XENKBD_MT_EV_ORIENT:
+input_event(dev, EV_ABS, ABS_MT_ORIENTATION,
+event->mtouch.u.orientation);
+break;
+}
+/* only report syn when requested */
+if (event->mtouch.event_type != XENKBD_MT_EV_SYN)
+dev = NULL;
  }
  if (dev)
  input_sync(dev);
@@ -115,9 +179,9 @@ static int 

Re: [PATCH 2/2] xen/input: add multi-touch support

[Oleksandr Andrushchenko]

Hi, Dmitry!

On 04/21/2017 09:40 AM, Oleksandr Andrushchenko wrote:

Hi, Dmitry!

On 04/21/2017 05:10 AM, Dmitry Torokhov wrote:

Hi Oleksandr,

On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Extend xen_kbdfront to provide multi-touch support
to unprivileged domains.

Signed-off-by: Oleksandr Andrushchenko 


---
  drivers/input/misc/xen-kbdfront.c | 142 
+-

  1 file changed, 140 insertions(+), 2 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c

index 01c27b4c3288..e5d064aaa237 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -17,6 +17,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
#include 
@@ -34,11 +35,14 @@
  struct xenkbd_info {
  struct input_dev *kbd;
  struct input_dev *ptr;
+struct input_dev *mtouch;
  struct xenkbd_page *page;
  int gref;
  int irq;
  struct xenbus_device *xbdev;
  char phys[32];
+/* current MT slot/contact ID we are injecting events in */
+int mtouch_cur_contact_id;
  };
enum { KPARAM_X, KPARAM_Y, KPARAM_CNT };
@@ -47,6 +51,12 @@ module_param_array(ptr_size, int, NULL, 0444);
  MODULE_PARM_DESC(ptr_size,
  "Pointing device width, height in pixels (default 800,600)");
  +enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
+static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
+module_param_array(mtouch_size, int, NULL, 0444);
+MODULE_PARM_DESC(ptr_size,
+"Multi-touch device width, height in pixels (default 800,600)");
+

Why do you need separate module parameters for multi-touch device?

please see below



  static int xenkbd_remove(struct xenbus_device *);
  static int xenkbd_connect_backend(struct xenbus_device *, struct 
xenkbd_info *);

  static void xenkbd_disconnect_backend(struct xenkbd_info *);
@@ -100,6 +110,60 @@ static irqreturn_t input_handler(int rq, void 
*dev_id)

  input_report_rel(dev, REL_WHEEL,
   -event->pos.rel_z);
  break;
+case XENKBD_TYPE_MTOUCH:
+dev = info->mtouch;
+if (unlikely(!dev))
+break;
+if (unlikely(event->mtouch.contact_id !=
+info->mtouch_cur_contact_id)) {

Why is this unlikely? Does contact ID changes once in 1000 packets or
even less?

Mu assumption was that regardless of the fact that we are multi-touch
device still single touches will come in more frequently
But I can remove *unlikely* if my assumption is not correct

+ info->mtouch_cur_contact_id =
+event->mtouch.contact_id;
+input_mt_slot(dev, event->mtouch.contact_id);
+}
+switch (event->mtouch.event_type) {
+case XENKBD_MT_EV_DOWN:
+input_mt_report_slot_state(dev, MT_TOOL_FINGER,
+   true);
+input_event(dev, EV_ABS, ABS_MT_POSITION_X,
+event->mtouch.u.pos.abs_x);
+input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
+event->mtouch.u.pos.abs_y);
+input_event(dev, EV_ABS, ABS_X,
+event->mtouch.u.pos.abs_x);
+input_event(dev, EV_ABS, ABS_Y,
+event->mtouch.u.pos.abs_y);
+break;
+case XENKBD_MT_EV_UP:
+input_mt_report_slot_state(dev, MT_TOOL_FINGER,
+   false);
+break;
+case XENKBD_MT_EV_MOTION:
+input_event(dev, EV_ABS, ABS_MT_POSITION_X,
+event->mtouch.u.pos.abs_x);
+input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
+event->mtouch.u.pos.abs_y);
+input_event(dev, EV_ABS, ABS_X,
+event->mtouch.u.pos.abs_x);
+input_event(dev, EV_ABS, ABS_Y,
+event->mtouch.u.pos.abs_y);
+break;
+case XENKBD_MT_EV_SYN:
+input_mt_sync_frame(dev);
+break;
+case XENKBD_MT_EV_SHAPE:
+input_event(dev, EV_ABS, ABS_MT_TOUCH_MAJOR,
+event->mtouch.u.shape.major);
+input_event(dev, EV_ABS, ABS_MT_TOUCH_MINOR,
+event->mtouch.u.shape.minor);
+break;
+case XENKBD_MT_EV_ORIENT:
+input_event(dev, EV_ABS, ABS_MT_ORIENTATION,
+event->mtouch.u.orientation);
+break;
+}
+/* only report syn when requested */
+if (event->mtouch.event_type != XENKBD_MT_EV_SYN)
+dev = NULL;
  }
  if (dev)
  input_sync(dev);
@@ -115,9 +179,9 @@ static int xenkbd_probe(struct xenbus_device *dev,
const struct 

Re: [PATCH 1/2] xen/input: use string constants from PV protocol

[Oleksandr Andrushchenko]

Hello, Dmitry!
On 04/21/2017 09:42 AM, Oleksandr Andrushchenko wrote:

On 04/21/2017 05:11 AM, Dmitry Torokhov wrote:

On Thu, Apr 13, 2017 at 02:38:03PM +0300, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Xen input para-virtual protocol defines string constants
used by both back and frontend. Use those instead of
explicit strings in the frontend driver.

Signed-off-by: Oleksandr Andrushchenko 


I'll have to postpone it until I receive changes containing these new
string constants.

fair enough

  Otherwise it looks OK.

thank you

As all the dependencies are now merged into the kernel,
can we please proceed with this patch?


  drivers/input/misc/xen-kbdfront.c | 22 +-
  1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c

index 2fc7895373ab..01c27b4c3288 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -135,14 +135,17 @@ static int xenkbd_probe(struct xenbus_device 
*dev,

  goto error_nomem;
/* Set input abs params to match backend screen res */
-abs = xenbus_read_unsigned(dev->otherend, 
"feature-abs-pointer", 0);

-ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, "width",
+abs = xenbus_read_unsigned(dev->otherend,
+   XENKBD_FIELD_FEAT_ABS_POINTER, 0);
+ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
+  XENKBD_FIELD_WIDTH,
ptr_size[KPARAM_X]);
-ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, "height",
+ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
+  XENKBD_FIELD_HEIGHT,
ptr_size[KPARAM_Y]);
  if (abs) {
  ret = xenbus_write(XBT_NIL, dev->nodename,
-   "request-abs-pointer", "1");
+   XENKBD_FIELD_REQ_ABS_POINTER, "1");
  if (ret) {
  pr_warning("xenkbd: can't request abs-pointer");
  abs = 0;
@@ -271,14 +274,15 @@ static int xenkbd_connect_backend(struct 
xenbus_device *dev,

  xenbus_dev_fatal(dev, ret, "starting transaction");
  goto error_irqh;
  }
-ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
+ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_REF, 
"%lu",

  virt_to_gfn(info->page));
  if (ret)
  goto error_xenbus;
-ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", 
info->gref);

+ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_GREF,
+"%u", info->gref);
  if (ret)
  goto error_xenbus;
-ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
+ret = xenbus_printf(xbt, dev->nodename, 
XENKBD_FIELD_EVT_CHANNEL, "%u",

  evtchn);
  if (ret)
  goto error_xenbus;
@@ -353,7 +357,7 @@ static void xenkbd_backend_changed(struct 
xenbus_device *dev,

  }
static const struct xenbus_device_id xenkbd_ids[] = {
-{ "vkbd" },
+{ XENKBD_DRIVER_NAME },
  { "" }
  };
  @@ -390,4 +394,4 @@ module_exit(xenkbd_cleanup);
MODULE_DESCRIPTION("Xen virtual keyboard/pointer device frontend");
  MODULE_LICENSE("GPL");
-MODULE_ALIAS("xen:vkbd");
+MODULE_ALIAS("xen:" XENKBD_DRIVER_NAME);
--
2.7.4


Thank you,
Oleksandr

Thank you,
Oleksandr

Re: new ...at() flag: AT_NO_JUMPS

[Andy Lutomirski]

On Thu, May 4, 2017 at 9:39 PM, Al Viro  wrote:
> On Thu, May 04, 2017 at 08:46:49PM -0700, Linus Torvalds wrote:
>> On Thu, May 4, 2017 at 7:47 PM, Jann Horn  wrote:
>> >
>> > Thread 1 starts an AT_BENEATH path walk using an O_PATH fd
>> > pointing to /srv/www/example.org/foo; the path given to the syscall is
>> > "bar/../../../../etc/passwd". The path walk enters the "bar" directory.
>> > Thread 2 moves /srv/www/example.org/foo/bar to
>> > /srv/www/example.org/bar.
>> > Thread 1 processes the rest of the path ("../../../../etc/passwd"), never
>> > hitting /srv/www/example.org/foo in the process.
>> >
>> > I'm not really familiar with the VFS internals, but from a coarse look
>> > at the patch, it seems like it wouldn't block this?
>>
>> I think you're right.
>>
>> I guess it would be safe for the RCU case due to the sequence number
>> check, but not the non-RCU case.
>
> Yes and no...  FWIW, to exclude that it would suffice to have
> mount --rbind /src/www/example.org/foo /srv/www/example.org/foo done first.
> Then this kind of race will end up with -ENOENT due to path_connected()
> logics in follow_dotdot_rcu()/follow_dotdot().  I'm not sure about the
> intended applications, though - is that thing supposed to be used along with
> some horror like seccomp, or...?

How hard would it be for the kernel to prevent this on its own?
Asking users to do the mount --rbind seems like it's asking for users
to forget to do it.

Re: [PATCH 1/2] xen/input: use string constants from PV protocol

[Oleksandr Andrushchenko]

Hello, Dmitry!
On 04/21/2017 09:42 AM, Oleksandr Andrushchenko wrote:

On 04/21/2017 05:11 AM, Dmitry Torokhov wrote:

On Thu, Apr 13, 2017 at 02:38:03PM +0300, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Xen input para-virtual protocol defines string constants
used by both back and frontend. Use those instead of
explicit strings in the frontend driver.

Signed-off-by: Oleksandr Andrushchenko 


I'll have to postpone it until I receive changes containing these new
string constants.

fair enough

  Otherwise it looks OK.

thank you

As all the dependencies are now merged into the kernel,
can we please proceed with this patch?


  drivers/input/misc/xen-kbdfront.c | 22 +-
  1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c

index 2fc7895373ab..01c27b4c3288 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -135,14 +135,17 @@ static int xenkbd_probe(struct xenbus_device 
*dev,

  goto error_nomem;
/* Set input abs params to match backend screen res */
-abs = xenbus_read_unsigned(dev->otherend, 
"feature-abs-pointer", 0);

-ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, "width",
+abs = xenbus_read_unsigned(dev->otherend,
+   XENKBD_FIELD_FEAT_ABS_POINTER, 0);
+ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
+  XENKBD_FIELD_WIDTH,
ptr_size[KPARAM_X]);
-ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, "height",
+ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
+  XENKBD_FIELD_HEIGHT,
ptr_size[KPARAM_Y]);
  if (abs) {
  ret = xenbus_write(XBT_NIL, dev->nodename,
-   "request-abs-pointer", "1");
+   XENKBD_FIELD_REQ_ABS_POINTER, "1");
  if (ret) {
  pr_warning("xenkbd: can't request abs-pointer");
  abs = 0;
@@ -271,14 +274,15 @@ static int xenkbd_connect_backend(struct 
xenbus_device *dev,

  xenbus_dev_fatal(dev, ret, "starting transaction");
  goto error_irqh;
  }
-ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
+ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_REF, 
"%lu",

  virt_to_gfn(info->page));
  if (ret)
  goto error_xenbus;
-ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", 
info->gref);

+ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_GREF,
+"%u", info->gref);
  if (ret)
  goto error_xenbus;
-ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
+ret = xenbus_printf(xbt, dev->nodename, 
XENKBD_FIELD_EVT_CHANNEL, "%u",

  evtchn);
  if (ret)
  goto error_xenbus;
@@ -353,7 +357,7 @@ static void xenkbd_backend_changed(struct 
xenbus_device *dev,

  }
static const struct xenbus_device_id xenkbd_ids[] = {
-{ "vkbd" },
+{ XENKBD_DRIVER_NAME },
  { "" }
  };
  @@ -390,4 +394,4 @@ module_exit(xenkbd_cleanup);
MODULE_DESCRIPTION("Xen virtual keyboard/pointer device frontend");
  MODULE_LICENSE("GPL");
-MODULE_ALIAS("xen:vkbd");
+MODULE_ALIAS("xen:" XENKBD_DRIVER_NAME);
--
2.7.4


Thank you,
Oleksandr

Thank you,
Oleksandr

Re: new ...at() flag: AT_NO_JUMPS

[Andy Lutomirski]

On Thu, May 4, 2017 at 9:39 PM, Al Viro  wrote:
> On Thu, May 04, 2017 at 08:46:49PM -0700, Linus Torvalds wrote:
>> On Thu, May 4, 2017 at 7:47 PM, Jann Horn  wrote:
>> >
>> > Thread 1 starts an AT_BENEATH path walk using an O_PATH fd
>> > pointing to /srv/www/example.org/foo; the path given to the syscall is
>> > "bar/../../../../etc/passwd". The path walk enters the "bar" directory.
>> > Thread 2 moves /srv/www/example.org/foo/bar to
>> > /srv/www/example.org/bar.
>> > Thread 1 processes the rest of the path ("../../../../etc/passwd"), never
>> > hitting /srv/www/example.org/foo in the process.
>> >
>> > I'm not really familiar with the VFS internals, but from a coarse look
>> > at the patch, it seems like it wouldn't block this?
>>
>> I think you're right.
>>
>> I guess it would be safe for the RCU case due to the sequence number
>> check, but not the non-RCU case.
>
> Yes and no...  FWIW, to exclude that it would suffice to have
> mount --rbind /src/www/example.org/foo /srv/www/example.org/foo done first.
> Then this kind of race will end up with -ENOENT due to path_connected()
> logics in follow_dotdot_rcu()/follow_dotdot().  I'm not sure about the
> intended applications, though - is that thing supposed to be used along with
> some horror like seccomp, or...?

How hard would it be for the kernel to prevent this on its own?
Asking users to do the mount --rbind seems like it's asking for users
to forget to do it.

[PATCH] Staging: rtl8712: ieee80211: fixed brace coding style issue

[Jaya Durga]

Fixed coding style issue

Signed-off-by: Jaya Durga 
---
 drivers/staging/rtl8712/ieee80211.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/ieee80211.c 
b/drivers/staging/rtl8712/ieee80211.c
index d84da2b..512bf16 100644
--- a/drivers/staging/rtl8712/ieee80211.c
+++ b/drivers/staging/rtl8712/ieee80211.c
@@ -197,9 +197,10 @@ int r8712_generate_ie(struct registry_priv *pregistrypriv)
  pdev_network->rates, );
ie = r8712_set_ie(ie, _EXT_SUPPORTEDRATES_IE_, (rateLen - 8),
  (pdev_network->rates + 8), );
-   } else
+   } else {
ie = r8712_set_ie(ie, _SUPPORTEDRATES_IE_,
  rateLen, pdev_network->rates, );
+   }
/*DS parameter set*/
ie = r8712_set_ie(ie, _DSSET_IE_, 1,
  (u8 *)_network->Configuration.DSConfig, );
-- 
1.9.1

[PATCH] Staging: rtl8712: ieee80211: fixed brace coding style issue

[Jaya Durga]

Fixed coding style issue

Signed-off-by: Jaya Durga 
---
 drivers/staging/rtl8712/ieee80211.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/ieee80211.c 
b/drivers/staging/rtl8712/ieee80211.c
index d84da2b..512bf16 100644
--- a/drivers/staging/rtl8712/ieee80211.c
+++ b/drivers/staging/rtl8712/ieee80211.c
@@ -197,9 +197,10 @@ int r8712_generate_ie(struct registry_priv *pregistrypriv)
  pdev_network->rates, );
ie = r8712_set_ie(ie, _EXT_SUPPORTEDRATES_IE_, (rateLen - 8),
  (pdev_network->rates + 8), );
-   } else
+   } else {
ie = r8712_set_ie(ie, _SUPPORTEDRATES_IE_,
  rateLen, pdev_network->rates, );
+   }
/*DS parameter set*/
ie = r8712_set_ie(ie, _DSSET_IE_, 1,
  (u8 *)_network->Configuration.DSConfig, );
-- 
1.9.1

Re: new ...at() flag: AT_NO_JUMPS

[Al Viro]

On Thu, May 04, 2017 at 08:46:49PM -0700, Linus Torvalds wrote:
> On Thu, May 4, 2017 at 7:47 PM, Jann Horn  wrote:
> >
> > Thread 1 starts an AT_BENEATH path walk using an O_PATH fd
> > pointing to /srv/www/example.org/foo; the path given to the syscall is
> > "bar/../../../../etc/passwd". The path walk enters the "bar" directory.
> > Thread 2 moves /srv/www/example.org/foo/bar to
> > /srv/www/example.org/bar.
> > Thread 1 processes the rest of the path ("../../../../etc/passwd"), never
> > hitting /srv/www/example.org/foo in the process.
> >
> > I'm not really familiar with the VFS internals, but from a coarse look
> > at the patch, it seems like it wouldn't block this?
> 
> I think you're right.
> 
> I guess it would be safe for the RCU case due to the sequence number
> check, but not the non-RCU case.

Yes and no...  FWIW, to exclude that it would suffice to have
mount --rbind /src/www/example.org/foo /srv/www/example.org/foo done first.
Then this kind of race will end up with -ENOENT due to path_connected()
logics in follow_dotdot_rcu()/follow_dotdot().  I'm not sure about the
intended applications, though - is that thing supposed to be used along with
some horror like seccomp, or...?

Re: new ...at() flag: AT_NO_JUMPS

[Al Viro]

On Thu, May 04, 2017 at 08:46:49PM -0700, Linus Torvalds wrote:
> On Thu, May 4, 2017 at 7:47 PM, Jann Horn  wrote:
> >
> > Thread 1 starts an AT_BENEATH path walk using an O_PATH fd
> > pointing to /srv/www/example.org/foo; the path given to the syscall is
> > "bar/../../../../etc/passwd". The path walk enters the "bar" directory.
> > Thread 2 moves /srv/www/example.org/foo/bar to
> > /srv/www/example.org/bar.
> > Thread 1 processes the rest of the path ("../../../../etc/passwd"), never
> > hitting /srv/www/example.org/foo in the process.
> >
> > I'm not really familiar with the VFS internals, but from a coarse look
> > at the patch, it seems like it wouldn't block this?
> 
> I think you're right.
> 
> I guess it would be safe for the RCU case due to the sequence number
> check, but not the non-RCU case.

Yes and no...  FWIW, to exclude that it would suffice to have
mount --rbind /src/www/example.org/foo /srv/www/example.org/foo done first.
Then this kind of race will end up with -ENOENT due to path_connected()
logics in follow_dotdot_rcu()/follow_dotdot().  I'm not sure about the
intended applications, though - is that thing supposed to be used along with
some horror like seccomp, or...?

Re: new ...at() flag: AT_NO_JUMPS

[Andy Lutomirski]

On Thu, May 4, 2017 at 9:01 PM, Linus Torvalds
 wrote:
> On Thu, May 4, 2017 at 8:00 PM, Al Viro  wrote:
>>>
>>> That could still allow crossing mount-points, but only if they are
>>> non-bind mounts and cannot let us escape.
>>>
>>> I'm not sure if that's testable, though.
>>
>> This one isn't, unfortunately - there is no difference between bind and
>> no-bind; vfsmounts form a tree and both normal mount and bind add leaves
>> to it.  Moreover, mount -t ext2 /dev/sdc7 /mnt; mount -t ext2 /dev/sdc7 
>> /tmp/a
>> yield the same state as mount -t ext2 /dev/sdc7; mount --bind /mnt /tmp/a.
>> There is no way to tell the difference, simply because there *is* no
>> difference.  Moreover, either can be followed by umount /mnt and you'll get
>> the same state as you would have after a solitary mount of the same fs on
>> /tmp/a.
>
> Fair enough.
>
>> Ho-hum...  So:
>>
>> AT_BENEATH  AT_XDEV AT_NO_SYMLINKS
>> absolute pathname:  EXDEV
>> non-relative symlink:   EXDEV   ?   ELOOP
>> relative symlink:   ELOOP
>> .. from starting point: EXDEV
>> .. crossing mountpoint: EXDEV
>> crossing into mountpoint:   EXDEV
>>
>> 1) What should AT_XDEV do about absolute symlinks?  Nothing special?  EXDEV?
>> EXDEV if we are not on root?
>
> My mental model would say that AT_XDEV without AT_BENEATH would
> _logically_ result in "EXDEV if / is a different vfsmount", accept the
> absolute path otherwise.
>
> But honestly, just returning EXDEV unconditionally for an absolute
> symlink might just be the simpler and more straightforward thing to
> do.
>
> Because testing the particular vfsmount of / simply doesn't seem to be
> a very useful operation.  I dunno.

My intuition is that, regardless of whether it's obviously useful to
test the vfsmount, we should allow / if it's the same mount for
orthogonality and because it seems more likely to be the expected
behavior.

>
>> 3) What effect should AT_NO_SYMLINKS have upon the final component?  Same
>> as AT_SYMLINK_NOFOLLOW?
>
> I actually would suggest "error if it's followed".
>
> So if you use AT_SYMLINK_NOFOLLOW | AT_NO_SYMLINKS, then you do *not*
> get an error if the last component (but nothing before it) is a
> symlink, and the end result is the symlink itself.
>
> If you use just AT_NO_SYMLINKS, then the lack of NOFOLLOW implies that
> you'd follow the symlink to look it up, and then AT_NO_SYMLINKS means
> that you get an error (ELOOP).
>
> So the user gets to choose, and gets to basically indicate whether
> it's fine to end at a dangling symlink or not. Which is exactly what
> AT_SYMLINK_NOFOLLOW is all about.

Sounds reasonable to me.

--Andy

Re: new ...at() flag: AT_NO_JUMPS

[Andy Lutomirski]

On Thu, May 4, 2017 at 9:01 PM, Linus Torvalds
 wrote:
> On Thu, May 4, 2017 at 8:00 PM, Al Viro  wrote:
>>>
>>> That could still allow crossing mount-points, but only if they are
>>> non-bind mounts and cannot let us escape.
>>>
>>> I'm not sure if that's testable, though.
>>
>> This one isn't, unfortunately - there is no difference between bind and
>> no-bind; vfsmounts form a tree and both normal mount and bind add leaves
>> to it.  Moreover, mount -t ext2 /dev/sdc7 /mnt; mount -t ext2 /dev/sdc7 
>> /tmp/a
>> yield the same state as mount -t ext2 /dev/sdc7; mount --bind /mnt /tmp/a.
>> There is no way to tell the difference, simply because there *is* no
>> difference.  Moreover, either can be followed by umount /mnt and you'll get
>> the same state as you would have after a solitary mount of the same fs on
>> /tmp/a.
>
> Fair enough.
>
>> Ho-hum...  So:
>>
>> AT_BENEATH  AT_XDEV AT_NO_SYMLINKS
>> absolute pathname:  EXDEV
>> non-relative symlink:   EXDEV   ?   ELOOP
>> relative symlink:   ELOOP
>> .. from starting point: EXDEV
>> .. crossing mountpoint: EXDEV
>> crossing into mountpoint:   EXDEV
>>
>> 1) What should AT_XDEV do about absolute symlinks?  Nothing special?  EXDEV?
>> EXDEV if we are not on root?
>
> My mental model would say that AT_XDEV without AT_BENEATH would
> _logically_ result in "EXDEV if / is a different vfsmount", accept the
> absolute path otherwise.
>
> But honestly, just returning EXDEV unconditionally for an absolute
> symlink might just be the simpler and more straightforward thing to
> do.
>
> Because testing the particular vfsmount of / simply doesn't seem to be
> a very useful operation.  I dunno.

My intuition is that, regardless of whether it's obviously useful to
test the vfsmount, we should allow / if it's the same mount for
orthogonality and because it seems more likely to be the expected
behavior.

>
>> 3) What effect should AT_NO_SYMLINKS have upon the final component?  Same
>> as AT_SYMLINK_NOFOLLOW?
>
> I actually would suggest "error if it's followed".
>
> So if you use AT_SYMLINK_NOFOLLOW | AT_NO_SYMLINKS, then you do *not*
> get an error if the last component (but nothing before it) is a
> symlink, and the end result is the symlink itself.
>
> If you use just AT_NO_SYMLINKS, then the lack of NOFOLLOW implies that
> you'd follow the symlink to look it up, and then AT_NO_SYMLINKS means
> that you get an error (ELOOP).
>
> So the user gets to choose, and gets to basically indicate whether
> it's fine to end at a dangling symlink or not. Which is exactly what
> AT_SYMLINK_NOFOLLOW is all about.

Sounds reasonable to me.

--Andy

Re: [PATCH tip/sched/core v2] sched/rt: Simplify the IPI rt balancing logic

[Mike Galbraith]

> To get rteval:
> 
>  $ git clone 
> git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rteval.git
>  $ cd rteval
>  $ git checkout origin/v2/master

ImportError: No module named ethtool

Where does one find the ethtool bits it seems to depend upon?

-Mike

Re: [PATCH tip/sched/core v2] sched/rt: Simplify the IPI rt balancing logic

[Mike Galbraith]

> To get rteval:
> 
>  $ git clone 
> git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rteval.git
>  $ cd rteval
>  $ git checkout origin/v2/master

ImportError: No module named ethtool

Where does one find the ethtool bits it seems to depend upon?

-Mike

linux-next: Tree for May 5

[Stephen Rothwell]

Hi all,

Please do not add any v4.13 destined material in your linux-next
included branches until after v4.12-rc1 has been released.

Changes since 20170504:

The rdma tree gained a conflict against the pci tree.

The spi-nor tree lost its build failure.

Non-merge commits (relative to Linus' tree): 5017
 5511 files changed, 511077 insertions(+), 81899 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 258 trees (counting Linus' and 37 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (4ac4d584886a Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (9be3213b14d4 gconfig: remove misleading 
parentheses around a condition)
Merging arc-current/for-curr (65c02a556bc4 ARCv2: ptrace: provide regset for 
accumulator/r30 regs)
Merging arm-current/fixes (6d8059493691 ARM: 8670/1: V7M: Do not corrupt vector 
table around v7m_invalidate_l1 call)
Merging m68k-current/for-linus (f6ab4d59a5fe nubus: Add MVC and VSC video card 
definitions)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (be5c5e843c4a powerpc/64: Fix HMI exception on LE 
with CONFIG_RELOCATABLE=y)
Merging sparc/master (8c64415cc1f5 sparc: Remove redundant tests in 
boot_flags_init().)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (842be75c77cb cfg80211: make RATE_INFO_BW_20 the default)
Merging ipsec/master (9b3eb54106cf xfrm: fix stack access out of bounds with 
CONFIG_XFRM_SUB_POLICY)
Merging netfilter/master (f411af682218 Merge branch 
'ibmvnic-Updated-reset-handler-andcode-fixes')
Merging ipvs/master (c8d6c6b496dc ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (d77facb88448 brcmfmac: use local iftype 
avoiding use-after-free of virtual interface)
Merging mac80211/master (842be75c77cb cfg80211: make RATE_INFO_BW_20 the 
default)
Merging sound-current/for-linus (a5c3b32a1146 Merge tag 'asoc-v4.12' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (b9c1153f7a9c PCI: hisi: Fix DT binding 
(hisi-pcie-almost-ecam))
Merging driver-core.current/driver-core-linus (39da7c509acf Linux 4.11-rc6)
Merging tty.current/tty-linus (4f7d029b9bf0 Linux 4.11-rc7)
Merging usb.current/usb-linus (a71c9a1c779f Linux 4.11-rc5)
Merging usb-gadget-fixes/fixes (25cd9721c2b1 usb: gadget: f_hid: fix: Don't 
access hidg->req without spinlock held)
Merging usb-serial-fixes/usb-linus (c02ed2e75ef4 Linux 4.11-rc4)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (1a09b6a7c10e phy: qcom-usb-hs: Add depends on EXTCON)
Merging staging.current/staging-linus (39da7c509acf Linux 4.11-rc6)
Merging char-misc.current/char-misc-linus (c02ed2e75ef4 Linux 4.11-rc4)
Merging input-current/for-linus (0337966d121e Merge branch 'next' into 
for-linus)
Merging crypto-current/master (929562b14478 crypto: stm32 - Fix OF module alias 
information)
Merging ide/master (96297aee8bce ide: palm_bk3710: add __initdata to 
palm_bk3710_port_info)
Merging vfio-fixes/for-linus (39da7c509acf Linux 4.11-rc6)
Merging kselftest-fixes/fixes (c1ae3cfa0e89 Linux 4.11-rc1)
Merging backli

linux-next: Tree for May 5

[Stephen Rothwell]

Hi all,

Please do not add any v4.13 destined material in your linux-next
included branches until after v4.12-rc1 has been released.

Changes since 20170504:

The rdma tree gained a conflict against the pci tree.

The spi-nor tree lost its build failure.

Non-merge commits (relative to Linus' tree): 5017
 5511 files changed, 511077 insertions(+), 81899 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 258 trees (counting Linus' and 37 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (4ac4d584886a Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (9be3213b14d4 gconfig: remove misleading 
parentheses around a condition)
Merging arc-current/for-curr (65c02a556bc4 ARCv2: ptrace: provide regset for 
accumulator/r30 regs)
Merging arm-current/fixes (6d8059493691 ARM: 8670/1: V7M: Do not corrupt vector 
table around v7m_invalidate_l1 call)
Merging m68k-current/for-linus (f6ab4d59a5fe nubus: Add MVC and VSC video card 
definitions)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (be5c5e843c4a powerpc/64: Fix HMI exception on LE 
with CONFIG_RELOCATABLE=y)
Merging sparc/master (8c64415cc1f5 sparc: Remove redundant tests in 
boot_flags_init().)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (842be75c77cb cfg80211: make RATE_INFO_BW_20 the default)
Merging ipsec/master (9b3eb54106cf xfrm: fix stack access out of bounds with 
CONFIG_XFRM_SUB_POLICY)
Merging netfilter/master (f411af682218 Merge branch 
'ibmvnic-Updated-reset-handler-andcode-fixes')
Merging ipvs/master (c8d6c6b496dc ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (d77facb88448 brcmfmac: use local iftype 
avoiding use-after-free of virtual interface)
Merging mac80211/master (842be75c77cb cfg80211: make RATE_INFO_BW_20 the 
default)
Merging sound-current/for-linus (a5c3b32a1146 Merge tag 'asoc-v4.12' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (b9c1153f7a9c PCI: hisi: Fix DT binding 
(hisi-pcie-almost-ecam))
Merging driver-core.current/driver-core-linus (39da7c509acf Linux 4.11-rc6)
Merging tty.current/tty-linus (4f7d029b9bf0 Linux 4.11-rc7)
Merging usb.current/usb-linus (a71c9a1c779f Linux 4.11-rc5)
Merging usb-gadget-fixes/fixes (25cd9721c2b1 usb: gadget: f_hid: fix: Don't 
access hidg->req without spinlock held)
Merging usb-serial-fixes/usb-linus (c02ed2e75ef4 Linux 4.11-rc4)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (1a09b6a7c10e phy: qcom-usb-hs: Add depends on EXTCON)
Merging staging.current/staging-linus (39da7c509acf Linux 4.11-rc6)
Merging char-misc.current/char-misc-linus (c02ed2e75ef4 Linux 4.11-rc4)
Merging input-current/for-linus (0337966d121e Merge branch 'next' into 
for-linus)
Merging crypto-current/master (929562b14478 crypto: stm32 - Fix OF module alias 
information)
Merging ide/master (96297aee8bce ide: palm_bk3710: add __initdata to 
palm_bk3710_port_info)
Merging vfio-fixes/for-linus (39da7c509acf Linux 4.11-rc6)
Merging kselftest-fixes/fixes (c1ae3cfa0e89 Linux 4.11-rc1)
Merging backli

Re: [PATCH v7] Input: psxpad-spi - Add PlayStation 1/2 joypads via SPI interface Driver

[Tomohiro Yoshidomi]

Mr.Torokhov
Mr.Herrmann

> Anyway, I'd suggest leaving the patch unchanged. You can do the
> modification as a follow-up. It is not urgent.

I don't change now.
Please continue with the processing.

Regard.

---
Tomohiro


2017-05-05 0:09 GMT+09:00 Tomohiro Yoshidomi :
> Mr.Torokhov
> Mr.Herrmann
>
>> The FF code could be select'ed rather than conditional.
>
> Sorry, I can't understand mean well. How I to do...?
>
> I should to fix,
>
> In 'config JOYSTICK_PSXPAD_SPI',
> change 'select INPUT_POLLDEV' to
> 'select INPUT_POLLDEV
> select INPUT_FF_MEMLESS'.
>
> And
>
> In 'config JOYSTICK_PSXPAD_SPI_FF',
> remove 'select INPUT_FF_MEMLESS'.
>
> ...Can I understand in the sense?
>
> Regard.
>
>
> 2017-05-03 20:14 GMT+09:00 David Herrmann :
>> Hey
>>
>> On Mon, May 1, 2017 at 9:47 PM, Dmitry Torokhov
>>  wrote:
>>> On Sun, Apr 30, 2017 at 02:11:03PM +0900, Tomohiro Yoshidomi wrote:
 PlayStation 1/2 joypads can be connected directly to the SPI interface.

 Signed-off-by: Tomohiro Yoshidomi 
>>>
>>> Benjamin, David, I think this driver now matches the gamepad spec that
>>> we have in Drivers/input/gamepad.rst. Could you give it an one-over, as
>>> far as mappings go, otherwise I think it can be applied and merged with
>>> my 2nd pull request.
>>
>> Looks good to me:
>>
>> Acked-by: David Herrmann 
>>
>> The FF code could be select'ed rather than conditional. Everything
>> else looks fine. I didn't check the SPI internals though. Never
>> touched SPI, sorry.
>>
>> Thanks
>> David

Re: [PATCH v7] Input: psxpad-spi - Add PlayStation 1/2 joypads via SPI interface Driver

[Tomohiro Yoshidomi]

Mr.Torokhov
Mr.Herrmann

> Anyway, I'd suggest leaving the patch unchanged. You can do the
> modification as a follow-up. It is not urgent.

I don't change now.
Please continue with the processing.

Regard.

---
Tomohiro


2017-05-05 0:09 GMT+09:00 Tomohiro Yoshidomi :
> Mr.Torokhov
> Mr.Herrmann
>
>> The FF code could be select'ed rather than conditional.
>
> Sorry, I can't understand mean well. How I to do...?
>
> I should to fix,
>
> In 'config JOYSTICK_PSXPAD_SPI',
> change 'select INPUT_POLLDEV' to
> 'select INPUT_POLLDEV
> select INPUT_FF_MEMLESS'.
>
> And
>
> In 'config JOYSTICK_PSXPAD_SPI_FF',
> remove 'select INPUT_FF_MEMLESS'.
>
> ...Can I understand in the sense?
>
> Regard.
>
>
> 2017-05-03 20:14 GMT+09:00 David Herrmann :
>> Hey
>>
>> On Mon, May 1, 2017 at 9:47 PM, Dmitry Torokhov
>>  wrote:
>>> On Sun, Apr 30, 2017 at 02:11:03PM +0900, Tomohiro Yoshidomi wrote:
 PlayStation 1/2 joypads can be connected directly to the SPI interface.

 Signed-off-by: Tomohiro Yoshidomi 
>>>
>>> Benjamin, David, I think this driver now matches the gamepad spec that
>>> we have in Drivers/input/gamepad.rst. Could you give it an one-over, as
>>> far as mappings go, otherwise I think it can be applied and merged with
>>> my 2nd pull request.
>>
>> Looks good to me:
>>
>> Acked-by: David Herrmann 
>>
>> The FF code could be select'ed rather than conditional. Everything
>> else looks fine. I didn't check the SPI internals though. Never
>> touched SPI, sorry.
>>
>> Thanks
>> David

Re: [linux-next][bisected 1945bc45] build brakes for PowerPC BE configuration on LPAR

[Abdul Haleem]

On Thu, 2017-05-04 at 20:41 +1000, Nicholas Piggin wrote:
> On Thu, 04 May 2017 14:54:19 +0530
> Abdul Haleem  wrote:
> 
> > Hi,
> > 
> > linux-next build fails on BE config with next-20170424 onwards
> > 
> > the patch https://lkml.org/lkml/2017/4/20/994  fixes a similar issue
> > with kvm guest build failure.
> > 
> > arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
> > arch/powerpc/kernel/exceptions-64s.S:395: Error: operand out of range
> > (0x8280 is not between 0x and
> > 0x)
> > make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1
> > 
> > Bisection resulted with the below bad commit.
> > 
> > commit 1945bc4549e5cb1f9aa873ec29191aa54dc851d
> > Author: Nicholas Piggin 
> > Date:   Wed Apr 19 23:05:47 2017 +1000
> > 
> > powerpc/64s: Fix POWER9 machine check handler from stop state
> > 
> > Reviewed-by: Gautham R. Shenoy 
> > Reviewed-by: Mahesh J Salgaonkar 
> > Signed-off-by: Nicholas Piggin 
> > Signed-off-by: Michael Ellerman 
> > 
> >  arch/powerpc/include/asm/reg.h   |  1 +
> >  arch/powerpc/kernel/exceptions-64s.S | 79 
> > ---
> >  arch/powerpc/kernel/idle_book3s.S| 25 +
> >  3 files changed, 70 insertions(+), 35 deletions(-)
> > 
> > the BE configuration file is attached.
> > 
> 
> Thanks for the report. I wouldn't reproduce it with this config. I
> suspect the following patch should fix it, can you test?
> 
> powerpc/64s: Fix unnecessary machine check handler relocation branch
> 
> Similarly to 2563a70c3b ("powerpc/64s: Remove unnecessary relocation
> branch from idle handler"), the machine check handler has a BRANCH_TO
> from relocated to relocated code, which is unnecessary.
> 
> It has also caused build errors with some toolchains:
> 
>   arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
>   arch/powerpc/kernel/exceptions-64s.S:395: Error: operand out of range
>   (0x8280 is not between 0x and
>   0x)
> 
> Fixes: 1945bc4549 ("powerpc/64s: Fix POWER9 machine check handler from stop 
> state")
> Signed-off-by: Nicholas Piggin 
> ---
>  arch/powerpc/kernel/exceptions-64s.S | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/exceptions-64s.S 
> b/arch/powerpc/kernel/exceptions-64s.S
> index 3840a7700285..ef72065f684c 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -391,9 +391,7 @@ EXC_COMMON_BEGIN(machine_check_handle_early)
>*/
>   BEGIN_FTR_SECTION
>   rlwinm. r11,r12,47-31,30,31
> - beq-4f
> - BRANCH_TO_COMMON(r10, machine_check_idle_common)
> -4:
> + bne machine_check_idle_common
>   END_FTR_SECTION_IFSET(CPU_FTR_HVMODE | CPU_FTR_ARCH_206)
>  #endif
> 

Machine Builds and boots fine, Thanks for the patch :-)

Reported-and-tested-by : Abdul Haleem 

-- 
Regard's

Abdul Haleem
IBM Linux Technology Centre

Re: [linux-next][bisected 1945bc45] build brakes for PowerPC BE configuration on LPAR

[Abdul Haleem]

On Thu, 2017-05-04 at 20:41 +1000, Nicholas Piggin wrote:
> On Thu, 04 May 2017 14:54:19 +0530
> Abdul Haleem  wrote:
> 
> > Hi,
> > 
> > linux-next build fails on BE config with next-20170424 onwards
> > 
> > the patch https://lkml.org/lkml/2017/4/20/994  fixes a similar issue
> > with kvm guest build failure.
> > 
> > arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
> > arch/powerpc/kernel/exceptions-64s.S:395: Error: operand out of range
> > (0x8280 is not between 0x and
> > 0x)
> > make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1
> > 
> > Bisection resulted with the below bad commit.
> > 
> > commit 1945bc4549e5cb1f9aa873ec29191aa54dc851d
> > Author: Nicholas Piggin 
> > Date:   Wed Apr 19 23:05:47 2017 +1000
> > 
> > powerpc/64s: Fix POWER9 machine check handler from stop state
> > 
> > Reviewed-by: Gautham R. Shenoy 
> > Reviewed-by: Mahesh J Salgaonkar 
> > Signed-off-by: Nicholas Piggin 
> > Signed-off-by: Michael Ellerman 
> > 
> >  arch/powerpc/include/asm/reg.h   |  1 +
> >  arch/powerpc/kernel/exceptions-64s.S | 79 
> > ---
> >  arch/powerpc/kernel/idle_book3s.S| 25 +
> >  3 files changed, 70 insertions(+), 35 deletions(-)
> > 
> > the BE configuration file is attached.
> > 
> 
> Thanks for the report. I wouldn't reproduce it with this config. I
> suspect the following patch should fix it, can you test?
> 
> powerpc/64s: Fix unnecessary machine check handler relocation branch
> 
> Similarly to 2563a70c3b ("powerpc/64s: Remove unnecessary relocation
> branch from idle handler"), the machine check handler has a BRANCH_TO
> from relocated to relocated code, which is unnecessary.
> 
> It has also caused build errors with some toolchains:
> 
>   arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
>   arch/powerpc/kernel/exceptions-64s.S:395: Error: operand out of range
>   (0x8280 is not between 0x and
>   0x)
> 
> Fixes: 1945bc4549 ("powerpc/64s: Fix POWER9 machine check handler from stop 
> state")
> Signed-off-by: Nicholas Piggin 
> ---
>  arch/powerpc/kernel/exceptions-64s.S | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/exceptions-64s.S 
> b/arch/powerpc/kernel/exceptions-64s.S
> index 3840a7700285..ef72065f684c 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -391,9 +391,7 @@ EXC_COMMON_BEGIN(machine_check_handle_early)
>*/
>   BEGIN_FTR_SECTION
>   rlwinm. r11,r12,47-31,30,31
> - beq-4f
> - BRANCH_TO_COMMON(r10, machine_check_idle_common)
> -4:
> + bne machine_check_idle_common
>   END_FTR_SECTION_IFSET(CPU_FTR_HVMODE | CPU_FTR_ARCH_206)
>  #endif
> 

Machine Builds and boots fine, Thanks for the patch :-)

Reported-and-tested-by : Abdul Haleem 

-- 
Regard's

Abdul Haleem
IBM Linux Technology Centre

Re: [PATCHv4 3/3] drm/vgem: Enable dmabuf import interfaces

[Joe Perches]

On Thu, 2017-05-04 at 21:25 +0100, Chris Wilson wrote:
> On Thu, May 04, 2017 at 11:45:48AM -0700, Laura Abbott wrote:
> > 
> > Enable the GEM dma-buf import interfaces in addition to the export
> > interfaces. This lets vgem be used as a test source for other allocators
> > (e.g. Ion).
> > 
> > Reviewed-by: Chris Wilson 
> > Signed-off-by: Laura Abbott 
> > ---
> > v4: Use new drm_gem_prime_import_dev function
> > ---
> >  static const struct vm_operations_struct vgem_gem_vm_ops = {
> > @@ -114,12 +142,8 @@ static void vgem_postclose(struct drm_device *dev, 
> > struct drm_file *file)
> > kfree(vfile);
> >  }
> >  
> > -/* ioctls */
> > -
> > -static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
> > - struct drm_file *file,
> > - unsigned int *handle,
> > - unsigned long size)
> > +static struct drm_vgem_gem_object *__vgem_gem_create(struct drm_device 
> > *dev,
> > +   unsigned long size)
> 
> I'm going to guess that doesn't line up anymore. If checkpatch isn't
> complaining, then sorry for the noise.

Because of the very long identifiers, perhaps a
nicer way to write this is like:

static struct drm_vgem_gem_object *
__vgen_gem_create(struct drm_device *dev, unsigned long size);

> > +static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
> > + struct drm_file *file,
> > + unsigned int *handle,
> > + unsigned long size)
> 
> Ditto.

etc...

Re: [PATCHv4 3/3] drm/vgem: Enable dmabuf import interfaces

[Joe Perches]

On Thu, 2017-05-04 at 21:25 +0100, Chris Wilson wrote:
> On Thu, May 04, 2017 at 11:45:48AM -0700, Laura Abbott wrote:
> > 
> > Enable the GEM dma-buf import interfaces in addition to the export
> > interfaces. This lets vgem be used as a test source for other allocators
> > (e.g. Ion).
> > 
> > Reviewed-by: Chris Wilson 
> > Signed-off-by: Laura Abbott 
> > ---
> > v4: Use new drm_gem_prime_import_dev function
> > ---
> >  static const struct vm_operations_struct vgem_gem_vm_ops = {
> > @@ -114,12 +142,8 @@ static void vgem_postclose(struct drm_device *dev, 
> > struct drm_file *file)
> > kfree(vfile);
> >  }
> >  
> > -/* ioctls */
> > -
> > -static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
> > - struct drm_file *file,
> > - unsigned int *handle,
> > - unsigned long size)
> > +static struct drm_vgem_gem_object *__vgem_gem_create(struct drm_device 
> > *dev,
> > +   unsigned long size)
> 
> I'm going to guess that doesn't line up anymore. If checkpatch isn't
> complaining, then sorry for the noise.

Because of the very long identifiers, perhaps a
nicer way to write this is like:

static struct drm_vgem_gem_object *
__vgen_gem_create(struct drm_device *dev, unsigned long size);

> > +static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
> > + struct drm_file *file,
> > + unsigned int *handle,
> > + unsigned long size)
> 
> Ditto.

etc...

Re: new ...at() flag: AT_NO_JUMPS

[Linus Torvalds]

On Thu, May 4, 2017 at 8:00 PM, Al Viro  wrote:
>>
>> That could still allow crossing mount-points, but only if they are
>> non-bind mounts and cannot let us escape.
>>
>> I'm not sure if that's testable, though.
>
> This one isn't, unfortunately - there is no difference between bind and
> no-bind; vfsmounts form a tree and both normal mount and bind add leaves
> to it.  Moreover, mount -t ext2 /dev/sdc7 /mnt; mount -t ext2 /dev/sdc7 /tmp/a
> yield the same state as mount -t ext2 /dev/sdc7; mount --bind /mnt /tmp/a.
> There is no way to tell the difference, simply because there *is* no
> difference.  Moreover, either can be followed by umount /mnt and you'll get
> the same state as you would have after a solitary mount of the same fs on
> /tmp/a.

Fair enough.

> Ho-hum...  So:
>
> AT_BENEATH  AT_XDEV AT_NO_SYMLINKS
> absolute pathname:  EXDEV
> non-relative symlink:   EXDEV   ?   ELOOP
> relative symlink:   ELOOP
> .. from starting point: EXDEV
> .. crossing mountpoint: EXDEV
> crossing into mountpoint:   EXDEV
>
> 1) What should AT_XDEV do about absolute symlinks?  Nothing special?  EXDEV?
> EXDEV if we are not on root?

My mental model would say that AT_XDEV without AT_BENEATH would
_logically_ result in "EXDEV if / is a different vfsmount", accept the
absolute path otherwise.

But honestly, just returning EXDEV unconditionally for an absolute
symlink might just be the simpler and more straightforward thing to
do.

Because testing the particular vfsmount of / simply doesn't seem to be
a very useful operation.  I dunno.

> 2) What should AT_BENEATH | AT_NO_SYMLINKS do on absolute symlinks?  My
> preference would be "AT_NO_SYMLINKS wins, ELOOP for you", but that's based
> mostly upon the convenience of implementation.

I think either is fine, and convenience wins.

> 3) What effect should AT_NO_SYMLINKS have upon the final component?  Same
> as AT_SYMLINK_NOFOLLOW?

I actually would suggest "error if it's followed".

So if you use AT_SYMLINK_NOFOLLOW | AT_NO_SYMLINKS, then you do *not*
get an error if the last component (but nothing before it) is a
symlink, and the end result is the symlink itself.

If you use just AT_NO_SYMLINKS, then the lack of NOFOLLOW implies that
you'd follow the symlink to look it up, and then AT_NO_SYMLINKS means
that you get an error (ELOOP).

So the user gets to choose, and gets to basically indicate whether
it's fine to end at a dangling symlink or not. Which is exactly what
AT_SYMLINK_NOFOLLOW is all about.

No?

   Linus

Re: new ...at() flag: AT_NO_JUMPS

[Linus Torvalds]

On Thu, May 4, 2017 at 8:00 PM, Al Viro  wrote:
>>
>> That could still allow crossing mount-points, but only if they are
>> non-bind mounts and cannot let us escape.
>>
>> I'm not sure if that's testable, though.
>
> This one isn't, unfortunately - there is no difference between bind and
> no-bind; vfsmounts form a tree and both normal mount and bind add leaves
> to it.  Moreover, mount -t ext2 /dev/sdc7 /mnt; mount -t ext2 /dev/sdc7 /tmp/a
> yield the same state as mount -t ext2 /dev/sdc7; mount --bind /mnt /tmp/a.
> There is no way to tell the difference, simply because there *is* no
> difference.  Moreover, either can be followed by umount /mnt and you'll get
> the same state as you would have after a solitary mount of the same fs on
> /tmp/a.

Fair enough.

> Ho-hum...  So:
>
> AT_BENEATH  AT_XDEV AT_NO_SYMLINKS
> absolute pathname:  EXDEV
> non-relative symlink:   EXDEV   ?   ELOOP
> relative symlink:   ELOOP
> .. from starting point: EXDEV
> .. crossing mountpoint: EXDEV
> crossing into mountpoint:   EXDEV
>
> 1) What should AT_XDEV do about absolute symlinks?  Nothing special?  EXDEV?
> EXDEV if we are not on root?

My mental model would say that AT_XDEV without AT_BENEATH would
_logically_ result in "EXDEV if / is a different vfsmount", accept the
absolute path otherwise.

But honestly, just returning EXDEV unconditionally for an absolute
symlink might just be the simpler and more straightforward thing to
do.

Because testing the particular vfsmount of / simply doesn't seem to be
a very useful operation.  I dunno.

> 2) What should AT_BENEATH | AT_NO_SYMLINKS do on absolute symlinks?  My
> preference would be "AT_NO_SYMLINKS wins, ELOOP for you", but that's based
> mostly upon the convenience of implementation.

I think either is fine, and convenience wins.

> 3) What effect should AT_NO_SYMLINKS have upon the final component?  Same
> as AT_SYMLINK_NOFOLLOW?

I actually would suggest "error if it's followed".

So if you use AT_SYMLINK_NOFOLLOW | AT_NO_SYMLINKS, then you do *not*
get an error if the last component (but nothing before it) is a
symlink, and the end result is the symlink itself.

If you use just AT_NO_SYMLINKS, then the lack of NOFOLLOW implies that
you'd follow the symlink to look it up, and then AT_NO_SYMLINKS means
that you get an error (ELOOP).

So the user gets to choose, and gets to basically indicate whether
it's fine to end at a dangling symlink or not. Which is exactly what
AT_SYMLINK_NOFOLLOW is all about.

No?

   Linus

Re: new ...at() flag: AT_NO_JUMPS

[Linus Torvalds]

On Thu, May 4, 2017 at 7:47 PM, Jann Horn  wrote:
>
> Thread 1 starts an AT_BENEATH path walk using an O_PATH fd
> pointing to /srv/www/example.org/foo; the path given to the syscall is
> "bar/../../../../etc/passwd". The path walk enters the "bar" directory.
> Thread 2 moves /srv/www/example.org/foo/bar to
> /srv/www/example.org/bar.
> Thread 1 processes the rest of the path ("../../../../etc/passwd"), never
> hitting /srv/www/example.org/foo in the process.
>
> I'm not really familiar with the VFS internals, but from a coarse look
> at the patch, it seems like it wouldn't block this?

I think you're right.

I guess it would be safe for the RCU case due to the sequence number
check, but not the non-RCU case.

Al?

 Linus

Re: new ...at() flag: AT_NO_JUMPS

[Linus Torvalds]

On Thu, May 4, 2017 at 7:47 PM, Jann Horn  wrote:
>
> Thread 1 starts an AT_BENEATH path walk using an O_PATH fd
> pointing to /srv/www/example.org/foo; the path given to the syscall is
> "bar/../../../../etc/passwd". The path walk enters the "bar" directory.
> Thread 2 moves /srv/www/example.org/foo/bar to
> /srv/www/example.org/bar.
> Thread 1 processes the rest of the path ("../../../../etc/passwd"), never
> hitting /srv/www/example.org/foo in the process.
>
> I'm not really familiar with the VFS internals, but from a coarse look
> at the patch, it seems like it wouldn't block this?

I think you're right.

I guess it would be safe for the RCU case due to the sequence number
check, but not the non-RCU case.

Al?

 Linus

Re: [linux-sunxi] Re: [PATCH v6 08/13] drm/sun4i: add support for Allwinner DE2 mixers

[Chen-Yu Tsai]

On Fri, May 5, 2017 at 12:52 AM,   wrote:
> 在 2017-05-04 21:05，Maxime Ripard 写道：
>>
>> On Thu, May 04, 2017 at 07:48:53PM +0800, Icenowy Zheng wrote:
>>>
>>> Allwinner have a new "Display Engine 2.0" in their new SoCs, which comes
>>> with mixers to do graphic processing and feed data to TCON, like the old
>>> backends and frontends.
>>>
>>> Add support for the mixer on Allwinner V3s SoC; it's the simplest one.
>>>
>>> Currently a lot of functions are still missing -- more investigations
>>> are needed to gain enough information for them.
>>>
>>> Signed-off-by: Icenowy Zheng 
>>> ---
>>> Changes in v6:
>>> - Rebased on wens's multi-pipeline patchset.
>>> Changes in v5:
>>> - Changed some code alignment.
>>> - Request real 32-bit DMA (prepare for 64-bit SoCs).
>>> Changes in v4:
>>> - Killed some dead code according to Jernej.
>>>
>>>  drivers/gpu/drm/sun4i/Kconfig   |  10 +
>>>  drivers/gpu/drm/sun4i/Makefile  |   3 +
>>>  drivers/gpu/drm/sun4i/sun8i_layer.c | 140 +
>>>  drivers/gpu/drm/sun4i/sun8i_layer.h |  36 
>>>  drivers/gpu/drm/sun4i/sun8i_mixer.c | 394
>>> 
>>>  drivers/gpu/drm/sun4i/sun8i_mixer.h | 137 +
>>>  6 files changed, 720 insertions(+)
>>>  create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.c
>>>  create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.h
>>>  create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.c
>>>  create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.h
>>>

[...]

>>> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
>>> b/drivers/gpu/drm/sun4i/sun8i_mixer.c
>>> new file mode 100644
>>> index ..e216b84d5bb2
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
>>> @@ -0,0 +1,394 @@

[...]

>>> +   list_add_tail(>engine.list, >engine_list);
>>
>>
>> You didn't call INIT_LIST_HEAD on that list.
>
>
> So didn't the sun4i_backend driver...
>
> I think the mixer->engine.list only means an item in the
> engine_list, and the drv->engine_list is initialized in the
> sun4i_drv source code.

I read [1] that if the item is subsequently added to a list,
you could omit the INIT_LIST_HEAD call.

Makes sense, though you have to be sure you aren't doing anything
else with the list element.

ChenYu

[1] https://isis.poly.edu/kulesh/stuff/src/klist/

Re: [linux-sunxi] Re: [PATCH v6 08/13] drm/sun4i: add support for Allwinner DE2 mixers

[Chen-Yu Tsai]

On Fri, May 5, 2017 at 12:52 AM,   wrote:
> 在 2017-05-04 21:05，Maxime Ripard 写道：
>>
>> On Thu, May 04, 2017 at 07:48:53PM +0800, Icenowy Zheng wrote:
>>>
>>> Allwinner have a new "Display Engine 2.0" in their new SoCs, which comes
>>> with mixers to do graphic processing and feed data to TCON, like the old
>>> backends and frontends.
>>>
>>> Add support for the mixer on Allwinner V3s SoC; it's the simplest one.
>>>
>>> Currently a lot of functions are still missing -- more investigations
>>> are needed to gain enough information for them.
>>>
>>> Signed-off-by: Icenowy Zheng 
>>> ---
>>> Changes in v6:
>>> - Rebased on wens's multi-pipeline patchset.
>>> Changes in v5:
>>> - Changed some code alignment.
>>> - Request real 32-bit DMA (prepare for 64-bit SoCs).
>>> Changes in v4:
>>> - Killed some dead code according to Jernej.
>>>
>>>  drivers/gpu/drm/sun4i/Kconfig   |  10 +
>>>  drivers/gpu/drm/sun4i/Makefile  |   3 +
>>>  drivers/gpu/drm/sun4i/sun8i_layer.c | 140 +
>>>  drivers/gpu/drm/sun4i/sun8i_layer.h |  36 
>>>  drivers/gpu/drm/sun4i/sun8i_mixer.c | 394
>>> 
>>>  drivers/gpu/drm/sun4i/sun8i_mixer.h | 137 +
>>>  6 files changed, 720 insertions(+)
>>>  create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.c
>>>  create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.h
>>>  create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.c
>>>  create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.h
>>>

[...]

>>> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
>>> b/drivers/gpu/drm/sun4i/sun8i_mixer.c
>>> new file mode 100644
>>> index ..e216b84d5bb2
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
>>> @@ -0,0 +1,394 @@

[...]

>>> +   list_add_tail(>engine.list, >engine_list);
>>
>>
>> You didn't call INIT_LIST_HEAD on that list.
>
>
> So didn't the sun4i_backend driver...
>
> I think the mixer->engine.list only means an item in the
> engine_list, and the drv->engine_list is initialized in the
> sun4i_drv source code.

I read [1] that if the item is subsequently added to a list,
you could omit the INIT_LIST_HEAD call.

Makes sense, though you have to be sure you aren't doing anything
else with the list element.

ChenYu

[1] https://isis.poly.edu/kulesh/stuff/src/klist/

Re: [linux-sunxi] [PATCH v2 01/10] arm: sunxi: add support for R40 SoC

[Chen-Yu Tsai]

On Thu, May 4, 2017 at 9:49 PM, Icenowy Zheng  wrote:
> From: Icenowy Zheng 

Do you want to update your author email address?

>
> Allwinner R40 is a new SoC, with Quad Core Cortex-A7 and peripherals
> like A20.
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng 

Same here.

For the subject, "ARM" should be uppercase.

> ---
>  Documentation/arm/sunxi/README  | 4 
>  Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
>  arch/arm/mach-sunxi/sunxi.c | 1 +
>  3 files changed, 6 insertions(+)
>
> diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
> index d7b1f016bd62..25c814adcd47 100644
> --- a/Documentation/arm/sunxi/README
> +++ b/Documentation/arm/sunxi/README
> @@ -75,6 +75,10 @@ SunXi family
>  + Datasheet
>http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf
>
> +  - Allwinner R40 (sun8i)
> ++ Datasheet Draft
> +  http://linux-sunxi.org/File:Allwinner_R40_Datasheet_V0.1.pdf

We have the official 1.0 version, don't we? Also please keep the README
entries in alphabetical order


Regards
ChenYu

> +
>  * Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs
>- Allwinner A80
>  + Datasheet
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt 
> b/Documentation/devicetree/bindings/arm/sunxi.txt
> index d2c46449b4eb..b3ffe6cf821a 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.txt
> +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
> @@ -14,6 +14,7 @@ using one of the following compatible strings:
>allwinner,sun8i-a83t
>allwinner,sun8i-h2-plus
>allwinner,sun8i-h3
> +  allwinner-sun8i-r40
>allwinner,sun9i-a80
>allwinner,sun50i-a64
>nextthing,gr8
> diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
> index f44e3acb5c90..aea616759451 100644
> --- a/arch/arm/mach-sunxi/sunxi.c
> +++ b/arch/arm/mach-sunxi/sunxi.c
> @@ -66,6 +66,7 @@ static const char * const sun8i_board_dt_compat[] = {
> "allwinner,sun8i-h2-plus",
> "allwinner,sun8i-h3",
> "allwinner,sun8i-v3s",
> +   "allwinner,sun8i-r40",
> NULL,
>  };
>
> --
> 2.12.2
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH v2 01/10] arm: sunxi: add support for R40 SoC

[Chen-Yu Tsai]

On Thu, May 4, 2017 at 9:49 PM, Icenowy Zheng  wrote:
> From: Icenowy Zheng 

Do you want to update your author email address?

>
> Allwinner R40 is a new SoC, with Quad Core Cortex-A7 and peripherals
> like A20.
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng 

Same here.

For the subject, "ARM" should be uppercase.

> ---
>  Documentation/arm/sunxi/README  | 4 
>  Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
>  arch/arm/mach-sunxi/sunxi.c | 1 +
>  3 files changed, 6 insertions(+)
>
> diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
> index d7b1f016bd62..25c814adcd47 100644
> --- a/Documentation/arm/sunxi/README
> +++ b/Documentation/arm/sunxi/README
> @@ -75,6 +75,10 @@ SunXi family
>  + Datasheet
>http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf
>
> +  - Allwinner R40 (sun8i)
> ++ Datasheet Draft
> +  http://linux-sunxi.org/File:Allwinner_R40_Datasheet_V0.1.pdf

We have the official 1.0 version, don't we? Also please keep the README
entries in alphabetical order


Regards
ChenYu

> +
>  * Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs
>- Allwinner A80
>  + Datasheet
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt 
> b/Documentation/devicetree/bindings/arm/sunxi.txt
> index d2c46449b4eb..b3ffe6cf821a 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.txt
> +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
> @@ -14,6 +14,7 @@ using one of the following compatible strings:
>allwinner,sun8i-a83t
>allwinner,sun8i-h2-plus
>allwinner,sun8i-h3
> +  allwinner-sun8i-r40
>allwinner,sun9i-a80
>allwinner,sun50i-a64
>nextthing,gr8
> diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
> index f44e3acb5c90..aea616759451 100644
> --- a/arch/arm/mach-sunxi/sunxi.c
> +++ b/arch/arm/mach-sunxi/sunxi.c
> @@ -66,6 +66,7 @@ static const char * const sun8i_board_dt_compat[] = {
> "allwinner,sun8i-h2-plus",
> "allwinner,sun8i-h3",
> "allwinner,sun8i-v3s",
> +   "allwinner,sun8i-r40",
> NULL,
>  };
>
> --
> 2.12.2
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: linux-next: manual merge of the rdma tree with the pci tree

[Doug Ledford]

On 5/4/2017 8:19 PM, Stephen Rothwell wrote:
> Hi Doug,
> 
> Today's linux-next merge of the rdma tree got a conflict in:
> 
>   drivers/infiniband/hw/hfi1/hfi.h
> 
> between commit:
> 
>   21c433a74b6b ("IB/hfi1: Use pcie_flr() instead of duplicating it")
> 
> from the pci tree and commit:
> 
>   f4cd87652919 ("IB/hfi1: Name function prototype parameters")
> 
> from the rdma tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

This is not unexpected entirely, only unexpected in that the PCI tree
hasn't been merged yet ;-).  The first commit was part of a series that
was mainly a PCI series that just touched hfi1, so it's entirely
understandable that it went through the PCI tree and something in my
tree might happen, as it were, to touch the same area.  Your fix was
fine and I'm sure Linus can sort the same thing out.  Thanks ;-)

-- 
Doug Ledford 
GPG Key ID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD



signature.asc
Description: OpenPGP digital signature

Re: linux-next: manual merge of the rdma tree with the pci tree

[Doug Ledford]

On 5/4/2017 8:19 PM, Stephen Rothwell wrote:
> Hi Doug,
> 
> Today's linux-next merge of the rdma tree got a conflict in:
> 
>   drivers/infiniband/hw/hfi1/hfi.h
> 
> between commit:
> 
>   21c433a74b6b ("IB/hfi1: Use pcie_flr() instead of duplicating it")
> 
> from the pci tree and commit:
> 
>   f4cd87652919 ("IB/hfi1: Name function prototype parameters")
> 
> from the rdma tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

This is not unexpected entirely, only unexpected in that the PCI tree
hasn't been merged yet ;-).  The first commit was part of a series that
was mainly a PCI series that just touched hfi1, so it's entirely
understandable that it went through the PCI tree and something in my
tree might happen, as it were, to touch the same area.  Your fix was
fine and I'm sure Linus can sort the same thing out.  Thanks ;-)

-- 
Doug Ledford 
GPG Key ID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] ion: hisilicon: check the right value after ion_heap_create

[Yisheng Xie]

Hi Laura,

On 2017/5/5 1:47, Laura Abbott wrote:
> On 05/04/2017 07:45 AM, Yisheng Xie wrote:
>> From: Yisheng Xie 
>>
>> It should check ipdev->heaps[i] whether it is error or null instead of
>> ipdev->heaps, after ion_heap_create() for ipdev->heaps[i].
>>
>> Signed-off-by: Yisheng Xie 
>> ---
>>  drivers/staging/android/ion/hisilicon/hi6220_ion.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/android/ion/hisilicon/hi6220_ion.c 
>> b/drivers/staging/android/ion/hisilicon/hi6220_ion.c
>> index 0de7897..7f8eda5 100644
>> --- a/drivers/staging/android/ion/hisilicon/hi6220_ion.c
>> +++ b/drivers/staging/android/ion/hisilicon/hi6220_ion.c
>> @@ -66,7 +66,7 @@ static int hi6220_ion_probe(struct platform_device *pdev)
>>  
>>  for (i = 0; i < ipdev->data->nr; i++) {
>>  ipdev->heaps[i] = ion_heap_create(>data->heaps[i]);
>> -if (!ipdev->heaps) {
>> +if (IS_ERR_OR_NULL(ipdev->heaps[i])) {
>>  ion_destroy_platform_data(ipdev->data);
>>  return -ENOMEM;
>>  }
>>
> 
> This file was removed in a recent clean up series.
I see, but maybe you should clean up more totally, I mean you should also
remove ./drivers/staging/android/ion/devicetree.txt for it is also useless.

Thanks
Yisheng Xie

Re: [linux-sunxi] [PATCH v6 10/13] drm/sun4i: tcon: add support for V3s TCON

[Chen-Yu Tsai]

On Thu, May 4, 2017 at 7:48 PM, Icenowy Zheng  wrote:
> Allwinner V3s SoC features a TCON without channel 1.
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng 

Reviewed-by: Chen-Yu Tsai 

Re: [PATCH] ion: hisilicon: check the right value after ion_heap_create

[Yisheng Xie]

Hi Laura,

On 2017/5/5 1:47, Laura Abbott wrote:
> On 05/04/2017 07:45 AM, Yisheng Xie wrote:
>> From: Yisheng Xie 
>>
>> It should check ipdev->heaps[i] whether it is error or null instead of
>> ipdev->heaps, after ion_heap_create() for ipdev->heaps[i].
>>
>> Signed-off-by: Yisheng Xie 
>> ---
>>  drivers/staging/android/ion/hisilicon/hi6220_ion.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/android/ion/hisilicon/hi6220_ion.c 
>> b/drivers/staging/android/ion/hisilicon/hi6220_ion.c
>> index 0de7897..7f8eda5 100644
>> --- a/drivers/staging/android/ion/hisilicon/hi6220_ion.c
>> +++ b/drivers/staging/android/ion/hisilicon/hi6220_ion.c
>> @@ -66,7 +66,7 @@ static int hi6220_ion_probe(struct platform_device *pdev)
>>  
>>  for (i = 0; i < ipdev->data->nr; i++) {
>>  ipdev->heaps[i] = ion_heap_create(>data->heaps[i]);
>> -if (!ipdev->heaps) {
>> +if (IS_ERR_OR_NULL(ipdev->heaps[i])) {
>>  ion_destroy_platform_data(ipdev->data);
>>  return -ENOMEM;
>>  }
>>
> 
> This file was removed in a recent clean up series.
I see, but maybe you should clean up more totally, I mean you should also
remove ./drivers/staging/android/ion/devicetree.txt for it is also useless.

Thanks
Yisheng Xie

Re: [linux-sunxi] [PATCH v6 10/13] drm/sun4i: tcon: add support for V3s TCON

[Chen-Yu Tsai]

On Thu, May 4, 2017 at 7:48 PM, Icenowy Zheng  wrote:
> Allwinner V3s SoC features a TCON without channel 1.
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng 

Reviewed-by: Chen-Yu Tsai 

Re: [linux-sunxi] [PATCH v6 11/13] ARM: dts: sun8i: add DE2 nodes for V3s SoC

[Chen-Yu Tsai]

On Thu, May 4, 2017 at 7:48 PM, Icenowy Zheng  wrote:
> Allwinner V3s SoC features a "Display Engine 2.0" with only one TCON
> which have RGB LCD output.

Please also mention that it only has one mixer.

For the subject, you could just say "Add device nodes for the display pipeline".

>
> Add device nodes for it as well as the TCON.
>
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm/boot/dts/sun8i-v3s.dtsi | 87 
> 
>  1 file changed, 87 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi 
> b/arch/arm/boot/dts/sun8i-v3s.dtsi
> index 71075969e5e6..0a895179d8ae 100644
> --- a/arch/arm/boot/dts/sun8i-v3s.dtsi
> +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
> @@ -41,6 +41,10 @@
>   */
>
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
>
>  / {
> #address-cells = <1>;
> @@ -59,6 +63,12 @@
> };
> };
>
> +   de: display-engine {
> +   compatible = "allwinner,sun8i-v3s-display-engine";
> +   allwinner,pipelines = <_mixer0>;
> +   status = "disabled";
> +   };
> +
> timer {
> compatible = "arm,armv7-timer";
> interrupts =  IRQ_TYPE_LEVEL_LOW)>,
> @@ -93,6 +103,83 @@
> #size-cells = <1>;
> ranges;
>
> +   de2_clocks: clock@100 {
> +   compatible = "allwinner,sun50i-h5-de2-clk";

I am a bit skeptical about this. Since the V3S only has one mixer, do the clocks
for the second one even exist?

> +   reg = <0x0100 0x10>;
> +   clocks = < CLK_DE>,
> +< CLK_BUS_DE>;
> +   clock-names = "mod",
> + "bus";
> +   resets = < RST_BUS_DE>;
> +   #clock-cells = <1>;
> +   #reset-cells = <1>;
> +   };
> +
> +   de2_mixer0: mixer@110 {
> +   compatible = "allwinner,sun8i-v3s-de2-mixer";
> +   reg = <0x0110 0x10>;
> +   clocks = <_clocks CLK_MIXER0>,
> +<_clocks CLK_BUS_MIXER0>;
> +   clock-names = "mod",
> + "bus";

Nit: could you list the bus clock first?

Regards
ChenYu

> +   resets = <_clocks RST_MIXER0>;
> +   assigned-clocks = <_clocks CLK_MIXER0>;
> +   assigned-clock-rates = <15000>;
> +
> +   ports {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   mixer0_out: port@1 {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   reg = <1>;
> +
> +   mixer0_out_tcon0: endpoint@0 {
> +   reg = <0>;
> +   remote-endpoint = 
> <_in_mixer0>;
> +   };
> +   };
> +   };
> +   };
> +
> +   tcon0: lcd-controller@1c0c000 {
> +   compatible = "allwinner,sun8i-v3s-tcon";
> +   reg = <0x01c0c000 0x1000>;
> +   interrupts = ;
> +   clocks = < CLK_BUS_TCON0>,
> +< CLK_TCON0>;
> +   clock-names = "ahb",
> + "tcon-ch0";
> +   clock-output-names = "tcon-pixel-clock";
> +   resets = < RST_BUS_TCON0>;
> +   reset-names = "lcd";
> +   status = "disabled";
> +
> +   ports {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   tcon0_in: port@0 {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   reg = <0>;
> +
> +   tcon0_in_mixer0: endpoint@0 {
> +   reg = <0>;
> +   remote-endpoint = 
> <_out_tcon0>;
> +   };
> +   };
> +
> +   tcon0_out: port@1 {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   reg = <1>;
> +   };
> +   };
> +   

Re: [linux-sunxi] [PATCH v6 11/13] ARM: dts: sun8i: add DE2 nodes for V3s SoC

[Chen-Yu Tsai]

On Thu, May 4, 2017 at 7:48 PM, Icenowy Zheng  wrote:
> Allwinner V3s SoC features a "Display Engine 2.0" with only one TCON
> which have RGB LCD output.

Please also mention that it only has one mixer.

For the subject, you could just say "Add device nodes for the display pipeline".

>
> Add device nodes for it as well as the TCON.
>
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm/boot/dts/sun8i-v3s.dtsi | 87 
> 
>  1 file changed, 87 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi 
> b/arch/arm/boot/dts/sun8i-v3s.dtsi
> index 71075969e5e6..0a895179d8ae 100644
> --- a/arch/arm/boot/dts/sun8i-v3s.dtsi
> +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
> @@ -41,6 +41,10 @@
>   */
>
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
>
>  / {
> #address-cells = <1>;
> @@ -59,6 +63,12 @@
> };
> };
>
> +   de: display-engine {
> +   compatible = "allwinner,sun8i-v3s-display-engine";
> +   allwinner,pipelines = <_mixer0>;
> +   status = "disabled";
> +   };
> +
> timer {
> compatible = "arm,armv7-timer";
> interrupts =  IRQ_TYPE_LEVEL_LOW)>,
> @@ -93,6 +103,83 @@
> #size-cells = <1>;
> ranges;
>
> +   de2_clocks: clock@100 {
> +   compatible = "allwinner,sun50i-h5-de2-clk";

I am a bit skeptical about this. Since the V3S only has one mixer, do the clocks
for the second one even exist?

> +   reg = <0x0100 0x10>;
> +   clocks = < CLK_DE>,
> +< CLK_BUS_DE>;
> +   clock-names = "mod",
> + "bus";
> +   resets = < RST_BUS_DE>;
> +   #clock-cells = <1>;
> +   #reset-cells = <1>;
> +   };
> +
> +   de2_mixer0: mixer@110 {
> +   compatible = "allwinner,sun8i-v3s-de2-mixer";
> +   reg = <0x0110 0x10>;
> +   clocks = <_clocks CLK_MIXER0>,
> +<_clocks CLK_BUS_MIXER0>;
> +   clock-names = "mod",
> + "bus";

Nit: could you list the bus clock first?

Regards
ChenYu

> +   resets = <_clocks RST_MIXER0>;
> +   assigned-clocks = <_clocks CLK_MIXER0>;
> +   assigned-clock-rates = <15000>;
> +
> +   ports {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   mixer0_out: port@1 {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   reg = <1>;
> +
> +   mixer0_out_tcon0: endpoint@0 {
> +   reg = <0>;
> +   remote-endpoint = 
> <_in_mixer0>;
> +   };
> +   };
> +   };
> +   };
> +
> +   tcon0: lcd-controller@1c0c000 {
> +   compatible = "allwinner,sun8i-v3s-tcon";
> +   reg = <0x01c0c000 0x1000>;
> +   interrupts = ;
> +   clocks = < CLK_BUS_TCON0>,
> +< CLK_TCON0>;
> +   clock-names = "ahb",
> + "tcon-ch0";
> +   clock-output-names = "tcon-pixel-clock";
> +   resets = < RST_BUS_TCON0>;
> +   reset-names = "lcd";
> +   status = "disabled";
> +
> +   ports {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   tcon0_in: port@0 {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   reg = <0>;
> +
> +   tcon0_in_mixer0: endpoint@0 {
> +   reg = <0>;
> +   remote-endpoint = 
> <_out_tcon0>;
> +   };
> +   };
> +
> +   tcon0_out: port@1 {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   reg = <1>;
> +   };
> +   };
> +   };
> +
> +
> mmc0: 

Re: [PATCH] RTC: Add functionality to read/write rtc scratch registers

[Keerthy]

On Friday 05 May 2017 04:08 AM, Alexandre Belloni wrote:
> Hi,
> 
> On 03/05/2017 at 11:39:34 +0530, Keerthy wrote:
>> On Tuesday 18 April 2017 10:50 AM, Keerthy wrote:
>>> From: Russ Dill 
>>>
>>> Many RTCs provide scratch registers that are maintained so long as the RTC
>>> has power. Provide a generic method to access these registers.
>>>
>>
>> A gentle ping on this
>>
> 
> Yeah, I apologize for the delay (I know you already sent this 6-8 months
> ago).
> I'm not satisfied with the interface (and its name). I gave a lot of
> thought into it and I'm currently reworking part of the subsystem to
> create a similar feature. I'm planning to have it in 4.13.

Okay then i will wait for that. Thanks for the response.

> 
>>> Signed-off-by: Russ Dill 
>>> Signed-off-by: Keerthy 
>>> ---
>>>  drivers/rtc/interface.c | 50 
>>> +
>>>  drivers/rtc/rtc-omap.c  | 35 ++
>>>  include/linux/rtc.h |  7 +++
>>>  3 files changed, 92 insertions(+)
>>>
>>> diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
>>> index fc0fa75..facde06 100644
>>> --- a/drivers/rtc/interface.c
>>> +++ b/drivers/rtc/interface.c
>>> @@ -1016,3 +1016,53 @@ int rtc_set_offset(struct rtc_device *rtc, long 
>>> offset)
>>> mutex_unlock(>ops_lock);
>>> return ret;
>>>  }
>>> +
>>> +/* rtc_read_scratch - Read from RTC scratch register
>>> + * @ rtc: rtc device to be used
>>> + * @ index: index of scratch register
>>> + * @ value: returned value read
>>> + *
>>> + * Kernel interface read from an RTC scratch register
>>> + */
>>> +int rtc_read_scratch(struct rtc_device *rtc, unsigned int index, u32 
>>> *value)
>>> +{
>>> +   int err;
>>> +
>>> +   mutex_lock(>ops_lock);
>>> +   if (!rtc->ops)
>>> +   err = -ENODEV;
>>> +   else if (index >= rtc->ops->scratch_size || !rtc->ops->read_scratch)
>>> +   err = -EINVAL;
>>> +   else
>>> +   err = rtc->ops->read_scratch(rtc->dev.parent, index, value);
>>> +   mutex_unlock(>ops_lock);
>>> +   return err;
>>> +}
>>> +EXPORT_SYMBOL_GPL(rtc_read_scratch);
>>> +
>>> +/* rtc_write_scratch - Write to RTC scratch register
>>> + * @ rtc: rtc device to be used
>>> + * @ index: index of scratch register
>>> + * @ value: value to write
>>> + *
>>> + * Kernel interface write to an RTC scratch register
>>> + */
>>> +int rtc_write_scratch(struct rtc_device *rtc, unsigned int index, u32 
>>> value)
>>> +{
>>> +   int err;
>>> +
>>> +   mutex_lock(>ops_lock);
>>> +
>>> +   if (!rtc->ops)
>>> +   err = -ENODEV;
>>> +   else if (index >= rtc->ops->scratch_size ||
>>> +!rtc->ops->write_scratch)
>>> +   err = -EINVAL;
>>> +   else
>>> +   err = rtc->ops->write_scratch(rtc->dev.parent, index, value);
>>> +
>>> +   mutex_unlock(>ops_lock);
>>> +
>>> +   return err;
>>> +}
>>> +EXPORT_SYMBOL_GPL(rtc_write_scratch);
>>> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
>>> index 13f7cd1..c90d93e 100644
>>> --- a/drivers/rtc/rtc-omap.c
>>> +++ b/drivers/rtc/rtc-omap.c
>>> @@ -70,6 +70,10 @@
>>>  #define OMAP_RTC_COMP_MSB_REG  0x50
>>>  #define OMAP_RTC_OSC_REG   0x54
>>>  
>>> +#define OMAP_RTC_SCRATCH0_REG  0x60
>>> +#define OMAP_RTC_SCRATCH1_REG  0x64
>>> +#define OMAP_RTC_SCRATCH2_REG  0x68
>>> +
>>>  #define OMAP_RTC_KICK0_REG 0x6c
>>>  #define OMAP_RTC_KICK1_REG 0x70
>>>  
>>> @@ -414,6 +418,34 @@ static int omap_rtc_set_alarm(struct device *dev, 
>>> struct rtc_wkalrm *alm)
>>>  
>>>  static struct omap_rtc *omap_rtc_power_off_rtc;
>>>  
>>> +static const u32 omap_rtc_scratch_regs[] = {
>>> +   OMAP_RTC_SCRATCH0_REG,
>>> +   OMAP_RTC_SCRATCH1_REG,
>>> +   OMAP_RTC_SCRATCH2_REG,
>>> +};
>>> +
>>> +static int omap_rtc_read_scratch(struct device *dev, unsigned int index,
>>> +u32 *value)
>>> +{
>>> +   *value = readl(omap_rtc_power_off_rtc->base +
>>> +  omap_rtc_scratch_regs[index]);
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +static int omap_rtc_write_scratch(struct device *dev, unsigned int index,
>>> + u32 value)
>>> +{
>>> +   struct omap_rtc *rtc = dev_get_drvdata(dev);
>>> +
>>> +   rtc->type->unlock(rtc);
>>> +   writel(value, omap_rtc_power_off_rtc->base +
>>> +  omap_rtc_scratch_regs[index]);
>>> +   rtc->type->lock(rtc);
>>> +
>>> +   return 0;
>>> +}
>>> +
>>>  /*
>>>   * omap_rtc_poweroff: RTC-controlled power off
>>>   *
>>> @@ -484,6 +516,9 @@ static void omap_rtc_power_off(void)
>>> .read_alarm = omap_rtc_read_alarm,
>>> .set_alarm  = omap_rtc_set_alarm,
>>> .alarm_irq_enable = omap_rtc_alarm_irq_enable,
>>> +   .read_scratch   = omap_rtc_read_scratch,
>>> +   .write_scratch  = omap_rtc_write_scratch,
>>> +   .scratch_size   = ARRAY_SIZE(omap_rtc_scratch_regs),
>>>  };
>>>  
>>>  static const struct omap_rtc_device_type 

Re: [PATCH] RTC: Add functionality to read/write rtc scratch registers

[Keerthy]

On Friday 05 May 2017 04:08 AM, Alexandre Belloni wrote:
> Hi,
> 
> On 03/05/2017 at 11:39:34 +0530, Keerthy wrote:
>> On Tuesday 18 April 2017 10:50 AM, Keerthy wrote:
>>> From: Russ Dill 
>>>
>>> Many RTCs provide scratch registers that are maintained so long as the RTC
>>> has power. Provide a generic method to access these registers.
>>>
>>
>> A gentle ping on this
>>
> 
> Yeah, I apologize for the delay (I know you already sent this 6-8 months
> ago).
> I'm not satisfied with the interface (and its name). I gave a lot of
> thought into it and I'm currently reworking part of the subsystem to
> create a similar feature. I'm planning to have it in 4.13.

Okay then i will wait for that. Thanks for the response.

> 
>>> Signed-off-by: Russ Dill 
>>> Signed-off-by: Keerthy 
>>> ---
>>>  drivers/rtc/interface.c | 50 
>>> +
>>>  drivers/rtc/rtc-omap.c  | 35 ++
>>>  include/linux/rtc.h |  7 +++
>>>  3 files changed, 92 insertions(+)
>>>
>>> diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
>>> index fc0fa75..facde06 100644
>>> --- a/drivers/rtc/interface.c
>>> +++ b/drivers/rtc/interface.c
>>> @@ -1016,3 +1016,53 @@ int rtc_set_offset(struct rtc_device *rtc, long 
>>> offset)
>>> mutex_unlock(>ops_lock);
>>> return ret;
>>>  }
>>> +
>>> +/* rtc_read_scratch - Read from RTC scratch register
>>> + * @ rtc: rtc device to be used
>>> + * @ index: index of scratch register
>>> + * @ value: returned value read
>>> + *
>>> + * Kernel interface read from an RTC scratch register
>>> + */
>>> +int rtc_read_scratch(struct rtc_device *rtc, unsigned int index, u32 
>>> *value)
>>> +{
>>> +   int err;
>>> +
>>> +   mutex_lock(>ops_lock);
>>> +   if (!rtc->ops)
>>> +   err = -ENODEV;
>>> +   else if (index >= rtc->ops->scratch_size || !rtc->ops->read_scratch)
>>> +   err = -EINVAL;
>>> +   else
>>> +   err = rtc->ops->read_scratch(rtc->dev.parent, index, value);
>>> +   mutex_unlock(>ops_lock);
>>> +   return err;
>>> +}
>>> +EXPORT_SYMBOL_GPL(rtc_read_scratch);
>>> +
>>> +/* rtc_write_scratch - Write to RTC scratch register
>>> + * @ rtc: rtc device to be used
>>> + * @ index: index of scratch register
>>> + * @ value: value to write
>>> + *
>>> + * Kernel interface write to an RTC scratch register
>>> + */
>>> +int rtc_write_scratch(struct rtc_device *rtc, unsigned int index, u32 
>>> value)
>>> +{
>>> +   int err;
>>> +
>>> +   mutex_lock(>ops_lock);
>>> +
>>> +   if (!rtc->ops)
>>> +   err = -ENODEV;
>>> +   else if (index >= rtc->ops->scratch_size ||
>>> +!rtc->ops->write_scratch)
>>> +   err = -EINVAL;
>>> +   else
>>> +   err = rtc->ops->write_scratch(rtc->dev.parent, index, value);
>>> +
>>> +   mutex_unlock(>ops_lock);
>>> +
>>> +   return err;
>>> +}
>>> +EXPORT_SYMBOL_GPL(rtc_write_scratch);
>>> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
>>> index 13f7cd1..c90d93e 100644
>>> --- a/drivers/rtc/rtc-omap.c
>>> +++ b/drivers/rtc/rtc-omap.c
>>> @@ -70,6 +70,10 @@
>>>  #define OMAP_RTC_COMP_MSB_REG  0x50
>>>  #define OMAP_RTC_OSC_REG   0x54
>>>  
>>> +#define OMAP_RTC_SCRATCH0_REG  0x60
>>> +#define OMAP_RTC_SCRATCH1_REG  0x64
>>> +#define OMAP_RTC_SCRATCH2_REG  0x68
>>> +
>>>  #define OMAP_RTC_KICK0_REG 0x6c
>>>  #define OMAP_RTC_KICK1_REG 0x70
>>>  
>>> @@ -414,6 +418,34 @@ static int omap_rtc_set_alarm(struct device *dev, 
>>> struct rtc_wkalrm *alm)
>>>  
>>>  static struct omap_rtc *omap_rtc_power_off_rtc;
>>>  
>>> +static const u32 omap_rtc_scratch_regs[] = {
>>> +   OMAP_RTC_SCRATCH0_REG,
>>> +   OMAP_RTC_SCRATCH1_REG,
>>> +   OMAP_RTC_SCRATCH2_REG,
>>> +};
>>> +
>>> +static int omap_rtc_read_scratch(struct device *dev, unsigned int index,
>>> +u32 *value)
>>> +{
>>> +   *value = readl(omap_rtc_power_off_rtc->base +
>>> +  omap_rtc_scratch_regs[index]);
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +static int omap_rtc_write_scratch(struct device *dev, unsigned int index,
>>> + u32 value)
>>> +{
>>> +   struct omap_rtc *rtc = dev_get_drvdata(dev);
>>> +
>>> +   rtc->type->unlock(rtc);
>>> +   writel(value, omap_rtc_power_off_rtc->base +
>>> +  omap_rtc_scratch_regs[index]);
>>> +   rtc->type->lock(rtc);
>>> +
>>> +   return 0;
>>> +}
>>> +
>>>  /*
>>>   * omap_rtc_poweroff: RTC-controlled power off
>>>   *
>>> @@ -484,6 +516,9 @@ static void omap_rtc_power_off(void)
>>> .read_alarm = omap_rtc_read_alarm,
>>> .set_alarm  = omap_rtc_set_alarm,
>>> .alarm_irq_enable = omap_rtc_alarm_irq_enable,
>>> +   .read_scratch   = omap_rtc_read_scratch,
>>> +   .write_scratch  = omap_rtc_write_scratch,
>>> +   .scratch_size   = ARRAY_SIZE(omap_rtc_scratch_regs),
>>>  };
>>>  
>>>  static const struct omap_rtc_device_type omap_rtc_default_type = {
>>> diff --git 

Re: [linux-sunxi] [PATCH v6 12/13] ARM: dts: sun8i: add pinmux for LCD pins of V3s SoC

[Chen-Yu Tsai]

On Thu, May 4, 2017 at 7:48 PM, Icenowy Zheng  wrote:
> Allwinner V3s SoC features a set of pins that have functionality of RGB
> LCD, the pins are at different pin ban than other SoCs.
>
> Add pinctrl node for them.
>
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm/boot/dts/sun8i-v3s.dtsi | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi 
> b/arch/arm/boot/dts/sun8i-v3s.dtsi
> index 0a895179d8ae..a37d68b227bc 100644
> --- a/arch/arm/boot/dts/sun8i-v3s.dtsi
> +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
> @@ -297,6 +297,15 @@
> function = "i2c0";
> };
>
> +   lcd_rgb666_pins: lcd_rgb666@0 {

Drop the trailing "@0". Otherwise,

Acked-by: Chen-Yu Tsai 

> +   pins = "PE0", "PE1", "PE2", "PE3", "PE4",
> +  "PE5", "PE6", "PE7", "PE8", "PE9",
> +  "PE10", "PE11", "PE12", "PE13", "PE14",
> +  "PE15", "PE16", "PE17", "PE18", "PE19",
> +  "PE23", "PE24";
> +   function = "lcd";
> +   };
> +
> uart0_pins_a: uart0@0 {
> pins = "PB8", "PB9";
> function = "uart0";
> --
> 2.12.2
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH v6 12/13] ARM: dts: sun8i: add pinmux for LCD pins of V3s SoC

[Chen-Yu Tsai]

On Thu, May 4, 2017 at 7:48 PM, Icenowy Zheng  wrote:
> Allwinner V3s SoC features a set of pins that have functionality of RGB
> LCD, the pins are at different pin ban than other SoCs.
>
> Add pinctrl node for them.
>
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm/boot/dts/sun8i-v3s.dtsi | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi 
> b/arch/arm/boot/dts/sun8i-v3s.dtsi
> index 0a895179d8ae..a37d68b227bc 100644
> --- a/arch/arm/boot/dts/sun8i-v3s.dtsi
> +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
> @@ -297,6 +297,15 @@
> function = "i2c0";
> };
>
> +   lcd_rgb666_pins: lcd_rgb666@0 {

Drop the trailing "@0". Otherwise,

Acked-by: Chen-Yu Tsai 

> +   pins = "PE0", "PE1", "PE2", "PE3", "PE4",
> +  "PE5", "PE6", "PE7", "PE8", "PE9",
> +  "PE10", "PE11", "PE12", "PE13", "PE14",
> +  "PE15", "PE16", "PE17", "PE18", "PE19",
> +  "PE23", "PE24";
> +   function = "lcd";
> +   };
> +
> uart0_pins_a: uart0@0 {
> pins = "PB8", "PB9";
> function = "uart0";
> --
> 2.12.2
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH v6 03/13] dt-bindings: add bindings for DE2 on V3s SoC

[Chen-Yu Tsai]

On Thu, May 4, 2017 at 7:48 PM, Icenowy Zheng  wrote:
> Allwinner V3s SoC have a display engine which have a different pipeline
> with older SoCs.
>
> Add document for it (new compatibles and the new "mixer" part).
>
> Signed-off-by: Icenowy Zheng 
> Acked-by: Rob Herring 
> ---
> Changes in v4:
> - Removed the refactor at TCON chapter.
> Changes in v3:
> - Remove the description of having a BE directly as allwinner,pipeline.
>
>  .../bindings/display/sunxi/sun4i-drm.txt   | 29 
> --
>  1 file changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
> b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> index 7acdbf14ae1c..33452884b96e 100644
> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> @@ -41,6 +41,7 @@ Required properties:
> * allwinner,sun6i-a31-tcon
> * allwinner,sun6i-a31s-tcon
> * allwinner,sun8i-a33-tcon
> +   * allwinner,sun8i-v3s-tcon
>   - reg: base address and size of memory-mapped region
>   - interrupts: interrupt associated to this IP
>   - clocks: phandles to the clocks feeding the TCON. Three are needed:
> @@ -62,7 +63,7 @@ Required properties:
>second the block connected to the TCON channel 1 (usually the TV
>encoder)
>
> -On SoCs other than the A33, there is one more clock required:
> +On SoCs other than the A33 and V3s, there is one more clock required:
> - 'tcon-ch1': The clock driving the TCON channel 1
>
>  DRC
> @@ -148,6 +149,26 @@ Required properties:
>Documentation/devicetree/bindings/media/video-interfaces.txt. The
>first port should be the input endpoints, the second one the outputs
>
> +Display Engine 2.0 Mixer
> +
> +
> +The DE2 mixer have many functionalities, currently only layer blending is
> +supported.
> +
> +Required properties:
> +  - compatible: value must be one of:
> +* allwinner,sun8i-v3s-de2-mixer
> +  - reg: base address and size of the memory-mapped region.
> +  - clocks: phandles to the clocks feeding the frontend and backend
> +* bus: the backend interface clock
> +* ram: the backend DRAM clock

You probably mean "mixer" here.

> +  - clock-names: the clock names mentioned above
> +  - resets: phandles to the reset controllers driving the backend

And here.

> +
> +- ports: A ports node with endpoint definitions as defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt. The
> +  first port should be the input endpoints, the second one the output
> +
>
>  Display Engine Pipeline
>  ---
> @@ -162,9 +183,13 @@ Required properties:
>  * allwinner,sun6i-a31-display-engine
>  * allwinner,sun6i-a31s-display-engine
>  * allwinner,sun8i-a33-display-engine
> +* allwinner,sun8i-v3s-display-engine
>
>- allwinner,pipelines: list of phandle to the display engine
> -frontends available.
> +pipeline entry point. For SoCs with original DE (currently
> +all SoCs supported by display engine except V3s), this
> +phandle should be a display frontend; for SoCs with DE2,
> +this phandle should be a mixer.

You could simplify this to "list of phandles to the display
engine frontends (DE 1.0) or mixers (DE 2.0) available".

Regards
ChenYu

>
>  Example:
>
> --
> 2.12.2
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH v6 03/13] dt-bindings: add bindings for DE2 on V3s SoC

[Chen-Yu Tsai]

On Thu, May 4, 2017 at 7:48 PM, Icenowy Zheng  wrote:
> Allwinner V3s SoC have a display engine which have a different pipeline
> with older SoCs.
>
> Add document for it (new compatibles and the new "mixer" part).
>
> Signed-off-by: Icenowy Zheng 
> Acked-by: Rob Herring 
> ---
> Changes in v4:
> - Removed the refactor at TCON chapter.
> Changes in v3:
> - Remove the description of having a BE directly as allwinner,pipeline.
>
>  .../bindings/display/sunxi/sun4i-drm.txt   | 29 
> --
>  1 file changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
> b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> index 7acdbf14ae1c..33452884b96e 100644
> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> @@ -41,6 +41,7 @@ Required properties:
> * allwinner,sun6i-a31-tcon
> * allwinner,sun6i-a31s-tcon
> * allwinner,sun8i-a33-tcon
> +   * allwinner,sun8i-v3s-tcon
>   - reg: base address and size of memory-mapped region
>   - interrupts: interrupt associated to this IP
>   - clocks: phandles to the clocks feeding the TCON. Three are needed:
> @@ -62,7 +63,7 @@ Required properties:
>second the block connected to the TCON channel 1 (usually the TV
>encoder)
>
> -On SoCs other than the A33, there is one more clock required:
> +On SoCs other than the A33 and V3s, there is one more clock required:
> - 'tcon-ch1': The clock driving the TCON channel 1
>
>  DRC
> @@ -148,6 +149,26 @@ Required properties:
>Documentation/devicetree/bindings/media/video-interfaces.txt. The
>first port should be the input endpoints, the second one the outputs
>
> +Display Engine 2.0 Mixer
> +
> +
> +The DE2 mixer have many functionalities, currently only layer blending is
> +supported.
> +
> +Required properties:
> +  - compatible: value must be one of:
> +* allwinner,sun8i-v3s-de2-mixer
> +  - reg: base address and size of the memory-mapped region.
> +  - clocks: phandles to the clocks feeding the frontend and backend
> +* bus: the backend interface clock
> +* ram: the backend DRAM clock

You probably mean "mixer" here.

> +  - clock-names: the clock names mentioned above
> +  - resets: phandles to the reset controllers driving the backend

And here.

> +
> +- ports: A ports node with endpoint definitions as defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt. The
> +  first port should be the input endpoints, the second one the output
> +
>
>  Display Engine Pipeline
>  ---
> @@ -162,9 +183,13 @@ Required properties:
>  * allwinner,sun6i-a31-display-engine
>  * allwinner,sun6i-a31s-display-engine
>  * allwinner,sun8i-a33-display-engine
> +* allwinner,sun8i-v3s-display-engine
>
>- allwinner,pipelines: list of phandle to the display engine
> -frontends available.
> +pipeline entry point. For SoCs with original DE (currently
> +all SoCs supported by display engine except V3s), this
> +phandle should be a display frontend; for SoCs with DE2,
> +this phandle should be a mixer.

You could simplify this to "list of phandles to the display
engine frontends (DE 1.0) or mixers (DE 2.0) available".

Regards
ChenYu

>
>  Example:
>
> --
> 2.12.2
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Patch v2] x86/build: require only gcc use -maccumulate-outgoing-args

[Nick Desaulniers]

Other compilers, like clang, treat unknown compiler flags as errors.

Signed-off-by: Nick Desaulniers 
---
 arch/x86/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 4430dd489620..12757a252e6b 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -179,7 +179,7 @@ ifdef CONFIG_JUMP_LABEL
 endif
 
 ifeq ($(ACCUMULATE_OUTGOING_ARGS), 1)
-   KBUILD_CFLAGS += -maccumulate-outgoing-args
+   KBUILD_CFLAGS += $(if $(filter 
gcc,$(cc-name)),-maccumulate-outgoing-args)
 endif
 
 # Stackpointer is addressed different for 32 bit and 64 bit x86
-- 
2.11.0

[Patch v2] x86/build: require only gcc use -maccumulate-outgoing-args

[Nick Desaulniers]

Other compilers, like clang, treat unknown compiler flags as errors.

Signed-off-by: Nick Desaulniers 
---
 arch/x86/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 4430dd489620..12757a252e6b 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -179,7 +179,7 @@ ifdef CONFIG_JUMP_LABEL
 endif
 
 ifeq ($(ACCUMULATE_OUTGOING_ARGS), 1)
-   KBUILD_CFLAGS += -maccumulate-outgoing-args
+   KBUILD_CFLAGS += $(if $(filter 
gcc,$(cc-name)),-maccumulate-outgoing-args)
 endif
 
 # Stackpointer is addressed different for 32 bit and 64 bit x86
-- 
2.11.0

Re: [linux-sunxi] [PATCH v6 07/13] drm/sun4i: add a Kconfig option for sun4i-backend

[Chen-Yu Tsai]

On Thu, May 4, 2017 at 7:48 PM, Icenowy Zheng  wrote:
> As sun4i-backend is now a dedicated module, add an Kconfig option for
> it to make it optional, since some build may only use other engines.
>
> Signed-off-by: Icenowy Zheng 
> ---
> Splited out patch.
>
>  drivers/gpu/drm/sun4i/Kconfig  | 10 ++
>  drivers/gpu/drm/sun4i/Makefile |  2 +-
>  2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
> index a4b357db8856..5a8227f37cc4 100644
> --- a/drivers/gpu/drm/sun4i/Kconfig
> +++ b/drivers/gpu/drm/sun4i/Kconfig
> @@ -12,3 +12,13 @@ config DRM_SUN4I
>   Choose this option if you have an Allwinner SoC with a
>   Display Engine. If M is selected the module will be called
>   sun4i-drm.
> +
> +config DRM_SUN4I_BACKEND
> +   tristate "Support for Allwinner A10 Display Engine Backend"
> +   depends on DRM_SUN4I
> +   default DRM_SUN4I
> +   help
> + Choose this option if you have an Allwinner SoC with the
> + original Allwinner Display Engine, which has a backend to
> + do some alpha blending and feed graphics to TCON. If M is
> + selected the module will be called sun4i-backend.
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index a251fb36c951..a08df56759e3 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -9,6 +9,6 @@ sun4i-tcon-y += sun4i_crtc.o
>  sun4i-backend-y += sun4i_backend.o sun4i_layer.o
>
>  obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o sun4i-tcon.o
> -obj-$(CONFIG_DRM_SUN4I)+= sun4i-backend.o
> +obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o
>  obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o
>  obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o

Can you move sun4i-backend to the bottom in a separate section? The idea
is to have a bunch of core or common stuff, then platform specific modules.

Thanks
ChenYu

Re: [linux-sunxi] [PATCH v6 07/13] drm/sun4i: add a Kconfig option for sun4i-backend

[Chen-Yu Tsai]

On Thu, May 4, 2017 at 7:48 PM, Icenowy Zheng  wrote:
> As sun4i-backend is now a dedicated module, add an Kconfig option for
> it to make it optional, since some build may only use other engines.
>
> Signed-off-by: Icenowy Zheng 
> ---
> Splited out patch.
>
>  drivers/gpu/drm/sun4i/Kconfig  | 10 ++
>  drivers/gpu/drm/sun4i/Makefile |  2 +-
>  2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
> index a4b357db8856..5a8227f37cc4 100644
> --- a/drivers/gpu/drm/sun4i/Kconfig
> +++ b/drivers/gpu/drm/sun4i/Kconfig
> @@ -12,3 +12,13 @@ config DRM_SUN4I
>   Choose this option if you have an Allwinner SoC with a
>   Display Engine. If M is selected the module will be called
>   sun4i-drm.
> +
> +config DRM_SUN4I_BACKEND
> +   tristate "Support for Allwinner A10 Display Engine Backend"
> +   depends on DRM_SUN4I
> +   default DRM_SUN4I
> +   help
> + Choose this option if you have an Allwinner SoC with the
> + original Allwinner Display Engine, which has a backend to
> + do some alpha blending and feed graphics to TCON. If M is
> + selected the module will be called sun4i-backend.
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index a251fb36c951..a08df56759e3 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -9,6 +9,6 @@ sun4i-tcon-y += sun4i_crtc.o
>  sun4i-backend-y += sun4i_backend.o sun4i_layer.o
>
>  obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o sun4i-tcon.o
> -obj-$(CONFIG_DRM_SUN4I)+= sun4i-backend.o
> +obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o
>  obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o
>  obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o

Can you move sun4i-backend to the bottom in a separate section? The idea
is to have a bunch of core or common stuff, then platform specific modules.

Thanks
ChenYu

Re: [linux-sunxi] [PATCH v6 06/13] drm/sun4i: add a dedicated module for sun4i-backend and sun4i-layer

[Chen-Yu Tsai]

On Thu, May 4, 2017 at 7:48 PM, Icenowy Zheng  wrote:
> Currently the direct call from CRTC code to layer code has disappeared,
> instead the layer's init function is called via the backend's ops.
>
> Add a dedicated module for sun4i-backend and sun4i-layer, and drop the
> EXPORT_SYMBOL from backend code to layer code.
>
> Signed-off-by: Icenowy Zheng 

Reviewed-by: Chen-Yu Tsai 

Re: [linux-sunxi] [PATCH v6 06/13] drm/sun4i: add a dedicated module for sun4i-backend and sun4i-layer

[Chen-Yu Tsai]

On Thu, May 4, 2017 at 7:48 PM, Icenowy Zheng  wrote:
> Currently the direct call from CRTC code to layer code has disappeared,
> instead the layer's init function is called via the backend's ops.
>
> Add a dedicated module for sun4i-backend and sun4i-layer, and drop the
> EXPORT_SYMBOL from backend code to layer code.
>
> Signed-off-by: Icenowy Zheng 

Reviewed-by: Chen-Yu Tsai 

Re: [PATCH] perf report: Make --branch-history work without callgraphs(-g) option in perf record

[Jin, Yao]

SNIP

-   if (symbol_conf.use_callchain) {
+   if (symbol_conf.use_callchain &&
+   !symbol_conf.show_branchflag_count) {
ui__error("Selected -g or --branch-history but no "
  "callchain data. Did\n"
  "you call 'perf record' without -g?\n");

The `--branch-history` part of this error message is now stale, no?


Yes, the error message is obsolete. I will change it in next version.



@@ -397,7 +398,8 @@ static int perf_evlist__tty_browse_hists(struct
perf_evlist *evlist,

hists__fprintf_nr_sample_events(hists, rep, evname, stdout);
hists__fprintf(hists, !quiet, 0, 0, rep->min_percent, stdout,
-  symbol_conf.use_callchain);
+  symbol_conf.use_callchain |
+  symbol_conf.show_branchflag_count);
fprintf(stdout, "\n\n");
}

Not sure about the coding style here, but shouldn't this be a boolean or
operator here '||' - semantically? Functionality wise it will be the same, I
guess?


Should be same. While I will follow your comments to change it to '||'.

I will wait other comments for some days and then send out the next version.

Thanks
Jin Yao

Re: [PATCH] perf report: Make --branch-history work without callgraphs(-g) option in perf record

[Jin, Yao]

SNIP

-   if (symbol_conf.use_callchain) {
+   if (symbol_conf.use_callchain &&
+   !symbol_conf.show_branchflag_count) {
ui__error("Selected -g or --branch-history but no "
  "callchain data. Did\n"
  "you call 'perf record' without -g?\n");

The `--branch-history` part of this error message is now stale, no?


Yes, the error message is obsolete. I will change it in next version.



@@ -397,7 +398,8 @@ static int perf_evlist__tty_browse_hists(struct
perf_evlist *evlist,

hists__fprintf_nr_sample_events(hists, rep, evname, stdout);
hists__fprintf(hists, !quiet, 0, 0, rep->min_percent, stdout,
-  symbol_conf.use_callchain);
+  symbol_conf.use_callchain |
+  symbol_conf.show_branchflag_count);
fprintf(stdout, "\n\n");
}

Not sure about the coding style here, but shouldn't this be a boolean or
operator here '||' - semantically? Functionality wise it will be the same, I
guess?


Should be same. While I will follow your comments to change it to '||'.

I will wait other comments for some days and then send out the next version.

Thanks
Jin Yao

RE: [PATCH] ACPI: SPCR: Use access width to determine mmio usage

[Zheng, Lv]

Hi,

> From: Jon Mason [mailto:jon.ma...@broadcom.com]
> Sent: Thursday, May 4, 2017 11:06 PM
> Subject: [PATCH] ACPI: SPCR: Use access width to determine mmio usage
> 
> The current SPCR code does not check the access width of the mmio, and
> uses a default of 8bit register accesses.  This prevents devices that
> only do 16 or 32bit register accesses from working.  By simply checking
> this field and setting the mmio string appropriately, this issue can be
> corrected.  To prevent any legacy issues, the code will default to 8bit
> accesses if the value is anything but 16 or 32.
> 
> Signed-off-by: Jon Mason 
> ---
>  drivers/acpi/spcr.c | 18 --
>  include/acpi/acrestyp.h |  7 +++
>  2 files changed, 23 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
> index 01c9466..11233f6 100644
> --- a/drivers/acpi/spcr.c
> +++ b/drivers/acpi/spcr.c
> @@ -74,8 +74,22 @@ int __init parse_spcr(bool earlycon)
>   goto done;
>   }
> 
> - iotype = table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY ?
> - "mmio" : "io";
> + if (table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
> + switch (table->serial_port.access_width) {
> + default:
> + pr_err("Unexpected SPCR Access Width.  Defaulting to 
> byte size\n");
> + case ACPI_ACCESS_SIZE_BYTE:
> + iotype = "mmio";
> + break;
> + case ACPI_ACCESS_SIZE_WORD:
> + iotype = "mmio16";
> + break;
> + case ACPI_ACCESS_SIZE_DWORD:
> + iotype = "mmio32";
> + break;
> + }
> + } else
> + iotype = "io";
> 
>   switch (table->interface_type) {
>   case ACPI_DBG2_ARM_SBSA_32BIT:
> diff --git a/include/acpi/acrestyp.h b/include/acpi/acrestyp.h
> index f0f7403..781cb55 100644
> --- a/include/acpi/acrestyp.h
> +++ b/include/acpi/acrestyp.h
> @@ -372,6 +372,13 @@ struct acpi_resource_generic_register {
>   u64 address;
>  };
> 
> +/* Generic Address Space Access Sizes */
> +#define ACPI_ACCESS_SIZE_UNDEFINED   0
> +#define ACPI_ACCESS_SIZE_BYTE1
> +#define ACPI_ACCESS_SIZE_WORD2
> +#define ACPI_ACCESS_SIZE_DWORD   3
> +#define ACPI_ACCESS_SIZE_QWORD   4
> +
>  struct acpi_resource_gpio {
>   u8 revision_id;
>   u8 connection_type;

Please don't define this.
It's possible to calculate 8/16/32/64 from the access width value.
Try:
1 << (access_width + 2）

Thanks
Lv

RE: [PATCH] ACPI: SPCR: Use access width to determine mmio usage

[Zheng, Lv]

Hi,

> From: Jon Mason [mailto:jon.ma...@broadcom.com]
> Sent: Thursday, May 4, 2017 11:06 PM
> Subject: [PATCH] ACPI: SPCR: Use access width to determine mmio usage
> 
> The current SPCR code does not check the access width of the mmio, and
> uses a default of 8bit register accesses.  This prevents devices that
> only do 16 or 32bit register accesses from working.  By simply checking
> this field and setting the mmio string appropriately, this issue can be
> corrected.  To prevent any legacy issues, the code will default to 8bit
> accesses if the value is anything but 16 or 32.
> 
> Signed-off-by: Jon Mason 
> ---
>  drivers/acpi/spcr.c | 18 --
>  include/acpi/acrestyp.h |  7 +++
>  2 files changed, 23 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
> index 01c9466..11233f6 100644
> --- a/drivers/acpi/spcr.c
> +++ b/drivers/acpi/spcr.c
> @@ -74,8 +74,22 @@ int __init parse_spcr(bool earlycon)
>   goto done;
>   }
> 
> - iotype = table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY ?
> - "mmio" : "io";
> + if (table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
> + switch (table->serial_port.access_width) {
> + default:
> + pr_err("Unexpected SPCR Access Width.  Defaulting to 
> byte size\n");
> + case ACPI_ACCESS_SIZE_BYTE:
> + iotype = "mmio";
> + break;
> + case ACPI_ACCESS_SIZE_WORD:
> + iotype = "mmio16";
> + break;
> + case ACPI_ACCESS_SIZE_DWORD:
> + iotype = "mmio32";
> + break;
> + }
> + } else
> + iotype = "io";
> 
>   switch (table->interface_type) {
>   case ACPI_DBG2_ARM_SBSA_32BIT:
> diff --git a/include/acpi/acrestyp.h b/include/acpi/acrestyp.h
> index f0f7403..781cb55 100644
> --- a/include/acpi/acrestyp.h
> +++ b/include/acpi/acrestyp.h
> @@ -372,6 +372,13 @@ struct acpi_resource_generic_register {
>   u64 address;
>  };
> 
> +/* Generic Address Space Access Sizes */
> +#define ACPI_ACCESS_SIZE_UNDEFINED   0
> +#define ACPI_ACCESS_SIZE_BYTE1
> +#define ACPI_ACCESS_SIZE_WORD2
> +#define ACPI_ACCESS_SIZE_DWORD   3
> +#define ACPI_ACCESS_SIZE_QWORD   4
> +
>  struct acpi_resource_gpio {
>   u8 revision_id;
>   u8 connection_type;

Please don't define this.
It's possible to calculate 8/16/32/64 from the access width value.
Try:
1 << (access_width + 2）

Thanks
Lv

Re: [PATCH 04/16] fpga: intel: pcie: parse feature list and create platform device for features.

[Wu Hao]

On Thu, May 04, 2017 at 10:13:41AM -0500, Li, Yi wrote:
> hi Hao
> 
> 
> On 3/30/2017 7:08 AM, Wu Hao wrote:
> >From: Xiao Guangrong 
> >
> >Device Featuer List structure creates a link list of feature headers
> >within the MMIO space to provide an extensiable way of adding features.
> >
> >The Intel FPGA PCIe driver walks through the feature headers to enumerate
> >feature devices, FPGA Management Engine (FME) and FPGA Port for Accelerated
> >Function Unit (AFU), and their private sub features. For feature devices,
> >it creates the platform devices and linked the private sub features into
> >their platform data.
> >
> >Signed-off-by: Tim Whisonant 
> >Signed-off-by: Enno Luebbers 
> >Signed-off-by: Shiva Rao 
> >Signed-off-by: Christopher Rauer 
> >Signed-off-by: Kang Luwei 
> >Signed-off-by: Zhang Yi 
> >Signed-off-by: Xiao Guangrong 
> >Signed-off-by: Wu Hao 
> >---
> >  drivers/fpga/intel/Makefile  |   2 +-
> >  drivers/fpga/intel/feature-dev.c | 139 +++
> >  drivers/fpga/intel/feature-dev.h | 342 
> >  drivers/fpga/intel/pcie.c| 841 
> > ++-
> >  4 files changed, 1321 insertions(+), 3 deletions(-)
> >  create mode 100644 drivers/fpga/intel/feature-dev.c
> >  create mode 100644 drivers/fpga/intel/feature-dev.h
> >
> >.
> >+
> >+static int
> >+build_info_create_dev(struct build_feature_devs_info *binfo,
> >+  enum fpga_id_type type, int feature_nr, const char *name)
> >+{
> >+struct platform_device *fdev;
> >+struct resource *res;
> >+struct feature_platform_data *pdata;
> >+int ret;
> >+
> >+/* we will create a new device, commit current device first */
> >+ret = build_info_commit_dev(binfo);
> 
> Looks like the code create the platform device (prepared by previous
> feature) when prepare the current feature binfo, which I found is somewhat
> confusing. Is there a reason to do so?

Hi Yi,

Driver only creates new platform device when it switches to new feature
device parsing (new feature device found in the 'Device Feature List'),
this code just makes sure previous platform device for last feature device
is committed (platform_device_add). If there is no previous feature device
or previous feature device has been already committed, then this function
build_info_commit_dev will return 0 directly.

Thanks
Hao

> 
> >+if (ret)
> >+return ret;
> >+
> >+/*
> >+ * we use -ENODEV as the initialization indicator which indicates
> >+ * whether the id need to be reclaimed
> >+ */
> >+fdev = binfo->feature_dev = platform_device_alloc(name, -ENODEV);
> >+if (!fdev)
> >+return -ENOMEM;
> >+
> >+fdev->id = alloc_fpga_id(type, >dev);
> >+if (fdev->id < 0)
> >+return fdev->id;
> >+
> >+fdev->dev.parent = >parent_dev->dev;
> >+
> >+/*
> >+ * we need not care the memory which is associated with the
> >+ * platform device. After call platform_device_unregister(),
> >+ * it will be automatically freed by device's
> >+ * release() callback, platform_device_release().
> >+ */
> >+pdata = feature_platform_data_alloc_and_init(fdev, feature_nr);
> >+if (!pdata)
> >+return -ENOMEM;
> >+
> >+/*
> >+ * the count should be initialized to 0 to make sure
> >+ *__fpga_port_enable() following __fpga_port_disable()
> >+ * works properly for port device.
> >+ * and it should always be 0 for fme device.
> >+ */
> >+WARN_ON(pdata->disable_count);
> >+
> >+fdev->dev.platform_data = pdata;
> >+fdev->num_resources = feature_nr;
> >+fdev->resource = kcalloc(feature_nr, sizeof(*res), GFP_KERNEL);
> >+if (!fdev->resource)
> >+return -ENOMEM;
> >+
> >+return 0;
> >+}
> >+
> >

Re: [PATCH 04/16] fpga: intel: pcie: parse feature list and create platform device for features.

[Wu Hao]

On Thu, May 04, 2017 at 10:13:41AM -0500, Li, Yi wrote:
> hi Hao
> 
> 
> On 3/30/2017 7:08 AM, Wu Hao wrote:
> >From: Xiao Guangrong 
> >
> >Device Featuer List structure creates a link list of feature headers
> >within the MMIO space to provide an extensiable way of adding features.
> >
> >The Intel FPGA PCIe driver walks through the feature headers to enumerate
> >feature devices, FPGA Management Engine (FME) and FPGA Port for Accelerated
> >Function Unit (AFU), and their private sub features. For feature devices,
> >it creates the platform devices and linked the private sub features into
> >their platform data.
> >
> >Signed-off-by: Tim Whisonant 
> >Signed-off-by: Enno Luebbers 
> >Signed-off-by: Shiva Rao 
> >Signed-off-by: Christopher Rauer 
> >Signed-off-by: Kang Luwei 
> >Signed-off-by: Zhang Yi 
> >Signed-off-by: Xiao Guangrong 
> >Signed-off-by: Wu Hao 
> >---
> >  drivers/fpga/intel/Makefile  |   2 +-
> >  drivers/fpga/intel/feature-dev.c | 139 +++
> >  drivers/fpga/intel/feature-dev.h | 342 
> >  drivers/fpga/intel/pcie.c| 841 
> > ++-
> >  4 files changed, 1321 insertions(+), 3 deletions(-)
> >  create mode 100644 drivers/fpga/intel/feature-dev.c
> >  create mode 100644 drivers/fpga/intel/feature-dev.h
> >
> >.
> >+
> >+static int
> >+build_info_create_dev(struct build_feature_devs_info *binfo,
> >+  enum fpga_id_type type, int feature_nr, const char *name)
> >+{
> >+struct platform_device *fdev;
> >+struct resource *res;
> >+struct feature_platform_data *pdata;
> >+int ret;
> >+
> >+/* we will create a new device, commit current device first */
> >+ret = build_info_commit_dev(binfo);
> 
> Looks like the code create the platform device (prepared by previous
> feature) when prepare the current feature binfo, which I found is somewhat
> confusing. Is there a reason to do so?

Hi Yi,

Driver only creates new platform device when it switches to new feature
device parsing (new feature device found in the 'Device Feature List'),
this code just makes sure previous platform device for last feature device
is committed (platform_device_add). If there is no previous feature device
or previous feature device has been already committed, then this function
build_info_commit_dev will return 0 directly.

Thanks
Hao

> 
> >+if (ret)
> >+return ret;
> >+
> >+/*
> >+ * we use -ENODEV as the initialization indicator which indicates
> >+ * whether the id need to be reclaimed
> >+ */
> >+fdev = binfo->feature_dev = platform_device_alloc(name, -ENODEV);
> >+if (!fdev)
> >+return -ENOMEM;
> >+
> >+fdev->id = alloc_fpga_id(type, >dev);
> >+if (fdev->id < 0)
> >+return fdev->id;
> >+
> >+fdev->dev.parent = >parent_dev->dev;
> >+
> >+/*
> >+ * we need not care the memory which is associated with the
> >+ * platform device. After call platform_device_unregister(),
> >+ * it will be automatically freed by device's
> >+ * release() callback, platform_device_release().
> >+ */
> >+pdata = feature_platform_data_alloc_and_init(fdev, feature_nr);
> >+if (!pdata)
> >+return -ENOMEM;
> >+
> >+/*
> >+ * the count should be initialized to 0 to make sure
> >+ *__fpga_port_enable() following __fpga_port_disable()
> >+ * works properly for port device.
> >+ * and it should always be 0 for fme device.
> >+ */
> >+WARN_ON(pdata->disable_count);
> >+
> >+fdev->dev.platform_data = pdata;
> >+fdev->num_resources = feature_nr;
> >+fdev->resource = kcalloc(feature_nr, sizeof(*res), GFP_KERNEL);
> >+if (!fdev->resource)
> >+return -ENOMEM;
> >+
> >+return 0;
> >+}
> >+
> >

Re: [linux-sunxi] [PATCH 04/13] drm/sun4i: return only planes for layers created

[Chen-Yu Tsai]

On Thu, May 4, 2017 at 7:41 PM, Icenowy Zheng  wrote:
> As we are going to add support for the Allwinner DE2 Mixer in sun4i-drm
> driver, we will finally have two types of layers.
>
> Each layer is bound to a drm_plane that is CRTC-specific, so we create
> them when initializing CRTC (calling sun4i_layers_init, which will be
> generalized in next patch). The drm_plane's will be used when creating
> CRTC, but the CRTC initialization code do not care other properties of
> the layer, so we let the sun4i_layers_init function return drm_plane's
> only.
>
> As we have no need to trace the layers after the CRTC is properly
> created, we drop the layers pointer in sun4i_crtc struct.
>
> Doing these things makes the CRTC code independent to the type of layer

Doing this uncouples the CRTC code from the type of layer.

> (the sun4i_layers_init function name is still hardcoded and will be
> changed in the next patch), so that we can finally gain support for the
> mixer in DE2, which will has different layers.

... which has ...

>
> Signed-off-by: Icenowy Zheng 

Otherwise,

Reviewed-by: Chen-Yu Tsai 

Re: [linux-sunxi] [PATCH 04/13] drm/sun4i: return only planes for layers created

[Chen-Yu Tsai]

On Thu, May 4, 2017 at 7:41 PM, Icenowy Zheng  wrote:
> As we are going to add support for the Allwinner DE2 Mixer in sun4i-drm
> driver, we will finally have two types of layers.
>
> Each layer is bound to a drm_plane that is CRTC-specific, so we create
> them when initializing CRTC (calling sun4i_layers_init, which will be
> generalized in next patch). The drm_plane's will be used when creating
> CRTC, but the CRTC initialization code do not care other properties of
> the layer, so we let the sun4i_layers_init function return drm_plane's
> only.
>
> As we have no need to trace the layers after the CRTC is properly
> created, we drop the layers pointer in sun4i_crtc struct.
>
> Doing these things makes the CRTC code independent to the type of layer

Doing this uncouples the CRTC code from the type of layer.

> (the sun4i_layers_init function name is still hardcoded and will be
> changed in the next patch), so that we can finally gain support for the
> mixer in DE2, which will has different layers.

... which has ...

>
> Signed-off-by: Icenowy Zheng 

Otherwise,

Reviewed-by: Chen-Yu Tsai 

Re: new ...at() flag: AT_NO_JUMPS

[Al Viro]

On Thu, May 04, 2017 at 06:27:10PM -0700, Linus Torvalds wrote:

> As mentioned last time, at least for the git usage, even relative
> symlinks are a no-no - not because they'd escape, but simply because
> git wants to see the *unique* name, and resolve relative symlinks to
> either the symlink, or to the actual file it points to.
> 
> So I think that we'd want an additional flag that says "no symlinks at all".

OK, that's easily done.

> And I think the "no mountpoint" traversal might be splittable too.
> 
> Yes, sometimes you'd probably want to say "stay exactly inside this
> filesystem" (like find -xdev). So no arguments against AT_XDEV that
> refuses any mount traversal (kind of like my "no symlink traversal"
> thing).
> 
> But at other points you might want to just guarantee that the walk
> stays below a certain starting point and doesn't escape.
> 
> That could still allow crossing mount-points, but only if they are
> non-bind mounts and cannot let us escape.
> 
> I'm not sure if that's testable, though.

This one isn't, unfortunately - there is no difference between bind and
no-bind; vfsmounts form a tree and both normal mount and bind add leaves
to it.  Moreover, mount -t ext2 /dev/sdc7 /mnt; mount -t ext2 /dev/sdc7 /tmp/a
yield the same state as mount -t ext2 /dev/sdc7; mount --bind /mnt /tmp/a.
There is no way to tell the difference, simply because there *is* no
difference.  Moreover, either can be followed by umount /mnt and you'll get
the same state as you would have after a solitary mount of the same fs on
/tmp/a.

Ho-hum...  So:

AT_BENEATH  AT_XDEV AT_NO_SYMLINKS
absolute pathname:  EXDEV
non-relative symlink:   EXDEV   ?   ELOOP
relative symlink:   ELOOP
.. from starting point: EXDEV
.. crossing mountpoint: EXDEV
crossing into mountpoint:   EXDEV

1) What should AT_XDEV do about absolute symlinks?  Nothing special?  EXDEV?
EXDEV if we are not on root?
2) What should AT_BENEATH | AT_NO_SYMLINKS do on absolute symlinks?  My
preference would be "AT_NO_SYMLINKS wins, ELOOP for you", but that's based
mostly upon the convenience of implementation.
3) What effect should AT_NO_SYMLINKS have upon the final component?  Same
as AT_SYMLINK_NOFOLLOW?

Re: new ...at() flag: AT_NO_JUMPS

[Al Viro]

On Thu, May 04, 2017 at 06:27:10PM -0700, Linus Torvalds wrote:

> As mentioned last time, at least for the git usage, even relative
> symlinks are a no-no - not because they'd escape, but simply because
> git wants to see the *unique* name, and resolve relative symlinks to
> either the symlink, or to the actual file it points to.
> 
> So I think that we'd want an additional flag that says "no symlinks at all".

OK, that's easily done.

> And I think the "no mountpoint" traversal might be splittable too.
> 
> Yes, sometimes you'd probably want to say "stay exactly inside this
> filesystem" (like find -xdev). So no arguments against AT_XDEV that
> refuses any mount traversal (kind of like my "no symlink traversal"
> thing).
> 
> But at other points you might want to just guarantee that the walk
> stays below a certain starting point and doesn't escape.
> 
> That could still allow crossing mount-points, but only if they are
> non-bind mounts and cannot let us escape.
> 
> I'm not sure if that's testable, though.

This one isn't, unfortunately - there is no difference between bind and
no-bind; vfsmounts form a tree and both normal mount and bind add leaves
to it.  Moreover, mount -t ext2 /dev/sdc7 /mnt; mount -t ext2 /dev/sdc7 /tmp/a
yield the same state as mount -t ext2 /dev/sdc7; mount --bind /mnt /tmp/a.
There is no way to tell the difference, simply because there *is* no
difference.  Moreover, either can be followed by umount /mnt and you'll get
the same state as you would have after a solitary mount of the same fs on
/tmp/a.

Ho-hum...  So:

AT_BENEATH  AT_XDEV AT_NO_SYMLINKS
absolute pathname:  EXDEV
non-relative symlink:   EXDEV   ?   ELOOP
relative symlink:   ELOOP
.. from starting point: EXDEV
.. crossing mountpoint: EXDEV
crossing into mountpoint:   EXDEV

1) What should AT_XDEV do about absolute symlinks?  Nothing special?  EXDEV?
EXDEV if we are not on root?
2) What should AT_BENEATH | AT_NO_SYMLINKS do on absolute symlinks?  My
preference would be "AT_NO_SYMLINKS wins, ELOOP for you", but that's based
mostly upon the convenience of implementation.
3) What effect should AT_NO_SYMLINKS have upon the final component?  Same
as AT_SYMLINK_NOFOLLOW?

Re: [linux-sunxi] [PATCH v6 05/13] drm/sun4i: abstract a engine type

[Chen-Yu Tsai]

On Thu, May 4, 2017 at 7:48 PM, Icenowy Zheng  wrote:
> As we are going to add support for the Allwinner DE2 engine in sun4i-drm
> driver, we will finally have two types of display engines -- the DE1
> backend and the DE2 mixer. They both do some display blending and feed
> graphics data to TCON, so I choose to call them both "engine" here.

These engines composite different layers into a final image which is
then sent out to the TCONs. As such, "compositor" would be an accurate
name.

However, "engine" is OK, since Allwinner calls this stuff Display Engine
1.0 and 2.0. Hope there won't be a 3.0 ...

Maybe you should note that in your commit message. That is justifies the name.

>
> Abstract the engine type to a new struct with an ops struct, which contains
> functions that should be called outside the engine-specified code (in
> TCON, CRTC or TV Encoder code).
>
> Signed-off-by: Icenowy Zheng 
> ---
> Changes in v6:
> - Rebased on wens's multi-pipeline patchset.
> - Split out Makefile changes.
> Changes in v5:
> - Really made a sunxi_engine struct type, and moved ops pointer
>   into it.
> - Added checked ops wrappers.
> - Changed the second parameter of layers_init from crtc to engine.
> Changes in v4:
> - Comments to tag the color correction functions as optional.
> - Check before calling the optional functions.
> - Change layers_init to satisfy new PATCH v4 04/11.
>
>  drivers/gpu/drm/sun4i/sun4i_backend.c |  68 -
>  drivers/gpu/drm/sun4i/sun4i_backend.h |  17 +++---
>  drivers/gpu/drm/sun4i/sun4i_crtc.c|  11 ++--
>  drivers/gpu/drm/sun4i/sun4i_crtc.h|   4 +-
>  drivers/gpu/drm/sun4i/sun4i_drv.c |   2 +-
>  drivers/gpu/drm/sun4i/sun4i_drv.h |   2 +-
>  drivers/gpu/drm/sun4i/sun4i_layer.c   |   8 +--
>  drivers/gpu/drm/sun4i/sun4i_layer.h   |   5 +-
>  drivers/gpu/drm/sun4i/sun4i_tcon.c|  36 ++-
>  drivers/gpu/drm/sun4i/sun4i_tv.c  |   9 ++-
>  drivers/gpu/drm/sun4i/sunxi_engine.h  | 112 
> ++
>  11 files changed, 198 insertions(+), 76 deletions(-)
>  create mode 100644 drivers/gpu/drm/sun4i/sunxi_engine.h
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
> b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index e53107418add..611cdcb9c182 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -25,6 +25,8 @@
>
>  #include "sun4i_backend.h"
>  #include "sun4i_drv.h"
> +#include "sun4i_layer.h"
> +#include "sunxi_engine.h"
>
>  static const u32 sunxi_rgb2yuv_coef[12] = {
> 0x0107, 0x0204, 0x0064, 0x0108,
> @@ -32,41 +34,38 @@ static const u32 sunxi_rgb2yuv_coef[12] = {
> 0x01c1, 0x3e88, 0x3fb8, 0x0808
>  };
>
> -void sun4i_backend_apply_color_correction(struct sun4i_backend *backend)
> +static void sun4i_backend_apply_color_correction(struct sunxi_engine *engine)
>  {
> int i;
>
> DRM_DEBUG_DRIVER("Applying RGB to YUV color correction\n");
>
> /* Set color correction */
> -   regmap_write(backend->regs, SUN4I_BACKEND_OCCTL_REG,
> +   regmap_write(engine->regs, SUN4I_BACKEND_OCCTL_REG,
>  SUN4I_BACKEND_OCCTL_ENABLE);
>
> for (i = 0; i < 12; i++)
> -   regmap_write(backend->regs, SUN4I_BACKEND_OCRCOEF_REG(i),
> +   regmap_write(engine->regs, SUN4I_BACKEND_OCRCOEF_REG(i),
>  sunxi_rgb2yuv_coef[i]);
>  }
> -EXPORT_SYMBOL(sun4i_backend_apply_color_correction);
>
> -void sun4i_backend_disable_color_correction(struct sun4i_backend *backend)
> +static void sun4i_backend_disable_color_correction(struct sunxi_engine 
> *engine)
>  {
> DRM_DEBUG_DRIVER("Disabling color correction\n");
>
> /* Disable color correction */
> -   regmap_update_bits(backend->regs, SUN4I_BACKEND_OCCTL_REG,
> +   regmap_update_bits(engine->regs, SUN4I_BACKEND_OCCTL_REG,
>SUN4I_BACKEND_OCCTL_ENABLE, 0);
>  }
> -EXPORT_SYMBOL(sun4i_backend_disable_color_correction);
>
> -void sun4i_backend_commit(struct sun4i_backend *backend)
> +static void sun4i_backend_commit(struct sunxi_engine *engine)
>  {
> DRM_DEBUG_DRIVER("Committing changes\n");
>
> -   regmap_write(backend->regs, SUN4I_BACKEND_REGBUFFCTL_REG,
> +   regmap_write(engine->regs, SUN4I_BACKEND_REGBUFFCTL_REG,
>  SUN4I_BACKEND_REGBUFFCTL_AUTOLOAD_DIS |
>  SUN4I_BACKEND_REGBUFFCTL_LOADCTL);
>  }
> -EXPORT_SYMBOL(sun4i_backend_commit);
>
>  void sun4i_backend_layer_enable(struct sun4i_backend *backend,
> int layer, bool enable)
> @@ -81,7 +80,7 @@ void sun4i_backend_layer_enable(struct sun4i_backend 
> *backend,
> else
> val = 0;
>
> -   regmap_update_bits(backend->regs, SUN4I_BACKEND_MODCTL_REG,
> +   regmap_update_bits(backend->engine.regs, SUN4I_BACKEND_MODCTL_REG,
>

Re: [linux-sunxi] [PATCH v6 05/13] drm/sun4i: abstract a engine type

[Chen-Yu Tsai]

On Thu, May 4, 2017 at 7:48 PM, Icenowy Zheng  wrote:
> As we are going to add support for the Allwinner DE2 engine in sun4i-drm
> driver, we will finally have two types of display engines -- the DE1
> backend and the DE2 mixer. They both do some display blending and feed
> graphics data to TCON, so I choose to call them both "engine" here.

These engines composite different layers into a final image which is
then sent out to the TCONs. As such, "compositor" would be an accurate
name.

However, "engine" is OK, since Allwinner calls this stuff Display Engine
1.0 and 2.0. Hope there won't be a 3.0 ...

Maybe you should note that in your commit message. That is justifies the name.

>
> Abstract the engine type to a new struct with an ops struct, which contains
> functions that should be called outside the engine-specified code (in
> TCON, CRTC or TV Encoder code).
>
> Signed-off-by: Icenowy Zheng 
> ---
> Changes in v6:
> - Rebased on wens's multi-pipeline patchset.
> - Split out Makefile changes.
> Changes in v5:
> - Really made a sunxi_engine struct type, and moved ops pointer
>   into it.
> - Added checked ops wrappers.
> - Changed the second parameter of layers_init from crtc to engine.
> Changes in v4:
> - Comments to tag the color correction functions as optional.
> - Check before calling the optional functions.
> - Change layers_init to satisfy new PATCH v4 04/11.
>
>  drivers/gpu/drm/sun4i/sun4i_backend.c |  68 -
>  drivers/gpu/drm/sun4i/sun4i_backend.h |  17 +++---
>  drivers/gpu/drm/sun4i/sun4i_crtc.c|  11 ++--
>  drivers/gpu/drm/sun4i/sun4i_crtc.h|   4 +-
>  drivers/gpu/drm/sun4i/sun4i_drv.c |   2 +-
>  drivers/gpu/drm/sun4i/sun4i_drv.h |   2 +-
>  drivers/gpu/drm/sun4i/sun4i_layer.c   |   8 +--
>  drivers/gpu/drm/sun4i/sun4i_layer.h   |   5 +-
>  drivers/gpu/drm/sun4i/sun4i_tcon.c|  36 ++-
>  drivers/gpu/drm/sun4i/sun4i_tv.c  |   9 ++-
>  drivers/gpu/drm/sun4i/sunxi_engine.h  | 112 
> ++
>  11 files changed, 198 insertions(+), 76 deletions(-)
>  create mode 100644 drivers/gpu/drm/sun4i/sunxi_engine.h
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
> b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index e53107418add..611cdcb9c182 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -25,6 +25,8 @@
>
>  #include "sun4i_backend.h"
>  #include "sun4i_drv.h"
> +#include "sun4i_layer.h"
> +#include "sunxi_engine.h"
>
>  static const u32 sunxi_rgb2yuv_coef[12] = {
> 0x0107, 0x0204, 0x0064, 0x0108,
> @@ -32,41 +34,38 @@ static const u32 sunxi_rgb2yuv_coef[12] = {
> 0x01c1, 0x3e88, 0x3fb8, 0x0808
>  };
>
> -void sun4i_backend_apply_color_correction(struct sun4i_backend *backend)
> +static void sun4i_backend_apply_color_correction(struct sunxi_engine *engine)
>  {
> int i;
>
> DRM_DEBUG_DRIVER("Applying RGB to YUV color correction\n");
>
> /* Set color correction */
> -   regmap_write(backend->regs, SUN4I_BACKEND_OCCTL_REG,
> +   regmap_write(engine->regs, SUN4I_BACKEND_OCCTL_REG,
>  SUN4I_BACKEND_OCCTL_ENABLE);
>
> for (i = 0; i < 12; i++)
> -   regmap_write(backend->regs, SUN4I_BACKEND_OCRCOEF_REG(i),
> +   regmap_write(engine->regs, SUN4I_BACKEND_OCRCOEF_REG(i),
>  sunxi_rgb2yuv_coef[i]);
>  }
> -EXPORT_SYMBOL(sun4i_backend_apply_color_correction);
>
> -void sun4i_backend_disable_color_correction(struct sun4i_backend *backend)
> +static void sun4i_backend_disable_color_correction(struct sunxi_engine 
> *engine)
>  {
> DRM_DEBUG_DRIVER("Disabling color correction\n");
>
> /* Disable color correction */
> -   regmap_update_bits(backend->regs, SUN4I_BACKEND_OCCTL_REG,
> +   regmap_update_bits(engine->regs, SUN4I_BACKEND_OCCTL_REG,
>SUN4I_BACKEND_OCCTL_ENABLE, 0);
>  }
> -EXPORT_SYMBOL(sun4i_backend_disable_color_correction);
>
> -void sun4i_backend_commit(struct sun4i_backend *backend)
> +static void sun4i_backend_commit(struct sunxi_engine *engine)
>  {
> DRM_DEBUG_DRIVER("Committing changes\n");
>
> -   regmap_write(backend->regs, SUN4I_BACKEND_REGBUFFCTL_REG,
> +   regmap_write(engine->regs, SUN4I_BACKEND_REGBUFFCTL_REG,
>  SUN4I_BACKEND_REGBUFFCTL_AUTOLOAD_DIS |
>  SUN4I_BACKEND_REGBUFFCTL_LOADCTL);
>  }
> -EXPORT_SYMBOL(sun4i_backend_commit);
>
>  void sun4i_backend_layer_enable(struct sun4i_backend *backend,
> int layer, bool enable)
> @@ -81,7 +80,7 @@ void sun4i_backend_layer_enable(struct sun4i_backend 
> *backend,
> else
> val = 0;
>
> -   regmap_update_bits(backend->regs, SUN4I_BACKEND_MODCTL_REG,
> +   regmap_update_bits(backend->engine.regs, SUN4I_BACKEND_MODCTL_REG,
>SUN4I_BACKEND_MODCTL_LAY_EN(layer), 

[GIT PULL] liblockdep for 4.12

[alexander . levin]

Hi Ingo,

Please pull fixes for liblockdep.

===

The following changes since commit a351e9b9fc24e982ec2f0e76379a49826036da12:

  Linux 4.11 (2017-04-30 19:47:48 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux.git 
liblockdep-fixes

for you to fetch changes up to ec3cedc646ea697c849fe651f62ed448760ea569:

  tools: liblockdep: Use LDFLAGS (2017-05-04 21:34:07 -0400)


Alexander Sverdlin (2):
  tools: add install make target for liblockdep
  tools: liblockdep: Don't mix fd-based and stream IO

Ben Hutchings (10):
  liblockdep: Fix undefined symbol prandom_u32
  liblockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain::depth
  liblockdep: Define the ARRAY_SIZE() macro
  liblockdep: Enable -Wall by default
  liblockdep: Fix 'unused value' warnings
  liblockdep: Fix 'set but not used' warnings
  liblockdep: Fix 'defined but not used' warning for init_utsname()
  tools: liblockdep: Fix object file paths used in an out-of-tree build
  tools: liblockdep: Remove double-quotes from soname
  tools: liblockdep: Use LDFLAGS

Sasha Levin (2):
  MAINTAINERS: update email for Sasha Levin
  tools: liblockdep: fix compilation for 4.11

Vishal Thanki (1):
  liblockdep: Remove -lpthread compiler option

 MAINTAINERS|   2 +-
 tools/Makefile |   8 +-
 tools/include/linux/bitops.h   |  10 ++
 tools/include/linux/jhash.h| 125 +++
 tools/include/linux/sched/clock.h  |   0
 tools/include/linux/sched/task.h   |   0
 tools/include/linux/unaligned/packed_struct.h  |   0
 tools/lib/lockdep/Makefile |   9 +-
 tools/lib/lockdep/lockdep.c|  17 +++
 tools/lib/lockdep/preload.c|   3 +-
 tools/lib/lockdep/run_tests.sh |   4 +-
 tools/lib/lockdep/uinclude/linux/bitops.h  |   3 -
 tools/lib/lockdep/uinclude/linux/debug_locks.h |   2 +-
 tools/lib/lockdep/uinclude/linux/irqflags.h|   8 +-
 tools/lib/lockdep/uinclude/linux/kallsyms.h|   3 +-
 tools/lib/lockdep/uinclude/linux/kernel.h  |  16 ++-
 tools/lib/lockdep/uinclude/linux/lockdep.h |  21 ++--
 tools/lib/lockdep/uinclude/linux/rcu.h |   2 +
 18 files changed, 198 insertions(+), 35 deletions(-)
 create mode 100644 tools/include/linux/jhash.h
 create mode 100644 tools/include/linux/sched/clock.h
 create mode 100644 tools/include/linux/sched/task.h
 create mode 100644 tools/include/linux/unaligned/packed_struct.h
 delete mode 100644 tools/lib/lockdep/uinclude/linux/bitops.h

-- 

Thanks,
Sasha

[GIT PULL] liblockdep for 4.12

[alexander . levin]

Hi Ingo,

Please pull fixes for liblockdep.

===

The following changes since commit a351e9b9fc24e982ec2f0e76379a49826036da12:

  Linux 4.11 (2017-04-30 19:47:48 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux.git 
liblockdep-fixes

for you to fetch changes up to ec3cedc646ea697c849fe651f62ed448760ea569:

  tools: liblockdep: Use LDFLAGS (2017-05-04 21:34:07 -0400)


Alexander Sverdlin (2):
  tools: add install make target for liblockdep
  tools: liblockdep: Don't mix fd-based and stream IO

Ben Hutchings (10):
  liblockdep: Fix undefined symbol prandom_u32
  liblockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain::depth
  liblockdep: Define the ARRAY_SIZE() macro
  liblockdep: Enable -Wall by default
  liblockdep: Fix 'unused value' warnings
  liblockdep: Fix 'set but not used' warnings
  liblockdep: Fix 'defined but not used' warning for init_utsname()
  tools: liblockdep: Fix object file paths used in an out-of-tree build
  tools: liblockdep: Remove double-quotes from soname
  tools: liblockdep: Use LDFLAGS

Sasha Levin (2):
  MAINTAINERS: update email for Sasha Levin
  tools: liblockdep: fix compilation for 4.11

Vishal Thanki (1):
  liblockdep: Remove -lpthread compiler option

 MAINTAINERS|   2 +-
 tools/Makefile |   8 +-
 tools/include/linux/bitops.h   |  10 ++
 tools/include/linux/jhash.h| 125 +++
 tools/include/linux/sched/clock.h  |   0
 tools/include/linux/sched/task.h   |   0
 tools/include/linux/unaligned/packed_struct.h  |   0
 tools/lib/lockdep/Makefile |   9 +-
 tools/lib/lockdep/lockdep.c|  17 +++
 tools/lib/lockdep/preload.c|   3 +-
 tools/lib/lockdep/run_tests.sh |   4 +-
 tools/lib/lockdep/uinclude/linux/bitops.h  |   3 -
 tools/lib/lockdep/uinclude/linux/debug_locks.h |   2 +-
 tools/lib/lockdep/uinclude/linux/irqflags.h|   8 +-
 tools/lib/lockdep/uinclude/linux/kallsyms.h|   3 +-
 tools/lib/lockdep/uinclude/linux/kernel.h  |  16 ++-
 tools/lib/lockdep/uinclude/linux/lockdep.h |  21 ++--
 tools/lib/lockdep/uinclude/linux/rcu.h |   2 +
 18 files changed, 198 insertions(+), 35 deletions(-)
 create mode 100644 tools/include/linux/jhash.h
 create mode 100644 tools/include/linux/sched/clock.h
 create mode 100644 tools/include/linux/sched/task.h
 create mode 100644 tools/include/linux/unaligned/packed_struct.h
 delete mode 100644 tools/lib/lockdep/uinclude/linux/bitops.h

-- 

Thanks,
Sasha

[PATCH] tcmu: Add fifo type waiter list support to avoid starvation

[lixiubo]

From: Xiubo Li 

The fifo type waiter list will hold the udevs who are waiting for the
blocks from the data global pool. The unmap thread will try to feed the
first udevs in waiter list, if the global free blocks available are
not enough, it will stop traversing the list and abort waking up the
others.

Signed-off-by: Xiubo Li 
---
 drivers/target/target_core_user.c | 82 +++
 1 file changed, 66 insertions(+), 16 deletions(-)

diff --git a/drivers/target/target_core_user.c 
b/drivers/target/target_core_user.c
index 9045837..10c99e7 100644
--- a/drivers/target/target_core_user.c
+++ b/drivers/target/target_core_user.c
@@ -97,6 +97,7 @@ struct tcmu_hba {
 
 struct tcmu_dev {
struct list_head node;
+   struct list_head waiter;
 
struct se_device se_dev;
 
@@ -123,7 +124,7 @@ struct tcmu_dev {
wait_queue_head_t wait_cmdr;
struct mutex cmdr_lock;
 
-   bool waiting_global;
+   uint32_t waiting_blocks;
uint32_t dbi_max;
uint32_t dbi_thresh;
DECLARE_BITMAP(data_bitmap, DATA_BLOCK_BITS);
@@ -165,6 +166,10 @@ struct tcmu_cmd {
 static DEFINE_MUTEX(root_udev_mutex);
 static LIST_HEAD(root_udev);
 
+/* The data blocks global pool waiter list */
+static DEFINE_MUTEX(root_udev_waiter_mutex);
+static LIST_HEAD(root_udev_waiter);
+
 static atomic_t global_db_count = ATOMIC_INIT(0);
 
 static struct kmem_cache *tcmu_cmd_cache;
@@ -195,6 +200,11 @@ enum tcmu_multicast_groups {
 #define tcmu_cmd_set_dbi(cmd, index) ((cmd)->dbi[(cmd)->dbi_cur++] = (index))
 #define tcmu_cmd_get_dbi(cmd) ((cmd)->dbi[(cmd)->dbi_cur++])
 
+static inline bool is_in_waiter_list(struct tcmu_dev *udev)
+{
+   return !!udev->waiting_blocks;
+}
+
 static void tcmu_cmd_free_data(struct tcmu_cmd *tcmu_cmd, uint32_t len)
 {
struct tcmu_dev *udev = tcmu_cmd->tcmu_dev;
@@ -250,8 +260,6 @@ static bool tcmu_get_empty_blocks(struct tcmu_dev *udev,
 {
int i;
 
-   udev->waiting_global = false;
-
for (i = tcmu_cmd->dbi_cur; i < tcmu_cmd->dbi_cnt; i++) {
if (!tcmu_get_empty_block(udev, tcmu_cmd))
goto err;
@@ -259,9 +267,7 @@ static bool tcmu_get_empty_blocks(struct tcmu_dev *udev,
return true;
 
 err:
-   udev->waiting_global = true;
-   /* Try to wake up the unmap thread */
-   wake_up(_wait);
+   udev->waiting_blocks += tcmu_cmd->dbi_cnt - i;
return false;
 }
 
@@ -671,6 +677,7 @@ static inline size_t tcmu_cmd_get_cmd_size(struct tcmu_cmd 
*tcmu_cmd,
 
while (!is_ring_space_avail(udev, tcmu_cmd, command_size, data_length)) 
{
int ret;
+   bool is_waiting_blocks = !!udev->waiting_blocks;
DEFINE_WAIT(__wait);
 
prepare_to_wait(>wait_cmdr, &__wait, TASK_INTERRUPTIBLE);
@@ -688,6 +695,18 @@ static inline size_t tcmu_cmd_get_cmd_size(struct tcmu_cmd 
*tcmu_cmd,
return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE;
}
 
+   /*
+* Try to insert the current udev to waiter list and
+* then wake up the unmap thread
+*/
+   if (is_waiting_blocks) {
+   mutex_lock(_udev_waiter_mutex);
+   list_add_tail(>waiter, _udev_waiter);
+   mutex_unlock(_udev_waiter_mutex);
+
+   wake_up(_wait);
+   }
+
mutex_lock(>cmdr_lock);
 
/* We dropped cmdr_lock, cmd_head is stale */
@@ -902,8 +921,6 @@ static unsigned int tcmu_handle_completions(struct tcmu_dev 
*udev)
if (mb->cmd_tail == mb->cmd_head)
del_timer(>timeout); /* no more pending cmds */
 
-   wake_up(>wait_cmdr);
-
return handled;
 }
 
@@ -996,7 +1013,17 @@ static int tcmu_irqcontrol(struct uio_info *info, s32 
irq_on)
struct tcmu_dev *tcmu_dev = container_of(info, struct tcmu_dev, 
uio_info);
 
mutex_lock(_dev->cmdr_lock);
-   tcmu_handle_completions(tcmu_dev);
+   /*
+* If the current udev is also in waiter list, this will
+* make sure that the other waiters in list be feeded ahead
+* of it.
+*/
+   if (is_in_waiter_list(tcmu_dev)) {
+   wake_up(_wait);
+   } else {
+   tcmu_handle_completions(tcmu_dev);
+   wake_up(_dev->wait_cmdr);
+   }
mutex_unlock(_dev->cmdr_lock);
 
return 0;
@@ -1231,7 +1258,7 @@ static int tcmu_configure_device(struct se_device *dev)
udev->data_off = CMDR_SIZE;
udev->data_size = DATA_SIZE;
udev->dbi_thresh = 0; /* Default in Idle state */
-   udev->waiting_global = false;
+   udev->waiting_blocks = 0;
 
/* Initialise the mailbox of the ring buffer */
mb = udev->mb_addr;
@@ -1345,6 +1372,13 @@ static void tcmu_free_device(struct se_device *dev)

[PATCH] tcmu: Add fifo type waiter list support to avoid starvation

[lixiubo]

From: Xiubo Li 

The fifo type waiter list will hold the udevs who are waiting for the
blocks from the data global pool. The unmap thread will try to feed the
first udevs in waiter list, if the global free blocks available are
not enough, it will stop traversing the list and abort waking up the
others.

Signed-off-by: Xiubo Li 
---
 drivers/target/target_core_user.c | 82 +++
 1 file changed, 66 insertions(+), 16 deletions(-)

diff --git a/drivers/target/target_core_user.c 
b/drivers/target/target_core_user.c
index 9045837..10c99e7 100644
--- a/drivers/target/target_core_user.c
+++ b/drivers/target/target_core_user.c
@@ -97,6 +97,7 @@ struct tcmu_hba {
 
 struct tcmu_dev {
struct list_head node;
+   struct list_head waiter;
 
struct se_device se_dev;
 
@@ -123,7 +124,7 @@ struct tcmu_dev {
wait_queue_head_t wait_cmdr;
struct mutex cmdr_lock;
 
-   bool waiting_global;
+   uint32_t waiting_blocks;
uint32_t dbi_max;
uint32_t dbi_thresh;
DECLARE_BITMAP(data_bitmap, DATA_BLOCK_BITS);
@@ -165,6 +166,10 @@ struct tcmu_cmd {
 static DEFINE_MUTEX(root_udev_mutex);
 static LIST_HEAD(root_udev);
 
+/* The data blocks global pool waiter list */
+static DEFINE_MUTEX(root_udev_waiter_mutex);
+static LIST_HEAD(root_udev_waiter);
+
 static atomic_t global_db_count = ATOMIC_INIT(0);
 
 static struct kmem_cache *tcmu_cmd_cache;
@@ -195,6 +200,11 @@ enum tcmu_multicast_groups {
 #define tcmu_cmd_set_dbi(cmd, index) ((cmd)->dbi[(cmd)->dbi_cur++] = (index))
 #define tcmu_cmd_get_dbi(cmd) ((cmd)->dbi[(cmd)->dbi_cur++])
 
+static inline bool is_in_waiter_list(struct tcmu_dev *udev)
+{
+   return !!udev->waiting_blocks;
+}
+
 static void tcmu_cmd_free_data(struct tcmu_cmd *tcmu_cmd, uint32_t len)
 {
struct tcmu_dev *udev = tcmu_cmd->tcmu_dev;
@@ -250,8 +260,6 @@ static bool tcmu_get_empty_blocks(struct tcmu_dev *udev,
 {
int i;
 
-   udev->waiting_global = false;
-
for (i = tcmu_cmd->dbi_cur; i < tcmu_cmd->dbi_cnt; i++) {
if (!tcmu_get_empty_block(udev, tcmu_cmd))
goto err;
@@ -259,9 +267,7 @@ static bool tcmu_get_empty_blocks(struct tcmu_dev *udev,
return true;
 
 err:
-   udev->waiting_global = true;
-   /* Try to wake up the unmap thread */
-   wake_up(_wait);
+   udev->waiting_blocks += tcmu_cmd->dbi_cnt - i;
return false;
 }
 
@@ -671,6 +677,7 @@ static inline size_t tcmu_cmd_get_cmd_size(struct tcmu_cmd 
*tcmu_cmd,
 
while (!is_ring_space_avail(udev, tcmu_cmd, command_size, data_length)) 
{
int ret;
+   bool is_waiting_blocks = !!udev->waiting_blocks;
DEFINE_WAIT(__wait);
 
prepare_to_wait(>wait_cmdr, &__wait, TASK_INTERRUPTIBLE);
@@ -688,6 +695,18 @@ static inline size_t tcmu_cmd_get_cmd_size(struct tcmu_cmd 
*tcmu_cmd,
return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE;
}
 
+   /*
+* Try to insert the current udev to waiter list and
+* then wake up the unmap thread
+*/
+   if (is_waiting_blocks) {
+   mutex_lock(_udev_waiter_mutex);
+   list_add_tail(>waiter, _udev_waiter);
+   mutex_unlock(_udev_waiter_mutex);
+
+   wake_up(_wait);
+   }
+
mutex_lock(>cmdr_lock);
 
/* We dropped cmdr_lock, cmd_head is stale */
@@ -902,8 +921,6 @@ static unsigned int tcmu_handle_completions(struct tcmu_dev 
*udev)
if (mb->cmd_tail == mb->cmd_head)
del_timer(>timeout); /* no more pending cmds */
 
-   wake_up(>wait_cmdr);
-
return handled;
 }
 
@@ -996,7 +1013,17 @@ static int tcmu_irqcontrol(struct uio_info *info, s32 
irq_on)
struct tcmu_dev *tcmu_dev = container_of(info, struct tcmu_dev, 
uio_info);
 
mutex_lock(_dev->cmdr_lock);
-   tcmu_handle_completions(tcmu_dev);
+   /*
+* If the current udev is also in waiter list, this will
+* make sure that the other waiters in list be feeded ahead
+* of it.
+*/
+   if (is_in_waiter_list(tcmu_dev)) {
+   wake_up(_wait);
+   } else {
+   tcmu_handle_completions(tcmu_dev);
+   wake_up(_dev->wait_cmdr);
+   }
mutex_unlock(_dev->cmdr_lock);
 
return 0;
@@ -1231,7 +1258,7 @@ static int tcmu_configure_device(struct se_device *dev)
udev->data_off = CMDR_SIZE;
udev->data_size = DATA_SIZE;
udev->dbi_thresh = 0; /* Default in Idle state */
-   udev->waiting_global = false;
+   udev->waiting_blocks = 0;
 
/* Initialise the mailbox of the ring buffer */
mb = udev->mb_addr;
@@ -1345,6 +1372,13 @@ static void tcmu_free_device(struct se_device *dev)
list_del(>node);
mutex_unlock(_udev_mutex);
 
+ 

Re: new ...at() flag: AT_NO_JUMPS

[Jann Horn]

+CC drysdale in case he has thoughts on this

On Fri, May 5, 2017 at 2:30 AM, Al Viro  wrote:
> On Mon, May 01, 2017 at 07:36:52PM +0200, Jann Horn wrote:
>
>> Oh, nice!
>>
>> It looks like this is somewhat similar to the old O_BENEATH proposal,
>> but because the intentions behind the proposals are different
>> (application sandboxing versus permitting an application to restrict its
>> own filesystem accesses), the semantics differ: AT_NO_JUMPS
>> doesn't prevent starting the path with "/", but does prevent mountpoint
>> traversal. Is that correct?
>
> It prevents both, actually - I missed that in description, but this
> if (unlikely(nd->flags & LOOKUP_NO_JUMPS))
> return -ELOOP;
> in nd_jump_root() affects absolute pathnames same way as it affects
> absolute symlinks.
>
> It's not quite O_BENEATH, and IMO it's saner that way - a/b/c/../d is
> bloody well allowed, and so are relative symlinks that do not lead out of
> the subtree.  If somebody has a good argument in favour of flat-out
> ban on .. (_other_ than "other guys do it that way, and it doesn't need
> to make sense 'cuz security!!1!!!", please), I'd be glad to hear it.

One annoying edgecase might be what happens when one thread
does an AT_BENEATH walk while another thread mutates the directory
structure. If some directory that is currently being traversed by the walk
is moved out of the directory at which the walk started, would that be
detected somehow, or could the walk then follow ".." path
components up to the root directory of the current process / of the
namespace the fd is referring to? As in:

Thread 1 starts an AT_BENEATH path walk using an O_PATH fd
pointing to /srv/www/example.org/foo; the path given to the syscall is
"bar/../../../../etc/passwd". The path walk enters the "bar" directory.
Thread 2 moves /srv/www/example.org/foo/bar to
/srv/www/example.org/bar.
Thread 1 processes the rest of the path ("../../../../etc/passwd"), never
hitting /srv/www/example.org/foo in the process.

I'm not really familiar with the VFS internals, but from a coarse look
at the patch, it seems like it wouldn't block this?

Re: new ...at() flag: AT_NO_JUMPS

[Jann Horn]

+CC drysdale in case he has thoughts on this

On Fri, May 5, 2017 at 2:30 AM, Al Viro  wrote:
> On Mon, May 01, 2017 at 07:36:52PM +0200, Jann Horn wrote:
>
>> Oh, nice!
>>
>> It looks like this is somewhat similar to the old O_BENEATH proposal,
>> but because the intentions behind the proposals are different
>> (application sandboxing versus permitting an application to restrict its
>> own filesystem accesses), the semantics differ: AT_NO_JUMPS
>> doesn't prevent starting the path with "/", but does prevent mountpoint
>> traversal. Is that correct?
>
> It prevents both, actually - I missed that in description, but this
> if (unlikely(nd->flags & LOOKUP_NO_JUMPS))
> return -ELOOP;
> in nd_jump_root() affects absolute pathnames same way as it affects
> absolute symlinks.
>
> It's not quite O_BENEATH, and IMO it's saner that way - a/b/c/../d is
> bloody well allowed, and so are relative symlinks that do not lead out of
> the subtree.  If somebody has a good argument in favour of flat-out
> ban on .. (_other_ than "other guys do it that way, and it doesn't need
> to make sense 'cuz security!!1!!!", please), I'd be glad to hear it.

One annoying edgecase might be what happens when one thread
does an AT_BENEATH walk while another thread mutates the directory
structure. If some directory that is currently being traversed by the walk
is moved out of the directory at which the walk started, would that be
detected somehow, or could the walk then follow ".." path
components up to the root directory of the current process / of the
namespace the fd is referring to? As in:

Thread 1 starts an AT_BENEATH path walk using an O_PATH fd
pointing to /srv/www/example.org/foo; the path given to the syscall is
"bar/../../../../etc/passwd". The path walk enters the "bar" directory.
Thread 2 moves /srv/www/example.org/foo/bar to
/srv/www/example.org/bar.
Thread 1 processes the rest of the path ("../../../../etc/passwd"), never
hitting /srv/www/example.org/foo in the process.

I'm not really familiar with the VFS internals, but from a coarse look
at the patch, it seems like it wouldn't block this?