Re: [PATCH v2] perf/sdt: Show proper hint

[Ingo Molnar]

* Arnaldo Carvalho de Melo  wrote:

> Em Fri, Feb 03, 2017 at 03:56:42PM +0530, Ravi Bangoria escreveu:
> > After patch:
> >   $ perf record -a -e sdt_glib:idle__add
> > event syntax error: 'sdt_glib:idle__add'
> >  \___ unknown tracepoint
> > 
> > Error: File /sys/kernel/debug/tracing/events/sdt_glib/idle__add not 
> > found.
> > Hint:  SDT event cannot be directly recorded on. Please use 'perf probe 
> > sdt_glib:idle__add' before recording it.
> > ...
> > 
> >   $ perf probe sdt_glib:idle__add
> > Added new event:
> >   sdt_glib:idle__add   (on %idle__add in 
> > /usr/lib64/libglib-2.0.so.0.5000.2)
> > 
> > You can now use it in all perf tools, such as:
> > 
> > perf record -e sdt_glib:idle__add -aR sleep 1
> > 
> >   $ perf record -a -e sdt_glib:idle__add
> > [ perf record: Woken up 1 times to write data ]
> > [ perf record: Captured and wrote 0.175 MB perf.data ]
> 
> Looks much better! Thanks!
> 
> Unsure if we should state somewhere that this needs to be done only once
> per boot.
> 
> Ingo, are you ok now? Ack?

Yeah, looks perfect to me!

Acked-by: Ingo Molnar 

Thanks,

Ingo

Re: [PATCH v2] perf/sdt: Show proper hint

[Ingo Molnar]

* Arnaldo Carvalho de Melo  wrote:

> Em Fri, Feb 03, 2017 at 03:56:42PM +0530, Ravi Bangoria escreveu:
> > After patch:
> >   $ perf record -a -e sdt_glib:idle__add
> > event syntax error: 'sdt_glib:idle__add'
> >  \___ unknown tracepoint
> > 
> > Error: File /sys/kernel/debug/tracing/events/sdt_glib/idle__add not 
> > found.
> > Hint:  SDT event cannot be directly recorded on. Please use 'perf probe 
> > sdt_glib:idle__add' before recording it.
> > ...
> > 
> >   $ perf probe sdt_glib:idle__add
> > Added new event:
> >   sdt_glib:idle__add   (on %idle__add in 
> > /usr/lib64/libglib-2.0.so.0.5000.2)
> > 
> > You can now use it in all perf tools, such as:
> > 
> > perf record -e sdt_glib:idle__add -aR sleep 1
> > 
> >   $ perf record -a -e sdt_glib:idle__add
> > [ perf record: Woken up 1 times to write data ]
> > [ perf record: Captured and wrote 0.175 MB perf.data ]
> 
> Looks much better! Thanks!
> 
> Unsure if we should state somewhere that this needs to be done only once
> per boot.
> 
> Ingo, are you ok now? Ack?

Yeah, looks perfect to me!

Acked-by: Ingo Molnar 

Thanks,

Ingo

Re: [PATCH 3/7] efi: Add SHIM and image security database GUID definitions

[Ingo Molnar]

* Ard Biesheuvel  wrote:

> From: David Howells 
> 
> Add the definitions for shim and image security database, both of which
> are used widely in various Linux distros.
> 
> Signed-off-by: Josh Boyer 
> Signed-off-by: David Howells 
> Cc: Matt Fleming 
> Signed-off-by: Ard Biesheuvel 

That's not a valid SOB chain: the SOB of the author of the patch (David 
Howells) 
must come first.

I changed it to:

  Signed-off-by: David Howells 
  Acked-by: Josh Boyer 
  Cc: Matt Fleming 
  Signed-off-by: Ard Biesheuvel 

Please holler if that's not OK.

Thanks,

Ingo

Re: [PATCH 3/7] efi: Add SHIM and image security database GUID definitions

[Ingo Molnar]

* Ard Biesheuvel  wrote:

> From: David Howells 
> 
> Add the definitions for shim and image security database, both of which
> are used widely in various Linux distros.
> 
> Signed-off-by: Josh Boyer 
> Signed-off-by: David Howells 
> Cc: Matt Fleming 
> Signed-off-by: Ard Biesheuvel 

That's not a valid SOB chain: the SOB of the author of the patch (David 
Howells) 
must come first.

I changed it to:

  Signed-off-by: David Howells 
  Acked-by: Josh Boyer 
  Cc: Matt Fleming 
  Signed-off-by: Ard Biesheuvel 

Please holler if that's not OK.

Thanks,

Ingo

Re: [PATCH V3 3/4] arch/powerpc: Implement Optprobes

[Naveen N. Rao]

On 2017/02/07 10:05AM, Masami Hiramatsu wrote:
> On Sat, 4 Feb 2017 01:09:49 +0530
> "Naveen N. Rao"  wrote:
> 
> > Hi Michael,
> > Thanks for the review! I'll defer to Anju on most of the aspects, but...
> > 
> > On 2017/02/01 09:53PM, Michael Ellerman wrote:
> > > Anju T Sudhakar  writes:
> > > 
> > > > +static void optimized_callback(struct optimized_kprobe *op,
> > > > +  struct pt_regs *regs)
> > > > +{
> > > > +   struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> > > > +   unsigned long flags;
> > > > +
> > > > +   /* This is possible if op is under delayed unoptimizing */
> > > > +   if (kprobe_disabled(>kp))
> > > > +   return;
> > > > +
> > > > +   local_irq_save(flags);
> > > 
> > > What is that protecting against? Because on powerpc it doesn't actually
> > > disable interrupts, it just masks some of them, the perf interrupt for
> > > example can still run.
> > 
> > That's an excellent catch, as always! :)
> > 
> > This is meant to prevent us from missing kprobe hits while processing 
> > interrupts that arrive when this optprobe is being handled. And you are 
> > totally right -- we would miss kprobe hits during PMI handling with the 
> > current approach. We need a hard_irq_disable() there.
> 
> One note: it depends on the arch implementation of kprobes, since this
> is only for "emulating" the int3 behavior on x86 for compatibility.
> On x86, int3 is disabling interrupt automatically, so all the kprobes
> user handlers will be run under irq-disabled. This means that user may
> write their code to run as such condition. They even can not know
> that is optimized or not at programming timing, because the kprobe
> will be optimized after a while from enabled it.
> 
> So the important point is that you have to keep it compatible of
> unoptimized kprobes.

Thanks for the pointers, Masami.
Yes, with unoptimized kprobes on powerpc, we run with interrupts hard 
disabled as well. So, we need to hard disable for optprobes too.

Regards,
Naveen

Re: [PATCH V3 3/4] arch/powerpc: Implement Optprobes

[Naveen N. Rao]

On 2017/02/07 10:05AM, Masami Hiramatsu wrote:
> On Sat, 4 Feb 2017 01:09:49 +0530
> "Naveen N. Rao"  wrote:
> 
> > Hi Michael,
> > Thanks for the review! I'll defer to Anju on most of the aspects, but...
> > 
> > On 2017/02/01 09:53PM, Michael Ellerman wrote:
> > > Anju T Sudhakar  writes:
> > > 
> > > > +static void optimized_callback(struct optimized_kprobe *op,
> > > > +  struct pt_regs *regs)
> > > > +{
> > > > +   struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> > > > +   unsigned long flags;
> > > > +
> > > > +   /* This is possible if op is under delayed unoptimizing */
> > > > +   if (kprobe_disabled(>kp))
> > > > +   return;
> > > > +
> > > > +   local_irq_save(flags);
> > > 
> > > What is that protecting against? Because on powerpc it doesn't actually
> > > disable interrupts, it just masks some of them, the perf interrupt for
> > > example can still run.
> > 
> > That's an excellent catch, as always! :)
> > 
> > This is meant to prevent us from missing kprobe hits while processing 
> > interrupts that arrive when this optprobe is being handled. And you are 
> > totally right -- we would miss kprobe hits during PMI handling with the 
> > current approach. We need a hard_irq_disable() there.
> 
> One note: it depends on the arch implementation of kprobes, since this
> is only for "emulating" the int3 behavior on x86 for compatibility.
> On x86, int3 is disabling interrupt automatically, so all the kprobes
> user handlers will be run under irq-disabled. This means that user may
> write their code to run as such condition. They even can not know
> that is optimized or not at programming timing, because the kprobe
> will be optimized after a while from enabled it.
> 
> So the important point is that you have to keep it compatible of
> unoptimized kprobes.

Thanks for the pointers, Masami.
Yes, with unoptimized kprobes on powerpc, we run with interrupts hard 
disabled as well. So, we need to hard disable for optprobes too.

Regards,
Naveen

[PATCH] vhost: try avoiding avail index access when getting descriptor

[Jason Wang]

If last avail idx is not equal to cached avail idx, we're sure there's
still available buffers in the virtqueue so there's no need to re-read
avail idx. So let's skip this to avoid unnecessary userspace memory
access and memory barrier. Pktgen test show about 3% improvement on rx
pps.

Signed-off-by: Jason Wang 
---
 drivers/vhost/vhost.c | 39 +++
 1 file changed, 23 insertions(+), 16 deletions(-)

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 9f11838..bffbeeb 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1932,25 +1932,32 @@ int vhost_get_vq_desc(struct vhost_virtqueue *vq,
 
/* Check it isn't doing very strange things with descriptor numbers. */
last_avail_idx = vq->last_avail_idx;
-   if (unlikely(vhost_get_user(vq, avail_idx, >avail->idx))) {
-   vq_err(vq, "Failed to access avail idx at %p\n",
-  >avail->idx);
-   return -EFAULT;
-   }
-   vq->avail_idx = vhost16_to_cpu(vq, avail_idx);
 
-   if (unlikely((u16)(vq->avail_idx - last_avail_idx) > vq->num)) {
-   vq_err(vq, "Guest moved used index from %u to %u",
-  last_avail_idx, vq->avail_idx);
-   return -EFAULT;
-   }
+   if (vq->avail_idx == vq->last_avail_idx) {
+   if (unlikely(vhost_get_user(vq, avail_idx, >avail->idx))) {
+   vq_err(vq, "Failed to access avail idx at %p\n",
+   >avail->idx);
+   return -EFAULT;
+   }
+   vq->avail_idx = vhost16_to_cpu(vq, avail_idx);
 
-   /* If there's nothing new since last we looked, return invalid. */
-   if (vq->avail_idx == last_avail_idx)
-   return vq->num;
+   if (unlikely((u16)(vq->avail_idx - last_avail_idx) > vq->num)) {
+   vq_err(vq, "Guest moved used index from %u to %u",
+   last_avail_idx, vq->avail_idx);
+   return -EFAULT;
+   }
+
+   /* If there's nothing new since last we looked, return
+* invalid.
+*/
+   if (vq->avail_idx == last_avail_idx)
+   return vq->num;
 
-   /* Only get avail ring entries after they have been exposed by guest. */
-   smp_rmb();
+   /* Only get avail ring entries after they have been
+* exposed by guest.
+*/
+   smp_rmb();
+   }
 
/* Grab the next descriptor number they're advertising, and increment
 * the index we've seen. */
-- 
2.7.4

[PATCH] vhost: try avoiding avail index access when getting descriptor

[Jason Wang]

If last avail idx is not equal to cached avail idx, we're sure there's
still available buffers in the virtqueue so there's no need to re-read
avail idx. So let's skip this to avoid unnecessary userspace memory
access and memory barrier. Pktgen test show about 3% improvement on rx
pps.

Signed-off-by: Jason Wang 
---
 drivers/vhost/vhost.c | 39 +++
 1 file changed, 23 insertions(+), 16 deletions(-)

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 9f11838..bffbeeb 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1932,25 +1932,32 @@ int vhost_get_vq_desc(struct vhost_virtqueue *vq,
 
/* Check it isn't doing very strange things with descriptor numbers. */
last_avail_idx = vq->last_avail_idx;
-   if (unlikely(vhost_get_user(vq, avail_idx, >avail->idx))) {
-   vq_err(vq, "Failed to access avail idx at %p\n",
-  >avail->idx);
-   return -EFAULT;
-   }
-   vq->avail_idx = vhost16_to_cpu(vq, avail_idx);
 
-   if (unlikely((u16)(vq->avail_idx - last_avail_idx) > vq->num)) {
-   vq_err(vq, "Guest moved used index from %u to %u",
-  last_avail_idx, vq->avail_idx);
-   return -EFAULT;
-   }
+   if (vq->avail_idx == vq->last_avail_idx) {
+   if (unlikely(vhost_get_user(vq, avail_idx, >avail->idx))) {
+   vq_err(vq, "Failed to access avail idx at %p\n",
+   >avail->idx);
+   return -EFAULT;
+   }
+   vq->avail_idx = vhost16_to_cpu(vq, avail_idx);
 
-   /* If there's nothing new since last we looked, return invalid. */
-   if (vq->avail_idx == last_avail_idx)
-   return vq->num;
+   if (unlikely((u16)(vq->avail_idx - last_avail_idx) > vq->num)) {
+   vq_err(vq, "Guest moved used index from %u to %u",
+   last_avail_idx, vq->avail_idx);
+   return -EFAULT;
+   }
+
+   /* If there's nothing new since last we looked, return
+* invalid.
+*/
+   if (vq->avail_idx == last_avail_idx)
+   return vq->num;
 
-   /* Only get avail ring entries after they have been exposed by guest. */
-   smp_rmb();
+   /* Only get avail ring entries after they have been
+* exposed by guest.
+*/
+   smp_rmb();
+   }
 
/* Grab the next descriptor number they're advertising, and increment
 * the index we've seen. */
-- 
2.7.4

Re: [PATCH tip/master] tracing/probes: Fix a warning message to show correct maximum length

[Ingo Molnar]

* Masami Hiramatsu  wrote:

> Since tracing/*probe_events will accept a probe definition
> up to 4096 - 2 ('\n' and '\0') bytes, it must show 4094 instead
> of 4096 in warning message.
> 
> Signed-off-by: Masami Hiramatsu 
> ---
>  kernel/trace/trace_probe.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
> index 8c0553d..7138fea 100644
> --- a/kernel/trace/trace_probe.c
> +++ b/kernel/trace/trace_probe.c
> @@ -673,8 +673,9 @@ ssize_t traceprobe_probes_write(struct file *file, const 
> char __user *buffer,
>   *tmp = '\0';
>   size = tmp - kbuf + 1;
>   } else if (done + size < count) {
> + /* This can accept WRITE_BUFSIZE - 2 ('\n' + '\0') */
>   pr_warn("Line length is too long: Should be less than 
> %d\n",
> - WRITE_BUFSIZE);
> + WRITE_BUFSIZE - 2);

The message should also indicate which kernel subsystem generated it - which is 
useful if the message is not immediately noticed in the kernel log.

You can do this by having something like this at the top of the trace_probe 
file:

  #define pr_fmt(fmt) "trace_probe: " fmt

Thanks,

Ingo

Re: [PATCH tip/master] tracing/probes: Fix a warning message to show correct maximum length

[Ingo Molnar]

* Masami Hiramatsu  wrote:

> Since tracing/*probe_events will accept a probe definition
> up to 4096 - 2 ('\n' and '\0') bytes, it must show 4094 instead
> of 4096 in warning message.
> 
> Signed-off-by: Masami Hiramatsu 
> ---
>  kernel/trace/trace_probe.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
> index 8c0553d..7138fea 100644
> --- a/kernel/trace/trace_probe.c
> +++ b/kernel/trace/trace_probe.c
> @@ -673,8 +673,9 @@ ssize_t traceprobe_probes_write(struct file *file, const 
> char __user *buffer,
>   *tmp = '\0';
>   size = tmp - kbuf + 1;
>   } else if (done + size < count) {
> + /* This can accept WRITE_BUFSIZE - 2 ('\n' + '\0') */
>   pr_warn("Line length is too long: Should be less than 
> %d\n",
> - WRITE_BUFSIZE);
> + WRITE_BUFSIZE - 2);

The message should also indicate which kernel subsystem generated it - which is 
useful if the message is not immediately noticed in the kernel log.

You can do this by having something like this at the top of the trace_probe 
file:

  #define pr_fmt(fmt) "trace_probe: " fmt

Thanks,

Ingo

[PATCH] [media] mtk-vcodec: fix build errors without DEBUG

[Minghsiu Tsai]

Fix build errors after removing DEBUG definition.

Signed-off-by: Minghsiu Tsai 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 9 -
 drivers/media/platform/mtk-vcodec/vdec_vpu_if.c| 5 ++---
 drivers/media/platform/mtk-vcodec/venc_vpu_if.c| 4 +---
 3 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 0746592..6219c7d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -1126,15 +1126,14 @@ static void vb2ops_vdec_buf_queue(struct vb2_buffer *vb)
 * if there is no SPS header or picture info
 * in bs
 */
-   int log_level = ret ? 0 : 1;
 
src_buf = v4l2_m2m_src_buf_remove(ctx->m2m_ctx);
v4l2_m2m_buf_done(to_vb2_v4l2_buffer(src_buf),
VB2_BUF_STATE_DONE);
-   mtk_v4l2_debug(log_level,
-   "[%d] vdec_if_decode() src_buf=%d, size=%zu, 
fail=%d, res_chg=%d",
-   ctx->id, src_buf->index,
-   src_mem.size, ret, res_chg);
+   mtk_v4l2_debug(ret ? 0 : 1,
+  "[%d] vdec_if_decode() src_buf=%d, size=%zu, 
fail=%d, res_chg=%d",
+  ctx->id, src_buf->index,
+  src_mem.size, ret, res_chg);
return;
}
 
diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c 
b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
index 5a24c51..1abd14e 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
@@ -70,9 +70,8 @@ void vpu_dec_ipi_handler(void *data, unsigned int len, void 
*priv)
 static int vcodec_vpu_send_msg(struct vdec_vpu_inst *vpu, void *msg, int len)
 {
int err;
-   uint32_t msg_id = *(uint32_t *)msg;
 
-   mtk_vcodec_debug(vpu, "id=%X", msg_id);
+   mtk_vcodec_debug(vpu, "id=%X", *(uint32_t *)msg);
 
vpu->failure = 0;
vpu->signaled = 0;
@@ -80,7 +79,7 @@ static int vcodec_vpu_send_msg(struct vdec_vpu_inst *vpu, 
void *msg, int len)
err = vpu_ipi_send(vpu->dev, vpu->id, msg, len);
if (err) {
mtk_vcodec_err(vpu, "send fail vpu_id=%d msg_id=%X status=%d",
-  vpu->id, msg_id, err);
+  vpu->id, *(uint32_t *)msg, err);
return err;
}
 
diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c 
b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
index a01c759..0d882ac 100644
--- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
@@ -79,10 +79,8 @@ static int vpu_enc_send_msg(struct venc_vpu_inst *vpu, void 
*msg,
 
status = vpu_ipi_send(vpu->dev, vpu->id, msg, len);
if (status) {
-   uint32_t msg_id = *(uint32_t *)msg;
-
mtk_vcodec_err(vpu, "vpu_ipi_send msg_id %x len %d fail %d",
-  msg_id, len, status);
+  *(uint32_t *)msg, len, status);
return -EINVAL;
}
if (vpu->failure)
-- 
1.9.1

[PATCH] [media] mtk-vcodec: fix build errors without DEBUG

[Minghsiu Tsai]

Fix build errors after removing DEBUG definition.

Signed-off-by: Minghsiu Tsai 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 9 -
 drivers/media/platform/mtk-vcodec/vdec_vpu_if.c| 5 ++---
 drivers/media/platform/mtk-vcodec/venc_vpu_if.c| 4 +---
 3 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 0746592..6219c7d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -1126,15 +1126,14 @@ static void vb2ops_vdec_buf_queue(struct vb2_buffer *vb)
 * if there is no SPS header or picture info
 * in bs
 */
-   int log_level = ret ? 0 : 1;
 
src_buf = v4l2_m2m_src_buf_remove(ctx->m2m_ctx);
v4l2_m2m_buf_done(to_vb2_v4l2_buffer(src_buf),
VB2_BUF_STATE_DONE);
-   mtk_v4l2_debug(log_level,
-   "[%d] vdec_if_decode() src_buf=%d, size=%zu, 
fail=%d, res_chg=%d",
-   ctx->id, src_buf->index,
-   src_mem.size, ret, res_chg);
+   mtk_v4l2_debug(ret ? 0 : 1,
+  "[%d] vdec_if_decode() src_buf=%d, size=%zu, 
fail=%d, res_chg=%d",
+  ctx->id, src_buf->index,
+  src_mem.size, ret, res_chg);
return;
}
 
diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c 
b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
index 5a24c51..1abd14e 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
@@ -70,9 +70,8 @@ void vpu_dec_ipi_handler(void *data, unsigned int len, void 
*priv)
 static int vcodec_vpu_send_msg(struct vdec_vpu_inst *vpu, void *msg, int len)
 {
int err;
-   uint32_t msg_id = *(uint32_t *)msg;
 
-   mtk_vcodec_debug(vpu, "id=%X", msg_id);
+   mtk_vcodec_debug(vpu, "id=%X", *(uint32_t *)msg);
 
vpu->failure = 0;
vpu->signaled = 0;
@@ -80,7 +79,7 @@ static int vcodec_vpu_send_msg(struct vdec_vpu_inst *vpu, 
void *msg, int len)
err = vpu_ipi_send(vpu->dev, vpu->id, msg, len);
if (err) {
mtk_vcodec_err(vpu, "send fail vpu_id=%d msg_id=%X status=%d",
-  vpu->id, msg_id, err);
+  vpu->id, *(uint32_t *)msg, err);
return err;
}
 
diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c 
b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
index a01c759..0d882ac 100644
--- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
@@ -79,10 +79,8 @@ static int vpu_enc_send_msg(struct venc_vpu_inst *vpu, void 
*msg,
 
status = vpu_ipi_send(vpu->dev, vpu->id, msg, len);
if (status) {
-   uint32_t msg_id = *(uint32_t *)msg;
-
mtk_vcodec_err(vpu, "vpu_ipi_send msg_id %x len %d fail %d",
-  msg_id, len, status);
+  *(uint32_t *)msg, len, status);
return -EINVAL;
}
if (vpu->failure)
-- 
1.9.1

Re: [PATCHv2 1/2] arch: Move CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX to be common

[Pavel Machek]

On Mon 2017-02-06 10:47:45, Laura Abbott wrote:
> On 02/03/2017 01:08 PM, Kees Cook wrote:
> > On Fri, Feb 3, 2017 at 12:29 PM, Russell King - ARM Linux
> >  wrote:
> >> On Fri, Feb 03, 2017 at 11:45:56AM -0800, Kees Cook wrote:
> >>> On Fri, Feb 3, 2017 at 9:52 AM, Laura Abbott  wrote:
>  diff --git a/arch/Kconfig b/arch/Kconfig
>  index 99839c2..22ee01e 100644
>  --- a/arch/Kconfig
>  +++ b/arch/Kconfig
>  @@ -781,4 +781,32 @@ config VMAP_STACK
>    the stack to map directly to the KASAN shadow map using a 
>  formula
>    that is incorrect if the stack is in vmalloc space.
> 
>  +config ARCH_NO_STRICT_RWX_DEFAULTS
>  +   def_bool n
>  +
>  +config ARCH_HAS_STRICT_KERNEL_RWX
>  +   def_bool n
>  +
>  +config DEBUG_RODATA
>  +   def_bool y if !ARCH_NO_STRICT_RWX_DEFAULTS
>  +   prompt "Make kernel text and rodata read-only" if 
>  ARCH_NO_STRICT_RWX_DEFAULTS
> >>>
> >>> Ah! Yes, perfect. I totally forgot about using conditional "prompt"
> >>> lines. Nice!
> >>
> >> It's no different from the more usual:
> >>
> >> bool "Make kernel text and rodata read-only" if 
> >> ARCH_NO_STRICT_RWX_DEFAULTS
> >> default y if !ARCH_NO_STRICT_RWX_DEFAULTS
> >> depends on ARCH_HAS_STRICT_KERNEL_RWX
> >>
> >> But... I really don't like this - way too many negations and negatives
> >> which make it difficult to figure out what's going on here.
> >>
> >> The situation we have today is:
> >>
> >> -config DEBUG_RODATA
> >> -   bool "Make kernel text and rodata read-only"
> >> -   depends on MMU && !XIP_KERNEL
> >> -   default y if CPU_V7
> >>
> >> which is "allow the user to select DEBUG_RODATA if building a MMU non-XIP
> >> kernel", suggesting that the user turns it on for ARMv7 CPUs.
> >>
> >> That changes with this and the above:
> >>
> >> +   select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
> >> +   select ARCH_HAS_STRICT_MODULE_RWX if MMU
> >> +   select ARCH_NO_STRICT_RWX_DEFAULTS if !CPU_V7
> >>
> >> This means that ARCH_HAS_STRICT_KERNEL_RWX is set for a MMU non-XIP
> >> kernel, which carries the same pre-condition for DEBUG_RODATA - no
> >> problem there.
> >>
> >> However, ARCH_NO_STRICT_RWX_DEFAULTS is set for non-ARMv7 CPUs, which
> >> means the "Make kernel text and rodata read-only" prompt _is_ provided
> >> for those.  However, for all ARMv7 systems, we go from "suggesting that
> >> the user enables the option" to "you don't have a choice, you get this
> >> whether you want it or not."
> >>
> >> I'd prefer to keep it off for my development systems, where I don't
> >> care about kernel security.  If we don't wish to do that as a general
> >> rule, can we make it dependent on EMBEDDED?
> >>
> >> Given that on ARM it can add up to 4MB to the kernel image - there
> >> _will_ be about 1MB before the .text section, the padding on between
> >> __modver and __ex_table which for me is around 626k, the padding
> >> between .notes and the init sections start with .vectors (the space
> >> between __ex_table and end of .notes is only 4124, which gets padded
> >> up to 1MB) and lastly the padding between the .init section and the
> >> data section (for me around 593k).  This all adds up to an increase
> >> in kernel image size of 3.2MB on 14.2MB - an increase of 22%.
> >>
> >> So no, I'm really not happy with that.
> > 
> > Ah yeah, good point. We have three cases: unsupported, mandatory,
> > optional, but we have the case of setting the default for the optional
> > case. Maybe something like this?
> > 
> > config STRICT_KERNEL_RWX
> >   bool "Make kernel text and rodata read-only" if ARCH_OPTIONAL_KERNEL_RWX
> >   depends on ARCH_HAS_STRICT_KERNEL_RWX
> >   default ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
> > 
> > unsupported:
> > !ARCH_HAS_STRICT_KERNEL_RWX
> > 
> > mandatory:
> > ARCH_HAS_STRICT_KERNEL_RWX
> > !ARCH_OPTIONAL_KERNEL_RWX
> > 
> > optional:
> > ARCH_HAS_STRICT_KERNEL_RWX
> > ARCH_OPTIONAL_KERNEL_RWX
> > with default controlled by ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
> > 
> > Then arm is:
> >   select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
> >   select ARCH_HAS_STRICT_MODULE_RWX if MMU
> >   select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
> >   select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT if CPU_V7
> > 
> > x86 and arm64 are:
> >   select ARCH_HAS_STRICT_KERNEL_RWX
> >   select ARCH_HAS_STRICT_MODULE_RWX
> > 
> > ?
> > 
> > -Kees
> > 
> 
> Yes, that looks good. I wanted it to be mandatory to avoid the
> mindset of "optional means we don't need it" but I see there
> are some cases where it's better to turn it off. I'll see if
> I can emphasize this properly in the help text ("Say Y here
> unless you love security exploits running in production")

What about fixing the memory wastage, instead? If you want something
almost-always-on, it should not waste megabytes of memory.

And BTW it is help text, not 

Re: [PATCHv2 1/2] arch: Move CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX to be common

[Pavel Machek]

On Mon 2017-02-06 10:47:45, Laura Abbott wrote:
> On 02/03/2017 01:08 PM, Kees Cook wrote:
> > On Fri, Feb 3, 2017 at 12:29 PM, Russell King - ARM Linux
> >  wrote:
> >> On Fri, Feb 03, 2017 at 11:45:56AM -0800, Kees Cook wrote:
> >>> On Fri, Feb 3, 2017 at 9:52 AM, Laura Abbott  wrote:
>  diff --git a/arch/Kconfig b/arch/Kconfig
>  index 99839c2..22ee01e 100644
>  --- a/arch/Kconfig
>  +++ b/arch/Kconfig
>  @@ -781,4 +781,32 @@ config VMAP_STACK
>    the stack to map directly to the KASAN shadow map using a 
>  formula
>    that is incorrect if the stack is in vmalloc space.
> 
>  +config ARCH_NO_STRICT_RWX_DEFAULTS
>  +   def_bool n
>  +
>  +config ARCH_HAS_STRICT_KERNEL_RWX
>  +   def_bool n
>  +
>  +config DEBUG_RODATA
>  +   def_bool y if !ARCH_NO_STRICT_RWX_DEFAULTS
>  +   prompt "Make kernel text and rodata read-only" if 
>  ARCH_NO_STRICT_RWX_DEFAULTS
> >>>
> >>> Ah! Yes, perfect. I totally forgot about using conditional "prompt"
> >>> lines. Nice!
> >>
> >> It's no different from the more usual:
> >>
> >> bool "Make kernel text and rodata read-only" if 
> >> ARCH_NO_STRICT_RWX_DEFAULTS
> >> default y if !ARCH_NO_STRICT_RWX_DEFAULTS
> >> depends on ARCH_HAS_STRICT_KERNEL_RWX
> >>
> >> But... I really don't like this - way too many negations and negatives
> >> which make it difficult to figure out what's going on here.
> >>
> >> The situation we have today is:
> >>
> >> -config DEBUG_RODATA
> >> -   bool "Make kernel text and rodata read-only"
> >> -   depends on MMU && !XIP_KERNEL
> >> -   default y if CPU_V7
> >>
> >> which is "allow the user to select DEBUG_RODATA if building a MMU non-XIP
> >> kernel", suggesting that the user turns it on for ARMv7 CPUs.
> >>
> >> That changes with this and the above:
> >>
> >> +   select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
> >> +   select ARCH_HAS_STRICT_MODULE_RWX if MMU
> >> +   select ARCH_NO_STRICT_RWX_DEFAULTS if !CPU_V7
> >>
> >> This means that ARCH_HAS_STRICT_KERNEL_RWX is set for a MMU non-XIP
> >> kernel, which carries the same pre-condition for DEBUG_RODATA - no
> >> problem there.
> >>
> >> However, ARCH_NO_STRICT_RWX_DEFAULTS is set for non-ARMv7 CPUs, which
> >> means the "Make kernel text and rodata read-only" prompt _is_ provided
> >> for those.  However, for all ARMv7 systems, we go from "suggesting that
> >> the user enables the option" to "you don't have a choice, you get this
> >> whether you want it or not."
> >>
> >> I'd prefer to keep it off for my development systems, where I don't
> >> care about kernel security.  If we don't wish to do that as a general
> >> rule, can we make it dependent on EMBEDDED?
> >>
> >> Given that on ARM it can add up to 4MB to the kernel image - there
> >> _will_ be about 1MB before the .text section, the padding on between
> >> __modver and __ex_table which for me is around 626k, the padding
> >> between .notes and the init sections start with .vectors (the space
> >> between __ex_table and end of .notes is only 4124, which gets padded
> >> up to 1MB) and lastly the padding between the .init section and the
> >> data section (for me around 593k).  This all adds up to an increase
> >> in kernel image size of 3.2MB on 14.2MB - an increase of 22%.
> >>
> >> So no, I'm really not happy with that.
> > 
> > Ah yeah, good point. We have three cases: unsupported, mandatory,
> > optional, but we have the case of setting the default for the optional
> > case. Maybe something like this?
> > 
> > config STRICT_KERNEL_RWX
> >   bool "Make kernel text and rodata read-only" if ARCH_OPTIONAL_KERNEL_RWX
> >   depends on ARCH_HAS_STRICT_KERNEL_RWX
> >   default ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
> > 
> > unsupported:
> > !ARCH_HAS_STRICT_KERNEL_RWX
> > 
> > mandatory:
> > ARCH_HAS_STRICT_KERNEL_RWX
> > !ARCH_OPTIONAL_KERNEL_RWX
> > 
> > optional:
> > ARCH_HAS_STRICT_KERNEL_RWX
> > ARCH_OPTIONAL_KERNEL_RWX
> > with default controlled by ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
> > 
> > Then arm is:
> >   select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
> >   select ARCH_HAS_STRICT_MODULE_RWX if MMU
> >   select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
> >   select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT if CPU_V7
> > 
> > x86 and arm64 are:
> >   select ARCH_HAS_STRICT_KERNEL_RWX
> >   select ARCH_HAS_STRICT_MODULE_RWX
> > 
> > ?
> > 
> > -Kees
> > 
> 
> Yes, that looks good. I wanted it to be mandatory to avoid the
> mindset of "optional means we don't need it" but I see there
> are some cases where it's better to turn it off. I'll see if
> I can emphasize this properly in the help text ("Say Y here
> unless you love security exploits running in production")

What about fixing the memory wastage, instead? If you want something
almost-always-on, it should not waste megabytes of memory.

And BTW it is help text, not advertising for your favourite feature.
   

[PATCH v4 2/2] perf tools: Add missing newline in debug messages

[He Kuang]

These two debug messages are missing the trailing newline.

Signed-off-by: He Kuang 
---
 tools/perf/util/bpf-loader.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
index 36c8611..bc6bc70 100644
--- a/tools/perf/util/bpf-loader.c
+++ b/tools/perf/util/bpf-loader.c
@@ -670,13 +670,13 @@ int bpf__probe(struct bpf_object *obj)
 
err = convert_perf_probe_events(pev, 1);
if (err < 0) {
-   pr_debug("bpf_probe: failed to convert perf probe 
events");
+   pr_debug("bpf_probe: failed to convert perf probe 
events\n");
goto out;
}
 
err = apply_perf_probe_events(pev, 1);
if (err < 0) {
-   pr_debug("bpf_probe: failed to apply perf probe 
events");
+   pr_debug("bpf_probe: failed to apply perf probe 
events\n");
goto out;
}
 
-- 
1.8.5.2

[PATCH v4 2/2] perf tools: Add missing newline in debug messages

[He Kuang]

These two debug messages are missing the trailing newline.

Signed-off-by: He Kuang 
---
 tools/perf/util/bpf-loader.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
index 36c8611..bc6bc70 100644
--- a/tools/perf/util/bpf-loader.c
+++ b/tools/perf/util/bpf-loader.c
@@ -670,13 +670,13 @@ int bpf__probe(struct bpf_object *obj)
 
err = convert_perf_probe_events(pev, 1);
if (err < 0) {
-   pr_debug("bpf_probe: failed to convert perf probe 
events");
+   pr_debug("bpf_probe: failed to convert perf probe 
events\n");
goto out;
}
 
err = apply_perf_probe_events(pev, 1);
if (err < 0) {
-   pr_debug("bpf_probe: failed to apply perf probe 
events");
+   pr_debug("bpf_probe: failed to apply perf probe 
events\n");
goto out;
}
 
-- 
1.8.5.2

[PATCH v4 1/2] perf tools arm64: Add support for generating bpf prologue

[He Kuang]

Since HAVE_KPROBES can be enabled in arm64, this patch introduces
regs_query_register_offset() to convert register name to offset for
arm64, so the BPF prologue feature is ready to use.

Signed-off-by: He Kuang 
---
 tools/perf/arch/arm64/Makefile  |  1 +
 tools/perf/arch/arm64/util/dwarf-regs.c | 15 ++-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/tools/perf/arch/arm64/Makefile b/tools/perf/arch/arm64/Makefile
index 18b1351..eebe1ec 100644
--- a/tools/perf/arch/arm64/Makefile
+++ b/tools/perf/arch/arm64/Makefile
@@ -2,3 +2,4 @@ ifndef NO_DWARF
 PERF_HAVE_DWARF_REGS := 1
 endif
 PERF_HAVE_JITDUMP := 1
+PERF_HAVE_ARCH_REGS_QUERY_REGISTER_OFFSET := 1
diff --git a/tools/perf/arch/arm64/util/dwarf-regs.c 
b/tools/perf/arch/arm64/util/dwarf-regs.c
index d49efeb..068b618 100644
--- a/tools/perf/arch/arm64/util/dwarf-regs.c
+++ b/tools/perf/arch/arm64/util/dwarf-regs.c
@@ -10,17 +10,20 @@
 
 #include 
 #include 
+#include  /* for struct user_pt_regs */
+#include "util.h"
 
 struct pt_regs_dwarfnum {
const char *name;
unsigned int dwarfnum;
 };
 
-#define STR(s) #s
 #define REG_DWARFNUM_NAME(r, num) {.name = r, .dwarfnum = num}
 #define GPR_DWARFNUM_NAME(num) \
{.name = STR(%x##num), .dwarfnum = num}
 #define REG_DWARFNUM_END {.name = NULL, .dwarfnum = 0}
+#define DWARFNUM2OFFSET(index) \
+   (index * sizeof((struct user_pt_regs *)0)->regs[0])
 
 /*
  * Reference:
@@ -78,3 +81,13 @@ const char *get_arch_regstr(unsigned int n)
return roff->name;
return NULL;
 }
+
+int regs_query_register_offset(const char *name)
+{
+   const struct pt_regs_dwarfnum *roff;
+
+   for (roff = regdwarfnum_table; roff->name != NULL; roff++)
+   if (!strcmp(roff->name, name))
+   return DWARFNUM2OFFSET(roff->dwarfnum);
+   return -EINVAL;
+}
-- 
1.8.5.2

[PATCH v4 1/2] perf tools arm64: Add support for generating bpf prologue

[He Kuang]

Since HAVE_KPROBES can be enabled in arm64, this patch introduces
regs_query_register_offset() to convert register name to offset for
arm64, so the BPF prologue feature is ready to use.

Signed-off-by: He Kuang 
---
 tools/perf/arch/arm64/Makefile  |  1 +
 tools/perf/arch/arm64/util/dwarf-regs.c | 15 ++-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/tools/perf/arch/arm64/Makefile b/tools/perf/arch/arm64/Makefile
index 18b1351..eebe1ec 100644
--- a/tools/perf/arch/arm64/Makefile
+++ b/tools/perf/arch/arm64/Makefile
@@ -2,3 +2,4 @@ ifndef NO_DWARF
 PERF_HAVE_DWARF_REGS := 1
 endif
 PERF_HAVE_JITDUMP := 1
+PERF_HAVE_ARCH_REGS_QUERY_REGISTER_OFFSET := 1
diff --git a/tools/perf/arch/arm64/util/dwarf-regs.c 
b/tools/perf/arch/arm64/util/dwarf-regs.c
index d49efeb..068b618 100644
--- a/tools/perf/arch/arm64/util/dwarf-regs.c
+++ b/tools/perf/arch/arm64/util/dwarf-regs.c
@@ -10,17 +10,20 @@
 
 #include 
 #include 
+#include  /* for struct user_pt_regs */
+#include "util.h"
 
 struct pt_regs_dwarfnum {
const char *name;
unsigned int dwarfnum;
 };
 
-#define STR(s) #s
 #define REG_DWARFNUM_NAME(r, num) {.name = r, .dwarfnum = num}
 #define GPR_DWARFNUM_NAME(num) \
{.name = STR(%x##num), .dwarfnum = num}
 #define REG_DWARFNUM_END {.name = NULL, .dwarfnum = 0}
+#define DWARFNUM2OFFSET(index) \
+   (index * sizeof((struct user_pt_regs *)0)->regs[0])
 
 /*
  * Reference:
@@ -78,3 +81,13 @@ const char *get_arch_regstr(unsigned int n)
return roff->name;
return NULL;
 }
+
+int regs_query_register_offset(const char *name)
+{
+   const struct pt_regs_dwarfnum *roff;
+
+   for (roff = regdwarfnum_table; roff->name != NULL; roff++)
+   if (!strcmp(roff->name, name))
+   return DWARFNUM2OFFSET(roff->dwarfnum);
+   return -EINVAL;
+}
-- 
1.8.5.2

Re: [PATCH 18/89] sched/core: Move task->mm handling methods to

[Ingo Molnar]

* Ingo Molnar  wrote:

> 
> * Christoph Hellwig  wrote:
> 
> > On Mon, Feb 06, 2017 at 02:28:21PM +0100, Ingo Molnar wrote:
> > > Move the following task->mm helper APIs into a new header file,
> > > , to further reduce the size and complexity
> > > of :
> > 
> > Is there any good reason why they can't just go into linux/mm.h?
> 
> So mm.h is pretty large already, and I wanted to preserve the natural API and 
> header separation that was the result of these APIs being in sched.h. Many 
> smaller headers are so much easier to maintain, and they are much more 
> readable 
> as well in my experience.

The other big reason is that putting these APIs (mmget()/mmput()/etc.) into 
mm.h 
would cause mm.h to include sched.h, which would make the whole major kernel 
header coupling situation I'm trying to improve with this series so much worse 
all 
around.

The current stats are:  is included in almost as many files as 
, and about half of them don't include . So 
adding 
these APIs would significantly bloat the kernel in the header build space. So 
we 
really don't want to include sched.h in mm.h.

Thanks,

Ingo

Re: [PATCH 18/89] sched/core: Move task->mm handling methods to

[Ingo Molnar]

* Ingo Molnar  wrote:

> 
> * Christoph Hellwig  wrote:
> 
> > On Mon, Feb 06, 2017 at 02:28:21PM +0100, Ingo Molnar wrote:
> > > Move the following task->mm helper APIs into a new header file,
> > > , to further reduce the size and complexity
> > > of :
> > 
> > Is there any good reason why they can't just go into linux/mm.h?
> 
> So mm.h is pretty large already, and I wanted to preserve the natural API and 
> header separation that was the result of these APIs being in sched.h. Many 
> smaller headers are so much easier to maintain, and they are much more 
> readable 
> as well in my experience.

The other big reason is that putting these APIs (mmget()/mmput()/etc.) into 
mm.h 
would cause mm.h to include sched.h, which would make the whole major kernel 
header coupling situation I'm trying to improve with this series so much worse 
all 
around.

The current stats are:  is included in almost as many files as 
, and about half of them don't include . So 
adding 
these APIs would significantly bloat the kernel in the header build space. So 
we 
really don't want to include sched.h in mm.h.

Thanks,

Ingo

Re: [PATCH] f2fs: enhance lookup xattr

[Chao Yu]

Hi Jaegeuk,

On 2017/1/29 11:58, Jaegeuk Kim wrote:
> Hi Chao,
> 
> On 01/24, Chao Yu wrote:
> 
> ...
> 
>>  
>> -error = read_all_xattrs(inode, ipage, _addr);
>> +error = lookup_all_xattrs(inode, ipage, index, len, name,
>> +, _addr);
>>  if (error)
>>  return error;
>>  
>> -entry = __find_xattr(base_addr, index, len, name);
>> -if (IS_XATTR_LAST_ENTRY(entry)) {
>> -error = -ENODATA;
>> -goto cleanup;
>> -}
>> -
>> -size = le16_to_cpu(entry->e_value_size);
>> +size = __le16_to_cpu(entry->e_value_size);
> 
> Looks good to me, except __le16_to_cpu() here.
> Do we need to use this instead of le16_to_cpu()?

Indeed, no needed. :)

Thanks,

> 
> Thanks,
> 
>>  
>>  if (buffer && size > buffer_size) {
>>  error = -ERANGE;
>> -goto cleanup;
>> +goto out;
>>  }
>>  
>> +pval = entry->e_name + entry->e_name_len;
>> +
>>  if (buffer) {
>>  char *pval = entry->e_name + entry->e_name_len;
>>  memcpy(buffer, pval, size);
>>  }
>>  error = size;
>> -
>> -cleanup:
>> +out:
>>  kzfree(base_addr);
>>  return error;
>>  }
>> diff --git a/fs/f2fs/xattr.h b/fs/f2fs/xattr.h
>> index f990de20cdcd..d5a94928c116 100644
>> --- a/fs/f2fs/xattr.h
>> +++ b/fs/f2fs/xattr.h
>> @@ -72,9 +72,10 @@ struct f2fs_xattr_entry {
>>  for (entry = XATTR_FIRST_ENTRY(addr);\
>>  !IS_XATTR_LAST_ENTRY(entry);\
>>  entry = XATTR_NEXT_ENTRY(entry))
>> -
>> -#define MIN_OFFSET(i)   XATTR_ALIGN(inline_xattr_size(i) + PAGE_SIZE -  
>> \
>> -sizeof(struct node_footer) - sizeof(__u32))
>> +#define MAX_XATTR_BLOCK_SIZE(PAGE_SIZE - sizeof(struct node_footer))
>> +#define VALID_XATTR_BLOCK_SIZE  (MAX_XATTR_BLOCK_SIZE - sizeof(__u32))
>> +#define MIN_OFFSET(i)   XATTR_ALIGN(inline_xattr_size(i) +  
>> \
>> +VALID_XATTR_BLOCK_SIZE)
>>  
>>  #define MAX_VALUE_LEN(i)(MIN_OFFSET(i) -\
>>  sizeof(struct f2fs_xattr_header) -  \
>> -- 
>> 2.8.2.295.g3f1c1d0
> 
> .
> 

Re: [PATCH] f2fs: enhance lookup xattr

[Chao Yu]

Hi Jaegeuk,

On 2017/1/29 11:58, Jaegeuk Kim wrote:
> Hi Chao,
> 
> On 01/24, Chao Yu wrote:
> 
> ...
> 
>>  
>> -error = read_all_xattrs(inode, ipage, _addr);
>> +error = lookup_all_xattrs(inode, ipage, index, len, name,
>> +, _addr);
>>  if (error)
>>  return error;
>>  
>> -entry = __find_xattr(base_addr, index, len, name);
>> -if (IS_XATTR_LAST_ENTRY(entry)) {
>> -error = -ENODATA;
>> -goto cleanup;
>> -}
>> -
>> -size = le16_to_cpu(entry->e_value_size);
>> +size = __le16_to_cpu(entry->e_value_size);
> 
> Looks good to me, except __le16_to_cpu() here.
> Do we need to use this instead of le16_to_cpu()?

Indeed, no needed. :)

Thanks,

> 
> Thanks,
> 
>>  
>>  if (buffer && size > buffer_size) {
>>  error = -ERANGE;
>> -goto cleanup;
>> +goto out;
>>  }
>>  
>> +pval = entry->e_name + entry->e_name_len;
>> +
>>  if (buffer) {
>>  char *pval = entry->e_name + entry->e_name_len;
>>  memcpy(buffer, pval, size);
>>  }
>>  error = size;
>> -
>> -cleanup:
>> +out:
>>  kzfree(base_addr);
>>  return error;
>>  }
>> diff --git a/fs/f2fs/xattr.h b/fs/f2fs/xattr.h
>> index f990de20cdcd..d5a94928c116 100644
>> --- a/fs/f2fs/xattr.h
>> +++ b/fs/f2fs/xattr.h
>> @@ -72,9 +72,10 @@ struct f2fs_xattr_entry {
>>  for (entry = XATTR_FIRST_ENTRY(addr);\
>>  !IS_XATTR_LAST_ENTRY(entry);\
>>  entry = XATTR_NEXT_ENTRY(entry))
>> -
>> -#define MIN_OFFSET(i)   XATTR_ALIGN(inline_xattr_size(i) + PAGE_SIZE -  
>> \
>> -sizeof(struct node_footer) - sizeof(__u32))
>> +#define MAX_XATTR_BLOCK_SIZE(PAGE_SIZE - sizeof(struct node_footer))
>> +#define VALID_XATTR_BLOCK_SIZE  (MAX_XATTR_BLOCK_SIZE - sizeof(__u32))
>> +#define MIN_OFFSET(i)   XATTR_ALIGN(inline_xattr_size(i) +  
>> \
>> +VALID_XATTR_BLOCK_SIZE)
>>  
>>  #define MAX_VALUE_LEN(i)(MIN_OFFSET(i) -\
>>  sizeof(struct f2fs_xattr_header) -  \
>> -- 
>> 2.8.2.295.g3f1c1d0
> 
> .
> 

Re: [RFC PATCH] perf/stat: Add --disable-hwdt

[Ingo Molnar]

* Borislav Petkov  wrote:

> On Mon, Feb 06, 2017 at 02:18:32PM +0100, Robert Richter wrote:
>
> > Isn't there the danger the previous watchdog state is never restored if for 
> > some reason perf got killed? So maybe have some other task running that 
> > restores it once perf is gone.
> 
> Currently, I'm restoring it in the atexit() sighandler. Isn't that always 
> called?

Normally yes, but it's not guaranteed as atexit() is all user-space, SIGKILL 
(or 
OOM) or a straight exit (or a crash in the exit handler itself) will cause it 
to 
not run.

But there's only so much we can do about that, the /proc/sys API is 
fundamentally 
lossy in that regard. We'd have to add much more involved kernel support to 
guarantee that the watchdog state is restored.

A way to do it would be create a new /proc/sys/kernel/watchdog_disable_file 
that 
disables that watchdog while it's _open_. When a task exits and the kernel 
automatically closes the file, the watchdog is re-enabled again. (Or the 
process 
itself can close the file too.)

This method would also nest properly and would handle multi-processes races 
correctly: for example if a script runs perf as root, and root uses 'perf top', 
the two should not race and the hardware watchdog should not end up being 
disabled...

Thanks,

Ingo

Re: [RFC PATCH] perf/stat: Add --disable-hwdt

[Ingo Molnar]

* Borislav Petkov  wrote:

> On Mon, Feb 06, 2017 at 02:18:32PM +0100, Robert Richter wrote:
>
> > Isn't there the danger the previous watchdog state is never restored if for 
> > some reason perf got killed? So maybe have some other task running that 
> > restores it once perf is gone.
> 
> Currently, I'm restoring it in the atexit() sighandler. Isn't that always 
> called?

Normally yes, but it's not guaranteed as atexit() is all user-space, SIGKILL 
(or 
OOM) or a straight exit (or a crash in the exit handler itself) will cause it 
to 
not run.

But there's only so much we can do about that, the /proc/sys API is 
fundamentally 
lossy in that regard. We'd have to add much more involved kernel support to 
guarantee that the watchdog state is restored.

A way to do it would be create a new /proc/sys/kernel/watchdog_disable_file 
that 
disables that watchdog while it's _open_. When a task exits and the kernel 
automatically closes the file, the watchdog is re-enabled again. (Or the 
process 
itself can close the file too.)

This method would also nest properly and would handle multi-processes races 
correctly: for example if a script runs perf as root, and root uses 'perf top', 
the two should not race and the hardware watchdog should not end up being 
disabled...

Thanks,

Ingo

Re: [PATCH] f2fs: introduce nid cache

[Chao Yu]

Hi Jaegeuk,

Happy Chinese New Year! :)

On 2017/1/24 12:35, Jaegeuk Kim wrote:
> Hi Chao,
> 
> On 01/22, Chao Yu wrote:
>> In scenario of intensively node allocation, free nids will be ran out
>> soon, then it needs to stop to load free nids by traversing NAT blocks,
>> in worse case, if NAT blocks does not be cached in memory, it generates
>> IOs which slows down our foreground operations.
>>
>> In order to speed up node allocation, in this patch we introduce a new
>> option named "nid cache", when turns on this option, it will load all
>> nat entries in NAT blocks when doing mount, and organize all free nids
>> in a bitmap, for any operations related to free nid, we will query and
>> set the new prebuilded bitmap instead of reading and lookuping NAT
>> blocks, so performance of node allocation can be improved.
>>
> 
> How does this affect mount time and memory consumption?

Sorry for the delay.

Let me figure out some numbers later.

> IMO, if those do not
> raise huge concerns, we would be able to consider just replacing current free
> nid list with this bitmap.

Yup, I agree with you.

Thanks,

Re: [PATCH] f2fs: introduce nid cache

[Chao Yu]

Hi Jaegeuk,

Happy Chinese New Year! :)

On 2017/1/24 12:35, Jaegeuk Kim wrote:
> Hi Chao,
> 
> On 01/22, Chao Yu wrote:
>> In scenario of intensively node allocation, free nids will be ran out
>> soon, then it needs to stop to load free nids by traversing NAT blocks,
>> in worse case, if NAT blocks does not be cached in memory, it generates
>> IOs which slows down our foreground operations.
>>
>> In order to speed up node allocation, in this patch we introduce a new
>> option named "nid cache", when turns on this option, it will load all
>> nat entries in NAT blocks when doing mount, and organize all free nids
>> in a bitmap, for any operations related to free nid, we will query and
>> set the new prebuilded bitmap instead of reading and lookuping NAT
>> blocks, so performance of node allocation can be improved.
>>
> 
> How does this affect mount time and memory consumption?

Sorry for the delay.

Let me figure out some numbers later.

> IMO, if those do not
> raise huge concerns, we would be able to consider just replacing current free
> nid list with this bitmap.

Yup, I agree with you.

Thanks,

Re: [PATCH 1/9] virtio_pci: remove struct virtio_pci_vq_info

[Jason Wang]

On 2017年02月06日 01:15, Christoph Hellwig wrote:

We don't really need struct virtio_pci_vq_info, as most field in there
are redundant:

  - the vq backpointer is not strictly neede to start with
  - the entry in the vqs list is not needed - the generic virtqueue already
has list, we only need to check if it has a callback to get the same
semantics
  - we can use a simple array to look up the MSI-X vec if needed.
  - That simple array now also duoble serves to replace the per_vq_vectors
flag

Signed-off-by: Christoph Hellwig
---
  drivers/virtio/virtio_pci_common.c | 117 +++--
  drivers/virtio/virtio_pci_common.h |  25 +---
  drivers/virtio/virtio_pci_legacy.c |   6 +-
  drivers/virtio/virtio_pci_modern.c |   6 +-
  4 files changed, 39 insertions(+), 115 deletions(-)

diff --git a/drivers/virtio/virtio_pci_common.c 
b/drivers/virtio/virtio_pci_common.c
index 186cbab327b8..a33767318cbf 100644
--- a/drivers/virtio/virtio_pci_common.c
+++ b/drivers/virtio/virtio_pci_common.c
@@ -62,16 +62,13 @@ static irqreturn_t vp_config_changed(int irq, void *opaque)
  static irqreturn_t vp_vring_interrupt(int irq, void *opaque)
  {
struct virtio_pci_device *vp_dev = opaque;
-   struct virtio_pci_vq_info *info;
irqreturn_t ret = IRQ_NONE;
-   unsigned long flags;
+   struct virtqueue *vq;
  
-	spin_lock_irqsave(_dev->lock, flags);

-   list_for_each_entry(info, _dev->virtqueues, node) {
-   if (vring_interrupt(irq, info->vq) == IRQ_HANDLED)
+   list_for_each_entry(vq, _dev->vdev.vqs, list) {
+   if (vq->callback && vring_interrupt(irq, vq) == IRQ_HANDLED)
ret = IRQ_HANDLED;
}


The check is still there.

Thanks

Re: [PATCH 1/9] virtio_pci: remove struct virtio_pci_vq_info

[Jason Wang]

On 2017年02月06日 01:15, Christoph Hellwig wrote:

We don't really need struct virtio_pci_vq_info, as most field in there
are redundant:

  - the vq backpointer is not strictly neede to start with
  - the entry in the vqs list is not needed - the generic virtqueue already
has list, we only need to check if it has a callback to get the same
semantics
  - we can use a simple array to look up the MSI-X vec if needed.
  - That simple array now also duoble serves to replace the per_vq_vectors
flag

Signed-off-by: Christoph Hellwig
---
  drivers/virtio/virtio_pci_common.c | 117 +++--
  drivers/virtio/virtio_pci_common.h |  25 +---
  drivers/virtio/virtio_pci_legacy.c |   6 +-
  drivers/virtio/virtio_pci_modern.c |   6 +-
  4 files changed, 39 insertions(+), 115 deletions(-)

diff --git a/drivers/virtio/virtio_pci_common.c 
b/drivers/virtio/virtio_pci_common.c
index 186cbab327b8..a33767318cbf 100644
--- a/drivers/virtio/virtio_pci_common.c
+++ b/drivers/virtio/virtio_pci_common.c
@@ -62,16 +62,13 @@ static irqreturn_t vp_config_changed(int irq, void *opaque)
  static irqreturn_t vp_vring_interrupt(int irq, void *opaque)
  {
struct virtio_pci_device *vp_dev = opaque;
-   struct virtio_pci_vq_info *info;
irqreturn_t ret = IRQ_NONE;
-   unsigned long flags;
+   struct virtqueue *vq;
  
-	spin_lock_irqsave(_dev->lock, flags);

-   list_for_each_entry(info, _dev->virtqueues, node) {
-   if (vring_interrupt(irq, info->vq) == IRQ_HANDLED)
+   list_for_each_entry(vq, _dev->vdev.vqs, list) {
+   if (vq->callback && vring_interrupt(irq, vq) == IRQ_HANDLED)
ret = IRQ_HANDLED;
}


The check is still there.

Thanks

Re: [PATCH 4/6] xfs: use memalloc_nofs_{save,restore} instead of memalloc_noio*

[Michal Hocko]

On Tue 07-02-17 09:51:50, Dave Chinner wrote:
> On Mon, Feb 06, 2017 at 07:47:43PM +0100, Michal Hocko wrote:
> > On Mon 06-02-17 10:32:37, Darrick J. Wong wrote:
[...]
> > > I prefer to keep the "...yet we are likely to be under GFP_NOFS..."
> > > wording of the old comment because it captures the uncertainty of
> > > whether or not we actually are already under NOFS.  If someone actually
> > > has audited this code well enough to know for sure then yes let's change
> > > the comment, but I haven't gone that far.
> > 
> > I believe we can drop the memalloc_nofs_save then as well because either
> > we are called from a potentially dangerous context and thus we are in
> > the nofs scope we we do not need the protection at all.
> 
> No, absolutely not. "Belief" is not a sufficient justification for
> removing low level deadlock avoidance infrastructure. This code
> needs to remain in _xfs_buf_map_pages() until a full audit of the
> caller paths is done and we're 100% certain that there are no
> lurking deadlocks.

Exactly. I was actually refering to "If someone actually has audited
this code" above... So I definitely do not want to justify anything
based on the belief

> For example, I'm pretty sure we can call into _xfs_buf_map_pages()
> outside of a transaction context but with an inode ILOCK held
> exclusively. If we then recurse into memory reclaim and try to run a
> transaction during reclaim, we have an inverted ILOCK vs transaction
> locking order. i.e. we are not allowed to call xfs_trans_reserve()
> with an ILOCK held as that can deadlock the log:  log full, locked
> inode pins tail of log, inode cannot be flushed because ILOCK is
> held by caller waiting for log space to become available
> 
> i.e. there are certain situations where holding a ILOCK is a
> deadlock vector. See xfs_lock_inodes() for an example of the lengths
> we go to avoid ILOCK based log deadlocks like this...

Thanks for the reference. This is really helpful!

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 4/6] xfs: use memalloc_nofs_{save,restore} instead of memalloc_noio*

[Michal Hocko]

On Tue 07-02-17 09:51:50, Dave Chinner wrote:
> On Mon, Feb 06, 2017 at 07:47:43PM +0100, Michal Hocko wrote:
> > On Mon 06-02-17 10:32:37, Darrick J. Wong wrote:
[...]
> > > I prefer to keep the "...yet we are likely to be under GFP_NOFS..."
> > > wording of the old comment because it captures the uncertainty of
> > > whether or not we actually are already under NOFS.  If someone actually
> > > has audited this code well enough to know for sure then yes let's change
> > > the comment, but I haven't gone that far.
> > 
> > I believe we can drop the memalloc_nofs_save then as well because either
> > we are called from a potentially dangerous context and thus we are in
> > the nofs scope we we do not need the protection at all.
> 
> No, absolutely not. "Belief" is not a sufficient justification for
> removing low level deadlock avoidance infrastructure. This code
> needs to remain in _xfs_buf_map_pages() until a full audit of the
> caller paths is done and we're 100% certain that there are no
> lurking deadlocks.

Exactly. I was actually refering to "If someone actually has audited
this code" above... So I definitely do not want to justify anything
based on the belief

> For example, I'm pretty sure we can call into _xfs_buf_map_pages()
> outside of a transaction context but with an inode ILOCK held
> exclusively. If we then recurse into memory reclaim and try to run a
> transaction during reclaim, we have an inverted ILOCK vs transaction
> locking order. i.e. we are not allowed to call xfs_trans_reserve()
> with an ILOCK held as that can deadlock the log:  log full, locked
> inode pins tail of log, inode cannot be flushed because ILOCK is
> held by caller waiting for log space to become available
> 
> i.e. there are certain situations where holding a ILOCK is a
> deadlock vector. See xfs_lock_inodes() for an example of the lengths
> we go to avoid ILOCK based log deadlocks like this...

Thanks for the reference. This is really helpful!

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 2/9] virtio_pci: use shared interrupts for virtqueues

[Jason Wang]

On 2017年02月06日 01:15, Christoph Hellwig wrote:

This lets IRQ layer handle dispatching IRQs to separate handlers for the
case where we don't have per-VQ MSI-X vectors, and allows us to greatly
simplify the code based on the assumption that we always have interrupt
vector 0 (legacy INTx or config interrupt for MSI-X) available, and
any other interrupt is request/freed throught the VQ, even if the
actual interrupt line might be shared in some cases.

This allows removing a great deal of variables keeping track of the
interrupt state in struct virtio_pci_device, as we can now simply walk the
list of VQs and deal with per-VQ interrupt handlers there, and only treat
vector 0 special.

Additionally clean up the VQ allocation code to properly unwind on error
instead of having a single global cleanup label, which is error prone,
and in this case also leads to more code.

Signed-off-by: Christoph Hellwig 


Reviewed-by: Jason Wang 


---
  drivers/virtio/virtio_pci_common.c | 235 -
  drivers/virtio/virtio_pci_common.h |  16 +--
  2 files changed, 106 insertions(+), 145 deletions(-)

diff --git a/drivers/virtio/virtio_pci_common.c 
b/drivers/virtio/virtio_pci_common.c
index a33767318cbf..274dc1ff09c0 100644
--- a/drivers/virtio/virtio_pci_common.c
+++ b/drivers/virtio/virtio_pci_common.c
@@ -33,10 +33,8 @@ void vp_synchronize_vectors(struct virtio_device *vdev)
struct virtio_pci_device *vp_dev = to_vp_device(vdev);
int i;
  
-	if (vp_dev->intx_enabled)

-   synchronize_irq(vp_dev->pci_dev->irq);
-
-   for (i = 0; i < vp_dev->msix_vectors; ++i)
+   synchronize_irq(pci_irq_vector(vp_dev->pci_dev, 0));
+   for (i = 1; i < vp_dev->msix_vectors; i++)
synchronize_irq(pci_irq_vector(vp_dev->pci_dev, i));
  }
  
@@ -99,77 +97,10 @@ static irqreturn_t vp_interrupt(int irq, void *opaque)

return vp_vring_interrupt(irq, opaque);
  }
  
-static int vp_request_msix_vectors(struct virtio_device *vdev, int nvectors,

-  bool per_vq_vectors)
-{
-   struct virtio_pci_device *vp_dev = to_vp_device(vdev);
-   const char *name = dev_name(_dev->vdev.dev);
-   unsigned i, v;
-   int err = -ENOMEM;
-
-   vp_dev->msix_vectors = nvectors;
-
-   vp_dev->msix_names = kmalloc(nvectors * sizeof *vp_dev->msix_names,
-GFP_KERNEL);
-   if (!vp_dev->msix_names)
-   goto error;
-   vp_dev->msix_affinity_masks
-   = kzalloc(nvectors * sizeof *vp_dev->msix_affinity_masks,
- GFP_KERNEL);
-   if (!vp_dev->msix_affinity_masks)
-   goto error;
-   for (i = 0; i < nvectors; ++i)
-   if (!alloc_cpumask_var(_dev->msix_affinity_masks[i],
-   GFP_KERNEL))
-   goto error;
-
-   err = pci_alloc_irq_vectors(vp_dev->pci_dev, nvectors, nvectors,
-   PCI_IRQ_MSIX);
-   if (err < 0)
-   goto error;
-   vp_dev->msix_enabled = 1;
-
-   /* Set the vector used for configuration */
-   v = vp_dev->msix_used_vectors;
-   snprintf(vp_dev->msix_names[v], sizeof *vp_dev->msix_names,
-"%s-config", name);
-   err = request_irq(pci_irq_vector(vp_dev->pci_dev, v),
- vp_config_changed, 0, vp_dev->msix_names[v],
- vp_dev);
-   if (err)
-   goto error;
-   ++vp_dev->msix_used_vectors;
-
-   v = vp_dev->config_vector(vp_dev, v);
-   /* Verify we had enough resources to assign the vector */
-   if (v == VIRTIO_MSI_NO_VECTOR) {
-   err = -EBUSY;
-   goto error;
-   }
-
-   if (!per_vq_vectors) {
-   /* Shared vector for all VQs */
-   v = vp_dev->msix_used_vectors;
-   snprintf(vp_dev->msix_names[v], sizeof *vp_dev->msix_names,
-"%s-virtqueues", name);
-   err = request_irq(pci_irq_vector(vp_dev->pci_dev, v),
- vp_vring_interrupt, 0, vp_dev->msix_names[v],
- vp_dev);
-   if (err)
-   goto error;
-   ++vp_dev->msix_used_vectors;
-   }
-   return 0;
-error:
-   return err;
-}
-
-/* the config->del_vqs() implementation */
-void vp_del_vqs(struct virtio_device *vdev)
+static void vp_remove_vqs(struct virtio_device *vdev)
  {
struct virtio_pci_device *vp_dev = to_vp_device(vdev);
struct virtqueue *vq, *n;
-   int i;
  
  	list_for_each_entry_safe(vq, n, >vqs, list) {

if (vp_dev->msix_vector_map) {
@@ -181,35 +112,33 @@ void vp_del_vqs(struct virtio_device *vdev)
}
vp_dev->del_vq(vq);
}
+}
  
-	if (vp_dev->intx_enabled) {

-   free_irq(vp_dev->pci_dev->irq, 

Re: [PATCH 2/9] virtio_pci: use shared interrupts for virtqueues

[Jason Wang]

On 2017年02月06日 01:15, Christoph Hellwig wrote:

This lets IRQ layer handle dispatching IRQs to separate handlers for the
case where we don't have per-VQ MSI-X vectors, and allows us to greatly
simplify the code based on the assumption that we always have interrupt
vector 0 (legacy INTx or config interrupt for MSI-X) available, and
any other interrupt is request/freed throught the VQ, even if the
actual interrupt line might be shared in some cases.

This allows removing a great deal of variables keeping track of the
interrupt state in struct virtio_pci_device, as we can now simply walk the
list of VQs and deal with per-VQ interrupt handlers there, and only treat
vector 0 special.

Additionally clean up the VQ allocation code to properly unwind on error
instead of having a single global cleanup label, which is error prone,
and in this case also leads to more code.

Signed-off-by: Christoph Hellwig 


Reviewed-by: Jason Wang 


---
  drivers/virtio/virtio_pci_common.c | 235 -
  drivers/virtio/virtio_pci_common.h |  16 +--
  2 files changed, 106 insertions(+), 145 deletions(-)

diff --git a/drivers/virtio/virtio_pci_common.c 
b/drivers/virtio/virtio_pci_common.c
index a33767318cbf..274dc1ff09c0 100644
--- a/drivers/virtio/virtio_pci_common.c
+++ b/drivers/virtio/virtio_pci_common.c
@@ -33,10 +33,8 @@ void vp_synchronize_vectors(struct virtio_device *vdev)
struct virtio_pci_device *vp_dev = to_vp_device(vdev);
int i;
  
-	if (vp_dev->intx_enabled)

-   synchronize_irq(vp_dev->pci_dev->irq);
-
-   for (i = 0; i < vp_dev->msix_vectors; ++i)
+   synchronize_irq(pci_irq_vector(vp_dev->pci_dev, 0));
+   for (i = 1; i < vp_dev->msix_vectors; i++)
synchronize_irq(pci_irq_vector(vp_dev->pci_dev, i));
  }
  
@@ -99,77 +97,10 @@ static irqreturn_t vp_interrupt(int irq, void *opaque)

return vp_vring_interrupt(irq, opaque);
  }
  
-static int vp_request_msix_vectors(struct virtio_device *vdev, int nvectors,

-  bool per_vq_vectors)
-{
-   struct virtio_pci_device *vp_dev = to_vp_device(vdev);
-   const char *name = dev_name(_dev->vdev.dev);
-   unsigned i, v;
-   int err = -ENOMEM;
-
-   vp_dev->msix_vectors = nvectors;
-
-   vp_dev->msix_names = kmalloc(nvectors * sizeof *vp_dev->msix_names,
-GFP_KERNEL);
-   if (!vp_dev->msix_names)
-   goto error;
-   vp_dev->msix_affinity_masks
-   = kzalloc(nvectors * sizeof *vp_dev->msix_affinity_masks,
- GFP_KERNEL);
-   if (!vp_dev->msix_affinity_masks)
-   goto error;
-   for (i = 0; i < nvectors; ++i)
-   if (!alloc_cpumask_var(_dev->msix_affinity_masks[i],
-   GFP_KERNEL))
-   goto error;
-
-   err = pci_alloc_irq_vectors(vp_dev->pci_dev, nvectors, nvectors,
-   PCI_IRQ_MSIX);
-   if (err < 0)
-   goto error;
-   vp_dev->msix_enabled = 1;
-
-   /* Set the vector used for configuration */
-   v = vp_dev->msix_used_vectors;
-   snprintf(vp_dev->msix_names[v], sizeof *vp_dev->msix_names,
-"%s-config", name);
-   err = request_irq(pci_irq_vector(vp_dev->pci_dev, v),
- vp_config_changed, 0, vp_dev->msix_names[v],
- vp_dev);
-   if (err)
-   goto error;
-   ++vp_dev->msix_used_vectors;
-
-   v = vp_dev->config_vector(vp_dev, v);
-   /* Verify we had enough resources to assign the vector */
-   if (v == VIRTIO_MSI_NO_VECTOR) {
-   err = -EBUSY;
-   goto error;
-   }
-
-   if (!per_vq_vectors) {
-   /* Shared vector for all VQs */
-   v = vp_dev->msix_used_vectors;
-   snprintf(vp_dev->msix_names[v], sizeof *vp_dev->msix_names,
-"%s-virtqueues", name);
-   err = request_irq(pci_irq_vector(vp_dev->pci_dev, v),
- vp_vring_interrupt, 0, vp_dev->msix_names[v],
- vp_dev);
-   if (err)
-   goto error;
-   ++vp_dev->msix_used_vectors;
-   }
-   return 0;
-error:
-   return err;
-}
-
-/* the config->del_vqs() implementation */
-void vp_del_vqs(struct virtio_device *vdev)
+static void vp_remove_vqs(struct virtio_device *vdev)
  {
struct virtio_pci_device *vp_dev = to_vp_device(vdev);
struct virtqueue *vq, *n;
-   int i;
  
  	list_for_each_entry_safe(vq, n, >vqs, list) {

if (vp_dev->msix_vector_map) {
@@ -181,35 +112,33 @@ void vp_del_vqs(struct virtio_device *vdev)
}
vp_dev->del_vq(vq);
}
+}
  
-	if (vp_dev->intx_enabled) {

-   free_irq(vp_dev->pci_dev->irq, vp_dev);
-   

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

[Al Viro]

On Mon, Feb 06, 2017 at 03:18:42PM +0100, Miklos Szeredi wrote:

> But I think it's breakable in the same way: if the deadlocked request
> is aborted, the fault will release the page lock as well as mmap_sem,
> and from there things will resolve themselves.

Right you are - original holder of ->mmap_sem is waiting for request and
abort will wake it up...

> But you are definitely right about needing to clean up that mess in
> fuse/dev.c and doing so by fixing up the arg refcounting for just the
> read and write requests is going to be a lot simpler than having to do
> that for all of them (which was my original plan).

Speaking of refcounting - what's going on with fuse_file one?  My reading
of that code is that you have 4 states of that thing:
* new (just created, fallback request allocated, use fuse_file_free()
to kill).  Refcount is 0.
* intermediate - in fact it's already opened, but still not
put into ->private_data.  Refcount is still 0.  Use fuse_sync_release() to kill.
* live - normal refcounting (fuse_file_get()/fuse_file_put()).
* shutdown - refcount has reached 0.  Can't happen until ->release()
(obviously - ->private_data holds a counting reference), some pieces of
fuse_sync_release() correspond to some stuff in fuse_release_common(), some -
to final fuse_file_put().

To make it even more convoluted, cuse is using fuse_sync_release() and
apparently relies upon no references being grabbed after fuse_do_open(),
so that thing can be called with refcount 0 *or* refcount 1.

Another thing: what guarantees that places in writepages-related paths
where we store a reference into req->ff won't hit a request with already
non-NULL ->ff?

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

[Al Viro]

On Mon, Feb 06, 2017 at 03:18:42PM +0100, Miklos Szeredi wrote:

> But I think it's breakable in the same way: if the deadlocked request
> is aborted, the fault will release the page lock as well as mmap_sem,
> and from there things will resolve themselves.

Right you are - original holder of ->mmap_sem is waiting for request and
abort will wake it up...

> But you are definitely right about needing to clean up that mess in
> fuse/dev.c and doing so by fixing up the arg refcounting for just the
> read and write requests is going to be a lot simpler than having to do
> that for all of them (which was my original plan).

Speaking of refcounting - what's going on with fuse_file one?  My reading
of that code is that you have 4 states of that thing:
* new (just created, fallback request allocated, use fuse_file_free()
to kill).  Refcount is 0.
* intermediate - in fact it's already opened, but still not
put into ->private_data.  Refcount is still 0.  Use fuse_sync_release() to kill.
* live - normal refcounting (fuse_file_get()/fuse_file_put()).
* shutdown - refcount has reached 0.  Can't happen until ->release()
(obviously - ->private_data holds a counting reference), some pieces of
fuse_sync_release() correspond to some stuff in fuse_release_common(), some -
to final fuse_file_put().

To make it even more convoluted, cuse is using fuse_sync_release() and
apparently relies upon no references being grabbed after fuse_do_open(),
so that thing can be called with refcount 0 *or* refcount 1.

Another thing: what guarantees that places in writepages-related paths
where we store a reference into req->ff won't hit a request with already
non-NULL ->ff?

Re: [PATCHv3 1/2] arch: Move CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX to be common

[Ingo Molnar]

* Laura Abbott  wrote:

> 
> There are multiple architectures that support CONFIG_DEBUG_RODATA and
> CONFIG_SET_MODULE_RONX. These options also now have the ability to be
> turned off at runtime. Move these to an architecture independent
> location and make these options def_bool y for almost all of those
> arches.
> 
> Signed-off-by: Laura Abbott 
> ---
> v3: Make these configs selectable for arm. Include some documentation about
> how the setup of the optional Kconfigs work as well. Stop spelling 'kenrel'
> in prompt text.
> ---
>  Documentation/security/self-protection.txt |  6 ++
>  arch/Kconfig   | 34 
> ++
>  arch/arm/Kconfig   |  4 
>  arch/arm/Kconfig.debug | 11 --
>  arch/arm/mm/Kconfig| 12 ---
>  arch/arm64/Kconfig |  5 ++---
>  arch/arm64/Kconfig.debug   | 11 --
>  arch/parisc/Kconfig|  1 +
>  arch/parisc/Kconfig.debug  | 11 --
>  arch/s390/Kconfig  |  5 ++---
>  arch/s390/Kconfig.debug|  3 ---
>  arch/x86/Kconfig   |  5 ++---
>  arch/x86/Kconfig.debug | 11 --
>  13 files changed, 51 insertions(+), 68 deletions(-)

Acked-by: Ingo Molnar 

Thanks,

Ingo

Re: [PATCHv3 1/2] arch: Move CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX to be common

[Ingo Molnar]

* Laura Abbott  wrote:

> 
> There are multiple architectures that support CONFIG_DEBUG_RODATA and
> CONFIG_SET_MODULE_RONX. These options also now have the ability to be
> turned off at runtime. Move these to an architecture independent
> location and make these options def_bool y for almost all of those
> arches.
> 
> Signed-off-by: Laura Abbott 
> ---
> v3: Make these configs selectable for arm. Include some documentation about
> how the setup of the optional Kconfigs work as well. Stop spelling 'kenrel'
> in prompt text.
> ---
>  Documentation/security/self-protection.txt |  6 ++
>  arch/Kconfig   | 34 
> ++
>  arch/arm/Kconfig   |  4 
>  arch/arm/Kconfig.debug | 11 --
>  arch/arm/mm/Kconfig| 12 ---
>  arch/arm64/Kconfig |  5 ++---
>  arch/arm64/Kconfig.debug   | 11 --
>  arch/parisc/Kconfig|  1 +
>  arch/parisc/Kconfig.debug  | 11 --
>  arch/s390/Kconfig  |  5 ++---
>  arch/s390/Kconfig.debug|  3 ---
>  arch/x86/Kconfig   |  5 ++---
>  arch/x86/Kconfig.debug | 11 --
>  13 files changed, 51 insertions(+), 68 deletions(-)

Acked-by: Ingo Molnar 

Thanks,

Ingo

Re: [PATCH v4 3/3] i2c: zx2967: add i2c controller driver for ZTE's zx2967 family

[Shawn Guo]

On Mon, Feb 06, 2017 at 11:28:20AM +0800, Baoyou Xie wrote:
> + Shawn
> 
> On 6 February 2017 at 11:26, Baoyou Xie  wrote:
> 
> > This patch adds i2c controller driver for ZTE's zx2967 family.
> >
> > Signed-off-by: Baoyou Xie 

Reviewed-by: Shawn Guo 

Re: [PATCH v4 3/3] i2c: zx2967: add i2c controller driver for ZTE's zx2967 family

[Shawn Guo]

On Mon, Feb 06, 2017 at 11:28:20AM +0800, Baoyou Xie wrote:
> + Shawn
> 
> On 6 February 2017 at 11:26, Baoyou Xie  wrote:
> 
> > This patch adds i2c controller driver for ZTE's zx2967 family.
> >
> > Signed-off-by: Baoyou Xie 

Reviewed-by: Shawn Guo 

Re: [PATCH v3 2/7] drm/tinydrm: Add helper functions

[Daniel Vetter]

On Mon, Feb 06, 2017 at 04:55:55PM -0600, Rob Herring wrote:
> On Mon, Feb 6, 2017 at 5:08 AM, Thierry Reding  
> wrote:
> > On Mon, Feb 06, 2017 at 11:07:42AM +0100, Daniel Vetter wrote:
> >> On Mon, Feb 6, 2017 at 10:35 AM, Thierry Reding 
> >> wrote:
> >>
> >> > > > > +EXPORT_SYMBOL(tinydrm_disable_backlight);
> >> > > > > +#endif
> >> > > >
> >> > > > These look like they really should be part of the backlight 
> >> > > > subsystem.
> >> > I
> >> > > > don't see anything DRM specific about them. Well, except for the 
> >> > > > error
> >> > > > messages.
> >> > >
> >> > > So this is a bit an unpopular opinion with some folks, but I don't
> >> > require
> >> > > anyone to submit new code to subsystems outside of drm for new drivers.
> >> > > Simply because it takes months to get stuff landed, and in general it's
> >> > > not worth the trouble.
> >> >
> >> > "Not worth the trouble" is very subjective. If you look at the Linux
> >> > kernel in general, one of the reasons why it works so well is because
> >> > the changes we make apply to the kernel as a whole. Yes, sometimes that
> >> > makes things more difficult and time-consuming, but it also means that
> >> > the end result will be much more widely usable and therefore benefits
> >> > everyone else in return. In my opinion that's a large part of why the
> >> > kernel is so successful.
> >> >
> >> > > We have piles of stuff in drm and drm drivers that should be in core 
> >> > > but
> >> > > isn't.
> >> > >
> >> > > Imo the only reasonable way is to merge as-is, then follow-up with a
> >> > patch
> >> > > series to move the helper into the right subsystem. Most often
> >> > > unfortunately that follow-up patch series will just die.
> >> >
> >> > Of course follow-up series die. That's because nobody cares to follow-up
> >> > once their code has been merged.
> >> >
> >> > Collecting our own helpers or variants of subsystems is a great way of
> >> > isolating ourselves from the rest of the community. I don't think that's
> >> > a good solution in the long run at all.
> >> >
> >>
> >> We have a bunch of patch series that we resubmit for months and they go
> >> exactly nowhere. They don't die because we stop caring, they die because
> >> they die. Some of them we even need to constantly rebase and carry around
> >> in drm-tip since our CI would Oops or spew WARNIGs all over the place.
> >> There's simply some areas of the kernel which seem overloaded under patches
> >> and no one is willing or able to fix things, and I can't fix the entire
> >> kernel. Nor expect contributors (who have much less political weight to
> >> throw around than me) to do that and succeed. And we don't end up with
> >> worse code in the drm subsystem, since we can still do the refactoring
> >> within drm helpers and end up with clean drivers.
> >>
> >> I fully agree that it's not great for the kernel's future, but when I'm
> >> stuck with the option to get shit done or burning out playing the
> >> upstreaming game, the choice is easy. And in the end I care about open
> >> source gfx much more than the kernel, and I think for open source gfx's
> >> success it's crucial that we're welcoming to new contributors and don't
> >> throw up massive roadblocks. Open source gfx is tiny and still far away
> >> from world domination, we need _lots_ more people. If that means routing
> >> around other subsystems for them, I'm all for it.
> >
> > I can't say I fully agree with that sentiment. I do see how routing
> > around subsystems can be useful occasionally. If nobody will merge the
> > code, or if nobody cares, then by all means, let's make them DRM-
> > specific helpers.
> 
> In this case, these backlight helpers aren't even common across DRM.
> They are tinydrm specific, but only in name and location. They look
> like they'd be helpful to panel-simple.c and other panel drivers, too.
> :)
> 
> Who's to blame for duplication within DRM then? If only I had 1
> location of OF graph code to clean-up... I get new DT functions all
> the time that other subsystems want, so I don't think the problem lies
> there.
> 
> > But I think we need to at least try to do the right thing. If only to
> > teach people what the right way is. If we start accepting such things
> > by default, how can we expect contributors to even try?
> >
> > I also think that contributors will often end up contributing not only
> > to DRM but to the kernel as a whole. As such it should be part of our
> > mentoring to teach them about how the process works as a rule, even if
> > the occasional exception is necessary to get things done.
> 
> Yes, it's important for contributors to learn to avoid "the platform
> problem"[1].

Stuff Noralf has done over the past few months to get tinydrm merged:
- proper deferred io support in fbdev helpers
- refactoring all drivers to use the same that rolled their own
- bunch of refactoring all around in drm core
- remove the debugfs cleanup 

Re: [PATCH v3 2/7] drm/tinydrm: Add helper functions

[Daniel Vetter]

On Mon, Feb 06, 2017 at 04:55:55PM -0600, Rob Herring wrote:
> On Mon, Feb 6, 2017 at 5:08 AM, Thierry Reding  
> wrote:
> > On Mon, Feb 06, 2017 at 11:07:42AM +0100, Daniel Vetter wrote:
> >> On Mon, Feb 6, 2017 at 10:35 AM, Thierry Reding 
> >> wrote:
> >>
> >> > > > > +EXPORT_SYMBOL(tinydrm_disable_backlight);
> >> > > > > +#endif
> >> > > >
> >> > > > These look like they really should be part of the backlight 
> >> > > > subsystem.
> >> > I
> >> > > > don't see anything DRM specific about them. Well, except for the 
> >> > > > error
> >> > > > messages.
> >> > >
> >> > > So this is a bit an unpopular opinion with some folks, but I don't
> >> > require
> >> > > anyone to submit new code to subsystems outside of drm for new drivers.
> >> > > Simply because it takes months to get stuff landed, and in general it's
> >> > > not worth the trouble.
> >> >
> >> > "Not worth the trouble" is very subjective. If you look at the Linux
> >> > kernel in general, one of the reasons why it works so well is because
> >> > the changes we make apply to the kernel as a whole. Yes, sometimes that
> >> > makes things more difficult and time-consuming, but it also means that
> >> > the end result will be much more widely usable and therefore benefits
> >> > everyone else in return. In my opinion that's a large part of why the
> >> > kernel is so successful.
> >> >
> >> > > We have piles of stuff in drm and drm drivers that should be in core 
> >> > > but
> >> > > isn't.
> >> > >
> >> > > Imo the only reasonable way is to merge as-is, then follow-up with a
> >> > patch
> >> > > series to move the helper into the right subsystem. Most often
> >> > > unfortunately that follow-up patch series will just die.
> >> >
> >> > Of course follow-up series die. That's because nobody cares to follow-up
> >> > once their code has been merged.
> >> >
> >> > Collecting our own helpers or variants of subsystems is a great way of
> >> > isolating ourselves from the rest of the community. I don't think that's
> >> > a good solution in the long run at all.
> >> >
> >>
> >> We have a bunch of patch series that we resubmit for months and they go
> >> exactly nowhere. They don't die because we stop caring, they die because
> >> they die. Some of them we even need to constantly rebase and carry around
> >> in drm-tip since our CI would Oops or spew WARNIGs all over the place.
> >> There's simply some areas of the kernel which seem overloaded under patches
> >> and no one is willing or able to fix things, and I can't fix the entire
> >> kernel. Nor expect contributors (who have much less political weight to
> >> throw around than me) to do that and succeed. And we don't end up with
> >> worse code in the drm subsystem, since we can still do the refactoring
> >> within drm helpers and end up with clean drivers.
> >>
> >> I fully agree that it's not great for the kernel's future, but when I'm
> >> stuck with the option to get shit done or burning out playing the
> >> upstreaming game, the choice is easy. And in the end I care about open
> >> source gfx much more than the kernel, and I think for open source gfx's
> >> success it's crucial that we're welcoming to new contributors and don't
> >> throw up massive roadblocks. Open source gfx is tiny and still far away
> >> from world domination, we need _lots_ more people. If that means routing
> >> around other subsystems for them, I'm all for it.
> >
> > I can't say I fully agree with that sentiment. I do see how routing
> > around subsystems can be useful occasionally. If nobody will merge the
> > code, or if nobody cares, then by all means, let's make them DRM-
> > specific helpers.
> 
> In this case, these backlight helpers aren't even common across DRM.
> They are tinydrm specific, but only in name and location. They look
> like they'd be helpful to panel-simple.c and other panel drivers, too.
> :)
> 
> Who's to blame for duplication within DRM then? If only I had 1
> location of OF graph code to clean-up... I get new DT functions all
> the time that other subsystems want, so I don't think the problem lies
> there.
> 
> > But I think we need to at least try to do the right thing. If only to
> > teach people what the right way is. If we start accepting such things
> > by default, how can we expect contributors to even try?
> >
> > I also think that contributors will often end up contributing not only
> > to DRM but to the kernel as a whole. As such it should be part of our
> > mentoring to teach them about how the process works as a rule, even if
> > the occasional exception is necessary to get things done.
> 
> Yes, it's important for contributors to learn to avoid "the platform
> problem"[1].

Stuff Noralf has done over the past few months to get tinydrm merged:
- proper deferred io support in fbdev helpers
- refactoring all drivers to use the same that rolled their own
- bunch of refactoring all around in drm core
- remove the debugfs cleanup code from drivers and move into core

I don't think you 

Re: [PATCH v3 2/7] drm/tinydrm: Add helper functions

[Daniel Vetter]

On Tue, Feb 07, 2017 at 08:28:16AM +1000, Dave Airlie wrote:
> >
> > I definitely don't want that we don't attempt this. But brought from years
> > of experience, I recommend to merge first (with pre-refactoring already
> > applied, but helpers only extracted, not yet at the right spot), and then
> > follow up with. Because on average, there's way too many trees with
> > overloaded maintainers who maybe look at your patch once per kernel
> > release cycle.
> >
> > If you know that backlight and spi isn't one of these areas (anything that
> > goes through takashi/sound is a similar good experience for us on the i915
> > side), then I guess we can try. But then Noralf has already written a few
> > months worth of really great refactoring, and I'm seriously starting to
> > feel guilty for volunteering him for all of this. Even though he seems to
> > be really good at it, and seems to not mind, it's getting a bit silly.
> > Given that I'd say up to Noralf.
> >
> > In short, there's always a balance.
> 
> I don't think we can make a rule for this, it will always depend on the
> code. There is always going to be stuff we put in drm that should go
> elsewhere, and stuff that is elsewhere that drm should use.
> 
> I think however if we do add stuff like this, someone should keep track
> of them and try to make them get further into the kernel. In this case
> I don't think the patches are too insane to keep in drm and refactor up
> later, in other cases I'm sure it'll be lot more obvious (i.e. we could
> make the same argument for chunks of DAL :-)

DAL's not under this exception, since DAL is all about using drm stuff
more (and maybe fixing a few things in drm helpers). My concern here is
only about going outside of drm, where at least sometimes it's just utter
pain to get even the most trivial bits merged. And holding up an entire
driver for that seems silly, hence merge first, try to further refactor
later.

For DAL amd has started to work on things properly, and since Alex is now
drm-misc committer that should all progress reasonably quickly.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v3 2/7] drm/tinydrm: Add helper functions

[Daniel Vetter]

On Tue, Feb 07, 2017 at 08:28:16AM +1000, Dave Airlie wrote:
> >
> > I definitely don't want that we don't attempt this. But brought from years
> > of experience, I recommend to merge first (with pre-refactoring already
> > applied, but helpers only extracted, not yet at the right spot), and then
> > follow up with. Because on average, there's way too many trees with
> > overloaded maintainers who maybe look at your patch once per kernel
> > release cycle.
> >
> > If you know that backlight and spi isn't one of these areas (anything that
> > goes through takashi/sound is a similar good experience for us on the i915
> > side), then I guess we can try. But then Noralf has already written a few
> > months worth of really great refactoring, and I'm seriously starting to
> > feel guilty for volunteering him for all of this. Even though he seems to
> > be really good at it, and seems to not mind, it's getting a bit silly.
> > Given that I'd say up to Noralf.
> >
> > In short, there's always a balance.
> 
> I don't think we can make a rule for this, it will always depend on the
> code. There is always going to be stuff we put in drm that should go
> elsewhere, and stuff that is elsewhere that drm should use.
> 
> I think however if we do add stuff like this, someone should keep track
> of them and try to make them get further into the kernel. In this case
> I don't think the patches are too insane to keep in drm and refactor up
> later, in other cases I'm sure it'll be lot more obvious (i.e. we could
> make the same argument for chunks of DAL :-)

DAL's not under this exception, since DAL is all about using drm stuff
more (and maybe fixing a few things in drm helpers). My concern here is
only about going outside of drm, where at least sometimes it's just utter
pain to get even the most trivial bits merged. And holding up an entire
driver for that seems silly, hence merge first, try to further refactor
later.

For DAL amd has started to work on things properly, and since Alex is now
drm-misc committer that should all progress reasonably quickly.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 3.10 141/319] scsi: mpt3sas: Fix secure erase premature termination

[Willy Tarreau]

Hi James,

On Mon, Feb 06, 2017 at 10:38:48PM -0800, James Bottomley wrote:
> On Mon, 2017-02-06 at 23:26 +0100, Willy Tarreau wrote:
(...)
> > We don't have the referenced commit above in 3.10 so we should be 
> > safe. Additionally I checked that neither 4.4 nor 3.12 have them 
> > either, so that makes me feel confident that we can skip it in 3.10
> > as well.
> 
> The original was also racy with respect to multiple commands, so the
> above fixed the race as well.

OK so I tried to backport it to 3.10. I dropped a few parts which were
addressing this one marked for stable 4.4+ :
7ff723a ("scsi: mpt3sas: Unblock device after controller reset")

And I got the attached patch. All I know is that it builds. I'd appreciate
it if someone could confirm its validity, in which case I'll add it.

Thanks,
Willy

---

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 994656c..997e13f 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -219,6 +219,7 @@ struct MPT3SAS_TARGET {
  * @eedp_enable: eedp support enable bit
  * @eedp_type: 0(type_1), 1(type_2), 2(type_3)
  * @eedp_block_length: block size
+ * @ata_command_pending: SATL passthrough outstanding for device
  */
 struct MPT3SAS_DEVICE {
struct MPT3SAS_TARGET *sas_target;
@@ -227,6 +228,17 @@ struct MPT3SAS_DEVICE {
u8  configured_lun;
u8  block;
u8  tlr_snoop_check;
+   /*
+* Bug workaround for SATL handling: the mpt2/3sas firmware
+* doesn't return BUSY or TASK_SET_FULL for subsequent
+* commands while a SATL pass through is in operation as the
+* spec requires, it simply does nothing with them until the
+* pass through completes, causing them possibly to timeout if
+* the passthrough is a long executing command (like format or
+* secure erase).  This variable allows us to do the right
+* thing while a SATL command is pending.
+*/
+   unsigned long ata_command_pending;
 };
 
 #define MPT3_CMD_NOT_USED  0x8000  /* free */
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index e414b71..db38f70 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -3515,9 +3515,18 @@ _scsih_eedp_error_handling(struct scsi_cmnd *scmd, u16 
ioc_status)
SAM_STAT_CHECK_CONDITION;
 }
 
-static inline bool ata_12_16_cmd(struct scsi_cmnd *scmd)
+static int _scsih_set_satl_pending(struct scsi_cmnd *scmd, bool pending)
 {
-   return (scmd->cmnd[0] == ATA_12 || scmd->cmnd[0] == ATA_16);
+   struct MPT3SAS_DEVICE *priv = scmd->device->hostdata;
+
+   if (scmd->cmnd[0] != ATA_12 && scmd->cmnd[0] != ATA_16)
+   return 0;
+
+   if (pending)
+   return test_and_set_bit(0, >ata_command_pending);
+
+   clear_bit(0, >ata_command_pending);
+   return 0;
 }
 
 /**
@@ -3547,13 +3556,6 @@ _scsih_qcmd_lck(struct scsi_cmnd *scmd, void 
(*done)(struct scsi_cmnd *))
scsi_print_command(scmd);
 #endif
 
-   /*
-* Lock the device for any subsequent command until command is
-* done.
-*/
-   if (ata_12_16_cmd(scmd))
-   scsi_internal_device_block(scmd->device);
-
scmd->scsi_done = done;
sas_device_priv_data = scmd->device->hostdata;
if (!sas_device_priv_data || !sas_device_priv_data->sas_target) {
@@ -3568,6 +3570,19 @@ _scsih_qcmd_lck(struct scsi_cmnd *scmd, void 
(*done)(struct scsi_cmnd *))
return 0;
}
 
+   /*
+* Bug work around for firmware SATL handling.  The loop
+* is based on atomic operations and ensures consistency
+* since we're lockless at this point
+*/
+   do {
+   if (test_bit(0, _device_priv_data->ata_command_pending)) {
+   scmd->result = SAM_STAT_BUSY;
+   scmd->scsi_done(scmd);
+   return 0;
+   }
+   } while (_scsih_set_satl_pending(scmd, true));
+
sas_target_priv_data = sas_device_priv_data->sas_target;
 
/* invalid device handle */
@@ -4057,8 +4072,7 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 
msix_index, u32 reply)
if (scmd == NULL)
return 1;
 
-   if (ata_12_16_cmd(scmd))
-   scsi_internal_device_unblock(scmd->device, SDEV_RUNNING);
+   _scsih_set_satl_pending(scmd, false);
 
mpi_request = mpt3sas_base_get_msg_frame(ioc, smid);
 

Re: [PATCH 3.10 141/319] scsi: mpt3sas: Fix secure erase premature termination

[Willy Tarreau]

Hi James,

On Mon, Feb 06, 2017 at 10:38:48PM -0800, James Bottomley wrote:
> On Mon, 2017-02-06 at 23:26 +0100, Willy Tarreau wrote:
(...)
> > We don't have the referenced commit above in 3.10 so we should be 
> > safe. Additionally I checked that neither 4.4 nor 3.12 have them 
> > either, so that makes me feel confident that we can skip it in 3.10
> > as well.
> 
> The original was also racy with respect to multiple commands, so the
> above fixed the race as well.

OK so I tried to backport it to 3.10. I dropped a few parts which were
addressing this one marked for stable 4.4+ :
7ff723a ("scsi: mpt3sas: Unblock device after controller reset")

And I got the attached patch. All I know is that it builds. I'd appreciate
it if someone could confirm its validity, in which case I'll add it.

Thanks,
Willy

---

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 994656c..997e13f 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -219,6 +219,7 @@ struct MPT3SAS_TARGET {
  * @eedp_enable: eedp support enable bit
  * @eedp_type: 0(type_1), 1(type_2), 2(type_3)
  * @eedp_block_length: block size
+ * @ata_command_pending: SATL passthrough outstanding for device
  */
 struct MPT3SAS_DEVICE {
struct MPT3SAS_TARGET *sas_target;
@@ -227,6 +228,17 @@ struct MPT3SAS_DEVICE {
u8  configured_lun;
u8  block;
u8  tlr_snoop_check;
+   /*
+* Bug workaround for SATL handling: the mpt2/3sas firmware
+* doesn't return BUSY or TASK_SET_FULL for subsequent
+* commands while a SATL pass through is in operation as the
+* spec requires, it simply does nothing with them until the
+* pass through completes, causing them possibly to timeout if
+* the passthrough is a long executing command (like format or
+* secure erase).  This variable allows us to do the right
+* thing while a SATL command is pending.
+*/
+   unsigned long ata_command_pending;
 };
 
 #define MPT3_CMD_NOT_USED  0x8000  /* free */
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index e414b71..db38f70 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -3515,9 +3515,18 @@ _scsih_eedp_error_handling(struct scsi_cmnd *scmd, u16 
ioc_status)
SAM_STAT_CHECK_CONDITION;
 }
 
-static inline bool ata_12_16_cmd(struct scsi_cmnd *scmd)
+static int _scsih_set_satl_pending(struct scsi_cmnd *scmd, bool pending)
 {
-   return (scmd->cmnd[0] == ATA_12 || scmd->cmnd[0] == ATA_16);
+   struct MPT3SAS_DEVICE *priv = scmd->device->hostdata;
+
+   if (scmd->cmnd[0] != ATA_12 && scmd->cmnd[0] != ATA_16)
+   return 0;
+
+   if (pending)
+   return test_and_set_bit(0, >ata_command_pending);
+
+   clear_bit(0, >ata_command_pending);
+   return 0;
 }
 
 /**
@@ -3547,13 +3556,6 @@ _scsih_qcmd_lck(struct scsi_cmnd *scmd, void 
(*done)(struct scsi_cmnd *))
scsi_print_command(scmd);
 #endif
 
-   /*
-* Lock the device for any subsequent command until command is
-* done.
-*/
-   if (ata_12_16_cmd(scmd))
-   scsi_internal_device_block(scmd->device);
-
scmd->scsi_done = done;
sas_device_priv_data = scmd->device->hostdata;
if (!sas_device_priv_data || !sas_device_priv_data->sas_target) {
@@ -3568,6 +3570,19 @@ _scsih_qcmd_lck(struct scsi_cmnd *scmd, void 
(*done)(struct scsi_cmnd *))
return 0;
}
 
+   /*
+* Bug work around for firmware SATL handling.  The loop
+* is based on atomic operations and ensures consistency
+* since we're lockless at this point
+*/
+   do {
+   if (test_bit(0, _device_priv_data->ata_command_pending)) {
+   scmd->result = SAM_STAT_BUSY;
+   scmd->scsi_done(scmd);
+   return 0;
+   }
+   } while (_scsih_set_satl_pending(scmd, true));
+
sas_target_priv_data = sas_device_priv_data->sas_target;
 
/* invalid device handle */
@@ -4057,8 +4072,7 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 
msix_index, u32 reply)
if (scmd == NULL)
return 1;
 
-   if (ata_12_16_cmd(scmd))
-   scsi_internal_device_unblock(scmd->device, SDEV_RUNNING);
+   _scsih_set_satl_pending(scmd, false);
 
mpi_request = mpt3sas_base_get_msg_frame(ioc, smid);
 

Re: [PATCH v3 1/7] drm: Add DRM support for tiny LCD displays

[Daniel Vetter]

On Mon, Feb 06, 2017 at 08:23:36PM +0100, Noralf Trønnes wrote:
> 
> Den 06.02.2017 10.17, skrev Thierry Reding:
> > On Tue, Jan 31, 2017 at 05:03:13PM +0100, Noralf Trønnes wrote:
> > > tinydrm provides helpers for very simple displays that can use
> > > CMA backed framebuffers and need flushing on changes.
> > > 
> > > Signed-off-by: Noralf Trønnes 
> > > Acked-by: Daniel Vetter 
> > > ---
> > > 
> > > Changes since version 2:
> > > - Remove fbdev after drm unregister, not before.
> > > 
> > > Changes since version 1:
> > > - Add tinydrm.rst
> > > - Set tdev->fbdev_cma=NULL on unregister (lastclose is called after that).
> > > - Remove some DRM_DEBUG*()
> > > 
> > >   Documentation/gpu/index.rst |   1 +
> > >   Documentation/gpu/tinydrm.rst   |  21 ++
> > >   drivers/gpu/drm/Kconfig |   2 +
> > >   drivers/gpu/drm/Makefile|   1 +
> > >   drivers/gpu/drm/tinydrm/Kconfig |   8 +
> > >   drivers/gpu/drm/tinydrm/Makefile|   1 +
> > >   drivers/gpu/drm/tinydrm/core/Makefile   |   3 +
> > >   drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 377 
> > > 
> > >   drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 234 +
> > >   include/drm/tinydrm/tinydrm.h   | 115 +
> > >   10 files changed, 763 insertions(+)
> > >   create mode 100644 Documentation/gpu/tinydrm.rst
> > >   create mode 100644 drivers/gpu/drm/tinydrm/Kconfig
> > >   create mode 100644 drivers/gpu/drm/tinydrm/Makefile
> > >   create mode 100644 drivers/gpu/drm/tinydrm/core/Makefile
> > >   create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> > >   create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> > >   create mode 100644 include/drm/tinydrm/tinydrm.h
> > I realize this is totally subjective, but this feels somewhat too much
> > of a separation. Given the helper nature of TinyDRM, I think it would be
> > more appropriate to move the helpers themselves into drm_tiny.[ch] and
> > then maybe add a subdirectory drivers/gpu/drm/tiny that contains all the
> > drivers that use the helpers.
> > 
> > The separation above further shows in subsequent patches where helpers
> > are added to tinydrm that aren't specific to TinyDRM. So this make the
> > new helpers appear as more of a subsystem in DRM rather than a helper
> > library. It also makes things somewhat inconsistent with existing
> > infrastructure.
> 
> What I have done with tinydrm is to do as little as possible in the
> core helper. The minimum required to pull together
> drm_simple_display_pipe, cma helper + fbdev and framebuffer flushing.
> 
> Then I have added a set of functions that ease the writing of drivers
> for RGB565 displays with optional backlight and regulator.
> 
> Added to that is a controller library that handles register access (will
> use regmap for non-mipi) and framebuffer flushing (set the windowing
> registers and write the buffer to the pixel register).
> 
> And at last there's the display driver that initializes the controller
> to match a particular panel.
> 
> Maybe I should narrow tinydrm to _just_ support "RGB565 displays with
> optional backlight and regulator". It looks like I split it up to much,
> unless someone sees a need for the core of tinydrm elsewhere.
> 
> I think it's hard to avoid the subsystem smell here. These displays are
> really simple, fbdev is more than enough to cover their needs.
> But fbdev is closed.
> 
> I'm glad you pick on this, as getting the architecture right will save
> me maintenance down the line. I did paint me into a corner with
> staging/fbtft and I'm not keen on repeating that (to my defence it was
> my first C code since university and I had 2 displays that had some
> similarities which ended up as fbtft).

tbh I'm not sure either whether the tinydrm midlayer is good or not. But
then it is what it says on the tin, i.e. tiny, so not much work to
demidlayer if we notice a clear need for that change. I wouldn't worry
about this for now, but good to keep in mind. In the end, good design is
design that can be changed, because you'll only get it right until the
next unforseen thing happens :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v3 1/7] drm: Add DRM support for tiny LCD displays

[Daniel Vetter]

On Mon, Feb 06, 2017 at 08:23:36PM +0100, Noralf Trønnes wrote:
> 
> Den 06.02.2017 10.17, skrev Thierry Reding:
> > On Tue, Jan 31, 2017 at 05:03:13PM +0100, Noralf Trønnes wrote:
> > > tinydrm provides helpers for very simple displays that can use
> > > CMA backed framebuffers and need flushing on changes.
> > > 
> > > Signed-off-by: Noralf Trønnes 
> > > Acked-by: Daniel Vetter 
> > > ---
> > > 
> > > Changes since version 2:
> > > - Remove fbdev after drm unregister, not before.
> > > 
> > > Changes since version 1:
> > > - Add tinydrm.rst
> > > - Set tdev->fbdev_cma=NULL on unregister (lastclose is called after that).
> > > - Remove some DRM_DEBUG*()
> > > 
> > >   Documentation/gpu/index.rst |   1 +
> > >   Documentation/gpu/tinydrm.rst   |  21 ++
> > >   drivers/gpu/drm/Kconfig |   2 +
> > >   drivers/gpu/drm/Makefile|   1 +
> > >   drivers/gpu/drm/tinydrm/Kconfig |   8 +
> > >   drivers/gpu/drm/tinydrm/Makefile|   1 +
> > >   drivers/gpu/drm/tinydrm/core/Makefile   |   3 +
> > >   drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 377 
> > > 
> > >   drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 234 +
> > >   include/drm/tinydrm/tinydrm.h   | 115 +
> > >   10 files changed, 763 insertions(+)
> > >   create mode 100644 Documentation/gpu/tinydrm.rst
> > >   create mode 100644 drivers/gpu/drm/tinydrm/Kconfig
> > >   create mode 100644 drivers/gpu/drm/tinydrm/Makefile
> > >   create mode 100644 drivers/gpu/drm/tinydrm/core/Makefile
> > >   create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> > >   create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> > >   create mode 100644 include/drm/tinydrm/tinydrm.h
> > I realize this is totally subjective, but this feels somewhat too much
> > of a separation. Given the helper nature of TinyDRM, I think it would be
> > more appropriate to move the helpers themselves into drm_tiny.[ch] and
> > then maybe add a subdirectory drivers/gpu/drm/tiny that contains all the
> > drivers that use the helpers.
> > 
> > The separation above further shows in subsequent patches where helpers
> > are added to tinydrm that aren't specific to TinyDRM. So this make the
> > new helpers appear as more of a subsystem in DRM rather than a helper
> > library. It also makes things somewhat inconsistent with existing
> > infrastructure.
> 
> What I have done with tinydrm is to do as little as possible in the
> core helper. The minimum required to pull together
> drm_simple_display_pipe, cma helper + fbdev and framebuffer flushing.
> 
> Then I have added a set of functions that ease the writing of drivers
> for RGB565 displays with optional backlight and regulator.
> 
> Added to that is a controller library that handles register access (will
> use regmap for non-mipi) and framebuffer flushing (set the windowing
> registers and write the buffer to the pixel register).
> 
> And at last there's the display driver that initializes the controller
> to match a particular panel.
> 
> Maybe I should narrow tinydrm to _just_ support "RGB565 displays with
> optional backlight and regulator". It looks like I split it up to much,
> unless someone sees a need for the core of tinydrm elsewhere.
> 
> I think it's hard to avoid the subsystem smell here. These displays are
> really simple, fbdev is more than enough to cover their needs.
> But fbdev is closed.
> 
> I'm glad you pick on this, as getting the architecture right will save
> me maintenance down the line. I did paint me into a corner with
> staging/fbtft and I'm not keen on repeating that (to my defence it was
> my first C code since university and I had 2 displays that had some
> similarities which ended up as fbtft).

tbh I'm not sure either whether the tinydrm midlayer is good or not. But
then it is what it says on the tin, i.e. tiny, so not much work to
demidlayer if we notice a clear need for that change. I wouldn't worry
about this for now, but good to keep in mind. In the end, good design is
design that can be changed, because you'll only get it right until the
next unforseen thing happens :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v4] zram: extend zero pages to same element pages

[Minchan Kim]

Hi Andrew,

On Mon, Feb 06, 2017 at 12:16:44AM +0900, Minchan Kim wrote:
> From: zhouxianrong 
> 
> the idea is that without doing more calculations we extend zero pages
> to same element pages for zram. zero page is special case of
> same element page with zero element.
> 
> 1. the test is done under android 7.0
> 2. startup too many applications circularly
> 3. sample the zero pages, same pages (none-zero element)
>and total pages in function page_zero_filled
> 
> the result is listed as below:
> 
> ZERO  SAMETOTAL
> 36214 17842   598196
> 
>   ZERO/TOTAL   SAME/TOTAL   (ZERO+SAME)/TOTAL ZERO/SAME
> AVERAGE   0.060631909  0.024990816  0.085622726   
> 2.663825038
> STDEV 0.00674612   0.005887625  0.009707034   2.115881328
> MAX   0.069698422  0.030046087  0.094975336   
> 7.56043956
> MIN   0.03959586   0.007332205  0.056055193   
> 1.928985507
> 
> from above data, the benefit is about 2.5% and up to 3% of total
> swapout pages.
> 
> the defect of the patch is that when we recovery a page from
> non-zero element the operations are low efficient for partial
> read.
> 
> This patch extend zero_page to same_page so if there is any user to have
> monitored zero_pages, he will be surprised if the number is increased
> but it's no harmful, I believe.
> 
> Link: 
> http://lkml.kernel.org/r/1483692145-75357-1-git-send-email-zhouxianr...@huawei.com
> Signed-off-by: zhouxianrong 
> Signed-off-by: Minchan Kim 

zhouxianrong pointed out we shouldn't free same element pages in zram_meta_free.
Otherwise, it can encounter oops due to invalid handle passed into zram_free.
This patch fixes it. Please fold this patch into 
zram-extend-zero-pages-to-same-element-pages.patch.

Thanks.


>From e5a2a1dac4783f29d028170724578c0d11c80975 Mon Sep 17 00:00:00 2001
From: Minchan Kim 
Date: Tue, 7 Feb 2017 12:00:05 +0900
Subject: [PATCH] zram: do not free same element pages in zram_meta_free

zhouxianrong pointed out that we shouldn't free same element pages
in zram_meta_free. Otherwise, it will encounter oops due to invalid
handle value.

Signed-off-by: Minchan Kim 
---
Andrew,

Please fold it to zram-extend-zero-pages-to-same-element-pages.patch.

Thanks.

 drivers/block/zram/zram_drv.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index c20b05a84f21..a25d34a8af19 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -425,8 +425,11 @@ static void zram_meta_free(struct zram_meta *meta, u64 
disksize)
/* Free all pages that are still in this zram device */
for (index = 0; index < num_pages; index++) {
unsigned long handle = meta->table[index].handle;
-
-   if (!handle)
+   /*
+* No memory is allocated for same element filled pages.
+* Simply clear same page flag.
+*/
+   if (!handle || zram_test_flag(meta, index, ZRAM_SAME))
continue;
 
zs_free(meta->mem_pool, handle);
-- 
2.7.4

Re: [PATCH v4] zram: extend zero pages to same element pages

[Minchan Kim]

Hi Andrew,

On Mon, Feb 06, 2017 at 12:16:44AM +0900, Minchan Kim wrote:
> From: zhouxianrong 
> 
> the idea is that without doing more calculations we extend zero pages
> to same element pages for zram. zero page is special case of
> same element page with zero element.
> 
> 1. the test is done under android 7.0
> 2. startup too many applications circularly
> 3. sample the zero pages, same pages (none-zero element)
>and total pages in function page_zero_filled
> 
> the result is listed as below:
> 
> ZERO  SAMETOTAL
> 36214 17842   598196
> 
>   ZERO/TOTAL   SAME/TOTAL   (ZERO+SAME)/TOTAL ZERO/SAME
> AVERAGE   0.060631909  0.024990816  0.085622726   
> 2.663825038
> STDEV 0.00674612   0.005887625  0.009707034   2.115881328
> MAX   0.069698422  0.030046087  0.094975336   
> 7.56043956
> MIN   0.03959586   0.007332205  0.056055193   
> 1.928985507
> 
> from above data, the benefit is about 2.5% and up to 3% of total
> swapout pages.
> 
> the defect of the patch is that when we recovery a page from
> non-zero element the operations are low efficient for partial
> read.
> 
> This patch extend zero_page to same_page so if there is any user to have
> monitored zero_pages, he will be surprised if the number is increased
> but it's no harmful, I believe.
> 
> Link: 
> http://lkml.kernel.org/r/1483692145-75357-1-git-send-email-zhouxianr...@huawei.com
> Signed-off-by: zhouxianrong 
> Signed-off-by: Minchan Kim 

zhouxianrong pointed out we shouldn't free same element pages in zram_meta_free.
Otherwise, it can encounter oops due to invalid handle passed into zram_free.
This patch fixes it. Please fold this patch into 
zram-extend-zero-pages-to-same-element-pages.patch.

Thanks.


>From e5a2a1dac4783f29d028170724578c0d11c80975 Mon Sep 17 00:00:00 2001
From: Minchan Kim 
Date: Tue, 7 Feb 2017 12:00:05 +0900
Subject: [PATCH] zram: do not free same element pages in zram_meta_free

zhouxianrong pointed out that we shouldn't free same element pages
in zram_meta_free. Otherwise, it will encounter oops due to invalid
handle value.

Signed-off-by: Minchan Kim 
---
Andrew,

Please fold it to zram-extend-zero-pages-to-same-element-pages.patch.

Thanks.

 drivers/block/zram/zram_drv.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index c20b05a84f21..a25d34a8af19 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -425,8 +425,11 @@ static void zram_meta_free(struct zram_meta *meta, u64 
disksize)
/* Free all pages that are still in this zram device */
for (index = 0; index < num_pages; index++) {
unsigned long handle = meta->table[index].handle;
-
-   if (!handle)
+   /*
+* No memory is allocated for same element filled pages.
+* Simply clear same page flag.
+*/
+   if (!handle || zram_test_flag(meta, index, ZRAM_SAME))
continue;
 
zs_free(meta->mem_pool, handle);
-- 
2.7.4

Re: [PATCH 1/4] drm/rockchip: Do not use DMA mapping API if attached to IOMMU domain

[Tomasz Figa]

Hi Mark,

Thanks for reviving this series and sorry for not taking care of it
myself. Please see some comments inline.

On Tue, Feb 7, 2017 at 3:09 PM, Mark Yao  wrote:
> From: Tomasz Figa 
>
> The API is not suitable for subsystems consisting of multiple devices
> and requires severe hacks to use it. To mitigate this, this patch
> implements allocation and address space management locally by using
> helpers provided by DRM framework, like other DRM drivers do, e.g.
> Tegra.
>
> This patch should not introduce any functional changes until the driver
> is made to attach subdevices into an IOMMU domain with the generic IOMMU
> API, which will happen in following patch. Based heavily on GEM
> implementation of Tegra DRM driver.
>
> Signed-off-by: Tomasz Figa 
> Signed-off-by: Shunqian Zheng 
> Acked-by: Mark Yao 

I believe you need your Signed-off-by here.

> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   4 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 217 
> ++--
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.h |   8 +
>  3 files changed, 219 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> index fb6226c..7c123d9 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> @@ -30,6 +30,7 @@
>
>  struct drm_device;
>  struct drm_connector;
> +struct iommu_domain;
>
>  /*
>   * Rockchip drm private crtc funcs.
> @@ -60,7 +61,8 @@ struct rockchip_drm_private {
> struct drm_gem_object *fbdev_bo;
> const struct rockchip_crtc_funcs *crtc_funcs[ROCKCHIP_MAX_CRTC];
> struct drm_atomic_state *state;
> -
> +   struct iommu_domain *domain;
> +   struct drm_mm mm;
> struct list_head psr_list;
> spinlock_t psr_list_lock;
>  };
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> index b70f942..5209392 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> @@ -16,11 +16,135 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "rockchip_drm_drv.h"
>  #include "rockchip_drm_gem.h"
>
> -static int rockchip_gem_alloc_buf(struct rockchip_gem_object *rk_obj,
> +static int rockchip_gem_iommu_map(struct rockchip_gem_object *rk_obj)
> +{
> +   struct drm_device *drm = rk_obj->base.dev;
> +   struct rockchip_drm_private *private = drm->dev_private;
> +   int prot = IOMMU_READ | IOMMU_WRITE;
> +   ssize_t ret;
> +
> +   ret = drm_mm_insert_node_generic(>mm, _obj->mm,
> +rk_obj->base.size, PAGE_SIZE,
> +0, 0);
> +   if (ret < 0) {
> +   DRM_ERROR("out of I/O virtual memory: %zd\n", ret);
> +   return ret;
> +   }
> +
> +   rk_obj->dma_addr = rk_obj->mm.start;
> +
> +   ret = iommu_map_sg(private->domain, rk_obj->dma_addr, 
> rk_obj->sgt->sgl,
> +  rk_obj->sgt->nents, prot);
> +   if (ret < 0) {
> +   DRM_ERROR("failed to map buffer: %zd\n", ret);
> +   goto err_remove_node;
> +   }
> +
> +   rk_obj->size = ret;
> +
> +   return 0;
> +
> +err_remove_node:
> +   drm_mm_remove_node(_obj->mm);
> +
> +   return ret;
> +}
> +
> +static int rockchip_gem_iommu_unmap(struct rockchip_gem_object *rk_obj)
> +{
> +   struct drm_device *drm = rk_obj->base.dev;
> +   struct rockchip_drm_private *private = drm->dev_private;
> +
> +   iommu_unmap(private->domain, rk_obj->dma_addr, rk_obj->size);
> +   drm_mm_remove_node(_obj->mm);
> +
> +   return 0;
> +}
> +
> +static int rockchip_gem_get_pages(struct rockchip_gem_object *rk_obj)
> +{
> +   struct drm_device *drm = rk_obj->base.dev;
> +   int ret, i;
> +   struct scatterlist *s;
> +
> +   rk_obj->pages = drm_gem_get_pages(_obj->base);
> +   if (IS_ERR(rk_obj->pages))
> +   return PTR_ERR(rk_obj->pages);
> +
> +   rk_obj->num_pages = rk_obj->base.size >> PAGE_SHIFT;
> +
> +   rk_obj->sgt = drm_prime_pages_to_sg(rk_obj->pages, rk_obj->num_pages);
> +   if (IS_ERR(rk_obj->sgt)) {
> +   ret = PTR_ERR(rk_obj->sgt);
> +   goto err_put_pages;
> +   }
> +
> +   /*
> +* Fake up the SG table so that dma_sync_sg_for_device() can be used
> +* to flush the pages associated with it.
> +*
> +* TODO: Replace this by drm_clflush_sg() once it can be implemented
> +* without relying on symbols that are not exported.
> +*/
> +   for_each_sg(rk_obj->sgt->sgl, s, rk_obj->sgt->nents, i)
> +   sg_dma_address(s) = sg_phys(s);
> +
> +   dma_sync_sg_for_device(drm->dev, rk_obj->sgt->sgl, 

Re: [PATCH 1/4] drm/rockchip: Do not use DMA mapping API if attached to IOMMU domain

[Tomasz Figa]

Hi Mark,

Thanks for reviving this series and sorry for not taking care of it
myself. Please see some comments inline.

On Tue, Feb 7, 2017 at 3:09 PM, Mark Yao  wrote:
> From: Tomasz Figa 
>
> The API is not suitable for subsystems consisting of multiple devices
> and requires severe hacks to use it. To mitigate this, this patch
> implements allocation and address space management locally by using
> helpers provided by DRM framework, like other DRM drivers do, e.g.
> Tegra.
>
> This patch should not introduce any functional changes until the driver
> is made to attach subdevices into an IOMMU domain with the generic IOMMU
> API, which will happen in following patch. Based heavily on GEM
> implementation of Tegra DRM driver.
>
> Signed-off-by: Tomasz Figa 
> Signed-off-by: Shunqian Zheng 
> Acked-by: Mark Yao 

I believe you need your Signed-off-by here.

> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   4 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 217 
> ++--
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.h |   8 +
>  3 files changed, 219 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> index fb6226c..7c123d9 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> @@ -30,6 +30,7 @@
>
>  struct drm_device;
>  struct drm_connector;
> +struct iommu_domain;
>
>  /*
>   * Rockchip drm private crtc funcs.
> @@ -60,7 +61,8 @@ struct rockchip_drm_private {
> struct drm_gem_object *fbdev_bo;
> const struct rockchip_crtc_funcs *crtc_funcs[ROCKCHIP_MAX_CRTC];
> struct drm_atomic_state *state;
> -
> +   struct iommu_domain *domain;
> +   struct drm_mm mm;
> struct list_head psr_list;
> spinlock_t psr_list_lock;
>  };
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> index b70f942..5209392 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> @@ -16,11 +16,135 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "rockchip_drm_drv.h"
>  #include "rockchip_drm_gem.h"
>
> -static int rockchip_gem_alloc_buf(struct rockchip_gem_object *rk_obj,
> +static int rockchip_gem_iommu_map(struct rockchip_gem_object *rk_obj)
> +{
> +   struct drm_device *drm = rk_obj->base.dev;
> +   struct rockchip_drm_private *private = drm->dev_private;
> +   int prot = IOMMU_READ | IOMMU_WRITE;
> +   ssize_t ret;
> +
> +   ret = drm_mm_insert_node_generic(>mm, _obj->mm,
> +rk_obj->base.size, PAGE_SIZE,
> +0, 0);
> +   if (ret < 0) {
> +   DRM_ERROR("out of I/O virtual memory: %zd\n", ret);
> +   return ret;
> +   }
> +
> +   rk_obj->dma_addr = rk_obj->mm.start;
> +
> +   ret = iommu_map_sg(private->domain, rk_obj->dma_addr, 
> rk_obj->sgt->sgl,
> +  rk_obj->sgt->nents, prot);
> +   if (ret < 0) {
> +   DRM_ERROR("failed to map buffer: %zd\n", ret);
> +   goto err_remove_node;
> +   }
> +
> +   rk_obj->size = ret;
> +
> +   return 0;
> +
> +err_remove_node:
> +   drm_mm_remove_node(_obj->mm);
> +
> +   return ret;
> +}
> +
> +static int rockchip_gem_iommu_unmap(struct rockchip_gem_object *rk_obj)
> +{
> +   struct drm_device *drm = rk_obj->base.dev;
> +   struct rockchip_drm_private *private = drm->dev_private;
> +
> +   iommu_unmap(private->domain, rk_obj->dma_addr, rk_obj->size);
> +   drm_mm_remove_node(_obj->mm);
> +
> +   return 0;
> +}
> +
> +static int rockchip_gem_get_pages(struct rockchip_gem_object *rk_obj)
> +{
> +   struct drm_device *drm = rk_obj->base.dev;
> +   int ret, i;
> +   struct scatterlist *s;
> +
> +   rk_obj->pages = drm_gem_get_pages(_obj->base);
> +   if (IS_ERR(rk_obj->pages))
> +   return PTR_ERR(rk_obj->pages);
> +
> +   rk_obj->num_pages = rk_obj->base.size >> PAGE_SHIFT;
> +
> +   rk_obj->sgt = drm_prime_pages_to_sg(rk_obj->pages, rk_obj->num_pages);
> +   if (IS_ERR(rk_obj->sgt)) {
> +   ret = PTR_ERR(rk_obj->sgt);
> +   goto err_put_pages;
> +   }
> +
> +   /*
> +* Fake up the SG table so that dma_sync_sg_for_device() can be used
> +* to flush the pages associated with it.
> +*
> +* TODO: Replace this by drm_clflush_sg() once it can be implemented
> +* without relying on symbols that are not exported.
> +*/
> +   for_each_sg(rk_obj->sgt->sgl, s, rk_obj->sgt->nents, i)
> +   sg_dma_address(s) = sg_phys(s);
> +
> +   dma_sync_sg_for_device(drm->dev, rk_obj->sgt->sgl, rk_obj->sgt->nents,
> +  DMA_TO_DEVICE);
> +
> +   return 0;
> +
> +err_put_pages:

Re: [PATCH 3.10 000/319] 3.10.105-stable review

[Willy Tarreau]

On Mon, Feb 06, 2017 at 08:56:25PM -0800, Guenter Roeck wrote:
> On 02/06/2017 02:48 PM, Willy Tarreau wrote:
> > On Mon, Feb 06, 2017 at 06:46:39AM -0800, Guenter Roeck wrote:
> > > > An updated patch was pushed here :
> > > > 
> > > >   
> > > > https://kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.10.105-rc2.gz
> > > > 
> > > 
> > > Better, but unfortunately there is now a different build error.
> > > 
> > > Build results:
> > >   total: 124 pass: 122 fail: 2
> > > Failed builds:
> > >   x86_64:allyesconfig
> > >   x86_64:allmodconfig
> > > 
> > > Qemu test results:
> > >   total: 83 pass: 83 fail: 0
> > > 
> > > Build error:
> > > 
> > > drivers/block/xen-blkback/common.h: In function 'blkif_get_x86_32_req':
> > > drivers/block/xen-blkback/common.h:272:2: error: implicit declaration of 
> > > function 'READ_ONCE'
> > 
> > So I could easily reproduce it on allmodconfig here and fix it, by
> > replacing this READ_ONCE with ACCESS_ONCE. You don't need to build again
> > Guenter, your report already helped me a lot.
> > 
> 
> This time everything builds fine.
> 
> Build results:
>   total: 124 pass: 124 fail: 0
> Qemu test results:
>   total: 83 pass: 83 fail: 0

Pretty cool, thanks!
Willy

Re: [PATCH 3.10 000/319] 3.10.105-stable review

[Willy Tarreau]

On Mon, Feb 06, 2017 at 08:56:25PM -0800, Guenter Roeck wrote:
> On 02/06/2017 02:48 PM, Willy Tarreau wrote:
> > On Mon, Feb 06, 2017 at 06:46:39AM -0800, Guenter Roeck wrote:
> > > > An updated patch was pushed here :
> > > > 
> > > >   
> > > > https://kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.10.105-rc2.gz
> > > > 
> > > 
> > > Better, but unfortunately there is now a different build error.
> > > 
> > > Build results:
> > >   total: 124 pass: 122 fail: 2
> > > Failed builds:
> > >   x86_64:allyesconfig
> > >   x86_64:allmodconfig
> > > 
> > > Qemu test results:
> > >   total: 83 pass: 83 fail: 0
> > > 
> > > Build error:
> > > 
> > > drivers/block/xen-blkback/common.h: In function 'blkif_get_x86_32_req':
> > > drivers/block/xen-blkback/common.h:272:2: error: implicit declaration of 
> > > function 'READ_ONCE'
> > 
> > So I could easily reproduce it on allmodconfig here and fix it, by
> > replacing this READ_ONCE with ACCESS_ONCE. You don't need to build again
> > Guenter, your report already helped me a lot.
> > 
> 
> This time everything builds fine.
> 
> Build results:
>   total: 124 pass: 124 fail: 0
> Qemu test results:
>   total: 83 pass: 83 fail: 0

Pretty cool, thanks!
Willy

Re: [PATCH 3.10 141/319] scsi: mpt3sas: Fix secure erase premature termination

[James Bottomley]

On Mon, 2017-02-06 at 23:26 +0100, Willy Tarreau wrote:
> Hi Sathya,
> 
> On Mon, Feb 06, 2017 at 09:21:44AM -0700, Sathya Prakash Veerichetty
> wrote:
> > Willy,
> > I think this patch had a problem and later modified to a different
> > blocking mechanism.  Could you please pull in the latest change for
> > this?
> 
> Much appreciated, thanks. I've checked and found the patch you're
> talking about :
> 
>   commit ffb58456589443ca572221fabbdef3db8483a779
>   Author: James Bottomley 
>   Date:   Sun Jan 1 09:39:24 2017 -0800
> 
> scsi: mpt3sas: fix hang on ata passthrough commands
> 
> mpt3sas has a firmware failure where it can only handle one pass
> through
> ATA command at a time.  If another comes in, contrary to the SAT
> standard, it will hang until the first one completes (causing
> long
> commands like secure erase to timeout).  The original fix was to
> block
> the device when an ATA command came in, but this caused a
> regression
> with
> 
> commit 669f044170d8933c3d66d231b69ea97cb8447338
> Author: Bart Van Assche 
> Date:   Tue Nov 22 16:17:13 2016 -0800
> 
> scsi: srp_transport: Move queuecommand() wait code to SCSI
> core
> 
> So fix the original fix of the secure erase timeout by properly
> returning SAM_STAT_BUSY like the SAT recommends.  The original
> patch
> also had a concurrency problem since scsih_qcmd is lockless at
> that
> point (this is fixed by using atomic bitops to set and test the
> flag).
> 
> [mkp: addressed feedback wrt. test_bit and fixed whitespace]
> 
> Fixes: 18f6084a989ba1b (mpt3sas: Fix secure erase premature
> termination)
> Signed-off-by: James Bottomley <
> james.bottom...@hansenpartnership.com>
> Acked-by: Sreekanth Reddy 
> Reviewed-by: Christoph Hellwig 
> Reported-by: Ingo Molnar 
> Tested-by: Ingo Molnar 
> Signed-off-by: Martin K. Petersen 
> 
> We don't have the referenced commit above in 3.10 so we should be 
> safe. Additionally I checked that neither 4.4 nor 3.12 have them 
> either, so that makes me feel confident that we can skip it in 3.10
> as well.

The original was also racy with respect to multiple commands, so the
above fixed the race as well.

James

Re: [PATCH 3.10 141/319] scsi: mpt3sas: Fix secure erase premature termination

[James Bottomley]

On Mon, 2017-02-06 at 23:26 +0100, Willy Tarreau wrote:
> Hi Sathya,
> 
> On Mon, Feb 06, 2017 at 09:21:44AM -0700, Sathya Prakash Veerichetty
> wrote:
> > Willy,
> > I think this patch had a problem and later modified to a different
> > blocking mechanism.  Could you please pull in the latest change for
> > this?
> 
> Much appreciated, thanks. I've checked and found the patch you're
> talking about :
> 
>   commit ffb58456589443ca572221fabbdef3db8483a779
>   Author: James Bottomley 
>   Date:   Sun Jan 1 09:39:24 2017 -0800
> 
> scsi: mpt3sas: fix hang on ata passthrough commands
> 
> mpt3sas has a firmware failure where it can only handle one pass
> through
> ATA command at a time.  If another comes in, contrary to the SAT
> standard, it will hang until the first one completes (causing
> long
> commands like secure erase to timeout).  The original fix was to
> block
> the device when an ATA command came in, but this caused a
> regression
> with
> 
> commit 669f044170d8933c3d66d231b69ea97cb8447338
> Author: Bart Van Assche 
> Date:   Tue Nov 22 16:17:13 2016 -0800
> 
> scsi: srp_transport: Move queuecommand() wait code to SCSI
> core
> 
> So fix the original fix of the secure erase timeout by properly
> returning SAM_STAT_BUSY like the SAT recommends.  The original
> patch
> also had a concurrency problem since scsih_qcmd is lockless at
> that
> point (this is fixed by using atomic bitops to set and test the
> flag).
> 
> [mkp: addressed feedback wrt. test_bit and fixed whitespace]
> 
> Fixes: 18f6084a989ba1b (mpt3sas: Fix secure erase premature
> termination)
> Signed-off-by: James Bottomley <
> james.bottom...@hansenpartnership.com>
> Acked-by: Sreekanth Reddy 
> Reviewed-by: Christoph Hellwig 
> Reported-by: Ingo Molnar 
> Tested-by: Ingo Molnar 
> Signed-off-by: Martin K. Petersen 
> 
> We don't have the referenced commit above in 3.10 so we should be 
> safe. Additionally I checked that neither 4.4 nor 3.12 have them 
> either, so that makes me feel confident that we can skip it in 3.10
> as well.

The original was also racy with respect to multiple commands, so the
above fixed the race as well.

James

Re: [PATCH v2, 6/6] dt-bindings: phy-mt65xx-usb: add support for new version phy

[Chunfeng Yun]

On Fri, 2017-01-27 at 14:07 -0600, Rob Herring wrote:
> On Fri, Jan 20, 2017 at 04:18:41PM +0800, Chunfeng Yun wrote:
> > add a new compatible string for "mt2712", and move reference clock
> > into each port node;
> > 
> > Signed-off-by: Chunfeng Yun 
> > ---
> >  .../devicetree/bindings/phy/phy-mt65xx-usb.txt |   91 
> > +---
> >  1 file changed, 77 insertions(+), 14 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt 
> > b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> > index 33a2b1e..1d06604 100644
> > --- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> > +++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> > @@ -6,21 +6,27 @@ This binding describes a usb3.0 phy for mt65xx platforms 
> > of Medaitek SoC.
> >  Required properties (controller (parent) node):
> >   - compatible  : should be one of
> >   "mediatek,mt2701-u3phy"
> > + "mediatek,mt2712-u3phy"
> >   "mediatek,mt8173-u3phy"
> > - - reg : offset and length of register for phy, exclude port's
> > - register.
> > - - clocks  : a list of phandle + clock-specifier pairs, one for each
> > - entry in clock-names
> > - - clock-names : must contain
> > - "u3phya_ref": for reference clock of usb3.0 analog phy.
> >  
> >  Required nodes : a sub-node is required for each port the controller
> >   provides. Address range information including the usual
> >   'reg' property is used inside these nodes to describe
> >   the controller's topology.
> >  
> > +Optional properties (controller (parent) node):
> > + - reg : offset and length of register shared by multiple 
> > ports,
> 
> How is this optional?
I put register shared by ports in parent node, but no shared register
for new phy, so change it as optional.

> 
> > + exclude port's private register. It is needed on mt2701
> > + and mt8173, but not on mt2712.
> > +
> >  Required properties (port (child) node):
> >  - reg  : address and length of the register set for the port.
> > +- clocks   : a list of phandle + clock-specifier pairs, one for each
> > + entry in clock-names
> > +- clock-names  : must contain
> > + "ref_clk": 48M reference clock for HighSpeed analog phy; and
> 
> _clk is redundant. Just "ref"
Ok
> 
> > +   26M reference clock for SuperSpeed analog phy, 
> > sometimes is
> > +   24M, 25M or 27M, depended on platform.
> >  - #phy-cells   : should be 1 (See second example)
> >   cell after port phandle is phy type from:
> > - PHY_TYPE_USB2
> > @@ -31,21 +37,31 @@ Example:
> >  u3phy: usb-phy@1129 {
> > compatible = "mediatek,mt8173-u3phy";
> > reg = <0 0x1129 0 0x800>;
> > -   clocks = < CLK_APMIXED_REF2USB_TX>;
> > -   clock-names = "u3phya_ref";
> > #address-cells = <2>;
> > #size-cells = <2>;
> > ranges;
> > status = "okay";
> >  
> > -   phy_port0: port@11290800 {
> > -   reg = <0 0x11290800 0 0x800>;
> > +   u2port0: port@11290800 {
> > +   reg = <0 0x11290800 0 0x100>;
> > +   clocks = < CLK_APMIXED_REF2USB_TX>;
> > +   clock-names = "ref_clk";
> > #phy-cells = <1>;
> > status = "okay";
> > };
> >  
> > -   phy_port1: port@11291000 {
> > -   reg = <0 0x11291000 0 0x800>;
> > +   u3port0: port@11290900 {
> > +   reg = <0 0x11290800 0 0x700>;
> > +   clocks = <>;
> > +   clock-names = "ref_clk";
> > +   #phy-cells = <1>;
> > +   status = "okay";
> > +   };
> > +
> > +   u2port1: port@11291000 {
> > +   reg = <0 0x11291000 0 0x100>;
> > +   clocks = < CLK_APMIXED_REF2USB_TX>;
> > +   clock-names = "ref_clk";
> > #phy-cells = <1>;
> > status = "okay";
> > };
> > @@ -64,7 +80,54 @@ Example:
> >  
> >  usb30: usb@1127 {
> > ...
> > -   phys = <_port0 PHY_TYPE_USB3>;
> > -   phy-names = "usb3-0";
> > +   phys = < PHY_TYPE_USB2>, < PHY_TYPE_USB3>;
> > +   phy-names = "usb2-0", "usb3-0";
> > ...
> >  };
> > +
> > +
> > +Layout differences of banks between mt8173/mt2701 and mt2712
> > +-
> > +mt8173 and mt2701:
> > +portoffsetbank
> > +shared  0xSPLLC
> > +0x0100FMREG
> > +u2 port00x0800U2PHY_COM
> > +u3 port00x0900U3PHYD
> > +0x0a00U3PHYD_BANK2
> > +0x0b00U3PHYA
> > +0x0c00U3PHYA_DA
> > +u2 port10x1000U2PHY_COM
> > +u3 port10x1100U3PHYD
> > +0x1200U3PHYD_BANK2
> > +0x1300U3PHYA
> > +0x1400U3PHYA_DA
> > +u2 port20x1800U2PHY_COM
> > +...
> > +
> > +mt2712:
> > 

Re: [PATCH v2, 6/6] dt-bindings: phy-mt65xx-usb: add support for new version phy

[Chunfeng Yun]

On Fri, 2017-01-27 at 14:07 -0600, Rob Herring wrote:
> On Fri, Jan 20, 2017 at 04:18:41PM +0800, Chunfeng Yun wrote:
> > add a new compatible string for "mt2712", and move reference clock
> > into each port node;
> > 
> > Signed-off-by: Chunfeng Yun 
> > ---
> >  .../devicetree/bindings/phy/phy-mt65xx-usb.txt |   91 
> > +---
> >  1 file changed, 77 insertions(+), 14 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt 
> > b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> > index 33a2b1e..1d06604 100644
> > --- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> > +++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> > @@ -6,21 +6,27 @@ This binding describes a usb3.0 phy for mt65xx platforms 
> > of Medaitek SoC.
> >  Required properties (controller (parent) node):
> >   - compatible  : should be one of
> >   "mediatek,mt2701-u3phy"
> > + "mediatek,mt2712-u3phy"
> >   "mediatek,mt8173-u3phy"
> > - - reg : offset and length of register for phy, exclude port's
> > - register.
> > - - clocks  : a list of phandle + clock-specifier pairs, one for each
> > - entry in clock-names
> > - - clock-names : must contain
> > - "u3phya_ref": for reference clock of usb3.0 analog phy.
> >  
> >  Required nodes : a sub-node is required for each port the controller
> >   provides. Address range information including the usual
> >   'reg' property is used inside these nodes to describe
> >   the controller's topology.
> >  
> > +Optional properties (controller (parent) node):
> > + - reg : offset and length of register shared by multiple 
> > ports,
> 
> How is this optional?
I put register shared by ports in parent node, but no shared register
for new phy, so change it as optional.

> 
> > + exclude port's private register. It is needed on mt2701
> > + and mt8173, but not on mt2712.
> > +
> >  Required properties (port (child) node):
> >  - reg  : address and length of the register set for the port.
> > +- clocks   : a list of phandle + clock-specifier pairs, one for each
> > + entry in clock-names
> > +- clock-names  : must contain
> > + "ref_clk": 48M reference clock for HighSpeed analog phy; and
> 
> _clk is redundant. Just "ref"
Ok
> 
> > +   26M reference clock for SuperSpeed analog phy, 
> > sometimes is
> > +   24M, 25M or 27M, depended on platform.
> >  - #phy-cells   : should be 1 (See second example)
> >   cell after port phandle is phy type from:
> > - PHY_TYPE_USB2
> > @@ -31,21 +37,31 @@ Example:
> >  u3phy: usb-phy@1129 {
> > compatible = "mediatek,mt8173-u3phy";
> > reg = <0 0x1129 0 0x800>;
> > -   clocks = < CLK_APMIXED_REF2USB_TX>;
> > -   clock-names = "u3phya_ref";
> > #address-cells = <2>;
> > #size-cells = <2>;
> > ranges;
> > status = "okay";
> >  
> > -   phy_port0: port@11290800 {
> > -   reg = <0 0x11290800 0 0x800>;
> > +   u2port0: port@11290800 {
> > +   reg = <0 0x11290800 0 0x100>;
> > +   clocks = < CLK_APMIXED_REF2USB_TX>;
> > +   clock-names = "ref_clk";
> > #phy-cells = <1>;
> > status = "okay";
> > };
> >  
> > -   phy_port1: port@11291000 {
> > -   reg = <0 0x11291000 0 0x800>;
> > +   u3port0: port@11290900 {
> > +   reg = <0 0x11290800 0 0x700>;
> > +   clocks = <>;
> > +   clock-names = "ref_clk";
> > +   #phy-cells = <1>;
> > +   status = "okay";
> > +   };
> > +
> > +   u2port1: port@11291000 {
> > +   reg = <0 0x11291000 0 0x100>;
> > +   clocks = < CLK_APMIXED_REF2USB_TX>;
> > +   clock-names = "ref_clk";
> > #phy-cells = <1>;
> > status = "okay";
> > };
> > @@ -64,7 +80,54 @@ Example:
> >  
> >  usb30: usb@1127 {
> > ...
> > -   phys = <_port0 PHY_TYPE_USB3>;
> > -   phy-names = "usb3-0";
> > +   phys = < PHY_TYPE_USB2>, < PHY_TYPE_USB3>;
> > +   phy-names = "usb2-0", "usb3-0";
> > ...
> >  };
> > +
> > +
> > +Layout differences of banks between mt8173/mt2701 and mt2712
> > +-
> > +mt8173 and mt2701:
> > +portoffsetbank
> > +shared  0xSPLLC
> > +0x0100FMREG
> > +u2 port00x0800U2PHY_COM
> > +u3 port00x0900U3PHYD
> > +0x0a00U3PHYD_BANK2
> > +0x0b00U3PHYA
> > +0x0c00U3PHYA_DA
> > +u2 port10x1000U2PHY_COM
> > +u3 port10x1100U3PHYD
> > +0x1200U3PHYD_BANK2
> > +0x1300U3PHYA
> > +0x1400U3PHYA_DA
> > +u2 port20x1800U2PHY_COM
> > +...
> > +
> > +mt2712:
> > +portoffset

RE: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements

[Dexuan Cui]

> From: linux-block-ow...@vger.kernel.org [mailto:linux-block-
> ow...@vger.kernel.org] On Behalf Of Dexuan Cui
> with the linux-next kernel.
> 
> I can boot the guest with linux-next's next-20170130 without any issue,
> but since next-20170131 I haven't succeeded in booting the guest.
> 
> With next-20170203 (mentioned in my mail last Friday), I got the same
> calltrace as Hannes.
> 
> With today's linux-next (next-20170206), actually the calltrace changed to
> the below.
> [  122.023036]  ? remove_wait_queue+0x70/0x70
> [  122.051383]  async_synchronize_full+0x17/0x20
> [  122.076925]  do_init_module+0xc1/0x1f9
> [  122.097530]  load_module+0x24bc/0x2980
 
I don't know why it hangs here, but this is the same calltrace in my
last-Friday mail, which contains 2 calltraces. It looks the other calltrace has
been resolved by some changes between next-20170203 and today.

Here the kernel is trying to load the Hyper-V storage driver (hv_storvsc), and
the driver's __init and .probe have finished successfully and then the kernel
hangs here.

I believe something is broken recently, because I don't have any issue before
Jan 31. 

Thanks,
-- Dexuan

RE: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements

[Dexuan Cui]

> From: linux-block-ow...@vger.kernel.org [mailto:linux-block-
> ow...@vger.kernel.org] On Behalf Of Dexuan Cui
> with the linux-next kernel.
> 
> I can boot the guest with linux-next's next-20170130 without any issue,
> but since next-20170131 I haven't succeeded in booting the guest.
> 
> With next-20170203 (mentioned in my mail last Friday), I got the same
> calltrace as Hannes.
> 
> With today's linux-next (next-20170206), actually the calltrace changed to
> the below.
> [  122.023036]  ? remove_wait_queue+0x70/0x70
> [  122.051383]  async_synchronize_full+0x17/0x20
> [  122.076925]  do_init_module+0xc1/0x1f9
> [  122.097530]  load_module+0x24bc/0x2980
 
I don't know why it hangs here, but this is the same calltrace in my
last-Friday mail, which contains 2 calltraces. It looks the other calltrace has
been resolved by some changes between next-20170203 and today.

Here the kernel is trying to load the Hyper-V storage driver (hv_storvsc), and
the driver's __init and .probe have finished successfully and then the kernel
hangs here.

I believe something is broken recently, because I don't have any issue before
Jan 31. 

Thanks,
-- Dexuan

Re: [RFC v2] [ALSA][CONTROL] 1. Added 2 ioctls for reading/writing values of multiple controls in one go (at once) 2. Restructured the code for read/write of a single control

[Takashi Iwai]

On Tue, 07 Feb 2017 05:33:05 +0100,
Takashi Sakamoto wrote:
> 
> On Feb 3 2017 16:24, Takashi Iwai wrote:
> > On Thu, 02 Feb 2017 04:45:48 +0100,
> > Takashi Sakamoto wrote:
> >>
> >> I'm _strongly_ interested in your two patches, because it has a
> >> potentiality to purge ASoC abuse of TLV feature, which was introduced
> >> in  2014 with a bad reviewing process.
> >
> > I don't think it can be a replacement for the extended TLV usages.
> > The proposed API is nothing but a loop of ctl elem read/write, and I'm
> > not sure whether it worth to introduce the new ioctls just for that.
> 
> In my opinion, an idea to handle several control elements in one system
> call could perhaps overcome current limitation of control elements,
> which comes from definition of 'struct snd_ctl_elem_value'. Aim of the
> abuse of TLV feature in ASoC part essentially comes from the
> limitation, as long as I understand.

Yes, it's the limitation, but it won't be eased by this kind of patch.
The TLV usage came just because of its required data size, sometimes
over mega bytes.  It's not about the number of elements.  It's about
the data size a single element needs to deal with.


Takashi

Re: [PATCH v2] PCI: pciehp: Don't enable PME on runtime suspend

[Lukas Wunner]

On Mon, Feb 06, 2017 at 10:52:12PM +0100, Rafael J. Wysocki wrote:
> On Monday, February 06, 2017 10:20:41 PM Lukas Wunner wrote:
> > On Mon, Feb 06, 2017 at 11:54:05AM -0600, Bjorn Helgaas wrote:
> > > On Mon, Feb 06, 2017 at 06:54:37AM +0100, Lukas Wunner wrote:
> > > > Since commit 68db9bc81436 ("PCI: pciehp: Add runtime PM support for PCIe
> > > > hotplug ports") we runtime suspend a hotplug port to D3hot when all its
> > > > children are runtime suspended or none are present.
> > > > 
> > > > When runtime suspending the port the PCI core automatically enables PME:
> > > > pci_pm_runtime_suspend()
> > > > pci_finish_runtime_suspend()
> > > > __pci_enable_wake()
> > > > 
> > > > According to the PCI Express Base Specification, section 6.7.3.4:
> > > >"Note that PME and Hot-Plug Event interrupts (when both are
> > > > implemented) always share the same MSI or MSI-X vector [...]
> > > > If wake generation is required by the associated form factor
> > > > specification, a hot-plug capable Downstream Port must support
> > > > generation of a wakeup event (using the PME mechanism) on hotplug
> > > > events that occur when the system is in a sleep state or the Port
> > > > is in device state D1, D2, or D3Hot."
> > > > 
> > > > Thus, if the port is runtime suspended even though it is still occupied,
> > > > it may immediately be woken by a PME interrupt.
> > > 
> > > The spec goes on to say that a wakeup event should be generated when
> > > all three of these conditions occur:
> > > 
> > >   - status register for an enabled [hotplug] event transitions from
> > > not set to set
> > > 
> > >   - Port is in D1, D2, or D3hot,
> > > 
> > >   - PME_En is set
> > > 
> > > I think you're saying that if we put a hotplug-capable port that
> > > controls an occupied slot into D3hot, the port may immediately
> > > generate a wakeup PME.
> > > 
> > > What is the hotplug event that causes generation of this wakeup event?
> > 
> > If you had read all e-mails in this thread or looked at the bugzilla
> > entry I've created, you wouldn't have to ask this question.
> > 
> > I think it's disappointing that you're asking me to jump through
> > various hoops like creating a bugzilla entry, as well as threatening
> > to revert my patch, but are unwilling to even look at the bugzilla
> > entry or read the entire thread.  It is equally disappointing that
> > the reporter of the regression was unwilling or unable to provide
> > dmesg output for both machines so that we've got no real idea what
> > we're dealing with.
> > 
> > It's a Link Up event.
> > 
> > Which doesn't make sense of course because per the spec PME is only
> > supposed to be signaled when the Link Status *changes* from 0 to 1,
> 
> BTW, where exactly did you find this bit in the spec?

PCIe Base Spec, section 6.7.3.4:

"For form factors that support wake generation, a wakeup event must be
 generated if all three of the following conditions occur:

 * The status register for an enabled event transitions from not set to set
^^^
 * The Port is in device state D1, D2, or D3Hot, and
 * The PME_En bit in the Port's Power Management Control/Status register is
   set"


My point was that the Link Status shouldn't arbitrarily change from 0 to 1
after powering off the slot.

Best regards,

Lukas

Re: [RFC v2] [ALSA][CONTROL] 1. Added 2 ioctls for reading/writing values of multiple controls in one go (at once) 2. Restructured the code for read/write of a single control

[Takashi Iwai]

On Tue, 07 Feb 2017 05:33:05 +0100,
Takashi Sakamoto wrote:
> 
> On Feb 3 2017 16:24, Takashi Iwai wrote:
> > On Thu, 02 Feb 2017 04:45:48 +0100,
> > Takashi Sakamoto wrote:
> >>
> >> I'm _strongly_ interested in your two patches, because it has a
> >> potentiality to purge ASoC abuse of TLV feature, which was introduced
> >> in  2014 with a bad reviewing process.
> >
> > I don't think it can be a replacement for the extended TLV usages.
> > The proposed API is nothing but a loop of ctl elem read/write, and I'm
> > not sure whether it worth to introduce the new ioctls just for that.
> 
> In my opinion, an idea to handle several control elements in one system
> call could perhaps overcome current limitation of control elements,
> which comes from definition of 'struct snd_ctl_elem_value'. Aim of the
> abuse of TLV feature in ASoC part essentially comes from the
> limitation, as long as I understand.

Yes, it's the limitation, but it won't be eased by this kind of patch.
The TLV usage came just because of its required data size, sometimes
over mega bytes.  It's not about the number of elements.  It's about
the data size a single element needs to deal with.


Takashi

Re: [PATCH v2] PCI: pciehp: Don't enable PME on runtime suspend

[Lukas Wunner]

On Mon, Feb 06, 2017 at 10:52:12PM +0100, Rafael J. Wysocki wrote:
> On Monday, February 06, 2017 10:20:41 PM Lukas Wunner wrote:
> > On Mon, Feb 06, 2017 at 11:54:05AM -0600, Bjorn Helgaas wrote:
> > > On Mon, Feb 06, 2017 at 06:54:37AM +0100, Lukas Wunner wrote:
> > > > Since commit 68db9bc81436 ("PCI: pciehp: Add runtime PM support for PCIe
> > > > hotplug ports") we runtime suspend a hotplug port to D3hot when all its
> > > > children are runtime suspended or none are present.
> > > > 
> > > > When runtime suspending the port the PCI core automatically enables PME:
> > > > pci_pm_runtime_suspend()
> > > > pci_finish_runtime_suspend()
> > > > __pci_enable_wake()
> > > > 
> > > > According to the PCI Express Base Specification, section 6.7.3.4:
> > > >"Note that PME and Hot-Plug Event interrupts (when both are
> > > > implemented) always share the same MSI or MSI-X vector [...]
> > > > If wake generation is required by the associated form factor
> > > > specification, a hot-plug capable Downstream Port must support
> > > > generation of a wakeup event (using the PME mechanism) on hotplug
> > > > events that occur when the system is in a sleep state or the Port
> > > > is in device state D1, D2, or D3Hot."
> > > > 
> > > > Thus, if the port is runtime suspended even though it is still occupied,
> > > > it may immediately be woken by a PME interrupt.
> > > 
> > > The spec goes on to say that a wakeup event should be generated when
> > > all three of these conditions occur:
> > > 
> > >   - status register for an enabled [hotplug] event transitions from
> > > not set to set
> > > 
> > >   - Port is in D1, D2, or D3hot,
> > > 
> > >   - PME_En is set
> > > 
> > > I think you're saying that if we put a hotplug-capable port that
> > > controls an occupied slot into D3hot, the port may immediately
> > > generate a wakeup PME.
> > > 
> > > What is the hotplug event that causes generation of this wakeup event?
> > 
> > If you had read all e-mails in this thread or looked at the bugzilla
> > entry I've created, you wouldn't have to ask this question.
> > 
> > I think it's disappointing that you're asking me to jump through
> > various hoops like creating a bugzilla entry, as well as threatening
> > to revert my patch, but are unwilling to even look at the bugzilla
> > entry or read the entire thread.  It is equally disappointing that
> > the reporter of the regression was unwilling or unable to provide
> > dmesg output for both machines so that we've got no real idea what
> > we're dealing with.
> > 
> > It's a Link Up event.
> > 
> > Which doesn't make sense of course because per the spec PME is only
> > supposed to be signaled when the Link Status *changes* from 0 to 1,
> 
> BTW, where exactly did you find this bit in the spec?

PCIe Base Spec, section 6.7.3.4:

"For form factors that support wake generation, a wakeup event must be
 generated if all three of the following conditions occur:

 * The status register for an enabled event transitions from not set to set
^^^
 * The Port is in device state D1, D2, or D3Hot, and
 * The PME_En bit in the Port's Power Management Control/Status register is
   set"


My point was that the Link Status shouldn't arbitrarily change from 0 to 1
after powering off the slot.

Best regards,

Lukas

Re: [PATCH v2] PCI: pciehp: Don't enable PME on runtime suspend

[Lukas Wunner]

On Mon, Feb 06, 2017 at 04:15:02PM -0600, Bjorn Helgaas wrote:
> On Mon, Feb 06, 2017 at 10:20:41PM +0100, Lukas Wunner wrote:
> > On Mon, Feb 06, 2017 at 11:54:05AM -0600, Bjorn Helgaas wrote:
> > > What is the hotplug event that causes generation of this wakeup event?
> > 
> > If you had read all e-mails in this thread or looked at the bugzilla
> > entry I've created, you wouldn't have to ask this question.
> 
> I'm sorry, I don't necessarily have time to sort through all the
> emails.  My idea is that the changelog should be a self-contained
> justification for the patch.  The bugzilla is for supporting details
> and future archaeologists.
> 
> > I think it's disappointing that you're asking me to jump through
> > various hoops like creating a bugzilla entry, as well as threatening
> > to revert my patch, but are unwilling to even look at the bugzilla
> > entry or read the entire thread.  It is equally disappointing that
> > the reporter of the regression was unwilling or unable to provide
> > dmesg output for both machines so that we've got no real idea what
> > we're dealing with.
> 
> I beg your pardon?  I don't think it's fair to malign Yinghai.  He's
> tested at least two machines and at least two patches, and it's only
> been two working days since he reported the problem.

I think the commercialization of Linux kernel development has put this
open source project in a sorry state if an unpaid volunteer is told off
because he expresses disappointment that a paid contributor is asking
him to debug an issue on secret hardware using secret patches and not
providing secret dmesg output.


> If you think a bugzilla is onerous

Hold on.  I didn't say a bugzilla is onerous, I said I'm disappointed
that you're asking me to create one and then don't look at it.

Lukas

Re: [PATCH v2] PCI: pciehp: Don't enable PME on runtime suspend

[Lukas Wunner]

On Mon, Feb 06, 2017 at 04:15:02PM -0600, Bjorn Helgaas wrote:
> On Mon, Feb 06, 2017 at 10:20:41PM +0100, Lukas Wunner wrote:
> > On Mon, Feb 06, 2017 at 11:54:05AM -0600, Bjorn Helgaas wrote:
> > > What is the hotplug event that causes generation of this wakeup event?
> > 
> > If you had read all e-mails in this thread or looked at the bugzilla
> > entry I've created, you wouldn't have to ask this question.
> 
> I'm sorry, I don't necessarily have time to sort through all the
> emails.  My idea is that the changelog should be a self-contained
> justification for the patch.  The bugzilla is for supporting details
> and future archaeologists.
> 
> > I think it's disappointing that you're asking me to jump through
> > various hoops like creating a bugzilla entry, as well as threatening
> > to revert my patch, but are unwilling to even look at the bugzilla
> > entry or read the entire thread.  It is equally disappointing that
> > the reporter of the regression was unwilling or unable to provide
> > dmesg output for both machines so that we've got no real idea what
> > we're dealing with.
> 
> I beg your pardon?  I don't think it's fair to malign Yinghai.  He's
> tested at least two machines and at least two patches, and it's only
> been two working days since he reported the problem.

I think the commercialization of Linux kernel development has put this
open source project in a sorry state if an unpaid volunteer is told off
because he expresses disappointment that a paid contributor is asking
him to debug an issue on secret hardware using secret patches and not
providing secret dmesg output.


> If you think a bugzilla is onerous

Hold on.  I didn't say a bugzilla is onerous, I said I'm disappointed
that you're asking me to create one and then don't look at it.

Lukas

[PATCH -next 1/3] arm64: dts: mt8173: add reference clock for usb

[Chunfeng Yun]

Due to the reference clock comes from 26M oscillator directly
on mt8173, and it is a fixed-clock in DTS which always turned
on, we ignore it before. But on some platforms, it comes
from PLL, and need be controlled, so here add it, no matter
it is a fixed-clock or not.

Signed-off-by: Chunfeng Yun 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 07fd2eb..e2862b6 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -729,9 +729,11 @@
   < PHY_TYPE_USB2>;
power-domains = < MT8173_POWER_DOMAIN_USB>;
clocks = < CLK_TOP_USB30_SEL>,
+<>,
 < CLK_PERI_USB0>,
 < CLK_PERI_USB1>;
clock-names = "sys_ck",
+ "ref_ck",
  "wakeup_deb_p0",
  "wakeup_deb_p1";
mediatek,syscon-wakeup = <>;
@@ -746,8 +748,8 @@
reg-names = "mac";
interrupts = ;
power-domains = < 
MT8173_POWER_DOMAIN_USB>;
-   clocks = < CLK_TOP_USB30_SEL>;
-   clock-names = "sys_ck";
+   clocks = < CLK_TOP_USB30_SEL>, 
<>;
+   clock-names = "sys_ck", "ref_ck";
status = "disabled";
};
};
-- 
1.7.9.5

[PATCH -next 1/3] arm64: dts: mt8173: add reference clock for usb

[Chunfeng Yun]

Due to the reference clock comes from 26M oscillator directly
on mt8173, and it is a fixed-clock in DTS which always turned
on, we ignore it before. But on some platforms, it comes
from PLL, and need be controlled, so here add it, no matter
it is a fixed-clock or not.

Signed-off-by: Chunfeng Yun 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 07fd2eb..e2862b6 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -729,9 +729,11 @@
   < PHY_TYPE_USB2>;
power-domains = < MT8173_POWER_DOMAIN_USB>;
clocks = < CLK_TOP_USB30_SEL>,
+<>,
 < CLK_PERI_USB0>,
 < CLK_PERI_USB1>;
clock-names = "sys_ck",
+ "ref_ck",
  "wakeup_deb_p0",
  "wakeup_deb_p1";
mediatek,syscon-wakeup = <>;
@@ -746,8 +748,8 @@
reg-names = "mac";
interrupts = ;
power-domains = < 
MT8173_POWER_DOMAIN_USB>;
-   clocks = < CLK_TOP_USB30_SEL>;
-   clock-names = "sys_ck";
+   clocks = < CLK_TOP_USB30_SEL>, 
<>;
+   clock-names = "sys_ck", "ref_ck";
status = "disabled";
};
};
-- 
1.7.9.5

[PATCH -next 3/3] usb: xhci-mtk: make the reference clock optional

[Chunfeng Yun]

Make the reference clock optional for DTS backward compatibility
and ignore the error if it does not exist.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/host/xhci-mtk.c |   11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 4d75ac5..75bae8e 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -559,10 +559,17 @@ static int xhci_mtk_probe(struct platform_device *pdev)
return PTR_ERR(mtk->sys_clk);
}
 
+   /*
+* reference clock is usually a "fixed-clock", make it optional
+* for backward compatibility and ignore the error if it does
+* not exist.
+*/
mtk->ref_clk = devm_clk_get(dev, "ref_ck");
if (IS_ERR(mtk->ref_clk)) {
-   dev_err(dev, "fail to get ref_ck\n");
-   return PTR_ERR(mtk->ref_clk);
+   if (PTR_ERR(mtk->ref_clk) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+
+   mtk->ref_clk = NULL;
}
 
mtk->lpm_support = of_property_read_bool(node, "usb3-lpm-capable");
-- 
1.7.9.5

[PATCH -next 2/3] usb: mtu3: make the reference clock optional

[Chunfeng Yun]

Make the reference clock optional for DTS backward compatibility
and ignore the error if it does not exist.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/mtu3/mtu3_plat.c |   11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index 19a345d..c3125da 100644
--- a/drivers/usb/mtu3/mtu3_plat.c
+++ b/drivers/usb/mtu3/mtu3_plat.c
@@ -225,10 +225,17 @@ static int get_ssusb_rscs(struct platform_device *pdev, 
struct ssusb_mtk *ssusb)
return PTR_ERR(ssusb->sys_clk);
}
 
+   /*
+* reference clock is usually a "fixed-clock", make it optional
+* for backward compatibility and ignore the error if it does
+* not exist.
+*/
ssusb->ref_clk = devm_clk_get(dev, "ref_ck");
if (IS_ERR(ssusb->ref_clk)) {
-   dev_err(dev, "failed to get ref clock\n");
-   return PTR_ERR(ssusb->ref_clk);
+   if (PTR_ERR(ssusb->ref_clk) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+
+   ssusb->ref_clk = NULL;
}
 
ssusb->num_phys = of_count_phandle_with_args(node,
-- 
1.7.9.5

[PATCH -next 3/3] usb: xhci-mtk: make the reference clock optional

[Chunfeng Yun]

Make the reference clock optional for DTS backward compatibility
and ignore the error if it does not exist.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/host/xhci-mtk.c |   11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 4d75ac5..75bae8e 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -559,10 +559,17 @@ static int xhci_mtk_probe(struct platform_device *pdev)
return PTR_ERR(mtk->sys_clk);
}
 
+   /*
+* reference clock is usually a "fixed-clock", make it optional
+* for backward compatibility and ignore the error if it does
+* not exist.
+*/
mtk->ref_clk = devm_clk_get(dev, "ref_ck");
if (IS_ERR(mtk->ref_clk)) {
-   dev_err(dev, "fail to get ref_ck\n");
-   return PTR_ERR(mtk->ref_clk);
+   if (PTR_ERR(mtk->ref_clk) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+
+   mtk->ref_clk = NULL;
}
 
mtk->lpm_support = of_property_read_bool(node, "usb3-lpm-capable");
-- 
1.7.9.5

[PATCH -next 2/3] usb: mtu3: make the reference clock optional

[Chunfeng Yun]

Make the reference clock optional for DTS backward compatibility
and ignore the error if it does not exist.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/mtu3/mtu3_plat.c |   11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index 19a345d..c3125da 100644
--- a/drivers/usb/mtu3/mtu3_plat.c
+++ b/drivers/usb/mtu3/mtu3_plat.c
@@ -225,10 +225,17 @@ static int get_ssusb_rscs(struct platform_device *pdev, 
struct ssusb_mtk *ssusb)
return PTR_ERR(ssusb->sys_clk);
}
 
+   /*
+* reference clock is usually a "fixed-clock", make it optional
+* for backward compatibility and ignore the error if it does
+* not exist.
+*/
ssusb->ref_clk = devm_clk_get(dev, "ref_ck");
if (IS_ERR(ssusb->ref_clk)) {
-   dev_err(dev, "failed to get ref clock\n");
-   return PTR_ERR(ssusb->ref_clk);
+   if (PTR_ERR(ssusb->ref_clk) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+
+   ssusb->ref_clk = NULL;
}
 
ssusb->num_phys = of_count_phandle_with_args(node,
-- 
1.7.9.5

[PATCH 3/4] drm/rockchip: gem: add mutex lock for drm mm

[Mark Yao]

drm_mm_insert_node_generic and drm_mm_remove_node may access same
resource with list ops, it's not threads safe, so protect this context
with mutex lock.

Fix bug:
[49451.856244] 
==
[49451.856350] BUG: KASAN: wild-memory-access on address dead0108
[49451.856379] Write of size 8 by task Binder:218_4/683
[49451.856417] CPU: 2 PID: 683 Comm: Binder:218_4 Not tainted 4.4.36 #62
[49451.856443] Hardware name: Rockchip RK3399 Excavator Board edp (Android) (DT)
[49451.856469] Call trace:
[49451.856519] [] dump_backtrace+0x0/0x230
[49451.856556] [] show_stack+0x14/0x1c
[49451.856592] [] dump_stack+0xa0/0xc8
[49451.856633] [] kasan_report+0x110/0x4dc
[49451.856670] [] __asan_store8+0x24/0x7c
[49451.856715] [] drm_mm_insert_node_generic+0x2dc/0x464
[49451.856760] [] rockchip_gem_iommu_map+0x60/0x158
[49451.856794] [] rockchip_gem_create_object+0x278/0x488
[49451.856827] [] rockchip_gem_create_with_handle+0x24/0x10c
[49451.856862] [] rockchip_gem_create_ioctl+0x3c/0x50
[49451.856896] [] drm_ioctl+0x354/0x52c
[49451.856939] [] do_vfs_ioctl+0x670/0x78c
[49451.856976] [] SyS_ioctl+0x60/0x88
[49451.857009] [] el0_svc_naked+0x24/0x28

Change-Id: I2ea377aa9ca24f70c59e2d86f2a6ad5ccb9c0891
Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 2 ++
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 9 +
 3 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 7a610e9..b360e62 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -146,6 +146,7 @@ static int rockchip_drm_init_iommu(struct drm_device 
*drm_dev)
DRM_DEBUG("IOMMU context initialized (aperture: %#llx-%#llx)\n",
  start, end);
drm_mm_init(>mm, start, end - start + 1);
+   mutex_init(>mm_lock);
 
return 0;
 }
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 7c123d9..adc3930 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -62,6 +62,8 @@ struct rockchip_drm_private {
const struct rockchip_crtc_funcs *crtc_funcs[ROCKCHIP_MAX_CRTC];
struct drm_atomic_state *state;
struct iommu_domain *domain;
+   /* protect drm_mm on multi-threads */
+   struct mutex mm_lock;
struct drm_mm mm;
struct list_head psr_list;
spinlock_t psr_list_lock;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 5209392..8d27965 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -28,9 +28,13 @@ static int rockchip_gem_iommu_map(struct rockchip_gem_object 
*rk_obj)
int prot = IOMMU_READ | IOMMU_WRITE;
ssize_t ret;
 
+   mutex_lock(>mm_lock);
+
ret = drm_mm_insert_node_generic(>mm, _obj->mm,
 rk_obj->base.size, PAGE_SIZE,
 0, 0);
+
+   mutex_unlock(>mm_lock);
if (ret < 0) {
DRM_ERROR("out of I/O virtual memory: %zd\n", ret);
return ret;
@@ -61,8 +65,13 @@ static int rockchip_gem_iommu_unmap(struct 
rockchip_gem_object *rk_obj)
struct rockchip_drm_private *private = drm->dev_private;
 
iommu_unmap(private->domain, rk_obj->dma_addr, rk_obj->size);
+
+   mutex_lock(>mm_lock);
+
drm_mm_remove_node(_obj->mm);
 
+   mutex_unlock(>mm_lock);
+
return 0;
 }
 
-- 
1.9.1

[PATCH 1/4] drm/rockchip: Do not use DMA mapping API if attached to IOMMU domain

[Mark Yao]

From: Tomasz Figa 

The API is not suitable for subsystems consisting of multiple devices
and requires severe hacks to use it. To mitigate this, this patch
implements allocation and address space management locally by using
helpers provided by DRM framework, like other DRM drivers do, e.g.
Tegra.

This patch should not introduce any functional changes until the driver
is made to attach subdevices into an IOMMU domain with the generic IOMMU
API, which will happen in following patch. Based heavily on GEM
implementation of Tegra DRM driver.

Signed-off-by: Tomasz Figa 
Signed-off-by: Shunqian Zheng 
Acked-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   4 +-
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 217 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h |   8 +
 3 files changed, 219 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index fb6226c..7c123d9 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -30,6 +30,7 @@
 
 struct drm_device;
 struct drm_connector;
+struct iommu_domain;
 
 /*
  * Rockchip drm private crtc funcs.
@@ -60,7 +61,8 @@ struct rockchip_drm_private {
struct drm_gem_object *fbdev_bo;
const struct rockchip_crtc_funcs *crtc_funcs[ROCKCHIP_MAX_CRTC];
struct drm_atomic_state *state;
-
+   struct iommu_domain *domain;
+   struct drm_mm mm;
struct list_head psr_list;
spinlock_t psr_list_lock;
 };
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index b70f942..5209392 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -16,11 +16,135 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "rockchip_drm_drv.h"
 #include "rockchip_drm_gem.h"
 
-static int rockchip_gem_alloc_buf(struct rockchip_gem_object *rk_obj,
+static int rockchip_gem_iommu_map(struct rockchip_gem_object *rk_obj)
+{
+   struct drm_device *drm = rk_obj->base.dev;
+   struct rockchip_drm_private *private = drm->dev_private;
+   int prot = IOMMU_READ | IOMMU_WRITE;
+   ssize_t ret;
+
+   ret = drm_mm_insert_node_generic(>mm, _obj->mm,
+rk_obj->base.size, PAGE_SIZE,
+0, 0);
+   if (ret < 0) {
+   DRM_ERROR("out of I/O virtual memory: %zd\n", ret);
+   return ret;
+   }
+
+   rk_obj->dma_addr = rk_obj->mm.start;
+
+   ret = iommu_map_sg(private->domain, rk_obj->dma_addr, rk_obj->sgt->sgl,
+  rk_obj->sgt->nents, prot);
+   if (ret < 0) {
+   DRM_ERROR("failed to map buffer: %zd\n", ret);
+   goto err_remove_node;
+   }
+
+   rk_obj->size = ret;
+
+   return 0;
+
+err_remove_node:
+   drm_mm_remove_node(_obj->mm);
+
+   return ret;
+}
+
+static int rockchip_gem_iommu_unmap(struct rockchip_gem_object *rk_obj)
+{
+   struct drm_device *drm = rk_obj->base.dev;
+   struct rockchip_drm_private *private = drm->dev_private;
+
+   iommu_unmap(private->domain, rk_obj->dma_addr, rk_obj->size);
+   drm_mm_remove_node(_obj->mm);
+
+   return 0;
+}
+
+static int rockchip_gem_get_pages(struct rockchip_gem_object *rk_obj)
+{
+   struct drm_device *drm = rk_obj->base.dev;
+   int ret, i;
+   struct scatterlist *s;
+
+   rk_obj->pages = drm_gem_get_pages(_obj->base);
+   if (IS_ERR(rk_obj->pages))
+   return PTR_ERR(rk_obj->pages);
+
+   rk_obj->num_pages = rk_obj->base.size >> PAGE_SHIFT;
+
+   rk_obj->sgt = drm_prime_pages_to_sg(rk_obj->pages, rk_obj->num_pages);
+   if (IS_ERR(rk_obj->sgt)) {
+   ret = PTR_ERR(rk_obj->sgt);
+   goto err_put_pages;
+   }
+
+   /*
+* Fake up the SG table so that dma_sync_sg_for_device() can be used
+* to flush the pages associated with it.
+*
+* TODO: Replace this by drm_clflush_sg() once it can be implemented
+* without relying on symbols that are not exported.
+*/
+   for_each_sg(rk_obj->sgt->sgl, s, rk_obj->sgt->nents, i)
+   sg_dma_address(s) = sg_phys(s);
+
+   dma_sync_sg_for_device(drm->dev, rk_obj->sgt->sgl, rk_obj->sgt->nents,
+  DMA_TO_DEVICE);
+
+   return 0;
+
+err_put_pages:
+   drm_gem_put_pages(_obj->base, rk_obj->pages, false, false);
+   return ret;
+}
+
+static void rockchip_gem_put_pages(struct rockchip_gem_object *rk_obj)
+{
+   sg_free_table(rk_obj->sgt);
+   kfree(rk_obj->sgt);
+   drm_gem_put_pages(_obj->base, rk_obj->pages, false, false);
+}
+
+static int rockchip_gem_alloc_iommu(struct rockchip_gem_object *rk_obj,
+

[PATCH 2/4] drm/rockchip: Use common IOMMU API to attach devices

[Mark Yao]

From: Shunqian Zheng 

Rockchip DRM used the arm special API, arm_iommu_*(), to attach
iommu for ARM32 SoCs. This patch convert to common iommu API
so it would support ARM64 like RK3399.

Since previous patch added support for direct IOMMU address space
management, there is no need to use DMA API anymore and this patch wires
things to use the new method.

Signed-off-by: Shunqian Zheng 
Signed-off-by: Tomasz Figa 
Acked-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 100 +++-
 1 file changed, 53 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index c30d649..7a610e9 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -14,19 +14,19 @@
  * GNU General Public License for more details.
  */
 
-#include 
-
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include "rockchip_drm_drv.h"
 #include "rockchip_drm_fb.h"
@@ -50,28 +50,31 @@
 int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
   struct device *dev)
 {
-   struct dma_iommu_mapping *mapping = drm_dev->dev->archdata.mapping;
+   struct rockchip_drm_private *private = drm_dev->dev_private;
int ret;
 
if (!is_support_iommu)
return 0;
 
-   ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
-   if (ret)
+   ret = iommu_attach_device(private->domain, dev);
+   if (ret) {
+   dev_err(dev, "Failed to attach iommu device\n");
return ret;
+   }
 
-   dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
-
-   return arm_iommu_attach_device(dev, mapping);
+   return 0;
 }
 
 void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
struct device *dev)
 {
+   struct rockchip_drm_private *private = drm_dev->dev_private;
+   struct iommu_domain *domain = private->domain;
+
if (!is_support_iommu)
return;
 
-   arm_iommu_detach_device(dev);
+   iommu_detach_device(domain, dev);
 }
 
 int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
@@ -123,11 +126,45 @@ static void rockchip_drm_crtc_disable_vblank(struct 
drm_device *dev,
priv->crtc_funcs[pipe]->disable_vblank(crtc);
 }
 
+static int rockchip_drm_init_iommu(struct drm_device *drm_dev)
+{
+   struct rockchip_drm_private *private = drm_dev->dev_private;
+   struct iommu_domain_geometry *geometry;
+   u64 start, end;
+
+   if (!is_support_iommu)
+   return 0;
+
+   private->domain = iommu_domain_alloc(_bus_type);
+   if (!private->domain)
+   return -ENOMEM;
+
+   geometry = >domain->geometry;
+   start = geometry->aperture_start;
+   end = geometry->aperture_end;
+
+   DRM_DEBUG("IOMMU context initialized (aperture: %#llx-%#llx)\n",
+ start, end);
+   drm_mm_init(>mm, start, end - start + 1);
+
+   return 0;
+}
+
+static void rockchip_iommu_cleanup(struct drm_device *drm_dev)
+{
+   struct rockchip_drm_private *private = drm_dev->dev_private;
+
+   if (!is_support_iommu)
+   return;
+
+   drm_mm_takedown(>mm);
+   iommu_domain_free(private->domain);
+}
+
 static int rockchip_drm_bind(struct device *dev)
 {
struct drm_device *drm_dev;
struct rockchip_drm_private *private;
-   struct dma_iommu_mapping *mapping = NULL;
int ret;
 
drm_dev = drm_dev_alloc(_drm_driver, dev);
@@ -151,38 +188,14 @@ static int rockchip_drm_bind(struct device *dev)
 
rockchip_drm_mode_config_init(drm_dev);
 
-   dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
- GFP_KERNEL);
-   if (!dev->dma_parms) {
-   ret = -ENOMEM;
+   ret = rockchip_drm_init_iommu(drm_dev);
+   if (ret)
goto err_config_cleanup;
-   }
-
-   if (is_support_iommu) {
-   /* TODO(djkurtz): fetch the mapping start/size from somewhere */
-   mapping = arm_iommu_create_mapping(_bus_type,
-  0x,
-  SZ_2G);
-   if (IS_ERR(mapping)) {
-   ret = PTR_ERR(mapping);
-   goto err_config_cleanup;
-   }
-
-   ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
-   if (ret)
-   goto err_release_mapping;
-
-   dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
-
-   ret = arm_iommu_attach_device(dev, mapping);
-   if (ret)
-   goto err_release_mapping;

[PATCH 3/4] drm/rockchip: gem: add mutex lock for drm mm

[Mark Yao]

drm_mm_insert_node_generic and drm_mm_remove_node may access same
resource with list ops, it's not threads safe, so protect this context
with mutex lock.

Fix bug:
[49451.856244] 
==
[49451.856350] BUG: KASAN: wild-memory-access on address dead0108
[49451.856379] Write of size 8 by task Binder:218_4/683
[49451.856417] CPU: 2 PID: 683 Comm: Binder:218_4 Not tainted 4.4.36 #62
[49451.856443] Hardware name: Rockchip RK3399 Excavator Board edp (Android) (DT)
[49451.856469] Call trace:
[49451.856519] [] dump_backtrace+0x0/0x230
[49451.856556] [] show_stack+0x14/0x1c
[49451.856592] [] dump_stack+0xa0/0xc8
[49451.856633] [] kasan_report+0x110/0x4dc
[49451.856670] [] __asan_store8+0x24/0x7c
[49451.856715] [] drm_mm_insert_node_generic+0x2dc/0x464
[49451.856760] [] rockchip_gem_iommu_map+0x60/0x158
[49451.856794] [] rockchip_gem_create_object+0x278/0x488
[49451.856827] [] rockchip_gem_create_with_handle+0x24/0x10c
[49451.856862] [] rockchip_gem_create_ioctl+0x3c/0x50
[49451.856896] [] drm_ioctl+0x354/0x52c
[49451.856939] [] do_vfs_ioctl+0x670/0x78c
[49451.856976] [] SyS_ioctl+0x60/0x88
[49451.857009] [] el0_svc_naked+0x24/0x28

Change-Id: I2ea377aa9ca24f70c59e2d86f2a6ad5ccb9c0891
Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 2 ++
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 9 +
 3 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 7a610e9..b360e62 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -146,6 +146,7 @@ static int rockchip_drm_init_iommu(struct drm_device 
*drm_dev)
DRM_DEBUG("IOMMU context initialized (aperture: %#llx-%#llx)\n",
  start, end);
drm_mm_init(>mm, start, end - start + 1);
+   mutex_init(>mm_lock);
 
return 0;
 }
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 7c123d9..adc3930 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -62,6 +62,8 @@ struct rockchip_drm_private {
const struct rockchip_crtc_funcs *crtc_funcs[ROCKCHIP_MAX_CRTC];
struct drm_atomic_state *state;
struct iommu_domain *domain;
+   /* protect drm_mm on multi-threads */
+   struct mutex mm_lock;
struct drm_mm mm;
struct list_head psr_list;
spinlock_t psr_list_lock;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 5209392..8d27965 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -28,9 +28,13 @@ static int rockchip_gem_iommu_map(struct rockchip_gem_object 
*rk_obj)
int prot = IOMMU_READ | IOMMU_WRITE;
ssize_t ret;
 
+   mutex_lock(>mm_lock);
+
ret = drm_mm_insert_node_generic(>mm, _obj->mm,
 rk_obj->base.size, PAGE_SIZE,
 0, 0);
+
+   mutex_unlock(>mm_lock);
if (ret < 0) {
DRM_ERROR("out of I/O virtual memory: %zd\n", ret);
return ret;
@@ -61,8 +65,13 @@ static int rockchip_gem_iommu_unmap(struct 
rockchip_gem_object *rk_obj)
struct rockchip_drm_private *private = drm->dev_private;
 
iommu_unmap(private->domain, rk_obj->dma_addr, rk_obj->size);
+
+   mutex_lock(>mm_lock);
+
drm_mm_remove_node(_obj->mm);
 
+   mutex_unlock(>mm_lock);
+
return 0;
 }
 
-- 
1.9.1

[PATCH 1/4] drm/rockchip: Do not use DMA mapping API if attached to IOMMU domain

[Mark Yao]

From: Tomasz Figa 

The API is not suitable for subsystems consisting of multiple devices
and requires severe hacks to use it. To mitigate this, this patch
implements allocation and address space management locally by using
helpers provided by DRM framework, like other DRM drivers do, e.g.
Tegra.

This patch should not introduce any functional changes until the driver
is made to attach subdevices into an IOMMU domain with the generic IOMMU
API, which will happen in following patch. Based heavily on GEM
implementation of Tegra DRM driver.

Signed-off-by: Tomasz Figa 
Signed-off-by: Shunqian Zheng 
Acked-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   4 +-
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 217 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h |   8 +
 3 files changed, 219 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index fb6226c..7c123d9 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -30,6 +30,7 @@
 
 struct drm_device;
 struct drm_connector;
+struct iommu_domain;
 
 /*
  * Rockchip drm private crtc funcs.
@@ -60,7 +61,8 @@ struct rockchip_drm_private {
struct drm_gem_object *fbdev_bo;
const struct rockchip_crtc_funcs *crtc_funcs[ROCKCHIP_MAX_CRTC];
struct drm_atomic_state *state;
-
+   struct iommu_domain *domain;
+   struct drm_mm mm;
struct list_head psr_list;
spinlock_t psr_list_lock;
 };
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index b70f942..5209392 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -16,11 +16,135 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "rockchip_drm_drv.h"
 #include "rockchip_drm_gem.h"
 
-static int rockchip_gem_alloc_buf(struct rockchip_gem_object *rk_obj,
+static int rockchip_gem_iommu_map(struct rockchip_gem_object *rk_obj)
+{
+   struct drm_device *drm = rk_obj->base.dev;
+   struct rockchip_drm_private *private = drm->dev_private;
+   int prot = IOMMU_READ | IOMMU_WRITE;
+   ssize_t ret;
+
+   ret = drm_mm_insert_node_generic(>mm, _obj->mm,
+rk_obj->base.size, PAGE_SIZE,
+0, 0);
+   if (ret < 0) {
+   DRM_ERROR("out of I/O virtual memory: %zd\n", ret);
+   return ret;
+   }
+
+   rk_obj->dma_addr = rk_obj->mm.start;
+
+   ret = iommu_map_sg(private->domain, rk_obj->dma_addr, rk_obj->sgt->sgl,
+  rk_obj->sgt->nents, prot);
+   if (ret < 0) {
+   DRM_ERROR("failed to map buffer: %zd\n", ret);
+   goto err_remove_node;
+   }
+
+   rk_obj->size = ret;
+
+   return 0;
+
+err_remove_node:
+   drm_mm_remove_node(_obj->mm);
+
+   return ret;
+}
+
+static int rockchip_gem_iommu_unmap(struct rockchip_gem_object *rk_obj)
+{
+   struct drm_device *drm = rk_obj->base.dev;
+   struct rockchip_drm_private *private = drm->dev_private;
+
+   iommu_unmap(private->domain, rk_obj->dma_addr, rk_obj->size);
+   drm_mm_remove_node(_obj->mm);
+
+   return 0;
+}
+
+static int rockchip_gem_get_pages(struct rockchip_gem_object *rk_obj)
+{
+   struct drm_device *drm = rk_obj->base.dev;
+   int ret, i;
+   struct scatterlist *s;
+
+   rk_obj->pages = drm_gem_get_pages(_obj->base);
+   if (IS_ERR(rk_obj->pages))
+   return PTR_ERR(rk_obj->pages);
+
+   rk_obj->num_pages = rk_obj->base.size >> PAGE_SHIFT;
+
+   rk_obj->sgt = drm_prime_pages_to_sg(rk_obj->pages, rk_obj->num_pages);
+   if (IS_ERR(rk_obj->sgt)) {
+   ret = PTR_ERR(rk_obj->sgt);
+   goto err_put_pages;
+   }
+
+   /*
+* Fake up the SG table so that dma_sync_sg_for_device() can be used
+* to flush the pages associated with it.
+*
+* TODO: Replace this by drm_clflush_sg() once it can be implemented
+* without relying on symbols that are not exported.
+*/
+   for_each_sg(rk_obj->sgt->sgl, s, rk_obj->sgt->nents, i)
+   sg_dma_address(s) = sg_phys(s);
+
+   dma_sync_sg_for_device(drm->dev, rk_obj->sgt->sgl, rk_obj->sgt->nents,
+  DMA_TO_DEVICE);
+
+   return 0;
+
+err_put_pages:
+   drm_gem_put_pages(_obj->base, rk_obj->pages, false, false);
+   return ret;
+}
+
+static void rockchip_gem_put_pages(struct rockchip_gem_object *rk_obj)
+{
+   sg_free_table(rk_obj->sgt);
+   kfree(rk_obj->sgt);
+   drm_gem_put_pages(_obj->base, rk_obj->pages, false, false);
+}
+
+static int rockchip_gem_alloc_iommu(struct rockchip_gem_object *rk_obj,
+   bool alloc_kmap)
+{
+   int ret;
+
+   ret = 

[PATCH 2/4] drm/rockchip: Use common IOMMU API to attach devices

[Mark Yao]

From: Shunqian Zheng 

Rockchip DRM used the arm special API, arm_iommu_*(), to attach
iommu for ARM32 SoCs. This patch convert to common iommu API
so it would support ARM64 like RK3399.

Since previous patch added support for direct IOMMU address space
management, there is no need to use DMA API anymore and this patch wires
things to use the new method.

Signed-off-by: Shunqian Zheng 
Signed-off-by: Tomasz Figa 
Acked-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 100 +++-
 1 file changed, 53 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index c30d649..7a610e9 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -14,19 +14,19 @@
  * GNU General Public License for more details.
  */
 
-#include 
-
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include "rockchip_drm_drv.h"
 #include "rockchip_drm_fb.h"
@@ -50,28 +50,31 @@
 int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
   struct device *dev)
 {
-   struct dma_iommu_mapping *mapping = drm_dev->dev->archdata.mapping;
+   struct rockchip_drm_private *private = drm_dev->dev_private;
int ret;
 
if (!is_support_iommu)
return 0;
 
-   ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
-   if (ret)
+   ret = iommu_attach_device(private->domain, dev);
+   if (ret) {
+   dev_err(dev, "Failed to attach iommu device\n");
return ret;
+   }
 
-   dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
-
-   return arm_iommu_attach_device(dev, mapping);
+   return 0;
 }
 
 void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
struct device *dev)
 {
+   struct rockchip_drm_private *private = drm_dev->dev_private;
+   struct iommu_domain *domain = private->domain;
+
if (!is_support_iommu)
return;
 
-   arm_iommu_detach_device(dev);
+   iommu_detach_device(domain, dev);
 }
 
 int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
@@ -123,11 +126,45 @@ static void rockchip_drm_crtc_disable_vblank(struct 
drm_device *dev,
priv->crtc_funcs[pipe]->disable_vblank(crtc);
 }
 
+static int rockchip_drm_init_iommu(struct drm_device *drm_dev)
+{
+   struct rockchip_drm_private *private = drm_dev->dev_private;
+   struct iommu_domain_geometry *geometry;
+   u64 start, end;
+
+   if (!is_support_iommu)
+   return 0;
+
+   private->domain = iommu_domain_alloc(_bus_type);
+   if (!private->domain)
+   return -ENOMEM;
+
+   geometry = >domain->geometry;
+   start = geometry->aperture_start;
+   end = geometry->aperture_end;
+
+   DRM_DEBUG("IOMMU context initialized (aperture: %#llx-%#llx)\n",
+ start, end);
+   drm_mm_init(>mm, start, end - start + 1);
+
+   return 0;
+}
+
+static void rockchip_iommu_cleanup(struct drm_device *drm_dev)
+{
+   struct rockchip_drm_private *private = drm_dev->dev_private;
+
+   if (!is_support_iommu)
+   return;
+
+   drm_mm_takedown(>mm);
+   iommu_domain_free(private->domain);
+}
+
 static int rockchip_drm_bind(struct device *dev)
 {
struct drm_device *drm_dev;
struct rockchip_drm_private *private;
-   struct dma_iommu_mapping *mapping = NULL;
int ret;
 
drm_dev = drm_dev_alloc(_drm_driver, dev);
@@ -151,38 +188,14 @@ static int rockchip_drm_bind(struct device *dev)
 
rockchip_drm_mode_config_init(drm_dev);
 
-   dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
- GFP_KERNEL);
-   if (!dev->dma_parms) {
-   ret = -ENOMEM;
+   ret = rockchip_drm_init_iommu(drm_dev);
+   if (ret)
goto err_config_cleanup;
-   }
-
-   if (is_support_iommu) {
-   /* TODO(djkurtz): fetch the mapping start/size from somewhere */
-   mapping = arm_iommu_create_mapping(_bus_type,
-  0x,
-  SZ_2G);
-   if (IS_ERR(mapping)) {
-   ret = PTR_ERR(mapping);
-   goto err_config_cleanup;
-   }
-
-   ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
-   if (ret)
-   goto err_release_mapping;
-
-   dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
-
-   ret = arm_iommu_attach_device(dev, mapping);
-   if (ret)
-   goto err_release_mapping;
-   }
 
/* Try to bind all sub drivers. */
ret = component_bind_all(dev, 

[PATCH 0/4] drm/rockchip: switch to drm_mm for support arm64 iommu

[Mark Yao]

Some iommu patches on the series[0] "iommu/rockchip: Fix bugs and
enable on ARM64" already landed, So drm/rockchip related patches [1] and [2]
ready to landed, this series just rebase them to lastest drm-next.

And fix some bugs for drm/rockchip drm_mm

[0]: http://www.spinics.net/lists/arm-kernel/msg513781.html
[1]: https://patchwork.kernel.org/patch/9196367
[2]: https://patchwork.kernel.org/patch/9196369

Mark Yao (2):
  drm/rockchip: gem: add mutex lock for drm mm
  drm/rockchip: gem: fixup iommu_map_sg error path

Shunqian Zheng (1):
  drm/rockchip: Use common IOMMU API to attach devices

Tomasz Figa (1):
  drm/rockchip: Do not use DMA mapping API if attached to IOMMU domain

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 101 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   6 +-
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 228 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h |   8 +
 4 files changed, 286 insertions(+), 57 deletions(-)

-- 
1.9.1

[PATCH 0/4] drm/rockchip: switch to drm_mm for support arm64 iommu

[Mark Yao]

Some iommu patches on the series[0] "iommu/rockchip: Fix bugs and
enable on ARM64" already landed, So drm/rockchip related patches [1] and [2]
ready to landed, this series just rebase them to lastest drm-next.

And fix some bugs for drm/rockchip drm_mm

[0]: http://www.spinics.net/lists/arm-kernel/msg513781.html
[1]: https://patchwork.kernel.org/patch/9196367
[2]: https://patchwork.kernel.org/patch/9196369

Mark Yao (2):
  drm/rockchip: gem: add mutex lock for drm mm
  drm/rockchip: gem: fixup iommu_map_sg error path

Shunqian Zheng (1):
  drm/rockchip: Use common IOMMU API to attach devices

Tomasz Figa (1):
  drm/rockchip: Do not use DMA mapping API if attached to IOMMU domain

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 101 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   6 +-
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 228 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h |   8 +
 4 files changed, 286 insertions(+), 57 deletions(-)

-- 
1.9.1

[PATCH 4/4] drm/rockchip: gem: fixup iommu_map_sg error path

[Mark Yao]

The return value of iommu_map_sg is size_t, it's unsigned,
So check ret < 0 is wrong.

And if iommu_map_sg is error, it's return value is zero, but
rockchip_gem_iommu_map feel the zero return value is success,
bug happen:

[5.227458] [drm:rockchip_gem_iommu_map] *ERROR* failed to map buffer: 0
[   12.291590] WARNING: at drivers/gpu/drm/drm_mm.c:369
[   12.291611] Modules linked in:
[   12.291634]
[   12.291658] CPU: 4 PID: 338 Comm: cameraserver Not tainted 4.4.41 #196
[   12.291680] Hardware name: rockchip,rk3399-mid (DT)
[   12.291703] task: ffc0e5a23100 ti: ffc0e5a64000 task.ti: 
ffc0e5a64000
[   12.291739] PC is at drm_mm_remove_node+0xc/0xf8
[   12.291766] LR is at rockchip_gem_iommu_unmap+0x3c/0x54
[   12.303799] [] drm_mm_remove_node+0xc/0xf8
[   12.303827] [] rockchip_gem_free_object+0x98/0x168
[   12.303854] [] drm_gem_object_free+0x2c/0x34
[   12.303878] [] drm_gem_dmabuf_release+0x90/0xa4
[   12.303904] [] dma_buf_release+0x64/0x15c
[   12.303929] [] __fput+0xe0/0x1a4
[   12.303950] [] fput+0xc/0x14
[   12.303977] [] task_work_run+0xa0/0xc0
[   12.304004] [] do_notify_resume+0x40/0x54
[   12.304026] [] work_pending+0x10/0x14

Change-Id: Id79c052691270553c1c60086f9926f39a5296354
Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 8d27965..cc48673 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -44,8 +44,10 @@ static int rockchip_gem_iommu_map(struct rockchip_gem_object 
*rk_obj)
 
ret = iommu_map_sg(private->domain, rk_obj->dma_addr, rk_obj->sgt->sgl,
   rk_obj->sgt->nents, prot);
-   if (ret < 0) {
-   DRM_ERROR("failed to map buffer: %zd\n", ret);
+   if (ret < rk_obj->base.size) {
+   DRM_ERROR("failed to map buffer: size=%zd request_size=%zd\n",
+ ret, rk_obj->base.size);
+   ret = -ENOMEM;
goto err_remove_node;
}
 
-- 
1.9.1

[PATCH 4/4] drm/rockchip: gem: fixup iommu_map_sg error path

[Mark Yao]

The return value of iommu_map_sg is size_t, it's unsigned,
So check ret < 0 is wrong.

And if iommu_map_sg is error, it's return value is zero, but
rockchip_gem_iommu_map feel the zero return value is success,
bug happen:

[5.227458] [drm:rockchip_gem_iommu_map] *ERROR* failed to map buffer: 0
[   12.291590] WARNING: at drivers/gpu/drm/drm_mm.c:369
[   12.291611] Modules linked in:
[   12.291634]
[   12.291658] CPU: 4 PID: 338 Comm: cameraserver Not tainted 4.4.41 #196
[   12.291680] Hardware name: rockchip,rk3399-mid (DT)
[   12.291703] task: ffc0e5a23100 ti: ffc0e5a64000 task.ti: 
ffc0e5a64000
[   12.291739] PC is at drm_mm_remove_node+0xc/0xf8
[   12.291766] LR is at rockchip_gem_iommu_unmap+0x3c/0x54
[   12.303799] [] drm_mm_remove_node+0xc/0xf8
[   12.303827] [] rockchip_gem_free_object+0x98/0x168
[   12.303854] [] drm_gem_object_free+0x2c/0x34
[   12.303878] [] drm_gem_dmabuf_release+0x90/0xa4
[   12.303904] [] dma_buf_release+0x64/0x15c
[   12.303929] [] __fput+0xe0/0x1a4
[   12.303950] [] fput+0xc/0x14
[   12.303977] [] task_work_run+0xa0/0xc0
[   12.304004] [] do_notify_resume+0x40/0x54
[   12.304026] [] work_pending+0x10/0x14

Change-Id: Id79c052691270553c1c60086f9926f39a5296354
Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 8d27965..cc48673 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -44,8 +44,10 @@ static int rockchip_gem_iommu_map(struct rockchip_gem_object 
*rk_obj)
 
ret = iommu_map_sg(private->domain, rk_obj->dma_addr, rk_obj->sgt->sgl,
   rk_obj->sgt->nents, prot);
-   if (ret < 0) {
-   DRM_ERROR("failed to map buffer: %zd\n", ret);
+   if (ret < rk_obj->base.size) {
+   DRM_ERROR("failed to map buffer: size=%zd request_size=%zd\n",
+ ret, rk_obj->base.size);
+   ret = -ENOMEM;
goto err_remove_node;
}
 
-- 
1.9.1

Re: [PATCH v2 6/6] dt-bindings: mt8173-mtu3: add reference clock

[Chunfeng Yun]

Please ignore this series of patches, due to the first version have been
merged into usb-next branch except DTS's one[PACH 4/6].
This will cause mtu3 probe failure, so I will send new patches based on
usb-next branch.

sorry

On Mon, 2017-02-06 at 17:29 +0800, Chunfeng Yun wrote:
> Due to the reference clock comes from 26M oscillator directly
> on mt8173, and it is a fixed-clock in DTS which always turned
> on, we ignore it before. But on some platforms, it comes
> from PLL, and need be controlled, so here add it, no matter
> it is a fixed-clock or not.
> 
> Signed-off-by: Chunfeng Yun 
> ---
>  .../devicetree/bindings/usb/mt8173-mtu3.txt|   10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt 
> b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> index e049d19..8c976cd 100644
> --- a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> +++ b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> @@ -10,7 +10,7 @@ Required properties:
>   - vusb33-supply : regulator of USB avdd3.3v
>   - clocks : a list of phandle + clock-specifier pairs, one for each
>   entry in clock-names
> - - clock-names : must contain "sys_ck" for clock of controller;
> + - clock-names : must contain "sys_ck" and "ref_ck" for clock of controller;
>   "wakeup_deb_p0" and "wakeup_deb_p1" are optional, they are
>   depends on "mediatek,enable-wakeup"
>   - phys : a list of phandle + phy specifier pairs
> @@ -56,10 +56,10 @@ ssusb: usb@11271000 {
>   phys = <_port0 PHY_TYPE_USB3>,
>  <_port1 PHY_TYPE_USB2>;
>   power-domains = < MT8173_POWER_DOMAIN_USB>;
> - clocks = < CLK_TOP_USB30_SEL>,
> + clocks = < CLK_TOP_USB30_SEL>, <>,
>< CLK_PERI_USB0>,
>< CLK_PERI_USB1>;
> - clock-names = "sys_ck",
> + clock-names = "sys_ck", "ref_ck",
> "wakeup_deb_p0",
> "wakeup_deb_p1";
>   vusb33-supply = <_vusb_reg>;
> @@ -79,8 +79,8 @@ ssusb: usb@11271000 {
>   reg-names = "mac";
>   interrupts = ;
>   power-domains = < MT8173_POWER_DOMAIN_USB>;
> - clocks = < CLK_TOP_USB30_SEL>;
> - clock-names = "sys_ck";
> + clocks = < CLK_TOP_USB30_SEL>, <>;
> + clock-names = "sys_ck", "ref_ck";
>   vusb33-supply = <_vusb_reg>;
>   status = "disabled";
>   };

Re: [PATCH v2 6/6] dt-bindings: mt8173-mtu3: add reference clock

[Chunfeng Yun]

Please ignore this series of patches, due to the first version have been
merged into usb-next branch except DTS's one[PACH 4/6].
This will cause mtu3 probe failure, so I will send new patches based on
usb-next branch.

sorry

On Mon, 2017-02-06 at 17:29 +0800, Chunfeng Yun wrote:
> Due to the reference clock comes from 26M oscillator directly
> on mt8173, and it is a fixed-clock in DTS which always turned
> on, we ignore it before. But on some platforms, it comes
> from PLL, and need be controlled, so here add it, no matter
> it is a fixed-clock or not.
> 
> Signed-off-by: Chunfeng Yun 
> ---
>  .../devicetree/bindings/usb/mt8173-mtu3.txt|   10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt 
> b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> index e049d19..8c976cd 100644
> --- a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> +++ b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> @@ -10,7 +10,7 @@ Required properties:
>   - vusb33-supply : regulator of USB avdd3.3v
>   - clocks : a list of phandle + clock-specifier pairs, one for each
>   entry in clock-names
> - - clock-names : must contain "sys_ck" for clock of controller;
> + - clock-names : must contain "sys_ck" and "ref_ck" for clock of controller;
>   "wakeup_deb_p0" and "wakeup_deb_p1" are optional, they are
>   depends on "mediatek,enable-wakeup"
>   - phys : a list of phandle + phy specifier pairs
> @@ -56,10 +56,10 @@ ssusb: usb@11271000 {
>   phys = <_port0 PHY_TYPE_USB3>,
>  <_port1 PHY_TYPE_USB2>;
>   power-domains = < MT8173_POWER_DOMAIN_USB>;
> - clocks = < CLK_TOP_USB30_SEL>,
> + clocks = < CLK_TOP_USB30_SEL>, <>,
>< CLK_PERI_USB0>,
>< CLK_PERI_USB1>;
> - clock-names = "sys_ck",
> + clock-names = "sys_ck", "ref_ck",
> "wakeup_deb_p0",
> "wakeup_deb_p1";
>   vusb33-supply = <_vusb_reg>;
> @@ -79,8 +79,8 @@ ssusb: usb@11271000 {
>   reg-names = "mac";
>   interrupts = ;
>   power-domains = < MT8173_POWER_DOMAIN_USB>;
> - clocks = < CLK_TOP_USB30_SEL>;
> - clock-names = "sys_ck";
> + clocks = < CLK_TOP_USB30_SEL>, <>;
> + clock-names = "sys_ck", "ref_ck";
>   vusb33-supply = <_vusb_reg>;
>   status = "disabled";
>   };

Re: [PATCH 5/6] dmaengine: Add Broadcom SBA RAID driver

[Anup Patel]

On Mon, Feb 6, 2017 at 10:24 PM, Vinod Koul  wrote:
> On Mon, Feb 06, 2017 at 05:31:15PM +0530, Anup Patel wrote:
>
>> >> +
>> >> +/* SBA C_MDATA helper macros */
>> >> +#define SBA_C_MDATA_LOAD_VAL(__bnum0)((__bnum0) & 0x3)
>> >> +#define SBA_C_MDATA_WRITE_VAL(__bnum0)   ((__bnum0) & 0x3)
>> >> +#define SBA_C_MDATA_XOR_VAL(__bnum1, __bnum0)\
>> >> + ({  u32 __v = ((__bnum0) & 0x3);\
>> >> + __v |= ((__bnum1) & 0x3) << 2;  \
>> >> + __v;\
>> >> + })
>> >> +#define SBA_C_MDATA_PQ_VAL(__dnum, __bnum1, __bnum0) \
>> >> + ({  u32 __v = ((__bnum0) & 0x3);\
>> >> + __v |= ((__bnum1) & 0x3) << 2;  \
>> >> + __v |= ((__dnum) & 0x1f) << 5;  \
>> >> + __v;\
>> >> + })
>> >
>> > ah why are we usig complex macros, why can't these be simple functions..
>>
>> "static inline functions" seemed too complicated here because most of
>> these macros are two lines of c-code.
>
> and thats where I have an issue with this. Macros for simple things is fine
> but not for couple of line of logic!
>
>>
>> Do you still insist on using "static inline functions"?
>
> Yes

Sure, will use "static inline functions" instead these macros.

>
>>
>> >
>> >> +#define SBA_C_MDATA_LS(__c_mdata_val)((__c_mdata_val) & 0xff)
>> >> +#define SBA_C_MDATA_MS(__c_mdata_val)(((__c_mdata_val) >> 8) & 
>> >> 0x3)
>> >> +
>> >> +/* Driver helper macros */
>> >> +#define to_sba_request(tx)   \
>> >> + container_of(tx, struct sba_request, tx)
>> >> +#define to_sba_device(dchan) \
>> >> + container_of(dchan, struct sba_device, dma_chan)
>> >> +
>> >> +enum sba_request_state {
>> >> + SBA_REQUEST_STATE_FREE = 1,
>> >> + SBA_REQUEST_STATE_ALLOCED = 2,
>> >> + SBA_REQUEST_STATE_PENDING = 3,
>> >> + SBA_REQUEST_STATE_ACTIVE = 4,
>> >> + SBA_REQUEST_STATE_COMPLETED = 5,
>> >> + SBA_REQUEST_STATE_ABORTED = 6,
>> >
>> > whats up with a very funny indentation setting, we use 8 chars.
>> >
>> > Please re-read the Documentation/process/coding-style.rst
>>
>> I have double checked this enum. The indentation is fine
>> and as-per coding style. Am I missing anything else?
>
> Somehow the initial indent doesnt seem to be 8 chars to me.
>
>> >> +static enum dma_status sba_tx_status(struct dma_chan *dchan,
>> >> +  dma_cookie_t cookie,
>> >> +  struct dma_tx_state *txstate)
>> >> +{
>> >> + int mchan_idx;
>> >> + enum dma_status ret;
>> >> + struct sba_device *sba = to_sba_device(dchan);
>> >> +
>> >> + ret = dma_cookie_status(dchan, cookie, txstate);
>> >> + if (ret == DMA_COMPLETE)
>> >> + return ret;
>> >> +
>> >> + for (mchan_idx = 0; mchan_idx < sba->mchans_count; mchan_idx++)
>> >> + mbox_client_peek_data(sba->mchans[mchan_idx]);
>> >
>> > what is this achieving?
>>
>> The mbox_client_peek_data() is a hint to mailbox controller driver
>> to check for available messages.
>>
>> This gives good performance improvement when some DMA client
>> code is polling using tx_status() callback.
>
> Then why do it before and then check status.

If there was a work completed when mbox_client_peek_data()
is called then sba_receive_message() will be called immediately
by mailbox controller driver.

We are doing dma_cookie_complete() in sba_receive_message()
so if mbox_client_peek_data() is called before dma_cookie_status()
then dma_cookie_status() will see correct state of cookie.

Also, I explored virt-dma APIs for BCM-SBA-RAID driver. The virt-dma
implements tasklet based bottom-half for each virt-dma-channel. This
bottom-half is not required for BCM-FS4-RAID driver because its a
mailbox client driver and the mailbox controller driver already implements
bottom-half for each mailbox channel.

If we still go ahead and use virt-dma in BCM-FS4-RAID driver then we
will have two bottom-halfs in-action one in mailbox controller driver and
another in BCM-FS4-RAID driver which in-turn will add bottom-half
scheduling overhead thereby reducing performance of BCM-FS4-RAID
driver.

Regards,
Anup

Re: [PATCH 5/6] dmaengine: Add Broadcom SBA RAID driver

[Anup Patel]

On Mon, Feb 6, 2017 at 10:24 PM, Vinod Koul  wrote:
> On Mon, Feb 06, 2017 at 05:31:15PM +0530, Anup Patel wrote:
>
>> >> +
>> >> +/* SBA C_MDATA helper macros */
>> >> +#define SBA_C_MDATA_LOAD_VAL(__bnum0)((__bnum0) & 0x3)
>> >> +#define SBA_C_MDATA_WRITE_VAL(__bnum0)   ((__bnum0) & 0x3)
>> >> +#define SBA_C_MDATA_XOR_VAL(__bnum1, __bnum0)\
>> >> + ({  u32 __v = ((__bnum0) & 0x3);\
>> >> + __v |= ((__bnum1) & 0x3) << 2;  \
>> >> + __v;\
>> >> + })
>> >> +#define SBA_C_MDATA_PQ_VAL(__dnum, __bnum1, __bnum0) \
>> >> + ({  u32 __v = ((__bnum0) & 0x3);\
>> >> + __v |= ((__bnum1) & 0x3) << 2;  \
>> >> + __v |= ((__dnum) & 0x1f) << 5;  \
>> >> + __v;\
>> >> + })
>> >
>> > ah why are we usig complex macros, why can't these be simple functions..
>>
>> "static inline functions" seemed too complicated here because most of
>> these macros are two lines of c-code.
>
> and thats where I have an issue with this. Macros for simple things is fine
> but not for couple of line of logic!
>
>>
>> Do you still insist on using "static inline functions"?
>
> Yes

Sure, will use "static inline functions" instead these macros.

>
>>
>> >
>> >> +#define SBA_C_MDATA_LS(__c_mdata_val)((__c_mdata_val) & 0xff)
>> >> +#define SBA_C_MDATA_MS(__c_mdata_val)(((__c_mdata_val) >> 8) & 
>> >> 0x3)
>> >> +
>> >> +/* Driver helper macros */
>> >> +#define to_sba_request(tx)   \
>> >> + container_of(tx, struct sba_request, tx)
>> >> +#define to_sba_device(dchan) \
>> >> + container_of(dchan, struct sba_device, dma_chan)
>> >> +
>> >> +enum sba_request_state {
>> >> + SBA_REQUEST_STATE_FREE = 1,
>> >> + SBA_REQUEST_STATE_ALLOCED = 2,
>> >> + SBA_REQUEST_STATE_PENDING = 3,
>> >> + SBA_REQUEST_STATE_ACTIVE = 4,
>> >> + SBA_REQUEST_STATE_COMPLETED = 5,
>> >> + SBA_REQUEST_STATE_ABORTED = 6,
>> >
>> > whats up with a very funny indentation setting, we use 8 chars.
>> >
>> > Please re-read the Documentation/process/coding-style.rst
>>
>> I have double checked this enum. The indentation is fine
>> and as-per coding style. Am I missing anything else?
>
> Somehow the initial indent doesnt seem to be 8 chars to me.
>
>> >> +static enum dma_status sba_tx_status(struct dma_chan *dchan,
>> >> +  dma_cookie_t cookie,
>> >> +  struct dma_tx_state *txstate)
>> >> +{
>> >> + int mchan_idx;
>> >> + enum dma_status ret;
>> >> + struct sba_device *sba = to_sba_device(dchan);
>> >> +
>> >> + ret = dma_cookie_status(dchan, cookie, txstate);
>> >> + if (ret == DMA_COMPLETE)
>> >> + return ret;
>> >> +
>> >> + for (mchan_idx = 0; mchan_idx < sba->mchans_count; mchan_idx++)
>> >> + mbox_client_peek_data(sba->mchans[mchan_idx]);
>> >
>> > what is this achieving?
>>
>> The mbox_client_peek_data() is a hint to mailbox controller driver
>> to check for available messages.
>>
>> This gives good performance improvement when some DMA client
>> code is polling using tx_status() callback.
>
> Then why do it before and then check status.

If there was a work completed when mbox_client_peek_data()
is called then sba_receive_message() will be called immediately
by mailbox controller driver.

We are doing dma_cookie_complete() in sba_receive_message()
so if mbox_client_peek_data() is called before dma_cookie_status()
then dma_cookie_status() will see correct state of cookie.

Also, I explored virt-dma APIs for BCM-SBA-RAID driver. The virt-dma
implements tasklet based bottom-half for each virt-dma-channel. This
bottom-half is not required for BCM-FS4-RAID driver because its a
mailbox client driver and the mailbox controller driver already implements
bottom-half for each mailbox channel.

If we still go ahead and use virt-dma in BCM-FS4-RAID driver then we
will have two bottom-halfs in-action one in mailbox controller driver and
another in BCM-FS4-RAID driver which in-turn will add bottom-half
scheduling overhead thereby reducing performance of BCM-FS4-RAID
driver.

Regards,
Anup

linux-next: Tree for Feb 7

[Stephen Rothwell]

Hi all,

Changes since 20170206:

The tty tree lost its build failure.

The akpm tree gained a conflict against the net-next tree.

Non-merge commits (relative to Linus' tree): 7711
 8737 files changed, 327880 insertions(+), 163014 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 256 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 (d5adbfcd5f7b Linux 4.10-rc7)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP 
defines before declaring the functions)
Merging arc-current/for-curr (8ba605b607b7 ARC: [plat-*] ARC_HAS_COH_CACHES no 
longer relevant)
Merging arm-current/fixes (228dbbfb5d77 ARM: 8643/3: arm/ptrace: Preserve 
previous registers for short regset write)
Merging m68k-current/for-linus (ad595b77c4a8 m68k/atari: Use seq_puts() in 
atari_get_hardware_list())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (a0615a16f7d0 powerpc/mm: Use the correct pointer 
when setting a 2MB pte)
Merging sparc/master (f9a42e0d58cf Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (b3f2d07f4649 hns: avoid stack overflow with CONFIG_KASAN)
Merging ipsec/master (4e5da369df64 Documentation/networking: fix typo in 
mpls-sysctl)
Merging netfilter/master (f95d7a46bc57 netfilter: ctnetlink: Fix regression in 
CTA_HELP processing)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (52f5631a4c05 rtlwifi: rtl8192ce: Fix loading 
of incorrect firmware)
Merging mac80211/master (fd551bac4795 nl80211: Fix mesh HT operation check)
Merging sound-current/for-linus (37a7ea4a9b81 ALSA: seq: Don't handle loop 
timeout at snd_seq_pool_done())
Merging pci-current/for-linus (77fbffc2aa09 Revert "PCI: pciehp: Add runtime PM 
support for PCIe hotplug ports")
Merging driver-core.current/driver-core-linus (49def1853334 Linux 4.10-rc4)
Merging tty.current/tty-linus (49def1853334 Linux 4.10-rc4)
Merging usb.current/usb-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix 
Wmaybe-uninitialized warning)
Merging usb-serial-fixes/usb-linus (d07830db1bdb USB: serial: pl2303: add ATEN 
device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging staging.current/staging-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging char-misc.current/char-misc-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging input-current/for-linus (601bbbe05173 Input: uinput - fix crash when 
mixing old and new init style)
Merging crypto-current/master (7c2cf1c4615c crypto: chcr - Fix key length for 
RFC4106)
Merging ide/master (da095587e6be Revert "ide: Fix interface autodetection in 
legacy IDE driver (trial #2)")
Merging vfio-fixes/for-linus (2da64d20a0b2 vfio/spapr: Fix missing mutex unlock 
when creating a window)
Merging kselftest-fixes/fixes (7738789fba09 selftests: x86/p

linux-next: Tree for Feb 7

[Stephen Rothwell]

Hi all,

Changes since 20170206:

The tty tree lost its build failure.

The akpm tree gained a conflict against the net-next tree.

Non-merge commits (relative to Linus' tree): 7711
 8737 files changed, 327880 insertions(+), 163014 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 256 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 (d5adbfcd5f7b Linux 4.10-rc7)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP 
defines before declaring the functions)
Merging arc-current/for-curr (8ba605b607b7 ARC: [plat-*] ARC_HAS_COH_CACHES no 
longer relevant)
Merging arm-current/fixes (228dbbfb5d77 ARM: 8643/3: arm/ptrace: Preserve 
previous registers for short regset write)
Merging m68k-current/for-linus (ad595b77c4a8 m68k/atari: Use seq_puts() in 
atari_get_hardware_list())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (a0615a16f7d0 powerpc/mm: Use the correct pointer 
when setting a 2MB pte)
Merging sparc/master (f9a42e0d58cf Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (b3f2d07f4649 hns: avoid stack overflow with CONFIG_KASAN)
Merging ipsec/master (4e5da369df64 Documentation/networking: fix typo in 
mpls-sysctl)
Merging netfilter/master (f95d7a46bc57 netfilter: ctnetlink: Fix regression in 
CTA_HELP processing)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (52f5631a4c05 rtlwifi: rtl8192ce: Fix loading 
of incorrect firmware)
Merging mac80211/master (fd551bac4795 nl80211: Fix mesh HT operation check)
Merging sound-current/for-linus (37a7ea4a9b81 ALSA: seq: Don't handle loop 
timeout at snd_seq_pool_done())
Merging pci-current/for-linus (77fbffc2aa09 Revert "PCI: pciehp: Add runtime PM 
support for PCIe hotplug ports")
Merging driver-core.current/driver-core-linus (49def1853334 Linux 4.10-rc4)
Merging tty.current/tty-linus (49def1853334 Linux 4.10-rc4)
Merging usb.current/usb-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix 
Wmaybe-uninitialized warning)
Merging usb-serial-fixes/usb-linus (d07830db1bdb USB: serial: pl2303: add ATEN 
device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging staging.current/staging-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging char-misc.current/char-misc-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging input-current/for-linus (601bbbe05173 Input: uinput - fix crash when 
mixing old and new init style)
Merging crypto-current/master (7c2cf1c4615c crypto: chcr - Fix key length for 
RFC4106)
Merging ide/master (da095587e6be Revert "ide: Fix interface autodetection in 
legacy IDE driver (trial #2)")
Merging vfio-fixes/for-linus (2da64d20a0b2 vfio/spapr: Fix missing mutex unlock 
when creating a window)
Merging kselftest-fixes/fixes (7738789fba09 selftests: x86/p

[PATCH v2] perf/probe: Change MAX_CMDLEN

[Ravi Bangoria]

There are many SDT markers in powerpc whose uprobe definition goes
beyond current MAX_CMDLEN, especially when target filename is long
and sdt marker has long list of arguments. For example, definition
of sdt marker

  method__compile__end: 8@17 8@9 8@10 -4@8 8@7 -4@6 8@5 -4@4 1@37(28)

from file

  /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.91-2.b14.fc22.ppc64/jre/lib/\
 ppc64/server/libjvm.so

is

  p:sdt_hotspot/method__compile__end /usr/lib/jvm/java-1.8.0-openjdk-\
1.8.0.91-2.b14.fc22.ppc64/jre/lib/ppc64/server/libjvm.so:0x4c4e00\
arg1=%gpr17:u64 arg2=%gpr9:u64 arg3=%gpr10:u64 arg4=%gpr8:s32\
arg5=%gpr7:u64 arg6=%gpr6:s32 arg7=%gpr5:u64 arg8=%gpr4:s32\
arg9=+37(%gpr28):u8

Perf probe fails with seg fault for such markers. As uprobe_events file
accepts definition upto 4094 characters(4096 - 2 (\n\0)), increase value
of MAX_CMDLEN to 4094.

Signed-off-by: Ravi Bangoria 
---
Changes in v2:
  - Set MAX_CMDLEN to 4094 instead of 512

 tools/perf/util/probe-event.c | 1 -
 tools/perf/util/probe-file.c  | 3 ++-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 6a6f44d..e6e3244 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -47,7 +47,6 @@
 #include "probe-file.h"
 #include "session.h"
 
-#define MAX_CMDLEN 256
 #define PERFPROBE_GROUP "probe"
 
 bool probe_event_dry_run;  /* Dry run flag */
diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index 38eca3c..fdabe7e 100644
--- a/tools/perf/util/probe-file.c
+++ b/tools/perf/util/probe-file.c
@@ -29,7 +29,8 @@
 #include "session.h"
 #include "perf_regs.h"
 
-#define MAX_CMDLEN 256
+/* 4096 - 2 ('\n' + '\0') */
+#define MAX_CMDLEN 4094
 
 static void print_open_warning(int err, bool uprobe)
 {
-- 
2.9.3

[PATCH v2] perf/probe: Change MAX_CMDLEN

[Ravi Bangoria]

There are many SDT markers in powerpc whose uprobe definition goes
beyond current MAX_CMDLEN, especially when target filename is long
and sdt marker has long list of arguments. For example, definition
of sdt marker

  method__compile__end: 8@17 8@9 8@10 -4@8 8@7 -4@6 8@5 -4@4 1@37(28)

from file

  /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.91-2.b14.fc22.ppc64/jre/lib/\
 ppc64/server/libjvm.so

is

  p:sdt_hotspot/method__compile__end /usr/lib/jvm/java-1.8.0-openjdk-\
1.8.0.91-2.b14.fc22.ppc64/jre/lib/ppc64/server/libjvm.so:0x4c4e00\
arg1=%gpr17:u64 arg2=%gpr9:u64 arg3=%gpr10:u64 arg4=%gpr8:s32\
arg5=%gpr7:u64 arg6=%gpr6:s32 arg7=%gpr5:u64 arg8=%gpr4:s32\
arg9=+37(%gpr28):u8

Perf probe fails with seg fault for such markers. As uprobe_events file
accepts definition upto 4094 characters(4096 - 2 (\n\0)), increase value
of MAX_CMDLEN to 4094.

Signed-off-by: Ravi Bangoria 
---
Changes in v2:
  - Set MAX_CMDLEN to 4094 instead of 512

 tools/perf/util/probe-event.c | 1 -
 tools/perf/util/probe-file.c  | 3 ++-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 6a6f44d..e6e3244 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -47,7 +47,6 @@
 #include "probe-file.h"
 #include "session.h"
 
-#define MAX_CMDLEN 256
 #define PERFPROBE_GROUP "probe"
 
 bool probe_event_dry_run;  /* Dry run flag */
diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index 38eca3c..fdabe7e 100644
--- a/tools/perf/util/probe-file.c
+++ b/tools/perf/util/probe-file.c
@@ -29,7 +29,8 @@
 #include "session.h"
 #include "perf_regs.h"
 
-#define MAX_CMDLEN 256
+/* 4096 - 2 ('\n' + '\0') */
+#define MAX_CMDLEN 4094
 
 static void print_open_warning(int err, bool uprobe)
 {
-- 
2.9.3

Re: [lkp-robot] [scsi, block] 0dba1314d4: WARNING:at_fs/sysfs/dir.c:#sysfs_warn_dup

[Dan Williams]

On Mon, Feb 6, 2017 at 8:09 PM, Jens Axboe  wrote:
> On 02/06/2017 05:14 PM, James Bottomley wrote:
>> On Sun, 2017-02-05 at 21:13 -0800, Dan Williams wrote:
>>> On Sun, Feb 5, 2017 at 1:13 AM, Christoph Hellwig  wrote:
 Dan,

 can you please quote your emails?  I can't find any content
 inbetween all these quotes.
>>>
>>> Sorry, I'm using gmail, but I'll switch to attaching the logs.
>>>
>>> So with help from Xiaolong I was able to reproduce this, and it does
>>> not appear to be a regression. We simply change the failure output of
>>> an existing bug. Attached is a log of the same test on v4.10-rc7
>>> (i.e. without the recent block/scsi fixes), and it shows sda being
>>> registered twice.
>>>
>>> "[6.647077] kobject (d5078ca4): tried to init an initialized
>>> object, something is seriously wrong."
>>>
>>> The change that "scsi, block: fix duplicate bdi name registration
>>> crashes" makes is to properly try to register sdb since the sda devt
>>> is still alive. However that's not a fix because we've managed to
>>> call blk_register_queue() twice on the same queue.
>>
>> OK, time to involve others: linux-scsi and linux-block cc'd and I've
>> inserted the log below.
>>
>> James
>>
>> ---
>>
>> [5.969672] scsi host0: scsi_debug: version 1.86 [20160430]
>> [5.969672]   dev_size_mb=8, opts=0x0, submit_queues=1, statistics=0
>> [5.971895] scsi 0:0:0:0: Direct-Access Linuxscsi_debug   
>> 0186 PQ: 0 ANSI: 7
>> [6.006983] sd 0:0:0:0: [sda] 16384 512-byte logical blocks: (8.39 
>> MB/8.00 MiB)
>> [6.026965] sd 0:0:0:0: [sda] Write Protect is off
>> [6.027870] sd 0:0:0:0: [sda] Mode Sense: 73 00 10 08
>> [6.066962] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
>> supports DPO and FUA
>> [6.486962] sd 0:0:0:0: [sda] Attached SCSI disk
>> [6.488377] sd 0:0:0:0: [sda] Synchronizing SCSI cache
>> [6.489455] sd 0:0:0:0: Attached scsi generic sg0 type 0
>> [6.526982] sd 0:0:0:0: [sda] 16384 512-byte logical blocks: (8.39 
>> MB/8.00 MiB)
>> [6.546964] sd 0:0:0:0: [sda] Write Protect is off
>> [6.547873] sd 0:0:0:0: [sda] Mode Sense: 73 00 10 08
>> [6.586963] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
>> supports DPO and FUA
>> [6.647077] kobject (d5078ca4): tried to init an initialized object, 
>> something is seriously wrong.
>
> So sda is probed twice, and hilarity ensues when we try to register it
> twice.  I can't reproduce this, using scsi_debug and with scsi_async
> enabled.
>
> This is running linux-next? What's your .config?
>

The original failure report is here:

http://marc.info/?l=linux-kernel=148619222300774=2

...but it reproduces on current mainline with the same config. I
haven't spotted what makes scsi_debug behave like this.

Re: [lkp-robot] [scsi, block] 0dba1314d4: WARNING:at_fs/sysfs/dir.c:#sysfs_warn_dup

[Dan Williams]

On Mon, Feb 6, 2017 at 8:09 PM, Jens Axboe  wrote:
> On 02/06/2017 05:14 PM, James Bottomley wrote:
>> On Sun, 2017-02-05 at 21:13 -0800, Dan Williams wrote:
>>> On Sun, Feb 5, 2017 at 1:13 AM, Christoph Hellwig  wrote:
 Dan,

 can you please quote your emails?  I can't find any content
 inbetween all these quotes.
>>>
>>> Sorry, I'm using gmail, but I'll switch to attaching the logs.
>>>
>>> So with help from Xiaolong I was able to reproduce this, and it does
>>> not appear to be a regression. We simply change the failure output of
>>> an existing bug. Attached is a log of the same test on v4.10-rc7
>>> (i.e. without the recent block/scsi fixes), and it shows sda being
>>> registered twice.
>>>
>>> "[6.647077] kobject (d5078ca4): tried to init an initialized
>>> object, something is seriously wrong."
>>>
>>> The change that "scsi, block: fix duplicate bdi name registration
>>> crashes" makes is to properly try to register sdb since the sda devt
>>> is still alive. However that's not a fix because we've managed to
>>> call blk_register_queue() twice on the same queue.
>>
>> OK, time to involve others: linux-scsi and linux-block cc'd and I've
>> inserted the log below.
>>
>> James
>>
>> ---
>>
>> [5.969672] scsi host0: scsi_debug: version 1.86 [20160430]
>> [5.969672]   dev_size_mb=8, opts=0x0, submit_queues=1, statistics=0
>> [5.971895] scsi 0:0:0:0: Direct-Access Linuxscsi_debug   
>> 0186 PQ: 0 ANSI: 7
>> [6.006983] sd 0:0:0:0: [sda] 16384 512-byte logical blocks: (8.39 
>> MB/8.00 MiB)
>> [6.026965] sd 0:0:0:0: [sda] Write Protect is off
>> [6.027870] sd 0:0:0:0: [sda] Mode Sense: 73 00 10 08
>> [6.066962] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
>> supports DPO and FUA
>> [6.486962] sd 0:0:0:0: [sda] Attached SCSI disk
>> [6.488377] sd 0:0:0:0: [sda] Synchronizing SCSI cache
>> [6.489455] sd 0:0:0:0: Attached scsi generic sg0 type 0
>> [6.526982] sd 0:0:0:0: [sda] 16384 512-byte logical blocks: (8.39 
>> MB/8.00 MiB)
>> [6.546964] sd 0:0:0:0: [sda] Write Protect is off
>> [6.547873] sd 0:0:0:0: [sda] Mode Sense: 73 00 10 08
>> [6.586963] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
>> supports DPO and FUA
>> [6.647077] kobject (d5078ca4): tried to init an initialized object, 
>> something is seriously wrong.
>
> So sda is probed twice, and hilarity ensues when we try to register it
> twice.  I can't reproduce this, using scsi_debug and with scsi_async
> enabled.
>
> This is running linux-next? What's your .config?
>

The original failure report is here:

http://marc.info/?l=linux-kernel=148619222300774=2

...but it reproduces on current mainline with the same config. I
haven't spotted what makes scsi_debug behave like this.

Re: [PATCH 1/2] arm: dts: qcom: msm8974: Add RPMCC DT node

[Bjorn Andersson]

On Fri 03 Feb 10:36 PST 2017, Georgi Djakov wrote:

> Add the RPM Clock Controller DT node for msm8974-based platforms, so that
> drivers can use the clocks provided by the RPM processor.
> 
> Signed-off-by: Georgi Djakov 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> ---
>  arch/arm/boot/dts/qcom-msm8974.dtsi | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
> b/arch/arm/boot/dts/qcom-msm8974.dtsi
> index d3e1a61b8671..4b4c61e2ee35 100644
> --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> @@ -2,6 +2,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "skeleton.dtsi"
> @@ -760,6 +761,11 @@
>   compatible = "qcom,rpm-msm8974";
>   qcom,smd-channels = "rpm_requests";
>  
> + rpmcc: clock-controller {
> + compatible = "qcom,rpmcc-msm8974", 
> "qcom,rpmcc";
> + #clock-cells = <1>;
> + };
> +
>   pm8841-regulators {
>   compatible = 
> "qcom,rpm-pm8841-regulators";
>  

Re: [PATCH 1/2] arm: dts: qcom: msm8974: Add RPMCC DT node

[Bjorn Andersson]

On Fri 03 Feb 10:36 PST 2017, Georgi Djakov wrote:

> Add the RPM Clock Controller DT node for msm8974-based platforms, so that
> drivers can use the clocks provided by the RPM processor.
> 
> Signed-off-by: Georgi Djakov 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> ---
>  arch/arm/boot/dts/qcom-msm8974.dtsi | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
> b/arch/arm/boot/dts/qcom-msm8974.dtsi
> index d3e1a61b8671..4b4c61e2ee35 100644
> --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> @@ -2,6 +2,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "skeleton.dtsi"
> @@ -760,6 +761,11 @@
>   compatible = "qcom,rpm-msm8974";
>   qcom,smd-channels = "rpm_requests";
>  
> + rpmcc: clock-controller {
> + compatible = "qcom,rpmcc-msm8974", 
> "qcom,rpmcc";
> + #clock-cells = <1>;
> + };
> +
>   pm8841-regulators {
>   compatible = 
> "qcom,rpm-pm8841-regulators";
>  

[PATCH] arm64: dts: mediatek: add mt8176 device tree

[Yidi Lin]

The core configuration is the only difference between mt8173 and mt8176.
Like what arm/juno and marvell/armada-ap806 did, this change splits
mt8173.dtsi into mt817x.dtsi and mt8173.dtsi. mt817x.dtsi defines the
common blocks for mt8173 and mt8176. mt8173.dtsi and mt8176.dtsi
describe mt8173 and mt8176 respectively.

Signed-off-by: Yidi Lin 
---
 Documentation/devicetree/bindings/arm/mediatek.txt |1 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   | 1205 +---
 arch/arm64/boot/dts/mediatek/mt8176.dtsi   |  125 ++
 arch/arm64/boot/dts/mediatek/mt817x.dtsi   | 1199 +++
 4 files changed, 1338 insertions(+), 1192 deletions(-)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8176.dtsi
 create mode 100644 arch/arm64/boot/dts/mediatek/mt817x.dtsi

diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt 
b/Documentation/devicetree/bindings/arm/mediatek.txt
index c860b24..f305149 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek.txt
@@ -16,6 +16,7 @@ compatible: Must contain one of
"mediatek,mt8127"
"mediatek,mt8135"
"mediatek,mt8173"
+   "mediatek,mt8176"
 
 
 Supported boards:
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 12e7027..c0a9cfa 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2014 MediaTek Inc.
+ * Copyright (c) 2016 MediaTek Inc.
  * Author: Eddie Huang 
  *
  * This program is free software; you can redistribute it and/or modify
@@ -11,45 +11,10 @@
  * GNU General Public License for more details.
  */
 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include "mt8173-pinfunc.h"
+#include "mt817x.dtsi"
 
 / {
compatible = "mediatek,mt8173";
-   interrupt-parent = <>;
-   #address-cells = <2>;
-   #size-cells = <2>;
-
-   aliases {
-   ovl0 = 
-   ovl1 = 
-   rdma0 = 
-   rdma1 = 
-   rdma2 = 
-   wdma0 = 
-   wdma1 = 
-   color0 = 
-   color1 = 
-   split0 = 
-   split1 = 
-   dpi0 = 
-   dsi0 = 
-   dsi1 = 
-   mdp_rdma0 = _rdma0;
-   mdp_rdma1 = _rdma1;
-   mdp_rsz0 = _rsz0;
-   mdp_rsz1 = _rsz1;
-   mdp_rsz2 = _rsz2;
-   mdp_wdma0 = _wdma0;
-   mdp_wrot0 = _wrot0;
-   mdp_wrot1 = _wrot1;
-   };
 
cpus {
#address-cells = <1>;
@@ -120,1163 +85,19 @@
};
};
};
+};
 
-   psci {
-   compatible = "arm,psci-1.0", "arm,psci-0.2", "arm,psci";
-   method = "smc";
-   cpu_suspend   = <0x8401>;
-   cpu_off   = <0x8402>;
-   cpu_on= <0x8403>;
-   };
-
-   clk26m: oscillator@0 {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <2600>;
-   clock-output-names = "clk26m";
-   };
-
-   clk32k: oscillator@1 {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <32000>;
-   clock-output-names = "clk32k";
-   };
-
-   cpum_ck: oscillator@2 {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <0>;
-   clock-output-names = "cpum_ck";
-   };
-
-   thermal-zones {
-   cpu_thermal: cpu_thermal {
-   polling-delay-passive = <1000>; /* milliseconds */
-   polling-delay = <1000>; /* milliseconds */
-
-   thermal-sensors = <>;
-   sustainable-power = <1500>; /* milliwatts */
-
-   trips {
-   threshold: trip-point@0 {
-   temperature = <68000>;
-   hysteresis = <2000>;
-   type = "passive";
-   };
-
-   target: trip-point@1 {
-   temperature = <85000>;
-   hysteresis = <2000>;
-   type = "passive";
-   };
-
-   cpu_crit: cpu_crit@0 {
-   temperature = <115000>;
-   hysteresis = <2000>;
-   type = "critical";
-   };
-   };
-
-   

[PATCH] arm64: dts: mediatek: add mt8176 device tree

[Yidi Lin]

The core configuration is the only difference between mt8173 and mt8176.
Like what arm/juno and marvell/armada-ap806 did, this change splits
mt8173.dtsi into mt817x.dtsi and mt8173.dtsi. mt817x.dtsi defines the
common blocks for mt8173 and mt8176. mt8173.dtsi and mt8176.dtsi
describe mt8173 and mt8176 respectively.

Signed-off-by: Yidi Lin 
---
 Documentation/devicetree/bindings/arm/mediatek.txt |1 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   | 1205 +---
 arch/arm64/boot/dts/mediatek/mt8176.dtsi   |  125 ++
 arch/arm64/boot/dts/mediatek/mt817x.dtsi   | 1199 +++
 4 files changed, 1338 insertions(+), 1192 deletions(-)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8176.dtsi
 create mode 100644 arch/arm64/boot/dts/mediatek/mt817x.dtsi

diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt 
b/Documentation/devicetree/bindings/arm/mediatek.txt
index c860b24..f305149 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek.txt
@@ -16,6 +16,7 @@ compatible: Must contain one of
"mediatek,mt8127"
"mediatek,mt8135"
"mediatek,mt8173"
+   "mediatek,mt8176"
 
 
 Supported boards:
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 12e7027..c0a9cfa 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2014 MediaTek Inc.
+ * Copyright (c) 2016 MediaTek Inc.
  * Author: Eddie Huang 
  *
  * This program is free software; you can redistribute it and/or modify
@@ -11,45 +11,10 @@
  * GNU General Public License for more details.
  */
 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include "mt8173-pinfunc.h"
+#include "mt817x.dtsi"
 
 / {
compatible = "mediatek,mt8173";
-   interrupt-parent = <>;
-   #address-cells = <2>;
-   #size-cells = <2>;
-
-   aliases {
-   ovl0 = 
-   ovl1 = 
-   rdma0 = 
-   rdma1 = 
-   rdma2 = 
-   wdma0 = 
-   wdma1 = 
-   color0 = 
-   color1 = 
-   split0 = 
-   split1 = 
-   dpi0 = 
-   dsi0 = 
-   dsi1 = 
-   mdp_rdma0 = _rdma0;
-   mdp_rdma1 = _rdma1;
-   mdp_rsz0 = _rsz0;
-   mdp_rsz1 = _rsz1;
-   mdp_rsz2 = _rsz2;
-   mdp_wdma0 = _wdma0;
-   mdp_wrot0 = _wrot0;
-   mdp_wrot1 = _wrot1;
-   };
 
cpus {
#address-cells = <1>;
@@ -120,1163 +85,19 @@
};
};
};
+};
 
-   psci {
-   compatible = "arm,psci-1.0", "arm,psci-0.2", "arm,psci";
-   method = "smc";
-   cpu_suspend   = <0x8401>;
-   cpu_off   = <0x8402>;
-   cpu_on= <0x8403>;
-   };
-
-   clk26m: oscillator@0 {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <2600>;
-   clock-output-names = "clk26m";
-   };
-
-   clk32k: oscillator@1 {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <32000>;
-   clock-output-names = "clk32k";
-   };
-
-   cpum_ck: oscillator@2 {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <0>;
-   clock-output-names = "cpum_ck";
-   };
-
-   thermal-zones {
-   cpu_thermal: cpu_thermal {
-   polling-delay-passive = <1000>; /* milliseconds */
-   polling-delay = <1000>; /* milliseconds */
-
-   thermal-sensors = <>;
-   sustainable-power = <1500>; /* milliwatts */
-
-   trips {
-   threshold: trip-point@0 {
-   temperature = <68000>;
-   hysteresis = <2000>;
-   type = "passive";
-   };
-
-   target: trip-point@1 {
-   temperature = <85000>;
-   hysteresis = <2000>;
-   type = "passive";
-   };
-
-   cpu_crit: cpu_crit@0 {
-   temperature = <115000>;
-   hysteresis = <2000>;
-   type = "critical";
-   };
-   };
-
-   cooling-maps {
-   map@0 

linux-next: manual merge of the akpm tree with the net-next tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in:

  drivers/net/can/flexcan.c

between commits:

  9eb7aa891101 ("can: flexcan: add quirk FLEXCAN_QUIRK_ENABLE_EACEN_RRS")
  b3cf53e988ce ("can: flexcan: add support for timestamp based rx-offload")

from the net-next tree and commit:

  "scripts/spelling.txt: add "disble(d)" pattern and fix typo instances"

from the akpm 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.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/can/flexcan.c
index ea57fed375c6,4dc71bce525c..
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@@ -195,9 -189,7 +195,9 @@@
   */
  #define FLEXCAN_QUIRK_BROKEN_ERR_STATEBIT(1) /* [TR]WRN_INT not 
connected */
  #define FLEXCAN_QUIRK_DISABLE_RXFGBIT(2) /* Disable RX FIFO Global mask */
 -#define FLEXCAN_QUIRK_DISABLE_MECRBIT(3) /* Disable Memory error 
detection */
 +#define FLEXCAN_QUIRK_ENABLE_EACEN_RRSBIT(3) /* Enable EACEN and RRS 
bit in ctrl2 */
- #define FLEXCAN_QUIRK_DISABLE_MECRBIT(4) /* Disble Memory error detection 
*/
++#define FLEXCAN_QUIRK_DISABLE_MECRBIT(4) /* Disbale Memory error 
detection */
 +#define FLEXCAN_QUIRK_USE_OFF_TIMESTAMP   BIT(5) /* Use timestamp based 
offloading */
  
  /* Structure of the message buffer */
  struct flexcan_mb {

linux-next: manual merge of the akpm tree with the net-next tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in:

  drivers/net/can/flexcan.c

between commits:

  9eb7aa891101 ("can: flexcan: add quirk FLEXCAN_QUIRK_ENABLE_EACEN_RRS")
  b3cf53e988ce ("can: flexcan: add support for timestamp based rx-offload")

from the net-next tree and commit:

  "scripts/spelling.txt: add "disble(d)" pattern and fix typo instances"

from the akpm 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.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/can/flexcan.c
index ea57fed375c6,4dc71bce525c..
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@@ -195,9 -189,7 +195,9 @@@
   */
  #define FLEXCAN_QUIRK_BROKEN_ERR_STATEBIT(1) /* [TR]WRN_INT not 
connected */
  #define FLEXCAN_QUIRK_DISABLE_RXFGBIT(2) /* Disable RX FIFO Global mask */
 -#define FLEXCAN_QUIRK_DISABLE_MECRBIT(3) /* Disable Memory error 
detection */
 +#define FLEXCAN_QUIRK_ENABLE_EACEN_RRSBIT(3) /* Enable EACEN and RRS 
bit in ctrl2 */
- #define FLEXCAN_QUIRK_DISABLE_MECRBIT(4) /* Disble Memory error detection 
*/
++#define FLEXCAN_QUIRK_DISABLE_MECRBIT(4) /* Disbale Memory error 
detection */
 +#define FLEXCAN_QUIRK_USE_OFF_TIMESTAMP   BIT(5) /* Use timestamp based 
offloading */
  
  /* Structure of the message buffer */
  struct flexcan_mb {

Re: [PATCH 3/5] perf/sdt/x86: Move OP parser to tools/perf/arch/x86/

[Ravi Bangoria]

Thanks Masami for the review.

On Tuesday 07 February 2017 08:41 AM, Masami Hiramatsu wrote:
> On Thu,  2 Feb 2017 16:41:41 +0530
> Ravi Bangoria  wrote:
>
>> SDT marker argument is in N@OP format. N is the size of argument and
>> OP is the actual assembly operand. OP is arch dependent component and
>> hence it's parsing logic also should be placed under tools/perf/arch/.
>>
> Ok, I have one question. Is there any possibility that N is different
> size of OP? e.g. 8@dil, in this case we will record whole rdi.
> is that OK?

By looking at list of markers on my x86 Fedora25 box, yes, it's possible
for case when register size used in OP is more than size specified by N.
For example, -4@68(%rbx). But I don't see any argument which specifies
higher size in N compared to size of register in OP, like you mentioned
in your example.

Ravi

[PATCH] Make EN2 pin optional in the TRF7970A driver

[Heiko Schocher]

From: Guan Ben 

Make the EN2 pin optional. This is useful for boards,
which have this pin fix wired, for example to ground.

Signed-off-by: Guan Ben 
Signed-off-by: Mark Jonas 
Signed-off-by: Heiko Schocher 

---

 .../devicetree/bindings/net/nfc/trf7970a.txt   |  4 ++--
 drivers/nfc/trf7970a.c | 26 --
 2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt 
b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
index 32b35a0..5889a3d 100644
--- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -5,8 +5,8 @@ Required properties:
 - spi-max-frequency: Maximum SPI frequency (<= 200).
 - interrupt-parent: phandle of parent interrupt handler.
 - interrupts: A single interrupt specifier.
-- ti,enable-gpios: Two GPIO entries used for 'EN' and 'EN2' pins on the
-  TRF7970A.
+- ti,enable-gpios: One or two GPIO entries used for 'EN' and 'EN2' pins on the
+  TRF7970A. EN2 is optional.
 - vin-supply: Regulator for supply voltage to VIN pin
 
 Optional SoC Specific Properties:
diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
index 26c9dbb..75079fb 100644
--- a/drivers/nfc/trf7970a.c
+++ b/drivers/nfc/trf7970a.c
@@ -1885,8 +1885,10 @@ static int trf7970a_power_up(struct trf7970a *trf)
usleep_range(5000, 6000);
 
if (!(trf->quirks & TRF7970A_QUIRK_EN2_MUST_STAY_LOW)) {
-   gpio_set_value(trf->en2_gpio, 1);
-   usleep_range(1000, 2000);
+   if (gpio_is_valid(trf->en2_gpio)) {
+   gpio_set_value(trf->en2_gpio, 1);
+   usleep_range(1000, 2000);
+   }
}
 
gpio_set_value(trf->en_gpio, 1);
@@ -1914,7 +1916,8 @@ static int trf7970a_power_down(struct trf7970a *trf)
}
 
gpio_set_value(trf->en_gpio, 0);
-   gpio_set_value(trf->en2_gpio, 0);
+   if (gpio_is_valid(trf->en2_gpio))
+   gpio_set_value(trf->en2_gpio, 0);
 
ret = regulator_disable(trf->regulator);
if (ret)
@@ -2032,15 +2035,14 @@ static int trf7970a_probe(struct spi_device *spi)
 
trf->en2_gpio = of_get_named_gpio(np, "ti,enable-gpios", 1);
if (!gpio_is_valid(trf->en2_gpio)) {
-   dev_err(trf->dev, "No EN2 GPIO property\n");
-   return trf->en2_gpio;
-   }
-
-   ret = devm_gpio_request_one(trf->dev, trf->en2_gpio,
-   GPIOF_DIR_OUT | GPIOF_INIT_LOW, "trf7970a EN2");
-   if (ret) {
-   dev_err(trf->dev, "Can't request EN2 GPIO: %d\n", ret);
-   return ret;
+   dev_info(trf->dev, "No EN2 GPIO property\n");
+   } else {
+   ret = devm_gpio_request_one(trf->dev, trf->en2_gpio,
+   GPIOF_DIR_OUT | GPIOF_INIT_LOW, "trf7970a EN2");
+   if (ret) {
+   dev_err(trf->dev, "Can't request EN2 GPIO: %d\n", ret);
+   return ret;
+   }
}
 
if (of_property_read_bool(np, "en2-rf-quirk"))
-- 
2.7.4

Re: [PATCH 3/5] perf/sdt/x86: Move OP parser to tools/perf/arch/x86/

[Ravi Bangoria]

Thanks Masami for the review.

On Tuesday 07 February 2017 08:41 AM, Masami Hiramatsu wrote:
> On Thu,  2 Feb 2017 16:41:41 +0530
> Ravi Bangoria  wrote:
>
>> SDT marker argument is in N@OP format. N is the size of argument and
>> OP is the actual assembly operand. OP is arch dependent component and
>> hence it's parsing logic also should be placed under tools/perf/arch/.
>>
> Ok, I have one question. Is there any possibility that N is different
> size of OP? e.g. 8@dil, in this case we will record whole rdi.
> is that OK?

By looking at list of markers on my x86 Fedora25 box, yes, it's possible
for case when register size used in OP is more than size specified by N.
For example, -4@68(%rbx). But I don't see any argument which specifies
higher size in N compared to size of register in OP, like you mentioned
in your example.

Ravi

[PATCH] Make EN2 pin optional in the TRF7970A driver

[Heiko Schocher]

From: Guan Ben 

Make the EN2 pin optional. This is useful for boards,
which have this pin fix wired, for example to ground.

Signed-off-by: Guan Ben 
Signed-off-by: Mark Jonas 
Signed-off-by: Heiko Schocher 

---

 .../devicetree/bindings/net/nfc/trf7970a.txt   |  4 ++--
 drivers/nfc/trf7970a.c | 26 --
 2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt 
b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
index 32b35a0..5889a3d 100644
--- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -5,8 +5,8 @@ Required properties:
 - spi-max-frequency: Maximum SPI frequency (<= 200).
 - interrupt-parent: phandle of parent interrupt handler.
 - interrupts: A single interrupt specifier.
-- ti,enable-gpios: Two GPIO entries used for 'EN' and 'EN2' pins on the
-  TRF7970A.
+- ti,enable-gpios: One or two GPIO entries used for 'EN' and 'EN2' pins on the
+  TRF7970A. EN2 is optional.
 - vin-supply: Regulator for supply voltage to VIN pin
 
 Optional SoC Specific Properties:
diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
index 26c9dbb..75079fb 100644
--- a/drivers/nfc/trf7970a.c
+++ b/drivers/nfc/trf7970a.c
@@ -1885,8 +1885,10 @@ static int trf7970a_power_up(struct trf7970a *trf)
usleep_range(5000, 6000);
 
if (!(trf->quirks & TRF7970A_QUIRK_EN2_MUST_STAY_LOW)) {
-   gpio_set_value(trf->en2_gpio, 1);
-   usleep_range(1000, 2000);
+   if (gpio_is_valid(trf->en2_gpio)) {
+   gpio_set_value(trf->en2_gpio, 1);
+   usleep_range(1000, 2000);
+   }
}
 
gpio_set_value(trf->en_gpio, 1);
@@ -1914,7 +1916,8 @@ static int trf7970a_power_down(struct trf7970a *trf)
}
 
gpio_set_value(trf->en_gpio, 0);
-   gpio_set_value(trf->en2_gpio, 0);
+   if (gpio_is_valid(trf->en2_gpio))
+   gpio_set_value(trf->en2_gpio, 0);
 
ret = regulator_disable(trf->regulator);
if (ret)
@@ -2032,15 +2035,14 @@ static int trf7970a_probe(struct spi_device *spi)
 
trf->en2_gpio = of_get_named_gpio(np, "ti,enable-gpios", 1);
if (!gpio_is_valid(trf->en2_gpio)) {
-   dev_err(trf->dev, "No EN2 GPIO property\n");
-   return trf->en2_gpio;
-   }
-
-   ret = devm_gpio_request_one(trf->dev, trf->en2_gpio,
-   GPIOF_DIR_OUT | GPIOF_INIT_LOW, "trf7970a EN2");
-   if (ret) {
-   dev_err(trf->dev, "Can't request EN2 GPIO: %d\n", ret);
-   return ret;
+   dev_info(trf->dev, "No EN2 GPIO property\n");
+   } else {
+   ret = devm_gpio_request_one(trf->dev, trf->en2_gpio,
+   GPIOF_DIR_OUT | GPIOF_INIT_LOW, "trf7970a EN2");
+   if (ret) {
+   dev_err(trf->dev, "Can't request EN2 GPIO: %d\n", ret);
+   return ret;
+   }
}
 
if (of_property_read_bool(np, "en2-rf-quirk"))
-- 
2.7.4